feat: put go-code-standards in the corpus - #88
Merged
Conversation
Five repositories name go-code-standards as the source for their Go conventions. It was not in openspec/specs/ -- it existed only inside the unarchived change, so a reader following the pointer to where the corpus lives found nothing. That was survivable while each repository also kept a local copy. It stopped being survivable when gohai dropped its copy: the rules are now stated in one place, and until this sync that place was not reachable. Synced rather than archived because the change is not finished -- the hand-written mocks and the export_test.go audit are still open. Also corrects the record on section 2. All four Go libraries restated the capability, not two; nats-client and nats-server still do, under Code style rather than Code standards, which an earlier check scoped to the wrong heading and missed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Thank you for contributing to this project! 😊🕹️ |
This was referenced Aug 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Five repositories name
go-code-standardsas the source for their Go conventions. It was not inopenspec/specs/. It existed only inside the unarchived change, atopenspec/changes/specify-go-code-standards/specs/go-code-standards/spec.md, so a reader following the pointer to where the corpus lives found nothing.Why this is now urgent
That gap was survivable while every repository also kept a local copy of the rules. It stopped being survivable when osapi-io/gohai#163 merged:
gohaidropped its copy, so the conventions are now stated in exactly one place — and until this PR, that place was not reachable from the corpus.osapiis in the same position after osapi-io/osapi#450, and osapi-io/osapi-orchestrator#76 would put a third repository there. That PR should not merge before this one.Synced, not archived
The change is not finished — 3.4 (hand-written mocks) and 3.5 (the
export_test.goaudit) are open.CONTRIBUTING.mdsanctions exactly this:Merged as a new main spec: 7 requirements, 13 scenarios, delta operation headers resolved into a single
## Requirementssection per the main-spec format.Also corrects the record
Section 2 claimed
nats-clientandnats-serverpointed at the capability without restating it. They don't — they restate under## Code stylewith lowercase headings (### Function signatures,### Go patterns), which an earlier check missed by scoping to## Code standards. So all four Go libraries restated, not two, and tasks 2.2/2.3 are reopened to reflect that.A new task 2.0 records the ordering this PR establishes: the capability must be in the corpus before a repository can rely on the pointer alone.
Verification
openspec validate --specs— 7 passed, 0 failedjust test— 11 passed, 0 failed🤖 Generated with Claude Code