docs: add decision traceability governance

docs/reference/frontend.md

@@ -31,6 +31,8 @@ Code Queue 的 queue 合并弹窗是该公共组件的首个业务复用示例
 
 `server rebuild frontend` 只保留为维护/非标准路径，不得作为标准发布证据。正式 frontend 发布必须通过 `ci publish-user-service --service frontend` 产出 commit-pinned image，再由 `deploy apply --env dev|prod --service frontend` 消费。
 
+如果一个用户服务同时存在主用户路径和 diagnostics/status 路径，默认路由必须优先呈现主用户路径，diagnostics/status 只能作为显式二级入口或标签页，不得替代默认产品页。该边界规则的追溯文号是 `DC-DCSN-P0-2026-004`。
+
 如果公网仍是旧界面：1. 确认 job 已成功且容器创建时间晚于代码修改；2. 强制刷新或开无痕窗口；3. 用 curl -H "Cache-Control: no-cache" http://74.48.78.17:18081/app.js 查新 bundle。
 
 ## Time Zone Contract

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 文案、验收点、风险分析和下一步计划，而不是只给口头建议。
 - 对于明确已经能执行的内容，直接落地；对于仍需确认的内容，先写清前置条件和阻塞点。
 

docs/reference/strategy-governance.md

@@ -1,6 +1,6 @@
 # Strategy Governance
 
-This document owns the strategic filter for UniDesk requirements: external-benefit traceability, short-term versus long-term investment, and anti-loop guardrails for architecture proposals. The analysis record for the current strategy framing is [GitHub issue #7](https://github.com/pikasTech/unidesk/issues/7).
+This document owns the strategic filter for UniDesk requirements: external-benefit traceability, short-term versus long-term investment, and anti-loop guardrails for architecture proposals. The analysis record for the current strategy framing is [GitHub issue #7](https://github.com/pikasTech/unidesk/issues/7). The long-term governance follow-up for the default user path versus diagnostics/status boundary is `DC-DCSN-P0-2026-004`.
 
 ## Scope
 
@@ -98,6 +98,12 @@ When a new idea is proposed, classify it immediately:
 
 The default bias should be toward the simplest path that satisfies the external need. Complexity is only justified when it pays for itself in visible external value.
 
+## Default Path Boundary
+
+When a product surface has both a primary user workflow and an internal diagnostics or acceptance surface, the primary workflow must remain the default discoverable entry. Diagnostics and status pages may exist for verification, recovery, or observability, but they do not become the product's headline or default route unless a decision record explicitly says so.
+
+For the current HWLAB case, `DC-DCSN-P0-2026-003` freezes the short-term product direction, and `DC-DCSN-P0-2026-004` records the longer-term governance rule for keeping the default path distinct from diagnostics/status surfaces.
+
 ## Relationship to Other Governance Docs
 
 - `docs/reference/release-governance.md` owns release lines, stabilization windows, runtime pinning, and feature-flag governance.

docs/reference/user-service-delivery.md

@@ -60,6 +60,8 @@ The current catalog covers `frontend`, `baidu-netdisk`, `decision-center`, `proj
 
 Many user services are surfaced through the UniDesk frontend rather than through their own browser-exposed product. When a user-service backend has a paired UniDesk frontend page, the frontend change must be validated in the same dev/prod release window as the backend artifact. The frontend itself is also a reviewed artifact producer/consumer sample: its release unit is `127.0.0.1:5000/unidesk/frontend:<commit>`, and the live UI must expose the same requested commit through image labels and `/health.deploy.commit`.
 
+The paired frontend's default route must continue to expose the real user workflow. Diagnostics or status surfaces may exist for verification and recovery, but they must stay explicit secondary routes and must not replace the default product entry. The traceability record for this boundary is `DC-DCSN-P0-2026-004`.
+
 ## Frontend
 
 Frontend is the canonical user-service UI sample. It is not released by target-side source build as the standard path.
@@ -152,6 +154,7 @@ Decision Center is the canonical example of a user service that doubles as a pro
 - Before any production deploy, the dev gate must pass first with the focused Decision Center E2E set covering `microservice:decision-center-record-crud`, `microservice:decision-center-diary-lifecycle`, `frontend:decision-center-visible`, `frontend:decision-center-demand-management-visible`, and `frontend:decision-center-diary-visible`; this is an automated user-service validation gate, not a production deploy.
 - Document-management changes must first land in the D601 dev Decision Center service and extend the focused E2E set with doc-number creation/upsert/list/detail uniqueness, migration/backfill, frontend visibility and temporary body-prefix compatibility before production rollout.
 - Production acceptance is manual after the dev gate and must explicitly verify `health`, `records`, `diary editor`, the paired frontend page, no public business ports, and live commit / artifact information.
+- Acceptance notes may cite diagnostics/status pages as evidence, but those pages must be labeled as diagnostics and not as the default user workflow.
 
 Detailed service-level API and UI contracts remain in `docs/reference/microservices.md`.