mergestorm 0.3.61 → 0.3.63
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -8
- package/dist/api.d.ts +16 -8
- package/dist/api.js +16 -23
- package/dist/client/index.d.ts +1 -1
- package/dist/client/index.js +1 -1
- package/dist/commands/dismiss.js +4 -1
- package/dist/commands/login.d.ts +4 -1
- package/dist/commands/login.js +5 -3
- package/dist/commands/registry.js +1 -1
- package/dist/commands/review-client.d.ts +1 -2
- package/dist/commands/review-client.js +24 -3
- package/dist/commands/stack.d.ts +9 -1
- package/dist/commands/stack.js +99 -42
- package/dist/config.d.ts +1 -0
- package/dist/config.js +4 -1
- package/dist/errors.d.ts +1 -1
- package/dist/git-stack.d.ts +2 -0
- package/dist/git-stack.js +15 -0
- package/dist/repo-identity.d.ts +0 -3
- package/dist/repo-identity.js +0 -23
- package/dist/server-publish.d.ts +14 -1
- package/dist/server-publish.js +37 -9
- package/dist/stack-blockers.d.ts +4 -17
- package/dist/stack-blockers.js +93 -26
- package/dist/stack-dto.d.ts +2 -0
- package/dist/stack-meta.d.ts +0 -2
- package/dist/stack-meta.js +3 -81
- package/dist/stack-watch-loop.js +4 -1
- package/dist/stack-watch-obligation.d.ts +4 -1
- package/dist/stack-watch-obligation.js +7 -4
- package/dist/stack-watch.js +2 -1
- package/dist/ui/banner.js +6 -0
- package/package.json +9 -2
- package/skill/SKILL.md +1 -1
- package/skill/mergestorm-bounce-watch/SKILL.md +11 -5
- package/skill/mergestorm-pr-loop/SKILL.md +7 -3
|
@@ -5,7 +5,9 @@ description: Watch stacks explicitly named by the human while Auto land is on, p
|
|
|
5
5
|
|
|
6
6
|
# Mergestorm bounce watch
|
|
7
7
|
|
|
8
|
-
Use only these shipped Mergestorm MCP tools: `stack_wait`, `stack_status`, `queue_status`, and `stack_set` with `auto_land: true` only at enrollment on the human's request or as "Re-arm after a bounce" allows. Use local checkout, test, and Git operations to make the patch, and the `mg stack watch`
|
|
8
|
+
Use only these shipped Mergestorm MCP tools (plus `cyclone_start` and `cyclone_job` for the hosted handoff below): `stack_wait`, `stack_status`, `queue_status`, and `stack_set` with `auto_land: true` only at enrollment on the human's request or as "Re-arm after a bounce" allows. Use local checkout, test, and Git operations to make the patch, and, where the `mg` CLI is installed, the `mg stack watch` command to wait in the background. Auto land owns landing.
|
|
9
|
+
|
|
10
|
+
A chat agent that reaches Mergestorm only through the hosted MCP tools has no checkout it can push and no `mg`. It hands each fix a commit would make to Cyclone: `cyclone_start` with task `resolve_conflicts` for a merge conflict, `fix_ci` for a failing check, or `fix_findings` for Vortex findings, then `cyclone_job` with its `dispatch_id` until the job is pushed, completed or failed. It waits with `stack_wait` and does not install `mg`.
|
|
9
11
|
|
|
10
12
|
## Who fixes what
|
|
11
13
|
|
|
@@ -17,7 +19,7 @@ A stack watch is done only when the stack is landed, or when the human takes it
|
|
|
17
19
|
|
|
18
20
|
## Waiting in the background
|
|
19
21
|
|
|
20
|
-
The CLI watcher monitors the stack but cannot wake an agent by itself. Use the background handoff only when the host has a confirmed notification that resumes this task. A confirmed notification is a host feature you can name that turns the command's exit or matching output into your next turn; a process left running, or output written to a log or terminal you do not read, is not one. Without one, keep using `stack_wait` with `watch.next.args`, or tell the human that automatic follow-up is unavailable before ending the turn. Do not claim the task will resume just because a shell process is running. Do not subscribe to GitHub events. With a confirmed notification:
|
|
22
|
+
This section needs the `mg` CLI where you run commands. Without it, skip this section and keep calling `stack_wait` with `watch.next.args`. The CLI watcher monitors the stack but cannot wake an agent by itself. Use the background handoff only when the host has a confirmed notification that resumes this task. A confirmed notification is a host feature you can name that turns the command's exit or matching output into your next turn; a process left running, or output written to a log or terminal you do not read, is not one. Without one, keep using `stack_wait` with `watch.next.args`, or tell the human that automatic follow-up is unavailable before ending the turn. Do not claim the task will resume just because a shell process is running. Do not subscribe to GitHub events. With a confirmed notification:
|
|
21
23
|
|
|
22
24
|
1. Run `mg stack watch <stack-id>` as a background command (add `--head <sha>` right after you pushed that SHA) with a notification on output matching `MS-WATCH (ATTENTION|LANDED)`, then end your turn. The watcher runs the same stack wait against the Mergestorm API in slices of at most 300s, carries the cursor (`enrolled_head_sha`, `after_finished_at`, `bounce_id`) from one slice to the next, and prints nothing while the stack is `waiting` or `in_progress`, including `busy[]` holds and `actAfter: "agents_idle"`. It spends no model tokens while it waits. Ending your turn while it runs is not ending the task. Every `watch.next` carries this command as `watch.next.background`.
|
|
23
25
|
2. It prints one line and exits for one of three reasons:
|
|
@@ -25,10 +27,14 @@ The CLI watcher monitors the stack but cannot wake an agent by itself. Use the b
|
|
|
25
27
|
- `MS-WATCH ATTENTION failed stack=<id> error="<message>"` (exit 3): a read failed and its one retry failed too.
|
|
26
28
|
- `MS-WATCH LANDED stack=<id> reason=landed` (exit 0): the stack is confirmed landed. `closed`, `archived`, and `not_found` instead emit `MS-WATCH ATTENTION stack=<id> reason=<reason>` (exit 3); follow "Not done until landed".
|
|
27
29
|
With `--max <minutes>` it can also stop with `MS-WATCH TIMEOUT` (exit 5). The stack is not landed then; start the watcher again. `--json` writes exactly one JSON document to stdout: the final `mergestorm.stack_watch/v1` envelope, or `{ stackId, outcome }` when there is no envelope (a repeated failed read, timeout, or abort). MS-WATCH marker lines go to stderr; do not merge the streams before parsing stdout.
|
|
28
|
-
3. When the host resumes you on `MS-WATCH ATTENTION pr=`, call `stack_status` once for that stack, then fix the blocker as steps 3 to 7 of "Watch and patch" say, push, and start the watcher again with `--head` set to the SHA you pushed. On `MS-WATCH ATTENTION failed`, the watcher already retried once: tell the human the stack is not landed and is no longer being watched.
|
|
29
|
-
4. When the human has taken one blocker over and asked you to keep watching the
|
|
30
|
+
3. When the host resumes you on `MS-WATCH ATTENTION pr=`, call `stack_status` once for that stack, then fix the blocker as steps 3 to 7 of "Watch and patch" say, push, and start the watcher again with `--head` set to the SHA you pushed. When the ATTENTION line ends with `restart="mg stack watch <id> --bounce-id <id> --after-finished-at <time>"` (a merge queue bounce), start the watcher again with that command, adding `--head <sha>` after a push; without those flags a bounce you handled without a push (for example by turning Auto land back on) is reported again at once. On `MS-WATCH ATTENTION failed`, the watcher already retried once: tell the human the stack is not landed and is no longer being watched.
|
|
31
|
+
4. When the human has taken one blocker over and asked you to keep watching the stack, pass `--ignore <blocker-substring>`. The watcher stays silent on the first attention whose blocker contains that text until the blocker, its PR, or its head changes. Attention names one blocker at a time, so while the ignored blocker stands, blockers on higher layers stay hidden too; the next blocked layer wakes you only after the ignored blocker, its PR, or its head changes.
|
|
30
32
|
5. `--until landed` keeps the watcher running after an attention: it prints each new attention line once and exits only when the watch is done or a read fails twice. Use it only when your host streams output lines to you while the command runs.
|
|
31
33
|
|
|
34
|
+
## Attention on any layer
|
|
35
|
+
|
|
36
|
+
Attention covers the whole stack, not only `currentCandidate`. It names the lowest open layer, a parked one included, that has a blocker an agent must fix while no Vortex or Cyclone run is working on that layer. On a layer with auto-patch off, request_changes from Vortex at the live head is `Vortex findings need a person`, whichever layer it is on. There is one attention at a time: fix it, push, and restart the watch; the next read names the next blocked layer at once. Vortex findings that do not stop Auto land (Important findings Cyclone never took, Info notes) are not attention and the watch does not report them.
|
|
37
|
+
|
|
32
38
|
## Scope and enrollment
|
|
33
39
|
|
|
34
40
|
Watch only stacks the human named. If no unambiguous stack ID is available, ask the human to identify it; do not discover and enroll other stacks. Keep a separate cursor for each named stack.
|
|
@@ -44,7 +50,7 @@ A stack whose layers are all merged into `mg-stack-N` but has no open land PR re
|
|
|
44
50
|
3. `attention` always means something for you to fix. A land gate that is only waiting (`landGatePending` with `ci_pending` or another `*_pending` / `*_running` reason on the land PR) returns `in_progress`, not `attention`: keep watching. On `attention`, read `repair` when present: it names the blocked PR's `branch` and the concrete fix. For `restack_conflict` and `merge_conflict` it gives `liveParent` (the sibling PR head, or `mg-stack-N` once the lower layers are merged or promoted, or the land PR's base such as `main` when the blocked PR is the land PR, never `mg-park-*`) and the conflicted `files`; a null `liveParent` means stop and tell the human. For `ci_failure` it names the failing check. A stack whose `autoLandOff.reason` is `bounced` (a `merge_failed`, `gh_error`, or `ci_timeout` bounce turned Auto land off and nobody took the stack back since) returns `attention` with the blocker `Auto land off after <kind> bounce`, the bounce in `issues[]`, and a `repair` of kind `auto_land_off`; handle it as "Re-arm after a bounce" describes. A stack whose review unit was abandoned because a human moved its bottom PR off `mg-stack-N` returns `attention` with the blocker `Review unit abandoned: based on <base>` and a `repair` of kind `unit_abandoned`: do not patch or retarget anything. Ask the human whether to re-root it: if at least two PRs remain open, tell them that `mg stack adopt owner/repo#<bottom PR>` re-roots it on a new review unit; with only one open PR, re-adopting will not create a review unit, so tell them to close and resubmit it to create a fresh stack, then stop. Auto land records why it is waiting in the stack's `autoLandWait` (`reason`, `prNumber`, `headSha`, `since`), and the watch returns `attention` on that PR when the wait cannot clear on its own: a failing check Auto land reads live on GitHub while the ledger may still show CI green (blocker `CI failed — Auto land reads a failing check on GitHub at this head`, `repair` kind `ci_failure`); a check pending for 45 minutes (`repair` kind `ci_pending`: find the check that never finished and re-run it, or tell the human when no workflow reports it); no approving Vortex review for 30 minutes with no Vortex run working (`repair` kind `vortex_not_green`: fix or dismiss the findings, or tell the human when no review exists at the head); and a promote GitHub refused 3 times with `merge_failed`, after which Auto land stops retrying that head (`repair` kind `promote_failed`: fix the cause on the PR and push a new head, or tell the human when the cause is outside the PR; never toggle Auto land yourself for it). The watch also returns `attention` when GitHub refuses to let Mergestorm read the head's check runs or commit statuses (blocker `Mergestorm cannot read ... on this head`, `repair` kind `ci_unreadable`: do not patch or push; tell the human to grant the Mergestorm GitHub App the permission the repair names), and when any other wait reason has held for 45 minutes, a land gate left pending or running on the land PR included (blocker `Auto land has waited <N>m: <reason in plain words>`, `repair` kind `auto_land_waiting`: read `stack_status`, fix what a commit on the named branch can fix, otherwise tell the human what Auto land waits for and since when). A merge queue entry that has sat queued for 45 minutes with nothing working on it or ahead of it returns `attention` with the blocker `Merge queue stuck: ...` and a `repair` whose kind is queue_stalled: do not patch or push; tell the human. A Vortex review skipped because the PR author is on the ignored authors list, or because reviews are turned off for the repository, returns `attention` at once with a `repair` of kind `vortex_skipped`; a Vortex retry that is scheduled (`Vortex hit a temporary error on this head and will retry by itself`) is a wait listed in `issues[]`, never `attention`. `Review failed` carries a `repair` of kind `vortex_failed`: comment `@mergestorm-vortex review` on the PR or push a new commit, and tell the human if it fails again. A PR open on `mg-stack-N` that is not a layer of the stack returns `attention` at once with the blocker `The land PR cannot be queued: ...` and a `repair` of kind `members_remaining`: do not patch or push; close, retarget or adopt that PR (a draft or fork PR cannot be adopted). A layer whose live head has a Vortex verdict that requests changes after Cyclone left those findings for a person (a hold directive, the Vortex patch cap, auto-patch off, no billing, a batch it gave up on, or a PR state it could not read) returns `attention` with the blocker `Vortex findings need a person` and a `repair` of kind `vortex_findings` naming the Cyclone reason (`handoff`) and where the review is (`findings`): verify each finding against the checkout, fix the real ones with the smallest patch and an ordinary push, and tell the human about the ones you judge wrong. `repair` does not replace the checks below. On `attention`, fix the named PR: `prNumber` and `headSha` identify the blocked PR, while `currentCandidate` identifies the promote candidate. The gate covers the bottom and its direct child only when the child has current-head DIRTY on the live bottom branch. A GitHub DIRTY whose `parentBranch` starts with `mg-park-` is not that gate. Refresh `stack_status`; use `queue_status` with the same `stack_id` when bounce details are needed. Verify the blocker still applies to the current PR head. Never treat `verifyHeadSha` as the current head: it is a queue verification SHA and can be stale or synthetic. Compare the live PR branch head, the current stack layer head, and the checkout before editing. Read the live PR head with `git ls-remote origin refs/heads/<branch>` or `gh api repos/OWNER/REPO/pulls/N --jq .head.sha`. If you need CI logs, use `gh run list --branch <branch>`, `gh run view <run-id> --log-failed`, or `gh api repos/OWNER/REPO/commits/SHA/check-runs`. Read GitHub only through git and these REST calls; do not use other `gh pr` subcommands. Restack `clean` does not mean mergeable or CI-green. Attention is a diagnosis, not permission to mutate stack or queue policy; the only policy change you make is the re-arm in "Re-arm after a bounce". A bounce is the reason to look, not the moment to commit. `stack_wait` and `stack_status` hold the blocked PR's attention themselves while Vortex or Cyclone is still working on that PR, whatever the blocker (a red CI failure, a merge conflict, a bounce, Draft, a failed restack or review): they return `in_progress` instead of `attention`, with `busy[]` naming the PR (`prNumber`, `headSha`), the `blocker`, and the `agent` (`vortex` or `cyclone`), and `agents` carrying that PR's `vortexStatus`, `cycloneStatus`, `vortexReview`, and `busy` flags. `in_progress` with a nonempty `busy[]` means do not patch yet: keep calling `stack_wait` with the same cursor until that work has finished and the watch returns `attention`, then make the follow-up commit. You do not need an extra `stack_status` refresh each slice for this check. A nonempty `busy[]` reports still-working agents on that PR's current head. Vortex holds when `vortexReview` is `reviewing` at the head, an unfinished vortex `agentRuns` row at the head is `reviewing`, or an unfinished vortex run at the head is `queued` and started within the last 15 minutes (with no `agentRuns` or `vortexReview` on the layer, `vortexStatus` `reviewing` holds). Cyclone holds when `cycloneStatus` is `patching`, an unfinished cyclone `agentRuns` row is `patching`, or the server sees a live Cyclone patch lease or an open Cyclone check run on the head. `seam_pending` alone, and a `queued` run older than 15 minutes, are not treated as work in progress. `all_clear`, `findings`, `skipped`, `failed`, `throttled`, `awaiting_fix`, and a null status are finished. A queued Vortex run holds for at most 15 minutes; reviewing and patching hold until the run finishes or its lease or check run is cleared. A blocker no Vortex or Cyclone run can clear is not hidden by the hold: a merge conflict vs the live parent, a restack `Conflict` or `Restack failed` (a parked freeze included), a Draft PR, `Seam review pending, no review running`, or `Review skipped, out of review quota`. For those the envelope stays `in_progress` but names the blocker in the top-level `blocker`, `prNumber`, `headSha`, and `issues[]`, with `actAfter: "agents_idle"`, `waitingOn` listing the busy agents, and `repair` when there is one. Plan the fix from it, but do not patch, merge, or push while `actAfter` is set: keep calling `stack_wait` with the same cursor, and act when a snapshot after the agents finish returns `attention`; a Cyclone push can change or clear the blocker, so re-read it then. Blockers the agents can change (a red CI failure, a failed review, seam findings, a bounce) keep the plain hold: `blocker` is null, `actAfter` is null, and only `busy[]` names them. If a hold looks stuck, refresh `stack_status` and tell the human. Do not turn Cyclone off or Auto land off, and do not turn Auto land on to end the wait; turn it on only as "Re-arm after a bounce" allows. If the remote head moves while you wait, stop and tell the human.
|
|
45
51
|
4. Use a clean worktree on that named PR's head branch and record the remote starting SHA. Fix the current blocker with the smallest patch, and run the relevant checks. For conflicts, the live parent is the sibling PR head or the unit branch (`mg-stack-N`, Mergestorm's owned trunk, not an alias for main) — not the DTO `parentBranch` when that field starts with `mg-park-*`. If `parentBranch` is `mg-park-*`, never merge or rebase onto it; if the real live parent is unknown, stop. The land PR is the one PR whose head is `mg-stack-N`: its live parent is its base (`main`), and merging that base into `mg-stack-N` with an ordinary push is its conflict repair, the same as for any other layer. Cyclone patches Vortex findings on a land PR when auto-patch is on for that stack; every other land PR blocker, a conflict with main or failing CI included, is yours: when `busy[]` shows no Cyclone run on it, fix it with the smallest patch on `mg-stack-N` and push with an ordinary push, never a force push; while Cyclone is patching findings on it the envelope stays `in_progress` with `busy[]`, so wait. For a conflict, prefer merging that live parent into the PR branch, resolving locally, then an ordinary push. Do not click Dashboard Continue yourself: Continue is a human action, and you relay it to the human only when step 5 or a `repair` names it. When the live parent is a sibling, never rebase onto trunk or `mg-stack-N` instead. Parked-freeze DIRTY alone needs no conflict patch. Leave GitHub bases as Mergestorm set them: the bottom of a 2+ PR stack is based on `mg-stack-N`, layer 2 on layer 1, PR3+ on `mg-park-*`.
|
|
46
52
|
5. CI-only fixes may run while Cyclone auto-patch is still on for the stack. Auto-patch may stay on, and you still wait until the current Vortex run and the current Cyclone run on that PR have finished before the follow-up commit. When the gate is clean, inspect `issues[]` and fix a live upstack CI failure one PR at a time, refreshing the gate before the next PR. Do not use higher-layer bounce history as a patch target. Do not fight Cyclone: if the remote head moved, stop and tell the human. Do not take over Cyclone's review-finding work while it is active; if the blocker requires that or a policy/queue action rather than a concrete patch, stop and explain what needs human attention. On a `Seam findings` blocker, read that PR's seam finding, the Vortex review "Integration review — IU <n> seam" (`gh api repos/OWNER/REPO/pulls/N/reviews` and `gh api repos/OWNER/REPO/pulls/N/comments`), and patch its concrete findings on that PR's head; a "Decision required" seam finding needs a human, so tell them and do not guess. A seam finding you verified is wrong is recorded with `mg dismiss` (the audited dismissal in `mergestorm-pr-loop`) at that PR's live head and that seam review's id; a `mergestorm-loop: dismiss` comment alone does not clear the seam gate. On `Seam review failed`, do not patch; tell the human, unless a new push already has a seam re-review held in `busy[]`. On `Seam review pending, no review running`, do not patch; tell the human: the seam review was skipped (usually because the monthly review limit is reached) and nothing re-runs it until they raise the limit and click Continue on the stack, or push a new head. On `Seam review stuck in reviewing, no review running`, `Seam re-review pending, no review running`, or `Seam verdict is for an older head, no review running` (repair kind `seam_review_stuck`), do not patch or push; tell the human: no seam review is queued or running for that PR's live head, and clicking Continue on the stack re-queues it (a new pushed head also does). On `Review skipped, out of review quota`, do not patch; tell the human: the review credit limit for the period is reached and nothing re-reviews that head until they raise the limit and push a new head or re-run the review.
|
|
47
|
-
6. Recheck Auto land (off is expected only after a disarming bounce you are handling) and the remote PR head (`git ls-remote origin refs/heads/<branch>`) immediately before pushing. Commit the patch and push the PR head with an ordinary push. A rebase onto that same live parent followed by force-with-lease is allowed only if the remote is still exactly the SHA you started from and Cyclone did not move it; use an explicit lease bound to that starting SHA. This exception never permits rebasing onto a parked freeze or substituting trunk / the unit for a sibling parent. If the remote head moved or the push is rejected because it moved, stop; do not rebase and retry.
|
|
53
|
+
6. Recheck Auto land (off is expected only after a disarming bounce you are handling) and the remote PR head (`git ls-remote origin refs/heads/<branch>`) immediately before pushing. Also call `queue_status` with the `stack_id`: while an entry of the stack is `queued`, `running`, or `waiting`, do not push. The queue is verifying the diff that was reviewed when it was queued; a push that changes that diff bounces the entry `head_moved` and stops the batch it is in, which re-runs CI for every PR in that batch. Do not cancel the entry. Keep the fix on a local branch and keep watching: when the entry bounces, push the fix to this PR; when the stack lands, open the fix as a follow-up PR (`mg stack create <name> --onto main`, then `mg stack submit`) and tell the human its number. Commit the patch and push the PR head with an ordinary push. A rebase onto that same live parent followed by force-with-lease is allowed only if the remote is still exactly the SHA you started from and Cyclone did not move it; use an explicit lease bound to that starting SHA. This exception never permits rebasing onto a parked freeze or substituting trunk / the unit for a sibling parent. If the remote head moved or the push is rejected because it moved, stop; do not rebase and retry.
|
|
48
54
|
7. After your successful push, leave a clean worktree and keep watching the named stack. Start a new watch cycle with `enrolled_head_sha` set to the SHA you pushed (in the background: `mg stack watch <stack-id> --head <pushed-sha>`). If you handled a bounce, retain the returned `cursor.afterFinishedAt` as `after_finished_at` and `cursor.bounceId` as `bounce_id` so that attempt is not handled again. Keep these selectors unchanged across subsequent retries. Continue watching; do not enqueue anything. If the bounce you handled turned Auto land off, turn it back on as "Re-arm after a bounce" allows; if that section does not allow it, report and stop.
|
|
49
55
|
|
|
50
56
|
## Re-arm after a bounce
|
|
@@ -19,10 +19,13 @@ mg skill install --claude --cursor --agents
|
|
|
19
19
|
|
|
20
20
|
## Preconditions (in order)
|
|
21
21
|
|
|
22
|
+
A hosted-only agent (no checkout of the PR head; see 5) checks 1, then follows 5 instead of 2 to 4: those gates are for the local patching loop it does not run, and the `mg login` sign-in in 4 needs a shell it does not have.
|
|
23
|
+
|
|
22
24
|
1. There is an already-open GitHub PR on a Vortex-monitored repo. No PR, wrong skill.
|
|
23
25
|
2. Auto-patch (Cyclone) must be off for this PR so you are the only patcher. Do not take anyone's word for it: the settings API and the PR's stack are the source of truth, and step 1 of the loop verifies them before anything else runs. Cyclone is off for the PR when its adopted stack has `autoPatchOverride` `false`, or when that override is unset and the account `auto_patch_enabled` is `false`.
|
|
24
26
|
3. The Bearer key and the Cyclone GitHub App install must be the same Mergestorm account. `stack_list` / `stack_status` expose `keyUserId`, `cycloneInstallUserId`, and `cycloneOwnerMatch`. Cyclone apply always uses the install account, not the key. If those identities differ, your `settings_get` mute reading is about the wrong person.
|
|
25
27
|
4. `whoami` works on the `mergestorm` MCP server (or `mg whoami --json` exits 0). Otherwise stop and ask for install, or sign in yourself: run `mg login --start`, send the person the link it prints, and after they approve it run `mg login --finish`.
|
|
28
|
+
5. You have a checkout of the PR head that you can push. A chat agent that reaches Mergestorm only through the hosted MCP tools, with no such checkout, does not run this loop: Cyclone patches the PR. Call `cyclone_start` with task `fix_findings` for the PR, then call `cyclone_job` with its `dispatch_id` until the job is pushed, completed or failed, and tell the human what it pushed.
|
|
26
29
|
|
|
27
30
|
## Loop (in order)
|
|
28
31
|
|
|
@@ -55,9 +58,10 @@ mg skill install --claude --cursor --agents
|
|
|
55
58
|
- A refusal (stale_head, review_mismatch, unknown_finding, forbidden) means nothing was written. Re-read the pass at the live head; do not retry with another review's ids.
|
|
56
59
|
- The seam gate clears only when every finding of that seam review is dismissed. Once every Vortex Blocker (error finding) at the live head is dismissed (every Core review merged into that head, not only the one you name), the Vortex gate clears at that head; while any is open, or a Vortex review of the head is still running or incomplete, it stays shut and `gate.vortex.message` says why. The result's `gate` says whether either cleared; CI and Auto land policy are unchanged. For a stack PR, follow `watch.next` (the next `stack_wait` call).
|
|
57
60
|
6. Patch on the PR head branch only.
|
|
58
|
-
7.
|
|
59
|
-
8.
|
|
60
|
-
9.
|
|
61
|
+
7. If the PR is a layer of a stack, call `queue_status` with that `stack_id` before you push. While an entry of the stack is `queued`, `running`, or `waiting`, do not push: the queue is verifying the reviewed diff, and a push that changes it bounces the entry `head_moved` and stops the batch it is in, which re-runs CI for every PR in that batch. Do not cancel the entry. Keep the fix on a local branch and wait for the entry to finish: when it bounces, continue with the push; when it lands, open the fix as a follow-up PR (`mg stack create <name> --onto main`, then `mg stack submit`), tell the human its number, and stop this loop. Without a live entry, continue. Auto land needs no change: a push before it queues the PR only restarts its wait on the new head.
|
|
62
|
+
8. Push that head branch with an ordinary push. If the push is rejected because the remote branch moved, another patcher already pushed for this pass. Do not rebase, do not force, do not retry the push: stop and tell the human that a second patcher is active on this PR.
|
|
63
|
+
9. Call `review_wait_pr` again with `after_sha` set to the SHA you just pushed (7+ hex) and `timeout_s` 45. If the last envelope you acted on has that same `head_sha` (no new commit, for example a re-review requested on the same head), also pass `after_pass` set to that envelope's saved `pass`, so the wait cannot hand you that attempt again. For a freshly pushed SHA omit `after_pass`; its first pass is 1. Keep `after_sha` and `after_pass` unchanged across 45s timeout retries; never replace `after_pass` with the `pass` of an in-progress envelope. `pass` reads one exact attempt; `timeout_s` 0 reads once without waiting. An envelope whose `head_sha` is an older commit is a previous pass, not yours; keep waiting.
|
|
64
|
+
10. Repeat from step 4 until a stop rule fires.
|
|
61
65
|
|
|
62
66
|
## Stop rules
|
|
63
67
|
|