批量 UI 修改执行

批量读取问题需求文档，逐条调用 .codex/agents/ui_fixer.md 子智能体修复 Renderer UI 问题，并输出汇总结果。该技能只处理 UI 样式和前端可闭环逻辑；涉及 Preload / Main / Core / Agent / Tool Utility、contracts、磁盘写入、密钥或外部配置的问题，只记录为“需要全栈处理”，不修改非 Renderer 代码。

输入

用户会提供一个 Markdown 需求文档路径，常见格式如下：

# 标题

> 解析时间：...
> 来源文件：...
> 记录数：N 条

---

## #编号 — 标题

| 字段 | 内容 |
| --- | --- |
| **编号** | X |
| **时间** | ... |
| **发起人** | ... |
| **定位** | 左侧资源树 / 中间对话 / 右侧编辑器 / 设置弹窗 |
| **问题类型** | 样式问题 / 前端逻辑 / UI问题 / bug |
| **完成状态** | — |
| **验证状态** | — |
| **备注** | — |

### 问题描述

...

### 问题截图

![截图](data/xxx/row_X_img_1.jpeg)

---

工作流程

1. 读取并解析需求文档

读取用户提供的 Markdown 文件，将其按 --- 分隔为独立条目。每个条目提取：

• 编号：条目编号，如 #17。
• 标题：条目标题，如存在则保留。
• 定位：页面、模块、组件或交互区域。
• 问题类型：样式问题、前端逻辑、UI 问题、bug 等。
• 问题描述：问题描述正文。
• 问题截图路径：Markdown 图片路径，如存在。

如果截图路径是相对路径，基于需求文档所在目录解析为绝对路径；如果截图文件不存在，传递原始路径并记录截图不可读。

2. 加载 UI 修复 agent

读取 .codex/agents/ui_fixer.md，将其完整内容作为 UI 修复子智能体的角色定义和执行边界。

必须使用 ui_fixer.md，不得调用 .codex/agents/fixer.md，不得使用全栈修复 agent 替代。

3. 逐条串行调用 ui_fixer

对每个条目按编号顺序串行执行。必须等待上一条完成并记录结果后，再启动下一条，避免多个子智能体同时修改同一页面或组件。

构造任务描述：

请严格遵守以下 Codex 子智能体使用说明：

1. 你是通过 Codex 子智能体工具调用的 UI 修复子智能体。
2. 角色定义使用仓库内 `.codex/agents/ui_fixer.md` 的完整内容。
3. 调用参数建议：
   - agent_type: worker
   - reasoning_effort: medium
   - fork_context: true
4. 你不独占代码库，可能存在用户或其他智能体的改动；不要回滚无关修改。
5. 你只处理 `apps/desktop/src/renderer/` 的 UI 样式和前端可闭环逻辑问题。
6. 如果确认根因涉及 Preload / Main / Core / Agent / Tool Utility、packages/contracts、磁盘写入、密钥或外部配置，停止非 Renderer 方向修复，只说明需要全栈处理；不要修改非 Renderer 代码。
7. 你需要直接在自己的工作区修改 UI 侧代码，并在最终回复中列出修改文件、修复摘要、是否涉及全栈处理和验证结果。

{.codex/agents/ui_fixer.md 的完整内容作为角色定义}

当前任务：
- 编号：#{编号}
- 标题：{标题}
- 定位：{定位}
- 问题类型：{问题类型}
- 问题描述：{问题描述}

{如果有截图且文件存在，补充：相关截图：{绝对路径}}
{如果截图不存在，补充：截图路径不可读：{原始路径}}

请快速定位相关 Renderer 组件、样式、composable、浮层反馈或状态管理代码，直接修复 UI 样式或 UI 前端逻辑问题。保持回复精简。

4. 捕获并记录返回值

对每次 ui_fixer 调用，记录：

• 修复状态：根据返回内容判断为 已修复 / 部分修复 / 未修复 / 需要全栈处理 / 跳过。
• 修改文件：提取子智能体返回的已修改文件路径。
• 修复摘要：概括 UI 样式或 UI 前端逻辑修复内容。
• 是否涉及全栈处理：未涉及 / 需要全栈处理且未修改非 Renderer 代码。
• 验证结果：记录子智能体执行的验证命令、页面检查或未验证原因。
• 未修复原因：未修复、跳过或需要全栈处理时必须记录。

5. 生成解决结果文档

所有条目处理完毕后，创建目录 docs/bug解决需求文档/需求文档/样式需求与bug/（如果不存在），并在该目录下生成：

docs/bug解决需求文档/需求文档/样式需求与bug/{原始文件名（不含扩展名）}-解决结果.md

文档模板：

# {原始文件名} — UI 修改解决结果

> 生成时间：YYYY-MM-DD HH:mm:ss
> 总条目数：N
> 已修复：X
> 部分修复：Y
> 需要全栈处理：Z
> 未修复/跳过：W

---

## #{编号} — {标题}

**定位**：{定位}

**问题类型**：{问题类型}

**修复状态**：{已修复/部分修复/需要全栈处理/未修复/跳过}

**修改文件**：
{如果有修改文件，逐行列出；如果没有则写“无”}

**修复摘要**：
{1-3 句话概括 UI 修复内容}

**是否涉及全栈处理**：
{未涉及 / 需要全栈处理且未修改非 Renderer 代码}

**验证结果**：
{验证结果或未验证原因}

**未修复原因**：
{如未修复、跳过或需要全栈处理，说明原因；否则写“—”}

---

注意事项

• 必须串行调用 ui_fixer，不要并发。
• 固定调用 .codex/agents/ui_fixer.md，不得调用全栈 fixer。
• 只处理 Renderer UI 样式和前端可闭环逻辑。
• 可以修改 Renderer 对 window.deepwrite.* 的调用编排、参数组装、空值兼容和展示映射，但不得修改 Preload / Main / Utility / contracts。
• 如果条目明显是协议、Core 写入、Agent 流式事件、磁盘、密钥或配置问题，记录为 需要全栈处理；只有存在 UI 侧兜底展示时才做前端修改。
• 保留原始需求文档，不要改写用户输入文档。
• 截图文件真实存在时必须传给 ui_fixer；读取失败或不存在时记录原因。
• 某条失败时记录失败原因后继续下一条，不中断整个批量流程。
• 结果文档必须生成在 docs/bug解决需求文档/需求文档/样式需求与bug/，文件名格式为 {原始文件名}-解决结果.md。