Report the business identifiers already minted twice by the tenancy split — an operator-facing inventory, on installs the #8686 backfill cannot repair

[hotlong]

Follow-up deliverable required by the #8844 maintainer ruling (comment 5302919977), binding point 3, filed as its own card rather than folded into the fix:

Already-minted duplicates: report, do not rewrite — same posture as #8686. The implementing dev files the duplicate-reporting deliverable as its own follow-up card (dedupe first) rather than folding renumbering into this fix.

Dedupe: searched open and closed issues for an operator-facing duplicate-identifier report (keyword and file-path over the autonumber/tenancy family — #8686, #8844, #5495, #6806, #6249, #8323, #3696, #7287). Nothing covers this. The closest existing thing is backfillSeedTenancy's collisions array (packages/metadata-protocol/src/migrations/seed-tenancy-backfill.ts), which is the seed of the answer but not the deliverable — see "What exists already" below.

Why this is needed, and why it is not the fix

Two producers of untenanted rows have now been closed:

• Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 (PR fix(runtime): stamp seed rows with the install's organization so one object runs one autonumber scope #8832) — the seed loader, plus a one-shot backfill for rows already written;
• System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 — the runtime producer: a system-context write (hook, cron, custom endpoint, runAs: system) on a tenant-scoped application object now resolves the install's organization or is refused.

Neither touches the damage already done. On the reporting install the duplicated numbers have propagated into notification bodies, approval trails and a cross-reference field, so renumbering is off the table there — and both rulings say the same thing: a business identifier that has already been handed out is not the platform's to rewrite. What the operator needs instead is to know which ones they are, per object and per field, so they can decide case by case.

The urgency is that the evidence is perishable. The moment either repair merges the two partitions, the two rows become indistinguishable: the organization_id = NULL marker that says "this one came from the untenanted side" is exactly what the repair overwrites. backfillSeedTenancy already runs its collision probe before the stamp for this reason. An install that upgrades without ever running a report loses the ability to produce one.

What exists already, and what is missing

backfillSeedTenancy returns collisions: [{ object, field, value, rows }] and a buildCollisionProbeSql(object, field) the operator can re-run themselves. That covers exactly one entry point and one moment:

gap	why it matters
only reachable during a backfill run	the report is a side effect of a repair. An operator who wants to know the damage without repairing anything has no door.
only on single-tenant installs	the backfill returns skipped-multi-tenant before the collision probe runs, so the population that most needs a manual decision gets no list at all.
only on the __global__ / organization seed split	it enumerates from _objectstack_sequences rows, so a duplicate on an object whose counter was since merged, or one produced by a different partition pair, is invisible.
no persisted record	the result lives in one log line at boot. There is nothing to hand an auditor, and nothing survives the next restart.
sys_/cloud_/ai_ filtered out	correct for a repair (platform seeds stay global), but a report should not silently omit a real duplicate.

What a fix has to decide

1. Where the door is. A CLI command (os …, next to os migrate) is the obvious shape — it is the surface an operator already uses for exactly this class of question, and it does not need a running server. An admin REST endpoint and a boot-time report are the alternatives; they have different audiences and different disclosure properties.
2. What "duplicate" means for the report. The narrow reading is the ruled one: values held by more than one row within one object/field, across the partitions COALESCE(organization_id, '__global__') separates. A wider reading (any unique-declared field with repeated values, whatever the cause) would also catch damage from other sources — worth deciding explicitly rather than by accident.
3. Output shape and durability. Machine-readable (JSON/CSV, one row per duplicated value with its holder ids, organizations and creation timestamps) so it can be diffed and archived, versus a human summary. Persisting it as data would itself be a schema decision.
4. Whether it also reports the CONDITION, not just the damage. An install still holding a __global__ counter beside an organization-scoped one for the same object is about to mint more duplicates. On a version carrying both Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 and System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 that should no longer happen, so its presence is a useful signal in its own right.
5. Scope beyond the driver. _objectstack_sequences is driver-sql's table (driver-turso inherits it). A report keyed on it does not cover a non-SQL driver, and the data-side probe (group by value, having count greater than 1) does — that is a design choice, not an oversight to discover later.

⛔ Explicitly out of scope, per both rulings: renumbering, deduplicating, or otherwise rewriting any already-minted identifier. This card produces an inventory and nothing else.

Related

• System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 — the runtime producer; this deliverable is its ruling's binding point 3, deliberately not folded into that fix.
• Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 / PR fix(runtime): stamp seed rows with the install's organization so one object runs one autonumber scope #8832 — the seed producer and the one-shot backfill whose collisions array is the seed of this report.
• tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 / 多租户缺陷:unique 物化为全局唯一索引、无视 tenancy,与按租户分裂的 autonumber 序列自相矛盾(跨租户必然撞号 + 存在性探测泄露) #3696 — the adjacent "which partition does uniqueness mean" family.
• Downstream app-side tracking (private): steedos-labs/os-project-titanwind-ehr#1082.

[os-project-manager]

Triage note — four-prism block + recommendation (triage seat, scheduled run).

Routing confirmed as filed: type Feature, domain:cli (the likely door is a CLI command beside os migrate; decision point 1 is the routing question, so re-route if the ruling picks a different door). Manual floor, not auto-adjudicable: feature-class, a new operator-facing surface, and an output-durability question that could become a schema decision. Stays in the inbox.

Four-prism block:

1. Platform long-term coherence — a read-only inventory door beside the existing operator surface adds no runtime path and no schema; persisting results as data, or opening a REST/boot door, would each be their own contract decisions — defer both unless pulled.
2. Measured business pull — required by the System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA) #8844 ruling (binding point 3); a production install with propagated duplicates exists today (downstream tracker linked in the card). The evidence is perishable: the organization_id = NULL marker is destroyed by the very repair that just shipped (fix(runtime): stamp seed rows with the install's organization so one object runs one autonumber scope #8832), so an install that repairs before reporting loses the report forever.
3. AI-agent error-resistance — report-only, with rewriting explicitly out of scope per both rulings; machine-readable output (JSON, one row per duplicated value with holder ids, organizations, timestamps) is consumable by tools and auditors without guessing.
4. Startup scope discipline — the narrowest deliverable satisfying the ruling: one CLI command, the ruled duplicate definition, JSON to stdout, no persistence, no new schema. The wider "any unique-declared field" reading and the REST/boot doors are scope growth — better named-and-declined than drifted-into.

Recommendation on the five decision points: (1) CLI door only; (2) the narrow ruled definition (same object/field value held across the COALESCE(organization_id, '__global__') partitions); (3) JSON to stdout — the operator archives it themselves, no persistence; (4) yes, also report the live CONDITION (a __global__ counter still standing beside an org-scoped one for the same object) — cheap, actionable, and the only forward-looking line in the report; (5) probe the data side (GROUP BY value HAVING count > 1 within partition), not _objectstack_sequences, so the report is driver-neutral and catches merged-counter history.

Timing note: whatever is ruled, the report must be runnable before the #8832 backfill is applied on an install; any operator guidance that mentions the backfill should cross-reference this command once it exists.

Dependency flag: no open card carries a Blocked-by: line pointing here; the #8844 fix ships independently by design.

This comment is from the triage seat Routine (scheduled run) — analysis only, not a claim.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-16, recorded by PM session session_01NYgmGheCzM6NrHZN436Cxf). The maintainer approved the report's recommendation for this card (「主线1 3 4：同意」 — this card sat in the one-line-approval group with the recommendation "adopt triage's five points as-is").

Ruled: the triage seat's recommendations on all five decision points, as written (comment 5304029448):

1. CLI door only (beside os migrate); no REST/boot door.
2. The narrow ruled definition of duplicate — same object/field value held across the COALESCE(organization_id, '__global__') partitions.
3. JSON to stdout, no persistence — the operator archives it; no new schema.
4. Yes, also report the live condition (a __global__ counter still standing beside an org-scoped one for the same object).
5. Data-side probe (GROUP BY value HAVING count > 1 within partition), driver-neutral — not keyed on _objectstack_sequences.

Binding timing note carried forward: the command must be runnable before the #8832 backfill is applied on an install (the organization_id = NULL marker is what the repair overwrites); operator guidance around the backfill cross-references this command once it exists. ⛔ Renumbering/rewriting stays out of scope per the #8844 ruling.

Label flipped needs-user-decision → pm:queue in the same stroke.

---

Generated by Claude Code