心图

很多 Agent 协作失败，不是模型不够聪明，而是项目真相散落在聊天记录里：谁授权了这次修改、当前目标是功能还是重构、哪些决策被后来的实现推翻，往往只在一轮轮对话中隐约存在。一旦会话关闭或换一个 Agent 窗口，后来的执行者只能重新猜测，甚至从错误的中间状态继续改代码。WishGraph 要做的是把人类意图编译成一份可审计的项目状态图，让不确定性、权限、证据和当前项目真相落在仓库文件中。

核心能力

• 项目激活而不是全局可用：安装技能只代表 Agent 具备能力；只有当前 Git 根目录存在 .wishgraph/config.json，且 mode 为 warn 或 enforce 时，WishGraph 才真正介入项目。缺少配置、mode: off，或用户只是说 开始讨论，都不会触发项目初始化。
• 讨论与执行分离：讨论阶段负责澄清意图、产出可观察行为、验收标准、非目标和关键决策；正式 Task 则交给独立 Worker，Discussion 不会直接实现业务代码、跑构建，也不会变成 Worker 的兜底执行者。
• 最小持久化状态图：复用仓库中已有的项目事实，不另建平行记忆；只创建必要的 Task、Revision、Claim、Run Report 等结构化记录，形成从意图到结果的可追踪链路。
• 双模式治理：enforce 会在 Claim、Hook receipt、Run、transition grant 等机械闸门上做强约束；warn 保留可见 Worker 与证据链，但不会因为宿主缺少 Hook 或 Claim 自动化而阻断普通任务。

关键流程

1. 检查仓库，读取兼容的项目事实，避免复制已有记忆。
2. 把用户意图编译成行为、验收标准、非目标和实质决策。
3. 创建最小 durable 状态图与有边界的可执行工作单元。
4. 分类工作，记录唯一预期的 expected_transition，并取得明确人类授权。
5. 从 Discussion 路由到独立 Worker；若宿主允许，也可绑定一个明确指定的中性窗口，但不重复创建 Worker。
6. 要求限定范围的实现、预定验证和不可变证据；严格模式下完成 Claim closeout。
7. 所有终止结果自动进入 Discussion 内的 Integration；只有实质决策才询问用户。
8. 展示集成结果、证据、剩余风险和下一步，不抹除历史。

适用边界

WishGraph 适合需要跨 Agent、跨会话保持项目真相的研发流程，尤其是代码库持续演进、多人或多 Agent 协作、变更需要审计的场景。它不是聊天摘要器，也不会替代 Git 或 CI：Hook 是机械闸门和状态读取器，不是产品决策者；read gate 在无法拦截全部读取路径的宿主上能力有限。首次启用需要显式命名 WishGraph，并明确项目里哪些 Agent 参与；之后应重开会话，再通过 开始讨论 进入正式流程。enforce 要求宿主 Adapter、Hook receipt 与实时 Claim；warn 可以在自动化缺失时继续，但仍要求 Task 范围、验证计划、Run Report 和结果 commit 完整可查。