[Decision] Skills lane — batch 6 (3 items): execution-seat promotion of same-family findings · extend ruling 3B to objectui CLAUDE.md · check-ratchet-remedy-authority walk over scripts/pm/** #14978

os-decision-facets

Filed by the skills seat (session session_019RfFHiRCSs3JXLK4cwcfox, GitHub os-steve), 2026-09-03T16:2xZ. Decision batch 6 of the skills lane (batch 5 = #14909, unruled). Three items, each a human-floor question (protocol/remit change, governed-surface ruling extension, gate-strength widening); ⛔ none is dispatchable before a ruling. Premises re-verified on origin/main 5bc2f27 (objectstack) and 0e3b3be (objectui) at 16:17Z with the re-check commands inline. Reply shape: 「1A 2B 3A」 (with 「X, 但…」 for conditions). 四维分析按业务角度、中文(2026-08-19 / 08-20 裁定)。(Body revision 2 at 16:2xZ: one typo in a quotation corrected — 「跨仓」; content otherwise identical to revision 1.)

Dropped from this batch after measurement: #14445 ①1 (objectui packages/types lane ownership) is not a decision — the rule already exists in writing: references/lanes/spec.md:12 「objectui 的契约面同辖:packages/types、schema/$schema 语料、@objectstack/spec pin 耦合与契约决策」 and SKILL.md:201-203 「objectui 卡按修复落点分流三流 … domain:spec(契约面)跨仓归各自车道」. The seven mis-routed cards are a triage-application matter (pm:retriage is already open on objectui#6910); recorded on #14445, not escalated. #14445 ② (a strip-pm:*-on-close workflow) was ruled not_planned on 2026-08-31 (批 #13, #13901) and is not re-opened.

1. 执行席能否凭母单裁决自行晋级本车道的 finding(#14445 ①2)

一句话问题:一张 finding 的方向已被母卡上的维护者裁决完全决定,执行席手里有裁决、有空槽,却只能等分诊席下一轮来定级 —— 要不要允许执行席在引用母单裁决的条件下自己把它推进队列?

背景:finding = 待首次定级,定级只由分诊席产出(单一生产者;skills 车道自分诊是唯一例外)。objectui#7200 就是这种卡:母卡 objectstack#13626 的维护者裁决已定方向,spec@objectui 席在上限 5 下空转,只能靠维护者当场直派通道桥接(出处在卡上)。同族元判据「兄弟支已裁 ⇒ 复用母单裁决直接入队」今天只对 needs-user-decision 卡成立(SKILL.md:848)。

前提(带 re-check):git grep -n "兄弟支已裁" origin/main -- .claude/skills/pm-dispatch/SKILL.md → :848(阳性对照 finding 自分诊 → :230 :409);分诊席今晚在班(#6015 🟢 15:10Z),对本车道裸卡首触延迟约 1 小时。

业务含义:A = 「已判过的案子,执行部门可以照判决直接开工,法务保留撤回权」;B = 「每张单子都过一次立案窗口,哪怕判决已经写在案卷里」。

四轴:

• 长远(≥50%):单一生产者是分诊的结构性设计(双生产者并存即失守);A 靠「引用母单裁决」这一可核条件把例外收窄成机械判据,与既有异议窗形状同构,不是新机制;但它把「裁决是否真的决定方向」的判断交给有动机的一方。
• 业务拉动:一例实测(objectui#7200);今晚分诊在班,延迟约一轮 —— 拉动存在但小。
• 防 AI 犯错:B 结构上更难写错(零新判断点);A 的错法是「引一条不相干的裁决自证同族」,响亮度取决于分诊是否回看 —— 异议窗是事后的。
• 不扩散:B 零改动;A 加规则行 + 一个新的晋级评论形状。

推荐 B(不扩散);回退 A,条件收紧为「母单裁决评论必须点名该 finding 的文件面或缺陷类,晋级评论引其 comment id」。置信缺口:本分析看不见分诊首触延迟的稳态(只有两个点:1 小时、4 小时);若延迟屡超一轮,A 的拉动就成立。

裁后执行:B ⇒ #14445 ①2 记「维持」关项,无 PR;A ⇒ skills 车道一趟 fable 档 SKILL.md 单行卡(删减付账),分诊席收到通知即按新形状复核。

os-decision-facets
① 项目长远合理性:B 守住单一生产者,零新判断点;A 把例外机械化但仍是第二写手。
② 实际业务拉动:一例实测 + 分诊延迟约一轮 —— 小拉动。
③ 防 AI 犯错:B 无新错法;A 的错法(引错母单)只在事后被看见。
④ 创业阶段不扩散:B 零改动;A 加规则行与新评论形状。
推荐:B;回退 A(收紧条件)。
本分析看不见什么:分诊首触延迟的稳态分布。

2. 把 #14685 项 3 的裁决 B 延展到 objectui 的 CLAUDE.md(objectui#7506)

一句话问题:objectstack 的 CLAUDE.md 已按你的裁决从 86 行收成 36 行(规则一句 + 钩子 + 指向 AGENTS.md 的指针);objectui 的 CLAUDE.md 还是同一旧形状(51 行,两段手抄 AGENTS.md 全文,首段还写着「the one rule」而实际内嵌两条)—— 同一裁决要不要覆盖它?

前提(带 re-check):git -C /home/user/objectui show origin/main:CLAUDE.md | wc -l → 51(ba55fb5,2026-08-31);grep -n "the one rule" → :4;grep -n "guard-main-checkout\|guard-shared-stash" → :20 :43(guard-main-checkout-bash.sh 未被点名,而 .claude/settings.json:36 已挂它)。objectstack 侧裁决:#14685 项 3 = B(director 记录 5520452691,原话「同意，然后执行契约复审」),PR #14855 5290fcbe91 已落 main。

业务含义:A = 「两间办公室贴同一张门禁告示」;B = 「一间贴告示,另一间贴整本手册的复印件」。

四轴:

• 长远(≥50%):同一裁决同一形状,叙事只在 AGENTS.md 维护一次;两仓的 agent 是同一批。
• 业务拉动:每个 objectui 会话都读它(注入面),按行计税;首段与 hook 名单的两处事实错误已实测。
• 防 AI 犯错:指针 + 钩子名让 agent 找到强制点而不是复述;手抄复制品是漂移温床(objectstack 侧已测出两处漂移)。
• 不扩散:只删不增(shrink-only)。

推荐 A;回退 B。置信缺口:未逐字比对 objectui AGENTS.md:234-243 是否已含 CLAUDE.md 手抄段的全部实测叙事(若有缺,收缩时要先搬回 AGENTS.md,即多一处 governed 改动)。

裁后执行:skills 车道,objectui 一趟 S 卡(#7506),opus 施工 + 席内 fable 复核,governed ⇒ draft、请审 os-zhuang + hotlong、人合。

os-decision-facets
① 项目长远合理性:A —— 同裁决同形状,叙事单点维护。
② 实际业务拉动:每会话注入面按行计税;两处事实错误已实测。
③ 防 AI 犯错:指针 + 钩子优于手抄复制品(objectstack 侧已测出漂移)。
④ 创业阶段不扩散:A 只删不增。
推荐:A;回退 B。
本分析看不见什么:objectui AGENTS.md 是否已完整承载被删叙事。

3. check-ratchet-remedy-authority 的扫描是否扩到 scripts/pm/**

一句话问题:「门禁不得把『扩大名单/抬上限』当补救建议随手交给 agent」这条约定(#8435)由一道门强制,但那道门只扫 scripts/ 顶层,PM 循环自己的 14 个门禁(scripts/pm/*.mjs,含行数棘轮、派发门禁、半状态巡查)从来不在扫描面内 —— 要不要把它们纳入?

前提(带 re-check):git grep -n "NON-RECURSIVE" origin/main -- scripts/check-ratchet-remedy-authority.mjs → :43 :242(「never scripts/pm/」);ls scripts/pm/*.mjs | wc -l → 14;PR #14860 已钉一条自测:扩宽扫描即红(把扩面变成显式决定而非静默落地)。⚠️ 未测量:14 个脚本中有几个向读者交出扩张类补救(候选:行数棘轮的「抬上限」文案 —— 其头部已用散文写明抬限归维护者裁决)。

业务含义:A = 「审计范围补上审计部门自己」;B = 「审计部门自己免检,写进章程」;C = 「顺便把所有楼层都审一遍」。

四轴:

• 长远(≥50%):约定只覆盖一半门禁是 declared≠enforced 形状;A 把 PM 自己的门纳入同一强制,与「AI 有把 CI 弄绿的结构性动机,削弱农场必须是人的动作」同向。
• 业务拉动:零事故;但行数棘轮正是本车道最常交出「抬上限」建议的门,而抬限恒为人工地板。
• 防 AI 犯错:A 机械化「PM 门禁不得递出扩张补救」;B 靠 14 个脚本各自的散文。
• 不扩散:B 零改动;A 一次名册 + 一行扫描面;C 面积未测。

推荐 A(测量先行:名册先出、再标);回退 B(成文的免检比隐性的免检好)。置信缺口:名册大小未测 —— 若 14 个脚本中命中为零,A 只剩一行扫描面改动,代价几乎为零;若命中多且涉及自测判定,一次落地可能拆两趟。

裁后执行:A ⇒ skills 车道 S/M 卡(纯代码,scripts/check-ratchet-remedy-authority.mjs + 命中的 scripts/pm/** 脚本;domain:devx 与 domain:skills 的分界按 SUBJECT —— 该门治理 governed 面的门禁本身,归 skills),席内契约档复核后入队;B ⇒ 一行自述 + 关闭本项。

os-decision-facets
① 项目长远合理性:A —— 约定覆盖 PM 自己的门,消除 declared≠enforced。
② 实际业务拉动:零事故;棘轮门天然递出「抬上限」,人工地板项。
③ 防 AI 犯错:A 机械强制;B 靠散文。
④ 创业阶段不扩散:B 零改动;A 一次名册(大小未测)。
推荐:A(测量先行);回退 B。
本分析看不见什么:14 个 PM 脚本中递出扩张补救的实际数目。

Refs: #14445 (①2 的出处) · objectui#7506 · PR #14860 (item 3 的自测钉) · #14685 (item 2 的母裁决) · #14909 (batch 5)