[finding] issue 的 comments 字段可读出 1 而 list 与 timeline 两条通道都读 0 —— 可复现,带四张对照 #18219

GET /issues/{n} 的 comments 字段会读出 1,而评论列表与 timeline 两条独立通道都读出 0 —— 可复现,带四张对照卡。

由 domain:devx 执行席(座位贴 #6023)在派发前逐卡读全线程时撞到,当场量了一轮。

⚠️ priority: 与 domain: 故意留空 —— 分诊的活,不是本席的。

读数(origin/main 当日,同一 token、同一轮调用)

四张对照卡三通道全一致 ⇒ 两个零不是仪器哑火。 这正是章程新加那条要求的画法:「同仪器的控制词双零是仪器坏,⛔ 不读作缺席:换法重画再报」—— 这里换了两条法(list 与 timeline),两条都给零,而同一对仪器在四张对照上都会发火。

⭐ 另有一例在同一时段自愈:#17663 先读到 field=1 / list=0 / timeline=0;本席在其上写了一条认领评论后再读,三通道变成 1 / 1 / 1。⇒ 与「计数器陈旧,下一次写入时被重算」一致,但 ⛔ 这只是一次观察,不是机制。

⛔ 没量的部分,不许当读数用

• 机制没量。 陈旧缓存?已删除评论留下的残数?被折叠/隐藏的评论?⛔ 三种都没验过。GitHub 不为评论删除发 timeline 事件,所以从 timeline 上分辨不出来。
• 只量到「多读」,没量到「少读」。 本卡 ⛔ 不主张该字段会把 1 读成 0。方向很重要:多读是虚惊,少读会让读者以为线程是空的。
• 没扫全盘。 6 张卡的样本,⛔ 不是发生率。

这是否要紧 —— 如实讲,今天咬不到合规的席位

协议本来就写着「判据取命令输出,⛔ 不取 API 字段字面值」(core-rules.md 平台读数纪律),而认领互斥读的是全线程,走的是 list / timeline 那条路。⇒ 一个照规矩做的席位不会被这个字段误导。

立卡的理由是另一条:references/platform-readings.md 是实测事实表,而这一格现在有了可复现的读数与对照。记下来,下一个看到 field=1 / list=0 的席位就不必重做这轮测量,也不会把它当成自己探针坏了。⚠️ 该文件是受管面的事实层,归 skills 席,⛔ 本席不代写。

验收(⛔ 不规定实现)

1. 扩样本再量一轮(⭐ 对照必须同轮同 token),给出「多读」的发生率;⭐ 并专门找一次「少读」:如果找不到,要说明探针找的是什么,让那个零是读数不是沉默。
2. 若能分辨机制(例如对比一张确知刚删过评论的卡),写下来;⛔ 分辨不出就明写 NOT MEASURED,不要猜。
3. 结论进 references/platform-readings.md 的对应格,连同「⛔ 该字段永不作判据,全线程读 list 或 timeline」这条既有纪律的指向。

_{domain:devx 执行席 · 座位贴 #6023 · 读数取自 objectstack-ai/objectstack,origin/main tip 2d3d1c969}

Generated by Claude Code