Gate Checks

Every lifecycle phase ends at a gate that checks artifact structure, evidence and decisions. Pass every required condition, advance. Fail one, stop and say which: a gate holds whatever the argument. This skill inspects an active lifecycle initiative; a standalone review returns findings and leaves lifecycle state as it is.

Read evidence-ledger when tag counting or source provenance needs clarifying, and pressure-testing for a material open branch that evidence and delegated judgment leave unsettled.

The Conditions

Read current_phase from state.json, then read only the conditions file for that gate: 0 Frame, 1 Discover, 2 Define, 3 Ideate, 4 Shape, 5 Build, 6 Ship, 7 Learn, C Coverage on the feature track, M Mandate on the change track, or N Need on the internal track. Each holds the condition table (id, condition, check), which conditions the script decides, and the phase's recording flags. Read lite mode when state.json sets mode: "lite".

E.1 and E.2 run on every gate, including the coverage check (against PRODUCT.md and 00-request.md) and the mandate check. A tag without its file is an untagged claim wearing a tag; a provisional block is a recommendation wearing a decision.

Who Checks

A gate checked by the model that wrote the artifact is a gate checked on trust, so state.json records who decided each condition in gate.checked_by.

• Script-decided conditions are structure and arithmetic: a word list, a tag count, an enum, a date comparison, a table with no empty cell. Where commands run, node scripts/bos.mjs gate {N} decides them and prints one line per condition. Relay that result as decided; the model judges the judge lines alone.
• Model-judged conditions need meaning: whether an assumption is falsifiable, whether two options are mechanically distinct. The script lists them as judge, with whatever structural precheck it could run, and the model decides them.

Where commands cannot run, the model checks every condition and records all of them under model: same conditions, weaker provenance, and the record says so. E.1 and E.2 are script-decided; each conditions file states its own split, and the emitted checked_by split is authoritative.

• Attested conditions rest on a fact outside the repository: a session with a user, a payment, a person who tried the build. The script checks the citation and its file, never the event. Each conditions file lists them; say so when relaying them.

Recording the result. Where commands run, the result reaches state.json only through node scripts/bos.mjs record {N} --judged "{id}=pass|fail,...": the script re-runs its own conditions, takes the model's verdict on the judge ones, and writes the phase status, checked_at, checked_by, the failed conditions and the history event, then advances, closes or holds the phase and regenerates the roadmap. A gate result written into state.json by hand where the script can run is a claim, not a record, exactly like a completion marker. Phases 1, 6 and 7 take phase-specific flags (verdict, review date, re-entry), stated in their conditions files. The record also stores the script's version and the skipped conditions, so a later release can tell "not applicable then" from "not there yet". Verdict/enum contradictions cannot be overridden.

Debt After a Release

Each record carries the BuilderOS version that wrote it and the conditions it skipped. A release that adds conditions leaves earlier passed gates passed; the briefing and bos.mjs doctor list the conditions in force now that the record did not check and the artifact does not meet. That is debt: meet it when the work next touches that phase, or name it at phase 7. The phase stays passed.

Acceptance

A gate says an artifact is complete, not that a person has read it and agrees. BuilderOS records both, separately.

Phases 0, 4 and 6 each need a person's acceptance, and the build plan inside phase 5 needs its owner's **Accepted:** line before any code. Who accepts and where it is recorded is in that gate's conditions file.

Rules. Acceptance comes from the person's own words: ask, then record what they said, quoted. A standing instruction counts when it named the scope ("proceed through the build without stopping"), quoted with its date. The script refuses to pass phases 0, 4 and 6 without --accepted-by; a failed gate records no acceptance.

Decisions

The choices a phase turns on belong to a person, and each gate checks a **Chosen by:** naming the person who chose, from their answer: the assumption phase 1 tests (0.5), what a discovery verdict means for the work (1.6), the opportunity and its target (2.8), the bet (3.6), the look (4.9), the rollout (6.13), and keep, iterate or kill (7.7). The agent does the analysis and recommends in a pressure-testing round; "go with the recommendations" is a valid answer and is quoted as such. A standing instruction that named the scope counts, quoted with its date, exactly as for acceptance.

The person's words. Where the host runs the BuilderOS message hook, each message the person writes is appended to .builderos/person-log.jsonl, which only the hook writes. Every person field (Chosen by, Accepted, Tried by, Rules decided by, Authorized by, --accepted-by, a kill, jump or override reason) quotes their words in quotation marks; a quote they never wrote fails. Without the log the field passes, marked unverified.

Refusal Protocol

When a condition fails, the agent produces exactly this and holds the phase:

## GATE {N} FAILED

**Failed condition:** {the condition, verbatim}
**Found:** {what the artifact actually contains}
**Satisfied by:** {what would make it pass}
**Cheapest path:** {the least expensive way to get there, with a time estimate}

Remaining conditions: {passed}/{total}

A phase advances on a pass or a logged override, nothing in between. When a test came back under its stop line, the honest outcome may be to stop: offer the kill next to the override.

Override and Kill

An override waives conditions by name, each with the person's reason: record {N} --judged ... --override "reason" waives a single failure; several need --waive 4.22,5.8, and conditions left unnamed still fail. The record keeps overridden, the reason, the failed and waived conditions; the briefing shows them until a later cycle meets them, and phase 7 reads them. The entry checks cannot be overridden.

record {N} --kill "reason" ends the initiative at phases 0 to 6, with the person's words; phase 7 kills through its verdict. Moves the process asks for have their commands: resume {slug}, reframe --reason (a new cycle from phase 0), jump {N} --reason (back reopens phases; forward records the jumped phases as overridden).

Entry Checks and Spike Stop

Each runs once, at initialization, and stands in for the early gates by reading 00-request.md:

• Coverage (feature): gates 0 and 1, from PRODUCT.md and the request's own evidence: coverage-check.md. A failure makes a product.
• Mandate (change): gates 0 to 3, from the bug, debt, rule or contract that already decided what to build: mandate-check.md. A failure makes a feature.
• Need (internal): gates 0 to 2, from the job, its users by name, how long it takes today and when it is done: need-check.md. A failure makes a product.

A spike ends at gate 1 with phase 1 answered and the initiative closed: gate-1-discover.md, Spike Stop.

Watch for

Capability Requirements

Procedure

1. Read the gate. Resolve the active initiative and phase; read its artifact, its gate's conditions file and the raw evidence the conditions touch. For a standalone review, return findings and stop here. Done when you can list every condition of this gate.
2. Run the script's checks where commands run (node scripts/bos.mjs gate {N}). Gate inspection runs the gate's own checks; a project check runs only when the person authorized that command (capturing a run: gate 5), with failures and raw logs kept as they came. Done when every script-decided condition has its line.
3. Judge the judge conditions against the evidence, and surface unavailable evidence, failed runs and incomplete observation windows. Done when every judge line has pass or fail with its reason.
4. Close what can be closed. Fix authorized local gaps and repeat the affected checks. A real failure gets the refusal protocol; an explicit override keeps the failed conditions and its reason. Done when every condition passes, or the refusal or override is written.
5. Record through the script with consistent phase-specific verdicts and dates and, at phases 0, 4 and 6, the person who accepted. Done when record succeeded and state.json shows the result.

Output Contract

## GATE {N} PASSED only after recording succeeds; ## GATE {N} FAILED in the refusal format with the failed conditions; ## REVIEW DEFERRED for a deferred phase 7, which holds the phase.