Sync ako/mxcli: describe performance and round-trips on MPR v1, git notes, test --db-type

.claude/skills/fix-issue/findings/cmd-mxcli.jsonl

@@ -168,3 +168,6 @@
 {"area": "cmd/mxcli", "date": "2026-10-05", "symptom": "`mxcli run --local --watch`: a model change made while the app is still booting is never built — the app keeps serving the model from before it, `--watch` logs no `Change detected`, and a waiter on the change times out. Re-running the exec does nothing (byte-idempotent: it writes nothing, so nothing re-triggers the watcher)", "cause": "watchAndApply took its baseline `last := sourceMTime(...)` after the boot finished, so an edit landing between the boot build's model read and the watch loop's start was already folded into the baseline", "file": "`cmd/mxcli/docker/runlocal.go` (`RunLocal` bootSource, `watchAndApply`)", "insight": "A watcher's baseline must be the source time the last build was MADE FROM, taken before that build — not 'now' when the watcher starts. Same class as the earlier fix that stopped moving the baseline to time.Now() after an apply. Measured with the run-lifecycle integration test: exec a page while the detached run's state says the boot build is in progress; with the old baseline `run wait` times out after 2m (no build #2), with the fix it reports `applied: build #2 via reload`. Exposed by making `run wait` race-free on source time: a generation-counting wait could not have told the change was lost.", "refs": ["cmd_run_lifecycle_integration_test.go"]}
 {"area": "cmd/mxcli", "date": "2026-10-06", "symptom": "`mxcli run --local --watch` on Mendix 10.24 / 11.6 dies after 5 minutes with `starting web client bundler: web client watcher timed out after 5m0s`, while the bundler's own log says `Bundling finished in 8999 milliseconds` — the bundle was done in 9s", "cause": "`parseBundlerStatus` (`cmd/mxcli/docker/webclient_watch.go`) only understood the modern-web-bundler protocol (`{\"protocol\":\"mx-modern-web-bundler\",\"type\":\"status\",\"payload\":{\"kind\":…}}`). The rollup-runner.mjs shipped with 10.24 and 11.6 predates it and writes `{\"code\":\"START\"|\"SUCCESS\"|\"ERROR\",\"payload\":…}` (ERROR payload an object with `message`, or a bare string when the config fails to load). Every status line was dropped as plain logging, so the first-build wait never saw a success", "file": "cmd/mxcli/docker/webclient_watch.go", "insight": "--watch had never worked on these versions: the parser has accepted only the new protocol since it was written (#349). Nothing exercised the watcher below 11.12 until the run-lifecycle integration test reached the nightly matrix — and it reached it only because ResolveMxForVersion substitutes ANY cached mxbuild for the test's default 11.13.0, so each matrix leg ran it against its own version. The runner's protocol is part of the mxbuild version contract: read tools/node/rollup-runner.mjs of the oldest supported version before assuming a stdout shape. Control: the lifecycle test on 11.6.8 with the parser reverted fails with the nightly's exact timeout (MXCLI_WEB_CLIENT_TIMEOUT=60s makes it fail in a minute); with the fix it passes", "refs": ["nightly 2026-10-06 (ako/mxcli run 37437089065, mendixlabs/mxcli run 37437605368)"]}
 {"area": "cmd/mxcli", "date": "2026-10-06", "symptom": "`mxcli syntax rename` printed `Unknown topic: rename` and `mxcli syntax --json` had rename only for attributes, values and definitions, while `RENAME MICROFLOW <qn> TO <name>;` passed `mxcli check` and `mxcli help rename` documented it; an agent concluded MDL could not rename a microflow and copied, re-pointed and deleted it by hand", "cause": "The renameStatement rule (MDLParser.g4) and its executor (mdl/executor/cmd_rename.go) never got a SyntaxFeature in cmd/mxcli/syntax/; the only discovery path was the cobra `rename` subcommand's Long text, which `syntax` does not read. BySegmentMatch could not rescue it because no registered path has a `rename` segment", "file": "cmd/mxcli/syntax/features_misc.go", "insight": "Same class as the TABCONTAINER gap (widget_keywords_drift_test.go): an agent treats absence from `mxcli syntax` as absence from the language, so a statement the grammar accepts but the registry omits is effectively missing. Fixed with a `rename` topic plus a guard (rename_topic_test.go) that reads the renameTarget rule from the .g4 and requires every alternative in the topic, and see_also links from microflow/page/entity/move. The CLI subcommand and the MDL statement diverge (MDL also takes JAVA ACTION and WORKFLOW); the topic says so rather than implying parity. Control: with the topic reverted the built binary prints `Unknown topic: rename` verbatim and TestSyntaxRenameTopic fails; dropping the RENAME WORKFLOW line fails the grammar guard. A sweep for other top-level statements with no topic would be the cheap next step", "refs": ["mendixlabs/mxcli#1318"]}
+{"area": "cmd/mxcli", "date": "2026-10-08", "symptom": "Main's build-and-test fails intermittently in the run-lifecycle tests, several at once in one run and green on the next: TestRunStop_LeavesNoOrphanBehind (\"fake run has 0 session members, want the leader and its child\"), TestRunStop_ReapsTheLeftoversOfAKilledRun, TestSessionMembers_FindsOrphanedGrandchild (\"members … = [<the sleep>], want the leader and its sleep\"). Not reproducible locally (20/20 green). In real use the same path makes `run stop` / `run status` miss a live run's processes.", "cause": "docker.SessionMembers' pid-reuse guard rebuilt a process's start time as btime + starttime/USER_HZ and dropped it if that fell more than 1s before notBefore. btime in /proc/stat is whole seconds (up to 1s early) and starttime whole 10ms ticks (up to 10ms early), so the rebuild can be ~1.01s early: a process started a few ms after notBefore was dropped. frac(btime) is fixed for a machine's uptime, so a CI VM booted late in a second failed every such test in the run, and others never did; a process started a few ms later (the leader's sleep) survived.", "file": "`cmd/mxcli/docker/session_linux.go` (`startedBefore`, `startSlack` = 2s)", "insight": "A flake that fails a whole family of tests in one run and none in the next points at per-machine state, not timing within the test: here the fractional second of the VM's boot. Make the comparison a pure function and pin the worst case (boot at X.9999, start 9.9ms into a tick, 1ms after notBefore); the test then fails deterministically against the old slack. Rebuilding a wall-clock time from btime + ticks loses up to 1s + 1 tick; any slack must exceed both.", "refs": ["https://github.com/ako/mxcli/actions/runs/37733157296", "https://github.com/ako/mxcli/actions/runs/37688181946"]}
+{"area": "cmd/mxcli", "date": "2026-10-08", "symptom": "`mxcli test --local` had no --db-type, so on a machine without PostgreSQL it stopped with \"Error: ensuring database: no local PostgreSQL superuser available to create the role/database\" while `run --local --db-type hsqldb` served the same project. Passing the type through naively then failed with \"database not reachable at 127.0.0.1:5432\".", "cause": "The headless boot (docker.LocalAppOptions) never learned the file database: applyDefaults filled PostgreSQL's host/user/password into every config, StartLocalApp pinged that host, and testrunner hardcoded EnsureDB=true. run --local had the file-database branches in its own applyDatabaseDefaults/StartLocalRun, a second boot path that the test runner does not use. DBConfig.IsFileBased keys on the runtime spelling \"HSQLDB\", so the canonical \"hsqldb\" passed straight through also silently skipped every file-based branch.", "file": "`cmd/mxcli/docker/localapp.go` (`applyDefaults`, `prepareLocalAppDatabase`), `cmd/mxcli/testrunner/localapp_options.go` (`dbConfig`, `ResolveTestDBType`), `cmd/mxcli/cmd_test_run.go`", "insight": "Two boot paths (StartLocalRun for run --local, StartLocalApp for test --local) each own their database defaults, so a capability added to one is absent from the other until someone asks; grep both when adding a database option. Keep the _test scratch suffix for HSQLDB as well: the name selects the database files under deployment/data/database/hsqldb/, and the unsuffixed ones are the dev loop's (shared data + HSQLDB file lock). A test that asserts EnsureDB is refused must match the refusal's message: EnsureDatabase itself fails on a host without PostgreSQL, which passes an err != nil check for the wrong reason.", "refs": ["https://github.com/mendixlabs/mxcli/pull/1274", "https://github.com/mendixlabs/mxcli/issues/1292"]}
+{"area": "cmd/mxcli", "date": "2026-10-08", "symptom": "Studio Pro (11.12/11.13) shows conflicts the change pane does not show, history entries with BranchName/ModelerVersion \"(unknown)\", and crashes on open (\"Unable to find 'system' property in 'system'\") after an agent committed and branched with plain git on a Team Server project", "cause": "Studio Pro keeps per-commit metadata in git notes under refs/notes/mx_metadata (written on every Studio Pro commit, pushed with it); git commits had none, so Studio Pro 11.13 back-fills a placeholder (HasModelerVersion:false) for each after every background fetch (~3 min), and that fetch force-replaces the local notes ref, discarding notes an agent wrote but did not push. Branches made with git checkout -b have no upstream (ako/mxcli#972).", "file": "cmd/mxcli/gitnote.go", "fix": "`mxcli git note` computes the note from the commit (the .mpr Unit index + mprcontents at commit and parent, canon.Equal to skip $ID-only churn, a deleted module listed once, Moved from a container change, the project root listed on a version change); the teamserver-git skill teaches server branches and pushing refs/notes/mx_metadata with the branch.", "insight": "The ground truth was in the user's own repository, not in any doc: `git log refs/notes/mx_metadata` separates Studio Pro's notes (libgit2 'git_note_create', or the git CLI in 11.13 within a second of a host-timezone commit) from agent ones, and the notes reflog shows the 3-minute fetch-and-backfill cycle. Comparing a generator against those notes commit by commit settled every rule; an ordinary commit must match exactly, and the only residual difference is upgrade commits, where Studio Pro also records names from its editing session (a rename before commit) that no diff can recover.", "refs": ["mendixlabs/mxcli#1337", "ako/mxcli#972"]}