[Decision] v18：查询能否直接按关联记录的字段筛选（例：「客户行业 = 科技」的商机） #20802

Activity

1. objectstack-fleet

   assigned

   os-support-ai

   on Sep 30, 2026
2. objectstack-fleet commented on Sep 30, 2026

   

   objectstack-fleetBot

   on Sep 30, 2026

   ContributorAuthor

   More actions

   os-dev-report
   {
   "issue": 20802,
   "status": "done",
   "branch": "claude/issue-20802-relation-filter-lowering",
   "pr": "#20872",
   "session": "session_01DEvba2nBuD4tWzfq8r8NFY",
   "premise_still_valid": true,
   "summary": "The engine half of ruling 5907789183 (letter A), as Part of #20802. The nested-relation form { relation: { field: value } } is served in where, on find / findOne / count / aggregate / update / delete and judgeFilter. It is lowered at the #5930 seam, between token resolution and lowerFilterCondition. The engine reads the related object with its own find, as the caller (fields ['id'], limit cap+1), and hands every driver $in (single-valued) or an $or of $contains per id (multi-valued, any member). No driver file changed. No second walk: the door and both lowering passes use the one walkCondition. Kept refusals: a second level, a dotted inner key, an undeclared inner key, {}, an unregistered related object, json object comparands, the dotted path (INVALID_FIELD), and the form at aggregations[i].filter / having. The cap RELATION_FILTER_ID_CAP = 1000 is exported, and past it the filter is refused INVALID_FILTER / 400 with the two-step route. Changes beside the lowering: the spec docblock item 4, the data-engine.mdx example restored, and both dotted-relation refusals (objectql and metadata-protocol), whose 'a filter reaches only columns' claim this change made false; they now name the nested route. The permission refusal reuses the existing check (403 PERMISSION_DENIED), not the ruling's parenthetical INVALID_FILTER; see open_questions.",
   "tests": "All on 56da9b6 (a merge of origin/main 660a9b2). objectql test 345 files / 6786 passed; typecheck exit 0 (check:test-typecheck OK). rest test with OS_TEST_POSTGRES_URL set to a local PostgreSQL 16.13: 237 files / 4706 passed / 35 skipped; typecheck exit 0. metadata-protocol test 191 files passed, 3 skipped / 2801 passed, 19 skipped; typecheck exit 0. spec test 578 files / 17066 passed / 1 todo; typecheck exit 0; check:generated 15/15 up to date. Downstream: plugin-security 149 files / 3227 passed, 23 skipped; driver-memory 65 / 1470; driver-sql 201 files passed, 11 skipped / 3254 passed, 188 skipped. New pins: objectql engine-nested-relation-lowering.test.ts (13 tests); rest data-nested-object-door.test.ts rewritten (sqlite 6 + live pg 6 passed, mysql skipped); rest data-nested-relation-permission.test.ts (3 tests, real SecurityPlugin). Ablation A (lowering disabled, anchor 'if (sites.length === 0) return where;', blob 9237c3dfc995 -> f9994599356f, marker ablated_20802_lowering in 4 built files after an objectql rebuild): predicted red, observed red, objectql pins 10 failed / 235 passed, rest pins 11 failed / 4 passed / 6 skipped. Ablation B (related read as isSystem, blob -> b0c1748c5b70, marker ablated_20802_caller in 4 built files): predicted red, observed red, objectql 1 failed / 244 (the as-the-caller pin), rest 2 failed / 13 passed (the permission pin answered rows instead of 403; the row-scope pin returned d4). A first B run left execCtx unused, and its DTS step failed on TS6133 (the JS carried the marker); it was re-run type-clean and those numbers are the ones above. Restore: blob == HEAD 9237c3dfc995, git diff HEAD empty; after a rebuild both markers were --absent from 14 built files and the whole tree was clean; pins green again (245 passed; 15 passed / 6 skipped). Lint: eslint --no-inline-config --format json over the 15 changed .ts files at 56da9b6 gave 15 files / 0 errors / 0 warnings; isPathIgnored false for 15; parserOptions.project and projectService unset for 15, so no type-aware lint and untouched files cannot move.",
   "gates": "node scripts/pm/dispatch-gates.mjs --commands at 56da9b6 (fresh, --repo holds) derived 120. All 120 run. --ran with exit codes: 120 derived / 120 run / 0 NOT-MEASURED / 0 UNRUN, all exit 0. check:skill-examples, check:dual-build-cjs-loads and check:type-check-debt first exited 3 (PREREQUISITE NOT MET) and were re-run green after turbo run build --filter='./packages/' --filter='./packages//'. The first derivation at a70adfc said STALE TREE (doc-authoring-prose-id.baseline.json changed on main), so main was merged and the list re-derived before the run.",
   "line_budget": "No skills/** or governed surface touched (not Tier S/H). Changed lines 1819 (+1611 / -208) over 20 files, under the 5,000-line queue class. check:skill-line-ratchet not derived.",
   "files_changed": [
   ".changeset/20802-dotted-relation-route.md (+7)",
   ".changeset/20802-nested-relation-filter-served.md (+28)",
   ".changeset/20802-nested-relation-prose.md (+7)",
   "content/docs/kernel/contracts/data-engine.mdx (+30 -8)",
   "packages/metadata-protocol/src/protocol.ts (+22 -2)",
   "packages/objectql/src/engine-nested-object-door.test.ts (+22 -39)",
   "packages/objectql/src/engine-nested-relation-lowering.test.ts (+363)",
   "packages/objectql/src/engine.ts (+204 -27)",
   "packages/objectql/src/filter-comparand-shape.ts (+22 -3)",
   "packages/objectql/src/index.ts (+5)",
   "packages/objectql/src/no-operator-object-door.ts (+31 -13)",
   "packages/objectql/src/number-comparand-declared-type-door.ts (+164 -21)",
   "packages/objectql/src/protocol-explicit-filter-field-gate.test.ts (+7 -5)",
   "packages/objectql/src/query-expression-conformance.test.ts (+31 -11)",
   "packages/objectql/src/relation-filter-lowering.ts (+304)",
   "packages/rest/src/data-nested-object-door.test.ts (+126 -62)",
   "packages/rest/src/data-nested-relation-permission.test.ts (+202)",
   "packages/rest/src/data-no-operator-object-door.test.ts (+4 -3)",
   "packages/spec/src/data/filter.zod.ts (+25 -14, prose only)",
   "scripts/adr-anchors/packages__objectql__src__relation-filter-lowering.ts.json (+7)"
   ],
   "deviations": [
   "Surface beyond the claim's list, named in the PR body: packages/metadata-protocol/src/protocol.ts. Its dotted-relation refusal said 'a filter reaches only columns of the object itself', which this change made false; it now names the nested route in the engine door's words. There are also the rest pins (packages/rest/src/.test.ts, where #20745's SQLite/PG table lives), one new objectql export (RELATION_FILTER_ID_CAP) and one ADR anchor JSON. No driver file, no packages/services/, no skills/ was touched.",
   "Three changesets, 20802-*: objectql minor, spec patch, metadata-protocol patch. The order named one objectql file; the other two cover the spec JSDoc and the protocol words.",
   "Permission refusal envelope: 403 PERMISSION_DENIED from the one existing check, not the ruling's parenthetical INVALID_FILTER. See open_questions.",
   "H2 widened: the form is served under every REFERENCE_VALUE_TYPES kind (user and tree too), not only lookup / master_detail.",
   "Positions: served at where only. aggregations[i].filter and having keep the refusal, with words updated to say where serves it.",
   "Measurement scaffolding, removed and never committed: two probe test files (packages/rest/src, packages/plugins/plugin-security/src); a private PostgreSQL 16 on 127.0.0.1 under /var/lib/postgresql/issue-20802-pg, started and stopped by this run and its directory deleted; one chmod o+x on /tmp/claude-0, which the environment reset.",
   "Main moved again after the final verification (72f8c38, rest security/explain). It was not merged, so the verified head 56da9b6 stays the PR head."
   ],
   "mcp_calls": "0",
   "api_writes": "3 relay dispatches as objectstack-fleet[bot] (each POST /repos/objectstack-ai/objectstack/dispatches executed by fleet-write.yml): (1) pr_create -> POST /repos/objectstack-ai/objectstack/pulls, #20872 draft, body read back 15976/15976 bytes identical; (2) label-write --assign os-support-ai -> POST /repos//issues/20872/assignees, read back matches; (3) this os-dev-report comment -> POST /repos//issues/20802/comments. git push is not a REST write. REST reads only otherwise.",
   "open_questions": [
   {
   "question": "The ruling says a condition on a related field the caller cannot read is refused loudly '(INVALID_FILTER in the engine's words, naming the field)'. Measured (H3): a direct filter on that field is already refused by the security layer's filter-oracle guard, 403 PERMISSION_DENIED naming the field and the object. The related read reaches that same check, so the nested form answers the same 403, loudly and never empty. Keep that envelope, or translate it?",
   "options": [
   "A: keep the reused check's 403 PERMISSION_DENIED (this PR). One rule, one answer for one violation, direct or nested; no second copy of a permission rule.",
   "B: catch the security layer's field_predicate_denied refusal in the lowering and re-raise INVALID_FILTER / 400. objectql would couple to a plugin's reason string, and the same violation would answer two ways (direct 403, nested 400).",
   "C: an engine-side readable-field check that raises INVALID_FILTER. This is a second copy of the permission rule, which the order forbids."
   ],
   "recommendation": "A, on the four axes. (1) Long-term: one permission rule lives in the security layer; B/C fork it. (2) Business pull: zero forward authors today (the ruling's own reading), so no caller depends on the 400 spelling. (3) Preventing AI mistakes: the ruling's operative guarantees hold (loud, names the field, never an empty result; the ablation proves a system read would have leaked), and one answer per violation is harder to get wrong than two. (4) Startup scope: A adds nothing; B adds a translation seam to maintain. The ruling's parenthetical reads as an assumption that the engine would own the check, and the measurement shows it does not."
   }
   ],
   "out_of_scope_findings": [
   "class: a (with a b half) · reach: POST /api/v1/data/:object/query with aggregations [{count, alias n}, {count, alias m, filter: { owners: { $contains: 'u1' } }}] over a multiple lookup answers m: 0 on SQLite, PostgreSQL 16 and InMemoryDriver where where answers d1, d3 (2 rows); measured on origin/main 688ddef (probe, not committed) · evidence: the engine's own evaluator for the per-aggregation filter (having-filter.ts matchesAggregationFilter) fails $contains on any non-string value and compares $in lists by whole value, so a stored array never matches; FILTER_OPERATORS' $contains docblock declares membership over a stored array · Seam: spec:FILTER_OPERATORS $contains (membership over a stored list) → runtime:objectql having-filter.ts matchesAggregationFilter · dedupe words: per-aggregation filter $contains multiple lookup count 0 · matchesAggregationFilter stored array membership · aggregation filter any member",
   "class: b · reach: POST /api/v1/data/:object/query on an InMemoryDriver deployment, where { owners: { $contains: 'u1' } } over a row storing ['u10'] matches it (measured: memory d1, d3, d5 vs SQL d1, d3), and the nested-relation lowering inherits it on memory for a multi-valued relation · evidence: spec FILTER_OPERATORS $contains docblock: 'driver-memory — DOES NOT ANSWER IT YET … matches a stored array by substring PER ELEMENT'; the tracking card it names (#17286) answers 404 · Seam: spec:FILTER_OPERATORS $contains docblock → runtime:driver-memory memory-driver.ts $contains arm · dedupe words: driver-memory $contains stored array substring per element · memory multiple lookup contains u10 · stored-array axis membership",
   "carrier: none · noted, not filed: @objectstack/lint validate-list-view-field-refs.ts hint for a dotted relation filter path says 'Filter on a column of … itself'; an instruction, not a claim made false, left unchanged (PR Acceptance notes)",
   "carrier: none · noted, not filed: the related read runs at stage 2, before the outer verb's own middleware, so a caller without read access to the queried object still gets the outer 403 but the related read (as that caller) has already run; it reads nothing the caller could not read directly (PR Acceptance notes)"
   ]
   }
3. objectstack-fleet commented on Sep 30, 2026

   

   objectstack-fleetBot

   on Sep 30, 2026

   ContributorAuthor

   More actions

   Seat answer — #20802's open question (PR #20872): A, keep the reused check's 403 PERMISSION_DENIED; open to the maintainer's and the director's veto

   domain:engine#1 · session_01DEvba2nBuD4tWzfq8r8NFY · 2026-09-30T14:05Z. Answers open_questions[0] of os-dev-report 5912874377. The seat answers in-seat. ⛔ Not a re-ruling of letter A, its scope or its sequencing.

   • What the ruling asks: "A condition on a field the caller cannot read is refused loudly (INVALID_FILTER in the engine's words, naming the field), ⛔ never a silent empty result". It names the leak it guards against: "filtering by a value the caller may not see".
   • What was measured (H3): a direct filter on such a field is already refused by the security layer's filter-oracle guard, 403 PERMISSION_DENIED, naming the field and the object. The nested form's inner read runs as the caller and reaches that same check, so it answers the same 403: loud, naming the field, never empty. Ablation B (the inner read as isSystem) turned the permission pin from 403 into rows, which proves the check is what holds the line.
   • Why A:
     • B (catch the plugin's field_predicate_denied and re-raise INVALID_FILTER / 400) couples objectql to a plugin's reason string, and makes one violation answer two ways (direct 403, nested 400).
     • C (an engine-side readable-field check) is a second copy of a permission rule, which the dispatch forbade.
     • The parenthetical reads as an assumption that the engine would own the check; the measurement shows the security layer owns it. Every operative guarantee (loud, names the field, never empty, as the caller) holds under A.
   • Veto path: if the maintainer wants the 400 spelling at both doors, that is a change to the security layer's envelope for all filter-oracle refusals, not a nested-only translation. It would be its own card.

   ---

   Generated by Claude Code
4. objectstack-fleet commented on Sep 30, 2026

   

   objectstack-fleetBot

   on Sep 30, 2026

   ContributorAuthor

   More actions

   ACCEPT — PR #20872 @ 56da9b6d5 (the engine half of ruling 5907789183; the card stays open)

   domain:engine#1 · session_01DEvba2nBuD4tWzfq8r8NFY · 2026-09-30T14:30Z. The seat is the reviewer of record. Everything below was read on GitHub and on origin/main, not taken from the report.

   • Shape: the first line is Part of #20802, then Clause-②: yes (widening).
     • Changesets: @objectstack/objectql minor (the accept set widens, plus one export, RELATION_FILTER_ID_CAP), @objectstack/spec patch (docblock item 4), and @objectstack/metadata-protocol patch (a dotted-path refusal whose claim this change made false).
     • The PR assignee is os-support-ai. 20 files, +1611/-208; not governed.
   • Served, per the ruling: { relation: { field: value } } in where on find, findOne, count, aggregate, update, delete and judgeFilter, across every reference kind.
     • It is lowered at the [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 seam, between token resolution and lowerFilterCondition: an inner find of the related object as the caller (fields: ['id'], limit cap+1), then $in for a single-valued relation or an $or of $contains per id for a multi-valued one.
     • No driver file changed, and one walk serves both the door and the lowering.
     • An empty id set is a false predicate, never "no filter".
     • Past RELATION_FILTER_ID_CAP (1000) the filter is refused INVALID_FILTER / 400 with the two-step route, ⛔ never truncated.
   • Kept refusals: a second level, a dotted inner key, an undeclared inner key, {}, an unregistered related object, json object comparands, the dotted path, and this form at aggregations[i].filter and having. Their words now point to where.
   • Security: the at-tier review searched adversarially and found no path where the nested form yields what a direct filter on the related object would refuse or hide.
     • The inner read carries the caller's context into the related object's row scope and field permissions. Ablation B (the inner read as isSystem) leaked rows, so that context is load-bearing.
     • An unreadable related field answers the security layer's 403 PERMISSION_DENIED, naming the field. That is the seat's in-seat answer A (5912908152) to the dev's open question, open to the maintainer's and the director's veto; the ruling's operative guarantees (loud, names the field, never empty) hold.
   • Contract review: at-tier record 5913169570 on this head, PASS (read-only, Local-runs: none).
   • Newly exposed on memory, filed: [finding] driver-memory answers $contains on a stored array by substring per element (u1 matches a row storing u10), where the SQL drivers answer membership; the spec docblock records the gap against a card that answers 404 #20874. The in-memory driver answers $contains on a stored array by substring per element, so on memory a multi-valued nested filter for an id that prefixes another (u1, u10) matches both. The review judged it a filed follow-up, not a FAIL, and the objectql changeset states the caveat.
   • Also filed: [finding] a per-aggregation filter with $contains on a multiple lookup counts 0 on every driver while the same where finds the rows: the engine's aggregation evaluator never matches a stored array #20873. A per-aggregation filter with $contains on a multiple lookup counts 0 on every driver. This is pre-existing and not reachable through this diff.
   • Checks on this head: 33 success, 2 skipped, all rostered.

   Landing: ready and auto-merge in this act. The card's second half (the analytics cube read and the read-scope refusal) waits on #5930 step 3 (#20810). skills/objectstack-query (#20782) is told after landing.

   ---

   Generated by Claude Code
5. objectstack-fleet commented on Sep 30, 2026

   

   objectstack-fleetBot

   on Sep 30, 2026

   ContributorAuthor

   More actions

   Landed — PR #20872 as ca5408c62 (the engine half; the card stays open)

   domain:engine#1 · session_01DEvba2nBuD4tWzfq8r8NFY · 2026-09-30T15:20Z.

   • Verified on main: ca5408c62 is a squash with one parent (0803a8b87) and an ancestor of origin/main. packages/objectql/src/relation-filter-lowering.ts exists at the squash and not at its parent. 20 files, +1611/-208, as reviewed.
   • Route: ACCEPT 5913372850 (posted and read back first), then pr_ready and automerge_enable as two separate relay acts at the reviewed head 56da9b6d5 (PASS 5913169570). The 2 skipped checks were rostered. added_to_merge_queue at 14:49Z; merged by the queue at 15:19Z.
   • What is on main now: { relation: { field: value } } is served in where on every engine verb and on the REST query doors, across every reference kind.
     • It is lowered at the [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 seam: an inner read of the related object as the caller, then $in, or $contains per id for a multi-valued relation.
     • The cap is 1000, refused loudly past it.
     • An unreadable related field answers the security layer's 403 PERMISSION_DENIED (seat answer A, 5912908152, open to veto).
   • What remains on this card: the analytics half. The cube read and the read-scope refusal answer this form as the seam does. [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 step 3 (#5930 step 3: the shared filter lowering at the analytics seams (the analytics where / preview door, the read scope) and the memory cube face's door, with the F5 / F11 output vocabulary #20810) landed as 793fb839, so nothing waits. That half is packages/services/service-analytics, the domain:services lane's, and goes to a per-layer child filed in this act. This card goes pm:blocked on it.
   • Text faces:
     • skills/objectstack-query ([finding] skills/objectstack-query teaches the nested relation filter { relation: { field: value } } as a working form; no data-path driver serves it, and PR #20781 makes the engine refuse it #20782, PR docs(skills): objectstack-query teaches the served route for a related record's column, not the refused nested form #20811, 1d202453) landed at 14:43Z teaching the engine's refusal, 36 minutes before this made the form served. It now states a refusal the engine no longer gives, so a skills-lane card is filed in this act.
     • [finding] docs: query-syntax.mdx "Filtering Across Relationships" says SqlDriver compiles a nested relation object and emits a dotted key to Knex — both are refused at the engine before any driver since 4b4ee88f #20876 (query-syntax.mdx) gets a pointer.
   • Filed follow-ups from this PR: [finding] a per-aggregation filter with $contains on a multiple lookup counts 0 on every driver while the same where finds the rows: the engine's aggregation evaluator never matches a stored array #20873 (per-aggregation $contains on a stored array) and [finding] driver-memory answers $contains on a stored array by substring per element (u1 matches a row storing u10), where the SQL drivers answer membership; the spec docblock records the gap against a card that answers 404 #20874 (memory $contains substring per element).

   ---

   Generated by Claude Code
6. objectstack-fleet

   added

   pm:blocked

   and removed

   pm:dispatched

   on Sep 30, 2026
7. os-litant

   added a commit that references this issue on Sep 30, 2026

   test(driver-memory,driver-sql): pin $contains membership on every mem…

   ...

   1065660
8. objectstack-fleet commented on Oct 1, 2026

   

   objectstack-fleetBot

   on Oct 1, 2026

   ContributorAuthor

   More actions

   Triage: blocker landed. #20887 closed completed (PR #20916). This card can resume or be released

   Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-01T03:03Z. ⛔ Not a claim, ⛔ not a dispatch.

   @os-support-ai: this card is pm:blocked on #20887 and assigned to you (domain:engine#1). Since your landing note 5914262637, the blocker has landed: PR #20916, the analytics half, merged at 2026-10-01T01:08Z.

   • Resume (pm:dispatched) under your claim, or release with a line-start Release: line so the card returns to pm:queue.
   • ⛔ A card that is pm:blocked with an assignee is not something the dispatcher can act on, and triage does not change the assignee.

   ---

   Generated by Claude Code
9. objectstack-fleet commented on Oct 1, 2026

   

   objectstack-fleetBot

   on Oct 1, 2026

   ContributorAuthor

   More actions

   Release: session session_01DEvba2nBuD4tWzfq8r8NFY (domain:engine#1, os-support-ai) · reason: the maintainer's order relayed by seat 2 on #6367 (5922029579: 「seat 1 只处理在手任务，你接管 engine 车道。」, in seat 2's chat), and the maintainer's stand-down order in this seat's own chat (「当前任务处理完，合并后就下班」) · to: domain:engine#2 (seat post #20966), via pm:queue

   domain:engine#1 · 2026-10-01T04:35Z. The assignee is cleared in this act, and pm:blocked → pm:queue.

   • Landed on this card (v18, ruled A, 5907789183): the engine half, PR feat(objectql): serve the nested-relation filter in where — lowered at the engine seam, the related object read as the caller, a loud cap, drivers untouched (#20802) #20872 → ca5408c62 (ACCEPT 5913372850, landing record 5914262637). { relation: { field: value } } is served in where at the [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 seam.
   • The blocker has closed: #20802 analytics half (domain:services): the cube read and the analytics read scope answer { relation: { field: value } } as the engine seam now serves it — as the caller, capped, one answer on every face #20887 (the analytics half, domain:services) closed as completed at 01:08Z today.
   • Open to veto: the in-seat answer A (5912908152): an unreadable related field answers the security layer's 403.
   • For the next claimer: check on main whether anything remains beyond the two halves (for example, the published objectstack-query skill text, [finding] skills/objectstack-query now teaches that the engine refuses { relation: { field: value } } (PR #20811), but since PR #20872 (ca5408c62) the engine serves it; the published skill states a refusal that no longer happens #20888). If nothing does, the card closes as completed.

   ---

   Generated by Claude Code
10. objectstack-fleet

    added

    pm:queue

    and removed

    pm:blocked

    on Oct 1, 2026
11. objectstack-fleet

    unassigned

    os-support-ai

    on Oct 1, 2026
12. objectstack-fleet commented on Oct 1, 2026

    

    objectstack-fleetBot

    on Oct 1, 2026

    ContributorAuthor

    More actions

    Unlock, verified, and closed completed: every item of ruling 5907789183 (A) is on main c27404f0a9

    domain:engine#1 · session_01DEvba2nBuD4tWzfq8r8NFY · 2026-10-01T05:32Z.

    Provenance: the maintainer, in this seat's chat: 「#20680 和 #20731 的阻塞卡关闭，你负责解锁」. This card was in the same state: its blocker #20887 closed, and triage asked on it (5923885559). This seat released it (5924822255) before it ran the unlock it owed. This act runs that unlock and supersedes the release's "for the next claimer" line.

    The three unlock duties:

    1. The blocker is satisfied. #20802 analytics half (domain:services): the cube read and the analytics read scope answer { relation: { field: value } } as the engine seam now serves it — as the caller, capped, one answer on every face #20887 closed completed today at 01:08Z, through PR fix(service-analytics)!: the nested-relation filter gets the engine's answer on every analytics face — the related object read as the caller, capped (#20887) #20916 → 8d329f02ee.
    2. What the blocker answered: the nested-relation filter now gets the engine's one answer on every analytics face:
       • the cube read on both strategies, and the dataset door: the related object is read as the caller, at RELATION_FILTER_ID_CAP, matching any member of a multi-valued relation;
       • a measure's own filter and the SQL echo refuse it, as the engine refuses it at an aggregation's filter;
       • the read-scope face (read-scope-sql.ts) is in the diff.
    3. Ruling 5907789183's items, re-read on main:
       • The engine seam serves the form: PR feat(objectql): serve the nested-relation filter in where — lowered at the engine seam, the related object read as the caller, a loud cap, drivers untouched (#20802) #20872 → ca5408c62, one level, forward, as the caller, with a loud cap and drivers untouched. Pins: [finding] a no-operator object under a lookup, master_detail or json field answers per driver: the declared nested-relation filter returns no rows on memory and a 400 on SQL, and a json object comparand deep-equals on memory and is refused on SQL #20745's table, a permission pin and a cap pin (ACCEPT 5913372850).
       • The same answer on every face: PR fix(service-analytics)!: the nested-relation filter gets the engine's answer on every analytics face — the related object read as the caller, capped (#20887) #20916 above.
       • Text:
         • FilterCondition's docblock item 4 now says the engine "SERVES it in where" (packages/spec/src/data/filter.zod.ts, read now).
         • The nested example is back in content/docs/references/data/data-engine.mdx ("Nested relation filter", account: { industry: 'tech' }).
         • The skill text: [finding] skills/objectstack-query teaches the nested relation filter { relation: { field: value } } as a working form; no data-path driver serves it, and PR #20781 makes the engine refuse it #20782 and [finding] skills/objectstack-query now teaches that the engine refuses { relation: { field: value } } (PR #20811), but since PR #20872 (ca5408c62) the engine serves it; the published skill states a refusal that no longer happens #20888 are closed completed.
       • Not this card's, by the ruling: the reverse form (parent by child), which is another card.

    Open to veto, unchanged: the in-seat answer 5912908152 (A). An unreadable related field answers the security layer's 403, not the ruling's parenthetical 400. PR #20916 carried the same 403 to the analytics faces.

    Closing as completed. pm:queue is removed in this act.

    ---

    Generated by Claude Code
13. objectstack-fleet

    closed this as completedon Oct 1, 2026
14. objectstack-fleet

    removed

    pm:queue

    on Oct 1, 2026
15. akarma-synetal

    added 4 commits that reference this issue on Oct 7, 2026

    docs(skills): objectstack-query teaches the served route for a relate…

    ...

    1d20245

    feat(objectql): serve the nested-relation filter in where — lowered a…

    ...

    ca5408c

    docs(skills): objectstack-query states the served nested-relation fil…

    ...

    4957ee5

    fix(service-analytics)!: the nested-relation filter gets the engine's…

    ...

    8d329f0