เส้นทางการตั้งค่าและซ่อมแซมตามปกติมีการจัดทำเอกสารไว้ในเอกสารการติดตั้ง, CLI และ Gateway ส่วนเส้นทางเฉพาะแพลตฟอร์ม Windows มีการติดตามในแถว Windows ผ่าน WSL2 และ Windows แบบเนทีฟ

สถาปัตยกรรมหลัก การยืนยันตัวตน การจับคู่ เอกสารโปรโตคอล เอกสารดีมอน และคู่มือปฏิบัติงาน CLI มีเนื้อหาครอบคลุมและเป็นปัจจุบัน

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

เอกสารมีคุณภาพสูงและมีการพัฒนาอย่างต่อเนื่อง ระดับความพร้อมขึ้นอยู่กับความคงทนของทรานสคริปต์ คุณภาพของ Compaction และความเท่าเทียมกันระหว่างไคลเอนต์

ช่องทางจำนวนมากใช้สัญญาการส่งและการกำหนดเส้นทางของ Gateway ร่วมกัน แต่ลักษณะการทำงานของช่องทางจะแตกต่างกันไปตาม API ต้นทางและข้อจำกัดของนโยบายบัญชี

มีเอกสารเกี่ยวกับ OTel, Prometheus, การบันทึกล็อก และการวินิจฉัยแล้ว แต่ยังต้องปรับปรุงระดับความพร้อมสำหรับสาธารณะในส่วน "สิ่งที่ผู้ดูแลระบบควรตรวจสอบก่อน"

มีการจัดทำเอกสาร Web UI ซึ่งครอบคลุมขั้นตอนการจับคู่ แชต PWA การสนทนา การแจ้งเตือนแบบพุช และ Gateway ระยะไกล เลื่อนระดับหลังจากจัดทำตารางคะแนนสำหรับหลายเบราว์เซอร์และ PWA บนอุปกรณ์เคลื่อนที่แล้ว

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

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

มีเอกสารและใช้งานได้ แต่หลักฐานจากสถานการณ์ควรครอบคลุมการส่งมอบแบบไม่มีผู้ดูแล การลองใหม่ และการมองเห็นความล้มเหลว

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

มีการใช้งานหลายรูปแบบใน Control UI, แอป และผู้ให้บริการ ต้องมีตารางประเมินเวลาแฝง รูปแบบความล้มเหลว และการตั้งค่าก่อนเข้าสู่เบตา

มีอยู่ในเอกสารและซอร์สโค้ด แต่มองเห็นได้ไม่ชัดเจนนักในฐานะเวิร์กโฟลว์หลักของผู้ใช้ จำเป็นต้องกำหนดสถานการณ์การใช้งานอย่างชัดเจน

มีเอกสารสาธารณะและแนวคิดระบบนิเวศแล้ว แต่ยังต้องมีตารางประเมินการติดตั้ง ความน่าเชื่อถือ การอัปเดต การย้อนกลับ และความเข้ากันได้

OpenClaw App SDK เป็นสัญญาสำหรับแอปภายนอกที่แยกออกจากรันไทม์ Gateway และ Plugin SDK อย่างชัดเจน คะแนนปัจจุบันแสดงเส้นทาง @openclaw/sdk ที่ใช้งานได้จริง โดยยังมีช่องว่างด้านการจัดแพ็กเกจสาธารณะ การค้นพบอัตโนมัติ การอนุมัติ ตัวช่วย และความเข้ากันได้

แนะนำให้ใช้รันไทม์ Node มีเอกสารสำหรับบริการผู้ใช้ systemd และมีคำแนะนำที่ครอบคลุมสำหรับ VPS/คอนเทนเนอร์

มีเอกสารอธิบายเส้นทางบริการ LaunchAgent, โหมด Gateway แบบภายใน/ระยะไกล, การติดตั้ง CLI และการผสานรวมแอป

มีการเผยแพร่อย่างเป็นทางการผ่าน Google Play มีการดูแลเอกสารสำหรับการสร้างและเรียกใช้จากซอร์สโค้ด และมีการจัดทำเอกสารให้แอป Android เป็นโหนดคู่หูทั่วไปสำหรับผู้ใช้

มีการเผยแพร่อย่างเป็นทางการผ่าน App Store มีเอกสารเกี่ยวกับการแจ้งเตือนแบบพุชที่ทำงานผ่านรีเลย์ และแอป iOS ได้รับการระบุในเอกสารว่าเป็นโหนดคู่หูตามปกติสำหรับผู้ใช้

มีเอกสารการติดตั้งและเป็นแนวทางการปรับใช้ที่ใช้กันทั่วไป เลื่อนระดับเมื่อการทดสอบควันประจำรุ่นบันทึกพฤติกรรมการอัปเกรดและวอลุ่มได้อย่างสม่ำเสมอ

แนวทางที่แนะนำสำหรับ Windows พร้อมคำแนะนำเกี่ยวกับ systemd/บริการผู้ใช้และเอกสารลำดับการบูต เลื่อนระดับหลังจากมีตารางคะแนนการติดตั้ง/อัปเดตซ้ำหลายครั้ง

มีเอกสารแพลตฟอร์มและเส้นทาง Gateway ใช้ Linux เป็นพื้นฐาน ต้องมีหลักฐานการทดสอบ smoke ของรุ่นเผยแพร่บนฮาร์ดแวร์เฉพาะจึงจะเลื่อนไประดับที่สูงขึ้นได้

มีแอปแถบเมนูที่ครบครัน การอนุญาต โหมด Node, Canvas, การปลุกด้วยเสียง, WebChat และโหมดระยะไกล แต่ยังเปลี่ยนแปลงรวดเร็วเกินกว่าจะจัดเป็นระดับเสถียร

ขั้นตอนหลักของ CLI/Gateway ใช้งานได้ แต่เอกสารยังคงแนะนำ WSL2 เพื่อประสบการณ์ที่สมบูรณ์ และระบุข้อควรระวังสำหรับการใช้งานแบบเนทีฟ

การโฮสต์บน Kubernetes เป็นแนวทางการปรับใช้คลัสเตอร์ที่ใช้ Kustomize โดยเฉพาะ คะแนนปัจจุบันแสดงให้เห็นว่ามีแนวทางการปรับใช้ขั้นต่ำที่ใช้งานได้จริง แต่ยังมีช่องว่างด้าน CI สำหรับ Kubernetes โดยเฉพาะ การจัดแพ็กเกจ ingress/TLS/NetworkPolicy การสำรองและกู้คืน และการเสริมความปลอดภัยสำหรับการเปิดให้เข้าถึงในระบบใช้งานจริง

ขั้นตอนการติดตั้งทางเลือก ต้องมีคำมั่นด้านการสนับสนุนที่ชัดเจนยิ่งขึ้นก่อนเลื่อนระดับเป็นอัลฟา/เบตา

ซอร์สมีส่วนของแอป/ส่วนขยายสำหรับ Watch แต่เอกสารสาธารณะยังไม่ได้นำเสนอสิ่งนี้เป็นฟีเจอร์สำหรับผู้ใช้

เอกสารระบุว่ามีแผนพัฒนาแอปคู่หูแบบเนทีฟสำหรับ Linux ปัจจุบัน Gateway คือแนวทางที่รองรับบน Linux

อยู่ในแผนเท่านั้น

เอกสารเชิงลึกและครอบคลุมฟีเจอร์อย่างกว้างขวาง เส้นทางเสียง/การมอบหมายงานควรได้รับการประเมินแยกเป็นเบตา/อัลฟาต่อไป

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

เอกสารแชนเนลและพื้นผิวการกำหนดเส้นทางที่รองรับอย่างเต็มรูปแบบ ต้องมีตารางประเมินสถานการณ์การติดตั้งในเวิร์กสเปซและการดูแลระบบ

iMessage ที่รองรับทำงานผ่าน imsg บนโฮสต์ macOS Messages ที่ลงชื่อเข้าใช้แล้ว ส่วนการกำหนดค่า BlueBubbles แบบเดิมจำเป็นต้องย้ายข้อมูล ต้องแสดงข้อควรระวังเกี่ยวกับสิทธิ์ของ macOS, ตัวครอบ SSH, SIP/API ส่วนตัว และการย้ายข้อมูลไว้อย่างชัดเจน

เส้นทางหลักมีความสำคัญและมีเอกสารประกอบ แต่ความผันผวนของ Baileys/เซสชันต้นทางทำให้ยังอยู่ต่ำกว่าระดับเสถียร

รองรับผ่าน Plugin ที่รวมมาให้ ต้องมีตารางคะแนนสำหรับบริดจ์ การยืนยันตัวตน และวงจรชีวิตของห้อง

ช่องทางที่มีเอกสารประกอบ แต่การตั้งค่าระดับองค์กร/ผู้ดูแลระบบเพิ่มความเสี่ยงด้านระดับความพร้อม

ขั้นตอนการยืนยันตัวตน/การดูแลระบบสำหรับองค์กรจำเป็นต้องมีหลักฐานสถานการณ์อย่างชัดเจน