@tacuchi/agent-workflow-cli 20.22.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/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,65 +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 **all three axes** — checkboxes (`tasks_done` / `tasks_total`), validated phases (`phases_validated` / `phases_total`) and closure (`plan_state`, with `final_validation_pending` and `blocked_phases[]`); 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**.
-
-> **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.
+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.
 
-> **`plan_state` decides whether a plan is resumable at all.** Only `done` is finished; everything else routes back to `/w:plan-exec` with a different re-entry point. `final_validation_pending: true` means the phases are green but the final validation never ran — the plan re-enters **at that validation**, not at a phase. `inconsistent` means the document contradicts itself (`done` declared over open work, or an unreadable value): the re-entry is **repairing the state first**, and the proposal says so instead of pretending there is work to implement.
+## 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 `open` — open checkboxes **or** phases not `validada` | `/w:plan-exec` | `Cerrar` |
-| plan `open` with `final_validation_pending` — everything validated, no closure | `/w:plan-exec`, from the final validation | `Cerrar` |
-| plan `inconsistent` — `done` over open work, or an unreadable value | `/w:plan-exec`, repairing the state first | `Cerrar` |
-| plan `done` | — not resumed automatically | — |
-| 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/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,63 +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 whose `plan_state` is `done`, with their progress (`tasks_done`/`tasks_total`, `progress_pct`) **and** their validated phases (`phases_validated`/`phases_total`); `closed` sessions.
-   - `▸ FALTA` — `active` sessions; plans whose `plan_state` is `open` (pending tasks `tasks_total − tasks_done`, phases still to validate `phases_total − phases_validated`, or a final validation that never ran); plans whose `plan_state` is `inconsistent`, **naming the contradiction**; 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. **Say what blocks a phase.** Every entry of `blocked_phases[]` is rendered with its `number`, its `name` and its `blocker` — `• F3 — Persistencia real — bloqueada: falta aplicar la migración`. A `blocker: null` is a legacy block that stated no reason: render it as `bloqueada` with `motivo no declarado`, never a guess.
-6. 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`.
-7. **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**.
 
-> **Three axes, none of them a substitute for another.** A task completed answers *what work was done* (`tasks_done`/`tasks_total`); a phase validated answers *what functional state was demonstrated* (`phases_validated`/`phases_total`); a plan closed answers *whether the whole solution was validated* (`plan_state`). `progress_pct` stays checkbox-derived — it never reads the phase marks. A plan at 100% with `phases_validated: 0` is **work implemented, not validated**: report it in both blocks and say so. `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.
 
-> **`plan_state` is derived, never declared alone.** `open` (or nothing declared) keeps the plan in `▸ FALTA`, **including** a plan whose every box is ticked and every phase validated: that one carries `final_validation_pending: true` and is reported as `validación final pendiente` — the work is complete, the final validation never ran. `done` reaches `▸ HECHO` only when the counters back the declaration. `inconsistent` means the document declares `done` while tasks or phases stay open, or declares a value nobody can read: it belongs in `▸ FALTA` **with the contradiction named** (`declara done con 2 tareas abiertas`), because only a human repairs it.
+> **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.
 
-> **A blocked phase says what it waits on.** A `bloqueada` phase is the implemented-not-validated gap made explicit — every box ticked, its verification still pending — and belongs in both blocks: the work under `▸ HECHO`, the phase under `▸ FALTA` with its `> Bloqueo:` reason, so the reader knows the next action instead of only the state.
-
-> **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`).
-
-Suggested format (plain text; user-facing labels in Spanish):
-
-```
-Workspace: <name>
-
-▸ HECHO
-  • plan <slug> — cerrado · <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
-  • plan <slug> — validación final pendiente (todo validado, sin cierre)
-  • plan <slug> — inconsistente: declara done con <n> tareas abiertas
-  • F3 — Persistencia real — bloqueada: falta aplicar la migración
-  • 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/roles/git/ROLE.md

@@ -97,14 +97,13 @@ Outside an active session: relax to "1 line + no co-author"; the `session<NNN>`
 
 Autonomous `git merge` is forbidden (above), **but** resolving an **in-progress** merge (MERGE_HEAD), or one invoked by the user via `/w:fix-git`, **is** sanctioned work. **Workspace-agnostic**: it operates on any repo (no `.workflow/`, flows or sessions required).
 
-1. **Detect + identify** with `aw merge-state [<path>|--source <alias>|--all]` (read-only): `is_merging`, `current_branch` (**destination / ours**), `merge_origin` (**origin / theirs**), `conflicted_files`. If `merge_origin` comes empty, check `.git/MERGE_MSG` or `git log --oneline -1 MERGE_HEAD`.
-2. **Analyze each conflict's intent** **before** resolving — never pick a side blindly:
-   - The three versions: `git show :1:<file>` (base) · `:2:<file>` (ours/destination) · `:3:<file>` (theirs/origin).
-   - Each side's why: `git log --merge -p -- <file>`; the hunk's history on each branch.
-   - The code around the marker (coherence with the rest of the file).
-3. **Resolve** by editing the file (remove `<<<<<<<` / `=======` / `>>>>>>>`): pick **ours**, **theirs**, **combine** both intents, or **rewrite** to satisfy both. `git add <file>` what is resolved.
-4. **Ask** (*structured-choice*) when the intent is **ambiguous** or both sides are **incoherent** with each other (not combinable without losing something): one content question per doubtful file/hunk (≤3 + `flow` control), options "Ours (`<destination>`)" / "Theirs (`<origin>`)" / "Combine" / "Edit manually". **Never invent** a resolution under real doubt.
-5. **Proposed commit**: completing the merge is a `git commit` (the merge commit) → **propose-then-execute** like any commit (canonical format above; outside a session → 1 line without the `session<NNN>` tag; never `--no-verify`/`--amend`/`push`). The `git-commit-advisor` hook gates it.
+**The mechanics live in the CLI** (`aw fix-git prepare | apply | commit`); what follows is the reasoning it expects from you. Never edit a conflicted file, `git add` or `git commit` by hand here — see [`../../commands/fix-git.md`](../../commands/fix-git.md) for the exact invocations.
+
+1. **Detect + identify**: `aw fix-git prepare` (read-only) returns the merge direction (**theirs → ours**), the conflicted paths and, per path, its three index stages with their blob hashes. `aw merge-state` remains the lighter inspector when you only need the state.
+2. **Analyze each conflict's intent** **before** resolving — never pick a side blindly. The request already carries the three versions: `base` (common ancestor), `ours` (destination) and `theirs` (origin). Add `git log --merge -p -- <file>` when the *why* of a hunk is not evident, and read the surrounding code for coherence.
+3. **Resolve** by composing the complete resolved file: pick **ours**, **theirs**, **combine** both intents, or **rewrite** to satisfy both — with no `<<<<<<<` / `=======` / `>>>>>>>` left. The CLI writes and stages it; a leftover marker is rejected, and so is a path that is no longer in conflict.
+4. **Ask** (*structured-choice*) when the intent is **ambiguous** or both sides are **incoherent** with each other (not combinable without losing something): answer `state: "ambiguous"` so nothing is written, then ask one content question per doubtful file/hunk (≤3 + `flow` control), options "Ours (`<destination>`)" / "Theirs (`<origin>`)" / "Combine" / "Edit manually". **Never invent** a resolution under real doubt. A **binary** conflict is never resolved automatically: propose `git checkout --ours|--theirs`.
+5. **Proposed commit**: completing the merge is a `git commit` (the merge commit) → **propose-then-execute** like any commit (canonical format above; outside a session → 1 line without the `session<NNN>` tag; never `--no-verify`/`--amend`/`push`). It is a **separate, confirmed** invocation — `aw fix-git commit --message "<msg>" --confirm` — which refuses while any file stays unmerged. The `git-commit-advisor` hook gates it.
 6. **Escape hatch**: if the merge must not complete, `git merge --abort` **after user confirmation** (*structured-choice*) — leaves the repo as before the merge.
 
 > **Resume via git**: the merge state in `.git` (MERGE_HEAD + index) **is** the checkpoint; re-running `/w:fix-git` resumes from the remaining conflicts. No session, no artifact.