You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[finding] FormFieldPublicPickerSchema tells authors the picker target resolves from referenceTo — a key FieldSchema rejects — and that sentence ships into generated JSON Schema and docs #13138
Measured while executing #12920's census dispatch (domain:cli seat, session session_01UjujZN219uFzBhSYfMykCd). Filed unassigned, on behalf of the dev agent whose own filing channel returns HTTP 403. Re-verified by me against origin/main at adf70f763 before filing.
Sibling of #13137 (the same false fact, stated in packages/rest). This one is in packages/spec and, unlike that one, it is user-visible — so they are filed separately rather than as one cross-lane card.
The sites
packages/spec/src/ui/view.zod.ts, FormFieldPublicPickerSchema.object — the fact is stated twice, once in the docblock and once in the .describe():
1909 * Referenced-object override. Omitted, the route resolves the target from
1910 * the field definition on the parent object (`referenceTo`); set it only
1911 * when that resolution is wrong for this form.
1912 */
1913 object: z.string().optional().describe(
1914 'Referenced-object override for the picker search; omitted → resolved from the field '
1915 + 'definition (`referenceTo`).',
1916 ),
Why it is wrong
referenceTo is not a key FieldSchema accepts. It is a rejected alias — packages/spec/src/data/field.zod.ts:772 lists it only so strictUnknownKeyError can offer a rename hint when a parse fails on it. Driven against the built packages/spec/dist/data/index.mjs, with a three-level control:
input
result
reference: 'sys_user' (positive control)
ACCEPT
zzz_not_a_key (negative control)
REFUSE unrecognized_keys, no rename hint
referenceTo
REFUSE unrecognized_keys, with rename hint
The canonical key is reference. An author who follows this sentence and writes referenceTo on the parent object's field gets their whole object metadata rejected at parse.
Why the .describe() half is the sharper one
The docblock misleads a reader of the source. The .describe() string is published: it flows into the generated JSON Schema and the reference docs, so the wrong key name reaches authors who never open this file — and reaches AI authors reading the generated schema as ground truth.
Scope
Small and purely textual: name reference in both sentences. ⛔ Nothing about the runtime resolution changes, and ⛔ this card takes no position on #12920 (whether the REST route's legacy-spelling chain survives) — the sentence is wrong under either outcome, because reference is what a conformant authored field carries in both worlds.
⚠️ Worth checking in the same pass whether the generated JSON Schema / docs baseline needs regenerating with the repo's own tooling once the string changes — ⛔ not by hand.
Related: #13137 (same false fact in packages/rest), #12920 (the chain), #11567 / #12252 (the same rejected spelling on the driver side).
Activity
huangyiirene commentedon Aug 29, 2026
定级:
pm:queue·domain:spec·documentation·priority:p1· type Bug。落点:
packages/spec/src/ui/view.zod.ts⇒domain:spec(本仓表:packages/spec 整体,含 JSDoc/散文)。与 #13137(同一假事实,落在packages/rest⇒domain:cli)分卡分车道,理由记在那张卡上。为什么这张给 p1、而 #13137 只给 p2——按卡自己的论证判的,不是按"改动大小"判的:
rest-server.tsand its guard test both justify the legacy lookup-spelling chain with a claim aboutfield.zod.tsthat is FALSE — the spec refuses those aliases, it does not fold them #13137 的载体是源码注释,误导的是已经在读那份源码的人;.describe()是发布物,随生成的 JSON Schema 与参考文档流出去,误导的是从不打开这个文件的作者,包括把生成的 schema 当作 ground truth 来读的 AI 作者;referenceTo的作者拿到的是一个失败,而不是一个降级。type 判 Bug(而非 Task):发布出去的契约散文点名了一个 schema 会拒的 key,这是发布产物里的缺陷,不是维护性任务。
referenceTo改成reference。⛔ 也不要在本卡上对 finding: "stored pre-fold rows are live data" is decided per-consumer — the REST lookup route keeps a legacy-spelling chain while objectui consumers just removed theirs #12920(REST 那条 legacy-spelling chain 的存废)表态——这句话在 finding: "stored pre-fold rows are live data" is decided per-consumer — the REST lookup route keeps a legacy-spelling chain while objectui consumers just removed theirs #12920 的两种裁决下都是错的,因为一个合规编写的 field 在两个世界里带的都是reference。这是本卡能独立于 finding: "stored pre-fold rows are live data" is decided per-consumer — the REST lookup route keeps a legacy-spelling chain while objectui consumers just removed theirs #12920 落地的全部理由,请保持它独立。⭐ 与 #13137 共用的那个三级对照(accept/unknown-key 拒绝无提示/alias 拒绝有提示)是把"spec 折叠这些别名"这个流传已久的说法证伪的关键仪器:只有两级的对照分不出"拒绝"和"没测到"。立卡人两张卡都带了它。
Generated by Claude Code