@ingeniomaps/cauce 0.43.0 → 0.47.0

package/template/planning/PROTOCOL.md

@@ -8,12 +8,18 @@ invariantes.
 - Épica: frontmatter `epic/title/status/service`; criterios `**CN**`; historias con slug, `(→ CN)` y
   `(service: ruta)`.
 - Hito: `## Hito slug — Título`.
-- Tarea: `- [ ] **slug** [directo|lite|full] — descripción. _Aceptación: observable._ (service: ruta)`;
-  puede heredar aceptación usando `(→ CN) (epic: NNN)`.
+- Tarea: `- [ ] **slug** [express|directo|lite|full] — descripción. _Aceptación: observable._ (service: ruta) (cast: quien-entrega → quien-revisa, otro)`;
+  puede heredar aceptación usando `(→ CN) (epic: NNN)`. Lane y cast son opcionales: sin ellos la tarea
+  está sin clasificar, que es un estado y no un error.
 - DONE: entrada `[x]` con `acept:`, `done:`, `qa:`, `tests:` y `commit:`. `tests:` enlaza cada criterio
   mediante `CN → prueba`; usa `A → prueba` cuando no hay épica o `n/a — razón` si no existe una
   superficie ejecutable. `decisions:` es opcional y, si aparece, cita `[fuente: ...]` o
-  `[supuesto: ...]`.
+  `[supuesto: ...]`. `commit:` apunta a `<sha> <asunto>`, o a `n/a — razón` cuando la tarea no
+  produce commit.
+- Acción humana: fila `| tarea | estado | origen | acción y condición de desbloqueo |`, con el estado
+  en el vocabulario cerrado `pendiente | resuelta` —la fecha puede ir detrás—. Mientras la fila no
+  esté resuelta, su tarea no se toma; un estado fuera del vocabulario es un error de `check` y no un
+  bloqueo silencioso.
 - WIP activo: frontmatter y checklist; inactivo: `status: IDLE`.
 
 ## Gates de arranque
@@ -28,35 +34,59 @@ invariantes.
 
 1. Triage: inspeccionar estado y cambios existentes.
 2. Pick: primera tarea no bloqueada del primer hito.
-3. Ready: exigir aceptación concreta y decisiones resueltas.
-4. Decompose: dividir trabajo mayor a `maxTaskHours`.
-5. Plan y Critique: entender contexto, escribir plan y atacarlo una vez.
-6. WIP: persistir el plan aprobado antes del primer cambio.
-7. Build: alcance exacto, progreso tildado, RED/GREEN/VERIFY aplicable.
-8. Review: calidad y seguridad según la superficie modificada.
-9. Verify: ejecutar los gates declarados por el servicio y registrar exit codes.
-10. QA: probar la aceptación por el camino que usa un consumidor real.
-11. Commit: stage explícito y un commit verificable por tarea.
-12. Done: mover la tarea, registrar evidencia, limpiar WIP y cerrar/archivar la épica si corresponde.
-13. Cierre: check verde, deuda residual al INBOX y checkpoint entre hitos.
+3. Classify: si la tarea no declara lane y cast, decidirlos y escribirlos en su línea.
+4. Ready: exigir aceptación concreta y decisiones resueltas.
+5. Decompose: dividir trabajo mayor a `maxTaskHours` o con más de cinco condiciones de aceptación.
+6. Plan y Critique: entender contexto, escribir plan y atacarlo una vez.
+7. WIP: persistir el plan aprobado antes del primer cambio.
+8. Build: alcance exacto, progreso tildado, RED/GREEN/VERIFY aplicable.
+9. Review: calidad y seguridad según la superficie modificada.
+10. Verify: ejecutar los gates declarados por el servicio y registrar exit codes.
+11. QA: probar la aceptación por el camino que usa un consumidor real.
+12. Commit: stage explícito y commits verificables, uno por naturaleza del diff.
+13. Done: mover la tarea, registrar evidencia, limpiar WIP y cerrar/archivar la épica si corresponde.
+14. Cierre: check verde, deuda residual al INBOX y checkpoint entre hitos.
 
 ## Lanes
 
-- `directo`: cambio mecánico; Build, Verify, Commit y Done.
-- `lite`: omite descomposición y crítica; mantiene review y evidencia.
-- `full` o sin tag: todas las fases.
+El lane dice cuánta ceremonia merece la tarea y el cast quiénes la miran. Son una sola decisión —la
+clasificación—, se toma al escribir la tarea y viaja en su línea, así que se decide una vez y no una
+vez por corrida. La tarea que llega sin ella se clasifica antes de ejecutarse.
 
-El lane reduce ceremonia, nunca seguridad, aceptación ni evidencia.
+- `express`: la aceptación nombra un valor literal y el resultado no lo mira nadie —un typo, un umbral
+  interno, un renombre—; WIP, Build, Verify, Commit y Done.
+- `directo`: igual de mecánico, pero cambia una superficie que alguien ve; agrega el review del cargo
+  que nombra el cast.
+- `lite`: comportamiento nuevo dentro de un servicio con superficie conocida; agrega Ready, Plan y QA.
+- `full` o sin tag: cruza contratos entre servicios, datos, autenticación o permisos, o la aceptación
+  tiene un borde sin decidir; todas las fases.
+
+El lane reduce ceremonia, nunca seguridad, aceptación ni evidencia: Verify y el WIP corren en los
+cuatro. Lo que decide el carril es la superficie del cambio y no su tamaño en líneas — un `if` en el
+chequeo de permisos es `full`, y un componente entero de presentación puede ser `directo`.
 
 ## Invariantes
 
 1. Una tarea tiene un dueño de estado: roadmap → BACKLOG → overlay WIP → DONE.
-2. Un solo runner a la vez; WIP activo es mutex.
-3. INBOX nunca se ejecuta automáticamente.
-4. No declarar éxito sin comandos, resultados y exit codes reales.
+2. Un solo runner a la vez; WIP activo es mutex — `business-rules/system/BR-OPS-001`.
+3. INBOX nunca se ejecuta automáticamente — `business-rules/system/BR-OPS-002`.
+4. No declarar éxito sin comandos, resultados y exit codes reales — `business-rules/system/BR-OPS-004`.
 5. No inventar credenciales ni decisiones; registrar HUMAN_ACTIONS.
 6. No ampliar alcance; lo adyacente vuelve al INBOX.
 7. No reescribir este proceso dentro de una tarea de producto.
 8. No push, amend, force, deploy o escritura externa sin autorización explícita.
 9. Todo gate manual dice qué pasó, qué debe hacer la persona y cómo continuar.
 10. El repositorio de código, no planning, es dueño del commit de producto.
+
+## Razones de parada
+
+Toda parada se nombra con una de éstas, en cualquier runner:
+
+`awaiting-review` · `blocked-on-human` · `not-ready` · `plan-rejected` · `review-unresolved` ·
+`verify-regression` · `verify-inconsistent` · `qa-failed` · `commit-failed` · `budget-low`
+
+Y deja el estado consistente: la tarea sin marcar, el WIP activo si es resumible, y —si necesita a una
+persona— la fila en `HUMAN_ACTIONS.md` o el `AWAITING_REVIEW.md` ya escritos.
+
+`ops context` emite las dos que puede determinar solo, `awaiting-review` y `blocked-on-human`; las
+demás las nombra la fase que para, que es la única que sabe por qué.

package/template/planning/README.md

@@ -1,18 +1,38 @@
 # Planning — intención, estado y evidencia
 
+## Estado de la corrida
+
+Se lee y se escribe en cada tarea.
+
 | Pieza | Responsabilidad |
 |---|---|
-| `INBOX.md` | Ideas y deuda sin autorización de ejecución. |
-| `roadmap/` | Especificaciones de épicas y criterios del QUÉ. |
 | `BACKLOG.md` | Única cola de tareas promovidas y listas. |
 | `WIP.md` | Única tarea en vuelo; recuperación y mutex. |
 | `DONE.md` | Evidencia activa de tareas terminadas. |
-| `done/` | Historial inmutable por épica cerrada. |
 | `HUMAN_ACTIONS.md` | Acciones externas que requieren una persona. |
 | `AWAITING_REVIEW.md` | Gate efímero; mientras existe no inicia trabajo. |
+
+## Intención y horizonte
+
+Se decide antes de ejecutar y no cambia dentro de una tarea.
+
+| Pieza | Responsabilidad |
+|---|---|
+| `INBOX.md` | Ideas y deuda sin autorización de ejecución. |
+| `roadmap/` | Especificaciones de épicas y criterios del QUÉ. |
 | `adr/` | Decisiones arquitectónicas durables. |
 | `business-rules/` | Invariantes observables de negocio y operación. |
 | `delivery/` | Camino objetivo para ramas, ambientes, releases y rollback. |
 | `rules/` | Reglas transversales de craft. |
 
-El protocolo exacto está en `PROTOCOL.md`; la explicación visual en `FLOW.md`.
+## Historial
+
+Evidencia que no se reescribe.
+
+| Pieza | Responsabilidad |
+|---|---|
+| `done/` | Historial inmutable: una épica cerrada por archivo, más las acciones humanas resueltas. |
+| `reports/` | Informes de recorridos de equipo. |
+
+El protocolo exacto está en `PROTOCOL.md`, la explicación visual en `FLOW.md` y los principios que
+sostienen a los dos en `METHODOLOGY.md`.

package/template/planning/adr/000-template.md

@@ -1,8 +1,9 @@
 # ADR-NNN — Título corto en imperativo
 
-**Estado:** Propuesto | Aceptado | Obsoleto | Reemplazada por [NNN](./NNN-slug.md)
+**Estado:** Propuesto
 **Fecha:** YYYY-MM-DD
 **Responsable:** Persona o equipo
+**Reemplaza:** ninguna | [NNN](NNN-slug.md)
 
 > Una frase opcional que delimita qué decide esta ADR y qué queda fuera.
 
@@ -39,9 +40,3 @@ Una ADR decide una dirección durable; no reemplaza el plan de implementación n
 
 Separar lo construido de lo objetivo. Enumerar pruebas, migraciones y follow-ups pendientes. Una ADR propuesta
 no se presenta como implementada; una aceptada debe indicar cómo se verificó o qué parte sigue en transición.
-
-## Relaciones
-
-- Reemplaza: ninguna | [ADR-NNN](./NNN-slug.md).
-- Depende de: ninguna | referencia.
-- Follow-ups: tarea, épica o entrada de `INBOX.md`.

package/template/planning/adr/README.md

@@ -18,11 +18,19 @@ de una, crea una ADR propia que documente la excepción; no modifica silenciosam
 - `Propuesto`: decidido pero aún no implementado o pendiente de aprobación.
 - `Aceptado`: vigente, con implementación o transición descrita honestamente.
 - `Obsoleto`: desaconsejado, aunque todavía pueda existir en el sistema.
-- `Reemplazada por [NNN]`: sustituido por otra decisión; el archivo original no se elimina.
+- `Reemplazada por [NNN](NNN-slug.md)`: sustituido por otra decisión; el archivo original no se elimina.
+  Se puede cerrar con la fecha del reemplazo entre paréntesis.
+
+El estado se escribe elegido, nunca como lista de opciones: `check` rechaza la línea que todavía trae el
+menú, porque una decisión que no dice si rige no decide nada. Por eso el molde nace en `Propuesto`.
+
+Lo que una decisión reemplaza va en el encabezado, junto al estado. Los follow-ups van donde se ejecutan
+—una tarea, una épica o el INBOX—, y lo construido contra lo pendiente en `## Estado de implementación`.
 
 ## Cómo crear una ADR del proyecto
 
-1. Copiar `000-template.md` como `NNN-slug-corto.md`.
+1. Copiar `000-template.md` como `NNN-slug-corto.md`. El nombre lleva el número: es de donde sale la
+   identidad con que se detecta un override, y por él se cita la decisión.
 2. Documentar contexto, fuentes, supuestos, decisión, alternativas y costos.
 3. Declarar por separado lo construido y lo pendiente.
 4. Al reemplazarla, enlazar la nueva ADR sin borrar el historial.
@@ -37,3 +45,5 @@ archivo lo mantiene Cauce, así que una fila agregada acá se perdería en el pr
 - [OPS-002](system/OPS-002-runtime-autocontenido-y-neutral-al-runner.md): runtime portable y neutral.
 - [OPS-003](system/OPS-003-integraciones-seguras-por-staging.md): integraciones mediante staging seguro.
 - [OPS-004](system/OPS-004-promocion-humana-y-evidencia-verificable.md): promoción controlada y verificable.
+- [OPS-005](system/OPS-005-catalogo-en-el-paquete.md): el catálogo viaja dentro del paquete.
+- [OPS-006](system/OPS-006-ceremonia-por-superficie.md): la ceremonia escala con la superficie del cambio.

package/template/planning/adr/system/OPS-005-catalogo-en-el-paquete.md

@@ -0,0 +1,56 @@
+# OPS-005 — Distribuir el catálogo dentro del paquete
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-22
+**Responsable:** Cauce
+**Reemplaza:** ninguna
+
+> Decide cómo llegan los cargos y los recorridos a una instancia. No decide qué contiene cada cargo.
+
+## Contexto
+
+Una instancia necesita el catálogo de cargos y equipos para resolver el `cast` de una tarea y para correr un
+recorrido. Copiarlo en cada instalación lo vuelve un archivo del proyecto: deja de recibir mejoras, y dos
+empresas creadas con seis meses de diferencia terminan con contratos distintos bajo el mismo nombre.
+
+El catálogo tampoco es como el molde. `template/` se copia una vez y la empresa lo edita —es suyo—; un cargo
+del sistema se mantiene acá y se mejora versión a versión [fuente: OPS-002-runtime-autocontenido-y-neutral-al-runner.md].
+
+## Decisión
+
+**El catálogo viaja dentro del paquete y se resuelve desde ahí, no se copia a la instancia.** `ops agents fork`
+existe para el caso contrario: cuando una empresa quiere apartarse de un cargo, lo copia y pasa a mantenerlo,
+con una fila en su `HISTORY.md` que marca dónde termina lo nuestro y empieza lo suyo.
+
+Lo que el paquete publica es el contrato de cada cargo —`SKILL.md`, `references/`, los casos de evaluación,
+`sources.yaml` y `HISTORY.md`—. La evidencia de nuestras propias corridas queda fuera: informes, propuestas y
+veredictos son lo que produjo nuestra versión del contrato, y una copia que los heredara recibiría una garantía
+que no rindió.
+
+## Alternativas consideradas
+
+- **Copiar el catálogo en cada `init`:** cada instancia queda congelada en la versión del día que se creó, y
+  `upgrade` no puede mejorarlo sin pisar lo que la empresa haya editado.
+- **Resolverlo desde una API remota:** rompe que la instalación sea autocontenida y agrega una dependencia de
+  red a una operación que hoy funciona sin conexión.
+
+## Consecuencias
+
+**Ganamos:**
+
+- Un cargo del sistema mejora para todas las instancias con un `upgrade`, sin migración.
+- `fork` es explícito: apartarse queda registrado en vez de ocurrir por deriva.
+
+**Costos que aceptamos:**
+
+- El peso del paquete es el del catálogo entero, aunque una empresa use tres cargos. Se acota publicando el
+  contrato y no la evidencia, que es lo que lo hacía crecer sin techo.
+- Un cargo del sistema no se puede editar en la instancia: hay que forkearlo, y eso es una decisión.
+
+## Estado de implementación
+
+Construido: el catálogo se resuelve desde el paquete, `fork` copia excluyendo informes, propuestas y veredictos,
+y `files` en `package.json` deja fuera esas mismas rutas al publicar.
+
+Pendiente: nada. La exclusión tiene prueba que corre `npm pack --dry-run` y verifica las dos mitades — que la
+evidencia no viaje y que el contrato sí.

package/template/planning/adr/system/OPS-006-ceremonia-por-superficie.md

@@ -0,0 +1,60 @@
+# OPS-006 — Escalar la ceremonia con la superficie del cambio
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-22
+**Responsable:** Cauce
+**Reemplaza:** ninguna
+
+> Decide cuánto proceso corre una tarea y quién la mira. No decide qué fases existen.
+
+## Contexto
+
+La máquina de fases sirve para el cambio que cruza contratos, datos o permisos. Corrida entera sobre un typo o
+un umbral interno cuesta un plan, una crítica, un review y un QA para una línea, y ese costo no lo paga la
+tarea: lo paga la cola, porque cada vuelta es contexto que se reenvía [fuente: ../../rules/system/process.md].
+
+Bajar la ceremonia por tamaño es la salida obvia y es la equivocada. Un `if` en el chequeo de permisos son tres
+líneas y puede tirar la autorización de todo un servicio; un componente entero de presentación son cuatrocientas
+y lo peor que hace es verse mal. Lo que predice el riesgo es qué superficie toca el cambio, no cuánto ocupa.
+
+## Decisión
+
+**La tarea declara un carril, y el carril decide qué fases corren; el cast decide quién la mira.** Son una sola
+decisión —la clasificación— y viaja escrita en la línea de la tarea, así que se toma una vez al promoverla y no
+una vez por corrida.
+
+Lo que fija el carril es la superficie: `express` cuando la aceptación nombra un valor literal y el resultado no
+lo mira nadie; `directo` cuando es igual de mecánico pero cambia algo que alguien ve; `lite` para comportamiento
+nuevo dentro de un servicio conocido; `full` cuando cruza contratos, datos, autenticación o permisos, o cuando
+la aceptación tiene un borde sin decidir.
+
+El carril reduce ceremonia y nunca seguridad, aceptación ni evidencia: WIP, Verify y el registro en DONE corren
+en los cuatro.
+
+## Alternativas consideradas
+
+- **Derivar el carril en cada corrida:** costaba una llamada por tarea y el resultado se tiraba al terminar,
+  así que la misma tarea podía clasificarse distinto dos veces sin que nadie lo viera.
+- **Una sola ceremonia para todo:** predecible y cara. La cola avanza al ritmo de la tarea más chica.
+- **Escalar por tamaño del diff:** medible y mal correlacionado con el riesgo, que es lo que se quiere acotar.
+
+## Consecuencias
+
+**Ganamos:**
+
+- La tarea mecánica no paga el proceso de la tarea riesgosa, y la riesgosa no se abarata por ser corta.
+- La clasificación es auditable antes de ejecutar: está escrita y `check` la contrasta contra el catálogo.
+
+**Costos que aceptamos:**
+
+- Un carril mal elegido baja ceremonia donde hacía falta. Se acota con el criterio escrito y con que la tarea
+  sin clasificar sea un estado válido que dispara al clasificador, en vez de un default silencioso.
+- Cuatro carriles son cuatro contratos que mantener alineados entre la prosa, el motor y el workflow.
+
+## Estado de implementación
+
+Construido: el vocabulario vive en el motor, `check` rechaza un carril inexistente y distingue la tarea sin
+clasificar, y una prueba contrasta las copias del workflow y del protocolo contra el motor.
+
+Pendiente: no hay medición de si el carril elegido fue el correcto. Se sabría comparando hallazgos de review
+por carril, y hoy no se registra esa dimensión en DONE.

package/template/planning/business-rules/000-template.md

@@ -7,6 +7,9 @@ se citan como `[fuente: ruta#sección|ADR-NNN|URL]`; lo desconocido se marca `[s
 
 ## Reglas
 
+El `BR-` es parte del id, no decoración: una épica o un ADR cita la regla como `[fuente: BR-DOM-001]`,
+y `check` rechaza un id sin él. `DOM` es el dominio en mayúsculas, `NNN` correlativo dentro del dominio.
+
 | ID | Regla | Condición y resultado |
 |---|---|---|
 | BR-DOM-001 | Nombre breve | Cuando ocurre X, el sistema produce o impide Y. |

package/template/planning/business-rules/system/BR-OPS-001-una-sola-tarea-activa.md

@@ -5,6 +5,9 @@
 WIP protege la exclusión mutua y permite recuperar una ejecución interrumpida.
 [fuente: ../../adr/system/OPS-001-planificacion-como-fuente-de-verdad.md]
 
+Elabora el invariante 2 de `../../PROTOCOL.md`, que lo enuncia en una línea: acá viven sus bordes
+y su evidencia. Cambiar una sin la otra las separa.
+
 ## Reglas
 
 | ID | Regla | Condición y resultado |

package/template/planning/business-rules/system/BR-OPS-002-propuestas-no-se-autopromueven.md

@@ -5,6 +5,9 @@
 Proponer genera una opción revisable; no concede autoridad para alterar prioridades o comprometer alcance.
 [fuente: ../../adr/system/OPS-004-promocion-humana-y-evidencia-verificable.md]
 
+Elabora el invariante 3 de `../../PROTOCOL.md`, que lo enuncia en una línea: acá viven sus bordes
+y su evidencia. Cambiar una sin la otra las separa.
+
 ## Reglas
 
 | ID | Regla | Condición y resultado |

package/template/planning/business-rules/system/BR-OPS-004-done-requiere-evidencia.md

@@ -5,11 +5,14 @@
 Cerrar una tarea es una afirmación sobre comportamiento observado, no una impresión del ejecutor.
 [fuente: ../../adr/system/OPS-004-promocion-humana-y-evidencia-verificable.md]
 
+Elabora el invariante 4 de `../../PROTOCOL.md`, que lo enuncia en una línea: acá viven sus bordes
+y su evidencia. Cambiar una sin la otra las separa.
+
 ## Reglas
 
 | ID | Regla | Condición y resultado |
 |---|---|---|
-| BR-OPS-004 | Cierre con evidencia | Una entrada en DONE registra aceptación, fecha, QA y commit verificables. |
+| BR-OPS-004 | Cierre con evidencia | Una entrada en DONE registra aceptación, comandos con sus exit codes, QA, la prueba que sostiene cada criterio citado, y el commit. |
 
 ## Por qué existe cada regla
 

package/template/planning/reports/README.md

@@ -6,6 +6,12 @@ posteriores y cualquier recorrido que registre lo aprendido en vez de proponer t
 Un archivo por informe, nombrado `<AAAA-MM-DD>-<slug>.md`. Son evidencia: se commitean y no se
 reescriben. Si una conclusión cambia, se agrega un informe nuevo que lo diga.
 
-Los seguimientos que salen de un informe van a la sección Lecciones de `../INBOX.md` sin promover, y
-las acciones que requieren una persona a `../HUMAN_ACTIONS.md`. Convertir un seguimiento en trabajo es
-una decisión humana.
+La forma del informe no la fija este directorio: la declara el recorrido que lo produce. Cada etapa de
+un recorrido dice qué produce y con qué condición de salida —una revisión de incidente entrega línea de
+tiempo y alcance, un triage entrega la reproducción y a quiénes alcanza—, y el informe teje eso. Por
+eso no hay molde acá: uno solo contradiría a dos de los tres recorridos que escriben informes.
+
+Los seguimientos van al INBOX sin promover, cada uno a la sección que le corresponde por su sujeto: lo
+que propone un cambio del producto, con su evidencia, a Propuestas; lo que se aprendió sobre cómo
+trabajamos, a Lecciones. Las acciones que requieren una persona van a `../HUMAN_ACTIONS.md`. Convertir
+un seguimiento en trabajo es una decisión humana.

package/template/planning/roadmap/README.md

@@ -52,11 +52,19 @@ archivos auxiliares vacíos ni se usa una carpeta si la épica sigue siendo fác
 
 - Frontmatter: `epic`, `title`, `status` y `service`.
 - Resultado: cambio esperado para el usuario o sistema.
-- Fuera de alcance: límites que evitan expansión accidental.
-- Criterios `CN`: resultados observables y verificables.
-- Contexto relevante: rutas existentes, patrones, ADR y reglas aplicables.
+- Fuera de alcance: lo que se decidió no hacer, para que no entre solo.
+- Criterios `CN`: disparador, sujeto y resultado observable. Los bordes —input vacío, permiso ajeno,
+  dependencia caída— se escriben como criterios y no como prosa, porque sólo así se rastrean y se prueban.
+- Contexto relevante: rutas existentes verificadas, patrones, y los ADR e invariantes de
+  `../business-rules/` que rigen el resultado.
 - Historias: incrementos de hasta cuatro horas, con slug, servicio y referencias `(→ CN)`.
-- Riesgos y decisiones humanas: incertidumbres, dependencias y acciones que un runner no puede resolver.
+- Riesgos y decisiones humanas: lo que no se puede decidir acá — supuestos, dependencias y acciones que
+  un runner no puede resolver. Lo que sí se decidió y queda afuera va en Fuera de alcance.
+
+Lo que todavía no se decidió se escribe con el marcador `Por definir`, en la sección que corresponda.
+Una épica `open` puede llevarlos —es un borrador—; `check` los rechaza al pasar a `active`. Por eso la
+plantilla no trae ninguno: lo que se copia no puede incluir algo que haya que borrar para poder
+activar la épica.
 
 Cada criterio debe estar cubierto por al menos una historia. Una historia puede cubrir varios criterios y todo
 slug debe ser estable y único en el roadmap.

package/template/planning/roadmap/epic-000-template.md

@@ -13,20 +13,34 @@ Qué cambia para el usuario o el sistema.
 
 ## Fuera de alcance
 
-- Límites explícitos.
+- Lo que decidimos no hacer en esta épica, para que no entre solo. Lo que todavía no se puede decidir
+  no va acá: va en Riesgos.
 
 ## Criterios
 
-- **C1** — Comportamiento observable y verificable.
+Cada criterio nombra tres cosas: el disparador, el sujeto y el resultado observable. Sin disparador no
+se sabe cuándo probarlo; sin sujeto, a quién. Los bordes son criterios como cualquier otro —el input
+vacío, el permiso ajeno, el sistema del que depende caído—: escritos acá se rastrean y se prueban;
+escritos en prosa se pierden.
+
+Pasando de siete, `check` pide decidir (R17): o son dos resultados con vidas distintas y la épica se
+parte, o es uno solo y se escribe `(sin partir: <razón>)` en cualquier parte de este archivo. La razón
+es para quien la lea en tres meses, no para silenciar el mensaje.
+
+- **C1** — Cuando <disparador>, <sujeto> obtiene <resultado observable>.
+- **C2** — Al <borde>, <sujeto> obtiene <resultado observable>, y <lo que no cambia> no cambia.
 
 ## Contexto relevante
 
-- Estado actual, reglas, ADR y rutas reales — verificadas en el repositorio — que el ejecutor debe leer.
+- Estado actual y rutas reales, verificadas en el repositorio; los ADR de `../adr/` y las invariantes
+  de `../business-rules/` que rigen este resultado. Es lo que el ejecutor lee antes de decidir el cómo.
 
 ## Historias
 
 - [ ] **slug-de-historia** (→ C1) — Incremento ≤4h. _Aceptación: resultado observable._ (service: ruta)
+- [ ] **slug-del-borde** (→ C2) — Incremento ≤4h. _Aceptación: resultado observable._ (service: ruta)
 
 ## Riesgos y decisiones humanas
 
-- Riesgos, supuestos, dependencias o acciones humanas. Escribir `Ninguno` cuando se hayan revisado.
+- Lo que no se puede decidir acá: supuestos, dependencias y acciones que necesitan una persona.
+  Escribir `Ninguno` cuando se hayan revisado.

package/template/planning/rules/README.md

@@ -2,13 +2,21 @@
 
 `system/` pertenece a Cauce y se reemplaza completo en cada actualización:
 
-- `system/process.md`: planificación, alcance, review y sincronización de estado.
-- `system/code-shape.md`: simplicidad y forma del cambio.
-- `system/commits.md`: historia versionada y entrega.
-- `system/conduct.md`: trato con sistemas externos y obligación de entregar al negarse.
+- `system/process.md` — R1..R4, R16, R17, R20, R21: planificación, alcance, review, sincronización de estado,
+  medición y retomar lo interrumpido.
+- `system/code-shape.md` — R5..R7, R11, R18: simplicidad y forma del cambio.
+- `system/commits.md` — R8..R10: historia versionada y entrega.
+- `system/conduct.md` — R12..R15, R19: trato con sistemas externos, lo que llega de ellos, y la
+  obligación de entregar al negarse.
+
+El número es el identificador: una regla se cita por él desde un cargo, un workflow o una entrada de
+DONE, y por eso no se reordena ni se reusa.
 
 Las reglas propias del proyecto van en este directorio, junto a `system/`, y nunca se tocan al
-actualizar. Para cambiar una regla del sistema, escribí la tuya con el mismo nombre: la del proyecto
-manda y `check` reporta el override en vez de fallar.
+actualizar. **Se numeran `P1..Pn`**: `R` queda reservado al sistema, y `check` rechaza un `R` definido
+fuera de él para que no existan dos reglas con el mismo nombre.
+
+Para cambiar una regla del sistema, escribí la tuya **con el mismo nombre de archivo**: ahí redefinir
+sus números es la función, la del proyecto manda, y `check` reporta el override en vez de fallar.
 
 Las convenciones específicas de lenguaje viven junto al servicio que usa ese lenguaje.

package/template/planning/rules/system/code-shape.md

@@ -8,10 +8,31 @@ Preferir la solución más simple que cubre toda la aceptación, sin infraestruc
 
 No reformatear, renombrar ni reparar elementos ajenos a la tarea.
 
+Lo que aparece durante el trabajo y el plan no previó no es ajeno, y no tiene por destino el silencio.
+Si esta tarea lo puede fijar, entra con la prueba que lo fija; si es una decisión que no le toca, queda
+registrada con qué la cierra y quién puede tomarla. Implementarlo sin prueba lo vuelve invisible y
+descartarlo lo pierde: en los dos casos el próximo que lo encuentre empieza donde empezó éste.
+
+Lo que impide entregar es otra cosa, y ya tenía su camino: se dice que no se pudo, con el bloqueo
+nombrado. Confundirlo con lo anterior frena entregas completas por un borde que alguien iba a decidir de
+todos modos —toda aceptación escrita en prosa tiene uno—, y un freno que salta siempre se termina apagando.
+
+Y lo que separa un destino del otro es quién puede resolverlo, no cuán grave parece. Una prueba que
+falta la escribe quien está trabajando; una definición que falta, no. Tratarlas igual interrumpe a una
+persona por lo que se resolvía solo, o resuelve solo lo que no le tocaba.
+
 ## R7 — Límites legibles
 
-Extraer responsabilidades cuando una unidad deja de poder entenderse y probarse aisladamente; no usar
-límites numéricos como sustituto del juicio.
+Extraer responsabilidades cuando una unidad deja de poder entenderse y probarse aisladamente.
+
+Un umbral no decide la división: la dispara. Al cruzarlo se revisa si la unidad mezcla dos propósitos con
+ciclos de vida distintos, y recién ahí se parte, o se deja con la razón escrita. Un número usado como límite
+se cumple partiendo por la mitad lo que era una sola cosa; usado como disparador encuentra lo que nadie iba
+a mirar. Cuáles son esos números los fija el proyecto, porque dependen del lenguaje y de la superficie.
+
+Lo que crece por diseño no se juzga por tamaño: un registro que sólo agrega, una salida generada o un
+histórico son largos porque eso es lo que son. Y una división que duplica un hecho es peor que el archivo
+largo — una de las dos copias se pudre y nada falla.
 
 ## R11 — Comentarios con destinatario
 
@@ -29,3 +50,15 @@ nada falla.
   qué algo se aparta del idioma habitual, y qué quedó a medias.
 
 Un comentario que cuesta escribir suele estar señalando el código, no la falta de palabras.
+
+## R18 — Un doble se justifica y los datos salen de una fábrica
+
+Todo doble de prueba —mock, stub, fake, spy— declara en una línea por qué existe, y se busca en el lugar
+compartido antes de escribir uno nuevo. Los datos de ejemplo salen de una fábrica, nunca de un volcado de
+producción ni de una credencial real.
+
+El enemigo no es el doble: es el test que afirma estructura en vez de conducta. Una suite entera puede
+quedar verde con el defecto adentro sin que sobre un solo doble — lo que faltaba era el caso que nadie
+escribió. Por eso se justifica y se reúsa en vez de prohibirse: un doble sin razón escrita se copia, y la
+copia deja de coincidir con lo que reemplaza sin que ninguna prueba lo note.
+

package/template/planning/rules/system/commits.md

@@ -1,14 +1,36 @@
 # Commits y entrega
 
-## R8 — Un commit por tarea
+## R8 — Un commit por naturaleza
 
 Stagear rutas explícitas, revisar el diff staged y crear un Conventional Commit en inglés. No usar
 `git add .`, `git add -A`, amend, force ni trailers de IA.
 
+Dónde corta un commit lo decide la naturaleza del diff, no su tamaño ni un conteo. Una tarea suele
+tener una sola, y por eso un commit por tarea es lo habitual; cuando tiene dos, se hacen dos. Un
+refactor y el arreglo de traducción que lo acompaña, juntos en un commit, ya no se pueden revertir
+por separado, y quien revise tiene que volver a separarlos a mano.
+
+La unidad de aceptación y de evidencia sigue siendo la tarea: su entrada de DONE registra todos los
+commits que produjo, separados por `;`. Partir el diff no parte la aceptación.
+
 ## R9 — El artefacto manda
 
 Tests verdes no reemplazan build, paquete, imagen o migración cuando son parte del artefacto entregable.
 
+Verde tampoco prueba lo que la tarea prometió. El criterio de aceptación que ningún test asercia no está
+cubierto, y el que dice cubrirlo sin aserciar esa propiedad tampoco lo cubre. Eso se ve leyendo el fuente
+del test, no su salida: un exit code no distingue la prueba que sostiene el criterio de la que lo nombra.
+Y una prueba que nunca se vio fallar no muestra que su aserción funcione: el rojo previo es lo único que
+la separa de una que pasa haga lo que haga el código.
+
+Pero el rojo previo prueba ausencia —el método no existe, la pantalla no está montada—, y eso no distingue
+una implementación sutilmente equivocada de una correcta. Lo que sí la distingue es romper, ya con el código
+puesto, exactamente lo que el caso dice cuidar, y verlo ponerse rojo por eso. Si no se pone rojo, no lo cuida,
+y la cobertura no lo va a decir: mide qué líneas se ejecutan, no qué defectos se atrapan.
+
+La precondición del caso también cuenta. Si el estado en que arranca no puede ocurrir por el camino de
+producción, lo que prueba tampoco: queda verde para siempre sobre algo que nadie va a vivir.
+
 ## R10 — Publicación humana por defecto
 
 Push, PR, merge, tags, deploy y rollback requieren la autorización configurada para el proyecto.