17 路线图¶
目的¶
本章定义未来版本的阶段性演进方向。
核心要求¶
路线图必须在保持架构连续性的同时,为未来一致性层、运行时层与后端扩展预留空间。
路线图原则¶
路线图的演进方式应当是在既有架构上逐步加深,而不是频繁改写核心定义。未来版本应优先增强一致性、诊断能力、后端覆盖面与运行能力,同时保持 UQCI IR 的 canonical 地位以及 sidecar 工件的规范性角色。
v0.1¶
首个公开版本聚焦于与当前仓库形态直接对应的基础能力:
- UQCI 程序与 sidecar 工件的强类型模型
- Bundle 读写与校验辅助
- 与模型对齐的 JSON Schema
- OpenQASM 兼容导出配置
- 可运行的超导与中性原子 Mock 后端
- 仓库原生测试、文档与 CLI 命令
这一阶段有意保持收敛。它的目标,是让规范变成可执行、可检查的参考实现,而不是过早宣称生产就绪。
v0.2¶
下一阶段宜在保持轻量的前提下增强工程深度,建议重点包括:
- 可选的离子阱 Mock 后端
- 更丰富的诊断与 trace 工件
- 更多 Bundle 检查与 patching 工具
- 更广的兼容导出覆盖范围
- 后端能力发现与报告机制
这些方向与当前仓库中的扩展预留保持一致,并且能够在不改变既有架构 doctrine 的前提下逐步引入。
v0.3 及之后¶
更长期的方向可以包括:
- 面向真实硬件环境的实验性适配器
- 调度与路由原型模块
- 更完整的校准生命周期工作流
- 面向第三方实现的一致性测试套件
- 超出当前仓库范围的可选运行时编排原型
如果未来推进这些方向,也应建立在现有 canonical 核心之上,而不是把架构重心重新放回某个特定后端或某个导出格式。
面向发布的指导¶
参考草案建议同时发布规范文档、机器可读 Schema、参考实现和示例 Bundle。当前仓库的路线图与这一建议是一致的:
- Markdown 章节承担仓库原生规范角色
- JSON Schema 文件承担机器可读工件层
- Python 模块承担参考实现层
- 示例 Bundle 与兼容导出承担可运行演示层
稳定性规则¶
未来版本应将以下内容视为连续性锚点:
- QOS 是 runtime 与 systems 视角
- UQCI 是 canonical protocol 层
- OpenQASM 是 compatibility 与 exchange 层
DeviceSpec、CalSet、Manifest、Bundle是规范性 sidecar 工件
任何会削弱这些锚点的改动,都应被视为架构级修订,而不是普通功能演进。