3 Commits

Include renames

Author	SHA1	Message	Date
dongarandClaude Opus 5.5	8bd1ac0fa2	Adopt an already-published PR instead of publishing again ... Fixes counterexample 5 from specs/orchestrator.qnt. A crash after the PR was opened but before PR_OPEN was recorded left the agent in EXECUTING; the restart question's 'continue' and 'start' then published again, Gitea refused a second PR, and there was no way back to PR_OPEN. On the live run the executor model happened to notice the existing work; recovery must not depend on that. - Boot (A3 step 4): in EXECUTING, if Gitea shows the milestone's PR open, adopt it, watch it from the start, and resume in PR_OPEN with a notice. Gitea unreachable or the PR closed: the restart question, as before. - MilestonePublisher.publish is idempotent: after pushing, an open PR for the branch is adopted (and so updated) rather than a second one opened. This also covers a PR opened whose response was lost. - The model adopts too, gains the lost-response outcome, and now counts PRs opened per milestone (one_pr_per_milestone was a flag the fixed model could never set). A mutant without adoption fails the new scenario; the properties held over 200,000 traces each. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-09-29 19:58:19 +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	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