The bases, starters and rulesets are verified by hand today. Every one of them lints clean at the moment it ships, and nothing keeps it that way.
That is the gap that matters most, because these artifacts are what other people copy.
What should run in CI
Rulesets — OWASP, API Authorization, Problem Details, FHIR each already have npm test, and the harness is strong: it asserts every declared rule fires on the noncompliant fixture, that the clean fixture is silent, and that no rule throws. It just is not wired to a workflow. Add one, and adding a rule without a fixture case fails the build.
Bases — accounts, images, videos, problem-details-for-http-apis: lint each openapi.yml against the Problem Details ruleset and spectral:oas, allowing only oas3-api-servers.
Starters — run validate.py, plus Spectral on starter-openapi.yml asserting zero findings. That claim is in the README; CI should hold it true.
Schema repos — rate-limits, versioning, features, benefits, integrations each have validate.py covering their examples.
Why now
The APIs.json starter validates against a schema fetched live from apis-json/api-json. That is deliberate — a vendored copy would drift — but it means an upstream change can silently invalidate the starter with nobody noticing. CI is what turns that into a red build instead of a wrong artifact people copy.
governance-pipeline is the org's own forkable reference pipeline. Using it here would be the obvious dogfood.
The bases, starters and rulesets are verified by hand today. Every one of them lints clean at the moment it ships, and nothing keeps it that way.
That is the gap that matters most, because these artifacts are what other people copy.
What should run in CI
Rulesets — OWASP, API Authorization, Problem Details, FHIR each already have
npm test, and the harness is strong: it asserts every declared rule fires on the noncompliant fixture, that the clean fixture is silent, and that no rule throws. It just is not wired to a workflow. Add one, and adding a rule without a fixture case fails the build.Bases —
accounts,images,videos,problem-details-for-http-apis: lint eachopenapi.ymlagainst the Problem Details ruleset andspectral:oas, allowing onlyoas3-api-servers.Starters — run
validate.py, plus Spectral onstarter-openapi.ymlasserting zero findings. That claim is in the README; CI should hold it true.Schema repos —
rate-limits,versioning,features,benefits,integrationseach havevalidate.pycovering their examples.Why now
The APIs.json starter validates against a schema fetched live from
apis-json/api-json. That is deliberate — a vendored copy would drift — but it means an upstream change can silently invalidate the starter with nobody noticing. CI is what turns that into a red build instead of a wrong artifact people copy.governance-pipeline is the org's own forkable reference pipeline. Using it here would be the obvious dogfood.