在 ADR、spec、epic、story 或设计方案写好或修改之后
找出弱点，对照出处核实每一条论断，并追问计划可能怎样失败。不说客套话。
opus · max.projectstore / 方法 / 1
一个内含独立检查的循环。
智能体写代码很快，重新决定已经定下的事也一样快：每个新会话都是空白开始。解决办法不是更聪明的智能体，而是“收集上下文 → 行动 → 验证”，并且针对整个项目运行，而不只针对代码。
循环
八个步骤。其中两步是由没有参与写草稿的智能体做的检查。
- 01你说出想要什么。智能体先打开一个工件，再打开编辑器。
- 02需要决策时写 ADR，工作写成 epic 和 story，“怎么做”不明显时写 spec。先预览，在你说“是”之后写入。
- 03一个全新上下文、与草稿没有利害关系的 critic 会挑它的毛病。预期会得到“revise”。
- 04你批准修正。工件被标记为已评审，进入待办池。
- 05一个智能体接手 story。planner 查看早先的 epic 是怎样落到代码里的，并指出这次改动应放在哪里。
- 06按 story 的计划写代码和测试。
- 07一个全新上下文的 reviewer 对照每条验收标准检查 diff，并要求提供证据。
- 08完成，每条标准下都有证据。看板、关系图和代码地图随之重建。
智能体
6 个智能体。 除一个外，其余都只能读。
顾问们负责检查、规划和整理，不改动任何东西。唯一的 clerk 在你说“是”之后，只保存你批准的内容。
在 story 开工之前（story plan）
查看早先的 epic 在代码中的位置。指出改动应放在哪里、复用什么、需要注意什么，以及按什么顺序来做。
opus · max写完代码后，在提交或 story close 之前
要求每条验收标准都有证据，包括 spec 中的标准。然后检查正确性、回归和测试。
opus · max每隔一段时间、发布之前、vault 快速增长之后
找出任何规则都抓不住的问题：与已接受的 ADR 相矛盾的研究笔记、重复内容、缺失的链接、可以归档的文件。
opus · max绑定已有代码库之后运行一次
从代码、配置文件和 git 历史中找出没人写下来的决策，并附上证据，建议为它们补写 ADR。
opus · max只在命令流程内，只在你说“是”之后
原样保存你批准的内容，不多一字。然后重建看板并运行检查。不自行撰写任何内容，也不提任何问题。
sonnet · max默认模型针对的是 Claude Code。在 Codex 中，每个角色都是一个同名 skill，它会请求 Codex 启动该角色，例如 $projectstore-critic 对应 critic 角色；除非你另行设置，它使用会话的模型。
防护
靠机制维系，而不是靠自觉。
没有 story，就提醒
智能体在没有打开任何 story 的情况下开始改代码时，会被提醒先打开一个。功能规模的改动从 vault 开始。
未经评审，就一直标着“未评审”
需要评审的工件带着 review_status: pending，直到应用了 critic 的评审。“尚未评审”是工具能读取的状态，而不是要靠人去记。
不含 AI 的 doctor
doctor 以确定性的方式检查 vault 在机械层面的一致性。在 CI 中运行时不需要智能体，也不消耗 token。
该看哪里，自动生成
graph.md 记录每个工件双向的链接；code-map.md 说明每个 epic 的代码在哪里。做架构选择之前，智能体会先被指向 ADR 索引。
/compact 之后，vault 回来了
在 Claude Code 中，你运行 /compact 之后，会话会重新带着 vault 的概况开始，并带上在此之前对话中涉及的 vault 文件。
第二个会话会收到警告
当另一个会话正在处理同一个 vault 时，新启动的会话开头会出现多会话警告：创建任何新内容之前先搜索。
完成意味着有证明
story 关闭时，每条标准下都有证据。
--- type: story epic: "CHECKOUT" title: "结账时列出已保存的银行卡" status: done code_refs: ["src/billing/cards/", "tests/cards.test.ts"] closed_at: "2026-07-14T16:02:11Z" --- ## 验收标准 - [x] 已保存的银行卡排在最前 — 证据：tests/cards.test.ts:21 - [x] 银行卡被拒时显示银行给出的原因 — 证据：tests/cards.test.ts:58 - [x] 卡号不会进入日志 — 证据：tests/cards.test.ts:73
planner 在写代码之前说明了改动应放在哪里，计划在你说“是”之后写进了 story；reviewer 在代码写完后，对照每条标准检查了 diff。每一行证明都是一个测试、一条运行过的命令或一行代码。
任何智能体都可以读取这份记录，装不装插件都行：通过 CLI（它以 JSON 作答，不消耗 token），或通过 MCP 服务器的 8 个只读工具。
- orientation
- search
- status
- get_artifact
- lineage
- neighbors
- code_refs
- doctor
细则
细则
- 运行这个循环会消耗 token：草稿、critic 和 reviewer 都使用你已经在付费的模型。README 对此有实测数据。
- 在 Claude Code 中，critic 和 reviewer 是上下文全新的独立智能体。在 Codex 中，这些角色是 skill。
- ProjectStore 是共享的项目上下文，也是一种工作方式。它不是智能体编排器：启动智能体是你的 harness 的职责。