dsh-perm-gate 2.1.0 → 2.6.1

package/README.md

@@ -26,7 +26,8 @@
 > | DSH version | Branch | Version | npm tag |
 > | --- | --- | --- | --- |
 > | 0.1.0-rc.7 ~ 0.1.1-rc.x | `legacy` | `1.x` | `@legacy` |
-> | 0.1.2-alpha.1+ (incl. 0.1.5-rc.2) | `main` | `2.x` | `@latest` / `@dsh-0.1.2` (`@2.x` is a range) |
+> | 0.1.2-alpha.1 ~ 0.1.5-rc.0 | `main` | `2.x` | `@latest` / `@dsh-0.1.2` (`@2.x` is a range) |
+> | 0.1.5-rc.1+ | `sync/0.1.5-from-main` (=`compat/0.1.5`) | `3.x` | GitHub ref install (no dist-tag yet) |
 >
 > The series number tracks the **DSH line** (`1.x` = DSH ≤ 0.1.1, `2.x` = DSH 0.1.2+),
 > and the majors fence each other: a `^1.x` install never resolves a `2.x` release and
@@ -42,7 +43,7 @@
 > **private** method of the user-approval service on both, so it is read behind a
 > `typeof` probe and degrades to “policy unknown” when absent or throwing.
 
-Version **2.0.0** — see the [Changelog](./CHANGELOG.md).
+Version **2.6.1** — see the [Changelog](./CHANGELOG.md).
 
 A single, self-sufficient, deterministic-first, fail-closed permission gate for DeepSeek Harness.
 
@@ -77,11 +78,13 @@ cross-plugin version coupling.
   malformed rules, and source-hash compile caching.
 - **Audit** — every decision is logged as an `{ignorable:true}` event with its `callId`; the
   model-visible reason matches the recorded outcome.
-- **自动审查 tier** (`permissive`) — an **independent approval mode** (separate from read-only,
-  full-access and whitelist tiers) that is neither "auto-approve" nor blanket trust. Front-end
-  exposes a **single switch** (`permissive`); the four backend strategies are **combinable** and
-  driven by plugin settings — still fail-closed against P0. The permission picker and the
-  settings row both show it under the product label 自动审查, with no icon.
+- **自动审查 tier** (`permissive`, plus `permissive-full`) — an **independent approval mode**
+  (separate from read-only, full-access and whitelist tiers) that is neither "auto-approve" nor
+  blanket trust. Front-end exposes a **single switch** (`permissive`); the four backend strategies
+  are **combinable** and driven by plugin settings — still fail-closed against P0. The permission
+  picker and the settings row both show it under the product label 自动审查, with no icon. The
+  `permissive-full` variant keeps the identical approval behaviour but drops the built-in file
+  sandbox, which otherwise denies the named pipes `git clone` / Cygwin / ConPTY need.
 - **Sandbox-escalation auto-answer** (`trustEscalation`) — a sandbox escalation is asked from
   *inside* the shell / pwsh / edit tool body, after `tools/pre-execute`, so the gate never saw
   it and a call it auto-allowed still prompted you to approve the widening. With this strategy
@@ -102,6 +105,31 @@ grants and LLM. It is editable as a list in the settings card (preset entries ar
 one-click restore brings the preset back); unset or empty applies the preset — the blacklist
 never silently turns off.
 
+## Screenshots
+
+**The settings card — the 自动审查 tier.** The front end exposes a single switch; the four back-end
+strategies combine. `LlmAssist` can follow the session's current model or be pinned to a provider /
+model, and carries its own health test and verdict learning:
+
+![Settings card — the 自动审查 tier](assets/setting-head.png)
+![LlmAssist — provider, model, API key](assets/llms.png)
+
+**The rules the gate actually loaded**, read straight from the `dsh-perm-gate-rules` settings
+namespace — the panel is read-only by design, so it can never edit what it shows:
+
+![Built-in rules, read-only](assets/setting-rules.png)
+
+**Approval decision log** — every verdict in this session, newest first, with the reason the model saw:
+
+![Approval decision log](assets/permlist.png)
+
+**Decision strips** — an auto-allow states its basis (a read-only tool, or an LLM `safe` verdict),
+and a stand-down is never silent:
+
+![ALLOW strip — read-only internal tool](assets/allow1.png)
+![ALLOW strip — llm-assist risk: safe](assets/allow2.png)
+![GATE OFF strip — the gate stood down](assets/gateoff.png)
+
 ## Install
 
 Requires an existing [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) installation.
@@ -125,9 +153,24 @@ Add the plugin to `cordis.yml`:
     rulesFile: ./permissions.yaml   # optional; defaults to $DSH_HOME/perm-gate/rules.yml
     dshHome: $DSH_HOME              # root pinned for protected-target checks
     defaultAction: ask              # allow | ask | deny
-    gatePresets: [permissive]       # tiers where the gate is active at all (default)
+    gatePresets: [permissive, permissive-full]   # tiers where the gate is active (default)
+    sessionSweep: true              # hourly cleanup of archived/dead sessions' gate data
 ```
 
+### Session sweep
+
+On startup and every hour the gate reads DSH's workspace store
+(`$DSH_HOME/storages/workspace.json`, read-only) and classifies every session it
+holds authorization-chain data for. Sessions DSH has archived (`global.archivedSessionIds`)
+or no longer tracks at all have their decision events dropped from
+`$DSH_HOME/perm-gate/events.jsonl` and their pre-change snapshot files deleted
+from `$DSH_HOME/perm-gate/snapshots/` — history the review page can no longer
+reach, for data the harness itself considers gone. Live sessions are untouched,
+unattributable rows (empty session id) are never deleted, and any failure is
+fail-open: the round is skipped and retried an hour later. Set `sessionSweep: false`
+to disable; `workspaceStoreFile` overrides the store path. Restoring an archived
+session does not restore its swept history.
+
 ### Rules file
 
 ```yaml
@@ -154,18 +197,105 @@ permissions:
 A command entry `word#flag` matches the command word (`word`) with the modifier `recursive` or
 `force` — so `rm#recursive` matches `rm -rf`, `env rm -rf`, and `sh -c "rm -rf /"`.
 
+### Network policy (opt-in)
+
+A local HTTP/CONNECT proxy that adjudicates the outbound traffic of **shell
+subprocesses** against the same rules file, plus an approval path for targets no
+rule covers. **Off by default** — enabling it binds a loopback port and rewrites
+the proxy environment for child processes, so it is never turned on implicitly.
+
+```yaml
+- id: dsh-perm-gate
+  config:
+    networkEnabled: false          # master switch (default false)
+    networkMode: whitelist         # deny-all | whitelist | allow-all
+    networkUnlisted: ask           # ask | deny  — unlisted target handling
+    networkUnattributed: allow     # allow | deny — traffic with no shell attribution
+    networkInjectEnv: true         # rewrite HTTP(S)_PROXY/ALL_PROXY for children
+    networkAskTimeoutMs: 120000    # approval wait before failing closed
+    networkGrantTtlMs: 1800000     # how long one approval covers its target
+```
+
+**Tiered behaviour.** Nothing reaches the network without an allow rule.
+An unlisted target is escalated to the interactive approval seam, raised on
+behalf of the shell command that opened the connection; approving widens reach
+for that target for the session. A `deny` rule is **never** escalated —
+approval can widen what an unlisted target may reach, but it can never override
+a rule that says no.
+
+**The boundary — read this before relying on it.** The proxy is a *cooperative*
+policy layer, not an enforcement boundary. It only sees traffic from clients
+that read the proxy environment:
+
+| Client | Covered? |
+|--------|----------|
+| `curl`, `wget`, `git`, Go `net/http`, Python `requests` | yes |
+| **Node.js `http`/`https`/`fetch`** | **no — connects directly** |
+| Java (without `-D` proxy flags), .NET `HttpClient` | no |
+| Raw sockets, custom TCP | no |
+| DNS, QUIC/HTTP3, non-HTTP protocols | no |
+| Connections to a literal IP | no |
+
+So a shell command like `node -e "require('http').get('http://host/')"` is not
+intercepted. Treat this as a guardrail against accidents and a place to state
+intent, not as a hermetic sandbox.
+
+DSH's **own** network traffic — the built-in network tools and the LLM
+transport — is deliberately left alone. Those connections carry no shell
+attribution, and `networkUnattributed: allow` (the default) passes them
+through unreviewed: reviewing them would let the host block *itself*, which is
+a worse failure than a missed block. Set `networkUnattributed: deny` only if
+you know your host's clients ignore the proxy environment.
+
+Query the live state at `GET /api/dsh-perm-gate/network` (mode, bind, port,
+proxy liveness, env-injection state, block counters, recent blocks).
+
 ## The 自动审查 tier (machine value `permissive`)
 
 自动审查 is an **independent approval tier** in the DSH permission picker, parallel to
 Read Only / Workspace Write / Full access / Whitelist. It is **not** generic "auto-approval" and
 never mints blanket authority: it only narrows or widens the seam *before* the human/LLM step
-while P0 hard-deny stays monotonic and non-negotiable.
+while P0 hard-deny stays monotonic and non-negotiable **within the gate's own scope**.
+
+> **P0 is scoped, not global.** The gate acts only while the session's permission preset is one
+> of `gatePresets` (default `permissive` / `permissive-full`). Under any other preset — Read Only,
+> Workspace Write, or Full access — the **entire** gate stands down, P0 hard-deny included,
+> because the selected tier's own policy governs that session. This is deliberate (see
+> `gatePresets` in the configuration table), but it means "P0 is non-negotiable" holds *inside*
+> the gate's tiers rather than across every tier. A stand-down is not silent: the gate records one
+> `stand-down` event per session/preset transition and the browser shows a sticky **GATE OFF**
+> strip above the input. Set `gatePresets: ['*']` to make P0 global again.
+
+**Two variants ship**, because a preset's `sandbox` and `approval` are independent knobs and
+coupling them forced a bad trade:
+
+| Picker label | Machine value | sandbox | approval |
+|--------------|---------------|---------|----------|
+| 自动审查 | `permissive` | `workspace-write` | `ask` |
+| 自动审查（高权限） | `permissive-full` | `danger-full-access` | `ask` |
+
+The plain tier keeps the built-in file sandbox. That sandbox also denies the named pipes a child
+process needs to start, so `git clone`, MSYS2/Cygwin `sh.exe` and ConPTY fail under it with
+`Win32 error 5` / `couldn't create signal pipe`. Because the gate is active **only** in the tiers
+listed in `gatePresets`, wanting the gate meant accepting that restriction. 自动审查（高权限）
+removes the coupling: identical approval behaviour, no file-sandbox restriction. The tier's own
+description states the trade plainly — the workflow is smoother, approvals still apply per call,
+but there is **no system sandbox left as a backstop**. Both are in the
+default `gatePresets`, so either one gives you the full P0–P4 chain — the gate reads the preset
+**name** only, never the sandbox mode.
 
 The picker label is a **host-supplied product string**, not a per-locale dictionary entry: DSH
-0.1.2 renders a plugin tier's `name:` verbatim on both permission surfaces (the General-settings
+renders a plugin tier's `name:` verbatim on both permission surfaces (the General-settings
 default row and the composer picker) and only supplies its own localized labels for the three
-built-in values, so `cordis.patch.yml` ships the Chinese label for every session. The tier draws
-**no icon** — the composer renders glyphs only for the built-in values.
+built-in values, so `cordis.patch.yml` ships the Chinese label for every session.
+
+The **icon** is a different story. The composer's glyph map is closed, and its own comment states
+the rule: *host-configured names outside the design set get none.* Neither tier is a built-in value,
+so both get an icon only because `npx dsh-perm-gate-patch-glyph` adds them to that map — 自动审查
+copies the `workspace-write` glyph, 自动审查（高权限） the `danger-full-access` one, so each tier
+shows the glyph of the file sandbox it actually shares. That patch edits a **host**
+package, so it is lost on every DSH upgrade — see
+[After a DSH upgrade](./INSTALL.md#after-a-dsh-upgrade-re-apply-the-composer-glyph-patch).
 
 In `cordis.yml`:
 
@@ -232,7 +362,13 @@ optionally overridden with `classifierProvider` / `classifierModel`). A **health
 
 - `safe` → the call is auto-allowed (audited as the `classifier` source); no panel is shown.
 - `risky` + a **hard category** (`deletion`, `credential`, `remote`, `system`, `bulk`) → the call
-  is **auto-denied** without a panel; hard risks are never auto-allowed and never learned.
+  **keeps the human ask**. The classifier **never denies**: the deny path belongs to the
+  deterministic layers alone (P0 hard-deny, the deny-keyword blacklist, explicit `deny:` rules), so
+  a misgraded category is always negotiable instead of an unappealable block. Hard categories stay
+  distinct from `neutral` in one way that matters: they are **never learned**, so repeated
+  approvals can never sediment them into an auto-allow.
+  (Denying on the model's word was measured live: a benign `git commit -F …` graded `remote`
+  produced an auto-deny with no panel and no grant to retry with.)
 - `risky:neutral` → with `riskLearning` enabled (Settings card, off by default), each human
   approval that actually executes (settled via the host's `tools/result` event) counts toward
   a `tool|category` key; once the count reaches `riskThreshold` (default 3) **and** the new
@@ -265,8 +401,10 @@ channel existed), with `tools/result` settling the same ask as a fallback when t
 correlate it. Approvals report the post-approval learning progress (`n`/threshold), and the notice
 strip labels all three terminal states.
 
-The tier draws no icon in the permission picker: the composer's glyphs are keyed to the three
-built-in values, so a plugin-contributed tier is text-only on every surface.
+自动审查 and 自动审查（高权限） both draw a glyph in the picker — copied from the built-in tiers whose
+file sandbox they share (`workspace-write` and `danger-full-access`) by the host patch the
+installation guide describes. Without that patch both tiers are text-only on every surface; their
+labels and their gating are unaffected.
 
 ### A selectable session tier
 
@@ -278,16 +416,17 @@ built-ins (`read-only` / `workspace-write` / `danger-full-access`, from
 session permission picker offers 自动审查 as an independent selectable approval tier, not a
 generic "auto-approval" mode.
 
-The gate is active **only in the tiers listed in `gatePresets`** (default `['permissive']`, the
-tier this plugin adds). In every other tier — Read Only, Workspace Write, Full access,
-`custom` — the gate's decision flow does not run at all: no allow, no ask, no deny, no P0
-hard-deny, no deny-keyword veto, and no audit event. The selected tier's own policy governs the
-call, which is the point: `danger-full-access` is defined as "full access without approval
-prompts", so overruling it with an ask (unanswerable there — the approval seam rejects before any
-answerer runs, producing `the user rejected tool "..."` with no panel) or with a hard-deny would
-silently contradict the tier the user chose. `gatePresets: ['*']` makes the gate global again
-(hard-deny included); inside an active tier an `ask` is still degraded to passthrough when the
-session's effective approval policy is `never`.
+The gate is active **only in the tiers listed in `gatePresets`** (default
+`['permissive', 'permissive-full']`, the two tiers this plugin adds). In every other tier —
+Read Only, Workspace Write, Full access, `custom` — the gate's decision flow does not run at all:
+no allow, no ask, no deny, no P0 hard-deny, no deny-keyword veto, and no audit event. The
+selected tier's own policy governs the call, which is the point: the built-in
+`danger-full-access` is defined as "full access without approval prompts", so overruling it with
+an ask (unanswerable there — the approval seam rejects before any answerer runs, producing
+`the user rejected tool "..."` with no panel) or with a hard-deny would silently contradict the
+tier the user chose. `gatePresets: ['*']` makes the gate global again (hard-deny included);
+inside an active tier an `ask` is still degraded to passthrough when the session's effective
+approval policy is `never` — which is why both 自动审查 tiers declare `approval: ask`.
 
 ### Configurable in the UI
 
@@ -297,6 +436,21 @@ The tier is also adjustable at runtime from **Settings → Plugins → 自动审
 namespace live, so a change applies to the next tool call without a restart. This is an
 independent approval class, NOT a generic "auto-approval" mode.
 
+### Rule test (dry-run)
+
+The same page carries a **Rule test** panel: type a tool name and a command, press Test, and the
+gate judges that call against the ruleset it currently has loaded — without running anything and
+without writing any rule. You get the verdict, the matched rule (index and action), the dimensions
+that rule constrains, and the reason.
+
+It reports the effective verdict (the whole P0 → P1 → P2 → P3 → P4 chain) *and* the rule layer's own
+answer, which are not the same thing: a P0 hard-deny or a preset deny-keyword fires before the rule
+chain and leaves no rule index behind, so the panel says "no rule matched" rather than naming an
+unrelated rule. A `0 rules loaded` note means the `rulesFile` path resolved to nothing.
+
+The panel talks to `POST /api/dsh-perm-gate/dry-run`, which is **read-only by construction** — it
+has no write form at all, so testing a rule can never change it.
+
 ## CLI
 
 Dry-run one call against a rules file (no harness needed):

package/README.zh.md

@@ -25,7 +25,8 @@
 > | DSH 版本 | 分支 | 版本号 | npm 标签 |
 > | --- | --- | --- | --- |
 > | 0.1.0-rc.7 ~ 0.1.1-rc.x | `legacy` | `1.x` | `@legacy` |
-> | 0.1.2-alpha.1+（含 0.1.5-rc.2） | `main` | `2.x` | `@latest` / `@dsh-0.1.2` （`@2.x` 是范围） |
+> | 0.1.2-alpha.1 ~ 0.1.5-rc.0 | `main` | `2.x` | `@latest` / `@dsh-0.1.2` （`@2.x` 是范围） |
+> | 0.1.5-rc.1+ | `sync/0.1.5-from-main`（=`compat/0.1.5`） | `3.x` | GitHub ref 安装（暂无 dist-tag） |
 >
 > 版本序列号跟的是 **DSH 线**（`1.x` = DSH ≤ 0.1.1，`2.x` = DSH 0.1.2+），两条大版本互
 > 相隔离：锁在 `^1.x` 的安装绝不会解析到 `2.x`，反之亦然。`engines.dsh` 表达同样的
@@ -39,7 +40,7 @@
 > 线上都是 user-approval 服务的**私有**方法，因此通过 `typeof` 探测读取，缺失
 > 或抛错时降级为「策略未知」。
 
-版本 **2.0.0** —— 变更见 [Changelog](./CHANGELOG.md)。
+版本 **2.6.1** —— 变更见 [Changelog](./CHANGELOG.md)。
 
 一个**单一自足、确定性优先、fail-closed** 的 DeepSeek Harness 权限门插件。
 
@@ -62,9 +63,30 @@
 - **会话放行** — 精确的 `(工具, 规范化 fingerprint)` grant，带 `TTL` + `maxUses`；换目标绝不复用。子代理继承但不可自授。
 - **纯函数规则引擎** — glob/regex 编译 + ReDoS 上限、坏规则 loud fail、按源内容哈希缓存。
 - **审计** — 每次决策写为 `{ignorable:true}` 事件并带 `callId`；模型可见理由与记录一致。
-- **自动审查档位**（机器值 `permissive`）——一个**独立审批模式**（区别于只读、完全权限与白名单档），既不是"自动审批"，也不授予泛化权限。前端只暴露**一个开关**（`permissive`），后台四个审批策略**可组合**、由插件设置决定——仍对 P0 保持 fail-closed。权限下拉框与设置行都按产品名「自动审查」显示，且不带图标。
+- **自动审查档位**（机器值 `permissive`）——一个**独立审批模式**（区别于只读、完全权限与白名单档），既不是"自动审批"，也不授予泛化权限。前端只暴露**一个开关**（`permissive`），后台四个审批策略**可组合**、由插件设置决定——仍对 P0 保持 fail-closed。权限下拉框与设置行都按产品名「自动审查」显示；图标见下文（内置档自带，插件档需补丁）。
 - **沙箱提权自动答复**（`trustEscalation`）— 沙箱提权是从 shell / pwsh / edit 工具**体内部**（`tools/pre-execute` 之后）发出的，所以门禁从未见过它，一个它自动放行的调用仍会弹出确认。开启后，门禁以 `callId` 精确匹配已放行调用并直接答复。
 
+## 界面预览
+
+**设置卡片 —— 自动审查档位**：前端只暴露一个开关，后台四个策略可组合；`LlmAssist` 可跟随会话当前模型，也可钉住 Provider / Model，并自带健康测试与裁决学习：
+
+![设置卡片 —— 自动审查档位](assets/setting-head.png)
+![LlmAssist —— Provider / Model / API Key](assets/llms.png)
+
+**门禁实际加载的规则**——直接读自 `dsh-perm-gate-rules` 设置命名空间；面板按设计只读，改不了它显示的内容：
+
+![内置规则（只读）](assets/setting-rules.png)
+
+**权限审批记录**——本会话每一次裁决，最新在上，附带模型看到的理由：
+
+![权限审批记录](assets/permlist.png)
+
+**裁决条**——自动放行会写明依据（只读工具，或 LLM 判定 `safe`）；停摆也绝不静默：
+
+![ALLOW 条 —— 只读内置工具](assets/allow1.png)
+![ALLOW 条 —— llm-assist 判定 safe](assets/allow2.png)
+![GATE OFF 条 —— 门禁停摆](assets/gateoff.png)
+
 ## 安装
 
 需要先安装 [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness)。
@@ -87,21 +109,104 @@ dsh plugin --profile web add dsh-perm-gate
     rulesFile: ./permissions.yaml   # 可选；默认 $DSH_HOME/perm-gate/rules.yml
     dshHome: $DSH_HOME
     defaultAction: ask
-    gatePresets: [permissive]       # 门禁生效的档位（默认值）
+    gatePresets: [permissive, permissive-full]   # 门禁生效的档位（默认值）
+    sessionSweep: true              # 每小时清理已归档/已删除会话的门禁数据
 ```
 
+### 会话清扫（session sweep）
+
+插件启动时及每小时读取 DSH 的工作区存储（`$DSH_HOME/storages/workspace.json`，只读），
+对门禁持有授权链数据的每个会话做归类。已被 DSH 归档（`global.archivedSessionIds`）
+或彻底不存在的会话，其决策事件会从 `$DSH_HOME/perm-gate/events.jsonl` 中移除，
+其决策前文件快照会从 `$DSH_HOME/perm-gate/snapshots/` 中删除——宿主已视为消失的数据，
+审查页也不再保留其历史。活跃会话不受影响；无法归属的行（空 sessionId）永不删除；
+任何失败都 fail-open：本轮跳过，一小时后重试。设 `sessionSweep: false` 关闭；
+`workspaceStoreFile` 可覆盖存储路径。恢复归档会话不会找回已被清扫的历史。
+
 规则示例：见 [examples/permissions.example.yaml](./examples/permissions.example.yaml)。
 
+### 网络策略（可选开启）
+
+本地 HTTP/CONNECT 代理，用**同一份规则文件**审查 **shell 子进程**的出站流量，并对无规则
+覆盖的目标提供审批通道。**默认关闭** —— 开启后会绑定回环端口并改写子进程的代理环境变量，
+因此绝不隐式启用。
+
+```yaml
+- id: dsh-perm-gate
+  config:
+    networkEnabled: false          # 总开关（默认 false）
+    networkMode: whitelist         # deny-all | whitelist | allow-all
+    networkUnlisted: ask           # ask | deny —— 未列出目标的处理方式
+    networkUnattributed: allow     # allow | deny —— 无 shell 归属的流量
+    networkInjectEnv: true         # 为子进程改写 HTTP(S)_PROXY / ALL_PROXY
+    networkAskTimeoutMs: 120000    # 审批等待上限，超时按拒绝处理
+    networkGrantTtlMs: 1800000     # 一次批准的会话有效期
+```
+
+**分层行为**：没有 allow 规则，任何目标都出不去。未列出的目标会升级到交互审批，挂在该
+shell 命令的会话上；批准后该目标在本次会话内放行。**`deny` 规则永不升级为审批** —— 审批
+只能为「无规则禁止的目标」拓宽可达性，永远不能推翻一条说「不」的规则。
+
+**边界 —— 依赖它之前请先读这段**：代理是**协作式**策略层，不是强制边界。它只能看到
+**愿意读代理环境变量**的客户端的流量。
+
+| 客户端 | 能拦吗 |
+|--------|--------|
+| `curl`、`wget`、`git`、Go `net/http`、Python `requests` | ✅ |
+| **Node.js `http` / `https` / `fetch`** | ❌ **直连，代理看不到** |
+| Java（未加 `-D` 代理参数）、.NET `HttpClient` | ❌ |
+| 原始 socket、自写 TCP | ❌ |
+| DNS、QUIC/HTTP3、非 HTTP 协议 | ❌ |
+| 连接字面 IP | ❌ |
+
+因此 `node -e "require('http').get('http://host/')"` 这类命令**不会被拦截**。请把它当作
+「防误操作的护栏 + 声明意图的地方」，而不是密闭沙箱。
+
+DSH **自身**的网络流量 —— 内建网络工具与 LLM 传输 —— 刻意不管：这些连接不带 shell 归属，
+而 `networkUnattributed: allow`（默认）会直接放行。审查它们会导致宿主**把自己拦死**，
+那比漏拦严重得多。只有在你确定宿主的客户端不读代理环境变量时，才考虑改成 `deny`。
+
+实时状态查询：`GET /api/dsh-perm-gate/network`（模式 / 绑定 / 端口 / 代理存活 / 环境注入
+状态 / 阻断计数 / 最近阻断）。
+
 ## 自动审查档位（机器值 `permissive`）
 
 自动审查是权限下拉框里一个**独立审批档**，与只读 / 工作区内修改 / 完全权限 / 白名单平行。
 它不是泛化的"自动审批"、也不授予泛化权限：只会在人类/LLM 接缝**之前**收窄或放宽决策，
-P0 硬拒绝始终单调且不可协商。
-
-下拉框里的名字是**宿主提供的产品名**，不是逐语言的字典项：DSH 0.1.2 对插件档位在**两个**权限界面上
+P0 硬拒绝在**本门禁自身的档位作用域内**始终单调且不可协商。
+
+> **P0 是档位作用域内的，不是全局的。** 门禁只在会话权限档位属于 `gatePresets`
+> （默认 `permissive` / `permissive-full`）时生效。其他档位 —— 只读、工作区内修改、完全权限
+> —— 下**整个门禁停用，包括 P0 硬拒绝**，因为该档位自身的策略接管了这个会话。这是刻意设计
+> （见配置表的 `gatePresets`），但也就意味着「P0 不可协商」成立于**门禁的档位之内**，而非所有档位。
+> 停用**不是静默的**：每次会话档位切换会记录一条 `stand-down` 事件，浏览器在输入框上方常驻一条
+> **GATE OFF** 提示条。把 `gatePresets` 设为 `['*']` 可让 P0 重新变成全局。
+
+**提供两个变体** —— 因为预设的 `sandbox` 与 `approval` 是两根**独立**旋钮，把它们绑死会逼出
+一个糟糕的取舍：
+
+| 下拉框名称 | 机器值 | sandbox | approval |
+|-----------|--------|---------|----------|
+| 自动审查 | `permissive` | `workspace-write` | `ask` |
+| 自动审查（高权限） | `permissive-full` | `danger-full-access` | `ask` |
+
+普通档保留内置文件沙箱。而那个沙箱**同时**拒绝子进程启动所需的命名管道 —— 所以 `git clone`、
+MSYS2/Cygwin 的 `sh.exe`、ConPTY 都会以 `Win32 error 5` / `couldn't create signal pipe` 失败。
+又因为门禁**只在 `gatePresets` 列出的档位里生效**，想用门禁就必须接受这个限制。
+「自动审查（高权限）」解开了这个耦合：**审批行为完全相同，但不限制文件沙箱** —— 档位自带的描述已把代价
+写明：流程更顺畅、审批仍逐次生效，但**不再有系统沙箱兜底**。两者都在默认
+`gatePresets` 里，任选其一都能获得完整的 P0–P4 链路 —— 门禁只读预设的**名字**，从不读 sandbox 模式。
+
+下拉框里的名字是**宿主提供的产品名**，不是逐语言的字典项：DSH 对插件档位在**两个**权限界面上
 （通用设置默认档行、输入栏权限选择器）都原样渲染补丁里的 `name:`，只给三个内置档提供自己的本地化
-标签，因此 `cordis.patch.yml` 直接写中文名，对所有会话一致。该档位**不画图标**——选择器的图标只按
-三个内置值取。
+标签，因此 `cordis.patch.yml` 直接写中文名，对所有会话一致。
+
+**图标是另一回事。** 输入栏的图标表是闭合的，表自己的注释写明了规则：*host-configured names
+outside the design set get none*。两个档位都不是内置值，图标全靠
+`npx dsh-perm-gate-patch-glyph` 往那张表里补两项 ——「自动审查」复制 `workspace-write` 的
+盾+铅笔，「自动审查（高权限）」复制 `danger-full-access` 的盾+感叹号，各自对应自己实际共用的
+文件沙箱。该补丁改的是**宿主**包，每次 DSH 升级都会丢 —— 见
+[DSH 升级后：重打输入区图标补丁](./INSTALL.zh.md)。
 
 `cordis.yml`：
 
@@ -156,7 +261,8 @@ LLM 评定为 `safe` 且门禁自动放行的调用因此仍会弹出确认。
 `@deepseek-ai/dsh-base/cordis.patch.yml`）；`test/patch-presets.spec.ts` 固定了这份键集合。因此会话权限
 下拉里会出现「自动审查」这个**独立可选审批档**，而不是"auto-approval"档。
 
-门禁**只在 `gatePresets` 列出的档位里生效**（默认 `['permissive']`，即本插件新增的那一档）。在其余任何档位
+门禁**只在 `gatePresets` 列出的档位里生效**（默认 `['permissive', 'permissive-full']`，即本插件新增的
+两个档位）。在其余任何档位
 （Read Only、Workspace Write、Full access、`custom`）里，门禁的判定流程**完全不运行**：不放行、不弹审批、
 不拒绝、不执行 P0 硬拒绝、不做黑名单关键词拦截，也不写审计事件——该档位自己的策略说了算。这正是重点所在：
 `danger-full-access` 的定义就是"全权限、不弹审批"，用 ask 去覆盖它毫无意义（该档 `approval: never` 会让审批接缝
@@ -176,7 +282,8 @@ LLM 评定为 `safe` 且门禁自动放行的调用因此仍会弹出确认。
 开启 `llmAssist` 后，接收 LLM（自定义 OpenAI 兼容端点，或 DSH 宿主模型组——见上文）按结构化协议逐条评估 `ask`。**判定发生在门禁的 `tools/pre-execute` 瀑布内部、决策返回宿主之前**：`safe` 直接放行，审批面板根本不会出现；只有真正无法确定的判定才会弹到你面前。
 
 - `safe` → 自动放行（审计来源为 `classifier`），不弹面板。
-- `risky` + **硬风险类别**（`deletion`、`credential`、`remote`、`system`、`bulk`）→ **自动拒绝**、不弹面板；硬风险永不自动放行、也永不进入学习。
+- `risky` + **硬风险类别**（`deletion`、`credential`、`remote`、`system`、`bulk`）→ **维持人工确认（ask）**。分类器**永不拒绝**：拒绝只属于确定性层（P0 硬拒绝、黑名单关键词、显式 `deny:` 规则），所以被误判的类别永远可协商，而不会变成无法申诉的封禁。硬类别与 `neutral` 仅保留一条关键区别：**永不进入学习**，因此反复确认也不可能把它沉淀成自动放行。
+  （拿模型的判断当拒绝依据是实测出来的问题：一条无害的 `git commit -F …` 被判 `remote`，直接自动拒绝——没有面板、也没有可重试的授权入口。）
 - `risky:neutral` → 若开启 `riskLearning`（设置卡片内，默认关闭），人工批准且真实执行的 neutral 风险会按 `tool|类别` 计数；计数达到 `riskThreshold`（默认 3）且新调用的操作指纹（命令词 + 目标基名）命中已确认样本时，**同一操作**自动放行。不同目标永不复用该放行。开启学习沉淀（`riskSediment`，默认开）后，满阈值 key 的确认样本会成为**确定性放行规则**：指纹精确命中即直接放行、无需再过 LLM——即使关闭 llmAssist 也继续生效；沉淀规则在设置卡片中可见、可管理（终止学习 / 删除样本）。
 - 超时（`riskTimeoutMs`，默认 20s，重试 1 次）、传输失败与协议外输出均维持原 `ask`——门禁绝不猜测。
 
@@ -191,7 +298,9 @@ LLM 评定为 `safe` 且门禁自动放行的调用因此仍会弹出确认。
 调用文本命中任一关键词（大小写不敏感子串）即直接拒绝，且先于白名单 / 授权 / LLM。黑名单在设置
 卡片中按列表查看与增删（预置条目带标签，可一键恢复预置）；未设置或为空时应用预置列表——黑名单
 不会静默关闭。
-该档位在权限选择器中**不显示图标**：选择器的图标只按三个内置值取，插件新增的档位是纯文字。
+「自动审查」与「自动审查（高权限）」在选择器里都画图标 —— 图标由安装指南里描述的那次宿主补丁
+从各自共用的文件沙箱档位复制而来（`workspace-write` 与 `danger-full-access`）。没有该补丁时，
+两个档位在所有界面上都是纯文字；它们的标签与门禁不受影响。
 
 
 ## CLI（独立 dry-run）

package/cordis.patch.yml

@@ -14,9 +14,20 @@
 # stays `permissive`: it is the key `gatePresets` matches and the value the
 # permission projection reports, so only the label text is user-facing.
 #
-# The tier now carries a shield+eye icon in the composer glyph map (patched
-# into dsh-client-ui-conversation).  The permissive glyph sits alongside the
-# three built-in ones so both the trigger button and the dropdown rows show it.
+# The composer's permission picker draws an icon per preset from a CLOSED map
+# inside @deepseek-ai/dsh-client-ui-conversation (`permissionGlyphs`), whose
+# source states the rule: "host-configured names outside the design set get
+# none". Neither tier is a built-in value, so DSH renders no glyph for either
+# — the map is a closed closure variable and its only plugin-facing input is
+# {value, name, description} on the option objects, which carries no icon. The
+# only way to give a tier an icon is to add an entry to that map.
+# `scripts/patch-permission-glyph.mjs` does exactly that, copying the glyph of
+# the built-in tier whose file sandbox each of ours shares:
+#   permissive       <- ["workspace-write",  (same sandbox: workspace-write)
+#   permissive-full  <- [FULL_ACCESS,        (same sandbox: danger-full-access)
+# The source key is RESOLVED, not assumed (0.1.2 keyed a `permissive` glyph that
+# 0.1.5 dropped, so a literal anchor died with "anchor not found"). It patches a
+# HOST package, so it must be re-run after any DSH upgrade or reinstall.
 #
 # The DSH bundle patch REPLACES the whole `permission.config.presets` map (it
 # does not merge per key), so this file MUST restate every tier that should
@@ -32,6 +43,24 @@
 # lost its implementation with that plugin, and this gate is inactive in it
 # (`gatePresets` defaults to `['permissive']`) — so it only offered a duplicate
 # tier that looked protected while nothing was.
+#
+# TWO tiers ship, because `sandbox` and `approval` are INDEPENDENT knobs and
+# coupling them forced a bad trade:
+#
+#   permissive       sandbox: workspace-write   approval: ask
+#   permissive-full  sandbox: danger-full-access approval: ask
+#
+# `permissive` keeps the built-in file sandbox. That sandbox also denies the
+# named pipes a child process needs to start — `git clone`, MSYS2/Cygwin
+# `sh.exe` and ConPTY all fail with `Win32 error 5` under it. Because this gate
+# is only active in the tiers listed in `gatePresets`, a user who wanted the
+# gate had to accept that restriction to get it. `permissive-full` removes the
+# coupling: same approval behaviour, no file-sandbox restriction.
+#
+# The gate itself only reads the preset NAME (see `src/preset.ts`), never the
+# sandbox mode, so both tiers get the full P0–P4 chain. `approval: ask` is
+# required on both — under `approval: never` the DSH seam rejects every ask
+# before any answerer runs, which would degrade this gate's asks to passthrough.
 - id: permission
   config:
     presets:
@@ -46,6 +75,11 @@
         approval: ask
         name: 自动审查
         description: 独立审批档 —— 作用域内安全操作自动放行，危险/未知越界转人工确认（审批强度可在「设置 → 插件 → 自动审查」调整）。
+      permissive-full:
+        sandbox: danger-full-access
+        approval: ask
+        name: 自动审查（高权限）
+        description: 只由本插件的审批门过滤 —— 文件修改与子进程网络访问不再受沙箱限制，审批仍逐次生效，但没有系统沙箱兜底。
       danger-full-access:
         sandbox: danger-full-access
         approval: never

package/docs/baseline-guard.md

@@ -0,0 +1,56 @@
+# Baseline Snapshot: feat/capability-absorption
+
+> Captured at T0.3/T0.4 on 2026-09-15
+>
+> **为什么这份快照留在仓库里**：下面那 30 个测试文件是能力吸收（6 维度 / 网络执行面 / 热重载）
+> 落地**之前**的既有覆盖，充当回归护栏——新增行为**不得**靠修改它们来适配。
+> 原位置 `.agents/baseline-snapshot.md` 未入库（`.agents/` 是仓库惯例的本地目录），
+> 2026-09-17 迁到 `docs/` 以便随包分发、可追溯。
+> 注意：仓库当前已有 **40** 个测试文件；本列表是**护栏基线**，不是当前全量清单。
+
+## Gate Status
+
+| Gate | Status | Notes |
+|------|--------|-------|
+| typecheck | ✅ 0 errors | After pre-existing fix commit |
+| test | ✅ 278/278 | 30 spec files |
+| build | ✅ tsc + tsdown | client.js 99.95 kB |
+| lint | ✅ 0 errors | — |
+
+## Pre-existing Fixes (committed)
+
+- `src/risk.ts:137-138` — cast `req.args` to `Record<string, unknown>` (was `{}`)
+- `src/runtime.ts:26` — add `import { decomposeShellCommand } from './shell.js'`
+
+## Test File List (30 files, DO NOT modify to accommodate new behavior)
+
+1. audit.spec.ts
+2. auto-allow-tools.spec.ts
+3. compiler.spec.ts
+4. custom-llm.spec.ts
+5. data-home.spec.ts
+6. deny-keywords.spec.ts
+7. deny-keywords-scope.spec.ts
+8. engine.spec.ts
+9. evaluate.spec.ts
+10. events.spec.ts
+11. feature.spec.ts
+12. grant.spec.ts
+13. host-llm.spec.ts
+14. learning.spec.ts
+15. manual-approval.spec.ts
+16. patch-presets.spec.ts
+17. permissive.spec.ts
+18. pre-execute.spec.ts
+19. preset-scope.spec.ts
+20. review.spec.ts
+21. risk.spec.ts
+22. rule.spec.ts
+23. runtime.spec.ts
+24. runtime-risk.spec.ts
+25. sediment.spec.ts
+26. session-resolution.spec.ts
+27. session-sweep.spec.ts
+28. session-sweep-apply.spec.ts
+29. shell.spec.ts
+30. write-path.spec.ts