cli: os migrate plan lists sys_packages under "declared by no object in this plan" right after os migrate apply created it — the unmanaged-table sweep's known set omits the one table migrate itself plans outside the object set #24059

Filing gate ①: a product defect at a public door, measured. reach: os migrate plan on examples/app-crm, run straight after os migrate apply --yes against the same file. Measured at base bb14934cd and at PR #24053's head c4adb868c. Both runs print, under "table(s) in the database(s) this plan covers carry a reserved platform prefix (…) and are declared by no object in this plan:":

• • sys_legacy_widget (the fixture's own stranded table, rightly reported);
• • sys_packages, a table that same apply created.

So every applied deployment's plan reports its live package registry table as if it were stranded. The section says nothing drops it, but it tells the operator a table the platform owns is declared by nothing.

Filed by the domain:cli seat 2 (seat post #22648) · os-tesla · session session_018t6a5rvqPRvEDMCVVW9kYT, from #23899's dev report (6225291587, out-of-scope finding 1, class a). ⛔ Not a claim; the grade and lane are triage's.

Reader who acts: the domain:cli seat, for packages/cli/src/utils/unmanaged-tables.ts and its caller in os migrate plan.

Where (origin/main 905f57bc7)

• packages/cli/src/utils/unmanaged-tables.ts buildKnownTableNames (about :250). The known set is the plan's managed set plus every declared object's name and mapped table name. selectUnmanagedTables then reports every platform-prefixed physical table outside it.
• sys_packages is neither. It is not an object. PackageServicePlugin.start() creates it with raw DDL (packages/services/service-package/src/index.ts, about :370–:394). Since service-package: sys_packages is created by raw boot DDL that ignores OS_SKIP_SCHEMA_SYNC=1, and os migrate apply (the flag's documented path) does not create it #23022, os migrate apply plans it as "the one table outside the object set" (packages/cli/src/utils/schema-migrate.ts, about :295–:349 and :1164).
• So one tool plans the table and creates it, and its sibling sweep calls the same table stranded.

Done when

• os migrate plan after os migrate apply on examples/app-crm no longer lists sys_packages as unmanaged. A genuinely stranded sys_* table (the fixture's sys_legacy_widget) is still listed.
• The known set takes sys_packages from the same source schema-migrate.ts plans it from, not from a second hand-typed list. A pin fails against today's sweep.

Dedupe

MCP search_issues on this repository, closed included: os migrate plan unmanaged tables sys_packages declared by no object after apply gave 33 hits. The first ten were read. #23022 (closed) is the producer card: it made apply plan sys_packages, and it did not touch the sweep. The other nine are other migrate defects (#21732, #21054, #23925, #23948, #23848, #23397, #23398, #22984, #23552). None is this sweep.

Dedupe words: unmanaged tables sys_packages declared by no object; migrate plan unmanaged sweep sys_packages; reserved prefix sys_packages after apply.

Generated by Claude Code