OnProud
Module 02 Product Plan & First Build

Define & Build · Module 02

Product Plan & First Build

เมื่อ Project Intake บอกทิศทางและเครื่องพร้อมแล้ว เราจะเปลี่ยนมันเป็นแผน ที่คนอนุมัติได้ แล้วให้ AI สร้าง ProudVault รุ่นแรกทีละ phase โดยไม่เผลอสร้าง Search/ISBN ก่อนถึงเวลาของมันได้อย่างไร?

Project Intake + live technical preflightProduct MapSite MapUser StoriesAcceptance criteriaStitch visual reviewDESIGN.mdStitch MCPStack DecisionBUILD_PLAN.mdFirst Rails build

Start with four product questions

ก่อนสร้าง เราต้องตอบให้ได้ว่า “ต้องทำอะไร” และ “ทำอะไรก่อน”

Module 1 ส่ง Project Intake ที่บอกว่าใครเจอปัญหาอะไรและอยากได้ผลลัพธ์แบบไหน แต่ยังไม่บอกว่า product ต้องมีหน้า ฟังก์ชัน และงานหลังบ้านอะไรบ้าง Module นี้จะค่อย ๆ เปลี่ยน Intake ให้เป็นคำตอบสี่เรื่อง แล้วเก็บคำตอบที่อนุมัติแล้วไว้ใน PRODUCT_PLAN.md

สี่คำถามที่เราจะตอบ

1 · ต้องมีงานอะไรบ้าง
ทั้งสิ่งที่ผู้ใช้เห็น และงานที่ทำให้ระบบปลอดภัยหรือใช้งานได้ครบ
2 · ผู้ใช้เจองานนั้นที่ไหน
เป็น page, function, state ของหน้าเดิม หรืองานที่ไม่มีหน้า
3 · อะไรสำคัญ และอะไรต้องสร้างก่อน
คุณค่าต่อผู้ใช้ไม่จำเป็นต้องเรียงเหมือน dependency ของการพัฒนา
4 · จะรู้ได้อย่างไรว่าผ่าน
คนกำหนด acceptance criteria ที่สังเกตและตรวจได้
ตอนนี้ยังไม่ต้องคิดชื่อ controller หรือเริ่มเขียน code เรากำลังทำให้เห็น product ทั้งก้อนก่อน

Worked Example · Intake → Work

หนึ่งเส้นทางของผู้ใช้ แตกออกมาเป็นงานหลายชิ้น

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

  • รู้ว่าเป็นใคร → สมัคร, sign in และข้อมูลแต่ละคนไม่ปนกัน
  • มีที่เก็บของตัวเอง → สร้างและเปิดดู Vault
  • มีข้อมูลให้ค้น → เพิ่มและดูรายละเอียดหนังสือใน Vault
  • ค้นแล้วรู้ผล → ช่องค้น, ผล “มีแล้ว/ยังไม่มี” และทางไปเพิ่มหนังสือ
  • ใช้งานแล้วไม่ติดขัด → empty state, feedback และแก้หรือลบข้อมูลที่ผิด
Intake ไม่ได้หายไป มันเป็นเหตุผลของทุกงาน และ AI ไม่มีสิทธิ์เปลี่ยน user, trigger หรือ desired outcome เงียบ ๆ

Direct the AI · Read before proposing

เริ่ม PRODUCT_PLAN.md เป็นโครง — ยังไม่ต้องมีคำตอบครบ

PRODUCT_PLAN.md จะค่อย ๆ โตตาม decision ที่คุณอนุมัติใน module นี้ ขั้นแรกให้ AI เสนอ Intake Snapshot จาก Project Intake แล้วนำผลที่อนุมัติไปวางใน Generator ซึ่งจะสร้าง scaffold กลางให้ ส่วน Scope, Product Map, Site Map, Data Relationship และ Acceptance Criteria ยังคงเป็น PENDING รอเรียนและตัดสินทีละส่วน

เติมตอนนี้

  • Intake Snapshot ที่รักษา user, trigger, outcome และ Primary Path
  • Non-goals และ Risk→Evidence เดิม
  • Scaffold และ Section headings ที่ Generator สร้างให้

ยังไม่ให้ AI ตอบ

  • Scope และความสำคัญของงาน
  • Page, state และ data relationship
  • Acceptance Criteria หรือ build order
เปิด Studio เพื่อเริ่ม PRODUCT_PLAN.md Generator
ทุกหน้าถัดไปนำเฉพาะผลที่อนุมัติแล้วมาเติม section ที่กำลังเรียน ห้าม AI rewrite decision ที่ผ่านแล้วหรือเติม PENDING ล่วงหน้า

Concept · Three lenses

ใช้สามคำถามกันงานสำคัญหล่น และกัน scope บวม

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

ProudVault · สามคำถาม หกกลุ่ม

ผู้ใช้ได้คุณค่าอะไร
Core Path, Supporting และ Usable Completeness
อะไรต้องมีเพื่อให้ใช้ได้และไว้ใจได้
Precondition และ Protection & Evidence แม้บางงานไม่มีหน้า
อะไรยังไม่จำเป็นในรุ่นนี้
Deferred พร้อมเหตุผล เช่น recommendation, lending หรือ AI import
“แอปทั่วไปควรมี” และ “AI สร้างได้” ยังไม่ใช่เหตุผลให้งานเข้ารุ่นนี้

Practice · Grow the Scope section

เติม Scope ให้เสร็จ แล้วตรวจว่าไฟล์โตขึ้นอย่างไร

เปิด PRODUCT_PLAN.md ที่มี Intake Snapshot และหัวข้อ PENDING ให้ AI ช่วยเสนอ Scope จาก Intake จากนั้นคุณตัดสินใจทีละข้อ ส่วนอื่นยังคงเป็น PENDING

  1. 1

    ให้ AI เสนองานพร้อมบอกว่ามาจากส่วนใดของ Intake

  2. 2

    ย้ายแต่ละงานเข้าหกกลุ่ม และเพิ่มงานจำเป็นที่ AI มองข้าม

  3. 3

    approve, reject หรือ request changes ทีละข้อ

  4. 4

    เปลี่ยนเฉพาะ Scope จาก PENDING เป็นเนื้อหาที่อนุมัติแล้ว

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 12 นาที

PRODUCT_PLAN.md ที่ Intake Snapshot และ Scope มีคำตอบ ส่วนที่เหลือยัง PENDING

เปิด Product Plan Studio

Concept · Two different orders

“สำคัญที่สุด” ไม่ได้แปลว่า “ต้องเขียนก่อน”

ลองเรียงงาน ProudVault สองครั้ง ครั้งแรกเรียงตามคุณค่าต่อผู้ใช้ ครั้งที่สองเรียงตามสิ่งที่ code ต้องพึ่งพา เราจะได้คนละลำดับ และต้องเก็บทั้งคู่ไว้ในแผน

Importance · ผู้ใช้ต้องการอะไรที่สุด

  • ค้นชื่อหรือ ISBN แล้วรู้ว่ามีหนังสือแล้วหรือยัง
  • เพิ่มหนังสือที่ยังไม่มีเข้า Vault
  • จัดการข้อมูลและบัญชีได้ครบพอใช้งาน

Build order · อะไรต้องเกิดก่อน

  • User และ ownership
  • Vault และ Asset ที่มีข้อมูลจริง
  • Search บนฐานข้อมูลที่พร้อมแล้ว
Login สร้างก่อนเพราะเป็น dependency ไม่ได้แปลว่า Login คือคุณค่าหลักของ product หน้าถัดไปเราจะนำ Importance, Dependencies และ Build order มารวมเป็น Product Map

Concept + Direct the AI · One row per work item

ทำให้งานแต่ละชิ้นตอบคำถามเดียวกันได้

Product Map คือการนำ Scope มาแจกแจงเป็นหนึ่งแถวต่อหนึ่งงาน เพื่อให้ตรวจย้อนกลับได้ ยังไม่ต้องเริ่มจากศัพท์ User Story ให้เริ่มจากคำถามธรรมดาว่า งานนี้มีไว้ทำไม ผู้ใช้หรือระบบ ต้องได้อะไร เจอที่ไหน สำคัญแค่ไหน พึ่งอะไร และควรสร้างลำดับใด

ProudVault · ตัวอย่างหนึ่งแถว

PV-04 · เพิ่มหนังสือเข้า Vault
Source = Primary Path · Outcome = เก็บหนังสือที่ยังไม่มี · Surface = Asset form · Importance = สูง · Depends on = User, Vault, ownership · Build order = หลัง Vault
PV-02 · ป้องกันข้อมูลข้ามผู้ใช้
Source = Risk→Evidence · System rule = ทุก Vault และ Asset ย้อนหาเจ้าของได้ · Surface = ไม่มีหน้า · Depends on = User relationship
เปิด Product Plan Studio · ขั้นที่ 3 เพื่อสร้าง Product Map
งานที่ไม่มีหน้าไม่ใช่งานที่ AI ทำเงียบ ๆ มันต้องมี ID, ที่มา และตำแหน่งในลำดับพัฒนาเหมือนงานบนจอ

Product Map → Site Map

เมื่อรู้งานทั้งหมดแล้ว จึงค่อยเห็นว่าต้องมีหน้าอะไร

ใช้เฉพาะ Product Map ที่อนุมัติแล้วมาจัดเป็น Site Map หน้าใหม่เกิดเมื่อผู้ใช้เดินทางไปยัง พื้นที่หรือทำงานที่ต่างออกไป ส่วน loading, empty, error, success และ search result มักเป็น state ของหน้าเดิม และบาง requirement ไม่มีหน้าเลย

ProudVault · page family รุ่นแรก

Authentication
Sign up / Sign in
Vault index + Vault detail
รายการ Vault, Assets, empty state และภายหลังพื้นที่ Search/ISBN
Vault form + Asset form/detail
สร้าง/แก้ Vault และเพิ่ม ดู แก้ ลบ Asset
ไม่มีหน้า
ownership, validation, constraint และ automated tests
เปิด Product Plan Studio · ขั้นที่ 4 เพื่อเติม Site Map
Dashboard, profile, settings และ feed เป็น Deferred ไม่ใช่หน้าที่ AI เพิ่มเองเพื่อให้แอปดูเต็ม

Site Map → Data Relationship draft

หน้าเหล่านี้ต้องอ่านและเปลี่ยนข้อมูลของใคร

วาด relationship ระดับ product ก่อน แล้วใช้คำถาม lifecycle ตรวจ plan ของ AI ProudVault ใช้ User 1 → many Vaults และ Vault 1 → many Assets; Asset หนึ่ง belongs to Vault หนึ่ง และทุก record ต้องย้อนกลับหา User เจ้าของได้

  • User หนึ่งมี Vault ได้กี่อัน และ Asset ย้าย Vault ได้หรือไม่
  • ลบ Vault แล้ว Asset ด้านในต้องเกิดอะไรขึ้น
  • ฟิลด์ใดห้ามว่าง หรือห้ามซ้ำภายในขอบเขตใด
  • เรื่องไหนเป็น decision ตอนนี้ และเรื่องไหนเลื่อนไป Module 3
เปิด Product Plan Studio · ขั้นที่ 5 เพื่อเติม Data Relationship Draft
AI อาจเสนอ model name หรือ migration ได้ภายหลัง แต่คนต้องอนุมัติ relationship และ lifecycle ก่อน

Human Decision Gate · Structure

หยุดตรวจโครง product ก่อนเขียนเกณฑ์ว่าผ่าน

ตอนนี้ PRODUCT_PLAN.md ยังไม่เสร็จ แต่ควรตอบได้แล้วว่าอะไรอยู่ในรุ่นนี้ งานแต่ละชิ้นมาจากไหน ผู้ใช้พบมันที่ใด อะไรต้องสร้างก่อน และข้อมูลสัมพันธ์กันอย่างไร เจ้าของ product ต้องอนุมัติ โครงนี้ก่อนจึงค่อยกำหนด Acceptance Criteria

  1. 1

    ตรวจทุก Story/Requirement ว่ามี source และ ID

  2. 2

    ตรวจ importance แยกจาก build order และ dependency

  3. 3

    ตรวจ page, state และงานไม่มีหน้า

  4. 4

    approve, reject หรือ request changes เป็นรายข้อ

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 8 นาที

Scope, Product Map, Site Map และ Data Relationship Draft ที่เจ้าของ product อนุมัติ

Concept · Acceptance criteria

Acceptance criteria คือประตูตัดสินใจของคน ไม่ใช่ checklist ที่ AI ติ๊กเอง

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

PV-04 · เพิ่ม Asset

ตั้งต้น
ผู้ใช้ sign in และมี Vault ของตนเอง
ลงมือ
กรอกข้อมูลหนังสือขั้นต่ำที่ผ่าน validation แล้วบันทึก
เห็นผล
Asset ปรากฏใน Vault ที่เลือก; ถ้าข้อมูลไม่ผ่าน เห็น feedback และไม่เกิด record ที่ใช้ไม่ได้
เปิด Product Plan Studio · ขั้นที่ 6 เพื่อเติม Acceptance Criteria
Human outcome เช่น “ตัดสินใจไม่ซื้อซ้ำ” เป็นเหตุผลของ behavior แต่ software ไม่ควรเคลมว่าพิสูจน์การตัดสินใจของมนุษย์แล้ว

Final Human Gate · Acceptance Criteria

ให้ AI เสนอเกณฑ์ แล้วคนปิด Product Plan ทีละข้อ

สั่ง AI ให้เติม acceptance criteria โดยอ้าง Story ID และ Risk→Evidence จาก PRODUCT_PLAN.md จากนั้นใช้สถานะ Approve, Reject หรือ Request changes; ไม่มีสถานะ “AI คิดว่าพอแล้ว”

  1. 1

    ตรวจเส้นทางปกติ และเลือกสถานการณ์อื่นที่เกิดกับงานนี้จริง

  2. 2

    ตรวจว่าเกณฑ์บอกสิ่งที่ผู้ใช้สังเกตหรือ verifier ทดสอบได้

  3. 3

    ผูก verifier และ Risk→Evidence เมื่อมีความเสี่ยง

  4. 4

    อนุมัติ criteria ก่อนให้ AI เริ่มออกแบบหรือสร้าง

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 12 นาที

PRODUCT_PLAN.md ที่มี Acceptance Criteria ที่คนอนุมัติและทุก section พร้อมใช้

เปิด Product Plan Studio · ขั้นที่ 7 เพื่อตรวจ Final Product Plan

Concept · Visual contract

ก่อน build ให้ทำ Primary Path ที่ยังไม่เสร็จ “มองเห็นได้”

Product Plan บอก behavior ที่ต้องมี แต่ภาพทำให้เราเห็นเร็วขึ้นว่าคนที่ยืนอยู่ในร้านจะเดินจาก “ไม่แน่ใจว่ามีเล่มนี้แล้วหรือยัง” ไปสู่คำตอบได้จริงหรือไม่ ใช้ Stitch สร้างภาพของ Primary Path ให้ครบ loop: My Vault → ค้นชื่อหรือ ISBN → มีแล้ว/ยังไม่มี → เพิ่มเมื่อจำเป็น → กลับมามั่นใจ ภาพนี้เป็น visual hypothesis ไม่ใช่สิทธิ์เพิ่ม product scope และ Search/ISBN ยังไม่ใช่ code ของ Module 2

  1. 1

    ส่งเฉพาะ Primary Path, Site Map, story/criterion ที่อนุมัติแล้ว และ non-goals เข้า Stitch

  2. 2

    สร้าง screens ที่ทำให้ loop จบ รวม empty, invalid และ result state ที่จำเป็น

  3. 3

    ติดป้าย M2 foundation และ M3 Search/ISBN บน screens ตาม build scope จริง

  4. 4

    หยุดเมื่อภาพพอให้ตรวจการตัดสินใจของผู้ใช้ได้ ไม่ขัดรายละเอียด pixel ต่อ

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 15 นาที

Stitch board หรือ screenshots ของ Primary Path ครบ loop พร้อมป้าย build scope

Human gate · Design-to-Plan review

ภาพสวยยังไม่ผ่าน ถ้ามี feature ที่แผนไม่อนุมัติ

ตรวจทีละ screen ว่าทุก action, state และข้อความ trace กลับไปที่ Product Map, Story หรือ AC ได้ หาก Stitch เติม barcode scan, recommendation, settings, statistics, external metadata หรือคำอ้าง security ที่ไม่มีหลักฐาน ให้ mark ว่า REMOVE หรือ DEFER ไม่ใช่ปล่อยเข้า build เพราะดูน่าใช้

เก็บเป็น visual rule

  • primary action เดียวที่มองเห็นชัดขณะถือโทรศัพท์มือเดียว
  • ผล “มีแล้ว/ยังไม่มี” อ่านจบก่อนต้องตัดสินใจซื้อ
  • empty และ invalid state สื่อสิ่งที่ต้องทำต่ออย่างชัดเจน

KEEP · เขียนต่อเป็น DESIGN.md ได้

ตัดหรือรอ

  • barcode scan, API metadata, recommendations หรือ statistics
  • tab/settings/navigation ใหม่ที่ไม่มีใน Site Map
  • claim เช่น end-to-end encryption ที่ยังไม่มี requirement และ evidence

REMOVE / DEFER · ไม่สร้างและไม่สัญญาแทน product

Primary Path ต้องครบในภาพเพื่อให้ตรวจคุณค่าได้ แต่ build วันนี้ยังทำเฉพาะ foundation slice ตาม BUILD_PLAN

Concept · Visual contract

DESIGN.md เก็บกติกาที่ผ่าน visual review แล้วให้ AI ใช้ซ้ำ

เปิด DESIGN.md แล้วควรเห็นกติกาหลักห้าส่วน: สี, ตัวอักษร, spacing และรูปทรง, หน้าตาของ component และสิ่งที่ควร/ไม่ควรทำ กติกาเหล่านี้ช่วยให้ AI สร้างทุกหน้า ไปในทิศทางเดียวกัน โดย PRODUCT_PLAN.md ยังเป็นเจ้าของว่า product ต้องทำอะไร

  • Colors — สีพื้น สีข้อความ สี action และสี focus
  • Typography — font, ขนาด และลำดับชั้นของข้อความ
  • Spacing & shapes — ระยะห่าง ความกว้าง และความโค้ง
  • Components — ปุ่ม input card และ state ต่าง ๆ หน้าตาอย่างไร
  • Do / Don't — กติกาที่ช่วยรักษาทิศทางของงาน
เปลี่ยนหน้าตาปุ่ม ให้แก้ DESIGN.md; เพิ่มปุ่มหรือเปลี่ยนปลายทาง ให้กลับไปขออนุมัติ PRODUCT_PLAN.md ก่อน

Stitch → Extract → Approve

สกัดกติกาจากภาพ ไม่ copy ภาพมาเป็น specification

ใช้ screens ที่ผ่าน scope review เพื่อเสนอสี ตัวอักษร spacing รูปทรง และ component rules ที่ต้องใช้ซ้ำ ใน DESIGN.md ภาพเป็นตัวทดลอง ไม่ใช่ source of truth เพิ่มเติม; ถ้า Stitch ยังให้ visual language ไม่ชัด จึงค่อยใช้ shadcn Design Gallery เป็น reference เสริมหนึ่งแบบ แล้ว adapt ก่อนรับเข้า contract

  1. 1

    เลือก rules ที่ซ้ำกันจาก screens และอธิบายว่าช่วยผู้ใช้ในบริบทจริงอย่างไร

  2. 2

    เขียน Stitch-ready extract สั้น ๆ แล้วทดสอบ generate ใหม่เมื่อ rule สำคัญยังไม่ชัด

  3. 3

    ให้ AI ร่าง DESIGN.md จาก rules ที่ผ่าน review โดยไม่เพิ่ม behavior ใหม่

  4. 4

    ตรวจความครบถ้วนและอนุมัติก่อนใช้ DESIGN.md สร้าง UI

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 15 นาที

DESIGN.md ที่ได้รับอนุมัติและอ้าง PRODUCT_PLAN.md เป็นเจ้าของ behavior

เปิด DESIGN.md Studio เพื่อ review Stitch และสร้าง visual contract

Build Gate · Select today’s slice

วันนี้เราจะหยิบงานไหนจาก Product Plan มาสร้างก่อน

เราไม่ได้หยิบงานที่สำคัญที่สุดทั้งหมดมาสร้างวันนี้ แต่เลือกชุดที่เป็น dependency ของ Primary Path และมีผลลัพธ์ให้ผู้เรียนเปิดดูและทดลองได้: identity, ownership, Vault, Asset และ usable states ส่วน Search/ISBN ยังสำคัญที่สุดต่อ core value แต่ต้องรอข้อมูลและเส้น ownership พร้อมก่อน

Build วันนี้

  • PV-01 · Devise identity
  • PV-02 · Ownership foundation
  • PV-03 · Vault CRUD
  • PV-04 · Asset CRUD
  • PV-07 · Empty/invalid feedback
  • PV-08 · Evidence ในทุก phase

ยังไม่ Build

  • PV-05–06 · Search/ISBN — Planned · Module 3
  • Recommendation, lending, feed และ external API
  • Deployment และ Deferred อื่น
Prompt · Select the Module 2 build slice 
อ่าน PRODUCT_PLAN.md ที่ READY แล้ว

เสนอ build slice สำหรับ Module 2 โดยเลือกเฉพาะงานที่:
1. เป็น dependency ที่ Primary Path ต้องพึ่ง
2. ทำให้ผู้เรียนเห็นและทดลองความคืบหน้าได้วันนี้

สำหรับ ProudVault ให้ตรวจว่า slice มี PV-01, PV-02, PV-03, PV-04, PV-07 และ PV-08
และแยก PV-05–06 Search/ISBN ไป Planned · Module 3

แสดง Include / Exclude พร้อมเหตุผลและ Build order
รอให้ฉันอนุมัติ ห้ามสร้างไฟล์หรือ code

ความสำคัญตอบว่า “ผู้ใช้ต้องการอะไร” ส่วน slice วันนี้ตอบว่า “อะไรพร้อมสร้างและทำให้เห็นความคืบหน้าได้”

BUILD_PLAN.md anatomy

ก่อนสร้าง BUILD_PLAN.md มาดูว่าไฟล์นี้ประกอบด้วยอะไร

BUILD_PLAN.md เป็นไฟล์ควบคุมการลงมือ ไม่ใช่ task list ยาว ๆ มันบอกว่าเราใช้ stack อะไร เลือก Story ใดมาสร้าง แบ่งงานเป็น phase อย่างไร จะตรวจอะไร และตอนนี้อยู่สถานะใด ทุก phase ต้องหยุดให้คนอนุมัติก่อนเดินต่อ

Anatomy ของ BUILD_PLAN.md

1 · Stack Decision
ใช้เทคโนโลยีอะไร เพราะอะไร และอะไรห้ามเปลี่ยนระหว่าง build
2 · Build Scope
Include Story ใดวันนี้ และ Story/feature ใดเป็น forbidden scope
3 · Phases
Goal, Story/AC IDs, dependency, expected changes, verifier, stop และ approval
4 · Evidence Log
ตรวจอะไร ผลเป็นอย่างไร และคนอนุมัติเมื่อไร
5 · Current Status
phase ใด PENDING, IN PROGRESS, PASSED หรือ BLOCKED
ถ้าไฟล์ไม่มี verifier และจุดหยุด มันเป็นเพียงรายการสิ่งที่อยากทำ ไม่ใช่ Build Plan ที่ควบคุม AI ได้

Fixed stack + Build Scope

เติมสองส่วนแรกจาก decision ที่เรามีแล้ว

Stack ของคลาสถูกล็อกไว้ ส่วน Build Scope มาจาก slice ที่อนุมัติในหน้า 16 ให้ AI สร้าง scaffold ของ BUILD_PLAN.md แล้วเติมเพียง Stack Decision และ Build Scope ส่วน Phases, Evidence Log และ Current Status ยังรอขั้นถัดไป

Stack Decision

  • Rails monolith + PostgreSQL
  • Server HTML + Turbo และ Devise
  • Rails tests + Git/GitHub

Build Scope

  • Include PV-01, PV-02, PV-03, PV-04, PV-07, PV-08
  • Forbidden PV-05–06 Search/ISBN
  • Forbidden Deferred และ deployment
Prompt · Start BUILD_PLAN.md 
BUILD_PLAN.md คือ execution control contract ที่ให้คนใช้ควบคุมการทำงานของ AI
ไฟล์ต้องมี 5 sections ตามลำดับนี้:

# Build Plan

## 1. Stack Decision
- Chosen stack:
- Why this workshop uses it:
- Forbidden substitutions:
- Revisit when:
- Human decision:

## 2. Build Scope
### Include
| Story ID | เหตุผลที่เลือกวันนี้ |
|---|---|

### Forbidden Scope
| Story/Feature | เหตุผลที่ยังไม่สร้าง |
|---|---|

## 3. Phases
PENDING — รอ Human Decision

## 4. Evidence Log
| Phase | Verifier | Result | Human decision |
|---|---|---|---|

## 5. Current Status
- Current phase: NOT STARTED
- Overall status: PENDING
- Blockers: None recorded

รอบนี้เติมเฉพาะ Section 1 และ 2 จาก decision ที่อนุมัติแล้ว:
- Stack: Rails monolith, PostgreSQL, Server HTML + Turbo, Devise,
  Rails tests และ Git + GitHub
- Include: PV-01, PV-02, PV-03, PV-04, PV-07, PV-08
- Forbidden: PV-05–06 Search/ISBN, Deferred และ deployment

Stack นี้เป็น classroom paved road ห้ามเปลี่ยนใน Module 2
Section 3–5 ต้องคง skeleton และสถานะ PENDING ห้ามเติมล่วงหน้า
แสดง draft ให้ฉันตรวจก่อนเขียนไฟล์ ห้ามสร้าง project หรือ code

Rails + PostgreSQL เป็น technical foundation ไม่ใช่ User Story และไม่ทำให้มันกลายเป็น core value ของ product

Plan before code

ค่อยแบ่ง Build Scope เป็น phase ตาม Product Map

หลังสองส่วนแรกผ่านแล้ว จึงแบ่ง phase ตาม dependency: foundation → identity → ownership/data → Vault → Asset/usable states → evidence แต่ละ phase ต้อง trace กลับ Story/AC และมีจุดหยุดของตัวเอง

ProudVault · phase ที่ตรงกับ Product Map

Phase 1 · Foundation
Rails + PostgreSQL, documents, database, baseline test และ localhost
Phase 2–3 · Identity + ownership
PV-01 ก่อน แล้ว PV-02 กับ User → Vault → Asset
Phase 4–5 · Visible progress
PV-03 Vault CRUD แล้ว PV-04/PV-07 Asset CRUD และ usable states
Phase 6 · Evidence
PV-08, two-user check, tests, diff และ checkpoint
Prompt · Draft BUILD_PLAN.md 
อ่าน PRODUCT_PLAN.md, DESIGN.md และ BUILD_PLAN.md ที่อนุมัติ Stack Decision กับ Build Scope แล้ว

เติม Section 3: Phases โดยทุก phase ต้องใช้ schema นี้ exactly:

### Phase [N] · [Name]
- Status: PENDING
- Goal:
- Product Map IDs:
- Acceptance Criteria IDs:
- Dependencies:
- Expected changes:
- Verifiers:
- Stop when:
- Forbidden scope:
- Human approval: PENDING

ใช้ลำดับ:
1. Rails + PostgreSQL foundation
2. PV-01 Devise identity
3. PV-02 User → Vault → Asset และ ownership
4. PV-03 Vault CRUD
5. PV-04/PV-07 Asset CRUD และ usable states
6. PV-08 verification และ GitHub checkpoint

Search/ISBN และ Deferred ทั้งหมดเป็น forbidden scope

Section 4: Evidence Log ให้คง columns:
| Phase | Verifier | Result | Human decision |

Section 5: Current Status ให้เริ่ม:
- Current phase: NOT STARTED
- Overall status: PENDING
- Blockers: None recorded

แสดง draft Section 3–5 ให้ฉันตรวจ
ห้ามแก้ไฟล์หรือสร้าง code จนกว่าจะได้รับอนุมัติ

อนุมัติแผนทั้งก้อนหนึ่งครั้ง แต่เวลา Build ให้อนุมัติและหยุดตรวจทีละ phase

Build gate · Connect design context

ต่อ Stitch MCP เพื่อให้ agent อ่าน design ที่อนุมัติ — ไม่ใช่ให้มันเขียนทับแผน

เมื่อ PRODUCT_PLAN.md, DESIGN.md และ BUILD_PLAN.md ผ่านแล้ว จึงต่อ Stitch MCP ตาม paved lane ของผู้สอน ให้ agent เปิดเฉพาะ project/screens ที่ผ่าน scope review และรายงานสิ่งที่อ่านได้ก่อนสร้าง code การต่อไม่ผ่านไม่ใช่เหตุให้หยุด product work: ใช้ DESIGN.md กับ screenshot/export ที่ผ่าน review ต่อได้

Prompt · Read approved Stitch context 
ก่อนสร้างหรือแก้ code ให้ inspect แบบ read-only:
- PRODUCT_PLAN.md
- DESIGN.md
- BUILD_PLAN.md
- Stitch project/screens ที่ฉันระบุว่า approved สำหรับ Module 2 เท่านั้น

รายงาน:
1. screen ที่อ่านและ visual rules ที่จะใช้
2. behavior/state ที่ต้องอ้าง PRODUCT_PLAN.md แทนภาพ
3. สิ่งใดใน Stitch ที่เป็น Module 3, Deferred หรือไม่มีในแผน จึงห้ามสร้าง
4. phase ปัจจุบันและไฟล์ที่อาจเกี่ยวข้อง

ห้ามสร้าง code, เปลี่ยนไฟล์, เพิ่ม route/feature หรือเรียกใช้ screen อื่น
รอให้ฉันอนุมัติรายงานก่อนทำ BUILD_PLAN phase ปัจจุบัน

  1. 1

    รัน connection preflight ตามคู่มือผู้สอน โดยไม่วาง API key หรือ credential ลง repository

  2. 2

    ให้ agent list project/screens และเลือกเฉพาะ M2 foundation screens ที่อนุมัติ

  3. 3

    ให้ agent สรุป visual rules ที่พบและ conflict กับ BUILD_PLAN ก่อนเปลี่ยนไฟล์

  4. 4

    {"\u0E2B\u0E32\u0E01 BLOCKED \u0E43\u0E2B\u0E49\u0E1A\u0E31\u0E19\u0E17\u0E36\u0E01 fallback" => "DESIGN.md + reviewed screenshots \u0E41\u0E25\u0E49\u0E27\u0E44\u0E1B Live preflight"}

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 10 นาที

MCP PASS พร้อมรายการ screen ที่ agent ได้อ่าน หรือ fallback record ที่เดิน lab ต่อได้

Agent ที่บอกว่า “design มีปุ่มนี้” ยังไม่พอ ต้องบอกด้วยว่าปุ่มนั้นอยู่ใน scope และผ่าน gate ไหน

Step 1 · Live preflight

ตรวจเครื่องและ folder จริงก่อนเปลี่ยนอะไร

Technical Bootstrapping Lab เคยพิสูจน์ sandbox แล้ว แต่ project นี้ใช้ folder จริง ให้ AI ตรวจเฉพาะ working directory, version ที่ล็อก, PostgreSQL connection และ browser capability ถ้าผ่านให้ใช้ของเดิมต่อ ถ้าไม่ผ่านให้หยุดพร้อม error ล่าสุด

Prompt · Run the live preflight 
Inspect แบบ read-only ก่อนเริ่ม Phase 1

ตรวจเฉพาะ:
- working directory และไฟล์ระดับบนสุด
- Ruby, Bundler และ Rails version
- PostgreSQL client และ connection จริง
- Git
- AI browser เปิด localhost ได้หรือไม่

เทียบกับ workshop stack แล้วรายงาน PASS หรือ BLOCKED
ห้ามติดตั้ง อัปเดต เปลี่ยน config/PATH หรือเริ่มสร้าง project

PASS จึงไปต่อ; BLOCKED ให้กลับ setup clinic พร้อม error จริง ไม่เริ่มติดตั้งใหม่แบบเดา

Step 2 · Phase 1

สร้าง Rails + PostgreSQL foundation แล้วหยุด

Phase นี้ยังไม่มี feature ให้ AI ยืนยัน target folder และ command ก่อนสร้าง project จริง จากนั้นเตรียม development/test database, วาง PRODUCT_PLAN.md, DESIGN.md และ BUILD_PLAN.md ที่ root รัน baseline tests และเปิด Rails Welcome page

Prompt · Build Phase 1 only 
ทำเฉพาะ BUILD_PLAN Phase 1 ที่อนุมัติแล้ว

ก่อนลงมือ แสดง target folder, rails new command, expected files และ verifier
รอฉันอนุมัติ command แล้วจึง:
- สร้าง Rails project ด้วย PostgreSQL
- วาง PRODUCT_PLAN.md, DESIGN.md และ BUILD_PLAN.md ที่ root
- เตรียม development/test databases
- รัน baseline tests
- เปิด server และตรวจ Rails Welcome page ผ่าน AI browser
- แสดง git status และสรุป diff

ห้ามใช้ SQLite ห้ามติดตั้ง Devise และหยุดเมื่อ Phase 1 ผ่านหรือพบ blocker

  1. 1

    ตรวจ target folder และ command ก่อนอนุมัติ

  2. 2

    ดู database preparation และ baseline test output

  3. 3

    เปิด localhost ด้วยคนและ AI browser

  4. 4

    ตรวจ git status แล้วหยุด

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ ทำตามจริง

Rails + PostgreSQL repository ที่ baseline tests และ Welcome page ผ่าน

Step 3 · Phase 2

เพิ่ม Devise identity ตาม PV-01 แล้วหยุด

Identity ตอบว่า “คุณคือใคร” และเป็น precondition ของข้อมูลส่วนตัว Phase นี้ทำเพียง sign up, sign in, sign out และ protected entry ไม่สร้าง Vault หรือ Asset ล่วงหน้า

Prompt · Build PV-01 identity 
ทำเฉพาะ BUILD_PLAN Phase 2 · PV-01

เสนอไฟล์และคำสั่งที่จะเปลี่ยน พร้อม verifier ก่อนลงมือ
หลังฉันอนุมัติ:
- เพิ่ม Devise
- ทำ sign up, sign in และ sign out
- ให้ protected entry redirect เมื่อยังไม่ sign in
- ใช้ visual rules ที่เกี่ยวข้องจาก DESIGN.md
- รัน tests และตรวจ flow ผ่าน browser
- แสดง diff/status

ห้ามสร้าง Vault, Asset, Search หรือ feature อื่น
หยุดเมื่อ AC ของ PV-01 ผ่านหรือพบ blocker

Login ได้ยังไม่แปลว่าข้อมูลปลอดภัย เรื่อง owner จะถูกสร้างและตรวจใน phase ถัดไป

Step 4 · Phase 3

สร้าง User → Vault → Asset และ ownership ตาม PV-02

ใช้ Data Relationship Draft ที่อนุมัติแล้วสร้าง model, migration และเส้น owner ผู้เรียนต้องตรวจชื่อ field, required rule และ delete behavior ก่อน migration ทุก query ของข้อมูลส่วนตัวต้องเริ่มจาก current user

Prompt · Build PV-02 data foundation 
ทำเฉพาะ BUILD_PLAN Phase 3 · PV-02

อ่าน Data Relationship Draft แล้วเสนอ model, fields, relationships,
migrations, ownership queries และ tests ก่อนลงมือ
ถ้ามี required/unique/delete decision ที่ยังไม่ชัด ให้ถามฉัน ห้ามเดา

หลังอนุมัติ สร้าง User → Vault → Asset และ basic ownership evidence
รัน migration/tests แสดง schema diff และหยุด

ห้ามสร้าง CRUD UI, Search/ISBN หรือ feature อื่น

Phase นี้สร้าง data foundation; Module 3 จะเปิดอธิบาย relation, authorization และ constraint ให้เข้าใจลึกขึ้น

Step 5 · Phase 4

ทำ Vault CRUD เป็น vertical slice แรก

เริ่มจาก PV-03 ให้ผู้ใช้สร้าง ดู แก้ และลบ Vault ของตัวเองได้ครบหนึ่งเส้น รวม empty และ invalid state ที่ AC ระบุ แล้วตรวจ UI กับ DESIGN.md

Prompt · Build PV-03 Vault CRUD 
ทำเฉพาะ BUILD_PLAN Phase 4 · PV-03

เสนอ route, controller concern, views, tests และ browser checks ก่อนลงมือ
หลังฉันอนุมัติ ทำ Vault index/create/read/update/delete ของ current user
พร้อม empty state, validation feedback และ visual rules จาก DESIGN.md

รัน tests เปิด localhost ตรวจ AC ของ PV-03 และแสดง diff/status
ห้ามสร้าง Asset CRUD หรือ Search
หยุดเมื่อ slice นี้ผ่านหรือพบ blocker

หนึ่ง slice ที่จบและตรวจได้ดีกว่าการเปิดงาน Vault กับ Asset พร้อมกันแล้วไม่มีอะไรใช้ได้ครบ

Step 6 · Phase 5

เติม Asset CRUD และ usable states ตาม PV-04/PV-07

เมื่อ Vault slice ผ่านแล้วจึงเพิ่มหนังสือเป็น Asset ภายใน Vault ผู้เรียนต้องทดลองเพิ่ม ดู แก้ ลบ พร้อม first-use, invalid และ feedback ที่เกี่ยวข้อง แต่ยังไม่มี Search

Prompt · Build PV-04/PV-07 Asset slice 
ทำเฉพาะ BUILD_PLAN Phase 5 · PV-04 และ PV-07

เสนอ route, nested ownership scope, views, tests และ browser checks ก่อนลงมือ
หลังฉันอนุมัติ ทำ Asset create/read/update/delete ภายใน Vault ของ current user
พร้อม first-use empty state, invalid feedback และ DESIGN.md

รัน tests ตรวจ AC ผ่าน browser และแสดง diff/status
ห้ามสร้าง Search, ISBN normalization, duplicate detection หรือ external API
หยุดเมื่อ slice นี้ผ่านหรือพบ blocker

ตอนนี้ผู้เรียนเห็น product โตขึ้นจริง: สมัครได้ มี Vault และเก็บหนังสือของตัวเองได้

Step 7 · Phase 6

พิสูจน์ด้วยสอง user, tests และ browser

AI ช่วยเตรียม test data และรัน verifier ได้ แต่คนต้องสลับ Account A/B ทดลอง URL และ behavior ที่ AC ระบุ หลักฐานต้องครอบ ownership, happy, empty และ invalid cases ที่เกิดกับ slice นี้จริง

Prompt · Verify PV-08 
ทำเฉพาะ BUILD_PLAN Phase 6 · PV-08

เสนอ verification checklist ที่ trace กลับ PV-01, PV-02, PV-03, PV-04 และ PV-07
แล้วรอฉันอนุมัติ ก่อน:
- รัน test suite
- เปิด app ผ่าน AI browser
- เตรียม Account A และ B สำหรับ manual isolation check
- ตรวจ happy, empty และ invalid cases ที่ AC ระบุ
- แสดง server output, diff และ git status

คนจะเป็นผู้ทดลอง Account A/B และตัดสินผล
ห้ามแก้ code อัตโนมัติหาก verifier fail ให้หยุดพร้อม evidence

  1. 1

    Account A สร้าง Vault/Asset

  2. 2

    Account B ต้องไม่เห็นหรือแก้ URL ของ A

  3. 3

    ตรวจ cases ที่ AC ระบุและรัน tests

  4. 4

    บันทึก PASS/BLOCKED พร้อม evidence

สิ่งที่ต้องได้จาก Pause นี้ เวลาที่ให้ 20 นาที

Verification record ที่คนอนุมัติ ไม่ใช่คำว่า “done” จาก AI

Step 8 · Checkpoint

ตรวจ diff แล้วค่อยสร้าง GitHub checkpoint

เมื่อทุก verifier ผ่าน ให้ AI สรุปไฟล์ที่เปลี่ยนและสิ่งที่ไม่ควร commit คนตรวจว่าไม่มี secret, database dump หรือไฟล์ที่ไม่รู้ที่มา ก่อนอนุมัติ commit และ push ไป remote ที่ถูกต้อง

สิ่งที่ส่งต่อ

สร้างแล้ว
Rails + PostgreSQL, Devise, ownership, Vault/Asset CRUD และ usable states
หลักฐาน
PRODUCT_PLAN.md, DESIGN.md, BUILD_PLAN.md, tests, browser checks และ GitHub checkpoint
ยังรอ Module 3
PV-05–06 Search/ISBN และผล “มีแล้ว/ยังไม่มี”
Prompt · Prepare the GitHub checkpoint 
เตรียม checkpoint โดยยังห้าม commit หรือ push

แสดง:
- test และ browser evidence ล่าสุด
- git status และ diff summary
- รายการไฟล์ที่จะ commit
- secret, database dump หรือไฟล์ชั่วคราวที่ต้องกันออก
- remote และ branch ปลายทาง
- commit message ที่เสนอ

รอฉันตรวจและอนุมัติก่อน commit
หลัง commit ให้แสดงผล แล้วรออนุมัติอีกครั้งก่อน push

Lab วันนี้ไม่ใช่ core value ทั้งหมด แต่มันคือ foundation ที่ถูกเลือกจาก Product Map และมีความคืบหน้าให้ผู้เรียนเห็นจริง

Module checkpoint

สิ่งที่ต้องนำออกจากห้อง

MyShelf milestone

ProudVault มี PRODUCT_PLAN.md, Stitch visual review, DESIGN.md และ BUILD_PLAN.md ที่เจ้าของอนุมัติ พร้อม Rails + PostgreSQL repository จริงที่มี Devise, User → Vault → Asset, basic CRUD, tests, local evidence และ GitHub checkpoint; Search/ISBN เห็นเป็น Primary Path เต็ม loop ใน Stitch แต่ยังเป็น story ที่สร้างจริงใน Module 3

Deliverable

PRODUCT_PLAN.md ที่มี Product Map, Site Map, Data Relationship และ acceptance criteria ที่อนุมัติแล้ว; Stitch board/screenshots ที่ผ่าน scope review; DESIGN.md; BUILD_PLAN.md; Rails + PostgreSQL repository ที่มี Devise และ basic User → Vault → Asset CRUD พร้อม tests, local evidence และ GitHub checkpoint

Exit gate

อธิบายและแสดงหลักฐานของเส้น Project Intake + live technical preflight → PRODUCT_PLAN.md → human-approved acceptance criteria → Stitch scope review → DESIGN.md → fixed stack decision → BUILD_PLAN.md → Rails build ได้ บอกได้ว่า Search/ISBN เป็น Primary Path ที่เห็นครบใน Stitch แต่จะสร้างใน Module 3, และพิสูจน์ว่า User A ไม่เห็นข้อมูลของ User B, tests ผ่าน, local app ใช้งานได้ และ GitHub checkpoint ไม่มี secret

Module resources
Product Plan Studio + ตัวอย่าง ProudVault → Design Contract Studio + ตัวอย่าง ProudVault → คู่มือผู้สอน Module 2 →

จบ module นี้แล้ว — ไปต่อหรือกลับไปดูภาพรวม

← Module 01 ดูทุก module Module 03 →