Había DOS tipos exportados con el mismo nombre. config-types.ts:39 declara
`ColorRole = HierarchyColorRole | Intent` derivado del const (9 roles, con
tertiary) y existía desde el 2026-05-13; eidos/lib/types.ts:125 lo re-escribió
a mano siete días después con 8 miembros —sin tertiary— y nada lo justifica:
ni el commit (fb5dd0919, «Advance Eidos demos and form validation docs»), ni un
comentario, ni un documento. No fue una decisión de excluirlo: fue una omisión,
y el 2026-06-27 se fosilizó al añadir HierarchyColorRole AL LADO en vez de
arreglarla. Qué fichero importara de dónde decidía si tertiary era legal.
La deriva era SÓLO de tipos: el runtime nunca divergió. resolveComponentColor
une COLOR_ROLES + PALETTE_SCALES (42), la capa compartida emite la fila
[data-color='tertiary'] iterando COLOR_ROLES, y 94 ficheros pasan por ese
resolvedor. O sea que el tipo rechazaba en compilación un valor que el motor
resuelve. Por eso ensanchar 8 -> 9 es aditivo: check queda en la línea base
exacta (73 errores / 53 warnings) y los 362 tests de eidos pasan.
- eidos/lib/types.ts re-exporta ambos tipos de config-types, donde derivan del
const. El docblock deja escrito el porqué para que no vuelva por ignorancia.
- Guard nuevo en recipe-css-contract.test.ts: falla si un fichero de eidos/lib
vuelve a deletrear >=2 nombres de rol como literales. Verificado con control
negativo — caza el texto del bug original y el HierarchyColorRole a mano;
permite el Extract<> legítimo, el re-export y uniones ajenas al color.
Documentación del color, reconciliada contra el código:
- reference.md §4 «Per-component subset» seguía enseñando los subconjuntos por
componente que §25 derogó el 2026-07-18, con tabla y justificación, sin marca.
Marcada REVOKED; conserva el arbitraje (intent evaluativo gana), que es lo que
sigue vivo.
- `tertiary` figuraba como RESERVADO y no consumido en dos sitios (reference §4
y el comentario de themes/base.ts) cuando entra en ComponentColor, lo acepta
todo prop color abierto y tiene su fila en la capa compartida.
- rfc-color-engine §13 decía «the 9 --color-{role}-{slot} slots»; son 12
(COLOR_ROLE_SLOTS). Ahora enlaza el const en vez de copiar el número.
- El frontmatter del mismo RFC daba la fase 5 por «gated» cuando su `border`
6->7 aterrizó el 2026-06-05 (reference §28); y §9 leía como lista de defectos
vivos cuando sus cuatro filas están hechas.
- reference §40 se contradecía en una línea: llamaba a CONTRAST_PAIRS fuente
compartida «con el Stage-2 solver» y 40 líneas después declaraba que Stage 2
cerró SIN solver.
- 8 citas a «THEMING §25.5» apuntadas a §25: esa numeración sobrevivió en la
crónica (changelog §25.5) pero no en la referencia tras la escisión.
- JSDoc de avatar y card documentaba su prop como «Canonical ColorRole» (8)
cuando el tipo real es ComponentColorProp (42 + CSS crudo) — justo lo que lee
un consumidor.
- «8 roles» hardcodeado en callout/README.md (error de docs:check),
callout.svelte y mark/README.md: enlazan el const, como manda authoring.md.
docs:check baja de 2 errores a 1.
Y una anotación, no un arreglo: banner/types.ts declara `BannerIntent =
ColorRole`, fundiendo el eje evaluativo con el de pintura (primary/secondary no
son evaluativos), y Banner no tiene prop `color` en absoluto. Queda marcado en
el docblock como decisión pendiente con sus citas — resolverlo es el otro frente
(un solo eje de color arbitrado por intent), y no está decidido.
Fuera de este commit: src/uix/blocks/banner/ es un directorio entero sin
trackear (trabajo en vuelo), y ahí quedan las dos últimas instancias del conteo
hardcodeado, incluido el error que le queda a docs:check.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dev
15621632be