[finding] CLOUD_PROVIDED_OBJECT_NAMES misses sys_environment_credential (cloud DOES register it), and the spec still declares sys_tenant_database (cloud does NOT) #18309

Measured while answering the cloud half of #17233, against cloud cb8ee7ff60c097cc21a584fe9caf8ef4391cc0e8 (the REST tip of main, 2026-09-15T15:1xZ). #17233 asked its reader to carry two extra names alongside its own question; both came back with an answer, and each implies a different spec-side edit. Filed rather than fixed — ⛔ no domain:* label, that production is the triage seat's, and both edits land in packages/spec, which is the domain:spec lane's call.

1. sys_environment_credential IS cloud-provided, and CLOUD_PROVIDED_OBJECT_NAMES does not list it

Registration chain, read end to end in cloud:

• packages/service-tenant/src/objects/sys-environment-credential.object.ts:19 — ObjectSchema.create({ name: 'sys_environment_credential', … })
• exported through objects/index.ts, imported by manifest.ts, and listed second in tenantObjects
• tenant-plugin.ts:85-92 spreads tenantObjects into manifestService.register({ objects: manifestObjects, … })

⇒ It is registered by @objectstack/service-tenant on exactly the same path as sys_package, sys_package_version and sys_package_installation, which the allowlist does carry.

⚠️ No live defect reproduces today, and #17233 already measured why: 0 shipped *.object.ts files reference the name, so the object-reference ladder has nothing to falsely refuse. This is an incompleteness in a list, not a broken build — which is precisely the reason it needs a card rather than a fix in flight: the first shipped reference to it would be refused, and the refusal would look like an authoring error rather than a stale allowlist.

2. sys_tenant_database is NOT registered by cloud, and packages/spec/src/cloud/tenant.zod.ts still declares it

Whole-repo census in cloud: 2 files, neither a registration —

• packages/service-tenant/README.md:13 — "The legacy sys_tenant_database (per-organization DB) registry is …"
• packages/service-tenant/migrations/v4-to-v5-env-migration.ts — a migration that moves rows off it, ending in UPDATE sys_tenant_database SET status = 'archived'

⛔ It appears nowhere in tenantObjects and there is no sys-tenant-database.object.ts. Control for the census shape: sys_package_version returns 11 files inside the same package and sys_definitely_not_real returns 0, so the instrument separates present from absent.

⇒ Its absence from CLOUD_PROVIDED_OBJECT_NAMES is correct. What is left open is the other direction, which is the question #17233 asked to have raised: the spec still ships a row schema in packages/spec/src/cloud/tenant.zod.ts for a table the owning runtime no longer registers and actively migrates away from. Whether that is an ADR-0049 retirement unit is the domain:spec lane's grading, ⛔ not decided here.

Suggested shape, offered not asserted

Two independent edits, both in packages/spec:

1. add sys_environment_credential to CLOUD_PROVIDED_OBJECT_NAMES — mechanical, and the same shape as platform-object-names: CLOUD_PROVIDED_OBJECT_NAMES omits sys_package_version, so sys_metadata.package_version_id (shipped metadata-core lookup) is classed as a fictional platform object #16745's fix;
2. grade cloud/tenant.zod.ts's sys_tenant_database declaration under the enforce-or-remove playbook.

⚠️ The list's own header records why neither could be settled from the objectstack side: "They cannot be conformance-tested from this repo — the cloud repo owns that half of the contract." Both readings above are therefore cross-repo facts with a pinned cloud SHA, ⛔ not re-derivable by any gate in this repo.

Dedup: the repo:cloud seam set was enumerated complete (11 open at 2026-09-15T15:08:13Z, later 9) and read; none concerns CLOUD_PROVIDED_OBJECT_NAMES beyond #17233 itself, which this card is the follow-up to. Refs #17233 · #16745 · PR #17214.

Generated by Claude Code