Release Gate

Run this before any ticket merges. The gate is structural: it either passes or the ticket becomes a blocker. It fails closed — anything missing or unverifiable is a failure, not a pass.

The gate

1. Tests green. Run the ticket's testCmd if set, otherwise the area default at config.orchestrator.testCmd.<area> in the project's config.json (the same lookup scripts/run-ticket.mjs uses). If neither is set there is no test command — that is a failure. Green means more than exit 0: no skipped tests masking the change, and coverage at or above the declared threshold if the project declares one. A placeholder like "no test command configured" is a failure, not a pass — configure a real command.
2. Scope matches the ticket. The diff does what the ticket says and nothing unrelated.
3. Acceptance criteria met. Every AC from the ticket is satisfied and tested. A ticket with no acceptance criteria at all is an automatic no-go — there is nothing verifiable to gate against. Send it back to get ACs written first.
4. The plan's bar is met. Read the ticket's traces_to against {{BOARD}}/plan.json (maestro plan show --board {{BOARD}}/data.json):
   • Run the invariants. maestro plan check --traces <the ticket's traces_to> --board {{BOARD}}/data.json. Every enforce command the ticket's plan items declare must exit 0. A non-zero exit is a hard no-go — not a judgment, not something to weigh against how good the change looks, and never something to "fix" by editing the check. That is the entire reason the field exists: a rule stated in prose is one an agent can talk itself past; a rule that exits non-zero is one it cannot.
   • Every FR- it traces to has its verify method actually run, and the result recorded.
   • Every NFR- it traces to has evidence against that NFR's stated budget — the measured number, not an assurance. "Should be fast" does not clear p95 < 300ms; a p95 you measured does. An NFR with no budget in the plan is a no-go on the plan, not on the ticket: send it to /plan-update to get a number, and say so.
   • A ticket whose traces_to is empty or points at ids the plan doesn't define should never have run — the orchestrator's scope gate should have refused it. Finding one here is a no-go, and worth reporting as a process failure rather than quietly fixing.
5. Upstream verdicts verified. Use the words each stage actually returns:
   • qa returned Pass (not Defects, and not a block for missing ACs).
   • security-review returned Ship (not Block) — required when an acceptance criterion on the ticket requires a security review; otherwise N/A (nothing runs it by default, so the gate does not demand a verdict nobody was asked to produce). security-review is a skill, not an agent — agent_plan can only hold agent codes — so the stage that owns that AC (build, or qa) runs the skill and states the verdict in its stage report, as that AC's evidence. The board has no field for verdicts in flight; the verdict is read from that report, then copied into the ticket's archive evidence at step 8. No verdict in the report fails this line. A security-sensitive ticket with no such AC is a no-go on the plan — send it back to add one. Do not use human_gate to request a review: it means human approval, so the orchestrator will not auto-run the ticket and it forces pd onto the plan.
   • principal-delivery, when in the plan, decides Land / Block after this gate is GO; its verdict is not an input here.
   • No stage in the plan is incomplete or errored. A missing verdict is a failure, not a pass — the gate never infers a stage went fine because nothing says otherwise.
6. Mergeable. The branch merges cleanly onto the default branch; every depends_on ticket is actually done; the diff contains no debug code, leftover secrets, or commented-out blocks.
7. No new warnings/errors introduced (lint, type-check, console).
8. Evidence captured. Record commit SHA + test result on the ticket before archiving.
9. No human gate bypassed. If the ticket carries a human_gate, it must have been cleared by a human — the gate does not clear it.

Local gate over CI

AI Maestro assumes the gate runs locally, deterministically — a single command you can trust — rather than depending on remote CI. Wire your per-area test commands under config.orchestrator.testCmd (e.g. { "backend": "npm test" }) so that one command per area gives a trustworthy pass/fail. Keep a known-good baseline; a jump above it is a regression to fix, not noise to ignore.

Output

Report the gate as a structured block, not prose — same contract as the frontend-quality and pipeline-quality skills:

=== Release Gate ===
Ticket: <id>   Branch: <branch>

Tests:                PASS / FAIL
Scope:                PASS / FAIL
Acceptance criteria:  PASS / FAIL   (<n met> / <total>; 0 total = automatic NO-GO)
Plan (traces_to):     PASS / FAIL   (<ids>; FR verify run: <result>; NFR budget: <measured vs bar>)
Plan invariants:      PASS / FAIL   (maestro plan check --traces <ids>: <n> ran, <n> failed)
Upstream verdicts:    PASS / FAIL   (qa: Pass/Defects; security-review: Ship/Block/N/A)
Mergeable:            PASS / FAIL   (conflicts / open deps / debug leftovers)
Warnings/errors:      PASS / FAIL
Evidence:             PASS / FAIL
Human gate:           CLEAR / PENDING / N/A

NO-GO REASONS:
  - <specific blocker>

VERDICT: GO / NO-GO

Every line gets a value — an item that could not be checked is FAIL with the reason listed, never omitted.

On failure

A failing gate sends the ticket back to build or files a blocker with the specific failure. Never land a change to hit a schedule — an unverified merge costs more than a late one.