Genie Editor 快速编辑工作流通过 Chrome 扩展注入编辑器，再由 CLI 读取待办、修改代码、设置终态并复核，形成完整闭环。
用途
该工作流用于处理网页编辑器中的待办节点：用户在浏览器里通过 Axhub AI Extension 注入 Genie Editor，对页面元素进行标注或标记待办，AI 代理则通过 @axhub/genie CLI 读取这些待办，在本地项目中修改代码，并把处理结果回写到编辑器状态。
前置条件与使用方式
CLI 环境方面，需要 @axhub/genie ≥ 0.2.4，可通过 npm install -g @axhub/genie 安装，再用 npx @axhub/genie --cwd /path/to/project 启动服务并指定项目目录。之后用 npx @axhub/genie status --json 确认服务在线，看到 running: true 后继续。
Chrome 扩展方面，用户需要安装 Axhub AI Extension，安装地址为 https://axhub.im/chrome/ 。安装后打开目标网页，扩展会自动注入 Genie Editor。
连接检测方面，通过 npx @axhub/genie editor clients list 验证扩展是否已连接后端。检查返回结果时，total > 0 表示至少有一个客户端在线；可查看 source 字段确认是否来自 Chrome 扩展（source: "chrome-extension"）；可查看 capabilities 确认包含 editor.snapshot、editor.nodes.list 等。如果列表为空，需要引导用户确认扩展已安装并启用、在目标页面启动编辑器，并确认后端服务正在运行。
主流程
第一步是确认服务与扩展连接，使用 npx @axhub/genie status --json 和 npx @axhub/genie editor clients list，确认 running: true 且有在线客户端，并记录本次任务使用的 channel 和 targetClientId。若只有一个客户端可直接使用，多个客户端则用 pageUrl、sessionId、source 缩小范围，无法安全判断时向用户补问。整个任务复用同一个 channel + targetClientId。
第二步是全局扫描，至少获取 editor snapshot 和 editor nodes list（状态为 pending-dispatch,dirty）两份数据，按 pending-dispatch → dirty → error → 疑似卡住的 editing 的优先级处理节点。扫描结果为空时，应告知用户当前没有可消费的编辑器待办，不要硬编待办。
第三步是领取节点，开始处理前将其标记为 editing，要求每个节点生成唯一 taskRequestId，provider 固定用 codex。修改成功设为 --state completed（前端显示绿色勾，1.8s 后自动消除），失败设为 --state error（红色叉，保留在 overlay 上），异常退出设为 --state idle 兜底释放。设置 editing 后任务状态会持久化到 localStorage，页面刷新后可恢复。CLI 具备自动重试能力，遇到 CONNECTION_ERROR、CONNECTION_CLOSED 或 REQUEST_TIMEOUT 错误会在 1 秒后自动重试一次。
第四步是收集上下文，每个节点至少查看 elementKey、label、changeState、taskState、hasNote、hasImages、changeKinds。按需补充上下文图片或节点截图，截图返回 absolutePath 可直接用 view_file 查看。由于 context-images 是页面级共享上下文，不一定能精确映射到单个节点，推荐先读 nodes list 获取有标注的节点，再导出 context-images 并用 createdAt 时间戳与节点的 dirtySince 关联，不确定时拉取 node screenshot 进行视觉比对，仍无法对应时将所有上下文图片作为全局参考。
第五步是实施代码修改，优先处理用户明确要求或影响最大的节点；多个节点属于同一块 UI 时合并为一个实现批次；多个节点互相独立时可拆给子代理，子代理仅负责实现，不负责客户端发现和状态回写；无法安全定位节点时先截图再交叉判断，仍不行就告知用户阻塞点。
第六步是验证，至少做一轮回读，重新获取 snapshot 和 nodes list（状态含 pending-dispatch,dirty,error,editing）。如果节点代码已改但 backlog 仍显示 dirty/pending-dispatch，不要假装已完成，要明确说明页面实现已完成、编辑器 backlog 仍显示未消费，并将节点标记为 completed 表示 AI 已处理完毕。
第七步是设置终态，对每个已领取节点设置 completed、error 或 idle，任务未完成也要设置终态，并在总结里写清未完成原因。
通信稳定性
编辑器前端会实时跟踪 WebSocket 连接状态（connected / disconnected / reconnecting）并在 UI 展示：断线时显示黄色脉搏点与“重连中…”，重连失败显示红色 badge 与“连接失败”，重连成功则自动消失。前端采用指数退避重连策略（3s → 6s → 12s → … → 48s，最多 10 次），避免服务端重启时被瞬间洪泛。用户切换回标签页时，前端会立即检查连接，已断线则立刻发起重连并重置计数器。CLI 内置自动重试，对 AI Agent 透明无感。任务持久化方面，通过 editing.set --state editing 设置的外部编辑任务会同步持久化到 localStorage，页面刷新后任务状态自动恢复（overlay 保留“AI 编辑中”），error 终态持久化 30 分钟刷新后仍可见，completed 终态 1.8s 后自动消除。
阶段感知 overlay
当 AI Agent 通过内置 Genie Bridge 执行时，编辑器 overlay 会根据处理阶段显示不同文案：thinking 显示“AI 正在分析”，coding 显示“正在修改代码”，reviewing 显示“正在检查修改”，running 显示“Genie 正在执行”，waiting 显示“等待 AI 响应”，completed 显示“修改完成 ✓”，error 显示“AI 修改失败 ✕”。对于通过 CLI editing.set 发起的外部任务，overlay 显示固定的“AI 编辑中”文案，可通过 taskRef 携带自定义 message。
效率优化与并行策略
建议尽早 editing.set，在读取 snapshot 后立即标记 editing，让用户第一时间看到 AI 已领取；批量扫描一次、分批处理，先一次性读完所有待办再逐个处理；小节点优先，让用户快速看到成果；并行截图，可并行发起多个 node screenshot 请求；节流 context-images，全局上下文图片只导出一次供后续节点复用。多节点并行方面，适合并行的情形是不同页面区块、改动文件不重叠、上下文已足够清楚；不适合并行的情形是同一组件树深度耦合、依赖同一套重构、还没搞清各节点位置。主代理应保留客户端选择、节点领取/释放、最终复核。
失败处理与交付要求
服务离线时引导用户启动 npx @axhub/genie --cwd <path>；找不到客户端时引导用户检查扩展连接；节点不存在、截图失败或无法定位节点时如实报告阻塞点；扩展 WS 断开重连时等待几秒后重新检查 clients list；部分完成时清楚列出已完成/未完成节点及原因。最终回复至少应包含：使用的 channel + targetClientId、本轮处理过的 elementKey、修改了哪些文件、各节点的终态（completed / error / idle）、做了哪些验证，以及还有哪些节点仍未处理或状态异常。
适用场景与限制
该工作流适用于在浏览器页面上直接接收并处理编辑待办的开发与协作场景，尤其适合需要可视化标注反馈的网页编辑器项目。其主要限制在于依赖 Axhub AI Extension 与 @axhub/genie CLI 的配合，且 provider 固定为 codex；context-images 为页面级共享上下文，不一定能精确映射到单个节点；页面代码已改但编辑器 backlog 未消费时不能视为已完成。其他如收费、价格、平台范围等信息暂未提供。