@kaavee315draftchecks…ci/openapi-completeness-check → master1 files · +230 −0updated 5d agoAdds a hermetic completeness guard for v3.1 OpenAPI registration at apps/apollo/src/pages/api/v3.1/openapi.completeness.test.ts.
A handler module under pages/api/v3.1/ that exports a routes array can silently be omitted from openapi.json.ts, causing SDK codegen to miss that endpoint with no CI signal. The new test prevents this by:
v3.1/ directory tree (fs.readdirSync) to find every .ts handler file (excluding test files and openapi.json.ts itself).export const routes = declaration in each file's source text (regex; no module import).openapi.json.ts, unless it appears in an explicit INTENTIONALLY_EXCLUDED set (currently the deprecated ./tools/get_scopes_required alias and the internal ./webhook_ingress/metronome/alerts billing webhook).A second test guards against stale INTENTIONALLY_EXCLUDED entries (file deleted/renamed, or no longer exports routes).
The check is purely static (fs + regex), so it runs without a database, performs no route-module imports, and is fully deterministic. Index handlers imported via either the explicit ./foo/index form or the bare ./foo directory form are both recognized (Node/TS resolution equivalence).
node_modules is not installed in the review worktree, so vitest could not be run locally.collectTsFiles + exportsRoutes + specifier comparison) with a standalone Node script against the live v3.1/ tree: confirmed the unregistered set is empty and the stale-exclusion set is empty, i.e. both tests pass at the current repo state.node:fs, node:path, and vitest (no route modules, no env.ts, no DB client), so it cannot trip the env/DB-validation failures that runtime route imports would.src/**/*.test.ts and runs under environment: 'node' (so __dirname resolves correctly).🤖 Generated with Claude Code