返回 TraceWise 项目总览 · 交互图：系统 · 架构 / 核心 · 知识 · 副本 · 工作流 / 审核 · 决定 · 生命周期
项目复盘很容易写成一串功能清单：做了 Graph、接了模型、增加人审、拆出平台、补了恢复。这样的总结能说明工作量，却很难说明架构判断力。
TraceWise 开发过程中更有价值的部分，是几次结论被反例推翻。它们有的促成代码修复，有的只收窄公开说法，还有的明确留下“当前没有实现”的边界。
这篇文章选择八个讨论，不按提交顺序罗列，而是使用同一条审计脊柱：
原说法 → 最小反例 → 被破坏的不变量 → 修复或收窄 → 当前证据边界
讨论不是投票，而是让主张可以被推翻
这些结论不是因为某个角色“意见更大”而改变。一次有效讨论至少要把五件事说清楚：当前主张是什么，它依赖哪个不变量，谁拥有被修改的 Authority，什么最小输入可以推翻它，以及修正后允许怎样公开表达。
NIST AI RMF Core把清晰的角色、责任、沟通线路以及批判性和安全优先的文化列入治理要求；Google SRE 的可靠性测试章节则强调测试应减少特定不确定性，并考虑成本。它们不是 TraceWise 的认证材料，但帮助我们形成同一条讨论纪律：反对意见必须落到可检查的事实，测试必须对应真实风险，结论必须允许被新证据推翻。
在实践中，讨论按下面的责任分工收敛：
| 参与视角 | 需要贡献什么 | 不能用什么代替 |
|---|---|---|
| 产品视角 | 用户会依据该结论做什么决定 | 功能数量或界面完成度 |
| 领域/治理视角 | 谁拥有事实、谁审核、什么情况下授权失效 | 一句“最终由人负责” |
| 工程视角 | 真实输入、状态、写入、失败和恢复路径 | HTTP 200、日志文案或 mock 成功 |
| 反方视角 | 能够推翻当前大结论的最小反例 | 泛泛的风险提醒 |
| 交付视角 | 当前版本、证据状态、非目标和停止条件 | “后续再完善”的模糊承诺 |
下面八个案例因此不是意见记录，而是八次主张—证据—决策闭环。
1. 有 Planner 和 Verifier，就能叫 Multi-Agent 吗
原说法
项目存在 Planner、Worker、Verifier、Synthesizer 和多个 Persona，因此可以描述成“多 Agent 自治协作”。
最小反例
沿一次子图请求检查控制流：同一个 SubgraphOrchestratorService 在一个调用栈里规划子图，然后用普通 for 循环逐个分析。运行记录明确标记 execution=sequential。没有独立 Worker 状态、预算、取消、重启恢复或调度器。
修正
保留责任名称和阶段事件，但公开说法改为“可解释子图分析流水线”。Verifier 只检查 Evidence 缺口和启发式差异；confidence 不再描述成经过校准的正确率。Persona 被区分为对话视角和实体档案，不再当作自治 Agent 实例。
这次修正主要提高可信度，没有直接提升模型质量。
2. 有 graph_id，就能叫租户隔离吗
原说法
数据按 graph_id 和 Project/Scope 组织，因此系统具备租户隔离。
最小反例
graph_id 能选择逻辑数据分区，却不能回答：谁是 tenant owner？成员权限如何执行？跨项目读取是否被统一 IAM 阻止？凭据和后台任务是否沿用同一授权？
修正
graph_id 只描述逻辑分区。项目级 Authority Selector 负责决定哪个后端拥有写入权，也不等于 tenant security。生产 IAM、tenant/RBAC、Secret、TLS 和端到端越权验证继续保留为未完成边界。
这里没有“补一个权限标签就完成安全”的代码捷径。收窄声明本身就是正确结果。
技术解释图：Project、Graph 和 Authority Selector 组织产品边界，但不自动构成企业租户安全。
3. Snapshot 标记 compatible=true，就能叫备份恢复吗
原说法
项目可以导出和导入 Snapshot，因此具备备份恢复。
最小反例
早期 tracewise.project_snapshot.v1 包含多个项目分区，但导入只恢复节点、关系、Evidence 和规则；运行历史、Simulation、Agent 交互、报告、文档活动和 Timeline 没有恢复。浅层 preview 只检查 schema 标签，compatible=true 也不能发现 dangling reference、ID 冲突或执行中断。
被破坏的不变量
“可恢复”至少要求用户清楚哪些 Authority 会被还原、写入前能验证引用和冲突、失败后有可追踪状态，并且结果不会与源项目身份碰撞。
修复
产品将功能改名为“创建核心知识副本”，只承诺 Entity、Relation、Evidence 和 Rule。Preflight 明确 restored/omitted sections，绑定请求 fingerprint，检查引用、Scope、冲突和调用者身份，创建隔离 draft project，并保存 immutable applied 或 partial receipt。
技术解释图：核心知识副本有明确覆盖面；它不是完整 Backup、生产 Migration 或 DR。
4. 记录旧版本 ID，就能证明历史版本参与计算吗
原说法
Simulation 结果保存了用户传入的 entity_version_id，因此支持历史推演。
最小反例
创建 v1：status=at-risk，再创建 v2：status=on-track。请求显式选择 v1，旧实现虽然记录 v1 ID，却从实体的 latest 状态读取规则输入，最终按 v2 计算。
被破坏的不变量
历史身份不仅要进入日志，还必须驱动真正的权威读取和规则计算。
修复
服务从 SQLite Authority 精确解析每个 version ID，并把该版本状态传给规则。缺失、重复、跨 Graph 和实体不匹配全部返回 typed 422。未提供 ID 是独立的 latest 模式，并冻结实际解析出的版本；旧记录标注 legacy_unspecified。
同时，Simulation restore 被限定为读取已持久化运行，不再与 rerun 混为一谈。
5. approved=true，能代表人已经审核过当前变更吗
原说法
Proposal 上有批准状态，系统就可以执行。
最小反例
审核页面打开后，Graph、Evidence 或 Policy 发生变化；Proposal 内容也可能被替换。一个裸 approved=true 无法说明审核者看过的是哪份 Proposal、哪版 Graph、哪些 Evidence。
修复
一次审核被建模为不可变 tracewise.review-decision.v1，绑定 Project、Graph、Scope、Proposal fingerprint、Graph revision/fingerprint、Evidence IDs/fingerprint、Policy、Reviewer、decision、reason 和 replay identity。
审核到达时重读权威状态，真正执行前再次重读。Evidence 或 Graph 漂移使旧决定 stale，而不是把新内容偷偷拼入旧批准。
6. Foundation 失败，能宣称整体回滚吗
原说法
Graph 和 Foundation 属于同一业务动作，因此任一失败整体回滚。
最小反例
受控验收中，TraceWise Graph 已成功写入，随后 Foundation PostgreSQL 真实不可用。没有跨 SQLite/PostgreSQL/Graph store 的统一事务，应用层无法让已观察到的 Graph 写入“从未发生”。
修复
产品保留 applied_with_foundation_pending，记录失败原因与同一 ReviewDecision。数据库恢复后显式重试原决定，原 sync record 更新为 applied；再次重试返回 deduplicated。AF-X01 项目则使用 Proposal/outbox/Executor/recovery state machine，不能与产品 Authority 路径混写。
技术解释图：跨存储失败进入显式恢复状态，不伪造原子回滚。
7. Graph 中有 Relation，就等于接入 Foundation Relation 吗
原说法
TraceWise 能审核关系变更，Foundation 又有 Relation 能力，因此可以宣称 Relation lifecycle 已集成。
最小反例
独立 relation-only 验收中，approve 确实写入一条 TraceWise 有向 Graph edge，reject 不写。但 Foundation receipts 仍然只针对 Memory；直接存储读取找到零条 Relation event，公共计划返回 relation_evolution_variant_required。
被破坏的不变量
当前 RelationMutation 只有动作、端点、relation label、reason 和 confidence，缺少 relation-level Evidence、valid time 和 source authority。不能从 Proposal 时间猜 valid_from，也不能把 Proposal-wide Evidence 冒充 Relation Authority。
结论
当前公开能力明确写成“TraceWise Graph + Foundation Memory”。Relation consumption 是 verified gap，需要新的产品决策和合法 Variant，而不是补一条适配器调用。
8. 没有流量地等待 24 小时，能叫 soak 吗
原说法
Stage B 需要空闲运行满 24 小时，达到后即可认为稳定。
最小反例
环境中没有生产流量。系统在 24 小时内没有执行新请求、没有遇到新的并发和故障，时间经过本身没有增加任何稳定性证据。
修正
observation_in_progress 与空闲 24 小时门槛被标记为 superseded。保留真正发生过的证据：24 次受控 Authority 操作、重启 reload、exact replay、不可用与恢复、clone rehearsal、旧写阻断、原项目零变化和响应式浏览器验收。
生产流量、长期 soak 和 canary 仍然未验证，但不再阻塞已经完成的受控本地 vertical slice。
这些讨论如何改变开发方法
八个问题表面不同，背后共享四条方法：
先找最小反例
不要先写大规模方案。用两个不同 ID 的项目打破身份偶然性；用 v1/v2 状态打破伪历史；让真实 PostgreSQL 中断打破原子回滚想象；直接查 Relation store 打破“Graph edge 等于 Relation”的推断。
找最早变假的不变量
UI 文案、错误码和成功响应都可能只是表象。身份混淆要修在 Authority contract，历史错误要修在版本读取，Snapshot 假绿要修在 preflight 和 import receipt，而不是增加一个提示框。
允许新证据推翻旧说法
旧 acceptance 不必删除，但必须标记 superseded。当前 PROJECT_STATUS、ROADMAP 和 EVIDENCE_INDEX 区分 verified、code-confirmed、partial、blocked 和 superseded，避免把多个时期的证据拼成一个更强结论。
让“没有实现”成为可交付边界
Multi-Agent、tenant security、完整 Backup/DR、Foundation Relation、自动跨存储回滚、模型质量和生产 soak 都没有因为不完整而被藏起来。边界被写进产品文案、typed status、验收和文章 claims。
把讨论结果写进权威位置
口头达成一致不算完成。产品事实进入 PROJECT_STATUS，未完成工作进入 ROADMAP，运行和验收材料进入 EVIDENCE_INDEX，架构所有权进入 ADR 或机器可读合同，旧结论保留为 superseded evidence。这样下一次讨论面对的是同一份当前状态，而不是每个人记忆中的不同版本。
为继续与停止设置条件
如果最小反例、相邻负例、真实 Authority 状态和用户工作流都已覆盖，继续增加同类测试只会提高成本而不降低当前风险，就应停止该切片。反过来，如果生产流量、合规、HA/DR 或模型效果需要新环境和数据，则应作为独立目标重新授权，而不是偷偷塞进既有工作。
这些反例最终留下了什么
TraceWise 的工程价值不取决于页面数量、Graph 节点或测试总数。更重要的是，每当一个术语比证据更强时，项目能否给出反例、找到最早失真的层、修复权威契约，并在必要时主动降低声明。
八次讨论最终形成同一条原则：
保留历史证据；新反例改变前提时，更新当前合同，并留下决定变化的依据。
这也是 TraceWise 与一般 AI 演示项目最明显的区别：它不仅展示“系统能做什么”，还保存“为什么现在只能这样说”。