La Antesala — enrutado de deliberación, guía de voz y archivo de informes

La Antesala — enrutado de deliberación, guía de voz y archivo de informes

Ajuste del harness cerrado en las sesiones 208-211 (8-9 julio 2026). Reúne cuatro piezas relacionadas del ecosistema de deliberación de CreaRack: cómo se decide qué herramienta usar ante una decisión de nivel (La Antesala), cómo escriben los informes que salen de ellas (guía de voz), dónde se guardan (el archivo de informes en el Workspace) y cómo se ven (el sistema de diseño Esferic, módulo kb). Ampliado el 27-07-2026 con el cierre por apuesta (wager ledger, §1b) y el 03-08-2026 con /plan-review en el menú.

1. La Antesala — elige cómo vas a pensar antes de decidir

Nombre de Edu (s207). Es la sala donde decides cómo vas a decidir, antes de entrar a decidir. Ante una decisión de nivel (movimiento de negocio o producto, cambio de precio o de línea, feature gorda, decisión de arquitectura, “¿construimos X?”), el agente no se lanza a la primera herramienta obvia: primero evalúa en 2-3 líneas qué herramienta de deliberación encaja —una, otra o varias encadenadas— y la propone a Edu con su recomendación primero.

Regla siempre cargada: CreaRack-Pro/.claude/rules/antesala.md (+ puntero en CLAUDE.md). No dispara en lo trivial, reversible u obvio (YAGNI); ahí se contesta directo.

El menú de herramientas:

Para un dato factual suelto no hay skill (no existe /deep-research — corregido en el os-audit del 26-07-2026): búsqueda web directa, y /method:storm solo si el dato resulta tener matiz.

Combinaciones potentes: storm → roast (investiga el terreno con fuentes y luego juzga la idea con esa evidencia — el flujo por defecto para una decisión de negocio con incógnitas de mercado) · divergir → grill · divergir → roast · grill → plan-review (afina el plan con Edu y, si es load-bearing —migraciones, maquinaria heredada, difícil de revertir—, pásalo por revisores fríos antes de construir).

/plan-review (añadida 03-08-2026, adaptada de ConnorGriffin/skills, MIT) cubre el hueco entre /grill (alinear el plan CON Edu) y /roast (idea de negocio): ataca un plan técnico ya escrito con revisores sin contexto del autor (“cold means cold”), rúbrica de exactamente 5 ejes (grounding verificado en código · aceptación observable · forma de la interfaz · presupuesto de scope · coste vs radio de explosión), terminación según lo que el plan se juega y tope duro de 3 paneles. Solo lectura: produce objeciones y veredicto, nunca arregla el plan.

1b. La apuesta — cómo se cierra una decisión (wager ledger, 27-07-2026)

Cherry-pick de starmynd-org/infinite-brain-os (evaluación 27-07-2026, ficha en memoria reference_infinite_brain_evaluation; el resto del repo NO se adoptó por redundante con nuestro método). Ya lo hacíamos sin nombre — el umbral pre-declarado del gate #202, el “test de 48h” del roast —; ahora es paso fijo de la regla antesala.md.

Una decisión de nivel no se cierra con el GO: se cierra con una apuesta pre-registrada en el ledger CreaRackSL-workspace/public/supercontext/WAGERS.md, escrita ANTES de conocer el resultado:

1. Qué esperamos que pase — métrica u observable concreto, no una sensación.
2. Contra qué baseline — el punto de comparación explícito.
3. Cuándo se evalúa — fecha o disparador concreto.
4. Veredicto al vencer — hit / miss / parcial, contra el dato real (log, query, resultado observable), nunca afirmado de memoria; + diagnóstico de una línea.

Disciplina del ledger: append-only (una apuesta no se edita; condiciones nuevas = superseded + apuesta nueva) · apuesta vencida al arrancar sesión → se evalúa antes de abrir tema nuevo · decisión sin métrica posible → se registra con no-medible y el porqué. Semilla del ledger: el gate #202 de la Barra de Integridad, retro-registrado (≥80% señal en red ajena → GO a F4; evalúa sept-oct 2026).

2. La guía de voz — cómo escriben los informes y los agentes

Corrección de Edu (s207-s208). Los informes de /roast y /storm tenían un contenido excelente pero una voz que chirriaba: sonaban a robot imitando a un colega de barrio, con jerga sin explicar, frases de eslogan y muletillas que podían ofender. La guía fija cómo debe sonar lo que escribimos.

Vive en claude-method/guides/VOZ.md (junto al GLOSSARY.md técnico). El norte: escribir como en el chat de la terminal cuando va bien —ameno, didáctico, como alguien sentado en la misma mesa—. Reglas principales:

• Fuera “en cristiano” (término religioso; Edu es agnóstico) — y sin sustituirlo por otra muletilla equivalente.
• Fuera “el dolor” (calco de pain point): problema, inconveniente, desventaja.
• Fuera los remates de eslogan y la sobre-condensación.
• Explicar la jerga la primera vez o usar la palabra llana. La guía trae ejemplos “antes → después” y un diccionario de traducción (foso → ventaja defendible, gemelo → copia digital viva del datacenter, sonda → programa que recoge datos, comoditizado → ya lo ofrece cualquiera…).

Aplicada al harness: el punto de tono de /roast (Paso 5) y /storm (Fase 3) apunta a la guía; los prompts de los subagentes piden ese tono (con la salvedad de que el control fuerte es la síntesis final, no la voz cruda del subagente). El “en cristiano” que estaba literal en ambos skills se eliminó. El veredicto de /plan-review cierra igual: en llano y con su sección “En sencillo”.

3. El archivo de informes — dónde se guardan (no en Artifacts)

Decisión de Edu (s209). Los informes de La Antesala ya no se publican como Artifacts de Claude (que viven en la cuenta de claude.ai de quien los genera y pueden perderse): se archivan en el Workspace, que es infra propia.

• Los HTML autocontenidos viven en public/informes/<tipo>/<slug>-<fecha>.html del repo CreaRackSL-workspace y se sirven estáticos por Cloudflare Pages.
• El manifest public/informes/index.json lista qué hay; lo actualizan los skills al archivar.
• La sección “Deliberaciones” (ruta /informes, en el menú Operaciones, desktop y mobile) los lista con tipo, título, fecha y veredicto, y enlaza a cada HTML.
• URL compartible: workspace.crearack.com/informes/... (nuestra, no depende de claude.ai).

Los skills /roast (Paso 5) y /storm (Salida) escriben el HTML ahí, actualizan el manifest y hacen push del workspace con add específico. Las encuestas de cliente (el “test de 48h”) se dejaron como pieza aparte (formulario cara al cliente, probablemente en Cloudflare), no forman parte de este archivo interno.

Nota de implementación (s209): los report-template de roast/storm se diseñaron para el wrapper de Artifact (roast sin <!DOCTYPE>/<head> propios; storm con webfonts externas). Al servirlos standalone desde CF Pages hay que añadir el skeleton HTML — conviene reflejarlo en los skills cuando se retoque.

4. El sistema de diseño Esferic — módulo kb (glosa + tema oscuro)

Estrenado en s209 con los informes; extendido a todo el Workspace en s211 (09-07-2026, PRs #145/#146/#147). Es el sistema de diseño central de Esferic Labs: tema siempre oscuro (decisión de Edu) + una “glosa” automática que subraya sutilmente los términos técnicos y muestra un globo con su significado al pasar el ratón o enfocarlos con el teclado.

Vive en public/_kb/ del workspace (promovido de public/informes/_kb/ en s211 — es el sistema central, no una pieza de los informes):

• kb.css — paleta oscura (near-black #0a0d12, azul de marca #2962ff, azul-tinta legible #6ea8ff) + estilos de la glosa. Los valores semánticos (verde/ámbar/rojo) son los MISMOS que los tokens de globals.css — los dos archivos se mantienen en sync a mano porque kb.css es autocontenido (lo cargan informes HTML estáticos que no pasan por Astro).
• kb.js — el motor: marca todas las apariciones de los términos del diccionario respetando enlaces, código, títulos y los <abbr data-kb> manuales (que ganan). Expone window.kbApply(el) para contenido que nace tarde (islas React con dangerouslySetInnerHTML).
• glossary.json — diccionario central (~141 términos). Añadir un término = una línea aquí.

Dónde está activo: informes de La Antesala (las plantillas de roast/storm apuntan a /_kb/) · todas las páginas de docs del workspace (wiki, guías, agentes — vía DocsLayout, escaneo acotado al artículo) · el “detalle técnico” del Worklog (vía kbApply; el resumen queda sin glosa a propósito — es texto React vivo y mutarlo rompería el timeline). Las páginas de docs usan además el fondo de lectura near-black --kb-bg, más cómodo que el negro puro para texto largo.

Consolidación s211 en el workspace: tokens tipográficos declarados de verdad (--font-heading Oswald, --font-mono JetBrains Mono, --text-2xl/3xl), anillo de foco de teclado global (:focus-visible), un solo juego de colores semánticos, y el tema claro/auto RETIRADO (~200 líneas; data-theme solo admite dark; las preferencias guardadas migran solas). Detalle operativo de los tokens: [[runbook—workspace—design-tokens-migration]].

Política de anglicismos (VOZ.md): se traduce si la forma española es natural; se mantiene en inglés + globo si suena forzada (cloud, on-premise, appliance…). Aplica al texto, no solo al globo.

Véase también

• [[ia-tech—metodo—claude-method-guide]]
• [[ia-tech—metodo—fable-handover]]
• [[ia-tech—metodo—glossary]]
• [[runbook—workspace—design-tokens-migration]]