The Deploy section claimed a Spark Control tile was "captured in the inbox"
pending build. It isn't: spark-control has shipped this bot's tile since
v0.28.0, verified live against the running dashboard. Deploy is one click.
Record in Layout that the poll loop walks all mapped repos serially in one
async task. That's why rooms can't interleave, and why a long review
head-of-line-blocks the next room's poll at 3+ repos.
Current state: prune the finished merge-redact narrative to a line, keep
the stale-prune orphan as the concrete next step, and record the 2026-07-18
adjudication that cut ROADMAP to one phase.
Phase 2 (both lines) — done. The headless review spawns the enabled
subagents and prints each verdict under its own heading (src/bot.py),
proven end-to-end on ten31-site PR #4; the `agents +/-` handler updates
and atomically persists each room's enabled set. Finished milestone, and
the record already lives in AGENTS.md Decisions + Current state.
Phase 4 (Spark Control tile) — already built elsewhere. spark-control's
Bots tab has had a first-class gitea-review-bot entry since v0.28.0, same
code path as matrix-bridge; the running dashboard reports it live. The
work was never this repo's. Left a one-line pointer under Deferred.
Phase 3, deploy-on-a-non-static-repo — dropped. No repo needs it (only
the static ten31-site is onboarded), and it isn't doable as written: the
deploy step is hardcoded to the static-site publish script and the only
per-repo knob is on/off, not a per-repo deploy command. Exercising it
means a real deploy plus a force-merge against a live service. Revisit
when a concrete non-static repo needs it — that repo is the honest test
target, and the deploy-command field comes first.
Phase 3, three-repo onboarding — kept, annotated with its check plan and
a correction: reviews run serially, so the stated "no interleaving" exit
is trivially satisfied. What matters at 3+ repos is a long review
head-of-line-blocking the next room's poll.
New: heartbeat for wedge detection. Scoped to the gap the tile leaves —
it reads container state, so it catches a crash but not a stuck sync/poll
loop, which looks identical to healthy from outside.
A merge whose post-merge deploy failed left the review thread orphaned (redaction was gated on deploy success). Now the thread always redacts on merge success and the deploy-failure warning is posted at top level so it survives. New clear/resolve command redacts an orphaned thread without touching the PR.
Keysat