功能可运行但上线前需用户实时浏览器反馈做聚焦 UX 打磨时…

让用户在真实运行页面上观察并指出问题，你只做其请求的聚焦 UX 修复，最后本地提交。

适用场景

解决思路

1. 先阅读 `references/run.md`，再解析请求的 ref 或启动任何操作；按其中要求处理现有 worktree 安全、发现 dev-server、调用 bundled scripts、可达性检查和浏览器交接。
2. 把可工作的功能放到用户面前并确保服务器运行，告知用户服务器地址。
3. 等待用户观察：询问哪里可以更好；用户浏览时不要自行开始 review pass。
4. 对每个用户请求的变更，仅按需检查，编辑范围内的界面或代码。
5. 依赖 hot reload 更新页面；当用户要求检查结果时，使用当前 harness 中可用的浏览器能力查看。
6. 如果当前 harness 没有浏览器能力，请用户描述其看到的内容。
7. 用户表示完成后，调用 `ce-commit` 提交本次 polish 变更。
8. 报告 commit(s)、仍在运行的 server URL，以及任何残余 blocker。
9. 在用户要求结束时结束 polish loop，并确保每个请求的修复都已反映在实时功能中，或报告为 blocked。
10. 把范围内变更保存为本地 commit(s)。
11. 如果出现 server 或 checkout blocker，也在带足恢复所需证据并报告后结束运行。
12. 边界：由用户驱动检查与修改内容，不要自创自主检查清单，也不要扩展成通用 QA。
13. 绝不操作仓库的默认分支。
14. 可以编辑并本地提交用户请求的 polish，但绝不 push 或开 PR。

适用边界 · 注意事项

• 用户无法或不愿意参与实时观察与反馈时。
• 任务需要自主全面 QA，或需要超出用户指定范围的大规模 UX 修改时。
• 需要在默认分支工作，或需要 push/open PR 时。