Fix #271: surface checks API in docs #293

Merged
crueber merged 1 commit from fix/issue-271 into main 2026-09-10 16:06:21 +00:00
Owner

Checks were dynamically reportable (POST …/api/checks/statuses/{sha} + wct_ CI tokens) but invisible in discovery and the /api docs page. This change surfaces them — docs + discovery wiring only, no wire/behavior change (full audit of the 7-route checks surface against internal/checks/http.go; nothing missing, nothing phantom).\n\n- Discovery: GET /api/v1 lists the 5 checks templates via checks.ExposedTemplates + api.RegisterExposed from newChecksService (Feature 10 precedent, law 12). Live-verified on a zero-config boot: 28 endpoints incl. all 5 checks shapes.\n- /api page: checks rows in the route table + a Checks-CI section (auth incl. wct_ usage, request/response shapes, worked example: mint token → POST status → GET combined, SDK pointers).\n- /checks page links to /api#checks-ci.\n- Contract tests: TestExposedTemplatesExact + TestExposedCoversRoutes (internal/checks, both lanes, 405s recognized, both directions) and TestNewChecksServiceRegistersDiscovery (cmd/walhub, through the exported api.Mount document).\n- Docs (law 12): 05_checks_statuses.md §4 + implementation notes + Decisions; 14_extensibility.md Wave 05 amendment (#271 supersedes no-discovery-entries for checks only); 07_api.md §8 + Decisions.\n\nTests: go vet clean; internal/checks -race green (cover 96.4%); internal/api -race green (cover 95.2%); cmd/walhub -race green; node --test 554 pass (smoke.test.js excluded — needs a live server; it also misbehaves on main under Node 26, pre-existing). JSX parse-checked with the repo esbuild. No new deps. No browser run (reasoning + tests, per task).

Checks were dynamically reportable (POST …/api/checks/statuses/{sha} + wct_ CI tokens) but invisible in discovery and the /api docs page. This change surfaces them — docs + discovery wiring only, no wire/behavior change (full audit of the 7-route checks surface against internal/checks/http.go; nothing missing, nothing phantom).\n\n- Discovery: GET /api/v1 lists the 5 checks templates via checks.ExposedTemplates + api.RegisterExposed from newChecksService (Feature 10 precedent, law 12). Live-verified on a zero-config boot: 28 endpoints incl. all 5 checks shapes.\n- /api page: checks rows in the route table + a Checks-CI section (auth incl. wct_ usage, request/response shapes, worked example: mint token → POST status → GET combined, SDK pointers).\n- /checks page links to /api#checks-ci.\n- Contract tests: TestExposedTemplatesExact + TestExposedCoversRoutes (internal/checks, both lanes, 405s recognized, both directions) and TestNewChecksServiceRegistersDiscovery (cmd/walhub, through the exported api.Mount document).\n- Docs (law 12): 05_checks_statuses.md §4 + implementation notes + Decisions; 14_extensibility.md Wave 05 amendment (#271 supersedes no-discovery-entries for checks only); 07_api.md §8 + Decisions.\n\nTests: go vet clean; internal/checks -race green (cover 96.4%); internal/api -race green (cover 95.2%); cmd/walhub -race green; node --test 554 pass (smoke.test.js excluded — needs a live server; it also misbehaves on main under Node 26, pre-existing). JSX parse-checked with the repo esbuild. No new deps. No browser run (reasoning + tests, per task).
Discovery (GET /api/v1) lists the five checks templates via
checks.ExposedTemplates + api.RegisterExposed from newChecksService
(Feature 10 precedent, law 12: template + handler, same change). The /api
page documents the routes, auth, request/response shapes, and a worked CI
example (#checks-ci, linked from the /checks page). TestExposedCoversRoutes
pins the template-route correspondence both ways (no phantoms, nothing
missing); cmd/walhub pins the composition registration. No wire or behavior
change.

Docs: 05_checks_statuses.md section 4 + implementation notes + Decisions;
14_extensibility.md Wave 05 amendment (#271 supersedes no-discovery-entries
for checks only); 07_api.md section 8 + Decisions.
Sign in to join this conversation.
No description provided.