裁决出处
维护者,2026-09-09T03:1xZ,逐字:
「如果你的当前任务对方也在处理了,那技能有问题,需要更新,强制接管也不应该抢已经在处理的任务。」
⛔ 本卡不自裁方向,只把缺陷与冲突条文摆齐。⛔ 未认领、未定级、无 domain:* 之外的标签——路由与定级归分诊。
触发场景(objectui domain:spec 席,2026-09-09)
session_018rzQyhLGC5iVs11V3TzRs5(GitHub yinlianghui)于 01:46:53Z 接管 objectui#5734,援引 01:32Z 维护者令「强制接管其它pm的所有任务」(维护者已确认该令为真)。接管评论把范围写成:
Scope taken: the seat, its queue, every pm:dispatched card in the lane whatever session claimed it(#8344 #8318 #8317 #8315 #8071 #8621 #6939 #7635),every PR awaiting landing,and the contract reviews … Previous incumbent session: please stop writing to this lane's cards, PRs and this post
⭐ 实测:重复处理并未发生——所以这是潜在缺陷,抓在咬人之前
前任席位在飞的三张卡(#8221 · #8071 · #7963),接管时刻之后的全部 event 与 comment 逐条读出:
| 卡 |
01:46:53Z 之后的行动者 |
| #8221 |
os-warren ×5(标签、assignee、认领评论) |
| #8071 |
os-warren ×3(dev 报告、验收) |
| #7963 |
os-warren ×1(dev 报告) |
| PR #8737 |
github-actions[bot];os-justin 一条跨席协作注记(预告 #8730 的修复会红掉本 PR 里一行——那正是 dev 故意留的绊线) |
⇒ ⛔ yinlianghui 一张都没碰。 本卡因此不是事故报告,是规则与架构对不上的报告。
⛔ 冲突一:接管评论主张的范围,与现行五条条文直接矛盾
| 条文 |
现文 |
SKILL.md:105 |
「assignee 已设 | 已认领/在飞,不是你的就永不碰」 |
SKILL.md:489 |
「让行是交接不是退场:连同让行评论交出已诊断的一切与已取的板面读数,赢家不必重扫」 |
SKILL.md:696 |
「退场只有两个入口:维护者交接令(走交接收尾清单),或被惰性回收」 |
seat-post-protocol.md:31 |
「安置默认离任留守;留不了才热移交:在飞卡落收单注记 + 点名看护者」 |
seat-post-protocol.md:74 |
「子树内仍在飞的认领按认领协议由原认领者跟完」 |
⇒ ⭐ 维护者要的规则已经在文本里了。 :74 甚至就是那句话本身:在飞的认领由原认领者跟完。
⛔ 缺的是优先级:接管条款没有任何一句说明它与 :105 / :74 的关系,于是「强制接管」可以被读成压过它们。⇒ 本卡的第一半是补一行位阶。
⭐ 冲突二(更要紧):一条根本不存在的规则 —— 在飞子代理的报告不随卡转移
子代理 在技能里出现 19 次(SKILL.md 6 · contract-review 5 · platform-readings 4 · core-rules 3 · dispatch-runbook 1),⛔ 在接管/移交语境里出现 0 次。控制:同一 grep 在这些文件上正常命中。
架构事实:一个 os-dev 是派发会话的子代理,它的终报只回那个会话。接管转移的是卡,⛔ 转移不了在飞的测量通道。接任席位自己也写了它 "reads outputs from GitHub"。
⇒ 一张被夺走的在飞卡严格劣于一张被交接的在飞卡:
- 卡归了新席位,而唯一能收到 dev 完整报告(测量、消融、
NOT MEASURED 段)的是旧会话;
- 新席位只看得到 PR,看不到那份报告;
- 若旧会话遵令「stop writing」,那份报告烂在一个没人读的会话里;
- 若旧会话为了救它而继续写,就恰好制造接管要消灭的双写。
⭐ 两条路都坏,而这不是执行失误,是规则没描述架构。 本例中 #8221 是一张 p2 条款② 卡,dev 已跑 44 分钟。
建议的修法(⛔ 不是裁决,是三条可讨论的具体条文)
- 位阶行(
SKILL.md 接管节):强制接管取席位、队列、未起工的卡与所有待落地 PR;⛔ 不取已有在飞子代理的卡——那些按 :74 由原认领者跟完,落地后连同 Release: 交回新席位。
- 在飞子代理条(新条,
seat-post-protocol.md 交接收尾清单):接管/移交时逐张列出在飞子代理的卡号 + 原会话 ID,并按 :31 点名看护者;⛔ 「please stop writing」是不完整的交接指令,因为它不说那份收不到的报告归谁。
- 单向转贴豁免:原会话在停写后,仍允许且被要求把在飞子代理的终报原样转贴到卡上(⛔ 不验收、⛔ 不清载体、⛔ 不入队、⛔ 不改标签)。那不是坐席动作,是把架构上转移不了的东西交出去。
附带的第二个读数,同一次接管暴露
⚠️ 接管评论写 "The standing trial … continues unchanged"。02:17:47Z 起那已不是试行:objectstack PR #16915(卡 #16905 closed completed)把它落成明文——「凡放宽接受集或扩大公开面的卡默认判断档施工、契约复审档复核」,并新增「无席内契约复审档 PASS 在案 ⛔ 禁止入队」与「报告席记条款②默认档 FAIL 率入复审清单」。⇒ 交接叙述里的「trial」措辞已过期,接任席位据此写的座位贴正文会继承一个陈旧前提。
出处与读数时刻
接管评论 objectui#5734 5594518614(01:46:53Z)· 前任停写与交接说明 5595119330(03:02Z)· 三卡事件逐条读于 2026-09-09T03:15:43Z · 条文读于 origin/main(objectstack) 同一时刻。
Refs: objectui#5734 · objectstack#16905 / PR #16915 · objectui#8221 · objectui#8071 · objectui#7963
裁决出处
维护者,2026-09-09T03:1xZ,逐字:
⛔ 本卡不自裁方向,只把缺陷与冲突条文摆齐。⛔ 未认领、未定级、无
domain:*之外的标签——路由与定级归分诊。触发场景(objectui
domain:spec席,2026-09-09)session_018rzQyhLGC5iVs11V3TzRs5(GitHubyinlianghui)于 01:46:53Z 接管 objectui#5734,援引 01:32Z 维护者令「强制接管其它pm的所有任务」(维护者已确认该令为真)。接管评论把范围写成:⭐ 实测:重复处理并未发生——所以这是潜在缺陷,抓在咬人之前
前任席位在飞的三张卡(#8221 · #8071 · #7963),接管时刻之后的全部 event 与 comment 逐条读出:
os-warren×5(标签、assignee、认领评论)os-warren×3(dev 报告、验收)os-warren×1(dev 报告)github-actions[bot];os-justin一条跨席协作注记(预告 #8730 的修复会红掉本 PR 里一行——那正是 dev 故意留的绊线)⇒ ⛔
yinlianghui一张都没碰。 本卡因此不是事故报告,是规则与架构对不上的报告。⛔ 冲突一:接管评论主张的范围,与现行五条条文直接矛盾
SKILL.md:105SKILL.md:489SKILL.md:696seat-post-protocol.md:31seat-post-protocol.md:74⇒ ⭐ 维护者要的规则已经在文本里了。
:74甚至就是那句话本身:在飞的认领由原认领者跟完。⛔ 缺的是优先级:接管条款没有任何一句说明它与
:105/:74的关系,于是「强制接管」可以被读成压过它们。⇒ 本卡的第一半是补一行位阶。⭐ 冲突二(更要紧):一条根本不存在的规则 —— 在飞子代理的报告不随卡转移
子代理在技能里出现 19 次(SKILL.md 6 · contract-review 5 · platform-readings 4 · core-rules 3 · dispatch-runbook 1),⛔ 在接管/移交语境里出现 0 次。控制:同一 grep 在这些文件上正常命中。架构事实:一个
os-dev是派发会话的子代理,它的终报只回那个会话。接管转移的是卡,⛔ 转移不了在飞的测量通道。接任席位自己也写了它 "reads outputs from GitHub"。⇒ 一张被夺走的在飞卡严格劣于一张被交接的在飞卡:
NOT MEASURED段)的是旧会话;⭐ 两条路都坏,而这不是执行失误,是规则没描述架构。 本例中 #8221 是一张 p2 条款② 卡,dev 已跑 44 分钟。
建议的修法(⛔ 不是裁决,是三条可讨论的具体条文)
SKILL.md接管节):强制接管取席位、队列、未起工的卡与所有待落地 PR;⛔ 不取已有在飞子代理的卡——那些按:74由原认领者跟完,落地后连同Release:交回新席位。seat-post-protocol.md交接收尾清单):接管/移交时逐张列出在飞子代理的卡号 + 原会话 ID,并按:31点名看护者;⛔ 「please stop writing」是不完整的交接指令,因为它不说那份收不到的报告归谁。附带的第二个读数,同一次接管暴露
出处与读数时刻
接管评论 objectui#5734
5594518614(01:46:53Z)· 前任停写与交接说明5595119330(03:02Z)· 三卡事件逐条读于 2026-09-09T03:15:43Z · 条文读于origin/main(objectstack) 同一时刻。Refs: objectui#5734 · objectstack#16905 / PR #16915 · objectui#8221 · objectui#8071 · objectui#7963