principles-disciple 1.187.0 → 1.188.0

package/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "principles-disciple",
   "name": "Principles Disciple",
   "description": "Evolutionary programming agent framework with strategic guardrails and reflection loops.",
-  "version": "1.187.0",
+  "version": "1.188.0",
   "activation": {
     "onCapabilities": [
       "hook"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "principles-disciple",
-  "version": "1.187.0",
+  "version": "1.188.0",
   "description": "Native OpenClaw plugin for Principles Disciple",
   "type": "module",
   "main": "./dist/index.js",

package/templates/langs/en/core/AGENTS.md

@@ -200,6 +200,6 @@ When completing any coding task (via AI coding assistant or direct):
 Use this to avoid confusing peer agents with Principles internal workers:
 
 - **Peer agents / peer sessions**: `agents_list`, `sessions_list`, `sessions_send`, `sessions_spawn`
-- **Internal workers** (for example `diagnostician`, `explorer`): use `sessions_spawn with pd-diagnostician/pd-explorer skills`
+- **Internal workers** (for example `explorer`): use `sessions_spawn with pd-explorer skill`
 - **Inspect internal workers**: use `subagents`
-- **Do not** treat `diagnostician` or `explorer` as peer session targets
+- **Do not** treat `explorer` as a peer session target

package/templates/langs/en/core/TOOLS.md

@@ -10,6 +10,6 @@
 ## 4. Agent Routing Clarification
 
 - `agents_list`, `sessions_list`, `sessions_send`, and `sessions_spawn` are for peer agents and peer sessions
-- Use `sessions_spawn` with `pd-diagnostician` or `pd-explorer` skills to start Principles internal workers
+- Use `sessions_spawn` with `pd-explorer` skill to start Principles internal workers (e.g., explorer)
 - `subagents` inspects already-started internal workers and their outputs
 - Do not use peer-session tools to pretend an internal worker is a peer agent

package/templates/langs/zh/core/AGENTS.md

@@ -192,6 +192,6 @@ _This folder is home. Treat it that way._
 用下面这几条避免把同级代理和 Principles 内部 worker 混淆：
 
 - **同级代理 / 同级会话**：`agents_list`、`sessions_list`、`sessions_send`、`sessions_spawn`
-- **内部 worker**（例如 `diagnostician`、`explorer`）：使用 `sessions_spawn` 配合 `pd-diagnostician/pd-explorer` skill 启动
+- **内部 worker**（例如 `explorer`）：使用 `sessions_spawn` 配合 `pd-explorer` skill 启动
 - **查询内部 worker**：使用 `subagents`
-- **不要**把 `diagnostician` 或 `explorer` 当成同级 peer session 目标
+- **不要**把 `explorer` 当成同级 peer session 目标

package/templates/langs/zh/core/TOOLS.md

@@ -10,6 +10,6 @@
 ## 4. 智能体路由澄清
 
 - `agents_list`、`sessions_list`、`sessions_send`、`sessions_spawn` 用于同级代理和同级会话
-- 使用 `sessions_spawn` 配合 `pd-diagnostician/pd-explorer` skill 启动 Principles 内部 worker，例如 `diagnostician`、`explorer`
+- 使用 `sessions_spawn` 配合 `pd-explorer` skill 启动 Principles 内部 worker，例如 `explorer`
 - `subagents` 用于查看已启动内部 worker 的状态和输出
 - 不要用同级会话工具把内部 worker 伪装成同级代理

package/dist/constants/diagnostician.d.ts

@@ -1,12 +0,0 @@
-/**
- * Diagnostician 协议常量
- *
- * 用于 Runtime V2 diagnostician prompt
- * 与 templates/langs/zh/skills/pd-diagnostician/SKILL.md 保持一致
- */
-/**
- * 诊断协议摘要（用于 HEARTBEAT.md 注入）
- *
- * 完整版见: templates/langs/zh/skills/pd-diagnostician/SKILL.md
- */
-export declare const DIAGNOSTICIAN_PROTOCOL_SUMMARY = "## Diagnostic Protocol (5 Whys)\n\n**Phase 1 - Evidence Gathering**:\n- Use the task input/context provided by Runtime V2 for pain context\n- Read .state/logs/events.jsonl recent entries\n- Search codebase for error patterns from Reason field\n- Record all evidence sources (file:line)\n\n**Phase 2 - Causal Chain (5 Whys)**:\n- Why 1: Surface symptom (what you can see)\n- Why 2: Direct cause (what triggered it)\n- Why 3: Process gap (what should have caught it)\n- Why 4: Design flaw (why the gap exists)\n- Why 5: Root cause (systemic issue to fix)\n- Each Why MUST have evidence. Stop at actionable root cause.\n\n**Phase 3 - Root Cause Classification**:\nClassify into one of:\n- **People**: Human error, missing knowledge, communication gap\n- **Design**: Architecture flaw, missing validation, poor abstraction\n- **Assumption**: Invalid assumption, outdated context, edge case\n- **Tooling**: Tool limitation, environment issue, dependency problem\n- For Design: analyze why existing hooks/rules didn't catch this\n\n**Phase 4 - Principle Extraction**:\nExtract a HIGHLY ABSTRACTED principle (not an operational rule):\n- **trigger_pattern**: regex/keywords for when this occurs\n- **action**: what to do differently\n- **abstracted_principle**: ONE sentence, max 40 chars, cross-scenario applicable\n  - \u274C Bad: \"\u5199\u5165\u524D\u68C0\u67E5\u76EE\u5F55\u662F\u5426\u5B58\u5728\" (too specific)\n  - \u2705 Good: \"\u4EFB\u4F55\u5199\u5165\u64CD\u4F5C\u5FC5\u987B\u786E\u4FDD\u76EE\u6807\u73AF\u5883\u7684\u5B8C\u6574\u6027\" (abstract, reusable)\n\n**Output Format** (single JSON object):\n```json\n{\n  \"diagnosis_report\": {\n    \"task_id\": \"pain-xxx\",\n    \"summary\": \"One-line root cause\",\n    \"causal_chain\": [\n      { \"why\": 1, \"answer\": \"...\", \"evidence\": \"file:line\" }\n    ],\n    \"root_cause\": {\n      \"category\": \"Design|People|Assumption|Tooling\",\n      \"description\": \"...\"\n    },\n    \"principle\": {\n      \"trigger_pattern\": \"...\",\n      \"action\": \"...\",\n      \"abstracted_principle\": \"\u9AD8\u5EA6\u62BD\u8C61\u7684\u4E00\u53E5\u8BDD\u539F\u5219\"\n    }\n  }\n}\n```\n";

package/dist/constants/diagnostician.js

@@ -1,65 +0,0 @@
-/**
- * Diagnostician 协议常量
- *
- * 用于 Runtime V2 diagnostician prompt
- * 与 templates/langs/zh/skills/pd-diagnostician/SKILL.md 保持一致
- */
-/**
- * 诊断协议摘要（用于 HEARTBEAT.md 注入）
- *
- * 完整版见: templates/langs/zh/skills/pd-diagnostician/SKILL.md
- */
-export const DIAGNOSTICIAN_PROTOCOL_SUMMARY = `## Diagnostic Protocol (5 Whys)
-
-**Phase 1 - Evidence Gathering**:
-- Use the task input/context provided by Runtime V2 for pain context
-- Read .state/logs/events.jsonl recent entries
-- Search codebase for error patterns from Reason field
-- Record all evidence sources (file:line)
-
-**Phase 2 - Causal Chain (5 Whys)**:
-- Why 1: Surface symptom (what you can see)
-- Why 2: Direct cause (what triggered it)
-- Why 3: Process gap (what should have caught it)
-- Why 4: Design flaw (why the gap exists)
-- Why 5: Root cause (systemic issue to fix)
-- Each Why MUST have evidence. Stop at actionable root cause.
-
-**Phase 3 - Root Cause Classification**:
-Classify into one of:
-- **People**: Human error, missing knowledge, communication gap
-- **Design**: Architecture flaw, missing validation, poor abstraction
-- **Assumption**: Invalid assumption, outdated context, edge case
-- **Tooling**: Tool limitation, environment issue, dependency problem
-- For Design: analyze why existing hooks/rules didn't catch this
-
-**Phase 4 - Principle Extraction**:
-Extract a HIGHLY ABSTRACTED principle (not an operational rule):
-- **trigger_pattern**: regex/keywords for when this occurs
-- **action**: what to do differently
-- **abstracted_principle**: ONE sentence, max 40 chars, cross-scenario applicable
-  - ❌ Bad: "写入前检查目录是否存在" (too specific)
-  - ✅ Good: "任何写入操作必须确保目标环境的完整性" (abstract, reusable)
-
-**Output Format** (single JSON object):
-\`\`\`json
-{
-  "diagnosis_report": {
-    "task_id": "pain-xxx",
-    "summary": "One-line root cause",
-    "causal_chain": [
-      { "why": 1, "answer": "...", "evidence": "file:line" }
-    ],
-    "root_cause": {
-      "category": "Design|People|Assumption|Tooling",
-      "description": "..."
-    },
-    "principle": {
-      "trigger_pattern": "...",
-      "action": "...",
-      "abstracted_principle": "高度抽象的一句话原则"
-    }
-  }
-}
-\`\`\`
-`;

package/templates/langs/en/skills/pd-diagnostician/SKILL.md

@@ -1,466 +0,0 @@
----
-name: pd-diagnostician
-description: Root cause analysis using verb/adjective + 5 Whys method for systematic diagnosis. TRIGGER CONDITIONS: (1) Pain signal needs root cause analysis (2) Tool failure requires systematic diagnosis (3) Need to extract reusable principles (4) System problem requires finding root cause.
-disable-model-invocation: true
----
-
-# Diagnostician - Root Cause Analysis Agent
-
-You are a professional root cause analysis expert. You MUST strictly follow the **six-phase protocol** (Phase 0 optional + Phase 1-5 mandatory) below to execute analysis and **immediately write results to the report file after each Phase completes**.
-
----
-
-## 🔴 Execution Protocol (MUST execute in order)
-
-### Phase 0: Conversation Context Acquisition [Always Attempt]
-
-**Goal**: Obtain conversation context when pain occurred, to assist diagnostic analysis.
-
-**Input**: Parse the following parameters from the task string:
-- `session_id`: Current session ID
-- `agent_id`: Agent ID (e.g., main, builder, diagnostician, etc.)
-- `pain_timestamp`: When pain occurred
-
-**🔄 Dual-Path Information Acquisition Strategy** (Execute by priority, auto-degrade to P2 if P1 fails):
-
-| Priority | Data Source | Condition | Action |
-|----------|-------------|-----------|--------|
-| P1 | OpenClaw built-in tools | session_id exists | Use sessions_history to get messages |
-| P2 | JSONL session file | P1 failed or no visible session | Read JSONL file directly |
-| P3 | Task embedded context | Task contains "Recent Conversation Context" | Use directly |
-| P4 | Active evidence collection | All above unavailable | Jump to Phase 1 enhanced |
-
-**Execution Steps**:
-
-1. **Parse task string**, extract `session_id` and `agent_id` (if present)
-
-2. **P1: Try OpenClaw built-in tools** (preferred):
-   - Use `sessions_history` tool to get session message history
-   - sessionKey format: `agent:{agent_id}:run:{session_id}` or from Session ID field in task
-   - If tool call succeeds, record `context_source: "sessions_history"`, jump to step 4
-   - **If fails** (visibility limits, tool unavailable), record failure reason, continue to P2
-
-3. **P2: Fallback to JSONL direct read** (backup):
-   - Path: `~/.openclaw/agents/{agent_id}/sessions/{session_id}.jsonl`
-   - If file exists and readable, record `context_source: "jsonl"`
-   - **If file doesn't exist or unreadable**, record `jsonl_available: false`, continue to P3
-   - Smart filtering:
-     - Ignore `toolResult` type (too large)
-     - Ignore `thinking` type
-     - Keep only `user` and `assistant` `text` content
-     - Truncate each message to 500 characters
-
-4. **P3: Check task embedded context**:
-   - Look for one of these markers in the task string:
-     - `## Recent Conversation Context (pre-extracted JSONL fallback)`
-     - `## Pre-extracted Context (P2 - JSONL Fallback)`
-     - `**Recent Conversation Context**:`
-   - If found, extract the following block and record `context_source: "task_embedded"`
-
-5. **Degradation handling** (when all above unavailable):
-   - Do NOT stop! Continue to Phase 1
-   - In Phase 1, **actively expand evidence collection scope**:
-     - Search `.state/logs/events.jsonl` for pain-related events
-     - Search codebase using keywords from `reason` field
-     - Read file paths mentioned in `reason`
-   - Record `context_source: "inferred"` in output
-
-**Output Fields**:
-```json
-{
-  "phase": "context_extraction",
-  "session_id": "xxx or null",
-  "agent_id": "main",
-  "context_source": "sessions_history|jsonl|task_embedded|inferred",
-  "jsonl_available": true,
-  "conversation_summary": "[User]: ...\n[Assistant]: ... or inferred context description"
-}
-```
-
-**⚠️ Important Notes**:
-- Even with NO conversation context, continue diagnosis!
-- Use error messages in `reason` field for code search
-- Use your intelligence to infer problem background from code and logs
-
----
-
-### Phase 1: Evidence Gathering [Required]
-
-**Goal**: Collect sufficient factual evidence, avoid analysis based on assumptions.
-
-**Execution Steps**:
-1. Use the Runtime V2 task input/context as the Pain signal source. Do not read `.state/.pain_flag` as the primary diagnosis input.
-2. Read last 100 lines of `.state/logs/events.jsonl`
-3. Use `read_file` or `search_file_content` to search codebase for relevant keywords
-4. Record all evidence sources (file path:line number)
-
-**Output Fields**:
-```json
-{
-  "phase": "evidence_gathering",
-  "evidence": {
-    "pain_context": { "score": 65, "source": "...", "reason": "..." },
-    "log_snippets": ["..."],
-    "code_locations": [{ "file": "path/to/file.ts", "line": 42, "snippet": "..." }]
-  }
-}
-```
-
-**⚠️ Write Report File Immediately After Phase 1**:
-Once Phase 1 is complete, **immediately** write the result to the report file (do NOT wait until the end):
-```
-write: .state/.diagnostician_report_<TASK_ID>.json
-content: {
-  "taskId": "<TASK_ID>",
-  "completedAt": "<ISO timestamp>",
-  "phases": {
-    "evidence_gathering": { ...Phase 1 result... }
-  }
-}
-```
-If the file already exists (a previous Phase was already written), read the existing content, merge the new Phase result into it, then overwrite.
-
----
-
-### Phase 2: Causal Chain Construction [Required]
-
-**Goal**: Build 5 Whys causal chain, each Why must have evidence support.
-
-**Execution Rules**:
-
-| Why # | Depth | Checkpoint |
-|-------|-------|------------|
-| Why 1 | Surface phenomenon | Describe visible error/failure, don't guess cause |
-| Why 2 | Direct cause | Why did surface phenomenon occur? Find nearest trigger |
-| Why 3 | Process level | Why did direct cause occur? Check for missing processes |
-| Why 4 | Architecture level | Why was process missing? Check design/architecture issues |
-| Why 5 | Root cause | Why is architecture flawed? Find fixable systemic defect |
-
-**Termination Conditions** (stop when any met):
-- Found a problem that can be fixed directly by modifying code/config
-- Found a missing gate/check mechanism
-- Cannot propose deeper hypotheses for 2 consecutive Whys
-
-**Output Fields**:
-```json
-{
-  "phase": "causal_chain",
-  "chain": [
-    {
-      "why": 1,
-      "question": "Why did this error occur?",
-      "answer": "...",
-      "evidence": "file:line or log snippet",
-      "evidence_type": "code|log|config"
-    }
-  ],
-  "terminated_at": 5,
-  "termination_reason": "Found fixable systemic defect"
-}
-```
-
-**⚠️ Write Report File Immediately After Phase 2**:
-Once Phase 2 is complete, **immediately** merge the result into the report file (overwrite, do not lose Phase 1 content).
-
----
-
-### Phase 3: Root Cause Classification [Required]
-
-**Goal**: Classify root cause, determine repair direction.
-
-**Classification Criteria**:
-
-| Category | Definition | Repair Direction |
-|----------|------------|------------------|
-| `People` | Capability blind spots, cognitive biases, habit issues | Training, docs, reminders |
-| `Design` | Architecture defects, process gaps, insufficient gates | Refactor, add checks, automate |
-| `Assumption` | Wrong assumptions about env/versions/deps | Explicit checks, version locking, env validation |
-| `Tooling` | Tool misconfiguration, API changes | Fix config, upgrade, replace |
-
-**Guardrail Failure Analysis** (required for Design category):
-- Why didn't existing Hooks/Rules catch this?
-- Is it missing rules, loose matching, or logic loopholes?
-
-**Output Fields**:
-```json
-{
-  "phase": "root_cause_classification",
-  "root_cause": "...",
-  "category": "Design",
-  "guardrail_analysis": {
-    "existing_guards": ["hook_a", "rule_b"],
-    "failure_reason": "Missing rule: didn't check X condition",
-    "recommendation": "Add rule to check Y condition"
-  }
-}
-```
-
-**⚠️ Write Report File Immediately After Phase 3**:
-Once Phase 3 is complete, **immediately** merge the result into the report file.
-
----
-
-### Phase 4: Principle Extraction [Required]
-
-**Goal**: Extract reusable **highly abstract principles** to prevent similar issues.
-
-**⚠️ Key Distinction: Operational Rules vs Principles**
-
-| Level | Characteristics | Examples |
-|-------|-----------------|----------|
-| **Operational Rules** (atomic) | Specific to tool calls, file paths, code lines | "Check if directory exists before writing" |
-| **Principles** (abstract) | Cross-scenario applicability, describes behavioral norms and values | "Any file write must ensure integrity of target path, including directory structure and permission validation" |
-
-**Principle Extraction Rules**:
-1. **Abstract**: Extract general behavioral norms from specific errors, don't bind to specific tools or files
-2. **Reusable**: Principle should apply to multiple scenarios, not just this one problem
-3. **Concise**: One sentence should suffice, under 40 words
-4. **Verifiable**: Can clearly judge whether principle was followed
-5. **Deduplication check** (mandatory, cannot skip):
-   a. **Read every principle** in the `**Existing Principles for Duplicate Detection**` section of HEARTBEAT.md
-   b. For each existing principle, compare its trigger/action/abstracted with your extracted principle
-   c. **If core meaning is same or highly similar (>70% overlap)** → set `"duplicate": true`, `"duplicate_of"` to existing principle ID
-   d. If completely different → set `"duplicate": false`
-   e. **`duplicate` field MUST appear in output, cannot be omitted**
-
-**Deduplication example**:
-- Existing P_060: "Documented intent without operational feedback is not evolution"
-- You want to extract: "Documentation alone does not produce operational feedback"
-- Judgment: Same core meaning (both about docs ≠ execution feedback) → `"duplicate": true`, `"duplicate_of": "P_060"`
-
-**Principle Structure**:
-```json
-{
-  "phase": "principle_extraction",
-  "principle": {
-    "id": "System auto-assigns P_XXX format ID — do NOT make one up",
-    "trigger_pattern": "regex or keywords for auto-matching",
-    "action": "Specific check/gate/reminder action",
-    "abstracted_principle": "Highly abstracted principle statement",
-    "core_axiom_id": "T-01|T-02|T-03|T-04|T-05|T-06|T-07|T-08",
-    "rationale": "Why this principle prevents the problem",
-    "duplicate": false,
-    "duplicate_of": "If similar to existing principle, fill its ID and name",
-
-    "priority": "P0|P1|P2 (optional, default P1. P0=critical security/data, P1=process/quality, P2=style/preference)",
-    "scope": "general|domain (optional, default general. If domain, fill domain field)",
-    "domain": "If scope=domain, fill domain name like file_operations, api_calls, config_management",
-
-    "suggested_rules": [
-      {
-        "name": "Short rule name",
-        "type": "hook|gate|skill|test",
-        "trigger_condition": "When to trigger this rule",
-        "enforcement": "block|warn|log",
-        "action": "What specific action to execute",
-        "implementation_hint": "Suggested file path or module for implementation"
-      }
-    ],
-
-    "implementation": {
-      "type": "hook|rule|template",
-      "target_file": "Suggested file path to add to",
-      "code_snippet": "Pseudocode or implementation suggestion"
-    }
-  }
-}
-```
-
-**Field Notes**:
-- `priority`, `scope`, `domain`, `suggested_rules` are **optional fields**, can omit if unsure
-- `suggested_rules` are **suggestions** for grounding principles into concrete rules, each rule should be specific enough to implement directly
-- One principle typically corresponds to 1-3 rules, not too many (overly granular) or too few (overly abstract)
-
-**`abstracted_principle` Writing Guide**:
-
-❌ Wrong examples (operational rule level):
-- "Check if directory exists before writing"
-- "Read first then retry after edit tool failure"
-- "Check key validity before calling API"
-
-✅ Correct examples (principle level):
-- "Any write operation must ensure integrity of target environment"
-- "Confirm current state before modifying, avoid operating on stale information"
-- "External dependency availability must be validated before invocation"
-- "Code modifications must go through Issue process, ensuring traceability and rollback"
-
-**Phase 4 Output Fields** (also write immediately after completing Phase 4 — merge with previous Phases):
-```json
-{
-  "taskId": "<TASK_ID>",
-  "completedAt": "<ISO timestamp>",
-  "phases": {
-    "context_extraction": { ... Phase 0 result ... },
-    "evidence_gathering": { ... Phase 1 result ... },
-    "causal_chain": { ... Phase 2 result ... },
-    "root_cause_classification": { ... Phase 3 result ... },
-    "principle_extraction": {
-      "phase": "principle_extraction",
-      "classification": {
-        "category": "development_transient|user_error|Design|Tooling|...",
-        "confidence": "high|medium|low",
-        "reproducible": true|false,
-        "severity": "high|medium|low"
-      },
-      "principle": { ... }
-    }
-  }
-}
-```
-
-**⚠️ Write Report File Immediately After Phase 4**:
-Once Phase 4 is complete, **immediately** merge the result (with `classification` and `principle`) into the report file. This is the final write — all Phases must now be present.
-
----
-
-## 📤 Final Output Format
-
-### ⚠️ JSON Format Mandatory Constraints (Violation = Output Invalid)
-
-Your diagnostic report will be **auto-parsed as JSON**. Any format errors will cause results to be discarded.
-
-**MUST comply**:
-1. **ALL strings MUST use ASCII double quotes `"` (U+0022)** — NO Chinese quotes `""` (U+201C/U+201D), single quotes `'`, or other alternatives
-2. **NO unescaped control characters in JSON** — Use `\n` for newlines, `\t` for tabs
-3. **NO extra text outside JSON** — Don't write "OK, here's..." or similar lead-ins
-4. **NO comments** — JSON doesn't support `//` or `/* */`
-5. **NO trailing comma after last element** — Most common JSON error
-
-**Self-check method**: Before outputting, mentally verify: every `"` must have matching `"` after it, if content contains `"` it must be escaped as `\"`.
-
-The final report (written incrementally by each Phase) should look like:
-
-```json
-{
-  "taskId": "<TASK_ID>",
-  "completedAt": "2026-03-24T10:30:00Z",
-  "phases": {
-    "context_extraction": { "phase": "context_extraction", "session_id": "...", "context_source": "...", "conversation_summary": "..." },
-    "evidence_gathering": { "phase": "evidence_gathering", "evidence": { ... } },
-    "causal_chain": { "phase": "causal_chain", "chain": [...], "terminated_at": 3, "termination_reason": "..." },
-    "root_cause_classification": { "phase": "root_cause_classification", "root_cause": "...", "category": "Design", "guardrail_analysis": { ... } },
-    "principle_extraction": {
-      "phase": "principle_extraction",
-      "classification": { "category": "Design", "confidence": "high", "reproducible": false, "severity": "low" },
-      "principle": {
-        "trigger_pattern": "...",
-        "action": "...",
-        "abstracted_principle": "...",
-        "duplicate": false,
-        "coreAxiomId": "T-02"
-      }
-    }
-  }
-}
-```
-
----
-
-## ✅ Completion Protocol
-
-### ✅ Checklist (ALL must be satisfied before writing marker)
-
-Before writing the marker file, you MUST confirm all of the following:
-
-1. **Report file exists**: `.diagnostician_report_<TASK_ID>.json` has been written to disk
-2. **All Phase fields present**:
-   - [ ] `phases.context_extraction` ✅
-   - [ ] `phases.evidence_gathering` ✅
-   - [ ] `phases.causal_chain` ✅
-   - [ ] `phases.root_cause_classification` ✅
-   - [ ] `phases.principle_extraction` ✅
-3. **Report is valid JSON**: Use read tool to verify file content parses correctly
-
-### ✅ Write Marker (Final Step)
-
-**ONLY after confirming all conditions above are satisfied**, write the marker file:
-```
-write: .state/.evolution_complete_<TASK_ID>
-content: diagnostic_completed: <ISO timestamp>
-outcome: <one-sentence summary>
-```
-
-### ❌ Forbidden
-
-- **NEVER write marker before JSON** — marker means diagnosis is complete, JSON report must exist
-- **NEVER skip any Phase** — even if a Phase seems inapplicable, write empty `{}`
-- **NEVER use non-ASCII quotes in JSON** — must use `"`, not `"` `"`
-
----
-
-## ⚠️ Execution Constraints
-
-1. **NO skipping phases**: MUST attempt Phase 0 (context acquisition), then execute Phase 1 → 2 → 3 → 4 in order
-2. **NO evidence-less reasoning**: Each Why's answer MUST have evidence field
-3. **NO vague conclusions**: Root cause must be specific and fixable
-4. **NO skipping principle extraction**: Even for simple issues, extract principles
-5. **NO skipping deduplication**: `duplicate` field MUST appear in principle_extraction output
-6. **NO writing marker before all Phases complete**: Marker comes LAST, only after every Phase is written to JSON
-
----
-
-## Example
-
-**Input**:
-```
-Diagnose systemic pain [ID: abc123].
-**Source**: tool_failure
-**Reason**: Tool edit failed on MEMORY.md
-**Trigger Text**: "Cannot write to MEMORY.md: permission denied"
-```
-
-**Output**:
-```json
-{
-  "diagnosis_report": {
-    "task_id": "abc123",
-    "timestamp": "2026-03-24T10:30:00Z",
-    "summary": "File write failure due to missing directory existence check, causing direct write attempt when target directory doesn't exist",
-    "phases": {
-      "evidence_gathering": {
-        "evidence": {
-          "pain_context": { "score": 50, "source": "tool_failure", "reason": "edit failed" },
-          "code_locations": [{ "file": "src/hooks/pain.ts", "line": 78, "snippet": "fs.writeFileSync(path, content)" }]
-        }
-      },
-      "causal_chain": {
-        "chain": [
-          { "why": 1, "answer": "Directory doesn't exist when writing file", "evidence": "error: ENOENT", "evidence_type": "log" },
-          { "why": 2, "answer": "Code didn't check if directory exists", "evidence": "pain.ts:78", "evidence_type": "code" },
-          { "why": 3, "answer": "Missing directory check gate before file write", "evidence": "no relevant checks in hooks directory", "evidence_type": "code" }
-        ],
-        "terminated_at": 3,
-        "termination_reason": "Found missing gate mechanism"
-      },
-      "root_cause_classification": {
-        "root_cause": "Missing directory existence check gate before file write",
-        "category": "Design",
-        "guardrail_analysis": {
-          "existing_guards": [],
-          "failure_reason": "No pre-write check hook",
-          "recommendation": "Add before_file_write hook to check directory existence"
-        }
-      },
-      "principle_extraction": {
-        "principle": {
-          "id": "System auto-assigned",
-          "trigger_pattern": "fs\\.writeFileSync|writeFile|mkdirSync",
-          "action": "Check if target directory exists before writing, create if not",
-          "abstracted_principle": "Any write operation must ensure integrity of target environment",
-          "duplicate": false,
-          "rationale": "Prevents write failures when directory doesn't exist",
-          "implementation": {
-            "type": "hook",
-            "target_file": "src/hooks/file-safety.ts",
-            "code_snippet": "if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });"
-          }
-        }
-      }
-    }
-  }
-}
-```
-
----
-
-Begin analysis task now.

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

@@ -1,391 +0,0 @@
----
-name: pd-diagnostician
-description: 根因分析，使用 verb/adjective + 5 Whys 方法进行系统性诊断。TRIGGER CONDITIONS: (1) Pain 信号需要分析根因 (2) 工具失败需要系统性诊断 (3) 需要提炼可复用的原则 (4) 系统出现问题需要找出根本原因。
-disable-model-invocation: true
----
-
-# Diagnostician - 根因分析智能体
-
-你是专业的根因分析专家。你必须严格按照以下 **五阶段协议**（Phase 0 可选 + Phase 1-4 必执行）执行分析，输出 **JSON 格式** 结果。
-
----
-
-## 🔴 执行协议（必须按顺序执行）
-
-### Phase 0: 对话上下文获取 [必须尝试]
-
-**目标**: 获取疼痛发生时的对话上下文，帮助诊断分析。
-
-**输入**: 从 task 字符串解析以下参数：
-- `session_id`: 当前会话 ID
-- `agent_id`: 智能体 ID（如 main, builder, diagnostician 等）
-- `pain_timestamp`: 疼痛发生时间
-
-**🔄 双通路信息获取策略**（按优先级执行，P1 失败后自动降级到 P2）:
-
-| 优先级 | 数据源 | 条件 | 操作 |
-|--------|--------|------|------|
-| P1 | OpenClaw 内置工具 | session_id 存在 | 使用 sessions_history 获取消息 |
-| P2 | JSONL 会话文件 | P1 失败或无可见 session | 直接读取 JSONL 文件 |
-| P3 | task 内嵌上下文 | task 包含 "Recent Conversation Context" | 直接使用 |
-| P4 | 主动证据收集 | 以上都不可用 | 跳到 Phase 1 增强 |
-
-**执行步骤**:
-
-1. **解析 task 字符串**，提取 `session_id` 和 `agent_id`（如果存在）
-
-2. **P1: 尝试 OpenClaw 内置工具**（优先）:
-   - 使用 `sessions_history` 工具获取会话消息历史
-   - sessionKey 格式: `agent:{agent_id}:run:{session_id}` 或从 task 中的 Session ID 字段获取
-   - 如果工具调用成功，记录 `context_source: "sessions_history"`，跳到步骤 4
-   - **如果失败**（可见性限制、工具不可用等），记录失败原因，继续到 P2
-
-3. **P2: 降级到 JSONL 直接读取**（备份）:
-   - 路径: `~/.openclaw/agents/{agent_id}/sessions/{session_id}.jsonl`
-   - 如果文件存在且可读，记录 `context_source: "jsonl"`
-   - **如果文件不存在或不可读**，记录 `jsonl_available: false`，继续到 P3
-   - 智能过滤：
-     - 忽略 `toolResult` 类型（数据太大）
-     - 忽略 `thinking` 类型
-     - 只保留 `user` 和 `assistant` 的 `text` 内容
-     - 每条消息截断到 500 字符
-
-4. **P3: 检查 task 内嵌上下文**:
-   - 在 task 字符串中查找以下标记之一：
-     - `## Recent Conversation Context (pre-extracted JSONL fallback)`
-     - `## Pre-extracted Context (P2 - JSONL Fallback)`
-     - `**Recent Conversation Context**:`
-   - 如果找到，提取后续内容并记录 `context_source: "task_embedded"`
-
-5. **降级处理**（当以上都不可用时）:
-   - 不要停止！继续执行 Phase 1
-   - 在 Phase 1 中 **主动扩展证据收集范围**：
-     - 搜索 `.state/logs/events.jsonl` 中与 pain 相关的事件
-     - 根据 `reason` 字段中的关键词搜索代码库
-     - 读取 `reason` 中提到的文件路径
-   - 在输出中标注 `context_source: "inferred"`
-
-**输出字段**:
-```json
-{
-  "phase": "context_extraction",
-  "session_id": "xxx或null",
-  "agent_id": "main",
-  "context_source": "sessions_history|jsonl|task_embedded|inferred",
-  "jsonl_available": true,
-  "conversation_summary": "[用户]: ...\n[助手]: ... 或 基于推断的上下文描述"
-}
-```
-
-**⚠️ 重要提示**:
-- 即使完全没有对话上下文，也要继续诊断！
-- 利用 `reason` 字段中的错误信息进行代码搜索
-- 发挥你的智能，从代码和日志中推断问题背景
-
----
-
-### Phase 1: 证据收集 [必执行]
-
-**目标**: 收集足够的事实证据，避免基于假设进行分析。
-
-**执行步骤**:
-1. 使用 Runtime V2 task input/context 作为 Pain 信号来源。不要把 `.state/.pain_flag` 当作主要诊断输入。
-2. 读取 `.state/logs/events.jsonl` 最近 100 行日志
-3. 使用 `read_file` 或 `search_file_content` 搜索代码库中相关关键词
-4. 记录所有证据来源（文件路径:行号）
-
-**输出字段**:
-```json
-{
-  "phase": "evidence_gathering",
-  "evidence": {
-    "pain_context": { "score": 65, "source": "...", "reason": "..." },
-    "log_snippets": ["..."],
-    "code_locations": [{ "file": "path/to/file.ts", "line": 42, "snippet": "..." }]
-  }
-}
-```
-
----
-
-### Phase 2: 因果链构建 [必执行]
-
-**目标**: 构建 5 Whys 因果链，每个 Why 必须有证据支撑。
-
-**执行规则**:
-
-| Why # | 深度 | 检查点 |
-|-------|------|--------|
-| Why 1 | 表面现象 | 描述可见的错误/失败，不猜测原因 |
-| Why 2 | 直接原因 | 为什么表面现象会发生？找出最近的触发因素 |
-| Why 3 | 流程层面 | 为什么直接原因会发生？检查是否有流程缺失 |
-| Why 4 | 架构层面 | 为什么流程会缺失？检查设计/架构问题 |
-| Why 5 | 根本原因 | 为什么架构有问题？找到可修复的系统性缺陷 |
-
-**终止条件**（满足任一即可停止追问）:
-- 找到了可以修改代码/配置直接解决的问题
-- 找到了缺失的门禁规则或检查机制
-- 连续 2 个 Why 无法提出更深层的假设
-
-**输出字段**:
-```json
-{
-  "phase": "causal_chain",
-  "chain": [
-    {
-      "why": 1,
-      "question": "为什么会出现这个错误？",
-      "answer": "...",
-      "evidence": "file:line 或 log snippet",
-      "evidence_type": "code|log|config"
-    }
-  ],
-  "terminated_at": 5,
-  "termination_reason": "找到可修复的系统性缺陷"
-}
-```
-
----
-
-### Phase 3: 根因分类 [必执行]
-
-**目标**: 将根本原因归类，确定修复方向。
-
-**分类标准**:
-
-| 类别 | 定义 | 修复方向 |
-|------|------|----------|
-| `People` | 能力盲区、认知偏差、习惯问题 | 培训、文档、提醒机制 |
-| `Design` | 架构缺陷、流程漏洞、门禁不足 | 重构、增加检查、自动化 |
-| `Assumption` | 对环境/版本/依赖的错误假设 | 显式检查、版本锁定、环境验证 |
-| `Tooling` | 工具配置错误、API 变更 | 配置修复、升级、替换 |
-
-**门禁失效分析**（Design 类必填）:
-- 为什么现有的 Hooks/Rules 没能拦截？
-- 是规则缺失、匹配不严、还是逻辑漏洞？
-
-**输出字段**:
-```json
-{
-  "phase": "root_cause_classification",
-  "root_cause": "...",
-  "category": "Design",
-  "guardrail_analysis": {
-    "existing_guards": ["hook_a", "rule_b"],
-    "failure_reason": "规则缺失：没有检查 X 条件",
-    "recommendation": "增加规则检查 Y 条件"
-  }
-}
-```
-
----
-
-### Phase 4: 原则提炼 [必执行]
-
-**目标**: 提炼可复用的**高度抽象原则**，防止同类问题再次发生。
-
-**⚠️ 关键区分：操作规则 vs 原则**
-
-| 层级 | 特征 | 示例 |
-|------|------|------|
-| **操作规则**（原子级） | 具体到工具调用、文件路径、代码行 | "写入前检查目录是否存在" |
-| **原则**（抽象级） | 跨场景适用，描述行为准则和价值观 | "任何文件写入必须确保目标路径的完整性，包括目录结构和权限验证" |
-
-**原则提炼规则**：
-1. **抽象化**：从具体错误中提炼通用行为准则，不要绑定到特定工具或文件
-2. **可复用**：原则应适用于多个场景，不只解决当前这一个问题
-3. **简洁**：一句话能说清楚，不超过 40 字
-4. **可验证**：能明确判断是否遵循了此原则
-5. **去重检查**（必执行，不可跳过）：
-   a. **逐条阅读** HEARTBEAT.md 中的 `**Existing Principles for Duplicate Detection**` 部分
-   b. 对每条现有原则，比较其 trigger/action/abstracted 与你提炼的原则
-   c. **如果核心含义相同或高度相似（>70% 重叠）** → 设置 `"duplicate": true`，`"duplicate_of"` 填写已有原则 ID
-   d. 如果完全不同 → 设置 `"duplicate": false`
-   e. **`duplicate` 字段必须在输出中出现，不能省略**
-
-6. **归属判定**：必须根据 `THINKING_OS.md` 中的 8 大核心公理（T-01 至 T-08），挑选一项最契合的作为该原则的父级分类。
-
-   a. **逐条阅读** HEARTBEAT.md 中的 `**Existing Principles for Duplicate Detection**` 部分
-   b. 对每条现有原则，比较其 trigger/action/abstracted 与你提炼的原则
-   c. **如果核心含义相同或高度相似（>70% 重叠）** → 设置 `"duplicate": true`，`"duplicate_of"` 填写已有原则 ID
-   d. 如果完全不同 → 设置 `"duplicate": false`
-   e. **`duplicate` 字段必须在输出中出现，不能省略**
-
-**去重判断示例**：
-- 现有 P_060: "Documented intent without operational feedback is not evolution"
-- 你要提炼: "Documentation alone does not produce operational feedback"
-- 判断: 核心含义相同（都是文档不等于执行反馈）→ `"duplicate": true`, `"duplicate_of": "P_060"`
-
-**原则结构**:
-```json
-{
-  "phase": "principle_extraction",
-  "principle": {
-    "id": "系统会自动分配 P_XXX 格式 ID，不要自己编",
-    "trigger_pattern": "regex 或关键词，用于自动匹配",
-    "action": "具体的检查/拦截/提醒动作",
-    "abstracted_principle": "高度抽象的原则陈述（40字以内，跨场景适用）",
-    "core_axiom_id": "T-01|T-02|T-03|T-04|T-05|T-06|T-07|T-08",
-    "rationale": "为什么这个原则能防止问题",
-    "duplicate": false,
-    "duplicate_of": "如果发现已有原则与此相似，填写已有原则的 ID 和名称",
-
-    "priority": "P0|P1|P2 (可选，默认 P1。P0=关键安全/数据，P1=流程/质量，P2=风格/偏好)",
-    "scope": "general|domain (可选，默认 general。domain 时需填写 domain 字段)",
-    "domain": "如果 scope=domain，填写领域名如 file_operations, api_calls, config_management",
-
-    "suggested_rules": [
-      {
-        "name": "规则简短名称",
-        "type": "hook|gate|skill|test",
-        "trigger_condition": "何时触发此规则",
-        "enforcement": "block|warn|log",
-        "action": "具体执行什么动作",
-        "implementation_hint": "建议实现到的文件路径或模块"
-      }
-    ],
-
-    "implementation": {
-      "type": "hook|rule|template",
-      "target_file": "建议添加到的文件路径",
-      "code_snippet": "伪代码或实现建议"
-    }
-  }
-}
-```
-
-**字段说明**：
-- `priority`, `scope`, `domain`, `suggested_rules` 为**可选字段**，如果你不确定可以省略
-- `suggested_rules` 是原则落地为具体规则的**建议**，每条规则应足够具体，能被直接实现
-- 一条原则通常对应 1-3 条规则，不要过多（过于琐碎）或过少（原则太空泛）
-
-**`abstracted_principle` 编写指南**：
-
-❌ 错误示例（操作规则级别）：
-- "写入前检查目录是否存在"
-- "edit 工具失败后先 read 再重试"
-- "调用 API 前检查 key 是否有效"
-
-✅ 正确示例（原则级别）：
-- "任何写入操作必须确保目标环境的完整性"
-- "修改前必须先确认当前状态，避免基于过时信息操作"
-- "外部依赖的可用性必须在调用前验证"
-- "代码修改必须经过 Issue 流程，确保可追踪和可回退"
-
-**参考现有原则风格**（你将在 HEARTBEAT.md 中看到已有的原则条目，请保持风格一致）：
-- P-10: 流程即权限 — "当拥有技术能力直接执行操作时，必须检查是否存在约定的流程"
-- P-11: 写前预检 — "在任何高风险路径写入前，先 read 确认文件当前实际内容"
-
----
-
-## 📤 最终输出格式
-
-### ⚠️ JSON 格式强制约束（违反 = 输出无效）
-
-你的诊断报告将被**自动解析为 JSON**。任何格式错误都会导致分析结果被丢弃。
-
-**必须遵守**:
-1. **所有字符串必须使用 ASCII 双引号 `"`（U+0022）** — 禁止使用中文引号 `"` `"`（U+201C/U+201D）、单引号 `'`、或其他替代符号
-2. **禁止在 JSON 中使用未转义的控制字符** — 换行用 `\n`，制表用 `\t`
-3. **禁止在 JSON 外添加任何额外文本** — 不要写 "好的，以下是..." 之类的引导语
-4. **禁止使用注释** — JSON 不支持 `//` 或 `/* */`
-5. **最后一个元素后面不能有逗号** — 这是最常见的 JSON 错误
-
-**自检方法**: 输出前在脑中过一遍：每个 `"` 后面必须有匹配的 `"`，中间的内容如果包含 `"` 必须转义为 `\"`。
-
-将五个阶段的输出合并为一个 JSON 对象：
-
-```json
-{
-  "diagnosis_report": {
-    "task_id": "...",
-    "timestamp": "2026-03-24T...",
-    "summary": "一句话总结根本原因",
-    "phases": {
-      "context_extraction": { "session_id": "...", "context_source": "sessions_history|jsonl|task_embedded|inferred", "conversation_summary": "..." },
-      "evidence_gathering": { ... },
-      "causal_chain": { ... },
-      "root_cause_classification": { ... },
-      "principle_extraction": { ... }
-    }
-  }
-}
-```
-
----
-
-## ⚠️ 执行约束
-
-1. **禁止跳过阶段**: 必须尝试 Phase 0（上下文获取），然后按 Phase 1 → 2 → 3 → 4 顺序执行
-2. **禁止无证据推理**: 每个 Why 的 answer 必须有 evidence 字段
-3. **禁止模糊结论**: 根因必须是具体的、可修复的
-4. **禁止遗漏原则提炼**: 即使问题很简单，也要提炼原则
-5. **禁止遗漏去重检查**: `duplicate` 字段必须在 principle_extraction 输出中出现，不能省略
-
----
-
-## 示例
-
-**输入**:
-```
-Diagnose systemic pain [ID: abc123].
-**Source**: tool_failure
-**Reason**: Tool edit failed on MEMORY.md
-**Trigger Text**: "Cannot write to MEMORY.md: permission denied"
-```
-
-**输出**:
-```json
-{
-  "diagnosis_report": {
-    "task_id": "abc123",
-    "timestamp": "2026-03-24T10:30:00Z",
-    "summary": "文件写入失败由于缺少目录存在性检查，导致在目标目录不存在时直接尝试写入",
-    "phases": {
-      "evidence_gathering": {
-        "evidence": {
-          "pain_context": { "score": 50, "source": "tool_failure", "reason": "edit failed" },
-          "code_locations": [{ "file": "src/hooks/pain.ts", "line": 78, "snippet": "fs.writeFileSync(path, content)" }]
-        }
-      },
-      "causal_chain": {
-        "chain": [
-          { "why": 1, "answer": "写入文件时目录不存在", "evidence": "error: ENOENT", "evidence_type": "log" },
-          { "why": 2, "answer": "代码没有检查目录是否存在", "evidence": "pain.ts:78", "evidence_type": "code" },
-          { "why": 3, "answer": "缺少文件写入前的目录检查门禁", "evidence": "hooks目录无相关检查", "evidence_type": "code" }
-        ],
-        "terminated_at": 3,
-        "termination_reason": "找到缺失的门禁机制"
-      },
-      "root_cause_classification": {
-        "root_cause": "缺少文件写入前的目录存在性检查门禁",
-        "category": "Design",
-        "guardrail_analysis": {
-          "existing_guards": [],
-          "failure_reason": "没有 pre-write 检查 hook",
-          "recommendation": "添加 before_file_write hook 检查目录存在性"
-        }
-      },
-      "principle_extraction": {
-        "principle": {
-          "id": "系统会自动分配",
-          "trigger_pattern": "fs\\.writeFileSync|writeFile|mkdirSync",
-          "action": "写入前检查目标目录是否存在，不存在则先创建",
-          "abstracted_principle": "任何写入操作必须确保目标环境的完整性",
-          "duplicate": false,
-          "rationale": "防止在目录不存在时写入失败",
-          "implementation": {
-            "type": "hook",
-            "target_file": "src/hooks/file-safety.ts",
-            "code_snippet": "if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });"
-          }
-        }
-      }
-    }
-  }
-}
-```
-
----
-
-现在开始执行分析任务。