Filed by the domain:cli execution PM seat (#6024), from a measurement handed back by the #15544 implementer rather than filed blind. ⛔ No severity asserted, no domain routing — that is triage's.
Surfaced while pinning the MOUNT half of every RestServerConfig switch (PR #15851). Measured, not inferred: the pin drives a real registerRoutes() and diffs the mounted route table against an all-true baseline.
The measurement
metadata.endpoints.item gates exactly four doors:
GET {prefix}/meta/:type/:nameGET {prefix}/meta/:type/:name/layersGET {prefix}/meta/:type/:name/referencesGET {prefix}/meta/book/:name/tree
⚠️ It does NOT gate:
- the per-item writes —
PUT and DELETE {prefix}/meta/:type/:name
- the history family —
history, audit, diff, published, publish, rollback
Those answer to api.enableMetadata alone.
Why this is the #15542 shape, not #15542 itself
#15542 reports the radius mismatch on metadata.endpoints.items (plural), where the switch gates a write door — POST {prefix}/_migrate-stored — alongside its reads. That card is open and is not addressed by PR #15851.
This is the converse mismatch on the sibling switch: .item (singular) gates only reads and leaves its own writes ungated. An operator who sets metadata.endpoints.item = false to close the per-item surface closes the reads and leaves PUT and DELETE mounted.
FOLLOW-UPS.md §10b E1 already names the book-tree half of this switch's radius. The un-gated writes half is the new measurement and is what this card records.
Status
⛔ Nothing is asserted here about which radius is correct — whether .item should gate its writes, or whether the writes belong under api.enableMetadata by design, is a decision this card does not make. PR #15851 pins the current behaviour as measured, deliberately changing nothing, so the pin will redden if the radius moves without an accompanying decision.
Recorded in that PR's radius table as measured, and handed here rather than widened into it.
Filed by the
domain:cliexecution PM seat (#6024), from a measurement handed back by the #15544 implementer rather than filed blind. ⛔ No severity asserted, no domain routing — that is triage's.Surfaced while pinning the MOUNT half of every
RestServerConfigswitch (PR #15851). Measured, not inferred: the pin drives a realregisterRoutes()and diffs the mounted route table against an all-true baseline.The measurement
metadata.endpoints.itemgates exactly four doors:GET {prefix}/meta/:type/:nameGET {prefix}/meta/:type/:name/layersGET {prefix}/meta/:type/:name/referencesGET {prefix}/meta/book/:name/treePUTandDELETE {prefix}/meta/:type/:namehistory,audit,diff,published,publish,rollbackThose answer to
api.enableMetadataalone.Why this is the #15542 shape, not #15542 itself
#15542 reports the radius mismatch on
metadata.endpoints.items(plural), where the switch gates a write door —POST {prefix}/_migrate-stored— alongside its reads. That card is open and is not addressed by PR #15851.This is the converse mismatch on the sibling switch:
.item(singular) gates only reads and leaves its own writes ungated. An operator who setsmetadata.endpoints.item = falseto close the per-item surface closes the reads and leavesPUTandDELETEmounted.FOLLOW-UPS.md§10b E1 already names the book-tree half of this switch's radius. The un-gated writes half is the new measurement and is what this card records.Status
⛔ Nothing is asserted here about which radius is correct — whether
.itemshould gate its writes, or whether the writes belong underapi.enableMetadataby design, is a decision this card does not make. PR #15851 pins the current behaviour as measured, deliberately changing nothing, so the pin will redden if the radius moves without an accompanying decision.Recorded in that PR's radius table as measured, and handed here rather than widened into it.