[objectstack-fleet]

Fixes #20995
Clause-②: no (narrowing)

What this changes

A field that declares maskingRule is masked for every non-system caller unless the caller holds all of the field's requiredPermissions (the describe on maskingRule in packages/spec/src/data/field.zod.ts). A caller who carries a principal but resolves no permission set holds no capability, so the rule applies to it. The runtime served that caller the stored value and let it filter, sort, group and aggregate on the field. It now serves the masked value and refuses those queries, as it already did for every other masked caller.

Correction to the card's source-read, measured. The card read the result masker as already masking for this caller. It does not: for a caller who resolves no set, the middleware stood a posture stand-in in for the object, and the stand-in carried no masking rule. The result masker, the predicate guard and the field projections therefore all agreed on "stored and queryable". The disagreement was between that one answer and the maskingRule describe, and the explain engine, which reads the real posture and reports the field partially masked.

Reach (triage step 1), measured on real boots. Doors that serve this caller class with a masked field in reach exist at public entry points: an anonymous public-form door that serves a referenced object's declared display fields, on a deployment that registers no profile for public forms, and every data door for a signed-in user on a deployment whose baseline is switched off. The readings, by door and class, are in the seat's private scratch file issue-20995/reach-readings.txt. Nothing here states a request.

One derivation (triage step 2)

• resolveCallerPosture is the posture every gate and both field projections read. For a caller who resolves a set it is getObjectSecurityMeta, unchanged. For a caller who resolves none it is the stand-in with two things carried from the posture: the object's masking rules, and whether the posture resolved. Every rule then applies (computePartialMaskRules holds nothing to lift it), and an unreadable posture fails closed for this caller as for any other.
• The masked-echo write refusal (step 2.5a) and the aggregate-input guard (step 2.5b) are no longer gated on a resolved set. The predicate guard (step 2.9) never was. Without 2.5a a caller now served the mask could save it back over the stored value.
• isPrincipalLessContext is the one predicate for the hand-off the middleware makes before it resolves anything (no position, no named set, no user id). The middleware and resolveProjectionFieldMask both read it, so the boundary of the class has one answer too: that context is still served stored and the projections still answer the full set.
• The projection asks the on-behalf-of delegator only when the caller resolved a set, as the middleware does.
• ⛔ Not carried into the stand-in: the per-field capability fold and the object's capability contract. getReadableFields still answers the full set for this caller (a masked field is a served column), which is what the service contract in packages/spec/src/contracts/security-service.ts states. No spec file is touched.

Per door, by class

Door, by class	Caller class	Before	After
Anonymous public-form door serving a referenced object's declared display fields	visitor with no session, on a deployment with no public-form profile (resolves no set)	masked field served stored; a search or sort on it answered	masked field served masked; a search or sort on it refused, 403 PERMISSION_DENIED
Record, list and query doors	signed-in user on a deployment with the baseline switched off, holding no grant (resolves no set)	stored; a filter on it answered	masked; filter, sort, group and aggregate refused, 403
Doors that compile their own query and read getQueryableFields	a caller who resolves no set	the field queryable, its value served stored as a group key	the field not queryable, refused 403
Engine middleware, any operation	a context that names only sets resolving to nothing, or holds only an audience anchor no set is named after	stored and queryable	masked and not queryable
Engine middleware	principal-less context (internal)	stored and queryable	unchanged
Engine middleware	a caller who resolves at least one set	unchanged	unchanged

ISecurityService.getQueryableFields for this caller drops the masked fields. getReadableFields and getWritableFields answer as before.

Pins, red then green

• packages/plugins/plugin-security/src/zero-set-masking.test.ts (new). Three caller classes, each by what resolution answers for it: a user id on a deployment with no baseline, no user id with only unresolvable named sets, and no user id with only an audience anchor. Each case first asserts the premise (zero sets). Then the query projection equals the middleware's query guards field for field across four positions and excludes the masked fields; result masking serves them masked and the read projection keeps them; and a masked-echo write is refused with 400 VALIDATION_ERROR. A last block pins the boundary: a principal-less context is handed through untouched and the projections agree.
• packages/plugins/plugin-security/src/get-queryable-fields.test.ts: the one case that pinned the full field set for this caller now expects the masked fields excluded.
• packages/qa/dogfood/test/zero-set-masking.dogfood.test.ts (new). A real boot, two doors: the anonymous public-form door and the record door for a signed-in user with no baseline. Each asserts the scene is real (a system read holds the stored value), the masked field is served masked beside a field served as stored, and on the record door a predicate on it is refused.
• Red on the pins commit 4b7105c437 (tree equal to HEAD for the plugin source): 10 failed, 14 passed. These are the 9 zero-set cases and the updated getQueryableFields case. Premises and boundary green.
• Green on the fix commit 21a8de2f92: the two files 24 of 24. With the masking, readable and writable suites beside them, 76 of 76.

Ablation

The fix reverted by writing the pre-fix blob of security-plugin.ts (from 4b7105c437) into the tree at 075fa174e6. Landing proven by blob hash (58bf1990…, the pre-fix blob) and by the marker resolveCallerPosture counting 8, then 0. Then:

• unit pins: 10 failed, 14 passed, the same ten as the red run;
• plugin-security rebuilt, and ablation-dist-preflight --absent passed: the marker is in none of the 6 built files;
• dogfood pin: 2 of 2 failed, each on the stored value served where the mask was expected.

Restored with git checkout HEAD -- on the absolute path inside an EXIT INT TERM trap. Restore proven byte-identical: the blob hash equals HEAD's (2a1f47aa…), git diff HEAD is empty and the status is clean. Then rebuilt, and the preflight found the marker in 4 built files with the tree clean. Unit pins 24 of 24 and the dogfood pin 2 of 2.

Consumers (Z3), suites run, not edited

• @objectstack/plugin-approvals test: 52 files, 804 passed. Its snapshot redaction reads the read projection intersected with the query one, so a masked field is now dropped from the snapshot for an approver who resolves no set, where it was served stored.
• @objectstack/service-analytics test: 150 files, 3458 passed. Its field gate reads getQueryableFields, so for this caller a masked field is now refused as a group key, aggregate input or filter.

Local verification, at 075fa174e6

• @objectstack/plugin-security test: 151 files, 3276 passed, 23 skipped. Typecheck passed, including the test layer (check:test-typecheck OK).
• @objectstack/dogfood typecheck: passed.
• node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack: 67 commands, all run in one locked sequential script, every exit 0. --ran reconciliation: 67 derived, 67 run, 0 not measured.
• eslint --no-inline-config --format json on the 4 touched TypeScript files: 4 files linted, 0 errors, 0 warnings. The population is eslint.config.mjs's **/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs} minus its never-linted build directories, and all 4 files are in it. The config enables no type-aware linting (its own header states this), so this diff cannot move the verdict on any untouched file. The repo-wide pnpm lint is left to CI.
• check:adr-0087-registration: the changeset reads [BREAKING+bang+clause-②-narrowing], not-required (no-migration-prescription).

Acceptance notes

• Not measured: an approval inbox read on a real boot by an approver who resolves no set. The consumer suites cover that seam, and the field answers it reads are pinned here.
• Not measured: CI's whole-root and workflow-valued families. dispatch-gates names 11 whole-root families and 6 workflow-valued ones as not placeable locally. They run on this PR.
• The gate scripts were read on the base tree. After this branch was cut, origin/main moved by 7 commits. None of them touches this PR's files, so nothing was merged. Two of those commits changed gate scripts (scripts/check-test-typecheck.mts, scripts/cross-package-test-inputs.mjs), and CI runs the new copies.
• The narrowing reaches one authoring shape. A public-form lookup whose first declared display field carries a masking rule now answers 403 for every request from a caller who resolves no set. That door sorts, and searches, by its first display field. The changeset states the class. Whether authoring should refuse that shape is a separate question, reported to the seat.
• Contract docblock, for the spec owner. getMetadataReadableFields' docblock in packages/spec/src/contracts/security-service.ts says the middleware "skips its whole field gate" for a caller with no permission sets. That now holds for the grant-based gates and not for masking. The answers it states are unchanged: the full read set on the data plane. This PR leaves that file alone, by the claim's surface. The plugin's own docblock is updated.
• Unchanged by design, and outside this surface: the per-field capability fold for this caller, admission and row scope for this caller, and the public-form submit path, which never resolves sets. Further findings in the same caller class went to the seat privately, by class, under the disclosure discipline.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-security, touching 4 documentable anchor(s).

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

• content/docs/permissions/field-level-security.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/permissions/index.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via SecurityPlugin (symbol, a top-level class))
• content/docs/ui/forms.mdx (via SecurityPlugin (symbol, a top-level class))

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

• content/docs/releases/implementation-status.mdx (via SecurityPlugin (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

• 1 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 — 16 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 d1f8ce8658b937d3685df62b04e2e478430b8e83 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json d1f8ce8658b937d3685df62b04e2e478430b8e83

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

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 075fa174e61e43e962844e8ff2dd7fff75da39ef
Local-runs: none

Isolated reviewer, read at 2026-10-01T03:55Z. Inputs and nothing else: card #20995 (body and all four comments: triage 5923142248, claim 5923572624, dev report 5924254306, seat ACCEPT 5924277913), PR #21051 (body, five-file list, the net diff from merge base 2f2fa11d to the head), and the head's check-runs. The seven commits main gained since the merge base touch none of the PR's five paths. ⚠️ Security card: everything below is stated by class and position only.

Gate verdicts, read off the head's check-runs

Waited for the head's CI to finish before writing (two polls, three minutes apart). 35 check-runs on the head, all completed: 31 success, 4 skipped (Build Docs, Console Pin Gate, Packed-tarball smoke — path-filtered or opt-in, none a required context), 0 failed. All seven required contexts are success: Lint & Repo Gates, TypeScript Type Check, Test Core (and its six shards), Dogfood Regression Gate (and its three shards), Build Core, Temporal Conformance (live PG + MySQL), Governed Surface Queue Guard. Also green: Check Changeset (the PR Automation job that carries the ADR-0087 registration gate and the no-major guard), the claim guards, Spec property liveness, the four Type Check leaves and Dogfood Verify CLI. These conclusions are the gate verdicts; nothing was built, run or re-run locally.

① Derived judgments

Each accept-set or public-surface change the diff implies, with the verdict on it.

1. One derivation — right. resolveCallerPosture is read at exactly two sites: the engine middleware (its secMeta, which every gate downstream reads: the capability AND-gate, the CRUD gate, the FLS write gate, the masked-echo refusal 2.5a, the aggregate-input guard 2.5b, the predicate guard 2.9 and the step-4 result masker) and resolveProjectionFieldMask, which all three published projections (getReadableFields / getMetadataReadableFields, getWritableFields, getQueryableFields) go through. For a caller with one or more sets it returns the real posture, so that class is byte-identical to before. For a caller with none it returns the stand-in with two things carried from the posture: the masking-rule map and the resolved flag. computePartialMaskRules is untouched and has no empty-set short-circuit (an empty capability set lifts no rule), so the stand-in's rule map is what turns every reader from "stored and queryable" to "masked and not queryable" at once. No second reading of masking is introduced; only the input to the one reading changed. The one reader of masking outside this derivation is the explain engine's injected dep, which reads the posture directly: it agrees with the stand-in on masking by construction (same rule map) and disagrees only on the capability fold for this class, which is the pre-existing F3 the dev reported, not a change this diff makes.

2. Served value for the class: stored → masked — right. Step 4 was never gated on a resolved set; it was inert for the class because the old stand-in carried an empty rule map. The read partial-mask rules for an empty set are every declared rule (the explicit-deny subtraction has nothing to subtract from an empty evaluator map). Pinned three ways in the unit suite, each case asserting the zero-set premise first, and on two real-boot doors in the dogfood pin.

3. Query accept set for the class: filter, sort, group and aggregate naming a masked field → refused 403 — right. Step 2.9 was never gated on a set; 2.5b was and is now ungated. Both read computeQueryGuardFieldPerms, whose map for the class is exactly its masked fields (the evaluator's map for no sets is empty, the capability fold is deliberately not carried). The unit suite proves the published getQueryableFields equal to the two guards' verdicts field for field across the four query positions.

4. Write accept set for the class: an echoed mask → refused 400 — right, and necessary. Ungating 2.5a is the one edit beside the claim's named regions in the same file, and it is load-bearing: a caller now served the mask would otherwise save it back over the stored value. The dev declared it; the seat accepted it; I judge it part of the fix, not scope creep. Callers with sets are unaffected (their condition already held).

5. getQueryableFields for the class: full set → full set minus masked — right. This is the one published answer that moves, and its contract (a subset of the read projection differing by exactly the fields the caller is served masked) now holds for this class as it did for every other.

6. getReadableFields / getWritableFields / getMetadataReadableFields for the class — unchanged on a resolved posture, as claimed. The evaluator's field map for no sets is empty, the stand-in's capability contract is empty, so nothing is non-readable or non-editable and a masked field is kept as a served column: the full set, which is what the service contract in packages/spec/src/contracts/security-service.ts states for the data plane. ⚠️ One branch is narrower than the PR body's "answer as before": on an unreadable posture these now answer [] for the class where they answered the full set before. That is the same fail-closed tier every other caller already got, the changeset declares it ("one more refusal"), and the field-universe resolver and the posture resolver read the same two sources in the same order, so it is reached only where the universe resolves and the posture does not — a corner, on the safe side. Judged right; the PR body's sentence is right on every resolved posture.

7. Middleware fail-closed on an unreadable posture now reaches the class — right. The rules come from that posture; while it is unreadable they are unknown. Declared in the changeset. Principal-less and system contexts still short-circuit before it.

8. The principal-less boundary — preserved, one predicate. isPrincipalLessContext is the old middleware condition extracted byte-for-byte (no position, no named set, no user id) and is now read by the middleware hand-off and by the projection's early answer, so an absent or empty context still answers the full set and is still handed through. A context naming only sets that resolve to nothing, or holding only an audience anchor no set is named after, carries a principal and reaches the gates. The unit suite pins both sides of the boundary.

9. Delegator intersection asked only when a set resolved — right. Matches the middleware's own condition; a caller who resolved nothing reaches the projection only for its masking rules, every one of which already applies.

10. Consumers — nothing beyond the intended safe side. plugin-approvals serves the snapshot fields in the read projection intersected with the query one, so for an approver in this class a masked field is now dropped (the fail-closed shape that seam chose when it landed, not a new behaviour). service-analytics admits a member only when both answers carry its field, so for this class a masked field is refused as a group key, aggregate input, filter or sort key, with the engine's own words. On an unreadable posture the approvals seam reads [] as the denial its own docblock names. Both suites ran green per the dev report and the whole-root test gate on the head is the verdict.

11. Public surface. No spec file, export, REST route or governed path moves. The one REST door that inherits the narrowing without being touched is the anonymous public-form lookup picker: its context names one set, so on a deployment registering no profile for public forms the visitor is in this class, and because the door sorts and searches by its first declared display field, a picker whose first display field declares a masking rule now answers 403 for that class. Covered by the changeset's mechanism and class (a sort key naming the field is refused; a query that must sort or search on it needs the capability or the rule dropped); not named by door, and the door-specific remedy (reorder the display fields, or register a profile holding the capability) is not in the changeset. Judged in ③ as the F4 residual.

12. Reach. The dev measured the class reachable at public doors on real boots, correcting the card's source-read (the result masker did not mask either, because the stand-in carried no rule). The dogfood pin boots the real composition for two doors and asserts the scene first; its file lands in the dogfood package's isolated project by glob, so the Dogfood Regression Gate's conclusion is the gate verdict on it.

② Semver level

• Changeset .changeset/20995-zero-set-masking.md: @objectstack/plugin-security at minor, bang in the title, a BREAKING banner, and Clause-②: no (narrowing). Right: the diff narrows a published accept set for one caller class (values served, queries admitted, one published projection's answer) and widens nothing, which is exactly the no (narrowing) arm; under the launch-window convention a breaking change ships as minor, and the no-major guard ran green. @objectstack/plugin-security is published; @objectstack/dogfood is private, so the dogfood pin needs no changeset. skip-changeset would have been wrong.
• The PR body's line 2 carries the identical declaration.
• ADR-0087 disposition not-required (no-migration-prescription): right. Nothing an author can write is removed, renamed or re-meant; no stored shape, spec key or export moves; objectstack migrate meta has nothing to rewrite. The changeset body carries no migration prescription (its "What to do" paragraph is prose without a FROM → TO shape), so the category's statement-against-statement check holds, and the PR Automation run that carries that gate is green.
• The BREAKING text: states the class (who resolves no set but carries a position, a named set or a user id — the exact complement of the shared predicate), the four refused query positions, the echo refusal, the one moved projection, the unresolved-posture refusal and the remedy. One measured consequence is covered by class but not by door: see ① item 11 and ③.

③ Boundary flags

• open_questions: none declared by the dev; none found.
• Dev deviations, each answered: (a) no WIP push before the first edit — the order's push-only-after-the-fix rule is stricter and the seat accepted it; (b) one wait located a PID by name rather than by the recorded PID — a process-discipline deviation, reported, nothing killed, no effect on the diff; (c) the ablation wrote the whole pre-fix blob and proved landing by blob hash and marker count rather than with the replace tool — accepted by the seat, and the restore was proven byte-identical.
• Surface amendments beside the claim's named regions, same file: the 2.5a gating edit (judged load-bearing in ① item 4) and the byte-for-byte extraction of the principal-less predicate (① item 8). Both declared, both accepted, both right.
• F4, judged here as the seat asked: the changeset's BREAKING text covers the public-picker consequence by mechanism and class but does not name the door or its own remedy. Not a defect of the fix (the 403 is the safe side triage directed) and not a gate failure; it is a changelog-completeness residual for the F4 card the seat committed to file. That card should carry the authoring-side question (whether a picker whose first display field declares a masking rule is a shape authoring should refuse) and the two remedies by class. Escalated to the domain:services seat for filing.
• F1, F2, F3: outside this card's surface, measured, reported by class; the seat committed to file each under the disclosure discipline. F3 is the one that touches this PR's own boundary: the capability fold is deliberately not carried into the stand-in because narrowing getReadableFields for this class would move an answer the spec contract states, so it is a domain:spec decision. Escalated as the seat recorded.
• The spec contract docblock (getMetadataReadableFields in packages/spec/src/contracts/security-service.ts) still says the middleware skips its whole field gate for a caller with no permission sets. After this PR that holds for the grant-based gates and not for masking; the answers it states are unchanged. The dev left the spec file alone per the claim and reported it; escalated to the domain:spec seat.
• Docs Drift Check (advisory): four hand-written pages name SecurityPlugin; the field-level-security page states no zero-set behaviour, so nothing on it is falsified by this diff.
• Triage asked for a re-grade against the measured reach; the seat's ACCEPT carries that request. Not a dev flag; noted for the record.

Implemented-by: claude/issue-20995-zero-set-masking
Reviewed-by: session_01XY5uCwTjZj7884yYtyur4H

VERDICT: PASS

---

Generated by Claude Code