兩套都能準確定位符號；勝負在「定位之外」。下列每一處差異都用 grep 對過真值，按四個維度逐項裁決。
四個維度是平行類別、非流程，故以對決計分呈現；長條即評分，亮色一方為該維勝者。
節點數差異主要來自建模哲學：codegraph 把 import / constant / enum_member 也物化成節點；codebase-memory 走「符號 + 結構 + 語意」分層。同自 repo 根索引，scope 一致。
兩個符號的 caller 完整性是這次裁決的決定性證據。每處呼叫點皆 grep 確認其外層函式。
handleUserText 的 callers ✓ 真值 = 2真實呼叫點：ws-gateway.ts:235（handleConnection）、webrtc-connection.ts:99（巢狀 async function onUserTurn）
assertWithinQuota 的 callers ✓ 真值 = 55 處呼叫程式碼模式完全相同（quotaService.assertWithinQuota(...)）— 同一 singleton 實例方法
handleUserText body 的 callees ✓ 真值 = 5runStreamingTurn / handleTurnError / log（同檔）兩邊皆對；介面型別 dispatch 是共同盲點
同樣是圖，但能問的問題不同。青色「僅此一家」為對方完全沒有對應能力的項目。
| 能力 | codegraph | codebase-memory |
|---|---|---|
| 兩符號間路徑追蹤 | ⭐ trace：整條 path + 每跳 inline body | 名稱清單，無 body |
| 複合 context 一次取 | ⭐ context / explore 多符號源碼 | 需分次組合 |
| 任意 Cypher 查詢 | ❌ 無 | ⭐ query_graph 僅此一家 |
| 複雜度 / 效能指標 | ❌ 節點無此屬性 | ⭐ 跨程序 transitive_loop_depth 僅此一家 |
| 語意向量搜尋 | ❌ | ⭐ semantic_query 僅此一家 |
| co-change 耦合 | ❌ | ⭐ FILE_CHANGES_WITH 僅此一家 |
| Leiden 架構分群 | get_architecture | ⭐ + 社群偵測 |
兩者對 this.transport.isOpen() 這類介面型別方法呼叫都會把 callee 誤指到 mock / 同名前端實作 — 只是猜錯的對象不同。涉及介面多型的調用邊，任一工具的 callee 結果都需 grep 收尾複核。
不是「誰較好」，而是「這件事用哪個」。兩者互補。
caller 完整性全勝（5/5、2/2 對 3/5、1/2）。type-aware LSP 對巢狀函式與 singleton 實例方法的 CALLS 邊全中。
trace 回傳整條路徑並 inline 每跳原始碼，context / explore 一次取多符號源碼，搜尋直接帶型別簽章。讀碼體驗最佳。
Cypher、跨程序迴圈深度、語意搜尋、co-change 耦合 — codegraph 完全沒有對應能力，只能用它。