# ColdFusion Developer e bridge CF

## Contratto osservato nella baseline

**FACT.** `cf-node/index.js:63` esponeva soltanto `evaluate`, `logs_list` e `logs_read`. `shared-agent-rules/COLDFUSION.md:20-22` citava invece `cf_bridge.datasources`. La discrepanza era documentale: l'audit non ha invocato il bridge.

`mcp-coldfusion-developer/SKILL.md:85` e la regola condivisa definivano `evaluate` per ispezione pura, senza query mutative, HTTP, file write o workflow applicativi. L'implementazione CFM aveva denylist/controlli parziali; l'audit non li ha certificati come sandbox completa. Le annotation conservative e le azioni log separate rimangono parte del contratto legacy.

## SGI-05A: decisione accettata e verificata

Sul branch corrente, `COLDFUSION.md` non cita più l'action inesistente e richiede verifica del datasource tramite configurazioni, documentazione o altre fonti target realmente disponibili e autorizzate.

## SGI-05B: decisione accettata e verificata

`cf-node/index.js` descrive `evaluate` come singola espressione/comando CFML breve, una riga, passive inspection, e dichiara che non è una sandbox.

## Confini conservati

La decisione non modifica enum, enforcement, denylist, annotation, routing o comportamento runtime. Sono fuori scope split di `evaluate`, nuova sandbox, nuove action e redesign del bridge. Non previsto dal prodotto: lo sviluppo ColdFusion avviene sulla superficie coding/Codex, non tramite GPT browser.