What Studio needs
A by-BRD rollup in project-bin/build-plan-status.sh, so progress can be read per functional domain and not only per Mendix module.
Blast radius
Rating: needs care.
Additive as a new View C. Behaviour changing if it replaces View B, because that changes the meaning of "reviewed" for every existing project. Keep View B.
The failure mode to design against, stated plainly. A naive join attributes one module's summary.tsv result to every BRD that lists that module. One real project has eight domains inside a single Practice module. One journey run and one FAULT would render as eight domains each reporting a fault, and a human reading build-plan.html sees eight failures where there is one. Studio hit exactly this and fixed it (commit 0e9f11b, "give a shared module's test result to the module, not to every domain in it"). A toolkit view that joins naively would reintroduce it, and the two tools would then disagree on screen.
Suggested rule, which is the one Studio already uses:
- Join on requirement id first, using the
requirement field on docs/report.json rows.
- Fall back to module only when that module is claimed by exactly one BRD.
- Otherwise print "shared by N domains, not measured on its own" rather than a verdict.
- When
claims: blocks are absent, print "no claims, cannot roll up" rather than zeros. project-bin/coverage-preflight.sh already treats that as a lower level and its ledger derivation can be reused rather than writing a second parser.
Each row should say which join source produced it.
Decision needed
Which source is authoritative when they disagree: BRD modules[], the claims: blocks in build-plan.md, or requirement on report.json rows. All three exist and can contradict each other.
What Studio needs
A by-BRD rollup in
project-bin/build-plan-status.sh, so progress can be read per functional domain and not only per Mendix module.Blast radius
Rating: needs care.
Additive as a new View C. Behaviour changing if it replaces View B, because that changes the meaning of "reviewed" for every existing project. Keep View B.
The failure mode to design against, stated plainly. A naive join attributes one module's
summary.tsvresult to every BRD that lists that module. One real project has eight domains inside a singlePracticemodule. One journey run and one FAULT would render as eight domains each reporting a fault, and a human readingbuild-plan.htmlsees eight failures where there is one. Studio hit exactly this and fixed it (commit0e9f11b, "give a shared module's test result to the module, not to every domain in it"). A toolkit view that joins naively would reintroduce it, and the two tools would then disagree on screen.Suggested rule, which is the one Studio already uses:
requirementfield ondocs/report.jsonrows.claims:blocks are absent, print "no claims, cannot roll up" rather than zeros.project-bin/coverage-preflight.shalready treats that as a lower level and its ledger derivation can be reused rather than writing a second parser.Each row should say which join source produced it.
Decision needed
Which source is authoritative when they disagree: BRD
modules[], theclaims:blocks inbuild-plan.md, orrequirementonreport.jsonrows. All three exist and can contradict each other.