@ingeniomaps/cauce 0.1.0

package/template/integrations/jira/config.json

@@ -0,0 +1,17 @@
+{
+  "enabled": false,
+  "baseUrl": "https://your-domain.atlassian.net",
+  "jql": "project = KEY AND resolution = Unresolved ORDER BY priority DESC, created ASC",
+  "pageSize": 100,
+  "timeoutMs": 30000,
+  "maxPages": 100,
+  "auth": {
+    "type": "basic",
+    "emailEnv": "JIRA_EMAIL",
+    "tokenEnv": "JIRA_API_TOKEN"
+  },
+  "serviceFrom": "component",
+  "candidateAssigneeEnv": "",
+  "acceptanceHeading": "Criterios de aceptación",
+  "writeBack": false
+}

package/template/integrations/jira/proposed/README.md

@@ -0,0 +1,22 @@
+# Propuestas locales para Jira
+
+Cada archivo representa un item que todavía no existe en Jira:
+
+```markdown
+---
+provider: jira
+state: draft
+parent: KEY-123
+type: Task
+service: app
+estimateHours: 2
+---
+
+# Resultado observable
+
+## Descripción
+
+Comportamiento que debe entregar el item.
+```
+
+Estados: `draft`, `approved`, `published`. Cauce valida y muestra el plan; nunca publica propuestas.

package/template/integrations/jira/staging/.gitkeep

@@ -0,0 +1 @@
+

package/template/integrations/jira/staging/README.md

@@ -0,0 +1,4 @@
+# Staging Jira
+
+Directorio administrado por `integration sync`. No edites `remote.json` ni `sync-state.json`; cura solamente
+`draft.md`. Las categorías son `epics/`, `stories/`, `tasks/`, `subtasks/` e `items/`.

package/template/ops.config.json

@@ -0,0 +1,15 @@
+{
+  "$schema": ".ops/engine/schemas/ops-config.schema.json",
+  "project": "{{PROJECT_NAME}}",
+  "mode": "{{MODE}}",
+  "planningDir": "{{PLANNING_DIR}}",
+  "workspaceRoots": [
+    { "name": "main", "path": "{{WORKSPACE_PATH}}" }
+  ],
+  "runner": {
+    "maxTaskHours": 4,
+    "humanCheckpointBetweenMilestones": true,
+    "commitPerTask": true,
+    "allowPush": false
+  }
+}

package/template/organization/README.md

@@ -0,0 +1,13 @@
+# Contexto estable del proyecto
+
+Este directorio contiene hechos de negocio y producto que cambian lentamente. No guarda tareas ni estado.
+
+Documentos recomendados:
+
+- `company.md`: misión, modelo de negocio, objetivos, estructura y derechos de decisión.
+- `product.md`: problema, usuarios, propuesta de valor y límites.
+- `domains.md`: lenguaje ubicuo, dominios y dueños.
+- `architecture.md`: mapa de sistemas y enlaces a las fuentes técnicas.
+- `risks.md`: riesgos operativos, regulatorios, financieros y de seguridad.
+
+Principio: cada hecho tiene un dueño. Enlaza en vez de copiar información que ya vive en otro lugar.

package/template/organization/company.md

@@ -0,0 +1,38 @@
+# Empresa — {{PROJECT_NAME}}
+
+Este archivo es específico de la empresa. Completar hechos; marcar lo desconocido como `Por definir`.
+
+## Misión y visión
+
+Por completar.
+
+## Modelo de negocio
+
+- Clientes y usuarios:
+- Quién paga:
+- Propuesta de valor:
+- Fuentes de ingreso:
+- Costos o restricciones relevantes:
+
+## Objetivos actuales
+
+Por completar. Incluir horizonte, responsable y métrica cuando existan.
+
+## Estructura y derechos de decisión
+
+| Área o rol | Responsable | Decide sobre | Debe consultar a |
+|---|---|---|---|
+| Producto | Por definir | Por definir | Por definir |
+
+## Restricciones y compromisos
+
+- Mercados y territorios:
+- Regulación y privacidad:
+- Seguridad:
+- Contratos o promesas vigentes:
+- Presupuesto:
+
+## Fuentes de verdad
+
+Enlazar CRM, analítica, investigación, documentación financiera y demás sistemas autorizados.
+No copiar secretos ni credenciales aquí.

package/template/organization/product.md

@@ -0,0 +1,17 @@
+# Producto — {{PROJECT_NAME}}
+
+## Problema
+
+Por completar.
+
+## Usuarios y resultados
+
+Por completar.
+
+## Alcance / fuera de alcance
+
+Por completar.
+
+## Métricas de éxito
+
+Por completar.

package/template/planning/BACKLOG.md

@@ -0,0 +1,9 @@
+# Backlog promovido
+
+Solo contiene trabajo aprobado y listo. Las ideas viven en `INBOX.md`.
+
+<!--
+## Hito primer-resultado — Primer resultado observable
+
+- [ ] **slug-de-tarea** [full] — Resultado a construir. _Aceptación: conducta observable._ (service: ruta)
+-->

package/template/planning/DONE.md

@@ -0,0 +1,13 @@
+# Done activo
+
+<!--
+## Hito slug — Título
+
+- [x] **slug-de-tarea** (epic: 001) — Resultado
+  acept: comportamiento aceptado
+  done: cambios y comandos de verificación con exit codes
+  qa: comportamiento observado por el camino real
+  tests: C1 → nombre de prueba o comando; C2 → nombre de prueba o comando
+  decisions: decisión no obvia [fuente: ruta/archivo] o [supuesto: motivo verificable]
+  commit: abc1234 feat(scope): subject (repo@branch)
+-->

package/template/planning/FLOW.md

@@ -0,0 +1,34 @@
+# Flujo operativo
+
+```text
+INBOX ──promoción humana──▶ roadmap ──historias listas──▶ BACKLOG
+                                                              │
+                                                           Pick/Plan
+                                                              ▼
+                         done/ ◀── archive ◀── DONE ◀── Verify/QA ◀── WIP
+```
+
+## Preparar
+
+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.
+4. Promover historias a un hito de BACKLOG sin cambiar su slug ni aceptación.
+
+## Ejecutar
+
+1. Comprobar gates (`AWAITING_REVIEW`, WIP ajeno, acciones humanas).
+2. Tomar la primera tarea no bloqueada.
+3. Persistir el plan aprobado en WIP antes de editar código.
+4. Construir con RED/GREEN/VERIFY cuando sea aplicable.
+5. Revisar, verificar y hacer QA con evidencia real.
+6. Commit por tarea; mover BACKLOG → DONE; limpiar WIP.
+
+Los pasos 1 y 2 los resuelve `node tools/ops.js context planning` en una sola salida: si imprime
+`BLOCKED`, parar; si imprime una tarea, ésa es la que corresponde, ya con su aceptación y sus
+criterios. Añadir `--json` para consumirlo desde un workflow.
+
+## Cerrar
+
+Al terminar la última historia, cambiar la épica a `closed`, archivar su evidencia y ejecutar el check.
+Cruzar a otro hito crea `AWAITING_REVIEW.md` si la configuración exige checkpoint humano.

package/template/planning/HUMAN_ACTIONS.md

@@ -0,0 +1,4 @@
+# Acciones humanas
+
+| Tarea | Estado | Origen | Acción concreta y condición de desbloqueo |
+|---|---|---|---|

package/template/planning/INBOX.md

@@ -0,0 +1,11 @@
+# Inbox sin promover
+
+El runner puede agregar; solo una persona promueve y elimina.
+
+## Deuda
+
+## Ideas
+
+## Propuestas
+
+## Lecciones

package/template/planning/METHODOLOGY.md

@@ -0,0 +1,26 @@
+# Metodología
+
+## Separar QUÉ y CÓMO
+
+La épica define comportamiento observable y restricciones, sin prescribir implementación salvo que sea una
+restricción real. El plan de la tarea decide tecnología después de leer el código actual.
+
+## Trazabilidad
+
+Cada criterio tiene identificador `CN`; cada historia apunta a criterios con `(→ C1, C2)`. Si una historia
+no contribuye a un criterio, sobra o falta un criterio. DONE conserva aceptación, evidencia y commit.
+
+## Context engineering
+
+El contexto mínimo para ejecutar una tarea es: reglas raíz, épica y sus criterios, contexto relevante,
+contrato del servicio, tarea y WIP. No cargar todo el historial en el loop caliente.
+
+## Especificación viva
+
+Antes de activar una épica, `## Contexto relevante` debe señalar lo que existe hoy con rutas verificadas.
+Si el código contradice la spec, parar y resolver la fuente de verdad; no inventar una tercera versión.
+
+## Automatizar invariantes
+
+Lo comprobable debe vivir en validadores o hooks: formatos, duplicados, gates peligrosos y evidencia. El
+juicio sigue en review: claridad, adecuación al dominio, UX y decisiones de arquitectura.

package/template/planning/PROTOCOL.md

@@ -0,0 +1,62 @@
+# Protocolo agnóstico de ejecución
+
+Es la fuente de verdad del proceso para cualquier runner. Ninguna herramienta concreta puede relajar estas
+invariantes.
+
+## Contratos
+
+- É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)`.
+- 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: ...]`.
+- WIP activo: frontmatter y checklist; inactivo: `status: IDLE`.
+
+## 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.
+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.
+
+## Máquina por tarea
+
+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.
+
+## 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 reduce ceremonia, nunca seguridad, aceptación ni evidencia.
+
+## 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.
+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.

package/template/planning/README.md

@@ -0,0 +1,18 @@
+# Planning — intención, estado y evidencia
+
+| 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. |
+| `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`.

package/template/planning/WIP.md

@@ -0,0 +1,22 @@
+status: IDLE
+
+<!-- Activo:
+---
+task: slug
+hito: "Hito slug — Título"
+epic: 001
+phase: Build
+started: YYYY-MM-DD
+service: ruta
+acceptance: "criterio observable"
+---
+
+## Plan aprobado
+1. [ ] Paso verificable
+
+## Decisiones tomadas
+- (ninguna)
+
+## Bloqueos
+- (ninguno)
+-->

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

@@ -0,0 +1,47 @@
+# ADR-NNN — Título corto en imperativo
+
+**Estado:** Propuesto | Aceptado | Obsoleto | Reemplazada por [NNN](./NNN-slug.md)
+**Fecha:** YYYY-MM-DD
+**Responsable:** Persona o equipo
+
+> Una frase opcional que delimita qué decide esta ADR y qué queda fuera.
+
+## Contexto
+
+Explicar el problema, las fuerzas que compiten y el costo de no decidir. Una persona nueva debe entenderlo
+sin depender de conversaciones privadas. Separar la decisión si necesita abarcar problemas independientes.
+
+Respaldar cada afirmación no obvia con `[fuente: ruta#sección|ADR-NNN|URL]`. Lo que todavía no esté probado se
+declara como `[supuesto: explicación]`; si requiere una respuesta humana, también se registra en
+`../HUMAN_ACTIONS.md`.
+
+## Decisión
+
+**Expresar en una frase qué se elige.** Después definir límites, responsabilidades y contratos relevantes.
+Una ADR decide una dirección durable; no reemplaza el plan de implementación ni afirma trabajo inexistente.
+
+## Alternativas consideradas
+
+- **Alternativa:** por qué se descartó con las restricciones conocidas.
+- **No decidir todavía:** qué costo o riesgo produciría.
+
+## Consecuencias
+
+**Ganamos:**
+
+- Beneficio concreto y verificable.
+
+**Costos que aceptamos:**
+
+- Complejidad, deuda o restricción introducida, junto con su mitigación cuando exista.
+
+## Estado de implementació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

@@ -0,0 +1,42 @@
+# Decisiones de arquitectura
+
+Las ADR conservan decisiones durables y su razonamiento. No sustituyen tareas, reglas de código ni hechos de
+negocio. Una decisión interna de un servicio debe vivir junto a ese servicio; aquí van decisiones del proyecto
+como conjunto o que cruzan sus límites.
+
+## Namespaces
+
+- `system/OPS-NNN-*`: decisiones heredadas de Cauce. Explican el protocolo instalado y no se renumeran.
+- `NNN-*`: decisiones propias del proyecto, numeradas correlativamente desde `001`.
+- `000-template.md`: molde para una decisión nueva; no representa una decisión vigente.
+
+Las ADR del sistema se conservan para que la instalación sea autocontenida. Si un proyecto necesita apartarse
+de una, crea una ADR propia que documente la excepción; no modifica silenciosamente la heredada.
+
+## Estados
+
+- `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.
+
+## Cómo crear una ADR del proyecto
+
+1. Copiar `000-template.md` como `NNN-slug-corto.md`.
+2. Documentar contexto, fuentes, supuestos, decisión, alternativas y costos.
+3. Declarar por separado lo construido y lo pendiente.
+4. Actualizar el índice siguiente.
+5. Al reemplazarla, enlazar la nueva ADR sin borrar el historial.
+
+## Decisiones del sistema
+
+- [OPS-001](system/OPS-001-planificacion-como-fuente-de-verdad.md): planning conserva intención y estado.
+- [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.
+
+## Decisiones del proyecto
+
+| ADR | Decisión | Fecha | Estado |
+|---|---|---|---|
+| _(ninguna todavía)_ | | | |

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

@@ -0,0 +1,32 @@
+# OPS-001 — Usar planning como fuente de verdad operativa
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-14
+
+> Decide dónde viven intención, estado y evidencia; no decide la arquitectura del producto.
+
+## Contexto
+
+Los agentes pierden contexto entre sesiones y los chats no son un registro durable. Mantener estado paralelo
+en conversaciones, tickets y memoria del runner hace imposible saber qué está aprobado, activo o terminado.
+
+## 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.
+
+## Alternativas consideradas
+
+- **Usar la conversación del agente:** no es durable ni verificable fuera de la sesión.
+- **Usar solo el proveedor externo:** mezcla intención curada con estado remoto y pierde recuperación local.
+
+## Consecuencias
+
+**Ganamos:** recuperación determinista, revisión humana y trazabilidad portable.
+
+**Costos que aceptamos:** el estado debe mantenerse consistente y pasar validaciones antes de cada transición.
+
+## Estado de implementación
+
+Implementado por el parser, el CLI, el protocolo, los guards y las pruebas del toolkit.

package/template/planning/adr/system/OPS-002-runtime-autocontenido-y-neutral-al-runner.md

@@ -0,0 +1,34 @@
+# OPS-002 — Distribuir un runtime autocontenido y neutral al runner
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-14
+
+> Decide cómo se instala y ejecuta Cauce; no elige qué runner debe usar cada proyecto.
+
+## Contexto
+
+Claude, Codex, Gemini y Antigravity tienen formatos y capacidades diferentes. Si el protocolo depende de una
+herramienta o de rutas hacia este repositorio central, una actualización o sesión sin acceso rompe el proyecto.
+
+## Decisión
+
+**Cada instancia recibe una copia autocontenida del motor en `.ops/engine/`.** El protocolo y los guards son
+neutrales; cada runner se conecta mediante un adaptador declarado. La instalación preserva archivos existentes,
+no activa runners silenciosamente y rechaza destinos atravesados por symlinks inseguros.
+
+## Alternativas consideradas
+
+- **Depender del toolkit central:** impide operar de forma aislada y hace frágiles las rutas.
+- **Duplicar lógica por runner:** permite divergencias de seguridad y comportamiento.
+- **Materializar mediante symlinks:** cruza límites del workspace y dificulta reproducibilidad y distribución.
+
+## Consecuencias
+
+**Ganamos:** portabilidad, comportamiento uniforme y actualizaciones revisables.
+
+**Costos que aceptamos:** cada instancia conserva una copia que debe actualizarse explícitamente sin sobrescribir
+personalizaciones.
+
+## Estado de implementación
+
+Implementado por `ops init`, el registro de runners y los comandos `automation install` y `automation doctor`.

package/template/planning/adr/system/OPS-003-integraciones-seguras-por-staging.md

@@ -0,0 +1,33 @@
+# OPS-003 — Procesar integraciones externas mediante staging seguro
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-14
+
+> Decide el límite de seguridad común; cada proveedor conserva su autenticación y normalización.
+
+## Contexto
+
+Un proveedor externo puede cambiar mientras existe curación local. Escribir directamente desde un agente
+mezcla datos remotos, intención y autorización, y hace difícil detectar conflictos o recuperar una decisión.
+
+## Decisión
+
+**Toda integración es de solo lectura por defecto y pasa por staging tipado.** El motor conserva snapshot,
+base reconciliada y borrador local; deriva cambios entrantes, salientes y conflictos. Los snapshots son
+inmutables para el usuario. `writeback-plan` calcula intención, pero no ejecuta escrituras remotas.
+
+## Alternativas consideradas
+
+- **Editar el proveedor durante la sincronización:** combina lectura y mutación sin checkpoint revisable.
+- **Usar un único archivo mutable:** pierde la base necesaria para comparar cambios de tres vías.
+
+## Consecuencias
+
+**Ganamos:** reconciliación explícita, limpieza segura y adaptación de nuevos proveedores sin duplicar el ciclo.
+
+**Costos que aceptamos:** el staging ocupa espacio y una escritura futura necesitará otro contrato, pruebas y
+autorización humana explícita.
+
+## Estado de implementación
+
+Implementado para Jira con sincronización, propuestas, promoción local y plan de escritura sin ejecutor remoto.

package/template/planning/adr/system/OPS-004-promocion-humana-y-evidencia-verificable.md

@@ -0,0 +1,34 @@
+# OPS-004 — Exigir promoción humana y evidencia verificable
+
+**Estado:** Aceptado
+**Fecha:** 2026-08-14
+
+> Decide quién autoriza intención nueva y cuándo puede afirmarse que una tarea terminó.
+
+## Contexto
+
+Un agente puede producir ideas y cambios plausibles sin autoridad de producto ni evidencia del camino real.
+Permitir que apruebe sus propuestas o declare éxito por inspección convierte una sugerencia en alcance y oculta
+fallas funcionales.
+
+## Decisión
+
+**Los agentes pueden proponer, pero una persona controla la promoción de intención nueva y las acciones externas.**
+Una tarea solo termina con aceptación observable y resultados reales de las verificaciones aplicables. Los
+bloqueos que requieren autoridad se registran en `HUMAN_ACTIONS.md` o `AWAITING_REVIEW.md`.
+
+## Alternativas consideradas
+
+- **Autopromoción por confianza o puntuación:** no concede autoridad ni elimina el riesgo de ampliar alcance.
+- **Éxito por revisión estática:** no demuestra ejecución, integración ni comportamiento de usuario.
+
+## Consecuencias
+
+**Ganamos:** control de alcance, auditoría y afirmaciones respaldadas por evidencia.
+
+**Costos que aceptamos:** ciertos hitos se detienen hasta obtener una decisión o ejecutar una prueba real.
+
+## Estado de implementación
+
+Implementado por el protocolo, los estados de planning, los guards, las propuestas de agentes y los checkpoints
+humanos de las integraciones.

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

@@ -0,0 +1,34 @@
+# Tema
+
+> **Dominio:** nombre | **Estado:** vigente | **Actualizado:** YYYY-MM-DD
+
+Describir brevemente el comportamiento de negocio compartido y el riesgo que controla. Las fuentes no obvias
+se citan como `[fuente: ruta#sección|ADR-NNN|URL]`; lo desconocido se marca `[supuesto: explicación]`.
+
+## Reglas
+
+| ID | Regla | Condición y resultado |
+|---|---|---|
+| BR-DOM-001 | Nombre breve | Cuando ocurre X, el sistema produce o impide Y. |
+
+## Por qué existe cada regla
+
+- **BR-DOM-001:** riesgo concreto que evita o propiedad que conserva.
+
+## Casos borde
+
+Conservar solo casos no obvios. Eliminar esta sección si no aplica.
+
+| Caso | Comportamiento esperado |
+|---|---|
+| Condición límite | Resultado observable. |
+
+## Evidencia
+
+- Prueba, métrica o procedimiento que demuestra la regla.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| YYYY-MM-DD | Creación | ADR, épica o decisión humana. |

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

@@ -0,0 +1,32 @@
+# Reglas de negocio durables
+
+Este registro contiene invariantes observables que sobreviven a una tarea o épica. No es otra cola de trabajo,
+una copia de `PROTOCOL.md` ni un lugar para justificar decisiones arquitectónicas.
+
+## Cuándo crear una regla
+
+Crear una regla cuando al menos una condición se cumpla:
+
+- varias épicas, servicios o integraciones consumen el mismo comportamiento;
+- debe seguir vigente después de cerrar la iniciativa que la introdujo;
+- protege autorización, dinero, datos externos o recuperación operativa;
+- varios criterios de aceptación necesitan citar el mismo resultado.
+
+Lo específico de una épica permanece en `roadmap/`. El porqué de una estructura durable vive en `adr/`. El
+orden de ejecución y las transiciones pertenecen a `PROTOCOL.md`.
+
+## Namespaces
+
+- `system/BR-OPS-NNN-*`: reglas heredadas del sistema; no se renumeran.
+- `<dominio>/<tema>.md`: reglas propias del proyecto.
+- `000-template.md`: molde, no una regla vigente.
+
+Los IDs son globalmente únicos y no se reutilizan. `ops check` valida duplicados y secciones obligatorias.
+Épicas, ADR y planes pueden citar una regla como `[fuente: BR-OPS-001]`.
+
+## Reglas del sistema
+
+- [BR-OPS-001](system/BR-OPS-001-una-sola-tarea-activa.md): WIP activo funciona como mutex.
+- [BR-OPS-002](system/BR-OPS-002-propuestas-no-se-autopromueven.md): una propuesta no se aprueba sola.
+- [BR-OPS-003](system/BR-OPS-003-conflictos-bloquean-promocion.md): un conflicto impide promover.
+- [BR-OPS-004](system/BR-OPS-004-done-requiere-evidencia.md): DONE exige evidencia verificable.