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>
La tool llamaba a `action_ws=setStaticVars`, que hace un file_put_contents
del builder.json ENTERO en la web para cambiar una sola clave. Eso se
saltaba las dos garantias que protegen ese fichero: el bloqueo de escritura
de la API de ficheros (BLOCKED_GENERATED_FILENAMES en handlers/files.py) y
la allowlist de /api/modules/update-metadata.
El riesgo no era teorico. El builder.json es la unica memoria de que
variable vive en que columna de builder_custom: si una compilacion caia
entre la lectura y la escritura de setStaticVars, esta devolvia el mapeo
var->columna anterior encima del recien generado y el contenido guardado
quedaba colgado de la variable equivocada en TODAS las paginas que usan el
modulo.
Ahora delega en /api/modules/update-metadata, que ya es la via quirurgica
para la metadata y acepta staticVars en su allowlist (objeto, <=64KB,
<=200 claves).
Se aprovecha para quitar el volcado del schema y del payload completos por
consola en cada llamada.
Companion en el repo de Forge: compiler.js reenvia staticVars en cada
compilacion. Antes no lo mandaba, asi que el CMS lo tiraba al regenerar el
builder.json — solo 5 de 4870 modulos lo conservaban.
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.
