@ingeniomaps/cauce 0.78.0 → 0.80.0

package/CHANGELOG.md

@@ -14,6 +14,125 @@ desde este repositorio no va, porque el que lee no puede actuar sobre eso. Cuand
 unas pocas líneas casi siempre es porque cuenta cómo se descubrió el problema o por qué se eligió el
 diseño — eso vive en el commit y en el código.
 
+## [0.80.0] - 2026-09-10
+
+### Agregado
+
+- **Leer una credencial también se frena, y las identidades declaradas cuentan como credencial.** Un guard
+  nuevo, `secrets-read`, corre en la herramienta de lectura de Claude (`Read`) y de Gemini (`read_file`) y
+  frena los mismos archivos que `secrets` frena al escribir. Esos archivos ahora incluyen las identidades
+  `source: file` de `organization/secrets.json`, que antes pasaban por no tener nombre de credencial. En
+  Claude, además, la instalación agrega reglas `permissions.deny` `Read(...)` que el propio Claude aplica
+  también a `cat`, `head`, `tail`, `sed` y redirecciones.
+
+  **Qué cambia para vos**: el agente deja de poder leer `.env`, claves y tokens conocidos; `.env.example`
+  sigue legible. Si una lectura hace falta, aprobá la ruta en `planning/.ops-approval`. Corré
+  `automation install` para que tu `.claude/settings.json` reciba las reglas: se suman a las tuyas. No es un
+  límite de seguridad —un `grep -r` o un script propio siguen leyendo—, y en Codex y Antigravity no hay guard
+  de lectura.
+
+- **Un proveedor de integraciones propio, sin tocar Cauce.** El registro de `integrations/config.json`
+  ya tenía un campo `adapter` que nadie leía: ahora `"adapter": "./adapter.js"` carga el adaptador de la
+  empresa desde `integrations/<nombre>/`, e `integration enable` lo conecta sin exigir un molde de Cauce.
+  El adaptador declara `contract: 1` y las tres funciones del contrato, y `check` rechaza el que no
+  cumpla.
+
+  **Qué cambia para vos**: nada si sólo usás Jira. Para otra herramienta, `integrations/README.md` de tu
+  instancia trae el recorrido.
+
+- **Un contrato de secretos compartido entre repositorios, y un chequeo sin red.** Si tus servicios
+  usan un gestor de secretos, los scripts y workflows que lo conectan terminan copiados en cada
+  repositorio, y el arreglo que alguien hizo en uno no llega a los demás. `organization/secrets.json`
+  declara qué cuenta, qué identidad y qué archivos comparte cada servicio, y
+  `node tools/ops.js secrets check .` compara cada copia contra la canónica que guarda la instancia:
+  dice cuál quedó atrás y el `cp` que la pone al día. También falla si una credencial vive dentro de un
+  repositorio o si la declaración guarda un valor en vez de una referencia.
+
+  **Qué cambia para vos**: nada si no lo usás. Para adoptarlo, `organization/README.md` trae el formato
+  y el recorrido. Cauce no se conecta a ningún gestor ni trae adaptadores: lo que habla con el gestor
+  sigue siendo tuyo. Si tus proyectos tienen instancias separadas, el chequeo sólo compara dentro de
+  cada una: para que un esqueleto y sus derivados se midan contra lo mismo, van como raíces de la misma
+  instancia.
+
+### Corregido
+
+- **`init` rechaza un runner mal escrito sin crear la instancia.** Con `--runner none` —el valor es
+  `ninguno`— o una `--integration` que no existe, `init` escribía la instancia entera y recién después
+  salía con error: el código de salida decía que no había pasado nada y el segundo intento encontraba la
+  carpeta creada. Ahora valida los dos valores antes de escribir.
+
+  **Qué cambia para vos**: nada con un valor correcto. Con uno mal escrito, el destino queda como estaba.
+
+- **El bloqueo de `verify` cita la prueba que falló.** Mostraba la primera línea de la salida que dijera
+  «error», y en un reporte de pruebas ésa puede ser una verde cuyo nombre lo dice. Ahora, con la salida de
+  `node --test` —spec y TAP— y de `go test`, cita la primera prueba en rojo; con otras herramientas sigue
+  buscando por palabra, pero ya no elige una línea marcada como verde.
+
+  **Qué cambia para vos**: el mensaje apunta a la prueba que hay que mirar.
+
+- **Cada bloqueo con salida angosta dice qué líneas pegar.** Aprobar en `planning/.ops-approval` sólo
+  funciona si la ruta está escrita en la forma que ese guard coteja —absoluta la de un `Write`, relativa
+  al repositorio la de un commit—, y el mensaje decía «escribí esa(s) ruta(s)» sin nombrarlas. `verify`
+  y `dependencies` ni siquiera mostraban la línea. Ahora cada bloqueo imprime las líneas exactas, y
+  pegarlas tal cual destraba ese mismo bloqueo.
+
+  **Qué cambia para vos**: si una aprobación no pegaba y terminabas exportando la variable del guard,
+  pegá lo que dice el mensaje.
+
+- **`plan-first` deja de frenar la configuración y los archivos de la instancia.** Frenaba
+  `ops.config.json` —justo el archivo que el límite de raíces manda a editar para declarar una ruta— y,
+  en sidecar, también `AGENTS.md`, `CLAUDE.md`, `package.json` y `.gitignore` de la instancia, como si
+  fueran producto. Ahora producto es el código de una raíz declarada: la instancia sidecar no lo es
+  aunque viva dentro de su raíz (`..`), y lo que queda fuera de toda raíz —lo declarado en
+  `writableOutsideRoots`— tampoco. En embedded, el `package.json` de la raíz sigue siendo producto.
+
+  **Qué cambia para vos**: si aprobabas esas rutas a mano en `.ops-approval` o exportabas
+  `OPS_PLAN_FIRST_OVERRIDE` para poder tocarlas, ya no hace falta.
+
+- **`verify` deja afuera del índice de su copia lo que enlaza.** Cuando el árbol difiere del índice, el
+  guard corre los gates sobre una copia del índice con lo ignorado enlazado —`node_modules`, `.env`—. Si
+  tu `.gitignore` escribe ese directorio con barra final (`node_modules/`), el enlace entraba al índice de
+  la copia, y un gate que recorre lo trackeado —`git ls-files`— lo recibía como si fuera parte del commit.
+
+  **Qué cambia para vos**: si una suite que pasa a mano fallaba bajo `verify` sólo cuando tenías archivos
+  sin trackear, podía ser esto.
+
+## [0.79.0] - 2026-09-10
+
+### Corregido
+
+- **La fila que registra una parada se escribe antes de parar.** Cuando ningún plan sobrevive a la
+  crítica, el recorrido pide que la tarea quede en `HUMAN_ACTIONS.md` con su motivo —así `context` deja
+  de ofrecerla y alguien la ve—. Esa escritura se lanzaba y el recorrido volvía en la línea siguiente,
+  así que el agente que la escribía se quedaba a mitad de camino: en una corrida real el resumen contó
+  diez agentes y el registro nueve. La parada se informaba bien y el disco no la tenía.
+
+  Ahora se espera. Y en las tres paradas que dejan fila —plan rechazado, tarea que no está lista,
+  criterio que no dice qué aserciar— si el agente no contesta, el detalle de la parada lo dice: el
+  motivo sigue siendo el que la causó, y se agrega que la fila hay que escribirla a mano.
+
+  **Qué cambia para vos**: relanzar después de un plan rechazado deja de repetir la planificación
+  entera, porque la tarea queda registrada. Si venías viendo que `context` te ofrecía otra vez la tarea
+  que acababa de rechazarse, era esto.
+
+- **El guard de migraciones frena por haber viajado, no por estar en disco.** Escribir una migración son
+  dos pasos —crearla y completarla— y el segundo se bloqueaba: el chequeo preguntaba si el archivo
+  existía, que no es la pregunta. Un stub de hace dos segundos y una migración publicada hace un año
+  daban la misma respuesta, y **ninguna herramienta lo esquivaba** —`Write`, `Edit` y `MultiEdit` se
+  bloqueaban igual—, así que lo único que quedaba a la vista era apagar el guard entero, incluida la
+  protección contra SQL destructivo.
+
+  Ahora se le pregunta a git si el archivo está en `HEAD`. En el índice no alcanza: un archivo apenas
+  agregado no viajó a ninguna parte. Y sin repositorio con el que contestar —un proyecto sin git— se
+  conserva la conducta anterior en vez de dejar pasar, que es el lado correcto para equivocarse cuando
+  no se puede saber.
+
+  **Qué cambia para vos**: completar una migración recién creada deja de frenarse. El mensaje del
+  bloqueo pasa a decir el hecho que lo sostiene —que está en el historial, o que existe y acá no hay con
+  qué saberlo— y a nombrar cómo aprobar esa ruta puntual en `planning/.ops-approval`, que es lo que el
+  bloqueo hermano ya hacía. Si tenías `OPS_MIGRATIONS_OVERRIDE=1` puesto para poder trabajar, ya no hace
+  falta y conviene sacarlo: apagaba también lo que sí te cuida.
+
 ## [0.78.0] - 2026-09-10
 
 ### Corregido

package/README.md

@@ -216,6 +216,7 @@ Lee [template/planning/PROTOCOL.md](template/planning/PROTOCOL.md) para el contr
 | `ops integration rebase <ops-root> jira KEY` | Recalcula el borrador canónico sin avanzar la base remota. |
 | `ops integration reconcile <ops-root> jira KEY` | Conserva curación sobre la nueva base remota. |
 | `ops integration writeback-plan <ops-root> jira` | Muestra escrituras posibles sin ejecutarlas. |
+| `ops secrets check <ops-root>` | Compara el contrato de secretos compartido contra cada servicio, sin conectarse. |
 | `ops automation list <ops-root>` | Lista adaptadores y su instalación. |
 | `ops automation list-hooks <ops-root>` | Describe los guards portables disponibles. |
 | `ops automation check <ops-root>` | Valida guards, permisos y configuraciones. |
@@ -314,9 +315,11 @@ La sincronización solo lee Jira. `writeback-plan` calcula intención local, no
 `writeBack` permanece en `false`. Consulta el [recorrido de Jira](template/integrations/jira/README.md) antes
 de conectar una instancia real.
 
-Para añadir otra herramienta se crea un adaptador en `engine/integrations/providers/` con `validateConfig`,
-`fetchItems` y `normalizeFixture`, y se registra en `engine/integrations/registry.js`. Staging, revisión,
-promoción y validación no se reimplementan. Consulta [integrations/README.md](integrations/README.md).
+Para añadir otra herramienta no hace falta tocar Cauce: el adaptador se escribe en la instancia, se
+registra con una ruta en el campo `adapter` y cumple el contrato —`contract: 1`, `validateConfig`,
+`fetchItems` y `normalizeFixture`—. Staging, revisión, promoción y validación no se reimplementan. El
+recorrido está en [template/integrations/README.md](template/integrations/README.md) y el contrato en
+[integrations/README.md](integrations/README.md).
 
 ## Hooks y runners
 

package/automatization/hooks/README.md

@@ -4,6 +4,7 @@ Los hooks convierten invariantes comprobables en gates mecánicos. La base recom
 
 - comandos destructivos, force, amend y stage indiscriminado;
 - escritura de secretos o credenciales;
+- lectura de credenciales conocidas o declaradas, en los runners que tienen una herramienta de lectura;
 - edición manual de código generado y drift respecto a OpenAPI/SQL;
 - commits sin Verify aplicable;
 - apagado o borrado de la prueba que juzga el cambio;
@@ -44,6 +45,20 @@ publica— por la sensación de que ya está cubierto.
 Regla práctica: si algo **tiene** que ser imposible, no lo pongas acá. Ponelo donde no dependa de leer
 una cadena — permisos del runner, alcance del token, aprobación de un PR.
 
+### Leer una credencial
+
+`secrets-read` frena leer, con la herramienta de lectura del runner, un archivo que `secrets` frenaría al
+escribir —los nombres conocidos y las identidades que declara `organization/secrets.json`—. Qué alcanza en
+cada runner es distinto, y conviene saberlo:
+
+- **Claude Code**: el guard corre en `Read`, y además la instalación agrega reglas `permissions.deny`
+  `Read(...)` por los nombres conocidos. Esas reglas las aplica el propio Claude Code a `Read`, a `cat`,
+  `head`, `tail`, `sed` y a las redirecciones, pero no a un `grep -r` ni a un subproceso que abra el archivo
+  por su cuenta. Van por nombre exacto: `.env.*` también negaría `.env.example`.
+- **Gemini CLI**: el guard corre en `read_file`. Un `cat` por `run_shell_command` no lo ve.
+- **Codex y Antigravity**: sin guard de lectura. Sus adaptadores sólo enganchan shell y edición, y leer por
+  shell no pasa por ningún matcher de archivo.
+
 ## Cómo se ejecutan
 
 ```text
@@ -67,8 +82,9 @@ runner, mientras la lógica se prueba y mantiene una sola vez en `engine/hooks/r
 
 | Grupo | Guards | Wrapper |
 |---|---|---|
-| `pre-shell` | destructive, git-add, dependencies, governance, verify | `guard-shell.sh` |
-| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence | `guard-files.sh` |
+| `pre-shell` | destructive, git-add, dependencies, governance, verify, shell-boundary | `guard-shell.sh` |
+| `pre-files` | secrets, generated, workspace-boundary, engine, migrations, integration-snapshot, test-evidence, plan-first | `guard-files.sh` |
+| `pre-read` | secrets-read | `guard-secrets-read.sh` |
 | `stop` | planning-drift | `guard-planning-drift.sh` |
 
 Registrar el grupo gasta un proceso por herramienta en lugar de cinco, con el mismo orden y la misma

package/automatization/hooks/guard-secrets-read.sh

@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+# Shim: qué bloquea el guard está en engine/hooks/run.js → guards['secrets-read'].
+exec "$(dirname "$0")/run-hook.sh" secrets-read

package/automatization/runners/claude/README.md

@@ -6,7 +6,9 @@ Adaptador nativo mediante `PreToolUse` y `Stop`. Instalar con:
 node tools/ops.js automation install . claude
 ```
 
-El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves. Si ya
+El instalador fusiona la sección `hooks` en `.claude/settings.json` y conserva otras claves. También
+suma a `permissions.deny` reglas `Read(...)` por los nombres de credencial conocidos, junto a las que el
+proyecto ya tenga; una que Cauce retire en una versión futura no se quita sola. Si ya
 existe una versión distinta de un archivo, se detiene sin sobrescribirla para no destruir
 personalizaciones del proyecto. También crea `CLAUDE.md` cuando no existe y conserva uno existente.
 

package/automatization/runners/claude/settings.json

@@ -1,4 +1,27 @@
 {
+  "permissions": {
+    "deny": [
+      "Read(.env)",
+      "Read(.env.local)",
+      "Read(.env.*.local)",
+      "Read(.npmrc)",
+      "Read(.netrc)",
+      "Read(_netrc)",
+      "Read(.pypirc)",
+      "Read(.dockercfg)",
+      "Read(id_rsa)",
+      "Read(id_dsa)",
+      "Read(id_ecdsa)",
+      "Read(id_ed25519)",
+      "Read(credentials)",
+      "Read(credentials*.json)",
+      "Read(*service-account*.json)",
+      "Read(*.pem)",
+      "Read(*.key)",
+      "Read(accesos.md)",
+      "Read(credenciales*)"
+    ]
+  },
   "hooks": {
     "PreToolUse": [
       {
@@ -12,6 +35,12 @@
         "hooks": [
           { "type": "command", "command": "$CLAUDE_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-files.sh" }
         ]
+      },
+      {
+        "matcher": "Read",
+        "hooks": [
+          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-secrets-read.sh" }
+        ]
       }
     ],
     "Stop": [

package/automatization/runners/gemini/README.md

@@ -19,6 +19,7 @@ instalación vieja, `.gemini/commands/ops/` queda huérfano y se borra a mano.
 
 Gemini CLI tiene hooks nativos y el adaptador los usa: `BeforeTool` y `AfterAgent` en
 `.gemini/settings.json`, declarados en `manifest.json`. Sólo corren si la carpeta está marcada como
-confiable —`GEMINI.md` explica qué avisa Gemini cuando no lo está—.
+confiable —`GEMINI.md` explica qué avisa Gemini cuando no lo está—. `read_file` pasa por
+`guard-secrets-read.sh`, que frena leer una credencial; un `cat` por `run_shell_command` no lo ve.
 
 Comprueba la instalación con `node tools/ops.js automation doctor . gemini`.

package/automatization/runners/gemini/settings.json

@@ -27,6 +27,15 @@
             "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-files.sh"
           }
         ]
+      },
+      {
+        "matcher": "read_file",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$GEMINI_PROJECT_DIR/{{OPS_DIR}}automatization/hooks/guard-secrets-read.sh"
+          }
+        ]
       }
     ],
     "AfterAgent": [

package/automatization/workflows/autobuild.js

@@ -355,6 +355,14 @@ const read = (prompt, options = {}) => agent(`${BASE}\n\n${prompt}`, options)
 const run = (prompt, options = {}) => agent(`${SCOPE}\n\n${prompt}`, options)
 const write = (prompt, options = {}) => agent(`${LEDGER}\n\n${prompt}`, options)
 
+// Las tres paradas que dejan una fila en HUMAN_ACTIONS delegan esa escritura a un agente, y esa fila es
+// el único rastro de la parada: sin ella el recorrido informa un estado que el disco no tiene. Por eso
+// se espera —lanzarla y volver en la línea siguiente la abandona— y por eso se mira si contestó.
+// Devuelve lo que hay que agregarle al detalle, vacío cuando la fila quedó pedida. Caso 087.
+const registerHuman = async (prompt, label) => (await write(prompt, { label })
+  ? ''
+  : ` — la fila en ${HUMAN} no se pudo registrar: escribila a mano`)
+
 // Gate, mutex de WIP y selección de tarea salen de un comando determinista: AWAITING_REVIEW, BACKLOG,
 // WIP y HUMAN_ACTIONS nunca entran al contexto de un modelo, y su tamaño deja de costar tokens.
 const readContext = () => read(
@@ -552,12 +560,13 @@ while (rounds++ < MAX_TASKS) {
   //
   // Lo que la fila le pide a una persona lo dice R17: dos rechazos sobre lo mismo son el disparador
   // posterior de división. No se parte acá porque partir es una decisión, y ésa no le toca al recorrido.
-  const planRejected = (reason, unit, found) => {
+  const planRejected = async (reason, unit, found) => {
     const detail = found.join('; ') || 'sin condiciones nombradas'
-    write(`Registrá ${unit.id} en ${HUMAN}: nadie pudo escribir un plan que sobreviva a la crítica. `
+    const nota = await registerHuman(
+      `Registrá ${unit.id} en ${HUMAN}: nadie pudo escribir un plan que sobreviva a la crítica. `
       + `Motivo: ${detail}. La acción humana es revisar si la unidad son dos resultados con vidas `
-      + `distintas y partirla —R17—, o dejarla entera con la razón escrita.`, { label: 'plan-human' })
-    return stop(reason, detail)
+      + `distintas y partirla —R17—, o dejarla entera con la razón escrita.`, 'plan-human')
+    return stop(reason, `${detail}${nota}`)
   }
 
   if (!planning.wipActive) {
@@ -571,9 +580,10 @@ while (rounds++ < MAX_TASKS) {
       )
       if (!ready) return stop('agent-unavailable', 'Ready no devolvió resultado')
       if (!ready.ready) {
-        await write(`Registrá ${task.id} en ${HUMAN} con el motivo y una acción humana exacta: ${ready.reason}.`,
-          { label: 'ready-human' })
-        return stop('not-ready', ready.reason)
+        const nota = await registerHuman(
+          `Registrá ${task.id} en ${HUMAN} con el motivo y una acción humana exacta: ${ready.reason}.`,
+          'ready-human')
+        return stop('not-ready', `${ready.reason}${nota}`)
       }
       if (ready.refinedAcceptance) task.acceptance = ready.refinedAcceptance
     }
@@ -793,9 +803,10 @@ while (rounds++ < MAX_TASKS) {
   // hacer parar a una persona por eso le cobra una interrupción por algo que se resolvía solo.
   const ambiguous = verified.uncovered.find((entry) => entry.cause === 'ambiguous')
   if (ambiguous) {
-    await write(`Registrá ${task.id} en ${HUMAN}: el criterio "${ambiguous.criterion}" no dice qué habría ` +
-      `que aserciar, y hace falta la decisión que lo fija.`, { label: 'verify-human' })
-    return stop('acceptance-ambiguous', ambiguous.criterion)
+    const nota = await registerHuman(
+      `Registrá ${task.id} en ${HUMAN}: el criterio "${ambiguous.criterion}" no dice qué habría ` +
+      `que aserciar, y hace falta la decisión que lo fija.`, 'verify-human')
+    return stop('acceptance-ambiguous', `${ambiguous.criterion}${nota}`)
   }
   if (verified.uncovered.length) {
     await run(`${asRole(cast.build)}Escribí sólo las pruebas que faltan en ${task.id}, con el mismo rojo ` +

package/engine/cli/args.js

@@ -32,6 +32,7 @@ const FLAGS = {
   adopt: [],
   agents: ['--json', '--own', '--system'],
   integration: ['--fixture'],
+  secrets: [],
   automation: ['--force'],
   learn: ['--flow', '--proposal', '--applied', '--archived', '--period'],
   evaluate: ['--cases', '--json', '--bench', '--force', '--record', '--flow'],

package/engine/cli/bootstrap.js

@@ -97,4 +97,4 @@ async function run(root, opciones, deps) {
   return { runner, provider, installed: true }
 }
 
-module.exports = { run, NO_RUNNER, NO_PROVIDER }
+module.exports = { run, validate, NO_RUNNER, NO_PROVIDER }

package/engine/cli/ops.js

@@ -95,11 +95,6 @@ async function init(target, cli) {
   if (existing.length && !force) {
     fail(`El destino no está vacío: ${root}. Usa --force para agregar solo archivos faltantes.`)
   }
-  IN.scaffold(root, { name, mode, force })
-  const relative = path.relative(process.cwd(), root)
-  const enter = relative && relative !== '.' ? `cd ${relative} && ` : ''
-  console.log(`\n✓ ${name}: sistema ops creado en ${root} (modo ${mode})`)
-
   // Preguntar exige una terminal, e instalar baja un paquete y escribe `node_modules`: las dos cosas
   // pasan cuando hay alguien mirando. Una corrida automatizada —CI, un contenedor, estas pruebas—
   // recibe la instancia materializada y decide por bandera, sin descargas ni preguntas implícitas.
@@ -112,6 +107,13 @@ async function init(target, cli) {
     interactive,
     install: cli.has('--install') || (interactive && !cli.has('--no-install')),
   }
+  // Se valida antes de escribir: un runner o una integración que no existen no pueden dejar una
+  // instancia hecha con el comando en error (caso 096). `BOOT.run` vuelve a validar con la misma función.
+  try { BOOT.validate(options) } catch (error) { fail(error.message, 2) }
+  IN.scaffold(root, { name, mode, force })
+  const relative = path.relative(process.cwd(), root)
+  const enter = relative && relative !== '.' ? `cd ${relative} && ` : ''
+  console.log(`\n✓ ${name}: sistema ops creado en ${root} (modo ${mode})`)
   let result
   try {
     result = await BOOT.run(root, options, {
@@ -166,6 +168,7 @@ function usage() {
   ops integration rebase <ops-root> <provider> <remote-key>
   ops integration reconcile <ops-root> <provider> <remote-key>
   ops integration writeback-plan <ops-root> <provider>
+  ops secrets check <ops-root>
   ops automation list <ops-root>
   ops automation list-hooks <ops-root>
   ops automation check <ops-root>
@@ -218,6 +221,7 @@ async function run(cli) {
   else if (command === 'integration') {
     await W.integration(arg[1], arg[2], arg[3], arg[4], cli)
   }
+  else if (command === 'secrets') W.secrets(arg[1], arg[2])
   else if (command === 'automation') W.automation(arg[1], arg[2], arg[3], cli)
   else if (command === 'learn') CAT.learn(arg[1], cli)
   else if (command === 'evaluate') CAT.evaluate(arg[1], arg[2], cli)

package/engine/cli/wiring.js

@@ -8,6 +8,7 @@ const fs = require('node:fs')
 const path = require('node:path')
 const F = require('../core/files')
 const I = require('../integrations/registry')
+const SE = require('../secrets')
 const A = require('../automation')
 const SC = require('../core/scan')
 const OB = require('../core/onboarding')
@@ -38,11 +39,18 @@ const INTEGRATION = {
     missing: 'Falta <provider>.',
     run: (root, provider) => {
       const source = path.join(IN.PROJECT_ROOT, 'template', 'integrations', provider)
-      if (!fs.existsSync(source)) fail(`Cauce no trae un adaptador para ${provider}.`, 2)
+      const fromCauce = fs.existsSync(source)
+      // Sin molde en Cauce no hay andamiaje que reponer: habilitar un proveedor propio es sólo el interruptor.
+      const own = !fromCauce && (providerRegistry(root).config.providers || {})[provider]
+        && fs.existsSync(path.join(root, 'integrations', provider))
+      if (!fromCauce && !own) {
+        fail(`Cauce no trae un adaptador para ${provider}. Uno propio vive en integrations/${provider}/ y se `
+          + `registra en integrations/config.json con "adapter": "./adapter.js"; con eso, enable lo conecta.`, 2)
+      }
       // Habilitar no es inicializar: repone lo que falte y conserva lo que ya esté. Una instancia que
       // trae el andamiaje de una versión anterior —o que ya tiene snapshots— sólo quiere el interruptor.
       providerRegistry(root)
-      IN.copyTemplate(source, path.join(root, 'integrations', provider), {}, true)
+      if (fromCauce) IN.copyTemplate(source, path.join(root, 'integrations', provider), {}, true)
       switchProvider(root, provider, true)
       console.log(`✓ ${provider}: conectado al proyecto y andamiaje en integrations/${provider}/.`)
       // Sólo se pide lo que falta: reencender un proveedor ya configurado no debería mandar a
@@ -277,8 +285,18 @@ function automation(action, rootArg, runnerName, cli) {
   fail(`Acción de automatización desconocida: ${action || '(vacía)'}`, 2)
 }
 
+function secrets(action, rootArg) {
+  if (action !== 'check') fail(`Acción de secretos desconocida: ${action || '(vacía)'}`, 2)
+  const result = SE.check(opsRoot(rootArg))
+  if (!result.declared) return console.log(`Sin ${SE.DECLARATION}: no hay contrato de secretos que comprobar.`)
+  for (const warning of result.warnings) console.log(`⚠ ${warning}`)
+  for (const error of result.errors) console.error(`✗ ${error}`)
+  if (result.errors.length) fail(`${result.errors.length} error(es) en el contrato de secretos`)
+  console.log(`✓ contrato de secretos: ${result.current} servicio(s) al día`)
+}
+
 // `init` enciende un proveedor en la misma corrida en que crea la instancia, y ésta es la operación
 // que lo hace: se expone para que la composición no tenga que conocer la tabla entera.
 const enableProvider = (root, provider) => INTEGRATION.enable.run(root, provider)
 
-module.exports = { scan, onboard, integration, automation, enableProvider }
+module.exports = { scan, onboard, integration, automation, secrets, enableProvider }

package/engine/config/paths.js

@@ -10,7 +10,9 @@ const path = require('node:path')
 
 // `~` se expande sólo cuando es el prefijo entero. `~datos` es un nombre de directorio válido y no la
 // casa de nadie; expandirlo ahí convertiría una ruta relativa en una absoluta que el autor no escribió.
-function resolve(root, entry) {
+// La usa también el contrato de secretos para las rutas de sus identidades, por la misma razón que
+// arriba: una ruta declarada en un archivo del proyecto se resuelve igual la lea quien la lea.
+function resolvePath(root, entry) {
   return path.resolve(root, String(entry).replace(/^~(?=$|[/\\])/, os.homedir()))
 }
 
@@ -21,7 +23,7 @@ function resolve(root, entry) {
 function writableOutsideRoots(root, config) {
   const declared = config && Array.isArray(config.writableOutsideRoots) ? config.writableOutsideRoots : []
   return declared.filter((entry) => typeof entry === 'string' && entry.trim())
-    .map((entry) => ({ declared: entry, path: resolve(root, entry) }))
+    .map((entry) => ({ declared: entry, path: resolvePath(root, entry) }))
 }
 
-module.exports = { writableOutsideRoots }
+module.exports = { writableOutsideRoots, resolvePath }

package/engine/hooks/approval.js

@@ -41,10 +41,14 @@ function pending(root, files) {
   return files.filter((file) => !approved.has(file))
 }
 
-// Cómo se toma la salida angosta, dicho una vez porque ahora lo dicen cinco bloqueos. Nombra también la
-// variable: sigue existiendo, y esconderla haría que quien la necesite la descubra sin saber su alcance.
-const HOW = (variable) => `Aprobalo escribiendo esa(s) ruta(s) en planning/${APPROVAL}, una por línea: `
-  + `vale para ese conjunto y deja de valer en cuanto cambie. La variable ${variable}=1 sigue existiendo `
+// Cómo se toma la salida angosta, dicho una vez porque lo dicen todos los bloqueos que la tienen. Lleva
+// las líneas exactas porque cada guard coteja la ruta en la forma que tiene a mano —absoluta la que llega
+// de un Write, relativa al repositorio la que sale del índice— y una línea en la otra forma no pega: sin
+// decirla, lo que quedaba a mano era la variable (caso 089). Nombra también la variable: sigue
+// existiendo, y esconderla haría que quien la necesite la descubra sin saber su alcance.
+const HOW = (variable, lines) => `Aprobalo pegando tal cual en planning/${APPROVAL} estas líneas:\n`
+  + lines.map((line) => `  ${line}\n`).join('')
+  + `Valen para ese conjunto y dejan de valer en cuanto cambie. La variable ${variable}=1 sigue existiendo `
   + 'y apaga el guard para toda la sesión, que es por lo que no es la vía recomendada.'
 
 module.exports = { APPROVAL, read, pending, HOW }