El shell declara la excepción B-10 —los shells componen otros blocks por
diseño— y no compone ninguno. Eso estaba escrito como si fuera una tarea
pendiente. No lo es, y ahora dice por qué.
El candidato obvio es `site-header`, y es la pieza equivocada aquí por tres
cosas que están en su propio API: es `Sticky` por defecto (una barra de
aplicación bajo `scroll="main"` NO debe pegarse — nada se desplaza por debajo
de ella), envuelve su contenido en un `Container` MEDIDA (una barra de app va de
borde a borde de su inset), y su forma es marca · nav · acciones + drawer
móvil, o sea una SEGUNDA navegación dentro de un shell cuya navegación es el
raíl. Es el cromo de un SITIO; esto es una aplicación.
Lo que sí falta, y queda registrado como gap: lo que una barra de aplicación
sostiene de verdad —disparador del raíl, rastro, buscador, avisos, menú de
usuario— no tiene pieza en el tier. `user-menu` (F3.6) y `notifications` (F3.7)
están planificados y sin construir, y el shell los compondrá POR esta misma
excepción el día que aterricen. Hasta entonces la barra es el snippet del app,
montada con canon (`Sidebar.Trigger` + `Breadcrumb` + `Toolbar` + `Button`), que
es lo que enseña la demo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| **Los primitivos de layout no pueden cambiar de elemento** (F21) | **canon, registrado**: `Box` —y con él `Grid`/`Flex`/`Stack`— renderiza un `<div>` fijo, así que `<main>` / `<aside>` no pueden SER una caja del sistema. Por eso esos dos elementos llevan un `style` en línea con dos declaraciones (`flex`, `min-inline-size`, `overflow`). No es re-estilizar internals de un compuesto (B-3): es el elemento propio del block. Precedente en el tier: `article-grid-article.svelte` |
| **Topbar a todo lo ancho** (eje `layout` del `Sidebar`) | **canon, v2** — el provider del `Sidebar` es la fila flex. Lo pedirá `docs-shell` (F4.1) |
| **El `Sidebar` no publica su ancho actual** | no hace falta aquí (la reserva es flexbox), pero un app que quiera anclar algo al borde del rail no tiene a qué. Mantine expone 8 vars `--app-shell-*`; anotado por si aparece un consumidor real |
| **Superficie online/offline** | no existe en el ecosistema (ni art ni dimensión de prefs). Un ribbon de «sin conexión» en `banner` lo tiene que alimentar el app desde `Connections.anyReconnecting` |
| **Dos landmarks `banner`** cuando el `banner` que entra es el canon `Banner` | **ledger A-109**, del canon: `Banner` estampa `role="banner"` DESPUÉS de los rest props, así que no se puede quitar. Nombrar los dos es todo lo que puede un app |
| `scroll-margin-block-start` en los destinos bajo `scroll="body"` | del consumidor: la altura de la cabecera la sabe él. Lo cerrará `docs-shell`, que es quien tiene anclas |
| **`Sidebar.MenuButton` es MUDO y `NavigationMenu.Link` no** — el mismo acto, dos respuestas | **canon, para una sesión de sema**: elegir un destino en una superficie de navegación emite `commit-select` en el `NavigationMenu` y NADA en el `Sidebar` ni en el `NavTree` (sus morfos sólo declaran `emerge-expand`/`emerge-collapse` sobre el panel). El README del `Sidebar` lo firma —«navegar una fila es nativo y no suena»— pero entonces el `NavigationMenu` contradice la firma. Además, en un shell la fila del raíl casi nunca navega: SELECCIONA la sección (`aria-current="page"`), que es exactamente el caso de `commit.select`. No se decide desde el tier |
| **`Toolbar.Button` no acepta `variant`/`color`** | **canon, anotado**: `ToolbarButtonProps` tipa contra el `ButtonProps` de SOMA (`{ id, disabled }`), así que el tratamiento es del root y todos los ítems lo llevan igual. Un grupo donde una acción es la principal no tiene cómo decirlo desde dentro; aquí la principal va al lado del cluster, como en las referencias |
| **No existe `description-list`** | **canon, F5**: el backlog lo condiciona a «el primer detail-view real» — y el panel de detalle de este shell lo es. Mientras no exista, el significado lo llevan `dl`/`dt`/`dd` con la tipografía del tema, y se declara aquí en vez de fingirlo con `div`s |
| **Los primitivos de layout no pueden cambiar de elemento** (F21) | **canon, registrado**: `Box` —y con él `Grid`/`Flex`/`Stack`— renderiza un `<div>` fijo, así que `<main>` / `<aside>` no pueden SER una caja del sistema. Por eso esos dos elementos llevan un `style` en línea con dos declaraciones (`flex`, `min-inline-size`, `overflow`). No es re-estilizar internals de un compuesto (B-3): es el elemento propio del block. Precedente en el tier: `article-grid-article.svelte` |
| **Topbar a todo lo ancho** (eje `layout` del `Sidebar`) | **canon, v2** — el provider del `Sidebar` es la fila flex. Lo pedirá `docs-shell` (F4.1) |
| **El `Sidebar` no publica su ancho actual** | no hace falta aquí (la reserva es flexbox), pero un app que quiera anclar algo al borde del rail no tiene a qué. Mantine expone 8 vars `--app-shell-*`; anotado por si aparece un consumidor real |
| **Superficie online/offline** | no existe en el ecosistema (ni art ni dimensión de prefs). Un ribbon de «sin conexión» en `banner` lo tiene que alimentar el app desde `Connections.anyReconnecting` |
| **Dos landmarks `banner`** cuando el `banner` que entra es el canon `Banner` | **ledger A-109**, del canon: `Banner` estampa `role="banner"` DESPUÉS de los rest props, así que no se puede quitar. Nombrar los dos es todo lo que puede un app |
| `scroll-margin-block-start` en los destinos bajo `scroll="body"` | del consumidor: la altura de la cabecera la sabe él. Lo cerrará `docs-shell`, que es quien tiene anclas |
| **`Sidebar.MenuButton` es MUDO y `NavigationMenu.Link` no** — el mismo acto, dos respuestas | **canon, para una sesión de sema**: elegir un destino en una superficie de navegación emite `commit-select` en el `NavigationMenu` y NADA en el `Sidebar` ni en el `NavTree` (sus morfos sólo declaran `emerge-expand`/`emerge-collapse` sobre el panel). El README del `Sidebar` lo firma —«navegar una fila es nativo y no suena»— pero entonces el `NavigationMenu` contradice la firma. Además, en un shell la fila del raíl casi nunca navega: SELECCIONA la sección (`aria-current="page"`), que es exactamente el caso de `commit.select`. No se decide desde el tier |
| **`Toolbar.Button` no acepta `variant`/`color`** | **canon, anotado**: `ToolbarButtonProps` tipa contra el `ButtonProps` de SOMA (`{ id, disabled }`), así que el tratamiento es del root y todos los ítems lo llevan igual. Un grupo donde una acción es la principal no tiene cómo decirlo desde dentro; aquí la principal va al lado del cluster, como en las referencias |
| **La barra superior no tiene pieza propia** | **tier, planificado**: lo que sostiene una barra de aplicación —disparador del raíl, rastro, buscador, avisos, menú de usuario— no existe como una pieza; `user-menu` (F3.6) y `notifications` (F3.7) están planificados y sin construir, y el shell los compondrá POR la excepción B-10 el día que aterricen. Mientras tanto la barra es el snippet del app, montado con canon. ⚠️ El candidato obvio, `site-header`, es la pieza equivocada aquí y por su propio API: es `Sticky` por defecto (una barra de app bajo `scroll="main"` NO se pega — nada se desplaza por debajo), envuelve en un `Container` MEDIDA (una barra de app va de borde a borde de su inset) y su forma es marca · nav · acciones + drawer móvil, o sea una SEGUNDA navegación dentro de un shell cuya navegación es el raíl. Es el cromo de un SITIO, y esto es una aplicación |
| **No existe `description-list`** | **canon, F5**: el backlog lo condiciona a «el primer detail-view real» — y el panel de detalle de este shell lo es. Mientras no exista, el significado lo llevan `dl`/`dt`/`dd` con la tipografía del tema, y se declara aquí en vez de fingirlo con `div`s |
