Keysat
9adcdc8c0d
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.
2.1 KiB
2.1 KiB
gitea-review-bot — ROADMAP
Phases beyond the first milestone (threaded single-flow review + merge/reject/deploy; see AGENTS.md
## Current state).
Phase 3 — Multi-repo at scale
- Onboard ≥3 repos to their own rooms; confirm independent polling, no cross-talk. Exit: three
repos reviewed from three rooms in one run. (adjudicated 2026-07-18: verify — needs no new code;
rooms are already independent (per-room heads/threads/agents are namespaced, merge-confirm state is
keyed by room+PR). Check plan, when a real 2nd/3rd repo is onboarded: watch one poll cycle in
docker compose logs -f. Note the exit criterion is mis-stated — reviews run serially (one async task walks the rooms in turn), so "no interleaving" is trivially satisfied; the thing actually worth watching at 3+ repos is a long review head-of-line-blocking the next room's poll, i.e. the latency problem the deferred poll→webhook item anticipates.) - Emit a heartbeat the poll loop touches, so a wedged bot (container up, sync/poll loop silently stuck) is distinguishable from a healthy one — today it looks identical from outside. Crash detection is already covered by spark-control's tile, which reads the container's docker state; this is only the gap that leaves. Lightest correct form is a heartbeat file a Docker healthcheck or any monitor can read, not an HTTP status server (this repo has no HTTP surface; don't add one for a badge).
Deferred / non-goals
- Not a Claude-session bot (that's matrix-bridge); not Maubot (revisit at ~6+ bots or web-UI mgmt); no GitHub/non-Gitea; no Gitea account/permission management; E2EE deferred (private LAN transport).
- A shared "bot kit" library (extract the common matrix-nio + SSH plumbing across the three bots) once duplication bites — the lighter step before ever considering Maubot.
- Poll → webhook upgrade if 60s latency ever matters.
- Ops/dashboard tile lives in spark-control, not here — its Bots tab has shipped a gitea-review-bot tile since v0.28.0 (status badge, Update, Start/Restart/Stop, View logs), confirmed live.