The four lifecycle operations are defined by what each does to the record: deploy replaces it, upgrade updates it, decommission removes it, reconcile restores it #913

Epic: #451 · Feature: #762 The writ lifecycle surface: reconcile, scopes, and the vocabulary settlement

The ruling, 2026-09-22

The four lifecycle operations are defined by what each does to the record -- the deployment's record of what is
deployed, the receipts writ leaves:

The owner: "deploy should replace the record, upgrade should update the record, and decommission should remove
the record. Reconcile should restore the record." And: "this should not be something you have to save to memory.
The code base and its supporting documentation should exude this."

Why now

Found on danoble-ud24-1.local 2026-09-22 running lane 18's sequence: after the personal checkout's layer
reorganization, writ reconcile reports 52 records as orphan (target present, source gone) and, once the
targets are removed, as missing. Both words treat the record as the desired state when the checkout is. Nothing
retires them: the inventory pre-flight and reconcile read is readback.Fold, a fold over every receipt the
machine has ever written, newest per target winning, so a file that left the checkout stays in the record forever.
Under the ruling the next deploy is the record and those rows are gone with it; reconcile never retires
anything -- there is nothing of theirs to restore.

Refined the same day: each deploy is one lifetime. Its receipts stack and fold naturally -- the deploy, then the
upgrades and reconciliations that follow -- and the record is that stack, watched ebb and flow until a later deploy
replaces it or a decommission removes it. The fold is not wrong; it is unbounded: it folds every lifetime the machine
has ever had into one record. A machine sees many lifetimes, and one will eventually want to prune them: housekeeping on the store,
not a fifth verb, named so the pages leave room for it.

The design does not say this. 10-command-line-interface.md ("The lifecycle is named once") and
5.1-reconciliation.md ("Relationship to the Writ Lifecycle") each carry a four-row table stated from the
mechanism's side -- "persist the trace", "fold the run index", "constrained re-deploy", "reverse traversal" -- and
neither names the record as the thing every verb acts on. #762's work list has "reconcile reports and repairs" as
one row of this table and nothing for the other three.

The change

1. docs/architecture/5.1-reconciliation.md: the table above opens "Relationship to the Writ Lifecycle", each row
   then stating the mechanism as today; a paragraph says what the fold does today and that a deploy replacing the
   record is chartered under The writ lifecycle surface: reconcile, scopes, and the vocabulary settlement #762.
2. docs/architecture/10-command-line-interface.md: "The lifecycle is named once" carries the same table beside
   the per-program one, so the command reference states the verbs' meaning before their mechanics.
3. 5.1-reconciliation.status.md and 10-command-line-interface.status.md (if present): the revision noted.
4. The writ lifecycle surface: reconcile, scopes, and the vocabulary settlement #762's work list gains the three implied rows -- deploy replaces the record (a lifetime begins; the fold is bounded to it), upgrade updates it,
   decommission removes it -- beside "reconcile reports and repairs", so the code lanes are named by the table.

Documentation only; no code.

Acceptance

• the table appears in both documents, the record named as the subject of every verb: 10-command-line-interface.md §3.1, 5.1-reconciliation.md (2026-09-22)
• 5.1 says what readback.Fold does today and why it is not the ruling ("What the fold does today")
• The writ lifecycle surface: reconcile, scopes, and the vocabulary settlement #762's work list carries the rows (four, reconcile's classification included); its plan gains Requirement 10
• the status files note the revision (2026-09-22)

Plan and design documents