@tacuchi/agent-workflow-cli 20.26.0 → 21.1.0

package/dist/domain/skills.js

@@ -1,7 +1,7 @@
 /**
  * Capability roles for the pluggable skills model.
  *
- * A loop composes a CAPABILITY by its role (e.g. "ui-design"), not a concrete
+ * A loop composes a CAPABILITY by its role (e.g. "design"), not a concrete
  * skill. The role → skill binding is resolved from `skills.toml`
  * (cascade: built-in default → global → workspace). See skills-resolver-service.
  *
@@ -12,10 +12,10 @@
  * or binds a specific convention skill; the host surfaces any useful one that is
  * installed (e.g. from the `dev-conventions` marketplace plugin, or anywhere).
  */
-export const SKILL_ROLES = ["ui-design", "sql", "git", "research", "diagrams", "overview"];
+export const SKILL_ROLES = ["design", "sql", "git", "research", "diagrams", "overview"];
 /** Built-in default skill name for each capability role. */
 export const BUILTIN_DEFAULT_SKILLS = {
-    "ui-design": "ui-spec",
+    design: "design",
     sql: "sql",
     git: "git",
     research: "research",
@@ -26,4 +26,27 @@ const ROLE_SET = new Set(SKILL_ROLES);
 export function isSkillRole(value) {
     return ROLE_SET.has(value);
 }
+export function classifyCapabilityBinding(resolved, canonicalName) {
+    if (!resolved.enabled || resolved.skill === null) {
+        return { state: "off", reason: `'${resolved.role}' está en off`, action: null };
+    }
+    if (resolved.skill === canonicalName) {
+        return { state: "floor_and_improvements", reason: null, action: null };
+    }
+    return {
+        state: "misconfigured",
+        reason: `'${resolved.role}' apunta a '${resolved.skill}', y un binding de reemplazo no selecciona una mejora`,
+        action: `dejá el binding sin declarar, ponelo en '${canonicalName}' o desactivalo con "off"`,
+    };
+}
+export const RETIRED_SKILL_IDENTITIES = new Map([
+    [
+        "ui-design",
+        "el role de diseño ahora es 'design' y su implementación por defecto también: no hay alias",
+    ],
+    [
+        "ui-spec",
+        "'ui-spec' es el render legacy y no implementa 'design', cuyo único formato es el UI Design Package v1",
+    ],
+]);
 //# sourceMappingURL=skills.js.map

package/dist/domain/skills.js.map

@@ -1 +1 @@
-{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG,CAAC,WAAW,EAAE,KAAK,EAAE,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,UAAU,CAAU,CAAC;AAIpG,4DAA4D;AAC5D,MAAM,CAAC,MAAM,sBAAsB,GAA8B;IAC/D,WAAW,EAAE,SAAS;IACtB,GAAG,EAAE,KAAK;IACV,GAAG,EAAE,KAAK;IACV,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,GAAG;CACd,CAAC;AAcF,MAAM,QAAQ,GAAwB,IAAI,GAAG,CAAC,WAAW,CAAC,CAAC;AAE3D,MAAM,UAAU,WAAW,CAAC,KAAa;IACvC,OAAO,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC7B,CAAC"}
+{"version":3,"file":"skills.js","sourceRoot":"","sources":["../../src/domain/skills.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG,CAAC,QAAQ,EAAE,KAAK,EAAE,KAAK,EAAE,UAAU,EAAE,UAAU,EAAE,UAAU,CAAU,CAAC;AAIjG,4DAA4D;AAC5D,MAAM,CAAC,MAAM,sBAAsB,GAA8B;IAC/D,MAAM,EAAE,QAAQ;IAChB,GAAG,EAAE,KAAK;IACV,GAAG,EAAE,KAAK;IACV,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,UAAU;IACpB,QAAQ,EAAE,GAAG;CACd,CAAC;AAcF,MAAM,QAAQ,GAAwB,IAAI,GAAG,CAAC,WAAW,CAAC,CAAC;AAE3D,MAAM,UAAU,WAAW,CAAC,KAAa;IACvC,OAAO,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC7B,CAAC;AA+CD,MAAM,UAAU,yBAAyB,CACvC,QAAuB,EACvB,aAAqB;IAErB,IAAI,CAAC,QAAQ,CAAC,OAAO,IAAI,QAAQ,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;QACjD,OAAO,EAAE,KAAK,EAAE,KAAK,EAAE,MAAM,EAAE,IAAI,QAAQ,CAAC,IAAI,eAAe,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC;IAClF,CAAC;IACD,IAAI,QAAQ,CAAC,KAAK,KAAK,aAAa,EAAE,CAAC;QACrC,OAAO,EAAE,KAAK,EAAE,wBAAwB,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC;IACzE,CAAC;IACD,OAAO;QACL,KAAK,EAAE,eAAe;QACtB,MAAM,EAAE,IAAI,QAAQ,CAAC,IAAI,eAAe,QAAQ,CAAC,KAAK,uDAAuD;QAC7G,MAAM,EAAE,4CAA4C,aAAa,2BAA2B;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,CAAC,MAAM,wBAAwB,GAAgC,IAAI,GAAG,CAAC;IAC3E;QACE,WAAW;QACX,2FAA2F;KAC5F;IACD;QACE,SAAS;QACT,uGAAuG;KACxG;CACF,CAAC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tacuchi/agent-workflow-cli",
-  "version": "20.26.0",
+  "version": "21.1.0",
   "description": "Runtime CLI for Workline — the stages + loops + artifacts system for agent work. Bundles the universal `w` skill set under `skills/w/` (slash commands `/w:*`: spec-new/spec-refine, plan-new/plan-exec, quick, persist, workspace-init, export-*); `self install --target <host>` copies SKILL + commands + hooks into the host. Pluggable capability skills via `.workflow/skills.toml`. Multi-empresa parametrization via `profile.json` cascade. Namespace auto-detected from any `.<ns>/sessions/` dir in CWD; default `workflow`.",
   "type": "module",
   "bin": {

package/skills/w/SKILL.md

@@ -48,7 +48,7 @@ USER invokes
         │ the export-* read the artifacts
         ▼
   docs/ ZONE — permanent, user-facing documents
-    specs · plans (flows) · research (persist / no-flow) · scripts · manuals · diagrams · reports (export-*) · tools (ambient)
+    specs · plans (flows) · designs (UI Design Packages) · research (persist / no-flow) · scripts · manuals · diagrams · reports (export-*) · tools (ambient)
 ```
 
 - **Layer 1** — high level. Single-pass or starts a loop. No iteration logic.
@@ -89,11 +89,11 @@ Before any loop, the AI resolves its **operating context** on **every prompt** w
 **Continuity rule** (single source — the chassis and the loops reference here):
 
 1. **Flow command** = **new work line** → new session.
-2. **Exception — re-run:** the same command over the **same input** (e.g. `/w:spec-refine` over the same spec) does **not** open another line: `create_or_resume` locates that flow's session (descriptor + `## Origin`) and **resumes or reopens** it (removes `.closed`), never duplicating it.
-3. **Consented exception — escalation:** an **accepted escalation** inside a loop (e.g. quick → SPEC) opens a **new work line without a command**; the signal is the user's **explicit consent** in the structured-choice, equivalent to having invoked the destination flow's command.
-4. **Prompt with no command** = "same line" → continue/reopen the **most recent** session (the *last started*).
-5. Only if the prompt is clearly **unrelated**: offer choosing (`continuar NNN` | `trabajo nuevo`) or fall to "no flow".
-6. **Convergence closes** the session; a later related prompt **reopens** it (resume removes `.closed`).
+2. **Prompt with no command** = "same line" → continue/reopen the **most recent** session (the *last started*).
+3. Only if the prompt is clearly **unrelated**: offer choosing (`continuar NNN` | `trabajo nuevo`) or fall to "no flow".
+4. **Convergence closes** the session; a later related prompt **reopens** it (resume removes `.closed`).
+
+> **The two exceptions to #1 are not this document's call:** re-running the same command over the **same input** does not open another line — `aw session-resume --code <NNN> --reopen` locates that flow's session by descriptor and `## Origin` and resumes it instead of duplicating it — and an **accepted escalation** inside a loop (quick → SPEC) opens a new line **without** a command, which `aw resume` treats as equivalent to having invoked the destination flow's, because the consent was explicit. Both stay stated here for their reason, not their rule: a line must never fork because somebody re-ran a command, and never continue silently because somebody changed subject.
 
 It is the **inter-turn** face of the *persistent objective* (same `CHECKPOINT`+resume, applied to the next prompt) — agnostic doctrine, not a host hook. It applies to **every artifact** (`SCRIPTS.sql` is the worked example; QUICK case: `loops/quick-loop/LOOP.md`).
 
@@ -108,7 +108,7 @@ The flows are **composable with host-native work, never exclusive**. The host is
 - `/w:spec-refine` — starts `spec-refine-loop` to refine the spec until it is `ready-for-plan`: the blocking functional decisions closed, the architecture/implementation ones declared for PLAN.
 - `/w:plan-new` — starts `plan-new-loop` to derive an executable plan from the ready spec.
 - `/w:plan-refine` — starts `plan-refine-loop` to turn the plan, in place, into an executable sequence of functional states (auxiliary, **not mandatory**); it is also the return path when execution hits a structural deviation.
-- `/w:plan-exec` — starts `plan-exec-loop` to execute the planned states and maintain the plan: it validates each phase before closing it, and never silently redesigns what it was given.
+- `/w:plan-exec` — executes planned states in live-inferred isolated/continuous batches; continuous units validate, review and commit only at batch close.
 - `/w:quick` — starts `quick-loop` (shortcut, no `docs/`; escalates live to SPEC when the objective exceeds a quick).
 - `/w:export-scripts` · `/w:export-manuals` · `/w:export-diagrams` · `/w:export-reports` — promote artifacts to `docs/`.
 
@@ -143,16 +143,16 @@ Common: Layer 1, explicit (user-invoked, never by a loop) · single-pass, read-o
 
 ### Capability skills + `.workflow/skills.toml`
 
-A loop does **not** compose a concrete skill; it composes a **capability by its role** (e.g. `ui-design`). Which skill fulfills the role is decided by config, never by the loop. Swapping implementations = one config line.
+A loop does **not** compose a concrete skill; it composes a **capability by its role** (e.g. `design`). Which skill fulfills the role is decided by config, never by the loop. Swapping implementations = one config line.
 
 ```toml
 [skills]
-ui-design        = "ui-spec"          # built-in default
+design           = "design"           # built-in default
 sql              = "sql"
 git              = "git"
 research         = "research"
 # diagrams       = "off"              # ← capability disabled
-# ui-design      = "acme/figma-spec"  # ← third-party skill (via skills.sh)
+# design         = "acme/figma-spec"  # ← third-party skill (via skills.sh)
 ```
 
 **Resolution cascade**: built-in default → `~/.workflow/skills.toml` (global, machine) → `.workflow/skills.toml` (workspace). Workspace overrides global; global overrides default. Unbound role → built-in default. `off` → disabled (the loop continues without it; if it was needed, it says so or asks).
@@ -161,13 +161,15 @@ Role catalog and defaults:
 
 | Role | Default | Tier | Composed by |
 |---|---|---|---|
-| `ui-design` | `ui-spec` | must | `spec-refine-loop` (UI) · `plan-new-loop` / `plan-refine-loop` (design SPECs) |
+| `design` | `design` | must | `spec-refine-loop` (UI) · `plan-new-loop` / `plan-refine-loop` · `plan-exec-loop` (reads, never redesigns) † |
 | `sql` | `sql` | must | research · `plan-exec-loop` · `quick-loop` · `export-scripts` |
 | `git` | `git` | must | `plan-exec-loop` · `quick-loop` |
 | `research` | `research` | should | every loop (inline capability) |
 | `diagrams` | `diagrams` | should | `export-diagrams` |
 | `overview` | `w` | should | anyone (orientation) |
 
+> † **The composing loops land references, not design.** `spec-refine` keeps `## Design references` and the plan loops promote the closure they implement and pin exact roots. The retired names `ui-design` and `ui-spec` resolve to nothing — no alias, no dual-read, no migration. See [roles/README.md](roles/README.md).
+>
 > **Ambient conventions (not roles):** code/testing/writing standards and `creating-tools` are standalone skills the host auto-discovers by `description` — Workline neither binds nor depends on them. Full doctrine: [roles/README.md](roles/README.md).
 
 The **loop chassis** is NOT bound: it is the common engine of the 5 loops ([`loops/CHASSIS.md`](loops/CHASSIS.md), a referenced doc), not a pluggable capability.
@@ -199,8 +201,8 @@ One language per plane — never mix them:
 ### The 6 hard invariants
 
 1. **No auto-export** — loops never graduate/export to `docs/`. Only `export-*` does, explicitly.
-2. **Each flow touches only its `docs/` folders** — SPEC→`specs` · PLAN→`plans` · QUICK→none · rest→`export-*`. (`docs/tools` and `docs/research` belong to no flow: `docs/tools` is written by the ambient skill `creating-tools`; `docs/research` by `/w:persist` or direct no-flow authoring.)
-3. **The spec and the plan are documents** (`docs/`), not session artifacts. *(Not to be confused with the **design SPECs** `NNN-SPEC-<SLUG>.md`: **per-screen** UI design artifacts that PLAN sessions produce via the `ui-design` capability when the plan includes UI — see `artifacts/artifacts-design/` — they are not the requirement-spec.)*
+2. **Each flow touches only its `docs/` folders** — SPEC→`specs` · PLAN→`plans` · QUICK→none · rest→`export-*`, **plus `docs/designs` for whichever loop composes the `design` capability** (spec-refine and the plan loops publish the package; `plan-exec` only reads it). (`docs/tools` and `docs/research` belong to no flow: `docs/tools` is written by the ambient skill `creating-tools`; `docs/research` by `/w:persist` or direct no-flow authoring.)
+3. **The spec and the plan are documents** (`docs/`), not session artifacts. *(Not to be confused with the **UI Design Package** the `design` capability produces under `docs/designs/NNN-design-<slug>/`: a durable dossier a spec **references** by baseline and digest — see [`roles/design/ROLE.md`](roles/design/ROLE.md) — it is not the requirement-spec.)*
 4. **DB scripts-only** — the AI never executes DML/DDL; migrations stay in `SCRIPTS.sql` and the user applies them. Only read-only reads via MCP.
 5. **Safe git** — expected branch verified before editing; proposed commits per source; never `push`/`--amend`/`--no-verify`.
 6. **Loop chassis** — the 5 loops run the same **common engine**; each loop is an heir adding only its deltas, nothing of the engine is re-declared. Detail: `loops/CHASSIS.md`.

package/skills/w/artifacts/README.md

@@ -35,7 +35,7 @@ Sessions are created by the loops as needed — **one session per run**. The ses
 
 > **Inline research (any session):** research is **not** a session type. When any session (`refine`/`exec`/`quick`) needs to investigate, it produces research artifacts **inline**: `ANALYSIS-FILE` (optional scratchpad), `CONCLUSIONS`, and read-only `SCRIPTS.sql` (if DB). These are written into the active session — there is no separate research session.
 
-> **Inline design (PLAN sessions):** when the plan **includes UI**, `plan-new-loop`/`plan-refine-loop` compose the **`ui-design`** capability and produce **design SPECs** — `NNN-SPEC-<SLUG>.md`, one **per screen** (`001-SPEC-MODAL-EXPORT.md`, `002-SPEC-ADMIN-DASHBOARD.md`), numbering local to the session — inside their own session. The plan-doc **references** them (UI Tasks) and `plan-exec-loop` reads them as the design reference. They are **not** the requirement-spec (invariant 3): they are process artifacts. See [`artifacts-design/`](artifacts-design/).
+> **Design is NOT a session artifact.** When a spec or a plan involves UI, the composed [`design`](../roles/design/ROLE.md) capability publishes a **UI Design Package** under `docs/designs/NNN-design-<slug>/` — a durable dossier the spec references by baseline and digest and the plan pins by exact root. Nothing about it lives in a session. The per-screen design SPEC (`NNN-SPEC-<SLUG>.md`) that PLAN sessions used to carry is **retired and unsupported**: no loop produces or reads one, there is no importer or conversion, and presenting one as input or as a gate's evidence is rejected — the result has to be recreated from current sources. Documents already written stay exactly where they are, byte for byte.
 
 > **PLAN note (rich plan):** the plan-doc (`docs/plans/PPP-plan.md`) absorbs inline the `TECHNICAL-NOTE` level (`Solution` — summary + AS-IS → TO-BE delta + Final behavior block —, `Impacted`, `Validations`…) **and** the phased `Tasks` (`### Fn` blocks). Therefore exec sessions do **not** carry a `TECHNICAL-NOTE` or own `TASKS` artifact: the technical detail and progress live in the plan-doc (living). `TASKS` remains as an optional artifact for sessions that need their own internal breakdown.
 
@@ -53,7 +53,6 @@ Sessions are created by the loops as needed — **one session per run**. The ses
 |---|---|---|
 | [`artifacts-core/`](artifacts-core/) | common to any session | `SESSION` · `TASKS` · `CHECKPOINT` · `BACKLOG` · `SCRIPTS.sql` |
 | [`artifacts-research/`](artifacts-research/) | inline research (any session) | `ANALYSIS-FILE` · `CONCLUSIONS` |
-| [`artifacts-design/`](artifacts-design/) | inline design (PLAN sessions with UI) | `NNN-SPEC-<SLUG>.md` (design SPEC, one per screen) |
 | [`artifacts-exec/`](artifacts-exec/) | `exec` / `quick` session | `DECISION` · `TECHNICAL-NOTE` (schema reference; absorbed by the plan-doc) |
 
 ---
@@ -61,6 +60,6 @@ Sessions are created by the loops as needed — **one session per run**. The ses
 ## Invariants (hard rules — canonical list: [`../SKILL.md`](../SKILL.md) § *The 6 hard invariants*)
 
 1. **No auto-export**: only `export-*` promotes to `docs/`, explicitly.
-2. **Each flow touches only its `docs/` folders**: SPEC→`specs` · PLAN→`plans` · QUICK→none.
-3. **Spec and plan are documents**, never session artifacts. *(Design SPECs `NNN-SPEC-<SLUG>.md` are a different thing: per-screen UI artifacts of PLAN sessions — [`artifacts-design/`](artifacts-design/).)*
+2. **Each flow touches only its `docs/` folders**: SPEC→`specs` · PLAN→`plans` · QUICK→none — plus `docs/designs` for whichever loop composes `design`.
+3. **Spec and plan are documents**, never session artifacts. *(Neither is the **UI Design Package** under `docs/designs/`: a durable dossier the spec references, not the requirement-spec.)*
 4. **DB scripts-only**: never execute DML/DDL; migrations (type B) stay in `SCRIPTS.sql` and ship via `export-scripts`; only read-only queries (type A) run via MCP.

package/skills/w/artifacts/artifacts-core/CHECKPOINT.md

@@ -13,10 +13,10 @@
 ## Completed
 What already happened: finished phases/tasks/gaps with their outcome (ref: plan-doc `docs/plans/PPP-plan.md`, the spec's gaps, or `TASKS.md` if the session created its own split). Fold the key context a resume needs (settled decisions, discoveries) into these bullets.
 
-> **Implemented is not validated (exec sessions).** A phase lands here only once the plan-doc's `> Estado: validada` was flipped. Work that is written but not yet proven stays in `Pending / Next` with its validation pending — a full set of ticked tasks never promotes a phase into this section. Each closed phase records the **functional state reached** and, **only when the change carries one**, the **simulation boundary in force** — that, not the list of files touched, is what a resume actually needs.
+> **Implemented is not validated (exec sessions).** A phase lands here only once the plan-doc's `> Estado: validada` was flipped. Work that is written but not yet proven stays in `Pending / Next` with its validation pending — a full set of ticked tasks never promotes a phase into this section. Continuous-batch phases move together only after their combined validation/review. Each closed phase records the **functional state reached** and, **only when the change carries one**, the **simulation boundary in force** — that, not the list of files touched, is what a resume actually needs.
 
 ## Pending / Next
-The intent: what remains and what comes immediately next (seeded BEFORE executing — artifact-first). A resume starts here. In exec: the next functional state being pursued, plus any blocker or deferral that keeps a phase out of `validada`. A phase left `bloqueada` states here **what is missing to validate it** — applying the migration, an environment, a third party — so the next run knows what to execute before flipping the state.
+The intent: what remains and what comes immediately next (seeded BEFORE executing — artifact-first). A resume starts here. In exec, record the effective batch (`id` · `continuous|isolated` · phases), any declared-vs-live regrouping and explicit conditional commit authorization, then the next functional state. A phase left `bloqueada` states here **what is missing to validate it** — applying the migration, an environment, a third party — so the next run knows what to execute before flipping the state.
 
 ## Open questions
 Live doubts not yet resolved — the section exists only while there are any (rule 1). Deferred ones move to the session's `BACKLOG` or the flow doc's `## Open questions`.

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

@@ -1,5 +1,5 @@
 ---
-description: Use when a plan is ready to implement — the real work: code edits, proposed SQL scripts, created tools. Starts or resumes plan-exec-loop over docs/plans/PPP-plan-<slug>.md, phase by phase, validating each before closing it. Git-safe (proposes commits, never push/--amend).
+description: Use when a plan is ready to implement. Starts/resumes plan-exec-loop over docs/plans/PPP-plan-<slug>.md, re-inferring continuous batches and deferring their validation, review and single-per-source commits to batch close.
 argument-hint: <docs/plans/PPP-plan-<slug>.md>
 allowed-tools:
   [
@@ -12,19 +12,25 @@ allowed-tools:
 
 # plan-exec — trampoline to the execution loop
 
-Starts or resumes `plan-exec-loop` (Layer 2), which executes the real work phase by phase — each phase a **verifiable state of the system**, not a batch of technical chores. The plan is a living document the loop keeps updated: each `### Fn` carries its own `> Estado:` line (`pendiente` | `en ejecución` | `bloqueada` | `validada`) next to its task checkboxes.
+Starts or resumes `plan-exec-loop` (Layer 2). Phases remain verifiable states; effective batches are
+execution units. The loop re-infers them from live state using
+[`PLAN-EXECUTION-BATCHES`](../modules/PLAN-EXECUTION-BATCHES.md), then updates each phase's
+checkboxes and `> Estado:` line in the living plan.
 
 > **Hard floor — applies even if you read nothing beyond this file:**
 >
 > 1. **Session first** — create/resume the run's session before touching code: `aw session-create --type exec --name <slug>-plan-exec --objetivo "<one-line objective>"`; keep its `CHECKPOINT.md` updated (`## Completed` · `## Pending / Next`; `## Open questions` only while live doubts exist).
-> 2. **Git/DB** — verify each source's expected branch before editing (`aw check-branch`); commits are **proposed**, never executed without approval; **never** `push`/`--amend`/`--no-verify`; never execute DML/DDL (SQL goes to the session's `SCRIPTS.sql`).
+> 2. **Git/DB** — branch-check before a batch; exactly one commit per affected source after its
+>    checks/review. Use one final approval unless the user explicitly pre-authorized green commits.
+>    Never `push`/`--amend`/`--no-verify`; DML/DDL stays in `SCRIPTS.sql`.
 > 3. **Ask, don't invent** — user-dependent decisions go through questions with a recommended option first (≤3 content questions + the `flow` control `Compactar`/`Cerrar`).
 > 4. **Language** — everything user-facing (questions, option labels, reports) goes in the **user's language**.
 
 ## Run the loop
 
 1. `aw context-plan --command plan-exec --root "${CLAUDE_PLUGIN_ROOT}/skills/w"` — read exactly the documents it lists, in order.
-2. Follow the loop manual end to end, taking `$ARGUMENTS` as input: it checks executability on entry, executes phase by phase (git-safe, DB scripts-only), keeps the plan alive and reports.
+2. Follow it end to end: check executability, infer live batches, execute each without internal
+   validation pauses, then validate/review/commit at its close.
 
 > `plan-exec-loop` is **not** a skill invocable by name — it is this command's operating manual. The command **is** the entry; the loop is its body. It is **resumable**: an existing CHECKPOINT continues from there.
 
@@ -40,4 +46,4 @@ Starts or resumes `plan-exec-loop` (Layer 2), which executes the real work phase
 - `db` — the plan touches a database → [`../modules/EXEC-DB-POLICY.md`](../modules/EXEC-DB-POLICY.md)
 - `probe` — a task is a PoC → [`../modules/EXEC-PROBE-TASKS.md`](../modules/EXEC-PROBE-TASKS.md)
 - `simulation` — **only when the change carries temporary behavior**, its boundary is declared and its retirement identified → [`../modules/SIMULATION-LIFECYCLE.md`](../modules/SIMULATION-LIFECYCLE.md)
-- `ui` — the plan references design SPECs → [`../modules/PLAN-DESIGN-SPECS.md`](../modules/PLAN-DESIGN-SPECS.md)
+- `ui` — the plan pins design references → [`../modules/DESIGN-REFERENCES.md`](../modules/DESIGN-REFERENCES.md). Before implementing a task that pins one, `aw designs --plan <plan-doc>` decides: absent, altered, revoked or an applicable closure short of `handoff` **block** naming the artifact and the fix; superseded-but-intact only warns. `plan-exec` never redesigns.

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

@@ -1,5 +1,5 @@
 ---
-description: Use when a spec is ready to become an executable plan — not to refine one (plan-refine) nor execute one (plan-exec). Starts plan-new-loop from docs/specs/NNN-spec-<slug>.md, turning the "what" into the "how". Also adopts an externally-built plan. May split into sibling plans.
+description: Use when a spec is ready to become an executable plan. Starts plan-new-loop from docs/specs/NNN-spec-<slug>.md, turning the "what" into functional phases and inferred execution batches. Also adopts an external plan and may split siblings.
 argument-hint: <docs/specs/NNN-spec-<slug>.md | prompt>
 allowed-tools:
   [
@@ -32,11 +32,15 @@ SPEC → PLAN bridge. Turns the "what" (refined spec) into the "how" (plan). Del
 
 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`; only `plan-exec` closes it.
 
+It also writes the complete `## Execution batches` partition from
+[`PLAN-EXECUTION-BATCHES`](../modules/PLAN-EXECUTION-BATCHES.md): maximal eligible ranges are
+`continuous`; the rest are one-phase `isolated` units. This is inferred, not asked.
+
 ## More context
 
 `aw context-plan --command plan-new --signal <s> --root "${CLAUDE_PLUGIN_ROOT}/skills/w"` returns the extra documents a case needs; read exactly what it lists:
 
 - `input` — the argument is not plainly a `ready-for-plan` spec → [`../modules/PLAN-INPUT.md`](../modules/PLAN-INPUT.md)
 - `split` — the spec may need more than one plan → [`../modules/PLAN-SPLIT-GATE.md`](../modules/PLAN-SPLIT-GATE.md)
-- `ui` — the plan includes UI, so it composes `ui-design` → [`../modules/PLAN-DESIGN-SPECS.md`](../modules/PLAN-DESIGN-SPECS.md)
+- `ui` — the plan includes UI: promote the closure, pin the roots → [`../modules/DESIGN-REFERENCES.md`](../modules/DESIGN-REFERENCES.md)
 - `probe` — the plan rests on a runnable unknown → [`../modules/PLAN-PROBE-TASKS.md`](../modules/PLAN-PROBE-TASKS.md)

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

@@ -1,5 +1,5 @@
 ---
-description: Use when a plan must become executable before running it — new requirements, scope tweaks, phases shaped as file lists, or a structural deviation returned by plan-exec. Starts plan-refine-loop, which re-shapes docs/plans/PPP-plan-<slug>.md in place into verifiable functional states.
+description: Use when a plan must become executable before running it. Starts plan-refine-loop, which re-shapes docs/plans/PPP-plan-<slug>.md in place into verifiable functional states and re-infers its execution batches.
 argument-hint: <docs/plans/PPP-plan-<slug>.md>
 allowed-tools:
   [
@@ -28,7 +28,10 @@ allowed-tools:
 
 > `plan-refine-loop` is **not** a skill invocable by name — it is this command's operating manual. The command **is** the entry; the loop is its body.
 
-**Expected output: an executable plan.** The loop converges on its **executability gate** — each phase a verifiable state with its evidence, its exit condition and, **only when the change carries temporary behavior**, its simulation boundary — so `plan-exec` implements it without inventing contracts, observable states, order or evidence.
+**Expected output: an executable plan.** Each phase has evidence and an exit condition;
+**only when the change carries temporary behavior**, it declares that boundary. The complete partition follows
+[`PLAN-EXECUTION-BATCHES`](../modules/PLAN-EXECUTION-BATCHES.md), so execution need not invent or
+ask about units.
 
 ## More context
 
@@ -38,4 +41,4 @@ allowed-tools:
 - `resume` — a prior refinement of this plan may exist → [`../modules/PLAN-REFINE-KEYS.md`](../modules/PLAN-REFINE-KEYS.md)
 - `replan` — work already executed has to be re-planned around → [`../modules/REPLANNING.md`](../modules/REPLANNING.md)
 - `simulation` — the change carries temporary behavior, so **only when** it does, its boundary is declared → [`../modules/SIMULATION-LIFECYCLE.md`](../modules/SIMULATION-LIFECYCLE.md)
-- `ui` — the refine touches UI → [`../modules/PLAN-REFINE-DESIGN-SPECS.md`](../modules/PLAN-REFINE-DESIGN-SPECS.md)
+- `ui` — the refine touches UI, so it revises only the artifacts it affects → [`../modules/DESIGN-REFERENCES.md`](../modules/DESIGN-REFERENCES.md)

package/skills/w/commands/quick.md

@@ -30,8 +30,8 @@ Delegates to `quick-loop` (Layer 2). Creates a light session (traceability + res
 
 ## Two things this command never does
 
-- **It never touches `docs/`** and it exports nothing.
-- **It never re-derives what the conversation already settled.** Analysis already established here is *input*, seeded into the session with `## Origin` = adopted.
+- **It never writes `docs/`** and it exports nothing. It may READ a design package; changing one escalates.
+- **It never re-derives what the conversation already settled** — that analysis is *input* (`## Origin` = adopted).
 
 ## More context
 

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

@@ -76,7 +76,7 @@ Assumed facts.
 Pending doubts. ← the spec-refine-loop closes them.
 ```
 
-> **`Open questions` goes last** — the refined spec **inserts before `Open questions`** `## UI spec` (if there is UI) + `## Decisions`, and may add `## Affected capabilities` / `## Behavioral changes` right after `Context` when the change touches behavior that already exists (refined schema in the [`spec-refine-loop`](../loops/spec-refine-loop/LOOP.md); the refine drops `Open questions` when it empties). Draft and refined spec share the same skeleton and order.
+> **`Open questions` goes last** — the refined spec **inserts before `Open questions`** `## Design references` (if there is UI) + `## Decisions`, and may add `## Affected capabilities` / `## Behavioral changes` right after `Context` when the change touches behavior that already exists (refined schema in the [`spec-refine-loop`](../loops/spec-refine-loop/LOOP.md); the refine drops `Open questions` when it empties). Draft and refined spec share the same skeleton and order.
 
 **Filling notes:**
 
@@ -88,7 +88,7 @@ Pending doubts. ← the spec-refine-loop closes them.
 - **The code found never widens `Scope`** and never becomes a requirement: **acceptance criteria derive from the user's intent**. The reconnaissance may lend vocabulary, name existing actors and boundaries, and avoid obvious contradictions. It must not invent behavior nobody asked for, turn a current technical decision into a user requirement, or impose an implementation as a criterion.
 - **Acceptance criteria = static testable criteria** (the "what"): `plan-exec` validates them, but progress is tracked in the PLAN (its Tasks), never by ticking these `- [ ]`; the spec never mutates by execution, only by a re-refine.
 - **Scenarios = behavior made concrete** (uppercase GIVEN/WHEN/THEN/AND): draft them only when the prompt already describes behavior — deriving the rest is spec-refine work. A scenario earns its place only when it adds GIVEN setup or edge semantics the criterion does not capture — **never restate a criterion 1:1**.
-- If **UI** is involved, mention it in `Requirement`/`Context`; `## UI spec` is authored in `spec-refine` (via the `ui-design` capability). "UI unspecified" is a first-class refinement gap.
+- If **UI** is involved, **record the need and stop there**: mention it in `Requirement`/`Context`. This command creates **no design package** and writes no `## Design references` — the design is composed in `spec-refine` (via the [`design`](../roles/design/ROLE.md) capability, which publishes the package the spec then references). Minting a package from a draft would pin an identity before the requirement is even closed. "UI unspecified" is a first-class refinement gap.
 - The **gaps** the loop detects = weak sections of the schema (vague Requirement, Scope without `Out`, untestable criteria, open questions, undeclared assumptions, contradictions) **+ UI unspecified** when the requirement involves UI.
 - Equivalent alternative: the user writes the draft by hand. Both paths produce the same file.
 

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

@@ -35,5 +35,6 @@ Delegates to `spec-refine-loop` (Layer 2), which iterates, closes the blocking g
 `aw context-plan --command spec-refine --signal <s> --root "${CLAUDE_PLUGIN_ROOT}/skills/w"` returns the extra documents a case needs; read exactly what it lists:
 
 - `shape` — the loop's change-shape gate fired and you must tell `split` from `replace` → [`../modules/SPEC-CHANGE-SHAPE.md`](../modules/SPEC-CHANGE-SHAPE.md)
+- `ui` — the requirement involves UI, so the spec references a design package instead of containing one → [`../modules/DESIGN-REFERENCES.md`](../modules/DESIGN-REFERENCES.md)
 - `resume` — a prior refinement of this spec may exist → [`../modules/SPEC-REFINE-KEYS.md`](../modules/SPEC-REFINE-KEYS.md)
 - `web` — the solution space looks unexplored and the loop opens its ideation step → [`../modules/IDEATION-GATE.md`](../modules/IDEATION-GATE.md)

package/skills/w/context/MANIFEST.json

@@ -22,6 +22,36 @@
     "classification": "in-conversation work has to be classified before it is written",
     "authoring": "the deliverable's own notation, structure or ordering is not obvious from the material"
   },
+  "$comment_flow_signals": "Vocabulary the AGENT may declare at a flow boundary — kept HERE, next to the context signals, so there is one catalog and not two that drift. The frontier is exact: recognizing a signal is judgment (the agent's), applying the threshold over the declared signals is a rule (the CLI's). A signal outside this vocabulary never advances a journey. Each id must be consumed by some transition of the authority registry, and every signal a transition consumes must appear here: the guard runs in both directions.",
+  "flow_signals": {
+    "quick.needs-architecture": "the objective cannot be met without deciding how responsibilities are distributed",
+    "quick.two-or-more-sources": "the change reaches two or more declared sources",
+    "quick.multiple-deliverables": "the objective bundles more than one independent deliverable",
+    "quick.large-feature-or-refactor": "the size is that of a feature or a refactor, not a scoped fix",
+    "quick.ambiguous-requirements": "what is being asked needs elicitation before anything can be built",
+    "quick.deliverable-is-analysis": "what the task produces is an analysis or a design, so its criterion is a rubric a person ratifies",
+    "spec.functional-ambiguity": "a functional ambiguity with two readings that would change what gets built is blocking this spec",
+    "spec.solution-space-unexplored": "a trigger of the ideation gate fires: the spec settled on its first idea and the alternatives would change the outcome",
+    "spec.independent-outcomes": "the prompt holds outcomes each worth delivering on its own",
+    "spec.enumerated-features": "the prompt enumerates distinct features explicitly",
+    "spec.distinct-moments": "the parts are requested for different moments or in a stated order",
+    "spec.independent-value": "the users or the value of each part do not depend on the others",
+    "plan.independent-tranches": "the tranches are executable and deliverable independently",
+    "plan.no-shared-deps": "the tranches share neither dependencies nor risk",
+    "plan.distinct-priorities": "the tranches are requested at different moments or priorities",
+    "plan.far-beyond-s": "the plan far exceeds S-complexity phases",
+    "plan.staging-requested": "the person asked for the work to be staged",
+    "plan.dependency-outside-range": "a phase of the range depends on something neither already satisfied nor an earlier phase of that same range",
+    "plan.result-shapes-later": "a phase result, proof, probe or human decision determines how a later phase has to be built",
+    "plan.blocker-between-phases": "an unresolved question, a live blocker, an operative handoff or an irreversible external action sits between the phases",
+    "plan.recovery-boundary": "an intermediate commit, release, review or deployment is a required recovery boundary",
+    "plan.not-one-reviewable-unit": "the combined change is not coherent, recoverable and reviewable as a single unit",
+    "plan.entry-gap-minor": "the plan is all but executable: the gap is derivable from what it already states, so it can be normalized in place",
+    "plan.entry-gap-structural": "phases, contracts or journey are missing, or temporary behavior leaves its boundary undeclared",
+    "plan.deviation-structural": "the change that appeared while implementing touches a contract, the participating components, the phase order or the simulation boundary",
+    "plan.deviation-functional": "the change that appeared while implementing touches the expected result, the scope, a business rule or an acceptance criterion",
+    "chassis.context-pressure": "a fresh reader would need the CHECKPOINT to continue this run"
+  },
   "commands": {
     "quick": {
       "core": [
@@ -53,6 +83,10 @@
           "signal": "db",
           "requires": "external-data"
         },
+        {
+          "path": "modules/DESIGN-REFERENCES.md",
+          "signal": "ui"
+        },
         {
           "path": "modules/COMPACTION.md",
           "signal": "compaction",
@@ -100,6 +134,10 @@
           "path": "modules/SPEC-REFINE-KEYS.md",
           "signal": "resume"
         },
+        {
+          "path": "modules/DESIGN-REFERENCES.md",
+          "signal": "ui"
+        },
         {
           "path": "modules/IDEATION-GATE.md",
           "signal": "web",
@@ -130,7 +168,12 @@
       ]
     },
     "plan-new": {
-      "core": ["commands/plan-new.md", "loops/plan-new-loop/LOOP.md", "loops/CHASSIS.md"],
+      "core": [
+        "commands/plan-new.md",
+        "loops/plan-new-loop/LOOP.md",
+        "modules/PLAN-EXECUTION-BATCHES.md",
+        "loops/CHASSIS.md"
+      ],
       "modules": [
         {
           "path": "modules/PLAN-MODE.md",
@@ -149,7 +192,7 @@
           "signal": "split"
         },
         {
-          "path": "modules/PLAN-DESIGN-SPECS.md",
+          "path": "modules/DESIGN-REFERENCES.md",
           "signal": "ui"
         },
         {
@@ -185,6 +228,7 @@
         "commands/plan-refine.md",
         "loops/plan-refine-loop/LOOP.md",
         "loops/plan-new-loop/LOOP.md",
+        "modules/PLAN-EXECUTION-BATCHES.md",
         "loops/CHASSIS.md"
       ],
       "modules": [
@@ -213,11 +257,7 @@
           "signal": "split"
         },
         {
-          "path": "modules/PLAN-REFINE-DESIGN-SPECS.md",
-          "signal": "ui"
-        },
-        {
-          "path": "modules/PLAN-DESIGN-SPECS.md",
+          "path": "modules/DESIGN-REFERENCES.md",
           "signal": "ui"
         },
         {
@@ -260,6 +300,7 @@
       "core": [
         "commands/plan-exec.md",
         "loops/plan-exec-loop/LOOP.md",
+        "modules/PLAN-EXECUTION-BATCHES.md",
         "loops/CHASSIS.md",
         "loops/CODE-POLICIES.md"
       ],
@@ -296,7 +337,7 @@
           "signal": "simulation"
         },
         {
-          "path": "modules/PLAN-DESIGN-SPECS.md",
+          "path": "modules/DESIGN-REFERENCES.md",
           "signal": "ui"
         },
         {
@@ -437,6 +478,13 @@
       ]
     }
   },
+  "capabilities": {
+    "$comment": "Conformant capabilities: the same read-set question as a command, and deliberately NOT commands — no commands/<name>.md, no activation median, no reclassification as a single-pass command.",
+    "design": {
+      "core": ["roles/design/CONTRACT.md"],
+      "modules": []
+    }
+  },
   "journeys": [
     {
       "id": "spec",
@@ -476,7 +524,7 @@
     }
   ],
   "budget_policy": {
-    "$comment": "Ratios of the frozen baseline (spec 009 \u00a7 Decisions: -30% discovery, -40% median and -20% minimum activation, -25% median execution, +5% ceiling per journey). Absolute targets are DERIVED from baseline x ratio, never written by hand. The +5% ceiling also caps modules.total, the conditional tree as one figure: a representative journey carries no signal, so no journey line ever prices a module, and without that line the modules would grow unwatched.",
+    "$comment": "Ratios of the frozen baseline (spec 009 § Decisions: -30% discovery, -40% median and -20% minimum activation, -25% median execution, +5% ceiling per journey). Absolute targets are DERIVED from baseline x ratio, never written by hand. The +5% ceiling also caps modules.total, the conditional tree as one figure: a representative journey carries no signal, so no journey line ever prices a module, and without that line the modules would grow unwatched.",
     "discovery_max_ratio": 0.7,
     "activation_median_max_ratio": 0.6,
     "activation_each_max_ratio": 0.8,

package/skills/w/harness/HARNESS.md

@@ -79,6 +79,26 @@ Concrete mechanism per harness (matrix base verified **Jul-2026**; the `structur
 
 > **web-research (consumer & consent).** Single consumer today: `spec-refine-loop` § *Ideation gate* (the SPEC flow's divergent gate). Consent is **bundled into accepting that gate's offer** — one accepted offer authorizes that round's searches; never free browsing outside a consented round. It is *enhancement*, never a `must`: on degrade the loop ideates **offline and declares it** (unlike host-memory's silent omit — the user consented expecting the web, so silence would mislead).
 
+## Directive presentation (flow boundaries)
+
+A host surface — a command wrapper, a skill, an adapter — **invokes** the direction engine (`aw flow advance` / `aw flow submit`), **transports** the directive it returns and **presents** it. It never re-derives a transition, re-orders a journey or restates a rule the engine owns: the CLI decides, the surface shows. Two surfaces on two hosts therefore show the *same* boundary through *different* mechanisms, which is precisely the *capability, not tool* principle applied to one more capability.
+
+Each boundary kind maps to a capability **already catalogued above**; this table adds no host column, so per-host mechanisms keep living in exactly one place — the binding matrix.
+
+| Boundary | What it asks for | Capability used | Must survive the presentation |
+|---|---|---|---|
+| **semantic** | a bounded judgment from the agent | *procedure-loading* — the agent reads the request's `read_set` and answers inline; no human mechanism involved | `request` whole — contract, limits, `read_set` — and `state_digest` |
+| **human** | a preference nobody may infer | *structured-choice* | every `choices` entry with its consequence, and the single recommendation |
+| **authorization** | an approval over the effect classes it names | *structured-choice* | `choices`, `effects`, `authorizations`, and the approval digest carried in `next_action` |
+| **execution** | a step the CLI decided and cannot run inside its own process | *command-invocation* — run exactly the invocation the directive names | `action` whole — program, args, target, input, the `evidence` demanded and the recovery — plus `state_digest` |
+| **blocked** | nothing, until the cause is cleared | — (plain report) | `error`: code, message and the one valid action |
+| **final** | nothing: the journey is done | — (plain report) | `pending` (empty) and the `applied` trace with each step's authority |
+
+- **Four things a presentation may never drop**, whatever the host: the **options** with their consequence (`choices`), the **explanation** of what is being asked (`request` at a semantic boundary), the **effects** at stake (`effects` + `authorizations`), and the **resume evidence** (`state_digest` + `session`) — without that last pair the boundary cannot be answered from another host, or after the conversation is gone.
+- **Degrade the mechanism, never the content.** A host with no native question surface renders labeled markdown (see the matrix); it does not merge, truncate or drop alternatives to fit. Losing content is a *degradation* and is declared as one.
+- **Ownership travels with every step.** The trace says each applied transition is `cli-owned`, and a surface may not present one as its own decision — the registry (`domain/flow/authority.ts`) is the only place ownership changes.
+- **An execution boundary is answered with output, never with agreement.** The surface transports `action` unchanged, the executor runs *that* invocation, and `aw flow submit` brings back the real result: the outcome, the invocation it actually ran, and one validation per demanded evidence id carrying the tool's own output in `detail`. A boolean confirmation, a narration or an approval already granted prove nothing ran — the engine refuses them and the transition stays pending with the action's declared recovery.
+
 ## Leverage installed skills
 
 "Leverage whatever skills the harness has installed" resolves through the **same** `.workflow/skills.toml` binding: a role can point at a skill **installed on the host** (third-party, via skills.sh) instead of the built-in. Rule:

package/skills/w/loops/CHASSIS.md

@@ -2,6 +2,8 @@
 
 This document is the **common engine** of the Workline loops: the doctrine every loop runs underneath its deltas. **It is not a skill** — it is a referenced document: every loop orders it read from its `## Inherits`, **always, before its deltas**. If you edit the engine, edit it **here** — heirs never repeat it, they only reference it.
 
+> **When each step below happens is no longer this document's call:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document. What stays is what each rule is FOR — the half no engine carries.
+
 ## Heirs (canonical list)
 
 The **5 loops** run this engine; each adds only its deltas:
@@ -67,13 +69,7 @@ The loop works **artifact-first**: the artifact is **seeded before** executing a
 
 ## Gap-driven convergent engine
 
-The common cycle — each heir instantiates it in its `## Sequence` with its own gap taxonomy:
-
-1. `detect_gaps(work)`, minus the *exhausted* gaps (see *Research*).
-2. If `∅` → **convergence gate** (see *Convergence / exit*).
-3. If there are gaps: take a batch (≤3) and **seed** `CHECKPOINT.Pending/Next` (*artifact-first*).
-4. Resolve each gap with its **resolver** per the *ask-vs-research rule*: human (structured-choice) · inline research · a probe (PoC) · a composed capability (e.g. `ui-design`).
-5. **Integrate**, update `CHECKPOINT` → repeat.
+The common cycle — each heir instantiates it in its `## Sequence` with its own gap taxonomy: detect the gaps, seed `CHECKPOINT.Pending/Next` (*artifact-first*), resolve each with its resolver, integrate, repeat until none is left and the convergence gate can run. The pacing is the CLI's — one open boundary at a time, which meets the ≤3 ceiling by construction. Why it is gap-driven at all stays here: a plan fixed up front cannot notice what it did not know.
 
 ## Internal sessions (managed) — one session per run
 
@@ -87,12 +83,7 @@ The loop creates and manages its session under `.workflow/sessions/`; **the user
 
 ## Ask-vs-research rule (the discriminator)
 
-For every gap, a single question picks the resolver:
-
-> *"Was this already established in the current conversation?"* → **adopt it** (`adopted` module) — never re-ask or re-research settled conclusions.
-> *"Can I answer this by reading the repo/data?"* → **research** (autonomous).
-> *"Can I only answer it by RUNNING a small experiment?"* → **probe** (`probe` module).
-> *"Does it depend on what the user wants?"* → **ask the human** (structured-choice).
+Which resolver a gap gets is the kind of thing it is, and the CLI classifies it: a boundary's kind IS its resolver. Already **established in this conversation** → adopt it (`adopted` module), never re-ask a settled conclusion · answerable by **reading** the repo/data → research, autonomously · answerable only by **RUNNING a small experiment** → a probe (`probe` module) · dependent on **what the user wants** → ask the human. Why: asking a person what a file already says wastes the one resource the loop cannot regenerate, and guessing what only they decide is worse.
 
 ## Research: autonomy, scope & failure
 
@@ -101,16 +92,16 @@ Investigation is **inline**: an activity **inside the run's current session**, n
 - **Autonomous**: the AI investigates inline and reports **without asking permission**. The human learns of it at integration time and keeps control via the `flow` control.
 - **Scope**: the current conversation (settled conclusions are reused, never re-derived) + workspace + associated repos + DB MCPs.
 - **DB rule** — the single exception to autonomy: it lives in the `db` module and is loaded **before** any query runs.
-- **Inconclusive research** (DB unavailable, insufficient evidence, unresolvable factual gap): the investigation closes with status **`inconclusive`** in `CONCLUSIONS` and reports why. The loop **degrades** the gap — to a human question, or failing that to the flow doc's `## Open questions` (the session's `BACKLOG` when the flow has no doc) — and marks it **"already tried via research"** (`attempts[gap]++`, `MAX` cap) so `detect_gaps` does **not** re-fire it in a loop. That is what guarantees convergence.
+- **Inconclusive research** (DB unavailable, insufficient evidence, unresolvable factual gap): the investigation closes with status **`inconclusive`** in `CONCLUSIONS` and reports why. The loop **degrades** the gap — to a human question, or failing that to the flow doc's `## Open questions` (the session's `BACKLOG` when the flow has no doc) — instead of re-firing it. Counting the attempts and refusing the one past the cap is the CLI's; declaring where a degraded gap GOES is doctrine's, because a gap dropped without a destination is the convergence this engine promises, faked.
 
 ## Structured-choice (design & batching)
 
-**Canonical rule:** *structured-choice* = **≤3 content questions + 1 `flow` control**, always. Each option is a **short semantic label + one functional sentence** (outcome/trade-off or simple example), never a positional code. Use the richest current binding in [`HARNESS.md`](../harness/HARNESS.md); otherwise use labeled markdown.
+**Canonical form:** *structured-choice* = **≤3 content questions + 1 `flow` control**, always. Each option is a **short semantic label + one functional sentence** (outcome/trade-off or simple example), never a positional code. The CLI builds it and refuses a question that does not hold this form. Present it with the richest current binding in [`HARNESS.md`](../harness/HARNESS.md); otherwise labeled markdown.
 
-- **Flow:** `Compactar` | `Cerrar`; an unanswered control means continue (`Continuar` when the UI requires it). Under context pressure the loop **raises the choice itself**, recommending `Compactar`.
+- **Flow:** `Compactar` | `Cerrar`, appended to every boundary with alternatives — never the question's to omit, because one nobody can pause or leave is not a question. An unanswered control means continue (`Continuar` when the UI requires it). Under context pressure the loop **raises the choice itself**, recommending `Compactar`.
 - **Content/batching:** human gaps, pre-query MCP choice and the convergence action | `Preguntar algo más`; at most 3 per call. Honor a smaller native ceiling by reserving one question slot for `flow`; carry overflow, prioritizing blockers.
 - **Options/encoding:** prefer 2–3 alternatives. Map label/sentence to separate fields or `Label — functional sentence`. If it cannot fit, use labeled markdown; never truncate or merge candidates or duplicate a host-provided free-text option.
-- **Recommendation:** the first option is marked *recommended* and comes from research; the human ratifies or corrects it, never starts cold.
+- **Recommendation:** exactly one option is *recommended*, it comes first, and it comes from research; the human ratifies or corrects it, never starts cold.
 - **Text fallback:** answer by label; `Aceptar recomendaciones` accepts all first options. Never require composite coordinates such as `1A, 2A, 3A`.
 
 > Canonical labels (`Continuar`, `Compactar`, `Cerrar`, `Aceptar recomendaciones`, `Guardar plan`, …) stay verbatim; other user-facing text follows [`SKILL.md`](../SKILL.md) § *Language policy*.
@@ -129,12 +120,12 @@ Resume **keys off the `CHECKPOINT`** of the run's session, not the existence of
 
 ## Convergence / exit
 
-- **No material gaps** → **convergence gate** (read-only) = **`Success criteria` green** (*verification-first*). Whatever fails **comes back as a gap**; if it passes → the loop **flips the green criteria** in `SESSION.md` (`- [ ]` → `- [x]`) and offers its closing action. The checklist must reflect the real final state: a criterion left unchecked at `finalize` needs an explicit reason. Each heir names its own instance of this gate.
-- `Cerrar` (the `flow` control, at any time) → `finalize`. **`finalize` always persists `CHECKPOINT.md`** (resumable) and, **only if** something was deferred, writes `BACKLOG.md` (close reason + the deferred items); closes the session and reports. Progress survives even without a prior `Compactar`.
+- **No material gaps** → **convergence gate** (read-only) = **`Success criteria` green** (*verification-first*). Whatever fails **comes back as a gap**; if it passes → the loop **flips the green criteria** in `SESSION.md` (`- [ ]` → `- [x]`) and offers its closing action. The checklist must reflect the real final state: a criterion left unchecked at `finalize` needs an explicit reason. Each heir names its own instance of this gate, and those instances are what realize it.
+- `Cerrar` (the `flow` control, at any time) → `finalize`, the last step of every journey. **`finalize` always persists `CHECKPOINT.md`** (resumable) and, **only if** something was deferred, writes `BACKLOG.md` (close reason + the deferred items); closes the session and reports. Progress survives even without a prior `Compactar`.
 
 ## docs/ boundary — no auto-export (hard rule)
 
-A loop writes into `docs/` **only** its own flow's doc (spec-refine: `docs/specs` · the three plan flows: `docs/plans` · quick: **none** — it never touches `docs/`). No loop **graduates/promotes artifacts** into `docs/`: migrations → `docs/scripts`, manuals → `docs/manuals`, diagrams → `docs/diagrams` are done by the separate **`export-*`** skills, as an explicit later step; artifacts stay in their sessions until then. A task that creates a tool/utility has it documented in `docs/tools` by the ambient `creating-tools` skill (auto-discovered; Workline does not bind it).
+A loop writes into `docs/` **only** its own flow's doc plus, when it composes a capability whose own deliverable is a `docs/` category, that category — today only the **UI Design Package** under `docs/designs` (`design`). Which folders that is per flow, and refusing any delegated step whose target leaves them, is the CLI's. **Published, never graduated**: the test is the origin, not the folder. No loop **graduates/promotes artifacts** into `docs/`: migrations → `docs/scripts`, manuals → `docs/manuals`, diagrams → `docs/diagrams` are done by the separate **`export-*`** skills, as an explicit later step; artifacts stay in their sessions until then. A task that creates a tool/utility has it documented in `docs/tools` by the ambient `creating-tools` skill (auto-discovered; Workline does not bind it).
 
 ## Conditional modules