推荐采用下面这条版本演进路径，而不是直接把 30 / 60 / 90 天阶段映射成 1.0 / 2.0 / 3.0：
v0.8 / v0.9 → v1.0 → v2.0
这是更稳妥、也更符合当前仓库状态的映射。
- v0.8 / v0.9：承载“30 天阶段”，目标是把主路径做通，形成可用预发布产品
- v1.0：承载“60 天阶段”，目标是把可信度、解释性和记忆治理补齐，形成可持续使用的正式版本
- v2.0：承载“90 天阶段”，目标是把运维、发布门禁和团队能力做完整，形成团队试点版本
这个判断不是凭空设想，而是基于当前仓库已经具备的能力，以及当前检查范围内可见的产品缺口：
- README 已经明确列出混合检索、项目记忆、长期记忆、跨项目 Hub、异步索引、观测、索引优化和 22 个 MCP 工具，说明底层 infra 能力已经比较完整
- CLI 已经具备
init、index、search、daemon、mcp等主命令，说明接入、索引、检索、服务化入口都已存在 - 在统一产品身份之前，仓库曾存在 README 标题、包名与仓库链接不一致的问题
- 当前检查到的 workflow 以
release.yml为主，说明发布路径已存在；但在本次检查范围内，还没有看到同样清晰的测试 / 验证门禁表达
因此，接下来不应该优先继续横向堆能力，而应优先把能力压缩成清晰、可信、可运维的产品主路径。
从仓库现状看，ContextAtlas 对应的这套系统已经不是“只有一个搜索工具”的雏形，而是一套面向 AI 编码助手的上下文基础设施。
当前已具备的能力包括：
- 混合检索：向量召回 + FTS + RRF + rerank
- 语义分片与上下文扩展：Tree-sitter 分片、邻居扩展、breadcrumb 补全、跨文件 import 解析
- 项目知识层：Feature Memory、Decision Record、Project Profile
- 长期记忆：支持
user/feedback/project-state/reference - 跨项目 Hub：项目注册、跨项目搜索、依赖链、关系图谱
- 索引可靠性：SQLite 队列、daemon 消费、快照写入、原子切换
- 观测与优化：retrieval telemetry、usage tracker、索引优化报告
- MCP 产品接口：22 个 MCP 工具
这些能力已经足以支撑“产品化补全”阶段，而不是继续优先证明“技术上还能做到什么”。
虽然底层能力很多，但从对外产品视角看，仍存在 3 个关键缺口：
README 更像能力总览，而不是“新用户第一次上手就能跑通”的产品路径。当前仓库虽然已经有 CLI / MCP / 索引 / 搜索 / 记忆能力，但还缺少一个更统一的默认使用闭环：
connect repo → index status → ask → inspect result → feedback / save memory
项目的差异化不只是检索，而是“检索 + 项目记忆 + 长期记忆 + Hub”。
这也意味着一旦来源层级、时效状态、冲突规则不透明，用户会很快怀疑结果质量。README 虽然已经定义了长期记忆边界、过期、核验时间和 stale 清理，但这些机制还需要成为产品表面的一部分，而不是只停留在模型设计里。
仓库已经有异步索引、daemon、usage tracker、retrieval monitor、release workflow，这说明系统性能力已有较好基础。
但如果没有：
- 索引健康可视化
- 增量更新策略
- 发布前测试与 smoke gate
- 团队层使用/纠错/质量指标
在这些能力没有产品化收口之前，它更像“工程能力很强的 infra 原型”，而不是“团队愿意持续使用的产品”。
90 天后的版本，不应该只是“功能更多”，而应该尽量满足下面 5 个产品结果：
- 用户几分钟内就能接入一个 repo 并完成首次有效问答
- 首次问答不只是代码片段，还能带出相关记忆、决策背景和来源解释
- 索引状态可见，失败可恢复，冷启动期间也有降级结果
- 记忆写入有质量门槛，且有 freshness / stale / conflict 治理
- 仓库名、包名、CLI、README、发布信息一致，不再出现产品身份割裂
所以这份路线图的重点，不是继续添加横向能力，而是把已有能力压缩成：
- 一条主路径
- 一套可信机制
- 一组可运维闭环
这一阶段对应原来的 30 天阶段。
目标不是“功能做全”，而是把它做成一个可跑通主路径的预发布产品。
之所以仍建议放在 0.x，而不是直接叫 1.0，主要原因是：
- 当前产品身份仍未统一
- 现有文档更偏 infra 能力展示，而不是用户导向主路径
- 可信机制和记忆治理还没有系统外显
换句话说，它已经具备可用性，但还没有达到“正式承诺长期稳定体验”的程度。
用户第一次接触产品时，不应该先学习 22 个 MCP 工具。
应优先形成一个固定主流程：
Connect Repo
→ Check Index Status
→ Ask
→ Review Result
→ Give Feedback / Save Memory
不管最终承载形态是 CLI + TUI、轻量工作台，还是 MCP 上层默认交互，产品层都应该先把这条路径做清楚。
每次回答都应固定输出 4 个区域：
- 命中的代码片段
- 相关模块记忆
- 相关决策记录
- 为什么命中这些结果
这一步的意义是把异构能力统一成同一种阅读体验，而不是把代码、记忆和解释拼成一大段文本。
在首次索引未完成时，系统应支持：
- 先走 lexical / FTS 降级查询
- 明确显示“索引中 / 可部分回答 / 完整模式未就绪”
- 索引完成后自动切换到完整混合检索
这会把现有的异步索引能力真正翻译成用户体验。
这是 v0.8 / v0.9 阶段必须完成的事情。
当前对外身份存在明显割裂：
- README 标题、包名与 repository / homepage 曾存在旧品牌残留
如果不先统一这些信息，用户对产品成熟度和产品身份的感知会天然打折。
- 新用户能在 10 分钟内跑通首次接入与问答
- 首次结果结构固定，不再只是长文本输出
- 索引未完成时可返回有限结果，不会直接卡死
- 仓库名、CLI 名、README、包名、发布信息完成统一
如果这阶段只是把主路径跑通，但可信与治理机制还未完整，就更适合标成：
- v0.8：主路径初步成型
- v0.9：主路径打磨 + 产品身份统一 + 冷启动体验稳定
而不是过早叫 1.0。
这一阶段对应原来的 60 天阶段。
这里才更适合定义为 1.0，因为此时产品的门槛不再是“第一次能跑通”，而是：
用户第一次用能跑通，第二次用还敢信。
ContextAtlas 的核心差异化并不是单纯检索，而是“检索 + 记忆 + 决策 + Hub”的组合。因此，1.0 的真正门槛也不是“已经能搜到代码”，而是：
- 结果来源清楚
- 记忆状态清楚
- 冲突规则清楚
- 写入治理清楚
只有这些补齐后，1.0 的定义才更站得住。
在产品结果中显式标注：
- Source: Code
- Source: Feature Memory
- Source: Decision Record
- Source: Long-term Memory
- Source: Cross-project Hub
这不是 UI 修饰，而是可信基础设施的产品化。
每条 memory 至少应可见下面几个维度：
- 最后核验时间
- 是否 stale
- 是否可能与当前仓库状态冲突
- 是否来自人工确认写入
README 已经定义了过期、核验时间和 stale 清理，因此这一阶段的重点，是把这些内部模型变成用户可感知的可信信号。
建议把下面规则升格为产品规则，而不只是实现细节：
- 代码优先于旧 memory
- 新 decision record 优先于旧 profile
- 长期记忆只补“代码推不出来的事实”
- 发生冲突时直接展示冲突状态，而不是静默覆盖
记忆系统要能持续用，就必须防止污染。
建议在这一阶段补上：
- 默认建议写入，而不是自动落库
- 相似 feature memory 去重 / 合并
- 源码或路径大变动时自动标记“待复核”
- 把“人工确认”作为高质量记忆的显式状态
在结果页增加极简反馈动作：
- 这条结果有帮助 / 没帮助
- 这条记忆过期
- 这条记忆绑定错模块
- 保存为决策 / 保存为参考
这一步能把现有 retrieval telemetry 与 usage tracker 更明确地推进到“质量闭环”。
- 每条回答都能解释来源层级
- memory 具备 freshness / stale / conflict 状态
- 用户能一键标记错误记忆为过期或冲突
- 新增记忆不会无限膨胀，存在去重与人工确认机制
- 产品可以对“为什么这条结果可信”给出稳定解释
因为到了这一步，ContextAtlas 的核心承诺从：
“我能找到相关代码”
升级成：
“我能把代码、记忆和决策一起给你，并告诉你哪些可信、哪些可能过时、哪些互相冲突。”
这才是一个知识增强型开发工具真正的 1.0。
这一阶段对应原来的 90 天阶段。
适合定义成 v2.0，因为这不再只是“把单产品做成熟”，而是开始进入：
- 团队级运维
- 稳定发布
- 多仓库协作
- 组织级知识治理
也就是说，v2.0 代表的不是简单迭代，而是产品作用范围和运营复杂度上了一个台阶。
至少要能展示：
- 当前索引状态
- 上次成功时间
- 待处理队列长度
- 最近失败任务
- 当前快照版本
- 全量 / 增量模式
仓库已经有 SQLite 队列、daemon、快照写入、原子切换，所以这一步不是发明新能力，而是把已有能力变成运维可见性。
需要补齐：
- 仓库变动后的增量索引触发机制
- AST / embedding schema 变更时提示全量重建
- 记忆受影响范围提示
这决定了产品能否成为“日常可依赖系统”，而不是一次性分析工具。
当前检查范围内可以确认 release.yml 存在，说明发布动作已具备基础路径。
但如果要进入团队试点，必须把测试目录里已经存在的能力真正纳入门禁，例如：
- daemon / queue 相关测试
- memory / MCP / monitoring 相关测试
- release 前 smoke 检查
- 基础回归验证
否则很容易停留在“有测试文件，但产品发版前验证路径并不透明”的状态。
至少应包含一版管理指标：
- 查询成功率
- 空结果率
- 用户纠错率
- memory stale 比例
- 查询延迟
- 索引失败率
- 每仓库 / 每模块质量分布
这一层会让产品从“个人工具”过渡到“团队基础设施”。
如果要真正进入团队试点，建议补上：
- shared memory 与 personal memory 分层
- 组织级只读 project profile
- 决策记录审核人字段
- 跨项目 Hub 的权限边界与来源边界
- 产品能稳定处理日常 repo 变化，不需要频繁人工全量重建
- 发版前存在明确测试与 smoke gate
- 管理者能看见“是否在用、哪里不准、哪里在坏”
- 团队能够共享高价值 memory，但不会彼此污染
- 多仓库/多项目知识复用开始具备组织级约束
因为这里发生的变化，不只是“质量提升”，而是：
- 目标用户从个人扩展到团队
- 系统职责从问答扩展到持续运维
- 记忆系统从单仓库助手扩展到组织级知识层
这类变化足以支撑一次大版本升级的叙事。
如果资源有限，建议按下面顺序推进：
先把“接入 → 索引 → 提问 → 可解释结果”做成真正可演示、可日用的闭环。
原因：仓库能力已经很多，但主路径还不够收束。
补来源层级、freshness、冲突处理、写入治理。
原因：这个项目越强，越需要解释自己为什么可信。
补索引健康、增量更新、失败恢复、测试门禁、团队指标、共享记忆分层。
原因：这是把强能力产品化为团队级系统的最后一道门槛。
可以直接采用下面这组外部叙事：
可跑通主路径的预发布版本
- 默认入口
- 默认结果卡片
- 基础冷启动降级
可日用的预发布版本
- 主路径打磨完成
- 安装与命名体验统一
- 冷启动和索引状态表达稳定
可信的知识辅助版本
- 来源解释
- freshness / stale / conflict
- 受控写入
- 用户反馈闭环
可运维的团队试点版本
- 索引健康面板
- 增量更新策略
- 发布门禁
- 团队指标
- shared / personal memory 分层
如果只看技术能力，ContextAtlas 对应的这套系统已经远不止 0.0.x 水平。
但如果看“产品承诺”这件事：
- 主路径是否足够清晰
- 用户是否知道为什么结果可信
- 记忆是否会随时间变脏
- 产品身份是否统一
- 发布和运维是否足够稳定
那么现在直接把 30 / 60 / 90 天分别叫成 1.0 / 2.0 / 3.0，会显得过于激进。
更稳、更可信的版本映射是：
v0.8 / v0.9 → v1.0 → v2.0
其中：
- v0.8 / v0.9 解决“能不能顺畅用起来”
- v1.0 解决“能不能持续信任它”
- v2.0 解决“能不能作为团队系统运营起来”
这条路线既尊重当前仓库已经很强的工程现实，也避免过早承诺一个尚未完全产品化的 1.0。