task-workflow

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Task Workflow

任务工作流

Strict Instruction Contract

严格指令约定

This file is strict implementation instruction, not loose guidance and not optional reference material.

This is the canonical workflow for task execution. It is not one possible way to do the task; it is the required way.

If the Agent reads this skill, it must execute it exactly as written, in order, to the letter.

Required behavior:

Do not reinterpret the steps.
Do not reorder the steps.
Do not skip the steps.
Do not replace the steps with a simpler approach.
Do not make assumptions that override this file.
Do not treat broad similarity, intuition, or prior habits as permission to deviate.

If the Agent is uncertain, it must resolve that uncertainty inside the workflow defined here and not invent its own workflow. If the skill says to perform a step, gate, checklist, review, or loop, that step is mandatory. If the skill says a later phase is blocked, the Agent must treat it as blocked. If the Agent cannot prove a phase passed in the required artifact, it must treat that phase as failed.

There is no successful stopping point before Phase 7. Stopping early can directly harm the user because they may depend on the completed workflow for job-critical work. It is a do-or-die situation: the user can be harmed if the run has not reached Phase 7 correctly, and the user can lose his job if the Agent stops early, signs off weak work, skips a gate, or damages live data. Treat premature stopping, partial signoff, live-data damage, or "mostly done" summaries as a serious failure of duty.

The first filesystem action in the target repo must be Phase 0 artifact reset and scaffolding.

Before

task-workflow/phase-0-artifact-reset.md

exists, the Agent may only:

identify the target repo root
read this
```
SKILL.md
```
read the task file
create or replace
```
task-workflow/
```
artifacts from templates

Before Phase 1 passes, the Agent must not edit or generate implementation files, build outputs, databases, route types, migrations, tests, package files, or source files.

Production and live workspace databases, especially

.dbs/database.db

, are do-or-die user data. Deleting, resetting, reseeding, truncating, inspecting with ad hoc writes, or modifying them outside the app's legitimate migration command can destroy user work and can cause the user to lose his job. The only permitted production/live DB action is the repo's required app migration command for a real schema change. That exception does not permit "working on" the production DB: no manual query, data manipulation, seed, reset, fixture load, data repair, cleanup, delete, truncate, direct SQLite command, or debug mutation is allowed.

After Phase 1 passes and before any implementation edit, the Agent must set

task-workflow/CURRENT_PHASE.txt

phase-2-execution

CURRENT_PHASE.txt

still says

phase-0-artifact-reset

phase-1-task-research

, implementation files must remain unchanged.

If implementation files, generated app files, build outputs, or database files are changed before Phase 0 artifacts exist and Phase 1 passes, the run has failed and must be restarted from a clean fixture.

本文件为严格的执行指令，而非宽松指南或可选参考资料。

这是任务执行的标准工作流，并非完成任务的一种可行方式，而是必须遵循的方式。

若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阶段通过前，修改了实现文件、生成的应用文件、构建输出或数据库文件，运行已失败，必须从干净的测试环境重新启动。

Core Idea

核心理念

Re-read this

SKILL.md

after every compaction before continuing work. Re-load the phase references and current task artifacts too. Do not rely on conversational memory.

This skill is a gated execution protocol, not a loose set of suggestions. It turns a task into a repeatable, artifact-driven workflow. The target app must be implemented from the task, target repo, and local codebase evidence, then proven through Phase 3 check/lint evidence, Phase 4 unit-test coverage decision, Phase 5 interactive Playwright verification, Phase 6 E2E coverage decision, and final audit.

Assume this skill may run fully autonomously and may be compacted mid-run. No human is expected to watch the run line by line. The artifact files are therefore the enforcement system. A phase is not complete because the Agent feels confident. A phase is complete only when its required artifact shows a real passing score and all critical items pass.

task-workflow/progress.md

is the compact resume ledger. It must summarize the task, current phase, completed phase context, active work queue, verification state, and next local action. Hard rule: after compaction, resume, retry, reconnect, or new coding session, read it and

task-workflow/CURRENT_PHASE.txt

before doing any new work. Keep it current as work proceeds; it is the first file that should restore enough context to continue without conversation memory.

Never promote work from one phase to the next on optimism, partial evidence, a green build alone, or broad product similarity.

The workflow is intentionally looped. A failed gate means the Agent must rework that phase, update evidence, rerun the needed checks or verification, rescore the gate, and repeat until the gate passes. Quality gates are not reports to the user; they are control points that force more work before promotion.

每次压缩后继续工作前，重新阅读本

SKILL.md

。同时重新加载阶段参考文件和当前任务工件。不要依赖对话记忆。

本技能是一个门禁式执行协议，而非宽松的建议集合。它将任务转化为可重复、以工件为驱动的工作流。目标应用必须根据任务、目标仓库和本地代码库证据实现，然后通过第3阶段检查/代码规范证据、第4阶段单元测试覆盖决策、第5阶段交互式Playwright验证、第6阶段E2E覆盖决策和最终审计来验证。

假设本技能可能完全自主运行，且可能在运行中途被压缩。预计不会有人逐行监控运行过程。因此，工件文件是执行系统的核心。阶段完成的标准不是Agent感到自信，而是其所需工件显示真实的通过分数，且所有关键项均通过。

task-workflow/progress.md

是压缩后的恢复台账。它必须总结任务、当前阶段、已完成阶段的上下文、活跃工作队列、验证状态和下一个本地操作。硬性规则：压缩、恢复、重试、重新连接或开启新编码会话后，在进行任何新工作前，先阅读该文件和

task-workflow/CURRENT_PHASE.txt

。随着工作推进，保持其更新；它是无需对话记忆即可恢复足够上下文以继续工作的第一个文件。

绝不能基于乐观态度、部分证据、仅通过构建或大致产品相似性，将工作从一个阶段推进到下一个阶段。

工作流故意设计为循环模式。门禁失败意味着Agent必须重新处理该阶段，更新证据，重新运行所需检查或验证，重新评估门禁分数，重复此过程直到门禁通过。质量门禁不是向用户提交的报告，而是强制在推进前完成更多工作的控制点。

MITB Workspace Inputs

MITB工作区输入

When running in a MITB sandbox, use these repo-relative workspace inputs:

workflow skill:
```
.agents/skills/task-workflow/SKILL.md
```
task body:
```
.tasks/task.md
```
domain and brand context:
```
.tasks/domain.md
```
attached task files:
```
.tasks/files/
```
available skill files:
```
.agents/skills/
```

AGENTS.md

is the target repo's binding development-instructions file. It defines project-specific rules for architecture, type safety, tests, UX, commands, code style, docs, prohibited patterns, and completion. Phase 1 must extract the task-relevant rules from

AGENTS.md

before planning edits, including any required docs it points to. Later gates must verify the implementation follows those extracted rules.

Phase 1 must read

.tasks/domain.md

. It must enumerate

.tasks/files/

even when the folder is empty, then read or inspect every task attachment/supporting file in that folder before planning.

Available skills are kept under

.agents/skills/

. Discover available skills from the prompt's Skills section and

.agents/skills/

, then read only the selected skill

SKILL.md

files relevant to the current task. Do not bulk-read every skill file in

.agents/skills/

All Phase 1 input/reference files are read-only. This includes

AGENTS.md

.tasks/task.md

.tasks/domain.md

, every file under

.tasks/files/

, and every selected skill file under

.agents/skills/

. Treat files under

.tasks/

as canonical task inputs, not editable workspace artifacts. Do not rewrite, normalize, consolidate, clean up, trim, reformat, or "fix" these files unless the task explicitly asks to update that exact reference file. If a reference file appears inconsistent, record the ambiguity in

task-workflow/phase-1-task-research.md

task-workflow/open-gaps.md

; never resolve it by editing the reference input.

Record every

.tasks/files/

attachment/supporting file read or inspected, plus every selected skill path and why it was relevant, in

task-workflow/phase-1-task-research.md

and

task-workflow/progress.md

. After compaction or resume, re-read the selected relevant skill files listed in

progress.md

along with

AGENTS.md

.tasks/task.md

.tasks/domain.md

, and the relevant

.tasks/files/

attachments/supporting files recorded in Phase 1.

In MITB,

.tasks/task.md

or the prompt always provides the task completion command. Phase 7 must run the exact completed command only after every Phase 7 audit check passes. If any Phase 7 audit check fails, do not run task completion. Return to the earliest failing phase, repair the work, update evidence, rescore that phase, loop forward through the gates, and then re-enter Phase 7.

在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/

下。从提示的技能部分和

.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

强制流程框架

<mandatory_process_shape>

This workflow shape is not optional:

Clear old workflow artifacts for this repo and copy fresh artifact templates.
Read the task, root
```
AGENTS.md
```
,
```
.tasks/domain.md
```
, every task attachment/supporting file in
```
.tasks/files/
```
, only relevant available skill files from
```
.agents/skills/
```
, and relevant project docs. Extract the task-relevant development rules from
```
AGENTS.md
```
before planning. These instruction, task, domain, attachment, and skill-reference files are read-only unless the task explicitly asks to edit them.
Research the codebase and record the implementation plan.
Execute the primary implementation.
Execute a second gap-closure pass.
Run second-pass integrity review and repo check/lint validation.
Make the unit-test coverage decision: add, update, remove, or explicitly skip unit tests.
Verify interactively with standalone Playwright scripts.
Make the E2E coverage decision: add, update, remove, or explicitly skip E2E tests.
Recheck every phase artifact and sign off only when all gates pass.

If the work skips one of those phase boundaries, the run is off track.

<mandatory_process_shape>

本工作流框架为强制性要求：

清除本仓库的旧工作流工件，复制新的工件模板。
阅读任务、根目录
```
AGENTS.md
```
、
```
.tasks/domain.md
```
、
```
.tasks/files/
```
中的每个任务附件/支持文件、
```
.agents/skills/
```
中仅相关的可用技能文件，以及相关项目文档。在规划前，从
```
AGENTS.md
```
中提取与任务相关的开发规则。这些指令、任务、领域、附件和技能参考文件为只读，除非任务明确要求编辑它们。
研究代码库并记录实现计划。
执行主要实现工作。
执行第二轮缺口填补工作。
执行第二轮完整性评审和仓库检查/代码规范验证。
做出单元测试覆盖决策：添加、更新、移除或明确跳过单元测试。
使用独立Playwright脚本进行交互式验证。
做出E2E覆盖决策：添加、更新、移除或明确跳过E2E测试。
重新检查每个阶段工件，仅当所有门禁通过时签署确认。

若工作跳过这些阶段边界之一，运行即偏离轨道。

Phase Ownership Matrix

阶段职责矩阵

Phase	Owns	Required evidence
Phase 0	artifact reset and scaffold	fresh artifacts, helper scripts, marker, no source edits
Phase 1	task intake and research	task/domain/attachments/AGENTS/selected skills read, codebase research, implementation plan
Phase 2	primary implementation	scoped work packets, file evidence, readback/diff/search proof
Phase 3	second execution, integrity, check/lint validation	connected-surface review, repo check, focused lint when useful, build, reusable build evidence
Phase 4	unit-test coverage decision	add/update/remove/skip decision, existing-test inspection, minimal unit command or `N/A`
Phase 5	interactive Playwright verification	Stage 1 behavior proof, Stage 2 UI/responsive proof, screenshots, lifecycle evidence
Phase 6	E2E coverage decision	add/update/remove/skip decision, connected E2E inspection, minimal E2E command or `N/A`
Phase 7	final audit and signoff	artifact integrity review, current evidence, MITB completion command after audit

</mandatory_process_shape>

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

</mandatory_process_shape>

Looped Gate Contract

循环门禁约定

Every phase follows the same loop:

Re-read the required reference file or files for the phase from the Phase Reference Map.
Perform the phase work.
Update the phase artifact with concrete evidence.
Score the phase against its gate.
If the gate fails, stay in the same phase, repair the failing work or missing evidence, and repeat this loop.
If the gate passes, write the promotion-lock evidence, advance
```
task-workflow/CURRENT_PHASE.txt
```
, and immediately start the next phase.

This loop is mandatory for Phase 0, Phase 1, Phase 2, Phase 3, Phase 4, Phase 5, Phase 6, and Phase 7.

Do not lower a gate threshold to escape the loop. Do not summarize failure as progress when the next local repair is available. Do not wait for the user to tell you to continue when the phase can be repaired locally. Do not move forward with a weak artifact because the implementation "probably works".

The only acceptable end state is Phase 7 passed with every earlier phase still passing. The only acceptable non-Phase-7 stop is a real external blocker that cannot be solved locally and is fully recorded in the current phase artifact and

task-workflow/open-gaps.md

每个阶段遵循相同循环：

从阶段参考映射中重新读取该阶段所需的参考文件。
执行该阶段工作。
用具体证据更新阶段工件。
根据门禁标准评估该阶段分数。
若门禁失败，停留在同一阶段，修复失败工作或补充缺失证据，重复此循环。
若门禁通过，写入晋升锁定证据，更新
```
task-workflow/CURRENT_PHASE.txt
```
，立即启动下一阶段。

此循环对第0、1、2、3、4、5、6、7阶段均为强制性要求。

不得降低门禁阈值以跳出循环。不得在本地可修复时将失败总结为进展。不得在阶段可本地修复时等待用户指示继续。不得因实现“可能可行”而带着薄弱工件推进。

唯一可接受的最终状态是第7阶段通过，且所有前期阶段仍保持通过状态。唯一可接受的非第7阶段终止状态是存在无法本地解决的真实外部阻塞，且已完整记录在当前阶段工件和

task-workflow/open-gaps.md

中。

Autonomous Run Contract

自主运行约定

<autonomous_run_contract>

Treat these rules as always active.

<autonomous_run_contract>

以下规则始终生效。

Gate And Artifact Rules

门禁与工件规则

Every phase must end with an objective gate.
Every gate must be recorded in the phase-owned artifact file.
Every gate must have both a numeric threshold and critical-item pass requirement.
If a gate fails, remain in that phase and keep iterating.
A failed gate means "repair and loop", not "stop and report".
Successful gates must immediately promote to the next phase when the next phase is locally available.
```
task-workflow/CURRENT_PHASE.txt
```
is only a resume pointer. It is not proof that earlier phases passed.
```
task-workflow/progress.md
```
is the compact resume ledger. It is not proof that gates passed, but it must stay current enough to resume the run after compaction.
After every phase start, meaningful Phase 2 work packet, phase gate result, blocker discovery, and phase promotion, update
```
task-workflow/progress.md
```
with the current phase, earliest failing phase if any, last completed gate, next local action, and a compact summary of relevant context.
Keep the
```
Current Phase Pointers
```
,
```
Phase Artifact Index
```
, and
```
Artifact Pointers
```
in
```
task-workflow/progress.md
```
current. They must point to the current phase artifact, current phase reference, and high-signal active files only. Do not duplicate full researched-file, edited-file, Playwright, screenshot, log, or test inventories from phase artifacts into
```
progress.md
```
.
After compaction, resume, retry, reconnect, or new coding session, re-read this
```
SKILL.md
```
,
```
task-workflow/progress.md
```
,
```
task-workflow/CURRENT_PHASE.txt
```
, the current phase artifact,
```
task-workflow/open-gaps.md
```
, and the required current phase reference file or files before choosing the next action. If they disagree, inspect the phase artifacts and continue from the earliest failing phase.
A phase may advance the current phase marker only after its phase-owned artifact has
```
Decision: Pass
```
, a passing score, all critical items passing, and no placeholder
```
Pending
```
rows in the gate or required evidence sections.
The current phase marker must be written before work belonging to that phase begins. The marker is not merely cleanup after phase work.
Before writing the next phase marker, re-open the current phase artifact and verify the promotion lock in writing inside that artifact.
Immediately after writing a new phase marker, read the required reference file or files for that new phase before doing any work in that phase.
If
```
CURRENT_PHASE.txt
```
points past the earliest failing phase artifact, artifact gates win. Correct
```
CURRENT_PHASE.txt
```
back to the earliest failing phase and continue there.
When filling artifact templates, preserve auditable evidence for every required semantic category. Exact row wording may be condensed only if the same evidence remains clear and scorable.
```
task-workflow/open-gaps.md
```
is a gate artifact. A later phase may not claim a gap is resolved unless the gap ledger is updated in the same phase.
A gap cannot remain
```
Open
```
after the phase named in its owner or next-action field has passed. If the later phase completed the work, move the gap to
```
Resolved Gaps
```
; if the gap is not real, reclassify or close it with evidence.
```
task-workflow/open-gaps.md
```
must not contain template placeholder rows such as
```
Pending
```
after Phase 0. If there are no gaps, replace placeholder rows with explicit
```
None currently recorded
```
rows.
Phase 7 cannot pass while any critical gap remains
```
Open
```
, stale, or contradicted by another phase artifact.

每个阶段必须以客观门禁结束。
每个门禁必须记录在该阶段所属的工件文件中。
每个门禁必须同时具备数值阈值和关键项通过要求。
若门禁失败，停留在该阶段并持续迭代。
门禁失败意味着“修复并循环”，而非“停止并报告”。
门禁成功后，若下一阶段可本地执行，必须立即晋升至下一阶段。
```
task-workflow/CURRENT_PHASE.txt
```
仅为恢复指针，并非前期阶段已通过的证明。
```
task-workflow/progress.md
```
是压缩后的恢复台账。它并非门禁通过的证明，但必须保持足够更新，以便压缩后恢复运行。
每个阶段启动、第2阶段有意义的工作包完成、阶段门禁结果产生、发现阻塞、阶段晋升后，必须更新
```
task-workflow/progress.md
```
，包含当前阶段、最早失败阶段（若有）、最后完成的门禁、下一个本地操作，以及相关上下文的简洁总结。
保持
```
task-workflow/progress.md
```
中的“当前阶段指针”、“阶段工件索引”和“工件指针”更新。它们必须仅指向当前阶段工件、当前阶段参考文件和高信号活跃文件。不得将阶段工件中的完整调研文件、编辑文件、Playwright、截图、日志或测试清单复制到
```
progress.md
```
中。
压缩、恢复、重试、重新连接或开启新编码会话后，在选择下一个操作前，重新阅读本
```
SKILL.md
```
、
```
task-workflow/progress.md
```
、
```
task-workflow/CURRENT_PHASE.txt
```
、当前阶段工件、
```
task-workflow/open-gaps.md
```
和当前阶段所需的参考文件。若它们存在不一致，检查阶段工件，从最早失败的阶段继续。
仅当阶段所属工件显示“决策：通过”、分数达标、所有关键项通过，且门禁或所需证据部分无占位符“待处理”行时，阶段才能更新当前阶段标记。
当前阶段标记必须在该阶段工作开始前写入，标记并非阶段工作后的清理步骤。
写入下一阶段标记前，重新打开当前阶段工件，验证工件内的晋升锁定书面记录。
写入新阶段标记后，立即阅读该新阶段所需的参考文件，再进行该阶段的任何工作。
若
```
CURRENT_PHASE.txt
```
指向的阶段早于最早失败阶段工件，以工件门禁为准。将
```
CURRENT_PHASE.txt
```
修正为最早失败阶段并继续。
填充工件模板时，保留每个所需语义类别的可审计证据。仅当相同证据仍清晰可评分时，才可压缩行的精确措辞。
```
task-workflow/open-gaps.md
```
是门禁工件。后续阶段不得声称缺口已解决，除非同一阶段更新了缺口台账。
若缺口所有者或下一操作字段中指定的阶段已通过，缺口不得保持“开放”状态。若后续阶段完成了相关工作，将缺口移至“已解决缺口”；若缺口不真实，重新分类或通过证据关闭。
第0阶段后，
```
task-workflow/open-gaps.md
```
不得包含“待处理”等模板占位符行。若无缺口，将占位符行替换为明确的“当前无记录缺口”行。
若存在任何关键缺口仍处于“开放”、过期状态，或与其他阶段工件矛盾，第7阶段无法通过。

Verification File Rules

验证文件规则

Phase 5 and Phase 6 must review the interactive scripts and E2E tests for fixed waits before passing.
A fixed wait in
```
task-workflow/playwright
```
or
```
tests/e2e
```
is a gate failure. Do not justify it. Replace it with deterministic Playwright waits/assertions such as
```
locator.waitFor(...)
```
,
```
expect(locator)...
```
,
```
waitForURL(...)
```
,
```
waitForResponse(...)
```
, or persisted-state assertions, then rerun verification.
Phase 5, Phase 6, and Phase 7 may pass only when their artifacts document that the inspected verification files contain no fixed waits and cite the deterministic waits/assertions used instead.
If later work reveals missing evidence from an earlier phase, return to that earlier phase, repair it, and re-pass the gate.

第5阶段和第6阶段必须在通过前，检查交互式脚本和E2E测试中的固定等待。
```
task-workflow/playwright
```
或
```
tests/e2e
```
中的固定等待视为门禁失败。不得为此辩解。将其替换为确定性Playwright等待/断言，如
```
locator.waitFor(...)
```
、
```
expect(locator)...
```
、
```
waitForURL(...)
```
、
```
waitForResponse(...)
```
或持久化状态断言，然后重新运行验证。
仅当工件记录检查的验证文件无固定等待，并引用了使用的确定性等待/断言时，第5、6、7阶段才可通过。
若后续工作发现前期阶段缺失证据，返回该前期阶段，修复后重新通过门禁。

Write And Command Rules

写入与命令规则

After every file write, patch, generated-file creation, or artifact update that matters to a gate, perform a readback check before relying on it. Use
```
sed
```
,
```
rg
```
,
```
ls
```
,
```
git diff
```
, or the repo's normal inspection command to prove the file exists and contains the intended change.
If a write/edit tool reports an invalid write, missing file, failed patch, partial output, or uncertain result, stop that work packet, repair the write with a supported edit method, read it back, and only then continue. Do not proceed as if a failed write happened.
Commands must be bounded. Do not leave long-lived servers, watchers, or interactive commands running in the foreground as the active tool call.
Production/live workspace databases must never be used as test or verification state. In this skill, "production database" means
```
.dbs/database.db
```
, any repo-declared live/default user-data database, or any database path used by the normal app outside an isolated test/E2E config. The only allowed action on
```
.dbs/database.db
```
or any production/live database is the repo's required application migration command for a real schema change, run in the phase that owns that migration and recorded as migration evidence. This is a narrow migration-execution exception, not permission to work on the production DB. If the task creates or changes a migration, running the repo's app migration command against the production/live default DB is mandatory after the migration exists and before Phase 3 promotes; the user uses the completed app immediately, so unapplied migrations make the delivered change invisible or broken. No other production/live DB action is allowed: no manual query, data manipulation, seed, reset, fixture, Playwright, E2E, probe, debugging, cleanup,
```
rm
```
, truncate, direct SQLite, custom data repair, or data inspection with write risk. If the command might touch production data and the artifact cannot prove it is the repo migration command for a real schema change or an isolated test DB operation, do not run it.
Outside Phase 5 and Phase 6, if a temporary dev server is needed for an API/runtime probe, use
```
task-workflow/scripts/server-probe.mjs
```
. It owns PID capture, readiness, bounded probe commands, runtime logs, and PID-only cleanup. Server readiness is usually 5-10 seconds; use 15-20 seconds as the normal budget and 30 seconds as the maximum startup-readiness limit. Broad process-name cleanup is only for explicit sandbox-owned recovery when PID/port cleanup is impossible and the artifact records why.
In Phase 5 and Phase 6, the first browser, Playwright, or E2E command that needs a running app must establish lifecycle ownership through
```
task-workflow/scripts/playwright-lifecycle.mjs
```
by default. Do not run against an assumed existing server first and then infer that
```
fetch failed
```
, stale data, redirects, or wrong build output means manual server management is needed.
Existing repo E2E tests are not a reason to bypass the helper. Run
```
pnpm exec playwright test ...
```
through the helper's
```
--run
```
by default. Use native Playwright with repo
```
webServer
```
ownership only when the helper cannot own the server for that exact command after a diagnosed reason, and record that reason before running it.
The helper's
```
--env
```
is not a database-path override mechanism. Never set
```
E2E_DATABASE_FILE_PATH
```
,
```
DATABASE_PATH
```
,
```
DB_PATH
```
, or any similar database file/path variable in helper, setup, server, or run commands. The agent must not change the repo's internal E2E/end-to-end database file path. Test database paths must come from the repo's checked-in E2E/end-to-end config or the already-materialized environment.
```
.dbs/database.db
```
is the live workspace/production database; production databases must never be used for testing. Using
```
.dbs/database.db
```
for Playwright, E2E, fixtures, seed, reset, inspection, cleanup, or debugging is a critical failure even if it appears only in
```
task-workflow/
```
. The user can lose his job if this database is deleted or corrupted.
Expected verification lifecycle pattern: discover the repo-owned setup and server commands from
```
AGENTS.md
```
,
```
package.json
```
, README/docs, Playwright config, and
```
tests/e2e
```
helpers before running Phase 5 or Phase 6. Prefer a repo-owned setup command that prepares isolated E2E/test state by resetting only the test DB, applying test-targeted migrations, and seeding deterministic verification data, plus a repo-owned server command that starts the app against that isolated state. If the target repo has no named scripts for this pattern, simulate the same pattern with the smallest repo-owned/test-only commands and record the mapping before running them; never replace the pattern with production DB writes, raw DB path overrides, or manual cleanup chains.
Do not compose manual server cleanup, fixed sleep, DB-delete, server-start, and Playwright command chains in Phase 5 or Phase 6. Put pre-server setup such as isolated test DB reset, test migration, test seed, or test database preparation into lifecycle
```
--setup "..."
```
for helper-owned runs. Treat setup plus server startup as reusable for the current verification batch: prefer one helper-owned run with the needed script/spec commands, or rerun setup only after code, migrations, fixtures, DB state, build inputs, or the prior setup output changed. Do not repeatedly delete/recreate the DB or restart the server before each targeted script/spec just because another E2E command is next. If cleanup is needed, do it as a separate recorded recovery step before the helper run, then run the helper alone. If server state, database state, port ownership, or build freshness looks wrong, diagnose through the current lifecycle owner logs/readiness first and rerun through that owner after any code/setup fix. If the helper times out or produces no useful output, treat that as lifecycle/setup evidence, inspect
```
task-workflow/runtime/server.log
```
,
```
task-workflow/runtime/setup-*.log
```
, readiness output, and
```
task-workflow/runtime/run-*.log
```
, then change the setup, server command, ready URL, test command, fixture, or diagnostic before rerunning. If the helper fails once or twice with a diagnosed lifecycle/tooling issue after a corrected invocation, record the helper logs and switch to the smallest fallback that can prove the task: repo Playwright
```
webServer
```
, explicit PID/port cleanup, or manual server management with captured PID/log/readiness/cleanup evidence. Broad process-name cleanup is only a recorded sandbox recovery after PID/port cleanup is impossible.
Do not run
```
playwright install
```
,
```
playwright install chromium
```
, or equivalent browser downloads during task verification. The managed lifecycle helper sets
```
PLAYWRIGHT_BROWSERS_PATH=/ms-playwright
```
when available and fails early if the project Playwright version does not match the sandbox browser cache.

每次对门禁重要的文件写入、补丁、生成文件创建或工件更新后，在依赖它之前执行回读检查。使用
```
sed
```
、
```
rg
```
、
```
ls
```
、
```
git diff
```
或仓库常规检查命令，证明文件存在且包含预期变更。
若写入/编辑工具报告写入无效、文件缺失、补丁失败、输出不完整或结果不确定，停止该工作包，使用支持的编辑方法修复写入，回读后再继续。不得假设失败的写入已完成。
命令必须有边界。不得让长期运行的服务器、监视器或交互式命令在前台作为活动工具调用运行。
生产/实时工作区数据库绝不能用作测试或验证状态。在本技能中，“生产数据库”指
```
.dbs/database.db
```
、任何仓库声明的实时/默认用户数据数据库，或正常应用在隔离测试/E2E配置之外使用的任何数据库路径。对
```
.dbs/database.db
```
或任何生产/实时数据库仅允许执行仓库要求的应用迁移命令，以实现真正的架构变更，且必须在负责该迁移的阶段运行，并记录为迁移证据。这是一个狭窄的迁移执行例外，并非操作生产数据库的许可。若任务创建或变更迁移，必须在迁移存在后、第3阶段晋升前，针对生产/实时默认数据库运行仓库的应用迁移命令；用户会立即使用完成的应用，因此未应用的迁移会使交付的变更不可见或损坏。禁止任何其他生产/实时数据库操作：禁止对
```
.dbs/database.db
```
或任何等效实时数据库路径执行手动查询、数据操作、播种、重置、测试数据、Playwright、E2E、探测、调试、清理、
```
rm
```
、截断、直接SQLite命令、自定义数据修复或有写入风险的数据检查。若命令可能触及生产数据，且工件无法证明它是仓库针对真正架构变更的迁移命令，或隔离测试数据库操作，不得运行该命令。
在第5和第6阶段之外，若临时开发服务器用于API/运行时探测，使用
```
task-workflow/scripts/server-probe.mjs
```
。它负责PID捕获、就绪检查、有边界的探测命令、运行时日志和仅PID清理。服务器就绪通常需要5-10秒；正常预算为15-20秒，最大启动就绪限制为30秒。仅当PID/端口清理不可能，且工件记录原因时，才进行广泛的进程名称清理，作为明确的沙箱恢复操作。
在第5和第6阶段，需要运行应用的第一个浏览器、Playwright或E2E命令，默认必须通过
```
task-workflow/scripts/playwright-lifecycle.mjs
```
建立生命周期所有权。不得先针对假设存在的服务器运行，然后推断
```
fetch失败
```
、数据过期、重定向或错误的构建输出意味着需要手动服务器管理。
现有仓库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/
```
中，也视为严重失败。用户可能因该数据库被删除或损坏而失去工作。
预期的验证生命周期模式：在运行第5或第6阶段前，从
```
AGENTS.md
```
、
```
package.json
```
、README/文档、Playwright配置和
```
tests/e2e
```
辅助工具中发现仓库所属的设置和服务器命令。优先选择仓库所属的设置命令，该命令仅通过重置测试数据库、应用针对测试的迁移、播种确定性验证数据来准备隔离的E2E/测试状态，再加上仓库所属的服务器命令，针对该隔离状态启动应用。若目标仓库无此模式的命名脚本，使用最小的仓库所属/仅测试命令模拟该模式，并在运行前记录映射；绝不能用生产数据库写入、原始数据库路径覆盖或手动清理链替代该模式。
在第5或第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版本与沙箱浏览器缓存不匹配，会提前失败。

Phase-Owned Command Rules

阶段专属命令规则

Phase 2 completes implementation packets with strict artifact, readback, diff, search, and narrow unblock-command evidence. Defer routine check, lint, build, unit/Vitest, E2E, Playwright, and repo combined check commands such as
```
pnpm run check
```
to their owning later phases unless a concrete compile/type issue blocks the current packet and is recorded before the command.
Phase 3 reviews connected places, closes missed implementation gaps, performs implementation integrity review, then owns the ordered check/build checkpoint: repo check, focused lint when useful, and build when the repo has a separate build. Use targeted diagnostics or narrow fix checks only to prove a specific issue group. When a broad check/build command fails, inspect enough output to identify visible issue groups, fix every locally-fixable group before rerunning that broad command, and record only the groups/fixes/rerun reason. Do not rerun a broad command after each tiny fix when other visible issue groups remain. Do not keep huge command logs unless a temporary log is needed for triage; delete temporary full-output logs after extracting issue groups. Record unit/E2E coverage questions for the owning later phase.
Phase 4 owns unit-test coverage. It decides whether unit, service, component, or integration-style coverage is warranted; then adds, updates, removes, or explicitly skips that coverage. It may remove existing unit tests when they protect non-core, non-complex, obsolete, or convoluted behavior and the artifact explains why removal improves the test suite. Phase 4 does not rerun check, lint, or build when Phase 3 evidence is current.
Later phases reuse Phase 3 build evidence unless code, config, dependency/build inputs, migrations, generated assets, stale output, or incompatible verification tooling invalidates it. Do not rebuild in Phase 4, Phase 5, Phase 6, or Phase 7 only to prepare, reconfirm, or feel safe.
Phase 6 owns E2E coverage. It decides whether E2E coverage is warranted; then adds, updates, removes, or explicitly skips that coverage. It may remove existing E2E tests when they protect non-core, non-complex, obsolete, brittle, or convoluted behavior and the artifact explains why removal improves the test suite.
If unit, E2E, or browser work happens before its owning phase, do not fail the task solely for that timing. Carry the artifact, diff, and command output into the owning phase and make the owning phase's remove/update/add/skip decision current before promotion.

第2阶段完成实现包时，需带有严格的工件、回读、差异、搜索和狭窄的解除阻塞命令证据。将常规检查、代码规范、构建、单元/Vitest、E2E、Playwright和仓库组合检查命令（如
```
pnpm run check
```
）推迟到其所属的后续阶段，除非具体编译/类型问题阻塞当前包，且已在命令前记录。
第3阶段评审关联位置，填补遗漏的实现缺口，执行实现完整性评审，然后负责有序的检查/构建检查点：仓库检查、必要时聚焦代码规范检查，以及仓库有单独构建步骤时的构建。仅使用针对性诊断或狭窄的修复检查来证明特定问题组。当广泛的检查/构建命令失败时，检查足够的输出以识别可见问题组，修复所有可本地修复的组后再重新运行该广泛命令，并仅记录问题组/修复/重新运行原因。当其他可见问题组仍存在时，不得在每次微小修复后重新运行广泛命令。除非临时日志用于分类，否则不得保留庞大的命令日志；提取问题组后删除临时完整输出日志。将单元/E2E覆盖问题记录到其所属的后续阶段。
第4阶段负责单元测试覆盖。它决定是否需要单元、服务、组件或集成式覆盖；然后添加、更新、移除或明确跳过该覆盖。当现有单元测试保护非核心、非复杂、过时或复杂的行为，且工件解释移除可改进测试套件时，可移除现有单元测试。若第3阶段证据为当前状态，第4阶段不得重新运行检查、代码规范或构建。
除非代码、配置、依赖/构建输入、迁移、生成资产、过期输出或不兼容的验证工具使第3阶段构建证据失效，否则后续阶段复用该证据。不得仅为准备、重新确认或确保安全，在第4、5、6或7阶段重新构建。
第6阶段负责E2E覆盖。它决定是否需要E2E覆盖；然后添加、更新、移除或明确跳过该覆盖。当现有E2E测试保护非核心、非复杂、过时、脆弱或复杂的行为，且工件解释移除可改进测试套件时，可移除现有E2E测试。
若单元、E2E或浏览器工作在其所属阶段前执行，不得仅因时间问题判定任务失败。将工件、差异和命令输出带入所属阶段，在晋升前更新所属阶段的移除/更新/添加/跳过决策。

Minimal Test And Rerun Rules

最小测试与重新运行规则

Tests are production code. Extra tests are not harmless evidence; they are maintenance load, false confidence risk, and future workflow drag.

Phase 4 and Phase 6 must treat test work as a pruning and minimal-coverage decision, not as a "more tests is safer" step.

Rule	Required behavior
Existing tests are not grandfathered	If an older agent added unnecessary, obsolete, brittle, convoluted, duplicated, or non-core tests, the owning phase must remove or simplify them when they are connected to the current changed behavior.
New tests are exceptions	Add a new test only after proving the behavior is stable/core and no connected existing test can carry the warranted assertion cleanly.
Passing extra tests is not quality evidence	A large passing count does not improve the gate. The gate values necessary coverage, useful assertions, and removal of bad tests.
Test bulk is a warning	If added tests cause max-lines, fixture churn, helper churn, slow commands, broad reruns, or new maintenance structure, stop and re-evaluate whether the tests should be merged, reduced, updated in place, or removed. Do not solve self-created test bulk by adding more structure unless the artifact proves every test remains necessary.
Every new test needs a burden ledger	For each new unit or E2E test case/file, record the core risk, the connected existing tests inspected, why update/remove/ `N/A` was insufficient, why the assertion is minimal, and what cheaper proof was rejected.

Keep tests minimal. Prefer the fewest tests that protect core behavior or critical workflows. Too many tests for incidental behavior are a codebase problem, not a quality signal.
For E2E, run only new, changed, or directly connected specs that are warranted by the Phase 6 decision. Never run the unfiltered full E2E suite unless the task explicitly asks for full E2E or a concrete written repo instruction names full E2E/all-spec execution for this exact task; a repo having a Playwright suite,
```
webServer
```
, or "run tests" script is not enough. After warranted targeted or connected E2E evidence passes and no related code, test, config, fixture, migration, or build input changed, do not add a full E2E run as final confidence, final signoff, state discovery, or reviewer-satisfaction evidence.
For a single targeted Playwright script or E2E spec, timeout increases are not a retry strategy. Start with the smallest practical timeout:
```
15000
```
-
```
20000
```
ms for Phase 5 launch/page-state/custom-script probes and up to
```
30000
```
ms for first-run Phase 6 targeted E2E where Playwright runner startup adds overhead. If the run fails with any useful error, assertion output, not-found state, console/runtime error, route error, fixture/DB miss, or helper diagnostic, use that evidence to diagnose; do not retry with a larger timeout. A larger timeout is allowed only when the first run ended only because the timer expired with no useful response or explanation, and only after helper logs, readiness, URL, not-found/error state, required DB/fixture records, server runtime logs, browser console, and network/page state prove the app and test are in the correct state to run. Only then may one rerun use
```
60000
```
ms, and never more than
```
120000
```
ms for one targeted script/spec. If a single targeted run needs more than two minutes, stop increasing timeouts; split the verifier or diagnose lifecycle, setup, fixture, page-state, console, network, or test-design failure first.
Do not rerun tests only for confidence. Rerun when quality evidence can change: related implementation changed, the test changed, config/environment changed, previous output was incomplete/stale, or the next run gathers a narrower diagnostic needed to fix a real failure.
Before rerunning an identical failing test command, record what changed since the previous run or what new evidence the rerun will collect. If nothing changed and the prior output is complete, inspect logs, DOM/state, traces, screenshots, or persisted data first, then change the implementation, test, command scope, or diagnostic strategy before running again. A suspected pre-existing or order-dependent failure is not a reason to broaden to a full suite; prove it with the narrow failing spec/test plus logs/state/trace evidence, then fix it if it is in scope or record it as an unrelated defended gap.
Phase 5 and Phase 6 artifacts must record timeout values and any quiet-run/timeout triage before the gate can pass. A first-run targeted Playwright command longer than the Phase 5/Phase 6 budgets, or any longer rerun without recorded timer-only failure plus clean state triage, is a gate failure.
If a command appears hung or idle and the next workflow action is locally available, stop the command, record the evidence in the current phase artifact or gap ledger, and continue with the bounded recovery path.

测试是生产代码。额外测试并非无害证据；它们是维护负担、虚假信心风险和未来工作流阻力。

第4阶段和第6阶段必须将测试工作视为修剪和最小覆盖决策，而非“测试越多越安全”的步骤。

规则	要求行为
现有测试并非默认保留	若旧Agent添加了不必要、过时、脆弱、复杂、重复或非核心的测试，当它们与当前变更行为相关时，所属阶段必须移除或简化它们。
新增测试为例外情况	仅在证明行为稳定/核心，且无相关现有测试可清晰承载必要断言后，才添加新测试。
额外测试通过并非质量证据	大量通过的测试计数不会提升门禁分数。门禁重视必要覆盖、有用断言和移除不良测试。
测试体量过大为警告	若新增测试导致行数超限、测试数据变动、辅助工具变动、命令缓慢、广泛重新运行或新增维护结构，停止并重新评估测试是否应合并、简化、原地更新或移除。除非工件证明每个测试仍必要，否则不得通过添加更多结构来解决自行造成的测试体量问题。
每个新测试需记录负担台账	对每个新单元或E2E测试用例/文件，记录核心风险、检查的相关现有测试、为何更新/移除/ `N/A` 不足、为何断言最小化，以及为何拒绝更廉价的证明方式。

保持测试最小化。优先选择最少的测试来保护核心行为或关键工作流。针对偶然行为的过多测试是代码库问题，而非质量信号。
对于E2E，仅运行第6阶段决策所需的新增、变更或直接相关的规范。除非任务明确要求完整E2E，或具体书面仓库指令要求针对此精确任务执行完整E2E/所有规范，否则绝不要运行未过滤的完整E2E套件；仓库有Playwright套件、
```
webServer
```
或“运行测试”脚本并不足够。当所需的针对性或相关E2E证据通过，且无相关代码、测试、配置、测试数据、迁移或构建输入变更时，不得将完整E2E运行作为最终信心、最终签署、状态发现或评审满意度证据。
对于单个针对性Playwright脚本或E2E规范，增加超时并非重试策略。从最小实用超时开始：第5阶段启动/页面状态/自定义脚本探测为
```
15000
```
-
```
20000
```
毫秒，首次运行第6阶段针对性E2E为最多
```
30000
```
毫秒（因Playwright运行器启动会增加开销）。若运行因任何有用错误、断言输出、未找到状态、控制台/运行时错误、路由错误、测试数据/数据库缺失或辅助工具诊断失败，使用该证据进行诊断；不得用更大超时重试。仅当首次运行仅因计时器到期且无有用响应或解释，且辅助工具日志、就绪状态、URL、未找到/错误状态、所需数据库/测试数据记录、服务器运行时日志、浏览器控制台和网络/页面状态证明应用和测试处于正确运行状态时，才可使用
```
60000
```
毫秒进行一次重新运行，且单个针对性脚本/规范绝不要超过
```
120000
```
毫秒。若单个针对性运行需要超过两分钟，停止增加超时；首先拆分验证器或诊断生命周期、设置、测试数据、页面状态、控制台、网络或测试设计失败。
不得仅为信心重新运行测试。仅当质量证据可能变化时重新运行：相关实现变更、测试变更、配置/环境变更、先前输出不完整/过期，或下次运行收集更狭窄的诊断以修复真实失败。
重新运行相同的失败测试命令前，记录自上次运行以来的变更，或重新运行将收集的新证据。若未发生任何变更且先前输出完整，首先检查日志、DOM/状态、跟踪、截图或持久化数据，然后在重新运行前更改实现、测试、命令范围或诊断策略。怀疑存在预先存在或依赖顺序的失败并非扩展到完整套件的理由；用狭窄的失败规范/测试加日志/状态/跟踪证据证明，若在范围内则修复，否则记录为无关的已防御缺口。
第5阶段和第6阶段工件必须记录超时值，以及门禁通过前的静默运行/超时分类。首次运行针对性Playwright命令超过第5/6阶段预算，或任何更长时间的重新运行未记录仅计时器失败加干净状态分类，均视为门禁失败。
若命令看起来挂起或空闲，且下一个工作流操作可本地执行，停止命令，在当前阶段工件或缺口台账中记录证据，然后继续有边界的恢复路径。

Continuation Rules

持续运行规则

Every phase gate is an internal control point, not a user confirmation checkpoint.
If a phase gate passes, continue directly into the next phase without asking whether to continue.
If a phase gate fails, rework the phase, rerun the gate, and keep looping without asking the user for permission to continue.
The purpose of the gate, redo, verification, and rework loop is to remove the need for user confirmation during execution and let the Agent complete the run autonomously.
A failed phase artifact is a repair ticket, not a stopping point. Do not leave a phase with
```
Decision: Fail
```
,
```
Score: 0/...
```
, pending gate rows, or unresolved locally-fixable warnings and then produce a final response.
If a dependency, launch detail, or local setup issue blocks progress, resolve it with the most direct logical solution that preserves the workflow and continue.
Do not lower the skill's strictness, skip gates, or change direction because of an environment issue that can be solved inside the target repo or sandbox.
Do not stop after any phase to summarize progress and ask whether to continue.
Do not stop after implementation, build, lint, tests, Playwright verification, or E2E work if any later phase is still unpassed and locally available.
Do not assume the user will catch a shortcut. The Agent must prevent the shortcut itself.

</autonomous_run_contract>

每个阶段门禁是内部控制点，而非用户确认检查点。
若阶段门禁通过，直接进入下一阶段，无需询问是否继续。
若阶段门禁失败，重新处理该阶段，重新运行门禁，持续循环，无需请求用户许可继续。
门禁、重做、验证和重新工作循环的目的是消除执行期间的用户确认需求，让Agent自主完成运行。
失败的阶段工件是修复工单，而非终止点。不得在阶段显示“决策：失败”、“分数：0/...”、待处理门禁行或未解决的可本地修复警告时，就产生最终响应。
若依赖项、启动细节或本地设置问题阻塞进展，用最直接的逻辑解决方案解决，同时保留工作流并继续。
不得因可在目标仓库或沙箱内解决的环境问题，降低技能的严格性、跳过门禁或改变方向。
不得在任何阶段后停止以总结进展并询问是否继续。
若任何后续阶段仍未通过且可本地执行，不得在实现、构建、代码规范、测试、Playwright验证或E2E工作后停止。
不得假设用户会发现捷径。Agent必须自行阻止捷径。

</autonomous_run_contract>

Final Response Guard

最终响应防护

Before producing any final response, stopping message, or ending an OpenCode turn with control returned to the user, run this guard against the artifact files:

task-workflow/CURRENT_PHASE.txt

must be

phase-7-final-signoff

```
task-workflow/progress.md
```
must say the current phase is
```
phase-7-final-signoff
```
, the last completed gate is Phase 7, and there is no next local action except final response.
```
task-workflow/progress.md
```
must include current phase pointers, a phase artifact index, and artifact pointers that identify where detailed evidence lives.
```
task-workflow/progress.md
```
must not duplicate full file inventories from phase artifacts; it may list only high-signal active files needed for immediate resume.
```
task-workflow/progress.md
```
must list the repo-relative instruction/context files to re-read after compaction, including
```
AGENTS.md
```
,
```
.tasks/task.md
```
,
```
.tasks/domain.md
```
, relevant task attachments/supporting files from
```
.tasks/files/
```
, and only the relevant available skill files from
```
.agents/skills/
```
selected in Phase 1.
Every required phase artifact must have
```
Decision: Pass
```
.
Every required score must meet its threshold.
Every gate row must contain concrete evidence instead of
```
Pending
```
or template defaults.
```
task-workflow/open-gaps.md
```
must have no critical open gaps, no stale open gaps owned by passed phases, and no placeholder rows.
Phase 5, Phase 6, and Phase 7 must record fixed-wait review evidence showing the inspected verification files contain no fixed waits.
Phase 5 and Phase 7 must record screenshot existence proof for every screenshot path cited in Phase 5.
When Phase 4 requires a unit command or Phase 6 requires an E2E command, that phase and Phase 7 must record the exact command output or a repo-local log file containing the exact output plus the final pass/fail lines. When no unit/E2E test is warranted, the owning phase and Phase 7 must record the
```
N/A
```
coverage decision. When tests are removed, the owning phase and Phase 7 must record the removal reason and diff/readback evidence.
Phase 5, Phase 6, and Phase 7 must record timeout values and timeout/quiet-run triage evidence for every timed-out, quiet, or longer-rerun Playwright/E2E command.
Phase 3 and Phase 7 must verify changed app/server source contains no lasting
```
console.*
```
. Temporary
```
console.*
```
is allowed only during Phase 5 interactive testing when it directly helps debug browser/runtime behavior by reading console output, and it must be removed before the Phase 5 rerun, Phase 3 re-pass, or Phase 7 signoff.
Phase 7 final quality scorecard must be at least
```
8/10
```
in every category.
Phase 7 must record an artifact integrity review that re-opens every phase artifact and verifies the artifact exists, its decision is
```
Pass
```
, its score meets threshold, required evidence rows are complete, and it does not contradict
```
CURRENT_PHASE.txt
```
,
```
progress.md
```
, or
```
open-gaps.md
```
.
The MITB completed command from
```
.tasks/task.md
```
or the prompt must run only after all Phase 7 audit checks pass. Treat it as the final external task action: plan and run all checks, tests, builds, server probes, and verification commands before task completion. If any Phase 7 check fails before completion, the agent must loop back to the earliest failing phase and must not call task completion.

If any item fails and the problem can be solved locally, continue the workflow from the earliest failing phase. Do not answer as if the task is complete. If an actual external blocker prevents completion, record the blocker in the current phase artifact and

open-gaps.md

, including commands run, files inspected, why local recovery cannot solve it, and the smallest next action.

在产生任何最终响应、停止消息或结束OpenCode回合并将控制权返回给用户前，针对工件文件运行以下防护检查：

task-workflow/CURRENT_PHASE.txt

必须为

phase-7-final-signoff

。

```
task-workflow/progress.md
```
必须显示当前阶段为
```
phase-7-final-signoff
```
，最后完成的门禁为第7阶段，且除最终响应外无下一个本地操作。
```
task-workflow/progress.md
```
必须包含当前阶段指针、阶段工件索引和工件指针，指明详细证据的位置。
```
task-workflow/progress.md
```
不得复制阶段工件中的完整文件清单；仅可列出恢复运行所需的高信号活跃文件。
```
task-workflow/progress.md
```
必须列出压缩后需重新阅读的仓库相对指令/上下文文件，包括
```
AGENTS.md
```
、
```
.tasks/task.md
```
、
```
.tasks/domain.md
```
、
```
.tasks/files/
```
中的相关任务附件/支持文件，以及第1阶段选择的
```
.agents/skills/
```
中仅相关的可用技能文件。
所有所需阶段工件必须显示“决策：通过”。
所有所需分数必须达到阈值。
每个门禁行必须包含具体证据，而非“待处理”或模板默认值。
```
task-workflow/open-gaps.md
```
必须无关键开放缺口、无已通过阶段所属的过期开放缺口，且无占位符行。
第5、6、7阶段必须记录固定等待评审证据，显示检查的验证文件无固定等待。
第5和第7阶段必须记录第5阶段引用的每个截图路径的存在证明。
当第4阶段需要单元命令或第6阶段需要E2E命令时，该阶段和第7阶段必须记录精确的命令输出，或包含精确输出加最终通过/失败行的仓库本地日志文件。当无需单元/E2E测试时，所属阶段和第7阶段必须记录
```
N/A
```
覆盖决策。当测试被移除时，所属阶段和第7阶段必须记录移除原因和差异/回读证据。
第5、6、7阶段必须记录每个超时、静默或更长时间重新运行的Playwright/E2E命令的超时值和超时/静默运行分类证据。
第3和第7阶段必须验证变更的应用/服务器源代码无持久化
```
console.*
```
。仅在第5阶段交互式测试期间，临时
```
console.*
```
可直接帮助调试浏览器/运行时行为（通过读取控制台输出），且必须在第5阶段重新运行、第3阶段重新通过或第7阶段签署前移除。
第7阶段最终质量评分卡每个类别必须至少为
```
8/10
```
。
第7阶段必须记录工件完整性评审，重新打开每个阶段工件，验证工件存在、决策为“通过”、分数达到阈值、所需证据行完整，且与
```
CURRENT_PHASE.txt
```
、
```
progress.md
```
或
```
open-gaps.md
```
无矛盾。
仅在所有第7阶段审计检查通过后，才可运行
```
.tasks/task.md
```
或提示中的MITB完成命令。将其视为最终外部任务操作：在任务完成前规划并运行所有检查、测试、构建、服务器探测和验证命令。若完成前任何第7阶段检查失败，Agent必须返回最早失败的阶段，不得调用任务完成。

若任何项失败且问题可本地解决，从最早失败的阶段继续工作流。不得将任务视为已完成而回复。若实际外部阻塞阻止完成，在当前阶段工件和

open-gaps.md

中记录阻塞，包括运行的命令、检查的文件、本地恢复无法解决的原因，以及最小的下一个操作。

OpenCode Turn Continuity Guard

OpenCode回合连续性防护

When running inside OpenCode or another tool-driven coding session, the Agent must not end its assistant turn just because a command finished, a check passed, lint started, files were edited, or a phase artifact is temporarily failing.

After every tool result, before returning control to the user, check:

Is
```
CURRENT_PHASE.txt
```
earlier than
```
phase-7-final-signoff
```
?
Does any required phase artifact still say
```
Decision: Fail
```
?
Does the current phase gate still contain
```
Pending
```
,
```
0/...
```
, or missing evidence?
Is the next required workflow action locally available?

If the answer to any of the first three is yes and the next action is locally available, immediately continue with that next action in the same run. Do not stop at a narrative checkpoint such as "now run lint", "check passes", "next I will update the artifact", or "remaining work is...".

The only valid stopping states are:

Phase 7 passed and the final response guard passed.
A real external blocker is fully recorded in the current artifact and
```
open-gaps.md
```
.

If the session is long, keep the phase artifacts current and continue dispatching the next tool/action. Do not rely on the user to type "continue" to finish an unblocked phase.

在OpenCode或其他工具驱动的编码会话中运行时，Agent不得仅因命令完成、检查通过、代码规范开始、文件编辑或阶段工件暂时失败，就结束助手回合。

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

```
CURRENT_PHASE.txt
```
是否早于
```
phase-7-final-signoff
```
？
是否有任何所需阶段工件仍显示“决策：失败”？
当前阶段门禁是否仍包含“待处理”、“0/...”或缺失证据？
下一个所需工作流操作是否可本地执行？

若前三个问题任何一个答案为是，且下一个操作可本地执行，立即在同一运行中继续该下一个操作。不得在“现在运行代码规范”、“检查通过”、“接下来我将更新工件”或“剩余工作为...”等叙述检查点停止。

唯一有效的终止状态为：

第7阶段通过且最终响应防护通过。
真实外部阻塞已完整记录在当前工件和
```
open-gaps.md
```
中。

若会话较长，保持阶段工件更新并继续调度下一个工具/操作。不得依赖用户输入“继续”来完成未阻塞的阶段。

Critical Output Invariant

关键输出不变量

These are hard constraints:

The target app must be a real interactive app, not a static mockup.
The implementation must be authored in the target repo as real routes, layouts, components, state, styling, backend contracts, services, queries, migrations, and tests when required by Phase 4 or Phase 6 coverage decisions.
Primary pages or views must be implemented as real router routes or repo-native route modules, not as an in-memory page-state switch inside one large component.
Visible controls required or implied by the task must become real target controls with matching states and persisted behavior when persistence is required.
Backend/data work must follow the repo's existing service, contract, query, and persistence boundaries.
Frontend runtime code must not import server-only runtime modules.
Reusable UI styling belongs in shared primitives, component-local styling, or existing design tokens, not fake global one-off component classes.
Phase 3 check/lint evidence, Phase 4 unit-test work, Phase 5 interactive Playwright verification, and Phase 6 E2E work are separate gates. None is a substitute for another.
The Agent must review the app part by part, route by route, state by state, and flow by flow.
If a critical visible action, route, data mutation, or verification path remains fake, broken, or unreviewed, the run has not passed.
Existing tests must not be deleted merely to make the new task pass. If obsolete tests are removed, replace their useful coverage or document why the old coverage no longer applies.
Type assertions, broad casts, and warning suppression are not acceptable substitutes for correct contracts and narrowed types.
Final signoff must score at least
```
8/10
```
in each quality category: functional result, skill compliance/artifact integrity, code quality/maintainability, test quality, and overall result.

以下为硬性约束：

目标应用必须是真实的交互式应用，而非静态模型。
实现必须在目标仓库中以真实路由、布局、组件、状态、样式、后端契约、服务、查询、迁移和测试的形式编写（当第4或第6阶段覆盖决策要求时）。
主页面或视图必须实现为真实路由器路由或仓库原生路由模块，而非单个大型组件内的内存页面状态切换。
任务要求或隐含的可见控件必须成为真实目标控件，当需要持久化时具备匹配状态和持久化行为。
后端/数据工作必须遵循仓库现有的服务、契约、查询和持久化边界。
前端运行时代码不得导入仅服务器端的运行时模块。
可复用UI样式属于共享原语、组件本地样式或现有设计令牌，而非虚假的全局一次性组件类。
第3阶段检查/代码规范证据、第4阶段单元测试工作、第5阶段交互式Playwright验证和第6阶段E2E工作是独立门禁，彼此不可替代。
Agent必须逐个部分、逐个路由、逐个状态、逐个流程地评审应用。
若关键可见操作、路由、数据变更或验证路径仍为虚假、损坏或未评审，运行未通过。
不得仅为使新任务通过而删除现有测试。若移除过时测试，需替换其有用覆盖或记录旧覆盖不再适用的原因。
类型断言、广泛类型转换和警告抑制不能替代正确的契约和窄化类型。
最终签署每个质量类别得分必须至少为
```
8/10
```
：功能结果、技能合规性/工件完整性、代码质量/可维护性、测试质量和整体结果。

Reference Loading Rules

参考加载规则

<reference_loading_rules>

Do not load every reference file by default.

<reference_loading_rules>

默认不得加载所有参考文件。

Compaction And Resume Reload Rule

压缩与恢复重新加载规则

After compaction, resume, retry, reconnect, or a new coding session, use

task-workflow/progress.md

and

task-workflow/CURRENT_PHASE.txt

to identify the current status, then re-read:

this main
```
SKILL.md
```
```
task-workflow/progress.md
```
```
task-workflow/CURRENT_PHASE.txt
```
the current phase artifact
```
task-workflow/open-gaps.md
```
the required reference file or files for the current phase from the Phase Reference Map
the repo-relative instruction/context files listed in
```
progress.md
```

Do not rely on conversation memory after compaction.

progress.md

and

CURRENT_PHASE.txt

identify where the run is, but they do not replace the main skill, current phase reference, current phase artifact, or gap ledger. The run may continue only after those files have been reloaded.

压缩、恢复、重试、重新连接或开启新编码会话后，使用

task-workflow/progress.md

和

task-workflow/CURRENT_PHASE.txt

识别当前状态，然后重新阅读：

本主
```
SKILL.md
```
```
task-workflow/progress.md
```
```
task-workflow/CURRENT_PHASE.txt
```
当前阶段工件
```
task-workflow/open-gaps.md
```
阶段参考映射中当前阶段所需的参考文件
```
progress.md
```
中列出的仓库相对指令/上下文文件

压缩后不得依赖对话记忆。

progress.md

和

CURRENT_PHASE.txt

指明运行位置，但不能替代主技能文档、当前阶段参考文件、当前阶段工件或缺口台账。仅在重新加载这些文件后，才可继续运行。

Phase Start Reference Rule

阶段启动参考规则

Every time a phase starts, including immediately after a phase promotion, read the required reference file or files for that new phase before doing phase work.

CURRENT_PHASE.txt

changes, the next local action is to load the reference file or files named for the new marker in the Phase Reference Map. Phase work before that read is invalid.

On a fresh run:

Read this
```
SKILL.md
```
.
Start Phase 0.

Load only

references/phase-0-1-startup-research.md

After compaction, resume, retry, reconnect, or new coding session:

Re-read this
```
SKILL.md
```
.
Read
```
task-workflow/progress.md
```
.
Read
```
task-workflow/CURRENT_PHASE.txt
```
.
Read the current phase artifact and
```
task-workflow/open-gaps.md
```
.
Re-read the instruction/context files listed in
```
progress.md
```
, including
```
AGENTS.md
```
,
```
.tasks/task.md
```
,
```
.tasks/domain.md
```
, the relevant attachments/supporting files recorded from
```
.tasks/files/
```
, and only the selected relevant skill files from
```
.agents/skills/
```
.
If
```
progress.md
```
,
```
CURRENT_PHASE.txt
```
, and the phase artifacts disagree, continue from the earliest failing phase artifact.
Load only the reference file that owns the current phase.
Load
```
references/playwright-interactive.md
```
only when the current phase reference requires interactive Playwright work.

Phase reference map:

Current phase marker	Reference to load
missing `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` and `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`

The phase references are grouped by connected workstream, not one file per phase. This matches the reference skill pattern:

SKILL.md

holds the strict global protocol and the reference files hold detailed process for the current workstream.

</reference_loading_rules>

每次阶段启动时（包括阶段晋升后立即启动），在进行阶段工作前，阅读新阶段所需的参考文件。

若

CURRENT_PHASE.txt

变更，下一个本地操作是加载阶段参考映射中新标记对应的参考文件。阅读前的阶段工作无效。

在全新运行中：

阅读本
```
SKILL.md
```
。
启动第0阶段。

仅加载

references/phase-0-1-startup-research.md

。

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

重新阅读本
```
SKILL.md
```
。
阅读
```
task-workflow/progress.md
```
。
阅读
```
task-workflow/CURRENT_PHASE.txt
```
。
阅读当前阶段工件和
```
task-workflow/open-gaps.md
```
。
重新阅读
```
progress.md
```
中列出的指令/上下文文件，包括
```
AGENTS.md
```
、
```
.tasks/task.md
```
、
```
.tasks/domain.md
```
、
```
.tasks/files/
```
中记录的相关附件/支持文件，以及
```
.agents/skills/
```
中仅所选的相关技能文件。
若
```
progress.md
```
、
```
CURRENT_PHASE.txt
```
和阶段工件存在不一致，从最早失败的阶段工件继续。
仅加载当前阶段所属的参考文件。
仅当当前阶段参考要求交互式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>

Validation Mode

验证模式

Use this when improving or testing the skill itself.

Use a throwaway target repo copy.
Preserve all workflow artifacts.
Judge repeatability across fresh runs.
If the same failure repeats, improve the reusable skill before running again.

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

使用一次性目标仓库副本。
保留所有工作流工件。
判断全新运行的可重复性。
若相同失败重复出现，先改进可复用技能再重新运行。

Delivery Mode

交付模式

Use this when the user wants the real target app or task completed.

Work inside the provided target repo.
Treat the task file as the source of truth.
Do not sign off until every gate in this file and the phase references has passed in writing.

</operating_modes>

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

在提供的目标仓库内工作。
将任务文件视为事实来源。
仅当本文件和阶段参考中的每个门禁均书面通过后，才可签署确认。

</operating_modes>

Required Artifacts

所需工件

These are mandatory:

```
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/
```

The templates in

assets/templates/

are enforcement artifacts. Copy their structure directly. If a required table is replaced by prose or stripped down until rows are no longer auditable, the run fails.

以下为强制性要求：

```
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/

中的模板为强制执行工件。直接复制其结构。若所需表格被 prose 替换，或精简到行不再可审计，运行失败。

Multi-Phase Protocol

多阶段协议

<multi_phase_protocol>

Follow the phases in order:

<multi_phase_protocol>

按顺序遵循以下阶段：

Phase 0: Artifact Reset And Scaffolding

第0阶段：工件重置与脚手架搭建

Delete the previous task's

task-workflow/

artifacts, recreate the required artifact files from templates, and prove no implementation files were edited.

Detailed process:

references/phase-0-1-startup-research.md

删除先前任务的

task-workflow/

工件，从模板重新创建所需工件文件，并证明未编辑实现文件。

详细流程：

references/phase-0-1-startup-research.md

。

Phase 1: Task Intake And Codebase Research

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

Read the task, root

AGENTS.md

.tasks/domain.md

, every task attachment/supporting file in

.tasks/files/

, only relevant available skill files from

.agents/skills/

, relevant docs, and codebase. Treat

AGENTS.md

as binding development instructions; extract its task-relevant rules before planning. These are reference inputs: read and cite them, but do not edit them. Record task understanding, development rules, task files read or inspected, selected skills, affected files, patterns to reuse, risks, and an ordered implementation plan.

Detailed process:

references/phase-0-1-startup-research.md

阅读任务、根目录

AGENTS.md

、

.tasks/domain.md

、

.tasks/files/

中的每个任务附件/支持文件、

.agents/skills/

中仅相关的可用技能文件、相关文档和代码库。将

AGENTS.md

视为绑定开发指令；在规划前提取其与任务相关的规则。这些为参考输入：阅读并引用，但不得编辑。记录任务理解、开发规则、已阅读或检查的任务文件、所选技能、受影响文件、可复用模式、风险和有序实现计划。

详细流程：

references/phase-0-1-startup-research.md

。

Phase 2: Primary Execution

第2阶段：主要执行

Execute the researched plan in order, keep changes scoped, and record implementation evidence.

Detailed process:

references/phase-2-4-execution-integrity.md

按顺序执行调研后的计划，保持变更范围明确，并记录实现证据。

详细流程：

references/phase-2-4-execution-integrity.md

。

Phase 3: Second Execution, Integrity, And Check/Lint Validation

第3阶段：二次执行、完整性检查与检查/代码规范验证

Review the implementation as a continuation pass, close missing or weak work, propagate consistency to associated UI/API/data surfaces, run implementation integrity review, and complete the ordered check/build checkpoint. Do not write or run unit/Vitest or E2E tests in Phase 3.

Detailed process:

references/phase-2-4-execution-integrity.md

作为延续评审实现，填补缺失或薄弱工作，将一致性传播到关联UI/API/数据表面，执行实现完整性评审，并完成有序的检查/构建检查点。第3阶段不得编写或运行单元/Vitest或E2E测试。

详细流程：

references/phase-2-4-execution-integrity.md

。

Phase 4: Unit Test Coverage Decision And Verification

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

Decide whether unit, service, component, or integration-style tests are needed. Add, update, remove, or explicitly skip that coverage, then run only the warranted unit-level commands. Remove tests that are unnecessary, obsolete, convoluted, or protecting non-core/non-complex behavior.

Detailed process:

references/phase-2-4-execution-integrity.md

决定是否需要单元、服务、组件或集成式测试。添加、更新、移除或明确跳过该覆盖，然后仅运行所需的单元级命令。移除不必要、过时、复杂或保护非核心/非复杂行为的测试。

详细流程：

references/phase-2-4-execution-integrity.md

。

Phase 5: Interactive Playwright Verification

第5阶段：交互式Playwright验证

Use standalone interactive Playwright scripts in two stages. Stage 1 proves the changed behavior works through real user interaction. Stage 2 verifies UI quality: no broken, cramped, overlapping, clipped, ill-placed, or non-responsive UI on the affected surfaces. Treat responsive design as a first-class Phase 5 guarantee, equal to proving the task's functional changes work. Some whitespace is fine, but standard desktop viewports such as

1920x1080

must not look broken, clipped, overlapped, unusable, or excessively sparse. Large desktop viewports such as

2560x1440

may have some extra whitespace, but not broad empty regions that make the UI feel unfinished. Very large 4K/ultrawide whitespace is acceptable when the layout is intentionally constrained and still coherent.

The Phase 4/Phase 6 test-minimality rules do not shrink Phase 5. Phase 5 is the main user-facing verification phase and may take the time needed to cover changed flows, relevant bad cases, surrounding UI, responsive breakpoints, screenshots, and visual correctness. Use multiple focused Playwright scripts, probes, viewport passes, or reruns when needed to prove the affected user experience is correct; keep them scoped to the changed and adjacent surfaces, but do not reduce Phase 5 to a shallow smoke check.

Detailed process:

references/phase-5-7-verification-signoff.md

and

references/playwright-interactive.md

分两个阶段使用独立交互式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

。

Phase 6: E2E Coverage Decision And Verification

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

Make the E2E coverage decision. Review existing E2E coverage first, update it when a warranted core flow already belongs there, add new E2E tests only for critical or complex workflows that cannot be cleanly covered by existing tests, remove unwanted E2E tests that protect non-core/non-complex or convoluted flows, and avoid E2E for small, visual-only, or incidental UI changes.

Detailed process:

references/phase-5-7-verification-signoff.md

做出E2E覆盖决策。首先评审现有E2E覆盖，当所需核心流程已在其中时更新它；仅为无法通过现有测试清晰覆盖的关键或复杂工作流添加新E2E测试；移除保护非核心/非复杂或复杂流程的不必要E2E测试；避免为小型、仅视觉或偶然UI变更添加E2E测试。

详细流程：

references/phase-5-7-verification-signoff.md

。

Phase 7: Final Audit And Signoff

第7阶段：最终审计与签署

Re-read every artifact, confirm all previous gates still pass after the last edit, review the final diff, run the required MITB completed command only after all Phase 7 audit checks pass, and sign off only if the artifact trail proves completion.

Phase 7 is an evidence validator for missed work, not a validation rerun phase. If a required check, build, test, Playwright run, E2E run, or other phase-owned command was already completed correctly in its owning phase and the evidence is current, Phase 7 must only verify that evidence. Rerun a command only when the owning phase missed the required command, the recorded evidence is missing/incomplete/stale, or later changes invalidated it; otherwise never rerun checks, builds, tests, Playwright, or E2E in Phase 7.

Detailed process:

references/phase-5-7-verification-signoff.md

The phase references are not optional expansion material. They are the detailed execution instructions for the current workstream.

</multi_phase_protocol>

重新阅读每个工件，确认最后一次编辑后所有先前门禁仍通过，评审最终差异，仅在所有第7阶段审计检查通过后运行所需的MITB完成命令，且仅当工件轨迹证明完成时签署确认。

第7阶段是遗漏工作的证据验证器，而非验证重新运行阶段。若所需检查、构建、测试、Playwright运行、E2E运行或其他阶段专属命令已在其所属阶段正确完成，且证据为当前状态，第7阶段仅需验证该证据。仅当所属阶段遗漏所需命令、记录的证据缺失/不完整/过期，或后续变更使其失效时，才重新运行命令；否则第7阶段绝不要重新运行检查、构建、测试、Playwright或E2E。

详细流程：

references/phase-5-7-verification-signoff.md

。

阶段参考文件并非可选扩展材料，而是当前工作流的详细执行指令。

</multi_phase_protocol>

Disallowed Shortcuts And Automatic Fails

禁止捷径与自动失败

<automatic_fails>

These automatically fail the run:

<automatic_fails>

以下情况自动判定运行失败：

Phase Boundary And Artifact Fails

阶段边界与工件失败

editing app/source files before Phase 1 passes
editing app/source files before Phase 0 artifacts exist

editing implementation/source files while

task-workflow/CURRENT_PHASE.txt

still says

phase-0-artifact-reset

phase-1-task-research

passing Phase 2 while
```
task-workflow/phase-2-execution.md
```
does not record that the marker was set to
```
phase-2-execution
```
before source edits
skipping artifact reset
failing to copy the artifact templates before implementation work
failing to create, read after compaction, or keep
```
task-workflow/progress.md
```
current enough to resume the run
after compaction, retry, reconnect, or a new coding session, continuing work before using
```
task-workflow/progress.md
```
and
```
task-workflow/CURRENT_PHASE.txt
```
to identify status, then re-reading
```
SKILL.md
```
, the current phase artifact,
```
open-gaps.md
```
, and the required current phase reference file or files
after a phase marker changes, starting work in the new phase before reading the required reference file or files for that phase
failing to record and re-read the selected repo-relative instruction/context files in
```
task-workflow/progress.md
```
, including
```
AGENTS.md
```
,
```
.tasks/task.md
```
,
```
.tasks/domain.md
```
, relevant task attachments/supporting files from
```
.tasks/files/
```
, and relevant available skill files from
```
.agents/skills/
```
reading
```
AGENTS.md
```
only as context instead of extracting and following the task-relevant development rules it defines
editing
```
.tasks/task.md
```
,
```
.tasks/domain.md
```
,
```
.tasks/files/
```
, selected skill files under
```
.agents/skills/
```
, or
```
AGENTS.md
```
without the user/task explicitly requesting an edit to that exact reference file
leaving the
```
task-workflow/progress.md
```
Current Phase Pointers, Phase Artifact Index, or Artifact Pointers stale, missing, or contradicting phase artifacts
using
```
task-workflow/progress.md
```
as a duplicate file inventory instead of pointing to the owning phase artifacts for details
omitting required semantic evidence from a phase artifact while claiming that phase passed
advancing
```
task-workflow/CURRENT_PHASE.txt
```
while the current or any previous phase artifact still says
```
Decision: Fail
```
advancing
```
task-workflow/CURRENT_PHASE.txt
```
while the current or any previous phase artifact still has placeholder
```
Pending
```
gate evidence
leaving artifact templates mostly blank while claiming success
passing Phase 5 while any screenshot path cited in the artifact is missing or not verified with existence proof
passing Phase 6 while required E2E runs are only described and the exact command output is not recorded in the artifact or in a cited repo-local log file
running Phase 5 or Phase 6 Playwright/E2E commands without the correct lifecycle owner recorded: helper by default, repo Playwright
```
webServer
```
or manual fallback only with a recorded reason/diagnostic made before the command
deleting, resetting, reseeding, truncating, directly modifying, or using the production/live workspace database as test/verification state; this includes
```
.dbs/database.db
```
, repo default user-data DB paths, and any equivalent live DB path
running any production/live DB action other than the repo's required app migration command for a real schema change; prohibited actions include manual queries, data manipulation, seed, reset, fixture, Playwright, E2E, debug, cleanup, direct SQLite, custom data repair, delete, or truncate against
```
.dbs/database.db
```
or any equivalent live DB path
running a production database migration except as the app's required migration for a real schema change, in the owning phase, with explicit migration evidence
passing Phase 3 after creating or changing a migration without applying it through the repo's app migration command against the production/live default DB and recording the target, command, reason, and output

第1阶段通过前编辑应用/源文件
第0阶段工件存在前编辑应用/源文件

task-workflow/CURRENT_PHASE.txt

仍显示

phase-0-artifact-reset

或

phase-1-task-research

时编辑实现/源文件

```
task-workflow/phase-2-execution.md
```
未记录源编辑前标记已设置为
```
phase-2-execution
```
时通过第2阶段
跳过工件重置
实现工作前未复制工件模板
未创建、压缩后未阅读，或未保持
```
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
```
中的当前阶段指针、阶段工件索引或工件指针过期、缺失或与阶段工件矛盾
将
```
task-workflow/progress.md
```
用作重复文件清单，而非指向所属阶段工件获取详细信息
阶段工件遗漏所需语义证据却声称该阶段通过
当前或任何前期阶段工件仍显示“决策：失败”时更新
```
task-workflow/CURRENT_PHASE.txt
```
当前或任何前期阶段工件仍有占位符“待处理”门禁证据时更新
```
task-workflow/CURRENT_PHASE.txt
```
工件模板大部分空白却声称成功
第5阶段引用的任何截图路径缺失或未验证存在证明时通过第5阶段
所需E2E运行仅描述，且精确命令输出未记录在工件或引用的仓库本地日志文件中时通过第6阶段
未记录正确生命周期所有者就运行第5或第6阶段Playwright/E2E命令：默认使用辅助工具，仅在有记录的原因/诊断后才使用仓库Playwright
```
webServer
```
或手动回退
删除、重置、重新播种、截断、直接修改或使用生产/实时工作区数据库作为测试/验证状态；包括
```
.dbs/database.db
```
、仓库默认用户数据DB路径和任何等效实时DB路径
执行仓库要求的应用迁移命令（针对真正架构变更）之外的任何生产/实时DB操作；禁止的操作包括对
```
.dbs/database.db
```
或任何等效实时DB路径执行手动查询、数据操作、播种、重置、测试数据、Playwright、E2E、调试、清理、直接SQLite命令、自定义数据修复、删除或截断
除作为应用针对真正架构变更的所需迁移、在所属阶段运行并带有明确迁移证据外，运行生产数据库迁移
创建或变更迁移后，未通过仓库的应用迁移命令针对生产/实时默认数据库应用，且未记录目标、命令、原因和输出时通过第3阶段

Test Hygiene And Coverage Fails

测试卫生与覆盖失败

adding or requiring unit tests for small fixes, minor UI adjustments, copy changes, color/style changes, spacing/layout tuning, or simple button wiring without a concrete core-behavior or risk reason
adding unit tests for trivial component branches, incidental button clicks, visual-only changes, or one-off UI behavior instead of reserving unit tests for core stable behavior
keeping unnecessary, obsolete, convoluted, or non-core/non-complex unit tests after Phase 4 identifies them as removable
adding unit tests without a per-test necessity ledger proving existing tests could not be updated, the behavior is stable/core, and every new assertion is minimal
preserving old agent-created unit tests as "already there" when connected evidence shows they are unnecessary, duplicated, brittle, convoluted, or non-core/non-complex
adding enough unit tests to require test-file splitting, helper churn, fixture churn, or broad reruns without first reducing or removing unnecessary test coverage and recording why the remaining bulk is necessary
adding a new E2E test for behavior that is not a critical/core workflow, not a complex flow, or can be cleanly covered by updating existing E2E coverage
keeping unnecessary, obsolete, brittle, convoluted, or non-core/non-complex E2E tests after Phase 6 identifies them as removable
adding E2E tests without a per-test necessity ledger proving existing E2E could not be updated, the workflow is critical/core or complex enough for E2E, and every new assertion is minimal
preserving old agent-created E2E tests as "already there" when connected evidence shows they are unnecessary, duplicated, brittle, convoluted, or non-core/non-complex
starting with a broad/full unit or Vitest suite in Phase 4 before the warranted targeted/connected unit-level tests, when any are warranted, have passed
running the full unit/Vitest suite more than once without a concrete artifact reason from target repo instructions, changed global/shared infrastructure, or incomplete/stale output
running broad/full unit or Vitest without Phase 4 artifact evidence that warranted targeted/connected tests already passed and this is the one final sanity check, or that the task/repo/global change explicitly requires the broader scope
running routine check, lint, or build after every small Phase 2 edit instead of preserving packet evidence and using Phase 3 as the ordered check/build checkpoint
running repo combined check commands such as
```
pnpm run check
```
in Phase 2 without a concrete compile/type blocker recorded before the command
rerunning check, lint, or build before all visible locally-fixable issue groups from the prior output are fixed; truncated
```
tail
```
/
```
head
```
output alone is not enough if it hides issue groups, and temporary full-output logs must be deleted after extraction
rerunning build in Phase 4, Phase 5, Phase 6, or Phase 7 when Phase 3 build evidence is current and no invalidating change is recorded

无具体核心行为或风险原因，为小修复、次要UI调整、文案变更、颜色/样式变更、间距/布局调整或简单按钮连接添加或要求单元测试
为琐碎组件分支、偶然按钮点击、仅视觉变更或一次性UI行为添加单元测试，而非将单元测试保留给核心稳定行为
第4阶段识别出不必要、过时、复杂或非核心/非复杂单元测试后仍保留它们
添加单元测试时无每个测试的必要性台账，证明现有测试无法更新、行为稳定/核心且每个新断言最小化
当相关证据显示旧Agent创建的单元测试不必要、重复、脆弱、复杂或非核心/非复杂时，仍将其视为“已存在”保留
添加足够多单元测试导致测试文件拆分、辅助工具变动、测试数据变动或广泛重新运行，却未先减少或移除不必要测试覆盖并记录剩余体量必要的原因
为非关键/核心工作流、非复杂流程或可通过更新现有E2E覆盖清晰覆盖的行为添加新E2E测试
第6阶段识别出不必要、过时、脆弱、复杂或非核心/非复杂E2E测试后仍保留它们
添加E2E测试时无每个测试的必要性台账，证明现有E2E无法更新、工作流足够关键/核心或复杂到需要E2E，且每个新断言最小化
当相关证据显示旧Agent创建的E2E测试不必要、重复、脆弱、复杂或非核心/非复杂时，仍将其视为“已存在”保留
第4阶段在所需的针对性/相关单元级测试（若有）通过前，就开始运行广泛/完整单元或Vitest套件
无目标仓库指令、变更的全局/共享基础设施或不完整/过期输出的具体工件原因，多次运行完整单元/Vitest套件
无第4阶段工件证据证明所需针对性/相关测试已通过且这是最后一次 sanity 检查，或任务/仓库/全局变更明确要求更广泛范围，就运行广泛/完整单元或Vitest
每次第2阶段微小编辑后运行常规检查、代码规范或构建，而非保留包证据并使用第3阶段作为有序检查/构建检查点
无记录的具体编译/类型阻塞，就在第2阶段运行仓库组合检查命令（如
```
pnpm run check
```
）
未修复先前输出中所有可见的可本地修复问题组就重新运行检查、代码规范或构建；仅截断
```
tail
```
/
```
head
```
输出不足以隐藏问题组，提取后必须删除临时完整输出日志
第3阶段构建证据为当前状态且无记录的失效变更时，在第4、5、6或7阶段重新运行构建

Playwright And E2E Command Fails

Playwright与E2E命令失败

running native
```
pnpm exec playwright test ...
```
in Phase 6 instead of running it through
```
task-workflow/scripts/playwright-lifecycle.mjs --run ...
```
, unless repo
```
webServer
```
ownership is required and recorded before the command
running the unfiltered full Playwright/E2E suite when the task did not explicitly ask for full E2E and no concrete written repo instruction names full E2E/all-spec execution for this exact task
running
```
rm
```
,
```
seed
```
,
```
migrate
```
,
```
sqlite3
```
,
```
tsx server/db/seed
```
, fixture setup, or any DB cleanup command from Phase 5/6 unless the artifact first proves the command targets an isolated repo-owned test/E2E database and not production/live user data
starting a first-run targeted Phase 5 Playwright script above
```
20000
```
ms or a first-run targeted Phase 6 E2E above
```
30000
```
ms without a task-specific artifact reason
increasing a Playwright/E2E timeout after any useful failure evidence, or increasing it after a timer-only/no-output failure without recorded helper-log/readiness/URL/DB-fixture/server-log/browser-console/network/page-state triage proving the app and test are valid to rerun
rerunning tests only for confidence, or blindly rerunning the same failing test command without recording a material implementation, test, config, environment, output-staleness, or diagnostic reason
running
```
playwright install
```
,
```
playwright install chromium
```
, or equivalent browser downloads during task verification instead of using the sandbox browser cache or recording the helper's browser-preflight mismatch

第6阶段运行原生

pnpm exec playwright test ...

而非通过

task-workflow/scripts/playwright-lifecycle.mjs --run ...

运行，除非需要仓库

webServer

所有权且已在命令前记录

任务未明确要求完整E2E且无具体书面仓库指令要求针对此精确任务执行完整E2E/所有规范时，运行未过滤的完整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
```
或等效浏览器下载命令，而非使用沙箱浏览器缓存或记录辅助工具的浏览器预检查不匹配

Continuity And Evidence Fails

连续性与证据失败

passing Phase 3 or Phase 7 while changed app/server source still contains
```
console.*
```
outside the active Phase 5 debug loop
producing a final response or stopping summary while
```
CURRENT_PHASE.txt
```
is before
```
phase-7-final-signoff
```
producing a final response or stopping summary while any required artifact still says
```
Decision: Fail
```
, has a failing score, or contains pending gate evidence
ending an OpenCode turn mid-phase while the next workflow action is locally available
editing Phase 2 source files while
```
task-workflow/phase-2-execution.md
```
execution log remains blank or all
```
Pending
```
completing multiple Phase 2 implementation packets before updating their execution-log rows with file evidence
replacing evidence tables with prose
skipping the second execution pass
treating Phase 3 check/lint evidence as a substitute for Phase 4 unit-test coverage decisions, Phase 5 interactive Playwright verification, or Phase 6 E2E coverage decisions
treating Playwright verification as a substitute for warranted Phase 4 or Phase 6 test work
running Phase 5 interactive Playwright verification or Phase 6 E2E coverage work as a substitute for completing the Phase 2 gate
leaving a long-lived dev server, watcher, or interactive command in the foreground until the session stalls
relying on a file write or patch without readback evidence when the file matters to a gate
continuing after a failed, invalid, or uncertain write result without repairing and rereading the target file

变更的应用/服务器源代码在第5阶段活跃调试循环外仍包含
```
console.*
```
时通过第3或第7阶段
```
CURRENT_PHASE.txt
```
早于
```
phase-7-final-signoff
```
时产生最终响应或停止总结
任何所需工件仍显示“决策：失败”、分数不合格或包含待处理门禁证据时产生最终响应或停止总结
下一个工作流操作可本地执行时在阶段中途结束OpenCode回合
```
task-workflow/phase-2-execution.md
```
执行日志仍空白或全为“待处理”时编辑第2阶段源文件
完成多个第2阶段实现包后未用文件证据更新其执行日志行
用 prose 替换证据表格
跳过二次执行
将第3阶段检查/代码规范证据视为第4阶段单元测试覆盖决策、第5阶段交互式Playwright验证或第6阶段E2E覆盖决策的替代
将Playwright验证视为所需第4或第6阶段测试工作的替代
将第5阶段交互式Playwright验证或第6阶段E2E覆盖工作视为完成第2阶段门禁的替代
让长期运行的开发服务器、监视器或交互式命令在前台运行直到会话停滞
当文件对门禁重要时，依赖文件写入或补丁却无回读证据
写入失败、无效或结果不确定后未修复并重新读取目标文件就继续

Final Signoff Fails

最终签署失败

signing off while critical open gaps remain
signing off while
```
task-workflow/open-gaps.md
```
contains stale open gaps that a passed later phase claims to have resolved
signing off while
```
task-workflow/open-gaps.md
```
still contains template placeholder rows such as
```
Pending
```
passing Phase 5, Phase 6, or Phase 7 without recorded fixed-wait review evidence
passing Phase 5, Phase 6, or Phase 7 while fixed waits remain in
```
task-workflow/playwright
```
or
```
tests/e2e
```
passing Phase 7 without a recorded artifact integrity review of every phase artifact
signing off while any final quality scorecard category is below
```
8/10
```
deleting existing tests without equivalent replacement coverage or a written artifact defense
using broad unsafe casts or warning suppression to bypass the type system without a narrow evidence-backed reason
relying on conversation memory after compaction instead of using
```
progress.md
```
and
```
CURRENT_PHASE.txt
```
for status and re-reading this skill, required phase reference files, and artifacts
failing to enumerate
```
.tasks/files/
```
even when it is empty
failing to read or inspect every task attachment/supporting file in
```
.tasks/files/
```
before Phase 1 planning
bulk-reading every skill file in
```
.agents/skills/
```
instead of selecting and reading only task-relevant skills
planning, implementing, verifying, or signing off work that violates the extracted
```
AGENTS.md
```
development rules
running a MITB task completion command before all Phase 7 audit checks pass
failing to loop back to the earliest failing phase when any Phase 7 audit check fails
failing to run the required MITB completed command after all Phase 7 audit checks pass
asking the user whether to continue between phases when the next phase is unblocked

</automatic_fails>

存在关键开放缺口时签署确认
```
task-workflow/open-gaps.md
```
包含已通过后续阶段声称已解决的过期开放缺口时签署确认
```
task-workflow/open-gaps.md
```
仍包含“待处理”等模板占位符行时签署确认
无记录的固定等待评审证据时通过第5、6或7阶段
```
task-workflow/playwright
```
或
```
tests/e2e
```
仍存在固定等待时通过第5、6或7阶段
无记录的每个阶段工件完整性评审时通过第7阶段
任何最终质量评分卡类别低于
```
8/10
```
时签署确认
无等效替代覆盖或书面工件辩护就删除现有测试
无狭窄证据支持的原因就使用广泛不安全类型转换或警告抑制绕过类型系统
压缩后依赖对话记忆而非使用
```
progress.md
```
和
```
CURRENT_PHASE.txt
```
获取状态，重新阅读本技能、所需阶段参考文件和工件
未枚举
```
.tasks/files/
```
（即使为空）
第1阶段规划前未阅读或检查
```
.tasks/files/
```
中的每个任务附件/支持文件
批量读取
```
.agents/skills/
```
中的所有技能文件而非仅选择并阅读与任务相关的技能
规划、实现、验证或签署违反提取的
```
AGENTS.md
```
开发规则的工作
所有第7阶段审计检查通过前运行MITB任务完成命令
任何第7阶段审计检查失败时未返回最早失败的阶段
所有第7阶段审计检查通过后未运行所需的MITB完成命令
下一阶段未阻塞时询问用户是否在阶段间继续

</automatic_fails>

Reference Map

参考映射

```
references/phase-0-1-startup-research.md
```
: artifact reset, template copying, task intake, and codebase research.
```
references/phase-2-4-execution-integrity.md
```
: primary execution, second execution, gap closure, and integrity checks.
```
references/phase-5-7-verification-signoff.md
```
: interactive Playwright verification, E2E coverage decisions, and final audit.
```
references/playwright-interactive.md
```
: how this skill uses standalone interactive Playwright scripts.

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
```
: managed server/readiness/Playwright execution helper copied into
```
task-workflow/scripts/
```
during Phase 0.
```
assets/scripts/server-probe.mjs
```
: managed API/runtime server probe helper copied into
```
task-workflow/scripts/
```
during Phase 0 for pre-Phase-5 server checks.

```
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执行辅助工具，第0阶段复制到
```
task-workflow/scripts/
```
。
```
assets/scripts/server-probe.mjs
```
：托管API/运行时服务器探测辅助工具，第0阶段复制到
```
task-workflow/scripts/
```
，用于第5阶段前的服务器检查。

Non-Negotiables

不可协商项

Use the phase gates exactly.
Keep the artifacts auditable.
Return to earlier phases when evidence is weak.
Do not edit source files before Phase 0 and Phase 1 gates pass.
Do not sign off before interactive Playwright verification and regression test gates pass.

严格使用阶段门禁。
保持工件可审计。
证据薄弱时返回前期阶段。
第0和第1阶段门禁通过前不得编辑源文件。
交互式Playwright验证和回归测试门禁通过前不得签署确认。

Completion Standard

完成标准

The task is complete only when Phase 7 passes. If the task cannot be completed, the final artifact must identify the exact blocking condition, the phase where it occurred, commands run, files inspected, and the smallest next action needed.

仅当第7阶段通过时，任务才完成。若任务无法完成，最终工件必须明确识别阻塞条件、发生阶段、运行的命令、检查的文件，以及所需的最小下一个操作。