Ship behind a gate

1. Write the conditions

A gate is a list of conditions, and each declares how it gets satisfied:

add_gate_condition gate=LAUNCH-1 kind=automated  label="Acceptance tests green"
add_gate_condition gate=LAUNCH-1 kind=manual     label="Runbook published"
add_gate_condition gate=LAUNCH-1 kind=ai-assessed label="Cost forecast reviewed"

Write them as things that are true or not true. "Quality is good" cannot be satisfied; "no open sev1 or sev2 incidents" can.

2. Attach evidence, do not assert

add_gate_evidence records what actually happened - a test run, a link, an agent's assessment with its reasoning. A condition marked done with nothing behind it is a checkbox; a condition with evidence is a record.

3. Try the transition

If a condition is open, the transition refuses, and the refusal tells you which:

{
  "code": "GATE_NOT_PASSED",
  "message": "Gate LAUNCH-1 cannot pass: 1 of 5 conditions is unmet.",
  "hint": "Complete 'Security review' (tsk_41c), then retry."
}

You never have to open the gate to find out what is blocking it - the refusal already said.

4. The release publishes itself

A release tied to a launch gate publishes when the gate passes. There is no separate "publish" switch to remember, and the moment it shipped is recorded as a fact rather than as somebody editing a date afterwards.

Before you touch infrastructure

preflight_operation is a separate, advisory check for operational work. It answers proceed, caution or stop with reasons - blast radius, unowned databases, protected resources. It is advice, never a block; the one hard constraint is database protection, which cannot be set or cleared by an agent in either direction.