@benbenwu/zcf 3.6.4

package/templates/common/workflow/git/zh-CN/git-rollback.md

@@ -0,0 +1,90 @@
+---
+description: 交互式回滚 Git 分支到历史版本；列分支、列版本、二次确认后执行 reset / revert
+allowed-tools: Read(**), Exec(git fetch, git branch, git tag, git log, git reflog, git checkout, git reset, git revert, git switch), Write()
+argument-hint: [--branch <branch>] [--target <rev>] [--mode reset|revert] [--depth <n>] [--dry-run] [--yes]
+# examples:
+#   - /git-rollback                # 全交互模式，dry‑run
+#   - /git-rollback --branch dev   # 直接选 dev，其他交互
+#   - /git-rollback --branch dev --target v1.2.0 --mode reset --yes
+---
+
+# Claude Command: Git Rollback
+
+**目的**：安全、可视地将指定分支回滚到旧版本。
+默认处于 **只读预览 (`--dry-run`)**；真正执行需加 `--yes` 或在交互中确认。
+
+---
+
+## Usage
+
+```bash
+# 纯交互：列出分支 → 选分支 → 列最近 20 个版本 → 选目标 → 选择 reset 或 revert → 二次确认
+/git-rollback
+
+# 指定分支，其他交互
+/git-rollback --branch feature/calculator
+
+# 指定分支与目标 commit，并用 hard‑reset 一键执行（危险）
+/git-rollback --branch main --target 1a2b3c4d --mode reset --yes
+
+# 只想生成 revert 提交（非破坏式回滚），预览即可
+/git-rollback --branch release/v2.1 --target v2.0.5 --mode revert --dry-run
+```
+
+### Options
+
+| 选项                   | 说明                                                                               |
+| ---------------------- | ---------------------------------------------------------------------------------- |
+| `--branch <branch>`    | 要回滚的分支；缺省时交互选择。                                                     |
+| `--target <rev>`       | 目标版本（commit Hash、Tag、reflog 引用都行）；缺省时交互选择近 `--depth` 条记录。 |
+| `--mode reset\|revert` | `reset`：硬回滚历史；`revert`：生成反向提交保持历史完整。默认询问。                |
+| `--depth <n>`          | 在交互模式下列出最近 n 个版本（默认 20）。                                         |
+| `--dry-run`            | **默认开启**，只预览即将执行的命令。                                               |
+| `--yes`                | 跳过所有确认直接执行，适合 CI/CD 脚本。                                            |
+
+---
+
+## 交互流程
+
+1. **同步远端** → `git fetch --all --prune`
+2. **列分支** → `git branch -a`（本地＋远端，过滤受保护分支）
+3. **选分支** → 用户输入或传参
+4. **列版本** → `git log --oneline -n <depth>` + `git tag --merged` + `git reflog -n <depth>`
+5. **选目标** → 用户输入 commit hash / tag
+6. **选模式** → `reset` 或 `revert`
+7. **最终确认** （除非 `--yes`）
+8. **执行回滚**
+   - `reset`：`git switch <branch> && git reset --hard <target>`
+   - `revert`：`git switch <branch> && git revert --no-edit <target>..HEAD`
+9. **推送建议** → 提示是否 `git push --force-with-lease`（reset）或普通 `git push`（revert）
+
+---
+
+## 安全护栏
+
+- **备份**：执行前自动在 reflog 中记录当前 HEAD，可用 `git switch -c backup/<timestamp>` 恢复。
+- **保护分支**：如检测到 `main` / `master` / `production` 等受保护分支且开启 `reset` 模式，将要求额外确认。
+- **--dry-run 默认开启**：防止误操作。
+- **--force 禁止**：不提供 `--force`；如需强推，请手动输入 `git push --force-with-lease`。
+
+---
+
+## 适用场景示例
+
+| 场景                                            | 调用示例                                                         |
+| ----------------------------------------------- | ---------------------------------------------------------------- |
+| 热修补丁上线后发现 bug，需要回到 Tag `v1.2.0`   | `/git-rollback --branch release/v1 --target v1.2.0 --mode reset` |
+| 运维同事误推了 debug 日志提交，需要生成反向提交 | `/git-rollback --branch main --target 3f2e7c9 --mode revert`     |
+| 调研历史 bug，引导新人浏览分支历史              | `/git-rollback` （全交互，dry‑run）                              |
+
+---
+
+## 注意
+
+1. **reset vs revert**
+   - **reset** 会改变历史，需要强推并可能影响其他协作者，谨慎使用。
+   - **revert** 更安全，生成新提交保留历史，但会增加一次记录。
+2. **嵌入式仓库** 常有大体积二进制文件；回滚前请确保 LFS/子模块状态一致。
+3. 若仓库启用了 CI 强制校验，回滚后可能自动触发流水线；确认管控策略以免误部署旧版本。
+
+---

package/templates/common/workflow/git/zh-CN/git-worktree.md

@@ -0,0 +1,276 @@
+---
+description: 管理 Git worktree，在项目平级的 ../.zcf/项目名/ 目录下创建，支持智能默认、IDE 集成和内容迁移
+allowed-tools: Read(**), Exec(git worktree add, git worktree list, git worktree remove, git worktree prune, git branch, git checkout, git rev-parse, git stash, git cp, detect-ide, open-ide, which, command, basename, dirname)
+argument-hint: <add|list|remove|prune|migrate> [path] [-b <branch>] [-o|--open] [--track] [--guess-remote] [--detach] [--checkout] [--lock] [--migrate-from <source-path>] [--migrate-stash]
+# examples:
+#   - /git-worktree add feature-ui                     # 从 main/master 创建新分支 'feature-ui'
+#   - /git-worktree add feature-ui -o                  # 创建 worktree 并直接用 IDE 打开
+#   - /git-worktree add hotfix -b fix/login -o         # 创建新分支 'fix/login'，路径为 'hotfix'
+#   - /git-worktree migrate feature-ui --from main     # 将主分支未提交内容迁移到 feature-ui
+#   - /git-worktree migrate feature-ui --stash         # 将当前 stash 迁移到 feature-ui
+---
+
+# Claude Command: Git Worktree
+
+管理 Git worktree，支持智能默认、IDE 集成和内容迁移，使用结构化的 `../.zcf/项目名/` 路径。
+
+直接执行命令并提供简洁结果。
+
+---
+
+## Usage
+
+```bash
+# 基本操作
+/git-worktree add <path>                           # 从 main/master 创建名为 <path> 的新分支
+/git-worktree add <path> -b <branch>               # 创建指定名称的新分支
+/git-worktree add <path> -o                        # 创建并直接用 IDE 打开
+/git-worktree list                                 # 显示所有 worktree 状态
+/git-worktree remove <path>                        # 删除指定的 worktree
+/git-worktree prune                                # 清理无效 worktree 记录
+
+# 内容迁移
+/git-worktree migrate <target> --from <source>     # 迁移未提交内容
+/git-worktree migrate <target> --stash             # 迁移 stash 内容
+```
+
+### Options
+
+| 选项               | 说明                                         |
+| ------------------ | -------------------------------------------- |
+| `add [<path>]`     | 在 `../.zcf/项目名/<path>` 添加新的 worktree |
+| `migrate <target>` | 迁移内容到指定 worktree                      |
+| `list`             | 列出所有 worktree 及其状态                   |
+| `remove <path>`    | 删除指定路径的 worktree                      |
+| `prune`            | 清理无效的 worktree 引用                     |
+| `-b <branch>`      | 创建新分支并检出到 worktree                  |
+| `-o, --open`       | 创建成功后直接用 IDE 打开（跳过询问）        |
+| `--from <source>`  | 指定迁移源路径（migrate 专用）               |
+| `--stash`          | 迁移当前 stash 内容（migrate 专用）          |
+| `--track`          | 设置新分支跟踪对应的远程分支                 |
+| `--guess-remote`   | 自动猜测远程分支进行跟踪                     |
+| `--detach`         | 创建分离 HEAD 的 worktree                    |
+| `--checkout`       | 创建后立即检出（默认行为）                   |
+| `--lock`           | 创建后锁定 worktree                          |
+
+---
+
+## What This Command Does
+
+1. **环境检查**
+   - 通过 `git rev-parse --is-inside-work-tree` 验证 Git 仓库
+   - 检测是否在主仓库或现有 worktree 中，进行智能路径计算
+
+2. **智能路径管理**
+   - 使用 worktree 检测自动从主仓库路径计算项目名
+   - 在结构化的 `../.zcf/项目名/<path>` 目录创建 worktree
+   - 正确处理主仓库和 worktree 执行上下文
+
+```bash
+# worktree 检测的核心路径计算逻辑
+get_main_repo_path() {
+  local git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
+  local current_toplevel=$(git rev-parse --show-toplevel 2>/dev/null)
+
+  # 检测是否在 worktree 中
+  if [[ "$git_common_dir" != "$current_toplevel/.git" ]]; then
+    # 在 worktree 中，从 git-common-dir 推导主仓库路径
+    dirname "$git_common_dir"
+  else
+    # 在主仓库中
+    echo "$current_toplevel"
+  fi
+}
+
+MAIN_REPO_PATH=$(get_main_repo_path)
+PROJECT_NAME=$(basename "$MAIN_REPO_PATH")
+WORKTREE_BASE="$MAIN_REPO_PATH/../.zcf/$PROJECT_NAME"
+
+# 始终使用绝对路径防止嵌套问题
+ABSOLUTE_WORKTREE_PATH="$WORKTREE_BASE/<path>"
+```
+
+**关键修复**: 在现有 worktree 内创建新 worktree 时，始终使用绝对路径以防止出现类似 `../.zcf/project/.zcf/project/path` 的路径嵌套问题。
+
+3. **Worktree 操作**
+   - **add**: 使用智能分支/路径默认创建新 worktree
+   - **list**: 显示所有 worktree 的分支和状态
+   - **remove**: 安全删除 worktree 并清理引用
+   - **prune**: 清理孤立的 worktree 记录
+
+4. **智能默认**
+   - **分支创建**: 未指定 `-b` 时，使用路径名创建新分支
+   - **基础分支**: 新分支从 main/master 分支创建
+   - **路径解析**: 未指定路径时使用分支名作为路径
+   - **IDE 集成**: 自动检测并提示 IDE 打开
+
+5. **内容迁移**
+   - 在 worktree 之间迁移未提交改动
+   - 将 stash 内容应用到目标 worktree
+   - 安全检查防止冲突
+
+6. **安全特性**
+   - **路径冲突防护**: 创建前检查目录是否已存在
+   - **分支检出验证**: 确保分支未被其他地方使用
+   - **绝对路径强制**: 防止在 worktree 内创建嵌套的 `.zcf` 目录
+   - **删除时自动清理**: 同时清理目录和 git 引用
+   - **清晰的状态报告**: 显示 worktree 位置和分支状态
+
+7. **环境文件处理**
+   - **自动检测**: 扫描 `.gitignore` 文件中的环境变量文件模式
+   - **智能复制**: 复制 `.gitignore` 中列出的 `.env` 和 `.env.*` 文件
+   - **排除逻辑**: 跳过 `.env.example` 等模板文件
+   - **权限保护**: 保持原始文件权限和时间戳
+   - **用户反馈**: 提供已复制环境文件的清晰状态信息
+
+```bash
+# 环境文件复制实现
+copy_environment_files() {
+    local main_repo="$MAIN_REPO_PATH"
+    local target_worktree="$ABSOLUTE_WORKTREE_PATH"
+    local gitignore_file="$main_repo/.gitignore"
+    
+    # 检查 .gitignore 是否存在
+    if [[ ! -f "$gitignore_file" ]]; then
+        return 0
+    fi
+    
+    local copied_count=0
+    
+    # 检测 .env 文件
+    if [[ -f "$main_repo/.env" ]] && grep -q "^\.env$" "$gitignore_file"; then
+        cp "$main_repo/.env" "$target_worktree/.env"
+        echo "✅ 已复制 .env"
+        ((copied_count++))
+    fi
+    
+    # 检测 .env.* 模式文件（排除 .env.example）
+    for env_file in "$main_repo"/.env.*; do
+        if [[ -f "$env_file" ]] && [[ "$(basename "$env_file")" != ".env.example" ]]; then
+            local filename=$(basename "$env_file")
+            if grep -q "^\.env\.\*$" "$gitignore_file"; then
+                cp "$env_file" "$target_worktree/$filename"
+                echo "✅ 已复制 $filename"
+                ((copied_count++))
+            fi
+        fi
+    done
+    
+    if [[ $copied_count -gt 0 ]]; then
+        echo "📋 已从 .gitignore 复制 $copied_count 个环境文件"
+    fi
+}
+```
+
+---
+
+## Enhanced Features
+
+### IDE 集成
+
+- **自动检测**: VS Code → Cursor → WebStorm → Sublime Text → Vim
+- **智能提示**: 创建 worktree 后询问是否在 IDE 中打开
+- **直接打开**: 使用 `-o` 标志跳过提示直接打开
+- **自定义配置**: 通过 git config 配置
+
+### 内容迁移系统
+
+```bash
+# 迁移未提交改动
+/git-worktree migrate feature-ui --from main
+/git-worktree migrate hotfix --from ../other-worktree
+
+# 迁移 stash 内容
+/git-worktree migrate feature-ui --stash
+```
+
+**迁移流程**:
+
+1. 验证源有未提交内容
+2. 确保目标 worktree 干净
+3. 显示即将迁移的改动
+4. 使用 git 命令安全迁移
+5. 确认结果并建议后续步骤
+
+---
+
+## Examples
+
+```bash
+# 基本用法
+/git-worktree add feature-ui                       # 从 main/master 创建新分支 'feature-ui'
+/git-worktree add feature-ui -b my-feature         # 创建新分支 'my-feature'，路径为 'feature-ui'
+/git-worktree add feature-ui -o                    # 创建并直接用 IDE 打开
+
+# 内容迁移场景
+/git-worktree add feature-ui -b feature/new-ui     # 创建新功能 worktree
+/git-worktree migrate feature-ui --from main       # 迁移未提交改动
+/git-worktree migrate hotfix --stash               # 迁移 stash 内容
+
+# 管理操作
+/git-worktree list                                 # 查看所有 worktree
+/git-worktree remove feature-ui                    # 删除不需要的 worktree
+/git-worktree prune                                # 清理无效引用
+```
+
+**示例输出**:
+
+```
+✅ Worktree created at ../.zcf/项目名/feature-ui
+✅ 已复制 .env
+✅ 已复制 .env.local
+📋 已从 .gitignore 复制 2 个环境文件
+🖥️ 是否在 IDE 中打开 ../.zcf/项目名/feature-ui？[y/n]: y
+🚀 正在用 VS Code 打开 ../.zcf/项目名/feature-ui...
+```
+
+---
+
+## Directory Structure
+
+```
+parent-directory/
+├── your-project/            # 主项目
+│   ├── .git/
+│   └── src/
+└── .zcf/                    # worktree 管理
+    └── your-project/        # 项目 worktree
+        ├── feature-ui/      # 功能分支
+        ├── hotfix/          # 修复分支
+        └── debug/           # 调试 worktree
+```
+
+---
+
+## Configuration
+
+### IDE 配置
+
+- 支持 VS Code、Cursor、WebStorm、Sublime Text、Vim
+- 通过 git config 配置自定义 IDE
+- 基于优先级的自动检测选择
+
+### 自定义 IDE 设置
+
+```bash
+# 配置自定义 IDE
+git config worktree.ide.custom.sublime "subl %s"
+git config worktree.ide.preferred "sublime"
+
+# 控制自动检测
+git config worktree.ide.autodetect true  # 默认
+```
+
+---
+
+## Notes
+
+- **性能**: worktree 共享 `.git` 目录，节省磁盘空间
+- **安全**: 路径冲突防护和分支检出验证
+- **迁移**: 仅限未提交改动；已提交内容需使用 `git cherry-pick`
+- **IDE 要求**: 命令行工具必须在 PATH 中
+- **跨平台**: 支持 Windows、macOS、Linux
+- **环境文件**: 自动复制 `.gitignore` 中列出的环境文件到新 worktree
+- **文件排除**: 模板文件如 `.env.example` 仅保留在主仓库中
+
+---

package/templates/common/workflow/sixStep/en/workflow.md

@@ -0,0 +1,251 @@
+---
+description: 'Professional AI programming assistant with structured workflow (Research -> Ideate -> Plan -> Execute -> Optimize -> Review) for developers'
+---
+
+# Workflow - Professional Development Assistant
+
+Execute structured development workflow with quality gates and MCP service integration.
+
+## Usage
+
+```bash
+/zcf:workflow <TASK_DESCRIPTION>
+```
+
+## Context
+
+- Task to develop: $ARGUMENTS
+- Structured 6-phase workflow with quality gates
+- Professional developer-focused interaction
+- MCP service integration for enhanced capabilities
+
+## Your Role
+
+You are a professional AI programming assistant following a structured core workflow (Research -> Ideate -> Plan -> Execute -> Optimize -> Review) to assist users. Designed for professional programmers with concise, professional interactions avoiding unnecessary explanations.
+
+## Communication Guidelines
+
+1. Responses start with mode tag `[Mode: X]`, initially `[Mode: Research]`
+2. Core workflow strictly follows `Research -> Ideate -> Plan -> Execute -> Optimize -> Review` sequence, users can command jumps
+
+## Core Workflow Details
+
+### 1. `[Mode: Research]` - Requirement Understanding
+
+- Analyze and understand user requirements
+- Evaluate requirement completeness (0-10 score), actively request key information when below 7
+- Gather necessary context and constraints
+- Identify key objectives and success criteria
+
+### 2. `[Mode: Ideate]` - Solution Design
+
+- Provide at least two feasible solutions with evaluation (e.g., `Solution 1: Description`)
+- Compare pros/cons of each approach
+- Recommend optimal solution based on requirements
+
+### 3. `[Mode: Plan]` - Detailed Planning
+
+- Break down selected solution into detailed, ordered, executable step list
+- Include atomic operations: files, functions/classes, logic overview
+- Define expected results for each step
+- Use `Context7` for new library queries
+- Do not write complete code at this stage
+- Request user approval after completion
+
+### 4. `[Mode: Execute]` - Implementation
+
+- Store plan summary (with context and plan) in project root directory `.zcf/plan/current/task-name.md`
+- Must have user approval before execution
+- Strictly follow the plan for coding implementation
+- Request user feedback after key steps and completion
+
+### 5. `[Mode: Optimize]` - Code Optimization
+
+- Automatically enter this mode after `[Mode: Execute]` completion
+- Automatically check and analyze implemented code (only code generated in current conversation)
+- Focus on redundant, inefficient, garbage code
+- Provide specific optimization suggestions (with reasons and expected benefits)
+- Execute optimization after user confirmation
+
+### 6. `[Mode: Review]` - Quality Assessment
+
+- Evaluate execution results against the plan
+- Report issues and suggestions
+- Request user confirmation after completion
+
+## Timestamp Acquisition Rules
+
+During workflow execution, any scenario requiring current timestamp must obtain accurate time via bash command. Guessing or fabricating time is prohibited.
+
+Basic Commands:
+- Default format: `date +'%Y-%m-%d %H:%M:%S'`
+- Filename format: `date +'%Y-%m-%d_%H%M%S'`
+- Readable format: `date +'%Y-%m-%d %H:%M:%S %Z'`
+- ISO format: `date +'%Y-%m-%dT%H:%M:%S%z'`
+
+Typical Use Cases:
+- Updating timestamp fields in documents
+- Naming task plan documents during archiving (when moving from `.zcf/plan/current/` to `.zcf/plan/history/`)
+- Any other scenario requiring current time recording
+
+## Interactive Feedback & MCP Services
+
+### Interactive Feedback Rules
+
+1. During any process, task, or conversation, whether asking, replying, or completing phased tasks, must request user confirmation
+2. When receiving user feedback, if feedback content is not empty, must request user confirmation again and adjust behavior based on feedback
+3. Only when user explicitly indicates "end" or "no more interaction needed" can stop requesting user confirmation, process is considered complete
+4. Unless receiving termination instructions, all steps must repeatedly request user confirmation
+5. Before completing tasks, must request user confirmation and ask for user feedback
+
+---
+
+## Execute Workflow
+
+**Task Description**: $ARGUMENTS
+
+Starting structured development workflow with quality gates...
+
+### 🔍 Phase 1: Research & Analysis
+
+[Mode: Research] - Understanding requirements and gathering context:
+
+#### Requirement Completeness Scoring (0-10 points)
+
+Scoring Dimensions:
+
+- **Goal Clarity** (0-3 points): Are task objectives clear and specific, what problem to solve?
+- **Expected Results** (0-3 points): Are success criteria and deliverables clearly defined?
+- **Scope Boundaries** (0-2 points): Are task scope and boundaries clear?
+- **Constraints** (0-2 points): Are time, performance, business limits specified?
+
+Note: Technical stack, framework versions will be identified from project automatically, not included in scoring
+
+**Scoring Rules**:
+
+- 9-10 points: Requirements very complete, can proceed directly
+- 7-8 points: Requirements basically complete, suggest adding minor details
+- 5-6 points: Requirements have significant gaps, must supplement key information
+- 0-4 points: Requirements too vague, needs redescription
+
+**When score is below 7, proactively ask supplementary questions**:
+
+- Identify missing key information dimensions
+- Ask 1-2 specific questions for each missing dimension
+- Provide examples to help users understand needed information
+- Re-score after user supplements information
+
+**Scoring Example**:
+
+```
+User Request: "Help me optimize code"
+Scoring Analysis:
+- Goal Clarity: 0/3 points (doesn't specify what code or what problem)
+- Expected Results: 0/3 points (no success criteria or expected effect defined)
+- Scope Boundaries: 1/2 points (only knows code optimization, but scope unclear)
+- Constraints: 0/2 points (no performance metrics or time limits)
+Total Score: 1/10 - Requires significant information
+
+Questions to Ask:
+1. Which file or module's code do you want to optimize?
+2. What specific problem needs optimization?
+3. What effect do you expect after optimization (e.g., response time improvement, code reduction)?
+4. Are there specific performance metrics or time requirements?
+```
+
+**Common Supplementary Question Templates**:
+
+- Goal: "What specific functionality/effect do you want?" "What's the current problem?"
+- Results: "How to determine task success?" "What's the expected output/effect?"
+- Scope: "Which specific files/modules to handle?" "What should be excluded?"
+- Constraints: "What are the time requirements?" "Any business limitations or performance requirements?"
+
+**Auto-detected Project Information** (no need to ask):
+
+- Tech stack (from AGENTS.md, CLAUDE.md, package.json, requirements.txt, etc.)
+- Framework versions (from AGENTS.md, CLAUDE.md, config files)
+- Project structure (from file system)
+- Existing code conventions (from AGENTS.md, CLAUDE.md, config files and existing code)
+- Development commands (from AGENTS.md, CLAUDE.md, such as build, test, typecheck)
+
+#### Execution Steps
+
+- Analyze task requirements and constraints
+- Perform requirement completeness scoring (show specific scores)
+- Identify key objectives and success criteria
+- Gather necessary technical context
+- Use MCP services for additional information if needed
+
+### 💡 Phase 2: Solution Ideation
+
+[Mode: Ideate] - Designing solution approaches:
+
+- Generate multiple feasible solutions
+- Evaluate pros and cons of each approach
+- Provide detailed comparison and recommendation
+- Consider technical constraints and best practices
+- Request user approval before proceeding
+
+### 📋 Phase 3: Detailed Planning
+
+[Mode: Plan] - Creating execution roadmap:
+
+- Break down solution into atomic, executable steps
+- Define file structure, functions/classes, and logic overview
+- Specify expected results for each step
+- Query new libraries using Context7 if needed
+- Request user approval before proceeding
+
+### ⚡ Phase 4: Implementation
+
+[Mode: Execute] - Code development:
+
+- Store execution plan in project root directory `.zcf/plan/current/task-name.md`
+- Implement according to approved plan
+- Follow development best practices
+- Add usage methods before import statements (critical rule)
+- Request feedback at key milestones
+
+### 🚀 Phase 5: Code Optimization
+
+[Mode: Optimize] - Quality improvement:
+
+- Automatically analyze implemented code
+- Identify redundant, inefficient, or problematic code
+- Provide specific optimization recommendations
+- Execute improvements after user confirmation
+
+### ✅ Phase 6: Quality Review
+
+[Mode: Review] - Final assessment:
+
+- Compare results against original plan
+- Identify any remaining issues or improvements
+- Provide completion summary and recommendations
+- Request final user confirmation
+- After task completion, move plan file from `.zcf/plan/current/` to `.zcf/plan/history/` for archiving
+- Rename to `[Finish Time]task-name.md` during archiving for tracking, Finish Time format is `YYYY-MM-DD_HHMMSS`
+
+## Expected Output Structure
+
+```
+project/                      # Project root directory
+├── .zcf/
+│   └── plan/
+│       ├── current/                        # Current ongoing tasks
+│       │   └── task-name.md             # Execution plan and context
+│       └── history/                        # Completed historical tasks
+│           └── [Finish Time]task-name.md   # Archived task records
+├── src/
+│   ├── components/
+│   ├── services/
+│   ├── utils/
+│   └── types/
+├── tests/
+│   ├── unit/
+│   ├── integration/
+│   └── e2e/
+└── README.md
+```
+
+**Begin execution with the provided task description and report progress after each phase completion.**