OPALL

OPALL-E · EVIDENCE INDEX · 证据索引

证据只支撑它能支撑的 claim

七类证据的编目与边界

OPALL 用证据让项目可以被追问。每种证据只能证明一小段事实,不能被拿来替代完整能力声明。索引的核心是限制,而不是夸大。

01README · 项目的入口README

能证明什么:项目有公开说明、启动路径和基本使用语境。

不能证明什么:不能证明运行质量、正确性或完成度。

应该如何使用:把具体 claim 链接到 README 的具体段落,并保留限制说明。

02架构说明 · 系统形状ARCHITECTURE NOTE

能证明什么:组件、边界、数据流或控制流经过设计。

不能证明什么:不能证明所有组件都已经实现。

应该如何使用:配合 implemented、prototype、planned、not claimed 状态标签。

03执行轨迹与产物 · 检查一次运行TRACE & ARTIFACT

能证明什么:某个任务产生了可见事件、文件、日志、报告或输出。

不能证明什么:没有验证结果时,不能证明输出正确。

应该如何使用:把每个 artifact 连接到对应任务和 quality gate。

04测试结果 · 验证记录TEST RESULT

能证明什么:某个命令或检查在特定时间通过或失败。

不能证明什么:不能证明产品已经完整可用,也不能覆盖所有失败模式。

应该如何使用:写清命令、范围、结果和已知缺口。

05截图 · 可见状态SCREENSHOT

能证明什么:某个 UI 或产物在特定状态下存在。

不能证明什么:不能证明稳定性、正确性或后端行为。

应该如何使用:和日志、测试、边界说明一起使用,不单独当作证据终点。

06回放 · 复盘路径REPLAY

能证明什么:某个工作流可以在特定条件下被检查或重复。

不能证明什么:不能证明它适用于所有输入或所有用户。

应该如何使用:写清数据集、环境、限制和预期检查。

07边界声明 · 说明不声称什么BOUNDARY STATEMENT

能证明什么:项目区分了证据、原型和计划。

不能证明什么:边界声明本身不能证明技术实现。

应该如何使用:每个重要 claim 附近都要放边界。