Kanban vault projection — decided: state 1 (no vault projection), generator stopped

Trigger. Echo flagged a live regression (his addendum 3, a9aa356): Sol removed the projection file Docs/Kanban/SOLOS-V3.md at 21:49 (5b48edc, per Young), but the generator was never retargeted and its cron was still active — next fire 22:13:11, which would resurrect a file Young ordered deleted. Verified live, then fixed.

What was wrong (measured, not inferred)

The defect class is the same one that has caused every restore incident: a control at the wrong choke point. The deletion lived at the call site (git rm); the generator lived in cron with a hardcoded target. Neither knew about the other, so deletion and generation contradicted each other indefinitely.

Why Echo's option 2 (retarget OUT to fleet-board.md) is rejected

Echo's read was: "retarget the cron to fleet-board.md, since ruling 2 already says 'DB canonical, .md generated' and her reporting system references it." This would have destroyed data.

First, a correction to my own initial reasoning (measured, not assumed): I first read fleet-board.md as "not in the plugin's format". That was wrong. It does carry kanban-plugin: board frontmatter and a valid %% kanban:settings fence ({"kanban-plugin":"board","list-collapse":[null,null]}), so it passes the plugin's format and the generator's own verify_parseable(). The file is plugin-parseable.

The rejection therefore rests on a stronger, measured ground — content loss, not format:

1. The generator sees only the 13 LIVE kernel tasks (ready=3, running=6, blocked=3, done=1 — archived rows are not returned by list --json), while fleet-board.md carries 32 curated cards. A retarget would replace those 32 cards with 13.
2. Whole sections would vanish. The generator emits only its seven fixed lanes (Ready/Doing/Todo/Blocked/Triage/Review/Done) plus ## Unmapped. It has no concept of the file's custom sections — ## Docker image build (Young's approval 2026-10-20) (10 cards: the four ARM64 image builds, onboard_tenant.sh proof, Nova's brief, Tam's tenant configs, Mira's prod costing) and ## Fleet board — temporary task register would be deleted outright. Ten of those cards are not in the kernel at all.
3. It would collide with live concurrent edits. fleet-board.md is actively being edited by other agents — Tam committed a card change (c93a25a) at 21:57, three minutes before this fix. A generator overwriting that file every 30 minutes would destroy work that lands between runs, and the git history would show the loss as a silent overwrite rather than a reviewed change.

So the target was never a projection target — it is a register, and the difference is the whole point. fleet-board.md is already recorded as superseded — Tam's own migration doc item 2 ("fleet-board.md … is superseded by the same mechanism — it stays only as today's migration record until Min retires it"). A register that other agents still write to by hand cannot be a generated artifact. If both are wanted, they need different files — that is a decision for Min, and it is the open one this document leaves behind (§Open question).

The decision: state 1 — no vault projection

Of the three states Echo named, only two are coherent, and we are now in one of them:

1. ✅ No vault projection at all. Task truth is hermes kanban (board solos-v3); the vault holds no board artifact that claims to be generated. This is the state we chose and implemented.
2. ⚠️ A generated projection — coherent, but requires re-creating the target file deliberately, not retargeting OUT at fleet-board.md.
3. ❌ The incoherent state we were in: projection deleted + generator active + hand-written board nothing regenerates.

Why state 1 rather than state 2: Young's instruction is unambiguous — "hermes kanban kernel is task truth". The one surviving vault artifact (fleet-board.md) is a hand-written register, not a projection — it is neither truth nor generated, and it is still being hand-edited by other agents, so a generator must never own it. A projection can be re-enabled later as a deliberate act, in its own file; it must not be resurrected by accident, and it must not be confused with the register.

What was changed (all verified live)

The fail-closed guard is the point. The cron pause is one field; if a future agent resumes the job, the script itself now refuses to resurrect the file. That is the control at the choke point, not at the call site.

Re-enabling a projection (if ever wanted)

Do not retarget OUT at fleet-board.md. To project deliberately:

1. Re-create the target file as a real projection (e.g. Docs/Kanban/SOLOS-V3.md), or accept that the projection is retired.
2. Resume kanban-obsidian-sync only then.
3. Record the decision in this file.

Honest limits

• I fixed the generator and the cron — both mine. The three open cards that remain (t_7018df81 blocked 215 h; the two skipped_nonspawnable Pulse-assignee issues) are Min's lane and are already on the board.
• kanban.dispatch_profiles still reads any (no per-home claim allowlist) — Echo's finding, Min's lane. Reported, not fixed here.
• I did not touch fleet-board.md; it is Min's to retire.