diff --git a/CHANGELOG.md b/CHANGELOG.md index 8ba727d1..b574dd26 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(existing-app-change): **Stage 0 in the change-an-existing-app mode now asks in plain words.** "What do you want to work on", "do you have input documents", "what else does it touch" replace slice / blast radius in the skill, intake Q4–Q5, the gate message, the pipeline walk and the routing row; migration keeps its own vocabulary — Maurits Visser - new(existing-app-change): **map the app first, ask what to do with the findings, and let a project park until the change is named.** Stage 0 in this mode now opens with the app analysis (`app-facts.sh` + `app-report.sh`, `skills/app-analysis.md`), run without asking since it is read-only and takes about a minute, followed by the question the user owns: fix / log / accept per top finding. Kickoff no longer opens with "which slice?"; the slice and its blast radius (read from the map's tangles and edges, not recomputed) come at Stage 0b, when the change arrives. `artifact-manifest.tsv` owes the map in this mode (`app-report`, Stage 0); gate-check reports a mapped project with no change as Stage 0 `PENDING` instead of a permanent FAIL, and its Stage 1 hint names Path D instead of an extractor. `existing-app-assurance.md` Track A starts from the same report, so an audit that turns into a change does not redo it. Fixture: `test-bug03-gates.sh` T12. Field run: a live client workflow app — 28 modules, one tangle of 7 of 9 own modules, 213 loop microflows, mapped in 76 s; gate-check read it PENDING/parked with 0 needing attention — Maurits Visser - docs(pipeline-walks): **`docs/pipeline-walks.html` — a process diagram per entry mode, with the scripts run at every step.** Shared spine, migration, requirements-driven (incl. the docs-ready fast path), greenfield, change-an-existing-app (opening with the app-mapping step: `SHOW STRUCTURE`, `graph-report`, `lint`, `report`, security matrix, `marketplace diff`), à-la-carte tracks A/A2/B, and the Stage 5 BUILD→GATE→PROVE→LOOK→CONFIRM loop, each as a mermaid flowchart plus a stage/what/scripts table. Linked from the README entry-modes paragraph — Maurits Visser - fix(bin/doctor.sh): **doctor told every Podman user "docker is not installed"** — the section advertised Podman in its advice text ("Rancher Desktop or Podman … are common substitutes") while all four probes ran `docker` only: `docker info`, the `command -v docker` gate, the not-installed warning, and a start hint that said `open -a Docker`. So a machine fully able to run the container lane on Podman, but without the docker shim, was reported broken — and on a team that cannot licence Docker Desktop that reads as "go install software you are not allowed to have" (a colleague's machine-ready status carried "Docker not installed" as a known issue; they may have had Podman all along). Detection is now docker-then-podman (`MXTK_CONTAINER_RUNTIME` forces one), the runtime is **named** in the report (`podman responding — …`), the start hint knows `podman machine start` / `podman.socket`, and the not-installed warning names Podman as the licence-free option instead of implying Docker Desktop is required. Same bounded background/poll/kill probe for both, same 0/1/2 exit contract; `mxcli docker check` invocation deliberately untouched (different repo). **Not field-run** — no container runtime in the authoring container; needs one run on a Mac with Podman and no `docker` on PATH. Driver: the Mendix migration team's Docker Desktop licensing constraint — Maurits Visser diff --git a/CONVERSION-RUNBOOK.md b/CONVERSION-RUNBOOK.md index 710e0e5a..ca339816 100644 --- a/CONVERSION-RUNBOOK.md +++ b/CONVERSION-RUNBOOK.md @@ -22,7 +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 | +| A live Mendix app you are changing | Change an existing app | P, 0–6 per change | ## Where you run this — detected, not asked diff --git a/README.md b/README.md index 1528a9e5..d207470e 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ Serves five ways in — four pipeline entry modes that share the same stages, pl - **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`. +- **Changing an existing app** (a live `.mpr`, a feature or flow being added or altered) — stages P, 0–6 per change; 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. @@ -532,7 +532,7 @@ Every mxcli project has a `.ai-context/skills/` directory (bundled by `mxcli ini | Stage 0 sign-off when the inventory is at or under 1 module / 8 screens / 25 use cases, or the user says the app is small — declare the tier, then apply its per-stage caps and the three artifact waivers | `skills/small-project-tier.md` | | Generating a new project's CLAUDE.md — baseline routing plus project-specific facts | `skills/bootstrap-project.md` | | Setting up or resuming an mxcli project in a cloud/ephemeral container — the one-time setup order (mxcli download → mxcli init → init-project.sh → sources decision → push) and the commit-and-push loop that survives container reclaim | `skills/cloud-dev-environment.md` | -| Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over the changed slice plus its blast radius only, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | `skills/existing-app-change.md` | +| Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over what changes plus what it touches, nothing more, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | `skills/existing-app-change.md` | | Setting up or wiring a COMPANY BRAIN — the private tier between the toolkit and a project for own skills, conventions, lint rules, MDL snippets and approved MPKs; and deciding whether something goes to the toolkit, the company brain or docs/brain/ | `skills/company-brain.md` | | Cutover and retrospective — promoting proven patterns back into the toolkit | `skills/close-the-loop.md` | | Before citing ANY behavioural claim about the harness, the Mendix runtime or a test tool as evidence — a claim not in the register may not be cited | `skills/measured-claims.md` | diff --git a/ROUTING.md b/ROUTING.md index bca5d9ab..6bcf33aa 100644 --- a/ROUTING.md +++ b/ROUTING.md @@ -51,7 +51,7 @@ picks the row up. That is the whole procedure — there is no second list to rem | Deciding who answers a question — before putting any batch to the user. gap/conflict/choice/user-only is what keeps a gate batch at four questions instead of 127 | `bin/question-kinds.sh` | ba | 1,2,3 | baseline | | Generating a new project's CLAUDE.md — baseline routing plus project-specific facts | `skills/bootstrap-project.md` | ba | P | ondemand | | Setting up or resuming an mxcli project in a cloud/ephemeral container — the one-time setup order (mxcli download → mxcli init → init-project.sh → sources decision → push) and the commit-and-push loop that survives container reclaim | `skills/cloud-dev-environment.md` | all | P | ondemand | -| Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over the changed slice plus its blast radius only, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | `skills/existing-app-change.md` | ba,architect | P,0 | ondemand | +| Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over what changes plus what it touches, nothing more, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | `skills/existing-app-change.md` | ba,architect | P,0 | ondemand | | Setting up or wiring a COMPANY BRAIN — the private tier between the toolkit and a project for own skills, conventions, lint rules, MDL snippets and approved MPKs; and deciding whether something goes to the toolkit, the company brain or docs/brain/ | `skills/company-brain.md` | all | - | ondemand | | Cutover and retrospective — promoting proven patterns back into the toolkit | `skills/close-the-loop.md` | all | 7 | ondemand | | Before citing ANY behavioural claim about the harness, the Mendix runtime or a test tool as evidence — a claim not in the register may not be cited | `skills/measured-claims.md` | all | - | ondemand | diff --git a/agents/architect-agent.md b/agents/architect-agent.md index 09db2f50..d3be5b8d 100644 --- a/agents/architect-agent.md +++ b/agents/architect-agent.md @@ -52,7 +52,7 @@ You own architecture and build-plan decisions for {{PROJECT}}. Hard rule: you ne | `project-bin/assemble-prototype.js` | After every wireframe edit: assembles design/wireframes/*.html into design/prototype.html, one hash-routed page a stakeholder can click through instead of twenty separate files. Generated, never edited (design-artifacts.md Step 3) | | `project-bin/check-prototype-links.js` | Before wireframes pass to the build loop, and with --brd before a BRD is signed off: dead #/route links, orphan screens, controls with no data-bind and no data-cut, BRD routes no screen has, screens no use case walks (design-artifacts.md Step 3c, brd-validation.md check 8) | | `skills/cloud-dev-environment.md` | Setting up or resuming an mxcli project in a cloud/ephemeral container — the one-time setup order (mxcli download → mxcli init → init-project.sh → sources decision → push) and the commit-and-push loop that survives container reclaim | -| `skills/existing-app-change.md` | Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over the changed slice plus its blast radius only, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | +| `skills/existing-app-change.md` | Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over what changes plus what it touches, nothing more, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | | `project-bin/app-facts.sh` | Collecting the facts an app dossier is written from: forces a full catalog build, module edges through the real module column, strongly connected components, describes every loop-containing microflow and parses the loop bodies; exit 2 on a stale, fast-mode or schema-incomplete catalog, never a verdict | | `skills/app-analysis.md` | Building or refreshing the standing dossier of an EXISTING app before changing it: inventory, module dependency shape, loop risk patterns, each section with a verdict and a fault where nothing was measured (a standing document; nothing else in the toolkit reads it yet) | | `skills/layering-review.md` | Checking whether an EXISTING app's module boundaries still hold: the layer map (bin/app-layer-map.sh) computes the order the modules would stack in and draws only the edges that point back up, so one tangle of N mutually reachable modules becomes a named list of edges with a weight and a ref kind; Stage 3 in existing-app-change mode, and the honest blast radius for a slice | diff --git a/agents/ba-agent.md b/agents/ba-agent.md index 04e7b03b..a64df0a1 100644 --- a/agents/ba-agent.md +++ b/agents/ba-agent.md @@ -64,7 +64,7 @@ You run discovery and the interview gates for {{PROJECT}}. You never touch the ` | `bin/brd-report.sh` | Reviewing what the BRDs actually say — the Stage 2 surface, for BRDs from any source. Reads every knowledge base at once, and keeps a section that is absent-because-not-applicable apart from one that is absent-because-expected | | `skills/bootstrap-project.md` | Generating a new project's CLAUDE.md — baseline routing plus project-specific facts | | `skills/cloud-dev-environment.md` | Setting up or resuming an mxcli project in a cloud/ephemeral container — the one-time setup order (mxcli download → mxcli init → init-project.sh → sources decision → push) and the commit-and-push loop that survives container reclaim | -| `skills/existing-app-change.md` | Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over the changed slice plus its blast radius only, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | +| `skills/existing-app-change.md` | Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over what changes plus what it touches, nothing more, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance | | `skills/app-analysis.md` | Building or refreshing the standing dossier of an EXISTING app before changing it: inventory, module dependency shape, loop risk patterns, each section with a verdict and a fault where nothing was measured (a standing document; nothing else in the toolkit reads it yet) | | `skills/layering-review.md` | Checking whether an EXISTING app's module boundaries still hold: the layer map (bin/app-layer-map.sh) computes the order the modules would stack in and draws only the edges that point back up, so one tangle of N mutually reachable modules becomes a named list of edges with a weight and a ref kind; Stage 3 in existing-app-change mode, and the honest blast radius for a slice | | `skills/assess-migration.md` | Assessing or planning a migration up front, before any pipeline is chosen | diff --git a/bin/gate-check.sh b/bin/gate-check.sh index a902c938..82a2086c 100755 --- a/bin/gate-check.sh +++ b/bin/gate-check.sh @@ -827,9 +827,9 @@ check_stage_0() { elif printf '%s' "$signer" | grep -q '\[' && [ "$ENTRY_MODE" = "existing-app-change" ] \ && [ -s "$PROJECT_DIR/analysis/app-report.json" ]; then # Mapped and waiting for a change is a normal state in this mode (existing-app-change.md - # §"Map the app first"): there is no slice to sign off yet, so this is not-started, not wrong. + # §"Map the app first"): there is nothing to sign off yet, so this is not-started, not wrong. # Without it a parked project read "needs attention" forever (existing-app field run, 2026-09-22). - echo "PENDING|app mapped (analysis/app-report.html), waiting on the change — triage.md is signed off at Stage 0b, once the user names the slice and its blast radius is written ($f, ## Sign-off)" + echo "PENDING|app mapped (analysis/app-report.html), waiting on the change — triage.md is signed off at Stage 0b, once the user says what to work on and what it touches is written ($f, ## Sign-off)" elif printf '%s' "$signer" | grep -q '\['; then echo "FAIL|'Confirmed by:' still holds the shipped placeholder: \"$signer\" — replace it with whatever the user actually said (\"confirmed in chat 2026-08-20\" is fine; a full name is not required) ($f, ## Sign-off)" else diff --git a/bin/lib/intake-template.sh b/bin/lib/intake-template.sh index d3fd2b0e..a6243275 100644 --- a/bin/lib/intake-template.sh +++ b/bin/lib/intake-template.sh @@ -69,17 +69,24 @@ _Not yet asked._ Default inherited from Q2 — (b) implies as-is, (c) licenses r put the inherited default to the user and ask what to override. This decides whether every Stage 3 fit-gap finding is a gap to close or an opportunity to take. -## 4. Scope boundary: the whole application, or a slice? +## 4. What are we working on: the whole application, or a part of it — and what else does that touch? -_Not yet asked._ Name what is explicitly OUT, not just what is in — "out" is the half that +_Not yet asked._ Name the topic in plain words — a feature, a flow, a module, a fix, or the +whole app. Say what else it touches, and name what is explicitly OUT — "out" is the half that gets forgotten and rebuilt anyway. A module-sized source is the common case and is easy to -mistake for a whole app; if it is a slice, say what the slice must keep working with. +mistake for a whole app. Also ask whether there are input documents — user stories, tickets, +a spec: they go in `sources/`, and "none, the app plus my description" is a fine answer. For +an existing app this is settled at Stage 0b, after the map, so +`Unverified — how to verify: named when the change request arrives (Stage 0b)` is a legitimate +kickoff answer. -## 5. What must NOT change? +## 5. Of what we touch, what must stay exactly as it is? _Not yet asked._ Integrations, data contracts, external URLs, scheduled jobs, reports other systems consume. These are the constraints that invalidate an architecture late and cheaply -if found now; they are rarely visible in the source, because they live in its consumers. +if found now; they are rarely visible in the source, because they live in its consumers. For +an existing app the default is that nothing beyond the ask changes — this question names the +things the change must not break. ## 6. Are there licence/security constraints on storing this client's source in this workspace? diff --git a/bin/lib/skill-routing.tsv b/bin/lib/skill-routing.tsv index 9a63104f..44876f15 100644 --- a/bin/lib/skill-routing.tsv +++ b/bin/lib/skill-routing.tsv @@ -112,7 +112,7 @@ mxcli-bugs bug-logs/mxcli-bugs.md Reading a whole class of tool defects (a retes bootstrap-project skills/bootstrap-project.md Generating a new project's CLAUDE.md — baseline routing plus project-specific facts ba P ondemand spine cloud-dev-environment skills/cloud-dev-environment.md Setting up or resuming an mxcli project in a cloud/ephemeral container — the one-time setup order (mxcli download → mxcli init → init-project.sh → sources decision → push) and the commit-and-push loop that survives container reclaim all P ondemand spine existing-app-assurance skills/existing-app-assurance.md Auditing or regression/e2e-testing an EXISTING app — no intake, no stages, no gates test,review 6 ondemand verify -existing-app-change skills/existing-app-change.md Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over the changed slice plus its blast radius only, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance ba,architect P,0 ondemand spine +existing-app-change skills/existing-app-change.md Changing an EXISTING Mendix app — adding a feature, altering a flow, restructuring a module — when it has no BRDs, no architecture doc and no wireframes: the knowledge base comes from the live model (Path D), stages 2–4 run over what changes plus what it touches, nothing more, and the Track B regression baseline is the precondition; audit-only stays in existing-app-assurance ba,architect P,0 ondemand spine app-facts project-bin/app-facts.sh Collecting the facts an app dossier is written from: forces a full catalog build, module edges through the real module column, strongly connected components, describes every loop-containing microflow and parses the loop bodies; exit 2 on a stale, fast-mode or schema-incomplete catalog, never a verdict architect,review 0,6 ondemand architecture app-analysis skills/app-analysis.md Building or refreshing the standing dossier of an EXISTING app before changing it: inventory, module dependency shape, loop risk patterns, each section with a verdict and a fault where nothing was measured (a standing document; nothing else in the toolkit reads it yet) ba,architect,review P,0,6 ondemand architecture layering-review skills/layering-review.md Checking whether an EXISTING app's module boundaries still hold: the layer map (bin/app-layer-map.sh) computes the order the modules would stack in and draws only the edges that point back up, so one tangle of N mutually reachable modules becomes a named list of edges with a weight and a ref kind; Stage 3 in existing-app-change mode, and the honest blast radius for a slice architect,ba 0,3 ondemand architecture diff --git a/docs/pipeline-walks.html b/docs/pipeline-walks.html index 7e390a8b..dbd31540 100644 --- a/docs/pipeline-walks.html +++ b/docs/pipeline-walks.html @@ -244,7 +244,7 @@
The knowledge base comes from the model itself (Path D). The first real step is mapping the whole app, run without asking, followed by the one question the user owns: what to do with each top finding. The project may park there until a change is named; Stage 0b then adds the blast radius of the slice, read from the map. A regression net goes under the app before anything changes, and every gate from Stage 5 on is also a regression gate.
+The knowledge base comes from the model itself (Path D). The first real step is mapping the whole app, run without asking, followed by the one question the user owns: what to do with each top finding. The project may park there until a change is named; Stage 0b then asks what the user wants to work on, whether there are input documents, and what else it touches, read from the map. A regression net goes under the app before anything changes, and every gate from Stage 5 on is also a regression gate.
flowchart TD P["P Kickoff light
./mxcli in place, then init-project.sh
open question: what is driving it?
register: Change an existing app CONFIRMED"] --> M["0a Map the app, not asked, just run
bin/app-facts.sh then bin/app-report.sh
(app-analysis.md, about a minute)"] @@ -254,18 +254,18 @@Change an existing app A live .mpr yo PARK -.->|change arrives| S0 PK -- "only audits / tests wanted" --> AS["switch to existing-app-assurance
Track A starts from the same report"] PK -- "yes" --> S0 - S0["0b Triage ✋ which slice,
what is its blast radius"] --> S0a["blast radius into triage.md, read from the map:
dependencies.json tangles and edges,
then associations, SEARCH, SHOW PAGES IN,
published / consumed services"] + S0["0b Scope ✋ what do you want to work on,
what else does it touch"] --> S0a["what it touches into triage.md, read from the map:
dependencies.json tangles and edges,
then associations, SEARCH, SHOW PAGES IN,
published / consumed services"] S0a --> S0b["capability map from SHOW MODULES
extraction rows N/A
CAC-1, sign-off"] S0b --> RN["Regression net under the app
Track B baseline from existing-app-assurance"] - RN --> S1["1 Analysis Path D
DESCRIBE ENTITY, SHOW MICROFLOWS IN,
graph-report scoped to slice + blast radius
counts recorded, Path A = N/A, CAC-1b"] - S1 --> S2["2 Requirements
slice-only BRDs, as-is / to-be
CAC-2, CAC-3"] + RN --> S1["1 Analysis Path D
DESCRIBE ENTITY, SHOW MICROFLOWS IN,
graph-report scoped to the change + what it touches
counts recorded, Path A = N/A, CAC-1b"] + S1 --> S2["2 Requirements
BRDs for what changes only, as-is / to-be
CAC-2, CAC-3"] S2 --> Q{"crosses a module boundary,
adds an integration,
alters the domain model?"} Q -- "yes" --> S3["3 Architecture and Design ✋ in full
wireframes for changed screens only
design system = captured existing styling"] Q -- "no" --> S3b["3 collapses to:
which existing module owns this"] S3 --> S4 - S3b --> S4["4 Build Plan ✋ slice only
respects live data
coverage ledger = mxcli brain plan
CAC-5, build-ready"] + S3b --> S4["4 Build Plan ✋ what changes only
respects live data
coverage ledger = mxcli brain plan
CAC-5, build-ready"] S4 --> S5["5 Build
module loop + regression net must stay green
mxcli brain capture per leaf"] - S5 --> S6["6 Test
slice journeys + full regression suite"] + S5 --> S6["6 Test
journeys of the change + full regression suite"] S6 --> S7["7 Cutover N/A: the app is live"] classDef stop fill:#f8dedb,stroke:#b3261e,color:#1d2430 class S0,S3,S4 stop @@ -278,12 +278,12 @@Change an existing app A live .mpr yo
Step What it does Scripts and commands P light Scaffold. Intake answers come from the model, not from the user's memory. Run the machine check once. bin/doctor.shbin/init-project.sh <project>- 0a Map the app Run, do not ask: it is read-only and takes about a minute. Inventory, module tangles, loop-risk microflows, dead elements, with a fix-first list. Show the report and ask the user to disposition each top finding (fix in this work / log / accept); answers go to PROJECT.md. The project may then park until a change is named. Owed in this mode as theapp-reportartifact. Lint, security matrix and marketplace drift fill the report's Security and Lint sections.bin/app-facts.sh(app-analysis.md)bin/app-report.sh <project>./mxcli lint -p app.mpr./mxcli -p app.mpr -c "SHOW SECURITY MATRIX"./mxcli marketplace diff <content-id> -p app.mpr(v0.18+)+ 0b Triage ✋ Once the change is named: which slice, and what is its blast radius, starting from the map's tangles and edges. The radius is written into triage.mdas its own section, with counts. Capability map from the module list. CAC-1 and sign-off.SHOW ASSOCIATIONS IN <Module>·DESCRIBE ENTITY M.ESEARCH '<entity>'·SHOW PAGES IN <Module>SHOW REFERENCES OF M.E·SHOW IMPACT OF M.Eanalysis/app-facts/dependencies.jsonfor the tanglebin/gate-check.sh <project> 00b Scope ✋ Once the change is named: what do you want to work on, do you have input documents, and what else does it touch — starting from the map's tangles and edges. What it touches is written into triage.mdas its own section, with counts. Capability map from the module list. CAC-1 and sign-off.SHOW ASSOCIATIONS IN <Module>·DESCRIBE ENTITY M.ESEARCH '<entity>'·SHOW PAGES IN <Module>SHOW REFERENCES OF M.E·SHOW IMPACT OF M.Eanalysis/app-facts/dependencies.jsonfor the tanglebin/gate-check.sh <project> 0- Regression net Track B from the assurance skill, before any change: harness, action inventory, one journey per action, DB assertions, wiring sweep, LOOK pass, committed baseline. see Track B below project-bin/coverage-preflight.sh --assess --module <M>+ 1 Path D Query the model into the knowledge base, scoped to slice plus blast radius. Record counts. Path A declared N/A with attribution. Path C matters most here: the people who know why the app is the way it is. SHOW ENTITIES IN·DESCRIBE ENTITY·SHOW MICROFLOWS INDESCRIBE MICROFLOW·DESCRIBE PAGEbin/extraction-report.sh <project>bin/gate-check.sh <project> 11 Path D Query the model into the knowledge base, scoped to the change plus what it touches. Record counts. Path A declared N/A with attribution. Path C matters most here: the people who know why the app is the way it is. SHOW ENTITIES IN·DESCRIBE ENTITY·SHOW MICROFLOWS INDESCRIBE MICROFLOW·DESCRIBE PAGEbin/extraction-report.sh <project>bin/gate-check.sh <project> 12 Requirements One as-is / to-be BRD per capability being changed. Nothing for the untouched rest. bin/brd-report.sh·bin/open-questions.sh --stage 2- 3 Design Full only when the change crosses a module boundary, adds an integration or alters the domain model. Otherwise "which module owns this". Wireframes for changed screens only. bin/gate-check.sh <project> 3+ 4 Build plan ✋ Slice-only plan that respects live data. Coverage ledger lives in the brain, not a hand-kept file. ./mxcli brain init·./mxcli brain planbin/gate-check.sh <project> build-ready4 Build plan ✋ Plan for what changes only, that respects live data. Coverage ledger lives in the brain, not a hand-kept file. ./mxcli brain init·./mxcli brain planbin/gate-check.sh <project> build-ready5–6 Module loop unchanged. Every gate also re-runs the regression net. Each finished leaf is captured in the brain. bin/exec.sh s.mdl·project-bin/verify-module.sh <M>./mxcli brain capture "<leaf>"·./mxcli brain check7 N/A in the register: the app is already live. register line only