plugin-dev's "no security services" warning cannot fire for a SecurityPlugin whose start() bailed — the three slots it probes are registered in init(), before the bail

[os-elon]

Found while implementing #7616 (step 2, PR #10035), which had to establish exactly when the security service is and is not registered. Filed rather than fixed there: the defect is in plugin-dev / plugin-security, and #7616's file surface was ruled to be plugin-hono-server plus its pins.

The two registration phases are not the same phase

SecurityPlugin registers in init() (packages/plugins/plugin-security/src/security-plugin.ts:725-743):

• security.permissions, security.rls, security.fieldMasker
• security.bootstrapPermissionSets, security.fallbackPermissionSet, security.baselinePermissionSets

and in start() (:1157, plus every ql.registerMiddleware call from :1166 on):

• the published security service
• all of the enforcement middleware

start() returns early, twice, before any of that (:794-812): once when objectql / metadata cannot be resolved, and once when if (!ql || typeof ql.registerMiddleware !== 'function'). Both log a warn and return.

So a stack in that state has all six init()-registered handles present and no enforcement whatsoever — no RBAC, no RLS, no field masking, and no security service.

What that breaks

packages/plugins/plugin-dev/src/dev-plugin.ts:897 probes precisely those handles to decide whether to warn:

const missing = ['security.permissions', 'security.rls', 'security.fieldMasker'].filter((svc) => {
 try { ctx.getService(svc); return false; } catch { return true; }
});

…and the warning it guards says, in as many words, that "RBAC, row-level security and field masking are NOT enforced".

In the bailed-start state all three resolve, missing is empty, and the warning does not print — in the one state where its text is exactly, literally true. The check answers "is SecurityPlugin loaded?" when the question the warning asks is "is anything being enforced?", and those two came apart at start().

The comment above it is right about the principle it is defending ("a fake that answers allowed is worse than an absent one", #4126 / ADR-0076 D12); the probe just reads a signal that outlives the capability it signals. This is the AGENTS.md "absence must be loud" rule failing in the direction that is hardest to notice: silence read as health.

Why it is worth a card rather than a comment

The same presence signal misled a second consumer, which is how it was found. plugin-hono-server's /auth/me/permissions and /me/apps keyed their degraded branches on security.permissions and therefore, in this state, reported a restrictive permission map computed against enforcement that does not exist — the console hiding what the API serves. PR #10035 fixes that half by keying on the published security service instead, and measured the before/after; it does not touch this one.

Two consumers, two packages, same misread. That is a property of the signal, not of either reader.

Leads, not decisions

1. Probe the thing that means enforcement. The security service is registered only after both bails and only alongside the middleware, so its presence is the honest proxy. Cheapest fix, and it is the same move fix(plugin-hono-server): delegate permission-set resolution to the security service #10035 made.
2. Do not leave a half-initialised presence signal at all — have SecurityPlugin either not register the internal handles until start() succeeds, or register a boot-state handle that says which phase it reached. This is the contract-first shape but it is a behaviour change for anything that resolves those three today.
3. Make the bail itself loud at the composition level. Both early returns currently warn from inside the plugin; neither is visible to a consumer asking "is this stack enforcing anything?".

Worth noting for whoever picks this up: after #10035 lands, security.permissions / security.rls / security.fieldMasker have no non-test consumers left in this repo other than the dev-plugin.ts probe above (verified by grep across packages/ and apps/, excluding tests and the registrar itself). So option 2's blast radius inside this repo is small — though these are resolvable service names and may have out-of-repo consumers.

Unassigned and unlabelled — for the triage seat to grade and route.

[os-zhuang]

Triage: lands in plugin-dev's security-services warning probe ⇒ domain:cli, pm:queue, type Bug. Rationale: the warning probes three handles SecurityPlugin registers in init(), but the failure mode it describes (enforcement absent) happens when start() bails while those handles still resolve — so the warning cannot fire in exactly the state it warns about, and a second consumer was already misled (fixed in PR #10035/#7616). Producer-side note for the dev: if the honest fix is SecurityPlugin not exposing (or explicitly poisoning) its handles until start() succeeds, that lands in plugin-security — report the re-route rather than patching the consumer probe to guess.

---

Generated by Claude Code

[os-elon]

Claim: PM loop round 29
Session: session_019bmVFqoQPq63zhKrxdYG1r
Branch: claude/issue-10036-security-warning-probe
Worktree: objectstack-issue-10036
Domain: domain:cli
File surface: packages/plugins/plugin-dev/src/dev-plugin.ts + its pins · .changeset/** (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus — dispatch-gates --tier gives no path-derived mandate. Above the sonnet floor because the deliverable is a judgement about which signal is honest, not a mechanical edit.
Clause-②: no — this changes when a warning prints; it moves no accept/reject boundary and adds no public surface.
Serial constraints cleared: 🔓 free. Open PRs are the in-flight population (12 open); none touches packages/plugins/plugin-dev/**. ⚠️ A bare claude/* head sweep reported this file as contended on 11 branches — that was a stale-merge-base artifact (those branches carry merges from main; none has an open PR). ⛔ Do not clear serial constraints that way; see #10077's claim for the full reading.

I filed this card, and ⛔ that buys its premises nothing

I filed it out of #7616's measurements. The dev re-derives the anchors on its own branch point — security-plugin.ts:725-743 (the init() registrations), :794-812 (the two start() bails), :1157+ (the published service and middleware), and dev-plugin.ts:897 (the probe). ⛔ If any line has moved, the measurement is the deliverable and my line numbers are not evidence.

⭐ The fork triage named, and it is the whole card

Triage (5349770682) graded this dispatchable with an instruction attached:

"if the honest fix is SecurityPlugin not exposing (or explicitly poisoning) its handles until start() succeeds, that lands in plugin-security — report the re-route rather than patching the consumer probe to guess."

⇒ Two outcomes are both correct, and picking wrongly is the failure mode:

• Consumer-side (option 1) — probe the published security service instead of the three init() handles, because it is registered only after both bails and only alongside the middleware. In surface, small, and it is the same move PR fix(plugin-hono-server): delegate permission-set resolution to the security service #10035 already made for the other misled consumer. Ship it.
• Producer-side (option 2) — plugin-security stops exposing (or poisons) the handles until start() succeeds. Out of surface ⇒ ⛔ do not implement. Report the re-route with your measurement.

⚠️ Do not treat option 1 as a workaround you are settling for. The card's own argument is that the probe reads a signal that outlives the capability it signals — if the published security service is genuinely the honest proxy, fixing the reader is the correct fix, not a patch over a producer bug. Say which you measured it to be, and why.

📌 One measurement in the card to re-verify rather than inherit: it claims that after #10035, security.permissions / security.rls / security.fieldMasker have no non-test consumers in this repo other than this probe. #10035 has since landed (c1731d023). Re-run that sweep — if a new consumer appeared, option 2's blast radius changed and that is worth reporting even though option 2 is out of surface.

---

Generated by Claude Code

[os-elon]

{
 "issue": 10036,
 "status": "done",
 "branch": "claude/issue-10036-security-warning-probe",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/10092",
 "premise_still_valid": true,
 "summary": "Measured option 1 (consumer-side) to be the HONEST fix, not a settle — and the spec already rules on it: packages/spec/src/contracts/security-service.ts:20 names `security.permissions`/`security.rls`/`security.fieldMasker` 'implementation internals and deliberately NOT part of this contract', with the published `security` service as the contract. So a consumer asking a capability question of an internal is the contract violation, and moving the reader onto the published contract is contract-first; option 2 would have had to re-shape an internal to carry a signal the spec deliberately withholds from it. ONE PM PREDICTION WAS WRONG, and it changed the fix: the probe runs in DevPlugin.init(), not start(), so the literal 'swap the probed name at dev-plugin.ts:897' would have warned on EVERY stack including healthy ones — a permanent false positive traded for the false negative. The check therefore MOVED to DevPlugin.start(), after the child-start loop and into the boot banner (the #3900 placement precedent this same file already established), where the question is answerable at all. The three internal handles keep exactly one honest use — discriminating 'never loaded' from 'loaded, then failed to start' — so the warning names which state it saw. Option 2 remains available and its in-repo blast radius is unchanged (still exactly one live consumer, now this discriminator).",
 "tests": "All evidence at final commit b366c6e7f, working tree clean; gate union run AFTER that commit. BEFORE (unmodified main, new test file drives the REAL SecurityPlugin through the real DevPlugin assembly into both bail states): 'Tests 2 failed | 56 passed (58)' — bail #1 'AssertionError: the dev assembly must warn that nothing is enforced: expected +0 to be 1'; bail #2 'expected +0 to be 1'. Each bail test asserts the STATE before the warning: all three init() handles resolve, `security` does not, and SecurityPlugin logged its own bail ('security middleware not registered' / 'does not support middleware'). AFTER: 'Test Files 6 passed (6) · Tests 58 passed (58)' plus plugin-dev typecheck clean. REVERSE VERIFICATION (predicted direction stated first: healthy control turns red): moved the call back into init() keeping the corrected service name — 'Tests 1 failed | 57 passed (58)', the failure being 'does not fire when SecurityPlugin.start() completed and published the `security` service — AssertionError: expected [ Array(1) ] to deeply equal []'. That is the false positive the phase move avoids; direction matched the prediction. Restored via `git checkout --` from the commit, `git diff --quiet` clean (byte-identical), re-run green. ABLATION REBUILD NOTE: the subject resolves intra-package by relative source import ('./dev-plugin'), so no dist/ is in that loop and no rebuild applies to the mutated half; the real SecurityPlugin resolves through `exports` to dist/, built before any measurement via `pnpm --filter '@objectstack/plugin-dev^...' build` (and it is already a registered unaliased import for this package in scripts/check-test-source-alias.mjs, so no ledger change). GATES — 15/15 green, derived by `node scripts/pm/dispatch-gates.mjs` with NO paths passed (script took its own change set from merge base b1457eeca), exit codes captured by redirect-then-read before any pipe, verdicts quoted from each gate's own printed line: check:changeset-gate-self-tests (3x self-test OK); check:objectui-changeset ('all checks passed'); check:slot-lookup ('ratchet holds: 107 unswept site(s), none new; baseline key set verified against b1457ee: no files added'); check:test-source-alias ('OK — 72 packages with tests scanned'); check:type-source-resolution ('OK — 76 packages with a tsconfig.json scanned'); check-adr-0087-registration ('this PR adds no declared-breaking changeset'); check-changeset-no-major ('introduces no `major` bump'); check-empty-changeset ('No empty-frontmatter changeset introduced (1 declaring changeset added)'); check-affected-docs ('self-test: 262 cases pass', exit 0); check:query-options-erasure ('ratchet holds: 67 unswept non-test site(s), none new'); check:type-check-coverage ('OK — 64/77 workspace packages type-checked'); check:type-check-debt --re-measure ('OK — 33 ledger entr(ies) re-measured, 1924 raw tsc error(s), none above its recorded number; surplus: none'); check:engine-double-contract ('OK — 325 pinned, 133 in the DEBT ledger, 2 exempt'); check:where-matcher ('conformance holds: 263 matcher(s), none new'); pnpm lint (eslint clean, no output). No gate refused. No gate weakened: no threshold moved, no baseline raised, no test skipped, quarantined or retry-wrapped. CONSUMER SWEEP re-run rather than inherited, across packages/ and apps/: the card's claim HOLDS — the dev-plugin probe is still the only live non-test consumer of the three handles. Remaining hits are all inert: plugin-hono-server/src/current-user-endpoints.ts:353-356 (post-#10035 prose only), spec/src/contracts/security-service.ts:20 (docblock), plugin-security/src/security-plugin.ts:605 + :725-727 (providesServices + the registrations), and `security.rls.predicate` in packages/spec migrations (a spec surface path, a different namespace, not a service name). No new consumer appeared, so option 2's blast radius is unchanged.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

---

Generated by Claude Code