feat: record how Go is written across the organization

[retr0h]

The org-wide capability you asked for. Spec only — no implementation.

What the survey found

I compared what each repository states against what its code does, rather than comparing the five documents to each other. Nothing conflicts:

Rule	Stated in	Followed by
Multi-line signatures, gofumpt, early returns, import order	5 of 5	all
Table-driven testify suites	5 of 5	every test package — 70, 1, 1, 2, 72
types.go holds only types	2 of 5	all — 0 violations in 64 files
A file is named for what it holds	3 of 5	all — no helpers.go/utils.go anywhere
Generated mocks	2 of 5	the four repositories that mock anything
export_test.go exposes only setters	2 of 5	where the pattern is used

Two rules are universal in practice and written down in only two or three places. That gap is the reason for the capability — a convention followed everywhere and recorded twice survives on memory, and the next repository copies whichever file it started from.

Comparing the documents to each other would have missed this: the intersection of what all five state drops types.go and the file-naming rule, both of which all five obey.

Mocking is conditional, deliberately

osapi-orchestrator declares no mocking library and mocks nothing — it tests against httptest.Server. Written as "SHALL use gomock", the requirement would make a compliant repository non-compliant and the fix would be adding a dependency it does not need. So the requirement binds which mock, not whether to mock.

This is the second time that repository's approach has been read as an omission — correct-documentation-drift carried a task asking it to "state that it uses no mocking library", on the same mistaken premise.

export_test.go, org-wide per your call

Constrained by what such a file may expose rather than requiring one to exist, so the two repositories not using the pattern are unaffected. The reasoning generalizes past the collector-testing problem it came from: an alias makes an internal step directly callable, and a directly callable step attracts a test that duplicates coverage the caller's test already provides.

Note on my own numbers

An earlier count in this session said 77 of 109 gohai test files used testify — that was wrong three attempts running. Files that add methods to a suite declared in a sibling file do not import testify/suite themselves, so counting imports undercounts badly. Measured per package, it is 100% in all five.

Sections 2 and 3 stay open — they are the implementation, and the spec merges first.

🤖 Generated with Claude Code

[github-actions]

Thank you for contributing to this project! 😊🕹️