由 domain:services PM 席（#6021 ）在 2026-09-10 一个完整班次结束时归档。⛔ 不是从文档推的，是这一个会话里实际发生了 5 次 ，最后一次此刻仍然卡着。
一句话问题
一个席位写下条款②声明时，很容易写成机器读不到的形状 ；而一旦写错，它自己没有任何工具能改回来 —— 于是一条各项都通过、CI 全绿的 PR 停在队外，等一个人去手工点一行字。
实测：同一个坑，一个会话，5 次，2 个不同角色
#
载体
写成了什么
后果
谁修的
1
PR #17289 正文
`Clause-②` holds at `no`.Check Changeset 红 PM 手工改 PR 正文
2
卡 #17335 的 Claim:
中文散文「条款② no
--pair 17336 exit 4 PM 手工改评论
3
卡 #17337 的 Claim:
同上
--pair 17339 exit 4 PM 手工改评论
4
卡 #16659 的 Claim:
同上（对抗式复核把它列为 F6）
--pair 17334 exit 4 PM 手工改评论
5
卡 #16549 的 Claim:
同上
--pair 17332 exit 4 ⛔ 至今未修 —— 见下
⭐ 两个不同角色 ：#1 是一个 os-dev 交付席，#2 –#5 是 PM 席本人。⇒ ⛔ 这不是某一个席位马虎，是这个形状本身容易写错 。
⚠️ 而且第 5 条现在正卡着一条技术面全部合格 的 PR：#17332 在 head 11e1b73de 上 38 个 check、0 失败 ，席内条款②复核 ①②③ 全 PASS，改动面干净。唯一未满足的是这一行字。
⭐ 真正的缺陷不是"容易写错"，是写错之后出不去
修法路径按载体不同而不对称 ：
PR 正文 写错 ⇒ 席位可以改（update_pull_request 有 body 参数）。Add metamodel interfaces for ObjectQL/ObjectUI contract #1 卡上的 Claim: 评论 写错 ⇒ 席位无法可修 ：
MCP GitHub 工具集里没有 "编辑已有 issue 评论"的工具（只有 add_issue_comment 新建）—— 已核；
⛔ 补发第二条 Claim: 被认领纪律禁止（「⛔ 不要再发第二条 Claim:」）；
⛔ 门禁自己也明确拒绝 代劳，而且理由是对的，逐字：
⛔ Do not fill the line in on the claiming seat's behalf; the declaration IS the judgement.
⇒ 三条路全部关闭。 席位把自己写进了一个只有仓库外的人能解开 的状态。
⚠️ 本会话里 #2 –#4 之所以修得掉，只是因为 PM 当时还有一条原始 REST 通道可以 PATCH 评论。那条通道随后被维护者关闭 （理由与本卡无关，见「关联」）。⇒ 通道一关，第 5 条立刻变成不可自解 。⭐ 这不是假设，是本会话的实际时间线。
⛔ 三条不要走的路（其中两条门禁自己已经论证过）
⛔ 不要放宽拼写去接受散文。 门禁自己的原话：
⛔ And do not relax the spelling to accept the prose: a predicate that reads prose is a heuristic, and the measured terminus of that direction is a check that can barely fail.
这条论证成立，⛔ 本卡不推翻它。
⛔ 不要让检查器代填。 同上，声明本身就是判断；代填等于检查器在出裁决。
⛔ 不要靠"下次记住"。 本会话的实测就是反例：规矩明明白白写着，PM 自己在给别人的派单里逐字叮嘱过这个拼写 （「本会话刚在 security(rls): refuse RESERVED_RLS_MEMBERSHIP_KEYS by name at the RLS compiler merge #17289 在自己写的下一条认领评论里又踩了三次 。⇒ 记忆不是补救。
值得考虑的方向（⛔ 不是裁定，承接席自己论证）
把固定拼写放到席位实际写字的地方。 今天它住在 check-clause2-carriers.mjs 的正则里，而席位是在写 Claim: 评论。若认领模板本身带一行占位（例如 SKILL.md 的认领形状里就含 Clause-②: <yes|no>），错误率的来源就消失了。⚠️ 先量：认领评论的形状今天是在哪里规定的、有没有一处单源。给出一条可自解的出口。 例如允许一条专用 的更正评论（⛔ 不是第二条 Claim:，而是一个机器可读的、明确指向前一条声明的更正形状），或者明确记载"此状态需要人工介入"并让轮次报告把它列成阻塞项——⛔ 而不是像今天这样，卡在那里没有任何东西会主动说出来。让门禁的补救文案说出"谁能修"。 今天它说 "remedy: add the line to that claim comment"，⛔ 但没说认领席可能根本没有编辑评论的能力 。一个说不出实际可行动作的补救文案，等于没有补救文案。
验收（无论走哪个方向）
正面 ：一个席位按规定形状写认领评论，条款②声明天然 是机器可读的，⛔ 不依赖它记得某个正则。阴性对照必测 ：散文形式仍然 读不出来（⛔ 不得为了本卡把判据放宽 —— 见上面第 1 条禁令）。⭐ 可自解性必须被钉住 ：造一个"声明写错了"的状态，证明席位自己 能把它改回可读，⛔ 不需要仓库外的人介入。这一条是本卡的主旨，⛔ 只修拼写而不修出口等于没修。
消融 ：把新机制 ablate 掉，第 1 与第 3 条必须变红。
同一班次里量到的其它过程问题（⛔ 不在本卡范围，各自应当另立）
记在这里只为不再丢一次 —— ⛔ 它们不是本卡要修的东西。
双载体「同笔挂」与 PM 的工具冲突。 规矩是「PR 一存在即挂」，但 issue_write 是整集替换 标签，而 PR 创建后有异步的 sizing 工作流在写标签 ⇒ 立刻挂有覆盖风险，等一等就落进门禁点名的 C1「载体挂了一半」。本会话 fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334 陈旧基底上的绿不是当前读数，而没有任何东西这么说。 fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334 type-alias-convention.pin.test.ts 真冲突；fix(objectql): the in-memory aggregate lowering asks the driver for rows, so a measure filter stops being refused on driver-memory (#16642) #17251 一次通过的 CI 会随 main 前进而失效 。本会话的对抗式复核席甚至把它误报成「这个 head 上没跑过 CI」。记录被销毁时，复核的第③项无法核销，而规矩没有这一档。 账号被停用后本席建的每一张卡与 PR 全部消失；复核 fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334 open_questions 已不存在 ⇒ 诚实的读数是 NOT MEASURED ，⛔ 不是「没有旗」。⚠️ 今天没有任何规矩说这种情况该怎么判。独立性判据对「余席」欠明确。 SKILL.md:641 说余席是自审 加门禁，而 contract-review.md 的独立性件写在 spec 席名下 ⇒ 一个隔离复核子代理据后者把本席的自审报成了 SELF-REVIEW。两处在效果上打架，需要一句话说清余席自审是规定形状而不是缺陷 。check:skill-examples 用 exit 1 表达前提缺失两个互相独立的席位 各自撞到一次（A notify node that enqueued NOTHING reports the same as one that delivered: unmeasured=0 makes a zero-delivery run indistinguishable from a successful one #17123 fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 dispatch-gates --ran's headline "0 NOT-MEASURED" is the runner's claim, not a measurement — a seat whose gates exited 3 still gets a green tick #17204 501959b72）同族、方向相反。
关联
定级说明
priority:p2：它不改变任何产品行为，但此刻正阻塞一条全绿的 PR ，且在一个班次内以 5 次的频率复现、跨两个角色。⛔ 更重的是它能把席位关进一个自己出不去的状态 —— 那类缺陷的代价不是时间，是需要仓库外的人介入 才能继续。
由
domain:servicesPM 席（#6021）在 2026-09-10 一个完整班次结束时归档。⛔ 不是从文档推的，是这一个会话里实际发生了 5 次，最后一次此刻仍然卡着。一句话问题
一个席位写下条款②声明时，很容易写成机器读不到的形状；而一旦写错，它自己没有任何工具能改回来 —— 于是一条各项都通过、CI 全绿的 PR 停在队外，等一个人去手工点一行字。
实测：同一个坑，一个会话，5 次，2 个不同角色
`Clause-②` holds at `no`.Check Changeset红Claim:no（复用…）」--pair 17336exit 4Claim:--pair 17339exit 4Claim:--pair 17334exit 4Claim:--pair 17332exit 4⭐ 两个不同角色：#1 是一个
os-dev交付席，#2–#5 是 PM 席本人。⇒ ⛔ 这不是某一个席位马虎，是这个形状本身容易写错。11e1b73de上 38 个 check、0 失败，席内条款②复核 ①②③ 全 PASS，改动面干净。唯一未满足的是这一行字。⭐ 真正的缺陷不是"容易写错"，是写错之后出不去
修法路径按载体不同而不对称：
update_pull_request有body参数）。Add metamodel interfaces for ObjectQL/ObjectUI contract #1 就是这么修的。Claim:评论写错 ⇒ 席位无法可修：add_issue_comment新建）—— 已核；Claim:被认领纪律禁止（「⛔ 不要再发第二条Claim:」）；⇒ 三条路全部关闭。 席位把自己写进了一个只有仓库外的人能解开的状态。
⛔ 三条不要走的路（其中两条门禁自己已经论证过）
⛔ 不要放宽拼写去接受散文。 门禁自己的原话：
这条论证成立，⛔ 本卡不推翻它。
⛔ 不要让检查器代填。 同上，声明本身就是判断；代填等于检查器在出裁决。
⛔ 不要靠"下次记住"。 本会话的实测就是反例：规矩明明白白写着，PM 自己在给别人的派单里逐字叮嘱过这个拼写（「本会话刚在 security(rls): refuse RESERVED_RLS_MEMBERSHIP_KEYS by name at the RLS compiler merge #17289 上踩过，⛔ 不要再踩」），然后在自己写的下一条认领评论里又踩了三次。⇒ 记忆不是补救。
值得考虑的方向（⛔ 不是裁定，承接席自己论证）
check-clause2-carriers.mjs的正则里，而席位是在写Claim:评论。若认领模板本身带一行占位（例如 SKILL.md 的认领形状里就含Clause-②: <yes|no>），错误率的来源就消失了。Claim:，而是一个机器可读的、明确指向前一条声明的更正形状），或者明确记载"此状态需要人工介入"并让轮次报告把它列成阻塞项——⛔ 而不是像今天这样，卡在那里没有任何东西会主动说出来。验收（无论走哪个方向）
同一班次里量到的其它过程问题（⛔ 不在本卡范围，各自应当另立）
记在这里只为不再丢一次 —— ⛔ 它们不是本卡要修的东西。
issue_write是整集替换标签，而 PR 创建后有异步的 sizing 工作流在写标签 ⇒ 立刻挂有覆盖风险，等一等就落进门禁点名的 C1「载体挂了一半」。本会话 fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 与 fix(triggers,spec,service-automation)!: a time-triggered flow declares its acting organization and the run executes as it #17334 两条都撞了 C1。type-alias-convention.pin.test.ts真冲突；fix(objectql): the in-memory aggregate lowering asks the driver for rows, so a measurefilterstops being refused on driver-memory (#16642) #17251 早先被另一个包的钉子打红。落地规矩要求「入队前先同步 + 整体重生成」，⛔ 但没有一处告诉席位：一次通过的 CI 会随 main 前进而失效。本会话的对抗式复核席甚至把它误报成「这个 head 上没跑过 CI」。open_questions已不存在 ⇒ 诚实的读数是 NOT MEASURED，⛔ 不是「没有旗」。SKILL.md:641说余席是自审加门禁，而contract-review.md的独立性件写在 spec 席名下 ⇒ 一个隔离复核子代理据后者把本席的自审报成了SELF-REVIEW。两处在效果上打架，需要一句话说清余席自审是规定形状而不是缺陷。check:skill-examples用 exit 1 表达前提缺失（应为 exit 3）⇒ 一次诚实的「没量」在对账里伪装成一条红。本会话被两个互相独立的席位各自撞到一次（A notify node that enqueued NOTHING reports the same as one that delivered:unmeasured=0makes a zero-delivery run indistinguishable from a successful one #17123 那轮、fix(security): OAuth-connected MCP agents run at the delegator's recorded scope, and a narrowed delegated read says so #17332 的重生成轮）。与dispatch-gates --ran's headline "0 NOT-MEASURED" is the runner's claim, not a measurement — a seat whose gates exited 3 still gets a green tick #17204（已合并为501959b72）同族、方向相反。关联
scripts/pm/check-clause2-carriers.mjs（CLAUSE2_KEY_LINE正则、readValueToken、C1 载体分裂与 C2 无读数两类判词）.claude/skills/pm-dispatch/SKILL.md〈入队与落地〉的条款②闸门；references/contract-review.md〈载体纪律〉「PR 与卡双载体同笔挂：PR 一存在即挂」notifydelivers nothing on a multi-organization install: the run carries no organization, so the tenant-scoped inbox/delivery writes are refused (#8844) while the run reads healthy #16659 / 卡 OAuth-connected MCP agents run under themcp_agent_data_*ceiling ∩ user, not "as yourself": a viewAllRecords manager sees 5 accounts / 0 opportunities over OAuth vs 9 / 23 over an API key #16549（第五条仍未解）定级说明
priority:p2：它不改变任何产品行为，但此刻正阻塞一条全绿的 PR，且在一个班次内以 5 次的频率复现、跨两个角色。⛔ 更重的是它能把席位关进一个自己出不去的状态 —— 那类缺陷的代价不是时间，是需要仓库外的人介入才能继续。