Dogfood（测试版）

充当 QA 工程师，对 活动分支 进行端到端的测试：了解每个更改，像用户一样在真实浏览器中测试每个更改，并自主修复损坏的内容，直到分支真正准备就绪。

这是差异范围，而不是整个应用程序探索。您测试此分支相对于 main 引入或修改的内容。 （对于完整应用程序探索性 QA，请改用 dogfood 技能。）

仅将 agent-browser 用于浏览器自动化

此工作流程仅通过 agent-browser CLI 驱动浏览器。请勿使用 Chrome MCP 工具 (mcp__claude-in-chrome__*)、任何浏览器 MCP 集成或其他内置浏览器控制工具。如果平台提供多种方式来控制浏览器，请始终选择 agent-browser。使用直接二进制文件，切勿使用 npx agent-browser （直接二进制文件使用快速 Rust 客户端）。

先决条件

• 您可以启动的本地开发服务器（bin/dev、rails server、npm run dev 等）。
• 已安装 agent-browser。查看：

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

如果未安装，请运行 ce-setup 技能来安装依赖项，然后继续。没有它就不要继续。

重用复合工程技能

ce-dogfood-beta 是一个协调器。更愿意委托现有的 CE 技能，而不是重新派生他们的行为：

重用 ce-test-browser 的端口检测和开发服务器启动机制（请参阅第 3 阶段），而不是重新发明它们。

工作流程

0. Scope        Pick the branch, get onto it (offer worktree), never touch main
1. Analyze      Diff branch vs main, understand every change
2. Map+Matrix   Map user flows as Mermaid flowcharts, then derive the test matrix as a task list
3. Serve        Detect port, start dev server, open agent-browser
4. Execute      Work the matrix one item at a time with agent-browser
5. Fix loop     On failure: fix -> add regression test -> commit -> continue
6. Report       Write durable doc to docs/dogfood-reports/ (flows, matrix, fixes, learnings, verdict)

第 0 阶段：确定范围并选择正确的分支

解析 $ARGUMENTS：PR 编号、分支名称或空白（使用当前分支）。剥离 --port PORT（如果存在）。

1.解析目标分支：

• PR 编号： gh pr checkout <number>（首先探测现有工作树）。
• 分支名称： 签出（首先探测现有工作树）。
• 空白： 使用当前分支。

2. 拒绝在 main/master 上运行。 如果解析的分支是主干，请停止并告诉用户 — 与dogfood 没有差异。
3. 提供隔离。 询问是否在 git 工作树中运行，以便主要结帐保持不变（使用平台的阻塞问题工具）。如果是，则移交给 ce-worktree；如果不是，则继续原地踏步。
4. 如果存在先前的运行，则恢复。 在 docs/dogfood-reports/*-<branch-slug>-dogfood.md 查找现有报告。如果发现有未完成的场景，询问是继续还是重新开始。要恢复，请从矩阵中重新补充任务列表（通过/固定/跳过保持完成；待定/阻止/进行中成为剩余工作）并从那里继续。

可恢复性（随时停止并返回）

此工作流程设计为可以中断和恢复。有两个状态可以保证这一点：

• 任务列表 (TaskCreate/TaskUpdate) 是实时待办事项 - 每个矩阵场景一项任务。当您启动它时标记每个 in_progress ，仅当它真正通过时标记 completed 。
• 位于 docs/dogfood-reports/<YYYY-MM-DD>-<branch-slug>-dogfood.md 的报告文档是跨会话存活的持久检查点。 一旦矩阵存在（第 2 阶段结束） 就创建它，每个场景都列为 Pending，并 增量更新 - 在判断每个场景之后和提交每个修复之后 - 不仅仅是在最后。

由于任务是会话范围的，但报告文档位于磁盘上，因此报告是恢复的真实来源。始终保持两者同步，以便稍后的运行（或队友）可以准确地从停止的位置开始。

第 1 阶段：分析变化

拉取 main 的完整差异并仔细阅读 - 你无法测试你不理解的内容。

git diff --name-only main...HEAD     # what changed
git diff main...HEAD                 # how it changed

为每一个变化建立一个心理模型：新功能、修改的行为、新的路由/视图/组件、接触的数据流。注意任何产生用户可见行为的东西——这就是矩阵必须涵盖的内容。

**以产品的角色和愿景为基础。**寻找角色和愿景背景，以便可以从真实用户的眼睛来判断流程，而不仅仅是“它是否有效”。按顺序检查：STRATEGY.md（其“它是为谁”部分命名主要角色及其要完成的工作）、VISION.md 和任何角色文档（例如 docs/personas/、PERSONAS.md）。捕捉 1-3 个主要角色以及每个角色关心的内容。如果不存在，请从产品和差异中推断出合理的主要角色，并在报告中说明。

第 2 阶段：绘制流程，然后构建矩阵

整个狗粮的质量取决于这个阶段。不要直接跳到简单的页面列表。首先了解差异所涉及的用户流程，然后从中导出矩阵。没有流程模型构建的矩阵孤立地测试页面，并错过了旅程——“发送”但落在错误线程中的电子邮件。

2a。绘制用户流图（必需）

对于每个用户可见的更改，从头到尾追踪完整的旅程并绘制它。将每个流程映射为 Mermaid flowchart，以便在任何测试发生之前，旅程都是明确且可审查的 - 入口点、每个用户操作、分支点（成功/验证错误/空/权限被拒绝）、副作用（电子邮件、作业、通知）以及真正的最终状态。

电子邮件示例：“发送电子邮件”是不够的。它会发送给正确的收件人吗？当用户点击时，应用程序是否会登陆并滚动到右侧消息？内容有意义吗？整个流程是否符合产品的愿景和用户体验？流程图必须包含点击及其目的地，而不是停留在“电子邮件已发送”处。

flowchart TD
    A[User opens /threads] --> B[Clicks 'Reply']
    B --> C{Form valid?}
    C -->|No| D[Inline validation error shown]
    C -->|Yes| E[Reply saved]
    E --> F[Notification email sent to thread participants]
    E --> G[UI scrolls to new reply, focus on it]
    F --> H[Recipient clicks email link]
    H --> I{Lands on correct thread + scrolls to the reply?}

每个不同的旅程生成一个流程图。覆盖快乐路径和分支点（错误、空、边界、权限）。这些图表有助于理解——它们成为矩阵的支柱，属于最终报告。

2b。从流量中导出矩阵

遍历每个流程图并将每个节点和分支转变为一个或多个测试场景。阅读 references/test-matrix-taxonomy.md 了解完整的维度（旅程、功能检查、体验检查、边缘/错误/空状态、可访问性、响应能力）。涵盖功能性（“它有效吗？”）和体验性（“它感觉正确并与产品相符吗？”）。

将更改的文件映射到具体路径（视图 -> 其页面、组件 -> 渲染它们的页面、布局 -> 所有页面、样式表 -> 关键页面上的视觉回归）并将这些路径附加到执行它们的流程。

将矩阵加载为任务列表 (TaskCreate)，每个场景一个任务，因此可以跟踪进度并且不会跳过任何内容。按照流程图，按流程（而不是按文件）对任务进行排序。

第 3 阶段：检测端口并启动开发服务器

确定端口（优先级：显式 --port > AGENTS.md/CLAUDE.md > package.json 开发脚本 > .env* PORT= > 默认 3000）。如果服务器已经在监听，则重用它；否则在后台启动项目的 dev 命令并等待端口出现。这与 ce-test-browser 使用的机制相同 - 遵循其第 5-6 阶段逻辑。

agent-browser open "http://localhost:${PORT}"
agent-browser snapshot -i

第 4 阶段：执行矩阵

处理任务列表一次一项。对于每个场景，标记任务 in_progress，然后：

1. 记录您正在测试的内容（过程和预期结果）。
2. 使用代理浏览器驱动它 — 导航、交互式参考快照、单击、填写、提交，跟随旅程到达真正的最终状态：

   agent-browser open "http://localhost:${PORT}/<route>"
   agent-browser snapshot -i
   agent-browser click @e1
   agent-browser fill @e2 "value"
   agent-browser screenshot <scenario>.png
   agent-browser errors      # check console/page errors

3. 判断正确性和体验：正确的数据、正确的目的地、合理的内容、没有控制台错误，以及感觉与产品是否一致？
4. 像每个角色一样行走。 从每个主要角色的角度（从第一阶段开始）在你的脑海中重新运行旅程，并询问他们在哪里感觉到剪纸 - 一种不会导致功能测试失败但会降低体验的小摩擦：令人困惑的标签、额外的点击、意外的跳跃、感觉缓慢的步骤、缺少反馈、与角色的想法不匹配的副本。场景可以在功能上是 Pass 但仍然带有剪纸。记下每一次剪纸、哪些角色感受到了它，以及它的严重程度。
5. 记录通过/失败以及任何剪纸，并注明具体情况。仅当任务真正通过时才将其标记为 completed （记录剪纸，而不是阻碍 - 在第 5 阶段修复尖锐的，在报告中显示其余部分）。

外部交互流（OAuth、真实电子邮件发送、支付、短信）无法完全无头驱动 - 暂停并要求用户验证该分支，然后继续。

第 5 阶段：修复循环（自主）

当场景失败时，修复它并证明它 - 但首先决定修复是由您自主进行还是由人类决定。

在接触代码之前判断修复的大小。 当更改很小、易于理解且风险较低时自动修复：具有明显正确修复的明显错误，包含在几个文件中，没有模式/架构/产品权衡。 当更改很大或不明确时，不要自动修复 - 它需要架构或模式决策，更改产品行为或用户体验意图，跨越许多文件，具有看似合理的竞争解决方案，或者您不确定“正确”答案是否明确。强迫自主做出重大判断比升级更糟糕。

对于自主修复：

1. 调查根本原因。如果不明显，请使用 ce-debug。
2. 应用代码中的修复。
3. 添加自动回归测试，该测试在修复之前失败并在修复之后通过，因此错误无法返回。
4. 使用明确的消息提交修复（使用 ce-commit）。每次提交一个逻辑修复。
5. 在浏览器中重新运行失败的场景以确认它现在已经通过；然后继续矩阵。
6. 如果 bug 带有可重用的教训，请使用 ce-compound 捕获它。

对于太大而无法自主进行的更改：不实施。将其记录在报告的人类决策部分中，内容包括：出了什么问题、为什么它不是安全的自主修复、您看到的选项（需要权衡）以及您的建议。在矩阵中标记场景 Blocked (human decision)，然后继续其余部分。切勿仅仅为了清除矩阵项而进行大型的、不可逆转的或改变产品的更改。

继续迭代，直到每个任务都是 completed 或显式 Blocked (human decision)。重新测试修复可能影响的任何内容（注意相邻旅程中的回归）。

第 6 阶段：编写报告工件

报告文档是在第 2 阶段结束时创建的，并在整个过程中逐步更新（请参阅可恢复性）。当矩阵为绿色（或每个剩余项目都被明确阻止）时，在测试的存储库中的 docs/dogfood-reports/<YYYY-MM-DD>-<branch-slug>-dogfood.md 处最终确定它，然后在与文件路径的聊天中显示一个简短的摘要。

使用 references/dogfood-report-template.md 作为形状 - 与从模板中捕获计划和头脑风暴的方式相同。最终确定的工件必须包括：

1. 差异摘要 — 分支和 main 之间发生了什么变化。
2. 角色 — 评估的主要角色（及其来源：STRATEGY.md / VISION.md / 推断）。
3. 流程已测试 — 来自第 2a 阶段的 Mermaid 流程图，因此保留了旅程。
4. 测试矩阵和结果 — 每种场景：测试内容、通过/失败、发现问题、应用修复、提交 SHA。
5. 修复了什么 — 每个错误、其根本原因、修复、添加的回归测试以及提交。
6. 剪纸（按人物） — 发现的体验摩擦，每个人物感觉如何，严重程度，以及是否固定或推迟。
7. 人类的决策 — 问题太大而无法自主解决：出了什么问题，为什么升级，需要权衡的选项以及建议。
8. 经验 — 值得继承的可重复使用的经验教训（为 ce-compound 提供大量经验教训）。
9. 最终状态 — 准备就绪判定，以及仍然受阻或需要人工验证的任何内容。

在文档中使用存储库相对路径，而不是绝对路径，因此它保持可移植性。