@tacuchi/agent-workflow-cli 20.25.0 → 21.0.0

package/skills/w/harness/HARNESS.md

@@ -34,7 +34,7 @@ The capabilities the harness layer depends on, with their universal fallback (wh
 |---|---|---|
 | **command-invocation** | the user triggers a flow by name (`spec-new`, `plan-exec`, …) | the user writes "run the `<cmd>` procedure" and the AI reads its doc |
 | **procedure-loading** | load a loop's/command's doctrine | the AI **reads the `.md`** of the loop and follows it (read-and-follow) |
-| **structured-choice** | ask the human ≤3 content questions **+ always** a `flow` control (`Compactar`/`Cerrar`) through a side channel | a **numbered markdown** question in chat; the `flow` control is offered as one more option |
+| **structured-choice** | ask the human ≤3 content questions **+ always** a `flow` control (`Compactar`/`Cerrar`); every option has a semantic label + one-sentence functional explanation/example | **labeled markdown** in chat; answer by label or ratify all first options with `Aceptar recomendaciones` |
 | **compaction** | shrink the context without losing the thread (+ a context-pressure **signal** for the chassis' self-regulation) | write `CHECKPOINT` and ask the user to restart the context and resume (resume keys off `CHECKPOINT`) |
 | **subagent-dispatch** | *(optional)* parallelize research breadth | **inline sequential** research in the same session (the default anyway) |
 | **persistent-context** | the `WORKSPACE` block + conventions always present | the repo's context file (standard **`AGENTS.md`**; `CLAUDE.md` on Claude Code) |
@@ -47,13 +47,13 @@ The capabilities the harness layer depends on, with their universal fallback (wh
 
 ## Harness binding matrix
 
-Concrete mechanism per harness (**Jul-2026**, verified against official docs; `~` partial). Antigravity CLI reuses Gemini's surfaces (`~/.gemini/`); Oz reuses Warp's (they share the **Warp / Oz** column, with MCP via flag — see the note under the matrix).
+Concrete mechanism per harness (matrix base verified **Jul-2026**; the `structured-choice` row was refreshed **Aug-2026** against current official docs/source and local host probes; `~` partial). Antigravity CLI reuses Gemini's surfaces (`~/.gemini/`); Oz reuses Warp's (they share the **Warp / Oz** column, with MCP via flag — see the note under the matrix).
 
 | Capability | Claude Code | Codex | Kimi Code | Gemini / Antigravity | OpenCode | Crush | Warp / Oz | Generic |
 |---|---|---|---|---|---|---|---|---|
 | command-invocation | `.claude/commands/` (slash) | skills only (`$` mention; no commands dir, prompts removed) | skills only, as `/skill:<name>` (no commands dir) | skills only in agy (system slash commands; `.gemini/commands/*.toml` = legacy Gemini CLI) | `.opencode/command/` | `.crush/commands` (palette) + user-invocable skills | skills as `/name` | text |
 | procedure-loading (skills) | `SKILL.md` `.claude/skills` | `SKILL.md` `.agents/skills` | `SKILL.md` `.kimi-code/skills`+`.agents/skills` (user and project tiers) | `SKILL.md` (agentskills) | `SKILL.md` `.opencode`+`.claude`+`.agents` | `SKILL.md` `~/.config/crush`+`.agents`+`.claude` (`.crush/skills` is project-only) | `SKILL.md` `.agents`+`.warp`+`.claude` | read-and-follow `.md` |
-| structured-choice | `AskUserQuestion` (**main-agent only**) | — | — | — | — | — | — | numbered markdown |
+| structured-choice | `AskUserQuestion` (**main-agent only**; 1–4 questions, 2–4 options; label + description) | `request_user_input` when exposed (~; 1–3 questions, 2–3 options; label + description) | `AskUserQuestion` (1–4 questions, 2–4 options; label + description; failure → text) | `ask_user` (Gemini: 1–4 questions, 2–4 choice options; label + description) · `AskQuestion` (Antigravity: option text + write-in; public limits undocumented) | `question` (label + description; custom answer; public limits undocumented) | `question` (≤5 questions, ≤5 choices; descriptions + fill-in) | no documented structured-choice surface → labeled markdown | labeled markdown (label + sentence) |
 | compaction | `/compact` | Pre/PostCompact hooks | `/compact` + Pre/PostCompact hooks | ~ | `session.compacted` | ~ | ~ | CHECKPOINT + resume |
 | subagent-dispatch | `Task` (parallel) | `SubagentStart` / agents | sub-agents (`SubagentStart`/`SubagentStop`) | agents (`.gemini/agents`) | `.opencode/agent/*.md` | ~ | ~ (cloud agents) | inline |
 | persistent-context | `CLAUDE.md` (does **not** read AGENTS.md → symlink) | `AGENTS.md` | `AGENTS.md` (hierarchical) | `GEMINI.md` + `AGENTS.md` | `AGENTS.md` | `CRUSH.md` + `AGENTS.md` | `AGENTS.md` (auto) | `AGENTS.md` |
@@ -65,9 +65,13 @@ Concrete mechanism per harness (**Jul-2026**, verified against official docs; `~
 
 > **Kimi Code caveats** (verified 2026-07-29 vs the shipped v0.29.2 binary + live probes): it exports **no env markers** to its subprocesses, so `aw harness` legitimately answers `unknown` inside it and detection goes through binary + config dir. Its hooks live **only** in the user-global `config.toml` — there is no project-level config — and their schema is `event`/`matcher`/`command`/`timeout`, so the bundled JSON template is *transformed*, not copied: `type: "prompt"` hooks cannot be expressed and are reported as skipped, and matchers are carried only for the tool-name events.
 
-> **Notes (field research Jul-2026):** **`SKILL.md` skills** are the **universal** portable unit — **every harness in the matrix** supports them (Codex added them Dec-2025; **`.agents/skills` is the cross-host anchor**, read by Codex/OpenCode/Crush/Warp/Oz/**Kimi Code** — every host except Claude Code, which reads only `.claude/skills`). **Structured choice** (`AskUserQuestion`) remains **Claude Code / main-agent only** → elsewhere `structured-choice` degrades to numbered markdown. The **enforcement layer** (new row) is **NO longer Claude-exclusive**: Codex + Gemini use a near-identical protocol (`permissionDecision:deny` / exit 2) and OpenCode blocks via `throw` in a JS plugin; Crush/Warp only offer **coarse** allow/deny (no custom per-command logic) → there, conventions stay **advisory** + allow/deny lists. Enforced **plan mode** is never trusted for safety; git-safe (invariant #5) is our own — though a host-planner's *output* (the plan it built) is adoptable input (`../commands/plan-new.md` § *Input resolution*, mode 4). **MCP** is universal (each host its file/key). The **guaranteed floor** (last column) runs the full model.
+> **Notes (field research Aug-2026):** **`SKILL.md` skills** are the **universal** portable unit — **every harness in the matrix** supports them (Codex added them Dec-2025; **`.agents/skills` is the cross-host anchor**, read by Codex/OpenCode/Crush/Warp/Oz/**Kimi Code** — every host except Claude Code, which reads only `.claude/skills`). The **enforcement layer** is **not Claude-exclusive**: Codex + Gemini use a near-identical protocol (`permissionDecision:deny` / exit 2) and OpenCode blocks via `throw` in a JS plugin; Crush/Warp only offer **coarse** allow/deny (no custom per-command logic) → there, conventions stay **advisory** + allow/deny lists. Enforced **plan mode** is never trusted for safety; git-safe (invariant #5) is our own — though a host-planner's *output* (the plan it built) is adoptable input (`../commands/plan-new.md` § *Input resolution*, mode 4). **MCP** is universal (each host its file/key). The **guaranteed floor** (last column) runs the full model.
 
-> **Oz (Warp's cloud sibling).** `oz agent run` is a cloud agent orchestrator that **reuses Warp's surfaces**: same skills (`.agents/skills`, top-level dirs like Warp) and `AGENTS.md`, with `structured-choice` equally degraded to numbered markdown. It differs in three points: **detection** via `OZ_RUN_ID` (takes priority over Warp when both markers coexist); **MCP without a config file** — the JSON is passed via the `--mcp` flag of `oz agent run` (or the `OZ_MCP_CONFIG` env), it never writes `.warp/.mcp.json`; and **no plugin or hooks** (advisory enforcement, like Warp). Hence it shares the **Warp / Oz** column with that MCP caveat.
+> **structured-choice routing.** A native binding qualifies only when the current client exposes it and can display the option's functional sentence without loss. When it has separate fields, map the semantic label and sentence to them; when it exposes one visible option string, render `Label — functional sentence`. Otherwise use labeled markdown. Respect the per-call ceilings in the row and reserve one question slot for `flow`; carry overflow into a later call. If the native tool already injects a custom/free-text option, do not add a duplicate `Other` option.
+
+> **structured-choice evidence (checked 2026-08-02):** [Claude Code](https://code.claude.com/docs/en/agent-sdk/user-input) · [Codex App Server](https://learn.chatgpt.com/docs/app-server.md) · [Kimi Code](https://moonshotai.github.io/kimi-code/en/reference/tools.html) · [Gemini CLI](https://geminicli.com/docs/tools/ask-user/) · [Antigravity changelog](https://github.com/google-antigravity/antigravity-cli/blob/main/CHANGELOG.md) · [OpenCode](https://dev.opencode.ai/docs/tools/) · [Crush source](https://github.com/charmbracelet/crush) · [Warp agents](https://docs.warp.dev/agent-platform/getting-started/agents-in-warp) / [Oz CLI](https://docs.warp.dev/reference/cli). Public docs do not expose Antigravity's full question schema or a dedicated Warp/Oz structured-choice schema; the row says so instead of inferring one.
+
+> **Oz (Warp's cloud sibling).** `oz agent run` is a cloud agent orchestrator that **reuses Warp's surfaces**: same skills (`.agents/skills`, top-level dirs like Warp) and `AGENTS.md`. No dedicated structured-choice schema is documented for Oz itself, so a direct Oz run uses labeled markdown; if Oz delegates to another harness and exposes that harness's native question surface, follow that harness's own binding. Oz differs from Warp in three points: **detection** via `OZ_RUN_ID` (takes priority over Warp when both markers coexist); **MCP without a config file** — the JSON is passed via the `--mcp` flag of `oz agent run` (or the `OZ_MCP_CONFIG` env), it never writes `.warp/.mcp.json`; and **no plugin or hooks** (advisory enforcement, like Warp). Hence it shares the **Warp / Oz** column with those caveats.
 
 > **compaction (signal & self-regulation).** The chassis' *Self-regulation (proactive compaction)* doctrine (`../modules/COMPACTION.md`, loaded under the `compaction` signal) needs two per-host facts: the **context-pressure signal** (does the host surface one the agent can read?) and **`auto`-mode viability** (can compaction fire **without user interaction**?). Claude Code: the signal is the harness' own context warnings; `/compact` is user-invoked — the agent cannot run it itself, so `auto` **degrades to `confirm`** there (the native auto-compact is already cushioned by the PreCompact/PostCompact hooks: checkpoint-write + resume-summary). Hosts with compaction hooks/events (Codex Pre/PostCompact, OpenCode `session.compacted`) cushion resume the same way; hosts with neither signal nor mechanism run the universal fallback (CHECKPOINT + restart + resume) and `auto` likewise degrades. Mode semantics (`[compaction]` config, default, consent): the chassis' subsection — single source.
 
@@ -85,8 +89,8 @@ Concrete mechanism per harness (**Jul-2026**, verified against official docs; `~
 ## Convention for the rest of the corpus
 
 - Loops/commands reference the **capability** by name (e.g. "*structured-choice* (see `harness/HARNESS.md`)"), **never** the concrete tool.
-- The historical name `AskUserQuestion` survives **only** as the Claude-Code binding of `structured-choice` (this table), never as doctrine vocabulary.
-- The `flow` lifecycle control (`Compactar`/`Cerrar`) belongs to the `structured-choice` capability, not to a tool: on harnesses without structured choice it is offered as one more textual option.
+- Concrete tool names survive **only** as per-host bindings in this document, never as doctrine vocabulary.
+- The `flow` lifecycle control (`Compactar`/`Cerrar`) belongs to the `structured-choice` capability, not to a tool: a required native field adds neutral `Continuar`; the text fallback leaves flow optional.
 
 ## Distribution (install-time)
 
@@ -94,7 +98,7 @@ Proven pattern (Spec Kit, 30+ agents): **one canonical source** + generate/symli
 
 ## Command packaging (harness-specific)
 
-Each command's **contract** (Flow, Trigger, Input, Mode, …) is agnostic. The **file** the harness executes wraps that contract in its native format — the installer (`aw self install-skill`) emits the right wrapper per host:
+Each command's **contract** (Flow, Trigger, Input, Mode, …) is agnostic. The **file** the harness executes wraps that contract in its native format — the installer (`aw self install-skill`) emits the right wrapper per host, retargets bundle-relative links to that host's installed `skills/w` directory and materializes the authored `${CLAUDE_PLUGIN_ROOT}/skills/w` token to the same absolute bundle for `aw context-plan --root`. Claude's plugin surface expands that token natively; installed wrappers never rely on the CLI's potentially different packaged copy:
 
 | Host | Wrapper installed | Invoked as |
 |---|---|---|
@@ -110,8 +114,8 @@ Each command's **contract** (Flow, Trigger, Input, Mode, …) is agnostic. The *
 
 ## Status
 
-Capability model + binding matrix **defined** and **validated** with field research (**Jul-2026**, against official docs and, for Kimi Code, the shipped binary).
+Capability model + binding matrix **defined** and **validated** with field research (base **Jul-2026**; `structured-choice` refreshed **Aug-2026** against the linked official docs/source and current local probes).
 
-The catalog counts **8 hosts** — `claude-code`, `codex`, `oz`, `warp`, `gemini`, `opencode`, `crush`, `kimi` — each with its own entry in `domain/harnesses.ts`. The columns above group two pairs that share a config surface (Warp/Oz, Gemini/Antigravity), which is a presentation choice, not a second taxonomy: the host set is whatever `HARNESSES` says. The anti-drift guards cover the CODE projections (TUI, install targets, doctor, detection) — this table is prose and no test reads it, so it is kept in step by review, not by a check. Support levels: **official** — Claude Code, Codex, Warp, Gemini/Antigravity, Kimi Code; **best-effort** — Oz, OpenCode, Crush. `agents` (`~/.agents/skills`) is a **shared destination**, never a host.
+The catalog counts **8 hosts** — `claude-code`, `codex`, `oz`, `warp`, `gemini`, `opencode`, `crush`, `kimi` — each with its own entry in `domain/harnesses.ts`. The columns above group two pairs that share a config surface (Warp/Oz, Gemini/Antigravity), which is a presentation choice, not a second taxonomy: the host set is whatever `HARNESSES` says. Anti-drift guards cover the CODE projections (TUI, install targets, doctor, detection); `chassis-consistency.test.ts` additionally parses the `structured-choice` row and asserts every host binding or explicit limitation. Support levels: **official** — Claude Code, Codex, Warp, Gemini/Antigravity, Kimi Code; **best-effort** — Oz, OpenCode, Crush. `agents` (`~/.agents/skills`) is a **shared destination**, never a host.
 
 All support `SKILL.md` (anchor `.agents/skills`) + MCP + `AGENTS.md`; deterministic enforcement on Claude/Codex/Kimi/Gemini/OpenCode, advisory + coarse allow/deny on Crush/Warp/Oz. The CLI (`aw`) implements the registry (`domain/harnesses.ts`), the per-host MCP writers, `detect-hosts` and `install-skill --target <host>`. The universal floor (`AGENTS.md` + text + files + skills) runs the full model today.

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
@@ -105,14 +105,15 @@ Investigation is **inline**: an activity **inside the run's current session**, n
 
 ## Structured-choice (design & batching)
 
-**Canonical rule (single source — the rest of the corpus only references it):** *structured-choice* = **≤3 content questions + 1 `flow` control**, always. Per-harness binding in [`../harness/HARNESS.md`](../harness/HARNESS.md) (Claude Code: `AskUserQuestion`, max 4 questions/call; without structured choice it degrades to **numbered markdown**).
+**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.
 
-- **`flow` control** (lifecycle, always present): `Compactar` | `Cerrar`. Answering only the content questions = keep iterating. Under context pressure the loop **raises the choice itself**, with `Compactar` recommended.
-- **Content questions** are: human doubts (non-factual gaps) · MCP choice (DB rule), before running queries · at **convergence**, the loop's own closing action — each heir defines it in its *Convergence / exit* (e.g. `Guardar especificación refinada` · `Cerrar tarea`) — | `Preguntar algo más`.
-- **Batching**: up to 3 human gaps per call; with more pending, prioritize the ones that unblock others and defer the rest.
-- **Recommended answer per question**: every content question **always** carries the AI's recommended answer — the first option, marked *recommended*. Never ask "cold": the human ratifies or corrects a proposal, never starts from zero. The recommendation comes from what was researched (ask-vs-research rule), never from an empty default.
+- **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`.
+- **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.
+- **Text fallback:** answer by label; `Aceptar recomendaciones` accepts all first options. Never require composite coordinates such as `1A, 2A, 3A`.
 
-> **Label language:** the literal option labels (`Compactar`, `Cerrar`, `Guardar plan`, …) are **canonical product strings** — present them **verbatim**. All other user-facing output follows [`../SKILL.md`](../SKILL.md) § *Language policy*.
+> Canonical labels (`Continuar`, `Compactar`, `Cerrar`, `Aceptar recomendaciones`, `Guardar plan`, …) stay verbatim; other user-facing text follows [`SKILL.md`](../SKILL.md) § *Language policy*.
 
 ## Compact / resume
 
@@ -133,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)
 

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

@@ -2,12 +2,10 @@
 name: plan-exec-loop
 description: >-
   Executes an implementation plan (docs/plans/PPP-plan-<slug>.md) as a living
-  doc: runs it phase by phase — each phase a verifiable state — while editing
-  the real code and managing DB and git. Heir of the chassis (loops/CHASSIS.md
-  + CODE-POLICIES.md). Deltas: executability entry gate, deviation gate
-  (structural to plan-refine, functional to spec-refine), single resumable
-  session, safe git, DB scripts-only, phase proof plus progressive tests,
-  pre-commit closing review gate, no auto-export. Composes git and sql.
+  doc: re-infers isolated or continuous phase batches, edits real code, then
+  validates/reviews/commits each effective batch. Heir of CHASSIS.md and
+  CODE-POLICIES.md. Keeps the executability and deviation gates, one resumable
+  session, safe git, DB scripts-only and no auto-export. Composes git and sql.
   Started by /w:plan-exec. Invoke to implement an already generated plan.
 ---
 
@@ -25,7 +23,7 @@ PLAN
 `/w:plan-exec` — **resumable** (same chassis mechanism; here resume keys off the plan-doc phase states + checkboxes + CHECKPOINT, see Delta 1).
 
 ## Reads
-`docs/plans/PPP-plan-<slug>.md` (locate via the `docs/plans/PPP-plan-*.md` glob or the exact path from the command argument) **and its source spec** (resolved through the plan's `## Origin`) — the entry gate reads both. It runs **any** plan, whether or not it passed through [`plan-refine-loop`](../plan-refine-loop/LOOP.md) — plan-refine is auxiliary, not mandatory; no gate requires it. What it does require is an **executable shape** (§ *Entry gate — executability*). If the plan includes UI, it also reads the **design SPECs** (`NNN-SPEC-<SLUG>.md`) its Tasks reference — artifacts of the plan-new/plan-refine session, read **read-only** as the design reference while implementing (see [`SPEC.md`](../../artifacts/artifacts-design/SPEC.md)).
+`docs/plans/PPP-plan-<slug>.md` (locate via the `docs/plans/PPP-plan-*.md` glob or the exact path from the command argument) **and its source spec** (resolved through the plan's `## Origin`) — the entry gate reads both. It runs **any** plan, whether or not it passed through [`plan-refine-loop`](../plan-refine-loop/LOOP.md) — plan-refine is auxiliary, not mandatory; no gate requires it. What it does require is an **executable shape** (§ *Entry gate — executability*). If the plan pins design, it also reads the **UI Design Package** revisions its `## Design references` and its tasks name — **read-only**, at the exact revision each one fixed (§ *Design precondition gate*).
 
 ## Writes
 - `docs/plans/PPP-plan-<slug>.md` (**read/update**, living doc: phase/task state, `Open questions`).
@@ -40,6 +38,10 @@ Full rule in the chassis (§ *docs/ boundary — no auto-export*). Here: the onl
 
 Read **[`../CHASSIS.md`](../CHASSIS.md)** — the loop's **full engine** — **and** **[`../CODE-POLICIES.md`](../CODE-POLICIES.md)** — the *code-editing loop policies* — **always before** these deltas. *(If `../` does not resolve: same names next to this file — global layout rule, chassis § Reference resolution.)*
 
+Read the shared execution-unit contract in
+[`PLAN-EXECUTION-BATCHES`](../../modules/PLAN-EXECUTION-BATCHES.md); it owns batch syntax,
+inference, the deferred-validation cycle and conditional Git authorization.
+
 ## Composes
 
 `git` (safe branch + proposed commits) · `sql` (DB rule). Both resolved via `.workflow/skills.toml`; `off` → the loop continues without the capability and, if it was needed, says so or asks.
@@ -72,20 +74,64 @@ Execution **no longer accepts in silence** a plan that would force it to invent
 
 > The gate reads the **canonical phase contract** from [`plan-new-loop`](../plan-new-loop/LOOP.md) § *Phase contract (canonical)* — required sections, the `> Estado:` vocabulary, semantic granularity. Execution references it; it never redefines it. The marker is a **line of its own** inside the `### Fn` block (`> Estado: <value>`); written any other way it reads as `pendiente`.
 
-## Delta 1 — One session per run; the phase cycle in the plan-doc
-
-- Walks the plan's `### Fn` blocks under `## Tasks` in order (respecting deps) **inside the run's single session** (no session-per-phase). *(Legacy plans: a separate `## Phases` table — walk it the same way.)*
-- **Phase cycle** (artifact-first, one per `### Fn`): read `Resultado` + `Condición de salida` → confirm the initial state → flip `> Estado: en ejecución` and seed `CHECKPOINT.Next` → execute its tasks → run the phase proof plus the justified focused tests (Delta 4). Then: closing review gate over the phase's whole diff (Delta 5) → confirm the `Condición de salida` → flip `> Estado: validada` → update `CHECKPOINT` and propose commits (Delta 2).
+After this gate and before editing, infer the effective batches over pending phases. The live
+checkout may merge or split the plan's declaration without consent; record the result and drift in
+`CHECKPOINT`. A missing `## Execution batches` is legacy compatibility, not an entry gap.
+
+## Design precondition gate (fail-closed, per task)
+
+Applies **only** to a task that pins design (`DES-001@r4 / SCR-002@r2#empty`). Run
+`aw designs --plan <plan-doc>` before implementing the batch; it answers per task
+and the verdict is the command's, not the implementer's.
+
+**Four causes block, and each names the artifact and the corrective action:** the
+reference does not resolve · its digest no longer matches the bytes · the revision
+is **revoked** · the applicable **closure** does not reach `handoff`. A blocked
+task is not implemented, its phase stays `en ejecución` or `bloqueada`, and the
+correction goes to `/w:plan-refine` — or to `/w:spec-refine` when it changes
+behavior or acceptance.
+
+**One cause only warns:** a revision **superseded** by a newer one but intact
+stays executable. Publishing `@r5` never invalidates the `@r4` a task pinned on
+purpose; only an explicit, audited revocation does. A **stale path hint** warns
+the same way — identity resolved, the recorded path moved.
+
+> **`plan-exec` never redesigns.** Completing an `outline` artifact, inventing a
+> missing state or promoting a revision to `handoff` are design decisions and
+> belong to the refine that owns them. Full contract in
+> [`DESIGN-REFERENCES.md`](../../modules/DESIGN-REFERENCES.md) (signal `ui`).
+
+**Publishing a document together with a package revision is one transition.** A
+spec or plan whose reference moves is written in the **same** all-or-nothing batch
+as the revision it points at, so no reader ever sees a document citing a baseline
+that is not there, or a revision no document reached. An effect the batch cannot
+cover — anything outside the workspace files — is recorded as **pending
+reconciliation** in `CHECKPOINT`, never reported as published.
+
+## Delta 1 — One session per run; execution-unit cycle in the plan-doc
+
+- Walk the plan's `### Fn` blocks under `## Tasks` in dependency order inside one session. Infer
+  effective `continuous`/`isolated` batches first; legacy `## Phases` tables degrade the same way.
+- **Execution-unit cycle:** seed one batch intent; implement all its phases in order; validate and
+  review at unit close; then update states/`CHECKPOINT` and enter Git. An isolated unit contains
+  one phase. A continuous unit follows `PLAN-EXECUTION-BATCHES`: no proof, runner, build, lint,
+  review or commit between its phases.
 - Executes the phase's tasks; **skips** the ones already `- [x]` in the plan (the plan-doc is the per-task source of truth). **Micro steps stay internal** (canonical contract): they reach `CHECKPOINT` only when a resume needs them, never the plan.
-- **Marking order (hard rule):** a task is marked `- [x]` when its local work is finished. A phase reaches `validada` **only** when its primary proof **ran and passed**, the needed focused checks passed, its `Condición de salida` is true, the review gate is green and every remaining review finding is explicitly deferred — a blocker is never deferred into `validada`. **Never** because all its checkboxes are ticked.
+- **Marking order (hard rule):** mark a task when its local work finishes and each reached phase
+  `en ejecución`. After the whole unit is green, flip all its phases to `validada`. Each still
+  requires its proof, focused checks, exit condition and the combined review;
+  a blocker is never deferred into `validada`. **Never** because all its checkboxes are ticked.
 - **Intermediate states:** `bloqueada` = the phase is stopped on a live blocker — recorded in `CHECKPOINT` + the plan's `## Open questions`, back to `en ejecución` when it clears; it counts as **not validated**. A phase whose work is complete but whose operative check the AI **cannot run** (an unapplied migration — Delta 3) **stays `bloqueada`**: its finished tasks keep their boxes ticked, and the reason goes on its own `> Bloqueo:` line, dropped when the blocker clears. It counts as **not validated** until the check runs and passes. Never a silent `validada`.
 - **A blocker without a reason is not a blocker (hard rule).** Writing `> Estado: bloqueada` **always** writes its `> Bloqueo:` line in the same edit: a state that says "stopped" without saying on what is a dead end for whoever reads `aw status` next. The runtime tolerates a legacy block that states none (`blocker: null`) — this loop never produces one. `CHECKPOINT.Next` names **the action that unblocks it** ("apply migration 014, then re-run the persistence proof"), never the state it is in.
 - **Plan-doc residue (hard rule):** execution writes into the plan-doc **only** five things — checkbox flips (`- [ ]` → `- [x]`), the phase's own `> Estado:` line, its `> Bloqueo:` line while blocked, deferrals appended to its `## Open questions`, and the plan's own status mark (its `> Estado:` line and, on close, its `> Cierre:` line — Delta 6). The declared-gap hatch is Deltas 4, 5 and 7. Per-phase results, review-gate findings and metrics go to the session's `DECISION`/`CHECKPOINT` — **never** into the plan-doc. Phase blocks are updated **in place — NEVER append a duplicate `### Fn` block** (same contract as CHECKPOINT sections). The entry gate's consented normalization is the single exception, and it lands before execution starts.
-- **CHECKPOINT per phase:** on closing a phase record the **functional state reached**, the simulation boundary in force **only when the change carries one**, the tests run and their result, the non-obvious decisions, the deferrals and the next state being pursued. Enumerating every file touched is not required unless it helps a resume.
+- **CHECKPOINT per execution unit:** record its effective grouping, functional states, simulation
+  boundary when applicable, checks/results, decisions, deferrals and next intent. The task boxes
+  and `en ejecución` marks preserve an intra-batch resume.
 - Records in `DECISION` only the **non-obvious**, **as it is decided** (per-phase decisions accumulate in the SINGLE `DECISION`, tagged by phase/task — e.g. `Origin: T2 (F1)`). A structural deviation is **not** settled with an entry there (§ *Deviation gate*).
 - The chassis **gap-driven** engine applies here **inside a task**: facing a non-obvious decision/doubt → inline research, a probe (Delta 7) OR structured-choice.
 
-> **Legacy plans degrade safely.** `plan-exec` still runs plans with `### Fn` blocks, `- [ ]` tasks, legacy sections and **no** `> Estado:` line: a missing line reads `pendiente`, and nothing is back-filled. A plan with every box ticked is **not** validated by that fact — the session (`CHECKPOINT`, review gate) decides. What is genuinely missing is closed by the entry gate or by `plan-refine`, never assumed.
+> **Legacy plans degrade safely:** a missing line reads `pendiente`; missing execution batches are
+> inferred into `CHECKPOINT`; neither is back-filled. Checked boxes alone prove nothing.
 
 ## Deviation gate
 
@@ -108,7 +154,10 @@ On either return path: `CHECKPOINT` records the state reached and the trigger, t
 
 ## Delta 2 — Git policy: **safe branch + proposed commits**
 
-Full policy in [`../CODE-POLICIES.md`](../CODE-POLICIES.md) (§ *Safe git*: branch-check before editing, rejected commit — changes stay + get recorded —, working-tree precondition between phases). **Inline:** before editing, verify each source's expected branch (`aw check-branch --source <alias>`; on mismatch → pause and resolve with the human); at each phase close and **after the review gate** (Delta 5), **proposed commits per source** (approve first) — never `push`/`--amend`/`--no-verify`.
+Full policy in [`../CODE-POLICIES.md`](../CODE-POLICIES.md). Inline: branch-check every source
+before the unit; after its green review, produce exactly one proposed commit per affected source.
+Use one consolidated approval, or the explicit conditional pre-authorization already recorded in
+`CHECKPOINT`. Never `push`/`--amend`/`--no-verify`.
 
 ## Delta 4 — Validation: phase proof + progressive tests
 
@@ -117,7 +166,12 @@ Full policy in [`../CODE-POLICIES.md`](../CODE-POLICIES.md) (§ *Safe git*: bran
   2. **focused tests** — added when the layer carries its own rules, a relevant transformation, error handling, persistence, transactions, temporal logic or external integration;
   3. **risk tests** — security, concurrency, idempotency, retries, known regressions.
 - **One vertical proof per operation while wiring** (request → controller → use case → repository → fake or stub → expected response): it demonstrates the path once instead of re-asserting the same happy path at every layer. Trivial mappers, plain DTOs and framework behavior get no dedicated test.
-- Compatible with **TDD without a test per method**: the evidence may be written before, during or after the phase's code. What is mandatory is that the `Condición de salida` be demonstrated **before** the phase is flipped to `validada`.
+- `isolated` remains compatible with literal TDD. A continuous batch may author evidence before
+  code, but first runs it at batch close. No phase becomes `validada` before its exit is demonstrated.
+- **Continuous means all checks at batch close.** Do not run its phase proofs, focused/risk tests,
+  build, typecheck, lint or review while implementing internal phases. At close run proofs in phase
+  order, then the justified checks and cross-cutting validations. `isolated` runs the same stack for
+  its single phase.
 - Each added test is re-weighed at the closing review gate ([`../CODE-POLICIES.md`](../CODE-POLICIES.md) § *Closing review gate* → *Test-value lens*, tag `overtest`): over-testing is a **finding to fix or justify**, never an automatic rejection.
 - Also run the plan's `## Validations` (cross-cutting rules and constraints) + the Final behavior block of `## Solution` (legacy plans: the `## Final behavior` section) + the spec's acceptance/success criteria (its `## Scenarios`, if present, are ready-made test cases: GIVEN=arrange · WHEN=act · THEN=assert).
 - A validation that **runs and fails** → back into the phase (gap): no advancing, no `validada`.
@@ -127,13 +181,21 @@ Full policy in [`../CODE-POLICIES.md`](../CODE-POLICIES.md) (§ *Safe git*: bran
 
 ## Delta 5 — Closing review gate (conventions, pre-commit)
 
-Full gate in [`../CODE-POLICIES.md`](../CODE-POLICIES.md) (§ *Closing review gate*): **independent** diff re-read + installed ambient conventions + the floor lenses (minimality, **test value**, **temporary simulation**, tooling); findings → fix (re-validating the phase) or defer justified. Here only the exec wiring: it runs over the phase's **whole** diff, **between the phase validation (Delta 4) and its commits (Delta 2)**; only with the gate green is the phase flipped to `validada` and its commits proposed.
+Full gate in [`../CODE-POLICIES.md`](../CODE-POLICIES.md): independent re-read, ambient
+conventions and the floor lenses. It covers the execution unit's **whole** diff after every phase
+proof/check and before states or Git advance. Findings are fixed and the affected checks rerun, or
+deferred with justification when they are not blockers.
 
 ## Delta 6 — Completion / close
 
-- A phase closes when its `> Estado:` reads `validada`: work done, `Condición de salida` true, proof **run and passed**. A proof still waiting on an operative handoff leaves it `bloqueada`.
+- A phase closes when its `> Estado:` reads `validada`: work done, exit condition true and proof
+  passed. In a continuous batch every phase waits for the batch review; an operative handoff leaves
+  the affected phase `bloqueada` and the unit uncommitted.
 - **The plan's own state is the third axis, and it stays `open` during the whole run.** Every phase `validada` is **not** the plan closed: the final validation still has to run. Keep `> Estado: open` under the title while executing — stamping it on the first write if the plan carries none — and never write `done` from the counters — a legacy plan with every box ticked is not closed by that fact (§ *Legacy plans degrade safely*).
-- **Every phase `validada` + the final validation passed** → final *structured-choice* (content: `Marcar plan done` / `Preguntar algo más`; flow: `Compactar`/`Cerrar`). `Marcar plan done` is offered under no other condition: one `bloqueada` phase keeps the plan open, however many of its tasks are ticked.
+- **Every phase `validada` + final validation passed** unlocks completion.
+  `Marcar plan done` is offered under no other condition. On the last batch, its one consolidated Git approval also authorizes
+  this mark before committing, so the status write lands in the same source commit. Explicit
+  green-commit pre-authorization applies it without another question.
 - **Marking done = ONE status line in the plan-doc**, under the title's blockquote: `> Estado: done`, updated in place on a re-run. The machine value **stands alone** — the date and session go on their own `> Cierre: YYYY-MM-DD · sesión NNN` line right under it, for the same reason a blocker never rides on a phase's state line. It never replaces the per-phase lines inside the `### Fn` blocks — position tells the two apart. No per-phase result tables, no ✅ suffixes — that record lives in the session (`DECISION`/`CHECKPOINT`).
 - **Legacy status line, migrated on write.** A plan carrying the old single-line form (`> Estado: done — YYYY-MM-DD · sesión NNN`) is still **read** as closed; the first time this loop legitimately writes that document, it is rewritten to the two-line form. Compatibility is for reading old plans — every new write uses the normalized contract.
 - **No automatic export**: the artifacts (`SCRIPTS.sql`, `DECISION`, …) stay in the session. Promoting them to `docs/` (scripts, manuals, …) is a separate step via `export-*`.
@@ -147,54 +209,58 @@ plan-exec-loop(PPP-plan-<slug>.md):
   entry gate (executability): result · exit condition · phase proof · simulation boundary if any · no structural contradiction
       minor gap      → structured-choice [Normalizar y ejecutar | Ir a plan-refine] → normalize in place + DECISION
       structural gap → CHECKPOINT(blocker) → hand off to /w:plan-refine → stop
-  for each Phase (### Fn block in ## Tasks; legacy: ## Phases table) in plan (in order, respecting deps):
-    if Estado == validada: skip                            # legacy (no line): all its Tasks - [x] AND the session shows it closed
-    read Resultado + Condición de salida; confirm the initial state
-    set > Estado: en ejecución
-    seed CHECKPOINT.Next = Phase N (Pending = its Tasks)   # BEFORE starting the phase: seed the intent (artifact-first)
-    for each Task of the Phase:
-      if Task - [x] in the plan: skip                      # intra-phase resume by checkbox
-      verify each source's expected branch (branch-check)
-        on mismatch → pause + resolve with the human
-      execute Task (micro steps internal — never plan entries):
-        edit code in the sources (minimal change)
-        if it creates a tool/utility → the ambient creating-tools skill documents it in docs/tools
-        if read-only DB query → SCRIPTS.sql + execute read-only
-        if DB change (DDL/DML) → draft in SCRIPTS.sql (session artifact, DO NOT execute)
-        deviation gate:
-            local decision       → resolve; DECISION only if non-obvious (tagged by phase/task)
-            structural deviation → CHECKPOINT(state + trigger) → stop → /w:plan-refine
-            functional change    → CHECKPOINT(state + trigger) → stop → /w:spec-refine
-        if probe (PoC) task / runnable doubt → seed check → run throwaway code in the
-            session folder → verdict → CONCLUSIONS/DECISION; failed → structured-choice (Delta 7)
-        if doubt/gap → inline research, probe OR structured-choice   # chassis
-      mark Task - [x] IN THE PLAN                          # AFTER its local work; checkbox flip ONLY — results go to DECISION/CHECKPOINT
-    phase proof (Validación de fase) + the justified focused tests:   # Delta 4 levels 1→3
-        what runs and fails → back into the phase (no validada)
-        what cannot run (unapplied migration) → defer the CHECK, never the validation: the phase stays bloqueada
-    closing review gate (pre-commit):                      # Delta 5: CHECKPOINT.Next = "review phase N"
-        INDEPENDENT re-read of the WHOLE phase diff + installed ambient conventions
-        + floor lenses: minimality · test value (overtest) · temporary simulation · tooling
-        findings → fix (and re-validate the phase) OR defer justified (Open questions + BACKLOG)
-    confirm the Condición de salida → set > Estado: validada  # ONLY with the proof run and passed; NEVER from the checkboxes alone
-        blocker still live       → set > Estado: bloqueada + > Bloqueo: <reason> + CHECKPOINT + Open questions
-        check not runnable (SQL) → set > Estado: bloqueada + > Bloqueo: <reason> + CHECKPOINT + Open questions + BACKLOG
-    update CHECKPOINT (functional state reached · simulation boundary if any · tests + result · decisions · deferrals · next state)
-    propose commit(s) per source (approve first)           # never push/amend/--no-verify; only after the gate is green
-        if rejected → changes stay; record "phase uncommitted"
-    next-phase precondition: working tree clean or acknowledged
-  final validation (whatever can run; a deferred check keeps its phase bloqueada)
-  if every phase validada AND the final validation passed:
-    structured_choice(content: [Marcar plan done, Preguntar algo más], flow: [Compactar, Cerrar])
-    mark plan done → > Estado: done + > Cierre: YYYY-MM-DD · sesión NNN under the title (Delta 6), in place
-  else: the plan-level > Estado: stays open → CHECKPOINT.Next = the action that unblocks the phase(s)
+  batches = infer_effective_batches(pending phases, plan + live checkout)
+      may merge/split declared rows without asking; legacy absence is allowed
+      record batches + declaration drift in CHECKPOINT
+  commit_authorization = explicit conditional pre-authorization from the user, if any
+      record it before editing; otherwise approval is deferred to each green batch close
+  for each Batch in batches:
+    verify every affected source's branch; mismatch → stop + human
+    seed CHECKPOINT.Next = Batch Bn (mode + phases + tasks)
+    for each Phase in Batch:
+      if Estado == validada: skip
+      read Resultado + Condición de salida; set > Estado: en ejecución
+      for each pending Task:
+        execute minimal work; keep DB/tool policies; apply deviation gate
+          local decision → resolve; DECISION only if non-obvious
+          structural/functional deviation → CHECKPOINT + stop → refine destination
+          probe whose verdict shapes later work → batch was ineligible; stop/re-infer
+        mark Task - [x] after its local work
+      # continuous: advance directly to the next phase; run NO validation/review/commit here
+    at Batch close, in phase order:
+      run every Validación de fase, then justified focused/risk checks
+      run applicable plan Validations; last Batch also runs final validation before Git
+      failures → fix + rerun affected checks
+      unrun operative check → phase bloqueada + > Bloqueo: + CHECKPOINT + Open questions
+    closing review gate over the WHOLE BATCH diff
+      findings → fix + rerun affected checks OR defer justified if non-blocking
+    if any proof/check/review/exit condition is not green:
+      preserve actual states + combined uncommitted diff; record unblocking action; stop
+    set every Batch phase > Estado: validada; update CHECKPOINT
+    prepare exactly one commit per affected source
+      if last Batch + final validation green:
+        pre-authorized → mark plan done, then commit once per affected source without asking
+        otherwise → structured_choice(content: [Marcar plan done, Preguntar algo más], flow: [Compactar, Cerrar])
+          Marcar plan done → approve; mark done; commit all source changes once
+      else if pre-authorized → commit without another question
+      else → one consolidated approval for all source commits
+      rejected → changes stay; record "batch uncommitted"
+    next-batch precondition: working trees clean or acknowledged
+  if no Batch ran and phases are already validada:
+    run final validation now
+    if green:
+      use the same pre-authorized/final structured-choice completion branch
+      when authorized → mark plan done with > Estado: done + > Cierre: YYYY-MM-DD · sesión NNN under the title (Delta 6), then commit that source once
+  if plan is not done:
+    the plan-level > Estado: stays open → CHECKPOINT.Next = the action that unblocks the phase(s)
   # NO export: artifacts stay in the session; a separate export-* promotes them
 finalize: CHECKPOINT (+ BACKLOG if something is deferred) + close session + report
 ```
 
 ## Convergence / exit
 
-- **Every phase `validada`** + final validation **run and passed** + **every phase passed its closing review gate** before committing → `Marcar plan done`. A phase left `pendiente`, `en ejecución` or `bloqueada` keeps the plan open, whatever its checkboxes say — a proof waiting on an operative handoff (an unapplied migration) is exactly that case.
+- **Every phase `validada`** + final validation passed + every effective batch reviewed before its
+  commits → `Marcar plan done`. Any pending/running/blocked phase keeps the plan open.
 - A **structural deviation** or a **functional change** exits this loop without converging (§ *Deviation gate*): `CHECKPOINT` + `finalize`, and the work continues in `plan-refine` / `spec-refine`. Same exit when the entry gate finds a structural gap.
 - `Cerrar` (`flow` control, at any time) → `finalize` persists `CHECKPOINT` (and `BACKLOG` only if something remained unexecuted / uncommitted / unapplied), closes the session, reports.
 - Promoting artifacts to `docs/` (via `export-*`) is **always** a later, explicit step outside this loop.