@c4a/context-cli 0.6.1 → 0.6.3

package/docs/context-debug-event-v1.schema.json

@@ -0,0 +1,29 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://context4.ai/schemas/context-debug-event-v1.schema.json",
+  "title": "Context debug event v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "trace_id", "sequence", "at", "kind", "data"],
+  "properties": {
+    "schema": { "const": "context.debug.event.v1" },
+    "trace_id": { "type": "string", "minLength": 1 },
+    "sequence": { "type": "integer", "minimum": 1 },
+    "at": { "type": "string", "format": "date-time" },
+    "kind": {
+      "enum": [
+        "debug.enabled",
+        "debug.disabled",
+        "cli.invoked",
+        "cli.completed",
+        "agent-graph.evaluated",
+        "workflow.action-started",
+        "workflow.action-completed",
+        "workflow.stopped"
+      ]
+    },
+    "invocation_id": { "type": "string", "minLength": 1 },
+    "parent_invocation_id": { "type": "string", "minLength": 1 },
+    "data": { "type": "object" }
+  }
+}

package/docs/context-debug-replay-v1.schema.json

@@ -0,0 +1,33 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://context4.ai/schemas/context-debug-replay-v1.schema.json",
+  "title": "Context debug replay v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "generated_at", "events", "transitions"],
+  "properties": {
+    "schema": { "const": "context.debug.replay.v1" },
+    "generated_at": { "type": "string", "format": "date-time" },
+    "trace_id": { "type": "string" },
+    "events": {
+      "type": "array",
+      "items": { "$ref": "./context-debug-event-v1.schema.json" }
+    },
+    "transitions": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["sequence", "at", "current"],
+        "properties": {
+          "sequence": { "type": "integer", "minimum": 1 },
+          "at": { "type": "string", "format": "date-time" },
+          "invocation_id": { "type": "string" },
+          "previous": { "type": "object" },
+          "current": { "type": "object" },
+          "selected_route": { "type": "object" }
+        }
+      }
+    }
+  }
+}

package/docs/debug-tracing.md

@@ -0,0 +1,86 @@
+# Workspace debug tracing
+
+Context debug tracing is an explicit, workspace-local observation mode. It is
+disabled by default. It does not change Agent Graph facts, route selection,
+human gates, command eligibility, lifecycle writes, or command exit status.
+
+Enable it while initializing a workspace:
+
+```bash
+context init context --debug
+```
+
+Or enable it later:
+
+```bash
+context debug enable
+```
+
+Both forms set `package.json` `context.debug` to `true`. Disabling tracing
+removes that property but keeps the existing trace for inspection:
+
+```bash
+context debug disable
+```
+
+## Files
+
+Tracing writes only below the ignored workspace `.tmp` directory:
+
+```text
+.tmp/context-runtime/debug/
+├── events.jsonl
+├── state.json
+└── replay.json
+```
+
+- `events.jsonl` is the append-only source of truth. Each line conforms to
+  [`context.debug.event.v1`](./context-debug-event-v1.schema.json).
+- `state.json` owns the trace id, monotonic sequence, and last observed graph
+  state. It is recorder state, not workflow state.
+- `replay.json` is a disposable projection produced by `context debug export`
+  and conforms to [`context.debug.replay.v1`](./context-debug-replay-v1.schema.json).
+
+No command stdout, source body, knowledge page, or resource body is copied into
+the trace. Sensitive option values are redacted. Command receipts contain only
+status, duration, byte counts, and hashes already available to the managed
+runner.
+
+## Event model
+
+The event stream records:
+
+- CLI invocation and completion, including parent invocation identity for
+  managed child commands;
+- Agent Graph evaluation revision, status, selected route, alternatives, and
+  whether the observable graph position changed;
+- managed workflow action start and completion with deterministic receipts;
+- the reason and graph position at which a managed loop stopped.
+
+`trace_id` groups the workspace-local debug history, `sequence` defines replay order,
+`invocation_id` groups work performed by one CLI process, and
+`parent_invocation_id` connects managed child commands to their runner. A UI
+can animate `agent-graph.evaluated` events whose `data.transition.changed` is
+true, then associate intervening command and action events by sequence and
+invocation identity.
+
+## Inspect and export
+
+```bash
+context debug status --format json
+context debug export --format json
+```
+
+Status returns configuration, event counts, and relative trace paths. Export
+mechanically derives a replay document containing the complete event stream and
+its changed graph transitions. A custom export path must remain below the
+workspace `.tmp` directory:
+
+```bash
+context debug export --output .tmp/analysis/replay.json --format json
+```
+
+Recorder failures are intentionally non-fatal. They can make a trace
+incomplete, but they cannot alter the command being observed. Consumers should
+therefore validate monotonic `sequence` values before presenting a replay as
+complete.

package/docs/quickstart.md

@@ -31,6 +31,13 @@ Create a standalone workspace:
 context init context
 ```
 
+Choose the generated workspace and starter-template language explicitly when
+needed; the CLI does not infer it from terminal locale or conversation text:
+
+```bash
+context init context --language zh-CN
+```
+
 Then enter it and install dependencies:
 
 ```bash
@@ -44,8 +51,8 @@ After initialization, read the workspace guidance:
 AGENTS.md
 ```
 
-`AGENTS.md` explains the current project, SDK references, plugin Skills, and
-the safe workflow for agents. It is the project-local starting point after
+`AGENTS.md` explains the current project, SDK references, installed Agent
+entry, and safe workflow contract. It is the project-local starting point after
 `context init`.
 
 ## 3. Work Through an Agent
@@ -54,15 +61,26 @@ Inside the workspace, ask the installed agent plugin to continue the workflow.
 The agent should:
 
 1. read `AGENTS.md`;
-2. run `context status`;
-3. follow the status `next` hint and CLI diagnostics;
-4. stop at human gates such as source scope, structure confirmation, review,
+2. run `context status --format json`;
+3. treat `workflow.current` as the current-step authority, read each
+   `resources.required` item, and execute only the returned command or
+   configuration action;
+4. at a Gate, load an `inspection_action` Skill or Schema only for
+   pre-decision inspection and a `resolution_action` Skill or Schema only
+   after confirmation;
+5. stop at human gates such as source scope, structure confirmation, review,
    and package decisions.
 
 The CLI performs mechanical work such as source registration, capture,
 validation, review application, verify, close, and build. The agent performs
 semantic judgment only when the workflow asks for it.
 
+When the user explicitly requests fully managed operation, the Agent starts with
+`context run --managed --until blocked-or-complete --format json` to collapse
+consecutive deterministic routes. The CLI re-evaluates every revision and
+stops before semantic reads, configuration, missing authority, diagnostics, or
+multiple commands.
+
 ## 4. Manual Orientation
 
 When operating without an agent plugin, start with:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@c4a/context-cli",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "type": "module",
   "description": "Local CLI for capturing, compiling, and governing knowledge workspaces",
   "license": "MIT",
@@ -16,12 +16,17 @@
     "claude-code",
     "claude-plugin"
   ],
+  "engines": {
+    "node": ">=20"
+  },
   "bin": {
-    "context": "cli.js"
+    "context": "dist/cli.js"
   },
   "dependencies": {
-    "@c4a/context": "0.6.1",
+    "@c4a/agent-graph": "0.2.4",
+    "@c4a/context": "0.6.3",
     "commander": "^11.0.0",
+    "fast-xml-parser": "^5.10.1",
     "handlebars": "^4.7.8",
     "ink": "^5.0.0",
     "jiti": "^2.7.0",

package/plugins/README.md

@@ -4,155 +4,97 @@
 
 <p align="center"><img src="./assets/logo.svg" alt="C4A Context" width="180"/></p>
 
-Context provides agent commands for maintaining a project-local knowledge workspace. The plugin is installed globally for the agent, while each workspace keeps its own sources, pending review state, approved knowledge, and build output. Public agent entrypoints are intentionally small: initialize once, then use next-step guidance.
-
-Agent dialogue should follow the user's current conversation language. CLI
-commands, flags, ids, status values, JSONL keys, and `source_ref` tokens are
-protocol text and stay unchanged.
+Context provides a thin Agent entry for project-local knowledge workspaces. The
+plugin does not embed the whole workflow in one prompt. It starts from current
+workspace facts, then Context CLI selects the legal route, commands, gates, and
+Markdown/schema resources for that step.
 
 ## Install
 
-Install the CLI first:
-
 ```bash
 npm i -g @c4a/context-cli
-# or
-bun add -g @c4a/context-cli
-```
-
-Then install the bundled plugin marketplace globally:
-
-```bash
 context plugin install
 ```
 
-The installer resolves the plugin marketplace from the installed CLI package. Published packages use `dist/plugins`; source checkouts use the same generated tree after `bun run --filter @c4a/context-cli build`. For Codex, it materializes the bundled plugin into `~/.codex/plugins/cache/c4a/context/local/`, matching Codex's local-plugin cache convention.
-
-For a dry run:
+For a source checkout, build the CLI and plugin first:
 
 ```bash
-context plugin install --dry-run
-context plugin path
+bun run --filter @c4a/context-cli build
+context plugin install --dev
 ```
 
-## Workflow
+Use `context plugin install --dry-run` to inspect installation and
+`context plugin path` to locate the bundled marketplace.
 
-Run commands from the context project root.
+## Agent entry
 
-1. Initialize a workspace:
+The public host surface stays small:
 
-   ```bash
-   context init context
-   cd context
-   bun install
-   ```
+- `init` creates a Context workspace;
+- `continue` observes and advances an existing workspace.
 
-2. Continue through the installed agent entry:
+Continuation starts with:
 
-   ```bash
-   <host-specific Context continuation command or skill>
-   ```
+```bash
+context status --format json
+```
 
-The continuation entry first runs `context status`, then follows CLI diagnostics. It
-executes safe mechanical `next:` steps instead of only reporting them, and stops
-at `Human gate:` / placeholder next steps, source registration, source scope
-selection, review, package output choice, or source-repo operations that require
-user approval. It must not infer repo sources or extraction scope from the
-surrounding monorepo.
-It uses lower-level CLI primitives only when the workspace state requires them:
+`workflow.current` is the current-step authority. The Agent reads every required
+resource marked `read_state: read-required`, executes only returned commands,
+preserves revision and authority flags, and reevaluates status after each
+action. Current-conversation read receipts may be passed back through
+`context status --resource-receipts @<file>` so unchanged resources are marked
+`current`. A dynamic materialization becomes a receipt only after the Agent
+reads the complete returned file. `context.source-body/*` resources are source
+text; source indexes and heading metadata never replace the body. Long procedures and semantic
+judgment rules are published in the Context workflow bundle and loaded only
+when the current route or operation selects them.
 
-- `context source ...`
-- `context run ...`
-- `context review ...`
-- `context close`
-- `context build`
-- `context verify`
+Gate inspection and resolution Actions keep their own Skill and Schema
+locators. The Agent loads those conditional resources only when it enters that
+phase; they are not preloaded with the Route's ordinary required resources.
 
-When the user explicitly requests fully managed operation in the current
-conversation, continuation uses `context status --managed --format json` and
-follows its managed commands. Eligible classification, extraction-scope,
-structure-confirmation, Review, and package-output gates proceed automatically;
-source boundaries, unread source permission, external operations, and
-validation failures remain gated. No managed policy is written to the project,
-and a new conversation returns to ordinary gates.
+The two entry documents are also the source for hosts that expose Agent Skills
+instead of commands. There are no stage-specific skills: source, alignment,
+compile, review, and package guidance comes from the route-selected workflow
+resources.
 
-## SDK Manual For Agents
+## Human gates and managed sessions
 
-After `bun install`, the project has a local SDK manual under:
+Ordinary mode preserves source, read-permission, scope, structure, Review, and
+package decisions as explicit gates. Fully managed mode is available only when
+the user explicitly requests it in the current conversation:
 
-```text
-node_modules/@c4a/context/docs/
+```bash
+context status --managed --format json
 ```
 
-Recommended files:
-
-- `node_modules/@c4a/context/docs/guides/agent-dialogue.md`
-- `node_modules/@c4a/context/docs/guides/agent-guide.md`
-- `node_modules/@c4a/context/docs/reference/project-api.md`
-- `node_modules/@c4a/context/docs/reference/package-templates.md`
+That session authority is not stored. It cannot choose source boundaries,
+authorize unread external content, perform external repository operations, or
+bypass validation and verification.
 
-Template examples are installed at:
+After the initial managed status, consecutive deterministic routes can be
+collapsed with:
 
-```text
-node_modules/@c4a/context/templates/package-templates/
+```bash
+context run --managed --until blocked-or-complete --format json
 ```
 
-Agents should read these files instead of probing `node_modules/@c4a/context/dist`
-with ad-hoc scripts.
-
-## Workspace Shape
-
-Committed project state lives in:
-
-- `src/` — project flow and custom code;
-- `sources/repo/index.yaml`, `sources/file/index.yaml`, and
-  `sources/lark/index.yaml` — source registries;
-- `unapproved/entities.jsonl` — draft/rejected/deprecated metadata;
-- `unapproved/structure.yaml` — unconfirmed or confirmed prose structure draft;
-- `knowledge/` — approved Markdown;
-- `knowledge/structure.yaml` — closed structure/edge projection derived from
-  approved knowledge;
-- `dist/` — built packages;
-- `README.md`, `AGENTS.md`, `package.json`.
-
-Runtime scratch lives in `.tmp/context-runtime/` and is ignored.
-
-## Agent Entry Points
-
-The global plugin exposes only the user-facing Context commands for the current workspace:
+The loop stops before any route that needs Agent interpretation, configuration,
+additional authority, or diagnostic repair, and returns the current workflow
+route for normal progressive loading.
 
-- `init`
-- `continue`
+## Workspace and SDK
 
-The CLI still provides lower-level primitives, but they are not public slash
-commands. The continuation entry chooses them based on CLI output and user intent.
+Run the plugin from the initialized Context project root. Project declarations
+live in `src/index.ts`; source state, draft state, approved knowledge, generated
+packages, and disposable runtime state remain owned by Context CLI.
 
-Current source registration, document capture discipline, structure planning,
-node classification, reading density, candidate resolution, edge gates,
-source-bound section drafting, refresh/update judgment, semantic conflict
-judgment, and close guidance live in internal procedures under
-`skill-source-scope`, `skill-prose-align`, and `skill-prose-compile`.
+After workspace dependency installation, the SDK manual starts at:
 
-Package-time querying is generated into each built package as the
-`knowledge-query` skill. Package output decisions live in `skill-package-output`.
-The current workflow does not expose source deletion, purge, or retraction
-commands. If a user asks for that kind of lifecycle change, stop and explain
-that the current plugin has no approved gate for it; do not recreate
-file-mutating operations outside the current workflow.
-
-Agents should follow the current status route and internal procedures. Do not
-call or reconstruct command shapes or payload protocols that are absent from the
-current CLI/schema views.
-
-The CLI performs mechanical work only. It does not clone, checkout, reset, fetch, or call an LLM silently. When source repos are missing or at the wrong commit, it reports diagnostics and expects the agent to ask the user before running external repo operations.
-
-## Current Workflow Surface
-
-This plugin exposes the current workflow through `init` and `continue`.
-`continue` starts from `context status`, follows the status route, and delegates
-to current source/capture phases, prose align evidence views, source-bound prose
-compile, review, close, verify/build/status guidance, OKF indexes, generated
-knowledge-query skills, and declared project phase previews.
+```text
+node_modules/@c4a/context/docs/README.md
+```
 
-Agents must not simulate lifecycle or retraction work by deleting workspace
-files. Source deletion, purge, and retraction are not current plugin operations.
+The plugin does not expose source deletion, purge, or retraction. It also does
+not silently clone, fetch, checkout, install, build, test, or call an LLM.

package/plugins/README_CN.md

@@ -4,139 +4,88 @@
 
 <p align="center"><img src="./assets/logo.svg" alt="C4A Context" width="180"/></p>
 
-Context 提供面向 Agent 的知识工作区命令。Plugin 安装到全局 Agent 环境;每个知识工作区只保存自己的源声明、待审状态、已批准知识和构建产物。公开入口刻意收口:初始化一次,之后通过 next-step guidance 推进。
-
-Agent 与用户对话时应使用当前对话语言;CLI 命令、参数、id、状态枚举、JSONL key 和 `source_ref` 属于协议文本,保持英文或原样。
+Context 为项目内知识工作区提供轻量 Agent 入口。Plugin 不会把完整工作流塞进
+一份提示词，而是先观察当前工作区事实，再由 Context CLI 选择当前步骤允许的
+路线、命令、门禁以及 Markdown/schema 资源。
 
 ## 安装
 
-先安装 CLI:
-
 ```bash
 npm i -g @c4a/context-cli
-# 或
-bun add -g @c4a/context-cli
-```
-
-再把随 CLI 包发布的 plugin marketplace 安装到全局:
-
-```bash
 context plugin install
 ```
 
-安装器会从当前 CLI 包动态解析 marketplace 目录。发布包使用 `dist/plugins`;源码 checkout 在执行 `bun run --filter @c4a/context-cli build` 后也使用同样的生成目录。对 Codex,安装器会把随包生成的插件复制到 `~/.codex/plugins/cache/c4a/context/local/`,符合 Codex 本地插件的 cache 约定。
-
-只查看将执行的操作:
+源码开发模式需要先构建：
 
 ```bash
-context plugin install --dry-run
-context plugin path
+bun run --filter @c4a/context-cli build
+context plugin install --dev
 ```
 
-## 工作流
+可用 `context plugin install --dry-run` 查看安装动作，用
+`context plugin path` 定位随 CLI 发布的 marketplace。
 
-在 context 项目根目录执行命令。
+## Agent 入口
 
-1. 初始化工作区:
+公开入口保持精简：
 
-   ```bash
-   context init context
-   cd context
-   bun install
-   ```
+- `init`：创建 Context 工作区；
+- `continue`：观察并推进已有工作区。
 
-2. 通过已安装的 Agent 入口继续推进:
+Continuation 从以下命令开始：
 
-   ```bash
-   <当前宿主暴露的 Context continuation command 或 skill>
-   ```
+```bash
+context status --format json
+```
 
-Continuation 入口会先运行 `context status`,然后跟随 CLI 诊断。安全的机械 `next:` 步骤会直接执行,不会只把命令复述给用户;遇到 `Human gate:`、带占位符的 next、source 注册、source 范围选择、审阅、package 输出选择或需要用户授权的 source repo 操作才会停下来确认。它不能根据周边 monorepo 自行推断 repo source 或提取范围,只在工作区状态需要时调用底层 CLI 能力:
+`workflow.current` 是当前步骤的权威协议。Agent 读取所有标记为
+`read_state: read-required` 的 required 资源，只执行返回的命令，完整保留
+revision 与 authority 参数，并在每次动作后重新求值。当前会话可通过
+`context status --resource-receipts @<file>` 回传读取回执，使未变化资源标记为
+`current`。动态资源的 materialize 结果只有在 Agent 完整读取返回文件后才可作为
+回执；`context.source-body/*` 是必须阅读的正文，source-index 和标题元数据不能
+替代正文。
+长篇流程与语义判断规则发布在 Context workflow bundle 中，仅在当前路线或操作
+选中时加载。
 
-- `context source ...`
-- `context run ...`
-- `context review ...`
-- `context close`
-- `context build`
-- `context verify`
+Gate 的检查动作与决议动作分别保留自己的 Skill 和 Schema 位置。Agent 只在进入
+相应阶段时加载这些条件资源，不会把它们提前混入 Route 的普通 required 资源。
 
-如果用户在当前对话明确要求“全托管”,Continuation 会改用 `context status
---managed --format json` 并持续跟随其命令。分类、提取范围、结构确认、审阅和
-package 输出门禁可自动完成;来源边界、尚未授权的文档读取、外部仓库/系统操作和
-校验失败仍会停下。该授权不会写入 `defineProject` 或工作区,新对话默认恢复普通
-人工门禁。
+这两个入口文档也用于生成仅支持 Agent Skills 的宿主入口。不再发布阶段型
+Skill；来源、对齐、编译、审核和构建说明均由当前路线选择的 workflow resources
+动态提供。
 
-## Agent 可读的 SDK 手册
+## 人工门禁与全托管会话
 
-执行 `bun install` 后,项目内会有 SDK 手册:
+普通模式保留来源、读取权限、提取范围、结构、审阅和包形态等显式门禁。只有用户
+在当前对话明确要求全托管时，才使用：
 
-```text
-node_modules/@c4a/context/docs/
+```bash
+context status --managed --format json
 ```
 
-推荐先读:
-
-- `node_modules/@c4a/context/docs/guides/agent-dialogue.md`
-- `node_modules/@c4a/context/docs/guides/agent-guide.md`
-- `node_modules/@c4a/context/docs/reference/project-api.md`
-- `node_modules/@c4a/context/docs/reference/package-templates.md`
+该会话权限不会持久化，也不能选择来源边界、授权尚未允许读取的外部内容、执行
+外部仓库操作，或绕过校验与验证。
 
-模板示例在:
+首次读取托管状态后，可用下面的命令合并连续的确定性步骤：
 
-```text
-node_modules/@c4a/context/templates/package-templates/
+```bash
+context run --managed --until blocked-or-complete --format json
 ```
 
-Agent 应读取这些文件,不要通过临时脚本反查 `node_modules/@c4a/context/dist`
-来猜 SDK API。
-
-## 工作区形态
-
-需要提交的项目状态在:
-
-- `src/`:项目流程和定制代码;
-- `sources/repo/index.yaml`、`sources/file/index.yaml`、`sources/lark/index.yaml`:源 registry;
-- `unapproved/entities.jsonl`:draft/rejected/deprecated 元信息;
-- `unapproved/structure.yaml`:未确认或已确认的文档结构草稿;
-- `knowledge/`:approved Markdown;
-- `knowledge/structure.yaml`:由 approved knowledge 派生的结构与关系投影;
-- `dist/`:构建产物;
-- `README.md`、`AGENTS.md`、`package.json`。
-
-运行缓存放在 `.tmp/context-runtime/`,并被忽略。
-
-## Agent 入口
-
-全局 plugin 只暴露面向用户的 Context 命令:
-
-- `init`
-- `continue`
-
-CLI 仍保留底层能力,但它们不是公开 slash command。Continuation 入口根据 CLI 输出和用户意图选择要调用的底层命令。
-
-当前 source 注册、文档 capture 纪律、structure planning、Node 分类、阅读密度、
-候选处理、edge gates、source-bound section drafting、refresh/update 判断、
-语义冲突判断和 close 指引都在 `skill-source-scope`、`skill-prose-align`、
-`skill-prose-compile` 下面的内部 procedure。
+遇到需要 Agent 判断、配置修改、额外权限、诊断修复或多条命令的路线时，循环会
+立即停止，并返回当前 `workflow.current` 供 Agent 按需加载上下文。
 
-包内查询能力在构建包时生成到 `knowledge-query` skill。package 输出决策在
-`skill-package-output`。当前工作流不暴露 source 删除、purge 或撤回命令。
-如果用户要求这类生命周期变更,先停下来说明当前 plugin 没有已批准门禁;
-Agent 不得在当前工作流之外重建文件变更类操作。
+## 工作区与 SDK
 
-Agent 应按当前 status route 和内部 procedure 推进。不要调用或重建当前
-CLI/schema views 没有暴露的命令形态或 payload 协议。
+Plugin 应在初始化后的 Context 项目根目录运行。`src/index.ts` 保存项目声明；
+来源状态、草稿状态、已批准知识、构建产物和临时运行状态均由 Context CLI 管理。
 
-CLI 只做机械操作。它不会静默 clone、checkout、reset、fetch,也不会调用 LLM。源仓库缺失或 commit 不匹配时,CLI 只返回诊断;Agent 需要先征询用户,再决定是否执行外部 repo 操作。
+安装工作区依赖后，SDK 手册入口为：
 
-## 当前工作流入口
-
-本 plugin 只暴露当前工作流入口: `init` 和 `continue`。`continue` 从
-`context status` 开始,按 status route 分发到 source/capture phase、prose
-align evidence views、source-bound prose compile、review、close、
-verify/build/status guidance、OKF indexes、生成包里的 knowledge-query skill,
-以及已声明 project phase 的只读预览。
+```text
+node_modules/@c4a/context/docs/README.md
+```
 
-Agent 不得通过直接删除 `sources/`、`knowledge/`、`unapproved/`、`dist/`
-或 `.tmp` 来模拟生命周期或撤回操作。source 删除、purge 和撤回不是当前
-plugin 操作。
+当前 Plugin 不暴露 source 删除、purge 或 retraction，也不会静默执行 clone、
+fetch、checkout、install、build、test 或调用 LLM。

package/plugins/VERSION

@@ -1 +1 @@
-0.6.1
+0.6.3