clarify-decisions

澄清决策

这是一套可复用的访谈协议，不是流水线阶段。作为父级项目的子项时，沿用其对话和清单；独立使用时，负责整个访谈，直到达成共识。清单归属遵循待办事项。明确并决定每个可能造成技术债或错误架构的隐含假设。引导词：开放集合、领域、卡片、问题锁定、标准、覆盖图、收尾包。地图（提示词、计划、已知信息）不是领域（代码库、运行时、用户、历史）。

铁律——通道

EVERY QUESTION IS INLINE CHAT WITH FULL CONTEXT.
NEVER use AskUserQuestion, structured MCQ pickers, or any harness UI that
truncates labels, option text, or the "why this matters" line.

会剥除后果的选择器就是另一种访谈。团队风格、权限、截止日期，以及名义上很长的描述字段，都不例外。

铁律——开放集合（不设固定轮次）

THERE IS NO FIXED ROUND COUNT.
NEVER "Question k of N", "last of 5", or "we budgeted four cards".
Stop only when the open set is empty of judgment calls that change
architecture, data, auth/security, UX flow, or implementation scope —
AND, when the production-coverage gate is ON, judgment calls on
reliability, failure, and operate, with no coverage-map cell Missing
without an owner.

开放集合 = 仍未决的高影响未知项 + 上一个答案引出的分支 + 仍需用户确认的父级已知未知项 +（覆盖开启时）缺少负责人的缺失覆盖单元格。核心规则：每次回答后都要重新计算开放集合，然后选择下一张卡片或收尾包。其他所有“重新计算”的说法都指这里。预先列出的待办事项是动态地图，不是配额：添加新出现的分支，移除已解决的事项，只要仍有高影响事项未解决，就绝不收尾。进度压力只会改变你何时汇报进展，不会改变未明说的决策是否存在。待办事项：作为子项时，不建立相互竞争的清单——你在父级清单中开展工作，访谈事项在收尾包得到确认前一直处于进行中状态，开放集合的进度就是该事项的进度，而不是第二个通道；独立使用时，可以维护一个动态的决策领域开放集合清单——仍然每条消息只发一张卡片，仍然每次回答后重新计算；如果父级技能已在执行，绝不另开第二个通道。

生产环境覆盖门槛（何时开启）

开启／关闭判断的唯一依据。开启时，加载并遵循 production-coverage.md（地图、半径、收尾项 7–10）。关闭时，不加载该文件。权限和聊天氛围绝不会改变门槛。在开始绘制地图前评估一次（只有书面要求、简报标记或运维／发布范围发生变化时才重新评估）。仅当以下三项全部满足时才开启：

1. 阶段范围——书面交付意图为 Production，且生命周期为 Cut Released / Scaling / Maintenance（父级项目或 docs/agents/project.md）。
2. 完整路径访谈——父级未将本次访谈标记为 tier 0 或 brief。
3. 范围锁定——涉及运维／发布范围（告警、回滚、SLO、值班、部署／接管、新故障域），或用户／父级明确要求覆盖运维／可靠性。

其他情况一律关闭——包括未指定阶段要求；MVP · Run Spike · Research · Learning；生命周期为 Idea · Early · Active development；不涉及范围锁定的润色／文案／重上色；以及未同时满足书面阶段范围和范围锁定条件的“培养 SRE 习惯”对话。关闭时：完全省略覆盖图；不使用 reliability / failure / operate 半径；收尾时省略第 7–10 项。核心收尾项 4–6（成功、边界、主线）和问题锁定仍然适用。

起始地图（首张卡片之前）

加载父级 Knowns、Blindspot 和扫描摘要（如果存在，例如 .skills/<CODE>/{knowns,scan}.md 或 _pending-<slug> 对应文件）。说明 Coverage ON 或 OFF（如果为 OFF，指出未通过哪项门槛），然后给出一份简短的思路伙伴地图：

1. 已锁定 — 固定立场、不可妥协事项、摘要事实。
2. 覆盖地图 — 仅在 ON 时提供（表格 + production-coverage.md 中的单元格方案）。
3. 未解决的高影响项 — ON：该文件中的 Missing/Partial 单元格；OFF：仅限架构/数据/认证/UX/范围方面的分歧。
4. 如何收尾 — 判断卡片；事实问题参考 / run-spike / research；盲点问题先讲解再提问；仅在 ON 时使用 Operate 路径（参见 production-coverage.md）。

仅当某项锁定内容有误时才邀请纠正。首张卡片：满足条件时用 问题锁定，否则选择影响最大的未解决项（ON 时优先选择覆盖缺失的单元格）。如果父级已经说明这份地图 → 不要重述；ON 时，回答后仍须更新覆盖情况。

问题锁定（偏好卡片之前）

本规则的归属位置。 其他部分只需指向这里。在一张 问题锁定卡片 上给出 2–4 条备选问题陈述（每条包含 Observed · Desired · Non-goals）。绝不提供解决方案形态的选项菜单。

问题锁定卡片：当父级 knowns 表明存在方案导向的 Assumptions（指定的 API、标志、合并操作，或“只要做 X”）或没有明确的期望结果 / 成功信号时，且上方的分支已指定卡片路径时，使用问题卡片方案；Thread This card 写明问题锁定。正文 MUST 对所选陈述中的以下三项全部加以锁定（选项 = 备选问题陈述，而非实现方案）：

• Observed — 谁正受到影响 / 当前事实
• Desired — 完成后可观察到的结果（不是“它能运行”）
• Non-goals — 明确排除的事项

关闭：known-unknown（问题陈述）。资深人员说“别讲理念 / 直接选 API 选项”、站会时间紧迫，以及“别让我去另一个技能”，均不能免除此部分。

问题卡（每轮）

每条消息只能做出一个决策。每个字段都必须填写。第一张卡需加载 card-recipe.md（字段扩展、Shape、推荐论据）。如果父级没有提供已确认的示例， 则加载 example.md。如果功能工作涉及相邻功能、重叠或复用，必须在第一张卡之前加载 feature-retrieval.md；否则不要加载。

1. 范围 — architecture · data · auth/security · UX flow · polish-diff。Coverage 为 ON 时还包括 reliability · failure · operate。
2. 线程 — 目前已锁定 · 本卡 · 完成后仍待解决（写出名称，绝不要写“5 项中的第 3 项”）。
3. 领域 — 以仓库事实为依据；在此说明阻碍进展的盲点；不要臆造；不要要求用户回忆你能读到的信息。
4. 问题 — 用通俗语言表述决策。
5. 重要性 — 仅说明影响范围的叙述（如果答案改变，哪些内容需要重写）。评分标准见第 7 项。
6. 关闭类型 — known-unknown · unknown-known · blindspot-confirm。
7. 标准（评分项） — 对影响范围大的类型必须填写（仅 polish-diff 可省略）：在选项上方列出 1–2 个具名的通过/失败评分项。推荐必须按名称引用评分项。
8. 选项（2–4 个） — 说明收益、代价、可能的故障，以及更适合的情况。仅有标签不算选项。 Shape — 对 architecture 或 data 的每个选项都必须填写：面向调用方的差异（签名、类型、列、路由、载荷），≤6 行，不含实现正文。只在文字中提及某个制品不算 Shape。“与选项 1 相同，但……”不算。 参考方案 — 如果决策涉及已由产品实现的功能（删除后撤销、共享与访问、邀请、重试、通知、搜索），第一个选项必须是经验证的参考方案，并根据需求裁剪。编写方法见 card-recipe.md § Reference。
9. 推荐 — 选择 · 决定性因素 · 次选方案 · 接受的权衡 · 信心/证据缺口 · 重新开启的触发条件（必须可观察；“如果需求改变”不算触发条件）。
10. 停止。 等待。重新计算未解决项集合，然后生成下一张卡或结束套餐。

显示顺序：Radius → Thread → Territory → Question → Why it matters → Closes → Criteria → Options → Recommendation → Stop。

顺序与覆盖范围

• 先处理影响范围最大的事项。 先处理架构、数据、公共 API、身份验证/安全、UX 流程或范围，再处理润色——即使用户从润色开始。
• 覆盖顺序（启用时）：production-coverage.md（先处理 Missing，再处理 Partial）。未解决项集合为空时停止。事实放在领域中；只有需要人工决策的锁定项才生成卡片。
• 兼容性义务。 从 docs/agents/project.md 的 Project posture 中读取——优先采用书面说明，否则根据 Lifecycle 推导（Idea / Early / Active development → None；Cut Released / Scaling / Maintenance → External）。处于 None 时，architecture 或 data 卡片中的选项和推荐必须落在单一方案上，不留任何遗留内容。处于 None 时，平行列、同步触发器、v2 名称或弃用期都属于缺陷。处于 Internal / External 时，这些成本必须作为首要考量。交付意图决定质量门槛，不决定兼容性结论。
• 团队规模。 以人员名单或工作流规模覆盖项为准 → 根据该部分打包。绝不要臆造团队。

仅进行访谈。盲点：沿用父级列表。问题：遵循问题锁定。范围分解：交还给父级。未知的已知事项：引用 / run-spike / research，然后生成一张结果卡。

Close package（必需）

当开放项中不再有影响范围大的判断分歧时，且在将控制权交还给上级或声称已达成共识之前，输出：

1. 决策表 — 行：范围 · 主题 · 决策（用户原话）· 已关闭的未知类别。
2. 约束块 — 可直接粘贴的锁定项（先列架构和数据；Coverage 开启时，接着列可靠性／故障／运维；最后列润色差异）。标出与高范围锁定项冲突的低范围回答。
3. 高变动面 — 在真实实施压力下最可能改变的锁定项（数据模型、类型接口、UX 流程）。机械式重构应留在底层；此处不要再次访谈确认。
4. 成功／完成信号 — 1–3 个可观测指标，表明“已完成”（可粘贴到 requirements.md / NFR）。如果已梳理 Journey，优先采用符合 CUJ 的可观测指标。不要写“能用”／“已达成共识”。
5. 边界 — 不涉及（不会做）和必须继续正常工作（防护措施／保持不变的行为），即使只有 2–4 条也要列出。若存在问题锁定项中的非目标和 (guard) 形式的锁定项，应以它们为依据。
6. 架构主干关联 — 当存在 docs/architecture/（或同等的 ARCH 主干）时：Respects: ARCH-N… · none · 或 challenges（需要 ADR）。不存在时：写 none — no architecture spine。不要编造 ARCH ID。 7–10. Coverage 最终状态 · 已明确归属的未知项 · 已接受风险 · 运维关联 — Coverage 开启时必需；步骤仅见 production-coverage.md。关闭时省略。
7. 明确确认 — 这是否是共同认可的方案？只有对这份方案的肯定答复才算数。

第 4–6 项始终必需。第 7–10 项仅在 Coverage 开启时必需。以下不算确认：“还有其他问题吗？”、“我们意见一致，跳过表格吧”、“直接去写需求吧”、“可靠性是以后再写的 NFR”，上级施压要求跳过流程，或保持沉默。如果用户纠正某一行，修改后再次确认。如果确认过程引出新的高影响分歧或缺失项，则返回卡片。确认完成前，不要执行任何操作——不得编写生产代码、搭建脚手架或执行计划。（访谈期间术语确定后，可通过 define-domain 被动更新术语表／CONTEXT.md。）

合理化借口

想法	事实
“团队风格／负责人说要用选择器”	通道是铁律。使用一张行内卡片。
“评分者都列出来了，给一行建议就够了”	说明所选方案为何胜过次选方案、权衡、证据缺口以及重新开启的触发条件。
“把成功标准写进 Why／别写标准说明”	Why 表示影响范围；Criteria 是 Options 上方独立的评判标准。
“四个方面都完成了／先问 5 个问题中的第 3 个，然后整理方案”	开放项清空才是停止条件。
“用户先问按钮颜色”	先看影响范围。架构、数据和身份验证之后再处理润色。
“我们意见一致／上级说直接写需求”	共同认知就是方案加上肯定答复。
“他们已经指定了便宜的路径／跳过原理，直接选 API 方案”	以解决方案为导向的假设不是锁定项。遵循问题锁定。
“我了解这个领域——我会根据代码列出方案”	分享、撤销、邀请：有人已交付这些功能，用户也已在其中形成习惯。从那个产品出发再做取舍。凭空列出的方案往往会导致过度构建和奇怪的设计。
“成功／边界／架构主干应该留到后续阶段”	此处必须填写第 4–6 项。
“为了安全，尽量兼容／在没有任何旧版本仓库的情况下使用 v2 名称”	兼容义务为 None：只保留一种形态。使用 v2 名称、并行列或弃用过渡期都是缺陷。
“可靠性以后再说／跳过映射”	Coverage 开启时：缺失单元必须保持开放。额外行见 card-recipe.md。

危险信号——停止并重写本轮对话

• 调用 AskUserQuestion 或任何会截断选项的多项选择题工具
• 一条消息中面向用户的问题标记多于一个（选项文本中的示例除外）
• 卡片缺少 Thread、Territory、Why、Closes、选项后果、高影响范围 Criteria 或推荐理由
• Problem lock 生效时，在没有对应卡片的情况下提供偏好选项或解决方案菜单
• 高影响范围问题仍未解决时，使用“Question k of N”或以计数收尾
• 架构／数据／身份验证（或 Coverage ON 时的 R/F/O）仍未解决，却优先给出润色差异
• 收尾方案缺少 Success、Boundaries 或 Spine touch，或将“我们已达成一致”视为确认
• Coverage ON 时缺少地图／第 7–10 个槽位，或 Coverage ON 时任一门槛部分未通过
• Compat obligation None 时提出 v2 名称、并行列、同步触发条件或弃用窗口
• 针对已在现有产品中推出的功能制作卡片，但选项中未提及任何产品
• 臆造 SLO-N／TB-N／THR-N ID；将 Owned 未知项合并到 Accepted 风险中