Claim และ capability

ผู้อ่าน: Coding agent และผู้ดูแล integration คำสั่ง CLI และ schema ด้านล่างเป็นเอกสารระบบ ไม่ใช่รายการที่ผู้ใช้ต้องทำเอง ผู้ใช้เริ่มที่ เริ่มใช้งาน

พูดง่าย ๆ: claim คือคำสัญญาเรื่องพฤติกรรมที่ change ให้ไว้ capability คือประเภทของการตรวจที่แสดงคำสัญญานั้นได้ (เช่น test, browser, accessibility) provider คือเครื่องมือของโปรเจกต์ที่รันการตรวจ และ receipt คือบันทึกผล หน้านี้สำหรับ agent และผู้ทำ integration ที่ประกาศว่า change ต้องพิสูจน์อะไร คุณต้องมี change ที่มี acceptance scenario และจะได้รายการ claim ที่กำหนดว่าการตรวจใดต้องผ่านก่อน Land ดู อภิธานศัพท์

กฎหลักของ Change Loop คือ คำสั่งที่ผ่านไม่ได้แปลว่าเป็นหลักฐานโดยอัตโนมัติ

ทุก scenario ที่ยอมรับได้และสังเกตได้จะได้ claim ID ที่คงที่ แต่ละ claim ประกาศ capability ที่พิสูจน์มันได้จริง หลักฐานที่ขาด, stale, fail, error หรือ inconclusive จะบล็อกการ land

สัญญาเชิงพฤติกรรม

evidence.yaml เก็บส่วนที่คงที่ มันเปลี่ยนก็ต่อเมื่อ claim หรือภาระที่สังเกตได้เปลี่ยน

{
  "version": 2,
  "claims": [
    {
      "id": "profile-update",
      "scenario": "The owner can update their profile",
      "impact": "medium",
      "capabilities": ["test", "browser", "accessibility"]
    }
  ]
}

Semantic draft v3 derive provider wiring ปกติจาก verify ของ task แล้วเก็บกับ contract ใน evidence.yaml ส่วน custom command, report, service หรือ readiness override อยู่ใน execution.yaml แบบ conditional การเปลี่ยน wiring จึงยังไม่เปลี่ยนสิ่งที่ซอฟต์แวร์สัญญาไว้

เคล็ดลับ

discovery เป็นภาระระดับ suite ที่มาโดยปริยายทุกครั้งที่เลือก test ไม่ต้องใส่ซ้ำในทุก claim

แคตตาล็อก capability

เลือกเฉพาะที่ claim ต้องการ ไม่ใช่เลือกทั้งแคตตาล็อกเป็นค่าเริ่มต้น

Capability	ยืนยันอะไร
test	การตรวจเชิงพฤติกรรมที่รันได้สำหรับ claim ที่ประกาศไว้
discovery	พบเทสตามที่คาด และจำนวนที่เจอถึงเกณฑ์ขั้นต่ำ
browser	พฤติกรรมที่เรนเดอร์ในเบราว์เซอร์จริง พร้อม input capability ที่ต้องการ
mutation	ความผิดพลาดเชิงพฤติกรรมที่จงใจใส่เข้าไปถูกชุดหลักฐานจับได้
state-identity	state ก่อน ระหว่าง หรือหลัง เป็นของ actor และ revision ที่ตั้งใจ
integration	หลายคอมโพเนนต์หรือขอบเขตภายนอกทำงานร่วมกันได้
compatibility	สัญญาสาธารณะหรือที่ persist ไว้ยังเข้ากันได้ข้ามเวอร์ชันที่รองรับ
performance	latency, throughput, ทรัพยากร หรือขนาด อยู่ในงบที่วัดได้
concurrency	งานที่ทำพร้อมกันหรือแบบ async ยังรักษาลำดับ การแยกกัน และการทำงานให้จบได้เมื่อแย่งทรัพยากรกัน
security-static	การตรวจความปลอดภัยเชิงสถิตครอบคลุม trust boundary และ sink ที่ไม่ปลอดภัยที่เปลี่ยนไป
cross-repo-contract	ฝั่งผลิตและฝั่งบริโภคตกลงกันบนสัญญาเวอร์ชันเดียวกัน
review	การรีวิวความเสี่ยงอย่างอิสระครอบคลุม claim และประเด็นที่ยังค้าง
acceptance	มีคนที่ระบุชื่อยอมรับการตัดสินใจเชิงอัตวิสัยอย่างชัดเจน
static-analysis	การคอมไพล์ type check lint และ static quality gate ผ่าน
data-migration	การเปลี่ยน schema หรือข้อมูลปลอดภัยไปข้างหน้า เข้ากันได้ย้อนหลัง และ rollback ได้
accessibility	semantics การใช้คีย์บอร์ด focus contrast และการเข้าถึงด้วยเครื่องมือช่วย ผ่านนโยบาย
resilience	พฤติกรรมเรื่อง timeout retry ความล้มเหลวบางส่วน การกู้คืน และ dependency ที่ทำงานไม่เต็มที่ ถูกพิสูจน์
observability	log, metric, trace และ alert ที่จำเป็นเปิดเผยทั้งความสำเร็จและความล้มเหลวอย่างปลอดภัย
deployment	การแพ็กเกจ การตั้งค่า health check ตอน rollout และพฤติกรรม rollback ถูกพิสูจน์
dependency-supply-chain	นโยบายเรื่องช่องโหว่ ไลเซนส์ lockfile และ provenance ของ dependency ผ่าน

| evaluation | การประเมินโมเดลหรือการจัดอันดับได้คะแนนไม่ต่ำกว่า threshold | | parity | implementation ใหม่ให้ผลตรงกับ reference บนชุดเปรียบเทียบที่ประกาศไว้ | | plan-check | plan ของ infra หรือ migration มีเฉพาะการเปลี่ยนแปลงที่ประกาศไว้ | | release-health | สัญญาณ crash, error และ adoption ยังปกติระหว่าง rollout (หลัง release) | | experiment-guardrail | metric guardrail อยู่ในกรอบหลัง release |

รวม 25 ตัว change ส่วนใหญ่ใช้แค่สองสามตัว สองตัวสุดท้ายเป็นด่าน rollout หลัง release ที่ถูกบันทึกใน proposal ที่ archive และไม่เคยบล็อก proof หรือ Land work type ที่ต้องใช้ capability เฉพาะทาง (เช่น ml → evaluation, infra → plan-check) ดูที่ evidence contract

provider ของ security-static, resilience, compatibility, data-migration หรือ cross-repo-contract ที่แค่รันคำสั่งเทสซ้ำ ไม่ได้สังเกตอะไรเกินกว่าเทส จึงไม่ถูกรันและไม่ถูกนับเป็นหลักฐาน การรีวิวที่บังคับจะครอบคลุม capability นั้นแทน ในระดับที่สูงขึ้น และ proof จะบันทึกไว้เป็น covered-by-review ถ้าต้องการสังเกต capability นั้นโดยตรง ให้ wire คำสั่งจริงสำหรับมัน

Receipt

receipt คือสิ่งที่ capability ผลิตออกมา มันผูกกับทุกอย่างที่ทำให้มันใช้ไม่ได้

provider      browser
adapter       playwright · protocol 7
execution     harness
claims        profile-view, profile-update
workspace     sha256:7f31…
environment   node 22 · darwin-arm64
input         browser-automation
artifacts     trace.zip · screenshot.png
duration      8.42s

เปลี่ยน input ที่ผูกไว้เมื่อไหร่ receipt จะ stale ทันที Change Loop ไม่เคยใช้หลักฐานที่ไม่ตรงกันซ้ำแบบเงียบ ๆ

execution: harness ถูกตั้งได้เฉพาะจากจุดเรียกที่รันคำสั่งจริง ดูเกณฑ์เต็มของหลักฐานที่บันทึกด้วยมือได้ที่ /prove

Test และ discovery

รายงาน JSON ที่ตั้งค่าไว้ต้องเปิดเผยจำนวนเต็มไม่ติดลบ เช่น numTotalTests, totalTests, testCount หรือ expected

ถ้าคำสั่งผ่านแต่ไม่มีจำนวนที่แน่นอน หลักฐาน test อาจผ่านได้ ขณะที่ discovery เป็น inconclusive — และการ land ยังถูกบล็อกอยู่ อาร์เรย์ สตริงตัวเลข คีย์ซ้อนที่กำหนดเอง และ stdout ที่ปนกัน จะไม่ ถูกแปลงเป็นจำนวนให้ เพราะ suite ที่เงียบ ๆ แล้วเจอศูนย์เทสคือความล้มเหลวที่กฎนี้ตั้งใจดักไว้พอดี

ความเชื่อมโยง

claude-foundation change audit <change>

ตรวจความเชื่อมโยง scenario → claim → task → provider ทุก scenario ที่สังเกตได้ควรไปถึง claim และทุก claim ควรไปถึง provider ที่พิสูจน์มันได้ scenario ที่ไม่มี claim คือคำสัญญาที่ไม่มีใครตรวจ