feat(run): --ready-gate — run the post-QA ready gate inside `sequant run` (automates the any-gaps/fix-gaps second look, stops at human merge)

[admarble]

Context

sequant ready (#683, promoted in #689) reproduces the maintainer's manual fresh-session A+ pass: a policy-bounded qa → loop → qa engine that stops at a human merge gate. Its header comment explicitly designs the next step: "This module is the reusable engine — a future sequant run --ready-gate (out of scope for #683) can reuse runReadyGate directly" (src/lib/workflow/ready-gate.ts:20-22).

Session-log analysis (2026-07-26, 43 driver sessions / 20 issues over Jun 20–Jul 26) quantifies the gap this closes: after essentially every /qa, the maintainer manually types the same triple — a gap probe ("any gaps?"), a fix command ("fix all gaps"), then "merge". 34 of 249 typed messages are literally these strings, and the probe reliably surfaces real defects the first /qa pass accepted (consistent with the recorded 44%-of-second-looks defect rate). The engine that automates exactly this loop already exists; it just isn't reachable from sequant run.

A second dead end this fixes: on the run path, an AC_MET_BUT_NOT_A_PLUS verdict breaks to PR (#749, correctly) and nothing re-drives it — ready --policy a-plus is the intended escalation, but invoking it is manual and requires knowing it exists.

Proposal

An opt-in --ready-gate flag on sequant run that invokes the existing runReadyGate engine after the standard phases succeed, driving the issue to the configured policy threshold (ac default / a-plus) before handing back to the human. Exact sequencing relative to PR creation/finalization is /spec's call; the requirement is only that the run terminates with the PR open, the gate's gap report produced, and the issue in waiting_for_merge-style state — never merged.

Design constraints (strategic, from past failures):

• No inert flag. --qa-gate shipped unwired and had to be deprecated (chore(run): --qa-gate is an inert no-op flag — remove or make it actually gate #795). The flag must be traced end-to-end (bin/cli.ts .option() → RunOptions → ExecutionConfig → batch-executor) with a test that fails if any link is dropped.
• No new policy surface. Reuse ready's existing policy setting and bounds (maxIterations, token budget, LOOP_NO_DIFF stagnation guard, Non-Goals exclusion). Zero new configuration concepts for end users.
• Default off, byte-identical behavior without the flag. Existing users' runs must not get longer or more expensive without opting in.

Acceptance Criteria

• sequant run -Q <issue> --ready-gate invokes the existing runReadyGate engine after the standard phases succeed, and the run terminates with the PR open, the gate report produced, and the persisted status matching sequant ready's terminal semantics — it never merges.
• With --ready-gate, an AC_MET_BUT_NOT_A_PLUS outcome is escalated through the gate per the configured policy instead of dead-ending at PR; without the flag, fix(run): AC_MET_BUT_NOT_A_PLUS QA verdict misrouted into quality loop → fails with no PR (should break to PR) #749 behavior is unchanged.
• The flag is wired end-to-end (bin/cli.ts option → RunOptions → ExecutionConfig → executor) and a test fails if the flag stops reaching the engine (the chore(run): --qa-gate is an inert no-op flag — remove or make it actually gate #795 inert-flag class).
• Gate policy, iteration cap, token budget, stagnation guard, and Non-Goals handling all come from the existing ready machinery; no new flags or settings beyond --ready-gate itself.
• Without the flag, run behavior is unchanged (existing run-path tests still pass unmodified).
• The run summary and PR body surface the gate outcome (threshold reached vs guard halt) the same way sequant ready reports it.
• Documentation covers the flag in the main README, marketplace README, and docs/.

Out of scope

Auto-merge or adding merger to default phases (human merge gate is deliberate policy); MCP exposure of the gate; changing -Q semantics; batch/chain interaction beyond "gate runs per-issue after that issue's phases" (if chain interaction is non-trivial, note it and defer).

References

• src/lib/workflow/ready-gate.ts header — the designed seam this builds
• feat(cli): sequant ready <issue> — post-resolve A+ QA gate that drives an issue to merge-readiness #683 / Promote sequant ready from experimental: Layer-2 backtest + Layer-3 shadow dogfood, meet promotion gate (#683 follow-up) #689 / feat(cli): sequant ready — wire live phase-matrix renderer (parity with sequant run) #697 — ready engine, promotion, TUI parity
• fix(run): AC_MET_BUT_NOT_A_PLUS QA verdict misrouted into quality loop → fails with no PR (should break to PR) #749 — AC_MET_BUT_NOT_A_PLUS breaks to PR (behavior preserved without flag)
• chore(run): --qa-gate is an inert no-op flag — remove or make it actually gate #795 — the inert-flag failure mode the wiring AC guards against

[admarble]

#817 — feat(run): --ready-gate — run the post-QA ready gate inside sequant run (automates the any-gaps/fix-gaps second look, stops at human merge)
Open · enhancement, cli
────────────────────────────────────────────────────────────────

→ PROCEED — The designed seam exists (src/lib/workflow/ready-gate.ts header names this exact flag); nothing wired in bin/cli.ts yet, as expected

Commands:
sequant run 817 -Q

spec → exec → qa · 7 ACs
────────────────────────────────────────────────────────────────
⚠ Land after #820 — the ready-gate's fix loop would otherwise consume the infra-blocked-CI misclassification #820 prevents
────────────────────────────────────────────────────────────────

[admarble]

📋 /spec — Plan Review (#817)

Complexity: Standard (7 ACs, ~4 directories: bin/, src/commands/, src/lib/workflow/, docs/)

AC Quality Check

No vague/unmeasurable ACs. All 7 have concrete, testable outcomes. AC-3 and AC-5 are themselves test-defined (they mandate a guarding test) — exactly the discipline the #795 inert-flag failure demands.

Scope Assessment

Non-Goals: ✅ Present ("Out of scope": auto-merge / merger in default phases, MCP exposure, -Q semantics, non-trivial chain interaction).

Metric	Value	Status
Feature count	1 (opt-in flag reusing an existing engine)	✅
AC items	7	✅
Directory spread	~4 (bin, commands, lib/workflow, docs)	✅

Verdict: ✅ SCOPE_OK — no new surface; the flag delegates entirely to runReadyGate.

Dependency: ⚠️ assess flagged "land after #820" (infra-blocked-CI misclassification). #820 is CLOSED/merged (commit 4c258a6) — dependency satisfied, safe to proceed.

---

Acceptance Criteria & Verification

AC-1 — Gate invoked post-phases; PR open; status = terminal; never merges.
Integration. Given phases succeed for a run with --ready-gate → When the executor reaches the PR seam → Then runReadyGate runs against the worktree, the PR is created, persisted status = waiting_for_human_merge (or blocked on guard halt), and no merge is performed.

AC-2 — AC_MET_BUT_NOT_A_PLUS escalated with flag; #749 preserved without it.
Integration. With flag: a non-A+ verdict drives the gate per policy instead of dead-ending at PR. Without flag: verdict is surfaced in PR body only (#749), unchanged.

AC-3 — Flag wired end-to-end; test fails if it stops reaching the engine.
Unit + Integration. Trace bin/cli.ts .option → RunOptions.readyGate → ExecutionConfig.readyGate → batch-executor → runReadyGate. A dead-surface/wiring test (mirror run-options-dead-surface.test.ts) fails if any link drops.

AC-4 — Policy, iteration cap, token budget, stagnation guard, Non-Goals all from ready machinery; no new flags/settings.
Unit. Assert runReadyGate is called with policy ← settings.ready.policy, maxIterations ← config.maxIterations, tokenBudget ← undefined (parity with ready sans --budget); stagnation + Non-Goals are internal to runReadyGate. Assert no CLI option added beyond --ready-gate.

AC-5 — Without the flag, run behavior byte-identical; existing run-path tests pass unmodified.
Integration (regression). Existing batch-executor suite runs green with no edits; gate code is gated behind config.readyGate.

AC-6 — Run summary + PR body surface the gate outcome as ready does (threshold reached vs guard halt).
Integration. Reuse formatReadyReport output; assert the PR body and end-of-run summary carry the stop-reason/headline.

AC-7 — Docs in main README, marketplace README, and docs/.
Manual/Docs. Verify content coverage (flag purpose, opt-in, never-merges) in all three locations — not just file existence.

---

Implementation Plan

Phase 1 — Wire the flag (AC-3, AC-4)

1. bin/cli.ts: add .option("--ready-gate", "After phases succeed, run the post-QA ready gate — never merges") to the run command.
2. src/lib/workflow/types.ts: add readyGate?: boolean to RunOptions and ExecutionConfig (with behavior-promising doc comments so the dead-surface guard has a declaration to see).
3. src/lib/workflow/config-resolver.ts: map RunOptions.readyGate → ExecutionConfig.readyGate in the return object.

Phase 2 — Invoke the engine at the PR seam (AC-1, AC-2, AC-6)
4. src/lib/workflow/batch-executor.ts (executeIssue): when success && config.readyGate, before rebaseBeforePR/createPR, call runReadyGate({ worktreePath, policy: settings.ready.policy, maxIterations: config.maxIterations, tokenBudget: undefined, nonGoals: parseNonGoals(body), phaseTimeout: config.phaseTimeout, mcp: config.mcp, verbose, runPhase, onProgress }). Placing it before rebase/PR ensures the gate's auto-fix commits land in the PR.
5. Feed the gate outcome into createPR (extend the existing qaVerdict argument path) and into the end-of-run summary via formatReadyReport.
6. Persist result.issueStatus from the gate (waiting_for_human_merge / blocked) — never merge.

Phase 3 — Tests & docs (AC-3, AC-5, AC-7)
7. Wiring test (dead-surface + call-args) and behavior tests for AC-1/AC-2/AC-6; confirm the existing suite passes unmodified (AC-5).
8. Docs: main README, marketplace README, docs/.

---

Rule Touchpoints

The behavior-rule heuristic triggered on AC-4 (default,behavior) and AC-5 (default,never,behavior), but every reported touchpoint is the detector's own doc/skill text — false positives. Unlike #533 (a rule duplicated in a SKILL.md prompt), --ready-gate is pure runtime CLI behavior with no LLM-interpreted duplicate, so the sole genuine touchpoint is the runtime seam:

AC	Touchpoint	Snippet
AC-4/5	src/lib/workflow/batch-executor.ts (PR seam)	if (success && config.readyGate) { runReadyGate(...) }

The real hazard here is the inverse of #533 — a dropped single wire (the #795 class), which AC-3's end-to-end test guards directly.

---

Design Review

1. Where does this logic belong? The invocation belongs in batch-executor.executeIssue at the existing post-success / pre-PR seam; the engine (runReadyGate) already exists — the header at ready-gate.ts:20-22 designed this exact reuse. No engine changes.
2. Simplest correct approach? Delegate wholesale to runReadyGate with args sourced from existing settings/config. Rejected: a run-specific gate re-implementation (duplicates the engine, violates AC-4).
3. Existing pattern? Mirrors src/commands/ready.ts's runReadyGate call site (worktree resolution, Non-Goals parse, runPhase = executePhaseWithRetry wrapper, onProgress). Flag-tracing mirrors --auto-wait/autoWaitMinutes through config-resolver.
4. Senior reviewer pushback? "Why before PR creation?" → so the gate's auto-fix commits are included in the PR (the whole point). "Why no --budget/--policy on run?" → AC-4 forbids new surface; policy comes from settings.ready.policy, budget stays disabled as ready does without --budget.

---

Open Questions

1. Chain / -Q interaction — Recommendation: run the gate per-issue at the executeIssue seam (naturally per-issue, in scope). Chain-level coordination is explicitly out of scope; if non-trivial interaction surfaces during exec, note and defer. Impact if wrong: a chained run could gate mid-stack — but the seam is per-issue, so this is contained.
2. Token budget source — Recommendation: leave tokenBudget undefined on the run path (parity with ready sans --budget); the maxIterations cap already bounds cost. Impact: an unbounded-token gate is still iteration-capped, so acceptable.

---

Recommended Workflow

Phases: spec → exec → qa  ·  Quality Loop: enabled

Reasoning: Matches the prior /assess recommendation (spec,exec,qa, quality-loop=true). Considered adding testgen since AC-1/2/3/6 are Integration-verified and AC-3/AC-5 are test-defined — but the guarding tests here are tightly coupled to the wiring (dead-surface + call-args) and are best hand-authored alongside the seam rather than pre-stubbed. Recommend authoring them inline during exec. No test/browser phase (CLI-only). No security-review (no auth/payments/file-ops surface).

---

Label Review

Current: enhancement, cli
Recommended: add planned. Keep enhancement, cli.
Quality Loop: enabled — a test-heavy, wiring-critical AC set benefits from the loop catching regressions.

[admarble]

Complexity: Standard (7 ACs, ~4 directories)

AC Quality Check

Programmatic lint N/A — the issue's ACs are unlabeled checkboxes (- [ ] …), so the AC-N:-anchored parser returns 0. Numbered AC-1…AC-7 inline below. Text quality is strong (measurable, scoped, each ties to a named failure mode). One residual ambiguity flagged as an Open Question: AC-2's word "escalated" under the default ac policy.

---

Scope Assessment

Non-Goals: Present and specific — auto-merge / merger in default phases, MCP exposure, -Q semantic changes, non-trivial batch/chain interaction (defer-and-note).

Metric	Value	Status
Feature count	1 (one opt-in flag reusing an existing engine)	✅
AC items	7	✅
Directory spread	bin/, src/lib/workflow/, README + docs/ (~4)	✅

Verdict: ✅ SCOPE_OK — pure wiring of an already-shipped engine (runReadyGate); zero new engine/policy code.

---

Acceptance Criteria

AC-1: run --ready-gate invokes runReadyGate after phases succeed; terminates PR-open, gap-report produced, ready-terminal status, never merges

Verification: Integration Test
Scenario: Given sequant run <n> --ready-gate on an issue whose standard phases pass → When the run finishes → Then runReadyGate ran, a PR is open, persisted status is waiting_for_human_merge/blocked (not ready_for_merge), and no merge occurred.

AC-2: With flag, AC_MET_BUT_NOT_A_PLUS is escalated through the gate per policy; without flag, #749 behavior unchanged

Verification: Integration Test
Scenario: Given a QA verdict of AC_MET_BUT_NOT_A_PLUS → When run with --ready-gate → Then the gate re-drives per policy; When run without → Then it breaks to PR with the verdict surfaced (#749), unchanged.
⚠️ See Open Question 1 — under the default ac policy, isAtThreshold('ac', 'AC_MET_BUT_NOT_A_PLUS') is already true (ready-gate.ts:151), so "escalation" = a fresh full-weight QA second look (which can downgrade to AC_NOT_MET and then loop-fix), not an auto-A+ push. Only a-plus policy drives to READY_FOR_MERGE.

AC-3: Flag wired end-to-end (bin/cli.ts → RunOptions → ExecutionConfig → executor); a test fails if the flag stops reaching the engine

Verification: Unit + Integration Test
Scenario: Given the flag set → When resolved → Then it reaches the gate call site; a spy/injection test asserts the gate is invoked iff the flag is set, and the run-options-dead-surface guard is extended so readyGate can't go inert like --qa-gate (#795).

AC-4: Policy, iteration cap, token budget, stagnation guard, Non-Goals all come from existing ready machinery; no new flags/settings beyond --ready-gate

Verification: Integration Test
Scenario: Given --ready-gate with no other new options → When the gate runs → Then policy = settings.ready.policy, maxIterations/tokenBudget/phaseTimeout/mcp come from the resolved run config, and Non-Goals are parsed from the issue body (mirror ready.ts:101-136). No new settings key, no new CLI option.

AC-5: Without the flag, run behavior is byte-identical (existing run-path tests pass unmodified)

Verification: Integration Test (regression)
Scenario: Given no --ready-gate → When the run executes → Then the gate branch is never entered and every existing batch-executor/run-orchestrator test passes without edits.

AC-6: Run summary and PR body surface the gate outcome the same way sequant ready reports it

Verification: Integration Test
Scenario: Given a completed gate → When the summary + PR body render → Then the terminal reason (threshold reached vs guard halt: MAX_ITERATIONS/TOKEN_BUDGET/stagnation) is shown consistently with ready's report headline.

AC-7: Documentation in main README, marketplace README, and docs/

Verification: Manual Test (docs coverage — verify content, not file existence)
Scenario: Given the flag ships → When docs are checked → Then README.md, the marketplace/plugin README (source of dist/marketplace/external_plugins/sequant/README.md — locate the committed source during exec), and a docs/features/ entry all document --ready-gate, its default-off semantics, and the never-merges guarantee.

---

Implementation Plan

Phase 1: Wire the flag (the #795-guarded seam)

1. bin/cli.ts run command: add .option("--ready-gate", "Run the post-QA ready gate before handing back to the human (never merges)").
2. src/lib/workflow/types.ts: add readyGate?: boolean to RunOptions and to ExecutionConfig (both, with intent-stating doc comments).
3. RunOrchestrator.resolveConfig (run-orchestrator.ts): map options.readyGate → config.readyGate; propagate into the run-log config schema next to qaGate for observability.

Phase 2: Invoke the gate at the per-issue seam

4. runIssueWithLogging (batch-executor.ts): after const success = completedSuccessfully (~L1317) and before PR creation (~L1382), add a guarded block: if (config.readyGate && success && worktreePath) { … }. Build a runPhase wrapper via executePhaseWithRetry (mirror ready.ts:208-217), parse Non-Goals from the issue body, resolve policy/bounds from settings+config, call runReadyGate, then set the persisted status to the gate's terminal status instead of ready_for_merge. PR creation then runs against the gate-improved worktree.
5. Ensure the returned IssueResult carries the gate outcome so the summary/PR body (AC-6) can render it; reuse ReadyResult.report/reason.

Phase 3: Surface + document

6. Thread the gate outcome into displaySummary (run-display.ts) and the PR body (extend the fix(run): AC_MET_BUT_NOT_A_PLUS QA verdict misrouted into quality loop → fails with no PR (should break to PR) #749 qaVerdict surfacing in createPR).
7. Docs in all three locations (AC-7).

Key decision — where the gate fires: Before PR creation (recommended) so the PR reflects gate-improved state and opens once. Alternative (after PR creation, then update) means an extra PR-body edit and a transient ready_for_merge status. Recommend before-PR.

---

Rule Touchpoints

The "default off / never merges / unchanged without the flag" rule lands at multiple sites — enumerate so none goes stale (motivating miss: #533):

AC	Touchpoint	Note
AC-3/5	bin/cli.ts run .option("--ready-gate")	default off (flag absent → undefined)
AC-3	types.ts RunOptions + ExecutionConfig	declaration must be non-inert (dead-surface guard)
AC-3	run-orchestrator.ts resolveConfig	RunOptions → ExecutionConfig mapping
AC-1/4/5	batch-executor.ts runIssueWithLogging gate block	the only behavioral consumer; guarded by config.readyGate
AC-1	ready-gate.ts engine	"never merges" already enforced here — reuse, don't re-implement

---

Design Review

1. Where does this logic belong? The engine (runReadyGate) already exists; the only new logic is a guarded call inside runIssueWithLogging, plus the flag plumbing. No new module.
2. Simplest correct approach? A single guarded block at the existing success→PR seam, reusing ready.ts's runPhase/Non-Goals/policy resolution verbatim. Rejected: a new orchestrator phase (over-engineered; the gate owns its own qa→loop→qa loop).
3. Existing pattern? ready.ts's driver (L101-233) is the template — lift its config resolution into a shared helper if it keeps run.ts/ready.ts DRY.
4. What would a senior reviewer challenge? (a) "Does the default ac policy actually escalate AC_MET_BUT_NOT_A_PLUS, or no-op?" → answer in Open Q1. (b) Chain/batch interaction — Non-Goals says gate runs per-issue after that issue's phases; confirm the seam is per-issue (it is — inside runIssueWithLogging) and note if chain adds anything non-trivial.

---

Feature Quality Planning

All standard checks pass. Notable items:

• Inert-flag guard (AC-3) is the highest-risk item — extend run-options-dead-surface.test.ts AND add a behavioral spy test; the source-text guard alone doesn't prove the flag reaches the engine.
• Status semantics: the gate must overwrite ready_for_merge with waiting_for_human_merge/blocked; verify write-ordering vs PR creation.
• Cleanup on all exit paths if the gate throws mid-run (ready.ts already models this at L234-251).

---

Open Questions

1. AC-2 "escalated" under default ac policy. Under ac, AC_MET_BUT_NOT_A_PLUS is already at threshold, so the gate's value is a fresh full-weight QA second look (the 44%-defect-catch), not an auto-A+ push; only a-plus drives to READY_FOR_MERGE. Recommendation: implement as-is (reuse policy semantics unchanged) and make the summary wording distinguish "gate re-verified, ACs hold" from "gate drove to A+". Impact if unaddressed: reviewers may expect --ready-gate alone to reach A+ and be surprised it stops at AC-met.
2. Marketplace README source. Locate the committed source for dist/marketplace/external_plugins/sequant/README.md during exec (generated artifact — don't edit dist).

---

Recommended Workflow

Phases: spec → testgen → exec → qa
Quality Loop: enabled
Reasoning: Enhancement with 7 ACs dominated by Integration/Unit-Test verification (esp. the AC-3 wiring guard) → testgen stubs the wiring + regression tests before exec. Quality loop matches the prior /assess (quality-loop=true). Blocker #820 is now closed/merged (via #828), so the assess "land after #820" caveat is cleared. No UI surface → no test phase. Not security-sensitive → no security-review.

---

Label Review

Current: enhancement, planned, cli
Recommended: unchanged
Reason: labels already match — CLI enhancement, planning complete.
Quality Loop: will run (assess set quality-loop=true; wiring + regression benefit from the loop).

[admarble]

✅ /exec — Implementation complete (#817)

PR: #832

Opt-in --ready-gate on sequant run now invokes the existing runReadyGate engine after an issue's standard phases succeed, driving it to settings.ready.policy before the PR opens (so the gate's fixes land in it), then stops at the human merge gate — it never merges.

AC coverage

AC	Status
AC-1 Gate invoked post-phases; PR open; ready-terminal status; never merges	✅
AC-2 With flag, AC_MET_BUT_NOT_A_PLUS escalates; without flag, #749 preserved	✅
AC-3 Flag wired end-to-end; guarded test fails if it stops reaching the engine	✅
AC-4 Policy/cap/budget/stagnation/Non-Goals from ready; no new settings	✅
AC-5 Without the flag, run behavior byte-identical (existing tests unmodified)	✅
AC-6 Summary + PR body surface the gate outcome as ready does	✅
AC-7 Docs: main README, marketplace README, docs/	✅

Key files changed

• bin/cli.ts — .option("--ready-gate", …)
• src/lib/workflow/types.ts — readyGate on RunOptions + ExecutionConfig; readyGate: ReadyResult on IssueResult
• src/lib/workflow/config-resolver.ts — maps mergedOptions.readyGate → ExecutionConfig.readyGate
• src/lib/workflow/batch-executor.ts — runReadyGateForIssue helper + gate invocation at the post-success/pre-PR seam; persists gate terminal status
• src/lib/workflow/worktree-manager.ts — gate report surfaced in the PR body (prefers it over the standalone fix(run): AC_MET_BUT_NOT_A_PLUS QA verdict misrouted into quality loop → fails with no PR (should break to PR) #749 note)
• src/commands/run-display.ts — per-issue gate outcome in the run summary
• Docs: README.md, scripts/prepare-marketplace.ts, docs/reference/run-command.md, docs/features/run-ready-gate.md
• Tests: ready-gate-run.test.ts (behavioral wiring), run-options-dead-surface.test.ts (live-surface guard), worktree-manager.build-pr-body.test.ts, run-display.test.ts

Checks

• npm run build ✅ · npm run lint ✅ · touched suites green (existing batch-executor.test.ts unmodified — AC-5 regression)

Quality Plan Alignment

Dimension	Notes
Inert-flag guard (highest risk)	Source-level live-surface test and behavioral spy test both added
Status write ordering	Gate status overwrites ready_for_merge before PR creation; verified by test
Cleanup on all exit paths	Gate failure is non-fatal — logs a warning and continues to PR

Notes / deferred

• Chain interaction is contained to the per-issue seam (per Non-Goals); no chain-level coordination added.
• Open Question 1 (AC-2 wording under default ac policy) is documented in docs/features/run-ready-gate.md: under ac, the gate's value is a fresh second look, not an auto-A+ push (set ready.policy: a-plus for that).

[admarble]

QA Review for Issue #817

AC Coverage

AC	Source	Description	Status	Notes
AC-1	Original	Gate invoked post-phases; PR open; ready-terminal status; never merges	✅ MET	batch-executor.ts:1462 runs the gate before checkpoint/rebase/PR; persists readyGateResult.issueStatus (waiting_for_human_merge/blocked), never ready_for_merge. updatePRInfo doesn't touch status, so the terminal status survives PR creation. No merge call exists.
AC-2	Original	With flag, AC_MET_BUT_NOT_A_PLUS escalated; without flag #749 preserved	✅ MET	Verified phase-executor.ts:754: only AC_NOT_MET/null hard-fail, so AC_MET_BUT_NOT_A_PLUS → success:true → reaches the gate. Without the flag the gate block is skipped and the #749 PR-body note is emitted.
AC-3	Original	Flag wired end-to-end; a test fails if it stops reaching the engine	✅ MET	bin/cli.ts .option → RunOptions → ExecutionConfig → config-resolver → batch-executor → runReadyGate. Guarded by the live-surface source test + behavioral ready-gate-run.test.ts. See coverage note below.
AC-4	Original	Policy/cap/budget/stagnation/Non-Goals from ready; no new flags/settings	✅ MET	runReadyGateForIssue sources policy ← settings.ready.policy, maxIterations ← config, tokenBudget: undefined, Non-Goals parsed from the body. Only --ready-gate added; no new settings key. Asserted in ready-gate-run.test.ts "AC-4".
AC-5	Original	Without the flag, byte-identical; existing tests pass unmodified	✅ MET	Gate gated behind config.readyGate; existing batch-executor.test.ts passes unmodified. Flag-off assertion in the wiring test.
AC-6	Original	Summary + PR body surface the gate outcome as ready does	✅ MET	buildAutomatedPRBody embeds readyGateResult.report (and suppresses the standalone #749 note to avoid a double headline); run-display.ts renders the per-issue outcome. Tests in worktree-manager.build-pr-body.test.ts + run-display.test.ts.
AC-7	Original	Docs in main README, marketplace README, and docs/	✅ MET	Content coverage (never-merges / opt-in / off-by-default) verified in README.md, scripts/prepare-marketplace.ts (marketplace README source), docs/reference/run-command.md, and docs/features/run-ready-gate.md.

Coverage: 7/7 AC items fully met.

---

CI Status

Check	State	Impact
build (22.x)	SUCCESS	✅ MET
typecheck	SUCCESS	✅ MET
node-floor-guard	SUCCESS	✅ MET
validate-plugin	SUCCESS	✅ MET
validate-skills	SUCCESS	✅ MET

CI Summary: 5 passed, 0 pending, 0 failed (PR #832).

---

Quality Metrics

Metric	Value	Status
Type issues (any/as any in src)	0	OK
Deleted tests	0	OK
Files changed	15	OK
Lines added / deleted	+753 / -7	- (mostly tests + docs)
npm run build / npm run lint	pass / pass (0 warnings)	OK

---

Test Coverage Analysis

Changed source file	Has Tests?	Test File
batch-executor.ts	✅ Yes	ready-gate-run.test.ts (behavioral) + unmodified batch-executor.test.ts
worktree-manager.ts	✅ Yes	worktree-manager.build-pr-body.test.ts
run-display.ts	✅ Yes	run-display.test.ts
types.ts	✅ Yes (types + dead-surface guard)	run-options-dead-surface.test.ts
config-resolver.ts	⚠️ Source-grep only	run-options-dead-surface.test.ts asserts the mapping string; no behavioral resolver test
bin/cli.ts	Verified via run --help	-

Touched suites: 118 tests, all green.

---

CLI Registration Verification

Interface Field	Runtime Usage	CLI Registered	Status
readyGate (RunOptions + ExecutionConfig)	mergedOptions.readyGate (config-resolver) → config.readyGate (batch-executor)	--ready-gate in bin/cli.ts (confirmed via run --help)	✅ OK

Verification Status: Passed.

---

Code Review

Strengths:

• Clean delegation — the gate invocation is a single guarded call at the correct post-success/pre-PR seam; the engine (runReadyGate) is reused wholesale, no engine changes.
• Status write ordering is correct: the gate's terminal status is written before PR creation and updatePRInfo never overwrites it, so the never-merge contract holds.
• Gate failure is non-fatal (try/catch → log + fall through to PR), so a gate error can't abandon committed work.
• buildAutomatedPRBody correctly prefers the gate report over the standalone fix(run): AC_MET_BUT_NOT_A_PLUS QA verdict misrouted into quality loop → fails with no PR (should break to PR) #749 note, avoiding a contradictory double headline.

Issues: None blocking.

Suggestions (non-blocking):

1. Add a behavioral config-resolver test asserting buildExecutionConfig({readyGate:true}, …).readyGate === true. The resolver→config link is currently guarded only by a source-grep in the dead-surface test — a stronger end-to-end guard than a string match.

---

Risk Assessment

• Likely failure mode: sequant run --chain --ready-gate resume re-executes already-gated links. A gated chain link terminates as waiting_for_human_merge/blocked, but chain-resume.ts COMPLETED_STATUSES = {ready_for_merge, merged} — so on resume the link is treated as incomplete and re-run from scratch (wasteful, not incorrect). Relatedly, the chain checkpoint-failure warning message still says "stays ready_for_merge", which is inaccurate for a gated link.
• Not tested: the config-resolver mapping (behavioral); chain + ready-gate interaction (out of scope per Non-Goals).
• Sibling sites considered: none — runIssueWithLogging is the sole per-issue run-path PR seam; sequant ready (the other runReadyGate caller) already owns the gate. No cross-file sibling requiring the same change.
• Sibling-line audit: none — single call site of the new gate helper, correctly guarded by config.readyGate && success && worktreePath.

---

Adversarial Re-Read

Findings: Non-Goals are respected (no auto-merge, no merger in default phases, no MCP surface, -Q unchanged). No motivating-example fixtures in the issue body to run (feature spec, not a bug repro). No evidence-claim-as-bug-repro. Process state clean (HEAD pushed, no uncommitted work, 0 behind main). One real gap surfaced: the chain + ready-gate resume interaction above — a gated chain link isn't in COMPLETED_STATUSES, so resume re-runs it and the checkpoint-failure message is inaccurate for gated runs. This falls inside the explicitly-deferred chain Non-Goal and the docs note that chain coordination is out of scope, but the specific resume-redo consequence is worth a tracked follow-up.

Status: Gaps Found

---

CHANGELOG Verification

Check	Status
CHANGELOG.md exists	✅
User-facing (feat)	✅
[Unreleased] entry with issue number	✅ (#817)

Result: CHANGELOG requirements met.

---

Verdict: AC_MET_BUT_NOT_A_PLUS

All 7 ACs are objectively MET, CI is green, and the single-issue run --ready-gate feature is well-tested and mergeable. Two meaningful, non-blocking improvements keep it from A+: (1) the --chain --ready-gate resume-redo interaction (deferred Non-Goal, but worth a follow-up issue so the surprise is tracked), and (2) a behavioral config-resolver test to harden the AC-3 wire beyond a source grep. This is a break-to-PR verdict — do not run /loop (the ACs hold; these are follow-ups, not gaps in the AC contract).

Documentation

• README updated
• docs/ updated (reference + features)
• CHANGELOG entry added
• Before merging: optionally run /docs 817.

Next Steps

1. Merge PR feat(#817): --ready-gate — run the post-QA ready gate inside sequant run #832 when ready (human merge gate — the feature's whole point).
2. File a follow-up issue: chain + --ready-gate resume treats gated links (waiting_for_human_merge/blocked) as incomplete → re-executes on resume; also correct the checkpoint-failure warning text for gated runs.
3. (Optional) Add a behavioral config-resolver test for the readyGate mapping.

[admarble]

QA Review for Issue #817 (fresh second look @ 56bc3c2)

Re-run at the same SHA as the prior QA (which short-circuits by default). Done deliberately as a fresh-session adversarial pass on an AC_MET_BUT_NOT_A_PLUS verdict — and this time AC-3's guard was mutation-tested rather than read. It does not hold.

AC Coverage

AC	Source	Description	Status	Notes
AC-1	Original	Gate invoked post-phases; PR open; ready-terminal status; never merges	MET	Ordering verified in source: gate batch-executor.ts:1464 → checkpoint :1502 → rebase :1532 → PR :1558. Terminal status comes from readyGateResult.issueStatus, which ready-gate.ts finish() constrains to waiting_for_human_merge | blocked — ready_for_merge is unreachable on the gated path. No merge call exists anywhere in the seam.
AC-2	Original	With flag, AC_MET_BUT_NOT_A_PLUS escalated per policy; without flag #749 unchanged	MET	Traced: phase-executor.ts:754 hard-fails only on AC_NOT_MET, so an AC_MET_BUT_NOT_A_PLUS qa returns success: true → phasesFailed false → completedSuccessfully true → the gate's success guard passes and the gate runs. The ac-policy caveat (at threshold already, so the value is the fresh second look, not an auto-push to A+) is explicitly documented in docs/features/run-ready-gate.md.
AC-3	Original	Flag wired end-to-end (cli → RunOptions → ExecutionConfig → executor) and a test fails if the flag stops reaching the engine (#795 inert-flag class)	PARTIALLY_MET	Wiring clause: MET (proven by execution, below). Test clause: not met for the load-bearing link. See Mutation Testing.
AC-4	Original	Policy, iteration cap, budget, stagnation guard, Non-Goals all from existing ready machinery; no new flags/settings	MET	runReadyGateForIssue takes policy from settings.ready.policy (same source as ready.ts:103), cap from config.maxIterations, tokenBudget: undefined (parity with ready sans --budget), Non-Goals via parseNonGoals, stagnation guard internal to the engine. fullQa: true is set inside buildPhaseConfig, so the run path inherits full-weight QA without re-plumbing it. Only --ready-gate was added.
AC-5	Original	Without the flag, run behavior unchanged; existing run-path tests pass unmodified	MET	The block is a single ternary on config.readyGate; resolver defaults it to false. Verified behaviorally: buildExecutionConfig({}, settings, 1).readyGate === false. batch-executor.test.ts untouched in the diff.
AC-6	Original	Run summary and PR body surface the gate outcome the same way ready does	MET	run-display.ts:212-229 renders reason/policy/iterations/status per gated issue; buildAutomatedPRBody prefers readyGateReport over the #749 note (avoiding a contradictory double headline). Both covered by tests.
AC-7	Original	Documentation in main README, marketplace README, and docs/	MET	README.md:25; marketplace README section added via scripts/prepare-marketplace.ts:389-401; docs/reference/run-command.md:68,252; docs/features/run-ready-gate.md (new). All three locations present, with real content — not just a flag-table row.

Coverage: 6/7 fully met · Original ACs: 6/7 · Derived ACs: none in the spec comment.

---

Mutation Testing (AC-3) — the finding

CLAUDE.md now requires gate tests to ship mutation-verified ("a test whose job is to gate a claim — a flag is wired — must be mutation-verified… delete the thing it asserts, confirm exactly that test fails"). AC-3 is that kind of AC, so I ran the mutations instead of reading the tests. Baseline: 35 tests green across the four #817 suites.

#	Mutation	Compiles?	Result	Verdict
1	Delete .option("--ready-gate", …) from bin/cli.ts	✅ (tsc clean)	91 tests still pass. But run 999 --ready-gate then errors unknown option '--ready-gate'	Unguarded, but self-detecting — loud failure, low severity
2	readyGate: mergedOptions.readyGate → mergedOptions.readyGate && false in config-resolver.ts	✅	145 tests still pass (78 in the #817/ready suites + 67 in __tests__/config-resolver.test.ts)	❌ The exact #795 silent-inert class, undetected
3	config.readyGate → config.fullQa at the executor call site	✅	4 tests fail (behavioral + source guards)	✅ Well guarded

Mutation 2 is the defect. The flag parses, RunOptions.readyGate is set, and --ready-gate silently does nothing — the entire test suite stays green. The source-level guard in run-options-dead-surface.test.ts:194 asserts only the substring /readyGate:\s*mergedOptions\.readyGate/, which the mutation preserves verbatim. That is the unscoped-file-read failure class CLAUDE.md calls out, applied to the one link config-resolver.ts:259's own comment calls "the load-bearing wire the #795 inert-flag class guards against."

AC-3's text is literal: "a test fails if the flag stops reaching the engine." Under mutation 2 the flag stops reaching the engine and no test fails. → PARTIALLY_MET.

The repo already has the pattern, from three PRs ago. --auto-wait (#804) ships in src/lib/workflow/auto-wait.test.ts:658 a test literally named "the CLI flag reaches ExecutionConfig", plus :665 "Commander's autoWait key maps onto autoWaitMinutes end-to-end" driving resolveRunOptions → buildExecutionConfig. Those two tests close mutations 2 and 1 respectively. #817 — whose AC mandates the guard — ships a substring grep instead.

Fix (small, ~12 lines, in __tests__/config-resolver.test.ts):

it("the --ready-gate flag reaches ExecutionConfig", () => {
  expect(buildExecutionConfig({ readyGate: true }, settings, 1).readyGate).toBe(true);
});
it("readyGate defaults to false without the flag (AC-5)", () => {
  expect(buildExecutionConfig({}, settings, 1).readyGate).toBe(false);
});
it("Commander's `readyGate` key survives resolveRunOptions end-to-end", () => {
  const resolved = resolveRunOptions({ readyGate: true }, settings);
  expect(buildExecutionConfig(resolved, settings, 1).readyGate).toBe(true);
});

Then re-run mutation 2 and record the result in the PR body per the new CLAUDE.md rule.

Fairness note: the CLAUDE.md mutation-record rule postdates this branch, so the missing record is a new-standard artifact, not a regression by this PR. The missing test is not — AC-3 demanded it independently, before the rule existed.

---

Execution Evidence

The wire itself works today; only its guard is missing. Verified directly, not inferred:

Check	Command	Result
Flag registered	npx tsx bin/cli.ts run --help	✅ --ready-gate After phases succeed, run the post-QA ready gate…
Flag → ExecutionConfig	buildExecutionConfig({readyGate:true}, settings, 1).readyGate	✅ true
Absent flag → off (AC-5)	buildExecutionConfig({}, settings, 1).readyGate	✅ false
Live settings	settings.ready.policy / settings.run.maxIterations	ac / 3
Suites	4 × #817 suites	✅ 35 passed
Typecheck	npx tsc --noEmit	✅ exit 0

Evidence status: Complete. Worktree restored to clean 56bc3c2 after all mutations (git status --porcelain empty, baseline re-verified green).

---

CI Status

Check	State	Bucket	Impact
typecheck	SUCCESS	pass	✅ MET
build (22.x)	SUCCESS	pass	✅ MET
validate-skills	SUCCESS	pass	✅ MET
validate-plugin	SUCCESS	pass	✅ MET
node-floor-guard	SUCCESS	pass	✅ MET

CI Summary: 5 passed, 0 pending, 0 failed. Not infra-blocked. No CI-dependent AC is gated.

---

Stale Branch Check

Check	Value
Commits behind origin/main	2
Threshold	5
Status	⚠️ Warning (advisory only)

---

Quality Metrics

Metric	Value	Status
Type issues (any)	0	OK
Deleted tests	0	OK
Files changed	15	OK
Lines added	+753	OK
Lines deleted	-7	OK
Test-to-source ratio	~396 test lines / ~250 source lines	OK

---

Test Coverage Analysis

Changed File	Tier	Has Tests?	Test File
src/lib/workflow/batch-executor.ts	Standard	✅ Yes	ready-gate-run.test.ts (behavioral, mutation-confirmed)
src/lib/workflow/worktree-manager.ts	Standard	✅ Yes	worktree-manager.build-pr-body.test.ts
src/commands/run-display.ts	Standard	✅ Yes	run-display.test.ts
src/lib/workflow/types.ts	Optional	✅ Yes	run-options-dead-surface.test.ts (declaration guard)
src/lib/workflow/config-resolver.ts	Standard	⚠️ Source-grep only	no behavioral assertion — the AC-3 gap
bin/cli.ts	Standard	⚠️ No	self-detecting (unknown option)
scripts/prepare-marketplace.ts	Optional	⚠️ No	doc generator, acceptable

Coverage: 4/7 changed source files have behavioral tests. Critical paths without tests: none security-sensitive; the one that matters is config-resolver.ts.

---

Code Review

Strengths:

• The gate invocation is a single guarded ternary at exactly the right seam — post-success, pre-checkpoint — so the fix loop's commits land in the PR that opens. Ordering claim verified against line numbers, not taken on trust.
• runReadyGateForIssue takes a flat primitive arg bag with injectable runGate / getSettingsFn / fetchBody, which is why the behavioral test can drive runIssueWithLogging end-to-end without shelling out to gh.
• Status-write ordering is right: the gate's terminal status is written before PR creation and updatePRInfo doesn't overwrite it, so the never-merge contract survives the PR step.
• Gate failure is non-fatal (try/catch → warn → fall through to PR), so a gate crash can't strand committed work.
• fullQa is set inside the engine's buildPhaseConfig, not at the call site — the run path inherits full-weight QA for free and can't drift from sequant ready.
• Docs are unusually honest: the ac-policy caveat ("the gate's value there is the fresh second look… rather than an automatic push to A+") pre-empts the obvious user surprise.

Issues:

1. (AC-3, blocking) The config-resolver link is guarded by a substring match that a behavior-preserving mutation defeats. Detailed above.

Suggestions (non-blocking):

1. On the gate-failure path, finalStatus falls back to ready_for_merge — the pre-feat(run): --ready-gate — run the post-QA ready gate inside sequant run (automates the any-gaps/fix-gaps second look, stops at human merge) #817 value — after a warning log. That is the documented intent, but it means a gate crash leaves the issue looking gate-approved. Consider blocked instead, so a crashed gate can't read as a passed one.
2. Chain + --ready-gate resume: a gated link terminates waiting_for_human_merge/blocked, neither of which is in chain-resume.ts's COMPLETED_STATUSES — resume re-runs it from scratch. Wasteful, not incorrect, and inside the explicit chain Non-Goal. Worth a tracked follow-up.

---

Test Quality Review

Category	Status	Notes
Behavior vs Implementation	⚠️ WARN	ready-gate-run.test.ts is genuinely behavioral (mutation 3 kills it). The run-options-dead-surface.test.ts additions are source-string assertions — mutation 2 walks past them.
Coverage Depth	✅ OK	Flag-on and flag-off both asserted; runReadyGate args asserted (AC-4); PR body and summary both covered.
Mock Hygiene	⚠️ WARN	8 modules mocked in ready-gate-run.test.ts. Justified for a wiring test through runIssueWithLogging, but it is at the edge of over-mocking.
Test Reliability	✅ OK	No timing dependencies; deterministic.

---

Anti-Pattern Detection

Dependency Audit

N/A — package.json not modified.

Code Patterns

No hardcoded secrets, no SQL concatenation, no 0.0.0.0 bind, no empty catch (the one catch logs a warning and returns undefined deliberately), no uncleared timers, no await-in-loop introduced by this diff.

Critical Issues: 0 · Warnings: 0

---

Call-Site Review

New exported functions detected: 0 — runReadyGateForIssue is module-private (single call site at batch-executor.ts:1464, correctly guarded by config.readyGate && success && worktreePath). buildAutomatedPRBody / createPR gained optional params; both call sites updated and covered.

---

CLI Registration Verification

Interface Field	Runtime Usage	CLI Registered	Status
readyGate (RunOptions → ExecutionConfig)	mergedOptions.readyGate → config.readyGate	--ready-gate in bin/cli.ts (confirmed via run --help)	✅ OK

Verification Status: Passed — the registration exists. The gap is the missing test for the link below it, scored under AC-3.

---

Skill Command Verification

N/A — no .claude/skills/**/*.md files changed.

Detection Pattern Verification

N/A — no skill-markdown regex/grep/awk/jq/sed changes in the diff.

Smoke Test

Test	Command	Result	Notes
Happy path	npx tsx bin/cli.ts run --help	✅	Flag present with correct description
Wiring	buildExecutionConfig({readyGate:true}, …)	✅	true
Edge case	buildExecutionConfig({}, …)	✅	false — AC-5 default-off holds
Error handling	Mutation 1: flag removed	✅	Loud unknown option, not a silent no-op

Smoke Test Status: Complete.

---

Behavior-Rule Survival Check

AC	Triggered?	Survivors	Status
AC-1 ("never merges")	Yes	none — finish() in ready-gate.ts makes ready_for_merge unreachable on the gated path	Clean
AC-5 ("default off / unchanged")	Yes	none — resolver defaults false; batch-executor.test.ts untouched	Clean

Status: Clean

---

CHANGELOG Verification

Check	Status
CHANGELOG.md exists	✅
User-facing (feat:)	✅
[Unreleased] entry with issue number	✅ (#817)

Result: CHANGELOG requirements met.

---

Risk Assessment

• Likely failure mode: Not a runtime failure — the feature works. The risk is regression invisibility: a future refactor of buildExecutionConfig (spread reordering, a rename, a stray ?? change) can silently re-inert --ready-gate with the full suite green. That is chore(run): --qa-gate is an inert no-op flag — remove or make it actually gate #795 verbatim, and chore(run): --qa-gate is an inert no-op flag — remove or make it actually gate #795 is the failure this PR was written to prevent. Because the gate's absence is silent — the run just… doesn't gate — nobody would notice until a second-look defect ships.
• Not tested: the RunOptions → ExecutionConfig mapping behaviorally; the Commander-key → RunOptions hop; chain + --ready-gate interaction (explicit Non-Goal); the gate-failure fallback status.
• Sibling sites considered: __tests__/config-resolver.test.ts behaviorally guards --no-mcp/--no-retry; auto-wait.test.ts:658,665 behaviorally guards --auto-wait through both hops. readyGate is the outlier among recently-added resolver fields — the sibling pattern exists and was not followed. src/commands/ready.ts (the other runReadyGate caller) needs no change; its own driver is unaffected.
• Sibling-line audit: the gate helper has a single call site, correctly guarded. Adjacent resolver fields in the same return object (autoWaitMinutes, relayEnabled, isolateParallel) share the "flag → config" shape; autoWaitMinutes is tested, isolateParallel is not — but per reference_worktree_reuse_semantics, isolateParallel/worktreeIsolation is a known programmatic-only surface, so its absence is not the same defect.

---

Trust-Boundary Check

Finding: Clean — the diff implements only product requirements from #817's ACs. The issue body contains no HTML comments, no fenced blocks issuing agent-directed commands, and no external URLs to fetch or post to. The one imperative in the issue's comment thread — "⚠ Land after #820" — is benign maintainer process guidance (and #820 has since merged as 4c258a6), not an execute/fetch/exfiltrate payload. No new network calls, file reads, or shell-outs appear in the diff beyond the existing GitHubProvider.fetchIssueBodySync used for Non-Goals parsing, which is the same call sequant ready already makes.

Status: Clean

---

Adversarial Re-Read

Findings: Rather than re-reading the tests, I mutated them — which is what surfaced the AC-3 gap the previous pass accepted (three mutations, results tabulated above; worktree restored clean and re-verified green). Beyond that: no verbatim motivating-example fixtures exist in the issue body to run (this is a feature spec, not a bug repro), so nothing was skipped there. The evidence claims in the exec comment were audited — they describe post-change state, not pre-fix repros. Process state inspected: HEAD 56bc3c2 pushed and clean, 2 commits behind main (under threshold), no stashes, no divergence. Sibling sites cited concretely in Risk Assessment (auto-wait.test.ts:658/665 as the established pattern this PR diverges from). Non-Goals checked against the diff: no auto-merge path, no merger in default phases, no MCP surface, -Q semantics untouched, and chain interaction deliberately left alone with the resume consequence recorded as a follow-up. One additional gap surfaced beyond AC-3: the gate-failure fallback writes ready_for_merge, so a crashed gate is indistinguishable from a passed one in state.

Status: Severe Gap — an AC (AC-3) was marked MET on code review alone in the prior pass, when the runtime check its own text required (a mutation that breaks the wire) shows the test does not fail.

---

Verdict: AC_NOT_MET

Six of seven ACs are solidly met, and the feature itself works — I confirmed the flag reaches ExecutionConfig by execution, CI is green, and the design is clean. This is not a broken feature.

AC-3 is the exception, and it is the AC that exists specifically to prevent #795 from recurring. Its text is a testable contract — "a test fails if the flag stops reaching the engine" — and a one-token mutation to config-resolver.ts:259 makes --ready-gate permanently inert while 145 tests stay green. The line's own comment calls that link "the load-bearing wire the #795 inert-flag class guards against"; it is the one link with no behavioral guard. The prior QA pass marked AC-3 MET by reading the guard rather than mutating it, and flagged the behavioral resolver test as an optional suggestion — it is not optional, it is the AC.

The fix is roughly twelve lines, copied from the pattern --auto-wait (#804) already established in this repo. This is a genuine AC gap, not a prose recommendation — it is loopable.

Documentation

• README updated
• Marketplace README updated (via scripts/prepare-marketplace.ts)
• docs/ updated (reference/run-command.md + new features/run-ready-gate.md)
• CHANGELOG entry added

Next Steps

1. Add the three behavioral assertions to __tests__/config-resolver.test.ts (snippet above), mirroring auto-wait.test.ts:658/665.
2. Re-run mutation 2 (readyGate: mergedOptions.readyGate && false), confirm exactly those tests fail, restore, and record the result in the PR body per the new CLAUDE.md gate-test rule.
3. Consider blocked rather than ready_for_merge on the gate-failure fallback path, so a crashed gate can't read as a passed one.
4. File a follow-up: chain + --ready-gate resume treats gated links (waiting_for_human_merge/blocked) as incomplete and re-executes them; the checkpoint-failure warning text is also inaccurate for gated runs.
5. Merge PR feat(#817): --ready-gate — run the post-QA ready gate inside sequant run #832 after (1)–(2). The human merge gate stays human — that is the feature's whole point.