Accept

Accept — The Boundary Ritual

Accept fires after every pipeline step. It is the only step that writes approval records — every other step reads them. It reviews what just happened, records a disposition, writes a journal entry, and advances the phase in project-state.md.

Accept does NO git. No commit, no push, no PR, no branch operations. Git lives entirely in /genesis-closure. This separation is load-bearing: Accept records what landed; Closure moves what landed. If Accept committed, uncommitted work could masquerade as approved.

Inference

Accept infers what it is approving from context — the most recent un-approved artifact — so it usually needs no argument. Always print an inference trace so the decision is explainable:

Approving: {phase} — most recent un-approved action in {file}

If a phase is given as an argument, approve that phase explicitly.

Routing — which file gets written

Two approval layers live under .genesis/features/{feature}/approvals/:

• master.json — spec-level and feature-level phases (brainstorm, design, specify, clarify, northstar, group-accept, final audits, review).
• group-N.json — per-group work (the micro specs for group N, each spec's implementation, and the per-group audits A1–A5).

Phase being approved	Target file	Recorded phase
brainstorm / design / specify / clarify / northstar	master.json	brainstorm / design / …
micro specs for group N	group-N.json	micro
implement spec	group-N.json	implement-{spec-id}
audit AX for group N	group-N.json	audit-aX
group accept for group N	master.json	group-accept (with group: N)
final audit FX	master.json	audit-fX
feature review	master.json	review

Rule of thumb: spec-level phases → master.json; per-spec implementation and per-group audits → group-N.json; group-accept closes the group but is itself a spec-level gate, so it writes to master.json.