⚙️ Esfuerzo × garantía estricta
Una guía de comportamiento — por bien escrita que esté — es intención. El modelo puede olvidar, restarle prioridad o no activar la regla en el turno correcto. La disposición es mejor esfuerzo por naturaleza. Este módulo trata sobre la otra mitad: las palancas mecánicas que el harness realmente fuerza — o effortLevel y los hooks. Escribe la disposición e activa los bloqueos. Por sí solo, ninguno de los dos basta.
Contenido detallado
Por qué una guía de comportamiento es solo «el mejor esfuerzo»
La reflexión más sobria de todo el material fuente cabe en una frase: la disposición es una intención, no una garantía. Puedes escribir la guía de comportamiento más lúcida del mundo, hacer que la sesión la consulte y, aun así, el modelo puede olvidarla, darle menos prioridad o simplemente no activar la regla en el turno en que importaba. No porque la guía sea mala, sino porque una guía, por naturaleza, es mejor esfuerzoDepende de que el modelo lo recuerde.
⚙️ La idea en una frase
Una guía de comportamiento es la capa de disposición: moldea lo que el modelo tiende a hacer, y la prosa cierra una parte real de la brecha. Pero "tiende a" no es "va a". Quien confía solo en el prompt confía en el mejor esfuerzo de un sistema que tiene días malos.
La medida de esto está en los números: incluso el modelo fuente, con la disciplina más alta observada, ejecuta la prueba real después de editar en solo el 23% de los turnos. La intención estaba ahí. La ejecución se filtró. Precisamente esa filtración es la que bloquea un mecanismo estricto, y este módulo trata de instalarlos.
Qué es
La capa de disposición es todo lo que vive en prosa: el Fable_Mindset, las reglas de tu CLAUDE.md, los «siempre haz X / nunca hagas Y». Es probabilísticaaumenta la probabilidad de que el comportamiento aparezca, pero nunca la lleva al 100%. La garantía firme es lo contrario: es lo que ejecuta el harness independientemente de que el modelo coopere.
Por qué aprender
Porque la tentación del operador principiante es resolver todo escribiendo más reglas. Cuando el agente «a veces no ejecuta las pruebas», la reacción instintiva es agregar una más "¡SIEMPRE ejecuta las pruebas!!!" al prompt — en mayúsculas y con signos de exclamación. Eso aumenta un poco la probabilidad, pero en nada la garantía. El operador avanzado reconoce cuándo un problema es de disposición (se resuelve con prosa) y cuándo es de mecánica (solo una barrera lo resuelve).
✓ Lo que la disposición hace bien
- ✓Moldea el tono, el estilo y la postura predeterminados
- ✓Aumenta la probabilidad de que aparezcan buenos hábitos
- ✓Cubre los casos que ningún bloqueo previó
- ✓Da el porqué — el bloqueo solo da el qué
✗ Lo que la disposición NO garantiza
- ✗Que la regla se active en el turno en que importaba
- ✗Que el modelo no la relegue bajo presión
- ✗Que la prueba se ejecute toda vez después de una edición
- ✗Repetibilidad — hoy funciona, mañana puede fallar
La pregunta que clasifica el problema
Antes de agregar una línea más al prompt, pregúntate: "¿es cuestión de que el modelo quiera hacerlo o de que pueda olvidarlo?" Si se trata de querer —tono, postura, criterio—, la prosa es el lugar adecuado. Si se trata de olvidar —un paso que debe ocurrir toda esta vez — ninguna prosa basta; necesitas un bloqueo. Escribir una regla para un problema mecánico es tratar una fractura con consejos.
Densidad de razonamiento = effortLevel, no el antiguo token budget
El primer límite estricto es la densidad de razonamiento. El Fable_Mindset insiste en que razonar no es overhead, sino el trabajo; pero la prosa solo lo pide, no lo asigna más razonamiento. Quien lo asigna es el harness, y la palanca correcta en Opus 4.8 es el effortLevelAquí está la trampa en la que cae casi todo operador que viene de modelos anteriores.
🧠 La palanca adecuada — y la que no hace nada
- ✓ Usa el effortLevel. En Opus 4.8, la densidad del razonamiento se controla mediante effortLevel en xhigh o máx., manteniendo alwaysThinkingEnabled conectado. Es el harness quien decide cuánto piensa el modelo; no es una petición en prosa.
- ✗ Olvida el MAX_THINKING_TOKENS. La variable de entorno antigua no hace absolutamente nada en modelos de thinking adaptativo. El modelo decide por sí solo cuándo y cuánto pensar; ignora un límite fijo de tokens. Confiar en ella es configurar una palanca desconectada.
# eleva la densidad de razonamiento solo en esta sesión
/effort máx.
Usa /effort max cuando el trabajo de la sesión realmente requiera un mayor ritmo de razonamiento. Para fijarlo de forma permanente, prefiere effortLevel: "max" en la configuración. Lección: la prosa de la guía cierra parte de la brecha de razonamiento; el effortLevel cierra el resto.
✗ Configurar la palanca inactiva
- ✗Configurar MAX_THINKING_TOKENS y creer que algo cambió
- ✗Esperar que un techo fijo controle el thinking adaptativo
- ✗Pedir «piensa más» en prosa y dejarlo ahí
- ✗Depurar un razonamiento superficial modificando la variable equivocada
✓ Accionar la palanca activa
- ✓effortLevel: "xhigh" o "max" en la configuración
- ✓alwaysThinkingEnabled: true conectado junto
- ✓/effort max para la sesión puntual
- ✓Effort + las reglas de razonamiento de la guía, juntos
Cuando ni siquiera el effort basta
La densidad de razonamiento del modelo de origen depende en parte intrínseca — no se reproduce al 100 % solo con instrucciones ni solo con effort. Para el trabajo que realmente exige esa cadencia, la palanca final es cambiar de modelo directamente con /model fableEffort eleva lo que el modelo actual puede ofrecer; no inventa razonamiento que no esté en los pesos.
Hábito determinista = el hook PostToolUse
Esta es la barrera más poderosa del arsenal, porque transforma un hábito probabilístico en un evento determinístico. "Después de una edición, ejecuta las pruebas" es la regla en la que más falla el modelo fuente: en el 23% de los turnos. La solución no es gritar la regla más fuerte; es quitársela de las manos al modelo. Un hook PostToolUse casado en Edit|Write|MultiEdit ejecuta la prueba quieras o no que el agente lo recuerde.
{ "hooksEnabled": true, "hooks": { "PostToolUse": [ { "matcher": "Edit|Write|MultiEdit", "hooks": [ { "type": "command", "command": "npm test" } ] } ] } }
O matcher se adapta a cualquier herramienta de edición; el command es la prueba real del proyecto. Sin "hooksEnabled": true no se activa nada; esta flag es el interruptor general. Lección: lo que debe pasar toda esta vez no puede depender de la memoria del agente; necesita un disparador del harness.
✗ Confiar en la intención
- ✗"Recuerda ejecutar las pruebas después de editar" en el prompt
- ✗Se activa cuándo el modelo lo recuerda — 23% de los turnos
- ✗Con carga o una conversación larga, la regla se evapora
- ✗Descubres el error solo después, sin que se haya ejecutado la prueba
✓ Activar el hook
- ✓El harness ejecuta la prueba después de cada edición, siempre
- ✓Se activa quieras o no que el agente lo recuerde — 100%
- ✓Inmune a la carga, al contexto largo y a un mal día del modelo
- ✓El resultado de la prueba vuelve antes de que el agente continúe
No todo hábito se convierte en hook — y está bien
El hook es perfecto para lo que se reduce a «después del evento X, ejecuta el comando Y". Pero las reglas que requieren criterio — como "prefiere las rutas absolutas a cd" — no se reescriben de forma confiable mediante un hook, porque requieren un contexto que una coincidencia de patrones no tiene. Estas siguen como regla de disposición. Usa el bloqueo donde corresponde; deja que la prosa cubra el resto.
Dónde reside la regla: CLAUDE.md vs auto-memory
Una regla de disposición correcta, en el lugar equivocado, deja de ser una garantía. El effortLevel y los hooks son los bloqueos rígidos; la guía de comportamiento es la capa flexible, pero dónde tú mismo guardas esta capa y decides si se carga de forma confiable o si desaparece durante turnos enteros. Y el detalle engañoso es que auto-memory parece el lugar obvio, y no lo es.
CLAUDE.md
Las reglas de disposición encajan bien aquí. El CLAUDE.md se inyecta toda sesión, de forma determinista: la regla está siempre en el contexto, en cada turno, sin depender de que el modelo "recuerde buscar".
Es el lugar correcto para la guía de comportamiento y las reglas de conducta.
auto-memory
No es el lugar para una regla de comportamiento. El recall es relevance-gatedla memoria solo aumenta si el turno actual la considera relevante. Una regla de disposición puede no disparar en el turno en que importaba.
Ideal para hechos puntuales; arriesgada para reglas que deben cumplirse siempre.
📌 Para las reglas de comportamiento, lo determinista prima sobre lo relevante
La diferencia está en la forma de carga. CLAUDE.md é carga garantizada: presente en todos los turnos por diseño. La memoria automática es carga condicional: presente si dejar pasar el filtro de relevancia. Para un hecho ("el deploy es en Vercel"), basta con que sea condicional — solo importa cuando surge el tema. Para una regla de comportamiento ("siempre verifica lo que cambió"), lo condicional es una falla a punto de ocurrir: debe aplicarse justo en los turnos en que el gate podría no considerarla relevante.
Por eso la heurística es directa: la regla que debe aplicarse siempre va en CLAUDE.md; un hecho que solo importa a veces puede ir a la memoria.
La prueba del "turno malo"
Para decidir dónde va una regla, imagina el peor turno: el contexto está lleno, el tema es otro, el modelo está bajo carga. La regla todavía ¿necesita estar ahí? Si es así, exige una carga determinista — CLAUDE.md, no auto-memory. La memoria brilla precisamente cuando el turno trae el tema a la vista; falla cuando la regla debía estar ahí a pesar de del turno.
Los output styles sirven para el tono y el papel, no para la disciplina agéntica
Existe un tercer mecanismo que intenta convertir cada operador en un vehículo de comportamiento, y es el vehículo equivocado: los estilos de salidaExisten y son útiles, pero para lo que fueron creados: tono y papelAplicar disciplina agéntica en un output style es usar la herramienta adecuada para el problema equivocado, y el comportamiento que querías garantizar sigue siendo best-effort, solo que en un lugar más oculto.
🎭 Cada vehículo tiene su cargo
Hay tres vehículos diferentes, y confundirlos es la fuente más común de una configuración frágil. Cada uno lleva un tipo de instrucción — y solo uno de ellos es una garantía firme:
✓ Output style: para qué sirve
- ✓"Responde como un revisor sénior, de forma concisa"
- ✓O rol que el modelo encarna en la respuesta
- ✓El registro: formal, didáctico, telegráfico
- ✓La persona y la voz de la respuesta
✗ Output style: lo que NO incluye
- ✗"Ejecuta siempre las pruebas después de editar" → va en el hook
- ✗"Razona antes de actuar" → effort + CLAUDE.md
- ✗"Verifica antes de declarar que está listo" → disposición
- ✗Cualquier disciplina de proceso, no de voz
La pregunta que separa el tono de la disciplina
Antes de poner algo en un output style, pregúntate: "¿esto describe cómo suena la respuesta o lo que hace el agente?" Si es cómo suena — voz, papel, registro: el output style es el vehículo adecuado. Si es lo que hace — un paso del proceso, un hábito de verificación: está en el lugar equivocado; pásalo a la configuración (CLAUDE.md) o, mejor aún, al control (hook/effort). El estilo es ropa; la disciplina es músculo.
Unir los dos: disposición (flexible) + bloqueos estrictos = garantía
Aquí todo converge. La guía de comportamiento es la capa de disposición; o effortLevel y los hooks son las garantías estrictas. La tesis del material fuente es una sola: usa los dos. Por sí sola, ninguna basta. La prosa cierra parte de la brecha; el bloqueo cierra el resto. Escribe la disposición e activa los bloqueos: esta conjunción es todo el montaje operativo.
Escribe la disposición en CLAUDE.md
Dirige la sesión a la guía de comportamiento y pon las reglas de actitud en el CLAUDE.md — se carga en cada sesión, de forma determinística. Es la capa flexible, y es ahí donde pertenece. No en auto-memory ni en output style.
Ajusta la densidad del razonamiento
Configura effortLevel: "xhigh" o "max" con alwaysThinkingEnabled conectado (o /effort max en la sesión). Ignora MAX_THINKING_TOKENS — palanca muerta en thinking adaptativo.
Fija el hábito que debe ser determinista
Instala el hook PostToolUse en Edit|Write|MultiEdit que ejecuta la prueba real, con hooksEnabled: true. El paso que debe ocurrir siempre deja de estar en manos del modelo y se convierte en un evento del harness.
Deja que la prosa cubra lo que la restricción no alcanza
Lo que requiere criterio — rutas absolutas vs cd, cuándo consolidar, cómo narrar: eso sigue dependiendo de la disposición. El bloqueo cubre lo repetible y determinista; la prosa cubre lo contextual. Juntos, cierran toda la brecha.
✗ Disposición por sí sola
- ✗Best-effort: funciona en el mejor día, falla en el peor
- ✗La prueba se ejecuta cuándo el modelo lo recuerda (23%)
- ✗No repetible: el mismo prompt, distintos resultados
- ✗Confías en el mejor esfuerzo de un sistema que tiene días malos
✓ Disposición + protecciones estrictas
- ✓La prosa aumenta la probabilidad; el límite garantiza el mínimo
- ✓La prueba se ejecuta toda esta vez, recuérdaselo al agente o no
- ✓Repetible: el comportamiento garantizado no depende del día
- ✓Disposición e mecánica — el montaje completo
⚙️ El puente más importante
Trata la guía como la capa de mentalidaddirige las sesiones a él deliberadamente. Y conecta el hook de prueba y el effortLevel por separado, como los garantías estrictas. La disposición le dice al modelo qué querer; el bloqueo elimina la dependencia de que quiera hacerlo. Uno sin el otro deja un hueco: la prosa falla en los turnos difíciles, el bloqueo sin prosa no sabe cómo manejar el caso que nadie previó.
Es la misma lógica que atraviesa toda la ruta: heredas el método sin heredar la mente. La disposición es el método en prosa; el bloqueo es el método mecánico. Escribe la disposición y configura las barreras — y el comportamiento deja de ser una esperanza para convertirse en una propiedad del sistema.
La regla práctica del operador
Para cada comportamiento que quieras, hazte dos preguntas en orden: "¿esto tiene que ocurrir siempre?" e "¿esto se reduce a un disparador determinístico?". Sí y sí → se convierte en hook o config. Sí, pero requiere criterio → se convierte en regla en el CLAUDE.md. Solo a veces → puede ser un hecho en la memoria. Nunca confíes a un vehículo blando lo que necesita ser firme.
📝 Resumen del Módulo
- ✓Una guía de comportamiento es mejor esfuerzo: el modelo puede olvidar la regla, darle menos prioridad o no activarla en el turno adecuado
- ✓Densidad de razonamiento = effortLevel (xhigh/máx., o /effort max) — no o MAX_THINKING_TOKENS, que no hace nada en el pensamiento adaptativo
- ✓Hábito determinista = hook PostToolUse en Edit|Write|MultiEdit que ejecuta la prueba, recuerde o no el agente (hooksEnabled: true)
- ✓La regla está en el CLAUDE.md (se carga en toda sesión); la auto-memory es relevance-gated y puede que no se active
- ✓Output styles son para el tono y el papel — no para la disciplina agéntica
- ✓Une los dos: disposición (flexible) + bloqueos estrictos = comportamiento garantizado. Por sí sola, ninguna basta
➡️ Siguiente Módulo
3.7 — 🏁 Proyecto final. Ya tienes el análisis, la consolidación y las barreras. Ahora es hora de reunirlo todo en un proyecto que aplique el método de punta a punta: leer la evolución, destilar la guía y configurar las garantías estrictas en un sistema que se sostiene por sí solo.