integration 2026-10-14: nineteen independently reviewed PRs combined for one merge

.github/workflows/checks.yml

@@ -98,3 +98,5 @@ jobs:
         run: bash tests/lint-rules/test-batch2-rules.sh
       - name: Lint-rule unit suite, batch 3 (tests/lint-rules/test-batch3-rules.sh)
         run: bash tests/lint-rules/test-batch3-rules.sh
+      - name: Lint-rule unit suite, batch 4 (tests/lint-rules/test-batch4-rules.sh)
+        run: bash tests/lint-rules/test-batch4-rules.sh

CLAUDE.md

@@ -160,6 +160,72 @@ checkpoint script, and an expert user's reaction was "I can't even compact?":
 7. **A guard must never block the action that resolves it.** Blocking the remedy is
    perverse: warn once, then let it through.
 
+## Merging a PR — independent review before every merge
+
+**A merge go from the maintainer is not a review.** Before any PR merges, an agent that did
+**not** write it reviews the diff and returns a verdict. The builder's own report and green CI
+never count: the builder grades its own work, and CI proves only the tests the builder wrote.
+
+1. **Who reviews, and with what.** A fresh agent given the PR diff, the linked issues and the PR
+   body's description of *what* changed — never the builder's verdict, risk assessment or "all
+   checks pass" claims. One reviewer per PR, plus one composition check when several PRs in a
+   batch touch the same files. The reviewer may run the fixtures the PR adds or that target its
+   changed files, in a detached worktree — that is part of the review the maintainer asked for, not
+   a free-standing test run (see "Testing this toolkit").
+2. **What it answers, each with file:line.** *Value*: does it fix the issue as reported, and is
+   anything overbuilt? *Regression risk*: what changes for an existing project after
+   `sync-project.sh` (new FAIL / BLIND / refusals, exit codes, output another tool parses, gate
+   verdicts that flip), across both layouts and macOS / Git Bash? *Correctness*: real bugs, tests
+   that do not test what they claim, hand-written golden input where a capture was required.
+   *Context cost*: words added to always-loaded skill files — re-measured by the reviewer, not taken
+   from the PR body.
+3. **Verdict.** `MERGE`, `MERGE-AFTER-FIX` (exact fixes listed; the fixes are pushed and
+   re-reviewed before merge) or `HOLD` (goes back to the maintainer with the reason). Only `MERGE`
+   merges.
+4. **Record the verdict durably.** The squash commit body carries a line
+   `Review: MERGE — <one-line top finding or "no findings">`, and the merge announcement repeats it
+   next to CI. A merge with no `Review:` line was not reviewed.
+5. **No exceptions for size.** A one-line fix, a docs-only PR and an outside contributor's PR all
+   get the same review. "Small", "only skill text" and "CI is green" are how the exceptions start.
+   The one exception is guard rule 7's: a fix whose only purpose is to unblock master (a broken CI
+   check, a leak guard that blocks every commit) may merge first, with its review within 24 hours
+   and a `Review: PENDING (unblock)` line; the follow-up verdict is recorded as a comment on the
+   merged PR (and a follow-up fix PR if it finds anything), since a squash commit cannot be edited.
+
+**Why (real incident, 2026-10-13).** Nine PRs merged in one day on the builders' own reports and
+green CI, each carrying its builder's "all checks pass". When the maintainer asked whether value
+and regression risk had been checked, the honest answer was no: nobody who had not written the
+code had read it. The after-the-fact reviews found, among others, a journey preflight that made
+every synced project's journey rung FAULT, and an exec lock that let three writers in at once. The same day showed the cost of unread diffs in another form — the always-loaded
+skill text hit its 80,000-word cap because each PR added words that nobody outside the PR weighed.
+
+## Always-loaded skill text — the word budget
+
+`bin/render-routing.sh --check` caps the always-loaded (baseline) skill set at
+`MXTK_BASELINE_BUDGET_WORDS` — a ratchet, explained in that script's header: lowered as text moves
+out, never raised to admit growth. Room is made by **moving** text, never by deleting the text
+that does the work.
+
+1. **Protected — never removed to make room:** rules, STOP rows, denominators / completion
+   criteria, and the one-line failure example each rule is paired with. Removing one needs its own
+   PR that argues the rule itself is obsolete, with an independent review.
+2. **Movable:** incident narratives, worked examples, tables of past numbers, and a rule stated a
+   second time in another baseline file. Each moves to an on-demand file and leaves a one-line
+   pointer (path) at the same spot. A move keeps the text; nothing is lost.
+3. **Every PR that adds baseline words** states the before/after count from
+   `render-routing.sh --check` in its body, and why each addition is needed at the trigger moment.
+   The independent reviewer checks that (see "Merging a PR").
+4. **At the cap, a feature PR never squeezes other text to fit.** Room comes from a separate trim
+   PR that only moves movable text; its reviewer compares removed against moved line by line, and
+   any protected line that disappeared is a HOLD.
+5. **Trim before the cap, not at it:** when a PR would take the baseline (measured after the PR)
+   within 2,000 words of the budget, a trim PR lands first. A trim PR does not lower the ratchet by
+   itself; lowering it is a separate one-line change once the trimmed total has held for a release.
+
+**Why (2026-10-13).** One feature PR pushed the baseline to 80,466 words against the 80,000 budget
+while six other open PRs each added words; to fit, it merged two sentences in a testing skill and
+landed at 79,997. That one was harmless, but nothing stopped the next one from cutting a STOP row.
+
 ## Changelog and contributions
 
 **Every user-visible change appends its `CHANGELOG.md` line in the same commit.** That is the
@@ -172,7 +238,7 @@ and tag every few days — the release cycle is defined at the top of `CHANGELOG
 
 Contributions arrive through three lanes (`CONTRIBUTING.md`): the `contrib/inbox/` drop
 (no quality bar — triage promotes into `skills/`/`bug-logs/`/`bin/` and deletes the inbox file
-in the same commit; inbox files are unreviewed and nothing may cite them),
+in the same commit; inbox files are unreviewed — their content is not vetted for promotion — and nothing may cite them; a PR that adds one still gets the merge review below),
 `bin/harvest-learnings.sh <project-root>` (drafts inbox files from a project's bug logs,
 register promotion tables, and locally-patched installed scripts — run it at project wrap-up),
 and direct PRs held to the full field-proof bar. CI (`.github/workflows/checks.yml`) runs
@@ -277,7 +343,12 @@ to. Wide blast radius is a reason to pick the right *scoped* check, not to run e
 `bin/lib/skill-routing.tsv` and its re-render (README.md, ROUTING.md, every agent template, and
 `gate-check.sh`'s stage map at once) that check is `bin/render-routing.sh --check`.
 
-**Asking is also required for a single fixture** — name it, say what it will tell us, and wait.
+**One standing exception: the independent reviewer of a PR** (see "Merging a PR") may run the
+fixtures the PR adds or that target its changed files, without asking, in a detached worktree of
+the PR branch. That isolation is what avoids the shared-tree problem above; the reviewer still
+never runs the full suites.
+
+**Outside that reviewer exception, asking is also required for a single fixture** — name it, say what it will tell us, and wait.
 
 Where a fixture's assertions are greps over a file you changed, prefer verifying by inspection:
 read the fixture, replicate its greps against the changed file, and report that. Same signal, no

README.md

@@ -511,6 +511,7 @@ Every mxcli project has a `.ai-context/skills/` directory (bundled by `mxcli ini
 
 | Task | Skill to load |
 |---|---|
+| Applying or proving a change request (CR row), a change whose class, size or status is unclear, or a "Change log:" gate line to explain: full class/size/ask tables, the wrong-vs-right example, apply and prove steps, the owners table and what the warn-only gate check counts | `skills/change-intake-detail.md` |
 | Deep, adaptive interview on one topic, on demand, when a checkpoint's 2+1 or a single question batch isn't enough | `skills/grill-mode.md` |
 | CAC-1, closing Stage 0 in EVERY entry mode — scope IN: full scope or a slice, and in what order. Opens with a brainstorm, not options | `skills/checkpoints/checkpoint-scope.md` |
 | CAC-1b, after Stage 1 — scope OUT: is what extraction produced what you meant. No gate stops you; run it late against the BRDs if it was skipped | `skills/checkpoints/checkpoint-extraction.md` |
@@ -525,7 +526,7 @@ Every mxcli project has a `.ai-context/skills/` directory (bundled by `mxcli ini
 | 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` |
+| Before citing ANY behavioural claim about the harness, the Mendix runtime or a test tool as evidence, or counting tokens from transcripts — a claim not in the register may not be cited | `skills/measured-claims.md` |
 | Any review pass that runs more than once — module-review, coherence, monkey, wiring-sweep: findings accumulate across runs, a per-run report cannot show a trend | `skills/improvement-register.md` |
 
 **Source — reading a legacy system (migration entry mode)**
@@ -580,14 +581,15 @@ Every mxcli project has a `.ai-context/skills/` directory (bundled by `mxcli ini
 | 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/assemble-prototype.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) | `project-bin/check-prototype-links.js` |
 | Designing the brand and ONE ANNOTATED WIREFRAME PER SCREEN before building pages — the design system alone is half the deliverable | `skills/design-artifacts.md` |
+| Stage 3, after the role model is CONFIRMED and BEFORE THE FIRST WIREFRAME — and any time a page shows ONE object, a menu item or home page is added, or a data source retrieves the current/first record: role homes, inboxes, and per page how it is reached and which object it takes as parameter | `skills/interaction-model.md` |
 | Before a wireframe or a design commits to a WIDGET, when a requirement shows a widget to one role and not another, and when a page script hits a parse error that looks like a syntax mistake: the short list of things MDL cannot write at all, and the four-minute probe that answers it at Stage 3 instead of at build time | `skills/learned-mdl-cannot-express.md` |
 
 **Build — the loop itself**
 
 | Task | Skill to load |
 |---|---|
 | Dispatching a build step to a helper — generate its one-file pack (the brief's Build steps row, mxcli brain brief, live DESCRIBEs, example, folder) and hand over the path instead of a reading list. Measured: 25-38% fewer tool calls and 30-41% less time, same quality; the token saving is not proven | `project-bin/context-pack.sh` |
-| Building a module with mxcli — verified, iterative, coverage-checklist gated | `skills/iterative-build-loop.md` |
+| An exec.sh guard refused a write (not a permission prompt), or building a module with mxcli — verified, iterative, coverage-checklist gated; on a refusal: commit, wait or stop, never FORCE_EXEC | `skills/iterative-build-loop.md` |
 | After marking a module done, or any time "how much is built vs proven" is asked — renders build-plan.html from done- prefixes and verify-module.sh/improvement-register.md, kept as two honestly separate views; --json writes architecture/build-plan.json parsed from build-plan.md's Phase headings (a plan with no Phase headings gets no file) | `project-bin/build-plan-status.sh` |
 | Turning a client-derived Mendix app into a clean, shareable demo with zero client fingerprint — branding, data, custom widgets | `skills/anonymize-client-app-for-demo.md` |
 | Handing a headless-built model to a person — opening it in Studio Pro, a free sandbox, or a colleague's machine: the model travels, the demo data and runtime config (keys, an agent's bound model) do not, and each needs its own re-establish step | `skills/handoff-to-studio-pro.md` |
@@ -610,7 +612,7 @@ Every mxcli project has a `.ai-context/skills/` directory (bundled by `mxcli ini
 
 | Task | Skill to load |
 |---|---|
-| Building and auditing Mendix pages — widget patterns, datasource shapes | `skills/learned-page-patterns.md` |
+| Building and auditing Mendix pages, or starting a UI fix round across many pages — widget patterns, datasource shapes; for a round: SCSS first, four regressions to check | `skills/learned-page-patterns.md` |
 | Generating a whole page tree in one script — the structure patterns that survive it | `skills/oneshot-page-structure-patterns.md` |
 | Building or auditing a collapsible sidebar nav — Atlas Core's collapsed state needs icons assigned per menu item or it silently clips label text | `skills/learned-sidebar-collapse-icons.md` |
 | Building or altering any data grid — native DATAGRID vs pluggable DG2 decision rule, the ALTER PAGE INSERT corruption, sort-by and filter-binding traps | `skills/learned-dg2-patterns.md` |
@@ -764,7 +766,8 @@ Then filter by Role(s). A helper dispatched with a role stub (ba, architect, mdl
 | Putting a question TO the user — any gate, any stage: ask in chat not in a file, two named options plus your recommendation, one batch per gate then end the turn | `skills/interview-protocol.md` | P,0,1,2,3,4,5,6,7 | lead, ba, architect |
 | The user gives feedback or asks for a change mid-project — "change X", "it also needs Y", a remark on a screenshot or the running app, a stakeholder's ask relayed in chat: log a CR row in PROJECT.md ## Change log BEFORE any edit, size it, then edit the highest artifact it alters (BRD, decision, architecture, wireframe), never the MDL first | `skills/change-intake.md` | 2,3,4,5,6,7 | lead, ba |
 | Any stage transition — the 2+1 format every CAC uses, and the one-register rule (answers land in PROJECT.md, never in a separate state file). The seven CACs themselves are routed per stage in the situational table | `skills/checkpoints/checkpoint-template.md` | 0,1,2,3,4,6,7 | lead, ba, architect |
-| Starting a subagent, sending it a fix round, or reading an agent-stop notice; or setting up the project's subagents — read its Dispatching section per dispatch, the rest once at setup | `skills/agent-roles.md` | P,1,2,3,4,5,6 | lead |
+| Setting up or completing a project's dev-process subagents — once, at project start, not "on demand" | `skills/agent-roles.md` | P,4,5 | lead |
+| Starting a subagent, sending it a fix round, or reading an agent-stop notice — name the model, fresh not fork, fresh fixer not resume, coalesce notices | `skills/dispatching.md` | P,1,2,3,4,5,6 | lead |
 | Deciding whether to extract at all, before any BRD gets generated | `skills/source-triage.md` | 0 | ba |
 | Taking in a new source — before generating anything from it. Grades what the source can support; nothing else in this toolkit reads a source | `bin/source-sufficiency.sh` | 0,1 | ba |
 | Closing Stage 1, or adding files to a source folder — every inventoried file must name the artifact that consumed it (text AND embedded diagrams), or carry a waiver; blocks Stages 1–2 until it does | `bin/source-ledger.sh` | 0,1,2 | ba |