docs: ✏️ update tui optimization design doc

docs/design/tui-optimization/06-implementation-rollout-checklist.md

@@ -3,7 +3,7 @@
 > 本文档给 `00-05` 各设计/调研文档补齐实施门槛、验收标准、灰度顺序和回滚条件。目标不是重复方案细节，而是把“什么时候能开始做、做到什么算完成、什么情况下必须停下来”写清楚。
 
 如果需要把设计进一步落成开发排期，请与 [08-execution-plan-and-test-matrix.md](./08-execution-plan-and-test-matrix.md) 配套阅读：本清单负责“能不能上线”，`08` 负责“先改哪里、先测什么、先拆哪几条 PR”。
-如果要把 `#3013` 拆成多个小 PR，请再配合 [10-pr-3013-split-plan.md](./10-pr-3013-split-plan.md) 使用：`10` 负责“这一大条 PR 应该拆成哪几条更好 review、每条故意不带什么”。
+如果要把闪屏治理真正拆成可 review、可复现、可关闭 issue 的一组小 PR，请再配合 [10-issue-oriented-flicker-plan.md](./10-issue-oriented-flicker-plan.md) 使用：`10` 负责“按用户问题类拆 PR、每条 PR 故意不带什么、应该先验证哪些场景”。
 
 ## 1. 使用方式
 
@@ -34,13 +34,16 @@
 
 ## 2A. PR 拆分门禁
 
-如果某条闪屏修复 PR 是从 `#3013` 或其后续补漏中拆出来的，进入 review 前还应满足：
+如果某条闪屏修复 PR 是按用户 issue 类别组织的，进入 review 前还应满足：
 
-- [ ] PR 只覆盖一种主闪屏机制
+- [ ] PR 标题和描述明确写出目标问题类，并链接对应 issue
+- [ ] PR 只覆盖一种主故障簇，不同时声称“顺手解决”其他类型闪屏
 - [ ] PR 描述明确写出非目标（哪些问题故意留给下一条）
+- [ ] PR 附带至少一个稳定复现脚本或固定操作步骤
 - [ ] PR 中不包含临时 diagnostics / `stderr` 调试输出
 - [ ] PR 有独立的验证场景，而不是复用“大而全”视频证明
 - [ ] PR 没有同时引入两层以上 stdout monkeypatch / render hook 变化
+- [ ] 若借鉴 `#3013`、Gemini CLI、Claude Code 的 patch 或思路，PR 描述明确写出“借鉴了什么、故意没带什么”
 
 ## 3. 启动与 MCP 验收清单