What Studio needs
A structured per domain test outcome, and a structured record that a person signed off, so the Build room can show "tested" and "checked by a person" as facts rather than blanks.
Today neither exists per domain. Studio's Build board renders those two columns with a "not recorded" glyph, deliberately distinct from "not yet", because a blank that reads as a pass is the failure this board exists to prevent.
Blast radius
Rating: needs care, and not ready for a PR. The carrier has not been chosen, and two of the candidates are gated.
Candidates and what each would disturb:
| carrier |
problem |
docs/report.json |
Required by gate-check.sh Stage 6. Additive optional fields on schema 1.x are the only safe option, and the requirement field already names BRD ids. A major bump to 2.0 makes Studio's reportParser.ts return null, so every domain silently loses its tested chip. |
architecture/build-plan.md State column |
Closed set today: built, partial, not built, blocked. |
docs/BUILD-LOG.md |
Parsed by status.sh, done-drift-check.sh and Studio's proof.ts. See ask 5. |
design/ui-reviews/ui-review-*.html |
The look obligation's artifact, with a mandatory denominator. Replacing the requirement flips that obligation to PENDING or FAULT on every project that has reviews in the old shape. |
.claude/loop/verify/<Module>/summary.tsv |
The journeys obligation's artifact. |
Second risk: attaching outcomes per domain when a BRD only carries modules[] recreates the shared module overclaim described in ask 3.
Decision needed
- What a domain is for this purpose: a BRD id, a requirement id, or a module.
- The carrier. Additive optional fields on
report.json 1.x rows, keyed by requirement, is the only candidate that changes no gate and keeps Studio's parser working.
- Whether human sign off lives in the toolkit at all. Studio already writes
.mxtk/proof.json and may write only inside .mxtk/. If sign off stays there, the toolkit side may need nothing beyond an agreed file name that the LOOK row in ask 4 can point at.
What Studio needs
A structured per domain test outcome, and a structured record that a person signed off, so the Build room can show "tested" and "checked by a person" as facts rather than blanks.
Today neither exists per domain. Studio's Build board renders those two columns with a "not recorded" glyph, deliberately distinct from "not yet", because a blank that reads as a pass is the failure this board exists to prevent.
Blast radius
Rating: needs care, and not ready for a PR. The carrier has not been chosen, and two of the candidates are gated.
Candidates and what each would disturb:
docs/report.jsongate-check.shStage 6. Additive optional fields on schema 1.x are the only safe option, and therequirementfield already names BRD ids. A major bump to 2.0 makes Studio'sreportParser.tsreturn null, so every domain silently loses its tested chip.architecture/build-plan.mdState columndocs/BUILD-LOG.mdstatus.sh,done-drift-check.shand Studio'sproof.ts. See ask 5.design/ui-reviews/ui-review-*.htmllookobligation's artifact, with a mandatory denominator. Replacing the requirement flips that obligation to PENDING or FAULT on every project that has reviews in the old shape..claude/loop/verify/<Module>/summary.tsvjourneysobligation's artifact.Second risk: attaching outcomes per domain when a BRD only carries
modules[]recreates the shared module overclaim described in ask 3.Decision needed
report.json1.x rows, keyed byrequirement, is the only candidate that changes no gate and keeps Studio's parser working..mxtk/proof.jsonand may write only inside.mxtk/. If sign off stays there, the toolkit side may need nothing beyond an agreed file name that the LOOK row in ask 4 can point at.