Problem
Three doc comments name ir-design §10 as the authority for openapi.Options' shape:
compilers/openapi/options.go — "Its shape is a published contract (ir-design §10)"compilers/openapi/openapi.go (loadOptions) — "whose shape ir-design §10 fixes"compilers/openapi/internal/load/load.go (load.Options) — "because openapi.Options is public API whose shape is fixed by ir-design §10"
docs/ir-design.md §10 is Servers:
$ grep -n '^## ' docs/ir-design.md | sed -n '10p'
1442:## 10. Servers
and the document does not describe compiler options in any section — grep -n 'openapi.Options\|compiler options' docs/ir-design.md is empty.
Why it matters
All three comments use the citation to justify a real design decision — that openapi.Options stays whole and each phase takes its own projected input rather than the public type. The decision looks right; the reason given for it points at nothing. A reader who follows the citation to check the constraint finds a struct about server URLs, and cannot tell whether the constraint exists elsewhere or does not exist at all.
The three restate one claim, which is why one wrong section number is wrong in three places.
Fix
Either point at whatever does fix the shape, or drop the citation and state the reason on its own terms in one place with the other two referring to it. Worth deciding which, since "the public options type is a published contract" is a real constraint if it holds.
Problem
Three doc comments name
ir-design §10as the authority foropenapi.Options' shape:compilers/openapi/options.go— "Its shape is a published contract (ir-design §10)"compilers/openapi/openapi.go(loadOptions) — "whose shape ir-design §10 fixes"compilers/openapi/internal/load/load.go(load.Options) — "because openapi.Options is public API whose shape is fixed by ir-design §10"docs/ir-design.md§10 is Servers:and the document does not describe compiler options in any section —
grep -n 'openapi.Options\|compiler options' docs/ir-design.mdis empty.Why it matters
All three comments use the citation to justify a real design decision — that
openapi.Optionsstays whole and each phase takes its own projected input rather than the public type. The decision looks right; the reason given for it points at nothing. A reader who follows the citation to check the constraint finds a struct about server URLs, and cannot tell whether the constraint exists elsewhere or does not exist at all.The three restate one claim, which is why one wrong section number is wrong in three places.
Fix
Either point at whatever does fix the shape, or drop the citation and state the reason on its own terms in one place with the other two referring to it. Worth deciding which, since "the public options type is a published contract" is a real constraint if it holds.