absorb remaining d365fo-mcp-server material: RDL precision design (R3) and form engine extras (R5)

[dynamics365ninja]

Carried over from docs/KNOWLEDGE_AUDIT.md §7 items R3 and R5 — reusable material from the predecessor dynamics365ninja/d365fo-mcp-server, audited at v1.8.0. The audit docs are retired; this issue is their successor.

R3 — RDL / precision design (also finding G7). generate report now emits the full stack (TempDB table, DP, contract, SrsReportRunController, output menu item, AxReportAutoDesign with table data regions), all verified lossless against the live provider. RDL is deliberately not generated: it lives in AxReportPrecisionDesign.Text as an escaped document, and although precision designs outnumber auto designs in shipped code, a wrong RDL is far harder to detect than a wrong contract — the file loads and the report simply renders wrongly. The predecessor's generateSmartReport.ts (64 KB) does emit CDATA-embedded RDL 2016 with page-header injection and grouped-tablix/subtotals, and carries two regression-locked EDT-resolution bugs. Absorbing it needs its own evidence base first (a rendering oracle, not just a deserialization one).

R5 — form engine extras. Not ported:

• formCloner.ts — clone a Microsoft reference form and re-bind data sources, string-level by design (XML round-trips corrupt AOT files).
• fieldControlTypes.ts — derive the control type from the field's real i:type rather than EDT-name heuristics.
• crossCheck.ts — mined-usage cross-check reporting catalog gaps after every index build.

Note that the structural half of R5 was absorbed and then some: scripts/emit-form-patterns.ps1 derives 162 pattern definitions from Microsoft.Dynamics.AX.Metadata.Patterns.dll, which is stronger than the predecessor's hand-maintained catalog.

[dynamics365ninja]

Closed in #167 (ea61000, 6731160).

R5 — crossCheck. d365fo index cross-check compares what the installation actually uses against the catalogs this repo ships. Run against a live install it found one real gap — three shipped forms use the HubPartGrid pattern and the registry has no entry, so form-pattern validate and repair cannot judge them — and one instructive false positive worth recording: Custom is the fourth most common <Pattern> value (915 indexed forms) and is not a pattern at all, it is the AOT's marker for a form that deliberately has none. Of 143 sampled forms carrying it, not one has a PatternVersion.

Gaps and uncovered families are reported separately rather than ranked. A gap is where the tool will be wrong; an uncovered AOT family is where it is merely narrow, and 40 of the 83 AOT folders on a real installation are families this tool was never built to handle. Mixed together, the 40 would have buried the 1.

R5 — formCloner. d365fo generate form-clone, string-level by design. An AxForm's Design subtree is the empty namespace with i:type on every control, so a round-trip through XDocument rewrites namespace declarations nobody asked to change — the same reason FormPatternTemplates renders forms as strings. Verified against a shipped 16 KB CustGroup: the clone differs on exactly the intended lines, is byte-identical everywhere else, and passes validate xpp clean.

R5 — fieldControlTypes landed earlier in #166.

R3 — RDL precision design: declined, not deferred. This issue already contained the reason and it holds up: a wrong RDL renders wrongly rather than failing to load, so absorbing generateSmartReport.ts needs a rendering oracle. Every other check in this repo rests on a deserialization oracle — the file either loads as the type says or it does not — and that is a different class of evidence from "does this report show the right numbers on a page". Nothing here can build the latter, and shipping RDL generation without it would produce exactly the confident-but-unverifiable output the rest of the repo is built to avoid.

If that changes — a rendering oracle, or a corpus of RDL known-good outputs to diff against — this is worth reopening. Absent that, R3 stays out on purpose.