ProudVault ค้นชื่อหรือ ISBN แล้วตอบ “มีแล้ว/ยังไม่มี” ได้ถูกต้องเฉพาะ Vault ของผู้ใช้
Complete & Protect · Module 03
Core Flow, Ownership & Search
เราจะเข้าใจสิ่งที่สร้างไว้ ปกป้องข้อมูล และทำ Primary Success Path ให้จบได้อย่างไร?
Re-entry · Read what exists
Module นี้ไม่สร้าง CRUD ซ้ำ แต่ทำของเดิมให้เข้าใจและไว้ใจได้
เปิด repository, PRODUCT_PLAN.md และ evidence จาก Module 2 เลือก request จริงหนึ่งเส้น แล้วตามว่ามันผ่าน route, controller, current user, model, PostgreSQL และ view อย่างไร
เริ่มจาก code ที่ทำงานอยู่ ห้าม reset หรือให้ AI สร้าง authentication/CRUD ใหม่
Mental model · Request lifecycle
หนึ่ง click เดินผ่านระบบหลายชั้น
ผู้เรียน trace action “เปิด Vault” จาก browser request ไปจน response และชี้ได้ว่า authentication, ownership query, validation และ database ทำงานตรงไหน
Inspect code แบบ read-only และ trace request “เปิด Vault ของ current user”
ตั้งแต่ route → controller → authentication → ownership query → model/database → response
อ้าง file path และ method จริง ห้ามแก้ code
ถ้าหลักฐานไม่พอให้บอกจุดที่ต้อง inspect เพิ่ม ห้ามเดา
Protect · Three separate questions
คุณคือใคร, ทำสิ่งนี้ได้ไหม และ query ไปถึงข้อมูลใด
Authentication, authorization และ ownership scoping เป็นคนละหน้าที่ ให้ตรวจทุก lookup และ mutation ของ Vault/Asset ว่าเริ่มจาก current user ไม่ใช่ global id
ต้องรักษา
- Devise ยืนยันว่าใคร sign in
- Query จำกัด record ตาม owner
- Action ตรวจสิทธิ์ก่อนเปลี่ยนข้อมูล
หลักฐาน
- Direct URL ของ user อื่นถูกปฏิเสธ
- Read/update/delete ข้าม user ไม่ได้
- Test รันซ้ำได้
Defense in depth
Validation, constraint และ test ป้องกันคนละชั้น
ทบทวน required, unique และ foreign-key decisions จาก Product Plan แล้วเพิ่ม application feedback, database constraints และ tests เฉพาะกฎที่สำคัญ ห้ามสร้าง constraint จากความเคยชิน
Primary Path · Reopen approved criteria
ตอนนี้ฐานพร้อมแล้ว เรากลับมาสร้าง Search/ISBN
PV-05/06 ถูกวางไว้ตั้งแต่ Module 2 ให้ยืนยัน input, found/not-found result, ownership boundary และ invalid cases ก่อนวาง Build Plan
อ่าน PRODUCT_PLAN.md และ code ปัจจุบัน
เสนอ Build Plan สำหรับ PV-05/06 เท่านั้น:
input → normalization → ownership-scoped query → found/not-found state → tests
ระบุ files, verifier, stop condition และ forbidden scope
ห้าม external API, autocomplete หรือ shared catalog ใน Module 3
รอ Human approval ก่อนแก้ code
Integrity · Normalize before compare
ISBN รูปต่างกันต้องเปรียบเทียบด้วยกติกาเดียวกัน
ตัดสินใจกฎ ISBN ที่มีขีด/ช่องว่าง, blank/invalid input และ title-only search แล้ววาง normalization ที่ boundary ชัดเจนก่อน query หรือ persist
Module นี้ตอบว่า “มีใน Vault ของฉันไหม” ยังไม่สร้างข้อมูลหนังสือกลางของทุกคน
Build · One vertical slice
ทำ request, rule, data, UI และ evidence ให้จบในเส้นเดียว
ให้ AI ลงมือทีละ phase ตามแผน: query rule ก่อน, states ต่อ, tests และ browser evidence โดยหยุดหลัง verifier ทุก phase และอ่าน diff ก่อนเดินต่อ
Automated evidence
เปลี่ยน manual checks สำคัญให้รันซ้ำได้
เพิ่ม automated isolation test และ critical-flow tests สำหรับ found, not found และ invalid ISBN โดย manual browser check ยังใช้ตรวจภาษากับประสบการณ์ของผู้ใช้
Exit Gate
Core flow เสร็จเมื่อคำตอบถูกและไม่รั่วข้าม user
ผู้เรียนต้อง demo Search/ISBN ด้วยข้อมูลที่รู้คำตอบล่วงหน้า อธิบาย request path, แสดง automated evidence และบอกได้ว่ากฎใดอยู่ application/database layer
ของที่ส่งต่อ Module 4 คือ Primary Path ที่ทำงานบน local พร้อม tests และ Build evidence ที่อธิบายได้
Module checkpoint
สิ่งที่ต้องนำออกจากห้อง
Request map, hardened ownership/data rules, Search/ISBN vertical slice และ automated critical-flow tests
อธิบาย request path ได้, User A แตะข้อมูล B ไม่ได้, ISBN ถูก normalize และ Evidence ของ Primary Path ผ่านทั้ง browser กับ tests