Nine Doors, One Store

01The verdict in one paragraph

Every individual mechanism in this fleet is well-reasoned and carries a scar comment naming the incident that produced it. What is missing is not care. It is that no lesson propagates across doors. start-operator learned to arm its own watcher; the Supervisor — the only component that runs continuously — never did. operator-here learned that the allowlist erases fields and wrote a sidecar; start-operator wrote a comment claiming it had been fixed instead. That comment is false, and it was itself written to warn that an earlier comment lied about the identical field. The correction did not survive. Only the confidence did.

The recurring defect is not any one of these bugs. It is the class: one question, two stores that can disagree about the answer. Identity has two answers. Revival has two authorities. Done-ness has nine derivations. Terminal states are declared in five places and superseded is in none of them.

02The shape of the problem

Nine ways a session comes into existence. One shared store on disk. Two independent authorities that revive from it, with no field anywhere saying which one owns a given task.

03The door matrix

measured Nine doors, six questions each. The gaps are the finding.

Three gaps

(a) Two of nine doors arm a watcher, and they arm different, mutually unaware watchers. start-operator arms nudge --idle 600. operator-here arms a Temporal OperatorTaskWorkflow. grep -c temporal ~/.local/bin/nudge → 1, and it is a comment.

(b) The Supervisor can remove watchers and has no code path that adds one. In supervisor/src/spawn.ts, the occurrence counts for nudge, temporal, acceptance.json, operator-here and OperatorTaskWorkflow are all zero. Meanwhile releases.ts:55 runs nudge --stop --sid. It is a one-way ratchet: every respawn silently strips the Operator's alarm clock, and revival is the path that actually runs — 391 attempts today alone.

If the system gates on the agent doing something, the PROMPT must say it… So the launcher arms it. start-operator, ~line 669 — a lesson learned at one door and never carried to the door that fires 391 times a day

(c) Acceptance is validated at exactly one door and re-checked at none. 32 of 53 active tasks have no acceptance.json at all — no finish condition, so they can never mechanically complete.

04Two revival authorities — live, and already firing

verified The question was: what prevents double-revival today — timing, convention, or nothing? The answer is nothing, and the overlap is 100%, not partial. All six running OperatorTaskWorkflow subjects have a task.json, and all six are non-terminal by the Supervisor's own predicate.

Why nothing separates them

• Timing doesn't — it synchronizes them. 60s vs 60–120s, both requiring two confirmations. Both cross the threshold within 2–4 minutes of the same death.
• The budgets are invisible to each other. grep -rn "operatorRespawns" agent-smith/src/ → zero hits, whole tree. Each side independently permits five. One task can burn ten revivals and neither cap will ever fire.
• No partition field exists. Union of every key across the six live files: acceptance, createdAt, criterion, lastSupervisedAt, name, note, operatorFirst, operatorRespawns, operatorSid, repo, requestedBy, startedFrom, state, task, workerSid. No owner, no engine, no watchedBy.
• The successors are incompatible. A double-revival yields two live sessions answering to one name, working from different context.

And there are five authorities, not two

co.propflow.watcher-doctor (re-arms nudge lanes every 180s), co.propflow.operator-heartbeat (120s) and co.propflow.decision-block-sweep (600s) each independently restore state. The watcher-doctor's own plist comment concedes the underlying deploy problem:

The AgentFlow Supervisor is the obvious host… It runs from supervisor/dist/index.js, a BUILD ARTIFACT, on a checkout that is presently an unmerged live-deploy branch — so a change there is code that cannot run until somebody builds it, which is not a fix, it is a plan. co.propflow.watcher-doctor.plist

05The allowlist is not a filter — it is a destructor

readTasks (supervisor/src/tasks.ts) rebuilds a fresh object from 15 named fields. writeTask then does JSON.stringify(t). Every Supervisor sweep therefore permanently erases every unnamed field from disk. Measured across 176 live task files:

The end-to-end receipt. ci-green-main was minted carrying startedFrom: "tmux" and a full Slack origin block, captured verbatim in the minting session's transcript. On disk today both are gone, while every allowlisted field survived and grew (operatorRespawns 0→2, lastSupervisedAt and releasedAt added).

Two independent audits computed the dropped-field inventory separately and arrived at the same nine fields with identical counts. The system has now invented two separate sidecar files — acceptance.json and the heartbeat — whose entire reason for existing is that a field cannot survive the Supervisor. awaiting-human exists as a state rather than a field for the same reason.

06Nine done-ness rules across twenty-one code sites

Three surfaces once gave three answers about one task: the table said ✅ done, the container said deploy verdict=-, the watchdog said "needs a human." That was not a bug. It is the designed state of a system with nine independent derivations of the same fact.

The two worth acting on

E9 — session-scope self-report (completion.ts:254-271). A directory matching /^[0-9a-f]{8}$/ whose events.jsonl contains any row with kind === 'closed' counts as complete. No state corroboration is possible — a sid8 dir has no task.json. A bare {"kind":"closed"} line yields a valid report that every consumer renders as a completion, with no validation of the actor.

Two aggravating facts: preferReport (:219-228) picks newest at regardless of scope, and 8 of 123 task-scope reports carry at: null — so any dated self-report outranks them. And the relay manufactures the write target: digester.ts:456 mkdirs tasks/<sid8>/ for every live roster row every 45 seconds. That is the actual cause of the directory sprawl.

The acceptance grammar the evaluator implements is not the one operators write. parse_check accepts exactly four forms — pr:…merged, run:…green, file:…exists, exit:name N. Anything else returns None = open forever. Fleet-wide: 67 acceptance items, 55 evaluable, 12 unevaluable. Ten of the twelve use the prefix cmd:, which does not exist. All twelve are on one task, sess-propflow-9f, where 12 of 12 are unevaluable — that workflow could never have reached DONE by any amount of correct work, and it has logged 34,134 lines saying so.

07Absence reads as success — the full inventory

intake.ts:358 is the sharpest of these because its own sibling check two branches earlier is deliberately three-valued and returns retryable: true. The ledger check has no such branch. An I/O failure reads as permission.

The atomicity is applied in inverse proportion to who reads the file

verified writeTask does tmp + fsync + rename + directory fsync, with a docblock explaining that "a torn read would give the Operator a criterion that is half a sentence, and it would act on it." Meanwhile:

digest/digester.ts:444   fs.writeFileSync(target, renderTaskStateMd(...), 'utf8')
digest/digester.ts:458   fs.writeFileSync(path.join(dir,'STATE.md'), ..., 'utf8')
                         intervalMs = 45_000  ·  ~297 writes per sweep

Bare writeFileSync — no temp file, no rename, no fsync — on the file that start-operator:359, 699, 701 and spawn-pair:188 tell every Operator to read instead of the transcript, at every wake. STATE.md copies that same criterion in verbatim and never got the treatment. Elsewhere, audit.ts:175 stages-and-renames for an audit request under no contention at all.

08What is actually deployed

Neither production component runs main. The worker runs a checked-out feature branch's working tree — no build, no artifact, no pin. There is no Temporal Worker Versioning: Worker(...) sets only task_queue=. A git checkout in that directory is a production deploy that hits every in-flight days-long workflow at its next workflow task, with workflow.patched() as the only guard.

Running but not on main: repoPathProblem cwd validation, the bootSessionWithKickoff refusal, the task-repo-unusable alarm. On main but not running: PR #67's multi-question blocks and AND-gate. Merging main would be a regression — main still has the log-only MALFORMED task.json line measured to have logged 2,947 times over eleven days with zero escalations.

Nobody can currently answer "what is running?" from a git ref. That is why "we fixed it" and "it is fixed on the mini" are independent claims.

09Outdated, and still interfering

1. watchOnly — the doctrine was abolished 2026-08-19 ("THERE IS ONLY ONE KIND OF OPERATOR"), and start-operator:620, edited six days later, still writes it. Read by nothing (isWatchOnly: 0 hits). Its comment actively lies to the next reader.
2. pf-arm-operator.sh — operator-here:41 states the /operator shape deleted it, the pending marker, the /api/adopt intake, the Supervisor's operator-spawn, and idle mode. It deleted none of them. aliases.sh:185 and :654 still invoke it, and its output is the 14 repo-less tasks now failing respawn.
3. spawn-pair — writes the two-peer-session shape start-operator's own header calls abandoned, arms no watcher, has a fixed sleep 25, no acceptance gate, and the sid8 defect. Still blessed at operator-SKILL:587.
4. register-work — vestigial as a tool (one call site, last successful run 2026-08-19, its only caller under a fleet-wide killswitch) but its marker is load-bearing: derive-registry is the sole disk signal that produces the "architect" role. Decouple before deleting.
5. worker-SKILL.md — describes a peer session with its own sid, pane and /rename. The default Worker is now a subagent with none of those. Every kickoff pointing there hands a subagent instructions it cannot execute. Same for the peer-worker machinery in operator-SKILL (msg <worker-sid>, capture-pane, self-compact <worker-sid>).
6. 6 of 26 workflow types have zero executions in 30 days. Two have no schedule and no in-code starter at all. They are inert code the worker still loads and every redeploy must keep deterministic.

The decision-block treadmill

40 of 55 running workflows (73%) are SmithDecisionBlockWorkflow. They are not long-lived watchers; they are a relay race. Armed with a 24-hour lifetime, they exit after ~30 minutes, and decision-block-sweep re-arms them ten minutes later. smith-decision-b86386853 has been re-created 296 times in seven days — for a block that already carries an answer, and three of whose four ledger copies say adopted. Three such blocks account for 69% of all decision-block volume.

The sweep's own comment predicted this exact failure — for a different row class. The prediction was right; the case it was written for was the wrong one.

b86386853   3 copies adopted  ·  1 copy open
b86388306   3 copies adopted  ·  1 copy open
b86228042   3 copies adopted  ·  1 copy resolved

10What not to change

Half of a reassessment is naming what is already right, so the next pass does not spend itself re-litigating it.

• Subject-derived workflow ids + USE_EXISTING. op-task-<slug>, smith-decision-<block>, smith-pr-drive-<pr>. Any door, any machine, any day — a duplicate arm is a free no-op. This is the single best decision in the architecture, and the argument for it is inverted: the one place this fleet built its own locking instead — the block ledger — is exactly where 25% of records now contradict each other.
• The dataclasses.replace(req, …) pattern for continue_as_new. All four hopping workflows use it and all four carry their deadline correctly. The worst variant — a resetting deadline making a workflow immortal — does not exist here. Make it the written rule: state that must survive a hop is a request field, never self.*, and the bug class closes by construction.
• OperatorTaskWorkflow's exit table. 2-day idle, 24-hour blocked grace, 10-nudge ceiling, 5-respawn cap, 7-day hard lifetime, 15-task concurrency cap, every terminal named. Best-bounded thing in the fleet. The problem is the second authority beside it, not it.
• The patch-gate discipline. Zero unguarded determinism-affecting changes in 30 commits. #275's two-disjunct gate — patched() plus a hardcoded start-time cutoff for runs minted during the ungated window — is a sophisticated fix to a genuinely hard problem. Do not simplify it.
• The op- / operator- two-name split. Looks like duplication; is not. op- is the Supervisor's kill/revive namespace, operator- is the human-facing roster row. Collapsing them was tried on 2026-08-07 and made an Operator invisible to the thing reviving it.
• The Supervisor's zero-token, file-and-tmux-only design. The one layer that cannot rot. Every fix below stays inside that constraint.
• Fail-toward-open in the check evaluator, and isStalled() returning false on unknown staleness. Unknown is not evidence. Fix the grammar and the log rate; keep the posture — but pair the latter with a visible transcript moved: unknown banner in STATE.md, because an Operator told to "read STATE.md and judge" currently sees a page with no warning on it.
• loop-keeplist returning "undetermined". It changed from return "worker" on 2026-08-21 and that was right. An honest "I don't know" is the correct output for a system where role genuinely is not durable state. Fix the architecture; do not fix the symptom by guessing again.

11The staged plan

Ordered by harm removed ÷ blast radius. Stages 1–2 are reversible and touch no structure; 3–4 are code with a deploy; 5–6 need a decision first.

Stage 1 · today, reversible

Stage 2 · merge what is already written

Stage 3 · make the erasure stop

Stage 4 · close the watcher gap

Stage 5 · the decision, not a patch

Stage 6 · make deploys reproducible

12Open decisions

These are yours, not mine. The answer store is currently unreachable — ~/.config/cloudflare/token is empty on the MacBook, and the fallback read through the mini has been sitting on a single wrangler kv key get for over ten minutes under load 4–7 — so they are listed here rather than filed as blocks.

13Method, and the corrections

Three independent audits ran against the live fleet, not against recollection. Every figure in this document is a measurement taken 2026-08-26. Four claims were wrong and are recorded here rather than quietly dropped, because a document about comments that lied should not become one.

The pattern is worth naming, because it is the same one the document is about: "I grepped and found nothing" is not "it does not exist." Three of the four errors above are that exact substitution. The rule that governs the store governs the audit.