@tacuchi/agent-workflow-cli 20.26.0 → 21.0.0

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.
@@ -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

@@ -53,6 +53,10 @@
           "signal": "db",
           "requires": "external-data"
         },
+        {
+          "path": "modules/DESIGN-REFERENCES.md",
+          "signal": "ui"
+        },
         {
           "path": "modules/COMPACTION.md",
           "signal": "compaction",
@@ -100,6 +104,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 +138,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 +162,7 @@
           "signal": "split"
         },
         {
-          "path": "modules/PLAN-DESIGN-SPECS.md",
+          "path": "modules/DESIGN-REFERENCES.md",
           "signal": "ui"
         },
         {
@@ -185,6 +198,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 +227,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 +270,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 +307,7 @@
           "signal": "simulation"
         },
         {
-          "path": "modules/PLAN-DESIGN-SPECS.md",
+          "path": "modules/DESIGN-REFERENCES.md",
           "signal": "ui"
         },
         {

package/skills/w/loops/CHASSIS.md

@@ -72,7 +72,7 @@ The common cycle — each heir instantiates it in its `## Sequence` with its own
 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`).
+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. `design`).
 5. **Integrate**, update `CHECKPOINT` → repeat.
 
 ## Internal sessions (managed) — one session per run
@@ -134,7 +134,7 @@ Resume **keys off the `CHECKPOINT`** of the run's session, not the existence of
 
 ## 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 (spec-refine: `docs/specs` · the three plan flows: `docs/plans` · quick: **none** — it never touches `docs/`) 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`). **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
 

package/skills/w/loops/CODE-POLICIES.md

@@ -1,17 +1,31 @@
 # CODE-POLICIES — policies for code-editing loops
 
-They apply to **`plan-exec-loop`** (per plan phase) and **`quick-loop`** (the single task; **proportional** gate): each orders this doc read from its `## Inherits`, **together with the chassis** ([`CHASSIS.md`](CHASSIS.md)). The document loops (spec-refine, plan-new, plan-refine) edit no code and do **not** load this doc — that is why it lives apart from the chassis. These policies materialize the **DB scripts-only** and **safe git** invariants — which also stay summarized **inline** (1-2 lines) in each code-editing loop's `LOOP.md`, because advisory hosts do not follow Reads; the full normative text lives here.
+They apply to **`plan-exec-loop`** (per effective batch) and **`quick-loop`** (the single task;
+**proportional** gate): each reads this doc with the chassis. Document loops do not edit code and
+do not load it. These policies own the DB scripts-only, safe Git and closing-review invariants;
+code loops keep only a short inline floor for advisory hosts.
 
 ## Safe git — verified branch + proposed commits
 
-- **Before editing** a source's files: verify current branch = that source's expected branch (`aw check-branch --source <alias>`; see the `git` role). On mismatch → **pause and resolve with the human**; never `stash`/`reset --hard`/`checkout -- .`/`clean` without per-source confirmation.
-- **Proposed commits** (propose-then-execute, approve before): **after the closing review gate passes** (below), propose commits **per source** — in plan-exec at each phase close (or on `Cerrar`); in quick, **a single commit** at the end if there were code changes. Never `push`/`--amend`/`--no-verify`. Nothing reaches a proposed commit without review.
-- **Rejected commit**: the changes **stay in the working tree** (never reverted). Re-proposing / editing the message is allowed. Record in `CHECKPOINT` + `BACKLOG` that the phase/task remained **uncommitted** (resumable).
-- **Between-phase precondition** (plan-exec): `branch-check` validates branch *identity*, **not** working-tree *cleanliness*. Before starting the next phase, each source's working tree must be **clean** (committed) or explicitly **acknowledged** as "uncommitted changes from phase N" — so two phases never co-mingle in one commit.
+- **Before editing** an execution unit's sources, verify every current branch (`aw check-branch
+  --source <alias>`). On mismatch, pause; never destructively clean or switch without confirmation.
+- **Proposed commits:** only after the closing review gate. In plan-exec create exactly one commit
+  per affected source at effective-batch close; in quick, one at task close. Never
+  `push`/`--amend`/`--no-verify`.
+- **Authorization:** default to one consolidated approval for a green batch's source commits. An
+  explicit user pre-authorization conditional on all checks passing is recorded before editing and
+  removes that final question. A failed or unrun check never authorizes a commit.
+- **Rejected commit:** changes stay. Record the execution unit as uncommitted in `CHECKPOINT` and
+  `BACKLOG`.
+- **Between-unit precondition:** each working tree is clean or explicitly acknowledged. A
+  `continuous` batch is the narrow exception that intentionally co-mingles its internal phases in
+  one reviewed commit; no batch may co-mingle with another.
 
 ## Closing review gate (conventions, pre-commit)
 
-After validation (of the phase in plan-exec; of the task in quick, proportional) and **before proposing its commits** (also on an early `Cerrar`, before proposing the pending commits), the diff passes a **closing review gate**:
+After validation and before commits, the whole execution-unit diff passes a **closing review
+gate**: an effective batch in plan-exec, or the proportional task in quick. Early `Cerrar` uses the
+same gate before any pending commit.
 
 - **Independent re-read** of the diff (subagent or clean re-read — the engine's *independent verification*: it does not assume the implementation is correct; *only command output counts*).
 - **Apply the installed ambient conventions** relevant to the touched stack (code/stack standards, security, diff review, the workspace's own families) — the host **auto-discovers them by `description`**. Workline **names and binds no** concrete conventions skill: **it creates the moment; the installed skills fill it** (that is why review is **not a role** — see [`../roles/README.md`](../roles/README.md)). With no convention skills installed → minimal generic checklist: SOLID/early-return, clear names, DRY, no silenced errors, no secrets/PII, parametrized SQL, no dead code, + the plan's `Validations` (if any).
@@ -20,7 +34,8 @@ After validation (of the phase in plan-exec; of the task in quick, proportional)
 - **Temporary simulation check** (only when the change carries one): stubs, fakes and in-memory adapters are **explicit and named as such** (`Stub…` / `Fake…`), they sit at the boundary the plan declares, and no configuration can select them in a production runtime. A simulation still active on the main path with no declared removal is a finding, not a detail.
 - **Tooling check** (`docs/tools`): did the run create **reusable auxiliary tooling** (support scripts/CLIs/generators/reusable configs — not product code, not session probes)? → the host applies the **ambient `creating-tools` skill** (auto-discovered by its `description`; Workline does not bind it) so the tool gets its home under `docs/tools/<slug>/` (README + run/output structure per that skill's contract + its index row). Host without such a skill → the loop still **never writes `docs/tools` itself**: **declare the gap** — the homeless tool goes to the plan's `Open questions` + `BACKLOG` (in quick, `BACKLOG`) — never silent.
 - **Findings**: **fix** them in the working tree and **re-run validation** (the gate does not replace the tests: it re-verifies after fixing), or **defer them justified** (→ the plan's `Open questions` + `BACKLOG`; in quick, `BACKLOG`); the non-obvious → `DECISION`. Gate integrity (see [`CHASSIS.md`](CHASSIS.md) § *Verification-first*): never weaken a check or lower a convention to pass.
-- **Artifact-first + verification-first**: `CHECKPOINT.Next = "review <phase/task>"` before the pass; `SESSION.Success criteria` includes from the start "the diff passed the review gate before its commits".
+- **Artifact-first + verification-first**: seed `CHECKPOINT.Next = "review <batch/task>"`; Success
+  criteria require the whole diff to pass before commits.
 
 Only with the gate green are the commits proposed.
 

package/skills/w/loops/README.md

@@ -47,7 +47,7 @@ The **5 loops** are heirs: they use `## Inherits` (a one-line reference to [`CHA
 
 ## Chassis / heirs
 
-The **engine lives in [`CHASSIS.md`](CHASSIS.md)** (a referenced doc, not a skill); the 5 loops — including `spec-refine-loop` — are **heirs** of that engine. The canonical heirs list and their deltas live in the chassis itself (§ *Heirs*). The chassis is **not a bindable capability**: it is the loop engine; what is pluggable are the **capabilities** a loop composes (e.g. `ui-design`, `sql`, `git`), resolved via `.workflow/skills.toml`.
+The **engine lives in [`CHASSIS.md`](CHASSIS.md)** (a referenced doc, not a skill); the 5 loops — including `spec-refine-loop` — are **heirs** of that engine. The canonical heirs list and their deltas live in the chassis itself (§ *Heirs*). The chassis is **not a bindable capability**: it is the loop engine; what is pluggable are the **capabilities** a loop composes (e.g. `design`, `sql`, `git`), resolved via `.workflow/skills.toml`.
 
 ## Composed capabilities (roles)