The defect
A components/responses entry referenced from both a success and an error status interns its content schema once, at the component pointer — and the naming hint it gets depends on which mount lowered first.
responses:
"200": { $ref: '#/components/responses/Shared' }
"404": { $ref: '#/components/responses/Shared' }cmd/morphic-harness reddens on this:
order-dependent type registry ... Hint: "response" vs "error"
Not a regression
Confirmed present on main as well as on the feat/spaceapi-ir-consumer-gaps branch, so nothing recent caused it. It is reported here because the branch's work on ErrorCase (#422) is the natural place it would close and it was left standing.
Why it matters more than a cosmetic hint
The order-invariance oracle exists precisely because two pointer-collision bugs (#108, #112) were order-dependent, and internal/harness' orderInvariant check was built to catch exactly this class. A hint that depends on lowering order means the same document can produce two different IR documents, which is the property that check is there to deny.
Where it comes from
#422 made the success and error paths identical in every other respect — ErrorCase now lowers through the same responseName, lowerHeaders and lowerPayload helpers as ir.Response. The remaining asymmetry is the hint string passed at the two call sites ("response" versus "error"), which is what the shared component's single interned node ends up carrying.
Suggested
Either derive the hint from the component's own coordinate rather than from the mount that reached it first — which is what InternProvisional/NameFromDeclaration already do for the analogous "named from whichever reference arrived first" problem (#372) — or make the two hints agree for a shared component.
Found by an adversarial review of feat/spaceapi-ir-consumer-gaps, 2026-09-08. CLAUDE.md: "a defect is a property of its mechanism ... sweep every site."
The defect
A
components/responsesentry referenced from both a success and an error status interns its content schema once, at the component pointer — and the naming hint it gets depends on which mount lowered first.cmd/morphic-harnessreddens on this:Not a regression
Confirmed present on
mainas well as on thefeat/spaceapi-ir-consumer-gapsbranch, so nothing recent caused it. It is reported here because the branch's work onErrorCase(#422) is the natural place it would close and it was left standing.Why it matters more than a cosmetic hint
The order-invariance oracle exists precisely because two pointer-collision bugs (#108, #112) were order-dependent, and
internal/harness'orderInvariantcheck was built to catch exactly this class. A hint that depends on lowering order means the same document can produce two different IR documents, which is the property that check is there to deny.Where it comes from
#422 made the success and error paths identical in every other respect —
ErrorCasenow lowers through the sameresponseName,lowerHeadersandlowerPayloadhelpers asir.Response. The remaining asymmetry is the hint string passed at the two call sites ("response"versus"error"), which is what the shared component's single interned node ends up carrying.Suggested
Either derive the hint from the component's own coordinate rather than from the mount that reached it first — which is what
InternProvisional/NameFromDeclarationalready do for the analogous "named from whichever reference arrived first" problem (#372) — or make the two hints agree for a shared component.Found by an adversarial review of
feat/spaceapi-ir-consumer-gaps, 2026-09-08. CLAUDE.md: "a defect is a property of its mechanism ... sweep every site."