---
read_when:
    - คุณต้องเข้าใจว่าเหตุใดงาน CI จึงทำงานหรือไม่ทำงาน
    - คุณกำลังแก้ไขข้อบกพร่องของการตรวจสอบ GitHub Actions ที่ล้มเหลว
    - คุณกำลังประสานงานการดำเนินการตรวจสอบความถูกต้องของรีลีสหรือการดำเนินการซ้ำ
    - คุณกำลังเปลี่ยนการจัดส่งงานของ ClawSweeper หรือการส่งต่อกิจกรรม GitHub
summary: กราฟงาน CI, เกตขอบเขต, งานครอบคลุมการเผยแพร่ และคำสั่งเทียบเท่าสำหรับใช้งานในเครื่อง
title: ไปป์ไลน์ CI
x-i18n:
    generated_at: "2026-07-20T05:52:28Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 8d2b185ae6261201072242a3873bd154cbf695e16bae3e41f7e05f6a5ac1a173
    source_path: ci.md
    workflow: 16
---

OpenClaw CI ทำงานเมื่อมีการพุชไปยัง `main` (เส้นทาง Markdown และ `docs/**` จะถูกละเว้น
ในทริกเกอร์) ในทุก pull request ที่ไม่ใช่แบบร่าง และเมื่อสั่งทำงานด้วยตนเอง
การพุชไปยัง `main` หลักจะทำงานได้ครั้งละหนึ่งรอบ: กลุ่มการทำงานพร้อมกัน `CI` อนุญาตให้
วงจรการผสานรวมหนึ่งรอบทำงานจนเสร็จ ขณะที่ GitHub เก็บไว้เฉพาะการพุชที่รอดำเนินการล่าสุด
การผสานใหม่จะแทนที่รอบที่รอดำเนินการนั้น แทนที่จะยกเลิกงานที่
ลงทะเบียนเมทริกซ์ Blacksmith แล้ว ส่วน pull request ยังคงยกเลิก head ที่ถูกแทนที่
และการสั่งทำงานด้วยตนเองใช้กลุ่มที่แยกจากกัน `preflight` จะจำแนก diff และ
ปิดเลนที่ใช้ทรัพยากรมากเมื่อมีการเปลี่ยนแปลงเฉพาะส่วนที่ไม่เกี่ยวข้อง การเรียกใช้
`workflow_dispatch` ด้วยตนเองจะจงใจข้ามการกำหนดขอบเขตอัจฉริยะและกระจายงานไปยัง
กราฟทั้งหมดสำหรับตัวเลือกที่จะเผยแพร่และการตรวจสอบความถูกต้องแบบกว้าง เลน Android ยังคง
ต้องเปิดใช้โดยเฉพาะผ่าน `include_android` (หรืออินพุต `release_gate`) การครอบคลุม Plugin
เฉพาะรุ่นเผยแพร่อยู่ในเวิร์กโฟลว์
[`Plugin Prerelease`](#plugin-prerelease) ที่แยกต่างหาก และทำงานจาก
[`Full Release Validation`](#full-release-validation) หรือการสั่งทำงานด้วยตนเอง
อย่างชัดเจนเท่านั้น

## ภาพรวมไปป์ไลน์

| งาน                                | วัตถุประสงค์                                                                                                                                                                                                               | เวลาที่ทำงาน                                   |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- |
| `preflight`                        | ตรวจหาขอบเขตที่เปลี่ยนแปลงและสร้างรายการกำกับ CI; สำหรับ `main` หลักที่เกี่ยวข้องกับ Node ให้รีเฟรชและบำรุงรักษาสแนปช็อตการขึ้นต่อกันก่อนกระจายงาน                                                                        | ทุกครั้งที่พุชและเปิด PR ที่ไม่ใช่แบบร่าง             |
| `security-fast`                    | ตรวจหาคีย์ส่วนตัว ตรวจสอบเวิร์กโฟลว์ที่เปลี่ยนแปลงผ่าน `zizmor` และตรวจสอบ lockfile สำหรับการใช้งานจริง                                                                                                                             | ทุกครั้งที่พุชและเปิด PR ที่ไม่ใช่แบบร่าง             |
| `pnpm-store-warmup`                | เตรียมแคช Actions ที่ตรึงด้วย lockfile สำหรับ pull request และการเรียกใช้ด้วยตนเอง โดยไม่ขัดขวางชาร์ด Linux Node                                                                                                           | เมื่อเลือกเลน Node หรือการตรวจสอบเอกสารนอก main |
| `build-artifacts`                  | บิลด์ `dist/`, Control UI, ตรวจสอบการทำงานเบื้องต้นของ CLI ที่บิลด์แล้ว, หน่วยความจำเมื่อเริ่มต้น และตรวจสอบอาร์ติแฟกต์ที่บิลด์และฝังไว้                                                                                                                 | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `control-ui-i18n`                  | ตรวจสอบบันเดิลภาษาของ Control UI ที่สร้างขึ้น เมทาดาทา และหน่วยความจำการแปล; เป็นเพียงคำแนะนำในการทำงานอัตโนมัติ และบังคับผ่านในการเรียกใช้ CI รุ่นเผยแพร่ด้วยตนเอง                                                                               | การเปลี่ยนแปลงที่เกี่ยวข้องกับ i18n ของ Control UI และ CI แบบสั่งด้วยตนเอง |
| `checks-fast-core`                 | เลนตรวจสอบความถูกต้องอย่างรวดเร็วบน Linux: กลไกปรับเพดานจำนวนบรรทัดสูงสุดของค่าพื้นฐานการระงับ, แบบรวม + โปรโตคอล, ตัวเรียกใช้ Bun และงานด่วนสำหรับการกำหนดเส้นทาง CI                                                                                  | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `qa-smoke-ci-profile`              | สองส่วนที่สมดุลและทำงานได้ในตัวเองของชุดตัวแทน QA Smoke อัตโนมัติแบบจำกัด; ยังคงเข้าถึงการครอบคลุมอนุกรมวิธานทั้งหมดได้ผ่านโปรไฟล์ QA ที่ระบุ                                                         | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `checks-fast-contracts-plugins-*`  | ชาร์ดสัญญา Plugin แบบถ่วงน้ำหนักสองชาร์ด                                                                                                                                                                                   | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `checks-fast-contracts-channels-*` | ชาร์ดสัญญาช่องทางแบบถ่วงน้ำหนักสองชาร์ด                                                                                                                                                                                  | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `checks-node-*`                    | การทดสอบ Node เฉพาะเป้าหมายที่เปลี่ยนแปลงใน pull request; ชาร์ดแกนหลักทั้งหมดสำหรับ `main`, การเรียกใช้ด้วยตนเอง, รุ่นเผยแพร่ และการเรียกใช้ทางเลือกสำรองแบบกว้าง                                                                                                      | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `check-*`                          | เทียบเท่าเกตภายในหลักแบบแบ่งชาร์ด: ตัวป้องกัน, shrinkwrap, เมทาดาทาการกำหนดค่าช่องทางที่รวมมา, ชนิดสำหรับการใช้งานจริง, lint, การขึ้นต่อกัน, ชนิดการทดสอบ                                                                                   | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `check-additional-*`               | แถบการตรวจสอบขอบเขต (รวมถึงการคลาดเคลื่อนของสแนปช็อตพรอมต์), ขอบเขตตัวเข้าถึงเซสชัน/ตัวอ่านทรานสคริปต์/ธุรกรรม SQLite, กลุ่ม lint ของส่วนขยาย, การคอมไพล์/คะแนรีขอบเขตแพ็กเกจ และสถาปัตยกรรมโทโพโลยีรันไทม์ | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Node                          |
| `checks-node-compat-node22`        | เลนบิลด์และตรวจสอบการทำงานเบื้องต้นสำหรับความเข้ากันได้กับ Node 22                                                                                                                                                                            | การสั่ง CI ด้วยตนเองสำหรับรุ่นเผยแพร่                |
| `check-docs`                       | ตรวจสอบการจัดรูปแบบเอกสาร, lint และลิงก์เสีย                                                                                                                                                                         | เอกสารมีการเปลี่ยนแปลง (PR และการสั่งทำงานด้วยตนเอง)         |
| `native-i18n`                      | ตรวจสอบการแยกซอร์สเนทีฟและความปลอดภัยของการทำให้เป็นภาษาท้องถิ่นใน PR ซอร์ส; บังคับให้คำแปลและสิ่งที่สร้างเฉพาะแพลตฟอร์มสอดคล้องกันทั้งหมดใน PR ที่สร้างขึ้นและ CI แบบสั่งด้วยตนเอง                                                               | การเปลี่ยนแปลงที่เกี่ยวข้องกับ i18n เนทีฟ                   |
| `skills-python`                    | Ruff + pytest สำหรับ Skills ที่มี Python รองรับ                                                                                                                                                                                | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Skills ของ Python                  |
| `checks-windows`                   | การทดสอบกระบวนการ/เส้นทางเฉพาะ Windows รวมถึงการถดถอยของตัวระบุการนำเข้ารันไทม์ร่วม                                                                                                                                  | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Windows                       |
| `macos-node`                       | การทดสอบ TypeScript เฉพาะจุดบน macOS: launchd, Homebrew, เส้นทางรันไทม์, สคริปต์จัดแพ็กเกจ, ตัวห่อหุ้มกลุ่มกระบวนการ                                                                                                            | การเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS                         |
| `macos-swift`                      | lint และบิลด์ Swift สำหรับแอป macOS รวมถึงการทดสอบแอปและแพ็กเกจ OpenClawKit ที่ใช้ร่วมกัน                                                                                                                         | การเปลี่ยนแปลงที่เกี่ยวข้องกับ macOS                         |
| `ios-build`                        | การสร้างโปรเจกต์ Xcode และบิลด์แอป iOS สำหรับเครื่องจำลอง                                                                                                                                                             | การเปลี่ยนแปลงในแอป iOS, ชุดเครื่องมือแอปที่ใช้ร่วมกัน หรือ Swabble    |
| `android`                          | การทดสอบหน่วย Android สำหรับทั้งสองรูปแบบ รวมถึงบิลด์ APK ดีบักหนึ่งรายการ                                                                                                                                                          | การเปลี่ยนแปลงที่เกี่ยวข้องกับ Android                       |
| `openclaw/ci-gate`                 | ผลรวมสุดท้าย: ต้องผ่านการตรวจสอบล่วงหน้าและความปลอดภัย; ยอมรับการข้ามได้เฉพาะเลนปลายทางที่รายการกำกับปิดใช้งาน                                                                                                           | การเรียกใช้ CI ที่ไม่ใช่แบบร่างทุกครั้ง                         |
| `test-performance-agent`           | เวิร์กโฟลว์แยกต่างหาก: ปรับประสิทธิภาพการทดสอบช้าของ Codex รายวันหลังจากกิจกรรมที่เชื่อถือได้                                                                                                                                          | เมื่อ CI หลักสำเร็จหรือสั่งทำงานด้วยตนเอง             |
| `openclaw-performance`             | เวิร์กโฟลว์แยกต่างหาก: รายงานประสิทธิภาพรันไทม์ Kova รายวัน/ตามคำขอ พร้อมเลนผู้ให้บริการจำลอง, การทำโปรไฟล์เชิงลึก และ GPT 5.6 แบบสด                                                                                          | ตามกำหนดเวลาและการสั่งทำงานด้วยตนเอง                  |

เวิร์กโฟลว์ Periphery แบบแยกเดี่ยวบังคับให้ไม่พบโค้ดที่ไม่ได้ใช้งานสำหรับแอป iOS และ macOS เวิร์กโฟลว์ OpenClawKit ที่ใช้ร่วมกันจะสแกนผู้ใช้ทั้งสองแบบขนาน และรายงานการประกาศเฉพาะเมื่อ Periphery ส่ง Swift USR เดียวกันจากทั้งสองบิลด์ สัญญาสคีมา `OpenClawProtocol/GatewayModels.swift` ที่สร้างขึ้นจะคงไว้ในฐานะโค้ดที่ตัวสร้างเป็นเจ้าของ แทนที่จะถือว่าเป็นโค้ดที่ไม่ได้ใช้งานเฉพาะแอป

## ลำดับการหยุดเร็วเมื่อเกิดข้อผิดพลาด

1. `preflight` กำหนดว่าเลนใดจะมีอยู่เลย ตรรกะ `docs-scope` และ `changed-scope` เป็นขั้นตอนภายในงานนี้ ไม่ใช่งานแบบแยกเดี่ยว `main` หลักจะเริ่มทันที แต่กลุ่มการทำงานพร้อมกันอนุญาตให้ทำงานจนเสร็จได้เพียงหนึ่งรอบ และรวมการพุชภายหลังให้เหลือรอบรอดำเนินการล่าสุดหนึ่งรอบ การพุช main ที่เกี่ยวข้องกับ Node ยังจัดลำดับตัวเขียนดิสก์การขึ้นต่อกันเพียงตัวเดียวและการบำรุงรักษาขนาดไว้ที่นี่ ก่อนที่งานปลายทางจะเมานต์คีย์ได้; Blacksmith อาจเปิดเผยคอมมิตใหม่ให้เฉพาะการเรียกใช้เวิร์กโฟลว์ครั้งถัดไป ดังนั้นผู้ใช้ในรอบเดียวกันจึงยังคงใช้ทางเลือกสำรองภายในที่ตรวจสอบด้วยมาร์กเกอร์
2. `security-fast`, `check-*`, `check-additional-*`, `check-docs` และ `skills-python` จะล้มเหลวอย่างรวดเร็วโดยไม่รอเมทริกซ์งานอาร์ติแฟกต์และแพลตฟอร์มที่หนักกว่า
3. `build-artifacts` และการตรวจสอบภาษา locale ทำงานทับซ้อนกับเลน Linux แบบเร็ว PR ซอร์สของ Control UI และแอปเนทีฟจะไม่รวมสแนปช็อต/ทรัพยากร locale ที่สร้างขึ้น; เวิร์กโฟลว์รีเฟรชแบบเรียงลำดับจะซ่อมแซมและผสาน PR ที่สร้างขึ้นและแยกไว้โดยอัตโนมัติในเบื้องหลัง CI ของซอร์สยังคงบล็อกคลังรายการซอร์สที่ล้าสมัยและการเรียกใช้การทำให้เป็นภาษาท้องถิ่นที่ไม่ปลอดภัย PR ที่สร้างขึ้น, CI แบบสั่งด้วยตนเอง และการเตรียมรุ่นเผยแพร่จะบังคับให้คำแปลและสิ่งที่สร้างเฉพาะแพลตฟอร์มสอดคล้องกันทั้งหมด แบรนช์ `release/YYYY.M.PATCH` หลักอาจรวมการซ่อมแซม locale สำหรับการเตรียมรุ่นเผยแพร่ไว้กับเอาต์พุตรุ่นเผยแพร่ที่สร้างขึ้นอื่น ๆ
4. จากนั้นเลนแพลตฟอร์มและรันไทม์ที่หนักกว่าจะกระจายงานออกไป: `checks-fast-core`, `checks-fast-contracts-plugins-*`, `checks-fast-contracts-channels-*`, `checks-node-*`, `checks-windows`, `macos-node`, `macos-swift`, `ios-build` และ `android`
5. `openclaw/ci-gate` รอทุกเลนที่เลือก การตรวจสอบล่วงหน้าและความปลอดภัยต้องสำเร็จ; งานปลายทางข้ามได้เฉพาะเมื่อรายการกำกับไม่ได้เลือกงานเหล่านั้น เลนที่เลือกซึ่งล้มเหลวหรือถูกยกเลิกจะทำให้ผลรวมล้มเหลว

ตัวประสานงานการผสานอาจนำ `openclaw/ci-gate` ที่ผ่านสำเร็จและผ่านการยืนยันตัวตนแล้วกลับมาใช้ซ้ำ
สำหรับ head ของ pull request เดิมได้นานสูงสุด 24 ชั่วโมง วิธีนี้หลีกเลี่ยงการเขียน
แบรนช์ของผู้มีส่วนร่วมใหม่หลังจากมีการเปลี่ยนแปลง `main` ที่ไม่เกี่ยวข้อง ผลลัพธ์ที่นำกลับมาใช้ซ้ำได้จะไม่
แทนที่การตรวจสอบ test-merge แบบเข้มงวดที่แยกต่างหาก ซึ่ง App เป็นเจ้าของและตรวจเทียบกับ `main` ปัจจุบัน
การเรียกใช้ซ้ำที่รอดำเนินการหรือล้มเหลวในภายหลังจะไม่ลบล้างผลลัพธ์ที่สำเร็จก่อนหน้า
สำหรับ head ที่ไม่เปลี่ยนแปลงนั้นภายในช่วงเวลาความสดใหม่

กฎของสาขาเริ่มต้นกำหนดให้มีการตรวจสอบ `openclaw/ci-gate` ที่ GitHub Actions เป็นเจ้าของ ผู้ดูแลและผู้ดูแลระบบของรีโพซิทอรีมีการข้ามแบบฉุกเฉินที่มีการตรวจสอบย้อนหลัง ซึ่งมีไว้เฉพาะสำหรับการนำการเปลี่ยนแปลงเข้าโดยตรงแบบ fast-forward ที่ลงนามแล้วเท่านั้น ส่วนกฎระดับองค์กรยังคงบล็อกการลบและการอัปเดตแบบ non-fast-forward การผสาน pull request ตามปกติควรใช้เกตต่อไปแทนการข้ามไปป์ไลน์ CI ที่ล้มเหลว การตรวจสอบ test-merge แบบเข้มงวดที่ App เป็นเจ้าของซึ่งแยกต่างหากยังคงผูก head เข้ากับ `main` ปัจจุบัน

GitHub อาจทำเครื่องหมายงานของ pull request ที่ถูกแทนที่เป็น `cancelled` เมื่อมี head ใหม่กว่าถูกนำเข้า ให้ถือว่านั่นเป็นสัญญาณรบกวนของ CI เว้นแต่การรันล่าสุดของ PR เดียวกันจะล้มเหลวด้วย การรัน `main` ที่เป็นมาตรฐานจะไม่ถูกยกเลิกหลังผ่านการรับเข้า เมื่อมีทราฟฟิกการผสานเข้ามา GitHub จะแทนที่เฉพาะการรันเก่าที่ยังรอดำเนินการด้วย tip ล่าสุด งาน Matrix ใช้ `fail-fast: false` และ `build-artifacts` รายงานความล้มเหลวของช่องทางแบบฝัง ขอบเขตการรองรับของ core และการเฝ้าดู Gateway โดยตรง แทนการจัดคิวงานตรวจสอบขนาดเล็ก คีย์การทำงานพร้อมกันอัตโนมัติของ CI มีการกำหนดเวอร์ชัน (`CI-v7-*`) เพื่อไม่ให้ซอมบี้ฝั่ง GitHub ในกลุ่มคิวเก่าบล็อกการรัน main ที่ใหม่กว่าอย่างไม่มีกำหนด การรันชุดทดสอบเต็มรูปแบบด้วยตนเองใช้ `CI-manual-v1-*` และไม่ยกเลิกการรันที่กำลังดำเนินอยู่ ตัวป้องกันหน่วยความจำเมื่อเริ่มต้นของรายการ Plugin กำหนดเพดานไว้ที่ 350 MiB บน Blacksmith Linux แบบ self-hosted และอนุญาต 425 MiB บน Linux ที่ GitHub โฮสต์ ซึ่งมีค่า RSS พื้นฐานสูงกว่าสำหรับ CLI ที่บิลด์แบบเดียวกัน

ใช้ `pnpm ci:timings`, `pnpm ci:timings:recent` หรือ `node scripts/ci-run-timings.mjs <run-id>` เพื่อสรุประยะเวลาจริง เวลารอคิว งานที่ช้าที่สุด ความล้มเหลว และแนวกั้น fanout `pnpm-store-warmup` จาก GitHub Actions งาน `ci-timings-summary` ภายในเวิร์กโฟลว์มีอยู่ใน `ci.yml` แต่ขณะนี้ถูกปิดใช้งาน (`if: false`) ให้รันตัวช่วยจับเวลาในเครื่องแทน สำหรับเวลาบิลด์ ให้ตรวจสอบขั้นตอน `Build dist` ของงาน `build-artifacts`: `pnpm build:ci-artifacts` แสดง `[build-all] phase timings:` และรวม `ui:build` นอกจากนี้ งานยังอัปโหลดอาร์ติแฟกต์ `startup-memory`

## บริบทและหลักฐานของ PR

PR จากผู้มีส่วนร่วมภายนอกจะรันเกตตรวจสอบบริบทและหลักฐานของ PR จาก
`.github/workflows/real-behavior-proof.yml` เวิร์กโฟลว์จะเช็กเอาต์
รีวิชันของเวิร์กโฟลว์ที่เชื่อถือได้ (`github.workflow_sha`) และประเมินเฉพาะเนื้อหาของ PR
โดยไม่เรียกใช้โค้ดจากสาขาของผู้มีส่วนร่วม

เกตนี้ใช้กับผู้เขียน PR ที่ไม่ใช่เจ้าของรีโพซิทอรี สมาชิก
ผู้ร่วมงาน หรือบอต เกตจะผ่านเมื่อเนื้อหาของ PR มีส่วน
`What Problem This Solves` และ `Evidence` ที่ผู้เขียนจัดทำขึ้น หลักฐานอาจเป็นการทดสอบแบบเจาะจง
ผลลัพธ์ CI ภาพหน้าจอ การบันทึก เอาต์พุตเทอร์มินัล การสังเกตการณ์สด
บันทึกที่ปกปิดข้อมูลแล้ว หรือลิงก์อาร์ติแฟกต์ เนื้อหานี้ระบุเจตนาและการตรวจสอบความถูกต้องที่เป็นประโยชน์
ส่วนผู้รีวิวจะตรวจสอบโค้ด การทดสอบ และ CI เพื่อประเมินความถูกต้อง

เมื่อการตรวจสอบล้มเหลว ให้อัปเดตเนื้อหาของ PR แทนการพุชคอมมิตโค้ดเพิ่ม

## ขอบเขตและการกำหนดเส้นทาง

ตรรกะขอบเขตอยู่ใน `scripts/ci-changed-scope.mjs` และครอบคลุมด้วยการทดสอบหน่วยใน `src/scripts/ci-changed-scope.test.ts` การสั่งรันด้วยตนเองจะข้ามการตรวจหาขอบเขตที่เปลี่ยนแปลง และทำให้ manifest ขั้นตรวจสอบเบื้องต้นทำงานเสมือนว่าทุกพื้นที่ในขอบเขตมีการเปลี่ยนแปลง

เวิร์กโฟลว์ Periphery แยกกันสำหรับ iOS และ macOS บังคับใช้นโยบายโค้ดที่ไม่ได้ใช้งานซึ่งต้องไม่มีข้อค้นพบเลย แต่ละเวิร์กโฟลว์จะรันเฉพาะเมื่อ pull request ที่ไม่ใช่ฉบับร่างแตะขอบเขตการสแกนแบบเนทีฟของตน หรือเมื่อถูกสั่งรันด้วยตนเอง

- **การแก้ไขเวิร์กโฟลว์ CI** ตรวจสอบกราฟ CI ของ Node การ lint เวิร์กโฟลว์ และเลน Windows (`ci.yml` เป็นตัวเรียกใช้) แต่ไม่บังคับให้บิลด์เนทีฟของ iOS, Android หรือ macOS ด้วยตัวเอง เลนของแพลตฟอร์มเหล่านั้นยังคงจำกัดขอบเขตไว้เฉพาะการเปลี่ยนแปลงซอร์สของแพลตฟอร์ม
- **การตรวจสอบความสมเหตุสมผลของเวิร์กโฟลว์** รัน `actionlint`, `zizmor` กับไฟล์ YAML ของเวิร์กโฟลว์ทั้งหมด ตัวป้องกันการแทนค่า interpolation ของ composite action และตัวป้องกันเครื่องหมาย conflict งาน `security-fast` ที่จำกัดขอบเขตตาม PR ยังรัน `zizmor` กับไฟล์เวิร์กโฟลว์ที่เปลี่ยนแปลง เพื่อให้ข้อค้นพบด้านความปลอดภัยของเวิร์กโฟลว์ทำให้ล้มเหลวได้ตั้งแต่เนิ่น ๆ ในกราฟ CI หลัก
- **เอกสารในการพุชไปยัง `main`** จะถูกตรวจสอบโดยเวิร์กโฟลว์ `Docs` แบบสแตนด์อโลน โดยใช้มิเรอร์เอกสาร ClawHub เดียวกับ CI ดังนั้นการพุชที่มีทั้งโค้ดและเอกสารจะไม่จัดคิวชาร์ด `check-docs` ของ CI เพิ่มเติม Pull request และ CI ที่สั่งรันด้วยตนเองยังคงรัน `check-docs` จาก CI เมื่อเอกสารมีการเปลี่ยนแปลง
- **TUI PTY** รันในชาร์ด Linux Node `checks-node-core-runtime-tui-pty` สำหรับการเปลี่ยนแปลง TUI ชาร์ดนี้รัน `test/vitest/vitest.tui-pty.config.ts` พร้อม `OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1` จึงครอบคลุมทั้งเลนฟิกซ์เจอร์ `TuiBackend` ที่ให้ผลลัพธ์แน่นอน และการทดสอบ smoke `tui --local` ที่ช้ากว่าและจำลองเฉพาะปลายทางโมเดลภายนอก
- **การแก้ไขเฉพาะการกำหนดเส้นทาง CI ชุดฟิกซ์เจอร์ทดสอบ core ขนาดเล็กที่งานแบบเร็วรันโดยตรง และการแก้ไขตัวช่วยสัญญา Plugin ในขอบเขตแคบ** ใช้เส้นทาง manifest แบบเร็วสำหรับ Node เท่านั้น ได้แก่ `preflight`, `security-fast` และเฉพาะเลนแบบเร็วที่ได้รับผลกระทบจากการเปลี่ยนแปลง ได้แก่ งานกำหนดเส้นทาง CI `checks-fast-core` เพียงงานเดียว ชาร์ดสัญญา Plugin สองชาร์ด หรือทั้งสองอย่าง เส้นทางนี้ข้ามอาร์ติแฟกต์บิลด์ ความเข้ากันได้กับ Node 22 สัญญาของช่องทาง ชาร์ด core แบบเต็ม ชาร์ด Plugin ที่รวมมาให้ และเมทริกซ์ตัวป้องกันเพิ่มเติม
- **การตรวจสอบ Node บน Windows** จำกัดขอบเขตไว้เฉพาะตัวห่อหุ้มกระบวนการ/พาธสำหรับ Windows ตัวช่วยรัน npm/pnpm/UI การกำหนดค่าตัวจัดการแพ็กเกจ และพื้นผิวเวิร์กโฟลว์ CI ที่เรียกใช้เลนนั้น การเปลี่ยนแปลงซอร์ส Plugin การทดสอบ smoke การติดตั้ง และการเปลี่ยนแปลงเฉพาะการทดสอบที่ไม่เกี่ยวข้องยังคงอยู่บนเลน Linux Node

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

- สัญญา Plugin และสัญญาช่องทางต่างทำงานเป็นชาร์ดแบบถ่วงน้ำหนักสองชาร์ดที่ใช้ Blacksmith รองรับ พร้อมใช้รันเนอร์มาตรฐานของ GitHub เป็นทางเลือกสำรอง
- เลน fast/support ของยูนิตคอร์ทำงานแยกกัน ส่วนโครงสร้างพื้นฐานรันไทม์ของคอร์แบ่งเป็นชาร์ด process, shared, hooks, secrets และชาร์ดโดเมน Cron สามชาร์ด
- การตอบกลับอัตโนมัติทำงานเป็นเวิร์กเกอร์ที่ปรับสมดุล โดยซับทรีการตอบกลับแบ่งเป็นชาร์ด agent-runner, commands, dispatch, session และ state-routing
- การกำหนดค่า Gateway/เซิร์ฟเวอร์แบบเอเจนต์ (ระนาบควบคุม) แบ่งเป็นเลน chat, auth, model, HTTP/plugin, runtime และ startup แทนการรออาร์ติแฟกต์ที่สร้างเสร็จแล้ว
- CI ปกติรวมเฉพาะชาร์ดรูปแบบ include ของโครงสร้างพื้นฐานที่แยกอิสระไว้เป็นบันเดิลแบบกำหนดผลลัพธ์แน่นอน ซึ่งมีไฟล์ทดสอบไม่เกิน 64 ไฟล์ ช่วยลดเมทริกซ์ Node โดยไม่รวมชุดคำสั่ง/Cron ที่ไม่ได้แยกอิสระ, agents-core ที่มีสถานะ หรือชุด Gateway/เซิร์ฟเวอร์เข้าด้วยกัน ชุดงานหนักที่กำหนดตายตัวยังคงใช้ 8 vCPU ขณะที่เลนแบบบันเดิลและเลนที่มีน้ำหนักต่ำกว่าใช้ 4 vCPU
- Pull request ในรีโพซิทอรีมาตรฐานใช้ตัวแก้ไขการทดสอบที่เปลี่ยนแปลงซ้ำกับ diff ของทรีที่ผสานแบบสังเคราะห์ การเปลี่ยนแปลงที่ระบุได้แม่นยำจะเรียกใช้งาน Node เป้าหมายหนึ่งงาน โดยไฟล์ทดสอบที่เลือกแต่ละไฟล์จะมีกระบวนการของตนเองเพื่อคงการแยกชุดทดสอบที่มีสถานะไว้อย่างสมบูรณ์ ตัววางแผนรวมการทดสอบระดับเดียวกันกับรายการที่ขึ้นต่อกันตามกราฟการนำเข้า และย้อนกลับไปใช้แผนชุดทดสอบเต็มแบบกะทัดรัด 14 งานที่มีอยู่ สำหรับการเปลี่ยนแปลงแพ็กเกจ workspace, แพ็กเกจ/lockfile, ฮาร์เนสที่ใช้ร่วมกัน, การกำหนดค่าแบบแยก, การเปลี่ยนชื่อ หรือการลบ, การเปลี่ยนแปลงสัญญาส่วนขยายสาธารณะ, การทดสอบที่มีการตั้งค่าชาร์ดพิเศษ, เป้าหมายที่แก้ไขได้เพียงบางส่วนหรือว่างเปล่า, แผนพาธหรือเป้าหมายที่มีขนาดใหญ่เกินไป และข้อผิดพลาดของตัววางแผน แผนแบบกำหนดเป้าหมายจะคงเกตขอบเขตอาร์ติแฟกต์ที่สร้างทั้งหมดไว้เสมอ เนื่องจากสแกนเนอร์ของรีโพซิทอรีไม่สามารถอนุมานจากการนำเข้าได้ การพุช `main` เรียกใช้ชุดแบบกะทัดรัดเต็มรูปแบบเดียวกัน: เหตุการณ์พุชระหว่างกลางที่รอดำเนินการอาจถูกรวมกัน ดังนั้นการทำงานล่าสุดที่ยังคงอยู่ต้องตรวจสอบทรีการผสานรวมทั้งหมด ไม่ใช่เฉพาะ diff ของการพุชครั้งสุดท้ายเพียงครั้งเดียว การสั่งทำงานด้วยตนเองและเกตการเผยแพร่ยังคงใช้เมทริกซ์แบบระบุชื่อครบถ้วนต่อชาร์ด
- เมทริกซ์ Node แบบเต็มรับเครื่องมือแบบอนุกรมที่ช้าอย่างสม่ำเสมอ, ชาร์ดคำสั่งตอบกลับอัตโนมัติ และตัวเขียนแคช core-fast แบบกว้างก่อน วิธีนี้รักษาขีดจำกัด 28 งานไว้ พร้อมป้องกันไม่ให้งานบนเส้นทางวิกฤตและซีดการแปลงของการทำงานครั้งถัดไปเลื่อนไปยังระลอกภายหลัง
- การทดสอบเบราว์เซอร์, QA, สื่อ และ Plugin เบ็ดเตล็ดแบบกว้างใช้การกำหนดค่า Vitest เฉพาะของตนเองแทนตัวรวบรวม Plugin ที่ใช้ร่วมกัน ชาร์ดรูปแบบ include บันทึกรายการเวลาโดยใช้ชื่อชาร์ด CI เพื่อให้ `.artifacts/vitest-shard-timings.json` แยกการกำหนดค่าทั้งชุดออกจากชาร์ดที่กรองแล้วได้
- งานชาร์ด Linux Node เก็บรักษาแคชโมดูลบนระบบไฟล์รุ่นทดลองของ Vitest ผ่าน API แคช Actions ต้นทาง ซึ่ง Blacksmith เร่งความเร็วอย่างโปร่งใสบนรันเนอร์ของตน ทุกชาร์ด CI กู้คืนอย่างเดียวและแตกซีดที่ได้รับการป้องกันลงในรูทภายในรันเนอร์ของตนเอง จากนั้นแรปเปอร์ชาร์ดจะจัดไดเรกทอรีย่อยที่ใช้งานแยกกันให้กระบวนการ Vitest ที่ทำงานพร้อมกัน เฉพาะตัวอุ่นแคชรายวันที่ไม่ถูกยกเลิกหรือตัวอุ่นแคชที่สั่งทำงานอย่างชัดเจนเท่านั้นที่บันทึกอาร์ไคฟ์แบบเปลี่ยนแปลงไม่ได้ชุดใหม่ ดังนั้น Pull request จึงไม่สามารถเผยแพร่การแปลงหรือสร้างตระกูลแคชต่อ PR ได้ ลายนิ้วมืออินพุตการแปลงจะล้างรุ่นของ lockfile, แพ็กเกจ, tsconfig และการกำหนดค่า Vitest ที่เข้ากันไม่ได้ ตัวเขียนที่ได้รับการป้องกันจะสแกนและตัดแคชที่กู้คืนเหลือ 75% หลังจากมีขนาดเกิน 2 GiB Vitest แฮชรหัสโมดูล, เนื้อหาซอร์ส, สภาพแวดล้อม และการกำหนดค่าการแปลงที่แก้ไขแล้ว ดังนั้นการเปลี่ยนแปลงซอร์สบางส่วนตามปกติจะยังคงให้รายการที่ไม่เปลี่ยนแปลงอุ่นอยู่ ขณะที่โมดูลที่เปลี่ยนแปลงจะพลาดแคชอย่างปลอดภัย คำนำหน้าการกู้คืนแบบหยาบช่วยเชื่อมระหว่างการทำงานของเวิร์กโฟลว์ ส่วน LRU และการขับออกเมื่อไม่มีการใช้งานตามปกติของแคช Actions จะจำกัดอาร์ไคฟ์เก่าแบบเปลี่ยนแปลงไม่ได้
- งาน Linux Node ที่เชื่อถือได้ยังผูก pnpm store และ `node_modules` จากดิสก์การขึ้นต่อกันที่ได้รับการป้องกันหนึ่งชุดต่อสาย Node ที่รองรับ รายการแพ็กเกจ, การตั้งค่าการติดตั้ง, แพลตฟอร์มรันเนอร์ และแพตช์ Node ที่แน่นอนไม่รวมอยู่ในคีย์ดิสก์ โดยลายนิ้วมือของรันไทม์และอินพุตการติดตั้งที่แน่นอนจะตัดสินว่างานนำทรีกลับมาใช้ใหม่หรือติดตั้งใหม่และรีเฟรชดิสก์เดิม รายการต่างๆ จะถูกทำให้เป็นรูปแบบมาตรฐานก่อนแฮช ฮุกระดับรูทโดยตรงที่ผ่านการตรวจสอบจะคงไว้เฉพาะสคริปต์วงจรการติดตั้งของ pnpm ดังนั้นการแก้ไขการจัดรูปแบบและสคริปต์ทดสอบ/สร้างทั่วไปจะยังคงใช้ทรีการขึ้นต่อกันที่อุ่นอยู่ได้ การเปลี่ยนแปลงฮุกวงจรที่ไม่ได้รับการตรวจสอบจะล้มเหลวแบบปิดจนกว่าอินพุตซอร์สจะรวมอยู่ในสัญญาลายนิ้วมือ การเปลี่ยนแปลงการขึ้นต่อกัน, ตัวจัดการแพ็กเกจ, ซอร์สฮุก และ lockfile จะทำให้สแนปช็อตใช้ไม่ได้เสมอ ลายนิ้วมือที่ตรงกันเป็นเงื่อนไขจำเป็นแต่ไม่เพียงพอ: การตั้งค่ายังตรวจสอบอาร์ไคฟ์ importer และเช็กซัมรายการ จากนั้นตรวจสอบว่าการขึ้นต่อกันของ lockfile ที่อิงรีจิสทรีและ postinstall เก็บไว้ตรงกับรายการแพ็กเกจที่ Node แก้ไขจาก importer ของรายการเหล่านั้น เนื้อหา importer ที่ขาดหายหรือล้าสมัยจะย้อนกลับไปติดตั้งใหม่แทนการให้บริการ root hoist Pull request ที่สแนปช็อตแบบอ่านอย่างเดียวใช้ไม่ได้จะยกเลิกการผูก workspace และติดตั้งลงในพื้นที่จัดเก็บภายในรันเนอร์ เพื่อหลีกเลี่ยงการเขียนที่ช้าลงในโคลนที่ไม่สามารถเผยแพร่ได้ การติดตั้งแบบ cold บนดิสก์ถาวรจะปิดการลองดึงข้อมูลซ้ำภายในของ pnpm และพยายามติดตั้งแบบเต็มได้สูงสุดสามครั้งภายในขอบเขตที่กำหนดจาก store ที่อุ่นขึ้นเรื่อยๆ โดยการหมดเวลายังคงถือเป็นความล้มเหลว หลังจากกู้คืนโดยตรวจสอบเนื้อหาหรือติดตั้งแบบ frozen-lockfile แล้ว การตั้งค่าจะปิดการตรวจสอบการขึ้นต่อกันก่อนรันที่ซ้ำซ้อนของ pnpm: รีโพซิทอรีตั้งใจตัด `node_modules` ภายใน Plugin ซึ่ง pnpm จะถือว่าล้าสมัยและซ่อมผ่านการติดตั้งโดยนัยพร้อมกันที่ไม่ปลอดภัยระหว่างการกระจายงานชาร์ด การตรวจสอบล่วงหน้าของ main มาตรฐานเป็นตัวเขียนเพียงตัวเดียว และวัดขนาด store ทุกครั้งที่รีเฟรช โดยเรียกใช้ `pnpm store prune` เฉพาะเมื่อเวอร์ชันแพ็กเกจที่เลิกใช้แล้วทำให้ขนาดเกิน 8 GiB การเผยแพร่สแนปช็อตของ Blacksmith เป็นแบบอะซิงโครนัสแม้หลังงานตัวเขียนเสร็จสิ้น ดังนั้นการทำงานครั้งแรกหลังคีย์หรือลายนิ้วมือใหม่อาจยังคงเป็น cold ได้ การกู้คืนเครื่องหมายที่ตรงกันแบบแน่นอนและผ่านการตรวจสอบเนื้อหาในภายหลังเป็นหลักฐานการเปิดใช้งาน งาน CI ที่จำเป็นและ Pull request ได้รับโคลนแบบใช้แล้วทิ้ง ดังนั้นการเปลี่ยนแปลงการขึ้นต่อกันจึงไม่สร้างดิสก์ใหม่, สแนปช็อตที่แข่งขันกัน หรือล็อกแคชที่อาจยกเลิกการสร้าง
- งานชาร์ด Node และอาร์ติแฟกต์การสร้างยังกู้คืนแคชคอมไพล์แบบพกพาบนดิสก์ของ Node ผ่านแคช Actions แบบเปลี่ยนแปลงไม่ได้ เนมสเปซ `test` และ `build` ที่แยกจากกันป้องกันไม่ให้ตัวเขียนแทนที่อาร์ไคฟ์ของกันและกัน: ตัวอุ่นแคชการทดสอบตามกำหนดเวลาเป็นเจ้าของซีดทดสอบที่ได้รับการป้องกัน ขณะที่ `build-artifacts` อาจเผยแพร่อาร์ไคฟ์การสร้างที่ได้รับการป้องกันได้ไม่เกินหนึ่งชุดต่อวัน UTC จากการพุช `main` ที่เชื่อถือได้ งาน PR และงานทดสอบทั่วไปอ่านเฉพาะสแนปช็อตที่ได้รับการป้องกัน ดังนั้นไบต์โค้ดของฟีเจอร์บรานช์จะไม่เข้าสู่ซีดที่ใช้ร่วมกัน และทราฟฟิก PR จะไม่สร้างอาร์ไคฟ์แคช วิธีนี้นำไบต์โค้ด V8 กลับมาใช้ใหม่สำหรับการประสานงานที่โหลดโดย Node, เครื่องมือสร้าง และการขึ้นต่อกันภายนอกในพาธเช็กเอาต์ต่างๆ รวมถึงเมื่อมีการเปลี่ยนแปลงเพียงบางส่วนของกราฟซอร์ส กระบวนการลูก Vitest ปิดแคชคอมไพล์ที่สืบทอดมา เนื่องจากอาจเปิดใช้ความครอบคลุมภายในการกำหนดค่าแบบไดนามิก และความครอบคลุม V8 อาจสูญเสียความแม่นยำของตำแหน่งซอร์สเมื่อดีซีเรียลไลซ์สคริปต์จากไบต์โค้ด
- งานอาร์ติแฟกต์การสร้างยังเก็บรักษาเอาต์พุตขั้นตอน `build-all` ที่มีลายนิ้วมือตามเนื้อหา การประกาศ Plugin SDK ที่ CI สร้างขึ้นเองจะแฮชกราฟซอร์ส TypeScript/JSON ทั้งหมดที่รีโพซิทอรีเป็นเจ้าของ ไม่รวมไดเรกทอรีที่ติดตั้งและสร้างขึ้น และกู้คืนทั้งการประกาศแบบแบนและบริดจ์แพ็กเกจหลังจาก `tsdown` ล้าง `dist` การเปลี่ยนแปลงเอกสาร, เวิร์กโฟลว์, Plugin และรายการอื่นนอกกราฟนั้นสามารถนำสแนปช็อตการประกาศกลับมาใช้ใหม่ได้ ส่วนการเปลี่ยนแปลงซอร์สจะสร้างใหม่ก่อนเรียกใช้เกตการส่งออก
- การสร้างการประกาศแบบเต็มแบ่ง `tsdown` เป็นกลุ่ม AI, workspace-package และ unified แต่ละกลุ่มแคชเฉพาะการประกาศ จากนั้นยังคงสร้าง JavaScript รันไทม์ใหม่ก่อนกู้คืนการประกาศเหล่านั้น ดังนั้นการเปลี่ยนแปลงคอร์หรือ Plugin จะทำให้ใช้ไม่ได้เฉพาะกราฟ unified ขนาดใหญ่ ขณะที่การเปลี่ยนแปลง workspace-package จะทำให้กลุ่มการประกาศที่ขึ้นต่อกันทั้งหมดใช้ไม่ได้อย่างระมัดระวัง โดยทั่วไปการสร้างแบบเต็มสาธารณะใช้แคช Actions แบบเปลี่ยนแปลงไม่ได้ คีย์การกู้คืนแบบหยาบจะเป็นซีดให้การเปลี่ยนแปลงบางส่วน ลายนิ้วมือเนื้อหาต่อกลุ่มจะปฏิเสธข้อมูลล้าสมัย และโควตาแคชของ GitHub จะขับรุ่นเก่าออก ส่วนเลน Node 22 รายสัปดาห์จะเผยแพร่อาร์ติแฟกต์อายุ 14 วันหลังการทำงาน `main` สำเร็จ และกู้คืนเฉพาะอาร์ติแฟกต์ที่ข้อมูลระบุตัวผู้สร้างแบบเปลี่ยนแปลงไม่ได้แก้ไขไปยังเวิร์กโฟลว์นั้นบน `main` เพื่อหลีกเลี่ยงการหมุนเวียนโควตาโดยไม่อนุญาตให้โค้ด PR เขียนแคชที่ใช้ร่วมกัน การประกาศ Private-QA จะไม่ถูกเก็บในแคช Actions เนื่องจากเนมสเปซแคชไม่ใช่ขอบเขตการรักษาความลับ
- `check-additional-*` แบ่งรายการตัวป้องกันขอบเขตเสริม (`scripts/run-additional-boundary-checks.mjs`) เป็นชาร์ดที่ใช้พรอมต์หนักหนึ่งชาร์ด (`check-additional-boundaries-a` ซึ่งรวมการตรวจสอบการคลาดเคลื่อนของสแนปช็อตพรอมต์ Codex) และชาร์ดรวมหนึ่งชาร์ดสำหรับแถบที่เหลือ (`check-additional-boundaries-bcd`) โดยแต่ละชาร์ดเรียกใช้ตัวป้องกันอิสระพร้อมกันและพิมพ์เวลาต่อการตรวจสอบ งานคอมไพล์/คานารีของขอบเขตแพ็กเกจยังคงอยู่ด้วยกัน และสถาปัตยกรรมโทโพโลยีรันไทม์ทำงานแยกจากความครอบคลุมการเฝ้าดู Gateway ที่ฝังอยู่ใน `build-artifacts`
- บนรันเนอร์การสร้างแบบ self-hosted ขนาด 32-vCPU การเฝ้าดู Gateway, การทดสอบช่องทาง และชาร์ดขอบเขตการรองรับของคอร์จะเริ่มพร้อมกันภายใน `build-artifacts` หลังจากสร้าง `dist/` และ `dist-runtime/` แล้ว การทำงานสำรองบน GitHub-hosted จะยังคงเรียกใช้การเฝ้าดู Gateway แบบอนุกรม เพื่อไม่ให้การแข่งขันแย่งชิงคอร์ที่มีจำนวนน้อยกินเส้นตายความพร้อมของงาน

เมื่อได้รับอนุญาตแล้ว CI มาตรฐานบน Linux อนุญาตให้ทำงานทดสอบ Node พร้อมกันได้สูงสุด 28 งาน และ
12 งานสำหรับเลน fast/check ขนาดเล็กกว่า ส่วน Windows และ Android ยังคงอยู่ที่สองงานเนื่องจาก
พูลรันเนอร์เหล่านั้นมีขนาดจำกัดกว่า แบตช์การกำหนดค่าทั้งชุดแบบกะทัดรัดทำงานโดยมีเวลาหมดเวลาแบตช์
120 นาที ขณะที่กลุ่มรูปแบบ include ใช้งบประมาณงานที่มีขอบเขตเดียวกันร่วมกัน

Android CI เรียกใช้ทั้ง `testPlayDebugUnitTest` และ `testThirdPartyDebugUnitTest` แล้วสร้าง Play debug APK flavor ของบุคคลที่สามไม่มีชุดซอร์สหรือ manifest แยกต่างหาก เลนยูนิตทดสอบของ flavor นี้ยังคงคอมไพล์ flavor พร้อมแฟล็ก BuildConfig ของ SMS/call-log โดยหลีกเลี่ยงงานแพ็กเกจ debug APK ที่ซ้ำกันในการพุชทุกครั้งที่เกี่ยวข้องกับ Android งาน Gradle ปัจจุบันแต่ละงานมีดิสก์ถาวรที่ได้รับการป้องกันหนึ่งชุด งาน PR ใช้โคลนแบบใช้แล้วทิ้ง ขณะที่การทำงานที่ได้รับการป้องกันจะรีเฟรชรายการ Gradle แบบระบุตามเนื้อหาในตำแหน่งเดิม

คีย์ดิสก์ถาวรของ Blacksmith ถูกจำกัดโดยเจตนาตามมิติรันไทม์หรืองานที่รองรับเท่านั้น ไม่ใช้หมายเลข PR, คอมมิต, การทำงาน, บรานช์ หรือแฮชการขึ้นต่อกัน แคชการแปลงและคอมไพล์รันไทม์ใช้แคช Actions แทนดิสก์ถาวร เนื่องจากอาร์ไคฟ์แบบเปลี่ยนแปลงไม่ได้แสดงผลการกู้คืน/บันทึกที่ตรวจสอบได้ และหลีกเลี่ยงความล้มเหลวในการเลื่อนระดับสแนปช็อตแบบเปลี่ยนแปลงได้ หลังการย้ายเวอร์ชันคีย์ถาวร ให้เพิ่มเฉพาะข้อมูลระบุตัวตนของคีย์, สถาปัตยกรรม และภูมิภาคที่เลิกใช้แล้วอย่างแน่นอนลงใน `.github/retired-sticky-disks.json`, สั่งทำงาน `Sticky Disk Cleanup` จาก `main` ด้วยมิติและการยืนยันเดียวกัน, ตรวจสอบการลบ แล้วจึงนำรายการเหล่านั้นออก เวิร์กโฟลว์กำหนดเส้นทางข้อมูลระบุตัวตน ARM ไปยังรันเนอร์ ARM, ปฏิเสธความไม่ตรงกันของภูมิภาครันเนอร์, ใช้แอ็กชันลบคีย์แบบตรงกันทุกประการของ Blacksmith และไม่ลบแคชตัวสร้าง Docker หรือคำนำหน้าแบบไวลด์การ์ด แคชอาร์ไคฟ์ Actions ใช้ LRU และการขับออกเมื่อไม่มีการใช้งานตามปกติ

ชาร์ด `check-dependencies` เรียกใช้การตรวจสอบการขึ้นต่อกัน, ไฟล์ที่ไม่ได้ใช้ และการส่งออกที่ไม่ได้ใช้ในโค้ดใช้งานจริงด้วย Knip ตัวป้องกันไฟล์ที่ไม่ได้ใช้จะล้มเหลวเมื่อ PR เพิ่มไฟล์ที่ไม่ได้ใช้ใหม่ซึ่งยังไม่ผ่านการรีวิว หรือทิ้งรายการ allowlist ที่ล้าสมัยไว้ โดยยังคงรักษาพื้นผิว Plugin แบบไดนามิก, ที่สร้างขึ้น, การสร้าง, การทดสอบแบบ live และบริดจ์แพ็กเกจที่ตั้งใจไว้ ซึ่ง Knip ไม่สามารถแก้ไขแบบสแตติกได้ ตัวป้องกันการส่งออกที่ไม่ได้ใช้จะไม่รวมไฟล์สนับสนุนการทดสอบและล้มเหลวเมื่อพบการส่งออกของโค้ดใช้งานจริงที่ไม่ได้ใช้ทุกรายการ ผู้ใช้แบบไดนามิกที่ตั้งใจไว้ต้องถูกจำลองใน `config/knip.config.ts` เป้าหมายในอดีตจะเรียกใช้ตัวป้องกันการส่งออกเมื่อมีให้ใช้ และยังคงใช้วิธีสำรองตรวจหาโค้ดที่ไม่ทำงานแบบเดิมในกรณีอื่น

## การส่งต่อกิจกรรม ClawSweeper

`.github/workflows/clawsweeper-dispatch.yml` เป็นบริดจ์ฝั่งเป้าหมายที่ส่งกิจกรรมจากที่เก็บ OpenClaw ไปยัง ClawSweeper โดยจะไม่ checkout หรือเรียกใช้โค้ด pull request ที่ไม่น่าเชื่อถือ เวิร์กโฟลว์สร้างโทเค็น GitHub App จาก `CLAWSWEEPER_APP_PRIVATE_KEY` แล้วส่งเพย์โหลด `repository_dispatch` แบบกะทัดรัดไปยัง `openclaw/clawsweeper`

เวิร์กโฟลว์มีสี่เลน:

- `clawsweeper_item` สำหรับคำขอรีวิว issue และ pull request ที่ระบุอย่างเจาะจง;
- `clawsweeper_comment` สำหรับคำสั่ง ClawSweeper ที่ระบุอย่างชัดเจนในความคิดเห็นของ issue;
- `clawsweeper_commit_review` สำหรับคำขอรีวิวระดับ commit ในการ push ไปยัง `main`;
- `github_activity` สำหรับกิจกรรมทั่วไปของ GitHub ที่เอเจนต์ ClawSweeper อาจตรวจสอบ

เลน `github_activity` ส่งต่อเฉพาะเมทาดาทาที่ปรับให้อยู่ในรูปแบบมาตรฐาน ได้แก่ ประเภทเหตุการณ์ การดำเนินการ ผู้กระทำ ที่เก็บ หมายเลขรายการ URL ชื่อเรื่อง สถานะ และข้อความตัดตอนสั้น ๆ ของความคิดเห็นหรือรีวิวเมื่อมี โดยตั้งใจหลีกเลี่ยงการส่งต่อเนื้อหา Webhook ทั้งหมด เวิร์กโฟลว์ฝั่งรับใน `openclaw/clawsweeper` คือ `.github/workflows/github-activity.yml` ซึ่งโพสต์เหตุการณ์ที่ปรับให้อยู่ในรูปแบบมาตรฐานไปยังฮุกของ OpenClaw Gateway สำหรับเอเจนต์ ClawSweeper

กิจกรรมทั่วไปมีไว้เพื่อการสังเกต ไม่ใช่การส่งโดยค่าเริ่มต้น เอเจนต์ ClawSweeper จะได้รับเป้าหมาย Discord ในพรอมป์ต์ และควรโพสต์ไปยัง `#clawsweeper` เฉพาะเมื่อเหตุการณ์นั้นผิดคาด ดำเนินการต่อได้ มีความเสี่ยง หรือมีประโยชน์ต่อการปฏิบัติงาน การเปิดและแก้ไขตามปกติ ความเคลื่อนไหวจากบอต สัญญาณรบกวนจาก Webhook ที่ซ้ำกัน และการรับส่งรีวิวตามปกติควรให้ผลลัพธ์เป็น `NO_REPLY`

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

## การ dispatch ด้วยตนเอง

การ dispatch CI ด้วยตนเองเรียกใช้กราฟงานเดียวกับ CI ปกติ แต่บังคับเปิดทุกเลนตามขอบเขตที่ไม่ใช่ Android ได้แก่ shard ของ Linux Node, shard ของ Plugin ที่รวมมาให้, shard ของสัญญา Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, `check-*`, `check-additional-*`, การตรวจสอบ smoke ของอาร์ติแฟกต์ที่ build แล้ว, การตรวจสอบเอกสาร, Python skills, Windows, macOS, การ build iOS และ i18n ของ Control UI/แอปเนทีฟ PR ต้นทางอัตโนมัติจะตรวจสอบรายการคงคลังการแยกข้อความเนทีฟและความปลอดภัยในการแปล Android/Apple โดยไม่กำหนดให้มีเอาต์พุตที่แปลแล้วหรือสร้างโดยแพลตฟอร์มใน PR เดียวกัน เวิร์กโฟลว์ Native App Locale Refresh แบบเรียงลำดับจะสร้างอาร์ติแฟกต์เหล่านั้นใหม่ใน PR แยกต่างหากหนึ่งรายการ และเปิดใช้การผสานอัตโนมัติที่ exact-head หลังจากการตรวจสอบที่จำเป็นผ่าน ความสอดคล้องครบถ้วนของเนทีฟยังคงเป็นเงื่อนไขบังคับสำหรับ PR อาร์ติแฟกต์ที่สร้างขึ้น, CI แบบดำเนินการด้วยตนเอง, Full Release Validation และการเตรียมรีลีส ความสอดคล้องของโลแคล Control UI ยังคงเป็นเพียงคำแนะนำในการทำงานของ PR อัตโนมัติและ `main` และเป็นเงื่อนไขบังคับใน CI แบบดำเนินการด้วยตนเอง/รีลีส การ dispatch CI ด้วยตนเองแบบสแตนด์อโลนจะเรียกใช้ Android เฉพาะเมื่อมี `include_android=true` (อินพุต `release_gate` ก็บังคับ Android เช่นกัน); เวิร์กโฟลว์ครอบคลุมรีลีสฉบับเต็มจะเปิดใช้ Android โดยส่ง `include_android=true` การตรวจสอบแบบสแตติกก่อนรีลีสของ Plugin, shard เฉพาะรีลีส `agentic-plugins`, การกวาดตรวจส่วนขยายทั้งชุด และเลน Docker ก่อนรีลีสของ Plugin ไม่รวมอยู่ใน CI ชุดทดสอบก่อนรีลีสของ Docker จะทำงานเฉพาะเมื่อ `Full Release Validation` dispatch เวิร์กโฟลว์ `Plugin Prerelease` แยกต่างหากโดยเปิดใช้เกตการตรวจสอบรีลีส

การตรวจสอบจำนวนบรรทัดสูงสุดของ PR จะหา baseline จาก merge tree สังเคราะห์ที่ checkout แล้ว และตรวจสอบ parent ของ head เทียบกับ head ของเหตุการณ์ การทำงานด้วยตนเองใช้กลุ่ม concurrency ที่ไม่ซ้ำกัน เพื่อไม่ให้ชุดทดสอบฉบับเต็มของ release candidate ถูกยกเลิกโดยการ push หรือการทำงานของ PR อื่นบน ref เดียวกัน อินพุต `target_ref` ซึ่งเป็นตัวเลือกช่วยให้ผู้เรียกที่เชื่อถือได้เรียกใช้กราฟนั้นกับ branch, tag หรือ SHA ของ commit แบบเต็ม โดยใช้ไฟล์เวิร์กโฟลว์จาก ref ที่เลือกสำหรับการ dispatch; baseline ของจำนวนบรรทัดสูงสุดจะถูกเปรียบเทียบกับ merge base ของเป้าหมายเทียบกับ head ของ branch เริ่มต้นที่ resolve สำหรับการทำงานนั้น อินพุต `release_gate` เป็นทางเลือกสำรองแบบ exact-SHA สำหรับผู้ดูแลเมื่อ CI ของ PR ติดขัดจากข้อจำกัดด้านความจุ โดยกำหนดให้ `target_ref` เป็น SHA ของ commit แบบเต็มที่ตรงกับ head ของ branch ที่ dispatch และให้ `pull_request_number` ระบุ PR ที่เปิดอยู่ซึ่งมีการตรวจสอบ merge tree

```bash
gh workflow run ci.yml --ref release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=true
gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
```

เส้นทาง extended-stable รายเดือนเฉพาะ npm เป็นข้อยกเว้น: ให้ dispatch ทั้ง preflight `OpenClaw NPM
Release` และ `Full Release Validation` จาก branch
`extended-stable/YYYY.M.33` ที่ตรงกันทุกประการ เก็บรักษา ID การทำงานของทั้งสองรายการ และส่ง ID ทั้งสองไปยัง
การทำงานเผยแพร่ npm โดยตรง ดูคำสั่ง ข้อกำหนดด้านข้อมูลประจำตัวที่ตรงกันทุกประการ การอ่านค่ากลับจากรีจิสทรี และกระบวนการ
ซ่อมแซม selector ได้ที่ [การเผยแพร่ extended-stable รายเดือนเฉพาะ npm](/th/reference/RELEASING#monthly-npm-only-extended-stable-publication)
เส้นทางนี้จะไม่ dispatch การเผยแพร่ Plugin, macOS, Windows, GitHub
Release, dist-tag ส่วนตัว หรือแพลตฟอร์มอื่น

## Runner

| Runner                          | งาน                                                                                                                                                                                                                                                                              |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04`                  | `security-fast`, การ dispatch CI ด้วยตนเองและทางเลือกสำรองสำหรับที่เก็บที่ไม่ใช่ canonical, ผลรวม QA Smoke, การสแกนความปลอดภัยและคุณภาพด้วย CodeQL, การตรวจสอบความสมเหตุสมผลของเวิร์กโฟลว์, ตัวติดป้ายกำกับ, การตอบกลับอัตโนมัติ, เวิร์กโฟลว์ Docs แบบสแตนด์อโลน และเวิร์กโฟลว์ Install Smoke ทั้งหมด                                |
| `blacksmith-4vcpu-ubuntu-2404`  | `preflight`, `pnpm-store-warmup`, `native-i18n`, `checks-fast-core` ยกเว้น QA Smoke CI, shard ของสัญญา Plugin/ช่องทาง, shard ของ Linux Node ที่รวมมาให้/น้ำหนักเบากว่าส่วนใหญ่, เลน `check-*` ยกเว้น `check-lint`, shard `check-additional-*` ที่เลือกไว้, `check-docs` และ `skills-python` |
| `blacksmith-8vcpu-ubuntu-2404`  | ชุดทดสอบ Linux Node ขนาดใหญ่ที่ยังคงไว้, shard `check-additional-*` ที่เน้นขอบเขต/ส่วนขยาย และ `android`                                                                                                                                                                             |
| `blacksmith-16vcpu-ubuntu-2404` | shard QA Smoke CI อัตโนมัติ, `build-artifacts` ใน CI และ Testbox และ `check-lint` (ไวต่อ CPU มากพอที่ 8 vCPU มีค่าใช้จ่ายสูงกว่าประโยชน์ที่ประหยัดได้)                                                                                                                                  |
| `blacksmith-8vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                  |
| `blacksmith-6vcpu-macos-15`     | `macos-node` บน `openclaw/openclaw`; fork จะใช้ `macos-15` เป็นทางเลือกสำรอง                                                                                                                                                                                                                |
| `blacksmith-12vcpu-macos-26`    | `macos-swift` และ `ios-build` บน `openclaw/openclaw`; fork จะใช้ `macos-26` เป็นทางเลือกสำรอง                                                                                                                                                                                               |

## งบประมาณการลงทะเบียน Runner

บัคเก็ตการลงทะเบียน Runner ของ GitHub ปัจจุบันสำหรับ OpenClaw รายงานการลงทะเบียน Runner แบบ self-hosted 10,000
ครั้งต่อ 5 นาทีใน `ghx api rate_limit` ให้ตรวจสอบ
`actions_runner_registration` อีกครั้งก่อนการปรับแต่งแต่ละรอบ เพราะ GitHub อาจเปลี่ยน
บัคเก็ตนี้ ขีดจำกัดนี้ใช้ร่วมกันโดยการลงทะเบียน Runner ของ Blacksmith ทั้งหมดใน
องค์กร `openclaw` ดังนั้นการเพิ่มการติดตั้ง Blacksmith อีกรายการจะไม่เพิ่ม
บัคเก็ตใหม่

ให้ถือว่าป้ายกำกับ Blacksmith เป็นทรัพยากรที่มีจำกัดสำหรับการควบคุมการทำงานเป็นระลอก งานที่
ทำเพียงกำหนดเส้นทาง แจ้งเตือน สรุป เลือก shard หรือเรียกใช้การสแกน CodeQL ระยะสั้นควร
คงอยู่บน Runner ที่โฮสต์โดย GitHub เว้นแต่จะมีความจำเป็นเฉพาะ Blacksmith ที่วัดผลแล้ว
เมทริกซ์ Blacksmith ใหม่ทุกชุด, `max-parallel` ที่ใหญ่ขึ้น หรือเวิร์กโฟลว์
ความถี่สูง ต้องแสดงจำนวนการลงทะเบียนในกรณีเลวร้ายที่สุด และรักษาเป้าหมายระดับองค์กร
ไว้ต่ำกว่าประมาณ 60% ของบัคเก็ตที่ใช้งานอยู่ สำหรับบัคเก็ตปัจจุบันที่รองรับการลงทะเบียน 10,000 ครั้ง
นั่นหมายถึงเป้าหมายการปฏิบัติงานที่ 6,000 การลงทะเบียน โดยเหลือพื้นที่สำรองสำหรับ
ที่เก็บที่ทำงานพร้อมกัน การลองใหม่ และการซ้อนทับของระลอกงาน

แผน PR แบบ changed-target ลดระลอกการทดสอบ Node ทั่วไปจากการลงทะเบียน Blacksmith 14 ครั้งเหลือหนึ่งครั้ง PR ที่มีความเสี่ยงกว้างยังคงใช้ทางเลือกสำรองแบบกะทัดรัดที่มีการลงทะเบียน 14 ครั้ง ดังนั้นกรณีเลวร้ายที่สุดจึงไม่เพิ่มขึ้น

CI ของที่เก็บ canonical ยังคงใช้ Blacksmith เป็นเส้นทาง Runner เริ่มต้นสำหรับการ push และการทำงานของ pull request ตามปกติ `workflow_dispatch` และการทำงานในที่เก็บที่ไม่ใช่ canonical จะใช้ Runner ที่โฮสต์โดย GitHub แต่การทำงาน canonical ตามปกติยังไม่ตรวจสอบสภาพคิวของ Blacksmith หรือเปลี่ยนไปใช้ป้ายกำกับที่โฮสต์โดย GitHub โดยอัตโนมัติเมื่อ Blacksmith ไม่พร้อมใช้งาน

## คำสั่งเทียบเท่าสำหรับเครื่องภายใน

```bash
pnpm changed:lanes                            # ตรวจสอบตัวจำแนกเลนที่เปลี่ยนแปลงในเครื่องสำหรับ origin/main...HEAD
pnpm check:changed                            # เกตตรวจสอบอัจฉริยะในเครื่อง: การจัดรูปแบบ/typecheck/lint/guard ที่เปลี่ยนแปลงตามเลนขอบเขต
pnpm check                                    # เกตภายในเครื่องแบบรวดเร็ว: tsgo สำหรับ prod + lint แบบแบ่ง shard + guard แบบรวดเร็วที่ทำงานขนานกัน
pnpm check:test-types
pnpm check:timed                              # เกตเดียวกันพร้อมเวลาในแต่ละขั้น
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.ts
pnpm test                                     # การทดสอบ vitest
pnpm test:changed                             # เป้าหมาย Vitest ที่เปลี่ยนแปลงแบบอัจฉริยะและประหยัด
pnpm test:ui                                  # ชุดทดสอบ unit/เบราว์เซอร์ของ Control UI
pnpm ui:i18n:check                            # ความสอดคล้องของโลแคล Control UI ที่สร้างขึ้น (เกตรีลีส)
pnpm native:i18n:baseline                     # อัปเดตรายการคงคลังการแยกข้อความเนทีฟที่ต้นทางเป็นเจ้าของ
pnpm native:i18n:verify                       # รายการคงคลังต้นทาง + ความปลอดภัยในการแปล Android/Apple
pnpm native:i18n:check                        # ความสอดคล้องอย่างเข้มงวดของงานแปล/สิ่งที่แพลตฟอร์มสร้างขึ้น (เกตรีลีส)
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs                               # รูปแบบเอกสาร + lint + ลิงก์เสีย
pnpm build                                    # build dist เมื่อการตรวจสอบอาร์ติแฟกต์/smoke ของ CI มีความสำคัญ
pnpm ios:build                                # สร้างและ build โปรเจกต์แอป iOS
pnpm ci:timings                               # สรุปการทำงาน CI จากการ push ไปยัง origin/main ล่าสุด
pnpm ci:timings:recent                        # เปรียบเทียบการทำงาน CI ของ main ที่สำเร็จล่าสุด
node scripts/ci-run-timings.mjs <run-id>      # สรุปเวลารวม เวลารอคิว และงานที่ช้าที่สุด
node scripts/ci-run-timings.mjs --latest-main # ไม่รวมสัญญาณรบกวนจาก issue/ความคิดเห็น และเลือก CI จากการ push ไปยัง origin/main
node scripts/ci-run-timings.mjs --recent 10   # เปรียบเทียบการทำงาน CI ของ main ที่สำเร็จล่าสุด
pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json
pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
pnpm test:startup:memory
pnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.json
pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md
```

## ประสิทธิภาพของ OpenClaw

`OpenClaw Performance` คือเวิร์กโฟลว์ประสิทธิภาพของผลิตภัณฑ์/รันไทม์ โดยทำงานทุกวันบน `main` และสามารถ dispatch ด้วยตนเองได้:

```bash
gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=true
gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3
```

โดยปกติการสั่งรันด้วยตนเองจะวัดประสิทธิภาพของ ref ของเวิร์กโฟลว์ ตั้งค่า `target_ref` เพื่อวัดประสิทธิภาพของแท็กรุ่นเผยแพร่หรือสาขาอื่นด้วยการใช้งานเวิร์กโฟลว์ปัจจุบัน พาธรายงานที่เผยแพร่และตัวชี้ล่าสุดจะกำหนดคีย์ตาม ref ที่ทดสอบ และแต่ละ `index.md` จะบันทึก ref/SHA ที่ทดสอบ, ref/SHA ของเวิร์กโฟลว์, ref ของ Kova, โปรไฟล์, โหมดการยืนยันตัวตนของเลน, โมเดล, จำนวนครั้งที่ทำซ้ำ และตัวกรองสถานการณ์

เวิร์กโฟลว์ติดตั้ง OCM จากรุ่นเผยแพร่ที่ตรึงไว้ และติดตั้ง Kova จาก `openclaw/Kova` ตามอินพุต `kova_ref` ที่ตรึงไว้ จากนั้นรันสามเลน:

- `mock-provider`: สถานการณ์วินิจฉัยของ Kova กับรันไทม์ที่บิลด์ภายในเครื่อง โดยใช้การยืนยันตัวตนจำลองที่เข้ากันได้กับ OpenAI และให้ผลลัพธ์แบบกำหนดแน่นอน
- `mock-deep-profile`: การทำโปรไฟล์ CPU/ฮีป/เทรซสำหรับจุดคอขวดในการเริ่มต้น, Gateway และรอบการทำงานของเอเจนต์ รันตามกำหนดเวลา หรือเมื่อสั่งรันด้วย `deep_profile=true`
- `live-openai-candidate`: รอบการทำงานจริงของเอเจนต์ OpenAI `openai/gpt-5.6-luna` ซึ่งจะข้ามเมื่อ `OPENAI_API_KEY` ไม่พร้อมใช้งาน รันตามกำหนดเวลา หรือเมื่อสั่งรันด้วย `live_openai_candidate=true`

เลนผู้ให้บริการจำลองยังรันโพรบซอร์สแบบเนทีฟของ OpenClaw หลังจาก Kova ทำงานผ่านแล้ว ได้แก่ เวลาเริ่มทำงานและหน่วยความจำของ Gateway ในกรณีเริ่มต้นแบบค่าเริ่มต้น, ข้ามช่องทาง, ฮุกภายใน และ Plugin จำนวนห้าสิบรายการ; RSS จากการนำเข้า Plugin ที่รวมมาให้, ลูปกล่าวทักทาย `channel-chat-baseline` ด้วย OpenAI จำลองซ้ำหลายครั้ง, คำสั่งเริ่มต้น CLI กับ Gateway ที่บูตแล้ว และโพรบประสิทธิภาพ smoke ของสถานะ SQLite เมื่อมีรายงานซอร์สของผู้ให้บริการจำลองที่เผยแพร่ก่อนหน้าสำหรับ ref ที่ทดสอบ สรุปซอร์สจะเปรียบเทียบค่า RSS และฮีปปัจจุบันกับค่าฐานนั้น และทำเครื่องหมายการเพิ่มขึ้นอย่างมากของ RSS เป็น `watch` สรุปโพรบซอร์สแบบ Markdown อยู่ที่ `source/index.md` ในชุดรายงาน โดยมี JSON ดิบอยู่ข้างกัน

ทุกเลนจะอัปโหลดอาร์ติแฟกต์ GitHub ฉบับสมบูรณ์ รวมถึงชุด CPU, ฮีป, เทรซ และชุดวินิจฉัยที่บีบอัด งานเผยแพร่แยกต่างหากจะดาวน์โหลดและตรวจสอบอาร์ติแฟกต์เหล่านั้น จากนั้นสร้างโทเค็น GitHub App ของ ClawSweeper ที่มีอายุสั้นและจำกัดขอบเขตเฉพาะเนื้อหา `openclaw/clawgrit-reports` แล้วส่งโทเค็นนั้นให้เฉพาะขั้นตอน Git push เท่านั้น งานจะคอมมิต `report.json`, `report.md`, `index.md`, อาร์ติแฟกต์โพรบซอร์ส และเมทาดาทา/ผลรวมตรวจสอบของชุดไว้ภายใต้ `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`; ส่วนคลังวินิจฉัยฉบับเต็มจะยังคงอยู่ในอาร์ติแฟกต์ Actions ที่เชื่อมโยง งานเผยแพร่จะปฏิเสธไฟล์รายงานใดก็ตามที่มีขนาดเกิน 50 MB ก่อนพยายามพุช ตัวชี้ ref ที่ทดสอบปัจจุบันคือ `openclaw-performance/<tested-ref>/latest-<lane>.json` การรันตามกำหนดเวลาและการสั่งรัน `profile=release` จะล้มเหลวหากการสร้างโทเค็นแอปหรือการเผยแพร่รายงานล้มเหลว การสั่งรันด้วยตนเองที่ไม่ใช่รุ่นเผยแพร่จะถือว่าการเผยแพร่เป็นเพียงคำแนะนำ และเก็บอาร์ติแฟกต์ GitHub ไว้เมื่อการยืนยันตัวตนหรือการเผยแพร่ล้มเหลว ค่าฐานซอร์สก่อนหน้าจะถูกดึงแบบไม่ระบุตัวตนจากที่เก็บรายงานสาธารณะ ดังนั้นการดึงค่าฐานสำเร็จจึงไม่ได้พิสูจน์ว่าการยืนยันตัวตนของผู้เผยแพร่สำเร็จ

## การตรวจสอบความถูกต้องของรุ่นเผยแพร่แบบเต็ม

`Full Release Validation` คือเวิร์กโฟลว์ครอบคลุมแบบสั่งรันด้วยตนเองสำหรับ "รันทุกอย่างก่อนเผยแพร่รุ่น" โดยรับสาขา แท็ก หรือ SHA แบบเต็มของคอมมิต สั่งรันเวิร์กโฟลว์ `CI` แบบกำหนดเองด้วยเป้าหมายนั้น (รวมถึง Android) สั่งรัน `Plugin Prerelease` สำหรับหลักฐานเฉพาะรุ่นเผยแพร่ของ Plugin/แพ็กเกจ/สแตติก/Docker สั่งรัน `OpenClaw Performance` กับ SHA เป้าหมาย และสั่งรัน `OpenClaw Release Checks` สำหรับ smoke การติดตั้ง, การยอมรับแพ็กเกจ, การตรวจสอบแพ็กเกจข้ามระบบปฏิบัติการ, ความสอดคล้องของ QA Lab, Matrix, Telegram และเลน Discord, WhatsApp และ Slack ที่มีเกต (การเรนเดอร์ตารางคะแนนวุฒิภาวะแบบคำแนะนำเปิดใช้ได้ด้วย `run_maturity_scorecard`) โปรไฟล์เสถียรและเต็มจะรวมความครอบคลุม live/E2E แบบละเอียดครบถ้วนและการทดสอบแช่เส้นทางเผยแพร่ Docker เสมอ ส่วนโปรไฟล์เบตาสามารถเลือกเข้าร่วมด้วย `run_release_soak=true` E2E ของ Telegram สำหรับแพ็กเกจมาตรฐานจะรันภายใน Package Acceptance ดังนั้นตัวเลือกฉบับเต็มจึงไม่เริ่มตัวสำรวจแบบ live ซ้ำ หลังเผยแพร่ ให้ส่ง `release_package_spec` เพื่อนำแพ็กเกจ npm ที่เผยแพร่แล้วกลับมาใช้ซ้ำในการตรวจสอบรุ่นเผยแพร่, Package Acceptance, Docker, การตรวจสอบข้ามระบบปฏิบัติการ และ Telegram โดยไม่ต้องบิลด์ใหม่ ใช้ `npm_telegram_package_spec` เฉพาะสำหรับการรัน Telegram ซ้ำแบบเจาะจงกับแพ็กเกจที่เผยแพร่แล้ว เลนแพ็กเกจ live ของ Plugin Codex ใช้สถานะที่เลือกเดียวกันโดยค่าเริ่มต้น: `release_package_spec=openclaw@<tag>` ที่เผยแพร่แล้วจะกำหนด `codex_plugin_spec=npm:@openclaw/codex@<tag>` ส่วนการรัน SHA/อาร์ติแฟกต์จะแพ็ก `extensions/codex` จาก ref ที่เลือก ตั้งค่า `codex_plugin_spec` อย่างชัดเจนสำหรับซอร์ส Plugin แบบกำหนดเอง เช่นข้อกำหนด `npm:`, `npm-pack:` หรือ `git:` หลักฐานเอเจนต์แบบ live จะส่งความคืบหน้าที่มองเห็นได้ ดำเนินต่อด้วยการอ่านเวิร์กสเปซแบบสุ่มและการเขียนอาร์ติแฟกต์อย่างแม่นยำ จากนั้นส่งสถานะเสร็จสมบูรณ์

ดู[การตรวจสอบความถูกต้องของรุ่นเผยแพร่แบบเต็ม](/th/reference/full-release-validation)สำหรับ
เมทริกซ์ขั้นตอน ชื่องานเวิร์กโฟลว์ที่แน่นอน ความแตกต่างของโปรไฟล์ อาร์ติแฟกต์ และ
ตัวจัดการการรันซ้ำแบบเจาะจง

`OpenClaw Release Publish` คือเวิร์กโฟลว์เผยแพร่ที่เปลี่ยนแปลงสถานะและสั่งรันด้วยตนเอง สั่งรัน
การเผยแพร่เบตาและเสถียรตามปกติจาก `main` ที่เชื่อถือได้หลังจากมีแท็กรุ่นเผยแพร่
และหลังจากการตรวจสอบเบื้องต้นของ OpenClaw npm สำเร็จแล้ว (การตรวจสอบเบื้องต้นจะรัน
`pnpm plugins:sync:check` เป็นหนึ่งในการตรวจสอบ) แท็กยังคงเลือก
คอมมิตรุ่นเผยแพร่ที่แน่นอน รวมถึงคอมมิตบน `release/YYYY.M.PATCH`; การเผยแพร่ Tideclaw alpha
ยังคงใช้สาขา alpha ที่ตรงกัน โดยต้องมี
`preflight_run_id` ที่บันทึกไว้ รวมถึง
`full_release_validation_run_id` ที่สำเร็จและ
`full_release_validation_run_attempt` ที่ตรงกันอย่างแม่นยำ จากนั้นสั่งรัน `Plugin NPM Release` สำหรับ
แพ็กเกจ Plugin ทั้งหมดที่เผยแพร่ได้ สั่งรัน `Plugin ClawHub Release` สำหรับ
SHA รุ่นเผยแพร่เดียวกัน และหลังจากนั้นเท่านั้นจึงสั่งรัน `OpenClaw NPM Release` การเผยแพร่แบบเสถียรยัง
ต้องมี `windows_node_tag` ที่ตรงกันอย่างแม่นยำ เวิร์กโฟลว์จะตรวจสอบรุ่นเผยแพร่ซอร์ส Windows
และเปรียบเทียบตัวติดตั้ง x64/ARM64 กับอินพุต
`windows_node_installer_digests` ที่ตัวเลือกได้อนุมัติแล้วก่อนเริ่มงานย่อยสำหรับเผยแพร่ใดๆ จากนั้นจึงเลื่อนสถานะ
และตรวจสอบไดเจสต์ตัวติดตั้งที่ตรึงไว้ชุดเดียวกัน รวมทั้งสัญญาของอาร์ติแฟกต์คู่กันและผลรวมตรวจสอบที่ตรงกัน
ก่อนเผยแพร่ฉบับร่างรุ่นเผยแพร่ GitHub
การแก้ไขเฉพาะ Plugin แบบเจาะจงใช้ `plugin_publish_scope=selected` พร้อม
รายการแพ็กเกจที่ไม่ว่างเปล่า การรัน `all-publishable` เฉพาะ Plugin ต้องใช้หลักฐาน
การตรวจสอบเบื้องต้น npm ที่เปลี่ยนแปลงไม่ได้และการตรวจสอบความถูกต้องของรุ่นเผยแพร่แบบเต็มเช่นเดียวกับการเผยแพร่แกนหลัก

```bash
gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \
  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \
  -f npm_dist_tag=beta
```

สำหรับหลักฐานคอมมิตที่ตรึงไว้บนสาขาที่เปลี่ยนแปลงอย่างรวดเร็ว ให้ใช้ตัวช่วยแทน
`gh workflow run ... --ref main -f ref=<sha>`:

```bash
pnpm ci:full-release --sha <full-sha>
```

ref สำหรับสั่งรันเวิร์กโฟลว์ GitHub ต้องเป็น branch หรือ tag ไม่ใช่ commit SHA ดิบ ตัวช่วยจะ push branch ชั่วคราว `release-ci/<sha>-...` ที่ workflow SHA `main` ที่เชื่อถือได้ ส่ง target SHA ที่ร้องขอผ่าน input `ref` ของเวิร์กโฟลว์ ใช้หลักฐาน exact-target แบบเข้มงวดซ้ำเมื่อมีอยู่ ตรวจสอบว่า `headSha` ของเวิร์กโฟลว์ลูกทุกรายการตรงกับ workflow SHA ที่เชื่อถือได้ และลบ branch ชั่วคราวเมื่อการรันเสร็จสิ้น ส่ง `-f reuse_evidence=false` เพื่อบังคับให้ตรวจสอบความถูกต้องใหม่ ตัวตรวจสอบแบบครอบคลุมจะล้มเหลวด้วยหากเวิร์กโฟลว์ลูกใดรันด้วย workflow SHA ที่แตกต่างกัน

`release_profile` ควบคุมขอบเขต live/provider ที่ส่งไปยังการตรวจสอบ release เวิร์กโฟลว์ release แบบดำเนินการด้วยตนเองมีค่าเริ่มต้นเป็น `stable`; ใช้ `full` เฉพาะเมื่อต้องการเมทริกซ์ provider/media แบบ advisory ที่ครอบคลุมโดยตั้งใจเท่านั้น การตรวจสอบ stable และ full release จะรันการทดสอบต่อเนื่องตามเส้นทาง release แบบ live/E2E และ Docker อย่างครบถ้วนเสมอ ส่วนโปรไฟล์ beta สามารถเลือกเปิดใช้ได้ด้วย `run_release_soak=true`

- `beta` คง lane ที่สำคัญต่อ release ของ OpenAI/core ซึ่งเร็วที่สุดไว้
- `stable` เพิ่มชุด provider/backend สำหรับ stable
- `full` รันเมทริกซ์ provider/media แบบ advisory ที่ครอบคลุม

ตัวครอบคลุมจะบันทึก ID การรันของรายการลูกที่สั่งรัน และ job สุดท้าย `Verify full validation` จะตรวจสอบผลสรุปปัจจุบันของการรันลูกอีกครั้งและเพิ่มตาราง job ที่ช้าที่สุดสำหรับการรันลูกแต่ละรายการ หากเวิร์กโฟลว์ลูกถูกรันซ้ำและเปลี่ยนเป็นผ่าน ให้รันซ้ำเฉพาะ job ตัวตรวจสอบของ parent เพื่อรีเฟรชผลลัพธ์และสรุปเวลาของตัวครอบคลุม

สำหรับการกู้คืน ทั้ง `Full Release Validation` และ `OpenClaw Release Checks` รองรับ `rerun_group` ใช้ `all` สำหรับ release candidate, `ci` สำหรับเฉพาะรายการลูก full CI ปกติ, `plugin-prerelease` สำหรับเฉพาะรายการลูก prerelease ของ plugin, `performance` สำหรับเฉพาะรายการลูก OpenClaw Performance, `release-checks` สำหรับรายการลูก release ทั้งหมด หรือใช้กลุ่มที่แคบกว่า ได้แก่ `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` หรือ `npm-telegram` บนตัวครอบคลุม วิธีนี้จำกัดขอบเขตการรันซ้ำของกล่อง release ที่ล้มเหลวหลังการแก้ไขเฉพาะจุด สำหรับ lane ข้าม OS ที่ล้มเหลวหนึ่งรายการ ให้ใช้ `rerun_group=cross-os` ร่วมกับ `cross_os_suite_filter` เช่น `windows/packaged-upgrade`; คำสั่งข้าม OS ที่ใช้เวลานานจะแสดงบรรทัด Heartbeat และสรุปการอัปเกรดแพ็กเกจจะรวมเวลาของแต่ละระยะ lane QA ของ Matrix และ Telegram ที่เลือกไว้จะบล็อกการตรวจสอบ release ปกติ เช่นเดียวกับ gate มาตรฐานสำหรับความครอบคลุมของเครื่องมือ runtime ส่วนความสอดคล้องของ QA ความสอดคล้องของ runtime และ lane live ของ Discord, WhatsApp และ Slack ที่มี gate เป็นเพียง advisory

`OpenClaw Release Checks` ใช้ ref ของเวิร์กโฟลว์ที่เชื่อถือได้เพื่อ resolve ref ที่เลือกเป็น tarball `release-package-under-test` เพียงครั้งเดียว จากนั้นส่ง artifact ดังกล่าวไปยังการตรวจสอบข้าม OS และ Package Acceptance รวมถึงเวิร์กโฟลว์ Docker ตามเส้นทาง release แบบ live/E2E เมื่อมีการรันความครอบคลุมแบบ soak วิธีนี้ทำให้ไบต์ของแพ็กเกจสอดคล้องกันในกล่อง release ต่าง ๆ และหลีกเลี่ยงการแพ็ก candidate เดียวกันซ้ำใน job ลูกหลายรายการ สำหรับ lane live ของ Codex npm-plugin การตรวจสอบ release จะส่ง spec ของ plugin ที่เผยแพร่แล้วซึ่งตรงกันและได้มาจาก `release_package_spec` หรือส่ง `codex_plugin_spec` ที่ผู้ปฏิบัติงานระบุ หรือเว้น input ว่างไว้เพื่อให้สคริปต์ Docker แพ็ก Codex plugin จาก checkout ที่เลือก

การรัน `Full Release Validation` ที่ซ้ำกันสำหรับ `ref=main` และ `rerun_group=all`
จะแทนที่ตัวครอบคลุมรายการเก่า ตัวเฝ้าติดตามของ parent จะยกเลิกเวิร์กโฟลว์ลูกทุกรายการที่สั่งรันไปแล้วเมื่อ parent ถูกยกเลิก เพื่อให้การตรวจสอบ main ที่ใหม่กว่าไม่ต้องรอหลังการรันตรวจสอบ release เก่าที่ใช้เวลาสองชั่วโมง การตรวจสอบ branch/tag ของ release และกลุ่มการรันซ้ำเฉพาะจุดจะคง `cancel-in-progress: false` ไว้

## shard แบบ Live และ E2E

รายการลูก live/E2E ของ release ยังคงความครอบคลุม native `pnpm test:live` ที่กว้าง แต่รันเป็น shard ที่มีชื่อผ่าน `scripts/test-live-shard.mjs` แทน job แบบลำดับเดียว:

- `native-live-src-agents` และ `native-live-src-agents-zai-coding`
- `native-live-src-gateway-core`
- job `native-live-src-gateway-profiles` ที่กรองตาม provider
- `native-live-src-gateway-backends`
- `native-live-src-infra`
- `native-live-test`
- `native-live-extensions-a-k`
- `native-live-extensions-l-n`
- `native-live-extensions-moonshot`
- `native-live-extensions-openai`
- `native-live-extensions-o-z-other`
- `native-live-extensions-xai`
- แยก shard เสียง/วิดีโอของสื่อและ shard เพลงที่กรองตาม provider

วิธีนี้คงความครอบคลุมของไฟล์เดิมไว้ พร้อมทำให้ความล้มเหลวของ provider แบบ live ที่ช้ารันซ้ำและวินิจฉัยได้ง่ายขึ้น ชื่อ shard แบบรวม `native-live-src-gateway`, `native-live-extensions-o-z`, `native-live-extensions-media` และ `native-live-extensions-media-music` ยังคงใช้ได้สำหรับการรันซ้ำครั้งเดียวด้วยตนเอง

shard สื่อแบบ native live รันใน `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04` ซึ่งสร้างโดยเวิร์กโฟลว์ `Live Media Runner Image` image ดังกล่าวติดตั้ง `ffmpeg` และ `ffprobe` ไว้ล่วงหน้า; job สื่อจะตรวจสอบเฉพาะ binary ก่อนการตั้งค่า ให้ชุดทดสอบ live ที่ใช้ Docker backend รันบน runner Blacksmith ปกติ เพราะ container job ไม่เหมาะสำหรับเปิดการทดสอบ Docker แบบซ้อนกัน

ชาร์ดโมเดล/แบ็กเอนด์แบบใช้งานจริงที่รองรับด้วย Docker ใช้อิมเมจ `ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions>` ที่ใช้ร่วมกันแยกต่างหากต่อคอมมิตที่เลือก เวิร์กโฟลว์รีลีสแบบใช้งานจริงจะสร้างและพุชอิมเมจนั้นหนึ่งครั้ง จากนั้นชาร์ดโมเดลแบบใช้งานจริงบน Docker, Gateway ที่แบ่งชาร์ดตามผู้ให้บริการ, แบ็กเอนด์ CLI, การผูก ACP และชุดทดสอบ Codex จะทำงานด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1` ชาร์ด Gateway Docker มีขีดจำกัด `timeout` ระดับสคริปต์ที่กำหนดไว้อย่างชัดเจนและต่ำกว่าไทม์เอาต์ของงานในเวิร์กโฟลว์ เพื่อให้คอนเทนเนอร์ที่ค้างหรือเส้นทางการล้างข้อมูลที่ติดขัดล้มเหลวอย่างรวดเร็วแทนที่จะใช้โควตาเวลาของการตรวจสอบรีลีสจนหมด หากชาร์ดเหล่านั้นสร้างเป้าหมาย Docker จากซอร์สทั้งหมดใหม่โดยอิสระ แสดงว่าการเรียกใช้รีลีสกำหนดค่าผิดและจะเสียเวลาจริงไปกับการสร้างอิมเมจซ้ำ

## การยอมรับแพ็กเกจ

ใช้ `Package Acceptance` เมื่อคำถามคือ "แพ็กเกจ OpenClaw ที่ติดตั้งได้นี้ทำงานเป็นผลิตภัณฑ์ได้หรือไม่" ซึ่งแตกต่างจาก CI ปกติ: CI ปกติตรวจสอบความถูกต้องของแผนผังซอร์ส ขณะที่การยอมรับแพ็กเกจตรวจสอบ tarball เดียวผ่านชุดทดสอบ Docker E2E เดียวกับที่ผู้ใช้ใช้งานหลังติดตั้งหรืออัปเดต

### งาน

1. `resolve_package` เช็กเอาต์ `workflow_ref`, ระบุแพ็กเกจที่เป็นตัวเลือกหนึ่งรายการ, เขียน `.artifacts/docker-e2e-package/openclaw-current.tgz`, เขียน `.artifacts/docker-e2e-package/package-candidate.json`, อัปโหลดทั้งสองเป็นอาร์ติแฟกต์ `package-under-test` และพิมพ์ซอร์ส, อ้างอิงเวิร์กโฟลว์, อ้างอิงแพ็กเกจ, เวอร์ชัน, SHA-256 และโปรไฟล์ในสรุปขั้นตอนของ GitHub
2. `package_integrity` ดาวน์โหลดอาร์ติแฟกต์ `package-under-test` และบังคับใช้สัญญา tarball ของแพ็กเกจสาธารณะด้วย `scripts/check-openclaw-package-tarball.mjs`
3. `docker_acceptance` เรียก `openclaw-live-and-e2e-checks-reusable.yml` ด้วย SHA ซอร์สของแพ็กเกจที่ระบุได้ (โดยใช้ `workflow_ref` เป็นทางเลือกสำรอง) และ `package_artifact_name=package-under-test` เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้จะดาวน์โหลดอาร์ติแฟกต์นั้น ตรวจสอบรายการภายใน tarball เตรียมอิมเมจ Docker ตามไดเจสต์ของแพ็กเกจเมื่อจำเป็น และเรียกใช้เลน Docker ที่เลือกกับแพ็กเกจนั้นแทนการแพ็กเช็กเอาต์ของเวิร์กโฟลว์ เมื่อโปรไฟล์เลือก `docker_lanes` แบบเจาะจงหลายรายการ เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้จะเตรียมแพ็กเกจและอิมเมจที่ใช้ร่วมกันหนึ่งครั้ง จากนั้นกระจายเลนเหล่านั้นเป็นงาน Docker แบบเจาะจงที่ทำงานขนานกันพร้อมอาร์ติแฟกต์เฉพาะ
4. `package_telegram` เลือกเรียก `NPM Telegram Beta E2E` ได้ งานนี้ทำงานเมื่อ `telegram_mode` ไม่ใช่ `none` และติดตั้งอาร์ติแฟกต์ `package-under-test` เดียวกันเมื่อการยอมรับแพ็กเกจระบุอาร์ติแฟกต์ได้ ส่วนการสั่งงาน Telegram แบบสแตนด์อโลนยังคงติดตั้งข้อกำหนด npm ที่เผยแพร่แล้วได้
5. `summary` ทำให้เวิร์กโฟลว์ล้มเหลวหากการระบุแพ็กเกจ ความสมบูรณ์ การยอมรับบน Docker หรือเลน Telegram ที่เป็นตัวเลือกล้มเหลว อินพุต `advisory` จะลดระดับความล้มเหลวของการยอมรับให้เป็นคำเตือนสำหรับผู้เรียกที่ใช้เป็นคำแนะนำ

### แหล่งที่มาของตัวเลือก

- `source=npm` ยอมรับเฉพาะ `openclaw@extended-stable`, `openclaw@beta`, `openclaw@latest` หรือเวอร์ชันรีลีส OpenClaw ที่ระบุแน่นอน เช่น `openclaw@2026.4.27-beta.2` ใช้สำหรับการยอมรับเวอร์ชัน extended-stable, ก่อนรีลีส หรือ stable ที่เผยแพร่แล้ว
- `source=ref` แพ็กบรานช์ แท็ก หรือ SHA คอมมิตแบบเต็มของ `package_ref` ที่เชื่อถือได้ ตัวระบุจะดึงบรานช์/แท็ก OpenClaw ตรวจสอบว่าคอมมิตที่เลือกเข้าถึงได้จากประวัติบรานช์ของรีโพซิทอรีหรือแท็กรีลีส ติดตั้งดีเพนเดนซีใน worktree ที่แยกออกมา และแพ็กด้วย `scripts/package-openclaw-for-docker.mjs`
- `source=url` ดาวน์โหลด `.tgz` ผ่าน HTTPS สาธารณะ โดยต้องระบุ `package_sha256` เส้นทางนี้ปฏิเสธข้อมูลรับรองใน URL, พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น, ชื่อโฮสต์หรือ IP ที่แก้ชื่อแล้วซึ่งเป็นแบบส่วนตัว/ภายใน/ใช้งานเฉพาะ และการเปลี่ยนเส้นทางที่อยู่นอกนโยบายความปลอดภัยสาธารณะเดียวกัน
- `source=trusted-url` ดาวน์โหลด `.tgz` ผ่าน HTTPS จากนโยบายแหล่งที่มาที่เชื่อถือได้ซึ่งระบุชื่อไว้ใน `.github/package-trusted-sources.json` โดยต้องระบุ `package_sha256` และ `trusted_source_id` ใช้เฉพาะกับมิเรอร์ระดับองค์กรหรือรีโพซิทอรีแพ็กเกจส่วนตัวที่ผู้ดูแลเป็นเจ้าของ ซึ่งต้องกำหนดค่าโฮสต์ พอร์ต คำนำหน้าพาธ โฮสต์สำหรับเปลี่ยนเส้นทาง หรือการแก้ชื่อเครือข่ายส่วนตัว หากนโยบายประกาศการยืนยันตัวตนแบบ bearer เวิร์กโฟลว์จะใช้ซีเคร็ต `OPENCLAW_TRUSTED_PACKAGE_TOKEN` แบบคงที่ โดยยังคงปฏิเสธข้อมูลรับรองที่ฝังใน URL
- `source=artifact` ดาวน์โหลด `.tgz` หนึ่งรายการจาก `artifact_run_id` และ `artifact_name`; `package_sha256` เป็นตัวเลือก แต่ควรระบุสำหรับอาร์ติแฟกต์ที่แชร์ภายนอก

แยก `workflow_ref` และ `package_ref` ออกจากกัน `workflow_ref` คือโค้ดเวิร์กโฟลว์/ชุดทดสอบที่เชื่อถือได้ซึ่งเรียกใช้การทดสอบ `package_ref` คือคอมมิตซอร์สที่จะถูกแพ็กเมื่อ `source=ref` วิธีนี้ช่วยให้ชุดทดสอบปัจจุบันตรวจสอบคอมมิตซอร์สเก่าที่เชื่อถือได้โดยไม่ต้องเรียกใช้ตรรกะเวิร์กโฟลว์เก่า

### โปรไฟล์ชุดทดสอบ

- `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `skill-install`, `update-corrupt-plugin`, `upgrade-survivor`, `published-upgrade-survivor`, `root-managed-vps-upgrade`, `update-restart-auth`, `plugins-offline`, `plugin-update`
- `product` — ชุด `package` ที่มีความครอบคลุม `plugins` แบบใช้งานจริงแทน `plugins-offline` พร้อมด้วย `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
- `full` — ส่วนงานเส้นทางรีลีส Docker แบบเต็มพร้อม OpenWebUI
- `custom` — `docker_lanes` ที่ตรงกันทุกประการ; จำเป็นเมื่อ `suite_profile=custom`

โปรไฟล์ `package` ใช้ความครอบคลุม Plugin แบบออฟไลน์ เพื่อไม่ให้การตรวจสอบแพ็กเกจที่เผยแพร่แล้วขึ้นอยู่กับความพร้อมใช้งานของ ClawHub แบบใช้งานจริง เลน Telegram ที่เป็นตัวเลือกจะใช้อาร์ติแฟกต์ `package-under-test` ซ้ำใน `NPM Telegram Beta E2E` โดยยังคงเส้นทางข้อกำหนด npm ที่เผยแพร่แล้วไว้สำหรับการสั่งงานแบบสแตนด์อโลน

สำหรับนโยบายเฉพาะด้านการทดสอบการอัปเดตและ Plugin รวมถึงคำสั่งภายในเครื่อง
เลน Docker, อินพุตการยอมรับแพ็กเกจ, ค่าเริ่มต้นของรีลีส และการคัดแยกความล้มเหลว
โปรดดู [การทดสอบการอัปเดตและ Plugin](/th/help/testing-updates-plugins)

การตรวจสอบรีลีสเรียกการยอมรับแพ็กเกจด้วย `source=artifact`, อาร์ติแฟกต์แพ็กเกจรีลีสที่เตรียมไว้, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape'` และ `telegram_mode=mock-openai` วิธีนี้ทำให้การย้ายข้อมูลแพ็กเกจ การอัปเดต การติดตั้ง skill จาก ClawHub แบบใช้งานจริง การล้างดีเพนเดนซี Plugin ที่ล้าสมัย การซ่อมแซมการติดตั้ง Plugin ที่กำหนดค่าไว้ Plugin แบบออฟไลน์ การอัปเดต Plugin และหลักฐาน Telegram ใช้ tarball แพ็กเกจที่ระบุได้ชุดเดียวกัน ตั้งค่า `release_package_spec` ในการตรวจสอบรีลีสแบบเต็มหรือการตรวจสอบรีลีส OpenClaw หลังเผยแพร่ beta เพื่อเรียกใช้เมทริกซ์เดียวกันกับแพ็กเกจ npm ที่ส่งมอบแล้วโดยไม่สร้างใหม่ ตั้งค่า `package_acceptance_package_spec` เฉพาะเมื่อการยอมรับแพ็กเกจต้องใช้แพ็กเกจที่แตกต่างจากส่วนอื่นของการตรวจสอบรีลีส การตรวจสอบรีลีสข้ามระบบปฏิบัติการยังคงครอบคลุมการเริ่มต้นใช้งาน ตัวติดตั้ง และพฤติกรรมเฉพาะแพลตฟอร์ม ส่วนการตรวจสอบผลิตภัณฑ์ด้านแพ็กเกจ/การอัปเดตควรเริ่มจากการยอมรับแพ็กเกจ

เลน Docker `published-upgrade-survivor` ตรวจสอบฐานแพ็กเกจที่เผยแพร่แล้วหนึ่งรายการต่อการเรียกใช้ในเส้นทางรีลีสที่บล็อกอยู่ ในการยอมรับแพ็กเกจ tarball `package-under-test` ที่ระบุได้จะเป็นตัวเลือกเสมอ และ `published_upgrade_survivor_baseline` จะเลือกฐานที่เผยแพร่แล้วสำหรับใช้เป็นทางเลือกสำรอง โดยมีค่าเริ่มต้นเป็น `openclaw@latest`; คำสั่งเรียกใช้เลนที่ล้มเหลวซ้ำจะคงฐานนั้นไว้ การตรวจสอบรีลีสแบบเต็มที่มี `run_release_soak=true` หรือ `release_profile=full` จะตั้งค่า `published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15'` และ `published_upgrade_survivor_scenarios=reported-issues` เพื่อขยายการตรวจสอบให้ครอบคลุมรีลีส npm แบบ stable ล่าสุดสี่รายการ พร้อมรีลีสขอบเขตความเข้ากันได้ของ Plugin ที่ปักหมุดไว้และฟิกซ์เจอร์ที่จำลองรูปแบบปัญหาสำหรับการกำหนดค่า Feishu, ไฟล์ bootstrap/persona ที่เก็บรักษาไว้, การติดตั้ง Plugin OpenClaw ที่กำหนดค่าไว้, พาธล็อกที่ใช้ทิลเดอ และรากดีเพนเดนซี Plugin แบบเก่าที่ล้าสมัย การเลือกผู้รอดจากการอัปเกรดที่เผยแพร่แล้วแบบหลายฐานจะแบ่งชาร์ดตามฐานเป็นงานตัวรัน Docker แบบเจาะจงแยกกัน เวิร์กโฟลว์ `Update Migration` ที่แยกต่างหากใช้เลน Docker `update-migration` พร้อมฐาน `all-since-2026.4.23` และสถานการณ์ `plugin-deps-cleanup` เมื่อคำถามคือการล้างข้อมูลการอัปเดตที่เผยแพร่แล้วอย่างครอบคลุม ไม่ใช่ขอบเขต CI รีลีสแบบเต็มตามปกติ การเรียกใช้แบบรวมภายในเครื่องสามารถส่งข้อกำหนดแพ็กเกจที่ตรงกันทุกประการด้วย `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, คงเลนเดียวไว้ด้วย `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC` เช่น `openclaw@2026.4.15` หรือตั้งค่า `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` สำหรับเมทริกซ์สถานการณ์ เลนที่เผยแพร่แล้วจะกำหนดค่าฐานด้วยชุดคำสั่ง `openclaw config set` ที่ฝังไว้ บันทึกขั้นตอนของชุดคำสั่งใน `summary.json` และตรวจสอบ `/healthz`, `/readyz` รวมถึงสถานะ RPC หลังเริ่ม Gateway เลนแพ็กเกจและตัวติดตั้งแบบใหม่ของ Windows ยังตรวจสอบด้วยว่าแพ็กเกจที่ติดตั้งสามารถนำเข้า browser-control override จากพาธ Windows แบบสัมบูรณ์ดิบได้ การทดสอบแบบ smoke ของ agent turn สำหรับ OpenAI ข้ามระบบปฏิบัติการจะใช้ `OPENCLAW_CROSS_OS_OPENAI_MODEL` เป็นค่าเริ่มต้นเมื่อมีการตั้งค่า มิฉะนั้นจะใช้ `openai/gpt-5.6-luna` เพื่อให้หลักฐานการติดตั้งและ Gateway ใช้ระดับทดสอบ GPT-5.6 ที่มีต้นทุนต่ำกว่า

### ช่วงความเข้ากันได้กับระบบเก่า

การยอมรับแพ็กเกจมีช่วงความเข้ากันได้กับระบบเก่าที่มีขอบเขตจำกัดสำหรับแพ็กเกจที่เผยแพร่แล้ว แพ็กเกจจนถึง `2026.4.25` รวมถึง `2026.4.25-beta.*` อาจใช้เส้นทางความเข้ากันได้:

- รายการ QA ส่วนตัวที่ทราบใน `dist/postinstall-inventory.json` อาจชี้ไปยังไฟล์ที่ถูกละเว้นจาก tarball;
- `doctor-switch` อาจข้ามกรณีย่อยด้านการคงอยู่ของ `gateway install --wrapper` เมื่อแพ็กเกจไม่เปิดเผยแฟล็กนั้น;
- `update-channel-switch` อาจตัด `patchedDependencies` ของ pnpm ที่หายไปออกจากฟิกซ์เจอร์ git จำลองที่ได้จาก tarball และอาจบันทึก `update.channel` ที่คงอยู่แต่หายไป;
- การทดสอบแบบ smoke ของ Plugin อาจอ่านตำแหน่งบันทึกการติดตั้งแบบเก่า หรือยอมรับการไม่คงอยู่ของบันทึกการติดตั้งจากมาร์เก็ตเพลส;
- `plugin-update` อาจอนุญาตการย้ายข้อมูลเมทาดาทาการกำหนดค่า โดยยังคงกำหนดให้บันทึกการติดตั้งและพฤติกรรมไม่ติดตั้งซ้ำต้องไม่เปลี่ยนแปลง

แพ็กเกจ `2026.4.26` ที่เผยแพร่แล้วอาจเตือนเกี่ยวกับไฟล์ประทับเมทาดาทาบิลด์ภายในเครื่องที่เคยส่งมอบแล้วได้เช่นกัน และแพ็กเกจจนถึง `2026.5.20` อาจเตือนแทนการล้มเหลวเมื่อ `npm-shrinkwrap.json` หายไป แพ็กเกจรุ่นหลังต้องเป็นไปตามสัญญาสมัยใหม่ โดยเงื่อนไขเดียวกันจะทำให้ล้มเหลวแทนการเตือนหรือข้าม

### ตัวอย่าง

```bash
# ตรวจสอบแพ็กเกจ beta ปัจจุบันด้วยความครอบคลุมระดับผลิตภัณฑ์
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f telegram_mode=mock-openai

# ตรวจสอบแพ็กเกจ extended-stable ที่เผยแพร่แล้วด้วยความครอบคลุมระดับแพ็กเกจ
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# แพ็กและตรวจสอบบรานช์รีลีสด้วยชุดทดสอบปัจจุบัน
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=release/YYYY.M.PATCH \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

# ตรวจสอบ URL ของ tarball ต้องระบุ SHA-256 สำหรับ source=url
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=url \
  -f package_url=https://example.com/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# ตรวจสอบ tarball จากนโยบายมิเรอร์ส่วนตัวที่เชื่อถือได้ซึ่งระบุชื่อไว้
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=trusted-url \
  -f trusted_source_id=enterprise-artifactory \
  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \
  -f package_sha256=<64-char-sha256> \
  -f suite_profile=smoke

# ใช้ tarball ที่อัปโหลดโดยการเรียกใช้ Actions อื่นซ้ำ
gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=artifact \
  -f artifact_run_id=<run-id> \
  -f artifact_name=package-under-test \
  -f suite_profile=custom \
  -f docker_lanes='install-e2e plugin-update'
```

เมื่อดีบักการเรียกใช้การยอมรับแพ็กเกจที่ล้มเหลว ให้เริ่มที่สรุป `resolve_package` เพื่อยืนยันแหล่งที่มาของแพ็กเกจ เวอร์ชัน และ SHA-256 จากนั้นตรวจสอบการเรียกใช้ลูก `docker_acceptance` และอาร์ติแฟกต์ Docker ได้แก่ `.artifacts/docker-tests/**/summary.json`, `failures.json`, ล็อกของเลน, ระยะเวลาของแต่ละเฟส และคำสั่งเรียกใช้ซ้ำ ควรเรียกใช้โปรไฟล์แพ็กเกจที่ล้มเหลวหรือเลน Docker ที่ระบุแน่นอนซ้ำ แทนการเรียกใช้การตรวจสอบรีลีสแบบเต็มซ้ำ

## การทดสอบเบื้องต้นของการติดตั้ง

เวิร์กโฟลว์ `Install Smoke` จะไม่ทำงานบน pull request หรือการพุช `main` อีกต่อไป Wrapper สำหรับการทำงานรายคืน/ด้วยตนเองและการตรวจสอบความถูกต้องของรีลีสต่างเรียกใช้แกนหลัก `install-smoke-reusable.yml` แบบอ่านอย่างเดียว และทุกการทำงานจะดำเนินตามเส้นทางการทดสอบเบื้องต้นของการติดตั้งแบบเต็มบน Runner ที่โฮสต์โดย GitHub:

- อิมเมจทดสอบเบื้องต้นจาก Dockerfile รากจะถูกสร้างหนึ่งครั้งต่อ SHA เป้าหมาย ผูกกับรุ่นแก้ไขของเวิร์กโฟลว์และความพยายามของผู้ผลิตในอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้ จากนั้น CLI smoke, การทดสอบ CLI smoke ที่เอเจนต์ลบพื้นที่ทำงานร่วมกัน, E2E ของเครือข่าย Gateway ในคอนเทนเนอร์ และการทดสอบ build-arg ของ Plugin `matrix` ที่รวมมาในชุดจะโหลดอิมเมจดังกล่าว การทดสอบ Plugin จะตรวจสอบการทำมิเรอร์การติดตั้งการขึ้นต่อกันของรันไทม์ และตรวจสอบว่า Plugin โหลดได้โดยไม่มีการวินิจฉัยการหลุดออกจากจุดเข้า
- การติดตั้งแพ็กเกจ QR และการทดสอบ Docker เบื้องต้นของตัวติดตั้ง/การอัปเดต (รวมถึงเลนตัวติดตั้ง Rocky Linux และเลนอัปเดตเทียบกับค่าเริ่มต้น npm `update_baseline_version` ที่กำหนดค่าได้) จะทำงานเป็นงานแยกกัน เพื่อให้งานตัวติดตั้งไม่ต้องรอหลังการทดสอบอิมเมจราก

การทดสอบผู้ให้บริการอิมเมจสำหรับการติดตั้ง Bun แบบโกลบอลที่ทำงานช้าจะถูกควบคุมแยกต่างหากด้วย `run_bun_global_install_smoke` โดยทำงานตามกำหนดการรายคืน เปิดใช้โดยค่าเริ่มต้นสำหรับการเรียกเวิร์กโฟลว์จากการตรวจสอบรีลีส และการสั่งทำงาน `Install Smoke` ด้วยตนเองสามารถเลือกเข้าร่วมได้ CI ของ PR ปกติยังคงเรียกใช้เลนตรวจสอบการถดถอยของตัวเรียกใช้ Bun แบบรวดเร็วสำหรับการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node การทดสอบ Docker สำหรับ QR และตัวติดตั้งยังคงใช้ Dockerfile ที่เน้นการติดตั้งของตนเอง

## E2E ของ Docker ภายในเครื่อง

`pnpm test:docker:all` จะสร้างอิมเมจการทดสอบสดที่ใช้ร่วมกันล่วงหน้าหนึ่งอิมเมจ แพ็ก OpenClaw เป็น npm tarball หนึ่งครั้ง และสร้างอิมเมจ `scripts/e2e/Dockerfile` ที่ใช้ร่วมกันสองอิมเมจ:

- Runner Node/Git เปล่าสำหรับเลนตัวติดตั้ง/การอัปเดต/การขึ้นต่อกันของ Plugin;
- อิมเมจใช้งานจริงที่ติดตั้ง tarball เดียวกันลงใน `/app` สำหรับเลนการทำงานทั่วไป

ข้อกำหนดเลน Docker อยู่ใน `scripts/lib/docker-e2e-scenarios.mjs` ตรรกะของตัววางแผนอยู่ใน `scripts/lib/docker-e2e-plan.mjs` และ Runner จะดำเนินการเฉพาะแผนที่เลือก ตัวจัดกำหนดการเลือกอิมเมจต่อเลนด้วย `OPENCLAW_DOCKER_E2E_BARE_IMAGE` และ `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE` จากนั้นเรียกใช้เลนด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1`

### ค่าที่ปรับแต่งได้

| ตัวแปร                               | ค่าเริ่มต้น | วัตถุประสงค์                                                                                       |
| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | จำนวนสล็อตของพูลหลักสำหรับเลนปกติ                                                        |
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | จำนวนสล็อตของพูลส่วนท้ายที่ไวต่อผู้ให้บริการ                                                      |
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | ขีดจำกัดเลนสดที่ทำงานพร้อมกัน เพื่อไม่ให้ผู้ให้บริการจำกัดอัตรา                                        |
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 5       | ขีดจำกัดเลนติดตั้ง npm ที่ทำงานพร้อมกัน                                                              |
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | ขีดจำกัดเลนหลายบริการที่ทำงานพร้อมกัน                                                            |
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | ระยะหน่วงระหว่างการเริ่มเลนเพื่อหลีกเลี่ยงการสร้างพร้อมกันอย่างหนักของ Docker daemon; ตั้งค่า `0` เพื่อไม่ใช้ระยะหน่วง     |
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | ระยะหมดเวลาสำรองต่อเลน (120 นาที); เลนสด/ส่วนท้ายที่เลือกใช้ขีดจำกัดที่เข้มงวดกว่า           |
| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | ไม่ได้ตั้งค่า   | `1` จะแสดงแผนของตัวจัดกำหนดการโดยไม่เรียกใช้เลน                                          |
| `OPENCLAW_DOCKER_ALL_LANES`            | ไม่ได้ตั้งค่า   | รายการเลนแบบตรงกันทุกประการคั่นด้วยจุลภาค; ข้ามการทดสอบการล้างข้อมูลเพื่อให้เอเจนต์ทำซ้ำเลนที่ล้มเหลวหนึ่งเลนได้ |

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

### เวิร์กโฟลว์สด/E2E ที่นำกลับมาใช้ใหม่ได้

เวิร์กโฟลว์สด/E2E ที่นำกลับมาใช้ใหม่ได้จะสอบถาม `scripts/test-docker-all.mjs --plan-json` ว่าต้องใช้แพ็กเกจ ชนิดอิมเมจ อิมเมจสด เลน และความครอบคลุมของข้อมูลประจำตัวใด จากนั้น `scripts/docker-e2e.mjs` จะแปลงแผนดังกล่าวเป็นเอาต์พุตและข้อมูลสรุปของ GitHub โดยจะเลือกแพ็ก OpenClaw ผ่าน `scripts/package-openclaw-for-docker.mjs`, ดาวน์โหลดอาร์ติแฟกต์แพ็กเกจของการทำงานปัจจุบัน หรือดาวน์โหลดอาร์ติแฟกต์แพ็กเกจจาก `package_artifact_run_id` แล้วตรวจสอบรายการภายใน tarball เส้นทางเริ่มต้น `no-push-artifact` จะสร้างอิมเมจเปล่า/ใช้งานจริงที่ติดแท็กด้วยไดเจสต์ของแพ็กเกจผ่านแคชเลเยอร์ Docker ของ Blacksmith แพ็กไบต์ของอิมเมจที่ตรงกันทุกประการลงในอาร์ติแฟกต์เวิร์กโฟลว์แบบเปลี่ยนแปลงไม่ได้ และให้ผู้ใช้แต่ละรายตรวจสอบและโหลดอาร์ติแฟกต์นั้น ส่วน `existing-only` ต้องระบุการอ้างอิง GHCR `docker_e2e_bare_image`/`docker_e2e_functional_image` อย่างชัดเจนแทน และจะไม่สร้างหรือพุช การดึงจากรีจิสทรีเหล่านั้นใช้ระยะหมดเวลาต่อความพยายามแบบจำกัดที่ 180 วินาที เพื่อให้สตรีมที่ค้างลองใหม่อย่างรวดเร็ว แทนที่จะใช้เวลาส่วนใหญ่ของเส้นทางวิกฤตใน CI หลังการตรวจสอบตามกำหนดการสำเร็จ `openclaw-scheduled-live-checks.yml` จะส่งแมนิเฟสต์อิมเมจที่ทดสอบแล้วแบบเปลี่ยนแปลงไม่ได้ไปยังผู้เผยแพร่ที่เขียนแพ็กเกจแยกต่างหาก ผู้เรียกรีลีสและพรีรีลีสแบบอ่านอย่างเดียวจะไม่ผ่านตัวเขียนนั้น

### ส่วนย่อยของเส้นทางรีลีส

ความครอบคลุม Docker ของรีลีสจะทำงานเป็นงานส่วนย่อยขนาดเล็กด้วย `OPENCLAW_SKIP_DOCKER_BUILD=1` เพื่อให้แต่ละส่วนย่อยตรวจสอบและโหลดเฉพาะชนิดอิมเมจที่มีอาร์ติแฟกต์รองรับตามที่ต้องใช้ (หรือดึงอิมเมจภายใต้การใช้ซ้ำ `existing-only` ที่ระบุอย่างชัดเจน) และดำเนินการหลายเลนผ่านตัวจัดกำหนดการแบบถ่วงน้ำหนักเดียวกัน:

- `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
- `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui`

ส่วนย่อย Docker ของรีลีสปัจจุบันคือ `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` ถึง `plugins-runtime-install-h` และ `openwebui` โดย `package-update-openai` รวมเลนแพ็กเกจ Plugin Codex แบบสด ซึ่งติดตั้งแพ็กเกจ OpenClaw ตัวเลือก ติดตั้ง Plugin Codex จาก `codex_plugin_spec` หรือ tarball ของการอ้างอิงเดียวกันโดยมีการอนุมัติการติดตั้ง Codex CLI อย่างชัดเจน เรียกใช้การตรวจสอบล่วงหน้าของ Codex CLI และรอบการทำงานของเอเจนต์ในเซสชันเดียวกัน จากนั้นเรียกใช้รอบที่ไม่มีการลองใหม่และใช้การคิดระดับปานกลาง ซึ่งส่งความคืบหน้า อ่านอินพุตพื้นที่ทำงานแบบสุ่ม เขียนอาร์ติแฟกต์ที่ตรงกันทุกประการ และส่งการแจ้งเสร็จสมบูรณ์ `plugins-runtime-core`, `plugins-runtime` และ `plugins-integrations` ยังคงเป็นนามแฝงรวมของ Plugin/รันไทม์ นามแฝงเลน `install-e2e` ยังคงเป็นนามแฝงรวมสำหรับการเรียกซ้ำด้วยตนเองของเลนตัวติดตั้งผู้ให้บริการทั้งสอง

OpenWebUI ทำงานเป็นส่วนย่อย `openwebui` แบบสแตนด์อโลนบน Runner Blacksmith ที่มีดิสก์ขนาดใหญ่โดยเฉพาะ เมื่อใดก็ตามที่ความครอบคลุมเส้นทางรีลีสแบบเสถียรหรือแบบเต็มร้องขอ แม้ในกรณีที่เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้กำหนดเส้นทางงานที่รองรับไปยัง Runner ที่โฮสต์โดย GitHub การแยกการดึงอิมเมจภายนอกออกมาต่างหากช่วยป้องกันไม่ให้อิมเมจขนาดใหญ่แข่งขันกับแพ็กเกจและอิมเมจ Plugin ที่ใช้ร่วมกันใน `plugins-runtime-services`; ส่วนย่อยรวม Plugin/รันไทม์แบบเดิมยังคงรวม OpenWebUI สำหรับการเรียกซ้ำด้วยตนเองที่เข้ากันได้ เลนอัปเดตช่องทางที่รวมมาในชุดจะลองใหม่หนึ่งครั้งเมื่อเกิดความล้มเหลวชั่วคราวของเครือข่าย npm

แต่ละส่วนย่อยจะอัปโหลด `.artifacts/docker-tests/` พร้อมบันทึกของเลน เวลา `summary.json`, `failures.json`, เวลาของแต่ละเฟส, JSON แผนตัวจัดกำหนดการ, ตารางเลนที่ทำงานช้า และคำสั่งเรียกซ้ำต่อเลน อินพุตเวิร์กโฟลว์ `docker_lanes` จะเรียกใช้เลนที่เลือกกับอิมเมจที่เตรียมไว้สำหรับการทำงานนั้นแทนงานส่วนย่อย ซึ่งจำกัดการดีบักเลนที่ล้มเหลวไว้ที่งาน Docker เป้าหมายเพียงงานเดียว หากเลนที่เลือกเป็นเลน Docker แบบสด งานเป้าหมายจะสร้างอิมเมจการทดสอบสดภายในเครื่องสำหรับการเรียกซ้ำนั้น ตัวช่วยเรียกซ้ำจะตรวจสอบ SHA เป้าหมายที่เลือกอย่างตรงกันทุกประการของอาร์ติแฟกต์ความล้มเหลว และการสั่งทำงานด้วยตนเองจะแพ็กการอ้างอิงนั้นใหม่ เนื่องจากทูเพิลแพ็กเกจภายในของเวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้ไม่ใช่ส่วนหนึ่งของสคีมา `workflow_dispatch` คำสั่งที่สร้างขึ้นจะรวมอินพุตอิมเมจที่เตรียมไว้และ `shared_image_policy=existing-only` เฉพาะเมื่ออินพุตเหล่านั้นมี GHCR รองรับ; แท็กอาร์ติแฟกต์เฉพาะ Runner จะถูกละไว้ เพื่อให้ Runner ใหม่สร้างแท็กดังกล่าวขึ้นใหม่ การแทนที่เป้าหมายอย่างชัดเจนจะทิ้งการอ้างอิงอิมเมจ GHCR ที่กู้คืนมา เว้นแต่อาร์ติแฟกต์จะพิสูจน์ว่าตรงกับค่าที่แทนที่ การอ้างอิงข้อกำหนดเวิร์กโฟลว์ที่สร้างจากอาร์ติแฟกต์จะถูกละไว้เช่นกัน เนื่องจากสาขาชั่วคราวของรีลีสแบบเต็มจะถูกลบ การสั่งทำงานจะใช้สาขาเริ่มต้นของที่เก็บ เว้นแต่ผู้ปฏิบัติงานจะระบุค่าแทนที่อย่างชัดเจน

```bash
pnpm test:docker:rerun <run-id>      # ดาวน์โหลดอาร์ติแฟกต์ Docker และแสดงคำสั่งเรียกซ้ำแบบกำหนดเป้าหมายทั้งแบบรวม/ต่อเลน
pnpm test:docker:timings <summary>   # ข้อมูลสรุปเลนที่ทำงานช้าและเส้นทางวิกฤตของแต่ละเฟส
```

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

## พรีรีลีสของ Plugin

`Plugin Prerelease` เป็นความครอบคลุมผลิตภัณฑ์/แพ็กเกจที่มีค่าใช้จ่ายสูงกว่า จึงเป็นเวิร์กโฟลว์แยกที่สั่งทำงานโดย `Full Release Validation` หรือผู้ปฏิบัติงานที่ระบุอย่างชัดเจน Pull request ปกติ การพุช `main` และการสั่งทำงาน CI ด้วยตนเองแบบสแตนด์อโลนจะไม่เปิดใช้ชุดดังกล่าว เวิร์กโฟลว์นี้กระจายการทดสอบ Plugin ที่รวมมาในชุดให้สมดุลระหว่าง Worker ส่วนขยายแปดตัว งานชาร์ดส่วนขยายเหล่านั้นจะเรียกใช้กลุ่มการกำหนดค่า Plugin ได้พร้อมกันสูงสุดสองกลุ่ม โดยมี Worker Vitest หนึ่งตัวต่อกลุ่มและฮีป Node ที่ใหญ่ขึ้น เพื่อไม่ให้ชุด Plugin ที่มีการนำเข้าจำนวนมากสร้างงาน CI เพิ่มเติม เส้นทาง Docker สำหรับพรีรีลีสเฉพาะรีลีส (เปิดใช้โดยอินพุต `full_release_validation`) จะรวมเลน Docker เป้าหมายเป็นกลุ่มละสี่ เพื่อหลีกเลี่ยงการจอง Runner หลายสิบตัวสำหรับงานที่ใช้เวลาหนึ่งถึงสามนาที เวิร์กโฟลว์ยังอัปโหลดอาร์ติแฟกต์ `plugin-inspector-advisory` เพื่อให้ข้อมูลจาก `@openclaw/plugin-inspector`; ผลการตรวจสอบเป็นอินพุตสำหรับการคัดแยก และไม่เปลี่ยนเกต Plugin Prerelease ที่บล็อกอยู่

## QA Lab

QA Lab มีเลน CI เฉพาะนอกเวิร์กโฟลว์หลักที่กำหนดขอบเขตอย่างชาญฉลาด ความเท่าเทียมของ Agentic ซ้อนอยู่ภายใต้ Harness QA และรีลีสแบบกว้าง ไม่ใช่เวิร์กโฟลว์ PR แบบสแตนด์อโลน ใช้ `Full Release Validation` กับ `rerun_group=qa-parity` เมื่อต้องการให้ความเท่าเทียมทำงานร่วมกับการตรวจสอบแบบกว้าง

- เวิร์กโฟลว์ `QA-Lab - All Lanes` ทำงานทุกคืนบน `main` และเมื่อสั่งทำงานด้วยตนเอง โดยกระจายงานความเท่าเทียมแบบจำลองและงาน Matrix, Telegram, Discord, WhatsApp และ Slack แบบสด งานสดใช้สภาพแวดล้อม `qa-live-shared`; Telegram, Discord, WhatsApp และ Slack ใช้สัญญาเช่า Convex ส่วน Matrix จัดเตรียมข้อมูลประจำตัวภายในเครื่องแบบใช้แล้วทิ้ง

การตรวจสอบรีลีสจะเรียกใช้เลนการขนส่ง Matrix และ Telegram แบบสดด้วยผู้ให้บริการจำลองที่กำหนดผลลัพธ์ได้และโมเดลที่ระบุคุณสมบัติเป็นแบบจำลอง (`mock-openai/gpt-5.6-luna` และ `mock-openai/gpt-5.6-luna-alt`) เพื่อแยกสัญญาช่องทางออกจากเวลาแฝงของโมเดลสดและการเริ่มต้น Plugin ผู้ให้บริการตามปกติ Gateway สำหรับการขนส่งสดจะปิดใช้การค้นหาหน่วยความจำ เนื่องจากความเท่าเทียมของ QA ครอบคลุมพฤติกรรมหน่วยความจำแยกต่างหาก ส่วนการเชื่อมต่อผู้ให้บริการครอบคลุมโดยชุดโมเดลสด ผู้ให้บริการเนทีฟ และผู้ให้บริการ Docker ที่แยกต่างหาก

เกต Matrix ตามกำหนดการและของรีลีสใช้โฮสต์ชุด QA Lab ที่ใช้ร่วมกันและอะแดปเตอร์สดกับสถานการณ์รีลีส ค่าเริ่มต้นของ CLI และอินพุตเวิร์กโฟลว์ด้วยตนเองยังคงเป็น `all`; การสั่งทำงาน `all` ด้วยตนเองจะกระจายโปรไฟล์ `transport`, `media`, `e2ee-smoke`, `e2ee-deep` และ `e2ee-cli` เพื่อให้หลักฐาน 93 สถานการณ์อยู่ภายในระยะหมดเวลาต่องาน การสั่งทำงานด้วยตนเองแบบเจาะจงจะเลือก `fast`, `release` หรือ `transport` ในงานเดียว

`OpenClaw Release Checks` ยังเรียกใช้เลน QA Lab ที่สำคัญต่อรีลีสก่อนการอนุมัติรีลีส เกตความเท่าเทียมของ QA จะเรียกใช้แพ็กตัวเลือกและแพ็กค่าพื้นฐานเป็นงานเลนแบบขนาน จากนั้นดาวน์โหลดอาร์ติแฟกต์ทั้งสองไปยังงานรายงานขนาดเล็กเพื่อเปรียบเทียบความเท่าเทียมขั้นสุดท้าย

สำหรับ PR ปกติ ให้ใช้หลักฐาน CI/การตรวจสอบตามขอบเขต แทนการถือว่าความเท่าเทียมเป็นสถานะที่จำเป็น

## CodeQL

เวิร์กโฟลว์ `CodeQL` ตั้งใจให้เป็นเครื่องสแกนความปลอดภัยรอบแรกที่มีขอบเขตแคบ ไม่ใช่การกวาดตรวจทั้งที่เก็บ การทำงานรายวัน ด้วยตนเอง การพุช `main` และการทำงานป้องกันสำหรับ pull request ที่ไม่ใช่ฉบับร่าง จะสแกนโค้ดเวิร์กโฟลว์ Actions รวมถึงพื้นผิว JavaScript/TypeScript ที่มีความเสี่ยงสูงสุด ด้วยคิวรีความปลอดภัยที่มีความเชื่อมั่นสูงซึ่งกรองเป็น `security-severity` ระดับสูง/วิกฤต

ตัวป้องกัน pull request ยังคงมีขอบเขตเบา โดยจะเริ่มทำงานเฉพาะเมื่อมีการเปลี่ยนแปลงภายใต้ `.github/actions`, `.github/codeql`, `.github/workflows`, `packages`, `scripts`, `src` หรือพาธรันไทม์ของ Plugin แบบรวมที่เป็นเจ้าของกระบวนการ และจะเรียกใช้เมทริกซ์ความปลอดภัยความเชื่อมั่นสูงชุดเดียวกับเวิร์กโฟลว์ตามกำหนดการ ส่วน CodeQL สำหรับ Android และ macOS จะไม่รวมอยู่ในค่าเริ่มต้นของ PR

### หมวดหมู่ความปลอดภัย

| หมวดหมู่                                          | พื้นผิว                                                                                                                             |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-security-high/core-auth-secrets`         | เส้นฐานของการยืนยันตัวตน ข้อมูลลับ แซนด์บ็อกซ์ cron และ gateway                                                                                  |
| `/codeql-security-high/channel-runtime-boundary`  | สัญญาการติดตั้งใช้งานช่องทางหลัก รวมถึงรันไทม์ Plugin ช่องทาง, gateway, Plugin SDK, ข้อมูลลับ และจุดเชื่อมต่อการตรวจสอบ              |
| `/codeql-security-high/network-ssrf-boundary`     | พื้นผิวนโยบาย SSRF ของ SSRF หลัก การแยกวิเคราะห์ IP ตัวป้องกันเครือข่าย การดึงข้อมูลเว็บ และ Plugin SDK                                                |
| `/codeql-security-high/mcp-process-tool-boundary` | เซิร์ฟเวอร์ MCP ตัวช่วยเรียกใช้กระบวนการ การส่งออก และเกตการเรียกใช้เครื่องมือของเอเจนต์                                           |
| `/codeql-security-high/process-exec-boundary`     | เชลล์ภายในเครื่อง ตัวช่วยสร้างกระบวนการ รันไทม์ Plugin แบบรวมที่เป็นเจ้าของกระบวนการย่อย และส่วนเชื่อมสคริปต์เวิร์กโฟลว์                             |
| `/codeql-security-high/plugin-trust-boundary`     | พื้นผิวความเชื่อถือของการติดตั้ง Plugin, ตัวโหลด, แมนิเฟสต์, รีจิสทรี, การติดตั้งด้วยตัวจัดการแพ็กเกจ, การโหลดซอร์ส และสัญญาแพ็กเกจ Plugin SDK |

### ชาร์ดความปลอดภัยเฉพาะแพลตฟอร์ม

- `CodeQL Android Critical Security` — ชาร์ดความปลอดภัย Android ตามกำหนดการ สร้างแอป Android ด้วยตนเองสำหรับ CodeQL บนรันเนอร์ Blacksmith Linux ที่เล็กที่สุดซึ่งผ่านการตรวจสอบความสมเหตุสมผลของเวิร์กโฟลว์ อัปโหลดภายใต้ `/codeql-critical-security/android`
- `CodeQL macOS Critical Security` — ชาร์ดความปลอดภัย macOS แบบรายสัปดาห์/เรียกด้วยตนเอง สร้างแอป macOS ด้วยตนเองสำหรับ CodeQL บน Blacksmith macOS กรองผลลัพธ์การสร้างของการอ้างอิงออกจาก SARIF ที่อัปโหลด และอัปโหลดภายใต้ `/codeql-critical-security/macos` โดยแยกออกจากค่าเริ่มต้นรายวัน เนื่องจากการสร้างบน macOS ใช้เวลาส่วนใหญ่ของรันไทม์แม้ไม่มีปัญหา

### หมวดหมู่คุณภาพระดับวิกฤต

`CodeQL Critical Quality` คือชาร์ดคู่กันที่ไม่ใช่ด้านความปลอดภัย โดยเรียกใช้เฉพาะคิวรีคุณภาพ JavaScript/TypeScript ที่ไม่ใช่ด้านความปลอดภัยและมีระดับความรุนแรงเป็นข้อผิดพลาด บนพื้นผิวมูลค่าสูงที่มีขอบเขตแคบโดยใช้รันเนอร์ Linux ที่โฮสต์โดย GitHub เพื่อไม่ให้การสแกนคุณภาพใช้งบประมาณการลงทะเบียนรันเนอร์ Blacksmith ตัวป้องกัน pull request ของชาร์ดนี้ตั้งใจให้มีขอบเขตเล็กกว่าโปรไฟล์ตามกำหนดการ โดย PR ที่ไม่ใช่ฉบับร่างจะเรียกใช้เฉพาะชาร์ดที่ตรงกับพื้นผิวซึ่งมีการแก้ไข จากชาร์ดที่กำหนดเส้นทาง PR ได้ทั้งหมด 13 ชาร์ด ได้แก่ `agent-runtime-boundary`, `channel-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `gateway-runtime-boundary`, `mcp-process-runtime-boundary`, `memory-runtime-boundary`, `network-runtime-boundary`, `plugin-boundary`, `plugin-sdk-package-contract`, `plugin-sdk-reply-runtime`, `provider-runtime-boundary` และ `session-diagnostics-boundary` ส่วน `ui-control-plane` และ `web-media-runtime-boundary` จะไม่รวมอยู่ในการเรียกใช้ของ PR การเปลี่ยนแปลงการกำหนดค่า CodeQL และเวิร์กโฟลว์คุณภาพจะเรียกใช้ชุดชาร์ด PR ทั้งหมด (ชาร์ดรันไทม์เครือข่ายจะใช้ไฟล์การกำหนดค่า CodeQL ของตนเองและพาธซอร์สที่เป็นเจ้าของเครือข่ายเป็นตัวกำหนด)

การสั่งทำงานด้วยตนเองรองรับ:

```text
profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
```

โปรไฟล์ขอบเขตแคบเป็นฮุกสำหรับการเรียนรู้/การทำซ้ำ เพื่อเรียกใช้ชาร์ดคุณภาพหนึ่งรายการแยกจากส่วนอื่น

| หมวดหมู่                                                | พื้นผิว                                                                                                                                                           |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-critical-quality/core-auth-secrets`            | โค้ดขอบเขตความปลอดภัยสำหรับการยืนยันตัวตน ข้อมูลลับ แซนด์บ็อกซ์ cron และ gateway                                                                                                  |
| `/codeql-critical-quality/config-boundary`              | สัญญาของสคีมาการกำหนดค่า การย้ายข้อมูล การทำให้เป็นมาตรฐาน และ IO                                                                                                         |
| `/codeql-critical-quality/gateway-runtime-boundary`     | สคีมาโปรโตคอล Gateway และสัญญาเมธอดเซิร์ฟเวอร์                                                                                                              |
| `/codeql-critical-quality/channel-runtime-boundary`     | สัญญาการติดตั้งใช้งานช่องทางหลักและ Plugin ช่องทางแบบรวม                                                                                                  |
| `/codeql-critical-quality/agent-runtime-boundary`       | สัญญารันไทม์สำหรับการเรียกใช้คำสั่ง การส่งต่อโมเดล/ผู้ให้บริการ การส่งต่อและคิวตอบกลับอัตโนมัติ และระนาบควบคุม ACP                                               |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | เซิร์ฟเวอร์ MCP และบริดจ์เครื่องมือ ตัวช่วยกำกับดูแลกระบวนการ และสัญญาการส่งออก                                                                        |
| `/codeql-critical-quality/memory-runtime-boundary`      | SDK โฮสต์หน่วยความจำ ฟาซาดรันไทม์หน่วยความจำ นามแฝง Plugin SDK สำหรับหน่วยความจำ ส่วนเชื่อมการเปิดใช้งานรันไทม์หน่วยความจำ และคำสั่ง doctor สำหรับหน่วยความจำ                                    |
| `/codeql-critical-quality/network-runtime-boundary`     | แพ็กเกจนโยบายเครือข่าย รันไทม์ซ็อกเก็ตดิบและการจับพร็อกซี อุโมงค์ SSH ล็อก gateway ซ็อกเก็ต JSONL และพื้นผิวการขนส่งแบบพุช                                 |
| `/codeql-critical-quality/session-diagnostics-boundary` | กลไกภายในของคิวตอบกลับ คิวการส่งเซสชัน ตัวช่วยผูก/ส่งออกเซสชัน พื้นผิวบันเดิลเหตุการณ์/บันทึกการวินิจฉัย และสัญญา CLI ของ doctor สำหรับเซสชัน |
| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | การส่งต่อการตอบกลับขาเข้าของ Plugin SDK ตัวช่วยเพย์โหลด/การแบ่งส่วน/รันไทม์การตอบกลับ ตัวเลือกการตอบกลับของช่องทาง คิวการส่ง และตัวช่วยผูกเซสชัน/เธรด             |
| `/codeql-critical-quality/provider-runtime-boundary`    | การทำแค็ตตาล็อกโมเดลให้เป็นมาตรฐาน การยืนยันตัวตนและการค้นหาผู้ให้บริการ การลงทะเบียนรันไทม์ผู้ให้บริการ ค่าเริ่มต้น/แค็ตตาล็อกผู้ให้บริการ และรีจิสทรีเว็บ/การค้นหา/การดึงข้อมูล/เอ็มเบดดิง    |
| `/codeql-critical-quality/ui-control-plane`             | การบูต Control UI การเก็บข้อมูลภายในเครื่อง โฟลว์ควบคุม gateway และสัญญารันไทม์ระนาบควบคุมงาน                                                          |
| `/codeql-critical-quality/web-media-runtime-boundary`   | สัญญารันไทม์สำหรับการดึงข้อมูล/ค้นหาเว็บหลัก IO สื่อ การทำความเข้าใจสื่อ การสร้างรูปภาพ และการสร้างสื่อ                                                    |
| `/codeql-critical-quality/plugin-boundary`              | สัญญาของตัวโหลด รีจิสทรี พื้นผิวสาธารณะ และจุดเริ่มต้น Plugin SDK                                                                                             |
| `/codeql-critical-quality/plugin-sdk-package-contract`  | ซอร์ส Plugin SDK ฝั่งแพ็กเกจที่เผยแพร่และตัวช่วยสัญญาแพ็กเกจ Plugin                                                                                      |

คุณภาพยังคงแยกจากความปลอดภัย เพื่อให้สามารถกำหนดเวลา วัดผล ปิดใช้งาน หรือขยายผลการตรวจพบด้านคุณภาพได้โดยไม่บดบังสัญญาณด้านความปลอดภัย การขยาย CodeQL สำหรับ Swift, Python และ Plugin แบบรวมควรเพิ่มกลับเข้ามาเฉพาะในรูปแบบงานติดตามผลที่กำหนดขอบเขตหรือแบ่งชาร์ดแล้ว หลังจากโปรไฟล์ขอบเขตแคบมีรันไทม์และสัญญาณที่เสถียร

## เวิร์กโฟลว์การบำรุงรักษา

### เอเจนต์เอกสาร

เวิร์กโฟลว์ `Docs Agent` เป็นเลนการบำรุงรักษา Codex แบบขับเคลื่อนด้วยเหตุการณ์สำหรับทำให้เอกสารที่มีอยู่สอดคล้องกับการเปลี่ยนแปลงที่เพิ่งรวมเข้า ไม่มีการทำงานตามกำหนดเวลาเพียงอย่างเดียว โดยการเรียกใช้ CI จากการพุชที่สำเร็จและไม่ได้มาจากบอตบน `main` สามารถทริกเกอร์ได้ และการสั่งทำงานด้วยตนเองสามารถเรียกใช้ได้โดยตรง การเรียกใช้จาก workflow-run จะข้ามเมื่อ `main` เดินหน้าไปแล้ว หรือเมื่อมีการสร้างการเรียกใช้ Docs Agent อื่นที่ไม่ได้ถูกข้ามภายในชั่วโมงที่ผ่านมา เมื่อทำงาน ระบบจะตรวจสอบช่วงคอมมิตตั้งแต่ SHA ซอร์สของ Docs Agent ครั้งก่อนที่ไม่ได้ถูกข้ามจนถึง `main` ปัจจุบัน ดังนั้นการเรียกใช้หนึ่งครั้งต่อชั่วโมงจึงครอบคลุมการเปลี่ยนแปลงทั้งหมดบน main ที่สะสมตั้งแต่การตรวจเอกสารครั้งล่าสุดได้

### เอเจนต์ประสิทธิภาพการทดสอบ

เวิร์กโฟลว์ `Test Performance Agent` เป็นเลนการบำรุงรักษา Codex แบบขับเคลื่อนด้วยเหตุการณ์สำหรับการทดสอบที่ทำงานช้า ไม่มีการทำงานตามกำหนดเวลาเพียงอย่างเดียว โดยการเรียกใช้ CI จากการพุชที่สำเร็จและไม่ได้มาจากบอตบน `main` สามารถทริกเกอร์ได้ แต่จะข้ามหากการเรียกใช้จาก workflow-run อื่นทำงานไปแล้วหรือกำลังทำงานอยู่ในวัน UTC เดียวกัน การสั่งทำงานด้วยตนเองจะข้ามเกตกิจกรรมรายวันนี้ เลนนี้สร้างรายงานประสิทธิภาพ Vitest แบบจัดกลุ่มของชุดทดสอบทั้งหมด อนุญาตให้ Codex แก้ไขประสิทธิภาพการทดสอบได้เฉพาะขนาดเล็กโดยคงความครอบคลุมไว้แทนการรีแฟกเตอร์วงกว้าง จากนั้นเรียกใช้รายงานชุดทดสอบทั้งหมดอีกครั้งและปฏิเสธการเปลี่ยนแปลงที่ลดจำนวนการทดสอบเส้นฐานที่ผ่าน รายงานแบบจัดกลุ่มจะบันทึกเวลาจริงและ RSS สูงสุดต่อการกำหนดค่าบน Linux และ macOS เพื่อให้การเปรียบเทียบก่อน/หลังแสดงเดลตาหน่วยความจำของการทดสอบควบคู่กับเดลตาระยะเวลา หากเส้นฐานมีการทดสอบที่ล้มเหลว Codex สามารถแก้ไขได้เฉพาะความล้มเหลวที่ชัดเจน และรายงานชุดทดสอบทั้งหมดหลังเอเจนต์ทำงานต้องผ่านก่อนคอมมิตสิ่งใด เมื่อ `main` เดินหน้าก่อนการพุชของบอตจะรวมเข้า เลนนี้จะรีเบสแพตช์ที่ผ่านการตรวจสอบ เรียกใช้ `pnpm check:changed` อีกครั้ง และลองพุชใหม่ ส่วนแพตช์เก่าที่ขัดแย้งกันจะถูกข้าม เลนนี้ใช้ Ubuntu ที่โฮสต์โดย GitHub เพื่อให้แอ็กชัน Codex คงแนวทางความปลอดภัยแบบตัดสิทธิ์ sudo เช่นเดียวกับเอเจนต์เอกสาร

### PR ซ้ำหลังการรวม

เวิร์กโฟลว์ `Duplicate PRs After Merge` เป็นเวิร์กโฟลว์สำหรับผู้ดูแลที่เรียกใช้ด้วยตนเองเพื่อทำความสะอาดรายการซ้ำหลังการรวม ค่าเริ่มต้นเป็น dry-run และจะปิดเฉพาะ PR ที่ระบุไว้อย่างชัดเจนเมื่อ `apply=true` ก่อนเปลี่ยนแปลง GitHub ระบบจะตรวจสอบว่า PR ที่รวมเข้าได้รับการรวมแล้ว และรายการซ้ำแต่ละรายการมี issue อ้างอิงร่วมกันหรือมีฮังก์ที่เปลี่ยนแปลงทับซ้อนกัน

```bash
gh workflow run duplicate-after-merge.yml \
  -f landed_pr=70532 \
  -f duplicate_prs='70530,70592' \
  -f apply=true
```

## เกตการตรวจสอบภายในเครื่องและการกำหนดเส้นทางตามการเปลี่ยนแปลง

ตรรกะเลนตามการเปลี่ยนแปลงภายในเครื่องอยู่ใน `scripts/changed-lanes.mjs` และเรียกใช้โดย `scripts/check-changed.mjs` เกตการตรวจสอบภายในเครื่องนี้เข้มงวดกับขอบเขตสถาปัตยกรรมมากกว่าขอบเขตแพลตฟอร์ม CI แบบกว้าง:

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

การกำหนดเส้นทางการทดสอบตามการเปลี่ยนแปลงภายในเครื่องอยู่ใน `scripts/test-projects.test-support.mjs` และตั้งใจให้มีต้นทุนต่ำกว่า `check:changed` โดยการแก้ไขการทดสอบโดยตรงจะเรียกใช้ตัวเอง การแก้ไขซอร์สจะเลือกการแมปที่ชัดเจนก่อน แล้วจึงเลือกการทดสอบข้างเคียงและรายการที่ขึ้นต่อกันตามกราฟการนำเข้า การกำหนดค่าการส่งในห้องกลุ่มที่ใช้ร่วมกันเป็นหนึ่งในการแมปที่ชัดเจน โดยการเปลี่ยนแปลงการกำหนดค่าการตอบกลับที่มองเห็นได้ในกลุ่ม โหมดการส่งการตอบกลับของซอร์ส หรือพรอมต์ระบบของเครื่องมือข้อความ จะกำหนดเส้นทางผ่านการทดสอบการตอบกลับหลัก รวมถึงรีเกรสชันการส่งของ Discord และ Slack เพื่อให้การเปลี่ยนแปลงค่าเริ่มต้นที่ใช้ร่วมกันล้มเหลวก่อนการพุช PR ครั้งแรก ใช้ `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` เฉพาะเมื่อการเปลี่ยนแปลงครอบคลุมฮาร์เนสกว้างพอจนชุดการแมปต้นทุนต่ำไม่ใช่ตัวแทนที่น่าเชื่อถือ

## การตรวจสอบด้วย Testbox

Crabbox คือ wrapper สำหรับกล่องระยะไกลที่รีโพเป็นเจ้าของ ซึ่งใช้สำหรับการพิสูจน์บน Linux โดยผู้ดูแล เซสชันของเอเจนต์จะรันการทดสอบแบบเจาะจงหนึ่งหรือไม่กี่รายการและการตรวจสอบแบบสแตติกราคาถูกภายในเครื่อง เฉพาะกับซอร์สที่เชื่อถือได้และเมื่อการติดตั้ง dependency ที่มีอยู่พร้อมใช้งานเท่านั้น โดยใช้ Crabbox สำหรับชุดการทดสอบขนาดใหญ่ขึ้นและ
งานที่ใช้ทรัพยากรประมวลผลสูง รวมถึงการ build, typecheck, การกระจายงาน lint,
Docker, เลนแพ็กเกจ, E2E, การพิสูจน์แบบสด และความสอดคล้องกับ CI การพิสูจน์งานหนักของผู้ดูแลที่เชื่อถือได้
ใช้ `blacksmith-testbox` เป็นค่าเริ่มต้น และขณะนี้ `.crabbox.yaml` ก็ใช้ค่านี้เป็นค่าเริ่มต้นเช่นกัน เวิร์กโฟลว์ที่กำหนดค่าไว้
จะเติมข้อมูลรับรองของผู้ให้บริการและเอเจนต์ ดังนั้นโค้ดจากผู้ร่วมพัฒนาที่ไม่น่าเชื่อถือหรือ
โค้ดจาก fork ต้องใช้ CI ของ fork ที่ไม่มีข้อมูลลับ หรือ AWS Crabbox โดยตรงที่ผ่านการทำให้ปลอดภัยแทน
การรันบน AWS ที่ผ่านการทำให้ปลอดภัยจะตั้งค่า `CRABBOX_ENV_ALLOW=CI`, ส่ง
`--no-hydrate` และใช้ `HOME` ระยะไกลชั่วคราวชุดใหม่ ซึ่งจะป้องกันไม่ให้ allowlist
`OPENCLAW_*` ของรีโพและโปรไฟล์การยืนยันตัวตนที่มีอยู่เข้าถึงโค้ดที่ไม่น่าเชื่อถือ
การรันเหล่านี้ใช้ lease ที่วอร์มใหม่และจัดสรรเฉพาะให้ซอร์สที่ไม่น่าเชื่อถือนั้นเท่านั้น ห้ามใช้
lease ที่เชื่อถือได้หรือเคยเติมข้อมูลรับรองแล้ว เรียกใช้ไบนารี Crabbox
ที่เชื่อถือได้และติดตั้งไว้แล้วจาก checkout `main` ที่สะอาดและเชื่อถือได้ และดึงเฉพาะ PR ระยะไกลด้วย
`--fresh-pr` เท่านั้น ห้ามรัน wrapper หรือการกำหนดค่าของ checkout ที่ไม่น่าเชื่อถือภายในเครื่อง
ยกเลิกการตั้งค่า `CRABBOX_AWS_INSTANCE_PROFILE` และปฏิเสธการทำงานโดยค่าเริ่มต้น เว้นแต่
`aws.instanceProfile` ที่ resolve แล้วจะว่างเปล่า ก่อนการติดตั้ง/ทดสอบใด ๆ ให้ใช้เครื่องมือ
ที่เชื่อถือได้ผ่านพาธแบบสัมบูรณ์เพื่อบังคับใช้โทเค็น IMDSv2, พิสูจน์ว่า endpoint ข้อมูลรับรอง IAM
ส่งคืน 404 และเปรียบเทียบ `git rev-parse HEAD` ระยะไกลกับ SHA แบบเต็ม
ของ head PR ที่ผ่านการรีวิวแล้ว ผูก lease เข้ากับ SHA นั้น และหยุด/วอร์มใหม่เมื่อ head เปลี่ยน
อัปโหลด `scripts/crabbox-untrusted-bootstrap.sh` ที่เชื่อถือได้จาก `main` ที่สะอาด
ควบคู่กับ `--fresh-pr` โดยจะติดตั้ง Node/pnpm เวอร์ชันที่ปักหมุดไว้ ตรวจสอบ SHA และ
การปักหมุด package manager, แยก `HOME` ออกจากกัน, ติดตั้ง dependency แล้วจึงรัน
การทดสอบที่ร้องขอ
ยกเลิกการตั้งค่า override `CRABBOX_TAILSCALE*` ทั้งหมด บังคับใช้ `--network public
--tailscale=false`, ล้างแฟล็ก exit-node/LAN และกำหนดให้ `crabbox inspect`
รายงานว่าใช้เครือข่ายสาธารณะโดยไม่มีสถานะ Tailscale ก่อนอัปโหลดสคริปต์ใด ๆ
ความจุ AWS/Hetzner ที่เป็นเจ้าของยังคงเป็นทางเลือกสำรองสำหรับเหตุขัดข้องของ Blacksmith,
ปัญหาโควตา หรือการทดสอบที่ระบุให้ใช้ความจุที่เป็นเจ้าของอย่างชัดเจน

เอเจนต์จะไม่วอร์มล่วงหน้าสำหรับงานที่คาดว่าจะทำ ให้ขอ Testbox แบบ lazy เมื่อ
คำสั่งงานหนักคำสั่งแรกพร้อม ใช้รหัส `tbx_...` ที่ได้รับกลับมาซ้ำสำหรับคำสั่งงานหนัก
คำสั่งต่อ ๆ ไป ซิงค์ checkout ปัจจุบันในการรันทุกครั้ง และหยุดก่อนส่งมอบงาน

การรัน Blacksmith ผ่าน Crabbox จะวอร์ม, อ้างสิทธิ์, ซิงค์, รัน, รายงาน และล้าง
Testbox แบบใช้ครั้งเดียว การตรวจสอบความสมเหตุสมผลของการซิงค์ในตัวจะหยุดทันทีเมื่อ
`git status --short` บนกล่องที่ซิงค์แล้วแสดงการลบไฟล์ที่ติดตามอย่างน้อย 200 รายการ
ซึ่งช่วยตรวจจับไฟล์รากที่หายไป เช่น `pnpm-lock.yaml` สำหรับ PR ที่ตั้งใจ
ลบไฟล์จำนวนมาก ให้ตั้งค่า `CRABBOX_ALLOW_MASS_DELETIONS=1` สำหรับคำสั่งระยะไกล

Crabbox ยังยุติการเรียกใช้ Blacksmith CLI ภายในเครื่องที่ค้างอยู่ใน
ขั้นตอนซิงค์นานกว่าห้านาทีโดยไม่มีเอาต์พุตหลังการซิงค์ ตั้งค่า
`CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0` เพื่อปิดตัวป้องกันนี้ หรือใช้ค่ามิลลิวินาทีที่มากขึ้น
สำหรับ diff ภายในเครื่องที่มีขนาดใหญ่ผิดปกติ

ก่อนการรันครั้งแรก ให้ตรวจสอบ wrapper จากรากของรีโพ:

```bash
pnpm crabbox:run -- --help | sed -n '1,120p'
```

wrapper ของรีโพจะปฏิเสธไบนารี Crabbox ที่ล้าสมัยและไม่ได้ประกาศรองรับผู้ให้บริการที่เลือก และการรันที่ใช้ Blacksmith ต้องใช้ Crabbox 0.22.0 หรือใหม่กว่า เพื่อให้ wrapper ได้รับพฤติกรรมปัจจุบันสำหรับการซิงค์ คิว และการล้าง Testbox ใน worktree ของ Codex หรือ checkout แบบ linked/sparse ให้หลีกเลี่ยงสคริปต์ `pnpm crabbox:run` ภายในเครื่อง เพราะ pnpm อาจปรับ dependency ให้สอดคล้องกันก่อน Crabbox เริ่มทำงาน ให้เรียกใช้ node wrapper โดยตรงแทน:

```bash
node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"
```

เมื่อใช้ checkout ที่อยู่ข้างเคียง ให้ build ไบนารีภายในเครื่องที่ถูก ignore ใหม่ก่อนงานจับเวลาหรือพิสูจน์:

```bash
version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \
  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox
```

บล็อก `blacksmith:` ใน `.crabbox.yaml` ปักหมุดค่าเริ่มต้นขององค์กร เวิร์กโฟลว์ งาน และ ref ไว้แล้ว ดังนั้นแฟล็กที่ระบุอย่างชัดเจนด้านล่างจึงเป็นตัวเลือก เกตสำหรับการเปลี่ยนแปลง:

```bash
pnpm crabbox:run -- --provider blacksmith-testbox \
  --blacksmith-org openclaw \
  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \
  --blacksmith-job check \
  --blacksmith-ref main \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm check:changed"
```

รันการทดสอบแบบเจาะจงซ้ำบน Testbox เมื่อ dependency ภายในเครื่องไม่พร้อมใช้งาน หรือ
เป้าหมายกระจายงานออกไป:

```bash
pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test <path-or-filter>"
```

ชุดการทดสอบทั้งหมด:

```bash
pnpm crabbox:run -- --provider blacksmith-testbox \
  --idle-timeout 90m \
  --ttl 240m \
  --timing-json \
  --shell -- \
  "corepack pnpm test"
```

อ่านสรุป JSON สุดท้าย ฟิลด์ที่มีประโยชน์คือ `provider`, `leaseId`,
`syncDelegated`, `exitCode`, `commandMs` และ `totalMs` สำหรับการรัน
Blacksmith Testbox ที่มอบหมายให้ทำ รหัสออกของ Crabbox wrapper และสรุป JSON คือ
ผลลัพธ์ของคำสั่ง การรัน GitHub Actions ที่เชื่อมโยงอยู่จะเป็นเจ้าของการเติมข้อมูลและ keepalive โดยอาจ
สิ้นสุดด้วย `cancelled` เมื่อ Testbox ถูกหยุดจากภายนอกหลังจากคำสั่ง SSH
ส่งผลลัพธ์กลับมาแล้ว ให้ถือว่านั่นเป็นอาร์ติแฟกต์ของการล้าง/สถานะ เว้นแต่
`exitCode` ของ wrapper จะไม่เป็นศูนย์ หรือเอาต์พุตคำสั่งแสดงว่าการทดสอบล้มเหลว
การรัน Crabbox แบบใช้ครั้งเดียวที่ใช้ Blacksmith ควรหยุด Testbox โดยอัตโนมัติ
หากการรันถูกขัดจังหวะหรือสถานะการล้างไม่ชัดเจน ให้ตรวจสอบกล่องที่ยังทำงานอยู่และหยุดเฉพาะ
กล่องที่สร้างขึ้น:

```bash
blacksmith testbox list --all
blacksmith testbox status --id <tbx_id>
blacksmith testbox stop --id <tbx_id>
```

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

```bash
node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"
pnpm crabbox:stop -- <tbx_id>
```

นำ lease กลับมาใช้ซ้ำ ไม่ใช่ซอร์สที่ล้าสมัย ละ `--no-sync` ไว้ เพื่อให้การรันแต่ละครั้งอัปโหลด
checkout ปัจจุบัน ใช้ตัวเลือกนี้เฉพาะเมื่อตั้งใจรัน tree ที่ไม่เปลี่ยนแปลงและซิงค์ไว้แล้วซ้ำ
โค้ดจากผู้ร่วมพัฒนาที่ไม่น่าเชื่อถือหรือจาก fork ต้องใช้
`CRABBOX_ENV_ALLOW=CI`, `--provider aws --no-hydrate` และ `HOME` ระยะไกล
ชั่วคราวชุดใหม่สำหรับทุกคำสั่ง ติดตั้ง dependency ภายในคำสั่งที่ผ่านการทำให้ปลอดภัยนั้น
ก่อนทดสอบ นำกลับมาใช้ซ้ำได้เฉพาะ lease ที่วอร์มใหม่และจัดสรรให้ซอร์สที่ไม่น่าเชื่อถือ
ชุดเดียวกันเท่านั้น ห้ามใช้ lease ที่เชื่อถือได้หรือเคยเติมข้อมูลรับรองแล้ว ห้าม
รัน wrapper หรือการกำหนดค่าของ checkout ที่ไม่น่าเชื่อถือภายในเครื่อง ให้เรียกใช้ไบนารี Crabbox
ที่เชื่อถือได้และติดตั้งไว้แล้วจาก `main` ที่สะอาดและเชื่อถือได้ และส่ง `--fresh-pr` ในทุก
การรัน คง `CRABBOX_AWS_INSTANCE_PROFILE` ไว้โดยไม่ตั้งค่า ปฏิเสธ instance profile
ที่ resolve แล้วและไม่ว่างเปล่า กำหนดให้มีหลักฐาน IMDS ระยะไกลที่เชื่อถือได้ว่าไม่มีบทบาท และตรวจสอบ
SHA ของ head ที่ผ่านการรีวิวแล้วก่อนติดตั้ง/ทดสอบ ผูก lease เข้ากับ SHA นั้น และหยุดแล้ว
วอร์มใหม่หลังจาก head เปลี่ยนทุกครั้ง หากไม่มี PR ระยะไกล ให้ใช้ CI ของ fork ที่ไม่มีข้อมูลลับ
ห้ามเลือก `hydrate-github` หรือเวิร์กโฟลว์ Blacksmith ที่เติมข้อมูลรับรองแล้ว
สำหรับซอร์สที่ไม่น่าเชื่อถือ

หาก Crabbox เป็นชั้นที่เสีย แต่ Blacksmith เองยังทำงานได้ ให้ใช้
Blacksmith โดยตรงเฉพาะสำหรับการวินิจฉัย เช่น `list`, `status` และการล้าง แก้ไข
เส้นทาง Crabbox ก่อนถือว่าการรัน Blacksmith โดยตรงเป็นหลักฐานสำหรับผู้ดูแล

หาก `blacksmith testbox list --all` และ `blacksmith testbox status` ทำงานได้ แต่การวอร์มใหม่
ค้างอยู่ที่ `queued` โดยไม่มี IP หรือ URL ของการรัน Actions หลังผ่านไปสองสามนาที
ให้ถือว่าเป็นแรงกดดันจากผู้ให้บริการ Blacksmith, คิว, การเรียกเก็บเงิน หรือขีดจำกัดขององค์กร หยุด
รหัสที่อยู่ในคิวซึ่งสร้างขึ้น หลีกเลี่ยงการเริ่ม Testbox เพิ่ม และย้ายการพิสูจน์ไปยัง
เส้นทางความจุ Crabbox ที่เป็นเจ้าของด้านล่าง ระหว่างที่มีผู้ตรวจสอบแดชบอร์ด Blacksmith,
การเรียกเก็บเงิน และขีดจำกัดขององค์กร

ยกระดับไปใช้ความจุ Crabbox ที่เป็นเจ้าของเฉพาะเมื่อ Blacksmith ใช้งานไม่ได้ ถูกจำกัดโควตา ไม่มีสภาพแวดล้อมที่ต้องการ หรือมีเป้าหมายให้ใช้ความจุที่เป็นเจ้าของอย่างชัดเจน:

```bash
CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \
  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90m
pnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>
pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"
pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>
```

เมื่อ AWS อยู่ภายใต้แรงกดดัน ให้หลีกเลี่ยง `class=beast` เว้นแต่งานต้องใช้ CPU ระดับ 48xlarge จริง ๆ คำขอ `beast` เริ่มต้นที่ 192 vCPU และเป็นวิธีที่ง่ายที่สุดในการชนโควตา EC2 Spot หรือ On-Demand Standard ระดับภูมิภาค `.crabbox.yaml` ที่รีโพเป็นเจ้าของใช้ค่าเริ่มต้นเป็น `class: standard`, ตลาด on-demand และ `capacity.hints: true` เพื่อให้ lease AWS ผ่านโบรกเกอร์แสดงภูมิภาค/ตลาดที่เลือก แรงกดดันด้านโควตา การ fallback ไปใช้ Spot และคำเตือนคลาสที่มีแรงกดดันสูง ใช้ `fast` สำหรับการตรวจสอบวงกว้างที่หนักขึ้น ใช้ `large` หลังจาก standard/fast ไม่เพียงพอเท่านั้น และใช้ `beast` เฉพาะสำหรับเลนที่ผูกกับ CPU เป็นกรณีพิเศษ เช่น ชุดการทดสอบทั้งหมดหรือเมทริกซ์ Docker ของ Plugin ทั้งหมด การตรวจสอบ release/blocker ที่ระบุอย่างชัดเจน หรือการทำโปรไฟล์ประสิทธิภาพแบบหลายคอร์ ห้ามใช้ `beast` สำหรับ `pnpm check:changed`, การทดสอบแบบเจาะจง, งานเฉพาะเอกสาร, lint/typecheck ทั่วไป, การทำซ้ำ E2E ขนาดเล็ก หรือการไตร่สวนเหตุขัดข้องของ Blacksmith ใช้ `--market on-demand` สำหรับการวินิจฉัยความจุ เพื่อไม่ให้ความผันผวนของตลาด Spot ปะปนอยู่ในสัญญาณ

`.crabbox.yaml` เป็นเจ้าของค่าเริ่มต้นของผู้ให้บริการ การซิงค์ และการเติมข้อมูลผ่าน GitHub Actions การซิงค์ของ Crabbox จะไม่ถ่ายโอน `.git` ดังนั้น checkout ของ Actions ที่เติมข้อมูลแล้วจะเก็บข้อมูลเมตา Git ระยะไกลของตนเอง แทนที่จะซิงค์รีโมตและ object store ภายในเครื่องของผู้ดูแล และการกำหนดค่าของรีโพยังไม่รวมอาร์ติแฟกต์รันไทม์/build ภายในเครื่องเพิ่มเติม (เช่น `.artifacts` และรายงานการทดสอบ) ซึ่งไม่ควรถูกถ่ายโอนโดยเด็ดขาด `.github/workflows/crabbox-hydrate.yml` เป็นเจ้าของ checkout, การตั้งค่า Node/pnpm, การดึง `origin/main` และการส่งต่อสภาพแวดล้อมที่ไม่มีข้อมูลลับสำหรับคำสั่ง `crabbox run --id <cbx_id>` บนคลาวด์ที่เป็นเจ้าของ

## ที่เกี่ยวข้อง

- [ภาพรวมการติดตั้ง](/th/install)
- [ช่องทางการพัฒนา](/th/install/development-channels)
