PRODUCT_PLAN.md Studio

PRODUCT_PLAN.md ไม่ใช่เอกสารที่ AI สร้างครบใน prompt เดียว ไฟล์นี้จะค่อย ๆ โตตามสิ่งที่คุณเรียนและอนุมัติใน Module 2

ทุกครั้งที่ใช้ Studio:

เปิด Project Intake.md และร่างล่าสุดจาก Generator
ใช้ prompt ของ section ที่กำลังเรียน
ตรวจข้อเสนอของ AI แล้ว Approve, Reject หรือ Request changes
ขอ output เฉพาะ section ที่อนุมัติแล้ว แล้ววางลง Generator
ดู Preview และดาวน์โหลด draft; section ที่ยังไม่ถึงคงเป็น PENDING

Anatomy กลางของ `PRODUCT_PLAN.md`

ทุก project ใช้ลำดับ section เดียวกัน เพื่อให้คนและ AI รู้ว่า decision แต่ละชนิดอยู่ที่ไหน:

Section	ตอบคำถาม	เติมเมื่อ
1. Intake Snapshot	เราสร้างให้ใคร เพราะอะไร และห้ามเปลี่ยนอะไร	เริ่ม Studio
2. Scope	งานนี้รับใช้รุ่นแรกในฐานะอะไร	Scope lesson
3. Product Map	Story/Requirement อยู่หน้า/function ใด สำคัญและพึ่งอะไร	Stories + priority
4. Site Map	มี page, navigation, state และงานไม่มีหน้าอะไรบ้าง	Page/state lesson
5. Data Relationship Draft	ข้อมูลหลักสัมพันธ์และเป็นของใคร	Data lesson
6. Acceptance Criteria	แต่ละ Story ผ่านเมื่อสังเกตอะไร	Human AC gate
7. Open Decisions	เรื่องใดต้องให้คนตอบก่อนสร้าง	ทุกครั้งที่พบ
8. Deferred / Non-goals	อะไรตั้งใจไม่สร้างรอบนี้	Scope lesson
9. Changelog	คนอนุมัติ decision ใดและเมื่อไร	หลังทุก gate

กติกาการโตของไฟล์

เติมเฉพาะ section ที่ classroom กำลังสอน
Section ที่ยังไม่ถึงให้เขียน PENDING — รอ Human Decision
AI เสนอได้ แต่ห้ามเปลี่ยน decision ที่มีสถานะ APPROVED
หากข้อเสนอแตะ primary user, trigger หรือ desired outcome ให้กลับไปทบทวน Project Intake.md
Product behavior, page, state และ Acceptance Criteria อยู่ที่นี่ ส่วน DESIGN.md เป็น visual contract

ขั้นที่ 1 · สร้าง scaffold จาก Project Intake

รอบแรกเติมเฉพาะ Intake Snapshot แล้วสร้าง heading ที่เหลือไว้ ห้าม AI แตก feature หรือคิด Acceptance Criteria ล่วงหน้า

Prompt · Create PRODUCT_PLAN.md scaffold

อ่าน Project Intake.md แล้วเสนอเนื้อหาสำหรับ Section 1: Intake Snapshot

รอบนี้เติมเฉพาะ Section 1: Intake Snapshot โดยรักษาความหมายเดิมของ:
- Primary user
- Trigger / Pain
- Desired outcome
- Primary Success Path และ end state
- Preconditions / Supporting paths ที่ Intake ระบุไว้
- Non-goals
- Risk → Evidence

ห้ามเปลี่ยน decision เดิม ห้ามเพิ่ม feature มาตรฐานของแอปทั่วไป และห้ามเลือก stack

แสดง Intake Snapshot ที่เสนอให้ผมตรวจ
หากข้อมูลใดไม่มีใน Intake ให้เขียน UNKNOWN และถามผม ห้ามเดา
หลังผมอนุมัติ ให้ส่ง Markdown เฉพาะเนื้อหาภายใน Section 1 โดยไม่ใส่ heading
ห้ามสร้างหรือแก้ไฟล์ ห้ามสร้าง code, DESIGN.md หรือ BUILD_PLAN.md

Human check

Primary user, trigger และ desired outcome ไม่เปลี่ยน
Primary Path ยังมีจุดเริ่มและ end state เดิม
Non-goals และ Risk→Evidence ไม่หาย
Section 2–8 ยังเป็น PENDING
AI ไม่สร้าง feature, page, model หรือ criteria ล่วงหน้า

เมื่อผ่าน ให้เปลี่ยน Changelog เป็น Intake Snapshot · APPROVED

ขั้นที่ 2 · เติม Scope

Scope ไม่ใช่ feature list ให้จัดงานเป็นหกกลุ่ม:

กลุ่ม	ใช้เมื่อ	ProudVault
Core Path	พิสูจน์ desired outcome	ค้นชื่อหรือ ISBN แล้วเห็น “มีแล้ว/ยังไม่มี”
Precondition	ต้องพร้อมก่อน path เริ่ม	account และ sign in
Supporting Path	เตรียมข้อมูลให้ path เดินได้	เพิ่มหนังสือเข้า Vault
Usable Completeness	ไม่มีแล้วระบบดูพังหรือแก้ข้อมูลพื้นฐานไม่ได้	ดูรายการ, empty state, edit/delete, sign out
Protection & Evidence	ปกป้องความถูกต้อง แม้อาจไม่มีหน้า	ownership, validation, constraints, tests
Deferred	ตั้งใจยังไม่สร้าง พร้อมเหตุผล	recommendation, lending, feed, external API

Prompt · Update Scope only

อ่าน Project Intake.md และ PRODUCT_PLAN.md ฉบับปัจจุบัน

ช่วยเสนอการเติมเฉพาะ:
- Section 2: Scope
- Section 8: Deferred / Non-goals
- Section 7: Open Decisions เฉพาะคำถาม scope ที่คนต้องตอบ

จัดทุก item เป็น Core Path, Precondition, Supporting Path, Usable Completeness, Protection & Evidence หรือ Deferred

ทุก item ต้องระบุ Source:
- INTAKE — มาจาก Intake โดยตรง
- DERIVED — จำเป็นเพื่อให้ path เดินหรือระบบใช้ได้ไม่พิการ พร้อมเหตุผล
- PROPOSED — ข้อเสนอใหม่ที่รอเจ้าของ product ตัดสินใจ

ห้ามเติม Product Map, Site Map, Data Relationship หรือ Acceptance Criteria
ห้ามเปลี่ยน Intake Snapshot และ section ที่ APPROVED แล้ว

แสดงข้อเสนอทีละกลุ่มและรอผม Approve, Reject หรือ Request changes
หลังอนุมัติ ให้ส่ง Markdown เฉพาะเนื้อหาของ Section 2, 7 และ 8 แยกกล่องกัน
โดยไม่ใส่ heading และห้ามสร้างหรือแก้ไฟล์

ขั้นที่ 3 · เติม Product Map

แยก Importance ออกจาก Build order:

Importance: งานนี้สำคัญต่อคุณค่าหรือความน่าเชื่อถือแค่ไหน
Dependencies: ต้องพึ่งอะไร
Build order: จึงควรสร้างลำดับใด

Product Map ใช้ schema เดียวกันทุก project:

ID	Source/Group	User Story or System Requirement	Page/Function	Importance	Dependencies	Build order

Page/Function เขียน No page ได้สำหรับ ownership, validation, constraints และ tests

Prompt · Build Product Map

อ่าน Section 1, 2 และ 8 ของ PRODUCT_PLAN.md

เสนอการเติมเฉพาะ Section 3: Product Map ด้วยตาราง:
| ID | Source/Group | User Story or System Requirement | Page/Function | Importance | Dependencies | Build order |

กติกา:
- User Story ใช้รูป “ในฐานะ… ฉันต้องการ… เพื่อ…”
- งานหลังฉากใช้ System Requirement ที่บอกกฎและ Risk ที่ปกป้อง
- ID ต้องสั้นและคงที่
- Importance ใช้ P0 Protect/Unblock, P1 Core value, P2 Usable หรือ Later
- Importance ห้ามใช้แทน Dependencies หรือ Build order
- งานไม่มี UI ให้เขียน No page ห้าม invent หน้า
- Deferred ต้องไม่หลุดเข้า build order ของรอบนี้

ห้ามแก้ Scope, Intake Snapshot หรือ section ที่ APPROVED
แสดงตาราง draft และรายการ assumption ให้ผม Approve, Reject หรือ Request changes
หลังอนุมัติ ให้ส่ง Markdown เฉพาะเนื้อหาของ Section 3 โดยไม่ใส่ heading
และห้ามสร้างหรือแก้ไฟล์

ขั้นที่ 4 · เติม Site Map และ states

หน้าใหม่เกิดเมื่อผู้ใช้เดินทางไปตำแหน่งใหม่ ส่วน Empty, Loading, Error, Success และ Search Result มักเป็น state ของหน้าที่มีอยู่ งานหลังฉากไม่ต้องถูกแปลงเป็นหน้า

Prompt · Map pages, states and invisible work

อ่าน Product Map ที่ APPROVED แล้ว และเสนอการเติมเฉพาะ Section 4: Site Map

ต้องมี:
1. Pages — ชื่อ page, จุดประสงค์ และ Story/Requirement IDs
2. Navigation — ผู้ใช้เดินจาก page ใดไป page ใด
3. States — empty, loading, error, success, validation หรือ result ที่อยู่ใน page เดิม
4. No-page work — ownership, constraints, tests หรืองานหลังฉาก
5. Intentionally absent — page ที่ไม่สร้างในรอบนี้และชี้กลับ Deferred

ก่อนเพิ่ม page ให้ตอบว่า “ผู้ใช้เดินทางมาที่นี่ด้วย action หรือ URL อะไร”
ถ้าตอบไม่ได้ ให้เสนอเป็น state ไม่ใช่ page

ห้ามเพิ่ม dashboard, profile, settings หรือ page pattern ทั่วไปที่ไม่มี Story ID
ห้ามแก้ Product Map เอง หากพบ conflict ให้หยุดและเสนอว่าต้องกลับไปขอ Human Decision ข้อใด
รอผมอนุมัติ แล้วส่ง Markdown เฉพาะเนื้อหาของ Section 4 โดยไม่ใส่ heading
และห้ามสร้างหรือแก้ไฟล์

ขั้นที่ 5 · เติม Data Relationship Draft

ส่วนนี้เป็น product-level relationship ยังไม่ใช่ migration:

Entity A 1 ─── many Entity B
Entity B belongs to Entity A
ทุกข้อมูลที่เป็นของผู้ใช้ต้องมี ownership path กลับไปหา User

Prompt · Draft data relationships

อ่าน Intake Snapshot, Product Map และ Site Map ที่ APPROVED แล้ว

เสนอการเติมเฉพาะ Section 5: Data Relationship Draft:
- Entities และความหมายในภาษาของ product
- Relationships และ cardinality เช่น one-to-many
- Ownership path กลับไปหา User
- Lifecycle questions เช่น create, move, archive/delete และผลต่อข้อมูลลูก
- Required/unique questions ที่คนต้องตัดสินใจก่อน migration

ห้ามเลือกชื่อ table, column type, foreign-key implementation หรือเขียน migration
ห้ามตอบ lifecycle decision แทนเจ้าของ product
สิ่งที่ยังไม่ตัดสินใจให้เพิ่มใน Section 7: Open Decisions

แสดง draft และคำถาม Human Decision ทีละข้อ รอผมอนุมัติ
แล้วส่ง Markdown เฉพาะเนื้อหาของ Section 5 และ 7 แยกกล่องกัน โดยไม่ใส่ heading
และห้ามสร้างหรือแก้ไฟล์

ขั้นที่ 6 · เติม Acceptance Criteria

AI ร่างได้ แต่เจ้าของ product ต้อง Approve, Reject หรือ Request changes ทีละ Story

แต่ละ criterion ใช้รูป:

ตั้งต้น: ผู้ใช้และข้อมูลอยู่ในสถานะใด
ลงมือ: ผู้ใช้หรือ verifier ทำอะไร
เห็นผล: สิ่งใดสังเกตหรือทดสอบได้

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

Acceptance Criteria บอกว่าผู้ใช้ต้องสังเกตเห็นอะไร หรือ verifier ต้องตรวจอะไรได้ ไม่ได้บอกว่าจะเขียน controller, model, table หรือ CSS อย่างไร

Prompt · Draft AC for human decision

อ่าน PRODUCT_PLAN.md ที่ APPROVED ถึง Section 5

ร่าง Acceptance Criteria สำหรับ Story/Requirement ทีละ ID

แต่ละ criterion ต้องมี:
- ตั้งต้น
- ลงมือ
- เห็นผลที่สังเกตหรือทดสอบได้
- Risk/Evidence ที่เกี่ยวข้อง
- Human decision: PENDING

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

ไม่จำเป็นต้องสร้าง criterion ให้ครบทุกสถานการณ์
ห้ามใช้ implementation เช่น controller, model, table หรือ CSS class เป็น criterion
ห้าม claim ผลลัพธ์ที่ software สังเกตไม่ได้

แสดงทีละ Story/Requirement แล้วรอผมตอบ Approve, Reject หรือ Request changes
หลังผมอนุมัติ ให้ส่ง Markdown เฉพาะเนื้อหาของ Section 6 โดยไม่ใส่ heading
และห้ามสร้างหรือแก้ไฟล์
หาก criterion ทำให้ Scope/Product Map ต้องเปลี่ยน ให้หยุดและขอเปิด decision เดิมก่อน

ขั้นที่ 7 · Final Product Plan Check

ขั้นนี้ไม่เพิ่ม requirement ใหม่ แต่ตรวจว่า decision ที่ค่อย ๆ เติมมาพร้อมส่งต่อไปออกแบบและวาง Build Plan หรือยัง Risk ยังคงอยู่ใน Intake Snapshot และต้อง trace ไปยัง Acceptance Criteria หรือ verifier ที่ตรวจได้ ส่วนมาตรฐานการพัฒนา เช่น tests, diff และ phase approval จะกำหนดใน BUILD_PLAN.md

Prompt · Run the final Product Plan check

อ่าน PRODUCT_PLAN.md ฉบับปัจจุบันโดยห้าม rewrite section ที่ APPROVED

ตรวจว่า:
- Intake Snapshot, Scope, Product Map, Site Map และ Data Relationship ไม่ขัดกัน
- Risk จาก Intake แต่ละข้อ trace ไปยัง Acceptance Criteria หรือ verifier ที่ตรวจได้
- Deferred / Non-goals ไม่หลุดกลับเข้า Product Map หรือ build order
- ไม่มี Open Decision ที่ block การออกแบบหรือสร้าง
- Section ที่ต้องใช้ต่อผ่าน Human Decision แล้ว

จากนั้น audit Section 1–9 โดยรายงาน:
- COMPLETE — มีข้อมูลและผ่าน Human Decision
- PENDING — ยังรอ decision แต่ไม่ block งานถัดไป
- BLOCKED — ขาด decision ที่ทำให้ยังสร้างไม่ได้
- CONFLICT — section ขัดกัน ต้องกลับไปเปิด decision เดิม

ห้ามแก้ conflict เอง แสดงสิ่งที่ขัดและรอผมตัดสินใจ
หลังผมอนุมัติ ให้ส่งรายการแก้ไขที่ผมต้องนำกลับไปวางใน Generator โดยไม่แก้ไฟล์เอง
จบด้วย PRODUCT PLAN: READY หรือ PRODUCT PLAN: BLOCKED ตามหลักฐานจริง

Final Human Review Gate

เมื่อ Gate นี้ผ่าน จึงสร้าง DESIGN.md, Stack Decision และ BUILD_PLAN.md

สร้าง `PRODUCT_PLAN.md` ของคุณ

หลังจบแต่ละขั้น ให้นำเฉพาะผลที่คุณอนุมัติแล้วมาใส่ใน section ที่ตรงกัน Generator จะประกอบ heading, สถานะ และ Changelog ให้เอง พร้อมบันทึกร่างไว้เฉพาะใน browser เครื่องนี้

เริ่มประกอบ PRODUCT_PLAN.md PRODUCT PLAN: BLOCKED

ชื่อ project

1 Intake Snapshot

วางผลจากขั้นที่ 1 โดยไม่ใส่ heading ของ section