@izkac/forgekit 0.3.11 → 0.3.13

package/vendor/skills/forge/phases/plan-specs.md

@@ -1,117 +1,163 @@
-# Plan phase — built-in specs engine
-
-For projects with `.forge/config.json` → `plan.engine: specs`. Mirrors the
-OpenSpec propose flow without the vendor CLI. Change lives under
-`<specsDir>/changes/<change-name>/` (default `specs/changes/…`).
-
-## Steps
-
-1. Derive a kebab-case change name from the brainstorm outcome (e.g.
-   `add-stripe-refunds`). No date prefix while active.
-2. Create the change directory (preferred: CLI scaffold):
-
-   ```bash
-   forge change new <change-name>
-   ```
-
-   Or create manually under `<specsDir>/changes/<change-name>/` with:
-
-   **`proposal.md`** (required)
-
-   ```markdown
-   # <Change title>
-
-   ## Why
-   One or two paragraphs: problem / pressure.
-
-   ## What Changes
-   Bulleted scope — behavior, contracts, data.
-
-   ## Impact
-   Affected code/areas, risks, migration notes.
-   ```
-
-   **`design.md`** (only when there are real design decisions)
-
-   Context, decisions with alternatives, risks. Skip for mechanical changes.
-
-   **`tasks.md`** (required)
-
-   ```markdown
-   # Tasks
-
-   ## 1. <Group name>
-   - [ ] 1.1 <Bite-sized task — exact files, expected tests>
-   - [ ] 1.2 …
-
-   ## 2. <Group name>
-   - [ ] 2.1 …
-   ```
-
-   Task-writing rules (from writing-plans practice):
-   - Bite-sized: one task = one reviewable step (a test + the code to pass it).
-   - Name exact file paths where known.
-   - Each task states its verification (test command or observable behavior).
-   - Group with `##` sections — Forge reviews per group under `standard` pace.
-
-3. Confirm `tasks.md` exists and the change is apply-ready.
-4. **Spine (always) + orchestration seam** — see [../references/runtime-integrity.md](../references/runtime-integrity.md):
-
-   ```bash
-   forge spine init     # mandatory every change — fill rows or set notApplicable
-   ```
-
-   Sync-only / docs-only: `"notApplicable": "<reason>"`. Capability work: one row
-   per REQ cluster (library → runtime owner → writes → evidence).
-
-   When the spine has real rows, also `forge e2e init` — the executable
-   product-loop steps (`e2e.json`) are a **plan deliverable**: author them (or
-   task out their authoring) so verify can `forge e2e run` them.
-
-   If the change also involves workers, job queues, handlers, or cross-runtime
-   calls, `tasks.md` MUST include:
-
-   - Explicit **wiring** tasks per job kind / entry point → domain pipeline
-   - One **product-loop acceptance** task (last implement task, before
-     verify) — its output is a green `forge e2e run`
-
-   Missing spine = plan **not** ready. (`forge phase done` refuses without a
-   valid spine and, when the spine has rows, a green current e2e run —
-   keyword sniffing does not decide.)
-
-5. **Operator brief (mandatory)** — see [../references/operator-brief.md](../references/operator-brief.md):
-   write `<specsDir>/changes/<change-name>/brief.html` — a plain-language,
-   self-contained HTML explanation of what will be built (mermaid diagrams
-   where helpful), then:
-
-   ```bash
-   forge brief stamp    # records specs hash (does NOT auto-open)
-   ```
-
-   `forge phase implement` hard-refuses while the brief is missing or stale
-   (specs edited after stamping → rewrite affected sections and re-stamp).
-
-6. Update session:
-
-   ```bash
-   forge phase plan --plan-type specs --openspec <change-name>
-   forge phase implement --tasks-total <N>
-   ```
-
-   Count tasks from `tasks.md` checkboxes. (`--openspec` carries the change
-   name for both engines.)
-
-7. Get user approval on the artefacts before implementing (unless they already said "go").
-   The brief is what the operator reviews — tell them its path and that
-   `forge brief open` launches it; never open it for them.
-
-## Compatibility
-
-Layout and conventions are deliberately identical to OpenSpec
-(`proposal.md` / `design.md` / `tasks.md`, archive on finish). Migration:
-`openspec init`, then move `specs/changes/*` into `openspec/changes/`.
-
-## Session tracking
-
-Forge session holds orchestration artefacts; the canonical plan lives under
-`<specsDir>/changes/<change-name>/`.
+# Plan phase — built-in specs engine
+
+For projects with `.forge/config.json` → `plan.engine: specs`. Mirrors the
+OpenSpec propose flow without the vendor CLI. Engine root is `plan.dir`
+(default `specs/`; set to `openspec` to reuse an OpenSpec tree).
+
+Change lives under `<plan.dir>/changes/<change-name>/`.
+
+## Steps
+
+1. Derive a kebab-case change name from the brainstorm outcome (e.g.
+   `add-stripe-refunds`). No date prefix while active.
+2. Create the change directory (preferred: CLI scaffold):
+
+   ```bash
+   forge change new <change-name> --capability <domain> [--capability <other>]
+   ```
+
+   Or create manually under `<plan.dir>/changes/<change-name>/` with the
+   **same layout as OpenSpec**:
+
+   **`proposal.md`** (required)
+
+   ```markdown
+   # <Change title>
+
+   ## Why
+   One or two paragraphs: problem / pressure.
+
+   ## What Changes
+   Bulleted scope — behavior, contracts, data.
+
+   ## Capabilities
+   - `<domain>`: brief — delta at `specs/<domain>/spec.md`
+
+   ## Impact
+   Affected code/areas, risks, migration notes.
+   ```
+
+   **`design.md`** (scaffold always; trim or delete when purely mechanical)
+
+   Context, decisions with alternatives, risks.
+
+   **`tasks.md`** (required)
+
+   ```markdown
+   # Tasks
+
+   ## 1. <Group name>
+   - [ ] 1.1 <Bite-sized task — exact files, expected tests>
+   - [ ] 1.2 …
+
+   ## 2. <Group name>
+   - [ ] 2.1 …
+   ```
+
+   **`specs/<capability>/spec.md`** (delta specs — required for capability work)
+
+   Same format as OpenSpec. There is **no** `deltas/` directory — deltas live
+   under `changes/<name>/specs/`:
+
+   ```markdown
+   # Delta for <Capability>
+
+   ## ADDED Requirements
+
+   ### Requirement: …
+   The system SHALL …
+
+   #### Scenario: …
+   - GIVEN …
+   - WHEN …
+   - THEN …
+
+   ## MODIFIED Requirements
+   …
+
+   ## REMOVED Requirements
+   …
+   ```
+
+   Task-writing rules (from writing-plans practice):
+   - Bite-sized: one task = one reviewable step (a test + the code to pass it).
+   - Name exact file paths where known.
+   - Each task states its verification (test command or observable behavior).
+   - Group with `##` sections — Forge reviews per group under `standard` pace.
+
+3. Confirm `tasks.md` exists and at least one delta under `specs/` when the
+   change adds/changes behavior. Apply-ready = proposal + tasks + deltas
+   (design when non-mechanical).
+4. **Spine (always) + orchestration seam** — see [../references/runtime-integrity.md](../references/runtime-integrity.md):
+
+   ```bash
+   forge spine init     # mandatory every change — fill rows or set notApplicable
+   ```
+
+   Sync-only / docs-only: `"notApplicable": "<reason>"`. Capability work: one row
+   per REQ cluster (library → runtime owner → writes → evidence).
+
+   When the spine has real rows, also `forge e2e init` — the executable
+   product-loop steps (`e2e.json`) are a **plan deliverable**: author them (or
+   task out their authoring) so verify can `forge e2e run` them.
+
+   If the change also involves workers, job queues, handlers, or cross-runtime
+   calls, `tasks.md` MUST include:
+
+   - Explicit **wiring** tasks per job kind / entry point → domain pipeline
+   - One **product-loop acceptance** task (last implement task, before
+     verify) — its output is a green `forge e2e run`
+
+   Missing spine = plan **not** ready. (`forge phase done` refuses without a
+   valid spine and, when the spine has rows, a green current e2e run —
+   keyword sniffing does not decide.)
+
+5. **Operator brief (mandatory)** — see [../references/operator-brief.md](../references/operator-brief.md):
+   write `<plan.dir>/changes/<change-name>/brief.html` — a plain-language,
+   self-contained HTML explanation of what will be built (mermaid diagrams
+   where helpful), then:
+
+   ```bash
+   forge brief stamp    # records specs hash (does NOT auto-open)
+   ```
+
+   `forge phase implement` hard-refuses while the brief is missing or stale
+   (specs edited after stamping → rewrite affected sections and re-stamp).
+
+6. Update session:
+
+   ```bash
+   forge phase plan --plan-type specs --openspec <change-name>
+   forge phase implement --tasks-total <N>
+   ```
+
+   Count tasks from `tasks.md` checkboxes. (`--openspec` carries the change
+   name for both engines.)
+
+7. Get user approval on the artefacts before implementing (unless they already said "go").
+   The brief is what the operator reviews — tell them its path and that
+   `forge brief open` launches it; never open it for them.
+
+## Compatibility
+
+Layout and conventions are identical to OpenSpec:
+
+| Path | Role |
+| ---- | ---- |
+| `<plan.dir>/specs/<cap>/spec.md` | Source of truth |
+| `<plan.dir>/changes/<name>/proposal.md` | Why / what / capabilities / impact |
+| `<plan.dir>/changes/<name>/design.md` | Technical approach |
+| `<plan.dir>/changes/<name>/tasks.md` | Checklist |
+| `<plan.dir>/changes/<name>/specs/<cap>/spec.md` | Delta specs |
+
+Switch engines without moving files:
+
+```bash
+forge init --no-openspec --plan-dir openspec
+# → .forge/config.json { "plan": { "engine": "specs", "dir": "openspec" } }
+```
+
+## Session tracking
+
+Forge session holds orchestration artefacts; the canonical plan lives under
+`<plan.dir>/changes/<change-name>/`.

package/vendor/skills/forge/phases/review.md

@@ -1,25 +1,25 @@
-# Review phase
-
-Per-task reviews happen inside [implement.md](./implement.md). This phase covers **final** review before finish.
-
-Read and follow [../skills/requesting-code-review/SKILL.md](../skills/requesting-code-review/SKILL.md).
-
-**Pace:** Check `review.final` via [../references/pace.md](../references/pace.md) / `forge status`. If pace skips final review and the session is not high-risk, write `.forge/sessions/<id>/reviews/final-review.md` with `SKIPPED (pace=…)` and proceed. High-risk sessions (money/auth/contracts/migrations) always get a final review (hard floor).
-
-Otherwise dispatch the final reviewer using [../subagents/final-reviewer-prompt.md](../subagents/final-reviewer-prompt.md) (whole-session verdict; the reviewer applies the checklist from [code-reviewer.md](../skills/requesting-code-review/code-reviewer.md)).
-
-**Model:** `forge resolve-model --tier capable` (or `standard`/`fast` when `models.bias` is `prefer-fast` and not high-risk; billing **`included`** by default). If `omitModel` is true, omit the Task `model` parameter; otherwise pass `model` exactly. Do not use metered/API models unless the user explicitly requests them.
-
-<HARD-GATE>
-Do NOT hand-pick a model slug for the final reviewer — not even "the most capable" from the host's model list. Resolver output only. On dispatch failure, re-resolve; do not substitute a slug yourself.
-</HARD-GATE>
-
-Save output to `.forge/sessions/<id>/reviews/final-review.md`.
-
-```bash
-forge phase review
-```
-
-Address Critical and Important findings before finish.
-
-Then proceed to [finish.md](./finish.md).
+# Review phase
+
+Per-task reviews happen inside [implement.md](./implement.md). This phase covers **final** review before finish.
+
+Read and follow [../skills/requesting-code-review/SKILL.md](../skills/requesting-code-review/SKILL.md).
+
+**Pace:** Check `review.final` via [../references/pace.md](../references/pace.md) / `forge status`. If pace skips final review and the session is not high-risk, write `.forge/sessions/<id>/reviews/final-review.md` with `SKIPPED (pace=…)` and proceed. High-risk sessions (money/auth/contracts/migrations) always get a final review (hard floor).
+
+Otherwise dispatch the final reviewer using [../subagents/final-reviewer-prompt.md](../subagents/final-reviewer-prompt.md) (whole-session verdict; the reviewer applies the checklist from [code-reviewer.md](../skills/requesting-code-review/code-reviewer.md)).
+
+**Model:** `forge resolve-model --tier capable` (or `standard`/`fast` when `models.bias` is `prefer-fast` and not high-risk; billing **`included`** by default). If `omitModel` is true, omit the Task `model` parameter; otherwise pass `model` exactly. Do not use metered/API models unless the user explicitly requests them.
+
+<HARD-GATE>
+Do NOT hand-pick a model slug for the final reviewer — not even "the most capable" from the host's model list. Resolver output only. On dispatch failure, re-resolve; do not substitute a slug yourself.
+</HARD-GATE>
+
+Save output to `.forge/sessions/<id>/reviews/final-review.md`.
+
+```bash
+forge phase review
+```
+
+Address Critical and Important findings before finish.
+
+Then proceed to [finish.md](./finish.md).

package/vendor/skills/forge/phases/verify.md

@@ -1,124 +1,124 @@
-# Verify phase
-
-Read and follow [../skills/verification-before-completion/SKILL.md](../skills/verification-before-completion/SKILL.md) and [../references/test-strategy.md](../references/test-strategy.md).
-
-## Required checks
-
-### 1. Audit tier 2 evidence (per task)
-
-For each completed task under `.forge/sessions/<id>/tasks/<nn>-<slug>/`:
-
-- `test-evidence.md` exists with command, exit code `0`, and pass summary (or key output lines).
-- `task-review.md` shows **APPROVED** (legacy sessions: `spec-review.md` + `quality-review.md`).
-- Evidence uses tier 2 scope (narrow) unless the task documented a tier-2 full-workspace exception.
-
-If any task lacks evidence, shows non-zero exit, or reviewers rejected test coverage → **stop** and fix or re-dispatch that task's implementer.
-
-**Do not** re-run tier 2 commands here — audit the artifacts.
-
-### 2. Tier 3 (scope from pace)
-
-After tier 2 audit passes, honor `verify.tier3` from [../references/pace.md](../references/pace.md) / `forge status`:
-
-| `verify.tier3` | Action |
-| -------------- | ------ |
-| `full-workspace` | One fresh full test per affected workspace (default thorough/standard) |
-| `affected-only` | Full test only for workspaces touched by this change |
-| `audit-tier2-only` | Do **not** run the suite; record deferral to push/CI in `verify-evidence.md` |
-
-```bash
-npm test (affected package/workspace)
-```
-
-When contracts changed and tier3 is not `audit-tier2-only`, also run tests in downstream consumer workspaces (project ecosystem-impact policy).
-
-Save to `.forge/sessions/<id>/verify-evidence.md`:
-
-```markdown
-# Verify evidence — tier 3
-
-- **Workspaces:** your-workspace, …
-- **Command:** `npm test -- path/to/scoped.test.ts`
-- **Exit code:** 0
-- **Summary:** 142/142 pass (or paste last ~30 lines)
-- **Run at:** 2026-06-07T12:00:00Z
-```
-
-Cite this file when claiming the implementation passes. Exit code must be `0` before leaving verify.
-
-### 2b. Strict typecheck — enforced at the gate, not here
-
-Tier 3 runs **tests**, and Vitest transpiles without type-checking — so green tests do
-**not** prove the code compiles under strict `tsc`. You do **not** need to run the full
-build gate to leave verify — strict typecheck is enforced automatically by the `pre-push`
-hook (diff-scoped, on every push / launcher **Publish**) and the full typecheck + tests on
-`development` by CI. If you want local certainty on the types you touched, optionally run:
-
-```bash
-npm run build:packages           # fresh dist/ so dependents resolve current .d.ts
-node scripts/agent-check.mjs     # strict typecheck + tests for the diff-affected workspaces
-```
-
-— but a clean tier-3 test audit is the bar to leave verify; the Publish/push + CI gate
-(`shared-build-gate` capability) catches any strict-mode breakage before it's shared.
-
-### 3. Runtime wiring audit
-
-Honor [../references/runtime-integrity.md](../references/runtime-integrity.md).
-
-For each requirement in the change's **capability specs** (not only `tasks.md`):
-
-- Name the **production caller** (job kind, endpoint, CLI, …) that invokes the implementing code.
-- Library-only / stub handler / false success / enqueueable-but-unhandled kind → **stop**. Add wiring or mark explicit gaps; do not advance.
-
-Record the trace in `verify-evidence.md` (a short REQ → caller table is enough).
-
-### 4. Product-loop E2E — executed, or BLOCKED
-
-Before leaving verify / claiming the change complete:
-
-1. Confirm `e2e.json` (scaffolded at plan time via `forge e2e init`) drives the **closed product loop** — not a single job slice. When the design has a producer/consumer split (analyze vs execute, proposals vs ratify), the loop is: produce artifact → consumer reads it → decision/state change → **next run's output differs from baseline**. Steps must assert domain side effects; a step list that would pass against a stubbed handler is invalid.
-2. `forge e2e run` — executes the steps sequentially and writes `e2e-results.json` (per-step exit codes, output tails, steps hash) into the session dir. A **green run** is required; results go stale if `e2e.json` changes afterwards (re-run). Prose in `verify-evidence.md` no longer satisfies the done gate. **Or**
-3. Leave an explicit **`BLOCKED`** list in `verify-evidence.md` explaining why E2E cannot run here — the done gate then refuses `done` until unblocked or the user signs `--allow-incomplete`. (`e2e.json` `notApplicable` is only for loops no command can drive — reviewers police the reason.)
-
-Keep a short loop narrative under `## Product loop` in `verify-evidence.md` as reviewer context — the gate checks the executed results, not the heading.
-
-Also enforce **job-kind closure**: every product-surface job kind is wired end-to-end or deleted from enums/API/UI before complete. And the **consumer–producer rule**: anything the UI/API reads must be proven written by the production path.
-
-Do **not** mark the change complete or advance to `done` while a critical path is stubbed, unwired, or unverified without `BLOCKED`. Green unit/tier-3 suites alone are not enough when jobs/workers/orchestration are in scope (`integrity.requireE2E`).
-
-### 5. Mechanical gate
-
-```bash
-forge spine check        # every capability row wired (library → runtime owner → writes → evidence)
-forge e2e check          # green, current e2e-results.json (steps hash matches e2e.json)
-forge defer list         # no unresolved deferrals
-forge integrity-check    # combined; forge phase done runs the same checks
-```
-
-Fix any failure before proceeding — `forge phase done|finish` refuses on the same problems.
-
-### 6. Plan completeness
-
-- Confirm every plan task is marked complete.
-- Confirm no tier 2 evidence contradicts another.
-- For OpenSpec: `openspec instructions apply --change "<name>" --json` shows expected progress.
-- Requirements met = line-by-line vs **capability specs**, not vs a narrowed task reading.
-
-```bash
-forge phase verify
-```
-
-## When to re-run tier 3
-
-- Tier 3 failed (fix, then re-run tier 3)
-- Coordinator edited code after `verify-evidence.md` was recorded
-- Quality or final reviewer flagged test gaps
-- User explicitly asks for a fresh run
-
-## When NOT to re-run
-
-- Tier 2 narrow commands — already audited; duplicating them is slow and redundant
-- Tier 3 passed and nothing changed since — do not run full suite again "for freshness"
-
-Then proceed to [review.md](./review.md) if not already done per task.
+# Verify phase
+
+Read and follow [../skills/verification-before-completion/SKILL.md](../skills/verification-before-completion/SKILL.md) and [../references/test-strategy.md](../references/test-strategy.md).
+
+## Required checks
+
+### 1. Audit tier 2 evidence (per task)
+
+For each completed task under `.forge/sessions/<id>/tasks/<nn>-<slug>/`:
+
+- `test-evidence.md` exists with command, exit code `0`, and pass summary (or key output lines).
+- `task-review.md` shows **APPROVED** (legacy sessions: `spec-review.md` + `quality-review.md`).
+- Evidence uses tier 2 scope (narrow) unless the task documented a tier-2 full-workspace exception.
+
+If any task lacks evidence, shows non-zero exit, or reviewers rejected test coverage → **stop** and fix or re-dispatch that task's implementer.
+
+**Do not** re-run tier 2 commands here — audit the artifacts.
+
+### 2. Tier 3 (scope from pace)
+
+After tier 2 audit passes, honor `verify.tier3` from [../references/pace.md](../references/pace.md) / `forge status`:
+
+| `verify.tier3` | Action |
+| -------------- | ------ |
+| `full-workspace` | One fresh full test per affected workspace (default thorough/standard) |
+| `affected-only` | Full test only for workspaces touched by this change |
+| `audit-tier2-only` | Do **not** run the suite; record deferral to push/CI in `verify-evidence.md` |
+
+```bash
+npm test (affected package/workspace)
+```
+
+When contracts changed and tier3 is not `audit-tier2-only`, also run tests in downstream consumer workspaces (project ecosystem-impact policy).
+
+Save to `.forge/sessions/<id>/verify-evidence.md`:
+
+```markdown
+# Verify evidence — tier 3
+
+- **Workspaces:** your-workspace, …
+- **Command:** `npm test -- path/to/scoped.test.ts`
+- **Exit code:** 0
+- **Summary:** 142/142 pass (or paste last ~30 lines)
+- **Run at:** 2026-06-07T12:00:00Z
+```
+
+Cite this file when claiming the implementation passes. Exit code must be `0` before leaving verify.
+
+### 2b. Strict typecheck — enforced at the gate, not here
+
+Tier 3 runs **tests**, and Vitest transpiles without type-checking — so green tests do
+**not** prove the code compiles under strict `tsc`. You do **not** need to run the full
+build gate to leave verify — strict typecheck is enforced automatically by the `pre-push`
+hook (diff-scoped, on every push / launcher **Publish**) and the full typecheck + tests on
+`development` by CI. If you want local certainty on the types you touched, optionally run:
+
+```bash
+npm run build:packages           # fresh dist/ so dependents resolve current .d.ts
+node scripts/agent-check.mjs     # strict typecheck + tests for the diff-affected workspaces
+```
+
+— but a clean tier-3 test audit is the bar to leave verify; the Publish/push + CI gate
+(`shared-build-gate` capability) catches any strict-mode breakage before it's shared.
+
+### 3. Runtime wiring audit
+
+Honor [../references/runtime-integrity.md](../references/runtime-integrity.md).
+
+For each requirement in the change's **capability specs** (not only `tasks.md`):
+
+- Name the **production caller** (job kind, endpoint, CLI, …) that invokes the implementing code.
+- Library-only / stub handler / false success / enqueueable-but-unhandled kind → **stop**. Add wiring or mark explicit gaps; do not advance.
+
+Record the trace in `verify-evidence.md` (a short REQ → caller table is enough).
+
+### 4. Product-loop E2E — executed, or BLOCKED
+
+Before leaving verify / claiming the change complete:
+
+1. Confirm `e2e.json` (scaffolded at plan time via `forge e2e init`) drives the **closed product loop** — not a single job slice. When the design has a producer/consumer split (analyze vs execute, proposals vs ratify), the loop is: produce artifact → consumer reads it → decision/state change → **next run's output differs from baseline**. Steps must assert domain side effects; a step list that would pass against a stubbed handler is invalid.
+2. `forge e2e run` — executes the steps sequentially and writes `e2e-results.json` (per-step exit codes, output tails, steps hash) into the session dir. A **green run** is required; results go stale if `e2e.json` changes afterwards (re-run). Prose in `verify-evidence.md` no longer satisfies the done gate. **Or**
+3. Leave an explicit **`BLOCKED`** list in `verify-evidence.md` explaining why E2E cannot run here — the done gate then refuses `done` until unblocked or the user signs `--allow-incomplete`. (`e2e.json` `notApplicable` is only for loops no command can drive — reviewers police the reason.)
+
+Keep a short loop narrative under `## Product loop` in `verify-evidence.md` as reviewer context — the gate checks the executed results, not the heading.
+
+Also enforce **job-kind closure**: every product-surface job kind is wired end-to-end or deleted from enums/API/UI before complete. And the **consumer–producer rule**: anything the UI/API reads must be proven written by the production path.
+
+Do **not** mark the change complete or advance to `done` while a critical path is stubbed, unwired, or unverified without `BLOCKED`. Green unit/tier-3 suites alone are not enough when jobs/workers/orchestration are in scope (`integrity.requireE2E`).
+
+### 5. Mechanical gate
+
+```bash
+forge spine check        # every capability row wired (library → runtime owner → writes → evidence)
+forge e2e check          # green, current e2e-results.json (steps hash matches e2e.json)
+forge defer list         # no unresolved deferrals
+forge integrity-check    # combined; forge phase done runs the same checks
+```
+
+Fix any failure before proceeding — `forge phase done|finish` refuses on the same problems.
+
+### 6. Plan completeness
+
+- Confirm every plan task is marked complete.
+- Confirm no tier 2 evidence contradicts another.
+- For OpenSpec: `openspec instructions apply --change "<name>" --json` shows expected progress.
+- Requirements met = line-by-line vs **capability specs**, not vs a narrowed task reading.
+
+```bash
+forge phase verify
+```
+
+## When to re-run tier 3
+
+- Tier 3 failed (fix, then re-run tier 3)
+- Coordinator edited code after `verify-evidence.md` was recorded
+- Quality or final reviewer flagged test gaps
+- User explicitly asks for a fresh run
+
+## When NOT to re-run
+
+- Tier 2 narrow commands — already audited; duplicating them is slow and redundant
+- Tier 3 passed and nothing changed since — do not run full suite again "for freshness"
+
+Then proceed to [review.md](./review.md) if not already done per task.