Genesis A1

---
name: "A1 — Design & Master-Spec Consistency"
description: The drift check. Compare what was built against the design doc and master spec. Sets the Double Gate — A3 cannot start until A1 is at zero findings.
argument-hint: "<group-number> [feature-name]"
---

# A1 — Design + Master-Spec Consistency

The **drift** check, and the first lens. A1 compares what was actually built against the two authoritative intent documents — the **design doc** (architecture, data models, boundaries, technology choices, data flow) and the **master spec** (the WHAT). Has the architecture been honored? Are boundaries respected? Was anything built that isn't specified (scope creep), or specified but not built?

A1 is the **gate-setter**: `/genesis-a3` cannot begin until A1 reports zero findings.

## Inputs

- `design.md` (required — refuse if missing) · `spec.md` (required — refuse if missing)
- The group's micro specs and the implementation code in scope
- The constitution · `northstar.md` · the project mode

## Process

1. Detect the mode (greenfield/brownfield/lowfield) — it drives the checklist.
2. Confirm every spec in the group is implemented; if not, refuse: "Cannot audit — {spec-id} is not implemented."
3. **Design doc vs implementation:** are architecture decisions reflected in code? boundaries respected? any forbidden/unconstitutional dependency introduced? does data flow match the design?
4. **Master spec vs implementation:** anything implemented but not specified (scope creep)? anything specified but not implemented? did the micro-spec plan structure hold?
5. **Determine fix direction** per divergence — code wrong → fix code; code right but docs stale → update docs; both → a finding for each. A1 is the only lens that judges fix direction; it does not assume the code is wrong. Where both directions are plausible, the finding declares which interpretation it assumes.
6. **(Brownfield)** scope strictly to the spec's File Operations table; classify each finding **Introduced** (added on this branch) vs **Inherited** (pre-existing) via git blame. Both get fixed; the classification is reported.
7. Write the report to `audits/{scope}-a1.md`: a design-consistency table (decision → code → match/drift), a spec-consistency table (FR/behavior → implemented → match/drift/extra), document-update recommendations, and a reasoning trace per finding.

## The finding format, the zero-tolerance loop, the Double Gate, and conviction

These are shared by all five lenses — see [docs/the-audit-system.md](../../docs/the-audit-system.md) for the full definitions. In brief:

- **Finding format** carries: Severity, Conviction (0–100), File:lines, Requirement (FR/AC ID or "general quality"), Classification (Introduced/Inherited/N/A), Description, a **Reasoning Trace** (premises, alternatives considered, why this is a finding), a Suggested Fix, and Status.
- **Zero-tolerance loop:** A1 loops until it reports **zero findings**. No "won't fix," no "out of scope." Every finding becomes a fix, a new micro spec, or a tracked design input — and the open-finding count must reach zero.
- **Double Gate:** A1 must reach zero before A3 may run. There is no override.
- **Conviction:** write the finding first, then score it 0–100 against the conviction scale; record it in the finding. Zero findings ⇒ conviction 100.

## Natural language triggers

```
- "a1 audit group 1"
- "design consistency audit"
- "check for drift"
```