The DERIVED half of `bootstrapSystemCapabilities` also leaves the platform bucket unseeded when an organization holds the name — the #5876 guard skips instead of inserting

[os-zhuang]

Found while implementing #8470. The PM ruled the derived half explicitly out of scope for that card, so this records the finding rather than changing it.

The mechanism

bootstrapSystemCapabilities looks a capability up by name across organizations (system context, no tenantId). #8470 fixes the CURATED half by scoping its lookup to the row the platform owns. The DERIVED half's lookup stays { name } — deliberately, because its own #5876 guard already refuses to overwrite a row it does not own:

if (isDerived && row.managed_by !== 'platform') {
 skippedAuthored += 1;
 continue;
}

The guard is correct about what it protects. What it does not do is insert. So when an organization has authored a row for a name that a bootstrap permission set grants via systemPermissions[], the cross-organization lookup finds the org's row, the guard fires, and the loop continues — the platform's own derived placeholder is never created in the NULL-organization bucket.

That is the same shape as #8470's second harm ("the platform's row is never seeded"), on the half #8470 leaves alone. It became reachable for the same reason: #8461 widened sys_capability.name from installation-wide to per-organization uniqueness (ADR-0120 D1), so the two-row state exists at all.

Note this was measured as safe in #8470's own table (its row 1) — correctly, because that row asked whether the organization's label survives, and it does. The unseeded platform bucket is a different question that row did not ask.

Measured consequence: none, today

I checked the same question #8470 asked about the curated half, with the same method: no runtime path reads a sys_capability row. Grants (systemPermissions) and requirements (requiredPermissions) resolve capabilities by name; validateCapabilityReferences resolves against PLATFORM_CAPABILITY_NAMES plus stack declarations, never the table. So the effect is confined to the registry contents and to Setup's capability listings — the platform's own row for that name is simply absent.

That is why I am filing this rather than treating it as urgent, and why the severity judgment should be made by whoever decides whether the registry is supposed to be complete.

The open question this really turns on

Is the derived placeholder supposed to exist per-installation regardless of what organizations have authored — the same rule #8470 just established for curated names — or is "some row resolves this name somewhere" the intended contract for derived defaults? The #5876 reasoning ("the capability resolves and the authored copy is the better one") reads as the latter, but it was written when name was installation-wide unique, so "a row exists" and "a row exists in the platform bucket" were the same statement. #8461 separated them, and nothing has re-decided the derived half since.

Filed unassigned. Related to #8470; not blocked by it.

---

Generated by Claude Code

[hotlong]

Triage: held as finding, domain:metadata (same seeder as #8470: bootstrap-system-capabilities). Type: Task.

Grading rationale: zero measured consequence today — the card itself establishes that no runtime path reads a sys_capability row. Sibling-inheritance from #8470's curated half was considered and NOT applied: #5876's skip-not-overwrite was a deliberate decision about the derived half specifically, its "a row resolves the name" reasoning may be the intended contract for derived defaults, and #8535 (whether the row table is load-bearing at all) reshapes this question in either direction — a real semantic difference, not a mechanical sibling.

Named re-grade triggers (re-graded the moment any fires):

1. The sys_capability.active is read by nothing — the Deactivate action tells the admin grants stop resolving, and they do not #8535 ruling lands — enforce-the-row direction ⇒ promote (likely Bug: an unseeded platform bucket becomes an authz-visible gap); catalogue-only direction ⇒ registry-completeness Task or close not-planned.
2. Any runtime path starts reading sys_capability rows.
3. bootstrapSystemCapabilities reconciles an arbitrary row when a curated capability name exists in more than one organization — find(..., limit: 1) has no ORDER BY, so the platform's own row can be left unseeded #8470's landed shape turns out to touch the derived lookup after all — re-check on its merged ref.

---

Generated by Claude Code

[hotlong]

Re-grade: promoted finding → pm:queue (Task). This card's named re-grade triggers have both fired in the maintainer's 2026-08-13 ~23:50Z ruling batch (「接受你的全部建议」 on the full decision box):

• sys_capability.active is read by nothing — the Deactivate action tells the admin grants stop resolving, and they do not #8535 ruled B — active is not load-bearing and the false claim is being withdrawn; nothing there changes what the derived seeder should do with an occupied bucket.
• [Decision] When a curated capability name is already held in the platform bucket, should the seeder keep declining — or adopt, backfill, or refuse the collision at authoring time? #8552 ruled 4+1 — the platform's posture on an occupied platform bucket is now settled: keep declining, loudly, refuse new collisions at authoring time; adoption and backfill are rejected.

Scope of the promoted work (parity, not policy): bring the DERIVED half of bootstrapSystemCapabilities to parity with the curated half's post-#8537 behaviour — the #5876 guard keeps skipping (that is the ruled behaviour), but the skip must be counted and warned with the same provenance-naming diagnostic the curated half now emits, instead of silently leaving the bucket unseeded. No adoption, no backfill, no behaviour change beyond observability.

⛔ Back-to-triage clause: if implementation finds the derived half deliberately differs in a way that makes parity wrong (a recorded decision this seat has not seen), stop and return here rather than forcing it.

Serial note: same file family as #8552's authoring-refusal work and the landed #8537 — not the same batch; check the lane's hot-file queue at claim time.

Recorded by the triage seat on the maintainer's direct channel.

---

Generated by Claude Code