---
read_when:
    - กำลังมองหาคำจำกัดความของช่องทางการเผยแพร่สาธารณะ
    - การรันการตรวจสอบความถูกต้องของรีลีสหรือการยอมรับแพ็กเกจ
    - กำลังมองหาหลักการตั้งชื่อเวอร์ชันและรอบการเผยแพร่
summary: ช่องทางการเผยแพร่ รายการตรวจสอบสำหรับผู้ปฏิบัติงาน กล่องตรวจสอบความถูกต้อง การตั้งชื่อเวอร์ชัน และรอบการเผยแพร่
title: นโยบายการเผยแพร่
x-i18n:
    generated_at: "2026-07-20T06:05:30Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 7807f44029f8f5fd0d40499c0b1f2e731cd99780cf1f081bf62230a2146c49e4
    source_path: reference/RELEASING.md
    workflow: 16
---

OpenClaw เปิดให้ผู้ใช้ใช้งานช่องทางอัปเดตสามช่องทางในปัจจุบัน:

- stable: ช่องทางรุ่นที่ได้รับการโปรโมตซึ่งมีอยู่เดิม และยังคงชี้ผ่าน npm `latest` จนกว่าหมุดหมาย CLI/ช่องทางแบบแยกส่วนจะพร้อมใช้งาน
- beta: แท็กรุ่นก่อนเผยแพร่ที่เผยแพร่ไปยัง npm `beta`
- dev: จุดล่าสุดที่เคลื่อนไหวของ `main`

นอกจากนี้ ผู้ดำเนินการเผยแพร่สามารถเผยแพร่แพ็กเกจหลักของเดือนล่าสุดที่สิ้นสุดแล้ว
ไปยัง npm `extended-stable` โดยเริ่มที่แพตช์ `33` ส่วนสายรุ่น final ปกติ
ของเดือนปัจจุบันยังคงอยู่บน npm `latest`; การแยกการเผยแพร่ในฝั่งผู้ดำเนินการนี้
ไม่ได้เปลี่ยนการเลือกช่องทางอัปเดตของ CLI ด้วยตัวมันเอง

บิลด์ alpha ของ Tideclaw เป็นสายรุ่นก่อนเผยแพร่ภายในที่แยกต่างหาก (npm dist-tag `alpha`) ซึ่งอธิบายไว้ใน [อินพุตเวิร์กโฟลว์ NPM](#npm-workflow-inputs) และ [กล่องทดสอบรุ่นเผยแพร่](#release-test-boxes)

## การตั้งชื่อเวอร์ชัน

- เวอร์ชันรุ่น extended-stable รายเดือนบน npm: `YYYY.M.PATCH` พร้อม `PATCH >= 33`, git tag `vYYYY.M.PATCH`
- เวอร์ชันรุ่น final รายวัน/ปกติ: `YYYY.M.PATCH` พร้อม `PATCH < 33`, git tag `vYYYY.M.PATCH`
- เวอร์ชันรุ่นแก้ไขสำรองแบบปกติ: `YYYY.M.PATCH-N`, git tag `vYYYY.M.PATCH-N`
- เวอร์ชันรุ่นก่อนเผยแพร่ beta: `YYYY.M.PATCH-beta.N`, git tag `vYYYY.M.PATCH-beta.N`
- เวอร์ชันรุ่นก่อนเผยแพร่ alpha: `YYYY.M.PATCH-alpha.N`, git tag `vYYYY.M.PATCH-alpha.N`
- ห้ามเติมเลขศูนย์นำหน้าเดือนหรือแพตช์
- `PATCH` คือหมายเลขสายการเผยแพร่รายเดือนแบบลำดับต่อเนื่อง ไม่ใช่วันตามปฏิทิน รุ่น final ปกติและรุ่น beta จะเลื่อนสายปัจจุบัน ส่วนแท็กเฉพาะ alpha จะไม่ใช้หรือเลื่อนหมายเลขแพตช์ของ beta/รุ่นปกติ ดังนั้นให้ข้ามแท็กเดิมที่มีเฉพาะ alpha และมีหมายเลขแพตช์สูงกว่าเมื่อเลือกสาย beta หรือสายปกติ
- บิลด์ alpha/nightly ใช้สายแพตช์ถัดไปที่ยังไม่เผยแพร่ และเพิ่มเฉพาะ `alpha.N` สำหรับบิลด์ซ้ำ เมื่อแพตช์นั้นมีรุ่น beta แล้ว บิลด์ alpha ใหม่จะย้ายไปยังแพตช์ถัดไป
- เวอร์ชัน npm เปลี่ยนแปลงไม่ได้: ห้ามลบ เผยแพร่ซ้ำ หรือนำแท็กที่เผยแพร่แล้วกลับมาใช้ใหม่ ให้สร้างหมายเลขรุ่นก่อนเผยแพร่ถัดไปหรือแพตช์รายเดือนถัดไปแทน
- `latest` ยังคงติดตามสาย npm ปกติ/รายวันในปัจจุบัน; `beta` คือเป้าหมายการติดตั้ง beta ปัจจุบัน
- `extended-stable` หมายถึงแพ็กเกจ npm ของเดือนล่าสุดที่รองรับ โดยเริ่มที่แพตช์ `33`; แพตช์ `34` และหลังจากนั้นคือรุ่นบำรุงรักษาบนสายรายเดือนนั้น
- รุ่น final ปกติและรุ่นแก้ไขปกติจะเผยแพร่ไปยัง npm `beta` โดยค่าเริ่มต้น; ผู้ดำเนินการเผยแพร่สามารถระบุเป้าหมาย `latest` อย่างชัดเจน หรือโปรโมตบิลด์ beta ที่ผ่านการตรวจสอบแล้วในภายหลัง
- เส้นทาง extended-stable รายเดือนโดยเฉพาะจะเผยแพร่แพ็กเกจหลักบน npm และ Plugin อย่างเป็นทางการทุกรายการที่เผยแพร่บน npm ได้ด้วยเวอร์ชันเดียวกันทุกประการ เส้นทางนี้จะไม่เผยแพร่ Plugin ไปยัง ClawHub หรือเผยแพร่อาร์ติแฟกต์ macOS หรือ Windows, GitHub Release, dist-tag ของที่เก็บส่วนตัว, อิมเมจ Docker, อาร์ติแฟกต์มือถือ หรือไฟล์ดาวน์โหลดบนเว็บไซต์
- รุ่น final ปกติทุกรุ่นจะจัดส่งแพ็กเกจ npm, แอป macOS, Android APK แบบสแตนด์อโลนที่ลงนามแล้ว และตัวติดตั้ง Windows Hub ที่ลงนามแล้วพร้อมกัน โดยปกติรุ่น beta จะตรวจสอบและเผยแพร่เส้นทาง npm/แพ็กเกจก่อน ส่วนการสร้าง/ลงนาม/รับรองเอกสาร/โปรโมตแอปเนทีฟจะสงวนไว้สำหรับรุ่น final ปกติ เว้นแต่จะมีการร้องขออย่างชัดเจน

## รอบการเผยแพร่

- การเผยแพร่จะเริ่มจาก beta ก่อน; stable จะตามมาหลังจากตรวจสอบ beta ล่าสุดแล้วเท่านั้น
- โดยปกติผู้ดูแลจะสร้างรุ่นเผยแพร่จากสาขา `release/YYYY.M.PATCH` ที่สร้างจาก `main` ปัจจุบัน เพื่อให้การตรวจสอบและแก้ไขรุ่นเผยแพร่ไม่ขัดขวางการพัฒนาใหม่บน `main`
- หากมีการพุชหรือเผยแพร่แท็ก beta แล้วและจำเป็นต้องแก้ไข ผู้ดูแลจะสร้างแท็ก `-beta.N` ถัดไป แทนการลบหรือสร้างแท็กเดิมใหม่
- ขั้นตอนการเผยแพร่ การอนุมัติ ข้อมูลประจำตัว และหมายเหตุการกู้คืนโดยละเอียดมีไว้สำหรับผู้ดูแลเท่านั้น

## การเผยแพร่ extended-stable รายเดือนเฉพาะ npm

นี่เป็นข้อยกเว้นเฉพาะจากขั้นตอนการเผยแพร่ปกติด้านล่าง สำหรับเดือน
ที่สิ้นสุดแล้ว `YYYY.M` ให้สร้าง `extended-stable/YYYY.M.33`; เผยแพร่
`vYYYY.M.33` และแพตช์บำรุงรักษาหลังจากนั้นจากสาขาเดียวกัน แท็ก
รุ่นเผยแพร่ ปลายสาขา เช็กเอาต์ เวอร์ชันแพ็กเกจ การตรวจสอบล่วงหน้าของ npm และการรัน Full Release
Validation ต้องระบุคอมมิตเดียวกันทั้งหมด `main` ที่ได้รับการป้องกันต้อง
มีเวอร์ชัน final ของเดือนตามปฏิทินที่ใหม่กว่าอย่างเคร่งครัดและต่ำกว่าแพตช์
`33` อยู่แล้ว; แพตช์บำรุงรักษายังคงมีสิทธิ์หลังจาก `main` เลื่อนไปมากกว่าหนึ่ง
เดือน

บนสาขา extended-stable ที่ตรงกันทุกประการ ให้เพิ่มเวอร์ชันแพ็กเกจรากเป็น `YYYY.M.P`, รัน
`pnpm release:prep` และตรวจสอบว่าแพ็กเกจส่วนขยายที่เผยแพร่ได้ทุกรายการใช้
เวอร์ชันเดียวกัน คอมมิตและพุชการเปลี่ยนแปลงที่สร้างขึ้นทั้งหมด สร้างและพุช
แท็ก `vYYYY.M.P` ที่เปลี่ยนแปลงไม่ได้ ณ คอมมิตนั้น และบันทึก SHA แบบเต็มที่ได้
เวิร์กโฟลว์จะใช้โครงสร้างที่เตรียมไว้นี้; เวิร์กโฟลว์จะไม่เพิ่มหรือซิงโครไนซ์
เวอร์ชันให้

รันการตรวจสอบล่วงหน้าของ npm และ Full Release Validation จากปลายสาขา
ที่เตรียมไว้ตรงกันทุกประการ จากนั้นบันทึก ID ของการรันทั้งสองรายการและครั้งที่รัน Full Release Validation
ซึ่งสำเร็จ:

```bash
gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=true \
  -f npm_dist_tag=extended-stable

gh workflow run full-release-validation.yml \
  --ref extended-stable/YYYY.M.33 \
  -f ref=extended-stable/YYYY.M.33 \
  -f release_profile=stable
```

`release_profile=stable` คือโปรไฟล์ความลึกในการตรวจสอบที่มีอยู่เดิม; โปรไฟล์นี้
แยกจาก dist-tag `extended-stable` ของ npm และตั้งใจให้
คงเดิม

หลังจากการรันทั้งสองสำเร็จ ให้เผยแพร่ Plugin อย่างเป็นทางการที่เผยแพร่บน npm ได้ทุกรายการจาก
ปลายสาขาเดียวกันทุกประการ แพตช์ `P` ต้องเป็น `33` หรือสูงกว่า ส่ง SHA ของรุ่นเผยแพร่
แบบเต็มเป็น `ref` รอให้เมทริกซ์ทั้งหมดและการอ่านกลับจากรีจิสทรีเสร็จสมบูรณ์ จากนั้นบันทึก
ID การรัน Plugin NPM Release ที่สำเร็จ:

```bash
RELEASE_SHA="$(git rev-parse HEAD)"
gh workflow run plugin-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f publish_scope=all-publishable \
  -f ref="$RELEASE_SHA" \
  -f npm_dist_tag=extended-stable
```

เวิร์กโฟลว์ใช้รายการแพ็กเกจ `all-publishable` ที่เตรียมไว้ตามปกติ
รวมถึงแพ็กเกจที่ซอร์สไม่ได้เปลี่ยนแปลง เวิร์กโฟลว์จะตรวจสอบแพ็กเกจทุกแพ็กเกจ
และแท็ก `extended-stable` ของ Plugin ทุกรายการให้ตรงกันทุกประการก่อนสำเร็จ หากการรันบางส่วน
ล้มเหลว ให้รันคำสั่งเดิมอีกครั้ง: แพ็กเกจที่เผยแพร่แล้วจะถูกนำกลับมาใช้ แท็ก Plugin
ที่ขาดหายหรือล้าสมัยจะได้รับการปรับให้สอดคล้องภายใต้สภาพแวดล้อมการเผยแพร่ npm และ
การอ่านกลับขั้นสุดท้ายยังคงครอบคลุมชุดแพ็กเกจทั้งหมด

หลังจากเวิร์กโฟลว์ Plugin สำเร็จและสภาพแวดล้อมการเผยแพร่ npm พร้อมแล้ว
ให้เผยแพร่ tarball หลักจากการตรวจสอบล่วงหน้าที่ตรงกันทุกประการ การเผยแพร่ส่วนหลักจะตรวจสอบว่า
การรัน Plugin ที่อ้างอิงมีสถานะ `completed/success` บนสาขามาตรฐานเดียวกันและ
มี SHA ของซอร์สตรงกันทุกประการ:

```bash
gh workflow run openclaw-npm-release.yml \
  --ref extended-stable/YYYY.M.33 \
  -f tag=vYYYY.M.P \
  -f preflight_only=false \
  -f npm_dist_tag=extended-stable \
  -f preflight_run_id=<npm-preflight-run-id> \
  -f full_release_validation_run_id=<full-validation-run-id> \
  -f full_release_validation_run_attempt=<full-validation-run-attempt> \
  -f plugin_npm_run_id=<plugin-npm-run-id>
```

สำหรับฟอร์กหรือการซ้อมในสภาพแวดล้อมที่ไม่ใช่ระบบจริงซึ่งตั้งใจว่าไม่สามารถปฏิบัติตาม
นโยบายเดือนของ `.33` หรือ `main` ที่ได้รับการป้องกันได้ ให้เพิ่ม
`-f bypass_extended_stable_guard=true` ทั้งในการส่งคำสั่งตรวจสอบล่วงหน้าและเผยแพร่
ของ npm ค่าเริ่มต้นคือ `false` การข้ามจะได้รับการยอมรับเฉพาะเมื่อใช้
`npm_dist_tag=extended-stable` และจะถูกบันทึกในสรุปเวิร์กโฟลว์ การข้ามนี้
ไม่ข้าม ref เวิร์กโฟลว์ `extended-stable/YYYY.M.33` มาตรฐาน
ความเท่ากันของปลายสาขา/แท็ก/เช็กเอาต์ ไวยากรณ์แท็ก final ความเท่ากันของเวอร์ชัน
แพ็กเกจ/แท็ก อัตลักษณ์ของการรันและแมนิเฟสต์ที่อ้างอิง ที่มาของ tarball
การอนุมัติสภาพแวดล้อม การอ่านกลับจากรีจิสทรี หรือหลักฐานการซ่อมแซมตัวเลือก

เวิร์กโฟลว์เผยแพร่จะตรวจสอบอัตลักษณ์ของการตรวจสอบล่วงหน้า การตรวจสอบ และการรัน Plugin
ที่อ้างอิง ไดเจสต์ของ tarball ที่เตรียมไว้ และตัวเลือกรีจิสทรีของส่วนหลัก
ให้ยืนยันผลลัพธ์โดยอิสระหลังจากเวิร์กโฟลว์สำเร็จ:

```bash
npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"
npm view openclaw@extended-stable version --userconfig "$(mktemp)"
```

คำสั่งทั้งสองต้องคืนค่า `YYYY.M.P` หากการเผยแพร่สำเร็จแต่การอ่านกลับตัวเลือก
ล้มเหลว ห้ามเผยแพร่เวอร์ชันแพ็กเกจที่เปลี่ยนแปลงไม่ได้ซ้ำ ให้ใช้
คำสั่งซ่อมแซม `npm dist-tag add openclaw@YYYY.M.P extended-stable` เพียงคำสั่งเดียว
ที่พิมพ์ในสรุปแบบรันเสมอของเวิร์กโฟลว์ที่ล้มเหลว จากนั้นทำการอ่านกลับอิสระทั้งสองรายการ
อีกครั้ง การย้อนกลับไปยังตัวเลือกก่อนหน้าเป็นการตัดสินใจของผู้ดำเนินการที่แยกต่างหาก
ไม่ใช่เส้นทางซ่อมแซมการอ่านกลับ

เอกสารการสนับสนุนสาธารณะระบุ Slack, Discord และ Codex เป็น
พื้นผิว Plugin แบบ extended-stable ที่ครอบคลุมในช่วงแรก รายการดังกล่าวเป็นคำประกาศการสนับสนุน ไม่ใช่
รายการอนุญาตของโค้ดการเผยแพร่: Plugin อย่างเป็นทางการที่เผยแพร่บน npm ได้ทุกรายการจะใช้
เส้นทางการเผยแพร่ด้วยเวอร์ชันเดียวกันทุกประการ

รายการตรวจสอบปกติด้านล่างยังคงครอบคลุม beta, `latest`, GitHub Release,
Plugin, macOS, Windows และการเผยแพร่แพลตฟอร์มอื่น ๆ ห้ามรัน
ขั้นตอนเหล่านั้นสำหรับเส้นทาง extended-stable เฉพาะ npm นี้

## รายการตรวจสอบสำหรับผู้ดำเนินการเผยแพร่แบบปกติ

รายการตรวจสอบนี้แสดงรูปแบบสาธารณะของขั้นตอนการเผยแพร่ ข้อมูลประจำตัวส่วนตัว การลงนาม การรับรองเอกสาร การกู้คืน dist-tag และรายละเอียดการย้อนกลับฉุกเฉินจะอยู่ในคู่มือการเผยแพร่สำหรับผู้ดูแลเท่านั้น

1. เริ่มจาก `main` ปัจจุบัน: ดึงข้อมูลล่าสุด ยืนยันว่าคอมมิตเป้าหมายถูกพุชแล้ว และยืนยันว่าไปป์ไลน์ CI ของ `main` ผ่านมากพอที่จะสร้างสาขาได้
2. สร้าง `release/YYYY.M.PATCH` จากคอมมิตนั้น การแบ็กพอร์ตเป็นทางเลือก; ใช้เฉพาะชุดที่ผู้ดำเนินการเลือก เพิ่มเวอร์ชันในทุกตำแหน่งที่กำหนด รัน `pnpm release:prep` ดำเนินการแก้ไขรุ่นเผยแพร่และฟอร์เวิร์ดพอร์ตที่จำเป็นให้เสร็จสิ้น และตรวจสอบ `src/plugins/compat/registry.ts` รวมถึง `src/commands/doctor/shared/deprecation-compat.ts`
3. ตรึงคอมมิตก่อนบันทึกการเปลี่ยนแปลงที่ผลิตภัณฑ์เสร็จสมบูรณ์เป็น **Code SHA** รันการตรวจสอบล่วงหน้าของซอร์สแบบกำหนดผลลัพธ์แน่นอน จากนั้นใช้ `node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH` ขั้นตอนนี้จะตรึงเครื่องมือเวิร์กโฟลว์ที่เชื่อถือได้ ขณะที่เมทริกซ์ Vitest, Docker, QA, แพ็กเกจ และประสิทธิภาพฉบับเต็มกำหนดเป้าหมายไปยัง Code SHA ที่ตรงกันทุกประการ
4. จำแนกความล้มเหลวก่อนแก้ไข ความล้มเหลวของผลิตภัณฑ์/โค้ดจะสร้าง Code SHA ใหม่และกำหนดให้มีการตรวจสอบฉบับเต็มที่ผ่านสำหรับ SHA นั้น ความล้มเหลวของเวิร์กโฟลว์ ชุดทดสอบ ข้อมูลประจำตัว การอนุมัติ หรือโครงสร้างพื้นฐานจะได้รับการซ่อมแซมในพื้นผิวที่เป็นเจ้าของและรันใหม่กับ Code SHA เดิม
5. หลังจาก Code SHA ผ่านแล้วเท่านั้น ให้สร้างส่วนบนสุดของ `CHANGELOG.md` จาก pull request ที่ผสานแล้วและคอมมิตโดยตรงนับจากแท็กรุ่นที่จัดส่งแล้วล่าสุดซึ่งเข้าถึงได้ ทำให้รายการมุ่งเน้นผู้ใช้และไม่ซ้ำกัน เมื่อแท็กรุ่นที่จัดส่งแล้วซึ่งแยกสายออกไปหรือฟอร์เวิร์ดพอร์ตในภายหลังเชื่อมโยง pull request ที่เผยแพร่แล้วใหม่อีกครั้ง ให้ส่งแท็กนั้นอย่างชัดเจนเป็น `--shipped-ref`
6. คอมมิตเฉพาะ `CHANGELOG.md` คอมมิตนี้คือ **Release SHA** diff ทั้งหมดจาก Code SHA ถึง Release SHA ต้องเป็น `CHANGELOG.md` เท่านั้น; เส้นทางอื่นที่เปลี่ยนแปลงจะทำให้การเผยแพร่ย้อนกลับไปยังขั้นตอนที่ 2
7. รัน Full Release Validation แบบตรึง SHA สำหรับ Release SHA โดยเปิดใช้การนำหลักฐานกลับมาใช้ โพรเซสหลักแบบเบาต้องบันทึก `changelog-only-release-v1` ชี้ไปยัง Code SHA ที่ผ่าน และไม่ส่งเลนย่อยของผลิตภัณฑ์ใด ๆ ขั้นตอนนี้นำหลักฐานผลิตภัณฑ์กลับมาใช้; ไม่ได้นำไบต์ของแพ็กเกจกลับมาใช้
8. รัน `OpenClaw NPM Release` พร้อม `preflight_only=true` กับ Release SHA/แท็ก บันทึก `preflight_run_id` ที่สำเร็จ ขั้นตอนนี้จะสร้างและตรวจสอบไบต์แพ็กเกจที่ตรงกันทุกประการซึ่งรวมบันทึกการเปลี่ยนแปลงฉบับสุดท้าย
9. แท็ก Release SHA จากนั้นรันตัวช่วยสำหรับรุ่นที่พร้อมเสนอด้วยโพรเซสหลักการตรวจสอบ Release-SHA ที่สำเร็จและการตรวจสอบล่วงหน้าของ npm แทนการส่งทั้งสองรายการอีกครั้ง:

   ```bash
   pnpm release:candidate -- \
     --tag vYYYY.M.PATCH-beta.N \
     --full-release-run <release-sha-validation-run-id> \
     --npm-preflight-run <preflight-run-id> \
     --skip-dispatch
   ```

   สำหรับรุ่นเสถียร ให้ส่ง `--windows-node-tag vX.Y.Z` ด้วย ตัวช่วยจะตรวจสอบแหล่งที่มาของบันทึกประจำรุ่น ไบต์พรีไฟลต์ของ npm หลักฐานการติดตั้ง/อัปเดต Parallels หลักฐานแพ็กเกจ Telegram และแผนการเผยแพร่ plugin จากนั้นจะแสดงคำสั่งเผยแพร่

   `OpenClaw Release Publish` จะส่งแพ็กเกจ plugin ที่เลือกหรือแพ็กเกจ plugin ทั้งหมดที่เผยแพร่ได้ไปยัง npm และส่งชุดเดียวกันไปยัง ClawHub แบบขนาน จากนั้นโปรโมตอาร์ติแฟกต์พรีไฟลต์ npm ของ OpenClaw ที่เตรียมไว้ด้วย dist-tag ที่ตรงกันเมื่อเผยแพร่ plugin ไปยัง npm สำเร็จ เช็กเอาต์รุ่นยังคงเป็นรูทของผลิตภัณฑ์/ข้อมูล ขณะที่การวางแผนและการตรวจสอบขั้นสุดท้ายจะดำเนินการจากเช็กเอาต์แหล่งที่มาของเวิร์กโฟลว์ที่เชื่อถือได้ซึ่งตรงกันทุกประการ เพื่อไม่ให้คอมมิตรุ่นเก่าใช้เครื่องมือออกรุ่นที่ล้าสมัยโดยไม่มีการแจ้งเตือน ก่อนเริ่มโปรเซสย่อยสำหรับเผยแพร่ใด ๆ ระบบจะเรนเดอร์และแคชเนื้อหาของ GitHub release ที่ตรงกันทุกประการ เมื่อส่วน `CHANGELOG.md` ที่ตรงกันทั้งหมดอยู่ภายในขีดจำกัด 125,000 อักขระของ GitHub และเพดานความปลอดภัย 125,000 ไบต์ที่ตรงกันของตัวเรนเดอร์ หน้าเว็บจะมีส่วน `## YYYY.M.PATCH` นั้นแบบตรงกันทุกประการ รวมถึงหัวข้อของส่วนนั้นด้วย เมื่อส่วนต้นฉบับมีขนาดเกินกำหนด หน้าเว็บจะคงบันทึกบรรณาธิการที่จัดกลุ่มไว้อย่างตรงกันทุกประการ และแทนที่บันทึกการมีส่วนร่วมที่มีขนาดใหญ่เกินไปด้วยลิงก์ถาวรไปยังบันทึกฉบับเต็มใน `CHANGELOG.md` ที่ตรึงกับแท็ก โดยจะไม่เผยแพร่บันทึกบางส่วนหรือหัวข้อย่อยที่ถูกตัดทอน เวิร์กโฟลว์จะเลือกเนื้อหาแบบเต็มหรือแบบย่อก่อนเพิ่ม `### Release verification`; หากส่วนท้ายของหลักฐานทำให้เกินขีดจำกัด ระบบจะคงเนื้อหามาตรฐานไว้และอาศัยหลักฐานแนบที่เปลี่ยนแปลงไม่ได้แทน รุ่นเสถียรที่เผยแพร่ไปยัง npm `latest` จะกลายเป็น GitHub release ล่าสุด ส่วนรุ่นบำรุงรักษาเสถียรที่คงไว้บน npm `beta` จะถูกสร้างด้วย GitHub `latest=false` นอกจากนี้ เวิร์กโฟลว์ยังอัปโหลดหลักฐานการขึ้นต่อกันจากพรีไฟลต์ แมนิเฟสต์การตรวจสอบแบบเต็ม และหลักฐานการตรวจสอบรีจิสทรีหลังเผยแพร่ไปยัง GitHub release เพื่อใช้ตอบสนองต่อเหตุขัดข้องหลังออกรุ่น ระบบจะแสดง ID ของรันย่อยทันที อนุมัติเกตสภาพแวดล้อมการออกรุ่นที่โทเค็นเวิร์กโฟลว์ได้รับอนุญาตให้อนุมัติโดยอัตโนมัติ สรุปงานย่อยที่ล้มเหลวพร้อมส่วนท้ายของล็อก สร้างหน้า GitHub release แบบฉบับร่างไว้ล่วงหน้า และโปรโมตแอสเซ็ต Windows และ Android พร้อมกับการเผยแพร่ OpenClaw ไปยัง npm ปิดงานหน้า release และหลักฐานการขึ้นต่อกันเมื่อขั้นตอนเหล่านั้นสำเร็จ รอ ClawHub ทุกครั้งที่กำลังเผยแพร่ OpenClaw ไปยัง npm จากนั้นเรียกใช้ตัวตรวจสอบเบตาจาก main ที่เชื่อถือได้ และอัปโหลดหลักฐานหลังเผยแพร่สำหรับ GitHub release, แพ็กเกจ npm, แพ็กเกจ plugin บน npm ที่เลือก, แพ็กเกจ ClawHub ที่เลือก, ID รันของเวิร์กโฟลว์ย่อย และ ID รัน NPM Telegram ซึ่งเป็นทางเลือก ตัวตรวจสอบบูตสแตรป ClawHub ต้องการพาธและ SHA ของเวิร์กโฟลว์จาก main ที่เชื่อถือได้แบบตรงกันทุกประการ ความพยายามรันของผู้สร้างและรันปลายทาง SHA ของรุ่น ชุดแพ็กเกจที่ร้องขอ ทูเพิลอาร์ติแฟกต์แพ็กเกจที่เปลี่ยนแปลงไม่ได้ และอาร์ติแฟกต์การอ่านค่ากลับจากรีจิสทรีปลายทาง โดยจะไม่ยอมรับรันอ้างอิงรุ่นแบบเดิมที่สำเร็จ

   จากนั้นเรียกใช้การทดสอบยอมรับแพ็กเกจหลังเผยแพร่กับแพ็กเกจ `openclaw@YYYY.M.PATCH-beta.N` หรือ `openclaw@beta` ที่เผยแพร่แล้ว หากรุ่นก่อนเผยแพร่ที่พุชหรือเผยแพร่แล้วต้องแก้ไข ให้สร้างหมายเลขรุ่นก่อนเผยแพร่ลำดับถัดไปที่ตรงกัน ห้ามลบหรือเขียนทับรุ่นเก่า

10. เมื่อความพยายามเผยแพร่ล้มเหลว ให้คง Release SHA ไว้โดยไม่เปลี่ยนแปลง เว้นแต่ความล้มเหลวจะพิสูจน์ว่าผลิตภัณฑ์หรือบันทึกการเปลี่ยนแปลงมีข้อบกพร่อง ให้ดำเนินการต่อจากโปรเซสย่อยและอาร์ติแฟกต์ที่เปลี่ยนแปลงไม่ได้ซึ่งสำเร็จแล้ว ห้ามสร้างใหม่หรือเผยแพร่ซ้ำแพ็กเกจเวอร์ชันที่สำเร็จแล้ว
11. สำหรับรุ่นเสถียร ให้ดำเนินการต่อเฉพาะเมื่อเบตาหรือรุ่นทดสอบก่อนออกรุ่นที่ผ่านการตรวจสอบแล้วมีหลักฐานการตรวจสอบที่จำเป็น การเผยแพร่รุ่นเสถียรไปยัง npm จะผ่าน `OpenClaw Release Publish` เช่นกัน โดยนำอาร์ติแฟกต์พรีไฟลต์ที่สำเร็จแล้วกลับมาใช้ผ่าน `preflight_run_id` ความพร้อมสำหรับการออกรุ่นเสถียรบน macOS ยังต้องมี `.zip`, `.dmg`, `.dSYM.zip` ที่จัดแพ็กเกจแล้ว และ `appcast.xml` ที่อัปเดตแล้วบน `main`; เวิร์กโฟลว์เผยแพร่ macOS จะเผยแพร่ appcast ที่ลงนามแล้วไปยัง `main` สาธารณะโดยอัตโนมัติหลังตรวจสอบแอสเซ็ตของรุ่น หรือเปิด/อัปเดต PR สำหรับ appcast หากการป้องกันสาขาปิดกั้นการพุชโดยตรง ความพร้อมของ Windows Hub รุ่นเสถียรต้องมีแอสเซ็ต `OpenClawCompanion-Setup-x64.exe`, `OpenClawCompanion-Setup-arm64.exe` และ `OpenClawCompanion-SHA256SUMS.txt` ที่ลงนามแล้วบน GitHub release ของ OpenClaw ส่งแท็กออกรุ่น `openclaw/openclaw-windows-node` ที่ลงนามแล้วแบบตรงกันทุกประการเป็น `windows_node_tag` และส่งแผนที่ไดเจสต์ของตัวติดตั้งที่ผู้สมัครอนุมัติแล้วเป็น `windows_node_installer_digests`; `OpenClaw Release Publish` จะคงฉบับร่างของรุ่นไว้ ส่ง `Windows Node Release` และตรวจสอบแอสเซ็ตทั้งสามก่อนเผยแพร่
12. หลังเผยแพร่ ให้เรียกใช้ตัวตรวจสอบหลังเผยแพร่ของ npm, E2E Telegram แบบสแตนด์อโลนบน npm ที่เผยแพร่แล้วซึ่งเป็นทางเลือกเมื่อจำเป็นต้องมีหลักฐานช่องทางหลังเผยแพร่, การโปรโมต dist-tag เมื่อจำเป็น, ตรวจสอบหน้า GitHub release ที่สร้างขึ้น, ดำเนินขั้นตอนประกาศออกรุ่น แล้วจึงทำ [การปิดงาน main สำหรับรุ่นเสถียร](#stable-main-closeout) ให้เสร็จสิ้นก่อนถือว่าการออกรุ่นเสถียรเสร็จสมบูรณ์

## การปิดงาน main สำหรับรุ่นเสถียร

การเผยแพร่รุ่นเสถียรยังไม่เสร็จสมบูรณ์จนกว่า `main` จะมีสถานะรุ่นที่เผยแพร่จริง

1. เริ่มจาก `main` ล่าสุดที่สดใหม่ ตรวจสอบ `release/YYYY.M.PATCH` เทียบกับรายการดังกล่าว และพอร์ตการแก้ไขจริงที่ไม่มีใน `main` ไปข้างหน้า อย่าผสานตัวปรับความเข้ากันได้ การทดสอบ หรือตัวปรับการตรวจสอบที่มีเฉพาะรุ่นเข้าไปใน `main` ที่ใหม่กว่าโดยไม่พิจารณา
2. สำหรับเส้นทางปกติ ให้ตั้ง `main` เป็นเวอร์ชันเสถียรที่เผยแพร่แล้ว การปิดงานล่าช้าอาจใช้ `main` หลังจากที่รายการดังกล่าวเลื่อนไปยัง OpenClaw CalVer รุ่นเสถียรที่ใหม่กว่าแล้ว ห้ามดาวน์เกรดขบวนการออกรุ่นที่เริ่มไปแล้วเพียงเพื่อปิดรุ่นก่อนหน้า ตัวตรวจสอบยังคงกำหนดให้มีส่วนบันทึกการเปลี่ยนแปลงและรายการ appcast ของรุ่นที่เผยแพร่แบบตรงกันทุกประการ และบันทึกเวอร์ชันกับ SHA ของ `main` ที่ใช้งานจริง เรียกใช้ `pnpm release:prep` หลังการเปลี่ยนเวอร์ชันรูททุกครั้ง จากนั้นเรียกใช้ `pnpm deps:shrinkwrap:generate`
3. ทำให้ส่วน `## YYYY.M.PATCH` ของ `CHANGELOG.md` บน `main` ตรงกับสาขารุ่นที่ติดแท็กทุกประการ รวมการอัปเดต `appcast.xml` รุ่นเสถียรเมื่อรุ่น Mac เผยแพร่รายการดังกล่าว
4. ห้ามเพิ่ม `YYYY.M.PATCH+1`, เวอร์ชันเบตา หรือส่วนบันทึกการเปลี่ยนแปลงในอนาคตที่ว่างเปล่าลงใน `main` จนกว่าผู้ดำเนินการจะเริ่มขบวนการออกรุ่นนั้นอย่างชัดเจน
5. เรียกใช้ `pnpm release:generated:check`, `pnpm deps:shrinkwrap:check` และ `OPENCLAW_TESTBOX=1 pnpm check:changed` พุช แล้วตรวจสอบว่า `origin/main` มีเวอร์ชันและบันทึกการเปลี่ยนแปลงที่เผยแพร่แล้ว ก่อนถือว่าการออกรุ่นเสถียรเสร็จสิ้น
6. อัปเดตตัวแปรที่เก็บ `RELEASE_ROLLBACK_DRILL_ID` และ `RELEASE_ROLLBACK_DRILL_DATE` ให้เป็นปัจจุบันหลังการซ้อมย้อนกลับแบบส่วนตัวแต่ละครั้ง

`OpenClaw Stable Main Closeout` เริ่มจากการพุช `main` ที่มีเวอร์ชัน บันทึกการเปลี่ยนแปลง และ appcast ที่เผยแพร่แล้วหลังการเผยแพร่รุ่นเสถียร โดยจะอ่านหลักฐานหลังเผยแพร่ที่เปลี่ยนแปลงไม่ได้เพื่อผูกแท็กที่เผยแพร่กับรันการตรวจสอบรุ่นเต็มและการเผยแพร่ จากนั้นตรวจสอบสถานะ main รุ่นเสถียร รุ่น การทดสอบเฝ้าดูรุ่นเสถียรที่บังคับใช้ และหลักฐานประสิทธิภาพที่เป็นตัวบล็อก ระบบจะแนบแมนิเฟสต์การปิดงานและผลรวมตรวจสอบที่เปลี่ยนแปลงไม่ได้กับ GitHub release ทริกเกอร์การพุชอัตโนมัติจะข้ามรุ่นเดิมที่มีมาก่อนหลักฐานหลังเผยแพร่แบบเปลี่ยนแปลงไม่ได้ และจะไม่ถือว่าการข้ามนั้นเป็นการปิดงานที่เสร็จสมบูรณ์

การปิดงานที่สมบูรณ์ต้องมีทั้งสองแอสเซ็ตและผลรวมตรวจสอบที่ตรงกัน แมนิเฟสต์บางส่วนจะเล่นซ้ำ SHA ของ `main` และการซ้อมย้อนกลับที่บันทึกไว้เพื่อสร้างไบต์ที่เหมือนเดิม จากนั้นแนบผลรวมตรวจสอบที่ขาดหายไป คู่ที่ไม่ถูกต้องหรือผลรวมตรวจสอบที่ไม่มีแมนิเฟสต์จะยังคงเป็นตัวบล็อก รันที่ทริกเกอร์ด้วยการพุชโดยไม่มีตัวแปรที่เก็บสำหรับการซ้อมย้อนกลับจะข้ามโดยไม่ทำการปิดงานให้เสร็จสมบูรณ์ ส่วนบันทึกการซ้อมที่ไม่มีหรือเก่ากว่า 90 วันจะยังคงบล็อกการปิดงานแบบกำหนดเองที่มีหลักฐานรองรับ คำสั่งกู้คืนแบบส่วนตัวยังคงอยู่ในคู่มือปฏิบัติสำหรับผู้ดูแลเท่านั้น ใช้การส่งแบบกำหนดเองเฉพาะเพื่อซ่อมแซมหรือเล่นซ้ำการปิดงานรุ่นเสถียรที่มีหลักฐานรองรับ

หากพาเรนต์ Release Publish ล้มเหลวเฉพาะหลังจากแนบหลักฐาน npm/plugin ที่เปลี่ยนแปลงไม่ได้แล้ว ให้ซ่อมแซมและเผยแพร่แอสเซ็ตแพลตฟอร์มรุ่นเสถียรทุกประเภทก่อน จากนั้นผู้ดูแลอาจส่งการปิดงานด้วยตนเองโดยใช้ `allow_failed_publish_recovery=true`; โหมดดังกล่าวยอมรับเฉพาะพาเรนต์ที่ล้มเหลวและเสร็จสิ้นแล้ว และยังต้องมีสัญญาแอสเซ็ต Android และ Windows แบบตรงกันทุกประการ ไดเจสต์ SHA-256 ของ GitHub การตรวจสอบผลรวมตรวจสอบ แหล่งที่มาของ Android และการโปรโมต Windows ที่พาเรนต์ส่งและสำเร็จ ซึ่งการตรวจสอบ Authenticode และไดเจสต์ที่ผู้สมัครอนุมัติตรงกับตัวติดตั้งที่เผยแพร่ ควบคู่กับการตรวจสอบ macOS/appcast ตามปกติ การปิดงานอัตโนมัติจากการพุชจะไม่เปิดใช้โหมดกู้คืนนี้

แท็กแก้ไขสำรองแบบเดิมอาจนำหลักฐานของแพ็กเกจฐานกลับมาใช้ได้เฉพาะเมื่อแท็กแก้ไขชี้ไปยังคอมมิตต้นฉบับเดียวกับแท็กเสถียรฐาน รุ่น Android ของแท็กดังกล่าวจะนำ APK ที่ตรวจสอบแล้วของแท็กฐานกลับมาใช้และเพิ่มแหล่งที่มาสำหรับแท็กแก้ไข การแก้ไขที่มีต้นฉบับต่างกันต้องเผยแพร่และตรวจสอบหลักฐานแพ็กเกจของตนเอง และใช้ Android `versionCode` ที่สูงกว่า

## พรีไฟลต์การออกรุ่น

- เรียกใช้ `pnpm check:test-types` ก่อนพรีไฟลต์การออกรุ่น เพื่อให้ TypeScript สำหรับการทดสอบยังได้รับการครอบคลุมนอกเกต `pnpm check` ภายในเครื่องที่รวดเร็วกว่า
- เรียกใช้ `pnpm check:architecture` ก่อนพรีไฟลต์การออกรุ่น เพื่อให้การตรวจสอบวงจรการนำเข้าและขอบเขตสถาปัตยกรรมที่กว้างขึ้นผ่านทั้งหมดนอกเกตภายในเครื่องที่รวดเร็วกว่า
- เรียกใช้ `pnpm build && pnpm ui:build` ก่อน `pnpm release:check` เพื่อให้อาร์ติแฟกต์รุ่น `dist/*` ที่คาดไว้และบันเดิล Control UI มีอยู่สำหรับขั้นตอนตรวจสอบแพ็ก
- เรียกใช้ `pnpm release:prep` หลังเพิ่มเวอร์ชันรูทและก่อนติดแท็ก โดยจะเรียกใช้ตัวสร้างรุ่นแบบกำหนดแน่นอนทุกตัวที่มักคลาดเคลื่อนหลังการเปลี่ยนเวอร์ชัน/การกำหนดค่า/API ได้แก่ เวอร์ชัน plugin, shrinkwrap ของ npm, บัญชีรายการ plugin, สคีมาการกำหนดค่าพื้นฐาน, ข้อมูลเมตาการกำหนดค่าช่องทางที่รวมมาให้, เส้นฐานเอกสารการกำหนดค่า, การส่งออก SDK ของ plugin, แมนิเฟสต์สัญญา API ของ SDK สำหรับ Plugin และบันเดิลภาษาของ Control UI นอกจากนี้ยังบล็อกจนกว่าคำแปลแอปเนทีฟและทรัพยากรภาษาที่แพลตฟอร์มสร้างจะตรงกับบัญชีรายการต้นฉบับ หากล่าช้า ให้รอหรือส่ง `Native App Locale Refresh` ก่อนตรึง Code SHA `pnpm release:check` จะเรียกใช้ตัวป้องกันเหล่านั้นอีกครั้งในโหมดตรวจสอบ (รวมถึงเกตภาษาที่เข้มงวดและงบประมาณพื้นผิว SDK ของ plugin) และรายงานความล้มเหลวจากการคลาดเคลื่อนของสิ่งที่สร้างขึ้นทั้งหมดในครั้งเดียวก่อนเรียกใช้การตรวจสอบการออกรุ่นแพ็กเกจ
- การซิงค์เวอร์ชัน plugin จะอัปเดตแพ็กเกจรันไทม์ `@openclaw/ai` ที่เผยแพร่ได้ เวอร์ชันแพ็กเกจ plugin อย่างเป็นทางการ และค่าขั้นต่ำ `openclaw.compat.pluginApi` ที่มีอยู่ให้เป็นเวอร์ชันรุ่นของ OpenClaw โดยค่าเริ่มต้น ให้ถือว่าฟิลด์ดังกล่าวเป็นค่าขั้นต่ำของ API สำหรับ SDK/รันไทม์ของ plugin ไม่ใช่เพียงสำเนาเวอร์ชันแพ็กเกจ สำหรับรุ่นเฉพาะ plugin ที่ตั้งใจให้ยังเข้ากันได้กับโฮสต์ OpenClaw รุ่นเก่า ให้คงค่าขั้นต่ำไว้ที่ API โฮสต์รุ่นเก่าสุดที่รองรับ และบันทึกตัวเลือกนั้นไว้ในหลักฐานการออกรุ่น plugin
- เรียกใช้เวิร์กโฟลว์ `Full Release Validation` แบบกำหนดเองก่อนอนุมัติการออกรุ่น เพื่อเริ่มกล่องทดสอบก่อนออกรุ่นทั้งหมดจากจุดเริ่มต้นเดียว เวิร์กโฟลว์นี้รับสาขา แท็ก หรือ SHA ของคอมมิตแบบเต็ม ส่ง `CI` แบบกำหนดเอง และส่ง `OpenClaw Release Checks` สำหรับการทดสอบติดตั้งเบื้องต้น การยอมรับแพ็กเกจ การตรวจสอบแพ็กเกจข้ามระบบปฏิบัติการ ความสอดคล้องของ QA Lab, Matrix และเลน Telegram รันเสถียรและรันเต็มจะรวมการทดสอบเฝ้าดูเส้นทางการออกรุ่นแบบ live/E2E และ Docker อย่างละเอียดเสมอ โดยเก็บ `run_release_soak=true` ไว้สำหรับการทดสอบเฝ้าดูเบตาโดยชัดเจน การยอมรับแพ็กเกจมี E2E Telegram สำหรับแพ็กเกจที่เป็นมาตรฐานระหว่างการตรวจสอบผู้สมัคร จึงหลีกเลี่ยงตัวโพลแบบ live ตัวที่สองซึ่งทำงานพร้อมกัน

  ระบุ `release_package_spec` หลังเผยแพร่เบตาเพื่อนำแพ็กเกจ npm ที่เผยแพร่แล้วกลับมาใช้ในการตรวจสอบรุ่น การยอมรับแพ็กเกจ และ E2E Telegram สำหรับแพ็กเกจ โดยไม่สร้างทาร์บอลล์รุ่นใหม่ ระบุ `npm_telegram_package_spec` เฉพาะเมื่อ Telegram ควรใช้แพ็กเกจที่เผยแพร่ซึ่งต่างจากส่วนอื่นของการตรวจสอบรุ่น ระบุ `package_acceptance_package_spec` เมื่อการยอมรับแพ็กเกจควรใช้แพ็กเกจที่เผยแพร่ซึ่งต่างจากข้อกำหนดแพ็กเกจรุ่น ระบุ `evidence_package_spec` เมื่อรายงานหลักฐานรุ่นควรพิสูจน์ว่าการตรวจสอบตรงกับแพ็กเกจ npm ที่เผยแพร่ โดยไม่บังคับใช้ E2E Telegram

  ```bash
  node scripts/full-release-validation-at-sha.mjs \
    --sha <code-sha> \
    --target-ref release/YYYY.M.PATCH
  ```

- เรียกใช้เวิร์กโฟลว์ `Package Acceptance` แบบแมนนวลเมื่อต้องการหลักฐานจากช่องทางเสริมสำหรับแพ็กเกจที่เป็นตัวเลือก ระหว่างที่งานรีลีสดำเนินต่อไป ใช้ `source=npm` สำหรับ `openclaw@beta`, `openclaw@latest` หรือเวอร์ชันรีลีสที่ระบุแน่นอน; ใช้ `source=ref` เพื่อแพ็ก branch/tag/SHA ของ `package_ref` ที่เชื่อถือได้ด้วยชุดทดสอบ `workflow_ref` ปัจจุบัน; ใช้ `source=url` สำหรับ tarball HTTPS สาธารณะที่ต้องระบุ SHA-256 และใช้นโยบาย URL สาธารณะที่เข้มงวด; ใช้ `source=trusted-url` สำหรับนโยบายแหล่งที่เชื่อถือได้ที่มีชื่อ โดยต้องใช้ `trusted_source_id` และ SHA-256; หรือใช้ `source=artifact` สำหรับ tarball ที่อัปโหลดโดยการรัน GitHub Actions อื่น

  เวิร์กโฟลว์จะแปลงตัวเลือกเป็น `package-under-test` นำตัวจัดกำหนดการรีลีส Docker E2E มาใช้ซ้ำกับ tarball นั้น และสามารถเรียกใช้ QA ของ Telegram กับ tarball เดียวกันโดยใช้ `telegram_mode=mock-openai` หรือ `telegram_mode=live-frontier` เมื่อเลน Docker ที่เลือกมี `published-upgrade-survivor` อาร์ติแฟกต์แพ็กเกจจะเป็นตัวเลือก และ `published_upgrade_survivor_baseline` จะเลือก baseline ที่เผยแพร่แล้ว `update-restart-auth` ใช้แพ็กเกจตัวเลือกเป็นทั้ง CLI ที่ติดตั้งและแพ็กเกจที่อยู่ระหว่างการทดสอบ เพื่อให้ทดสอบเส้นทางรีสตาร์ตแบบมีการจัดการของคำสั่งอัปเดตจากตัวเลือก

  ตัวอย่าง:

  ```bash
  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 published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai
  ```

  โปรไฟล์ที่ใช้บ่อย:
  - `smoke`: เลนการติดตั้ง/ช่องทาง/เอเจนต์, เครือข่าย Gateway และการโหลดการกำหนดค่าใหม่
  - `package`: เลนแพ็กเกจ/อัปเดต/รีสตาร์ต/Plugin ที่ทำงานกับอาร์ติแฟกต์โดยตรง โดยไม่มี OpenWebUI หรือ ClawHub แบบใช้งานจริง
  - `product`: โปรไฟล์แพ็กเกจพร้อมช่องทาง MCP, การล้างข้อมูล cron/เอเจนต์ย่อย, การค้นหาเว็บของ OpenAI และ OpenWebUI
  - `full`: ส่วนย่อยของเส้นทางรีลีส Docker พร้อม OpenWebUI
  - `custom`: การเลือก `docker_lanes` แบบตรงทั้งหมดสำหรับการรันซ้ำแบบเจาะจง

- เรียกใช้เวิร์กโฟลว์ `CI` แบบแมนนวลโดยตรง เมื่อต้องการเพียงความครอบคลุมของ CI ปกติที่กำหนดผลลัพธ์ได้สำหรับตัวเลือกรีลีส การสั่งรัน CI แบบแมนนวลจะข้ามการจำกัดขอบเขตตามการเปลี่ยนแปลง และบังคับใช้ shard ของ Linux Node, shard ของ Plugin ที่รวมมาด้วย, shard สัญญาของ Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, `check-*`, `check-additional-*`, การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ที่สร้างแล้ว, การตรวจสอบเอกสาร, Skills ของ Python, Windows, macOS และเลน i18n ของ Control UI การรัน CI แบบแมนนวลแยกต่างหากจะเรียกใช้ Android เฉพาะเมื่อสั่งรันด้วย `include_android=true`; `Full Release Validation` จะส่งอินพุตนั้นให้ CI ลูก

  ```bash
  gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
  ```

- เรียกใช้ `pnpm qa:otel:smoke` เมื่อตรวจสอบเทเลเมทรีของรีลีส โดยจะทดสอบ QA-lab ผ่านตัวรับ OTLP/HTTP ภายในเครื่อง และตรวจสอบการส่งออก trace, metric และ log รวมถึงแอตทริบิวต์ trace ที่มีขอบเขตจำกัดและการปกปิดเนื้อหา/ตัวระบุ โดยไม่ต้องใช้ Opik, Langfuse หรือตัวรวบรวมภายนอกอื่น
- เรียกใช้ `pnpm qa:otel:collector-smoke` เมื่อตรวจสอบความเข้ากันได้กับตัวรวบรวม โดยจะกำหนดเส้นทางการส่งออก OTLP ของ QA-lab เดียวกันผ่านคอนเทนเนอร์ Docker ของ OpenTelemetry Collector จริง ก่อนตรวจสอบกับตัวรับภายในเครื่อง
- เรียกใช้ `pnpm qa:prometheus:smoke` เมื่อตรวจสอบการ scrape Prometheus ที่มีการป้องกัน โดยจะทดสอบ QA-lab ปฏิเสธการ scrape ที่ไม่ได้ยืนยันตัวตน และตรวจสอบว่ากลุ่ม metric ที่สำคัญต่อรีลีสไม่มีเนื้อหา prompt, ตัวระบุดิบ, โทเค็นการยืนยันตัวตน และพาธภายในเครื่อง
- เรียกใช้ `pnpm qa:observability:smoke` สำหรับเลนตรวจสอบเบื้องต้นของ OpenTelemetry และ Prometheus จาก source checkout ต่อเนื่องกัน
- เรียกใช้ `pnpm release:check` ก่อนทุกรีลีสที่มีแท็ก
- ขั้นตอนตรวจสอบเบื้องต้นของ `OpenClaw NPM Release` จะสร้างหลักฐานรีลีสของ dependency ก่อนแพ็ก npm tarball เกตช่องโหว่จากคำแนะนำด้านความปลอดภัยของ npm จะบล็อกรีลีส รายงานความเสี่ยงของ manifest แบบส่งต่อ, ขอบเขตความเป็นเจ้าของ/การติดตั้ง dependency และการเปลี่ยนแปลง dependency ใช้เป็นหลักฐานรีลีสเท่านั้น รายงานการเปลี่ยนแปลง dependency จะเปรียบเทียบตัวเลือกรีลีสกับแท็กรีลีสก่อนหน้าที่ยังเข้าถึงได้ ขั้นตอนตรวจสอบเบื้องต้นจะอัปโหลดหลักฐาน dependency เป็น `openclaw-release-dependency-evidence-<tag>` และฝังไว้ภายใต้ `dependency-evidence/` ภายในอาร์ติแฟกต์ตรวจสอบเบื้องต้นของ npm ที่เตรียมไว้ด้วย เส้นทางเผยแพร่จริงจะนำอาร์ติแฟกต์ตรวจสอบเบื้องต้นนั้นมาใช้ซ้ำ แล้วแนบหลักฐานเดียวกันกับรีลีส GitHub เป็น `openclaw-<version>-dependency-evidence.zip`
- เรียกใช้ `OpenClaw Release Publish` สำหรับลำดับการเผยแพร่ที่แก้ไขสถานะ หลังจากมีแท็กแล้ว ให้สั่งเผยแพร่ beta และ stable ตามปกติจาก `main` ที่เชื่อถือได้ โดยแท็กรีลีสยังคงเลือก commit เป้าหมายที่แน่นอนและอาจชี้เข้าไปใน `release/YYYY.M.PATCH` การเผยแพร่ alpha ของ Tideclaw ยังคงอยู่บน branch alpha ที่ตรงกัน ส่ง `preflight_run_id` ของ npm สำหรับ OpenClaw ที่สำเร็จ, `full_release_validation_run_id` ที่สำเร็จ และ `full_release_validation_run_attempt` ที่แน่นอน และคงขอบเขตการเผยแพร่ Plugin เริ่มต้นเป็น `all-publishable` เว้นแต่กำลังดำเนินการซ่อมแซมแบบเจาะจงโดยตั้งใจ เวิร์กโฟลว์จะเรียงลำดับการเผยแพร่ npm ของ Plugin, การเผยแพร่ Plugin ไปยัง ClawHub และการเผยแพร่ npm ของ OpenClaw เพื่อไม่ให้เผยแพร่แพ็กเกจหลักก่อน Plugin ที่แยกออกมาเป็นภายนอก ส่วนการโปรโมต Windows และ Android จะทำงานพร้อมกับการเผยแพร่ npm หลักโดยอ้างอิงหน้ารีลีสฉบับร่าง การรันเผยแพร่ซ้ำสามารถทำต่อจากเดิมได้: เวอร์ชัน npm หลักที่เผยแพร่แล้วจะข้ามการสั่งรันส่วนหลัก หลังจากเวิร์กโฟลว์พิสูจน์ว่า tarball ในรีจิสทรีตรงกับอาร์ติแฟกต์ตรวจสอบเบื้องต้นของแท็ก และจะข้ามการโปรโมต Windows/Android เมื่อรีลีสมีสัญญาอาร์ติแฟกต์ที่ตรวจสอบแล้ว ดังนั้นการลองใหม่จะทำซ้ำเฉพาะขั้นตอนที่ล้มเหลว การซ่อมแซมเฉพาะ Plugin แบบเจาะจงต้องใช้ `plugin_publish_scope=selected` และรายการ Plugin ที่ไม่ว่าง การรัน `all-publishable` แบบเฉพาะ Plugin ต้องมีหลักฐานการตรวจสอบเบื้องต้นและ Full Release Validation ที่ครบถ้วนและเปลี่ยนแปลงไม่ได้ โดยจะปฏิเสธหลักฐานที่ไม่ครบถ้วน
- `OpenClaw Release Publish` แบบ stable ต้องใช้ `windows_node_tag` ที่แน่นอน หลังจากมีรีลีส `openclaw/openclaw-windows-node` ที่ตรงกันและไม่ใช่ prerelease แล้ว พร้อมกับแผนที่ `windows_node_installer_digests` ที่ตัวเลือกได้รับการอนุมัติ ก่อนสั่งรันส่วนการเผยแพร่ใด ๆ ระบบจะตรวจสอบว่ารีลีสต้นทางนั้นเผยแพร่แล้ว ไม่ใช่ prerelease มีตัวติดตั้ง x64/ARM64 ที่จำเป็น และยังคงตรงกับแผนที่ที่อนุมัติ จากนั้นจะสั่งรัน `Windows Node Release` ขณะที่รีลีส OpenClaw ยังเป็นฉบับร่าง โดยส่งแผนที่ digest ของตัวติดตั้งที่ตรึงไว้โดยไม่เปลี่ยนแปลง เวิร์กโฟลว์ลูกจะดาวน์โหลดตัวติดตั้ง Windows Hub ที่ลงนามแล้วจากแท็กที่ระบุแน่นอนนั้น เปรียบเทียบกับ digest ที่ตรึงไว้ ตรวจสอบบน runner ของ Windows ว่าลายเซ็น Authenticode ใช้ผู้ลงนาม OpenClaw Foundation ตามที่คาดไว้ เขียน manifest SHA-256 และอัปโหลดตัวติดตั้งพร้อม manifest ไปยังรีลีส GitHub มาตรฐานของ OpenClaw จากนั้นดาวน์โหลดอาร์ติแฟกต์ที่โปรโมตแล้วอีกครั้งและตรวจสอบการเป็นสมาชิกใน manifest พร้อมแฮช เวิร์กโฟลว์แม่จะตรวจสอบสัญญาอาร์ติแฟกต์ x64, ARM64 และ checksum ปัจจุบันก่อนเผยแพร่ การกู้คืนโดยตรงจะปฏิเสธชื่ออาร์ติแฟกต์ `OpenClawCompanion-*` ที่ไม่คาดหมาย ก่อนแทนที่อาร์ติแฟกต์ตามสัญญาที่คาดไว้ด้วยไบต์จากต้นทางที่ตรึงไว้

  สั่งรัน `Windows Node Release` แบบแมนนวลเฉพาะเพื่อการกู้คืนเท่านั้น และส่งแท็กที่ระบุแน่นอนเสมอ ห้ามใช้ `latest` พร้อมกับแผนที่ JSON `expected_installer_digests` ที่ระบุอย่างชัดเจนจากรีลีสต้นทางที่ได้รับอนุมัติ ลิงก์ดาวน์โหลดบนเว็บไซต์ควรชี้ไปยัง URL อาร์ติแฟกต์ของรีลีส OpenClaw ที่ระบุแน่นอนสำหรับรีลีส stable ปัจจุบัน หรือใช้ `releases/latest/download/...` เฉพาะหลังจากตรวจสอบแล้วว่าการเปลี่ยนเส้นทาง latest ของ GitHub ชี้ไปยังรีลีสเดียวกัน ห้ามลิงก์เฉพาะไปยังหน้ารีลีสของ repo คู่กัน

- ขณะนี้การตรวจสอบรีลีสทำงานในเวิร์กโฟลว์แบบเรียกใช้ด้วยตนเองที่แยกต่างหาก: `OpenClaw Release Checks` นอกจากนี้ยังเรียกใช้เลนตรวจสอบความสอดคล้องของม็อก QA Lab รวมถึงโปรไฟล์รีลีส Matrix และเลน QA ของ Telegram ก่อนอนุมัติรีลีส เลนแบบสดใช้สภาพแวดล้อม `qa-live-shared`; Telegram ยังใช้การเช่าข้อมูลรับรอง Convex CI ด้วย เรียกใช้เวิร์กโฟลว์ `QA-Lab - All Lanes` แบบเรียกใช้ด้วยตนเองพร้อม `matrix_profile=all` เมื่อต้องการทุกสถานการณ์ Matrix ที่ยังได้รับการดูแล โดยเวิร์กโฟลว์จะกระจายตัวเลือกนั้นไปยังโปรไฟล์การขนส่ง สื่อ และ E2EE เพื่อให้หลักฐานทั้งหมดเสร็จสิ้นภายในเวลาหมดเวลาของแต่ละงาน
- การตรวจสอบรันไทม์สำหรับการติดตั้งและอัปเกรดข้ามระบบปฏิบัติการเป็นส่วนหนึ่งของ `OpenClaw Release Checks` และ `Full Release Validation` สาธารณะ ซึ่งเรียกเวิร์กโฟลว์แบบนำกลับมาใช้ใหม่ `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` โดยตรง การแยกนี้เป็นไปโดยเจตนา เพื่อให้เส้นทางรีลีส npm จริงสั้น ทำงานแบบกำหนดผลลัพธ์ได้ และมุ่งเน้นอาร์ติแฟกต์ ขณะที่การตรวจสอบแบบสดที่ช้ากว่าจะอยู่ในเลนของตนเอง เพื่อไม่ให้การเผยแพร่หยุดชะงักหรือถูกบล็อก
- ควรสั่งให้การตรวจสอบรีลีสที่มีข้อมูลลับทำงานผ่าน `Full Release Validation` หรือจากรีเฟอเรนซ์เวิร์กโฟลว์ `main`/release เพื่อให้ตรรกะของเวิร์กโฟลว์และข้อมูลลับยังคงอยู่ภายใต้การควบคุม
- `OpenClaw Release Checks` ยอมรับชื่อแบรนช์ แท็ก หรือ SHA ของคอมมิตแบบเต็ม ตราบใดที่คอมมิตที่แก้ไขแล้วสามารถเข้าถึงได้จากแบรนช์หรือแท็กรีลีสของ OpenClaw
- การตรวจสอบก่อนเริ่มแบบตรวจสอบเท่านั้นของ `OpenClaw NPM Release` ยังยอมรับ SHA แบบเต็ม 40 อักขระของคอมมิตแบรนช์เวิร์กโฟลว์ปัจจุบันโดยไม่ต้องมีแท็กที่พุชแล้ว เส้นทาง SHA นั้นใช้สำหรับการตรวจสอบเท่านั้นและไม่สามารถเลื่อนขั้นเป็นการเผยแพร่จริงได้ ในโหมด SHA เวิร์กโฟลว์จะสังเคราะห์ `v<package.json version>` สำหรับการตรวจสอบข้อมูลเมตาของแพ็กเกจเท่านั้น ส่วนการเผยแพร่จริงยังคงต้องใช้แท็กรีลีสจริง
- ทั้งสองเวิร์กโฟลว์คงเส้นทางการเผยแพร่และการเลื่อนขั้นจริงไว้บนรันเนอร์ที่โฮสต์โดย GitHub ขณะที่เส้นทางการตรวจสอบที่ไม่เปลี่ยนแปลงข้อมูลสามารถใช้รันเนอร์ Blacksmith Linux ที่มีขนาดใหญ่กว่าได้
- เวิร์กโฟลว์นั้นเรียกใช้ `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` โดยใช้ข้อมูลลับของเวิร์กโฟลว์ทั้ง `OPENAI_API_KEY` และ `ANTHROPIC_API_KEY`
- การตรวจสอบก่อนเริ่มรีลีส npm ไม่รอเลนการตรวจสอบรีลีสที่แยกต่างหากอีกต่อไป
- ก่อนติดแท็กรีลีสแคนดิเดตในเครื่อง ให้เรียกใช้ `RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check` ตัวช่วยจะเรียกใช้ข้อควบคุมรีลีสแบบรวดเร็ว การตรวจสอบรีลีส npm/ClawHub ของ Plugin การบิลด์ การบิลด์ UI และ `release:openclaw:npm:check` ตามลำดับที่ตรวจพบข้อผิดพลาดทั่วไปซึ่งอาจบล็อกการอนุมัติ ก่อนที่เวิร์กโฟลว์เผยแพร่ของ GitHub จะเริ่มทำงาน
- เรียกใช้ `RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts` (หรือแท็กพรีรีลีส/แท็กแก้ไขที่ตรงกัน) ก่อนอนุมัติ
- หลังเผยแพร่ npm ให้เรียกใช้ `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH` (หรือเวอร์ชันเบต้า/เวอร์ชันแก้ไขที่ตรงกัน) เพื่อตรวจสอบเส้นทางการติดตั้งจากรีจิสทรีที่เผยแพร่แล้วในคำนำหน้าชั่วคราวใหม่
- หลังเผยแพร่เบต้า ให้เรียกใช้ `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` เพื่อตรวจสอบการเริ่มต้นใช้งานจากแพ็กเกจที่ติดตั้ง การตั้งค่า Telegram และ E2E จริงของ Telegram กับแพ็กเกจ npm ที่เผยแพร่ โดยใช้พูลข้อมูลรับรอง Telegram แบบเช่าที่ใช้ร่วมกัน การทำงานเฉพาะกิจในเครื่องของผู้ดูแลสามารถละเว้นตัวแปร Convex และส่งข้อมูลรับรองสภาพแวดล้อม `OPENCLAW_QA_TELEGRAM_*` ทั้งสามรายการโดยตรง
- หากต้องการเรียกใช้การทดสอบควันเบต้าแบบเต็มหลังการเผยแพร่จากเครื่องของผู้ดูแล ให้ใช้ `pnpm release:beta-smoke -- --beta betaN` ตัวช่วยจะเรียกใช้การตรวจสอบการอัปเดต npm/เป้าหมายใหม่ของ Parallels สั่งให้ `NPM Telegram Beta E2E` ทำงาน สำรวจสถานะการทำงานของเวิร์กโฟลว์ที่ตรงกัน ดาวน์โหลดอาร์ติแฟกต์ และพิมพ์รายงาน Telegram
- ผู้ดูแลสามารถเรียกใช้การตรวจสอบหลังการเผยแพร่เดียวกันจาก GitHub Actions ผ่านเวิร์กโฟลว์ `NPM Telegram Beta E2E` แบบเรียกใช้ด้วยตนเอง เวิร์กโฟลว์นี้จงใจให้เรียกใช้ด้วยตนเองเท่านั้นและไม่ทำงานในการผสานทุกครั้ง
- ระบบอัตโนมัติสำหรับรีลีสของผู้ดูแลใช้กระบวนการตรวจสอบก่อนเริ่มแล้วจึงเลื่อนขั้น:
  - การเผยแพร่ npm จริงต้องผ่าน npm `preflight_run_id` ที่สำเร็จ
  - การประสานงานเผยแพร่และการตรวจสอบก่อนเริ่มสำหรับเบต้าและสเตเบิลตามปกติใช้ `main` ที่เชื่อถือได้กับแท็กเป้าหมายที่ตรงกันทุกประการ การเผยแพร่และการตรวจสอบก่อนเริ่มสำหรับ Tideclaw alpha ใช้แบรนช์ alpha ที่ตรงกัน
  - รีลีส npm แบบสเตเบิลมีค่าเริ่มต้นเป็น `beta`; การเผยแพร่ npm แบบสเตเบิลสามารถกำหนดเป้าหมาย `latest` อย่างชัดเจนผ่านอินพุตของเวิร์กโฟลว์
  - การเปลี่ยนแปลง dist-tag ของ npm ที่ใช้โทเค็นอยู่ใน `openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml` เนื่องจาก `npm dist-tag add` ยังคงต้องใช้ `NPM_TOKEN` ขณะที่รีโพซิทอรีต้นทางคงการเผยแพร่แบบ OIDC เท่านั้น
  - `macOS Release` สาธารณะใช้สำหรับการตรวจสอบเท่านั้น เมื่อแท็กอยู่เฉพาะบนแบรนช์รีลีส แต่เวิร์กโฟลว์ถูกสั่งให้ทำงานจาก `main` ให้ตั้งค่า `public_release_branch=release/YYYY.M.PATCH`
  - การเผยแพร่ macOS จริงต้องผ่าน macOS `preflight_run_id` และ `validate_run_id` ที่สำเร็จ
  - เส้นทางการเผยแพร่จริงจะเลื่อนขั้นอาร์ติแฟกต์ที่เตรียมไว้ แทนที่จะบิลด์ใหม่อีกครั้ง
- สำหรับรีลีสแก้ไขแบบสเตเบิล เช่น `YYYY.M.PATCH-N` ตัวตรวจสอบหลังการเผยแพร่ยังตรวจสอบเส้นทางอัปเกรดด้วยคำนำหน้าชั่วคราวเดียวกันจาก `YYYY.M.PATCH` ไปยัง `YYYY.M.PATCH-N` เพื่อให้การแก้ไขรีลีสไม่สามารถปล่อยให้การติดตั้งแบบโกลบอลรุ่นเก่าค้างอยู่กับเพย์โหลดสเตเบิลพื้นฐานโดยไม่มีการแจ้งเตือน
- การตรวจสอบก่อนเริ่มรีลีส npm จะล้มเหลวแบบปิด เว้นแต่ tarball จะมีทั้ง `dist/control-ui/index.html` และเพย์โหลด `dist/control-ui/assets/` ที่ไม่ว่างเปล่า เพื่อไม่ให้เราเผยแพร่แดชบอร์ดเบราว์เซอร์ที่ว่างเปล่าอีก
- การตรวจสอบหลังการเผยแพร่ยังตรวจสอบด้วยว่าจุดเข้าใช้งาน Plugin และข้อมูลเมตาของแพ็กเกจที่เผยแพร่มีอยู่ในเลย์เอาต์รีจิสทรีที่ติดตั้งแล้ว รีลีสที่เผยแพร่โดยขาดเพย์โหลดรันไทม์ของ Plugin จะไม่ผ่านตัวตรวจสอบหลังการเผยแพร่และไม่สามารถเลื่อนขั้นเป็น `latest` ได้
- `pnpm test:install:smoke` ยังบังคับใช้งบประมาณ `unpackedSize` ของ npm pack กับ tarball อัปเดตแคนดิเดตด้วย เพื่อให้ E2E ของตัวติดตั้งตรวจพบขนาดแพ็กเกจที่เพิ่มขึ้นโดยไม่ตั้งใจก่อนเข้าสู่เส้นทางเผยแพร่รีลีส
- หากงานรีลีสแก้ไขการวางแผน CI แมนิเฟสต์เวลาทำงานของส่วนขยาย หรือเมทริกซ์การทดสอบส่วนขยาย ให้สร้างเอาต์พุตเมทริกซ์ `plugin-prerelease-extension-shard` ที่ตัววางแผนเป็นเจ้าของขึ้นใหม่จาก `.github/workflows/plugin-prerelease.yml` และตรวจสอบก่อนอนุมัติ เพื่อไม่ให้บันทึกประจำรุ่นอธิบายเลย์เอาต์ CI ที่ล้าสมัย
- ความพร้อมของรีลีส macOS แบบสเตเบิลยังรวมถึงพื้นผิวของตัวอัปเดตด้วย: รีลีส GitHub ต้องมี `.zip`, `.dmg` และ `.dSYM.zip` ที่บรรจุแพ็กเกจแล้ว; `appcast.xml` บน `main` ต้องชี้ไปยังไฟล์ zip สเตเบิลใหม่หลังเผยแพร่ (เวิร์กโฟลว์เผยแพร่ macOS จะคอมมิตไฟล์นี้โดยอัตโนมัติ หรือเปิด appcast PR เมื่อการพุชโดยตรงถูกบล็อก); แอปที่บรรจุแพ็กเกจแล้วต้องคงรหัสบันเดิลที่ไม่ใช่ดีบัก URL ฟีด Sparkle ที่ไม่ว่างเปล่า และ `CFBundleVersion` ที่เท่ากับหรือสูงกว่าค่าขั้นต่ำของบิลด์ Sparkle มาตรฐานสำหรับเวอร์ชันรีลีสนั้น

## กล่องทดสอบรีลีส

`Full Release Validation` คือวิธีที่ผู้ปฏิบัติงานเริ่มเมทริกซ์ผลิตภัณฑ์แบบเต็มจากจุดเข้าใช้งานเดียว ใช้ตัวช่วยเพื่อให้ทุกเวิร์กโฟลว์ย่อยทำงานจากแบรนช์ชั่วคราวที่ตรึงไว้กับ SHA ของเวิร์กโฟลว์ `main` ที่เชื่อถือได้หนึ่งรายการ ขณะที่คอมมิตที่ร้องขอยังคงเป็นแคนดิเดตที่อยู่ระหว่างการทดสอบ:

```bash
pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH
```

ตัวช่วยจะดึง `origin/main` ปัจจุบัน พุช `release-ci/<workflow-sha>-...` ที่คอมมิตเวิร์กโฟลว์ที่เชื่อถือได้นั้น อนุมาน `beta` จากเวอร์ชันแพ็กเกจ alpha/beta และใช้ `stable` ในกรณีอื่น สั่งให้ `Full Release Validation` ทำงานจากแบรนช์ชั่วคราวพร้อม `ref=<target-sha>` ตรวจสอบว่า `headSha` ของทุกเวิร์กโฟลว์ย่อยตรงกับ SHA ของเวิร์กโฟลว์หลักที่ตรึงไว้ แล้วจึงลบแบรนช์ชั่วคราว ส่ง `-f reuse_evidence=false` เพื่อบังคับให้ทำงานใหม่ `-f release_profile=full` สำหรับการตรวจสอบคำแนะนำแบบกว้าง หรือ `--workflow-sha <trusted-main-sha>` เพื่อตรึงคอมมิตเก่าที่ยังเข้าถึงได้จาก `origin/main` ปัจจุบัน ตัวเวิร์กโฟลว์เองจะไม่เขียนรีเฟอเรนซ์ของรีโพซิทอรี วิธีนี้ทำให้เครื่องมือรีลีสที่ใช้ได้เฉพาะ main ยังคงพร้อมใช้งานโดยไม่เพิ่มคอมมิตเครื่องมือลงในแคนดิเดต และหลีกเลี่ยงการพิสูจน์การทำงานย่อย `main` ที่ใหม่กว่าโดยไม่ตั้งใจ

หลังจาก Code SHA เป็นสีเขียว ให้คอมมิตเฉพาะ `CHANGELOG.md` และเรียกใช้ตัวช่วยเดิมด้วย Release SHA:

```bash
pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH
```

เวิร์กโฟลว์หลักครั้งที่สองจะนำหลักฐานผลิตภัณฑ์กลับมาใช้ใหม่ก็ต่อเมื่อ GitHub พิสูจน์ว่า Release SHA สืบทอดจาก Code SHA และชุดพาธที่เปลี่ยนแปลงทั้งหมดเป็น `CHANGELOG.md` ทุกประการ เวิร์กโฟลว์จะบันทึก `changelog-only-release-v1` และไม่สั่งให้เวิร์กโฟลว์ย่อยของผลิตภัณฑ์ทำงาน การตรวจสอบก่อนเริ่ม npm และการยอมรับแพ็กเกจ/การติดตั้งยังคงทำงานบน Release SHA เนื่องจากไบต์ของ tarball เปลี่ยนแปลง

สำหรับ Code SHA ใหม่ เวิร์กโฟลว์จะแก้ไขเป้าหมาย สั่งให้ `CI` แบบเรียกใช้ด้วยตนเองทำงาน แล้วจึงสั่งให้ `OpenClaw Release Checks` ทำงาน `OpenClaw Release Checks` จะกระจายงานไปยังการทดสอบควันการติดตั้ง การตรวจสอบรีลีสข้ามระบบปฏิบัติการ ความครอบคลุมเส้นทางรีลีส Docker แบบสด/E2E เมื่อเปิดใช้การแช่ทดสอบ การยอมรับแพ็กเกจพร้อม E2E แพ็กเกจ Telegram มาตรฐาน การตรวจสอบความสอดคล้องของ QA Lab, Matrix แบบสด และ Telegram แบบสด การทำงานแบบเต็ม/ทั้งหมดจะยอมรับได้ก็ต่อเมื่อสรุป `Full Release Validation` แสดงว่า `normal_ci`, `plugin_prerelease` และ `release_checks` สำเร็จ เว้นแต่การเรียกใช้ใหม่แบบเจาะจงจะจงใจข้ามเวิร์กโฟลว์ย่อย `Plugin Prerelease` ที่แยกต่างหาก ใช้เวิร์กโฟลว์ย่อย `npm-telegram` แบบสแตนด์อโลนเฉพาะสำหรับการเรียกใช้แพ็กเกจที่เผยแพร่แล้วใหม่แบบเจาะจงด้วย `release_package_spec` หรือ `npm_telegram_package_spec` สรุปของตัวตรวจสอบขั้นสุดท้ายมีตารางงานที่ช้าที่สุดสำหรับการทำงานย่อยแต่ละครั้ง เพื่อให้ผู้จัดการรีลีสเห็นเส้นทางวิกฤตปัจจุบันโดยไม่ต้องดาวน์โหลดบันทึก

เวิร์กโฟลว์ย่อยด้านประสิทธิภาพผลิตภัณฑ์ใช้เฉพาะอาร์ติแฟกต์ในเส้นทางรีลีสนี้ เวิร์กโฟลว์
หลักสั่งให้ทำงานด้วย `publish_reports=false` และการตรวจสอบจะถูกปฏิเสธ
เว้นแต่ข้อควบคุมแบบใช้อาร์ติแฟกต์เท่านั้นจะพิสูจน์ว่าตัวเผยแพร่รายงาน Clawgrit ยังคง
ถูกข้าม

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

เวิร์กโฟลว์ย่อยถูกสั่งให้ทำงานจากรีเฟอเรนซ์ที่เชื่อถือได้ซึ่งตรึงด้วย SHA และเรียกใช้ `Full Release Validation` การทำงานย่อยทุกครั้งต้องใช้ SHA ของเวิร์กโฟลว์หลักที่ตรงกันทุกประการ อย่าใช้การสั่งให้ `--ref main -f ref=<sha>` ทำงานโดยตรงสำหรับหลักฐานรีลีส ให้ใช้ `pnpm ci:full-release --sha <target-sha> --target-ref release/YYYY.M.PATCH`

ใช้ `release_profile` เพื่อเลือกขอบเขตความครอบคลุมแบบสด/ของผู้ให้บริการ:

- `beta`: เส้นทาง OpenAI/แกนหลักแบบสดและ Docker ที่สำคัญต่อรีลีสและเร็วที่สุด
- `stable`: ความครอบคลุมผู้ให้บริการ/แบ็กเอนด์ระดับเบต้ารวมถึงสเตเบิลสำหรับการอนุมัติรีลีส
- `full`: สเตเบิลรวมถึงความครอบคลุมผู้ให้บริการ/สื่อเชิงคำแนะนำแบบกว้าง

การตรวจสอบแบบสเตเบิลและแบบเต็มจะเรียกใช้การตรวจสอบแบบสด/E2E อย่างละเอียด เส้นทางรีลีส Docker และการตรวจสอบแพ็กเกจที่เผยแพร่แล้วว่ายังคงอัปเกรดได้ภายในขอบเขต ก่อนการเลื่อนขั้นเสมอ ใช้ `run_release_soak=true` เพื่อร้องขอการตรวจสอบชุดเดียวกันสำหรับเบต้า การตรวจสอบนี้ครอบคลุมแพ็กเกจสเตเบิลสี่เวอร์ชันล่าสุด รวมถึงค่าพื้นฐาน `2026.4.23` และ `2026.5.2` ที่ตรึงไว้ ตลอดจนความครอบคลุม `2026.4.15` ที่เก่ากว่า โดยนำค่าพื้นฐานที่ซ้ำกันออกและแบ่งค่าพื้นฐานแต่ละรายการไปยังงานรันเนอร์ Docker ของตนเอง

`OpenClaw Release Checks` ใช้รีเฟอเรนซ์เวิร์กโฟลว์ที่เชื่อถือได้เพื่อแก้ไขรีเฟอเรนซ์เป้าหมายครั้งเดียวเป็น `release-package-under-test` และนำอาร์ติแฟกต์นั้นกลับมาใช้ในการตรวจสอบข้ามระบบปฏิบัติการ การยอมรับแพ็กเกจ และเส้นทางรีลีส Docker เมื่อการแช่ทดสอบทำงาน วิธีนี้ทำให้กล่องที่เกี่ยวข้องกับแพ็กเกจทั้งหมดใช้ไบต์ชุดเดียวกันและหลีกเลี่ยงการบิลด์แพ็กเกจซ้ำ หลังจากเบต้าอยู่บน npm แล้ว ให้ตั้งค่า `release_package_spec=openclaw@YYYY.M.PATCH-beta.N` เพื่อให้การตรวจสอบรีลีสดาวน์โหลดแพ็กเกจที่เผยแพร่แล้วเพียงครั้งเดียว แยก SHA ของซอร์สบิลด์จาก `dist/build-info.json` และนำอาร์ติแฟกต์นั้นกลับมาใช้สำหรับเลนข้ามระบบปฏิบัติการ การยอมรับแพ็กเกจ เส้นทางรีลีส Docker และ Telegram ของแพ็กเกจ

การทดสอบควันการติดตั้ง OpenAI ข้ามระบบปฏิบัติการใช้ `OPENCLAW_CROSS_OS_OPENAI_MODEL` เมื่อตั้งค่าตัวแปรของรีโพซิทอรี/องค์กร มิฉะนั้นจะใช้ `openai/gpt-5.6-luna` เนื่องจากเลนนี้พิสูจน์การติดตั้งแพ็กเกจ การเริ่มต้นใช้งาน การเริ่มทำงานของ Gateway และการทำงานของเอเจนต์แบบสดหนึ่งรอบ ไม่ใช่การวัดประสิทธิภาพของโมเดลที่มีความสามารถสูงสุด เมทริกซ์ผู้ให้บริการแบบสดที่กว้างกว่ายังคงเป็นพื้นที่สำหรับความครอบคลุมเฉพาะโมเดล

ใช้รูปแบบต่อไปนี้ตามขั้นตอนของรีลีส:

```bash
# ตรวจสอบ Code SHA ที่ผลิตภัณฑ์เสร็จสมบูรณ์
pnpm ci:full-release \
  --sha <code-sha> \
  --target-ref release/YYYY.M.PATCH

# ตรวจสอบ Release SHA ที่เปลี่ยนเฉพาะ changelog โดยใช้หลักฐานผลิตภัณฑ์จาก Code SHA ซ้ำ
pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH

# หลังเผยแพร่ beta ให้เพิ่ม Telegram E2E สำหรับแพ็กเกจที่เผยแพร่แล้ว
pnpm ci:full-release \
  --sha <release-sha> \
  --target-ref release/YYYY.M.PATCH \
  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \
  -f npm_telegram_provider_mode=mock-openai
```

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

`rerun_group=all` อาจใช้การรันชุดรวมที่ผ่านก่อนหน้านี้ซ้ำได้ เมื่อโปรไฟล์รีลีส
การตั้งค่า soak ที่มีผล และอินพุตการตรวจสอบตรงกัน และ target SHA
เหมือนกัน หรือเป้าหมายใหม่เป็น descendant ที่มีชุดพาธที่เปลี่ยนแปลงทั้งหมด
ตรงกับ `CHANGELOG.md` ทุกประการ การใช้เป้าหมายเดิมซ้ำจะบันทึก
`exact-target-full-validation-v1`; Release SHA หลังการตรวจสอบจะบันทึก
`changelog-only-release-v1` โดยกรณีหลังจะใช้ซ้ำเฉพาะการตรวจสอบผลิตภัณฑ์เท่านั้น ส่วนการตรวจสอบล่วงหน้าของ npm
ไบต์ของแพ็กเกจ ที่มาของบันทึกประจำรุ่น และการยอมรับการติดตั้ง/อัปเดต
ยังต้องรันกับ Release SHA การเปลี่ยนแปลงเวอร์ชัน ซอร์ส ไฟล์ที่สร้างขึ้น
การอ้างอิง แพ็กเกจ หรือเป้าหมายที่เวิร์กโฟลว์เป็นเจ้าของ ต้องใช้ Code SHA ใหม่
และการตรวจสอบฉบับเต็มใหม่ การรันชุดรวมที่ใหม่กว่าสำหรับ ref `release/*` และ
กลุ่มการรันซ้ำเดียวกัน จะแทนที่รายการที่กำลังดำเนินการโดยอัตโนมัติ ส่ง
`reuse_evidence=false` เพื่อบังคับให้รันฉบับเต็มใหม่

สำหรับการกู้คืนที่มีขอบเขต ให้ส่ง `rerun_group` ไปยังชุดรวม `all` คือการรัน release candidate จริง, `ci` รันเฉพาะรายการลูกของ CI ปกติ, `plugin-prerelease` รันเฉพาะรายการลูกของ Plugin ที่ใช้เฉพาะรีลีส, `release-checks` รันทุกกล่องรีลีส และกลุ่มรีลีสที่แคบกว่าคือ `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` และ `npm-telegram` การรันซ้ำแบบเจาะจง `npm-telegram` ต้องใช้ `release_package_spec` หรือ `npm_telegram_package_spec`; การรันแบบเต็ม/ทั้งหมดจะใช้ Telegram E2E ของแพ็กเกจมาตรฐานภายใน Package Acceptance การรันซ้ำข้ามระบบปฏิบัติการแบบเจาะจงสามารถเพิ่ม `cross_os_suite_filter=windows/packaged-upgrade` หรือตัวกรองระบบปฏิบัติการ/ชุดทดสอบอื่นได้ ความล้มเหลวของการตรวจสอบรีลีส QA จะบล็อกการตรวจสอบรีลีสตามปกติ รวมถึงความคลาดเคลื่อนของ dynamic tool ของ OpenClaw ที่กำหนดให้ตรวจสอบในระดับมาตรฐาน การรัน Tideclaw alpha ยังอาจถือว่าเลนตรวจสอบรีลีสที่ไม่เกี่ยวกับความปลอดภัยของแพ็กเกจเป็นเพียงคำแนะนำ เมื่อใช้ `release_profile=beta` ชุดทดสอบผู้ให้บริการจริง `Run repo/live E2E validation` จะเป็นเพียงคำแนะนำ (คำเตือน ไม่ใช่ตัวบล็อก) ส่วนโปรไฟล์ stable และ full ยังคงใช้เป็นตัวบล็อก เมื่อ `live_suite_filter` ร้องขอเลน QA แบบใช้งานจริงที่มีเกตอย่างชัดเจน เช่น Discord, WhatsApp หรือ Slack ต้องเปิดใช้งานตัวแปร repo `OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED` ที่ตรงกัน มิฉะนั้นการเก็บอินพุตจะล้มเหลวแทนที่จะข้ามเลนโดยไม่แจ้ง

### Vitest

กล่อง Vitest คือเวิร์กโฟลว์ลูกแบบแมนนวล `CI` CI แบบแมนนวลจงใจข้ามการจำกัดขอบเขตตามการเปลี่ยนแปลง และบังคับใช้กราฟการทดสอบปกติสำหรับ release candidate ได้แก่ shard ของ Linux Node, shard ของ Plugin ที่รวมมาในแพ็กเกจ, shard สัญญาของ Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, `check-*`, `check-additional-*`, การตรวจสอบ smoke ของอาร์ติแฟกต์ที่สร้างแล้ว, การตรวจสอบเอกสาร, Skills สำหรับ Python, Windows, macOS และ i18n ของ Control UI โดยจะรวม Android เมื่อ `Full Release Validation` รันกล่องนี้ เนื่องจากชุดรวมส่ง `include_android=true`; ส่วน CI แบบแมนนวลที่รันแยกต่างหากต้องใช้ `include_android=true` เพื่อครอบคลุม Android

ใช้กล่องนี้เพื่อตอบว่า "ซอร์สทรีผ่านชุดทดสอบปกติฉบับเต็มหรือไม่" ซึ่งไม่เหมือนกับการตรวจสอบผลิตภัณฑ์ตามเส้นทางรีลีส หลักฐานที่ต้องเก็บไว้:

- สรุป `Full Release Validation` ที่แสดง URL ของการรัน `CI` ที่ถูกสั่งให้ทำงาน
- การรัน `CI` ผ่านบน target SHA ที่ตรงกันทุกประการ
- ชื่อ shard ที่ล้มเหลวหรือทำงานช้าจากงาน CI เมื่อตรวจสอบ regression
- อาร์ติแฟกต์เวลาของ Vitest เช่น `.artifacts/vitest-shard-timings.json` เมื่อการรันต้องวิเคราะห์ประสิทธิภาพ

รัน CI แบบแมนนวลโดยตรงเฉพาะเมื่อรีลีสต้องการ CI ปกติที่กำหนดผลได้แน่นอน แต่ไม่ต้องใช้กล่อง Docker, QA Lab, การใช้งานจริง, ข้ามระบบปฏิบัติการ หรือแพ็กเกจ ใช้คำสั่งแรกสำหรับ CI โดยตรงที่ไม่รวม Android เพิ่ม `include_android=true` เมื่อ CI ของ release candidate ที่รันโดยตรงต้องครอบคลุม Android:

```bash
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true
```

### Docker

กล่อง Docker อยู่ใน `OpenClaw Release Checks` ถึง `openclaw-live-and-e2e-checks-reusable.yml` รวมถึงเวิร์กโฟลว์โหมดรีลีส `install-smoke` กล่องนี้ตรวจสอบ release candidate ผ่านสภาพแวดล้อม Docker ที่จัดแพ็กเกจแล้ว แทนการใช้เฉพาะการทดสอบระดับซอร์ส

ความครอบคลุมของ Docker สำหรับรีลีสประกอบด้วย:

- การทดสอบ smoke การติดตั้งแบบเต็ม โดยเปิดใช้การทดสอบ smoke การติดตั้ง Bun แบบ global ที่ทำงานช้า
- การเตรียม/ใช้ซ้ำอิมเมจ smoke จาก Dockerfile รากตาม target SHA โดยงาน smoke สำหรับ QR, root/gateway และ installer/Bun ทำงานเป็น shard ของ install-smoke แยกกัน
- เลน E2E ของรีโพซิทอรี
- ส่วนย่อย 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`
- ความครอบคลุม OpenWebUI บน runner เฉพาะที่มีดิสก์ขนาดใหญ่เมื่อมีการร้องขอ
- เลนติดตั้ง/ถอนการติดตั้ง Plugin ที่รวมมาในแพ็กเกจแบบแยกส่วน `bundled-plugin-install-uninstall-0` ถึง `bundled-plugin-install-uninstall-23`
- ชุดทดสอบผู้ให้บริการแบบใช้งานจริง/E2E และความครอบคลุมโมเดลจริงใน Docker เมื่อการตรวจสอบรีลีสรวมชุดทดสอบแบบใช้งานจริง

ใช้อาร์ติแฟกต์ Docker ก่อนรันซ้ำ ตัวกำหนดตารางเวลาตามเส้นทางรีลีสจะอัปโหลด `.artifacts/docker-tests/` พร้อมบันทึกของเลน, `summary.json`, `failures.json`, เวลาของแต่ละเฟส, JSON แผนตัวกำหนดตารางเวลา และคำสั่งรันซ้ำ สำหรับการกู้คืนแบบเจาะจง ให้ใช้ `docker_lanes=<lane[,lane]>` กับเวิร์กโฟลว์แบบใช้งานจริง/E2E ที่ใช้ซ้ำได้ แทนการรันส่วนย่อยของรีลีสทั้งหมดซ้ำ คำสั่งรันซ้ำที่สร้างขึ้นจะรวม `package_artifact_run_id` ก่อนหน้าและอินพุตอิมเมจ Docker ที่เตรียมไว้เมื่อมี เพื่อให้เลนที่ล้มเหลวใช้ tarball และอิมเมจ GHCR ชุดเดิมซ้ำได้

### QA Lab

กล่อง QA Lab เป็นส่วนหนึ่งของ `OpenClaw Release Checks` เช่นกัน กล่องนี้เป็นเกตการรีลีสสำหรับพฤติกรรมเชิงเอเจนต์และระดับช่องทาง ซึ่งแยกจากกลไกแพ็กเกจของ Vitest และ Docker

ความครอบคลุม QA Lab สำหรับรีลีสประกอบด้วย:

- เลนความเท่าเทียมแบบจำลองที่เปรียบเทียบเลน candidate ของ OpenAI กับ baseline `anthropic/claude-opus-4-8` โดยใช้ชุดทดสอบความเท่าเทียมเชิงเอเจนต์
- โปรไฟล์รีลีสของอะแดปเตอร์จริง Matrix โดยใช้สภาพแวดล้อม `qa-live-shared`
- เลน QA ของ Telegram แบบใช้งานจริงโดยใช้การเช่าข้อมูลประจำตัว Convex CI
- `pnpm qa:otel:smoke`, `pnpm qa:otel:collector-smoke`, `pnpm qa:prometheus:smoke` หรือ `pnpm qa:observability:smoke` เมื่อ telemetry ของรีลีสต้องการหลักฐานภายในเครื่องอย่างชัดเจน

ใช้กล่องนี้เพื่อตอบว่า "รีลีสทำงานถูกต้องในสถานการณ์ QA และโฟลว์ช่องทางแบบใช้งานจริงหรือไม่" เก็บ URL อาร์ติแฟกต์ของเลนความเท่าเทียม, Matrix และ Telegram ไว้เมื่ออนุมัติรีลีส ความครอบคลุม Matrix แบบเต็มยังคงมีให้ใช้เป็นการรัน QA Lab แบบแบ่ง shard ด้วยตนเอง แทนที่จะเป็นเลนวิกฤตต่อรีลีสตามค่าเริ่มต้น

### แพ็กเกจ

กล่อง Package คือเกตสำหรับผลิตภัณฑ์ที่ติดตั้งได้ โดยใช้ `Package Acceptance` และตัวแก้ไข `scripts/resolve-openclaw-package-candidate.mjs` ตัวแก้ไขจะปรับ candidate ให้อยู่ในรูป tarball `package-under-test` ที่ Docker E2E ใช้ ตรวจสอบรายการภายในแพ็กเกจ บันทึกเวอร์ชันแพ็กเกจและ SHA-256 และแยก ref ของชุดควบคุมเวิร์กโฟลว์ออกจาก ref ของซอร์สแพ็กเกจ

แหล่งที่มาของ candidate ที่รองรับ:

- `source=npm`: `openclaw@beta`, `openclaw@latest` หรือเวอร์ชันรีลีส OpenClaw ที่ระบุชัดเจน
- `source=ref`: แพ็ก branch, tag หรือ commit SHA แบบเต็มของ `package_ref` ที่เชื่อถือได้ ด้วยชุดควบคุม `workflow_ref` ที่เลือก
- `source=url`: ดาวน์โหลด `.tgz` ผ่าน HTTPS สาธารณะโดยต้องมี `package_sha256`; ระบบจะปฏิเสธข้อมูลประจำตัวใน URL, พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น, ชื่อโฮสต์หรือแอดเดรสที่แก้ไขได้ซึ่งเป็นแบบ private/internal/special-use และการเปลี่ยนเส้นทางที่ไม่ปลอดภัย
- `source=trusted-url`: ดาวน์โหลด `.tgz` ผ่าน HTTPS โดยต้องมี `package_sha256` และ `trusted_source_id` จากนโยบายที่ระบุชื่อใน `.github/package-trusted-sources.json`; ใช้ตัวเลือกนี้สำหรับมิเรอร์องค์กรหรือรีโพซิทอรีแพ็กเกจส่วนตัวที่ผู้ดูแลเป็นเจ้าของ แทนการเพิ่มตัวเลือกข้ามข้อจำกัดเครือข่ายส่วนตัวระดับอินพุตให้กับ `source=url`
- `source=artifact`: ใช้ `.tgz` ที่อัปโหลดโดยการรัน GitHub Actions อื่นซ้ำ

`OpenClaw Release Checks` รัน Package Acceptance ด้วย `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` Package Acceptance จะคงการตรวจสอบ migration, update, การอัปเกรด VPS ที่จัดการโดย root, การรีสตาร์ตหลังอัปเดตเมื่อกำหนดค่าการยืนยันตัวตนแล้ว, การติดตั้ง ClawHub skill แบบใช้งานจริง, การล้าง dependency ของ Plugin ที่ล้าสมัย, fixture ของ Plugin แบบออฟไลน์, การอัปเดต Plugin, การเสริมความแข็งแกร่งต่อการหลบเลี่ยงการผูกคำสั่งของ Plugin และ QA ของแพ็กเกจ Telegram โดยใช้ tarball ที่แก้ไขแล้วชุดเดียวกัน การตรวจสอบรีลีสแบบบล็อกจะใช้ baseline ของแพ็กเกจล่าสุดที่เผยแพร่ตามค่าเริ่มต้น ส่วนโปรไฟล์ beta ที่ใช้ `run_release_soak=true`, `release_profile=stable` หรือ `release_profile=full` จะขยายการกวาดตรวจผู้รอดจากการอัปเกรดแพ็กเกจที่เผยแพร่แล้วไปยัง `last-stable-4` รวมถึง baseline ที่ปักหมุด `2026.4.23`, `2026.5.2` และ `2026.4.15` พร้อมสถานการณ์ `reported-issues` ใช้ Package Acceptance กับ `source=npm` สำหรับ candidate ที่เผยแพร่แล้ว, `source=ref` สำหรับ tarball npm ภายในเครื่องที่อิง SHA ก่อนเผยแพร่, `source=trusted-url` สำหรับมิเรอร์องค์กร/ส่วนตัวที่ผู้ดูแลเป็นเจ้าของ หรือ `source=artifact` สำหรับ tarball ที่เตรียมไว้และอัปโหลดโดยการรัน GitHub Actions อื่น

กล่องนี้เป็นตัวแทนแบบ GitHub-native สำหรับความครอบคลุมการทดสอบแพ็กเกจ/อัปเดตส่วนใหญ่ที่ก่อนหน้านี้ต้องใช้ Parallels การตรวจสอบรีลีสข้ามระบบปฏิบัติการยังสำคัญต่อการเริ่มต้นใช้งาน ตัวติดตั้ง และพฤติกรรมเฉพาะแพลตฟอร์ม แต่การตรวจสอบผลิตภัณฑ์ด้านแพ็กเกจ/อัปเดตควรเลือกใช้ Package Acceptance

รายการตรวจสอบมาตรฐานสำหรับการตรวจสอบอัปเดตและ Plugin คือ [การทดสอบอัปเดตและ Plugin](/th/help/testing-updates-plugins) ใช้รายการนี้เมื่อตัดสินใจว่าเลนภายในเครื่อง, Docker, Package Acceptance หรือการตรวจสอบรีลีสใดสามารถพิสูจน์การติดตั้ง/อัปเดต Plugin, การล้างข้อมูลโดย doctor หรือการเปลี่ยนแปลง migration ของแพ็กเกจที่เผยแพร่แล้วได้ การย้ายข้อมูลอัปเดตที่เผยแพร่แล้วอย่างละเอียดจากทุกแพ็กเกจ stable `2026.4.23+` เป็นเวิร์กโฟลว์แบบแมนนวล `Update Migration` ที่แยกต่างหาก และไม่ได้เป็นส่วนหนึ่งของ Full Release CI

การผ่อนปรนของ package-acceptance แบบเดิมถูกจำกัดเวลาโดยเจตนา แพ็กเกจจนถึง `2026.4.25` อาจใช้เส้นทางความเข้ากันได้สำหรับช่องว่างของข้อมูลเมตาที่เผยแพร่ไปยัง npm แล้ว ได้แก่ รายการสินค้าคงคลัง QA แบบ private ที่ไม่มีใน tarball, ไม่มี `gateway install --wrapper`, ไม่มีไฟล์ patch ใน fixture git ที่ได้จาก tarball, ไม่มี `update.channel` ที่จัดเก็บอย่างถาวร, ตำแหน่งระเบียนการติดตั้ง Plugin แบบเดิม, ไม่มีการจัดเก็บระเบียนการติดตั้ง marketplace อย่างถาวร และ migration ของข้อมูลเมตาการกำหนดค่าระหว่าง `plugins update` แพ็กเกจ `2026.4.26` ที่เผยแพร่แล้วอาจแจ้งเตือนเรื่องไฟล์ตราประทับข้อมูลเมตาของ build ภายในเครื่องที่เผยแพร่ไปแล้ว แพ็กเกจหลังจากนั้นต้องเป็นไปตามสัญญาแพ็กเกจสมัยใหม่ ช่องว่างเดิมเหล่านั้นจะทำให้การตรวจสอบรีลีสล้มเหลว

ใช้โปรไฟล์ Package Acceptance ที่กว้างขึ้นเมื่อคำถามเกี่ยวกับรีลีสเป็นเรื่องของแพ็กเกจที่ติดตั้งได้จริง:

```bash
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 published_upgrade_survivor_baseline=openclaw@2026.4.26
```

โปรไฟล์แพ็กเกจที่ใช้บ่อย:

- `smoke`: เลนสำหรับการติดตั้งแพ็กเกจ/ช่องทาง/เอเจนต์อย่างรวดเร็ว เครือข่าย Gateway และการโหลดการกำหนดค่าใหม่
- `package`: สัญญาการติดตั้ง/อัปเดต/รีสตาร์ต/แพ็กเกจ Plugin พร้อมหลักฐานการติดตั้ง Skills จาก ClawHub แบบสด; นี่คือค่าเริ่มต้นของการตรวจสอบรีลีส
- `product`: `package` พร้อมช่องทาง MCP, การล้าง cron/เอเจนต์ย่อย, การค้นหาเว็บของ OpenAI และ OpenWebUI
- `full`: ส่วนย่อยของเส้นทางรีลีส Docker พร้อม OpenWebUI
- `custom`: รายการ `docker_lanes` ที่ตรงตามที่กำหนดสำหรับการรันซ้ำแบบเจาะจง

สำหรับหลักฐาน Telegram ของแพ็กเกจที่เป็นตัวเลือก ให้เปิดใช้ `telegram_mode=mock-openai` หรือ `telegram_mode=live-frontier` ใน Package Acceptance เวิร์กโฟลว์จะส่ง tarball `package-under-test` ที่ได้รับการระบุแล้วไปยังเลน Telegram; เวิร์กโฟลว์ Telegram แบบสแตนด์อโลนยังคงยอมรับข้อมูลจำเพาะ npm ที่เผยแพร่แล้วสำหรับการตรวจสอบหลังเผยแพร่

## ระบบอัตโนมัติสำหรับการเผยแพร่รีลีสตามปกติ

สำหรับการเผยแพร่เบตา, `latest`, Plugin, GitHub Release และแพลตฟอร์ม
`OpenClaw Release Publish` คือจุดเริ่มต้นปกติที่มีการเปลี่ยนแปลงข้อมูล เส้นทาง extended-stable รายเดือน
`.33+` ซึ่งใช้เฉพาะ npm ไม่ใช้ตัวประสานงานนี้
เวิร์กโฟลว์ปกติจะประสานเวิร์กโฟลว์ trusted-publisher ตามลำดับที่
รีลีสต้องการ:

1. เช็กเอาต์แท็กรีลีสและระบุ SHA ของคอมมิต
2. ตรวจสอบว่าแท็กเข้าถึงได้จาก `main` หรือ `release/*` (หรือสาขาอัลฟาของ Tideclaw สำหรับอัลฟาพรีรีลีส)
3. รัน `pnpm plugins:sync:check`
4. สั่งรัน `Plugin NPM Release` ด้วย `publish_scope=all-publishable` และ `ref=<release-sha>`
5. สั่งรัน `Plugin ClawHub Release` ด้วยขอบเขตและ SHA เดียวกัน
6. สั่งรัน `OpenClaw NPM Release` ด้วยแท็กรีลีส, npm dist-tag และ `preflight_run_id` ที่บันทึกไว้ หลังจากตรวจสอบ `full_release_validation_run_id` ที่บันทึกไว้และครั้งที่รันอย่างตรงกัน
7. สำหรับรีลีสเสถียร ให้สร้างหรืออัปเดต GitHub release เป็นฉบับร่าง สั่งรัน `Windows Node Release` ด้วย `windows_node_tag` ที่ระบุชัดเจนและ `windows_node_installer_digests` ที่ตัวเลือกได้รับการอนุมัติ และตรวจสอบแอสเซ็ตตัวติดตั้ง/เช็กซัม Windows มาตรฐาน นอกจากนี้ ให้สั่งรัน `Android Release` เพื่อสร้าง APK ที่ลงนามแล้วจากแท็กที่ตรงกัน พร้อมเช็กซัมและข้อมูลแหล่งที่มา ตรวจสอบสัญญาแอสเซ็ตเนทีฟทั้งสองก่อนเผยแพร่ฉบับร่าง

ตัวอย่างการเผยแพร่เบตา:

```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
```

การเผยแพร่รีลีสเสถียรไปยัง beta dist-tag เริ่มต้น:

```bash
gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -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
```

การเลื่อนรีลีสเสถียรไปยัง `latest` โดยตรงต้องระบุอย่างชัดเจน:

```bash
gh workflow run openclaw-release-publish.yml \
  --ref main \
  -f tag=vYYYY.M.PATCH \
  -f windows_node_tag=vX.Y.Z \
  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \
  -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=latest
```

ใช้เวิร์กโฟลว์ระดับล่าง `Plugin NPM Release` และ `Plugin ClawHub Release` เฉพาะสำหรับงานซ่อมแซมหรือเผยแพร่ซ้ำแบบเจาะจงเท่านั้น `OpenClaw Release Publish` จะปฏิเสธ `plugin_publish_scope=selected` เมื่อ `publish_openclaw_npm=true` เพื่อไม่ให้แพ็กเกจหลักจัดส่งโดยไม่มี Plugin ทางการที่เผยแพร่ได้ครบทุกตัว รวมถึง `@openclaw/diffs-language-pack` สำหรับการซ่อมแซม Plugin ที่เลือก ให้ตั้งค่า `publish_openclaw_npm=false` พร้อม `plugin_publish_scope=selected` และ `plugins=@openclaw/name` หรือสั่งรันเวิร์กโฟลว์ลูกโดยตรง

การบูตสแตรป ClawHub สำหรับการเผยแพร่ครั้งแรกเป็นข้อยกเว้น: สั่งรัน `Plugin ClawHub New`
จาก `main` ที่เชื่อถือได้ และส่ง SHA เต็มของรีลีสเป้าหมายผ่าน `ref`
ห้ามรันเวิร์กโฟลว์บูตสแตรปจากแท็กหรือสาขารีลีสโดยตรง:

```bash
gh workflow run plugin-clawhub-new.yml \
  --ref main \
  -f plugins=@openclaw/name \
  -f ref=<full-40-character-release-sha> \
  -f pretag_validation=true \
  -f dry_run=true
```

การตรวจสอบก่อนสร้างแท็กกำหนดให้ใช้ `dry_run=true` ปฏิเสธอินพุตแท็กรีลีสและการรันแม่
และยอมรับเฉพาะเป้าหมายที่ตรงกันและเข้าถึงได้จาก `main` หรือ `release/*`
โดยจะไม่โหลดข้อมูลประจำตัว ClawHub, เผยแพร่ไบต์ของแพ็กเกจ หรือเปลี่ยนการกำหนดค่า
trusted publisher เวิร์กโฟลว์ยังคงระบุแผนรีจิสทรีจริง
เช็กเอาต์และแพ็กเป้าหมายเฉพาะในงานที่ไม่มีข้อมูลลับ จัดเตรียม
ชุดเครื่องมือ ClawHub ที่ล็อกไว้ และตรวจสอบอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้และ
สลัก/ข้อมูลประจำตัวของแพ็กเกจก่อนมีแท็กรีลีส อนุมัติสภาพแวดล้อม
`clawhub-plugin-bootstrap` หลังจากงานแพ็กที่ไม่มีข้อมูลลับ
เสร็จสิ้นแล้วเท่านั้น; งานตรวจสอบที่ได้รับการป้องกันนี้ไม่มีข้อมูลประจำตัวหรือคำสั่งเปลี่ยนแปลงข้อมูล

การทดลองรันที่ได้รับอนุมัติหรือการบูตสแตรปจริงหลังสร้างแท็กต้องระบุ
แท็กรีลีสที่ตรงกัน พร้อม ID การรัน, ครั้งที่รัน และ
สาขาของ `OpenClaw Release Publish` แม่ ตัวแม่รับรอง SHA ของเวิร์กโฟลว์ตนเองและ SHA ที่เชื่อถือได้ซึ่งตรงกัน
แยกต่างหากของ `main` สำหรับ `Plugin ClawHub New`; การรันลูกและการอนุมัติ
สภาพแวดล้อมที่ได้รับการป้องกันทุกรายการต้องตรงกับ SHA ของลูกที่ได้รับอนุมัตินั้น แท็กรีลีสจะได้รับ
การตรวจสอบซ้ำก่อนการพยายามเผยแพร่และการเปลี่ยนแปลง trusted-publisher ทุกครั้ง

งานแพ็ก
อัปโหลดอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้หนึ่งรายการ โดยส่งชื่อ, ID/ไดเจสต์ของอาร์ติแฟกต์ Actions,
การรัน/ครั้งที่รันของผู้สร้าง, SHA เป้าหมาย และ SHA-256/ขนาดของ tarball ต่อแพ็กเกจ
ไปยังงานตรวจสอบและงานที่ได้รับการป้องกัน งานที่ได้รับการป้องกันจะเช็กเอาต์เฉพาะเครื่องมือ `main`
ที่เชื่อถือได้ ตรวจสอบทูเพิลของอาร์ติแฟกต์ผ่าน GitHub API ดาวน์โหลด
ด้วย ID อาร์ติแฟกต์ที่ตรงกัน แฮช tarball ทุกไฟล์ซ้ำ และตรวจสอบพาธ TAR ภายในเครื่องและ
ข้อมูลประจำตัวของแพ็กเกจด้วยกฎการทำให้ USTAR เป็นรูปแบบมาตรฐานของ CLI ที่ปักหมุดไว้ จากนั้นตัวเลือก
ทุกรายการจะผ่านการทดลองเผยแพร่ของ CLI ที่ปักหมุดไว้ ซึ่งจะส่งคืนผลก่อน
การค้นหารีจิสทรีหรือการตรวจสอบสิทธิ์ ตัวกรองล่วงหน้าของงานข้อมูลประจำตัวจำกัด ClawPack ที่บีบอัดไว้
ที่ 120 MiB, เพย์โหลดไฟล์รวมที่ 50 MiB, ข้อมูล TAR เมื่อขยายแล้วที่ 64 MiB และ
จำนวนรายการ TAR ที่ 10,000 การซ่อมแซม trusted-publisher ของแพ็กเกจที่มีอยู่ยังคง
เป็นการกำหนดค่าเท่านั้น แต่ยังคงแพ็กเป้าหมายและกำหนดให้แท็กที่ร้องขอ
ตรงกับไบต์และเมทาดาทาของรีจิสทรีอย่างสมบูรณ์ก่อนเปลี่ยนการกำหนดค่า trusted-publisher
การตรวจสอบหลังเผยแพร่จะดาวน์โหลดอาร์ติแฟกต์ ClawHub และ
กำหนดให้ SHA-256 และขนาดตรงกัน การกู้คืนด้วยการรันงานที่ล้มเหลวซ้ำอาจใช้อาร์ติแฟกต์แพ็กเกจ
จากครั้งก่อนหน้าได้เฉพาะเมื่องานผู้สร้างที่ตรงกันเสร็จสมบูรณ์
สำเร็จแล้วเท่านั้น หลักฐานขั้นสุดท้ายยังผูกเวอร์ชัน ClawHub ที่ล็อกไว้, SHA-256 ของล็อก
และความสมบูรณ์ของ npm หากไม่ตรงกันต้องใช้แพ็กเกจเวอร์ชันใหม่

## อินพุตเวิร์กโฟลว์ NPM

`OpenClaw NPM Release` ยอมรับอินพุตที่ควบคุมโดยผู้ปฏิบัติงานดังต่อไปนี้:

- `tag`: แท็กรีลีสที่จำเป็น เช่น `v2026.4.2`, `v2026.4.2-1`, `v2026.4.2-beta.1` หรือ `v2026.4.2-alpha.1`; เมื่อ `preflight_only=true` ค่านี้อาจเป็น SHA ของคอมมิตปัจจุบันบนสาขาเวิร์กโฟลว์แบบเต็ม 40 อักขระสำหรับการตรวจสอบก่อนดำเนินการเท่านั้น
- `preflight_only`: `true` สำหรับการตรวจสอบ/บิลด์/แพ็กเกจเท่านั้น, `false` สำหรับเส้นทางเผยแพร่จริง
- `preflight_run_id`: ID การรันก่อนดำเนินการที่สำเร็จและมีอยู่แล้ว ซึ่งจำเป็นในเส้นทางเผยแพร่จริง เพื่อให้เวิร์กโฟลว์นำ tarball ที่เตรียมไว้กลับมาใช้แทนการสร้างใหม่
- `full_release_validation_run_id`: ID การรัน `Full Release Validation` ที่สำเร็จสำหรับแท็ก/SHA นี้ ซึ่งจำเป็นสำหรับการเผยแพร่จริง การเผยแพร่เบตาอาจดำเนินต่อโดยมีเพียงการตรวจสอบก่อนดำเนินการพร้อมคำเตือน แต่การเลื่อนรีลีสเสถียร/`latest` ยังคงจำเป็นต้องใช้ค่านี้
- `full_release_validation_run_attempt`: ครั้งที่รันซึ่งเป็นจำนวนบวกที่ตรงกันและจับคู่กับ `full_release_validation_run_id`; จำเป็นทุกครั้งที่ระบุ ID การรัน เพื่อไม่ให้การรันซ้ำเปลี่ยนหลักฐานการอนุญาตระหว่างการเผยแพร่
- `release_publish_run_id`: ID การรัน `OpenClaw Release Publish` ที่ได้รับอนุมัติ; จำเป็นเมื่อเวิร์กโฟลว์นี้ถูกสั่งรันโดยตัวแม่นั้น (การเรียกเผยแพร่จริงโดยตัวกระทำที่เป็นบอต)
- `plugin_npm_run_id`: ID การรัน `Plugin NPM Release` ที่ส่วนหัวตรงกันและสำเร็จ; จำเป็นสำหรับการเผยแพร่หลัก `extended-stable` จริง
- `npm_dist_tag`: แท็กเป้าหมาย npm สำหรับเส้นทางเผยแพร่; ยอมรับ `alpha`, `beta`, `latest` หรือ `extended-stable` และมีค่าเริ่มต้นเป็น `beta` แพตช์สุดท้าย `33` และใหม่กว่าต้องใช้ `extended-stable`; โดยค่าเริ่มต้น `extended-stable` จะปฏิเสธแพตช์ก่อนหน้า และจะปฏิเสธแท็กที่ไม่ใช่แท็กสุดท้ายเสมอ
- `bypass_extended_stable_guard`: ค่าบูลีนสำหรับการทดสอบเท่านั้น มีค่าเริ่มต้นเป็น `false`; เมื่อใช้กับ `npm_dist_tag=extended-stable` จะข้ามเกณฑ์คุณสมบัติ extended-stable รายเดือน โดยยังคงการตรวจสอบข้อมูลประจำตัวรีลีส, อาร์ติแฟกต์, การอนุมัติ และการอ่านกลับไว้

`Plugin NPM Release` ยอมรับ `npm_dist_tag=default` สำหรับพฤติกรรมรีลีส
ที่มีอยู่ หรือ `npm_dist_tag=extended-stable` สำหรับเส้นทางรายเดือนที่มีการป้องกัน
ตัวเลือก extended-stable กำหนดให้ใช้ `publish_scope=all-publishable`, มีอินพุต
`plugins` ว่าง, เป็นแพตช์สุดท้ายที่ `33` หรือสูงกว่า และอยู่บนสาขา
`extended-stable/YYYY.M.33` มาตรฐานที่ส่วนปลายตรงกัน โดยจะไม่ย้าย
`latest` หรือ `beta` ของ Plugin แพ็กเกจเวอร์ชันใหม่จะได้รับ `extended-stable` แบบอะตอม
ผ่านการเผยแพร่ที่เชื่อถือได้ด้วย OIDC (`npm publish --tag extended-stable`); เวิร์กโฟลว์ต้นทางนี้
ไม่ใช้ `npm dist-tag add` ที่ตรวจสอบสิทธิ์ด้วยโทเค็น การลองใหม่
จะข้ามเวอร์ชันที่ตรงกันซึ่งมีอยู่แล้วใน npm จากนั้นจะล้มเหลวแบบปิด เว้นแต่การอ่านกลับอย่างสมบูรณ์
จะยืนยันว่าทุกแพ็กเกจและแท็ก `extended-stable` ที่ตรงกันได้ลู่เข้าสู่สถานะเดียวกันแล้ว

`OpenClaw Release Publish` ยอมรับอินพุตที่ควบคุมโดยผู้ปฏิบัติงานดังต่อไปนี้:

- `tag`: แท็กรีลีสที่จำเป็น; ต้องมีอยู่แล้ว
- `preflight_run_id`: ID การรันก่อนดำเนินการ `OpenClaw NPM Release` ที่สำเร็จ; จำเป็นเมื่อ `publish_openclaw_npm=true` หรือ `plugin_publish_scope=all-publishable`
- `full_release_validation_run_id`: ID การรัน `Full Release Validation` ที่สำเร็จ; จำเป็นเมื่อ `publish_openclaw_npm=true` หรือ `plugin_publish_scope=all-publishable`
- `full_release_validation_run_attempt`: ครั้งที่รันซึ่งเป็นจำนวนบวกที่ตรงกันและจับคู่กับ `full_release_validation_run_id`; จำเป็นทุกครั้งที่ระบุ ID การรัน
- `windows_node_tag`: แท็กรีลีส `openclaw/openclaw-windows-node` ที่ไม่ใช่พรีรีลีสและตรงกัน; จำเป็นสำหรับการเผยแพร่ OpenClaw แบบเสถียร
- `windows_node_installer_digests`: แมป JSON แบบกะทัดรัดที่ตัวเลือกได้รับการอนุมัติ ซึ่งแมปชื่อตัวติดตั้ง Windows ปัจจุบันกับไดเจสต์ `sha256:` ที่ปักหมุดไว้; จำเป็นสำหรับการเผยแพร่ OpenClaw แบบเสถียร
- `npm_telegram_run_id`: ID การรัน `NPM Telegram Beta E2E` ที่สำเร็จและเป็นตัวเลือก เพื่อรวมไว้ในหลักฐานรีลีสขั้นสุดท้าย
- `npm_dist_tag`: แท็กเป้าหมาย npm สำหรับแพ็กเกจ OpenClaw ซึ่งเป็นหนึ่งใน `alpha`, `beta` หรือ `latest`
- `plugin_publish_scope`: มีค่าเริ่มต้นเป็น `all-publishable`; ใช้ `selected` เฉพาะสำหรับงานซ่อมแซม Plugin แบบเจาะจงเท่านั้นพร้อมกับ `publish_openclaw_npm=false`
- `plugins`: ชื่อแพ็กเกจ `@openclaw/*` ที่คั่นด้วยจุลภาค เมื่อ `plugin_publish_scope=selected`
- `publish_openclaw_npm`: มีค่าเริ่มต้นเป็น `true`; ตั้งเป็น `false` เฉพาะเมื่อใช้เวิร์กโฟลว์เป็นตัวประสานงานการซ่อมแซมเฉพาะ Plugin
- `release_profile`: โปรไฟล์ความครอบคลุมของรีลีสที่ใช้สำหรับสรุปหลักฐานรีลีส; มีค่าเริ่มต้นเป็น `from-validation` ซึ่งอ่านค่าจากแมนิเฟสต์การตรวจสอบ หรือแทนที่ด้วย `beta`, `stable` หรือ `full`
- `wait_for_clawhub`: มีค่าเริ่มต้นเป็น `false` เพื่อไม่ให้ความพร้อมใช้งานของ npm ถูกบล็อกโดยไซด์คาร์ ClawHub; ตั้งเป็น `true` เฉพาะเมื่อการเสร็จสิ้นเวิร์กโฟลว์ต้องรวมการเสร็จสิ้นของ ClawHub ด้วย

`OpenClaw Release Checks` ยอมรับอินพุตที่ควบคุมโดยผู้ปฏิบัติงานดังต่อไปนี้:

- `ref`: แบรนช์ แท็ก หรือ SHA ของคอมมิตแบบเต็มที่จะตรวจสอบ การตรวจสอบที่ใช้ข้อมูลลับกำหนดให้คอมมิตที่แก้ไขแล้วต้องเข้าถึงได้จากแบรนช์หรือแท็กรีลีสของ OpenClaw
- `run_release_soak`: เลือกใช้การทดสอบสด/E2E แบบครอบคลุม เส้นทางรีลีส Docker และการทดสอบ soak การอยู่รอดหลังอัปเกรดทั้งหมดนับตั้งแต่ต้นสำหรับการตรวจสอบรีลีสเบตา ตัวเลือกนี้จะถูกบังคับเปิดโดย `release_profile=stable` และ `release_profile=full`

กฎ:

- เวอร์ชันสุดท้ายและเวอร์ชันแก้ไขปกติที่มีแพตช์ต่ำกว่า `33` สามารถเผยแพร่ไปยัง `beta` หรือ `latest` ได้ เวอร์ชันสุดท้ายที่มีแพตช์ `33` ขึ้นไปต้องเผยแพร่ไปยัง `extended-stable` และเวอร์ชันที่มีส่วนต่อท้ายสำหรับการแก้ไข ณ ขอบเขตดังกล่าวจะถูกปฏิเสธ
- แท็กพรีรีลีสเบตาสามารถเผยแพร่ไปยัง `beta` เท่านั้น ส่วนแท็กพรีรีลีสอัลฟาสามารถเผยแพร่ไปยัง `alpha` เท่านั้น
- สำหรับ `OpenClaw NPM Release` อนุญาตให้ป้อน SHA ของคอมมิตแบบเต็มได้เฉพาะเมื่อ `preflight_only=true`
- `OpenClaw Release Checks` และ `Full Release Validation` ใช้สำหรับการตรวจสอบเท่านั้นเสมอ
- เส้นทางเผยแพร่จริงต้องใช้ `npm_dist_tag` เดียวกับที่ใช้ระหว่างการตรวจสอบก่อนเริ่มงาน โดยเวิร์กโฟลว์จะตรวจสอบข้อมูลเมตาดังกล่าวก่อนดำเนินการเผยแพร่ต่อ

## ลำดับการรีลีสเบตา/เสถียรล่าสุดแบบปกติ

ลำดับแบบเดิมนี้ใช้สำหรับรีลีสแบบประสานงานปกติ ซึ่งยังครอบคลุม Plugin, GitHub Release, Windows และงานสำหรับแพลตฟอร์มอื่นด้วย ไม่ใช่เส้นทางเสถียรระยะยาวแบบ npm เท่านั้นรายเดือน `.33+` ที่จัดทำเอกสารไว้ด้านบนของหน้านี้

เมื่อจัดทำรีลีสเสถียรแบบประสานงานปกติ:

1. เรียกใช้ `OpenClaw NPM Release` พร้อม `preflight_only=true` ก่อนที่จะมีแท็ก สามารถใช้ SHA ของคอมมิตแบบเต็มปัจจุบันของแบรนช์เวิร์กโฟลว์เพื่อทดลองรันเวิร์กโฟลว์ตรวจสอบก่อนเริ่มงานสำหรับการตรวจสอบเท่านั้น
2. เลือก `npm_dist_tag=beta` สำหรับขั้นตอนปกติที่เริ่มจากเบตา หรือเลือก `latest` เฉพาะเมื่อตั้งใจเผยแพร่เวอร์ชันเสถียรโดยตรง
3. เรียกใช้ `Full Release Validation` บนแบรนช์รีลีส แท็กรีลีส หรือ SHA ของคอมมิตแบบเต็ม เมื่อต้องการ CI ปกติพร้อมการครอบคลุมแคชพรอมต์แบบสด, Docker, QA Lab, Matrix และ Telegram จากเวิร์กโฟลว์แบบเรียกใช้ด้วยตนเองรายการเดียว หากตั้งใจต้องการเฉพาะกราฟการทดสอบปกติที่ให้ผลลัพธ์แน่นอน ให้เรียกใช้เวิร์กโฟลว์ `CI` แบบเรียกใช้ด้วยตนเองบนรีลีส ref แทน
4. เลือกแท็กรีลีส `openclaw/openclaw-windows-node` ที่ไม่ใช่พรีรีลีสอย่างเจาะจง ซึ่งควรจัดส่งตัวติดตั้ง x64 และ ARM64 ที่ลงนามแล้ว บันทึกแท็กดังกล่าวเป็น `windows_node_tag` และบันทึกแมปไดเจสต์ที่ผ่านการตรวจสอบเป็น `windows_node_installer_digests` ตัวช่วยรีลีสแคนดิเดตจะบันทึกทั้งสองรายการและรวมไว้ในคำสั่งเผยแพร่ที่สร้างขึ้น
5. บันทึก `preflight_run_id`, `full_release_validation_run_id` ที่สำเร็จ และ `full_release_validation_run_attempt` ที่ตรงกันทุกประการ
6. เรียกใช้ `OpenClaw Release Publish` จาก `main` ที่เชื่อถือได้ โดยใช้ `tag` เดิม, `npm_dist_tag` เดิม, `windows_node_tag` ที่เลือก, `windows_node_installer_digests` ที่บันทึกไว้ของรายการนั้น, `preflight_run_id` ที่บันทึกไว้, `full_release_validation_run_id` และ `full_release_validation_run_attempt` ระบบจะเผยแพร่ Plugin ที่แยกออกไปยัง npm และ ClawHub ก่อนโปรโมตแพ็กเกจ OpenClaw บน npm
7. หากรีลีสลงที่ `beta` ให้ใช้เวิร์กโฟลว์ `openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml` เพื่อโปรโมตเวอร์ชันเสถียรนั้นจาก `beta` ไปยัง `latest`
8. หากตั้งใจเผยแพร่รีลีสไปยัง `latest` โดยตรง และ `beta` ควรใช้บิลด์เสถียรเดียวกันทันที ให้ใช้เวิร์กโฟลว์รีลีสเดียวกันนั้นเพื่อชี้ dist-tag ทั้งสองไปยังเวอร์ชันเสถียร หรือปล่อยให้การซิงค์ซ่อมแซมตนเองตามกำหนดการย้าย `beta` ในภายหลัง

การเปลี่ยนแปลง dist-tag อยู่ในรีโพซิทอรีบัญชีแยกประเภทรีลีส เนื่องจากยังคงต้องใช้ `NPM_TOKEN` ขณะที่รีโพซิทอรีซอร์สยังคงใช้การเผยแพร่แบบ OIDC เท่านั้น วิธีนี้ทำให้ทั้งเส้นทางเผยแพร่โดยตรงและเส้นทางโปรโมตที่เริ่มจากเบตามีเอกสารกำกับและผู้ปฏิบัติงานมองเห็นได้

หากผู้ดูแลต้องเปลี่ยนไปใช้การยืนยันตัวตน npm ภายในเครื่อง ให้เรียกใช้คำสั่ง 1Password CLI (`op`) ภายในเซสชัน tmux เฉพาะเท่านั้น ห้ามเรียก `op` โดยตรงจากเชลล์หลักของเอเจนต์ การเก็บไว้ภายใน tmux ทำให้สามารถสังเกตพรอมต์ การแจ้งเตือน และการจัดการ OTP ได้ และป้องกันการแจ้งเตือนซ้ำบนโฮสต์

## เอกสารอ้างอิงสาธารณะ

- [`.github/workflows/full-release-validation.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/full-release-validation.yml)
- [`.github/workflows/package-acceptance.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/package-acceptance.yml)
- [`.github/workflows/openclaw-npm-release.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-npm-release.yml)
- [`.github/workflows/openclaw-release-checks.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-release-checks.yml)
- [`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-cross-os-release-checks-reusable.yml)
- [`scripts/resolve-openclaw-package-candidate.mjs`](https://github.com/openclaw/openclaw/blob/main/scripts/resolve-openclaw-package-candidate.mjs)
- [`scripts/openclaw-npm-release-check.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/openclaw-npm-release-check.ts)
- [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
- [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)

ผู้ดูแลใช้เอกสารรีลีสส่วนตัวใน [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) เป็นคู่มือปฏิบัติงานจริง

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

- [ช่องทางรีลีส](/th/install/development-channels)
