@tacuchi/agent-workflow-cli 25.8.0 → 25.9.0

package/skills/w/context/MANIFEST.json

@@ -62,7 +62,7 @@
     "plan.escalation-adopted": "this refine consumed the escalation package an execution handed over, instead of re-deriving its diagnosis",
     "plan.escalation-absent": "no escalation package reached this refine, so it starts from the document alone",
     "chassis.context-pressure": "a fresh reader would need the CHECKPOINT to continue this run",
-    "quick.db-touched": "the task read from or wrote to a database, so there is a statement to derive into the session script"
+    "quick.db-touched": "the task mutates a database; derive its DDL or DML into the session script"
   },
   "commands": {
     "doctor": {

package/skills/w/exports/export-diagrams/EXPORT.md

@@ -1,11 +1,11 @@
 ---
 name: export-diagrams
-description: "Generates the workspace's architecture and flow diagrams in `docs/diagrams/` consolidating the sources' code + the plan-doc (the AS-IS → TO-BE delta in `## Solution`, `Impacted`) of N sessions. Produces context, containers, components, integrations and data model (when read-only MCP is available). Default `mermaid` (renders on GitHub, `mermaid.ink` link for preview); `c4`/structurizr opt-in via `--engine`. Output in `docs/diagrams/NNN-export-diagrams-YYYY-MM-DD/` (or `.md`). Read-only/report: emits only the diagram source (the reader renders it); never commits nor mutates anything; MCP reads only. Composes the `diagrams` capability. Use for 'system diagram', 'workspace C4', 'architecture/flow map'. User-invoked via `/w:export-diagrams`."
+description: "Generates architecture and flow diagram source in `docs/diagrams/`, consolidating code and plan context from N sessions. The CLI proposes an optional exact-path commit after publication and executes it only with approval; MCP reads only. Composes `diagrams`. User-invoked via `/w:export-diagrams`."
 ---
 
 # export-diagrams — architecture and flow diagrams from code + plan-doc
 
-Generates a diagram dossier (**architecture and flows**) of the workspace, aggregating the sources' structure and the sessions' delta. **Read-only / report** — it emits only the diagram **source** (Mermaid / DSL); the reader renders it. It never commits, never mutates anything; MCP reads only.
+Generates a diagram dossier (**architecture and flows**) of the workspace, aggregating the sources' structure and the sessions' delta. It emits only diagram **source** (Mermaid / DSL); the reader renders it. The CLI offers an optional approved commit after publication; MCP reads only.
 
 > `export-*` family (the only artifact→`docs/` path). Design: `docs/referencias/workflow-exports/export-diagrams.md`.
 
@@ -102,7 +102,7 @@ Per `--engine`: `mermaid` → native Mermaid C4 blocks (`C4Context`/`C4Container
 
 ### Step 6 — Write or report
 
-With `--dry-run`: print the report; write nothing. Otherwise: `aw next-number docs/diagrams` + write the dossier. **NEVER commit**. Summary to the user: engine, present/omitted sections (e.g. Data omitted without MCP) and the path.
+With `--dry-run`: print the report; write nothing. Otherwise: `aw next-number docs/diagrams` + write the dossier. The CLI proposes `aw workspace-commit prepare --export <ruta>` after publication; `apply --approval <digest>` commits only approved paths, never pushes. Summary to the user: engine, present/omitted sections (e.g. Data omitted without MCP) and the path.
 
 ## Output location
 

package/skills/w/exports/export-manuals/EXPORT.md

@@ -1,21 +1,21 @@
 ---
 name: export-manuals
-description: "Operations / onboarding manuals (operator/support audience). Synthesizes the workspace's technical manuals into `docs/manuals/` consolidating N sessions (`exec`/`quick`) + `docs/`. Reads each session's `DECISION` and the plan-doc (`Solution` — including its Final behavior block —, `Validations`) + the touched code in the sources (how what was built operates/works). Two modes: `complement` (default, overwrites `INDEX.md` pointing at the detected manuals) and `regenerate` (produces a `NNN-export-manuals-YYYY-MM-DD/` dossier with 1 manual per topic). Audience: operators / support / onboarding. Read-only/report: it never commits nor mutates sessions. The prose follows the ambient writing conventions (the host auto-applies an installed writing skill when present). Use for 'operations manual', 'how what we shipped works', 'technical onboarding pack', 'manuals index'. User-invoked via `/w:export-manuals`."
+description: "Operations/onboarding manuals from N sessions into `docs/manuals/` or `[docs] manuals`. The CLI previews replacement, publishes on approval and offers a separate exact-path commit, executed only with approval; sessions remain untouched. User-invoked via `/w:export-manuals`."
 ---
 
 # export-manuals — technical manuals from sessions + `docs/`
 
-Generates or refreshes **operations / how-it-works / onboarding** manuals in `docs/manuals/`, consolidating what N sessions delivered + the `docs/` corpus. **Read-only / report** — it never commits, never mutates sessions or code.
+Generates or refreshes **operations / how-it-works / onboarding** manuals in `docs/manuals/`, consolidating what N sessions delivered + the `docs/` corpus. It never mutates sessions or code; the CLI separately proposes a commit after publication.
 
 > `export-*` family (the only artifact→`docs/` path). Design: `docs/referencias/workflow-exports/export-manuals.md`.
 
 ## Category
 
-`docs/manuals` — the **only** `docs/` folder this export writes.
+`docs/manuals` or its `[docs] manuals` override — the **only** `docs/` folder this export writes.
 
 ## Writing (ambient convention, not a role)
 
-The manual's prose follows the **ambient** writing conventions: the host auto-applies an installed writing skill (when present) by its `description` — short sentences, lists over prose, no filler, technical lexicon for the operator/support audience. This export does **not** compose or bind a `writing` role; it is **indifferent** to which writing skill exists. A useful family lives in the `dev-conventions` marketplace plugin, but the export does **not depend** on it. Manuals are user-facing deliverables → write them in the user's language.
+The manual's prose follows **ambient** writing conventions when the host has one installed — short sentences, lists over prose, no filler, technical lexicon for operators and support. This export does not bind a writing role and works without any installed convention. Manuals are user-facing → write them in the user's language.
 
 ## When to use
 
@@ -29,9 +29,9 @@ The manual's prose follows the **ambient** writing conventions: the host auto-ap
 1. Reads the session corpus (`exec`/`quick`): per session, `DECISION` + the plan-doc (`Solution` — including its Final behavior block; legacy plans: a separate `## Final behavior` section —, `Validations`).
 2. Inspects the touched code in the sources (how what was built operates/works) — read-only.
 3. Detects topics (declared in `SESSION` — its `## Objective` —, or inferred by operational keywords).
-4. Resolves the mode (`complement` or `regenerate`).
+4. Infers mode from the response (`complement`, flat or `regenerate`).
 5. Synthesizes the content applying the ambient writing conventions (host).
-6. Writes: `complement` → overwrites `docs/manuals/INDEX.md`; `regenerate` → a `docs/manuals/NNN-export-manuals-YYYY-MM-DD/` dossier with 1 manual per topic.
+6. Publishes: index only → `INDEX.md`; direct `<slug>.md` → flat canon; dossier → numbered pack. Existing files require `--overwrite`.
 
 ## What it does NOT do
 
@@ -44,7 +44,7 @@ The manual's prose follows the **ambient** writing conventions: the host auto-ap
 
 ## Read-only sandbox
 
-In plan mode it **describes**, never writes: the resolved mode, the detected topics (with origin sessions), the manuals already present in `docs/manuals/`, and — per mode — the `INDEX.md` structure it would overwrite or the count of manuals the dossier would generate. It does **not** run `Write`; numbering queries use `aw next-number --dry-run` (pure).
+In plan mode it **describes**, never writes: the inferred mode, topics and destination. It does **not** run `Write`; numbering queries use `aw next-number --dry-run` (pure).
 
 ## Inputs
 
@@ -64,7 +64,6 @@ In plan mode it **describes**, never writes: the resolved mode, the detected top
 
 ```
 /w:export-manuals [--sessions NNN[,NNN]] [--since sessionNNN] [--source <alias>]
-                  [--mode complement|regenerate] [--topics slug1,slug2] [--dry-run]
 ```
 
 | Flag | Behavior |
@@ -72,17 +71,15 @@ In plan mode it **describes**, never writes: the resolved mode, the detected top
 | `--sessions NNN[,NNN]` | Discrete filter by code (takes precedence over `--since`) |
 | `--since sessionNNN` | Only sessions after NNN (exclusive: NNN itself is out; use `--sessions` to include it) |
 | `--source <alias>` | Limits to one source (multi-source workspace) |
-| `--mode complement\|regenerate` | Default `complement` |
-| `--topics slug1,slug2` | Limits to the declared topics |
-| `--dry-run` | Propositional report, no files written |
 
-No args: `--mode complement` over the whole corpus.
+No args: the response determines the mode over the whole corpus.
 
-### `--mode` resolution
+### Response shape determines the mode
 
 | Mode | Output | When to use |
 |---|---|---|
 | `complement` (default) | `docs/manuals/INDEX.md` (overwrites) | Refresh the index after new sessions/manuals |
+| Flat canon | Direct `docs/manuals/<slug>.md` files | One manual per topic without a dossier; replacements need `--overwrite` |
 | `regenerate` | `docs/manuals/NNN-export-manuals-YYYY-MM-DD/` (next-number) | Consolidated manual pack (e.g. onboarding) |
 
 ## Flow
@@ -97,7 +94,7 @@ List `docs/manuals/*.md` (excluding `INDEX.md` and `NNN-export-manuals-*/` subdi
 
 ### Step 3 — Detect topics
 
-For every filtered corpus session (`aw session-artifacts --code <NNN> --dump objetivo,decisiones`): take the dump's `DECISION` + the plan-doc (`Solution` with its Final behavior block/`Validations`) + the touched code. **Primary** topic: the topic in `SESSION` (its `## Objective`). **Secondary**: inference by operational keywords ("configure", "install", "step by step", "how to …" — in the user's language). Filter by `--topics` when present. List (slug, confidence, origin sessions).
+For every filtered corpus session (`aw session-artifacts --code <NNN> --dump objetivo,decisiones`): take the dump's `DECISION` + the plan-doc (`Solution` with its Final behavior block/`Validations`) + the touched code. **Primary** topic: the topic in `SESSION` (its `## Objective`). **Secondary**: inference by operational keywords ("configure", "install", "step by step", "how to …" — in the user's language). List (slug, confidence, origin sessions).
 
 ### Step 4 — Synthesize (prose: ambient conventions)
 
@@ -107,11 +104,12 @@ For every filtered corpus session (`aw session-artifacts --code <NNN> --dump obj
 
 ### Step 5 — Write or report
 
-With `--dry-run`: print the report; write nothing. Otherwise: `complement` → `Write` over `docs/manuals/INDEX.md`; `regenerate` → `aw next-number docs/manuals` + create the dossier. **NEVER commit**. Summary to the user: mode + written paths + counts; if there are detectable topics without a manual, suggest covering them.
+Publish via `aw export-manuals` prepare → validate → apply: index-only response → `complement`; dossier → `regenerate`. The CLI then proposes `aw workspace-commit prepare --export <ruta>`; only approval of the pathspec and message allows `apply --approval <digest>`, never push. Summarize mode and written paths.
 
 ## Output location
 
-- `complement`: `docs/manuals/INDEX.md` (overwrites).
+- `complement`: `docs/manuals/INDEX.md` (overwrites if already present).
+- Flat: `docs/manuals/<slug>.md` (each existing file requires `--overwrite`).
 - `regenerate`: `docs/manuals/NNN-export-manuals-YYYY-MM-DD/` with `README.md` + 1 `.md` per topic.
 
 ## Re-run

package/skills/w/exports/export-reports/EXPORT.md

@@ -1,11 +1,11 @@
 ---
 name: export-reports
-description: "Executive/functional report (management/committee audience) consolidating N workspace sessions under `docs/reports/NNN-<slug>-YYYY-MM-DD.md`. Reads the corpus: the spec (`docs/specs`), `CONCLUSIONS` (research), `DECISION`, the plan-doc state + the rest of `docs/` for context. Synthesizes: what was done, key decisions, results/conclusions, pending/roadmap — with cross-session recommendation dedup. Audience adjustable via `--audience` (gerencia ≈ short; tecnica ≈ detailed). Read-only/report: it never commits nor mutates sessions. The prose follows the ambient writing conventions (the host auto-applies an installed writing skill when present). Use for 'executive report', 'what got done this quarter for management', 'brief with consolidated recommendations'. User-invoked via `/w:export-reports`."
+description: "Executive/functional report consolidating N workspace sessions under `docs/reports/`. Publishes only the report and proposes an exact-path workspace commit, executed by the CLI only with approval. The prose follows ambient writing conventions. User-invoked via `/w:export-reports`."
 ---
 
 # export-reports — executive/functional report from the session corpus + `docs/`
 
-Generates a single `.md` consolidating N workspace sessions into an **executive/functional** report: what was done, key decisions, results/conclusions and pending/roadmap. **Read-only / report** — it never commits, never mutates sessions or the corpus.
+Generates a single `.md` consolidating N workspace sessions into an **executive/functional** report: what was done, key decisions, results/conclusions and pending/roadmap. It does not mutate sessions or the source corpus; after publication the CLI proposes an optional approved commit.
 
 > `export-*` family (the only artifact→`docs/` path). It **merges** two legacy exports into one `docs/reports` output: the executive report and the cross-session recommendation dedup. Design: `docs/referencias/workflow-exports/export-reports.md`.
 
@@ -95,7 +95,7 @@ Render applying the ambient writing conventions (host): Executive summary · Wha
 
 ### Step 5 — Write or report
 
-`aw next-number docs/reports` → `docs/reports/NNN-<slug>-YYYY-MM-DD.md`. With `--dry-run`: print; write nothing. **NEVER commit**. Summary to the user: path, audience/length, covered sessions (count + range), consolidated R-items, and a note if a conditional section was omitted.
+`aw next-number docs/reports` → `docs/reports/NNN-<slug>-YYYY-MM-DD.md`. With `--dry-run`: print; write nothing. After publication the CLI proposes `aw workspace-commit prepare --export <ruta>`; only an explicit approval runs `apply --approval <digest>` with exact paths and no push. Summary to the user: path, audience/length, covered sessions (count + range), consolidated R-items, and a note if a conditional section was omitted.
 
 ## Output location
 

package/skills/w/exports/export-scripts/EXPORT.md

@@ -1,11 +1,11 @@
 ---
 name: export-scripts
-description: "Consolidates pending SQL into one `docs/scripts/NNN-export-scripts-YYYY-MM-DD/` bundle with continuous numbering after `00-ROLLBACK.sql`. It publishes the net final state, not a chronological transcript. Its origin is DECLARED: a base (the session corpus, the published bundles, or a sweep of the whole workspace), minus the pieces named in `--exclude`, minus whatever the release book says already ran in `--environment`. Read-only/report: it NEVER executes SQL nor commits; external application is a handoff. Composes the `sql` capability. User-invoked via `/w:export-scripts`."
+description: "Consolidates pending SQL into a numbered `docs/scripts/` bundle: five forward categories and paired rollbacks. Publishes the net final state; never executes SQL. After publication the CLI offers a commit of explicit paths, only with approval. Composes `sql`. User-invoked via `/w:export-scripts`."
 ---
 
 # export-scripts — consolidated SQL bundle, simple and direct
 
-Consolidates pending SQL migrations into a single bundle under `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`, with continuous numbering after `00-ROLLBACK.sql`. **Read-only / report** — the AI **never executes** the SQL; external application is an optional handoff.
+Consolidates pending SQL into `docs/scripts/NNN-export-scripts-YYYY-MM-DD/`, with category folders and rollback files under `rollback/`. The AI **never executes** SQL; application is a handoff.
 
 **The material is declared, not assumed:** a base brings it, `--exclude` subtracts pieces and `--environment` what the book records as applied. With no flag: the session corpus, bundles out.
 
@@ -30,23 +30,23 @@ The **`sql`** capability (built-in default `sql`), resolved via `.workflow/skill
 
 ## Read-only sandbox
 
-In plan mode it **describes**, never writes: the resolved `NNN`, the declared origin with its exclusions, the categories with content and the files that would appear. No `Write`, no mutations; numbering uses `aw next-number --dry-run` (pure).
+In plan mode do **not** call `prepare` (it reserves a folder): describe the origin, categories and tentative `NNN` from `aw next-number --dry-run docs/scripts`. No mutations.
 
 ## Inputs
 
 **`agent-workflow` CLI (alias `aw`)** — never read hardcoded paths:
 
 - `aw release-data [--since sessionNNN] [--source <alias>]` — the session corpus (ALL sessions, closed + active, with `release_eligible`). `aw sessions` lists only ACTIVE ones: never use it as the corpus.
-- `aw session-artifacts --code <NNN> --dump scripts` — the session's `.sql` files with path and size (content is read by path). No scripts → empty list, silent skip.
+- `aw session-artifacts --code <NNN> --dump scripts` — session SQL including root `SCRIPTS.sql` and `SCRIPTS.rollback.sql`, with relative names, path and size. No SQL → not material.
 - `aw release-data --standalone-sql [--include-graduated]` — the loose `docs/scripts/*.sql` and the previous bundles. `prepare` already reads both through its base; these are for looking by hand.
-- `aw release-pass list` — the book `--environment` reads: `link --artifact <ruta>` says which bundle a pass carries, `applied --environment` that its SQL RAN there. Nothing inspects a database.
+- `aw release-pass list` — `--environment` reads linked/applied bundles. `--catalog <connection>` optionally inspects the target catalog through Workline's read-only PostgreSQL connection; unreachable or missing objects block publication. Without it, no database connection opens.
 - `aw next-number docs/scripts` — deterministic numbering; it also creates `docs/scripts` when missing, which is what makes destination resolution a CLI guarantee. In plan mode, `--dry-run`.
 
 **Args** (no lifecycle *structured-choice*; harness capability — see [`../../harness/HARNESS.md`](../../harness/HARNESS.md)):
 
 ```
 /w:export-scripts [--from sessions|bundles|workspace] [--exclude <nombre>]… [--environment <ambiente>]
-                  [--sessions NNN[,NNN]] [--since sessionNNN] [--source <alias>]
+                  [--sessions NNN[,NNN]] [--since sessionNNN] [--source <alias>] [--code <sesión>] [--catalog <conexión>]
 ```
 
 | Flag | Behavior |
@@ -57,6 +57,8 @@ In plan mode it **describes**, never writes: the resolved `NNN`, the declared or
 | `--sessions NNN[,NNN]` | Discrete filter by code (takes precedence over `--since`) |
 | `--since sessionNNN` | Only sessions after NNN (exclusive: NNN itself is out; use `--sessions` to include it) |
 | `--source <alias>` | Limits to one source (multi-source workspace) |
+| `--catalog <connection>` | Optional read-only target catalog check, repeated on validate and apply |
+| `--code <sesión>` | Owns the folder reservation; without it, the sealed operation owns it |
 
 No args: every corpus session, bundles and loose SQL out — the behavior that always was. The three composition flags are this export's alone.
 
@@ -66,11 +68,11 @@ No args: every corpus session, bundles and loose SQL out — the behavior that a
 
 `prepare` already resolved WHICH pieces are in: its inventory lists them per origin with every exclusion and its reason. Read only that.
 
-**Sessions**: for every session the inventory names (`aw session-artifacts --code <NNN> --dump scripts`), read the `.sql` files the dump lists (per-script path). Take **only** type-B statements (deliverable DDL/DML migrations); ignore read-only type-A (diagnostic queries). Expected per-statement markers: `-- @category: <01-04>` + `-- @stmt: NNN-verb-target` (format defined by the `sql` capability).
+**Sessions**: read every `.sql` named by `aw session-artifacts --code <NNN> --dump scripts`, including root `SCRIPTS.sql` and `SCRIPTS.rollback.sql`. Take only type-B migrations; skip type-A research. Markers: `-- @category: <01-05>` and `-- @stmt: NNN-verb-target` (from the `sql` capability).
 
 **Loose SQL**: per file, honor `@category` markers when present; otherwise infer it from content (`CREATE/ALTER TABLE`, `CREATE INDEX` → `01`; `CREATE OR REPLACE FUNCTION`/`PROCEDURE` → `02`; `UPDATE`/`DELETE` → `03`; `INSERT INTO … VALUES` → `04`). If the filename contains `rollback` → skip (it never enters a forward).
 
-**Published bundles**: their forwards in numeric order, same markers. `00-ROLLBACK.sql` is **never** read as a forward — it is the bundle's reverse, not its material.
+**Published bundles**: read forwards in category and filename order. Both `rollback/` and legacy flat rollbacks are **never** forwards.
 
 An empty origin → **abort**: `prepare` already refused, saying whether nothing matched or everything was already applied.
 
@@ -84,47 +86,69 @@ Reconcile every candidate the origin brought against the code and the declared f
 objects born and retired within the sequence; write migrated objects directly in their final form;
 omit explicitly retired objects even when their deletion is absent from the input.
 
+| History in the corpus | Publish |
+|---|---|
+| Created, then dropped | Nothing: neither forward nor rollback |
+| Created, then changed (type/rename) | One statement in final form |
+| Created, untouched | The original statement |
+| Retired by session context without an explicit `DROP` | Omit it |
+
+**Synthesize, never invent:** folding `CREATE` + `ALTER` into a final `CREATE` is required;
+adding a migration no session performed is forbidden. Session context outranks script chronology:
+a retired object stays out even when no file dropped it. Check actual state **read-only** before
+deciding what remains; reconcile code (including entity mappings and native queries) with it.
+Do not promote one-off QA data repairs into release migrations.
+
+**Corpus ≠ live source environment.** Hand edits may never appear in a script. As an
+operational handoff after application, compare source and target object by object through
+read-only inspections; before application the planned delta hides omissions. Portable
+guards assert existence, not a source-specific row count. Compare routine definitions
+from the live catalog, not the file that once created them: omit a replacement when live
+bodies already agree. User-visible labels matter too; an older label can leave an object
+present but unfindable. None of these remote observations is a local closure criterion.
+
 **A previous bundle in the origin is MATERIAL A RECONCILIAR, not untouchable history.** Two that
 contradict — one creating an object, a later one retiring it — publish the resulting net final state,
-never their chronological sum: the new bundle does not create it, and its `00-ROLLBACK.sql` does not
+never their chronological sum: the new bundle does not create it, and its global rollback does not
 reverse a creation it never published. The bundles on disk are never modified.
 
-Then group the remaining statements by canonical category: `01 DDL-TABLES` · `02 DDL-FUNCTIONS` · `03 DML` ·
-`04 INSERTS`. Origin is traceability, not an ordering authority over the final contract.
+Group the remaining statements: `01-ddl-tablas` · `02-ddl-funciones` · `03-migracion` · `04-inserts` · `05-grants`. Origin traces changes, never determines their order.
 
 ### Step 4 — Continuous numbering (no gaps)
 
-Assign sequential numbers **only to categories with content**, in canonical order. The first forward is always `01-…`. E.g.: DML only → `00-ROLLBACK.sql`, `01-DML.sql`; all 4 categories → `00-ROLLBACK.sql`, `01-DDL-TABLES.sql`, `02-DDL-FUNCTIONS.sql`, `03-DML.sql`, `04-INSERTS.sql`.
+Keep the five fixed category numbers. Omit empty folders; within each populated folder, number files `01-<nombre>.sql`, `02-<nombre>.sql`, … with no gaps.
 
 ### Step 5 — Write the forwards
 
-Per category with content, one file with a 1-2 line header (`-- 0N-<CATEGORY>.sql — bundle NNN-export-scripts-YYYY-MM-DD`) and traceable origin comments where useful. Write SQL for the reconciled final state, not necessarily the original statement verbatim; preserve explicit intent, idempotency and safe transaction boundaries. Do not replicate motivation/impact already present at the origin; no statement index, no invented verification SELECTs.
+Write each forward in its category folder with a concise header and useful origin. Reconcile to the net final state; keep idempotency, intent and transaction boundaries. Never invent verification SELECTs.
 
 ### Step 6 — Derive `00-ROLLBACK.sql` (at the end)
 
-Via the `sql` capability, **reading the already-written forwards** (not the original `SCRIPTS.sql`): inverse statements in reverse order (last→first), a single transactional block, and an "irreversible cleanup" block at the end outside the transaction only if there are operations without an automatic reverse.
+For every forward `<categoría>/NN-<nombre>.sql`, write `rollback/<categoría>/NN-<nombre>.rollback.sql`. Derive `rollback/00-global/00-ROLLBACK.sql` from the consolidated final state, **in dependency-safe order**: drop referencing rows/tables before their FK targets; never reverse the session chronology or file order literally. Verify the real state only through read-only inspection; application is the user's handoff.
 
 ### Step 7 — Write the `README.md` (3 sections)
 
-`## Archivos` (table: 1 row per file present) · `## Aplicar` (one `psql -f` per file in ascending order; the export executes nothing) · `## Revertir` (`psql -f 00-ROLLBACK.sql` + a note if there is an irreversible block). The README is a user-facing deliverable → write it in the user's language. **Vetoed**: everything the section above forbids.
+`## Archivos` (every file present) · `## Aplicar` (`psql -f` for each forward, category then filename order; `*/*.sql` or `0*/*.sql` reaches only forwards; `**/*.sql`, `find` and PowerShell `-Recurse` also reach rollbacks and MUST NOT be used to apply) · `## Revertir` (`rollback/00-global/00-ROLLBACK.sql`). Write it in the user's language.
 
 ### Step 8 — Write or report
 
-Publish through the three stages (`prepare` → `validate` → `apply --approval`); in plan mode, describe instead. **NEVER commit**. Summary: one line per file + the bundle path, naming the origin and what stayed out.
+Publish through the three stages (`prepare` → `validate` → `apply --approval`); in plan mode, describe instead. Once published, the CLI proposes `aw workspace-commit prepare --export <ruta>` and executes `apply --approval <digest>` only with explicit approval, with exact paths and no push. Summary: one line per file + the bundle path, naming the origin and what stayed out.
 
 ## Output location
 
 ```
 docs/scripts/NNN-export-scripts-YYYY-MM-DD/
-├── 00-ROLLBACK.sql       # reverse derived from the forwards
-├── 01-<CATEGORY>.sql     # first forward (continuous numbering)
-├── 02-<CATEGORY>.sql     # …per category with content
-└── README.md             # Archivos · Aplicar · Revertir
+├── README.md
+├── 01-ddl-tablas/01-<nombre>.sql
+├── 02-ddl-funciones/ · 03-migracion/ · 04-inserts/ · 05-grants/
+└── rollback/
+    ├── 00-global/00-ROLLBACK.sql
+    └── <categoría>/NN-<nombre>.rollback.sql  # one per forward
 ```
 
 ## Re-run
 
-Functionally idempotent: each invocation takes the next `NNN` and **never overwrites** a previous bundle. To regenerate, delete the directory by hand and re-invoke.
+Each invocation publishes a new `NNN`: never delete or overwrite a published bundle. Corrections supersede the earlier bundle.
 
 ## Resources
 

package/skills/w/harness/HARNESS.md

@@ -74,7 +74,7 @@ coordination, without turning a deterministic CLI rule into model work.
 
 ## Harness binding matrix
 
-Concrete mechanism per harness (matrix base verified **Jul-2026**; the `structured-choice` row re-verified **2026-08-22**, the Codex `hooks` row **2026-08-05** and the crush/gemini/opencode `hooks` contract **2026-08-18**, all against the INSTALLED runtimes plus real runs — not 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**; `structured-choice` re-verified **2026-08-22**, Codex `hooks` **2026-08-05**, crush/gemini/opencode `hooks` **2026-08-18**; Codex `host-memory` **2026-09-27**; installed runtimes and real runs, `~` partial). Antigravity reuses Gemini's surfaces; Oz reuses Warp's (MCP via flag — see below).
 
 | Capability | Claude Code | Codex | Kimi Code | Gemini / Antigravity | OpenCode | Crush | Warp / Oz | Generic |
 |---|---|---|---|---|---|---|---|---|
@@ -84,7 +84,7 @@ Concrete mechanism per harness (matrix base verified **Jul-2026**; the `structur
 | compaction | `/compact` | Pre/PostCompact hooks | `/compact` + Pre/PostCompact hooks | ~ | `session.compacted` | ~ | ~ | CHECKPOINT + resume |
 | subagent-dispatch | `Task` (parallel) | `agents` | `SubagentStart` | agents (`.gemini/agents`) | `.opencode/agent/*.md` | inline | inline (Oz cloud orchestration is not a direct worker binding) | 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` |
-| **host-memory** | `MEMORY.md` (cheap) + transcripts/`--resume` (deep) | `AGENTS.md` (static → fallback) | sessions with resume/fork (`kimi -S`) + `AGENTS.md` | `GEMINI.md`+`AGENTS.md` (static → fallback) | `AGENTS.md` (static → fallback) | `CRUSH.md`+`AGENTS.md` (static → fallback) | rules / history (~) | git/`docs/` + ask |
+| **host-memory** | `MEMORY.md` (cheap) + transcripts/`--resume` (deep) | `~/.codex/memories/` (config-enabled); `AGENTS.md` static fallback | sessions with resume/fork (`kimi -S`) + `AGENTS.md` | `GEMINI.md`+`AGENTS.md` (static → fallback) | `AGENTS.md` (static → fallback) | `CRUSH.md`+`AGENTS.md` (static → fallback) | rules / history (~) | git/`docs/` + ask |
 | **web-research** | `WebSearch` / `WebFetch` | `web_search` (opt-in config) | moonshot search + fetch services | `google_web_search` + `web_fetch` | `webfetch` (~) | ~ | ~ (agent web access) | — (offline + declare) |
 | external-data (MCP) | `.mcp.json` | `.codex/config.toml` `[mcp_servers]` | `~/.kimi-code/mcp.json` `mcpServers` (also reads project `.mcp.json`) | `settings.json` `mcpServers` | `opencode.json` `mcp` | `crush.json` `mcp` | `.warp/.mcp.json` (+auto-discovers `.mcp.json`) · Oz: `--mcp` flag | — |
 | **enforcement (deny tool)** | `PreToolUse` → `permissionDecision:deny` / exit 2 | `PreToolUse` (**≈same protocol**) | `PreToolUse` → block / exit 2 | `PreToolUse` in its `hooks.json` (Claude-shaped; `BeforeTool` **does not exist**) | plugin `tool.execute.before` (`throw`) | `PreToolUse` in `crush.json` → `hooks` (+ `allowed_tools` allowlist) | allow/deny lists (**coarse**) | doctrine (git-safe #5) |

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

@@ -1,5 +1,11 @@
 {
   "hooks": {
+    "UserPromptSubmit": [
+      {
+        "matcher": "",
+        "hooks": [{ "type": "command", "command": "agent-workflow hook turn-start", "timeout": 10 }]
+      }
+    ],
     "SessionStart": [
       {
         "matcher": "startup|resume|clear",
@@ -78,10 +84,6 @@
             "command": "agent-workflow resume-summary",
             "statusMessage": "Recuperando estado tras compact...",
             "timeout": 10
-          },
-          {
-            "type": "prompt",
-            "prompt": "Contexto compactado. El JSON anterior es output de `agent-workflow resume-summary`. Si `continuity` es `ok`, reanudá el loop de `primary_session` desde su CHECKPOINT.md y presentá un resumen. Si `continuity` es `degraded`, NO reanudes ninguna sesión: `active_sessions` es un listado, no una identidad — mostrá `candidates` con su `action` y pedí al usuario que elija (después reintentá con `--code <NNN>`). Si el JSON trae `refuge`, la compactación dejó un CHECKPOINT de refugio fuera de toda sesión: mostrá su `path` y avisá que se adopta al resolver la sesión (`aw checkpoint-write --code <NNN>`). Si no hay sesiones, terminá."
           }
         ]
       }

package/skills/w/loops/CHASSIS.md

@@ -1,8 +1,14 @@
 # CHASSIS — the loop engine
 
-The **common engine** of the Workline loops: every loop reads it from its `## Inherits`, **always, before its deltas**. Edit the engine **here**; heirs only reference it.
+The **common engine** of Workline loops: heirs read it before their deltas and only reference it.
 
-> **When each step below happens is no longer this document's call:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document. They consume no model worker, subagent or external process: the CLI advances them locally to the first real frontier. What stays is what each rule is FOR — the half no engine carries. Answering the frontier it stops at is `aw flow submit`, and its envelope — which fields each kind of frontier demands, and where each digest comes from — is **read** with `aw flow --help`, never guessed.
+> **When:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document. `aw flow submit` answers the frontier. Read its envelope and digest from `aw flow --help`, never guess. Use `--adopt` for an existing run; `aw flow recover` restores a no-effect exhausted frontier, `aw flow restart` handles stuck runs, `aw flow annul` reopens miscredited batches, and `aw flow prove` binds evidence to the checkout.
+
+## Host execution rules
+
+- Write JSON envelopes with the file tool, never heredoc or shell-built JSON; redirect the file to stdin.
+- Use a CLI verb before editing the runtime; make one call per approvable effect.
+- The user executes force-push; on Windows set `PYTHONUTF8=1` for Python consumers.
 
 ## Heirs (canonical list)
 
@@ -18,9 +24,9 @@ The two that edit code also apply [`CODE-POLICIES.md`](CODE-POLICIES.md).
 
 ## Persistent objective
 
-A loop **is a persistent objective**: it exists to fulfill the `SESSION.Objective` declared at start, and **it is not finished until the convergence gate confirms the objective was met**. Gap-driven iteration is the *method*; the artifacts are the *record*; the objective is the *frame*.
+A loop fulfills `SESSION.Objective` until its convergence gate confirms it. Gaps are the method; artifacts the record.
 
-"Don't stop until convergence" is sustained by the loop itself — its `repeat:` plus the convergence gate — never by a host hook, which is what makes it harness-agnostic.
+The loop's `repeat:` and gate sustain convergence, not a host hook.
 
 > **Inter-turn continuity.** The same `CHECKPOINT`+resume governs the **next prompt**: the objective persists **across turns**, not only within a run. Its canonical rules have their **single source** in [`../SKILL.md`](../SKILL.md) § *Operating context*; this engine executes them via *Compact / resume* (case 3).
 
@@ -125,7 +131,7 @@ Resume **keys off the `CHECKPOINT`** of the run's session, not the existence of
 ## Convergence / exit
 
 - **No material gaps** → **convergence gate** (read-only) = **`Success criteria` green** (*verification-first*). Whatever fails **comes back as a gap**; if it passes → the loop **flips the green criteria** in `SESSION.md` (`- [ ]` → `- [x]`) and offers its closing action. The checklist must reflect the real final state: a criterion left unchecked at `finalize` needs an explicit reason. Each heir names its own instance of this gate, and those instances are what realize it.
-- `Cerrar` (the `flow` control, at any time) → `finalize`, the last step of every journey. **`finalize` always persists `CHECKPOINT.md`** (resumable) and, **only if** something was deferred, writes `BACKLOG.md` (close reason + the deferred items); closes the session and reports. Progress survives even without a prior `Compactar`.
+- Finish sources → approve exact workspace paths/message or skip → `finalize` persists CHECKPOINT, deferred BACKLOG if needed, archive and HISTORY; an approved commit runs last, never push. `Cerrar` at any time uses `finalize` and preserves progress.
 
 ## docs/ boundary — no auto-export (hard rule)
 

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

@@ -6,19 +6,22 @@ closing-review invariants.
 
 ## Safe git — verified branch + proposed commits
 
-Sources are edited on a **verified** branch (`aw check-branch`), and the unit's commits are
-**proposed**: exactly one commit per affected source — at effective-batch close in plan-exec, at task
-close in quick — never `push`/`--amend`/`--no-verify`, and never a destructive clean or a branch
+Sources are edited on a **verified** branch (`aw check-branch`), and commits are
+**proposed**: in plan-exec the CLI commits only the batch's approved paths once per source; in quick
+the task closes with one proposed commit. Never `push`/`--amend`/`--no-verify`, a destructive clean or a branch
 switch without confirmation. A **rejected** commit leaves the changes in the tree and the unit
 recorded as uncommitted in `CHECKPOINT` and `BACKLOG`. Between units 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, and no batch may co-mingle with another.
 
-Concurrent flows never share a working tree: a run declares its sources and takes an **isolation
+Concurrent flows declare sources. By default a run takes an **isolation
 unit** in each before writing — a worktree on its own branch
 (`aw worktree ensure | list | release`). An edit outside is
 blocked naming the command that gets one, and at close `aw worktree integrate` merges each into
 the source's work branch; a conflict is reported, routed to `aw fix-git --path`, never alone.
+An in-place workspace declares `Modo de edición: in-place`; a plan may override it with `> Aislamiento: unidad`. In-place declares and approves only its own paths against the acquisition snapshot, without integration.
+
+For frontend sources, install dependencies (`npm ci` if the lockfile changes) inside each acquired unit: `node_modules` belongs to that worktree, never to a sibling checkout.
 
 > **When the branch is verified, when a commit becomes available and what an approval covers is not this document's call:** the deterministic steps below are decided by the CLI (`aw flow advance`), not by this document. Approving is the person's act and committing is a separate effect that comes back as the units' own git state — which is what makes "the checks passed" impossible to assert without having run them.
 

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

@@ -111,8 +111,11 @@ reconciliation** in `CHECKPOINT`, never reported as published.
 
 ## Delta 1 — One session per run; execution-unit cycle in the plan-doc
 
+`aw flow advance --adopt` adopts an existing plan; `aw flow recover` restores exhausted no-effect frontiers, `aw flow restart` unsticks runs, `aw flow annul` reopens miscredited batches. `aw flow prove --source <alias>` supplies checkout-bound evidence to `aw flow submit` after validation.
+
 - 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.
+- In-place `branch-precondition`: clean on another branch → offer switch, change document branch or cancel; dirty on another branch → pause; expected branch with user changes → proceed. Switch only with consent; the hook guards edits and the commit fences HEAD/branch against acquisition.
 - **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,
@@ -123,7 +126,7 @@ reconciliation** in `CHECKPOINT`, never reported as published.
   **Never** because all its checkboxes are ticked.
 - **Intermediate states:** `bloqueada` = the phase is stopped on a live checkout blocker — recorded in `CHECKPOINT` + the plan's `## Open questions`, back to `en ejecución` when it clears; it counts as **not validated**. A proof that cannot run **stays `bloqueada`**. A deferred check never counts as a passed one. A script awaiting real-world application is a **handoff**, not a blocker: local fixture/ephemeral validation can still establish the promised behavior and the phase may become `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** in the checkout, never an operator's deployed run.
-- **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.
+- **Plan-doc residue (hard rule):** execution writes **only** checkbox flips (`- [ ]` → `- [x]`), phase `> Estado:` and `> Bloqueo:` while blocked, deferrals in `## Open questions`, and the plan's title-level `> Estado:`, `> Cierre:` and `> Assurance:` (CLI-sealed at close). Deltas 4, 5 and 7 permit declared gaps; consented normalization occurs before execution. Results, findings and metrics belong in session `DECISION`/`CHECKPOINT`, **never** the plan. Update phases **in place — NEVER append a duplicate `### Fn` block**.
 - **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.
@@ -222,20 +225,22 @@ adds nothing of its own beyond running on a verified branch and never
   1. **phase proof** — component interaction, endpoint smoke test, vertical run down to the stub, persistence integration, or the main path end to end;
   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.
+- **One vertical proof per operation**; don't repeat happy paths or test trivial mappers/DTOs.
 - `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). **What execution runs is the PLAN's evidence, never the spec's prose:** `plan-new` already derived those validations from the spec's acceptance criteria and its `## Scenarios`, so the spec is confirmed functionally **through** them. A criterion no validation covers is a gap of the plan, not a test to improvise here.
+- Review each test's value at close (`CODE-POLICIES.md`, `overtest`); over-testing is a finding to fix or justify, never an automatic rejection.
+- Run the plan's `## Validations` and `## Solution` Final behavior (legacy: `## Final behavior`). The PLAN's evidence, derived from spec criteria and scenarios, decides closure; a criterion without evidence is a plan gap.
 - A validation that **runs and fails** → back into the phase (gap): no advancing, no `validada`.
 
 - **SQL delivery**: validate the migration's behavior against a fixture or ephemeral database in the acquired checkout. The forward/rollback script is delivered through `SCRIPTS.sql` and `export-scripts`; a real application is an optional handoff and never keeps a phase or the plan open.
 
-> The **final validation** is PLAN-exec's **convergence gate** = **`Success criteria` green** (*verification-first*; analogous to SPEC's *analyze gate* and plan-new's *coherence gate*): the plan is not marked *done* until local proof passes. For code and persistence these are checkout commands/tests; a script's real-world application is never a closing criterion.
+> **Final validation** is the convergence gate: `Success criteria` green on local checkout proof before `done`. A script's real-world application is never a closing criterion.
+
+For each code source, the final-validation directive names its required build and tests and whether each came from the plan's `## Validations` override or the source's versioned pipeline. A missing command leaves the gate open with the action to declare it in either place. Run both commands in the acquired checkout and return each command's real output as its own evidence; a test suite that did not run never counts. The final gate cannot be omitted by the adaptive route.
 
 ## Delta 5 — Closing review gate (conventions, pre-commit)
 
@@ -250,24 +255,23 @@ without subagents runs a clean re-read instead, and the closing report declares
 
 ## Delta 6 — Completion / close
 
-- 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*).
+- A phase closes as `validada` only after its exit, proof and batch review pass. An operative handoff leaves it `bloqueada` and uncommitted.
+- Check each known outdated spec/plan line with `aw amend apply … --check` before closing; propose its path, edit only with approval.
+- **The plan stays `open` until final validation.** Every phase `validada` is **not** the plan closed; keep `> Estado: open` under the title (stamp it if absent); never write `done` from the counters (§ *Legacy plans degrade safely*).
 - **Every phase `validada` + final validation passed** unlocks completion, and the mark is written
   **after Git**: commit each unit, integrate it, and only then seal `done`. A run that isolates its
   writing holds commits that live on `aw/<session>` and nowhere else, so a `done` stamped before the
   merge would be true of no branch anybody reads.
 - **Integrating is part of closing, not a chore after it.** `aw worktree integrate --code <NNN>`
-  merges every unit of the session into its source's working branch, in alias order, one at a time
-  over the live branch — never a rebase, a force, a push or a silent branch switch. A **conflict is a
+  merges each unit into its sealed base, in alias order, over the live branch — never a rebase,
+  force, push or silent branch switch. A **conflict is a
   live state, not a failure**: the unit, its commits and the merge are kept, the receipt names the
-  plan, the source and the files, and `aw fix-git --path <source>` (`prepare` → `apply` →
+  plan, the source and the files, and `aw fix-git --path <reported merge path>` (`prepare` → `apply` →
   `commit --confirm`) resolves it; then integrate again to confirm and give the unit back. The plan
   is not `done` and the session does not close while a unit is still alive.
-- **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`).
+- **Marking done = ONE status line in the plan-doc** under the title: `> Estado: done`. The CLI seals `> Cierre:` with evidence of the run and `> Assurance: verified|partially_verified|unverified_accepted` on separate lines. Position distinguishes title from phase states; no per-phase result tables or suffixes (use 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-*`.
+- **No automatic export**: session artifacts stay there; only a later explicit `export-*` promotes them to `docs/`.
 
 ## Sequence
 
@@ -281,8 +285,6 @@ plan-exec-loop(PPP-plan-<slug>.md):
   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)
@@ -306,16 +308,15 @@ plan-exec-loop(PPP-plan-<slug>.md):
     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, in its own isolation unit
-      pre-authorized → commit without another question
-      else → one consolidated approval for all source commits
-      rejected → changes stay; record "batch uncommitted"
+    propose one message and exact paths per changed source; show them for batch approval
+      approved → CLI commits those paths, verifies git and stores receipts before the next batch
+      Cerrar → persist the pending batch and its uncommitted changes
     if last Batch + final validation green:
       integrate: aw worktree integrate --code NNN            # every unit, alias order, live branch
-        conflict → keep unit + merge; report plan/source/files; aw fix-git --path <source>
+        conflict → keep unit + merge; report plan/source/files; aw fix-git --path <reported merge path>
                    (prepare → apply → commit --confirm) → integrate again → release
         refused (dirty checkout / off branch / uncommitted unit) → fix what it names; retry
-      then mark plan done: > Estado: done + > Cierre: YYYY-MM-DD · sesión NNN under the title (Delta 6)
+      then CLI seals plan: > Estado: done + > Cierre: run evidence + > Assurance: verdict (Delta 6)
     next-batch precondition: working trees clean or acknowledged
   if no Batch ran and phases are already validada:
     run final validation now; if green → same integrate-then-mark-done branch