readonly-package-locks-studio: the read-only metadata refusal keys on the metadata type's overlay policy, not package writability (ITEM_LOCKED / WRITABLE_PACKAGE_REQUIRED never emitted)

[huangyiirene]

Symptom

Studio's read-only lock is real, not cosmetic (207/207 checkboxes disabled, 92/92 bulk buttons disabled, no Save rendered, Publish disabled; a forced click left data-state unchanged; the direct write is refused and the artifact is byte-identical afterwards, sha256 match). But the server-side refusal does not key on package writability:

PUT /api/v1/meta/object/showcase_task → 403 NOT_OVERRIDABLE ("'object' is not allowOrgOverride in the registry"), the same with ?package= pointing at either a read-only or a writable package. ITEM_LOCKED and WRITABLE_PACKAGE_REQUIRED are both in the error-code ledger and neither was ever emitted on this path.

Root cause

Located by the run. SysMetadataRepository.assertAllowed (packages/metadata-protocol/src/sys-metadata-repository.ts ~L1055; code selected at ~L1086: intent === 'runtime-only' ? 'NOT_CREATABLE' : 'NOT_OVERRIDABLE') discriminates on the metadata type's overlay policy (allowOrgOverride in the registry), not on a package-writability check. Confirmed present on origin/main.

Caveat needing a maintainer decision

With the documented operator hatch OS_METADATA_WRITABLE=permission, PUT /api/v1/meta/permission/showcase_contributor?package=com.example.showcase — a set belonging to the read-only package — succeeds (200, env-wide overlay), while Studio still renders that matrix fully disabled with a "Read-only" badge. The hatch is documented as unlocking the write, so this may be intended — but the Studio badge then asserts a lock the server is not applying. Please rule: intended hatch (fix the badge) vs badge is correct (the server should refuse). (The overlay was reverted afterwards.)

Reproduction

1. Stock showcase (read-only package). PUT /api/v1/meta/object/showcase_task → 403 NOT_OVERRIDABLE; repeat with ?package=<read-only pkg> and ?package=<writable pkg> — same code, never ITEM_LOCKED/WRITABLE_PACKAGE_REQUIRED.
2. Set OS_METADATA_WRITABLE=permission; PUT /api/v1/meta/permission/showcase_contributor?package=com.example.showcase → 200 while Studio still shows the matrix disabled with a "Read-only" badge.

Suggested fix

Make the refusal on the package door discriminate on package writability (emitting the ledgered ITEM_LOCKED / WRITABLE_PACKAGE_REQUIRED where appropriate), and resolve the badge-vs-hatch inconsistency per the decision above.

Source

Extracted from the QA run #7637 (framework 92f26f7, console 09987b680).

[huangyiirene]

Claim: PM loop round 12
Session: session_01AmES43BMDg4bPrxTdi5q7t
Branch: claude/issue-7682-package-writability-refusal
Worktree: objectstack-issue-7682
Domain: domain:metadata
File surface: packages/metadata-protocol/src/sys-metadata-repository.ts (region: assertAllowed and the code-selection it feeds) + its tests. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: no in-flight card in this lane declares sys-metadata-repository.ts. Sibling cards on protocol.ts (#8136, #8003) are a different file — do not edit protocol.ts.

Scope ruling (PM, binding for this dispatch). This card carries two separable defects and only the first is dispatched:

1. In scope — the invariant restoration. ITEM_LOCKED and WRITABLE_PACKAGE_REQUIRED are in the error-code ledger and are never emitted on this path; the refusal discriminates on the metadata type's overlay policy instead of package writability. This is declared ≠ enforced, and restoring it needs no maintainer call.
2. Out of scope — the OS_METADATA_WRITABLE hatch vs the Studio "Read-only" badge. The card asks the maintainer to rule "intended hatch (fix the badge)" vs "badge is correct (server should refuse)". That is a product-semantics call spanning this repo and objectui, and it is being filed separately rather than answered here.

Therefore: preserve the OS_METADATA_WRITABLE behaviour exactly as measured — an env-hatch write that succeeds today must still succeed after your change — and pin that behaviour so the separate decision can move it deliberately later. Changing it silently while fixing (1) would pre-empt the maintainer's ruling.

Verified on origin/main before dispatch: the discriminator is live at packages/metadata-protocol/src/sys-metadata-repository.ts:1086 (intent === 'runtime-only' ? 'NOT_CREATABLE' : 'NOT_OVERRIDABLE'), matching the card's ~L1086.

---

Generated by Claude Code

[huangyiirene]

The carved-out half of this card is now filed as #8146 — "OS_METADATA_WRITABLE unlocks a write on a read-only package while Studio renders a 'Read-only' badge — which one is telling the truth?" — carrying needs-user-decision + repo:objectui, with the three options (fix the badge / server should refuse / allow-but-loudly), a recommendation, and the four-cornered card face.

For the dev on this card: nothing changes in your instructions. Preserve the OS_METADATA_WRITABLE behaviour exactly as measured and pin it. #8146 is where it moves, if it moves.

---

Generated by Claude Code

[hotlong]

⚠️ In-flight scope change — read before landing any pin.

Maintainer ruling (2026-08-12, live PM chat session session_01GxKQfv3k8b6a2d2QrZU411, verbatim: 「接受你的全部建议。」 on the decision-box analysis) has settled #8146 as option B: the server should refuse — the badge is telling the truth. The hatch is type-level by its own shipped documentation (content/docs/deployment/environment-variables.mdx:305; v15 release notes distinguish the package-level vs OS_METADATA_WRITABLE type-level gates), so the measured 200 on a read-only package is a bug, not intended behaviour.

Consequence for this card's dispatch: ⛔ do not land a pin asserting the current hatch-bypasses-package-lock behaviour as correct. First re-reproduce the 200 on current main (the original measurement is from two-week-old builds): if it no longer reproduces, pin the refusal and close #8146 as moot; if it reproduces, the deliverable becomes the refusal + a rejection pin (code + status), per #8146's ruling. If your in-flight work has already built the preserve-and-pin version, stop and report — don't merge it.

---

Generated by Claude Code