grant/gitea-review-bot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Record the push watch as live and verified end to end

Browse Source
This commit is contained in:
Keysat
2026-08-21 10:51:17 -05:00
parent e5a187b507
commit 1a39b1679c
1 changed files with 17 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+17 -11
View File
@@ -198,13 +198,20 @@ revisit this — local inference via Spark Control would be the path.
up since 08-13 with zero restarts, and the poll loop is genuinely alive (two Gitea connections exactly
60s apart — see the liveness recipe in Commands).
**2026-08-21 — the collaborator push watch shipped.** `master` now carries code the Spark hasn't got
yet, so **a redeploy is pending** (and the Spark's `config.toml` needs the new `[gitea] my_emails` +
`[repo.ten31-brand]` keys, which are gitignored and live only there). Two independent reviewer passes
ran over it; the first found the batch being recorded only *after* its assessment (a crash would have
replayed the whole notice) and an all-clear line printable from a missing file list, the second found
untrusted PR/commit metadata sitting above the prompt's fence. All fixed, each with a mutation that
reproduces it.
**2026-08-21 — the collaborator push watch shipped and is LIVE on the Spark** (`e5a187b`, no redeploy
pending). Verified end to end in the real room, not just in tests:
- a real notice + assessment for jonathan's `75cc63d` (VERDICT: OK, panel off), and
- the owner's own `4230f30`/`d307bdd`, pushed while the watch was already running, recorded silently
with no notice — the identity filter proven on live traffic rather than a fixture, and
- the record-before-assess ordering proven at runtime: the commit was already in `state/rooms.json`
while the assessment's `ssh mac-bridge` process was still alive.
Two independent reviewer passes ran over it. The first found the batch being recorded only *after*
its assessment (a crash would have replayed the whole notice) and an all-clear line printable from a
missing file list; the second found untrusted PR/commit metadata sitting above the prompt's fence.
All fixed, each with a mutation that reproduces it. The Spark's `config.toml` carries the new
`[gitea] my_emails` + `[repo.ten31-brand]` keys (gitignored, so they live only there); the pre-change
copies are at `~/gitea-review-bot/config.toml.bak-20260821` and `~/rooms.json.bak-20260821`.
- **ten31-site** — proven end-to-end on PR #4 (2026-06-28: review → `merge` + `yes` → force_merge →
auto-publish → redacted). **PR #5 "Update index.html" is still open**, reviewed 2026-06-30, its thread
@@ -222,11 +229,10 @@ reproduces it.
hypothetical.
**Next steps, in priority order:**
1. **Deploy the push watch and watch one real notice land** (see the pending redeploy above).
2. **Fix the orphaned-thread prune** (`src/bot.py` ~L594): the poll loop drops a PR's thread root from
1. **Fix the orphaned-thread prune** (`src/bot.py` ~L594): the poll loop drops a PR's thread root from
state when the PR leaves the open list *without redacting*, so a PR merged or closed in the Gitea web
UI strands its thread and `clear` can no longer reach it. More likely to bite now with two rooms.
3. **`/triage` the 3 untriaged inbox items** tagged for this repo — adjudication never reads the inbox, so
2. **`/triage` the 3 untriaged inbox items** tagged for this repo — adjudication never reads the inbox, so
their content is still unknown here.
4. With a 2nd repo mapped, ROADMAP Phase 3's verify is unblocked: next time both rooms have open PRs at
3. With a 2nd repo mapped, ROADMAP Phase 3's verify is unblocked: next time both rooms have open PRs at
once, watch a cycle (`docker compose logs -f`) for a long review head-of-line-blocking the other room.