Copilot CLI 1.0.103 เลิกธง remote เดิม ทีมใช้สคริปต์ควรเช็กก่อนอัปเดต

GitHub Copilot CLI 1.0.103 ออกวันที่ 22 ตุลาคม 2026 พร้อมเลิกใช้ตัวเลือกเริ่มโปรแกรม --remote และ --no-remote แบบเดิม ซึ่งคนที่ผูกคำสั่งเหล่านี้ไว้กับงานประจำควรตรวจสอบก่อนอัปเดต (GitHub Releases) สำหรับทีมที่ให้ AI ช่วยทำงานในเครื่อง ประเด็นนี้เกี่ยวกับทั้งเวลาที่อาจเสียไปกับการแก้คำสั่งเก่า และการทบทวนว่าเรายอมให้ผู้ช่วยเข้าถึงงานได้แค่ไหนครับ

รอบนี้ยังแก้การใช้ค่าจำกัดสิทธิ์ที่บันทึกไว้เมื่อกลับมาทำงานต่อ และแก้ข้อความตอบกลับจากคลาวด์หลังการเชื่อมต่อหลุด จึงเป็นอัปเดตเรื่องความต่อเนื่องของงานและขอบเขตการทำงานด้วย (GitHub Changelog) แต่ชื่อของตัวเลือกใหม่ที่ใช้แทนธง remote เดิมยังไม่ปรากฏในข้อความแหล่งข่าวชุดนี้ ผมจึงจะไม่เดาคำสั่งให้เอาไปใช้ผิดเครื่อง

สรุป 30 วินาที: เกิดอะไรขึ้น

• รุ่นปกติ 1.0.103 ลงวันที่ 22 ตุลาคม 2026 ระบุว่าปรับตัวเลือกเปิดงานระยะไกลให้แยกเรื่องการเปิดให้เชื่อมต่อกับการเชื่อมต่อชัดขึ้น และเลิกธงเริ่มโปรแกรม remote แบบเก่า แต่ไม่ได้บอกชื่อธงใหม่ในรายการเปลี่ยนแปลงที่ให้มา (GitHub Releases)
• รุ่นก่อนเผยแพร่เต็ม 1.0.103-0 มีรายการเปลี่ยนแปลงชุดเดียวกัน โดย NewReleases แสดงรุ่นนี้ลงวันที่ 22 ตุลาคม 2026 เช่นกัน ต้องแยกเลขที่มีส่วนต่อท้ายออกจากรุ่นปกติให้ดี (NewReleases)
• งานแบบ ACP ซึ่งเป็นชื่อรูปแบบเซสชันที่ changelog ใช้ จะทำตามค่า sandbox ที่บันทึกไว้และธงเปิดหรือปิด sandbox รวมถึงตอนกลับเข้าเซสชันเดิมด้วย ส่วน sandbox คือสภาพแวดล้อมที่จำกัดขอบเขตการเข้าถึงของคำสั่ง (GitHub Changelog)
• ถ้าการเชื่อมต่อหลุดแล้ว CLI เชื่อมต่อใหม่ ข้อความตอบกลับจากคลาวด์จะเก็บเนื้อหาไว้ครบตามรายการแก้ไขของรุ่นนี้ (GitHub Releases)

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

ทำไมเรื่องนี้เกี่ยวกับคุณ

Copilot CLI คือผู้ช่วยเขียนโค้ดด้วย AI ที่ทำงานในเทอร์มินัล หรือหน้าต่างพิมพ์คำสั่งบนคอมพิวเตอร์ ตัวโครงการอธิบายว่านำความสามารถของ Copilot coding agent เข้ามาในเทอร์มินัล ขณะที่เอกสารมีทั้งการรันงานอัตโนมัติ การตั้งค่าสิทธิ์ และการใช้ sandbox จึงต้องพิจารณามากกว่าหน้าจอแชตตอบข้อความ (GitHub Releases, GitHub Docs) พูดให้เห็นภาพการใช้งานคือผู้ช่วยที่เกี่ยวข้องกับการสั่งทำงานและแก้โค้ดในโครงการ เราจึงควรคิดถึงสิทธิ์ของมันควบคู่กับความสะดวกเสมอ

คนที่ควรสนใจเป็นพิเศษคือผู้พัฒนาที่ใช้สคริปต์ หรือชุดคำสั่งที่เขียนให้ทำงานซ้ำ และ alias หรือชื่อย่อแทนคำสั่งยาว เพราะรุ่นนี้ประกาศเลิกตัวเลือกเริ่มโปรแกรมเดิมอย่างชัดเจน (GitHub Changelog) คำแนะนำของผมคืออย่าตรวจเฉพาะคำสั่งที่จำได้ว่าพิมพ์เอง ให้รวมคู่มือเริ่มงานและชุดคำสั่งที่ทีมส่งต่อกันด้วย

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

ผู้ดูแลทีมมีอีกจุดที่ต้องดู รุ่นนี้แก้การกลับเข้าเซสชันภายใต้ค่าเริ่มต้นของโมเดลที่ผู้ดูแลบังคับใช้ โดยไม่ปฏิเสธค่าความชอบที่บันทึกไว้ โมเดลในที่นี้หมายถึงระบบ AI ที่รับหน้าที่คิดและตอบ (GitHub Releases) ผมแนะนำให้ทดลองกับบัญชีและนโยบายของทีมจริงในพื้นที่ทดสอบ เพราะค่าที่ผู้ใช้เลือกกับค่าที่องค์กรกำหนดควรทำงานร่วมกันได้ตามที่ตั้งใจ

ทำงานยังไง

เซสชันคือช่วงการทำงานหรือบทสนทนาหนึ่งชุดที่กลับมาทำต่อได้ รุ่น 1.0.103 ปรับตัวเลือกเปิดงาน remote หรือการเชื่อมต่อระยะไกล โดยข้อความต้นทางใช้คำว่า hosting/connection flags และเลิกธง --remote กับ --no-remote ตอนเริ่มโปรแกรม (GitHub Changelog) ความหมายที่ยืนยันได้จึงมีเพียงว่าตัวเลือกฝั่งเปิดให้เชื่อมต่อและฝั่งเชื่อมต่อถูกทำให้ชัดขึ้น ยังไม่มีชื่อคำสั่งทดแทนให้ถอดตาม

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

ในทางสิทธิ์ ผมมองว่าการเข้าถึงจากระยะไกลเพิ่มจุดที่ต้องพิจารณาว่าใครเชื่อมต่อได้ และเมื่อเชื่อมต่อแล้วทำอะไรได้บ้าง อย่างไรก็ตาม ข้อความต้นทางชุดนี้ไม่ได้อธิบายวิธีควบคุมเซสชันผ่าน GitHub.com หรือ GitHub Mobile จึงยังใช้ยืนยันช่องทางควบคุมเหล่านั้นหรือขั้นตอนตั้งค่าไม่ได้ การเลิกธงเดิมก็ไม่ได้เป็นหลักฐานว่าความสามารถระยะไกลทั้งหมดถูกยกเลิก เพราะ changelog ระบุว่าปรับตัวเลือกเปิดงานให้ชัดขึ้น (GitHub Releases)

อีกส่วนคือการจำขอบเขต sandbox งาน ACP ในรุ่นนี้จะเคารพค่าที่บันทึกไว้และตัวเลือก --sandbox หรือ --no-sandbox แม้กลับมาทำต่อ ขณะเดียวกันคำสั่งพัฒนา .NET บางส่วนใช้สิทธิ์ sandbox เดิมของ .NET และ NuGet ได้เมื่อเปิดสิทธิ์เครื่องมือพัฒนา และตัวเรียกเครื่องมือบน Windows อย่าง npm.cmd ได้รับสิทธิ์แบบเดียวกับ npm (GitHub Changelog) ใจความคือการให้สิทธิ์เดิมถูกนำไปใช้สม่ำเสมอขึ้น ไม่ควรตีความว่าเปิดสิทธิ์เครื่องมือพัฒนาแล้วปลอดภัยโดยอัตโนมัติ

จุดสังเกต: คำสั่งเลิกใช้ชัด แต่ชื่อที่มาแทนยังขาด

ประเด็นที่ต้องระวังที่สุดคือความต่างระหว่าง “รู้ว่าของเดิมเลิกใช้” กับ “รู้วิธีย้ายไปของใหม่” ทั้งหน้า Releases และ changelog ระบุการเลิกธงเดิมตรงกัน แต่บอกสิ่งที่มาแทนเพียงระดับหมวดว่าเป็นตัวเลือก hosting/connection ที่ชัดขึ้น ไม่มีชื่อธงใหม่หรือรูปแบบการย้ายคำสั่งในข้อความที่ได้รับ (GitHub Releases, GitHub Changelog) บทความนี้จึงให้คำสั่งทดแทนแบบคัดลอกไปใช้ไม่ได้

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

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

เรื่องเงิน / ผลกระทบ

แหล่งข้อมูลชุดนี้ไม่มีราคาแพ็กเกจไทย ราคาเงินบาท หรือประกาศเปลี่ยนค่าใช้บริการของรุ่น 1.0.103 จึงยังบอกไม่ได้ว่าค่าใช้จ่ายของผู้ใช้จะเพิ่มหรือลดเท่าไร สิ่งที่มีใน changelog รุ่นนี้คือการใช้ข้อมูลเครื่องมือ MCP ที่เก็บไว้ชั่วคราวร่วมกันระหว่าง Git worktrees ที่ลงทะเบียนอยู่ในโครงการเดียวกัน (GitHub Changelog) MCP คือช่องทางให้ AI เชื่อมกับเครื่องมืออื่น ส่วน worktree คือพื้นที่ทำงานแยกของโครงการ Git เดียวกัน ข้อมูลนี้ไม่ได้ให้ตัวเลขประหยัดเวลา เงิน หรือปริมาณการเรียก AI

ผลกระทบที่ผมแนะนำให้ทีมประเมินจึงเป็นเวลาทดสอบและแก้ชุดคำสั่งเริ่มงาน มากกว่าตั้งสมมติฐานว่าจะประหยัดค่าบริการ การเลิกธงเก่าทำให้การตรวจสคริปต์มีเหตุผลรองรับ แต่ต้นทางไม่ได้ระบุว่าสคริปต์ทุกรูปแบบจะเสียหรือรายงานจำนวนผู้ใช้ที่ได้รับผลกระทบ (GitHub Releases) ไม่ควรตีมูลค่าความเสียหายจากชื่ออัปเดตเพียงอย่างเดียว

ด้านความต่อเนื่อง รุ่นนี้แก้คำตอบคลาวด์ให้เก็บข้อความเต็มเมื่อเชื่อมต่อกลับมา และแก้การเรียกเครื่องมือของ Gemini ที่เคยเจอข้อผิดพลาดตรวจรูปแบบข้อมูลในช่องที่รับค่าว่างหรือชุดค่าที่กำหนดไว้ (GitHub Changelog) ข้อดีเชิงการใช้งานคือทีมมีกรณีทดสอบที่ชัดเจนขึ้น แต่ยังไม่มีผลวัดว่าลดงานสะดุดได้มากแค่ไหน

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันออกกับเลขรุ่น: หน้า Releases และ changelog ระบุรุ่นปกติ 1.0.103 วันที่ 22 ตุลาคม 2026 ส่วน NewReleases ระบุรุ่นก่อนเผยแพร่เต็ม v1.0.103-0 ในวันเดียวกัน นี่เป็นคนละเลขรุ่น ไม่ใช่หลักฐานว่าวันออกขัดกัน และไม่มีเวลาเผยแพร่พร้อมเขตเวลาให้จัดลำดับภายในวันได้ (GitHub Releases, GitHub Changelog, NewReleases) ข้อมูลที่ให้มาไม่มีรายการ npm หรือ AgentAtlas จึงไม่ได้ใช้สองแหล่งนั้นยืนยันเพิ่มเติม

ธงใหม่และเอกสาร: แหล่งประกาศตรงกันว่าเลิกธง remote เดิม แต่ยังไม่บอกชื่อธงทดแทน ส่วนข้อความจากหน้าเอกสารที่ได้รับไม่มีหัวข้อ remote ให้เปรียบเทียบ จึงยังยืนยันข้อสงสัยว่าเอกสารตามไม่ทันไม่ได้ (GitHub Changelog, GitHub Docs) จุดนี้ควรตรวจต่อก่อนแก้คู่มือทีม ไม่ควรเติมชื่อธงใหม่จากการคาดเดา

ขอบเขตผลกระทบ: ไม่มีข้อมูลผู้ใช้ไทยที่ได้รับผลกระทบ ไม่มีจำนวนเหตุการณ์ด้านความปลอดภัย และไม่มีผลทดสอบว่าแก้ปัญหาได้ครบทุกสภาพแวดล้อม รายการเปลี่ยนแปลงยืนยันสิ่งที่ผู้พัฒนาประกาศแก้ แต่ไม่ได้ให้หลักฐานรับรองผลในทุกเครื่อง (GitHub Releases) ผมจึงแยกคำแนะนำให้ทดสอบออกจากข้อเท็จจริงเรื่องรุ่นอย่างชัดเจน

แล้วเราควรทำอะไร

ผู้พัฒนาและคนมีสคริปต์เริ่มงาน

1. ตรวจเวอร์ชันที่ติดตั้งและแยก 1.0.103 ออกจาก 1.0.103-0 ให้ชัด เอกสารระบุว่ามีคำสั่งดูเวอร์ชันและตรวจอัปเดต จึงควรใช้ข้อมูลจากเครื่องประกอบการตัดสินใจ (GitHub Docs)
2. ทบทวนสคริปต์ ชื่อย่อ และคู่มือที่ใช้ธง remote เดิม เพราะรุ่นนี้ประกาศเลิกใช้แล้ว อย่าแทนด้วยชื่อธงที่ยังไม่มีหลักฐานในข้อความต้นทาง (GitHub Changelog)
3. ลองในโครงการทดลองที่ทิ้งได้ก่อน ตรวจทั้งเริ่มงานใหม่และกลับเข้าเซสชันเดิม โดยเฉพาะการคงค่า sandbox ที่รุ่นนี้ระบุว่าแก้ไขแล้ว (GitHub Releases) ผมแนะนำว่าอย่านำข้อมูลรับรองของระบบใช้งานจริงเข้าไปในการทดลอง

ผู้ดูแลทีมและฝ่ายไอที

1. ตรวจนโยบายโมเดลที่องค์กรบังคับกับค่าที่ผู้ใช้บันทึกไว้ และทดสอบการกลับเข้าเซสชัน เพราะเป็นกรณีที่มีการแก้ในรุ่นนี้ (GitHub Changelog)
2. แยกตรวจงานอัตโนมัติจากงานที่มีคนนั่งดู เอกสารระบุว่าคำสั่งรัน dynamic workflow หรือชุดงานอัตโนมัติที่ส่วนขยายจัดให้ ใช้ค่าการยืนยันตัวตน สิทธิ์ และ sandbox ของ CLI แต่ไม่แสดงหน้าถามอนุมัติสิทธิ์ (GitHub Docs) คำแนะนำคือกำหนดสิทธิ์ให้พอดีก่อนปล่อยงาน
3. บันทึกผลทดสอบว่าเปิดงานได้ กลับมาทำต่อได้ และขอบเขตการเข้าถึงตรงกับที่ตั้งใจ จากนั้นจึงปรับคู่มือทีมตามตัวเลือกใหม่ที่ตรวจยืนยันได้

เจ้าของธุรกิจ นักศึกษา และคนใช้ผ่านทีมงาน

1. ให้ผู้ดูแลอธิบายว่าผู้ช่วยเข้าถึงโครงการใดและใครรับผิดชอบตรวจผล โดยไม่จำเป็นต้องขอสิทธิ์กว้างขึ้นเพียงเพื่อผ่านขั้นตอนอัปเดต
2. หากมีการเสนอให้เชื่อมต่อระยะไกล ให้ขอคำอธิบายเรื่องผู้มีสิทธิ์เชื่อมต่อและวิธีจบการเข้าถึงก่อนเปิดใช้ นี่เป็นข้อแนะนำเรื่องการจัดการสิทธิ์ ไม่ใช่คำยืนยันว่ารุ่นนี้มีเหตุข้อมูลรั่ว
3. ให้เริ่มจากงานทดลองที่ไม่มีความลับหรือข้อมูลรับรองระบบจริง แล้วค่อยประเมินว่าขั้นตอนตรวจงานเหมาะกับทีมของเราหรือยัง

หลักฐานความปลอดภัยและความเสี่ยงที่ยังเหลือ

ที่มาและรุ่นที่ตรวจอ้างอิงได้: หลักฐานหลักคือ repository ทางการ github/copilot-cli หรือพื้นที่เผยแพร่โครงการของ GitHub พร้อมรายการรุ่น 1.0.103 ลงวันที่ 22 ตุลาคม 2026 และ changelog ที่ตรงกัน ส่วนหน้า NewReleases ใช้แท็ก v1.0.103-0 สำหรับรุ่นก่อนเผยแพร่เต็ม (GitHub Releases, GitHub Changelog, NewReleases) นี่ช่วยตรวจที่มาของประกาศ แต่ยังไม่ใช่การตรวจไฟล์ติดตั้งหรือการทดสอบความปลอดภัยด้วยตัวเอง

ประกาศช่องโหว่ที่มีในชุดข้อมูล: ข้อความที่ให้มาไม่ได้แสดงประกาศช่องโหว่หรือรหัส CVE สำหรับรุ่นนี้ การไม่พบในเอกสารชุดนี้จึงใช้รับรองว่าไม่มีช่องโหว่ทั้งหมดไม่ได้ รายการแก้เรื่อง sandbox และสิทธิ์เป็นข้อมูลพฤติกรรมที่ควรนำไปทดสอบ ไม่ใช่เหตุให้เรียกทุกรายการว่าเป็นการอุดช่องโหว่ (GitHub Releases)

สิทธิ์และการอนุมัติ: ข้อความรุ่น 1.0.100 ระบุว่า sandbox อนุญาตการเข้าถึงเครือข่ายภายในโดยค่าเริ่มต้น และโหมด Assisted ซึ่งช่วยตัดสินใจเรื่องสิทธิ์ อาจอนุญาตการกระทำที่จัดว่าปลอดภัยภายใต้นโยบายองค์กรโดยไม่ถามยืนยันที่ไม่จำเป็น ข้อมูลนี้เป็นพฤติกรรมที่บันทึกในรุ่นก่อนหน้า ไม่ใช่ฟีเจอร์ใหม่ของ 1.0.103 และยังไม่พอจะสรุปว่าทุกเครื่องตั้งค่าเหมือนกัน (GitHub Changelog) ส่วนเอกสาร workflow ยืนยันเฉพาะรูปแบบนั้นว่าไม่แสดงคำถามอนุมัติ จึงไม่ควรเหมารวมว่าทุกโหมดถามเหมือนกัน (GitHub Docs)

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

ผมมองว่า…

ผมมองว่า อัปเดตนี้มีคุณค่าในฐานะการทำให้ขั้นตอนทำงานและสิทธิ์สม่ำเสมอขึ้น ความเห็นของผมคือ ไม่ใช่แข่งกันอัปเดตให้เร็วที่สุด แต่คืออัปเดตแล้วรู้ว่างานยังอยู่ในขอบเขตที่ตั้งใจ โดยเฉพาะเมื่อรายการเดียวกันมีทั้งการจำ sandbox การใช้สิทธิ์เครื่องมือพัฒนา และการเปลี่ยนตัวเลือกเริ่มงานระยะไกล (GitHub Changelog)

ผมจะให้ความสำคัญกับการตรวจคำสั่งเก่าและทดลองกลับเข้าเซสชันก่อน ส่วนความสะดวกอย่างชื่อเซสชันที่ถูกต้องหรือข้อความตอบกลับที่ไม่ขาดหลังเชื่อมต่อใหม่ เป็นเหตุผลที่ดีในการนำรุ่นนี้ไปทดสอบ แต่ยังไม่พอให้ข้ามการตรวจสิทธิ์ (GitHub Releases) ทีมที่อธิบายได้ว่าผู้ช่วยทำอะไรได้บ้าง จะตัดสินใจใช้มันกับงานจริงได้มั่นใจกว่าทีมที่รู้เพียงว่าเปิดติดแล้ว

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่ต้องตรวจต่อคือชื่อและความหมายของตัวเลือก hosting/connection ที่มาแทนธงเดิม รวมถึงเอกสารและคู่มือทีมที่ตรงกับรุ่นติดตั้ง เพราะรายการเปลี่ยนแปลงที่มีอยู่ยังไม่ให้รายละเอียดการย้ายคำสั่ง (GitHub Changelog) สำหรับรอบนี้ ข้อแนะนำคือใช้รุ่นและที่มาที่ตรวจสอบได้เป็นจุดเริ่ม แล้วพิสูจน์ด้วยงานทดลองว่าการเริ่มงาน การกลับมาทำต่อ และขอบเขตสิทธิ์ทำงานตรงกับที่ทีมต้องการ

Recap

• แยกรุ่นปกติ 1.0.103 ออกจากรุ่นก่อนเผยแพร่เต็ม 1.0.103-0
• ตรวจสคริปต์และชื่อย่อที่ยังใช้ธง remote เดิม
• อย่าเดาชื่อธงทดแทนจากข้อความประกาศที่ยังไม่ระบุ
• ทดลองเริ่มงานและกลับเข้าเซสชันเพื่อตรวจค่า sandbox
• ตรวจนโยบายโมเดลและสิทธิ์ที่มีผลจริงกับบัญชีของทีม
• แยกพฤติกรรมอนุมัติของงานอัตโนมัติออกจากงานโต้ตอบ
• ทดลองในโครงการที่ทิ้งได้ โดยไม่ใช้ข้อมูลรับรองระบบจริง
• ยังไม่มีราคาไทย ตัวเลขผู้ได้รับผลกระทบ หรือหลักฐานรับรองว่าปลอดภัยทั้งหมดในข้อมูลชุดนี้