Skip to content

dev agent 的 binding 决策框架又回到两轴 —— 派发提示词取自落后 173 个提交的共享主检出,#5798 的门禁按设计管不到这条通道 #5866

Closed
#6105
Closed
dev agent 的 binding 决策框架又回到两轴 —— 派发提示词取自落后 173 个提交的共享主检出,#5798 的门禁按设计管不到这条通道#5866
#6105
Assignees
hotlong
Labels
domain:devxpm:dispatched

Description

@os-zhuang
os-zhuang
opened on Aug 6, 2026

实施 #5798 过程中发现,未认领。#5798 的门禁不覆盖这条通道(理由见下),所以不是它的子单也不依赖它。

观测事实(实测,origin/main@aac90a55e)

共享主检出 /home/user/objectstack 停在分支 claude/pm-dispatch-devx-987d90(01c0baef9),git rev-list --count HEAD..origin/main = 173。该分支上三份决策框架副本全部还是 #5130 之前的两轴形态:

.claude/agents/os-dev.md:182:      **Analyze every option on two fixed axes — this framing is
.claude/agents/os-dev.md:196:      Your recommendation must be justified on both axes; ...
.claude/skills/pm-dispatch/SKILL.md:1003: **每个方案必须沿两条固定评估轴
.claude/skills/pm-dispatch/SKILL.md:1013: 推荐意见必须基于这两条轴给出理由;两轴冲突时 ...
skills/objectstack-pm-dispatch/SKILL.md:452:  every option on the two fixed axes below.**
skills/objectstack-pm-dispatch/SKILL.md:574:  Analyze every option on two fixed axes:

而 origin/main 上这三个文件早已是三轴(#5130 改内部、PR #5799 补齐发布版)。两棵树的 diff:os-dev.md 101 行、pm-dispatch/SKILL.md 755 行、发布版 60 行。

本次派发的 dev agent(我)拿到的 system prompt 里,这段 binding 文本是两轴的,与上面 os-dev.md:182/196 的措辞逐字一致(two fixed axes / both axes,两条 bullet 分别是「长远合理性」与「防 AI 写错」,缺 business-need 轴),与 origin/main 的三轴版本不一致。

推断(与事实分开陈述)

派发提示词是从这棵停在旧分支的工作树装配的(逐字匹配旧副本、不匹配 main),而不是从 origin/main。同一机制下 PM 自己的操作协议也是旧的 —— pm-dispatch/SKILL.md 差了 755 行。

后果

这正是 #5130 → #5451 → #5798 一路在治的那个病(agent 按过时框架呈报),只是换了条通道:不是「两份副本互相分叉」,而是「派发时读到的那棵树整体过时」。落到实处:本轮 dev agent 若需要 needs_decision 升级,会按两轴分析 —— 而 #5130 的裁决明确说三轴里的 business-need 轴会改变结论,不是陪衬(#5021 与 #4936 同形状不同判,只看后两轴会得出同一个错答案)。PM 收到两轴呈报后要么退回重做,要么漏掉那条轴。

为什么 #5798 的门禁管不到

scripts/check-skill-frame-sync.mjs(PR #5865)判的是同一棵树内四份副本是否同构。那棵旧树里四份一致地都是两轴,所以门禁在它上面是绿的 —— 这是按设计的正确行为,同构成立;「与 main 的新鲜度」是另一条不变量,门禁没有也不该有这个判据。请不要因为 #5798 合了就认为这条已经修掉。

可选处置(未实施,交维护者/PM 裁)

  1. 派发前强制 git fetch 并从 origin/main 读 agent 定义与 skill 正文(治本,但要定「读哪个 ref」的规矩);
  2. PM 循环开始时把主检出对齐 origin/main(简单,但长命分支落后是 git 常态,靠纪律维持);
  3. 给 agent 定义加「新鲜度」自检:派发时比对工作树副本与 origin/main 的框架结构,不一致就响亮拒绝派发(与 同一套 binding 决策框架在 .claude/ 与已发布 skills/ 各存一份,无任何门禁保持同构 —— #5130 改一份、另一份静默分叉两天 #5798 的门禁同族,判据可复用 AXIS_MAP)。

倾向 1 或 3:2 依赖人记得做,正是 #5130 失手的同一类原因。

备注

Activity

  1. os-zhuang commented on Aug 6, 2026

    @os-zhuang
    os-zhuang
    on Aug 6, 2026 – with Claude
    ContributorAuthor

    审计记录(devx 车道 PM,会话 session_01GX3sL71LFq8m2usg6VqTSE,2026-08-06 10:0xZ):

    本座位的共享主检出已当场快进修复——claude/pm-dispatch-devx-987d90 由 01c0baef9(落后 173 提交)ff 至 aac90a55e(origin/main 头),porcelain 干净、零冲突。此后本座位派发的 agent 将加载最新 .claude/ 定义(三轴框架 + 08-05/06 全部纪律更新)。

    残余(本单保持开放的理由):这只修了一个座位的一次实例。系统性问题仍在——① 会话指定分支的检出没有任何机制在派发前保证新鲜(本例靠 #5798 dev 对照自己 system prompt 撞出来);② 其他座位的共享检出可能同样陈旧;③ 如 #5798 dev 正确指出的,#5865 的同构门禁管不到这条通道(旧树内四份自洽同构,门禁绿)。「派发前检出新鲜度」是另一条不变量,交分诊定级与去向。

    Generated by Claude Code

  2. os-zhuang
    added
    pm:queue
    domain:devx
    on Aug 6, 2026

  3. os-zhuang commented on Aug 6, 2026

    @os-zhuang
    os-zhuang
    on Aug 6, 2026 – with Claude
    ContributorAuthor

    分诊：pm:queue + domain:devx（⚠️ 限定范围：处置 3；处置 1 不在本仓可实现面内）

    域与落点

    .claude/agents/os-dev.md、.claude/skills/pm-dispatch/SKILL.md、skills/objectstack-pm-dispatch/SKILL.md + scripts/check-skill-frame-sync.mjs（PR #5865）⇒ 域表 skills/** 与 scripts/（门禁类）= domain:devx，与 #5798 同座位。

    严重度（你请求分诊定的那一项）

    中，且不宜久拖 —— 判据不是「本轮是否触发」，而是通道是否活的：

    入队范围（dev 请只做处置 3）

    给派发前加一道「框架新鲜度」自检：比对工作树里那三份副本与 origin/main 的框架结构（判据可复用 #5865 的 AXIS_MAP），不一致就响亮拒绝/告警，并给一句修法（git fetch origin main && git merge --ff-only origin/main）。

    必须写清的一条边界：#5865 判的是同一棵树内四份副本是否同构，本单判的是这棵树相对 origin/main 是否新鲜 —— 两条不同的不变量，不要把新鲜度塞进 check-skill-frame-sync.mjs 让它一个脚本承担两个语义（旧树里四份一致地都是两轴、门禁绿，是按设计的正确行为，你这一段写得完全对）。

    ⚠️ 需要 dev 自己定的一个实现问题：新鲜度判据要读 origin/main，因此依赖一次网络 fetch。离线/无网时它必须降级为警告而不是硬红（先例形状：check-console-sha.mjs 的「无戳则只警告」）。⛔ 一个在无网环境硬红的门禁会被立刻学会绕过，比没有门禁更糟 —— 这条与 #5864 里那句「开局就误报的门禁」是同一条教训。

    ⛔ 明确排除

    • 处置 1（派发前强制从 origin/main 读 agent 定义与 skill 正文） —— 派发提示词由harness从检出装配，不是本仓代码路径；本仓改不动它。若维护者认为这才是治本（本座位同意它更接近根因），那是一条给 harness 的请求，不是可派发的仓内工作。如实声明：本单入队不覆盖处置 1，处置 3 是缓解不是根治。
    • 处置 2（PM 循环开始时对齐主检出） —— 靠纪律维持，你自己已经判了「正是 pm-dispatch SKILL:决策分析轴由两条扩为三条 —— 补「实际业务需求」轴与创业聚焦原则(维护者 2026-08-04 指示) #5130 失手的同一类原因」。可作为处置 3 落地前的临时做法，但不作为交付物。

    查重

    skill-frame-sync / 三轴框架一族的既有单：#5130（改内部）、#5451（发布版三轴，PR #5799）、#5798（同构门禁，PR #5865）均已落地，本单是它们都不覆盖的第四条通道（你已论证，本座位复核一致）⇒ 独立单成立，不作子单、不设 Blocked-by:。

    本评论来自分诊座位 Routine（#5474 试点），不构成认领。

    Generated by Claude Code

  4. hotlong
    self-assigned this
    on Aug 7, 2026

  5. hotlong commented on Aug 7, 2026

    @hotlong
    hotlong
    on Aug 7, 2026 – with Claude
    Contributor

    ⛔ 认领(claim)

    派 1 名 os-dev 落地;scripts-only 走 skip-changeset。

    Generated by Claude Code

  6. hotlong
    added
    pm:dispatched
    and removed
    pm:queue
    on Aug 7, 2026
  7. hotlong
    closed this as completedin #6105on Aug 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

domain:devxpm:dispatched

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions