Technical Bootstrapping Lab

Part B นี้ต่อจาก Module 1 checkpoint แล้ว ไม่ได้เปลี่ยน Project Intake.md และยังไม่เริ่มสร้าง ProudVault

เป้าหมายคือให้คุณได้เจอ setup ของจริงอย่างปลอดภัย: ใช้ AI ช่วยอ่านปัญหา วางแผน และตรวจหลักฐาน แต่คุณยังเป็นคนอนุมัติสิ่งที่จะเปลี่ยนบนเครื่อง

เมื่อจบ lab คุณควรมี Rails PostgreSQL sandbox ที่ทิ้งได้ และมีผลตรวจสดว่า Ruby, Rails, PostgreSQL, database, tests และ localhost พร้อมเริ่ม Module 2

ใช้ lab นี้กับ supported environment ของ workshop เท่านั้น ผู้สอนต้องประกาศ lane ที่รองรับล่วงหน้า (เช่น macOS หรือ Windows ผ่าน WSL2) พร้อมวิธีติดตั้งที่ตรงกับ lane นั้น หากเครื่องอยู่นอก lane ให้เข้าคลินิกก่อน อย่าสุ่มคำสั่งข้ามระบบปฏิบัติการ

ก่อนเริ่ม: ขอบเขตและกติกา

• สร้าง folder ใหม่สำหรับ rails-pg-sandbox เท่านั้น อย่าเริ่มใน folder ของ ProudVault หรือ project จริง
• ต่อ AI coding tool ให้ทำงานที่ root ของ sandbox และตรวจว่ามันเห็น path นั้นจริง
• ต่อ AI browser capability ที่เปิดและตรวจ URL ได้; ไม่ผูกกับ extension หรือชื่อ browser ใดชื่อหนึ่ง
• ใช้ PostgreSQL บนเครื่องตั้งแต่ต้น ไม่ใช้ SQLite
• อย่าแทนที่ system Ruby, อย่าติดตั้ง Ruby version manager ตัวใหม่แบบสุ่ม และอย่าใช้ sudo เป็นคำตอบแรก
• ห้ามส่งหรือเก็บ password, API key, token, database dump หรือ secret ลงใน project หรือ prompt
• อย่าใช้ PostgreSQL superuser หรือแก้ authentication ทั้งเครื่องเพื่อข้าม error; ระบุ role, host, port และชื่อ database ก่อนทุกคำสั่งที่สร้าง/reset/ลบ database
• แก้ทีละสาเหตุ แล้วรัน verifier เดิมซ้ำ หากติด blocker เดิมเกิน 20–30 นาที ให้หยุด เข้า setup clinic และบันทึกสิ่งที่ลองแล้ว

แผนที่ของสิ่งที่กำลังพิสูจน์

psql มีอยู่ ไม่ได้แปลว่า PostgreSQL server กำลังรัน และ server รันอยู่ ก็ไม่ได้แปลว่า Rails เชื่อมได้แล้ว เราจะตรวจทั้งสามชั้นแยกกัน

ขั้นที่ 1 · Connect workspace และ browser

1. สร้าง working folder ตามที่ผู้สอนกำหนด แล้วเปิด terminal และ AI coding tool ที่ root เดียวกัน
2. ให้ AI รายงาน current working directory และรายชื่อไฟล์/โฟลเดอร์ที่เห็น
3. ให้ AI เสนอไฟล์ทดสอบเล็ก ๆ หนึ่งไฟล์ พร้อม path ที่จะเขียน ก่อนลงมือ
4. อนุมัติแล้วตรวจด้วยตัวเองว่าไฟล์อยู่ใน folder ถูกต้อง จากนั้นลบไฟล์ทดสอบอย่างเจาะจง หรือให้ AI ลบหลังคุณอนุมัติ
5. ต่อ AI browser capability แล้วให้มันเปิด URL ทดสอบและรายงาน title หรือข้อความที่เห็นจริง

ผ่านเมื่อ: คุณชี้ได้ว่า AI เขียนได้ใน folder ไหน และ AI browser พร้อมกลับมาตรวจ localhost URL เดียวกับคุณในขั้นสุดท้าย

ขั้นที่ 2 · Inspect ก่อน install

ก่อนวางแผนติดตั้ง เราต้องรู้ก่อนว่าเครื่องนี้มีอะไรอยู่แล้วและต่างจาก Workshop Version Matrix ตรงไหน เป้าหมายไม่ใช่สำรวจเครื่องทุกซอกหรือแก้ error ทันที แต่เก็บข้อมูลเท่าที่จำเป็นเพื่อไม่ให้ AI ติดตั้งเครื่องมือซ้ำ ทับของเดิม หรือเลือกวิธีที่ผิดกับ operating system นี้

Prompt ด้านล่างจึงทำงานสามอย่าง:

1. จำกัด AI ให้ตรวจแบบ read-only โดยยังไม่เปลี่ยนเครื่อง
2. เปรียบเทียบของที่พบกับ target เดียวกันของทั้ง workshop
3. ส่งต่อ Machine Readiness Report แบบสั้นให้ใช้สร้าง Install Plan ในขั้นที่ 3

NOT FOUND หรือ UNKNOWN เป็นผลตรวจที่ยอมรับได้ ไม่ใช่สัญญาณให้ AI เริ่มติดตั้งเอง

Prompt สำหรับ Inspect เครื่อง

Copy prompt นี้ไปให้ AI แล้วรอจนได้ READY FOR INSTALL PLAN:

ช่วย inspect เครื่องนี้แบบ read-only เพื่อเตรียมเข้า workshop

ตอนนี้ยังห้ามติดตั้ง ถอน อัปเดต เปลี่ยน config/PATH เริ่มหรือหยุด service และห้ามตรวจเรื่องอื่นนอกขอบเขตนี้

Workshop target:
- Ruby 4.0.6
- Bundler 2.7.2
- Rails 8.1.3
- PostgreSQL 18.x
- Git ใช้ version ที่ supported lane รองรับ
- ไม่ติดตั้ง Node.js

ตรวจเฉพาะ:
1. current working directory
2. OS และ CPU architecture
3. current version และ executable path ของ Ruby, Bundler, Rails, psql และ Git
4. มี Ruby version manager ตัวใดที่กำลังใช้อยู่
5. มี package manager หลักตัวใดที่ใช้ติดตั้ง software ได้
6. PostgreSQL major version ใดถูกติดตั้ง และ service รุ่นใดแสดงสถานะ running

ไม่ต้อง:
- ไล่รายชื่อ version manager/package manager ทุกตัวที่ไม่มี
- อ่าน process, PID, port listener, launchd plist, data directory หรือ log
- ตรวจ health/connection ของ PostgreSQL
- สำรวจไฟล์ภายใน project
- เสนอคำสั่งติดตั้งหรือวิเคราะห์สาเหตุเชิงลึกในขั้นนี้
- แนบ raw output ยาว ๆ เว้นแต่มี error ที่ทำให้ตอบรายการข้างต้นไม่ได้

สรุปผลเป็นตารางเท่านั้น:
| Component | Current | Target | Status |

Status ใช้ได้เฉพาะ:
- KEEP — ใช้ของเดิมได้
- CHANGE — มีอยู่แต่ version ไม่ตรง
- INSTALL — ยังไม่มี
- VERIFY AFTER CHANGE — ต้องตรวจใหม่หลังเปลี่ยน dependency ก่อนหน้า
- UNKNOWN — ตรวจไม่ได้จากหลักฐานที่มี

หลังตารางให้สรุปสั้น ๆ:
- Existing tools to reuse
- Changes required
- Conflicts to handle
- Unknowns that block planning (ไม่เกิน 3 ข้อ และใส่เฉพาะข้อที่ทำให้วาง Install Plan ต่อไม่ได้จริง)

หากข้อมูลพอวาง Install Plan แล้ว ให้เขียนว่า READY FOR INSTALL PLAN และหยุดรอผมอนุมัติขั้นต่อไป

Workshop Version Matrix

ทุกคนใน cohort ใช้ target เดียวกัน AI ไม่มีสิทธิ์เลือก latest version หรือเปลี่ยน stack เอง:

หากเครื่องมี version อื่นอยู่แล้ว อย่ารีบถอนหรือลงทับ ให้ AI อธิบายว่าจะเลือก Ruby 4.0.6 ใน project shell อย่างไร, จะรักษา project เดิมบนเครื่องอย่างไร และจะตรวจ PATH ด้วยหลักฐานอะไร

ขั้นที่ 3 · Plan & Approve

ก่อนรันคำสั่งที่ติดตั้งหรือเปลี่ยนระบบ ให้ AI นำ Machine Readiness Report จากขั้นที่ 2 มาเทียบ Workshop Version Matrix แล้วเสนอแผนตาม supported lane คุณต้องอนุมัติแผนนั้นก่อน

Prompt สำหรับ copy ไปใช้กับผล Inspect

แนบ output จริงจากขั้นที่ 2 ต่อท้าย prompt นี้:

อ่าน MACHINE READINESS REPORT จากขั้นที่ 2 แล้วเสนอ Install Plan สำหรับ Technical Bootstrapping Lab เท่านั้น

ตอนนี้ยังไม่มีสิทธิ์รันคำสั่ง ติดตั้ง ถอน อัปเดต เปลี่ยน config/PATH เริ่มหรือหยุด service สร้าง role/database หรือเขียนไฟล์

Workshop target:
- Ruby 4.0.6
- Bundler 2.7.2
- Rails 8.1.3
- PostgreSQL 18.x
- Git ใช้ version ที่ supported lane รองรับ
- PostgreSQL เท่านั้น ไม่ใช้ SQLite
- ไม่ติดตั้ง Node.js

ขอบเขตของแผน:
1. ใช้เฉพาะข้อมูลใน report ห้ามเปิด investigation ใหม่ที่ไม่จำเป็น
2. ใช้ Ruby version manager และ package manager ที่พบอยู่แล้ว ถ้ารองรับ
3. ห้ามแทนที่ system Ruby และห้ามเพิ่ม version manager ตัวที่สอง
4. pin Ruby 4.0.6 เฉพาะ bounded workshop workspace โดยไม่กระทบ project อื่น
5. ติดตั้ง Bundler 2.7.2 และ Rails 8.1.3 ภายใต้ Ruby 4.0.6
6. ติดตั้ง PostgreSQL 18.x โดยไม่ถอนหรือลบ PostgreSQL version/cluster เดิม
7. หาก PostgreSQL เดิมกำลังใช้ port 5432 ให้ระบุเป็น Human Decision Gate ก่อนหยุด service เดิมหรือเปิด service ใหม่
8. หาก PostgreSQL เดิมมีข้อมูลสำคัญหรือผู้เรียนไม่แน่ใจ ให้หยุดและส่งเข้า setup clinic ห้ามวาง data migration ใน Technical Bootstrapping Lab
9. ใช้ local development role ที่ไม่เป็น superuser แต่มี CREATEDB เพื่อให้ Rails สร้าง development/test databases ผ่าน db:prepare
10. ห้ามสร้าง role หรือ database ที่ผูกชื่อ ProudVault ใน Technical Bootstrapping Lab
11. ผลลัพธ์สุดท้ายของแผนคือ disposable rails-pg-sandbox ที่สร้างด้วย --database=postgresql แล้วผ่าน db:prepare, baseline tests และ Rails Welcome page

ก่อนเสนอแผน ให้แสดงเฉพาะ Blocking Decisions ที่คนต้องตอบก่อนลงมือ ไม่เกิน 3 ข้อ
ใส่เฉพาะเรื่องที่ report แสดงว่ามีผลจริง ห้าม invent unknown ทั่วไป

จากนั้นแบ่งแผนเป็นช่วงสั้นตามลำดับ แต่ละช่วงต้องมี:
- Goal
- สิ่งที่จะเปลี่ยน
- Commands ที่เสนอ
- Verifier และ expected result
- Stop condition
- สิ่งที่ต้องให้คนอนุมัติก่อนรัน

กติกาเพิ่มเติม:
- อธิบาย command ที่เปลี่ยน package, workspace config, PATH หรือ service
- ใช้ PATH แบบ project/session-scoped เมื่อทำได้
- ห้ามใช้ sudo, PostgreSQL superuser, password ใน source/prompt หรือแก้ authentication ทั้งเครื่องเป็น shortcut
- ห้ามสำรวจ project files, process/PID, launchd plist, data directory หรือ log เว้นแต่ report ระบุ blocker ที่ทำให้สร้างแผนไม่ได้จริง
- ห้ามเริ่มสร้าง ProudVault, Devise, model, migration ของ product หรือ CRUD
- จบหลังแสดงแผนและเขียนว่า WAITING FOR HUMAN APPROVAL ห้ามรันคำสั่ง

MACHINE READINESS REPORT:
[วางผลจากขั้นที่ 2 ที่นี่]

แผนต้องระบุ:

• Ruby 4.0.6, Rails 8.1.3, Bundler 2.7.2 และ PostgreSQL 18.x
• Ruby version manager หรือ package manager ที่จะใช้ — ใช้ของที่มีอยู่ถ้ารองรับ ห้ามซ้อนหลายตัว
• สิ่งที่แต่ละคำสั่งจะเปลี่ยน: package, PATH, service หรือไฟล์ config
• วิธีเริ่ม/หยุด PostgreSQL service
• local development role ที่ไม่เป็น superuser แต่มี CREATEDB และวิธีเชื่อมโดยไม่ใส่ secret ลง source control
• verifier หลังแต่ละช่วง: version, service status, connection, db:prepare, tests และ browser

หากแผนมี system Ruby replacement, sudo ที่อธิบายไม่ได้, password ในไฟล์ที่จะ commit, superuser shortcut หรือการแก้ authentication ทั้งเครื่อง ให้หยุดและขอแผนใหม่

อ่านแผนแบบเจ้าของเครื่อง

คุณไม่ต้องอธิบาย syntax ทุกคำสั่ง แต่ก่อนอนุมัติต้องตอบได้:

• จะติดตั้งหรือเปลี่ยนอะไร และ scope อยู่ที่ workspace, package, PATH หรือ service ใด
• ของเดิมหรือข้อมูลใดต้องเก็บไว้
• มีคำสั่งหยุด service, overwrite, force, delete, reset หรือเปลี่ยนสิทธิ์หรือไม่
• แต่ละช่วงใช้ verifier อะไร และเมื่อใด AI ต้องหยุด
• Blocking Decisions ไม่เกิน 3 ข้อถูกตอบครบแล้วหรือยัง

หากแผนบอก “ไม่ติดตั้ง Node.js” แต่เครื่องมี Node อยู่แล้ว นั่นไม่ใช่เหตุผลให้ disable หรือถอน Node หากแผนต้องเปลี่ยนหลังเริ่มทำ การอนุมัติเดิมไม่ครอบคลุม change ใหม่

Prompt สำหรับอนุมัติและเริ่มทำ

กรอกคำตอบ Blocking Decisions จากแผนก่อน copy:

คำตอบของ Blocking Decisions:
1. [คำตอบ]
2. [คำตอบ หรือไม่มี]
3. [คำตอบ หรือไม่มี]

ผมอนุมัติให้ทำตาม Install Plan ที่แสดงไว้แล้วตามลำดับทั้งหมด โดยอนุมัติเฉพาะ commands, targets และ changes ที่อยู่ในแผนนั้น

คุณทำทุก phase ต่อเนื่องได้โดยไม่ต้องขออนุมัติซ้ำ เมื่อ verifier ของ phase ก่อนหน้าผ่านตาม expected result

ต้องหยุดและรายงานผลจริงก่อนทำต่อ หาก:
- verifier ไม่ผ่าน
- ต้องเพิ่ม ลบ หรือเปลี่ยน command, target, role, port, config หรือ service จากแผน
- พบข้อมูล/service เดิมที่ Blocking Decision ยังไม่ครอบคลุม
- ต้องใช้ sudo, --force, overwrite, destructive command, เปลี่ยน authentication หรือสิทธิ์นอกแผน
- target path มีไฟล์อยู่แล้วและแผนไม่ได้อนุมัติให้เปลี่ยน

ห้าม disable หรือถอนเครื่องมือเดิมเพียงเพราะ Technical Bootstrapping Lab ไม่ได้ใช้มัน
ห้ามสร้าง ProudVault, product model, product migration, Devise หรือ CRUD
ห้ามลบ sandbox เดิมเพื่อสร้างทับ ให้หยุดและขอ target path ใหม่

เมื่อทุก phase ผ่าน:
1. เก็บ version, database, test, browser และ server-log evidence
2. ให้ผมและ AI browser ตรวจ Rails Welcome page
3. หยุด Rails server
4. จบด้วย READY FOR FINAL READINESS CHECK

ผ่านเมื่อ: คุณตอบ Blocking Decisions ครบ ตรวจว่าแผนไม่มี change เสี่ยงที่ซ่อนอยู่ และส่ง approval ที่มี stop rules ชัดเจน

ขั้นที่ 4 · Execute approved plan

หลังอนุมัติ AI ทำแผนต่อเนื่องได้ตั้งแต่เตรียม Ruby/Rails, PostgreSQL และ local development role ไปจนสร้าง disposable rails-pg-sandbox ด้วย --database=postgresql

ผู้เรียนไม่ต้อง copy command ทีละบรรทัด ให้เฝ้าดูเพียงสามสัญญาณ:

• กำลังทำตามแผน: target, command และผลตรงกับ phase ที่อนุมัติ
• ต้องหยุด: verifier ไม่ผ่านหรือ AI เสนอ change นอกแผน
• พร้อมตรวจ: db:prepare, baseline tests และ Rails server ผ่านครบ

หากเกิด error AI แก้ได้เฉพาะวิธีที่อยู่ในแผนเดิม หากต้องเปลี่ยนวิธี ให้แสดง error, อธิบาย proposed change และกลับไปขอ Human approval ห้าม improvise ด้วย --force, destructive command หรือการสร้าง role/config ใหม่เอง

ผ่านเมื่อ: AI รายงาน READY FOR HUMAN EVIDENCE REVIEW โดยไม่มี unapproved deviation

ขั้นที่ 5 · Verify & Handoff

คนรับหลักฐาน ไม่รับเพียงคำว่า “เสร็จแล้ว”:

• Ruby 4.0.6, Bundler 2.7.2, Rails 8.1.3 และ PostgreSQL 18.x ทำงานใน workshop workspace
• PostgreSQL client, service และ local development role เชื่อมได้จริง
• sandbox ใช้ PostgreSQL และ bin/rails db:prepare เตรียม development/test databases สำเร็จ
• bin/rails test ผ่าน
• ผู้เรียนและ AI browser เห็น Rails Welcome page จาก URL เดียวกัน
• server log แสดง request และ Rails server ถูกหยุดหลังตรวจ

ใช้ prompt นี้รันหลักฐานจากเครื่องปัจจุบัน ไม่อาศัยความจำหรือรายงานเก่า:

ตรวจ Technical Readiness จากเครื่องและ rails-pg-sandbox ที่สร้างจริงตอนนี้

ห้ามติดตั้ง แก้ config เปลี่ยน service หรือซ่อมปัญหาในรอบนี้ หาก check ใดไม่ผ่านให้รายงาน BLOCKED ตามผลจริง

รันและสรุปหลักฐาน:
1. Ruby ต้องเป็น 4.0.6
2. Bundler ต้องเป็น 2.7.2
3. Rails ต้องเป็น 8.1.3
4. PostgreSQL client และ server ต้องเป็น 18.x
5. local development role เชื่อมได้ มี CREATEDB และไม่เป็น superuser
6. rails-pg-sandbox ใช้ PostgreSQL adapter
7. bin/rails db:prepare ผ่านสำหรับ development/test databases
8. bin/rails test ผ่าน 0 failures และ 0 errors
9. เปิด Rails server แล้วให้ผมและ AI browser ตรวจ Rails Welcome page จาก URL เดียวกัน
10. ยืนยัน server log มี request แล้วหยุด Rails server

สรุปเป็นตาราง:
| Check | Expected | Actual | PASS/BLOCKED |

หากผ่านทุกข้อ ให้จบด้วย TECHNICAL READINESS: PASS
หากมีข้อใดไม่ผ่าน ให้จบด้วย TECHNICAL READINESS: BLOCKED แล้วสรุปเฉพาะ:
- phase ที่ค้าง
- verifier ที่ไม่ผ่าน
- error ล่าสุด
- สิ่งที่ลองไปแล้ว
- verifier ที่ควรรันซ้ำหลังแก้

อย่าสร้างไฟล์รายงานหรือ artifact เพิ่ม

ผล PASS ใช้ยืนยัน readiness ในวันนี้ ส่วน Module 2 จะรัน technical preflight สั้น ๆ ซ้ำจากเครื่องจริง เพราะ PATH หรือ service อาจเปลี่ยนได้หลังจบ lab

Day 1 technical readiness gate

ผ่านเมื่อมีหลักฐานครบทุกข้อ:

• AI coding tool ทำงานใน bounded folder ที่ผู้เรียนตรวจ path แล้ว
• AI browser capability เปิดและตรวจ localhost ได้
• Ruby, Bundler และ Rails version ที่ workshop รองรับทำงานใน shell เดียวกัน
• PostgreSQL client มี, service รัน, และ role ที่กำหนดเชื่อมได้
• Rails sandbox ใช้ PostgreSQL ไม่ใช่ SQLite
• db:prepare สร้าง/เตรียม development และ test databases สำเร็จ
• Baseline tests ผ่าน
• ผู้เรียนและ AI browser เห็น Rails Welcome page จาก local server
• Rails server ถูกหยุดหลังตรวจ และผลสุดท้ายเป็น TECHNICAL READINESS: PASS

ถ้ายังไม่ครบ ให้ copy Clinic Handoff จากผล BLOCKED ไปหาผู้สอน ไม่ข้ามไปเริ่ม ProudVault. Sandbox นี้ทำหน้าที่พิสูจน์เครื่อง; Module 2 จะเริ่มงาน product จาก Project Intake และรัน preflight ซ้ำ.