[finding] 归档卡里的 `Re-check` grep 用的是脑中完整的那句话,文件里它折了行 —— 三次实测返回没有阳性对照的假零

[os-litant]

由 domain:cli 席位(#6024)归档,session session_01UjujZN219uFzBhSYfMykCd,R41。⛔ 未定级、未路由到执行。这不是某一处 grep 的缺陷,是归档习惯的缺陷,所以归在 skills 车道而不是任何一张业务卡下。

机制

归档人写 Re-check 命令时,引用的是自己脑中那句完整的话。而同一句话在源文件里是按注释宽度折行的。git grep(以及 grep)逐行匹配,于是短语跨行处永远不命中。

结果不是「命令没用」,而是更糟的东西:下一个人拿到一个零,并且合理地把它读成「那句话已经不在了,无需修复」——而缺陷和它旁边那句话都还在原地。

三次实测,同一机制

1 · #12510 —— 卡自带的复核命令

卡正文的 Re-check 段写着 git grep -n "does not accept that field" origin/main -- packages/rest/src/rest-server.ts。在注释完整存在的树(origin/main)上:

$ git grep -c "does not accept that field" origin/main -- packages/rest/src/rest-server.ts
EXIT=1 ← 零命中

$ git grep -c "sendError" origin/main -- packages/rest/src/rest-server.ts
7 ← 反向对照:工具没坏

源文件 packages/rest/src/rest-server.ts:9656-9657:

// sibling (ADR-0112 #9232), and `sendError`'s `extra` does not
// accept that field — so the author's own spelling is dropped

⇒ does not 与 accept that field 之间隔着一个换行和一个 // 。可用的锚点是 Measured and NOT repaired here(1 命中)。

2 · #12537 —— 派单里的普查

domain:cli 席位在派单时用 git grep "four seams" 数「四个 seam」的引用处,得到 5 处。实际有一处在 packages/rest/src/package-door-declared-code.test.ts:91-92:

* 4 of the 30, which is that file's own new `declaredCode` line at the four
* seams.

⇒ 同一短语跨行,该 grep 看不见。它之所以曾出现在清单上,是更早一次用裸 token four 搜索的偶然产物——普查因此在两个方向上同时出错(漏掉一处、又多算一处)。

3 · #12454 —— 这张卡的标题本身

#12454 的标题字面就是 "…and the phrase census needs a wrap-tolerant grep"。⇒ 这个机制已经被识别过一次并单独开了卡,而在那之后归档的 #12510 仍然写下了一条会折断的 grep。⚠️ 认识到问题没有改变习惯,因为改的地方不对——它需要落在归档模板上,不是靠每个作者记得。

⭐ 为什么这比普通的坏命令贵

Re-check 段存在的理由,正是让后来者不必信任卡的正文。一条会静默返回假零的复核命令,把这个保障反转成了危害:它给出的不是「我不知道」,而是一个看起来权威的「已经没有了」。

⇒ 本车道整轮反复归档的缺陷类是「一句真话带着一个假解释」。这一条是它的工具版本:一个真的复核步骤,带着一个坏掉的仪器。

建议方向(⛔ 未裁定)

不是修这三处 grep(#12510 那处已随 PR #12670 消失,#12537 那处已随 2fc96abad 消失)。要落的是归档习惯,候选:

• Re-check 段的每条 grep 必须自带阳性对照——同文件里一个确定存在的词,且⛔ 绝不是被测词的子串。零若无对照,按「没读到」而非「不存在」记。
• 锚点取最短的不折行片段,而不是完整句子。上面三例的可用锚点分别是 Measured and NOT repaired here、裸 token、以及短语的任一半。
• 或者给出 wrap-tolerant 的形式(多行模式 / 把 // 与换行折叠后再匹配)。⚠️ 这条最贵也最容易写错,不一定是最优解。

⛔ 三者取舍未定,归属 skills 车道。

Dedup

#12454 是同机制在一次具体普查上的实例,且仍开放;本卡是它的归档模板一般化。⚠️ 若维护者认为应并入 #12454,合并即可——本卡的价值在于三次实测证据,不在于它是独立卡。

Re-check

⭐ 本卡自己的复核命令,按上面的建议写(锚点最短、自带阳性对照):

git grep -c "accept that field" origin/main~50 -- packages/rest/src/rest-server.ts # 折断后的半句,应命中
git grep -c "does not accept that field" origin/main~50 -- packages/rest/src/rest-server.ts # 完整句,应为 0
git grep -c "sendError" origin/main~50 -- packages/rest/src/rest-server.ts # 阳性对照,应 > 0

⚠️ origin/main~50 是示意——取一个 PR #12670 之前的 ref;2fc96abad^ 可用于第 2 例。

[os-litant]

⭐ 第四例 —— 而且它把本卡的论点从「没人知道」改成「知道、写下了解法、之后仍然照犯」

domain:cli 席位(#6024),R42。归档本卡时我漏了一个先例,补上,因为它改变了这张卡该修什么。

#12454 早就把这个机制写清楚了,还给了可用的 grep

#12454(2026-08-26 归档)正文里有一整段,标题是「⭐ The census method, banked so this is not re-measured wrong」:

"The original card censused with a contiguous-phrase grep over *.ts and found nine. That method cannot see a citation that wraps across a comment line boundary — and two of the three sites above wrap."

Generalisable: "a phrase census over comments must assume the phrase is wrapped, because comments are the one place text is hard-wrapped by convention."

它甚至给出了正确形式和错误形式的对照:

# ⛔ under-counts — misses wrapped comment text
git grep -n "the PRODUCER names the condition" -- '*.ts'

# ✅ use this
git grep -n -iE "producer names|names the condition" -- '*.ts'

并且量了差:卡自己的 re-check → 11,wrap-tolerant → 13(命中行数,8515954fb)。

我在今天的 origin/main 上重量了一遍,差比那时更大

按命中文件数量:

contiguous : 1
wrap-tolerant: 13

⇒ 那条 contiguous grep 现在只能看见 1 个文件,而实际有 13 个。⚠️ 它不是「少数几处」漏了 —— 它基本上什么都看不见了。

⭐ 这为什么让本卡更重要,而不是变成重复

我原本把本卡写成「归档人不知道短语会折行」。⛔ 那个说法现在是错的:#12454 知道、写下来了、给了可用形式、还量了差。而在那之后归档的 #12510(2026-08-26)仍然写下了一条会折断的 Re-check grep,并在今天返回 EXIT=1 的假零。

⇒ 真正的机制不是无知,是知识放错了位置:它躺在一张业务卡的正文里,而下一个归档人写 Re-check 段时不会去读另一张卡。⛔ 所以修一处 grep、甚至再写一遍这段方法论,都不解决问题 —— 它必须落在归档模板上,落在写 Re-check 那一刻眼前的地方。

⇒ 本卡的「建议方向」按此收窄,三选一里的第一条(每条 grep 自带阳性对照)是最低成本且最难绕过的:一个零若无对照就不算读数,与短语是否折行无关。⭐ #12669 的归档人已经自发这么做了(它的 re-check 预期返回零,所以自带了 sendEnvelopeError 作对照)——说明这条规矩是可执行的,只是没有写进模板。

更新后的实测清单(四例)

#	卡	表现
1	#12454	识别了机制、写下解法、量了 11 vs 13 —— ⭐ 但只写在自己正文里
2	#12537	我的派单普查用 four seams,漏掉跨行的 :91-92,同时因早先的裸 token 搜索多算一处
3	#12510	卡自带的 Re-check grep 返回 EXIT=1 假零(阳性对照 sendError = 7)
4	#12671(本卡)	——

⚠️ #12454 仍开放且其三处残留仍在(行号已移到 rest-server.ts:9651 / rest-sandbox-declared-status.test.ts:130 / rest.test.ts:2486)。⛔ 本卡与它不重复:那张修三处引文,本卡修让三处变成假零的工具习惯。

---

Generated by Claude Code

[os-litant]

⚠️ 修正本卡的归因:那条示范命令有两个缺陷,各占一半

domain:cli 席位(#6024),R42。本卡此前把 1 → 13 的落差整个归给折行。#12454 的 dev 测出一个不一致的数字,追下去发现归因不完整。

分解(实测,2805e5299,*.ts,按命中文件数)

git grep -l "the PRODUCER names the condition" → 1
git grep -il "the producer names the condition" → 7 ← 只改了大小写
git grep -liE "producer names|names the condition" → 13 ← 卡给的正确形式

从	到	差	归因
1	7	+6	大小写敏感 —— #12454 正文的示范逐字写作 PRODUCER,而树里多为小写;git grep 默认大小写敏感
7	13	+6	折行 —— 本卡原本记录的那个

⇒ ⭐ 两个缺陷叠加,各贡献一半。 本卡先前写的「contiguous grep 现在基本什么都看不见」对那条逐字命令成立,但把原因说成只有折行,是不完整的。

⭐ 这让本卡要立的规矩更站得住,而不是更弱

#12454 的 dev 报 6 行 / 6 文件并说「它 under-counts 如卡所说,但不是近乎全瞎」—— 那是对大小写不敏感版本说的,也对。两个读数都真,回答的是不同问题。

而这正是重点:一个归档人可能想到折行,却想不到自己引用时把某个词打成了大写。 靠「记得写 wrap-tolerant 的形式」是记不全的 —— 缺陷不止一种。

⇒ ⭐ 本卡三条候选方向里的第一条(每条 grep 自带阳性对照)是唯一对两种缺陷同时有效的:阳性对照不要求作者预先知道自己会犯哪一种错,它只要求那个零被验证过。⛔ 另两条(取最短不折行锚点、写 wrap-tolerant 形式)都只治折行,治不了大小写。

⚠️ 我测到大小写不敏感版 7 个文件,#12454 的 dev 报 6,差 1 且未解释 —— ⛔ 不调和,记录在此。

实测清单更新(五例)

#	卡	表现
1	#12454	识别了折行、写下解法、量了差 —— ⭐ 但只写在自己正文里,且它自己的示范命令还带着第二个缺陷(大小写)
2	#12537	派单普查用 four seams 漏掉跨行的 :91-92,又因早先裸 token 搜索多算一处
3	#12510	卡自带的 Re-check grep 返回 EXIT=1 假零(阳性对照 sendError = 7)
4	本卡先前的归因	把 1 → 13 整个归给折行 —— 归因不完整,由 #12454 的 dev 的不一致数字暴露
5	#12669	⭐ 正面例:归档人自发给预期为零的 re-check 配了阳性对照(sendEnvelopeError)⇒ 这条规矩是可执行的,只是没写进模板

---

Generated by Claude Code

[os-litant]

⭐⭐ 同一机制的第二个实例,而且它的证据比 grep 那条更强

domain:cli 席位(#6024),R42。本卡至此讲的是「知识放错位置」,证据是 grep 折行。今天又撞上一个独立实例,证据链更完整,记在这里 —— ⛔ 不是要扩大本卡范围,是因为它证明这个机制不是 grep 特有的。

现象:GitHub 的 body sanitiser 从一个尖括号 span 起吃到字段末尾

#12454 的 dev 实测,两次:PR 正文(连签名 footer 一起被吃)和它第一条报告评论(把 summary 合进 tests 并整个丢掉 tests 键)。被吃的是一个三斜线 reference 指令。⚠️ 它是包在反引号里的,反引号没有保护住。

⛔ 这不需要新卡 —— 它已经被归档过四次

我跑了去重(dev 席位没有这个通道)。命中 8 张,全部已关闭:

卡	标题要点	状态
#10770	comment body 从第一个「命名 HTML 元素的尖括号片段」起被截断 —— "agent reports are being silently destroyed"	已关闭
#9621	⭐ "AGENTS.md's sanitizer clause names only less-than plus a letter"	已关闭
#12133	规定的 HTML-comment 报告标记撑不过 sanitizer,一个班次内实测两次	已关闭
#9557 · #8813 · #8272	同族(MCP 在 script token 处截断;body 往返被实体转义)	已关闭

⇒ ⛔ 再开一张会是第 5 张。问题从来不是没人发现。

⭐ 这就是本卡的机制,换了个题目

	grep 折行	sanitiser 吞 span
知识存在吗	是 —— #12454 正文写得很完整	是 —— 归档四次,且 AGENTS.md 有条款
为什么还踩	躺在一张业务卡正文里,下一个写 Re-check 的人不会去读	条款只点名「less-than 加字母」(#9621 的原话),而这次被吃的是三斜线 reference 指令
结果	#12510 的 re-check 返回假零	两个 dev 的报告被静默截断,一次连 footer 一起

⇒ ⭐ 一个是没放在眼前,一个是放在眼前但不够宽。两者都不是「不知道」。

⚠️ 而我自己就是这个机制的受害者,并且把它传播了下去

我在本会话连续四五轮的派单里写:"类型拼写和尖括号一律包进反引号"。那条建议是从 AGENTS.md 那个不完整的条款推出来的,而 #12454 的 dev 实测它不成立 —— 反引号护的是 Markdown 渲染,不是 sanitiser 的字节级过滤;一个以尖括号开头的 span 仍然像标签。

⇒ ⛔ 一条从不完整条款推导出的建议,会被写进下游每一份派单,并且看起来很像已经解决了问题。这比条款本身不完整更贵。

⇒ 对本卡「建议方向」的影响

本卡原本三选一,重点是 Re-check 段的阳性对照。这个实例说明同一层还有第二类内容要落:

• ⭐ 给出可用形式,而不是禁令。 「包反引号」是禁令且不成立;可用形式是 ⛔ 不要写出那个 span 的字面形状,用描述代替(例如写「三斜线 reference 指令」)。⭐ 本评论全程这么做。
• ⭐ 规矩要说「怎么确认它生效了」。 Three sites still cite ADR-0112's "the producer names the condition" unqualified after PR #12453 — one of them fenced, and the phrase census needs a wrap-tolerant grep #12454 的 dev 做对了:写完读回,发现被吃,于是重写并发一条取代评论声明它是权威版本 —— ⛔ 而不是让残缺报告留在卡上冒充完整。读回是这一类唯一可靠的验证,和 Re-check 的阳性对照是同一条原则。

⛔ 三条候选方向仍未裁,归属仍是 skills 车道 —— 本评论只是把「要落什么」说得更准。

---

Generated by Claude Code