fix(service-analytics): declare the measured deny on a kernel with no security service, pin it on both in-repo kernels, give the reconcile runner an explicit security double

[objectstack-fleet]

Fixes #22235

Clause-②: no

Executes the maintainer's ruling B (6056824332): deny, as measured, becomes the declaration. On a kernel that registers no security service, the analytics read bridges deny, fail-closed, as they already did. The comments and the test header now say so, a pin holds it on both in-repo kernels, and the one in-repo producer registers an explicit security double. No line that decides an answer moves, on any context.

What changed

• packages/services/service-analytics/src/plugin.ts: comments only. The resolution blocks of the row-scope bridge (near :556), the object-level admission bridge (near :700) and the field-level and query-side bridges now give the measured classification. ABSENT is reached only by a context that answers a miss with nothing: the package's test doubles do, and no in-repo kernel does. ObjectKernel and LiteKernel throw on a never-registered name, so the bridges take UNUSABLE and refuse with a located error. The same change is made in the two catch comments, the two ABSENT-branch comments, the per-query report comment (the block PR fix(service-analytics): log the admitObjectRead bridge's init-time security absence at info; WARN once at the first query that finds none #22234 last changed) and the two init-time comments. Proof that only comments moved: a comment-stripped transpile (ts.transpileModule, removeComments) of the base file and of this head is byte-identical (sha256 prefix c1a4301c498f8087 both sides, 30086 bytes).
• packages/services/service-analytics/src/__tests__/admission-bridge-resolution.test.ts:
  • The header is rewritten to the ruling. The sentence that called a deny on absence wrong is gone.
  • The ABSENT case keeps its assertions. Its title and inline comment now describe the context it actually models, a lookup that answers nothing.
  • A new pin covers both kernels (describe.each over ObjectKernel and LiteKernel), each booted with no security service ever registered. It asserts that the kernel's own lookup throws, and that the dataset query is refused with code: PERMISSION_DENIED, status: 403 and object: employer_member. It also asserts that nothing was read, and that exactly one error line from the object-level bridge names the object and the failed security lookup. Finally, it asserts that the ABSENT branch's WARN did not fire.
• scripts/analytics-reconcile/boot.ts registers an explicit, OPEN security test double as a named plugin. It answers canReadObject true, getReadFilter undefined (no row restriction) and getReadableFields undefined (no answer). The runner compares numbers, not access: its legacy engine.aggregate() path runs with no caller context on an engine with no security middleware, so the dataset path gets the same posture, declared by name.

Hypotheses, measured on origin/main 3513ac77

• H1, confirmed. The ABSENT rows at plugin.ts:556 and :691 stated "admits" and called a kernel shipping no plugin-security a legitimate configuration. The same claim repeated at the two catch comments, the two ABSENT-branch comments, the report block, the field-level and query-side rows, and both init-time comments. All are rewritten, comments only.
• H2, done. The header is rewritten and the pin is added. The pin's ablation is below.
• H3, confirmed, with a refinement. Driven through boot.ts's own reconcileApp() with one dual-form widget (todo_task by status, task_metrics / task_count), the composition is denied before this change. The dataset query is refused with Access denied and 0 rows, and the bridge logs the UNUSABLE error. After the change, the dataset query answers 4 groups whose counts equal the legacy path's (2, 1, 4, 1). Refinement: on 3513ac77 none of the three shipping runners reaches queryDataset. app-todo.ts boots and skips all 13 widgets and reports as not dual-form, and it exits 0 before and after this change. app-crm.ts and app-showcase.ts fail MODULE_NOT_FOUND on example files that no longer exist (noted below).
• H4, listed, not edited. The release-owned sentences are listed below for the docs card.
• H5 is raised as an open question in the seat report, not built.

Pin and ablation (head 183709e70c)

The pin's subject is imported from source (../plugin.js), so no dist leg applies.

• Green: vitest run over the two admission files gives 2 files and 13 tests passed. The new pin is 2 cases.
• Ablation A1 makes the object-level bridge's catch classify a throw as ABSENT. It went through scripts/ablation-replace.mjs: anchor x1 to x0, replacement x0 to x1, blob ccecf120ec1d to 1d21d50d6cea, with an outer trap restore.
  • Result: 4 failed, 9 passed. Both new pins (ObjectKernel, LiteKernel) are red, together with the double-based throw case here and admission-absence-report.test.ts's real-kernel case.
  • Observed direction: red. The object gate admitted, and the row-scope bridge then refused the same query with READ_SCOPE_COMPILE_FAILED / 500, so the declared PERMISSION_DENIED / 403 envelope naming the object was lost.
  • Restore: blob ccecf120ec1d equals HEAD:plugin.ts, and git diff HEAD is empty.

Local verification (head 183709e70c)

• @objectstack/service-analytics:
  • The build exits 0.
  • typecheck (tsc --noEmit) exits 0. The program includes the test file: --listFiles lists admission-bridge-resolution.test.ts.
  • vitest run --maxWorkers=2: Test Files 180 passed (180). Tests 4443 passed, 262 skipped (4705).
• Gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derives 66 families for this change set. 65 exit 0. pnpm check:dual-build-cjs-loads exits 3, PREREQUISITE NOT MET, because 37 workspace packages have no dist/ in this worktree. NOT MEASURED. A targeted substitute reading, a require() of this package's dist/index.cjs, loads. dispatch-gates --ran: 66 derived, 65 run, 1 NOT-MEASURED, 0 UNRUN.
• check:type-check-debt: 26 raw tsc errors, none above the recorded number. boot.ts carries the same 8 TS2307 it carried before this change, and no other diagnostic.
• Lint, narrowed: eslint --no-inline-config --format json over the 3 touched files reports 3 files, 0 errors and 0 warnings. The config lints every TS/JS file outside its never-linted list, so all 3 are in scope. It never enables type-aware linting (no parserOptions.project), so this diff cannot move the verdict on a file it does not touch. The repo-wide pnpm lint is left to CI.

Changeset: none, skip-changeset

Nothing this package publishes changes behaviour. Its files are dist, README.md and CHANGELOG.md. After a rebuild, three of the new comment phrases occur in 0 files under dist/, while the positive control (a runtime string from the same file) occurs in 2. The test file and scripts/ are not published.

Released sentences that state "absent admits": for the docs card, not edited here

packages/services/service-analytics/CHANGELOG.md:

• :583-584: "A deployment with no security service applies no field-level check, as on the data API."
• :645-647: "A deployment with no security service applies no object-level check, as on the data API."
• :1211-1213: "A deployment with no security service, and an object the security service gives no field answer for, apply no field-level check, as before."
• :1926: "a deployment with no security service registered keeps its previous analytics behaviour by design, because on that deployment /data carries no object-level gate either and the equivalence is what is being defended."
• :1930: "an ABSENT security service admits (that deployment has no object-level gate on /data either, so the two doors still agree, and this is what keeps a deployment shipping no plugin-security working as before)"
• :1936: "The object-level bridge tells three resolutions apart — ABSENT admits, THROWING and METHOD-LESS deny at error."
• :1952: "ABSENT — no security service resolved: unchanged. No row-scope provider on this deployment, which is a legitimate configuration (a single-tenant kernel that ships no plugin-security ...) ... ⛔ Deliberately not tightened: refusing here would break every such deployment."
• :2773: "a deployment with NO security service still runs unscoped exactly as before."

The same lockstep entry repeats, with the :1926 and :1930 sentences, in:

• packages/plugins/plugin-security/CHANGELOG.md:1675 and :1679
• packages/spec/CHANGELOG.md:13374 and :13378
• packages/verify/CHANGELOG.md:571 and :575

content/docs/releases/v17/17-5.mdx:482-484: "A deployment with no security service keeps its old behaviour and warns at init; a registered one that cannot be used denies."

Acceptance notes

• The same declaration repeats outside this card's file surface, in service-analytics:

  • the read-admission.ts module header (:59-65);
  • the admitObjectRead and getReadableFields docs on AnalyticsServiceConfig (analytics-service.ts near :842 and :862);
  • the assertReadAdmitted doc (near :1897);
  • field-read-admission.ts:339-341.

  Each equates "no provider wired" with "a deployment with no security service". Through the plugin a provider is always wired. Reported to the seat with the docs card's list, not edited here.

• On a kernel with no security service, the UNUSABLE error line reads "A security service is wired on this deployment". The assertObjectsReadable denial line that follows reads "the same verdict GET /data/OBJECT reaches". Neither holds on that deployment (measured through boot.ts before this change). These are runtime strings, outside this card's comments-only fence, and are reported to the seat.

• scripts/analytics-reconcile/app-crm.ts and app-showcase.ts import example files that no longer exist (MODULE_NOT_FOUND), and app-todo.ts has no dual-form widget. So no shipping runner exercises the dataset path. Driving one synthetic dual-form widget showed that the reconcile tool keys a select dimension by stored value on the legacy path and by option label on the dataset path. Counts agree, keys differ. Noted, not filed: no runner reaches it.

---

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 8cbe255ef6cadf6a38bcf68a49afa43591f88543 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ea934414a3c1a9ecd6776ff9af408ada03609cdf — the merge of head 183709e70ca3c45a2916ee4e738820d10e558b9f into base 8cbe255ef6cadf6a38bcf68a49afa43591f88543, 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 ea934414a3c1a9ecd6776ff9af408ada03609cdf && git checkout ea934414a3c1a9ecd6776ff9af408ada03609cdf
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8cbe255ef6cadf6a38bcf68a49afa43591f88543 183709e70ca3c45a2916ee4e738820d10e558b9f && git checkout -B drift-repro 8cbe255ef6cadf6a38bcf68a49afa43591f88543 && git merge --no-ff 183709e70ca3c45a2916ee4e738820d10e558b9f

node scripts/docs-audit/affected-docs.mjs --json 8cbe255ef6cadf6a38bcf68a49afa43591f88543

⚠️ 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 8cbe255ef6cadf6a38bcf68a49afa43591f88543 → pass the list as
args.docs, on the commit named under Which tree this was computed on.