# แผน Protocol 0.2 | HelmLoop

> HelmLoop แยกอำนาจ หลักฐาน การเลื่อนขั้น และผลลัพธ์ของเวิร์กโฟลว์ AI ดูรุ่น 0.1 ที่รันได้และแผนโพรโทคอล 0.2

Source: https://helmloop.dev/th/roadmap.html

0.1 มี 8 record schemas, reducer แบบ 6 แกน, CLI และ fixture adapters 2 ตัว ยังไม่ใช่แพ็กเกจสาธารณะหรือการรับรอง runtime จริง

0.2 วางแผนเพิ่มแกน assurance เหตุการณ์อำนาจ การสังเกตผลลัพธ์ และการรับหลักฐานตามเวอร์ชัน ทั้งหมดยังเป็นข้อเสนอ r3 / sync-4

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

## 10 records · 7 แกน

วางแผนเพิ่ม AuthorityEventV1, OutcomeObservationV1 และแกน assurance แยกต่างหาก

## Commitment ที่แน่นอน

JCS / SHA-256 และ JS/Python oracle อิสระ โดยเก็บ bytes และ reader ของ 0.1

## รับหลักฐานปัจจุบัน

ตรวจ subject, policy และ dependencies ใหม่ ผลเก่าไม่ถ่ายทอดอำนาจ

## หยุดและกู้คืน

แยกการหยุดจริง cleanup และการกระทบยอด effect ต้องตรวจผลที่ไม่ทราบก่อนลองใหม่

## CLI อิสระ

วางแผน try ออฟไลน์ที่รัน PASS และ HOLD ที่คาดไว้จริง ภายใน 90 วินาทีหลังติดตั้ง

## Conformance ที่จำกัดขอบเขต

mock 2 ครอบคลุม C0–C4 และ real 1 ตั้งเป้า C0–C5 พร้อมระบุชนิดและข้อจำกัดของหลักฐาน

## ลำดับการพัฒนา

- S0: ฐานและ wire freeze — อยู่ในแผน · ยังไม่เผยแพร่
- S1: แกนบริสุทธิ์ 0.2 — อยู่ในแผน · ยังไม่เผยแพร่
- S2: oracle อิสระ — อยู่ในแผน · ยังไม่เผยแพร่
- S3: mock adapters 2 ตัว — อยู่ในแผน · ยังไม่เผยแพร่
- S4: CLI และแพ็กเกจ — อยู่ในแผน · ยังไม่เผยแพร่
- S5: real binding 1 ตัว — อยู่ในแผน · ยังไม่เผยแพร่
- S6: เอกสารและรุ่นผู้สมัคร — อยู่ในแผน · ยังไม่เผยแพร่

ทุกขั้นยังเป็นแผน oracle ทำคู่กับ core ได้หลัง schema freeze และ CLI ทำคู่กับ mock ได้เมื่อ interface คงที่

## สองแพ็กเกจ สองความรับผิดชอบ

### Neutral core

วางแผน Apache-2.0 สำหรับ schemas, evaluator และ CLI ไม่มี scheduler หรือการพึ่งพา BW

### Better Workflows binding

วางแผน AGPL-3.0-only ทิศทางพึ่งพาคือ binding → core ยังไม่ใช่ข้อสรุปการตรวจสิทธิ์เผยแพร่

## จุดเชื่อมต่อ V5

sync-4 บันทึกการแก้ parser ของ BW ในขอบเขตจำกัด v3/v3 ใช้ typed และ legacy v1/v2 ใช้ bare hex การเชื่อมต่อ 0.2 เต็มรูปแบบยังเป็นแผน

## C0–C5 พิสูจน์อะไร

- C0: หมวดหมู่ manifest และเอกสารตรงกัน
- C1: ตัวตนของ source, package และ bytes ที่ติดตั้ง
- C2: assurance ของ host/session และ provider/model
- C3: ข้อจำกัด การยกเลิก และ cleanup ทรัพยากร
- C4: สัญญา อำนาจ การกระทำ และการกระทบยอด E2E
- C5: attestation ที่เชื่อถือได้และการเพิกถอนของ binding จริง

## 10 record types ในแผน

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

## 7 แกนการตัดสินใจในแผน

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

## 6 เป้าหมายการประเมิน

แต่ละ target กำหนดหลักฐานที่ต้องใช้ การอนุญาตเริ่มไม่ต้องมี receipt ในอนาคต แต่การเลื่อนขั้นต้องมีการตัดสินใจและอำนาจเฉพาะของ owner

- ADMIT_EXECUTION: ตรวจสัญญา action grant และเงื่อนไขปัจจุบัน
- ASSESS_RECONCILIATION: ตรวจ provider query ใหม่และการสังเกตอิสระ
- ASSESS_STOP: ตรวจ dispatch fence ทรัพยากร cleanup และ effect ที่ยังไม่ทราบ
- PROMOTE: ตรวจการตัดสินใจเลื่อนขั้นของ owner และ policy
- ADMIT_RECOVERY: กระทบยอด effect ค้าง พร้อม attempt epoch และอำนาจใหม่
- CONFORMANCE: ประเมินเฉพาะ suite และขอบเขต fixture หรือหลักฐานจริงที่ประกาศ

C3: ข้อจำกัด fs/network/tool/credential, timeout, ยกเลิก, cleanup และ readback อิสระ

C4: E2E ของสัญญา หลักฐาน approval action และการกระทบยอดตาม profile รวมกรณีเชิงลบ

## อ่านหลักฐานตามขอบเขตจริง

fixture ไม่รับรอง runtime จริง portability ความพร้อม production หรือคุณค่าทางธุรกิจ