Product question: an uninstall with no organizationId deletes EVERY organization's rows for that package (measured 5 of 5, including a foreign org's)

[os-zhuang]

Filed by the domain:metadata PM seat from a measurement made during #7705. Recording it as a product question, not a bug report — I am not asserting the current behaviour is wrong, only that nothing on record says it is right.

No domain:* label — routing is the triage seat's territory. The code is packages/metadata-protocol.

The measurement

protocol.deletePackage builds its selection as:

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

When no organizationId is supplied, the predicate is { package_id } alone — so the uninstall matches every organization's rows for that package. #7705's dev measured this directly on a real engine: 5 of 5 rows deleted, including a row belonging to a foreign org.

Two doors reach this, and they disagree:

• packages/rest/src/package-routes.ts:440 — direct-mount REST, calls deletePackage({ packageId }) with no org. Cross-tenant.
• packages/runtime/src/domains/packages.ts:782 — the dispatcher twin, resolves and passes organizationId. Org-scoped.

So which semantics a deployment gets depends on which door it mounts, and that is not a decision anyone appears to have made deliberately.

Why this is not folded into #7705

#7705 fixed a different defect (env-wide rows surviving an org-scoped uninstall) and deliberately preserved this behaviour: its case 4 pins that a no-org uninstall still clears the package. Narrowing the no-org branch to organization_id IS NULL would have re-created the orphaning bug on the other door. That was the right call for that card — the behaviour is load-bearing until someone decides what it should be, which is this card.

The question

Is a no-org uninstall intended to be a cross-tenant operation? Both readings are defensible:

• Yes — the caller with no org context is the operator/control plane, and uninstalling a package should remove it everywhere; a partial uninstall would leave unreferenced metadata behind.
• No — cross-tenant deletion through a door that simply omitted a parameter is a footgun. Absence of an org id is at least as likely to mean "the caller did not resolve one" as "the caller means all tenants", and the two are indistinguishable at the call site.

The second reading is sharpened by an already-open finding: resolveActiveOrganizationId (packages/runtime/src/http-dispatcher.ts:1687) reads authService?.auth?.api ?? authService?.api with no getApi() fallback (finding #4127, batch 5). That is precisely a path where an org id can go missing by accident rather than by intent — and it is what decides which of the two behaviours a deployment gets.

What would settle it

Whichever way it goes, the outcome should be declared and pinned, not left implicit in a truthy check. If cross-tenant is intended, an explicit parameter (allTenants: true, or a distinct method) makes the intent unmistakable and makes the accidental-omission case fail loudly instead of silently deleting other tenants' rows. If it is not intended, the no-org branch needs a decision about what it should match instead — noting that the naive narrowing re-creates #7705.

[os-zhuang]

Triage: reclassified pm:queue → needs-user-decision, routed domain:metadata.

Classification rationale. The card's own question — "is a no-org uninstall intended to be a cross-tenant operation?" — diverges on product semantics of a destructive, hard-to-reverse operation (deleting other tenants' rows), and no ADR, AGENTS.md norm, or existing ruling on record answers it. That is squarely the step-8 escalation bar; a card whose deliverable is a ruling must not sit in the dispatch queue where it reads as dispatchable. The step-8 "two implementations, governance side wins" default does not settle it: both doors call the same protocol.deletePackage, and even the governance-side door (the dispatcher) omits organizationId whenever resolveActiveOrganizationId comes up empty — the question is what the contract of the no-org call means, which the meta-rule cannot decide.

Routing anchor (read, not guessed). The behavior under decision lives in packages/metadata-protocol/src/protocol.ts:11626 — const where: Record<string, unknown> = { package_id: request.packageId } with the conditional org narrowing directly below (the #7705 comment block). Whichever way the ruling goes, the fix (explicit allTenants parameter, distinct method, or a pinned declaration of cross-tenant intent) lands in that package ⇒ domain:metadata. The two doors (packages/rest/src/package-routes.ts direct-mount, packages/runtime/src/domains/packages.ts:782 dispatcher) would adapt as consumers.

Stale-premise check (origin/main @ 098b629). All three anchors verified: the REST door calls deletePackage({ packageId }) with no org; the dispatcher door resolves and conditionally passes organizationId; protocol.ts:11626 builds the unscoped where when no org is supplied. Premise holds.

Dedup. #7705 (closed — the measurement's origin, fixed a different defect and deliberately preserved this behavior per its case 4), #7557 (open, pm:blocked — disable/uninstall not reaching the metadata/data layer; different defect, already cross-linked). No existing decision card covers the cross-tenant question. Not a duplicate.

Four-lens block (per #7498):
① Platform long-term coherence — an explicit allTenants: true (or distinct operator method) shrinks the special case: absence of a parameter stops meaning two opposite things depending on the mounting door.
② Measured business pull — measured live: 5 of 5 rows deleted including a foreign org's (#7705 dev measurement); any multi-tenant deployment mounting the direct REST door hits this on its next uninstall.
③ AI-agent error-resistance — an implicit truthy check is exactly the surface an AI-written caller misuses silently; a required explicit cross-tenant flag makes accidental omission fail loudly instead of deleting other tenants' rows.
④ Startup scope discipline — no new capability needed either way; the decision is whether to declare the existing cross-tenant behavior or remove it. Deciding now is cheaper than carrying an undeclared destructive semantic.

Release-relevance note for the maintainer: if the answer is "not intended", this is a tenant-isolation data-loss defect on a shipped surface and its execution card would be target:-relevant; left unstamped here because the target judgment presupposes the answer.

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

---

Generated by Claude Code

[huangyiirene]

Evidence bearing on this question, measured while doing #7819 tier 2 (duplicatePackage / reassignOrphanedMetadata, PR #7871). Posting it here rather than acting on it — the decision is a maintainer call and tier 2 explicitly did not touch it. No verdict offered; three facts that change the question's shape.

1. It is a class, not a deletePackage quirk — and there is a wider instance

reassignOrphanedMetadata carries the same no-org shape, one notch wider: its where starts as {}, not { package_id }. So a no-org adopt has no scoping predicate at all.

Measured on a real ObjectQL over a real SqlDriver (three orphans seeded, one per scope):

reassignOrphanedMetadata({ targetPackageId: 'app.iojn2' }) // no organizationId
→ reassignedCount: 3 — orph_env (env-wide) + orph_a (org_active) + orph_b (org_other)

One no-org call rebinds every organization's orphans, exactly as the 5-of-5 deletion here does. Pinned as-is in package-duplicate-adopt-org-scope.integration.test.ts so the door cannot drift while this card is open, and deliberately left un-narrowed for the reason #7705 established.

Whatever is decided here should probably be decided for this method too — and if the remedy is the declared-parameter route (allTenants: true or a distinct method), reassignOrphanedMetadata is the site where an accidental omission is widest, since there is no package_id to bound the blast radius.

2. The "accidental omission" reading is now measured, and one resolver decides four methods

This card sharpens the "No" reading with finding #4127 on resolveActiveOrganizationId. Two additions:

• Four more strict organization_id equalities left in protocol.ts — two measured (revertCommit / rollbackToPackageCommit), two unverified (duplicatePackage / reassignOrphanedMetadata) #7819 tier 1 measured that resolver's body as entirely catch-wrapped, so any throw on the auth seam yields undefined — which omits the predicate, i.e. selects the widest reading. A boundary that fails open is not a boundary, and at the call site "the caller did not resolve one" and "the caller means all tenants" are byte-identical.
• That same resolver now feeds deletePackage, revertCommit/rollbackToPackageCommit (tier 1), and duplicatePackage/reassignOrphanedMetadata (tier 2). One catch-wrapped read decides the tenancy semantics of the whole package-lifecycle surface, not one method.

3. Contrast worth having: these two methods have no door disagreement

The door-disagreement half of this card (packages/rest/src/package-routes.ts no-org vs the dispatcher twin org-scoped) does not reproduce for duplicatePackage / reassignOrphanedMetadata. Each has exactly one production caller — POST /packages/:id/duplicate (packages/runtime/src/domains/packages.ts:696) and POST /packages/:id/adopt-orphans (:669) — and both resolve and pass an org. There is no direct-mount REST twin.

So the no-org door on these two is reached only when the resolver fails or has no active org, never because a second mount was written without one. That isolates the variable: for these methods the cross-tenant path is purely the accidental-omission case, with no "the operator meant all tenants" caller to weigh against it.

4. The orphan population is live, not frozen legacy

reassignOrphanedMetadata's docstring describes orphans as a pre-package-first residue, and ADR-0070 D1 does reject a new orphan naming a read-only package (WRITABLE_PACKAGE_REQUIRED). But a saveMetaItem naming no package at all still succeeds today, landing package_id = null, organization_id = null — measured, and pinned in the same suite.

So the pile this door operates on keeps growing rather than draining, which bears on how long the question can sit open: the blast radius of the widest no-org door is not fixed.

---

Generated by Claude Code