Tool: record_add, record_show, record_search, record_update, record_link — ข้อเท็จจริงถาวรที่เชื่อมกันด้วยความสัมพันธ์แบบมี lifecycle
คำสั่ง record lifecycle จัดการข้อเท็จจริงที่ต้องเก็บอย่างถาวรใน SQLite เช่น สร้าง แก้ ยืนยัน หรือเลิกใช้ record จึงเหมาะกับข้อมูลของโปรเจกต์ที่ไม่ควรหายไปเมื่อจบ session
endeavor_memory_record_add — เพิ่มข้อเท็จจริงถาวร ไม่ใช่ความคืบหน้าประจำวัน
Docstring แยกให้ชัดตั้งแต่ต้น: “Use for durable lifecycle facts, not routine progress” — งานประจำวันทั่วไปใช้ checkpoint บันทึกพอ record_add สงวนไว้สำหรับข้อเท็จจริงที่ต้องการอ้างอิงถาวรได้ด้วย ID ที่เสถียร (เช่น AUDIT-MEM-001) — มี 5 ประเภท: audit (สิ่งที่ตรวจพบ), fix (การแก้ไข), verification (การยืนยันว่าแก้จริง), decision (การตัดสินใจ), knowledge (ความรู้ทั่วไป)
ความสัมพันธ์ 6 แบบที่เชื่อม record เข้าด้วยกันเป็นกราฟ
จุดที่ทำให้ durable record ต่างจากบันทึกทั่วไป: แต่ละ record เชื่อมกับ record อื่นได้ด้วย typed edge 6 แบบ (references, resolves, verifies, supersedes, contradicts, duplicates) ส่งผ่านพารามิเตอร์ link (แบบเดียว) หรือ links (หลายแบบพร้อมกันแบบ atomic) ในรูปแบบ RELATION:TARGET_ID เช่น resolves:AUDIT-MEM-001
ตัวอย่าง lifecycle ทั่วไป: เจอบั๊ก → เขียน record_add(type=audit, ...) ได้ ID AUDIT-MEM-001 → แก้บั๊กแล้ว → เขียน record_add(type=fix, link="resolves:AUDIT-MEM-001") → ทดสอบยืนยันแล้ว → เขียน record_add(type=verification, link="verifies:FIX-MEM-001") — ทั้งสามขั้นเป็น record แยกกันที่เชื่อมเป็นสายด้วย edge ไม่ใช่การแก้ไข record เดิมทับ ทำให้ประวัติทั้งหมดยังคงอยู่ครบ ตรวจสอบย้อนกลับได้ว่าใครแก้อะไรตอนไหนและยืนยันด้วยอะไร
endeavor_memory_record_link — เพิ่มความสัมพันธ์ทีหลังได้
ถ้าลืมเชื่อม edge ตอนสร้าง record หรือพบความสัมพันธ์ใหม่ทีหลัง (เช่นพบว่า record สองอันขัดแย้งกัน contradicts) ใช้ record_link สร้าง edge เดี่ยวระหว่าง record ที่มีอยู่แล้วได้โดยไม่ต้องสร้าง record ใหม่ — แยกเป็น tool ต่างหากจาก record_add เพราะการเชื่อม edge เป็น operation คนละแบบ (ไม่ต้องมี title/content ใหม่ แค่ระบุ source/relation/target)
endeavor_memory_record_show — ต้องเรียกก่อนเชื่อถือ record ใดๆ เสมอ
Docstring บอกตรงๆ ว่า “Use before relying on a known durable record” — คืน record พร้อมความสัมพันธ์ lifecycle ทั้งหมดของมัน เพื่อไม่ให้เข้าใจผิดว่า record ที่ถูก supersede หรือ contradict ไปแล้วยังเป็นความจริงปัจจุบัน การเรียกดู record แค่ตัวเดียวโดยไม่เห็นบริบท lifecycle รอบข้างเสี่ยงเข้าใจผิดได้ง่าย เช่นเห็น decision เก่าที่ถูก decision ใหม่กว่า supersede ไปแล้วแต่ไม่รู้
endeavor_memory_record_search — หา record เมื่อไม่รู้ ID
ใช้เมื่อยังไม่รู้ ID ที่แน่นอน ค้นด้วย full-text query พร้อม filter ตาม type — พารามิเตอร์ current_only=true สำคัญมาก: resolve lifecycle head ให้อัตโนมัติ ตัด record ที่ไม่ current ออกจากผลลัพธ์ (ตามกลไก lifecycle read semantics ที่อธิบายไว้ใน how it works — แม้ค้นด้วยคำเก่าที่ record ที่ถูก supersede เคยใช้ ก็ยัง resolve ไปหา record ปัจจุบันให้) — docstring ย้ำอีกครั้งว่า ต้องเรียก record_show ก่อนเชื่อถือผลลัพธ์ที่สำคัญเสมอ แม้จะเจอผ่าน search แล้วก็ตาม
endeavor_memory_record_update — แก้ truth field หรือ action_state แยกกันได้
อัปเดต record ที่มีอยู่แล้ว — แยกฟิลด์เป็น 2 กลุ่มที่เป็นอิสระต่อกัน: truth field (title, content, status — ความจริงของ record) กับ action_state (actionable/deferred/blocked/nonactionable/done — สถานะว่าต้องดำเนินการต่อหรือไม่) จุดสำคัญ: การ resolve/accept record จะตั้ง action_state เป็น done ให้อัตโนมัติ เพราะ record ที่ resolve แล้วโดยธรรมชาติไม่มีอะไรต้องทำต่อแล้ว — แต่ยังปรับ action_state แยกจาก status ได้เผื่อกรณีที่ status ยังเป็น open แต่ตัดสินใจ defer งานนั้นไว้ก่อน (ไม่ใช่ resolve จริง)
ทำไมเรื่องนี้ถึงสำคัญ
กลุ่ม record lifecycle แสดงหลักการสำคัญที่ต่างจากการ “เก็บ log” ทั่วไป: ประวัติของการแก้ปัญหาไม่ควรถูกเขียนทับ แต่ควรเก็บเป็นสายของ record ที่เชื่อมด้วยความสัมพันธ์ตรวจสอบได้ — แทนที่จะแก้ข้อความ audit ทับเป็น “แก้แล้ว” (สูญเสียประวัติว่าเดิมคืออะไร) ระบบสร้าง record ใหม่ที่เชื่อมกลับไปยัง record เดิมด้วย edge ที่มีความหมายชัดเจน (resolves, verifies ฯลฯ) ทำให้ทั้งสายของเหตุการณ์ยังตรวจสอบย้อนกลับได้ครบถ้วนตลอดไป
ความคิดเห็น
กำลังโหลดความคิดเห็น...