El item llevaba un mes en la cola como «la 6a fila fantasma» y estaba FIRMADO
para arreglarse. Al ir a ejecutarlo aparecio el SPEC del propio componente, que
dice lo contrario en TRES sitios coordinados: rejilla de 6 filas constante
«estabiliza la altura» (SPEC.md:270), inventario de reuso pidiendo «rejilla de
mes 6x7» (:492), y `data-outside-month` como estado declarado de `day-cell` CON
su propio token de tema (:311 y :461). Las celdas de fuera de mes son diseno,
no relleno.
La asimetria con la familia —chronos `true`, los otros cuatro `false`— se leyo
como deriva y es al reves: chronos es el unico que escribio su decision, y
coincide con el default de sus dos referentes de libreria, verificados en la
fuente y no citados de memoria: FullCalendar `fixedWeekCount` viene `true` («the
calendar will always be 6 weeks tall») y Toast UI `month.isAlways6Weeks` viene
`true`. Google/Apple/Outlook si varian las filas, pero porque son aplicaciones
que llenan el viewport; chronos no tiene contrato de altura, asi que la receta
propuesta tenia que inventarse la altura con `calc(6 * cell-min-block)` — la
altura de 6 filas. Era la misma altura con 5 filas mas gordas, y menos
informacion.
Medido antes de opinar: hoy son 115 px por fila y 724 px de rejilla en todos los
meses; con `fixedWeeks:false`, jul→dic 2026 da 609/724/609/609/724/609, o sea el
salto de 115 px que la decision queria evitar. Y crecer las filas no ensenaria
ni un evento mas: `maxLanes` es `$state(3)` fijo.
Corregidos ademas dos errores de la ficha original: el default vive en DOS
sitios (chronos.svelte:20 y engine/state.svelte.ts:64), y chronos.css:278 no es
la altura de las filas del mes sino la pista de carriles de chips dentro de una
fila. La conducta de Google queda anotada como FUNCIONALIDAD con firma propia
(contrato de altura + maxLanes derivado), no como flip de flag.
docs:check 0/623.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
