@nac3/forge-cli 1.23.6 → 1.24.0

package/dist/docs/doctrine/urazuke.md

@@ -18,8 +18,9 @@ stations (N0..N7) first and enters the loop at step 5.
   the step names exist, are not stubs, say what they must; the sizing
   record is admissible (G9); the plan items carry a spec; the evidence
   receipts exist. `yujin.pending.close` refuses a red step. An override
-  needs the OWNER's written `force_reason` (kept in history); never pass
-  one on your own initiative.
+  needs the OWNER's written `force_reason` AND its `force_kind` (kept in
+  history, counted per motive -- see "A forced close carries a TYPE");
+  never pass either on your own initiative.
 - Evidence is a RECEIPT Forge records (command, ref, exit code, counts),
   never your summary. "Tests pass" without a receipt is a claim.
 - A LONG run leaves its receipt the same way. `yujin.evidence.run` blocks
@@ -35,6 +36,123 @@ stations (N0..N7) first and enters the loop at step 5.
   receipt, `yujin.task.list` for a task. Two closes were reported as
   "believed" over a receipt that existed on disk the whole time.
 
+## When does a project EXPECT a ladder?
+
+Written here because the condition must be findable, not inferred from the
+source (the owner's condition on F-06, 2026-11-01): "if tomorrow a project
+should have a ladder and does not leave that trace, the notice does not
+come out and we are where we started. The condition has to be WRITTEN
+where someone would look for it."
+
+The switch being ON means **the method is available**, not **you are
+walking it**. It is ON by default in Forge developer, so injecting the
+step block -- or warning that it is missing -- in every project with the
+switch on would charge ~700 characters of system prompt per turn to
+everyone who does not use the method.
+
+So Forge warns ("enabled and NOT arriving") only when the project leaves a
+TRACE that it expects a ladder. Exactly three traces count, any one of
+them is enough (`expectsLadder` in `src/chat/urazuke_section.ts`):
+
+1. **A Urazuke workflow instance exists** for the project, open or closed
+   (`findUrazukeInstance`). This is the normal trace: `yf urazuke start` /
+   `yujin.urazuke.start` leaves it.
+2. **The frozen copy of the gate definition** is on disk
+   (`.forge/urazuke/gates.json`, PND-165): the project pinned a version of
+   the method, so it is using it.
+3. **The method's artifacts are in the repository**: all three of
+   `docs/WORKING_AGREEMENT.md`, `docs/SEMANTIC_TREE.md` and `docs/GATES.md`
+   exist and are not stubs (`hasMethodArtifacts` in
+   `src/urazuke/probes.ts`).
+
+With none of the three, the turn records `reason: 'not_in_use'` and stays
+silent. That reason is itself the trace: it is in the result of
+`buildUrazukeSection`, so "the notice did not come out" can always be
+answered with WHICH condition failed. If you want the ladder in a project
+that has none of the three, open it -- `yujin.urazuke.start` -- and the
+step prompt arrives on the next turn.
+
+## A forced close carries a TYPE, and the type is counted
+
+M-02, decided by the owner on 2026-11-01. A plan item ships only with its
+receipts, and some items have no red to produce at all (documentation,
+configuration). The answer is NOT a kind of pending that authorises
+itself -- nothing can guarantee a code item will not be declared
+"documentation" -- it is an honest forced close that is COUNTABLE:
+
+- `force_reason` (the owner's prose, min 15 chars) is still mandatory, and
+- `force_kind` is mandatory with it, from a CLOSED catalogue
+  (`src/urazuke/overrides.ts`; `yf pending close --force-kind`, or
+  `force_kind` on `yujin.pending.close`). A free-text type turns the
+  counter into a cloud of synonyms, which is not counting.
+
+The condition that makes this worth having, in the owner's words: "the
+typed motive has to be a NUMBER in the report. You have to be able to ask
+how many closes were forced by `documentacion_sin_rojo_posible` and get an
+answer. If the type exists and nobody counts it, it is the same hole with
+a better name -- and worse, because it sounds solved."
+
+So the override is stored as DATA on the item's history entry
+(`history[].override = {gate, kind, missing}`), and
+`docs/RETROSPECTIVE_<date>.md` prints one row per motive and one per gate
+bypassed. Overrides recorded before this change are still counted, in
+their own `sin tipo` row: discounting them would have made the total DROP
+on the day of the fix, which is the worst way to measure a debt.
+
+## The catalogue's file names are PROTOCOL
+
+Decided by the owner on 2026-11-01 (M-03, measured by the Urazuke
+experiment), as a rule of the contract and not as an error message:
+
+**The file names the step catalogue asks for are protocol and are NOT
+translated. The CONTENT goes in the project's language.**
+
+So a step that names `docs/ARCHITECTURE.md` is satisfied by a file at
+exactly that path, whose prose may be entirely in Spanish. A
+`docs/ARQUITECTURA.md` with the identical, correct content counts as
+ABSENT -- and the gate now says so, with that reason, every time an
+artifact is missing (`ARTIFACT_NAMES_ARE_PROTOCOL` in
+`src/urazuke/gate.ts`), whether or not a similar-looking neighbour is
+found next to it.
+
+Why not a per-language alias table, which was the other option: **an alias
+table is a second source of truth, and a second source of truth
+desynchronises** -- the defect this project already has on record three
+times. (Plus the price on the Forge side: 232 artifact names to maintain in
+two languages.) It is the same line the `language-sovereignty` doctrine
+draws for verb ids and code identifiers: translate the EXPERIENCE, never
+the protocol.
+
+What was unacceptable before this was never the requirement. It was the
+SILENCE: a file with the right content next to it, counted as absent, with
+no written reason.
+
+## The five statuses, and why `closed` is NOT `green`
+
+A step carries ONE of five statuses, and two of them are easy to confuse --
+the confusion cost a report that said 0 of 24 when three steps were closed
+(F-07, measured by the Urazuke experiment, 2026-11-01):
+
+| status       | meaning                                                      |
+|--------------|--------------------------------------------------------------|
+| `closed`     | the canonical task of this step IS CLOSED. Consolidated progress. The BEST state a step can be in. |
+| `green`      | the gate passes and the task is STILL OPEN: it CAN be closed, nobody closed it yet. |
+| `red`        | a check is missing. It does not close.                       |
+| `owner`      | nothing mechanical to check; the owner signs it.             |
+| `unmeasured` | the definition in force needs an evaluator this installation cannot measure. It does NOT close and it is NOT green. |
+
+The two rules that follow:
+
+1. **`closed` and `green` are disjoint.** A closed step is reported as
+   `closed`, never as `green`. So **counting `green` to measure progress
+   LOSES every closed step** -- the best ones. Progress is `closed + green`
+   (`done_or_ready`), and a summary prints BOTH numbers, never one.
+2. **Nobody counts statuses on their own.** `summarizeLadder()` in
+   `src/urazuke/current.ts` is the only counter; the verb, the CLI, the
+   retrospective and the cyclic report all read it. A second, independent
+   count is exactly the inference the method warns against: it is how the
+   distinction gets lost again, in one consumer, silently.
+
 ## How to work inside it
 
 1. Read the URAZUKE section: red checks are what is missing. Produce the
@@ -48,3 +166,56 @@ stations (N0..N7) first and enters the loop at step 5.
    when / then" + `how_verified`) before it is implemented (step 5).
 5. No deadlines, ever: the method fixes the order and the gates, not the
    calendar. Speed is a consequence, not the objective.
+
+## The profiles axis: three evaluators, and where their data lives
+
+Added 2026-11-01 (Pieza 6, D-044). The published definition requires these
+three on the three anchors of the construction loop, and until that day this
+installation could not measure any of them -- so adopting the published
+definition froze three permanently unmeasurable steps.
+
+| evaluator | step | what it measures |
+|---|---|---|
+| `pendings_profiles` | 5 | every open plan item that touches a screen declares its convergence group, the profiles that have it, and ONE acceptance criterion per profile |
+| `profile_matrix` | 8 | the matrix is consistent, the navigation is DERIVED from it, and each profile's e2e reaches exactly its row |
+| `manual_cases_per_profile` | 10 | every manual case ran once per affected profile, derived from the matrix |
+
+The data, and the one rule that explains every choice -- **the matrix is the
+producer**:
+
+- `docs/PROFILE_MATRIX.md` carries the four columns of Annex H B2 and
+  nothing else: functionality, home, profiles, entry point. The table is
+  found by HEADER, so the column order is free.
+- `.forge/profile-navigation.json` is the generated navigation, and it
+  declares a fingerprint. The evaluator **recomputes** that fingerprint from
+  the matrix and compares; it never reads the declared one and compares it
+  with itself, which would pass any file. The fingerprint is
+  self-describing (algorithm, encoding, canonical form, covers, excludes) --
+  one that cannot be reproduced from outside is not evidence.
+- `.forge/profile-reachability.json` lists, per profile, what the e2e
+  **reached** (not what it attempted) and the id of its receipt. The
+  evaluator contrasts that id against the receipt registry: an artifact
+  whose receipt the registry does not have is prose.
+- the two directions of "neither less nor more" fail DIFFERENTLY and never
+  merge into one red: reaching **less** than the row is a MISSING piece
+  (construction incomplete); reaching **more** is an AUTHORIZATION defect,
+  high severity by written definition. If the message does not name the
+  class, the reader under-rates it.
+- the per-profile pending fields live in `PendingSpec` **in the registry**,
+  not in `docs/PENDING.md` (owner's decision, 2026-11-01): a gate cannot
+  measure prose, `pendings_spec` already measures there, and two sources for
+  the same datum age in opposite directions. The document is generated from
+  the registry or cites it. Write them with
+  `yf pending add --touches-screen --convergence-group ... --row-profile ...
+  --accept-for perfil=criterio`.
+- `touches_screen` is a THREE-state field: absent means "not declared" and
+  the evaluator reports it as such -- never as "does not touch". Not looking
+  is not the same as nothing being there.
+- the manual case ledger carries `functionality` (the link the method's
+  "derived from the matrix" implies): `yf urazuke rules sign <rule> passed
+  --by <name> --profile <id> --functionality "<row>"`. A case with a single
+  profile does NOT count as executed when its row has more.
+
+To measure what adopting the published definition would cost BEFORE
+adopting it: `yf urazuke rules show --published` (read only, writes
+nothing, never blocks) and `yf urazuke gates pull`.

package/dist/nac3/internal_manifest.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"internal_manifest.d.ts","sourceRoot":"","sources":["../../src/nac3/internal_manifest.ts"],"names":[],"mappings":"AAiBA,MAAM,MAAM,UAAU,GAClB,cAAc,GACd,SAAS,GACT,mBAAmB,GACnB,aAAa,GACb,eAAe,GACf,oBAAoB,CAAC;AAEzB,MAAM,MAAM,cAAc,GACtB,MAAM,GACN,KAAK,GACL,YAAY,GACZ,SAAS,GACT,SAAS,GACT,cAAc,GACd,KAAK,CAAC;AAEV,MAAM,MAAM,QAAQ,GAChB,QAAQ,GACR,MAAM,GACN,QAAQ,GACR,QAAQ,GACR,OAAO,GACP,YAAY,GACZ,SAAS,GACT,QAAQ,GACR,YAAY,CAAC;AAEjB,MAAM,WAAW,cAAc;IAC7B,IAAI,EAAE,QAAQ,CAAC;IACf,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE;QACzB,IAAI,EAAE,QAAQ,GAAG,QAAQ,GAAG,SAAS,GAAG,QAAQ,GAAG,OAAO,CAAC;QAC3D,WAAW,CAAC,EAAE,MAAM,CAAC;QACrB,IAAI,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;QACzB,SAAS,CAAC,EAAE,MAAM,CAAC;QACnB,SAAS,CAAC,EAAE,MAAM,CAAC;QAKnB,OAAO,CAAC,EAAE,MAAM,CAAC;QACjB,OAAO,CAAC,EAAE,MAAM,CAAC;QACjB,OAAO,CAAC,EAAE,MAAM,CAAC;KAClB,CAAC,CAAC;IACH,QAAQ,EAAE,SAAS,MAAM,EAAE,CAAC;CAC7B;AAED,MAAM,WAAW,QAAQ;IACvB,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,QAAQ,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;IACf,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,MAAM,EAAE,cAAc,CAAC;IACvB,MAAM,EAAE,UAAU,CAAC;IACnB,YAAY,EAAE,cAAc,EAAE,CAAC;IAC/B,OAAO,EAAE,OAAO,CAAC;IACjB;;;4BAGwB;IACxB,YAAY,EAAE,OAAO,GAAG,QAAQ,CAAC;IACjC;;;;;;qCAMiC;IACjC,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,kBAAkB,CAAC,EAAE,MAAM,EAAE,CAAC;CAC/B;AAED,MAAM,WAAW,YAAY;IAC3B,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,MAAM,CAAC;IACjB,aAAa,EAAE,MAAM,CAAC;IACtB,KAAK,EAAE,QAAQ,EAAE,CAAC;CACnB;AAm7GD,wBAAgB,QAAQ,IAAI,YAAY,CAOvC;AAED,wBAAgB,QAAQ,CAAC,OAAO,EAAE,MAAM,GAAG,QAAQ,GAAG,IAAI,CAGzD;AAED;gEACgE;AAChE,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,QAAQ,GAAG,IAAI,CAO9D;AAED;;;uDAGuD;AACvD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,MAAM,GAAG,IAAI,CA2CzF;AAED;;sEAEsE;AACtE,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,SAAI,GAAG,MAAM,EAAE,CAO/D"}
+{"version":3,"file":"internal_manifest.d.ts","sourceRoot":"","sources":["../../src/nac3/internal_manifest.ts"],"names":[],"mappings":"AAsBA,MAAM,MAAM,UAAU,GAClB,cAAc,GACd,SAAS,GACT,mBAAmB,GACnB,aAAa,GACb,eAAe,GACf,oBAAoB,CAAC;AAEzB,MAAM,MAAM,cAAc,GACtB,MAAM,GACN,KAAK,GACL,YAAY,GACZ,SAAS,GACT,SAAS,GACT,cAAc,GACd,KAAK,CAAC;AAEV,MAAM,MAAM,QAAQ,GAChB,QAAQ,GACR,MAAM,GACN,QAAQ,GACR,QAAQ,GACR,OAAO,GACP,YAAY,GACZ,SAAS,GACT,QAAQ,GACR,YAAY,CAAC;AAEjB,MAAM,WAAW,cAAc;IAC7B,IAAI,EAAE,QAAQ,CAAC;IACf,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE;QACzB,IAAI,EAAE,QAAQ,GAAG,QAAQ,GAAG,SAAS,GAAG,QAAQ,GAAG,OAAO,CAAC;QAC3D,WAAW,CAAC,EAAE,MAAM,CAAC;QACrB,IAAI,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;QACzB,SAAS,CAAC,EAAE,MAAM,CAAC;QACnB,SAAS,CAAC,EAAE,MAAM,CAAC;QAKnB,OAAO,CAAC,EAAE,MAAM,CAAC;QACjB,OAAO,CAAC,EAAE,MAAM,CAAC;QACjB,OAAO,CAAC,EAAE,MAAM,CAAC;KAClB,CAAC,CAAC;IACH,QAAQ,EAAE,SAAS,MAAM,EAAE,CAAC;CAC7B;AAED,MAAM,WAAW,QAAQ;IACvB,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,QAAQ,CAAC;IACf,MAAM,EAAE,MAAM,CAAC;IACf,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,MAAM,EAAE,cAAc,CAAC;IACvB,MAAM,EAAE,UAAU,CAAC;IACnB,YAAY,EAAE,cAAc,EAAE,CAAC;IAC/B,OAAO,EAAE,OAAO,CAAC;IACjB;;;4BAGwB;IACxB,YAAY,EAAE,OAAO,GAAG,QAAQ,CAAC;IACjC;;;;;;qCAMiC;IACjC,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,kBAAkB,CAAC,EAAE,MAAM,EAAE,CAAC;CAC/B;AAED,MAAM,WAAW,YAAY;IAC3B,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,MAAM,CAAC;IACjB,aAAa,EAAE,MAAM,CAAC;IACtB,KAAK,EAAE,QAAQ,EAAE,CAAC;CACnB;AAw8GD,wBAAgB,QAAQ,IAAI,YAAY,CAOvC;AAED,wBAAgB,QAAQ,CAAC,OAAO,EAAE,MAAM,GAAG,QAAQ,GAAG,IAAI,CAGzD;AAED;gEACgE;AAChE,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,QAAQ,GAAG,IAAI,CAO9D;AAED;;;uDAGuD;AACvD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,EAAE,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,MAAM,GAAG,IAAI,CA2CzF;AAED;;sEAEsE;AACtE,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,SAAI,GAAG,MAAM,EAAE,CAO/D"}

package/dist/nac3/internal_manifest.js

@@ -14,6 +14,11 @@
  * ASCII-only.
  */
 import { VERSION as FORGE_VERSION } from '../version.js';
+/* M-02: el catalogo de motivos de un cierre forzado se declara UNA vez
+ * (src/urazuke/overrides.ts) y el schema del verbo lo refleja. Repetir la
+ * lista aca es la segunda fuente de verdad que se desincroniza el dia que
+ * se agregue un motivo. */
+import { OVERRIDE_KIND_NAMES } from '../urazuke/overrides.js';
 /* ============================================================
  * Verb declarations
  *
@@ -49,7 +54,7 @@ const VERBS = [
             type: 'object',
             properties: {
                 title: { type: 'string', description: 'Tab header label. Max 80 chars.', minLength: 1, maxLength: 80 },
-                kind: { type: 'string', description: 'Render mode. doc = DOCUMENTO (reporte/analisis/spec/ARQUITECTURA/DISEÑO): content = HTML por DEFAULT (h1/h2/h3, p, ul/ol, table, blockquote, pre, strong/em; NADA de <script>/<style>/JS -- se sanitiza), se renderiza dentro de una hoja con el look Yujin. Usa HTML siempre para documentos de arquitectura, diseño y specs (formato rico). Tambien acepta markdown como fallback. Usalo por DEFAULT para cualquier documento que generes. bpmn (o flow) = DIAGRAMA DE PROCESO BPMN 2.0 -- USALO cuando el usuario pide un FLUJO / flow / proceso / circuito de negocio (NO el grafo de nodos). content = JSON {lanes?:[{id,label}], nodes:[{id, type, label, lane?, gateway?}], flows:[{from, to, label?}]}; type en startEvent|endEvent|intermediate|task|userTask|serviceTask|scriptTask|sendTask|receiveTask|gateway; gateway en exclusive|parallel|inclusive. graph = grafo de nodos dinamico (relaciones/dependencias, NO procesos): content = JSON {nodes:[{id,label,weight,kind,detail}], edges:[{from,to,kind,label}]}; md/markdown = texto; code/table/tree. html = mini-navegador en iframe sandbox. app = mini-app con JS arbitrario (viz/herramienta) en iframe sandbox aislado; usa app solo si necesitas JS real, sino doc.', enum: ['code', 'table', 'markdown', 'md', 'html', 'app', 'bpmn', 'flow', 'document', 'doc', 'tree', 'graph'] },
+                kind: { type: 'string', description: 'Render mode. doc = DOCUMENTO (reporte/analisis/spec/ARQUITECTURA/DISENO): content = HTML por DEFAULT (h1/h2/h3, p, ul/ol, table, blockquote, pre, strong/em; NADA de <script>/<style>/JS -- se sanitiza), se renderiza dentro de una hoja con el look Yujin. Usa HTML siempre para documentos de arquitectura, diseno y specs (formato rico). Tambien acepta markdown como fallback. Usalo por DEFAULT para cualquier documento que generes. bpmn (o flow) = DIAGRAMA DE PROCESO BPMN 2.0 -- USALO cuando el usuario pide un FLUJO / flow / proceso / circuito de negocio (NO el grafo de nodos). content = JSON {lanes?:[{id,label}], nodes:[{id, type, label, lane?, gateway?}], flows:[{from, to, label?}]}; type en startEvent|endEvent|intermediate|task|userTask|serviceTask|scriptTask|sendTask|receiveTask|gateway; gateway en exclusive|parallel|inclusive. graph = grafo de nodos dinamico (relaciones/dependencias, NO procesos): content = JSON {nodes:[{id,label,weight,kind,detail}], edges:[{from,to,kind,label}]}; md/markdown = texto; code/table/tree. html = mini-navegador en iframe sandbox. app = mini-app con JS arbitrario (viz/herramienta) en iframe sandbox aislado; usa app solo si necesitas JS real, sino doc.', enum: ['code', 'table', 'markdown', 'md', 'html', 'app', 'bpmn', 'flow', 'document', 'doc', 'tree', 'graph'] },
                 content: { type: 'string', description: 'Body text. Max 100000 chars. Para kind=graph: JSON {nodes,edges}. Para kind=bpmn/flow: JSON {lanes?,nodes,flows} (ver kind).', minLength: 1, maxLength: 100000 },
                 language: { type: 'string', description: 'For kind=code: language hint.', maxLength: 40 },
             },
@@ -2962,6 +2967,19 @@ const VERBS = [
                 blocker_who: { type: 'string', maxLength: 80 },
                 priority: { type: 'number', description: '0..100 (0 = critical, 100 = nice-to-have). Default 50.' },
                 related_doc: { type: 'string', maxLength: 200 },
+                /* M-01 (experimento Urazuke, 2026-11-01) -- EL SPEC, por verbo.
+                 *
+                 * La compuerta del peldano 5 (gate.ts, evaluador `plan`) falla
+                 * cuando hay pendientes del plan SIN spec. El CLI podia escribirlo
+                 * (`yf pending add --acceptance ... --how-verified ...`) y el verbo
+                 * NO, asi que un agente que registraba un hallazgo durante el
+                 * recorrido volvia ROJO un peldano ya cerrado y no tenia manera de
+                 * arreglarlo. El metodo terminaba castigando la honestidad: el
+                 * camino barato era no anotar el hallazgo. Aparecio CUATRO veces en
+                 * la corrida. La forma es la del CLI, no una nueva. */
+                acceptance: { type: 'array', description: 'Urazuke peldano 5: criterios de aceptacion, uno por entrada, en forma "dado / cuando / entonces". Sin esto el item cuenta como SIN spec y pone el peldano 5 en rojo.' },
+                how_verified: { type: 'string', maxLength: 2000, description: 'Urazuke peldano 5: como se verifica SIN leer codigo. Va junto con acceptance: la compuerta exige los dos.' },
+                flows: { type: 'array', description: 'Urazuke: los flujos de usuario que toca el item (los que el e2e del peldano 8 tiene que recorrer).' },
             },
             required: ['title', 'category'],
         },
@@ -3000,7 +3018,8 @@ const VERBS = [
                 reason: { type: 'string', enum: ['shipped', 'obsoleted', 'duplicate', 'rejected'] },
                 commit: { type: 'string', description: 'Git SHA that delivered the close. The affected sources are derived from it.', maxLength: 80 },
                 resolution: { type: 'string', description: 'How it was resolved -- the closing history summary (what was done across the evolutive/corrective cycle). Saved as a history entry AND as the technical summary of the implementation record.', maxLength: 4000 },
-                force_reason: { type: 'string', maxLength: 500, description: 'Urazuke: ONLY when the owner explicitly decides to close a workflow task whose step is RED or out of order. The written reason (min 15 chars) is kept in the item history for the audit. Never use it on your own initiative.' },
+                force_reason: { type: 'string', maxLength: 500, description: 'Urazuke: ONLY when the owner explicitly decides to close a workflow task whose step is RED or out of order. The written reason (min 15 chars) is kept in the item history for the audit. Never use it on your own initiative. Requires force_kind.' },
+                force_kind: { type: 'string', maxLength: 60, description: 'Urazuke (M-02): the TYPE of the forced close, mandatory with force_reason so the retrospective can COUNT forced closes per motive. Closed catalogue.', enum: OVERRIDE_KIND_NAMES },
                 functional: { type: 'string', description: 'FUNCTIONAL description of what was delivered: what the user can do now and how it behaves. Mandatory with reason=shipped -- it is not in the diff.', maxLength: 8000 },
                 use_cases: { type: 'array', description: 'Concrete use cases now covered, one per entry.' },
                 files: { type: 'array', description: 'Extra affected sources. Normally empty: with `commit` they come from the SHA.' },
@@ -3057,6 +3076,13 @@ const VERBS = [
                 blocker_who: { type: 'string', maxLength: 80 },
                 priority: { type: 'number', description: '0..100' },
                 related_doc: { type: 'string', maxLength: 200 },
+                /* M-01 -- el spec tambien por EDIT, no solo por add: un item
+                 * abierto antes de tener spec tiene que poder adquirirlo sin pasar
+                 * por la consola. Pasar uno de los dos campos reemplaza el spec
+                 * entero; no pasar ninguno lo deja intacto. */
+                acceptance: { type: 'array', description: 'Urazuke peldano 5: criterios de aceptacion "dado / cuando / entonces", uno por entrada. Pasarlos REEMPLAZA el spec del item.' },
+                how_verified: { type: 'string', maxLength: 2000, description: 'Urazuke peldano 5: como se verifica sin leer codigo. Va junto con acceptance.' },
+                flows: { type: 'array', description: 'Urazuke: los flujos de usuario que toca el item.' },
             },
             required: ['id'],
         },