@ingeniomaps/cauce 0.1.0

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

@@ -0,0 +1,35 @@
+# Una sola tarea activa
+
+> **Dominio:** planning | **Estado:** vigente | **Actualizado:** 2026-08-14
+
+WIP protege la exclusión mutua y permite recuperar una ejecución interrumpida.
+[fuente: ../../adr/system/OPS-001-planificacion-como-fuente-de-verdad.md]
+
+## Reglas
+
+| 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. |
+
+## Por qué existe cada regla
+
+- **BR-OPS-001:** evita dos ejecuciones concurrentes, estado contradictorio y pérdida del plan recuperable.
+
+## Casos borde
+
+| Caso | Comportamiento esperado |
+|---|---|
+| 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. |
+
+## Evidencia
+
+- `ops check` rechaza un WIP cuya tarea no existe en BACKLOG ni DONE.
+- El guard de planning bloquea cambios incompatibles con un WIP activo.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| 2026-08-14 | Creación | OPS-001 y `PROTOCOL.md`. |

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

@@ -0,0 +1,35 @@
+# Las propuestas no se autopromueven
+
+> **Dominio:** governance | **Estado:** vigente | **Actualizado:** 2026-08-14
+
+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]
+
+## Reglas
+
+| ID | Regla | Condición y resultado |
+|---|---|---|
+| BR-OPS-002 | Sin autopromoción | Una propuesta queda fuera de la cola hasta aprobación humana explícita. |
+
+## Por qué existe cada regla
+
+- **BR-OPS-002:** impide que el mismo actor que genera una idea amplíe el alcance autorizado.
+
+## Casos borde
+
+| Caso | Comportamiento esperado |
+|---|---|
+| Evaluación verde | Demuestra calidad estructural, pero no equivale a aprobación. |
+| Propuesta automática mensual | Puede abrir revisión; nunca modifica `SKILL.md` ni BACKLOG por sí misma. |
+| Issue remoto listo | Requiere el comando explícito de promoción y superar sus validaciones. |
+
+## Evidencia
+
+- `learn --proposal` escribe bajo `learning/proposals/` y no modifica el agente.
+- La sincronización de integraciones no incorpora elementos directamente en BACKLOG.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| 2026-08-14 | Creación | OPS-004 y `AGENTS.md`. |

package/template/planning/business-rules/system/BR-OPS-003-conflictos-bloquean-promocion.md

@@ -0,0 +1,35 @@
+# Los conflictos bloquean la promoción
+
+> **Dominio:** integrations | **Estado:** vigente | **Actualizado:** 2026-08-14
+
+Una diferencia entre la base, el remoto y la curación local debe resolverse antes de convertirla en intención.
+[fuente: ../../adr/system/OPS-003-integraciones-seguras-por-staging.md]
+
+## Reglas
+
+| ID | Regla | Condición y resultado |
+|---|---|---|
+| BR-OPS-003 | Conflicto bloqueante | Si hay cambios remotos sin reconciliar o conflicto, el draft no se promueve. |
+
+## Por qué existe cada regla
+
+- **BR-OPS-003:** evita sobrescribir información remota o promover una interpretación basada en datos antiguos.
+
+## Casos borde
+
+| Caso | Comportamiento esperado |
+|---|---|
+| Elemento ausente del remoto | No puede permanecer `ready`; se marca para revisión o limpieza segura. |
+| Cambio solo remoto | El draft vuelve a `pending` hasta adoptar o reconciliar la nueva base. |
+| Cambios en campos distintos | Se revisan todas las señales antes de promover. |
+
+## Evidencia
+
+- `integration check` rechaza drafts `ready` con cambios entrantes o conflictos.
+- Las pruebas de integración cubren conflicto, `reset` y `reconcile`.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| 2026-08-14 | Creación | OPS-003. |

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

@@ -0,0 +1,35 @@
+# DONE requiere evidencia verificable
+
+> **Dominio:** delivery | **Estado:** vigente | **Actualizado:** 2026-08-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]
+
+## 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. |
+
+## Por qué existe cada regla
+
+- **BR-OPS-004:** evita declarar éxito con pruebas omitidas, resultados asumidos o cambios sin trazabilidad.
+
+## Casos borde
+
+| Caso | Comportamiento esperado |
+|---|---|
+| No existe superficie testeable | Se documenta la verificación aplicable; no se inventa una prueba. |
+| Verificación bloqueada | La tarea no pasa a DONE y el bloqueo queda visible. |
+| Commit no aplica | La excepción debe estar autorizada y explicada; el campo no desaparece silenciosamente. |
+
+## Evidencia
+
+- `ops check` valida los campos estructurales de cada entrada en DONE.
+- El guard de verificación ejecuta los gates disponibles antes de permitir un commit.
+
+## Historial
+
+| Fecha | Cambio | Origen |
+|---|---|---|
+| 2026-08-14 | Creación | OPS-004 y `PROTOCOL.md`. |

package/template/planning/delivery/README.md

@@ -0,0 +1,41 @@
+# Delivery — camino ideal de entrega
+
+Esta guía describe un estado objetivo adaptable, no capacidades que el proyecto ya posea. Cada proyecto
+declara en `project.md` qué partes existen, cuáles aplican y qué deuda separa la realidad del objetivo.
+
+## Mapa
+
+| Archivo | Fuente de verdad de | Aplicación |
+|---|---|---|
+| `branches.md` | Ramas, PR, integración y gates. | Elegir política y excepciones. |
+| `release.md` | Artefactos, versiones, promoción y rollback. | Proyectos liberables. |
+| `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. |
+| `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
+una ADR propia; una capacidad pendiente se registra en roadmap o INBOX.
+
+## Principios recomendados
+
+1. `main` es el único tronco de larga vida; otras ramas son breves y revisables.
+2. Se promueve un artefacto inmutable, no una rama ni una reconstrucción por ambiente.
+3. El mismo artefacto probado avanza entre ambientes con configuración externa.
+4. Cada ambiente responde una pregunta distinta; un ambiente no es una rama.
+5. Rollback restaura una versión conocida sin exigir un build nuevo.
+6. Los ambientes difieren en escala y datos, no innecesariamente en arquitectura.
+7. Cada componente versiona de forma independiente y demuestra compatibilidad mediante contratos.
+
+“Artefacto” puede ser una imagen, paquete, binario, sitio estático, manifiesto o bundle. La guía no obliga a
+usar contenedores, múltiples ambientes, feature flags ni varios repositorios cuando el producto no los necesita.
+
+## Recorrido de referencia
+
+```text
+rama breve -> PR + CI -> main -> artefacto -> staging -> aprobación -> production
+rama breve -> preview opcional              production -> rollback por versión
+```
+
+Antes de implementar este recorrido, completar `project.md` con evidencia del estado actual y el siguiente
+incremento que realmente aporta valor.

package/template/planning/delivery/branches.md

@@ -0,0 +1,55 @@
+# Ramas y ciclo de integración
+
+> Camino recomendado. Adaptar en `project.md` y registrar excepciones durables mediante ADR.
+
+## Topología por defecto
+
+```text
+main                 tronco protegido y siempre integrable
+<type>/<hito>        rama breve para una unidad revisable
+release/vX.Y         opcional; solo para mantener un candidato congelado
+hotfix/<slug>        emergencia desde la versión desplegada
+```
+
+No crear ramas permanentes por ambiente. `dev`, `staging` y `production` son destinos de despliegue.
+
+## Unidad de cambio
+
+- La épica organiza resultados de varias semanas; normalmente no es una rama.
+- El hito puede ser unidad de rama y PR cuando sus tareas se revisan juntas.
+- La tarea es unidad de aceptación y evidencia en DONE.
+- El commit es una unidad coherente; una tarea puede necesitar varios commits.
+
+Una rama por hito es el default, no un dogma. Dividirla si contiene grupos desplegables y revisables de forma
+independiente. Si una rama vive más de una semana o acumula conflictos, reducir la unidad de integración.
+
+## Nombres
+
+Usar `<type>/<slug>` con un vocabulario corto, por ejemplo `feat`, `fix`, `refactor`, `perf`, `docs`, `test`,
+`ci`, `build` y `chore`. El nombre documenta intención; nunca decide por sí solo versionado, permisos o CI.
+
+## Ciclo recomendado
+
+1. Crear la rama desde `main` actualizado.
+2. Implementar tareas con commits revisables y pruebas proporcionales al riesgo.
+3. Abrir PR hacia `main`; ejecutar lint, tipos, tests, integración, build y scans aplicables.
+4. Usar preview efímero cuando aporte una validación que CI no puede responder.
+5. Obtener las aprobaciones requeridas y mergear sin reescribir evidencia necesaria.
+6. Eliminar la rama y desplegar `main` a dev si existe ese ambiente.
+
+El proyecto decide entre merge commit, rebase o squash. Si `commitPerTask` es parte de la evidencia y los
+commits son la unidad de revert, no usar squash. Si los commits intermedios no son durables, documentar por qué
+el squash es preferible.
+
+## Protección de main
+
+- Sin commits directos, amend ni force-push.
+- CI requerido sobre PR, sin depender de un whitelist frágil de nombres de rama.
+- Reviews y ownership proporcionales al área cambiada.
+- Lo incompleto entra apagado solo cuando existe un release toggle seguro y con plan de eliminación.
+
+## Hotfix
+
+Un hotfix parte del artefacto o tag desplegado, no necesariamente de `main`, porque el tronco puede contener
+trabajo aún no liberado. El arreglo pasa por el camino de verificación más corto que conserve seguridad, se
+versiona y vuelve a `main` mediante un cambio revisable. No termina hasta que ese retorno queda integrado.

package/template/planning/delivery/environments.md

@@ -0,0 +1,35 @@
+# Ambientes
+
+> Crear únicamente los ambientes que respondan preguntas distintas y justifiquen su costo.
+
+| Ambiente | Pregunta | Fuente | Datos | Vida |
+|---|---|---|---|---|
+| local | ¿Arranca y permite desarrollar? | working tree | sintéticos | por sesión |
+| dev | ¿El tronco integrado sigue sano? | `main` | sintéticos o reseteables | permanente |
+| preview | ¿Este cambio funciona aislado? | PR o rama breve | aislados | efímera con TTL |
+| staging | ¿El candidato se despliega como producción? | versión candidata | anonimizados | permanente |
+| production | ¿Qué sirve a usuarios reales? | versión aprobada | reales | permanente |
+
+No todos los proyectos necesitan los cinco. Una librería puede usar CI y publicación sin ambientes; un sitio
+simple puede necesitar preview y production; un backend regulado puede requerir staging estricto.
+
+## Reglas recomendadas
+
+- Un ambiente es un destino, nunca una rama de larga vida.
+- Staging reproduce la forma de producción y difiere principalmente en escala y datos.
+- Ningún ambiente no productivo usa datos reales sin anonimización y autorización.
+- La configuración se declara como código; los secretos viven en un gestor autorizado.
+- Preview se destruye al cerrar la PR y además tiene TTL para recuperarse de fallas de cleanup.
+- Production solo recibe artefactos identificables que pasaron los gates definidos.
+
+## Gates
+
+Cada gate responde una pregunta nueva:
+
+- PR: corre análisis, tests, integración, build y seguridad aplicables.
+- Preview: valida comportamiento del cambio y experiencia de usuario.
+- Staging: ensaya deploy, migraciones, smoke y compatibilidad operativa.
+- Production: exige aprobación cuando corresponda y verifica salud después del deploy.
+
+No repetir tests pesados después de promover el mismo artefacto salvo que el ambiente cambie la propiedad que
+se está midiendo. Los smoke tests sí se ejecutan después de cada despliegue.

package/template/planning/delivery/flags.md

@@ -0,0 +1,35 @@
+# Release toggles
+
+> Esta guía cubre flags temporales para integrar trabajo incompleto; no modela permisos ni planes comerciales.
+
+## Taxonomía
+
+| Tipo | Propósito | Vida esperada |
+|---|---|---|
+| Release toggle | Ocultar una capacidad durante integración gradual. | Días o semanas. |
+| Kill switch | Apagar comportamiento riesgoso durante operación. | Larga, con runbook. |
+| Entitlement | Autorizar por plan, rol o contrato. | Regla permanente de dominio. |
+| Experimento | Comparar variantes y medir una hipótesis. | Duración del experimento. |
+
+Solo el release toggle pertenece al flujo de entrega. No usar un flag temporal para representar autorización.
+
+## Contrato recomendado
+
+- Nace apagado con la primera entrega de la capacidad.
+- Tiene dueño, propósito, fecha de creación y condición de eliminación.
+- Se evalúa en un punto y el resultado se propaga.
+- Puede cambiar sin desplegar cuando se usa como primera opción de rollback.
+- Su fuente caída conserva el default seguro.
+- La tarea de eliminación se crea al mismo tiempo que el flag.
+
+En capacidades multi-repo debe existir una sola fuente de verdad. Dos flags independientes generan estados
+inconsistentes durante el rollout.
+
+## Ciclo de vida
+
+```text
+crear apagado → habilitar gradualmente → observar → estabilizar → borrar flag y ramas muertas
+```
+
+No poner detrás de un release toggle migraciones destructivas ni arreglos de seguridad. Una migración necesita
+compatibilidad expand/contract; un arreglo de seguridad debe quedar activo al desplegarse.

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

@@ -0,0 +1,26 @@
+# Entrega multi-repo
+
+> Aplicar solo cuando `ops.config.json` declara varios repositorios o servicios liberables.
+
+Cada repositorio mantiene su propio tronco, artefactos, tags y cadencia. No crear una “versión de plataforma”
+que obligue a liberar componentes sin cambios únicamente para mantener números sincronizados.
+
+## Estado desplegado
+
+Un manifiesto generado por ambiente registra qué versión o digest de cada componente está desplegado. El
+manifiesto es evidencia del pipeline, no una lista que una persona edita manualmente.
+
+## Compatibilidad
+
+- Los consumidores verifican contratos publicados por sus proveedores.
+- Un cambio compatible se libera sin coordinar calendarios.
+- Un cambio incompatible ocurre en fases: proveedor soporta ambas formas, consumidores migran y después se
+  retira la forma anterior.
+- 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.
+
+## Cuándo coordinar
+
+Coordinar solo cuando una propiedad no puede preservarse mediante compatibilidad temporal, por ejemplo una
+migración legal, rotación de protocolo o cambio atómico autorizado. Documentar orden, rollback y dueño en el
+plan; no convertir esa excepción en la mecánica habitual.

package/template/planning/delivery/project.md

@@ -0,0 +1,31 @@
+# Aplicación de delivery a {{PROJECT_NAME}}
+
+> Este archivo describe realidad comprobada. La guía restante expresa un camino recomendado, no estado actual.
+
+## Perfil
+
+- Tipo de entrega: por definir.
+- Repositorios o componentes liberables: por definir.
+- Artefacto de cada componente: por definir.
+- Política de ramas y merge vigente: por definir.
+- Ambientes existentes: por definir.
+- Autoridad para release, deploy y rollback: por definir.
+
+## Estado actual
+
+Documentar únicamente capacidades verificadas: CI real, builds, despliegues, ambientes, flags, versionado,
+backups, migraciones, observabilidad y rollback ejercitado. Enlazar sus fuentes de verdad.
+
+## Camino adoptado
+
+Indicar qué recomendaciones de `README.md` aplican, cuáles no y por qué. Una diferencia durable que afecte la
+arquitectura debe tener ADR propia.
+
+## Siguiente incremento
+
+Elegir el cambio más pequeño que reduzca riesgo o entregue información. No crear staging, previews, flags o un
+sistema multi-repo solo para completar el diagrama.
+
+## Deuda contra el objetivo
+
+- Pendiente, evidencia actual, riesgo y destino en roadmap o INBOX.

package/template/planning/delivery/release.md

@@ -0,0 +1,54 @@
+# Artefactos, versiones y releases
+
+> Camino recomendado para productos liberables. Adaptar el tipo de artefacto y la estrategia en `project.md`.
+
+## Build una vez
+
+- Construir un artefacto inmutable por commit candidato.
+- Identificarlo por checksum, digest o versión verificable.
+- Promover exactamente ese artefacto entre ambientes; no reconstruirlo.
+- Mantener configuración y secretos fuera del artefacto.
+- Registrar procedencia, pruebas y scans asociados.
+
+El artefacto puede ser una imagen, paquete, binario, bundle o sitio. Si el producto no genera uno, documentar
+qué salida reproducible cumple esa función.
+
+## Corte de release
+
+El corte es una acción explícita y repetible:
+
+1. Verifica que el commit candidato tenga los gates requeridos.
+2. Calcula o recibe una versión según la política del proyecto.
+3. Actualiza changelog o metadata versionada cuando aplique.
+4. Crea una referencia inmutable, normalmente un tag.
+5. Dispara el despliegue del artefacto ya construido.
+
+SemVer y Conventional Commits son una recomendación útil para software versionado, no un requisito para todo
+proyecto. Si se usan, `feat` incrementa minor, `fix` patch y un breaking change major.
+
+## Promoción
+
+```text
+artefacto candidato → staging → aprobación registrada → production
+```
+
+Staging y production usan el mismo mecanismo de deploy. Solo cambian el destino, configuración autorizada,
+datos y escala. La aprobación no reconstruye ni reetiqueta el artefacto.
+
+## Rollback
+
+Orden recomendado durante un incidente:
+
+1. Apagar un release toggle seguro, si existe.
+2. Devolver tráfico a la versión anterior, si la plataforma lo permite.
+3. Redesplegar un artefacto anterior conocido.
+4. Reparar el tronco mediante el flujo normal después de restaurar servicio.
+
+Un rollback no debe exigir compilar. Las migraciones deben ser forward-only y expand/contract para que la
+versión anterior pueda convivir con el esquema nuevo durante la ventana de recuperación.
+
+## Bugfix y hotfix
+
+Un bugfix común sigue el flujo normal. Un hotfix solo existe cuando producción no puede esperar y `main`
+contiene cambios no liberados. Debe partir de la versión desplegada, pasar verificación proporcional, producir
+una nueva versión y regresar al tronco. El pipeline debe impedir una release que omita un hotfix ya desplegado.

package/template/planning/done/.gitkeep

@@ -0,0 +1 @@
+

package/template/planning/roadmap/README.md

@@ -0,0 +1,62 @@
+# Roadmap
+
+El roadmap contiene el horizonte de intención del proyecto: resultados grandes, observables y todavía no
+convertidos por completo en trabajo inmediato. El frontmatter de cada épica es la fuente de verdad y `ops tree`
+es su índice derivado; no se mantiene una tabla manual paralela.
+
+## Ciclo de vida
+
+```text
+roadmap (open) → BACKLOG (active) → DONE → done/epic-NNN.md (closed)
+```
+
+- `open`: candidata editable que aún no fue promovida al backlog.
+- `active`: sus historias están en ejecución o pendientes dentro del backlog.
+- `closed`: todas sus historias tienen evidencia verificable y la épica puede archivarse.
+
+La prioridad predeterminada es el número ascendente entre las épicas `open`. Cualquier excepción debe quedar
+como una decisión explícita, no como una segunda lista de prioridad escondida en este README.
+
+## Autoridad y curación
+
+Una persona crea, divide, reordena o descarta épicas. Los runners pueden consumirlas y cambiar su estado durante
+el ciclo acordado, pero no inventan objetivos de producto. Las propuestas provenientes de una integración o del
+INBOX requieren promoción humana.
+
+Antes de promover una épica se verifican en el repositorio las rutas, capacidades y datos que sus criterios
+suponen. Los resultados, reglas y criterios describen el qué; el cómo ejecutable se decide al planificar cada
+historia y no se congela prematuramente en la especificación.
+
+## Formas admitidas
+
+Una épica pequeña usa un único archivo:
+
+```text
+epic-NNN-slug.md
+```
+
+Una épica cuyo contexto ya no sea legible en un archivo puede graduarse a carpeta:
+
+```text
+epic-NNN-slug/
+├── spec.md       # obligatorio: contrato del resultado
+├── research.md   # opcional: fuentes, evidencia y supuestos
+├── plan.md       # opcional: orientación provisional, no fuente de verdad
+└── notes.md      # opcional: contexto complementario
+```
+
+Para graduarla, se mueve el contenido contractual a `spec.md` sin cambiar el número ni el slug. No se crean
+archivos auxiliares vacíos ni se usa una carpeta si la épica sigue siendo fácil de entender en un solo archivo.
+
+## Contrato de una épica
+
+- 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.
+- 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.
+
+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

@@ -0,0 +1,32 @@
+---
+epic: 000
+title: Plantilla (no ejecutar)
+status: template
+service: ruta-principal
+---
+
+# Épica 000 — Plantilla
+
+## Resultado
+
+Qué cambia para el usuario o el sistema.
+
+## Fuera de alcance
+
+- Límites explícitos.
+
+## Criterios
+
+- **C1** — Comportamiento observable y verificable.
+
+## Contexto relevante
+
+- Estado actual, reglas, ADR y rutas reales — verificadas en el repositorio — que el ejecutor debe leer.
+
+## Historias
+
+- [ ] **slug-de-historia** (→ C1) — Incremento ≤4h. _Aceptación: resultado observable._ (service: ruta)
+
+## Riesgos y decisiones humanas
+
+- Riesgos, supuestos, dependencias o acciones humanas. Escribir `Ninguno` cuando se hayan revisado.

package/template/planning/rules/README.md

@@ -0,0 +1,7 @@
+# Reglas transversales
+
+- `process.md`: planificación, alcance, review y sincronización de estado.
+- `code-shape.md`: simplicidad y forma del cambio.
+- `commits.md`: historia versionada y entrega.
+
+Las convenciones específicas de lenguaje viven junto al servicio que usa ese lenguaje.

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

@@ -0,0 +1,14 @@
+# Forma del cambio
+
+## R5 — Solución mínima completa
+
+Preferir la solución más simple que cubre toda la aceptación, sin infraestructura especulativa.
+
+## R6 — Cambios quirúrgicos
+
+No reformatear, renombrar ni reparar elementos ajenos a la tarea.
+
+## 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.

package/template/planning/rules/commits.md

@@ -0,0 +1,14 @@
+# Commits y entrega
+
+## R8 — Un commit por tarea
+
+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.
+
+## R9 — El artefacto manda
+
+Tests verdes no reemplazan build, paquete, imagen o migración cuando son parte del artefacto entregable.
+
+## R10 — Publicación humana por defecto
+
+Push, PR, merge, tags, deploy y rollback requieren la autorización configurada para el proyecto.

package/template/planning/rules/process.md

@@ -0,0 +1,17 @@
+# Proceso
+
+## R1 — Pensar antes de editar
+
+Leer aceptación, contexto y código actual; escribir el plan antes del primer cambio.
+
+## R2 — Ejecutar por objetivo
+
+Cada paso termina en un estado verificable, no en una lista de archivos a tocar.
+
+## R3 — Review proactivo
+
+Buscar fallos de corrección, seguridad, compatibilidad y operabilidad antes de Verify.
+
+## R4 — Sincronización de estados
+
+El estado se mueve de forma atómica entre contratos; nunca se copia para representar progreso.

package/template/tools/ops.js

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+'use strict'
+
+const path = require('path')
+require(path.join(__dirname, '..', '.ops', 'engine', 'cli', 'ops.js'))