วิธีสร้าง Agentic OS ด้วย Fable 5 (คู่มือสำหรับนักพัฒนา)

นี่คือคู่มือ A–Z ฉบับสมบูรณ์ของ Claude Fable 5 ว่ามันคืออะไร และวิธีใช้งานให้เหมือนวิศวกรระดับ 100x

สิ่งนี้จะเปลี่ยนทุกอย่างเกี่ยวกับวิธีที่คุณทำงานกับ Claude

บุ๊กมาร์ก 8 บิลด์เหล่านี้ไว้ก่อนที่คุณจะลืม

บทนำ

คุณมีโมเดลที่ทรงพลังที่สุดเท่าที่เคยมีมาให้ใช้งานทั่วไป แต่คุณยังคงพิมพ์พรอมต์ทีละอัน คู่มือนี้จะแก้ไขปัญหานั้น

นี่คือสถานการณ์ ณ เดือนกรกฎาคม 2026 Fable 5 สามารถทำงานได้เป็นชั่วโมงๆ โดยไม่ต้องมีคนดูแล ส่งเอเจนต์ย่อยของตัวเองออกไป และทำงานที่ต้องใช้เวลาหนึ่งสัปดาห์ให้เสร็จภายในคืนเดียว มันยังคิดค่าบริการตามการใช้งาน ($10/ล้านโทเค็นขาเข้า, $50/ล้านโทเค็นขาออกผ่านเครดิตการใช้งาน) มันทำงานเกินขอบเขตเมื่อไม่ได้กำหนดขอบเขตไว้ และมันเถียงเพื่อข้อผิดพลาดของมันได้น่าเชื่อถือกว่าที่คนส่วนใหญ่เถียงเพื่อคำตอบที่ถูกต้องของพวกเขา

ถ้าใช้แบบไม่เป็นระบบ มันเป็นวิธีที่แพงในการสร้างสิ่งที่ผิดพลาดแต่ดูน่าประทับใจ แต่ถ้าใช้ภายในระบบ มันคือสิ่งที่ใกล้เคียงกับพนักงานมากที่สุดที่คุณสามารถเช่าได้ในราคาสามดอลลาร์ต่อวัน

คู่มือนี้จะสร้างระบบนั้นขึ้นมา ไม่ใช่แค่แนวคิด: ไฟล์จริง ตามลำดับ พร้อมจุดตรวจสอบหลังจากแต่ละขั้นตอนเพื่อให้คุณรู้ว่ามันทำงานได้ก่อนที่จะต่อชิ้นส่วนถัดไป

สิ่งที่คุณจะมีเมื่อเสร็จสิ้น:

• CLAUDE.md ที่โมเดลไม่สามารถต่อรองได้ (BUILD 1)
• ลูปประจำวันที่ Fable 5 ตัดสินใจทุกอย่างแต่เขียนโทเค็นน้อยมาก โมเดลราคาถูกทำงาน ผู้ตรวจสอบอิสระให้คะแนน และสคริปต์ bash เป็นผู้ลงคะแนนเสียงสุดท้าย (BUILDs 2-3)
• บัญชีแยกประเภทความเชื่อถือที่ให้และเพิกถอนอิสระในการทำงานตามทักษะ โดยอัตโนมัติ ตามอัตราการผ่านที่วัดได้ (BUILD 4)
• ไดเรกทอรีเป้าหมายที่ทุกสิ่งที่คุณเคยทำเสร็จจะถูกตรวจสอบซ้ำทุกวัน ตลอดไป เพื่อไม่ให้อะไรเน่าเสียอย่างเงียบๆ (BUILD 5)
• งบประมาณที่บังคับใช้เองแทนที่จะทำให้คุณประหลาดใจ (BUILD 6)
• สี่ลูปเสริม (quorum, ratchet, sparring, compost) แต่ละอันมีเงื่อนไขที่บอกคุณว่าเมื่อไหร่ควรติดตั้ง (BUILD 7)
• ตาราง cron, คู่มือการดำเนินการสำหรับทุกสัญญาณเตือนที่ระบบสามารถแจ้งได้, และตารางความเชื่อถือ 30 วันที่จะพามันจากการถูกควบคุมไปสู่การขยายขีดความสามารถด้วยตนเอง

คู่มือนี้เหมาะสำหรับใคร ใครก็ตามที่มี repo, terminal, และการสมัครสมาชิก Claude Code หรือคีย์ API ตัวอย่างต่างๆ มีกลิ่นอายของโค้ดเพราะลูปต่างๆ เติบโตมาจากฐานโค้ด แต่ระบบเป้าหมายและครึ่งหนึ่งของลูปทำงานกับใบแจ้งหนี้ รายงาน และรายการอ่านได้ดีพอๆ กัน เงื่อนไขต่างๆ เป็นเพียงคำสั่ง shell

วิธีอ่าน อ่านตามลำดับ ทำตามจุดตรวจสอบ BUILD 0 คือการตั้งค่าและภาษาพรอมต์อย่างเป็นทางการของ Anthropic ทุกอย่างหลังจากนั้นคือระบบที่สร้างขึ้นบนนั้น แต่ละบิลด์ใช้เวลา 10 ถึง 20 นาที 30 วันในตอนท้ายไม่ใช่เวลาในการอ่าน แต่เป็นตารางความเชื่อถือแบบค่อยเป็นค่อยไปที่ระบบจะได้รับสิทธิ์ในการทำงานโดยไม่มีคุณ เวลาลงมือปฏิบัติจริงทั้งหมด: ประมาณ 2 ชั่วโมง

หลักการสามข้อที่อยู่ภายใต้ทุกสิ่ง เพื่อให้คุณสามารถคาดเดาการตัดสินใจในการออกแบบใดๆ ก่อนที่จะอ่าน:

1. กฎ ไม่ใช่คำแนะนำ ทุกกฎมีหมายเลข คำว่า "ห้าม" หรือคำสั่งที่ตรวจสอบมัน อะไรที่อ่อนกว่านั้นจะถูกปรับให้เหมาะสมจนหายไป
2. ไม่มีอะไรตรวจสอบการบ้านของตัวเอง ผู้วางแผน ผู้ทำงาน ผู้ตรวจสอบ และผู้เฝ้าประตู คือสี่ฝ่ายที่แตกต่างกัน และฝ่ายสุดท้ายเป็นแบบตายตัว (deterministic)
3. ไม่มีอะไรที่ผ่านแล้วจะไม่ถูกจับตามอง งานที่เสร็จแล้วจะเลื่อนขั้นไปเป็นค่าคงที่ที่ถูกตรวจสอบซ้ำ เป้าหมายที่คุณตรวจสอบเพียงครั้งเดียวคือสมมติฐานที่มีประทับเวลา

ไม่มีเรียงความอีกต่อไปจากตรงนี้ แปดบิลด์ แต่ละอันมีไฟล์ คำสั่ง และจุดตรวจสอบ

ข้อกำหนดเบื้องต้น

1CLI claude (Claude Code) พร้อมการเข้าถึง Fable 5     # เปิดใช้งานเครดิตการใช้งาน, ตั้งค่าขีดจำกัด /usage-credits
2CLI llm + คีย์ OpenRouter                              # llm install llm-openrouter
3jq, gh, git, make, cron
4repo ที่มีคำสั่งทดสอบ

สิ่งที่คุณกำลังสร้าง

1your-repo/
2  CLAUDE.md                    # BUILD 1: รัฐธรรมนูญ
3  loop/
4    loop.sh                    # BUILD 3: หัวใจหลัก
5    conductor.md               # BUILD 3: พรอมต์กำหนดเส้นทาง
6    triage.md                  # BUILD 3: พรอมต์ผู้อ่านราคาถูก
7    contract.md                # BUILD 2: สามรายการ
8    workers/implement.md       # BUILD 3
9    workers/verify.md          # BUILD 3
10    guardrails/verify.sh       # BUILD 2: ประตูตรวจสอบแบบตายตัว
11    scripts/trust-log.sh       # BUILD 4
12    scripts/log-cost.sh        # BUILD 6
13    scripts/cost-check.sh      # BUILD 6
14    quorum.sh                  # BUILD 7 (ไม่บังคับ)
15    verify-goals.sh            # BUILD 5
16    goals/                     # BUILD 5: เป้าหมายถาวร
17    skills/                    # BUILD 4: หนึ่งไฟล์ต่อพนักงานหนึ่งคน
18    memory/
19      STATE.md  trust.tsv  goal-ledger.tsv  dispatch.tsv  usage.log
20  Makefile                     # BUILD 8: tick / queue / trust / audit / dream

BUILD 0: กำหนดค่าเอ็นจิ้น (จากเอกสารทางการของ Fable 5)

ทุกอย่างในบิลด์นี้มาจากเอกสารของ Anthropic เอง ตั้งค่าสิ่งเหล่านี้ก่อนที่จะเขียนไฟล์ใดๆ ของคุณเอง

แผ่นข้อมูลจำเพาะ:

การตั้งค่า

ค่า

แหล่งที่มา

สตริงโมเดล

claude-fable-5

ภาพรวมโมเดล

บริบท / เอาต์พุต

1M โทเค็น / สูงสุด 128k เอาต์พุตต่อคำขอ

เอกสารแนะนำ

ราคา

$10/ล้านขาเข้า, $50/ล้านขาออก

เอกสารแนะนำ

การคิด (Thinking)

adaptive, เปิดตลอดเวลา;

thinking: {type:"disabled"}

ถูกปฏิเสธ; เอาต์พุตการคิดจะถูกสรุปเท่านั้น

เอกสารแนะนำ + ความพยายาม

ความพยายาม (Effort)

low

medium

high

xhigh

max

;

high

= ค่าเริ่มต้น = การละเว้นพารามิเตอร์

เอกสารความพยายาม

รูปร่าง API

output_config: {"effort": "..."}

บน Messages API

เอกสารความพยายาม

ข้อเท็จจริงอย่างเป็นทางการห้าข้อที่เปลี่ยนวิธีที่คุณสร้าง:

1. max_tokens คือขีดจำกัดสูงสุดของความคิด (thinking) บวกกับข้อความตอบกลับ ที่ระดับ high และ xhigh ให้ตั้งค่าให้ใหญ่ (เริ่มต้นที่ 64k) มิฉะนั้น Fable จะมีพื้นที่ไม่พอระหว่างการคิด ใช้กับการเรียก claude -p ทุกครั้งในคู่มือนี้
2. xhigh มีไว้สำหรับ "งานแบบเอเจนต์ที่ใช้เวลานาน (มากกว่า 30 นาที) โดยมีงบประมาณโทเค็นเป็นล้าน" อย่างเป็นทางการ นั่นคือที่นั่งของผู้ควบคุมวง (conductor) และไม่มีอะไรอื่นในระบบนี้ เอกสารยังบอกด้วยว่าการใช้ effort ต่ำกว่าบน Fable 5 "มักจะเกินประสิทธิภาพของ xhigh บนโมเดลรุ่นก่อนหน้า" ดังนั้นควรต่อต้านการอัปเกรดผู้ทำงาน (worker)
3. การปฏิเสธคือ HTTP 200 Fable 5 เรียกใช้ตัวแยกประเภทความปลอดภัย (อาชญากรรมไซเบอร์, ชีววิทยา/วิทยาศาสตร์ชีวภาพ, การแยกเหตุผล) คำขอที่ถูกปฏิเสธจะส่งคืน stop_reason: "refusal" เป็นการตอบสนองที่สำเร็จ (SUCCESS) สคริปต์ของคุณต้องตรวจสอบ stop reason ไม่ใช่ exit code วิธีแก้ไขอย่างเป็นทางการ: กำหนดค่า fallbacks ฝั่งเซิร์ฟเวอร์หรือมิดเดิลแวร์ SDK เพื่อเปลี่ยนเส้นทางไปยัง Opus 4.8
4. อย่าขอให้ Fable สะท้อนการใช้เหตุผลของมัน พรอมต์หรือทักษะที่พูดว่า "แสดงความคิดของคุณ" หรือ "อธิบายเหตุผลของคุณในการตอบกลับ" จะกระตุ้นหมวดหมู่การปฏิเสธ reasoning_extraction และยกระดับ fallbacks ตรวจสอบทุกทักษะเก่าเมื่อย้ายมาใช้สิ่งนี้ ให้อ่านบล็อกโครงสร้างความคิด (structured thinking blocks) แทน
5. เทิร์น (Turns) นั้นยาวโดยการออกแบบ งานยากใช้เวลาหลายนาทีต่อคำขอที่ effort สูงกว่า การทำงานอัตโนมัติจะขยายออกไปเป็นชั่วโมง ปรับค่า timeout ของไคลเอนต์และตรวจสอบการทำงานแบบอะซิงโครนัส (งานตามกำหนดการ, ไม่ใช่การรอแบบบล็อก) นี่คือสาเหตุที่หัวใจหลัก (heartbeat) เป็น cron ไม่ใช่ลูปแบบบล็อก

ชุดพรอมต์อย่างเป็นทางการ Anthropic จัดส่งภาษาพรอมต์ที่ผ่านการทดสอบสำหรับพฤติกรรมที่รู้จักของ Fable 5 สิ่งเหล่านี้จะใส่ลงในพรอมต์ของคุณแบบคำต่อคำ อย่าเปลี่ยนเป็นคำพูดของคุณเองให้สั้นลง:

1. ป้องกันการวางแผนมากเกินไป (Anti-overplanning) (สำหรับ conductor และเซสชันแบบโต้ตอบใดๆ):

1เมื่อคุณมีข้อมูลเพียงพอที่จะลงมือทำ ให้ลงมือทำ อย่าหาข้อเท็จจริงที่已经被
2กำหนดไว้แล้วในการสนทนาซ้ำ อย่าตั้งคำถามกับการตัดสินใจที่ผู้ใช้ได้ทำไปแล้ว
3หรือบรรยายตัวเลือกที่คุณจะไม่ดำเนินการ หากคุณกำลังชั่งน้ำหนักทางเลือก
4ให้คำแนะนำ ไม่ใช่การสำรวจอย่างละเอียดถี่ถ้วน

1. ป้องกันการทำเกินความจำเป็น (Anti-gold-plating) (สำหรับทุกพรอมต์ของผู้ทำงาน; นี่คือรั้วอย่างเป็นทางการรอบการทำงานเกินขอบเขต):

1อย่าเพิ่มฟีเจอร์, รีแฟคเตอร์, หรือแนะนำนามธรรมที่เกินกว่าที่งาน
2ต้องการ การแก้ไขบั๊กไม่จำเป็นต้องทำความสะอาดรอบข้าง อย่าออกแบบสำหรับ
3ความต้องการในอนาคตที่สมมติขึ้น: ทำสิ่งที่ง่ายที่สุดที่ทำงานได้ดี
4อย่าเพิ่มการจัดการข้อผิดพลาดหรือการตรวจสอบความถูกต้องสำหรับสถานการณ์ที่ไม่สามารถเกิดขึ้นได้
5ตรวจสอบความถูกต้องเฉพาะที่ขอบเขตของระบบเท่านั้น

1. การอ้างสิทธิ์ความคืบหน้าอย่างมีหลักฐาน (Grounded progress claims) (สำหรับการทำงานระยะยาวใดๆ; ในการทดสอบของ Anthropic สิ่งนี้เกือบจะขจัดรายงานสถานะที่กุขึ้น):

1ก่อนที่จะรายงานความคืบหน้า ตรวจสอบแต่ละข้ออ้างกับผลลัพธ์ของเครื่องมือจาก
2เซสชันนี้ รายงานเฉพาะงานที่คุณสามารถชี้ให้เห็นหลักฐานได้เท่านั้น หากบางอย่างยังไม่
3ได้รับการยืนยัน ให้พูดอย่างชัดเจน หากการทดสอบล้มเหลว ให้พูดพร้อมกับผลลัพธ์ หาก
4ขั้นตอนถูกข้ามไป ให้พูดอย่างนั้น

1. การเตือนความจำไปป์ไลน์อัตโนมัติ (Autonomous-pipeline reminder) (สำหรับทุกพรอมต์ที่ขับเคลื่อนโดย cron; ฆ่าการหยุดก่อนกำหนดแบบ "ฉันจะรัน X ทันที"):

1คุณกำลังทำงานโดยอัตโนมัติ ผู้ใช้ไม่ได้ดูอยู่และไม่สามารถตอบคำถาม
2ระหว่างทำงาน สำหรับการกระทำที่สามารถย้อนกลับได้ซึ่งเป็นไปตามคำขอเดิม
3ให้ดำเนินการต่อไปโดยไม่ต้องถาม ก่อนที่จะจบเทิร์นของคุณ ให้ตรวจสอบย่อหน้าสุดท้าย
4ของคุณ: ถ้ามันเป็นแผน, คำถาม, หรือคำมั่นสัญญาเกี่ยวกับงานที่คุณยังไม่ได้ทำ
5ให้ทำงานนั้นตอนนี้ด้วยการเรียกใช้เครื่องมือ จบลงเมื่องานเสร็จสมบูรณ์
6หรือคุณติดขัดเนื่องจากอินพุตที่ผู้ใช้เท่านั้นที่สามารถให้ได้

1. รูปแบบหน่วยความจำอย่างเป็นทางการ (Official memory format) (สำหรับ dreamer และ memory/learnings/):

1จัดเก็บบทเรียนหนึ่งบทเรียนต่อหนึ่งไฟล์ โดยมีสรุปหนึ่งบรรทัดอยู่ด้านบน
2บันทึกการแก้ไขและแนวทางที่ได้รับการยืนยันเช่นเดียวกัน รวมถึงสาเหตุที่มันสำคัญ
3อย่าบันทึกสิ่งที่ repo บันทึกไว้แล้ว อัปเดตบันทึกที่มีอยู่แทนที่จะทำซ้ำ
4ลบบันทึกที่กลายเป็นว่าผิด

1. คำแนะนำผู้ตรวจสอบอย่างเป็นทางการ (Official verifier instruction) (เอกสารระบุโดยตรง: "เอเจนต์ย่อยผู้ตรวจสอบที่มีบริบทแยกต่างหากและสดใหม่ มักจะทำงานได้ดีกว่าการวิจารณ์ตนเอง"):

1สร้างวิธีการตรวจสอบงานของคุณเองในช่วงเวลาทุกๆ [X] ขณะที่คุณ
2สร้าง เรียกใช้สิ่งนี้ทุกๆ [ช่วงเวลา X], ตรวจสอบงานของคุณกับเอเจนต์ย่อย
3ตามข้อกำหนด

คำสั่งนั่งร้านสองคำสั่งจากเอกสารที่ควรปฏิบัติตาม: เริ่มต้นที่จุดสูงสุดของช่วงความยากของคุณ (การทดสอบ Fable เฉพาะกับงานง่ายๆ ทำให้มันด้อยค่า; ให้ปัญหาที่ยากที่สุดที่ยังไม่ได้แก้และปล่อยให้มันกำหนดขอบเขต), และรีแฟคเตอร์ทักษะเก่า (คำแนะนำที่เขียนสำหรับโมเดลรุ่นก่อนหน้ามักจะกำหนดมากเกินไปสำหรับ Fable 5 และทำให้เอาต์พุตแย่ลง; หากประสิทธิภาพเริ่มต้นดีกว่าโดยไม่มีคำแนะนำ ให้ลบคำแนะนำนั้น)

CHECK 0: ทุกการเรียก claude -p ในสคริปต์ของคุณมี max_tokens ขนาดใหญ่ที่ชัดเจนในที่ที่รองรับ; สคริปต์ของคุณตรวจสอบ stop_reason: "refusal"; ไม่มีพรอมต์หรือทักษะใดๆ ที่พูดว่า "แสดงความคิดของคุณ"

BUILD 1: รัฐธรรมนูญ (CLAUDE.md)

เหตุผลในหนึ่งบรรทัด: Fable ปฏิบัติตามกฎและปรับให้เหมาะสมตามคำแนะนำ ดังนั้นทุกบรรทัดต้องมีหมายเลข คำว่า "ห้าม" หรือคำสั่งที่ตรวจสอบมัน

กฎสำหรับไฟล์: สี่บล็อก, ต่ำกว่า 150 บรรทัด, ไม่มี "คิดทีละขั้นตอน" (การให้เหตุผลเปิดอยู่เสมอ; สิ่งเหล่านั้นคือโทเค็นที่เสียเงิน), ไม่มีบุคลิกของเอเจนต์ที่กำหนดไว้ล่วงหน้า (Fable ออกแบบทีมได้ดีกว่าที่คุณจะกำหนดล่วงหน้า), ส่วนใหญ่เป็นป้ายหยุด

สร้าง CLAUDE.md:

1# CLAUDE.md
2
3## ห้าม (กฎ; ข้อยกเว้นต้องขออนุญาตก่อน)
4- ห้ามเกิน 200 บรรทัดที่เปลี่ยนแปลงในหนึ่งคอมมิตโดยไม่ขออนุญาต
5- ห้ามแตะ src/auth/, src/billing/, migrations/, หรือ prod config โดยไม่มีคนดูแล
6- ห้ามรายงานว่างานเสร็จจากการประเมินของคุณเอง เสร็จ = การตรวจสอบผ่าน
7- ห้ามสร้างความลับ, เอนด์พอยต์, หรือธรรมเนียมปฏิบัติขึ้นมาเอง ให้หยุดและถาม
8- ห้ามเพิ่ม dependency เสนอมันใน STATE.md และหยุด
9- ห้ามเกิน effort high ภายในลูปใดๆ xhigh มีไว้สำหรับการตรวจสอบครั้งเดียวเท่านั้น
10- ห้ามแก้ไขหรือลบการทดสอบเพื่อให้มันผ่าน นั่นคือความล้มเหลวเสมอ
11- ห้ามสะท้อน, ถอดความ, หรืออธิบายการใช้เหตุผลภายในของคุณในข้อความตอบกลับ
12  (ทางการ: กระตุ้นการปฏิเสธ reasoning_extraction บน Fable 5)
13- เมื่อเงื่อนไข /goal ผ่าน ให้เขียน goals/<name>.md โดยมีเงื่อนไขนั้น
14  เป็น predicate ก่อนที่จะรายงานความสำเร็จ
15
16## การจัดส่ง (กำหนดเส้นทางทุกงาน; รายการแรกที่ตรงกันชนะ; บันทึกลงใน memory/dispatch.tsv)
17| model           | marginal | appetite | intelligence | taste |
18|-----------------|----------|----------|--------------|-------|
19| claude-fable-5  | 2 (เครดิต) | 3     | 10           | 10    |
20| claude-opus-4-8 | 7 (sub)  | 6        | 8            | 9     |
21| claude-sonnet-5 | 9 (sub)  | 8        | 7            | 7     |
22| codex (sub ที่ 2) | 9        | 10       | 9            | 5     |
231. การตัดสินใจ (วางแผน/ตรวจสอบ/กำหนดเส้นทาง/ทางตัน) -> fable-5, effort high, อ่านอย่างเดียว
242. การอ่าน >50k โทเค็น (logs/PDFs/screenshots) -> codex ห้ามใช้ fable
253. การส่งถึงผู้ใช้ (UI/API/สำเนา) -> taste >= 8 ได้รับการตรวจสอบครั้งสุดท้าย
264. ข้อมูลจำเพาะสมบูรณ์ -> sonnet-5, effort medium
275. นอกเหนือจากนั้น sonnet-5; เลื่อนขึ้นหนึ่งขั้นเมื่อพลาดโดยไม่ต้องถาม
28
29## คำศัพท์
30- "intelligence" = ปัญหาที่ยากที่สุดที่จัดการได้โดยไม่ต้องดูแล
31- "taste" = UI/UX, คุณภาพโค้ด, การออกแบบ API, สำเนา
32- "done" = predicate ผ่าน; ไม่มีอะไรอื่น
33- "small" = ต่ำกว่า 50 บรรทัดที่เปลี่ยนแปลง; "quick" = ต่ำกว่า 10 นาทีของเวลาคุณ
34- "cleanup" = พฤติกรรมเหมือนเดิม, verify.sh สีเขียวก่อนและหลัง
35
36## เสร็จแล้ว
37- ทุกงานมี done_when ที่เครื่องตรวจสอบได้ก่อนเริ่มงาน
38- เอเจนต์ที่มีบริบทใหม่ซึ่งไม่เห็นทั้งแผนหรือร่างจะตรวจสอบกับมัน
39- guardrails/verify.sh มีคะแนนเสียงสุดท้าย
40- การเบี่ยงเบน: ตัวเลือกแบบอนุรักษ์นิยม, บันทึกลงใน IMPLEMENTATION.md, ดำเนินการต่อ
41- ผู้สร้างและผู้ตรวจสอบไม่เห็นด้วยสองครั้ง -> หยุด, เข้าคิวให้มนุษย์

แก้ไขตัวเลขและพาธให้เป็นของคุณ เนื้อหาเฉพาะเวิร์กโฟลว์ (ขั้นตอน PR, รายการตรวจสอบการเผยแพร่) ไปไว้ใน skills/ ไม่ใช่ที่นี่

CHECK 1: สำหรับทุกบรรทัดให้ถาม: โมเดลสามารถปฏิบัติตามได้ 80% และอ้างว่าสำเร็จได้หรือไม่? ถ้าใช่ ให้เขียนใหม่ด้วยตัวเลขหรือคำว่า "ห้าม" wc -l CLAUDE.md ต่ำกว่า 150

BUILD 2: กำแพงและประตู

เหตุผล: ต้องประกาศรัศมีการระเบิดก่อนการเดินเครื่องครั้งแรก และสคริปต์ bash ต้องถือคะแนนเสียงสุดท้าย

สร้าง loop/contract.md:

1## ทำงานคนเดียว
2ร่าง PR บน branch; แก้ไขหนี้ lint/test; อัปเดต STATE.md; ติดป้ายกำกับ issues
3
4## เข้าคิวให้ฉัน
5auth, payments, migrations; ทักษะใดๆ ที่ต่ำกว่าระดับ "auto"; diff ใดๆ > 400 บรรทัด
6
7## ปลุกฉัน
8verify ล้มเหลวสองครั้งในรายการเดียวกัน
9safeguard router สลับโมเดลระหว่างการทำงาน
10งบประมาณรายวันถูกเบิกเกิน
11มีอะไรขอ secret
12เป้าหมายถาวร (standing goal) ถูกละเมิด (VIOLATED)

สร้าง loop/guardrails/verify.sh (แก้ไขสำหรับสแต็คของคุณ):

1#!/usr/bin/env bash
2set -e
3npm run typecheck --if-present
4npm test --if-present
5npm run lint --if-present

CHECK 2: ./loop/guardrails/verify.sh ทำงานและออกด้วย 0 บน repo ปัจจุบันของคุณ ถ้ามันล้มเหลวตอนนี้ ให้แก้ไขก่อน; ทั้งระบบยืนอยู่บนสคริปต์นี้

BUILD 3: หัวใจหลัก

เหตุผลในสามบรรทัด: Fable ในฐานะผู้ทำงานคือบิลสี่หลัก (เซสชัน 500k-1M โทเค็นที่ $50/ล้านขาออก); Fable ในฐานะผู้ควบคุมวงปล่อยโทเค็น 10-20% ในขณะที่ตัดสินใจ 100% โมเดลราคา $0.01 อ่านการเดินเครื่องที่เงียบ เอเจนต์ส่งต่อผ่าน schema JSON เพื่อให้โมเดลใดๆ ก็สามารถนั่งในที่นั่งใดก็ได้

สร้าง loop/triage.md:

1คุณได้รับคอมมิตล่าสุด, issues ที่เปิดอยู่, และการรัน CI ส่งออกเฉพาะสิ่งที่พบ:
2- finding: <หนึ่งบรรทัด>
3  evidence: <id คอมมิต/issue/รัน>
4  status: actionable | informational
5ไม่มีการแก้ไข, ไม่มีความคิดเห็น ไม่มีอะไรจะรายงาน = ส่งออก "status: quiet" ทุกอย่างที่แตะ auth, payments, migrations, secrets = actionable เสมอ, บันทึกว่า "contract-sensitive"

สร้าง loop/conductor.md:

1คุณคือผู้ควบคุมวง คุณไม่เขียนโค้ด คุณไม่แก้ไขไฟล์
21. อ่าน STATE, TRUST LEDGER, CONTRACT ด้านล่าง อย่าเชื่อถือความทรงจำเกี่ยวกับสิ่งเหล่านี้
32. เลือก ONE รายการ actionable ที่มีมูลค่าสูงสุด
4   contract-sensitive, ambiguous, หรือน่าจะ >400 บรรทัด diff -> action: queue
5   ไม่มีอะไรคุ้มค่าที่จะทำ -> action: stop
63. มิฉะนั้น action: execute, พร้อม spec ที่โมเดลธรรมดาสามารถทำตามได้
7ส่งออกเฉพาะ JSON นี้:
8{ "action": "execute|queue|stop", "item": "...", "skill": "<kebab-case,
9stable across runs>", "spec": "...", "done_when": ["<verifiable>", ...] }
10คุณมีราคาแพง จงกระชับ ผลลัพธ์ของคุณคือการตัดสินใจ ไม่ใช่เรียงความ

สร้าง loop/workers/implement.md:

1คุณได้รับคำสั่งงาน (JSON) ดำเนินการตาม spec อย่างถูกต้อง
2ทำ ONE ขั้นตอนถัดไปสู่ done_when diff เล็กๆ ชนะ
3ข้อมูลประจำตัวที่หายไปหรือการตัดสินใจที่ไม่ได้บันทึก -> STOP, เขียนคำถามลงใน
4IMPLEMENTATION.md อย่าสร้างความลับหรือธรรมเนียมปฏิบัติ
5บันทึกสิ่งที่คุณทำและทำไมใน IMPLEMENTATION.md (สูงสุด 3 บรรทัด)

สร้าง loop/workers/verify.md:

1คุณได้รับ SPEC และ DIFF ไม่มีอะไรอื่น ตัดสินเฉพาะสิ่งที่อยู่ตรงหน้าคุณ
21. diff ทำให้ทุก done_when เป็นที่พอใจหรือไม่? อ้างอิงบรรทัด
32. มีอะไรที่อยู่นอกขอบเขตของ spec หรือไม่? ล้มเหลวทันที ลบ/ข้ามการทดสอบ? ล้มเหลวทันที
4ส่งออกหนึ่งบรรทัด: "PASS: <เหตุผล>" หรือ "FAIL: <เหตุผล>"
5ผู้สร้างมั่นใจ นั่นไม่ใช่หลักฐาน

สร้าง loop/loop.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3cd "$(dirname "$0")"
4MAX_ITERS="${MAX_ITERS:-10}"
5DAILY_BUDGET_USD="${DAILY_BUDGET_USD:-5}"
6CHEAP="${CHEAP:-openrouter/deepseek/deepseek-v4-flash}"
7WORKER="${WORKER:-openrouter/moonshotai/kimi-k2.6}"
8
9./scripts/cost-check.sh --budget "$DAILY_BUDGET_USD" || exit 3
10
11for ((i=1; i<=MAX_ITERS; i++)); do
12  # 1 TRIAGE: ประตูการเดินเครื่องเงียบ, ~$0.01
13  { git log --oneline -20; gh issue list --limit 20 2>/dev/null || true; \
14    gh run list --limit 10 2>/dev/null || true; } \
15    | llm -m "$CHEAP" -s "$(cat triage.md)" >> memory/STATE.md
16  ./scripts/log-cost.sh triage 0.01
17  grep -q "status: actionable" memory/STATE.md || { echo quiet; exit 0; }
18
19  # 2 CONDUCT: Fable, xhigh, บริบทใหม่, อ่านอย่างเดียว, JSON out
20  claude -p "$(cat conductor.md)
21STATE: $(cat memory/STATE.md)
22TRUST: $(./scripts/trust-log.sh --render)
23CONTRACT: $(cat contract.md)" \
24    --model claude-fable-5 --effort xhigh --allowedTools "Read" \
25    --output-format json > /tmp/c.json
26  ./scripts/log-cost.sh conductor 0.35
27
28  # 2a ROUTE-TOLERANCE: อย่าทำซ้ำบนโมเดลที่คุณไม่ได้เลือก
29  SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/c.json)
30  [[ "$SERVED" != *fable* ]] && { echo "rerouted" >> memory/STATE.md; exit 2; }
31
32  jq -r '.result' /tmp/c.json > work-order.json
33  SKILL=$(jq -r .skill work-order.json); ACTION=$(jq -r .action work-order.json)
34  [[ "$ACTION" == stop  ]] && exit 0
35  [[ "$ACTION" == queue ]] && { echo "queued: $SKILL" >> memory/STATE.md; continue; }
36
37  # 3 EXECUTE: ผู้ทำงานราคาถูก, worktree แยก
38  WT="../wt-$i"; git worktree add "$WT" -b "loop/$SKILL-$i" >/dev/null
39  ( cd "$WT" && llm -m "$WORKER" -s "$(cat "$OLDPWD/workers/implement.md")" \
40      "$(cat "$OLDPWD/work-order.json")" > IMPLEMENTATION.md )
41  ./scripts/log-cost.sh worker 0.10
42
43  # 4 VERIFY: Fable ใหม่, ไม่มีเครื่องมือ, เห็นเฉพาะ spec + diff
44  V=$(claude -p "$(cat workers/verify.md)
45SPEC: $(jq -r .spec work-order.json)
46DIFF: $(cd "$WT" && git diff)" \
47    --model claude-fable-5 --effort high --allowedTools "" \
48    --output-format json | jq -r .result)
49  ./scripts/log-cost.sh verifier 0.40
50
51  # 5 GATE: ตายตัว; จากนั้น ledger; ส่งเฉพาะที่ระดับ auto
52  if [[ "$V" == PASS* ]] && ( cd "$WT" && "$OLDPWD/guardrails/verify.sh" ); then
53    ./scripts/trust-log.sh "$SKILL" pass
54    if [[ "$(./scripts/trust-log.sh --tier "$SKILL")" == auto ]]; then
55      ( cd "$WT" && git add -A && git commit -qm "loop: $SKILL" && gh pr create --fill || true )
56      echo "- shipped: $SKILL" >> memory/STATE.md
57    else
58      echo "- review: $SKILL in $WT" >> memory/STATE.md
59    fi
60  else
61    ./scripts/trust-log.sh "$SKILL" fail
62    echo "- FAILED: $SKILL in $WT" >> memory/STATE.md
63  fi
64  ./scripts/cost-check.sh --budget "$DAILY_BUDGET_USD" || exit 3
65done
66exit 1   # ถึงขีดจำกัดการวนซ้ำโดยไม่หยุด: ตรวจสอบ STATE.md

แผนที่การออก: 0 เงียบ/เสร็จ, 1 ถึงขีดจำกัด, 2 เปลี่ยนเส้นทาง, 3 งบประมาณ ทั้งหมดมีป้ายกำกับ โดยเจตนา

CHECK 3: chmod +x loop.sh guardrails/verify.sh จากนั้นรัน ./loop.sh หนึ่งครั้งด้วยตนเอง ยืนยัน: repo ที่เงียบออกด้วย 0 โดยใช้เงินประมาณหนึ่งเพนนี; repo ที่มีสิ่งที่ต้องทำจะสร้าง work-order.json พร้อมทั้งห้าฟิลด์และบรรทัดคำตัดสินใน STATE.md

BUILD 4: บัญชีแยกประเภทความเชื่อถือ

เหตุผล: "เพิ่มอิสระในการทำงานเมื่อความเชื่อถือเพิ่มขึ้น" ไม่ใช่กลไก; TSV ที่มีกฎระดับคือกลไก อิสระในการทำงานเป็นแบบต่อทักษะ ไม่ใช่ต่อลูป

สร้าง loop/scripts/trust-log.sh:

1#!/usr/bin/env bash
2# การใช้งาน: trust-log.sh <skill> <pass|fail> | --render | --tier <skill>
3set -euo pipefail
4F="$(dirname "$0")/../memory/trust.tsv"; touch "$F"
5tier_of() { awk -v r="$1" -v p="$2" 'BEGIN{
6  rate=(r>0)?p/r:0
7  if (r>=20 && rate>=0.95) print "auto"
8  else if (r<10 || rate<0.90) print "watch"
9  else print "queue"}'; }
10case "${1:-}" in
11  --render)
12    printf "%-20s %5s %5s %6s %s\n" skill runs pass rate tier
13    while IFS=$'\t' read -r s r p; do [ -z "$s" ] && continue
14      printf "%-20s %5s %5s %5s%% %s\n" "$s" "$r" "$p" \
15        "$(awk -v r="$r" -v p="$p" 'BEGIN{printf "%.0f",(r>0)?p/r*100:0}')" \
16        "$(tier_of "$r" "$p")"; done < "$F";;
17  --tier)
18    line=$(grep -P "^${2}\t" "$F" || echo -e "${2}\t0\t0")
19    tier_of "$(cut -f2 <<<"$line")" "$(cut -f3 <<<"$line")";;
20  *)
21    awk -v s="$1" -v r="$2" -F'\t' 'BEGIN{OFS="\t"; f=0}
22      $1==s {f=1; print s,$2+1,$3+(r=="pass"); next} {print}
23      END{if(!f) print s,1,(r=="pass")?1:0}' "$F" > "$F.t" && mv "$F.t" "$F"
24    if [ "$2" = fail ]; then
25      runs=$(grep -P "^${1}\t" "$F" | cut -f2)
26      [ "$("$0" --tier "$1")" = watch ] && [ "$runs" -ge 10 ] \
27        && echo "ALERT: $1 ถูกลดระดับเป็น watch หลังจาก $runs ครั้ง" >&2 || true
28    fi;;
29esac

• กฎระดับ: auto = 20+ ครั้ง และ อัตราผ่าน 95%+, ส่งโดยไม่มีคนดูแล queue = ร่างที่ตรวจสอบแล้วรอคุณ watch = ต่ำกว่า 10 ครั้ง หรือ ต่ำกว่า 90%, เฉพาะร่าง การลดระดับเป็นแบบอัตโนมัติและพิมพ์ไปยัง stderr ซึ่ง cron จะส่งอีเมลถึงคุณ
• เตรียมรายชื่อ: สร้าง loop/skills/<name>/SKILL.md สำหรับงานประจำแต่ละอย่าง (fix-lint-debt, fix-flaky-test, bump-deps, triage-issues เป็นสี่มาตรฐาน) แต่ละไฟล์: ข้อมูลส่วนหน้า (ชื่อ, คำอธิบาย, เมื่อไหร่), ขั้นตอน, รายการ "ห้าม", done-when ที่ตรวจสอบได้ ทุกทักษะเริ่มต้นที่ watch

CHECK 4: รัน ./scripts/trust-log.sh demo pass 21 ครั้ง จากนั้น --tier demo จะพิมพ์ auto บันทึก fail บนทักษะที่รัน 10+ ครั้งและดู ALERT บน stderr รีเซ็ต: > memory/trust.tsv

BUILD 5: เป้าหมายถาวร + บัญชีแยกประเภทเป้าหมาย

เหตุผลในหนึ่งบรรทัด: เป้าหมายที่คุณตรวจสอบเพียงครั้งเดียวคือสมมติฐานที่มีประทับเวลา ดังนั้นเป้าหมายที่เสร็จแล้วจะเลื่อนขั้นเป็นค่าคงที่ที่ถูกตรวจสอบซ้ำทุกวันและบันทึก

สร้างหนึ่งไฟล์ต่อสิ่งที่เสร็จแล้ว, goals/<name>.md:

1predicate: cd $REPO && npm test -- tests/auth 2>&1 | tail -1 | grep -q passing
2born: 2026-07-06
3source: /goal session 2026-07-06 (แก้ไข auth flake)
4status: satisfied
5last-pass: 2026-07-06
6on-violation: ปลุกฉัน อย่าแก้ไขอัตโนมัติ
7retire-when: โมดูล auth ถูกลบ การเลิกใช้เป็นการตัดสินใจของมนุษย์, จะถูกบันทึก

สร้าง loop/verify-goals.sh:

1#!/usr/bin/env bash
2set -uo pipefail
3LEDGER="memory/goal-ledger.tsv"; VIOLATIONS=0
4for g in goals/*.md; do
5  [ -e "$g" ] || continue
6  grep -q '^status: retired' "$g" && continue
7  pred=$(grep '^predicate:' "$g" | cut -d' ' -f2-); name=$(basename "$g" .md)
8  start=$(date +%s%3N)
9  if timeout 60 bash -c "$pred" >/dev/null 2>&1; then r=pass
10    sed -i "s/^status:.*/status: satisfied/; s/^last-pass:.*/last-pass: $(date +%F)/" "$g"
11  else r=FAIL; VIOLATIONS=$((VIOLATIONS+1)); sed -i "s/^status:.*/status: VIOLATED/" "$g"; fi
12  echo -e "$(date -Is)\t$name\t$r\t$(( $(date +%s%3N) - start ))" >> "$LEDGER"
13done
14[ "$VIOLATIONS" -gt 0 ] && { grep -l '^status: VIOLATED' goals/*.md; exit 1; }
15echo "เป้าหมายถาวรทั้งหมดยังคงอยู่"

เริ่มต้นยามเฝ้าระวัง (ตรวจจับเท่านั้น; การแก้ไขจะผ่านไปป์ไลน์ปกติ):

1/loop 1d รัน ./verify-goals.sh. ถ้าผลลัพธ์ไม่เป็นศูนย์: สำหรับแต่ละเป้าหมายที่ถูกละเมิด
2ให้อ่านวันที่ last-pass และแสดงรายการสิ่งที่รวมเข้าด้วยกันตั้งแต่ตอนนั้น
3(git log --oneline --since=<date>)
4รายงานเป้าหมาย, ผู้ต้องสงสัย, นโยบาย on-violation อย่าแก้ไขอะไร

กฎการสำเร็จการศึกษาอยู่ใน CLAUDE.md แล้ว (BUILD 1): ทุก /goal ที่ผ่านจะเขียนเป้าหมายถาวรของตัวเอง การทำให้เสร็จคือการลงทะเบียน

การสืบค้น Ledger ที่คุณจะใช้จริง:

1awk -F'\t' '$3=="FAIL"{n[$2]++} END{for(g in n) print n[g],g}' memory/goal-ledger.tsv | sort -rn | head -5   # flakiest
2grep <goal> memory/goal-ledger.tsv | awk -F'\t' '$3=="FAIL"' | head -1                                      # when it broke

Flaky predicate: quarantine (status: retired, note "needs a better predicate"), never delete.

CHECK 5: Add a goal with predicate: true and one with predicate: false. ./verify-goals.sh exits 1, flips the second to VIOLATED, and both appear in the ledger. Delete the dummies.

BUILD 6: The Budget

Why: daily cost = ticks × triage + hits × (conductor + worker + verifier). At real prices (triage $0.01, conductor $0.35, worker $0.10, verifier $0.40): a daily janitor is ~$2.56/day; a 15-minute babysitter with Fable in the triage seat is $34/day for the identical outcome. The model that reads the quiet ticks decides the bill.

Create loop/scripts/log-cost.sh:

1#!/usr/bin/env bash
2echo -e "$(date -Is)\t$1\t$2" >> "$(dirname "$0")/../memory/usage.log"

Create loop/scripts/cost-check.sh:

1#!/usr/bin/env bash
2set -euo pipefail
3F="$(dirname "$0")/../memory/usage.log"; touch "$F"; TODAY=$(date +%F)
4case "${1:-}" in
5  --budget)
6    spent=$(awk -F'\t' -v d="$TODAY" '$1 ~ d {s+=$3} END{printf "%.2f",s}' "$F")
7    awk -v s="$spent" -v b="$2" 'BEGIN{exit (s>=b)?1:0}' \
8      || { echo "spent \$$spent of \$$2" >&2; exit 1; };;
9  --report)
10    awk -F'\t' -v since="$(date -d '7 days ago' +%F)" \
11      '$1>=since{s[$2]+=$3;t+=$3} END{for(k in s) printf "  %-10s $%.2f\n",k,s[k]; printf "  TOTAL      $%.2f\n",t}' "$F";;
12esac

Rules that keep it flat: cadence is a cost decision (halving the interval doubles the floor); the quiet tick must cost cents; effort never above high in loops (xhigh is for one-shot reviews; effort is per step, not per run).

CHECK 6: After a week of ticks, ./scripts/cost-check.sh --report matches the formula within noise. Set DAILY_BUDGET_USD to a number you would not mind wasting.

BUILD 7: The Optional Loops (install when their condition appears)

• Quorum (install when dispatch shows Fable wake-ups that produced action: stop). Three cheap models vote; Fable wakes on 2 of 3. Voters never see each other's answers.

1V=0
2for m in deepseek/deepseek-v4-flash qwen/qwen-3.6 moonshotai/kimi-k2.6; do
3  llm -m "openrouter/$m" -s "$(cat triage.md)" < /tmp/signals.txt \
4    | grep -q "status: actionable" && V=$((V+1))
5done
6[ "$V" -ge 2 ] && exec ./conduct.sh || echo "quorum: quiet ($V/3)"

• Ratchet (install when one number matters). Monotonic improvement or self-revert; the metric may not be gamed; the finished floor becomes a standing goal.

1/goal Reduce `npm run lint 2>&1 | grep -c warning` to 0.
2Permissions: edit src/; commit per fix; re-measure after every change.
3Walls: the number NEVER goes up; revert any change that raises it or breaks a
4test; never edit lint config to lower it.
5Timebox: stop after 3 attempts with no movement; report survivors.

• Sparring (install when you ship code daily). Builder and breaker, opposed; neither touches the other's output; disputes go to you.

1/loop 1d [breaker] Read yesterday's merged diffs. Write ONE failing test
2exposing a real weakness. Commit under tests/sparring/ tagged @sparring.
3Fix nothing. Solid code = say so, write nothing.
4/loop 1d [builder] If any @sparring test fails, fix the CODE until it passes.
5Never edit, weaken, or delete a sparring test; disputes queue for me.

• Compost (install always, weekly). Failures become laws; three proposals max; human signature required.

1/loop 7d Read this week's exhaust: FAILED in STATE.md, fails in trust.tsv,
2FAILs in goal-ledger.tsv, PRs closed unmerged. Extract AT MOST 3 proposals:
3a new CLAUDE.md law (quote incidents), a skill fix (same failure repeating),
4or a standing goal we lacked. Propose only. Clean week = say so.

CHECK 7: Each optional loop has its install condition written next to it in your notes. Installing them speculatively is how systems bloat.

BUILD 8: Ops

Create Makefile:

1tick:            ; ./loop/loop.sh
2queue:           ; @grep -E "review:|queued:|FAILED:|rerouted" loop/memory/STATE.md || echo empty
3trust:           ; @./loop/scripts/trust-log.sh --render
4audit:           ; @./loop/scripts/cost-check.sh --report
5goals:           ; @./loop/verify-goals.sh
6clean-worktrees: ; @git worktree list | awk '/wt-/{print $$1}' | xargs -rn1 git worktree remove --force

Cron, when Week 2 starts:

10 7 * * 1-5  cd /path/to/repo/loop && ./loop.sh >> memory/cron.log 2>&1
230 7 * * *   cd /path/to/repo/loop && ./verify-goals.sh >> memory/cron.log 2>&1

The 30-day trust schedule

Do not skip graduations; each unlocks the next.

Week

Level

You do

Graduate when

1

L1 report

Builds 1-6;

make tick

by hand daily; read everything

3 consecutive runs route exactly as you would have

2

L2 draft

cron on;

make queue

with coffee; reviews feed the ledger

2 skills cross 20 logged runs

3

L3 ship

make audit

vs the formula; best skill goes unattended

1 week, zero interventions

4

L4 grow

compost signs-offs; approve 1 proposed skill; run the delete pass

you removed something and nothing broke

The runbook. What each alarm means and what to do:

Signal

Meaning

Action

exit 2 (reroute)

safeguard router swapped models mid-run

read the checkpoint; re-run item tomorrow; never iterate on the swapped output

stop_reason: refusal

safety classifier declined (HTTP 200, not an error)

official path: fallback to Opus 4.8 via

fallbacks

or middleware; if it recurs on one skill, audit that skill for reasoning-echo or cyber/bio-adjacent phrasing

exit 3 (budget)

daily spend hit the line

make audit

; find which stage grew; fix the effort map, not the budget

ALERT demoted

an established skill dropped below 90%

read its last 3 fails; usually the spec pattern, not the worker

goal VIOLATED

something finished stopped being true

sentinel gives suspects; fix goes through the normal pipeline

maker/checker standoff x2

neither is presumed right

you decide, or run the standoff-breaker (third fresh reviewer, judges evidence, may not split the difference)

verify-goals timeout

predicate too expensive

that is a violation; cheapen the predicate

The Rules (print this)

1. Laws, not tips: a number, a never, or a command that checks it.
2. The conductor plans, workers execute, neither verifies. --allowedTools enforces it.
3. Agents talk in work orders. done_when = spec + stop condition + future invariant.
4. Spend effort where the loop branches. Never above high in a loop.
5. The quiet tick costs a penny or the loop costs a grand.
6. If a shell script couldn't check it, don't write it as a goal.
7. Goals graduate; they do not close. verify-goals.sh runs daily, forever.
8. Autonomy per skill: 20 runs, 95%, auto. Demotion automatic and loud.
9. Two ledgers: trust (workers) and goals (work). Read both with coffee.
10. Compute the metabolism before you cron.
11. Contract in the repo: acts-alone / queues / wakes-me.
12. Never iterate on output from a model you didn't choose.
13. The sentinel detects; the pipeline fixes.
14. Quorum before waking Fable. Ratchet then weld. Spar daily. Compost weekly.
15. One graduation criterion at a time. Every month, delete something.
16. From the official docs: max_tokens caps thinking plus text, refusals are HTTP 200, never ask for echoed reasoning, old skills degrade Fable, and fresh-context verifiers beat self-critique. Anthropic says so; the system enforces it.

Closing

Thirty days from now, if you did the checks: one loop ships boring work unattended, a goals directory re-verifies everything you ever finished, two ledgers tell you the truth about your workers and your work, and a weekly compost run proposes the system's own next improvement for your signature.

• The model was never the hard part. The hard part was building something around it that stays honest when you stop watching. That is what you just built.
• Start tonight with the twenty minutes that proves it: BUILD 2's verify.sh, BUILD 3's first tick by hand, and one standing goal for the last thing you finished.
• The first time verify-goals.sh catches a silent regression on something you were sure was done, you will not need convincing about the rest.

Disclaimer

This article was written by using the user's notes and edited by Claude Opus 4.8 max.