Golden captures for the seven asks, and three of them describe something that does not exist

[MendixMau]

Answers to the seven golden-capture requests, gathered from real projects on one machine and scrubbed of client, vendor and person names. Raised from the MXTK Studio side, where these files are consumed. Related to #74.

Read the three corrections first: three of the seven requests assume something that does not exist on disk.

Corrections

1. There is no 7-phase, 22-claim build plan

Every architecture/build-plan.md findable across a dozen real projects was counted. The distribution:

phases	claims
7	19
7	0 (x3)
8	17
3	23 (x2)
3	10
4	0
18	41

Nothing is 7/22. If #74 is reproducing against a specific plan, that plan is not in any project folder on this machine, and the nearest real fixture is the 8-phase / 17-claim one used as capture 1 below. Worth confirming which file #74 actually measured before a fix is written against a shape that does not occur.

2. BRD ids are not BRD-nn and modules are not M1..M8

Real BRD ids are F001, F002, and so on. Real modules are named (Identity, RoutingManagement, OperationManagement, QualityManagement), never numbered. No BRD-to-module TSV exists anywhere, and no BRD-related .tsv exists at all. Capture 4 below is therefore a reconstruction: real BRD-to-module facts, pulled from a real claims block, forced into the M1..M8 shape that was asked for. Only three modules exist in that project, so M4..M8 are empty rather than invented.

If anything downstream is being built against M1..M8, it is being built against a shape the toolkit does not produce.

3. There is exactly one studio_* tool, and no routing table for them

studio_ask is the only one, and it lives in the Studio daemon, not in this repo. Four others (studio_show, studio_checklist, studio_evidence, studio_decision) appear only in a brainstorm document and were never implemented. There is no tool-to-role or tool-to-tier routing table in this repo, in mxcli, or in Studio. ROUTING.md routes skills, not tools.

This is the substance of #72: the routing row being asked for would be the first one of its kind, not an addition to an existing set.

What is real and confirmed

• .claude/loop/summary.tsv exists in ten or more project folders.
• docs/report.json exists in twelve projects, and has top-level checks and coverage. Two of the twelve use a different schema with neither key, so jq '.checks, .coverage' returns null, null on those. Anything consuming this should handle both.
• mxcli lint --format json is genuinely supported, alongside sarif and the text default. Run against a real .mpr it exits 1 with valid JSON and 2,030 violations.
• DESCRIBE NAVIGATION is implemented in mxcli's own MDL engine, is read-only and needs no Studio Pro.

The captures

Every one states in its own header whether it is verbatim, partial or reconstructed, and cites its (scrubbed) source path. Nothing here is fabricated; omissions are marked as omissions.

2. .claude/loop/summary.tsv (verbatim, scrubbed)

# Source: <project-root>/learning-app/.claude/loop/review/Identity/summary.tsv
# Type: VERBATIM SCRUBBED CAPTURE (real file, no names to scrub — content is already generic
# instrument/verdict data; project name in the source path was "language-app" -> "learning-app").
#
# 15 summary.tsv files exist across several real Mendix project folders under
# <project-root>/Mendix/, all under a per-project ".claude/loop/{verify,review}/<Module>/"
# structure (e.g. approval-app-style migration-app, App-style App-main, learning-app-style
# language-app/language-app). None of them are secrets or contain real names; all rows use
# synthetic data (e.g. "@example.com" addresses, generic instrument names). This file is one
# representative example, chosen because it is short and complete.
#
# Columns: instrument | verdict | rc | elapsed | log
instrument	verdict	rc	elapsed	log
conformance (reused)	FAULT	2	-	(docs/conformance/report-2026-08-25.tsv missing)
graph sweep (orphans + wiring shape)	FAULT	2	0s	.claude/loop/review/Identity/graph.tsv
coverage (BRD leaves: UNCLAIMED/PHANTOM/DOUBLE)	FAULT	2	-	(the ledger names no reachable *.brd.json)
journeys	FAULT	2	-	(no journey run in this invocation)
look	FAULT	2	-	(no visual review in this invocation — module-review.md §4)

4. BRD id to module TSV (reconstruction, see correction 2)

# Source: <project-root>/learning-app/architecture/build-plan.md, "Step 5b — claims block"
# ("language-app" scrubbed to "learning-app"; also cross-checked against
# <project-root>/learning-app/architecture/modules/{Identity,Practice,Reporting}/ which confirms
# the same three module names).
#
# Type: VERBATIM DATA, RECONSTRUCTED TABLE SHAPE. The BRD-id -> module facts themselves are real,
# taken directly from the real project's own claims block (which maps each BRD's useCases/
# domainEntities/microflows/pages arrays to the .mdl script that builds them, and therefore to a
# module). This TSV distills that into a plain BRD -> module mapping and normalises the three real
# module names to M1..M8 as requested. Only 3 distinct modules exist in this project's real data
# (Identity, Practice, Reporting), so only M1-M3 are used; M4-M8 are not populated because no
# fourth+ module exists in the source material actually inspected.
#
# Other candidate projects checked for a richer multi-module BRD map:
#  - App (App-main): 10 modules across F001-F014 (RoutingManagement, OperationManagement,
#    DispatchListManagement, PrioritySequencing, ExecutionTransactionManagement,
#    QualityManagement x3 BRDs, ProcessVariant, ReworkDeviationRouting) — richer, but the BRD-id to
#    module link for F005/F006/F007 relies on each BRD's own internal `modules[0]` field
#    overriding a misleading filename, which needs each JSON opened individually; not reproduced
#    here to keep this a "real data, low-risk-of-error" sample. See item 1's header for that
#    project's module names if a fuller table is wanted later.
#  - change-governance-app (change-governance-app): single module only (all 10 BRDs -> module
#    "change-governance-app" i.e. change-governance-app itself) — not useful as a *mapping* example since it has
#    no fan-out.
#
# Columns: brd_id | module_name_real | module_normalized
brd_id	module_name_real	module_normalized
F001	Identity	M1
F002	Practice	M2
F003	Practice	M2
F004	Practice	M2
F005	Practice	M2
F006	Practice	M2
F007	Practice	M2
F008	Reporting	M3
F009	Practice	M2
F010	Reporting (deferred to phase 2, not built)	M3

5. mxcli lint --format json (real run, abridged)

// Source: real run of `mxcli lint --format json` against <project-root>/poc-app/PocApp.mpr
// ("poc-app-main"/"poc-app.mpr" scrubbed to "poc-app"/"PocApp.mpr").
//
// Implementation found at:
//   <project-root>/mxcli/cmd/mxcli/cmd_lint.go  (cobra command `lintCmd`, `Use: "lint"`, defined
//     from line 19; `Run:` func starts line 92)
//   <project-root>/mxcli/cmd/mxcli/main.go:359  — flag registration:
//     lintCmd.Flags().StringP("format", "f", "text", "Output format: text, json, sarif")
//   resolved via resolveFormat() at main.go:222-229. Usage example documented in the command's
//   own long description at cmd_lint.go:83-84: `mxcli lint -p app.mpr --format json`.
//
// --format json IS supported (also `text` and `sarif`). Confirmed by actually running:
//   mxcli lint -p "<project-root>/poc-app/PocApp.mpr" --format json
// Exit code: 1 (non-zero because violations were found; this is normal lint-tool convention, not
// a failure — catalog build, connect and formatting all succeeded per stderr progress log).
// Real stdout was valid JSON, 18,068 lines, shape {"violations": [...], "summary": {...}}.
// Progress/catalog-build noise (module/entity counts, "Connected to: ...") goes to stderr only,
// per the code comment at cmd_lint.go:106-109 ("with a machine-readable format, every progress
// line goes to stderr").
//
// Type: PARTIAL VERBATIM CAPTURE. The `summary` object below is reproduced in full and verbatim.
// The full `violations` array (2,030 entries) is NOT reproduced here — only 2 representative
// entries are kept, verbatim, as a shape sample. This is stated explicitly rather than inventing
// or padding out fake violation entries to look complete.

{
  "summary": {
    "total": 2030,
    "errors": 3,
    "warnings": 731,
    "infos": 1296,
    "hints": 0
  },
  "violations_sample_only_not_the_full_2030": [
    {
      "ruleId": "MPR001",
      "severity": "warning",
      "message": "Entity name 'InformationExtractor_EXAMPLE' should use PascalCase",
      "module": "AgentCommons",
      "document": "InformationExtractor_EXAMPLE",
      "documentType": "entity",
      "documentId": "262e6f3b-129e-4748-a5ec-a8fd6cb02f27",
      "suggestion": "InformationExtractorExample"
    },
    {
      "ruleId": "SEC007",
      "severity": "error",
      "message": "Entity 'Common.CachedEmployee' is readable by an anonymous user role",
      "module": "Common",
      "document": "CachedEmployee",
      "documentType": "entity"
    }
  ]
}

6. DESCRIBE NAVIGATION (real run, deeper nesting abridged)

Source: real run against <project-root>/poc-app/PocApp.mpr ("poc-app-main"/"poc-app.mpr" scrubbed
to "poc-app"/"PocApp.mpr"). Module and menu-label content below is real (a genuinely
Korean-language demo app); no client, company or person names appear in it.

Type: VERBATIM CAPTURE (real, actually executed, read-only command output).

Implementation found (mxcli, MDL query engine):
  grammar rule:   <project-root>/mxcli/mdl/grammar/domains/MDLCatalog.g4:179
                  DESCRIBE NAVIGATION (qualifiedName | IDENTIFIER)?
  AST node:       <project-root>/mxcli/mdl/ast/ast_query.go:337  (DescribeNavigation)
  parser wiring:  <project-root>/mxcli/mdl/visitor/visitor_query.go:1056
  executor:       <project-root>/mxcli/mdl/executor/cmd_navigation.go:282  (func describeNavigation)
  model reader:   <project-root>/mxcli/mdl/backend/modelsdk/navigation_read.go
  documented as a read-only "Show command" in:
    <project-root>/mxcli/cmd/mxcli/skills/manage-navigation/SKILL.md:46-59

This reads the .mpr directly via mxcli's own MDL engine (CONNECT LOCAL, BSON parsing). It does
NOT require Mendix Studio Pro or any other running infrastructure, and does not write anything.
Confirmed safe to run read-only, then actually run against a real .mpr:

  mxcli -p "PocApp.mpr" -c "SHOW NAVIGATION;"
  mxcli -p "PocApp.mpr" -c "DESCRIBE NAVIGATION;"

With no profile argument, DESCRIBE NAVIGATION iterates ALL navigation profiles in the project and
emits one "-- navigation PROFILE: <name>" / "create or replace navigation ...;" block per profile
(round-trippable back into CREATE OR REPLACE NAVIGATION). This project has exactly one profile
("Responsive"), so only one block appears below.

=== SHOW NAVIGATION; ===

| Profile    | Kind       | HomePage               | LoginPage        | MenuItems | RoleHomes |
|------------|------------|------------------------|------------------|-----------|-----------|
| Responsive | Responsive | MF:CommonData.Nav_Home | Common.LoginPage | 17        | 1         |

(1 navigation profiles)

=== DESCRIBE NAVIGATION; (all profiles) ===

-- navigation PROFILE: Responsive
--   Kind: Responsive
create or replace navigation Responsive
  home microflow CommonData.Nav_Home
  home page Common.LoginPage_Anonymous for Anonymous
  login page Common.LoginPage
  menu (
    menu item '대시보드' page Analytics.Dashboard_Home;
    menu '자산·바코드' (
      menu item '아이템 관리' page ItemManagement.Item_Overview;
      -- (additional items omitted from this sample capture)
    );
    menu 'AI' (
      -- (items omitted from this sample capture)
    );
    menu 'Configuration' (
      -- (items omitted from this sample capture)
    );
  )
;

7. The studio_* tools (see correction 3)

<!--
Source: grep across <project-root>/mxcli-project-toolkit, <project-root>/mxcli, and
<project-root>/mxtk-studio for "studio_".
Type: VERBATIM SCRUBBED CAPTURE of code and doc excerpts (no client/company/person names were
found in this material beyond the repo owner's own name, which is not a third party and was left
out of this table entirely).
-->

# studio_* tools

## Implemented (the only one that actually exists in code)

| Tool | Example trigger phrase (verbatim `description` field passed to the agent) | Roles that get it | Source |
|---|---|---|---|
| `studio_ask` | "Ask the practitioner one or more gate questions as a form with options and a recommendation. Blocks until answered. Use this for every gate question instead of asking in prose. A user-only question has no recommendation. When the result has outcome cancelled and a note, the practitioner wants to know more first: answer the note, then ask again." | none — no role/tier gating exists; it is the sole tool on the daemon's MCP server and is handed to whatever agent is running the session | `packages/daemon/src/agent/studioMcp.ts:12` (description constant), `:59` (`server.registerTool("studio_ask", ...)`) |

Confirmed explicitly in `docs/decisions-log.md:86`: "studio_ask is Studio's, not the toolkit's.
The string does not appear anywhere in the toolkit." Also documented in
`docs/adr/0009-forms-through-a-daemon-hosted-mcp-tool.md` (lines 14, 20, 23, 42, 49, 60) and
`docs/adr/0012-studio-never-parses-checkpoint-files.md:25,36`.

## Speculative / brainstormed only (never implemented — design doc, not code)

Source: `docs/brainstorm-2026-09-12-studio-ide.md:120-124`, a table under "Layer C: a Studio MCP
server handed to the agent". None of these four exist anywhere in code today.

| Tool | "What it does" (closest thing documented to a trigger phrase) |
|---|---|
| `studio_show(path, stage, title)` | "Pins an artifact in the canvas (a wireframe, the blueprint, a report)" |
| `studio_checklist(items)` | "Posts or updates the live stage checklist with status marks" |
| `studio_evidence(step, screenshot, db_delta, log_line)` | "Adds an evidence card to the proof view" |
| `studio_decision(stage, decision, status)` | "Records a decision row and refreshes the register panel" |

No role/tier mapping exists for any of these, implemented or speculative. The brainstorm doc
(line 126) proposes only a routing *preference*, not a role table: "one additive routing line,
'when a `studio_*` tool is available prefer it, otherwise fall back to the chat rendering'" — this
is the same "additive routing row for `studio_*` tools" the repo's own CLAUDE.md says is the only
toolkit change Studio may ever propose upstream, and per `docs/decisions-log.md` it has **not**
been made yet.

## Central routing table search result

No file maps ALL tools (studio_* or otherwise) to roles/tiers/permissions in any of the three
repos searched. The closest things found, none of which are actually a studio_*-to-role table:

- `<project-root>/mxcli-project-toolkit/bin/lib/skill-routing.tsv` — routes **skills**
  (toolkit checkpoints/protocols) to project stages, not tools to roles. Header comment: "the
  single source of truth for every routing surface", replacing six previously-duplicated tables.
  No `studio_` mentions in it.
- `docs/decisions-log.md:274` describes ACP's generic per-call permission options
  (`allow-once`, `allow-with-updates`, `reject`) — a tool-approval UI mechanism, not a role/tier
  routing table, and not specific to `studio_*`.
- `<project-root>/mxcli`'s `PED_MCP_CAPABILITIES.md` has a large tool | R/W-permission | notes
  matrix, but it is for an unrelated MCP surface (Mendix Studio Pro's own PED tools, e.g.
  `manage_navigation`, `get_studio_pro_logs`) — it only matched the "studio_" grep via the
  substring in `get_studio_pro_logs`, not a `studio_*`-prefixed tool family, and is unrelated to
  this Studio product.

Captures 1 (the build plan, 49 KB) and 3 (jq '.checks, .coverage', 16 KB) are too large to inline; say the word and they go in a follow-up comment.

No client, vendor or person names, paths, hosts or credentials appear above. The scrub was checked by a second pass, which caught names the first pass missed.