@tacuchi/agent-workflow-cli 20.21.0 → 20.23.0

package/skills/w/commands/persist.md

@@ -1,101 +1,66 @@
 ---
-description: Use when work already produced in this conversation (analysis, conclusions, a plan) should be saved into docs/ — classifies its shape and routes it. analysis → docs/research/ · requirement → spec draft (docs/specs) · plan → plan adoption (docs/plans). Transversal (no flow, no loop, no session); records ## Origin + attribution (host · model · date); anti-duplicate aware (update vs sibling perspective). The host→docs/ counterpart of export-*.
+description: Use when work already produced in this conversation (analysis, conclusions, a plan) should be saved into docs/ — classifies its shape and routes it. analysis → docs/research/ · requirement → spec draft (docs/specs) · plan → plan adoption (docs/plans). Backed by `aw persist`, which owns the inventory, the anti-duplicate check, the numbering, the destination and the write. Transversal (no flow, no loop, no session); records ## Origin + attribution.
 argument-hint: [what to persist — empty = the conversation's latest finished deliverable]
 allowed-tools:
   [
     "Bash",
     "Read",
-    "Write",
-    "Edit",
   ]
 ---
 
 # persist — persist in-conversation work into `docs/`
 
-Captures **work already produced in this conversation** — with or without host-native features (a `/goal` run, plan mode, plain chat analysis) — and persists it into `docs/`, classified by shape. It is the explicit form of *direct no-flow authoring* (`../SKILL.md` § *Operating context*, row 3) and the doctrinal entry for **host as producer** (`../loops/CHASSIS.md` § *Adopted context*).
+Captures **work already produced in this conversation** — with or without host-native features (a `/goal` run, plan mode, plain chat analysis) — and persists it into `docs/`, classified by shape. The explicit form of *direct no-flow authoring* (`../SKILL.md` § *Operating context*, row 3) and the doctrinal entry for **host as producer** (`../loops/CHASSIS.md` § *Adopted context*). The host→`docs/` counterpart of `export-*`.
 
 > **Hard floor — applies even if you read nothing beyond this file:**
 >
 > 1. **Adopt, don't re-derive** — single pass, **NO RESEARCH**: transcribe/organize what the conversation already established. New investigation is flow work (`spec-refine`, `quick`), never this command's.
-> 2. **Confirm before writing** — classification and destination go through **structured-choice** (recommendation first). Never write `docs/` silently.
-> 3. **Numbering via `aw next-number docs/<category>`** (it creates the folder when missing) — never invent numbers. **Never creates sessions** (sessions are loop-created only).
-> 4. **Language** — headings in English (parse contract); content in the **user's language**.
+> 2. **You classify and write; the CLI decides everything else** — inventory, anti-duplicate, numbering, destination, authorization and the write itself belong to `aw persist`. Never write into `docs/` with a file tool here; `Write`/`Edit` are deliberately not in `allowed-tools`.
+> 3. **Never invent the number** — the `NNN` you put in the path is consultative; `apply` reassigns it inside the lock. Do not renumber it.
+> 4. **Confirm before writing** — classification and destination go through **structured-choice**; `apply` refuses without the digest `validate` returned. **Never creates sessions** (sessions are loop-created only).
+> 5. **Language** — headings in English (parse contract); content in the **user's language**.
 
 ## Input
 
-`$ARGUMENTS` names what to persist (or is empty → the conversation's most recent finished deliverable). The **source is the conversation itself**: what was analyzed, concluded, designed or planned up to this point. If nothing persistable exists yet, say so and stop — do not manufacture content.
+`$ARGUMENTS` names what to persist (or is empty → the conversation's most recent finished deliverable). The **source is the conversation itself**. If nothing persistable exists yet, say so and stop — do not manufacture content.
 
-## Classification → routing
-
-Classify the content by **shape**, recommend the route, confirm via structured-choice:
-
-| Shape | Signals | Route |
-|---|---|---|
-| **Analysis / conclusions / design notes** | findings, comparisons, diagnoses, adjudications, recommendations | `docs/research/NNN-research-<slug>.md` (schema below) |
-| **Requirement** | describes a *wish*: what should exist/change, acceptance criteria derivable | **spec draft** via the [`spec-new`](spec-new.md) procedure (same schema, same NO RESEARCH), `## Origin` = "adopted from host conversation" → offer `/w:spec-refine` |
-| **Plan** | already answers the *how*: phases/tasks/solution — e.g. the host plan-mode output | **plan adoption** via [`plan-new`](plan-new.md) § *Input resolution* mode 4 (`docs/plans/PPP-plan-<slug>.md`) → offer `/w:plan-refine` / `/w:plan-exec` |
-| Mixed / ambiguous | e.g. analysis that ends in a requirement | structured-choice between the candidate routes (split is a valid option: research doc + spec draft referencing it) |
-
-Requires a **workspace** (`docs/` is the managed surface). Without one → degrade: propose `/w:workspace-init` or ask for an explicit destination path.
-
-## `docs/research/` — the analysis home (owned by this command)
-
-`docs/research` hosts standalone analyses: neither spec nor plan, but worth keeping. Written by this command (or by direct no-flow authoring following this same schema). Belongs to **no flow**; `export-*` never writes it; loops never read it implicitly (a flow uses it by **reference** — e.g. cited in a spec's `## Origin` or a quick prompt).
-
-```markdown
-# Research NNN — <slug>
-
-## Origin
-adopted from host conversation — <host> · <model> · <YYYY-MM-DD>
-(what prompted the analysis: goal, prior doc, question)
+## Run
 
-## Objective
-The question/situation the analysis addresses. In the user's language.
+1. `aw persist prepare --format human` (`--detail` prints the full response contract). Returns the inventory of the three categories, the consultative numbering, the allowed destinations, the limits and an `input_digest`.
+2. **Classify and write.** Compose one JSON answer:
+   - `version`, `operation`, `input_digest` copied **verbatim** from the request;
+   - `state`: `proposed`, or `ambiguous` when the inventory already holds this work (explain in `reason` — the CLI turns that into a question, never a write);
+   - `decisions`: `{ category, slug, mode }`, plus `target` + `target_digest` when `mode` is `update`;
+   - `artifacts`: exactly one `{ path, content }`.
+3. `echo '<json>' | aw persist validate --format human` → preview + `approval_digest`.
+4. **Confirm classification and destination** with the user via structured-choice, showing that preview.
+5. `echo '<json>' | aw persist apply --approval <digest> --format human`.
 
-## Analysis
-The analysis, transcribed/organized (not re-derived).
+Every rejection names its cause and one valid next action; nothing was written. Fix the answer and repeat from step 3.
 
-## Conclusions
-The settled conclusions — actionable, falsifiable where possible.
-
-## Perspectives        (opt. — multi-agent)
-### <host · model · YYYY-MM-DD>
-An additional agent's view on the same objective (see below).
-
-## Sources             (opt.)
-Docs / repos / prior research docs referenced (for a synthesis: the N crossed docs).
-
-## Open questions      (opt.)
-```
-
-## Anti-duplicate → update vs sibling perspective
-
-Before writing, scan `docs/research/*-research-*.md` for a doc whose `## Origin`/`## Objective` matches this objective. If one exists, **never** silently create a second: structured-choice —
-
-- **`Actualizar`** *(recommended when it is the same line of thought)* — correct/extend the existing doc in place (confirmation to overwrite).
-- **`Agregar perspectiva`** — append a `### <host · model · date>` subsection under `## Perspectives`: same objective, **different agent's view** (this is intentional and legitimate — the multi-host pattern below).
-- **`Documento nuevo`** — only if the objective genuinely differs.
+## Classification → routing
 
-## Multi-host cross-analysis (the docs-mediated pattern)
+| Shape | Signals | Category → destination |
+|---|---|---|
+| **Analysis / conclusions / design notes** | findings, comparisons, diagnoses, adjudications, recommendations | `research` → `docs/research/NNN-research-<slug>.md` |
+| **Requirement** | describes a *wish*: what should exist/change, acceptance criteria derivable | `spec` → `docs/specs/NNN-spec-<slug>.md`, born `status: draft`, `## Origin` = "adopted from host conversation" → offer `/w:spec-refine` |
+| **Plan** | already answers the *how*: phases/tasks/solution — e.g. the host plan-mode output | `plan` → `docs/plans/NNN-plan-<slug>.md` (adoption, [`plan-new`](plan-new.md) § *Input resolution* mode 4) → offer `/w:plan-refine` / `/w:plan-exec` |
+| Mixed / ambiguous | e.g. analysis that ends in a requirement | one `persist` per document, each confirmed; a research doc plus a spec draft that cites it is a valid split |
 
-`docs/research` is git-shareable — unlike sessions (gitignored, machine-local, loop-owned). That makes it the exchange surface for **N agents analyzing the same situation**:
+Requires a **workspace** (`docs/` is the managed surface). Without one → degrade: propose `/w:workspace-init`.
 
-1. **Each host** analyzes in-conversation, then runs `/w:persist` → first agent creates the research doc; the rest **add perspectives** (or sibling docs), always attributed (host · model · date).
-2. **The final cross**: the user picks the strongest host; its input is the N research docs/perspectives (referenced explicitly in the prompt or via this command's argument). The synthesis persists as a **new research doc** whose `## Origin` states "synthesis" and whose `## Sources` lists every doc/perspective crossed — attribution lets it weigh who concluded what.
-3. Sessions stay **out** of the exchange path — no concurrent-session doctrine is needed; hosts meet only in `docs/`.
+## `docs/research/` — the analysis home (owned by this command)
 
-## What this command is NOT
+`docs/research` hosts standalone analyses: neither spec nor plan, but worth keeping. Belongs to **no flow**; `export-*` never writes it; loops never read it implicitly (a flow uses it by **reference** — cited in a spec's `## Origin` or a quick prompt). It is git-shareable, unlike sessions (gitignored, machine-local, loop-owned), which makes it the exchange surface for **N agents analyzing the same situation**.
 
-- **Not export-*** — it never reads sessions; `export-*` remains the only session→`docs/` path.
-- **Not a flow** — no loop, no session, no `CHECKPOINT`; single pass.
-- **Not research** — it investigates nothing (NO RESEARCH); it persists what already exists.
+> **Anti-duplicate is a decision, not an accident.** The inventory carries each existing document's summary and digest. Same work already there → `mode: "update"` (proving you saw the current bytes via `target_digest`) or `state: "ambiguous"` so the user chooses between updating and writing a sibling perspective. A second near-identical document is never created silently.
 
 ## Plan mode
 
-Classifies the content, resolves `NNN`/destination (`aw next-number --dry-run`) and describes the doc it would write (or the update/perspective it would append) without writing anything.
+Describe the classification, the destination and the document it would write. Running `prepare` is fine (read-only); never `apply`.
 
 ## Resources
 
-- Adopted-context doctrine: `../loops/CHASSIS.md` § *Adopted context* · `../SKILL.md` § *Host as producer*
-- Spec-draft procedure: [`spec-new.md`](spec-new.md) · Plan adoption: [`plan-new.md`](plan-new.md) § *Input resolution* (mode 4)
-- Session→docs counterpart: [`../exports/README.md`](../exports/README.md)
+- CLI: `aw persist prepare | validate | apply` (service `persist-service` over `semantic-operation/`)
+- Siblings: the four `export-*` commands (session → `docs/`), same handshake
+- Design reference: `docs/referencias/workflow-skills/persist.md`

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

@@ -45,7 +45,7 @@ The skill evaluates `$ARGUMENTS` (specs live in place — `docs/specs/NNN-spec-<
 
 ## Phases are functional states
 
-The plan is born with `### Fn` phases that each leave a **verifiable state of the system** — each with its `> Estado:` line, its primary evidence and its exit condition — never a list of files, classes or layers. Contract: `../loops/plan-new-loop/LOOP.md` § *Phase contract (canonical)*.
+The plan is born with `### Fn` phases that each leave a **verifiable state of the system** — each with its `> Estado:` line, its primary evidence and its exit condition — never a list of files, classes or layers. The blocks beyond those are **conditional**: a phase with no temporary behavior gets no `Límite de simulación`, and one with nothing excluded gets no `Diferido` — a heading is never written empty to satisfy a template. The plan itself is born `> Estado: open` under the title; only `plan-exec` closes it. Contract: `../loops/plan-new-loop/LOOP.md` § *Phase contract (canonical)*.
 
 ## Numbering notes
 

package/skills/w/commands/resume.md

@@ -1,6 +1,6 @@
 ---
-description: Use when the user asks to resume or pick up pending work — a half-done session, a spec to refine, a plan mid-execution, or work with no Workline flow at all. Composes /w:status and proposes how to continue via structured-choice routed to the right command; an artifact argument (spec, plan or session) skips the survey and gets its exact re-entry route. Transversal (not a flow), read-only; never touches docs/ or .workflow/. Backed by aw status + aw resume-summary.
-argument-hint: "[docs/specs/… | docs/plans/… | session NNN]"
+description: Use when the user asks to resume or pick up pending work — a half-done session, a spec to refine, a plan mid-execution. Backed by `aw resume`, which derives the priority, the progress and the exact re-entry command from the Workline index. An artifact argument (spec, plan or session) skips the survey. Transversal (not a flow), read-only; never touches docs/ or .workflow/.
+argument-hint: "[docs/specs/… | docs/plans/… | NNN | --code <session>]"
 allowed-tools:
   [
     "Bash",
@@ -10,60 +10,44 @@ allowed-tools:
 
 # resume — pick up pending work (transversal)
 
-Summarizes what is pending in the workspace and proposes how to continue. Single-pass, **read-only**: no loop, no session, writes nothing in `docs/` or `.workflow/`. **Transversal** command (belongs to no SPEC/PLAN/QUICK flow). The **actionable sibling of `/w:status`**: it composes the `/w:status` summary and adds a proposal layer. With an **argument** (a spec, plan or session) it skips the survey and proposes the exact re-entry route for that artifact (§ *Directed resume*). User-facing output in the user's language.
+Single-pass, **read-only**: no loop, no session, writes nothing in `docs/` or `.workflow/`. **Transversal** command (belongs to no SPEC/PLAN/QUICK flow). The actionable sibling of `/w:status`: same index, but it answers *what to pick up* instead of *what exists*.
 
-> **Not `aw session-resume` / `aw resume-summary` / `create_or_resume`.** Those are internal session mechanics (reopen a session, the PostCompact payload, loop resume). `/w:resume` is the **user-facing** command that *summarizes + proposes*; it never runs the pending work — it routes to the command that does.
+> **Not `aw session-resume` / `aw resume-summary`.** Those are internal session mechanics (reopen a session; the PostCompact payload). `aw resume` is the user-facing command.
 
 > **Hard floor — applies even if you read nothing beyond this file:**
 >
-> 1. **Read-only** — never execute the pending work and never write `docs/` or `.workflow/`, **with or without an argument**. Routing means handing off to the target command; the user drives it.
-> 2. **Summary always, question only when pending** — without an argument, show the prioritized summary every time and ask **only** when there is at least one pending item; with an argument, the directed route (§ *Directed resume*) replaces the survey.
-> 3. **Ask via structured-choice** — the proposal is a structured-choice with the top ≤3 concrete options, recommendation first. Never route silently.
-> 4. **Language** — headings in English (parse contract); user-facing output in the **user's language**.
-
-## Directed resume (optional argument)
-
-`$ARGUMENTS` may name an artifact: a spec (`docs/specs/NNN-spec-<slug>.md`), a plan (`docs/plans/PPP-plan-<slug>.md`) or a session (`NNN` code or `NNN-<slug>-<flow>` folder). Empty → the survey flow below (`## Run`). With an argument:
-
-1. **Derive the slug** from the artifact name (session code `NNN` → resolve the folder via `aw sessions --state all`).
-2. **Locate the candidate sessions**: `aw sessions --state all` (and `aw resume-summary --include-recent-closed` for checkpoint detail) filtered by that slug.
-3. **Confirm by `## Origin`**: read the candidates' `SESSION.md` — the `## Origin` names the spec/plan the session came from; it, not the slug match, decides the association.
-4. **Propose the exact route** via structured-choice, per the `## Routing` table with the artifact's path filled in (`Retomar` recommended, `Descartar`/`Cerrar` secondary). No candidate session and no clear stage → say so and fall back to the survey flow.
-
-Same hard floor: this mode **proposes** the route — it never starts the target command itself.
+> 1. **Read-only** — never execute the proposed route, with or without an argument. The CLI hands back a command string; the user drives it.
+> 2. **Never re-decide** — priority, ties, the spec→plan relation and the exact command come from the CLI. Do not re-sort by date, do not associate a session to a plan by slug, do not pick a winner the CLI left tied.
+> 3. **Ask via structured-choice** when the CLI returns candidates, never otherwise.
+> 4. **Language** — user-facing output in the **user's language**.
 
 ## Run
 
-1. **Workline level — compose `/w:status`.** Read-and-follow [`status.md`](status.md) to produce the prioritized summary (it already renders `aw status` and, when available, the host-context section). Do **not** re-implement the summary. For deeper session detail, `aw resume-summary [--include-recent-closed]` gives the primary session's CHECKPOINT state, and `aw session-resume --code <NNN>` the full checkpoint of any other active or closed session.
-2. **Interpret the stage marks.** Map each signal to its stage: the spec's `status` (`draft`/`refining` = SPEC work still open · `ready-for-plan` = it can go to PLAN) + `open_questions`; plan progress on **both axes** — checkboxes (`tasks_done` / `tasks_total`) and validated phases (`phases_validated` / `phases_total`); session `checkpoint_present`. A `status` that is absent, empty or unknown reads `draft`: that work stays in SPEC and never routes to PLAN on an unreadable mark. Associate a session to its plan or spec by **slug** — there is no linkage field in the `aw status` output, so infer it from `folder` / `slug`; when precision matters, confirm by the session's `## Origin` (§ *Directed resume*).
-3. **Build the prioritized pending list** — fixed order: **session with CHECKPOINT > plan half-done > spec not ready > host context**.
-4. **Host level (second source).** If the workline level does not explain the pending work (or no Workline flow was used), rely on the host-context already surfaced by `/w:status`; escalate it to a proposal and, only if needed, use the host-memory *deep* tier or ask the user (universal fallback: git / `docs/` signals + a question). See [`../harness/HARNESS.md`](../harness/HARNESS.md) § *host-memory*.
-5. **Propose (only when ≥1 pending).** One structured-choice with the top ≤3 options by the priority order; each option **routes** to its command (table below). Every proposal carries `Retomar` (recommended) and `Descartar` / `Cerrar` (secondary).
-6. **Nothing pending.** Show the `/w:status` summary and state clearly that there is nothing pending — **do not ask**.
-
-## Routing (stage → command)
-
-Priority: **session+CHECKPOINT > plan half-done > spec not ready > host context**.
+1. Run `aw resume --format human`, forwarding the argument when there is one:
+   - a doc path or number → pass it as the positional (`aw resume docs/plans/009-plan-x.md`);
+   - a session → `aw resume --code <NNN | folder>`;
+   - nothing → no argument, and the CLI walks the pipeline.
+2. **Relay the output verbatim.** It already carries the objective, the progress or checkpoint, the next pending step or blocker, and the exact command.
+3. **When the CLI returns candidates**, present them as a structured-choice, one option per candidate, in the order given — the CLI declares a tie precisely because there is no correct automatic winner. Add the `flow` control. Never break the tie yourself.
+4. **When it returns nothing pending**, say so and stop. Do not ask.
+5. **Host context (optional).** If nothing is pending at the Workline level and the host exposes cheap host-memory ([`../harness/HARNESS.md`](../harness/HARNESS.md) § *host-memory*), you may add a short note about recent focus. Never expensive, never blocking.
 
-> **Every box ticked is not a finished plan.** A plan with `phases_validated` below `phases_total` still has functional state to reach — work implemented, not validated — so it counts as half-done and routes to `/w:plan-exec`, which re-enters at the first phase that is not `validada`. A phase left `bloqueada` routes the same way: `/w:plan-exec` re-enters **through it** to run the validation still pending, and the plan stays open until that phase reads `validada`. A plan with `phases_total: 0` is a legacy plan (no phase marks) and is judged by its checkboxes alone.
+## What the CLI decides (do not re-derive)
 
-| Pending detected | `Retomar` (recommended) | Secondary |
-|---|---|---|
-| spec not ready (`draft` / `refining`, or a `status` absent or unreadable) | `/w:spec-refine` | `Descartar` |
-| spec `ready-for-plan`, no plan | `/w:plan-new` | `Descartar` |
-| plan half-done — open checkboxes **or** phases not `validada` | `/w:plan-exec` | `Cerrar` |
-| active session with CHECKPOINT | continue / reopen (`aw session-resume --reopen`) | `Cerrar` |
-| host context only (no workline) | best next step for what was found | `Descartar` |
+- **Priority**: spec sin refinar → spec `ready-for-plan` sin plan → plan incompleto → checkpoint no asociado. Within plans, one already started outranks an untouched one.
+- **Ties**: same priority and same progress → candidates. Date and age never break a tie.
+- **The spec→plan relation**: proven by the plan's `Derived from` header, an explicit spec path in its `## Origin`, or an unambiguous `Spec NNN` there — never by slug. A plan whose provenance is unproven leaves its spec visible as still unplanned.
+- **The route**: `/w:spec-refine`, `/w:plan-new`, `/w:plan-exec`, or `aw session-resume --reopen`, with the path already filled in.
 
-Reuses the continuity rule of [`../SKILL.md`](../SKILL.md) § *Operating context* — it synthesizes the route from the `/w:status` summary + that rule; it does not re-implement it.
+> A plan is not finished because its boxes are ticked. `aw resume` re-enters at the first phase that is not `validada`, reports a `bloqueada` phase with its declared reason, and, when everything is green but the plan never closed, says the final validation is what remains. A plan that declares `done` over open work comes back as inconsistent — repair before implementing.
 
 ## Plan mode
 
-Read-only already: compose `/w:status`, describe the prioritized summary and the proposal it would offer (top ≤3 routed options; with an argument, the exact route it would propose), without asking or writing.
+Read-only already: run `aw resume --format human` and describe the proposal (and the choice it would offer), without asking or writing.
 
 ## Resources
 
-- Composes: [`status.md`](status.md) (the summary) · Capability: `host-memory` ([`../harness/HARNESS.md`](../harness/HARNESS.md))
-- CLI: `aw status` · `aw resume-summary [--include-recent-closed]` · `aw session-resume --code <NNN> [--reopen]`
+- CLI: `aw resume` (service `resume-service` over `workline-index-service`) · sibling `aw status`
+- Session mechanics: `aw session-resume --code <NNN> [--reopen]` · `aw resume-summary`
 - Continuity rule: [`../SKILL.md`](../SKILL.md) § *Operating context*
 - Design reference: `docs/referencias/workflow-skills/resume.md`

package/skills/w/commands/spec-refine.md

@@ -21,6 +21,18 @@ This command does not refine the spec itself: it delegates to `spec-refine-loop`
 > 3. **Write boundary** — this flow edits only `docs/specs/…` (in place, with confirmation), stamping the spec's frontmatter `status: ready-for-plan` on save; nothing else lands in `docs/`.
 > 4. **Language** — everything user-facing (questions, option labels, the doc's content) goes in the **user's language**.
 > 5. **Converge, do not close everything** — the target is `ready-for-plan`, not a spec without unknowns: close what can change **what** gets built; hand architecture and implementation questions to `PLAN`, recorded in `## Open questions` with their destination.
+> 6. **Shape before gaps** — if the investigation shows the spec must be **split** or **replaced**, ask and resolve that **before** the gap questions, in its own question, and record the answer in `CHECKPOINT`. Never mix it into the gap batch.
+
+## The two shape branches are not the same question
+
+The loop's *change-shape gate* can find that one spec is the wrong container. `split` and `replace` are different findings, so they ask different things and do different things — reusing one for the other asks about cardinality when what changed was purpose:
+
+| Finding | What it asks | What it writes |
+|---|---|---|
+| **`split`** — independent functional outcomes discovered | `Dividir en varias specs` \| `Una sola spec` | the original, rewritten reduced, **plus** one new file per extracted outcome |
+| **`replace`** — the purpose itself changed | `Crear una nueva spec` \| `Reformular esta spec` | `Crear` → one **new** file, this spec untouched · `Reformular` → **no new file**: this same file, same number, same path |
+
+Both branches keep the `Cerrar` control, which closes the run **without applying the change**. No file — new or overwritten — is written without confirmation.
 
 ## Run the loop
 

package/skills/w/commands/status.md

@@ -1,6 +1,6 @@
 ---
-description: Use when the user asks "what's the state", "what got done", or "where are we". Read-only workspace dashboard — what got done / what is missing / what was discarded, with dates humanized in the user's language, optionally enriched with host context when the host exposes cheap memory. Backed by `aw status`. Transversal command (not a flow); writes nothing.
-argument-hint: (no arguments)
+description: Use when the user asks "what's the state", "what got done", or "where are we". Read-only workspace dashboard — the pending pipeline by default, the full history under detail — optionally enriched with host context when the host exposes cheap memory. Backed by `aw status`. Transversal command (not a flow); writes nothing.
+argument-hint: (no arguments — pass `detalle` for the full inventory)
 allowed-tools:
   [
     "Bash",
@@ -10,55 +10,27 @@ allowed-tools:
 
 # status — workspace state (read-only)
 
-Shows, simple and direct, the workspace state grouped as **Done / Missing / Discarded**. Single-pass, read-only: no loop, no sessions, writes nothing in `docs/` or `.workflow/`. **Transversal** command (belongs to no flow). When the host exposes cheap memory it *opportunistically* adds a host-context section — additive, never blocking, never asked.
+Single-pass, read-only: no loop, no sessions, writes nothing in `docs/` or `.workflow/`. **Transversal** command (belongs to no flow).
 
 ## Run
 
-1. Run `aw status` (returns JSON; backed by `status-service`).
-2. Render a readable summary from the JSON — do **not** show the raw JSON. Use the `relative` field verbatim (it comes pre-humanized in the user's language — Spanish). Head it with `workspace.name`.
-3. Group into three blocks (the dashboard is user-facing → render it in the user's language; the canonical Spanish labels below):
-   - `▸ HECHO` — specs whose `status` is `ready-for-plan` (the JSON keeps `refined: true` as its boolean mirror); plans with their progress (`tasks_done`/`tasks_total`, `progress_pct`) **and** their validated phases (`phases_validated`/`phases_total`); `closed` sessions.
-   - `▸ FALTA` — `active` sessions; plans with pending tasks (`tasks_total − tasks_done`) or phases still to validate (`phases_total − phases_validated`); specs whose `status` is `draft` or `refining`; specs with `open_questions > 0`.
-   - `▸ DESCARTÓ` — every item in `discarded[]` (`kind: deferred` = deferred in BACKLOG; `kind: excluded` = excluded in CHECKPOINT), with its `text`.
-4. Every line ends with its relative date after ` · ` (e.g. `· ayer en la mañana`). An empty section shows `— (nada)`. Never invent data not present in the JSON.
-5. If `workspace.initialized` is `false` and everything is empty → say the folder is not an agent-workflow workspace (no `.workflow/`) and suggest `/w:workspace-init`.
-6. **Host context (opportunistic, read-only).** After the dashboard, if the host exposes *cheap* host-memory (see [`../harness/HARNESS.md`](../harness/HARNESS.md) § *host-memory* — e.g. the auto-memory `MEMORY.md` on Claude Code), append a `▸ CONTEXTO DEL HOST` section with a few signals of recent focus relevant to this workspace. If there is no cheap host memory, **omit the section silently**. Never run an expensive transcript scan here and **never ask** — this is a read-only dashboard; the enrichment is additive and must not slow the default output.
+1. Run `aw status --format human` — add `--detail` when the user asked for the full inventory ("detalle", "todo", "historial").
+2. **Relay its output verbatim.** The CLI already selects, filters, groups and humanizes the dates; re-rendering it here is what made the two drift apart. Do not paraphrase it, do not re-sort it, do not add or drop a line.
+3. **Host context (opportunistic, read-only).** After the dashboard, if the host exposes *cheap* host-memory (see [`../harness/HARNESS.md`](../harness/HARNESS.md) § *host-memory* — e.g. the auto-memory `MEMORY.md` on Claude Code), append a `▸ CONTEXTO DEL HOST` section with a few signals of recent focus relevant to this workspace. No cheap host memory → **omit the section silently**. Never run an expensive transcript scan and **never ask**.
 
-> **Checkboxes measure work; phases measure state.** `progress_pct` stays checkbox-derived — it never reads the phase marks. A validated phase (`> Estado: validada` in the plan-doc) is the real signal of functional state, so a plan at 100% with `phases_validated: 0` is **work implemented, not validated**: report it in both blocks and say so. A `bloqueada` phase is that same gap made explicit — every box ticked, its verification still pending — and belongs in both blocks too: the work under `▸ HECHO`, the phase under `▸ FALTA` with what it waits on (its `> Bloqueo:` line). `phases_total: 0` means a legacy plan with no phase marks — show only its checkbox progress, never a `0/0`.
+> **The default view is what is LEFT TO DO** — unrefined specs, refined specs with no plan, plans not `done`. Finished history, sessions and discarded items are still in the model; `--detail` brings them back. If the user asks about something the default hides, re-run with `--detail` instead of explaining its absence.
 
-> **The frontmatter governs spec maturity.** The spec's `status` (`draft` | `refining` | `ready-for-plan`) is the primary source, and readiness is never inferred from a section the spec happens to carry. A `status` that is absent, empty or unknown reads `draft` and the spec is reported as pending; only a spec with **no frontmatter at all** falls back to the two legacy marks (`## Refinement decisions`, `## Q&A traceability`).
+> **Automation reads JSON.** Through a pipe, and with `--json` or `--format json`, `aw status` emits the same machine-readable envelope it always has. `--detail` belongs to the human projection only.
 
-Suggested format (plain text; user-facing labels in Spanish):
-
-```
-Workspace: <name>
-
-▸ HECHO
-  • plan <slug> — <done>/<total> tareas (<pct>%) · <validadas>/<fases> fases validadas · <relative>
-  • spec <slug> — lista para plan · <relative>
-  • <folder> (<type>) — cerrada · <relative>
-
-▸ FALTA
-  • <folder> (<type>) — activa · <relative>
-  • plan <slug> — <pendientes> tareas pendientes · <sin validar> fases sin validar
-  • spec <slug> — borrador · <relative>
-  • spec <slug> — <n> preguntas abiertas
-
-▸ DESCARTÓ
-  • <text> (<kind>) · <relative>
-
-▸ CONTEXTO DEL HOST   (solo si hay memoria barata; se omite si no)
-  • <foco reciente / hilo relevante>
-```
+Uninitialized workspace (`initialized: false`, everything empty) → say the folder is not an agent-workflow workspace and suggest `/w:workspace-init`.
 
 ## Plan mode
 
-Same as execution: run `aw status` (read-only) and show the summary. There are no changes to apply.
+Same as execution: `aw status --format human` is read-only. There are no changes to apply.
 
 ## Resources
 
-- CLI: `aw status` (service `status-service`; dates via `humanize-es`)
+- CLI: `aw status` (index `workline-index-service`, projection `status-service`; dates via `humanize-es`)
+- Sibling: `aw resume` — what to pick up next, from the same index
 - Capability: `host-memory` ([`../harness/HARNESS.md`](../harness/HARNESS.md)) — cheap tier only, opportunistic, silent-omit, never asks
 - Design reference: `docs/referencias/workflow-skills/status.md`
-
-> **Note:** the host-context section is an opportunistic addendum — originally `/status` was a pure `aw status` dashboard. It composes the `host-memory` capability and is purely additive (the fast dashboard is unchanged).

package/skills/w/commands/workspace-init.md

@@ -5,8 +5,6 @@ allowed-tools:
   [
     "Bash",
     "Read",
-    "Write",
-    "Edit",
   ]
 ---
 
@@ -15,9 +13,11 @@ allowed-tools:
 Runs `aw workspace-init` to turn the current folder into a Workline workspace. A workspace has **1+ sources** (repos); "standalone" = a single source. There are no project/hub modes — the model is unified.
 
 ```bash
-aw workspace-init --source alias:path[:branch] [--proyecto <name>] [--main-branch <branch>] [--dry-run]
+aw workspace-init --source alias:path[:branch] [--proyecto <name>] [--main-branch <branch>] [--dry-run] --format human
 ```
 
+> **The CLI writes; this wrapper does not.** Every file below is created by `aw workspace-init` — `Write` and `Edit` are deliberately absent from `allowed-tools`. Use `--dry-run` to show the user what would land, then re-run without it. Relay the CLI's output instead of re-rendering it.
+
 ## Interactive steps
 
 1. **Detect/confirm sources** — the CLI detects the repo path(s); the user confirms aliases, paths and branches. Multiple `--source` accepted.

package/skills/w/hooks/README.md

@@ -11,8 +11,27 @@
 | `PreToolUse` (`execute_sql`) | `hook sql-mutation-guard` | Blocks DML/DDL over MCP — reads only (DB scripts-only invariant). |
 | `PreToolUse` (Bash) | `hook git-commit-advisor` | **Advisory (does not block)**: warns if a `git commit` message lacks the active session's `sessionNNN` tag (traceability). Does **not** inspect `push`/`--amend`/`--no-verify`. |
 | `SessionEnd` | `auto-compact-on-close` | Writes `CHECKPOINT.md` on close — the resume key (*CHECKPOINT always* — chassis § Convergence / exit). |
-| `PreCompact` | `checkpoint-write` | Writes `CHECKPOINT.md` before the host compacts. |
-| `PostCompact` | `resume-summary` | Recovers the active loop state after a compact. |
+| `PreCompact` | `checkpoint-write --can-pause` | Writes `CHECKPOINT.md` before the host compacts. |
+| `PostCompact` | `resume-summary` | Recovers **the conversation's own** loop state after a compact. |
+
+> **Conversation identity (spec 011).** The three lifecycle hooks act on **one**
+> session — the conversation's own — never on "the first active one" and never
+> on all of them. They resolve it with the canonical precedence: explicit
+> `--code` → the conversation's durable association → the sole active session.
+> The identity travels in the hook payload's `session_id` (read from stdin) or
+> in `AW_CONTEXT_ID`; two signals naming different conversations fail with
+> `CONTEXT_ID_CONFLICT` instead of picking one. The association lives in
+> `.workflow/sessions/.bindings.json` keyed by the SHA-256 of that id — the raw
+> value is never persisted.
+>
+> **Ambiguity is a capability question, not a guess.** `--can-pause` declares
+> that *this host* can hold its compaction: Claude Code can, so the template
+> passes it and `checkpoint-write` exits **2** with the candidate list instead of
+> writing to an arbitrary session. A host that cannot pause omits the flag —
+> its native compaction completes, and Workline reports
+> `continuity: "degraded"` with `primary_session: null`, having written nothing.
+> The flag is never inferred: guessing it produces false blocks. Per-host
+> installation and transport belong to spec 010.
 
 > **What they enforce (host-level, blocking):** invariant **#4** (DB scripts-only) via `sql-mutation-guard` (blocks DML/DDL over MCP), and the *expected-branch* clause of **#5** via `branch-check` (blocks edits on the wrong branch). The rest of git-safe (`push`/`--amend`/`--no-verify`/`--force`) is **doctrinal** — `git-commit-advisor` only **warns**, it does not block; a host may add its own deny hook if it wants hard enforcement.
 >

package/skills/w/hooks/hooks.template.json

@@ -62,7 +62,7 @@
         "hooks": [
           {
             "type": "command",
-            "command": "agent-workflow checkpoint-write",
+            "command": "agent-workflow checkpoint-write --can-pause",
             "statusMessage": "Escribiendo CHECKPOINT.md antes de compactar...",
             "timeout": 10
           }
@@ -81,7 +81,7 @@
           },
           {
             "type": "prompt",
-            "prompt": "Contexto compactado. El JSON anterior es output de `agent-workflow resume-summary`. Si hay `active_sessions`, reanudá el loop activo desde su CHECKPOINT.md y presentá un resumen. Si está vacío, terminá."
+            "prompt": "Contexto compactado. El JSON anterior es output de `agent-workflow resume-summary`. Si `continuity` es `ok`, reanudá el loop de `primary_session` desde su CHECKPOINT.md y presentá un resumen. Si `continuity` es `degraded`, NO reanudes ninguna sesión: `active_sessions` es un listado, no una identidad — mostrá `candidates` con su `action` y pedí al usuario que elija (después reintentá con `--code <NNN>`). Si no hay sesiones, terminá."
           }
         ]
       }

package/skills/w/loops/README.md

@@ -16,14 +16,16 @@ The 5 loops run the same **common engine**, whose canon lives in [`CHASSIS.md`](
 
 | Loop (`name:`) | Flow | Started by | Reads | Writes |
 |---|---|---|---|---|
-| [`spec-refine-loop`](spec-refine-loop/LOOP.md) | SPEC | `/w:spec-refine` | `docs/specs/NNN-spec*.md` (the spec itself) | `docs/specs/NNN-spec-<slug>.md` (in place) |
-| [`plan-new-loop`](plan-new-loop/LOOP.md) | PLAN | `/w:plan-new` | `docs/specs/NNN-spec-*.md` | `docs/plans/PPP-plan-<slug>.md` |
-| [`plan-refine-loop`](plan-refine-loop/LOOP.md) | PLAN | `/w:plan-refine` *(aux, optional)* | `docs/plans/PPP-plan-*.md` (the plan itself) | `docs/plans/PPP-plan-<slug>.md` (in place) |
+| [`spec-refine-loop`](spec-refine-loop/LOOP.md) | SPEC | `/w:spec-refine` | `docs/specs/NNN-spec*.md` (the spec itself) | `docs/specs/NNN-spec-<slug>.md` (in place) **and, with confirmation, sibling specs** (accepted split) **or one replacement spec** (`Crear una nueva spec`) |
+| [`plan-new-loop`](plan-new-loop/LOOP.md) | PLAN | `/w:plan-new` | `docs/specs/NNN-spec-*.md` | `docs/plans/PPP-plan-<slug>.md`, **or N sibling plans** (accepted split) |
+| [`plan-refine-loop`](plan-refine-loop/LOOP.md) | PLAN | `/w:plan-refine` *(aux, optional)* | `docs/plans/PPP-plan-*.md` (the plan itself) | `docs/plans/PPP-plan-<slug>.md` (in place) **plus the extracted sibling plans** (accepted split) |
 | [`plan-exec-loop`](plan-exec-loop/LOOP.md) | PLAN | `/w:plan-exec` | `docs/plans/PPP-plan-*.md` | `docs/plans/PPP-plan-<slug>.md` (update); the rest via `export-*` |
 | [`quick-loop`](quick-loop/LOOP.md) | QUICK | `/w:quick` | — (prompt) | edits code + light session; **no** `docs/` |
 
 > `/w:spec-new` has no loop (single-pass). Hence **6 commands / 5 loops**.
 
+> **A single run may write several documents.** Splitting, and replacing by a new spec, produce more than one file — always **inside the same flow's folder**, always **after confirmation**, never in another `docs/` zone: the `docs/` boundary below bounds *where* a loop writes, not *how many* files it writes there. `Reformular esta spec` is the counter-case: a replacement that creates nothing and edits the same file in place.
+
 ### `docs/` boundary (hard rule)
 
 Every loop writes **only** its own flow's doc (SPEC→`docs/specs` · PLAN→`docs/plans` · QUICK→none) and **never** graduates other artifacts to `docs/` — that promotion belongs to the separate, explicit `export-*` skills. Canon: [`CHASSIS.md`](CHASSIS.md) § *docs/ boundary*.

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

@@ -66,7 +66,9 @@ Read **[`../CHASSIS.md`](../CHASSIS.md)** — the loop's **full engine** — **a
 Execution **no longer accepts in silence** a plan that would force it to invent its own structure. Two outcomes:
 
 - **Minor gap** — the plan is all but executable: an exit condition derivable from what is already written, the obvious evidence unnamed, micro-tasks to group. `plan-exec` may **normalize it with consent** — one structured-choice content question, labels `Normalizar y ejecutar` (recommended) | `Ir a plan-refine`. Normalizing edits the `### Fn` blocks in place, **adds no scope and moves no boundary**, and is recorded in `DECISION` + `CHECKPOINT`.
-- **Structural gap** — phases, contracts, journey or simulation boundary are missing. It does **not** improvise: record the finding in `CHECKPOINT`, hand off to [`plan-refine-loop`](../plan-refine-loop/LOOP.md) (`/w:plan-refine`) and resume execution over the refined plan.
+- **Structural gap** — phases, contracts or journey are missing, or a change that **does** carry temporary behavior leaves its boundary undeclared. It does **not** improvise: record the finding in `CHECKPOINT`, hand off to [`plan-refine-loop`](../plan-refine-loop/LOOP.md) (`/w:plan-refine`) and resume execution over the refined plan.
+
+> **A missing `Límite de simulación` is a gap only when there is something to simulate.** No task and no phase introduces temporary behavior → the block is legitimately absent and the gate passes; demanding it anyway pushes execution to invent a stub so the plan matches a template. The same holds for `Diferido` and every other conditional block.
 
 > The gate reads the **canonical phase contract** from [`plan-new-loop`](../plan-new-loop/LOOP.md) § *Phase contract (canonical)* — required sections, the `> Estado:` vocabulary, semantic granularity. Execution references it; it never redefines it. The marker is a **line of its own** inside the `### Fn` block (`> Estado: <value>`); written any other way it reads as `pendiente`.
 
@@ -77,7 +79,8 @@ Execution **no longer accepts in silence** a plan that would force it to invent
 - Executes the phase's tasks; **skips** the ones already `- [x]` in the plan (the plan-doc is the per-task source of truth). **Micro steps stay internal** (canonical contract): they reach `CHECKPOINT` only when a resume needs them, never the plan.
 - **Marking order (hard rule):** a task is marked `- [x]` when its local work is finished. A phase reaches `validada` **only** when its primary proof **ran and passed**, the needed focused checks passed, its `Condición de salida` is true, the review gate is green and every remaining review finding is explicitly deferred — 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`.
-- **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, on close, the single plan status 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.
+- **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.
+- **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 phase:** on closing a phase record the **functional state reached**, the simulation boundary in force **only when the change carries one**, the tests run and their result, the non-obvious decisions, the deferrals and the next state being pursued. Enumerating every file touched is not required unless it helps a resume.
 - Records in `DECISION` only the **non-obvious**, **as it is decided** (per-phase decisions accumulate in the SINGLE `DECISION`, tagged by phase/task — e.g. `Origin: T2 (F1)`). A structural deviation is **not** settled with an entry there (§ *Deviation gate*).
 - The chassis **gap-driven** engine applies here **inside a task**: facing a non-obvious decision/doubt → inline research, a probe (Delta 7) OR structured-choice.
@@ -133,8 +136,10 @@ Full gate in [`../CODE-POLICIES.md`](../CODE-POLICIES.md) (§ *Closing review ga
 ## Delta 6 — Completion / close
 
 - A phase closes when its `> Estado:` reads `validada`: work done, `Condición de salida` true, proof **run and passed**. A proof still waiting on an operative handoff leaves it `bloqueada`.
+- **The plan's own state is the third axis, and it stays `open` during the whole run.** Every phase `validada` is **not** the plan closed: the final validation still has to run. Keep `> Estado: open` under the title while executing — stamping it on the first write if the plan carries none — and never write `done` from the counters — a legacy plan with every box ticked is not closed by that fact (§ *Legacy plans degrade safely*).
 - **Every phase `validada` + the final validation passed** → final *structured-choice* (content: `Marcar plan done` / `Preguntar algo más`; flow: `Compactar`/`Cerrar`). `Marcar plan done` is offered under no other condition: one `bloqueada` phase keeps the plan open, however many of its tasks are ticked.
-- **Marking done = ONE line in the plan-doc**, under the title's blockquote: `> Estado: done — YYYY-MM-DD · sesión NNN`, updated in place on a re-run. It never replaces the per-phase lines inside the `### Fn` blocks — position tells the two apart. No per-phase result tables, no ✅ suffixes — that record lives in the session (`DECISION`/`CHECKPOINT`).
+- **Marking done = ONE status line in the plan-doc**, under the title's blockquote: `> Estado: done`, updated in place on a re-run. The machine value **stands alone** — the date and session go on their own `> Cierre: YYYY-MM-DD · sesión NNN` line right under it, for the same reason a blocker never rides on a phase's state line. It never replaces the per-phase lines inside the `### Fn` blocks — position tells the two apart. No per-phase result tables, no ✅ suffixes — that record lives in the session (`DECISION`/`CHECKPOINT`).
+- **Legacy status line, migrated on write.** A plan carrying the old single-line form (`> Estado: done — YYYY-MM-DD · sesión NNN`) is still **read** as closed; the first time this loop legitimately writes that document, it is rewritten to the two-line form. Compatibility is for reading old plans — every new write uses the normalized contract.
 - **No automatic export**: the artifacts (`SCRIPTS.sql`, `DECISION`, …) stay in the session. Promoting them to `docs/` (scripts, manuals, …) is a separate step via `export-*`.
 
 ## Delta 7 — Probe (PoC) tasks
@@ -193,8 +198,8 @@ plan-exec-loop(PPP-plan-<slug>.md):
   final validation (whatever can run; a deferred check keeps its phase bloqueada)
   if every phase validada AND the final validation passed:
     structured_choice(content: [Marcar plan done, Preguntar algo más], flow: [Compactar, Cerrar])
-    mark plan done → ONE status line under the title blockquote (Delta 6), updated in place
-  else: the plan stays open → CHECKPOINT.Next = run the pending validation of the blocked phase(s)
+    mark plan done → > Estado: done + > Cierre: YYYY-MM-DD · sesión NNN under the title (Delta 6), in place
+  else: the plan-level > Estado: stays open → CHECKPOINT.Next = the action that unblocks the phase(s)
   # NO export: artifacts stay in the session; a separate export-* promotes them
 finalize: CHECKPOINT (+ BACKLOG if something is deferred) + close session + report
 ```

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

@@ -55,6 +55,7 @@ The plan absorbs the `TECHNICAL-NOTE` level **inline** (user decision) + the roa
 # Plan PPP — <slug>
 
 > Derived from docs/specs/NNN-spec-<slug>.md · generated by plan-new-loop
+> Estado: open        ← plan-level machine state (open | done); plan-exec closes it
 
 ## Origin              source spec · prompt (bootstrapped via spec-new) · "adopted from <source>" + attribution (external plan — /w:plan-new mode 4 / /w:persist)
 ## Solution            the how (core): 1–2 summary sentences + the AS-IS → TO-BE
@@ -83,6 +84,8 @@ The plan absorbs the `TECHNICAL-NOTE` level **inline** (user decision) + the roa
 
 A `### Fn` block is a **verifiable state of the system**, never a list of layers, files or classes. It answers one question: *what can the system do or demonstrate at the end that it could not at the start?* The contract is defined **once** here — [`plan-refine-loop`](../plan-refine-loop/LOOP.md) and [`plan-exec-loop`](../plan-exec-loop/LOOP.md) reference it and never redefine it.
 
+**Required — every phase, always:**
+
 ```markdown
 ### F1 — <result-oriented name>
 
@@ -90,28 +93,34 @@ A `### Fn` block is a **verifiable state of the system**, never a list of layers
 
 **Resultado:** <the new verifiable state of the system>
 
-**Recorrido afectado:** <consumer → components → current boundary>
-
 **Trabajo:**
 - [ ] T1.1 — <coherent unit of work>
 
-**Límite de simulación:** antes <where it is> → después <where it lands, or removed>
-
 **Validación de fase:** <the primary proof that the promised state was reached>
 
-**Condición de salida:** <falsifiable result · contract preserved · simulation, if any, located or removed>
+**Condición de salida:** <falsifiable result · contract preserved>
+```
 
+**Conditional — added to that block only when its own condition holds:**
+
+```markdown
+**Estado inicial:** <where the phase starts>
+**Recorrido afectado:** <consumer → components → current boundary>
+**Dependencias:** <phase(s) that must land first>
+**Límite de simulación:** antes <where it is> → después <where it lands, or removed>
 **Diferido:** <work consciously reserved for another phase>
 ```
 
-- **Always**: `Resultado` · `Trabajo` · `Validación de fase` · `Condición de salida`.
-- **Conditional**: `Estado inicial` (when it is not obvious) · `Recorrido afectado` (distributed change) · `Límite de simulación` (temporary behavior exists) · `Diferido` · `Dependencias` (the phase cannot run in direct sequence).
+- **Required**: `Resultado` · `Trabajo` · `Validación de fase` · `Condición de salida`, plus the `> Estado:` line.
+- **Conditional**: `Estado inicial` (when it is not obvious) · `Recorrido afectado` (distributed change) · `Dependencias` (the phase cannot run in direct sequence) · `Límite de simulación` (**only** when temporary behavior exists) · `Diferido` (only when work was consciously excluded).
+
+**A new phase never writes an empty conditional block.** No temporary behavior in the change → no `Límite de simulación` line at all; nothing consciously excluded → no `Diferido`. Writing the label with `no aplica` under it is the failure mode this split exists to prevent: it invites inventing a stub to justify the heading, and turns a contract into a form to fill in. The gates check the same way — an absent conditional block is not a gap (§ *Convergence / exit*).
 
 **Phase state = machine state.** One `> Estado: <value>` line directly under the `### Fn` heading; vocabulary `pendiente` | `en ejecución` | `bloqueada` | `validada`, updated **in place**, never duplicated. It is what `aw status` counts (`phases_validated` / `phases_total`), **alongside — not instead of —** the checkbox progress. A phase reaches `validada` only when its work is done, its `Condición de salida` holds, its validation **ran and passed**, and the closing review gate passed. **Never** because all its checkboxes are ticked. *(Legacy plans carry no line at all: `aw status` reports them as zero phases — checkbox progress only. A missing line among stated blocks reads `pendiente`, and nothing is back-filled.)*
 
 **The state line carries its value alone** — no comment, no suffix, no annotation; an annotated value reads as `pendiente`. A blocker's reason lives on its own `> Bloqueo: <reason>` line inside the block, and in `CHECKPOINT`, `## Open questions` and `BACKLOG`.
 
-> Position disambiguates the two marks: the plan-level `> Estado: done — …` line lives under the title (plan-exec § *Delta 6*); the phase-level one lives inside its `### Fn` block.
+**The plan carries its own state, and it is a different axis.** One `> Estado:` line under the title, vocabulary `open` | `done`, born `open` with the plan; `plan-exec` writes `done` only after the final validation, adding a `> Cierre: YYYY-MM-DD · sesión NNN` line for the date and session (§ *Delta 6* there). `aw status` derives `plan_state` from that declaration **and** both counters: a `done` over open tasks or unvalidated phases reads `inconsistent`, and every phase `validada` with no closure reads `final_validation_pending` — still open. Position disambiguates the two marks: the plan-level one lives under the title, the phase-level one inside its `### Fn` block. *(Legacy: `> Estado: done — YYYY-MM-DD · sesión NNN` is still read; the next legitimate write normalizes it.)*
 
 **Granularity is semantic, not mechanical.** A phase earns its place when it leaves a demonstrable state, can be reviewed as a unit, and — when the change carries temporary behavior — moves or retires a simulation. A task is a **coherent unit of purpose** and may touch several files. Naming an edit operation — "create class X", "add method Y", "update the import" — describes a **micro step**: internal to execution, recorded in `CHECKPOINT` when a resume needs it, never a plan entry. `XS–S` stays an orientation of risk and scope; it never mandates splitting a semantic task into mechanical operations.