La seccion ya estaba escrita, pero el agente no llegaba a ella. Dos motivos:
- El summary del frontmatter y el parrafo de entrada de 01-builder-fields
enumeran lo que cubre el doc y no mencionaban ni el agrupado en pestanas ni
la visibilidad condicional. Ese summary no es decorativo: entra en el texto
que se embebe (title + summary + primeros 2000 chars) y es lo que se ve en
list_docs, asi que una seccion en el char 10000 sin rastro arriba es
invisible para la busqueda semantica y para el que decide que doc abrir.
- 11b-rules-cheat-sheet es el doc de consulta rapida y ya tenia la linea de
data-field-group; sin la hermana de data-field-show, quien mirase ahi
concluia que las pestanas no se pueden condicionar.
Se anade la linea al cheat-sheet con la gramatica minima y los dos errores
tipicos (se referencia el nombre de variable y no el label; `campo=` es vacio).
El doc cubria data-field-group (repartir vars en pestanas) pero no habia forma
documentada de condicionar que se ve: los modulos con modos excluyentes
ensenaban al usuario todos los campos de todos los modos a la vez.
Se documentan los dos atributos nuevos (data-field-show en el campo,
data-field-group-show en una var del grupo), que llegan al builder.json por el
mismo mecanismo generico que data-field-group, con la tabla de la gramatica y
un ejemplo de las dos formas de uso.
Dos avisos que ahorran el error tipico: el campo se referencia por su NOMBRE DE
VARIABLE y no por su label (los acentos se borran, no se transliteran: "Titulo"
es `ttulo`), y `campo=` significa vacio, que es la clave de la primera opcion de
todo `list`.
El commit anterior (49b52b0) anadio un aviso de que `checkbox` no existe como
data-field-type, pero lo dejo listado como tipo valido en cuatro sitios: la
tabla de tipos de 01-builder-fields, su propio frontmatter `summary`, la tabla
de la cheat-sheet 11b y la lista del glosario. El agente consulta esas tablas
antes que el cuerpo del documento, asi que la contradiccion seguia viva:
escribe `checkbox`, el parser lo deja con type indefinido y funciones.php
descarta la variable en silencio. Era el origen del bug de tipos fantasma.
- `checkbox` fuera de las cuatro listas de data-field-type. El aviso se
reescribe para remitir a `list` de dos opciones.
- OJO: `checkbox` SI existe como tipo de campo de TABLA del CMS
(server/handlers/schema.py:98 y :284). Se conservan intactas sus menciones en
05-tables-and-fields, 04-pages-and-records y la tabla de formato de datos de
11b:88, que son otro vocabulario. El aviso lo dice explicitamente para que no
se vuelva a borrar por error.
- `colors` entra en la tabla de 01, en la de 11b y en el glosario: tenia
seccion propia pero no aparecia en ninguna lista, asi que quien consultaba la
chuleta no sabia que existia. `colorpicker` se anade tambien al parrafo de
intro de 01, que lo omitia.
- `corners` y `ratio` se dejan fuera de las tablas a proposito (decision del
usuario: por ahora no se promocionan).
01-builder-fields.md documentaba `checkbox` y `colorpicker` como tipos validos
—y usaba colorpicker en un ejemplo— pero el parser no los reconocia. Verificado
contra el parser real: ambos salian con `type` indefinido, y en ese caso
funciones.php hace `continue` y **descarta la variable en silencio**. O sea que
el doc mandaba al agente a escribir campos que nunca llegaban al builder.json.
En cambio no documentaba `colors`, `corners` ni `ratio`, que si funcionan.
- Se documentan los cuatro tipos reales, con el formato de valor de cada uno.
`colors` es una paleta de N colores en una sola variable (JSON de pares
nombre/color, nombres declarados en data-field-colors); `colorpicker` es un
color suelto (hex plano).
- `colorpicker` pasa a existir de verdad: se anade al parser y al compilador
(companion en el plugin maestro). Forge ya tenia widget para ambos —
ColorsField y ColorField— asi que solo faltaba la pieza del parser.
- `checkbox` se marca explicitamente como inexistente, con la alternativa
(`list` de dos opciones).
- set_module_example_data documenta el formato de ambos, que el agente no podia
adivinar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Las cmsTables (tablas del CMS cuyo contenido MUESTRA un modulo) ya se
definen desde Forge y desde el CMS legacy; faltaba que el agente las
entendiera.
- update_module_metadata acepta cmsTables. El endpoint del server ya la
validaba, asi que solo habia que declararla en el schema Zod.
- get_module_config_vars la devuelve: sale gratis porque el handler ya
resolvia el schema del modulo para uploadFields/varsMeta.
- Docs (01, 03, 09) con el matiz que mas se puede confundir: `tables` es
donde viven los VALORES de las vars (siempre builder_custom, lo pone el
compilador) y `cmsTables` es que contenido MUESTRA el modulo.
Para el agente lo util no es solo escribirlas: al recibirlas sabe donde
esta de verdad el contenido visible. Si le piden cambiar lo que muestra un
listado de noticias, los registros estan en esa tabla, no en las vars del
modulo.
Se documenta ademas que la metadata del builder.json es la UNICA parte
editable del fichero (y solo con esta tool): el resto lo regenera el
compilador en cada compilacion.
