Tool: write_file — สร้างไฟล์ใหม่ได้เสมอ แทนที่ไฟล์เดิมต้องผ่าน permission gate เดียวกับ edit
write_file ใช้สำหรับการเขียนไฟล์แบบเต็มไฟล์ — สร้างไฟล์ใหม่จากศูนย์, บันทึกผลลัพธ์ที่สร้างขึ้นเป็นไฟล์ตั้งชื่อ, หรือแทนที่เนื้อหาทั้งไฟล์โดยตั้งใจ ไม่ใช่สำหรับแก้เฉพาะจุดในไฟล์เดิม — งานแบบนั้นเป็นหน้าที่ของ edit
สร้างไฟล์ใหม่: ไม่ต้องขออนุญาต
สร้างไฟล์ใหม่ (path ที่ยังไม่มีไฟล์อยู่) ทำได้ทันทีไม่ต้องผ่าน permission gate ใดๆ — เพราะไม่มีข้อมูลเดิมที่จะสูญหาย เป็น operation ที่ปลอดภัยโดยธรรมชาติ ถ้า path มีไฟล์อยู่แล้วและไม่ได้ตั้ง overwrite=true จะได้ [error] กลับมาแทนการเขียนทับเงียบๆ
แทนที่ไฟล์เดิม: permission gate เดียวกับ edit เป๊ะๆ
overwrite=true บนไฟล์ที่มีอยู่แล้วเท่านั้นที่ต้องผ่าน gate — ครั้งแรกที่แตะโฟลเดอร์ระดับบนสุดใน session นั้นจะ fail ด้วย [permission_required] พร้อม nonce ครั้งเดียว โมเดลต้องถามผู้ใช้ตรงๆ ในบทสนทนาก่อนส่ง grant_phrase กลับมา — ไม่มีสิทธิ์เดา ไม่มีสิทธิ์สันนิษฐานว่าใช่
จุดที่ควรรู้: gate นี้เป็น registry เดียวกับ edit ไม่ใช่คนละอันแยกตาม tool — ขออนุญาตโฟลเดอร์ผ่าน edit ครั้งหนึ่งแล้ว write_file(overwrite=true) ในโฟลเดอร์เดียวกันก็ใช้ grant นั้นได้เลยโดยไม่ต้องขอซ้ำ และในทางกลับกันก็เช่นกัน — เพราะสิ่งที่ผู้ใช้อนุญาตจริงๆ คือ “ไฟล์เดิมในโฟลเดอร์นี้แก้ไขได้” ไม่ใช่ “tool ชื่อนี้ใช้ได้”
นอก workspace: ไฟล์เดิมไม่ถูกแตะเลย แม้ได้รับอนุญาตแล้วก็ตาม
ในเวิร์กสเปซ เขียน/แทนที่ตรงตำแหน่งเดิมได้เต็มที่หลังผ่าน gate นอกเวิร์กสเปซ ไฟล์ใหม่สร้างได้ทุกที่ที่ไม่ใช่ protected path แต่ไฟล์เดิมที่มีอยู่แล้วจะไม่ถูกแทนที่ในตำแหน่งเดิมไม่ว่ากรณีใด — การเขียนถูก redirect ไปที่ working copy ข้างๆ ต้นฉบับเสมอ (report.md → report.edited.md) ผลลัพธ์ของการเรียกจะรายงาน path จริงที่ถูกเขียนกลับมาให้เห็น ไม่ใช่ path ที่ขอไปตอนแรก
ทำไมแยกสองเงื่อนไขแบบนี้
การออกแบบแยก “สร้างใหม่” ออกจาก “แทนที่ของเดิม” อย่างชัดเจน เพราะความเสี่ยงของสอง operation นี้ต่างกันโดยพื้นฐาน — สร้างไฟล์ใหม่ไม่มีอะไรให้สูญเสีย แต่แทนที่ไฟล์เดิมทั้งไฟล์คือการทำลายเนื้อหาเดิมแบบย้อนกลับไม่ได้ (นอกจาก user จะมี version control ของตัวเอง) ดังนั้นเฉพาะกรณีหลังเท่านั้นที่ต้องผ่าน consent gate — ไม่ใช่บังคับขออนุญาตทุกครั้งที่เขียนไฟล์แบบไม่เลือกปฏิบัติ ซึ่งจะทำให้ friction เกิดขึ้นแม้ในกรณีที่ไม่มีความเสี่ยงจริง
ทำไมเรื่องนี้ถึงสำคัญ
write_file เป็นตัวอย่างที่ดีของหลักการที่ใช้ทั้งระบบ: แยกแยะระดับความเสี่ยงของแต่ละ operation แล้วให้ friction ตรงกับความเสี่ยงจริง ไม่ใช่ใช้กฎเดียวกันหมดกับทุก path — สร้างไฟล์ใหม่ไหลลื่นไม่มีสะดุด แต่การทับไฟล์เดิมต้องผ่านด่านที่ผู้ใช้ยืนยันจริงเสมอ ไม่ว่าจะเรียกผ่าน write_file หรือ edit ก็ตาม
ความคิดเห็น
กำลังโหลดความคิดเห็น...