Filed out-of-scope from the published-skills factual sweep, flight ⑦ (skills/objectstack-api, card #13814, program #13658). Recording only — unassigned.
The measurement
handlerStatus (implemented / stub / planned) is an authorable key on RestApiEndpointSchema (packages/spec/src/api/plugin-rest-api.zod.ts). A repo-wide search for the identifier, excluding skills/** and test files, returns three hits and all three are in the declaring file itself:
plugin-rest-api.zod.ts:177 — the declaration on RestApiEndpointSchemaplugin-rest-api.zod.ts:1415 — the same enum re-declared on RouteCoverageEntrySchemaplugin-rest-api.zod.ts:1431 — a docblock saying adapters SHOULD warn when handlerStatus !== 'implemented'
Plus one CHANGELOG row. No consumer in packages/runtime, packages/rest, or anywhere else reads the key.
Why it is worth a card rather than a shrug
The key's documented effect is a specific runtime behaviour, and that behaviour has a different cause. DispatcherErrorCode.enum.NOT_IMPLEMENTED is emitted from exactly four sites — runtime/src/endpoint-executor.ts (three) and runtime/src/api-mapping.ts (one) — and every one of them is the declarative-endpoint executor refusing a target or a mapping it cannot serve. None consults handlerStatus. So an author who sets handlerStatus: 'stub' expecting the dispatcher to answer 501 gets an ordinary served route, and the declaration reports progress to nobody: RouteCoverageReportSchema is the only shape that would carry it outward and nothing constructs one.
This is the ADR-0049 enforce-or-remove class, and the same shape as #13613: a declared surface whose semantics no code implements. It is also a declared = enforced gap on the endpoint vocabulary — the same surface ApiEndpointSchema closed strictly in #5384 precisely so a typo could not parse green and configure nothing.
Two routes, for triage
- Remove. Retire the key from
RestApiEndpointSchema with a tombstone, and either retire RouteCoverageReportSchema alongside it or keep it as the report-only vocabulary it already is. Cheapest, and it matches the startup-scope posture for a key with no pull.
- Enforce. Have the route registrar consult
handlerStatus and mount a 501 stub for stub / planned. That is a real capability — a declared-but-unbuilt route answering an honest 501 instead of 404 — but it is new behaviour needing its own ruling, not a repair.
Recommendation: remove, unless someone can name a consumer that wants the coverage report. The evidence for "no pull" is that the key has shipped since the CHANGELOG row and nothing has grown to read it.
Provenance
Found while verifying the skill sentence "The dispatcher returns 501 NOT_IMPLEMENTED for stub and planned handlers", which flight ⑦ corrects in the skill text. Fixing the skill stops the false teaching; it does not close the declared-but-inert key, which is why this is a separate card.
Filed out-of-scope from the published-skills factual sweep, flight ⑦ (
skills/objectstack-api, card #13814, program #13658). Recording only — unassigned.The measurement
handlerStatus(implemented/stub/planned) is an authorable key onRestApiEndpointSchema(packages/spec/src/api/plugin-rest-api.zod.ts). A repo-wide search for the identifier, excludingskills/**and test files, returns three hits and all three are in the declaring file itself:plugin-rest-api.zod.ts:177— the declaration onRestApiEndpointSchemaplugin-rest-api.zod.ts:1415— the same enum re-declared onRouteCoverageEntrySchemaplugin-rest-api.zod.ts:1431— a docblock saying adapters SHOULD warn whenhandlerStatus !== 'implemented'Plus one CHANGELOG row. No consumer in
packages/runtime,packages/rest, or anywhere else reads the key.Why it is worth a card rather than a shrug
The key's documented effect is a specific runtime behaviour, and that behaviour has a different cause.
DispatcherErrorCode.enum.NOT_IMPLEMENTEDis emitted from exactly four sites —runtime/src/endpoint-executor.ts(three) andruntime/src/api-mapping.ts(one) — and every one of them is the declarative-endpoint executor refusing a target or a mapping it cannot serve. None consultshandlerStatus. So an author who setshandlerStatus: 'stub'expecting the dispatcher to answer 501 gets an ordinary served route, and the declaration reports progress to nobody:RouteCoverageReportSchemais the only shape that would carry it outward and nothing constructs one.This is the ADR-0049 enforce-or-remove class, and the same shape as #13613: a declared surface whose semantics no code implements. It is also a
declared = enforcedgap on the endpoint vocabulary — the same surfaceApiEndpointSchemaclosed strictly in #5384 precisely so a typo could not parse green and configure nothing.Two routes, for triage
RestApiEndpointSchemawith a tombstone, and either retireRouteCoverageReportSchemaalongside it or keep it as the report-only vocabulary it already is. Cheapest, and it matches the startup-scope posture for a key with no pull.handlerStatusand mount a 501 stub forstub/planned. That is a real capability — a declared-but-unbuilt route answering an honest 501 instead of 404 — but it is new behaviour needing its own ruling, not a repair.Recommendation: remove, unless someone can name a consumer that wants the coverage report. The evidence for "no pull" is that the key has shipped since the CHANGELOG row and nothing has grown to read it.
Provenance
Found while verifying the skill sentence "The dispatcher returns
501 NOT_IMPLEMENTEDforstubandplannedhandlers", which flight ⑦ corrects in the skill text. Fixing the skill stops the false teaching; it does not close the declared-but-inert key, which is why this is a separate card.