From af50e3f644e02733fb744d6945acf9ff2504528f Mon Sep 17 00:00:00 2001
From: AlvinnYeo <166688987+AlvinnYeo@users.noreply.github.com>
Date: Tue, 13 Oct 2026 18:56:36 +0800
Subject: [PATCH 1/2] inbox: eight field notes from an existing-app
 legacy-widget rebuild

exec.sh keeps an MDL write when mxbuild crashes on it; restore-mpr.sh
usage text; build-plan-status.sh flag order; field confirmations of #228
and #244; Unit-row delete orphan; durable-rebuild kit with a "restate
from DESCRIBE" STOP row; learned widget and data-source entries.
Mendix 11.14.0 Beta, mxcli v0.25.0, toolkit c1efcb3. Lane 1 only.

Co-Authored-By: Claude <noreply@anthropic.com>
---
 CHANGELOG.md                                  |   1 +
 ...0-13-build-plan-status-flag-before-path.md |  63 ++++++++
 ...0-13-durable-rebuild-kit-legacy-widgets.md |  82 +++++++++++
 ...xec-keeps-write-when-mxbuild-cannot-run.md |  75 ++++++++++
 ...-guard-blocks-other-projects-mxcli-test.md |  39 +++++
 ...-10-13-learned-widgets-and-data-sources.md | 135 ++++++++++++++++++
 ...2026-10-13-patch-unit-row-delete-orphan.md |  43 ++++++
 ...-10-13-restore-mpr-usage-says-timestamp.md |  61 ++++++++
 ...ndpoint-after-startup-left-after-signal.md |  55 +++++++
 9 files changed, 554 insertions(+)
 create mode 100644 contrib/inbox/2026-10-13-build-plan-status-flag-before-path.md
 create mode 100644 contrib/inbox/2026-10-13-durable-rebuild-kit-legacy-widgets.md
 create mode 100644 contrib/inbox/2026-10-13-exec-keeps-write-when-mxbuild-cannot-run.md
 create mode 100644 contrib/inbox/2026-10-13-exec-raw-guard-blocks-other-projects-mxcli-test.md
 create mode 100644 contrib/inbox/2026-10-13-learned-widgets-and-data-sources.md
 create mode 100644 contrib/inbox/2026-10-13-patch-unit-row-delete-orphan.md
 create mode 100644 contrib/inbox/2026-10-13-restore-mpr-usage-says-timestamp.md
 create mode 100644 contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md

diff --git a/CHANGELOG.md b/CHANGELOG.md
index b46921d3..7cefc831 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -17,6 +17,7 @@ Sections dated before 2026-09-19 predate the cycle and stay as they are.
 
 ## Unreleased
 
+- process(inbox): **eight field notes from an existing-app legacy-widget rebuild** — exec.sh keeps an MDL write when mxbuild crashes on it and the next exec runs on "Baseline NOT measured"; `restore-mpr.sh` usage says `[timestamp]` but needs the full snapshot path; `build-plan-status.sh` drops a flag given before the path; a field confirmation of #228 case 3 (another project's `mxcli test` blocks exec.sh) and of #244 (signal stop of `run --test-endpoint` leaves AfterStartupMicroflow on `MxTest.RegisterEndpoint`); Unit-row delete refused as ORPHAN, rename-then-drop works; a durable-rebuild kit with a "restate from DESCRIBE" STOP row (DESCRIBE omits module-role and layout-row visibility: 97 role locks in 16 documents, none shown); learned entries for File Uploader image mode (CE0463), native-mapped `radiobuttons`/`image`, tab-page `CaptionParams`/`Visible:` silently dropped, BUG-39 on widget XPath, and two-hop data-source paths. Mendix 11.14.0 Beta, mxcli v0.25.0, toolkit c1efcb3 — a field project (anonymised)
 - feat(lint): **Lint Batch 3 — TXT001 build-process words in user-visible text, TXT002 non-ISO dates in user-visible text, UI001 Data grid 2 / Atlas input layout traps.** From the 2026-10-12 UX-fix retros ([#280](https://github.com/MendixMau/mxcli-project-toolkit/issues/280), [#282](https://github.com/MendixMau/mxcli-project-toolkit/issues/282), [#276](https://github.com/MendixMau/mxcli-project-toolkit/issues/276)): leaked words reached 3 of 3 apps and non-ISO dates 2 of 3, each past a one-off glossary grep; a list view in a grid column and a width on an Atlas input each cost fix rounds. Warning severity, `_rule` finding on a missing field, an empty `strings()` under a FULL-catalog rule, or vocabulary that matches nothing; 23 cases in `tests/lint-rules/test-batch3-rules.sh` (harness gained a `strings()` mock). Field run (mxcli 0.26.0, 21-module Mendix 11.12 model): 0/0/0 over 478 user-visible strings and 271 widgets, with loosened positive controls returning 27/50/17 through the same accessors. TXT002 cannot see format strings inside expressions — that half is a blocked row. `process/lint-backlog.md` Batch 5 lists all 17 candidates from the three issues (rows 32–48) — MendixMau
 - new(process): **feedback typed mid-build gets a change log in `PROJECT.md`, written before any edit, and the BRD/decision/architecture/wireframe is edited before the MDL.** Across 12 mid-build changes on real projects, 12 went straight into MDL and 0 updated a BRD, build plan or wireframe; the drift-sync `UNSYNCED` marker was never written once, and its absence is invisible, so every gate passed on silence. At the other extreme, one already-settled entity change cost ~270k tokens through two helper agents, and one screenshot-driven fix took 4 rounds because it regressed twice. New `skills/change-intake.md` (baseline, lead+ba, Stages 2–7; routing trigger "the user gives feedback or asks for a change mid-project"): one `## Change log` row per ask (`CR | Date | Source | Verbatim ask | Class | Size | Entry artifact | Status | Closed-by`), six classes, each mapped to its entry artifact (a decision is superseded by a new row, never edited; a built page's visual change is recorded as a before/after screenshot pair instead of wireframe upkeep; impl/bug need only a regression journey). Ceremony is proportional: a small change the user typed gets a one-line receipt and no question, a medium one gets one batched question at the next module gate, a large one or one that contradicts a CONFIRMED decision is asked and stopped on, and stakeholder asks wait for the user. Statuses run open → refined → agreed → applied → proven, or rejected. `bin/lib/change-log.sh` holds the one template and the parser: `init-project.sh` writes the section, `sync-project.sh` appends it once to older projects, and `gate-check.sh` prints a **warn-only** `Change log:` line plus a dashboard row (rows not yet applied, N of M; applied/proven rows with no Closed-by; unrecognised statuses). It becomes blocking only after two projects' counts match a hand count. `project-bin/exec.sh --cr CR-NN` tags the BUILD-LOG detail cell (metrics-ledger columns unchanged). Ownership contradiction fixed: the lead marks; ba-agent flushes BRDs and briefs; architect-agent flushes wireframes and `architecture/` (runbook §3b, `iterative-build-loop.md`, `agent-roles.md`, both stubs, `close-the-loop.md`). Inbox TD-04's change-loop half is promoted here, and its row is narrowed to the two unpromoted items. Fixture `tests/wave2/test-change-log.sh` (39 cases, PROJECT.md built by the real init) — MendixMau
 - feat(exec): **per-project exec lock with stale takeover, opt-in `--commit-first`, a post-exec "restart needed / watch can apply this" verdict, a scoped `bin/app-restart.sh`, and `bin/test-scratch.sh` for `mxcli test` on a locked copy** ([#287](https://github.com/MendixMau/mxcli-project-toolkit/issues/287) items 3-4, [#284](https://github.com/MendixMau/mxcli-project-toolkit/issues/284), [#275](https://github.com/MendixMau/mxcli-project-toolkit/issues/275), [#289](https://github.com/MendixMau/mxcli-project-toolkit/issues/289) items 1-2, [#285](https://github.com/MendixMau/mxcli-project-toolkit/issues/285), [#278](https://github.com/MendixMau/mxcli-project-toolkit/issues/278) recipe half). In a 20-task UX-fix field run over three apps (2026-10-12), 57 of 148 `exec.sh` runs applied nothing (26 refused on uncommitted model changes, 15 gate failures, 16 mxbuild exit 1), a machine-wide `pgrep "mxcli exec"` guard blocked an exec because another project was writing, watch mode silently missed recreated microflows, grants, attributes, pages, page URLs and theme SCSS/JS (~26 restarts), and 24 implementer restart-resumes cost 41.6M tokens because only the lead could restart apps. `exec.sh` now locks per project (atomic, `<pid> <epoch> <script>`, a dead or reused pid is taken over with a note; another project never blocks), `--commit-first` commits only the `.mpr` + `mprcontents/` (refused while Studio Pro holds the model; the refusal names the flag), and every applied script ends with the watch verdict (`--watch-compat` alone). `app-restart.sh` stops only the pid `run --local` recorded for THIS project, restarts it with the same command and returns when the port serves a Mendix page and its JS bundle; no record, or a record from another project, refuses. `ui-loop.md` gains the covers / does-not-cover table and the stale-runtime symptom list (incl. the `IO_PathNotFound deployment/web/pages` rebuild crash); `agent-roles.md` lets implementers run that one helper. Fixtures: `test-exec-lock-watch.sh` (45), `test-app-restart.sh` (30), `test-test-scratch.sh` (20) — MendixMau
diff --git a/contrib/inbox/2026-10-13-build-plan-status-flag-before-path.md b/contrib/inbox/2026-10-13-build-plan-status-flag-before-path.md
new file mode 100644
index 00000000..10c444dc
--- /dev/null
+++ b/contrib/inbox/2026-10-13-build-plan-status-flag-before-path.md
@@ -0,0 +1,63 @@
+# build-plan-status.sh: a flag before the project path is dropped and the path is refused
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-13
+**Kind:** bug
+**Field evidence:** hit in the field as `build-plan-status.sh --json <root>`; reproduced on a scratch copy
+of `project-bin/build-plan-status.sh` (blob a5cfc2a, identical at c1efcb3 and on master 0c62f6f).
+**Proposed target:** `project-bin/build-plan-status.sh` (argument parsing, lines 46–62)
+
+---
+
+## What happens (finding, reproduced)
+
+The usage line is `build-plan-status.sh [project-dir] [--html] [--json] [--quiet] [--refresh]`, but
+every other toolkit script accepts flags anywhere, so agents write the flag first:
+
+```
+$ bash build-plan-status.sh --json /path/to/project
+unknown arg: /path/to/project
+exit=2
+$ bash build-plan-status.sh --quiet /path/to/project
+unknown arg: /path/to/project
+exit=2
+```
+
+Cause (code reading):
+
+```bash
+ROOT="${1:-}"
+[ -n "$ROOT" ] && [ "${ROOT#--}" = "$ROOT" ] || ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+shift 2>/dev/null || true
+```
+
+When `$1` is a flag, ROOT falls back to the git top level or `pwd`, and the unconditional `shift`
+then throws the flag away. The real path is left for the flag loop, which rejects it. Our field note
+first described this as "the flag's value is read as the project"; the reproduction shows the exact
+behaviour above (flag lost, path refused, exit 2), which is at least loud.
+
+**The quiet variant (finding, reproduced on a scratch project with one `### Phase 1` heading):** from
+inside a project, `build-plan-status.sh --json` with no path runs on `pwd`, but `--json` has already
+been shifted away. The table prints, no error is shown, and `architecture/build-plan.json` is not
+written. The same project with `build-plan-status.sh . --json` prints `wrote architecture/build-plan.json`.
+
+## Proposed fix
+
+Parse every argument in one loop: a word starting with `--` is a flag, the first other word is the
+project, a second one is an error.
+
+```bash
+ROOT=""
+for a in "$@"; do
+  case "$a" in
+    --html) WRITE_HTML=1 ;; --refresh) WRITE_HTML=1; REFRESH=1; QUIET=1 ;;
+    --json) WRITE_JSON=1 ;; --quiet) QUIET=1 ;;
+    --*) echo "unknown arg: $a" >&2; exit 2 ;;
+    *) [ -z "$ROOT" ] && ROOT="$a" || { echo "unexpected second path: $a" >&2; exit 2; } ;;
+  esac
+done
+[ -n "$ROOT" ] || ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
+```
+
+Retest: the two commands above (today exit 2; after the fix exit 0), plus `--json` alone from inside
+a project with a Phase heading (today no JSON; after the fix `wrote architecture/build-plan.json`).
diff --git a/contrib/inbox/2026-10-13-durable-rebuild-kit-legacy-widgets.md b/contrib/inbox/2026-10-13-durable-rebuild-kit-legacy-widgets.md
new file mode 100644
index 00000000..2df50c62
--- /dev/null
+++ b/contrib/inbox/2026-10-13-durable-rebuild-kit-legacy-widgets.md
@@ -0,0 +1,82 @@
+# Durable rebuild of legacy-widget pages: a four-part kit, and "restate from DESCRIBE" as a STOP item
+
+**From:** a field project (anonymised) — an existing Mendix app (old widgets throughout) changed with mxcli + this toolkit
+**Date:** 2026-10-13
+**Kind:** process
+**Field evidence:** 79 non-writable widgets on 40 live documents (DESCRIBE `-- NOT re-executable` count)
+and 97 role-locked widgets in 16 documents (BSON scan; DESCRIBE showed none). 34 pages and snippets
+were restated whole; the read-back afterwards found 0 non-writable widgets and 0 role locks on them.
+Two drafted scripts would have silently dropped role or row visibility had they run. Mendix 11.14.0
+Beta (Classic client, Production security), mxcli v0.25.0, toolkit c1efcb3.
+**Proposed target:** `skills/existing-app-change.md` (a "legacy-widget pages" section), a STOP row in
+`skills/learned-mdl-preflight.md`, possibly a `project-bin/` scan once field-proven as a file
+
+---
+
+## What is already covered
+
+- `bug-logs/mxcli-bugs.md` BUG-115 addendum: "Grep a generated script for `NOT re-executable` before
+  executing it" (for the File Manager widget).
+- `bug-logs/mxcli-bugs.md` (the `hasRole()` entry): no MDL syntax writes `ConditionalVisibilitySettings.ModuleRoles`.
+- `skills/learned-mdl-cannot-express.md` (master bda5bed, #277): "A widget visible to one role and not
+  another — nothing", with the execute-grant recipe for action buttons.
+
+## What is not covered (findings)
+
+1. **DESCRIBE does not print module-role visibility.** One portal page had 19 role-locked widgets; DESCRIBE
+   printed none of them (nor a hidden "show page" action behind 9 image widgets). A page restated from that
+   DESCRIBE builds clean and shows every widget to every role.
+2. **A drafted restatement said "the snippet has no visibility rules".** It restated a side-menu snippet
+   from DESCRIBE (navigation-list items have no names, so one item cannot be dropped alone). A BSON audit
+   found 13 role-locked items. Running the draft would have exposed all of them, with a clean build.
+3. **DESCRIBE does not print layout-grid row visibility.** Two form pages had nine detail sections shown
+   by type through row visibility; a snippet had 56 row-level "show only when it has a value" rules. None
+   appear in DESCRIBE. The drafters re-wrote them as container `Visible:` (which DESCRIBE does print and
+   mxcli does write); an audit confirmed every rule was carried over.
+4. **Tab-page `Visible:` and `CaptionParams` are accepted and not written** (see the learned-entries note).
+   Found only by reading the unit back after exec.
+
+So "copy the page from DESCRIBE, edit, `create or replace`" is silently lossy on any app built in Studio Pro.
+
+## Proposed STOP row (learned-mdl-preflight.md)
+
+| # | Operation | Why STOP | Do instead |
+|---|---|---|---|
+| new | Restate an existing page, snippet or layout from `describe` output (`create or replace`, or `alter … replace` of a container) | DESCRIBE omits module-role visibility, layout-grid row/column visibility and legacy-widget internals; check, exec and mxbuild all pass while the rules vanish | Run the visibility scan (below) on the unit first. Zero role locks and zero row rules: go. Otherwise rewrite each rule as container `Visible:` or flow access, or leave the page to `alter page` / Studio Pro |
+
+Probe that falsifies it: in Studio Pro, set one widget visible to one module role and one layout row
+visible on an attribute; `describe page`; grep the output for the role name and the attribute. Today
+(v0.25.0): 0 hits for both.
+
+## The kit (each part was done by hand in the field; none is a toolkit file yet)
+
+1. **BSON visibility scan, per document.** Decode each page/snippet/layout unit under `mprcontents/`
+   (the toolkit's `project-bin/mxunit_bson.py` codec is enough) and count (a) any
+   `ConditionalVisibilitySettings` whose `ModuleRoles` list is non-empty, (b) any
+   `ConditionalVisibilitySettings` on a `Forms$LayoutGridRow` or `Forms$LayoutGridColumn`. Report per
+   document: widget name, kind, roles or attribute. The field scans were inline one-offs, not a saved
+   script; a shipped version needs its own fixture.
+2. **Non-writable count, per document.** `describe` every page, snippet and layout in the app's own
+   modules (Marketplace modules excluded) and count `-- NOT re-executable` lines, grouped by the BSON
+   type in the comment. Field result: `Forms$DropDown` 29, `Forms$ReferenceSelector` 27,
+   `Forms$DataGrid` 16, sign-in widgets 4, `Forms$TemplateGrid` 1, `Forms$ImageUploader` 1,
+   `Forms$SidebarToggleButton` 1.
+3. **Rebuild brief per document.** Inventory first (DESCRIBE plus the scan), then each widget marked
+   KEEP / CUT / MOVED / NEW against the wireframe, then the restatement. Replacements used:
+   drop-down → `combobox` on the enumeration; reference selector → `combobox` on the association (a
+   microflow data source when the filter needs the context object); old data grid → Data grid 2;
+   template grid → `listview`; image uploader → File Uploader in files mode plus a `dynamicimage`;
+   role-only visibility → a per-viewer flag from a data-source microflow, or flow access (Mendix hides a
+   button whose flow the user cannot run). The restating script becomes the document's single owner;
+   older `alter page` blocks on it are marked superseded (compare #269).
+4. **Post-exec read-back.** After each exec: DESCRIBE again (0 `NOT re-executable`), rerun the scan
+   (0 role locks unless intended), and grep the unit for every `Visible:` / `CaptionParams` the script
+   wrote. Item 4 above was caught only this way.
+
+Cost, for scale: six drafting agents in parallel; one gated exec per document (about 5–10 minutes each
+with mxbuild and lint), serial because there is one writer to the `.mpr`.
+
+Upstream asks (mxcli), for the maintainer to file or link: print module-role and row/column visibility in
+DESCRIBE (or at least a `-- role-based visibility not shown (N roles)` comment), accept it on write, give
+navigation-list items stable names, and a legacy-widget migration (`DataGrid` → Data grid 2,
+`ReferenceSelector`/`DropDown` → combobox) behind a dry run.
diff --git a/contrib/inbox/2026-10-13-exec-keeps-write-when-mxbuild-cannot-run.md b/contrib/inbox/2026-10-13-exec-keeps-write-when-mxbuild-cannot-run.md
new file mode 100644
index 00000000..3ebeb7f3
--- /dev/null
+++ b/contrib/inbox/2026-10-13-exec-keeps-write-when-mxbuild-cannot-run.md
@@ -0,0 +1,75 @@
+# exec.sh keeps an MDL write when mxbuild crashes after it, and the next exec runs on an unloadable model
+
+**From:** a field project (anonymised) — an existing Mendix app being changed with mxcli + this toolkit
+**Date:** 2026-10-13
+**Kind:** bug
+**Field evidence:** the project's BUILD-LOG shows two "gate could not run" rows 46 s apart: the
+script that made the model unloadable, then the next script, which exec.sh accepted and ran on top
+of it. Mendix 11.14.0 Beta (Classic client), mxcli v0.25.0, toolkit commit c1efcb3 (`project-bin/exec.sh`
+is byte-identical on master 0c62f6f, blob a03adec).
+**Proposed target:** `project-bin/exec.sh` (gate branch "mxbuild failed to run" and the pre-flight
+"Baseline NOT measured" branch); one line in `skills/iterative-build-loop.md`
+
+---
+
+## What happened (finding, reproduced once in the field)
+
+A page script set a data view's data source to a two-hop association path in its full form
+(`$Parent/MyModule.A_B/MyModule.B/MyModule.B_C/MyModule.C`). `mxcli check` passed. After the
+exec, the mxbuild loader itself crashed instead of reporting CE errors:
+
+```
+An error occurred when trying to set the 'DestinationEntity' property of a Entity ref step in a Page.
+```
+
+exec.sh printed:
+
+```
+  ✗ mxbuild failed to run (exit 1) — gate could not verify the model.
+  → Snapshot preserved. Open in SP to verify manually before proceeding.
+```
+
+and kept the write. It did exit 1 and cleared the verification stamp (good), but the agent driving
+the build ran the next script. exec.sh's pre-flight printed `⚠  Baseline NOT measured: mxbuild exited 1
+without checking the model.`, carried on, applied the next script, and hit the same crash.
+
+BUILD-LOG rows, verbatim except the script names:
+
+```
+| 2026-10-13T12:26:18 | `25g-PageA-rebuild.mdl` | fail | ❌ gate failed | 5 error(s): CE1613 — script rolled back · approval: auto (PROJECT.md) |
+| 2026-10-13T12:28:46 | `25g-PageA-rebuild.mdl` | fail | ❌ gate could not run | mxbuild exit 1 · approval: auto (PROJECT.md) |
+| 2026-10-13T12:29:32 | `25h-SnippetB-rebuild.mdl` | fail | ❌ gate could not run | mxbuild exit 1 · approval: auto (PROJECT.md) |
+```
+
+Recovery: `./bin/restore-mpr.sh <full path to the snapshot taken before 25g>` then
+`./bin/verify-model.sh` (0 errors). The 25h row had to be re-run afterwards.
+
+## Why it matters
+
+- The header comment of exec.sh says an unverified gate is rolled back **for `--patch` only**. That is
+  true and deliberate, but for MDL the "kept" case was designed for "mxbuild could not start"
+  (wrong version, no JDK). Here mxbuild started, ran on the baseline cleanly a minute earlier, and
+  crashed only on the written model. That is a property of the write, not of the machine.
+- The next exec has no way to tell the two apart: "Baseline NOT measured" is a warning, not a refusal.
+  So in an unattended chain the damage compounds: every following script is written onto a model
+  nothing can load, and each one gets its own snapshot of the broken state.
+
+## Proposed fix (hypothesis, not built)
+
+1. **Restore when mxbuild ran clean on the baseline but cannot run after the write.** exec.sh already
+   has both facts: the pre-flight measured a baseline (`BASE_KNOWN=1`) and the post-exec run exits
+   non-zero with no errors file. In that case, call `restore_snapshot` exactly as the `--patch` path
+   does, and log `↩ rolled back: mxbuild crashed on the written model`. Keep today's behaviour when the
+   baseline itself was not measured (that is the real "machine cannot build" case).
+2. **Refuse a write when the baseline cannot be measured** and the last BUILD-LOG row for this model
+   is `gate could not run`, with one STOP line naming `bin/restore-mpr.sh` and the snapshot to restore.
+   `ALLOW_UNVERIFIED=1` stays the explicit override.
+3. Reword the kept-write message: "Open in SP to verify" is not something an agent can do. Something
+   like `STOP: the model may not load. Restore with ./bin/restore-mpr.sh <snapshot path>` is actionable.
+
+Probe that would falsify the claim (for the retest fixture): a fake mxbuild that exits 0 on the
+baseline and exits 1 with no errors file after the exec; today exec.sh exits 1 and leaves the
+written model in place; after the fix the model on disk equals the snapshot.
+
+Related: `--patch` already restores on an unverified gate (header lines 25–29); PR #304 touches the
+same file (per-project lock) but not this branch.
diff --git a/contrib/inbox/2026-10-13-exec-raw-guard-blocks-other-projects-mxcli-test.md b/contrib/inbox/2026-10-13-exec-raw-guard-blocks-other-projects-mxcli-test.md
new file mode 100644
index 00000000..1f4183ae
--- /dev/null
+++ b/contrib/inbox/2026-10-13-exec-raw-guard-blocks-other-projects-mxcli-test.md
@@ -0,0 +1,39 @@
+# Field confirmation of #228 case 3: another project's `mxcli test` blocks exec.sh
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-13
+**Kind:** bug
+**Field evidence:** on 2026-10-13 a `mxcli test` run in a second toolkit project on the same machine
+(writing only to that project's own `.mpr`) made this project's `bin/exec.sh` refuse a page script;
+it recurred several times that day. Toolkit commit c1efcb3; `project-bin/exec.sh` is unchanged on
+master 0c62f6f.
+**Proposed target:** `project-bin/exec.sh` step 3 — already addressed by open PR #257 (and the
+per-project lock in open PR #304). This note is evidence for those PRs, not a new design.
+
+---
+
+Issue #228 lists three false positives of the raw-exec guard
+
+```bash
+if pgrep -fl "mxcli exec" 2>/dev/null | grep -qv "$$"; then
+  echo "✗ A raw 'mxcli exec' is already running elsewhere — refusing to write concurrently."
+```
+
+and says of case 3 ("another project's `mxcli test` execs temp scripts"): *"This one has not been
+independently verified."* This project verified it:
+
+- Project B (a separate app, separate folder, separate `.mpr`) was running `mxcli test` against its own
+  model. `mxcli test` adds and removes its `MxTest` microflows through `mxcli exec`, so its process
+  list contains the substring.
+- In project A, `./bin/exec.sh mdlsource/3-module/03a-....mdl` refused with the message above and
+  wrote nothing. Waiting for B's test run to finish and re-running A's exec applied cleanly.
+- As #228 says, nothing reached A's BUILD-LOG: the guard exits before `log_build`, so the only trace is
+  the agent transcript. That is why this note has no BUILD-LOG row to quote.
+
+Two projects cannot share one `.mpr`, so the cross-project refusal protects nothing. #228's acceptance
+check "`mxcli test --local` running in project B does not block A" is the right test; this is one
+field case for it.
+
+Workaround until #257 or #304 merges: wait for the other project's process to end. `FORCE_EXEC=1`
+also passes the guard, but it skips the Studio Pro and uncommitted-model refusals too, so it is not
+a safe workaround.
diff --git a/contrib/inbox/2026-10-13-learned-widgets-and-data-sources.md b/contrib/inbox/2026-10-13-learned-widgets-and-data-sources.md
new file mode 100644
index 00000000..e5d7d710
--- /dev/null
+++ b/contrib/inbox/2026-10-13-learned-widgets-and-data-sources.md
@@ -0,0 +1,135 @@
+# Learned entries from a legacy-widget rebuild: File Uploader image mode, native-mapped keywords, tab pages, XPath comparands, multi-hop data sources
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-13
+**Kind:** learning
+**Field evidence:** each entry below was hit while restating 34 pages of an existing app, through
+`bin/exec.sh` (mxbuild delta gate) on mxcli v0.25.0, Mendix 11.14.0 Beta, Classic (Dojo) client,
+toolkit c1efcb3. Error texts are verbatim; module/entity names are genericised.
+**Proposed target:** per entry below (`skills/learned-file-upload-widget.md`,
+`skills/learned-mdl-cannot-express.md`, `skills/learned-page-patterns.md`, `bug-logs/mxcli-bugs.md`)
+
+---
+
+## 1. File Uploader: image mode fails the build; files mode against a `System.Image` subtype works
+
+Target: `skills/learned-file-upload-widget.md` §7 ("Image mode … was not tested").
+Status: files mode is ALREADY covered there (PR #139); this adds image mode and the image-preview pattern.
+
+```sql
+fileuploader upPictures (
+  uploadMode: 'images',
+  associatedImages: association $currentObject/MyModule.Picture_Asset,
+  readOnlyMode: true,
+  enableCustomButtons: false
+)
+```
+
+`mxcli check` passed. mxbuild: `CE0463 The definition of this widget has changed.` on
+`File uploader upPictures`; the gate rolled back (rollback verified by DESCRIBE). The same widget with
+`uploadMode: 'files'` builds clean (finding).
+
+What built clean instead (finding, mxbuild 0 errors): uploads in **files** mode against an entity that
+extends `System.Image` (which extends `FileDocument`), with a separate `dynamicimage` preview beside it;
+read-only picture lists as a `listview` whose template holds a `dynamicimage`.
+
+Also stale: `skills/learned-mdl-cannot-express.md` row 1 still says "A file upload control — nothing …
+⛔ not buildable", which contradicts `learned-file-upload-widget.md`. Suggest pointing that row at the
+File Uploader skill.
+
+Related (finding): the installed FileDropper widget's definition lists `dataFileEntity` and
+`dataContextAssociation` as known properties with no mapping; `check` accepts them, exec does not write
+them, and mxbuild then fails. Upstream ask: refuse unmapped definition properties with MDL-WIDGET07.
+
+## 2. `radiobuttons` and `image` can resolve to NATIVE mobile widgets on a web page
+
+Target: `skills/learned-page-patterns.md` (or the widgets section of `learned-mdl-cannot-express.md`).
+Status: NEW (no toolkit mention).
+
+In this project `DESCRIBE WIDGET TYPE radiobuttons` resolves to `com.mendix.widget.native.radiobuttons`,
+and `check` warns MDL-WIDGET10 that the label is dropped. The project's `image.def.json` maps `image` to
+`com.mendix.widget.native.image.Image`; a probe wrote `image` with no properties. DESCRIBE prints existing
+**web** radio groups with the same `radiobuttons` keyword, so re-running DESCRIBE output writes a native
+widget into a web page (finding for the resolution and the warning; the radiobuttons case was not taken
+through mxbuild).
+
+Rule used: Boolean → `checkbox`, enumeration → `combobox`, images → `dynamicimage`. Before relying on a
+keyword in an existing app, run `DESCRIBE WIDGET TYPE <keyword>` and check the id is a `web` widget.
+
+## 3. Tab pages: `CaptionParams` and `Visible:` pass every gate and are not written
+
+Target: `bug-logs/mxcli-bugs.md` as `## BUG-DRAFT-tabpage-captionparams-visible-dropped:`, plus a row in
+`learned-mdl-cannot-express.md` next to the existing "count badge on a tab" row.
+Status: NEW. (The existing row covers `Badge:`, which `check` refuses; these two are accepted.)
+
+```sql
+tabpage tpDue (Caption: 'Due today or earlier · {1}', CaptionParams: ({1} = DueCount)) { … }
+tabpage tpOther (Caption: 'Unassigned · {1}', Visible: $currentObject/ShowOtherTab) { … }
+```
+
+`check`, exec and mxbuild all passed, with no MDL-WIDGET07. The stored caption is literal text (the tab
+reads `· {1}`), and the tab page has no visibility setting: `ShowOtherTab` occurs 0 times in the unit.
+Found by a BSON read-back after exec (finding).
+
+Rule: no dynamic captions and no visibility on tab pages; put the count in a line inside the tab, and
+put anything conditional in a container with `Visible:` (container visibility is written correctly).
+
+## 4. DESCRIBE omits module-role visibility and layout-grid row visibility
+
+Target and detail: see the inbox note "Durable rebuild of legacy-widget pages" (same date). Listed
+here so triage sees it among the learned entries. Status: PARTLY (role visibility is known to be
+unwritable; that DESCRIBE also hides it is not recorded).
+
+## 5. Page XPath with a `$currentObject/<association>` comparand → CE0161 (BUG-39 on widgets)
+
+Target: `bug-logs/mxcli-bugs.md` BUG-39 (add a confirmation), `learned-page-patterns.md`.
+Status: PARTLY. BUG-39 records it for microflow retrieves only.
+
+```sql
+combobox cbLevel2 (
+  Attribute: Helper_Level2,
+  DataSource: database from "MyModule"."Level2"
+    where [MyModule.Level2_Level1 = $currentObject/MyModule.Helper_Level1]
+)
+```
+
+`check --references` passed; mxbuild: 3 × `CE0161 Error(s) in XPath constraint`, one per cascading combo
+box; rolled back (finding). Studio Pro accepts the same constraint.
+
+Workaround that built: each combo box takes its options from a microflow data source that retrieves the
+parent into a variable and filters on it.
+
+## 6. Two-hop association data source: neither path form is writable → use a microflow data source
+
+Target: `learned-page-patterns.md` (next to the BUG-04 multi-hop ContentParams section), and
+`bug-logs/mxcli-bugs.md` as `## BUG-DRAFT-two-hop-datasource-path:`.
+Status: NEW. BUG-20 (cross-module traversal writing a null `DestinationEntityId`) was fixed in v0.17.0;
+this is a same-module, two-hop path on v0.25.0.
+
+Short form, exactly as DESCRIBE prints it:
+
+```sql
+DataSource: $Parent/MyModule.A_B/MyModule.B_C
+```
+
+mxcli stored the last segment as an entity:
+`CE1613 The selected entity 'MyModule.B_C' no longer exists.` (5 errors); rolled back.
+
+Full form:
+
+```sql
+DataSource: $Parent/MyModule.A_B/MyModule.B/MyModule.B_C/MyModule.C
+```
+
+`check` passed; the mxbuild loader crashed:
+`An error occurred when trying to set the 'DestinationEntity' property of a Entity ref step in a Page.`
+(This crash is what exposed the exec.sh gap in the separate inbox note.)
+
+So DESCRIBE output containing such a path is not re-executable. Rule: no multi-hop association path as a
+data-view source; use a microflow data source that retrieves over each association in turn (built clean).
+
+## Not included here
+
+Other cases from the same run (Data grid 2 custom-content column losing its Attribute; XPath through a
+reverse association needing read access mxbuild does not check; names `check --references` does not
+validate) are upstream mxcli material and are left for a separate note.
diff --git a/contrib/inbox/2026-10-13-patch-unit-row-delete-orphan.md b/contrib/inbox/2026-10-13-patch-unit-row-delete-orphan.md
new file mode 100644
index 00000000..9355c51b
--- /dev/null
+++ b/contrib/inbox/2026-10-13-patch-unit-row-delete-orphan.md
@@ -0,0 +1,43 @@
+# exec.sh --patch: deleting a Unit row is refused by `mxcli fix hashes --repair` (ORPHAN file); rename-then-drop is the route that works
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-12
+**Kind:** learning
+**Field evidence:** two pages with the same qualified name (a live one and an excluded, archived copy in
+another folder). mxcli v0.25.0, Mendix 11.14.0 Beta, MPR v2, toolkit c1efcb3. The failed patch was
+rolled back by exec.sh; the second route built at 0 errors.
+**Proposed target:** `skills/learned-mdl-preflight.md` (a workaround row) or `skills/learned-mdl-cannot-express.md`;
+an upstream mxcli ask
+
+---
+
+## Situation
+
+`MyModule.Detail` existed twice: the live page and an archived copy (excluded from the project) with
+the same name in `Archive/Pages`. mxcli addresses documents by qualified name only, and different
+commands resolved the name to different copies: `DESCRIBE PAGE` found the live one, `SHOW ACCESS ON PAGE`
+the archived one, so a `grant view` by name landed on the archived copy. There is no `drop page … in
+folder '…'` and no drop by unit id.
+
+## Route 1, refused (finding)
+
+A gated patch through `./bin/exec.sh --patch` deleted the archived page's row from the `.mpr` `Unit`
+table and left its `.mxunit` file on disk (file removal being left to the owner). The patch's
+`mxcli fix hashes --repair` step then reported the file as **ORPHAN** (present on disk, not indexed)
+and failed; exec.sh restored the snapshot. Afterwards both pages were present and 3161 units verified.
+
+## Route 2, worked (finding)
+
+1. A gated patch renamed only the archived unit's top-level `Name` to `Detail_Archived`, after a
+   byte-identical decode/encode round-trip check of that unit. mxbuild stayed at 0 errors.
+2. Then plain MDL, through exec.sh: `drop page if exists "MyModule"."Detail_Archived";`
+
+## Rule proposed
+
+To remove one of two same-named documents: rename it by patch, then drop it by MDL. Never delete a
+`Unit` row by hand; `fix hashes --repair` treats the leftover file as an orphan and the gate rolls back.
+
+Ask for upstream mxcli: warn when a qualified name resolves to more than one document, make every
+command resolve it the same way, and add `drop page … in folder '…'` or a drop by unit id.
+
+Related, not the same: #294 (a shared patch helper) and #295 (adopt `mxcli fix hashes` in `--patch`).
diff --git a/contrib/inbox/2026-10-13-restore-mpr-usage-says-timestamp.md b/contrib/inbox/2026-10-13-restore-mpr-usage-says-timestamp.md
new file mode 100644
index 00000000..cec7a935
--- /dev/null
+++ b/contrib/inbox/2026-10-13-restore-mpr-usage-says-timestamp.md
@@ -0,0 +1,61 @@
+# restore-mpr.sh: usage says `[timestamp]`, but a bare timestamp is refused; it needs the snapshot's full path
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-13
+**Kind:** bug
+**Field evidence:** hit during recovery from an mxbuild crash (see the inbox note "exec.sh keeps an
+MDL write when mxbuild crashes"); reproduced afterwards on a scratch project with the toolkit's
+`project-bin/restore-mpr.sh` (blob c7ae37b, identical at c1efcb3 and on master 0c62f6f).
+**Proposed target:** `project-bin/restore-mpr.sh`
+
+---
+
+## What happens (finding, reproduced)
+
+The header says:
+
+```
+# Usage: ./bin/restore-mpr.sh [timestamp]    (defaults to the newest snapshot)
+```
+
+`snapshot-mpr.sh` names snapshots by timestamp (`.mpr-snapshots/20261013-120000/`), so the natural
+call is the folder name. On a scratch project with exactly that snapshot:
+
+```
+$ ./bin/restore-mpr.sh 20261013-120000
+ERROR: snapshot 20261013-120000 is missing App.mpr
+exit=1
+```
+
+The full path works:
+
+```
+$ ./bin/restore-mpr.sh /path/to/project/.mpr-snapshots/20261013-120000/
+Restoring from: /path/to/project/.mpr-snapshots/20261013-120000/
+  Restored: App.mpr
+  Restored: mprcontents/ (1 units verified)
+Restore complete. Verify with: ./mxcli docker check -p App.mpr --no-update-widgets
+```
+
+Cause (code reading): `SNAP="${1:-...}"` is used as given, after `cd "$MODEL_DIR"`. A bare name is
+therefore looked up relative to the model directory, not under `$SNAP_DIR`. A relative path such as
+`.mpr-snapshots/<ts>` works only when the model directory is the project root, so on a two-tree
+checkout (`app/` holding the `.mpr`) it fails too (that part is a hypothesis, not tested).
+
+The error message is also misleading: it says the snapshot is *missing the .mpr*, which sends you to
+inspect a healthy snapshot instead of fixing the argument. In a recovery, under pressure, that cost
+a few minutes.
+
+## Proposed fix
+
+```bash
+SNAP="${1:-$(ls -dt "$SNAP_DIR"/*/ 2>/dev/null | head -1)}"
+# accept a bare timestamp or a path relative to the caller
+[ -n "${1:-}" ] && [ ! -d "$SNAP" ] && [ -d "$SNAP_DIR/$1" ] && SNAP="$SNAP_DIR/$1"
+```
+
+(resolve a caller-relative path before the `cd`, as exec.sh does for its script argument), and make
+the usage line say `[timestamp | snapshot path]`. When the argument resolves to no directory at all,
+say `no snapshot named <arg> in $SNAP_DIR` and list the three newest.
+
+Retest: the two commands above on a scratch project. Today: exit 1 and exit 0. After: exit 0 and exit 0.
diff --git a/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md b/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md
new file mode 100644
index 00000000..a696d5fe
--- /dev/null
+++ b/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md
@@ -0,0 +1,55 @@
+# `mxcli run --local --test-endpoint` stopped by a signal leaves AfterStartupMicroflow on the injected flow (second field case for #244, and the toolkit-side half)
+
+**From:** a field project (anonymised)
+**Date:** 2026-10-13
+**Kind:** bug
+**Field evidence:** an agent stopped a running `mxcli run --local --test-endpoint` (a background-task
+stop, so a signal, not a clean exit) to restart the app. Later a clean-up removed the injected
+`MxTest` module but not the setting; exec.sh's pre-flight then reported the model "ALREADY has 1 error"
+(CE1613), and the next app start recursed with a StackOverflowError in `MxTest.RegisterEndpoint`.
+mxcli v0.25.0, Mendix 11.14.0 Beta, toolkit c1efcb3.
+**Proposed target:** upstream mxcli for the root cause (already logged here as #244, open); in the
+toolkit, `skills/testing-shape.md` (the `--test-endpoint` paragraph) and an exec.sh pre-flight hint
+
+---
+
+## What is already covered
+
+- #244 (open) describes the same family on mxcli v0.25.0 / Mendix 11.15.0: the wrapper chains the
+  "current" after-startup flow, which is already `MxTest.RegisterEndpoint`, so it calls itself. It
+  asks upstream to restore on interrupt and to refuse a self-wrap.
+- `skills/testing-shape.md` says `--test-endpoint` writes into the working model while the app runs and
+  that "a clean stop prints 'test endpoint removed; project restored'". It does not say that a stop by
+  signal skips that restore.
+
+## What this case adds
+
+1. **Trigger is a signal stop of `run --test-endpoint` itself**, not an interrupted `mxcli test` run.
+   Agents routinely stop background tasks this way to restart an app.
+2. **A partial clean-up makes it worse.** Removing the `MxTest` module afterwards (by hand or by a later
+   cleanup) leaves `AfterStartupMicroflow` pointing at a flow that no longer exists: CE1613 at build,
+   which exec.sh's delta gate then carries as a "pre-existing" error on every later script. Re-creating
+   it by starting with `--test-endpoint` again gives the self-recursion from #244.
+3. **The repair that worked**, run through `bin/exec.sh` (a STOP-table `ALTER SETTINGS`, said in chat):
+
+   ```sql
+   mdl 1;
+   alter settings runtime (AfterStartupMicroflow: 'MyModule.ASU_Startup');
+   ```
+
+   mxbuild went back to 0 errors; the app then started normally.
+
+## Proposed toolkit changes (hypothesis, not built)
+
+- `testing-shape.md`: add "Stop `run --test-endpoint` with Ctrl+C in its own terminal or let it exit;
+  a kill or task stop skips the restore. Afterwards `git status` on the model must be empty; if the
+  Settings unit is still modified, restore it from git (or with the `alter settings runtime` line
+  above) before any exec." Run build-time apps without `--test-endpoint` (the skill already says so).
+- `exec.sh` pre-flight: when the baseline holds CE1613 on the project Settings, or `describe settings`
+  shows `AfterStartupMicroflow` starting with `MxTest.`, print one line naming the cause and the repair,
+  instead of only "Model ALREADY has 1 error(s)".
+- Upstream (#244): restore the original after-startup on SIGTERM/SIGINT too, and refuse to wrap an
+  after-startup that is already `MxTest.RegisterEndpoint`.
+
+Probe: start `mxcli run --local --test-endpoint` on a scratch copy, stop it with `kill -TERM <pid>`,
+then `describe settings`. Today (v0.25.0): after-startup is still `MxTest.RegisterEndpoint`.

From 8400885addd148874953a66a8f2e7f18e9e36188 Mon Sep 17 00:00:00 2001
From: MendixMau <mauritscgvisser@gmail.com>
Date: Fri, 16 Oct 2026 10:59:14 +0800
Subject: [PATCH 2/2] inbox: mark #244 closed, drop retired STOP-table wording

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 ...10-13-test-endpoint-after-startup-left-after-signal.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md b/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md
index a8dd769e..91d26f81 100644
--- a/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md
+++ b/contrib/inbox/2026-10-13-test-endpoint-after-startup-left-after-signal.md
@@ -8,15 +8,15 @@ stop, so a signal, not a clean exit) to restart the app. Later a clean-up remove
 `MxTest` module but not the setting; exec.sh's pre-flight then reported the model "ALREADY has 1 error"
 (CE1613), and the next app start recursed with a StackOverflowError in `MxTest.RegisterEndpoint`.
 mxcli v0.25.0, Mendix 11.14.0 Beta, toolkit c1efcb3.
-**Proposed target:** upstream mxcli for the root cause (already logged here as #244, open); in the
+**Proposed target:** upstream mxcli for the root cause (already logged here as #244, closed 2026-10-14 after the toolkit refusal landed in the integration PR #329; the upstream root cause remains); in the
 toolkit, `skills/testing-shape.md` (the `--test-endpoint` paragraph) and an exec.sh pre-flight hint
 
-**Currency check:** 2026-10-16 against master d1cbd41: partly stale. exec.sh's pre-flight now refuses on a leftover injected setting and prints the `ALTER SETTINGS` repair (`_common.sh`), so the exec.sh hint half is done. Still open: #244 upstream, and `skills/testing-shape.md` does not say that a stop by signal skips the restore.
+**Currency check:** 2026-10-16 against master d1cbd41: partly stale. exec.sh's pre-flight now refuses on a leftover injected setting and prints the `ALTER SETTINGS` repair (`_common.sh`), so the exec.sh hint half is done. Still open: the upstream root cause behind #244 (closed 2026-10-14 once the toolkit refusal landed), and `skills/testing-shape.md` does not say that a stop by signal skips the restore.
 ---
 
 ## What is already covered
 
-- #244 (open) describes the same family on mxcli v0.25.0 / Mendix 11.15.0: the wrapper chains the
+- #244 (closed 2026-10-14; the toolkit refusal landed in #329, the upstream root cause remains) describes the same family on mxcli v0.25.0 / Mendix 11.15.0: the wrapper chains the
   "current" after-startup flow, which is already `MxTest.RegisterEndpoint`, so it calls itself. It
   asks upstream to restore on interrupt and to refuse a self-wrap.
 - `skills/testing-shape.md` says `--test-endpoint` writes into the working model while the app runs and
@@ -31,7 +31,7 @@ toolkit, `skills/testing-shape.md` (the `--test-endpoint` paragraph) and an exec
    cleanup) leaves `AfterStartupMicroflow` pointing at a flow that no longer exists: CE1613 at build,
    which exec.sh's delta gate then carries as a "pre-existing" error on every later script. Re-creating
    it by starting with `--test-endpoint` again gives the self-recursion from #244.
-3. **The repair that worked**, run through `bin/exec.sh` (a STOP-table `ALTER SETTINGS`, said in chat):
+3. **The repair that worked**, run through `bin/exec.sh` (an `ALTER SETTINGS`, said in chat):
 
    ```sql
    mdl 1;