GitNexus 端到端工程流水线gitnexus-lfg 的 plan → gate → work → review 四段式编排实战【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexusgitnexus-lfg 是 GitNexus 仓库中一个刻意保持薄的编排技能它本身不携带任何工程逻辑只负责把gitnexus-plan、gitnexus-work、gitnexus-review三个技能按固定顺序串成一条端到端流水线并在规划与执行之间设置唯一一个阻塞式闸门。读完本文你将掌握如何用/gitnexus-lfg一次性驱动计划生成 → 用户确认 → 原子提交执行 → 图驱动评审的完整闭环理解 35 轮边界planning boundary的由来与治理方式并能针对 headless 场景、结构漂移、评审返工等分支做出正确路由。定位一个不加工程逻辑的编排器gitnexus-lfg的 SKILL.mdSKILL.md开头就写明了自身定位thin orchestrator over three existing skills。它不新增任何工程判断只做三件事——排序、转发、设置闸门/gitnexus-lfg task description /gitnexus-lfg docs/plans/existing-plan.md # 跳过 lane 1直接从闸门开始核心纪律只有一条每个 lane 都必须真正调用对应的技能读取其 SKILL.md 并照做绝不允许用技能会做什么的摘要来代替真实调用。这样做的直接后果是——编排层保持零逻辑重复所有深度plan 的 13 节结构、work 的原子提交纪律、review 的评审标准都下沉到被编排的三个技能里由它们各自的 SKILL.md 和references/目录负责。在 GitNexus 仓库中技能以多份拷贝存在gitnexus/skills/是规范源gitnexus-claude-plugin/skills/、gitnexus-cursor-integration/skills/等是派生的插件镜像另有一份gitnexus-lfg出现在 gitnexus-claude-plugin/skills/gitnexus-lfg/ 下。编排时优先读取仓库内的规范源Claude Code 插件的 SKILL.md 与规范源内容一致。Lane 1 — 规划边界分诊优先第一个 lane 由gitnexus-plan负责但在真正规划之前编排器必须先做一次边界分诊boundary triage如果任务明显低于规划边界——即平凡或小范围工作Agent 用远少于约35 轮turns即可完成——编排器应当直接说明这一点并主动提供gitnexus-work直接模式direct mode作为整条流水线的替代方案然后尊重用户的选择否则才调用gitnexus-plan执行正式规划。这个 ~35 轮阈值不是拍脑袋的经验值而是一条经过离线基准验证后提升promoted的 benchmark 策略测量证据就记录在仓库的 eval/workflow_bench/README.md 中历史基准数据显示基线 Agent 能在 ≤35 轮内完成的任务完整 plan→work 流水线的固定成本新鲜度门禁含 analyzer 重建与重索引、完整的 13 节计划、work 阶段的再锚定约为每任务 $9–11在这种任务规模下无法摊薄回报而workflow_direct执行纪律但不做规划与基线成本差只有 −15% 到 −55%。因此该 README 给出的路由结论与 lfg 的边界分诊完全一致小任务走直接模式或纯 Agent完整流水线留给跨模块工作、多会话执行、或计划文档本身即为交付物的场景。关键约束阈值是一条被提升的基准策略不是永恒不变的启发式Agent 绝不能在一次实时任务中自行修改它。它的再评估治理权属于本技能的 READMEREADME.md § Threshold governance——每当命名模型或工具 harness 变更时离线重跑配对基准且至少每 90 天一次只有当确定性提升门deterministic promotion gate确认无质量回退后才允许更新 SKILL.md 中的阈值。这也与 workflow_bench 的prompt and skill evolution loop候选技能必须以配对基准击败当前技能后才能被人类合入互为表里。调用的细节与深度问题的归属确定需要规划后编排器用任务文本调用gitnexus-planknob 覆盖参数原样透传。例如用户写出/gitnexus-plan impact_depth:3 depth:deep task description其中depth、form、impact_depth、pdg_data_depth、freshness等配置旋钮的完整默认值表由gitnexus-plan的 SKILL.md § Configuration 定义如impact_depth默认 2、max_primary_symbols默认 5、max_snippet_lines默认 30。lfg 的规则很明确规划深度问得多深这个问题只能由gitnexus-plan在最开始问一次——gitnexus-plan在交互式会话且调用未携带任何显式深度信号时会以阻塞式问题给出 Quick / Standard / Deep 三档选择并把它换算成等价的 knob 值。编排层绝不重复询问。如果输入已经是一个计划文件路径docs/plans/existing-plan.md则直接跳过 Lane 1从 Lane 2 闸门开始。计划产出落在docs/plans/目录路径必须被记录下来因为后续每个 lane 都以它为输入。计划文档的形态gitnexus-plan产出的计划是docs/plans/YYYY-MM-DD-gitnexus-plan-3-5-word-slug.md一份 13 节的实现就绪计划其中第 11 节是机器可读的implementation context pack——包含acceptance_criteria、evidence_provenance、primary_symbols、files_to_modify、pdg_constraints、tests、verification_commands、avoid等字段让后续执行 Agent 无需重新调研仓库即可开工。计划的写入与读取都只能通过字节一致的辅助脚本 scripts/evidence-provenance.mjs 完成write-plan/read-plan其read-planreceipt 以描述符锚定规范路径、精确 base64 字节与 SHA-256 摘要evidence_provenance字段携带全局脏树摘要global dirty digest与按层排序的被引用路径清单把工作区证据与 HEAD 一起钉死。Lane 2 — 计划闸门流水线唯一的人工检查点这是整条流水线的唯一阻塞式检查点blocking gate目的很明确执行是昂贵且难以回滚的所以必须在投入执行前让用户做一次明确选择。编排器先向用户呈现计划摘要目标objective、拟议变更proposed changes、实施顺序sequence、顶级风险top risks、未决问题open questions以及计划文件路径。然后以阻塞式问题询问Proceed to work— 继续到 Lane 3Stop here— 计划文件即为交付物流水线到此结束。在 Claude Code 中使用AskUserQuestion工具在不支持阻塞式工具的 CLI 上使用聊天中的编号列表。两条重要规则加深deepen不是默认选项——深度在 Lane 1 已由用户在前置决定因此默认不再提供加深但如果用户在闸门处显式要求加深则执行gitnexus-plan的 Deepen 模式/gitnexus-plan deepen docs/plans/plan.md用加强后的计划回到闸门用户要求多少次就做多少次。Deepen 模式会先通过read-plan精确解码plan_bytes_base64重跑 Phase 1 新鲜度门禁把计划从 §11 pack 播种进台账再通过write-plan --replace --expected-plan-path --expected-plan-digest重写同一规范文件任何摘要/路径不匹配都会阻止发布。没有显式选择就绝不放行——闸门存在的意义正是因为它不可跳过。Headless / 非交互运行的规则无人能回答闸门问题时流水线在 Lane 1 之后直接结束——计划文件是交付物即闸门选项 2并在最终报告中明确说明这一点。绝不自动放行到执行阶段。这与 workflow_bench 的 bare / headless 运行模式dontAsk、无交互设计一致基准环境本身就是非交互的因此它在编排上天然落到计划即交付物这一档。Lane 3 — 执行以验证过的原子提交落地获得用户放行后编排器用计划路径调用gitnexus-work。执行技能负责四件事在 HEAD 处重新锚定计划——通过read-plan加载计划的精确字节即使当前 HEAD 与计划 pin 相同也要重算全局脏树摘要与排序的被引用路径清单两层漂移检查任何已变更的引用路径先重读再依赖按实施顺序Implementation Sequence执行计划 §7——每条目都遵循编辑前impact查询 → 最小实现 → 按计划场景补测试 → 提交前detect_changes {scope: staged}门禁 → 单条 conventional commit的固定纪律HIGH/CRITICAL 风险在动手前向用户暴露爆炸半径完成后刷新知识图谱Phase 4——跑完整验证套件、逐条核对 §13 Definition of Done 与acceptance_criteria最后再执行一次 Build-current/index-current 过程对已证明为最新的索引跑detect_changes {scope: all}报告偏差——完成的步骤、产生的提交、与计划的偏差及原因、未满足的假设、DoD 状态、最终索引的 commit 与 runner identity。执行中的关键基础设施是gitnexus-work独有的Build-current/index-current 过程SKILL.md § Phase 2每次图相关的impact查询前比对index.commit与当前 HEAD、要求 schema-4 的 runner identity含gitnexus-analyzer-dependency-runtime-v4依赖载荷摘要为 current、incomplete_reasons为空分析器源码有变动时先cd gitnexus npm run build再用node gitnexus/dist/cli/index.js analyze --index-only --pdg重建本地索引。任何构建/刷新/身份校验失败都会阻塞图相关的影响分析与最终完成绝不回退到旧图。结构漂移的分支处理如果gitnexus-work在执行途中发现计划的结构性假设不成立structural drift它会路由回gitnexus-plan的 Deepen 模式——而不是硬推过去。编排器此时负责把漂移后的计划带回 Lane 2 闸门由用户再次选择继续或停止。注意 drift 路由与普通偏差的区分小范围、计划内的偏差由执行器自行适配并记录在 commit message 与最终报告中只有结构性遗漏scope、需求、关键技术决策或规划接缝失效才触发 Deepen 回路。Lane 4 — 评审一次修复循环封顶编排器对完成的工作调用gitnexus-review。目标解析的规则是存在打开的 PR 时传 PR URL 或编号否则传当前分支branch/ref 对默认分支求 diffmerge-base 语义如果执行后还有本地改动残留则把local作为第二个、单独标注的评审面传入。gitnexus-review拥有自己的目标解析逻辑PR /base...head/base..head/ 分支 / local 多形态、精确 SHA 检出与索引对齐临时 detached worktree绝不切换用户当前 worktree、以及 merge-base 选择——SKILL.md 明令不要在这里重复该逻辑。评审流程包含编号工作流全量 diff →detect_changes对齐精确面 → 对每个行为变更符号跑impact {includeTests: true}→ 逐条核查 diff 外的 d1 直接依赖 →context核查关键符号 → taint/依赖传递检查 版本与失效常量核查外加按图聚类分组的专家透镜expert lenses变更触及哪个领域就派哪个领域的透镜ingestion、embeddings、Ladybug 等四个跨领域透镜架构契合、语言一致性、Definition of Done、简洁性恒定运行每个透镜的输出都必须落到 Finding 标准严重级 精确path:line锚点 失败场景 图证据 补救建议。编排层在评审后要做的是把评审结论与发现呈现给用户用户希望修复的发现按边界分流属于gitnexus-work直接模式范围1–2 个文件、无架构决策→ 交给直接模式更大的 → 回到计划闸门用发现 Deepen 计划或停止重跑本 lane 的评审一次。这次重跑不得再开启新的修复循环——即使仍有发现也要如实报告并把用户导向/gitnexus-work或计划闸门以有意为之的方式继续。一次修复循环封顶one bounded fix cycle的硬约束是为了防止评审-修复无限拉锯。最终报告与后续动作流水线以一条消息收尾包含计划路径、执行的加深循环次数、产出的提交、验证状态、评审结论与未解决的发现、以及明确未完成的事项如果有。一个重要的默认行为是流水线不会自行 push也不会自行开 PR——编排器把两者都作为可选的下一步提供给用户。完整链路图与各 lane 归属速查下表汇总整条流水线的 lane、技能归属与闸门Lane技能闸门/分支Plangitnexus-planSKILL.md深度前置询问阻塞闸门继续 / 停止Workgitnexus-workSKILL.md结构漂移路由回计划闸门Reviewgitnexus-reviewSKILL.md最多一次修复循环然后报告三个技能对应的仓库权威文档与契约gitnexus-plan的 README.md 定义了它与图谱/PDG/源码验证三层架构的交互以及references/下五个契约文件context-ledger、pdg-slice、plan-template、context-pack、evidence-provenancegitnexus-work的 README.md 定义了与计划的契约§11 pack 为机器接口、evidence_provenance强制、计划永不被修改以及唯一的新鲜度过程gitnexus-review的评审输出模板Findings / Change and blast-radius summary / Coverage and residual risk / Verdict可以直接复用到任何 CI 评审脚本中。阈值治理为什么 35 轮边界可以信赖Lane 1 的 ~35 轮边界来自 eval/workflow_bench/README.md 的测量结论在trivial-version-alias基线 16 轮、inv-bug-pdg-note基线 22 轮、inv-feature-list-repos-filter基线 32 轮这类任务上完整 workflow 的成本是基线的 3 倍以上而workflow_direct接近基线甚至更快真正的分水岭在cross-module-parse-retry这类跨模块任务上——workflow_direct以 52 轮 / $9.53 / 15 分钟对基线的 98 轮 / $18.03 / 34 分钟取胜成本 −47%、墙钟 −56%靠的正是 impact 优先导航与门禁化提交。这就是 lfg 边界分诊的实证基础小任务走直接模式跨模块任务才值得付完整规划的固定成本。同时workflow_bench 的 promotion 门对任何技能改进都要求至少 3 对有效运行、零排除、每任务每运行都过隐藏 oracle、无单任务分辨率回退、分辨率有 ≥2 的余量、同质量下效率指标中位提升 ≥5%、单任务效率回退 ≤20%。也就是说lfg 里那条 35 轮阈值不是谁拍脑袋写的而是经过确定性提升门验证后才写进 SKILL.md 的受管策略——这也是为什么实时任务中的 Agent 被明确禁止自行编辑它。何时使用 lfg一个路由速判任务平凡或 ≤35 轮可完成 → 跳过流水线直接/gitnexus-work small task text直接模式或纯 Agent跨模块、需要多会话执行、或计划文档本身是交付物 → 完整/gitnexus-lfg task已有现成计划文件 →/gitnexus-lfg docs/plans/existing-plan.md从闸门开始无人值守 / headless / CI 环境 → lfg 会在 Lane 1 后停住计划即交付物绝不自动执行。在 GitNexus 仓库里这套编排对应的技能栈与基准基础设施全部开源可查规范源在 gitnexus/skills/插件镜像在 gitnexus-claude-plugin/skills/配对基准与提升门在 eval/workflow_bench/你随时可以按 README 中的 quick start 复现测量或按 Prompt and skill evolution loop 的流程离线提交一个候选技能改动——但记住技能的自改进永远走离线候选循环绝不在实时任务中自我改写。【免费下载链接】GitNexusGitNexus: The Zero-Server Code Intelligence Engine - GitNexus is a client-side knowledge graph creator that runs entirely in your browser. Drop in a git repository (Github, Gitlab, Azure, Local) or ZIP file, and get an interactive knowledge graph with a built in Graph RAG Agent. Perfect for code exploration项目地址: https://gitcode.com/GitHub_Trending/gi/GitNexus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考