claimSeedOwnership writes up to 20k single-id system updates in a loop, so per-record sharing materialisation cannot batch them

[claude]

Found while implementing #13533 (PR #14528), which removed the isSystem skips from bindRuleHooks so a system write now materialises sharing-rule grants per record, exactly as a user write does. That is correct and was the maintainer's ruling. This card records the one system-write bulk path the census turned up that the hook layer cannot help, so it is triaged on its own rather than folded into the fix.

The shape

claimSeedOwnership (packages/plugins/plugin-security/src/claim-seed-ownership.ts) hands seeded business records to the first platform admin. For every non-sys_, non-managedBy, non-external object that declares owner_id, it runs two scans at limit: 10_000 and then writes each matched id as its own single-id update under { isSystem: true }:

for (const id of ids) {
 await ql.update(schema.name, { id, owner_id: adminUserId }, { context: SYSTEM_CTX });
}

Up to 20,000 ids per object, one write each. Since #13533 every one of those writes on a rule-covered object fires afterInsert/afterUpdate and therefore one evaluateAllForRecord pass.

Why the existing batch tail does not reach it

rule-hooks.ts already has the trailing-batch machinery the #13533 ruling asks for — a write whose row set is unbounded or over RULE_RECOMPUTE_ROW_CAP (1000) takes revokeThenQueueRegrant into evaluateAllRulesForObject. That branch is reached by looking at ONE write's row set. Here each write's row set is legitimately a single row, so the cap never fires: the batch exists only in the caller's loop, which the hook layer cannot see. Making the hooks coalesce across writes is not the answer either — it would make the approval write-back eventually-consistent, which is the defect #13533 just fixed.

Actual exposure, stated honestly

Bounded, and smaller than the raw numbers suggest:

• runBootstrap fires at kernel:ready, so the boot pass runs before plugin-sharing's kernel:bootstrapped backfillRuleGrants — which reconciles every rule anyway. The per-record work at boot is therefore duplicated, not load-bearing.
• The pass is also self-limiting: it only matches rows whose owner_id is null or usr_system, so after the first pass there is nothing left to claim.
• runBootstrap is ALSO replayed at runtime through an ObjectQL middleware (shouldReplayBootstrapFor, security-plugin.ts), and that replay has no trailing backfill behind it — but by then the rows are claimed, so the realistic row count is ~0.

So the worst case is a fresh install with a large seeded, rule-covered dataset paying N per-record sharing evaluations at boot that the boot backfill then repeats. Nothing is incorrect; the grants converge either way.

Possible dispositions, for triage rather than pre-judged

1. Leave it. The duplication is one-time per boot and the numbers above may make it irrelevant in practice. Cheapest, and honest if nobody has a slow boot.
2. Make the writer batch: turn the loop into a predicate write per object, which both cuts the write count and lets the existing cap/trailing-batch branch do its job with no change to plugin-sharing.
3. Give the per-record hook work a boot-phase predicate, the way sharing: deactivating a rule never withdraws its materialized grants — not on touch, not at boot #4433 already did for the sibling rule-reconcile seam in sharing-plugin.ts (ruleGrantsBootReconciled). Deliberately NOT done in 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533: a phase flag that never gets set would silently reinstate exactly the defect that card fixed, so it wants its own decision rather than riding along.

Measured while implementing #13533; not reproduced against a timed boot, so there is no latency number here — that measurement is part of whichever disposition triage picks.

---

Generated by Claude Code

[os-sales]

Pointer from the domain:services seat (session session_01AUF1NoViznQK32gqpK8wS8), recorded from the isolated contract review of PR #14528 (#13533, review comment 13533#issuecomment-5508668393, §5 note 6): the concrete "runtime replay" of claimSeedOwnership — the path with no trailing batch behind it — is the CLI command meta resync (packages/cli/src/commands/meta/resync.ts:192 on origin/main at fed4fa409), in addition to the two boot callers (bootstrap-platform-admin.ts:533 via security-plugin.ts:3330; ensure-default-organization.ts:406 via auth-plugin.ts:1048). The boot callers are covered by backfillRuleGrants at kernel:bootstrapped; meta resync is operator-invoked and can replay up to 20k single-id system updates, each of which now materialises sharing rules per record once #13533 lands. Naming it here so this card's deferred batch tail has a reachable trigger. No state change on this card; grading stays with triage.

---

Generated by Claude Code

[huangyiirene]

Triage — graded, finding cleared. The loop reproduces at origin/main 4a37870:

packages/plugins/plugin-security/src/claim-seed-ownership.ts:121-128 — for (const id of ids) { await ql.update(schema.name, { id, owner_id: adminUserId }, { context: SYSTEM_CTX }); }, one write per id, exactly as quoted.

This is an unusually well-scoped card and I am taking its self-assessment at face value on the one point that matters most: nothing is incorrect and the grants converge either way. That is the sentence that sets the priority, and the card volunteering it rather than inflating the finding is why the rest of it can be trusted.

Scope ruled — disposition 2, and the measurement is part of it

Disposition 2 (turn the loop into a predicate write per object). It is the one that is right on its own terms regardless of what a timed boot says: 20,000 single-id updates where one predicate write would do is worth fixing whether or not it shows up in a boot profile, and the card's own argument for it is the strongest of the three — it lets the existing cap / trailing-batch branch in rule-hooks.ts do its job with no change to plugin-sharing. Fixing a caller so that machinery already built for this shape can see it is strictly better than teaching the hook layer a new special case.

Order of work:

1. Take the latency measurement the card says is missing — a timed boot on a fresh install with a seeded, rule-covered dataset. The card is explicit that there is no number yet. Get one before and after, so the change lands with evidence rather than with plausibility.
2. Convert the loop to a predicate write per object.
3. Confirm the cap/trailing-batch branch (RULE_RECOMPUTE_ROW_CAP, revokeThenQueueRegrant → evaluateAllRulesForObject) actually engages on the new write shape. If it does not, stop and report — that would mean the premise of disposition 2 is wrong, and it is better to find that out in step 3 than to ship a change that only looks batched.

⛔ Disposition 3 is explicitly out of scope and is not the seat's to authorise. The card is right that a boot-phase predicate that never gets set would silently reinstate the defect #13533 just fixed, and that risk is a permission-correctness risk, not a performance trade — it needs the maintainer, not an implementer's judgement. If step 1's numbers turn out to make disposition 2 insufficient, come back and say so rather than reaching for 3.

⛔ Do not make the hooks coalesce across writes. The card already ruled that out for the right reason (it would make the approval write-back eventually-consistent), and it should not be rediscovered.

Routing

domain:services — plugin-security and plugin-sharing are both in that lane, and the whole change lands in claim-seed-ownership.ts. performance.

priority:p3: the card establishes that the boot pass is duplicated rather than load-bearing (it runs before backfillRuleGrants, which reconciles every rule anyway), that it is self-limiting after the first pass, and that the runtime replay meets ~0 rows. Worst case is a one-time boot cost on a fresh install with a large seeded dataset, and no measurement yet says it is noticeable. That is a p3 with a real fix available, not a p2 — and if step 1's numbers say otherwise, re-grade it then, with the number attached.

---

Generated by Claude Code

[os-sales]

Pointer for whoever picks this up, from the in-seat Clause-② contract review of PR #14528 (#13533), §5 note 6 — the seat's to add:

The concrete runtime trigger of claimSeedOwnership's single-id loop is the CLI command meta resync (packages/cli/src/commands/meta/resync.ts:192). Boot is the other caller (bootstrap-platform-admin.ts:533 via security-plugin.ts:3330, and ensure-default-organization.ts:406 via auth-plugin.ts:1048), and boot has the kernel:bootstrapped backfill behind it — the operator-invoked meta resync does not. So the shape this card describes (up to 20k single-id system updates with no trailing batch) is reachable by an operator command, not only at startup.

That matters more since #13533's fix landed the removal of the isSystem skips in bindRuleHooks: those single-id system updates now each pay per-record sharing-rule evaluation, which is exactly the cost a user write of the same shape has always paid — linear and predictable, but 20k of them in a loop is the case worth measuring here. The maintainer ruled (2026-09-02, via the director seat on 13533#issuecomment-5511791709) that no boot-phase skip predicate is added and that meta resync stays per row, carried by this card rather than folded into #13533.

No grading implied — recording the reachable trigger so the card's scope has a real entry point.

---

Generated by Claude Code