4 Commits

Include renames

Author	SHA1	Message	Date
dongarandClaude Opus 5.5	d68e3b3a83	Add the abandon command ... A4 already names abandon as one of the ways out of a halt (continue, re-plan, or abandon) and 0.2 closes a work item as completed or abandoned, but no command did it: from a gate or a question the only way to drop a task was to edit the state database. - 'abandon' ends the task from any waiting state and returns to IDLE. The move is made durable first; then the plan issue and any open milestone PR are closed with a note (branches kept), and any unresolved intent is aborted so boot reconciliation does not gate on work dropped on purpose. A Gitea failure is reported, not fatal. - Like 'status' it is a command in every state, never read as an answer or feedback. While work runs, 'stop' comes first, as before. - The restart / stranded question and the PR_OPEN hints mention it. - Spec: B1 gains the abandon edge and B2 the command. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 17:43:43 +00:00
dongarandClaude Opus 5.5	f97e459bc7	Publish work the executor committed itself, and gate when there is none ... On the first live run the executor committed its milestone itself, as its plan asked. The publisher only published a commit it made, found a clean tree, reported "no changes to publish", and left the agent in EXECUTING, where every message is answered "busy". - publish(): with nothing left to commit, publish anyway when the branch has commits origin/<base> lacks; report no changes only when it has none. - push_followup(): same for review fixes, comparing HEAD with what the remote branch holds (ls-remote; pushes go by URL, so there is no tracking ref). - Nothing to publish now gates to AWAIT_INPUT, and the reply returns to the still-approved milestone plan. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 16:17:41 +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
dongarandClaude Opus 5	3117565928	Publish finished milestones as PRs (B2/A3) — step 6a, part 2 ... Completes the B1 loop past EXECUTING, and answers the question raised reviewing #6: PR acceptance is a milestone's final gate, so there is no separate FINISHED state — completion returns to milestone planning or to IDLE. - publish.py: MilestonePublisher commits the work on a task-namespaced branch, pushes, and opens a PR carrying the approved plan. Intent is recorded before the first externally visible act, so a crash anywhere in the sequence leaves a durable record and boot reconciliation asks Gitea whether the PR exists rather than opening a second one - Nothing to commit is reported, not raised: the executor may legitimately conclude there was nothing to change - control.py: PR_OPEN state with EXECUTING -> PR_OPEN and PR_OPEN -> {MILESTONE_PLANNING, IDLE}; operator commands 'next milestone' and 'project complete' - A configured publisher always contributes its own reconciler at boot, so an interrupted publish is settled against external truth without the caller having to remember to register it - A publish failure gates to the operator rather than retrying into a possible duplicate Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 20:43:20 +00:00