# PLAN — Tier `blocks`: composición reutilizable (infraestructura + componentes base + catálogo) > **Kickoff para sesión nueva**: _"Lee `docs/process/PLAN-blocks.md` y continúa > la fase que toque."_ Decisión de usuario (2026-07-21): existe un tier nuevo > **`blocks`** — conjuntos de componentes desempeñando una función (cabecera > sticky, hero, footer, app-shell…). Este plan es autosuficiente: cada fase > lista QUÉ leer, QUÉ producir y CON QUÉ guard se verifica. Un agente no debe > descubrir la doctrina por arqueología — este documento la enlaza toda. > > **Antes de escribir código de F0**: presentar al usuario las decisiones > D-BLK de §2 (AskUserQuestion o tabla en chat) y obtener firma. Las > propuestas de este plan son eso — propuestas razonadas, no decisiones > tomadas. --- ## 0. Contexto y estado - **Origen**: análisis del ecosistema (sesión 2026-07-21). Diagnóstico: el catálogo de primitivas es excepcional (~140 componentes eidos, ~95 con soma); la brecha está en (a) piezas de contenido/estado de página y (b) el nivel de composición. Iniciativa registrada en `docs/next-features.md` §8. - **Precedentes en el repo**: la familia `chat-*` es un "bloque" construido como componentes canónicos (siguió la ruta de 9 fases porque cada pieza tiene contrato real); `picker-shell` es un chasis compartido; el tier `packs` (`docs/architecture/packs.md`) ya resolvió la pregunta "¿cómo vive un tier fuera del canon?" — este plan lo usa de espejo. - **Estado**: F0 pendiente (nada construido). Actualizar esta tabla al cerrar cada tanda, estilo `PLAN-component-coherence.md`. | Fase | Contenido | Estado | | ------ | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **F0** | Infraestructura del tier: doctrina + alias + guard + rutas demo | **HECHA 2026-07-21** (F0.1–F0.7; cross-ref en `comparison.md` omitido a propósito — sin aporte hasta que exista catálogo) | | **F1** | **8** componentes base del CANON que los blocks necesitan (7 + `nav-tree` por E-1) | **CERRADA — 8/8 HECHAS** (empty-state · result · callout · **sticky** · **prose** · **anchor-nav** · **nav-tree** · **sidebar**, PASS las ocho; ver registro) | | **F2** | Blocks de sitio (**14**: 10 + banner·team·contact·content-section por E-3) | pendiente (F2 solo requiere F1.1) | | **F3** | Blocks de aplicación (10) | pendiente | | **F4** | Blocks de docs (3) | pendiente | | **F5** | Backlog condicionado (componentes media/mobile + blocks diferidos) | pendiente | --- ## 1. Qué es un block (doctrina propuesta — aterriza en `docs/architecture/blocks.md` en F0) Un **block** es una composición nombrada de componentes del canon que desempeña una función de página: no aporta primitivas nuevas, aporta _ensamblaje correcto_ (layout, landmarks, jerarquía de headings, responsive, puntos de contenido). Consume el framework; el framework nunca lo referencia. La tabla de tiers queda: | Tier | Valor | Contrato | Entra por | | ------------------------------ | ------------------------------------------------------------------------ | ---------------------------- | ------------------------------------------------ | | **Canon** (`src/uix/`) | densidad de contrato (eventos, ARIA, teclado, tokens que otros consumen) | morfo + matriz de aceptación | ruta de 9 fases (`docs/building-a-component.md`) | | **Packs** (`src/packs/`) | decoración parametrizada de hoja | contrato P | `packs-check` | | **Blocks** (`src/uix/blocks/`) | composición de función de página | contrato B (§3) | `blocks-check` | **Regla de admisión (espejo de la de packs)**: si al construir un block hace falta comportamiento nuevo con superficie de contrato — un evento real, una máquina de estados, un `data-attr` que el CSS necesita seleccionar, una obligación a11y de widget — esa pieza se construye ANTES como componente canónico por la ruta de 9 fases, y el block la compone. **Nunca se le crece el privilegio al block**. (Es exactamente la regla "compose existing components; flag gaps" de `docs/guides/component-guide.md` §4, elevada a frontera de tier.) La F1 de este plan existe porque ese triage ya está hecho: los 7 gaps detectados se construyen primero. Lo que un block SÍ posee semánticamente: **landmarks y estructura de documento** (`header/nav/main/aside/footer`, jerarquía h1–h6, skip-link, `aria-label` de región). Los componentes no pueden saber el contexto de página; los blocks sí. Es su única superficie a11y propia. Un block PUEDE tener estado de vista local (pestaña activa, toggle mensual/anual) usando los props/eventos públicos de los componentes que compone. Lo que NO puede es materializar ese estado con DOM/CSS propio que requiera contrato (→ regla de admisión). --- ## 2. Decisiones D-BLK — FIRMADAS 2026-07-21 Repasadas y firmadas por el usuario en el kickoff (F0.1 HECHA). **D-BLK.1 quedó enmendada** respecto a la propuesta original del plan (que proponía `src/blocks/`); el resto se firmó tal como estaba propuesto. D-BLK.3/4/5 derivan de doctrina ya vigente y se firmaron por no-objeción. | # | Decisión | FIRMADO | | ----------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **D-BLK.1** | Ubicación y alias | **`src/uix/blocks/`** + alias `$blocks` (decisión de usuario: el tier es UI y vive junto a las capas). La prueba de encapsulación se conserva íntegra: borrar `src/uix/blocks/` deja `npm run check` verde y NADA del canon (`morfo/soma/sema/eidos/active-uix/langs`) lo importa — blocks es un tier bajo `src/uix/`, no una quinta capa. | | **D-BLK.2** | Estilos | **Layout-components-first**: el layout se hace componiendo `Container/Section/Stack/Flex/Grid/AutoGrid/Wrap/Group/Separator/AspectRatio/Surface` y sus props. Un block NO trae `.css` propio; un `