ci: auto-queue PRs in Mergify once verify, Unfret and live-gate pass (#100)

[mast-factory]

Related to #100. Supersedes the configuration proposed in #101; the operator will close #101 after this PR merges. Keep #100 open until the separate proof PR demonstrates automatic queueing and merging.

What changed

Add the approved .mergify.yml with a single serial, in-place default queue. Both queue conditions and merge protections require a non-draft PR with verify, Unfret, and exact-head live-gate passing. Empty merge conditions, batch size 1, and max parallel checks 1 avoid temporary batch PRs that Unfret would not review. Mergify owns automatic queueing and uses merge commits. Requeue remains restricted to writers.

Only .mergify.yml changes: 34 gross added lines, within the 45-line card budget (including the future one-line proof PR).

Verification

Candidate: 92b224961c4ff05a6ac0b16d233a69cffebea230 on factory/issue-100.

Sandbox checks actually run:

• PSTACK_STATIC_ONLY=1 bash tests/skill-collision-repro.sh — exit 0, all 13 static invariant groups reported ok.
• Parsed all four JSON manifests with Node's JSON.parse — exit 0, four PASS outputs. This replaces only the Bun-based manifest parsing command, not Bun tests or typecheck.
• git diff --check and git diff --cached --check — exit 0.
• git diff --cached --numstat — 34 0 .mergify.yml before committing.

Unavailable/deferred (no tools installed, per operator decision):

• bun install --frozen-lockfile, bun run test, and bun run typecheck: Bun unavailable.

• claude plugin validate . and claude plugin validate plugins/pstack: Claude CLI unavailable.

• YAML parsing: Python import yaml failed with ModuleNotFoundError; Node yaml and js-yaml could not resolve in workspace/system paths. bunx not used. Operator must validate YAML on the Mac, and the Mergify configuration check must pass.

• Bun tests, strict typecheck, static invariants, and plugin validation pass (operator, Mac; see evidence).

• The exact candidate is installed in every affected harness: none affected (no plugin content changes; repository Mergify configuration only).

• The changed behavior passes from its real surface: Mergify's Configuration changed check on this head. Queue behavior is proven by the follow-up proof PR (Configure Mergify to auto-queue PRs once verify and Unfret pass #100).

• The installed version, action, and observed result appear below.

Live evidence:

• Installed version / candidate: 91b0d5b47c46e1bcb57e38ded79f1f98f64987f1
• Surface / harness: Mergify (real service); no Claude Code or Codex harness affected
• Action: Mergify evaluated this head's .mergify.yml; operator ran Bun 1.4.0 tests and typecheck, the manifest parse, static invariants, claude plugin validate (2.1.283) for . and plugins/pstack, the YAML parse and git diff --check
• Observed result: Configuration changed pass; 158 tests 0 fail; typecheck, manifests, static invariants, both validations, YAML and diff-check all pass
• Evidence URL: ci: auto-queue PRs in Mergify once verify, Unfret and live-gate pass (#100) #107 (comment)

Operator handoff

This PR stays draft until the operator runs and records Mac checks and installed-harness evidence for the exact head. The operator marks it ready for Unfret, posts exact-head live-gate, and performs the one manual queue command needed to deploy this configuration from main. The builder does not post statuses, mark it ready, queue, or merge it.

After this PR merges, the operator posts a comment on #100 starting with live-gate evidence: #107 and resumes the builder. The separate proof PR must hold without live-gate, then auto-queue and merge without a manual queue command. The operator also captures babysit-pr's before/after output with the MASTRA-749 required-check map.

A pull request without live evidence remains a draft. Do not merge, tag, release, or roll it out.

[mergify]

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 📃 Configuration Change Requirements

Mergify configuration change

• any of:
  • check-success = @mergify/Configuration changed
  • check-success = @mergify/Configuration has been deleted

[ericlitman]

Operator checks on exact head 92b224961c4ff05a6ac0b16d233a69cffebea230 (pro14, Mac):

## operator checks on 92b2249 (2026-10-02T05:07:12Z), bun 1.4.0, 2.1.283 (Claude Code)
bun install: 0
 0 fail
 648 expect() calls
Ran 158 tests across 11 files. [18.25s]
test exit: 
typecheck exit: 0
manifests exit: 0
static invariants exit: 0
✔ Validation passed
validate root exit: 
✔ Validation passed
validate pstack exit: 
Resolving dependencies
Resolved, downloaded and extracted [6]
Saved lockfile
yaml exit: 0
diff-check exit: 0

Configuration changed (Mergify, real service) passes on this head: https://dashboard.mergify.com/orgs/ericlitman/repos/open-pstack/activity-log?pull_request=107

[greptile-apps]

Confidence Score: 4/5

[High risk] Adds automated merge queue to the CI/CD pipeline.

This PR should not merge until the queue requires a waiting branch to be current with main.

Findings

1.  Checks can miss newer main ▶

Summary

Adds Mergify rules to queue ready pull requests targeting main and merge them after required checks pass. The queue runs one pull request at a time, and only writers can requeue.

• Queue entry and merge protection both require a non-draft pull request and passing verify, Unfret, and live-gate checks.
• The queue uses single-pull-request batches and merge commits.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A["PR head passes three checks"] --> B["Enter serial queue"]
  B --> C["main may change"]
  C --> D["Merge without an up-to-date requirement"]

Loading

_{Reviews (1) · Last reviewed commit: "ci: require exact-head live evidence bef..."}

[greptile-apps]

Merged tree goes untested

If main moves after a PR passes verify, Unfret, and live-gate, these queue conditions still allow the older branch to merge. The merge commit can then contain a tree the live test never covered. Require the branch to be up to date with main so a move calls for fresh checks and live evidence.

[mast-factory]

Operator adjudication: no change. With in-place checks, Mergify updates a behind branch; the new head must pass the queue conditions again, including fresh exact-head live-gate after operator re-testing.

[greptile-apps]

Agreed. With max_parallel_checks: 1, batch_size: 1, and no additional merge_conditions, Mergify uses the in-place queue flow: when main advances, it updates the queued branch and restarts validation on the resulting head. Because check-success results are commit-specific, the old verify, Unfret, and exact-head live-gate results cannot satisfy the new head; fresh checks and live evidence are required before merging. No configuration change is needed.

[greptile-apps]

Checks can miss newer main

If main changes while a PR waits, its head can keep the earlier green checks. merge_conditions: [] does not require the branch to catch up or the checks to run against the new base. Mergify can then merge code that was not tested against current main. Require the branch to be up to date before merging, with fresh checks after it changes.

[mast-factory]

Operator adjudication: no change. With in-place checks, Mergify updates a behind branch; the new head must pass the queue conditions again, including fresh exact-head live-gate after operator re-testing.

[greptile-apps]

Understood. Given Mergify’s in-place update behavior, advancing main produces a new PR head and causes the queue conditions—including the exact-head live-gate—to be evaluated again before merge. That addresses the stale-base concern, so no change is needed.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[unfret-eal]

✅ Accepted risk

Accepted by ericlitman: MASTRA-738 (authority 48fa77b)

🟡 Medium · Stale queue admission invalidates the exact-head live gate

Details

Run: GET /unfret/run/panel:91b0d5b47c46e1bcb57e38ded79f1f98f64987f1:HguhhN4PMuM:21SKFyzcYwg.

_{@unfret review · @unfret status · @unfret help}

[unfret-eal]

🛑 2 blocking findings
🔴 Critical · Auto-queue gates accept spoofable check names
🟡 Medium · In-place update drops exact-head live-gate, stalling queue
Check

[unfret-eal]

🔴 Critical · Auto-queue gates accept spoofable check names

The queue conditions (L11-13) and merge-protection success conditions (L27-29) match verify, Unfret and live-gate by name only, with no source check. auto_merge_conditions (L18) admits any PR to main with no author or approval restriction. Scenario: a non-draft PR adds a workflow with jobs named live-gate/Unfret (and can edit the verify workflow). The PR could come from a fork whose Actions run, or from the builder bot. Those jobs post successful check-runs with the gated names on the PR head. Mergify then auto-queues the PR and, with empty merge_conditions, merges it. The operator never posted live-gate and the real Unfret may never have passed. Before this diff, merges were manual. Branch protection that requires human approval would block this, but it is not visible here and may exist outside this diff. Also reported for this defect: - Unqualified check names allow gate spoofing (.mergify.yml:11-13): Mergify's bare check-success form accepts a successful check with the matching name regardless of its producer. A pull request can publish trivially successful checks named verify, Unfret, and live-gate; these conditions then pass even if the trusted checks failed or never ran. The same unqualified names at lines 27-29 let the spoof satisfy merge protection too, allowing an untrusted PR to be auto-queued and merged without the mandated gates. - Authenticate the live-gate result's source (.mergify.yml:13): Mergify's unqualified check-success accepts a matching check from any app, not just the operator's commit status. A fork contributor can add a pull_request Actions job named live-gate that simply succeeds; GitHub publishes that check even with a read-only token. For an up-to-date, non-draft PR whose genuine verify and Unfret pass, this line and line 29 accept the workflow-produced result, allowing automatic merging without the operator's installed-candidate test required by AGENTS.md. Both gate conditions need to distinguish the trusted live-test result from PR-controlled check runs.

Also affects:

• .mergify.yml:13

Withdrawn in the latest review.

[mast-factory]

Applied the operator-confirmed correction in f65069f: both queue_conditions and success_conditions now include -files~=^\.github/, with a short explanatory comment. PRs touching .github/ cannot auto-queue and require manual operator queueing. No other mechanism added.

[unfret-eal]

🟡 Medium · Stale queue admission invalidates the exact-head live gate

These admission conditions allow a PR whose branch is behind main to enter the serial in-place queue while all three checks pass on its old head. Mergify then merges main into the PR branch, creating a new head SHA without the operator-posted live-gate. The gate required here and at line 31 cannot pass until the operator installs, live-tests, and publishes another status on that Mergify-created head, so the admitted PR cannot complete automatically. No automatic live-gate publisher is present. An up-to-date admission guard is still missing; the carried repair remains unresolved. Also reported for this defect: - Queue updates invalidate the exact-head live gate (.mergify.yml:13): A PR can satisfy this condition and enter the serial queue, then become stale when an earlier PR merges. Mergify's in-place update creates a new head SHA without the manually published live-gate, so the PR cannot complete automatically until an operator installs, retests, and posts a new status for the Mergify-created commit. - In-place update strands exact-head live-gate (.mergify.yml:31): Still present. Serial in-place checks (L2 max_parallel_checks: 1, L6 batch_size: 1) make Mergify merge main into a queued PR that has fallen behind, for example after an earlier queued PR merges. That creates a new head SHA. The operator's manual live-gate exists only on the tested SHA, and admission (L9-13) has no up-to-date guard. So L13 and L31 cannot pass on the head Mergify would merge, and nothing publishes live-gate automatically. With checks_timeout: null (L7), the PR either waits at the serial queue head, blocking every later PR, or is dequeued. Either way, progress requires an operator live-gate on a Mergify-made commit nobody live-tested. - In-place update strands exact-head live-gate (.mergify.yml:33, .mergify.yml:10-15, .mergify.yml:15, .mergify.yml:29): Carried, unchanged at this head. Serial in-place checking (L2, L6) merges main into a behind PR, creating a new head SHA. The operator's live-gate exists only on the old SHA, so L33 (and L15) cannot pass on the head Mergify would merge. With checks_timeout null (L7), the PR either waits at the serial queue head, blocking later PRs, or is dequeued. Either way, progress requires a live-gate on a Mergify-made commit the operator never tested. Trigger: a queued PR falls behind after another PR merges. Also reported for this defect: - Queue updates invalidate the approved live-gate (.mergify.yml:10-15): These admission conditions accept a green PR whose branch is behind main, including one made stale by an earlier queued merge. The serial in-place queue then merges main into that branch, creating a new head SHA. The operator's live-gate status remains on the old SHA, while lines 15 and 33 require it on the new one and no automatic publisher exists. The admitted PR consequently cannot complete its automatic merge until the operator installs and live-tests the Mergify-created head and posts another status. The prior missing up-to-date admission guard remains unresolved. - Updating a stale queued PR invalidates its live gate (.mergify.yml:15): A PR can satisfy this exact-head status while current, then become stale when an earlier PR merges. The serial in-place queue updates that PR to a new head, where the manually posted live-gate no longer exists; the protection therefore cannot pass until an operator tests and posts another status on Mergify's new commit, and checks_timeout: null leaves the wait unbounded. Thus ordinary queue advancement can strand or dequeue an otherwise ready PR instead of automatically merging it. - In-place update drops exact-head live-gate, stalling queue (.mergify.yml:29): batch_size: 1 (L6) and max_parallel_checks: 1 (L2) make Mergify check queued PRs in place. Scenario: a ready PR is behind main because another PR merged first. Mergify merges main into the PR branch and creates a new head SHA. The operator's exact-head live-gate exists only on the old SHA. So check-success=live-gate cannot pass on the head Mergify is about to merge, whether it comes from merge protections (L29), the queue condition (L13), or a live-gate check Mergify injects from branch protection. With checks_timeout: null, the serial queue then waits indefinitely, or the PR is dequeued. Every later PR is blocked until the operator posts live-gate on a Mergify-made commit they never live-tested. The planned proof PR will be up to date with main, so it will not exercise this path.

Now at .mergify.yml:9-13

Also affects:

• .mergify.yml:9-13
• .mergify.yml:10-15
• .mergify.yml:13
• .mergify.yml:15
• .mergify.yml:31
• .mergify.yml:33

[mast-factory]

Operator adjudication: no change. This is the documented fails-loudly hold: an updated head lacks exact-head live-gate and leaves the queue; the operator re-tests that head and re-posts live-gate before it can proceed.

[mast-factory]

Operator adjudication: no change. Mergify removes a PR from the queue when queue_conditions stop matching, including a new head without exact-head live-gate, so the queue does not stall. The operator re-tests the new head and re-posts live-gate.

[ericlitman]

@unfret review

[ericlitman]

Operator checks on exact head f65069fe3d35ba550c991e3fccc18a685b646b60 (pro14, Mac):

## operator checks on f65069fe3d35ba550c991e3fccc18a685b646b60 (2026-10-02T05:24:31Z), bun 1.4.0, 2.1.283 (Claude Code)
bun install: 0
 158 pass
 0 fail
Ran 158 tests across 11 files. [18.21s]
typecheck exit: 0
manifests exit: 0
static invariants exit: 0
validate root exit: 0
validate pstack exit: 0
yaml exit: 0
diff-check exit: 0

Mergify Configuration changed passes on this head.

[unfret-eal]

🛑 2 blocking findings
🟡 Medium · .github/ exclusion also blocks the promised operator queue
🟡 Medium · In-place update strands exact-head live-gate
Check

[unfret-eal]

🟡 Medium · .github/ exclusion also blocks the promised operator queue

L11 puts -files~=^\.github/ in the only queue rule's queue_conditions; L29 puts it in the merge protection's success_conditions. Mergify applies queue_conditions to the manual queue command too. Scenario: the operator runs @mergifyio queue on a PR editing .github/workflows/verify.yml or the PR template. The PR waits for queue conditions forever, and its merge-protection check never succeeds. The comment's 'operator queue' path therefore does not exist, and such PRs can merge only by bypassing Mergify. Placing the exclusion only on the auto-merge trigger (auto_merge_conditions) would avoid this. Also reported for this defect: - The workflow guard also blocks authorized manual queueing (.mergify.yml:11): For any PR changing .github/workflows/..., this negated file condition is false. Mergify requires a target queue's queue_conditions even for an explicit @mergifyio queue default command, and no alternate queue exists, so the operator queue described by the comment cannot admit such a PR; the command remains pending and the workflow change cannot progress through this merge queue. - Workflow PRs cannot use the operator queue (.mergify.yml:11): Mergify applies queue_conditions to manual queue commands too. A PR changing .github/workflows/ci.yml therefore cannot enter the default queue even after all three gates genuinely pass and an operator issues @mergifyio queue default. The identical predicate at line 29 also permanently fails its merge protection. This blocks the operator-controlled path promised by the comments, rather than merely excluding workflow changes from automatic queueing.

Withdrawn in the latest review.

[mast-factory]

Corrected in 91b0d5b: removed the .github/ exclusion and comments from queue_conditions and success_conditions; placed the exclusion only in auto_merge_conditions below base = main, with the requested short comment. Workflow changes cannot auto-queue, but the operator can queue them by hand after the required gates pass.

[unfret-eal]

🛑 1 blocking finding
🟡 Medium · Stale queue admission invalidates the exact-head live gate
Check

[ericlitman]

Operator waiver for head 91b0d5b (open-pstack#100, MASTRA-738 live run).

Finding v1:f47057cba2df325d463805f016bd47e61951a53fca9508b55efd8ca96815a21e, "Stale queue admission invalidates the exact-head live gate". Class: fails-loudly.

The trigger is real: a queued PR falls behind main, and Mergify's in-place update creates a new head with no live-gate. The consequence is the designed hold, not a bypass. queue_conditions stop matching on the new head, so Mergify removes the PR from the queue and nothing merges untested. The operator re-runs the live check on the new head and re-posts live-gate. The plan documents this hold (revision 7, Risks). Alternatives such as an up-to-date admission condition or an automatic live-gate publisher would add a gate or a publisher that no acceptance criterion asks for.

[ericlitman]

Operator checks on exact head 91b0d5b47c46e1bcb57e38ded79f1f98f64987f1 (pro14, Mac):

## operator checks on 91b0d5b47c46e1bcb57e38ded79f1f98f64987f1 (2026-10-02T06:06:03Z), bun 1.4.0, 2.1.283 (Claude Code)
bun install: 0
 158 pass
 0 fail
Ran 158 tests across 11 files. [18.41s]
typecheck exit: 0
manifests exit: 0
static invariants exit: 0
validate root exit: 0
validate pstack exit: 0
yaml exit: 0
diff-check exit: 0

Mergify Configuration changed passes on this head.

[mergify]

Queued — the merge queue status continues in this comment ↓.

[ericlitman]

@Mergifyio queue

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-10-02 06:08 UTC · Rule: default · triggered by @ericlitman with the @mergifyio queue command
• ✅ Checks skipped · PR is already up-to-date
• ✅ Merged — 2026-10-02 06:08 UTC · at a0ead6296ab2063e6a73a169054f0d9e1bf8d516

This pull request spent 18 seconds in the queue, including 1 second running CI.

Required conditions to merge

• github-review-approved [🛡 GitHub repository ruleset rule Protect main]
  • ci: auto-queue PRs in Mergify once verify, Unfret and live-gate pass (#100) #107
• any of [🛡 GitHub repository ruleset rule Protect main]:
  • check-success = @github-actions/verify
  • check-neutral = @github-actions/verify
  • check-skipped = @github-actions/verify
• any of [🛡 GitHub repository ruleset rule Review gate]:
  • check-success = @unfret-eal/Unfret
  • check-neutral = @unfret-eal/Unfret
  • check-skipped = @unfret-eal/Unfret

[mast-factory]

Merged-completion verification — #100

Agent verification on October 2, 2026: all eight approved-plan acceptance items are satisfied, applying the operator-approved replacement of #101 with deployment #107 and proof PR #108.

Delivery #107 is actually MERGED to main at a0ead6296ab2063e6a73a169054f0d9e1bf8d516 (2026-10-02T06:08:47Z), head 91b0d5b47c46e1bcb57e38ded79f1f98f64987f1. Proof #108 is MERGED at 6c44500ab0d4708cb40b29628d099105889359c7 (2026-10-02T06:25:16Z), head 95eed70a5002286c1a62553a9873be78f06d9411.

Acceptance items 1–4 and 8: operator artifacts read back

• 1: ci: auto-queue PRs in Mergify once verify, Unfret and live-gate pass (#100) #107 comment 5946511233 records exact-head Mac execution: Bun install exit 0; 158 tests pass / 0 fail; typecheck, manifests, static invariants, root/pstack Claude validation, YAML parse and diff-check all exit 0. docs: prove automatic Mergify queueing after live-gate (#100) #108 comment 5946633570 records exact proof-head Mac checks: 158 pass / 0 fail, all listed checks exit 0. These are operator executions, not sandbox Bun/Claude executions; the sandbox-tool deferral was explicitly authorized.
• 2: Independently ran gh pr checks 107 -R ericlitman/open-pstack: Configuration changed, verify, Unfret, live-gate and both Mergify checks pass.
• 3: Issue Configure Mergify to auto-queue PRs once verify and Unfret pass #100 comment 5946540669 records deployment merge and two parents; independently ran the commit API parent-count query and got 2.
• 4: Issue Configure Mergify to auto-queue PRs once verify and Unfret pass #100 operator proof comment 5946703987 records the historical ready-PR hold: verify/Unfret passed, no head statuses, Mergify queue neutral with “Waiting for queue conditions to match”, protections showed live-gate unmet. Historical hold is verified from the recorded operator artifact, not reconstructed from now-successful checks.
• 8: The same proof comment records mastra-pilot/MASTRA-749 babysit-pr changing from UNKNOWN before the gate to MERGE_READY immediately afterward, before merge.

Acceptance items 5–7: independently executed in sandbox

R=ericlitman/open-pstack
P=108
S=$(gh pr view $P -R $R --json headRefOid --jq .headRefOid)
gh pr view $P -R $R --json state,mergedBy,mergeCommit,comments --jq '{state, by: .mergedBy.login, manual: [.comments[].body|select(test("@Mergifyio"))]|length}'
gh api repos/$R/commits/$(gh pr view $P -R $R --json mergeCommit --jq .mergeCommit.oid) --jq '.parents|length'
gh pr list -R $R --state all --search "head:mergify/merge-queue" --json number

Actual output (all commands exited 0):

Proof PR 108 head 95eed70a5002286c1a62553a9873be78f06d9411
Acceptance 5:
{"by":"app/mergify","manual":0,"state":"MERGED"}
Acceptance 6:
2
Acceptance 7:
[]

Additional direct API corroboration: on proof head, verify (github-actions), Unfret (unfret-eal), Mergify Merge Protections and Merge Queue all succeeded. live-gate is successful, created at 2026-10-02T06:24:29Z and targets #108 comment 5946633570. Mergify's queue summary explicitly says entry was triggered by merge protections, checks skipped because the PR was already up-to-date, then merge after 10 seconds in queue. Merge occurred 47 seconds after the live-gate post. No manual queue comment and no batch PR were found.

No merge, status, readiness or queue action was performed during this verification. Acceptance is complete; requesting Factory Delivery Done separately.

Findings

None