Texto del ADR

Leído de docs/decisions/dec-0085-split-f-appliance-pi3-producto-cliente-vs.md, el fichero canónico.

Split F-APPLIANCE-PI3 (producto cliente) vs F-APPLIANCE-OS (lifecycle sistema)Copiar enlace

Split F-APPLIANCE-PI3 (producto cliente) vs F-APPLIANCE-OS (lifecycle sistema): cada concern tiene dueño distinto (r17 microservicios split-duro precedented)

Por qué pasa gate-3Copiar enlace

• Hard-to-reverse: F-APPLIANCE-PI3 (P0-P6) y F-APPLIANCE-OS (O0-O4) ya están definidas como tracks separados en styx.model.yml con sus propias sub-fases y gates. Revertir requeriría colapsar la estructura de fases, el dep-graph (F-APPLIANCE-OS dependsOn [F-APPLIANCE-PI3.P3, F-IDENTITY]) y re-asignar ownerships de 24 concerns (tabla D7.1)
• Surprising sin contexto: Un ingeniero viendo F-APPLIANCE-PI3 y F-APPLIANCE-OS como tracks separados en el spec NO inferiría automáticamente que tienen dueños distintos ni que Buildroot/OTA/watchdog NO bloquean P1/P2/P3. La tabla D7.1 (24 concerns repartidos) es non-obvious sin el ADR - parece un detalle de implementación, no un boundary arquitectónico
• Trade-off real: Trade-off explícito en Contexto: 'síntesis anterior incluía Buildroot, OTA, watchdog, recovery, rendering QML, GStreamer e input en una sola fase Pi 3. Esto fuerza a resolver distribución + actualización ANTES de validar el cliente (alto riesgo de propagar bugs OTA)'. Alternativa rechazada = fase monolítica única (con coste visible: mezcla ownership producto vs sistema, gates bloqueados por OTA antes de validar producto)

ProcedenciaCopiar enlace

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