dsh-perm-gate 0.2.1-beta.3 → 0.2.1-beta.4

package/CHANGELOG.ja.md

@@ -7,6 +7,28 @@
 
 ## [Unreleased]
 
+### 追加
+
+- Permissive ティアに `trustEscalation` 戦略を追加（ティア有効時に既定オン）：ゲートがすでに許可した呼び出しの
+  サンドボックス昇格承認をここで `allowed-once` と回答し、プロンプトを出さなくする。昇格は shell / pwsh / edit
+  ツールの内部 — `tools/pre-execute` の決着後 — から発生するため、ゲート自身の allow はそこに届かず、
+  LLM が `safe` と判定した呼び出しでも広げの確認を求めていた。ゲートが許可した呼び出しのみ
+  （`callId` とツール名で一致）がプロンプトをスキップし、`workspace-write` / `danger-full-access` を
+  命名する認識された昇格原因のみ適用。それ以外は変更なく人手へ委譲。自動回答はイベントフィードに記録
+  （`verdict: "escalation-auto"`、`mode: <ターゲット>`）。スイッチをオフにすると広げは人手ゲート化。
+
+### 修正
+
+- 設定カードがルール ファイルから編集可能なホワイトリストをシードするようになりました。
+  `installSettingsSection` はホスト設定スコープで `scope.set('allowlist', …)` を呼んでいましたが、
+  ホスト スコープは `get` / `watch` / `update` / `replace` だけ expose —
+  `set(field, value)` は *クライアント* の `mutate()` 用 convenience ラッパーで異なるオブジェクトなので、
+  呼び出しが投げて名前空間がシードされませんでした。
+  今度は `scope.update({ allowlist: … })` を使います。
+- `approval/request` リスナーが `prepend` で登録され、パッシブ オブザーバから回答ゲートになり、
+  ブラウザ プロンプトを描画するリモート ブリッジの前に位置するようになりました。
+  そのブリッジの後ろにリスナーがあれば、すでに示されたプロンプトしか記録できませんでした。
+
 ## [0.2.1-beta.3] - 2026-09-10
 
 ### 追加

package/CHANGELOG.ko.md

@@ -7,6 +7,28 @@
 
 ## [Unreleased]
 
+### 추가
+
+- Permissive 티어에 `trustEscalation` 전략 추가(티어 켜짐时 기본 켬): 게이트가 이미 허용한 호출의
+  샌드박스 승격 승인을 여기서 `allowed-once`로 응답하여 프롬프트를 표시하지 않음. 승격은 shell / pwsh / edit
+  도구 내부(`tools/pre-execute` 결착 후)에서 발생하므로 게이트의 allow는 여기에 닿지 않고,
+  LLM이 `safe`로 판정한 호출조차 승격 확인을 요구했음. 게이트가 허용한 호출만
+  (`callId` 및 툴 이름 일치) 프롬프트를 건너뛰고, `workspace-write` / `danger-full-access`를
+  명시하는 알려진 승격 원인에만 적용. 나머지는 변경 없이 사람에게 위임. 자동 응답은 이벤트 피드에 기록
+  (`verdict: "escalation-auto"`, `mode: <대상>`). 스위치를 끄면 승격은 사람 게이트화.
+
+### 수정
+
+- 설정 카드가 규칙 파일에서 편집 가능한 허용 목록을 시딩하도록 수정.
+  `installSettingsSection`은 호스트 설정 스코프에서 `scope.set('allowlist', …)`를 호출했지만,
+  호스트 스코프는 `get` / `watch` / `update` / `replace`만 제공 —
+  `set(field, value)`는 *클라이언트*의 `mutate()`용 convenience 래퍼로 다른 객체이므로
+  호출이 예외를 throw하고 네임스페이스가 시딩되지 않았음.
+  이제 `scope.update({ allowlist: … })`를 사용.
+- `approval/request` 리스너가 `prepend`로 등록되고 수동 옵서버에서 응답 게이트로 바뀌어,
+  브라우저 프롬프트를 렌더링하는 원격 브리ჯ 앞에 위치하게 됨.
+  그 브리ჯ 뒤에 리스너가 있으면 이미 표시된 프롬프트만 기록 가능했음.
+
 ## [0.2.1-beta.3] - 2026-09-10
 
 ### 추가

package/CHANGELOG.md

@@ -5,7 +5,53 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
+## [0.2.1-beta.4] - 2026-09-11
+
+### Added
+
+- `trustEscalation` strategy in the Permissive tier (on by default while the tier is on): a
+  sandbox-escalation approval for a call this gate already allowed is answered `allowed-once`
+  here instead of prompting you. The escalation is raised by `approveEscalation` from *inside*
+  the shell / pwsh / edit tool body — after `tools/pre-execute` settled — so the gate's own
+  allow never reached it and a call the LLM graded `safe` still asked you to approve the
+  widening. Only the exact call the gate cleared (matched by `callId` and tool name) skips the
+  prompt, and only for a recognized escalation reason naming `workspace-write` /
+  `danger-full-access`; everything else delegates to the human unchanged. The auto-answer is
+  recorded on the event feed (`verdict:"escalation-auto"`, `mode:<target>`). Turn the switch
+  off to keep sandbox widening human-gated.
+
+### Fixed
+
+- The settings card now seeds the editable whitelist from the rules file. `installSettingsSection`
+  called `scope.set('allowlist', …)` on the **host** settings scope, which exposes only
+  `get` / `watch` / `update` / `replace` — `set(field, value)` is the *client* convenience wrapper
+  over `mutate()`, a different object — so the call threw and the namespace stayed unseeded.
+  It now uses `scope.update({ allowlist: … })`.
+- The `approval/request` listener is registered `prepend` and is now an answering gate rather than
+  a passive observer, so it sits ahead of the remote bridge that renders the browser prompt. A
+  listener behind that bridge could only ever record a prompt that had already been shown.
+- The browser half no longer imports `@deepseek-ai/dsh-client-runtime`, which DSH removed in
+  `0.1.2-alpha.1`. `ClientContext` now comes from `@deepseek-ai/cordis` — the alias DSH 0.1.1
+  defined as `export type ClientContext = Context`, so it names the same type on both lines — and
+  the settings card declares the four scope members it uses locally (`SettingsScopeLike`), the
+  same local-face pattern the host half already uses for the host `settings` service. The client
+  contract is byte-identical on both lines; only its exporting package moved.
+
+### Changed
+
+- DSH compatibility now ships as **two long-lived branches**, each with its own version series,
+  `engines.dsh`, and npm dist-tag: `main` / `0.2.x` / `>=0.1.2-alpha.1 <0.2.0-0` / `latest`, and
+  `legacy` / `1.x` / `>=0.1.0-rc.7 <0.1.2-alpha.1` / `legacy`. This branch is `main`. See
+  `RELEASING.md` for the branch layout and the cherry-pick flow.
+- On this line `ctx.slots` is declared by `@deepseek-ai/dsh-client-ui-renderer/client` — from
+  `0.1.2-alpha.1` on, `@deepseek-ai/dsh-client-runtime` is gone — so the client entry imports it.
+- Client devDependency floors raised from `^0.1.0-rc.7` to `^0.1.5-rc.2`, and
+  `@deepseek-ai/dsh-client-ui-renderer` added. The old floor meant the build could only ever
+  resolve the 0.1.0-rc.8 package set, so this line was never compiled against.
+- `npm run verify:line` (`scripts/verify-line.mjs`) installs this branch's line packages with
+  `npm install --no-save` and runs typecheck + tests + build against them, so a build always
+  compiles against the packages the branch ships for. `npm run verify:lines` is an opt-in drift
+  check that builds on both lines and compares the bundles.
 
 ## [0.2.1-beta.3] - 2026-09-10
 

package/INSTALL.ja.md

@@ -23,6 +23,21 @@
 - インストール先の profile。ブラウザ側は `web` profile 向けにのみビルドされます
   （`package.json` の `dsh.client.platform = "web"`）。
 
+## DSH のバージョンに合う tag を選ぶ
+
+単一ビルドが DSH 両ラインをカバーするため、どちらの tag を選んでも動作するコードが
+インストールされます —— tag を残しておくのは、あなたがピン留めするバージョンが
+各ラインで意味を持つようにするためです。
+
+| DSH のバージョン | インストール方法 |
+|-----------------|-----------------|
+| `0.1.2-alpha.1` 以上（`0.1.5-rc.2` を含む） | `dsh plugin --profile web add dsh-perm-gate`（tag `latest`） |
+| `0.1.1-rc.2` まで | `dsh plugin --profile web add dsh-perm-gate@legacy` |
+
+DSH は `engines.dsh` を強制しないため、tag が選択メカニズムであり、互換性ゲート
+そのものではありません。単一ビルドが両ラインをカバーする理由と tag の公開方法については、
+[RELEASING.md](./RELEASING.md) を参照してください。
+
 ## 公式 CLI でインストール
 
 ```sh
@@ -105,11 +120,11 @@ dsh-perm-gate --rules permissions.yaml --tool bash --args '{"command":"pnpm inst
   "defaultAction": "ask",
   "ruleCount": 8,
   "permissive": false,
-  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false }
+  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false, "trustEscalation": true }
 }
 ```
 
-UI では **設定 → プラグイン → Permissive 承認ティア** に、1 つのスイッチと 3 つの
+UI では **設定 → プラグイン → Permissive 承認ティア** に、1 つのスイッチと 4 つの
 バックエンド戦略トグルが表示されます。
 
 ## アンインストール

package/INSTALL.ko.md

@@ -23,6 +23,21 @@
 - 설치할 profile. 브라우저 절반은 `web` profile용으로만 빌드됩니다
   (`package.json`의 `dsh.client.platform = "web"`).
 
+## DSH 버전에 맞는 tag 선택
+
+단일 빌드는 두 DSH 라인을 모두 커버하므로, 어느 tag를 골라도 작동하는 코드가
+설치됩니다 —— tag를 유지하는 이유는 당신이 고정하는 버전이 각 라인에서 의미 있게
+유지되도록 하기 위함입니다.
+
+| DSH 버전 | 설치 방법 |
+|----------|-----------|
+| `0.1.2-alpha.1` 이상 (`0.1.5-rc.2` 포함) | `dsh plugin --profile web add dsh-perm-gate` (tag `latest`) |
+| `0.1.1-rc.2` 이하 | `dsh plugin --profile web add dsh-perm-gate@legacy` |
+
+DSH는 `engines.dsh`를 강제하지 않으므로, tag는 선택 메커니즘이지 호환성 게이트가
+아닙니다. 단일 아티팩트가 두 라인을 커버하는 이유와 tag가 게시되는 방식에 대해서는
+[RELEASING.md](./RELEASING.md)를 참고하세요.
+
 ## 공식 CLI로 설치
 
 ```sh
@@ -104,12 +119,12 @@ dsh-perm-gate --rules permissions.yaml --tool bash --args '{"command":"pnpm inst
   "defaultAction": "ask",
   "ruleCount": 8,
   "permissive": false,
-  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false }
+  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false, "trustEscalation": true }
 }
 ```
 
 UI의 **설정 → 플러그인 → Permissive 승인 티어**에 스위치 하나와 백엔드 전략 토글
-세 개가 표시되어야 합니다.
+네 개가 표시되어야 합니다.
 
 ## 제거
 

package/INSTALL.md

@@ -23,6 +23,20 @@ decision chain, the rules file format and the Permissive tier.
 - A profile to install into — the browser half only ships for the `web` profile
   (`dsh.client.platform = "web"` in `package.json`).
 
+## Pick the tag for your DSH version
+
+One build serves both DSH lines, so either tag installs working code — the tag
+exists so a version you pin stays meaningful per line.
+
+| Your DSH | Install |
+|----------|---------|
+| `0.1.2-alpha.1` or newer (incl. `0.1.5-rc.2`) | `dsh plugin --profile web add dsh-perm-gate` (tag `latest`) |
+| up to `0.1.1-rc.2` | `dsh plugin --profile web add dsh-perm-gate@legacy` |
+
+DSH does not enforce `engines.dsh`, so the tags are the selection mechanism rather
+than a compatibility gate. See [RELEASING.md](./RELEASING.md) for why one artifact
+covers both lines and how the tags are published.
+
 ## Install with the official CLI
 
 ```sh
@@ -107,12 +121,12 @@ Expected `--list` output shape:
   "defaultAction": "ask",
   "ruleCount": 8,
   "permissive": false,
-  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false }
+  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false, "trustEscalation": true }
 }
 ```
 
 In the UI, **Settings → Plugins → Permissive approval tier** should render one
-switch plus the three backend strategy toggles.
+switch plus the four backend strategy toggles.
 
 ## Uninstall
 

package/INSTALL.zh.md

@@ -23,6 +23,19 @@
 - 需要一个目标 profile —— 浏览器端只为 `web` profile 构建（`package.json`
   里 `dsh.client.platform = "web"`）。
 
+## 按你的 DSH 版本选择 tag
+
+单一构建同时覆盖两条 DSH 线，所以任一 tag 安装的代码都能工作 —— 保留 tag
+是为了让你锁定的版本在每条线上都有意义。
+
+| 你的 DSH | 安装方式 |
+|----------|----------|
+| `0.1.2-alpha.1` 或更高（含 `0.1.5-rc.2`） | `dsh plugin --profile web add dsh-perm-gate`（tag `latest`） |
+| 不高于 `0.1.1-rc.2` | `dsh plugin --profile web add dsh-perm-gate@legacy` |
+
+DSH 不强制 `engines.dsh`，因此 tag 是选择机制而非兼容性关卡。
+详见 [RELEASING.md](./RELEASING.md) 了解为何单一制品覆盖两条线以及 tag 的发布方式。
+
 ## 用官方 CLI 安装
 
 ```sh
@@ -103,11 +116,11 @@ dsh-perm-gate --rules permissions.yaml --tool bash --args '{"command":"pnpm inst
   "defaultAction": "ask",
   "ruleCount": 8,
   "permissive": false,
-  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false }
+  "permissiveStrategies": { "trustAutoAllow": true, "alwaysConfirm": false, "llmAssist": false, "trustEscalation": true }
 }
 ```
 
-UI 里 **设置 → 插件 → Permissive 审批档** 应渲染出一个开关加三个后台策略开关。
+UI 里 **设置 → 插件 → Permissive 审批档** 应渲染出一个开关加四个后台策略开关。
 
 ## 卸载
 

package/README.ja.md

@@ -18,6 +18,28 @@
 > `LOCALE_IDS`（locale-settings.ts）と `LOCALES` ラベル（client/index.ts）を更新した
 > DSH fork を使って再ビルドしてください。
 
+> **▼ DSH バージョン互換性**
+>
+> 2 つの DSH ラインが 2 つの長期ブランチから提供され、それぞれが独立したバージョン
+> 系列、`engines.dsh`、npm dist-tag を持っています
+> （[リリースレイアウト](./RELEASING.md)）：
+>
+> | 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` | `0.2.x` | `@latest` |
+>
+> `@deepseek-ai/dsh-client-runtime` は `0.1.2-alpha.1` で**削除**されました ——
+> 単なる移動ではありません。`legacy` ラインは引き続きこれを通じて
+> `ctx.slots` にアクセスします；`main` は
+> `@deepseek-ai/dsh-client-ui-renderer/client` から同じ宣言を取得します。
+> 2 つのバージョン依存シームは、バージョンチェックではなく機能プロブで処理
+> されます：（1）設定登録は `register` を使い、両ラインとも存在します
+> （`installSection` は追加であり、置き換えではありません）；（2）
+> `effectivePolicy` は両ラインとも user-approval サービスの**プライベート**
+> メソッドであるため、`typeof` プロブで読み取り、欠落時やエラー時には「ポリシー
+> 不明」にフォールバックします。
+
 バージョン **0.2.1-beta.3** — 変更履歴は [日本語 changelog](./CHANGELOG.ja.md) を参照。
 
 DeepSeek Harness 向けの、単一・自己完結・決定論優先・fail-closed な権限ゲートです。
@@ -57,8 +79,13 @@ DSH の安全まわりのエコシステムでは、この役割が `dsh-permiss
   モデルに見える理由と記録される結果は常に一致します。
 - **Permissive ティア** — read-only / full-access / whitelist とは別の**独立した承認
   モード**。「自動承認」でもなく、包括的な権限付与でもありません。フロントが露出する
-  のは**単一スイッチ**（`permissive`）だけで、バックエンドの 3 つの戦略は**組み合わせ
+  のは**単一スイッチ**（`permissive`）だけで、バックエンドの 4 つの戦略は**組み合わせ
   可能**でプラグイン設定から制御されます。P0 に対しては依然 fail-closed です。
+- **サンドボックス昇格の自動回答**（`trustEscalation`）— サンドボックス昇格は shell /
+   pwsh / edit ツールの**内部**（`tools/pre-execute` 後）から発生するためゲートはそれを
+   見ておらず、ゲートが自動許可した呼び出しでも確認プロンプトが表示されます。この戦略を
+   オンにすると、ゲートが許可した呼び出しを `callId` で正確に一致させてここで直接回答
+   します。
 
 ## インストール
 
@@ -133,6 +160,7 @@ Whitelist と並ぶ**独立した承認ティア**です。「自動承認」で
     permissiveStrategies:        # バックエンド戦略、組み合わせ可
       trustAutoAllow: true       # スコープ内安全操作は自動許可、危険/不明は ask
       alwaysConfirm: false       # すべて ask。許可コントロールに拡張ボタン 2 つ
+      trustEscalation: true      # ゲートが許可済みの呼び出し自身のサンドボックス昇格は確認不要
       llmAssist: false           # まず LLM が分類、ask/失敗時は人手へ
 ```
 
@@ -144,7 +172,30 @@ Whitelist と並ぶ**独立した承認ティア**です。「自動承認」で
 永続化して再読込）。`llmAssist` は設定済みの実際の LLM
 （受信先は設定カードで選択：**カスタム API**（`classifierEndpoint` / `classifierModel`。OpenAI 互換 API なら何でも可、Xiaomi MiMo `https://api.xiaomimimo.com/v1` 等のプリセット付き）または**ホストモデルグループ**（DSH の `llm` サービスと現在のモデルグループ、`classifierProvider` / `classifierModel` で上書き可）。**健全性テスト**ボタンで受信 LLM の疎通とレイテンシを確認可能）に
 `ask` の自動判定を委ね、`ask`/エラー時は人手のシームへフォールバックします —
-常に fail-closed です。`permissive` がオフなら、ゲートの挙動は以前と完全に同じです。
+常に fail-closed です。`trustEscalation`（ティア有効時に既定オン）はゲートがすでに許可した呼び出し内で
+`sandbox_permissions` 昇格が発生した際にここで回答します。以下参照。`permissive` がオフなら、ゲートの挙動は以前と完全に同じです。
+
+### サンドボックス昇格：なぜ `safe` 判定でもプロンプトが出たか
+
+ツール呼び出しは**2 つの独立した承認**を引き起こし得ます。ゲートが持つのが第 1 の承認 —
+`tools/pre-execute` ウォーターフォール上の `ask` です。第 2 はツール内部の `approveEscalation`、
+`tools/execute` 時刻に発生し、モデルが `sandbox_permissions` + `justification` を渡したとき；
+すでに `tools/pre-execute` は決着しているため、ゲートの allow はそこに届きません。LLM が `safe` と
+判定しゲートが自動許可した呼び出しでも、サンドボックス広げの確認プロンプトが出たままでした。
+
+`trustEscalation` はこの隙間を埋めます。ゲートは正面向上許可した呼び出し（ホストの `callId` で
+キー化され、昇格リクエストがこれを繰り返す）を記憶し、昇格をここで `allowed-once` と自答します。
+**すべてが満たされる場合のみ**適用されます：
+
+- Permissive ティアがオンで `trustEscalation` がオン；
+- 呼び出しにゲートが許可した `callId` があり、ツール名が一致；
+- 理由は認識された昇格で `workspace-write` または `danger-full-access` を命名。
+
+それ以外は — 認識されない理由、異なる呼び出し、ゲートが ask した/拒否した呼び出し、`approval:
+never` パススルー — は人手に変更なく委譲されるため、将来の DSH 変更でも open ではなく closed
+になります。自動回答はイベントフィードに記録されます
+（`verdict: "escalation-auto"`、`mode: <ターゲット>`）。スイッチをオフにすると広げは
+人手ゲート化されたまま、他の許可は自動のままとします。
 
 ### 選択可能なセッション ティア
 
@@ -174,7 +225,7 @@ Full access / `custom`）では、ゲートの判定フローは**一切実行
 
 このティアは実行時にも **設定 → プラグイン → Permissive 承認ティア** から調整できます
 （プラグインのブラウザ側が描画する `settings.plugins.tab` ページ）。1 つのスイッチが
-`permissive` を切り替え、3 つのトグルがバックエンドの `permissiveStrategies` を編集
+`permissive` を切り替え、4 つのトグルがバックエンドの `permissiveStrategies` を編集
 します。host は名前空間を live に読むため、変更は再起動なしで次のツール呼び出しから
 適用されます。これは独立した承認クラスであり、DSH の「auto-approval」モードでは
 **ありません**。

package/README.ko.md

@@ -18,6 +18,26 @@
 > (locale-settings.ts)와 `LOCALES` 라벨(client/index.ts)을 갱신한 DSH fork를 사용해
 > 다시 빌드하세요.
 
+> **▼ DSH 버전 호환성**
+>
+> 두 DSH 라인 각각이 장기 유지되는 두 브랜치를 통해 제공되며, 각자 고유한
+> 버전 시리즈, `engines.dsh`, npm dist-tag 을 가집니다
+> ([릴아웃](./RELEASING.md)):
+>
+> | 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` | `0.2.x` | `@latest` |
+>
+> `@deepseek-ai/dsh-client-runtime`은 `0.1.2-alpha.1`에서 **제거**되었습니다 —
+> 단순히 이동한 것이 아닙니다. `legacy` 라인은 여전히 이를 통해 `ctx.slots`에
+> 접근합니다. `main`은 `@deepseek-ai/dsh-client-ui-renderer/client`에서 같은
+> 선언을 가져옵니다. 두 버전 민감 시ーム은 버전 체크 대신 기능 프로브로 처리합니다:
+> (1) 설정 등록은 `register`를 사용하며, 두 라인 모두에 존재합니다
+> (`installSection`은 대체가 아닌 추가 사항); (2) `effectivePolicy`는 두 라인
+> 모두에서 user-approval 서비스의 **개인** 메소드이므로 `typeof` 프로브를 통해
+> 읽으며, 누락되거나 예외 발생 시 "정책_unknown"으로 후퇴합니다.
+
 버전 **0.2.1-beta.3** — 변경 내역은 [한국어 changelog](./CHANGELOG.ko.md)를 참고하세요.
 
 DeepSeek Harness용 단일·자족적·결정론 우선·fail-closed 권한 게이트입니다.
@@ -57,8 +77,12 @@ DSH 안전 생태계에서는 이 역할이 `dsh-permission-rules` / `dsh-auto-m
   모델에 보이는 이유와 기록된 결과는 항상 일치합니다.
 - **Permissive 티어** — read-only / full-access / whitelist와 구별되는 **독립 승인
   모드**. "자동 승인"도 아니고 포괄적 권한 부여도 아닙니다. 프론트는 **단일 스위치**
-  (`permissive`)만 노출하고, 백엔드의 세 가지 전략은 **조합 가능**하며 플러그인
+  (`permissive`)만 노출하고, 백엔드의 네 가지 전략은 **조합 가능**하며 플러그인
   설정으로 제어됩니다. P0에 대해서는 여전히 fail-closed입니다.
+- **샌드박스 승격 자동 응답** (`trustEscalation`) — 샌드박스 승격은 shell / pwsh /
+   edit 도구의 **내부**(`tools/pre-execute` 이후)에서 발생하므로 게이트가 이를 볼 수
+   없고, 게이트가 자동 허용한 호출에도 확인 프롬프트가 나타납니다. 이 전략을 켜면 게이트가
+   `callId`로 이미 허용한 호출을 정확히 매칭하여 여기서 직접 응답합니다.
 
 ## 설치
 
@@ -133,10 +157,11 @@ Permissive는 권한 선택기에서 Read Only / Workspace Write / Full access /
     permissiveStrategies:        # 백엔드 전략, 조합 가능
       trustAutoAllow: true       # 범위 내 안전 작업 자동 허용, 위험/미확인은 ask
       alwaysConfirm: false       # 매번 ask. 허용 컨트롤에 확장 버튼 2개
+      trustEscalation: true      # 게이트가 허용한 호출 자체의 샌드박스 승격은 확인 불필요
       llmAssist: false           # 먼저 LLM이 분류, ask/실패 시 사람에게
 ```
 
-`trustAutoAllow`는 중간 티어의 기준선입니다(rule-allow는 자동 통과). `alwaysConfirm`은
+`trustAutoAllow`은 중간 티어의 기준선입니다(rule-allow는 자동 통과). `alwaysConfirm`은
 모든 경계에서 승인 패널을 띄우며, 그「허용 컨트롤」에 두 개의 확장 버튼을 추가합니다 —
 **이 세션에서 해당 유형 반복 허용**(`approveRepeat`, 유계 세션 허용)과 **모든 발생
 허용**(`approveAllowEverywhere`, 명령어를 `permissions.yaml`의 allow 허용 목록에
@@ -145,8 +170,33 @@ Permissive는 권한 선택기에서 Read Only / Workspace Write / Full access /
 프리셋 포함) 또는 **호스트 모델 그룹**(DSH의 `llm` 서비스와 현재 모델 그룹, `classifierProvider` /
 `classifierModel`로 재정의 가능). **상태 테스트** 버튼으로 수신 LLM의 연결과 지연 시간을 확인할 수 있음)에 `ask` 자동 판정을 맡기고,
 `ask`/오류 시 사람의 승인 심으로 폴백합니다 — 항상 fail-closed입니다.
+`trustEscalation`（티어 켜짐时 기본 켬）은 게이트가 이미 허용한 호출 내부에서
+`sandbox_permissions` 승격이 발생할 때 여기서 응답합니다. 아래 참조.
 `permissive`가 꺼져 있으면 게이트는 이전과 완전히 동일하게 동작합니다.
 
+### 샌드박스 승격: 왜 `safe` 판정에도 프롬프트가 떴나
+
+툴 호출은 **두 개의 독립된 승인**을 일으킬 수 있습니다. 게이트가 맡는 것이 첫 번째 —
+`tools/pre-execute` 워터폴의 `ask`입니다. 두 번째는 툴 내부의 `approveEscalation`,
+`tools/execute` 시점, 모델이 `sandbox_permissions` + `justification`을 건넸을 때
+발생 — 이미 `tools/pre-execute`는 끝났으므로 게이트의 allow는 여기에 닿지 않습니다.
+LLM이 `safe`로 판정하고 게이트가 자동 허용한 호출조차 샌드박스 확장을 승인하라는
+프롬프트가 떴습니다.
+
+`trustEscalation`은 이 간극을 메웁니다. 게이트가 정面向上 허용한 호출(호스트의
+`callId`로 키화, 승격 요청이 이를 반복)을 기억하고 승격을 여기서 `allowed-once`로
+자응답합니다. **모든 조건이 충족될 때만** 적용됩니다:
+
+- Permissive 티어가 켜져 있고 `trustEscalation`이 켜져 있음;
+- 호출에 게이트가 허용한 `callId`가 있고, 툴 이름이 일치;
+- 원인이 알려진 승격이며 `workspace-write` 또는 `danger-full-access`를 명시.
+
+그 외의 모든 경우 — 알려지지 않은 원인, 다른 호출, 게이트가 ask/deny한 호출, `approval:
+never` 패스스루 — 는 사람에 그대로 위임되므로 향후 DSH 변경이 open이 아닌 closed로
+실패합니다. 자동 응답은 이벤트 피드에 기록됩니다
+(`verdict: "escalation-auto"`, `mode: <대상>`). 스위치를 끄면 샌드박스 확장은
+사람 게이트로 유지되고 다른 허용은 자동 상태를 유지합니다.
+
 ### 선택 가능한 세션 티어
 
 `cordis.patch.yml`은 DSH의 `permission.config.presets`에 Workspace Write와
@@ -174,7 +224,7 @@ P0 하드 거부도, 거부 키워드 차단도, 감사 이벤트 기록도 하
 
 이 티어는 실행 중에도 **설정 → 플러그인 → Permissive 승인 티어**에서 조정할 수 있습니다
 (플러그인 브라우저 절반이 렌더링하는 `settings.plugins.tab` 페이지). 스위치 하나가
-`permissive`를 토글하고, 토글 세 개가 백엔드 `permissiveStrategies`를 편집합니다.
+`permissive`를 토글하고, 네 개가 백엔드 `permissiveStrategies`를 편집합니다.
 host는 네임스페이스를 live로 읽으므로 변경은 재시작 없이 다음 도구 호출부터 적용됩니다.
 이것은 독립적인 승인 클래스이며 DSH의 "auto-approval" 모드가 **아닙니다**.
 

package/README.md

@@ -20,19 +20,22 @@
 
 > **▼ DSH version compatibility**
 >
-> | DSH version | Load | Settings registration | Host gate | Client half |
-> | --- | --- | --- | --- | --- |
-> | 0.1.0-rc.7 ~ 0.1.1-rc.x | ✅ | `ctx.settings.register(ns, schema, { base })` | ✅ `tools/pre-execute` identical | ✅ type-only imports |
-> | 0.1.2-alpha.2+ / 0.1.2-rc.1 | ✅ | `register` still present (`installSection` added) | ✅ `tools/pre-execute` identical | ✅ type-only imports |
+> Two DSH lines are served from two long-lived branches, each with its own version
+> series, `engines.dsh`, and npm dist-tag ([release layout](./RELEASING.md)):
 >
-> One artifact covers both. Two version-sensitive seams are handled by capability
-> probes rather than version checks: (1) settings registration uses `register`,
-> which exists in every supported version (`installSection` is a 0.1.2 addition,
-> not a replacement); (2) `effectivePolicy` is a **private** method of the
-> user-approval service in **both** versions, so it is read behind a `typeof`
-> probe and degrades to “policy unknown” when absent or throwing. The client
-> bundle value-imports nothing from `@deepseek-ai/*`, so the 0.1.2
-> `dsh-client-runtime` → `dsh-client-store` rename cannot break it.
+> | 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` | `0.2.x` | `@latest` |
+>
+> `@deepseek-ai/dsh-client-runtime` was **removed** at `0.1.2-alpha.1` — it did not
+> merely move. The `legacy` line still reaches `ctx.slots` through it; `main` gets
+> the same declaration from `@deepseek-ai/dsh-client-ui-renderer/client`. Two
+> version-sensitive seams are handled by capability probes rather than version
+> checks: (1) settings registration uses `register`, which exists on both lines
+> (`installSection` is an addition, not a replacement); (2) `effectivePolicy` is a
+> **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 **0.2.1-beta.3** — see the [Changelog](./CHANGELOG.md).
 
@@ -71,8 +74,12 @@ cross-plugin version coupling.
   model-visible reason matches the recorded outcome.
 - **Permissive tier** — 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 three backend strategies are **combinable** and driven
+  **single switch** (`permissive`); the four backend strategies are **combinable** and driven
   by plugin settings — still fail-closed against P0.
+- **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
+  on, the exact call the gate cleared (matched by `callId`) is answered here instead.
 - **Risk-graded `llmAssist`** — a custom OpenAI-compatible LLM grades each `ask` as
   `safe` / `risky:<category>`; hard categories (deletion, credential, remote, system, bulk)
   **always ask**, neutral enters verdict learning, and every failure stays fail-closed.
@@ -161,6 +168,7 @@ In `cordis.yml`:
       trustAutoAllow: true       # in-scope safe ops auto-allow; dangerous/unknown ask
       alwaysConfirm: false       # every crossing asks; allow-controls add repeat-allow / wl-migrate buttons
       llmAssist: false           # LLM classify first, human fallback on ask/failure
+      trustEscalation: true      # a cleared call's own sandbox escalation needs no prompt
 ```
 
 `trustAutoAllow` is the baseline middle tier (rule-allow auto-passes). `alwaysConfirm` surfaces
@@ -169,8 +177,33 @@ the approval panel for every crossing; its "allow controls" add two extended but
 (which persists the command word into the `permissions.yaml` allow whitelist via
 `approveAllowEverywhere`). `llmAssist` consults a real, configurable LLM (`classifierEndpoint` /
 `classifierModel`, any OpenAI-compatible API) to auto-decide an `ask`, and falls back to the
-human seam on `ask`/error — always fail-closed. When `permissive` is off, the gate behaves
-exactly as before.
+human seam on `ask`/error — always fail-closed. `trustEscalation` (on by default while the tier
+is on) answers a `sandbox_permissions` escalation raised from inside a call the gate already
+allowed; see below. When `permissive` is off, the gate behaves exactly as before.
+
+### Sandbox escalation: why a `safe` verdict still prompted
+
+A tool call can raise **two independent approvals**. The gate owns the first — its own `ask`, on
+the `tools/pre-execute` waterfall. The second comes from `approveEscalation` **inside the tool
+body**, at `tools/execute` time, whenever the model passed `sandbox_permissions` +
+`justification`; by then `tools/pre-execute` has already settled, so the gate's allow never
+reaches it. A call the LLM graded `safe` and the gate auto-allowed therefore still showed a
+prompt asking you to approve the sandbox widening.
+
+`trustEscalation` closes that gap. The gate remembers every call it positively allowed (keyed by
+the host's `callId`, which the escalation request repeats) and answers the escalation
+`allowed-once` itself. It applies only when *all* hold:
+
+- the Permissive tier is on and `trustEscalation` is on;
+- the request carries a `callId` the gate cleared, with a matching tool name;
+- the reason is a recognized escalation naming `workspace-write` or `danger-full-access`.
+
+Everything else — an unrecognized reason, a different call, a call the gate asked or denied, the
+`approval: never` passthrough — delegates to the human unchanged, so a future DSH wording change
+fails closed rather than open. The auto-answer is recorded on the event feed
+(`verdict: "escalation-auto"`, `mode: <target>`). Turn the switch off to keep widening
+human-gated while other allows stay automatic.
+
 
 ### Risk-graded llmAssist, verdict learning, and the event feed
 
@@ -248,7 +281,7 @@ session's effective approval policy is `never`.
 
 The tier is also adjustable at runtime from **Settings → Plugins → Permissive approval tier**
 (a `settings.plugins.tab` page rendered by the plugin's browser client): one switch toggles
-`permissive`, and three toggles edit the backend `permissiveStrategies`. The host reads the
+`permissive`, and four toggles edit the backend `permissiveStrategies`. The host reads the
 namespace live, so a change applies to the next tool call without a restart. This is an
 independent approval class, NOT the DSH "auto-approval" mode.