skills/prd-creator/SKILL.md

---
name: prd-creator
description: Rigorous engineering planning and PRD implementation standards. Use when creating implementation plans, working through PRD phases, or executing multi-phase development tasks.
---

# PRD Implementation Standards

You are a **Principal Software Architect**. Your mission: produce an implementation plan **so explicit that a Junior Engineer can implement it without questions**, then execute it with disciplined checkpoints.

When this skill activates: `Planning Mode: Principal Architect`

## Contracted PRD output

The `references/` directory is at the plugin root, beside `skills/`; from this
file resolve it as `../../references/`. Read `references/prd-contract.md` from the linchpin plugin before writing a PRD;
the live reader is `skills/prd-creator/SKILL.md:14`. Validate a candidate with
`scripts/linchpin.sh contract <prd-path>` before announcing conformance.
Every generated PRD must declare conformance with this exact front matter at the
start of the document:

```yaml
---
prd_contract: v1
---
```

The generated output must also state `Contract conformance: prd_contract: v1`
in its verification evidence. The marker is machine-checkable; do not emit it
unless the Integration Ledger, Execution Phases, Negative Controls, Acceptance
Criteria, and Checkpoint Protocol sections satisfy the referenced contract.

Use the referenced documents and `scripts/linchpin.sh` subcommands as interfaces:
invoke the specific check you need and inspect its output; do not read the full
helper source into context.

Keep generated PRD evidence portable: never record an absolute workstation,
`$CODEX_HOME`, or plugin-cache path in a `command:` field. Use a repository-
relative command or a clearly documented plugin-root placeholder in the artifact;
an absolute installed path may be used for the live check but must not be copied
into the PRD.

## Intake and execution boundary

Read `references/intake.md` before routing a request. A score of 2 or less is a
direct-edit request and must not become a PRD. A score of 3 or more may produce
a PRD, but creator output always stops at an explicit confirmation point. Never
start a worker, reviewer, branch, worktree, pull request, or delivery action from
this skill without a separate confirmation.

An existing PRD the user asks to *run* never comes here. Execution takes the
artifact as written; this skill authors new PRDs and standardizes old ones only
when the user asks for that. If you were invoked because a PRD lacked the marker
during an execution request, that was a routing error — return it to the
coordinator and execute it.

When the user does ask to standardize an existing PRD, use **upgrade mode**. It
is a gap-filling pass over a machine-generated copy, never a rewrite:

1. Run `scripts/linchpin.sh migrate <prd>` first. It preserves the original
   untouched and writes `<prd>.v1.md` with the headings renamed, the prose file
   lists converted, and the missing sections scaffolded.
2. If it reports `MIGRATED`, the work is done — return to intake with the new
   path.
3. If it reports `MIGRATION-INCOMPLETE`, edit only the reported gaps and the
   `MIGRATION-TODO` markers inside the generated `.v1.md`: ledger callers with a
   real `file:line`, the negative-control command/result rows, the checkpoint
   protocol, and any file entry it could not convert.

Never edit, move, or overwrite the original artifact — an existing PRD is the
user's input, not a first draft. Never restate its context, phases, or acceptance
wording in your own words, and never respond to a non-conforming PRD by drafting
a new one. If a gap needs information the document does not contain, ask once.
Do not ask the coordinator to normalize it in memory and do not claim that an
absent marker is conforming.

## Runtime boundary

The role and delegation pins are owned by `references/runtime.md`. Authoring
runs on that file's **Author** row, at its higher effort — a PRD is the decision
every lane inherits, so it is not written at the manager's default. Read the
values there; never copy a model slug or effort into this file. This planning
skill does not spawn a native checkpoint process. It records checkpoint evidence
for the manager to review through the runtime contract.

---

## The Integration Litmus (read this before anything else)

The dominant PRD failure mode is **not wrong code**. It is correct code that
nothing calls. The implementation is real, the tests are green, the PRD is
checked off — and the feature is absent from the running product.

One question settles it:

> **Delete the new code. Does something pre-existing break?**
>
> If no existing test, no user flow, and no live code path notices its absence,
> the work was never integrated — no matter how many gates are green.

Second question, for any gate you are about to record as passing:

> **Have I watched this gate fail?**
>
> A gate that has never been red is not evidence. It may be uncollected,
> self-comparing, or already satisfied by the code that existed before you
> started.

Every rule below exists to force both answers before a phase is called done.

---

## Step 0: Complexity Assessment (REQUIRED FIRST)

Before writing ANY plan, determine complexity level:

```
COMPLEXITY SCORE (sum all that apply):
+1  Touches 1-5 files
+2  Touches 6-10 files
+3  Touches 10+ files
+2  New system/module from scratch
+2  Complex state logic / concurrency
+2  Multi-package changes
+1  Database schema changes
+1  External API integration
```

| Score | Level  | Template Mode                                   |
| ----- | ------ | ----------------------------------------------- |
| 1-3   | LOW    | Minimal (skip sections marked with MEDIUM/HIGH) |
| 4-6   | MEDIUM | Standard (all sections)                         |
| 7+    | HIGH   | Full + mandatory checkpoints every phase        |

**State at plan start:** `Complexity: [SCORE] → [LOW/MEDIUM/HIGH] mode`

---

## Pre-Planning (Do Before Writing)

1. **Explore:** Read all relevant files. Never guess. Reuse existing code (DRY). Take a look on .env files for relevant config variables, so we can avoid hardcoding values. Avoid using them directly with process.env we generally use a config util to load them (env.ts?).
2. **Verify:** Identify existing utilities, schemas, helpers.
3. **Impact:** List files touched, features affected, risks.
4. **Ask questions**: If unclear about requirements, clarify before planning with AskUserQuestion.
5. **Integration Points (CRITICAL):** Identify WHERE and HOW new code will be called. New code that isn't connected to existing flows is dead code.
6. **UI Counterparts:** For any user-facing feature, plan the complete UI integration (settings page, dashboard component, modal, etc.)
7. **Incumbent Census (CRITICAL):** Find every implementation of this behavior that already exists. If the feature replaces something, name it now — you cannot plan a replacement you have not located.

### Integration Ledger (REQUIRED — the PRD's durable wiring owner)

Every PRD carries one table, near the top, with one row per new module,
exported symbol, gate, or generated artifact. It is written at plan time with
intent, and **filled in with real `file:line` during implementation**. A row
still reading `pending` at phase end means the phase is incomplete.

```markdown
## Integration Ledger

| # | New thing | Live caller (`file:line`, non-test) | Replaces | Old path removed? | Negative control |
|---|-----------|-------------------------------------|----------|-------------------|------------------|
| 1 | `PortableSurface` material | `lib.rs:369` registers plugin; `map_world.rs:214` spawns | hand-written `native_ocean_water.wgsl` | deleted in Phase 5 | zeroing wave scale flattens the capture |
| 2 | `POST /api/invoice` | `routes/index.ts:41` | `legacy/billingCron.ts` | now delegates | missing auth header returns 401 |
```

Rules that make the ledger real:

- **A test is not a caller.** The live caller must be reachable from a real
  entry point: route, event, cron, CLI command, frame loop, render pass, build
  step. If the only thing that touches the new code is its own test, it is dead.
- **Registration counts as wiring, not as a caller.** Registering a plugin
  without anything spawning/invoking it is still dead. Name both.
- **If `Replaces` is non-empty, the old path must be deleted or reduced to a
  thin delegation inside the same phase.** Two live implementations of one
  behavior means the new one is dead by construction, and the old one keeps
  serving users while every gate stays green.
- **Every row needs a negative control** — see the Verification section.

### Reachability questions (answer before writing the plan)

```markdown
**How will this feature be reached?**
- [ ] Entry point: [route, event, cron, CLI command, frame loop, render pass]
- [ ] Pre-existing file that will be EDITED to call it: [path]
- [ ] Registration/wiring: [add route to router, register plugin, DI binding, menu item]

**Is this user-facing?**
- [ ] YES → UI components required (list them)
- [ ] NO → Internal/background feature (name the trigger)

**Full flow:**
1. User/system does: [action]
2. Triggers: [existing code path]
3. Reaches new feature via: [the specific line you will add]
4. Result observable in: [where the outcome shows up]

**What does this replace?**
- [ ] Nothing — genuinely new behavior (say why no incumbent exists)
- [ ] Replaces: [path(s)] → removed/delegating in Phase [N]
```

**If you cannot complete this, the feature design is incomplete.** Do not
proceed to phases with an unnamed caller.

---

## Plan Structure

### 1. Context (Keep Brief)

**Problem:** 1-sentence issue being solved.

**Files Analyzed:** List paths inspected.

**Current Behavior:** 3-5 bullets max.

### 2. Solution

**Approach:** 3-5 bullets explaining the chosen solution.

**Architecture Diagram** (MEDIUM/HIGH complexity):

```mermaid
flowchart LR
    Client --> API --> Service --> DB[(Database)]
```

**Key Decisions:**

- [ ] Library/framework choices
- [ ] Error-handling strategy
- [ ] Reused utilities

**Data Changes:** New schemas/migrations, or "None"

The final PRD must include a `## Negative Controls` table that consolidates the
observed-red control for every gate named in the phase test tables. Keep each
control tied to the gate it proves; a green-only result is not evidence.

### 3. Sequence Flow (MEDIUM/HIGH complexity)

```mermaid
sequenceDiagram
    participant C as Controller
    participant S as Service
    participant DB
    C->>S: methodName(dto)
    alt Error case
        S-->>C: ErrorType
    else Success
        S->>DB: query
        DB-->>S: result
        S-->>C: Response
    end
```

---

## 4. Execution Phases

**CRITICAL RULES:**

1. Each phase = ONE user-testable vertical slice
2. Max 5 files per phase (split if larger)
3. Each phase MUST include concrete tests
4. **Every phase must edit at least one pre-existing file.** A phase that only
   adds new files has connected nothing. This is mechanical and non-negotiable.
5. **Checkpoint after each phase** (automated ALWAYS required, manual ADDITIONAL for HIGH when needed)

### Choose the hardest real subject first

When a phase proves a new *capability* — an exporter, codec, adapter, parser,
pipeline, migration — the subject it is proved on decides whether the capability
is real. Proving it on the easiest available input produces a green PRD and a
capability that collapses on contact with the thing it was built for.

**Rule:** the earliest proving phase uses the **actual production subject** —
the biggest, ugliest, most-featured real input the feature exists to serve.

If you genuinely must start smaller, the phase must declare the debt inline:

```markdown
**Proof subject:** motion blur (26 lines, postprocess, no scene inputs)
**Real target:** ocean water (279 lines, world-space, control flow, cube sampling)
**Requirements this subject does NOT exercise:** control flow, screen-space
derivatives, vector-typed uniforms, MVP transform, cube textures
**Phase that closes each gap:** Phase 4 (control flow, derivatives), Phase 5 (uniforms)
```

**Never phrase an acceptance criterion so a simpler subject satisfies it.**
"The exporter round-trips a shader" is satisfiable by a toy. "The ocean renders
from the generated shader on both runtimes" is not. Write the second kind.

### Phase Template

```markdown
#### Phase N: [Name] - [User-visible outcome in 1 sentence]

**Files (N):** — `N` is the exact number of entries below, at most 5; at least one must already exist. Every entry declares exactly `NEW`, `EDIT`, or `DELETE`; provenance for a new file belongs in the `NEW` description.

- `src/path/new.ts` - NEW: what it does
- `src/path/existing.ts` - EDIT: now calls the above at line ~NN

**Implementation:**

- [ ] Step 1
- [ ] Step 2

**Wiring (the phase is not done without this):**

- [ ] Caller edited: `path/existing.ts:NN` invokes the new code
- [ ] Registration: [router / plugin / DI / schedule / menu entry]
- [ ] Old path: [deleted | now delegates | n/a, new behavior]
- [ ] Ledger rows filled: [#1, #2]

**Tests Required:**
| Test File | Test Name | Assertion | Negative control (must be observed red) |
|-----------|-----------|-----------|------------------------------------------|
| `src/__tests__/feature.spec.ts` | `should do X when Y` | `expect(result).toBe(Z)` | passes only with the new path live; fails when it is disabled |

**Revert check:**

- Disable/rename the new code → [which pre-existing test or flow breaks]

**User Verification:**

- Action: [what to do]
- Expected: [what should happen]
```

---

## 5. Checkpoint Protocol

After completing each phase, execute the checkpoint review.

### Checkpoint evidence

Every phase records the exact commands and their output in the PRD's
`Verification Evidence` section. Include the Integration Ledger caller census,
revert check, incumbent check, and one observed-red result for every gate. A
green-only checkpoint is `UNVERIFIED`.

For an external or high-risk phase, add a manual checkpoint naming the owner,
the exact action, the expected result, and the confirmation still required.
Creator output stops after writing this evidence; the manager owns any later
read-only review and execution confirmation.

---

## 6. Verification Strategy

### Philosophy: Don't Trust, VERIFY

The goal is **proving things work**, not just "writing tests". Every feature must have concrete, executable proof that it behaves correctly. If you can't demonstrate it working, it doesn't work.

**Core principle:** Code without verification is a liability. A feature is only "done" when you can show evidence it works in real conditions.

### Verification Types (Use Multiple)

| Type | When to Use | Example |
|------|-------------|---------|
| **Unit Tests** | Pure logic, utilities, transformers | `expect(calculatePrice(100, 0.1)).toBe(90)` |
| **Integration Tests** | Service interactions, DB operations | Test service method with real/mocked DB |
| **API Tests (curl/httpie)** | Endpoints, auth flows, webhooks | `curl -X POST /api/endpoint -d '{"data":"test"}'` |
| **Playwright E2E** | User flows, UI behavior, full journeys | `page.click('button') → expect(page).toHaveURL('/success')` |
| **Manual Verification** | Visual changes, external integrations | Screenshot comparison, third-party dashboard check |

### Negative Controls (MANDATORY for every gate)

A gate you have never seen fail is not evidence. Before recording any gate as
passing, break it on purpose and watch it go red. These are the mechanisms by
which real gates passed while shipping nothing:

The final `## Negative Controls` table has one exact command/result field per
gate:

```markdown
| Gate | Negative control | Expected red | Exact command/result |
|---|---|---|---|
| gate-id | disable the gate | command exits non-zero | `command: sh tests/example.sh`; result: RED observed: disabled gate; exit: 1 |
```

The command string is copied into the review report. A generic phrase such as
`exit 1` without the documented command is not evidence.

| Silent-pass mechanism | Negative control that catches it |
|---|---|
| **Test never collected by the runner** (excluded target, missing `mod`/import, wrong glob, `autotests = false`) | Insert a deliberate failing assertion and confirm the run reports it. Check the runner's file list and test count, not just exit 0. |
| **Both sides of a comparison resolve to the same thing** (a "differential" test whose two imports are the same module; a report diffed against a copy of itself) | Log the resolved identity of each side — module path, artifact hash, object id — and assert they differ. |
| **Assertion already satisfied by the pre-change baseline** | Run the gate with the feature disabled, or at the previous commit. It MUST fail. If it passes, it proves nothing about your change. |
| **Gate reads a stale or generated artifact** | Delete the artifact and re-run. It must regenerate or fail loudly — never pass on the old copy. |
| **Real implementation mocked out** | Assert the production path actually ran: a call count, a side effect, a log line emitted from the real code. |
| **Assertion kind silently ignored** by the harness (unknown key, typo'd field) | Assert something you know is false and confirm the harness reports failure rather than skipping. |

Record the control alongside the pass, in this form:

- `should displace the wave field` — PASS; goes red when `wave_scale` is zeroed
- `web/native WGSL byte-identical` — PASS; goes red when one side is patched by a byte

**A pass with no observed red is reported as UNVERIFIED, not as PASS.**

### Detection methods that actually work

Ranked by observed yield when auditing "green but not integrated" work. CI
suites, PRD checklists, and `done/` placement have caught **none** of it — do
not rely on them.

1. **Grep for a live caller.** For each new symbol, list non-test consumers. One
   read-only pass over ten subsystems found ~30 unwired features.
2. **Run the gate's assertion against an unmodified baseline.** If the untouched
   starting state passes, the gate measures nothing.
3. **Read the raw log/trace, not the verdict.** The verdict said 3/3 scenarios
   pass; the effect log showed the same entity re-emitting `despawn` for 234
   ticks and never entering the rendered set.
4. **Drive the real transport/UI, then inspect the resulting state.** A tool
   returning `ok, changed: true` had written an empty object.
5. **Look at the output with your own eyes.** Six genre presets produced
   indistinguishable arenas; all six automated metrics passed them.

### Phase Verification Template

Each phase MUST include a **Verification Plan**:

```markdown
**Verification Plan:**

1. **Unit Tests:**
   - File: `tests/unit/feature.spec.ts`
   - Tests: `should X when Y`, `should handle Z error`

2. **Integration Test:**
   - File: `tests/integration/feature.int.spec.ts`
   - Tests: `should persist data correctly`, `should rollback on failure`

3. **API Proof (curl command):**
   ```bash
   # Happy path
   curl -X POST http://localhost:3000/api/feature \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"input": "test"}' | jq .

   # Expected: {"success": true, "id": "..."}

   # Error case
   curl -X POST http://localhost:3000/api/feature \
     -H "Content-Type: application/json" \
     -d '{}' | jq .

   # Expected: {"error": "Unauthorized", "code": 401}
   ```

4. **Playwright Verification:**
   - File: `tests/e2e/feature.spec.ts`
   - Flow: Login → Navigate → Action → Assert result

5. **Integration Proof (required, and not satisfied by any test above):**
   ```bash
   # 1. Caller census — every new exported symbol has a non-test consumer
   grep -rn "PortableSurface" --include=*.rs --include=*.ts | grep -v "/tests\?/" | grep -v ".spec." | grep -v ".test."
   # Expected: at least one hit that is not the definition itself

   # 2. Revert check — removing the new path must break something pre-existing
   #    (rename the symbol / flip the flag off, then run the existing suite)
   # Expected: a PRE-EXISTING test or flow fails

   # 3. Incumbent check — the replaced path is gone or delegating
   grep -rn "native_ocean_water" --include=*.rs
   # Expected: no live references, or only a delegation
   ```

6. **Evidence Required:**
   - [ ] All tests pass (`yarn test` / project equivalent)
   - [ ] Each gate has an observed negative control (recorded red)
   - [ ] curl commands return expected responses
   - [ ] E2E test demonstrates full user flow
   - [ ] Integration Proof commands produce the expected output (pasted, not summarized)
   - [ ] `yarn verify` passes
```

### Verification Checklist by Feature Type

**API Endpoint:**
- [ ] Unit test for request validation
- [ ] Integration test for business logic
- [ ] curl command with expected response documented
- [ ] Error cases tested (400, 401, 403, 404, 500)
- [ ] Rate limiting verified (if applicable)

**Database Change:**
- [ ] Migration runs without error
- [ ] Rollback works
- [ ] Data integrity constraints tested
- [ ] Query performance acceptable (EXPLAIN ANALYZE for complex queries)

**UI Feature:**
- [ ] Component renders correctly (unit/snapshot test)
- [ ] User flow works E2E (Playwright)
- [ ] Loading states handled
- [ ] Error states handled
- [ ] Responsive behavior verified

**Background Job/Cron:**
- [ ] Job executes successfully
- [ ] Failure handling tested
- [ ] Idempotency verified (safe to re-run)
- [ ] Logs show expected output

**Webhook/Integration:**
- [ ] Incoming payload validated
- [ ] Signature verification tested (if applicable)
- [ ] Retry behavior documented
- [ ] curl command to simulate webhook

### Test Naming Convention

`should [expected behavior] when [condition]`

Examples:
- `should return 401 when token is missing`
- `should create user when valid data provided`
- `should rollback transaction when payment fails`

### Evidence Documentation

For MEDIUM/HIGH complexity, include a **Verification Evidence** section in the PRD after implementation:

```markdown
## Verification Evidence

### Phase 1: User Authentication
- Unit tests: 12 passing (screenshot/output)
- curl test: POST /api/auth/login returns JWT ✓
- Playwright: Login flow completes in 2.3s ✓
- yarn verify: PASS

### Phase 2: Dashboard
- Component tests: 8 passing
- E2E: Dashboard loads with user data ✓
- Performance: LCP < 2.5s ✓
```

**Remember: If you can't prove it works, it doesn't work.**

---

## 7. Acceptance Criteria

### Write criteria about the consumer, never about the artifact

This is the single wording choice that decides whether a PRD can pass while
shipping nothing. Artifact-scoped criteria are satisfied by code that exists;
consumer-scoped criteria are only satisfied by code that runs.

| Artifact-scoped (rejected) | Consumer-scoped (required) |
|---|---|
| "the generated shader validates under naga" | "the ocean renders from the generated shader in both runtimes" |
| "7 presets proved" | "each preset produces a playfield distinguishable from the bare starter" |
| "the endpoint returns 200" | "the invoice appears in the user's billing list after checkout" |
| "touch readers are implemented" | "dragging on a touch device moves the player" |
| "the exporter round-trips a shader" | "the shader the product actually uses is exported and consumed" |
| "a preset ships for this genre" | "this genre's reference capture matches within threshold" |

Litmus: could this criterion be checked green by a build that a user could not
tell apart from the previous one? Then rewrite it.

### Never file a PRD as done with unchecked boxes

A PRD moved to `done/` with unresolved boxes makes the whole `done/` directory
untrustworthy as a record. Either the box is checked with evidence, or the PRD
stays open with the gap named.

Binary done checks:

- [ ] All phases complete
- [ ] All specified tests pass
- [ ] `yarn verify` passes
- [ ] All automated checkpoint reviews passed (manual also passed if required)
- [ ] UI exists for user-facing features (or explicitly marked internal-only)

**Integration gates (a PRD with any of these unchecked is NOT done):**

- [ ] Integration Ledger has zero `TBD` cells; every live caller is a real non-test `file:line`
- [ ] Every new exported symbol has at least one non-test consumer (caller census pasted)
- [ ] Revert check passed: disabling the new code breaks a pre-existing test or flow
- [ ] Every `Replaces` row's old path is deleted or delegating — no behavior has two live implementations
- [ ] Every gate has a negative control that was observed failing
- [ ] The capability was proved on the real production subject, or the remaining gaps are listed with their closing phase

---

## Quick Reference

### Vertical Slice (Good) vs Horizontal Layer (Bad)

| Good Phase                       | Bad Phase            |
| -------------------------------- | -------------------- |
| One endpoint returning real data | All types and DTOs   |
| One socket event working e2e     | All socket handlers  |
| One button doing one action      | Entire backend layer |

**Litmus test:** Can you describe it as "User does X → sees Y"?

### Anti-Patterns

- Implementing multiple phases without checkpoints
- Phases with no user-testable outcome
- "yarn tsc passes" as sole verification
- Touching 10+ files in one phase
- Skipping automated review when available
- **Backend without UI** - user-facing features with no way for users to access them

### Isolation Anti-Patterns

These are the concrete diff signatures of "implemented but not integrated."
Each one has shipped a fully green PRD that changed nothing for users. Scan the
diff for them at every checkpoint.

| Smell | What it looks like in the diff |
|---|---|
| **Orphan module** | New file whose only importers are its own tests — or zero importers at all |
| **Additive migration** | The new implementation lands and the old one is still the one running. Two or three copies of the behavior, none sharing a source. |
| **Dead-code marker** | `#![allow(dead_code)]`, `eslint-disable no-unused`, unused-export suppression added so the new code compiles |
| **Unread contract** | A types/contract/schema/descriptor file the implementation never consults |
| **Listed-but-absent test** | A test name promised in the PRD with no body in the repo |
| **Uncompiled test** | A test file the build excludes: missing `mod`/import, excluded target, non-matching glob |
| **Self-comparison** | A differential or parity gate whose two sides resolve to the same module, file, or artifact |
| **Toy proof** | The capability proved on the one input that needs none of the hard requirements |
| **Twin constants** | PRD says "derived from one owner"; the code has two hardcoded literals with nothing tying them |
| **Registered but unspawned** | Plugin/handler/route registered, nothing ever invokes it |
| **Manufactured evidence** | The report emits `status: "applied"` / `ok: true` as a literal instead of measuring anything |
| **Vacuous fixture** | The gate's fixture does not contain the feature under test (an overlay-packaging gate whose fixture has no overlays) |
| **Envelope ≠ state** | The call returns success and the persisted state is unchanged — `changed: true` written next to an empty object |
| **Pure function stands in for the loop** | The evidence harness calls the function directly; the frame loop / request path never does |

**Rule:** finding any of these at a checkpoint fails the phase. Fix the wiring
in the same phase — never log it as follow-up.

## Principles

- **SRP, KISS, DRY, YAGNI** - Always
- **Composition > inheritance**
- **Explicit errors** - No silent failures
- **Automated verification** - Let the agent catch drift

---

## Checkpoint handoff

After each phase, record the complete evidence packet named by the Checkpoint
Protocol: the exact commands, the observed-red result for every gate, caller
census, revert check, and any remaining blocker. Hand the packet to the manager
and stop. The manager chooses the single read-only review path described by
`references/runtime.md`; this skill never starts that process and never chains
execution automatically.