You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7aa8d51
Browse filesBrowse the repository at this point in the historyBrowse files
feat(plugin-security): delete the curated capability seeder — the boot writes no sys_capability row for the platform's capabilities (ADR-0131 D3, #15204 stage 6b-1b) (#22709)
Part of #15204
Clause-②: no
**Stage 6b-1b of the cutover plan only** (claim amendment 6098440046):
the curated and derived-default capability seeder
`bootstrapSystemCapabilities`
(`packages/plugins/plugin-security/src/bootstrap-system-capabilities.ts`)
is deleted, with its test, its import and its one call in
`security-plugin.ts`. This is a deletion only (batch #310 item 4). The
rest of #15204 stays open. `bootstrapDeclaredCapabilities`,
`capability-name-collision` and 6b-1a's transitional engine view are
6b-1c's and are kept as they are. No `sys_capability` row is deleted,
`sys-capability.object.ts` is unchanged, and who may author a capability
is unchanged (#22621 → A).
**Landing:** after stage 5 (C9), per stage-0 order correction 3. This PR
stays a draft until the PM schedules it.
## Premise, re-verified on `origin/main` `96469912`
- The seeder is still on `main`: 995 lines, plus a 1,376-line test. Its
only production caller is `security-plugin.ts` (import `:88`, call
`:5015`). `index.ts` does not export it.
- No branch or open PR deletes it. The other `claude/issue-15204-*`
heads are s1, s3 and s6c-prep. Of these, only s6c-prep touches the
module, and only to repoint one import (`per-organization-catalog` to
`organization-scope`, 2 lines). Whichever of the two PRs lands second
gets a modify/delete conflict on this file, and the fix is to keep the
deletion.
- After 6b-1a (#22669), the nine curated names resolve in the registry.
This was measured on a booted showcase (below), and
`builtin-capabilities.boot.test.ts` asserts it.
## Who reads `sys_capability` rows (re-measured on this tree)
| reader | what it is | fresh database after this PR |
|:--|:--|:--|
| Setup nav `nav_capabilities` (`security-plugin.ts:1612`) and the
object's list page | a UI listing of rows | lists only the package rows
(showcase: 2, was 11). Correction 3 holds this PR behind C9, whose
picker reads the registry |
| `sys-capability.object.ts` lookup providers (`:122`, `:132`, `:142`) |
the picker data source | same rows as above |
| the curated-name row gate (`security-plugin.ts` `:7652`–`:7710`, stage
8-pre) | refuses a Setup row claiming a curated name | unchanged. It
reads `PLATFORM_CAPABILITY_NAMES`, not the seeded rows; it reads a row
only to detect a rename |
| `cli/src/utils/organization-ownership-inventory.ts:349` | an ownership
census of the table | counts fewer platform rows; no decision rides on
it |
| `lint/src/validate-capability-references.ts:97` | reads a stack's
`data` seed declarations, not rows | unchanged |
No runtime authorization path reads a row: grants resolve by the name in
`systemPermissions` (`core/src/security`, `rest`, `objectql`, `services`
grep: zero `sys_capability` reads).
## Measured fresh-database effect (showcase, `pnpm dev -- --fresh`, this
branch, all three reads as `admin@objectos.ai`)
| reading | before (`main`, from the 6b-1a report 6096357309 and the
boot pin's old census) | after (this branch, measured) |
|:--|--:|--:|
| `GET /api/v1/data/sys_capability` (the Setup capability list) | 11
rows: 9 curated `platform` + 2 `package` | **2 rows**:
`showcase.export_data`, `showcase.restricted_ops`, both `managed_by:
package` |
| `GET /api/v1/meta/capability` | 11 | 11 (the nine curated names plus
the two package names) |
| `GET /api/v1/meta/capability/manage_users` | 200 | 200 |
| capability refusal or failure lines in the boot log | 0 | 0 |
The derived half adds nothing: the 6b-1a report measured that every
`systemPermissions` entry of the platform's default sets is curated, and
the showcase's one non-curated grant (`showcase.export_data`) is its own
declared capability.
## Changes
- **Deleted:** `bootstrap-system-capabilities.ts` (995) and
`bootstrap-system-capabilities.test.ts` (1,376).
- **`security-plugin.ts`:** removed the import, the
`bootstrapSystemCapabilities` try block, and the
`materializedCapabilityNames` handoff. That variable existed only to
feed the deleted call, and under `noUnusedLocals` it cannot stay. The
`bootstrapDeclaredCapabilities` call, its arguments and the
`withoutPlatformCapabilityDeclarations` view are unchanged; only its
`const capOutcome =` binding goes. Two comments that would now be false
are reworded: the seeding block and the curated-name gate's doc.
- **Tests, each one classified:**
- `bootstrap-seed-round-trips.test.ts`: the `#11451/#11520` describe
asserts the seeder's own round trips, so its eight seeder cases go. One
case (`the existing callers still emit their exact key set`) only calls
`bootstrapDeclaredPermissions` and fences `buildExistingByName`. It is
kept, in a describe of its own.
- `bootstrap-declared-capabilities.test.ts` (measured here; not in the
amendment's list): `CLAIMS a derived … placeholder` used the seeder only
to set up a `platform` row, so it now inserts that row directly.
`declared name suppresses the implicit derived placeholder`, and eight
`#4967 Part 1` cases, assert how the two seeders combine, so they go.
`materializedNames reconciles with the outcome counters` stays. The
whole file goes in 6b-1c.
- `builtin-capabilities.boot.test.ts` (measured here; 6b-1a's pin): its
census expected the nine curated rows. It now expects only the stack's
package row, on a fresh database and on a re-opened one, with zero
writes on the second boot. This is the stage's acceptance pin.
- `seed-name-lookup-degradation-audible.test.ts`,
`bootstrap-platform-admin-seeded-provenance.test.ts`,
`sys-capability.organization-unique.test.ts`,
`driver-sql/…/sql-driver-declared-index-organization-respelling.test.ts`:
each named the seeder in a comment only. The sentence that would now be
false is reworded or dropped. No assertion changes.
- **Comments in surviving modules that would now be false:**
`builtin-capabilities.ts` (item 2 of its header),
`spec/src/security/capabilities.ts` (its consumer list; doc comment
only, no schema or export change),
`lint/src/validate-capability-references.ts` (the "mirrors
bootstrapSystemCapabilities" clause).
- **Censuses, each regenerated by its own tool:**
`scripts/engine-double-contract.baseline.json` loses the deleted test's
row. `node scripts/tenant-audit-census.mjs --write` re-counted the write
call sites (241 → 239, two erased-receiver sites gone). The hand-written
prose counts on `content/docs/permissions/tenant-audit-census.mdx` are
corrected to match, as the gate requires.
- **Changeset:** `.changeset/15204-s6b1b-system-capability-seeder.md`,
`@objectstack/plugin-security` minor.
## Verification
- Build: `--filter '@objectstack/plugin-security...'`, `lint...`,
`driver-sql...`, `dogfood^...`, `runtime...`, plus the packages
`dual-build-cjs-loads` needed: all exit 0.
- `plugin-security`: `typecheck` exit 0 (tsc, scripts, and
`check:test-typecheck`, which covers the tests); `vitest run`: **197
files, 4055 passed / 45 skipped**, at `b88b3567`. The later commit
`264e056d` touched only the two census docs.
- `lint`: 135 files, 6231 passed; typecheck exit 0. `driver-sql`: the
edited file passed 26 tests; typecheck exit 0. `runtime`:
`standalone-stack-seeder-declaration-copy` passed 13 tests.
- Dogfood pins that read capabilities: `security-catalog-showcase`,
`audit-log-audit-capability`, `showcase-d3-d4-capabilities`,
`me-apps-and-everyone-baseline` and `org-admin-affordance-reach`: 5
files, 69 passed.
- `dispatch-gates --commands` derived 121 commands. `--ran` reconciles
**121 derived, 121 run, 0 NOT-MEASURED, 0 UNRUN**. The first pass of
four commands needed work before they passed:
- `check-tenant-audit-census` and its self-test went red on this diff's
real count change, and were fixed above.
- `check-plugin-teardown-shape --self-test` needed an unshallowed clone.
- `check:dual-build-cjs-loads` needed 8 packages built outside the
closure.
- **Line budget:** 2,930 changed lines (+83 / −2,847, 17 files), under
3,000.
## Acceptance notes
- `sys-capability.object.ts:87` still says "The two production readers
of the table are both seeders (`bootstrap-system-capabilities.ts`,
`bootstrap-declared-capabilities.ts`)". The amendment excludes any
change to that file, so it waits for stage 8, which retires the object.
Carrier: stage 8.
- The 6b-1a ACCEPT (6096401008) records the transitional view's deletion
as owed by "6b-1b … together with the seeders". The later amendment
6098440046 moves it to 6b-1c, and the dispatch says not to touch it.
This PR follows the amendment.
- On a database that was already seeded, the curated `platform` rows
stay (no row is deleted). They are no longer refreshed at boot, and
stage 8 / C7b retire them.
---
_Generated by [Claude
Code](https://claude.ai/code/session_0113mDBBZPBFzvZqbJqfaFMv)_
---------
Co-authored-by: Claude <noreply@anthropic.com>
feat(plugin-security): the boot no longer writes `sys_capability` rows for the platform's curated capabilities
8
+
9
+
Clause-②: no
10
+
11
+
The curated and derived-default capability seeder (`bootstrapSystemCapabilities`) is deleted. On a fresh database the boot writes no `sys_capability` row for the nine curated platform capabilities (`manage_users`, `manage_org_users`, `manage_metadata`, `manage_platform_settings`, `setup.access`, `setup.write`, `studio.access`, `manage_sharing`, `view_all_audit_log`), and none for a name a permission set grants in `systemPermissions` without declaring it. The curated capabilities are served by the registry: `GET /api/v1/meta/capability` lists them and `GET /api/v1/meta/capability/:name` answers each one's definition, as before. Declare a capability your package grants with `defineCapability` (`stack.capabilities`); a declared capability is still seeded as a package row.
12
+
13
+
No authorization decision changes: a grant is still resolved by the capability name in `systemPermissions`, and no runtime check reads a `sys_capability` row. On a database that was already seeded, the existing rows stay as they are; they are no longer refreshed at boot.
14
+
15
+
In `@objectstack/spec` (`PLATFORM_CAPABILITIES`) and `@objectstack/lint` (`validateCapabilityReferences`), the doc comments now name the registry instead of the retired seeder; no behaviour changes there.
Copy file name to clipboardExpand all lines: content/docs/permissions/tenant-audit-census.mdx
+17-17Lines changed: 17 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -83,7 +83,7 @@ what moved this page's population from 225 to 227; nothing about the two sites
83
83
changed, only whether this instrument could see them.
84
84
85
85
**The expensive failure direction is a keyword.** Sites whose receiver the author
86
-
typed `any` have no type to read, and there are 53 of them — just over a fifth
86
+
typed `any` have no type to read, and there are 51 of them — just over a fifth
87
87
of the population, concentrated in exactly the seed and bootstrap paths this
88
88
control exists for. Scoring an unreadable receiver as "not an engine" would have
89
89
dropped every one of them silently, with a clean exit and a smaller number that
@@ -122,7 +122,7 @@ are reported as `undecidable` rather than assumed either way.
122
122
123
123
The same holds twice over for the context. An options argument spelled as a
124
124
literal can be read; one spelled `options`, `{ ...opts }`, or handed through a
125
-
forwarding shim cannot, and **53 of the 241 sites are spelled that way**. A
125
+
forwarding shim cannot, and **53 of the 239 sites are spelled that way**. A
126
126
context resolved from an inline literal or a local `const` can be tested for
127
127
`isSystem`; one arriving from a helper call cannot.
128
128
@@ -187,10 +187,10 @@ reproduce them. Where it disagrees, it disagrees on the page:
187
187
188
188
| carried figure | where it survives | this census |
189
189
| :--- | :--- | ---: |
190
-
| 175 write call sites | quoted in the merged changeset |**241**|
190
+
| 175 write call sites | quoted in the merged changeset |**239**|
191
191
| 24 carrying no tenant context | quoted in the merged changeset |**2** provable and tenancy-enabled; **32** more whose options argument is unreadable |
192
-
| 127 of 175 statically decidable, 48 runtime-parameter-name sites | restated on the `isSystem`-scoping card |**160 of 241** decidable, **81** undecidable |
193
-
| 135 (77%) silenced by the `isSystem` guard before the posture gate | the lost issue body — **no surviving corroboration**|**not reproduced**: 128 decidably elevated, 0 decidably not, 105 undecidable |
192
+
| 127 of 175 statically decidable, 48 runtime-parameter-name sites | restated on the `isSystem`-scoping card |**160 of 239** decidable, **79** undecidable |
193
+
| 135 (77%) silenced by the `isSystem` guard before the posture gate | the lost issue body — **no surviving corroboration**|**not reproduced**: 126 decidably elevated, 0 decidably not, 105 undecidable |
194
194
| 141 and 132, two independent re-derivations | the card that filed this work | — |
195
195
196
196
**The differences are not reconciled, and deliberately so.** The old census's
@@ -200,18 +200,18 @@ be stated is what this instrument counts, which is written above and re-runnable
200
200
at any commit.
201
201
202
202
Two structural facts do plausibly widen this reading against any hand or regex
203
-
one, and both are counted in the generated tables below: the 53 sites reached
203
+
one, and both are counted in the generated tables below: the 51 sites reached
204
204
through an erased (`any`) receiver, and the 53 that name their object through a
205
205
`const` rather than inline. An instrument that read either the way a person does
206
206
would report a smaller number and would not say so.
207
207
208
208
The fourth row is the one worth flagging to anyone citing it. **The 135 / 77%
209
209
figure has no surviving corroboration anywhere in the tree.** This census reads
210
-
128 of 241 (53%) as decidably elevated, with 105 more whose elevation is a
210
+
126 of 239 (53%) as decidably elevated, with 105 more whose elevation is a
211
211
run-time fact — so the claim is neither confirmed nor refuted, and the honest
212
212
answer is that a static reading cannot settle it.
213
213
214
-
⇒ **Cite `2 / 241`, and say what it is**: the sites whose options argument was
214
+
⇒ **Cite `2 / 239`, and say what it is**: the sites whose options argument was
215
215
READ and holds no tenant context, against a decidably tenancy-enabled object.
216
216
That is the control's provable yield surface. ⛔ Do not cite it as "the sites
217
217
without tenant context" — **32 further sites** have an options argument this
@@ -223,30 +223,30 @@ cannot read, and they are neither in nor out.
223
223
224
224
| what | count |
225
225
| :--- | ---: |
226
-
| write call sites on the application surface |**241**|
226
+
| write call sites on the application surface |**239**|
227
227
| …whose object name is statically decidable | 160 |
228
-
| …whose object name is chosen at run time |81|
228
+
| …whose object name is chosen at run time |79|
229
229
| …against an object with tenancy ENABLED | 159 |
230
230
| …against an object that declares tenancy off | 1 |
231
-
| threading a tenant context |180|
231
+
| threading a tenant context |178|
232
232
| PROVABLY carrying none (options read, no context key) |**8**|
233
233
| …of those, against a decidably tenancy-enabled object |**2**|
234
234
| options argument UNREADABLE — may or may not carry one | 53 |
235
235
| …of those, against a decidably tenancy-enabled object | 32 |
236
-
| threading a decidably ELEVATED (`isSystem`) context |128|
236
+
| threading a decidably ELEVATED (`isSystem`) context |126|
237
237
| threading a context that is decidably NOT elevated | 0 |
238
238
| threading a context whose elevation is a run-time fact | 105 |
239
239
240
240
| how the instrument reached the site | count |
241
241
| :--- | ---: |
242
242
| receiver carried a readable engine type | 188 |
243
243
| receiver erased, placed by the object NAME | 33 |
244
-
| receiver erased, placed by an `object: string` PARAMETER |15|
244
+
| receiver erased, placed by an `object: string` PARAMETER |13|
245
245
| receiver erased, placed by an `UNTYPED_RECEIVERS` row | 5 |
246
246
247
247
| object name spelled inline | 107 |
248
248
| object name spelled through a `const`| 53 |
249
-
| object name is an `object: string` parameter |19|
249
+
| object name is an `object: string` parameter |17|
250
250
| object name is some other run-time expression | 62 |
251
251
252
252
### Subtractions the census could NOT defend — enforced
@@ -297,13 +297,13 @@ holds still. They are required to be HERE and to say WHEN they were true;
297
297
their values are not compared. The reasoning, and the measurement behind it,
298
298
are in `scripts/check-tenant-audit-census.mjs`.
299
299
300
-
Measured on 2026-10-09 at `5551f8d8d`.
300
+
Measured on 2026-10-10 at `b88b35678`.
301
301
302
302
| corpus scale (not enforced) | count |
303
303
| :--- | ---: |
304
-
| tracked non-test sources scanned |625|
304
+
| tracked non-test sources scanned |631|
305
305
| engine-shaped types recognised | 72 |
306
-
| declared objects in the registry |116|
306
+
| declared objects in the registry |117|
307
307
| same-named calls subtracted as non-engine | 162 |
![objectstack-fleet[bot]](https://avatars.githubusercontent.com/u/254823548?v=4&size=40){kind=avatar}
0 commit comments