准确理解可靠性声明
理解哪些能力经过测试、有哪些证据，以及哪些生产范围仍被明确标记为未验证。
声明原则
每项可靠性声明都必须同时理解其范围与证据。“支持服务商 X”可能只代表可以编译、 确定性协议测试通过、在线冒烟通过，或已经在生产观察；它们并不等价。
Runifold 仍处于 Pre-alpha。请预期 API 会演进，认真审核迁移，并固定应用使用的准确 Crate 版本。
证据矩阵
为每条关键路径记录证据：
| 声明 | 必要证据 |
|---|---|
| 模型编码正确 | 确定性契约测试 |
| 真实端点兼容 | 带日期的在线冒烟 |
| 取消可传播 | 故障注入测试 |
| 持久化可恢复 | Worker 丢失和 Lease 过期测试 |
| 外部 Effect 安全 | 幂等或对账测试 |
证据应靠近发布产物保存，让后来者可以复现。
建立发布基线
固定准确的 Pre-1.0 版本，只启用应用实际使用的 Feature：
[dependencies]
runifold = { version = "=0.9.0", features = ["sqlite-bundled"] }
runifold-providers = { version = "=0.9.0", features = ["openai"] }每次修改都运行确定性基线：
cargo fmt --check
cargo check --locked --all-targets
cargo test --locked
cargo clippy --locked --all-targets -- -D warnings然后补充编译器无法提供的应用证据：每条协议路径的脱敏 Cassette、准确 Model ID 的 有预算在线冒烟、强制取消、Worker Loss 恢复与 Effect 对账。编译通过只能证明类型 兼容，不能证明端点或行为兼容。
基准测试
只有同时说明负载、硬件、Runtime、并发、Feature 与分位数定义时，Benchmark 才有 意义。服务商网络延迟通常远高于本地编排的微基准耗时。
测量用户真正关心的指标：首事件时间、完整延迟、资源使用、恢复时间与成本。同一 Fixture 下比较不同版本。
Pre-alpha 使用预期
投入生产前：
- 固定依赖并查看 Release Notes；
- 自行验证服务商与部署平台；
- 设置预算、Deadline 与显式能力；
- 测试取消、Worker 丢失和不确定 Effect；
- 保留回滚路径，并在事故中检查 Journal。
文档契约与实际行为不一致时，请提交包含最小复现的 Issue。
生产就绪工作表
| 问题 | 需要保留的证据 | 阻止发布的情况 |
|---|---|---|
| 准确模型是否支持 Tool / Stream / Schema？ | 带日期的在线冒烟 | Capability 不支持或 Unknown |
| 取消是否终止本地工作并限制远端暴露？ | 注入断连 / Deadline 测试 | 无界继续执行 |
| 进程退出后 Task 是否恢复？ | Kill Worker 恢复 Fixture | 重复已提交 Step 或 Usage 丢失 |
| 外部写入能否安全重试？ | 幂等 / 对账测试 | 把 Ambiguous 当成 Failed |
| Operator 能否解释一次 Run？ | 关联 Journal + Trace 样本 | 没有终止证据 |
| Release 能否回滚？ | 已测试 Binary / Schema / Definition 方案 | 旧 Task 依赖已删除代码 |
结果应同时记录 Cargo Lockfile、Rust 版本、Target、Feature、Provider / Model ID、 测试时间和 Fixture Revision。其中任一输入变化，都要重跑受影响行。
最小复现模板
实际行为与文档契约不一致时，把问题缩减成一个固定版本的 Cargo.toml、一个源文件、
准确命令、预期结果、实际类型化错误、Target / Runtime，以及测试使用 Cassette 还是
真实端点。移除凭证、Prompt、客户正文、Provider Request ID 与签名 URL。