fix(pages): stop wrapping layout placeholders in a synthetic container (#760)

[ako]

Fixes mendixlabs#760.

The bug

Every mxcli-authored page carried a container nobody asked for. The builder wrapped each non-empty layout placeholder in a Forms$DivContainer named conditionalVisibilityWidget<N>, so creating a single button produced a button and a container — visible in the Studio Pro widget tree of every page mxcli wrote.

Reproduced exactly as reported:

DivContainer count: 1
wrapper names: ['conditionalVisibilityWidget1']
ActionButton count: 1

Root cause — an artificial model constraint, not a BSON requirement

Forms$FormCallArgument carries a Widgets array, and both writers already emitted an array containing exactly one element. The wrapper existed only because pages.LayoutCallArgument declared a single Widget field, so N widgets had to be squeezed through a 1-widget hole.

Verified against Mendix's own output rather than inferred. Administration.Account_Overview in a mx create-project 11.12.2 app:

placeholder 'Atlas_Core.Atlas_Default.Main': 2 top-level widget(s)
  -> ['Forms$DivContainer', 'Forms$LayoutGrid']
conditionalVisibilityWidget occurrences: 0

Two top-level widgets sitting directly in the placeholder, no wrapper anywhere.

That also corrects a comment of ours claiming the wrapper is what "mxcli (and Studio Pro) adds as a layout placeholder container". Studio Pro uses that name when wrapping a widget for conditional visibility, not for placeholders — the same reasoned-by-analogy error that produced mendixlabs#812.

Corroborating signal

Three places already worked around the container: DESCRIBE unwrapped it to avoid "a phantom CONTAINER wrapping all widgets", and the catalog builder skipped it as "transparent". When three readers are compensating for a construct, it probably shouldn't be written.

Those readers are deliberately kept — projects authored before this fix still contain wrappers and must keep reading correctly. This changes what we write; it does not retro-clean existing pages.

The change

LayoutCallArgument.Widget → Widgets []Widget, and the builder places the authored widgets directly. Seven call sites across the two writers, the MCP backend, the builder and one example.

Verification

End-to-end on a real project, identical on both engines:

input	placeholder contents	wrappers
one button	[Forms$ActionButton]	0
three widgets	[Forms$DynamicText, Forms$ActionButton, Forms$DivContainer]	0

The DivContainer in the second row is the one the author wrote — the fix removes the synthetic wrapper, not real containers.

mx check   ->  "The app contains: 0 errors."
DESCRIBE   ->  round-trips to the authored MDL

Mutation-checked: truncating the writer's widget list fails the new test with the reported symptom. Full suite green; corpus 237/39 including the new repro fixture.

Note on test placement

I put the regression test at the writer level (sdk/mpr) rather than the builder. The builder test needs layout resolution through a backend, and the harness plumbing was costing more than the coverage was worth; the writer test needs no backend and still pins the model change and both serializers. The builder behaviour is covered by the end-to-end BSON evidence above.

🤖 Generated with Claude Code

https://claude.ai/code/session_012XR649rKk68z6gBpngu6MA

---

Generated by Claude Code