@pzy560117/codex-harness 0.1.0 → 0.1.2

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

@@ -0,0 +1,125 @@
+---
+description: Generate a custom checklist for the current feature based on user requirements.
+---
+
+## Checklist Purpose: "Unit Tests for English"
+
+**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain.
+
+**NOT for verification/testing**:
+- ❌ NOT "Verify the button clicks correctly"
+- ❌ NOT "Test error handling works"
+- ❌ NOT "Confirm the API returns 200"
+
+**FOR requirements quality validation**:
+- ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
+- ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
+- ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
+- ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的说明、完成汇报全部使用简体中文。
+- 实际写入仓库的 checklist 文档必须使用简体中文。
+- 即使模板原文是英文，实际落盘时也要把标题、分类、检查项说明改写成中文。
+- 保留 `CHK001` 这类编号、路径、命令和必要技术名词原样不变。
+
+## Execution Steps
+
+1. **Setup**: Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+   - All file paths must be absolute.
+
+2. **Clarify intent (dynamic)**: Derive up to THREE initial contextual clarifying questions. They MUST:
+   - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
+   - Only ask about information that materially changes checklist content
+   - Be skipped individually if already unambiguous in `$ARGUMENTS`
+
+3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
+   - Derive checklist theme (e.g., security, review, deploy, ux)
+   - Consolidate explicit must-have items mentioned by user
+   - Map focus selections to category scaffolding
+
+4. **Load feature context**: Read from FEATURE_DIR:
+   - spec.md: Feature requirements and scope
+   - plan.md (if exists): Technical details, dependencies
+   - tasks.md (if exists): Implementation tasks
+
+5. **Generate checklist** - Create "Unit Tests for Requirements":
+   - Create `FEATURE_DIR/checklists/` directory if it doesn't exist
+   - Generate unique checklist filename (e.g., `ux.md`, `api.md`, `security.md`)
+   - Number items sequentially starting from CHK001
+
+   **Category Structure** - Group items by requirement quality dimensions:
+   - **Requirement Completeness** (Are all necessary requirements documented?)
+   - **Requirement Clarity** (Are requirements specific and unambiguous?)
+   - **Requirement Consistency** (Do requirements align without conflicts?)
+   - **Acceptance Criteria Quality** (Are success criteria measurable?)
+   - **Scenario Coverage** (Are all flows/cases addressed?)
+   - **Edge Case Coverage** (Are boundary conditions defined?)
+   - **Non-Functional Requirements** (Performance, Security, Accessibility specified?)
+   - **Dependencies & Assumptions** (Are they documented and validated?)
+   - **Ambiguities & Conflicts** (What needs clarification?)
+
+   **HOW TO WRITE CHECKLIST ITEMS**:
+
+   ❌ **WRONG** (Testing implementation):
+   - "Verify landing page displays 3 episode cards"
+   - "Test hover states work on desktop"
+
+   ✅ **CORRECT** (Testing requirements quality):
+   - "Are the exact number and layout of featured episodes specified?" [Completeness]
+   - "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity]
+   - "Are hover state requirements consistent across all interactive elements?" [Consistency]
+   - "Are keyboard navigation requirements defined for all interactive UI?" [Coverage]
+
+   **ITEM STRUCTURE**:
+   - Question format asking about requirement quality
+   - Focus on what's WRITTEN (or not written) in the spec/plan
+   - Include quality dimension in brackets [Completeness/Clarity/Consistency/etc.]
+   - Reference spec section `[Spec §X.Y]` when checking existing requirements
+   - Use `[Gap]` marker when checking for missing requirements
+
+   **Traceability Requirements**:
+   - MINIMUM: ≥80% of items MUST include at least one traceability reference
+
+   **🚫 ABSOLUTELY PROHIBITED**:
+   - ❌ Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior
+   - ❌ References to code execution, user actions, system behavior
+   - ❌ "Displays correctly", "works properly", "functions as expected"
+   - ❌ "Click", "navigate", "render", "load", "execute"
+
+   **✅ REQUIRED PATTERNS**:
+   - ✅ "Are [requirement type] defined/specified/documented for [scenario]?"
+   - ✅ "Is [vague term] quantified/clarified with specific criteria?"
+   - ✅ "Are requirements consistent between [section A] and [section B]?"
+   - ✅ "Can [requirement] be objectively measured/verified?"
+   - ✅ "Does the spec define [missing aspect]?"
+
+6. **Structure Reference**: Generate the checklist following the canonical template in `.agents/.specify/templates/checklist-template.md`
+
+7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file.
+
+## Example Checklist Types & Sample Items
+
+**UX Requirements Quality:** `ux.md`
+- "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]"
+- "Is the number and positioning of UI elements explicitly specified? [Completeness, Spec §FR-1]"
+- "Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]"
+
+**API Requirements Quality:** `api.md`
+- "Are error response formats specified for all failure scenarios? [Completeness]"
+- "Are rate limiting requirements quantified with specific thresholds? [Clarity]"
+- "Are authentication requirements consistent across all endpoints? [Consistency]"
+
+**Security Requirements Quality:** `security.md`
+- "Are authentication requirements specified for all protected resources? [Coverage]"
+- "Are data protection requirements defined for sensitive information? [Completeness]"
+- "Is the threat model documented and requirements aligned to it? [Traceability]"

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

@@ -0,0 +1,107 @@
+---
+description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的澄清问答、推荐选项、完成汇报全部使用简体中文。
+- 回写到 `spec.md` 的澄清内容必须使用简体中文。
+- 保留 `[NEEDS CLARIFICATION]`、需求编号、路径、命令等机器敏感标记原样不变。
+
+## Outline
+
+Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
+
+Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/speckit.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
+
+## Execution Steps
+
+1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
+   - `FEATURE_DIR`
+   - `FEATURE_SPEC`
+   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
+   - If JSON parsing fails, abort and instruct user to re-run `/speckit.specify` or verify feature branch environment.
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
+
+   **Taxonomy Categories:**
+   - Functional Scope & Behavior
+   - Domain & Data Model
+   - Interaction & UX Flow
+   - Page Inventory & State Coverage
+   - Requirement-to-Interface Traceability
+   - Upfront Difficulty Research
+   - 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
+
+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
+
+4. Sequential questioning loop (interactive):
+    - Present EXACTLY ONE question at a time.
+    - For multiple-choice questions: Present your **recommended option prominently** at the top with clear reasoning.
+    - Format as: `**Recommended:** Option [X] - <reasoning>`
+    - Then render all options as a Markdown table
+    - After the user answers: validate and record in working memory
+
+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
+
+6. Validation (performed after EACH write plus final pass):
+   - Clarifications session contains exactly one bullet per accepted answer
+   - Total asked (accepted) questions ≤ 5
+   - Markdown structure valid
+
+7. Write the updated spec back to `FEATURE_SPEC`.
+
+8. Report completion:
+   - Number of questions asked & answered
+   - Path to updated spec
+   - Sections touched
+   - Coverage summary table
+   - Suggested next command
+
+## Behavior Rules
+
+- If no meaningful ambiguities found, respond: "No critical ambiguities detected worth formal clarification."
+- If spec file missing, instruct user to run `/speckit.specify` first
+- Never exceed 5 total asked questions
+- Respect user early termination signals ("stop", "done", "proceed")
+
+## Next Steps
+
+- `/speckit.plan` - Create a plan for the spec

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

@@ -0,0 +1,82 @@
+---
+description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are updating the project constitution at `.agents/.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+Follow this execution flow:
+
+1. Load the existing constitution template at `.agents/.specify/memory/constitution.md`.
+   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2. Collect/derive values for placeholders:
+   - If user input (conversation) supplies a value, use it.
+   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+     - MAJOR: Backward incompatible governance/principle removals or redefinitions.
+     - MINOR: New principle/section added or materially expanded guidance.
+     - PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+   - If version bump type ambiguous, propose reasoning before finalizing.
+
+3. Draft the updated constitution content:
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non-negotiable rules, explicit rationale if not obvious.
+   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4. Consistency propagation checklist (convert prior checklist into active validations):
+   - Read `.agents/.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `.agents/.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `.agents/.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `.agents/.specify/templates/commands/*.md` (including this one) to verify no outdated references remain.
+   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
+
+5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
+   - Version change: old → new
+   - List of modified principles (old title → new title if renamed)
+   - Added sections
+   - Removed sections
+   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
+   - Follow-up TODOs if any placeholders intentionally deferred.
+
+6. Validation before final output:
+   - No remaining unexplained bracket tokens.
+   - Version line matches report.
+   - Dates ISO format YYYY-MM-DD.
+   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7. Write the completed constitution back to `.agents/.specify/memory/constitution.md` (overwrite).
+
+8. Output a final summary to the user with:
+   - New version and bump rationale.
+   - Any files flagged for manual follow-up.
+   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+## Formatting & Style Requirements
+
+- Use Markdown headings exactly as in the template (do not demote/promote levels).
+- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
+- Keep a single blank line between sections.
+- Avoid trailing whitespace.
+
+If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
+
+If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
+
+Do not create a new template; always operate on the existing `.agents/.specify/memory/constitution.md` file.
+
+## Next Steps
+
+- `/speckit.specify` - Implement the feature specification based on the updated constitution

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

@@ -0,0 +1,59 @@
+---
+description: Generate comprehensive Test Cases, Test Plan, and actionable Tasks for an OpenSpec feature, emphasizing zero-mock validation, exhaustive element traversal, and full CRUD loop testing.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+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.
+
+## 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.
+
+## Task Format Rules
+
+When generating tasks for `tasks.md`, you MUST strictly use the `speckit.tasks` format:
+
+```markdown
+- [ ] **T00X [P?] [USn?] 任务描述** <!-- id: XX -->
+  - 📋 **规格参考**: document.md → Section
+  - ✅ **验收标准**: 可验证的完成条件
+  - 📁 **关联文件**: 相关文件路径
+  - 📝 **执行内容**: 具体执行细节
+```
+
+**Example Output**:
+
+```markdown
+- [ ] **T021 [US1] 扫除本模块界面中的 Mock 数据引用** <!-- id: 51 -->
+  - 📋 **规格参考**: e2e-plan.md
+  - ✅ **验收标准**: 界面不再依赖 `src/mock` 假数据，切换为真实 API
+  - 📁 **修改文件**: `src/pages/user/UserListPage.vue`
+  - 📝 **执行内容**: 移除 Mock 拦截器或假数据，对接实际后端接口
+- [ ] **T022 [US1] 执行全面元素级与 CRUD 闭环 E2E 测试** <!-- id: 52 -->
+  - 📋 **规格参考**: e2e-plan.md → TC-1.1, TC-1.2
+  - ✅ **验收标准**: 所有设计的交互边界及 CRUD 闭环 100% 验证通过
+  - 📝 **执行内容**: 调用 `/browser-e2e-testing` 根据 `e2e-plan.md` 逐一执行用例
+```
+
+## Next Steps
+
+- Execute the overall feature and mock cleanup tasks via `/speckit.implement`.
+- Use `/browser-e2e-testing` to systematically run the E2E tests against the verified live environment.

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

@@ -0,0 +1,129 @@
+---
+description: Execute the implementation plan by processing tasks one boundary at a time instead of batch-finishing the whole feature.
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## 语言要求
+
+- 与用户的执行进展、验证结果、阻塞说明、完成汇报全部使用简体中文。
+- 如需回写 `tasks.md`、补充说明或更新当前 feature 文档，实际落盘内容必须使用简体中文。
+- 保留 `_Requirements: ..._`、任务 ID、HTML `<!-- id: XX -->`、路径、命令等机器敏感标记原样不变。
+
+## Outline
+
+1. Run `.agents/.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+
+2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
+   - Scan all checklist files in the checklists/ directory
+   - For each checklist, count:
+     - Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
+     - Completed items: Lines matching `- [X]` or `- [x]`
+     - Incomplete items: Lines matching `- [ ]`
+   - Create a status table:
+
+     | Checklist | Total | Completed | Incomplete | Status |
+     |-----------|-------|-----------|------------|--------|
+     | ux.md     | 12    | 12        | 0          | ✓ PASS |
+     | test.md   | 8     | 5         | 3          | ✗ FAIL |
+     | security.md | 6   | 6         | 0          | ✓ PASS |
+
+   - **If any checklist is incomplete**:
+     - Display the table with incomplete item counts
+     - **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
+     - Wait for user response before continuing
+
+   - **If all checklists are complete**:
+     - 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
+
+4. **Project Setup Verification**:
+   - **REQUIRED**: Create/verify ignore files based on actual project setup:
+
+   **Detection & Creation Logic**:
+   - Check if git repo exists → create/verify .gitignore
+   - Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
+   - Check if .eslintrc* exists → create/verify .eslintignore
+   - Check if eslint.config.* exists → ensure the config's `ignores` entries cover required patterns
+   - Check if .prettierrc* exists → create/verify .prettierignore
+   - Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
+   - Check if terraform files (*.tf) exist → create/verify .terraformignore
+
+   **Common Patterns by Technology** (from plan.md tech stack):
+   - **Node.js/JavaScript/TypeScript**: `node_modules/`, `dist/`, `build/`, `*.log`, `.env*`
+   - **Python**: `__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/`
+   - **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**
+
+6. **单任务执行循环** (一次只完成一个任务边界):
+
+   **6.1 子任务分析阶段** (进入新子任务前必须执行):
+   - 从 tasks.md 读取当前唯一要执行的子任务
+   - 分析该任务的具体要求、输入输出、依赖关系
+   - 识别该任务需要修改/创建的文件列表
+   - 确认技术方案和实现思路
+   - **输出**: 简洁的单任务分析摘要（2-3行）
+
+   **6.2 子任务实现阶段**:
+   - 按分析结果执行具体实现
+   - 遵循 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
+
+8. Implementation execution rules:
+   - **Setup first**: Initialize project structure, dependencies, configuration
+   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
+   - **Core development**: Implement models, services, CLI commands, endpoints
+   - **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
+
+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.