Skip to content

fix(ci): 命令归属漂移 —— 6 个脚本逐个定性后再更新计数 - #6

Open
LinzeColin wants to merge 1 commit into
mainfrom
fix/command-drift-and-hygiene
Open

fix(ci): 命令归属漂移 —— 6 个脚本逐个定性后再更新计数#6
LinzeColin wants to merge 1 commit into
mainfrom
fix/command-drift-and-hygiene

Conversation

@LinzeColin

@LinzeColin LinzeColin commented Jul 28, 2026

Copy link
Copy Markdown
Owner

没有只把 84 改成 90

先说这条,因为它是这个 PR 唯一重要的地方。

实测证明只改数字能变绿:把 top_level_script_entrypoints_current 单独改成 90、不登记任何归属,校验器照样 PASS。

破坏方式 结果
计数改回 84 FAIL ✓
能力名重复 FAIL ✓
登记了不存在的实现文件 FAIL ✓
只改计数、不登记归属 PASS ← 守卫抓不到

也就是说,这条守卫只数文件个数,根本没有能力发现「加了脚本不登记」。它是一条漂移绊线,不是归属登记表。这一点已写进契约的 inventory 留痕字段,免得下一个人以为它管得住。

先把浅克隆加深

本地只有 5 个提交(浅克隆),git log 会显示 90 个脚本"全是同一次提交加的",查不出真相。加深到 703 个提交后才看清:

  • 84 是 2026-07-19(3ad3130b) 记下的
  • 那之后 OpenAIDatabase/scripts/ 正好新增 6 个文件

逐个定性

脚本 __main__ 定性 处置
build_recurring_prompt_analysis.py 有 CI 产出 write_ci_generated
update_human_readable_recurring.py 有 CI 产出 write_ci_generated
validate_human_readable_docs.py 有 只读校验 read_only
validate_recurring_prompt_analysis.py 有 只读校验 read_only
validate_skill_run_logs.py 有 只读校验 read_only
recurring_prompt_core.py 无 库模块,被上述 3 个 import 不登记为命令,仅计入总数

前 5 个进 canonical_commands,与既有惯例一致(validate_agent_transport_compatibility.py → agent-transport-compatibility 就是同款)。库模块不登记也是既有惯例(memory_atlas_paths.py、privacy_guard.py 同款)。

计数 84 → 90 放在最后做。

排版:12 增 3 删,不是 432 行

第一版我用 json.dumps(indent=2) 回写,把整个文件从 264 行重排成 547 行 —— 原文件的 canonical_commands 是一条压一行的。432 行的格式噪音会把真实改动彻底淹没。

改成文本级插入,保持原排版。现在 diff 是 12 增 3 删。

验证:与干净 main 逐条对比

跑满 430 条,和 origin/main 的干净检出做失败集差集:

我修掉的:FAIL: test_contract_and_repository_have_zero_command_drift
我引入的:(空)

其余 6 条(4 ERROR + 2 FAIL,分布在 memory_atlas_acceptance_audit / memory_atlas_goal_completion / repository_hygiene_audit)在干净 main 上同样存在,均非本次引入。

未处理:仓库卫生那条

test_current_migrated_worktree_is_within_declared_bounds 仍然红。那条的处置(删备份 / 加进批准清单)要 owner 拍板,我不自行选一个执行。

但复核后发现它和任务描述里说的不是一回事 —— 详见随后的评论。

@LinzeColin
fix(ci): 命令归属漂移 —— 6 个脚本逐个定性后再更新计数
1c9bdb1 
CI 报 `top-level script entrypoints: expected 84, observed 90`。

★ 没有只把 84 改成 90。实测证明那样能变绿:把计数单独改成 90 而不登记
  任何归属,校验器照样 PASS —— **这条守卫只数文件个数,根本没有能力发现
  「加了脚本不登记」**。所以先逐个定性,再更新计数。

先把浅克隆(只有 5 个提交)加深到 703 个,才查得出 84 是 2026-07-19
(3ad3130)记下的,以及那之后新增的正好 6 个脚本:

  build_recurring_prompt_analysis.py      有 __main__,CI 产出 -> write_ci_generated
  update_human_readable_recurring.py      有 __main__,CI 产出 -> write_ci_generated
  validate_human_readable_docs.py         有 __main__,只读     -> read_only
  validate_recurring_prompt_analysis.py   有 __main__,只读     -> read_only
  validate_skill_run_logs.py              有 __main__,只读     -> read_only
  recurring_prompt_core.py                无 __main__,是被上述脚本 import 的库模块

前 5 个进 canonical_commands(与 validate_agent_transport_compatibility 等
同类脚本的既有惯例一致);库模块按惯例不登记为命令(memory_atlas_paths /
privacy_guard 等同款),仅计入总数。计数 84 -> 90,并在 inventory 里留痕
说明改了什么、为什么,以及这条守卫的已知局限。

★ 修改用文本级插入,保持原文件「一条一行」的排版。先前用 json.dumps
  回写会把整个文件重排成 432 行 diff,真实改动会被格式噪音淹没。
  现在是 12 增 3 删。

实测(430 条全套,与干净 origin/main 逐条对比):
  我修掉的:test_contract_and_repository_have_zero_command_drift
  我引入的:无
  其余 6 条(4 ERROR + 2 FAIL)在干净 main 上同样存在,均非本次引入。

破坏测试:计数改回 84 -> FAIL;能力名重复 -> FAIL;登记不存在的实现
文件 -> FAIL;只改计数不登记 -> PASS(即上文说的守卫局限,已写进契约)。

未处理:test_current_migrated_worktree_is_within_declared_bounds(仓库卫生)。
那条要 owner 拍板,材料另附,不自行选一个处置执行。
@LinzeColin

LinzeColin commented Jul 28, 2026

Copy link
Copy Markdown
Owner Author

仓库卫生:复核后和任务描述里说的不是一回事

原以为是「几个散落的大 zip,删掉或批准二选一」。实测是 103 条违规 / 101 个文件 / 17.86 MB,而且分成性质完全不同的两类。

分布

目录 文件 MB
_delivery-backups/teleiosis 2 5.25
persona-distiller-group/软件开发师 34 3.87
persona-distiller-group/材料建工师 15 2.07
persona-distiller-group/投资资本师 20 2.03
persona-distiller-group/政治法律师 5 1.75
其余 persona 族 23 2.78
machine/runs 两个 2 0.12

违规类型:tracked_blob_exceeds_bound 2 条、unapproved_tracked_archive 101 条。

真正的根因:一次改名把批准清单整份作废了

repository_hygiene.json 的 allowed_archive_prefixes 里已经有 6 条 persona zip —— 说明 owner 早就决定批准这类文件。但:

清单里的 persona 条目: 6
其中指向的文件已不存在: 6      ← 全部
仍然生效的:             0

目录被改过名:清单写的是 政治法律家,磁盘上是 政治法律师(家 → 师)。6 条批准全部指向不存在的路径,静默失效。

而审计只报违规,不检查批准清单本身是不是已经指向不存在的路径 —— 所以没人发现它失效了。

两类的性质完全不同

persona 交付 zip teleiosis 备份 zip
数量 / 体积 95 个 / 12.6 MB 2 个 / 5.25 MB
.gitignore 反向保护 有,且写明理由 没有
治理定位 README「受保护资产」 无
源件是否还在 就是源件本身 技能本体仍在 registry 里
超 1 MB 上限 否(单个 0.07–0.7 MB) 是,两个都超

.gitignore 那条反向规则写得很清楚:

没有这条,register_persona 之后 git add -A 会静默漏掉 ZIP,仓库就会出现「team-index 说 N 人、实际只有 N-1 个 ZIP」的坏状态。

而且这条产品线在 95/600,每出一个人物就多一个 zip —— 逐个文件登记的方式本来就撑不住。

三种处置,后果各不相同(等你定,我不自选)

A. 修批准清单,改成前缀而非逐文件
把 CodexSkills/registry/codex/persona-distiller-group/ 整个前缀加进 allowed_archive_prefixes,清掉 6 条失效的精确路径。

  • 好:一次到位,跑到 600 人也不会再红;符合 .gitignore 已表达的意图
  • 坏:该前缀下任何 zip 都不再受审;仓库会随人物数持续增长(600 人 ≈ 80 MB)

B. 只删 teleiosis 那 2 个备份
技能本体仍在 registry,这 2 个是还活着的东西的备份,也是唯二超 1 MB 的。

  • 好:立刻少 5.25 MB,且删的是重复品
  • 坏:不解决 101 条里的 99 条,审计照样红

C. 什么都不动

  • 坏:这条红会一直在。一条 99% 属于"早就批准了、只是清单坏了"的红,只会训练人忽略它 —— 真有大文件混进来时也不会有人看

我的判断:A + B。A 修的是被改名弄坏的既有决定,B 删的是活物的重复备份。但这是你的仓、你的资产,我不替你选。

★ 另有一条独立建议:审计应该顺带检查批准清单里的路径是否还存在。这次就是靠人肉发现 6 条全死了 —— 一份自己烂掉却没人知道的豁免清单,比没有清单更危险。

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

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@LinzeColin