A
PHASE
DB Path 切換
兩邊都加 CCFAMILY_HOME env var 偵測。預設仍走各自 SQLite，啟用後讀寫 unified DB。
SCOPE: ccRecall + ccRewind
EFFORT: 1-2 hr each
RISK: 低（fallback default）
// 6 BASELINE (兩邊都有) + 7 ccRecall + 7 ccRewind = 20 unified target
ccFamily 共用的 SQLite schema 規範。真正兩邊都有、必須同步改的是 6 張 baseline 表；其餘 14 張各自獨立，因為兩個工具本來就在讀不同的東西。 未來合併到 ~/.ccfamily/db.sqlite 走 reversible migration。
6
BASELINE · 兩邊都有
7
ccRecall · DOMAIN
7
ccRewind · DOMAIN
改 baseline 表 → 兩邊同步 cross-PR；改 domain 表 → 自己 repo 即可。Source of truth 寫在 .claude/architecture/schema-spec.md。
// CROSS-PR ENFORCED
// 只有這 6 張要求兩邊同步改。
// 訊息內容那幾張為何不在這裡，見下方 DESIGN NOTE。
// MEMORY + METACOGNITION
// v0.5.0 刪掉 session_journal 與 session_checkpoints——
// 兩張都沒有呼叫者，理由見 ccRecall 頁
// 訊息內容 + GUI 狀態
它是從 ccRewind fork 出來的，當初連 storage 層一起搬了過去，訊息表也就跟著來了。v0.2.0 把它們刪掉——內部盤點發現記憶召回、session 摘要、FTS 搜尋、萃取，沒有一條路徑會去查訊息表。純粹是 fork 的殘留，佔著空間沒人讀。
所以現在的分法反映的是實際用途：ccRewind 是歷史 GUI，必須逐則存訊息才能讓你回頭讀；ccRecall 是記憶層，只需要 session 層級的 metadata，加上自己萃取出來的記憶。
// 這頁一度寫成「10 表已對齊」——那是 spec 沒跟上實作，2026-07 校正。
三段式 migration 設計：env var 切換 → migrate tool → rollback path。**ASSERT #06 可逆遷移**的具體實作路線。
兩邊都加 CCFAMILY_HOME env var 偵測。預設仍走各自 SQLite，啟用後讀寫 unified DB。
SCOPE: ccRecall + ccRewind
EFFORT: 1-2 hr each
RISK: 低（fallback default）
ccfamily-migrate 工具：偵測兩邊 DB → 建 unified → 複製 baseline + domain → VACUUM → 保留原始檔。
CONFLICT: UNION + PK dedup
EFFORT: 2-3 days
LOG: ~/.ccfamily/migration.log
ccfamily-migrate rollback → unified DB 標記 archived，兩邊重新指回各自舊 DB。**不刪除** unified（純粹回 baseline）。
REVERSIBLE: ✓ always
EFFORT: 1-2 days
DATA LOSS: 0
// 整合採用者隨時可退出 — 這是 family overview ASSERT #06 的承諾。Migration tool 還沒實作，但設計已定。