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

Ruled: 5907789183 · letter A — v18 serves { relation: { field: value } } at the #5930 seam (one level, forward, as the caller, a loud cap); this card carries the work · 2026-09-30T08:59Z
Unblocked: #5930 step 2 (the engine seam) landed as cfa931535 on 2026-09-30T08:00Z; released to pm:queue by domain:engine#1, record 5907891818.
Blocked-by: #20887

Filed by the triage seat (objectstack-wide, seat post #6015, session_01AavokzJ5DndAwitDXvKy4U) at the maintainer's request 「开一张 v18 的决策卡」. ⛔ Not a claim, ⛔ not a dispatch, ⛔ never dispatched while needs-user-decision is on. Graded: enhancement · priority:p3 · domain:engine · area:api · target:v18.

一句话问题

作者想查「客户行业是科技的商机」，最自然的写法是把条件写在关联字段下面。平台的类型接受这个写法，但数据查询会报 400；而同样的写法放到分析看板里却能查出结果。v18 要真的支持它，还是把这个写法从协议里去掉？

背景

[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 实测：{ account: { industry: 'tech' } } 这类「关联字段下挂无运算符对象」的写法，内存驱动静默返回 0 行，SQL 驱动返回 400。
PR fix(objectql)!: a no-operator object beneath a relation, structured-JSON or undeclared id column is refused INVALID_FILTER / 400 on every driver (#20745) #20781（4b4ee88fb）先把今天的答案统一成响亮拒绝：所有驱动都返回 INVALID_FILTER / 400，报错里指明可行的路（先查关联对象，再对关联字段用 $in 匹配它返回的 id）。文档里教这个写法的示例也删了。
当时 triage 把「要不要真正支持」留给维护者（[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 的定级 5902573237；[finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 上的指针 5902585544）。[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 已关，这个问题没有自然的挂靠处，所以单开此卡。

Governing text

spec 声明：packages/spec/src/data/filter.zod.ts 的 FilterCondition docblock，第 4 种形态「Nested relations: { relation: { field: value } }」。它写明类型和 schema 接受、查询引擎拒绝。
re-check：git grep -n "4. Nested relations" origin/main -- packages/spec/src/data/filter.zod.ts → 1
裁决基准（pm-dispatch 技能的「基本裁决原则」）：spec 声明 > 实现 > 文档面；声明了却不兑现是实现缺口，只能补实现或退役。所以「一直维持现状」不是选项，只是等裁决期间的过渡状态。
seam 架构（ADR-0053 修订第 5 条，即 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 裁决的 D4 (b)）：驱动收到的是已经在 seam 下译好的过滤条件，驱动本身不改。

协议声明、是否改协议

A 改的是 docblock 的描述：从「引擎拒绝」改成「引擎服务」。类型不收窄，属于扩大，Clause-②: no。
B 要收窄 FilterCondition：Clause-②: yes，是 BREAKING 的 minor，存量过滤条件需要一条 ADR-0087 处置。

前提（每条带 re-check，均已在 `origin/main` `96e724475c` 跑过）

CRUD 数据口今天拒绝这个写法，点号路径（'owner.region'）也在更早一道门被 [finding] The FILTER axis has no DOTTED-path verdict — where: { project_id.name: 'x' } rides its head segment past both doors, where SORT refuses the same spelling (#4256) #8371 拒掉。
git grep -n "the #8371 dotted verdict" origin/main -- packages/objectql/src/no-operator-object-door.ts → 1
分析看板那一面今天是支持的：cube 过滤把它拍平成点号成员（profile.verified），靠 cube 声明的 join 解析。
git grep -n "Nested relation (e.g." origin/main -- packages/services/service-analytics/src/strategies/filter-normalizer.ts → 1
分析的读权限范围那一面拒绝它。
git grep -n 'non-$ key means a nested relation' origin/main -- packages/services/service-analytics/src/read-scope-sql.ts → 1
引擎里已有同形的机制：expand 批量加载关联记录，用的就是对关联 id 的 $in 查询。
git grep -n 'Batch-load related records using $in' origin/main -- packages/objectql/src/engine.ts → 1
业务拉动（实测）：hotcrm 有 4 个 hook 手写同一段两步查询：先查成员行拿到线索 id，再对线索用 id: { $in: leadIds }，而且第一步手挑了 top: 5000，超过 5000 条会静默截断。
cd hotcrm && git grep -n 'id: { $in: leadIds }' origin/main -- src → 4
这 4 处是反向（父找子），不是本卡的正向写法。hotcrm 的 271 行 filter / where 中，按正则扫描，正向嵌套写法为 0。
objectui 按关键字检索（nested relation|relatedField|related field|cross-object filter）为 0 命中；这是关键字检索，⛔ 不是 UI 走查。

具体问题

v18 的平台契约里，「按关联记录的字段筛选」要么是服务的能力（A），要么不存在（B）。不裁时，今天的响亮拒绝继续有效，不影响 17.x 发版。

选项 × 真实代价

选项	做什么	客户可感知的后果
A 支持（v18，排在 #5930 收敛的 seam 之后）	引擎在一个 seam 上把 `{ 关联: { 字段: 值 } }` 下译成「以调用者身份查关联对象 → 对关联字段 `$in` 这些 id」，驱动不改（D4 (b)）。首版只做一层、只做正向（子 → 父）。多值关联按「任一匹配」处理。	列表视图、API、AI 写的查询都能直接写「客户行业 = 科技」。CRUD 与看板对同一写法给同一个答案。多一次内部查询；关联集合很大时按上限响亮拒绝，⛔ 不截断。
B 退役（v18 收窄类型）	`FilterCondition` 不再接受这个写法，在发布、保存时就报错，只剩「两步 + `$in`」一条路。分析看板的嵌套写法同时退役，点号成员写法保留。	作者和 AI 在保存时就被拦下，不用等到运行时。但这个能力要靠手写两步查询，像 hotcrm 那 4 个 hook 一样，会重复写、会截断。

业务含义直译

A = 像 Salesforce 那样，列表筛选可以直接写「客户.行业 = 科技」。平台替你做两步查询，并且按你的权限做。
B = 平台明说「不能跨对象筛选」，想做就在代码里自己先查一遍。像早期只支持单表筛选的轻量表格工具。

四轴论证（从业务立场）

项目长远合理性：两年后，一个元数据 CRM 平台应当能在列表和查询里按父记录字段筛选。主流做法都是服务它：Salesforce SOQL 的父关系字段 WHERE（Account.Industry）、Dataverse FetchXML 的 link-entity 过滤、ServiceNow 的 dot-walking。A 把它落在一个 seam 上，和 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 的收敛方向（一处下译，驱动不改）一致，并让 CRUD 与看板对齐。B 让契约更小，但这个能力大概率会以新拼写回来，届时要再迁一次。
实际业务拉动：正向写法今天零作者（hotcrm 为 0，objectui 关键字检索为 0）。相邻的需求是实测存在的：hotcrm 4 处手写两步查询，而且带静默截断。这说明「跨对象筛选」被需要，但需要的是反向，A 的首版不覆盖。
防 AI 犯错：AI 最自然写出的正是这个嵌套写法。
- A：写出来就对，而且以调用者权限执行。出错面在权限：若内部查询不套关联对象的读权限，就成了静默泄露（能按看不见的字段值筛出记录），所以这条是 A 的硬约束。
- B：保存时响亮拒绝，结构上最难写错，但 AI 会转去手写两步查询，把截断之类的错误带进应用代码。
创业阶段不扩散：B 最省，删一个声明面，不留永久义务。A 新增一个要长期维护的能力，含权限、上限、多值语义。A 的成本被 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 的 seam 摊薄，但仍是新义务。

os-decision-facets

① 项目长远合理性：A 与主流平台和 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 的单点下译一致，并消除 CRUD 与看板的分叉；B 缩小契约，但能力大概率日后以新拼写回归。
② 实际业务拉动：正向写法实测零作者；hotcrm 有 4 处反向两步查询（带静默截断），A 首版不覆盖。
③ 防 AI 犯错：B 在保存时响亮拒绝，结构最硬；A 让自然写法直接可用，但必须以调用者读权限执行，否则是静默泄露。
④ 创业阶段不扩散：B 删除声明面，零后续义务；A 新增权限、上限、多值三项长期义务。

Prior rulings read: nested relation / relation filter in docs/adr → 0 hits (only content/docs/references/api/contract.mdx maxQueryDepth); ADR-0053 amendment item 5 (D4 (b)); thread: #20745 grade 5902573237, #5930 ruling 5902355785, #20546 grade 5882227960 (which kept this form as an unjudged control).

裁后执行（维护者只裁方向）

A → triage 开一张 domain:engine · target:v18 卡，Blocked-by: [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 落地 seam 的那一步。卡上写明：
- 下译位置在引擎 seam，驱动不改；
- 内部查询以调用者身份执行，套用关联对象的行权限和字段权限；对调用者不可读字段的条件响亮拒绝，⛔ 不静默返回空；
- id 集合设上限，超限响亮拒绝，⛔ 不截断；
- 多值关联按「任一匹配」；
- docblock 第 4 条改为「服务」，恢复 data-engine.mdx 示例，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）同步；
- 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 的表在 memory / SQLite / PostgreSQL 上翻成返回 d1、d3，外加一条权限 pin 和一条上限 pin。
- 反向（父找子，hotcrm 那 4 处）另议，⛔ 不并入首版。
B → triage 开一张 domain:spec 卡：收窄 FilterCondition，Clause-②: yes，BREAKING minor；存量过滤条件按 ADR-0087 处置，带指引拒绝；分析看板的嵌套写法同时退役，点号成员写法保留；[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 的 skill 文案改成「这是唯一的路」。
不裁 → 维持 PR fix(objectql)!: a no-operator object beneath a relation, structured-JSON or undeclared id column is refused INVALID_FILTER / 400 on every driver (#20745) #20781 的响亮拒绝，不影响发版。

Released to `pm:queue`: #5930 step 2, this card's `Blocked-by:`, has landed

domain:engine#1 · session_01DEvba2nBuD4tWzfq8r8NFY · 2026-09-30T09:04Z. This seat landed that step, and ruling 5907789183 gives the move to "the seat that lands that step". ⛔ Not a claim.

Verified on main: PR feat(spec,objectql,plugin-security): one shared filter lowering, run once at the engine and RLS seams (#5930 step 2) #20794 merged as cfa931535 at 08:00Z. It is an ancestor of origin/main. packages/spec/src/data/filter-lowering.ts exports lowerFilterCondition in the @objectstack/spec/data subpath, and packages/objectql/src/engine.ts calls it at the engine filter positions. So the seam this card lowers at exists. [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 itself stays open for steps 3 and 4, which is why the unlock scan would not fire here.
Re-derived before release:
- No new blocker for the CRUD half: engine.find and POST /api/v1/data/:object/query go through the engine seam.
- The ruling's "same answer on every face" also names the analytics cube and the analytics read-scope refusal. The analytics where door and the read scope get the shared lowering in [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, filed bare, not yet triaged), not in step 2.
- The seat that claims this card orders that half: land the engine half first as Part of #20802, or wait for #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. ⛔ This does not re-rule the letter or the sequencing.
This act: pm:blocked → pm:queue. The body's Blocked-by: line is replaced by one Unblocked: line with this record, so the card does not sit in the queue behind a canonical line naming an open umbrella.

Generated by Claude Code

Claim: PM loop round 24
Session: session_01DEvba2nBuD4tWzfq8r8NFY
Account: os-support-ai (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-20802-relation-filter-lowering
Worktree: objectstack-issue-20802
Domain: domain:engine
Seat: domain:engine#1
File surface (ruling 5907789183, letter A; this claim takes the engine half, Part of #20802):

packages/objectql/src/**: lower { relation: { field: value } } at the engine filter seam that [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 step 2 built (cfa931535). The lowering reads the related object as the caller, then puts $in on the relation field.
- One level, forward only.
- A multi-valued relation matches on any member.
- A named cap on the id set, with a loud refusal over it that names the two-step route.
- A condition on a related field the caller cannot read is refused loudly, ⛔ never emptied.
- no-operator-object-door.ts admits the form on a relation field. The json-field and dotted-path verdicts stay.
Cross-lane surface, declared here: packages/spec/src/data/filter.zod.ts, FilterCondition's docblock item 4 ("the query engine REFUSES it" → the served semantics). Docblock only; the type does not move.
content/docs/kernel/contracts/data-engine.mdx: the example PR fix(objectql)!: a no-operator object beneath a relation, structured-JSON or undeclared id column is refused INVALID_FILTER / 400 on every driver (#20745) #20781 removed comes back.
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 on memory, SQLite and PostgreSQL (where the matrix runs it) turns into rows d1, d3, plus one permission pin and one cap pin;
.changeset/20802-*.md.

Stop on breach and explain in the report.

⛔ No driver file (D4 (b)).
⛔ Not the reverse form (parent by child).
⛔ Not 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, governed; told after landing).
⛔ Not the analytics faces: the cube read and the read-scope refusal get their seam in [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). They are this card's second half, after #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.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate, floor sonnet · default opus · ceiling fable; a contract-review-tier review is owed)
Clause-②: yes (widening)
Thread-read: 5907891818
Serial constraints cleared: read at 2026-09-30T11:51Z against origin/main (30839063b).
Clause-②: yes (widening): the engine's accept set widens from refused (PR fix(objectql)!: a no-operator object beneath a relation, structured-JSON or undeclared id column is refused INVALID_FILTER / 400 on every driver (#20745) #20781's INVALID_FILTER / 400) to served.
- The ruling's execution parameter reads Clause-②: no because "the type does not move". But scripts/pm/clause2-line.mjs asks whether the card widens an accept set or the public surface, and the ruling's own words say "the accepted set widens from schema-only to served".
- The seat carries the line the grammar requires; the letter, scope and sequencing are unchanged. Open to the director's veto.
PR fix(objectql): refusals, log lines and metadata text state each decision in words instead of a tracker number (stage 3) #20848 ([finding] runtime warnings outside the migration ledger print tracker numbers to authors and operators: the AutomationEngine resumeAuthority boot warning (#3801 / #5561 / #3823) and two objectql data-event warnings (#4639 / #4626) #20513 stage 3) rewrites string lines in engine.ts, none on the filter seam. Whichever lands second merges main. #5930 step 4 (domain:engine): the engine-fed faces delete their hand-copied filter meaning (driver-sql, turso remote, memory query, mongodb, formula, having); the memory reference matcher retires (D6) #20822 ([finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930 step 4, bare) will later delete face copies at the same seam.

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

@os-support-ai

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

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

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:

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.
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.
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

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

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

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

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

Navigation Menu

Repository navigation

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

一句话问题

背景

Governing text

协议声明、是否改协议

前提（每条带 re-check，均已在 `origin/main` `96e724475c` 跑过）

具体问题

选项 × 真实代价

业务含义直译

四轴论证（从业务立场）

推荐

裁后执行（维护者只裁方向）

相关单与 PR

Released to `pm:queue`: #5930 step 2, this card's `Blocked-by:`, has landed

5 remaining items

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

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

一句话问题

背景

Governing text

协议声明、是否改协议

前提（每条带 re-check，均已在 origin/main 96e724475c 跑过）

具体问题

选项 × 真实代价

业务含义直译

四轴论证（从业务立场）

推荐

裁后执行（维护者只裁方向）

相关单与 PR

Activity

objectstack-fleet commented on Sep 30, 2026

objectstack-fleet commented on Sep 30, 2026

Released to pm:queue: #5930 step 2, this card's Blocked-by:, has landed

objectstack-fleet commented on Sep 30, 2026

5 remaining items

objectstack-fleet commented on Oct 1, 2026

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

objectstack-fleet commented on Oct 1, 2026

objectstack-fleet commented on Oct 1, 2026

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

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

前提（每条带 re-check，均已在 `origin/main` `96e724475c` 跑过）

Released to `pm:queue`: #5930 step 2, this card's `Blocked-by:`, has landed

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

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