# Protocol 0.2 升級路線圖 — r3 / sync-4 | HelmLoop

> HelmLoop 為 AI Agent 工作流明確定義授權、證據、晉級與成果邊界。了解可執行的 0.1 候選版本，以及規劃中的 0.2 協定。

Source: https://helmloop.dev/zh-Hant/roadmap.html

Protocol 0.1 已有八種 record schemas、確定性的六軸 reducer、CLI 與兩個 fixture observation adapters。這些是本地實作產物，尚不代表公開套件發布或真實 runtime 認證。

0.2 計畫新增 assurance 軸、授權生命週期事件、criterion 綁定的成果觀測，以及版本化證據採認。這些能力目前仍是 r3 / sync-4 的規劃目標。

Plan: helmloop-v02-plan-20260915-r3 / sync-4; 2026-09-16; PROPOSED

## 十種 records・七軸判定

新增 AuthorityEventV1、OutcomeObservationV1，並讓 assurance 與 evidence 分開判定。

## 確定性的內容承諾

版本化 JCS / SHA-256 profile、精確引用綁定與獨立 JS/Python oracle，同時保留 0.1 原始 bytes 與 readers。

## 當次證據採認

依目前 subject、policy 與 dependencies 重新檢查證據；採用舊結果不會繼承動作授權。

## 停止與復原

實體停止、資源清理與 effect 對帳分開；送出不明時先 query、reconcile，再決定重試。

## 獨立 CLI

規劃離線 helmloop try，真正執行 PASS 與預期 HOLD 案例，安裝完成後的 smoke 目標為 90 秒內。

## 限定範圍的 conformance

兩個 mock adapters 覆蓋 C0–C4，一個 exact real binding 以 C0–C5 為目標。每項主張保留證據類別與限制。

## 交付順序

- S0: 基線與 wire freeze — 規劃中・尚未發布
- S1: 0.2 純核心 — 規劃中・尚未發布
- S2: 獨立 oracle — 規劃中・尚未發布
- S3: 兩個 mock adapters — 規劃中・尚未發布
- S4: CLI 與套件 — 規劃中・尚未發布
- S5: 一個 real binding — 規劃中・尚未發布
- S6: 文件與發行候選 — 規劃中・尚未發布

所有階段皆為規劃中。Canonical/schema freeze 後，oracle 可與核心並行；介面穩定後，CLI／套件可與 mock conformance 並行。

## 兩個套件，各有責任

### Neutral core

規劃採 Apache-2.0：schemas、純 evaluator、conformance 格式與離線 CLI，不含 scheduler、effect runner 或 Better Workflows 依賴。

### Better Workflows binding

規劃採 AGPL-3.0-only：版本化 mapping 與 host 驗證接線。依賴方向固定為 binding → neutral core。這是套件邊界規劃，不代表分發權利查核已完成。

## 與 V5 的互通接縫

r3 sync-4 記錄 Better Workflows typed-digest parser 已有 bounded 修正。Current profile v3 / mapper v3 接受 typed references；legacy profile v1 / mapper v2 保留裸 hex reader。完整 HelmLoop 0.2 互通仍在規劃。

## C0–C5 分別證明什麼

- C0: 分類、manifest 與文件一致性
- C1: 原始碼、套件與安裝 bytes 身份
- C2: 聲明範圍內的 account、host/session、provider/model assurance
- C3: Runtime 限制、取消與自有資源清理
- C4: 契約、授權、動作與對帳的端到端驗證
- C5: Exact live binding 的可信 attestation 與撤銷驗證

## 規劃中的十種 record types

- OutcomeContractV1
- AuthorityGrantV1
- ExecutionReceiptV1
- EvidenceRecordV1
- AssuranceDecisionV1
- PromotionDecisionV1
- ReconciliationRecordV1
- LearningSignalV1
- AuthorityEventV1
- OutcomeObservationV1

## 規劃中的七個判定軸

- execution
- evidence
- assurance
- authority
- promotion
- reconciliation
- observedOutcome

## 六種目標，各有判定條件

每個 target 宣告必要證據。准入不要求未來才會產生的 execution receipt；晉級仍須 exact owner decision 與獨立授權。

- ADMIT_EXECUTION: 檢查當次契約、動作、grant 與准入前提。
- ASSESS_RECONCILIATION: 判定新鮮的 provider query 與獨立觀測狀態。
- ASSESS_STOP: 檢查 dispatch fence、自有資源與清理；保留未知 effect。
- PROMOTE: 檢查 owner 的精確晉級決定及政策要求。
- ADMIT_RECOVERY: 檢查 pending effect 對帳與新的 attempt、epoch、授權。
- CONFORMANCE: 只判定 suite 宣告的 fixture 或真實證據範圍。

C3: 檔案系統、網路、工具與 credential 限制；timeout、取消、自有資源清理及獨立讀回

C4: 依 profile 綁定契約、證據、approval、動作與對帳的端到端流程，包含負向案例

## 依實際範圍閱讀證據

現有 fixture 結果不認證真實 runtime、全面可攜性、production readiness 或業務价值；研究頁保留這些待驗問題。