org-override-registry-gate: the `field` overlay lock is not enforced — an artifact-backed field PUT is accepted 200 (and is inert)

[huangyiirene]

Symptom

The registry declares field with allowOrgOverride=false, and the field is artifact-backed — yet the live route accepts the overriding write.

• PUT /api/v1/meta/field/showcase_task.title {name:'title', label:'Tampered', type:'text'} with an admin bearer → 200 state:'active'. Reproduced on showcase_task.status.
• The row is persisted and reads back with _diagnostics.valid=true.
• And the accepted write is inert: GET /meta/object/showcase_task still reads title.label = 'Title'. A brand-new field written the same way never appears in the object's fields either.

So the door answers success twice over — accepted, and stored valid — for a write the registry forbids and the runtime ignores. The object, view, dashboard and job variants all behave correctly in the same run, and locked-override vs open-create were proven independent there.

Root cause (suspected — located, not proven by a fix)

The gate keys on isArtifactBacked(type, name), which resolves through registry.getArtifactItem(singular, name, currentPackageId) ?? registry.getArtifactItem(type, name, currentPackageId) (packages/metadata-protocol/src/protocol.ts:8678-8679). Fields are not registered as standalone field artifact items — they live inside the object — so getArtifactItem('field', 'showcase_task.title') misses. With the artifact lookup empty, the write is classified as a runtime-only create, and the registry entry for field carries allowRuntimeCreate: true:

{ type: 'field', label: 'Field', …, allowOrgOverride: false, allowRuntimeCreate: true, … }

— packages/spec/src/kernel/metadata-plugin.zod.ts:629 on origin/main.

allowOrgOverride: false is never consulted because nothing on this path believes an artifact is being overridden.

Why the pin stayed green: overlay-precedence.test.ts (27 passing) pins the protocol-level denial. The live field route is not in its coverage, so the gate is proven where it is exercised and absent where it is used.

Stale-premise check: re-verified on objectstack origin/main (00e9196) — the isArtifactBacked resolution and the field registry row are both unchanged.

Reproduction

1. Boot the showcase with writable runtime packages; obtain an admin bearer.
2. PUT /api/v1/meta/field/showcase_task.title with {name:'title', label:'Tampered', type:'text'} → 200 state:'active'.
3. GET /api/v1/meta/field/showcase_task.title → the row exists, _diagnostics.valid=true.
4. GET /api/v1/meta/object/showcase_task → title.label is still 'Title' — the accepted write changed nothing.
5. Contrast: the same override attempt against object / view / dashboard / job is correctly refused.

Note for whoever reproduces the object contrast: a trimmed object body hits DESTRUCTIVE_CHANGE first — the full body is needed to reach the registry gate.

Source

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

[huangyiirene]

Claim: PM loop round 4 (domain:metadata seat, huangyiirene term)

• Session: session_01AmES43BMDg4bPrxTdi5q7t
• Branch: claude/issue-7743-field-overlay-lock
• Worktree: objectstack-issue-7743 (dedicated)
• Domain: domain:metadata
• File surface: packages/metadata-protocol/src/protocol.ts (isArtifactBacked and the org-override gate around :8678) + a route-level pin
• Container & model: M ⇒ mode:cloud, model: opus
• Serial constraints cleared: packages/metadata-protocol/src/protocol.ts is free — the organization_id strict-equality family closed out tonight (protocol.deletePackage finds zero sys_metadata rows the data plane finds 3 of — uninstall leaves orphaned rows (persistence half of #7557) #7705 → listCommits misses env-wide sys_metadata_commit rows — same strict organization_id equality #7705 fixed one function away #7779 → Four more strict organization_id equalities left in protocol.ts — two measured (revertCommit / rollbackToPackageCommit), two unverified (duplicatePackage / reassignOrphanedMetadata) #7819 tier 1 756fd12 → tier 2 bcea363), leaving 0 strict-equality sites and no open PR holding the file. Verified at source, not inherited.

Premise accepted as re-verified by the filer at origin/main 00e9196 (both the isArtifactBacked resolution and the field registry row unchanged); the dispatch still requires a fresh check at the branch point, since protocol.ts has taken several merges since.

Two defects are entangled here, and fixing one HIDES the other

The card records both, and this is the part the dispatch is built around:

1. the write is accepted 200 and persists with _diagnostics.valid=true, for an override the registry forbids;
2. the accepted write is inert — GET /meta/object/showcase_task still reads the original label, and a brand-new field written the same way never appears in the object's fields.

⚠️ Refusing the write at the door removes the only evidence that the runtime ignores it. If a later card makes field overrides legal, defect 2 reappears silently with no test in the way. So the dispatch requires the dev to establish whether the inertness is an independent defect — and if it is, to report it rather than fold it in, so it gets its own card while the evidence still exists.

⭐ The reason this survived is a test-placement fact, not an oversight

overlay-precedence.test.ts (27 passing) pins the protocol-level denial. The live field route is not in its coverage, so the gate is proven where it is exercised and absent where it is used.

A new pin written at the same layer would reproduce exactly that blindness — green, and blind to the reported symptom. The pin therefore has to exercise the route, which is the whole lesson of this card.

Gate list names consumer suites by what exercises the symbol

metadata-protocol, objectql, client, runtime, plus qa-dogfood (this is a live-route behaviour and the QA run is where it was found). ⚠️ Path-scoped gate derivation does not find packages/objectql's protocol doubles — that omission sent #7819 tier 1's first head red earlier tonight, and this seat does not intend to re-learn it.

---

Generated by Claude Code