From 2b13f57dd408588828f9525d8558df1808385068 Mon Sep 17 00:00:00 2001
From: r <r@x>
Date: Mon, 21 Sep 2026 11:32:27 +0000
Subject: [PATCH 1/4] docs(testing): Windows full test-run prompt

Adds docs/windows-test-run.md: a paste-able, unattended Claude Code prompt
for a Git Bash machine. Covers the CI guard scripts, 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 including
the two-tree and toolkit.env precedence probes. Produces one results file,
facts only. CHANGELOG line added in the same commit.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
---
 CHANGELOG.md             |   1 +
 docs/windows-test-run.md | 216 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 217 insertions(+)
 create mode 100644 docs/windows-test-run.md

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 51a77f7..9a749da 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,7 @@ 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(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(skills): **`learned-mdl-preflight.md` trimmed 7,173 → 5,311 words; `learned-stylegallery.md` demoted from baseline to on-demand (baseline pack 79,993 → 72,001 words).** Per the 2026-09-17 A/B/C freshness run: rows 2/7/10 cut to one-line RESOLVED cells with a pointer to the retest record; workflow rows 18–20 and the duplicate JUMP TO row 24 collapsed into one row 18 that routes to `learned-workflow-patterns.md` (cross-references in workflow-patterns, module-brief and the bug ledger renumbered); "MDL gotchas" cut to what the generated `CLAUDE.md` and `learned-microflow-patterns.md` do not already say; rows 23–24 (DesignProperties) rejoined to the STOP table from below a stray rule. STOP table itself unchanged — arm C kept it and matched arm B on every routing row — MendixMau
 - learn(bug-logs): **`BUG-DRAFT-stale-init-claude-md-declare-object`** — a `CLAUDE.md` written by a v0.16-era `mxcli init` still lists `DECLARE $Entity Module.Entity;` as a supported statement; v0.22 `check` rejects it (MDL043/CE0053, golden capture in the entry). v0.22 `init --tool claude` no longer emits the row, but `init` overwrites instead of refreshing and stamps no version into the file, so nothing flags an old scaffold. The sigil parameter form is accepted — the freshness report's first draft over-claimed that and is corrected in the same commit. Upstream ask (paste-ready in the entry): version stamp, `init --check`, refresh-only-generated-blocks. Toolkit follow-up proposed: a report-only warn in `sync-project.sh` and a strip rule in `bootstrap-project.md` — MendixMau
 - process(skill freshness): **A/B/C baseline of the four baseline-tier skills against mxcli v0.22.0 — three still change validator-blind behaviour, one does not.** `process/skill-freshness-2026-09-17.md`: 33 fresh Sonnet drafting runs (arm A no skill, B full text, C pure-deletion ablation; 3 reps) on a scratch copy of the TCX graph PoC, scored by `mxcli check`, `check-page-shell.sh`, `page-fidelity.js`, STOP-row greps and two rubric graders. `learned-mdl-preflight.md`: keep the STOP table, cut the retired-incident narratives and "MDL gotchas", move workflow rows 18–20 to `learned-workflow-patterns.md` (arm C at −37% words matched B on every routing row). `learned-microflow-patterns.md`: keep whole — arm C lost the Dto-section hint and 2/3 drafts regressed to declared object variables. `ui-preflight-pages.md`: keep; two sections are cut candidates (arm C indistinguishable from B: 3/3 top-bar layout, 3/3 H1 vs A 0/3). `learned-stylegallery.md`: no arm-B advantage on the add-a-gallery-page task (B wired the page 1/3, A 3/3) — demote that trigger to situational. Also found: the generated project `CLAUDE.md` teaches `DECLARE $Var Module.Entity;`, rejected by v0.22 (nine drafts across all arms hit it); two bundled skills contradict STOP row 6; the run cost 4.3M subagent tokens against a 0.5M estimate. Follow-up PRs listed in the report, none opened — MendixMau
diff --git a/docs/windows-test-run.md b/docs/windows-test-run.md
new file mode 100644
index 0000000..ba64dda
--- /dev/null
+++ b/docs/windows-test-run.md
@@ -0,0 +1,216 @@
+# Windows full test-run — paste-able prompt
+
+**Applies to:** the toolkit itself, on a Windows machine with Git Bash (MSYS)
+**Purpose:** one prompt you paste into a fresh Claude Code (or any agent) session on Windows.
+The session clones the toolkit, runs every guard, both fixture suites, the Windows-specific
+fixtures with their correct subjects, and a field run on a **scratch copy** of a real Mendix
+project. It writes one results file and stops. You read the file, not the transcript.
+
+Why this exists: `CLAUDE.md` → "Shipping an instrument" rule 3 ("Both platforms") and rule 2
+("Both layouts") are asserted by fixtures that were written on macOS and Linux. Nobody has run
+the whole set on the platform they claim to cover. This is that run.
+
+**Before you paste.** Fill in the two placeholders in the prompt:
+
+| Placeholder | What to put there |
+|---|---|
+| `<PROJECT-ROOT>` | An existing Mendix project on this machine that uses the toolkit (has `.mpr`, `./mxcli`, `mdlsource/`). It is copied; the original is never touched. Leave as-is to skip the field run. |
+| `<TOOLKIT-REF>` | `master`, a tag (`v2026.09.22`), or a branch. Default `master`. |
+
+Expected wall time: 20–40 minutes, most of it `bin/doctor.sh --install` and the wave2 suite.
+
+---
+
+## The prompt (copy from here to the end of the file)
+
+````text
+You are running the full Windows test run of the mxcli-project-toolkit. Work unattended:
+do not ask me anything, do not stop for approval, do not open a browser tab. If a step
+fails, record it and continue with the next step. When every step has run, write the
+results file and stop.
+
+RULES
+- Platform is Windows with Git Bash (MSYS). Run everything with `bash <script>` from a Git
+  Bash shell. Use forward slashes. Never use PowerShell for the toolkit scripts.
+- Never modify the real project at <PROJECT-ROOT>. Every field step runs on a copy under
+  ~/mxtk-win-run/. Never touch a real `.mpr` outside that copy.
+- Commit nothing, push nothing, open no PR. The clone is disposable.
+- Export these before the first script and keep them for the whole run:
+    export LEAKGUARD_ALLOW_NO_DENYLIST=1     # fresh clone has no denylist file
+    export MXTK_DOCTOR_SKIP_DOCKER=1         # docker probe is a separate step below
+    export LC_ALL=C                          # word counts must match the maintainers' numbers
+- For every step record: step id, exact command, PASS / FAIL / SKIP, the summary line
+  (`PASS=n FAIL=m`, exit code, or the first error line), and elapsed seconds.
+  SKIP needs a one-line reason. A step that emits nothing is FAIL, not PASS.
+- Reading a script to guess its result is not running it. Every PASS cites output.
+
+SETUP (S)
+S1  mkdir -p ~/mxtk-win-run && cd ~/mxtk-win-run
+    git clone https://github.com/MendixMau/mxcli-project-toolkit.git toolkit
+    cd toolkit && git checkout <TOOLKIT-REF> && git rev-parse --short HEAD
+    Record the sha. Every later relative path is from this clone root (call it $TK).
+S2  Record the environment verbatim:
+    uname -s ; uname -m ; bash --version | head -1 ; node --version ; git --version
+    where python python3 py 2>/dev/null ; docker --version 2>/dev/null || echo "no docker"
+S3  bash bin/doctor.sh --quick
+S4  bash bin/doctor.sh
+    Record every line that says MISSING, WARN or FAIL. Do not run --install yet.
+
+GUARDS (G) — the same checks CI runs on every PR
+G1  bash bin/check-scripts.sh
+G2  bash bin/check-portability.sh
+G3  LEAKGUARD_ALLOW_NO_DENYLIST=1 bash bin/check-no-client-data.sh
+G4  bash bin/check-pr-discipline.sh origin/master
+G5  bash bin/render-routing.sh --check
+    Record the baseline word count it prints (expect ~72k of the 80k budget; a number over
+    80,000 is FAIL even if the exit code is 0).
+G6  bash bin/check-skill-routing.sh
+G7  bash bin/check-docs-numbering.sh
+
+SUITES (T) — full runs, explicitly wanted for this test
+T1  bash tests/run-tests.sh -v
+    Self-contained guard-script fixtures (inputs are generated at run time, nothing on disk).
+T2  bash tests/wave2/run-all.sh -v
+    Runs a bash -n syntax pass over every fixture first, then each fixture with the subject
+    its `usage:` line declares. Known state on master: `test-bug06-freshness.sh` reports
+    PASS=55 FAIL=1 and the runner still marks the fixture ok — record that as PASS(known).
+    Any other fixture with FAIL>0 is a FAIL for this run. Record the runner's final tally.
+    Save the full output: bash tests/wave2/run-all.sh -v > ~/mxtk-win-run/wave2.log 2>&1
+
+WINDOWS-FOCUSED FIXTURES (F) — rerun singly so the Windows result is legible on its own.
+Each takes its subject as $1; the subject is the path shown.
+F1  bash tests/wave2/test-common-windows.sh project-bin/_common.sh
+    This is the MSYS fixture: `foo` -> `foo.exe` mapping, `.exe`-first mxcli lookup, CRLF.
+F2  bash tests/wave2/test-doctor-gate-selftest.sh bin/doctor.sh
+F3  bash tests/wave2/test-doctor-docker-probe.sh bin/doctor.sh
+F4  bash tests/wave2/test-bug07-08.sh project-bin/exec.sh
+F5  bash tests/wave2/test-model-stamp.sh
+    (subject is project-bin/model-stamp.sh, resolved inside the fixture; no argument)
+F6  bash tests/wave2/test-dryrun-writes-nothing.sh bin/sync-project.sh
+F7  bash tests/wave2/test-bug12-sync.sh bin/sync-project.sh
+F8  bash tests/wave2/test-guide-reopen.sh bin/init-project.sh
+F9  bash tests/wave2/test-render-routing.sh bin/render-routing.sh
+F10 bash tests/wave2/test-routing-tier.sh bin/render-routing.sh
+F11 bash tests/wave2/test-bug02-register.sh bin/gate-check.sh
+F12 bash tests/wave2/test-source-ledger.sh bin/gate-check.sh
+F13 bash tests/wave2/test-obligation-fidelity.sh bin/gate-check.sh
+F14 bash tests/wave2/test-wrong-verdicts.sh bin/gate-check.sh
+F15 bash tests/wave2/test-build-plan-json.sh project-bin/build-plan-status.sh
+F16 bash tests/wave2/test-docs-numbering.sh bin/check-docs-numbering.sh
+F17 bash tests/wave2/test-html-to-md.sh bin/html-to-md.sh
+    Input is the committed capture tests/wave2/fixtures/html-to-md/Fleet\ Portal\ Requirements.html
+    (a filename with a space — that is the point on Windows).
+F18 bash tests/wave2/test-page-fidelity-mocks.sh project-bin/page-fidelity.js
+    Input is tests/wave2/fixtures/page-fidelity-mocks/ (two wireframes + two MDL files;
+    CAPTURE.md there says what is verbatim and what was scrubbed).
+F19 bash tests/wave2/test-app-report.sh bin/app-report.sh
+F20 bash tests/wave2/test-app-layer-map.sh bin/app-layer-map.sh
+    F19/F20 read the committed fixture fixtures/app-analysis/ (app-dossier.md + facts/*.json).
+F21 bash tests/wave2/test-assemble-prototype.sh project-bin/assemble-prototype.js
+F22 bash tests/wave2/test-prototype-links.sh project-bin/check-prototype-links.js
+F23 bash tests/wave2/test-prototype-route.sh project-bin/prototype-route.js
+F24 bash tests/wave2/test-wire-agents-kiro.sh bin/wire-agents.sh
+F25 bash tests/wave2/test-install-claude-permissions.sh
+F26 bash tests/wave2/test-token-burn.sh bin/token-burn.sh
+F27 bash tests/wave2/test-harvest-learnings.sh
+
+TOOLS ON COMMITTED INPUTS (I) — direct runs, no fixture harness, so a Windows path or
+newline problem shows up as the tool's own error and not a fixture's.
+I1  bash bin/app-report.sh --facts fixtures/app-analysis/facts --dossier fixtures/app-analysis/app-dossier.md -o ~/mxtk-win-run/app-report.html
+    Then: test -s ~/mxtk-win-run/app-report.html && grep -c '<h' ~/mxtk-win-run/app-report.html
+I2  bash bin/app-layer-map.sh --facts fixtures/app-analysis/facts --json > ~/mxtk-win-run/layer-map.json
+    Then: node -e "JSON.parse(require('fs').readFileSync(process.argv[1],'utf8'))" ~/mxtk-win-run/layer-map.json
+I3  node project-bin/page-fidelity.js --no-log tests/wave2/fixtures/page-fidelity-mocks/grouped-overview.html DemoOverview tests/wave2/fixtures/page-fidelity-mocks/demo-overview.mdl
+I4  node project-bin/page-fidelity.js --no-log tests/wave2/fixtures/page-fidelity-mocks/mocked-list.html DemoList tests/wave2/fixtures/page-fidelity-mocks/demo-list.mdl
+I5  bash bin/html-to-md.sh "tests/wave2/fixtures/html-to-md/Fleet Portal Requirements.html" > ~/mxtk-win-run/fleet.md
+    Then: wc -l ~/mxtk-win-run/fleet.md
+I6  bash bin/brd-report.sh --help ; bash bin/triage-report.sh --help ; bash bin/questions-report.sh --help
+    (exit 0 and a usage text each = PASS; these are the report tools with no committed input)
+I7  bash bin/bug-lookup.sh CE0053
+I8  bash bin/token-burn.sh --help
+I9  bash bin/sync-labels.sh --dry-run
+I10 bash bin/cut-release.sh --dry-run
+I11 bash bin/exec-approval.sh --explain
+I12 bash bin/interview-mode.sh --help ; bash bin/question-kinds.sh --help ; bash bin/open-questions.sh --help
+
+FIELD RUN ON A SCRATCH COPY (P) — skip the whole block with reason "no project" if
+<PROJECT-ROOT> was left unfilled or does not contain a .mpr.
+P0  cp -r "<PROJECT-ROOT>" ~/mxtk-win-run/project
+    cd ~/mxtk-win-run/project && ls *.mpr ; ls mxcli* ; ls mdlsource | head
+    Record whether the .mpr is at the root (single-tree) or under app/ (two-tree).
+    Record `./mxcli --version` (Git Bash maps ./mxcli to mxcli.exe; note which file exists).
+P1  bash $TK/bin/init-project.sh ~/mxtk-win-run/project
+    Then: test -e ~/mxtk-win-run/project/.claude/.guide-shown && echo sentinel-ok
+    (the guide may open once here — that is the first-touch rule working; close the tab)
+P2  bash $TK/bin/init-project.sh ~/mxtk-win-run/project
+    Second run must be idempotent: no new files, no browser tab. Diff the file list before/after.
+P3  bash $TK/bin/sync-project.sh ~/mxtk-win-run/project --dry-run
+P4  bash $TK/bin/sync-project.sh ~/mxtk-win-run/project --strict
+    Record the `Toolkit release:` line it prints.
+P5  bash $TK/bin/gate-check.sh ~/mxtk-win-run/project
+    Expect PENDING verdicts on a fresh scaffold, no crash, dashboard index.html regenerated.
+P6  bash $TK/bin/gate-check.sh ~/mxtk-win-run/project --html --verbose
+P7  bash $TK/bin/status.sh ~/mxtk-win-run/project --brief
+P8  bash $TK/bin/doctor.sh --install --yes ~/mxtk-win-run/project
+    This is the step that fetches mxbuild/Java on demand. Record what it installed and where
+    (expect under ~/.mxcli/). Record every WARN.
+P9  bash $TK/bin/doctor.sh --gate-selftest ~/mxtk-win-run/project
+P10 unset MXTK_DOCTOR_SKIP_DOCKER; bash $TK/bin/doctor.sh --no-docker ~/mxtk-win-run/project; bash $TK/bin/doctor.sh ~/mxtk-win-run/project; export MXTK_DOCTOR_SKIP_DOCKER=1
+    Two runs: with and without the docker probe. Record both docker lines.
+P11 cd ~/mxtk-win-run/project && bash project-bin/install-project-hooks.sh --check
+    (if the project has no project-bin/, use $TK/project-bin/install-project-hooks.sh --check)
+P12 bash project-bin/model-stamp.sh fingerprint ; bash project-bin/model-stamp.sh check -q ; echo "exit=$?"
+P13 MODEL_UNVERIFIED_OK=1 bash project-bin/model-stamp.sh check -q ; echo "exit=$?"
+P14 Write a one-line MDL script that changes nothing:
+      printf 'SHOW MODULES;\n' > mdlsource/_win-probe.mdl
+    then: bash bin/exec.sh mdlsource/_win-probe.mdl
+    (the project's own bin/exec.sh; falls back to $TK/project-bin/exec.sh if absent)
+    Expect: snapshot taken, script executed, mxbuild check ran, no restore. Record the
+    snapshot directory it created and delete mdlsource/_win-probe.mdl afterwards.
+P15 ALLOW_UNVERIFIED=1 MXTK_NO_INSTALL=1 bash bin/exec.sh mdlsource/_win-probe.mdl
+    (recreate the probe file first) — the "no install, no verify" path must also complete.
+P16 bash project-bin/lint-gate.sh
+P17 bash project-bin/app-facts.sh --skip-loops
+    Record the facts dir it wrote and `ls` it (expect inventory.json, manifest.json, mdl/).
+P18 bash $TK/bin/app-layer-map.sh ~/mxtk-win-run/project -o ~/mxtk-win-run/project-layer-map.html
+P19 bash $TK/bin/app-report.sh ~/mxtk-win-run/project
+P20 bash $TK/bin/wire-agents.sh ~/mxtk-win-run/project --with-kiro --dry-run
+P21 bash $TK/bin/wire-agents.sh ~/mxtk-win-run/project --check
+P22 bash $TK/bin/triage.sh ~/mxtk-win-run/project
+P23 bash $TK/bin/source-sufficiency.sh init ~/mxtk-win-run/project ; bash $TK/bin/source-ledger.sh ~/mxtk-win-run/project
+P24 Two-tree probe (rule 2, "Both layouts"): if the copy is single-tree, make a second copy
+    with the .mpr moved under app/:
+      cp -r ~/mxtk-win-run/project ~/mxtk-win-run/project-2tree
+      mkdir -p ~/mxtk-win-run/project-2tree/app && mv ~/mxtk-win-run/project-2tree/*.mpr ~/mxtk-win-run/project-2tree/app/
+    then rerun P5, P7, P12 against ~/mxtk-win-run/project-2tree and record whether each
+    still finds the .mpr. If the copy is already two-tree, do the reverse (move the .mpr to
+    the root) and rerun the same three.
+P25 toolkit.env precedence: printf 'MXCLI_VERSION=0.0.0-probe\n' >> ~/mxtk-win-run/project/.claude/toolkit.env
+    then rerun P7 and P12; the output must mention 0.0.0-probe (proves _common.sh reads the
+    file on Windows). Remove the line afterwards.
+
+RESULTS FILE
+Write ~/mxtk-win-run/mxtk-windows-run-<YYYY-MM-DD>.md with:
+1. Header: toolkit sha, <TOOLKIT-REF>, the S2 environment block verbatim, single-tree or two-tree.
+2. One table for all steps S/G/T/F/I/P: `| id | command | verdict | summary line | seconds |`.
+   Verdicts are exactly PASS, PASS(known), FAIL, SKIP. Nothing else.
+3. Totals: PASS n / FAIL m / SKIP k over N steps (N is the number of ids listed above).
+4. For every FAIL: the first 20 lines of its output, indented, plus the fixture's own tally.
+5. A "Windows-only observations" list: any place Git Bash translated a path (C:\ vs /c/),
+   any `.exe` mapping surprise, any CRLF warning, any script that needed `python` instead
+   of `python3`, any tool doctor.sh said was missing.
+6. Do not summarise, interpret, or propose fixes. Facts only. The maintainer triages.
+Then print the totals line and the path of the results file, and stop.
+````
+
+---
+
+## After the run
+
+Paste the results file back to the maintainer session as-is. A FAIL there becomes either a
+`contrib/inbox/` drop or a direct PR held to the field-proof bar (`CONTRIBUTING.md`); the
+file itself is the "one field run, cited" evidence rule 4 asks for.
+
+What this run deliberately does **not** cover: browser-driven tests (`project-bin/test-stack-up.sh`
+needs a running app), MCP write sessions, and the pipelines under `pipelines/` (they need a
+legacy source tree; run their own `README.md` steps separately if one is available).

From 77969297b28e68ec41eeaed2d3b28e644fd38d39 Mon Sep 17 00:00:00 2001
From: r <r@x>
Date: Tue, 22 Sep 2026 11:51:08 +0000
Subject: [PATCH 2/4] docs(front door): README and toolkit-guide count four
 ways in, not three

Both already listed migration, requirements-driven, greenfield and the
a-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 a-la-carte. Wording is now: three pipeline
entry modes plus one route with no pipeline at all.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
---
 CHANGELOG.md       | 1 +
 README.md          | 2 +-
 toolkit-guide.html | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 9a749da..aba8e6d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,7 @@ 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 four 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: three 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(skills): **`learned-mdl-preflight.md` trimmed 7,173 → 5,311 words; `learned-stylegallery.md` demoted from baseline to on-demand (baseline pack 79,993 → 72,001 words).** Per the 2026-09-17 A/B/C freshness run: rows 2/7/10 cut to one-line RESOLVED cells with a pointer to the retest record; workflow rows 18–20 and the duplicate JUMP TO row 24 collapsed into one row 18 that routes to `learned-workflow-patterns.md` (cross-references in workflow-patterns, module-brief and the bug ledger renumbered); "MDL gotchas" cut to what the generated `CLAUDE.md` and `learned-microflow-patterns.md` do not already say; rows 23–24 (DesignProperties) rejoined to the STOP table from below a stray rule. STOP table itself unchanged — arm C kept it and matched arm B on every routing row — MendixMau
 - learn(bug-logs): **`BUG-DRAFT-stale-init-claude-md-declare-object`** — a `CLAUDE.md` written by a v0.16-era `mxcli init` still lists `DECLARE $Entity Module.Entity;` as a supported statement; v0.22 `check` rejects it (MDL043/CE0053, golden capture in the entry). v0.22 `init --tool claude` no longer emits the row, but `init` overwrites instead of refreshing and stamps no version into the file, so nothing flags an old scaffold. The sigil parameter form is accepted — the freshness report's first draft over-claimed that and is corrected in the same commit. Upstream ask (paste-ready in the entry): version stamp, `init --check`, refresh-only-generated-blocks. Toolkit follow-up proposed: a report-only warn in `sync-project.sh` and a strip rule in `bootstrap-project.md` — MendixMau
diff --git a/README.md b/README.md
index 669bbb7..f9315de 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@
 
 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 four ways in — three 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.
diff --git a/toolkit-guide.html b/toolkit-guide.html
index e085dbe..6366e35 100644
--- a/toolkit-guide.html
+++ b/toolkit-guide.html
@@ -80,7 +80,7 @@
   <h1>mxcli Project Toolkit — how this works</h1>
   <p class="lede">You point this toolkit at legacy source code <em>or</em> a stack of requirements, and it interviews you through to a running Mendix app. Every stage produces an artifact you can show a customer, and every decision you make is recorded — nothing is silently decided for you.</p>
 
-  <h2>1 · Three ways in — pick what you're starting from</h2>
+  <h2>1 · Four ways in — pick what you're starting from</h2>
   <div class="cards">
     <div class="card">
       <h3>Migration</h3>

From d0cd109d097f6ef2904c06d0bf5c26938b0b8374 Mon Sep 17 00:00:00 2001
From: r <r@x>
Date: Tue, 22 Sep 2026 12:18:44 +0000
Subject: [PATCH 3/4] new(entry modes): wire "Change an existing app" as the
 fourth pipeline entry mode

Until now only gate-check.sh knew the existing-app-change mode: intake.md
Q1 offered three modes, the runbook's classification rules had no rule for
a live .mpr being altered, and the artifact manifest owed that mode nothing.
A session changing a live app therefore had no option to pick (field run,
2026-09-22).

- intake-template.sh: Q1 lists four modes with ordered classification
  rules; the answer is recorded verbatim as "Change an existing app", which
  entry-mode.sh already maps to existing-app-change.
- conversion-runbook.md: new rule 1 + table row for the mode (P, 0-6 per
  slice, Path D, regression gates from Stage 5, Stage 7 N/A); incident note.
- CONVERSION-RUNBOOK.md pointer table: matching row.
- artifact-manifest.tsv: existing-app-change added to every P-6 row except
  coverage-ledger (that mode's ledger is `mxcli brain plan`).
- README.md, toolkit-guide.html, CLAUDE.md: four pipeline modes plus the
  a-la-carte no-pipeline route, i.e. five ways in.
- CHANGELOG.md: entry appended.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
---
 CHANGELOG.md                  |  2 +-
 CLAUDE.md                     |  4 +-
 CONVERSION-RUNBOOK.md         |  1 +
 README.md                     |  3 +-
 bin/lib/artifact-manifest.tsv | 82 ++++++++++++++++++-----------------
 bin/lib/intake-template.sh    | 13 +++---
 skills/conversion-runbook.md  | 10 +++--
 toolkit-guide.html            |  7 ++-
 8 files changed, 69 insertions(+), 53 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index edd95b6..56c4881 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,7 +16,7 @@ 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 four 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: three pipeline entry modes plus one route with no pipeline — Maurits Visser
+- 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
diff --git a/CLAUDE.md b/CLAUDE.md
index 4f164e9..c9ed08b 100644
--- a/CLAUDE.md
+++ b/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.**
diff --git a/CONVERSION-RUNBOOK.md b/CONVERSION-RUNBOOK.md
index 0b34e44..710e0e5 100644
--- a/CONVERSION-RUNBOOK.md
+++ b/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
 
diff --git a/README.md b/README.md
index aed6d2b..96d0a21 100644
--- a/README.md
+++ b/README.md
@@ -4,11 +4,12 @@
 
 Shared skills, prompt templates, and learnings for **Mendix migration and development projects**.
 
-Serves four ways in — three 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):
+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.
diff --git a/bin/lib/artifact-manifest.tsv b/bin/lib/artifact-manifest.tsv
index 4eb5195..ec138e5 100644
--- a/bin/lib/artifact-manifest.tsv
+++ b/bin/lib/artifact-manifest.tsv
@@ -39,8 +39,12 @@
 #   4 producer    the skill step or script that emits it — the thing a PENDING row tells you
 #                 to run
 #   5 consumers   the citations that earn the row its place (see above)
-#   6 modes       comma list of entry modes that owe it: migration,requirements,greenfield
-#                 (conversion-runbook.md §"Entry Modes", table at :98-102). À-la-carte projects
+#   6 modes       comma list of entry modes that owe it:
+#                 migration,requirements,greenfield,existing-app-change
+#                 (conversion-runbook.md §"Entry Modes", its table; existing-app-change runs
+#                 P–6 per slice, so it owes every row but coverage-ledger — that mode's ledger
+#                 is `mxcli brain plan`, existing-app-change.md §"Coverage in this mode").
+#                 À-la-carte projects
 #                 run no stages and are excused wholesale by artifact-check.sh, same test as
 #                 obligation-check.sh.
 #   7 absence     gate   — an existing mechanical check already refuses without it
@@ -63,46 +67,46 @@
 # later, not overdue now.
 #
 artifact	stage	paths	producer	consumers	modes	absence
-intake	P	intake.md	bin/init-project.sh scaffold + the Stage-P kickoff interview (conversion-runbook.md §2 Stage P)	bin/gate-check.sh:596 (check_stage_P), bin/gate-check.sh:497 (entry-mode fallback read)	migration,requirements,greenfield	gate
-register	P	PROJECT.md	bin/init-project.sh (empty register); every checkpoint writes into it (CLAUDE.md §One decision register)	bin/gate-check.sh:285 (register resolution feeding every ✋ gate), bin/lib/obligation-check.sh:151 (waivers/adoption read from it)	migration,requirements,greenfield	gate
-triage	0	triage.md	bin/init-project.sh scaffold, filled per skills/source-triage.md; N/A rows recorded, never deleted (conversion-runbook.md:130)	bin/gate-check.sh:684 (check_stage_0 sign-off test)	migration,requirements,greenfield	gate
-extraction-report	1	analysis/*/knowledge-base/extraction-report.html|analysis/knowledge-base/extraction-report.html|knowledge-base/extraction-report.html	bin/extraction-report.sh <project-root> — one renderer for every entry mode	bin/gate-check.sh:725 (check_stage_1)	migration,requirements	gate
-source-ledger	1	analysis/source-ledger.html	bin/source-ledger.sh report <project-root> — every inventoried source file and what consumed it (Stage 1 owes a disposition per row; gate-check blocks 1–2 on the check)	bin/gate-check.sh (LEDGER block — the check; the html is the human-facing table of the same rows)	migration,requirements	report
-brds	2	analysis/*/knowledge-base/brd/*.brd.json|analysis/knowledge-base/brd/*.brd.json|knowledge-base/brd/*.brd.json	pipeline generators (migration), skills/kb-generation.md (documents), skills/brd-generation.md (by hand) — the reader must not care which	bin/lib/discover-brds.sh:43 (the one path authority), bin/gate-check.sh:773 (check_stage_2), bin/brd-report.sh, bin/open-questions.sh	migration,requirements	gate
-brd-validation	2	analysis/*/knowledge-base/reports/validation-report.md|analysis/knowledge-base/reports/validation-report.md|knowledge-base/reports/validation-report.md	skills/brd-validation.md loop, run to Clean	bin/gate-check.sh:777-807 (check_stage_2 Stop-condition test)	migration,requirements	gate
-brd-surface	2	analysis/brd-report.html	bin/brd-report.sh <project-root> (default output, bin/brd-report.sh:113)	conversion-runbook.md §2 Stage-2 Surface row, parsed at bin/gate-check.sh:1284 (stage_surface_cells)	migration,requirements	report
-module-design	3	architecture/module-design.html|module-design.html	skills/modularize-domain.md:88 (the human-facing sign-off artifact)	skills/modularize-domain.md:109 (gate checklist), conversion-runbook.md:478 Stage-3 Surface row (parsed at bin/gate-check.sh:1284)	migration,requirements	report
-fit-gap	3	architecture/fit-gap.md	skills/architecture-blueprint.md Step 4	bin/gate-check.sh:912 (check_stage_3), bin/gate-check.sh:939 (blueprint.html staleness input)	migration,requirements	gate
-blueprint-md	3	architecture/blueprint.md	skills/architecture-blueprint.md Steps 2-6 — the markdown is the source of truth	bin/gate-check.sh:939 (staleness input), skills/architecture-blueprint.md:54 (render source for blueprint.html)	migration,requirements	report
-blueprint-html	3	architecture/blueprint.html	skills/architecture-blueprint.md Step 7 (generated render, never hand-edited)	bin/gate-check.sh:931-943 (check_stage_3 presence + freshness)	migration,requirements	gate
-design-system	3	design/design-system.html	skills/design-artifacts.md:79 (annotated showcase linking ds.css)	bin/gate-check.sh:913 (check_stage_3), bin/gate-check.sh:1135 (build-ready)	migration,requirements	gate
-ds-css	3	design/ds.css	skills/design-artifacts.md:75 (the physical token/component source)	skills/design-artifacts.md:68 (two-files rule — every wireframe links it), bin/gate-check.sh:1135 (build-ready accepts either file)	migration,requirements	report
-wireframes	3	design/wireframes/*.html	skills/design-artifacts.md Step 3, one per screen	bin/gate-check.sh:923 (check_stage_3), bin/gate-check.sh:1129 (build-ready), skills/ui-preflight-pages.md (mdl-agent pre-flight input)	migration,requirements	gate
-module-definition	3	architecture/modules/*/definition.md	skills/architecture-blueprint.md Step 1 (:60 — the directory shape, one doc per module)	THIS ROW IS ITS FIRST MECHANICAL CONSUMER — as of 2026-08-22 nothing executable read definition.md (improvement-plan P7 residue, the newest instance of the pattern this table exists to stop); prose consumers: skills/architecture-blueprint.md:43, skills/coverage-ledger.md:27	migration,requirements	report
-build-plan	4	architecture/build-plan.md	skills/brd-to-build-plan.md	bin/gate-check.sh:955 (check_stage_4), project-bin/build-plan-status.sh (progress board), project-bin/coverage-preflight.sh:238 (the claims join)	migration,requirements	gate
-build-plan-html	4	architecture/build-plan.html	project-bin/build-plan-status.sh --html (skills/brd-to-build-plan.md:47 — derived view, never hand-edited)	conversion-runbook.md §2 Stage-4 Surface row, parsed at bin/gate-check.sh:1284	migration,requirements	report
-build-plan-json	4	architecture/build-plan.json	project-bin/build-plan-status.sh --json (derived from build-plan.md's Step-5 Phase headings, row tables and claims: blocks, never hand-edited; not written when the markdown has no Phase headings)	MXTK Studio Plan room (a view built from data, not from the HTML); nothing in the toolkit reads it and no verdict may depend on it	migration,requirements	report
-module-brief	4	architecture/modules/*/module-brief.md|architecture/modules/*-brief.md	skills/module-brief.md — ba-agent writes the first at Stage 4, the rest just-in-time	bin/gate-check.sh:1121 (build-ready fails without one), project-bin/build-plan-status.sh:98	migration,requirements	gate
+intake	P	intake.md	bin/init-project.sh scaffold + the Stage-P kickoff interview (conversion-runbook.md §2 Stage P)	bin/gate-check.sh:596 (check_stage_P), bin/gate-check.sh:497 (entry-mode fallback read)	migration,requirements,greenfield,existing-app-change	gate
+register	P	PROJECT.md	bin/init-project.sh (empty register); every checkpoint writes into it (CLAUDE.md §One decision register)	bin/gate-check.sh:285 (register resolution feeding every ✋ gate), bin/lib/obligation-check.sh:151 (waivers/adoption read from it)	migration,requirements,greenfield,existing-app-change	gate
+triage	0	triage.md	bin/init-project.sh scaffold, filled per skills/source-triage.md; N/A rows recorded, never deleted (conversion-runbook.md:130)	bin/gate-check.sh:684 (check_stage_0 sign-off test)	migration,requirements,greenfield,existing-app-change	gate
+extraction-report	1	analysis/*/knowledge-base/extraction-report.html|analysis/knowledge-base/extraction-report.html|knowledge-base/extraction-report.html	bin/extraction-report.sh <project-root> — one renderer for every entry mode	bin/gate-check.sh:725 (check_stage_1)	migration,requirements,existing-app-change	gate
+source-ledger	1	analysis/source-ledger.html	bin/source-ledger.sh report <project-root> — every inventoried source file and what consumed it (Stage 1 owes a disposition per row; gate-check blocks 1–2 on the check)	bin/gate-check.sh (LEDGER block — the check; the html is the human-facing table of the same rows)	migration,requirements,existing-app-change	report
+brds	2	analysis/*/knowledge-base/brd/*.brd.json|analysis/knowledge-base/brd/*.brd.json|knowledge-base/brd/*.brd.json	pipeline generators (migration), skills/kb-generation.md (documents), skills/brd-generation.md (by hand) — the reader must not care which	bin/lib/discover-brds.sh:43 (the one path authority), bin/gate-check.sh:773 (check_stage_2), bin/brd-report.sh, bin/open-questions.sh	migration,requirements,existing-app-change	gate
+brd-validation	2	analysis/*/knowledge-base/reports/validation-report.md|analysis/knowledge-base/reports/validation-report.md|knowledge-base/reports/validation-report.md	skills/brd-validation.md loop, run to Clean	bin/gate-check.sh:777-807 (check_stage_2 Stop-condition test)	migration,requirements,existing-app-change	gate
+brd-surface	2	analysis/brd-report.html	bin/brd-report.sh <project-root> (default output, bin/brd-report.sh:113)	conversion-runbook.md §2 Stage-2 Surface row, parsed at bin/gate-check.sh:1284 (stage_surface_cells)	migration,requirements,existing-app-change	report
+module-design	3	architecture/module-design.html|module-design.html	skills/modularize-domain.md:88 (the human-facing sign-off artifact)	skills/modularize-domain.md:109 (gate checklist), conversion-runbook.md:478 Stage-3 Surface row (parsed at bin/gate-check.sh:1284)	migration,requirements,existing-app-change	report
+fit-gap	3	architecture/fit-gap.md	skills/architecture-blueprint.md Step 4	bin/gate-check.sh:912 (check_stage_3), bin/gate-check.sh:939 (blueprint.html staleness input)	migration,requirements,existing-app-change	gate
+blueprint-md	3	architecture/blueprint.md	skills/architecture-blueprint.md Steps 2-6 — the markdown is the source of truth	bin/gate-check.sh:939 (staleness input), skills/architecture-blueprint.md:54 (render source for blueprint.html)	migration,requirements,existing-app-change	report
+blueprint-html	3	architecture/blueprint.html	skills/architecture-blueprint.md Step 7 (generated render, never hand-edited)	bin/gate-check.sh:931-943 (check_stage_3 presence + freshness)	migration,requirements,existing-app-change	gate
+design-system	3	design/design-system.html	skills/design-artifacts.md:79 (annotated showcase linking ds.css)	bin/gate-check.sh:913 (check_stage_3), bin/gate-check.sh:1135 (build-ready)	migration,requirements,existing-app-change	gate
+ds-css	3	design/ds.css	skills/design-artifacts.md:75 (the physical token/component source)	skills/design-artifacts.md:68 (two-files rule — every wireframe links it), bin/gate-check.sh:1135 (build-ready accepts either file)	migration,requirements,existing-app-change	report
+wireframes	3	design/wireframes/*.html	skills/design-artifacts.md Step 3, one per screen	bin/gate-check.sh:923 (check_stage_3), bin/gate-check.sh:1129 (build-ready), skills/ui-preflight-pages.md (mdl-agent pre-flight input)	migration,requirements,existing-app-change	gate
+module-definition	3	architecture/modules/*/definition.md	skills/architecture-blueprint.md Step 1 (:60 — the directory shape, one doc per module)	THIS ROW IS ITS FIRST MECHANICAL CONSUMER — as of 2026-08-22 nothing executable read definition.md (improvement-plan P7 residue, the newest instance of the pattern this table exists to stop); prose consumers: skills/architecture-blueprint.md:43, skills/coverage-ledger.md:27	migration,requirements,existing-app-change	report
+build-plan	4	architecture/build-plan.md	skills/brd-to-build-plan.md	bin/gate-check.sh:955 (check_stage_4), project-bin/build-plan-status.sh (progress board), project-bin/coverage-preflight.sh:238 (the claims join)	migration,requirements,existing-app-change	gate
+build-plan-html	4	architecture/build-plan.html	project-bin/build-plan-status.sh --html (skills/brd-to-build-plan.md:47 — derived view, never hand-edited)	conversion-runbook.md §2 Stage-4 Surface row, parsed at bin/gate-check.sh:1284	migration,requirements,existing-app-change	report
+build-plan-json	4	architecture/build-plan.json	project-bin/build-plan-status.sh --json (derived from build-plan.md's Step-5 Phase headings, row tables and claims: blocks, never hand-edited; not written when the markdown has no Phase headings)	MXTK Studio Plan room (a view built from data, not from the HTML); nothing in the toolkit reads it and no verdict may depend on it	migration,requirements,existing-app-change	report
+module-brief	4	architecture/modules/*/module-brief.md|architecture/modules/*-brief.md	skills/module-brief.md — ba-agent writes the first at Stage 4, the rest just-in-time	bin/gate-check.sh:1121 (build-ready fails without one), project-bin/build-plan-status.sh:98	migration,requirements,existing-app-change	gate
 coverage-ledger	4	architecture/modules/*/coverage-ledger.md|architecture/modules/*-coverage-ledger.md|architecture/coverage-ledger.md	skills/coverage-ledger.md procedure at Stage 4 (BRD leaves × build-plan claims); the three shapes are §"Where the ledger lives", first canonical	project-bin/conformance-check.sh:85-93, project-bin/coverage-preflight.sh:134-137, project-bin/verify-module.sh:299-300, project-bin/review-module.sh:289, conversion-runbook.md:487 (Stage-4 produces row) — the eleven-consumers-no-producer artifact of improvement-plan Finding 12	migration,requirements	report
-ui-reviews	5	design/ui-reviews/ui-review-*.html	skills/module-review.md pass (review-agent), one report per module close-out	bin/gate-check.sh:984 (check_stage_6), bin/lib/obligations.tsv:47 (the look row — per-module coverage and denominators live THERE; this row only asks whether the stage produced any report at all)	migration,requirements,greenfield	gate
-journeys	5	journeys/*.journey.json	journey authoring per skills/testing-shape.md / skills/journey-proof.md (worked example: project-tests/e2e/example.journey.json)	project-bin/verify-module.sh:376,404 (the journeys rung), project-tests/e2e/journey-runner.js:5	migration,requirements,greenfield	report
-page-scope	5	.claude/loop/page-scope.json	project-bin/page-scope.sh (the phantom of improvement-plan Finding 15 until 078c7d8 shipped it)	project-tests/e2e/design-audit.js:55, project-tests/e2e/page-audit.js:66, project-tests/e2e/report-normalize.js:112 — without it the LOOK instruments degrade to --static-only	migration,requirements,greenfield	report
-lint-last	5	.claude/loop/lint-last.json	project-bin/lint-gate.sh (written on every run that reaches a verdict, not only --update-baseline), run as part of skills/module-review.md stage 2 GATE ("bin/exec.sh; gate-agent confirms 0 mxbuild errors, lint clean" — same step named in skills/iterative-build-loop.md's "Gate: BUILD")	bin/status.sh:75-81,129 (the OVERDUE line's lint readout — without it status.sh reports "lint gate never recorded here")	migration,requirements,greenfield	report
-improvement-register	5	docs/improvement-register.md	skills/improvement-register.md:39 (append-only, one row per finding, written during build/verify passes)	project-bin/build-plan-status.sh:58,202 (the proven-vs-built cross-reference), skills/close-the-loop.md	migration,requirements,greenfield	report
-improvement-register-html	5	docs/improvement-register.html	project-bin/render-improvement-register.sh (landed 2026-08-22; in MXTK_PROJECT_BIN — bin/lib/install-manifest.sh:81-85)	project-bin/render-improvement-register.sh:35 (output contract); human review surface for the register above — report-only by assignment	migration,requirements,greenfield	report
-report-json	6	docs/report.json	project-bin/verify-module.sh:518 (normalize rung → report-normalize.js), run as part of every module verify	bin/gate-check.sh:980 (check_stage_6 requires it alongside the HTML), project-tests/e2e/report-render.js (renders from it)	migration,requirements,greenfield	gate
-verification-html	6	docs/verification/report.html|test-report.html|reports/test-report.html	project-bin/verify-module.sh:521 (render rung → report-render.js); the two test-report.html shapes are the legacy names check_stage_6 still accepts	bin/gate-check.sh:970-995 (check_stage_6 — the gate that was structurally unpassable before b9c90a4/078c7d8, improvement-plan Finding 14)	migration,requirements,greenfield	gate
+ui-reviews	5	design/ui-reviews/ui-review-*.html	skills/module-review.md pass (review-agent), one report per module close-out	bin/gate-check.sh:984 (check_stage_6), bin/lib/obligations.tsv:47 (the look row — per-module coverage and denominators live THERE; this row only asks whether the stage produced any report at all)	migration,requirements,greenfield,existing-app-change	gate
+journeys	5	journeys/*.journey.json	journey authoring per skills/testing-shape.md / skills/journey-proof.md (worked example: project-tests/e2e/example.journey.json)	project-bin/verify-module.sh:376,404 (the journeys rung), project-tests/e2e/journey-runner.js:5	migration,requirements,greenfield,existing-app-change	report
+page-scope	5	.claude/loop/page-scope.json	project-bin/page-scope.sh (the phantom of improvement-plan Finding 15 until 078c7d8 shipped it)	project-tests/e2e/design-audit.js:55, project-tests/e2e/page-audit.js:66, project-tests/e2e/report-normalize.js:112 — without it the LOOK instruments degrade to --static-only	migration,requirements,greenfield,existing-app-change	report
+lint-last	5	.claude/loop/lint-last.json	project-bin/lint-gate.sh (written on every run that reaches a verdict, not only --update-baseline), run as part of skills/module-review.md stage 2 GATE ("bin/exec.sh; gate-agent confirms 0 mxbuild errors, lint clean" — same step named in skills/iterative-build-loop.md's "Gate: BUILD")	bin/status.sh:75-81,129 (the OVERDUE line's lint readout — without it status.sh reports "lint gate never recorded here")	migration,requirements,greenfield,existing-app-change	report
+improvement-register	5	docs/improvement-register.md	skills/improvement-register.md:39 (append-only, one row per finding, written during build/verify passes)	project-bin/build-plan-status.sh:58,202 (the proven-vs-built cross-reference), skills/close-the-loop.md	migration,requirements,greenfield,existing-app-change	report
+improvement-register-html	5	docs/improvement-register.html	project-bin/render-improvement-register.sh (landed 2026-08-22; in MXTK_PROJECT_BIN — bin/lib/install-manifest.sh:81-85)	project-bin/render-improvement-register.sh:35 (output contract); human review surface for the register above — report-only by assignment	migration,requirements,greenfield,existing-app-change	report
+report-json	6	docs/report.json	project-bin/verify-module.sh:518 (normalize rung → report-normalize.js), run as part of every module verify	bin/gate-check.sh:980 (check_stage_6 requires it alongside the HTML), project-tests/e2e/report-render.js (renders from it)	migration,requirements,greenfield,existing-app-change	gate
+verification-html	6	docs/verification/report.html|test-report.html|reports/test-report.html	project-bin/verify-module.sh:521 (render rung → report-render.js); the two test-report.html shapes are the legacy names check_stage_6 still accepts	bin/gate-check.sh:970-995 (check_stage_6 — the gate that was structurally unpassable before b9c90a4/078c7d8, improvement-plan Finding 14)	migration,requirements,greenfield,existing-app-change	gate
 
 # ── Opt-in rows (absence = optin) — added 2026-09-02 with the close-out block. Offered at
 # the stage open, owed only after opting in. Paths are the first-match convention; the second
 # alternative is the name a real project already used (workflow-design: TFC-TCXGraphPOC's
 # architecture/workflow-definition.md, written unprompted and never tracked by anything).
-workflow-design	3	architecture/workflow-definition.md|architecture/workflow-design.md|architecture/workflows/*.md	skills/architecture-blueprint.md Step 3b (state diagram per process: states, transitions, who moves it, SLA) + skills/learned-workflow-patterns.md for the native-Workflow shape	skills/checkpoints/checkpoint-architecture.md Q3 (asks whether the process is Workflow or enum-driven — either way this is where it is drawn), skills/learned-workflow-patterns.md (the build-time reader), bin/lib/closeout.sh (offers it at the Stage-3 open, lists it at the close)	migration,requirements,greenfield	optin
-swimlanes	3	architecture/swimlanes.md|architecture/swimlane-*.md|architecture/diagrams/swimlane*.md	Mermaid per business process, one lane per role from the Stage-3 role model, one section per process; the cross-persona journey diagrams of skills/architecture-blueprint.md Step 3d are the multi-persona case of the same picture	skills/checkpoints/checkpoint-architecture.md (the optional-artifacts question), skills/architecture-blueprint.md Step 3d (journey list it feeds), skills/journey-proof.md (the journeys a swimlane names are the ones Stage 5–6 must prove), bin/lib/closeout.sh	migration,requirements,greenfield	optin
-sequence-diagrams	3	architecture/sequence-diagrams.md|architecture/sequence-*.md|architecture/diagrams/sequence*.md	Mermaid sequenceDiagram per integration or agent call — caller, Mendix microflow, external system, sync/async, timeout, fallback; the agent-wiring diagram of skills/architecture-blueprint.md Step 3c is one instance	skills/checkpoints/checkpoint-architecture.md Q3 agent-wiring half, skills/rest-integration-first-time-right.md (build-time reader for the REST ones), skills/mendix-agents.md, bin/lib/closeout.sh	migration,requirements,greenfield	optin
-erd	3	architecture/erd.md|architecture/domain-model.md|architecture/diagrams/erd*.md	Mermaid erDiagram of the TARGET domain across modules — entities, associations, ownership per module; the blueprint's layer diagram shows modules, not entities, and .mx-brd.json shows one module at a time	skills/checkpoints/checkpoint-architecture.md Q2 (cross-module data strategy — the picture that question is about), skills/modularize-domain.md, bin/lib/closeout.sh	migration,requirements,greenfield	optin
-nfr-sheet	3	architecture/nfr.md|architecture/nfrs.md|architecture/non-functional-requirements.md	One table: NFR, target, how measured, where in the model it is enforced (XPath, index, batch size, timeout) — the per-NFR expansion of the list CAC-3's open question writes to project-profile.md	skills/checkpoints/checkpoint-architecture.md open question (the list), skills/architecture-blueprint.md Step 5 (the register that must not lose them), bin/lib/closeout.sh	migration,requirements,greenfield	optin
-integration-contracts	3	architecture/integration-contracts.md|architecture/integrations.md|architecture/integrations/*.md	Per integration: endpoint, auth, payload in/out, error handling, owner, test double — written BEFORE the build plan so the plan can sequence it	skills/rest-integration-first-time-right.md (reads it first thing at Stage 5), skills/architecture-blueprint.md Step 5 (the integrations register), bin/lib/closeout.sh	migration,requirements,greenfield	optin
-test-plan	4	architecture/test-plan.md|docs/test-plan.md	Per module: the journeys to prove, the fixtures they need, the DB assertions, the edge cases — the plan-side twin of the coverage ledger, written per skills/testing-shape.md before any MDL	skills/checkpoints/checkpoint-build.md (the optional-artifacts question), skills/testing-shape.md, skills/journey-proof.md, skills/fixture-seeding.md (Stage-5 readers), bin/lib/closeout.sh	migration,requirements,greenfield	optin
-acceptance-criteria	4	architecture/acceptance-criteria.md|docs/acceptance-criteria.md	Per module: what "done" means beyond CE-error-free — the Stage-4 "User defines" row of conversion-runbook.md §2, written down instead of held in chat; each criterion names the journey or check that proves it	conversion-runbook.md §2 Stage 4 "User defines" row, skills/module-brief.md (the brief's Done section is where these land per module), skills/module-review.md (the confirm step reads them), bin/lib/closeout.sh	migration,requirements,greenfield	optin
-demo-script	5	docs/demo-script.md|docs/demo/script.md	The narrated walk-through a human will give — beats, pages, fixtures on screen, what the audience must see happen; written at the Stage-5 open so the build front-loads what the demo needs	skills/record-demo-video.md (its input), skills/handoff-to-studio-pro.md §8 (demo data the script depends on), bin/lib/closeout.sh	migration,requirements,greenfield	optin
+workflow-design	3	architecture/workflow-definition.md|architecture/workflow-design.md|architecture/workflows/*.md	skills/architecture-blueprint.md Step 3b (state diagram per process: states, transitions, who moves it, SLA) + skills/learned-workflow-patterns.md for the native-Workflow shape	skills/checkpoints/checkpoint-architecture.md Q3 (asks whether the process is Workflow or enum-driven — either way this is where it is drawn), skills/learned-workflow-patterns.md (the build-time reader), bin/lib/closeout.sh (offers it at the Stage-3 open, lists it at the close)	migration,requirements,greenfield,existing-app-change	optin
+swimlanes	3	architecture/swimlanes.md|architecture/swimlane-*.md|architecture/diagrams/swimlane*.md	Mermaid per business process, one lane per role from the Stage-3 role model, one section per process; the cross-persona journey diagrams of skills/architecture-blueprint.md Step 3d are the multi-persona case of the same picture	skills/checkpoints/checkpoint-architecture.md (the optional-artifacts question), skills/architecture-blueprint.md Step 3d (journey list it feeds), skills/journey-proof.md (the journeys a swimlane names are the ones Stage 5–6 must prove), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+sequence-diagrams	3	architecture/sequence-diagrams.md|architecture/sequence-*.md|architecture/diagrams/sequence*.md	Mermaid sequenceDiagram per integration or agent call — caller, Mendix microflow, external system, sync/async, timeout, fallback; the agent-wiring diagram of skills/architecture-blueprint.md Step 3c is one instance	skills/checkpoints/checkpoint-architecture.md Q3 agent-wiring half, skills/rest-integration-first-time-right.md (build-time reader for the REST ones), skills/mendix-agents.md, bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+erd	3	architecture/erd.md|architecture/domain-model.md|architecture/diagrams/erd*.md	Mermaid erDiagram of the TARGET domain across modules — entities, associations, ownership per module; the blueprint's layer diagram shows modules, not entities, and .mx-brd.json shows one module at a time	skills/checkpoints/checkpoint-architecture.md Q2 (cross-module data strategy — the picture that question is about), skills/modularize-domain.md, bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+nfr-sheet	3	architecture/nfr.md|architecture/nfrs.md|architecture/non-functional-requirements.md	One table: NFR, target, how measured, where in the model it is enforced (XPath, index, batch size, timeout) — the per-NFR expansion of the list CAC-3's open question writes to project-profile.md	skills/checkpoints/checkpoint-architecture.md open question (the list), skills/architecture-blueprint.md Step 5 (the register that must not lose them), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+integration-contracts	3	architecture/integration-contracts.md|architecture/integrations.md|architecture/integrations/*.md	Per integration: endpoint, auth, payload in/out, error handling, owner, test double — written BEFORE the build plan so the plan can sequence it	skills/rest-integration-first-time-right.md (reads it first thing at Stage 5), skills/architecture-blueprint.md Step 5 (the integrations register), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+test-plan	4	architecture/test-plan.md|docs/test-plan.md	Per module: the journeys to prove, the fixtures they need, the DB assertions, the edge cases — the plan-side twin of the coverage ledger, written per skills/testing-shape.md before any MDL	skills/checkpoints/checkpoint-build.md (the optional-artifacts question), skills/testing-shape.md, skills/journey-proof.md, skills/fixture-seeding.md (Stage-5 readers), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+acceptance-criteria	4	architecture/acceptance-criteria.md|docs/acceptance-criteria.md	Per module: what "done" means beyond CE-error-free — the Stage-4 "User defines" row of conversion-runbook.md §2, written down instead of held in chat; each criterion names the journey or check that proves it	conversion-runbook.md §2 Stage 4 "User defines" row, skills/module-brief.md (the brief's Done section is where these land per module), skills/module-review.md (the confirm step reads them), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
+demo-script	5	docs/demo-script.md|docs/demo/script.md	The narrated walk-through a human will give — beats, pages, fixtures on screen, what the audience must see happen; written at the Stage-5 open so the build front-loads what the demo needs	skills/record-demo-video.md (its input), skills/handoff-to-studio-pro.md §8 (demo data the script depends on), bin/lib/closeout.sh	migration,requirements,greenfield,existing-app-change	optin
diff --git a/bin/lib/intake-template.sh b/bin/lib/intake-template.sh
index 81b7a0c..d3fd2b0 100644
--- a/bin/lib/intake-template.sh
+++ b/bin/lib/intake-template.sh
@@ -43,14 +43,17 @@ present — is the agent's homework, brought back as "I found X, confirm?" rathe
 here. Do that homework FIRST: it is what turns each question below into a recommendation
 with evidence instead of a blank prompt.
 
-## 1. Entry mode: migration, requirements-driven, or greenfield?
+## 1. Entry mode: migration, requirements-driven, greenfield, or change an existing app?
 
 _Not yet asked._ The agent proposes with evidence and the user confirms — never a silent
 inference (conversion-runbook.md "Entry Modes"; classification rules apply in order, first
-match wins: any legacy source → migration; else any specs/BRDs/wireframes →
-requirements-driven; else greenfield). Auditing or regression-testing an app nobody is
-rebuilding is not a mode at all — that routes to existing-app-assurance.md and skips the
-pipeline. Getting this wrong skips whole stages: real misrouting, 2026-07-14.
+match wins: a live Mendix `.mpr` you are adding to or altering, not rebuilding → change an
+existing app (record it verbatim as `Change an existing app`; existing-app-change.md); else
+any legacy source → migration; else any specs/BRDs/wireframes → requirements-driven; else
+greenfield). Auditing or regression-testing an app nobody is changing is not a mode at all —
+that routes to existing-app-assurance.md and skips the pipeline. Getting this wrong skips
+whole stages: real misrouting, 2026-07-14; and until 2026-09-22 this question listed only
+three modes, so a session changing a live app had no option to pick.
 
 ## 2. What is this project, and what is driving it?
 
diff --git a/skills/conversion-runbook.md b/skills/conversion-runbook.md
index 6e80699..a4b69b5 100644
--- a/skills/conversion-runbook.md
+++ b/skills/conversion-runbook.md
@@ -113,17 +113,19 @@ The stages are the same for everyone; what differs is where you enter and which
 
 **The entry mode is a Stage-P interview decision, not a silent inference.** The agent proposes a mode *with evidence* ("you have specs in X and source in Y, so…") and records it `CONFIRMED` in `PROJECT.md` before any stage is skipped. A skipped stage in the wrong mode is a gap; in the confirmed mode it's correct. Classification rules — apply in order, first match wins:
 
-1. **Any legacy/source code exists** (even a reference implementation you're not "migrating" — if it encodes behavior you want, it gets analyzed) → **Migration** (or at minimum, Stage 1 Path A runs on it).
-2. **Any requirements artifacts exist** — specs, BRDs, context docs, wireframes, workshop outputs → **Requirements-driven**. Having "complete" specs does *not* mean skipping to Stage 5: stages 2–4 are where those specs become validated BRDs, an architecture, module boundaries, a design system, and an ordered plan. Skipping them means improvising all of that mid-build.
-3. **Neither** — you're genuinely starting from a conversation → **Greenfield**. This is the narrowest mode, not the default for "no legacy system."
+1. **The app you are changing already exists in Mendix and stays** — a live `.mpr` you are adding to or altering, not rebuilding → **Change an existing app** (`existing-app-change.md`). The knowledge base comes from the model itself (Path D), stages 2–4 run over the slice being changed, and every gate from Stage 5 on is also a regression gate. Auditing or testing an app nobody is changing is not this mode — that is à-la-carte `existing-app-assurance.md`, no pipeline.
+2. **Any legacy/source code exists** (even a reference implementation you're not "migrating" — if it encodes behavior you want, it gets analyzed) → **Migration** (or at minimum, Stage 1 Path A runs on it).
+3. **Any requirements artifacts exist** — specs, BRDs, context docs, wireframes, workshop outputs → **Requirements-driven**. Having "complete" specs does *not* mean skipping to Stage 5: stages 2–4 are where those specs become validated BRDs, an architecture, module boundaries, a design system, and an ordered plan. Skipping them means improvising all of that mid-build.
+4. **None of the above** — you're genuinely starting from a conversation → **Greenfield**. This is the narrowest mode, not the default for "no legacy system."
 
-(Real misrouting incident, 2026-07-14: a project with full specs + analyzable source was classified greenfield "because there's nothing to migrate," proposing to skip 0–4 — exactly what rules 1–2 exist to prevent.)
+(Real misrouting incident, 2026-07-14: a project with full specs + analyzable source was classified greenfield "because there's nothing to migrate," proposing to skip 0–4 — exactly what rules 2–3 exist to prevent. Second incident, 2026-09-22: `intake.md` Q1 offered only three modes, so a session changing a live app could not pick the fourth even though `gate-check.sh` already recognised it — rule 1 and the table row below are the fix.)
 
 | You're starting from… | Mode | Stages that run | What changes |
 |---|---|---|---|
 | **Legacy source code** (± docs, ± SME) | **Migration** | P, 0–7 (all) | The default everything below describes. Path A (code extractors) always runs. |
 | **Requirements only** — BRDs, specs, workshop outputs, wireframes; no legacy code | **Requirements-driven** | P, 0–6 (skip 7) | Stage 0 runs. `document-discovery.md` runs over the whole corpus for the inventory, **and** the extraction call runs per extractable structure inside it — a schema, a table dump, a data export or entity tables in a spec each get one; `N/A` is earned on evidence, never on the mode label (`source-triage.md` owns that rule — see "Stage 0 runs in every entry mode" below). Stage 1 runs Path B (`kb-generation.md`) + Path C (SME) only; Path A is declared not-applicable, not "skipped". Stages 2–6 run unchanged — BRDs come from documents instead of extraction. Stage 7 only if legacy data exists somewhere to cut over. **A text-native corpus — Markdown and HTML pages, no legacy code, no Office/PDF containers — takes the docs-ready fast path below.** |
 | **Just an idea / a running start on the model** | **Greenfield** | P (light), 0 (scope only), 5–6 | Stages 1–4 collapse to whatever plan the user already has. Stage 0 does **not** collapse: with no corpus there is nothing to grade, but the scope conversation is exactly as load-bearing as it is anywhere else, so Stage 0 reduces to CAC-1's brainstorm and its sign-off. If you find yourself inventing requirements mid-build, you're actually in requirements-driven mode — back up to Stage 2. |
+| **A live Mendix app you are changing** — a slice is being added or altered, the rest stays as it is | **Change an existing app** | P, 0–6 per slice (skip 7 — the app is live) | `existing-app-change.md` owns the mode. Stage 1 runs **Path D** — `mxcli` queries the `.mpr` into the knowledge base, scoped to the slice **plus its blast radius**, which Stage 0 writes into `triage.md` as its own section. A regression net (Track B baseline) goes under the app before anything changes. Stages 2–4 run over the slice only: one as-is/to-be BRD per capability being changed, Stage 3 in full only when the change crosses a module boundary, adds an integration or alters the domain model — otherwise it collapses to "which existing module owns this". Stage 7 is N/A in the register with that reason. The coverage ledger is `mxcli brain plan`, not a hand-kept file. |
 
 ### Stage 0 runs in every entry mode
 
diff --git a/toolkit-guide.html b/toolkit-guide.html
index 376ac7d..c88310b 100644
--- a/toolkit-guide.html
+++ b/toolkit-guide.html
@@ -81,7 +81,7 @@
   <h1>mxcli Project Toolkit — how this works</h1>
   <p class="lede">You point this toolkit at legacy source code <em>or</em> a stack of requirements, and it interviews you through to a running Mendix app. Every stage produces an artifact you can show a customer, and every decision you make is recorded — nothing is silently decided for you.</p>
 
-  <h2>1 · Four ways in — pick what you're starting from</h2>
+  <h2>1 · Five ways in — pick what you're starting from</h2>
   <div class="cards">
     <div class="card">
       <h3>Migration</h3>
@@ -98,6 +98,11 @@ <h3>Greenfield</h3>
       <div class="stages">Stages P, 5–6</div>
       <p>You already know what to build. Skip straight to the Mendix build discipline: gated module-by-module construction, then end-to-end testing.</p>
     </div>
+    <div class="card">
+      <h3>Change an existing app</h3>
+      <div class="stages">Stages P, 0–6 per slice</div>
+      <p>You have a live Mendix app and are adding to or altering one slice of it. The knowledge base is queried from the model itself, a regression net goes under the app before anything changes, stages 2–4 run over the slice only, and every build gate is also a regression gate. No cutover — the app never stops being live.</p>
+    </div>
     <div class="card">
       <h3>Just the tools</h3>
       <div class="stages">No pipeline</div>

From 6d4147cb4265da1f824e89752880123b14bda12e Mon Sep 17 00:00:00 2001
From: r <r@x>
Date: Tue, 22 Sep 2026 12:35:09 +0000
Subject: [PATCH 4/4] fix(tests): bug12 sync fixture expects the four-mode
 intake Q1 heading

sync-project.sh reports the missing kickoff question using the current
template's heading, which now names the fourth entry mode; the fixture
still grepped for the three-mode wording.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw
---
 tests/wave2/test-bug12-sync.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/wave2/test-bug12-sync.sh b/tests/wave2/test-bug12-sync.sh
index 28d287e..792aa79 100755
--- a/tests/wave2/test-bug12-sync.sh
+++ b/tests/wave2/test-bug12-sync.sh
@@ -340,7 +340,7 @@ BEFORE="$(md5 -q "$P10/intake.md" 2>/dev/null || md5sum "$P10/intake.md" | cut -
 O="$("$SYNC" "$P10" 2>&1)"
 case "$O" in *"predates the current kickoff question set"*) ok "a plain run REPORTS the old set" ;;
               *) bad "a plain run REPORTS the old set" ;; esac
-case "$O" in *"Entry mode: migration, requirements-driven, or greenfield?"*)
+case "$O" in *"Entry mode: migration, requirements-driven, greenfield, or change an existing app?"*)
       ok "  and names the question that matters most" ;;
   *)  bad "  and names the question that matters most" ;; esac
 case "$O" in *"licence/security constraints"*)