dec-0063

Vista generada de dec-0063: Styx implementa Web Player y Web Engine first-party; ninguna runtime externa (Shaka/RxPlayer/Vidstack/Limeplay/Media Chrome/Video.js) es foundation del engine.

ImplementadoSin versión del tren todavía· generada desde docs/decisions/dec-0063-styx-implementa-web-player-web.md
track/docsdec-0124track/docs:DC10

Vista generada desde docs/decisions/dec-0063-styx-implementa-web-player-web.md. No se edita a mano: bun run docs:gen la regenera y bun run docs:check falla si difiere. El estado aquí es el del model: si discrepa con otra página, manda el model.

CampoValor
EstadoLOCKED (migrado de un rNN por gate-3: el fichero no declara estado)
Referencia legadaD1-web-player-engine-first-party
Ficherodocs/decisions/dec-0063-styx-implementa-web-player-web.md

Por qué importa (del frontmatter del ADR):

TKT-039 (F-WEB-PLAYER-ENGINE.W0) abre citando literalmente 'r53 lockea Web Player/Engine first-party'; roadmap.spec.yml F-WEB-PLAYER-ENGINE.ref incluye r53; styx.model.yml linea 502 lo registra locked, extendido por r54-r60; README §9 lo documenta como cabeza del paquete r53-r59.

Nodos del roadmap que lo citan en refs: ninguno.

Páginas de la documentación que lo citan: ninguna todavía.

Texto del ADR

Leído de docs/decisions/dec-0063-styx-implementa-web-player-web.md, el fichero canónico.

Styx implementa Web Player y Web Engine first-party; ninguna runtime externa (Shaka/RxPlayer/Vidstack/Limeplay/Media Chrome/Video.js) es foundation del engine.

Styx implementa Web Player y Web Engine first-party; ninguna runtime externa (Shaka/RxPlayer/Vidstack/Limeplay/Media Chrome/Video.js) es foundation del engine.

Por qué pasa gate-3

  • Hard-to-reverse: Revertir requeriría descartar inversión en Engine first-party y migrar a runtime externo (Vidstack/Limeplay/Shaka/RxPlayer), lo cual impone reescribir state machine, buffer policy, seek lifecycle, track/quality control, generation enforcement, recovery y metrics - toda la capa de ownership que el ADR define como responsabilidad Styx
  • Surprising sin contexto: Un ingeniero competente leyendo la codebase NO inferiría que Styx rechaza adoptar Vidstack, Limeplay, Shaka, RxPlayer, Media Chrome o Video.js como foundation, sin leer este ADR - la default assumption en la industria es adoptar alguno de esos runtimes consolidados en vez de implementar Engine first-party
  • Trade-off real: Se rechazó explícitamente la alternativa de adoptar Shaka/RxPlayer como runtime central (Rejected alternatives §85-86), lo cual implica aceptar el coste de desarrollo de Engine first-party a cambio de preservar autoridad completa sobre state machine, buffer policy, seek lifecycle, track/quality control, generation enforcement, recovery y metrics - sin scheduler multimedia externo compitiendo con ByteRuntime

Procedencia

Split de docs/decisions/r53-web-player-ownership-2026-07-15.md (lock D1-web-player-engine-first-party) durante PASO 7 (2026-07-16). Ver el fichero padre para el contexto completo del pack original.

dec-0062

Vista generada de dec-0062: r52 — Eden Treaty App type: runtime-first (bypass de contract-first)

dec-0064

Vista generada de dec-0064: MediaBunny es la única dependencia multimedia de alto nivel inicial; ownership matrix delega parsing/demux/sample-access/container-transformation SOLO a ella.

Texto del ADR
Styx implementa Web Player y Web Engine first-party; ninguna runtime externa (Shaka/RxPlayer/Vidstack/Limeplay/Media Chrome/Video.js) es foundation del engine.
Por qué pasa gate-3
Procedencia