คู่มือผู้สอน Module 2 · Product Plan & First Build

เป้าหมายของบท

Module 2 ชื่อ Product Plan & First Build รับ Project Intake.md และเครื่องที่ผ่าน Technical Bootstrapping Lab แล้วพาผู้เรียนไปถึง first build ที่ใช้งานและตรวจได้จริง ไม่ใช่แค่เอกสาร และไม่ใช่การให้ AI สร้าง product ทั้งก้อนในครั้งเดียว

เมื่อจบ ผู้เรียนควรทำได้ดังนี้:

1. แปลง Project Intake เป็น PRODUCT_PLAN.md ที่รักษา primary user, trigger, desired outcome, Primary Success Path, Non-goals และ Risk→Evidence เดิม
2. สร้าง Product Map, User Stories, Site Map, งานที่ไม่มีหน้า และ Data Relationship Draft โดยแยก ความสำคัญ ออกจาก ลำดับพัฒนา
3. อนุมัติ Acceptance Criteria ด้วยตนเองในรูป ตั้งต้น → ลงมือ → เห็นผล ก่อนให้ AI สร้าง code
4. ใช้ Stitch ทำให้ Primary Path ครบ loop มองเห็นได้, ตัด invented scope ออก และสกัด DESIGN.md ที่เป็นเจ้าของเฉพาะ visual language โดยไม่เขียนทับ behavior
5. ใช้ fixed workshop stack และให้ AI เสนอ BUILD_PLAN.md แบบแบ่ง phase ที่มี verifier, stopping condition และ forbidden scope ชัดเจน
6. ต่อ Stitch MCP ใน Build Gate เพื่อให้ agent อ่านเฉพาะ design context ที่อนุมัติ หรือใช้ DESIGN.md + screenshots เป็น fallback
7. สร้าง Rails + PostgreSQL project จริง, Devise identity, User → Vault → Asset และ basic CRUD ของ Vault/Asset ตามแผนที่อนุมัติ
8. ตรวจ localhost, tests, diff/status, manual two-user isolation และ GitHub checkpoint ด้วยหลักฐานจริง

Input, output และขอบเขต

Input ที่ต้องเปิดก่อนเริ่ม

• Project Intake.md — product decision ที่ผ่าน Module 1 แล้ว
• Live Technical Preflight — version, PostgreSQL connection และ AI browser ที่ตรวจจากเครื่องปัจจุบัน

อย่าเริ่มติดตั้ง toolchain ใหม่เพียงเพราะ AI อยาก “setup ใหม่ให้สะอาด” หาก preflight ยังผ่าน การตัดสินใจที่ถูกคือใช้ของเดิมต่อ

Output เมื่อจบ Module 2

• PRODUCT_PLAN.md ที่ผ่าน Human Review Gate
• DESIGN.md ที่ผ่าน Human Review Gate
• Stitch board/screenshots ที่ผ่าน Design-to-Plan Review และ MCP/fallback record
• BUILD_PLAN.md ที่บันทึก fixed stack, phase, evidence และ stop rules
• Rails monolith ที่ใช้ PostgreSQL และ Devise
• User → Vault → Asset พร้อม basic ownership และ CRUD ของ Vault/Asset
• หลักฐาน tests, browser checks, manual two-user isolation, Git status/diff ที่อธิบายได้ และ GitHub checkpoint

PRODUCT_PLAN.md ต้องค่อย ๆ โต

หน้าแรกของ Product Plan work ใช้ Generator สร้าง scaffold และเติม Intake Snapshot Section อื่นใช้ PENDING — รอ Human Decision จน classroom เดินมาถึงเรื่องนั้น

ลำดับการเติมคือ Scope → Product Map → Site Map → Data Relationship → Acceptance Criteria → Final Product Plan Check ผู้สอนต้องกันไม่ให้ AI สร้างเอกสารฉบับสมบูรณ์ตั้งแต่ prompt แรก หรือ rewrite section ที่ผู้เรียนอนุมัติแล้ว หลังแต่ละ gate ให้นำเฉพาะ Markdown ที่อนุมัติแล้ว มาวางใน Generator ตรวจ Preview และดาวน์โหลด draft เป็น checkpoint

การสอนไม่เริ่มจากชื่อ section แต่เริ่มจากคำถามสี่ข้อ: ต้องมีงานอะไร, ผู้ใช้เจองานนั้นที่ไหน, อะไรสำคัญและอะไรต้องสร้างก่อน, และจะรู้ได้อย่างไรว่าผ่าน จากนั้นจึงเฉลยว่าคำตอบที่ค่อย ๆ อนุมัติเหล่านี้รวมกันเป็น PRODUCT_PLAN.md

Code boundary

สิ่งที่สร้างใน Module 2 คือ foundation slice: identity, owned data และ CRUD ที่ทำให้ผู้เรียนมีข้อมูลจริงสำหรับพัฒนาต่อ

Search/ISBN ยังเป็น Module 3 แม้ Product Plan ต้องวาง story และ Acceptance Criteria ของมันไว้แล้ว เพราะนั่นคือ Primary Path ที่จะทำเป็น vertical slice และ critical-flow evidence ใน module นั้น

คำอธิบายเชิงลึก เรื่อง stack, request lifecycle, authentication, authorization/ownership, relation, constraint และเหตุผลของ tests อยู่ใน Module 3 ผู้สอนใน Module 2 ให้เพียง mental model ที่พอตรวจแผนและสังเกตหลักฐานได้ ห้ามเปลี่ยน lab นี้เป็น lecture Rails architecture เต็มรูปแบบ

ไม่สร้างใน Module 2: external book API, recommendation, feed, lending, AI import, native app, staging หรือ production deployment เว้นแต่เป็นเรื่องที่ curriculum owner อนุมัติในรอบถัดไป

รูปแบบและเวลาที่แนะนำ

เหมาะกับวันเต็มประมาณ 6–7.5 ชั่วโมงรวมพักและ clinic เพราะเพิ่ม Stitch visual review และ MCP/fallback gate แต่ Technical Bootstrapping Lab ให้ผู้เรียนผ่าน setup ที่มี productive struggle มาแล้ว และ build จริงยังมีจุดต่างรายเครื่องและราย project

ช่วง	เวลาโดยประมาณ	สิ่งที่ทำ	หลักฐานระหว่างทาง
Re-entry จาก Technical Bootstrapping Lab	15 นาที	เปิด Intake + รัน live preflight สั้น ๆ	รู้ว่าเครื่องและ AI browser ยังพร้อม
Product planning	70–85 นาที	Product Map, stories, site map, data draft, AC	PRODUCT_PLAN.md draft ที่เจ้าของตรวจแล้ว
Design + design context	55–65 นาที	Stitch Primary Path → scope review → DESIGN.md → MCP/fallback preflight	visual contract และ approved design context ที่ไม่แย่ง behavior
Plan gate	30–40 นาที	fixed stack, BUILD_PLAN.md, phase approval	phase 1 ได้รับอนุมัติ
First build	120–150 นาที	Rails/PG, Devise, User–Vault–Asset, CRUD	phase evidence ทีละช่วง
Verify + checkpoint	35–50 นาที	tests, localhost, two-user isolation, diff, GitHub	exit evidence ครบหรือระบุ pending
Setup/build clinic	30–45 นาที	แก้ blocker เป็นรายกลุ่ม	error log และ verifier ที่รันซ้ำ

อย่าตัด planning เพื่อให้ทัน code: acceptance criteria ที่ยังไม่ human-approved ทำให้ AI สร้างเร็วขึ้นได้เพียงงานที่ต้องรื้อและตรวจใหม่ทีหลัง

Block map สำหรับสอน

Classroom source อาจกำลังอยู่ระหว่างปรับ จึงใช้ block map นี้แทนการยืนยันจำนวนหน้า ให้ map ไปยัง frame/section ล่าสุดของ classroom ก่อนสอนจริง

Block	แก่นที่ต้องสอน	Pause / หลักฐาน
1. Four questions	เปิดช่องว่างระหว่าง Intake กับของที่ต้องสร้างด้วยสี่คำถามหลัก	ผู้เรียนบอกได้ว่า Module นี้กำลังตัดสินใจอะไร
2. ProudVault breakdown	แตกหนึ่ง Primary Path เป็นงานที่มองเห็นและมองไม่เห็น	เห็นเหตุผลจาก Intake ของแต่ละงาน
3. Scaffold then Scope	เติม Intake Snapshot แล้วตอบเฉพาะ Scope ผ่านสามมุมมอง/หกกลุ่ม	PRODUCT_PLAN.md ที่ section อื่นยัง PENDING
4. Product structure	แยก importance/order, สร้าง Product Map, Site Map และ data draft	structure ที่ไม่ invent งานหรือหน้า
5. Structure gate	คนอนุมัติโครง product ก่อนเขียนเกณฑ์ผ่าน	สี่ section ผ่าน; AC ยัง PENDING
6. Acceptance final gate	AC แบบ observable, Risk→Evidence และ READY/BLOCKED	PRODUCT_PLAN.md ที่คนปิดทีละข้อ
7. Visualize then prune	Stitch ทำ Primary Path ครบ loop → คน tag KEEP/DEFER/REMOVE	screenshots/board ที่ไม่ invent scope
8. Visual contract	สกัด rules จากภาพที่ผ่าน review; reference เป็นทางเลือก	DESIGN.md ที่ไม่ copy brand หรือเปลี่ยน behavior
9. Select build slice	เลือก dependency + visible progress จาก Product Map โดยไม่ลดความสำคัญของ Search	Include/Exclude ที่เจ้าของอนุมัติ
10. BUILD_PLAN anatomy	เห็น Stack Decision, Build Scope, Phases, Evidence Log และ Current Status ก่อนสั่ง AI สร้าง	ผู้เรียนอธิบายหน้าที่ของแต่ละส่วนได้
11. Plan + MCP gate	เติม Stack/Scope/phase แล้วต่อ MCP แบบ read-only หรือบันทึก fallback	approved BUILD_PLAN.md และ design-context record
12. Step-by-step build	preflight → Rails/PG → Devise → relation → Vault → Asset	prompt + evidence + stop หลังทุก phase
13. Verify and checkpoint	two-user isolation, tests, browser, diff และ GitHub	exit rubric + Module 3 handoff

วิธีพาผู้เรียนอ่านช่วง Product Plan

แต่ละช่วงใช้จังหวะเดิมซ้ำ: ตั้งคำถามธรรมดา → แตก ProudVault ให้เห็น → เติม section เดียว → เปิดดูว่าไฟล์โตขึ้นตรงไหน → ให้คนตัดสินใจ อย่า lecture คำว่า Product Map, Site Map หรือ Acceptance Criteria ก่อนผู้เรียนเห็นว่ามันช่วยตอบคำถามอะไร

Talk tracks สำคัญ

Importance ไม่ใช่ build order

ใช้ ProudVault เป็นตัวอย่าง: Search/ISBN คือ core value จึงสำคัญสูง แต่ยังสร้างไม่ได้จนกว่าจะมี account, ownership, Vault และ Asset ให้ค้น ผู้ใช้ไม่ได้มี journey ว่า “ติดตั้ง Devise → สร้าง migration → query” นั่นคือลำดับของทีม

ถามผู้เรียนว่า:

สิ่งนี้สำคัญเพราะผู้ใช้ได้คุณค่า หรือสำคัญเพราะ code อื่นต้องพึ่งมัน?

คำตอบแรกไปช่อง Importance; คำตอบหลังไป Dependency/Build order ทั้งสองอาจเป็น P0 ได้ แต่ห้ามเขียนทับกัน

Page ไม่ใช่ state

หน้าเป็นที่ที่ผู้ใช้เดินทางไปใหม่; state คือเนื้อหาของหน้าปัจจุบันเปลี่ยนตามข้อมูลหรือ action เช่น Empty, validation error, success, loading และผลค้นหา ProudVault ควรรวม Shelf และ Search state ไว้ด้วยกัน ไม่แตก “หน้าผลค้นหา”, “หน้าว่าง”, “หน้าสำเร็จ” โดยไม่มี navigation ใหม่

ให้ผู้เรียนพูดประโยคนี้ก่อนเพิ่ม screen:

ผู้ใช้กดหรือไป URL อะไรจึงเดินทางมาหน้าใหม่?

หากตอบไม่ได้ ให้บันทึกเป็น state ไม่ใช่ page

งานที่มองไม่เห็นก็เป็น product work

Ownership, validation, database constraint, automated test และ manual two-user check อาจไม่มีหน้าให้ถ่าย screenshot แต่เป็นงานที่ป้องกัน Risk→Evidence ได้โดยตรง ใน Product Map ให้เขียน “ไม่มีหน้า” อย่างตรงไปตรงมา ไม่ invent UI เพื่อทำให้ตารางดูครบ

Acceptance Criteria คือ human gate

AI ร่าง AC ได้ แต่ไม่อนุมัติแทนเจ้าของ product ผู้เรียนต้อง Approve, Reject หรือ Request changes ทีละ story ก่อน phase ที่แตะ story นั้นเริ่มได้

เกณฑ์ที่ดีบอก:

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

อย่ารับเกณฑ์แบบ “สร้าง controller/model/table” เพราะเป็น implementation ไม่ใช่ผลที่ต้องพิสูจน์

DESIGN.md เป็นเจ้าของ visual ไม่ใช่ behavior

PRODUCT_PLAN.md เป็นเจ้าของ story, behavior, states, scope และ Acceptance Criteria ส่วน DESIGN.md บอกว่าเมื่อ behavior นั้นเกิดขึ้น หน้าตาควรอ่านง่าย สม่ำเสมอ และเหมาะกับบริบทอย่างไร เช่น token, typography, spacing, component appearance, focus และ mobile consideration

เริ่มด้วย Stitch เพื่อทำ Primary Path ครบ loop ให้เห็น—not เพื่อให้ AI เลือก product แทนเรา ผู้สอนให้ผู้เรียนส่งเฉพาะ plan ที่รับแล้วเข้า Stitch แล้ว review ทุกสิ่งในภาพเป็น KEEP, DEFER หรือ REMOVE เช่น Search/ISBN และ owned/not-owned result เป็น DEFER เพราะอยู่ Module 3 แม้ต้องเห็นครบในภาพ; barcode scan, settings, recommendations, external metadata และ security claim ที่ไม่มี requirement เป็น REMOVE

เมื่อภาพผ่าน scope review จึงสกัด rules ซ้ำ ๆ เป็น DESIGN.md ไม่ต้องให้ผู้เรียนคิด token จากหน้าว่าง หาก rules ยังไม่ชัด ให้เลือก reference หนึ่งแบบจาก shadcn.io/design โดยเทียบ readability, บุคลิก และ component กับบริบทใน Product Plan แล้ว download เป็น REFERENCE_DESIGN.md เพื่ออ่านของจริง แต่ย้ำว่ายังไม่ใช่ contract จากนั้นให้ AI เสนอว่าจะเก็บ ปรับ และตัดอะไร เจ้าของ product ต้องอนุมัติและตรวจ checklist ก่อนใช้ DESIGN.md สร้าง UI เมื่อผ่านแล้วให้ลบไฟล์ reference เพื่อลด source of truth ที่ซ้ำกัน

ถ้า DESIGN.md เริ่มเพิ่ม flow, state, validation rule หรือ feature ใหม่ ให้หยุดและย้ายประเด็นกลับไป Product Plan เพื่อให้ human gate ตัดสินก่อน

Stitch MCP คือ design context ไม่ใช่ source of authority

ให้ต่อ Stitch MCP หลัง PRODUCT_PLAN.md, DESIGN.md และ BUILD_PLAN.md ผ่านแล้วเท่านั้น ผู้เรียนต้องเห็น agent list project/screens และรายงานว่าอ่าน screen ใด, จะใช้ rule ใด, และอะไรขัดกับ build scope ก่อนเริ่มเขียน code MCP ไม่ได้อนุญาตให้ agent clone ทั้ง board หรือเรียก screens ที่ไม่ได้อนุมัติ

ผู้สอนต้องเตรียม paved lane และ preflight ล่วงหน้า: credential เก็บนอก repository, ผู้เรียนไม่ paste API key ใน prompt/code, และ connection ที่ BLOCKED ต้องบันทึก fallback เป็น DESIGN.md + reviewed screenshots แล้วเดิน build ต่อทันที อย่าเปลี่ยนช่วงนี้เป็น workshop ตั้งค่า cloud หรือแก้ auth รายเครื่องจนแผน product หยุดเดิน

Fixed stack ตอนนี้, transfer ทีหลัง

ใช้ Rails monolith + PostgreSQL + server-rendered HTML/Turbo + Devise + Rails tests + Git/GitHub ตาม paved road เดียวกันทั้งห้อง การล็อก stack ลดตัวแปรเพื่อให้ผู้เรียนเห็น relation, ownership และ evidence จริง ไม่ใช่เพราะ stack นี้ถูกต้องสำหรับทุก product ตลอดไป

ให้ผู้เรียนบันทึกใน BUILD_PLAN.md ว่าเลือกนี้ตอบข้อจำกัดใด และ “revisit when” คือเงื่อนไขใดที่ project อื่นอาจต้องเลือกต่างออกไป แต่ห้ามเปลี่ยน stack ระหว่าง workshop

Phase approval และ stop

AI ต้องเสนอแผนก่อนเปลี่ยน code ทุก phase และหยุดเมื่อ verifier ไม่ผ่าน, scope เริ่มไหล, ข้อมูล/credential ไม่ชัด หรือ phase จบแล้วเพื่อรอ human approval

คำพูดที่ใช้ได้:

อย่าซ่อมสามเรื่องพร้อมกัน และอย่าก้าวข้าม phase เพื่อกลบหลักฐานที่ยังไม่ผ่าน

ให้แก้หนึ่ง cause, รัน verifier เดิมซ้ำ, ดู diff แล้วจึงตัดสินใจ phase ต่อไป

Productive struggle จาก Technical Bootstrapping Lab ต้องถูกใช้ต่อ

Technical Bootstrapping Lab ไม่ได้มีไว้ทำให้ทุกคนติดตั้งเหมือนกันหมด แต่เพื่อให้ผู้เรียนเคยเห็นว่า error เป็น evidence และ AI ช่วยอ่าน/ทดลองอย่างเป็นระบบได้ ใน Module 2 อย่า reset เครื่องหรือไล่ลง dependency ใหม่ตามความกลัว ให้รัน preflight, reproduce, แยกปัญหา และใช้ verifier เดิม ถ้าต้องเข้า clinic ให้เก็บ error ล่าสุดและสิ่งที่ลองแล้ว

วิธีคุม Step-by-step Build

Classroom เป็น learner flow หลัก ไม่ต้องส่งผู้เรียนไปอ่าน Guided First Build Lab แยกอีกหน้า ทุก phase มี Prompt, Human approval, verifier และจุดหยุดอยู่ในหน้าหลัก ผู้สอนใช้ส่วนนี้เป็น supervision reference เมื่อกลุ่มต่าง ๆ เดินเร็วไม่เท่ากัน

เหตุผลของ slice วันนี้

Slice ไม่ได้ถูกเลือกเพราะ Auth หรือ CRUD สำคัญกว่า Search/ISBN แต่เพราะ PV-01/02 เป็น dependency ที่ Primary Path ต้องพึ่ง และ PV-03/04/07 ทำให้ผู้เรียนเห็นความคืบหน้าที่ทดลองได้ในวันเดียว PV-05/06 ยังเป็น Core value และต้องคงสถานะ Planned · Module 3 ห้ามอธิบายว่า “เลื่อนไปเพราะทำไม่ทัน”

ก่อนให้ AI เริ่ม

ตรวจว่า PRODUCT_PLAN.md และ DESIGN.md ผ่าน Human Review Gate แล้ว และ BUILD_PLAN.md มีอย่างน้อย:

• Stack Decision Record
• Goal, Story/Requirement IDs และ AC IDs ของทุก phase
• dependency ที่ต้องพร้อม
• รายการไฟล์/concern ที่คาดว่าจะเปลี่ยน
• verifier ที่จะรัน
• stopping condition และ forbidden scope

แผนที่ไม่มี verifier ไม่ใช่แผน build ที่พร้อมอนุมัติ

ลำดับ phase ที่แนะนำ

1. Actual Rails + PostgreSQL project — สร้าง project จริงด้วย PG, bundle, database preparation, baseline test และ localhost
2. Devise identity — sign up, sign in, sign out และหลักฐานว่า session ใช้งานได้
3. Data foundation — User → Vault → Asset, migrations และ data preparation ตามแผน
4. Vault CRUD — PV-03 เป็น vertical slice แรก พร้อม empty/invalid state ที่เกี่ยวข้อง
5. Asset CRUD + usable states — PV-04/PV-07 ภายใน Vault ที่มี owner แล้ว
6. Verify and checkpoint — PV-08, manual two-user isolation, tests, browser, diff/status และ GitHub checkpoint

ผู้สอนต้องถือ boundary นี้ไว้: Search/ISBN ไม่ได้ถูก “เลื่อนเพราะทำไม่ทัน” แต่จงใจอยู่ Module 3 เพื่อให้สอน request/auth/ownership/relations/constraints แล้วนำไปประกอบเป็น Primary Path ใน module เดียวกัน

รูปแบบ supervision ระหว่าง phase

• ให้ผู้เรียนอ่าน AI plan ออกเสียงสั้น ๆ: เปลี่ยนอะไร, ไม่เปลี่ยนอะไร, จะพิสูจน์อะไร
• อนุมัติเฉพาะ phase เดียว ห้าม “ทำ phase 1–6 ให้หมด”
• หลัง AI ทำงาน ให้ดู command output, test result, browser result และ diff ไม่รับคำว่า “done” ลอย ๆ
• ถ้า AI เสนอ migration destructive, reset database, sudo, credential หรือเปลี่ยน dependency version ให้หยุดและ resolve target/impact ก่อน
• หาก phase fail ให้เก็บ error จริงใน evidence log, fix หนึ่งเรื่อง, รัน verifier เดิมซ้ำ
• ผู้ที่ผ่านเร็วให้ช่วย peer inspect evidence ไม่ใช่แถ feature ใหม่

Pause inspection rubrics

Pause A · Product Map และ scope

ตรวจว่า:

• ทุก story/requirement มีที่มาจาก Intake หรือมีป้ายว่า proposal รออนุมัติ
• Core Path, precondition, supporting, usable completeness, protection/evidence และ deferred ไม่ปนกัน
• Importance ไม่ถูกใช้เป็น build order
• Deferred มีเหตุผล ไม่ถูกวางเป็น phase แอบแฝง
• งาน ownership/test/validation ระบุว่า “ไม่มีหน้า” เมื่อเหมาะสม

ผ่านเมื่อผู้เรียนอธิบายได้ว่าอะไรสำคัญที่สุดต่อ outcome และทำไมบางงานที่สร้างก่อนจึงไม่ได้เป็น Primary Path

Pause B · Site Map, state และ data draft

ตรวจว่า:

• screen ใหม่มี navigation/URL/จุดเดินทางใหม่จริง
• empty, error, success, loading และ search result ถูกบันทึกเป็น state ของ screen ที่ถูกต้อง
• Screen ทุกอันชี้กลับ Story/Requirement ID และมี module owner
• Data draft ตอบ User 1—many Vaults, Vault 1—many Assets และเส้น ownership กลับไป User
• คำถาม lifecycle เช่นลบ Vault แล้ว Asset เป็นอย่างไร ถูกบันทึกเป็น decision หรือ question ไม่ใช่ปล่อย AI เดา

ผ่านเมื่อ screen map ไม่บวมและไม่มีงานสำคัญหลุดเพราะมันมองไม่เห็นบน UI

Pause C · Acceptance Criteria human gate

ตรวจว่า AC ของ first-build stories มี starting state, action, observable result และ feedback ที่เกี่ยวข้อง รวมถึง:

• happy path
• first-use/empty state
• invalid input หรือ validation ที่เกี่ยวข้อง
• ownership/data isolation เมื่อมีข้อมูลหลายผู้ใช้
• Risk→Evidence ที่รับมาจาก Intake

ผ่านเมื่อ owner ลงความเห็น Approve/Reject/Request changes ชัด และไม่มี implementation detail ปลอมเป็น criterion

Pause D · DESIGN.md

ตรวจว่า:

• ผู้เรียนเลือก reference ด้วยเหตุผลที่โยงกับผู้ใช้และบริบท ไม่ใช่เพราะชอบ brand อย่างเดียว
• ไฟล์ที่ download ถูกใช้เป็น REFERENCE_DESIGN.md ชั่วคราว ไม่ได้ถูกใช้เป็น contract ทันที
• ทุก component มี visual role และ traceability กลับไป story/criterion
• สี ตัวอักษร spacing focus และ mobile consideration บอกเป็นกติกาที่ใช้ซ้ำได้
• ไม่ copy brand/reference แบบตรง ๆ
• ไม่เพิ่ม behavior, page, flow หรือ future feature
• state ที่ต้องสื่อมี treatment ทางภาพโดยไม่ใช้สีเป็นความหมายอย่างเดียว

ผ่านเมื่อ AI ใช้ file นี้ทำ UI ให้สม่ำเสมอได้ แต่ยังต้องกลับไป PRODUCT_PLAN.md เมื่อต้องตัดสิน behavior

Pause E · Phase evidence

ตรวจทุก phase ว่า:

• ผลลัพธ์ตรง scope ที่อนุมัติ ไม่มี feature อื่นแถมมา
• verifier ที่ระบุใน BUILD_PLAN.md ถูกรันจริงและมี output
• browser แสดง behavior ที่เกี่ยวข้อง ไม่ใช่เพียง server start
• diff/status อธิบายได้ และไม่มี secret/database dump ที่ไม่ควร commit
• phase มี stopping condition ที่ทำงานจริง: ผ่านแล้วหยุดรออนุมัติ

Misconceptions ที่คาดว่าจะพบ

• “Search สำคัญสุด จึงต้องสร้างก่อน” — สำคัญต่อ value แต่ dependencies อาจต้องมาก่อน; เก็บ importance และ order แยกกัน
• “ทุก state คือหนึ่ง page” — ถ้าไม่มีการเดินทางใหม่ มันคือ state ของ page เดิม
• “งานไม่มี UI ยังไม่ต้องคิด” — ownership, validation และ evidence เป็นส่วนที่ทำให้ UI เชื่อถือได้
• “AI เขียน AC แล้วจบ” — owner เท่านั้นที่กำหนดว่า product ผ่านหรือไม่
• “DESIGN.md บอกได้ว่าปุ่มต้องทำอะไร” — visual contract บอกหน้าตา; behavior กลับไป Product Plan
• “เปลี่ยน stack เล็กน้อยไม่กระทบ” — stack ที่ต่างเพิ่มตัวแปรและทำให้ help/verification ในห้องแตกแขนง
• “ผ่าน Technical Bootstrapping Lab แล้วห้ามเจอ error อีก” — Technical Bootstrapping Lab สอนวิธีพบและแก้ error; Module 2 ต้องใช้ evidence log และ verifier อย่างมีวินัย
• “เปิด localhost ได้แปลว่า feature ผ่าน” — ต้องตรวจ criteria, tests, data state, two-user isolation และ diff ด้วย
• “ให้ AI ทำทุก phase รวดเดียวประหยัดเวลา” — ลดรอบอนุมัติ แต่เพิ่มพื้นที่ที่ต้องไล่หาสาเหตุเมื่อผิด
• “CRUD จบแล้วคือ Primary Path จบ” — CRUD เป็น supporting foundation; Search/ISBN และ critical-flow proof อยู่ Module 3

Manual two-user isolation

ทำหลัง CRUD phase โดยใช้ browser profile/session แยกกันหรือ logout/login สลับอย่างชัดเจน:

1. User A สร้าง Vault และ Asset ที่จำได้แน่นอน
2. Sign out แล้ว sign in เป็น User B
3. ตรวจว่า User B ไม่เห็น Vault/Asset ของ A ในรายการปกติ
4. ลองเข้าถึง URL ของ A หากมี URL ที่เดาได้; ระบบต้องไม่เปิดข้อมูลหรืออนุญาตแก้ไข
5. กลับเป็น A และตรวจว่าข้อมูลของ A ยังอยู่และแก้ไขได้ตาม criterion
6. บันทึกผล, user state และหลักฐานที่สังเกตได้ใน Evidence Log

การทดสอบนี้ไม่แทน automated test ของ Module 3 แต่ทำให้ผู้เรียนเห็น risk ownership ใน browser ก่อนเรียนคำอธิบายเชิงลึกและเขียน test ที่รันซ้ำได้

Exit Gate rubric

ด้าน	ผ่านเมื่อ
Product integrity	PRODUCT_PLAN.md รักษา Intake เดิม, scope มีเหตุผล, importance แยกจาก order และ deferred ชัด
Human-approved behavior	AC ของ stories ที่ build ถูกอนุมัติและสังเกตได้; Risk→Evidence ไม่หลุด
Visual contract	DESIGN.md trace กลับ criterion, คุม visual language และไม่แย่ง ownership ของ behavior
Design-to-code boundary	Stitch screens ถูก review เป็น KEEP/DEFER/REMOVE; MCP อ่านเฉพาะ approved screens หรือมี fallback record โดยไม่มี credential ใน repository
Plan discipline	BUILD_PLAN.md ใช้ fixed stack, phase/verifier/stop rule ชัด และมี human approval ก่อนแต่ละ phase
Working first build	Rails + PostgreSQL + Devise ทำงาน; User–Vault–Asset และ basic Vault/Asset CRUD ใช้งานได้ตาม AC ที่อยู่ใน scope
Evidence and safety	tests, localhost, manual two-user check, diff/status และ GitHub checkpoint มีหลักฐานจริง; ไม่มี secret หรือไฟล์ที่อธิบายไม่ได้

ผู้เรียนอาจจบเป็น Plan/design ready · Build clinic pending หรือ Build complete · evidence pending ได้ ต้องบันทึกสถานะจริง ห้ามให้คำว่า “ผ่าน” กลบ evidence ที่ยังขาด

ส่งต่อ Module 3

Module 3 รับ repository, PRODUCT_PLAN.md, DESIGN.md, BUILD_PLAN.md และ evidence log ต่อไปเพื่ออธิบายและทำให้ identity, request, authentication, ownership, relationships, constraints และ isolation tests แข็งแรงขึ้น

Module 3 รับ CRUD foundation ที่ตรวจแล้วไปสร้าง Search/ISBN เป็น Primary Path, ทำ critical-flow evidence และฝึก Git change protocol ระหว่างพัฒนาจริง ห้ามดึง Search/ISBN กลับมาแทรก Module 2 เพียงเพราะมีข้อมูลพร้อมแล้ว