Studio renders a ✅ on a "Test Fixtures" row and blocks activation until it passes, which reads as the fixtures were run and the measure produced the expected outcomes.
validateTests (backend-ts/src/measure/measure-read-models.ts:175-184) checks four things:
- the fixture list is non-empty
- each entry has a
fixtureName
- each entry has an
employeeExternalId
- each
expectedOutcome is in an allowed set
It never executes the measure. A fixture asserting an impossible outcome passes the gate, and so does one whose expected outcome contradicts the CQL.
docs/ARCHITECTURE.md §5.2 item 4 described it the same way and has been corrected in #592 — but the review's assessment was explicit that the documentation fix is not the whole of it:
This is a product behaviour change with its own affected test, not prose hygiene.
So the label is still overstating.
Options, in increasing cost
- Relabel — "Fixtures present" / "Fixtures well-formed", and say on the row that they are not executed. Honest immediately, no behaviour change.
- Execute them. The engine is right there; a fixture is a subject and an expected outcome. This makes the tick mean what it appears to mean, and makes activation a real gate.
- Option 2 plus a visible result per fixture, so an author sees which one disagreed.
Recommend 1 now and 2 when Studio is next touched — an approval gate that cannot fail is the same defect class this repo keeps rediscovering (a control that reads as present and cannot fire).
Note the blast radius is bounded today: Studio authoring is hidden from the pilot's ROLE_CASE_MANAGER seats (frontend/lib/rbac.ts canAuthorMeasures), so the misleading tick is in front of engineering users only. That is why it is not urgent — not a reason it is fine.
Related: #592 (the documentation half), ADR-065.
Studio renders a ✅ on a "Test Fixtures" row and blocks activation until it passes, which reads as the fixtures were run and the measure produced the expected outcomes.
validateTests(backend-ts/src/measure/measure-read-models.ts:175-184) checks four things:fixtureNameemployeeExternalIdexpectedOutcomeis in an allowed setIt never executes the measure. A fixture asserting an impossible outcome passes the gate, and so does one whose expected outcome contradicts the CQL.
docs/ARCHITECTURE.md§5.2 item 4 described it the same way and has been corrected in #592 — but the review's assessment was explicit that the documentation fix is not the whole of it:So the label is still overstating.
Options, in increasing cost
Recommend 1 now and 2 when Studio is next touched — an approval gate that cannot fail is the same defect class this repo keeps rediscovering (a control that reads as present and cannot fire).
Note the blast radius is bounded today: Studio authoring is hidden from the pilot's
ROLE_CASE_MANAGERseats (frontend/lib/rbac.tscanAuthorMeasures), so the misleading tick is in front of engineering users only. That is why it is not urgent — not a reason it is fine.Related: #592 (the documentation half), ADR-065.