16 非目标¶
目的¶
本章明确说明当前版本不试图解决的问题。
核心要求¶
非目标必须被清晰记录，以防止架构漂移和范围失控。
总体原则¶
本规范与参考仓库在 v0.1 中刻意保持收敛。当前目标是建立连贯的 canonical 协议层、规范性 sidecar 工件、兼容导出规则，以及可运行的参考工具链，而不是覆盖完整量子操作系统的全部问题空间。
v0.1 的明确非目标¶
以下内容不属于当前版本范围：
- 与真实硬件的生产级集成
- 完整的 OpenQASM 解析器或完整 OpenQASM 3 实现
- 面向全部后端家族的通用脉冲编译器
- 完整的路由、放置与优化流水线
- 生产级运行时编排或集群调度
- 厂商认证、合规声明或正式标准组织采纳
- GUI 工具、控制台或可视化运营界面
此外，v0.1 也不试图一次性标准化扩展讨论中提到的所有未来工件，例如 routing patch、diagnostics trace 或 backend capability catalog。
架构澄清¶
本仓库不主张 OpenQASM 单独就能承载全部运行时语义，也不主张 QOS 可以被简化成一种文本语言。QOS 仍然是 systems 与 orchestration 视角，UQCI 仍然是 canonical protocol 层，OpenQASM 仍然是 compatibility / exchange 层。
同样，本仓库也不声称一种物理控制词汇可以抹平超导、离子阱、中性原子、光子等平台之间的物理差异。
本仓库同样不会把 Mock backend 的存在解读为“真实硬件集成问题已经解决”。Mock 的作用是验证架构，而不是替代生产控制栈。
文档与范围纪律¶
从 Word 草案迁移到仓库原生 Markdown，并不意味着所有附录、长清单与说明性示例都应进入规范正文。v0.1 的范围纪律体现为：
- 完整机器可读 Schema 保留在仓库 Schema 文件中
- 可运行示例保留在
examples/ - backend 实现细节保留在代码与后端文档中
- 主规范正文聚焦于架构、契约与工件角色
为什么必须写清楚¶
这些非目标的明确化，是为了避免两类常见偏差：
- 试图把所有内容都压缩进单一文本导出格式
- 在过早阶段让 canonical 核心过度适配某一种后端
把边界写清楚，才能让仓库保持可实现、可测试，也更适合未来标准化讨论。