你的应用的测试知识
Hover 关于你的应用推导出的一切，都存放在项目根目录下的 .hover/ 里，随你的代码一起提交。随着时间推移，它会成为你的应用不断累积的测试知识：一份记录你各条流程的 Business Map，加上此前运行学到的规则，让测试套件保持自我认知，并随你的应用成长而越来越聪明。
.hover/ 下有什么
| 路径 | 它是什么 |
|---|---|
hover-map.md | 业务地图——一份按领域分组的清单，列出你应用的各条业务线，每条要么标记为已覆盖（[x]）并附上它生成的 spec，要么标记为未覆盖（[ ]）。agent 在每次运行时都会读取并扩展它；它同时充当大型应用的规划文档。 |
memory/ | 记住的规则——持久的业务规则、预期行为、校验规则，以及 agent 通过 record_fact 记录下来的访问策略。只存规则——绝不存 secret 或个人数据。 |
sidecars/<slug>.json | 每个 crystallize 出来的 spec 对应的结构化 SpecStep[] 记录——即 优化 pass 读取的机器可读记录。 |
cache/ | 可丢弃的工作数据（例如 cache/optimized/ 下的优化候选版本）。 |
crystallize 出来的 spec 本身存放在 __vibe_tests__/，不在 .hover/ 下。
重新提问前先回忆
在一次运行开始时，agent 会调用 recall_business_knowledge 并读取 hover-map.md，然后把两者都当作事实依据——这样它就不会重新问一个此前运行已经确定过的问题，并且会接着地图往下走，而不是从头再来。当你确认一条持久规则（"viewer 不能编辑其他用户的帖子"）时，agent 会调用 record_fact 把它持久化，供未来每一次运行使用。
为什么它归你所有且可携带
.hover/ 是你仓库里纯粹的 Markdown 和 JSON。没有托管数据库、没有账户、也没有上传通道——你的应用累积起来的测试知识是你的，与它所描述的代码一起版本化。这是护城河的支柱：制品（你的 spec）加上维护它们的知识，两者都归你所有。
哪些内置随包发布 vs 哪些存在你的仓库里
那份教会优化 pass 的 probe / seed 目录是内置随包发布的。落到 你的 .hover/ 里的，只有 agent 关于 你的 应用学到的东西——地图、记住的规则，以及各 spec 的 sidecar。
计划中：更深的记忆
一个更丰富的记忆层——一张把流程、页面以及它们触及的 endpoint 连接起来的关系图，加上覆盖缺口检测——已在 路线图 上。地图和记住的规则今天就已发布。