Outcome
Expand a documented release-baseline coverage boundary with a deterministic consumer regression.
Evidence
PR #88 review on e90a2c3: #88.
A field or method newly added to an embedded type can make an existing promoted selector ambiguous while all baseline declaration lines remain unchanged. Existing field-addition guards inspect the changed struct itself; they do not analyze its effects on other exported structs that embed it. Candidate method additions also need that analysis.
Acceptance
- Baseline: Options embeds A and B, only B has Run, and Options{}.Run() compiles. Candidate adds A.Run; external consumer fails and the gate must reject or explicitly request compatibility review.
- Define conservative handling versus method-set analysis, including pointer/value receivers and nested embedding. Retain a positive control for safe additions to unembedded receiver types. Clearly describe conservative false positives and the explicit review path.
- Compare independently generated inventories from an immutable baseline and candidate; candidate fixture or inventory refresh must not suppress the failure.
- Add focused positive/negative controls, current and minimum Go checks, and documentation of the precise supported boundary.
Scope relationship
This is additional Go type-system coverage beyond #58's explicit declaration/consumer fixture set. Track outside v1.1.0 rather than silently broadening its checker. The current gate must document this limitation; changes relying on this uncovered case need explicit compatibility review and consumer evidence before release.
Named field addition on an embedded type
Review evidence: #88 (comment) at head3927cbffd13a644711e9302fd28332b8ded5443c.
Use exported plain A, B with Run(), and Outer embedding A and B. The baseline consumer Outer{}.Run() compiles. Adding a named Run int field to A can make that existing selector ambiguous while the field-addition exception accepts A and the Outer/B declarations remain unchanged.
- Cover both named field and method additions to an embedded type; do not limit checks to additions inside the outer struct itself.
- Decide conservative rejection versus typed selector analysis across exported embedding relationships, with nested/pointer embeddings, aliases and generic boundaries explicitly scoped.
- Keep a positive control for a compatible field addition to an unembedded defined struct. A changed candidate inventory cannot waive an externally visible selector break.
- Record the original field-addition caveats separately from this cross-type selector coverage. Until implemented, these changes require explicit compatibility review and consumer compilation evidence.
Reproduced field-addition evidence
At immutable PR88 head3927cbf, an isolated baseline consumer QAOuter{}.Run() compiled. The candidate changed only embedded QAA to struct{Run int}; the same consumer failed with ambiguous selector api.QAOuter{}.Run. The compiled releasebaseline CLI still returned exit0/status=compatible. Temporary fixtures were cleaned up. This confirms the field-addition variant of this existing cross-type selector coverage gap.
Outcome
Expand a documented release-baseline coverage boundary with a deterministic consumer regression.
Evidence
PR #88 review on e90a2c3: #88.
A field or method newly added to an embedded type can make an existing promoted selector ambiguous while all baseline declaration lines remain unchanged. Existing field-addition guards inspect the changed struct itself; they do not analyze its effects on other exported structs that embed it. Candidate method additions also need that analysis.
Acceptance
Scope relationship
This is additional Go type-system coverage beyond #58's explicit declaration/consumer fixture set. Track outside v1.1.0 rather than silently broadening its checker. The current gate must document this limitation; changes relying on this uncovered case need explicit compatibility review and consumer evidence before release.
Named field addition on an embedded type
Review evidence: #88 (comment) at head3927cbffd13a644711e9302fd28332b8ded5443c.
Use exported plain A, B with Run(), and Outer embedding A and B. The baseline consumer Outer{}.Run() compiles. Adding a named Run int field to A can make that existing selector ambiguous while the field-addition exception accepts A and the Outer/B declarations remain unchanged.
Reproduced field-addition evidence
At immutable PR88 head3927cbf, an isolated baseline consumer QAOuter{}.Run() compiled. The candidate changed only embedded QAA to struct{Run int}; the same consumer failed with ambiguous selector api.QAOuter{}.Run. The compiled releasebaseline CLI still returned exit0/status=compatible. Temporary fixtures were cleaned up. This confirms the field-addition variant of this existing cross-type selector coverage gap.