[Decision] 一份提交式普查产物,漂移得比人工合并还快 —— 采纳兄弟门禁已有的「强制/不强制」拆分?
出处. 由 domain:devx 席(座位贴 #6023,session session_01Pk26oZ12t5N1hwGW1m1MgC)于 R33 上呈,携带 #13548 / PR #13584 的实测。⛔ 一行未实现。 三条要点原样取自该 PR 的 dev,本席核过判据后转呈。
一句话问题
.claude/** 命中 ⇒ 治理面 ⇒ 人工合并(小时级);漂移门禁要求产物匹配 HEAD(分钟级)。两者不可同时满足。
⚠️ 而合并队列不是出路:它对着当前 main 重建并重跑检查,但不重新生成产物 —— 陈旧的普查在队列里同样被踢出。
实测:PR #13584 在 50 分钟内红了两次,第二次连 population 都动了。
实测数据(origin/main 最近 60 个非 merge 提交)
| 提交能… |
占比 |
移动 sources scanned |
25% |
| 触到含写调用点的文件 |
15% |
| 真正移动写调用或其 context |
7% |
| 触到语料但不含任何站点文件 —— 纯规模抖动 |
10% |
⇒ 40% 的「可致漂移」提交根本不可能改变 population。 第一次漂移正是这一类:一个必需门禁,为一个没有任何安全内容的数字变红。
兄弟门禁已经解决过这件事
scripts/check-system-context-census.mjs 把普查推导数(强制)与全语料文本数(在场且注明日期,⛔ 不强制)拆开,并在自己的头注里给出理由(已核,:77-84):
"a set of numbers about a population the page does not certify — and whose churn, measured, was blocking the page from ever landing."
⇒ #13548 继承了它的锚点方案,没有继承这一半。
⛔ 一条看起来对、实则错的修法(本席提过,已被证伪)
本席曾建议:让门禁对记录的基线 sha 断言,而非活的 HEAD。错的。 兄弟头注 :30 直接反驳:
"a gate that only checks what the page already says can never find what the page failed to say."
⇒ 把门禁钉在一个没人复核的 commit 上,它就再也回答不了「新来了一个写调用点而没有任何文档记录它」—— 那正是 #13178 的形状。它不消除陈旧,它消除警报,并且带着一个绿勾。
四维分析
1 — 实际业务需求。 这份产物记录的是租户审计写入面:215 个写调用点、97 个可判定提权、9 个可证明缺租户上下文。是安全相关的。⇒ 让它落不了地,等于让这份记录不存在;而让它假绿落地,等于让它撒谎。两个失败方向都真实。
2 — 平台长远合理性。 产物里装着两种波动率完全不同的东西,而门禁用同一个标准管它们:population(安全相关,7% 提交会动)与规模数(出处性质,25% 会动)。⇒ 拆分不是放宽,是把标准对准它该管的东西。⭐ 而且这不是新设计 —— 兄弟门禁已经这么做,理由白纸黑字。
3 — 避免 AI 写代码犯错。 ⭐ 本卡最该记的一条:本席给 dev 的"诚实选项"是错的,它会用一个安静的错警报换掉一个吵闹的对警报。dev 拒绝了 PM 递过来的方案并给出反驳 —— 这条路径能走通,比这次的技术结论更重要。⇒ 任何修法都必须先答:它还能不能发现"页面没说的事"? 答不上就是 (b) 的变体。
4 — 创业阶段不扩散需求。 拆分零新增机制:复用兄弟门禁的既有形状,不加标签、不加 sweep、不加门禁。⚠️ 但要诚实:它必要而未必充分 —— 剩下 7% 仍会动 population,按本仓节奏约每日一次,而治理面的人工合并窗口长于此。
三条候选
- A —— 采纳兄弟门禁的强制/不强制拆分。(dev 与本席同荐)移除 40% 的可致漂移提交,即那一类纯噪声;有先例;⛔ 不削弱任何一条安全相关断言。
- B —— 记录基线 sha。 ⛔ 已被证伪,见上。列出仅为存档,免得下一个人再想一遍。
- C —— 由 CI 生成并提交这份产物,而不是由作者。 ⚠️ dev 明确拒绝猜测这一条:它改变谁拥有这个数字,是治理判断,不是工程判断。
⚠️ A 与 C 不互斥,很可能应当同时考虑:A 去掉噪声,C 解决剩下 7% 的调度问题。
⛔ 本席的边界
⛔ 不代裁:C 触治理归属,A 改一个必需门禁的强制面 —— 都在人工地板。上面是数字与建议,不是裁决。
Refs: #13548 / PR #13584(实测与两个分类器缺陷)· check-system-context-census.mjs:30, :77-84, :434-441(先例与反驳)· #13591(新增 content/docs/ 页面必然使 PR 变成人工合并)· #13178(本类记录最初要治的失败)
Generated by Claude Code
[Decision] 一份提交式普查产物,漂移得比人工合并还快 —— 采纳兄弟门禁已有的「强制/不强制」拆分?
出处. 由
domain:devx席(座位贴 #6023,sessionsession_01Pk26oZ12t5N1hwGW1m1MgC)于 R33 上呈,携带 #13548 / PR #13584 的实测。⛔ 一行未实现。 三条要点原样取自该 PR 的 dev,本席核过判据后转呈。一句话问题
.claude/**命中 ⇒ 治理面 ⇒ 人工合并(小时级);漂移门禁要求产物匹配 HEAD(分钟级)。两者不可同时满足。实测:PR #13584 在 50 分钟内红了两次,第二次连 population 都动了。
实测数据(
origin/main最近 60 个非 merge 提交)sources scanned⇒ 40% 的「可致漂移」提交根本不可能改变 population。 第一次漂移正是这一类:一个必需门禁,为一个没有任何安全内容的数字变红。
兄弟门禁已经解决过这件事
scripts/check-system-context-census.mjs把普查推导数(强制)与全语料文本数(在场且注明日期,⛔ 不强制)拆开,并在自己的头注里给出理由(已核,:77-84):⇒ #13548 继承了它的锚点方案,没有继承这一半。
⛔ 一条看起来对、实则错的修法(本席提过,已被证伪)
本席曾建议:让门禁对记录的基线 sha 断言,而非活的 HEAD。错的。 兄弟头注
:30直接反驳:⇒ 把门禁钉在一个没人复核的 commit 上,它就再也回答不了「新来了一个写调用点而没有任何文档记录它」—— 那正是 #13178 的形状。它不消除陈旧,它消除警报,并且带着一个绿勾。
四维分析
1 — 实际业务需求。 这份产物记录的是租户审计写入面:215 个写调用点、97 个可判定提权、9 个可证明缺租户上下文。是安全相关的。⇒ 让它落不了地,等于让这份记录不存在;而让它假绿落地,等于让它撒谎。两个失败方向都真实。
2 — 平台长远合理性。 产物里装着两种波动率完全不同的东西,而门禁用同一个标准管它们:population(安全相关,7% 提交会动)与规模数(出处性质,25% 会动)。⇒ 拆分不是放宽,是把标准对准它该管的东西。⭐ 而且这不是新设计 —— 兄弟门禁已经这么做,理由白纸黑字。
3 — 避免 AI 写代码犯错。 ⭐ 本卡最该记的一条:本席给 dev 的"诚实选项"是错的,它会用一个安静的错警报换掉一个吵闹的对警报。dev 拒绝了 PM 递过来的方案并给出反驳 —— 这条路径能走通,比这次的技术结论更重要。⇒ 任何修法都必须先答:它还能不能发现"页面没说的事"? 答不上就是 (b) 的变体。
4 — 创业阶段不扩散需求。 拆分零新增机制:复用兄弟门禁的既有形状,不加标签、不加 sweep、不加门禁。⚠️ 但要诚实:它必要而未必充分 —— 剩下 7% 仍会动 population,按本仓节奏约每日一次,而治理面的人工合并窗口长于此。
三条候选
⛔ 本席的边界
⛔ 不代裁:C 触治理归属,A 改一个必需门禁的强制面 —— 都在人工地板。上面是数字与建议,不是裁决。
Refs: #13548 / PR #13584(实测与两个分类器缺陷)·
check-system-context-census.mjs:30, :77-84, :434-441(先例与反驳)· #13591(新增content/docs/页面必然使 PR 变成人工合并)· #13178(本类记录最初要治的失败)Generated by Claude Code