@tacuchi/agent-workflow-cli 21.17.0 → 22.0.1

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tacuchi/agent-workflow-cli",
-  "version": "21.17.0",
-  "description": "Runtime CLI for Workline — the stages + loops + artifacts system for agent work. Bundles the universal `w` skill set under `skills/w/` (slash commands `/w:*`: spec-new/spec-refine, plan-new/plan-exec, quick, persist, workspace-init, export-*); `self install --target <host>` copies SKILL + commands + hooks into the host. Pluggable capability skills via `.workflow/skills.toml`. Multi-empresa parametrization via `profile.json` cascade. Namespace auto-detected from any `.<ns>/sessions/` dir in CWD; default `workflow`.",
+  "version": "22.0.1",
+  "description": "Runtime CLI for Workline — the stages + loops + artifacts system for agent work. Bundles the universal `w` skill set under `skills/w/` (slash commands `/w:*`: spec-new/spec-refine, plan-new/plan-exec, quick, persist, workspace-init, export-*); `self install --target <host>` copies SKILL + commands + hooks into the host. Pluggable capability skills resolve through `.workflow/skills.toml`. Namespace auto-detected from any `.<ns>/sessions/` dir in CWD; default `workflow`.",
   "type": "module",
   "bin": {
     "agent-workflow": "dist/cli/main.js",
@@ -9,8 +9,8 @@
   },
   "files": ["dist", "skills", "LICENSE", "README.md"],
   "scripts": {
-    "build": "tsc",
-    "build:watch": "tsc --watch",
+    "build": "node scripts/clean-dist.mjs && tsc",
+    "build:watch": "node scripts/clean-dist.mjs && tsc --watch",
     "test": "vitest run",
     "test:watch": "vitest",
     "test:golden": "vitest run tests/golden",
@@ -31,7 +31,7 @@
     "codex",
     "namespace"
   ],
-  "author": "Tacuchi <jesus.loayza@quetalcompra.com>",
+  "author": "Tacuchi",
   "license": "AGPL-3.0-or-later",
   "repository": {
     "type": "git",

package/skills/w/SKILL.md

@@ -55,7 +55,7 @@ USER invokes
 - **Layer 2** — the AI iterates end to end until convergence. No direct human invocation.
 - **Layer 3** — ephemeral, internal, process-only. Nobody invokes it by hand.
 
-> **Tools pointer:** auxiliary tooling has its home under `docs/tools/<slug>/` (README + run/output structure per the skill's contract; index row in `docs/tools/README.md`), authored by the **ambient `creating-tools` skill** — the host auto-discovers it when authoring any support tool, and the code loops' closing gate catches the miss (`loops/CODE-POLICIES.md` § *Closing review gate*). A ready implementation ships in the `tool-builder@qtc-marketplace` plugin; Workline does **not** depend on it (ambient, never bound).
+> **Tools pointer:** auxiliary tooling has its home under `docs/tools/<slug>/` (README + run/output structure per the skill's contract; index row in `docs/tools/README.md`), authored by the **ambient `creating-tools` skill** — the host auto-discovers it when authoring any support tool, and the code loops' closing gate catches the miss (`loops/CODE-POLICIES.md` § *Closing review gate*). A ready implementation may be installed independently; Workline does **not** depend on it (ambient, never bound).
 
 ### The 3 flows
 
@@ -196,7 +196,7 @@ One language per plane — never mix them:
 | **Section headings** of artifacts and docs (`## Requirement`, `## Completed`, …) | **English** (parse contract) |
 | Everything **user-facing**: structured-choice questions, reports, dashboards, the **content** the AI writes into artifacts and `docs/` deliverables, commit messages | **the user's language** (this product: Spanish) |
 | Literal option labels (`Continuar`, `Compactar`, `Cerrar`, `Aceptar recomendaciones`, `Aprobar y guardar`, `Refinar`, …) | canonical product strings — use them **verbatim** |
-| Domain terms (class/route/table names, e.g. the QTC fleet) | the domain's ubiquitous language (Spanish) — never translated |
+| Domain terms (class/route/table names, e.g. an existing fleet) | the domain's ubiquitous language (Spanish) — never translated |
 
 ### The 6 hard invariants
 

package/skills/w/artifacts/artifacts-core/SCRIPTS.sql

@@ -1,8 +1,8 @@
 -- SCRIPTS.sql — session artifact (common)
 --
--- What it is: the SQL produced by a session. TWO types, distinguished by whether they are EXECUTED:
---   A) READ-ONLY queries (diagnosis/validation): the AI writes them here and then
---      executes them read-only via MCP.
+-- What it is: SQL and remote-read context produced by a session. TWO roles are distinguished:
+--   A) READ-ONLY remote queries: research context captured before plan approval, never
+--      execution validation or a closing proof.
 --   B) DDL/DML migrations (schema/data changes): the AI DRAFTS them as a
 --      deliverable but NEVER executes them; they are exported to docs/scripts/ (forward +
 --      rollback) for a human/DBA to apply.
@@ -12,24 +12,29 @@
 --
 -- Rules:
 --   1) One entry per script, numbered, with purpose, DB/MCP target and type (A or B).
---   2) Only type A is executed (read-only, via the declared MCP).
+--   2) A type A entry records `{kind: remote-read, connection, readonly: true, query_artifact,
+--      captured_at, result_digest}` and has a matching note in CONCLUSIONS.md.
 --   3) Lives in the session (.workflow/sessions/NNN-.../SCRIPTS.sql).
 --   4) Type B is exported to docs/scripts/ as a deliverable (not executed by the AI).
 
 -- ============================================================
--- [Q1] <purpose of the query>   |   Type: A (read-only)
--- DB/MCP: <which>   |   Origin: <gap / task that motivates it>
+-- [Q1] <purpose of the query>   |   Type: A (remote-read research context)
+-- Snapshot: {kind: remote-read, connection: <which>, readonly: true,
+--            query_artifact: SCRIPTS.sql#Q1, captured_at: <ISO-8601>, result_digest: <digest>}
+-- Origin: <research gap only; never a plan task/validation/exit condition>
 -- ------------------------------------------------------------
 SELECT ...;
 
 -- ============================================================
--- [Q2] <purpose>   |   Type: A (read-only)
--- DB/MCP: <which>   |   Origin: <...>
+-- [Q2] <purpose>   |   Type: A (remote-read research context)
+-- Snapshot: {kind: remote-read, connection: <which>, readonly: true,
+--            query_artifact: SCRIPTS.sql#Q2, captured_at: <ISO-8601>, result_digest: <digest>}
+-- Origin: <research gap only>
 -- ------------------------------------------------------------
 SELECT ...;
 
 -- ============================================================
--- [M1] <migration>   |   Type: B  —  DO NOT EXECUTE (deliverable; applied by a DBA;
+-- [M1] <migration>   |   Type: B  —  DO NOT EXECUTE (deliverable; external application is handoff;
 --                        exported to docs/scripts/ via export-*)
 -- DB/MCP: <which>   |   Origin: <plan task>
 -- ------------------------------------------------------------

package/skills/w/artifacts/artifacts-research/CONCLUSIONS.md

@@ -15,3 +15,10 @@ Example:
 
 ## Details
 Supporting detail, evidence references, or additional context.
+
+## Remote context (only when captured)
+
+For each read-only remote investigation, record the matching `RemoteContextSnapshot` from
+`SCRIPTS.sql`: connection, query artifact, capture time and result digest. It is research context
+with no automatic expiry; refreshing it requires a plan/spec refine. It is never copied into a
+task, validation, exit condition or closure claim.

package/skills/w/commands/export-scripts.md

@@ -1,5 +1,5 @@
 ---
-description: Use to promote the type-B `SCRIPTS.sql` artifacts of N sessions into a docs/scripts/ bundle — continuous forwards plus rollback. `aw export-scripts` checks the bundle shape and NEVER executes SQL. Never automatic.
+description: Use to promote the type-B `SCRIPTS.sql` artifacts of N sessions into a docs/scripts/ bundle — continuous forwards plus rollback. `aw export-scripts` checks shape and NEVER executes SQL. Never automatic.
 argument-hint: "[--sessions <ids>] [--since <YYYY-MM-DD>] [--source <alias>]"
 allowed-tools: ["Bash", "Read"]
 ---
@@ -14,9 +14,15 @@ allowed-tools: ["Bash", "Read"]
 ## What it produces
 
 - `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`: `00-ROLLBACK.sql` and `README.md`, both required, + forwards `NN-<nombre>.sql` numbered **continuously from 01**; the CLI rejects a gap.
-- Neither the AI nor the CLI executes the SQL: the bundle is for a human or DBA to apply.
+- Neither the AI nor the CLI executes the SQL: its application is a non-blocking handoff to an authorized operator.
 - Never write into `docs/` with a file tool: one pass, all or nothing, no session or loop created/touched.
 
+## Net final state
+
+Publish the final state, not a session chronology: omit transients, write migrations in final form,
+and reconcile code before delivery. Rollback safely reverses it; exclude concrete identities and test seeds.
+`ESTADO FINAL NETO` · `orden seguro para las dependencias` · `objetos compartidos y necesarios para el estado final`
+
 ## More context
 
 `aw context-plan --command export-scripts --signal <s> --root "${CLAUDE_PLUGIN_ROOT}/skills/w"` returns the extra documents a case needs; read exactly what it lists:

package/skills/w/commands/plan-new.md

@@ -13,6 +13,7 @@ allowed-tools:
 # plan-new — trampoline to the planning loop
 
 SPEC → PLAN bridge. Turns the "what" (refined spec) into the "how" (plan). Delegates to `plan-new-loop` (Layer 2).
+An unready or legacy spec is input, never a block.
 
 > **Hard floor — applies even if you read nothing beyond this file:**
 >

package/skills/w/context/MANIFEST.json

@@ -175,18 +175,11 @@
         },
         {
           "path": "modules/EXEC-DB-POLICY.md",
-          "signal": "db",
-          "requires": "external-data"
+          "signal": "db"
         },
         {
           "path": "modules/DB-SCRIPTS-ONLY.md",
-          "signal": "db",
-          "requires": "external-data"
-        },
-        {
-          "path": "modules/DB-RESEARCH-RULE.md",
-          "signal": "db",
-          "requires": "external-data"
+          "signal": "db"
         },
         {
           "path": "modules/SIMULATION-LIFECYCLE.md",

package/skills/w/exports/export-scripts/EXPORT.md

@@ -1,11 +1,11 @@
 ---
 name: export-scripts
-description: "Consolidates the workspace's pending SQL into a single `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` bundle with continuous numbering after `00-ROLLBACK.sql`. Reads type-B migrations (DDL/DML) from two sources: `.workflow/sessions/<folder>/SCRIPTS.sql` across N sessions AND standalone `docs/scripts/*.sql` (excluding previous bundles). Ignores read-only type-A (diagnostic queries, not deliverables). Minimal SQL headers + a simple README (3 sections: Files / Apply / Revert). The rollback is derived from the forwards. Read-only/report: it NEVER executes SQL nor commits — the bundle is for a human/DBA to apply. Composes the `sql` capability. Use for 'release SQL bundle', 'prepare the prod push', 'consolidate pending SQLs'. User-invoked via `/w:export-scripts`."
+description: "Consolidates pending SQL into one `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` bundle with continuous numbering after `00-ROLLBACK.sql`. It publishes the net final state, not a chronological transcript. Reads type-B migrations (DDL/DML) from session `SCRIPTS.sql` and standalone `docs/scripts/*.sql`, excluding prior bundles and read-only research. Read-only/report: it NEVER executes SQL nor commits; external application is a handoff. Composes the `sql` capability. User-invoked via `/w:export-scripts`."
 ---
 
 # export-scripts — consolidated SQL bundle, simple and direct
 
-Consolidates the pending SQL migrations of N sessions + standalone files into a single bundle under `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`, with continuous numbering after `00-ROLLBACK.sql`. **Read-only / report** — the AI **never executes** the SQL; the user/DBA applies the bundle manually.
+Consolidates the pending SQL migrations of N sessions + standalone files into a single bundle under `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`, with continuous numbering after `00-ROLLBACK.sql`. **Read-only / report** — the AI **never executes** the SQL; external application is an optional handoff.
 
 > `export-*` family (the only artifact→`docs/` path). Design: `docs/referencias/workflow-exports/export-scripts.md`.
 
@@ -19,16 +19,16 @@ The **`sql`** capability (built-in default `sql`), resolved via `.workflow/skill
 
 ## When to use
 
-- "Release SQL bundle", "prepare the prod push", "consolidate pending SQLs".
-- Before promoting a branch to certification / `main`.
+- "Release SQL bundle", "consolidate pending SQLs".
+- Before an authorized release handoff.
 - After several `exec`/`quick` sessions left `SCRIPTS.sql` files with migrations.
 
 ## What it does
 
 1. Collects the workspace's SQL from **two sources**: each corpus session's type-B `SCRIPTS.sql` + standalone `docs/scripts/*.sql` (excluding previous bundles).
 2. Classifies the statements by canonical category (DDL-TABLES / DDL-FUNCTIONS / DML / INSERTS).
-3. Consolidates cross-source per category with **continuous numbering** after `00-ROLLBACK.sql`.
-4. Writes the consolidated forwards (each statement with its origin, 1 line).
+3. Resolves the **net final state** across sources, then groups it by category with **continuous numbering** after `00-ROLLBACK.sql`.
+4. Writes only the forwards needed for that final state, retaining traceable origin where useful.
 5. Derives `00-ROLLBACK.sql` **at the end**, reading the already-written forwards.
 6. Writes a minimal `README.md` (Files / Apply / Revert).
 
@@ -90,9 +90,13 @@ If the A + B union is empty → **abort**: there is no pending SQL in the worksp
 
 `aw next-number docs/scripts` → `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`.
 
-### Step 3 — Classification and internal order
+### Step 3 — Net final state, classification and internal order
 
-Group by canonical category: `01 DDL-TABLES` · `02 DDL-FUNCTIONS` · `03 DML` · `04 INSERTS`. Internal order chronological by origin (ascending session → ascending stmt; standalone interleaved by lexical filename order).
+Reconcile the session and standalone candidates against the code and the declared final state. Omit
+objects born and retired within the sequence; write migrated objects directly in their final form;
+omit explicitly retired objects even when their deletion is absent from the input. Then group the
+remaining statements by canonical category: `01 DDL-TABLES` · `02 DDL-FUNCTIONS` · `03 DML` ·
+`04 INSERTS`. Origin is traceability, not an ordering authority over the final contract.
 
 ### Step 4 — Continuous numbering (no gaps)
 
@@ -100,7 +104,7 @@ Assign sequential numbers **only to categories with content**, in canonical orde
 
 ### Step 5 — Write the forwards
 
-Per category with content, one file with a 1-2 line header (`-- 0N-<CATEGORY>.sql — bundle NNN-export-scripts-YYYY-MM-DD`) and, per statement, **a one-line origin comment** (`-- sessionXXX / stmt-id` or `-- docs/scripts/001-filename.sql`) followed by the SQL exactly as the developer wrote it (wrapped in `BEGIN; … COMMIT;` where it applies). Do not replicate motivation/impact/idempotency already present at the origin; no statement index, no invented verification SELECTs.
+Per category with content, one file with a 1-2 line header (`-- 0N-<CATEGORY>.sql — bundle NNN-export-scripts-YYYY-MM-DD`) and traceable origin comments where useful. Write SQL for the reconciled final state, not necessarily the original statement verbatim; preserve explicit intent, idempotency and safe transaction boundaries. Do not replicate motivation/impact already present at the origin; no statement index, no invented verification SELECTs.
 
 ### Step 6 — Derive `00-ROLLBACK.sql` (at the end)
 

package/skills/w/loops/CHASSIS.md

@@ -40,7 +40,7 @@ The persistent objective needs a **checkable done-condition** — otherwise the
 - **Form and weight scale**: a chore = "existing tests/build stay green" (one line); a feature = real acceptance tests. The rule is "**always declare the check before**", not "always write new tests".
 - **Subjective deliverable** (analysis/design): the AI **proposes** the rubric and the **human ratifies** it before pursuing it.
 - **Unresolvable criterion** (no evidence, DB unavailable): closes as `inconclusive` and the loop **degrades** — **never iterates against a fake target**.
-- **Cert-only**: a criterion needing **production or the deployed product** is not a done-condition — nobody in the run can run it, so the phase waits forever. Verify in cert.
+- **Source-bounded**: a closing criterion is demonstrated by a command or inspection tied to the acquired checkout. A deployed product, host runtime or remote connection is research context or an operational handoff, never a done-condition.
 
 **Gate integrity (anti-gaming + independent verification).** The gate only counts if it is not gamed to pass. The loop does **not**: modify the check or loosen a `Success criterion` to force green; weaken, delete or skip tests/validations; use trivial or tautological asserts that always pass (the expected value comes from an independent source, never from the output itself); patch the test instead of fixing the cause (prefer fixing production code).
 

package/skills/w/loops/plan-exec-loop/LOOP.md

@@ -23,7 +23,7 @@ PLAN
 `/w:plan-exec` — **resumable** (same chassis mechanism; here resume keys off the plan-doc phase states + checkboxes + CHECKPOINT, see Delta 1).
 
 ## Reads
-`docs/plans/PPP-plan-<slug>.md` (locate via the `docs/plans/PPP-plan-*.md` glob or the exact path from the command argument) **and its source spec** (resolved through the plan's `## Origin`) — the entry gate reads both. It runs **any** plan, whether or not it passed through [`plan-refine-loop`](../plan-refine-loop/LOOP.md) — plan-refine is auxiliary, not mandatory; no gate requires it. What it does require is an **executable shape** (§ *Entry gate — executability*). If the plan pins design, it also reads the **UI Design Package** revisions its `## Design references` and its tasks name — **read-only**, at the exact revision each one fixed (§ *Design precondition gate*).
+`docs/plans/PPP-plan-<slug>.md` (locate via the `docs/plans/PPP-plan-*.md` glob or the exact path from the command argument) **and its source spec** (resolved through the plan's `## Origin`) — the entry gate reads both. It runs any plan whose source contract is executable: `> Límite de ejecución: checkout`, explicit phase/task sources and aliases from `AGENTS.md > Fuentes`. A legacy or v21 plan that lacks it fails closed to [`plan-refine-loop`](../plan-refine-loop/LOOP.md); plan-refine remains auxiliary only after that contract exists. If the plan pins design, it also reads the **UI Design Package** revisions its `## Design references` and its tasks name — **read-only**, at the exact revision each one fixed (§ *Design precondition gate*).
 
 ## Writes
 - `docs/plans/PPP-plan-<slug>.md` (**read/update**, living doc: phase/task state, `Open questions`).
@@ -44,7 +44,7 @@ inference, the deferred-validation cycle and conditional Git authorization.
 
 ## Composes
 
-`git` (safe branch + proposed commits) · `sql` (DB rule). Both resolved via `.workflow/skills.toml`; `off` → the loop continues without the capability and, if it was needed, says so or asks.
+`git` (safe branch + proposed commits). `plan-exec` does **not** load `external-data`: its proof comes from the acquired checkout only. SQL fixture/ephemeral tests are ordinary local commands; remote MCP reads belong to earlier research, never this loop.
 
 > **Ambient conventions (not roles):** code/testing/writing standards and `creating-tools` are standalone skills the host auto-discovers by `description` — Workline neither binds nor depends on them. Full doctrine: [../../roles/README.md](../../roles/README.md).
 
@@ -59,11 +59,14 @@ inference, the deferred-validation cycle and conditional Git authorization.
 ## Entry gate — executability
 
 **Before touching code**, read the plan and its spec and check the shape execution depends on:
+this is § *Entry gate — executability*. Once that shape exists, plan-refine is auxiliary, not mandatory.
 
-1. every phase declares its `Resultado`, its `Condición de salida` and its `Validación de fase`;
-2. if temporary behavior exists, its current boundary and retirement phase are identifiable; otherwise the simulation check is not applicable;
-3. the primary proof of the first `pendiente` phase is identifiable;
-4. no structural contradiction is evident (a phase that undoes an earlier one, evidence nobody can produce).
+1. the plan declares `> Límite de ejecución: checkout`; every phase has `> Fuentes:` and every task has `_(fuentes: …)_`; aliases resolve through `AGENTS.md > Fuentes` (except reserved `workspace`) and task sources are a subset of their phase;
+2. every phase declares its `Resultado`, its `Condición de salida` and its `Validación de fase`;
+3. if temporary behavior exists, its current boundary and retirement phase are identifiable; otherwise the simulation check is not applicable;
+4. the primary proof of the first `pendiente` phase is identifiable and is a checkout command or inspection;
+5. no structural contradiction is evident (a phase that undoes an earlier one, evidence nobody can produce).
+6. reading the phase prose shows that no deployed product, installed host, MCP connection or remote URL is a validation or exit condition; those observations belong to research or `Handoff operativo`, never the closure path.
 
 Execution **no longer accepts in silence** a plan that would force it to invent its own structure. Two outcomes:
 
@@ -122,8 +125,8 @@ reconciliation** in `CHECKPOINT`, never reported as published.
 - **Marking order (hard rule):** a phase reaches `validada` only with its proof run and passed, its
   exit condition true and the combined review green; a blocker is never deferred into `validada`.
   **Never** because all its checkboxes are ticked.
-- **Intermediate states:** `bloqueada` = the phase is stopped on a live blocker — recorded in `CHECKPOINT` + the plan's `## Open questions`, back to `en ejecución` when it clears; it counts as **not validated**. A phase whose work is complete but whose operative check the AI **cannot run** (an unapplied migration — Delta 3) **stays `bloqueada`**: its finished tasks keep their boxes ticked, and the reason goes on its own `> Bloqueo:` line, dropped when the blocker clears. It counts as **not validated** until the check runs and passes. Never a silent `validada`.
-- **A blocker without a reason is not a blocker (hard rule).** Writing `> Estado: bloqueada` **always** writes its `> Bloqueo:` line in the same edit: a state that says "stopped" without saying on what is a dead end for whoever reads `aw status` next. The runtime tolerates a legacy block that states none (`blocker: null`) — this loop never produces one. `CHECKPOINT.Next` names **the action that unblocks it** ("apply migration 014, then re-run the persistence proof"), never the state it is in.
+- **Intermediate states:** `bloqueada` = the phase is stopped on a live checkout blocker — recorded in `CHECKPOINT` + the plan's `## Open questions`, back to `en ejecución` when it clears; it counts as **not validated**. A proof that cannot run **stays `bloqueada`**. A deferred check never counts as a passed one. A script awaiting real-world application is a **handoff**, not a blocker: local fixture/ephemeral validation can still establish the promised behavior and the phase may become `validada`.
+- **A blocker without a reason is not a blocker (hard rule).** Writing `> Estado: bloqueada` **always** writes its `> Bloqueo:` line in the same edit: a state that says "stopped" without saying on what is a dead end for whoever reads `aw status` next. The runtime tolerates a legacy block that states none (`blocker: null`) — this loop never produces one. `CHECKPOINT.Next` names **the action that unblocks it** in the checkout, never an operator's deployed run.
 - **Plan-doc residue (hard rule):** execution writes into the plan-doc **only** five things — checkbox flips (`- [ ]` → `- [x]`), the phase's own `> Estado:` line, its `> Bloqueo:` line while blocked, deferrals appended to its `## Open questions`, and the plan's own status mark (its `> Estado:` line and, on close, its `> Cierre:` line — Delta 6). The declared-gap hatch is Deltas 4, 5 and 7. Per-phase results, review-gate findings and metrics go to the session's `DECISION`/`CHECKPOINT` — **never** into the plan-doc. Phase blocks are updated **in place — NEVER append a duplicate `### Fn` block** (same contract as CHECKPOINT sections). The entry gate's consented normalization is the single exception, and it lands before execution starts.
 - **CHECKPOINT per execution unit:** record its effective grouping, functional states, simulation
   boundary when applicable, checks/results, decisions, deferrals and next intent. The task boxes
@@ -175,9 +178,10 @@ adds nothing of its own beyond running on a verified branch and never
 - Each added test is re-weighed at the closing review gate ([`../CODE-POLICIES.md`](../CODE-POLICIES.md) § *Closing review gate* → *Test-value lens*, tag `overtest`): over-testing is a **finding to fix or justify**, never an automatic rejection.
 - Also run the plan's `## Validations` (cross-cutting rules and constraints) + the Final behavior block of `## Solution` (legacy plans: the `## Final behavior` section) + the spec's acceptance/success criteria (its `## Scenarios`, if present, are ready-made test cases: GIVEN=arrange · WHEN=act · THEN=assert).
 - A validation that **runs and fails** → back into the phase (gap): no advancing, no `validada`.
-- **Validation depending on an unapplied migration**: since the AI never executes the DML, it **cannot run it read-only** → the check is **deferred** (handoff to a DBA) and the phase **stays `bloqueada`**. A phase whose implementation is finished but whose operative proof cannot run does not become `validada`: the work may be complete and its boxes ticked, but the state waits until the proof runs and passes. The reason goes on its `> Bloqueo:` line, in `CHECKPOINT`, in the plan's `## Open questions` and in `BACKLOG`, marked "verification pending until the SQL is applied". (Reuses the chassis degrade/defer pattern + `MAX` cap → avoids the "back to the task" loop.)
 
-> The **final validation** is PLAN-exec's **convergence gate** = **`Success criteria` green** (*verification-first*; analogous to SPEC's *analyze gate* and plan-new's *coherence gate*): the plan is not marked *done* until it passes. A deferred check never counts as a passed one — it keeps its phase `bloqueada` and the plan open. For code these are **runnable tests** (TDD); for non-executable DB migrations, a **rubric** (SCRIPTS.sql valid + reviewed).
+- **SQL delivery**: validate the migration's behavior against a fixture or ephemeral database in the acquired checkout. The forward/rollback script is delivered through `SCRIPTS.sql` and `export-scripts`; a real application is an optional handoff and never keeps a phase or the plan open.
+
+> The **final validation** is PLAN-exec's **convergence gate** = **`Success criteria` green** (*verification-first*; analogous to SPEC's *analyze gate* and plan-new's *coherence gate*): the plan is not marked *done* until local proof passes. For code and persistence these are checkout commands/tests; a script's real-world application is never a closing criterion.
 
 ## Delta 5 — Closing review gate (conventions, pre-commit)
 

package/skills/w/loops/plan-new-loop/LOOP.md

@@ -1,16 +1,10 @@
 ---
 name: plan-new-loop
 description: >-
-  Generates a rich implementation plan (docs/plans/PPP-plan-<slug>.md) from a
-  spec. Heir of the chassis (loops/CHASSIS.md). Deltas: the plan absorbs the
-  TECHNICAL-NOTE level + Tasks phased by verifiable functional state
-  (### Fn blocks with live state),
-  code/impact-mapping research, planning gap taxonomy, and promotion of the
-  design closure to handoff via `design`: reuse a valid one, promote the rest,
-  then pin the roots
-  when the plan includes UI. If the spec is not refined it suggests
-  spec-refine first. Started by /w:plan-new; resumable. Invoke when a spec
-  must become an executable plan.
+  Generates an executable plan (docs/plans/PPP-plan-<slug>.md) from a spec.
+  Heir of CHASSIS: phases are verifiable states; research maps impact and
+  gaps; UI design roots are reused or promoted and pinned. Suggests
+  spec-refine first when needed. Started by /w:plan-new; resumable.
 ---
 
 # plan-new-loop
@@ -27,14 +21,14 @@ PLAN
 `/w:plan-new` — **resumable** (same chassis mechanism, keyed off CHECKPOINT).
 
 ## Reads
-`docs/specs/NNN-spec-*.md` (glob — locates the spec by number; or the exact path from the command argument). **Ready vs not** is read from the spec's frontmatter `status`, never from the filename, and a spec that is not ready is a **soft suggestion** to refine first, never a block — the four input modes are in [`PLAN-INPUT`](../../modules/PLAN-INPUT.md). Questions the spec left with destination `PLAN` are **input to this loop**, not a reason to send it back.
+`docs/specs/NNN-spec-*.md` (glob or argument path). Readiness comes from frontmatter `status`, never the filename; an unrefined spec only suggests [`PLAN-INPUT`](../../modules/PLAN-INPUT.md)'s refine path. Questions routed to `PLAN` remain input to this loop.
 
 ## Writes
-`docs/plans/PPP-plan-<slug>.md` (`generate`; **overwrites with confirmation** if it exists) — or **several sibling plans** when an accepted split applies (§ *Split gate (multi-plan)*). With UI, also the design revision it publishes under `docs/designs` (chassis § *docs/ boundary*). It never graduates/exports anything else to `docs/` — that is separate `export-*` work.
+`docs/plans/PPP-plan-<slug>.md` (`generate`; overwrite needs confirmation), or sibling plans after an accepted split (§ *Split gate (multi-plan)*). With UI it also publishes the scoped design revision in `docs/designs/`; it never graduates/exports anything else to `docs/` — that is separate `export-*` work.
 
-> **Naming** follows [`PLAN-INPUT`](../../modules/PLAN-INPUT.md) § *Numbering*: the claim CLAIMS `PPP` **for its run** — two flows never get the same one, only its owner fills it; closing unpublished frees it. Plans glob as `docs/plans/PPP-plan-*.md`.
+> **Naming:** [`PLAN-INPUT`](../../modules/PLAN-INPUT.md) § *Numbering* claims `PPP` for its run; only its owner fills it and an unpublished close frees it. Plans glob as `docs/plans/PPP-plan-*.md`.
 
-> **Adoption (command mode 4):** an **externally-built plan** (host plan mode, hand-written, another agent) is materialized by the **command** in a single pass — this loop does not run: transcribe + normalize into the Delta 1 schema, `## Origin` = "adopted from <source>" + attribution; then `plan-refine` closes schema gaps (its coherence gate degrades for spec-less plans). See `../../modules/PLAN-INPUT.md` (the command's `input` module).
+> **Adoption (mode 4):** the command transcribes an externally-built plan once into Delta 1, records `## Origin`, then `plan-refine` closes schema gaps. See [`PLAN-INPUT`](../../modules/PLAN-INPUT.md).
 
 ## Inherits
 
@@ -57,6 +51,7 @@ The plan keeps technical detail and roadmap inline:
 
 > Derived from docs/specs/NNN-spec-<slug>.md · generated by plan-new-loop
 > Estado: open
+> Límite de ejecución: checkout
 
 ## Origin              source spec/prompt or adopted source + attribution
 ## Solution            the how: brief AS-IS → TO-BE + closing "Final behavior" block (core)
@@ -86,19 +81,24 @@ This is the single contract; the other PLAN loops reference it.
 ```markdown
 ### F1 — <result-oriented name>
 > Estado: pendiente
+> Fuentes: workspace, <declared-source>
 
 **Resultado:** <the new verifiable state of the system>
 **Trabajo:**
-- [ ] T1.1 — <coherent unit of work>
+- [ ] T1.1 — <coherent unit of work> _(fuentes: <declared-source>)_
 **Validación de fase:** <the primary proof that the promised state was reached>
 **Condición de salida:** <falsifiable result · contract preserved>
 ```
 
 **Required**: `Resultado` · `Trabajo` · `Validación de fase` · `Condición de salida` · the state
-line. **Conditional**: `Estado inicial` when unclear · `Recorrido afectado` for a distributed
+line · `Fuentes`. Every task declares `_(fuentes: …)_`; task sources are a phase subset and either
+`workspace` or an exact `AGENTS.md > Fuentes` alias. `Impacted` never substitutes them. **Conditional**: `Estado inicial` when unclear · `Recorrido afectado` for a distributed
 change · `Dependencias` when direct sequence is insufficient · `Límite de simulación` (**only** when temporary behavior exists) · `Diferido` when work was consciously excluded.
 **A new phase never writes an empty conditional block.**
 
+**Checkout is the only closing surface.** Proof is a local command, fixture, ephemeral DB or checkout
+inspection. A deployed host, product or remote read is research or non-blocking `Handoff operativo`, never phase closure.
+
 **Phase state = machine state.** One bare `> Estado: <value>` line uses `pendiente` | `en ejecución`
 | `bloqueada` | `validada`. It is updated in place and counted
 **alongside — not instead of —** checkboxes. `validada` requires completed work, a true exit

package/skills/w/loops/plan-refine-loop/LOOP.md

@@ -48,6 +48,9 @@ can establish.
 ## Writes
 Updates `docs/plans/PPP-plan-<slug>.md` **in place** (when the user picks `Aprobar y guardar`): completes/adjusts sections and **adds** `## Refinement decisions`. Since it overwrites an existing doc, the preview says so and the person approves it **once**. On an accepted split (§ *Split gate — refine semantics*) the same proposal also **creates** the extracted sibling plans (newly minted `docs/plans` files) — one preview, one decision, one all-or-nothing write. It writes `docs/plans` and, when the refine **touches UI**, the **revision it publishes** — scoped to the artifacts the delta actually affects — of the design package under `docs/designs` (chassis § *docs/ boundary*; see [`DESIGN-REFERENCES.md`](../../modules/DESIGN-REFERENCES.md)). It never graduates/exports anything else to `docs/` — that is separate `export-*` work.
 
+> **Revision + consumer:** a new baseline carries the final plan as `consumer_document`
+> (path + base digest); package, manifest and plan publish or roll back together.
+
 ## Inherits
 
 Read **[`../CHASSIS.md`](../CHASSIS.md)** — the loop's **full engine** — **always before** these deltas. *(If `../` does not resolve: `CHASSIS.md` next to this file — global layout rule, chassis § Reference resolution.)*
@@ -127,6 +130,8 @@ This loop's instance of the chassis convergence gate — the same one `plan-exec
 - **Contract** — relevant inputs, outputs and observable states identified; the final behavior matches the spec; no functional criterion invented here.
 - **Journey** — main components identified, order reasonable, repo/process boundaries visible, the described architecture the one the project actually has.
 - **Phases** — each leaves a verifiable state with its exit condition, none is a list of layers or files, the order allows early integration, deferrals are explicit.
+- **Source boundary** — the plan declares `> Límite de ejecución: checkout`, each phase declares `> Fuentes:`, every task carries `_(fuentes: …)_`, aliases resolve through `AGENTS.md > Fuentes` (or reserved `workspace`) and task sources stay within their phase.
+- **Source-bounded semantics** — read the meaning of every task, phase validation and exit condition. A deployed product, installed host, MCP connection or remote URL may be research context or `Handoff operativo`, never a prerequisite or proof of closure; rewrite it as a fixture, ephemeral dependency or checkout inspection. This is semantic review, not a word denylist.
 - **Simulation** *(only when the change carries one)* — initial boundary identified, every displacement foreseen, one phase owns the retirement, nothing can stay active by accident. No temporary behavior → the check does not apply, and no empty `Límite de simulación` is required.
 - **Evidence** — every phase declares its primary proof, per-layer tests are justified, the same scenario is not duplicated by default, declared risks have evidence or an explicit deferral.
 - **Execution batches** — every phase appears once; maximal continuous ranges cross no decision, proof, handoff, irreversible action or required recovery boundary.
@@ -152,7 +157,7 @@ plan-refine-loop(plan):
       design (revisions only for the artifacts this refine affects; behavior/acceptance → spec-refine first)
     integrate + update CHECKPOINT                              # artifact-first cycle
   executability gate (read-only) = Success criteria green:
-    - contract · journey · phases · simulation · evidence · execution batches · resumability (§ Executability gate)
+    - contract · journey · phases · source boundary · simulation · evidence · execution batches · resumability (§ Executability gate)
     - plan-new checklist (criterion→task · Final behavior block of Solution · deps · Impacted↔Solution · UI→exact roots · minimality)
       # spec-less plan (adopted/hand-written): criteria anchor to the plan's own Final behavior block/Validations (see Delta 2)
     - re-refine's own check: the plan is REALIGNED with what changed

package/skills/w/loops/quick-loop/LOOP.md

@@ -52,7 +52,7 @@ Read **[`../CHASSIS.md`](../CHASSIS.md)** — the loop's **full engine** — **a
 
 - **No phases, no plan-doc**: the prompt **is** the task (a single unit). No roadmap.
 - **Proportional verification-first** (minimal ceremony): even here the check is **seeded before**, sized to the task. Code: one test (bug repro → fix) or "existing build/lint/tests stay green" (chore). **Analysis/design**: a **short falsifiable rubric**, *ratified by the user* before pursuing it. It is the run's `SESSION.Success criteria` (see [chassis § *Verification-first*](../CHASSIS.md)).
-- **Git and DB inline** (full policies in [`../CODE-POLICIES.md`](../CODE-POLICIES.md)): before editing, verify each source's expected branch (`aw check-branch`); **proposed** commit (approve first) — never `push`/`--amend`/`--no-verify`. The AI **never executes DML/DDL**: migrations are drafted into the session's `SCRIPTS.sql` (read-only queries do run, via MCP).
+- **Git and DB inline** (full policies in [`../CODE-POLICIES.md`](../CODE-POLICIES.md)): before editing, verify each source's expected branch (`aw check-branch`); **proposed** commit (approve first) — never `push`/`--amend`/`--no-verify`. The AI **never executes DML/DDL**: migrations are drafted into the session's `SCRIPTS.sql`; fixture/ephemeral checks are local proof and any remote read is research context, never closure.
 - **One session. One commit** proposed at the end (only if there were code changes), **after the proportional closing review gate** ([`../CODE-POLICIES.md`](../CODE-POLICIES.md) § *Closing review gate*): diff re-read + ambient conventions; fix or defer; nothing reaches the commit unreviewed.
 - **Entry SIZE GATE** (before creating the session): a quick that should have been a spec costs more than the ceremony it saved, so the size of the objective is judged **before** anything exists. Your part is recognizing the signals; the threshold, the question and its options are the CLI's. A signal already resolved by *adopted context* is **not** a signal (chassis § *Adopted context*). A **resume** of an existing quick never re-fires it.
   - **`Recortar alcance`**, if chosen: propose the **sub-task that DOES fit** a quick (`SESSION.Objective` = the sub-task; the original prompt goes into `## Origin`) and defer the rest to `BACKLOG` ("trimmed at the gate — may warrant its own spec, `/w:spec-new`").
@@ -81,7 +81,7 @@ quick-loop(prompt):
   work the task (minimal loop):
     if it edits code → verify each source's expected branch (`aw check-branch`); mismatch → pause + resolve
     produce the deliverable: edit code (minimal change) OR author the analysis/design
-    if read-only DB query → SCRIPTS.sql + execute read-only
+    if fixture/ephemeral DB check → run it from the checkout + capture its proof
     if DB change (DDL/DML) → SCRIPTS.sql (session artifact, DO NOT execute)
     if non-obvious decision → DECISION
     if doubt/gap → inline research, a probe OR structured-choice   # chassis § Proof of concept

package/skills/w/loops/spec-refine-loop/LOOP.md

@@ -70,6 +70,9 @@ The **UI unspecified** gap (when the requirement involves UI; see *Gap taxonomy*
 
 > **Two levels of the same capability:** a compact SPEC may already close its exact roots at `handoff`; otherwise SPEC keeps an `outline` reference and PLAN promotes exactly the closure it implements. A valid handoff is reused, never re-authored. One package, two questions — never two formats.
 
+> **Compound publication:** a new baseline carries this final spec as `consumer_document`
+> (path + base digest); package, manifest and spec publish or roll back together.
+
 Other transversal capabilities the engine always uses: `research` (**inline** — chassis § *Research*), `sql` (DB rule inside research — chassis). All resolved by config; `off` → the loop continues without the capability and, if it was needed, says so or asks. The spec's **prose** follows the **ambient** writing conventions (the host auto-applies an installed writing skill if present), not a composed role.
 
 > **Ambient conventions (not roles):** code/testing/writing standards and `creating-tools` are standalone skills the host auto-discovers by `description` — Workline neither binds nor depends on them. Full doctrine: [../../roles/README.md](../../roles/README.md).
@@ -224,6 +227,7 @@ finalize:
   - every **blocking** functional decision is resolved, and every remaining question carries its destination;
   - **Minimality** — no gold-plating: every criterion and scope item earns its place (chassis § *Minimality*); speculative scope is cut or deferred, and no technical solution was imposed that the requirement did not ask for;
   - `PLAN` can continue without inventing behavior, scope or product decisions.
+  - its gate evidence is checkout-bounded: local inspection/commands may establish it; a deployed product, host runtime or remote query is context or handoff, never a closing condition.
 - Whatever fails **comes back as a gap**. A question owned by `PLAN` **never** fails the gate: it is recorded with its destination, not closed.
 - Passes → `edit_in_place_with_confirm(spec)` + `status: ready-for-plan` → `finalize`. The stamp only counts once the document really carries it.
 - `Cerrar` → the chassis `finalize` (always persists `CHECKPOINT`; `BACKLOG` **only if** something is deferred — here: close reason + deferred `Open questions`).

package/skills/w/modules/DB-RESEARCH-RULE.md

@@ -2,10 +2,10 @@
 
 Loaded when the run reads or writes a database (signal `db`).
 
-Investigation is otherwise autonomous: the AI investigates inline and reports without asking permission. A database is the one place where it asks first.
+Research is autonomous except for DB choice. A remote read is context, never plan-execution proof.
 
-1. **MCP choice**: if the gap needs DB and there is **>1 candidate MCP with no configured default**, the AI asks which one to use. That question goes through the **same structured-choice** as a **content question** (counts inside the ≤3 + `flow` limit), **before** running queries. A single MCP or a default → no question.
-2. Write the queries **first** into the session's `SCRIPTS.sql`.
-3. Execute them **read-only** via MCP (respect `sql-mutation-guard`: never DML/DDL).
+1. With >1 candidate MCP and no default, ask which one through the content structured-choice (inside the ≤3 + `flow` limit) before querying; otherwise do not ask.
+2. Write queries first in session `SCRIPTS.sql`.
+3. Run them read-only via MCP (`sql-mutation-guard`: never DML/DDL), then record `RemoteContextSnapshot` in `SCRIPTS.sql` plus conclusion/digest in `CONCLUSIONS.md` before plan approval.
 
-> The AI **never executes DML/DDL**. A migration is drafted in the session's `SCRIPTS.sql` and handed off; promoting it to `docs/scripts/` is a separate `export-*`, never a loop.
+> Snapshots have no automatic TTL; refreshing during execution means `/w:plan-refine`. The AI **never executes DML/DDL**. Draft migrations in session `SCRIPTS.sql`; `export-*` promotes them separately as handoff.

package/skills/w/modules/DB-SCRIPTS-ONLY.md

@@ -4,11 +4,10 @@ Loaded when a code-editing run touches the database (signal `db`).
 
 ## DB scripts-only — the AI never executes DML/DDL
 
-Distinguished by **execution**, not by file (see the [`SCRIPTS.sql`](../artifacts/artifacts-core/SCRIPTS.sql) schema):
+Classify by **role**, not file (see [`SCRIPTS.sql`](../artifacts/artifacts-core/SCRIPTS.sql)):
 
-- **Read-only queries** (diagnosis/validation) → `SCRIPTS.sql` (session artifact); the AI **does** execute them read-only via MCP (`sql-mutation-guard`).
-- **DDL/DML migrations** (schema/data changes) → the AI **drafts them in `SCRIPTS.sql`** (session artifact) but **NEVER executes them**.
+- **Read-only remote query** → research context: record query, digest and `RemoteContextSnapshot` before approval.
+- **Fixture/ephemeral DB test** → checkout proof; may validate a phase locally.
+- **DDL/DML migration** → draft in session `SCRIPTS.sql`; **NEVER execute**.
 
-> Mutating SQL **stays in the session**; it is never moved to `docs/`. Its promotion to `docs/scripts/` (forward + rollback) is done by a separate `export-*`, never by the loop.
-
-> **Showing beats asserting here:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document — it asks the session's script back, because no narration tells drafting from running.
+> Migration application is a non-blocking handoff, never a task, validation or exit condition. The plan closes on its local contract/tests; the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document and it verifies the session script, not narration.

package/skills/w/modules/EXEC-DB-POLICY.md

@@ -2,6 +2,6 @@
 
 Loaded when a phase touches the database (signal `db`).
 
-## Delta 3 — DB policy: **the AI never executes DML**
+## Delta 3 — DB policy: **checkout proof, never deployed closure**
 
-Full policy in [`DB-SCRIPTS-ONLY.md`](DB-SCRIPTS-ONLY.md), the `db` module of [`../loops/CODE-POLICIES.md`](../loops/CODE-POLICIES.md). **Inline:** read-only queries → the session's `SCRIPTS.sql`, executed via MCP (`sql-mutation-guard`); DDL/DML migrations → the AI **drafts them in `SCRIPTS.sql` but NEVER executes them** — their promotion to `docs/scripts/` is done by a separate `export-*`, never this loop.
+See [`DB-SCRIPTS-ONLY.md`](DB-SCRIPTS-ONLY.md) and [`../loops/CODE-POLICIES.md`](../loops/CODE-POLICIES.md). Fixture/ephemeral-DB checks in the acquired checkout may close a phase. Do not open remote reads here: they are captured research context. Draft DDL/DML in `SCRIPTS.sql`; applying it is handoff and never blocks `validada` or plan closure.

package/skills/w/modules/PLAN-INPUT.md

@@ -4,25 +4,27 @@ Loaded when the input is not plainly a `ready-for-plan` spec (signal `input`).
 
 ## plan-new — four modes
 
-1. **Ready spec** (`docs/specs/NNN-spec-<slug>.md` whose frontmatter declares `status: ready-for-plan`) → ideal. Proceed straight to the loop.
-2. **Spec not ready** (`status: draft` / `refining`, or no mark at all) → **soft-suggest** running `/w:spec-refine` first, **never a block**. Questions the spec left with destination `PLAN` are this flow's **input**, not a reason to send it back.
-3. **Prompt** (no spec referenced) → propose the SPEC flow; **by default launch `/w:spec-new`** with that prompt and continue the natural flow from there.
-4. **External plan content** — the argument carries an **already-built plan** (host plan mode, hand-written, another agent's) → **adopt it**. Single pass, **NO RESEARCH**: materialize as `docs/plans/PPP-plan-<slug>.md`, normalized to the rich-plan schema with only what the source provides. `## Origin` = "adopted from <source>" + attribution (host · model · date). Then offer `/w:plan-refine` or `/w:plan-exec`. Anti-duplicate: a plan whose `## Origin` matches this objective is resumed, never duplicated. Adoption **never regenerates over** an existing plan-doc.
+1. **Ready spec** (`docs/specs/NNN-spec-<slug>.md`, `status: ready-for-plan`) → proceed.
+2. **Spec not ready** (`draft`, `refining`, or no mark) → **soft-suggest** `/w:spec-refine`, never a block. `PLAN` questions remain input here.
+3. **Prompt** (no spec) → propose and normally launch `/w:spec-new`, then continue.
+4. **External plan** (host, hand-written, another agent) → **adopt once, NO RESEARCH** at `docs/plans/PPP-plan-<slug>.md`. Normalize only supplied material; set `## Origin` to "adopted from <source>" + host/model/date; offer `/w:plan-refine` or `/w:plan-exec`. A matching Origin resumes; never overwrite a plan-doc.
 
 > **Mode 3 vs 4:** a prompt that *describes a wish* → SPEC (mode 3); content that *already is a plan* → adopt (mode 4).
 
-> **What adoption may do once the mode is settled is not this document's call:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document.
+> Adoption is CLI-owned: the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document.
+
+> **Source-bounded:** new/refined plans declare `> Límite de ejecución: checkout`; each phase `> Fuentes:`; each task `_(fuentes: …)_`. `workspace` is reserved; other aliases exist in `AGENTS.md > Fuentes`; task sources are a phase subset. A legacy/manual plan without this form is adopted but **cannot execute**: `/w:plan-refine` adds it.
 
 > **Ready vs not** is read from the spec's frontmatter `status`, never from the filename. **Legacy compat:** a spec with no frontmatter that carries `## Refinement decisions` — or the older `## Q&A traceability` — counts as ready the same way.
 
 ## plan-refine — three modes
 
-1. **Existing plan** (`docs/plans/PPP-plan-<slug>.md`) → proceed, **regardless of provenance**: generated, hand-written, or adopted. Existence is the only requirement.
-2. **No plan** → **soft-suggest** `/w:plan-new` first; the user decides.
-3. **Returned by `plan-exec`** (its entry check found the plan unexecutable, or execution stopped on a structural deviation) → proceed carrying that finding: phases already `validada` stay, only pending work is re-designed.
+1. **Existing plan** (`docs/plans/PPP-plan-<slug>.md`) → proceed regardless of provenance.
+2. **No plan** → soft-suggest `/w:plan-new`; the user decides.
+3. **Returned by `plan-exec`** (unexecutable entry or structural deviation) → retain `validada` phases and redesign only pending work.
 
 > **Spec-less plans are legitimate input.** The coherence gate **degrades gracefully**: criteria trace to the plan's own Final behavior block instead of spec criteria, and the "spec criteria uncovered" gap does not apply.
 
 ## Numbering
 
-The plan is named `docs/plans/PPP-plan-<slug>.md`; `aw next-number docs/plans --claim plan-<slug>.md --code <NNN>` claims it **for its run**; the slug comes from the Requirement. It does **not inherit the spec's `NNN`** — the link is established by reference in `## Origin`, never by number.
+The name is `docs/plans/PPP-plan-<slug>.md`; `aw next-number docs/plans --claim plan-<slug>.md --code <NNN>` claims it for this run. The slug comes from the Requirement. It does not inherit the spec `NNN`: `## Origin` carries that link.