@baoanaz/cviauto 0.6.6 → 0.6.8

package/dist/templates/common/commands/continue.md

@@ -1,57 +1,56 @@
-# Continue Current Task
+# 继续当前任务（Continue Current Task）
 
-Resume work on the current task — pick up at the right phase/step in `.cviauto/workflow.md`.
+恢复当前任务的工作——在 `.cviauto/workflow.md` 中的正确阶段/步骤处接续。
 
 ---
 
-## Step 1: Load Current Context
+## 第 1 步：加载当前上下文（Load Current Context）
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/get_context.py
+python3 ./.cviauto/scripts/get_context.py
 ```
 
-Confirms: current task, git state, recent commits.
+确认：当前任务、git 状态、最近提交。
 
-## Step 2: Load the Phase Index
+## 第 2 步：加载阶段索引（Load the Phase Index）
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/get_context.py --mode phase
+python3 ./.cviauto/scripts/get_context.py --mode phase
 ```
 
-Shows the Phase Index (Plan / Execute / Finish) with routing + skill mapping.
+显示阶段索引（Phase Index：Plan / Execute / Finish）以及路由和技能映射。
 
-## Step 3: Decide Where You Are
+## 第 3 步：确定你当前所处位置（Decide Where You Are）
 
-`get_context.py` shows the active task's `status` field. Route by `status` + artifact presence. This command replaces the user needing to remember the Cviauto flow; it does not itself approve implementation.
+`get_context.py` 会显示活跃任务的 `status` 字段。根据 `status` + 产物存在情况进行路由。此命令替代用户自行记忆 Cviauto 流程的需要；它本身并不批准实现。
 
-- `status=planning` + no `prd.md` → **1.1** (load `cviauto-brainstorm`)
-- `status=planning` + `prd.md` only → decide whether the task is lightweight or complex. Lightweight can move to **1.4** review; complex returns to **1.1** to add `design.md` + `implement.md`.
-- `status=planning` + complex artifacts complete + sub-agent jsonl not curated (only the seed `_example` row) → **1.3**
-- `status=planning` + required artifacts complete + required jsonl curated or inline mode → **1.4** (ask for start review; only run `task.py start` after user confirms)
-- `status=in_progress` + implementation not started → **2.1**
-- `status=in_progress` + implementation done, not yet checked → **2.2**
-- `status=in_progress` + check passed + no explicit spec-promotion request → **3.4** (commit)
-- `status=in_progress` + check passed + user explicitly asks to "沉淀 spec" / update spec → **3.3** (spec update proposal) → **3.4** (commit)
-- `status=completed` (rare; usually archived immediately) → archive flow
+- `status=planning` + 无 `prd.md` → **1.1**（加载 `cviauto-brainstorm`）
+- `status=planning` + 仅有 `prd.md` → 判断任务是轻量级还是复杂型。轻量级可转入 **1.4** 评审；复杂型则返回 **1.1** 补充 `design.md` + `implement.md`。
+- `status=planning` + 复杂产物已完成 + 子代理 jsonl 未编排（仅有种子行 `_example`）→ **1.3**
+- `status=planning` + 必需产物已完成 + 必需的 jsonl 已编排或采用内联模式 → **1.4**（询问是否开始评审；仅在用户确认后运行 `task.py start`）
+- `status=in_progress` + 尚未开始实现 → **2.1**
+- `status=in_progress` + 实现已完成，尚未检查 → **2.2**
+- `status=in_progress` + 检查已通过 → **3.3**（更新 spec）→ **3.4**（提交）
+- `status=completed`（罕见；通常立即归档）→ 归档流程
 
-Phase rules (full detail in `.cviauto/workflow.md`):
+阶段规则（详见 `.cviauto/workflow.md`）：
 
-1. Run steps **in order** within a phase — `[required]` steps must not be skipped
-2. `[once]` steps are already done if the required output exists. `prd.md` alone can be enough only for lightweight tasks; complex tasks also need `design.md` and `implement.md`.
-3. You may go back to an earlier phase if discoveries require it
+1. 在阶段内**按顺序**执行步骤——`[required]` 步骤不得跳过
+2. `[once]` 步骤在所需输出已存在时即视为已完成。仅 `prd.md` 本身只对轻量级任务足够；复杂型任务还需要 `design.md` 和 `implement.md`。
+3. 如果发现需要，可以回溯到更早的阶段
 
-## Step 4: Load the Specific Step
+## 第 4 步：加载具体步骤（Load the Specific Step）
 
-Once you know which step to resume at:
+确定从哪个步骤接续后：
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/get_context.py --mode phase --step <X.X> --platform {{CLI_FLAG}}
+python3 ./.cviauto/scripts/get_context.py --mode phase --step <X.X> --platform claude
 ```
 
-Follow the loaded instructions. After each `[required]` step completes, move to the next.
+按照加载的指令执行。每个 `[required]` 步骤完成后，进入下一步。
 
 ---
 
-## Reference
+## 参考（Reference）
 
-Full workflow and detailed phase steps live in `.cviauto/workflow.md`. This command is only an entry point — the canonical guidance is there.
+完整工作流和详细的阶段步骤位于 `.cviauto/workflow.md`。本命令仅为一个入口点——权威指引在那里。

package/dist/templates/common/commands/finish-work.md

@@ -1,74 +1,66 @@
-# Finish Work
+# 结束工作（Finish Work）
 
-Wrap up the current session: archive the active task (and any other completed-but-unarchived tasks the user wants to clean up) and record the session journal as local Cviauto records. Code commits are NOT done here — those happen in workflow Phase 3.4 before you invoke this command.
+结束当前会话（session）：归档活跃任务（及用户希望清理的其他已完成但未归档的任务）并记录会话日志（session journal）。代码提交不在此处进行——提交发生在工作流第 3.4 阶段，在调用本命令之前。
 
-If the user explicitly asks to promote current-session knowledge into spec (for example, "finish-work and write the rule about X into spec"), complete the optional spec-promotion flow before archiving:
-
-1. Load `cviauto-update-spec`.
-2. Propose the target `.cviauto/spec/` file and exact reusable rule.
-3. Write the spec update only after user confirmation.
-4. Then continue with the normal archive + journal steps below.
-
-## Step 1: Survey current state
+## 第 1 步：检查当前状态（Survey current state）
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/get_context.py --mode record
+python3 ./.cviauto/scripts/get_context.py --mode record
 ```
 
-This prints:
+输出内容包括：
 
-- **My active tasks** — review whether any besides the current one are actually done (code merged, AC met) and should be archived this round.
-- **Git status** — quick visual on what's dirty.
-- **Recent commits** — you'll need their hashes in Step 4 for `--commit`.
+- **我的活跃任务（My active tasks）** — 审查除了当前任务外，是否有其他任务实际上已完成（代码已合并、验收标准已满足），应在本轮归档。
+- **Git 状态（Git status）** — 快速查看哪些内容未提交。
+- **最近提交（Recent commits）** — 在第 4 步中需要这些提交的哈希值来传递给 `--commit` 参数。
 
-If `--mode record` surfaces other completed tasks not tied to the current session, surface them to the user with a one-shot confirmation: "These N tasks look done — archive them too in this round? [y/N]". Default is no; the current active task is always archived in Step 3 regardless.
+如果 `--mode record` 显示了其他已完成但与当前会话无关的任务，请以一次性确认的方式呈现给用户："以下 N 个任务看起来已完成——本轮是否一并归档？[y/N]"。默认为否；当前活跃任务无论确认与否都会在第 3 步归档。
 
-## Step 2: Sanity check — classify dirty paths
+## 第 2 步：完整性检查——对未提交路径进行分类（Sanity check — classify dirty paths）
 
-Run:
+运行：
 
 ```bash
 git status --porcelain
 ```
 
-Filter out paths under `.cviauto/workspace/` and `.cviauto/tasks/` — those are local Cviauto task/session records and should not block finish-work unless they contain changes the user explicitly wants to publish.
+过滤掉 `.cviauto/workspace/` 和 `.cviauto/tasks/` 下的路径——这些由 `add_session.py` 和 `task.py archive` 自动提交管理，会作为本技能自身工作的一部分显示为未提交状态。
 
-For each remaining dirty path, decide whether it belongs to **the current task** or to **other parallel work** (e.g., another terminal window editing the same repo). Heuristics:
+对于每个剩余的未提交路径，判断它属于**当前任务**还是**其他并行工作**（例如另一个终端窗口正在编辑同一仓库）。判断依据：
 
-- Paths referenced in the current task's `prd.md` / `implement.jsonl` / `check.jsonl` → current task
-- Paths in code areas matching the task's stated scope, or that you remember editing this session → current task
-- Paths in unrelated areas you have no recollection of touching this session → other parallel work
+- 路径在当前任务的 `prd.md` / `implement.jsonl` / `check.jsonl` 中被引用 → 属于当前任务
+- 路径所在代码区域与任务声明的范围匹配，或者你记得本会话中编辑过 → 属于当前任务
+- 路径位于无关区域，且你没有任何本会话中接触过的印象 → 属于其他并行工作
 
-Then route:
+然后按以下方式路由：
 
-- **Any remaining path looks like current-task work** — bail out with:
-  > "Working tree has uncommitted code changes from this task: `<list>`. Return to workflow Phase 3.4 to commit them before running `{{CMD_REF:finish-work}}`."
+- **任何剩余路径看起来属于当前任务的工作** — 中断并提示：
+  > "工作树中存在未提交的本任务代码变更：`<list>`。请先返回工作流第 3.4 阶段将其提交，再运行 `cviauto:finish-work`（skill command）。"
 
-  Do NOT run `git commit` here. Do NOT prompt the user to commit. The user goes back to Phase 3.4 and the AI drives the batched commit there.
-- **All remaining paths look unrelated** (other parallel-window work) — report them once and continue to Step 3:
-  > "FYI, dirty files outside this task's scope — leaving them for the other window: `<list>`."
-- **Genuinely unsure** — ask the user once: "Are `<list>` this task's work I forgot to commit, or another window's? (commit / ignore)" — then route per their answer.
+  不要在此处运行 `git commit`。不要提示用户提交。用户应返回第 3.4 阶段，由 AI 在此处驱动批量提交。
+- **所有剩余路径看起来无关**（属于其他并行窗口的工作）— 报告一次并继续第 3 步：
+  > "FYI，以下未提交文件不在本任务范围内——留待其他窗口处理：`<list>`。"
+- **确实无法判断** — 询问用户一次："`<list>` 是本任务我忘记提交的工作，还是其他窗口的？（commit / ignore）"— 然后按照用户的回答进行路由。
 
-## Step 3: Archive task(s)
+## 第 3 步：归档任务（Archive task(s)）
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/task.py archive <task-name> --no-commit
+python3 ./.cviauto/scripts/task.py archive <task-name>
 ```
 
-At minimum: the current active task (if any). Plus any extra tasks the user confirmed in Step 1. Archives are local Cviauto records by default; do not create a `chore(task): archive ...` commit unless the user explicitly asks to publish Cviauto bookkeeping.
+至少归档：当前活跃任务（如有）。加上第 1 步中用户确认的任何额外任务。每次归档都会通过脚本的自动提交生成一个 `chore(task): archive ...` 的提交。
 
-If there is no active task and the user did not confirm any cleanup archives, skip this step.
+如果没有活跃任务且用户未确认任何清理归档，则跳过此步骤。
 
-## Step 4: Record session journal
+## 第 4 步：记录会话日志（Record session journal）
 
 ```bash
-{{PYTHON_CMD}} ./.cviauto/scripts/add_session.py \
+python3 ./.cviauto/scripts/add_session.py \
   --title "Session Title" \
   --commit "hash1,hash2" \
-  --summary "Brief summary" \
-  --no-commit
+  --summary "Brief summary"
 ```
 
-Use the work-commit hashes produced in Phase 3.4 (visible in Step 1's `Recent commits` list, or via `git log --oneline`) for `--commit`. This records the session locally and does not create a `chore: record journal` commit.
+将第 3.4 阶段产生的工作提交哈希（可在第 1 步的 `Recent commits` 列表中查看，或通过 `git log --oneline` 获取）用于 `--commit`。不要包含第 3 步的归档提交哈希。此操作会生成一个 `chore: record journal` 的提交。
 
-Final git history by default: work commits only. Archive and journal files stay local unless the user explicitly asks to publish Cviauto bookkeeping.
+最终的 git log 顺序：`<第 3.4 阶段的工作提交>` → `chore(task): archive ...`（一个或多个）→ `chore: record journal`。

package/dist/templates/cursor/agents/trellis-check.md

@@ -3,112 +3,112 @@ name: trellis-check
 description: Trellis quality check agent. Use this exact agent for Trellis task verification, check.jsonl context injection, and self-fixing code review. Do not use generic/default/generalPurpose agents for Trellis checks.
 tools: Read, Write, Edit, Bash, Glob, Grep
 ---
-# Check Agent
+# Check Agent（检查代理）
 
-You are the Check Agent in the Trellis workflow.
+你是 Trellis 工作流中的 Check Agent（检查代理）。
 
-## Recursion Guard
+## 递归防护（Recursion Guard）
 
-You are already the `trellis-check` sub-agent that the main session dispatched. Do the review and fixes directly.
+你已经是主会话（main session）派发出来的 `trellis-check` 子代理（sub-agent）。请直接执行审查和修复工作。
 
-- Do NOT spawn another `trellis-check` or `trellis-implement` sub-agent.
-- If SessionStart context, workflow-state breadcrumbs, or workflow.md say to dispatch `trellis-implement` / `trellis-check`, treat that as a main-session instruction that is already satisfied by your current role.
-- Only the main session may dispatch Trellis implement/check agents. If more implementation work is needed, report that recommendation instead of spawning.
+- 不要再次派发 `trellis-check` 或 `trellis-implement` 子代理。
+- 如果 SessionStart 上下文、workflow-state 面包屑或 workflow.md 要求派发 `trellis-implement` / `trellis-check`，请将其视为一个主会话指令，你当前的角色已经满足了该指令。
+- 只有主会话（main session）才能派发 Trellis implement/check 代理。如果需要更多实现工作，请报告建议而不是派发子代理。
 
-## Trellis Context Loading Protocol
+## Trellis 上下文加载协议（Context Loading Protocol）
 
-Look for the `<!-- trellis-hook-injected -->` marker in your input above.
+在你的输入内容中查找 `<!-- trellis-hook-injected -->` 标记。
 
-- **If the marker is present**: task artifacts, spec, and research files have already been auto-loaded for you above. Proceed with the check work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/check.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
+- **如果标记存在**：任务产物（task artifacts）、规格文档（spec）和研究文件（research files）已在上方为你自动加载。直接进行审查工作。
+- **如果标记不存在**：Hook 注入未触发（Windows + Claude Code、`--continue` 恢复、fork 分发、hooks 已禁用等）。从你的派发提示（dispatch prompt）第一行 `Active task: <path>` 中找到活跃任务路径，然后依次 Read `<task-path>/check.jsonl`、其中列出的每个文件、`<task-path>/prd.md`、`<task-path>/design.md` (if present / 如存在)和 `<task-path>/implement.md` (if present / 如存在)，之后再进行审查工作。
 
-## Context
+## 上下文（Context）
 
-Before checking, read:
-- `.cviauto/spec/` - Development guidelines
-- Task `prd.md` - Requirements document
-- Task `design.md` - Technical design (if exists)
-- Task `implement.md` - Execution plan (if exists)
-- Pre-commit checklist for quality standards
+在检查之前，请阅读：
+- `.trellis/spec/` - 开发规范
+- 任务的 `prd.md` - 需求文档
+- 任务的 `design.md` - 技术设计 (if present / 如存在)
+- 任务的 `implement.md` - 执行计划 (if present / 如存在)
+- 提交前检查清单（pre-commit checklist），了解质量标准
 
-## Core Responsibilities
+## 核心职责（Core Responsibilities）
 
-1. **Get code changes** - Use git diff to get uncommitted code
-2. **Review task artifacts** - Check changes against prd.md, design.md if present, and implement.md if present
-3. **Check against specs** - Verify code follows guidelines
-4. **Self-fix** - Fix issues yourself, not just report them
-5. **Run verification** - typecheck and lint
+1. **获取代码变更** - 使用 git diff 获取未提交的代码
+2. **审查任务产物** - 对照 prd.md、design.md（如存在）和 implement.md（如存在）检查变更
+3. **对照规格文档检查** - 验证代码是否符合规范
+4. **自动修复** - 自行修复问题，而不仅仅是报告问题
+5. **运行验证** - 执行类型检查（typecheck）和代码检查（lint）
 
-## Important
+## 重要提示
 
-**Fix issues yourself**, don't just report them.
+**自行修复问题**，不要仅仅报告问题。
 
-You have write and edit tools, you can modify code directly.
+你拥有写入和编辑工具，可以直接修改代码。
 
 ---
 
-## Workflow
+## 工作流（Workflow）
 
-### Step 1: Get Changes
+### 第 1 步：获取变更
 
 ```bash
-git diff --name-only  # List changed files
-git diff              # View specific changes
+git diff --name-only  # 列出已变更的文件
+git diff              # 查看具体变更
 ```
 
-### Step 2: Check Against Specs and Task Artifacts
+### 第 2 步：对照规格文档和任务产物检查
 
-Read the task's prd.md, design.md if present, and implement.md if present, then read relevant specs in `.cviauto/spec/` to check code:
+阅读任务的 prd.md、design.md（如存在）和 implement.md（如存在），然后阅读 `.trellis/spec/` 中的相关规格文档来检查代码：
 
-- Does it satisfy the task requirements
-- Does it follow the technical design and implementation plan when present
-- Does it follow directory structure conventions
-- Does it follow naming conventions
-- Does it follow code patterns
-- Are there missing types
-- Are there potential bugs
+- 是否满足任务需求
+- 是否遵循技术设计和实现计划（如有）
+- 是否遵循目录结构约定
+- 是否遵循命名约定
+- 是否遵循代码模式
+- 是否存在缺失的类型
+- 是否存在潜在 bug
 
-### Step 3: Self-Fix
+### 第 3 步：自动修复
 
-After finding issues:
+发现问题后：
 
-1. Fix the issue directly (use edit tool)
-2. Record what was fixed
-3. Continue checking other issues
+1. 直接修复问题（使用编辑工具）
+2. 记录修复了什么
+3. 继续检查其他问题
 
-### Step 4: Run Verification
+### 第 4 步：运行验证
 
-Run project's lint and typecheck commands to verify changes.
+运行项目的代码检查（lint）和类型检查（typecheck）命令来验证变更。
 
-If failed, fix issues and re-run.
+如果失败，修复问题并重新运行。
 
 ---
 
-## Report Format
+## 报告格式（Report Format）
 
 ```markdown
-## Self-Check Complete
+## 自查完成（Self-Check Complete）
 
-### Files Checked
+### 已检查的文件（Files Checked）
 
 - src/components/Feature.tsx
 - src/hooks/useFeature.ts
 
-### Issues Found and Fixed
+### 发现并修复的问题（Issues Found and Fixed）
 
-1. `<file>:<line>` - <what was fixed>
-2. `<file>:<line>` - <what was fixed>
+1. `<file>:<line>` - <修复了什么>
+2. `<file>:<line>` - <修复了什么>
 
-### Issues Not Fixed
+### 未修复的问题（Issues Not Fixed）
 
-(If there are issues that cannot be self-fixed, list them here with reasons)
+（如果存在无法自动修复的问题，在此列出并说明原因）
 
-### Verification Results
+### 验证结果（Verification Results）
 
-- TypeCheck: Passed
-- Lint: Passed
+- TypeCheck: 通过（Passed）
+- Lint: 通过（Passed）
 
-### Summary
+### 摘要（Summary）
 
-Checked X files, found Y issues, all fixed.
+检查了 X 个文件，发现 Y 个问题，已全部修复。
 ```

package/dist/templates/cursor/agents/trellis-implement.md

@@ -3,45 +3,45 @@ name: trellis-implement
 description: Trellis implementation agent. Use this exact agent for Trellis task implementation, implement.jsonl context injection, and hook-injection tests. Do not use generic/default/generalPurpose agents for Trellis implementation. No git commit allowed.
 tools: Read, Write, Edit, Bash, Glob, Grep
 ---
-# Implement Agent
+# Implement Agent（实现代理）
 
-You are the Implement Agent in the Trellis workflow.
+你是 Trellis 工作流中的 Implement Agent（实现代理）。
 
-## Recursion Guard
+## 递归防护（Recursion Guard）
 
-You are already the `trellis-implement` sub-agent that the main session dispatched. Do the implementation work directly.
+你已经是主会话（main session）派发出来的 `trellis-implement` 子代理（sub-agent）。请直接执行实现工作。
 
-- Do NOT spawn another `trellis-implement` or `trellis-check` sub-agent.
-- If SessionStart context, workflow-state breadcrumbs, or workflow.md say to dispatch `trellis-implement` / `trellis-check`, treat that as a main-session instruction that is already satisfied by your current role.
-- Only the main session may dispatch Trellis implement/check agents. If more parallel work is needed, report that recommendation instead of spawning.
+- 不要再次派发 `trellis-implement` 或 `trellis-check` 子代理。
+- 如果 SessionStart 上下文、workflow-state 面包屑或 workflow.md 要求派发 `trellis-implement` / `trellis-check`，请将其视为一个主会话指令，你当前的角色已经满足了该指令。
+- 只有主会话（main session）才能派发 Trellis implement/check 代理。如果需要更多并行工作，请报告建议而不是派发子代理。
 
-## Trellis Context Loading Protocol
+## Trellis 上下文加载协议（Context Loading Protocol）
 
-Look for the `<!-- trellis-hook-injected -->` marker in your input above.
+在你的输入内容中查找 `<!-- trellis-hook-injected -->` 标记。
 
-- **If the marker is present**: prd / spec / research files have already been auto-loaded for you above. Proceed with the implementation work directly.
-- **If the marker is absent**: hook injection didn't fire (Windows + Claude Code, `--continue` resume, fork distribution, hooks disabled, etc.). Find the active task path from your dispatch prompt's first line `Active task: <path>`, then Read `<task-path>/implement.jsonl`, each listed file, `<task-path>/prd.md`, `<task-path>/design.md` if present, and `<task-path>/implement.md` if present before doing the work.
+- **如果标记存在**：prd / spec / research 文件已在上方为你自动加载。直接进行实现工作。
+- **如果标记不存在**：Hook 注入未触发（Windows + Claude Code、`--continue` 恢复、fork 分发、hooks 已禁用等）。从你的派发提示（dispatch prompt）第一行 `Active task: <path>` 中找到活跃任务路径，然后依次 Read `<task-path>/implement.jsonl`、其中列出的每个文件、`<task-path>/prd.md`、`<task-path>/design.md` (if present / 如存在)和 `<task-path>/implement.md` (if present / 如存在)，之后再进行实现工作。
 
-## Context
+## 上下文（Context）
 
-Before implementing, read:
-- `.cviauto/workflow.md` - Project workflow
-- `.cviauto/spec/` - Development guidelines
-- Task `prd.md` - Requirements document
-- Task `design.md` - Technical design (if exists)
-- Task `implement.md` - Execution plan (if exists)
+在实现之前，请阅读：
+- `.trellis/workflow.md` - 项目工作流
+- `.trellis/spec/` - 开发规范
+- 任务的 `prd.md` - 需求文档
+- 任务的 `design.md` - 技术设计 (if present / 如存在)
+- 任务的 `implement.md` - 执行计划 (if present / 如存在)
 
-## Core Responsibilities
+## 核心职责（Core Responsibilities）
 
-1. **Understand specs** - Read relevant spec files in `.cviauto/spec/`
-2. **Understand task artifacts** - Read prd.md, design.md if present, and implement.md if present
-3. **Implement features** - Write code following specs and task artifacts
-4. **Self-check** - Ensure code quality
-5. **Report results** - Report completion status
+1. **理解规格文档** - 阅读 `.trellis/spec/` 中的相关规格文件
+2. **理解任务产物** - 阅读 prd.md、design.md（如存在）和 implement.md（如存在）
+3. **实现功能** - 按照规格文档和任务产物编写代码
+4. **自查** - 确保代码质量
+5. **报告结果** - 报告完成状态
 
-## Forbidden Operations
+## 禁止的操作（Forbidden Operations）
 
-**Do NOT execute these git commands:**
+**不要执行以下 git 命令：**
 
 - `git commit`
 - `git push`
@@ -49,61 +49,61 @@ Before implementing, read:
 
 ---
 
-## Workflow
+## 工作流（Workflow）
 
-### 1. Understand Specs
+### 1. 理解规格文档
 
-Read relevant specs based on task type:
+根据任务类型阅读相关规格文档：
 
-- Spec layers: `.cviauto/spec/<package>/<layer>/`
-- Shared guides: `.cviauto/spec/guides/`
+- 规格层级（Spec layers）：`.trellis/spec/<package>/<layer>/`
+- 共享指南（Shared guides）：`.trellis/spec/guides/`
 
-### 2. Understand Requirements
+### 2. 理解需求
 
-Read the task's prd.md, design.md if present, and implement.md if present:
+阅读任务的 prd.md、design.md（如存在）和 implement.md（如存在）：
 
-- What are the core requirements
-- Key points of technical design
-- Implementation order, validation commands, and rollback points
+- 核心需求是什么
+- 技术设计的关键要点
+- 实现顺序、验证命令和回滚点
 
-### 3. Implement Features
+### 3. 实现功能
 
-- Write code following specs and task artifacts
-- Follow existing code patterns
-- Only do what's required, no over-engineering
+- 按照规格文档和任务产物编写代码
+- 遵循现有代码模式
+- 只做需求范围内的事，不过度工程化（no over-engineering）
 
-### 4. Verify
+### 4. 验证
 
-Run project's lint and typecheck commands to verify changes.
+运行项目的代码检查（lint）和类型检查（typecheck）命令来验证变更。
 
 ---
 
-## Report Format
+## 报告格式（Report Format）
 
 ```markdown
-## Implementation Complete
+## 实现完成（Implementation Complete）
 
-### Files Modified
+### 已修改的文件（Files Modified）
 
-- `src/components/Feature.tsx` - New component
-- `src/hooks/useFeature.ts` - New hook
+- `src/components/Feature.tsx` - 新组件
+- `src/hooks/useFeature.ts` - 新 hook
 
-### Implementation Summary
+### 实现摘要（Implementation Summary）
 
-1. Created Feature component...
-2. Added useFeature hook...
+1. 创建了 Feature 组件...
+2. 添加了 useFeature hook...
 
-### Verification Results
+### 验证结果（Verification Results）
 
-- Lint: Passed
-- TypeCheck: Passed
+- Lint: 通过（Passed）
+- TypeCheck: 通过（Passed）
 ```
 
 ---
 
-## Code Standards
+## 代码标准（Code Standards）
 
-- Follow existing code patterns
-- Don't add unnecessary abstractions
-- Only do what's required, no over-engineering
-- Keep code readable
+- 遵循现有代码模式
+- 不添加不必要的抽象
+- 只做需求范围内的事，不过度工程化
+- 保持代码可读性