One struct in compilers/openapi accumulated every lowering concern, and no rule in force measured
the dimension it grew in. Function-size and complexity caps (#83) are worth having, but they were
already satisfied throughout: no function body in the package exceeds 50 lines against a 70-line cap.
The failure was type surface, and nothing measured type surface.
What to build
An AST rule in internal/archtest capping methods per type for packages under compilers/.
internal/archtest already carries the go/parser and go/token machinery, and already enforces
one AST rule of this kind — only compilers/compile may write an ir.TypeRegistry.
Acceptance
Re-adding methods to one type past the cap fails the build. Prove it by planting them, not by
reading the rule.
Sequenced after the restructuring rather than before it: the cap is calibrated against the finished
shape, and landing it first would only encode the current one.
One struct in
compilers/openapiaccumulated every lowering concern, and no rule in force measuredthe dimension it grew in. Function-size and complexity caps (#83) are worth having, but they were
already satisfied throughout: no function body in the package exceeds 50 lines against a 70-line cap.
The failure was type surface, and nothing measured type surface.
What to build
An AST rule in
internal/archtestcapping methods per type for packages undercompilers/.internal/archtestalready carries thego/parserandgo/tokenmachinery, and already enforcesone AST rule of this kind — only
compilers/compilemay write anir.TypeRegistry.Acceptance
Re-adding methods to one type past the cap fails the build. Prove it by planting them, not by
reading the rule.
Sequenced after the restructuring rather than before it: the cap is calibrated against the finished
shape, and landing it first would only encode the current one.