@pzy560117/codex-harness 0.1.3 → 0.1.4

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/speckit.analyze.md

@@ -8,13 +8,13 @@ description: Perform a non-destructive cross-artifact consistency and quality an
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 输出给用户的分析报告必须使用简体中文。
-- 报告中的表格标题、问题描述、修复建议、后续命令建议全部使用简体中文。
-- 保留需求编号、任务 ID、路径、命令、协议名等技术标识原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 输出给用户的分析报告必须使用简体中文。
+- 报告中的表格标题、问题描述、修复建议、后续命令建议全部使用简体中文。
+- 保留需求编号、任务 ID、路径、命令、协议名等技术标识原样不变。
 
 ## Goal
 
@@ -42,31 +42,31 @@ Abort with an error message if any required file is missing.
 
 Load only the minimal necessary context from each artifact:
 
-**From spec.md:**
-- Overview/Context
-- Delivery mode / integration boundary
-- Functional Requirements
-- Non-Functional Requirements
-- User Stories
-- Edge Cases (if present)
-
-**From plan.md:**
-- Delivery mode gate
-- OSS reuse matrix
-- Integration blockers & evidence
-- Connector / adapter strategy
-- Architecture/stack choices
-- Data Model references
-- Phases
-- Technical constraints
-
-**From tasks.md:**
-- Task IDs
-- Descriptions
-- Phase grouping
-- Parallel markers [P]
-- Delivery attributes, blockers, evidence paths, verification layers
-- Referenced file paths
+**From spec.md:**
+- Overview/Context
+- Delivery mode / integration boundary
+- Functional Requirements
+- Non-Functional Requirements
+- User Stories
+- Edge Cases (if present)
+
+**From plan.md:**
+- Delivery mode gate
+- OSS reuse matrix
+- Integration blockers & evidence
+- Connector / adapter strategy
+- Architecture/stack choices
+- Data Model references
+- Phases
+- Technical constraints
+
+**From tasks.md:**
+- Task IDs
+- Descriptions
+- Phase grouping
+- Parallel markers [P]
+- Delivery attributes, blockers, evidence paths, verification layers
+- Referenced file paths
 
 **From constitution:**
 - Load `.agents/.specify/memory/constitution.md` for principle validation
@@ -86,26 +86,26 @@ Focus on high-signal findings. Limit to 50 findings total.
 - **A. Duplication Detection**: Identify near-duplicate requirements
 - **B. Ambiguity Detection**: Flag vague adjectives lacking measurable criteria
 - **C. Underspecification**: Requirements with verbs but missing object or measurable outcome
-- **D. Constitution Alignment**: Any requirement or plan element conflicting with a MUST principle
-- **E. Coverage Gaps**: Requirements with zero associated tasks
-- **F. Inconsistency**: Terminology drift, conflicting requirements
-- **G. Delivery Mode Drift**: Prototype/spike deliverables masquerading as completed formal `FR-*`
-- **H. Integration Downgrade**: Requirements tied to predefined OSS/external systems but implemented only as local mock/sample without explicit downgrade note
-- **I. Reuse Matrix Gap**: Missing or incomplete OSS reuse matrix rows for predefined stack / external systems
-- **J. Blocker Gate Failure**: Related `TBD-*` still open while tasks try to close the linked requirement
-- **K. Ordering Risk**: UI/BFF tasks are planned ahead of environment evidence, real connector, or integration-prep tasks they depend on
-- **L. Task Compression Risk**: A story or feature is represented by a single oversized task that spans blockers/evidence, connector work, bridge logic, API/BFF, UI, and final verification, hiding progress and making stop-hook continuation ineffective
+- **D. Constitution Alignment**: Any requirement or plan element conflicting with a MUST principle
+- **E. Coverage Gaps**: Requirements with zero associated tasks
+- **F. Inconsistency**: Terminology drift, conflicting requirements
+- **G. Delivery Mode Drift**: Prototype/spike deliverables masquerading as completed formal `FR-*`
+- **H. Integration Downgrade**: Requirements tied to predefined OSS/external systems but implemented only as local mock/sample without explicit downgrade note
+- **I. Reuse Matrix Gap**: Missing or incomplete OSS reuse matrix rows for predefined stack / external systems
+- **J. Blocker Gate Failure**: Related `TBD-*` still open while tasks try to close the linked requirement
+- **K. Ordering Risk**: UI/BFF tasks are planned ahead of environment evidence, real connector, or integration-prep tasks they depend on
+- **L. Task Compression Risk**: A story or feature is represented by a single oversized task that spans blockers/evidence, connector work, bridge logic, API/BFF, UI, and final verification, hiding progress and making stop-hook continuation ineffective
 
 ### 5. Severity Assignment
 
-- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or open integration blocker falsely treated as complete
-- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, or a single oversized integration task that hides multiple execution layers
-- **MEDIUM**: Terminology drift, missing non-functional task coverage, or missing explicit downgrade record
-- **LOW**: Style/wording improvements, minor redundancy
+- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or open integration blocker falsely treated as complete
+- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, or a single oversized integration task that hides multiple execution layers
+- **MEDIUM**: Terminology drift, missing non-functional task coverage, or missing explicit downgrade record
+- **LOW**: Style/wording improvements, minor redundancy
 
 ### 6. Produce Compact Analysis Report
 
-Output a Markdown report in Simplified Chinese (no file writes) with:
+Output a Markdown report in Simplified Chinese (no file writes) with:
 
 | ID | Category | Severity | Location(s) | Summary | Recommendation |
 |----|----------|----------|-------------|---------|----------------|
@@ -119,23 +119,23 @@ Output a Markdown report in Simplified Chinese (no file writes) with:
 
 **Unmapped Tasks:** (if any)
 
-**Metrics:**
-- Total Requirements
-- Total Tasks
-- Coverage % (requirements with >=1 task)
-- Integration Requirements Count
-- Open `TBD-*` Count
-- Compressed Story Count
-- Ambiguity Count
-- Duplication Count
-- Critical Issues Count
+**Metrics:**
+- Total Requirements
+- Total Tasks
+- Coverage % (requirements with >=1 task)
+- Integration Requirements Count
+- Open `TBD-*` Count
+- Compressed Story Count
+- Ambiguity Count
+- Duplication Count
+- Critical Issues Count
 
 ### 7. Provide Next Actions
 
-- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
-- If Task Compression Risk exists: Recommend splitting the affected task into 4-6 acceptance-sized tasks before `/speckit.implement`
-- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions
+- If CRITICAL issues exist: Recommend resolving before `/speckit.implement`
+- If Task Compression Risk exists: Recommend splitting the affected task into 4-6 acceptance-sized tasks before `/speckit.implement`
+- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
+- Provide explicit command suggestions
 
 ### 8. Offer Remediation
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/speckit.checklist.md

@@ -23,14 +23,14 @@ description: Generate a custom checklist for the current feature based on user r
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的说明、完成汇报全部使用简体中文。
-- 实际写入仓库的 checklist 文档必须使用简体中文。
-- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
-- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的说明、完成汇报全部使用简体中文。
+- 实际写入仓库的 checklist 文档必须使用简体中文。
+- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
+- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
 
 ## Execution Steps
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/speckit.clarify.md

@@ -8,13 +8,13 @@ description: Identify underspecified areas in the current feature spec by asking
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
-- 回写到 `spec.md` 的澄清内容必须使用简体中文。
-- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
+- 回写到 `spec.md` 的澄清内容必须使用简体中文。
+- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
 
 ## Outline
 
@@ -43,27 +43,27 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i
    - Roles & Permissions
    - Non-Functional Quality Attributes
    - Integration & External Dependencies
-   - Edge Cases & Failure Handling
-   - Acceptance Criteria & Success Metrics
-   - Testability & Acceptance Evidence
-   - Required Test Data
-   - Evidence Paths & Observable Oracles
-   - Baseline / Affected Test Expectations
-   - Constraints & Tradeoffs
-   - Terminology & Consistency
-   - Completion Signals
-   - Misc / Placeholders
+   - Edge Cases & Failure Handling
+   - Acceptance Criteria & Success Metrics
+   - Testability & Acceptance Evidence
+   - Required Test Data
+   - Evidence Paths & Observable Oracles
+   - Baseline / Affected Test Expectations
+   - Constraints & Tradeoffs
+   - Terminology & Consistency
+   - Completion Signals
+   - Misc / Placeholders
 
 3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
     - Maximum of 10 total questions across the whole session.
     - Each question must be answerable with EITHER:
        - A short multiple-choice selection (2–5 distinct, mutually exclusive options), OR
        - A one-word / short-phrase answer (explicitly constrain: "Answer in <=5 words").
-    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
-    - Prioritize questions that unblock verification: missing environment, endpoint, RBAC, dashboard/panel ID, webhook target, fixture, credential, acceptance oracle, evidence path, or delivery-mode downgrade.
-    - If a P0/P1 requirement cannot be objectively verified, ask about verification before asking lower-impact UX or implementation-preference questions.
-    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first
-    - Never exceed 5 total asked questions
+    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
+    - Prioritize questions that unblock verification: missing environment, endpoint, RBAC, dashboard/panel ID, webhook target, fixture, credential, acceptance oracle, evidence path, or delivery-mode downgrade.
+    - If a P0/P1 requirement cannot be objectively verified, ask about verification before asking lower-impact UX or implementation-preference questions.
+    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first
+    - Never exceed 5 total asked questions
 
 4. Sequential questioning loop (interactive):
     - Present EXACTLY ONE question at a time.
@@ -74,12 +74,12 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i
 
 5. Integration after EACH accepted answer (incremental update approach):
     - Maintain in-memory representation of the spec
-    - Ensure a `## 澄清记录` section exists
-    - Append a bullet line in Chinese: `- 问：<问题> → 答：<最终答案>`
-    - Apply the clarification to the most appropriate section(s)
-    - If the answer changes testability, update `Testability & Acceptance Evidence`, `External Dependency Preconditions`, or the relevant acceptance scenario in the spec
-    - If the answer confirms a blocker, add or update a linked `TBD-*` / `TBD-TEST-*` item instead of silently treating the requirement as implementation-ready
-    - Save the spec file AFTER each integration
+    - Ensure a `## 澄清记录` section exists
+    - Append a bullet line in Chinese: `- 问：<问题> → 答：<最终答案>`
+    - Apply the clarification to the most appropriate section(s)
+    - If the answer changes testability, update `Testability & Acceptance Evidence`, `External Dependency Preconditions`, or the relevant acceptance scenario in the spec
+    - If the answer confirms a blocker, add or update a linked `TBD-*` / `TBD-TEST-*` item instead of silently treating the requirement as implementation-ready
+    - Save the spec file AFTER each integration
 
 6. Validation (performed after EACH write plus final pass):
    - Clarifications session contains exactly one bullet per accepted answer

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/speckit.e2e-testing.md

@@ -13,19 +13,19 @@ You **MUST** consider the user input before proceeding (if not empty).
 ## Context & Objectives
 
 This workflow analyzes the current frontend interface, meticulously examines code for mocked data, and generates a robust E2E test plan (`e2e-plan.md`) along with standard OpenSpec tasks in `tasks.md`. By generating E2E test cases during the OpenSpec Planning phase (Test-Left), you ensure that:
-1. **Zero-Mock Assurance**: No frontend interfaces rely on fake or mocked data; everything connects to real backend APIs.
-2. **Code-Intelligence First**: Start from `docs/ai/repo-map.md` or equivalent codemap when present, so page discovery and impact analysis are bounded by known entry points.
-3. **Exhaustive Coverage**: Every single interactive UI element (buttons, inputs, dropdowns) is mapped out and verified.
-4. **CRUD Reliability**: Core business entities seamlessly undergo Create, Read, Update, and Delete testing sequences without breakage.
+1. **Zero-Mock Assurance**: No frontend interfaces rely on fake or mocked data; everything connects to real backend APIs.
+2. **Code-Intelligence First**: Start from `docs/ai/repo-map.md` or equivalent codemap when present, so page discovery and impact analysis are bounded by known entry points.
+3. **Exhaustive Coverage**: Every single interactive UI element (buttons, inputs, dropdowns) is mapped out and verified.
+4. **CRUD Reliability**: Core business entities seamlessly undergo Create, Read, Update, and Delete testing sequences without breakage.
 
 ## Outline
 
-1. **Context & Mock Extraction**: Read `docs/ai/repo-map.md` or equivalent codemap when present, then inspect the frontend views (`src/pages`, `src/views`) identified by the feature spec. Rigorously check for mocked data or hardcoded dependencies. Flag these for mandatory cleanup.
-2. **Element Traversal Analysis**: Iterate across all extracted interactive UI elements. Generate dedicated natural language `browser-subagent` commands to test bounds and interactions.
-3. **CRUD Sequence Design**: Construct a cohesive execution sequence connecting Create -> Read -> Update -> Delete scenarios to validate the full business lifecycle.
-4. **Plan Output (`e2e-plan.md`)**: Produce an `e2e-plan.md` detailing code entry points, impact scope, exhaustive test cases, and the 10 dimensions of E2E verification.
-5. **Task Population (`tasks.md`)**: Append testing tasks into your `tasks.md`. Include an explicit task to clean up mock references, and a task to execute the E2E suites.
-6. **Failure Handling**: If later execution fails, classify the failure first as `TEST_CODE_ISSUE`, `PRODUCT_BUG`, `REQUIREMENT_CHANGE`, `ENV_OR_DATA_ISSUE`, or `FLAKY` before selecting the repair path.
+1. **Context & Mock Extraction**: Read `docs/ai/repo-map.md` or equivalent codemap when present, then inspect the frontend views (`src/pages`, `src/views`) identified by the feature spec. Rigorously check for mocked data or hardcoded dependencies. Flag these for mandatory cleanup.
+2. **Element Traversal Analysis**: Iterate across all extracted interactive UI elements. Generate dedicated natural language `browser-subagent` commands to test bounds and interactions.
+3. **CRUD Sequence Design**: Construct a cohesive execution sequence connecting Create -> Read -> Update -> Delete scenarios to validate the full business lifecycle.
+4. **Plan Output (`e2e-plan.md`)**: Produce an `e2e-plan.md` detailing code entry points, impact scope, exhaustive test cases, and the 10 dimensions of E2E verification.
+5. **Task Population (`tasks.md`)**: Append testing tasks into your `tasks.md`. Include an explicit task to clean up mock references, and a task to execute the E2E suites.
+6. **Failure Handling**: If later execution fails, classify the failure first as `TEST_CODE_ISSUE`, `PRODUCT_BUG`, `REQUIREMENT_CHANGE`, `ENV_OR_DATA_ISSUE`, or `FLAKY` before selecting the repair path.
 
 ## Task Format Rules
 

package/package-source/docs/codex-harness-engineering/templates/package-assets/workflows/speckit.implement.md

@@ -1,5 +1,5 @@
 ---
-description: Execute the implementation plan by processing tasks one boundary at a time instead of batch-finishing the whole feature.
+description: Execute the implementation plan by processing tasks one boundary at a time instead of batch-finishing the whole feature.
 ---
 
 ## User Input
@@ -8,13 +8,13 @@ description: Execute the implementation plan by processing tasks one boundary at
 $ARGUMENTS
 ```
 
-You **MUST** consider the user input before proceeding (if not empty).
-
-## 语言要求
-
-- 与用户的执行进展、验证结果、阻塞说明、完成汇报全部使用简体中文。
-- 如需回写 `tasks.md`、补充说明或更新当前 feature 文档，实际落盘内容必须使用简体中文。
-- 保留 `_Requirements: ..._`、任务 ID、HTML `<!-- id: XX -->`、路径、命令等机器敏感标记原样不变。
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的执行进展、验证结果、阻塞说明、完成汇报全部使用简体中文。
+- 如需回写 `tasks.md`、补充说明或更新当前 feature 文档，实际落盘内容必须使用简体中文。
+- 保留 `_Requirements: ..._`、任务 ID、HTML `<!-- id: XX -->`、路径、命令等机器敏感标记原样不变。
 
 ## Outline
 
@@ -43,12 +43,12 @@ You **MUST** consider the user input before proceeding (if not empty).
      - Display the table showing all checklists passed
      - Automatically proceed to step 3
 
-3. Load and analyze the implementation context progressively:
-   - **REQUIRED**: Read tasks.md only far enough to locate the current open task boundary
-   - **REQUIRED**: Read plan.md only for the sections directly referenced by the current task
-   - **IF NEEDED**: Read spec.md for the requirement or user story directly referenced by the current task
-   - **IF EXISTS AND CURRENT TASK NEEDS IT**: Read data-model.md, contracts/, research.md, quickstart.md
-   - Do **not** bulk-read the entire feature directory or attempt to plan every remaining task in one pass
+3. Load and analyze the implementation context progressively:
+   - **REQUIRED**: Read tasks.md only far enough to locate the current open task boundary
+   - **REQUIRED**: Read plan.md only for the sections directly referenced by the current task
+   - **IF NEEDED**: Read spec.md for the requirement or user story directly referenced by the current task
+   - **IF EXISTS AND CURRENT TASK NEEDS IT**: Read data-model.md, contracts/, research.md, quickstart.md
+   - Do **not** bulk-read the entire feature directory or attempt to plan every remaining task in one pass
 
 4. **Project Setup Verification**:
    - **REQUIRED**: Create/verify ignore files based on actual project setup:
@@ -68,41 +68,41 @@ You **MUST** consider the user input before proceeding (if not empty).
    - **Java**: `target/`, `*.class`, `*.jar`, `.gradle/`, `build/`
    - **Universal**: `.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/`
 
-5. Parse tasks.md structure and extract only the current execution slice:
-   - **Current task phase**
-   - **Current task dependencies**
-   - **Current task details**: ID, description, file paths, parallel markers [P]
-   - **Next immediate task only after the current one is complete**
+5. Parse tasks.md structure and extract only the current execution slice:
+   - **Current task phase**
+   - **Current task dependencies**
+   - **Current task details**: ID, description, file paths, parallel markers [P]
+   - **Next immediate task only after the current one is complete**
 
-6. **单任务执行循环** (一次只完成一个任务边界):
+6. **单任务执行循环** (一次只完成一个任务边界):
 
    **6.1 子任务分析阶段** (进入新子任务前必须执行):
-   - 从 tasks.md 读取当前唯一要执行的子任务
-   - 分析该任务的具体要求、输入输出、依赖关系
-   - 识别该任务需要修改/创建的文件列表
-   - 确认技术方案和实现思路
-   - **输出**: 简洁的单任务分析摘要（2-3行）
+   - 从 tasks.md 读取当前唯一要执行的子任务
+   - 分析该任务的具体要求、输入输出、依赖关系
+   - 识别该任务需要修改/创建的文件列表
+   - 确认技术方案和实现思路
+   - **输出**: 简洁的单任务分析摘要（2-3行）
 
    **6.2 子任务实现阶段**:
-   - 按分析结果执行具体实现
-   - 遵循 TDD：先写测试再写实现（如适用）
-   - 确保代码符合项目规范和设计文档
+   - 按分析结果执行具体实现
+   - 遵循 TDD：先写测试再写实现（如适用）
+   - 确保代码符合项目规范和设计文档
 
    **6.3 子任务完成更新** (完成后立即执行):
-   - **立即**将 tasks.md 中对应任务标记为 `[X]`
-   - 记录完成时间和关键产出（如新增文件路径）
-   - 验证该任务产出符合预期
-
-   **6.4 进入下一个子任务**:
-   - 当前轮次默认到此结束
-   - 只有在明确需要续跑时，再返回步骤 6.1 分析下一个未完成任务
-
-7. Execute implementation following the task plan:
-   - **Task-boundary execution**: Default to one task per round, not the whole phase at once
-   - **Respect dependencies**: Run sequential tasks in order; do not preemptively finish later tasks
-   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
-   - **File-based coordination**: Tasks affecting the same files must run sequentially
-   - **Validation checkpoints**: Verify the current task before touching the next one
+   - **立即**将 tasks.md 中对应任务标记为 `[X]`
+   - 记录完成时间和关键产出（如新增文件路径）
+   - 验证该任务产出符合预期
+
+   **6.4 进入下一个子任务**:
+   - 当前轮次默认到此结束
+   - 只有在明确需要续跑时，再返回步骤 6.1 分析下一个未完成任务
+
+7. Execute implementation following the task plan:
+   - **Task-boundary execution**: Default to one task per round, not the whole phase at once
+   - **Respect dependencies**: Run sequential tasks in order; do not preemptively finish later tasks
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify the current task before touching the next one
 
 8. Implementation execution rules:
    - **Setup first**: Initialize project structure, dependencies, configuration
@@ -111,19 +111,19 @@ You **MUST** consider the user input before proceeding (if not empty).
    - **Integration work**: Database connections, middleware, logging, external services
    - **Polish and validation**: Unit tests, performance optimization, documentation
 
-9. Progress tracking and error handling:
-   - Report progress after each completed task
-   - Halt execution if any non-parallel task fails
-   - For parallel tasks [P], continue with successful tasks, report failed ones
-   - Provide clear error messages with context for debugging
-   - Suggest next steps if implementation cannot proceed
-   - **CRITICAL**: 每个任务完成后必须立即更新 tasks.md，不要批量更新，更不要一次性勾完多个任务
-
-10. Completion validation:
-   - Verify the current task is completed and correctly tracked
-   - Check that the current task matches the original specification
-   - Validate that tests for the current task pass and coverage meets requirements
-   - Confirm the current task follows the technical plan
-   - Report status with summary of the current task boundary and the next suggested task
+9. Progress tracking and error handling:
+   - Report progress after each completed task
+   - Halt execution if any non-parallel task fails
+   - For parallel tasks [P], continue with successful tasks, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **CRITICAL**: 每个任务完成后必须立即更新 tasks.md，不要批量更新，更不要一次性勾完多个任务
+
+10. Completion validation:
+   - Verify the current task is completed and correctly tracked
+   - Check that the current task matches the original specification
+   - Validate that tests for the current task pass and coverage meets requirements
+   - Confirm the current task follows the technical plan
+   - Report status with summary of the current task boundary and the next suggested task
 
 Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/speckit.tasks` first to regenerate the task list.