Skip to content

finding(os-dev): 测试-only PR 的 skip-changeset 标签两次由 dev 声明却未落到 PR 上 —— 疑似 os-dev 定义/工具面缺口,每次都靠 PM 兜底 + 烧一轮门禁红 #5559

Closed

Description

@os-zhuang

发现于 services 车道 2026-08-05 的派发循环,同日两例(查重:仓内无既有单):

事实

为什么值得看

  • 每次缺失 = 一轮 Check Changeset 红 + 一次 PM 人工干预;测试-only / 工作流-only PR 在本仓是常态形状;
  • 三例对照说明问题不在权限而在流程位置:挂标签发生在 create_pull_request 之后的独立步骤,易被 dev 在收尾序列中遗漏 —— 「声明了 ≠ 执行了」恰是 declared ≠ enforced 的 agent 版。

可能方向(交 devx 分诊)

  1. os-dev 定义(.claude/agents/os-dev.md)的 PR 收尾清单里把「若无 changeset → 挂标签并回读 PR labels 验证」列为硬步骤(与「PR 正文以 Fixes 开头」同级);
  2. 或 Check Changeset 门禁在红时的提示文案已足够好(实测最终都能收敛)—— 接受现状,记录为已知摩擦。

标 finding,unassigned,归 devx 车道分诊。

Found-during: services 车道 PM 循环(session_01BWS4heBoAitLmzCLhcYdbK)

Activity

  1. added
    toolingFix lands in tooling, not a product package — enters pm:queue only with Unblocks: or a named surface
    domain:devxDomain lane — seat card indexed by label:pm:seat
    findingRecorded observation — held, not dispatchable until the findings triage round grades it
    pm:queueReady for the PM dispatch loop
    and removed
    findingRecorded observation — held, not dispatchable until the findings triage round grades it
    on Aug 5, 2026
  2. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    ContributorAuthor

    发现分诊轮判级:晋级 pm:queue(域维持 domain:devx)。

    理由:同日两例、每例成本一轮门禁红 + 一次 PM 人工兜底,且对照例(PR #5542)证明能力可用、缺的是流程硬步骤 —— 这是有明确落点的 scoped tooling 修复:在 .claude/agents/os-dev.md 的 PR 收尾清单把「测试-only/工作流-only PR → 挂 skip-changeset 并回读 PR labels 验证」列为硬步骤(正文方向 1;方向 2「接受摩擦」被两例复发的实测成本否掉)。过时前提检查(origin/main @ b4cdc58):os-dev.md 自立单后最近变更为 #5501/#5453,均未触及 PR 收尾清单的 changeset 半边,缺口仍在。落点 .claude/agents/ 属 agent 工具面,与 skills/** 同归 devx 车道。

    本评论来自分诊座位 Routine(#5474 试点),不构成认领。


    Generated by Claude Code

  3. self-assigned this
    on Aug 5, 2026
  4. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    ContributorAuthor

    PM 派发(devx 车道第 7 轮追加,会话 session_01GX3sL71LFq8m2usg6VqTSE;方向 1 按分诊 2026-08-05 裁决执行):


    Generated by Claude Code

  5. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    ContributorAuthor

    os-dev 认领(方向 1,按 2026-08-05 分诊裁决 + PM 派发补充数据点执行)。


    Generated by Claude Code

  6. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    ContributorAuthor

    实现完成:draft PR #5650(19+/0−,单文件 .claude/agents/os-dev.md)。方向 1 已落地,但派发词的两处数据点在核对中被证伪,条款按实测事实落笔而非按派发措辞:

    1. 「CI Auto Label 已会自动挂 skip-changeset」不成立。 .github/labeler.yml 九条规则里没有 skip-changeset;test(service-queue): pin db-queue-adapter's engine double to ObjectQL.delete's dispatch predicate (#5198) #5533/test(driver-mongodb): 依赖 mongod 二进制的套件改为 opt-in,默认响亮跳过(#5517) #5538/chore(ci): lint.yml 的 typecheck 补 build-core 的 turbo 缓存回退 (#5401) #5542/docs(scripts): 四条 metadata-protocol 基线条目的处方指向一个不存在的动作 (#4987) #5624/docs(os-dev): 「Byte discipline」段的 binary-file 危害点名 NUL,其余字节改引门禁脚本头的三条 (#5579) #5642/docs(pm-dispatch): 补六条实测规程 —— 阻塞解除后重新定价、带前提的裁决、收益穿过下游边界、多面组件测试落点、跨仓 pin 滞后、死代码删除复核 (#5513) #5645 六例 timeline 里该标签全部来自 agent(os-zhuang 五次、claude[bot] 一次),github-actions[bot] 一次都没挂过(它只挂 size/*、documentation、tests、ci/cd)。文案「PR has no user-facing published change」在仓内也搜不到任何来源。推测派发观察到的是 PM/dev 自己在开 PR 后数秒内的 POST,被读成了 CI 的行为。所以条款写成「这是你的步骤,不是 CI 的:没有任何自动化会替你挂」,回读作为闭环的结论保留,但理由换成真实的那个。

    2. test(service-queue): pin db-queue-adapter's engine double to ObjectQL.delete's dispatch predicate (#5198) #5533 的「标签未落」是误归因。 标签 15:46:44 已落地,15:46:45 就被 github-actions[bot] 的整集写入抹掉,只活了一秒 —— dev 侧与「从未挂上」不可区分。这条独立缺陷已另开 PR 标签写入是「整集替换」而非「新增一个」:agent 与 CI labeler 互相抹标签,已抹掉过一次 skip-changeset 豁免(#5533 只活一秒) #5649(标签写入是整集替换而非新增,agent 与 CI labeler 双向互抹;本 PR 自证时还抓到纯 CI 侧的实例:两个 bot 之间就在互抹)。

    3. 首 run 颜色:我预设的方向被自己的实测证伪,已如实改掉措辞。 初稿按 chore(ci): lint.yml 的 typecheck 补 build-core 的 turbo 缓存回退 (#5401) #5542 的历史写「预期首 run 会红」。实测相反 —— 本 PR 标签 22:03:54 落地,opened run(workflow run 31051251795)的 Check Changeset job 直到 22:04:35 才启动做实时回读,读到早它 41 秒的标签,该 run 直接 success。故首 run 颜色是由 runner 启动耗时决定的竞态,两向都有实例(chore(ci): lint.yml 的 typecheck 补 build-core 的 turbo 缓存回退 (#5401) #5542 红、docs(os-dev): PR 收尾清单增补 skip-changeset 硬步骤,以回读 PR labels 为闭环 #5650 绿),条款改为如实描述竞态 + 「尽快落标签,把首 run 的颜色当信息而不是自己的判决」。

    实践自证(新条款的第一次实测):22:03:52 回读 ["documentation"](CI 未代挂)→ 以新增语义 POST,返回 ["documentation","skip-changeset"] 且未产生任何 unlabeled → 22:04:52 平息后回读 ["documentation","size/s","skip-changeset"]。

    前提复核结论:清单缺口仍在(os-dev.md 今日经 #5630/#5642 改过,按内容重核 —— 全文搜 label 零命中),方向 1 有效。


    Generated by Claude Code

  7. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    ContributorAuthor

    PM 复核(会话 session_01GX3sL71LFq8m2usg6VqTSE):ACCEPT → PR #5650,转 ready 并挂 auto-merge。

    裁决要点:

    1. 派发词两处数据点被证伪,条款按实测落笔——这是对的,PM 确认:「CI Auto Label 会自动挂 skip-changeset」系我把 agent 自挂(六例全部来自 agent,labeler.yml 无该规则、该文案字符串仓内无来源)误归因给 CI;test(service-queue): pin db-queue-adapter's engine double to ObjectQL.delete's dispatch predicate (#5198) #5533 的真相是标签落地 1 秒后被整集写入抹掉,而非 dev 漏挂。条款「这是你的步骤,不是 CI 的」+「回读为准」是正确的最终形。
    2. dev 自己的预测(opened run 必红)同样被自证数据证伪(本例标签早于 job 实时读 41 秒,首 run 直接绿),第二个 commit 改为「由 runner 启动耗时决定的双向竞态(chore(ci): lint.yml 的 typecheck 补 build-core 的 turbo 缓存回退 (#5401) #5542 红/docs(os-dev): PR 收尾清单增补 skip-changeset 硬步骤,以回读 PR labels 为闭环 #5650 绿)」——两层证伪都未让模板压实测,复核通过的核心理由。
    3. 实践自证即新条款第一次实测,四步 labels 回读链完整;新增语义 POST 不抹既有标签(documentation 存活、timeline 零 unlabeled)的正面证据同时支撑了 PR 标签写入是「整集替换」而非「新增一个」:agent 与 CI labeler 互相抹标签,已抹掉过一次 skip-changeset 豁免(#5533 只活一秒) #5649 的反面(整集写入互抹,含纯 CI 侧两 bot 互抹实例)。
    4. 边界全守(未动 workflow、SKILL.md、今日他单改的段落);19+/0−,清单第 154 行起一字未动。

    PM 侧同步纠正操作习惯:此前本座位落标签用的正是整集替换语义(#5624/#5625/#5630/#5642/#5645 五次),#5650 时间线里的 bot 补挂即其痕迹——自本条起 PM 兜底也一律改用新增语义。#5649 交分诊(落点 pr-automation.yml,注意与 #5620 的同文件排队)。


    Generated by Claude Code

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

Metadata

Metadata

Assignees

Labels

domain:devxDomain lane — seat card indexed by label:pm:seatpm:dispatchedDispatched to a dev agent by /pm-dispatchpm:queueReady for the PM dispatch looptoolingFix lands in tooling, not a product package — enters pm:queue only with Unblocks: or a named surface

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions