4 Commits

Include renames

Author	SHA1	Message	Date
dongarandClaude Opus 5.5	651551aab4	Answer where asked, wait on a merge, and let the driver title PRs ... From the new loop's first live run (sandbox #255, PR #256): - A question asked on the PR is answered on the PR (an inline one quoted with its file and line, since the API can't reply in its thread), with a pointer in the item's Matrix thread; one asked in Matrix stays there. - wait_for_review: when a review needs no change, or only the operator's merge is left, the item waits on the merge instead of on an answer. - finish_milestone takes the PR's title from the driver. The e2e test's merge waits out Gitea's brief 'try again later' after a push. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-10-03 17:29:28 +00:00
dongarandClaude Opus 5.5	37965aefca	Fix the run-breaking tool-result order; e2e test runs the slice (M2.1, PR D) ... The first live run of the new loop's e2e test found that a fact recorded while start_milestone was in flight landed between the tool call and its result; both API formats reject that, so every later request in the run failed. Views now keep each result right after its call. Scripted test models check the APIs' ordering rules, so this can't pass unit tests again. The e2e tests no longer depend on the sandbox's history: each run asks for a uniquely named function and works against a base branch of its own, deleted afterwards. The review step asks for a change that can't already be there. The scripted operator gives up after five fruitless answers, and each run keeps its state store for inspection. The driver's prompt says review fixes stay in the current milestone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-10-03 15:11:06 +00:00
dongarandClaude Opus 5.5	266b5dbbd7	Check loop.qnt's properties against the real loop (M2.1, PR D part 1) ... test_loop_properties.py walks the new loop with a seeded mix of operator and Gitea actions (go-aheads, stale go-aheads, answers, comments, merges, the comment-then-merge race, closes, abandon, a crash and restart) and an adaptive scripted model, checking every loop.qnt property after every step. It found two bugs, both fixed with regression tests: abandoning an item left its open PR open (the model's fix 1, now in code), and after a review fix became a follow-up PR, the next fix went to the merged branch. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-10-03 14:19:19 +00:00
dongarandClaude Opus 5.5	21744efac1	Milestones and review in the new loop (M2.1, PR C) ... A work item starts from a fresh workspace: fetch, set aside (never discard) leftover changes, branches and unpushed commits, a clean default branch, and a branch of its own (D3, #62). start_milestone cuts the milestone's branch; finish_milestone commits only the work, pushes and opens a PR that closes the issue, under an intent, adopting an open PR and treating a closed one as the operator's answer (D4). Between runs the loop watches each item's PR: operator comments and inline review notes (#69) reach the item, a merge or close hands back to the driver. A review fix is checked after it's pushed and goes out as a new PR if the PR merged first (D5). At boot an interrupted publish is settled against Gitea (L8). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE	2026-10-02 23:53:02 +00:00