@ingeniomaps/cauce 0.68.0 → 0.70.0

package/template/AGENTS.md

@@ -150,9 +150,12 @@ que hacía falta, apagala después, y que la razón quede escrita donde alguien
 Antes de abrir un archivo de `planning/`, preguntarle al CLI: es determinista, no gasta contexto y no
 muta nada.
 
-- `node tools/ops.js context planning` — gate, mutex de WIP y la tarea que corresponde ahora, con su
-  aceptación y sus criterios. Es la entrada correcta para empezar a trabajar.
+- `node tools/ops.js context planning [--hito <slug>]` — gate, mutex de WIP y la tarea que corresponde
+  ahora, con su aceptación y sus criterios. Es la entrada correcta para empezar a trabajar. Con `--hito`
+  la cola se acota a ese hito, que es como un equipo se reparte trabajo sin coordinarse.
 - `node tools/ops.js tree planning` — panorama de roadmap, backlog, WIP, inbox y done.
+- `node tools/ops.js recurring planning [--promote <qué>]` — qué trabajo recurrente venció y con
+  qué línea se promueve. Emite esa línea; escribirla en `BACKLOG.md` es de una persona.
 - `node tools/ops.js check planning` — validación de contratos y trazabilidad.
 - `node tools/ops.js evidence planning [--task <slug>]` — contrasta la evidencia de una entrada de DONE
   contra lo que no escribió su autor: si el artefacto que `tests:` nombra existe en las raíces de
@@ -161,8 +164,49 @@ muta nada.
   nombrada haya corrido —eso depende del runner, y varios no la nombran al pasar— ni reemplaza a leer
   su fuente, que es lo que R9 pide.
 
-Los cuatro aceptan `--json`. Leer `BACKLOG.md`, `WIP.md` o `HUMAN_ACTIONS.md` completos sólo cuando haga
-falta editarlos o cuando el CLI no responda la pregunta.
+Los cinco aceptan `--json`. Leer `BACKLOG.md`, tu `wip/<runner>.md`, `HUMAN_ACTIONS.md` o `RECURRING.md`
+completos sólo cuando haga falta editarlos o cuando el CLI no responda la pregunta.
+
+## Cómo tomar trabajo
+
+Con equipo, la tarea que `context` devuelve puede estar libre o ya ser tuya, y la salida lo dice. Libre
+se toma antes de empezar:
+
+- `node tools/ops.js claim planning <tarea>` — la reserva a tu nombre y escribe `planning/claims/<tarea>.md`.
+- `node tools/ops.js release planning <tarea>` — la devuelve a la cola.
+
+Una tarea que declara `(depende: slug)` no se ofrece ni se puede tomar hasta que eso esté en DONE, y
+`context` la muestra con una línea `WAIT`. No hay que adelantarse: lo que sigue es trabajo de quien tiene
+la tarea de la que depende.
+
+Tomar no es promover: la tarea ya estaba aprobada en `BACKLOG.md` y esto sólo dice quién la hace, así que
+entra en la autonomía del runner. Lo que no entra es tocar el reclamo de otro — ni tomarlo, ni soltarlo—,
+y `context` directamente no ofrece una tarea reclamada.
+
+El reclamo hay que **commitearlo y empujarlo**: sin eso el otro runner lee lo que hay en su copia y la
+reserva no existe para nadie más.
+
+## Con qué runner arrancás
+
+Antes de pedir trabajo hay que saber quién lo tiene. Dos sesiones en la misma máquina resuelven la misma
+identidad de git, así que lo que las distingue es el `CAUCE_RUNNER` de cada una.
+
+`node tools/ops.js runners planning [--json]` dice qué runners tienen una tarea abierta, cuál, desde
+cuándo y si su rama avanzó. Según lo que devuelva:
+
+- **Ninguno** — arrancá con un id propio y no preguntes nada. No hay trabajo que retomar.
+- **Uno o más** — **preguntale a la persona** cuál retoma o si arranca uno nuevo, nombrando la tarea de
+  cada uno, desde cuándo y si avanzó. Retomar el id de un agente que sigue corriendo le saca la tarea, y
+  arrancar uno nuevo cuando había trabajo a medias lo deja huérfano: las dos rompen algo, y por eso la
+  elección no es tuya.
+
+Elegido el id, **exportalo vos** y usalo en cada `ops` de la sesión. **Nunca le pidas a una persona que
+escriba una variable de entorno**: no es el idioma en el que trabaja, y el runner es cómo el toolkit
+distingue dos sesiones, no una decisión de producto. Lo suyo es elegir; la mecánica es tuya.
+
+- `node tools/ops.js worktree planning <tarea>` — prepara el árbol de trabajo de esa tarea y te devuelve
+  la ruta con el `export CAUCE_RUNNER` hecho. No clona nada: `git worktree` comparte el mismo `.git`, y
+  cada árbol queda fijado a su rama, así que ningún agente hace `checkout` sobre el trabajo de otro.
 
 ## Autonomía
 
@@ -178,6 +222,11 @@ Nunca amplía el alcance, promueve sus propias ideas, reescribe el proceso duran
 `git add .`/`git add -A`, reescribe historia con `--force` o `--amend`, ni afirma éxito sin evidencia
 real. Tampoco publica: sin autorización no hay `push`.
 
+Una recurrencia vencida tampoco la promueve, y ésta es la que más se parece a una excepción: la
+aceptación ya está escrita, la fecha la calculó el CLI y `context` la nombra sola. Nada de eso es la
+aprobación que pide BR-OPS-002 — `context` la nombra para que la vea una persona, y quien la pega en
+`BACKLOG.md` es esa persona.
+
 Publicar es lo único de todo eso que este proyecto puede habilitar, y `runner.allowPush` en
 `ops.config.json` es la autorización que R10 pide. Reescribir historia publicada no entra en el trato:
 un `push --force` se frena con la llave prendida o apagada.
@@ -193,5 +242,5 @@ publicación tampoco se decide ahí: la decide `allowPush`.
 3. QA valida el comportamiento por el camino real, no por un atajo interno.
 4. La deuda residual va a `planning/INBOX.md`.
 5. El cambio se commitea en el repo del servicio —uno por naturaleza del diff, y una tarea suele
-   tener una sola— y el hash real queda en `DONE.md`.
+   tener una sola— y el hash real queda en la evidencia de la tarea, `planning/done/<slug>.md`.
 6. `node tools/ops.js check planning` queda verde.

package/template/Makefile

@@ -1,6 +1,6 @@
 .DEFAULT_GOAL := help
 
-.PHONY: help check tree context upgrade destroy automation-check
+.PHONY: help check tree context recurring upgrade destroy automation-check
 .PHONY: integration-check integration-sync require-key integration-promote
 .PHONY: require-agent agent-learn agent-propose agent-evaluate require-flow flow-list flow-check flow-show
 .PHONY: install-claude install-codex install-gemini install-antigravity
@@ -23,6 +23,9 @@ tree: ## Muestra roadmap, backlog, WIP y Done
 context: ## Muestra el contexto mínimo de la tarea vigente
 	@node tools/ops.js context planning
 
+recurring: ## Muestra qué trabajo recurrente vence y con qué línea se promueve
+	@node tools/ops.js recurring planning
+
 # `init` fija la versión exacta del motor, así que `npm update` no la mueve: hay que pedir @latest.
 # Sin este primer paso `upgrade` compara contra el motor instalado y contesta «al día» para siempre.
 destroy: ## Muestra qué se pierde al borrar esta instancia (borrar exige --force a mano)

package/template/automatization/AGENTS.md

@@ -62,6 +62,6 @@ cambia instalación o materialización, valida `ops init` en un directorio tempo
 
 ## Límites
 
-No edites `planning/BACKLOG.md`, `WIP.md` o `DONE.md` desde hooks o instaladores. No hagas que `ops init` active
+No edites `planning/BACKLOG.md`, `planning/wip/` ni `planning/done/` desde hooks o instaladores. No hagas que `ops init` active
 un runner silenciosamente. No agregues lógica de negocio, nombres de servicios de un proyecto, tokens, rutas
 personales ni modelos concretos a esta capa reusable.

package/template/gitignore

@@ -9,5 +9,14 @@ node_modules/
 # máquina. Committearlo sería historia que nadie lee y un conflicto por commit.
 planning/.verify-log
 
+# El plan de cada runner. Es de la máquina que lo corre —existe para recuperar una ejecución
+# interrumpida, y nadie más puede retomarla— y cambia en cada paso, así que compartirlo es un conflicto
+# por commit a cambio de nada. Lo que el equipo sí necesita saber vive en `planning/claims/`.
+#
+# Se excluyen los planes y no el directorio: git no puede volver a incluir un archivo cuyo directorio
+# está excluido, y el README de ahí adentro sí tiene que viajar.
+planning/wip/*.md
+!planning/wip/README.md
+
 *.tgz
 .DS_Store

package/template/planning/BACKLOG.md

@@ -5,6 +5,10 @@ Solo contiene trabajo aprobado y listo. Las ideas viven en `INBOX.md`.
 La aceptación se escribe en la línea o se hereda del criterio que la tarea cita. El lane y el cast son
 opcionales: sin ellos la tarea está sin clasificar, que es el estado que dispara al clasificador.
 
+`(depende: slug)` declara qué tiene que estar en DONE antes de que esta tarea se pueda tomar. El orden de
+la lista alcanzaba cuando trabajaba un runner; con dos, el segundo toma la que sigue mientras el primero
+construye aquella de la que depende.
+
 Pasando de nueve tareas un hito, o de cinco criterios heredados una tarea, `check` pide decidir (R17):
 o se parte, o lleva `(sin partir: <razón>)` en su línea.
 
@@ -14,4 +18,5 @@ o se parte, o lleva `(sin partir: <razón>)` en su línea.
 - [ ] **slug-de-tarea** [full] — Resultado a construir. _Aceptación: conducta observable._ (service: ruta) (cast: quien-entrega → quien-revisa)
 - [ ] **otro-slug** [lite] — Resultado a construir. (→ C1) (epic: 001) (service: ruta) (cast: quien-entrega → quien-revisa, otro-revisor)
 - [ ] **sin-clasificar** — Resultado a construir. _Aceptación: conducta observable._ (service: ruta)
+- [ ] **la-que-sigue** [lite] — Resultado a construir. _Aceptación: conducta observable._ (service: ruta) (depende: slug-de-tarea)
 -->

package/template/planning/FLOW.md

@@ -5,7 +5,7 @@ INBOX ──promoción humana──▶ roadmap ──historias listas──▶ B
   ▲                                                           │
   │                                                        Pick/Plan
   │                                                           ▼
-  │      done/ ◀── archive ◀── DONE ◀── Verify/QA ◀────────── WIP
+  │        done/<tarea>.md ◀── evidencia ◀── Verify/QA ◀───── WIP
   │                                                           │
   └───────────── deuda adyacente ─────────────────────────────┤
                                                               │
@@ -15,6 +15,8 @@ INBOX ──promoción humana──▶ roadmap ──historias listas──▶ B
 
 ## Preparar
 
+0. Si `ops recurring planning` nombra una recurrencia vencida, decidir si esta vuelta se promueve —el
+   comando emite su línea— o se posterga con su razón.
 1. Curar una idea desde INBOX.
 2. Escribir una épica con resultados observables, contexto actual y criterios `C1..CN`.
 3. Descomponerla en historias de máximo cuatro horas, cada una rastreada a uno o más criterios.

package/template/planning/PROTOCOL.md

@@ -9,9 +9,12 @@ invariantes.
   `(service: ruta)`.
 - Hito: `## Hito slug — Título`.
 - 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
+  puede heredar aceptación usando `(→ CN) (epic: NNN)` y declarar `(depende: slug, otro)`. Lane y cast son
+  opcionales: sin ellos la tarea está sin clasificar, que es un estado y no un error. Una tarea con
+  dependencias no se ofrece ni se toma hasta que todas estén en DONE.
+- DONE: un archivo por tarea cerrada, `done/<slug>.md`, con su entrada `[x]` y los campos `acept:`,
+  `fecha:` en AAAA-MM-DD, `done:`, `qa:`, `tests:` y `commit:`. La fecha es la del cierre, y es lo que
+  ordena una evidencia que ya no depende de su posición dentro de un archivo. `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: ...]`. `commit:` apunta a `<sha> <asunto>`, o a `n/a — razón` cuando la tarea no
@@ -20,12 +23,23 @@ invariantes.
   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`.
+- Recurrencia: fila `| qué | cada | desde | tarea y aceptación |` bajo `## Recurrencias`, con `cada` en
+  el vocabulario cerrado `mensual | trimestral | semestral | anual` y la celda de tarea escrita como la
+  cola de su línea de BACKLOG. Vencer no bloquea: cada vuelta se promueve con el período en el slug
+  —`<qué>-AAAA-MM`— y esa promoción la escribe una persona. Postergar se registra bajo
+  `## Postergaciones` con `- **qué** AAAA-MM-DD — razón`.
+- Reclamo: `claims/<tarea>.md` con frontmatter `task/owner/runner/started/service`; el nombre del
+  archivo es el slug que reserva, y por eso un `task` que diga otra cosa es un error. `owner` dice a
+  quién preguntarle y `runner` decide de quién es: con varios agentes en una máquina la persona es
+  la misma y el árbol de trabajo no.
+- WIP activo: frontmatter y checklist en `wip/<runner>.md`; inactivo cuando el archivo no está. Es
+  local y no viaja por git: existe para recuperar la sesión de quien lo escribió, y es uno por runner
+  porque una instancia sidecar la comparten todos los agentes de esa máquina.
 
 ## Gates de arranque
 
 1. Si existe `AWAITING_REVIEW.md`, parar y mostrar la acción que contiene.
-2. Si WIP está activo y puede pertenecer a otro runner, parar: es el mutex.
+2. Si tu WIP está activo, la tarea es ésa: es el mutex del runner, y sólo se lee el propio.
 3. Si WIP está activo tras una interrupción confirmada, verificar los pasos `[x]` en disco y continuar
    desde el primer `[ ]`; no replanear.
 4. Si WIP apunta a una tarea ya en DONE y fuera de BACKLOG, reparar el cierre dejando WIP en IDLE.
@@ -33,7 +47,8 @@ invariantes.
 ## Máquina por tarea
 
 1. Triage: inspeccionar estado y cambios existentes.
-2. Pick: primera tarea no bloqueada del primer hito.
+2. Pick: primera tarea no bloqueada ni reclamada por otro runner, recorriendo los hitos en orden;
+   reclamarla antes de empezar y empujar ese reclamo, que sin empujar no reserva nada.
 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.
@@ -44,7 +59,8 @@ invariantes.
 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.
+13. Done: sacar la tarea de la cola, escribir su evidencia en `done/<slug>.md`, limpiar WIP, soltar
+    el reclamo y cerrar la épica si no le queda ninguna historia abierta.
 14. Cierre: check verde, deuda residual al INBOX y checkpoint entre hitos.
 
 ## Lanes
@@ -68,7 +84,8 @@ chequeo de permisos es `full`, y un componente entero de presentación puede ser
 ## 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 — `business-rules/system/BR-OPS-001`.
+2. Un runner lleva una tarea a la vez —WIP, que es local: `business-rules/system/BR-OPS-001`— y una
+   tarea la lleva un runner —el reclamo, que es compartido: `business-rules/system/BR-OPS-005`—.
 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.

package/template/planning/README.md

@@ -7,8 +7,8 @@ Se lee y se escribe en cada tarea.
 | Pieza | Responsabilidad |
 |---|---|
 | `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. |
+| `wip/` | El plan en vuelo de cada runner; recuperación y mutex por runner. No viaja por git. |
+| `claims/` | Qué tarea tomó cada quien; un archivo por tarea. |
 | `HUMAN_ACTIONS.md` | Acciones externas que requieren una persona. |
 | `AWAITING_REVIEW.md` | Gate efímero; mientras existe no inicia trabajo. |
 
@@ -19,6 +19,7 @@ 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. |
+| `RECURRING.md` | Trabajo que vuelve cada tanto; declarado, nunca encolado solo. |
 | `roadmap/` | Especificaciones de épicas y criterios del QUÉ. |
 | `adr/` | Decisiones arquitectónicas durables. |
 | `business-rules/` | Invariantes observables de negocio y operación. |
@@ -31,7 +32,7 @@ Evidencia que no se reescribe.
 
 | Pieza | Responsabilidad |
 |---|---|
-| `done/` | Historial inmutable: una épica cerrada por archivo, más las acciones humanas resueltas. |
+| `done/` | Evidencia de lo terminado: una tarea 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

package/template/planning/RECURRING.md

@@ -0,0 +1,77 @@
+# Trabajo que vuelve
+
+Lo que hay que hacer cada tanto y no una vez: actualizar dependencias, revisar quién tiene acceso a
+producción, mirar el gasto del mes, recorrer el INBOX entero. No es una categoría de trabajo —puede ser
+cualquier cosa— sino una forma de declararlo: acá vive el enunciado, y cada vuelta se promueve a
+`BACKLOG.md` como una tarea más.
+
+**Nada se dispara.** Este archivo no ejecuta ni encola: declara cada cuánto algo debería mirarse, y el
+vencimiento se calcula cuando alguien corre el CLI. Promover sigue siendo un acto humano, igual que en
+`INBOX.md`. Lo que la máquina aporta es que no se te pase, no decidir por vos.
+
+## Cada fila
+
+- **Qué** — un identificador estable, en minúsculas y sin espacios. No cambia nunca: es lo que ata la
+  fila a las vueltas que ya se hicieron.
+- **Cada** — vocabulario cerrado: `mensual`, `trimestral`, `semestral`, `anual`. No hay expresiones de
+  cron, y esa ausencia es el enunciado: si hiciera falta una, lo que estarías declarando es otra cosa.
+  Tampoco hay `semanal`, porque el slug de cada vuelta tiene grano de mes.
+- **Desde** — `AAAA-MM-DD`. Ancla la primera vuelta y después no se toca.
+- **Tarea y aceptación** — lo que se va a promover, con su aceptación observable escrita una sola vez y
+  con calma. Improvisada en cada vuelta, la misma recurrencia termina significando cosas distintas sin
+  que nadie lo decida.
+
+## Cuándo vence
+
+Se cuenta desde la última vez que se cerró, no desde un día fijo del calendario: una recurrencia
+atrasada no debe tres vueltas, debe una, la que no se hizo.
+
+La fecha de ese último cierre **no se escribe acá**. Sale de `done/` — la entrada más nueva cuyo slug
+sea `<qué>-AAAA-MM`—, que es la evidencia de que efectivamente se hizo y no la afirmación de que se
+hizo. Una celda que alguien tiene que acordarse de actualizar miente a los tres meses, y el estado no se
+copia para representar progreso.
+
+Por eso cada vuelta se promueve con su período en el slug —`deps-2026-10`, después `deps-2026-11`— y no
+con el identificador pelado. Reusarlo tiene además su propio castigo: dos entradas de DONE con el mismo
+slug son un error de `check`, y ese error llega un mes tarde.
+
+## Lo que este archivo no es
+
+- **No bloquea.** Una recurrencia vencida no frena ninguna tarea. Lo que sí frena vive en
+  `HUMAN_ACTIONS.md`; ponerlo acá entrena a ignorar lo que vence, que es lo único que este archivo hace.
+- **No es una cola.** Nada de acá está aprobado para ejecutarse. `BACKLOG.md` sigue siendo la única cola
+  y se escribe a mano.
+- **No es el INBOX.** Una idea se promueve una vez y se borra; esto vuelve, y por eso se queda.
+
+## Recurrencias
+
+| Qué | Cada | Desde | Tarea y aceptación observable |
+|---|---|---|---|
+
+<!--
+| deps | mensual | 2026-09-01 | Actualizar dependencias. _Aceptación: `npm outdated` no deja una versión mayor sin decisión escrita y la puerta queda verde._ |
+| accesos | trimestral | 2026-07-01 | Revisar quién tiene acceso a producción. _Aceptación: cada cuenta activa figura en `organization/`, y las demás están dadas de baja._ |
+| costos | mensual | 2026-09-01 | Revisar el gasto de infraestructura del mes. _Aceptación: cada línea que subió más de 20% tiene una razón escrita._ |
+| inbox | trimestral | 2026-08-01 | Recorrer el INBOX entero. _Aceptación: ninguna viñeta queda sin decisión de promover, dejar o borrar._ |
+-->
+
+## Postergaciones
+
+Saltear una vuelta es legítimo y se escribe. Lo que no puede perderse es la razón: sin ella queda una
+recurrencia atrasada y nadie sabe si fue una decisión o un olvido.
+
+Postergar compra **un período**, no una fecha elegida: la vuelta siguiente vuelve a preguntar. Las
+postergaciones se cuentan desde el último cierre y el contador se reinicia al cerrar. Tres seguidas no
+son un atraso — son una recurrencia mal declarada, y lo que hay que revisar es la cadencia o la fila
+entera.
+
+La salida definitiva es borrar la fila. «Esto ya no lo hacemos» es un diff que alguien revisa; un estado
+`retirada` es una línea que nadie vuelve a leer.
+
+Cada una se escribe con el nombre de su fila en negrita, la fecha y la razón —`- **qué** AAAA-MM-DD —
+razón`—, igual que un ítem del INBOX y por el mismo motivo: el nombre es con lo que se cita la fila.
+Sólo se agrega al final; una línea escrita acá no se edita ni se borra.
+
+<!--
+- **deps** 2026-10-02 — Esperando el release de la 2.0; subir dependencias antes lo ensucia.
+-->

package/template/planning/adr/system/OPS-001-planificacion-como-fuente-de-verdad.md

@@ -13,8 +13,9 @@ en conversaciones, tickets y memoria del runner hace imposible saber qué está
 ## Decisión
 
 **La instancia usa `planning/` como fuente de verdad operativa, legible y validable.** `INBOX.md` recibe ideas,
-el roadmap define resultados, `BACKLOG.md` contiene trabajo promovido, `WIP.md` conserva una única ejecución y
-`DONE.md` registra evidencia. El protocolo define las transiciones permitidas.
+el roadmap define resultados, `BACKLOG.md` contiene trabajo promovido, `wip/<runner>.md` conserva la ejecución de cada runner y
+y `done/<slug>.md` registra la evidencia de cada tarea cerrada, un archivo por tarea. El protocolo
+define las transiciones permitidas.
 
 ## Alternativas consideradas
 

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

@@ -1,8 +1,9 @@
 # Una sola tarea activa
 
-> **Dominio:** planning | **Estado:** vigente | **Actualizado:** 2026-08-14
+> **Dominio:** planning | **Estado:** vigente | **Actualizado:** 2026-09-07
 
-WIP protege la exclusión mutua y permite recuperar una ejecución interrumpida.
+WIP protege la exclusión mutua dentro de un runner y permite recuperar una ejecución interrumpida.
+Que dos runners no tomen la misma tarea es otra cosa, y la sostiene `BR-OPS-005-una-tarea-un-runner.md`.
 [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
@@ -12,7 +13,7 @@ y su evidencia. Cambiar una sin la otra las separa.
 
 | ID | Regla | Condición y resultado |
 |---|---|---|
-| BR-OPS-001 | WIP es mutex | Si WIP está activo, ningún runner toma otra tarea hasta continuarlo o resolverlo. |
+| BR-OPS-001 | WIP es mutex | Si WIP está activo, ese runner no toma otra tarea hasta continuarlo o resolverlo. |
 
 ## Por qué existe cada regla
 
@@ -24,7 +25,8 @@ y su evidencia. Cambiar una sin la otra las separa.
 |---|---|
 | Sesión interrumpida | Se verifican pasos persistidos y se continúa la misma tarea. |
 | Tarea ya cerrada | Se repara el cierre y WIP vuelve a `IDLE`; no se ejecuta otra vez. |
-| Dueño incierto | Se detiene y solicita revisión; no se asume abandono. |
+| WIP ausente | Se lee como IDLE. El archivo es local y un clon nuevo no lo trae; eso no es un error. |
+| Tarea de otro runner | No la ve: el WIP ajeno no viaja. Lo que la reserva es su reclamo (BR-OPS-005). |
 
 ## Evidencia
 
@@ -36,3 +38,4 @@ y su evidencia. Cambiar una sin la otra las separa.
 | Fecha | Cambio | Origen |
 |---|---|---|
 | 2026-08-14 | Creación | OPS-001 y `PROTOCOL.md`. |
+| 2026-09-07 | El mutex se acota al runner; el WIP pasa a ser local | Trabajo en equipo: `../../delivery/teamwork.md`. |

package/template/planning/business-rules/system/BR-OPS-005-una-tarea-un-runner.md

@@ -0,0 +1,44 @@
+# Una tarea, un runner
+
+> **Dominio:** planning | **Estado:** vigente | **Actualizado:** 2026-09-07
+
+El reclamo protege la exclusión mutua entre runners y hace visible quién sostiene cada tarea.
+[fuente: ../../adr/system/OPS-001-planificacion-como-fuente-de-verdad.md]
+
+Es la contracara de `BR-OPS-001-una-sola-tarea-activa.md`, y las dos juntas son el invariante 2 de
+`../../PROTOCOL.md`. Se parecen y no son la misma: aquélla impide que un runner lleve dos tareas y vive
+en su `wip/<runner>.md`, que es local; ésta impide que dos runners lleven la misma y vive en `claims/`, que es
+compartido. Con una sola, un equipo trabaja una tarea por vez o duplica trabajo sin enterarse.
+
+## Reglas
+
+| ID | Regla | Condición y resultado |
+|---|---|---|
+| BR-OPS-005 | El reclamo reserva | Una tarea reclamada no se ofrece a otro runner ni se toma hasta que su reclamo se suelte. |
+
+## Por qué existe cada regla
+
+- **BR-OPS-005:** sin reserva, dos runners que preguntan a la vez reciben la misma tarea y ninguno lo
+  nota: el trabajo se duplica y el conflicto aparece recién al mergear, cuando ya se pagó dos veces.
+
+## Casos borde
+
+| Caso | Comportamiento esperado |
+|---|---|
+| Reclamo propio | Se continúa esa tarea; es lo que el runner declaró que iba a hacer. |
+| Reclamo de otro | La tarea no se ofrece; se toma la siguiente libre. |
+| Reclamo sin empujar | No protege a nadie: el otro runner lee lo que hay en su copia. |
+| Reclamo abandonado | Se avisa por antigüedad; soltarlo es un acto humano, no un comando. |
+| Tarea ya en DONE | El reclamo sobra y se avisa; la evidencia no depende de él. |
+
+## Evidencia
+
+- `ops context` no devuelve una tarea con reclamo ajeno y nombra quién la tiene.
+- `ops check` rechaza un reclamo cuya tarea no existe en BACKLOG ni DONE.
+- `ops claim` se niega a pisar el reclamo de otro.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| 2026-09-07 | Creación | Trabajo en equipo: `../../delivery/teamwork.md`. |

package/template/planning/claims/README.md

@@ -0,0 +1,70 @@
+# Reclamos
+
+Un archivo por tarea tomada, con el slug de la tarea como nombre: `dashboard-filtros.md` dice que esa
+tarea la está haciendo alguien. Crearlo es tomarla; borrarlo es soltarla.
+
+```bash
+node tools/ops.js claim planning dashboard-filtros
+node tools/ops.js release planning dashboard-filtros
+```
+
+Los dos escriben acá y sólo acá. `BACKLOG.md` no lo toca ningún comando del motor: la cola es de lo
+aprobado y la escribe una persona.
+
+## Por qué un archivo por tarea y no uno por persona
+
+Dos personas en tareas distintas no tocan nunca el mismo archivo, así que tomar trabajo no produce
+conflictos. Y dos que toman la misma sí chocan, en git, al mergear — que es exactamente donde el choque
+significa algo y donde alguien lo va a ver.
+
+Un archivo por persona invierte las dos propiedades: dos agentes de la misma persona pelean por su
+archivo, y dos personas que tomaron lo mismo no chocan hasta que alguien lo nota a mano.
+
+## Quién es «yo»: el runner, no la persona
+
+El archivo declara dos cosas distintas. `owner` es la persona —a quién preguntarle— y sale de
+`git config user.email`. `runner` es **el agente que la está haciendo**, y es lo que decide si una tarea
+es tuya.
+
+La diferencia sólo se nota con varios agentes en la misma máquina, y ahí es decisiva: dos sesiones tuyas
+resuelven el mismo email, así que si lo que decidiera «esto es mío» fuera la persona, el segundo agente
+tomaría por propia la tarea del primero y los dos construirían lo mismo sin que nada fallara.
+
+Cada agente exporta el suyo:
+
+```bash
+export CAUCE_RUNNER=/ruta/de/su/arbol-de-trabajo
+```
+
+Sin la variable se deduce del árbol donde corre el proceso, lo que acierta si el agente invoca desde el
+suyo y devuelve el mismo id para todos si invocan desde una instancia compartida. Eso **no queda en
+silencio**: un runner lleva una tarea a la vez, así que el segundo reclamo choca y el mensaje dice qué
+poner. `ops worktree` la imprime hecha.
+
+## Qué no va acá
+
+El plan, los pasos tildados y las decisiones en curso viven en `wip/<runner>.md`, que es local y no viaja por
+git: cambian en cada paso y no le sirven a nadie más. Acá va lo poco que el equipo necesita —qué está
+tomado y por quién—, que cambia dos veces por tarea.
+
+Son también dos exclusiones distintas: el reclamo evita que dos runners tomen la misma tarea, y el WIP
+evita que un runner lleve dos.
+
+## Un reclamo sin empujar no protege
+
+El otro runner lee lo que hay en su copia. Tomar una tarea y no commitear el archivo se ve igual que no
+haberla tomado, y por eso `ops claim` lo recuerda al terminar.
+
+## Cuando alguien se va
+
+Un reclamo abandonado bloquea su tarea para siempre. `ops check` avisa a los tres días **sin señales de
+avance**, que no es lo mismo que tres días desde que se tomó: lo que mira es si la rama `task/<tarea>`
+tiene commits **propios**, los que no están en el tronco. Una rama recién creada hereda la historia
+entera, así que sin esa distinción toda rama parecería haber avanzado el día que se creó. Una tarea larga que sigue recibiendo commits no se apura nunca; una que se detuvo se ve aunque el
+reclamo sea de anteayer.
+
+Sin repositorio resoluble —el `service:` no cae en ninguna raíz declarada, o el proyecto nombra sus ramas
+de otra forma— el aviso vuelve a mirar sólo la fecha. Degrada a lo que había antes, no rompe.
+
+Soltarlo es borrar el archivo a mano, y `ops release` se niega a hacerlo por vos: liberar el trabajo de
+otro es una decisión, no un comando.

package/template/planning/delivery/README.md

@@ -12,6 +12,7 @@ declara en `project.md` qué partes existen, cuáles aplican y qué deuda separa
 | `environments.md` | Pregunta, datos y ciclo de vida de cada ambiente. | Sistemas desplegables. |
 | `flags.md` | Release toggles temporales. | Productos con activación gradual. |
 | `multi-repo.md` | Versionado y compatibilidad entre repos. | Solo workspaces multi-repo. |
+| `teamwork.md` | Qué comparte el equipo, qué no, y cómo crece. | Más de una persona o más de un agente. |
 | `project.md` | Estado real, decisiones adoptadas y evolución. | Obligatorio personalizar. |
 
 Un proyecto puede adoptar una parte sin fingir que adoptó las demás. Una desviación durable se documenta en

package/template/planning/delivery/multi-repo.md

@@ -19,6 +19,17 @@ manifiesto es evidencia del pipeline, no una lista que una persona edita manualm
 - Bases de datos y APIs aplican expand/contract durante la ventana de convivencia.
 - Una entrega cross-repo registra qué PR y versión satisface cada lado del contrato.
 
+## El `service:` de una tarea tiene que resolver a un solo repositorio
+
+Con varias raíces declaradas, un `service:` que existe en más de una es ambiguo: `.` existe en todas, y un
+`src` puede existir en dos. `ops worktree` lo nombra y se niega en vez de elegir la primera, porque elegir
+da una respuesta plausible y equivocada —el árbol de trabajo en el repositorio que no era— sin que nada lo
+diga. El aviso de avance de un reclamo degrada por lo mismo: sin poder resolver el repositorio, mira sólo
+la fecha en que se tomó.
+
+La salida es escribir servicios que sólo existan en una raíz. Si dos repositorios tienen un directorio con
+el mismo nombre y los dos son servicios de verdad, conviene una instancia por repositorio.
+
 ## Cuándo coordinar
 
 Coordinar solo cuando una propiedad no puede preservarse mediante compatibilidad temporal, por ejemplo una