> ## Documentation Index
> Fetch the complete documentation index at: https://prism.ntecdev.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# SPEC-043 v0.1: Session-Start Delta Symmetry — Lifecycle Genesis Events as First-Class Deltas

> Session-Start Delta Symmetry — Lifecycle Genesis Events as First-Class Deltas

<Info>**Status:** `draft` · **Version** `0.1` · Filed 2026-04-25</Info>

# 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 event            | Writes delta?                               |
| -------------------------- | ------------------------------------------- |
| `prism_wrap`               | Yes — `delta_kind='wrap'` via `_do_hygiene` |
| `prism_checkpoint`         | Yes — analogous via `_do_hygiene`           |
| `hd_exec` (after SPEC-040) | Yes — `delta_kind='pickup'`                 |
| `prism_start`              | **No** ← 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:

```json theme={null}
{
  "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.