fix(service-analytics): log the admitObjectRead bridge's init-time security absence at info; WARN once at the first query that finds none

[objectstack-fleet]

Fixes #22154

Clause-②: no

What changed

packages/services/service-analytics/src/plugin.ts, the admitObjectRead bridge's absence logging only:

• Init-time line: warn to info, the same level and shape the sibling getReadScope line already uses for the identical situation: [Analytics] admitObjectRead bridged to the "security" service; that service is not registered yet at init and will be resolved per query (plugin order is not significant).
• Per-query bridge, ABSENT branch (the plugin context answers a lookup for security with nothing): it still returns true (admit), exactly as before, and now logs ONE WARN at the first query that finds no service, naming that query's object: [Analytics] No admitObjectRead configured and no "security" service registered when an analytics query needed one (first: "OBJECT") .... Once per plugin instance: a closure flag created per init(), deliberately not a module binding, so a second kernel in the same process gets its own report. The flag records only that the report was made; it caches no verdict, and every query still resolves the service afresh.
• The UNUSABLE branch (lookup threw, or the service answers neither canReadObject nor explain), the getReadScope bridge, and the translateSelectOptions region are untouched.

Tests (all in service-analytics): new src/__tests__/admission-absence-report.test.ts (5 cases); raw-sql-object-routing.test.ts follows the moved WARN text; admission-bridge-resolution.test.ts header comment. One @objectstack/service-analytics patch changeset.

Why the init-time WARN was always false on a default boot (measured)

@objectstack/plugin-security registers the security service in its start(): packages/plugins/plugin-security/src/security-plugin.ts:2355, inside start() (opens at :1646; init() opens at :1461). So at analytics' init() that service can never be present on a composition that ships plugin-security, whatever the plugin order, and the old branch fired on every default boot.

PM mechanism hypotheses, measured

• H1, confirmed at 7d7943dd: the init-time line was ctx.logger.warn at plugin.ts:1449; the getReadScope sibling logs at info at :1430; the admitObjectRead closure built at :754 calls trySecurityAdmission() (ctx.getService('security')) on every call.
• H2, refined. What the per-query bridge does today when no security service resolves depends on how the context answers the miss:
  • a context whose getService returns nothing (every in-package test double): the ABSENT branch admits and, before this PR, logged nothing;
  • the in-repo kernels (ObjectKernel, LiteKernel) THROW on a never-registered name ([Kernel] Service 'security' not found), so the bridge takes the UNUSABLE branch: every query is DENIED PERMISSION_DENIED / 403 with an error line per query, and nothing is read.
  • This PR keeps both outcomes exactly. On the in-repo kernels, absence at query time was and stays loud at error; the new once-WARN lives in the ABSENT branch. The divergence between the two classifications is reported to the seat as a separate finding; it is not changed here.
• H3, green, with a caveat. pnpm check:startup-registry-verdict and pnpm check:init-service-contract are green on this head. The startup-registry gate is ALSO green on the pre-fix tree, and it lists the analytics security probe as read-only (legal) [final: no workspace plugin declares providesServices: ['security']] both before and after. It does not see this shape, because providesServices is init-only by contract and plugin-security registers security in start(). Its green is not evidence for or against this fix.
• H4, pinned and ablated (below).

Before / after, real kernels, built dist

A scratch probe booted a real kernel with a data provider and this plugin, plus optionally a security provider registered after analytics' init, and ran the same dataset query twice. Rows below are admission-related log lines and outcomes.

kernel, security	before (7d7943dd)	after (this head)
ObjectKernel, registered after init	warn at init; 2 queries admitted, 2 reads	info at init; 2 queries admitted, 2 reads
LiteKernel, registered after init	warn at init; 2 admitted, 2 reads	info at init; 2 admitted, 2 reads
ObjectKernel, never registered	warn at init; per query error + 403, 0 reads	info at init; per query error + 403, 0 reads
LiteKernel, never registered	warn at init; per query error + 403, 0 reads	info at init; per query error + 403, 0 reads

Pins (admission-absence-report.test.ts)

1. Default composition on a real LiteKernel, security registered from start(): no admission warn/error at boot; the init line is the info above.
2. Same composition: the first query asks canReadObject('employer_member', ctx); an admitted caller gets rows (1 read); a refusing service gives PERMISSION_DENIED / 403 with 0 reads.
3. Real LiteKernel, no security service ever: no init-time admission WARN; the query is denied PERMISSION_DENIED / 403, 0 reads, with the bridge's existing error line (unchanged outcome).
4. ABSENT resolution (context answers nothing): no WARN at init; the first query is admitted and WARNs once, naming employer_member; the second query is admitted and does not repeat it; no error.
5. Per plugin instance: two separate inits each get their own single report.

Ablations (head 9c632fe74a; mutation through scripts/ablation-replace.mjs with an anchor that must hit, an outer trap restore, and a blob-hash proof)

The subject is imported from source (../plugin.js), so no dist leg applies. Each leg: anchor x1 to x0, replacement x0 to x1, restored blob fc1df493483a equal to HEAD:plugin.ts, git diff HEAD empty.

• A1, the init line back to ctx.logger.warn: 6 failed / 8 passed; red on pins 1 to 5 and on raw-sql-object-routing "leaves default-datasource objects exactly where they were".
• A2, once-guard removed (if (true)): 1 failed / 13 passed; red on pin 4 (the second query repeats the WARN).
• A3, the query-time WARN demoted to debug: 3 failed / 11 passed; red on pins 4 and 5 and on the same raw-sql-object-routing case.

Local verification (head 9c632fe74a)

• pnpm --filter @objectstack/service-analytics build: ok. typecheck (tsc --noEmit, whose program includes the new test file): exit 0.
• pnpm --filter @objectstack/service-analytics exec vitest run --maxWorkers=2: Test Files 179 passed (179); Tests 4415 passed, 262 skipped (4677).
• Gates: the 64 families node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derives on 9c632fe74a, plus pnpm check:startup-registry-verdict and pnpm check:init-service-contract: 66 of 66 exit 0. dispatch-gates --ran: 64 derived, 64 run, 0 NOT-MEASURED, 0 UNRUN.
• Lint, narrowed: eslint --no-inline-config --format json over the 4 touched source files. The config lints every *.{ts,tsx,mts,cts,js,jsx,mjs,cjs} outside its never-linted list and packages/spec/**, so all 4 are in scope; the JSON reports 4 files, 0 errors, 0 warnings. The config never enables type-aware linting (no parserOptions.project), so this diff cannot move the verdict on any file it does not touch. The repo-wide pnpm lint is left to CI.

Acceptance notes

• When a host supplies getReadScope but not admitObjectRead, securityPresentAtInit is never probed, so the admission init line reads "not registered yet at init" even when a security service is present. Before this PR the same branch was a WARN. The line is now info; the condition is unchanged and is noted here, not changed.
• analytics-service.ts:1901 (assertReadAdmitted doc) still says "AnalyticsServicePlugin reports that state at init." It is now reported at init at info, and at the first query at warn. That file is outside this card's file surface, so it is noted here, not edited.
• check:startup-registry-verdict cannot see init-time verdicts about a service its provider registers in start() (see H3).

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-analytics, touching 1 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/plugins/packages.mdx (via AnalyticsServicePlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-6.mdx (via AnalyticsServicePlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 10 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 7b926f76007316ec13d2b17ec4b0a316b94e4d7e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 80040dc7ce7987b0704186536a51e05832a4a3e1 — the merge of head 9c632fe74adcbe08c713f7c8f105f85098a72094 into base 7b926f76007316ec13d2b17ec4b0a316b94e4d7e, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 80040dc7ce7987b0704186536a51e05832a4a3e1 && git checkout 80040dc7ce7987b0704186536a51e05832a4a3e1
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7b926f76007316ec13d2b17ec4b0a316b94e4d7e 9c632fe74adcbe08c713f7c8f105f85098a72094 && git checkout -B drift-repro 7b926f76007316ec13d2b17ec4b0a316b94e4d7e && git merge --no-ff 9c632fe74adcbe08c713f7c8f105f85098a72094

node scripts/docs-audit/affected-docs.mjs --json 7b926f76007316ec13d2b17ec4b0a316b94e4d7e

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7b926f76007316ec13d2b17ec4b0a316b94e4d7e → pass the list as
args.docs, on the commit named under Which tree this was computed on.