Skip to main content
Status: draft · Version 0.1 · Filed 2026-04-25

​
SPEC-043: Session-Start Delta Symmetry — Lifecycle Genesis Events as First-Class Deltas

​
Version

0.1

​
Status

draft

​
Origin

SPEC-040 §6 Q3 decision (ratified by Frank: option C — symmetric): when hd_exec ships, it writes a delta_kind='pickup' delta on every successful pickup. For audit-trail symmetry, prism_start MUST do the same — write a delta_kind='start' delta on every successful registration. Currently it does not (per recon read of mcp/server.py:1325-1422). Without this fix, the delta stream has asymmetric coverage:
Lifecycle eventWrites delta?
prism_wrapYes — delta_kind='wrap' via _do_hygiene
prism_checkpointYes — analogous via _do_hygiene
hd_exec (after SPEC-040)Yes — delta_kind='pickup'
prism_startNo ← the gap this spec closes
A query like “show me every session boundary on this project” returns incomplete results today — starts are invisible. Fixing it now while we’re already in the lifecycle layer (SPEC-038/040/041 are touching the same code) is cheaper than fixing it later.

​
§1 — Rule

prism_start MUST emit a delta_kind='start' delta on every successful session registration. Delta body fields: 
{
  "session_id": "<new uuid>",
  "agent_identity": "<resolved per SPEC-038>",
  "agent_surface": "<claude_code | claude_desktop | ...>",
  "started_at": "<iso8601>",
  "bootstrap_path": "<explicit_pid | name_arg | env_var | cwd_basename | elicitation>",
  "machine_id": "<hostname>"
}

​
§2 — Implementation

mcp/server.py (around line 1511-1519, after register_controller returns successfully): write a delta via the same client.store_session_delta or _do_hygiene path that prism_wrap uses, with delta_kind='start' and the body above. Idempotency: a successful prism_start produces exactly one start delta. A re-bootstrapped session (SPEC-024 L1 in-process flag short- circuits a second prism_start call within the same process) does NOT write a duplicate.

​
§3 — Verification

  1. Fresh prism_start call → recent_deltas list now includes a delta_kind='start' entry as the most recent delta.
  2. Second prism_start in the same process (no-op due to L1 in-memory flag) → no duplicate start delta written.
  3. Cross-check with SPEC-040 verification §5.1: hd_exec’s pickup delta and prism_start’s start delta both appear in the delta stream with distinct kinds.
  4. Backfill query: count of start deltas per project equals count of distinct session_ids registered post-deploy. Pre-deploy gap is acceptable (no retroactive writes).

​
§4 — Decisions

  • Q1 (backfill pre-deploy starts?): NO. Pre-deploy gap is fine; the point is going-forward symmetry. Synthesizing historical start deltas would muddle audit trails with fictional events.
  • Q2 (does hd_exec ALSO write a start delta in addition to its pickup delta?): NO. A pickup IS a session-genesis event of a specific kind (pickup); writing both would double-count. One delta per genesis, with delta_kind reflecting the kind.
Last modified on April 27, 2026