pikasTech-HWLAB/docs/reference/user-feedback-triage.md

HWLAB 用户反馈分流规则

本规则固化 pikasTech/HWLAB#122，是 HWLAB 用户反馈分流规则的唯一维护处：用户和参谋提出的问题默认按高优先级用户反馈处理，并必须挂到 pikasTech/HWLAB#7 的醒目位置。

默认判定

• 用户直接提出的问题、阻塞、体验不满、验收异议和方向纠偏，默认视为高优先级用户反馈。
• 参谋、指挥官或 reviewer 代表用户提出的问题，默认也按高优先级用户反馈处理。
• blocked、blocker、环境不可用或等待上游只能描述执行状态，不能替代用户反馈分流；被阻塞的用户反馈仍要保留高优先级、来源、影响范围和下一步。
• 只有明确属于普通内部整理、低风险技术债或已被用户降级的事项，才可降为普通优先级。
• 与 DC-DCSN-P0-2026-003 / #78 冲突的反馈不能被忽略；必须先在 #7 标明冲突，再由指挥官决定排序。

必须进入 #7

分流时必须在 #7 醒目位置保留：

• 反馈来源：用户、参谋、reviewer 或具体 issue/PR。
• 反馈摘要：用中文一句话描述可执行问题。
• 影响范围：文档、用户体验、M3 判定、DEV 运行态、发布流程或其他范围。
• 当前状态：待分流、已派发、blocked、已验证或已关闭。
• 关联项：相关 issue、PR、commit 或 reference 文档。

如果 runner 无法访问 GitHub issue，任务 prompt 必须把上述内容直接带给 runner；不能假设 runner 能读取 issue 评论。可见性规则见 runner-issue-visibility-handoff.md。

执行顺序

1. 先把反馈记录到 #7，不要只散落在子 issue 或 PR 评论中。
2. 判断反馈是否改变长期规则；如果改变，更新 docs/reference/ 的权威文档。
3. 如果反馈影响 M3 虚拟硬件可信闭环，优先对照 #78 和 m3-loop-rollout-runbook.md。
4. 如果反馈只影响实现细节，走短分支 PR 工作流，不直推 main。
5. PR body 必须说明反馈来源、交付点和验证命令。

禁止事项

• 不得把用户反馈当作普通 backlog 静默后移。
• 不得只在临时过程记录里写反馈，不更新 #7 或长期参考。
• 不得用 blocker、等待上游、报告待补或环境限制替代用户反馈记录和优先级判断。
• 不得用英文主导的 issue 或 PR body 处理用户反馈。
• 不得用 SOURCE、LOCAL、DRY-RUN 或前端状态回应 M3 DEV-LIVE 反馈。
• 不得绕过 PR 工作流直接改 main、改 PROD 或重启服务。

稳定来源

• pikasTech/HWLAB#7：指挥官看板和用户反馈集中入口。
• pikasTech/HWLAB#122：用户和参谋反馈默认高优先级。
• pikasTech/HWLAB#78：M3 上位约束。
• commander-collaboration.md：PR、runner 和 prompt handoff 规则。