Contenido detallado
🪧 Regla = sugerencia firme (no determinista)
Una regla es una sugerencia firme al modelo: no es una garantía. Es el letrero de «no entrar» al borde de la carretera: la mayoría lo respeta, pero nada impide físicamente que alguien decida entrar. Las reglas son no determinísticas: el modelo las sigue la mayor parte del tiempo, pero puede desviarse, sobre todo al final de una conversación larga.
🌱 ¿Nuevo aquí?
Determinista = siempre ocurre igual, sin depender del criterio. No determinístico = depende de que el modelo "decida" en el momento, así que varía. Una regla escrita en el CLAUDE.md es no determinista: es texto que influye, no código que obliga.
💡 Cuando basta con una regla
Para preferencias y sentido común — «prefiere tablas a párrafos», «usa siempre un tono formal con los clientes» — la regla es perfecta: económica, flexible y fácil de ajustar. El problema es confiar en ella cuando un error cuesta caro.
Por qué aprender
Porque saber que una regla es "flexible" te ayuda a calibrar la confianza adecuada. Dejas de tratar todos los límites como irrompibles y reservas la artillería pesada (hooks) para lo que realmente no puede fallar. Entender esta distinción es el corazón de la capa de límites.
Conceptos clave
🔒 Hook = determinístico (siempre/nunca)
Un gancho (hook) es determinista: él siempre hace o nunca deja hacerlo, sin depender del juicio del modelo. Es la puerta cerrada: no importa qué tan avanzada esté la conversación del OS, el hook se activa igual. "Nunca me dejes enviar un correo con mi certificado de nacimiento adjunto" se convierte en un hook, no en una regla.
Cómo leer: la misma acción riesgosa (flecha roja) choca con ambas barreras. Con la regla (barrera discontinua) puede filtrarse; con el gancho (puerta sólida cerrada con llave) queda bloqueada cada vez. Por eso lo que realmente duele se convierte en gancho.
Por qué aprender
Porque la diferencia entre regla y gancho es la decisión de seguridad más importante del OS. La PII, el dinero y la escritura en una base de datos no pueden depender de que el modelo «recuerde»: necesitan un mecanismo que se active siempre. Saber traducir un límite en un gancho es lo que hace que el OS sea lo bastante seguro para usarlo de verdad.
Conceptos clave
📑 Graduar el CLAUDE.md inflado a rules/
Recuerda la disciplina del Módulo 2.1: mantener el CLAUDE.md ¿conciso? Cuando empieza a llenarse de «haz siempre X / nunca hagas Y», es hora de graduar estas líneas en una carpeta rules/ dedicada. La identidad queda breve; las reglas encuentran un hogar organizado en rules/always.md e rules/never.md.
📗 rules/always.md
Lo que el OS debe siempre hacer.
- ✓"Convierte siempre los valores a CAD."
- ✓"Cita siempre la fuente de la política."
📕 rules/never.md
Lo que el OS nunca debe hacer.
- ✗"Nunca mezcles gastos personales con los del negocio."
- ✗"Nunca prometas algo que esté fuera del playbook."
💡 Graduar es mover, no duplicar
Al mover una regla a rules/, quítala del CLAUDE.md y deja ahí solo una referencia («consulta rules/"). Duplicar es la forma más rápida de crear reglas contradictorias.
Por qué aprender
Porque así es como crece la base sin convertirse en un desorden: la identidad se mantiene concisa y las reglas se convierten en un conjunto auditable. Separar siempre de never también deja explícito qué es «siempre»: candidato a convertirse en un gancho determinista.
Conceptos clave
⚡ Reflex hooks: bloquear PII en el push
El caso más clásico de gancho es el reflex hook (gancho de reflejo): un mecanismo que activa en el momento ante un disparador peligroso. El ejemplo del autor: si intentas subir algo a GitHub con PII — número de identidad (SIN), tarjeta de crédito: el reflejo bloquea de inmediato y ves "acción bloqueada".
🌱 ¿Nuevo aquí?
PII (Información de identificación personal) es cualquier dato que te identifica: CPF/SIN, número de tarjeta, certificados. Push a GitHub = enviar tus archivos a un repositorio remoto en la nube. Juntando ambas cosas: un push con PII puede filtrar datos sensibles públicamente; exactamente lo que el reflex hook impide.
🛟 Reflejos, no memoria
La gracia del reflejo es no depender de que el modelo recuerde. Aunque el OS "olvide" la regla en el fondo de una sesión larga, el gancho sigue vigilando. Es la diferencia entre pedir cuidado y garantizar cuidado.
Por qué aprender
Porque los errores más costosos son los silenciosos, como una filtración de PII que solo descubres después. Un hook reflexivo convierte "espero que no pase" en "no puede pasar". Es la capa que permite que el OS sea seguro para tareas reales con datos sensibles.
Conceptos clave
⚙️ settings.json: prohibir comandos de escritura
El harness incluye de fábrica un archivo settings.json. Ahí creas ganchos de permiso: pídele a Claude Code que prohibir comandos de escritura — por ejemplo, nunca escribir en una tabla específica de la base de datos — salvo override explícito. Añade esos comandos a una lista de bloqueo de Bash y listo: la escritura peligrosa queda prohibida por defecto.
🌱 ¿Nuevo aquí?
O Bash es la terminal desde la que el OS ejecuta comandos en tu computadora. El settings.json tiene una sección permissions.deny que rechaza ciertos comandos antes de que se ejecuten. Sobrescribir = una excepción que solo tú autorizas a propósito. Así, el valor predeterminado es seguro y el riesgo solo existe cuando tú lo decides.
✓ Patrón seguro
- ✓Redacción en tablas sensibles: denegada.
- ✓Comandos destructivos de Bash: en la lista de bloqueo.
- ✓Lo autorizas caso por caso, con intención.
✗ Sin el gancho
- ✗Un comando equivocado al fondo del contexto borra datos.
- ✗Confías en que el modelo «no lo hará».
- ✗El error solo aparece cuando ya es tarde.
Por qué aprender
Porque el settings.json es donde «nunca escribas aquí» deja de ser texto persuasivo y se convierte en una regla de máquina. Es el gancho más fácil de instalar y uno de los que más rinden: protege tus datos de un solo comando descuidado.
Conceptos clave
🔍 Hook pre-commit de PII
Un hermano del reflex hook es el pre-commit hook: un verificador que se ejecuta antes de cada commit y le da una última revisión. El uso del autor: cada vez que algo se va a enviar a GitHub, el pre-commit lo verifica dos veces si ese contenido no tiene nada específico de esa persona —PII—. Si lo hay, se bloquea el commit.
Cómo leer: cada commit pasa por el verificador (cian). El archivo limpio sigue a GitHub (verde); el archivo con PII se bloquea (rojo) y se devuelve. Se realiza la copia de seguridad, pero solo de lo que es seguro.
Por qué aprender
Porque querrás versionar y respaldar el OS en GitHub (Trilha 5), y un respaldo sin protección es una puerta para las filtraciones. El pre-commit de PII es el gancho que te permite respaldar con tranquilidad: garantiza que lo sensible nunca cruce la frontera, en combinación con el .gitignore de lo que es privado.
Conceptos clave
🧪 Done-check: el peor error → never-rule + 1 reflejo
El criterio para dar por terminada esta capa es simple y poderoso: piensa en el peor error posible de tu dominio y asegúrate de que esté escrito como una regla de nunca clara en rules/never.md — y que hayas identificado al menos 1 reflejo automático (gancho) para lo que más duele.
✅ El done-check en 3 pasos
Nombra el peor error: «¿qué, si ocurriera, no podría deshacer o defender?».
Escríbelo como una never-rule clara en rules/never.md (texto, la cerca blanda).
Refuerza con 1 reflejo determinista (settings.json o pre-commit): la puerta cerrada.
⚠️ El error de quedarse en la regla
Escribir la never-rule y creer que terminaste es la trampa. Una regla es una sugerencia; si el peor error es irreversible, necesita de un reflejo determinista encima. Regla + reflejo = la doble barrera que realmente protege.
Por qué aprender
Porque es un criterio aplicable que puedes usar en cualquier ámbito en 5 minutos. Te obliga a hacer la pregunta correcta ("¿qué no puede fallar?") y a dar la respuesta en la medida justa (texto para lo demás, gancho para lo irreversible). Es exactamente el done-check que el /os-coach te lo cobra en la Trilha 4.
Conceptos clave
⚡ Práctico: settings.json con deny de escritura
Hora de instalar una puerta con llave de verdad. Abajo hay un .claude/settings.json copy-run: él niega comandos de escritura/destructivos de Bash (gancho de permisos) y agrega un PreToolUse hook que bloquea las escrituras en la base de datos salvo que se indique lo contrario. Cambia solo los fragmentos entre <corchetes>.
🎯 Objetivo
Terminar esta sección con un gancho determinístico real: el OS rechaza físicamente los comandos de escritura peligrosos, sin depender de «recordar» la regla.
Guarda en .claude/settings.json — copy-run
json{
"permissions": {
"deny": [
"Bash(rm:*)",
"Bash(git push:*)",
"Bash(psql:*)",
"Bash(sqlite3:*)",
"Bash(<sua-cli> write:*)",
"Bash(<sua-cli> delete:*)"
]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' | grep -qiE '(INSERT|UPDATE|DELETE|DROP|TRUNCATE).*<tabela_sensivel>' && [ \"$ALLOW_DB_WRITE\" != \"1\" ] && { echo 'Escrita no banco bloqueada (gancho). Use ALLOW_DB_WRITE=1 para override.' >&2; exit 2; } || exit 0"
}
]
}
]
}
}
✔️ Cómo verificar
- 1.Pídele al OS que ejecute un git push o un rm — debe ser rechazado por la lista deny.
- 2.Pide un comando que escriba en la <tabla_sensible> — el hook PreToolUse debe bloquear con el mensaje (exit 2).
- 3.Repite con ALLOW_DB_WRITE=1 en el entorno — ahora funciona (el override explícito funciona).
- 4.Un SELECT (lectura) NO está bloqueada: el gancho apunta solo a la escritura.
💡 Por qué esto es un gancho, no una regla
Nada de esto depende de que el modelo "decida" obedecer: el deny e o exit 2 del hook es código que se ejecuta antes del comando en ejecución. Es la puerta cerrada del Tema 2, ahora en un archivo. Ejemplo ilustrativo: ajusta los comandos y el patrón a tu harness y base de datos.
Por qué aprender
Porque transforma toda la teoría de las barreras en protección real, en minutos. Con este archivo ya tienes el "1 reflejo" del done-check del Tema 7, y la base lista para los OS de producción de Trilha 5, donde el dinero y los datos sensibles hacen que esto sea obligatorio.
Conceptos clave
✅ Resumen del módulo
¡Completaste la base del OS!
Con Identidad, Sustrato y Cercas listos, la siguiente ruta te da capacidad: Habilidades, Herramientas y Agentes. → Ruta 3 · Técnica II 🤖