plugin-security: claimSeedOwnership re-owns every ownerless row to the platform admin on each app:seeded, not only seed rows, so a record an app keeps unowned on purpose leaves its audience after any restart #23599

Filing gate ①: a product defect with a named producer and a reproduction; a finding, class a (runtime behaviour that contradicts the producer's own stated contract), measured at a public door.
reach: HotCRM on @objectstack/* 18.0.0-next.1 (branch of objectstack-ai/hotcrm#2116, base main 421bd1d8), local database, the public support form /_console/f/support. Measured by the repo:hotcrm seat's dev while working objectstack-ai/hotcrm#2060 item 4 (report comment 6183758498).
Filed by the repo:hotcrm seat (session_01P8mZuzuyZAHSrgQKmv6ASv). The seat re-read the producer on objectstack origin/main 16abea884. ⛔ Not a claim.
Reader: objectstack triage, then the lane that owns packages/plugins/plugin-security.
Dedupe (MCP search_issues, objectstack, open + closed): "claim seed ownership re-owns unowned rows owner_id null on every restart app:seeded" → 1 hit, #14157 (closed: maybeSeedDevAdmin gating on any sys_user row), a different defect.

Seen

1. With the Service Agent position empty, an anonymous submission of the support form (POST /api/v1/forms/support/submit → 201) creates a crm_case with owner_id = null. That is intended: HotCRM's criteria rule case_unassigned_triage_sharing (record.owner_id == null && status not resolved/closed → edit for position service_agent) is the triage queue for exactly these rows.
2. Once the pool is staffed and the rule evaluated, service.agent reads the case (CASE-00045: GET 200, owner_id null).
3. After a plain objectstack start restart, the same case is owned by the platform admin admin@objectos.ai, and the agent's GET answers 404. CASE-00040, -42 and -43 went the same way on a dev watch auto-restart: updated_at = the boot instant, updated_by null.

So every restart empties the app's "Unassigned — Triage" queue and hands the backlog to an identity that holds no app capability. No seed row is involved: these cases were created at runtime by a public form.

Producer

packages/plugins/plugin-security/src/claim-seed-ownership.ts:

• UNOWNED_PREDICATES (L234-237) is [{ owner_id: null }, { owner_id: SystemUserId.SYSTEM }], applied by claimSeedOwnership to every object that declares owner_id (filters (a)–(d) in its docblock: not managedBy, not sys_*, not external). Nothing narrows it to rows a seed wrote.
• security-plugin.ts L1565-1566 subscribes claimSeedOwnershipOnSettle to app:seeded, which fires on every boot (the header, L14-16: "again whenever a seed settles (app:seeded) on every boot — the first one and every later one").
• In the installed 18.0.0-next.1 dist/index.js the same code sits around L8025-8030 and L9903-9917.

The header's contract (L47-49) is "Idempotent: only NULL / usr_system-owned rows are touched, so once a real admin owns them a re-run is a no-op." That holds for seed rows. It does not hold for a row an app leaves unowned by design: owner_id = null is a legitimate runtime state (a queue, a web-to-X intake, a pooled record), and the claim cannot tell it apart from an orphaned seed row.

Expected

The claim re-owns rows the seed wrote, and leaves alone rows created at runtime with no owner. Ways the platform could tell them apart are for the owning lane to choose; for example, the seeder records which ids it wrote and the claim walks only those, or an object can opt out.

Acceptance

• On an app whose seed has settled once, a crm_case-like row created at runtime with owner_id = null keeps owner_id = null across a restart; a criteria share keyed on owner_id == null still reaches its recipients afterwards.
• A seeded row with no owner_id is still handed to the first platform admin, on first boot and on an over-budget background settle (the cases the header's "NOT a single pass" section exists for).

Generated by Claude Code