Evidence-Loop Development (ELD)

証拠で回す統合開発手法。コードを「相互接続された意味のグラフ」として理解し、 Law/Termで規範を定め、安全な微小変更で実装し、知識を構造化して蓄積する。

核心原則

1. •Epistemic Humility: 推測を事実として扱わない。unknownと言う勇気を持つ
2. •Evidence First: 結論ではなく因果と証拠を中心にする
3. •Grounded Laws: Lawは検証可能・観測可能でなければならない
4. •Minimal Change: 最小単位で変更し、即時検証する
5. •Source of Truth: 真実は常に「現在のコード」。要約をインデックスとして扱う

統一ループ

Sense → Model → Predict → Change → Ground → Commit → Record
  ↑                                                      ↓
  └──────────────────── 循環 ←───────────────────────────┘

統一概念

Evidence Pack（証拠パック）

変更の正当性を証明する一式の証拠。PRの中心。

Epistemic Status（認識論的状態）

• •verified: コードまたはテストで確認済み
• •inferred: 構造や慣習から推論
• •unknown: 確認不能/要調査

Evidence Ladder（証拠の梯子）

Issue Contract（ローカル契約）

• •目的（Goal）
• •不変条件（Invariants）
• •物差し（Acceptance Criteria）
• •停止条件（Stop Conditions）

Law/Term（グローバル法則）

• •Law: ビジネス上の「守るべき条件」（Invariant/Pre/Post/Policy）
• •Term: ドメインの語彙（Entity/Value/Context/Boundary）
• •Link Map: Law ↔ Term の相互参照。孤立禁止

詳細は 00-glossary.md を参照。

開発フロー

Phase 1: Issue（受付）

成果物:
  - Issue Contract: 目的/不変条件/物差し/停止条件
  - 現状証拠: Senseフェーズの観測結果
  - Term/Law候補: Modelフェーズの初期出力

実行内容: 0. 要件明確化 (新機能開発時):

• •/eld-sense-requirements-brainstorming で要件の曖昧さを対話的に解消
• •Law/Term観点、境界条件、失敗モードから体系的に質問
• •Issue Contract 下書き生成

1. •pce.memory.activate で関連知識を活性化
2. •目的に応じたツールでコード調査（10-sense.md 参照）
   • •特定キーワード → Grep
   • •定義・参照追跡 → LSP / serena
   • •シンボル検索 → serena（利用可能時）
   • •意味的関連探索 → kiri context_bundle
3. •Issue Contractを作成（issue-template.md使用）
4. •Term/Law候補を列挙

使用スキル: /eld-sense-requirements-brainstorming (新機能時), /eld-sense-activation, /eld-model-law-discovery

Phase 2: Design（設計）

成果物:
  - Law/Term Cards: 相互参照あり、孤立なし
  - Grounding Plan: 必要テスト/Telemetry（Evidence Ladder対応）
  - Change Plan: 微小変更列＋各ステップのチェック

実行内容:

1. •Law Card化（Scope/例外/違反時動作）
2. •Term Card化（意味/境界/観測写像）
3. •Link Map更新（孤立チェック）
4. •影響予測と段階化計画
5. •Grounding Plan策定（/test-design-auditでテスト設計）

使用スキル: /eld-model-law-card, /eld-model-term-card, /test-design-audit

Phase 3: Implementation（実装ループ）

各ステップを同じ型で回す:

1. Sense   → 触るシンボル/境界/設定の身体図更新
2. Predict → 期待される因果と失敗モード
           → High/Criticalリスク時はworktree提案
3. Change  → 最小単位で変更、Pure/IO分離を維持
           → worktree隔離環境で実験（高リスク時）
4. Ground  → テスト/Telemetryで観測写像を満たす
           → TDD強制（RED-GREEN-REFACTOR）でL1達成
5. Commit  → 検証通過後にコミット（詳細: 40-change.md）
6. Record  → Context Delta記録

高リスク変更の隔離:

• •リスクレベルがHigh/Criticalの場合、worktreeで隔離環境作成
• •実験成功後、Cherry-pick/Rebase/Mergeでmainに統合
• •失敗時は即座にworktree削除で元に戻る

TDD強制:

• •S0/S1 Lawは必ずL1（ユニットテスト）達成が必須
• •RED（失敗テスト）→ GREEN（最小実装）→ REFACTOR（品質改善）サイクル
• •テストなし実装を許さず、コミット前にEvidence L1確認

使用スキル: /eld-change-worktree, /eld-ground-tdd-enforcer, /eld-predict-impact, /eld-record-collection

停止条件チェック:

• •予測と現実の継続的乖離
• •観測不能な変更の増加
• •ロールバック線の崩壊

Phase 4: Review（レビュー）

証拠パック中心:
  - 因果と証拠の整合
  - Law/Term孤立チェック
  - 影響範囲のグラフ証拠
  - Evidence Ladder達成レベル

使用スキル: /eld-ground-check

PR作成: pr-template.md 使用

Phase 5: Ops（運用）

• •Telemetryで Law違反を監視
• •Context Deltaを回収→構造化
• •物差しの再点検
• •pce-memoryへのフィードバック

知識ストア

pce-memory 3層構造

品質優先原則（Superpowers統合）

核心原則

1. •Epistemic Humility: 推測を事実として扱わない。unknownと言う勇気を持つ
2. •Evidence First: 結論ではなく因果と証拠を中心にする
3. •Minimal Change: 最小単位で変更し、即時検証する
4. •Grounded Laws: Lawは検証可能・観測可能でなければならない
5. •Source of Truth: 真実は常に現在のコード。要約はインデックス

「速さより質」の実践

• •要件の曖昧さによる手戻りを根本から排除
• •テストなし実装を許さない
• •観測不能な変更を防ぐ

完了条件・停止条件の詳細は次セクション参照。

完了条件と停止条件

完了条件

• •Issue Contractの物差しが満たされている
• •Law/Termが接地している（Evidence Ladder L1以上）
• •Evidence Packが揃っている
• •Link Mapに孤立がない

停止条件（発生時は追加計測/スコープ縮小）

• •予測と現実の継続的乖離（想定外のテスト失敗3回以上）
• •観測不能な変更の増加（物差しで検証できない変更）
• •ロールバック線の崩壊（戻せない変更の発生）

リファレンス

概念定義

• •00-glossary.md - 統一語彙

フェーズ詳細

• •10-sense.md - 感知フェーズ（旧DCCA）
• •20-model.md - モデル化フェーズ（旧LDE Law/Term発見）
• •30-predict.md - 予測フェーズ（旧Proprioceptive）
• •40-change.md - 変更フェーズ
• •50-ground.md - 接地フェーズ
• •60-record.md - 記録フェーズ（旧PCE）

テンプレート

• •issue-template.md - Issue Contract雛形
• •pr-template.md - PR & Evidence Pack雛形
• •law-term-card.md - Law/Term Card雛形

使用例

User: ユーザー認証機能をELDで実装して

Claude:
## ELD Phase 1: Issue

### Issue Contract
- 目的: JWTベースの認証機能実装
- 不変条件: 既存APIとの後方互換性
- 物差し: 認証テスト通過 + レスポンス<200ms
- 停止条件: セキュリティ脆弱性発見時

### 現状証拠（Sense）
[verified]
- 既存認証: src/auth/legacy.ts:23-45（Basic認証）
- 関連モジュール: src/middleware/auth.ts

[unknown]
- 外部認証プロバイダとの連携状況

### Term/Law候補（Model）
- TERM-jwt-token: JWT形式のアクセストークン（S1）
- TERM-refresh-token: リフレッシュトークン（S1）
- LAW-token-expiry: アクセストークンは1時間で失効（S0）
- LAW-refresh-validity: リフレッシュトークンは7日間有効（S1）

Phase 2: Designに進みますか？

デバッグへの適用

ELDの統一ループはデバッグにも適用できる。バグを「法則（Law）からの逸脱」として捉え、 証拠ループで系統的に解決する。

デバッグループ

Sense → Model → Predict → Change → Ground → Record
  ↑                                            ↓
  └──────────── 法則復元まで循環 ←──────────────┘

ELD的デバッグの特徴

詳細は /eld-debug スキルを参照。

ユーティリティスキル

ELDループ内で使用する補助スキル:

Sense（感知）

Model（モデル化）

Change/Commit（変更・コミット）

Ground（接地）

Record（記録）

Debug（デバッグ）