@gtrabanco/pi-agentic-workflow 0.1.0 → 0.2.0

package/skills/orchestration-envelope/references/TURN_CONTRACT.md

@@ -19,3 +19,37 @@
 **Single owner:** orchestration-envelope/references/TURN_CONTRACT.md. All skills load this + skill-specific additions only. Duplication forbidden. Missing reference = STOP.
 
 **Push policy supplement:** Box 4 covers the end-of-unit push. Some consumers (e.g. `execute-phase/references/PREFLIGHT.md`) define additional push rules for mid-phase commits when a PR is already open — those per-consumer supplements extend this contract and must be loaded alongside it by the consumer skill.
+
+## Hand-off grammar (versioned — read by `scripts/normative-drift.test.mjs`)
+
+Box 9's closing hand-off and box 10's machine result are ordered here, so the
+tokens they may use are declared as grammar rather than prose. Every `from`/`to`
+pair below must exist in the schema package's `WORKFLOW_TRANSITION_TABLE`, and
+every field row must be a key that package's envelope validator declares: a pair
+or a key no machine surface defines is a defect in this file, never in the table.
+
+```text
+hand-off-transitions@1
+from | to
+workflow-intent:review-spec | workflow-intent:plan-feature
+workflow-intent:plan-feature | workflow-intent:review-plan
+workflow-intent:review-plan | workflow-intent:execute-phase
+workflow-intent:plan-fix | workflow-intent:review-plan
+workflow-intent:review-plan | workflow-intent:design-feature
+workflow-intent:execute-phase | workflow-intent:review-change
+workflow-intent:review-change | workflow-intent:audit-pr
+workflow-intent:audit-pr | workflow-intent:merge
+workflow-intent:triage-issue | workflow-intent:execute-phase
+workflow-intent:status | workflow-intent:design-feature
+```
+
+```text
+hand-off-fields@1
+# machine: envelope
+object | field
+next | recommended
+next | alternatives
+next | tier
+next | suggested
+```
+

package/skills/plan-feature/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plan-feature
 user-invocable: true
-version: 3.5.1
+version: 5.0.0
 argument-hint: <NN-slug | #N> | --from-issue N | --scaffold <slug> | --next
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -25,11 +25,18 @@ one — the routed redirect gate enforces that split.
 ```
 ✓ The redirect gate ran FIRST, before any SPEC edit: undesigned input → STOP,
   print the fixed `/design-feature <slug>` block, do nothing else this turn
+✓ Then the Product-review gate ran: no current `spec-review-pass` receipt bound to
+  the recomputed snapshot → STOP with its fixed block and the `/review-spec`
+  hand-off; a candidate/verification receipt, a Plan receipt, or readiness never counts
 ✓ Designed input only: engineering half filled, artifacts written, and the
   roadmap entry registered (number, order, deps verified)
 ✓ If `plan-feature-scaffold` ran this turn: the roadmap row was re-read
   AFTER the write and literally reads `planned` — a dropped `defined→planned`
   write fails this box; do not end the turn until it's fixed
+✓ Planned, not reviewed: the ledgers are frozen, `stage: plan` readiness printed
+  `READY-FOR-REVIEW`, and the turn hands off to `/review-plan` — this skill never
+  reviews the plan it just wrote and never hands off to `/execute-phase` for a
+  plan with no current Plan review receipt
 ✓ The dependency & blocker check was RUN and its result decides which closing block is printed
 ✓ An unmet dependency? The closing block lists the complete dependency chain, deepest first, joined with ` + `
 ✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English PRs/issues/commits/SPECs unless one of the first two says otherwise
@@ -51,7 +58,8 @@ and roadmap registration match the project's real layout.
 The reference allowlist is exactly the two paths below:
 
 1. Every invocation: read [redirect gate and routing](references/ROUTING.md),
-   apply the status gate first, and stop on its exact block when instructed.
+   apply the status gate first, then the Product-review gate, and stop on its
+   exact block when instructed.
 2. Any route that can write planning artifacts: after the redirect gate permits
    routing, consume the [planning preflight](<../planning-preflight/SKILL.md>) —
    it owns the normalized repository state read and the ONE final architectural
@@ -67,21 +75,24 @@ one hop from this file, and fail closed when missing.
 ## Process
 
 1. **Redirect gate** from `ROUTING.md` — always first.
-2. **Route** from the same resource. For issue input, resolve and validate the issue
+2. **Product-review gate** from the same resource — current `spec-review-pass`
+   receipt bound to the recomputed snapshot, or STOP. No bypass flag.
+3. **Route** from the same resource. For issue input, resolve and validate the issue
    identity only; after the [planning preflight](<../planning-preflight/SKILL.md>)
    confirms that planning may write, compose the from-issue internal to produce
-   a **filled, sized SPEC product half**; then invoke `plan-feature-scaffold`,
-   which fills the engineering half and scales the artifacts to the SPEC's size
-   (XS/S → SPEC-only; M/L → full set) and registers the roadmap. The
+   a **filled, sized SPEC product half**; that internal stops at the Product-review
+   gate, so `plan-feature-scaffold` runs only once `review-spec` has passed the half:
+   it fills the engineering half, scales the artifacts to the SPEC's size (XS/S →
+   SPEC-only; M/L → full set) and registers the roadmap. The
    already-designed scoped path runs `plan-feature-scaffold` directly. Every
    path holds **one immutable planning context** — the roadmap snapshot taken
    before writing (and one issue payload when `--from-issue`) — reused across
    the internal steps; never re-fetched mid-plan.
-3. **Confirm roadmap.** Verify the feature is registered in
+4. **Confirm roadmap.** Verify the feature is registered in
    `docs/features/ROADMAP.md` with the right number, ordering, and dependencies;
    if any of the three is missing or wrong, fix the entry now — never leave
    registration for later.
-4. **Dependency & blocker check (always, before recommending execution).**
+5. **Dependency & blocker check (always, before recommending execution).**
    - Walk the feature's `Depends on:` closure (transitively): every dependency
      must be `done` **and merged**. Any unmet → the closing block recommends
      building the deepest unmet dependency first, NOT this feature.
@@ -97,6 +108,9 @@ one hop from this file, and fail closed when missing.
 - Docs only — no code, no branch (that is `execute-phase`).
 - **Never plan an undesigned feature** — the redirect gate has no bypass flag,
   ever. Do not add one, even if asked; point at `/design-feature` instead.
+- **Never plan an unreviewed Product half** — this gate has no bypass flag either.
+  Planning binds the reviewer's receipt; it may never write, widen, or "refresh"
+  one, and a receipt bound to older bytes is stale, not close enough.
 - Don't re-ask what a flag, the issue, or the docs already settle.
 - Surface conflicts (numbering clashes, dependency cycles, scope overlap) before
   writing, not after.
@@ -133,6 +147,9 @@ enables:
 
 - **Redirects to** `design-feature` when the redirect gate stops on an
   undesigned feature — never composed in-turn (planning-class, ≥-tier hand-off).
+- **Redirects to** `review-spec` when the Product-review gate stops: designed is not
+  reviewed. Its receipt is this skill's input, and `plan-feature-scaffold` binds it
+  as the Plan snapshot's Product parent.
 - `triage-issue` routes here to promote an issue to a feature (still subject to
   the redirect gate if the promoted issue is undesigned).
 - `execute-phase` executes the phases afterward (`audit-docs` audits anytime).
@@ -144,12 +161,18 @@ enables:
 - Designed input only: a planned feature with its full artifact set exists and
   is roadmap-registered — **and the roadmap row was re-read after the write and
   literally reads `planned`** (never assumed from having run the write step).
+- The two planning ledgers were frozen with the Engineering half
+  ([planning ledgers](<../../pre-execution-review/SKILL.md>)), the
+  `stage: plan` readiness preflight printed `READY-FOR-REVIEW`, and the new
+  `artifactRevisionId` is named in the hand-off. A planned unit is **not** an
+  executable unit: this skill never reviews its own plan.
 - The dependency & blocker check ran, and **the closing `→ Next:` block matches
   its result** — clean:
 
   ```
-  → Next: /execute-phase <NN> — execute every remaining phase and open the PR
-    · explicit atomic mode → /execute-phase <NN> P1
+  → Next: /review-plan <NN> — the plan is written; an independent context must
+    review it before any phase is executed
+    · the review returned PLAN-REVIEW-FAIL → this skill replans the batch, then re-reviews
     · adjust scope first → re-run /design-feature <slug>   · audit the planning docs → /audit-docs
   ```
 
@@ -168,6 +191,10 @@ enables:
     (capability closure not done). Design it first; then re-run /plan-feature <slug>.
   ```
 
+  designed but unreviewed/stale (Product-review gate stopped): the fixed
+  `PRODUCT-REVIEW GATE … BLOCKED` block from `ROUTING.md`, closing with
+  `/review-spec <NN>-<slug>`.
+
   unmet dependency and/or blocking fix-now issue:
 
   ```

package/skills/plan-feature/references/ROUTING.md

@@ -54,6 +54,47 @@ SPEC's `## Design status` marker is the SPEC-local record and the
    applies: print the block above pointing at `/design-feature "<idea>"`
    instead of a slug.
 
+## Product-review gate (after the redirect gate, before Routing)
+
+The redirect gate proves the Product half was **designed**; this proves it was
+**independently reviewed** and unchanged since. Run it before any write on every
+planning route. Issue input has no slug yet: evaluate it on the slug
+`plan-feature-from-issue` produces, just before `plan-feature-scaffold` would run.
+
+1. Read the newest `## Pre-execution review receipt v1 — spec` block in the unit's
+   `progress.md`; none → fail closed.
+2. Recompute the SPEC-stage snapshot from the bytes on disk now — exactly one
+   artifact row (`kind: spec`, `selector: spec-product-v1`) plus the current
+   `artifactRevisionId` — digested with the schema package's canonical entry (no
+   package: record `validated: manual` and compare the stored digest line by line).
+3. Accept only when all hold: contract `agentic-workflow/
+   pre-execution-review-receipt@1`, `stage: spec`, verdict `spec-review-pass`,
+   `snapshotDigest` equals step 2, zero open or unverified material findings,
+   `contextClean: true`, and under `authorExclusion: enforced` reviewer ≠ author.
+4. Refuse, never silently: **missing** · **stale** (digest or `artifactRevisionId`
+   differs — any Product write, context change, or mutate-and-revert) ·
+   **wrong-stage** (a `plan` receipt) · **substitute** (candidate `ReviewReceipt v1`
+   or staged `VerificationReceipt v1`: different contracts, never interchangeable) ·
+   **self-approved** (reused identity under enforced exclusion, or `contextClean:
+   false`) · **author-readiness** (`READY-FOR-REVIEW` licenses a review request, it
+   is not one).
+
+Fail closed — print exactly, then touch nothing else this turn:
+
+```
+PRODUCT-REVIEW GATE — <NN>-<slug> BLOCKED (<missing|stale|wrong-stage|substitute|self-approved|author-readiness>)
+Expected: current spec-review-pass receipt bound to snapshot <digest>
+Actual:   <receipt state>
+
+→ Next: /review-spec <NN>-<slug> — the Product half needs a current independent
+    review before engineering planning can start
+  · a product choice is genuinely open → /design-feature <NN>-<slug> "<question>"
+  · no bypass flag exists for this gate
+```
+
+A stale receipt is never "refreshed" by editing the block — only a new review of a
+new snapshot produces one, and `--force` is not a `plan-feature` flag.
+
 ## Routing
 
 Once the gate passes, pick the mode — first match wins:
@@ -77,7 +118,25 @@ Once the gate passes, pick the mode — first match wins:
 | You run | Detected | Routes to | Then |
 |---|---|---|---|
 | `plan-feature 14-csv-export` (not designed) | undesigned slug | — | STOP → `/design-feature 14-csv-export` |
-| `plan-feature 131` | issue #131 | `plan-feature-from-issue` → `plan-feature-scaffold` | PR carries `Closes #131` |
-| `plan-feature 14-csv-export` (designed, `defined`) | designed slug | `plan-feature-scaffold` | `execute-phase 14 P1` |
+| `plan-feature 14-csv-export` (designed, no current spec review) | unreviewed Product half | — | STOP → `/review-spec 14-csv-export` |
+| `plan-feature 131` | issue #131 | `plan-feature-from-issue` (stops at the Product-review gate) | `/review-spec` → re-run `plan-feature 131` |
+| `plan-feature 14-csv-export` (designed + reviewed) | designed slug | `plan-feature-scaffold` | `execute-phase 14 P1` |
 | `plan-feature 14-csv-export` (already `planned`) | already-planned slug | — | STOP → `/execute-phase 14 P1` (no re-scaffold) |
 | `plan-feature --next` | next `defined` roadmap entry | gate, then scaffold | `execute-phase NN P1` |
+
+## Mode grammar (versioned — read by `scripts/normative-drift.test.mjs`)
+
+The detection order above is prose for the human; this table is the machine form
+of the same routing: `flag` must be a flag this skill's `argument-hint:` accepts
+and `route` must be a skill that exists. A flag or a route no surface declares is
+a defect in this table, never in the hint.
+
+```text
+plan-mode-routes@1
+# owner: plan-feature
+mode | flag | route
+issue-derived | --from-issue | plan-feature-from-issue
+forced-scaffold | --scaffold | plan-feature-scaffold
+next-defined | --next | plan-feature-scaffold
+designed-slug | n/a | plan-feature-scaffold
+```

package/skills/plan-feature-from-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plan-feature-from-issue
 user-invocable: false
-version: 1.7.0
+version: 2.0.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -17,6 +17,12 @@ clean issue → SPEC → PR(Closes #n) trace. Writes the SPEC's **product half**
 (same two-halves convention `design-feature` uses) and must satisfy capability
 closure before handing off — a thin issue does not get a shortcut around it.
 
+**This skill stops at the Product half.** It designs, then the unit goes to
+`review-spec` for an independent Product review; engineering planning is a
+different authority's turn. Composing `plan-feature-scaffold` in the same breath
+as the design it just wrote is the bypass this separation exists to close — the
+author of a Product half cannot be the one who decides it is ready to build on.
+
 ## When to use
 
 - The `plan-feature` router calls this when the input is a GitHub issue (or
@@ -77,9 +83,14 @@ gh issue view <N> --json number,title,body,labels,state,comments
    designed` once closure is complete; set the roadmap row (added at `idea`
    first if it didn't exist) to `defined` in the same edit — the same
    `idea → defined` transition `design-feature` owns, performed here when this
-   skill is the one that satisfies closure. The `plan-feature` router then runs
-   `plan-feature-scaffold` for the engineering half + `defined → planned`
-   roadmap promotion.
+   skill is the one that satisfies closure. Then run the `stage: spec` readiness
+   preflight from the internal
+   [`evidence-grounding`](<../evidence-grounding/SKILL.md>) capability, mint the
+   current `artifactRevisionId`, and **stop**: this skill never continues into the
+   engineering half, never promotes the row past `defined`, and never composes
+   `plan-feature-scaffold` in this turn. The `plan-feature` router may scaffold only
+   after `review-spec` returns a current `spec-review-pass` receipt bound to these
+   exact bytes.
 8. **Wire traceability.** Record `#N` in the SPEC; the PR body must include
    `Closes #N` so the issue closes on merge.
 9. **Hand off — return exactly** (fixed completion report, back to the router):
@@ -88,14 +99,19 @@ gh issue view <N> --json number,title,body,labels,state,comments
    ISSUE #<N> → SPEC <slug> — size: <XS|S|M|L>
    Verdict: feature (not bug/debt — else this would have routed to triage-issue)
    Gaps closed: <n> asked / <n> defaulted (logged)   Closure: designed | handed to design-feature
+   Readiness: READY-FOR-REVIEW | NEEDS-EVIDENCE | NEEDS-DESIGN   Artifact revision: <id>
    Traceability: Closes #<N> wired
-   → scaffold next (plan-feature-scaffold)
+   → review-spec next (engineering planning is gated on its receipt; do not scaffold here)
    ```
 
 ## Guardrails
 
 - Don't silently expand scope beyond the issue — surface additions as proposals.
 - Don't open the feature branch or write code here.
+- **Don't plan engineering work here.** No Engineering half, no phases, no
+  `defined → planned` promotion, no in-turn `plan-feature-scaffold` composition:
+  the Product half this skill writes must be reviewed by `review-spec` first, and
+  readiness `READY-FOR-REVIEW` is not that review.
 - Keep the `Closes #N` link; an issue-born feature must close it.
 - **Never stamp `## Design status: designed` with a blank Capability closure
   row** — the same rule `design-feature` follows; a thin issue hands off
@@ -124,17 +140,23 @@ passing test.
 - `plan-fix` — the fix-side sibling for bug/debt issues.
 - `design-feature` — receives thin issues this skill cannot safely close
   capability closure for; both write the SPEC's product half in the same format.
-- `plan-feature-scaffold` — fills the engineering half once the product half
-  is designed.
+- `review-spec` — the mandatory next hop for every issue-derived feature: it
+  reviews and receipts the Product half this skill produced.
+- `plan-feature-scaffold` — fills the engineering half later, only once
+  `review-spec` passed. This skill never invokes it.
 - `execute-phase` — executes the phases; its PR carries `Closes #N`.
 
 ## Done when
 
-- A filled SPEC product half + planning artifacts exist, roadmap-registered.
+- A filled SPEC product half exists, roadmap-registered at `defined`, with the
+  `stage: spec` readiness block printed and the current `artifactRevisionId`
+  recorded.
 - Capability closure is satisfied (or the issue was handed off to
   `design-feature` instead of faking it) and `## Design status` is accurate.
 - The roadmap row status is `defined` (added at `idea` first if new) whenever
   `## Design status: designed` was stamped — never `defined` on a hollow
   closure, never left at `idea` once `designed` is stamped.
+- Nothing was scaffolded: no Engineering half, no phases, no `planned` write, and
+  the fixed report hands off to `/review-spec`.
 - `#N` is recorded and the PR plan includes `Closes #N`.
 - Scope gaps were resolved with the user, not assumed.

package/skills/plan-feature-scaffold/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: plan-feature-scaffold
 user-invocable: false
-version: 1.14.0
+version: 2.1.0
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >

package/skills/plan-feature-scaffold/references/SCAFFOLD_PROCESS.md

@@ -10,6 +10,24 @@
    design, decisions to confirm, branch, phases, testing requirements, and dev
    scenarios covering happy path plus reproducible empty/degraded, race, and
    outage cases. Leave no placeholders; put genuine unknowns in `decisions.md`.
+   Ground it first per
+   [`evidence-grounding`](<../../evidence-grounding/SKILL.md>) — inventory,
+   evidence, draft from frozen rows — and freeze the two planning ledgers while
+   you cut phases, never afterwards from memory:
+   [planning ledgers](<../../pre-execution-review/SKILL.md>).
+
+   - Freeze `planning-evidence.md` (M/L) or `### Planning evidence` in the SPEC
+     (XS/S) and `planning-obligations.md` (M/L) or `### Obligations` (XS/S) with
+     the column order, statuses, and homes defined **once** in
+     [`pre-execution-review`](<../../pre-execution-review/SKILL.md>) — do not
+     restate or reorder those columns here. No transcripts, no discarded
+     hypotheses; one obligation row per normative behaviour, applicable invariant,
+     affected use case, and required failure state.
+   - Cut phases only after every obligation row has a phase and a validator that
+     can fail.
+   - Rotate `artifactRevisionId` for the unit's plan artifacts on this write and
+     carry it in the hand-off. A later revert to these same bytes is a new
+     authoring event and needs a new id.
 4. **Scale by size:**
 
    - **XS/S:** SPEC + `ACCEPTANCE.md`. Its `### Phases` has checkbox tasks and at least `P1`
@@ -63,8 +81,23 @@
 5. **Register and verify.** Set the roadmap row to `planned` (`defined → planned`;
    a missing row may be added directly as `planned`). Re-read it after the write.
    If it does not literally say `planned`, reapply and re-read before continuing.
-6. **Do not branch or code.** Record the future branch in the SPEC only.
-7. **Return exactly**; the `plan-feature` caller prints the closing hand-off:
+   Obligation rows are never discharged by this step: no phase may be cut with an
+   obligation pointing at a future issue, and this skill creates no forge issue —
+   `deferred` exists only after the user amends the governing SPEC
+   (`pre-execution-review` owns the rule).
+   No obligation is discharged by this step: a phase may not be cut while an
+   obligation points at a future issue, this skill creates no forge issue, and
+   `deferred` exists only after the user amends the governing SPEC
+   (`pre-execution-review` owns the rule).
+6. **Run the `stage: plan` readiness preflight** from
+   [`evidence-grounding`](<../../evidence-grounding/SKILL.md>) (it routes to
+   `READINESS.md`) and paste its block. Only `READY-FOR-REVIEW` licenses the hand-off below;
+   `NEEDS-EVIDENCE` / `NEEDS-DESIGN` / `NEEDS-REPLAN` means this turn re-runs its
+   own step, and it is never written as, quoted as, or summarized as a review
+   PASS. Never stamp a receipt or create `planning-findings.md` rows here.
+7. **Do not branch or code.** Record the future branch in the SPEC only.
+8. **Return exactly** (the caller prints the closing `→ Next:` block, which routes
+   to `/review-plan`, never to `/execute-phase`):
 
 ```
 SCAFFOLD <NN>-<slug> — size: <XS|S|M|L>

package/skills/plan-fix/SKILL.md

@@ -1,25 +1,33 @@
 ---
 name: plan-fix
 user-invocable: true
-version: 2.7.0
+version: 3.0.1
 argument-hint: <issue-number> [<issue-number> …]
 author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
   Draft and locally commit a tightly scoped, phased fix SPEC from one or more
-  issues, then stop before push/PR and hand off to execute-phase --fix. Triggers:
-  "plan-fix", "plan a fix for issue N", "draft the fix spec".
+  issues with its planning ledgers frozen, then stop before push/PR and hand off
+  to review-plan. Triggers: "plan-fix", "plan a fix for issue N", "draft the fix
+  spec".
 ---
 
 # Plan Fix
 
-Fix-flow counterpart of `plan-feature`: draft the SPEC plus frozen acceptance,
-stop for review, then `execute-phase --fix` implements every remaining phase.
+Fix-flow counterpart of `plan-feature`: draft the SPEC plus frozen acceptance and
+the two planning ledgers, then stop. `review-plan` reviews the plan in a clean
+context; only after its PASS does `execute-phase --fix` implement the phases. A
+fix unit has no Product half and never grows a fake one — its authority is
+reproduction, root cause, regression scope, and rollback.
 
 ## Turn contract — verify before ending the turn
 
 ```
 ✓ The fix SPEC is committed on its `fix/<n>-<topic>` branch (commit sha pasted) — NOT pushed, NO PR
+✓ Both ledgers are frozen in the SPEC, `stage: plan` readiness printed
+  `READY-FOR-REVIEW`, and the `artifactRevisionId` of this write is named in the hand-off
+✓ This fix has no fabricated Product half, and the hand-off routes to
+  `/review-plan` — never straight to `/execute-phase`
 ✓ The Hand-off block was printed exactly as specified
 ✓ A multi-issue unit? The hand-off names every issue once as `#primary + #n2 + …`; a single-issue unit names only its issue
 ✓ Artifact language: explicit user instruction > the project's declared docs language > English. The CONVERSATION language never decides — a Spanish prompt still produces English artifacts unless one of the first two says otherwise
@@ -51,9 +59,14 @@ One or more GitHub issue numbers from this repo, space-separated.
   issue number or the lowest merged issue; merged SPECs retain each issue's criteria.
 - `docs/fix/<primary-issue-number>-<topic>/ACCEPTANCE.md` — the compact frozen
   finish line from `verification-contract`, retaining one criterion per issue.
+- `### Planning evidence` and `### Obligations` inside that SPEC — the two frozen
+  ledgers ([planning ledgers](<../pre-execution-review/SKILL.md>)), with the fix
+  rows `evidence-grounding` names: reproduction, root cause with code evidence,
+  regression scope, rollback path, and the affected invariant or use case. A
+  missing reproduction row is `unknown` with an owner, not "probably this".
 - Branch `fix/<primary>-<topic>` from `main`.
 - One local commit with SPEC and `docs/fix/README.md` (`pending`, all merged issues).
-- **Stop: do not push/open PR.** Hand off to `execute-phase --fix`.
+- **Stop: do not push/open PR.** Hand off to `review-plan`, then `execute-phase --fix`.
 
 ## Hard rules
 
@@ -76,6 +89,12 @@ The allowlist is exactly these five paths:
 4. Before emitting phases: load the [phase contract](<../phase-contract/SKILL.md>) for the 8-box phase-lint and phase fingerprint.
 5. Before commit: consume the [verification contract](<../verification-contract/SKILL.md>)
    and write the frozen `ACCEPTANCE.md`.
+6. While drafting: ground per [`evidence-grounding`](<../evidence-grounding/SKILL.md>)
+   and freeze both ledgers per
+   [`pre-execution-review`](<../pre-execution-review/SKILL.md>); before the
+   hand-off run evidence-grounding's `stage: plan` readiness preflight and paste
+   the block. `READY-FOR-REVIEW` licenses the hand-off; it is never a review
+   verdict, and this skill does not review its own plan.
 
 Resources are normative and one hop from this file. Missing required resource →
 stop; never approximate fixed blocks or phase rules.
@@ -90,8 +109,12 @@ Branch: fix/<primary>-<topic> (local, not pushed)
 Commit: <short hash>
 Issue set: #<primary> + #<n2> + #<n3> (print every issue in this unit; single issue → #<primary>)
 
-→ Next: review the SPEC, then /execute-phase --fix <primary> — execute every remaining phase in issue set #<primary> + #<n2> + #<n3> and open the PR
-  · explicit atomic mode → /execute-phase --fix <primary> P<n> (same issue set: #<primary> + #<n2> + #<n3>)
+→ Next: /review-plan fix-<primary> — an independent context reviews this plan and
+  these ledgers before any phase runs; /execute-phase --fix <primary> follows its
+  PLAN-REVIEW-PASS (issue set #<primary> + #<n2> + #<n3>)
+  · PLAN-REVIEW-FAIL → repair here as one batch, rotate the artifact revision, re-review
+  · a product choice is open → /design-feature, then /review-spec, then replan this fix
+  · after PASS, explicit atomic mode → /execute-phase --fix <primary> P<n> (same issue set)
   · the final `Hardening & PR` phase pushes and opens the PR with `Closes #<primary>`
     plus one `Closes #<n>` line for every other issue listed in the Issue set
   · scope looks wrong → adjust the SPEC and re-run /plan-fix

package/skills/plan-fix/references/PLANNING_PROCESS.md

@@ -116,3 +116,18 @@
     Stage the SPEC and `docs/fix/README.md`; commit
     `docs(fix): draft SPEC for #<primary>[+#<n2>+…] — <topic>`. Never push or
     open a PR. Print branch, sha, and the entrypoint's hand-off block.
+
+## Mode grammar (versioned — read by `scripts/normative-drift.test.mjs`)
+
+`plan-fix` takes no flag of its own; the hand-off flag below belongs to the skill
+it routes to. `route` must be a skill that exists and `flag` must appear in that
+skill's `argument-hint:` — the rule `plan-mode-routes@1` states for `plan-feature`,
+applied here.
+
+```text
+fix-mode-routes@1
+# owner: plan-fix
+mode | flag | route
+issue-set-planned | n/a | review-plan
+after-plan-pass | --fix | execute-phase
+```

package/skills/pre-execution-review/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: pre-execution-review
+user-invocable: false
+version: 1.5.0
+author: "Gabriel Trabanco <gtrabanco@users.noreply.github.com>"
+license: MIT
+description: >
+  Internal owner of the pre-execution review cycle and the planning ledgers:
+  independence, unioned findings, counter-evidence dismissal, no-progress,
+  `CONVERGENCE-ANOMALY`, and the evidence/obligation/findings tables. Consumed by
+  `review-spec`, `review-plan`, and the authoring skills. Not a menu entry.
+---
+
+# Pre-Execution Review Policy (internal)
+
+One owner for the rules that both pre-execution reviewers apply, so a Product
+review and a Plan review cannot drift into two different definitions of
+independence, union, or convergence. It states **policy**; it runs nothing,
+writes nothing, and emits no verdict of its own.
+
+```text
+evidence-grounding  = how an author prepares and self-checks an artifact.
+pre-execution-review = how any pre-execution reviewer judges it, and what the
+                       frozen ledgers look like.
+review-spec / review-plan = the only skills that emit a pre-execution verdict.
+```
+
+## When to use
+
+- `review-spec` / `review-plan` — before the first check and again before any
+  repeat, repair, or synthesis step.
+- `design-feature`, `plan-feature`, `plan-feature-scaffold`, `plan-fix` — when
+  writing the ledgers and when a review comes back failed.
+- Nothing else. Candidate-source review (`review-change`), merge gating
+  (`audit-pr`) and execution (`execute-phase`) keep their own contracts; this
+  skill adds no authority over them.
+
+## Hard rule — no verdicts, no edits
+
+This skill never prints `SPEC-REVIEW-PASS`, `PLAN-REVIEW-PASS`,
+`SPEC-REVIEW-FAIL`, `PLAN-REVIEW-FAIL` or `NEEDS-DESIGN` as a result of its own
+reading, and it never writes a unit artifact. Quoting a verdict shape here is a
+definition, not an issuance. A policy summary that reads like an approval is a
+contract violation — the verdict belongs to the reviewer turn that binds the
+snapshot.
+
+## The three references
+
+| Condition now | LOAD |
+|---|---|
+| Running or repairing a pre-execution review | [references/POLICY.md](references/POLICY.md) — independence, union, dismissal, diversity labels, author exclusion, untrusted content, critique/synthesis/arbitration bounds, no quorum, no-progress, batch repair, `CONVERGENCE-ANOMALY`, write-then-report |
+| Building or re-checking a snapshot digest | [references/SNAPSHOT.md](references/SNAPSHOT.md) — the one executable recipe (`scripts/pre-execution-snapshot.mjs`), what each stage binds, how a consumer re-verifies a receipt, and why a snapshot digest is not a git blob id |
+| Writing or validating a Plan-stage artifact | [references/LEDGERS.md](references/LEDGERS.md) — the planning-evidence table, the obligation ledger, the stage-aware `planning-findings.md`, the durable review mark, and who may write each |
+
+## Guardrails
+
+- **Single owner.** A caller may restate a rule only as a one-line pointer plus
+  the stage-specific detail it adds. Two copies of the union rule, the dismissal
+  rule, or the convergence fields is the drift this skill exists to prevent.
+- **Policy is not a receipt.** Reading this file proves nothing about any
+  artifact; only a reviewer turn that binds a snapshot does.
+- **No weakening.** The bounds here are ceilings *and* floors: a cycle may be
+  shorter than the budget allows, never looser than the policy allows.
+- **Vocabulary is closed.** Severity, class, role, verdict and status words are
+  exactly those named in the references. Inventing `accepted`, `waived`,
+  `mitigated`, or a fourth verdict is a contract break.
+- Docs-language and commit conventions per the project's Workflow conventions.
+
+## Done when
+
+- Every pre-execution reviewer and authoring caller points here for the shared
+  cycle and ledger rules instead of restating them, and each stage file keeps
+  only the detail that is genuinely stage-specific.