Skip to content

[decision] 半状态巡逻的送法与形状:每天都在改的仪器靠「手工复制三个文件」分发,副本必然掉队——换成引用并把「写坏的」那半搬到写侧 #18471

Description

@hotlong

repo:cloud 执行席立卡,session session_01TAUTP6Yky8QWoHUAPDKNJQ,R38。维护者 2026-09-16 当面质疑 cloud PR #2317(「2 万行的 js」「重新开发是不是就不需要」)后要求落卡。 本卡落在 objectstack:修复落点是这里的 scripts/pm/**.github/,cloud 只是消费方。⛔ 执行席立卡不定级不路由。

触发

cloud 的 vendored check-half-states.mjs 落后上游三周 / 约 25 个提交,导致该板 38 条活半状态里 23 条完全不可见。刷新它的 PR(cloud#2317)diff 是 +23,959/−757,维护者由此发问。

实测(2026-09-16,我自己量的)

文件构成(objectstack origin/main,32,233 行):

行数 占比
注释/散文 16,473 51%
self-test 区块 ~10,060 31%
传输/渲染/CLI ~2,700 8%
谓词逻辑 3,036 9%

141 个导出谓词/辅助函数,中位 14 行,均值 22,最大 106。⭐ 控制词:我第一次用"下一个 export 开始才算上一个结束"去量,得出"某函数 12,547 行"的荒谬值;改成花括号配平才得到上表。非零读数不等于仪器正确。

改动频率(REST 按路径过滤,不受浅克隆影响):最近 100 次提交跨 2026-08-11 → 09-16,36 天里 30 天有改动(~83%),仅 09-16 当天就 ≥4 次。

送法已按自己警告的方式失败两次:workflow 头部写着 adopt list 到 2026-09-03 一直只写两个文件而脚本早就 import 了第三个 ——「the documented install was a patrol that could not start」,并留下「⛔ Do not shorten this list again from memory」。两周后它又短了四个(objectstack#18466)。

结论:两件事,可分别裁

① 把「写坏的」那半从巡逻搬到写侧

66 个 H 类可劈两半:

  • A 类·写坏的(H22 · H24 · H25 · H2 · H3 · H7 · H21…):写入落一半。⇒ 本该在写侧消灭。scripts/pm/label-write.mjs 已是雏形(取现集→只增删→写合并集→回读 diff);R38 用了十几次,零半状态。把所有状态转换收进一个写入器(标签+assignee+评论一口气写、回读验证),A 类基本不可能发生。
  • B 类·世界变了(H19 · H8 · H16 · H13 · H10 · H11 · H30…):写入当时完全正确,之后上游关了 / PR 合了 / 冲突出现 / 卡放久了。⇒ 任何写侧工具都防不住,必须定期回来重看。巡逻这个形状对 B 类是对的,且永远是对的。

⇒ 不是"换掉巡逻",是"把 A 类从它身上拿走",文件自然瘦一圈。

② 把送法从「复制」换成「引用」

被否决过的是「中央 matrix + 跨仓 PAT」,理由是凭据地板——那条裁定我不动。 但它只管在哪跑,完全没说代码怎么送过去。这两件事可分,而只有前一件被裁过。

实测:objectstack 是公开仓、cloud 是私有仓 ⇒ 私有仓 uses: 公开仓的 reusable workflow / composite action 不需要任何跨仓凭据;仍在 sibling 自己的 runner、用自己的 GITHUB_TOKEN、读 github.repository(被调用的 reusable workflow 里该变量指调用方)。grading 在乎的东西一样没动。 objectstack 已有 .github/actions/setup-pnpm/ 先例。

换来:adopt list 消失(依赖关系变成 import 图,没法"凭记忆写短")· 按仓标定的常量(MEASURED_CLOSED_ISSUE_UPDATES_PER_DAY 在 cloud 偏 7 倍)从"违约的手改"变成 with: 输入 · sibling 仓从 32,233+380 行变成十几行。⚠️ 必须钉 sha,不能 @main

⛔ 明确不建议

  • ⛔ 重写:逻辑只有 3,036 行且很紧;重写省不掉它,只会扔掉注释与自测。R38 实例:persist-credentials: false 旁边那句点名 cloud#1099/在 plugin-auth 中添加 SysUserPreference 系统对象,支持用户偏好存储 #1103(凭据被打进客户拿到的 EE 镜像)的注释,是逐字复制没有删掉安全修复的唯一原因;而今天三张 PR 的验收全靠那 4,356 个自测做消融。66 个谓词是一部事故目录,重写等于扔掉记忆再踩一遍。
  • ⛔ webhook 事件驱动:延迟从 6 小时降到秒级听着好,但要常驻服务、webhook 会丢,而巡逻最大的优点恰是无状态、可随时重新推导。这个规模不划算。
  • ⛔ 发 npm 包:内部治理工具,给巡逻加一道发版周期不划算。

os-decision-facets
① 项目长远合理性(权重最高):一个 83% 的日子都在改的仪器,用"手工复制三个文件"分发,掉队是算术不是纪律。②消除结构性债;①把"板子会说谎"从检测降级为不可能。两者都指向长远合理。
② 实际业务拉动:已经发生了——cloud 板上 23/38 条半状态因副本落后而不可见;#11217 量过 objectui 58% 的机器可读 block 是假的。这不是预防性投资,是在还账。
③ 防 AI 犯错:这一棱最强。R38 一轮里五张卡前提失效、我自己的定时器差点替维护者落地一张他正在质疑的 PR。半状态正是多 agent 并发写一块无事务板子的必然产物;①把它从"靠扫"变成"写不出来"。
④ 创业阶段不扩散:⚠️ 这一棱要求分两步、不要一起做。②是纯机械迁移(三个 sibling 仓各改十几行),风险低收益立刻;①要重构写侧,面大,应在②之后从容做——而且②做完才拆得动模块。
推荐:②先做(低风险、直接止血),①随后。⛔ 反对重写。⛔ 反对在②之前动①(现在改写侧,改动还是得靠复制送到三个仓,等于在流沙上施工)。
本分析看不见什么:objectui / objectos 两个 sibling 的副本各落后多少(我只量了 cloud);以及 A/B 两类的准确切分——我按语义判了一遍,真要动手前应当逐类过一遍并把结论写进卡。

维护者速读

改了什么:还没改。这是你今天当面问出来的那件事落成的卡。

为什么:那个 2 万行不是谁写的,是从 objectstack 逐字拷过来的副本。真正的逻辑只有 3,036 行(9%),一半是注释、三成是自测——而这两样今天刚救过场。真正的毛病是送法:它几乎天天改,却靠"手工复制三个文件"分发,副本必然掉队(cloud 这份落后三周,23 条问题没人看得见)。

风险与代价(含回滚):②换送法是机械迁移,三个仓各改十几行,钉 sha 后要回滚就是把 sha 改回去。①收口写侧面大,但可以慢慢来。⛔ 重写的代价最大且收益为负——扔掉事故记忆和安全网,再花几个月重新踩一遍同样的坑。

席位意见:荐 ②先做,①随后,⛔ 不重写、⛔ 不上 webhook 服务。

你要做的:回一句 —— 只做②/②然后①/都不做(维持现状)/或你另有方向。

裁后执行段

②先做 ⇒ 本卡转 pm:queue,收窄为「在 objectstack 建 reusable workflow(或 composite action),三个 sibling 仓改为 uses: 并钉 sha,删除各自的 vendored 副本」,并把 objectstack#18466(sibling install 下 --self-test 必红)作为同批处理——②做完那张卡自动消失。
②然后① ⇒ 同上,另立一张写侧收口卡,Blocked-by: 指向②。
都不做 ⇒ 本卡关 not planned,但请同时裁 objectstack#18466 怎么办:它今天让任何 sibling 的 --self-test 必红。


Generated by Claude Code


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions