De desarrollar a publicar, paso a paso, con la página que manda en cada uno; preparar el nodo, probar, versionar, construir, publicar nightly y stable, instalar y actualizar.
Especificado. Esta página es un mapa: cada paso remite a la página que lo explica. Los pasos de desarrollo y de comprobación son código que ya existe. Los de versión, release e instalación siguen
dec-0123, LOCKED. Sus scripts, sus workflows y el CLIstyxestán en el repositorio, pero todavía no hay un canal publicado ni un tag de tren.
dec-0123LOCKED (waxin, 2026-10-03) con su enmienda del 2026-10-02. Coolify es tier 1 con plantilla propia, junto a systemd nativo, Podman Quadlet y Docker Compose. El tren es0.0.0en estado alfa hasta que se corte el primerv0.y.z: los alfas son0.0.0-alpha.N(dec-0133), las nightly son builds de desarrollo marcadas clean o dirty, sólo hay canalesnightlyystable, y beta es un checkpoint opcional. El orden de trabajo lo dan los releases, que empiezan por la aplicación de Coolify del sitio de docs.
Cada build lleva su tren dentro (GET /version, --version, styx-release.json y la etiqueta
dev.styx.train de la imagen): un corte es X.Y.Z o 0.0.0-alpha.N; una nightly de CI,
<base>.<YYYYMMDD>.<run>+g<sha12>.clean; un build local, <base>+g<sha12>.clean o .dirty. La
forma exacta y por qué ordena bien está en docs/governance/release-engineering.md §1.2.
| Paso | Qué se hace | Orden principal | Dónde está explicado |
|---|---|---|---|
| 1. Preparar el nodo | Clonar styx y sus SDK, el Bun exacto, dependencias, submódulo QUIC, doctor | sh scripts/dev/bootstrap.sh, después bun scripts/dev/setup.ts verify | Puesta en marcha de un nodo |
| 2. Desarrollar | Infraestructura de dev, streams del bus, servicios, web | bun scripts/dev/setup.ts infra up | La pila en local |
| 3. Comprobar | Tipos, lint, tests TS, tests del CLI, data plane, guardas | bun run typecheck, lint, test, bun run --cwd apps/cli test, zig build test | Empezar a contribuir, guardas |
| 4. Versionar | Commits en Conventional Commits con trailers; el nivel de cada componente se calcula. Un alfa (0.0.0-alpha.N) se prepara sin tocar las versiones de componente | bun run release:plan, bun run release:version (alfa: -- --prerelease alpha) | docs/governance/release-engineering.md §1-§3.1 |
| 5. Construir | Un binario por componente y arquitectura, la imagen OCI derivada, el manifiesto styx-release.json y su smoke | bun run release:build, release:oci-verify, release:manifest, release:smoke | docs/governance/release-engineering.md §3.2 |
| 6. Publicar | Canal nightly (automático) y stable (tag del tren, promoción por digest sin recompilar) | nightly.yml, release.yml, ambos sobre release-build.yml | docs/governance/release-engineering.md §3.3-§3.4 |
| 7. Instalar | Un comando por runtime de tier 1: systemd nativo, Podman Quadlet, Docker Compose y Coolify (plantilla propia pendiente, #24); NAS con styx render | install.sh, styx install | Instalar y deploy/INSTALL.md |
| 8. Actualizar y revertir | Transacción con copia previa y vuelta atrás | styx update, styx rollback, styx backup | Actualizar y versiones y deploy/INSTALL.md |
La referencia de cada orden, opción y código de error del CLI se genera del código en
apps/cli/REFERENCE.md; qué hacer cuando algo falla está en deploy/RUNBOOK.md.
| Workflow | Se dispara con | Qué hace |
|---|---|---|
guard.yml | push y pull request a master | guardas, typecheck, lint, tests de la raíz y del CLI, imágenes de los servicios, referencia y sitio de docs, Zig y TSAN |
nightly.yml | cron diario sobre master (y a mano) | construye un candidato si master cambió, pasa los gates nightly por runtime y mueve el canal nightly |
release.yml | un tag v* | gates de stable sobre el candidato ya construido, promoción por digest y release de GitHub |
release-build.yml | sólo lo llaman nightly.yml y release.yml | el único que construye, firma y publica |
retention.yml | cron semanal (y a mano; borrar exige lanzarlo a mano) | plan de retención de nightly y candidatos |
Todos parten de master o de un tag. Una rama que no es master no pasa por CI hasta su pull
request a master; mientras tanto, las comprobaciones se corren a mano con los comandos del paso 3
y las guardas de guardas. Algunas guardas no tienen paso propio y corren dentro de
los tests: check:deploy en bun run test y check:deploy-render en bun run --cwd apps/cli test. check:infra-live mira los contenedores en marcha y es operativa: no corre en CI.