Public: anyone can read this; the crew can change it.
The OpenAPI document describes GET /api/v1/passport/health #5330
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/passport/health` now has a row in `ROUTES` (`src/contract/openapi.ts`), beside `/api/v1/health`. The OpenAPI tests pass (32 tests in `test/openapi*`). I did not run the full `bun test`. `tsc` could not run here because the `bun` type definitions are missing in this sandbox.
shipped production is serving it deploy 2fa0c24
GET /api/v1/passport/health now has a row in ROUTES (src/contract/openapi.ts), beside /api/v1/health. The OpenAPI tests pass (32 tests in test/openapi*). I did not run the full bun test. tsc could not run here because the bun type definitions are missing in this sandbox.
- The row: the summary says the caller holds a passport, sent as
Authorization: Passport <token>, for audienceforgeand scopehealth:read, not a token. It also says the answer is the same body as the anonymous health, uncached. The one refusal isunauthorized, which the handler always returns as a 401. auth: false: that flag only produces the bearer-token security entry, which this route doesn't use. So the passport requirement is in the summary text, not in the document's security scheme.- Coverage list: the route's line is gone from
NOT_YET_DESCRIBEDintest/openapi-coverage.test.ts. - New test:
test/openapi-oa-passport.test.tschecks the row exists, names the passport and thehealth:readscope, and listsunauthorized. It fails without the row. - Router check:
test/openapi.test.ts("every described route is registered in the router") only scannedserver.ts,api.tsandmcp.ts. It failed once the row existed, because the route is registered inpassport_edge.ts. I added that file to its list.
I did not add a separate security scheme for passports.
The row matches the handler in src/http/passport_edge.ts: GET, audience forge, scope health:read, always 401 unauthorized. The preview answers 401 without a passport. The new test fails without the row, the coverage entry is removed, and the router check now scans passport_edge.ts. Two things to do next: (1) add a real passport security scheme to the document so clients can see the requirement in the security block and not only in the summary text; (2) have the new test also assert the 401 response is described, not just the word unauthorized somewhere in the JSON.
GET /api/v1/passport/healthnow has a row inROUTES(src/contract/openapi.ts), beside/api/v1/health. The OpenAPI tests pass (32 tests intest/openapi*). I did not run the fullbun test.tsccould not run here because thebuntype definitions are missing in this sandbox.Authorization: Passport <token>, for audienceforgeand scopehealth:read, not a token. It also says the answer is the same body as the anonymous health, uncached. The one refusal isunauthorized, which the handler always returns as a 401.auth: false: that flag only produces the bearer-token security entry, which this route doesn't use. So the passport requirement is in the summary text, not in the document's security scheme.NOT_YET_DESCRIBEDintest/openapi-coverage.test.ts.test/openapi-oa-passport.test.tschecks the row exists, names the passport and thehealth:readscope, and listsunauthorized. It fails without the row.test/openapi.test.ts("every described route is registered in the router") only scannedserver.ts,api.tsandmcp.ts. It failed once the row existed, because the route is registered inpassport_edge.ts. I added that file to its list.I did not add a separate security scheme for passports.
Closes #5311