[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

Open
Open
[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
Labels
needs-user-decisionpriority:p3

Description

@os-steve
os-steve
opened on Sep 3, 2026

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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手

业务含义: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 #148555290fcbe91 已落 main。

选项做什么真实代价
A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续

业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录

业务含义: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)

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-user-decisionpriority:p3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

      Skip to content
      [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
      Open
      Open
      [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
      Labels
      needs-user-decisionpriority:p3
      Description
      @os-steve
      os-steve
      opened on Sep 3, 2026
      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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
      B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
      业务含义: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 #148555290fcbe91 已落 main。
      选项做什么真实代价
      A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
      Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
      业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
      B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
      C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
      业务含义: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)
      Activity
      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        needs-user-decisionpriority:p3
        Type
        No type
        Projects
        No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

          Skip to content
          [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
          Open
          Open
          [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
          Labels
          needs-user-decisionpriority:p3
          Description
          @os-steve
          os-steve
          opened on Sep 3, 2026
          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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
          B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
          业务含义: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 #148555290fcbe91 已落 main。
          选项做什么真实代价
          A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
          Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
          业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
          B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
          C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
          业务含义: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)
          Activity
          Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            needs-user-decisionpriority:p3
            Type
            No type
            Projects
            No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

              Skip to content
              [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
              Open
              Open
              [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
              Labels
              needs-user-decisionpriority:p3
              Description
              @os-steve
              os-steve
              opened on Sep 3, 2026
              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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
              B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
              业务含义: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 #148555290fcbe91 已落 main。
              选项做什么真实代价
              A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
              Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
              业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
              B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
              C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
              业务含义: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)
              Activity
              Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                needs-user-decisionpriority:p3
                Type
                No type
                Projects
                No projects
                  Milestone
                  No milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions
                  
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

                  Skip to content
                  [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
                  Open
                  Open
                  [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
                  Labels
                  needs-user-decisionpriority:p3
                  Description
                  @os-steve
                  os-steve
                  opened on Sep 3, 2026
                  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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
                  B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
                  业务含义: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 #148555290fcbe91 已落 main。
                  选项做什么真实代价
                  A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
                  Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
                  业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
                  B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
                  C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
                  业务含义: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)
                  Activity
                  Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
                  Metadata
                  Metadata
                  Assignees
                  No one assigned
                    Labels
                    needs-user-decisionpriority:p3
                    Type
                    No type
                    Projects
                    No projects
                      Milestone
                      No milestone
                      Relationships
                      None yet
                      Development
                      No branches or pull requests
                      Issue actions
                      
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

                      Skip to content
                      [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
                      Open
                      Open
                      [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
                      Labels
                      needs-user-decisionpriority:p3
                      Description
                      @os-steve
                      os-steve
                      opened on Sep 3, 2026
                      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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
                      B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
                      业务含义: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 #148555290fcbe91 已落 main。
                      选项做什么真实代价
                      A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
                      Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
                      业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
                      B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
                      C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
                      业务含义: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)
                      Activity
                      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
                      Metadata
                      Metadata
                      Assignees
                      No one assigned
                        Labels
                        needs-user-decisionpriority:p3
                        Type
                        No type
                        Projects
                        No projects
                          Milestone
                          No milestone
                          Relationships
                          None yet
                          Development
                          No branches or pull requests
                          Issue actions
                          
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

                          Skip to content
                          [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
                          Open
                          Open
                          [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
                          Labels
                          needs-user-decisionpriority:p3
                          Description
                          @os-steve
                          os-steve
                          opened on Sep 3, 2026
                          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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
                          B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
                          业务含义: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 #148555290fcbe91 已落 main。
                          选项做什么真实代价
                          A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
                          Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
                          业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
                          B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
                          C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
                          业务含义: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)
                          Activity
                          Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
                          Metadata
                          Metadata
                          Assignees
                          No one assigned
                            Labels
                            needs-user-decisionpriority:p3
                            Type
                            No type
                            Projects
                            No projects
                              Milestone
                              No milestone
                              Relationships
                              None yet
                              Development
                              No branches or pull requests
                              Issue actions
                              
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

                              Skip to content
                              [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
                              Open
                              Open
                              [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
                              Labels
                              needs-user-decisionpriority:p3
                              Description
                              @os-steve
                              os-steve
                              opened on Sep 3, 2026
                              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/main5bc2f27 (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允许执行席把本车道 finding 转 pm:queue,条件:晋级评论逐字引用母单裁决评论(带可取回的 comment id);分诊席可 pm:retriage 撤回(异议窗)分诊「单一生产者」出现第二写手;席位有给自己喂活的动机;SKILL.md 加一行(零余量,需删减付账)
                              B维持现状:只有分诊席定级;维护者在场时走直派通道空槽等分诊一轮(实测约 1 小时,曾达 4 小时);每次绕行都要维护者当场出手
                              业务含义: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 #148555290fcbe91 已落 main。
                              选项做什么真实代价
                              A延展 B:两段各收成「一句规则 + 强制钩子(含两条 hook 与覆盖开关)+ 指向 AGENTS.md → 9. Operational Rules → 多 agent 协作纪律 的指针」,首段改「each of the two rules」;51 → 约 25 行;标题字节不变一次 governed PR(draft、人合);叙事只留在 AGENTS.md 一处
                              Bobjectui 保留长形每个 objectui 会话每次开局多读约 26 行手抄叙事;两仓两形状;首段的事实错误(「one rule」)继续
                              业务含义: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扩到 scripts/pm/**(先在丢弃 worktree 里跑一次扩宽扫描出名册,再把命中的脚本按约定标 ⛔ MAINTAINER-ONLY 或改为拒绝,一个 PR 落地)一次名册整理;此后 PM 门禁每次交出扩张补救都要过这道门
                              B维持顶层扫描,把「scripts/pm/ 不在约定内」写进门的自述(现状成文)PM 门禁 —— 恰是 AI 席位天天跑的门 —— 继续靠散文纪律防「自抬上限」
                              C递归扫全部 scripts/**名册更大(未测量),可能牵出与本问题无关的子目录
                              业务含义: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)
                              Activity
                              Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
                              Metadata
                              Metadata
                              Assignees
                              No one assigned
                                Labels
                                needs-user-decisionpriority:p3
                                Type
                                No type
                                Projects
                                No projects
                                  Milestone
                                  No milestone
                                  Relationships
                                  None yet
                                  Development
                                  No branches or pull requests
                                  Issue actions