# Live status registry — the forgotten DB slice, and the WIP cap

outcome: work status lives as rows the machinery writes instantly — claimed, progressing, landed, deployed, with receipts — so the board is the truth of what is happening, not just of what was asked.
status: ACTIVE — factory run launched 2026-08-15 against this plan; design spec: docs/specs/2026-08-15-live-status-registry-design.md (queue stays file-based, state mirrored to DB — owner decision 2026-08-15)
source request: owner 2026-08-15 — "I dont see the DB part here, and it seems like nobody is planning to make it. and nobody is working towards the final direction. i want you to find the original plan where you present the slices to me and one of them was the DB slice. it seems to be forgotten." Recovered from the transcript: the four-part recommendation of 2026-08-14 06:14 (preserved at the session scratchpad, `db-slice-msg.txt`).

## The original recommendation, and what happened to each part

From the 06:14 message, verbatim anchors:

1. **"Move plan *status* into the live system you already built; keep plan *specs* in git.
   ... Statuses, receipts, 'who's working on this,' 'what happened last' become rows the
   agent writes instantly — zero landings, visible in every terminal and to you at any
   moment."** → PARTIALLY built, and the living half was dropped. Intake writes a row at
   ask time (landed). Nothing writes the row's LIFE: no claim, no progress, no landed, no
   deployed, no receipt. Rows are born and go silent — the same decay the markdown index
   has, one layer down. THIS PLAN.
2. **Session-start overlap check** ("is there active or recent work overlapping this?")
   → dedup-at-intake landed; conversation surfacing is in the running intake lane's brief.
3. **"Cap concurrent sessions; one intake queue... a small number of active lanes (3-5)
   pulling from one queue; everything else waits *visibly* with its position and reason."**
   The Little's Law point: ~45 completions/day ÷ 50 open sessions = every ask averages
   over a day regardless of machine speed. → proposed by the agent, REFUSED by the owner
   shortly after; refusal recorded here 2026-08-15 (see L4).
4. **Deploy as an async consumer of main** → registered and in flight
   (`2026-08-15-auto-deploy-on-main.md`).

Relationship to derived status (`2026-08-15-plan-status-self-reconciling.md`): the two are
complementary, not competing. WRITTEN rows are the fast path (instant, carries intent and
receipts); DERIVED status is the audit that catches rows whose writer died mid-life — the
crash-orphan case that made both the plan index and the session ledger decay. The board
shows the written state; the deriver corrects it. Neither alone survived contact with
reality this week.

## Slices

Each lands and deploys before the next; each ends in something the owner can see on
`/requests`.

**L1 — the store learns lifecycle.** Requests gain state transitions written through one
API: `claimed` (worker, host, at), `progress` (one-line receipt, at), `landed` (sha),
`deployed` (sha), `failed` (reason). Every transition appends to a receipt trail on the
row — "what happened last" is a column, not a memory. Evidence: a hand-driven ticket
walked through its whole life via `od-requests`, each step visible on the board's card.

**L2 — the machinery writes it, not the agents' goodwill.** The instruments that already
know the truth write the rows: the lander's post-land path stamps `landed` (it knows the
sha); the deploy watcher stamps `deployed`; the worker-association claim (intake lane S4)
stamps `claimed`. Agents may add `progress` receipts; they cannot be relied on to — the
machinery writes are the guarantee. Fail-open everywhere: a collector outage never blocks
a land or deploy. Evidence: land one real change and watch its ticket move to landed and
then deployed with no agent writing anything.

**L3 — silence becomes visible.** A claimed ticket whose worker is gone (pid-verified,
same evidence rules as the session ledger fix) shows "worker lost" on the card face
instead of a stale "in progress". This is the board catching what happened to this
session's own lanes twice today. Evidence: kill a claiming process; the card says so
within a sweep.

**L4 — WIP cap: REJECTED by owner (2026-08-15). NEVER build, NEVER re-propose.**
The cap was this agent's proposal in the 06:14 recommendation, and the owner refused it
shortly after; the refusal was never recorded, which is how it re-surfaced here as
PROPOSED — this line is the durable record. The owner's workflow IS many parallel
sessions; throughput comes from removing the queues' wait states (landing daemon,
auto-deploy, admission fixes — all delivered or in flight), not from capping his
parallelism. Any future agent reading Little's Law at this machine: the bottlenecks were
wedged locks and starved cgroups, not session count — measured and fixed 2026-08-15.

## Constraints

- The project owns specs in git; the store owns state. Never move plan DOCUMENTS into
  the DB (owner ruling, recorded in `2026-08-14-requests-board-astryx.md`).
- Machinery writes are fail-open: no land, deploy, or dispatch ever blocks on the
  collector being up.
- Seams: L1 lives in `collector/src/requests/**` (intake lane's files — coordinate,
  it is mid-slice on S4/A5); L2's write CALLS live in the lander
  (`finish-branch.sh` post-land) and the deploy watcher — both files owned by other
  active lanes today; L2 must not start until those lanes report done.
- Terminal state after L1-L3 + derived status: the index status column retires
  (registered in `2026-08-15-plan-status-self-reconciling.md`).