incitaciones 0.11.0 → 0.12.0

package/README.md

@@ -1,5 +1,10 @@
 # Incitaciones 🤖
 
+> **Why:** agent prompts rot — they accumulate metadata sections, stale claims,
+> and untraceable provenance. incitaciones keeps every prompt twice: a full
+> source (frontmatter, tags, status, provenance) and a structurally validated
+> distilled runtime file, gated end-to-end by `just ci`.
+> **Status:** [experimental](docs/src/status.md) · corpus + export tooling evolving · [Motivation & design](docs/src/index.md) · [charly-vibes Tool Ecosystem](https://charly-vibes.github.io/dulce-de-leche/ecosystem-map.html)
 [![npm](https://img.shields.io/npm/v/incitaciones)](https://www.npmjs.com/package/incitaciones)
 [![Publish to npm](https://github.com/charly-vibes/incitaciones/actions/workflows/npm-publish.yml/badge.svg)](https://github.com/charly-vibes/incitaciones/actions/workflows/npm-publish.yml)
 

package/content/distilled/issues/references/create-issues/SKILL.md

@@ -1,4 +1,4 @@
-<!-- skill: create-issues, version: 1.4.1, status: verified -->
+<!-- skill: create-issues, version: 1.5.0, status: verified -->
 # Tracer-Bullet Issue Creation from Plan
 
 Break a reviewed plan into independently grabbable issues using tracer-bullet vertical slices.
@@ -22,9 +22,19 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Prefer **vertical slices** over phase-by-phase horizontal tickets.
    - Each issue should cut through all necessary layers for one narrow capability: storage/schema, business logic, interface, tests, and observability/docs when relevant.
    - A slice must be independently verifiable or demoable.
-   - Mark each slice as:
-     - **AFK** — can be implemented and merged without human intervention.
-     - **HITL** — requires a human decision, approval, design review, copy review, policy signoff, etc.
+   - Mark each slice with a **lane** (execution mode) and a **complexity** grade:
+     - **Lane:**
+       - **AFK** — bounded, mechanically verifiable, mergeable without human intervention; the `afk` label means "safe to run autonomously", so it may only be applied when an objective gate exists (test suite, CI, or Meter command). Label: `afk`.
+       - **DESIGN** — needs an interactive design session before implementation: semantics decisions, API shape, concurrency models, trade-offs. A human works this with a strong-reasoning model, never autonomously. Label: `design`.
+       - **HITL** — pure human decision, approval, copy review, or policy signoff with little or no model work. Label: `hitl`.
+       - **REVIEW** — second-opinion pass over existing output (code review, spec audit, conformance check). Label: `review`.
+     - **Complexity (effort / model tier)** — graded by falsifiable criteria so a reviewer can gate a wrong tag:
+       - **S** — matches an existing pattern in the repo (same change shape already exists in code or a prior ticket); ≤3 files; no new public interface, dependency, or invariant; the Meter is an existing test command. Label: `complexity:s`.
+       - **M** — multi-file change within established patterns; new tests follow existing conventions; no new public API beyond the slice's own; no concurrency or protocol semantics. Label: `complexity:m`.
+       - **L** — introduces or changes an invariant, concurrency semantics, protocol conformance, or a public API; correctness requires reasoning the repo's existing tests do not already encode. Label: `complexity:l`.
+       - **XL** — unresolved semantics or cross-repo scope: two competent agents would disagree on what "done" means; do not schedule — decompose into S/M/L slices first. Label: `complexity:xl`.
+       - **Grade gate:** an S/M ticket that touches a public API, an invariant, or concurrency code is mis-tagged — retag L before publishing; an L ticket fully covered by an existing pattern plus an existing test command is mis-tagged — retag M or S.
+     - Classification signals: `decision`-type tickets or titles starting with Decide/Choose/Approve/Scope → DESIGN or HITL, never AFK; bounded bugs with a failing test or concrete repro in a repo with CI → AFK; verification/conformance sweeps → AFK; concurrency/security/semantics work → DESIGN unless a failing repro test exists; epics → XL. If the target repo has no CI or test suite, tag `no-gate` — never schedule AFK work without a gate.
    - Avoid tickets like “build backend”, “add UI”, or “refactor models first” unless the work is genuinely standalone.
    - **Title lint (hard rule — run on every drafted title before presenting):** a title must name a user-visible outcome (“CSV export works end-to-end”), not a layer. If a title names a layer or artifact — backend, frontend, API, route, button, serializer, schema, tests-only, docs-only, refactor-only — merge it into the outcome slice it serves. Layers differing is never sufficient reason to split: split by capability, never by layer.
 
@@ -33,11 +43,13 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Present a numbered list before creating anything.
    - For each slice include:
      - **Title**
-     - **Type:** AFK or HITL
+     - **Lane:** AFK | DESIGN | HITL | REVIEW
+     - **Complexity:** S | M | L | XL
+     - **Gate:** Meter command or CI suite (required for AFK; `no-gate` otherwise)
      - **Blocked by:** slice numbers or “None”
      - **User stories covered**
      - **Why this is a tracer bullet:** brief end-to-end justification
-   - Ask whether the granularity, dependency graph, and AFK/HITL split look right.
+   - Ask whether the granularity, dependency graph, and lane/complexity split look right.
    - Iterate until approved.
 
 5. **Prepare issue bodies:**
@@ -90,6 +102,9 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
 - **Name the cheats:** add anti-goals wherever the gate could be gamed (test edits, new deps, API breaks).
 - **Anchor staleness:** always record `base_commit` metadata at creation; never publish a ticket anchored to nothing.
 - **Stop and ask:** if the plan only supports horizontal decomposition, propose a vertical rewrite before publishing.
+- **Lane and complexity are mandatory metadata:** every published slice carries both (`bd update <id> --label design --label complexity:m`). Route by them, not by preference: S/M AFK work defaults to the cheapest capable model tier; DESIGN and L work gets the strongest reasoning tier with elevated effort.
+- **No gate, no AFK label:** in a repo without CI/tests, tag `no-gate` *instead of* `afk` — the ticket is not scheduled autonomously until a gate exists; when one does, replace `no-gate` with `afk`.
+- **Escalation is a retag:** after two failed implementation attempts, raise complexity one grade (S→M→L); if the failure cause is semantic (unclear spec or design rather than implementation), switch the lane to `design`. Record the failure cause in the ticket either way.
 
 ## References
 - **Templates:** `references/templates.md`

package/content/distilled/issues/references/create-issues/references/criteria.md

@@ -18,7 +18,8 @@ Use these criteria to evaluate whether a plan has been translated into strong tr
 | **Baseline anchored** | Measurable claims record the pre-work value and the HEAD SHA as `base_commit` metadata for staleness detection. |
 | **Dependency hygiene** | Only real blockers are encoded; parallel work is not serialized without reason. |
 | **Workflow Mandate** | Includes the mandatory TDD and Tidy First block. |
-| **Execution mode** | Slice is explicitly marked AFK or HITL. |
+| **Execution mode** | Slice is explicitly marked with a lane (AFK/DESIGN/HITL/REVIEW) and a complexity grade (S/M/L/XL); AFK slices carry an objective gate or `no-gate` tag. |
+| **Complexity honesty** | Complexity matches the work, not the optimism: XL is used when semantics or scope are unresolved, not as a badge. |
 
 ## Tracer-Bullet Heuristics
 

package/content/distilled/issues/references/create-issues/references/templates.md

@@ -6,7 +6,9 @@ Use these templates for proposed slice breakdowns, issue descriptions, and the f
 
 ```markdown
 1. **[Title]**
-   - **Type:** [AFK|HITL]
+   - **Lane:** [AFK|DESIGN|HITL|REVIEW]
+   - **Complexity:** [S|M|L|XL]
+   - **Gate:** [Meter command / CI suite — required for AFK]
    - **Blocked by:** [None | Slice 1, Slice 2]
    - **User stories covered:** [Story A, Story B]
    - **Tracer-bullet rationale:** [Why this is a thin end-to-end slice]
@@ -71,8 +73,8 @@ Or: `None - can start immediately`
 **Plan:** [path/to/plan.md]
 
 ### Approved Slice Set
-1. **[Title]** — [AFK|HITL], blocked by [None|IDs]
-2. **[Title]** — [AFK|HITL], blocked by [None|IDs]
+1. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
+2. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
 
 ### Summary
 - **Total Issues Created:** [count]

package/content/distilled/issues/references/issue-review/SKILL.md

@@ -26,7 +26,7 @@ Treat the best issue sets as:
 - thin vertical slices rather than layer tickets
 - independently verifiable or demoable
 - minimal but sufficient dependency graphs
-- explicit about AFK vs HITL work
+- explicit about lane (AFK/DESIGN/HITL/REVIEW) and complexity (S/M/L/XL) work
 - traceable back to stories, plans, or specs
 - self-describing: tickets that create or reshape source files carry the file-header criterion (see `file-headers`) — undocumented files force agents to re-derive intent
 - machine-verifiable value claims: quantified Must gate, runnable Meter, explicit anti-goals, and a `base_commit` anchor that reveals staleness

package/content/distilled/issues/references/issue-review/references/pass-5-executability.md

@@ -6,6 +6,9 @@ Focus on:
 - Is there a machine-checkable Must gate (quantified, unit + number) backed by a runnable Meter command?
 - Are touched code files self-describing — Purpose/Responsibilities/Rationale header present and current (see `file-headers`)?
 - Are priorities and labels sensible?
+- Does every ticket carry lane and complexity metadata (`afk`/`design`/`hitl`/`review` + `complexity:s/m/l/xl`)?
+- Are lane/complexity tags consistent with the work (DESIGN or HITL work never tagged `afk`)?
+- Are AFK tickets backed by an objective gate (CI/test suite/Meter), or tagged `no-gate` and kept out of autonomous scheduling?
 - Are HITL handoff points explicit?
 - Is it clear what demo, test, or observable behavior proves completion?
 
@@ -19,6 +22,10 @@ Watch for:
 - Tickets that create or reshape source files with no file-header acceptance criterion — undocumented files force every implementing agent to re-derive intent
 - No regression suite named (pass-to-pass coverage unspecified)
 - HITL work masquerading as AFK
+- DESIGN work (semantics decisions, API shape, concurrency models) tagged or scheduled as AFK — semantics need an interactive session, not an overnight run
+- Tickets tagged `complexity:xl` (epic-sized or semantics-heavy) presented as schedulable work instead of decomposition candidates
+- AFK tickets with no objective gate and no `no-gate` tag
+- Complexity grades that fail the falsifiable criteria — an S/M ticket touching a public API, an invariant, or concurrency code is mis-tagged and must be retagged L before scheduling
 - Tickets that cannot be closed without information from another issue not listed as a blocker
 
 Prefix findings with `EXEC-`.

package/content/distilled/whisper/SKILL.md

@@ -1,37 +1,20 @@
-# Whisper — Deterministic Operational Knowledge
+# Whisper — knowledge workspace (pointer)
 
-> **This skill is a thin pointer.** The canonical, versioned copy ships with
-> the `turu` CLI ([charly-vibes/whisper](https://github.com/charly-vibes/whisper),
-> `cargo install whisper-vibes`) — install it with `turu skill install`.
-> This file stays so agents without the binary have fallbacks.
+The canonical, versioned procedure lives in the **turu skill pack** —
+installed with `turu skill install` and shipped with the `turu` CLI
+([charly-vibes/whisper](https://github.com/charly-vibes/whisper),
+`cargo install whisper-vibes`).
 
-The `turu` CLI owns every mechanical step: canonical repo keys, branch slugs,
-worktree slots, and scope routing. Same inputs, same outputs — no more
-hand-rolled shell pipelines.
+## Routing rule
 
-## Decision procedure
-
-1. **Is `turu` available?** Run `turu key --json`.
-2. **If yes** — everything mechanical is a turu command:
-
-| Intent | Command |
-|---|---|
-| Derive repo key / branch slug / worktree slot | `turu key --json` |
-| Find the write destination for a scope | `turu resolve <scope> --json` |
-| Record knowledge (extend, don't duplicate) | `turu append <scope> --text "..."` |
-| Create the workspace layout | `turu init --json` |
-| Inspect paths and existence | `turu status --json` |
-| Validate / detect legacy keys | `turu check --json` · `turu doctor --json` |
-| Refresh the AGENTS.md routing block | `turu sync --json` |
-
-   Scopes: `global` (rules.md), `repo` (env.md), `branch` (notes.md),
-   `worktree` (env.md), `group` (shared workspace for a set of repos).
-   If a `<!-- TURU:START -->` block exists in `AGENTS.md`, read the routing
-   map from there instead of re-deriving paths.
-
-3. **If no** — use the manual fallbacks in `references/` (they remain the
-   source of truth for the shell-snippet procedures) and suggest
-   `cargo install whisper-vibes`.
+- **If `whisper.md` sits next to this file** (the installed pack), read it and follow it as your single source of procedure. It owns everything: the session loop (`turu recall all`
+at start, `turu append <scope> "..."` at capture), scope routing
+  (global → group → repo → branch → worktree), the command table, and all
+  modes. This pointer defers entirely and adds nothing — never reconcile
+  the two by hand.
+- **If the pack is absent**, `turu` is not installed: use the manual
+  fallbacks in `references/` (source of truth for the shell-snippet
+  procedures) and suggest `cargo install whisper-vibes`.
 
 ## Invariants (with or without the binary)
 
@@ -41,15 +24,4 @@ hand-rolled shell pipelines.
   than creating a new one that says the same thing.
 - **One repo, one key.** The canonical key is a pure function of the remote
   URL; never invent a variant.
-- **Search first.** Before creating a new entry, check if one exists.
-
-## Modes
-
-`/w init` → `turu init` · `/w` or `/w status` → `turu status` ·
-`/w check` → `turu check` · `/w link` → `subs/link-manual` (no CLI verb yet)
-· `/w decommission` → `subs/decommission-manual` · `/w consolidate` →
-`subs/consolidate-manual` (detection ships via `turu doctor`).
-
-Manual procedures for each mode: `references/init.md`, `references/check.md`,
-`references/status.md`, `references/link.md`, `references/decommission.md`,
-`references/consolidate.md`.
+- **Search first.** Before creating a new entry, check if one exists.

package/content/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "2026-09-30",
+  "version": "2026-10-06",
   "schema_version": "1.1",
   "prompts": [
     {
@@ -1465,7 +1465,7 @@
       "name": "whisper",
       "type": "workflow",
       "title": "Whisper — Accumulated Operational Knowledge",
-      "description": "Knowledge workspace management: init, check, status, link plan, decommission, routing. Delegates to the turu CLI when installed.",
+      "description": "Deterministic knowledge workspace: session loop (recall all / append), scope routing, distill, bundle. Delegates to the turu CLI when installed; manual fallbacks otherwise.",
       "source": "content/prompt-workflow-whisper.md",
       "distilled": "content/distilled/whisper/SKILL.md",
       "skill_format": "progressive-disclosure",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "incitaciones",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "description": "Reusable prompts and skills for CLI LLM tools, with native pi package support.",
   "repository": {
     "type": "git",

package/pi-package/prompts/whisper.md

@@ -1,5 +1,5 @@
 ---
-description: "Shortcut for the whisper skill. Knowledge workspace management: init, check, status, link plan, decommission, routing. Delegates to the turu CLI when installed."
+description: "Shortcut for the whisper skill. Deterministic knowledge workspace: session loop (recall all / append), scope routing, distill, bundle. Delegates to the turu CLI when installed; manual fallbacks otherwise."
 ---
 <!-- installed-from: incitaciones -->
 

package/pi-package/skills/create-issues/SKILL.md

@@ -12,7 +12,7 @@ disable-model-invocation: true
 
 #### Core Instructions (content/distilled/issues/references/create-issues/SKILL.md)
 
-<!-- skill: create-issues, version: 1.4.1, status: verified -->
+<!-- skill: create-issues, version: 1.5.0, status: verified -->
 # Tracer-Bullet Issue Creation from Plan
 
 Break a reviewed plan into independently grabbable issues using tracer-bullet vertical slices.
@@ -36,9 +36,19 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Prefer **vertical slices** over phase-by-phase horizontal tickets.
    - Each issue should cut through all necessary layers for one narrow capability: storage/schema, business logic, interface, tests, and observability/docs when relevant.
    - A slice must be independently verifiable or demoable.
-   - Mark each slice as:
-     - **AFK** — can be implemented and merged without human intervention.
-     - **HITL** — requires a human decision, approval, design review, copy review, policy signoff, etc.
+   - Mark each slice with a **lane** (execution mode) and a **complexity** grade:
+     - **Lane:**
+       - **AFK** — bounded, mechanically verifiable, mergeable without human intervention; the `afk` label means "safe to run autonomously", so it may only be applied when an objective gate exists (test suite, CI, or Meter command). Label: `afk`.
+       - **DESIGN** — needs an interactive design session before implementation: semantics decisions, API shape, concurrency models, trade-offs. A human works this with a strong-reasoning model, never autonomously. Label: `design`.
+       - **HITL** — pure human decision, approval, copy review, or policy signoff with little or no model work. Label: `hitl`.
+       - **REVIEW** — second-opinion pass over existing output (code review, spec audit, conformance check). Label: `review`.
+     - **Complexity (effort / model tier)** — graded by falsifiable criteria so a reviewer can gate a wrong tag:
+       - **S** — matches an existing pattern in the repo (same change shape already exists in code or a prior ticket); ≤3 files; no new public interface, dependency, or invariant; the Meter is an existing test command. Label: `complexity:s`.
+       - **M** — multi-file change within established patterns; new tests follow existing conventions; no new public API beyond the slice's own; no concurrency or protocol semantics. Label: `complexity:m`.
+       - **L** — introduces or changes an invariant, concurrency semantics, protocol conformance, or a public API; correctness requires reasoning the repo's existing tests do not already encode. Label: `complexity:l`.
+       - **XL** — unresolved semantics or cross-repo scope: two competent agents would disagree on what "done" means; do not schedule — decompose into S/M/L slices first. Label: `complexity:xl`.
+       - **Grade gate:** an S/M ticket that touches a public API, an invariant, or concurrency code is mis-tagged — retag L before publishing; an L ticket fully covered by an existing pattern plus an existing test command is mis-tagged — retag M or S.
+     - Classification signals: `decision`-type tickets or titles starting with Decide/Choose/Approve/Scope → DESIGN or HITL, never AFK; bounded bugs with a failing test or concrete repro in a repo with CI → AFK; verification/conformance sweeps → AFK; concurrency/security/semantics work → DESIGN unless a failing repro test exists; epics → XL. If the target repo has no CI or test suite, tag `no-gate` — never schedule AFK work without a gate.
    - Avoid tickets like “build backend”, “add UI”, or “refactor models first” unless the work is genuinely standalone.
    - **Title lint (hard rule — run on every drafted title before presenting):** a title must name a user-visible outcome (“CSV export works end-to-end”), not a layer. If a title names a layer or artifact — backend, frontend, API, route, button, serializer, schema, tests-only, docs-only, refactor-only — merge it into the outcome slice it serves. Layers differing is never sufficient reason to split: split by capability, never by layer.
 
@@ -47,11 +57,13 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Present a numbered list before creating anything.
    - For each slice include:
      - **Title**
-     - **Type:** AFK or HITL
+     - **Lane:** AFK | DESIGN | HITL | REVIEW
+     - **Complexity:** S | M | L | XL
+     - **Gate:** Meter command or CI suite (required for AFK; `no-gate` otherwise)
      - **Blocked by:** slice numbers or “None”
      - **User stories covered**
      - **Why this is a tracer bullet:** brief end-to-end justification
-   - Ask whether the granularity, dependency graph, and AFK/HITL split look right.
+   - Ask whether the granularity, dependency graph, and lane/complexity split look right.
    - Iterate until approved.
 
 5. **Prepare issue bodies:**
@@ -104,6 +116,9 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
 - **Name the cheats:** add anti-goals wherever the gate could be gamed (test edits, new deps, API breaks).
 - **Anchor staleness:** always record `base_commit` metadata at creation; never publish a ticket anchored to nothing.
 - **Stop and ask:** if the plan only supports horizontal decomposition, propose a vertical rewrite before publishing.
+- **Lane and complexity are mandatory metadata:** every published slice carries both (`bd update <id> --label design --label complexity:m`). Route by them, not by preference: S/M AFK work defaults to the cheapest capable model tier; DESIGN and L work gets the strongest reasoning tier with elevated effort.
+- **No gate, no AFK label:** in a repo without CI/tests, tag `no-gate` *instead of* `afk` — the ticket is not scheduled autonomously until a gate exists; when one does, replace `no-gate` with `afk`.
+- **Escalation is a retag:** after two failed implementation attempts, raise complexity one grade (S→M→L); if the failure cause is semantic (unclear spec or design rather than implementation), switch the lane to `design`. Record the failure cause in the ticket either way.
 
 ## References
 - **Templates:** `references/templates.md`
@@ -133,7 +148,8 @@ Use these criteria to evaluate whether a plan has been translated into strong tr
 | **Baseline anchored** | Measurable claims record the pre-work value and the HEAD SHA as `base_commit` metadata for staleness detection. |
 | **Dependency hygiene** | Only real blockers are encoded; parallel work is not serialized without reason. |
 | **Workflow Mandate** | Includes the mandatory TDD and Tidy First block. |
-| **Execution mode** | Slice is explicitly marked AFK or HITL. |
+| **Execution mode** | Slice is explicitly marked with a lane (AFK/DESIGN/HITL/REVIEW) and a complexity grade (S/M/L/XL); AFK slices carry an objective gate or `no-gate` tag. |
+| **Complexity honesty** | Complexity matches the work, not the optimism: XL is used when semantics or scope are unresolved, not as a badge. |
 
 ## Tracer-Bullet Heuristics
 
@@ -175,7 +191,9 @@ Use these templates for proposed slice breakdowns, issue descriptions, and the f
 
 ```markdown
 1. **[Title]**
-   - **Type:** [AFK|HITL]
+   - **Lane:** [AFK|DESIGN|HITL|REVIEW]
+   - **Complexity:** [S|M|L|XL]
+   - **Gate:** [Meter command / CI suite — required for AFK]
    - **Blocked by:** [None | Slice 1, Slice 2]
    - **User stories covered:** [Story A, Story B]
    - **Tracer-bullet rationale:** [Why this is a thin end-to-end slice]
@@ -240,8 +258,8 @@ Or: `None - can start immediately`
 **Plan:** [path/to/plan.md]
 
 ### Approved Slice Set
-1. **[Title]** — [AFK|HITL], blocked by [None|IDs]
-2. **[Title]** — [AFK|HITL], blocked by [None|IDs]
+1. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
+2. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
 
 ### Summary
 - **Total Issues Created:** [count]

package/pi-package/skills/issue-review/SKILL.md

@@ -40,7 +40,7 @@ Treat the best issue sets as:
 - thin vertical slices rather than layer tickets
 - independently verifiable or demoable
 - minimal but sufficient dependency graphs
-- explicit about AFK vs HITL work
+- explicit about lane (AFK/DESIGN/HITL/REVIEW) and complexity (S/M/L/XL) work
 - traceable back to stories, plans, or specs
 - self-describing: tickets that create or reshape source files carry the file-header criterion (see `file-headers`) — undocumented files force agents to re-derive intent
 - machine-verifiable value claims: quantified Must gate, runnable Meter, explicit anti-goals, and a `base_commit` anchor that reveals staleness
@@ -340,6 +340,9 @@ Focus on:
 - Is there a machine-checkable Must gate (quantified, unit + number) backed by a runnable Meter command?
 - Are touched code files self-describing — Purpose/Responsibilities/Rationale header present and current (see `file-headers`)?
 - Are priorities and labels sensible?
+- Does every ticket carry lane and complexity metadata (`afk`/`design`/`hitl`/`review` + `complexity:s/m/l/xl`)?
+- Are lane/complexity tags consistent with the work (DESIGN or HITL work never tagged `afk`)?
+- Are AFK tickets backed by an objective gate (CI/test suite/Meter), or tagged `no-gate` and kept out of autonomous scheduling?
 - Are HITL handoff points explicit?
 - Is it clear what demo, test, or observable behavior proves completion?
 
@@ -353,6 +356,10 @@ Watch for:
 - Tickets that create or reshape source files with no file-header acceptance criterion — undocumented files force every implementing agent to re-derive intent
 - No regression suite named (pass-to-pass coverage unspecified)
 - HITL work masquerading as AFK
+- DESIGN work (semantics decisions, API shape, concurrency models) tagged or scheduled as AFK — semantics need an interactive session, not an overnight run
+- Tickets tagged `complexity:xl` (epic-sized or semantics-heavy) presented as schedulable work instead of decomposition candidates
+- AFK tickets with no objective gate and no `no-gate` tag
+- Complexity grades that fail the falsifiable criteria — an S/M ticket touching a public API, an invariant, or concurrency code is mis-tagged and must be retagged L before scheduling
 - Tickets that cannot be closed without information from another issue not listed as a blocker
 
 Prefix findings with `EXEC-`.

package/pi-package/skills/issues/references/create-issues/SKILL.md

@@ -1,4 +1,4 @@
-<!-- skill: create-issues, version: 1.4.1, status: verified -->
+<!-- skill: create-issues, version: 1.5.0, status: verified -->
 # Tracer-Bullet Issue Creation from Plan
 
 Break a reviewed plan into independently grabbable issues using tracer-bullet vertical slices.
@@ -22,9 +22,19 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Prefer **vertical slices** over phase-by-phase horizontal tickets.
    - Each issue should cut through all necessary layers for one narrow capability: storage/schema, business logic, interface, tests, and observability/docs when relevant.
    - A slice must be independently verifiable or demoable.
-   - Mark each slice as:
-     - **AFK** — can be implemented and merged without human intervention.
-     - **HITL** — requires a human decision, approval, design review, copy review, policy signoff, etc.
+   - Mark each slice with a **lane** (execution mode) and a **complexity** grade:
+     - **Lane:**
+       - **AFK** — bounded, mechanically verifiable, mergeable without human intervention; the `afk` label means "safe to run autonomously", so it may only be applied when an objective gate exists (test suite, CI, or Meter command). Label: `afk`.
+       - **DESIGN** — needs an interactive design session before implementation: semantics decisions, API shape, concurrency models, trade-offs. A human works this with a strong-reasoning model, never autonomously. Label: `design`.
+       - **HITL** — pure human decision, approval, copy review, or policy signoff with little or no model work. Label: `hitl`.
+       - **REVIEW** — second-opinion pass over existing output (code review, spec audit, conformance check). Label: `review`.
+     - **Complexity (effort / model tier)** — graded by falsifiable criteria so a reviewer can gate a wrong tag:
+       - **S** — matches an existing pattern in the repo (same change shape already exists in code or a prior ticket); ≤3 files; no new public interface, dependency, or invariant; the Meter is an existing test command. Label: `complexity:s`.
+       - **M** — multi-file change within established patterns; new tests follow existing conventions; no new public API beyond the slice's own; no concurrency or protocol semantics. Label: `complexity:m`.
+       - **L** — introduces or changes an invariant, concurrency semantics, protocol conformance, or a public API; correctness requires reasoning the repo's existing tests do not already encode. Label: `complexity:l`.
+       - **XL** — unresolved semantics or cross-repo scope: two competent agents would disagree on what "done" means; do not schedule — decompose into S/M/L slices first. Label: `complexity:xl`.
+       - **Grade gate:** an S/M ticket that touches a public API, an invariant, or concurrency code is mis-tagged — retag L before publishing; an L ticket fully covered by an existing pattern plus an existing test command is mis-tagged — retag M or S.
+     - Classification signals: `decision`-type tickets or titles starting with Decide/Choose/Approve/Scope → DESIGN or HITL, never AFK; bounded bugs with a failing test or concrete repro in a repo with CI → AFK; verification/conformance sweeps → AFK; concurrency/security/semantics work → DESIGN unless a failing repro test exists; epics → XL. If the target repo has no CI or test suite, tag `no-gate` — never schedule AFK work without a gate.
    - Avoid tickets like “build backend”, “add UI”, or “refactor models first” unless the work is genuinely standalone.
    - **Title lint (hard rule — run on every drafted title before presenting):** a title must name a user-visible outcome (“CSV export works end-to-end”), not a layer. If a title names a layer or artifact — backend, frontend, API, route, button, serializer, schema, tests-only, docs-only, refactor-only — merge it into the outcome slice it serves. Layers differing is never sufficient reason to split: split by capability, never by layer.
 
@@ -33,11 +43,13 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
    - Present a numbered list before creating anything.
    - For each slice include:
      - **Title**
-     - **Type:** AFK or HITL
+     - **Lane:** AFK | DESIGN | HITL | REVIEW
+     - **Complexity:** S | M | L | XL
+     - **Gate:** Meter command or CI suite (required for AFK; `no-gate` otherwise)
      - **Blocked by:** slice numbers or “None”
      - **User stories covered**
      - **Why this is a tracer bullet:** brief end-to-end justification
-   - Ask whether the granularity, dependency graph, and AFK/HITL split look right.
+   - Ask whether the granularity, dependency graph, and lane/complexity split look right.
    - Iterate until approved.
 
 5. **Prepare issue bodies:**
@@ -90,6 +102,9 @@ You are a Technical Project Manager. Translate a plan, spec, or PRD into thin en
 - **Name the cheats:** add anti-goals wherever the gate could be gamed (test edits, new deps, API breaks).
 - **Anchor staleness:** always record `base_commit` metadata at creation; never publish a ticket anchored to nothing.
 - **Stop and ask:** if the plan only supports horizontal decomposition, propose a vertical rewrite before publishing.
+- **Lane and complexity are mandatory metadata:** every published slice carries both (`bd update <id> --label design --label complexity:m`). Route by them, not by preference: S/M AFK work defaults to the cheapest capable model tier; DESIGN and L work gets the strongest reasoning tier with elevated effort.
+- **No gate, no AFK label:** in a repo without CI/tests, tag `no-gate` *instead of* `afk` — the ticket is not scheduled autonomously until a gate exists; when one does, replace `no-gate` with `afk`.
+- **Escalation is a retag:** after two failed implementation attempts, raise complexity one grade (S→M→L); if the failure cause is semantic (unclear spec or design rather than implementation), switch the lane to `design`. Record the failure cause in the ticket either way.
 
 ## References
 - **Templates:** `references/templates.md`

package/pi-package/skills/issues/references/create-issues/references/criteria.md

@@ -18,7 +18,8 @@ Use these criteria to evaluate whether a plan has been translated into strong tr
 | **Baseline anchored** | Measurable claims record the pre-work value and the HEAD SHA as `base_commit` metadata for staleness detection. |
 | **Dependency hygiene** | Only real blockers are encoded; parallel work is not serialized without reason. |
 | **Workflow Mandate** | Includes the mandatory TDD and Tidy First block. |
-| **Execution mode** | Slice is explicitly marked AFK or HITL. |
+| **Execution mode** | Slice is explicitly marked with a lane (AFK/DESIGN/HITL/REVIEW) and a complexity grade (S/M/L/XL); AFK slices carry an objective gate or `no-gate` tag. |
+| **Complexity honesty** | Complexity matches the work, not the optimism: XL is used when semantics or scope are unresolved, not as a badge. |
 
 ## Tracer-Bullet Heuristics
 

package/pi-package/skills/issues/references/create-issues/references/templates.md

@@ -6,7 +6,9 @@ Use these templates for proposed slice breakdowns, issue descriptions, and the f
 
 ```markdown
 1. **[Title]**
-   - **Type:** [AFK|HITL]
+   - **Lane:** [AFK|DESIGN|HITL|REVIEW]
+   - **Complexity:** [S|M|L|XL]
+   - **Gate:** [Meter command / CI suite — required for AFK]
    - **Blocked by:** [None | Slice 1, Slice 2]
    - **User stories covered:** [Story A, Story B]
    - **Tracer-bullet rationale:** [Why this is a thin end-to-end slice]
@@ -71,8 +73,8 @@ Or: `None - can start immediately`
 **Plan:** [path/to/plan.md]
 
 ### Approved Slice Set
-1. **[Title]** — [AFK|HITL], blocked by [None|IDs]
-2. **[Title]** — [AFK|HITL], blocked by [None|IDs]
+1. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
+2. **[Title]** — [AFK|DESIGN|HITL|REVIEW] [S|M|L|XL], blocked by [None|IDs]
 
 ### Summary
 - **Total Issues Created:** [count]

package/pi-package/skills/issues/references/issue-review/SKILL.md

@@ -26,7 +26,7 @@ Treat the best issue sets as:
 - thin vertical slices rather than layer tickets
 - independently verifiable or demoable
 - minimal but sufficient dependency graphs
-- explicit about AFK vs HITL work
+- explicit about lane (AFK/DESIGN/HITL/REVIEW) and complexity (S/M/L/XL) work
 - traceable back to stories, plans, or specs
 - self-describing: tickets that create or reshape source files carry the file-header criterion (see `file-headers`) — undocumented files force agents to re-derive intent
 - machine-verifiable value claims: quantified Must gate, runnable Meter, explicit anti-goals, and a `base_commit` anchor that reveals staleness

package/pi-package/skills/issues/references/issue-review/references/pass-5-executability.md

@@ -6,6 +6,9 @@ Focus on:
 - Is there a machine-checkable Must gate (quantified, unit + number) backed by a runnable Meter command?
 - Are touched code files self-describing — Purpose/Responsibilities/Rationale header present and current (see `file-headers`)?
 - Are priorities and labels sensible?
+- Does every ticket carry lane and complexity metadata (`afk`/`design`/`hitl`/`review` + `complexity:s/m/l/xl`)?
+- Are lane/complexity tags consistent with the work (DESIGN or HITL work never tagged `afk`)?
+- Are AFK tickets backed by an objective gate (CI/test suite/Meter), or tagged `no-gate` and kept out of autonomous scheduling?
 - Are HITL handoff points explicit?
 - Is it clear what demo, test, or observable behavior proves completion?
 
@@ -19,6 +22,10 @@ Watch for:
 - Tickets that create or reshape source files with no file-header acceptance criterion — undocumented files force every implementing agent to re-derive intent
 - No regression suite named (pass-to-pass coverage unspecified)
 - HITL work masquerading as AFK
+- DESIGN work (semantics decisions, API shape, concurrency models) tagged or scheduled as AFK — semantics need an interactive session, not an overnight run
+- Tickets tagged `complexity:xl` (epic-sized or semantics-heavy) presented as schedulable work instead of decomposition candidates
+- AFK tickets with no objective gate and no `no-gate` tag
+- Complexity grades that fail the falsifiable criteria — an S/M ticket touching a public API, an invariant, or concurrency code is mis-tagged and must be retagged L before scheduling
 - Tickets that cannot be closed without information from another issue not listed as a blocker
 
 Prefix findings with `EXEC-`.

package/pi-package/skills/whisper/SKILL.md

@@ -1,44 +1,27 @@
 ---
 name: whisper
-description: "Knowledge workspace management: init, check, status, link plan, decommission, routing. Delegates to the turu CLI when installed."
+description: "Deterministic knowledge workspace: session loop (recall all / append), scope routing, distill, bundle. Delegates to the turu CLI when installed; manual fallbacks otherwise."
 metadata:
   installed-from: "incitaciones"
 disable-model-invocation: true
 ---
-# Whisper — Deterministic Operational Knowledge
+# Whisper — knowledge workspace (pointer)
 
-> **This skill is a thin pointer.** The canonical, versioned copy ships with
-> the `turu` CLI ([charly-vibes/whisper](https://github.com/charly-vibes/whisper),
-> `cargo install whisper-vibes`) — install it with `turu skill install`.
-> This file stays so agents without the binary have fallbacks.
+The canonical, versioned procedure lives in the **turu skill pack** —
+installed with `turu skill install` and shipped with the `turu` CLI
+([charly-vibes/whisper](https://github.com/charly-vibes/whisper),
+`cargo install whisper-vibes`).
 
-The `turu` CLI owns every mechanical step: canonical repo keys, branch slugs,
-worktree slots, and scope routing. Same inputs, same outputs — no more
-hand-rolled shell pipelines.
+## Routing rule
 
-## Decision procedure
-
-1. **Is `turu` available?** Run `turu key --json`.
-2. **If yes** — everything mechanical is a turu command:
-
-| Intent | Command |
-|---|---|
-| Derive repo key / branch slug / worktree slot | `turu key --json` |
-| Find the write destination for a scope | `turu resolve <scope> --json` |
-| Record knowledge (extend, don't duplicate) | `turu append <scope> --text "..."` |
-| Create the workspace layout | `turu init --json` |
-| Inspect paths and existence | `turu status --json` |
-| Validate / detect legacy keys | `turu check --json` · `turu doctor --json` |
-| Refresh the AGENTS.md routing block | `turu sync --json` |
-
-   Scopes: `global` (rules.md), `repo` (env.md), `branch` (notes.md),
-   `worktree` (env.md), `group` (shared workspace for a set of repos).
-   If a `<!-- TURU:START -->` block exists in `AGENTS.md`, read the routing
-   map from there instead of re-deriving paths.
-
-3. **If no** — use the manual fallbacks in `references/` (they remain the
-   source of truth for the shell-snippet procedures) and suggest
-   `cargo install whisper-vibes`.
+- **If `whisper.md` sits next to this file** (the installed pack), read it and follow it as your single source of procedure. It owns everything: the session loop (`turu recall all`
+at start, `turu append <scope> "..."` at capture), scope routing
+  (global → group → repo → branch → worktree), the command table, and all
+  modes. This pointer defers entirely and adds nothing — never reconcile
+  the two by hand.
+- **If the pack is absent**, `turu` is not installed: use the manual
+  fallbacks in `references/` (source of truth for the shell-snippet
+  procedures) and suggest `cargo install whisper-vibes`.
 
 ## Invariants (with or without the binary)
 
@@ -48,15 +31,4 @@ hand-rolled shell pipelines.
   than creating a new one that says the same thing.
 - **One repo, one key.** The canonical key is a pure function of the remote
   URL; never invent a variant.
-- **Search first.** Before creating a new entry, check if one exists.
-
-## Modes
-
-`/w init` → `turu init` · `/w` or `/w status` → `turu status` ·
-`/w check` → `turu check` · `/w link` → `subs/link-manual` (no CLI verb yet)
-· `/w decommission` → `subs/decommission-manual` · `/w consolidate` →
-`subs/consolidate-manual` (detection ships via `turu doctor`).
-
-Manual procedures for each mode: `references/init.md`, `references/check.md`,
-`references/status.md`, `references/link.md`, `references/decommission.md`,
-`references/consolidate.md`.
+- **Search first.** Before creating a new entry, check if one exists.