@tea-agent/loop-agent 0.2.0 → 0.2.1

package/docs/cursor-executor-usage.md

@@ -1,8 +1,8 @@
-# Cursor Executor Usage
+# Cursor Executor 用法
 
-Cursor is used for bounded write implementation. Every Cursor write task must define scope explicitly.
+Cursor 用于有界写实现。每个 Cursor 写任务必须显式定义 scope。
 
-## Required Prompt Fields
+## Prompt 必填字段
 
 - task id
 - objective
@@ -10,7 +10,7 @@ Cursor is used for bounded write implementation. Every Cursor write task must de
 - forbidden paths
 - constraints
 - expected verification
-- instruction to preserve unrelated changes
+- 保留无关变更的指令
 
 ## One-Shot Helper
 
@@ -22,4 +22,4 @@ loop-agent cursor-prompt \
   "<bounded task prompt>"
 ```
 
-After Cursor returns, the main session must inspect the diff and run the relevant verification commands.
+Cursor 返回后，主会话必须检查 diff 并运行相关验证命令。

package/docs/decisions/README.md

@@ -1,3 +1,3 @@
-# Decisions
+# 决策
 
-Use this directory for architecture decision records.
+本目录存放架构决策记录（ADR）。

package/docs/design/README.md

@@ -1,36 +1,36 @@
-# Design Notes
+# 设计笔记
 
-`docs/design/` contains planning notes for using `loop-agent` as the repo-local runtime inside a larger product-line agent platform. These documents are design inputs, not proof that the capability already exists in `src/`.
+`docs/design/` 存放将 `loop-agent` 作为更大产品线 agent 平台内仓库本地 runtime 的规划笔记。这些是设计输入，不是 `src/` 已具备该能力的证明。
 
-## Documents
+## 文档
 
-| Document | Purpose |
+| 文档 | 用途 |
 |---|---|
-| `产品线共享知识库.md` | Product-line docs repository as the upstream source of truth |
-| `研发模式.md` | 10-working-day Feature team workflow |
-| `1个月规划.md` | First-month landing plan |
-| `1月wbs.md` | First-month WBS and ownership |
-| `六个月规划.md` | Six-month roadmap and target architecture |
-| `taskspec-to-loop-agent-mapping.md` | Contract for adapting product-line TaskSpec into `loop-agent` tasks |
-| `state-and-failure-taxonomy.md` | Canonical status and failure taxonomy across docs, Task Pool, DAG, and Loop |
+| `产品线共享知识库.md` | 产品线文档仓库作为上游事实源 |
+| `研发模式.md` | 10 个工作日 Feature 团队工作流 |
+| `1个月规划.md` | 首月落地计划 |
+| `1月wbs.md` | 首月 WBS 与分工 |
+| `六个月规划.md` | 六个月路线图与目标架构 |
+| `taskspec-to-loop-agent-mapping.md` | 将产品线 TaskSpec 适配为 `loop-agent` task 的契约 |
+| `state-and-failure-taxonomy.md` | 文档、Task Pool、DAG、Loop 共用的 canonical status 与 failure taxonomy |
 
-## Current Implementation Boundary
+## 当前实现边界
 
-`loop-agent` currently owns a repo-local harness, Agent DAG generation/validation/execution, shell verification, artifacts, reports, and Loop state. It is not the product-line Task Pool, Orchestrator, docs-sync service, Git/CI platform, or artifact store.
+`loop-agent` 当前拥有：仓库本地 harness、Agent DAG 生成/验证/执行、shell 验证、artifacts、reports、Loop state。它不是产品线 Task Pool、Orchestrator、docs-sync 服务、Git/CI 平台或 artifact store。
 
-The design documents use two kinds of profile names:
+设计文档使用两类 profile 名称：
 
-- Business task profiles: `backend-feature`, `frontend-feature`, `qa-casegen`, `qa-testcode`, `reviewer-gate`.
-- `loop-agent dag run-task --profile` governance profiles: `auto`, `minimal`, `standard`, `reviewed`, `supervised`.
+- **Business task profiles**：`backend-feature`、`frontend-feature`、`qa-casegen`、`qa-testcode`、`reviewer-gate`
+- **`loop-agent dag run-task --profile` governance profiles**：`auto`、`minimal`、`standard`、`reviewed`、`supervised`
 
-Do not pass business task profiles directly to `loop-agent dag run-task --profile` unless the CLI is explicitly extended to support them. Use `taskspec-to-loop-agent-mapping.md` to route business profiles to current governance profiles.
+除非 CLI 显式扩展支持，否则不要把 business task profile 直接传给 `loop-agent dag run-task --profile`。用 `taskspec-to-loop-agent-mapping.md` 将 business profile 路由到当前 governance profile。
 
-## Maintenance Rules
+## 维护规则
 
-When these design notes change:
+设计笔记变更时：
 
-1. Keep TaskSpec fields, status names, failure categories, and command examples consistent with the contract docs.
-2. Mark future platform components as target architecture unless they exist in `src/` or `scripts/`.
-3. Update `taskspec-to-loop-agent-mapping.md` whenever `src/task/config-types.ts` or DAG profile routing changes.
-4. Update `state-and-failure-taxonomy.md` whenever DAG report categories, Loop failure classes, or Task Pool states change.
-5. Run `bash scripts/check-repo.sh`.
+1. 保持 TaskSpec 字段、status 名称、failure category 与命令示例与契约文档一致
+2. 未来平台组件标为目标架构，除非已存在于 `src/` 或 `scripts/`
+3. `src/task/config-types.ts` 或 DAG profile routing 变更时更新 `taskspec-to-loop-agent-mapping.md`
+4. DAG report category、Loop failure class 或 Task Pool state 变更时更新 `state-and-failure-taxonomy.md`
+5. 运行 `bash scripts/check-repo.sh`

package/docs/development-principles.md

@@ -1,71 +1,71 @@
-# Development Principles
+# 开发原则
 
-loop-agent is a workflow runtime for agentic coding work. The repository should stay small, explicit, and verifiable.
+loop-agent 是面向 agentic coding 的工作流 runtime。仓库应保持小而显式、可验证。
 
-## Operating Stance
+## 操作立场
 
-The project uses a human-led, agent-executed engineering model. Agents may implement, verify, and summarize, but durable intent and completion evidence must live in the repository.
+项目采用「人类掌舵、智能体执行」的工程模型。Agent 可实现、验证与总结，但持久意图与完成证据必须落在仓库中。
 
-- The repository is the record system. Decisions, contracts, plans, tests, reports, and handoffs belong in tracked files.
-- `AGENTS.md` is an operating map, not a knowledge dump. Long-lived methodology and decisions belong under `docs/`.
-- Work advances in small, reversible, verifiable increments.
-- Baseline verification comes before new work when the current state is uncertain.
-- Completion is defined by fresh evidence, not by intent or confidence.
+- 仓库是记录系统。决策、契约、计划、测试、报告与交接属于 tracked files。
+- `AGENTS.md` 是操作地图，不是知识 dump。长期方法论与决策属于 `docs/`。
+- 工作以小步、可逆、可验证的增量推进。
+- 状态不确定时，先跑基线验证再开新工。
+- 完成由新鲜证据定义，而非意图或信心。
 
-## Principles
+## 原则
 
-1. One task advances one bounded work block.
-2. Search existing code, docs, scripts, and tests before designing new behavior.
-3. Shell verification is the completion authority.
-4. Runtime state belongs in `.harness/`; durable decisions belong in `docs/`.
-5. Pi writer nodes and optional Cursor write execution must be bounded by explicit allowed and forbidden paths.
-6. Pi review/planning paths are advisory unless followed by deterministic verification.
-7. Repeated constraints should become docs, tests, scripts, checks, or templates.
-8. Do not keep hidden process state only in chat.
-9. Do not add placeholders as completed implementation.
-10. Prefer existing local patterns before adding new abstractions.
+1. 一次任务只推进一个有边界的工作块。
+2. 设计新行为前先搜索现有代码、文档、脚本与测试。
+3. Shell 验证是完成权威。
+4. Runtime 状态在 `.harness/`；持久决策在 `docs/`。
+5. Pi writer 节点与可选 Cursor 写执行必须由显式 allowed/forbidden paths 约束。
+6. Pi review/planning 路径是 advisory，除非后跟确定性验证。
+7. 反复出现的约束应固化为文档、测试、脚本、检查或模板。
+8. 不要把隐藏流程状态只留在聊天里。
+9. 不要把占位实现当作已完成交付。
+10. 新增抽象前先沿用现有局部模式。
 
-## Repository Shape
+## 仓库结构
 
-- Source lives in `src/`.
-- Tests live in `test/`.
-- Skill instructions live in `skills/`.
-- Verification and maintenance scripts live in `scripts/`.
-- Governance and handoff artifacts live in `docs/`.
+- 源码：`src/`
+- 测试：`test/`
+- Skill 指令：`skills/`
+- 验证与维护脚本：`scripts/`
+- 治理与交接产物：`docs/`
 
-## Change Discipline
+## 变更纪律
 
-For behavior changes, update tests. For workflow or command changes, update docs and examples. For governance changes, update `harness.json` and the relevant check scripts.
+行为变更要更新测试；工作流或命令变更要更新文档与示例；治理变更要更新 `harness.json` 与相关检查脚本。
 
-When work affects requirements, behavior, cross-command contracts, or harness rules, update the corresponding durable artifact:
+当工作影响需求、行为、跨命令契约或 harness 规则时，更新对应持久产物：
 
-- design or contract docs for changed expectations
-- tests or verification scripts for changed behavior
-- progress logs or reports for non-trivial handoff evidence
-- ADRs for architecture or public contract decisions
-- templates when a repeated process becomes reusable
+- 设计/契约文档 — 变更后的预期
+- 测试或验证脚本 — 变更后的行为
+- progress log 或 report — 非平凡交接证据
+- ADR — 架构或公开契约决策
+- 模板 — 重复流程可复用时
 
-Do not mix unrelated refactors, new features, and broad documentation migration in one work block unless the contract explicitly says why they must move together.
+除非 contract 明确说明必须一起移动，否则不要在一个工作块里混合无关重构、新功能与大规模文档迁移。
 
-## Search And Reuse
+## 搜索与复用
 
-Before implementing, inspect the existing system:
+实现前先检视现有系统：
 
-- Use CodeGraph first when the repository is indexed and the task needs code understanding.
-- Use `rg` for text search and `fd` for file discovery when available.
-- Read nearby tests and helpers before introducing new helpers.
-- Prefer structured parsers and existing local APIs over ad hoc string manipulation.
+- 仓库已索引且任务需要理解代码时，优先用 CodeGraph。
+- 可用时用 `rg` 做文本搜索、`fd` 找文件。
+- 引入新 helper 前先读邻近测试与 helper。
+- 优先结构化 parser 与现有本地 API，避免 ad hoc 字符串处理。
 
-Assume the system may already contain a partial solution until search proves otherwise.
+在搜索证明否则之前，假设系统可能已有部分解法。
 
-## Completion Discipline
+## 完成纪律
 
-A completion claim must answer:
+完成声明必须回答：
 
-- what changed
-- why this approach was chosen
-- which command verified it and what the result was
-- whether contracts, docs, tests, or scripts were affected
-- what risk or follow-up remains
+- 改了什么
+- 为何选此方案
+- 哪条命令验证、结果如何
+- 是否影响契约、文档、测试或脚本
+- 剩余风险或后续项
 
-If verification fails, report the failing command and observed state instead of softening the completion definition.
+验证失败时，报告失败命令与观察到的状态，而不是软化完成定义。

package/docs/dynamic-workflow-dag-engine-roadmap.md

@@ -147,11 +147,11 @@ LLM / profile 生成 WorkflowSpec JSON
 
 本次复核依据的关键代码与文档：
 
-- `docs/feature-workflow.md`
-- 源码仓库历史 completed execution plan: remove-level1-fallback
-- `src/workflows/dag/types.ts`
-- `src/workflows/dag/validate.ts`
-- `src/workflows/dag/runner.ts`
+- `docs/feature-workflow.md`
+- 源码仓库历史 completed execution plan: remove-level1-fallback
+- `src/workflows/dag/types.ts`
+- `src/workflows/dag/validate.ts`
+- `src/workflows/dag/runner.ts`
 - `src/workflows/dag/lifecycle.ts`
 - `src/workflows/dag/report.ts`
 - `src/workflows/dag/init-hybrid.ts`
@@ -1744,6 +1744,6 @@ https://code.claude.com/docs/en/workflows
 
 [3] 用户上传文档：`2026-07-02-repository-analysis.md`，关于当前 `loop-agent` 仓库结构、DAG 主路径、Loop 语义、治理边界与健康度的分析报告。
 
-[4] 当前源码仓库历史 completed execution plan，关于删除 Level 1 fallback、抽取 shell verification、建立 DAG-oriented task read model 的完成记录；发布包只携带 execution plan 目录说明，不携带具体历史计划正文。
+[4] 当前源码仓库历史 completed execution plan，关于删除 Level 1 fallback、抽取 shell verification、建立 DAG-oriented task read model 的完成记录；发布包只携带 execution plan 目录说明，不携带具体历史计划正文。
 
 [5] 当前源码复核：`src/workflows/dag/types.ts`、`src/workflows/dag/validate.ts`、`src/workflows/dag/runner.ts`、`src/workflows/loop/actions.ts`、`src/task/read-model.ts`、`src/cli/catalog.ts`。

package/docs/exec-plans/README.md

@@ -1,6 +1,6 @@
-# Execution Plans
+# 执行计划
 
-- `active/README.md` lists currently active plans.
-- `completed/README.md` lists completed plans.
+- `active/README.md` — 当前进行中的计划
+- `completed/README.md` — 已完成的计划
 
-Use an execution plan for changes that affect multiple files, public command behavior, or repository governance.
+影响多文件、公开命令行为或仓库治理的变更应使用 execution plan。

package/docs/exec-plans/active/README.md

@@ -1,9 +1,10 @@
-# Active Execution Plans
-
-Use this directory for execution plans that are currently in progress.
-
-Source repositories may keep concrete active plan files next to this README. The npm package carries this README as a directory contract and does not copy loop-agent source-history active plans; target repositories generate their own active plans.
-
-Current active plans:
-
-- [2026-07-04-dag-role-skill-alignment.md](2026-07-04-dag-role-skill-alignment.md)
+# 进行中的执行计划
+
+本目录存放当前进行中的 execution plan。
+
+源码仓库可在本 README 旁保留具体 active plan 文件。npm 包只携带本 README 作为目录契约，不复制 loop-agent 源码历史的 active plan；目标仓库自行生成 active plan。
+
+当前 active plan：
+
+- [2026-07-04-dag-role-skill-alignment.md](2026-07-04-dag-role-skill-alignment.md)
+- [2026-07-06-production-readiness-hardening.md](2026-07-06-production-readiness-hardening.md)

package/docs/exec-plans/completed/README.md

@@ -1,9 +1,9 @@
-# Completed Execution Plans
+# 已完成的执行计划
 
-Completed plans are moved here after their implementation and verification finish.
-
-The npm package carries this README as a directory contract. Concrete completed plans are target-repository history and are not copied from loop-agent's source history.
-
-- [`2026-07-02-loop-agent-subject-restructure.md`](2026-07-02-loop-agent-subject-restructure.md) — promoted the former `tools/code-agent` runtime to the repository root, renamed it to `loop-agent`, and removed the old memory plugin product lines.
-- [`2026-07-04-remove-level1-fallback.md`](2026-07-04-remove-level1-fallback.md) — removed the historical sequential Level 1 fallback and converged the runtime, docs, and command surface on DAG execution.
-- [`2026-07-04-runtime-boundary-remediation.md`](2026-07-04-runtime-boundary-remediation.md) — consolidated CLI/skill/runtime boundaries, extracted DAG/Loop runtime seams, and centralized harness store/guard policy.
+实现与验证结束后，已完成计划移入此目录。
+
+npm 包携带本 README 作为目录契约。具体 completed plan 属于目标仓库历史，不从 loop-agent 源码历史复制。
+
+- [`2026-07-02-loop-agent-subject-restructure.md`](2026-07-02-loop-agent-subject-restructure.md) — 将原 `tools/code-agent` runtime 提升到仓库根、重命名为 `loop-agent`，移除旧 memory plugin 产品线
+- [`2026-07-04-remove-level1-fallback.md`](2026-07-04-remove-level1-fallback.md) — 移除历史顺序 Level 1 fallback，runtime、文档与 command surface 收敛到 DAG 执行
+- [`2026-07-04-runtime-boundary-remediation.md`](2026-07-04-runtime-boundary-remediation.md) — 整合 CLI/skill/runtime 边界，抽出 DAG/Loop runtime seam，集中 harness store/guard 策略

package/docs/feature-workflow.md

@@ -1,117 +1,117 @@
-# Feature Workflow
+# 功能工作流
 
-This document separates two layers:
+本文档区分两层：
 
-- Session governance: how the supervising human/agent should structure a work session.
-- Runtime workflows: what the code actually executes under `src/workflows/`.
+- **Session governance**：监督方（人/agent）如何组织一次工作会话
+- **Runtime workflows**：`src/workflows/` 下代码实际执行的内容
 
-## Default Session Protocol
+## 默认会话协议
 
-1. Orient: read `README.md`, `harness.json`, and this docs index.
-2. Select: choose one bounded work block.
-3. Contract: state deliverables, non-goals, completion criteria, verification commands, and failure conditions.
-4. Implement: make the smallest coherent change and update required docs, scripts, and tests.
-5. Verify: run commands from `verification-matrix.md`; use fresh output for any completion claim.
-6. Handoff: record evidence in `docs/progress/`, `docs/reports/`, an exec plan, or an ADR when useful.
+1. **Orient**：读 `README.md`、`harness.json` 与本 docs 索引
+2. **Select**：选一个有限边界的工作块
+3. **Contract**：写明交付物、非目标、完成标准、验证命令、失败条件
+4. **Implement**：做最小连贯变更，同步更新必要文档、脚本与测试
+5. **Verify**：按 `verification-matrix.md` 跑命令；完成声明用新鲜输出
+6. **Handoff**：在 `docs/progress/`、`docs/reports/`、exec plan 或 ADR 中记录证据
 
 ## Orient
 
-Start by understanding the current system rather than assuming absence:
+先理解当前系统，不要默认「没有」：
 
-- read the repository entrypoints listed in `harness.json`
-- check `git status --short --branch` and recent commits
-- search existing source, tests, scripts, docs, and templates before adding new structure
-- run the smallest baseline check if the task depends on a healthy baseline
-- read methodology docs when the task involves TDD, verification claims, or debugging
+- 读 `harness.json` 列出的仓库入口
+- 查 `git status --short --branch` 与最近提交
+- 新增结构前搜索现有源码、测试、脚本、文档与模板
+- 任务依赖健康基线时跑最小基线检查
+- 涉及 TDD、完成声明或调试时读方法论文档
 
-If the baseline is already broken, record the failing command and decide whether the current work block is to repair the baseline or to proceed with a clearly scoped known failure.
+基线已坏时，记录失败命令，并决定当前块是修基线还是在明确范围内接受已知失败。
 
 ## Select
 
-Keep a work block narrow enough to verify. Avoid combining unrelated refactors, features, and documentation migrations.
+工作块要窄到可验证。避免无关重构、功能与文档迁移混在一起。
 
-A selected block should have:
+选中的块应有：
 
-- a single user-visible or maintainer-visible outcome
-- explicit allowed paths when delegating write work
-- known non-goals
-- a verification command that can prove the result
+- 单一用户可见或维护者可见结果
+- 委托写工作时显式 allowed paths
+- 已知非目标
+- 能证明结果的验证命令
 
 ## Contract
 
-For non-trivial work, write or update an execution plan, sprint contract, progress log, or issue-sized note before implementation. The contract should state:
+非平凡工作应在实现前写或更新 execution plan、sprint contract、progress log 或 issue 级笔记。Contract 应包含：
 
-- deliverables
-- non-goals
-- acceptance criteria
-- verification commands
-- failure conditions
-- expected artifacts to update
+- 交付物
+- 非目标
+- 验收标准
+- 验证命令
+- 失败条件
+- 预期更新的 artifacts
 
-For bug fixes, the contract should include the reproduction path and the regression test or smoke check that proves the fix.
+Bug 修复的 contract 应含复现路径，以及证明修复的回归测试或 smoke check。
 
 ## Implement
 
-Make the smallest coherent change that satisfies the contract.
+做满足 contract 的最小连贯变更。
 
-- Prefer existing helpers and directory boundaries.
-- Update tests for behavior changes.
-- Update docs and examples for workflow or command changes.
-- Update `harness.json`, check scripts, or templates for governance changes.
-- Do not submit placeholder implementations as completed work.
-- When a repeated constraint appears, promote it into a durable artifact.
+- 优先现有 helper 与目录边界
+- 行为变更更新测试
+- 工作流或命令变更更新文档与示例
+- 治理变更更新 `harness.json`、检查脚本或模板
+- 不把占位实现当作已完成
+- 重复约束出现时固化为持久产物
 
 ## Verify
 
-Verification is the completion authority.
+验证是完成权威。
 
-- Use `docs/verification-matrix.md` to choose the narrowest proving command.
-- Run the full command fresh.
-- Read the exit code and output.
-- Fix failures or report the exact failing state.
-- Do not claim completion from stale output or partial checks.
+- 用 `docs/verification-matrix.md` 选最窄的证明命令
+- 完整重跑命令
+- 读 exit code 与输出
+- 修失败或报告确切失败状态
+- 不用陈旧输出或部分检查声明完成
 
 ## Agent DAG First
 
-For complex implementation work, prefer the DAG workflow:
-
-```bash
-loop-agent new-task <task-id> "Task title"
-loop-agent dag run-task <task-id> --profile auto --strict-models --output <temp-dir>/<task-id>-dag.json
-loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --strict-governance
-loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd .
-```
-
-`<temp-dir>` means the platform-native temp directory. Use native paths for actual file operations on macOS and Windows; use `/` only for stable repo refs, JSON/Markdown evidence refs, and glob conventions.
-
-This is not a linear OS-CIVH runtime state machine. In code, DAG has three command phases:
-
-1. `dag run-task` loads `.harness/tasks/<task-id>/source/需求.md`, optional `执行约束.md`, `task.json`, and adapter verification commands, then writes a DAG spec.
-2. `dag validate` validates schema, dependencies, governance profile, write boundaries, model routing, and shell verification metadata.
-3. `run-dag` loads the DAG, topologically sorts tasks into ranks, executes runnable nodes with bounded concurrency, persists `.harness/dag-runs/<lifecycle>/<run-id>/`, and transfers the run to `completed` or `paused`.
-
-The standard generated hybrid DAG defaults to no-Cursor execution:
-
-```text
-contract-pi
-  -> scout-src + scout-tests
-  -> plan-pi
-  -> implement-pi
-  -> verify-pi
-  -> closeout-pi
-```
-
-`implement-pi` uses `executor: "pi"` with `toolProfile: "write"`. When `harness.json` explicitly disables Pi and enables Cursor, the implementation and repair writer nodes use `implement-cursor` / `repair-cursor` instead.
-
-The review-gated template inserts:
+复杂实现优先 DAG 工作流：
+
+```bash
+loop-agent new-task <task-id> "Task title"
+loop-agent dag run-task <task-id> --profile auto --strict-models --output <temp-dir>/<task-id>-dag.json
+loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --strict-governance
+loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd .
+```
+
+`<temp-dir>` 为平台原生临时目录。macOS/Windows 上实际文件操作用原生路径；`/` 仅用于稳定 repo 引用、JSON/Markdown 证据引用和 glob 约定。
+
+这不是线性 OS-CIVH runtime 状态机。代码里 DAG 有三个命令阶段：
+
+1. `dag run-task` 加载 `.harness/tasks/<task-id>/source/需求.md`、可选 `执行约束.md`、`task.json` 与 adapter 验证命令，写出 DAG spec
+2. `dag validate` 校验 schema、依赖、governance profile、写边界、model routing、shell 验证元数据
+3. `run-dag` 加载 DAG、按拓扑排序为 ranks、有界并发执行可运行节点、持久化到 `.harness/dag-runs/<lifecycle>/<run-id>/`，并转入 `completed` 或 `paused`
+
+标准生成的 hybrid DAG 默认无 Cursor：
+
+```text
+contract-pi
+  -> scout-src + scout-tests
+  -> plan-pi
+  -> implement-pi
+  -> verify-pi
+  -> closeout-pi
+```
+
+`implement-pi` 使用 `executor: "pi"` 与 `toolProfile: "write"`。当 `harness.json` 显式禁用 Pi 并启用 Cursor 时，实现与修复 writer 节点改用 `implement-cursor` / `repair-cursor`。
+
+review-gated 模板插入：
 
 ```text
 verify-pi -> review-pi -> review-gate-shell -> closeout-pi
 ```
 
-The supervised template adds write-set audit, soft/hard shell verification, process supervision, bounded repair, decision gates, and optional convergence retry passes around the implementation path.
+supervised 模板在实现路径上增加 write-set audit、soft/hard shell 验证、process supervision、有界 repair、decision gates 与可选 convergence retry。
 
-Source references:
+源码参考：
 
 - `src/commands/dag-run-task.ts`
 - `src/commands/dag-validate.ts`
@@ -119,34 +119,36 @@ Source references:
 - `src/workflows/dag/init-hybrid.ts`
 - `src/workflows/dag/runner.ts`
 
-The supervising agent remains responsible for:
+监督 agent 仍负责：
+
+- 写 contract
+- 限定 allowed/forbidden paths
+- 审查 DAG/writeSet 范围
+- 选择验证命令
+- 记录 handoff 证据
 
-- writing the contract
-- bounding allowed and forbidden paths
-- reviewing DAG/writeSet scope
-- selecting verification commands
-- recording handoff evidence
+声称 Production Readiness v0.1 的低/中风险单仓库任务，另须遵循 `docs/production-readiness.md` 与 `docs/templates/production-readiness-checklist.md`。该标准冻结支持范围、非目标、必需 DAG 证据、failure routing 字段与最终验证门禁。
 
-## Removed Sequential Workflow
+## 已移除的顺序工作流
 
-The historical Level 1 sequential command surface has been removed from the public workflow. Do not use `loop-agent run analyze|plan|spec|implement|verify|retrospective|auto|loop|continue|study` for new work.
+历史 Level 1 顺序 command surface 已从公开工作流移除。新工作不要用 `loop-agent run analyze|plan|spec|implement|verify|retrospective|auto|loop|continue|study`。
 
-Use the DAG path instead:
+改用 DAG 路径：
 
-```bash
-loop-agent new-task <task-id> "Task title"
-loop-agent dag run-task <task-id> --profile auto --strict-models --output <temp-dir>/<task-id>-dag.json
-loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --strict-governance
-loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd .
-```
+```bash
+loop-agent new-task <task-id> "Task title"
+loop-agent dag run-task <task-id> --profile auto --strict-models --output <temp-dir>/<task-id>-dag.json
+loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --strict-governance
+loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd .
+```
 
-Legacy `.harness/tasks/<task-id>/.workflow_state.json` files may still be read for compatibility until task status is fully migrated to the DAG-oriented read model. They are not the authority for new task completion.
+遗留 `.harness/tasks/<task-id>/.workflow_state.json` 在 task status 完全迁移到 DAG 导向读模型前仍可读，但不是新任务完成的权威。
 
 ## Outer Loop Runtime
 
-The `loop` command is a long-running task-control layer, not the same thing as the session governance protocol. It records rounds and signals, can run shell verification, Pi review, Cursor fixes, or DAG actions, and can choose the next automatic action.
+`loop` 命令是长跑任务控制层，与会话治理协议不是一回事。它记录 rounds 与 signals，可跑 shell 验证、Pi review、Cursor 修复或 DAG action，并选择下一自动 action。
 
-Supported loop actions are:
+支持的 loop actions：
 
 - `shell-verify`
 - `pi-review`
@@ -156,29 +158,29 @@ Supported loop actions are:
 - `add-signal`
 - `closeout`
 
-Source references:
+源码参考：
 
 - `src/commands/loop.ts`
 - `src/workflows/loop/actions.ts`
 - `src/workflows/loop/state.ts`
 - `src/workflows/loop/rounds.ts`
 
-## Debugging And TDD
+## 调试与 TDD
 
-Use the methodology docs when the task demands it:
+任务需要时使用方法论文档：
 
-- behavior changes and bug fixes: `docs/harness-methodology-tdd.md`
-- completion or handoff claims: `docs/harness-methodology-verification.md`
-- failures and unexpected behavior: `docs/harness-methodology-debugging.md`
+- 行为变更与 bug 修复：`docs/harness-methodology-tdd.md`
+- 完成或 handoff 声明：`docs/harness-methodology-verification.md`
+- 失败与意外行为：`docs/harness-methodology-debugging.md`
 
 ## Handoff
 
-A handoff should state:
+Handoff 应说明：
 
-- what changed
-- what was intentionally left out
-- which verification commands ran
-- whether contracts, docs, tests, or scripts were affected
-- any remaining risks or follow-up work
+- 改了什么
+- 有意未做什么
+- 跑了哪些验证命令
+- 是否影响契约、文档、测试或脚本
+- 剩余风险或后续工作
 
-For substantial work, update `docs/progress/`, `docs/reports/`, the active exec plan, or `docs/decisions/` so the next session can resume without relying on chat history.
+较大工作应更新 `docs/progress/`、`docs/reports/`、active exec plan 或 `docs/decisions/`，以便下一会话不依赖聊天历史。