feat: Memory Promotion Gate を導入し、経験のルール・Skill・Hook化を審査する

## 背景 / Why

セッション履歴から繰り返された失敗・成功を抽出し、`short-term → long-term → CLAUDE.md / Skill / Hook` へ昇格させる運用事例が公開されている。

参考:
- https://zenn.dev/nexta_/articles/858e92ee22b4a4

この仕組みは自己改善に有効だが、`pain_count >= 3` のような固定回数だけで実行可能なルールへ昇格させると、次のリスクがある。

- 偶発的な失敗や成功を恒久ルールとして誤採用する
- プロジェクト固有知識をグローバルルールへ拡大する
- CLAUDE.mdが肥大化し、指示競合やコンテキスト消費を起こす
- 本来はlint・test・CIで防ぐべき問題を自然言語ルールだけで処理する
- 古くなったルールを降格・廃止できない
- SkillやHookが権限・外部送信・破壊的操作へ影響する

PlanGateには、ai-second-brain等が生成した学習候補を審査し、実行可能な振る舞いへ安全に昇格させる **Memory Promotion Gate** が適している。

## 目的 / What

観測された経験を、証拠・重大度・再現性・適用範囲・強制方法・コスト・誤検知リスクに基づいて審査し、次のいずれかへ昇格、保留、却下、降格できるゲートを設計する。

- long-term memory / wiki
- CLAUDE.md等の常設ルール
- Skill
- Hook
- lint / test / CI
- Runbook
- 対応不要 / archive

## 想定フロー

```text
Observation / Pattern Candidate
  → Intake / Triage
  → Evidence Verification
  → Scope & Risk Classification
  → Promotion Target Selection
  → Gate Decision
  → Canary / Limited Rollout
  → Effect Verification
  → Promote / Revise / Rollback
  → Trust Ledger
```

既存の6段階ループとの対応案:

```text
Triage      : 候補の種類・重大度・対象スコープを分類
Conductor   : 必要な検証者・設計者・実行者を選択
Worker      : ルール、Skill、Hook、test等の変更案を作成
Verifier    : 根拠、反例、競合、既存機構との重複を検証
Gate        : 承認 / 条件付き承認 / 保留 / 却下 / 降格
Trust Ledger: 効果、失敗、再試行、ロールバック、人手介入を記録
```

## 検討項目

### 1. 入力契約

ai-second-brainやRiver Review等から、少なくとも次を受け取れる形式を定義する。

```yaml
candidate_id: pattern-id
kind: pain | success | decision | preference | fact
summary: ""
evidence: []
pain_count: 0
success_count: 0
failure_count: 0
severity: low | medium | high | critical
confidence: 0.0
scope: project | cross-project | global
proposed_target: memory | rule | skill | hook | test | runbook
constraints: []
risks: []
```

### 2. 固定回数ではなくリスクベースで判定

例:

| 種別 | 初期方針候補 |
|---|---|
| 秘密情報、認可、破壊的操作、データ損失 | 1回でも即時候補化。必ず人間承認 |
| 再現可能なバグ | 2〜3回、または重大度で前倒し |
| レビュー・検証手順 | 複数回の成功と失敗比較 |
| コーディングスタイル | 十分な反復とプロジェクト合意 |
| ユーザー選好 | 複数コンテキストで確認 |
| Skill化する成功手順 | 再利用性、成功率、適用条件を確認 |

次のようなスコアリングは参考案とし、最終的には説明可能な判定規則を優先する。

```text
promotion_score =
  recurrence
  × severity
  × confidence
  × cross_project_reusability
  × enforceability
  - context_cost
  - false_positive_risk
  - blast_radius
```

### 3. 昇格先の選択基準

- 説明・参照が目的ならmemory / wiki
- 常時必要な短い原則のみCLAUDE.md
- 条件付きの手順ならSkill
- 必ず実行すべき制約ならHook
- 決定論的に検証できるならlint / test / CI
- 障害対応・運用手順ならRunbook

自然言語ルールより機械的な制約を優先できるようにする。

### 4. 証拠検証

- 根拠となるセッション、diff、テスト、仕様を確認する
- 同じ根本原因を別件として重複カウントしていないか確認する
- 表面的に似ている別原因を統合していないか確認する
- 成功と手順の因果関係が弱い場合は保留する
- 反例と例外条件を記録する
- 外部記事だけを根拠に採用せず、対象リポジトリで再現・検証する

### 5. Gate結果

最低限、次の判定を扱う。

- `approve`: そのまま昇格可能
- `approve_with_conditions`: スコープ、期限、Canary等の条件付き
- `needs_evidence`: 根拠不足
- `needs_human_review`: 高リスクまたは価値判断が必要
- `reject`: 採用しない
- `duplicate`: 既存ルール・Skill・Hook等と重複
- `prefer_automation`: CLAUDE.mdではなくtest / CI等へ変更
- `deprecate`: 既存ルールを降格・廃止

### 6. Canaryとロールバック

- 最初はプロジェクト限定または特定タスク限定で試す
- CLAUDE.md、Skill、Hookの変更前後で成功率・再試行・人手介入を比較する
- 誤検知、過剰制約、コンテキスト増加、処理時間増加を測る
- 問題があれば前のバージョンへ戻せるようにする
- 昇格された知識には由来candidateとdecisionを紐付ける

### 7. Trust Ledger連携

記録候補:

```yaml
candidate_id: pattern-id
decision: approve_with_conditions
promoted_to: skill/review-ai-feedback
model: gpt-5.6-terra
reason: "複数案件で再現し、誤検知が低い"
evidence_count: 6
human_intervention: true
canary_scope: project-x
before:
  success_rate: 0.68
  retry_count: 9
after:
  success_rate: 0.84
  retry_count: 3
rollback_count: 0
revalidate_at: 2026-08-11
```

モデル別コスト、成功率、再試行、昇格理由、人手介入も追跡する。

### 8. 自動化レベル

初期方針案:

| 処理 | 自動化 |
|---|---|
| 候補受領・スキーマ検証 | 自動 |
| 類似候補・既存機構の検索 | 自動 |
| リスク分類・変更案作成 | 自動提案 |
| low-riskなmemory候補の保存 | 条件付き自動 |
| CLAUDE.md変更 | 承認必須 |
| Skill追加・変更 | 承認またはCanary必須 |
| Hook追加・権限変更 | 承認必須 |
| 外部送信・認証・破壊的操作 | 承認必須 |
| 降格・廃止 | 根拠提示と承認を原則 |

HOTLへ移行する場合も、blast radiusに応じて自動化範囲を段階的に拡大する。

## 他リポジトリとの責務分担

- `ai-second-brain`: 観測、パターン、証拠、知識候補を管理
- `PlanGate`: 候補の検証、昇格先選択、承認、Canary、ロールバック、Trust Ledger
- `river-review`: レビュー指摘の採否、誤検知、有効性を学習候補として供給
- `hermes-agent-ops`: 実環境への適用と権限制御

## 非目標 / Non-goals

- `3回発生したら自動承認` の固定ルールを導入すること
- すべての知識候補をPlanGate内に永続保存すること
- CLAUDE.mdを万能な知識保存先として扱うこと
- lint・test・CIで防止できる問題を自然言語だけで解決すること
- 高リスクなHookや権限変更を無承認で適用すること

## 受け入れ条件 / Definition of Done

- [ ] Memory Promotion Gateの責務と既存Gateとの差分を文書化する
- [ ] candidate入力スキーマとdecision出力スキーマを定義する
- [ ] 重大度、再現性、信頼度、スコープ、blast radiusを使う判定方針を定義する
- [ ] memory / rule / Skill / Hook / test / Runbookの選択基準を定義する
- [ ] Gate結果と理由コードを定義する
- [ ] 高リスク変更の承認境界を定義する
- [ ] Canary、効果測定、ロールバック、再検証の手順を定義する
- [ ] Trust Ledgerへの記録項目を追加・整理する
- [ ] 代表的な候補3種類以上で判定例を作る
- [ ] 既存PlanGate / ai-loopとの統合案を作成する
- [ ] 導入判断（採用 / 部分採用 / 見送り）をADRまたは同等文書に残す

## 成功指標候補

- 誤昇格率、取り消し率、ロールバック率
- 同型失敗の再発率
- 昇格後の成功率・再試行回数・人手介入の変化
- CLAUDE.mdの増加量と指示競合件数
- Skill / Hook / testへの適切な振り分け率
- 候補受領から判断までのリードタイム


Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Memory Promotion Gate を導入し、経験のルール・Skill・Hook化を審査する #811

背景 / Why

目的 / What

想定フロー

検討項目

1. 入力契約

2. 固定回数ではなくリスクベースで判定

3. 昇格先の選択基準

4. 証拠検証

5. Gate結果

6. Canaryとロールバック

7. Trust Ledger連携

8. 自動化レベル

他リポジトリとの責務分担

非目標 / Non-goals

受け入れ条件 / Definition of Done

成功指標候補

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

種別	初期方針候補
秘密情報、認可、破壊的操作、データ損失	1回でも即時候補化。必ず人間承認
再現可能なバグ	2〜3回、または重大度で前倒し
レビュー・検証手順	複数回の成功と失敗比較
コーディングスタイル	十分な反復とプロジェクト合意
ユーザー選好	複数コンテキストで確認
Skill化する成功手順	再利用性、成功率、適用条件を確認

処理	自動化
候補受領・スキーマ検証	自動
類似候補・既存機構の検索	自動
リスク分類・変更案作成	自動提案
low-riskなmemory候補の保存	条件付き自動
CLAUDE.md変更	承認必須
Skill追加・変更	承認またはCanary必須
Hook追加・権限変更	承認必須
外部送信・認証・破壊的操作	承認必須
降格・廃止	根拠提示と承認を原則

feat: Memory Promotion Gate を導入し、経験のルール・Skill・Hook化を審査する #811

Description

背景 / Why

目的 / What

想定フロー

検討項目

1. 入力契約

2. 固定回数ではなくリスクベースで判定

3. 昇格先の選択基準

4. 証拠検証

5. Gate結果

6. Canaryとロールバック

7. Trust Ledger連携

8. 自動化レベル

他リポジトリとの責務分担

非目標 / Non-goals

受け入れ条件 / Definition of Done

成功指標候補

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions