`protocol.deletePackage` finds zero `sys_metadata` rows the data plane finds 3 of — uninstall leaves orphaned rows (persistence half of #7557)

[os-help]

Part of #7557 — transferred to the metadata lane per the cross-seat protocol, from the engine-core dispatch of that card (PR #7700's report located it and deliberately did not patch it from the consumer side).

Symptom (reproduced live on origin/main, 2026-08-11)

DELETE /api/v1/packages/:id reports persisted: { success: false, deletedCount: 0, failedCount: 0 } while the package's sys_metadata rows demonstrably exist and survive: with 3 rows carrying package_id = 'com.repro.b',

• protocol.deletePackage finds 0 rows to delete;
• the same predicate through the data plane finds 3: GET /api/v1/data/sys_metadata?filters=[["package_id","=","com.repro.b"]] → 3 records.

After PR #7700 the dispatcher no longer wraps this in a 200 — but that fix is invisible to THIS defect by construction (failedCount: 0 legitimately reads as success). The rows still orphan until the producer stops missing them.

Located mechanism (from PR #7700's verification)

packages/metadata-protocol/src/protocol.ts:11486-11488:

const where = { package_id: request.packageId };
if (request.organizationId) where.organization_id = request.organizationId;
const rows = await this.engine.find('sys_metadata', { where });

The where clause is not intrinsically wrong (the data plane returns 3 with it). The scoping the protocol's engine applies to it is the suspect — strongest candidate: strict organization_id equality against rows stored env-wide (organization_id IS NULL). This is the same defect class this package already fixed once at sys-metadata-repository.ts:887-901, where identical strict equality silently dropped env-wide drafts and was replaced by an $or over [{organization_id: oid}, {organization_id: null}] (the orphaned-draft bug). Re-check commands:

git grep -n "organization_id" origin/main -- packages/metadata-protocol/src/protocol.ts | sed -n '1,10p'
git show origin/main:packages/metadata-service/src/sys-metadata-repository.ts | sed -n '880,905p'

Adjacent, distinct

• MetadataFacade.unregisterPackage removes only object contributors — every non-object item the package shipped stays registered #7221 (open finding): MetadataFacade.unregisterPackage removes only object contributors — same family at the in-memory layer; this card is the persisted layer. PR fix(engine-core): propagate package disable to metadata listings and the data plane (#7557) #7700's measured fix path did not run through it.
• PR fix(engine-core): propagate package disable to metadata listings and the data plane (#7557) #7700 shipped: disable enforcement (metadata listing + data plane) and the honest uninstall envelope. This card is the remaining third piece.

No domain:* label applied — routing labels are the triage seat's single-producer territory; filed with pm:queue per the transfer-via-target-queue protocol.

[os-zhuang]

Triage: domain:metadata appended (card already carried pm:queue from the cross-seat transfer; queue label untouched). Landing anchors read this round on origin/main @ a3c0865:

• The suspect where-clause is at packages/metadata-protocol/src/protocol.ts:11540-11542 (body cites 11486-11488 — drifted, same code: where = { package_id } + strict organization_id equality when set). packages/metadata-protocol ⇒ metadata lane per the domain table.
• The in-package $or precedent the body invokes is real but the citation's file is wrong: it lives at packages/metadata-protocol/src/sys-metadata-repository.ts:896-899 ($or: [{organization_id: oid}, {organization_id: null}], [BUG] publish-drafts fails with no_draft after saving draft via Studio UI #3115 comment block at :874-877) — not metadata-service (no such path on main). Same fix family, one package, one lane.

Dedup: parent #7557 is pm:dispatched (engine-core half, PR #7700 landed the dispatcher/enforcement pieces); adjacent #7221 is the distinct in-memory layer, held as finding. No other open card or PR covers the persistence half — this card is the single dispatch entry for it.

Not target:v17 (four-class re-run on this split half): the failure is visible (success:false envelope after PR #7700) and orphaned rows are recoverable post-release by a cleanup pass — not an irreversible data shape, not a today-hit on the published surface.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-zhuang]

Claimed — domain:metadata seat.

• Session: session_01GKUiYq4A42J7Aa1QfkKyiX
• Branch: claude/issue-7705-delete-package-org-scope
• Worktree: ../objectstack-7705 (dedicated)
• File surface: packages/metadata-protocol/src/protocol.ts (deletePackage), plus a new pin.

Takes the metadata-protocol slot freed by #7674 / PR #7710 merging.

Dispatched as diagnose-first, because the card's named mechanism may not be the mechanism. The body's strongest candidate is strict organization_id equality dropping env-wide (organization_id IS NULL) rows. But the where-clause applies the org filter only when request.organizationId is truthy:

const where: Record<string, unknown> = { package_id: request.packageId };
if (request.organizationId) where.organization_id = request.organizationId;

If the reproduction issued DELETE /api/v1/packages/:id with no org, where is { package_id } alone — the identical predicate the data plane used to find 3 rows. On that path strict equality cannot be the mechanism, and dropping in an $or would change nothing while looking exactly like a fix. So the dev reproduces and measures which predicate actually reaches the engine before choosing between (a) the route does supply an org id and the #3115 $or shape is right, or (b) the protocol's this.engine is scoped differently from the data plane's, in which case the $or is a workaround over the real defect and PD#5 forbids it. ⛔ Not applied on faith.

Anchors have drifted twice and are re-stated live. Body says protocol.ts:11486-11488; this card's triage comment says 11540-11542; on main @ f7e562457 it is :11626, inside deletePackage at :11613 — PR #7710 merged +559 lines into this same file minutes ago. Triage's other correction is confirmed against main: the $or precedent is packages/metadata-protocol/src/sys-metadata-repository.ts:896-899, not metadata-service (no such path exists).

Two scope fences, both narrow on purpose — this is the repo's hottest file and it is serialized:

• protocol.ts:12085 is out of scope. It carries the byte-identical pattern against sys_metadata_commit. If the measured mechanism implicates it, the dev reports and stops; I file it as its own card rather than growing this diff. Different table, different symptom (missing commit history, not orphaned rows).
• MetadataFacade.unregisterPackage removes only object contributors — every non-object item the package shipped stays registered #7221 stays out — same family at the in-memory layer (MetadataFacade.unregisterPackage). This card is the persisted layer only.

The pin has to assert the consequence. {success: true, deletedCount: 0} against a package with no rows is indistinguishable from this bug, so a call-shaped assertion proves nothing here. The test seeds rows first — including organization_id IS NULL rows, the suspected miss — drives the real uninstall, then asserts no row with that package_id survives and that deletedCount equals what was seeded. Negative direction is load-bearing: another package's rows and another org's rows must not be swept up, because a fix that over-widens the predicate deletes data that should have stayed — which is worse than the bug it closes.

---

Generated by Claude Code