เหตุผลที่มีของ BWOC — ปรัชญา การออกแบบ และเหตุผลเบื้องหลัง¶

สลับภาษา: English (canonical) | ภาษาไทย

บทนี้เขียนสำหรับวิศวกรหรือสถาปนิกที่กำลังพิจารณาว่า BWOC เหมาะกับงานสร้าง AI coding agent หรือไม่ บทนี้อธิบายว่า BWOC คืออะไร ออกแบบมาอย่างไร และที่มาของคำศัพท์สายพุทธศาสนา รวมถึงเหตุผลที่คำเหล่านั้นสมเหตุสมผลในเชิงวิศวกรรม

ข้อความสำคัญเกี่ยวกับคำภาษาบาลี¶

BWOC ใช้คำภาษาบาลีจากพระไตรปิฎกเป็น ชื่อหัวข้อและตัวย่อสำหรับแนวคิดเชิงวิศวกรรม เท่านั้น ไม่ใช่การสอนศาสนา คำบาลีทุกคำใน BWOC มีความหมายเชิงวิศวกรรมที่ระบุไว้ชัดเจนก่อน โดยคำบาลีเป็นเพียงป้ายชื่อ ไม่จำเป็นต้องมีพื้นฐานทางพุทธศาสนาเพื่อใช้งาน อ่าน หรือมีส่วนร่วมกับ BWOC ผู้อ่านที่ไม่เคยสัมผัสพุทธศาสนามาก่อนสามารถอ่านบทนี้และนำไปเขียนโค้ดได้เลย

เมื่อเห็นคำว่า "Yoniso Manasikāra" ในเอกสารหรือ commit message ให้อ่านว่า "ตรวจสอบสถานะปัจจุบันก่อนกระทำการใดๆ โดยอิงจากความจำที่บันทึกไว้" คำบาลีเป็นแค่ป้ายชื่อ ข้อกำหนดเชิงวิศวกรรมต่างหากที่สำคัญในโค้ดและการ review

สำหรับทุกคำในตารางเดียว ดู BWOC Glossary ส่วนแกนกลางของแนวคิด — การ mapping 22 framework ฉบับเต็ม — อยู่ใน PHILOSOPHY.en.md

ปัญหา: การสร้าง agent หลายตัวนำไปสู่ความยุ่งเหยิง¶

Agent ตัวแรกที่สร้างนั้นไม่ซับซ้อน ตั้งชื่อ เขียน system prompt อาจเชื่อมต่อ tool สักหนึ่งสองตัว Agent ตัวที่สองก็ทำแบบเดิม พอถึงตัวที่ห้าก็เริ่มเห็นรอยแตก:

มี agent สามตัวที่จัดเก็บ memory ในรูปแบบที่เข้ากันไม่ได้ การ review แต่ละตัวต้องจำว่า "ตัวนี้" เก็บสถานะแบบไหน
Agent หนึ่งตัวผูกติดกับรูปแบบ response ของ Claude ถ้าเปลี่ยน backend ต้องเขียน prompt logic ใหม่
Agent สองตัวต้องส่งต่องานกัน แต่ไม่มีรูปแบบ handoff ที่ตกลงไว้ ต้อง hardcode โปรโตคอลเฉพาะกิจระหว่างทั้งสอง
Agent ให้ผลลัพธ์แปลกๆ ออกมา แต่ไม่สามารถย้อนหาสาเหตุ ไม่รู้ว่าการตัดสินใจก่อนหน้าใดนำไปสู่ response นั้น เพราะบันทึกแค่ output ไม่ได้บันทึกเจตนา
ผ่านไปหกเดือน ยังมี branch เก่าสามอัน และ worktree ที่ถูกทิ้งสองอัน ค้างอยู่ในโปรเจกต์ เพราะไม่มีใครเคยลบทิ้ง

นี่ไม่ใช่ failure mode ที่หายาก แต่เป็น failure mode มาตรฐานของการขยาย codebase ที่เต็มไปด้วย agent โดยไม่มีรากฐานที่มีหลักการ BWOC ถูกออกแบบมาเพื่อจัดการกับห้ามิตินี้โดยเฉพาะ และการออกแบบทุกส่วนของ framework สามารถย้อนกลับไปยังหนึ่งในนั้นได้

BWOC คืออะไร¶

BWOC (Buddhist Way of Coding) คือ specification และ CLI framework ที่ไม่ผูกติดกับ backend สำหรับการสร้าง รัน และกำกับดูแล AI coding agent implementation อ้างอิงเขียนด้วย Rust ส่งมอบเป็น bwoc CLI ผลลัพธ์หลักคือ agent template ที่ clone ได้ — โครงสร้างไดเรกทอรีของไฟล์ Markdown, shell script, และ symlink ที่ LLM backend ใดๆ ก็สามารถอ่านได้

สี่เสาหลักด้านสถาปัตยกรรม อธิบายตรงๆ:

1. หนึ่ง repository ต่อหนึ่ง agent¶

Agent แต่ละตัวอาศัยอยู่ในไดเรกทอรีของตัวเองที่ clone มาจาก template ไม่มี shared runtime ไม่มี central agent server ไม่มี framework singleton ที่ agent ทุกตัวต้องคุยด้วย agent คือ ไดเรกทอรี ทำให้ agent สามารถ fork ตรวจสอบ และ retire ได้อย่างอิสระโดยไม่กระทบตัวอื่น

2. Backend-neutral โดยดีฟอลต์¶

ไฟล์เดียว — AGENTS.md — คือเอกสารคำสั่งหลักของ agent ทุก backend ที่รองรับ (Claude, Codex, Kimi, Copilot, Ollama, หรือ OpenAI-compatible endpoint ใดๆ) อ่านไฟล์เดียวกันผ่าน symlink:

CLAUDE.md   → AGENTS.md
CODEX.md    → AGENTS.md
KIMI.md     → AGENTS.md
OLLAMA.md   → AGENTS.md

ไม่มี backend ใดได้สิทธิพิเศษในเอกสารหลัก การเพิ่ม backend ใหม่ใช้คำสั่งเดียว: ln -s AGENTS.md <BACKEND>.md AGENTS.md เป็น plain Markdown — ไม่มี YAML frontmatter ไม่มี wikilink ไม่มี vendor-specific syntax — ทำให้ LLM ใดๆ parse ได้โดยไม่ต้องแปลงข้อมูลล่วงหน้า

3. Memory แบบ persistent ที่รู้จักความไม่เที่ยง¶

Agent สะสมความรู้ข้ามเซสชันใน MEMORY.md ไฟล์ถูกจำกัดที่ 200 บรรทัด ขอบเขตนี้บังคับใช้โดย bwoc check ข้อจำกัดนี้บังคับให้เลือกอย่างมีสติ: agent และผู้ดูแลต้องตัดสินใจว่าอะไรสำคัญพอที่จะเก็บไว้ ซึ่งหมายความว่า memory file มีแต่สัญญาณที่มีคุณภาพ ไม่ใช่ noise รายการที่ล้าสมัยคาดว่าจะถูกตัดทิ้ง ไม่ใช่เก็บไว้ "เผื่อจะใช้"

4. ปลอดภัยสำหรับหลาย agent¶

Agent หลายตัวอยู่ร่วมใน workspace เดียว BWOC มี shared task list (Saṅgha teams), inter-agent messaging (signed envelope), และระบบ trust scoring ที่กั้นการส่งมอบข้อความขาเข้า daemon ของ agent ตรวจสอบ signature ของผู้ส่งและเช็ค trust criteria เจ็ดข้อก่อนยอมรับข้อความเข้า inbox การ coordinate เป็นแบบชัดเจนและตรวจสอบได้ ไม่ใช่แบบนัยๆ และเปราะบาง

bwoc CLI (Rust, cross-platform) ขับเคลื่อนทั้งหมดนี้: bwoc new, bwoc start, bwoc spawn, bwoc send, bwoc team, bwoc check, bwoc audit

เหตุใด framework ตะวันตกจึงยังไม่พอ¶

DDD, Clean Architecture, SOLID, และ Hexagonal Architecture ครอบคลุมด้านโครงสร้างอย่างละเอียด: วิธีแยก layer วิธีสร้างโมเดล domain วิธีควบคุม dependency แต่บางในมิติที่ agent system กดดันพอดี:

มิติ	สถานะใน framework ตะวันตก	สิ่งที่ agent system ต้องการ
สถานะตามเวลา	โมเดลโครงสร้าง สมมติว่าจัดการสถานะที่อื่น	การดูแลความไม่เที่ยงเป็นสิ่งสำคัญอันดับแรก — เมื่อใดเก็บ เมื่อใดตัด จะ timestamp อย่างไร
การ trace ความล้มเหลว	ระบุ exception บันทึก stack trace	ย้อนหา เงื่อนไข ที่นำไปสู่ความล้มเหลว ไม่ใช่แค่จุดที่ล้มเหลว
Lifecycle	Stateless service ไม่มี lifecycle	Arc ที่มีชื่อ: สร้าง, ทำงาน-พร้อมเปลี่ยนแปลง, และปล่อยวางสะอาด
ความไว้วางใจระหว่าง agent	ไม่ได้สร้างโมเดล (สมมติระบบเดียว)	เกณฑ์ความไว้วางใจที่ชัดเจน ข้อความแบบ signed, การส่งมอบแบบกั้น
ความปลอดภัยดีฟอลต์	"เพิ่ม authorization ทีหลัง"	กฎพื้นฐานที่ไม่สามารถต่อรองได้ ใช้บังคับก่อนงาน feature ใดๆ
ขอบเขต specification	"เพิ่มตอนที่อยู่ตรงนี้แล้ว"	หลักการสำหรับการปฏิเสธที่จะเพิ่ม: spec ที่เล็กกว่าชนะ spec ที่สมบูรณ์กว่า

Agent system ไม่ใช่ stateless service มี identity, memory, การเติบโต และความสัมพันธ์กับ agent อื่น framework ตะวันตกไม่ได้ออกแบบมาสำหรับรูปร่างของระบบแบบนี้ BWOC ยืมมาจาก framework การวิเคราะห์ของพุทธศาสนาเพราะ framework เหล่านั้นมีความแม่นยำและมีโครงสร้างที่ดีเกี่ยวกับความไม่เที่ยง, ปฏิจจสมุปบาท, เจตนา และวินัย ซึ่งเป็นความกังวลเดียวกัน ในคำศัพท์ที่ต่างกัน

นี่ไม่ใช่การอ้างว่าพุทธศาสนาสอนสถาปัตยกรรมซอฟต์แวร์ แต่เป็นการอ้างว่า framework บางอย่างที่พัฒนาในประเพณีนั้นมีความแม่นยำ มีโครงสร้างดี และพอ portable พอที่จะเป็น engineering thinking aid ในโดเมนใหม่ได้

ตารางสมบูรณ์: ปัญหาวิศวกรรม → framework¶

specification เต็มรูปแบบอยู่ใน PHILOSOPHY.en.md ด้านล่างคือตารางอ้างอิง — ความหมายเชิงวิศวกรรมก่อน ป้ายชื่อบาลีในวงเล็บ:

ปัญหาเชิงวิศวกรรม	Framework (บาลี)	สิ่งที่ได้รับ
โครงสร้างการแก้ปัญหา	อริยสัจ 4 (Ariyasacca 4)	โครงกระดูกสี่ขั้น: ระบุปัญหา (ทุกข์) → หาต้นเหตุ (สมุทัย) → กำหนดสถานะสำเร็จ (นิโรธ) → วางแผนดำเนินการ (มรรค) ใช้สำหรับ PRD และการวางแผนงาน
Functional requirements	มรรค 8 (Magga 8)	แปดเสาหลักของการดำเนินงานที่ถูกต้อง: ทัศนะ เจตนา การสื่อสาร การกระทำ การดำรงชีพ ความพยายาม ความจำ สมาธิ map ไปยังหัวข้อ SRS
สถาปัตยกรรมระบบ	ขันธ์ 5 (Khandha 5)	ห้าองค์ประกอบ: layout ไฟล์, I/O, memory, logic, runtime map ไปยังเอกสาร ARCHITECTURE
สถานะและความไม่เที่ยง	ไตรลักษณ์ (Tilakkhaṇa)	ทุกอย่างไม่เที่ยง (อนิจจา) → memory ต้องมี timestamp และตัดทิ้ง branch ที่ล้าสมัยคือทุกข์ → ลบทิ้ง ไม่ยึดติดสถานะในอดีต (อนัตตา) → ปล่อยวางสะอาด
การวิเคราะห์ความล้มเหลว	ปฏิจจสมุปบาท (Paṭiccasamuppāda)	ย้อนหาเงื่อนไขไปข้างหลัง: สิ่งนี้มีเพราะสิ่งนั้นมี error ที่มองเห็นมักไม่ใช่ปัญหารากฐาน ป้องกันการแก้ไขแบบผิวเผิน
Audit logging	กรรม 3 (Kamma 3)	สามช่องทางบันทึกที่แตกต่างกัน: การดำเนินการไฟล์และ commit (สิ่งที่ทำ), ข้อความและ log (สิ่งที่พูด), การตัดสินใจและแผนงาน (สิ่งที่ตั้งใจ)
Observability	สติปัฏฐาน 4 (Satipaṭṭhāna 4)	สี่เป้าหมายการสังเกต: สถานะไฟล์และ working directory (กาย), ผลลัพธ์ tool และ I/O events (เวทนา), โหมด agent — วางแผน/กระทำ/ตรวจสอบ (จิต), กฎที่ใช้บังคับและ pattern ที่ match (ธรรม) map ไปยัง metrics, log, trace, และสถานะ
Agent lifecycle	ภาวนา 4 (Bhāvanā 4)	สี่ขั้นการเติบโต: template ถูก materialize (incarnation), งานแรกเสร็จ (onboarding), การดำเนินงานที่มั่นคง (ความสามารถ), pattern ที่แบ่งปันกับผู้อื่น (การเป็นพี่เลี้ยง)
Self-improvement	ปัญญา 3 (Paññā 3)	สามช่องทางการพัฒนา: เรียนรู้จากเอกสารและตัวอย่าง (การศึกษา), สังเคราะห์โดยการวางแผนและการดึง pattern (การใช้เหตุผล), เรียนรู้จากการปฏิบัติผ่าน feedback และการทบทวน (การปลูกฝัง) ดู บทพัฒนาตนเอง
Capability maturity	อริยทรัพย์ 7 (Ariya-dhana 7)	มาตรวัดความสามารถเจ็ดระดับ: ความไว้วางใจในธรรมเนียม (L1), ปฏิบัติตามกฎ (L2), ตระหนักถึงข้อผิดพลาด (L3), ความลึกของความรู้ (L4), แบ่งปันความสามารถ (L5), การตัดสินใจอิสระ (L6) map ไปยัง tag `maturity: L1..L6` ในไฟล์ skill slot
Error UX disposition	พรหมวิหาร 4 (Brahmavihāra 4)	สี่ท่าที: น้ำเสียงเป็นมิตรและตรงไปตรงมา (เมตตา), แนะนำวิธีแก้ไม่ใช่แค่รายงาน error (กรุณา), ยอมรับเมื่อผู้อื่นถูก (มุทิตา), คงความสมดุลแม้ผู้ใช้หงุดหงิด (อุเบกขา)
ความไว้วางใจระหว่าง agent	กัลยาณมิตร 7 (Kalyāṇamitta 7)	เจ็ดเกณฑ์ boolean ที่ peer agent ต้องผ่านก่อนข้อความจะได้รับการยอมรับ: มอบหมายงานได้สะดวก, น่าเคารพด้านความสามารถ, ช่วยให้เราพัฒนา, พูดความจริงที่เป็นประโยชน์, รับ feedback ได้, อธิบายเชิงลึกได้, ไม่นำไปในทางผิด บังคับใช้โดย trust gate ของ daemon
การ coordinate ระหว่าง agent	สาราณียธรรม 6 (Sāraṇīyadhamma 6)	หกคุณสมบัติการ coordinate: ความปรารถนาดีในสามช่องทางการกระทำต่อ agent อื่น, การแบ่งปันทรัพยากรอย่างยุติธรรม, กฎร่วม, เป้าหมายที่สอดคล้องกัน
Threat modeling	ตัณหา 3 (Taṇhā 3)	สามหมวดภัยคุกคาม: ความอยากในสิ่งกระตุ้น → prompt injection และ social engineering; ความอยากในการดำรงอยู่ → privilege escalation; ความอยากในการทำลาย → data loss และการกระทำที่ทำลายล้าง
ความปลอดภัยพื้นฐาน	ศีล 5 (Sīla 5)	ห้ากฎที่ไม่สามารถต่อรองได้: ห้าม `rm -rf` root ของ repo, ห้าม commit secret, ห้าม spoof identity ของ agent, ห้ามข้ามผ่าน verification gate, ห้าม side-effect ที่ไม่ได้ประกาศ
Fleet governance	อปริหานิยธรรม 7 (Aparihāniya-dhamma 7)	เจ็ดเงื่อนไขที่ทำให้ fleet ของ agent หลายตัวไม่เสื่อมถอย: sync point สม่ำเสมอ, เริ่ม/จบเซสชันอย่างประสานงาน, การเปลี่ยนธรรมเนียมผ่านกระบวนการ, เคารพลำดับชั้น template version, ปกป้อง agent และผู้ใช้ที่เปราะบาง, ความสมบูรณ์ของ registry และ schema ที่ใช้ร่วมกัน, ปกป้อง agent อาวุโสที่ไว้วางใจ
ขอบเขต specification	อจินไตย 4 (Acinteyya 4)	การสร้างโมเดลโดยเจตนาว่าอะไรที่ไม่ควรใช้เหตุผลถึง: เจตนาของ LLM provider, ส่วนในของโมเดล, ผลลัพธ์ทางธุรกิจระยะยาว, ขอบเขตนอกระบบนี้ ป้องกัน analysis paralysis และการ over-specify
ตัวชี้วัดคุณภาพงาน	อิทธิบาท 4 (Iddhipāda 4)	สี่ KPI: ทำงานภายในโดเมนที่ประกาศไว้ (ฉันทะ), อัตราการทำงานเสร็จ (วิริยะ), การปฏิบัติตาม gate (จิตตะ), ตัวชี้วัดการพัฒนาตนเอง (วิมังสา)
การรับรู้บริบท	สัปปุริสธรรม 7 (Sappurisadhamma 7)	เจ็ดมิติสถานการณ์: สาเหตุและหลักการ, ผลลัพธ์และเป้าหมาย, ตนเองและขีดจำกัด, ขอบเขต, เวลา, ชุมชน, บุคคล ใช้สำหรับการวิเคราะห์ stakeholder ใน PRD และการสแกนบริบทก่อนงาน
หลักการ UX	สังคหวัตถุ 4 (Saṅgahavatthu 4)	สี่ท่าทีต่อผู้ใช้: ค่าดีฟอลต์ที่ใจกว้าง, ข้อความ error ที่ชัดเจนและเป็นมิตร, การกระทำที่เป็นประโยชน์ต่อผู้ใช้, การปฏิบัติที่เท่าเทียมไม่ว่าผู้ใช้จะคุ้นเคยแค่ไหน
ทิศทางความพยายามที่ถูกต้อง	ปธาน 4 (Padhāna 4)	สี่ทิศทาง: ป้องกันสิ่งไม่ดีใหม่ (lint), ละสิ่งไม่ดีที่มีอยู่ (format, refactor), พัฒนาสิ่งดีใหม่ (test ใหม่), รักษาสิ่งดีที่มีอยู่ (regression) map ไปยังลำดับ verification gate

arc ที่อยู่ใต้ทั้งหมดนี้คือ อุปปาท · ฐิติ · วาย triad จาก AN 3.47: เกิดขึ้น, ตั้งอยู่พร้อมเปลี่ยนแปลง, ดับไป ทุก BWOC artifact — งาน, เซสชัน, worktree, agent ทั้งหมด — ดำเนินตาม arc นี้ 22 framework กำหนดวินัยภายในแต่ละเฟสของ arc

ห้าหลักการที่กำกับ tradeoff ที่ยากที่สุด¶

ห้าหลักการเหล่านี้ปรากฏตลอดทั้ง framework ถูกนำมาใช้เมื่อการออกแบบสองแบบที่ดีขัดแย้งกัน แต่ละหลักการระบุเป็นกฎวิศวกรรมที่เรียบง่าย ป้ายชื่อบาลีคือตัวย่อที่จะเห็นในเอกสารและ commit message

1. ตรวจสอบก่อนกระทำ (Yoniso Manasikāra)¶

Memory คือการอ้างสิทธิ์จากอดีต ก่อนดำเนินการตามสถานะที่จำไว้ — path ไฟล์, ชื่อ branch, รูปแบบ API, การตัดสินใจก่อนหน้า — ต้องตรวจสอบว่าการอ้างสิทธิ์นั้นยังเป็นจริงตามสถานะปัจจุบันของระบบ

ในทางปฏิบัติ: ก่อนเขียนไฟล์ที่ agent เห็นครั้งสุดท้ายสามเซสชันที่แล้ว ต้องอ่านก่อน ก่อนรันคำสั่งที่ agent เคยรันมาก่อน ต้องตรวจว่า environment ไม่ได้เปลี่ยนแปลง หลักการนี้ป้องกัน failure class ทั้งหมดที่เกิดจากการกระทำโดยอิงสมมติฐานที่ล้าสมัย

2. ปริมาณที่เหมาะสม ไม่ใช่ปริมาณสูงสุด (Mattaññutā)¶

สร้าง specification ที่เล็กที่สุดที่ load-bearing ขีดจำกัด MEMORY.md ที่ 200 บรรทัดคือการบังคับใช้หลักการนี้ที่มองเห็นชัดที่สุด แต่ใช้ได้ทุกที่: ไม่เพิ่ม slot file ที่ไม่สมควรมีที่ยืน ไม่เพิ่มหัวข้อ spec ที่ไม่จำเป็น ไม่ขยายการออกแบบเพื่อครอบคลุมกรณีที่ยังไม่เกิดขึ้น

เอกสาร VISION ของ framework ระบุโดยตรงว่า "spec ที่เล็กกว่าชนะ spec ที่สมบูรณ์กว่า ยกเว้นเมื่อความสมบูรณ์ load-bearing" ไม่ใช่ความชอบด้านความเรียบง่ายในเชิงสุนทรียศาสตร์ แต่เป็นการตระหนักว่าทุกบรรทัดของ specification มีต้นทุนในการดูแลและความซับซ้อนทางปัญญา

สำหรับผู้ดูแล หลักการนี้ปรากฏเป็น: ตัดออกก่อนขยาย ลดก่อนเพิ่ม ถ้า memory file เต็ม 200 บรรทัด ตัดสินใจว่าจะทิ้งอะไร ไม่ใช่ขยายขีดจำกัด

3. ไม่ยึดติดสถานะที่ล้าสมัย (Anattā)¶

เมื่องานเสร็จ ทำความสะอาด: ลบ branch ลบ worktree ตัดรายการ memory ที่ไม่ถูกต้องอีกต่อไป อย่าเก็บสถานะ "เผื่อจะใช้" Identity ของ agent ไม่ได้อยู่ที่สถานะที่สะสม แต่อยู่ที่ความสามารถปัจจุบันและงานปัจจุบัน

ในโค้ด: branch ที่ล้าสมัยเป็นสัญญาณว่าผู้ที่เป็นเจ้าของไม่ได้ปฏิบัติ Anattā ในการออกแบบ agent: memory file ที่แน่นไปด้วยรายการที่ล้าสมัยไม่ใช่บริบทที่อุดมสมบูรณ์ แต่เป็น noise ที่ลด performance ในอนาคต

bwoc check จะแจ้งเตือน MEMORY.md ที่เกิน 200 บรรทัด การตอบสนองที่ถูกต้องไม่ใช่ขยายขีดจำกัด แต่คือตัดทิ้ง

4. ปฏิบัติต่อทุก backend อย่างเท่าเทียม (Samānattatā)¶

ไม่มี backend ใดได้สิทธิพิเศษใน specification หลัก AGENTS.md ต้อง parse ได้โดย LLM backend ใดๆ โดยไม่ต้องแปลงข้อมูล การออกแบบที่ทำงานบน Claude แต่ต้องเขียนใหม่สำหรับ Ollama ยังไม่สมบูรณ์

ในทางปฏิบัติ: ใช้ placeholder {{camelCase}} สำหรับทุกค่าที่ configure ได้ใน AGENTS.md ไม่ hardcode model ID, ชื่อ tool, หรือรูปแบบ response เฉพาะ vendor ในเอกสารคำสั่งหลัก รัน bwoc check เพื่อตรวจสอบ neutrality การ optimize เฉพาะ backend อยู่ในไฟล์ companion ไม่ใช่ใน AGENTS.md

5. ธรรมเนียมร่วมชนะความชอบส่วนตัว (Sīlasāmaññatā)¶

Agent ทุกตัวใน workspace ดำเนินตามธรรมเนียมเดียวกัน: conventions.md เดียวกัน, schema manifest เดียวกัน, กฎ neutrality เดียวกัน, gate bwoc check เดียวกัน ความชอบส่วนตัวของผู้เขียน agent ในธรรมเนียมการตั้งชื่อที่ต่างออกไปหรือรูปแบบ memory ที่ต่างออกไปไม่ override มาตรฐานที่ใช้ร่วมกัน

สิ่งนี้สำคัญเพราะธรรมเนียมคือ interface ระหว่าง agent เมื่อสอง agent แลกเปลี่ยนข้อความ ทั้งสองฝ่ายต้องใช้รูปแบบเดียวกัน เมื่อผู้ดูแลตรวจสอบ workspace ที่มี agent หกตัว ต้องการให้ทั้งหกมี layout เดียวกัน

ธรรมเนียมถูกบังคับใช้โดยกลไก bwoc check ซึ่งรัน neutrality audit, ตรวจสอบ config.manifest.json เป็น JSON ที่ well-formed, และแจ้งเตือนการละเมิด MEMORY.md การตรวจสอบได้รับการออกแบบให้รันใน CI

Arc: ทุก BWOC object มีการเกิด การดำรงอยู่ และการดับที่สะอาด¶

กรอบที่เชื่อมทุกอย่างเข้าด้วยกันคือ lifecycle triad — อุปปาท, ฐิติ-พร้อมเปลี่ยนแปลง, วาย — จาก Saṅkhata Sutta (AN 3.47) ทุก BWOC object ดำเนินตาม arc นี้:

เฟส	ชื่อธรรมดา	สิ่งที่ agent ทำ
อุปปาท (Arising)	เกิด	Identity ถูกสร้าง Agent ถูก clone มาจาก template กำหนด persona ประกาศความสามารถ แก้ manifest
ฐิติ (Persisting-with-change)	ทำงาน	Agent ทำงาน วางแผนด้วยโครงสร้างปัญหาสี่ขั้น กระทำภายในแปดเสาหลักด้านฟังก์ชัน จำด้วย impermanence-aware memory สื่อสารด้วยโปรโตคอล UX สี่ disposition สถานะพัฒนาแต่ภายใต้วินัย
วาย (Passing-away)	ทำความสะอาด	งานหรือเซสชันสิ้นสุด Worktree ถูกลบ branch ปล่อยวาง memory ถูกตัด งานปิด ไม่ยึดติด

นี่ไม่ใช่อุปมา แต่คือโครงสร้างจริงของ bwoc new → bwoc start → bwoc stop → bwoc retire คำสั่ง lifecycle implement arc 22 framework กำหนดวินัยภายในแต่ละเฟส

เหตุผลที่ควรนำ BWOC ไปใช้¶

คุณกำลังสร้าง agent มากกว่าหนึ่งตัว¶

คุณค่าของรากฐานที่ใช้ร่วมกันเติบโตตามจำนวน agent หนึ่ง agent: overhead ในการเรียนรู้ template อาจยังไม่คุ้ม สาม agent ขึ้นไป: ความสอดคล้องของทุกตัว — รูปแบบ memory เดียวกัน, audit trail เดียวกัน, check gate เดียวกัน — เริ่มมีความสำคัญ สิบ agent ใน workspace เดียว: ธรรมเนียมที่ใช้ร่วมกันและโครงสร้างพื้นฐานด้านความปลอดภัยแบบ multi-agent เป็น load-bearing

คุณใส่ใจเรื่อง backend portability¶

ถ้าเคยย้าย agent จาก LLM หนึ่งไปอีกตัวและพบว่า system prompt ของคุณเขียนด้วย idiom แบบ Claude ที่ไม่ translate ออกมา คุณรู้ปัญหาแล้ว การออกแบบ backend-neutral ของ BWOC ทำให้สิ่งนี้เป็นข้อจำกัดอันดับแรก ไม่ใช่การแก้ไขภายหลัง

คุณต้องการ agent ที่ตรวจสอบและกู้คืนได้¶

audit trail สามช่องทาง (สิ่งที่ agent ทำ, พูด, ตั้งใจ) และโครงสร้าง problem-solving spine (ปัญหา → ต้นเหตุ → สถานะสำเร็จ → แผน) ทำให้สามารถย้อนกลับ เหตุผล ที่ agent ให้ผลลัพธ์ที่กำหนด สิ่งนี้มีค่าระหว่าง debug และระหว่างการทบทวนหลังเหตุการณ์

คุณต้องการแรงกดดันในตัวต่อต้าน over-engineering¶

ขีดจำกัด 200 บรรทัดของ memory, หลักการ "spec ที่เล็กกว่าชนะ", framework ขอบเขต, และ gate bwoc check ทั้งหมดสร้างแรงกดดันโครงสร้างไปสู่การออกแบบที่ lean และมีสติ ไม่ใช่แค่ความชอบด้านสไตล์ แต่ถูกบังคับใช้โดยกลไก

คุณต้องการคำศัพท์ร่วมสำหรับ tradeoff ด้านการออกแบบ¶

เมื่อวิศวกรสองคนไม่เห็นด้วยว่าจะขยาย memory file หรือตัดทิ้ง "Mattaññutā บอกให้ตัด ถ้าไม่ load-bearing" เป็นข้อโต้แย้งที่สั้นกว่าและแม่นยำกว่าการเริ่มต้นถกเถียง tradeoff พื้นฐานใหม่ทุกครั้ง คำศัพท์ได้รับที่ทางของมันโดยทำให้การตัดสินใจออกแบบที่เกิดซ้ำชัดเจนและแก้ไขได้เร็ว

BWOC ไม่เหมาะสำหรับใคร¶

BWOC ไม่ใช่รากฐานที่เหมาะสมถ้า:

คุณต้องการ time-to-first-token ที่เร็วที่สุด BWOC optimize สำหรับ agent ที่มีหลักการ, ตรวจสอบได้, กู้คืนได้ มันเพิ่มโครงสร้างที่ prototype ด่วนไม่ต้องการ
คุณกำลังสร้าง agent เพียงตัวเดียวแบบชั่วคราว คุณค่าของ framework อยู่ที่ความสอดคล้องข้ามฝูง agent ตามเวลา สำหรับ agent ระดับ script ที่ใช้ครั้งเดียว overhead ไม่คุ้มค่า
คุณต้องการ central runtime หรือ orchestration server BWOC เป็น decentralized โดยเจตนา: ไม่มี central agent server ไม่มีฐานข้อมูล ไม่มี container runtime ถ้าสถาปัตยกรรมของคุณต้องการ central broker รูปแบบของ BWOC ไม่ตรง
คุณไม่สามารถยอมรับวิธีการ specification-first BWOC บันทึกเอกสารก่อน implement Markdown specification คือ source of truth โค้ดตามหลักคำสอน ถ้าวัฒนธรรมของทีมคือ "code ก่อน document ทีหลัง" วินัยที่จำเป็นจะรู้สึกเป็นอุปสรรค

Tradeoff การออกแบบและ non-goal¶

ระบุตรงๆ จากเอกสาร VISION:

BWOC ไม่ใช่ศาสนา ไม่ใช่คู่มือการนั่งสมาธิ ไม่ใช่การรับรองครู, สายธรรม, หรือประเพณีใด

BWOC ไม่แทนที่ DDD, Clean Architecture, หรือ SOLID มันขยายสิ่งเหล่านั้นไปสู่มิติที่ไม่ได้ออกแบบมาเพื่อจัดการ คุณสามารถใช้ BWOC ควบคู่กับ framework เหล่านั้น

bwoc path ดีฟอลต์เป็น zero-dependency CLI orchestrator มัน exec vendor agentic CLI และไม่ทำ model-API call bwoc-harness runtime เป็น opt-in สำหรับ self-hosted backend ผู้ใช้ที่ทำงานกับ cloud backend เท่านั้นไม่เคย pull runtime dependency

ดีฟอลต์คือไม่เพิ่ม เมื่อไม่แน่ใจ หลักการออกแบบของ framework เองใช้บังคับ: spec ที่เล็กกว่าชนะ spec ที่สมบูรณ์กว่า BWOC ไม่สร้างโมเดลสิ่งที่ยังไม่เกิดขึ้นเป็นปัญหาวิศวกรรมจริง

บางสิ่งถูกสร้างโมเดลโดยเจตนาว่าไม่ต้องสร้างโมเดล — เจตนาของ LLM provider, ส่วนในของโมเดล, ผลลัพธ์ทางธุรกิจระยะยาว, ขอบเขตนอกระบบนี้ เหล่านี้คือ Acinteyya (สี่อจินไตย): ขอบเขตของ specification ไม่ใช่ช่องว่างที่ต้องเติม

Stack โดยสรุป¶

┌──────────────────────────────────────────────────────┐
│  Fleet Governance (อปริหานิยธรรม 7)                  │ ← ระดับองค์กร
├──────────────────────────────────────────────────────┤
│  Threat Model (ตัณหา 3) + Baseline Safety (ศีล 5)    │ ← ความปลอดภัย
├──────────────────────────────────────────────────────┤
│  Lifecycle (ภาวนา 4) + Self-improvement (ปัญญา 3)    │ ← การเติบโตของ agent
├──────────────────────────────────────────────────────┤
│  Coordination (สาราณียธรรม 6) + Trust (กัลยาณมิตร 7) │ ← Interconnect
├──────────────────────────────────────────────────────┤
│  UX (สังคหวัตถุ 4) + Error (พรหมวิหาร 4)            │ ← ชั้นผู้ใช้
├──────────────────────────────────────────────────────┤
│  Functional requirements (มรรค 8)                    │ ← SRS
├──────────────────────────────────────────────────────┤
│  Architecture (ขันธ์ 5)                              │ ← ส่วนประกอบ
├──────────────────────────────────────────────────────┤
│  Observability (สติปัฏฐาน 4)                         │ ← Cross-cutting
├──────────────────────────────────────────────────────┤
│  Engine of work (อิทธิบาท 4)                         │ ← Runtime
├──────────────────────────────────────────────────────┤
│  State & Audit (ไตรลักษณ์ + กรรม 3)                  │ ← รากฐาน
├──────────────────────────────────────────────────────┤
│  Failure analysis (ปฏิจจสมุปบาท)                     │ ← เมื่อเกิดปัญหา
├──────────────────────────────────────────────────────┤
│  Thinking method (โยนิโสมนสิการ + อจินไตย 4)          │ ← วิธีคิด
└──────────────────────────────────────────────────────┘
        Problem-solving cycle (อริยสัจ 4) — ตลอดทั้งระบบ
        Context sensing (สัปปุริสธรรม 7) — ตลอดทั้งระบบ

ดูเพิ่มเติม¶

PHILOSOPHY.en.md — 22 framework ฉบับเต็ม; ข้อมูลอ้างอิงที่เป็นบรรทัดฐาน เมื่อบทนี้และ PHILOSOPHY ขัดแย้งกัน PHILOSOPHY ชนะ
VISION.md — เจตนาการออกแบบ, ช่องว่างที่ BWOC เติม, ห้าหลักการกำกับ, และ non-goal
GLOSSARY.en.md — ทุกคำบาลีใน BWOC, ความหมายเชิงวิศวกรรมหนึ่งบรรทัดต่อคำ
คู่มือ Agents — incarnation, slot layout, manifest, gate bwoc check
บท Self-improvement — ปัญญา 3 ในทางปฏิบัติ: วิธีที่ agent เรียนรู้จากการศึกษา การใช้เหตุผล และ feedback
Glossary (handbook) — ตารางค้นหาคำระดับ handbook
BWOC Framework repository — source of truth สำหรับโค้ดและ spec ฉบับเต็ม