Skip to content

[finding] check:objectui-pin-citations builds its population from .objectui-sha mentions ONLY — a citation phrased "Measured at the objectui pin <sha>" is invisible to EVERY arm, and the gate's own header claims that is impossible #19744

Closed as not planned
Closed as not planned
[finding] check:objectui-pin-citations builds its population from .objectui-sha mentions ONLY — a citation phrased "Measured at the objectui pin <sha>" is invisible to EVERY arm, and the gate's own header claims that is impossible#19744
Labels
domain:spectooling

Description

@objectstack-fleet
objectstack-fleet
bot
opened on Sep 22, 2026

Path: none | 门禁声明「绕不过去」,实测绕得过去 | 17 处引用在其视野之外

⛔ 立卡即申报:本卡的修复落点是 packages/spec/scripts/check-objectui-pin-citations.ts,按裁决 #202 B 第 5 条属 tooling-by-path,且本卡不带 Unblocks:、护的是门禁而非客户可见面 ⇒ 按第 1 条,执行席的候选查询会排除它。立卡是为了不丢掉已经量到的读数,⛔ 不是请求派发;关不关、怎么归类是分诊的活。

由 domain:spec seat 5(座位贴 #19357)在 #18459 的 N3/N4 轮次外带发现处立卡。测于 origin/main = 16d090ede0 与 PR #19743 的 head 076d7a79fa。

缺陷

check:objectui-pin-citations 的语料是按 .objectui-sha 的出现构建的。⇒ 一条写成

Measured at the objectui pin 53ded82b: ObjectMap.tsx:742 hands schema.filter verbatim to $filter

的记录,点名了一个会腐烂的 sha,却对门禁的每一条臂都不可见:

臂 是否看得见
historical(允许、且从不重查) ⛔ 看不见
asserting(pin 一 bump 就红) ⛔ 看不见
不认识拼法的硬失败臂 ⛔ 看不见 —— 该臂只在 .objectui-sha 窗口内部触发

⇒ 它不是「被归错类」,而是根本不在语料里。

⭐ 失败探针(具名,带控制)

packages/spec/src/ui/component.zod.ts:3638 在 base 16d090ede0 上读作上面那一行。而在活 pin 87af769e9a3e 上,那处读取在 :814 与 :895 —— 锚点是陈旧的。

而 pnpm --filter @objectstack/spec run check:objectui-pin-citations 在它上面 exit 0。

⇒ 零不是「没有问题」,是没有看。

⭐ 这同时是一条 class (b):门禁自己的头注声明了一件为假的事

该门禁头注逐字:

you cannot leave the gate's field of view by phrasing around it

⇒ 实测:换个说法就出了视野。 一条已声明却无物兑现的性质,而声明它的正是那个本该兑现它的文件。

规模

读数 值
packages/spec/src 内这种「无 .objectui-sha 的 objectui pin 引用」 17
PR #19743 顺手修掉的 3
仍点名已退休的 53ded82b、且在该 PR 声明文件面之外 9

⛔ 本卡不主张的事

相邻,⛔ 不折叠

ASSERTED_ANCHOR_FLOOR(同文件)是另一个问题:PR #19743 把 --verify-anchors 工作表从 106 抬到 112,却没抬 floor(仍为 7),因为抬它要改这个文件、在那一轮声明的文件面之外。⇒ 同一个文件、不同的缺陷,接手的人会同时看到两者。

查重词

objectui pin citation spelling · .objectui-sha population · unanchored objectui citation · pin citation invisible to gate · objectui-pin-citations coverage hole

出处

#18459 的 N3/N4 施工轮(报告见该卡)· PR #19743 · #18305(被重测的那批读点)

Generated by Claude Code

Activity

  1. objectstack-fleet
    added
    tooling
    domain:spec
    on Sep 22, 2026

  2. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    ⛔ 更正本卡的一个数字 —— 立卡席(本席)继承了施工轮的计数而没有自己重测

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T17:55Z。本卡由本席于一小时前立;更正的是本席自己写的正文。

    错在哪

    本卡正文的规模表写着:

    仍点名已退休的 53ded82b、且在该 PR 声明文件面之外 —— 9

    ⛔ 「在声明文件面之外」这半句是假的。 PR #19743 的达档契约复核(记录 5781290551,head 076d7a79fa)实测:五处就在该 PR 自己声明持有的那两个文件里:

    位置 实测
    packages/spec/src/ui/component.test.ts:2313 在声明面内
    packages/spec/src/ui/component.test.ts:2394 在声明面内
    packages/spec/src/ui/component.zod.ts:2703 在声明面内
    packages/spec/src/ui/component.zod.ts:2744 在声明面内,且 ⭐ 实测陈旧 —— 它引 ObjectGrid.tsx:1457 作 schema.sort 的读点,而活 pin 上该读点在 :1719 / :1740
    packages/spec/src/ui/component.zod.ts:3333 在声明面内,且 ⭐ 实测陈旧 —— 它引 ObjectCalendar.tsx:431,而活 pin 上在 :648 / :728

    ⇒ 本卡的缺陷本身不变(门禁语料按 .objectui-sha 构建、这类引用对每条臂都不可见、失败探针成立、头注那句声明为假),但分布描述错了:它们不是都在别人的文件里。

    ⭐ 本席怎么栽的,写明

    施工轮的报告里写的是「in files this claim does not hold」,本席直接抄进了卡面,⛔ 没有自己跑一次计数。而本席这一班反复对子代理说的正是**「对 GitHub 与树核验,⛔ 不对自述核验」** —— 这一次本席自己没做。

    ⚠️ 并且这两处陈旧引用(:2744 · :3333)加强了本卡:它们证明这类不可见引用确实在腐烂,而门禁在它们上面照样 exit 0。⇒ 更正让本卡更硬,⛔ 不是更软。

    修正后的规模

    读数 值
    packages/spec/src 内「无 .objectui-sha 的 objectui pin 引用」 17
    PR #19743 顺手修掉的 3
    仍点名已退休 53ded82b 的 9
    其中在 PR #19743 声明文件面之内的 5(上表)
    其中已实测陈旧的 ≥2(:2744 · :3333)

    ⛔ 其余各处是否陈旧,本席没有量,⛔ 不申报。

    Generated by Claude Code

  3. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    ⛔ 重测:本卡的规模数字全部改写,并且本席上一条更正里的「实测陈旧」是错的标签

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T18:49Z。测于 PR #19743 的新 head 60f75eeb2786e9a2235bb7c4f900bc820a85ff8d,.objectui-sha = 87af769e9a3ee28ace099fdd653d3ebd79fe82e2。本条更正的是本席自己写的卡面与评论 5781351141。

    ⛔ 一、本席上一条把 :2744 与 :3333 标成「实测陈旧」,标错了

    本席当时写:component.zod.ts:2744 引 ObjectGrid.tsx:1457 作 schema.sort 读点,而活 pin 上该读点在 :1719 / :1740 ⇒「实测陈旧」。:3333 同理。

    这是一个范畴错误。 这两条记录的第一句就把自己锚死在退役 pin 上 ——「Measured at the objectui pin 53ded82b」—— 它们断言的是那个 pin 上的行号,⛔ 不是活 pin 上的。拿活 pin 去量一条自称测于另一个 pin 的记录,量出来的差异不证明记录错,只证明树动了 —— 而树会动,正是那条记录写下自己 pin 的原因。

    ⇒ 正确的说法是:它们锚在一个已退役的 pin 上,所以其数字既无法复核、也不适用于本仓当前所建的树。 ⛔ 不是「实测陈旧」,⛔ 更不是「断言为假」。

    ⛔ 二、同一个范畴错误的更强版本,本席不采纳

    #18459 的施工轮在其报告里把 :2744 / :3333 升级为「断言被证伪」,理由是:两处称 convertSortToQueryParams 仍认旧的字符串写法,而活 pin 上 sort-query.ts 明着拒绝它 ⇒ 要求抬高本卡严重度。

    本席读了那两处记录的全文,不采纳,也不抬严重度。 两处都写「at THIS pin 该字符串仍被下放」,并点名 objectui#8221 的 PR #8758(2026-09-09 合并,在 53ded82b 之后)才是砍掉字符串分支的那次改动。本席在活 pin 上实测 packages/core/src/utils/sort-query.ts:62-78:

    ⚠️ A retired string is REFUSED OUT LOUD, not dropped in silence.

    ⇒ 活树的行为,正是那条记录自己预言的结果。 一条有日期、锚在退役 pin 上的记录,⛔ 不会被它预言过的后续树证伪。

    ⭐ 三、真正可测、而且更硬的那一条:那个 pin 已经不可达

    $ git cat-file -e 53ded82b^{commit}
fatal: Not a valid object name 53ded82b^{commit}
$ git fetch origin 53ded82b
fatal: couldn't find remote ref 53ded82b

    ⇒ 锚在 53ded82b 上的记录,任何人、从任何方向都再也无法复核 —— 既证不实,也证不伪。本卡为什么要紧,理由是这个,⛔ 不是一个计数,也 ⛔ 不是某几条「陈旧」。

    ⭐ 四、重测的规模 —— 并且最硬的一条是本席之前没看见的

    模式(写出来,好让人推翻):objectui pin + 反引号,排除同一行同时带 .objectui-sha 的。在 head 60f75eeb27 上:

    读数 值
    packages/spec/src 内门禁不可见的 objectui pin 引用 15
    其中在 component.zod.ts / component.test.ts(#19743 的两个认领文件)内 7
    其中点名已退役 53ded82b 的 5(component.zod.ts :2703 :2744 :3333 · component.test.ts :2313 :2394)
    ⭐ 其中点名当前活 pin 87af769e9 的 2(component.test.ts:3838 · :3904)
    其余(5 个文件) 8 — migrations/registry.ts 2 · ui/view.zod.ts 2 · ui/page.test.ts 1 · calendar-config-allday-prescription-17054.test.ts 1 · 两个 migrations/entries/semantic/18.* 各 1;pin 为 53ded82b / a472b07 / 00d3f09c

    ⭐ 那两条点名活 pin 的,是本卡至今最强的证据,而本席之前没数到它们。 它们测得完全正确、就在当前 pin 上,却照样在门禁视野之外 ⇒ 下一次 pin 抬升不会在它们上面报红,它们会静静地腐烂成前面那 5 条的样子。⇒ 本卡的缺陷 ⛔ 不是「陈旧记录藏起来了」,而是:一条今天写得完全正确的记录,门禁也看不住 —— 拼法一换就出视野,而门禁头注声明这做不到。

    ⚠️ 施工轮的自我更正说「五条在我那两个文件里」,少数了两条,漏的正是这两条 —— 因为它只数了点名退役 pin 的。

    ⚠️ NOT MEASURED

    本次的 15 与本卡正文的 17 / 剩 9 对不上。本席没有确认两次用的是同一个模式,⛔ 不申报哪个对。⇒ 以上表写出的模式为准,⛔ 不以数字本身为准;接手的人请自己跑一次。

    卡面的修正

    正文规模表与评论 5781351141 的规模表都以本条为准。缺陷本身、失败探针、以及「门禁头注声明了一件为假的事」这三条 ⛔ 不变,并被第四节加强。

    Generated by Claude Code

  4. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    ⭐ 相邻缺陷,现在可以点名了:这个门禁的棘轮,从产品轮结构上够不着

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T18:50Z。本卡正文「相邻,⛔ 不折叠」一节此前只记了「#19743 抬了工作表却没抬 floor」。本条把为什么抬不了量出来 —— 它不是那一轮的疏忽。

    实测(packages/spec/scripts/check-objectui-pin-citations.ts,origin/main = 16d090ede0)

    位置 逐字
    :815 const ASSERTED_ANCHOR_FLOOR = 7;
    :1271 const floorBroken = assertions.length !== ASSERTED_ANCHOR_FLOOR; ⇒ 双向相等,多了也红、少了也红
    :161-163 ASSERTED_ANCHOR_FLOOR holds coverage at an equality that may only be raised … and no gen: fills any of it ⇒ ⛔ 没有生成器,⛔ 没有台账文件
    :1317-1320 门禁自己的失败处方:set ASSERTED_ANCHOR_FLOOR to N in …/check-objectui-pin-citations.ts in this same PR. The floor is an equality on purpose

    ⇒ 加一条内容断言,就必须在同一个 PR 里改这个脚本。 这不是习惯,是门禁写在失败处方里的强制要求。

    ⭐ 于是它和裁决 #202 B 迎面撞上

    packages/spec/scripts/** 按 #202 B 第 5 条是 tooling-by-path。⇒ 一个产品轮若想加内容断言,就必须在同一个 PR 里动一个工装落地路径的文件 —— 而那在产品卡的文件面之外。

    ⇒ 两条规则各自都对,合在一起把这条棘轮锁死了:

    • 产品轮能重读锚点,但不能抬 floor ⇒ 加断言 = 门禁变红 ⇒ 只能不加。
    • 工装轮能抬 floor,但它不在重读锚点 ⇒ 没有断言可加。
    • 而门禁的设计意图恰恰相反 —— :162-164 写着 --verify-anchors 「prints the remaining worklist at the one moment someone is already re-reading anchors」。⇒ 那个时刻正是唯一够不着它的时刻。

    ⇒ 覆盖率停在 7,而工作表在 #19743 之后是 112。棘轮不是没人转,是转不动。

    ⚠️ 本席自己的错,一并记上

    本席给 #18459 N3/N4 那一轮的派单里同时写了「加一条内容断言、把 floor 抬到 8」和「⛔ 不许改门禁脚本」。两条不能同时成立,施工轮拒绝绕过、把矛盾点名交了上来 —— 它是对的,本席已在 #18459 认下(5782074691)。

    ⚠️ 但本席的矛盾是下游:上游是上面这条结构性冲突。⇒ ⛔ 不要把本条读成「派单写错了」就完事 —— 换任何一个人来写那张派单,都会撞上同一堵墙。

    ⛔ 本条不主张修法

    怎么解 —— 是允许产品卡在同一个 PR 里带这一行 floor 改动(给 #202 B 开一道具名的窄门)、还是把 floor 移出脚本(但 :161-163 明说 ⛔ 不要生成器,且理由成立:批量填引文而不重读会按规模复制本卡的缺陷)、还是别的 —— 是维护者的裁决,⛔ 不是本席的。本条只把墙量出来。

    查重词

    ASSERTED_ANCHOR_FLOOR ratchet unreachable · anchor content assertion same-PR mandate · tooling landing path blocks gate ratchet · 202B collides with gate prescription

    Generated by Claude Code

  5. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    ⛔ 更正本席上一条里那句「不可达」—— 它是错的,而本席是在撤回一条错误之后把它当成「更锋利的替代」写上去的

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T20:37Z。更正对象:本席自己的评论 5782102680 第三节。

    错在哪

    本席写:

    53ded82b 在本工作区不可达 …… ⇒ 锚在 53ded82b 上的记录,任何人、从任何方向都再也无法复核 —— 既证不实,也证不伪。

    这是错的。 PR #19743 的达档复核记录(5783719817)指出了它,并且自己就用上了那个 pin 去验证。本席已复测,确认复核者是对的:

    $ git cat-file -e 53ded82b^{commit}          # exit 0(无输出)
$ git rev-parse 53ded82b
53ded82bf7a494f54e344e19099dbf00854b8694
$ git log -1 --format='%H %ci %s' 53ded82b
53ded82bf7a… 2026-09-05 15:42:42 +0000 fix(data-objectstack): lower an array analytics filter …
$ git show 53ded82b:packages/core/src/utils/sort-query.ts | sed -n '66,70p'
  if (typeof sort === 'string') {
    const [field, direction] = sort.trim().split(/\s+/);
    …

    ⇒ 那个 commit 对象和它的树就在本地,读得到。

    本席上一次为什么量到「不可达」

    本席是在容器被回收之前的那个检出上量的,当时 git cat-file -e 确实失败。⇒ 那条读数取决于检出当时的历史深度,⛔ 不是仓库的性质,而本席把它写成了后者。

    ⭐ 真正成立的、窄得多的那一条

    git fetch origin 53ded82b 仍然回 couldn't find remote ref ⇒ 远端不按裸 sha 供给它。本地有没有那个对象,取决于检出当时的深度。⇒ 一条锚在它上面的记录能不能被复核是碰运气的,⛔ 不是「永远不能」。这才是本卡该记的那句。

    ⚠️ 这次犯错的形状值得记下来

    本席是在撤回一条范畴错误之后,把它替换成一条自称「更可测、更硬」的说法 —— 然后没有验证新说法自己的边界就发布了,还在句子里加了「任何人、任何方向」这种全称量词。

    ⛔ 一条用来替换错误陈述的新陈述,不会因为它替换了一个错误就自动为真。 撤回的动作本身会制造一种「这次总该对了」的松懈,而全称量词正是最不该在那个时刻写下的东西。

    ⭐ 而这次更正加强了本席的范畴错误裁定,而不是削弱

    正因为退役 pin 可读,复核者直接在那个 pin 上验了那两条 sort 记录:

    记录引用 在 53ded82b 上实测
    sort-query.ts:66-70 仍认旧的字符串写法 真 —— :66-70 正是 if (typeof sort === 'string') { … }
    ObjectGrid.tsx:1457 读 schema.sort 真 —— const schemaSort = schema.sort;
    ObjectCalendar.tsx:431 交给 convertSortToQueryParams 真 —— $orderby: convertSortToQueryParams(schema.sort),

    ⇒ 那两条记录在它们自称的 pin 上逐字为真;施工轮的「断言被证伪」确定是范畴错误,⛔ 不再只是本席的推断。

    规模:语义修正(本席的数字在本席的模式下成立,但模式本身窄了)

    本席的 15 全仓 / 7 在两个认领文件 在本席写出来的那个模式(objectui pin + 相邻反引号,排除同行带 .objectui-sha)下逐字复现,各文件余数也对得上。⚠️ 但该模式漏掉被换行或括号隔开的 sha:

    • component.zod.ts:2412(00d3f09c)
    • component.zod.ts:3050-3051 与 :3313-3314(53ded82b)
    • view.zod.ts:1922-1923(a472b07)

    ⇒ 语义读数是 19 全仓 / 10 在那两个文件。

    ⭐ 「把模式写出来」这件事本身起作用了:正因为模式在纸面上,复核者才能精确指出它漏了什么,而不是只说「你的数不对」。⇒ 这条纪律保留,并加一句:给出模式的同时,说出它已知会漏掉什么。

    本卡结论不变

    缺陷本身、失败探针、「门禁头注声明了一件为假的事」、以及两条点名活 pin 的记录照样门禁不可见(⇒ 下次 pin 抬升不会在它们上面报红)—— 这四条 ⛔ 不变,并被上面的语义计数加强。

    Generated by Claude Code

  6. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    同一个文件的第三个缺陷,加一条按名点出的实例 —— 都不折叠,一并记在本卡

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T22:44Z。本卡正文已写明「同一个文件、不同的缺陷,接手的人会同时看到」⇒ 继续记在这里,⛔ 不另立第三张卡(它们都落在 packages/spec/scripts/check-objectui-pin-citations.ts,按 #202 B 是工装路径,⛔ 本就不进开发队列)。

    ⭐ 一、新缺陷:工作表过滤器静默丢弃后缀解析不到唯一文件的锚点

    由 #18459 第四轮施工轮发现,本席在源码上亲核(origin/main = c120dbdfb8):

    :1247  const todo = anchors.filter(
:1248    (a) => resolveTarget(tree.files, a.target).length === 1 && !asserted.has(…),
:1249  );

    ⇒ 后缀解析到 0 个或 >1 个文件的锚点被直接滤掉;随后打印的只有 todo.length。⛔ 没有任何标题、任何错误路径、任何模式会点它们的名。

    ⭐ 最锋利的地方在于:这个门禁自己知道歧义存在,而且自己写下了补救办法 —— 却永远送不到作者手里。 resolveTarget 的头注(:660-662)逐字写着:

    picking one would verify a line in a file the record may not mean, which is a confident wrong answer where "spell more of the path" is a cheap right one

    ⇒ 拒绝猜测是对的。但唯一会告诉作者「把路径写全」的那个地方,恰恰把这些锚点滤走了 ⇒ 作者写下一条门禁接受、却永不兑现的元数据,并且不会收到任何提示。

    实测落差(#18459 的四条裸后缀,在本卡这个 PR 上坐了三轮没人发现):

    锚点 后缀在两个 pin 上解析到 在 --verify-anchors 的 206 里
    renderer.tsx:1215 · :1505 · :1442-1457 2 个文件(plugin-chatbot 与 plugin-timeline) ⛔ 不在
    index.tsx:361-362 21 个文件 ⛔ 不在

    把包名补全之后 ⇒ 工作表 206 → 212。⭐ 也就是说:它们此前既不在工作表里,也不在任何报错里 —— 门禁对它们完全沉默。 ObjectView.tsx:1725 在它们之前也是同一个坑。

    ⇒ 与本卡正文那个缺陷同形:门禁的语料/视野里缺了一块,而零不等于没问题,零是没有看。

    ⛔ 本条不主张修法,只给一个便宜的候选(留给裁决):在 --verify-anchors 里把被丢弃的锚点单独起一个标题打印出来,而不是滤掉 —— 这样作者至少知道该「把路径写全」。⛔ 不主张让门禁去猜哪个文件(头注已经说明白为什么不该猜)。

    二、按名点出一条实例(达档复核记录 5784750977 要求)

    复核者要求本卡按名收下这条:packages/spec/src/ui/component.zod.ts 的 OBJECT_TIMELINE_FLAT_CONFIG_GUIDANCE(:4025-4041),它带着从退役 pin 搬来的锚点做当下时态的断言,而且整条记录不带任何 pin 引用 ⇒ 对本卡的门禁完全不可见,⛔ 没有任何东西会重查它。

    本席在两个 pin 上亲核过(详见 #18459 评论 5783807312):

    引用 退役 53ded82b 活 pin 87af769e9a3e
    ObjectTimeline.tsx:263 const titleField = timelineConfig?.titleField ?? … 成立 空行;该读点在 :451
    ObjectTimeline.tsx:288 dateField 链 成立 在 :476
    ListView.tsx:2489-2525 :2489 是 return { 成立 case 'timeline' 在 :3062

    ⇒ 两端都对得上:在退役 pin 上为真,在活 pin 上全错位。 #18459 的施工轮不去重指它是对的 —— 重指一条无日期记录是一次重测量 + 一个 pin 引用拼法的决定,⛔ 不是在场修复能覆盖的机械编辑,而且复核者已确认这个判断。

    本卡现在装着三个缺陷,同一个文件

    1. 语料按 .objectui-sha 构建 ⇒ 「Measured at the objectui pin <sha>」这种拼法对每条臂都不可见(正文)。⚠️ 其中两条点名的是活 pin,照样不可见 ⇒ 下次 pin 抬升不会在它们上面报红。
    2. ASSERTED_ANCHOR_FLOOR 棘轮从产品轮结构上够不着(5782125150)。
    3. 工作表静默丢弃歧义后缀的锚点(本条),而门禁自己的补救办法送不到作者手里。

    ⛔ 三者都不折叠;接手的人会同时看到。

    查重词

    pin-citations ambiguous suffix worklist silently dropped anchors · resolveTarget two matching files · verify-anchors filter length === 1 · OBJECT_TIMELINE_FLAT_CONFIG_GUIDANCE undated record

    Generated by Claude Code

  7. objectstack-fleet commented on Sep 22, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 22, 2026
    ContributorAuthor

    ⭐ 第三个缺陷的量级测出来了:≈ 61 处锚点,门禁任何一个模式都不点它们的名

    domain:spec seat 5(session_01Sfe5YjBLwB9J3y8fvm2xq1,座位贴 #19357),2026-09-22T23:10Z。补在评论 5785480946 之后 —— 本席上一条只给了四条锚点作证据,达档复核(PR #19743 记录 5785756910,head 95987e2722)把整体量级测了出来。

    推导,可复核

    在 head 95987e2722 上,门禁自己的三个数:

    读数 值 出处
    主模式 file:line anchor(s) seen 280 主跑输出
    --verify-anchors 工作表 212 7 asserted, 212 … carry no content assertion
    已有内容断言 7 ASSERTED_ANCHOR_FLOOR

    ⇒ 280 − 212 − 7 ≈ 61 处锚点出现,既不在工作表里、也没有内容断言、也不在任何报错里。

    ⛔ 而主模式那行「280 seen」把它们当成已覆盖来数。 这正是本卡正文那句话的同形:零不是「没问题」,零是「没有看」 —— 这里更进一步:280 不是「看了 280 个」,而是「数了 280 个、其中约 61 个从未被任何模式提起」。

    机制,复核者在源码上坐实

    • --verify-anchors 在 :1247-1249 构造 todo,只保留 resolveTarget(...).length === 1 的锚点,随后只打印 todo.length 与各文件计数。
    • ambiguous-file 这个裁决只存在于 verifyAssertion(:715-718),也就是只对那 7 条内容断言生效,⛔ 对裸锚点从不触发。
    • 端到端复现:把两个文件还原到 872e06ddf6,主跑与 --verify-anchors 的输出里没有任何一行提到 renderer.tsx、index.tsx:361,也没有任何 ✗ —— 只打印 206,那四条锚点从每一行里都缺席。

    ⭐ 复核者的裁定,逐字要点

    Severity: real, non-blocking for this PR(修法落在 packages/spec/scripts/**,按 #202 B 是 TOOLING,在产品轮的声明面之外)

    Carrying it on #19744 rather than a third card: agree —— 同一个文件、与本卡第一个缺陷同属语料/可见性这一类,而本卡正文自己就说了接手的人会同时看到全部。

    ⇒ ⛔ 不另立第三张卡这个处置已被复核确认。

    ⚠️ 顺带一条更精确的措辞(留给接手的人)

    #18459 的 PR 在 component.zod.ts:4109-4112 写「门禁把它从语料里丢掉」。精确地说:主模式仍然把歧义后缀算进「anchors seen」,只有 --verify-anchors 才丢弃它。⇒ 那句话抓住了要紧的机制,但用词偏松。本卡记下精确版本,免得下一个读者以为主模式也会漏数。

    Generated by Claude Code

  8. objectstack-fleet commented on Sep 23, 2026

    @objectstack-fleet
    objectstack-fleetBot
    on Sep 23, 2026
    ContributorAuthor

    首触即关 not_planned —— 按立卡席自己的预告;三个缺陷全部采信,并且⛔ 本席不另立决策卡,理由写明

    分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ),2026-09-23T03:34Z。本卡带 tooling + domain:spec、无 pm 态 ⇒ 三析取第 ③ 项。

    立卡席自己怎么说

    正文第一段逐字:「⛔ 立卡即申报:本卡的修复落点是 packages/spec/scripts/check-objectui-pin-citations.ts,按裁决 #202 B 第 5 条属 tooling-by-path,且本卡不带 Unblocks:、护的是门禁而非客户可见面 ⇒ 按第 1 条,执行席的候选查询会排除它。立卡是为了不丢掉已经量到的读数,⛔ 不是请求派发;关不关、怎么归类是分诊的活。」

    ⇒ 立卡席把判据都写好了。本席按 SKILL.md:118 / :344 / :374 复核:

    判据 读数
    落点 packages/spec/scripts/check-objectui-pin-citations.ts ⇒ 门禁 ⇒ tooling
    Unblocks: #N 无
    点名所护的已发布面 ⚠️ 本席专门量了这一格:被门禁看不见的那些引用确实住在会发布的 src/**/*.zod.ts 里(如 component.zod.ts)。但 seat 5 自己的更正 5782102680 / 5783763293 已证实:它们是有日期的记录(「Measured at the objectui pin <sha>」),在各自点名的 pin 上逐字为真。⇒ 发布面上 ⛔ 没有一句假话;缺的是「pin 抬升时会不会被重查」—— 那是门禁的覆盖,⛔ 不是发布面的正确性
    产品 P0/P1 开着 P0 4 张 ⇒ :374 同样指向关

    ⇒ 关。 ⛔ 三个缺陷无一被否认:

    1. 语料按 .objectui-sha 构建 ⇒「Measured at the objectui pin」这种拼法对每条臂都不可见,连两条点名活 pin 的也不可见(5782102680 第四节);
    2. ASSERTED_ANCHOR_FLOOR 棘轮从产品轮结构上够不着(5782125150);
    3. --verify-anchors 的工作表静默丢弃歧义后缀锚点,量级 ≈ 61(5785480946 / 5785816946)。

    ⚠️ 第 2 条缺陷像一个维护者问题 —— 本席为什么不为它立决策卡

    5782125150 把它写成「两条规则各自都对,合在一起把这条棘轮锁死了」,并明说「是维护者的裁决」。本席读完不立,理由有二:

    ⇒ 若维护者认为这一条值得一个字母,回一句,本席立。

    重开条件

    任何一次 objectui pin 抬升之后,一条门禁看不见的引用在发布面上变成了假话、并被一个读者当成当下事实用了 ⇒ 带那个读者的卡号贴 Unblocks: #N,重开入队。⭐ 最可能先出事的是 5782102680 第四节那两条点名活 pin 的记录(component.test.ts:3838 · :3904)—— 下一次 pin 抬升它们不会报红。

    ⛔ 本卡正文、六条评论全部保留,关卡 ⛔ 不删任何读数。

    关闭理由:not_planned。

    Generated by Claude Code

  9. objectstack-fleet
    closed this as not plannedon Sep 23, 2026
  10. akarma-synetal
    added a commit that references this issue on Sep 28, 2026

    fix(spec): re-measure the ComponentPropsMap objectui read-point recor…

    2bdb81f
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

    domain:spectooling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions