@gtrabanco/pi-agentic-workflow 0.15.1 → 0.15.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gtrabanco/pi-agentic-workflow",
-  "version": "0.15.1",
+  "version": "0.15.3",
   "description": "Pi package: canonical agentic-workflow skills, friendly slash commands, and per-command model routing.",
   "keywords": [
     "pi-package",

package/skills/audit-docs/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: audit-docs
 user-invocable: true
-version: 2.1.1
+version: 2.2.0
 argument-hint: "[--fix]"
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -156,7 +156,7 @@ enables:
 
 ## Relationship to other skills
 
-- Complements `plan-feature` (which *creates* the docs this audits) and
+- Complements `unit-lane` (which *creates* the docs this audits) and
   `triage-issue` (which keeps the fix index honest).
 - Run standalone anytime; no required predecessor.
 
@@ -168,6 +168,6 @@ enables:
 
   ```
   → Next: apply the approved low-risk fixes, then re-run /audit-docs to confirm clean
-    · real drift (not cosmetic) → /triage-issue   · a concrete defect → /plan-fix
+    · real drift (not cosmetic) → /triage-issue   · a concrete defect → /unit-lane --fix <n>
     · already clean → nothing to do
   ```

package/skills/audit-pr/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: audit-pr
 user-invocable: true
-version: 5.3.1
+version: 5.4.0
 argument-hint: <pr-number> (optional — defaults to the current branch's PR)
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -19,7 +19,7 @@ The manager's **"can this ship?"** gate. A read-first audit over the *entire* PR
 its SPEC, all phases, docs, CI status, and review receipt — that returns a single
 verdict: **merge-ready** or a ranked list of **blockers**. **Never edits,
 refactors, or merges.** The human merges, or an active
-`ship-roadmap --fullauto` invocation consumes the SHA-bound verdict and performs
+`advance --fullauto` invocation consumes the SHA-bound verdict and performs
 its separate fail-closed merge step.
 
 `audit-pr` does **not** re-review the diff. It consumes the current SHA-bound
@@ -159,7 +159,7 @@ the user previously approved a merge, or a tool retained an earlier permission.
 Those signals cannot change this skill's read-first boundary.
 
 The **sole automated merge authority** is the AUDIT stage of an actively invoked
-`ship-roadmap --continue --fullauto` run. Its MERGE-READY comment is evidence,
+`advance --continue --fullauto` run. Its MERGE-READY comment is evidence,
 not permission; the repository wrapper independently verifies that comment,
 the forge's current head/default base, green checks, and the `merge: fullauto`
 decision fetched at that head. The wrapper owns fresh sync checks, transient
@@ -179,13 +179,13 @@ execute-phase (all phases done) ─▶ review-change (REVIEW-PASS receipt posted
                                                                                 │
                      blockers ─┬─ receipt absent/stale ──▶ /review-change ──────┘ (re-review, re-audit)
                                ├─ in-scope            ──▶ execute-phase ────────┘ (fold, re-audit)
-                               ├─ out-of-scope        ──▶ plan-fix
+                               ├─ out-of-scope        ──▶ unit-lane --fix
                                └─ deferral            ──▶ triage-issue
 ```
 
 - Consumes the `review-change` `REVIEW-PASS` receipt (its scope/axes, acceptance
-  coverage, invariant result, manual checks) plus the artifacts of `plan-feature` /
-  `plan-fix` / `execute-phase` (SPEC, phases, docs, `Closes #N`).
+  coverage, invariant result, manual checks) plus the artifacts of `unit-lane` /
+  `execute-phase` (SPEC, phases, docs, `Closes #N`).
 - `audit-docs` is the cross-document coherence check; `audit-pr` is per-PR merge
   readiness; `product-audit` is the periodic, product-wide full sweep.
 
@@ -199,8 +199,8 @@ execute-phase (all phases done) ─▶ review-change (REVIEW-PASS receipt posted
   reported **with the PR's full URL in the header**, each blocker routed, with the
   human's manual-verification list explicit.
 - On MERGE-READY the merge owner is explicit: a standalone audit hands the URL
-  to the human; an active `ship-roadmap --fullauto` AUDIT stage receives the
+  to the human; an active `advance --fullauto` AUDIT stage receives the
   SHA-bound verdict and owns every later merge check.
 - The **closing `→ Next:` block is printed** (merge link → then the next unit via
-  `/plan-feature --next` or `/triage-issue`; BLOCKED → the routed fix, then re-audit).
+  `/unit-lane <unit>` or `/triage-issue`; BLOCKED → the routed fix, then re-audit).
 - Nothing was edited, refactored, or merged.

package/skills/audit-pr/references/01_MERGE_GATES.md

@@ -6,14 +6,14 @@ A gate that can't be confirmed is a **blocker**, not a pass — never assume gre
 | Gate | What it means | Blocker when |
 |---|---|---|
 | **Acceptance coverage** | The receipt's acceptance-coverage field accounts for every SPEC acceptance criterion (review-change verified the mapping). This gate confirms the receipt *names* the criteria — it never remaps diff hunks to criteria itself. | The receipt omits a criterion the SPEC lists, or its coverage field is absent/generic. |
-| **All phases complete** | Feature: every phase in `PLAN.md`/`TASKS.md` is done and logged in `progress.md`. Fix: the SPEC is fully implemented. | Any unchecked task or unimplemented phase without an explicit, tracked deferral. |
+| **All phases complete** | Feature: every task in the unit doc's `Tasks` section is done and logged in its `Progress log`. Fix: the SPEC is fully implemented. | Any unchecked task or unimplemented phase without an explicit, tracked deferral. |
 | **Scope integrity (creep)** | The PR implements the SPEC and no more; out-of-scope work was split out. | Undocumented scope creep, or in-scope work missing. |
 | **Docs updated** | Every "Affected docs" criterion is satisfied; per-phase docs (`progress`/`testing`/`known-issues`/`decisions`) reflect reality; the doc map still resolves. **Never merge with documentation still pending.** | A doc the map or SPEC requires is stale, missing, pending, or contradicts the code. |
-| **Traceability** | `Closes #N` is in the PR body when the work is issue-born (from `plan-feature-from-issue` or `plan-fix`); the roadmap/fix-index entry matches, is **still present** (removed only *after* merge, never before), and carries the linked PR reference (`done · [#<pr>](<pr-url>)`). | Issue-born work without `Closes #N`; a roadmap/index entry out of sync; the entry dropped before merge; or a `done` row without its PR link. |
+| **Traceability** | `Closes #N` is in the PR body when the work is issue-born (from `/unit-lane --from-issue <n>` or `/unit-lane --fix <n>`); the roadmap/fix-index entry matches, is **still present** (removed only *after* merge, never before), and carries the linked PR reference (`done · [#<pr>](<pr-url>)`). | Issue-born work without `Closes #N`; a roadmap/index entry out of sync; the entry dropped before merge; or a `done` row without its PR link. |
 | **Verification gate / CI** | The project's gate passes — type-check, tests, build — and `statusCheckRollup` is green at the current head. | Any required check failing, pending, or absent where the project requires one. |
 | **Mergeability** | Branch is off the default base, independently mergeable (no conflicts), not stacked on another PR, not draft. | Wrong base, conflicts, stacked dependency, or still draft. |
 | **Review receipt** | A current `REVIEW-PASS` receipt is posted on the PR: the newest comment carrying `<!-- review-change:pass sha=<40-hex> contract=v1 -->` whose `sha` equals the PR's current head SHA. Its scope/axes, acceptance coverage, invariant result, and manual checks are the review evidence this audit consumes. | Receipt absent, or its marker `sha` predates the current head (any later commit voids it). The blocker routes to `/review-change`; never re-review the diff from here (AC 13). |
-| **Closure integrity** | The governing **feature** SPEC's capability closure was taken and recorded — `design-feature` was actually run, not bypassed. Fix-governed PRs: `n/a` (no closure block by design). | A present `Capability closure` block has a blank row, or a resolved non-`n/a` row with no matching acceptance criterion. |
+| **Closure integrity** | The governing **feature** SPEC's capability closure was taken and recorded — the lane's `design` step was actually run, not bypassed. Fix-governed PRs: `n/a` (no closure block by design). | A present `Capability closure` block has a blank row, or a resolved non-`n/a` row with no matching acceptance criterion. |
 | **Scope integrity (descope)** | An issue born during this unit that maps to an unmet SPEC acceptance criterion or phase task has a matching, user-approved, dated `## Amendments` entry — descoped scope was recorded, not silently exported. Detection is two-path: a slug/issue-number text match, **or** an issue linked from an `## Amendments` row (`#89`) — either is sufficient to enumerate the issue, so a descoped issue with a generic title/body is not invisible to the gate. | An issue born since branch divergence that references this unit (by either detection path) maps to an unmet criterion/task with no matching `## Amendments` entry, or an `## Amendments` row that is undated, unapproved, or unlinked to an issue. |
 | **Architectural invariants** | The **receipt** records the invariant result review-change took against the optional project invariant document; this gate confirms that result is explicit (`pass | blocker | n-a`) and does not reclassify it (AC 13). No document → `n/a: no project invariants declared`, not a blocker. | The receipt's invariant result is absent/ambiguous, or a recorded `blocker`/`violates`/`introduces`/`changes` lacks the cited decision the review surfaced. |
 | **Hygiene — tree clean** | `git status --porcelain` is empty at the audited head: every artifact is committed, so nothing rides along to the next conversation (the field failure of issue #182). | Any modified or untracked path — the blocker names each one. |

package/skills/audit-pr/references/02_CLOSURE_AND_SCOPE_GATES.md

@@ -17,15 +17,15 @@
 >   decision was *taken and recorded*, never that UI/API surface exists. Never
 >   push a blank row into inventing surface to pass this gate.
 > - **Feature SPEC, block absent** → the SPEC predates or bypassed
->   `design-feature`. Never a blocker — emit a dated **warning**, PR still
+>   `unit-lane`. Never a blocker — emit a dated **warning**, PR still
 >   merges:
 >   ```
 >   design-debt: closure absent, SPEC predates the rule (dated <YYYY-MM-DD>)
 >   ```
 >   This warning is itself the **retrofit trigger**: the next unit of work that
->   touches this feature must fill the closure via `/design-feature <slug>`
+>   touches this feature must fill the closure via `/unit-lane <slug>`
 >   (upsert — fills only the missing rows, destroys nothing recorded) *before*
->   that new work is planned. See `design-feature`'s upsert semantics for the
+>   that new work is planned. See `unit-lane`'s design-step upsert semantics for the
 >   other half of this contract.
 
 > **`done` ≠ merge-ready.** A unit flips to `done` when its PR opens (built, not
@@ -96,8 +96,7 @@ verdict:
    feature unit — its named `— spec` parent re-derives the same way. Bound artifacts
    are frozen: new implementation-phase files are allowed, edits to a bound artifact
    are not. Stale, missing, wrong-stage **or impossible-timeline** lineage → **BLOCKED**,
-   `→ Next: /review-plan <unit>` (or `/review-spec <unit>` when the parent is the
-   broken link). A `SPEC-REVIEW-PASS` never satisfies the plan hop, and vice versa.
+   `→ Next: /unit-lane <unit>` (the lane's `review` step re-derives the artifact). A `SPEC-REVIEW-PASS` never satisfies the plan hop, and vice versa.
 2. **Obligations are closed.** Every row of the unit's obligation ledger is
    `verified` — with the validator that ran on this candidate — or an explicit
    `n/a: <reason>`. Any `planned`, `in-progress`, blank, or `deferred` row is

package/skills/audit-pr/references/03_AUDIT_PROCESS.md

@@ -53,5 +53,5 @@
    SHA re-posts (newest wins) — and it **refuses to post for a BLOCKED verdict**,
    so the page never shows a stale green flag.
 8. **Report** — the verdict block below, always headed by the PR's full URL.
-   In an active `ship-roadmap --fullauto` AUDIT stage, return the verdict to the
+   In an active `advance --fullauto` AUDIT stage, return the verdict to the
    conductor; never run its merge wrapper from this skill.

package/skills/audit-pr/references/04_VERDICT.md

@@ -27,14 +27,14 @@ Before merge, a human should still verify:
   also print the closure bullet (a warning never blocks, so it co-occurs with a
   MERGE-READY verdict; the two lines print together, never one instead of the other):
   · MERGE-READY, standalone/manual audit → you merge: <full PR URL>, then
-    /plan-feature --next (the next roadmap unit) or pick an issue with /triage-issue
-  · MERGE-READY inside active ship-roadmap --fullauto → return this SHA-bound
+    /unit-lane <next-roadmap-unit> (the next roadmap unit) or pick an issue with /triage-issue
+  · MERGE-READY inside active advance --fullauto → return this SHA-bound
     verdict to the conductor; it runs the transient merge wrapper
   · BLOCKED → clear the top blocker (routed above), then re-run /audit-pr
   · Receipt absent/stale blocker → /review-change (re-review at the head), then
     re-run /audit-pr — never re-review from this audit
   · Closure warning (in addition to the verdict above) or a closure blocker →
-    /design-feature <slug> — fills the missing closure rows (upsert, destroys
+    /unit-lane <slug> — re-runs the design step to fill the missing closure rows (upsert, destroys
     nothing) before further work on this feature is planned; re-run /audit-pr after
   · Scope-bleed blocker → record the missing `## Amendments` entry (user-approved,
     dated, linking the issue) in the governing SPEC, or re-classify the issue as

package/skills/audit-pr/references/05_ROUTING_AND_GUARDRAILS.md

@@ -4,7 +4,7 @@
   re-run `audit-pr`) — never re-review from here.
 - **Incomplete in-scope work** → fold into this branch via `execute-phase`
   (the relevant phase or `--fix`); re-run `audit-pr` after.
-- **Out-of-scope defect surfaced** → `plan-fix` (new fix entry), not this PR.
+- **Out-of-scope defect surfaced** → `/unit-lane --fix <n>` (new fix entry), not this PR.
 - **Deferred finding lacking a home** → `triage-issue` to file + classify it.
 - **Stale/missing docs** → update per the doc map (often a quick `execute-phase`
   doc commit), then re-audit.
@@ -15,7 +15,7 @@
 - **Read-first verdict. Never push, edit, refactor, or merge.** Its only forge
   write is the **MERGE-READY comment** (Process step 7 — idempotent,
   comment-only, never a commit tag). Fullauto merge execution belongs only to
-  the active `ship-roadmap --fullauto` conductor.
+  the active `advance --fullauto` conductor.
 - **Never re-review the diff.** The `REVIEW-PASS` receipt is the review evidence;
   a missing/stale receipt is a blocker routed to `/review-change`. The audit does
   not compose `review-change`, rescan axes, judge test quality, remap diff hunks

package/skills/discover-repository-state/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: discover-repository-state
 user-invocable: true
-version: 1.2.1
+version: 1.2.2
 description: >
   Discover repository evidence and write a frozen Normalized Repository State.
   Produces verified repository evidence and keeps facts, decisions, planned
@@ -79,6 +79,5 @@ If a contradiction was recorded:
 
 Otherwise:
 
-→ Next: /plan-feature <slug> — plan from frozen facts
-  · implementation-ready feature → /execute-phase <NN>
-    (planned is not executable: no current `PLAN-REVIEW-PASS` → /review-plan <NN>)
+→ Next: /unit-lane <slug> — triage and run the lane from frozen facts
+  · already-triaged unit → /execute-phase <NN>

package/skills/execute-phase/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: execute-phase
 user-invocable: true
-version: 5.0.0
+version: 5.0.1
 argument-hint: <NN-slug> [P<k>|step] [--max-attempts N] [--force]
 allowed-tools: [Bash, Read, Edit, Write, MultiEdit]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"

package/skills/execute-phase/references/DESCOPE.md

@@ -42,4 +42,4 @@ from the triage catalog, not step descopes):
 `audit-pr`'s obligation-closure check all key off this same `## References` log
 — it is the single authoritative record of every descope, defined once here.
 Nothing else in the pre-execution route creates an issue: a missing or failed
-`PLAN-REVIEW-PASS` is closed by `/review-plan`, never by a tracker item.
+the lane's `review` step closes it, never a tracker item.

package/skills/fold-findings/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fold-findings
 user-invocable: true
-version: 1.6.0
+version: 1.7.0
 argument-hint: [finding-id …]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -123,9 +123,9 @@ frozen class is `replan-in-unit` or `decision-required`, nothing folds: no
 `folded: yes` flips, no commits. The receipt records the `REPLAN-ROUTE` branch
 and every retained (unfolded) row id, and the loop stops. The consumer is the
 conclusion the already-run router printed, never the invocation itself: on
-`route: replan` the planner it named — `/plan-fix <n>` for a fix unit or
-`/plan-feature <slug>` for a feature unit; on `route: decision` stop and
-surface the decision to the user, never a planner. `<unit>` is the bare folder number or the full slug (both resolve). The invocation
+`route: replan` the planner command it printed — `/unit-lane <slug>` for a
+feature unit or `/unit-lane --fix <n>` for a fix unit; on `route: decision` stop
+and surface the decision to the user, never a planner. `<unit>` is the bare folder number or the full slug (both resolve). The invocation
 `node scripts/unit-route.mjs <unit>` is the discovery step the fold already
 ran; it is never the recommendation.
 
@@ -173,7 +173,7 @@ or touched outside the queue.
   · all FOLDED (<F1> + <F2> + …) → /review-change — re-review the branch now that all listed findings are fixed
   · any DISPUTED (<F1> + <F2> + …) → user decision — resolve every evidenced dispute without creating backlog
   · any BLOCKED (<F1> + <F2> + …) → supply the listed missing inputs, then re-run /fold-findings
-  · any REPLAN (<F1> + <F2> + …) → /plan-fix <n> or /plan-feature <slug> — the planner appends the proposed phases to the unit's SPEC, the user confirms them, then a fresh /review-plan must pass before /execute-phase on this unit
+  · any REPLAN (<F1> + <F2> + …) → /unit-lane <slug> or /unit-lane --fix <n> — the lane re-runs its plan step, appends the phases to the unit's SPEC; its review step gates before /execute-phase on this unit
   · any DECISION (<F1> + <F2> + …) → stop and surface the decision to the user — a `route: decision` conclusion names no planner, so the unit waits on the user before any plan or code change
 ```
 
@@ -182,8 +182,8 @@ several lines, never joined into one prose line.
 
 Replace placeholders with every actual affected finding ID before printing; never
 print `<F2>`, `…`, or a single representative ID in a live hand-off. Resolve the
-`/plan-fix <n>` / `/plan-feature <slug>` unit argument the same way — never carry
-`<n>` or `<slug>` into a live hand-off.
+`/unit-lane <slug>` / `/unit-lane --fix <n>` unit argument the same way — never
+carry `<slug>` or `<n>` into a live hand-off.
 
 ## Closing-block decision branch (choose one, at emission)
 
@@ -193,7 +193,7 @@ decision to skip.
 
 | Batch state | Branch | `→ Next:` (consumer) |
 |---|---|---|
-| freeze-batch (≥ 1 replan-class row) | `REPLAN-ROUTE` | `/plan-fix <n>` (fix) or `/plan-feature <slug>` (feature) when the router concludes `replan` — user confirms, fresh `/review-plan` passes, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user — the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran) |
+| freeze-batch (≥ 1 replan-class row) | `REPLAN-ROUTE` | `/unit-lane <slug>` (feature) or `/unit-lane --fix <n>` (fix) when the router concludes `replan` — user confirms, the lane's `plan` step appends the phases and its `review` step gates, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user — the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran) |
 | `all-repair-in-place` + docs-only + no folded row severity `high` + prior consumer skip decision | `RE-REVIEW-SKIPPED` | skip — consumer has explicitly decided to skip the re-review |
 | `all-repair-in-place` + docs-only + no folded row severity `high` | `RE-REVIEW-OPTIONAL` | `/review-change` (default, delta mode) — or the consumer's recorded skip decision |
 | empty batch (class `none`) | `RE-REVIEW-OPTIONAL` | `/review-change` by default — safe: the head is unchanged |

package/skills/fold-findings/references/FOLD_PROCESS.md

@@ -43,7 +43,7 @@
 
    | Condition over the taken batch | Batch class | Fold behavior |
    |---|---|---|
-   | ≥ 1 row with frozen class `replan-in-unit` or `decision-required` | `frozen (replan present)` | **freeze-batch** — nothing folds, no `folded: yes` flips, no commits; the receipt records the REPLAN-ROUTE and every retained (unfolded) row id; the loop stops; the consumer is the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran), where `<unit>` is the bare folder number or the full slug (both resolve): on `route: replan` the planner — `/plan-fix <n>` (fix) or `/plan-feature <slug>` (feature) — user confirms, fresh `/review-plan` passes, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user, never a planner |
+   | ≥ 1 row with frozen class `replan-in-unit` or `decision-required` | `frozen (replan present)` | **freeze-batch** — nothing folds, no `folded: yes` flips, no commits; the receipt records the REPLAN-ROUTE and every retained (unfolded) row id; the loop stops; the consumer is the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran), where `<unit>` is the bare folder number or the full slug (both resolve): on `route: replan` the planner command the router printed — `/unit-lane <slug>` (feature) or `/unit-lane --fix <n>` (fix) — the lane appends the phases and its `review` step gates, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user, never a planner |
    | all taken rows foldable, none replan-class | `all-repair-in-place` | fold as today (group → fix → gate → commit → flip) |
    | empty queue (zero findings taken) | `none` | receipt only |
 
@@ -58,11 +58,12 @@
    `DISPUTED <evidence → user decision>`; never edit classification or create an
    issue.
 9. **Replan.** If the smallest correct group exceeds a reviewable correction,
-   run `node scripts/unit-route.mjs <unit>` — its `route: replan` line names the
-   planner (`/plan-feature <slug>` or `/plan-fix <n>`) that appends the proposed
+   run `node scripts/unit-route.mjs <unit>` — its `route: replan` line prints the
+   planner command (`/unit-lane <slug>` for a feature, `/unit-lane --fix <n>` for
+   a fix) that appends the proposed
    phases to the unit's SPEC. The `<unit>` argument accepts the bare folder number
-   or the full slug (both resolve). After the user confirms and a fresh
-   `/review-plan <unit>` passes, `/execute-phase <unit>` completes them and ticks
+   or the full slug (both resolve). After the user confirms and the lane's
+   `review` step passes, `/execute-phase <unit>` completes them and ticks
    the rows. When the router concludes `route: decision` instead — a
    `decision-required` row with no replan row — stop and surface the decision to
    the user; no planner runs until the user decides.

package/skills/orchestration-envelope/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: orchestration-envelope
 user-invocable: false
-version: 2.2.0
+version: 2.2.1
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -36,8 +36,9 @@ copy a second schema here.
   driver appends `renderOutputInstruction(skill)` to that invocation. It has
   the small model-owned fields: outcome, next intent/targets, blockers,
   questions, discoveries, and evidence references.
-- `ship-roadmap` is the conductor, not a worker profile: it keeps its native
-  terminal `SHIP:` banner and is parsed by its own fixed turn contract.
+- `advance` (the companion pi package command) is the conductor, not a worker
+  profile: it runs as deterministic code over the sensor envelope and never
+  emits a worker SkillOutcome.
 - Interactive invocations emit their normal human-readable reports; no driver
   result is required.
 

package/skills/phase-contract/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: phase-contract
 user-invocable: false
-version: 1.0.5
+version: 1.0.6
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
   Internal contract: the single owner of the eight phase-lint rules, the fixed
   PASS/BLOCKED result, and the normalized phase fingerprint. Consumed by
-  plan-feature-scaffold, plan-fix, and execute-phase. Not a menu entry.
+  `execute-phase` and the lane's `plan` step. Not a menu entry.
 ---
 
 # Phase Contract (internal)
@@ -18,8 +18,7 @@ the same rules before any edit. Nothing else may define what a valid phase is.
 
 ## When to use
 
-- `plan-feature-scaffold` — lint every phase of a feature plan before emission.
-- `plan-fix` — lint every phase of a fix SPEC before commit.
+- The lane's `plan` step — lint every phase before emission.
 - `execute-phase` — phase-lint pre-flight guard before editing a phase.
 - Templates store the contract version + fingerprint + lint result, never the
   eight rules (they point here).

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

@@ -1,14 +1,16 @@
 ---
 name: pre-execution-review
 user-invocable: false
-version: 2.5.1
+version: 2.6.0
 author: "Gabriel Trabanco <1969593+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.
+  `execute-phase`, `review-change`, and the lane's authoring steps for the
+  **planning-ledger shapes and ownership**; the pre-execution verdict owners
+  (`review-spec`/`review-plan`) were retired by feature 61. Not a menu entry.
 ---
 
 # Pre-Execution Review Policy (internal)
@@ -22,15 +24,16 @@ writes nothing, and emits no verdict of its own.
 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.
+lane (design/plan/review steps) = the surviving pre-execution path; feature 61
+                       P8b retired the standalone review-spec / review-plan
+                       verdict skills, so this pack now owns the ledger shapes
+                       the lane and execute-phase consume, not a verdict gate.
 ```
 
 ## 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.
+- The lane's `plan`/`review` steps — 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.

package/skills/pre-execution-review/references/POLICY.md

@@ -1,6 +1,14 @@
+## Status (feature 61 P8b)
+
+`review-spec` and `review-plan` are retired and
+absorbed into the lane. This document now governs the **planning-ledger shapes
+and ownership** (`LEDGERS.md`) that `execute-phase` and `review-change` consume;
+the spec/plan review-cycle semantics below are retained for the legacy units
+that still carry those receipts and are not applied by any live skill.
+
 ## The pre-execution review cycle
 
-Both `review-spec` and `review-plan` run this cycle. The stage files add only
+Both `review-spec` and `review-plan` ran this cycle. The stage files added only
 what is specific to their artifact set.
 
 ### 1. Independence
@@ -97,10 +105,11 @@ outside this policy and can never be translated into a PASS.
 
 A **third cycle never** starts without explicit user instruction: after two
 consecutive unconverged cycles the orchestrator's `stop-review-loop-cap` refusal
-stops a further `review-spec`/`review-plan` invocation, names `design-feature` as
+stops a further spec/plan review-cycle invocation, names the lane's `design` step
+as
 the human route, and a PASS resets the count. An unconverged loop ends in the
 `needs-design` verdict where the verdict vocabulary sanctions it (the spec stage)
-and in the refusal plus `design-feature` routing at the plan stage. The guards
+and in the refusal plus the lane's `design` routing at the plan stage. The guards
 above gate **blind re-reviews** — an identical snapshot with the identical
 question — and never a repair performed in response to a persisted verdict: a
 repair turn whose input is a FAIL/NEEDS-DESIGN receipt produces a new snapshot by
@@ -115,9 +124,9 @@ a count and never waives a finding.
 - A PASS earned by dropping a finding to `info`, by narrowing a check, or by
   editing a validator/test to accept the artifact.
 - A silent second cycle, a silent dismissal, or a silent substitute receipt.
-- An automatic forge issue. No route in the pre-execution set — `evidence-grounding`
-  readiness, `review-spec`, `review-plan`, `plan-feature-scaffold`, `plan-fix`,
-  `execute-phase`, `workflow-status`, `ship-roadmap`, `review-change`,
+- An automatic forge issue. No route in the pre-execution set — the lane's
+  `research`/`design`/`plan`/`review` steps, `execute-phase`, `workflow-status`,
+  `advance`, `review-change`,
   `audit-pr` — creates one for a planning gap, and none defers
   an obligation to a future issue: the row stays in the unit's ledger, open, until
   the **user** amends the governing SPEC. A blocker that says "file an issue" is a
@@ -142,8 +151,8 @@ One rule, same shape for every consumer:
   and obligation ledgers, built from the artifacts as they stand today — and leave
   `ACCEPTANCE.md`, `PLAN.md`, `TASKS.md`, the phase commits and any older receipt
   byte-identical. Rewriting an old verdict, its digest, or its date is forgery.
-- **Re-review, then resume.** The adopted unit runs `/review-plan` like any other and
-  `execute-phase` resumes **only** on that current `PLAN-REVIEW-PASS`. A pre-28 unit
+- **Re-review, then resume.** The adopted unit re-runs the lane's `review` step like any other and
+  `execute-phase` resumes **only** on that current verdict. A pre-lane unit
   is never grandfathered in on the strength of its roadmap status.
 - **No retroactive defect.** A missing ledger means the unit predates the gate, not
   that its author was wrong; report it as `legacy`, never as a finding against them.

package/skills/product-audit/SKILL.md

@@ -2,7 +2,7 @@
 name: product-audit
 user-invocable: true
 disable-model-invocation: true
-version: 3.2.1
+version: 3.3.0
 metadata:
   opencode/autoinvoke: false
 argument-hint: <path-or-area> (optional — defaults to the whole product)
@@ -117,7 +117,7 @@ Verdict: <one-line honest health verdict>
   (none — <why>)
 
 ### Roadmap — add
-  - <feature> — from: F<k> — <rationale & opportunity> — route: plan-feature
+  - <feature> — from: F<k> — <rationale & opportunity> — route: /unit-lane --from-issue <n>
   (none — <why>)
 
 ### Roadmap — remove / revise
@@ -126,7 +126,7 @@ Verdict: <one-line honest health verdict>
 
 ### Tooling — register / re-design
   - <skill|MCP> — register in AGENTS.md (Optional review extras): <why> — route: user edits AGENTS.md
-  - <skill|MCP> — would change <feature> scope: <why> — route: /design-feature <slug>
+  - <skill|MCP> — would change <feature> scope: <why> — route: /unit-lane <slug>
   (none — <why>)
 
 ## Manual-verification checklist (what automation can't confirm)
@@ -134,7 +134,7 @@ Verdict: <one-line honest health verdict>
 
 Finding set: F<k> + F<j> + F<m> (print every proposed finding; one finding → F<k>)
 → Next: /triage-issue <id> F<k> F<j> F<m> — classify the complete finding set in one batch (opens the ones that warrant it)
-  · accepted bug/debt → /plan-fix   · accepted capability → /plan-feature
+  · accepted bug/debt → /unit-lane --fix <n>   · accepted capability → /unit-lane --from-issue <n>
   · nothing to act on → the persisted report is the record; move on
 ```
 
@@ -159,12 +159,12 @@ security items to track first").
   order, never a different letter per problem type. Once persisted, ids are
   frozen: a later audit gets a new audit id, never renumbers an old file; cross-audit
   lineage lives only in Delta mappings as `<audit-id> F<k>`, never global slugs or
-  replaced ids. When the user accepts, route: `triage-issue` files/classifies,
-  `plan-feature` adds roadmap work, `plan-fix` scopes a concrete fix.
+  replaced ids. When the user accepts, route: `triage-issue` files/classifies, `/unit-lane`
+  adds roadmap work or scopes a concrete fix.
 - **Never registers tooling or edits `AGENTS.md`.** The tooling sweep proposes a
-  skill/MCP to register, but the user (or a routed `design-feature` run)
+  skill/MCP to register, but the user (or a routed `/unit-lane <slug>` run)
   performs the edit; a scope-affecting discovery routes to
-  `/design-feature <slug>`, which the user approves.
+  `/unit-lane <slug>`, which the user approves.
 - Platform-adaptive: run only applicable axes; always list what you skipped and why.
 - **No silent caps.** If you sampled, prioritized, or time-boxed a dimension, say
   so — never present partial coverage as exhaustive.
@@ -198,10 +198,10 @@ product-audit (whole product, all axes, periodic)
    ├─ composes review-change axes (codebase-wide) + audit-docs (doc coherence)
    ├─ mines feature docs (decisions / known-issues / architecture-notes)
    ├─ sweeps installed skills / connected MCP servers (product-wide, periodic)
-   └─ proposes ─┬─ Issues to open ........ ▶ triage-issue / plan-fix
-                ├─ Roadmap: add .......... ▶ plan-feature
+   └─ proposes ─┬─ Issues to open ........ ▶ triage-issue / unit-lane --fix
+                ├─ Roadmap: add .......... ▶ unit-lane --from-issue
                 ├─ Roadmap: remove/revise  ▶ triage-issue / roadmap edit   (user decides)
-                └─ Tooling: register/re-design ▶ user edits AGENTS.md / design-feature
+                └─ Tooling: register/re-design ▶ user edits AGENTS.md / unit-lane
 ```
 
 - Broader than `review-change` (one change) and `audit-pr` (one PR); subsumes
@@ -221,5 +221,4 @@ product-audit (whole product, all axes, periodic)
   with the next incremental audit id, and printed in chat.
 - Nothing else was fixed, filed, or changed — the user decides what to act on.
 - The **closing `→ Next:` block is printed** — typically a batch
-  `/triage-issue <id> F<k> …` for the proposed issues, then `/plan-feature` /
-  `/plan-fix` for the accepted work.
+  `/triage-issue <id> F<k> …` for the proposed issues, then `/unit-lane` for the accepted work.

package/skills/product-audit/references/AUDIT_PROCESS.md

@@ -32,7 +32,7 @@ step (2–5). Each item ends with exactly one fallback; never pick another one m
    inventory freshness**: cross-check `docs/CAPABILITIES.md` against the code —
    roles, permissions, or cross-cutting subsystems present in the code but
    missing from the inventory (or vice versa) are a Process & docs finding
-   (`design-feature`'s Integration closure is only as good as this file). If
+   (`unit-lane`'s design step Integration closure is only as good as this file). If
    the project has no inventory file, propose seeding it from the template —
    a finding, never an auto-fix.
 4. **Mine accumulated suggestions** — read every feature folder's `decisions.md`,

package/skills/resolve-repository-state/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: resolve-repository-state
 user-invocable: true
-version: 1.2.1
+version: 1.2.2
 argument-hint: <contradiction-id>
 description: >
   Resolve an explicit Normalized Repository State contradiction. This is the
@@ -74,7 +74,6 @@ If human input is required:
 Otherwise:
 
 → Next: resume the interrupted workflow named by `Reported by` — continue from the resolved snapshot
-  · planning was interrupted → /plan-feature <slug>
+  · planning was interrupted → /unit-lane <slug>
   · implementation was interrupted → /execute-phase <NN>
-    (only while its `PLAN-REVIEW-PASS` is still current → else /review-plan <NN>)
   · review, audit, or status was interrupted → rerun that same skill

package/skills/review-change/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-change
 user-invocable: true
-version: 3.7.1
+version: 3.8.0
 argument-hint: <path-or-glob> [--adversarial N] [--synthesize]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -42,8 +42,8 @@ finding.
 ## Review-end turn boundary
 
 On `REVIEW-FAIL` or `NEEDS-DECISION`, this skill **ends at the report**: it
-never invokes `/fold-findings`, `/execute-phase`, `/plan-feature`,
-`/design-feature` or `/triage-issue` — those are separate user-initiated invocations,
+never invokes `/fold-findings`, `/execute-phase`, `/unit-lane` or
+`/triage-issue` — those are separate user-initiated invocations,
 run in a fresh turn (a programmatic outer driver may compose the same
 sequence in-turn, per `REVIEW_PROCESS.md`). The review's only mutations are the
 ledger commit (persist step 11) and, on `REVIEW-PASS` with a PR, the

package/skills/review-change/references/ADVERSARIAL_RECOMMENDATION.md

@@ -23,7 +23,7 @@ model identity, so this skill never tries; it states the condition in prose
 and lets the human (or the orchestrator that knows which model is running)
 judge it.
 
-**N ladder (fixed).** `N=2` is the default (the `ship-roadmap` floor). Bump to
+**N ladder (fixed).** `N=2` is the default (the `advance` floor). Bump to
 `N=3` when either holds: the change has a security/auth surface, or all
 available reviewers share one model family (the third reviewer buys back some
 of the decorrelation a single family can't provide). `N>3` is **explicitly

package/skills/review-change/references/ADVERSARIAL_SETUP.md

@@ -11,7 +11,7 @@ fused table.
 no message (today's default). `--adversarial` passed **without** a valid N
 (no number given, or a number `< 2`) → usage error: state that `--adversarial`
 needs an integer N≥2 and fall back to the single-reviewer path — never
-silently run 1. `ship-roadmap`'s hard floor always passes `N=2`.
+silently run 1. `advance`'s hard floor always passes `N=2`.
 
 **Why N reviewers.** A single adversarial, context-clean reviewer (see the
 turn-contract box) decorrelates some blind spots; running N independent

package/skills/review-change/references/OUTPUT_AND_GUARDRAILS.md

@@ -22,16 +22,16 @@ lost, and none becomes reviewer-created backlog (D3):
 
 - **fix-now** → persisted to the unit's `review-findings.md` fold ledger, then
   routed to the current phase's fold cycle (`/fold-findings`, invoked after this review ends)
-  — never a tracked issue, never `plan-fix`. Classification honors
+  — never a tracked issue, never a standalone replan. Classification honors
   `review-implementation`'s **current-unit contract**: in-scope defects are
   always fix-now / replan-in-unit — never a postpone/tradeoff/wontfix/new-issue
   escape.
 - **fix-now / `replan-in-unit`** (too large to fold as-is) → keeps its fix-now
   class and ledger row; run `node scripts/unit-route.mjs <unit>` — its
-  `route: replan` line names the planner (`/plan-feature <unit>` for a feature,
-  `/plan-fix <n>` for a fix). The planner re-cuts the plan on this branch, the
-  user confirms the appended SPEC phase(s), a fresh `/review-plan <unit>` passes,
-  and only then `execute-phase` runs them.
+  `route: replan` line prints the planner command (`/unit-lane <unit>` for a
+  feature, `/unit-lane --fix <n>` for a fix). The lane re-runs its plan step on
+  this branch, the user confirms the appended SPEC phase(s), its review step
+  gates, and only then `execute-phase` runs them.
 - **fix-now / `decision-required`** → stop and surface the decision to the user;
   the unit blocks until decided. No issue is created.
 - **proposal** (independent future capability) → batched in the report with a

package/skills/review-change/references/PERSIST_AND_DECIDE.md

@@ -126,13 +126,14 @@ exact command tokens.
      third cycle never starts without an explicit user instruction)
      · /audit-pr → only after the table is clean (not yet — findings open)
       · any finding routed replan-in-unit or owned by plan? → `node
-        scripts/unit-route.mjs <unit>` prints `route: replan` and names the
-        planner (`/plan-feature <unit>` for a feature, `/plan-fix <n>` for a fix);
-        the planner re-cuts the plan on this branch, a fresh `/review-plan <unit>`
-        passes, then `/execute-phase <unit>` (yes: list the finding ids; no: omit
+        scripts/unit-route.mjs <unit>` prints `route: replan` and the planner
+        command (`/unit-lane <unit>` for a feature, `/unit-lane --fix <n>` for a
+        fix); the lane re-runs its plan step on this branch, its review step
+        gates, then `/execute-phase <unit>` (yes: list the finding ids; no: omit
         this line)
-      · any finding owned by product? → /design-feature <unit>, then /review-spec
-        <unit> (yes: list the ids; no: omit this line)
+      · any finding owned by product? → /unit-lane <unit> — the lane's design
+        step repairs the half, its review step re-judges it (yes: list the ids;
+        no: omit this line)
       · independent proposals → present to the user; only the user routes them
         to /triage-issue
      · adversarial recommendation checklist fired AND this run was

package/skills/review-implementation/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-implementation
 user-invocable: false
-version: 1.9.0
+version: 1.10.0
 argument-hint: <path-or-glob>
 allowed-tools: Read, Grep, Glob, Bash, WebFetch
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"

package/skills/review-implementation/references/CLASSIFY.md

@@ -85,7 +85,7 @@ in-scope capability complete (D2: complete capabilities, not short unit
 duration). Current-unit work has **only blocking outcomes**:
 
 - **fix-now** — it can fold directly. It is NEVER a tracked issue and NEVER
-  routes to `plan-fix`: it folds into the current unit's open phase (AC 12).
+  routes to a standalone replan: it folds into the current unit's open phase (AC 12).
 - **replan-in-unit** — it needs additional user-confirmed phases (see *Large
   in-scope fix-now → replan, never downgrade* below).
 - **decision-required** — a new product/architecture decision is unavoidable.
@@ -109,11 +109,12 @@ the user routes a proposal to `triage-issue`.
 An in-scope fix-now too large to fold as-is (multi-file redesign, or evidence
 the unit should have been split) keeps its **fix-now** class — size is never a
 reason to downgrade. Set its `Route` to **`replan-in-unit`**: run
-`node scripts/unit-route.mjs <unit>` — its `route: replan` line names the planner
-(`/plan-feature <unit>` or `/plan-fix <n>`) — and the unit's SPEC `## Phases`
-ledger gets one or more new phases covering the work, on the SAME branch, a fresh
-`/review-plan <unit>` passing before `execute-phase` runs them. It never routes to
-`plan-fix` for a new unit or a new issue (AC 12). Placement
+`node scripts/unit-route.mjs <unit>` — its `route: replan` line prints the
+planner command (`/unit-lane <unit>` for a feature, `/unit-lane --fix <n>` for a
+fix) — and the unit's SPEC `## Phases`
+ledger gets one or more new phases covering the work, on the SAME branch, the
+lane's own `review` step passing before `execute-phase` runs them. It never routes to
+a standalone planner for a new unit or a new issue (AC 12). Placement
 depends on whether the final `Hardening & PR` phase has already run:
 
 - **Hardening not yet executed** → insert the new phase(s) BEFORE it; the
@@ -150,10 +151,11 @@ your domains):
 ## Routing (what each class feeds)
 
 - **fix-now** → fold directly into the current unit's open phase; never a
-  tracked issue, never `plan-fix` (AC 12).
+  tracked issue, never a standalone planner (AC 12).
 - **fix-now / `replan-in-unit`** → `node scripts/unit-route.mjs <unit>` prints
-  `route: replan`; the planner it names re-cuts the SPEC `## Phases` ledger
-  (user confirms), a fresh `/review-plan <unit>` passes, then `execute-phase`
+  `route: replan`; the planner command it prints re-cuts the SPEC `## Phases`
+  ledger
+  (user confirms), the lane's `review` step gates, then `execute-phase`
   runs the new phases — never a downgrade, never a tracked issue (AC 12).
 - **fix-now / `decision-required`** → stop and surface the decision; the unit
   blocks until the user decides. No issue is created.
@@ -172,8 +174,8 @@ finding in its `Route` cell.
 | Owning stage | Hand-off | Never |
 |---|---|---|
 | `source` | fold locally: `/fold-findings`, then re-run `/review-change` on the changed HEAD | — |
-| `plan` | run `node scripts/unit-route.mjs <unit>` → `route: replan`; the planning author re-cuts the artifact (SPEC `## Phases`, an obligation row, an acceptance mapping, a ledger) on the same branch with the user's confirmation, then a **fresh `/review-plan <unit>`** precedes `execute-phase` | fold it in code and leave the plan describing the old build |
-| `product` | `/design-feature <unit>` repairs the half, then `/review-spec <unit>` re-judges it | patch the product claim into agreement in code |
+| `plan` | run `node scripts/unit-route.mjs <unit>` → `route: replan`; the planning author re-cuts the artifact (SPEC `## Phases`, an obligation row, an acceptance mapping, a ledger) on the same branch with the user's confirmation, then the lane's **`review` step** precedes `execute-phase` | fold it in code and leave the plan describing the old build |
+| `product` | `/unit-lane <unit>` repairs the half through its `design` step, its `review` step re-judges it | patch the product claim into agreement in code |
 | `environment` / `runtime` | the existing retry/`BLOCKED` paths | translate into a PASS, or an issue |
 
 - `fix-now` with a `plan` or `product` owner keeps its severity but is **not**

package/skills/triage-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: triage-issue
 user-invocable: true
-version: 2.8.0
+version: 2.9.0
 argument-hint: <issue-number> [more issue numbers…] | <audit-id> F<k> [F<j>…] | --prioritize-now <unit> F<k> [F<j>…]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -106,20 +106,21 @@ classification, label ownership, and persisted-output contracts do not change.
 ## Relationship to other skills
 
 ```
-                 ┌─ fix-now ─────────▶ plan-fix ─▶ execute-phase --fix
+                 ┌─ fix-now ─────────▶ /unit-lane --fix <n> ─▶ the lane's implement step
                  ├─ fix-in-unit ─────▶ execute-phase <NN> P<k> (fold into phase)
 triage-issue ────┤                    or fold-findings (ledger row)
-                 │                    or unit-route → plan-feature / plan-fix (replan)
-                 ├─ promote ─────────▶ plan-feature (router → from-issue)
+                 │                    or unit-route <unit> → /unit-lane <unit> (replan)
+                 ├─ promote ─────────▶ /unit-lane --from-issue <n> (feature from issue)
                  ├─ postpone ────────▶ dated comment, leave open
                  └─ wontfix ─────────▶ propose close
 ```
 
 In review-finding mode, `replan-in-unit` runs `node scripts/unit-route.mjs
-<unit>`: its `route: replan` line names the planner (`/plan-feature` for a
-feature, `/plan-fix` for a fix), with new `P<n>` phases appended to the same
-unit and a fresh `/review-plan` before execution. The user manually runs those
-phases; this skill never implements them.
+<unit>`: its `route: replan` line prints the planner command — `/unit-lane
+<unit>` for a feature, `/unit-lane --fix <n>` for a fix — which re-runs the
+lane's `plan` catalog step and appends new `P<n>` phases to the same unit. The
+lane's own `review` step is the gate before execution. The user manually runs
+those phases; this skill never implements them.
 
 ## Done when
 
@@ -136,8 +137,8 @@ phases; this skill never implements them.
 
   Batch:
   → Next: apply every verdict: #<n1> → <command> + #<n2> → <command> + #<n3> → <command>
-    · fix-now → /plan-fix <n>   · promote → /plan-feature <n>
-    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never /plan-fix
+    · fix-now → /unit-lane --fix <n>   · promote → /unit-lane --from-issue <n>
+    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never a new planner skill
     · postpone → dated comment, leave open   · wontfix → propose close
     · same inconsistency across several issues → /product-audit (a recurring pattern,
       not isolated tickets — sweep the product rather than triaging one by one)

package/skills/triage-issue/references/ISSUE_PROCESS.md

@@ -25,12 +25,11 @@
        append a provenance-marked row to the unit's `review-findings.md` (see
        *Ledger-append mechanism* below).
      - *changes the unit's shape* → **incremental replan** on the same unit:
-       name the exact command — `design-feature <slug> "<instruction>"`
-       (product half, upsert) for a product-shape change, `plan-feature
-       <slug>` (re-run, engineering half) for an engineering-shape change, or
-       a user-approved, dated `## Amendments` entry per #66's mechanism (fix
-       units). Never write "replan if needed" — always name which of the
-       three applies and why.
+       name the exact command — `/unit-lane <slug>` (the lane re-reads the
+       SPEC, re-triages, and re-runs its `design`/`plan` catalog steps) — or a
+       user-approved, dated `## Amendments` entry per #66's mechanism (fix
+       units). Never write "replan if needed" — always name which applies and
+       why.
      - *born as an un-amended descope of an unmerged unit* →
        **scope-bleed restore**: the route is restore-the-criterion-in-the-unit
        (no matching `## Amendments` entry); the issue closes as
@@ -38,13 +37,15 @@
    - No candidate matched → fall through to today's four-verdict
      classification below, unchanged.
 4. **Classify** into one of:
-   - **fix-now** — defect or trigger met → route to `plan-fix` then
-     `execute-phase --fix`; add the entry to the fix index. **High severity** →
+   - **fix-now** — defect or trigger met → route to `/unit-lane --fix <n>`
+     (creates the fix unit and triages it; the lane's `implement` step runs
+     it); add the entry to the fix index. **High severity** →
      apply the urgency label per *Urgency label vocabulary* above (`urgent` by
      default; `fix-next` when the call is "queue it next" rather than "maybe
      interrupt now" — see that section's table). Non-high severity → no label.
-   - **promote-to-feature** — really new capability → route to `plan-feature`
-     (the router handles the issue path). Apply the `promoted` disposition
+   - **promote-to-feature** — really new capability → route to
+     `/unit-lane --from-issue <n>` (creates the feature unit from the issue and
+     triages it). Apply the `promoted` disposition
      label per *Disposition label vocabulary* above.
    - **postpone** — valid but trigger unmet → leave open; post a **dated
      re-confirmation** comment stating what you checked and why it stays

package/skills/triage-issue/references/LABELS.md

@@ -2,7 +2,7 @@
 
 This skill is the **sole owner and sole writer** of the workflow's urgency
 labels. No other skill defines, spells, or applies them — `workflow-status`
-only *reads* them (labels-only, presence-only) and `ship-roadmap` only
+only *reads* them (labels-only, presence-only) and `advance` only
 *consumes* what `workflow-status` reports.
 
 | Label | Color | Meaning |
@@ -38,8 +38,8 @@ verdict — never a separate, silent step:
    landing).
 
 A **fix-now + non-high** severity verdict routes normally (fix index +
-`plan-fix`) but applies **no** label — only high severity reaches the urgent
-tier.
+`/unit-lane --fix <n>`) but applies **no** label — only high severity reaches
+the urgent tier.
 
 ## Disposition label vocabulary (owned here)
 

package/skills/triage-issue/references/REVIEW_FINDING_PROCESS.md

@@ -15,11 +15,11 @@ after `/fold-findings` leaves rows unresolved.
      remains on the current unit. Route it to `/fold-findings` or an explicit
      `/execute-phase <unit> P<n>`.
    - A correction too large for the current fold is `replan-in-unit`. Run
-     `node scripts/unit-route.mjs <unit>`; its `route: replan` line names the
-     planner (`/plan-feature <unit>` for a feature, `/plan-fix <issue-number>`
-     for a fix) and the fresh `/review-plan <unit>` that must pass before
-     execution. The plan must append concrete `P<n>` phases to the unit's
-     SPEC and preserve the finding's acceptance evidence.
+     `node scripts/unit-route.mjs <unit>`; its `route: replan` line prints the
+     planner command — `/unit-lane <unit>` for a feature, `/unit-lane --fix <n>`
+     for a fix — which re-runs the lane's `plan` step and appends concrete
+     `P<n>` phases to the unit's SPEC, preserving the finding's acceptance
+     evidence. The lane's `review` step gates execution.
    - A product, architecture, or acceptance decision that blocks safe work is
      `decision-required`. Ask the user; do not guess or weaken the finish line.
    - A finding disproved by current evidence is `disputed`. Preserve the row
@@ -35,7 +35,7 @@ Return exactly one block per finding:
 REVIEW FINDING <F-k> — <short title>
 Checked: <commands and evidence>
 VERDICT: fix-now | replan-in-unit | decision-required | disputed
-Action taken: <current-unit fold/phase | plan-feature | plan-fix | user decision>
+Action taken: <current-unit fold/phase | unit-lane | user decision>
 ```
 
 Close with every finding ID mapped to its own command, joined with ` + `, and

package/skills/unit-lane/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: unit-lane
 user-invocable: true
-version: 1.0.0
-argument-hint: <NN-slug | "<idea>"> [--retriage]
+version: 1.1.0
+argument-hint: <NN-slug | "<idea>"> [--retriage] | --fix <issue-number> | --from-issue <issue-number>
 description: >
   One-shot lane conductor for a delivery unit: triage, implement, evidence, and
   close in a single document. Triggers: "unit-lane", "run the lane",
@@ -36,8 +36,14 @@ done:
 
 - A known unit slug: `unit-lane <NN-slug>`
 - A raw idea (no slug yet): `unit-lane "<idea description>"`
+- A tracked fix issue (no fix folder yet): `unit-lane --fix <issue-number>`
+- A tracked roadmap feature issue (no feature folder yet): `unit-lane --from-issue <issue-number>`
 - Force re-triage: `unit-lane <NN-slug> --retriage`
 
+Both `--fix <n>` and `--from-issue <n>` are the exact forms
+`scripts/unit-route.mjs` prints for a tracked issue with no unit folder
+(`route: plan-from-issue`) — never invent a different spelling.
+
 ## Step 0 — Discover the project
 
 Per the agent guide's **Workflow conventions** + **documentation map**, then read
@@ -48,11 +54,20 @@ exists, read its current `SPEC.md` to avoid overwriting.
 
 ### 1. Resolve or create the unit doc
 
-If the idea has no slug, assign the next number from `docs/features/ROADMAP.md`
-and create `docs/features/<NN>-<slug>/SPEC.md` from the template. Fill
-objective, why, user outcome, and non-goals from the invocation. Acceptance
-criteria are induced from user scenarios — **ask-don't-infer**; if the request
-is too vague, STOP and ask the user with concrete options. See
+If the unit folder already exists, read its `SPEC.md` and continue. Otherwise
+create it from the tree the unit belongs to:
+
+| Invocation | Folder | Template | Index to register |
+|---|---|---|---|
+| `<NN-slug>` / `"<idea>"` | `docs/features/<NN>-<slug>/` | `docs/features/_TEMPLATE/SPEC.md` | `docs/features/ROADMAP.md` |
+| `--fix <issue-number>` | `docs/fix/<issue-number>-<topic>/` | `docs/fix/_TEMPLATE/SPEC.md` | `docs/fix/README.md` |
+| `--from-issue <issue-number>` | `docs/features/<NN>-<slug>/` | `docs/features/_TEMPLATE/SPEC.md` | `docs/features/ROADMAP.md` (row links `#<issue-number>`) |
+
+For `--fix`/`--from-issue`, read the tracked issue in the forge first and keep
+its number; the folder name carries it (`fix/<issue-number>-<topic>`). Fill
+objective, why, user outcome, and non-goals from the invocation (or the issue).
+Acceptance criteria are induced from user scenarios — **ask-don't-infer**; if the
+request is too vague, STOP and ask the user with concrete options. See
 [the unit doc template](references/STEPS.md) for section order.
 
 ### 2. Triage — read the catalog, never re-derive
@@ -119,8 +134,8 @@ unit doc's status, and print the closing block.
 
 ## Relationship to other skills
 
-`unit-lane` absorbs the fixed-pipeline skills (design-feature, plan-feature,
-review-spec, review-plan) into catalog steps. The review pack axes
+`unit-lane` absorbed the retired fixed-pipeline skills (design-feature,
+plan-feature, review-spec, review-plan) into catalog steps. The review pack axes
 (`review-implementation`, `review-code`, `review-security`, `review-perf`,
 `review-a11y`, `review-debt`) compose the review step; `triage-issue` feeds
 issues into the lane; `workflow-status` computes the next lane invocation.

package/skills/workflow-status/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: workflow-status
 user-invocable: true
-version: 3.8.1
+version: 3.9.1
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
-argument-hint: "[--json-only] [--last-envelope <json|path>]"
+argument-hint: "[--json-only] [--last-envelope <json|path>] [--compact]"
 description: >
   Read-only workflow sensor: run the deterministic script, read the fixed
   machine envelope, interpret the recommendation. Never edits. Triggers:
@@ -25,20 +25,19 @@ report — it never assembles the envelope by hand.
 
 ```
 ✓ The script was RUN — `bun scripts/workflow-status.mjs [--json-only]
-  [--last-envelope <json|path>]` (node is the fallback when bun is absent, per
-  the repository's runtime convention); the envelope is the script's stdout, never
-  assembled by the model
+  [--last-envelope <json|path>] [--compact]` (node is the fallback when bun is
+  absent, per the repository's runtime convention); the envelope is the script's
+  stdout, never assembled by the model
 ✓ Nothing was edited, committed, pushed, or created — read-only, always
 ✓ `next.recommended` is non-bare (carries the unit's slug/NN, never a bare
-  `/plan-feature`) AND the script computed it from the unit's resolved status
-  **and** its current pre-execution evidence: `idea`/undesigned →
-  `/design-feature <slug>`; `defined` → `/plan-feature <slug>` only on a current
-  `SPEC-REVIEW-PASS`, else `/review-spec <slug>`; `planned`/`in-progress` → `/execute-phase <NN>` only on a
-  current `PLAN-REVIEW-PASS`, else `/review-plan <NN>` (step 6a)
+  `/unit-lane`) AND the script computed it from the unit's resolved status:
+  `idea`/`defined` → `/unit-lane <slug>` (or `/unit-lane --fix <n>` for a fix);
+  `planned`/`in-progress` → `/execute-phase <NN>` (its triage block is the
+  authority; no separate plan-receipt currency check, step 6a)
 ✓ `detail.crash_recovery` carries a verdict from the decision table and the
   envelope `state` matches it (CLEAN→OK, RESUMABLE→CONTINUE,
   AMBIGUOUS→NEEDS_INPUT)
-✓ Every `detail.design_candidates[].next` begins with `/design-feature `
+✓ Every `detail.design_candidates[].next` begins with `/unit-lane `
 ✓ Every degraded dimension is named in `detail.degradations` as
   `unavailable-<source>-<cause>` — and, when `--last-envelope` was supplied, the
   no-progress guard's `workflow_observations` note is present (never a silently
@@ -51,6 +50,12 @@ report — it never assembles the envelope by hand.
 
 With `--json-only`, skip the human-readable summary: print the envelope alone.
 
+## Compact mode — `--compact`
+
+`--compact` emits the same envelope with repository history dropped (~half the
+bytes on a mature repo); the exact keep/drop set is in
+[envelope fields](references/ENVELOPE_FIELDS.md).
+
 ## When to use
 
 - Between orchestration steps: an external driver runs it to decide the next
@@ -93,11 +98,11 @@ the JSON contract.
 
 ## Relationship to other skills
 
-- The **sensor** counterpart to `ship-roadmap`'s conductor: an external
-  orchestrator calls `workflow-status` → routes on the envelope → invokes
-  `plan-feature` / `execute-phase` / `review-change` / `audit-pr` /
-  `triage-issue` directly, choosing the model per step — the same loop without
-  the in-agent autopilot.
+- The **sensor** counterpart to `advance`'s conductor: an external
+  orchestrator (or `advance` itself) calls `workflow-status` → routes on the
+  envelope → invokes `unit-lane` / `execute-phase` / `review-change` /
+  `audit-pr` / `triage-issue` directly, choosing the model per step — the same
+  loop without the in-agent autopilot.
 - Read-only sibling of `audit-docs` (which judges coherence and can fix) and
   `product-audit` (which judges health): this one only reports state.
 - Schema owner: `orchestration-envelope` (internal).
@@ -112,7 +117,7 @@ the JSON contract.
   `detail.crash_recovery` were read from the envelope, and the envelope `state`
   matches the crash-recovery verdict.
 - With `--last-envelope` supplied: the no-progress guard ran — a stalled
-  `/plan-feature`/`/design-feature` hint surfaces as a `workflow_observations`
+  `/unit-lane` hint surfaces as a `workflow_observations`
   note, never a silent bland repeat, with no new write path introduced.
 - The human summary (unless `--json-only`) and the envelope are printed, envelope
   last.

package/skills/workflow-status/references/CRASH_RECOVERY.md

@@ -23,12 +23,12 @@ section *classifies*; the resume command it recommends does the acting.
   caller's persisted envelope against the recomputed state and report the
   divergence in one line. The hint never overrides recomputed state.
 - ✓ **No-progress guard (optional, requires `--last-envelope`).** When the
-  hint's `next.recommended` was `/plan-feature <slug>` or `/design-feature
-  <slug>` for a given unit, and this run's own recomputed status for that
-  **same unit** is still at the **same pre-advance status** the hint expected
-  to move it off of (`defined` for a `/plan-feature` hint; `idea` for a
-  `/design-feature` hint) — either the recommended command ran but its status
-  write was dropped, or it never ran at all; this guard cannot distinguish the
+  hint's `next.recommended` was `/unit-lane <slug>` for a given unit, and this
+  run's own recomputed status for that **same unit** is still at the **same
+  pre-advance status** the hint expected to move it off of (`idea`/`defined` —
+  the lane's triage write lands when the unit doc is created) — either the
+  recommended command ran but its status write was dropped, or it never ran at
+  all; this guard cannot distinguish the
   two from the envelope alone, so the note names it as a **suspected** stall,
   not a confirmed dropped write. Emit a `workflow_observations` note (see
   `## Machine envelope` for the exact note shape). This is strictly additive:

package/skills/workflow-status/references/ENVELOPE_CORE.md

@@ -108,15 +108,12 @@ the key's presence.
 |---|---|
 | `/discover-repository-state` | `strong` |
 | `/resolve-repository-state` | `strong` |
-| `/plan-feature` | `strong` |
-| `/design-feature` | `strong` |
+| `/unit-lane` | `strong` |
 | `/review-change` | `strong` |
 | `/audit-pr` | `strong` |
 | `/triage-issue` | `strong` |
 | `/product-audit` | `strong` |
 | `/execute-phase` | `cheap` |
-| `/review-spec` | `strong` |
-| `/review-plan` | `strong` |
 
 `next.tier` is read off this map by matching the resolved `next.recommended`
 command's name (ignoring its arguments) — never guessed and never copied from

package/skills/workflow-status/references/ENVELOPE_FIELDS.md

@@ -2,12 +2,12 @@
 
 **No-progress guard note (`workflow_observations`, requires `--last-envelope`,
 see the crash-recovery checklist above)** — when the hint's `next.recommended`
-targeted `/plan-feature <slug>` or `/design-feature <slug>` and this run still
+targeted `/unit-lane <slug>` and this run still
 classifies that same unit at the same pre-advance status, append a note of the
 exact shape:
-`"<slug> still 'defined' after the hint's /plan-feature <slug> recommendation — suspected dropped defined→planned write (see #51)"`
-(swap `defined`/`/plan-feature` for `idea`/`/design-feature` on the design
-side). The recommendation itself is unaffected — this only adds visibility.
+`"<slug> still 'defined' after the hint's /unit-lane <slug> recommendation — triage not yet applied"`
+(the note fires for a `defined` unit; the lane's triage write is what moves it
+off `idea`/`defined`). The recommendation itself is unaffected — this only adds visibility.
 
 **Shape vs. current output — read this before trusting the example below.** The
 example is the envelope's **intended shape**, not everything the deterministic
@@ -33,10 +33,10 @@ absent-legacy` or `issues_born.n: 0`; the owning note is
   "dependencies": {"unmet": [], "build_order": []},
   "recommendations": {"product_audit": false, "reason": null},
   "needs_input": null,
-  "next": {"recommended": "/review-change", "alternatives": ["/plan-feature 05"], "tier": "strong",
+  "next": {"recommended": "/review-change", "alternatives": ["/unit-lane 05"], "tier": "strong",
            "suggested": [{"command": "/review-change", "trigger": "accumulation: 420 changed lines since last-reviewed sha", "source_skill": "execute-phase"}]},
   "detail": {
-    "design_candidates": [{"id": "08-billing-webhooks", "status": "idea", "next": "/design-feature 08-billing-webhooks"}],
+    "design_candidates": [{"id": "08-billing-webhooks", "status": "idea", "next": "/unit-lane 08-billing-webhooks"}],
     "pre_execution": [{"unit": "12-export-api", "unitDir": "docs/features/12-export-api", "stage": "lane", "label": "current", "verdict": "READY", "boundDigest": null, "observedDigest": null, "recommended": "/unit-lane 12-export-api", "reason": "unit-doc currency is checked per step by unit-lane/execute-phase"}],
     "features": [
       {"id": "07-csv-export", "status": "in-progress", "deps": ["01"], "deps_unmet": [],
@@ -87,4 +87,39 @@ fully in `features`/`fixes` — an `idea` unit appears ONLY in
 `design_candidates` (and `detail.features`), never in `startable_now`, since
 it has no deps-met check to pass (design precedes dependency startability).
 `05-auth` above illustrates `defined` (not yet `planned`): startable, next
-`/plan-feature`, phase fields null (no planning artifacts yet).
+`/unit-lane`, phase fields null (no planning artifacts yet).
+
+## The `--compact` projection
+
+The envelope above is the complete one. `--compact` emits the **same shape and the
+same decisions** with repository history dropped, because a poll loop pays for
+that history in context on every read while no consumer of "what can I do now"
+reads it. On this repository it is roughly half the bytes.
+
+Exactly two fields change:
+
+- `detail.features` / `detail.fixes`: a `done` row is dropped **only on positive
+  proof its linked PR merged** (the merge resolver). An unmerged `done` row is
+  still at the merge gate and stays; every row in `idea`/`defined`/`planned`/
+  `in-progress` stays in both modes, so `detail.startable_now` and
+  `detail.blocked_units` keep naming every unit either way.
+- `findings.fix_now[].route`: the reviewer's multi-paragraph evidence memo becomes
+  `...(N char evidence, see the unit review-findings.md)`, keeping the original
+  length visible. `id`, `file`, `axis`, `severity`, `class` and `suggested_tier`
+  are untouched, and the memo is on disk in the unit's `review-findings.md`, which
+  is where the fold reads it.
+
+`detail.workflow_observations` is **not** reduced in either mode. Every note the
+sensor writes is a signal — an unmapped roadmap status, a slug that refused its
+files, a ledger severity outside the published enum, git and forge state, the
+`--last-envelope` guard's divergence note — and they total about a kilobyte, so
+trimming them would trade a real signal for no measurable win. The size comes from
+`features` and the route memos, which are an order of magnitude larger and pure
+history.
+
+Everything else is byte-identical: `state`, `summary`, `unit`, `phase`, `pr`,
+`gates`, `blockers`, `dependencies`, `recommendations`, `needs_input`, all of
+`next` (`recommended`, `alternatives`, `tier`, `reason`, `candidate_count`,
+`suggested`, `continuation`), `detail.repository_state`, `design_candidates`,
+`pre_execution`, `review_loop_cycles`, `crash_recovery` and `urgent`. A consumer
+may therefore switch modes per read without changing how it parses.

package/skills/workflow-status/references/PRE_EXECUTION.md

@@ -1,5 +1,10 @@
 ## Pre-execution receipt sensing (step 6a)
 
+> **Legacy (feature 61 P8b):** the spec/plan pre-execution receipt stages are
+> retired — the sensor now senses the unit doc's single triage block
+> (`stage: lane`, see `ENVELOPE_FIELDS.md`). This reference is retained for
+> units that still carry those receipts; the live sensing is the `lane` stage.
+
 Roadmap status says what exists; only a receipt bound to the current bytes says
 whether the unit may be executed. Sense it like every other signal — read the file,
 recompute the digest, never trust the prose sitting around the block.

package/skills/workflow-status/references/SENSOR_SIGNALS.md

@@ -145,5 +145,5 @@ mechanized.*
     `CRASH RECOVERY` sub-block to the report.
 18. **Report.** Print a short human summary (table: unit | status | deps unmet |
     PR | next gate) plus a **design candidates** line (`idea` units and their
-    `/design-feature` next command) plus the `CRASH RECOVERY` sub-block, then
+    `/unit-lane` next command) plus the `CRASH RECOVERY` sub-block, then
     the envelope. With `--json-only`, envelope only.