ce-dogfood

Dogfood

充当 QA 工程师，对当前分支进行端到端的实际使用测试，自主执行，直到它真正达到就绪状态。

目标： 在真实浏览器中完整走过此分支引入的每项用户可见变更的整个流程，并从正确性和产品目标用户的使用感受两方面进行评估；修复小问题、进行回归测试并提交。完成标准： 矩阵中的每个场景都标记为 Pass、Fixed、Skipped 或处于终态的 Blocked；项目的自动化测试套件已运行一次且记录了结果；报告 <root>/dogfood-reports/<YYYY-MM-DD>-<branch-slug>-dogfood.md 已按照模板完成，并已提交。如果矩阵全绿但测试套件未通过，最终结论应为尚未就绪，而不是已就绪。本次任务不负责追着把测试套件修到全绿。

本任务的范围由差异限定，不是对整个应用进行探索。你只测试此分支相对于主干引入或修改的内容。

第 0 阶段（范围）之前，请先阅读 references/phases.md 并遵照执行。**该文件详细定义了所有阶段；仅遵循下面的阶段列表无法正确执行本次任务。

边界

• 只能通过 agent-browser CLI 操作浏览器——绝不能使用 Chrome MCP 工具（mcp__claude-in-chrome__*）、其他浏览器 MCP 或内置的浏览器控制工具，即使平台提供了这些工具。使用直接二进制文件，绝不使用 npx agent-browser（直接二进制使用速度更快的 Rust 客户端）。
• 绝不能在分支名称或空白目标上对主干进行实际使用测试——不存在差异。PR 目标始终有基线，因此即使其头部分支名为 main，也始终可以进行差异测试。
• 数字目标在隔离和检出过程中始终保持为 PR 标识——绝不能将其简化为头部分支引用，因为其名称本身可能是 main。
• 绝不能擅自切换用户的主检出。此技能只决定是否提供隔离选项——空白目标或当前分支目标不提供（你已经位于该分支上），PR 或其他命名引用则提供——具体操作和结果由 ce-worktree 处理。如果用户拒绝隔离，则在原位置检出目标；若未提交的更改会受影响，须先确认。
• 截图和其他临时产物应保存到操作系统临时目录（mktemp -d "${TMPDIR:-/tmp}/ce-dogfood-XXXXXX"），绝不能放在仓库根目录；只有要嵌入报告时才复制一份到仓库中。
• 只自动修复范围小、充分理解且风险低的问题。若更改需要架构或模式决策、会改变产品行为或 UX 意图、涉及许多文件，或存在多个合理方案，则应升级并记入报告的供人工决策部分，绝不能为了清除矩阵项而直接实施。

先决条件

用户可执行的调用格式。 遇到先决条件失败时，默认使用 /ce-setup 和 /ce-dogfood <原始参数>；只有当当前宿主为 Codex 或明确说明支持带美元符号前缀的技能调用时，才使用 $ce-setup 和 $ce-dogfood <原始参数>。在 oh-my-pi（omp）上，使用 /skill:ce-setup 和 /skill:ce-dogfood <原始参数>。每个调用仅以行内代码格式呈现，并且只输出一种格式。

• 可以启动本地开发服务器（bin/dev、rails server、npm run dev 等）。

• 已安装 agent-browser。检查：

  command -v agent-browser >/dev/null 2>&1 && echo "Ready" || echo "NOT INSTALLED"
  

  如果未安装，则停止并告知用户安装 agent-browser：先输出当前安装命令对应的 ce-setup 调用格式，再输出用于重试的 ce-dogfood <原始参数> 调用格式。此工作流离不开它。

工件根目录

报告位于 <root>/dogfood-reports/ 下，人设位于 <root>/personas/ 下。首次组合任何 <root>/ 路径时（无论是读取还是写入），解析 <root>，之前不要解析。若运行期间没有组合任何 <root>/ 路径，则跳过。

在组合任何工件路径之前，先解析 CE 工件根目录 <root>。

• 读取 <repo-root>/.compound-engineering/config.yaml 中的 docs_root（<repo-root> = git rev-parse --show-toplevel）。不要从 config.local.yaml 中读取。未设置时，<root> 为 docs，与之前完全相同。
• 验证已设置的值：它必须是相对于仓库的目录，其真实路径（解析符号链接后）必须位于仓库内，且既不能是仓库根目录，也不能位于 .git/ 下。否则，停止并报错，指出 docs_root 和该值——绝不要回退到 docs。
• 将 <root> 用作唯一的工件位置：如果不存在则创建它，将每个路径组合为 <root>/<subdir>，其中 <subdir> 是此技能自己的子目录，且绝不同时读取 docs。

委派

ce-dogfood 是一个编排器：优先使用现有 CE 技能，而不是重新推导其行为。使用 ce-worktree 隔离 PR 或指定分支目标；将不明显的根本原因交给 ce-debug；使用 ce-commit 提交每项修复；使用 ce-compound 记录可复用的经验。

Compound Packs

仓库声明的 Compound Packs 提供人设和标准。描述用户的 Pack 规则是流程中要扮演的人设；规定产品应呈现何种外观或行为的规则，则是评判其涉及的每个场景的标准。若出现矛盾，则判定为失败，并通过其 (pack: <id>, <path within the pack>) 引用进入修复循环。若分支有意造成矛盾，则该规则的处理属于需要人工决定的事项，而非修复。可推广的评判结果应通过 ce-compound 回传到 Packs；此技能绝不写入 Pack。references/phases.md 定义了如何应用 Packs。

阶段顺序

确定范围 -> 分析差异 -> 梳理流程 -> 推导矩阵 -> 启动服务 -> 执行 -> 修复循环 -> 报告。顺序不可更改：必须先建立流程模型，再建立矩阵，且矩阵必须先于任何浏览器操作。各阶段的条件见 references/phases.md；在 Phase 0（确定范围）之前先阅读该文件，不要根据这一行自行重构阶段。每次处理一个场景，既要评判其正确性，也要评判它对每个人设的体验。修复只有在回归测试修复前失败、修复后通过时才算完成；否则，报告必须说明为何没有有意义的自动化测试。

检查点，而非最终写入。 矩阵一旦生成，就立即根据 references/dogfood-report-template.md 创建报告，并将每个场景设为 Pending；每评判完一个场景以及每提交一项修复后，都要更新报告。<branch-slug> 是分支名称转为小写后，将每段连续的非字母数字字符（包括斜杠）合并为一个 - 得到的字符串。通过 glob <root>/dogfood-reports/*-<branch-slug>-dogfood.md 查找先前的运行记录。任务列表仅在当前会话有效，但磁盘上的报告可供后续运行或队友继续处理，因此中断的运行必须留下符合模板结构的检查点，而不能只留下一个矩阵。

终止状态。 Blocked (needs human verify)（某个步骤需要外部交互，例如 OAuth、真实邮件、付款或 SMS，且无法通过无头方式驱动）和 Blocked (human decision)（修复规模过大，无法自主完成）这两种状态都需要等待人工处理；每种状态都会结束该场景，而不是整个运行：继续处理矩阵中的其余场景，且绝不要在本次运行或恢复运行时悄悄将被阻塞的场景重新排入队列。如何联系人工取决于状态；设置该状态的阶段会说明具体方式。