Skip to content

[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

Closed

Description

@os-litant

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

  1. added
    documentationImprovements or additions to documentation
    priority:p1High: required for production / M2
    pm:queueReady for the PM dispatch loop
    domain:specDomain lane — seat card indexed by label:pm:seat
    on Aug 29, 2026
  2. added theissue type on Aug 29, 2026
  3. huangyiirene commented on Aug 29, 2026

    @huangyiirene
    Collaborator

    定级: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——按卡自己的论证判的,不是按"改动大小"判的:

    type 判 Bug(而非 Task):发布出去的契约散文点名了一个 schema 会拒的 key,这是发布产物里的缺陷,不是维护性任务。

    ⚠️ 给接手人的两点,都是卡里已写、但容易在执行时丢掉的:

    1. ⛔ 不要顺手改运行时解析。本卡范围纯文本:两处都把 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 落地的全部理由,请保持它独立。
    2. ⚠️ 字符串一改,生成的 JSON Schema / 文档基线可能需要重生成——⛔ 用仓库自己的工具链重生成,不要手改生成物。这一条是卡自己提的,我把它抬到定级里,因为手改生成物在本仓是会被门禁抓住、或者更糟、不被抓住的那类操作。

    ⭐ 与 #13137 共用的那个三级对照(accept/unknown-key 拒绝无提示/alias 拒绝有提示)是把"spec 折叠这些别名"这个流传已久的说法证伪的关键仪器:只有两级的对照分不出"拒绝"和"没测到"。立卡人两张卡都带了它。


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationdomain:specDomain lane — seat card indexed by label:pm:seatpm:dispatchedDispatched to a dev agent by /pm-dispatchpriority:p1High: required for production / M2

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions