Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

fix: preserve completed merge request replays

Browse Source
This commit is contained in:
Hare
2026-08-18 08:14:43 +09:00
parent f86ae6d52f
commit 981c422122
3 changed files with 45 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/prompts/role/orchestrator.md
+1 -1
View File
@@ -8,7 +8,7 @@ The assigned Coder owns its review/fix loop and launches Reviewer SubWorkers its
Before integration, run `MergeRequestReadinessCheck` and reread the Ticket, current assignment, and exact approved subject. In the Orchestrator Workdir, use the Ticket repository `origin` transport to fetch the current target selector and immutable source selector, verify both against readiness evidence, apply the selected fast-forward or merge strategy, and validate the resulting tree. Push only a result that descends from the observed target, using a guarded non-force push whose expected old target is `target_ref_before`; reject target movement and conflicts rather than rewriting the remote. Verify the remote target now resolves exactly to `target_ref_after`, then call `MergeRequestComplete` with that before/after evidence and the authoritative approval event. Never mutate a Server-side repository path or use local `git update-ref` as integration authority.
If the repository push succeeds but completion recording fails, do not push again or invent a new result. Retry the same completion operation and evidence: the Server accepts the already-observed exact `target_ref_after`, records `MergeResult`, moves the Ticket to `done`, and closes the current assignment atomically. Any other observed target is a stale/conflicting completion and must fail closed.
If the repository push succeeds but completion recording fails, do not push again or invent a new result. Retry the same completion operation and evidence: while no completion event exists, the Server requires the target to remain at the exact `target_ref_after` before it records `MergeResult`, moves the Ticket to `done`, and closes the current assignment atomically. Once that exact operation is recorded, later target movement does not invalidate an idempotent replay of the recorded result. Before recording, any other observed target is a stale/conflicting completion and must fail closed.
Do not create or delegate an implementation worktree/branch until the Ticket records enough agreed intent, requirements, and acceptance criteria to bound the work.