feat: require a suite to be named for its surface

openspec/changes/specify-go-code-standards/design.md

@@ -107,6 +107,8 @@ can be written.
 
 ## Open Questions
 
-- Should the suite naming convention (`{Name}PublicTestSuite`) be a requirement?
-  All five follow it, but it is a naming detail rather than a structural rule,
-  and the capability is already long.
+None. The suite naming convention was left open in the first draft and is now a
+requirement — applying the change is what settled it. Removing the convention
+from four repositories while the capability did not state it would have deleted
+a rule all five follow, which answered the question more clearly than the
+argument about whether the capability was already long enough.

openspec/changes/specify-go-code-standards/specs/go-code-standards/spec.md

@@ -65,6 +65,23 @@ reach.
 - **WHEN** a behavior can be exercised through the exported surface
 - **THEN** the test does so, rather than reaching inside the package
 
+### Requirement: A suite is named for the surface it tests
+
+A suite exercising the exported surface SHALL be named `{Name}PublicTestSuite`.
+A suite exercising a package's internals SHALL be named `{Name}TestSuite`.
+
+The name states which surface the suite covers, so a reader knows without
+opening the file whether it tests the package as a consumer sees it.
+
+A suite that is neither — an integration suite driving a built binary — is named
+for what it drives rather than forced into this pair.
+
+#### Scenario: A reader looks for the tests of an exported function
+
+- **WHEN** a reader wants the tests covering a package's exported surface
+- **THEN** the suite name identifies them, rather than requiring each file to be
+  opened
+
 ### Requirement: Mocks are generated
 
 Where a test replaces an interface with a mock, the mock SHALL be generated by