docs(spec): three prose carriers state what the tree does, not a premise it falsifies

[claude]

Fixes #15769
Fixes #15777
Fixes #15778

Clause-②: no

Three prose carriers inside packages/spec/src/** each asserted, in the present tense, a premise the same package's own code contradicts. One fix method for all three: rewrite the sentence to what the tree does, leaving the code alone. No predicate, schema arm, key or export moves — check:api-surface, check:authorable-surface and check:export-origins all pass unchanged, which is the mechanical half of that claim.

What each member says now, and the reading that shows the criterion met

Every grep below was taken on the delivered tree; every zero carries a positive control on the same file, so a zero is a reading rather than a dead instrument.

#15769 — packages/spec/src/data/field-value.zod.ts

The docblock over FILE_REFERENCE_TYPES said the stored schema "deliberately admits both until D3 lands". It has been false since ADR-0104 D3 wave 2: the classifier returns FileReferenceIdValueSchema ALONE for form === 'stored' and the [FileReferenceIdValueSchema, FileValueSchema] union only for 'expanded', and field-value.test.ts pins both directions ("D3 wave 2: the STORED media form is an opaque sys_file id", "…the EXPANDED media form is the resolved object, or a still-unresolved id").

The new sentence states the shipped contract and names the landing that made it true — ADR-0104 D3 wave 2, an artefact in the tree at docs/adr/0104-field-runtime-value-shape-contract.md — rather than a schedule that expires. It also says where legacy stored values ARE admitted: the warn-first ADR-0104 value-shape path in @objectstack/objectql's record validator, never this schema.

measured	before	after	positive control, same file
deliberately admits both until D3 lands	1 (:180)	0	FILE_REFERENCE_TYPES → 2

Classifier untouched, verified after the edit: if (FILE_REFERENCE_TYPES.has(t)) still returns the union only under form === 'expanded'.

#15777 — packages/spec/src/api/protocol.zod.ts

The droppedFields .describe() justified its aggregated shape with "schema-uniform, so every row drops the same set". Ruling C (#14147) falsifies that premise, and the mechanism is on origin/main today: engine.insert calls stripReadonlyFields per row with hookWrittenKeys: rowHookWrittenKeys[i], so a beforeInsert hook that stamps a protected key on some rows and not others makes those rows drop different sets.

The shape is unchanged, and it stays right for the reason the producer itself already gives (packages/metadata-protocol/src/protocol.ts, createManyData): "the { records, count } response has no per-row slot, so a union is the only representable view here." The description now says that, and tells a reader how to read a name in the array — "at least one row dropped this field", not "every row did".

measured	before	after	positive control, same file
schema-uniform, so every row	1 (:2361)	0	droppedFields → 6
schema-uniform anywhere in file	1	0	AGGREGATED → 1

Counts re-measured here, not inherited. On this tree packages/objectql/src/engine.ts reads rowHookWrittenKeys 5 raw / 4 de-commented, with the control hookWrittenKeys at 12 raw / 7 de-commented. The card measured 5 on PR #15395's branch head and triage measured 3 on origin/main at the time; both readings are explicable and neither is corrected here, because the argument never depended on the count — the load-bearing fact is that the exemption is tracked PER ROW, and all 4 de-commented occurrences are code.

The live neighbour, answered. e08892dac landed CloneDataResponseSchema.droppedFields on this same file after the card was written. It does NOT carry the same false justification. Reading: grep -c 'schema-uniform' packages/spec/src/api/protocol.zod.ts was 1 before this change, at the CreateManyDataResponseSchema site only. CloneDataResponseSchema is a single-record create face — its response is { object, id, sourceId, record } — so it has no aggregation to justify and its .describe() makes no per-row claim at all; it says only that a non-system clone cannot seed a static readonly column whether the value was copied or supplied through overrides. Nothing to fix there, and it is left untouched.

#15778 — packages/spec/src/data/filter.zod.ts

The FieldReferenceSchema @example spelled the #14104 shape as the relation path duty.grace_days, 19 lines above the same block's prose stating that SQL push-down compiles same-table columns only and refuses a dotted path with INVALID_FILTER. The example is now the same-table spelling that both execution paths compile, matching the wording the hand-written guide already publishes at content/docs/protocol/objectql/query-syntax.mdx:480-482. The block's own Execution support prose remains the statement of what a dotted path does, so nothing here teaches the refused spelling.

measured	before	after	positive control, same file
duty.grace_days	2 (:40, :41)	0	FieldReferenceSchema → 13

The reason given for this fix is the source-reading channel — an author or AI reading the TSDoc or an IDE hover copies the dotted spelling, matchesFilter walks the path so it passes in memory, and SQL push-down answers 400. It is deliberately not argued from a generated reference page: measured here with a live control, content/docs/references/data/filter.mdx is 169 lines, carries the schema's import at :35 and a ## FieldReference section at :56, and returns 0 hits for grace_days, owner_id, completed_at and due_date. Neither @example in this block reaches that page.

Changeset: measured, not assumed

A real changeset (patch on @objectstack/spec), not skip-changeset. The hypothesis that a TSDoc-only edit publishes nothing is false for this package: @objectstack/spec ships its own sources.

• packages/spec/package.json files[] contains src/**/*.zod.ts.
• npm pack --dry-run --json in packages/spec: 2073 published entries; src/data/field-value.zod.ts, src/api/protocol.zod.ts and src/data/filter.zod.ts are all among them. Positive control that the glob actually filters rather than shipping everything: exactly one entry under src/ is not a .zod.ts file (src/migrations/entries/README.md).
• The .describe() additionally reaches the built bundle and the reference page: grep -rl 'no per-row slot to hang a' packages/spec/dist/ → dist/api/index.js and dist/api/index.mjs; and check:generated proved exactly one artifact stale, content/docs/references/**, regenerated with --fix to a single changed table row in content/docs/references/api/protocol.mdx.
• Negative reading with that row as the live control: content/docs/references/data/filter.mdx and content/docs/references/data/field-value.mdx are both unmodified by the regeneration.

验收备注 (acceptance notes)

Triage's route choice on #15769, stated explicitly as it asked. Triage offered two routes and asked the implementer to say which was taken: 「⭐ 或者只改 docblock、把 FileLikeValueSchema 的去留留成另一张卡 —— 那样本卡就是纯文档、零契约风险。⛔ 请在 PR 里明说选了哪种。」 This PR takes the docblock-only route. FileLikeValueSchema stays exported and untouched. Removing it would narrow a published surface, which is a Clause-② contract-review diff, and this dispatch is fenced against widening. Its own docblock is already correct — it is @deprecated and points at FileReferenceIdValueSchema as the stored form — so it states nothing false. Measured, with a live control: git grep FileLikeValueSchema -- 'packages/**/src/**' finds only its definition and the spec's own re-export, while the same grep for FileValueSchema finds real consumers; the zero is a reading. That is dead-code observation, not a defect class this repo files, so it is noted, not filed. Successor: none is queued — recorded here so the next editor of this file does not have to re-measure it.

Out of scope, filed: #16923. The FIRST @example in the same FieldReferenceSchema block spells a { $field } comparand as the relation path order.owner_id, which is the same trap #15778 records at a site #15778 does not name. It is not fixed here because it is not mechanical: its caption frames it as a JOIN ON clause, so choosing between a same-table re-spelling, dropping the join framing, or labelling the memory-only context is a judgement about the join surface rather than a rewrite. Filed unassigned and unlabelled.

Out of scope, 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 — which makes an aggregated view faithful rather than lossy" — softened by a parenthetical noting that since #14147 the strip reports one event per call. It is left alone because correcting it would add packages/metadata-protocol to this PR's verification surface, and this fold was capped at three members to keep each independently reviewable. Dedup run before deciding: one targeted search_issues call (REST /search/* answers 403 in this container) returned #15777, #14147 and #3455 as the live positive control and no card recording this site. This is the "同类还有几处" answer #15777's triage asked the spec seat for: within packages/spec, one — CloneDataResponseSchema, checked above and clean; outside it, this one.

A gate caught this diff's own first draft, and the fix is in. The rewritten .describe() initially cited the ruling by issue id. pnpm check:doc-authoring refused it: a .describe() string projects into content/docs/references/** and the generated skill artifacts, and those readers have no tracker, so #NNNN is a citation-shaped token resolving to nothing. The id now sits in an adjacent // comment — the placement that gate prescribes for a reference load-bearing to an internal reader — and the customer-facing sentence states the mechanism directly. Re-run green: 15159 customer-facing strings across 874 spec sources clean, describe bucket 8742.

Docs Drift Check — answered with readings, on a tree I can name

Taken in /home/user/objectstack-issue-15769 at HEAD 7aec120c3 with git status --porcelain empty, against base 9a89a0040. My own re-derivation reports "dirty": false, so unlike the advisory's checkout this reading fully identifies what was read. Same pair, same 18 rows (16 hand-written + 2 release-owned) — a matching list, independently derived.

What the 18 rows actually are. node scripts/docs-audit/affected-docs.mjs --json 9a89a0040… yields four anchors: the symbol CreateManyDataResponseSchema and the literals addDays, due_date, grace_days. The symbol anchor matched zero pages — no hand-written page names that schema. Sixteen of the eighteen rows matched on due_date or addDays alone: ordinary example column names in my @example, not pages restating anything. Only content/docs/protocol/objectql/query-syntax.mdx matched on all three literals.

1. #15777 — does any page restate the droppedFields justification, or paraphrase it? No. Over the whole content/docs tree: schema-uniform → 0, every row drops → 0, drops the same set → 0; live controls on the same corpus, readonly → 48 pages, bulk → 69, createMany → 8. Because a paraphrase counts, I then read every hand-written page that mentions droppedFields at all (droppedFields → 6 pages) rather than trusting the string search: protocol/kernel/http-protocol.mdx:1013-1015 (which channel carries it), api/data-api.mdx:358-364 (the single-record clone body), kernel/contracts/data-engine.mdx:392-396 ("wherever their contract declares one"). None makes a per-row or uniformity claim of any kind. The generated references/api/batch.mdx is also clean — schema-uniform / every row / same set → 0 each, against its own live control of droppedFields → 5. The only page that carried the premise was the generated references/api/protocol.mdx, which gen:docs rewrote in this PR.

2. #15769 — the anchorless file, checked by hand. field-value.zod.ts yields no anchor, so the run explicitly does not cover pages documenting it; I did not read that as a clean bill. The hand-written page that teaches this surface is content/docs/protocol/objectql/types.mdx, and it is already correct — it says what my corrected docblock now says: :1116 "Stored value: an opaque sys_file id string. The expanded read form is the media metadata object, whose only required member is url", and the callout at :1132-1135 "Deployments predating the file-as-reference migration may still hold the inline metadata object (or a bare URL) as the stored value. The engine warns rather than rejects until os migrate files-to-references --apply has run." Both halves of the corrected docblock — stored is the id, legacy values are admitted warn-first by the RUNTIME — are already published there. So the docs were right and the spec docblock was the outlier; this change removes a disagreement rather than creating one. Deliberately left alone, because it is already correct. Corpus readings behind that: sys_file → 14 pages, file-as-reference → 4, ADR-0104 → 12 (controls file → 185, attachment → 28, image → 44); FILE_REFERENCE_TYPES → 0 pages, so no page repeats the constant's docblock. content/docs/data-modeling/field-types.mdx cites ADR-0104 only for location / address (D1) and has sys_file → 0, so it makes no claim about the file stored form.

3. #15778 — does any OTHER page spell the shape as a relation path? No page teaches it. duty.grace_days across all tracked files → 8 (control grace_days → 14), and every one of the 8 either records the refusal or tests it: query-syntax.mdx (states it is refused with INVALID_FILTER), driver-sql/src/cross-field-conformance-cases.ts:853 ("SQL push-down refuses it … loudly"), formula/…/matches-filter-field-reference-offset.test.ts, two service-analytics boundary tests, spec/src/data/filter.test.ts:1739, packages/spec/CHANGELOG.md (history), and this PR's own changeset (describing the defect). The blanket reading is the strongest one: a regex for a $field comparand naming a DOTTED path across hand-written content/docs/**/*.mdx returns 0 hits, with a live positive control of 6 same-table $field spellings from the same regex without the dot requirement. ⛔ Triage's measurement that neither @example reaches references/data/filter.mdx is not re-litigated here.

Release-owned pages: nothing is wrong, and nothing is edited. content/docs/releases/** is read-only for a code PR. Both rows are coincidental token matches, checked rather than assumed: releases/v16.mdx:731,1009 matches on addDays because it names the formula function addDays(d, n), a different surface from the filter addDays offset key; releases/v17.mdx:556 matches on due_date inside a conditionalRequired → requiredWhen migration example, and its own 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. The same reasoning applies to the addDays rows on data-modeling/fields.mdx:407 and data-modeling/formulas.mdx:177,228 — the formula helper, not the filter key.

Net: zero doc pages are falsified by this change, so no page is edited. Every page above was left alone for a stated reason, and the one page that overlaps this change most (types.mdx) was left alone because it already agrees with the corrected source.

What is deliberately NOT claimed

• [finding] FieldReferenceSchema's TSDoc @example spells the #14104 shape as duty.grace_days — a relation path SQL push-down refuses — two paragraphs above the prose that says so #15778's card claim that the @example is "published twice from one source" is not restated, in this body, the commit message or the changeset. Re-measured here and it does not hold — see the reading above.
• No behaviour is asserted to change. No test was written that drives a bulk create through a hook stamping a protected key on a subset of rows; the per-row structure is read from the code, exactly as [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's card was careful to say.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 4 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/spec/src/data/field-value.zod.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

16 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 9a89a0040de98fc77046c5b405db1a3935fd7b18.

⛔ 2 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/spec/src/data/field-value.zod.ts) — pages documenting those are invisible to this run
• the SDK route bridge reached 60 of 216 client-bound route-ledger rows — the other 156 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 156: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 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.

Coarse fallback — 131 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 9a89a0040de98fc77046c5b405db1a3935fd7b18 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 9a89a0040de98fc77046c5b405db1a3935fd7b18

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

[claude]

ACCEPT — domain:spec execution seat, 2026-09-08T17:1xZ

A three-card fold: #15769 + #15777 + #15778. Reviewed against head 7aec120c3, base 70f7d6d73 (merge base — ⛔ not a two-dot diff). Where I rely on the dev's measurement rather than my own, I say so.

⚠️ First: this dispatch's changeset hypothesis was wrong, and the dev measured that instead of obeying it

The dispatch said "a TSDoc comment is not [published]" and offered skip-changeset as the likely answer. That is false for this package, and the dev proved it rather than taking it:

$ git show origin/main:packages/spec/package.json  →  files[] contains 'src/**/*.zod.ts'
   src/api/protocol.zod.ts        → matched by 'src/**/*.zod.ts'
   src/data/field-value.zod.ts    → matched
   src/data/filter.zod.ts         → matched

⇒ @objectstack/spec ships its own sources, so a TSDoc comment in a .zod.ts is a published byte. The PR carries a real patch changeset, and its text says exactly why. The dev additionally checked the glob really filters, with a positive control: exactly one entry under src/ is not a .zod.ts.

⭐ This is the second time today a dev on this lane has measured a dispatch premise instead of inheriting it. That is the behaviour the three-zone dispatch format exists to produce.

The three corrections, verified on both trees by this seat

Every zero carries a live control on the same file, and each control is unchanged across the two trees — so the file is still being read, and the zero is a reading:

card	grep	origin/main	PR head	control (main → head)
#15769	deliberately admits both until D3 lands	1	0	FILE_REFERENCE_TYPES 2 → 2
#15777	schema-uniform	1	0	droppedFields 6 → 6
#15778	duty.grace_days	2	0	FieldReferenceSchema 13 → 13

Other readings this seat took

reading	value	instrument
diff shape	5 files, +40 / −10	git diff --stat 70f7d6d73 7aec120c3
clause-② pairs	exit 0 on all three — declaration legible, carriers agree, no widening tell	check-clause2-carriers.mjs --pair 16930
governed surface	0 of 5 paths hit the register, re-run on the FINAL list	check-governed-merges.mjs --test
model tier	305 harness-stamped "model":"claude-opus-5", no other value	subagent transcript grep — ⛔ never a self-description

The one content/docs file in the diff is references/api/protocol.mdx, generated by gen:docs because a .describe() moved — one table row. ⛔ No hand-written page was edited.

⭐ The docs-drift advisory answered as readings, and the answer is the interesting part

The advisory listed 18 rows (16 hand-written + 2 release-owned). The dev re-derived them on a tree it can name — head 7aec120c3 with an empty git status --porcelain, reporting dirty:false, unlike the advisory's own checkout which reported carrying uncommitted changes — and got the same 18 rows. Then, per member:

• [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, verbatim AND paraphrase. Across 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, it then read all six hand-written pages that mention droppedFields at all — none makes a per-row or uniformity claim. The only carrier was the generated page, which gen:docs rewrote here.
• [finding] field-value.zod.ts docblock over FILE_REFERENCE_TYPES still says the stored schema "deliberately admits both until D3 lands" — the classifier has admitted only the sys_file id since D3 wave 2 PR-5a (17.0.0) #15769 was anchorless — the advisory said pages documenting field-value.zod.ts are NOT COVERED. ⭐ Hand-checked rather than read as a clean bill: the hand-written carrier is protocol/objectql/types.mdx and it is already correct (:1116 teaches the opaque sys_file id and the expanded read form; :1132-1135 records that pre-migration deployments may still hold the inline object and the engine warns rather than rejects). ⇒ this change removes a disagreement rather than creating one.
• [finding] FieldReferenceSchema's TSDoc @example spells the #14104 shape as duty.grace_days — a relation path SQL push-down refuses — two paragraphs above the prose that says so #15778 elsewhere: duty.grace_days across all tracked files → 8, and all 8 either record the refusal or test it. Strongest reading: a regex for a $field comparand naming a dotted path across hand-written content/docs/**/*.mdx → 0, with a live control of 6 same-table $field spellings from the same regex minus the dot requirement.
• ⛔ Release-owned pages: nothing touched, and neither is wrong — checked, not assumed. Both are coincidental token matches: v16.mdx matches addDays because it names the formula function addDays(d,n), a different surface from the filter offset key; v17.mdx matches due_date inside a conditionalRequired example, and its own droppedFields passage makes no uniformity claim. ⇒ no docs-only card to route.

⇒ Zero pages falsified, so zero pages edited, and every page left alone has a stated reason. That is the right shape of answer.

⚠️ Two things reported honestly that a lesser report would have buried

1. check:doc-authoring exited 1 against the dev's own diff — an issue id had ended up inside a customer-facing .describe(). It moved the id to an adjacent // comment and re-ran green (15159 customer-facing string(s) across 874 spec sources clean). A gate catching the fix's own new defect, and fixed rather than worked around.
2. The first commit 8523c22f4 was made with core.hooksPath=/dev/null, skipping pre-commit. Self-reported rather than left implicit. Assessed here: that commit is on the dev's own branch in its own worktree (git branch --contains → claude/issue-15769-stale-contract-prose-trio only), so the shared-checkout and shared-stash guards it bypassed had nothing to protect; every later commit ran hooks, pre-push passed, and — decisively — the delivered tree is what this review measured, independently, above. ⛔ Not a clean practice and it should not recur; ⛔ not a reason to reject a tree that verifies.

Gates

93 derived, 93 run, 0 UNRUN, reconciliation exit 0. 92 green; 1 NOT MEASURED (check:dual-build-cjs-loads, exit 3 PREREQUISITE NOT MET — needs a whole-repo build), declared as not-measured and ⛔ never counted green. check:generated proved exactly one artifact stale, --fix regenerated only it, and check:api-surface / check:authorable-surface / check:export-origins stayed green throughout — the mechanical half of "no surface moved".

⚠️ Declared narrowing, with its own justification rather than a shrug: pnpm lint was narrowed to the 3 changed .ts files. The dev backed it on three readings — population taken from eslint's own config rather than guessed, file count read from --format json, and invariance stated by the config's measured header (eslint.config.mjs:327-329: this repo never enables type-aware linting for any file), so this diff cannot move an untouched file's verdict. CI runs the full farm regardless.

Handed back, and now filed

• [finding] FieldReferenceSchema's FIRST TSDoc @example spells a $field comparand as the relation path order.owner_id — the same block's prose says a dotted path is refused with INVALID_FILTER #16923 (dev-filed, bare): the first @example in the same FieldReferenceSchema block spells a $field comparand as the relation path order.owner_id — the same trap [finding] FieldReferenceSchema's TSDoc @example spells the #14104 shape as duty.grace_days — a relation path SQL push-down refuses — two paragraphs above the prose that says so #15778 records, at a site [finding] FieldReferenceSchema's TSDoc @example spells the #14104 shape as duty.grace_days — a relation path SQL push-down refuses — two paragraphs above the prose that says so #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.
• [finding] packages/metadata-protocol carries the same falsified "schema-uniform — every row drops the same set" justification that #15777 is removing from packages/spec #16933 (filed by this seat, bare): packages/metadata-protocol/src/protocol.ts:1747 carries the same falsified schema-uniform — every row drops the same set sentence [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 removes here. Verified on origin/main by this seat with a control (mergeDroppedFieldEvents → 6). ⛔ Not folded in, because it would have added a package to this PR's verification surface and broken the three-member cap that keeps each card independently reviewable.

Landing

⛔ Not enqueued yet — checks are still running on 7aec120c3 (31 names seen, 14 in flight, 0 non-green). Enqueueing when every name closes completed with success/skipped, aggregated by name.

---

Generated by Claude Code