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.
Una sesion real del agente guardo title3/title6/title2 (columnas de
builder_custom segun varsMeta.fieldName, como decian las docs) y el front
no pintaba nada: el runtime traduce vars con t($record, $var) por nombre
de var. Corregidas descripciones de set/get_record_translations, docs
03/09/11b y ACAI_ENDPOINTS; ademas el puente PHP ahora rechaza titleN/
textN sobre builder_custom con error explicativo (guardrail).
Path absoluto con prefijo (/en/...); CocoEnlace regenera las filas al
cambiar el enlace base. Actualizados tool description, ACAI_ENDPOINTS y
docs 04/09/11b.
- Nueva categoria tools/languages: list_web_languages,
get_record_translations y set_record_translations (registros, config,
textos_generales y vars de modulo via builder_custom).
- Param lang opcional en list_table_records y get_record
(options.translates de CocoDB).
- Docs actualizados (03/04/06/09/11b + ACAI_ENDPOINTS) con el modelo de
cms_traducciones y los workflows de traduccion.
- role=tool → role=user con tool_result blocks
- assistant con tool_calls → assistant con tool_use blocks
- Merge mensajes consecutivos del mismo role (Claude requiere alternancia)
- Capturar input_tokens del evento message_start
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El planner generaba 3+ steps para tareas simples causando que el
coder repitiera acciones en cada step (creaba el módulo varias veces).
Ahora el engine fusiona los steps en 1 coder con descripción combinada.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
El server compila automáticamente al guardar index-base.tpl via
acai_write — no necesita create_module ni compile_module manual.
- mcp-tools-reference.md: flujo actualizado, create_module marcado legacy
- module-creation-guide.md: paso 2 usa acai_write
- ACAI-CLAUDE.md: key workflows actualizados
- coder.py: system prompt alineado
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
