OpenSpec v1.13.1 อุดช่องที่ไฟล์ config ในรีโปสั่งงาน agent ได้ — เครื่องมือ spec-driven 68.7k ดาว เพิ่งยอมรับว่าการโคลนรีโปแปลกหน้าแล้วรัน คือพื้นผิวโจมตี

17 ก.ย. 2026 เวลา 01:11 UTC โปรเจกต์ OpenSpec ออกเวอร์ชัน v1.13.1 ชื่อรุ่นว่า “Hardened CLI, safer archives” โดยประโยคเปิดของ release note บอกวัตถุประสงค์ตรง ๆ ว่า “This release makes OpenSpec safer to run in repositories you have not reviewed yet”

ตัวโปรเจกต์เองไม่ใช่ของใหม่ — Fission-AI สร้าง repo นี้ตั้งแต่ 5 ส.ค. 2025 และวันนี้มันมี 68,763 ดาว บน GitHub ภายใต้ MIT ซึ่งทำให้มันเป็นหนึ่งในเครื่องมือ spec-driven development (SDD) ที่ใหญ่ที่สุดในระบบนิเวศ coding agent ตอนนี้ (เทียบชั้นกับ Spec Kit ของ GitHub และ Kiro ของ AWS ซึ่ง README ของ OpenSpec เอาไปเทียบตรง ๆ เอง) เราไม่เคยเขียนถึงมันมาก่อน และสิ่งที่ทำให้วันนี้เป็นจังหวะที่ควรเขียน ไม่ใช่ตัวฟีเจอร์ แต่คือสิ่งที่ release note ยอมรับว่าเคยทำได้

OpenSpec ทำอะไร

แนวคิดคือใส่ชั้นบาง ๆ ของ “ข้อตกลงว่าจะสร้างอะไร” เข้าไปก่อนที่ agent จะเขียนโค้ด แทนที่จะให้ requirement อยู่ใน chat history อย่างเดียว เวิร์กโฟลว์หลักเป็น slash command สามตัว:

• /opsx:propose <ไอเดีย> — สร้างโฟลเดอร์ openspec/changes/<ชื่อ>/ ที่มี proposal.md (ทำไม / เปลี่ยนอะไร), specs/ (requirement + scenario), design.md (แนวทางเทคนิค) และ tasks.md (เช็กลิสต์งาน)
• /opsx:apply — ให้ agent ลงมือทำตาม tasks.md
• /opsx:archive — เก็บ change ที่เสร็จแล้วเข้า archive และอัปเดต spec หลัก

spec เป็น Markdown ธรรมดา ไม่มีไวยากรณ์พิเศษให้เรียน — requirement เขียนด้วย SHALL และ scenario เขียนด้วย WHEN / THEN ติดตั้งด้วย npm install -g @fission-ai/openspec@latest แล้ว openspec init ต้องการ Node.js 20.19.0 ขึ้นไป และรองรับเครื่องมือมากกว่า 30 ตัว โดยชื่อคำสั่งต่างกันตามเครื่องมือ: /opsx-propose บน Cursor และ GitHub Copilot, @opsx-propose บน Amazon Q, $openspec-propose บน Codex

มีฟีเจอร์ชื่อ Stores (สถานะ beta) ที่ย้ายโฟลเดอร์ openspec/ ออกไปอยู่ในรีโปของตัวเอง เพื่อให้ฟีเจอร์ที่กินหลายรีโป (API server + web app + shared library) มีแผนเดียวที่ทุกทีมและทุก agent อ่านได้

สามช่องที่ v1.13.1 ปิด

หัวข้อ Security hardening ของ release note ระบุช่องไว้สามอย่าง อ่านทีละข้อแล้วจะเห็นว่ามันคือปัญหาเดียวกันที่วงการ agent กำลังเจอทั่วกระดาน:

1. ค่าใน config.yaml ไม่สามารถฉีด directive เข้าไปใน agent instruction ได้อีกแล้ว — นี่คือ prompt injection ผ่านไฟล์ config ที่อยู่ในรีโป ไม่ใช่ผ่านข้อความที่ผู้ใช้พิมพ์ ใครก็ตามที่ควบคุมรีโปได้ ก็เขียนคำสั่งลงในบริบทของ agent คุณได้
2. ไฟล์ที่ถูกแต่งมาไม่สามารถทำให้ openspec update หรือ openspec archive ค้างได้อีก — denial of service จากไฟล์ในรีโป
3. .npmrc ของรีโปไม่สามารถเปลี่ยนทางการเช็กอัปเดตได้อีก — ไฟล์ในโปรเจกต์ที่เปลี่ยน registry ที่เครื่องมือไปดึงข้อมูล คือรูปแบบคลาสสิกของ supply chain

นอกจากนั้นในหัวข้อ Fixed ยังมีบรรทัดหนึ่งที่ควรอ่านช้า ๆ: “DO_NOT_TRACK=true now disables telemetry” — คำว่า now หมายความว่าก่อนหน้านี้การตั้งตัวแปรนี้ไม่ได้ผล ทั้งที่ DO_NOT_TRACK คือมาตรฐานโดยพฤตินัยที่เครื่องมือ CLI ใช้กันมานาน

ส่วนที่เหลือของรุ่นเป็นงานบ้าน: openspec status ปิดท้ายด้วยบรรทัด Next: ที่บอกคำสั่งถัดไปตรง ๆ, workflow ตรวจก่อนว่ารันคำสั่ง openspec init แล้วจริง ๆ ก่อนจะเขียนอะไร, /opsx:update ร่างก่อนแล้วรอยืนยันจึงเขียน, archive ปฏิเสธชื่อ requirement ที่ต่างกันแค่ตัวพิมพ์เล็กใหญ่ และ task ที่ใช้เครื่องหมาย +, 1., 1) ถูกนับแล้ว (เดิมไม่นับ ทำให้ ✓ Complete ซ่อนงานที่ยังค้าง)

มุมมอง AI Curator

ข่าวนี้ไม่ได้มาจากบริษัทใหญ่และไม่มีตัวเลขเบนช์มาร์กให้เถียงกัน แต่ผมคิดว่ามันสำคัญเพราะมันคือตัวอย่างรูปธรรมที่สุดในสัปดาห์นี้ของปัญหาที่เราเขียนถึงซ้ำ ๆ ในเชิงนามธรรม — สัปดาห์นี้เราเขียนถึงข้อกำหนดความปลอดภัยของ MCP Skills Extension ที่บังคับว่า allowed-tools ของสกิลจากเซิร์ฟเวอร์ภายนอกต้องถูกเมินจนกว่าผู้ใช้จะอนุมัติ และเขียนถึงเคสที่ eval ของ coding agent ผ่านเพราะ sandbox รั่ว วันนี้เราได้เคสที่ตรงกว่านั้น: เครื่องมือที่มีคนกดดาวเกือบเจ็ดหมื่นคน เพิ่งปิดช่องที่ไฟล์ในรีโปสั่งงาน agent ได้

เหตุผลที่มันเกิดขึ้นเป็นเรื่องเชิงโครงสร้าง ไม่ใช่ความประมาทของใครคนหนึ่ง เครื่องมือ SDD ทุกตัวจำเป็นต้องอ่านไฟล์จากรีโปแล้วเอาไปประกอบเป็นคำสั่งให้โมเดลอ่าน นั่นคือหน้าที่ของมันโดยตรง แต่พอมันทำแบบนั้น ทุกไฟล์ใน repo ก็กลายเป็นช่องทางเข้าสู่ context window ของ agent ที่รันด้วยสิทธิ์ของคุณบนเครื่องคุณ เส้นแบ่งระหว่าง “ข้อมูลที่ถูกอ่าน” กับ “คำสั่งที่ถูกเชื่อฟัง” จึงหายไปโดยปริยาย — และมันจะกลับมาซ้ำในเครื่องมือตัวถัดไปที่ทำเรื่องเดียวกัน

จุดที่ผมอยากให้ทีมไทยเอากลับไปคิด คือนิสัยที่เรายังทำกันอยู่ทุกวัน: โคลนรีโปจาก GitHub ที่เจอใน X มาลองดู แล้วเปิด Claude Code หรือ Cursor ในโฟลเดอร์นั้นทันที เมื่อก่อนความเสี่ยงคือคุณอาจรัน npm install แล้วโดน postinstall script วันนี้ความเสี่ยงคือแค่เปิด agent ในโฟลเดอร์นั้นก็พอ เพราะไฟล์ config ในรีโปอาจเขียนสิ่งที่ agent ของคุณจะอ่านเป็นคำสั่ง เรื่องนี้ไม่ได้จำกัดอยู่ที่ OpenSpec — AGENTS.md, CLAUDE.md, .cursorrules และไฟล์ทำนองเดียวกันทุกตัวมีคุณสมบัติเดียวกันหมด ข้อแนะนำที่ใช้ได้จริงมีสองข้อ: อ่านไฟล์คำสั่งของรีโปด้วยตาก่อนเปิด agent และรัน agent ใน container — ซึ่งบังเอิญเป็นข้อเดียวกับที่ README ของ Pi harness ในข่าวอีกชิ้นของเราวันนี้แนะนำไว้ด้วยเหตุผลคนละอย่าง

เรื่อง DO_NOT_TRACK ก็ควรพูดตรง ๆ เหมือนกัน ผมไม่คิดว่ามันเป็นเจตนาร้าย มันเป็นบั๊กที่พบได้ทั่วไปในเครื่องมือที่โตเร็ว แต่สำหรับทีมไทยที่ทำงานกับข้อมูลลูกค้าภายใต้ PDPA การที่เครื่องมือซึ่งอ่านชื่อ requirement, ชื่อ capability และโครงสร้างโปรเจกต์ของคุณ ส่ง telemetry ออกไปแม้ตั้งค่าปิดไว้แล้ว เป็นสิ่งที่ต้องตรวจเองก่อนอนุมัติเข้า pipeline ไม่ใช่เชื่อเอกสาร บทเรียนที่ใช้ซ้ำได้คือ ตรวจ release note ของเครื่องมือ agent ทุกตัวที่คุณติดตั้ง ไม่ใช่แค่ดูว่ามีฟีเจอร์อะไรใหม่ เพราะบรรทัดที่สำคัญที่สุดมักซ่อนอยู่ใต้หัวข้อ Fixed

ท้ายที่สุด ควรบอกด้วยว่า SDD เป็นแนวปฏิบัติที่ยังไม่มีหลักฐานเชิงปริมาณว่าช่วยให้ agent ทำงานสำเร็จมากขึ้นแค่ไหน ดาวเจ็ดหมื่นดวงบอกว่ามีคนสนใจ ไม่ได้บอกว่ามันได้ผล และงาน HarnessTax ที่เราเขียนถึงวันนี้ก็เตือนเราไว้พอดีว่าชั้นเครื่องมือที่หนาขึ้นไม่ได้แปลว่าผลลัพธ์ดีขึ้นเสมอไป — บางทีมันแค่แพงขึ้น ถ้าคุณจะลอง OpenSpec ผมแนะนำให้ลองในโปรเจกต์จริงที่มีคนหลายคน เพราะประโยชน์ที่ชัดที่สุดของมันไม่ใช่การทำให้โมเดลฉลาดขึ้น แต่คือการบังคับให้มนุษย์ในทีมตกลงกันเป็นลายลักษณ์อักษรก่อน ซึ่งเป็นปัญหาที่มีมาก่อน LLM หลายสิบปีแล้ว

แหล่งข่าว

• OpenSpec v1.13.1 — Hardened CLI, safer archives, GitHub Releases, 17 ก.ย. 2026
• Fission-AI/OpenSpec — Spec-driven development (SDD) for AI coding assistants (MIT)
• OpenSpec — เว็บไซต์โครงการ
• github/spec-kit — เครื่องมือ SDD ของ GitHub ที่ README ของ OpenSpec เอาไปเทียบ