devdocs-dev-workflow
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese开发工作流
Development Workflow
执行单个开发任务的工作流指导,采用自顶向下开发模式和分层 TDD。
Workflow guidance for executing individual development tasks, using top-down development mode and layered TDD.
语言规则
Language Rules
- 支持中英文提问
- 统一中文回复
- Supports Chinese and English queries
- Responses are uniformly in Chinese
触发条件
Trigger Conditions
- 用户开始执行某个任务(如 T-01)
- 用户需要开发指导
- 用户从 devdocs-dev-tasks 进入开发阶段
- 关键词:"开发任务"、"执行任务"、"开始 T-XX"
- User starts executing a task (e.g., T-01)
- User needs development guidance
- User enters the development phase from devdocs-dev-tasks
- Keywords: "execute task", "start T-XX", "开发任务", "执行任务"
前置条件
Preconditions
- 任务文档:
docs/devdocs/04-dev-tasks.md - 任务已定义并包含:关联需求、验收标准、测试方法
- Task document:
docs/devdocs/04-dev-tasks.md - Task is defined and includes: associated requirements, acceptance criteria, testing methods
工作流程
Workflow
1. 读取任务定义
├── 从 04-dev-tasks.md 获取任务详情
├── 确认关联的 F-XXX、AC-XXX
└── 确认关联的测试用例 UT/IT/E2E-XXX
│
▼
2. 生成骨架代码(自顶向下)
├── 接口骨架 + @requirement/@satisfies 标注
└── 测试骨架 + @verifies/@testcase 标注
│
▼
3. 执行开发(分层 TDD)
├── 核心逻辑 🔴:测试先行
├── 接口层 🟡:推荐测试先行
├── UI 层 🟢:可实现后补测试
└── 基础设施 ⚪:集成测试验证
│
▼
4. 完成检查
├── 基础检查(始终执行)
│ ├── 验收标准全部满足
│ ├── 测试通过
│ └── Review 要点自查
│
└── 对抗式验证(🔴自动触发 / 其他层级 --review 手动触发)
├── 🔍 代码质量审查(/code-quality 视角)
├── 🧪 测试完备性审查(/testing-guide 视角)
└── 📋 综合审查报告
│
▼
4.5 更新自描述(/code-self-describe --update)
│
▼
5. 提交代码(遵循 /commit-convention)
│
▼
6. 更新追溯(运行 /devdocs-sync --trace)1. Read Task Definition
├── Retrieve task details from 04-dev-tasks.md
├── Confirm associated F-XXX, AC-XXX
└── Confirm associated test cases UT/IT/E2E-XXX
│
▼
2. Generate Skeleton Code (Top-Down)
├── Interface skeleton + @requirement/@satisfies annotations
└── Test skeleton + @verifies/@testcase annotations
│
▼
3. Execute Development (Layered TDD)
├── Core Logic 🔴: Test-first
├── Interface Layer 🟡: Recommended test-first
├── UI Layer 🟢: Tests can be added after implementation
└── Infrastructure ⚪: Verified via integration tests
│
▼
4. Completion Check
├── Basic Check (Always Executed)
│ ├── All acceptance criteria are satisfied
│ ├── Tests pass
│ └── Self-check of review points
│
└── Adversarial Verification (🔴 Auto-triggered / Manual trigger via --review for other layers)
├── 🔍 Code Quality Review (from /code-quality perspective)
├── 🧪 Test Completeness Review (from /testing-guide perspective)
└── 📋 Comprehensive Review Report
│
▼
4.5 Update Self-description (Run /code-self-describe --update)
│
▼
5. Submit Code (Follow /commit-convention)
│
▼
6. Update Traceability (Run /devdocs-sync --trace)代码追溯标注规范
Code Traceability Annotation Specification
实现文档↔代码的双向追溯,AI 在生成代码时自动添加标注。
Achieve two-way traceability between documents and code; AI automatically adds annotations when generating code.
标注类型
Annotation Types
| 标注 | 用途 | 位置 |
|---|---|---|
| 关联功能点 | 接口/类/模块 |
| 满足的验收标准 | 接口/方法 |
| 验证的验收标准 | 测试用例 |
| 测试编号 | 测试用例 |
| Annotation | Purpose | Location |
|---|---|---|
| Associate with feature points | Interface/Class/Module |
| Meets acceptance criteria | Interface/Method |
| Verifies acceptance criteria | Test Case |
| Test ID | Test Case |
标注示例
Annotation Example
typescript
/**
* 创建用户
* @requirement F-001 - 用户注册
* @satisfies AC-001 - 邮箱格式校验
* @satisfies AC-002 - 密码强度校验
*/
export async function createUser(dto: CreateUserDTO): Promise<User> {
// 实现代码
}
/**
* @verifies AC-001 - 邮箱格式校验
* @testcase UT-001
*/
test('createUser 应该拒绝无效邮箱格式', () => {
// 测试代码
});typescript
/**
* Create User
* @requirement F-001 - User Registration
* @satisfies AC-001 - Email Format Validation
* @satisfies AC-002 - Password Strength Validation
*/
export async function createUser(dto: CreateUserDTO): Promise<User> {
// Implementation code
}
/**
* @verifies AC-001 - Email Format Validation
* @testcase UT-001
*/
test('createUser should reject invalid email formats', () => {
// Test code
});标注规则
Annotation Rules
| 层级 | 标注位置 | 强制性 |
|---|---|---|
| 公共接口 | Service/API 入口方法 | 必须 |
| 测试文件 | 每个测试用例 | 必须 |
| 内部实现 | 复杂逻辑 | 可选 |
| Level | Annotation Location | Mandatory |
|---|---|---|
| Public Interface | Service/API entry method | Required |
| Test Files | Each test case | Required |
| Internal Implementation | Complex logic | Optional |
See skeleton-examples.md for details
自顶向下开发模式
Top-Down Development Mode
先定义骨架,后填充细节。确保追溯链在代码生成时就建立。
Define the skeleton first, then fill in the details. Ensure the traceability chain is established during code generation.
开发流程
Development Process
Step 1: 生成接口骨架
├── 方法签名(来自 02-system-design.md)
├── 添加 @requirement/@satisfies 标注
└── 方法体: throw new Error('Not implemented')
│
▼
Step 2: 生成测试骨架
├── 测试结构(来自 03-test-cases.md)
├── 添加 @verifies/@testcase 标注
└── 测试体: test.skip() 或 test.todo()
│
▼
Step 3: 实现接口细节(遵循 /code-quality)
│
▼
Step 4: 完善测试(遵循 /testing-guide)
│
▼
Step 5: 运行 /devdocs-sync --trace 更新追溯矩阵Step 1: Generate Interface Skeleton
├── Method signature (from 02-system-design.md)
├── Add @requirement/@satisfies annotations
└── Method body: throw new Error('Not implemented')
│
▼
Step 2: Generate Test Skeleton
├── Test structure (from 03-test-cases.md)
├── Add @verifies/@testcase annotations
└── Test body: test.skip() or test.todo()
│
▼
Step 3: Implement Interface Details (Follow /code-quality)
│
▼
Step 4: Improve Tests (Follow /testing-guide)
│
▼
Step 5: Run /devdocs-sync --trace to update traceability matrix骨架生成约束
Skeleton Generation Constraints
- 接口骨架必须包含完整签名(参数、返回值、泛型)
- 接口骨架必须添加追溯标注
- 未实现方法必须抛出 Error 并注明任务编号
- 测试骨架必须使用 skip/todo 标记
- 测试骨架必须添加 @verifies 和 @testcase 标注
详见 skeleton-examples.md
- Interface skeleton must include complete signature (parameters, return value, generics)
- Interface skeleton must add traceability annotations
- Unimplemented methods must throw an Error and indicate the task ID
- Test skeleton must use skip/todo markers
- Test skeleton must add @verifies and @testcase annotations
分层 TDD 模式
Layered TDD Mode
根据任务类型决定测试优先级:
| 层级 | TDD 模式 | 说明 |
|---|---|---|
| 核心逻辑 (Service/Domain) | 🔴 强制 | 测试先行 |
| 接口层 (Controller/API) | 🟡 推荐 | 建议测试先行 |
| UI 层 (Component/View) | 🟢 可选 | 可实现后补 |
| 基础设施 (DB/Config) | ⚪ 不适用 | 集成测试验证 |
Determine test priority based on task type:
| Layer | TDD Mode | Description |
|---|---|---|
| Core Logic (Service/Domain) | 🔴 Mandatory | Test-first |
| Interface Layer (Controller/API) | 🟡 Recommended | Recommended to use test-first |
| UI Layer (Component/View) | 🟢 Optional | Tests can be added after implementation |
| Infrastructure (DB/Config) | ⚪ Not Applicable | Verified via integration tests |
TDD 循环
TDD Cycle
┌─────┐ ┌─────┐ ┌─────┐
│ 红 │ → │ 绿 │ → │重构 │ ──┐
│写测试│ │写实现│ │优化 │ │
│(失败)│ │(通过)│ │代码 │ │
└─────┘ └─────┘ └─────┘ │
↑ │
└───────────────────────────┘详细执行流程见 execution-flow.md
┌─────┐ ┌─────┐ ┌─────┐
│ Red │ → │ Green│ → │Refactor│ ──┐
│Write Test│ │Write Code│ │Optimize│ │
│(Fails)│ │(Passes)│ │Code │ │
└─────┘ └─────┘ └─────┘ │
↑ │
└───────────────────────────┘See execution-flow.md for detailed execution process
Skill 协作
Skill Collaboration
| 阶段 | 协作 Skill | 说明 |
|---|---|---|
| 写业务代码 | | MTE 原则、依赖注入、避免过度设计 |
| 写测试代码 | | 断言质量、变异测试、覆盖率 |
| UI 实现 | | 无障碍、动画、布局约束 |
| 完成验证 | | 对抗式验证:多视角审查 |
| 完成检查 | | 更新模块自描述(--update) |
| 代码提交 | | 使用 git mv/rm 处理文件 |
| 提交信息 | | 遵循项目提交规范 |
| 任务完成 | | 后续:更新追溯矩阵(--trace) |
| Phase | Collaborating Skill | Description |
|---|---|---|
| Writing business code | | MTE principles, dependency injection, avoid over-engineering |
| Writing test code | | Assertion quality, mutation testing, coverage |
| UI implementation | | Accessibility, animations, layout constraints |
| Completion verification | | Adversarial verification: multi-perspective review |
| Completion check | | Update module self-description (--update) |
| Code submission | | Use git mv/rm for file operations |
| Commit message | | Follow project commit conventions |
| Task completion | | Follow-up: Update traceability matrix (--trace) |
约束
Constraints
骨架生成约束
Skeleton Generation Constraints
- 接口骨架必须包含完整签名
- 接口骨架必须添加追溯标注
- 未实现方法必须抛出 Error
- 测试骨架必须使用 skip/todo 标记
- 测试骨架必须添加 @verifies 和 @testcase 标注
- Interface skeleton must include complete signature
- Interface skeleton must add traceability annotations
- Unimplemented methods must throw an Error
- Test skeleton must use skip/todo markers
- Test skeleton must add @verifies and @testcase annotations
分层 TDD 约束
Layered TDD Constraints
- 核心逻辑任务必须标记 🔴 强制 TDD
- 核心逻辑任务必须先写测试,后写实现
- 核心逻辑任务禁止在测试通过前提交
- 接口层任务标记 🟡 推荐 TDD
- UI 层任务标记 🟢 可选 TDD
- 基础设施任务标记 ⚪ 不适用 TDD
- TDD 任务必须包含红-绿-重构三步骤
- Core logic tasks must be marked 🔴 Mandatory TDD
- Core logic tasks must write tests first, then implementation
- Core logic tasks cannot be submitted before tests pass
- Interface layer tasks are marked 🟡 Recommended TDD
- UI layer tasks are marked 🟢 Optional TDD
- Infrastructure tasks are marked ⚪ Not Applicable TDD
- TDD tasks must include red-green-refactor three steps
完成检查约束
Completion Check Constraints
- 验收标准 (AC-XXX) 全部满足
- 关联测试全部通过
- Review 要点自查完成
- 代码追溯标注完整
- 代码分支覆盖分析完成(可选,使用 分支分析)
/testing-guide
- All acceptance criteria (AC-XXX) are satisfied
- All associated tests pass
- Self-check of review points is completed
- Code traceability annotations are complete
- Code branch coverage analysis is completed (Optional, use /testing-guide branch analysis)
对抗式验证(可选)
Adversarial Verification (Optional)
以不同角色视角审查代码,模拟 "开发 → 审查 → 测试" 的多人协作模式。 核心逻辑任务(🔴)自动触发,其他层级通过手动触发。--review
Review code from different role perspectives, simulating the multi-person collaboration mode of "Development → Review → Testing". Core logic tasks (🔴) trigger automatically; other layers are triggered manually via.--review
触发条件
Trigger Conditions
层级判定:任务层级标记(🔴🟡🟢⚪)来自中的任务定义,由04-dev-tasks.md在任务拆分时根据任务分层规则分配。/devdocs-dev-tasks
| 任务层级 | 默认行为 | 手动控制 |
|---|---|---|
| 🔴 核心逻辑 | 自动触发 | |
| 🟡 接口层 | 不触发 | |
| 🟢 UI 层 | 不触发 | |
| ⚪ 基础设施 | 不触发 | |
Layer Determination: Task layer markers (🔴🟡🟢⚪) come from task definitions in, assigned by04-dev-tasks.mdduring task splitting according to task layering rules./devdocs-dev-tasks
| Task Layer | Default Behavior | Manual Control |
|---|---|---|
| 🔴 Core Logic | Automatically triggered | |
| 🟡 Interface Layer | Not triggered | |
| 🟢 UI Layer | Not triggered | |
| ⚪ Infrastructure | Not triggered | |
验证流程
Verification Process
基础完成检查(始终执行)
│
├── AC 全部满足 ✅
├── 测试全部通过 ✅
├── 代码标注完整 ✅
│
▼ (对抗式验证触发时)
Phase 1: 代码质量审查 🔍
├── 切换到 /code-quality 视角
├── MTE 原则检查(函数长度/参数/嵌套/职责)
├── 依赖方向检查
├── 安全检查
└── 输出: 问题列表(Blocker/Suggestion)
│
▼
Phase 2: 测试完备性审查 🧪
├── 切换到 /testing-guide 视角
├── 断言质量检查(禁止弱断言)
├── 覆盖率检查(行/分支 ≥80%)
├── 需求追溯检查(AC 全覆盖)
├── [可选] 代码分支覆盖分析
└── 输出: 问题列表(Blocker/Suggestion)
│
▼
Phase 3: 综合审查报告 📋
├── 汇总所有问题
├── 🚫 Blocker → 必须修复后重新验证
└── 💡 Suggestion → 询问用户是否修复Basic Completion Check (Always Executed)
│
├── All AC satisfied ✅
├── All tests pass ✅
├── Code annotations complete ✅
│
▼ (When adversarial verification is triggered)
Phase 1: Code Quality Review 🔍
├── Switch to /code-quality perspective
├── MTE principle check (function length/parameters/nesting/responsibilities)
├── Dependency direction check
├── Security check
└── Output: Issue list (Blocker/Suggestion)
│
▼
Phase 2: Test Completeness Review 🧪
├── Switch to /testing-guide perspective
├── Assertion quality check (forbid weak assertions)
├── Coverage check (line/branch ≥80%)
├── Requirement traceability check (full AC coverage)
├── [Optional] Code branch coverage analysis
└── Output: Issue list (Blocker/Suggestion)
│
▼
Phase 3: Comprehensive Review Report 📋
├── Summarize all issues
├── 🚫 Blocker → Must fix before re-verification
└── 💡 Suggestion → Ask user if they want to fix审查结果分级
Review Result Levels
| 级别 | 标记 | 处理 |
|---|---|---|
| 🚫 Blocker | 必须修复 | 阻止提交,修复后重新验证 |
| 💡 Suggestion | 建议修复 | 询问用户,可选择忽略 |
| Level | Marker | Handling |
|---|---|---|
| 🚫 Blocker | Must fix | Blocks submission; re-verify after fixing |
| 💡 Suggestion | Recommended to fix | Ask user; can choose to ignore |
对抗式验证约束
Adversarial Verification Constraints
- Blocker 问题必须修复后才能提交
- 每个 Phase 必须明确声明当前审查角色
- 审查结果必须分级(Blocker/Suggestion)
- 核心逻辑任务(🔴)默认触发
- 修复 Blocker 后必须重新运行验证
详细审查清单和报告模板见 verification-flow.md
- Blocker issues must be fixed before submission
- Each phase must clearly state the current review role
- Review results must be classified (Blocker/Suggestion)
- Core logic tasks (🔴) are triggered by default
- Must re-run verification after fixing Blocker issues
See verification-flow.md for detailed review checklist and report template
任务完成流程
Task Completion Process
TDD 任务(核心逻辑 🔴)
TDD Tasks (Core Logic 🔴)
- 确认测试先行:检查是否先写了测试
- 确认红-绿循环:测试从失败到通过
- 检查重构:代码是否经过优化
- 验证验收标准:检查所有 AC 是否满足
- 对抗式验证(自动触发):
- Phase 1: 代码质量审查(/code-quality 视角)
- Phase 2: 测试完备性审查(/testing-guide 视角)
- Phase 3: 综合报告,处理 Blocker
- 更新自描述:运行 /code-self-describe --update
- 询问提交:使用 AskUserQuestion 询问:
- "任务 T-XX(TDD)已完成,测试通过,是否提交代码?"
- 选项:"提交" / "继续修改" / "跳过"
- 如提交:执行 git add 和 commit,消息包含任务编号
- 更新状态:将任务标记为已完成
- Confirm test-first approach: Check if tests were written first
- Confirm red-green cycle: Tests go from failed to passed
- Check refactoring: Whether code has been optimized
- Verify acceptance criteria: Check if all AC are satisfied
- Adversarial Verification (Auto-triggered):
- Phase 1: Code Quality Review (from /code-quality perspective)
- Phase 2: Test Completeness Review (from /testing-guide perspective)
- Phase 3: Comprehensive report, handle Blockers
- Update self-description: Run /code-self-describe --update
- Ask for submission: Use AskUserQuestion to ask:
- "Task T-XX (TDD) is completed, tests passed. Do you want to submit the code?"
- Options: "Submit" / "Continue modifying" / "Skip"
- If submit: Execute git add and commit, with task ID included in the message
- Update status: Mark the task as completed
非 TDD 任务(接口/UI/基础设施)
Non-TDD Tasks (Interface/UI/Infrastructure)
- 执行测试:运行任务定义的测试方法
- 验证验收标准:检查所有验收标准是否满足
- 对抗式验证(如 --review 触发):同上 Phase 1-3
- 自查 Review 要点:检查代码审查要点
- 询问提交:使用 AskUserQuestion 询问
- 如提交:执行 git add 和 commit
- 更新状态:将任务标记为已完成
- Execute tests: Run the testing methods defined in the task
- Verify acceptance criteria: Check if all acceptance criteria are satisfied
- Adversarial Verification (If triggered via --review): Same as Phase 1-3 above
- Self-check review points: Check code review points
- Ask for submission: Use AskUserQuestion to ask
- If submit: Execute git add and commit
- Update status: Mark the task as completed
提交信息格式
Commit Message Format
遵循 规范,格式如下:
/commit-convention<type>(T-XX): <任务名称>
- <完成内容1>
- <完成内容2>
关联: F-XXX, AC-XXX
测试: UT-XXX, IT-XXX 通过type 类型:feat | fix | refactor | test | docs | chore
Follow the specification, with the following format:
/commit-convention<type>(T-XX): <Task Name>
- <Completed Item 1>
- <Completed Item 2>
Related: F-XXX, AC-XXX
Tests: UT-XXX, IT-XXX PassedType Values: feat | fix | refactor | test | docs | chore
参考资料
References
- skeleton-examples.md - 接口/测试骨架示例
- execution-flow.md - 任务执行流程详解
- verification-flow.md - 对抗式验证流程详解
- skeleton-examples.md - Interface/test skeleton examples
- execution-flow.md - Detailed task execution process
- verification-flow.md - Detailed adversarial verification process