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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

มีเอกสารสำหรับพาธบริการ LaunchAgent, โหมด Gateway แบบ local/remote, การติดตั้ง CLI และการผสานรวมแอปแล้ว

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

เส้นทาง Windows ที่แนะนำ พร้อมคำแนะนำ systemd/user-service และเอกสารลำดับการบูต โปรโมตหลังจากมีสกอร์การ์ดการติดตั้ง/อัปเดตซ้ำหลายครั้ง

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

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

มีช่องทาง Google Play สาธารณะแล้ว แต่เอกสารของแอปยังคงอธิบายการสร้างใหม่ว่าเป็นอัลฟามาก และระบุงานเพิ่มความแข็งแกร่งสำหรับการเผยแพร่

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

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

ตัวอย่างภายใน / ระดับซูเปอร์อัลฟา มี TestFlight และโฟลว์พุชที่มีรีเลย์รองรับแล้ว แต่ยังไม่มีการเผยแพร่สาธารณะ

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

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

เอกสารระบุว่าแอปคู่ขนาน Linux แบบเนทีฟอยู่ในแผน; Gateway เป็นเส้นทาง Linux ที่รองรับในปัจจุบัน

วางแผนไว้เท่านั้น

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

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

เอกสารช่องทางและพื้นผิวการกำหนดเส้นทางระดับเฟิร์สคลาส ต้องมี scorecard สำหรับสถานการณ์การติดตั้ง/ผู้ดูแลระบบของพื้นที่ทำงาน

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

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

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

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

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

มีเอกสารช่องทางที่รองรับแล้ว แต่ยังต้องมีหลักฐานการติดตั้งและการเชื่อมต่อใหม่ที่แข็งแรงขึ้น

ความครอบคลุมระดับภูมิภาคที่สำคัญ แต่ควรปรับเทียบระดับการรองรับสาธารณะตามประเภทบัญชี การอนุมัติจาก upstream และหลักฐานจากผู้ดูแล