principles-disciple 2.1.10 → 2.1.12

package/dist/core/signal-collector-host.d.ts

@@ -107,10 +107,26 @@ export declare class SignalCollectorHost {
      *
      * 只入队"词库命中过的歧义候选"：零命中的普通消息体量与噪声不可控，其纠正
      * 语义覆盖由 G3 的词库扩充/earned 解锁承担。
+     *
+     * AUDIT-P2-01: stage2Queued 计数推迟到微任务执行（本方法可从无 await 的
+     * 降级分支同步到达）；SQLite 入队本身保持同步——它是可靠性要求，不是旁路
+     * 观测，微任务/事件循环淘汰不能承担丢候选的风险。
      */
     private queueUnconfirmedForBatch;
-    /** PRI-788 G4: 未经确认就消失的候选计数（旁路，失败不阻塞）。 */
+    /**
+     * PRI-788 G4: 未经确认就消失的候选计数（旁路，失败不阻塞）。
+     * AUDIT-P2-01: 推迟到微任务——本计数可从无 await 的降级分支同步到达，
+     * 不能把健康文件读改写留在 before_prompt_build 的同步调用栈上。
+     */
     private countStage2Dropped;
+    /** AUDIT-P2-02: 入队计数（旁路），与 countStage2Dropped 同理推迟到微任务。 */
+    private countStage2Queued;
+    /**
+     * AUDIT-P2-02: Stage2 分类调用计数（旁路）。realtime 路径的调用点位于
+     * detectSync 的同步调用栈上（async 函数体首个 await 前同步执行），批量路径
+     * 虽在后台周期内，也复用同一惯例推迟到微任务，保证两种路径计数语义一致。
+     */
+    private countStage2Invocation;
     /**
      * PRI-788 G4: stage1Strong 计数（旁路观测），刻意离开同步检测路径。
      *

package/dist/core/signal-health.d.ts

@@ -4,6 +4,20 @@ export interface SignalHealthState {
     stage2Confirmed: number;
     stage2Queued: number;
     stage2Dropped: number;
+    /**
+     * AUDIT-P2-02 (2026-10-21): 当日实际发起的 Stage2 LLM 分类调用次数
+     * （realtime detectAsyncAndRoute + 批量确认 confirmPendingSignal 都算——
+     * 两者都是花同一个 signal classifier 的钱）。计数时点：真正发起 classifier
+     * 调用前；降级/空队列/未配置不计数。跨日归零；旧文件缺失按 0 读。
+     */
+    stage2Invocations: number;
+    /**
+     * AUDIT-P2-02 (2026-10-21): 当日因分类器不可用被整批跳过的批量确认次数。
+     * 只在「队列非空但 classifier 解析失败」时 +1（空队列不计数——没有工作被
+     * 跳过）。让 Owner 能区分「没检测到信号 / 没调用模型 / 队列没被消费」。
+     * 跨日归零；旧文件缺失按 0 读。
+     */
+    stage2BatchSkipped: number;
     /** 最近一次刷新的队列深度（非计数） */
     pendingCount: number;
     lastStage2SuccessAt: string | null;
@@ -16,6 +30,7 @@ export interface SignalHealthState {
 }
 /**
  * 读健康状态（doctor 用）。文件缺失/损坏返回 null，由读取方呈现 unknown。
+ * 旧格式（无 AUDIT-P2-02 新增计数字段）照常解析，缺省字段读作 0。
  */
 export declare function readSignalHealth(stateDir: string): SignalHealthState | null;
 /**

package/dist/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "principles-disciple",
   "name": "Principles Disciple",
   "description": "Principles Disciple is an AI Agent Governance System. Stop correcting the same AI behavior across sessions. Turn repeated Agent corrections into Owner-approved, observable, reversible behavior principles.",
-  "version": "2.1.10",
+  "version": "2.1.12",
   "activation": {
     "onStartup": true,
     "onCapabilities": [

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

@@ -1,90 +1,52 @@
 ---
 name: pd-cli-operator
-description: Use this skill when operating the Principles Disciple `pd` CLI: probing runtime health, manually recording pain, inspecting tasks/runs/candidates/artifacts, intaking candidates, viewing flow policy, or tracing pain-to-ledger chains. It routes CLI commands safely and forbids direct `.state/.pain_flag` writes.
+description: Use for read-only PD health checks, querying pains/tasks/runs/candidates/artifacts, tracing pain-to-principle evidence, or diagnosing PD CLI and Runtime issues. Do not use for pain registration, Owner governance review, or host setup/control.
 disable-model-invocation: false
 ---
 
 # PD CLI Operator
 
-Use the `pd` CLI as the supported operator surface. Do not modify PD state files by hand unless a command explicitly says to do so.
+Use the existing PD CLI to inspect facts and locate pipeline breaks. This skill routes operations; it does not implement a second business logic path.
 
-## Runtime V2 Pain Diagnosis
+## Workflow
 
-Manual pain diagnosis (bind a recorded session so diagnosis carries real
-trajectory evidence):
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
+1. **Resolve the workspace.** Use the authoritative workspace supplied by the current OpenClaw host/plugin context. When a command requires `--workspace`, pass the confirmed absolute path. If the workspace is unknown, report the blocker instead of guessing from the current directory or another host.
+2. **Discover actual commands.** Start with `pd --help`, then inspect the target command's `--help`. The installed CLI is authoritative.
+3. **Prefer read-only inspection.** Choose the smallest set of queries that answers the question; do not scan unrelated workspaces.
+4. **Trace each stage.** Verify pain registration, diagnostic task, run result, candidate, admission, and Owner governance separately. Never infer that the whole chain completed from one status field.
+5. **Report evidence.** Separate confirmed facts, unknowns, the blocked stage, and next steps. Distinguish command success from business success.
 
-- Without `--session` the record is an honest unbound Owner report: no
-  trajectory evidence, candidates likely gated (`needs_evidence`) by the
-  admission threshold — the CLI output warns about this.
-- `--session <id>` is validated up front; a missing session fails with
-  `session_not_found` before anything is written. 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 — no evidence is fabricated.
-- A successful command returning a `painId` is only a record receipt; whether
-  the diagnosis produced candidates and whether they were admitted is decided
-  by `candidateIds` / `admissionResults` / `ledgerEntryIds` in the JSON
-  output. Activation is a separate stage that follows Owner approval.
+## Common read-only commands
 
-Success requires:
-- `status` is `succeeded`
-- candidates are ADMITTED, not merely generated: check `admissionResults` /
-  `candidateOutcomes` for `admitted` decisions and non-empty `ledgerEntryIds`
+Confirm that the installed CLI supports a command before running it:
 
-Forbidden:
-- Do not write `.state/.pain_flag`.
-- Do not use `write_file`, shell redirection, `Set-Content`, `Out-File`, or `node -e` to create pain flags.
+- Health: `pd health --workspace "<workspace>" --json`
+- Runtime probe: `pd runtime probe --runtime pi-ai --workspace "<workspace>" --json`
+- Flow policy: `pd runtime flow show --workspace "<workspace>" --json`
+- Pain list and admission evidence: `pd pain list --workspace "<workspace>" --json`, `pd pain evidence --workspace "<workspace>" --json`
+- Pain-to-principle trace: `pd runtime trace show --pain-id "<painId>" --workspace "<workspace>" --json`
+- Task and run: `pd task show "<taskId>" --workspace "<workspace>" --json`, `pd run show "<runId>" --workspace "<workspace>"`
+- Candidates and artifacts: `pd candidate list --task-id "<taskId>" --workspace "<workspace>" --json`, `pd candidate show "<candidateId>" --workspace "<workspace>" --json`, `pd artifact show "<artifactId>" --workspace "<workspace>" --json`
 
-## Health And Policy
+OpenClaw's `/pd-status` primarily reports host status such as GFI/Pain dictionary; it is not a substitute for Runtime health or tracing a specific task.
 
-Runtime probe:
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
+## Interpret results correctly
 
-Flow policy:
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
+- A `painId` proves only that pain registration returned a receipt.
+- Task creation does not prove diagnosis completed.
+- Candidate generation does not prove admission; inspect the actual admission decision and corresponding ledger evidence.
+- Admission does not prove Owner approval or activation; opening the Console does not prove a governance decision was made.
 
-## Trace Pain-To-Ledger Chain (PRI-455 promoted)
+## Writes and failures
 
-Trace the full evidence chain from pain signal to principle ledger:
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
+This skill is read-only by default. Before any retry, recovery, repair, or other side effect, confirm user intent, command help, eligibility, and impact. Use dry-run first when supported and read back the resulting state afterward. Do not blindly retry commands that may have side effects.
 
-## Activation Management (PRI-455 promoted)
+When the CLI is unavailable, preserve the actual error and distinguish missing installation, uninitialized workspace, insufficient permissions, and Runtime failure. Route host installation, initialization, disablement, or recovery to `pd-control`.
 
-List active activations:
-```bash
-pd activation list --workspace "<workspace>" --json
-```
+## Never
 
-Deactivate (rollback) an activation:
-```bash
-pd activation deactivate --activation-id "<activationId>" --workspace "<workspace>" --json
-```
-
-## Inspect Runtime V2 Objects
-
-Tasks and runs:
-```bash
-pd task show --task-id "<taskId>" --json
-pd run show --run-id "<runId>" --json
-```
-
-Candidates and artifacts:
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-pd artifact show --artifact-id "<artifactId>" --workspace "<workspace>" --json
-```
-
-Manual intake:
-```bash
-pd candidate intake --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
+- Edit the database, ledger, configuration, or internal artifacts directly.
+- Write `.state/.pain_flag` or call legacy `write_pain_flag`.
+- Fabricate runtime evidence or present a hypothesis as a confirmed root cause.
+- Approve, reject, or activate a principle through CLI, scripts, or another skill.
+- Treat exit code 0 as automatic proof of business success.

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

@@ -0,0 +1,50 @@
+---
+name: pd-control
+description: Use when the Owner explicitly requests installation, initialization, disablement, re-enablement, or repair of PD host integration. Use only management entrypoints supported by the current host; do not edit configuration or business state directly.
+disable-model-invocation: false
+---
+
+# PD Control
+
+## Purpose
+
+Manage PD integration through the official installer and host management surface. This skill is a constrained router; it does not duplicate installer logic or mutate principle, candidate, task, or ledger state.
+
+## Current OpenClaw support
+
+### Install or initialize
+
+Only when the Owner explicitly requests installation/initialization, use the documented non-interactive installer:
+
+    npx create-principles-disciple --yes
+
+Check the installed version's help and prerequisites first. Do not claim success when authorization, network, or dependency requirements are missing. After installation, use `pd-cli-operator` for a read-only health check.
+
+### Disable
+
+Only when the Owner explicitly requests disablement, run:
+
+    openclaw plugins disable principles-disciple
+
+This uses OpenClaw's official plugin-management route and does not delete installed files. Then inspect `openclaw plugins list --enabled --json` and confirm `principles-disciple` is no longer enabled. When a Gateway is running, the command applies the state change through that Gateway; distinguish a disabled switch from proof that every previously started task has stopped.
+
+### Enable or resume
+
+Only when the Owner explicitly requests enablement, run:
+
+    openclaw plugins enable principles-disciple
+
+If the command reports capability consent, allowlist, denylist, or another policy block, do not automatically add `--accept-capabilities` and do not edit `openclaw.json` by hand. Preserve the full receipt and explain the required choice or policy issue to the Owner. Continue with the exact retry command returned by OpenClaw only after the Owner explicitly consents to the requested capabilities.
+
+Afterward, inspect `openclaw plugins list --enabled --json`, then run `openclaw plugins inspect principles-disciple --runtime --json` to check registered runtime capabilities. A cold inventory or inspect result alone still does not prove a real Hook is effective; when needed, verify with a safe real host event.
+
+## Success criteria
+
+Distinguish installer success, host plugin discovery, actual Hook execution, and PD business-pipeline health. Each requires its own receipt or runtime evidence. Plugin presence does not prove it is enabled, and installation does not prove Runtime health.
+
+## Never
+
+- Edit host configuration or PD state files by hand.
+- Overwrite user configuration or delete business data to disable PD.
+- Approve, reject, or activate principles through CLI, scripts, or another skill.
+- Report an unverified host operation as successful.

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

@@ -1,71 +1,45 @@
 ---
 name: pd-pain-signal
-description: Manually trigger a Principles Disciple Runtime V2 pain diagnosis. Use this when the user reports the agent is stuck, looping, unresponsive, or asks to record/trigger a pain signal. In an OpenClaw session, direct the Owner to the /pd-pain command (it binds the real session automatically). From outside a session, use `pd pain record --session <id>`. Never write `.state/.pain_flag` and never use legacy write_pain_flag tooling.
+description: Use when the Owner explicitly asks to record an agent behavior problem, register a pain signal, or trace whether feedback entered the diagnostic pipeline. Automatic pain detection remains the responsibility of existing hooks, host entrypoints, and Runtime.
 disable-model-invocation: false
 ---
 
-# Pain Signal (Runtime V2)
+# PD Pain Signal
 
-Session evidence is what lets a diagnosis carry real trajectory evidence. A
-pain recorded without a session is a legal unbound Owner report: it carries no
-trajectory evidence, its diagnosis confidence tends to be low, and its
-candidates are likely gated as `needs_evidence` by the admission gate — the
-Owner's report is stored, but usually nothing is internalized.
+## Purpose
 
-## In an OpenClaw session (preferred)
+Send the Owner's real behavior feedback through the existing PD pain-registration and diagnosis pipeline while preserving the original statement, source, and available session evidence. This skill does not reimplement detection, deduplication, admission, or diagnosis.
 
-Ask the Owner to run the host command in the conversation where the pain
-occurred:
+## Steps
 
-```text
-/pd-pain <describe the issue>
-```
+1. **Check whether it was already recorded.** The current message may already have been handled by a hook or host entrypoint. If a real receipt exists, reuse its pain/task IDs. Do not submit a duplicate. If registration is not observable, do not claim success or blindly retry.
+2. **Preserve the Owner's words.** Use only a statement the Owner explicitly provided. Do not add a technical root cause, score, or tool-failure fact. Quoted text, tool output, and model paraphrases must not be presented as a new Owner submission.
+3. **Use the trusted host entrypoint.**
+   - In the OpenClaw session where the issue occurred, when the Owner explicitly requests registration, use the host command `/pd-pain <issue description>`. OpenClaw binds the authenticated current session.
+   - Outside the session, use the CLI only with a known, validated session: `pd pain record --reason "<reason>" --workspace "<workspace>" --session "<session-id>" --json`.
+4. **Do not guess session IDs.** Never scan the database, pick the "latest" session, or substitute another host's ID. If the required session identity is missing, stop that CLI path and explain why.
+5. **Verify the receipt.** Report registration only when the actual receipt confirms it. Without a receipt, say registration is unconfirmed.
 
-`/pd-pain` receives the authenticated current session from OpenClaw and
-submits the session's trajectory evidence automatically. You cannot obtain a
-trusted session ID yourself (none is injected into tool executions); never
-guess, scan, or pick the "latest" session.
+## Evidence and success criteria
 
-## Outside a session (CLI)
+- A real pain ID proves only that registration returned a receipt, not that diagnosis completed.
+- Generated candidates are not necessarily admitted.
+- Check the actual `admissionResults` / `candidateOutcomes` for an `admitted` decision and its non-empty `ledgerEntryIds`. A non-empty `candidateIds` alone is not success.
+- Report `needs_evidence`, `deferred`, and explicit admission rejection honestly. Never bypass the admission gate or fabricate trajectory evidence to increase confidence.
+- The Owner's statement, host trajectory, model diagnosis, admission result, Owner approval, and activation state are distinct evidence types.
 
-Bind an explicitly known session id recorded in this workspace:
+## Failure handling
 
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
+- Registration failure: preserve the real error and the host-provided next action.
+- Duplicate risk: check existing receipts and idempotency first.
+- Missing or untrusted session: stop; never guess.
+- CLI/hook unavailable: ask `pd-cli-operator` to inspect status; route installation repair to `pd-control`.
+- If the Owner wants to inspect resulting candidates, use `pd-review` to open the Console; do not re-register the same feedback.
 
-- `--session <id>` is validated against the workspace trajectory: a missing
-  session fails with `session_not_found` before anything is written.
-- When the `--session` binding is verified but the trajectory evidence is
-  empty or unreadable (the session is real), the record is submitted as an
-  honest bound + evidence-unavailable degrade: no evidence is fabricated and
-  the admission gate decides what empty evidence is worth, instead of a hard
-  refusal.
-- Recording without `--session` is allowed as an unbound Owner report, but it
-  attaches no evidence and its candidates will likely be gated
-  (`needs_evidence`) by the admission gate — the CLI output says so explicitly.
+## Never
 
-## Forbidden
-
-- Do not write `.state/.pain_flag` directly.
-- 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 `write_pain_flag`. That was a legacy path.
-- Do not guess, scan for, or infer a session ID. Use `/pd-pain` or an id the Owner provides.
-
-## Verify
-
-Use:
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-pd candidate list --workspace "<workspace>" --json
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-Success requires admitted candidates, not merely generated ones: check
-`admissionResults` for `admitted` decisions and non-empty `ledgerEntryIds`.
-A successful command returning a `painId` is only a record receipt — it does
-not mean the diagnosis produced candidates or that anything was admitted.
-Candidates reported as `needs_evidence` or `deferred` were NOT internalized —
-if candidates are gated, re-record with `/pd-pain` or `--session` so the
-diagnosis carries real trajectory evidence. Activation is a separate stage
-that follows Owner approval; this flow never activates anything by itself.
+- Write `.state/.pain_flag` or call legacy `write_pain_flag`.
+- Fabricate the Owner's words, session ID, turn ID, or tool failure.
+- Re-submit an event whose registration is confirmed.
+- Modify the pain database, candidate ledger, or admission state directly.
+- Approve, activate, or edit a principle.

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

@@ -0,0 +1,32 @@
+---
+name: pd-review
+description: Use when the Owner wants to inspect PD diagnoses, principle candidates, or governance state, or asks to approve, reject, or activate a principle. Every Owner decision must be completed by the Owner in the official Web Console.
+disable-model-invocation: false
+---
+
+# PD Review
+
+## Purpose
+
+Help the Owner inspect real evidence and reach the official PD governance interface. The skill may query, explain, and open the Console, but it cannot make the decision for the Owner.
+
+## Workflow
+
+1. Confirm the task concerns PD pain, diagnosis, candidates, or principle governance—not ordinary code review.
+2. Use `pd-cli-operator` or an existing real receipt to verify state. Distinguish the Owner's statement, host trajectory, model diagnosis, admission decision, and completed governance action.
+3. Open the Console using the workspace confirmed by the current OpenClaw host: `pd console open --workspace "<workspace>"`. Never guess the workspace.
+4. Report that the Console started only when the command returns real success. If it fails, preserve the error and route host-installation diagnosis to `pd-control`.
+5. Ask the Owner to inspect the evidence and personally complete approval, rejection, or another governance action in the Console.
+
+## State boundaries
+
+- A candidate's existence does not mean it was approved.
+- Opening the Console does not mean it was approved.
+- The Owner saying "approve" does not prove the Console action has completed.
+- Approval, activation, and a subsequent behavior change are separate stages and must be verified separately.
+
+## Never
+
+- Approve, reject, or activate a principle through CLI, scripts, databases, files, or another skill.
+- Fall back to CLI approval when the Console is unavailable.
+- Fabricate an Owner decision or describe candidate generation/admission as activation.

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

@@ -1,85 +1,52 @@
 ---
 name: pd-cli-operator
-description: 操作 Principles Disciple `pd` CLI 时使用：运行时健康检查、手动记录痛苦、查看 task/run/candidate/artifact、intake candidate、查看 flow policy、追踪痛苦到原则的证据链。本技能提供安全 CLI 路由，并禁止直接写 `.state/.pain_flag`。
+description: 当需要只读检查 PD 运行健康、查询痛苦/任务/运行/候选/工件，或追踪痛苦到原则的证据链时使用。用于 PD CLI 与 Runtime 排障；不用于登记痛苦、Owner 治理审阅或宿主管理。
 disable-model-invocation: false
 ---
 
 # PD CLI Operator
 
-把 `pd` CLI 当作唯一受支持的操作界面。不要手工修改 PD state 文件，除非某个 CLI 命令明确要求这样做。
+通过现有 PD CLI 查询事实、定位链路断点，并给出基于证据的结论。本技能只负责操作路由，不实现第二套业务逻辑。
 
-## Runtime V2 痛苦诊断
+## 工作流程
 
-手动痛苦诊断（绑定已记录的会话，让诊断携带真实轨迹证据）：
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
+1. **确认工作区。** 使用当前 OpenClaw 宿主/插件上下文提供的权威工作区。命令要求 `--workspace` 时传入已确认的绝对路径。无法确定工作区就先报告阻塞，不要从当前目录、最近目录或其他宿主猜测。
+2. **发现真实命令。** 先检查 `pd --help`，再检查目标命令的 `--help`。命令名和参数以当前安装版本为准。
+3. **优先只读检查。** 按问题选择最少的查询命令，不遍历无关工作区。
+4. **逐段追踪。** 分别核实痛苦登记、诊断任务、运行结果、候选、准入和 Owner 治理结果，不由单个状态字段推断整条链路已完成。
+5. **报告证据。** 说明已确认事实、未知部分、阻塞层和下一步；区分命令成功与业务目标成功。
 
-- 不带 `--session` 的记录是诚实的 unbound Owner 报告：没有轨迹证据，
-  候选大概率被准入阈值拦为 `needs_evidence` —— CLI 输出会明确警告。
-- `--session <id>` 会先校验；会话不存在时以 `session_not_found` 失败，
-  不会写入任何内容。会话验证通过但轨迹证据为空或不可读时，按
-  bound + 证据不可用诚实降级提交，由 admission gate 评判，不会伪造证据。
-- 命令成功返回 `painId` 只代表记录回执；诊断是否产出候选、候选是否被
-  准入，以 JSON 输出中的 `candidateIds` / `admissionResults` /
-  `ledgerEntryIds` 为准。激活是 Owner 批准之后的独立阶段。
+## 常用只读命令
 
-成功标准：
-- `status` 是 `succeeded`
-- 候选被**准入**而非仅被生成：检查 `admissionResults` /
-  `candidateOutcomes` 中的 `admitted` 决策和 `ledgerEntryIds` 非空
+先确认当前 CLI 支持这些命令，再按需执行：
 
-禁止：
-- 不要写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File` 或 `node -e` 创建 pain flag。
+- 健康检查：`pd health --workspace "<workspace>" --json`
+- Runtime 探针：`pd runtime probe --runtime pi-ai --workspace "<workspace>" --json`
+- 流程策略：`pd runtime flow show --workspace "<workspace>" --json`
+- 痛苦列表与准入证据：`pd pain list --workspace "<workspace>" --json`、`pd pain evidence --workspace "<workspace>" --json`
+- 痛苦到原则的追踪：`pd runtime trace show --pain-id "<painId>" --workspace "<workspace>" --json`
+- 任务与运行：`pd task show "<taskId>" --workspace "<workspace>" --json`、`pd run show "<runId>" --workspace "<workspace>"`
+- 候选与工件：`pd candidate list --task-id "<taskId>" --workspace "<workspace>" --json`、`pd candidate show "<candidateId>" --workspace "<workspace>" --json`、`pd artifact show "<artifactId>" --workspace "<workspace>" --json`
 
-## 健康检查和策略
+OpenClaw 的 `/pd-status` 主要展示 GFI/Pain 词典等宿主状态，不应代替 Runtime 健康检查或具体任务追踪。
 
-运行时探针：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
+## 结果判定
 
-业务流策略：
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
+- `painId` 只证明痛苦登记有回执。
+- 任务创建不等于诊断完成。
+- 候选生成不等于通过准入；必须检查实际 admission 决策及对应账本证据。
+- 准入成功不等于 Owner 已批准或原则已激活；打开 Console 也不等于完成治理决定。
 
-## 追踪痛苦到原则链（PRI-455 提升）
+## 写操作与失败
 
-追踪从痛苦信号到原则账本的完整证据链：
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
+本技能默认只读。若需要重试、恢复、修复或其他有副作用的操作，先确认用户意图、命令帮助、资格条件和影响范围；支持时先 dry-run，执行后读回真实状态。不要盲目重试可能产生副作用的命令。
 
-## 激活管理（PRI-455 提升）
+CLI 不可用时，保留真实错误并区分未安装、工作区未初始化、权限不足与 Runtime 故障。需要安装、初始化、停用或恢复宿主接入时转交 `pd-control`。
 
-列出当前激活：
-```bash
-pd activation list --workspace "<workspace>" --json
-```
+## 禁止
 
-停用（回滚）激活：
-```bash
-pd activation deactivate --activation-id "<activationId>" --workspace "<workspace>" --json
-```
-
-## 查看 Runtime V2 对象
-
-Tasks 和 runs：
-```bash
-pd task show --task-id "<taskId>" --json
-pd run show --run-id "<runId>" --json
-```
-
-Candidates 和 artifacts：
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-pd artifact show --artifact-id "<artifactId>" --workspace "<workspace>" --json
-```
-
-手动 intake：
-```bash
-pd candidate intake --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
+- 不直接修改数据库、账本、配置或内部工件。
+- 不写 `.state/.pain_flag`，不调用 legacy `write_pain_flag`。
+- 不伪造运行证据或把推测写成已确认根因。
+- 不通过 CLI、脚本或其他技能批准、拒绝或激活原则。
+- 不将命令退出码为 0 自动等同于业务成功。

package/dist/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、脚本或其他技能批准、拒绝或激活原则。
+- 不将未验证的宿主操作报告为成功。