呈维护者裁决 —— skills 席(session session_019RfFHiRCSs3JXLK4cwcfox,os-steve),第 7 批,共 1 项(末批不足照呈)。裁后一行回批即可(「1A」/「1A, 但…」)。
1. platform-readings.md 满了:八条席位实测踩过的平台坑,补不进参考文件
一句话问题:八张卡各记录了一条席位在真实干活时踩到的 GitHub 平台坑(其中三张点名了那条缺失读数本可避免的事故);要把它们写进席位人人先读的参考文件,需要 34 行,而这个文件的行数上限已经顶满,文件内没有任何可删的东西来付账。
背景:.claude/skills/pm-dispatch/references/platform-readings.md 是各席位读平台行为的唯一参考,受行数棘轮约束(当前 324/324,余量 0;09-03 上午刚由维护者裁定的跨文件挪移把它从 314 抬到 324)。今天的 intake 家族飞行(链头卡 + 七张成员卡)把每条事实按文件口吻写出、按门禁真实预算(每行 120 字节,中文约 40 字)折行后实测:合计 +34 行;同一飞行找到的三处被后续实测推翻的旧说法已删(净 0 行,已作为草稿 PR 交出),但这三处散在三个段落里,删掉的字节凑不出一整行,按 2026-08-17「⛔ re-wrap 不得用作筹行」的裁定不能靠重排段落回收。派发时本席点名的最大候选支付项(计数墓碑段)实测是上午那次授权挪移的目的地,删它等于悄悄撤销一次已裁的落地 —— 本席派发词有误,已在卡上当众更正。
带 re-check 命令的前提:
- 上限与现状:
node scripts/pm/check-skill-line-ratchet.mjs | grep platform-readings → is 324 lines (ceiling 324; headroom 0)。 - 逐成员成本(dev 实写实折,非估计):链头 +5(422 上限与 asc/desc 分区读法)· payload 通道 +5 · 搜索查询形 +3 · 通道信封 +6 · 队列仪表 +8 · 队列进度 +2 · 班末报告 +3 · 正文修复 +2 = +34。
- 可付账的删减:0 行(三处删减合计约 307 字节,不成整行)。
- 已在文件里、只需引用不必重写的七条事实已去重(
mergeable_state unknown、auto_merge 非决策依据、is-ancestor 误用、SQUASH/merge 回显、反引号注释清洗、REST 403 + payload 读、双标签并集)。
选项 × 真实代价:
| 选项 | 做什么 | 真实代价(客户/席位可感知) |
|---|
| A 抬上限 +34(324 → 358) | 在棘轮脚本里按裁定逐字引用抬上限,同一分支落八条事实 | 每个席位每次通读参考文件多读约 34 行(约 10%);换来的是八条已实测的坑不再靠每个席位自己再踩一遍 |
| B 跨文件挪移付账 | 从别的参考文件净删 34 行来换 | 实测没有哪个文件有 34 行可删(rest-channel.md 88/88);硬挪等于拆掉另一份参考来喂这一份,读者两头都变差 |
| C 劈半落地 | 只落能在本文件内付账的成员,其余关卡「不记录」 | 本文件内付账能力为 0,等于挑选丢弃哪几条实测事实 —— 没有任何证据支持这种挑选;被丢弃的坑照常被下一个席位踩 |
| D 不落地 | 事实留在各自卡上,参考文件只保留已落的三处更正 | 每个新席位要从八张卡里各自重新发现这八条;三张卡点名的事故形态(去重查询构造错、claim 状态误读、合并落地误判)会重演 |
业务含义直译:A = 像给 runbook 加一章「我们踩过的坑」,一次写清,以后的人照读;B = 从别的章撕页来贴;C = 只写一半的坑,读者以为读全了;D = 每个新人自己再踩一遍。
四轴从业务立场论证:
- 项目长远合理性(≥50%):参考文件的长期终态是「席位读它就够了」,而不是「读它还得翻八张卡」。棘轮的本意是防止文件无限膨胀、保持可读,它自带的合法出口就是「有名有姓有尺寸的抬升 + 维护者裁定逐字引用」—— 今天上午
rest-channel 87→93、contract-review 60→65→68 都是这条出口。A 是缩小特例(把散落在卡上的事实收拢进唯一参考),不是扩大契约。 - 实际业务拉动(实测):八张卡都是席位在真实工作中取的读数,不是「读起来有用」;三张卡各自点名了一次真实事故。拉动是实测的、有名字的。
- 防 AI 犯错:文件今天还含有实测已推翻的说法(本飞行删了三处);缺失的八条正是替换它们的正确规则。不补,席位会继续照旧说法构造坏掉的去重查询、误读 claim 状态、把已落地读成没合 —— 静默错误,不是响亮拒绝。A 是收紧方向。
- 创业阶段不扩散:+34 行是内部参考文件的一次尺寸抬升,没有发布面、没有新契约键、没有永久维护义务(每行都是已实测的平台事实,过期时按同一棘轮删)。它是「八个席位各自重新发现同一件事」的最便宜替代。
推荐 + 回退 + 置信缺口:荐 A。回退 D(若维护者不愿抬升,宁可不写,也不劈半 —— C 是本分析最反对的选项:挑选丢弃哪几条实测事实没有证据)。本分析看不见的:① 这八条读数每班各被用到多少次(dev 实测的是尺寸,不是频率);② 一位中文更精炼的编辑能否把 34 行压到更少 —— dev 是按文件现有口吻写的,不是按最短写的,所以 34 可能是上界而非下界;若维护者愿意,可裁「A 但压到 ≤ N 行」。
裁后我会怎么执行(你不用管):A ⇒ 更正 PR(草稿,治理面,已请 os-zhuang / hotlong)照常人工合入后,同一分支派第二增量:棘轮脚本按本裁定逐字引用抬上限、八条事实落文件、成员卡以 Fixes 关卡,链头卡随之关闭;四张前朝 hold 卡按落地后的文件逐条核对证据再关。D ⇒ 成员卡按 not_planned 关闭并各自指向卡上的实测证据,三处更正照常落地。B/C ⇒ 按裁定字面执行并在轮报里报实测。
os-decision-facets
① 项目长远合理性:席位读一份参考就够,是缩小特例;棘轮自带的合法出口就是这种有名有姓的抬升(权重 ≥50%,荐 A)。
② 实际业务拉动:八条读数全部来自真实工作中的实测,三条点名了已发生的事故;零拉动的说法不成立。
③ 防 AI 犯错:不补则席位继续按已推翻的旧说法静默犯错(坏查询、误读 claim、误判落地);补上是响亮的正确规则,收紧方向。
④ 创业阶段不扩散:内部参考 +34 行,无发布面、无新契约键、无永久义务;是「八个席位各自重踩」的最便宜替代。
推荐:A(抬上限 +34,或「A 但压到 ≤ N 行」);回退 D;⛔ 不荐 C。
置信缺口:本分析看不见这八条读数每班的使用频率,也看不见更精炼的写法能把 34 行压到多少。
Generated by Claude Code
呈维护者裁决 —— skills 席(session
session_019RfFHiRCSs3JXLK4cwcfox,os-steve),第 7 批,共 1 项(末批不足照呈)。裁后一行回批即可(「1A」/「1A, 但…」)。1.
platform-readings.md满了:八条席位实测踩过的平台坑,补不进参考文件一句话问题:八张卡各记录了一条席位在真实干活时踩到的 GitHub 平台坑(其中三张点名了那条缺失读数本可避免的事故);要把它们写进席位人人先读的参考文件,需要 34 行,而这个文件的行数上限已经顶满,文件内没有任何可删的东西来付账。
背景:
.claude/skills/pm-dispatch/references/platform-readings.md是各席位读平台行为的唯一参考,受行数棘轮约束(当前 324/324,余量 0;09-03 上午刚由维护者裁定的跨文件挪移把它从 314 抬到 324)。今天的 intake 家族飞行(链头卡 + 七张成员卡)把每条事实按文件口吻写出、按门禁真实预算(每行 120 字节,中文约 40 字)折行后实测:合计 +34 行;同一飞行找到的三处被后续实测推翻的旧说法已删(净 0 行,已作为草稿 PR 交出),但这三处散在三个段落里,删掉的字节凑不出一整行,按 2026-08-17「⛔ re-wrap 不得用作筹行」的裁定不能靠重排段落回收。派发时本席点名的最大候选支付项(计数墓碑段)实测是上午那次授权挪移的目的地,删它等于悄悄撤销一次已裁的落地 —— 本席派发词有误,已在卡上当众更正。带 re-check 命令的前提:
node scripts/pm/check-skill-line-ratchet.mjs | grep platform-readings→is 324 lines (ceiling 324; headroom 0)。mergeable_state unknown、auto_merge非决策依据、is-ancestor误用、SQUASH/merge 回显、反引号注释清洗、REST 403 + payload 读、双标签并集)。选项 × 真实代价:
rest-channel.md88/88);硬挪等于拆掉另一份参考来喂这一份,读者两头都变差业务含义直译:A = 像给 runbook 加一章「我们踩过的坑」,一次写清,以后的人照读;B = 从别的章撕页来贴;C = 只写一半的坑,读者以为读全了;D = 每个新人自己再踩一遍。
四轴从业务立场论证:
rest-channel87→93、contract-review60→65→68 都是这条出口。A 是缩小特例(把散落在卡上的事实收拢进唯一参考),不是扩大契约。推荐 + 回退 + 置信缺口:荐 A。回退 D(若维护者不愿抬升,宁可不写,也不劈半 —— C 是本分析最反对的选项:挑选丢弃哪几条实测事实没有证据)。本分析看不见的:① 这八条读数每班各被用到多少次(dev 实测的是尺寸,不是频率);② 一位中文更精炼的编辑能否把 34 行压到更少 —— dev 是按文件现有口吻写的,不是按最短写的,所以 34 可能是上界而非下界;若维护者愿意,可裁「A 但压到 ≤ N 行」。
裁后我会怎么执行(你不用管):A ⇒ 更正 PR(草稿,治理面,已请 os-zhuang / hotlong)照常人工合入后,同一分支派第二增量:棘轮脚本按本裁定逐字引用抬上限、八条事实落文件、成员卡以
Fixes关卡,链头卡随之关闭;四张前朝 hold 卡按落地后的文件逐条核对证据再关。D ⇒ 成员卡按 not_planned 关闭并各自指向卡上的实测证据,三处更正照常落地。B/C ⇒ 按裁定字面执行并在轮报里报实测。os-decision-facets
① 项目长远合理性:席位读一份参考就够,是缩小特例;棘轮自带的合法出口就是这种有名有姓的抬升(权重 ≥50%,荐 A)。
② 实际业务拉动:八条读数全部来自真实工作中的实测,三条点名了已发生的事故;零拉动的说法不成立。
③ 防 AI 犯错:不补则席位继续按已推翻的旧说法静默犯错(坏查询、误读 claim、误判落地);补上是响亮的正确规则,收紧方向。
④ 创业阶段不扩散:内部参考 +34 行,无发布面、无新契约键、无永久义务;是「八个席位各自重踩」的最便宜替代。
推荐:A(抬上限 +34,或「A 但压到 ≤ N 行」);回退 D;⛔ 不荐 C。
置信缺口:本分析看不见这八条读数每班的使用频率,也看不见更精炼的写法能把 34 行压到多少。
Generated by Claude Code