Protocol 0.2 / 規劃中・尚未發布

讓下一個決策，有更清楚的契約。

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

規劃更新 · r3 / sync-4

Markdown 版本 ↗

HelmLoop

讓下一個決策，有更清楚的契約。

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

01

十種 records・七軸判定

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

02

確定性的內容承諾

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

03

當次證據採認

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

04

停止與復原

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

05

獨立 CLI

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

06

限定範圍的 conformance

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

HelmLoop

0.2 / 0.2 規劃

規劃中的十種 record types

OutcomeContractV1AuthorityGrantV1ExecutionReceiptV1EvidenceRecordV1AssuranceDecisionV1PromotionDecisionV1ReconciliationRecordV1LearningSignalV1AuthorityEventV1OutcomeObservationV1

規劃中的七個判定軸

executionevidenceassuranceauthoritypromotionreconciliationobservedOutcome

六種目標，各有判定條件

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

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

版本邊界不能省略

0.1 保留 HL-C14N-1、原 reader 與六軸語義。規劃中的 0.2 使用 helmloop-jcs-sha256-v1 與 typed sha256: 引用。Digest 一致可檢查完整性，不會產生信任或授權。

HelmLoop

交付順序

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

  1. S0

    基線與 wire freeze

    規劃中・尚未發布

  2. S1

    0.2 純核心

    規劃中・尚未發布

  3. S2

    獨立 oracle

    規劃中・尚未發布

  4. S3

    兩個 mock adapters

    規劃中・尚未發布

  5. S4

    CLI 與套件

    規劃中・尚未發布

  6. S5

    一個 real binding

    規劃中・尚未發布

  7. S6

    文件與發行候選

    規劃中・尚未發布

HelmLoop

兩個套件，各有責任

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 互通仍在規劃。

HelmLoop

C0–C5 分別證明什麼

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

Level責任
C0分類、manifest 與文件一致性
C1原始碼、套件與安裝 bytes 身份
C2聲明範圍內的 account、host/session、provider/model assurance
C3檔案系統、網路、工具與 credential 限制；timeout、取消、自有資源清理及獨立讀回
C4依 profile 綁定契約、證據、approval、動作與對帳的端到端流程，包含負向案例
C5Exact live binding 的可信 attestation 與撤銷驗證