ghcr.io/abhigyanpatwari/gitnexus-web:1.6.6-rc.149

GitNexus

[!IMPORTANT]
GitNexus 没有官方加密货币、或硬币。任何在 Pump.fun 或其他平台上使用 GitNexus 名称的/硬币均与本项目或其维护者无关联、未获认可且非本项目创建。请勿购买任何声称与 GitNexus 相关的加密货币。

加入官方 *** 讨论想法、问题等！

企业版（SaaS 和自托管）- akonlabs.com

为智能体上下文构建神经系统。

将任何代码库索引到知识图谱中——包括每个依赖项、调用链、集群和执行流——然后通过智能工具将其公开，确保 AI 智能体不会遗漏代码。

类似 DeepWiki，但更深入。 DeepWiki 帮助你_理解_代码。GitNexus 让你_分析_代码——因为知识图谱跟踪每一种关系，而不仅仅是描述。

概要： Web UI 是与任何仓库快速交互的方式。CLI + MCP 则让你的 AI 智能体真正可靠——它为 Cursor、Claude Code、Antigravity、Codex 等工具提供代码库的深度架构视图，防止它们遗漏依赖项、破坏调用链和进行盲目编辑。即使是较小的模型也能获得完整的架构清晰度，使其能与大型模型竞争。

---

星标历史

使用 GitNexus 的两种方式

桥接模式： gitnexus serve 连接两者——Web UI 会自动检测本地服务器，无需重新上传或重新索引即可浏览所有通过 CLI 索引的仓库。

---

企业版

GitNexus 提供企业版——可作为完全托管的SaaS或自托管部署。开源版本也可通过适当授权用于商业用途。

企业版包含：

• PR 审查 - 自动分析拉取请求的影响范围
• 自动更新代码 Wiki - 始终保持最新的文档（代码 Wiki 也在开源版中提供）
• 自动重新索引 - 知识图谱自动保持最新
• 多仓库支持 - 跨仓库的统一图谱
• OCaml 支持 - 额外的语言覆盖
• 优先功能/语言支持 - 请求新语言或功能

即将推出：

• 自动回归取证
• 端到端测试生成

👉 了解更多：akonlabs.com

💬 商业授权或企业咨询，请通过 *** 联系我们，或发送邮件至 ***

---

开发

• ARCHITECTURE.md — 包结构、索引→图谱→MCP 流程、代码修改位置
• RUNBOOK.md — 分析、嵌入、索引过期处理、MCP 恢复、CI 代码片段
• GUARDRAILS.md — 贡献者和智能体的安全规则及操作“信号”
• CONTRIBUTING.md — 许可、设置、提交和拉取请求
• TESTING.md — gitnexus 和 gitnexus-web 的测试命令

CLI + MCP（推荐）

CLI 索引你的仓库并运行 MCP 服务器，为 AI 智能体提供深度代码库感知能力。

快速开始

# 索引你的仓库（从仓库根目录运行）
npx gitnexus analyze

就是这样。此命令会索引代码库、安装智能体技能、注册 Claude Code 钩子，并创建 AGENTS.md / CLAUDE.md 上下文文件——一步完成。

使用 npm 11.x？ npx 可能在安装时崩溃并显示 Cannot destructure property 'package' of 'node.target'（这是 npm/arborist 的 bug，发生在 GitNexus 运行前）。改用 pnpm，它会显式构建原生依赖：

> pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze
>

或全局安装（npm install -g gitnexus@latest）后运行 gitnexus analyze。详见 https://github.com/abhigyanpatwari/GitNexus/issues/1939%E3%80%82

要为编辑器配置 MCP，运行一次 npx gitnexus setup——或按以下步骤手动设置。

更快安装（无需 C++ 工具链）： 在 npm install -g gitnexus 前设置 GITNEXUS_SKIP_OPTIONAL_GRAMMARS=1，可跳过预编译语法的构建（tree-sitter-dart、tree-sitter-proto、tree-sitter-swift）。Dart/Proto/Swift 文件将无法解析，但安装可在几秒钟内完成，无需 python3/make/g++。仅严格支持 =1——其他值会触发重建。

MCP 设置

gitnexus setup 会自动检测你的编辑器并写入正确的全局 MCP 配置。只需运行一次。

编辑器支持

Claude Code 集成最深入：MCP 工具 + 智能体技能 + PreToolUse 钩子（通过图谱上下文丰富搜索）+ PostToolUse 钩子（提交后检测索引过期并提示智能体重索引）。

¹ Antigravity 钩子遵循 Gemini CLI 钩子参考（Antigravity 2.0 是 Gemini CLI 的官方继任者）。增强在 AfterTool 中运行，因为 Gemini 协议的 BeforeTool 没有上下文注入通道——智能体通过 hookSpecificOutput.additionalContext 查看附加到工具结果的图谱上下文。索引过期提示在 git commit/merge/rebase/cherry-pick/pull 成功后通过同一通道传递。如果 Antigravity 特定钩子文档与 Gemini CLI 出现差异，实现将跟踪这些变化。

社区集成

由社区构建——非官方维护，但值得一试。

有基于 GitNexus 构建的项目吗？提交 PR 在此处添加！

如果您倾向于手动配置：

[!IMPORTANT] 为实现最快启动：全局安装 gitnexus（npm i -g gitnexus）并运行 gitnexus setup——这会写入绝对路径的 MCP 配置，完全绕过 npx。下面的固定 npx 代码片段是快速启动的备选方案；在缓存未命中的情况下，npx 安装可能会超过 Claude Code 的默认 MCP_TIMEOUT（约 30 秒）。

Claude Code（完全支持 — MCP + 技能 + 钩子）：

# macOS / Linux
claude mcp add gitnexus -- npx -y gitnexus@latest mcp

# Windows
claude mcp add gitnexus -- cmd /c npx -y gitnexus@latest mcp

Codex（完全支持 — MCP + 技能）：

codex mcp add gitnexus -- npx -y gitnexus@latest mcp

Cursor（~/.cursor/mcp.json — 全局配置，适用于所有项目）：

{
"mcpServers": {
"gitnexus": {
"command": "npx",
"args": ["-y", "gitnexus@latest", "mcp"]
}
}
}

Antigravity (Google) — ~/.gemini/antigravity/mcp_config.json：

{
"mcpServers": {
"gitnexus": {
"command": "npx",
"args": ["-y", "gitnexus@latest", "mcp"]
}
}
}

gitnexus setup 还会将 AfterTool 条目合并到 ~/.gemini/settings.json（遵循标准 Gemini CLI 钩子 schema），并将技能安装到 ~/.gemini/antigravity/skills/。现有用户钩子会被保留。钩子适配器路径会在安装时重写，因此请运行 gitnexus setup 而非手动编辑。

OpenCode（~/.config/opencode/config.json）：

{
"mcp": {
"gitnexus": {
"type": "local",
"command": ["gitnexus", "mcp"]
}
}
}

Codex（系统范围：~/.codex/config.toml；项目范围：.codex/config.toml）：

[mcp_servers.gitnexus]
command = "npx"
args = ["-y", "gitnexus@latest", "mcp"]

CLI 命令

gitnexus setup # 配置编辑器的 MCP（一次性操作）
gitnexus analyze [path] # 索引仓库（或更新过期索引）
gitnexus analyze --repair-fts # 快速路径：仅在现有索引数据上重建/验证 FTS 索引
gitnexus analyze --force # 完全重建：重新解析 + 图重建 + FTS 重建
gitnexus analyze --skills # 从检测到的社区生成仓库特定的技能文件
gitnexus analyze --skip-embeddings # 跳过嵌入生成（更快）
gitnexus analyze --skip-agents-md # 保留自定义 AGENTS.md/CLAUDE.md 中 gitnexus 部分的编辑
gitnexus analyze --skip-skills # 跳过安装 .claude/skills/gitnexus/ 技能文件
gitnexus analyze --default-branch develop # 生成回归比较示例时使用的分支（base_ref）
gitnexus analyze --skip-git # 索引非 Git 仓库的文件夹
gitnexus analyze --embeddings [limit] # 启用嵌入生成（较慢，搜索效果更好）
gitnexus analyze --verbose # 当解析器不可用时记录跳过的文件
gitnexus analyze --worker-timeout 60 # 增加工作进程空闲超时以处理缓慢解析
gitnexus analyze --wal-checkpoint-threshold 67108864 # 64 MiB。控制 LadybugDB WAL 自动检查点阈值（默认：67108864 = 64 MiB；-1 保持 Ladybug 默认值 ~16 MiB）
gitnexus analyze --workers # 解析工作进程池大小（默认：核心数-1，上限 16；0 = 顺序执行）
gitnexus mcp # 启动 MCP 服务器（标准输入输出）——服务所有已索引仓库
gitnexus serve # 启动本地 HTTP 服务器（多仓库）以连接 Web UI
gitnexus list # 列出所有已索引仓库
gitnexus status # 显示当前仓库的索引状态
gitnexus clean # 删除当前仓库的索引
gitnexus clean --all --force # 删除所有索引
gitnexus wiki [path] # 从知识图谱生成仓库 Wiki
gitnexus wiki --model # 使用自定义 LLM 模型生成 Wiki（默认：gpt-4o-mini）
gitnexus wiki --base-url # 使用自定义 LLM API 基础 URL 生成 Wiki
gitnexus publish # 通知 understand-quickly 注册表（可选加入，见下文）

# 仓库组（多仓库/单体仓库服务跟踪）
gitnexus group create # 创建仓库组
gitnexus group add <group-path> <repo-name> # 将仓库添加到组。<group-path> 是层级路径（例如 hr/hiring/backend）；<repo-name> 是注册表中的仓库名称（见 `gitnexus list`）
gitnexus group remove <group-path> # 通过层级路径从组中移除仓库
gitnexus group list [name] # 列出所有组，或显示某个组的配置
gitnexus group sync # 提取契约并跨仓库/服务匹配
gitnexus group contracts # 检查提取的契约和交叉链接
gitnexus group query <pattern> # 搜索组内所有仓库的执行流
gitnexus group status # 检查组内仓库的过期状态

如果 analyze 在大型或特殊仓库上报告工作进程解析超时，它会继续运行并安全回退。要为缓慢的工作进程任务提供更多时间，请使用 gitnexus analyze --worker-timeout 60 或设置 GITNEXUS_WORKER_SUB_BATCH_TIMEOUT_MS=60000。对于非常大的文件，GITNEXUS_WORKER_SUB_BATCH_MAX_BYTES 控制工作进程任务的字节预算。

嵌入节点限制

gitnexus analyze --embeddings 生成语义搜索向量时，默认有 50,000 节点的安全上限，以保护大型仓库上的内存。当确认主机有足够内存处理更大图谱时，可覆盖此上限，或为一次性完整嵌入运行完全禁用上限。

# 使用默认 50,000 节点安全上限生成嵌入
gitnexus analyze --embeddings

# 完全禁用安全上限
gitnexus analyze --embeddings 0

# 使用自定义上限
gitnexus analyze --embeddings 100000

如果在大型仓库上跳过了嵌入，可能是索引图谱超过了默认安全上限。重新运行 gitnexus analyze --embeddings 0 可移除上限，或使用 gitnexus analyze --embeddings <number> 选择更高限制同时仍保持内存约束。

项目配置（.gitnexusrc）

在仓库根目录提交 .gitnexusrc JSON 文件，可为项目预配置重复的 analyze 选项，无需每次运行都重复传递相同标志。该文件从解析的仓库根目录读取（而非 .gitnexus/，后者是被 git 忽略的索引存储目录）。CLI 标志始终覆盖 .gitnexusrc。

{
// 生成回归比较示例时使用的默认分支（base_ref）。
// 用于确保使用 `develop`/`master` 分支的项目不会在每次分析时被重写为 "main" 分支
// （别名："branch"）
"defaultBranch": "develop",
"skipContextFiles": true, // skipAgentsMd 的别名：保留自定义 AGENTS.md/CLAUDE.md
"skipSkills": true, // 不安装 .claude/skills/gitnexus/
"embeddings": true, // 默认生成嵌入
"workerTimeout": 60
}

也接受嵌套的 analyze 块（并覆盖相同选项的扁平键）：

{ "analyze": { "defaultBranch": "develop", "skipSkills": true } }

[!NOTE]

• 默认分支的解析顺序为：--default-branch .gitnexusrc 中的 defaultBranch/branch 自动检测的 origin/HEAD main。
• skipContextFiles / skipAiContext 是 skipAgentsMd 的别名——它们仅跳过 AGENTS.md / CLAUDE.md 块。它们不会隐含 skipSkills。indexOnly 是更强的选项，会跳过所有文件注入。
• 支持的键：defaultBranch（branch）、skipAgentsMd（skipContextFiles、skipAiContext）、skipSkills、indexOnly、stats/noStats、embeddings、dropEmbeddings、name、allowDuplicateName、maxFileSize、workerTimeout、walCheckpointThreshold、workers、embeddingThreads、embeddingBatchSize、embeddingSubBatchSize、embeddingDevice。
• 该文件仅支持 JSON 格式。未知键和无效值会在分析开始前快速失败，并返回可操作的错误。

环境变量

大多数 analyze 控制项同时也是 CLI 标志（--workers、--worker-timeout、--max-file-size、--verbose）。当你需要在每次运行时重复使用相同的标志，或者从已管理自身环境的长期运行主机（MCP server、eval-server、CI shell）调用 GitNexus 时，使用环境变量形式。CLI 标志的优先级高于环境变量；环境变量的优先级高于内置默认值。

发布到 understand-quickly（可选）

多仓库MCP架构

GitNexus 使用全局注册表，因此一个 MCP 服务器可以为多个已索引仓库提供服务。无需每个项目单独配置 MCP——只需设置一次，即可在所有地方使用。

flowchart TD
subgraph CLI [CLI Commands]
Setup["gitnexus setup"]
Analyze["gitnexus analyze"]
Clean["gitnexus clean"]
List["gitnexus list"]
end

subgraph Registry ["~/.gitnexus/"]
RegFile["registry.json"]
end

subgraph Repos [Project Repos]
RepoA[".gitnexus/ in repo A"]
RepoB[".gitnexus/ in repo B"]
end

subgraph MCP [MCP Server]
Server["server.ts"]
Backend["LocalBackend"]
Pool["Connection Pool"]
ConnA["LadybugDB conn A"]
ConnB["LadybugDB conn B"]
end

Setup -->|"writes global MCP config"| CursorConfig["~/.cursor/mcp.json"]
Analyze -->|"registers repo"| RegFile
Analyze -->|"stores index"| RepoA
Clean -->|"unregisters repo"| RegFile
List -->|"reads"| RegFile
Server -->|"reads registry"| RegFile
Server --> Backend
Backend --> Pool
Pool -->|"lazy open"| ConnA
Pool -->|"lazy open"| ConnB
ConnA -->|"queries"| RepoA
ConnB -->|"queries"| RepoB

工作原理： 每次执行 gitnexus analyze 时，索引会存储在仓库内的 .gitnexus/ 目录中（可移植，已加入 gitignore），并在 ~/.gitnexus/registry.json 中注册一个指针。当 AI 代理启动时，MCP 服务器会读取注册表，并可为任何已索引的仓库提供服务。LadybugDB 连接在首次查询时延迟打开，闲置 5 分钟后关闭（最大并发数为 5）。如果仅索引了一个仓库，则所有工具的 repo 参数都是可选的——代理无需进行任何更改。

版本控制与供应链保护

Docker 镜像与 npm 包版本锁定：

• 稳定版镜像仅从 vX.Y.Z git 标签发布（通过标签推送直接触发 docker.yml 工作流），且工作流会拒绝构建，除非标签与 gitnexus/package.json 中的版本完全匹配。因此，ghcr.io/abhigyanpatwari/gitnexus:1.6.2（及其 Docker Hub 镜像 akonlabs/gitnexus:1.6.2）与 npm install gitnexus@1.6.2 的发布版本完全一致——无版本偏移，无来自 main 分支的浮动构建。两个 registry 均从同一构建步骤获得相同的摘要，因此你可以从任一 registry 拉取镜像，签名验证结果完全一致。
• 候选发布版镜像（例如 :1.7.0-rc.1）与每个 RC 版本的 npm 发布一同发布。它们由 publish.yml 在 RC 标签创建并推送后，调用 docker.yml 作为可重用工作流构建。
• :latest 标签仅由 Docker 元数据操作从非预发布标签自动提升，因此它始终指向真实的、已发布到 npm 的版本。

两个镜像均使用工作流的 GitHub OIDC 身份通过 Cosign 无密钥签名 进行签名，并附带构建来源和 SBOM 证明。这是你抵御供应链的保护措施**：即使**者在其他地方重新发布同名镜像（或通过某种方式推送到拼写相似的 registry），他们也无法伪造与 abhigyanpatwari/GitNexus 的 docker.yml 绑定的 Cosign 签名。在拉取到敏感环境前务必进行验证：

稳定版发布 — 从 v* 标签引用签名：

cosign verify ghcr.io/abhigyanpatwari/gitnexus:1.6.2 \
--certificate-identity-regexp '^https://github\.com/abhigyanpatwari/GitNexus/\.github/workflows/docker\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?

该正则表达式将证书身份固定到本仓库中**从 `v*` 标签运行**的 `docker.yml` 工作流——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个 registry 的正则表达式相同，因为两组标签在同一工作流运行中以相同摘要进行了签名。

**候选发布版** — 从 `refs/heads/main` 签名（当 `publish.yml` 将 `docker.yml` 作为可重用工作流调用时的调用者引用）：
```bash
cosign verify ghcr.io/abhigyanpatwari/gitnexus:1.7.0-rc.1 \
--certificate-identity 'https://github.com/abhigyanpatwari/GitNexus/.github/workflows/docker.yml@refs/heads/main' \
--certificate-oidc-issuer [***]

你还可以检查构建来源和 SBOM：

cosign download attestation ghcr.io/abhigyanpatwari/gitnexus:1.6.2 \
--predicate-type [***]

Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 ClusterImagePolicy，以便 Sigstore policy-controller 拒绝任何 GitNexus Pod，其镜像未由本仓库中从 vX.Y.Z 标签运行的 docker.yml 签名——与上述 cosign verify 代码片段固定的身份相同。

# 1. 安装控制器（一次性，集群范围）
helm repo add sigstore https://sigstore.github.io/helm-charts && helm repo update
helm install policy-controller -n cosign-system --create-namespace \
sigstore/policy-controller

# 2. 启用命名空间
kubectl label namespace policy.sigstore.dev/include=true

# 3. 应用策略
kubectl apply -f deploy/kubernetes/cluster-image-policy.yaml

完成后，尝试部署未签名镜像——或由 abhigyanpatwari/GitNexus 的 docker.yml 以外的任何东西在 v* 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这将可验证的签名转化为强制策略，这是大多数集群实际需要的供应链控制。

文件

• Dockerfile.web — 构建 gitnexus-shared 和 gitnexus-web，然后提供生产环境前端服务。
• Dockerfile.cli — 构建 CLI/服务器（包含其原生依赖）并运行 gitnexus serve --host 0.0.0.0。
• docker-compose.yaml — 并排启动两个已签名镜像。
• .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它非常适合快速探索，但对于较大的仓库，受浏览器内存限制。

本地后端模式：运行 gitnexus serve 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

GitNexus 解决的问题

诸如 Cursor、Claude Code、Codex、Cline、Roo Code 和 Windsurf 等工具功能强大，但它们并不真正了解你的代码库结构。

实际情况：

1. AI 编辑 UserService.validate()
2. 不知道有 47 个函数依赖于其返回类型
3. 破坏性变更被发布

传统 Graph RAG 与 GitNexus 的对比

传统方法向 LLM 提供原始图边缘，并希望它能充分探索。GitNexus 在索引时预计算结构——聚类、追踪、评分——因此工具可通过一次调用返回完整上下文：

flowchart TB
subgraph Traditional["传统 Graph RAG"]
direction TB
U1["用户：哪些依赖 UserService？"]
U1 --> LLM1["LLM 接收原始图"]
LLM1 --> Q1["查询 1：查找调用方"]
Q1 --> Q2["查询 2：哪些文件？"]
Q2 --> Q3["查询 3：过滤测试？"]
Q3 --> Q4["查询 4：高风险？"]
Q4 --> OUT1["4+ 次查询后返回答案"]
end

subgraph GN["GitNexus 智能工具"]
direction TB
U2["用户：哪些依赖 UserService？"]
U2 --> TOOL["impact UserService upstream"]
TOOL --> PRECOMP["预结构化响应：
8 个调用方，3 个集群，置信度均 90%+"]
PRECOMP --> OUT2["完整答案，1 次查询"]
end

核心创新：预计算关系智能

• 可靠性——LLM 不会遗漏上下文，因为上下文已包含在工具响应中
• 令牌效率——无需 10 次查询链即可理解单个函数
• 模型民主化——小型 LLM 也能正常工作，因为工具承担了繁重的计算任务

---

工作原理

GitNexus 通过多阶段索引管道为你的代码库构建完整的知识图谱：

1. 结构解析——遍历文件树并映射文件夹/文件关系
2. 解析——使用 Tree-sitter AST 提取函数、类、方法和接口
3. 解析处理——使用语言感知逻辑解析跨文件的导入、函数调用、继承关系、构造函数推断以及 self/this 接收者类型
4. 聚类——将相关符号分组为功能社区
5. 流程追踪——从入口点通过调用链追踪执行流
6. 搜索——构建混合搜索索引以实现快速检索

支持的语言

导入——跨文件导入解析 · 命名绑定——import { X as Y } / 重导出跟踪 · 导出——公共/导出符号检测 · 继承关系——类继承、接口、混合类型 · 类型注解——用于接收者解析的显式类型提取 · 构造函数推断——从构造函数调用推断接收者类型（所有语言均包含 self/this 解析） · 配置——语言工具链配置解析（tsconfig、go.mod 等） · 框架——基于 AST 的框架模式检测 · 入口点——入口点评分启发式

---

工具示例

影响分析

impact({target: "UserService", direction: "upstream", minConfidence: 0.8})

TARGET: Class UserService (src/services/user.ts)

UPSTREAM (依赖此目标的内容)：
Depth 1 (将中断)：
handleLogin [调用 90%] -> src/api/auth.ts:45
handleRegister [调用 90%] -> src/api/auth.ts:78
UserController [调用 85%] -> src/controllers/user.ts:12
Depth 2 (可能受影响)：
authRouter [导入] -> src/routes/auth.ts

选项：maxDepth、minConfidence、relationTypes（CALLS、IMPORTS、EXTENDS、IMPLEMENTS）、includeTests、limit（每深度最大符号数，默认 100）、offset（每深度分页起始位置）、summaryOnly（仅返回计数和风险，省略符号列表）

歧义消除——当多个符号共享目标名称时，impact 会返回排序的 ambiguous 候选列表而非猜测。可通过 target_uid（精确，零歧义）、file_path 或 kind（Function、Class、Method 等）缩小范围。在 CLI 中，这些参数为 --uid、--file 和 --kind，与 gitnexus context 匹配：

gitnexus impact get_embeddings # → ambiguous: 列出排序后的候选
gitnexus impact get_embeddings --file src/embed.py # → 解析为该文件中的符号
gitnexus impact get_embeddings --uid "Function:src/embed.py:get_embeddings" # 精确匹配

流程分组搜索

query({query: "authentication middleware"})

processes:
- summary: "LoginFlow"
priority: 0.042
symbol_count: 4
process_type: cross_community
step_count: 7

process_symbols:
- name: validateUser
type: Function
filePath: src/auth/validate.ts
process_id: proc_login
step_index: 2

definitions:
- name: AuthConfig
type: Interface
filePath: src/types/auth.ts

上下文（360 度符号视图）

context({name: "validateUser"})

symbol:
uid: "Function:validateUser"
kind: Function
filePath: src/auth/validate.ts
startLine: 15

incoming:
calls: [handleLogin, handleRegister, UserController]
imports: [authRouter]

outgoing:
calls: [checkPassword, createSession]

processes:
- name: LoginFlow (步骤 2/7)
- name: RegistrationFlow (步骤 3/5)

检测变更（提交前）

detect_changes({scope: "all"})

summary:
changed_count: 12
affected_count: 3
changed_files: 4
risk_level: medium

changed_symbols: [validateUser, AuthService, ...]
affected_processes: [LoginFlow, RegistrationFlow, ...]

重命名（多文件）

rename({symbol_name: "validateUser", new_name: "verifyUser", dry_run: true})

status: success
files_affected: 5
total_edits: 8
graph_edits: 6 (高置信度)
text_search_edits: 2 (需仔细审查)
changes: [...]

Cypher 查询

-- 查找高置信度调用认证函数的内容
MATCH (c:Community {heuristicLabel: 'Authentication'}) (fn)
WHERE r.confidence
> 0.8
RETURN caller.name, fn.name, r.confidence
ORDER BY r.confidence DESC

---

Wiki 生成

从知识图谱生成由 LLM 驱动的文档：

# 需要 LLM API 密钥（OPENAI_API_KEY 等）
gitnexus wiki

# 使用自定义模型或提供商
gitnexus wiki --model gpt-4o
gitnexus wiki --base-url [***]

# 强制完全重新生成
gitnexus wiki --force

--certificate-oidc-issuer https://token.actions.githubusercontent.com

相同签名可验证 Docker Hub 镜像（摘要相同）：

cosign verify docker.io/akonlabs/gitnexus:1.6.2
--certificate-identity-regexp '^https://github\.com/abhigyanpatwari/GitNexus/\.github/workflows/docker\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?

该正则表达式将证书身份固定到本仓库中从 CODE_TOKEN_194 标签运行的 CODE_TOKEN_195 工作流——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个 registry 的正则表达式相同，因为两组标签在同一工作流运行中以相同摘要进行了签名。

候选发布版 — 从 CODE_TOKEN_196 签名（当 CODE_TOKEN_197 将 CODE_TOKEN_198 作为可重用工作流调用时的调用者引用）：

CODE_TOKEN_14

你还可以检查构建来源和 SBOM：

CODE_TOKEN_15

Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 CODE_TOKEN_199，以便 Sigstore policy-controller 拒绝任何 GitNexus Pod，其镜像未由本仓库中从 CODE_TOKEN_200 标签运行的 CODE_TOKEN_201 签名——与上述 CODE_TOKEN_202 代码片段固定的身份相同。

CODE_TOKEN_16

完成后，尝试部署未签名镜像——或由 CODE_TOKEN_203 的 CODE_TOKEN_204 以外的任何东西在 CODE_TOKEN_205 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这将可验证的签名转化为强制策略，这是大多数集群实际需要的供应链控制。

文件

• Dockerfile.web — 构建 CODE_TOKEN_206 和 CODE_TOKEN_207，然后提供生产环境前端服务。
• Dockerfile.cli — 构建 CLI/服务器（包含其原生依赖）并运行 CODE_TOKEN_208。
• docker-compose.yaml — 并排启动两个已签名镜像。
• .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它非常适合快速探索，但对于较大的仓库，受浏览器内存限制。

本地后端模式：运行 CODE_TOKEN_209 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

GitNexus 解决的问题

诸如 Cursor、Claude Code、Codex、Cline、Roo Code 和 Windsurf 等工具功能强大，但它们并不真正了解你的代码库结构。

实际情况：

1. AI 编辑 CODE_TOKEN_210
2. 不知道有 47 个函数依赖于其返回类型
3. 破坏性变更被发布

传统 Graph RAG 与 GitNexus 的对比

传统方法向 LLM 提供原始图边缘，并希望它能充分探索。GitNexus 在索引时预计算结构——聚类、追踪、评分——因此工具可通过一次调用返回完整上下文：

CODE_TOKEN_17

核心创新：预计算关系智能

• 可靠性——LLM 不会遗漏上下文，因为上下文已包含在工具响应中
• 令牌效率——无需 10 次查询链即可理解单个函数
• 模型民主化——小型 LLM 也能正常工作，因为工具承担了繁重的计算任务

---

工作原理

GitNexus 通过多阶段索引管道为你的代码库构建完整的知识图谱：

1. 结构解析——遍历文件树并映射文件夹/文件关系
2. 解析——使用 Tree-sitter AST 提取函数、类、方法和接口
3. 解析处理——使用语言感知逻辑解析跨文件的导入、函数调用、继承关系、构造函数推断以及 CODE_TOKEN_211/CODE_TOKEN_212 接收者类型
4. 聚类——将相关符号分组为功能社区
5. 流程追踪——从入口点通过调用链追踪执行流
6. 搜索——构建混合搜索索引以实现快速检索

支持的语言

导入——跨文件导入解析 · 命名绑定——CODE_TOKEN_213 / 重导出跟踪 · 导出——公共/导出符号检测 · 继承关系——类继承、接口、混合类型 · 类型注解——用于接收者解析的显式类型提取 · 构造函数推断——从构造函数调用推断接收者类型（所有语言均包含 CODE_TOKEN_214/CODE_TOKEN_215 解析） · 配置——语言工具链配置解析（tsconfig、go.mod 等） · 框架——基于 AST 的框架模式检测 · 入口点——入口点评分启发式

---

工具示例

影响分析

CODE_TOKEN_18

选项：CODE_TOKEN_216、CODE_TOKEN_217、CODE_TOKEN_218（CODE_TOKEN_219、CODE_TOKEN_220、CODE_TOKEN_221、CODE_TOKEN_222）、CODE_TOKEN_223、CODE_TOKEN_224（每深度最大符号数，默认 100）、CODE_TOKEN_225（每深度分页起始位置）、CODE_TOKEN_226（仅返回计数和风险，省略符号列表）

歧义消除——当多个符号共享目标名称时，CODE_TOKEN_227 会返回排序的 CODE_TOKEN_228 候选列表而非猜测。可通过 CODE_TOKEN_229（精确，零歧义）、CODE_TOKEN_230 或 CODE_TOKEN_231（CODE_TOKEN_232、CODE_TOKEN_233、CODE_TOKEN_234 等）缩小范围。在 CLI 中，这些参数为 CODE_TOKEN_235、CODE_TOKEN_236 和 CODE_TOKEN_237，与 CODE_TOKEN_238 匹配：

CODE_TOKEN_19

流程分组搜索

CODE_TOKEN_20

上下文（360 度符号视图）

CODE_TOKEN_21

检测变更（提交前）

CODE_TOKEN_22

重命名（多文件）

CODE_TOKEN_23

Cypher 查询

CODE_TOKEN_24

---

Wiki 生成

从知识图谱生成由 LLM 驱动的文档：

CODE_TOKEN_25
--certificate-oidc-issuer https://token.actions.githubusercontent.com

该正则表达式将证书身份固定到本仓库中**从 __CODE_TOKEN_194__ 标签运行**的 __CODE_TOKEN_195__ 工作流——拒绝未签名镜像、由其他工作流签名的镜像以及从未受保护引用签名的镜像。两个 registry 的正则表达式相同，因为两组标签在同一工作流运行中以相同摘要进行了签名。

**候选发布版** — 从 __CODE_TOKEN_196__ 签名（当 __CODE_TOKEN_197__ 将 __CODE_TOKEN_198__ 作为可重用工作流调用时的调用者引用）：

__CODE_TOKEN_14__

你还可以检查构建来源和 SBOM：

__CODE_TOKEN_15__

#### Kubernetes：在准入阶段强制签名验证

对于 Kubernetes 部署，部署捆绑的 __CODE_TOKEN_199__，以便 [Sigstore policy-controller][policy-controller] 拒绝任何 GitNexus Pod，其镜像未由本仓库中从 __CODE_TOKEN_200__ 标签运行的 __CODE_TOKEN_201__ 签名——与上述 __CODE_TOKEN_202__ 代码片段固定的身份相同。

__CODE_TOKEN_16__

完成后，尝试部署未签名镜像——或由 __CODE_TOKEN_203__ 的 __CODE_TOKEN_204__ 以外的任何东西在 __CODE_TOKEN_205__ 标签签名的镜像——将在 Pod 创建前被准入 Webhook 拒绝。这将可验证的签名转化为强制策略，这是大多数集群实际需要的供应链控制。

[cosign-keyless]: [***]
[policy-controller]: [***]

### 文件

- Dockerfile.web — 构建 __CODE_TOKEN_206__ 和 __CODE_TOKEN_207__，然后提供生产环境前端服务。
- Dockerfile.cli — 构建 CLI/服务器（包含其原生依赖）并运行 __CODE_TOKEN_208__。
- docker-compose.yaml — 并排启动两个已签名镜像。
- .env.example — 用于覆盖镜像名称、容器名称、端口和工作区挂载的配置。

Web UI 使用与 CLI 相同的索引管道，但完全在 WebAssembly 中运行（Tree-sitter WASM、LadybugDB WASM、浏览器内嵌入）。它非常适合快速探索，但对于较大的仓库，受浏览器内存限制。

**本地后端模式**：运行 __CODE_TOKEN_209__ 并在本地打开 Web UI——它会自动检测服务器并显示所有已索引的仓库，支持完整的 AI 聊天。无需重新上传或重新索引。智能体工具（Cypher 查询、搜索、代码导航）会自动通过后端 HTTP API 路由。

---

## GitNexus 解决的问题

诸如 **Cursor**、**Claude Code**、**Codex**、**Cline**、**Roo Code** 和 **Windsurf** 等工具功能强大，但它们并不真正了解你的代码库结构。

**实际情况：**

1. AI 编辑 __CODE_TOKEN_210__
2. 不知道有 47 个函数依赖于其返回类型
3. **破坏性变更被发布**

### 传统 Graph RAG 与 GitNexus 的对比

传统方法向 LLM 提供原始图边缘，并希望它能充分探索。GitNexus **在索引时预计算结构**——聚类、追踪、评分——因此工具可通过一次调用返回完整上下文：

__CODE_TOKEN_17__

**核心创新：预计算关系智能**

- **可靠性**——LLM 不会遗漏上下文，因为上下文已包含在工具响应中
- **令牌效率**——无需 10 次查询链即可理解单个函数
- **模型民主化**——小型 LLM 也能正常工作，因为工具承担了繁重的计算任务

---

## 工作原理

GitNexus 通过多阶段索引管道为你的代码库构建完整的知识图谱：

1. **结构解析**——遍历文件树并映射文件夹/文件关系
2. **解析**——使用 Tree-sitter AST 提取函数、类、方法和接口
3. **解析处理**——使用语言感知逻辑解析跨文件的导入、函数调用、继承关系、构造函数推断以及 __CODE_TOKEN_211__/__CODE_TOKEN_212__ 接收者类型
4. **聚类**——将相关符号分组为功能社区
5. **流程追踪**——从入口点通过调用链追踪执行流
6. **搜索**——构建混合搜索索引以实现快速检索

### 支持的语言

| 语言       | 导入 | 命名绑定 | 导出 | 继承关系 | 类型注解 | 构造函数推断 | 配置 | 框架 | 入口点 |
|------------|------|----------|------|----------|----------|--------------|------|------|--------|
| TypeScript | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | ✓    | ✓    | ✓      |
| JavaScript | ✓    | ✓        | ✓    | ✓        | —        | ✓            | ✓    | ✓    | ✓      |
| Python     | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | ✓    | ✓    | ✓      |
| Java       | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | —    | ✓    | ✓      |
| Kotlin     | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | —    | ✓    | ✓      |
| C#         | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | ✓    | ✓    | ✓      |
| Go         | ✓    | —        | ✓    | ✓        | ✓        | ✓            | ✓    | ✓    | ✓      |
| Rust       | ✓    | ✓        | ✓    | ✓        | ✓        | ✓            | —    | ✓    | ✓      |
| PHP        | ✓    | ✓        | ✓    | —        | ✓        | ✓            | ✓    | ✓    | ✓      |
| Ruby       | ✓    | —        | ✓    | ✓        | —        | ✓            | —    | ✓    | ✓      |
| Swift      | —    | —        | ✓    | ✓        | ✓        | ✓            | ✓    | ✓    | ✓      |
| C          | —    | —        | ✓    | —        | ✓        | ✓            | —    | ✓    | ✓      |
| C++        | —    | —        | ✓    | ✓        | ✓        | ✓            | —    | ✓    | ✓      |
| Dart       | ✓    | —        | ✓    | ✓        | ✓        | ✓            | —    | ✓    | ✓      |

**导入**——跨文件导入解析 · **命名绑定**——__CODE_TOKEN_213__ / 重导出跟踪 · **导出**——公共/导出符号检测 · **继承关系**——类继承、接口、混合类型 · **类型注解**——用于接收者解析的显式类型提取 · **构造函数推断**——从构造函数调用推断接收者类型（所有语言均包含 __CODE_TOKEN_214__/__CODE_TOKEN_215__ 解析） · **配置**——语言工具链配置解析（tsconfig、go.mod 等） · **框架**——基于 AST 的框架模式检测 · **入口点**——入口点评分启发式

---

## 工具示例

### 影响分析

__CODE_TOKEN_18__

选项：__CODE_TOKEN_216__、__CODE_TOKEN_217__、__CODE_TOKEN_218__（__CODE_TOKEN_219__、__CODE_TOKEN_220__、__CODE_TOKEN_221__、__CODE_TOKEN_222__）、__CODE_TOKEN_223__、__CODE_TOKEN_224__（每深度最大符号数，默认 100）、__CODE_TOKEN_225__（每深度分页起始位置）、__CODE_TOKEN_226__（仅返回计数和风险，省略符号列表）

**歧义消除**——当多个符号共享目标名称时，__CODE_TOKEN_227__ 会返回排序的 __CODE_TOKEN_228__ 候选列表而非猜测。可通过 __CODE_TOKEN_229__（精确，零歧义）、__CODE_TOKEN_230__ 或 __CODE_TOKEN_231__（__CODE_TOKEN_232__、__CODE_TOKEN_233__、__CODE_TOKEN_234__ 等）缩小范围。在 CLI 中，这些参数为 __CODE_TOKEN_235__、__CODE_TOKEN_236__ 和 __CODE_TOKEN_237__，与 __CODE_TOKEN_238__ 匹配：

__CODE_TOKEN_19__

### 流程分组搜索

__CODE_TOKEN_20__

### 上下文（360 度符号视图）

__CODE_TOKEN_21__

### 检测变更（提交前）

__CODE_TOKEN_22__

### 重命名（多文件）

__CODE_TOKEN_23__

### Cypher 查询

__CODE_TOKEN_24__

---

## Wiki 生成

从知识图谱生成由 LLM 驱动的文档：

__CODE_TOKEN_25__