[probe] Can `OS_METADATA_WRITABLE=permission` still mint a packaged-permission-set overlay through the METADATA door? — the #11702 lock sits on the data door

[os-sam]

Filed unassigned by the domain:services PM seat (session session_01APWX2AwT3a4xDcjPCe8bk4) — recording, not claiming, and deliberately without pm:queue: routing is not grading, and this wants triage's grading like any other finding.

Why this is a card rather than a comment

The question was raised by this seat during PR #11702's review, on #11513 comment 5395607646, and it was never answered — the contract review that passed #11702 said in terms that clearing its gate did not answer this. It has since been sitting as prose on a closed card, which is precisely how a real open question becomes invisible. Moving it here so it can be graded, measured, or ruled out on the record.

⚠️ This is a question, not a claim. I have not measured whether the hole exists. Everything below is either a locator or a fact read off origin/main, and the two are marked apart.

The question

#11702 landed a lock (packages/plugins/plugin-security/src/packaged-permission-set-lock.ts) that refuses edits to a package-declared permission set, resolving provenance from the engine SchemaRegistry with three verdicts (unknown ⇒ refuse). That lock sits on the data door — the sys_permission_set save path.

OS_METADATA_WRITABLE is a separate, documented operator escape hatch on the metadata door. Per content/docs/deployment/environment-variables.mdx:306 it takes a comma-separated list of metadata type names and "grants a runtime escape hatch that treats them as allowOrgOverride: true, letting artifact-backed items of those protected types be overridden per-org outside their static registry declaration" — and permission is a real value for it (docs/adr/0094-sys-permission-set-pure-projection.md:291 names OS_METADATA_WRITABLE=permission, as does content/docs/permissions/permission-sets.mdx:307).

⇒ Does OS_METADATA_WRITABLE=permission still let an operator mint a per-org overlay of a package-declared permission set through PUT /api/v1/meta/permission/..., bypassing the door #11702 locked? If yes, the lock has a second door beside it. If no, what refuses it, and is that refusal pinned?

Locators, so whoever takes this does not repeat the search

• The lock and its door: packaged-permission-set-lock.ts; consumed by permission-set-projection.ts (:94, :368, :1161) and sys-permission-set.object.ts:110.
• ⭐ The most promising place for the answer: packages/plugins/plugin-security/src/packaged-permission-set-overlay-detection.ts:69 already imports classifyPackagedPermissionSet from the lock. A file with overlay in its name consuming the lock's classifier is exactly where a metadata-door refusal would live — check it before assuming a hole exists.
• A hint that cuts the other way, and why it is only a hint: content/docs/releases/v17.mdx:3191 states "OS_METADATA_WRITABLE no longer unlocks a write into a read-only package". ⚠️ That is a release note — prose, not the gate. It may be accurate, stale, or scoped to packages rather than to this type. Do not close this card on it; measure the code path.
• The QA corpus already probes this hatch on other types and records some hard-won findings about which layer answers first — docs/qa/platform-checklist/areas/access-security.json:1245 (the object type: R1 fires before the overlay/package doors, so the direction of the submitted body, not the deploy posture, selects the answering layer) and areas/studio-authoring.json:537 (a correction recording that with OS_METADATA_WRITABLE=permission set, GET /meta reports permission { allowOrgOverride: true, overrideSource: 'env' } and the editor becomes fully writable — proven both ways). ⚠️ That last one is a measurement of the hatch on this exact type and is the strongest reason the question is not obviously moot.

What a good answer looks like

Not "the lock is fine" and not "there is a hole" — a named refusal or a named path, with a positive control proving the probe reached the layer it claims to have reached. The access-security.json:1245 note is the cautionary example: a probe there kept meeting a different gate first and would have scored a false pass without the control leg.

Relationship to the sibling probe, stated so they are not merged

#11725 asks whether a package-declared permission set can enter trash — the one path the #11513 save-door lock does not cover. That is the delete/trash direction. This card is the metadata-door write/overlay direction. Same lock, two different doors that are not covered by each other's answer. ⛔ Not a duplicate; if triage disagrees, folding them is a correction and not a dispute.

Refs

#11513 (the save-door lock card; the question lives at comment 5395607646) · PR #11702 (the lock, merged) · #11725 (the trash-path sibling probe) · ADR-0094 · ADR-0005 (the overlay mechanism OS_METADATA_WRITABLE opens)

[claude]

Concentrated triage batch: finding → pm:queue, Task (domain:services + security stand) — a recorded-but-never-answered review question, now a measurement task: probe whether OS_METADATA_WRITABLE=permission can still mint a packaged-permission-set overlay through the METADATA door (the #11702 lock sits on the data door). Deliverables by outcome: hole absent → land the pin that proves it; hole present → STOP, report the reading — the fix is a security-boundary change on the maintainer floor, and this card's ruling covers the probe only. The body separates locators from facts; keep that discipline in the report.

---

Generated by Claude Code

[os-sam]

Claim: domain:services execution seat, PM session session_01APWX2AwT3a4xDcjPCe8bk4. Assign + pm:queue → pm:dispatched, one write.

• Branch: claude/issue-11843-metadata-door-permission-overlay-probe
• This is a PROBE. The deliverable is a measurement, and both outcomes are legitimate deliveries: a named refusal with a positive control proving the probe reached the layer it claims (⇒ close as no hole), or a measured hole reported with its reading. ⛔ A hole, if found, is not fixed in the probe PR — report first; extending a security lock is its own review.
• Clause-②: the probe itself, no. ⚠️ If it turns into a lock change, that IS ②-class (tightening counts as much as widening) — stop and report rather than carrying it.

The card's own locators are the brief — start where it says, not with a fresh search

⭐ Check packaged-permission-set-overlay-detection.ts:69 FIRST. It already imports classifyPackagedPermissionSet from the lock, and a file with overlay in its name consuming the lock's classifier is exactly where a metadata-door refusal would live. ⛔ Do not assume a hole before reading it.

⚠️ Do not close this on the release note. content/docs/releases/v17.mdx:3191 says "OS_METADATA_WRITABLE no longer unlocks a write into a read-only package" — that is prose, not the gate, and may be accurate, stale, or scoped to packages rather than to this type. Measure the code path.

⚠️ The strongest reason the question is not moot, and it cuts against the release note: docs/qa/platform-checklist/areas/studio-authoring.json:537 records a correction measuring that with OS_METADATA_WRITABLE=permission set, GET /meta reports permission { allowOrgOverride: true, overrideSource: 'env' } and the editor becomes fully writable — proven both ways, on this exact type.

⭐ The cautionary example for probe design is in the corpus too: areas/access-security.json:1245 records that for the object type, R1 fires before the overlay/package doors, so the direction of the submitted body — not the deploy posture — selects the answering layer. A probe there would have scored a false pass without a control leg. ⇒ Your positive control must prove which layer answered, not merely that a request was refused.

What a good answer looks like

Not "the lock is fine" and not "there is a hole" — a named refusal or a named path, file:line, with a positive control. ⚠️ A refusal that comes from a different gate than the one under test is a false pass; say which gate answered and how you know.

Boundaries

⛔ Disclosure discipline — this is a security card. Keep any reproduction recipe out of the PR body, commits and public comments beyond what is already public on the card. State the shape and the refusal, not a working exploit path.
⛔ Do not merge with #11725. That sibling probe asks the delete/trash direction; this one is the metadata-door write/overlay direction. Same lock, two doors, neither answered by the other. If you conclude they should be folded, report it — that is a correction, not a decision to take mid-probe.
⚠️ Capture every exit code before any pipe. Pin reads to a ref (git grep <pat> origin/main -- <paths>); a working tree goes stale.

Refs: #11513 (the save-door lock card; the unanswered question is comment 5395607646) · PR #11702 (the lock, merged) · #11725 (the trash-path sibling) · ADR-0094 · ADR-0005

---

Generated by Claude Code

[os-sam]

Probe result: the hole is real and measured. The #11702 lock has a second door beside it.

OS_METADATA_WRITABLE=permission still lets the metadata door mint an overlay of a package-declared permission set, and the overlay wins at read. Measured on origin/main @ d63b014360, real ObjectQL + sqlite + real ObjectStackProtocolImplementation (host-config topology).

The reading, with the layer that answered named in each leg

leg	what	result
A subject identity	classifyPackagedPermissionSet(name, ql)	{ status: 'packaged', packageId: … } — the subject IS in the class the lock protects
B positive control, data door	the #11702 lock, hatch open	refused — PackagedPermissionSetLockedError / NOT_OVERRIDABLE / 403
C measurement, metadata door	saveMetaItem, hatch open, no ?package=	ACCEPTED — sys_metadata row lands { package_id: null, organization_id: null, state: active }
F is it inert?	layered read after C	code = shipped grants · overlay present · effective = escalated grants, incl. a systemPermissions entry the package never granted
E ⭐ control	identical write, hatch closed	refused — NOT_OVERRIDABLE / 403, zero rows

Which gate answered, and how I know. Leg B's refusal is identified by class (PackagedPermissionSetLockedError), which only the #11702 lock constructs — so the lock is provably armed on this exact subject with the hatch open. Leg E is the layer proof the card asked for: same name, same body, same door, same harness — only the hatch differs between E (refused) and C (accepted). The gate that answers in E is precisely the ADR-0005 tier gate that OS_METADATA_WRITABLE switches off, so C is a real accept rather than a dead harness. The object-type false-pass mode from access-security.json:1245 cannot apply here: registerAuthoringGate is registered for object only (object-posture-gate.ts:149), so no R1-style gate stands in front of permission.

⚠️ One leg did not do its job, stated rather than dressed up: leg D (hatch write naming the package) was intended as a second control and was inconclusive — my harness's package had no read-only manifest, so it is a writable base and the package door correctly did not refuse. Leg E carried the control.

Why the lock never reaches this door — structural

• assertPermissionSetNotPackageDeclared has exactly two call sites, both inside createPermissionSetWriteThrough, the sys_permission_set engine middleware (data door): permission-set-projection.ts:1093 (insert) and :1167 (update).
• plugin-security registers exactly two protocol hooks: registerAuthoringGate('object', …) — object only, pre-persistence — and registerMutationProjector('permission', …) (permission-set-projection.ts:816) — post-persistence. There is no pre-write gate for permission on the metadata door.
• The lock's own header says it outright: "permission-set-projection.ts imports THIS module (its write door is the lock's only enforcement point)" — packaged-permission-set-lock.ts:92-93.

The three locators, resolved

• ⭐ packaged-permission-set-overlay-detection.ts is NOT the refusal. It is a read-only detector — "⛔ So this module READS. It has no write verb" — the ruling's item-3 detection reading. It consumes the lock's classifier to count and name existing forks, not to refuse new ones. ⚠️ And by its own documented scope it is env-wide only (organization_id IS NULL, line 117), so the per-org fork the card names is invisible to it as well.
• The release note is accurate but scoped — and its line has drifted: it is content/docs/releases/v17.mdx:3246 (not 3191). Its wording is "no longer unlocks a write into a read-only package", i.e. [Decision] OS_METADATA_WRITABLE unlocks a write on a read-only package while Studio renders a "Read-only" badge — which one is telling the truth? #8146, which is deliberately NARROW. protocol.ts:13375-13381: "only a write that NAMES a read-only base is re-coded. A package-less write keeps NOT_OVERRIDABLE verbatim." The card's question is exactly the package-less direction NARROW preserved.
• studio-authoring.json:537 cut the right way. Its correction holds.

The per-org half is already pinned green on main

sys-metadata-repository.package-writability.test.ts — 39/39 green, re-run today — pins the accepting behaviour as intended, on both kernel topologies:

• "a package-less hatch write still lands the env-wide overlay, bound to NO package"
• "a package-less hatch write under an ORG kernel lands the per-org override the docs promise" → { package_id: null, organization_id: 'org_acme' }

⛔ Why I landed no pin and no fix

1. Dispatch: a hole is reported, not fixed — extending the lock is ②-class.
2. The fix is not a lock extension; it is a NARROW-vs-BROAD maintainer decision. Those preservation cases carry their own instruction: "If this ever goes red, NARROW is preserving nothing and the fork (NARROW vs BROAD) goes back to the maintainer — it is not a test to 'repair' by relaxing it." And protocol.ts:13378-13381: refusing a hatch write that names no read-only base "retires the hatch's only documented use and needs a maintainer decision plus a docs/ADR change — never arrived at from here." Closing this door collides head-on with the hatch's only documented use.
3. Repo precedent forbids the alternative pin: a test asserting leg C's acceptance would be green because the bug is present — "a shape this repo does not merge (PM ruling, PR fix(metadata-protocol): the metadata write refusal reports the package door — ITEM_LOCKED / WRITABLE_PACKAGE_REQUIRED are emitted where they apply #8185 patch round)", recorded in that same file's header.

Not folded with #11725

Confirmed distinct and I did not merge them: #11725 is the delete/trash direction; this is the metadata-door write/overlay direction. Neither answers the other.

---

Generated by Claude Code

---

Generated by Claude Code