圖資料模型

13 種節點 label、23 種邊型、qualified name

節點 Label

Project · Package · Folder · File · Module · Class · Function · Method · Interface · Enum · Type · Route · Resource
Label意義
Project一個被索引的 repo(含 repo_path、generation)
Package / Module套件/模組(套件解析自 package.json / go.mod / Cargo.toml…)
Folder / File目錄與檔案
Class / Interface / Enum / Type型別定義
Function / Method可呼叫物
RouteREST 端點(HTTP method + path)
ResourceIaC 資源(K8s kinds 等)

邊型

意義
CONTAINS_PACKAGE/FOLDER/FILE容器關係
DEFINES / DEFINES_METHOD定義關係
IMPORTS匯入
CALLS呼叫(型別解析後的呼叫邊)
CALL_REFERENCE可呼叫值在支援的 reference site 使用、解析到單一目標
USAGE識別字被用,但無法證明唯一目標(含歧義/複雜運算式)
HTTP_CALLS / ASYNC_CALLS跨服務呼叫
IMPLEMENTS / INHERITS實作/繼承
HANDLESRoute → handler 的對應
EMITS / LISTENS_ONchannel(Socket.IO、EventEmitter、pub-sub)
DATA_FLOWS資料流(arg-to-param 對應 + field access chain)
SIMILAR_TOMinHash + LSH 近複製(Jaccard 計分)
SEMANTICALLY_RELATED詞彙不匹配、同語言、score ≥ 0.80 的語意關係
CONFIGURES / WRITES / MEMBER_OF / TESTS / USES_TYPE / FILE_CHANGES_WITH其餘語意邊
為什麼要分 CALLS / CALL_REFERENCE / USAGE:這三種「看起來都是呼叫」的邊,代表不同程度的解析確定性。型別解析成功且唯一 → CALLS;可呼叫值引用但只是當參數傳遞 → CALL_REFERENCE;無法證明唯一目標 → USAGE。這是 CBM 比單純 grep 強的地方——它不硬猜。

Qualified Name

get_code_snippet 用 qualified name 定位:

<project>.<path_parts>.<name>

例如: myproj.src.services.order.process_order

先用 search_graph 發現確切名稱,再餵給 get_code_snippet

查詢範例

資料模型 + Cypher 的威力(Cypher 全解):

// 死碼偵測:沒有被任何 CALLS 指向的函式
MATCH (f:Function)
WHERE NOT EXISTS { (f)<-[:CALLS]-() }
RETURN f.name

// main 呼叫了誰
MATCH (f:Function)-[:CALLS]->(g)
WHERE f.name = 'main'
RETURN g.name

跨 repo

多個 repo index 進同一個 store 時,會產生 CROSS_* 邊連結跨 repo 節點,3D UI 用 multi-galaxy 佈局呈現跨 repo 架構。詳見 Multi-Agentget_architecture

看完這頁你應該能說出:CALLS / CALL_REFERENCE / USAGE 的差異、Route 與 Resource 節點各代表什麼、qualified name 的格式、以及如何用 Cypher 的 NOT EXISTS 找死碼。