feat: record the SDK's contract with its consumers - #75
Merged
Conversation
osapi publishes a Go SDK that osapi-orchestrator is built on, and the rules governing it live in two documents addressed to people working inside osapi. The consumer cannot see the contract it depends on. Each rule was checked against the code before being written, so the capability records what is true rather than what was intended. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Thank you for contributing to this project! 😊🕹️ |
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
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.
First of the capabilities coming out of
specify-documentation-homessection 3. Spec only — no implementation, per the workflow.Why this one first
It is the only one of the five that already binds a second repository.
osapi-orchestratoris built entirely onpkg/sdk/clientand pins it by version, so the contract has a real consumer and real evidence for what the rules must be.Today those rules live in two documents inside
osapi—CLAUDE.md(method naming) anddocs/docs/sidebar/sdk/guidelines.md(type exposure, JSON tags, error handling). Both are addressed to people working insideosapi. The repository that depends on them cannot see them, and nothing detects a change to the contract until the consumer breaks.Recorded, not corrected
I checked every rule against the code before writing it down:
gentypegenThat is what makes this a recording. A requirement written from documentation alone records what someone intended; one checked against the code records what is true.
My first check for the
genrule was wrong — it grepped method bodies and reported five violations. Constructing a generated request inside a method is exactly what the SDK is supposed to do; the rule is about signatures. Re-checked by parsing parameters and return types only.One rule turned out to be load-bearing
"JSON tags required" reads like style until you find what depends on it: results are converted to generic maps by round-tripping through JSON. An untagged field arrives as
Hostnamerather thanhostname, so the lookup misses and the value is silently absent. The requirement states that reason, because a rule whose justification is invisible is one someone will later relax.The same applies to
omitempty— the requirement draws the line at whether absence carries meaning.Changedomitted when false makes "nothing changed" indistinguishable from "this SDK version does not report changes".Scope
Stops at the SDK boundary. How the API it calls is designed, how a provider behaves, and how Go is written across the organization are separate capabilities with separate readers — recorded in design.md as a rejected alternative.
Sections 2 and 3 stay open: they are the implementation, and per CONTRIBUTING the spec merges first.
🤖 Generated with Claude Code