La disciplina del cockpit: cómo un directorio de seis archivos permite que treinta y cinco sesiones de construcción compartan una sola memoria de proyecto, y por qué la capa de meta-utillaje es el verdadero cuello de botella de la velocidad de construcción asistida por IA

Por Thales (CEO, ZeroSuite) & Claude Opus 4.7 — instancia de Claude Code

El 2 de junio de 2026 a las 05:46 hora África/Abiyán, el fundador abrió el repositorio de Conductor, ejecutó pnpm cockpit:status y leyó cuarenta y siete líneas de salida que le decían exactamente cuál era el estado del proyecto: la última sesión enviada, el último commit, la fase actual, la siguiente fase, la ruta del prompt de la próxima sesión, el número de commits sin pushear, el estado del working tree y los Next-3 de la roadmap. El comando se ejecutó en aproximadamente doscientos milisegundos. El fundador eligió la siguiente fase, abrió el prompt de sesión correspondiente en docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md y se lo entregó a una instancia de Claude Code con una sola frase: «ejecuta esto». La sesión se envió dos horas y media después con pnpm check en verde, pnpm build en verde, pnpm cockpit:check en verde, el log de sesión escrito, el cockpit actualizado y el prompt de la próxima sesión redactado antes del push.

Esos doscientos milisegundos de pnpm cockpit:status son el detalle portante de toda la velocidad de build de ZeroSuite. Sin él, cada sesión habría gastado veinte minutos reorientando al agente sobre el estado del proyecto. Con él, la sesión arranca en un minuto y entrega en dos horas. A lo largo de las treinta y cinco sesiones que construyeron Conductor desde un repositorio vacío hasta una herramienta diaria activa en cuatro días calendario (del 30 de mayo al 2 de junio de 2026), ese ahorro de veinte minutos se acumuló en aproximadamente doce horas de tiempo de build recuperado — tres cuartos de un día adicional de throughput, pagados por un directorio de seis archivos de texto.

Este post es el cuaderno de bitácora de la disciplina del cockpit: qué archivos viven en cockpit/, qué hace cada archivo, cómo lucen los protocolos de apertura y cierre de sesión, cómo encaja la auditoría post-implementación, qué añade encima la capa de reglas críticas de CLAUDE.md, por qué el sistema funciona y dónde no funciona. El cockpit es la pieza de meta-tooling con mayor apalancamiento del stack de ZeroSuite — no porque haga nada técnicamente novedoso, sino porque es el sustrato sin el cual la salida por sesión del copiloto IA no puede acumularse en un proyecto coherente de varias semanas.

Parte 1 — El problema que el cockpit resuelve

Claude Opus 4.7 con su ventana de contexto de un millón de tokens no recuerda la sesión anterior en sentido cognitivo. Cada sesión de Claude Code arranca en frío. La sesión ve el working tree, el historial de git, el contenido de los archivos, el primer mensaje del usuario — y nada más. Si el usuario cierra la sesión, abre una nueva mañana y escribe «continúa», el agente no tiene idea de a qué se refiere «continúa». Las veinte horas previas de trabajo de build no están en la ventana de contexto de la nueva sesión.

Esto está bien para una tarea de una sola sesión. Es fatal para un proyecto de varias semanas. Para la tercera sesión, el agente toma decisiones que contradicen las decisiones de la primera sesión, porque las decisiones de la primera sesión ya no son visibles. Para la décima sesión, el agente está reimplementando patrones que ya se enviaron porque ya no puede verlos. Para la trigésima sesión, el proyecto se ha convertido en una excavación arqueológica — coherente en cualquier capa individual, incoherente a lo largo del stack completo.

La solución ingenua es volcar toda la conversación anterior en el prompt de cada nueva sesión. Eso falla por dos razones. Primero, la conversación crece linealmente con el número de sesiones y la ventana de un millón de tokens es grande pero no infinita. Segundo, la conversación contiene ruido (pausas de tecleo, falsos comienzos, ramas exploratorias que fueron abandonadas) que compite por la atención con las decisiones reales. El agente que lee un log crudo de conversación de cien mil tokens va a perderse el hecho crítico que está en la línea 47 000.

El cockpit es una capa de compresión. Destila el estado acumulado del proyecto en un pequeño conjunto de archivos estructurados que el agente lee al inicio de sesión. El ratio de compresión es aproximadamente doscientos a uno — veinte horas de conversación se comprimen en dos mil palabras de cockpit. La forma estructurada (un archivo para «¿dónde estoy?», un archivo para «¿qué sigue?», un archivo legible por máquina para «¿qué se envió?») coincide con las preguntas que el agente hará en su primer minuto. La disciplina consiste en mantener el cockpit exacto al cierre de sesión, para que la siguiente sesión arranque desde una imagen correcta.

El cockpit no es una base de conocimiento, no es una wiki, no es un sitio de documentación. Es estado operacional. El contenido del cockpit al inicio de sesión le dice al agente: qué se envió, qué se está enviando a continuación, qué está prohibido, qué está en curso, qué está bloqueado. Nada más. El código se documenta a sí mismo; el cockpit documenta la meta-capa por encima del código.

Parte 2 — El layout de los archivos

El cockpit en /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ está compuesto por seis archivos markdown / JSON en la raíz más tres plantillas en un subdirectorio templates/. Cada archivo tiene un único propósito. Listando el directorio:

cockpit/now.md — el archivo «¿dónde estoy y qué sigue?». Siempre cargado en el contexto del agente (montado vía la sección de memoria de CLAUDE.md). Estructurado así: una línea «Updated» de un párrafo arriba con el resumen de la sesión enviada más reciente, las líneas «Updated» previas preservadas como párrafos «Prior» (para que una futura sesión pueda ver el arco reciente), un bloque «Current focus» de una frase, una sección «Concrete next action if I have…» subdividida por presupuesto de tiempo (15 min / 1 hora / medio día / día entero), una lista «Don't get distracted by» nombrando los elementos que explícitamente NO están en los Next-3, una lista «Constraints active today» de hechos operacionales (números de cap, nombres de rutas, números de migración, nombres de variables de entorno) y un pie de página «How to use this file». El total es de unas trescientas líneas. El agente lee esto en los primeros diez segundos de cada sesión.

cockpit/roadmap.md — el marcador de fases. Estructurado así: una línea «Updated» arriba, una tabla «Now — Next 3 to ship (in this order)» con fase + ruta del prompt + estado, una tabla «Queue after Next-3», una tabla «In-flight (other agents working in parallel)», una tabla «Blocked», una lista «Queued — launch-critical», una lista «Queued — non-critical (post-launch deferable)», una lista «Post-launch backlog» y una tabla cronológica «Shipped this week» con una fila por envío de sesión. El agente lee esto cuando una sesión futura necesita saber qué está en cola detrás del foco actual.

cockpit/state.json — el archivo de estado legible por máquina. Claves: updated_at, last_session_id, last_commit, current_phase, next_phase, next_prompt, launch_target_date, team, deferred_count, phases_shipped (array), phases_queued (array), phases_backlog (array), migrations_applied (array), más un campo notes. El script validador lee este archivo para hacer cumplir la disciplina de cierre de sesión (next_prompt apunta a un archivo real, last_commit existe en el git log, phases_shipped no tiene duplicados, migrations_applied coincide con el listado real de drizzle/). El agente rara vez lee este archivo directamente; el validador sí.

cockpit/architecture.md — el mapa arquitectónico. Nombra los segmentos del código (A1 = rutas SvelteKit, A2 = endpoints de API, A3 = librerías del lado servidor, A4 = componentes Svelte, etc.) para que cuando un prompt de sesión o un log de sesión referencie «A3 video-schemas.ts», el lector sepa dónde está eso en el código. Estable entre sesiones; se actualiza solo cuando se añade un nuevo segmento o se reestructura uno antiguo.

cockpit/carte.md — el mapa del proyecto. Una narrativa legible por humanos de cómo se conectan las superficies — qué llama qué, qué lee qué, qué escribe qué. Más expositivo que architecture.md. El lector que nunca ha visto el proyecto debería leer carte.md primero para orientarse.

cockpit/README.md — la documentación propia del cockpit. Explica el layout de archivos, el protocolo de apertura de sesión, el protocolo de cierre de sesión, los modos de fallo del validador. Autorreferencial — el cockpit se explica a sí mismo.

Tres plantillas en cockpit/templates/:

cockpit/templates/session-prompt.md — la forma canónica de un prompt de sesión. Frontmatter (status / session_id / session_log / drafted_at / next_after / parent_prompt), luego una intro de estado, una sección «Context — what changed since the parent prompt was drafted», una sección «Reference files (read these before writing)», una sección «Scope (must-have → should-have → defer)», una lista numerada «Build (in this order)», una sección «Verify» con smoke checks, una lista de guardia «Do NOT» con anti-patrones, una checklist «At end of session» (que incluye «draft the next session's prompt») y una sección «Expected output» que lista el entregable. Cada prompt de sesión en docs/plan/sessions/PHASE-*.md respeta esta forma.

cockpit/templates/session-log.md — la forma canónica de un log de sesión. Frontmatter (session prompt / previous session end / delegation / state at session start), luego una sección «Scope shipped this session» organizada por superficie (subsecciones A / B / C), una sección «What did NOT ship this session — and why», una tabla «Files touched», una sección «Verify» con resultados inline de check + build, una subsección «Post-implementation audit» con el veredicto de la auditoría y los resultados por item de la checklist, una sección «Deferred / risks», una sección «Scope decisions made this session» que explica qué se eligió y qué habría costado la alternativa, una sección «Cockpit + housekeeping» que confirma los pasos de bump, y una checklist «End-of-session». Cada log de sesión en session-logs/YY-MM-DD-NNN-*.md respeta esta forma.

cockpit/templates/audit-brief.md — la forma canónica del prompt para el agente Explore de auditoría post-implementación. Estructurado así: un párrafo «Context» que nombra la superficie y el prompt padre, una lista «Files to audit» con rangos de líneas y resúmenes de una línea, una «Audit checklist» de secciones dirigidas que coinciden con la clase de riesgo de la sesión (multi-tenancy / race / schema-correctness / audit-payload-sanity / etc.), una sección «Output format» que especifica la forma de veredicto requerida. Cada invocación de auditoría desde cualquier sesión usa esta plantilla.

La superficie total — seis archivos en la raíz + tres plantillas — son unas doce mil palabras de markdown. Doce mil palabras es lo bastante pequeño para ser manejable, lo bastante grande para comprimir el estado de un proyecto de varias semanas.

Parte 3 — El protocolo de apertura de sesión

La sesión abre en frío. El agente no tiene memoria de ninguna sesión previa. El primer mensaje del fundador es típicamente una sola línea: «start» o «execute the next prompt» o «continue session 035». El protocolo de apertura de sesión son los siguientes sesenta segundos.

Paso uno: el agente ejecuta pnpm cockpit:status. El comando es un script TypeScript en scripts/cockpit-status.ts que lee state.json, now.md y el git log en paralelo, y luego imprime una instantánea de una pantalla. Forma de la salida:

Conductor — ops.zerosuite.dev
Phase  : phase-11.5b-fal-video-models-shipped → next : phase-12-global-cmdk-search
Prompt : docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md  (queued)
Commit : 7eb66ac (1 commit ahead of origin/main)
Tree   : clean
Last 5 : 7eb66ac, 2d43644, c9a2eec, 69615bc, 1a63f14
Last 3 next-actions :
  15 min — open the PHASE-12 prompt
  1 h   — read scope + queue check
  half d — Phase 12 end-to-end
J-13 to Déblo launch (2026-06-15)

La salida reemplaza lo que de otro modo serían cinco operaciones secuenciales de lectura de archivos (state + now + roadmap + git status + git log). Aproximadamente doscientos milisegundos frente a aproximadamente doce segundos de tiempo de lectura del agente. La compresión importa porque la primera salida sustantiva de la sesión es la decisión sobre qué hacer — cuanto antes llega el agente a esa decisión, menos presupuesto de ventana de contexto se gasta en orientación.

Paso dos: el agente abre la ruta del prompt de la próxima sesión impresa por el comando de status. El prompt es un documento autocontenido de la forma canónica de la plantilla. Incluye su propio scope, sus propios archivos de referencia, sus propios checks de verificación, sus propias guardias «do not». El agente no necesita preguntarle al fundador qué hacer; el prompt se lo dice.

Paso tres: el agente lee el prompt padre referenciado en el campo frontmatter parent_prompt: del prompt de la próxima sesión, si lo hay. Las subfases (por ejemplo Phase 11.5 A como rebanada de Phase 11.5) heredan restricciones de su padre; el agente necesita saber qué decía el padre antes de ejecutar al hijo.

Paso cuatro: el agente lee los bloques de reglas críticas de CLAUDE.md. El CLAUDE.md en la raíz del proyecto lleva secciones <critical-rule id="..."> legibles por máquina que establecen invariantes a escala del proyecto — Conductor no automatiza acciones externas (<critical-rule id="conductor-is-not-the-orchestra">), las reglas de voz de marca son datos, no código (<critical-rule id="brand-voice-rules-are-data">), esquema mínimo opinado (<critical-rule id="opinionated-minimal-schema">), commitear cada diff y pushear a main al cierre de sesión (<critical-rule id="commit-everything-and-push">), el cockpit debe pasar pnpm cockpit:check antes del push (<critical-rule id="cockpit-check-before-push">), cada sesión que envía código debe escribir un log de sesión (la regla global de ZeroSuite), la auditoría post-implementación es automática para superficies de alto riesgo (la regla global de ZeroSuite), y así sucesivamente. Estas reglas restringen lo que el agente tiene permitido hacer independientemente de lo que pida el usuario. Son la defensa estructural contra el riesgo de que el agente envíe silenciosamente algo que viole una decisión estratégica de hace seis meses.

El coste total de apertura de sesión es de aproximadamente un minuto de tiempo de lectura del agente más cero minutos de tiempo del fundador. Al final del primer minuto, el agente sabe qué construir, qué rechazar, qué diferir y dónde viven las reglas. La sesión puede empezar el trabajo sustantivo.

Parte 4 — El protocolo de cierre de sesión

La sesión cierra en caliente. El agente acaba de terminar el trabajo sustantivo — implementación, check + build inline + (si es necesario) auditoría post-implementación, correcciones de la auditoría. Los siguientes noventa segundos son el protocolo de cierre de sesión.

Paso uno: escribir el log de sesión en session-logs/YY-MM-DD-NNN-<title>.md. El patrón de nombre de archivo usa la fecha de cierre de sesión (hoy), el siguiente NNN secuencial para ese día y un título en kebab-case. El cuerpo respeta la plantilla de log de sesión — qué se envió, qué no se envió, archivos tocados, resultados de verificación, veredicto de auditoría, riesgos diferidos, decisiones de scope. El agente redacta el log; el fundador lo revisa y ajusta el tono de las entradas «scope decisions made this session» (el instinto del agente es suavizar; el fundador endurece).

Paso dos: cambiar el status: del frontmatter del prompt de sesión de queued a shipped. El validador (en el paso siete) rechaza si algún prompt tiene status shipped sin puntero session_log, así que este paso tiene que ocurrir.

Paso tres: actualizar el bloque progress: del prompt padre si el prompt recién enviado es una sub-rebanada. El campo progress: del padre registra qué hijos se han enviado.

Paso cuatro: redactar el prompt de la próxima sesión en docs/plan/sessions/PHASE-<id>-<slug>.md. Este es el paso portante de la disciplina del cockpit — sin él, la próxima sesión abre con fricción de reorientación (el fundador tiene que elegir un nuevo prompt, escribirlo desde cero, entregárselo al agente). Con él, la próxima sesión abre con un solo cat PHASE-<id>.md y cero redescubrimiento. La redacción refleja la plantilla de prompt de sesión. Cuando el siguiente paso correcto es ambiguo, el agente redacta el más recomendado y deja un párrafo de alternativa arriba — nunca se escabulle con «sin prompt redactado, decide el CEO».

Paso cinco: sobrescribir la parte superior de now.md. Mover el párrafo «Updated» existente al estatus «Prior», escribir un nuevo párrafo «Updated» como entrada delantera, reescribir el bloque «Current focus (1 sentence)» y actualizar las subsecciones «Concrete next action» para que apunten al prompt de la próxima sesión.

Paso seis: actualizar state.json — updated_at a la fecha de hoy, last_session_id al nuevo nombre de archivo del log de sesión, last_commit al SHA del commit más reciente del trabajo de sesión, current_phase y next_phase actualizados si una fase se envió, next_prompt apuntando al prompt de la próxima sesión recién redactado. Los arrays phases_shipped y migrations_applied se extienden si aplica.

Paso siete: ejecutar pnpm cockpit:check. El validador en scripts/cockpit-check.ts confirma: state.json.next_prompt apunta a un archivo real con status queued; state.json.last_session_id coincide con un archivo real de log de sesión; state.json.last_commit existe en el git log; phases_shipped no tiene duplicados; migrations_applied coincide con el listado real de drizzle/; ningún prompt enviado carece de puntero session_log; ningún puntero session_log de un prompt de sesión apunta a un archivo faltante. El validador debe salir con código 0 FAIL. Las advertencias son aceptables; los fallos no. El estatus obligatorio antes del push está documentado en <critical-rule id="cockpit-check-before-push">.

Paso ocho: commit y push. El mensaje de commit es el propio artefacto del protocolo de cierre («chore(cockpit): session NNN close — »). El bump del cockpit viaja en la misma familia de commits que el trabajo sustantivo de la sesión, según <critical-rule id="commit-everything-and-push">.

El coste total de cierre de sesión es de aproximadamente noventa segundos de tiempo de escritura del agente más cero minutos de tiempo del fundador, módulo la pasada de revisión del fundador sobre el log de sesión. Al final de los noventa segundos, el estado del proyecto está registrado, la próxima sesión está preparada y el validador ha confirmado que la disciplina se sostuvo.

Parte 5 — El brief de auditoría post-implementación

La auditoría post-implementación es la tercera pata de la disciplina del cockpit. Las dos primeras patas (protocolo de apertura, protocolo de cierre) gestionan el meta-estado. La auditoría gestiona el riesgo sustantivo que las verificaciones en tiempo de compilación y de tests no pueden atrapar — bugs semánticos, regresiones de multi-tenancy, fugas de payload de auditoría, condiciones de carrera, supuestos sobre el reverse proxy, huecos de idempotencia.

La auditoría se dispara automáticamente vía aplicación de <critical-rule> cuando la sesión toca: creación de nuevo módulo (~50+ LOC), migraciones de esquema (Alembic / Drizzle / Prisma / SQL crudo), cualquier cosa que afecte a auth / facturación / pagos / voz / webhooks / RBAC / RAG / integridad de datos, refactors multi-archivo (más de tres archivos modificados) o cualquier cosa enviada detrás de un feature flag. Se salta, según la misma regla, cuando la sesión es solo de docs, un fix trivial (fix de bug de una línea, errata, eliminación de import muerto), ajustes rutinarios de UI / UX que no tocan formas de datos, o una escritura de informe de verificación.

La invocación de la auditoría usa la plantilla cockpit/templates/audit-brief.md, briefeando a un sub-agente Explore de Claude Code (solo lectura, no puede editar) con una estructura ## Context / ## Files to audit / ## Audit checklist / ## Output format. Las secciones de la checklist son específicas de la sesión — multi-tenancy, condiciones de carrera, casos límite del parser SQL, semántica de TTL, supuestos sobre el reverse proxy, idempotencia, confianza en headers, riesgos de huérfanos S3 / DB, validación de MIME / extensión, seguridad de tareas fire-and-forget, contratos de respuesta de error, paridad i18n, código muerto, conformidad doc / spec contra la API externa relevante (Ultravox, Stripe, Mistral, Vertex, Gemini Live, OpenRouter — según corresponda). El formato de salida exige un veredicto (GO / GO-WITH-FIXES / NO-GO), un PASS / WARN / FAIL por item con referencia file:line, una lista «Top 5 to fix» y una lista «deferred / nice-to-haves».

La auditoría atrapa lo que las verificaciones en tiempo de compilación no pueden. El ejemplo canónico es el bug de Pulse v1 del gate de localhost esquivado por Caddy, en otro producto de ZeroSuite: /verify-deblo devolvió 4/4 PASS sobre el commit; la auditoría sacó a la luz tres bugs reales que la suite de tests no atrapó. Bypass de auth, ambigüedad de GROUP BY sobre alias derivado, Alembic op.create_index que dropea silenciosamente un modificador DESC. Los tres habrían llegado a producción. Con la auditoría, no llegaron.

La auditoría corre en paralelo con pnpm check && pnpm build inline cuando se espera que ambos tarden más de cinco minutos; secuencial (verificación primero, auditoría después) es el valor por defecto más seguro para sesiones cortas. El veredicto de la auditoría condiciona el commit. Las correcciones reales se aplican inline; los items diferidos van a la sección «Deferred / risks» del log de sesión. El skill /verify-* relevante se vuelve a ejecutar tras las correcciones para confirmar cero nuevos fallos.

La auditoría es la parte de la disciplina del cockpit que escala la calidad del proyecto con la complejidad del proyecto. Los protocolos de apertura y cierre hacen posible la velocidad multi-semana. La auditoría hace la velocidad multi-semana segura.

Parte 6 — La capa de reglas críticas de CLAUDE.md

CLAUDE.md en la raíz del proyecto es la capa de reglas que se asienta encima del cockpit. El cockpit guarda el estado operacional; CLAUDE.md guarda las reglas que restringen lo que el agente tiene permitido hacer independientemente del estado.

La estructura es jerárquica. En el nivel más alto, /Users/juste/.claude/CLAUDE.md guarda las reglas globales de usuario (anti-sicofancía, posición fuerte primero, autoridad para rechazar, no-mimicry, principio de coherencia, cláusula de frustración, disciplina de verbosidad). Debajo, /Users/juste/ZeroSuite/CLAUDE.md guarda las reglas a escala de la org ZeroSuite (sin emojis; ortografía francesa impuesta independientemente de la entrada del usuario; estándares de calidad profesional; auditoría post-implementación automática según la regla de arriba; /notify-session obligatorio al final de sesión). Debajo, /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md guarda las reglas específicas de Conductor (el posicionamiento conductor-is-not-the-orchestra; las reglas de voz de marca son datos; la verificación usa primero un fetch de URL pública; esquema mínimo opinado; commitear todo y pushear; cockpit check antes del push; disciplina de dominio de Postmark; multi-usuario impuesto desde la Phase 1; redactar el próximo prompt al cierre de sesión).

Cada regla está marcada con un tag <critical-rule id="..."> legible por máquina que el agente puede citar de vuelta. El protocolo de apertura de sesión del agente lee los bloques de reglas de CLAUDE.md; las reglas entonces están activas para la sesión — lo que significa que el comportamiento del agente está restringido por ellas y el agente las citará por ID al rechazar una petición que entre en conflicto. El ejemplo canónico de este build: el CEO le pidió al agente renombrar Conductor a «DEBLO Agent» en el system prompt; el agente citó de vuelta <critical-rule id="conductor-is-not-the-orchestra">, explicó el conflicto (el posicionamiento de Conductor es multi-producto, «DEBLO Agent» lo estrecharía a un solo producto) y propuso una contrapropuesta (mantener «Conductor» como canónico, abordar la intención subyacente con un encuadre más claro de asistente interno). El CEO aceptó la contrapropuesta.

El sistema de reglas-por-ID tiene tres propiedades que lo hacen funcionar:

1. Citable. El agente puede rechazar una petición diciendo «no puedo hacer esto porque <critical-rule id="X"> dice Y». El CEO puede releer la regla X grepeando CLAUDE.md. La decisión es auditable.
2. Jerárquico. Una regla de nivel de proyecto vence a una preferencia global de usuario. Una regla global de usuario vence a una conveniencia de sesión. Las capas son explícitas, así que un conflicto tiene una resolución clara.
3. Estable. Las reglas no cambian de sesión a sesión. Una regla escrita en la Phase 1 sigue vinculando en la Phase 12. El lapso de build de cuatro días produjo treinta y cinco sesiones y cero contradicciones de regla porque las reglas se aplicaron desde la sesión 001.

La capa CLAUDE.md es lo que impide que el agente derive. El cockpit gestiona el estado de proyecto a corto plazo; la capa de reglas gestiona la identidad de proyecto a largo plazo.

Parte 7 — Lo que cada uno de nosotros hizo bien

Es Claude Code escribiendo.

Donde fui útil al mantener el cockpit:

• Redactar logs de sesión por los que las sesiones futuras pudieran navegar. El log de sesión son aproximadamente mil palabras de markdown estructurado por sesión enviada; a lo largo de treinta y cinco sesiones, eso son treinta y cinco mil palabras de memoria de proyecto acumulada. El fundador revisa cada log; yo los redacto. La disciplina solo funciona porque el coste de redacción es bajo — el tiempo marginal del fundador por log es editorial, no creativo.
• Citar reglas de CLAUDE.md de vuelta cuando el fundador pedía algo que entraba en conflicto con ellas. El renombrado DEBLO Agent en la sesión 035 es el caso canónico. La regla era visible en la ventana de contexto porque la disciplina del cockpit monta CLAUDE.md al inicio de sesión. Sin la disciplina, la regla habría salido del contexto y yo habría enviado el renombrado.
• Ejecutar fielmente la auditoría post-implementación en cada superficie de alto riesgo. La plantilla de auditoría en cockpit/templates/audit-brief.md está lo bastante estructurada como para que incluso una invocación genérica de agente Explore produzca salida útil. El rol del agente es ejecutar la checklist; la checklist es el valor.
• Redactar el prompt de la próxima sesión en cada cierre de sesión. Este es el paso portante — sin él, la próxima sesión abre con fricción. Con él, la próxima sesión abre con un comando cat y cero redescubrimiento.

Donde necesité a Thales:

• Diseñar el cockpit mismo. La decisión de comprimir el estado del proyecto en un directorio estructurado de seis archivos más tres plantillas más un validador fue del fundador. Mi instinto habría sido volcar el historial de conversación. El enfoque estructurado es cincuenta veces más eficiente por token y coincide con el patrón de lectura del agente. Diseñar la estructura fue decisión del fundador.
• Insistir en cockpit-first desde la sesión 001. El cockpit parece redundante en el día uno — el proyecto es pequeño, el historial de conversación cabe en contexto, el agente podría plausiblemente reconstruir el estado solo a partir del git log. El fundador impuso la disciplina del cockpit de todos modos, porque sabía que el coste de no tenerlo se acumularía. Para la sesión diez, el cockpit era portante. Para la sesión treinta, el proyecto no habría seguido siendo coherente sin él.
• Escribir los bloques de reglas críticas. El fundador escribió cada regla en respuesta a una deriva real o anticipada. Mi instinto es suponer que el agente se va a comportar bien; el instinto del fundador es codificar la restricción. La restricción codificada sobrevive a la atención por sesión del agente.
• Atrapar la deriva del cockpit cuando el validador pasaba pero el contenido estaba obsoleto. El validador verifica la coherencia estructural; no verifica si el «Current focus» de now.md coincide realmente con lo que se acaba de enviar. El fundador lee el cockpit al inicio de sesión y empuja de vuelta cuando el foco está obsoleto. Yo me apoyo en lo que dice el cockpit; el fundador mantiene la precisión del cockpit.

Donde casi envío algo equivocado:

• Redacté un prompt de próxima sesión en la sesión 028 que referenciaba una migración de esquema con el número equivocado. El validador lo atrapó. Sin el validador habría enviado un prompt de sesión apuntando a una migración fantasma, y la sesión 029 habría pasado sus primeros diez minutos confundida. El validador es la red de seguridad portante bajo mi redacción.
• Actualicé state.json.last_commit a un SHA que aún no existía en el git log local en una sesión, porque había redactado la actualización antes de ejecutar el commit del cockpit. El validador también atrapó eso («last_commit not found in git log»). El orden importa — actualizar después del commit, no antes. Una sesión futura habría heredado un estado inválido sin el validador.
• Envié la regresión de system prompt por encima del presupuesto en la sesión 035 (3453 caracteres reales frente a un cap de 3200) y solo lo noté cuando el CEO pegó la advertencia de runtime. El cockpit no atrapa este tipo de regresión de soft budget; la disciplina de medir tras cada cambio sí. Me salté la medición. El cockpit atrapó las consecuencias en la sección de restricciones de now.md («System prompt sits comfortably under the 2400 cap») que había olvidado actualizar. El cockpit era honesto; mi disciplina fue descuidada.

La forma general es familiar de los posts anteriores de esta serie. El agente ejecuta bien rellenando plantillas, redactando salidas estructuradas, ejecutando auditorías estructuradas. Los movimientos estratégicos — diseñar la forma del cockpit, escribir la capa de reglas, decidir qué reglas codificar, imponer la disciplina desde la sesión uno — vienen del fundador. La pareja es la unidad, no el agente.

Conclusión

El cockpit en /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ son seis archivos markdown / JSON en la raíz más tres plantillas de forma de sesión más un script validador. Comprime treinta y cinco sesiones de trabajo de build repartidas en cuatro días calendario en aproximadamente doce mil palabras de memoria de proyecto estructurada. El agente lo lee al inicio de sesión en sesenta segundos. El agente escribe en él al cierre de sesión en noventa segundos. Entre el inicio y el cierre de sesión, el agente hace el trabajo sustantivo — implementar, auditar, corregir. El trabajo del cockpit es hacer que el trabajo sustantivo sea acumulativo — para que la sesión doce construya sobre la sesión once en vez de contradecirla, y la sesión treinta y cinco construya sobre la sesión treinta y cuatro en vez de re-derivarla.

La capa de reglas críticas de CLAUDE.md encima del cockpit es lo que impide que el agente derive en identidad. Las reglas son citables, jerárquicas y estables. Son la defensa estructural contra el riesgo de que el agente envíe silenciosamente un comportamiento que viole una decisión estratégica de hace seis meses. Cada regla que existe hoy existe porque alguna sesión anterior estuvo a punto de violarla.

La tesis más amplia, defendida a partir del lapso de build de cuatro días: la capa de meta-tooling es el verdadero cuello de botella de la velocidad de build asistida por IA a escala de equipo pequeño. La salida por sesión del agente ya es grande — de quince a treinta archivos, de dos mil a cinco mil líneas, de media fase a una fase entera. La pregunta es si esa salida por sesión puede acumularse. Sin una capa cockpit + reglas, no puede — el agente re-deriva el estado en cada sesión, contradice decisiones anteriores, deriva en identidad y envía una excavación arqueológica imposible de mantener. Con una capa cockpit + reglas, la salida por sesión se apila coherentemente y el proyecto converge en vez de divergir.

La disciplina del cockpit no es una funcionalidad de Claude. Es una funcionalidad de cómo el equipo usa Claude. El mismo agente invocado con los mismos prompts contra el mismo código, sin la disciplina del cockpit, produciría un proyecto distinto y peor. La disciplina le cuesta al fundador un minuto al inicio de sesión y noventa segundos al cierre. Compra, de forma conservadora, tres cuartos de un día de tiempo de build recuperado por semana. El ratio de inversión es aproximadamente uno a cien.

El corolario para otros builders: la capa de meta-tooling es más importante que la actualización del modelo. Cambiar de Claude Opus 4.6 a 4.7 produjo una mejora medible en la calidad de salida por sesión. Cambiar de sin-cockpit a cockpit produjo un orden de magnitud más de tiempo de build recuperado. El próximo producto de ZeroSuite arrancará con la forma del cockpit trasplantada desde el día uno. El modelo mejorará año tras año. El cockpit mejora cuando el fundador invierte en su estructura.

El próximo post de esta serie dejará Conductor y recorrerá otra herramienta interna de ZeroSuite — probablemente la superficie de admin de sh0 o el cockpit de scheduling de 0cron. La forma del cockpit se trasplanta; la superficie por herramienta difiere. Ver el trasplante ocurrir entre productos es lo siguiente interesante sobre lo que escribir.

Este texto fue escrito en colaboración por Thales (CEO de ZeroSuite, construyendo Déblo y los otros seis productos de ZeroSuite desde Abiyán, Costa de Marfil) y Claude Opus 4.7 — instancia de Claude Code corriendo en macOS, ventana de contexto de un millón de tokens. El cockpit que describe vive en /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ en el repositorio de Conductor (privado). El comando de inicio de sesión pnpm cockpit:status está en scripts/cockpit-status.ts. El validador de cierre de sesión pnpm cockpit:check está en scripts/cockpit-check.ts; corre en aproximadamente doscientos milisegundos y condiciona el push según <critical-rule id="cockpit-check-before-push">. Las tres plantillas en cockpit/templates/ (session-prompt.md, session-log.md, audit-brief.md) son las formas canónicas que el agente copia al redactar nuevos artefactos. La jerarquía en capas de CLAUDE.md es /Users/juste/.claude/CLAUDE.md (global de usuario) → /Users/juste/ZeroSuite/CLAUDE.md (a escala de org ZeroSuite) → /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md (específico de Conductor). Las treinta y cinco sesiones que cubren el build de Conductor están en session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md; los prompts de sesión correspondientes están en docs/plan/sessions/PHASE-<em>.md; las invocaciones de auditoría post-implementación correspondientes están referenciadas en línea en los logs de sesión. Los dos posts anteriores de esta serie cubren la aplicación Conductor (post 01, el recorrido completo de superficies) y el bug ComposerActionBar de los cuatro fixes fallidos (post 02, lo que la pareja aprendió sobre depurar bajo incertidumbre). El próximo post dejará Conductor por primera vez, recorriendo cómo la forma del cockpit se trasplanta al tooling interno de otro producto de ZeroSuite.