feature-dev-loop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feature Dev Loop

功能开发循环

Orchestrate a full software feature loop by composing local development skills instead of rewriting them: requirements baseline, plan breakdown, multi-perspective plan review, safe serial implementation, dynamic acceptance review, and an HTML PR summary.

This is a controller skill. It decides when to move between stages, how feedback is classified, when loops exit, what gets written to disk, and when to involve the user. It should call or follow existing local skills for the lower-level work when they are available, especially:

```
superpowers:writing-plans
```
for implementation plans
```
superpowers:subagent-driven-development
```
for task execution with implementer/reviewer agents
```
superpowers:test-driven-development
```
for feature and bugfix implementation
```
superpowers:requesting-code-review
```
for code review dispatch

superpowers:verification-before-completion

before claiming completion

Frontend/browser verification skills when UI behavior changes

通过组合本地开发技能而非重写它们，编排完整的软件功能开发循环：需求基线、计划拆解、多视角计划评审、安全串行实现、动态验收评审以及HTML PR摘要。

这是一个控制器技能。它决定何时在各阶段间切换、如何分类反馈、何时退出循环、哪些内容写入磁盘以及何时需要用户参与。当存在可用的本地技能时，它应调用或遵循这些技能来完成底层工作，尤其是：

```
superpowers:writing-plans
```
用于实现计划
```
superpowers:subagent-driven-development
```
用于通过实现者/评审者代理执行任务
```
superpowers:test-driven-development
```
用于功能和缺陷修复实现
```
superpowers:requesting-code-review
```
用于代码评审调度

superpowers:verification-before-completion

用于在声称完成前进行验证

前端/浏览器验证技能（当UI行为发生变化时）

Operating Defaults

操作默认值

Use this for non-trivial feature work, multi-step changes, PR-sized tasks, or explicit requests for plan review, subagent review, acceptance testing, code review, or PR summary generation.
For tiny edits, use a lightweight version unless the user explicitly asks for the full loop.
Default to safe serial implementation. Only run implementation workers in parallel when file/module ownership is disjoint and shared contracts are already fixed.
Default to human gates at the end of plan review and before final release. If the user asks for full auto mode, proceed automatically when exit criteria are met and record all assumptions.
Save process artifacts in the target repo under
```
docs/dev-loop-runs/YYYY-MM-DD-feature-slug/
```
.
Be git-aware, but do not commit, push, or open PRs unless the user explicitly asks.
Never loop forever. Each review loop has a default limit of 3 rounds.
Respect the active tool policy for subagents. If the user explicitly asked for subagents, delegation, plan review by agents, the full feature-dev-loop, or this skill by name, proceed with subagent dispatch when available. If not, ask before the first subagent dispatch or perform the review inline and record the limitation.

将此技能用于非简单功能工作、多步骤变更、PR级任务，或明确要求计划评审、子代理评审、验收测试、代码评审或PR摘要生成的请求。
对于微小编辑，除非用户明确要求完整循环，否则使用轻量版本。
默认采用安全串行实现。仅当文件/模块所有权完全独立且共享契约已固定时，才并行运行实现工作器。
默认在计划评审结束时和最终发布前设置人工审核关卡。如果用户要求全自动模式，当退出条件满足时自动进行，并记录所有假设。
将过程工件保存到目标仓库的
```
docs/dev-loop-runs/YYYY-MM-DD-feature-slug/
```
目录下。
具备git感知能力，但除非用户明确要求，否则不提交、推送或打开PR。
永不无限循环。每个评审循环默认限制为3轮。
尊重子代理的活动工具策略。如果用户明确要求子代理、任务委派、代理评审计划、完整功能开发循环或直接指定此技能，则在可用时调度子代理。否则，在首次调度子代理前询问用户，或内联执行评审并记录限制。

Dependency Gate

依赖检查

Before starting a full loop, check whether the local prerequisite skills are available in the active session. This skill depends on Superpowers-style development workflows; it should not silently degrade into an ad-hoc process when those skills are missing.

Check dependencies from the active skill list when it is available. If the active skill list is unavailable, inspect likely local skill/plugin locations such as

.agents/skills/superpowers

.codex/superpowers/skills

, or the harness plugin list. Do not assume a dependency exists just because this skill mentions it.

在启动完整循环前，检查当前会话中是否存在本地必备技能。此技能依赖Superpowers风格的开发工作流；当这些技能缺失时，不应自动退化为临时流程。

当可用时，从活动技能列表中检查依赖项。如果活动技能列表不可用，检查可能的本地技能/插件位置，如

.agents/skills/superpowers

、

.codex/superpowers/skills

或 harness插件列表。不要仅因本技能提及某依赖项就假设它存在。

Required skills

必填技能

These are required for the intended workflow:

```
superpowers:writing-plans
```
- implementation plan breakdown
```
superpowers:subagent-driven-development
```
- serial task execution with implementer/reviewer agents
```
superpowers:test-driven-development
```
- red/green/refactor discipline for behavior changes
```
superpowers:requesting-code-review
```
- structured code review dispatch

superpowers:verification-before-completion

- evidence before completion claims

这些是预期工作流所需的技能：

```
superpowers:writing-plans
```
- 实现计划拆解
```
superpowers:subagent-driven-development
```
- 通过实现者/评审者代理执行串行任务
```
superpowers:test-driven-development
```
- 针对行为变更的红/绿/重构准则
```
superpowers:requesting-code-review
```
- 结构化代码评审调度

superpowers:verification-before-completion

- 完成声明前的验证证据

Recommended skills

Missing dependency behavior

缺失依赖的处理

If any required skill is missing:

Stop before creating the full run directory or starting implementation.
Tell the user exactly which prerequisite skills are missing.
Recommend installing Superpowers, because these required skills are provided by the Superpowers workflow.
If a plugin-install tool for Superpowers is available in the current harness, use it or ask the user to approve it according to the active tool policy. Otherwise provide the appropriate install hint for the harness when known:
- Codex App: open Plugins in the sidebar, find
```
Superpowers
```
  in the Coding section, click
```
+
```
  , and follow the prompts.
- Codex CLI: run
```
/plugins
```
  , search for
```
superpowers
```
  , and select
```
Install Plugin
```
  .
- Claude Code: run
```
/plugin install superpowers@claude-plugins-official
```
  , or register the Superpowers marketplace with
```
/plugin marketplace add obra/superpowers-marketplace
```
  and then run
```
/plugin install superpowers@superpowers-marketplace
```
  .
After the user installs it, restart the dependency check before proceeding.

If installation is not possible in the current harness, offer a reduced inline mode only after making the limitation explicit. Reduced inline mode must still create the run artifacts and record that subagent/Superpowers dependencies were unavailable.

Reference for installation and workflow names:

https://github.com/obra/superpowers

如果任何必填技能缺失：

在创建完整运行目录或启动实现前停止。
准确告知用户哪些必备技能缺失。
建议安装Superpowers，因为这些必填技能由Superpowers工作流提供。
如果当前harness中存在Superpowers的插件安装工具，则根据活动工具策略使用它或请求用户批准。否则，提供已知的harness安装提示：
- Codex App：打开侧边栏的Plugins，在Coding部分找到
```
Superpowers
```
  ，点击
```
+
```
  并按照提示操作。
- Codex CLI：运行
```
/plugins
```
  ，搜索
```
superpowers
```
  ，选择
```
Install Plugin
```
  。
- Claude Code：运行
```
/plugin install superpowers@claude-plugins-official
```
  ，或使用
```
/plugin marketplace add obra/superpowers-marketplace
```
  注册Superpowers市场，然后运行
```
/plugin install superpowers@superpowers-marketplace
```
  。
用户安装后，重新进行依赖检查再继续。

如果当前harness无法安装，在明确说明限制后，仅提供简化内联模式。简化内联模式仍需创建运行工件，并记录子代理/Superpowers依赖不可用的情况。

安装和工作流名称参考：

https://github.com/obra/superpowers

。

Feedback Severity

反馈严重程度

All reviewer comments must use these severities:

```
BLOCKER
```
: Must be resolved before the loop can exit.
```
IMPORTANT
```
: Should be resolved before exit. The controller may adjudicate and close it only with written rationale.
```
QUESTION
```
: Must be answered or converted into a concrete change before exit.
```
NIT
```
: Non-blocking improvement. Record it, but do not let it block progress.

A phase may exit only when there are no unresolved

BLOCKER

IMPORTANT

, or

QUESTION

items. Remaining

NIT

items become follow-ups.

所有评审者评论必须使用以下严重程度：

```
BLOCKER
```
：必须解决后才能退出循环。
```
IMPORTANT
```
：应在退出前解决。控制器仅在提供书面理由的情况下才可判定并关闭此类问题。
```
QUESTION
```
：必须得到解答或转换为具体变更后才能退出。
```
NIT
```
：非阻塞性改进。记录此类问题，但不允许其阻碍进度。

仅当不存在未解决的

BLOCKER

、

IMPORTANT

或

QUESTION

项时，阶段才可退出。剩余的

NIT

项将成为后续任务。

Run Directory

运行目录

At the start of a run:

Locate the repo root with
```
git rev-parse --show-toplevel
```
when available.
Check
```
git status -sb
```
.
Record
```
base_sha
```
, current branch, dirty-state summary, user request, and mode.
Create:

text

docs/dev-loop-runs/YYYY-MM-DD-feature-slug/
  00-requirements.md
  01-plan.md
  02-plan-review-rounds.md
  03-implementation-log.md
  04-acceptance-report.md
  05-pr-summary.html
  artifacts/
    screenshots/
    test-outputs/

If the working tree is dirty, do not revert anything. Decide whether existing changes are related to the requested task. If ambiguous and risky, ask the user before editing.

在运行开始时：

可用时使用
```
git rev-parse --show-toplevel
```
定位仓库根目录。
检查
```
git status -sb
```
。
记录
```
base_sha
```
、当前分支、脏状态摘要、用户请求和模式。
创建：

text

docs/dev-loop-runs/YYYY-MM-DD-feature-slug/
  00-requirements.md
  01-plan.md
  02-plan-review-rounds.md
  03-implementation-log.md
  04-acceptance-report.md
  05-pr-summary.html
  artifacts/
    screenshots/
    test-outputs/

如果工作树处于脏状态，不要还原任何内容。判断现有变更是否与请求的任务相关。如果存在歧义且有风险，在编辑前询问用户。

Phase 1: Requirements Baseline

阶段1：需求基线

Create

00-requirements.md

before planning.

Use this structure:

markdown

undefined

在规划前创建

00-requirements.md

。

使用以下结构：

markdown

undefined

Requirements Baseline

Goal

Non-goals

User-visible Behavior

Acceptance Criteria

Constraints

Assumptions

Open Questions

Source Request

Repo Context


Ask the user only for open questions that materially affect architecture, data model, security, user experience, compatibility, or test strategy. Infer ordinary implementation details from repo conventions and record them as assumptions.

Do not enter plan breakdown while blocking open questions remain.


仅询问用户那些会实质性影响架构、数据模型、安全性、用户体验、兼容性或测试策略的未解决问题。从仓库约定中推断普通实现细节，并将其记录为假设。

在存在阻塞性未解决问题时，不要进入计划拆解阶段。

Phase 2: Plan Breakdown

阶段2：计划拆解

Explore the codebase before writing the plan. Prefer

rg

and existing project docs/tests. Let the repo teach the implementation style.

Create

01-plan.md

. When available, follow

superpowers:writing-plans

The plan must include:

Exact goal and architecture summary
Files/modules expected to change
Task order and dependencies
Test strategy and exact verification commands
Ownership boundaries for any worker subagents
Acceptance criteria mapped back to
```
00-requirements.md
```
Known risks and assumptions

Tasks should be small enough to implement and review independently. If a shared contract is needed, put it before dependent tasks.

编写计划前先探索代码库。优先使用

rg

和现有项目文档/测试。让仓库本身指导实现风格。

创建

01-plan.md

。如果可用，遵循

superpowers:writing-plans

的规范。

计划必须包含：

明确的目标和架构摘要
预期变更的文件/模块
任务顺序和依赖关系
测试策略和具体的验证命令
任何工作器子代理的所有权边界
映射回
```
00-requirements.md
```
的验收标准
已知风险和假设

任务应足够小，以便独立实现和评审。如果需要共享契约，将其放在依赖任务之前。

Phase 3: Multi-perspective Plan Review Loop

阶段3：多视角计划评审循环

Dispatch multiple plan-review subagents from different perspectives when subagents are available and permitted. Give each reviewer precise context: the requirements file, plan file, relevant repo conventions, and the requested output schema. Do not hand them the whole conversation history.

Default reviewer perspectives:

Architecture reviewer: decomposition, boundaries, dependency order, extensibility, integration risk
Test strategy reviewer: acceptance criteria, regression coverage, failure paths, verification commands
Product/spec reviewer: user-visible behavior, requirement gaps, non-goals, ambiguous semantics
Risk/complexity reviewer: hidden complexity, migration risk, rollout concerns, maintainability traps

Each reviewer must return:

markdown

undefined

当子代理可用且被允许时，从不同视角调度多个计划评审子代理。为每个评审者提供精确的上下文：需求文件、计划文件、相关仓库约定和请求的输出模式。不要将整个对话历史交给他们。

默认评审者视角：

架构评审者：分解方式、边界、依赖顺序、可扩展性、集成风险
测试策略评审者：验收标准、回归覆盖、故障路径、验证命令
产品/规格评审者：用户可见行为、需求缺口、非目标、模糊语义
风险/复杂度评审者：隐藏复杂度、迁移风险、部署问题、可维护性陷阱

每个评审者必须返回：

markdown

undefined

Verdict

APPROVED | COMMENTS

Comments

id: severity: BLOCKER | IMPORTANT | QUESTION | NIT area: target: comment: required_change:

id: severity: BLOCKER | IMPORTANT | QUESTION | NIT area: target: comment: required_change:

Approval Conditions


Aggregate all feedback into `02-plan-review-rounds.md`.

For each round:

1. Fix the plan for all valid `BLOCKER`, `IMPORTANT`, and `QUESTION` feedback.
2. If rejecting a comment, write the adjudication and rationale.
3. Re-run the reviewers on the whole revised plan, not just the diff.
4. Stop after 3 rounds and escalate unresolved blocking disagreement to the user with a concrete recommendation.

Plan review exits when all reviewers approve or only `NIT` items remain.


将所有反馈汇总到`02-plan-review-rounds.md`中。

每一轮：

1. 针对所有有效的`BLOCKER`、`IMPORTANT`和`QUESTION`反馈修改计划。
2. 如果拒绝某条评论，写下判定理由。
3. 让评审者重新评审整个修订后的计划，而不仅仅是差异部分。
4. 3轮后停止，将未解决的阻塞性分歧升级给用户，并提供具体建议。

当所有评审者批准或仅剩余`NIT`项时，计划评审退出。

Plan Gate

计划关卡

Unless the user requested auto mode, show a concise plan summary and ask for approval before implementation:

Goal
Major files/modules
Task sequence
Main risks
Verification strategy

除非用户请求自动模式，否则在实现前展示简洁的计划摘要并请求批准：

目标
主要文件/模块
任务序列
主要风险
验证策略

Phase 4: Safe Serial Implementation

阶段4：安全串行实现

Implement one task at a time in plan order. Use

superpowers:subagent-driven-development

when the plan is well-specified and worker subagents are appropriate. Use

superpowers:test-driven-development

for behavior changes.

For each task:

Assign clear file/module ownership.
Tell workers they are not alone in the codebase, must not revert others' edits, and must adapt to existing changes.
Prefer TDD: write/verify failing tests before implementation where practical.
Run task-specific verification commands.
Record changes, commands, results, and concerns in
```
03-implementation-log.md
```
.
Run task-level spec compliance and code-quality review when the task has meaningful behavior or risk.
Resolve review findings using the shared severity rules.

Default to serial implementation. Parallel implementation is allowed only when:

Tasks touch disjoint files/modules
Shared contracts are already committed or otherwise stable
Each worker has explicit ownership
The controller can safely integrate and review the outputs

Do not create checkpoint commits unless the user explicitly requested commits or PR mode.

按照计划顺序一次实现一个任务。当计划明确且工作器子代理合适时，使用

superpowers:subagent-driven-development

。针对行为变更使用

superpowers:test-driven-development

。

对于每个任务：

分配明确的文件/模块所有权。
告知工作器他们并非独自在代码库中，不得还原他人的编辑，必须适应现有变更。
优先采用TDD：在可行的情况下，先编写/验证失败的测试再进行实现。
运行任务特定的验证命令。
在
```
03-implementation-log.md
```
中记录变更、命令、结果和关注点。
当任务具有有意义的行为或风险时，运行任务级别的规格合规性和代码质量评审。
使用共享的严重程度规则解决评审发现的问题。

默认采用串行实现。仅在以下情况下允许并行实现：

任务涉及不相交的文件/模块
共享契约已提交或以其他方式稳定
每个工作器有明确的所有权
控制器可以安全地集成和评审输出

除非用户明确请求提交或PR模式，否则不要创建检查点提交。

Phase 5: Dynamic Acceptance Matrix

阶段5：动态验收矩阵

After implementation, choose reviewers based on the actual change surface.

Always run:

Requirements acceptance reviewer: verifies the delivered behavior against
```
00-requirements.md
```
and
```
01-plan.md
```
Test coverage reviewer: checks tests, missing cases, regression risk, and whether verification commands are credible
Code quality reviewer: checks correctness, maintainability, integration, edge cases, and hidden regressions

Run conditionally:

Frontend UX reviewer: for UI, interaction, layout, accessibility, or visual changes; require browser/screenshot evidence
Security reviewer: for auth, permissions, secrets, uploads, external input, payments, or data exposure
Performance reviewer: for queries, rendering loops, concurrency, caching, batching, or large data paths
Docs/migration reviewer: for configuration, migration, API behavior, setup instructions, or user-facing behavior changes
Compatibility reviewer: for public APIs, schemas, serialized data, plugins, or integration contracts

Each acceptance reviewer receives:

Requirements baseline
Final plan
Implementation log
```
base_sha
```
and current
```
HEAD
```
or working-tree diff
Relevant test outputs and screenshots
Their specific review mandate

Each reviewer returns:

markdown

undefined

实现完成后，根据实际变更范围选择评审者。

始终运行：

需求验收评审者：验证交付的行为是否符合
```
00-requirements.md
```
和
```
01-plan.md
```
测试覆盖评审者：检查测试、缺失用例、回归风险以及验证命令是否可信
代码质量评审者：检查正确性、可维护性、集成性、边缘情况和隐藏的回归问题

有条件地运行：

前端UX评审者：针对UI、交互、布局、可访问性或视觉变更；需要浏览器/截图证据
安全评审者：针对认证、权限、密钥、上传、外部输入、支付或数据暴露
性能评审者：针对查询、渲染循环、并发、缓存、批处理或大数据路径
文档/迁移评审者：针对配置、迁移、API行为、设置说明或用户可见行为变更
兼容性评审者：针对公共API、 schema、序列化数据、插件或集成契约

每个验收评审者会收到：

需求基线
最终计划
实现日志
```
base_sha
```
和当前
```
HEAD
```
或工作树差异
相关测试输出和截图
他们特定的评审任务

每个评审者返回：

markdown

undefined

Verdict

PASS | PASS_WITH_NOTES | FAIL

Scope Checked

Evidence

Findings

id: severity: BLOCKER | IMPORTANT | MINOR target: finding: suggested_fix: evidence:

id: severity: BLOCKER | IMPORTANT | MINOR target: finding: suggested_fix: evidence:

Residual Risks


Aggregate results into `04-acceptance-report.md`:

```markdown


将结果汇总到`04-acceptance-report.md`中：

```markdown

Acceptance Report

Verdict

PASS | PASS_WITH_NOTES | FAIL

Scope Checked

Reviewers Run

Tests Run

Requirement Coverage

Findings

Fixes Applied

Residual Risks

Follow-ups


Acceptance exits only when:

- No `BLOCKER` remains
- No unresolved `IMPORTANT` remains
- Verification commands pass, or unavailable commands are clearly explained
- The controller can honestly assign `PASS` or `PASS_WITH_NOTES`

If acceptance fails, fix the issues and re-run the relevant reviewers. Stop after 3 rounds and escalate with a blocker report.


仅当满足以下条件时，验收阶段才可退出：

- 无剩余`BLOCKER`
- 无未解决的`IMPORTANT`
- 验证命令通过，或无法运行的命令有明确解释
- 控制器可以诚实地判定为`PASS`或`PASS_WITH_NOTES`

如果验收失败，修复问题并重新运行相关评审者。3轮后停止，将阻塞问题报告升级给用户。

Phase 6: HTML PR Summary

阶段6：HTML PR摘要

Generate

05-pr-summary.html

as a self-contained, summary-first HTML report. It should help a PR reviewer understand the change quickly, while preserving expandable audit detail.

The first screen should answer:

What problem this PR solves
What changed
User-visible behavior changes
Validation and acceptance verdict
Residual risks and follow-ups

Include expandable detail sections for:

Requirements baseline
Plan review summary
Implementation log
Acceptance matrix
Tests run and key outputs
Code review findings
Screenshots or artifacts, when applicable
Main diff or changed-file summary

Use plain, readable HTML and CSS with no external network dependencies. Link local artifacts with relative paths where possible.

生成

05-pr-summary.html

作为一个自包含、摘要优先的HTML报告。它应帮助PR评审者快速理解变更，同时保留可展开的审计细节。

首屏应回答：

此PR解决了什么问题
发生了哪些变更
用户可见的行为变更
验证和验收结论
剩余风险和后续任务

包含可展开的详细部分：

需求基线
计划评审摘要
实现日志
验收矩阵
运行的测试和关键输出
代码评审发现
截图或工件（如适用）
主要差异或变更文件摘要

使用简洁易读的HTML和CSS，无外部网络依赖。尽可能使用相对路径链接本地工件。

Git Policy

Git策略

Always inspect and record current branch and
```
base_sha
```
.
Never run destructive git commands.
Never revert user changes unless explicitly requested.
Do not commit, push, or open a PR unless the user explicitly asks.
If commits are requested, use non-interactive git commands and keep commits scoped to completed, verified units.
If no commits exist, generate summaries from
```
git diff
```
and
```
git status
```
.

始终检查并记录当前分支和
```
base_sha
```
。
永不运行破坏性git命令。
除非明确请求，否则不还原用户变更。
除非用户明确要求，否则不提交、推送或打开PR。
如果请求提交，使用非交互式git命令，保持提交范围限于已完成、已验证的单元。
如果不存在提交，从
```
git diff
```
和
```
git status
```
生成摘要。

User Escalation Rules

用户升级规则

Ask the user only when:

Requirements ambiguity changes architecture, UX, data model, security, compatibility, or acceptance criteria
Existing workspace changes make safe editing ambiguous
Review loops hit the 3-round limit with unresolved blocking disagreement
The requested behavior conflicts with repo constraints or safety requirements

When asking, ask one concrete question at a time and provide a recommended answer.

仅在以下情况询问用户：

需求歧义会改变架构、UX、数据模型、安全性、兼容性或验收标准
现有工作区变更使安全编辑存在歧义
评审循环达到3轮限制且存在未解决的阻塞性分歧
请求的行为与仓库约束或安全要求冲突

询问时，一次提出一个具体问题，并提供建议答案。

Completion Checklist

完成检查清单

Before final response:

```
00-requirements.md
```
exists
```
01-plan.md
```
exists and passed plan review or has documented adjudications
```
03-implementation-log.md
```
records tasks, changed files, and verification evidence
```
04-acceptance-report.md
```
has a clear verdict
```
05-pr-summary.html
```
exists
Required tests or checks were run, or the reason they could not run is recorded
No unresolved
```
BLOCKER
```
,
```
IMPORTANT
```
, or
```
QUESTION
```
remains

Then summarize the outcome concisely for the user, including the report path and verification status.

在最终响应前：

```
00-requirements.md
```
已存在
```
01-plan.md
```
已存在且通过计划评审或有记录的判定
```
03-implementation-log.md
```
记录了任务、变更文件和验证证据
```
04-acceptance-report.md
```
有明确结论
```
05-pr-summary.html
```
已存在
已运行必填测试或检查，或记录了无法运行的原因
无未解决的
```
BLOCKER
```
、
```
IMPORTANT
```
或
```
QUESTION
```

然后为用户简洁总结结果，包括报告路径和验证状态。

feature-dev-loop

Original

Translation

Feature Dev Loop

功能开发循环

Operating Defaults

操作默认值

Dependency Gate

依赖检查

Required skills

必填技能

Recommended skills

推荐技能

Missing dependency behavior

缺失依赖的处理

Feedback Severity

反馈严重程度

Run Directory

运行目录

Phase 1: Requirements Baseline

阶段1：需求基线

Requirements Baseline

Requirements Baseline

Goal

Goal

Non-goals

Non-goals

User-visible Behavior

User-visible Behavior

Acceptance Criteria

Acceptance Criteria

Constraints

Constraints

Assumptions

Assumptions

Open Questions

Open Questions

Source Request

Source Request

Repo Context

Repo Context

Phase 2: Plan Breakdown

阶段2：计划拆解

Phase 3: Multi-perspective Plan Review Loop

阶段3：多视角计划评审循环

Verdict

Verdict

Comments

Comments

Approval Conditions

Approval Conditions

Plan Gate

计划关卡

Phase 4: Safe Serial Implementation

阶段4：安全串行实现

Phase 5: Dynamic Acceptance Matrix

阶段5：动态验收矩阵

Verdict

Verdict

Scope Checked

Scope Checked

Evidence

Evidence

Findings

Findings

Residual Risks

Residual Risks

Acceptance Report

Acceptance Report

Verdict

Verdict

Scope Checked

Scope Checked

Reviewers Run

Reviewers Run

Tests Run

Tests Run

Requirement Coverage

Requirement Coverage

Findings