Genesis Accept

---
name: "Accept"
description: The boundary ritual — review what just landed, record an approval, journal it, and advance the phase. The ONLY step that writes approvals, and it does NO git.
argument-hint: "[phase] [--force] [--exclude <item>]"
---

# 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`.

## What Accept checks before approving

### 1. Clean working tree

Before recording anything, verify the tree is clean:

```
git diff --quiet            # no unstaged changes
git diff --cached --quiet   # no staged-but-uncommitted changes
```

If either reports changes, refuse:

```
Cannot accept — working tree is dirty.
{N} files with unstaged changes, {M} files staged but uncommitted.

Accept records what landed. A dirty tree means uncommitted work is not
captured by the commit you are about to approve. Commit or stash first,
then re-run accept.

Override: --force (records the variance in the approval note).
```

This is the central guardrail and it is enforced by this skill itself — there is no external daemon. The rationale is the Accept/Closure split: if the tree is dirty, the thing you are approving is not what is actually committed.

### 2. Quality gates

If the constitution defines quality gates, run them — typically `lint` and `tests` (and a type-check or build where applicable) — and record each result. A failing gate does **not** auto-block: record it as `fail` in the `gates` field and let the user decide. With `--force`, note the failure and proceed. If the constitution defines no gates, `gates` is `null`.

### 3. Group-accept completeness

For a group-level accept, all in-scope audit types (A1–A5) must show clean passes in `group-N.json` before the group can close.

### 4. The Standard (rejection-default posture)

Accept does not ask "is this good enough to pass?" It asks **"is there any reason NOT to accept?"** The default is rejection; approval is *earned* by actively disproving each reason:

| # | Rejection reason | How to disprove it |
|---|---|---|
| 1 | Incomplete implementation | every file operation in the spec is satisfied |
| 2 | Failing quality gates | all constitution gates pass |
| 3 | Unresolved audit findings | zero open findings from A1–A5 (or the final audits at feature scope) |
| 4 | Missing acceptance criteria | every AC in the spec is checked |
| 5 | Drift from the North Star | implementation aligns with the stated direction |
| 6 | Undocumented decisions | key decisions are recorded in the journal / decision log |

If any reason cannot be disproven, return `revise` naming the specific unmet criterion. The default holds.

## The approval record

Append a record to the flat JSON array in the target file:

```json
{
  "phase": "implement-spec-3",
  "version": "1.0",
  "status": "approved",
  "disposition": "pass",
  "timestamp": "2026-06-18T14:32:00Z",
  "approvedBy": "user",
  "gates": { "lint": "pass", "tests": "pass" },
  "group": null,
  "scope": null,
  "note": "",
  "conviction": null,
  "exclusions": []
}
```

| Field | Meaning |
|---|---|
| `phase` | what was approved (from the routing table) |
| `version` | record schema version (`"1.0"`) |
| `status` | derived from disposition (mapping below) |
| `disposition` | the verdict: `pass` \| `revise` \| `conditional` \| `reject` |
| `timestamp` | ISO 8601 |
| `approvedBy` | who approved (e.g. `"user"`) |
| `gates` | `{ "lint": "pass"\|"fail", "tests": "pass"\|"fail" }`, or `null` if no gates defined |
| `group` | group number for group-scoped records; `null` otherwise |
| `scope` | optional finer scope (a spec id/title) or `null` |
| `note` | free text — findings reference, conditions, or a recorded variance |
| `conviction` | integer 0–100 for audit phases; `null` for non-audit phases |
| `exclusions` | items excluded under a conditional accept |

**Disposition → status:**

| Disposition | `status` | Behavior |
|---|---|---|
| `pass` | `approved` | advance to next phase |
| `revise` | `revise` | return to the previous stage; `note` must reference findings |
| `conditional` | `conditional` | advance with documented exceptions; `exclusions` populated |
| `reject` | `rejected` | return to an earlier phase; `note` must give the reason |

**Skipped stage** — when a stage is deliberately skipped, carry the justification rather than silently omitting it:

```json
"variance": { "skippedStage": "clarify", "reason": "spec is trivial, no open questions" }
```

## The clean-tree override (`--force`)

`--force` proceeds past a dirty tree or a failing gate. There is no enforcement daemon — the override is simply **a recorded variance in the `note` field**:

```
clean-tree override — 2 dirty files at accept time: src/foo.ts, README.md
```

The legitimate use case is parallel work: a second editing session can make the tree look dirty to the one running Accept. The override closes the loop while the note keeps the trail honest. Without `--force`, Accept exits *before* writing anything.

## Conviction

**Conviction** is an integer (0–100) attached to *audit-phase* approvals only — how confident the review is that the work is genuinely ready, not merely that no findings are open.

- Applies only to audit phases (A1–A5, final audits, feature review). Other phases leave `conviction: null`.
- Computed as the **mean conviction across all findings in scope** (each audit finding carries its own score). **Zero findings ⇒ conviction 100.**
- An optional `.genesis/features/{feature}/conviction/policy.yaml` defines thresholds. If absent, skip this step entirely (graceful degradation):

| Mean conviction | Behavior |
|---|---|
| ≥ auto-pass (default 80) | recommend pass; proceed, record the score |
| prompt ≤ … < auto-pass (default 60–79) | show breakdown, recommend reviewing low-conviction findings, ask before proceeding |
| < stop (default 60) | stop; list the lowest-conviction findings; require explicit `--force` |

When prompting or stopping, show a per-audit breakdown:

```
Conviction Breakdown:
  A1 (design+master): 3 findings, mean 88   [OK]
  A2 (spec review):   2 findings, mean 72   [REVIEW]
  A3 (polish):        0 findings            [CLEAN]
  A4 (north star):    1 finding,  mean 65   [LOW]
  A5 (web):           0 findings            [CLEAN]
  Aggregate: 76 (below auto-pass threshold of 80)
```

## Journal

After recording, write a plain markdown entry to `.genesis/features/{feature}/journal/{date}_{time}.md`:

```markdown
---
feature: "{feature}"
phase: "{phase}"
scope: "{group/spec if applicable}"
date: "{ISO date}"
---

## {Phase}: {Feature}

{2–3 sentence summary of what was done}

### Decisions
- {key decision made during this phase}

### Next
{what comes next in the pipeline}
```

The journal is the durable record of *why*. It is written here, never by an automatic hook.

## Advance the phase

After journaling, update `project-state.md` and present the next pipeline action:

- brainstorm → feature doc / specify · specify → clarify · clarify → northstar · northstar → first group's micro specs
- micro group N → next group's micro specs (if more) or implement (when all groups are written)
- implement spec → next spec, or A1 when the group's specs are done
- audit AX clean → next audit type, or **group-accept** after A5 is clean
- **group-accept** → if **all** groups are now accepted, the mandatory next step is **F1** (never skip straight to closure); otherwise run group closure (push + PR) and move to the next group
- final audits run F1 → F2 → … in sequence; after the last, feature review, then the final closure PR

Disposition routing: `revise` re-runs the stage sent back; `reject` re-runs from an earlier phase; `conditional` advances like `pass` but exclusions stay visible.

Finally, scan the accepted artifact for actionable ideas and ingest them into the furnace (see `/genesis-brainstorm` and `docs/concepts.md`): update a matching `F-NNN` entry, or append a new one with `status: seed`.

## Natural language triggers

```
- "accept"
- "approve this"
- "looks good, advance"
- "lock it in"
```