Corrección del autor, y era una equivocación de fondo, no de forma. Yo había
escrito que un menú en la barra sería «una segunda navegación dentro de un shell
cuya navegación es el raíl». Es al revés:
- la BARRA lleva la APLICACIÓN — su menú general, las áreas que tiene, y lo que
es de la persona y no de la página (buscar, avisos, la cuenta). No cambia
cuando el lector se mueve dentro de un contexto;
- el RAÍL lleva el CONTEXTO en el que está — este proyecto, esta tabla: sus
secciones y sus acciones. Cambias de contexto y el raíl entero cambia; la
barra no se mueve.
Es el `TopNav` + `SideNav` de Atlassian y el `TopBar` + `Navigation` de Polaris,
que estaban en mi propio dossier. Y es también por qué una app publica DOS
landmarks `navigation` legítimamente: la APG pide nombre único en los repetidos,
y cada uno nombra un ámbito distinto.
La demo modelaba mal: el raíl era el menú general. Ahora la barra lleva marca +
`NavigationMenu` de la aplicación (Bandeja · Proyectos · Informes) y el raíl es
el proyecto Apollo (Tablero · Conversaciones · Archivos + sus Acciones). El
rastro se va con ella: su sitio es la cabecera de la PÁGINA, no la barra —
cambia con cada vista mientras la barra no, y una barra que lo lleva crece una
segunda fila en cuanto la ruta tiene tres niveles, que es lo que se midió antes
de moverlo.
De `site-header` se queda sólo la razón que era cierta: no es que sobre una
navegación, es que la pieza es de un SITIO — `Sticky` por defecto (una barra de
app bajo `scroll="main"` no debe pegarse) y `Container` MEDIDA (una barra de app
va de borde a borde). Su forma marca · nav · acciones es la correcta.
**Y un defecto de canon que sólo aparece con dos navegaciones**: `NavigationMenu`
deja su landmark ANÓNIMO — el `aria-label` se reenvía al `<ul>` y el `<nav>` se
queda sin nombre (el morfo lo declara así: «the root delegates its name to the
list it wraps»). Un `<ul>` no es un landmark. Medido:
`navigation: ['Navegación principal', null, 'Migas de pan']`. No se arregla
desde fuera —nombrar la lista no nombra la región, y envolver en otro `<nav>`
anidaría landmarks—, así que queda VISIBLE y registrado en los Gaps.
Guards: `blocks:check` verde · `docs:check` 0/0 · `svelte-check` sin errores
propios (de paso, `NavigationMenu.Item` exige `value` y no se lo pasaba).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ -213,5 +213,6 @@ lo logra. Una receta que no se ha visto en el navegador NO entra en esta tabla._
| `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 |
| **`NavigationMenu` deja su landmark ANÓNIMO** | **canon, medido 2026-08-19**: su `aria-label` se reenvía al `<ul>` (`data-navigation-menu-list`) y el `<nav>` raíz se queda sin nombre — el morfo lo declara así a propósito («the root `<nav>` delegates its name to the list it wraps»). Un `<ul>` no es un landmark: quien navega por regiones ve el `<nav>`, y en un shell hay TRES navegaciones (la de la aplicación, la del contexto y el rastro), así que la APG exige nombre único en cada una. Medido en el preview: `navigation: ['Navegación principal', null, 'Migas de pan']`. No se arregla desde fuera —nombrar la lista no nombra la región, y envolver en otro `<nav>` sería anidar landmarks—, así que la demo lo deja visible en vez de fingirlo |
| **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 |
