new(entry modes): wire "Change an existing app" as the fourth pipeline entry mode; Windows test-run prompt

CHANGELOG.md

@@ -16,6 +16,8 @@ three commits past it), and a bug report can name a release instead of a sha nob
 Sections dated before 2026-09-19 predate the cycle and stay as they are.
 
 ## Unreleased
+- docs(front door): **README and `toolkit-guide.html` now count five ways in, not three.** Both already listed migration, requirements-driven, greenfield and the à-la-carte no-pipeline route; only the headlines said "three", so sessions reading the headline reported three entry modes while the runbook and `CLAUDE.md` said three plus à-la-carte. Wording now: four pipeline entry modes plus one route with no pipeline — Maurits Visser
+- docs(testing): **Windows full test-run prompt.** `docs/windows-test-run.md` — a paste-able, unattended Claude Code prompt for a Git Bash machine: guards, both fixture suites, 27 Windows-relevant fixtures with their subjects, the committed inputs (`fixtures/app-analysis`, page-fidelity mocks, html-to-md capture) run directly, and a field run on a scratch copy of a real project incl. the two-tree and toolkit.env probes; one results file, facts only — Maurits Visser
 - learn(eval install run, UPSTREAM-PR.md): **the "could we change the CLI?" question answered with a built, tested, field-run PR rather than an estimate** — `marketplace install --file <package.mpk>` on a shallow clone of the upstream repo, following its own CONTRIBUTING and PR checklist (test first, verify at the symptom's layer, prove by revert, record a finding). Eight unit tests with the marketplace client factory fatal-if-called, one integration test against a real package, lint and the full test tree green. The field run with real packages found a **pre-existing bug**: with a relative `-p app.mpr` the install writer refused every bundled file as path traversal after the module was already transplanted — fixed as a separate commit, test shown failing first. Two integration-test failures were my own test bugs (temp HOME hiding the mxbuild cache; return operands read before the command ran), each misread as a product failure for one round. Not submitted (repo unreachable from this session); patches, PR body and submission recipe staged in the private repo. — Maurits Visser
 - learn(eval install run, FORK-OR-PR.md): **"could we fork the CLI and add this?" — you could (Apache 2.0), but you should not need to: the install core is already decoupled from the marketplace.** Read from a shallow clone: `PackageProject`, `PerformInstall`, `InstallPackageFiles` and `moduleNameFromMpk` all take plain paths and strings — no client, no version struct, no token — and `InstallPackageFiles` already unzips exactly the bundled trees (widgets, themesource, styling, design properties) that had to be copied by hand. The only marketplace-specific work is resolving a content id and downloading to a temp path. So a file input is a small upstream change, not a fork; the one real design question is what the version stamp should record for a package from disk. Recommendation recorded: issue with sizing, then offer the PR, ship a wrapper script meanwhile, and fork only if upstream declines — the same overlay-not-fork argument this toolkit made for the company brain. Estimate labelled as read-from-call-graph, not a built patch. — Maurits Visser
 - learn(eval install run): **"could the CLI solve it in theory?" — it solves it in practice, proven end to end headless, and the earlier "blocked" verdict was about `mx`, not about the CLI as a whole.** Two probes: mxcli reads the **10.6.4** model fine (`SHOW MODULES`, exit 0) where `mx module-import` and `mx convert` at 11.14 both refuse it, so the version gate is `mx`'s alone; and the theme module carries **zero model documents**, so installing it is a file operation, not a model import. Copying `themesource/` + `widgets/` builds clean — **and silently applies none of the brand colours**, because the module's `main.scss` imports the *project's* `theme/web/custom-variables` while the file holding every USI value ships as `usi-custom-variables.scss` and is imported by nothing. A green build with the wrong palette: the false-green class this toolkit tracks. With that one extra copy the build succeeds and all five brand hexes are verified in the compiled CSS. Cost stated: the swap overwrites the project's existing theme, so on a non-greenfield app it is a merge. — Maurits Visser

CLAUDE.md

@@ -2,7 +2,7 @@
 
 ## What this repo is
 Shared skills, stage-gate tooling, and learnings for **Mendix migration and development projects**.
-Serves three entry modes (see `skills/conversion-runbook.md` → "Entry Modes"): **migration** (legacy source, all stages), **requirements-driven** (specs/SME input, no legacy code, stages 1–6), and **greenfield** (stage 5 onward). Plus **à-la-carte use with no pipeline at all** — auditing or regression/e2e-testing an existing app routes straight to `skills/existing-app-assurance.md`, skipping intake/stages/gates entirely.
+Serves four entry modes (see `skills/conversion-runbook.md` → "Entry Modes"): **migration** (legacy source, all stages), **requirements-driven** (specs/SME input, no legacy code, stages 1–6), **greenfield** (stage 5 onward), and **change an existing app** (a live `.mpr`, a slice being added or altered — stages P, 0–6 per slice, `skills/existing-app-change.md`). Plus **à-la-carte use with no pipeline at all** — auditing or regression/e2e-testing an existing app routes straight to `skills/existing-app-assurance.md`, skipping intake/stages/gates entirely.
 
 ## The front door
 - `CONVERSION-RUNBOOK.md` (root) — thin "how to start" pointer.
@@ -94,7 +94,7 @@ POINTERS, never copies — see `project-bin/check-root-clean.sh`.**
 
 The BRD is the platform boundary. Upstream of it a source is OutSystems, Java, or a folder of
 epics. Downstream of it there are only entities, microflows, pages and use cases. This repo
-serves three entry modes (migration, requirements-driven, greenfield) plus à-la-carte use, and
+serves four entry modes (migration, requirements-driven, greenfield, change an existing app) plus à-la-carte use, and
 only the first of those runs a pipeline at all.
 
 **Where things go.**

CONVERSION-RUNBOOK.md

@@ -22,6 +22,7 @@ Then open your agent (Claude Code or equivalent) in the workspace and say what y
 | Legacy source code | Migration | P, 0–7 |
 | Requirements/specs only, no code | Requirements-driven | P, 1–6 |
 | Just an idea / existing plan | Greenfield | P (light), 5–6 |
+| A live Mendix app you are changing | Change an existing app | P, 0–6 per slice |
 
 ## Where you run this — detected, not asked
 

README.md

@@ -4,11 +4,12 @@
 
 Shared skills, prompt templates, and learnings for **Mendix migration and development projects**.
 
-Serves three audiences — same stages, different entry points (see `skills/conversion-runbook.md` "Entry Modes"; the mode is a **confirmed Stage-P decision**, never silently inferred — if source code exists it gets analyzed, if specs exist stages 2–4 run, and greenfield is only for starting from a conversation):
+Serves five ways in — four pipeline entry modes that share the same stages, plus one route with no pipeline at all (see `skills/conversion-runbook.md` "Entry Modes"; the mode is a **confirmed Stage-P decision**, never silently inferred — if source code exists it gets analyzed, if specs exist stages 2–4 run, and greenfield is only for starting from a conversation):
 
 - **Migrations** (legacy source code) — all stages.
 - **Requirements-driven builds** (specs/BRDs/SME input, no legacy code) — stages 1–6; document discovery replaces source triage, extraction Path B/C replaces code extractors.
 - **Greenfield mxcli builds** — Stage 5 onward; the standard Mendix build discipline is not migration-specific.
+- **Changing an existing app** (a live `.mpr`, a slice being added or altered) — stages P, 0–6 per slice; the knowledge base is queried from the model itself (Path D), a regression net goes under the app first, and Stage 7 is N/A because the app never stops being live. `skills/existing-app-change.md`.
 - **Existing apps — à la carte, no pipeline** — audit, lint, or put a regression/e2e test net under a Mendix app you already have. No intake, no stages, no gates: start at `skills/existing-app-assurance.md` and grab only the tools you need.
 
 Used across all mxcli-powered projects — OS migrations, Java/Angular migrations, Node/Express+React migrations, and other client integration work.