mxcli-todo findings: nine fixes from bootstrapping an app (check-parity, first-build cleanliness, theming, diagnostics)

[ako]

Works through the findings from bootstrapping a to-do app end to end. Each item was reproduced first, fixed, then re-verified against real MxBuild (mx check → 0 errors) or in a browser where the symptom only exists at render time.

Two of the nine are deliberately not code changes — see "Investigated and documented, not fixed" below.

Check parity — accepted by check, rejected later

AND reached the model verbatim (#14b) — a condition kept as a SourceExpr (original text + parsed tree) skipped the operator lowercasing a rebuilt BinaryExpr gets, so IF … != … AND … != empty stored AND and MxBuild answered CE0117.

The reporter's nine-build probe table concluded "any != inside a conjunction fails". It doesn't — the = form of the same condition is rebuilt from the AST, and that path already lowercases. Every failing probe happened to be uppercase and every control lowercase, so the table tracked the wrong variable. The trigger is casing, and it is invisible in a lowercase script.

A parameterized microflow on BEFORE CREATE (#14a) — Mendix passes no object to a before-create handler (the object does not exist yet), so it builds as CE7247. The guard sits in buildEventHandlers, shared by CREATE ENTITY's inline handlers and ALTER ENTITY ADD EVENT HANDLER, and names the way out (AFTER CREATE, which does receive the object). A microflow created earlier in the same script is not readable back yet, so an unreadable microflow is skipped rather than refused.

A forward page reference (#9) — check passed and exec then failed partway through, after earlier statements were already written. --references had an ordered pass for this but needs -p. The ordering is knowable from the script alone when the target is created by a plain CREATE: that CREATE would fail if the page existed, so the script asserts it doesn't and the earlier reference cannot resolve against the project either. CREATE OR MODIFY / OR REPLACE assert nothing, so those stay with --references. The message also says what the old hint couldn't — a cycle has no valid ordering; create one page without the linking widget and add it with ALTER PAGE … INSERT.

Re-runnable scripts and honest feedback

Event handlers are the one member that will not re-run (#18) — ADD EVENT HANDLER errored when it existed, DROP errored when it didn't, and a defensive drop-then-add failed on whichever half didn't match. Now takes IF NOT EXISTS / IF EXISTS, reusing the existing grammar rules so the guard reads the same everywhere.

Demo users that do nothing (#15) — CREATE DEMO USER succeeded and SHOW PROJECT SECURITY said Demo Users Enabled: true, while the running app had zero accounts: with Security Level Off the runtime creates none. The model was written correctly; nothing connected the two facts. Now warned at the moment the user would otherwise believe it worked, naming the one statement that fixes it. A warning, not a refusal — authoring demo users before raising the level is legitimate ordering.

"Sign in failed" that isn't about the password (#16) — the unlicensed local runtime caps concurrent sessions and reports the refusal exactly like a wrong password; the reason is only in .mxcli/runtime.log. --screenshot-user didn't even notice — it filled the form, waited, and saved whatever session it had, so screenshots silently showed the login page. Mendix re-renders the same form on a rejected sign-in, so the username field still being present after the click is the signal; the helper now reports the page's own alert text and reads the log tail.

First build no longer dirties a fresh clone (#7)

The template ships the generated action stubs in an older shape and MxBuild rewrites all of them on the first build. They're tracked files, so a fresh clone went dirty with ~50 changes nobody wrote — and mx check doesn't do it, only a build, which is why it surfaced long after the initial commit.

Fixed the timing, not the content: mxcli new runs one mxbuild --target=deploy so the settled form lands in the first commit (--skip-build opts out). Best-effort by contract — no JDK, no mxbuild, or a failed build is a warning, never a failed creation. Reimplementing the rewrite was rejected: it's MxBuild's generator and version-specific.

Theming and ergonomics

The login page (#19a) — the first screen a user sees, and the one Atlas themes least. It loads the same compiled theme CSS, so it is themeable; nothing themed it. Atlas layers a gradient over a stock photograph and makes the submit button .btn-success, so it follows the success colour rather than the brand. Replaced with a token-built gradient and pointed the button at the brand.

Link text also got its own --mxt-link token: a link needs 4.5:1 as text, while a brand used as a button fill needs 3:1 plus contrast against its own ink — darkening the brand everywhere would have been the wrong lever. Console's light teal was 3.74:1 and is now 5.47/5.10/4.92 against surface/ground/surface-alt. The project's own theme/web/logo.png is deliberately left alone — it's the app's asset to replace.

Inherited attributes on pages (#12) — an attribute declared on a generalization was stored against the specialization, which MxBuild rejects as CE1613. Both resolvers now qualify with the declaring entity, walking the generalization chain.

Smaller ones — exec/check accept - for stdin (#5), so a heredoc works without a temp file; two mxcli syntax spellings the parser rejects are corrected and pinned by a test (#8); the SessionStart hook survives an idle reap and rewrites the legacy form in place rather than duplicating it (#2); theme-cache/ is gitignored; run --local honours the app's configured Application root URL.

Investigated and documented, not fixed

Clipped nav labels (#19d) — traced to Atlas's own constant: the closed sidebar is an icon rail at --navsidebar-width-closed: 48px, set in Atlas's _theme-default.scss. Reproduced against a real compiled theme in Chromium — the <a> for "All tasks" is 57px inside a 48px rail, matching the 56-in-48 measured on the live app. No mxcli theme sets a navigation width, which is why all three themes and both variants render it identically.

An ellipsis rule was written, verified as compiling last, screenshotted — and reverted. It only helps where Atlas also sets white-space: nowrap; elsewhere the label wraps to two readable lines and the rule turns All / tasks into All / t…. The answers (an icon on the nav item, or an open sidebar) belong to the app, not to a theme that would impose them on every app. Documented in theme-styling.md with the reasoning, so the next person doesn't re-derive it.

The #999 empty state (#19b) could not be reproduced: every #999 in the compiled CSS is a Bootstrap default (popover arrows, modal border, print styles). That one needs the reporter's app.

Verification

• Every fix has a unit test, and each was proven to detect its defect: reverting the fix (or stubbing the guard) makes the test fail with the reported symptom.
• A/B against a pre-fix binary on Mendix 11.12.1 where behaviour is observable: --skip-build leaves 50 modified tracked files and the default leaves 0; a pre-fix binary writes the CE7247 handler and MxBuild reports it, the fixed one refuses.
• MDL examples added under mdl-examples/bug-tests/; MDL-PAGE01 checked against every script in mdl-examples for false positives (none).
• The login-page change is verified at the compiled-CSS layer (the overriding rule is last and carries no photo; the button and link declarations resolve), not in a browser — raising the scratch project's security level to serve a login page surfaced pre-existing model errors there that block deploy.
• Symptom rows appended to .claude/skills/fix-issue.md for each fix.
• make build + full go test ./... green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JXnEgoc2NQP1Y2TWMCMXC4

---

Generated by Claude Code