lifecycle¶
Provenance¶
- Source:
.spec/spexcode/spec-cli/sessions/lifecycle/spec.md - Source SHA-256:
b7b1d73fb224690ccdab32495a6a54c7458bd6d8f40a980e5fbf40084e978c3b
lifecycle¶
raw source¶
The durable thing is the worktree, not the tmux process: a session survives a kill, a reboot, or a moved folder. So a session's life is three concerns over that one anchor — how it comes up, what state it declares while running, and where its private runtime bookkeeping is kept so the worktree root stays clean and the scratch dies with it. The agent authors its own state; nothing about its life is inferred behind its back.
expanded spec¶
The three concerns each own their detail:
- [[launch]] — bringing a worker up: the
reclaudewrapper, the per-session rendezvous socket, the non-truncating launch-prompt delivery, the materialized-contract auto-discovery (no--append-system-prompt, no hiddenCLAUDE.md), and the concurrency cap with its durable launch queue. - [[state]] — the lifecycle state machine: the declared statuses, the per-session
Stop/PreToolUse/Notificationhooks that gate them, AskUserQuestion →asking, and adapter-derived liveness. Lifecycle is agent-authored except for a proven hard runtime outcome: a headless turn's non-zero exit may compare-and-set an otherwise undeclaredactiverecord toerror, never overwrite a declaration. - [[runtime]] — the per-session GLOBAL store under
~/.spexcode(keyed bysession_id, grouped per project), NOT the worktree: every harness-written artifact (state record, originating + queued prompts, launch script, recorded comms, spec sentinels) lives there, so the worktree holds zero per-session SpexCode files and stays mergeable-clean.
The shared guarantee: state is read from the global store every time (no in-memory map), so a session's life is reconstructed from disk after any backend restart — the durable worktree, its global state record, and its socket liveness are the whole truth.