[objectstack-fleet]

Fixes #23047
Clause-②: no

What changed

Once GET /api/v1/auth/me/permissions knows who the caller is, it has two ways to fail, and for the caller they are the same event: the server could not compute the answer.

1. The permission-set resolution rejects. .catch(() => []) turns that into "no sets", and the success body reports systemPermissions: []. This path was already closed.
2. Anything else inside the handler's try throws, for example the effective-object merge or a resolver that throws synchronously. The outer catch answered the pre-ADR-0066 shape, with no systemPermissions. The console reads that as "capabilities unknown" and fails open on it (objectui#4656 keeps that reading for a genuine pre-ADR-0066 server).

The outer catch now answers the closed body. Both bodies below were measured on the test harness, base 84c4fffbcd against head 54bc11877a:

before  {"authenticated":true,"userId":"usr_member","objects":{},"fields":{}}
after   {"authenticated":true,"userId":"usr_member","tenantId":"org_active","positions":[],"permissionSets":[],"objects":{},"fields":{},"systemPermissions":[],"tabPermissions":{}}

The log line is unchanged: [hono] /auth/me/permissions failed at warn, with { err: err?.message }, logged once.

Design

• One builder, used by both paths. mePermissionsBody(identity, grants) builds the authenticated body. The success path passes its computed grants. The outer catch passes closedMePermissionsGrants(): every grant key present and empty, with fresh values on each call. MePermissionsGrants requires all six grant keys, so tsc refuses a caller that drops one. The closed body is therefore the same shape as the success body, not a second literal (pinned: the two bodies have the same key set).
• The catch cannot throw again. identity (userId, tenantId) is captured before the try, and the builder reads nothing but its two arguments.
• tenantId: the closed body now carries the session's tenantId (?? null), the same value the success body carries. The old catch body omitted it.
• positions: [], per the triage decision ("present and empty"): the server vouches for nothing it did not finish computing. The measurement below shows that no console reader takes positions from this body.
• Untouched: the deliberate degraded branch (no SecurityPlugin, or no metadata service), the success body, the resolver-rejection body and /me/apps. The first three are byte-identical on the harness, base against head.
• Spread at both call sites: c.json({ ...mePermissionsBody(...) }). check:route-envelope counts only object-literal bodies and treats a bare call as a relayed one. A bare call took its ruled unenveloped count for this file from 9 to 7, although both bodies are still built in this file. With the spread the count stays an exact list at 9, and the gate script is not edited.

Measurements

Does anything in the console read positions from this body? No.

I read objectui main e5c8ea7fe and the console pin 9646e2ed (shallow git fetch, read-only):

• packages/permissions/src/MePermissionsProvider.tsx has 0 occurrences of positions at both refs. Its MePermissionsResponse declares roles, not positions. The context value it builds exposes roles (data?.roles ?? []), userId, systemPermissions, hasCapabilities and effectiveObjects, and nothing taken from positions.
• The workspace-admin read that the card lists as not measured is useWorkspaceAdminStatus (packages/auth/src/useWorkspaceAdminStatus.ts:220-222). It reads user.positions from useAuth(), which is the auth session. The expression scope's current_user.positions (buildExpressionUser) also comes from useAuth().user.
• So positions: [] in this body opens no handle that the caller's real positions would close.

What /me/apps's catches answer (read only, not changed here)

Measured on the same harness shape:

• The outer catch answers {"apps":[]} and logs [hono] /me/apps failed once. That fails closed.
• The inner catch around the resolution (catch { failOpen = true; }) lists every app when the resolver throws synchronously or its accessor throws, including billing, which requires a capability nobody holds. It logs nothing. An async rejection keeps filtering, so only open is listed. This is an observation, not filed; see the acceptance notes.

Tests

New file current-user-endpoints-outer-catch-closed.test.ts, on the same mount shape as current-user-endpoints-delegated-resolution.test.ts: a bare Hono app, the real registrar, and a locator that throws for an unregistered slot.

• Pin, three throw sites inside the try, after the caller is known:

  • buildEffectiveObjectPermissions throws on a non-object objects value, the one input its doc says it throws on;
  • the resolver throws synchronously, before .catch(() => []) attaches;
  • permissionSetResolver(ctx) throws while reading the method.

  Each site answers 200 with the exact closed body and logs the warn line once.

• Pin: the closed body has the same key set as the success body.

• CONTROL: the resolver rejecting still answers systemPermissions: [] with the session's positions (["org_member","everyone"], non-empty on purpose), and never reaches the outer catch.

• CONTROL: the degraded branch answers its open body, byte for byte.

• CONTROL: a caller with no session gets {"authenticated":false}.

Ablation, run at 54bc11877a:

• Mutation: scripts/ablation-replace.mjs put the old literal back at the outer catch. It ran inside os-verify-lock.sh, so the mutation existed only while the lock was held (11 s). The anchor went from 1 to 0 and the old literal from 0 to 1, and the blob changed from f30ec90107aa to 8a61d5281761.
• Result: Tests 4 failed | 3 passed (7). The three throw-site pins and the key-set pin went red, and the three controls stayed green. The diff for the first red shows exactly the six missing keys.
• Restore: the blob equals HEAD f30ec90107aa again and git diff HEAD is empty.
• No dist/ is involved: the test imports ./current-user-endpoints from source.

Base-against-head measurement (one-off; scratch files deleted): the success, resolver-rejection, degraded and anonymous bodies are byte-identical. Only the three throw sites changed, from the old body to the closed one.

Verification at 54bc11877a

• pnpm --filter @objectstack/plugin-hono-server test: Test Files 29 passed (29), Tests 336 passed (336).

• pnpm --filter @objectstack/plugin-hono-server typecheck: exit 0, ending in check:test-typecheck: OK ... 0 file(s) / 0 error(s). The test program lists 466 files, and the new test is counted in it.

• Gates: node scripts/pm/dispatch-gates.mjs --commands derived 65 commands at 54bc11877a, the same 65 the claim's paths derive. I ran all 65 on the clean final tree, with each exit code captured before any pipe, and all 65 exited 0. Reconciliation: dispatch-gates --ran printed 65 derived famil(ies) accounted for — 65 run, 0 NOT-MEASURED (a DERIVED zero — all 65 recorded an exit code and none of them is 3). Lines worth naming:

  • check:route-envelope prints exempt, closed at unenveloped 9: packages/plugins/plugin-hono-server/src/current-user-endpoints.ts.
  • check:nul-bytes prints OK (scanned 11073 text file(s) ... no raw ASCII control bytes).
  • check:dual-build-cjs-loads and check:lean-entry-closure were measured, not refused: the workspace dist/ was present after check:type-check-debt's own build.

  The derivation names what sits outside the 65 and is CI's to run: 51 artifact-roster families, 10 wide-population families, 6 families that take a workflow value, 5 path-scheduled CI jobs and 4 type-check lanes. At the time of this report the tree is 6 commits behind origin/main 038d4c9588. None of those commits touches plugin-hono-server or these files. The one derivation input they change, scripts/check-verify-stand-in-erasure.mjs, only adds packages/verify entries.

• Lint, narrowed: pnpm lint (eslint . --no-inline-config) is CI's run. Locally I ran the same binary and flags over the touched files, with three pieces of evidence:

  • Population: read from eslint.config.mjs, whose config objects match **/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs} and packages/**/*.{ts,tsx,mts,cts}. Both touched .ts files are in it. The changeset .md is not.
  • File count: from --format json, 3 results. 2 files were linted with 0 errors and 0 warnings. The .md was reported as "File ignored because no matching configuration was supplied".
  • Invariance: the config enables no type-aware linting (no parserOptions.project or projectService; its own header says so). So this diff cannot move the verdict on any untouched file.

Acceptance notes

• /me/apps inner catch fails open, silently, on a synchronous resolver throw or a throwing accessor (measured above). This is not filed: there is no real producer. SecurityPlugin's resolvePermissionSetsForContext is async (packages/plugins/plugin-security/src/security-plugin.ts:6804), so it rejects and never throws synchronously, and the published service object exposes a plain method. Carrier: none.
• check:route-envelope blind spot: a body built by a helper in the same file and handed over as a call is counted as relayed, so it drops out of the ruled count. I handled it here by how the call sites are written. The gate is unchanged. Carrier: none.
• check:type-check-debt builds the whole workspace (turbo run build, scripts/check-type-check-coverage.mjs:3505) outside the verify lock. In this session it ran while an earlier ablation's mutation was on disk, and it rebuilt this package's dist/ from the mutated source. I found this by reading dist/, then rebuilt it and proved the old literal absent (ablation-dist-preflight.mjs --absent). The final ablation ran inside the lock, and every gate above was re-run afterwards on the clean tree. Carrier: none.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-hono-server, touching 16 documentable anchor(s).

16 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 038d4c958837fb42e71842c18f062f37bd866811.

⛔ 6 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 2 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 7 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 038d4c958837fb42e71842c18f062f37bd866811 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 038d4c958837fb42e71842c18f062f37bd866811

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