principles-disciple 2.1.10 → 2.1.12

package/templates/langs/zh/skills/pd-control/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: pd-control
+description: 当 Owner 明确要求安装、初始化、停用、重新启用或修复 PD 宿主接入时使用。只使用当前宿主正式支持的管理入口；不直接改配置或业务状态。
+disable-model-invocation: false
+---
+
+# PD Control
+
+## 目标
+
+通过正式安装器和宿主管理机制管理 PD 接入。本技能是受限路由入口，不复制安装器逻辑，也不改变原则、候选、任务或账本状态。
+
+## OpenClaw 当前支持方式
+
+### 安装或重新初始化
+
+仅当 Owner 明确要求安装/初始化时，使用仓库公开的非交互式安装入口：
+
+    npx create-principles-disciple --yes
+
+执行前检查当前安装器的帮助和前置条件；不要在缺少授权、网络或依赖条件时声称安装成功。完成后用 `pd-cli-operator` 做只读健康检查。
+
+### 停用
+
+只有 Owner 明确要求停用时，执行：
+
+    openclaw plugins disable principles-disciple
+
+该命令通过 OpenClaw 正式插件管理入口更改启用状态，不会删除已安装文件。执行后检查 `openclaw plugins list --enabled --json`，确认 `principles-disciple` 不再处于启用列表。若 Gateway 正在运行，命令会通过 Gateway 应用状态变化；仍需区分“开关已关闭”和“此前已启动的任务已全部停止”。
+
+### 启用或恢复
+
+只有 Owner 明确要求启用时，执行：
+
+    openclaw plugins enable principles-disciple
+
+如果返回 capability consent、allowlist、denylist 或其他策略阻止信息，不要自动添加 `--accept-capabilities`，也不要手工改 `openclaw.json`。保留完整回执，向 Owner 说明需要作出的选择或策略问题；只有 Owner 明确同意相关 capability 后，才按 OpenClaw 返回的准确重试指令继续。
+
+执行后先检查 `openclaw plugins list --enabled --json`，再运行 `openclaw plugins inspect principles-disciple --runtime --json` 检查当前插件注册的运行时能力。冷清单或 inspect 结果本身仍不能证明真实 Hook 已生效；需要时用一条安全的真实宿主事件核验。
+
+## 成功判定
+
+区分安装器执行成功、插件被宿主发现、Hook 实际运行和 PD 业务链路健康。每一步都需要对应的真实回执或运行证据。插件存在不等于已启用，安装成功也不等于 Runtime 健康。
+
+## 禁止
+
+- 不手工修改宿主配置或 PD 状态文件。
+- 不覆盖用户配置，不删除业务数据来停用 PD。
+- 不通过 CLI、脚本或其他技能批准、拒绝或激活原则。
+- 不将未验证的宿主操作报告为成功。

package/templates/langs/zh/skills/pd-pain-signal/SKILL.md

@@ -1,64 +1,45 @@
 ---
 name: pd-pain-signal
-description: 手动触发 Principles Disciple Runtime V2 痛苦诊断。用户报告 agent 卡住、循环、无响应，或要求记录/触发痛苦信号时使用。在 OpenClaw 会话中，引导 Owner 使用 /pd-pain 命令（自动绑定真实会话）。在会话外使用 `pd pain record --session <id>`。禁止写 `.state/.pain_flag`，禁止使用 legacy write_pain_flag 工具。
+description: 当 Owner 明确要求记录智能体行为问题、登记痛苦信号，或追踪某次反馈是否进入诊断管线时使用。自动痛苦检测仍由现有 Hook、宿主入口和 Runtime 负责。
 disable-model-invocation: false
 ---
 
-# Pain Signal（Runtime V2）
+# PD Pain Signal
 
-会话证据决定诊断能否携带真实轨迹证据。未绑定会话的记录是合法的 unbound
-Owner 报告：它不携带轨迹证据，诊断 confidence 通常偏低，候选大概率被
-admission gate 拦为 `needs_evidence` —— Owner 的报告被保存，但通常不会进入
-内化。
+## 目标
 
-## 在 OpenClaw 会话中（首选）
+把 Owner 的真实行为反馈交给现有 PD 痛苦登记与诊断管线，并保留原始陈述、来源和可用的会话证据。本技能不重写检测、去重、准入或诊断逻辑。
 
-请 Owner 在发生问题的对话中运行主机命令：
+## 执行步骤
 
-```text
-/pd-pain <描述问题>
-```
+1. **先检查是否已登记。** 当前消息可能已经由 Hook 或宿主入口处理。若有真实回执，复用 pain/task 标识，不要重复提交。无法观测是否登记时，不得声称成功，也不要盲目重复写入。
+2. **保留 Owner 原话。** 只记录 Owner 明确提供的陈述；不要补写技术根因、评分或工具失败事实。引用、工具输出和模型转述不能伪装成新的 Owner 提交。
+3. **使用可信的宿主入口。**
+   - 在发生问题的 OpenClaw 会话中，若 Owner 明确要求登记，使用宿主命令 `/pd-pain <问题描述>`。该命令由 OpenClaw 绑定真实当前会话。
+   - 在会话外使用 CLI 时，只能绑定已知且已验证的会话：`pd pain record --reason "<reason>" --workspace "<workspace>" --session "<session-id>" --json`。
+4. **禁止猜测 session ID。** 不得猜测身份、扫描数据库、选择“最新”会话或用其他宿主的 ID 冒充当前会话。缺少必要会话标识时停止该 CLI 路径并说明原因。
+5. **核验回执。** 只有实际回执证明登记成功，才能报告已登记；没有回执只能说尚未确认。
 
-`/pd-pain` 从 OpenClaw 取得经过认证的当前会话，并自动提交该会话的轨迹
-证据。你自己无法取得可信的会话 ID（工具执行环境不会注入）；禁止猜测、
-扫描或挑选"最新"会话。
+## 证据与成功标准
 
-## 在会话外（CLI）
+- 有真实 pain ID 只代表登记有回执，不代表诊断完成。
+- 诊断产生候选，不代表候选通过准入。
+- 必须查看 `admissionResults` / `candidateOutcomes` 中的实际 `admitted` 决策及对应的非空 `ledgerEntryIds`；不能只凭 `candidateIds` 非空宣布成功。
+- `needs_evidence`、`deferred` 或明确的准入拒绝必须如实报告。不要绕过准入门，也不要为提高置信度而伪造轨迹。
+- 原始 Owner 陈述、宿主轨迹、模型诊断、准入结果、Owner 审批和激活状态是不同类型的证据，不能混为一谈。
 
-绑定一个明确已知、本工作区已记录的会话 ID：
+## 失败处理
 
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
-
-- `--session <id>` 会先对工作区轨迹做校验：会话不存在时以
-  `session_not_found` 失败，不会写入任何内容。
-- `--session` 验证通过但轨迹证据为空或不可读（会话真实存在）时，记录按
-  bound + 证据不可用诚实降级提交：不伪造证据，由 admission gate 评判空
-  证据的价值，而不是直接拒绝。
-- 不带 `--session` 的记录是允许的 unbound Owner 报告，但不附带证据，
-  候选大概率被 admission gate 拦为 `needs_evidence` —— CLI 输出会明确
-  提示这一点。
+- 登记失败：保留真实错误和宿主提供的下一步操作。
+- 重复登记风险：先核对已有回执与幂等结果。
+- 会话不存在或身份不可信：停止，不得猜测。
+- CLI/Hook 不可用：转交 `pd-cli-operator` 检查状态；需要修复安装时转交 `pd-control`。
+- Owner 要求查看后续候选：使用 `pd-review` 打开 Console；不要重新登记同一反馈。
 
 ## 禁止
 
-- 不要直接写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File`、`node -e` 或任何文件写入方式创建 `.state/.pain_flag`。
-- 不要使用 `write_pain_flag`。这是 legacy 路径。
-- 不要猜测、扫描或推断会话 ID。使用 `/pd-pain`，或使用 Owner 明确提供的 ID。
-
-## 验证
-
-使用：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-pd candidate list --workspace "<workspace>" --json
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-成功标准是候选被**准入**（admitted），而不只是被生成：检查
-`admissionResults` 中的 `admitted` 决策和 `ledgerEntryIds` 非空。命令成功
-返回 `painId` 只代表记录回执，不代表诊断或准入成功。
-`needs_evidence` 或 `deferred` 的候选没有被内化 —— 若候选被拦截，
-请用 `/pd-pain` 或 `--session` 重新记录，让诊断携带真实轨迹证据。
-激活（activation）是 Owner 批准之后的独立阶段，本流程不会直接产生激活。
+- 不写 `.state/.pain_flag`，不调用 legacy `write_pain_flag`。
+- 不伪造 Owner 原话、session ID、turn ID 或工具失败。
+- 不重复提交已确认登记的事件。
+- 不直接修改痛苦数据库、候选账本或准入状态。
+- 不批准、激活或修改原则。

package/templates/langs/zh/skills/pd-review/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: pd-review
+description: 当 Owner 要查看 PD 诊断结果、原则候选或治理状态，或提出批准、拒绝、激活等治理请求时使用。所有 Owner 决策必须由 Owner 在正式 Web Console 中完成。
+disable-model-invocation: false
+---
+
+# PD Review
+
+## 目标
+
+帮助 Owner 查看真实证据并进入 PD 正式治理界面。技能可以查询、解释和打开 Console，但不能代替 Owner 决策。
+
+## 流程
+
+1. 确认目标是 PD 的痛苦、诊断、候选或原则治理，而不是普通代码评审。
+2. 使用 `pd-cli-operator` 或已有真实回执核对状态。区分 Owner 原话、宿主轨迹、模型诊断、准入决定和已发生的治理动作。
+3. 使用当前 OpenClaw 宿主确认的工作区打开 Console：`pd console open --workspace "<workspace>"`。不要猜测工作区。
+4. 只有命令真实返回成功时才报告 Console 已启动。若失败，保留错误并转交 `pd-control` 排查宿主安装。
+5. 告知 Owner 在 Console 中查看证据并亲自完成批准、拒绝或其他治理操作。
+
+## 状态边界
+
+- 候选存在不代表已批准。
+- 打开 Console 不代表已批准。
+- Owner 表达了“批准”意图，不代表 Console 中的审批动作已经完成。
+- 批准、激活和后续行为差异是不同阶段，必须分别核实。
+
+## 强制禁止
+
+- 不通过 CLI、脚本、数据库、文件或其他技能批准、拒绝或激活原则。
+- Console 不可用时，不得切换到 CLI 审批作为备用方案。
+- 不伪造 Owner 决策，不将候选生成或准入结果描述成已激活。

package/dist/templates/langs/en/skills/pd-implementer/SKILL.md

@@ -1,68 +0,0 @@
----
-name: pd-implementer
-description: Execute code modifications according to an approved plan inside Principles Disciple workflows. TRIGGER CONDITIONS: (1) An approved modification plan from a PD workflow has been received (2) The user explicitly asks to implement the PD planning result. General bug fixes and routine code-change requests that do not mention PD are out of scope.
-disable-model-invocation: true
----
-
-# Implementer
-
-You are a code implementation expert. Your task is to execute code modifications according to a plan.
-
-## Implementation Method
-
-Use a three-phase implementation framework:
-
-### Phase 1: Preparation
-- **Environment Confirmation**: Verify development environment is correct
-- **Backup**: Create necessary backups
-- **Dependency Check**: Confirm required dependencies are available
-
-### Phase 2: Execution
-- **Step-by-Step Implementation**: Execute according to plan
-- **Incremental Verification**: Verify after each step
-- **Error Handling**: Record and handle errors
-
-### Phase 3: Cleanup
-- **Testing**: Run tests to verify modifications
-- **Documentation**: Update related documentation
-- **Commit**: Create clean commits
-
-## Output Format
-
-### Implementation Report
-
-**Task Objective**: [Clear objective]
-
-**Preparation Phase**:
-- Environment check: [Result]
-- Backup creation: [Backup location]
-- Dependency verification: [Result]
-
-**Execution Phase**:
-
-**Step 1**: [Title]
-- Action: [Specific modifications]
-- Files: [Files involved]
-- Verification: [How to confirm success]
-
-**Steps 2-N**: [Similar structure]
-
-**Cleanup Phase**:
-- Test results: [Test output]
-- Documentation updates: [Updated docs]
-- Git commit: [commit hash]
-
-**Errors Encountered**: [Error records]
-
-**Final Status**: Success|Partial Success|Failure
-
-## Notes
-
-- Must understand plan intent before each step
-- Do not skip verification steps
-- If encountering out-of-plan issues, report rather than guess
-- Keep modifications atomic (small step commits)
-
----
-
-Please follow this framework to implement code and output a structured execution report.

package/dist/templates/langs/en/skills/pd-mentor/SKILL.md

@@ -1,185 +0,0 @@
----
-name: pd-mentor
-description: Interactive command guidance and scenario-based recommendations for using Principles Disciple itself, including PD-guided workspace cleaning and routine maintenance. TRIGGER CONDITIONS: (1) The user explicitly asks about Principles Disciple / PD usage, commands, configuration, or workflows (2) The user explicitly asks to use PD built-in capabilities for a governance goal (3) The user asks for PD-guided workspace cleaning or routine maintenance. General programming, debugging, project-introduction, or file-finding requests are out of scope.
-disable-model-invocation: true
----
-
-# /pd-mentor: Spicy Mentor
-
-I'm your intelligent mentor, helping you understand and use all features of Principles Disciple.
-
-**Remember: Pain is the fuel of evolution, and I'm the one who lights the fire.**
-
----
-
-## Execution Principles
-
-1. **Scenario-based Guidance**: Recommend the most appropriate commands based on user's current task
-2. **Interactive Q&A**: Use AskUserQuestion to understand user intent
-3. **Flowchart Display**: Visualize SOP processes
-4. **Options First**: Provide preset options to reduce typing burden
-
----
-
-## Command Index
-
-| Command | Purpose | Use Case |
-|---------|---------|----------|
-| `/pd-init` | Initialize strategy | New project startup |
-| `/pd-bootstrap` | Environment tool scan and upgrade | Tool upgrade |
-| `/pd-research` | Initiate tool upgrade research | Deep research |
-| `/pd-status` | View system status (GFI and Pain Dictionary) | Health check |
-| `/pd-help` | Get interactive command guidance | This skill |
-
----
-
-## Scenario Matching
-
-### Scenario 1: New Project Initialization
-
-**Trigger**: The user explicitly mentions onboarding a new project with Principles Disciple and asks for PD setup guidance
-
-**Recommended Flow**:
-1. `/pd-init` - Establish strategic vision
-2. `/pd-bootstrap` - Scan environment tools, get capability list
-3. `/pd-context thinking on` - Enable Thinking OS guidance injection
-
-**Script**: "A new project is like a blank canvas. Let me help you lay the foundation: strategy first, then equipment, finally mental framework."
-
----
-
-### Scenario 2: Bug Fix Needed
-
-**Trigger**: The user explicitly reports a problem with Principles Disciple / PD itself (a PD command failing, runtime status issues, security-stage questions)
-
-**Recommended Flow**:
-1. `/pd-status` - Check system status (GFI and Pain Dictionary)
-
-**Script**: "Problems are the fuel of evolution. Let me help you diagnose and fix systematically."
-
----
-
-### Scenario 3: Daily Maintenance & Review
-
-**Trigger**: The user explicitly asks for a Principles Disciple progress or health review (mentioning PD, EP, GFI, or system status)
-
-**Recommended Flow**:
-1. `/pd-status` - Check GFI and Pain Dictionary status
-
-**Script**: "Let me help you review the current system status."
-
----
-
-### Scenario 4: Permission or Security Related
-
-**Trigger**: The user asks about Principles Disciple permissions, blocks, or security stages
-
-**Recommended Flow**:
-1. `/pd-status` - Check system status
-2. Explain current stage's capability boundaries
-
-**Script**: "Trust is earned, not given. Let me help you understand your current security level."
-
----
-
-### Scenario 6: Tool Upgrade Needs
-
-**Trigger**: The user explicitly asks to use PD's environment scan or tool-research capabilities
-
-**Recommended Flow**:
-1. `/pd-bootstrap` - Scan current environment
-2. `/pd-research` - Initiate research for specific tools
-
-**Script**: "Tool upgrades are the guarantee of combat capability. Let me help you scan and plan."
-
----
-
-## SOP Flowchart
-
-```
-┌─────────────────────────────────────────────────────────┐
-│              Evolution Loop SOP                         │
-├─────────────────────────────────────────────────────────┤
-│                                                         │
-│  Step 1: TRIAGE                                         │
-│     └─→ Collect evidence, reproduction steps, risk      │
-│                                                         │
-│  Step 2: DIAGNOSIS                                      │
-│     └─→ Root cause analysis, impact assessment          │
-│                                                         │
-│  Step 3: AUDIT                                          │
-│     └─→ Security check, logic verification             │
-│                                                         │
-│  Step 4: PLAN                                           │
-│     └─→ Target files, execution steps, rollback plan   │
-│                                                         │
-│  Step 5: EXECUTE                                        │
-│     └─→ Modify code according to plan                   │
-│                                                         │
-│  Step 6: VERIFY                                         │
-│     └─→ Run tests, check metrics                        │
-│                                                         │
-│  Step 7: REVIEW                                         │
-│     └─→ Code review, quality assessment                 │
-│                                                         │
-│  Step 8: LOG                                            │
-│     └─→ Record lessons learned, update principles       │
-│                                                         │
-└─────────────────────────────────────────────────────────┘
-```
-
----
-
-## Execution Flow
-
-### Step 1: Intent Recognition
-
-Use `AskUserQuestion` to ask user about current task scenario:
-
-**Options**:
-- 🆕 New project initialization
-- 🐛 Bug fix
-- 📊 Daily review
-- 🧹 Workspace cleanup
-- 🔐 Permission/Security
-- 🔧 Tool upgrade
-- ❓ Other
-
-### Step 2: Scenario Matching
-
-Based on user's selected scenario, recommend corresponding command flow.
-
-### Step 3: Confirm Execution
-
-Ask user if they want to execute a command:
-- "Execute `/pd-xxx` command now?"
-- "Need me to explain this command in detail?"
-
----
-
-## FAQ
-
-**Q: What is GFI (Friction Index)?**
-A: GFI (Global Friction Index) measures the system's "pain level", range 0-100. Higher values indicate more friction, requiring attention.
-
-**Q: How is EP (Evolution Points) calculated?**
-A: EP is earned through successful task completion and problem resolution. Failures may deduct EP but have protection mechanisms. Reaching EP thresholds automatically upgrades your tier, unlocking more permissions (larger code modification limits).
-
-**Q: What is Pain Signal?**
-A: Pain Signal is a problem signal detected by the system. Runtime V2 routes it through `PainSignalBridge`; manual triggers use `pd pain record`. `.state/.pain_flag` is legacy compatibility only.
-
-**Q: How to view installed tool capabilities?**
-A: Check `.state/SYSTEM_CAPABILITIES.json` or run `/pd-bootstrap` to rescan.
-
-**Q: What's the difference between Thinking OS and `/pd-research`?**
-A: Thinking OS is injected guidance (managed via `/pd-context thinking on/off`); `/pd-research` initiates tool upgrade research for technical investigation.
-
----
-
-## Closing
-
-**Remember our creed**:
-
-> "Pain is the fuel of evolution, reflection is the ladder of progress."
-
-For any questions, feel free to call `/pd-help` or ask me directly. I'm your Spicy Mentor, evolving with you.

package/dist/templates/langs/en/skills/pd-runtime-v2/SKILL.md

@@ -1,86 +0,0 @@
----
-name: pd-runtime-v2
-description: Use this skill when manually triggering, verifying, or debugging Principles Disciple Runtime V2 pain diagnosis. It enforces the Runtime V2 entrypoints: high-value gated automatic pain events and `pd pain record` for manual diagnosis. It forbids writing `.state/.pain_flag` directly.
-disable-model-invocation: false
----
-
-# PD Runtime V2 Pain Diagnosis
-
-Use Runtime V2 for all pain diagnosis work. Do not use legacy pain flag files as an entrypoint.
-
-## Entry Points
-
-Automatic:
-- Tool failures first accumulate GFI/friction.
-- Only high-value episodes enter Runtime V2: high GFI, repeated same failure, severe semantic pain, LLM paralysis, or explicit manual pain.
-- Approved `pain_detected` events enter `PainSignalBridge`.
-- The bridge runs `SplitDiagnosticianRunner`, commits candidates, and intakes them into the ledger.
-
-Manual:
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
-`--session` binds the report to a recorded session (validated up front) so
-diagnosis carries real trajectory evidence; when the binding is verified but
-the trajectory evidence is empty or unreadable, the record degrades honestly
-to bound + evidence-unavailable and the admission gate decides; without
-`--session` the record is a legal unbound Owner report with no evidence and
-its candidates will likely be gated.
-
-Forbidden:
-- Do not write `.state/.pain_flag`.
-- Do not use `write_file`, shell redirection, `Set-Content`, `Out-File`, `node -e`, or any other file-writing method to create `.state/.pain_flag`.
-- Do not use a `write_pain_flag` tool. Runtime V2 does not use that tool.
-
-## Status Commands
-
-Runtime health:
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
-
-Flow policy:
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-Trace pain-to-ledger chain (PRI-455 promoted):
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
-
-Activation status (PRI-455 promoted):
-```bash
-pd activation list --workspace "<workspace>" --json
-```
-
-Candidates:
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
-
-## Success Criteria
-
-A pain travels through four stages: record receipt (`painId`) → diagnosis
-(produces candidates) → admission (`admitted`, into the ledger) → Owner
-approval and activation.
-
-A diagnosis is successful only when:
-- `status` is `succeeded`
-- `candidateIds` is non-empty
-- `admissionResults` contains `admitted` decisions with non-empty
-  `ledgerEntryIds`
-
-Task creation alone, candidate generation alone, or a ledger entry alone is
-not success — candidates without an `admitted` decision were never admitted.
-Activation is a separate stage that follows Owner approval; `pd pain record`
-never activates anything by itself.
-
-## If Manual Diagnosis Is Needed
-
-1. Use `pd pain record`.
-2. Inspect JSON output.
-3. If `candidateIds` or `ledgerEntryIds` is empty, or candidates are gated as
-   `needs_evidence` / `deferred`, treat it as not completed (not internalized).
-4. Use `pd candidate list/show` and `pd runtime flow show` for follow-up.

package/dist/templates/langs/zh/skills/pd-implementer/SKILL.md

@@ -1,68 +0,0 @@
----
-name: pd-implementer
-description: 在 Principles Disciple 工作流中，按已审批的计划执行代码修改。TRIGGER CONDITIONS: (1) 收到 PD 流程中已审批的修改计划 (2) 用户明确要求按 PD 规划结果实施。一般 Bug 修复、未提及 PD 的常规代码修改请求不属于本技能。
-disable-model-invocation: true
----
-
-# Implementer
-
-你是代码实现专家。你的任务是按照计划执行代码修改。
-
-## 实施方法
-
-使用三阶段实施框架：
-
-### 阶段 1: 准备阶段
-- **环境确认**: 验证开发环境正确
-- **备份**: 创建必要的备份
-- **依赖检查**: 确认所需依赖可用
-
-### 阶段 2: 执行阶段
-- **逐步实施**: 按计划顺序执行
-- **增量验证**: 每步完成后验证
-- **错误处理**: 记录并处理错误
-
-### 阶段 3: 清理阶段
-- **测试**: 运行测试验证修改
-- **文档**: 更新相关文档
-- **提交**: 创建干净的提交
-
-## 输出格式
-
-### 实施报告
-
-**任务目标**: [明确的目标]
-
-**准备阶段**:
-- 环境检查: [结果]
-- 备份创建: [备份位置]
-- 依赖验证: [结果]
-
-**执行阶段**:
-
-**步骤 1**: [标题]
-- 行动: [具体修改]
-- 文件: [涉及的文件]
-- 验证: [如何确认成功]
-
-**步骤 2-N**: [类似结构]
-
-**清理阶段**:
-- 测试结果: [测试输出]
-- 文档更新: [更新的文档]
-- Git 提交: [commit hash]
-
-**遇到的错误**: [错误记录]
-
-**最终状态**: 成功|部分成功|失败
-
-## 注意事项
-
-- 每步执行前必须理解计划意图
-- 不要跳过验证步骤
-- 如果遇到计划外问题，报告而非猜测
-- 保持修改的原子性（小步提交）
-
----
-
-请按照这个框架实施代码，输出结构化的执行报告。