m1nd 是一个面向编码代理（coding agents）的操作性智能层（operational intelligence），通过 MCP（Model Context Protocol）协议为代理提供代码库的结构化情报、目标导向的关注点（attention）路由以及对未校准结论的诚实拒答能力。项目核心理念是"诚实的『不知道』优于自信的猜测"，所有结论都附带可信度评分，避免给代理传递幻觉信息。资料来源：README.md:1-40

核心定位与设计原则

m1nd 不是一个检索增强生成（RAG）框架，而是一个预定向（pre-orient）→ 校准执行（act on calibrated verdicts）→ 经验沉淀（capture what you learned）的闭环系统。在 v1.2.0 进入 OMEGA 时代后，这一取代了纯"检索然后祈祷"的旧模式。资料来源：README.md:42-60

设计原则体现在三个层面：

• 信任层：响应附带 confidence 分数，低于阈值时直接返回 unknown 而不是伪造答案
• 关注层：通过 focus 接口实现目标条件化的注意力运行时，仅返回代理当前任务所需的最小代码子集
• 人类层：在 v1.4.0 引入"trees manager"（项目管理区），将单棵代码树拓展为多项目工作区

仓库结构与组件

m1nd 采用 monorepo 结构，顶层 package.json 用于统一管理工作区的 npm 子包与脚本。资料来源：package.json:1-30

主要子项目包括：

资料来源：m1nd-ui/package.json:1-25; m1nd-demo/package.json:1-25

核心能力接口

m1nd 通过 MCP 暴露给代理的接口可归纳为四类，每一类都对应不同的代理意图：

• 结构查询：impact（影响面分析）、why（调用原因链）；
• 探索查询：seek（按目标查找节点），v0.9.0-beta.8 修复后能正确看到物化边；
• 注意力：focus —— v1.1.0 引入的目标条件化注意力运行时，返回预算受限的最小代码子集；
• 方向导航：north —— v1.2.1 开启"复合（compounding）"循环后的方向锚点。

所有响应都遵循"诚实优于猜测"的原则：当调用方超出绑定仓库范围时，v1.4.0 引入的 degraded mode（降级模式）会返回降级答复而非保持沉默。资料来源：README.md:60-90

发布与社区反馈通道

m1nd 在 crates.io 与 npm 上同步发布，版本同步从 v1.2.0 起的 m1nd-core / m1nd-ingest / m1nd-mcp 三包同号。社区反馈通过本地邮箱 ~/.m1nd/field-reports.jsonl 收集，不进行远程上报（"m1nd never phones home"），v1.2.1 的"field-triage patch"即基于该邮箱的四条告警逐一转成红盒测试用例再修复。资料来源：README.md:90-110; skills/README.md:1-30

最新版本 v1.5.0 主要补全了人类视图的诚实 medulla 卡片、按类别着色的色块以及供编码代理使用的厂商中立工作指南 AGENTS.md。

flowchart LR
  Agent[编码代理] -->|MCP 调用| m1ndMCP[m1nd-mcp]
  m1ndMCP --> m1ndCore[m1nd-core / m1nd-ingest]
  m1ndCore --> Graph[(结构图谱)]
  m1ndMCP -->|confidence 校准| Agent
  m1ndUI[m1nd-ui 可视化] --> m1ndCore
  m1ndDemo[m1nd-demo 演示] --> m1ndCore

概述与定位

m1nd-ui/src/lib/ 是 m1nd 前端可视化子系统（m1nd-ui）的纯逻辑层。它不渲染 UI，而是把后端 MCP / core 接口的原始数据加工成视图所需的数据形状（如代码结构图、回放帧、告警集合），并集中处理跨组件复用的领域规则（"诚实沉默"、越界降级、可信评分）。该模块是 m1nd v1.4.0 引入 degraded mode、v1.5.0 人类视图（medulla card）等特性的逻辑承载层。资料来源：m1nd-ui/src/lib/api.ts。

核心子模块

API 客户端 (`api.ts`)

api.ts 封装了与 m1nd-mcp、m1nd-core 之间的请求边界。它处理身份、路径归一化（Windows 盘符已在 v0.9.0-beta.8 修复）、错误归一化，并向上层返回带可信度标记的结果，而不是裸 JSON——这与项目"诚实无可信数据时沉默"的原则一致。v1.4.0 的 degraded mode（§9.5）通过此层把"调用者位于绑定仓库之外"这一事实转化为可被 UI 解释的返回结构，而非静默失败。资料来源：m1nd-ui/src/lib/api.ts。

告警计算 (`alerts.ts` + `alerts.test.ts`)

alerts.ts 负责从结构图与回放数据中派生告警集合，而不是直接消费后端推送。它的纯函数风格使得 alerts.test.ts 能以"红电池"方式覆盖边界（如零边图、回放帧缺失、跨语言调用节点的解析降级）。v1.2.1 的 field-triage 闭环即在此层沉淀：用户本地报错 → 规则更新 → 测试固化。资料来源：m1nd-ui/src/lib/alerts.ts、m1nd-ui/src/lib/alerts.test.ts。

代码地图构建 (`buildMap.ts` + `buildMap.test.ts`)

buildMap.ts 将 ingest 输出转化为可视化的节点/边集合。它实现 Graph::finalize() 之后的投影层——v0.9.0-beta.8 修复的"重 finalize 丢弃边"问题在这一层也有镜像处理，避免 UI 在已有素材的情况下仍显示空图。它还负责 v1.5.0 pastel 字母盒（per-class letter boxes）的字母与配色分配。资料来源：m1nd-ui/src/lib/buildMap.ts、m1nd-ui/src/lib/buildMap.test.ts。

回放帧构建 (`buildReplayFrames.ts`)

buildReplayFrames.ts 把会话事件流按时间维度切片为"帧"，供时间轴组件消费。这一文件与 focus attention runtime（v1.1.0）配合，决定每一帧上重点呈现的节点与边。资料来源：m1nd-ui/src/lib/buildReplayFrames.ts。

数据流与架构

下表刻画了 lib/ 在 m1nd-ui 数据管道中的位置：

组件层只依赖 lib/ 暴露的函数与类型，不直接接触后端协议——这也是 m1nd-ui 能在 m1nd-viz 与 m1nd-demo 之间复用的根本原因。资料来源：m1nd-ui/src/lib/api.ts。

测试与可信赖性

lib/ 下每个非平凡文件都配有 *.test.ts（alerts.test.ts、buildMap.test.ts），与 m1nd "测量优于断言" 的方法论一致：先有红色用例，再有实现，再有 release note（如 v1.2.1 的四连闭环）。资料来源：m1nd-ui/src/lib/alerts.test.ts。

关联与边界

• 与 m1nd-mcp 的通信契约集中在 api.ts；当 MCP 后端 schema 演进时，lib/ 是首选适配点。
• v1.4.0 的 degraded mode 与 v1.5.0 的 honest medulla card 都是先在 lib/ 中实现判断逻辑，再被视图层消费。
• lib/ 不持有长期状态；会话状态由专用的 storage 模块管理，避免与派生逻辑混淆。

Pitfall Log / 踩坑日志

项目：maxkle1nz/m1nd

摘要：发现 7 个潜在踩坑项，其中 0 个为 high/blocking；最高优先级：配置坑 - 可能修改宿主 AI 配置。

1. 配置坑 · 可能修改宿主 AI 配置

• 严重度：medium
• 证据强度：source_linked
• 发现：项目面向 Claude/Cursor/Codex/Gemini/OpenCode 等宿主，或安装命令涉及用户配置目录。
• 对用户的影响：安装可能改变本机 AI 工具行为，用户需要知道写入位置和回滚方法。
• 证据：capability.host_targets | https://github.com/maxkle1nz/m1nd | host_targets=mcp_host, claude

2. 能力坑 · 能力判断依赖假设

• 严重度：medium
• 证据强度：source_linked
• 发现：README/documentation is current enough for a first validation pass.
• 对用户的影响：假设不成立时，用户拿不到承诺的能力。
• 证据：capability.assumptions | https://github.com/maxkle1nz/m1nd | README/documentation is current enough for a first validation pass.

3. 维护坑 · 维护活跃度未知

• 严重度：medium
• 证据强度：source_linked
• 发现：未记录 last_activity_observed。
• 对用户的影响：新项目、停更项目和活跃项目会被混在一起，推荐信任度下降。
• 证据：evidence.maintainer_signals | https://github.com/maxkle1nz/m1nd | last_activity_observed missing

• 严重度：medium
• 证据强度：source_linked
• 发现：no_demo
• 证据：downstream_validation.risk_items | https://github.com/maxkle1nz/m1nd | no_demo; severity=medium

5. 安全/权限坑 · 存在评分风险

• 严重度：medium
• 证据强度：source_linked
• 发现：no_demo
• 对用户的影响：风险会影响是否适合普通用户安装。
• 证据：risks.scoring_risks | https://github.com/maxkle1nz/m1nd | no_demo; severity=medium

6. 维护坑 · issue/PR 响应质量未知

• 严重度：low
• 证据强度：source_linked
• 发现：issue_or_pr_quality=unknown。
• 对用户的影响：用户无法判断遇到问题后是否有人维护。
• 证据：evidence.maintainer_signals | https://github.com/maxkle1nz/m1nd | issue_or_pr_quality=unknown

7. 维护坑 · 发布节奏不明确

• 严重度：low
• 证据强度：source_linked
• 发现：release_recency=unknown。
• 对用户的影响：安装命令和文档可能落后于代码，用户踩坑概率升高。
• 证据：evidence.maintainer_signals | https://github.com/maxkle1nz/m1nd | release_recency=unknown