lrnev-govern

mcp
Security Audit
Fail
Health Pass
  • License — License: MIT
  • Description — Repository has a description
  • Active repo — Last push 0 days ago
  • Community trust — 30 GitHub stars
Code Fail
  • rimraf — Recursive directory removal in package.json
  • exec() — Shell command execution in src/core/ADRManager.ts
  • exec() — Shell command execution in src/core/AutoAnalyzer.ts
  • exec() — Shell command execution in src/core/Doctor.ts
  • exec() — Shell command execution in src/core/GateRunner.ts
Permissions Pass
  • Permissions — No dangerous permissions requested

No AI report is available for this listing yet.

SUMMARY

AI 协作开发的项目治理引擎。MCP 服务 + CLI 双形态,文件即真相,零模型依赖。

README.md

lrnev 🧭

AI 协作开发的项目治理引擎 —— MCP 服务 + CLI 双形态,文件即真相,零模型依赖。

npm 包名 lrnev,当前版本 1.2.0lrnev 是命令行,lrnev-mcp 是 MCP 服务入口。一行命令装好 👇

npm install -g lrnev

1. 这是什么、为什么用它 🤔

一句话:lrnev 给"AI 帮你写代码"这件事加了一套档案和流程,让 AI 不再是"聊完就忘、每次从零开始猜你要什么"。

不用它会怎样?(很多人遇到的痛)

  • 🌀 AI 健忘:今天聊好的需求,明天新开窗口它全忘了,你得从头再讲一遍。
  • 🤷 没有依据:AI 写了一堆代码,过两周你自己都说不清"这段当初是为了满足什么需求、验收标准是什么"。
  • 👥 多窗口打架:你开俩 AI 窗口同时干活,它俩改同一个文件,互相覆盖。
  • 🎲 质量看运气:需求写得糊,AI 就发挥得糊,没有人提醒"这个需求还没说清就别动手"。

用了它,AI 会变好在哪?

lrnev 把项目的"需求、设计、任务、决策、踩过的坑"都落成 .lrnev/ 目录下的普通 Markdown 文件(你能直接看、能 git 提交)。于是:

  • 🧠 AI 有记忆了:新窗口、新对话,AI 调一下 project_status 就知道"这项目做到哪了、还剩什么活",不用你重讲。
  • 📌 每行代码可追溯:每个任务都挂在一条需求(Spec)下,写之前先有验收标准,AI 不会闷头乱写。
  • 🚦 质量有闸:需求没填清楚(gate 不通过),AI 不会急着写代码。
  • 👥 多窗口不打架:谁在做哪个任务有登记,碰同一文件会提醒。

什么是 Spec? 就是"一个要交付的功能"的小档案夹,里面三份文件:要做什么(requirements)、怎么做(design)、拆成哪些活(tasks)。你不用手写,AI 用工具生成。

核心宗旨:只引导,不强制 🕊️

这是 lrnev 最重要的一点:它不替 AI 做判断,也不锁死 AI 的手脚。

  • lrnev 只做确定性的事:读写文件、分配 ID、状态机、结构检查 —— 这些有标准答案,它自己干,全程不调用任何 LLM / Embedding,不联网、不烧你的 API
  • 凡是需要判断的事(这需求该拆几个、代码质量好不好、该不该开 Spec),lrnev 只通过 ai_followup 给 AI 提个醒,最终怎么做还是 AI 和你定。它不会强行拦着不让你干活。

所以你不会有"被工具绑架"的感觉——它更像个贴身提醒的助理,而不是卡审批的流程官

那会更费 token 吗?💰

会费一点,但比你想的少,而且很多场景反而更省。诚实说清楚:

  • 固定开销(一次性):接入后,客户端会把 lrnev 的工具清单 + 用法说明注入对话,约 2000 tokens 左右。这是每个 MCP 服务都有的标准开销,不是 lrnev 特有,且通常一个会话只注入一次。
  • 每次调用:调一个 lrnev 工具,返回的是一小段结构化 JSON + 下一步提示,约 100~400 tokens,很便宜。
  • 省回来的部分project_status 给的是有界的接手快照(只返活任务 + 计数),不让 AI 把整个代码库重读一遍;.lrnev/ 里的需求/设计让 AI 不用每次重新理解项目。在长项目、多次接手的场景,省下的远多于花掉的。

一句话:短平快的一次性小任务,lrnev 是净增开销,不划算需要持续迭代、多窗口、要追溯的真实项目,它通常帮你省 token、更省你重复解释的时间。按项目选用,别无脑全开。

它具体怎么帮 AI 省 token(这些是真正的隐藏价值)🔍

lrnev 的设计原则是让 AI 永远只读"当前这一步需要的最小信息",绝不让它把整个 .lrnev/ 或代码库挨个读一遍

  • 📸 接手只读"快照"不读全文project_status 只读各文档的 frontmatter(标题/状态)+ 任务状态,不加载 requirements/design 正文、不读你的源码。AI 一次调用就知道"项目做到哪、还剩什么活",而不是把几十个文档全 read 进上下文。
  • 🪜 分层摘要,按需下钻:每个 Spec/Scene 可存 L0(一句话)/ L1(概览) 摘要(.abstract.md / .overview.md)。AI 先读一句话判断"是不是我要找的",确认了才读全文。找东西时不用把候选文档整篇拉出来。
  • 🔎 关键词检索定位,而不是遍历context_search 按关键词 + 目录层级 + L0/L1 打分,直接告诉 AI"你要的需求/任务/决策在哪个文件",AI 只去读那一个,而不是 for 循环读所有 spec 找匹配。
  • 🎯 要哪份给哪份:查任务用 task_list、查某个 Spec 用 spec_get,返回的是结构化元信息,不会顺手把三份文档正文全塞回来。

对比"裸用 AI":你不挂 lrnev 时,AI 要了解项目现状,往往得 read 一堆文件、或你手动粘贴上下文——那才是真正烧 token 的地方。lrnev 把这步变成"一次小调用拿快照 + 按需精准下钻"。

lrnev 不做什么:代码语义理解 🤝

要分清边界:lrnev 管的是**「AI 怎么写代码」的流程与档案**(需求/任务/决策/状态),它不去理解你源码的语义(哪个函数调哪个、改这里会影响什么)。

如果你想要后者——让 AI 真正"读懂"整个代码库的结构和依赖——可以搭配 codegraph:它把整个项目解析成代码知识图谱(函数/类/文件之间的调用与依赖关系),AI 要改某处时,能顺着图谱知道"它关联哪些、动了会影响谁"。

而且 codegraph 同样帮 AI 省 token——AI 不必把一堆源文件整篇读进上下文去猜调用关系,直接查图谱就能精准定位相关代码。所以二者是同一种思路在两个层面的体现:lrnev 用快照/摘要让 AI 少读"项目档案",codegraph 用图谱让 AI 少读"源码",一个管流程治理,一个管代码理解,刚好互补

适合 / 不适合

✅ 适合:一个人多 AI 窗口接力、想让代码有需求追踪和验收、做 MCP 工具想给用户治理骨架、长期迭代的项目。
❌ 不太需要:改一两行的一次性小脚本、纯问答、玩具 demo —— 直接用 AI 就好,别为它套流程。

不绑定客户端:Claude Code / Cursor / Codex / 任何支持 MCP 的都能用,不接 MCP 直接敲 CLI 也行 🆓


2. .lrnev/ 工作区 📂

lrnev init 在项目根创建。全是 markdown + frontmatter,人可直接读、AI 可直接写、git add .lrnev/ 即可版本管理。不用数据库,不搞黑盒。

.lrnev/
├── PROJECT.md                      # 项目定位 + 团队约定(也是"已初始化"标记)
├── ARCHITECTURE.md                 # 全局架构约束
│
├── steering/                       # 全局行为指引(AI 读这些决定怎么干活)
│   ├── CORE_PRINCIPLES.md          # 核心原则
│   ├── SCOPE_RULES.md              # 范围规则 + EARS 写作提示
│   ├── ADR_TRIGGERS.md             # 什么情况下该建 ADR
│   └── MEMORY_TRIGGERS.md          # 什么情况下该记一条 memory
│
├── scenes/                         # 业务场景
│   ├── 00-default/                 # 默认 Scene(spec_create 不传 scene 时自动挂这里)
│   │   ├── scene.md                # Scene 元信息(边界、术语、背景)
│   │   ├── architecture.md         # 跨 Spec 共享的架构约束(可空)
│   │   ├── roadmap.md              # 演进路线(可空)
│   │   ├── decisions/adr/          # Scene 范围 ADR(编号 0001-)
│   │   ├── errorbook/              # Scene 范围错误手册
│   │   └── specs/                  # Scene 下所有 Spec
│   │       └── 01-00-user-login/   # 格式:{NN}-{VV}-{kebab-name}
│   │           ├── requirements.md # F-xx 需求 + 验收标准(L0/L1/L2 分层写作)
│   │           ├── design.md       # 技术方案 + 关键决策
│   │           └── tasks.md        # T-XXX 任务清单(HTML 注释承载状态机)
│   │
│   └── 01-user-management/         # 显式创建的业务 Scene
│       └── ...(同结构)
│
├── decisions/
│   └── adr/                        # 全局 ADR
│
├── errorbook/
│   ├── incidents/                  # 踩坑记录(指纹去重)
│   └── promoted/                   # 提升为手册的已验证错误
│
├── memory/                         # 5 类项目记忆(preferences/decisions/patterns/errors/facts)
│
├── auto/
│   └── codebase.json               # 技术栈自动探测快照
│
├── config/
│   └── hooks.json                  # Hooks 配置
│
├── agents/
│   └── registry.json               # Agent 注册中心(会话存活,随进程生命周期判定)
│
├── runtime/
│   └── claims/                     # Task claim 运行态软占用
│
├── state/
│   └── hook-log.jsonl              # Hook 执行日志
│
└── locks/                          # 运行时锁文件

ID 约定

  • Scene:{NN}-{kebab-name},如 01-user-management。序号扫描目录 max+1,删除高位会被复用。
  • Spec:{NN}-{VV}-{kebab-name},如 01-00-user-loginNN Scene 内递增,VV 版本号。
  • Task:T-001 起 Spec 内递增,状态机在标题行注释里 <!-- lrnev-task: status=completed, validates=F-01 -->

三档分流:踩坑→error_record;小决策/选型→adr_create;约定/要点→memory_save;可交付特性→spec_createassess_goal 提供建议,AI 和用户一起决定。


3. 使用 🚀

安装

npm install -g lrnev

搞定 ✨ 想在本地改源码玩:

git clone https://github.com/LuChangQiu/lrnev-govern.git
cd lrnev-govern
npm install && npm run build && npm link

接入 AI 客户端 🔌

在客户端 MCP 配置里加一行:

{ "mcpServers": { "lrnev": { "command": "lrnev-mcp" } } }

搞定。首次对话对 AI 说一句就行:

这个项目用 lrnev 治理。先调 lrnev_guide 了解怎么用,再按指引推进。

防长对话遗忘 💤

MCP 的工作流说明只在连接时注入一次。聊了几十轮之后 AI 可能"忘了"要用 lrnev——正常现象。把下面这段贴进客户端的常驻提示槽(不会被压缩),AI 每轮都被提醒:

  • Claude Code:项目根 CLAUDE.md
  • Cursor.cursor/rules 或 Settings → Rules
  • Codex / 其他:自定义 instructions

更完整的客户端适配说明见 docs/AI-ADAPTATION.md 的“常驻提示词模板”。

本项目用 lrnev 治理。规则:
1. 不确定当前状态时,先调 project_status,不要凭记忆直接改代码。
2. 【先想清楚该不该开 spec,自己判断、别对着清单匹配】问自己两点:这事(a)能写出一条有意义的"WHEN…THEN"验收吗?(b)是可独立交付的特性吗?两个都"是"才 spec_create。否则——比如改文档/排版/注释、小重构、调参数、回答问题等(这些只是举例,不止这些)——直接做,不要开 spec。拿不准就问我,别默认开 spec。
3. 踩坑→error_record,技术决策→adr_create,约定→memory_save;都不沾的小事直接做。
4. 多特性需求先按拆分标尺判断单/多 Spec(可用 assess_goal 辅助),别把多个特性塞进一个 Spec。
5. 改代码前确认对应 task 已 task_update(in_progress),完成后 task_update(completed)。
6. 不清楚怎么用就调 lrnev_guide。

常用命令 👇

# 初始化工作区(不传 --project-name 则默认用当前文件夹名)
lrnev init

# 接手一个项目 —— 先看做到哪了
lrnev status

# 新建 Spec(不传 scene 自动挂 00-default)
lrnev spec create user-login --priority P0

# 跑 ready gate(检查需求结构是否完整)
lrnev gate check --scene 00-default --spec 01-00-user-login --gate ready

# 建任务(validates 关联到需求锚点 F-01)
lrnev task create "实现登录 API" \
  --scene 00-default --spec 01-00-user-login \
  --validates F-01 \
  --acceptance "POST /login 200" "错误密码 401"

# 推任务状态(in_progress 时会提示 AI 先读 F-01 对应段)
lrnev task update T-001 --scene 00-default --spec 01-00-user-login --status in_progress
lrnev task update T-001 --scene 00-default --spec 01-00-user-login --status completed

# 全部完成跑 completion gate
lrnev gate check --scene 00-default --spec 01-00-user-login --gate completion

# 工作区体检 / 旧 TODO 迁移 / 使用手册
lrnev doctor
lrnev doctor --migrate-todos
lrnev guide

完整命令:lrnev --help。MCP 工具名跟 CLI 子命令一一对应,同一个能力两条路都能走 🚶‍♂️


4. 主要流程 🔄

新建特性

flowchart TD
  Start([用户提出需求]) --> Assess[assess_goal 判断粒度]
  Assess -->|可交付特性| SpecCreate[spec_create\n生成三文档]
  Assess -->|踩坑/小决策/约定| Light[error_record / adr_create / memory_save]
  Light --> Done([完])

  SpecCreate --> Fill[填 requirements\n替换 FILL 哨兵]
  Fill --> ReadyGate{spec_gate_check ready}
  ReadyGate -->|失败| Fill
  ReadyGate -->|通过| Prompt[ai_followup:\n建议 ADR?\nEARS 验收示范]
  Prompt --> TaskCreate[task_create]
  TaskCreate --> TaskProgress[task_update in_progress\nai_followup: 先读验收标准]
  TaskProgress --> TaskDone[task_update completed]
  TaskDone -->|还有 task| TaskProgress
  TaskDone -->|全部完成| CompletionGate{spec_gate_check completion}
  CompletionGate -->|通过| End([完结\n逐条核对验收])

接手项目

flowchart LR
  Resume([新 AI 会话]) --> Status[project_status\n一次拿全部状态]
  Status --> Read[active_tasks / active_agents / specs]
  Read -->|in_progress task| Continue[继续推进那个 task]
  Read -->|全部空闲| New[从 free_tasks_count > 0 的 Spec 领活]

AI 的视角 👀

step 1: 连上 → server instructions 告诉它"lrnev 是什么 + 新建/接手怎么走"
step 2: 懵了 → 调 lrnev_guide 拿完整手册
step 3: 每调一个工具 → ai_followup 推给它下一步该干嘛
step 4: 搞砸了 → 错误 hint 告诉它怎么修(不用回头问用户)

5. 文档与示例 📚

用户文档 内容
docs/ARCHITECTURE.md 源码结构与设计原则
docs/GOVERNANCE-FLOW.md Gate 语义、哨兵、状态机、resume、adopt、与 OV 边界
docs/HOOKS.md Hooks 配置写法与事件列表
docs/MULTI-AGENT.md 多 Agent 注册、心跳与 claim 接管
docs/AI-ADAPTATION.md 跨客户端适配原则、常驻提示词模板与实测矩阵
示例 内容
examples/sample-project 从初始化到 gate 通过的 CLI 上手 demo

6. 开发 🛠️

npm install && npm run build
npm test            # 532 条测试 ✅
npm run dev:mcp     # tsx watch 跑 MCP
npm run dev:inspect # MCP Inspector 调试
npm run lrnev -- init   # 本地跑 CLI

想一起搞?先看 CONTRIBUTING.md 🤝


7. 问题反馈 💬

遇到问题?有灵感?欢迎 提 Issue 🙋

不保证每个反馈都会改,但每一条都会认真看、认真想 🧠。是 bug → 🔨 一定修。暂不改 → 📝 也会在 Issue 里说清楚为什么,不冷处理。


许可证

MIT

Reviews (0)

No results found