# HWLAB 用户反馈分流规则

本规则固化 [pikasTech/HWLAB#122](https://github.com/pikasTech/HWLAB/issues/122)，是 HWLAB 用户反馈分流规则的唯一维护处：用户和参谋提出的问题默认按高优先级用户反馈处理，并必须挂到 [pikasTech/HWLAB#7](https://github.com/pikasTech/HWLAB/issues/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](runner-issue-visibility-handoff.md)。

## 执行顺序

1. 先把反馈记录到 `#7`，不要只散落在子 issue 或 PR 评论中。
2. 判断反馈是否改变长期规则；如果改变，更新 `docs/reference/` 的权威文档。
3. 如果反馈影响 M3 虚拟硬件可信闭环，优先对照 `#78` 和 [m3-loop-rollout-runbook.md](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](https://github.com/pikasTech/HWLAB/issues/7)：指挥官看板和用户反馈集中入口。
- [pikasTech/HWLAB#122](https://github.com/pikasTech/HWLAB/issues/122)：用户和参谋反馈默认高优先级。
- [pikasTech/HWLAB#78](https://github.com/pikasTech/HWLAB/issues/78)：M3 上位约束。
- [commander-collaboration.md](commander-collaboration.md)：PR、runner 和 prompt handoff 规则。