Found while implementing #11145 (the publishMetaItem consumer cleanup) — the retired docblock there named this door as its twin, and the twin is still in the state publishMetaItem just left. Filed rather than touched: the fix is a packages/spec contract decision, and packages/spec is off limits from the engine lane.
Measured on origin/main @ c251ef4213
auditMetaItem appears zero times in packages/spec/src/api/protocol.zod.ts:
$ grep -c "auditMetaItem" packages/spec/src/api/protocol.zod.ts
0
Positive control that the matcher works: the same grep against publishMetaItem in that file returns 4 hits, and MetadataProtocol gained its publishMetaItem member at line 2535 via #11426.
Both REST sites still reach the method through a cast — packages/rest/src/rest-server.ts:
5787: if (typeof (p as any).auditMetaItem !== 'function') — the feature-detection guard5873: const result = await (p as any).auditMetaItem({ … }) — the call
The request literal at 5873 threads four members (type, name, organizationId, conditionally limit). No declared type sees any of them, so an undeclared key added here would ship silently — exactly the blindness #9741 / #9805 / #11145 closed one door at a time.
Why this is the same shape #11006 adjudicated, one level earlier
#11006 (maintainer ruling 2026-08-22, 「同意所有」 item 5, option B) was about a half-declared door: PublishMetaItemResponseSchema existed (#7294) while the request schema and the interface member did not. This door is a step behind that — neither side is declared. The in-tree comment at rest-server.ts:5812 states the position as it stands: "auditMetaItem is not a member of …".
So the question is the same one #11006 answered, and it is a maintainer call rather than a mechanical catch-up:
⚠️ Not a straight copy of #11006's answer: the audit door has its own history (#9426 covered its {events: []} behaviour on a missing capability), and B widens the declared surface, which the startup scope discipline weighs against on its own terms. Needs triage into domain:spec, not a same-lane fix.
Scope note
Deliberately not bundled into #11145's PR: that card's file surface is this file, but its scope is the one method, and the bounded in-place exemption does not apply — the correct shape here is not pinned by existing evidence, it is an open contract decision.
Found while implementing #11145 (the
publishMetaItemconsumer cleanup) — the retired docblock there named this door as its twin, and the twin is still in the statepublishMetaItemjust left. Filed rather than touched: the fix is apackages/speccontract decision, andpackages/specis off limits from the engine lane.Measured on
origin/main@c251ef4213auditMetaItemappears zero times inpackages/spec/src/api/protocol.zod.ts:Positive control that the matcher works: the same grep against
publishMetaItemin that file returns 4 hits, andMetadataProtocolgained itspublishMetaItemmember at line 2535 via #11426.Both REST sites still reach the method through a cast —
packages/rest/src/rest-server.ts:5787:if (typeof (p as any).auditMetaItem !== 'function')— the feature-detection guard5873:const result = await (p as any).auditMetaItem({ … })— the callThe request literal at 5873 threads four members (
type,name,organizationId, conditionallylimit). No declared type sees any of them, so an undeclared key added here would ship silently — exactly the blindness #9741 / #9805 / #11145 closed one door at a time.Why this is the same shape #11006 adjudicated, one level earlier
#11006 (maintainer ruling 2026-08-22, 「同意所有」 item 5, option B) was about a half-declared door:
PublishMetaItemResponseSchemaexisted (#7294) while the request schema and the interface member did not. This door is a step behind that — neither side is declared. The in-tree comment atrest-server.ts:5812states the position as it stands: "auditMetaItemis not a member of …".So the question is the same one #11006 answered, and it is a maintainer call rather than a mechanical catch-up:
AuditMetaItemRequestonMetadataProtocol, mirroring what feat(spec): declare publishMetaItem as an optional MetadataProtocol member with PublishMetaItemRequest #11426 did for publish, after which the cast comes off in the engine lane the way Remove the(p as any)cast at the RESTpublishMetaItemcall site onceMetadataProtocoldeclares the member (#11006 follow-up) #11145 did it.{events: []}behaviour on a missing capability), and B widens the declared surface, which the startup scope discipline weighs against on its own terms. Needs triage intodomain:spec, not a same-lane fix.Scope note
Deliberately not bundled into #11145's PR: that card's file surface is this file, but its scope is the one method, and the bounded in-place exemption does not apply — the correct shape here is not pinned by existing evidence, it is an open contract decision.