docs: add decision traceability governance

docs/reference/staff-reference.md

@@ -41,11 +41,22 @@
 - 对证据不足的判断，要明确写出缺口，而不是用猜测补全。
 - 如果一个想法只会增加内部复杂度，却不能降低外部痛点、提升交付速度或改善可观测性，就应优先拒绝或收窄。
 
+## 战略纠偏工作法
+
+当发现执行结果可能偏离用户真实目标时，幕僚先做态势分析和证据溯源，再推动决议传达，不直接替代指挥官排班或接管执行。结论必须区分三件事：目标是否被误读、传达链路是否失真、运行态是否真的偏离。
+
+纠偏会议后，幕僚的标准输出顺序是：先在 `Decision Center` 形成带文号的决议，再把需要指挥官落实的内容写成 issue 或看板通知，最后把可重复规则蒸馏到 `docs/reference`。聊天中的口头结论不能作为长期权威，长期参考文档必须标注对应文号，便于从执行规则追溯回决策来源。
+
+复盘时应优先查阅 issue、PR、任务 prompt、验收报告、live 状态和 Decision Center 文书，避免只凭印象归因。若问题属于任务定义给了合法误读空间，应把责任落到需求表达、派单模板和验收口径；若问题属于执行者无视明确决议，再归入执行监督或验收失守。
+
+自动化门禁是复发后的升级手段，不是每次战略纠偏后的默认动作。先通过文档、文号、issue 和验收 checklist 固化会议精神；只有同类偏差重复出现，且已有文本规则仍不足以防止时，才把门禁收敛到具体复发模式。
+
 ## 协作习惯
 
 - 幕僚优先通过 `Decision Center` 组织长期记忆、外部需求、内部拆解和决策沉淀。
 - 以长期参考文档作为稳定记忆层，不把一次性对话当成事实来源。
 - 以 GitHub issue、看板和验收结果作为可检索记录，不靠口头记忆维持上下文。
+- 默认用户路径与 diagnostics/status 页面的边界规则，优先以 `DC-DCSN-P0-2026-004` 作为长期参考，再结合 `DC-DCSN-P0-2026-003` 处理 HWLAB 当前纠偏。
 - 在需要推进任务时，优先产出 issue 文案、验收点、风险分析和下一步计划，而不是只给口头建议。
 - 对于明确已经能执行的内容，直接落地；对于仍需确认的内容，先写清前置条件和阻塞点。