Context
The upstream d365fo-mcp-server exposes d365fo_file(action=modify), which performs safe, structured edits of X++ method bodies through Microsoft's IMetadataProvider — no string-replacement XML corruption. Per docs/MIGRATION_FROM_MCP.md, the CLI currently maps this to a manual editor edit of CDATA method bodies + d365fo index refresh, with structural changes routed through generate … --overwrite.
D365FO.Bridge (.NET Framework 4.8, stdio JSON-RPC, D365FO_BRIDGE_ENABLED=1) already loads IMetadataProvider and handles file create/update/delete for generate --install-to — so the hard part (provider loading, model folder resolution) is done. What is missing is a first-class command that round-trips a single method body through the metadata API.
Proposal
New command, e.g.:
d365fo modify method <ObjectKind> <ObjectName> --method <M> [--file body.xpp | --stdin] --output json
- Reads the object via the bridge, replaces the target method's source, writes back via
IMetadataProvider (never raw XML string surgery).
- Respects the existing grounding gates: require/accept a
prepare change grounding token, run validate references + validate xpp on the new body before write (fail-closed, consistent with generate form's FORM_PATTERN_VIOLATION behaviour).
- Triggers incremental
index refresh for the touched object.
- Non-Windows / bridge-disabled environments: fail with a clear
BRIDGE_REQUIRED error rather than falling back to raw XML edits.
- Expose the same operation through the
D365FO.Mcp adapter (extend ToolCatalog/ToolHandlers) so the unified tool surface keeps parity.
Acceptance criteria
Related: #113 (modifications should record pre-images once the journal lands).
🤖 Generated with Claude Code
Context
The upstream
d365fo-mcp-serverexposesd365fo_file(action=modify), which performs safe, structured edits of X++ method bodies through Microsoft'sIMetadataProvider— no string-replacement XML corruption. Per docs/MIGRATION_FROM_MCP.md, the CLI currently maps this to a manual editor edit of CDATA method bodies +d365fo index refresh, with structural changes routed throughgenerate … --overwrite.D365FO.Bridge(.NET Framework 4.8, stdio JSON-RPC,D365FO_BRIDGE_ENABLED=1) already loadsIMetadataProviderand handles file create/update/delete forgenerate --install-to— so the hard part (provider loading, model folder resolution) is done. What is missing is a first-class command that round-trips a single method body through the metadata API.Proposal
New command, e.g.:
IMetadataProvider(never raw XML string surgery).prepare changegrounding token, runvalidate references+validate xppon the new body before write (fail-closed, consistent withgenerate form'sFORM_PATTERN_VIOLATIONbehaviour).index refreshfor the touched object.BRIDGE_REQUIREDerror rather than falling back to raw XML edits.D365FO.Mcpadapter (extendToolCatalog/ToolHandlers) so the unified tool surface keeps parity.Acceptance criteria
d365fo modify methodupdates a method body via the bridge and the change compiles (covered by an integration test on a VM fixture or a golden-file test against the bridge protocol).docs/MIGRATION_FROM_MCP.mdmapping row ford365fo_file (action=modify)updated to point at the new command.Related: #113 (modifications should record pre-images once the journal lands).
🤖 Generated with Claude Code