# PLAN — `Background`: el anfitrión de capas de fondo del canon (estudio + plan) > **Estado: DECISIONES D-BG.1–11 y D-BG.13–15 FIRMADAS 2026-08-17 (D-BG.12 > superada por la 14) — NADA CONSTRUIDO.** Falta que el autor nombre la rama de > trabajo (§10.1) y ordene el arranque del agente (F0). El estudio original, > abajo, se conserva íntegro. > > ~~Estado: ESTUDIO ENTREGADO 2026-08-17 — NADA CONSTRUIDO, NADA FIRMADO.~~ > Este documento responde a la pregunta «¿conviene un componente `Background` > rico, composable desde el resto del framework, a la altura o por encima de lo > que hay hoy (parallax, capas, vídeo, patrones, scrim…)?». Contiene el > veredicto razonado, la comparativa con las referencias, el inventario de lo > que YA existe en el framework, la forma canónica propuesta, las decisiones > que sólo el autor puede firmar (§6, D-BG) y el plan por fases con sus gates > (§7). Es un documento de proceso: no es doctrina hasta que el autor firma. > > **Kickoff para sesión nueva**: _«Lee `docs/process/PLAN-background.md`; si > las D-BG de §6 están firmadas, ejecuta la fase que toque; si no, PARA y > preséntalas una a una.»_ Cada fase lista qué leer, qué producir y con qué > guard se verifica. > > **Enmiendas de la sesión 2026-08-17 (conversación con el autor, tras el > estudio)** — mandan sobre cualquier frase anterior de este documento: > > 1. **`Background` NO compone `Box` ni es una caja de flujo.** Es la PILA DE > CAPAS que el padre renderiza como hijo (`position:absolute; inset:0; > z-index:-1; border-radius: inherit; overflow: clip` en la propia pila). Un > solo modo de colocación; el layout sigue siendo de `Box`/`Section`/`Card` > («one axis, one primitive»). D-BG.12 queda superada por D-BG.14. > 2. **El padre se convierte en anfitrión sin tocarlo**: una regla de foundation > `:where(:has(> [data-background])) { position: relative; isolation: isolate }` > (`:has()` ya se usa 71 veces en eidos; `:where` deja ganar al `position` de > cualquier recipe). El bloque `data-on` gana el mismo gemelo `:has`. > 3. **Cero props nuevas en `Box`** (Box es layout-only por doctrina; el > tratamiento vive en primitivas aparte — Surface es el precedente). > 4. **Composición, no struct**: el padre que quiera renderizar el fondo expone > un snippet (`background`) donde el app compone `…`; > un prop `background={struct}` contradice la regla compositional-not-data-driven > del autor (OnionMenu 2026-06-21), B-5 y la regla 6 de eidos → D-BG.13. > 5. Ejecución: **un agente Opus 5 construye; Fable supervisa** — brief en §10, > protocolo de supervisión en §11. --- ## 0. La pregunta y la respuesta corta **Pregunta** (usuario, 2026-08-17): estudiar el sistema ActiveUIX, su documentación, filosofía y guías, y evaluar un componente `Background` rico, composable en el resto de componentes, que permita las técnicas de fondo de hoy (parallax, etc.), a la par o por encima de las referencias; evaluar idoneidad; si conviene, plan de desarrollo. **Respuesta corta — SÍ conviene, con una forma precisa**: no «un componente más» sino **el anfitrión canónico de capas de fondo** que el tier `blocks` ya está reclamando a gritos y que hoy se resuelve a mano. La evidencia es mecánica, no de gusto: - `src/uix/blocks/hero/hero.svelte` (layout `background`) monta **tres capas a mano**: un `Box` absoluto para el media del app, un `Box` con `style="background: var(--color-overlay); opacity: var(--opacity-scrim)"` de scrim y un `