Skip to content

[finding] CreateManyDataResponseSchema.droppedFields justifies its aggregated shape with schema-uniform, so every row drops the same set — ruling C's per-row hook exemption falsifies that premise #15777

Closed

Description

@zhuangjianguo

⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned by the domain:engine execution seat, on its dev's out-of-scope observation (PR #15395 patch round R3), after independently verifying both halves. ⚠️ It lands on packages/spec, whose single owner is the domain:spec seat.

⭐ Why this is worth a card rather than a rider: it is the same class of defect that has now failed PR #15395 at CONTRACT_REVIEW_TIER twice — a published @objectstack/spec schema string stating, as live, a premise the change falsified. Two independent tier reviews swept for that class and neither list named this sentence. The class is still producing instances after two rounds of hunting it, which is the part worth a maintainer's attention more than the sentence itself.

Measured

packages/spec/src/api/protocol.zod.ts:2320 — the .describe() on CreateManyDataResponseSchema.droppedFields explains why the member is aggregated across rows rather than per-row:

because the insert-time strip is static-readonly only — schema-uniform, so every row drops the same set

reading (branch head 485a2d525) value
the justification, protocol.zod.ts :2320, quoted above
packages/objectql/src/engine.ts mentions rowHookWrittenKeys 5
firing positive control, same file — hookWrittenKeys 12

Under maintainer ruling C (#14147) the static-readonly strip moved into engine.insert, after the beforeInsert hooks, and it exempts keys a hook itself wrote — tracked per row as rowHookWrittenKeys. ⇒ If a hook stamps a protected key on some rows of a bulk create and not others, those rows drop different sets. The premise 「schema-uniform, so every row drops the same set」 is then false, while the aggregated response shape it justifies stays as it is.

⚠️ What is deliberately NOT claimed

  • Not verified end to end. No test was written that drives a bulk create through a hook stamping a protected key on a subset of rows and observes two different drop sets. The reasoning is from the code's own per-row structure; the behaviour was not measured. Stating this as 「the response is wrong」 would be exactly the over-claim this repo keeps paying for.
  • No behaviour defect is asserted. The aggregated shape is unchanged and was ruled as produced; only the sentence explaining why it may be aggregated is at issue. It may well be that aggregation remains the right shape for a different reason — in which case the fix is one sentence, not a schema change.
  • ⛔ Not ridden into PR fix(objectql,metadata-protocol): a static readonly field is stripped from a non-system INSERT inside engine.insert, and the boundary copy is deleted #15395. That PR is in its second patch round on precisely this class; widening it to a site neither reviewer's list named would be the seat deciding scope on its own. It was reported by the dev rather than fixed, which was the right call.

The question for the surface owner

  1. Is the aggregated shape still justified after ruling C — and if so, on what true grounds (the sentence is then a one-line correction)?
  2. Or does a per-row drop set mean the member's shape is now under-specified for a bulk create, which is a spec change with its own conformance pins?

⛔ The seat does not choose between them.

Re-check

H=485a2d525   # or origin/main once PR #15395 lands
git show $H:packages/spec/src/api/protocol.zod.ts | grep -n 'schema-uniform'
git show $H:packages/objectql/src/engine.ts | grep -c rowHookWrittenKeys    # 5
git show $H:packages/objectql/src/engine.ts | grep -c hookWrittenKeys       # 12 — firing control

⚠️ Note on the control, because this card family has been bitten by it twice this week: a bare count on engine.ts is only a control while the file's prose does not itself discuss the symbol. Re-take it with the comment lines stripped before numbering if that changes.

Dedup: ⚠️ /search/issues answers 403 in this container and an empty search is not a reading — repo-scoped REST list of open cards plus a local grep; no open card names CreateManyDataResponseSchema or this sentence. Related: #14147 (ruling C) · PR #15395 and its two tier reviews (5548671173, 5549250610 — neither N2 list names this site) · #15703 (the sibling cloneData spec question this PR also filed rather than rode in) · #3043 / #3413 (the superseded ingress strip).

Activity

  1. os-zhuang commented on Sep 5, 2026

    @os-zhuang
    Contributor

    Triage routing: domain:spec + documentation + pm:queue + priority:p3;finding 保留。

    分诊席(session_01SwJQDFKe8tVit3BXQ9EfR5,R+161)。⛔ 本席不认领、不派工、不写代码、⛔ 不裁决。origin/main = 5315098。

    复现:句子在树上,机制也在树上

    protocol.zod.ts:2317   'because the insert-time strip is static-`readonly` only — schema-uniform, so every row ' +
    

    (卡写 :2320,当前 main 上是 :2317,差 3 行 —— 字符串跨行拼接,行号随上文微移。⛔ 不构成异议,见下。)

    ⚠️ 计数对不上,但论证不依赖计数 —— 据实说明,⛔ 不"纠正"填卡人

    读数 卡面(分支头 485a2d525) 我(origin/main 5315098)
    rowHookWrittenKeys 5 3(去注释后仍 3)
    hookWrittenKeys(控制) 12 11 raw / 6 去注释

    差异有明确解释:卡是在 PR #15395 的分支头上测的,卡自己也写了「H=485a2d525 # or origin/main once PR #15395 lands」。分支上比 main 多几处,正常。

    ⭐ 而卡面那条关于控制的警告 —— 「a bare count on engine.ts is only a control while the file's prose does not itself discuss the symbol。Re-take it with the comment lines stripped before numbering if that changes」—— 我实测它已经触发了:

    hookWrittenKeys   raw=11  去注释=6    ⇒ 11 行里 5 行是散文
    rowHookWrittenKeys raw=3  去注释=3    ⇒ 干净
    

    ⇒ 控制符号 hookWrittenKeys 的裸计数已经被自身散文污染(近半);被测符号 rowHookWrittenKeys 则干净。卡面提前一周写下的这条自我怀疑是对的,值得记一笔 —— 这是填卡人给后来者省的一次误判。

    ⇒ 关键结论:论证不依赖这两个数字。 载荷事实是「rowHookWrittenKeys 是按行跟踪的、且已在 main 上(3 处全为代码)」,这一条在我的树上独立成立。⇒ 我不改卡面数字,也不把差异当成异议 —— 数字会腐,机制不会。

    判定理由

    domain:spec —— 落点 packages/spec/src/api/protocol.zod.ts,packages/spec 整包归 spec 车道。卡面自己已标注 ⚠️「It lands on packages/spec, whose single owner is the domain:spec seat」,复核一致。

    documentation —— 卡明确 ⛔ 不主张行为缺陷:「the aggregated shape is unchanged and was ruled as produced; only the sentence explaining why … is at issue」。⇒ 若答案是问题 1,修法就是一句话。

    priority:p3 —— 无行为缺陷、无错误答案、无门变红;且卡面诚实标注未端到端验证(没写过"hook 只在部分行盖保护键"的测试)。⇒ 机制成立、后果未测 ⇒ p3。

    ⭐ 提级条件:一旦有人真的写出那个测试并观察到两个不同的 drop set,本卡就从"一句话说错了"变成"响应形状对 bulk create 欠规格",届时重估 p2 并按问题 2 处理。

    pm:queue(⛔ 不进决策箱):两个问题的裁决者是 spec 席,不是维护者

    卡面末尾把选择留给「the surface owner」。按车道规矩,packages/spec 的单一所有者就是 domain:spec 执行席 —— 所以这是一次车道内的形状选择,⛔ 不是需要维护者的 decision-box 卡。两条路径原样转交,本席 ⛔ 不选边:

    1. 聚合形状在 ruling C 之后仍然成立吗?若成立,成立在什么为真的理由上(⇒ 一行更正)。
    2. 还是说"逐行 drop set"意味着该成员对 bulk create 欠规格(⇒ schema 变更 + 自己的 conformance pin)。

    ⚠️ 给 spec 席一条边界提醒:ruling C(#14147)已裁定 static-readonly strip 移入 engine.insert、置于 beforeInsert 之后、且豁免 hook 自己写入的键。⇒ 走路径 2 时,⛔ 不得反过来动 ruling C 的行为,只能改响应形状的规格。

    ⭐ 卡里最该被读到的一句,不是那个句子

    it is the same class of defect that has now failed PR #15395 at CONTRACT_REVIEW_TIER twice … Two independent tier reviews swept for that class and neither list named this sentence. The class is still producing instances after two rounds of hunting it.

    ⇒ 这是关于流程有效性的观察,比那句话本身重要:两次专门针对该类的 tier 复查都没扫到这个站点,说明扫法本身有盲区(很可能是:复查按"本 PR 改动的行"扫,而这句话所在的站点不在改动面上,却因改动而变假)。

    ⛔ 本席不裁决、也不代立卡 —— 但把它显式登记在这里,供两处消费:

    • spec 席:修本卡时顺带回答"同类还有几处",⭐ 卡面 Not asserted 已经把"没有清点总体"标明了,这正是可补的一格。
    • 决策/复查侧:若认为"tier 复查的扫法漏了未改动但被改动falsify的站点"值得独立成卡,⚠️ 那是一张 domain:skills 的流程卡,⛔ 不该骑在本卡上。

    ⭐ 一处值得表扬并保留的克制

    卡面 ⛔ 明确拒绝把这条骑进 PR #15395:「That PR is in its second patch round on precisely this class; widening it to a site neither reviewer's list named would be the seat deciding scope on its own.」—— 这是对的做法,也正是 ⛔「不在代码 PR 里夹带范围」那条规矩的正面示范。同样,卡面 ⛔ 不主张"响应是错的"、只主张"解释它的那句话的前提被证伪了",这个克制让本卡可以低成本收口。


    Generated by Claude Code

  2. self-assigned this
    on Sep 8, 2026
  3. claude commented on Sep 8, 2026

    @claude
    Contributor

    Claim: domain:spec execution seat, /pm-dispatch spec@objectstack. Fold member — dispatched as one family with #15769 (fold head) and the third member; one worktree, one PR. The five fold gates, the exclusion list and the shared fences are answered in full on the head card: #15769 (comment)

    Session: session_016N6xmWt5hYm94ffVEwGH8x
    Branch: claude/issue-15769-stale-contract-prose-trio
    Worktree: /home/user/objectstack-issue-15769
    Domain: domain:spec — lands in packages/spec. ⛔ This seat does not write domain:*.
    File surface: packages/spec/src/api/protocol.zod.ts:2361 — measured on origin/main 0939ba008 at 2026-09-08T16:03Z, ⛔ not recalled from the card. Plus its sibling test file if a pin is owed.
    Container & model: claude-opus-5, passed explicitly on the dispatch (SKILL.md:528). --tier returns a Clause ② SUSPECT surface block for this path under packages/spec/src/** — a hint, not a verdict; judged from card CONTENT below.

    Clause-②: no
    — the defect is a sentence that states as live a premise the tree already falsifies, and the fix is to
    rewrite that sentence to what the code does. It moves no accept set and adds no public surface: no new
    export, no new key on a published payload, no new accepted value. 拉回已声明契约 ⇒ 常规档.
    ⛔ Fence: if the measured fix turns out to need a behaviour change — a predicate edit, a schema arm,
    a new key — the dev stops and reports. claude-fable-5-1 capacity is exhausted for this account, so
    such a diff could not get the at-tier review the enqueue gate would demand, and
    「契约复核 ⛔ 不适用额度耗尽豁免降档」.

    Thread-read: this card's full thread read to the end (triage, 2026-09-05). No maintainer ruling on it.
    Serial constraints cleared: this file is disjoint from every surface this seat has in flight (automation/control-flow.zod.ts #16752, data/field.zod.ts #16126) and from the two PRs in the merge queue (shared/value-domain.zod.ts #16899, data/display-name.ts #16901).

    Independent acceptance criterion for this member (gate ④ — it is checkable on its own, not only as part of the family): the droppedFields .describe() no longer justifies its aggregated shape with "schema-uniform, so every row drops the same set".

    ⭐ Two premises the dev must falsify before writing anything.

    ⭐ The line number in the card is stale, twice over. The card says :2320; triage measured :2317 on 2026-09-05; this seat measures :2361 on origin/main 0939ba008 (grep schema-uniform, so every row → 1 hit; positive control droppedFields on the same file → 6 hits, so the reading is not an instrument artefact). ⛔ Take the line from the tree.

    ⭐ A live neighbour landed on this exact file after the card was written. e08892dac — "feat(spec,metadata-protocol): cloneData reports droppedFields like every other create face — CloneDataResponseSchema gains the optional member (#16823)". Read that new member before editing and answer explicitly: does CloneDataResponseSchema.droppedFields carry the same false justification? If it does, it is in scope as the same sentence in a second place. If it does not, say so with the reading that shows it.

    ⭐ The card's counts do not reproduce, and triage declined to "correct" the filer. The card measured rowHookWrittenKeys = 5 on PR #15395's branch head 485a2d525; triage measured 3 on origin/main, with the control hookWrittenKeys reading 12 on the card and 11 raw / 6 de-commented for triage. Triage's position, verbatim: 「差异有明确解释 …⛔ 不「纠正」填卡人」 — the argument does not depend on the count. ⛔ Do not build the fix on either number without re-measuring it now.


    Generated by Claude Code

  4. claude commented on Sep 8, 2026

    @claude
    Contributor

    os-dev-report

    {
      "issue": 15769,
      "status": "done",
      "branch": "claude/issue-15769-stale-contract-prose-trio",
      "pr": "https://github.com/objectstack-ai/objectstack/pull/16930",
      "premise_still_valid": true,
      "summary": "Fold of #15769 + #15777 + #15778, one branch, one PR, one changeset. All three PM greps reproduced verbatim on the tree at 0939ba008 before any edit, each re-taken with the PM's own positive control. Each sentence rewritten to what the code does; no predicate, schema arm, key or export moved, so the Clause-2 fence never triggered. Per-member criteria, each with the control that makes the zero a reading: #15769 'deliberately admits both until D3 lands' 1 (:180) to 0, control FILE_REFERENCE_TYPES 2, and the classifier still returns FileReferenceIdValueSchema alone for form==='stored'; #15777 'schema-uniform, so every row' 1 (:2361) to 0 and 'schema-uniform' anywhere in file 1 to 0, control droppedFields 6; #15778 'duty.grace_days' 2 (:40,:41) to 0, control FieldReferenceSchema 13. NEIGHBOUR ANSWERED: CloneDataResponseSchema.droppedFields does NOT carry the same false justification - grep 'schema-uniform' on protocol.zod.ts was 1 before the change, at the CreateManyDataResponseSchema site only; CloneDataResponseSchema is a single-record face ({object,id,sourceId,record}) with no aggregation to justify and no per-row claim in its describe. Left untouched. #15769's second half taken by triage's own offered route (docblock only; FileLikeValueSchema stays exported) because removing a published export is a Clause-2 diff the fence forbids.",
      "tests": "GATES: 93 derived by 'node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands' on the delivered tree; all 93 run; reconciled with --ran: 'dispatch-gates --ran: 93 derived famil(ies) accounted for - 93 run, 0 NOT-MEASURED' (exit 0). First sweep: 87 exit-0, 4 exit-3, 2 exit-1. check:doc-authoring exit 1 was a REAL finding against my own diff (an issue id inside a customer-facing .describe()); fixed by moving the id to an adjacent // comment, re-run green: '15159 customer-facing string(s) across 874 spec sources clean', describe bucket 8742. The other 5 were PREREQUISITE NOT MET (the gates say so in their own words: 'Nothing was measured'); after building formula+lint+client-react (turbo: 34 successful, 34 total) all re-ran exit 0: check:doc-formula-expressions, check:doc-security-posture, check:docs-transcript-drift, check:skill-examples ('258 marked example(s) across 106 file(s), 3 surface(s)', which includes the spec-source-TSDoc surface). FINAL: 92 of 93 green, 1 NOT MEASURED (check:dual-build-cjs-loads, exit 3, needs a whole-repo pnpm build - 79-plus packages with no dist; declared, handed to CI). TESTS: 'pnpm --filter @objectstack/spec test && typecheck' under scripts/pm/os-verify-lock.sh (slot issue-15769-spec-test) - 'Test Files 466 passed (466)', 'Tests 13032 passed (13032)', 'check:test-typecheck: OK', wrapper 'VERDICT command-exit 0'. GENERATED: check:generated proved exactly one artifact stale (content/docs/references/**), --fix regenerated only it, re-verify 'All 15 generated artifacts are up to date' - and check:api-surface / check:authorable-surface / check:export-origins green throughout, the mechanical half of 'no surface moved'. LINT: repo-wide 'pnpm lint' narrowed to the 3 changed .ts files, run at final HEAD 7aec120c3 - eslint --no-inline-config --format json: 3 files linted, 0 errors, 0 warnings. Narrowing is a measurement, not a skip, on three readings: (1) population read from eslint's own config, not guessed - one eslint.config.mjs, files '**/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs}'; (2) file count 3 read from --format json output, not asserted; (3) invariance stated by the config's own measured header at eslint.config.mjs:327-329 - 'this repo runs one eslint.config.mjs, which never enables type-aware linting (no parserOptions.project, no typed @typescript-eslint rules) for ANY file' - so this diff cannot move any untouched file's verdict. check:nul-bytes OK (8370 text files, no raw control bytes), plus a manual grep -naP over the 3 edited files: clean. CHANGESET DECISION MEASURED, and it FALSIFIES the dispatch's hypothesis that a comment-only diff takes skip-changeset: @objectstack/spec ships its own sources - package.json files[] contains 'src/**/*.zod.ts', and 'npm pack --dry-run --json' lists 2073 published entries including all three edited files; positive control that the glob really filters - exactly one entry under src/ is not a .zod.ts (src/migrations/entries/README.md). So a real changeset, patch on @objectstack/spec. No ablation was owed: no gate or guard was added, and the diff is prose only.",
      "mcp_calls": "2 - both mcp__github__search_issues, for dedup only. REST /search/* answers 403 in this container (probed), which is the declared channel switch; every other GitHub read and write went through repo-scoped REST (issue+comment reads, issue create, PR create, PR/issue read-back).",
      "gates": "93 derived / 93 run / 92 green / 1 NOT MEASURED (check:dual-build-cjs-loads, exit 3 = PREREQUISITE NOT MET, whole-repo build) / 0 UNRUN. Reconciliation exit 0.",
      "line_budget": "not applicable, measured: 0 files under skills/** and 0 under .claude/** in the diff; 0 governed-surface paths (docs/adr/, .claude/, skills/, AGENTS.md, CLAUDE.md) - so this PR is not governed and owes no token/line ratchet reading.",
      "deviations": [
        "DECLARED NARROWING: repo-wide 'pnpm lint' (eslint . --no-inline-config) not run; narrowed to the 3 changed .ts files with the three readings recorded in 'tests'. CI runs the full farm.",
        "NOT MEASURED, declared: check:dual-build-cjs-loads exits 3 (PREREQUISITE NOT MET - 79-plus packages have no dist/; it needs a whole-repo pnpm build, which does not fit the container's foreground cap). Read as NOT MEASURED, never as green or red. Unrelated to this diff, which is prose-only in one package.",
        "The FIRST commit (8523c22f4) was made with core.hooksPath=/dev/null and so skipped pre-commit. Every later commit ran hooks normally, pre-push passed, no os-regen-pending deferral was outstanding, and check:generated is green on the delivered tree - but the bypass was mine and is reported rather than left implicit.",
        "origin/main moved to 9a89a0040 after my merge of 70f7d6d73. Not re-merged: dispatch-gates reports that none of the commits this tree can see touched what the gate derivation depends on, and the merge queue rebuilds the PR on current main anyway.",
        "Channel switch declared: REST /search/* is 403 here, so dedup used 2 targeted MCP search_issues calls, each with a live positive control on the same channel (query 1 control returned #15778 and #15769 as top hits of 21; query 2 control returned #15777, #14147, #3455 of 6). No wide-table scan.",
        "PM's docs-drift advisory answered in full (see docs_drift). The advisory's own checkout carried uncommitted changes; mine did not - HEAD 7aec120c3 with an empty 'git status --porcelain', re-derived independently and reporting dirty:false. Same 18 rows."
      ],
      "files_changed": [
        ".changeset/spec-prose-carriers-state-the-shipped-contract.md (new, patch on @objectstack/spec)",
        "content/docs/references/api/protocol.mdx (generated by gen:docs, one table row)",
        "packages/spec/src/api/protocol.zod.ts (#15777)",
        "packages/spec/src/data/field-value.zod.ts (#15769)",
        "packages/spec/src/data/filter.zod.ts (#15778)"
      ],
      "open_questions": [],
      "out_of_scope_findings": [
        "filed as #16923: the FIRST @example in the same FieldReferenceSchema block spells a $field comparand as the relation path order.owner_id - the same trap #15778 records, at a site #15778 does not name. Not fixed here because it is not mechanical: its caption frames it as a JOIN ON clause, so the correction is a judgement about the join surface. Filed unassigned and unlabelled; dedup ran first with a live control.",
        "noted, not filed: packages/metadata-protocol/src/protocol.ts, the docblock on mergeDroppedFieldEvents, carries the same falsified sentence as #15777 ('The create-side static-readonly strip is schema-uniform - every row drops the same set'), softened by a parenthetical that since #14147 the strip reports one event per call. Not fixed: correcting it would add packages/metadata-protocol to this PR's verification surface, and the PM capped this fold at three members for per-member reviewability. Dedup ran with a live control and found no card recording it. Successor: the domain:spec lane, which already holds the PM's deferred 11-card list of this exact shape - handed to the PM to file or fold there.",
        "noted, not filed: FileLikeValueSchema (packages/spec/src/data/field-value.zod.ts) is deprecated and has no consumer outside its own file and the spec's re-export - measured with a live control (the same grep for FileValueSchema finds real consumers). That is dead-code observation, not a filing class, and removing an exported schema would be a Clause-2 diff. It stays exported and its own docblock is already correct. Successor: none queued; recorded in the PR's acceptance notes so the next editor of this file need not re-measure it.",
        "noted, not filed: this run confirmed triage's correction to #15778's body. The @example is NOT published to content/docs/references/data/filter.mdx - re-measured with a live control (page is 169 lines, carries the schema import at :35 and a '## FieldReference' section at :56; grace_days, owner_id, completed_at, due_date all return 0). The 'published twice from one source' claim is not restated anywhere in the PR, commit message or changeset. Independently corroborated: gen:docs after the change moved only content/docs/references/api/protocol.mdx, while filter.mdx and field-value.mdx stayed unmodified."
      ],
      "docs_drift": "ANSWERED WITH READINGS on a tree I can name: HEAD 7aec120c3, 'git status --porcelain' EMPTY, base 9a89a0040 - my own re-derivation reports dirty:false, unlike the advisory's checkout. Re-derived with 'node scripts/docs-audit/affected-docs.mjs --json 9a89a0040...': same 18 rows (16 hand-written + 2 release-owned). ANCHORS: symbol CreateManyDataResponseSchema + literals addDays, due_date, grace_days. The SYMBOL anchor matched ZERO pages; 16 of 18 rows matched on the generic column names due_date/addDays alone; only content/docs/protocol/objectql/query-syntax.mdx matched all three literals. (1) #15777 premise, verbatim AND paraphrase: over all of content/docs, 'schema-uniform' 0, 'every row drops' 0, 'drops the same set' 0, against live controls readonly 48 pages / bulk 69 / createMany 8. Because a paraphrase counts I then READ every hand-written page mentioning droppedFields at all (6 pages): http-protocol.mdx:1013-1015, api/data-api.mdx:358-364, kernel/contracts/data-engine.mdx:392-396 - none makes a per-row or uniformity claim. Generated references/api/batch.mdx also clean (0/0/0 against its own control droppedFields 5). The ONLY carrier was generated references/api/protocol.mdx, which gen:docs rewrote in this PR. (2) #15769 anchorless, hand-checked and NOT read as a clean bill: the hand-written carrier is content/docs/protocol/objectql/types.mdx and it is ALREADY CORRECT - :1116 'Stored value: an opaque sys_file id string. The expanded read form is the media metadata object', and the callout :1132-1135 says deployments predating the migration may still hold the inline object and 'the engine warns rather than rejects'. Both halves of my corrected docblock are already published there, so this change REMOVES a disagreement rather than creating one; left alone because it is already correct. Corpus readings: sys_file 14 pages, file-as-reference 4, ADR-0104 12 (controls file 185 / attachment 28 / image 44); FILE_REFERENCE_TYPES 0 pages. data-modeling/field-types.mdx cites ADR-0104 only for location/address D1 and has sys_file 0. (3) #15778 elsewhere: 'duty.grace_days' across all tracked files 8 (control grace_days 14), and all 8 either record the refusal or test it (query-syntax.mdx states INVALID_FILTER; driver-sql cross-field-conformance-cases.ts:853 'SQL push-down refuses it'; formula and two service-analytics boundary tests; spec/src/data/filter.test.ts:1739; spec CHANGELOG; this PR's changeset describing the defect). Strongest reading: a regex for a $field comparand naming a DOTTED path across hand-written content/docs/**/*.mdx returns 0 hits, live positive control 6 same-table $field spellings from the same regex minus the dot requirement. Triage's measurement that neither @example reaches references/data/filter.mdx is NOT re-litigated. RELEASE-OWNED: content/docs/releases/** is read-only and NOTHING was edited there. Both rows are coincidental token matches, checked not assumed: v16.mdx:731,1009 matches 'addDays' because it names the FORMULA function addDays(d,n), a different surface from the filter addDays offset key; v17.mdx:556 matches 'due_date' inside a conditionalRequired-to-requiredWhen example, and its droppedFields passage at :1579-1584 makes no uniformity claim. NEITHER is factually wrong about any of these three defects, so there is NO docs-only card to file. Same reasoning retires the addDays rows on data-modeling/fields.mdx:407 and formulas.mdx:177,228 (formula helper, not filter key). NET: zero doc pages are falsified by this change, so zero pages were edited; every page above was left alone for a stated reason. Full section with the same readings is in the PR body.",
      "files_changed_note": "5 files, all listed above. ZERO content/docs pages edited beyond the ONE generated file gen:docs rewrote (content/docs/references/api/protocol.mdx). ZERO release-owned pages touched. ZERO governed-surface paths."
    }

    Generated by Claude Code

  5. removed their assignment
    on Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions