- roleCheck.js: isAuditor()/canEditContent(); canEditCode() tambien
excluye auditor. Superficie editor/developer intacta (verificado
contra el codigo pre-cambio en el test).
- records/tables/media/languages: tools de escritura gateadas con
canEditContent(), orden de registro original preservado.
- agents/soporte: agente de evaluacion de incidencias en produccion,
allowed_tools allowlist namespaceada (23 acai_code + 18 playwright,
cero fetch), system.md con formato de informe obligatorio y trato
del texto del cliente como dato no confiable.
- test/auditor-role.test.js: 22 tests de superficie exacta por rol.
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.
- 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.
