El generador de fichas conservaba un solo bloque —el veredicto §5, entre sus
marcadores— y reescribía todo lo demás desde la plantilla. Así que una
elaboración que un humano hubiera añadido en §1.1–§1.4 desaparecía en silencio:
donde alguien escribió «_Ninguno_ — los cuatro que había (el padding-block del
divisor, el radio de foco de la fila de evento…) están cosidos», la
regeneración dejaba «_Ninguno._».
Le pasó DOS VECES en el mismo día a las dos fichas de chat-*: la primera la
cosí a mano, y mientras trabajaba otra sesión regeneró y la volvió a borrar.
Restaurar a mano es jugar al topo; el defecto está en el generador.
EL CONTRATO NUEVO
Prosa a mano entre `<!-- mano:start -->` y `<!-- mano:end -->`, y el generador
la re-inserta después del MISMO encabezado bajo el que estaba. Un bloque cuyo
encabezado ya no exista NO se pierde: se añade al final bajo «Prosa rescatada»
para que alguien lo reubique. Perder prosa no es nunca el comportamiento por
defecto.
Verificado corriendo `--report` sobre las 170 fichas con la prosa ya envuelta:
los cuatro bloques de chat-log y chat-composer siguen ahí después.
Que la regeneración sea mayoritariamente inocua y ocasionalmente destructiva es
el peor reparto posible, porque nadie lee ese diff. Ahora no hace falta leerlo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
### 4.1 Tokens a declarar en `lib/recipes/base.ts` (0)
La propuesta generada pedía 5 claves. Entraron **2**:
Valor **verbatim** del CSS de hoy: el default no se mueve, sólo cambia quién
puede moverlo. Nombres derivados de recipe-contract §1 (ejes lógicos, talla
al final) y theming §6.7 (slots de color, modificador delante). Un token con
DOS valores distintos es una colisión de nombre: son dos knobs, o el nombre
no distingue lo que debería — se marca `⚠`.
| propuesto | acuñado | por qué |
| --- | --- | --- |
| `context-close-width` + `context-close-height` (⚠ dos valores) | **`context-close-size`** | el chip es un control CUADRADO: una clave para los dos ejes, la forma que `send-size` ya usa en esta misma receta. El ⚠ del generador era un falso conflicto: fundía la caja con su glifo |
| `send-width` / `send-height` (`1.1em`) | — | la regla estaba MUERTA (el `Icon` compuesto escribe su tamaño en línea): retirada, junto con la gemela del chip de cierre |
- El `inline-size: 100%` del textarea es identidad (§1.4), firmado con su anotación.
- **⚠ decisión: `100%` es un valor identidad o geometría de layout, no un knob de tema — el perímetro de «knob» es D-TH.2, sin firmar** — 1: `inline-size`.
### 4.4 Lo que hay que comprobar a mano (PLAN-theming §1.3 · §7.4)
### 4.1 Tokens a declarar en `lib/recipes/base.ts` (1)
La propuesta generada pedía 7 claves. Entraron **4**, con los nombres del
CATÁLOGO y no los del generador:
Valor **verbatim** del CSS de hoy: el default no se mueve, sólo cambia quién
puede moverlo. Nombres derivados de recipe-contract §1 (ejes lógicos, talla
al final) y theming §6.7 (slots de color, modificador delante). Un token con
DOS valores distintos es una colisión de nombre: son dos knobs, o el nombre
no distingue lo que debería — se marca `⚠`.
| propuesto | acuñado | por qué |
| --- | --- | --- |
| `divider-unread-padding-block` | **`divider-padding-block`** | la familia del contrato ya dice `divider-fg` / `-line` / `-font-size` / `-gap`; el generador nombra por el atributo de la parte, el catálogo por el grupo |
- Los dos `block-size: 100%` son identidad (§1.4), firmados con su anotación.
- **⚠ decisión: `100%` es un valor identidad o geometría de layout, no un knob de tema — el perímetro de «knob» es D-TH.2, sin firmar** — 2: `block-size`.
### 4.4 Lo que hay que comprobar a mano (PLAN-theming §1.3 · §7.4)
