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 定義保留在倉庫中供歷史參考，但不再接受任何更新