The published spec is linked from the site chrome, not only generated
Decided
/developers#spec is a named section carrying links to /openapi.json, the narrative reference on docs.novelsystems.ca, and the sandbox host, and { title: "OpenAPI Spec", href: "/developers#spec" } sits in the footer's Product column.
Affects: app/developers/page.tsx, config/site.ts
What went wrong. public/openapi.json has been generated from the Zod request validators and checked against the deployed API by check:api-reference since Task 4 shipped, and the GitBook space has been serving the reference since Task 68. Neither was linked from anywhere a developer looks. From the reader's chair a spec that nothing points at is indistinguishable from one that does not exist: the first question an integrator asks is "is there a spec", and the honest answer was yes while the discoverable answer was no.
Why the CI job is named in the copy. "Generated from the request validators" is a claim about our process that a reader cannot check. Naming the job that fails the build when the spec and the deployed API disagree is a claim they can go and look at. The former is marketing; the latter is evidence.
What would make this wrong: nothing about the decision — but the section's id is load-bearing. check:links resolves /developers#spec against the rendered ids, so renaming it fails the build rather than orphaning the footer entry a second time.