Add PR comment intake and the review loop (B2) — step 6b #17

Merged

dev-agent merged 5 commits from review-loop into main 2026-09-07 22:55:12 +00:00

Conversation 2 Commits 5 Files Changed 13

+1036 -9

5 Commits

Author	SHA1	Message	Date
dongarandClaude Opus 5	886cb80583	Count only mutating tools as evidence of work ... The previous fix challenged a completion claim made before any tool call, but treated every tool as work — so a model that ran one list_dir and then declared the milestone done was believed, and CI caught the same empty milestone again. Reading a file or listing a directory is the model orienting itself. Only write_file and run_command now count, so a completion claim must be backed by something that changed or verified the tree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 22:53:20 +00:00
dongar	8f365263c4	Merge pull request 'Externalise plans to Gitea and accept approvals there (A4, Part H)' (#18) from gitea-approvals into review-loop ... Reviewed-on: dongar/nisse#18 Reviewed-by: Don Garrett <dgarrett@acm.org>	2026-09-07 22:47:40 +00:00
dongarandClaude Opus 5	acee8b96f0	Do not believe a completion claim before any work was done ... CI caught the executor recording an empty milestone as a success: the model answered with prose on its first turn, and the loop reads "no tool call" as "the plan is done". It had therefore finished a milestone having touched nothing, and the milestone would have gone on to publish with no changes. A completion claim is now challenged once when no tool has been called yet — the same shape as the planner's nudge — and a model that persists escalates instead of reporting success. After the first tool call the claim is taken at face value, as before. The live milestone test failed roughly one run in five on this; four consecutive runs pass now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 22:19:15 +00:00
dongarandClaude Opus 5	d508e9a9b7	Externalise plans to Gitea and accept approvals there (A4, Part H) ... - approvals.py: PlanBoard opens one issue per project and posts each plan revision as a comment carrying its rev tag. The state store keeps only a pointer, so gate state can be re-derived from Gitea after a state-volume loss — external truth wins - Gitea comments are a second approval source: revision binding, the typed word approve, and first-approval-wins work exactly as over transport, with a per-channel allowlist because a Gitea login is not a Matrix MXID - Outcomes are echoed to the other channel, so the two records cannot silently disagree about what was approved - A Gitea outage degrades durability of the record, not the ability to approve: planning proceeds and Matrix remains a complete channel - Live test now asserts the server refuses the agent's own merge and its push to the protected branch. That property was previously true only because our code did not attempt it; branch protection makes it structural, and this test fails if the protection is ever relaxed - Fixed a race in the process-group test: killing a group is asynchronous and the grandchild is an orphan, so its exit is not synchronised with our return; the test now waits for death Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 22:15:08 +00:00
dongarandClaude Opus 5	affdb9e8aa	Add PR comment intake and the review loop (B2) — step 6b ... - poller.py: CommentPoller polls PR comments rather than taking webhooks, keeping the VM outbound-only (B3). On an outage it backs off exponentially, caps, and retries indefinitely while logging: polling is pure intake, so an outage delays a reaction but never fails a task or forces a transition - prime() marks the existing thread as seen without delivering it, so starting a watch does not re-address feedback already handled - Review loop: a comment in PR_OPEN enters the canonical transcript, the executor responds, and the fix is pushed to the same branch with a reply on the PR. No intent is recorded for a follow-up push — the PR already exists, so a repeated push is harmless, unlike opening a second PR - Comment authors are checked against a separate Gitea operator allowlist: a PR comment is an instruction channel into an agent that writes code, so it is operator-scoped, and a Gitea login is not a Matrix MXID (A4 per-channel allowlists) - Orchestrator now holds a lock: transport and the poller deliver on separate threads, and state transitions must not interleave - Backoff timings are injectable, so the outage path is tested in milliseconds instead of being untestable Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 21:59:50 +00:00