docs(pm-dispatch): decision card before popup — AskUserQuestion is a presence accelerator only (#11226)

The PM skill's self-description already routes maintainer decisions to
`needs-user-decision` cards, but the body never stated the ORDER between a card
and a blocking popup. Seats therefore treated AskUserQuestion as the default
channel: the whole seat round halts while it is pending, and its content lands
on no queryable surface.

Three rules now sit in "升级与决策", where a seat reads them at decision time:

1. Card first — file the `needs-user-decision` card as the first action
   (options + recommendation + evidence + facet block, the same content the
   popup would carry); the blocked execution card takes `pm:blocked` +
   `Blocked-by:` in the SAME write; the rest of the queue keeps moving.
2. AskUserQuestion is a presence accelerator only — allowed when the maintainer
   gave human input in this session within ~30 minutes, every ask carries a
   recommended option, a Skip or a long-pending ask falls back to the card
   channel and is never re-popped.
3. Batch intake — the maintainer saying 「处理决策卡」 sweeps every open
   decision card for one batch ruling, the standing trigger for the already
   ruled "定期和ai讨论" consumption path.

Paid for by genuine deletion in the same file (line ratchet 682/682, unchanged):
duplicated enumerations that references/decision-analysis.md and
references/dispatch-runbook.md already own verbatim, plus one narrative case
that belongs on a card. Payment ledger in the PR body.

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude[bot]

.claude/skills/pm-dispatch/SKILL.md

@@ -428,9 +428,8 @@ dev 侧推分支要早 —— 远程分支是在飞工作最硬的证据。**死
 - **文件面写两句**(预期落点 + 生产者在别包时报备后按生产者侧修,⛔ 不在消费者侧打补丁
   );**same-day churn 行**(当天合并 ⇒ 先核对当前 main);**在飞重叠拦截**(每轮求交,相交即发四句
   警告,被完全覆盖就停下回报 ⛔ 不硬造 diff)。
-- **翻转公开语义的裁决随卡带全仓 pin 清扫**,两句缺一不可(全仓一轮翻完;翻转后的pin 断言新语义
-  的实质,真非法形状的拒收断言逐字保留 —— 丢第二句就退化成「全仓删光」)。**条件性标准条款命中
-  判据才抄**:多实现面 ⇒ 共享一致性覆盖;拒收用例 ⇒ `code`+`status` 最低断言;过滤/谓词语
+- **翻转公开语义的裁决随卡带全仓 pin 清扫**,两句缺一不可(两句原文见 runbook)。**条件性标准条款
+  命中判据才抄**:多实现面 ⇒ 共享一致性覆盖;拒收用例 ⇒ `code`+`status` 最低断言;过滤/谓词语
   义 ⇒ 编译面清单逐面申报(⛔ 静默略过)。
 - **前提先行(premise-first)写明**:issue 正文是线索不是规格;`premise_still_valid: false` +无 PR 是合法
   且常常有价值的交付 —— 派发词预设 issue 为真,就把好运行变成表面抗命。
@@ -441,9 +440,8 @@ dev 侧推分支要早 —— 远程分支是在飞工作最硬的证据。**死
 作、浏览器/dogfood 验证、逐卡判断的 build 重 M 卡(论证见 `references/dispatch-runbook.md`)。**归档义
 务只落在云卡**;OOM 死的单独重派;判定连同档位写进认领评论。
 
-**云卡四课(① 授权面随 source 不随环境;② 派发词必带自驱条款;③ 交付通道 = 自开 draft PR + 终报
-issue 评论;④ draft PR 一存在立即 `subscribe_pr_activity` 硬步骤)全文见 runbook**;一次性云卡用
-`create_session`,⛔ 不用 create_trigger+fire(维护者 2026-08-07 拍板,trigger 流只留给定时/重复型)。
+**云卡四课全文见 runbook**;一次性云卡用 `create_session`,⛔ 不用 create_trigger+fire(维护者
+2026-08-07 拍板,trigger 流只留给定时/重复型)。
 云会话 `SendMessage` not-reachable 是设计非故障(维护者 2026-08-11 裁定)⛔ 不复测;**接手中断的 dev**:先试 SendMessage 复活,不可用才走接手协议(四条增量见 runbook,⛔ 不重跑原派发词)。
 
 ### 收集
@@ -611,20 +609,22 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
   应该先专注于核心能力」):能力扩张默认从紧,无拉动的声明面按 implementation-first 处置,已发
   布零消费的能力不因沉没成本获得豁免。
 
-推荐意见必须基于这四条轴给出理由;四轴冲突时如实呈现权衡,交维护者拍板。**标准四棱卡面块是落卡与
-升级的必备件**(四棱维护者 2026-08-11 接受;标准块 2026-08-18 裁定「同意」—— 块标准化把提取从 LLM
-理解题降级成 grep;同裁定的摘要视图/批量决裁通道已退役 —— 维护者 2026-08-19:「之前定期生成的决策
-汇总 issue没什么用」;收件箱由维护者定期与 AI 讨论消化,⛔ 不 assign 推送 —— 同日裁定:「我感觉决策
-卡推给我太麻烦了,我需要和ai讨论才能判断,这个还是维持之前的样子。我会定期和ai讨论。」),每张 `needs-user-decision` 卡落卡即带、⛔ 不留待维护者到
-场再补。**四维分析从业务的角度写**(维护者 2026-08-20 裁定,原话:「四维分析应该从业务的角度写我
-才好判断」;实测:实现视角让维护者追问一轮,业务视角当场裁决)—— 只约束 `needs-user-decision` 卡
-与决策箱讨论,dev 派发四维照旧、不强加行业类比;只管新记录,存量 ⛔ 不回改。六项写法要求(一句话
-问题、客户可感知代价的选项表、业务直译与行业类比、四轴业务论证、推荐+回退+置信缺口带低摩擦裁决格
-式、裁后执行段)、落卡分析模板与四棱块固定形状(首行机器可寻标记、四棱各一行中文、字母选项、**强
-制置信缺口行「本分析看不见什么」**)细则见 `references/decision-analysis.md` —— 案例(2026-08-15):两张四棱同向、低风
-险、全绿、已复核的 PR 仍因分析看不见的方向性前提被整体作废 —— 推荐是输入,永不是放行,人工地板不变。
-四棱是四条评估轴的卡面序列化,一一对应,同一个框架不是第二套;也是分诊代裁置信门的输入(见分诊职责)。交互会
-话可另发 `AskUserQuestion`,带标签的 issue 恒为持久记录。
+推荐意见必须基于这四条轴给出理由;四轴冲突时如实呈现权衡,交维护者拍板。**标准四棱卡面块是落卡与升级的
+必备件**(四棱维护者 2026-08-11 接受;标准块 2026-08-18 裁定「同意」;同裁定的摘要视图/批量决裁通道已退
+役 —— 维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么用」;收件箱由维护者定期与 AI
+讨论消化,⛔ 不 assign 推送 —— 同日裁定:「我感觉决策卡推给我太麻烦了,我需要和ai讨论才能判断,这个还是维
+持之前的样子。我会定期和ai讨论。」),每张 `needs-user-decision` 卡落卡即带、⛔
+不留待维护者到场再补。**四维分析从业务的角度写**(2026-08-20 裁)—— 落卡分析模板、写法六项、适用边界与
+四棱块固定形状细则连同出处原话见 `references/decision-analysis.md`;推荐是输入,永不是放行,人工地板不变。
+四棱是四条评估轴的卡面序列化,一一对应,同一个框架不是第二套,也是分诊代裁置信门的输入。
+
+**决策通道优先序:卡先于弹窗**(维护者 2026-08-23 报告:「项目经理干活时经常弹出需要我决策的问题,如果我
+不在旁边工作就卡住了。」)。凡需维护者裁决,第一动作是落 `needs-user-decision` 卡(选项 + 推荐 + 证据 +
+四棱块,与弹窗同内容),被阻塞的执行卡**同笔**挂 `pm:blocked` + `Blocked-by:`
+指向它,队列其余照常消化,⛔ 永不整席等答复。`AskUserQuestion` 只是**在场加速器**:仅当维护者在本会话
+~30 分钟内有过人类输入才可发,每问必带推荐项,被 Skip 或长挂即转卡通道 ⛔ 不重弹 ——
+卡先于弹窗存在,弹窗怎么死盘面都诚实。**回批入口**:维护者说「处理决策卡」= 当轮扫全部 open
+决策卡批量呈报清积压,即上句「定期和ai讨论」的常规触发词,⛔ 不复活已退役的汇总 issue。
 
 ## 护栏(Guardrails,有约束力)