Texto del ADR

Leído de docs/decisions/dec-0086-development-sequence-regla-dura.md, el fichero canónico.

Development sequence regla duraCopiar enlace

Development sequence regla dura: cliente valida primero sobre dev image reproducible; Buildroot NO bloquea P1/P2/P3; StyxOS integra cliente ya funcional; gates separados (no gate combinado)

Por qué pasa gate-3Copiar enlace

• Hard-to-reverse: El dep-graph styx.model.yml ya codifica esta secuencia: F-APPLIANCE-OS dependsOn [F-APPLIANCE-PI3.P3, F-IDENTITY]. Cambiarla requeriría reestructurar el graph, re-definir P3 como 'requiere Buildroot' y revertir la regla 'Buildroot NO bloquea'. O0 (dev image) precede O1 (Buildroot product image)
• Surprising sin contexto: Un ingeniero viendo 'F-APPLIANCE-PI3' y 'F-APPLIANCE-OS' en el spec podría asumir que son fases paralelas o que el OS es prerequisito del cliente. La regla 'Buildroot NO bloquea P1/P2/P3' es counter-intuitive sin contexto - Buildroot es parte de appliance, pero explícitamente NO es gate para P1/P2/P3
• Trade-off real: Trade-off visible: 'fuerza a resolver distribución + actualización ANTES de validar el cliente (alto riesgo de propagar bugs OTA antes de saber que el cliente funciona)'. Alternativa rechazada = gates combinados cliente+OS simultáneo (con coste: OTA bugs bloquearían P1/P2/P3). R-D7.1/R-D7.2 mitigan el riesgo al permitir que cliente corra sobre dev image mientras OS madura

ProcedenciaCopiar enlace

Split de docs/decisions/r59-appliance-client-os-separation-2026-07-15.md (lock D7.2) durante PASO 7 (2026-07-16). Ver el fichero padre para el contexto completo del pack original.