bug-logs: stamp BUG-114 and BUG-118 FILED as mendixlabs/mxcli#1076

CHANGELOG.md

@@ -8,6 +8,7 @@ Kinds: `new` · `fix` · `learn` (a skill/learning) · `process` (rules, templat
 Credit the person or project that surfaced the change — the credit line is the thank-you.
 
 ## 2026-09-09
+- process(bug-logs): BUG-114 filed upstream as mendixlabs/mxcli#1076 with BUG-118 as its second reproduction; both drafts and the ledger header stamped FILED — the toolkit merge queue
 - fix(project-bin/page-fidelity.js): **structure classed as bound data, and the score of record silently going `null%` again.** A wireframe's own `<style>` defines two very different kinds of class — BOUND-DATA MOCKS (a repeated region of sample rows, whose literal text a correctly *binding* page contains none of) and STRUCTURE (the wrapper, the page header, the toolbar — furniture the page script genuinely must declare) — and the classifier **drops a mock's whole subtree**, so a misclassified structural class deletes page content from the denominator. The test was `uses === 1 && kept < 0.4`, once-used AND dominant, which contradicts the paragraph directly above it stating that a mock is a **repeated** region: a once-used class whose subtree was *small* fell through the second conjunct and was dropped as sample data. Measured on a MOC/PSSR app replacement's project overview, 2026-09-09: `.page-head` (uses=1, kept=0.513) was deleted **with the page's only `<h1>` inside it**, `.toolbar` (uses=1, kept=0.825) with it, and every dimension reported `0 of 0` — which normalizes to **`null%`**, so the run printed a clean report over an empty corpus. That is the same silent-null failure this file's own header note says was worth fixing, arriving a second time through the other conjunct, on a page that scores **100%** once the page is not gutted. The threshold is **removed rather than retuned**: it was a guess, and any value for it splits once-used wrappers on a measurement that has nothing to do with whether their content is bound data; a repeated region is still a mock at any size, which is the half that was always right. New fixture `tests/wave2/test-page-fidelity-mocks.sh`, **14 assertions**, with two captured wireframe shapes and a `CAPTURE.md` stating that only literal text and class prefixes were changed. Its **first assertion is that the score is not `null`, not that it is high** — a null on a wireframe that draws an `<h1>` means the scorer gutted the page, whatever the eventual percentage. Proven against a known-bad control carrying the old rule: **8 of 14 fail** — Maurits Visser, from a MOC/PSSR app replacement
 - learn(workflow-structure-rules, learned-workflow-patterns): **two workflow signatures that `mxcli check` passes clean and the native build rejects**, plus a v0.21.0 re-probe of the four constructs a real approval chain needs. (1) **A user task's `PAGE` must take a `System.WorkflowUserTask` parameter, not the workflow's context entity** — a context-parameterised page passes `mxcli check --references`, execs, round-trips through `DESCRIBE`, and the native build then says *"The selected page 'X' should accept a parameter of type 'WorkflowUserTask', but expects parameters of types 'MOCProject' instead"*. (2) **A targeting microflow must accept TWO parameters, `System.Workflow` AND the context entity** — one parameter is the natural thing to write and it is wrong. Neither signature appears anywhere in `mxcli syntax workflow`, whose own targeting example is `TARGETING MICROFLOW HR.GetApprovers` with no signature stated. **The expensive half is the planning consequence: the task pages are a PREREQUISITE of the workflow row, not a later UI row** — a plan that builds the workflow at row 41 and its task pages at row 45 cannot make row 41 green, which is exactly how one project's Phase 7 was ordered. Also: with the signatures right, user task + targeting microflow, **multi-user task**, `CALL MICROFLOW` with a quoted `WITH`, and a **backward `JUMP TO`** inside an outcome all build clean on v0.21.0. That result is only worth having because **the same run included the construct known to be broken as a control**: a scripted `DECISION` passed `mxcli check`, printed `Created workflow`, and left the project unopenable (`StorageLoadException` → `BUILD FAILED`), so BUG-76 is open on v0.21.0 and the probe demonstrably distinguishes working from broken. A probe with no known-bad control cannot tell *"it works"* from *"the probe is blind"* — this repo has already published one wrong conclusion for that exact reason (BUG-121) — Maurits Visser, from a MOC/PSSR app replacement
 - new(project-bin): **`check-design-reaches-app.sh` — did any of the design system ARRIVE in the built app?** The gap it closes is a sentence in its own sibling: `check-design-portability.sh`'s header opened by asserting *"a design system's tokens port into Mendix perfectly — colours, radii and spacing variables survive the SCSS port intact"*, which is false and was the sentence that made everyone comfortable. Tokens survive the port into a **file**; nothing about landing in the file makes the framework read them. Measured on a MOC/PSSR app replacement, 2026-09-09: 55 tokens sampled from the customer's own screenshots, ported correctly, into the right file, at the stage that owed them — and the app rendered every screen in Atlas's default blue for **two more build phases**. Three independent failures, none visible to anything in this toolkit: the bridge assigned **SCSS variables** (`$brand-primary: var(--brand)`) to a theme running `$use-css-variables: true`, so it compiled to nothing (`--brand` present, `--brand-primary` untouched, `var(--brand)` **0 occurrences** in the built sheet); the **20 component classes were never ported at all**, so `ds-muted` on 12 live widgets resolved to the body colour; and a theme module's `:root` is emitted **before** `theme/web/custom-variables.scss`, so even what it did set lost the cascade. `mx check` 0 errors, `mxcli lint` 0 errors, MDL suite green, both e2e journeys green — every one of them reads the model or the authored stylesheet, and the defect lives between the authored stylesheet and the built one. **Found by a human opening a screenshot and asking why the UI was poor.** The check deliberately does NOT look for a known default hex (a cache of one framework version — authoring rule 5); it inverts the question to *"is the winning definition of each knob the framework declares pointed at a design-system token"*, which needs no defaults table and survives the next Atlas release. Four passes with denominators (knobs bound · tokens arrived · classes arrived · dead SCSS bridge) plus a WARN for classes the **model** asks for that the built sheet never defines — which found 17 of 23 on the same project, `ds-help` among them, class names typed from memory onto live widgets. Requires a build and exits **2** without one, because "did it reach the app" cannot be answered from source, and answering it from source is how this shipped — Maurits Visser, from a MOC/PSSR app replacement

bug-logs/mxcli-bugs.md

@@ -4076,7 +4076,7 @@ trusting either comparison's row count on its own.
 ## BUG-114: `ALTER PAGE ... REPLACE widget WITH {...}` re-scopes an inherited `ContentParams` reference to the page's OUTER data context — reproduced twice, independently, same project
 
 **Severity:** High — silent CE1613 build failure, and the app is DOWN until reverted
-**Upstream draft:** `bug-logs/pending-github-issues/bug114-alter-page-replace-rescopes-to-outer-context.md` (2026-09-09; carries BUG-118 as reproduction 2 — file once, not twice)
+**Upstream:** FILED — https://github.com/mendixlabs/mxcli/issues/1076 (2026-09-09), from `bug-logs/pending-github-issues/bug114-alter-page-replace-rescopes-to-outer-context.md`; carries BUG-118 as reproduction 2
 **Discovered:** 2026-09-01, re-confirmed independently 2026-09-02, both on the same
 dashboard-publishing migration project
 **Reproducible:** Yes, twice, on two different widgets on two different pages

bug-logs/pending-github-issues/bug114-alter-page-replace-rescopes-to-outer-context.md

@@ -1,6 +1,6 @@
 **Repo:** `mendixlabs/mxcli`
 **Source:** `bug-logs/mxcli-bugs.md`, `## BUG-114` (discovered 2026-09-01, re-confirmed independently 2026-09-02, dashboard-publishing migration project, Mendix 11.12.1, mxcli v0.20.0) and `## BUG-118` (discovered 2026-08-25, a language-learning app conversion, Mendix 11.13.0, mxcli `39c7d94`) — root cause located in the mxcli source at the 2026-09-07 merge review (`mdl/backend/pagemutator/mutator.go`, HEAD `191a0c9`). One issue for both: same walker, two symptoms.
-**Status:** DRAFT — not yet filed. File this one; `bug118-replace-in-gallery-template-drops-binding.md` is folded in below as reproduction 2 and must NOT be filed separately.
+**Status:** FILED — https://github.com/mendixlabs/mxcli/issues/1076 (2026-09-09). `bug118-replace-in-gallery-template-drops-binding.md` is folded in below as reproduction 2; do not file it separately.
 **Suggested labels:** bug, mdl, pages, alter-page, silent-corruption
 
 ---

bug-logs/pending-github-issues/bug118-replace-in-gallery-template-drops-binding.md

@@ -6,7 +6,7 @@ separately.
 **Source:** `bug-logs/mxcli-bugs.md`, `## BUG-118: ALTER PAGE ... REPLACE targeting a widget
 nested inside a GALLERY template's child slot drops the new widget's ContentParams/attribute
 binding` (discovered 2026-08-25, ToeicBuddy-conversion field run)
-**Status:** DO NOT FILE SEPARATELY — same defect as BUG-114 (root cause located in `mdl/backend/pagemutator/mutator.go`, merge review 2026-09-07); attach this body as the second reproduction to BUG-114's issue — it is the diagnostic one, because `<unbound>` is visible in `DESCRIBE PAGE` and the re-scope is not
+**Status:** FILED as reproduction 2 of BUG-114's issue — https://github.com/mendixlabs/mxcli/issues/1076 (2026-09-09). DO NOT FILE SEPARATELY — same defect as BUG-114 (root cause located in `mdl/backend/pagemutator/mutator.go`, merge review 2026-09-07); attach this body as the second reproduction to BUG-114's issue — it is the diagnostic one, because `<unbound>` is visible in `DESCRIBE PAGE` and the re-scope is not
 **Note:** unlike most entries in this folder, this defect WAS caught by the real `mx check`
 gate (CE0402), not left silent — filing it anyway because the two mxcli-side checks
 (`mxcli check --references`, `mxcli exec`) both reported success, so a project relying on those