--- title: "Tres capas, y sólo una de ellas impone algo" description: "El contexto aconseja, el hook niega en la tool call y la CI recalcula el diff, sólo en nuestro repo. Cada capa existe porque la de arriba puede fallar." url: https://commitcycle.com/es/three-layers/ language: es --- # Cada capa está ahí porque la de encima puede fallar > El contexto aconseja, el hook niega en la tool call y la CI recalcula el diff, sólo en nuestro repo. Cada capa existe porque la de arriba puede fallar. Tres capas Shipped · probado sólo en Claude Code Un fichero se puede ignorar. Un hook puede no estar. Un pull request no puede ser ninguna de las dos cosas, pero llega demasiado tarde para detener nada. Ninguna de las tres basta, y ésa es toda la razón de que haya tres. **Editor:** cycle start escribe la task en un CLAUDE.local.md ignorado por git, junto al mapa de zones de AGENTS.md, y cycle submit la vuelve a sacar. **Claude Code:** El hook rechaza la escritura antes de que ocurra, nombra la zone y su owner, y el agente pide acceso en vez de buscar otro camino. Claude Code es donde se ha visto funcionar este bloqueo. **Pull request:** La capa 3 vuelve a comprobar el diff contra lo que declaró la task. Hoy corre en el propio CI de CommitCycle, en modo consultivo; nada la instala en el tuyo. ## Capa 1 — el contexto, que aconseja [El bloque de AGENTS.md](https://commitcycle.com/es/agents-md/) lleva el mapa de zones, el board, la nota de entrega que espera y la regla de deploy; la task en sí — qué está abierto y qué está cerrado — se escribe en el gate en un `CLAUDE.local.md` ignorado por git, que carga Claude Code — si otros editores lo cargan no se ha comprobado nunca — y se retira al entregar. Es honesto en su propio texto sobre ser un consejo: _nothing is stopping you, so this one is on you_. ## Capa 2 — el hook, que deniega Un hook previo a la llamada a la herramienta responde antes de que ocurra la escritura. El nuestro sólo restringe: puede denegar, y desde CC-1142 nunca responde allow, así que los avisos de permisos del propio harness siguen aplicándose. Lo que importa más que el mecanismo: - **El camino crítico nunca toca la red.** La decisión es local, así que una caída no puede abrir una zone — el backend nunca estuvo en el camino de la denegación, para empezar. - **Bash se contiene, no se clasifica.** Adivinar qué hará un comando de shell es una apuesta perdida, así que los comandos corren contra un snapshot de git y los cambios en paths protegidos que la task no tiene abiertos se revierten byte a byte; los paths ignorados por git no se ven. La contención se cierra cuando la llamada vuelve, así que lo que un comando deja corriendo se le escapa hasta que el cierre comprueba el diff contra las zones: un comando en segundo plano (el hook pregunta antes), uno en primer plano que agota su timeout, un `cmd &` dentro de otro. **25/25** vectores de escape contenidos, **0/20** falsos positivos — el 2026-08-03, sobre un corpus que elegimos nosotros; el eval de falsos positivos en vivo no ha corrido. - **68–83 ms en p95** contra un presupuesto de 100 ms — medido el 2026-08-03 con la primera versión del hook, en una máquina en reposo, y el p99 tocó 102 ms en un caso. CC-1377 lo volvió a medir en octubre de 2026 en dos VM en la nube: en la más lenta, wrapper y núcleo llegaron a 211–228 ms en p95 (carga 0,74–1,04), y el coste del hook sobre un proceso node lanzado por shell fue de 84–111 ms allí frente a 44–48 ms en la más rápida, con el mismo código — dos hosts, no un estudio. Conviene decirlo claro: **este mecanismo es commodity**. Claude Code, Codex, Cursor, Augment, Factory y Devin CLI exponen todos un hook que puede devolver deny, y en el que probablemente usas es gratis. Lo que no es commodity es [el modelo que consulta](https://commitcycle.com/es/zones/) — owners, caducidad y permisos acotados a una task declarada. ## La admisión que hace creíble el resto Medimos el harness contra sesiones reales el 2026-08-03, y es **fail-open en los cuatro modos de fallo**: crash, timeout, salida malformada, no instalado. Eso no es una nota al pie — es la razón por la que las otras dos capas existen con la forma que tienen. Un wrapper puede cerrar tres de esos modos negándose por su cuenta cuando el hook no puede responder — pero sólo si la failure policy del repositorio está en closed. Desde CC-1143 el valor por defecto es open: las llamadas siguen y se avisa a la sesión. El cuarto — _no instalado en absoluto_ — es invisible desde dentro de la máquina, así que sólo CI puede verlo, y sólo donde el check corre. ## Capa 3 — CI, que recalcula [El check de CI](https://commitcycle.com/es/ci/) lee el mapa de zones desde el propio checkout del pull request y recalcula qué zones tocó de verdad el diff, frente a lo que declaró la task — la declaración, no el grant, así que las aprobaciones y la caducidad no se comprueban. Es la única capa que podría ver trabajo producido donde CommitCycle nunca se instaló. Sus propios límites, dichos en voz alta: sólo corre en el propio repositorio de CommitCycle, y nada lo instala en el tuyo. Ahí, en un plan personal privado gratuito, la protección de ramas responde **403**, así que corre en modo aviso, lo dice y no puede detener un merge. Un board que no responde lo convierte en un skip que igualmente pasa, y en un pull request del mismo repositorio la rama puede reescribir el workflow que la comprueba. Un modo que impone y un check run desde el board están construidos y sin activar. ## Dónde se detiene el conjunto - **La capa 2 está probada en un solo harness.** El modelo de zones es agnóstico del agente; el punto de enforcement no. `cycle init` escribe ficheros de hook para Claude Code y Codex, y para Cursor y Windsurf si se piden, sólo donde ya hay un wrapper del hook en disco, así que en tu máquina no escribe ninguno y el hook es el del plugin — sólo en Claude Code, así que Codex, Cursor y Windsurf no tienen ninguno. Sólo en [Claude Code](https://commitcycle.com/es/claude-code/) se ha visto denegar en una instalación real — los demás, donde se escriben sus ficheros, no se han probado y reciben las respuestas en el formato de Claude Code. De la mitad de la task de la capa 1 sólo se sabe que llega a Claude Code, y la capa 3 no se puede instalar en tu repositorio. - **Una empresa puede bloquear el hook de plano.** Los managed settings existen exactamente para eso, y una política que bloquea las fuentes de hooks bloquea el nuestro junto con los de todos los demás. - **Nada de esto arbitra entre agentes.** Cada checkout queda confinado a su propia task y su propia rama, así que dos agentes en un mismo directorio comparten ambas; dos que discrepan siguen discrepando. Cómo se reparten el trabajo las capas está en [la documentación](https://commitcycle.com/docs/concepts/three-layers/) (en inglés), y el mapa que leen las tres es [el mapa de zones](https://commitcycle.com/es/zones/).