獨立 peer
做成第三個 peer 等於要重新發明 storage 層 —— 自家 SQLite schema、自家 indexer、自家 lifecycle。資源浪費，且雙寫風險（ADR 推理需要的 memory 可能還沒同步）。
// duplicate storage layer
⚠ DESIGN PREVIEW · NOT YET BUILT · NO PUBLIC RELEASE
// READ(ccrecall.memories + knowledge_map) → REASON → ADR.md
獨立 npm 包，但讀 ccRecall 的共用 schema 推導 Architecture Decision Records。把 Claude 與你討論過的決策脈絡，整成可 commit 的 ADR markdown。 設計已定，實作待寫。
// 沒有 release date — 設計優先，實作待 Phase 02 ccRewind 收斂後啟動。
ccReason 的核心動作是「讀 ccRecall 的 memories + knowledge_map 表推 ADR」—— 讀寫都依賴 ccRecall 的 SQLite schema。三個架構選項擺在桌上：
做成第三個 peer 等於要重新發明 storage 層 —— 自家 SQLite schema、自家 indexer、自家 lifecycle。資源浪費，且雙寫風險（ADR 推理需要的 memory 可能還沒同步）。
// duplicate storage layer
做成 ccrecall reason adr 會污染 ccRecall codebase —— ADR 推理是另一個關注點，混在 memory layer 裡會讓兩者都複雜。lifecycle 也會綁死。
// codebase pollution
獨立 @tznthou/ccreason npm 包，但讀 ccRecall 的 SQLite schema。獨立 lifecycle、獨立 codebase，但共享資料層。兩邊優勢都拿到。
// independent npm + shared schema
// 仍是 CLI、仍是 ADR markdown、仍是 Apache-friendly 設計。對 V2 ADR CLI 路線是補充，不是顛覆。
下面命令與輸出是設計示意，尚未可執行。實際介面在實作時可能調整。
$ ccreason adr "why did we switch to NATS" # 讀取 ccRecall: 12 relevant memories # knowledge_map → topic="messaging" → 8 related entries → Synthesizing... ✓ ADR-042 written: docs/adr/0042-switch-to-nats.md Status: Accepted Context: 5 weeks of latency issues with RabbitMQ persistent queues... Decision: Migrate to NATS JetStream for at-least-once delivery... Consequences: +3 services impacted, -40% p99 latency observed... # Sources: 12 memories from ccRecall (2026-03-15 to 2026-04-22) # Confidence: 0.78 (high · 8/12 sources direct, 4/12 inferred)
// ccReason 不會替你做決策，只整合你（與 Claude）已經討論過的內容。Confidence 低於閾值會 abort 並列出缺失的脈絡。