Texto del ADR

Leído de docs/decisions/dec-0099-pausa-styx-axon-foundation.md, el fichero canónico.

dec-0099 — Pausa de Styx para la fundación de AxonCopiar enlace

⚠️ SUPERSEDED por dec-0102 (2026-08-27). El freeze scope=all de este ADR queda levantado — waxin: "lo pusimos muy literal ese freeze cuando es algo visual, podemos dejarlo abierto eso". La parte visual del criterio de salida (cockpit) pasa a no-bloqueante en vez de condición de salida. Detalle en dec-0102.

• Fecha: 2026-07-17
• Estado: LOCKED → SUPERSEDED (ver dec-0102)
• Decisor: waxin (AskUserQuestion ×3, tras review externa de los 3 repos)
• Plan de ejecución: docs/governance/axon-cli/PLAN.md
• Evidencia: docs/reviews/agentics-axon-workspaces/respuestas-consolidacion-2026-07-17.md

Qué se decideCopiar enlace

Styx se pausa —producto entero, no una fase— hasta que Axon exista como herramienta usable. El parón tiene criterio de salida explícito y verificable (abajo). Cuando se cumple, Styx vuelve a prioridad absoluta.

Por qué no es un cambio de prioridad de productoCopiar enlace

Es eliminar un cuello de botella de la infraestructura de desarrollo del ecosistema. La distinción es load-bearing: si fuera un cambio de prioridad, competiría con Styx y habría que justificar por qué Axon vale más que el producto. No compite: Axon es cómo se construye Styx.

Tres hechos lo sostienen:

1. Styx entra en su fase de más artefactos. Foundation está cerrada (r47). Lo que viene —UI, plugin system, playback, sources, sessions, integraciones, workers— genera cientos de tickets, planes, sesiones y commits. Arrancarlo con el workflow actual es deuda operativa compuesta.
2. El problema es de representación, no de arquitectura. La cadena real de trabajo —decision → track → ticket → plan → exec → commits → sessions— existe repartida entre 8 formatos: markdown, yaml, git, jsonl, taskwarrior, handoffs, commits, roadmap. Eso no se sostiene en memoria humana, y hoy se compensa a base de grep y de sesiones de arqueología.
3. Axon ya no es una idea. Tiene modelo canónico v2, ids derivables, DAG, guards, task-sync, commit integration y ADRs. Está disperso, no ausente.

⚠️ Lo que este ADR NO acepta: «el coste marginal es pequeño»Copiar enlace

La review externa argumentó que "ya tienes task-sync, parser, governance, ids, DAG, guards, modelo v2, commit wizard — falta unirlos". Verificado 2026-07-17: es falso. No es integración, es construcción:

Esto no invalida la decisión — invalida la tranquilidad. El parón se sigue defendiendo por los 3 hechos de arriba. Pero como el coste es mayor de lo que parecía, el criterio de salida no es opcional: es la única cosa que impide que este parón se coma el producto.

Criterio de salida (LOCKED — la condición que termina el parón)Copiar enlace

Cuando pueda abrir axon status y saber qué hice ayer, qué toca hoy, qué agentes trabajaron, qué tickets siguen abiertos, y navegar visualmente el roadmap sin abrir Markdown — el parón termina y Styx vuelve a ser prioridad absoluta.

El benchmark que lo hace concreto: «si cierro el portátil un mes, al volver entiendo Styx en diez minutos.»

Este criterio incluye la UI a propósito (navegar visualmente el roadmap) — es coherente con que el cockpit entre en el alcance (abajo). Sin esa cláusula el criterio se cumpliría con una CLI y el problema de representación seguiría intacto.

Alcance: qué entra y qué NOCopiar enlace

Entra (detalle y orden en el PLAN):

NO entra — explícitamente:

• ❌ Una app web nueva para el cockpit. Va dentro de gateway-web, que ya existe.
• ❌ El split de Mission Control (mks-git-client), pese a estar LOCKED desde 2026-04-27 y parado en el umbral de su gate 4.
• ❌ Retomar mks-workspaces, pese a tener la gobernanza podrida (3 fases declaradas contradictorias, 53 días fuera de la realidad).
• ❌ Trabajo de producto de Styx de cualquier tipo.
• ❌ A2A más allá de F2 + guard rails: F3 reliability, F5, F6 security quedan fuera.
• ❌ Cualquier "ya que estamos" sobre los 3 repos. La review de 2026-07-17 dejó una lista larga de cosas rotas y verificadas (dep fantasma ×2, 7757 LOC de rama muerta, mapPriorityToQueue muerto, inbox con evicción silenciosa, /admin/* legacy, better-auth zombi…). Ninguna entra. Se arreglan solo si M0/M1/M2 tropiezan con ellas.

Enmiendas a locks previos que esta decisión arrastraCopiar enlace

Los tres se lockearon el mismo día y viven en docs/governance/axon-cli/ARCHITECTURE.md:

• L1 REVERTIDO — axon-core va a un repo nuevo, no a mks-agentics/core/packages/. El argumento de L1 («ahí están las piezas y los consumidores») era falso: task-sync tiene 0 consumidores y 0 imports de agentics (su @mks-agentics/gateway-protocol es dep fantasma).
• L2 REVERTIDO — task-sync se queda en agentics, se publica y se importa. Ya no es cantera: es dependencia. Razón: su consumidor real es el cockpit (gateway-web), que vive ahí.
• L8 (nuevo) — el orden del carril, con A2A en el paso 5. Esto rechaza explícitamente la recomendación externa de «A2A solo si Axon lo necesita, y volver inmediatamente a Styx»: el trabajo está especificado (ADR-0018 F2), cuesta ~4h de LLM, y lleva 3 semanas parado a mitad de un debug. Dejarlo otras N semanas es deuda, no foco.

ConsecuenciasCopiar enlace

Positivas

• El trabajo de Styx que viene (el de más volumen de artefactos) arranca con la herramienta puesta.
• El criterio de salida es verificable por un comando + una vista, no por opinión.
• El cockpit no crea repo ni app nueva: reutiliza gateway-web y justifica que task-sync se quede.

Negativas / costes asumidos

• styx.model.yml describirá un roadmap que nadie ejecuta mientras dure el parón. Es la razón de ser de este ADR: sin él, el modelo miente por omisión — exactamente el fallo que mks-agentics/docs/jarvis/adr/unified-governance/0023-call-sites-como-unica-evidencia.md documenta en mks-workspaces (spec y ROADMAP coincidiendo, 53 días fuera de la realidad).
• El cockpit aterriza en la app menos cubierta del ecosistema: gateway-web son 50697 LOC con 3 tests, y arrastra fixtures que importan @mks-agentics/harness-core, un paquete inexistente desde el rename. Más barato que una app nueva —por eso se elige— pero no es greenfield.
• A2A sigue congelado hasta el paso 5, y lleva parado desde 2026-06-27 a mitad de un debug.
• Los 2 bugs de task-sync (el process.exit top-level que cuelga la suite, y propagateTwStatus metiendo status como UDA) ya no se arreglan «de paso»: L2 los arreglaba al extraer, y no hay extracción. Necesitan arreglo propio.

Riesgo principal, nombrado

Que Axon se coma indefinidamente el tiempo del producto. El único mecanismo de control es el criterio de salida, y su cláusula más débil es la de la UI: «navegar visualmente el roadmap» admite interpretaciones de una tarde y de dos meses. El PLAN acota qué cuenta como suficiente — si esa acotación se relaja, este ADR pierde su guard rail y hay que revisarlo, no estirarlo en silencio.