task-workflow

任务工作流

严格指令约定

本文件是严格的实现指令，不是宽泛的指导，也不是可选的参考资料。

这是任务执行的规范工作流。它不是完成任务的一种可选方式，而是必须遵循的方式。

如果 Agent 读取了此技能，就必须严格按照此处所述的顺序和要求执行。

必须遵守的行为：

• 不要重新解读步骤。
• 不要调整步骤顺序。
• 不要跳过步骤。
• 不要用更简单的方法替代这些步骤。
• 不要做出与本文件相冲突的假设。
• 不要将大体相似、直觉或以往习惯视为偏离要求的理由。

如果 Agent 不确定，就必须在此处定义的工作流内解决不确定性，不得自行编造工作流。 如果此技能要求执行某个步骤、关卡、检查清单、审查或循环，该要求就是强制性的。 如果此技能说明后续阶段受阻，Agent 必须将其视为受阻。 如果 Agent 无法在所需的产物中证明某阶段已通过，就必须将该阶段视为未通过。

在第 7 阶段之前，不存在可以成功停止的节点。提前停止可能直接伤害用户，因为他们可能依赖完整的工作流来完成对工作至关重要的工作。这是非成即败的情况：如果运行未正确到达第 7 阶段，用户就可能受到伤害；如果 Agent 提前停止、对质量欠佳的成果签字认可、跳过关卡或破坏实时数据，用户可能会丢掉工作。将过早停止、部分签字认可、实时数据损坏或“基本完成”的总结视为严重失职。

在目标仓库中，首个文件系统操作必须是重置并搭建第 0 阶段产物。

在 task-workflow/phase-0-artifact-reset.md 创建之前，Agent 只能：

• 确定目标仓库根目录
• 读取此 SKILL.md
• 读取任务文件
• 根据模板创建或替换 task-workflow/ 产物

在第 1 阶段通过之前，Agent 不得编辑或生成实现文件、构建输出、数据库、路由类型、迁移文件、测试、包文件或源文件。

生产数据库和实时工作区数据库，尤其是 .dbs/database.db，属于用户的关键数据。删除、重置、重新播种、截断、通过临时写入方式检查或修改这些数据库，都可能破坏用户的工作，并导致用户丢掉工作。唯一获准的生产/实时数据库操作，是在发生真实架构变更时运行仓库要求的应用迁移命令。此例外不允许对生产数据库进行“操作”：不得手动查询、操纵数据、播种、重置、加载测试夹具、修复数据、清理、删除、截断、直接运行 SQLite 命令或进行调试修改。

第 1 阶段通过后、编辑任何实现内容之前，Agent 必须将 task-workflow/CURRENT_PHASE.txt 设置为 phase-2-execution。

如果 CURRENT_PHASE.txt 仍写着 phase-0-artifact-reset 或 phase-1-task-research，则实现文件必须保持不变。

如果在第 0 阶段产物创建且第 1 阶段通过之前更改了实现文件、生成的应用文件、构建输出或数据库文件，则本次运行失败，必须从干净的测试夹具重新开始。

核心理念

每次上下文压缩后、继续工作前，都要重新阅读此 SKILL.md。也要重新加载各阶段参考资料和当前任务工件。不要依赖对话记忆。

这项技能是一套带门槛的执行协议，而非宽泛的建议。它将任务转化为可重复、由工件驱动的工作流。目标应用必须依据任务、目标仓库和本地代码库证据实现，然后通过第 3 阶段的检查／Lint 证据、第 4 阶段的单元测试覆盖决策、第 5 阶段的交互式 Playwright 验证、第 6 阶段的端到端测试覆盖决策，以及最终审计来证明实现正确。

假设这项技能可能完全自主运行，也可能在运行中途被压缩。没有人会逐行监看运行过程。因此，工件文件就是执行机制。Agent 觉得有把握，并不意味着阶段已完成。只有在必需的工件显示实际通过的分数且所有关键项均通过时，阶段才算完成。

task-workflow/progress.md 是精简的恢复台账。它必须概述任务、当前阶段、已完成阶段的上下文、当前工作队列、验证状态，以及下一步本地操作。硬性规定：压缩、恢复、重试、重新连接或开始新的编码会话后，在开展任何新工作前，先读取该文件和 task-workflow/CURRENT_PHASE.txt。随着工作推进，及时更新该文件；它是首要恢复文件，必须足以让你在没有对话记忆的情况下继续工作。

切勿仅凭乐观判断、不完整证据、仅凭构建成功，或仅凭宽泛的产品相似性，就将工作从一个阶段推进到下一个阶段。

此工作流有意设计为循环式。门槛未通过时，Agent 必须返工该阶段、更新证据、重新运行所需的检查或验证、重新评估门槛，并反复执行，直到通过。质量门槛不是给用户看的报告，而是促使继续完成工作后才能晋级的控制点。

MITB 工作区输入

在 MITB 沙盒中运行时，请使用以下相对于仓库的工作区输入：

• 工作流技能：.agents/skills/task-workflow/SKILL.md
• 任务正文：.tasks/task.md
• 领域和品牌背景：.tasks/domain.md
• 附加任务文件：.tasks/files/
• 可用技能文件：.agents/skills/

AGENTS.md 是目标仓库具有约束力的开发说明文件。它定义了项目特定的架构、类型安全、测试、UX、命令、代码风格、文档、禁止模式和完成要求。阶段 1 必须在规划编辑前，从 AGENTS.md 中提取与任务相关的规则，包括其中指向的任何必需文档。后续关卡必须验证实现是否遵循了提取的规则。

阶段 1 必须读取 .tasks/domain.md。即使文件夹为空，也必须枚举 .tasks/files/，然后在规划前读取或检查该文件夹中的每个任务附件／辅助文件。

可用技能保存在 .agents/skills/ 下。请根据提示词的 Skills 部分和 .agents/skills/ 发现可用技能，然后只读取与当前任务相关的已选技能 SKILL.md 文件。不要批量读取 .agents/skills/ 中的所有技能文件。

所有阶段 1 输入／参考文件均为只读文件。这包括 AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 下的每个文件，以及 .agents/skills/ 下每个已选技能文件。将 .tasks/ 下的文件视为规范的任务输入，而非可编辑的工作区文件。除非任务明确要求更新某个确切的参考文件，否则不得重写、规范化、合并、清理、删减、重新格式化或“修复”这些文件。如果参考文件看起来存在不一致之处，请在 task-workflow/phase-1-task-research.md 或 task-workflow/open-gaps.md 中记录这一歧义；切勿通过编辑参考输入来解决。

在 task-workflow/phase-1-task-research.md 和 task-workflow/progress.md 中记录每个已读取或检查的 .tasks/files/ 附件／辅助文件，以及每个已选技能的路径和相关原因。压缩或恢复后，请重新读取 progress.md 中列出的相关已选技能文件，以及 AGENTS.md、.tasks/task.md、.tasks/domain.md 和阶段 1 中记录的相关 .tasks/files/ 附件／辅助文件。

在 MITB 中，.tasks/task.md 或提示词始终会提供任务完成命令。只有在阶段 7 的所有审计检查均通过后，阶段 7 才能运行确切的已完成命令。如果任何阶段 7 审计检查未通过，则不得运行任务完成命令。返回最早未通过的阶段，修复工作、更新证据、重新评估该阶段，然后依次通过后续关卡，再次进入阶段 7。

强制流程结构

<mandatory_process_shape>

此工作流结构不可省略：

1. 清理此仓库中过时的工作流产物，并复制新的产物模板。
2. 读取任务、根目录 AGENTS.md、.tasks/domain.md、.tasks/files/ 中的每个任务附件／辅助文件、.agents/skills/ 中仅与任务相关的可用技能文件，以及相关项目文档。在规划前，从 AGENTS.md 中提取与任务相关的开发规则。这些说明、任务、领域、附件和技能参考文件均为只读文件，除非任务明确要求编辑它们。
3. 调研代码库并记录实现计划。
4. 执行主要实现。
5. 执行第二轮差距补全。
6. 进行第二轮完整性审查，并验证仓库检查／lint。
7. 决定单元测试覆盖方案：添加、更新、删除，或明确跳过单元测试。
8. 使用独立的 Playwright 脚本进行交互式验证。
9. 决定 E2E 覆盖方案：添加、更新、删除，或明确跳过 E2E 测试。
10. 重新检查每个阶段的产物，只有所有关卡均通过后才能签核。

如果工作跳过上述任何阶段边界，则流程偏离轨道。

</mandatory_process_shape>

阶段所有权矩阵

阶段	负责事项	必需证据
阶段 0	工件重置和脚手架搭建	全新工件、辅助脚本、标记、未修改源代码
阶段 1	任务接收和调研	已阅读任务／领域／附件／AGENTS／所选技能、代码库调研、实施计划
阶段 2	主要实现	范围明确的工作包、文件证据、回读／差异／搜索证明
阶段 3	第二次执行、完整性检查、检查／Lint 验证	关联表面审查、仓库检查、必要时进行有针对性的 Lint、构建、可复用的构建证据
阶段 4	单元测试覆盖决策	添加／更新／移除／跳过决策、现有测试检查、最精简的单元测试命令或 N/A
阶段 5	交互式 Playwright 验证	阶段 1 行为证明、阶段 2 UI／响应式证明、屏幕截图、生命周期证据
阶段 6	E2E 覆盖决策	添加／更新／移除／跳过决策、关联的 E2E 检查、最精简的 E2E 命令或 N/A
阶段 7	最终审计和签核	工件完整性审查、当前证据、审计后的 MITB 完成命令

</mandatory_process_shape>

循环式关卡约定

每个阶段都遵循相同的循环：

1. 从阶段参考映射中重新阅读该阶段所需的参考文件。
2. 执行阶段工作。
3. 使用具体证据更新阶段工件。
4. 根据关卡要求为阶段评分。
5. 如果未通过关卡，则留在当前阶段，修复未通过的工作或缺失的证据，然后重复此循环。
6. 如果通过关卡，则记录晋级锁定证据，推进 task-workflow/CURRENT_PHASE.txt，并立即开始下一阶段。

阶段 0、阶段 1、阶段 2、阶段 3、阶段 4、阶段 5、阶段 6 和阶段 7 都必须遵循此循环。

不得降低关卡门槛以跳出循环。 如果可以在本地进行下一步修复，不得将失败概括为进展。 如果可以在本地修复阶段，不得等待用户指示继续。 不得因为实现“可能可用”就带着不充分的工件继续推进。

唯一可接受的结束状态是阶段 7 已通过，且所有先前阶段仍然通过。唯一可接受的非阶段 7 停止情况，是确实存在无法在本地解决的外部阻碍，并且已在当前阶段工件和 task-workflow/open-gaps.md 中完整记录。

自主运行约定

<autonomous_run_contract>

始终遵守这些规则。

阶段门禁与工件规则

• 每个阶段都必须以客观门禁结束。
• 每个门禁都必须记录在该阶段所属的工件文件中。
• 每个门禁都必须同时包含数值阈值和关键项通过要求。
• 如果门禁未通过，则留在该阶段并继续迭代。
• 门禁未通过意味着“修复并循环”，而不是“停止并报告”。
• 门禁通过后，如果下一阶段已可在本地开展，则必须立即晋级到下一阶段。
• task-workflow/CURRENT_PHASE.txt 仅是恢复进度的指针，并不能证明之前的阶段已通过。
• task-workflow/progress.md 是精简的恢复进度台账。它不能证明门禁已通过，但必须保持最新，以便精简上下文后恢复运行。
• 每次启动阶段、完成有实质意义的 Phase 2 工作包、得出阶段门禁结果、发现阻塞项以及晋级阶段后，都要更新 task-workflow/progress.md，记录当前阶段、最早未通过的阶段（如有）、最近通过的门禁、下一项本地操作，以及相关上下文的精简摘要。
• 保持 task-workflow/progress.md 中的 Current Phase Pointers、Phase Artifact Index 和 Artifact Pointers 为最新状态。它们必须指向当前阶段工件、当前阶段参考文件以及高信号活动文件。不要将阶段工件中的完整调研文件、编辑文件、Playwright、截图、日志或测试清单重复到 progress.md 中。
• 在精简上下文后恢复、重试、重新连接或开启新的编码会话时，在选择下一步操作前，重新阅读此 SKILL.md、task-workflow/progress.md、task-workflow/CURRENT_PHASE.txt、当前阶段工件、task-workflow/open-gaps.md，以及当前阶段要求的参考文件。如果它们相互矛盾，请检查阶段工件，并从最早未通过的阶段继续。
• 只有当阶段所属工件中明确写有 Decision: Pass、分数达标、所有关键项均通过，且门禁或必需证据部分没有占位符 Pending 行时，该阶段才能推进当前阶段标记。
• 必须在该阶段工作开始前写入当前阶段标记，不能仅在阶段工作完成后将其作为清理步骤。
• 写入下一阶段标记前，重新打开当前阶段工件，并核实其中已书面记录晋级锁定条件。
• 写入新阶段标记后，必须立即阅读该新阶段要求的参考文件，然后才能开始该阶段的任何工作。
• 如果 CURRENT_PHASE.txt 指向最早未通过的阶段工件之后，则以工件门禁为准。将 CURRENT_PHASE.txt 更正为最早未通过的阶段，并从该阶段继续。
• 填写工件模板时，必须为每个必需语义类别保留可审计证据。只有在证据依然清晰且可评分时，才可精简具体行文。
• task-workflow/open-gaps.md 是门禁工件。除非在同一阶段更新缺口台账，否则后续阶段不得宣称某项缺口已解决。
• 在缺口所属阶段或下一步操作字段所指定的阶段通过后，缺口不得继续标记为 Open。如果后续阶段已完成相关工作，则将缺口移至 Resolved Gaps；如果该缺口并不存在，则须提供证据并重新归类或关闭。
• Phase 0 之后，task-workflow/open-gaps.md 中不得包含 Pending 等模板占位行。如果没有缺口，请将占位行替换为明确的 None currently recorded 行。
• 只要仍有任何关键缺口处于 Open、已过时或与其他阶段工件矛盾的状态，Phase 7 就不能通过。

验证文件规则

• 第 5 阶段和第 6 阶段必须检查交互脚本和 E2E 测试中的固定等待，再通过验证。
• task-workflow/playwright 或 tests/e2e 中出现固定等待即为门禁失败。不要为其辩解。应将其替换为确定性的 Playwright 等待／断言，例如 locator.waitFor(...)、expect(locator)...、waitForURL(...)、waitForResponse(...) 或持久化状态断言，然后重新运行验证。
• 只有当第 5 阶段、第 6 阶段和第 7 阶段的产物记录了受检验证文件中不含固定等待，并说明所使用的确定性等待／断言时，才能通过。
• 如果后续工作发现前一阶段缺少证据，应返回该阶段，补齐证据并重新通过门禁。

写入和命令规则

• 每次写入文件、应用补丁、创建生成文件或更新会影响门禁的构件后，都必须先回读检查，再依赖其结果。使用 sed、rg、ls、git diff 或仓库常用的检查命令，确认文件存在且包含预期更改。
• 如果写入/编辑工具报告写入无效、文件缺失、补丁失败、输出不完整或结果不确定，请停止当前工作包，使用受支持的编辑方法修复写入，回读检查后再继续。不得假定失败的写入已经生效。
• 命令必须有界。不得让长期运行的服务器、监视器或交互式命令作为当前活动工具调用在前台运行。
• 绝不能将生产/实时工作区数据库用作测试或验证状态。在本技能中，“生产数据库”指 .dbs/database.db、仓库声明的实时/默认用户数据数据库，或正常应用在隔离测试/E2E 配置之外使用的任何数据库路径。对 .dbs/database.db 或任何生产/实时数据库，唯一允许的操作是：在负责该迁移的阶段中，为实际架构更改运行仓库要求的应用迁移命令，并记录迁移证据。这是范围严格限定的迁移执行例外，并不代表可以对生产数据库进行其他操作。如果任务创建或更改了迁移，则迁移存在后、Phase 3 批准之前，必须针对生产/实时默认数据库运行仓库的应用迁移命令；用户会立即使用已完成的应用，因此未应用的迁移会导致交付的更改不可见或无法正常工作。除此之外，不得对生产/实时数据库执行任何操作：不得手动查询、操作数据、播种、重置、创建夹具、运行 Playwright 或 E2E、探测、调试、清理、rm、截断、直接使用 SQLite、自定义修复数据，或进行有写入风险的数据检查。如果命令可能触及生产数据，而构件无法证明它是针对实际架构更改的仓库迁移命令，或是针对隔离测试数据库的操作，则不要运行。
• 除 Phase 5 和 Phase 6 外，如果 API/运行时探测需要临时开发服务器，请使用 task-workflow/scripts/server-probe.mjs。它负责捕获 PID、检查就绪状态、运行有界探测命令、记录运行时日志，并仅按 PID 清理进程。服务器通常需要 5–10 秒就绪；常规预算为 15–20 秒，启动就绪时间上限为 30 秒。只有在明确属于沙盒自身的恢复操作中，且无法按 PID/端口清理时，才可按进程名广泛清理，并在构件中记录原因。
• 在 Phase 5 和 Phase 6 中，首次需要运行中应用的浏览器、Playwright 或 E2E 命令，默认必须通过 task-workflow/scripts/playwright-lifecycle.mjs 建立生命周期所有权。不要先对着假定已存在的服务器运行，再根据 fetch failed、数据过期、重定向或构建输出错误推断需要手动管理服务器。
• 已有仓库 E2E 测试不是绕过辅助脚本的理由。默认通过辅助脚本的 --run 运行 pnpm exec playwright test ...。只有在诊断确认辅助脚本无法为该确切命令管理服务器后，才可使用由仓库 webServer 管理的原生 Playwright，并且必须在运行前记录该原因。
• 辅助脚本的 --env 不是数据库路径覆盖机制。绝不能在辅助脚本、设置、服务器或运行命令中设置 E2E_DATABASE_FILE_PATH、DATABASE_PATH、DB_PATH 或任何类似的数据库文件/路径变量。Agent 不得更改仓库内部的 E2E/端到端数据库文件路径。测试数据库路径必须来自仓库已检入的 E2E/端到端配置或已就绪的环境。.dbs/database.db 是实时工作区/生产数据库；绝不能将生产数据库用于测试。使用 .dbs/database.db 运行 Playwright、E2E、夹具、播种、重置、检查、清理或调试，即使它只出现在 task-workflow/ 中，也属于严重错误。用户可能因此丢掉工作。
• 预期的验证生命周期模式：在运行 Phase 5 或 Phase 6 之前，先从 AGENTS.md、package.json、README/文档、Playwright 配置和 tests/e2e 辅助工具中找出仓库自有的设置与服务器命令。优先使用仓库自有的设置命令来准备隔离的 E2E/测试状态：只重置测试数据库、应用针对测试目标的迁移，并播种确定性的验证数据；同时使用仓库自有的服务器命令，以该隔离状态启动应用。如果目标仓库没有这类命名脚本，则使用最精简的仓库自有/仅测试命令模拟相同模式，并在运行前记录对应关系；绝不能以写入生产数据库、覆盖原始数据库路径或手动清理命令链替代此模式。
• Phase 5 或 Phase 6 中，不得将手动清理服务器、固定等待、删除数据库、启动服务器和运行 Playwright 拼成命令链。在由辅助脚本管理的运行中，将服务器启动前的设置（例如重置隔离测试数据库、测试迁移、测试数据播种或测试数据库准备）放入生命周期脚本的 --setup "..."。在当前验证批次中，将设置和服务器启动视为可复用：优先通过一次辅助脚本管理的运行执行所需脚本/测试规范；只有在代码、迁移、夹具、数据库状态、构建输入或先前设置输出发生更改后，才重新运行设置。不要只因为接下来要运行另一条 E2E 命令，就在每个定向脚本/测试规范前反复删除/重建数据库或重启服务器。如果需要清理，应将其作为单独记录的恢复步骤，在辅助脚本运行前完成，然后单独运行辅助脚本。如果服务器状态、数据库状态、端口归属或构建新鲜度看起来有问题，请先通过当前生命周期所有者的日志/就绪状态进行诊断；修复任何代码/设置问题后，再由该所有者重新运行。如果辅助脚本超时或没有产生有用输出，应将其视为生命周期/设置方面的证据，检查 task-workflow/runtime/server.log、task-workflow/runtime/setup-*.log、就绪状态输出和 task-workflow/runtime/run-*.log，然后在再次运行前更改设置、服务器命令、就绪 URL、测试命令、夹具或诊断。如果辅助脚本在修正调用后，因已诊断的生命周期/工具问题失败一到两次，请记录辅助脚本日志，并切换到能够证明任务的最小备用方案：仓库 Playwright webServer、显式 PID/端口清理，或提供 PID/日志/就绪状态/清理证据的手动服务器管理。只有在无法按 PID/端口清理时，才可将按进程名广泛清理作为已记录的沙盒恢复操作。
• 验证任务期间不得运行 playwright install、playwright install chromium 或同类浏览器下载命令。若可用，托管生命周期辅助脚本会设置 PLAYWRIGHT_BROWSERS_PATH=/ms-playwright；如果项目 Playwright 版本与沙盒浏览器缓存不匹配，它会提前失败。

由阶段负责的命令规则

• 阶段 2 通过严格的产物、回读、差异、搜索和有限解阻命令证据来完成实现包。常规检查、lint、构建、单元测试/Vitest、E2E、Playwright 以及仓库组合检查命令（例如 pnpm run check）应留给后续负责的阶段，除非具体的编译/类型问题阻碍当前实现包，且已在运行命令前记录。
• 阶段 3 检查相关位置，补齐遗漏的实现缺口，进行实现完整性审查，然后负责按顺序执行检查/构建检查点：仓库检查、适用时执行针对性 lint，以及在仓库单独提供构建命令时执行构建。仅使用定向诊断或有限修复检查来证明特定问题组。当宽泛的检查/构建命令失败时，应检查足够的输出以识别可见问题组，并在重新运行该宽泛命令前修复所有可在本地解决的问题组；只记录问题组、修复内容和重新运行的原因。其他可见问题组尚未解决时，不要每修复一个小问题就重新运行宽泛命令。除非需要临时日志进行问题排查，否则不要保留超大的命令日志；提取问题组后，删除临时的完整输出日志。将单元测试/E2E 覆盖问题记录下来，交由后续负责的阶段处理。
• 阶段 4 负责单元测试覆盖。它决定是否需要单元、服务、组件或集成式覆盖，然后添加、更新、移除或明确跳过该覆盖。如果现有单元测试保护的是非核心、非复杂、已过时或过于繁杂的行为，并且产物说明移除为何能改善测试套件，则可以移除这些测试。如果阶段 3 的证据仍然有效，阶段 4 不得重新运行检查、lint 或构建。
• 后续阶段沿用阶段 3 的构建证据，除非代码、配置、依赖项/构建输入、迁移、生成的资源、过时输出或不兼容的验证工具使其失效。不得仅为准备、重新确认或求个安心而在阶段 4、阶段 5、阶段 6 或阶段 7 重新构建。
• 阶段 6 负责 E2E 覆盖。它决定是否需要 E2E 覆盖，然后添加、更新、移除或明确跳过该覆盖。如果现有 E2E 测试保护的是非核心、非复杂、已过时、脆弱或过于繁杂的行为，并且产物说明移除为何能改善测试套件，则可以移除这些测试。
• 如果在负责阶段之前进行了单元测试、E2E 或浏览器相关工作，不要仅因时机问题而判定任务失败。将产物、差异和命令输出带入负责阶段，并在晋级前由该阶段做出当前的移除/更新/添加/跳过决定。

最小测试与重新运行规则

测试是生产代码。额外测试并非无害的证据；它们会增加维护负担、带来虚假的信心，并拖慢未来的工作流。

阶段 4 和阶段 6 必须将测试工作视为精简和最小化覆盖的决策，而不是“测试越多越安全”的步骤。

规则	要求的行为
不为现有测试保留特例	如果旧 Agent 添加了不必要、过时、脆弱、复杂、重复或非核心的测试，且这些测试与当前变更行为相关，则负责阶段必须将其删除或简化。
新增测试属于例外	只有在证明该行为稳定且属于核心行为，并且没有相关的现有测试可以妥善承载所需断言后，才能新增测试。
通过更多测试不代表质量更高	通过测试数量再多也不会提升门槛。门槛看重必要的覆盖、有用的断言，以及移除不良测试。
测试膨胀是警示信号	如果新增测试导致行数超限、fixture 频繁变动、helper 频繁变动、命令变慢、需要大范围重新运行测试，或引入新的维护结构，就应停止并重新评估这些测试是否应合并、精简、就地更新或删除。除非相关产物证明每项测试都有必要，否则不要通过增加更多结构来解决自己造成的测试膨胀。
每个新增测试都需要负担清单	对于每个新增的单元测试或 E2E 测试用例／文件，都要记录核心风险、检查过的相关现有测试、为什么更新／删除／N/A 不够、为什么断言已精简到最低限度，以及拒绝了哪种成本更低的验证方式。

• 测试应尽量精简。优先选择数量最少、但能保护核心行为或关键工作流的测试。针对偶发行为编写过多测试是代码库的问题，而不是质量的体现。
• 对于 E2E，只运行 Phase 6 决策所要求的新建、已更改或直接相关的规格。除非任务明确要求运行完整 E2E，或具体的书面仓库指令要求针对当前任务运行完整 E2E／所有规格，否则绝不要运行未经筛选的完整 E2E 套件；仓库中有 Playwright 套件、webServer 或“运行测试”脚本，都不足以构成运行完整套件的理由。在有必要的定向或相关 E2E 证据通过后，如果没有相关代码、测试、配置、固定数据、迁移或构建输入发生变化，就不要再运行完整 E2E，将其作为最终信心、最终验收、状态发现或满足审查者要求的证据。
• 对于单个定向 Playwright 脚本或 E2E 规格，延长超时并不是重试策略。使用最短且实用的超时时间：Phase 5 启动／页面状态／自定义脚本探测设为 15000-20000 毫秒；首次运行 Phase 6 定向 E2E 时，如果 Playwright 运行器启动会增加开销，最多可设为 30000 毫秒。如果运行出现任何有用的错误、断言输出、未找到状态、控制台／运行时错误、路由错误、固定数据／数据库缺失或辅助诊断信息，应根据这些证据诊断问题；不要用更长的超时时间重试。只有在首次运行仅因计时器到期而结束，且没有有用响应或说明时，才允许增加超时时间；并且只有在辅助日志、就绪状态、URL、未找到／错误状态、所需数据库／固定数据记录、服务端运行时日志、浏览器控制台以及网络／页面状态都证明应用和测试处于正确运行状态后，才可进行一次重跑，超时设为 60000 毫秒，单个定向脚本／规格的超时绝不能超过 120000 毫秒。如果单个定向运行需要超过两分钟才能完成，就停止增加超时时间；应先拆分验证程序，或诊断生命周期、设置、固定数据、页面状态、控制台、网络或测试设计问题。
• 不要仅为增强信心而重跑测试。只有在质量证据可能发生变化时才重跑：相关实现发生变化、测试发生变化、配置／环境发生变化、先前输出不完整／过时，或下一次运行能收集到修复实际故障所需的更具体诊断信息。
• 在重跑相同的失败测试命令前，记录自上次运行以来有哪些变化，或重跑会收集哪些新证据。如果没有任何变化且先前输出完整，应先检查日志、DOM／状态、跟踪记录、屏幕截图或持久化数据，再修改实现、测试、命令范围或诊断策略，然后才可再次运行。怀疑存在预先就有的故障或顺序依赖故障，并不是扩大到完整套件的理由；应通过范围最小的失败规格／测试及日志／状态／跟踪记录证据予以证实，然后修复范围内的问题，或记录为无关且有证据支持的差距。
• Phase 5 和 Phase 6 的产物必须记录超时值以及对无输出运行／超时的排查情况，之后才能通过门槛。首次运行的定向 Playwright 命令若超出 Phase 5／Phase 6 的时限，或任何更长的重跑未记录仅计时器超时及正常状态排查情况，都属于门槛失败。
• 如果命令看起来卡住或处于空闲状态，且工作流的下一步可在本地执行，就停止该命令，在当前阶段的产物或差距记录表中记录证据，然后继续采用有明确边界的恢复路径。

延续规则

• 每个阶段门禁都是内部控制点，而不是要求用户确认的检查点。
• 如果阶段门禁通过，直接进入下一阶段，不要询问是否继续。
• 如果阶段门禁未通过，返工该阶段，重新运行门禁并持续循环，不要征求用户继续的许可。
• 门禁、重做、验证和返工循环的目的是免去执行期间的用户确认，让 Agent 自主完成整个运行。
• 阶段产物未通过时，它是待修复项，而不是停止点。不要留下 Decision: Fail、Score: 0/...、待处理的门禁项或尚未解决且可在本地修复的警告，然后给出最终回复。
• 如果依赖项、启动详情或本地设置问题阻碍了进度，请采用最直接合理的解决方案，在保持工作流不变的前提下解决问题并继续。
• 不要因为可以在目标仓库或沙盒内解决的环境问题而降低技能的严格程度、跳过门禁或改变方向。
• 不要在任何阶段结束后停下来总结进度并询问是否继续。
• 如果后续阶段仍未通过且可在本地完成，不要在实现、构建、lint、测试、Playwright 验证或 E2E 工作后停止。
• 不要假设用户会发现走捷径的行为。Agent 必须杜绝捷径本身。 </autonomous_run_contract>

最终响应检查

在生成任何最终响应、停止消息，或以控制权交还用户的方式结束 OpenCode 轮次之前，请针对产物文件运行此检查：

1. task-workflow/CURRENT_PHASE.txt 必须为 phase-7-final-signoff。
2. task-workflow/progress.md 必须说明当前阶段为 phase-7-final-signoff，最后完成的关卡是 Phase 7，且除了最终响应外没有其他后续本地操作。
3. task-workflow/progress.md 必须包含当前阶段指针、阶段产物索引，以及标明详细证据所在位置的产物指针。
4. task-workflow/progress.md 不得重复列出阶段产物中的完整文件清单；其中只能列出恢复工作时立即需要的高优先级活动文件。
5. task-workflow/progress.md 必须列出压缩后需重新读取的仓库相对路径指令/上下文文件，包括 AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 中相关任务附件/支持文件，以及仅限 Phase 1 中选定的 .agents/skills/ 下相关且可用的技能文件。
6. 每个必需的阶段产物都必须标记 Decision: Pass。
7. 每项必需评分都必须达到阈值。
8. 每个关卡行都必须包含具体证据，不能使用 Pending 或模板默认值。
9. task-workflow/open-gaps.md 不得包含关键未解决问题、由已通过阶段负责的过时未解决问题，也不得包含占位行。
10. Phase 5、Phase 6 和 Phase 7 必须记录固定等待检查证据，证明检查过的验证文件不含固定等待。
11. Phase 5 和 Phase 7 必须为 Phase 5 中引用的每个截图路径记录截图存在性证明。
12. 若 Phase 4 要求运行单元测试命令，或 Phase 6 要求运行 E2E 命令，则该阶段和 Phase 7 必须记录精确的命令输出，或记录包含精确输出及最终通过/失败行的仓库本地日志文件。若无需进行单元/E2E 测试，则负责阶段和 Phase 7 必须记录 N/A 覆盖决定。若移除了测试，则负责阶段和 Phase 7 必须记录移除原因及差异/回读证据。
13. 对每个超时、无输出或较长时间重跑的 Playwright/E2E 命令，Phase 5、Phase 6 和 Phase 7 都必须记录超时值及超时/静默运行排查证据。
14. Phase 3 和 Phase 7 必须确认变更后的应用/服务端源代码中没有遗留 console.*。仅在 Phase 5 交互测试期间，为读取控制台输出并直接调试浏览器/运行时行为时，才允许临时使用 console.*；必须在 Phase 5 重跑、Phase 3 复查或 Phase 7 签核之前将其移除。
15. Phase 7 最终质量评分卡的每个类别都必须至少达到 8/10。
16. Phase 7 必须记录产物完整性审查，重新打开每个阶段产物并验证：产物存在、其决定为 Pass、评分达到阈值、必需证据行完整，且与 CURRENT_PHASE.txt、progress.md 或 open-gaps.md 不矛盾。
17. 只有在所有 Phase 7 审计检查均通过后，才能运行 .tasks/task.md 或提示词中指定的 MITB 完成命令。将其视为最终外部任务操作：必须在任务完成前规划并运行所有检查、测试、构建、服务探测和验证命令。如果任何 Phase 7 检查在任务完成前失败，Agent 必须返回最早失败的阶段，并且不得调用任务完成命令。

如果任何项目未通过，且问题可在本地解决，则从最早失败的阶段继续工作流。不得将任务描述为已完成。 如果确有外部阻碍导致无法完成，则在当前阶段产物和 open-gaps.md 中记录该阻碍，包括运行过的命令、检查过的文件、为何无法在本地恢复，以及最小后续操作。

OpenCode 回合连续性守卫

在 OpenCode 或其他工具驱动的编码会话中运行时，Agent 不得仅仅因为命令已完成、检查已通过、Lint 已启动、文件已编辑，或某个阶段产物暂时未通过，就结束助手回合。

每次工具返回结果后，在将控制权交还用户之前，请检查：

• CURRENT_PHASE.txt 是否早于 phase-7-final-signoff？
• 是否有任何必需的阶段产物仍标示 Decision: Fail？
• 当前阶段门是否仍包含 Pending、0/... 或缺失的证据？
• 下一项必需的工作流操作是否可以在本地执行？

如果前三项中任何一项的答案为是，且下一项操作可以在本地执行，则应立即在同一次运行中继续执行该操作。不要停在诸如“现在运行 Lint”“检查已通过”“接下来我会更新产物”或“剩余工作是……”这样的叙述性检查点。

仅以下情况可以作为有效的停止状态：

• 阶段 7 已通过，且最终回复守卫已通过。
• 当前产物和 open-gaps.md 中已完整记录确实存在的外部阻碍。

如果会话较长，请及时更新阶段产物，并继续分派下一项工具操作。不要指望用户输入“继续”来完成没有阻碍的阶段。

关键输出约束

以下为硬性约束：

• 目标应用必须是真正可交互的应用，而非静态样机。
• 实现必须在目标仓库中编写为真实的路由、布局、组件、状态、样式、后端契约、服务、查询、迁移和测试；是否需要这些内容，取决于阶段 4 或阶段 6 的覆盖范围决策。
• 主要页面或视图必须实现为真实的路由器路由或仓库原生路由模块，不能是在单个大型组件中以内存页面状态切换来实现。
• 任务要求或隐含要求的可见控件，必须成为目标应用中的真实控件；如果要求持久化，还必须具备相应状态和持久化行为。
• 后端和数据相关工作必须遵循仓库现有的服务、契约、查询和持久化边界。
• 前端运行时代码不得导入仅限服务端运行时使用的模块。
• 可复用的 UI 样式应放在共享基础组件、组件局部样式或现有设计令牌中，不得使用虚假的全局一次性组件类。
• 阶段 3 的检查／Lint 证据、阶段 4 的单元测试工作、阶段 5 的交互式 Playwright 验证，以及阶段 6 的 E2E 工作是彼此独立的门槛，任何一项都不能替代其他项。
• Agent 必须按部分、按路由、按状态、按流程逐一检查应用。
• 如果任何关键的可见操作、路由、数据变更或验证路径仍是虚假的、有问题的或未经检查的，则本次运行未通过。
• 不得仅为使新任务通过而删除现有测试。如果移除了过时测试，必须补上有用的覆盖，或说明旧覆盖为何不再适用。
• 类型断言、宽泛类型转换和屏蔽警告都不能替代正确的契约和经过收窄的类型。
• 最终签核中，每个质量类别都必须至少达到 8/10：功能结果、技能规范遵循／产物完整性、代码质量／可维护性、测试质量和总体结果。

参考资料加载规则

<reference_loading_rules>

默认情况下不要加载所有参考文件。

压缩与恢复加载规则

在压缩、恢复、重试、重新连接或开始新的编码会话后，使用 task-workflow/progress.md 和 task-workflow/CURRENT_PHASE.txt 确定当前状态，然后重新阅读：

1. 本主 SKILL.md
2. task-workflow/progress.md
3. task-workflow/CURRENT_PHASE.txt
4. 当前阶段产物
5. task-workflow/open-gaps.md
6. 阶段参考映射中当前阶段所需的参考文件
7. progress.md 中列出的相对于仓库的指令／上下文文件

压缩后不得依赖对话记忆。progress.md 和 CURRENT_PHASE.txt 用于确定当前运行进度，但不能取代主技能文件、当前阶段参考文件、当前阶段产物或差距记录表。只有重新加载这些文件后，运行才能继续。

阶段开始时的参考文件规则

每次开始一个阶段时（包括阶段提升后立即开始新阶段），都要先阅读该新阶段所需的参考文件，然后再进行阶段工作。

如果 CURRENT_PHASE.txt 发生变化，接下来的本地操作必须是加载阶段参考映射中为新标记指定的参考文件。未先阅读这些文件就开始阶段工作，该工作无效。

在全新运行中：

1. 阅读本 SKILL.md。
2. 开始阶段 0。
3. 仅加载 references/phase-0-1-startup-research.md。

在压缩、恢复、重试、重新连接或开始新的编码会话后：

1. 重新阅读本 SKILL.md。
2. 阅读 task-workflow/progress.md。
3. 阅读 task-workflow/CURRENT_PHASE.txt。
4. 阅读当前阶段产物和 task-workflow/open-gaps.md。
5. 重新阅读 progress.md 中列出的指令／上下文文件，包括 AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 中记录的相关附件／支持文件，以及 .agents/skills/ 中选定的相关技能文件。
6. 如果 progress.md、CURRENT_PHASE.txt 和阶段产物之间存在冲突，则从最早一个未通过的阶段产物继续。
7. 仅加载当前阶段对应的参考文件。
8. 仅当当前阶段参考文件要求进行交互式 Playwright 工作时，才加载 references/playwright-interactive.md。

阶段参考映射：

当前阶段标记	要加载的参考文件
缺少 task-workflow/	references/phase-0-1-startup-research.md
phase-0-artifact-reset	references/phase-0-1-startup-research.md
phase-1-task-research	references/phase-0-1-startup-research.md
phase-2-execution	references/phase-2-4-execution-integrity.md
phase-3-second-execution	references/phase-2-4-execution-integrity.md
phase-4-unit-coverage	references/phase-2-4-execution-integrity.md
phase-5-playwright-verification	references/phase-5-7-verification-signoff.md 和 references/playwright-interactive.md
phase-6-e2e-verification	references/phase-5-7-verification-signoff.md
phase-7-final-signoff	references/phase-5-7-verification-signoff.md

阶段参考文件按关联工作流分组，而不是每个阶段对应一个文件。这与参考技能模式一致：SKILL.md 保存严格的全局协议，参考文件则保存当前工作流的详细流程。

</reference_loading_rules>

运行模式

<operating_modes>

验证模式

在改进或测试技能本身时使用。

• 使用一次性目标仓库副本。
• 保留所有工作流产物。
• 评估不同全新运行之间的可重复性。
• 如果同一故障反复出现，应先改进可复用技能，再重新运行。

交付模式

在用户要求完成真实目标应用或任务时使用。

• 在提供的目标仓库中工作。
• 以任务文件为准。
• 在本文件和阶段参考文件中的所有关卡均以书面形式通过之前，不得签署完成。

</operating_modes>

必需的产物

以下内容为必需项：

• task-workflow/
• task-workflow/phase-0-artifact-reset.md
• task-workflow/phase-1-task-research.md
• task-workflow/phase-2-execution.md
• task-workflow/phase-3-second-execution.md
• task-workflow/phase-4-unit-coverage.md
• task-workflow/phase-5-playwright-verification.md
• task-workflow/phase-6-e2e-verification.md
• task-workflow/phase-7-final-signoff.md
• task-workflow/progress.md
• task-workflow/open-gaps.md
• task-workflow/CURRENT_PHASE.txt
• task-workflow/playwright/
• task-workflow/screenshots/
• task-workflow/scripts/
• task-workflow/scripts/playwright-lifecycle.mjs
• task-workflow/scripts/server-probe.mjs
• task-workflow/runtime/

assets/templates/ 中的模板是强制执行的产物。请直接复制其结构。如果必需的表格被替换为文字说明，或被删减到无法审计各行的程度，则本次运行失败。

多阶段协议

<multi_phase_protocol>

按顺序完成各阶段：

阶段 0：产物重置与脚手架搭建

删除上一项任务的 task-workflow/ 产物，根据模板重新创建所需的产物文件，并证明未编辑任何实现文件。

详细流程：references/phase-0-1-startup-research.md。

阶段 1：任务接收与代码库调研

阅读任务、根目录下的 AGENTS.md、.tasks/domain.md、.tasks/files/ 中的所有任务附件/支持文件、.agents/skills/ 中相关且可用的技能文件、相关文档和代码库。将 AGENTS.md 视为具有约束力的开发说明；在规划前提取与任务相关的规则。这些都是参考输入：阅读并引用，但不要编辑。记录对任务的理解、开发规则、已阅读或检查的任务文件、选用的技能、受影响的文件、可复用的模式、风险以及有序的实施计划。

详细流程：references/phase-0-1-startup-research.md。

阶段 2：主要执行

按调研所得计划的顺序执行，控制变更范围，并记录实施证据。

详细流程：references/phase-2-4-execution-integrity.md。

阶段 3：第二轮执行、完整性检查及检查/ lint 验证

将实现作为后续轮次进行审查，补齐缺失或薄弱的工作，将相关 UI/API/数据界面保持一致，执行实现完整性审查，并完成有序的检查/构建检查点。阶段 3 不要编写或运行单元/Vitest 或 E2E 测试。

详细流程：references/phase-2-4-execution-integrity.md。

阶段 4：单元测试覆盖决策与验证

判断是否需要单元、服务、组件或集成风格的测试。添加、更新、移除或明确跳过相应覆盖，然后仅运行有必要的单元级命令。移除不必要、过时、复杂难懂或用于保护非核心/非复杂行为的测试。

详细流程：references/phase-2-4-execution-integrity.md。

阶段 5：交互式 Playwright 验证

分两个阶段使用独立的交互式 Playwright 脚本。阶段 1 通过真实用户交互证明变更后的行为有效。阶段 2 验证 UI 质量：受影响的界面上没有损坏、拥挤、重叠、裁切、位置不当或无法响应的 UI。将响应式设计视为阶段 5 的首要保证，与证明任务的功能变更有效同等重要。留有一些空白没有问题，但在 1920x1080 等标准桌面视口中，界面不能显得损坏、裁切、重叠、无法使用或过于稀疏。2560x1440 等大型桌面视口可以有一些额外空白，但不能有大片空白区域，以免让 UI 显得尚未完成。当布局经过有意约束且仍然协调一致时，超大型 4K／超宽屏视口中的空白可以接受。

阶段 4／阶段 6 的测试最小化规则不会限制阶段 5。阶段 5 是面向用户的主要验证阶段，可以按需投入时间，覆盖变更后的流程、相关异常情况、周边 UI、响应式断点、截图和视觉正确性。必要时使用多个聚焦的 Playwright 脚本、探测、视口检查或重新运行，以证明受影响的用户体验正确；将测试范围限定在变更及相邻界面，但不要把阶段 5 缩减为浅层冒烟测试。

详细流程：references/phase-5-7-verification-signoff.md 和 references/playwright-interactive.md。

阶段 6：E2E 覆盖决策与验证

做出 E2E 覆盖决策。首先检查现有 E2E 覆盖；如果已有测试适合覆盖值得纳入的核心流程，则更新这些测试；仅当关键或复杂工作流无法通过现有测试清晰覆盖时，才添加新的 E2E 测试；删除保护非核心／非复杂或过于繁琐流程的不必要 E2E 测试；避免为细小的、仅视觉层面的或偶然出现的 UI 变更编写 E2E 测试。

详细流程：references/phase-5-7-verification-signoff.md。

阶段 7：最终审计与签核

重新阅读每项产物，确认所有先前的关卡在最后一次编辑后仍然通过，审查最终差异，并且仅在所有阶段 7 审计检查均通过后运行必需的 MITB 完成命令；只有在产物记录能够证明任务已完成时才签核。

阶段 7 是用于发现遗漏工作的证据验证阶段，而不是重新运行验证的阶段。如果某项必需检查、构建、测试、Playwright 运行、E2E 运行或其他由特定阶段负责的命令，已在其所属阶段正确完成，且证据仍然有效，那么阶段 7 只需验证该证据。只有在所属阶段遗漏了必需命令、记录的证据缺失／不完整／过时，或后续变更使其失效时，才重新运行命令；否则绝不能在阶段 7 重新运行检查、构建、测试、Playwright 或 E2E。

详细流程：references/phase-5-7-verification-signoff.md。

阶段参考资料不是可有可无的扩展内容，而是当前工作流的详细执行说明。

</multi_phase_protocol>

禁止的捷径与自动判定失败

<automatic_fails>

以下情况将自动导致本次运行失败：

阶段边界和产物失败

• Phase 1 通过前编辑应用程序或源文件
• Phase 0 产物尚不存在时编辑应用程序或源文件
• task-workflow/CURRENT_PHASE.txt 仍显示 phase-0-artifact-reset 或 phase-1-task-research 时编辑实现或源文件
• Phase 2 通过时，task-workflow/phase-2-execution.md 未记录在编辑源文件之前已将标记设置为 phase-2-execution
• 跳过产物重置
• 实现工作开始前未复制产物模板
• 未创建 task-workflow/progress.md、未在上下文压缩后重新读取该文件，或未及时更新该文件以便恢复工作
• 上下文压缩、重试、重新连接或开始新的编码会话后，未先使用 task-workflow/progress.md 和 task-workflow/CURRENT_PHASE.txt 确认状态，就继续工作；随后未重新阅读 SKILL.md、当前阶段产物、open-gaps.md 以及当前阶段要求的参考文件
• 阶段标记变更后，未先阅读该阶段要求的参考文件，就开始新阶段的工作
• 未在 task-workflow/progress.md 中记录并重新阅读所选的仓库相对路径指令/上下文文件，包括 AGENTS.md、.tasks/task.md、.tasks/domain.md、.tasks/files/ 中与任务相关的附件/支持文件，以及 .agents/skills/ 中相关的可用技能文件
• 仅将 AGENTS.md 作为上下文阅读，而未提取并遵循其中规定的与任务相关的开发规则
• 未经用户/任务明确要求编辑对应的参考文件，就编辑 .tasks/task.md、.tasks/domain.md、.tasks/files/、.agents/skills/ 下选定的技能文件或 AGENTS.md
• task-workflow/progress.md 中的 Current Phase Pointers、Phase Artifact Index 或 Artifact Pointers 过时、缺失，或与阶段产物矛盾
• 将 task-workflow/progress.md 当作重复的文件清单使用，而不是指向详细信息所在的阶段产物
• 声称某阶段已通过，却在阶段产物中遗漏了必需的语义证据
• 当前阶段或任何先前阶段的产物仍写着 Decision: Fail，却推进 task-workflow/CURRENT_PHASE.txt
• 当前阶段或任何先前阶段的产物仍有占位符 Pending 门禁证据，却推进 task-workflow/CURRENT_PHASE.txt
• 声称成功时，产物模板仍基本空白
• 声称 Phase 5 已通过，但产物中引用的任何截图路径缺失或未通过存在性证明核验
• 声称 Phase 6 已通过，但所需 E2E 运行仅作了描述，且确切命令输出未记录在产物中或其引用的仓库本地日志文件中
• 运行 Phase 5 或 Phase 6 的 Playwright/E2E 命令时，未记录正确的生命周期责任方：默认使用 helper；仅在事先记录原因/诊断后，才使用仓库 Playwright webServer 或手动回退方案
• 删除、重置、重新播种、截断或直接修改生产/线上工作区数据库，或将其用作测试/验证状态；这包括 .dbs/database.db、仓库默认用户数据数据库路径，以及任何等效的线上数据库路径
• 执行除仓库要求的真实架构变更应用迁移命令以外的任何生产/线上数据库操作；禁止的操作包括对 .dbs/database.db 或任何等效线上数据库路径执行手动查询、数据操作、播种、重置、测试夹具、Playwright、E2E、调试、清理、直接 SQLite 操作、自定义数据修复、删除或截断
• 除非是负责阶段中真实架构变更所需的应用迁移，并且有明确的迁移证据，否则运行生产数据库迁移
• 创建或更改迁移后，未通过仓库的应用迁移命令将其应用到生产/线上默认数据库并记录目标、命令、原因和输出，却通过 Phase 3

测试规范与覆盖率失败

• 对小型修复、轻微 UI 调整、文案更改、颜色／样式更改、间距／布局微调或简单的按钮接线添加或要求单元测试，却没有具体的核心行为或风险理由
• 为琐碎的组件分支、偶发的按钮点击、仅涉及视觉的更改或一次性的 UI 行为添加单元测试，而不是将单元测试保留给核心且稳定的行为
• 第 4 阶段确认可以移除不必要、过时、复杂难懂或非核心／非复杂的单元测试后，仍予以保留
• 添加单元测试，却没有提供逐项测试的必要性清单，证明现有测试无法更新、相关行为稳定且属于核心行为，并且每项新增断言都已精简至最低限度
• 将旧的 Agent 创建的单元测试以“已经存在”为由保留，但相关证据表明这些测试不必要、重复、脆弱、复杂难懂或非核心／非复杂
• 添加过多单元测试，以至于需要拆分测试文件、反复调整辅助工具或夹具，或大范围重新运行测试，却没有先减少或移除不必要的测试覆盖，并记录剩余大量测试为何必要
• 为非关键／非核心工作流、非复杂流程，或可通过更新现有 E2E 覆盖来妥善覆盖的行为添加新的 E2E 测试
• 第 6 阶段确认可以移除不必要、过时、脆弱、复杂难懂或非核心／非复杂的 E2E 测试后，仍予以保留
• 添加 E2E 测试，却没有提供逐项测试的必要性清单，证明现有 E2E 测试无法更新、相关工作流足够关键／核心或复杂到需要 E2E 测试，并且每项新增断言都已精简至最低限度
• 将旧的 Agent 创建的 E2E 测试以“已经存在”为由保留，但相关证据表明这些测试不必要、重复、脆弱、复杂难懂或非核心／非复杂
• 在第 4 阶段，任何有必要的定向／关联单元级测试尚未通过时，就先运行范围过广／完整的单元测试或 Vitest 测试套件
• 没有目标代码库说明、已更改的全局／共享基础设施或不完整／过时输出等具体制品作为理由，却多次运行完整的单元测试或 Vitest 测试套件
• 缺少第 4 阶段的制品证据，无法证明有必要的定向／关联测试已通过，且当前运行是最后一次完整检查；或任务／代码库／全局更改明确要求更广的测试范围，却运行范围过广／完整的单元测试或 Vitest 测试
• 在第 2 阶段的每次小修改后都运行常规检查、lint 或构建，而不是保留各阶段的证据，并将第 3 阶段作为按顺序进行检查／构建的节点
• 在运行命令前没有记录具体的编译／类型检查阻碍，却在第 2 阶段运行代码库的组合检查命令，例如 pnpm run check
• 在修复上一次输出中所有可见且可在本地修复的问题组之前，重新运行检查、lint 或构建；如果截断的 tail/head 输出隐藏了问题组，仅凭这些输出并不足够，而且提取问题后必须删除临时的完整输出日志
• 第 3 阶段的构建证据仍然有效，且没有记录任何会使其失效的更改时，却在第 4、第 5、第 6 或第 7 阶段重新运行构建

Playwright 和 E2E 命令失败

• 在第 6 阶段直接运行原生 pnpm exec playwright test ...，而不是通过 task-workflow/scripts/playwright-lifecycle.mjs --run ... 运行，除非需要由仓库 webServer 负责启动服务，并且已在运行命令前记录这一点
• 在任务未明确要求完整 E2E，且没有具体的书面仓库说明要求针对本任务运行完整 E2E／所有 spec 的情况下，运行未经筛选的完整 Playwright/E2E 套件
• 在第 5／6 阶段运行 rm、seed、migrate、sqlite3、tsx server/db/seed、测试固件设置或任何数据库清理命令，除非相关材料首先证明该命令的目标是隔离的、由仓库负责管理的测试/E2E 数据库，而不是生产／真实用户数据
• 在没有针对任务的材料说明理由时，首次运行第 5 阶段定向 Playwright 脚本的时限超过 20000 毫秒，或首次运行第 6 阶段定向 E2E 的时限超过 30000 毫秒
• 在获得任何有用的失败证据后增加 Playwright/E2E 超时，或者在仅超时／无输出的失败后增加超时，却没有记录辅助日志／就绪状态／URL／数据库测试固件／服务日志／浏览器控制台／网络／页面状态的排查结果来证明应用和测试均有效，可以重新运行
• 仅为增强信心而重新运行测试，或盲目地重新运行相同的失败测试命令，却没有记录实现、测试、配置、环境、输出陈旧或诊断方面的实质性原因
• 在任务验证期间运行 playwright install、playwright install chromium 或等效命令下载浏览器，而不是使用沙盒浏览器缓存，或记录辅助工具的浏览器预检不匹配情况

连续性和证据失败

• 在更改后的应用／服务源代码仍含有 console.*，且当前不处于第 5 阶段调试循环时，通过第 3 或第 7 阶段
• 在 CURRENT_PHASE.txt 尚未到达 phase-7-final-signoff 时生成最终回复或停止摘要
• 在任何必需材料仍写着 Decision: Fail、评分未通过或包含待处理门禁证据时生成最终回复或停止摘要
• 在下一项工作流操作可在本地执行时，于某个 OpenCode 回合中途结束该阶段
• 在 task-workflow/phase-2-execution.md 的执行日志仍为空白或全部为 Pending 时编辑第 2 阶段源文件
• 在更新多个第 2 阶段实现包的执行日志行并附上文件证据之前，就完成这些实现包
• 用散文替代表格证据
• 跳过第二次执行
• 将第 3 阶段检查／Lint 证据视为第 4 阶段单元测试覆盖决策、第 5 阶段交互式 Playwright 验证或第 6 阶段 E2E 覆盖决策的替代品
• 将 Playwright 验证视为必要的第 4 或第 6 阶段测试工作的替代品
• 将第 5 阶段交互式 Playwright 验证或第 6 阶段 E2E 覆盖工作视为完成第 2 阶段门禁的替代品
• 让长时间运行的开发服务器、监视程序或交互式命令持续在前台运行，直到会话卡住
• 对门禁所需文件的写入或补丁操作，仅凭写入结果而不提供回读证据
• 在写入结果失败、无效或不确定后继续操作，而不先修复并重新读取目标文件

最终签核失败

• 仍有关键未解决问题时就签核
• task-workflow/open-gaps.md 中仍有过时的未解决问题，而后续已通过的阶段声称这些问题已解决时就签核
• task-workflow/open-gaps.md 中仍包含 Pending 等模板占位行时就签核
• 未记录固定等待审查证据就通过 Phase 5、Phase 6 或 Phase 7
• task-workflow/playwright 或 tests/e2e 中仍有固定等待时就通过 Phase 5、Phase 6 或 Phase 7
• 未记录对每个阶段产物的完整性审查就通过 Phase 7
• 任何最终质量评分卡类别低于 8/10 时就签核
• 删除现有测试，却没有提供等效的替代覆盖或书面产物说明
• 没有范围明确且有证据支持的理由，却使用宽泛的不安全类型转换或警告抑制来绕过类型系统
• 压缩后依赖对话记忆，而不是使用 progress.md 和 CURRENT_PHASE.txt 获取状态，并重新阅读本技能、必需的阶段参考文件和产物
• 即使 .tasks/files/ 为空，也未列出其内容
• 在 Phase 1 规划前，未读取或检查 .tasks/files/ 中的每个任务附件/支持文件
• 批量读取 .agents/skills/ 中的所有技能文件，而不是仅选择并阅读与任务相关的技能
• 规划、实施、验证或签核违反提取出的 AGENTS.md 开发规则的工作
• 在 Phase 7 所有审计检查通过前运行 MITB 任务完成命令
• Phase 7 的任何审计检查失败时，未回退到最早的失败阶段
• Phase 7 所有审计检查通过后，未运行必需的 MITB 完成命令
• 下一阶段已解除阻塞时，仍询问用户是否要继续

</automatic_fails>

参考索引

• references/phase-0-1-startup-research.md：产物重置、模板复制、任务接收和代码库调研。
• references/phase-2-4-execution-integrity.md：主要执行、第二次执行、差距修复和完整性检查。
• references/phase-5-7-verification-signoff.md：交互式 Playwright 验证、E2E 覆盖决策和最终审计。
• references/playwright-interactive.md：本技能如何使用独立的交互式 Playwright 脚本。
• assets/templates/phase-0-artifact-reset.md
• assets/templates/phase-1-task-research.md
• assets/templates/phase-2-execution.md
• assets/templates/phase-3-second-execution.md
• assets/templates/phase-4-unit-coverage.md
• assets/templates/phase-5-playwright-verification.md
• assets/templates/phase-6-e2e-verification.md
• assets/templates/phase-7-final-signoff.md
• assets/templates/progress.md
• assets/templates/open-gaps.md
• assets/scripts/playwright-lifecycle.mjs：托管服务器/就绪状态/Playwright 执行辅助脚本，在 Phase 0 期间复制到 task-workflow/scripts/。
• assets/scripts/server-probe.mjs：托管 API/运行时服务器探测辅助脚本，在 Phase 0 期间复制到 task-workflow/scripts/，用于 Phase 5 前的服务器检查。

不可妥协的要求

• 严格遵循各阶段关卡。
• 确保产物可审计。
• 证据不足时返回较早阶段。
• Phase 0 和 Phase 1 关卡通过前，不得编辑源文件。
• 交互式 Playwright 验证和回归测试关卡通过前，不得签核。

完成标准

只有 Phase 7 通过，任务才算完成。 如果任务无法完成，最终产物必须指出确切的阻塞条件、发生问题的阶段、运行过的命令、检查过的文件，以及所需的最小后续操作。