Texto del ADR

Leído de docs/decisions/dec-0133-entidad-release-en-el-modelo.md, el fichero canónico.

dec-0133 — Entidad release en el modelo del roadmap: releases: ordenado por dependencias, publicado por su definition of doneCopiar enlace

• Fecha: 2026-10-02
• Estado: LOCKED (2026-10-03). waxin, vía AskUserQuestion, lockea el ADR y fija la identidad de versión de los alfas: 0.0.0-alpha.N (alpha.1 = 0.0.0-alpha.1 es el MVP); el primer v0.y.z se corta más adelante. P3 queda resuelta (el sitio de docs es privado por la red de Tailscale), P7 se decide al llegar, según coste, y P5 y P6 quedan diferidas de forma explícita. Todo está en Lock (2026-10-03, waxin). Donde §1–§7 y el lock difieren, gana el lock.
• Enmienda: dec-0123 D1 y D5 (§4). dec-0123 se lockea el mismo día con la enmienda a D1; la de D5 sigue pendiente de P5.
• Nodo: track/release-engineering, milestone track/release-engineering/release-entity (ticket #28, gate item RE17).
• Insumos: decisiones de waxin del 2026-10-01 y 2026-10-02 apuntadas en .claude/workflows/archive/orquestacion-2026-10/decisiones-pendientes.md (rama ops/orquestacion), puntos 2, 4, 6, 10, 11, 12, 13 y 19; y la orden de waxin del 2026-10-02: "pon como primera crear ya la app coolify y ir desplegando de momento la docu".

1. ContextoCopiar enlace

waxin pidió (punto 6) una entidad nueva en el model, release o versión, muy atada al roadmap:

• sin días, fechas ni estimaciones: sólo orden y dependencias, para saber cuándo empieza cada cosa;
• una sesión de axon tiene que mostrar lo abierto y lo que depende de qué;
• al sacar la alfa se decide con waxin qué ADRs y nodos entran en v0.2, beta o lo que siga;
• el gate de paso, la definition of done, es lo que dispara publicar.

Además:

• el primer MVP es la primera vertical VOD web e2e (punto 2), y con él empieza el modo serio: versionar y desplegar en el VPS de waxin con Coolify (punto 4);
• antes del MVP hay alfas previas; hasta estar listos la versión es 0.0.0 en estado alfa, indefinida; las nightly son builds de desarrollo marcadas clean o dirty; las releases son normalmente sólo stable; beta opcional como checkpoint; dos canales, nightly y stable (punto 13, que ya recoge la enmienda del 2026-10-02 de dec-0123);
• alpha.0 es privado hasta que la AppSec salga seca (punto 13);
• el contenido de alpha.0, alpha.1 y alpha.2 está en los puntos 11, 12 y 19;
• styx define la entidad y se sube a axon (punto 13), que la adopta como herramienta;
• la documentación como contrato se enlaza con los releases más adelante (punto 10);
• el 2026-10-02 waxin pone como primer paso de todo el camino crear la aplicación de Coolify y desplegar ya el sitio de documentación.

axon 0.3.0 no conoce la entidad. Su esquema arktype conserva las claves top-level no declaradas, así que un bloque releases: no rompe axon gen ni axon en general, pero tampoco lo valida ni lo pinta.

2. DecisiónCopiar enlace

D1 — La entidadCopiar enlace

Una lista top-level releases: en styx.model.yml, detrás de experiments:. Cada entrada:

Prohibido cualquier campo o valor con forma de fecha, plazo, ETA, duración, semana o sprint. updatedAt sigue siendo la única fecha del model y vive fuera de releases:.

D2 — SemánticaCopiar enlace

• published exige: todos los items del DoD en pass (el verdict es proyección del manifest, así que la separación autor ≠ verificador llega por GUARD 6), dodComplete: true, version no nula, cada requiresLocks locked en decisions: y cada release de dependsOn ya published.
• visibility: public exige todos los items de publicWhen en pass.
• El orden de releases concuerda con el DAG: un nodo de un release no depende, ni de forma transitiva, de un nodo que entra por primera vez en un release posterior. Depender de un nodo es depender de él y de todos sus descendientes, y un item del DoD (o de publicWhen) arrastra las aristas del nodo que lo declara aunque sólo entren sus milestones.
• Cada item del DoD y de publicWhen es de un nodo que entra en ese release o antes (él, un ancestro o un descendiente), o de un nodo ya done.
• Un nodo entra en un solo release (ni en dos, ni con un ancestro en otro).
• candidate y posteriores exigen dodComplete: true.

Lo valida scripts/check-releases.ts (bun run check:releases, dentro de check:roadmap; las dos reglas anteriores son R7 y R10, ampliadas el 2026-10-02 tras el panel de escépticos), con un mutante rojo por regla en test/check-releases.test.ts. Avisa, sin poner el guard en rojo, de las dependencias abiertas de un nodo incluido que ningún release incluye.

D3 — Política de versiones del trenCopiar enlace

• El punto 13 habla de las "alfas previas al MVP": es alpha.0, el esqueleto desplegado. alpha.1 es el MVP (punto 11), y también es una alfa.
• La nightly es la build de desarrollo, marcada clean o dirty. No es una entrada de releases:: es el canal por el que viajan los alpha mientras no hay versión cortada.
• Normalmente sólo se cortan stable; beta es un checkpoint opcional (punto 13).
• Propuesta, no decidida por waxin (§7, P5): un alpha o beta con channel: stable pasa por el pipeline de stable pero no mueve styx-release:stable.
• Tras alpha.1 se decide con waxin qué entra en v0.2, beta o lo que siga (punto 6). Este ADR no lo adelanta: alpha.2 recoge sólo lo que waxin ya puso detrás del MVP (puntos 12 y 19).
• Versión de los alfas (lock, P1): 0.0.0-alpha.N, con la N de su id: alpha.0 = 0.0.0-alpha.0, alpha.1 = 0.0.0-alpha.1 (el MVP), alpha.2 = 0.0.0-alpha.2. El primer v0.y.z lo corta waxin más adelante.

D4 — Docs enlazadas (propuesta para cuando waxin lo decida; milestone track/docs/available-from)Copiar enlace

El punto 10 enlaza releases y docs "cuando se decida". Esto es la forma que tendría, sin gate item: el track/docs:DC11 que se le dio el 2026-10-02 se retiró ese mismo día.

• Campo availableFrom: vX.Y.Z en el frontmatter de contrato de dec-0124 (el nombre del punto 10), derivado del model, nunca escrito a mano: la versión del primer release cuyo includes contiene un nodo que la página cita, o un ancestro suyo.
• Una página no implementada muestra "No implementado — disponible a partir de vX.Y.Z"; si su nodo no está en ningún release, "sin versión asignada". Mientras el release tenga version: null, qué se muestra es la pregunta P6 de §7.
• Guard: si un release se publica sin que una página de sus nodos esté como mínimo en implementado, falla.

D5 — Dónde vive y cómo sube a axonCopiar enlace

• El guard (scripts/check-releases.ts) y la vista (scripts/docs/gen-roadmap-adrs.ts escribe apps/docs/content/docs/roadmap/releases.mdx) viven en styx.
• El esquema en axon ('releases?': 'Release[]' y su pintado en axon gen) es el diferido d24. No hace falta tocar axon para aterrizar esto: la clave pasa sin error.

3. Los releases de hoyCopiar enlace

El bloque vive en styx.model.yml y su vista en roadmap/releases. Resumen:

• alpha.0, esqueleto desplegado, privado, in_progress. Primero, por orden de waxin del 2026-10-02, la aplicación Coolify del sitio de docs (track/release-engineering/coolify-docs, ticket #26, item RE13). Después la entidad release (RE17), la identidad de versión (RE1), el CLI y los runtimes, Coolify como tier 1 operable (RE15) y la nightly privada de master en Coolify (RE14). Pasa a público con RE16, la AppSec seca.
• alpha.1, el MVP, privado, planned, depende de alpha.0. La primera vertical VOD web sobre la biblioteca real, local y del Storage Box: DM4 primero (lo exige dec-0132), el origen TCP del daemon, las olas A, B y D, ME7 (audio transcodificado), el fichero como fuente de verdad y los metadatos incrustados, invitaciones, CLI con device grant, API keys y quick connect, styx doctor, métricas por sesión, páginas de contrato y la AppSec seca. Desde la corrección del 2026-10-02 también incluye los dos nodos de AppSec (track/byte-runtime/sec y track/identity/sec) y track/plugin-seams/w1, y su DoD cubre el login passwordless (I1..I5), los prerequisitos de FV1 (ME3, ME4, ME5, S6), DM2, la medida del Storage Box (RM1) y la promoción a stable (RE8). Exige los locks de dec-0133, dec-0123, dec-0113 y dec-0124.
• alpha.2, post-MVP inmediato, planned, depende de alpha.1. Runtimes medidos (lane E), cuentas, hogares y perfiles, dispositivos A0 (punto 19: justo después del MVP) y el resto de la ola C. dodComplete: false: los items de track/devices los redacta su ticket #01.

Fuera del alfa, de forma explícita: cast, handoff, federación, modo público, player propio y transcodificación de vídeo (no tiene nodo propio; es una parte de track/media-engine/download-output, que se excluye). La campaña de la ola E no está asignada.

4. Enmienda a dec-0123Copiar enlace

• D1: "el primer v0.y.z lo corta waxin". Hasta entonces el tren es 0.0.0 en estado alfa y los checkpoints previos son los alfas 0.0.0-alpha.N (lock, P1). Las versiones de componente (deploy/VERSION y el package.json de cada componente Bun, en 0.0.0 desde el lock) son marcadores congelados hasta ese corte. Las de los componentes Zig (build.zig.zon y native/zig/cli/VERSION, todavía en 0.1.0) se alinean en un cambio aparte.
• D5 (propuesta, pendiente de P5): un alpha o beta con channel: stable recorre el pipeline de stable (gates de release, aprobación) pero no mueve el puntero styx-release:stable. No hay tercer canal (esto sí es del punto 13).

5. DescartadoCopiar enlace

• Fechas o "objetivos" en el release. Lo prohíbe el punto 6 y lo prohíbe la gobernanza del repo (r31, product-vs-roadmap).
• Status in_progress en los tickets para lo implementado sin verificar: statusProvenance ya cubre ese caso.
• Release como fase del DAG. Un release agrupa nodos y se ordena por sus propias dependencias; no es un nodo (el kind phase está prohibido, r31).
• DoD en prosa. Sólo gate items: el pass es mecánico y el verificador es otro.
• Extender axon antes. La clave pasa; el guard styx basta hasta d24.

6. ConsecuenciasCopiar enlace

• check:roadmap corre check:releases en cada cambio del model.
• Cada nodo nuevo de un release necesita página a mano que lo cite (cov-node) y cada item del DoD, una cita (cov-gate); la vista generada roadmap/releases cita los del DoD y publicWhen.
• Un release no se publica por calendario ni por intuición: hace falta el pass de su DoD, sus locks y sus predecesores.

7. Preguntas para waxinCopiar enlace

Estado tras el lock del 2026-10-03: P1, P2, P3 y P4 resueltas; P7 se decide al llegar; P5 y P6 diferidas. El detalle está en el lock.

Lock (2026-10-03, waxin)Copiar enlace

Decisión de waxin vía AskUserQuestion (2026-10-03), apuntada en el §33 de .claude/workflows/archive/orquestacion-2026-10/decisiones-pendientes.md (rama ops/orquestacion):

1. Se lockea este ADR: la entidad releases: (D1), su semántica (D2), la política de versiones del tren (D3, salvo la parte de canal de P5) y dónde vive (D5). D4 sigue siendo propuesta «para cuando se decida» (punto 10).

2. Identidad de versión de los alfas (P1): 0.0.0-alpha.N, con la N del id del release.

   • alpha.0 = 0.0.0-alpha.0 (esqueleto desplegado);
   • alpha.1 = 0.0.0-alpha.1 (el MVP);
   • alpha.2 = 0.0.0-alpha.2 (post-MVP inmediato).

   El primer v0.y.z lo corta waxin más adelante. releases: del model lleva ya esas versiones con status: planned o in_progress: tener versión no publica nada (R5 sigue exigiendo el DoD en pass, los locks y los predecesores).

3. Componentes en 0.0.0. deploy/VERSION y el package.json de cada componente Bun pasan a 0.0.0, la versión del tren en estado alfa. Los componentes Zig se alinean en un cambio aparte.

4. Privacidad del sitio de docs (P3): la da el dominio. docs.vpn.<dominio> activa el hook de Coolify de waxin que limita el acceso a Tailscale. La basic auth de deploy/coolify/docs.compose.yml deja de ser obligatoria y queda como opción.

5. DM1 y DM3 frente al MVP (P7): «a decidir en el momento viendo lo que nos costaría». No se decide ahora; alpha.1 no cambia.

6. Diferidas de forma explícita: P5 (semántica de canal de los alfas por stable) y P6 (con D4).

7. Enmienda a dec-0123 (§4): entra en vigor la de D1. dec-0123 se lockea el mismo día con sus enmiendas del 2026-10-02; la de D5 queda pendiente de P5.