Uh oh!
There was an error while loading. Please reload this page.
fix(rest,lint,spec): prune nav entries whose destination object cannot serve, and refuse them at authoring time (#7912) - #8426
Merged
Conversation
…t serve, and refuse them at authoring time (#7912) A `type: 'object'` nav entry pointing at an object that cannot answer a list was served in the `/meta` payload anyway. Two independent conditions make a destination unservable — `enable.apiEnabled: false` (404) and an `enable.apiMethods` whitelist without `list` (405) — and both are pure functions of the object's own `enable` block, so the destination is dead for every persona. That is why no `requiredPermissions` gate on the entry could ever prune it. Per the maintainer ruling of 2026-08-12 (option (c)): derive the fact, mint no new key. - `filterAppForUser` consults the destination's `enable` for every `type: 'object'` entry, on both `/meta` app routes and inside `children` and `areas[]`. Fail-open on unknown objects and unreadable metadata, so `requiresObject`'s client-only pin and #3770 both stand. - The mandatory companion: `os validate` / `os build` / `os lint` now fail with `nav-object-unservable`, naming the entry, the object, the offending `enable` key path and which condition fired. The serving side logs the same facts. - The two-step gate order is declared once as `apiExposureDenialReason` / `canServeApiOperation` in `@objectstack/spec/data`. The REST data gate, the nav prune and #7909's invariant test all read that one export instead of re-spelling it — the third spelling is what this extraction removes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P7vaLs7bhBPi9m3JyzkhDj
…igin/main (#7912) Both artifacts were merged without a text merge: this branch and #8342 each added exports to `@objectstack/spec/data`, so neither side's baseline covered the union. Regenerated from the merged tree, after rebuilding dist — the gate reads the BUILT dist, and on a stale one it reports phantom removals that the generator would then write. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P7vaLs7bhBPi9m3JyzkhDj
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
📓 Docs Drift CheckThis PR changes 3 package(s): 108 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
⛔ 7 release-owned page(s) also reference the affected code. These are read-only:
|
This was referenced Aug 13, 2026
…js extension (#7912) `check:type-check-debt` went red: @objectstack/rest's TEST_DEBT records 155 raw tsc errors and the re-measure reported 156 (+1). Attributed, not assumed. The package-level `typecheck` is genuinely clean — `packages/rest` is one of the 20 packages whose tsconfig hides its own tests from tsc, so nothing local can see the test layer. Replaying the ledger's own program (the package tsconfig with the test globs dropped from `exclude`) gives 156, of which exactly ONE is in the new file and exactly 155 are not — matching the recorded number, so nothing pre-existing on main drifted: meta-app-nav-servability-gate.test.ts(22,28): error TS2835: Relative import paths need explicit file extensions in ECMAScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './rest-server.js'? The package resolves NodeNext, so the extensionless spelling the older test files use is a TS2835 — 67 of them are frozen in the ledger. The fix is the extension, so a new file does not add the 68th. ⛔ The TEST_DEBT entry was NOT raised, and `scripts/check-type-check-coverage.mjs` was not touched. The ledger is a ratchet: `--re-measure` now reports "none above its recorded number / surplus: none — every entry sits exactly at its measurement". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01P7vaLs7bhBPi9m3JyzkhDj
os-zhuang
marked this pull request as ready for review
August 13, 2026 14:19
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 13, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#7912
A
type: 'object'navigation entry pointing at an object that cannot answer a list was served in the/metapayload anyway. The user saw a menu item that could not work, and the console rendered the failure as a generic empty state — so it read as "you have no records" rather than "this page cannot work".Implements the maintainer ruling of 2026-08-12 (「接受你的全部建议。」) — option (c): derive it, mint no new key, plus its mandatory publish-time companion.
The gap, re-measured on the merged tree
The card's line numbers were stale (
rest-server.tsis 11k lines and moves daily). Anchored on symbols instead:filterAppForUser:2976-3056:2946, delegating tofilterAppForUserWithReasonat:2994— the real implementationapiAccessDenialFromEnable:1665/:1658:1439requiresObjectin nav filteringThe mechanism the card guessed at held:
apiExposureDenialReason's two steps are a pure function ofenable— no user, no permissions, no context — so the prune decision really is persona-independent and sits outside the permission logic entirely.What landed
1. The prune (
packages/rest).filterAppForUsergatestype: 'object'entries on whether the destination can serve alist, on both/metaapp routes, insidechildrenand insideareas[]— through the samefilterNavthe other gates use, so there is no second implementation to drift. The gate is resolved once per request from object metadata, mirroring the ADR-0057 D10serviceGatepattern rather than re-reading metadata per entry.Fail-open in three distinct cases, each deliberate: unreadable metadata resolves no gate at all (a cold start must not empty a healthy sidebar — the #3545 trade); an object absent from metadata is served (no declared policy to enforce, #3770); an object with no
enableblock is served.2. The mandatory companion (
packages/lint). A new reference-integrity rulenav-object-unservablefailsos validate/os build/os lint, naming the entry, the object, which of the two conditions fired and the offendingenablekey path. It gates (error) where its siblingvalidate-nav-accessonly warns, and the asymmetry is principled:enableis declared on the object in the same stack, so a finding is a certainty, not a suspicion. Objects the stack does not declare are skipped — theirenableis not visible from there. The serving side logs the same facts, throttled perapp|entry|object|reason.3. One gate order, three consumers (
packages/spec). The two-step order —apiEnabledfirst and independently, the whitelist second — is nowapiExposureDenialReason/canServeApiOperationin@objectstack/spec/data, beside theresolveEffectiveApiMethods/isApiOperationAllowedprimitives it composes. There were already three spellings of it; the REST data gate, the nav prune and #7909's invariant test now all read the one export. Per the card's ⛔, #7909's test was reused, not copied — its localcanListbecame a call to the shared function.Verification
Ablation (the assertion is not vacuous). Fix committed first, then the derivation removed, then restored from the commit — never against an uncommitted edit:
16 passed (16)8 failed / 8 passedThe 8 reds are exactly the pruning and diagnostic assertions; the 8 that stay green are exactly the fail-open "must NOT prune" cases, which should survive an ablation. Predicted before running, and that is the direction observed.
⭐ The control holds.
nav_api_keys→sys_api_keysurvives, asserted as the whole surviving set so an over-pruning derivation cannot pass by keeping one row alive.sys_jwksstaysapiEnabled: falseand is untouched.Full suites on the merged tree (
origin/mainadvanced twice mid-flight; merged, then artifacts regenerated viascripts/pm/os-regen-merge.sh):@objectstack/dogfood(full, as dispatched)@objectstack/rest@objectstack/spec@objectstack/lint@objectstack/cli@objectstack/platform-objects@objectstack/runtimespec check:generatedexamples/app-showcasebuilds green, which isos buildrunning the new gating rule against a real stack.Deliberately unchanged
requiresObjectkeeps its client-only pin. It asks whether an object is registered; this gate asks whether a registered object'senablelets it answer. Option (a) was rejected and nothing here re-means the key — an entry whose object this layer cannot find is served, not pruned. Pinned by test.visible(CEL) stays client-side only.sys_jwksis out of scope and untouched.The Account-app sibling closes — as already-closed
The ruling said it "closes with this card or not at all". Measured: the sibling is #7555 (same QA run #7514), and it was already closed by merged PR #7605. Its cause was permission composition — an app-declared baseline replacing the platform
member_default— which option (c) neither can nor should touch, since servability is persona-independent by construction. What this card owed it is proof of no regression, and that is asserted: all six Account-app object destinations grantlist, so the derived gate leaves the app exactly as it found it. No edit toaccount.app.tswas required.Serial-file note
#8039's region (the docblock aboveDATA_RECORD_READ_PARAMS) was not touched. My nearest hunk ends whereapiAccessDenialFromEnablecloses, two declarations earlier.Generated by Claude Code