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

[MendixMau]

What changed and why

Two things ride on this branch.

1. "Change an existing app" is now a wired fourth pipeline entry mode (d0cd109)

Until now only bin/gate-check.sh (via bin/lib/entry-mode.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, even though gate-check would have waived Stage 7 correctly had it been picked.

• bin/lib/intake-template.sh — Q1 now lists four modes with ordered classification rules (live .mpr being altered → change an existing app; else legacy source → migration; else specs → requirements-driven; else greenfield) and tells the agent to record the answer verbatim as Change an existing app, which entry-mode.sh already maps to existing-app-change. À-la-carte audit/testing is called out as not a mode.
• skills/conversion-runbook.md "Entry Modes" — new rule 1 (existing rules renumbered), a table row for the mode (stages P, 0–6 per slice; Stage 1 = Path D; every gate from Stage 5 is a regression gate; Stage 7 N/A; ledger is mxcli brain plan), and the incident note.
• CONVERSION-RUNBOOK.md pointer table — matching row.
• bin/lib/artifact-manifest.tsv — existing-app-change added to every P–6 row except coverage-ledger; header comment documents the policy. Stage-3 rows stay owed: a collapsed Stage 3 is recorded via the register's stage waiver, never by silence.
• README.md, toolkit-guide.html, CLAUDE.md — four pipeline entry modes plus the à-la-carte no-pipeline route, i.e. five ways in (new guide card, new README bullet).
• CHANGELOG.md — entry appended in the same commit.

2. Windows full test-run prompt (2b13f57, 7796929)

Adds docs/windows-test-run.md: a single paste-able, unattended Claude Code prompt for a Windows (Git Bash) machine that runs CI guards, both fixture suites, 27 Windows-relevant fixtures with their correct subjects, the tools on committed inputs, and a field run on a scratch project, writing one results file (PASS / PASS(known) / FAIL / SKIP). Placeholders only, no home paths, no client names. Also fixes the README / guide headlines that still said "three ways in".

Field evidence

• Entry-mode wiring: prompted by a real run on 2026-09-22 where a session scaffolding a change to a live Mendix app found intake.md Q1 offering only three modes while gate-check.sh already reported Stage 7 WAIVED and Stage P PASS for existing-app-change. Locally verified in this branch: entry_mode_token "Change an existing app" → existing-app-change; manifest parses to 38 data rows of 7 columns, 37 carrying the mode; check-scripts, check-portability, leak guard, check-pr-discipline, and render-routing.sh --check all clean. End-to-end init-project.sh → intake Q1 → gate-check.sh on a "Change an existing app" project is the user's next test in a separate session.
• Windows doc: documentation only; every cited bin/, project-bin/, tests/, fixtures/ path checked to exist on master (0 missing). The Windows results file is the field evidence and comes back as a follow-up.

Checklist

• CHANGELOG line in the same commit (both changes)
• No client data, home paths or private repo names (manual leak grep of the diff: clean; leak guard clean)
• check-scripts, check-portability, check-pr-discipline, render-routing --check clean locally
• Routing surfaces inside ROUTING:BEGIN/END untouched
• Field test of the new mode in a separate session (user)
• Windows results file returned (follow-up, after the run)

🤖 Generated with Claude Code

https://claude.ai/code/session_01VJgWP5vEoAsNsJYqCDMGNw