3 版本演进路线

第三章：版本演进路线

本章定义 CAP 协议的版本演进路线，明确 v1 版本的功能范围与排除项，建立版本号命名规则和兼容性策略，并描述从草案到正式版本的发布流程。版本路线为协议的迭代开发和社区协作提供清晰的路径指引。

3.1 v1 版本功能范围

CAP 协议 v1 版本聚焦于建立完整的终端控制权限管理基础框架，包含以下 6 种核心能力：

1. 离线授权（Authorization_Descriptor）：v1 版本的核心机制。实现 Authorization_Descriptor 的完整生命周期管理，包括签发、本地存储、校验、撤销和更新。终端在离线状态下可通过本地存储的 Authorization_Descriptor 独立完成授权校验，保障 Fay 在无网络环境下的基本可用性。v1 版本将实现完整的信任链模型和本地撤销列表机制。

2. 在线票据（Trusted_Ticket）：v1 版本的补充机制。实现联网环境下的实时授权签发和撤销状态查询能力，支持 Trusted_Ticket 到本地 Authorization_Descriptor 格式的转换，以及在线到离线的平滑降级策略。v1 版本确保在线票据与离线授权之间的协同工作。

3. 会话管理（Session lifecycle）：实现控制会话的完整生命周期管理，覆盖创建、活跃和终止三个阶段。v1 版本支持 Session 与 Terminal_Resource 的一对一绑定关系，实现主动释放、超时终止和撤销终止三种会话终止方式。

4. 控制权交接策略（Handover_Policy）：实现多控制方之间的控制权转移能力，覆盖 Fay 之间以及 Fay 与人类用户之间的交接场景。v1 版本支持三种策略类型（优先级规则脚本、AI 模型实时判定、人类用户决策），保证交接过程的原子性，并实现超时回滚机制。

5. 存活检测（Liveness_Detection）：实现基于长连接与应用层心跳结合的会话存活检测机制。v1 版本支持双重判定逻辑（长连接断开且心跳超时同时满足），可配置的心跳间隔和超时阈值，以及失效会话的自动终止和资源回收。

6. 资源访问模式（Resource_Access_Mode）：实现按操作类型的资源访问分级管理，支持 read、write、execute、configure 四种访问模式。v1 版本实现完整的读写锁模型，支持 read 模式的多方并发访问和 write、execute、configure 模式的排他控制。

以上 6 种核心能力构成 v1 版本的完整功能集，为 iFay 体系中智能代理安全接管终端提供基础的控制权限框架。

3.2 v1 明确排除的功能

以下功能明确不包含在 v1 版本中，标注为未来版本的候选项：

排除功能	说明	候选版本
跨终端会话迁移	将活跃 Session 从一个终端迁移到另一个终端，保持会话状态连续性	v2+
多终端协同授权	多个终端之间的授权状态同步和协同校验机制	v2+
授权委托链（Delegation Chain）	Fay 将自身获得的部分授权委托给其他 Fay 的级联授权机制	v2+
细粒度资源访问控制（ABAC）	基于属性的访问控制策略，支持更复杂的资源访问条件表达	v2+
审计日志标准化格式	统一的审计日志（Audit_Logger）输出格式和查询接口规范	v2+
协议消息加密传输规范	对 CAP 协议消息在网络传输层的加密方式和密钥协商流程的标准化定义	v2+
离线授权的分布式撤销共识	多终端之间在离线环境下对撤销状态达成一致的共识机制	v3+
动态权限提升（Session 内）	在活跃 Session 生命周期内动态提升访问权限而无需创建新 Session	v3+

v1 版本遵循"先建立基础、再扩展能力"的原则，优先确保 6 种核心能力的完整性和稳定性，将高级功能留给后续版本迭代。

3.3 版本号命名规则与兼容性策略

版本号命名规则

CAP 协议采用语义化版本号（Semantic Versioning）格式：MAJOR.MINOR.PATCH

• MAJOR（主版本号）：当协议发生不向后兼容的重大变更时递增。例如核心消息格式的结构性调整、授权校验流程的根本性改变。主版本号变更意味着现有实现需要进行适配修改
• MINOR（次版本号）：当协议新增向后兼容的功能或能力时递增。例如新增一种资源访问模式、扩展 Handover_Policy 的策略类型。次版本号变更不影响现有实现的正常运行
• PATCH（修订号）：当协议进行向后兼容的错误修正或文档澄清时递增。例如修正规范文档中的歧义描述、补充边界情况的处理说明

草案版本使用 draft 标识，不附带版本号。草案版本不承诺任何兼容性保证，可随时进行破坏性变更。

正式发布的版本号示例：1.0.0、1.1.0、1.1.1、2.0.0

兼容性策略

CAP 协议的兼容性策略遵循以下原则：

• 同一主版本内向后兼容：在同一 MAJOR 版本内，新版本的协议实现必须能够处理旧版本的协议消息。例如，实现了 v1.2.0 的终端必须能够处理 v1.0.0 格式的 Authorization_Descriptor
• 主版本间不保证兼容：不同 MAJOR 版本之间不保证向后兼容。当主版本号递增时，协议规范将明确列出所有破坏性变更和迁移指南
• Schema 版本与协议版本对齐：每个协议版本对应一个 Schema 版本，Schema 文件存放在以协议版本号命名的目录下（如 schema/2025-10-25/），确保版本对应关系清晰可追溯
• 最低支持版本声明：协议实现可声明其支持的最低协议版本，低于该版本的协议消息将被拒绝处理

3.4 从草案到正式版本的发布流程

CAP 协议从草案到正式版本的发布遵循以下流程：

阶段一：草案（Draft）

• 协议规范和 Schema 定义存放在 draft/ 目录下（如 schema/draft/、specification/draft/）
• 草案阶段允许频繁的破坏性变更，不承诺兼容性
• 草案内容接受社区反馈和评审，持续迭代优化
• 草案阶段的文档和 Schema 可随时更新，无需遵循版本号递增规则

阶段二：候选发布（Release Candidate）

• 当草案内容趋于稳定，进入候选发布阶段
• 候选发布版本使用 -rc.N 后缀标识（如 1.0.0-rc.1）
• 候选发布阶段仅接受错误修正和文档澄清，不接受新功能
• 候选发布版本需通过完整的测试验证，包括 Schema 校验、多语言文档结构等价性检查和属性测试

阶段三：正式发布（Release）

• 候选发布版本经过充分验证后，移除 -rc.N 后缀，成为正式版本
• 正式版本的协议规范和 Schema 定义从 draft/ 目录复制到以版本日期命名的目录下（如 schema/2025-10-25/）
• 正式版本发布后，该版本的协议规范和 Schema 定义不再修改（immutable），任何变更通过新版本发布
• 正式版本发布时，所有 9 种语言的蓝图文档和协议规范必须同步完成并通过结构等价性验证

阶段四：维护（Maintenance）

• 正式版本发布后进入维护阶段，仅接受 PATCH 级别的错误修正
• 当新的 MAJOR 或 MINOR 版本发布后，旧版本进入有限维护期，最终标记为废弃（deprecated）
• 废弃版本的文档和 Schema 定义保留在仓库中供历史参考，但不再接受任何更新