finding: the checklist's area-scoped `fixtures` recipe convention has hit its stated revisit trigger — 3 areas, and a consumer that cannot reference the recipe it needs

[os-elon]

Observation from #10236 (17.1.0 QA sweep checklist pass). Filed unassigned; recording the trigger, not claiming the work.

The deferred decision, and the condition it was deferred on

docs/qa/platform-checklist/README.md records option C from #7716's open question as deliberately deferred:

The validator does not yet resolve provisioning.use against the area's fixtures keys — that was deliberately deferred (option C on #7716's open question, tracked at #7720), to be revisited if the recipe shape spreads to more areas. Until then a typo'd use is caught by review, not by check:platform-checklist.

#7720 is closed (it landed the README documentation half). Nothing tracks option C itself, and its stated revisit condition has now been met.

What changed

Recipes now live in three area files, not one:

area file	recipes
areas/attachments-storage.json	qa-scratch-authz (#7670), qa-media-constraints
areas/automation.json	qa-flow-status-doors (new, #10236)
areas/search.json	qa-contributor-bound-member (new, #10236)

Six items now carry a provisioning.use. All six currently resolve — verified by hand, because nothing verifies it mechanically.

The sharper half: the first consumer that cannot opt in

records-forms.crud-roundtrip clause 7 (clone is RLS-gated ⇒ 404 RECORD_NOT_FOUND for a caller who cannot see the source) needs exactly the persona qa-contributor-bound-member provisions. That recipe lives in areas/search.json, and provisioning.use must name a key in the item's own area block — so the item cannot reference it.

#10236 handled this by cross-referencing the recipe by name in knownGaps and explicitly telling the runner not to fork a second copy. That works, but it is a pointer the tooling cannot see, in the one direction where drift is most expensive: if qa-contributor-bound-member is ever renamed or revised, the search.json reference moves and the records-forms.json prose does not.

So there are now two distinct gaps, and they want different answers:

1. Dangling use within an area — the original option C. A ~10-line resolve check in check-platform-checklist.mjs, symmetrical with the supersededBy check that already exists there.
2. Cross-area reuse has no spelling at all — a recipe needed by two areas can only be duplicated (drifts) or referenced in prose (invisible to tooling). Options worth weighing: a qualified use (search:qa-contributor-bound-member); a shared areas/_fixtures.json; or ruling that recipes stay area-local and cross-area consumers must duplicate with a pinned back-reference.

(2) is a convention decision, not a mechanical one, and is the reason this is filed as an observation for triage rather than as a ready task.

Not urgent

Nothing is broken today: all six references resolve and the two cross-area pointers are prose that a human reading the item will follow. The cost is that the guarantee is "caught by review", and the review surface just tripled.

[os-zhuang]

Triage (first-touch): promoted → pm:queue, domain:devx, Task. Scope for dispatch: gap 1 only — the ~10-line provisioning.use resolve check in check-platform-checklist.mjs, symmetrical with the existing supersededBy check, validating same-area references (all six current references resolve, so it lands green). Gap 2 (cross-area recipe spelling) is a convention choice the mechanical check does not depend on — the executing dev should propose a shape in the PR body as an open question rather than implement one; today's two cross-area pointers live in knownGaps prose and must not fail the new check.

---

Generated by Claude Code