Vibe Coding สอนสร้างเว็บไซต์คอร์สเรียนออนไลน์ พร้อมระบบจ่ายเงินแบบไม่ต้องเขียนโค้ดด้วย VibeKit

ระบบที่สร้างในบทความนี้คือ เว็บไซต์ขายคอร์สเรียนออนไลน์แบบคอร์สเดียว (single-course platform) ที่:

• มีหน้า Home page พร้อมรายละเอียดคอร์สและปุ่มจ่ายเงิน
• ผู้เรียนจ่ายเงินผ่าน Stripe (รองรับ PromptPay และ Credit Card) แล้ว ได้สิทธิเข้าเรียนทันทีแบบอัตโนมัติ ไม่ต้องรอแอดมินกดอนุมัติ
• มีหน้า Dashboard ให้ผู้เรียนไล่ดูความคืบหน้า ทำควิซท้ายบท และมีหน้า Admin สำหรับเพิ่ม/แก้ไขคอร์สและควิซ

ตัวอย่าง Application ที่ใช้งานจริง

ระบบคอร์สเรียนออนไลน์พร้อมระบบจ่ายเงินทำงานยังไง ?

เงื่อนไขการเข้าเรียนออนไลน์ของคอร์สเรียนคือการอัปเดตสิทธิการใช้งาน จากตอนแรกผู้ใช้ที่ Login เข้ามาทุกคนจะได้รับสิทธิเป็น Unverified และเมื่อกดจ่ายเงินสำเร็จผ่าน Stripe Payment Link (ระบบจ่ายเงินผ่าน Stripe รองรับการจ่ายเงินผ่าน PromptPay, Credit Card) ระบบจะอัปเดตสิทธิการใช้งานเป็น จาก Unverified เป็น User ด้วย Activepieces ทำให้สามารถเข้ามาเรียนคอร์สออนไลน์ผ่านหน้า Dashboard ได้

โดยมีการใช้

• VibeKit: Vibe Coding Template ในการขึ้น Project พร้อม Database
• Stripe: Platform รับชำระเงิน สามารถแนบ Link จ่ายเงินในหน้า Home Page ได้เลย
• Activepieces: เป็น No-Code Automation ที่มีหน้าที่รับคำสั่ง Stripe เพื่อไปอัปเดต Role ของผู้ใช้งาน ใน Database (Unverified -> User) ผ่าน API

Flow การทำงานของระบบจ่ายเงิน

[ 1. หน้า Home ] ──> ลูกค้ากดปุ่มสนใจซื้อคอร์ส
 │ 
 ▼ 
[ 2. Stripe Payment Link ] ──> หน้าจ่ายเงินคอร์สเรียนของ Stripe
 │ 
 ▼ 
[ 3. Activepieces ] ──> เมื่อ Stripe ตรวจสอบการจ่ายเงินสำเร็จ ระบบจะไปอัปเดต Role ของผู้ใช้งานจาก Unverified เป็น User ผ่าน API
 │ 
 ▼ 
[ 4. หน้า Dashboard] ──> เมื่อ Login เข้าสู่ระบบสามารถใช้งานได้เลย

เกี่ยวกับ Project

Page ใน Website

• Home page ที่มีรายละเอียดคอร์สเรียน และ Link Stripe สำหรับจ่ายเงิน
• Login ระบบ Login (มีใน Template)
• Learning Platform / Dashboard ต้อง Login มีสิทธิการใช้งานเป็น User / Admin ถึงจะเห็นข้อมูล
• Course Module for Admin ส่วนจัดการคอร์สเรียนสำหรับ Admin ในการเพิ่มข้อมูลคอร์ส, ควิซ

Data Model Diagram (โครงสร้างข้อมูล) (ใช้ใน PRD)

Website สำหรับจัดการข้อมูลคอร์สออนไลน์

Module (หมวดหมู่ของเนื้อหา)
ใช้เก็บหัวข้อหลักใหญ่ ๆ เช่น “พื้นฐานการสร้างระบบด้วย Vibe Coding”

• title ชื่อโมดูล
• slug ชื่อโมดูล (slug)
• description รายละเอียดภาพรวมของโมดูล

Chapter (เนื้อหาบทเรียน)
หนึ่ง Chapter จะอยู่ได้เพียงโมดูลเดียว

• title ชื่อบทเรียนย่อย
• slug ชื่อบทเรียน (slug)
• video_url ลิงก์วิดีโอสอน (เช่น YouTube)
• description เนื้อหาหรือคำอธิบายเพิ่มเติมใต้คลิป
• is_complete เรียนจบหรือยัง
• is_private เนื้อหานี้ต้องจ่ายเงินเท่านั้น หรือดูได้ฟรี

Quiz (แบบทดสอบท้ายบท)
แบบทดสอบผูกอยู่กับบทเรียนย่อยได้เพียงอันเดียว เป็นคำถามพร้อม 4 ตัวเลือกพร้อมเฉลย

• question_text ตัวคำถาม
• choice_a ตัวเลือก A
• choice_b ตัวเลือก B
• choice_c ตัวเลือก C
• choice_d ตัวเลือก D
• correct_answer เก็บค่าคำตอบที่ถูกต้องตรง ๆ เป็น ‘A’, ‘B’, ‘C’, หรือ ‘D’ เพื่อเอาไปเช็กคะแนนได้ทันที

อ้างอิงจาก แนวทางการออกแบบ Database สำหรับการทำ No-Code / Low-Code / Vibe Coding ฉบับเข้าใจง่าย

ระบบจัดการสิทธิการใช้งาน (Roles):

• Visitor: ผู้เยี่ยมชมเว็บไซต์ที่เข้ามาเรียน Lesson ฟรีได้ แต่ไม่สามารถสร้างหรือแก้ไขข้อมูลได้
• Unverified: รอแอดมินอนุมัติเพื่อเข้าระบบเข้ามาเรียน Lesson ฟรีได้ ไม่สามารถสร้างหรือแก้ไขข้อมูลได้
• User: สามารถเข้าถึงข้อมูลคอร์สเรียนในระบบได้
• Admin:
  • จัดการผู้ใช้งานทั้งหมดได้
  • สามารถสร้างและแก้ไขข้อมูลคอร์สเรียนในระบบได้

เทคโนโลยี / เครื่องมือที่ใช้ใน Project

• VibeKit Template: สำหรับการสร้าง Web Application โดยทำงานผ่าน GitHub Codespaces
  อ่านรายละเอียดเพิ่มติมเกี่ยวกับ VibeKit
• Activepieces (Automation tools) สำหรับสร้างระบบส่งข้อมูลจาก Stripe Payment
• Railway (Hosting) สำหรับการ Publish project เพื่อเข้าใช้งานจริง

ค่าใช้จ่ายที่อาจจะเกิดขึ้นใน Project

สำหรับการทำระบบนี้เพื่อใช้งานจริง สามารถแบ่งค่าใช้จ่ายรายเดือนได้ดังนี้:

• Coding Agent (GitHub Copilot) สำหรับใช้ AI ช่วยพัฒนา (Development) ประมาณ $10/เดือน (เริ่มใช้งานได้ฟรี)
• GitHub Codespaces สำหรับใช้รัน Project บน Cloud โดยไม่ต้องติดตั้งโปรแกรม (ใช้งานได้ฟรี 60 ชั่วโมง / เดือน)
• Stripe Payment: ระบบ Payment Gateway ใช้งานได้ฟรี และหัก Percent เมื่อมีการจ่ายเงินจริง
• Hosting (Railway): สำหรับรันระบบจริงให้คนในทีมเข้ามาใช้งาน (Publish) ประมาณ $5/เดือน
• Domain name: ค่าจดโดเมนเนมเพื่อให้ได้ชื่อเว็บไซต์ตามต้องการ (รายปี) ประมาณ 400 – 1,000 บาท

สิ่งที่ต้องเตรียม

• VibeKit template
• Google account
• Activepieces account
• GitHub account

ขั้นตอนการลงมือทำ

แบ่งขั้นตอนการลงมือทำได้ดังนี้

1. Development Stage (ขั้นตอนการพัฒนา): Setup VibeKit, ออกแบบ PRD, การ Vibe Design ด้วย Stitch, และใช้ Vibe Coding สร้าง Database, UI ในการแสดงผล, UI สำหรับ Admin ในการเพิ่มคอร์สลงเว็บไซต์
2. Payment automation การทำระบบจ่ายเงินผ่าน Stripe และ Activepieces เพื่ออัปเดต Role ของ User ทำให้สามารถเข้าเรียนได้ เมื่อระบบยืนยันการจ่ายเงินเรียบร้อยแล้ว
3. Testing Stage (การตรวจสอบ): ทดสอบระบบ (Manual Testing) ตาม Test Case
4. Deployment Stage (ขั้นตอนการใช้งานจริง): สำรองโค้ดผ่าน GitHub, การตรวจสอบก่อนใช้งานจริง และ Deploy ขึ้น Railway

สร้าง Product Requirement Document (PRD) และ Prototype

PRD สำหรับโปรเจกต์นี้จะเน้นไปที่เรื่อง Database Schema เป็นหลัก โดยเราจะใช้ Prompt สั่งให้ AI ช่วยเขียน PRD และ Prototype ให้ก่อนนำไปใส่ไว้ในไฟล์ addons.md ใน GitHub Codespaces (สามารถเพิ่มรายละเอียดอื่น ๆ ได้เช่น UX/UI , Concept etc.)

อ่านเพิ่มเติมเกี่ยวกับการเขียน PRD ฉบับเต็ม

Prompt สำหรับสร้าง PRD

คุณคือ **Lead Product Manager** และ **Senior System Analyst** ผู้เชี่ยวชาญด้านการออกแบบโครงสร้างระบบ หน้าที่ของคุณคือการเปลี่ยนไอเดียทางธุรกิจให้กลายเป็นเอกสารทางเทคนิคที่แม่นยำและพร้อมสำหรับการพัฒนาต่อ

### ภารกิจ (Mission)

สร้างเอกสารในรูปแบบ **Markdown** (.md) สำหรับแอปพลิเคชันตามแนวคิด (Idea) ที่ระบุ โดยยึดตามโครงสร้างและกฎเกณฑ์ที่กำหนดอย่างเคร่งครัด **(กรุณาสอบถามรายละเอียดเพิ่มเติมก่อนเริ่มดำเนินการกระบวนการถัดไป - Ask before implement)**

### โครงสร้างเนื้อหาที่ต้องระบุ (Required Structure)

**1. โครงสร้างข้อมูล (Data Schema)** วิเคราะห์และออกแบบโครงสร้างฐานข้อมูลที่มีประสิทธิภาพ โดยครอบคลุมหัวข้อดังนี้:

- **ความสัมพันธ์ของข้อมูล (Entity Relationship):** อธิบายความเชื่อมโยงระหว่างชุดข้อมูล (เช่น One-to-Many หรือ Many-to-Many)
    
- **การจัดระเบียบข้อมูล (Normalization):** ออกแบบตามหลักการ Normalization ไม่เกินระดับ **3NF** เพื่อลดความซ้ำซ้อนและรักษาความถูกต้องของข้อมูล (Data Integrity)
    
- **รายละเอียดฟิลด์ (Field Specifications):** นำเสนอในรูปแบบ **ตาราง (Table)** ซึ่งประกอบด้วย:
    
    - ชื่อฟิลด์ (Field Name)
        
    - ประเภทข้อมูล (Data Type)
        
    - ข้อกำหนดเพิ่มเติม (Constraints เช่น PK, FK, Unique, Not Null)
        
    - ตัวอย่างข้อมูล (Sample Data)

** ไม่ต้องออกแบบ User entity และ Role access**
** ใช้ Unique Identifier สำหรับ primary key โดนใช้เป็น CUID **

### Format
เขียนในรูปแบบไฟล์ Markdown

รายละเอียด Application
[รายละเอียด Application]

นำข้อมูลส่วนของ Data Model Diagram (โครงสร้างข้อมูล) (ใช้ใน PRD) มาก็อปปี้ใส่ตรงรายละเอียด Application

สิ่งที่ได้รับ AI จะพยายามช่วยออกแบบโครงสร้างข้อมูลที่เหมาะสมกับโจทย์ของงาน โดยการมีสอบถามเกี่ยวกับ Usecase การใช้งาน สามารถอ่านขั้นตอนการออกแบบโครงสร้างข้อมูลด้วยตัวเองที่ แนวทางการออกแบบ Database สำหรับการทำ No-Code / Low-Code / Vibe Coding ฉบับเข้าใจง่าย

Prompt สำหรับสร้าง Prototype ใช้ใน Artifact / Gem ของ LLM Chat

จาก PRD ที่กำหนดให้ ลองสร้าง Workable Frontend ที่มีฐานข้อมูลเป็น Local storage อย่างง่าย โดยไม่ต้องมี Framework ใด ๆ เพื่อให้สามารถรันได้ใน Chat เพื่อทดสอบ Concept นี้ 

ขอเป็นเวอร์ชั่นง่ายที่สุดไม่ต้องสวย แต่ควรทำงานได้จริง เพิ่ม ลบ แก้ไข พร้อมตัวอย่างข้อมูล โดยยังไม่ต้องทำระบบ Access control

Avoid this error
* Blocked form submission to '' because the form's frame is sandboxed and the 'allow-forms' permission is not set.

PRD
[รายละเอียด PRD]

สิ่งที่ได้รับ AI จะพยายามออกแบบ Prototype อย่างง่าย โดยแบบฟอร์มจะมีข้อมูลให้กรอกครบถ้วน ให้ตรวจสอบดูว่ามีข้อมูลที่ต้องการครบมั้ย โดยยังไม่ต้องสนใจเรื่องความสวยงาม

ตัวอย่าง PRD ฉบับเต็มของ Project นี้ ใช้ตอนสร้าง Database

(สังเกตว่าตัวอย่างนี้มีตาราง chapter_progress เพิ่มจาก 3 entity หลักด้านบน ส่วนนี้ AI เพิ่มให้เพื่อรองรับการติ๊ก “เรียนจบแล้ว” แยกตามผู้ใช้แต่ละคน ตามที่อธิบายไว้ในหัวข้อ Data Model ด้านบน)

# Data Schema — Online Course Management Website

## Overview

This document defines the data schema for an online course management website. The system supports structured learning content organized into **Modules** and **Chapters**, with per-chapter **Quizzes** and per-user **progress tracking**.

---

## Entity Relationship Summary

```
Module (1) ──────< Chapter (many)
Chapter (1) ──────< Quiz (1)        [one-to-one: at most one Quiz per Chapter]
Chapter (1) ──────< ChapterProgress (many)   [one per user per chapter]
```

| Relationship | Type | Description |
|---|---|---|
| Module → Chapter | One-to-Many | A module contains many chapters; each chapter belongs to exactly one module |
| Chapter → Quiz | One-to-One | Each chapter has at most one quiz |
| Chapter → ChapterProgress | One-to-Many | Many users can have progress records on one chapter |

---

## Normalization Notes

The schema is designed to **3NF**:

- All non-key attributes depend only on the primary key of their own table (no partial or transitive dependencies)
- `correct_answer` on `Quiz` stores a single enum value (`A`/`B`/`C`/`D`) — choices are co-located with the question since there is exactly one question per quiz record (no separate `choices` table needed at this cardinality)
- `user_id` on `ChapterProgress` is a bare `String` (CUID format) with no FK constraint — the `User` entity is out of scope for this document

---

## Tables

### 1. `modules`

Stores the top-level course groupings.

| Field Name | Data Type | Constraints | Sample Data |
|---|---|---|---|
| `id` | `String` (CUID) | PK, Not Null | `cm9x1a2b3c4d5e6f7g8h9i0j` |
| `title` | `String` | Not Null | `พื้นฐานการสร้างระบบด้วย Vibe Coding` |
| `slug` | `String` | Unique, Not Null | `vibe-coding-fundamentals` |
| `description` | `String` | Nullable | `โมดูลแนะนำแนวคิดและเครื่องมือ Vibe Coding สำหรับผู้เริ่มต้น` |
| `order` | `Int` | Not Null, Default 0 | `1` |
| `created_at` | `DateTime` | Not Null, Default now() | `2025-06-01T09:00:00Z` |
| `updated_at` | `DateTime` | Not Null, auto-update | `2025-06-15T12:30:00Z` |

---

### 2. `chapters`

Stores individual lesson units that belong to a module.

| Field Name | Data Type | Constraints | Sample Data |
|---|---|---|---|
| `id` | `String` (CUID) | PK, Not Null | `cm9x2b3c4d5e6f7g8h9i0j1k` |
| `module_id` | `String` (CUID) | FK → `modules.id`, Not Null | `cm9x1a2b3c4d5e6f7g8h9i0j` |
| `title` | `String` | Not Null | `ติดตั้ง Environment และเครื่องมือที่จำเป็น` |
| `slug` | `String` | Not Null | `install-environment` |
| `video_url` | `String` | Nullable | `https://www.youtube.com/watch?v=abc123` |
| `description` | `Text` | Nullable | `ในบทนี้เราจะติดตั้ง Node.js, VS Code และ extensions ที่จำเป็นทั้งหมด...` |
| `is_private` | `Boolean` | Not Null, Default false | `false` |
| `order` | `Int` | Not Null, Default 0 | `1` |
| `created_at` | `DateTime` | Not Null, Default now() | `2025-06-01T09:00:00Z` |
| `updated_at` | `DateTime` | Not Null, auto-update | `2025-06-15T12:30:00Z` |

> **Note on `slug` uniqueness:** `slug` is scoped to its parent module (a chapter slug must be unique within a module, not globally). Enforce this with a composite unique constraint on `(module_id, slug)`.

> **Note on `is_complete`:** Completion state is not stored here — it is a per-user concern tracked in `chapter_progress` below.

---

### 3. `quizzes`

Stores a single multiple-choice question attached to a chapter.

| Field Name | Data Type | Constraints | Sample Data |
|---|---|---|---|
| `id` | `String` (CUID) | PK, Not Null | `cm9x3c4d5e6f7g8h9i0j1k2l` |
| `chapter_id` | `String` (CUID) | FK → `chapters.id`, Unique, Not Null | `cm9x2b3c4d5e6f7g8h9i0j1k` |
| `question_text` | `String` | Not Null | `ข้อใดคือคำสั่งสำหรับติดตั้ง dependencies ใน Node.js?` |
| `choice_a` | `String` | Not Null | `npm install` |
| `choice_b` | `String` | Not Null | `node install` |
| `choice_c` | `String` | Not Null | `pip install` |
| `choice_d` | `String` | Not Null | `yarn add all` |
| `correct_answer` | `Enum` (`A`,`B`,`C`,`D`) | Not Null | `A` |
| `created_at` | `DateTime` | Not Null, Default now() | `2025-06-01T09:00:00Z` |
| `updated_at` | `DateTime` | Not Null, auto-update | `2025-06-15T12:30:00Z` |

> **One-to-One enforced via:** `UNIQUE` constraint on `chapter_id` — guarantees at most one quiz per chapter at the database level.

---

### 4. `chapter_progress`

Tracks whether a user has marked a chapter as complete. One record per `(user_id, chapter_id)` pair.

| Field Name | Data Type | Constraints | Sample Data |
|---|---|---|---|
| `id` | `String` (CUID) | PK, Not Null | `cm9x4d5e6f7g8h9i0j1k2l3m` |
| `user_id` | `String` (CUID) | Not Null *(no FK — User entity out of scope)* | `cm9x0z9y8x7w6v5u4t3s2r1q` |
| `chapter_id` | `String` (CUID) | FK → `chapters.id`, Not Null | `cm9x2b3c4d5e6f7g8h9i0j1k` |
| `is_complete` | `Boolean` | Not Null, Default false | `true` |
| `completed_at` | `DateTime` | Nullable | `2025-06-10T14:22:00Z` |
| `created_at` | `DateTime` | Not Null, Default now() | `2025-06-08T10:00:00Z` |
| `updated_at` | `DateTime` | Not Null, auto-update | `2025-06-10T14:22:00Z` |

> **Composite Unique constraint on `(user_id, chapter_id)`** — prevents duplicate progress rows for the same user and chapter.

> **`completed_at`** is set to the timestamp when `is_complete` is toggled to `true`, and reset to `null` if unchecked. This enables future analytics (e.g. time-to-complete per chapter).

---

## Prisma Schema Reference

```prisma
model Module {
  id          String    @id @default(cuid())
  title       String
  slug        String    @unique
  description String?
  order       Int       @default(0)
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt

  chapters    Chapter[]
}

model Chapter {
  id          String    @id @default(cuid())
  moduleId    String
  title       String
  slug        String
  videoUrl    String?
  description String?
  isPrivate   Boolean   @default(false)
  order       Int       @default(0)
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt

  module      Module            @relation(fields: [moduleId], references: [id])
  quiz        Quiz?
  progress    ChapterProgress[]

  @@unique([moduleId, slug])
}

model Quiz {
  id            String   @id @default(cuid())
  chapterId     String   @unique
  questionText  String
  choiceA       String
  choiceB       String
  choiceC       String
  choiceD       String
  correctAnswer String   // 'A' | 'B' | 'C' | 'D'
  createdAt     DateTime @default(now())
  updatedAt     DateTime @updatedAt

  chapter       Chapter  @relation(fields: [chapterId], references: [id])
}

model ChapterProgress {
  id          String    @id @default(cuid())
  userId      String    // bare CUID — no FK, User entity out of scope
  chapterId   String
  isComplete  Boolean   @default(false)
  completedAt DateTime?
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt

  chapter     Chapter   @relation(fields: [chapterId], references: [id])

  @@unique([userId, chapterId])
}
```

---

## Out of Scope (Phase 2 Dependencies)

| Item | Reason |
|---|---|
| `User` entity | Intentionally excluded per spec; `user_id` is a bare reference |
| Role-based access control | Out of scope per spec |
| Quiz attempt history | Not specified; `ChapterProgress` only tracks completion, not quiz scores |

ออกแบบ UI แบบ Vibe Design ด้วย Stitch

Stitch เป็น tool จาก Google Labs ที่เราสามารถ Prompt เพื่อ Design Website ได้เหมือน Figma เลย เริ่มต้นใช้งานได้ฟรีที่ https://stitch.withgoogle.com/

เมื่อเปิดใช้งาน Stitch แล้วให้นำข้อมูลเรื่องของ ฟีเจอร์การทำงาน และ รายละเอียดของ Projecct มาใส่เป็น Prompt สำหรับ Stitch โดยเลือก Mode เป็น Web ซึ่ง Stitch จะออกแบบได้ดี ถ้าเราให้รายละเอียดเกี่ยวกับ Mood & Tone และตัวอย่างเว็บไซต์ที่อยากได้

Prompt สำหรับให้ Gemini / Claude / ChatGPT ช่วยร่าง Design Direction

หากไม่มีหัวด้าน Design เลยจะทำให้ Prompt ใน Stitch ได้ลำบาก เราแนะนำให้ใช้ AI ช่วยร่าง Prompt สำหรับใช้งานใน Stitch

ออกแบบ Prompt สำหรับ Vibe Design ด้วย stitch.withgoogle.com โดยมีรายละเอียดดังนี้

เว็บไซต์ [รายละเอียดเว็บไซต์ และหน้าจอที่ต้องการ]

เขียนในรูปแบบ Markdown

โดยสามารถแนบภาพประกอบเข้าไปได้

ตัวอย่าง Prompt สำหรับ Google Stitch ในการออกแบบ UI

### **Master Prompt for "Creative Coding" Single-Course Platform**

**[System Instruction & Brand Identity]** Design a cohesive, ultra-premium web interface for an exclusive, single-course online platform. The entire site is dedicated to selling and hosting only one flagship masterclass called **"Creative Coding"**. The aesthetic must be a fusion of **"Luxury Editorial"** (inspired by Create Academy) and **"Modern Minimalist Tech"** (inspired by Domestika).

**[Visual Language & Style Guide]**

- **Typography:** Use a sophisticated, high-contrast Serif font (e.g., Playfair Display, Bodoni, or Garamond style) for all primary headings to evoke a cinematic and prestigious feel. Pair this with a clean, ultra-minimalist Sans-serif (e.g., Inter or Montserrat) for body text and navigation to maintain a "Tech" edge.
    
- **Color Palette:** A "Warm Dark" or "Obsidian & Cream" theme. Use Deep Charcoal (#121212) or Obsidian Black for backgrounds, complemented by Warm Cream (#FDFBF7) and muted Champagne Gold (#D4AF37) for accents.
    
- **UI Elements:** Use razor-thin borders (0.5px - 1px), generous white space (macro-padding), and sharp or slightly softened corners for a more "Architectural" and structured look.
    

### **PAGE 1: THE Flagship "Creative Coding" LANDING PAGE**

- **Hero Section:** Create a cinematic entrance dedicated solely to the course. Feature an oversized Serif headline: "Creative Coding: Where Logic Meets Art." Below it, a minimalist sub-text describing this exclusive masterclass.
    
- **The Call to Action:** Feature a prominent, luxury-styled **"Enroll in Creative Coding — $499" button** with a gold-leaf border or a subtle shimmering hover effect, designed as the primary conversion goal of the page.
    
- **Course Curator / Master Section:** Design an editorial-style profile section titled "Learn from the Master," featuring a high-quality black-and-white portrait of the industry expert teaching this single class, along with fine Serif typography detailing their background.
    
- **The Curriculum Preview:** A spacious, structured grid layout showing exactly what students will get inside this one course (e.g., 24 Cinematic Lessons, Source Code Archives, Lifetime Access). Include a secondary **"Instant Access" button** at the bottom of this section.
    

### **PAGE 2: THE "Creative Coding" DASHBOARD**

- **Workspace Layout:** A sophisticated two-column student portal designed exclusively for viewing the "Creative Coding" curriculum. The left sidebar is a slim, dark-glass navigation menu. The right main area is a clean, cream-colored workspace for focused learning.
    
- **Curriculum Architecture:** Display the "Creative Coding" course syllabus using an elegant accordion-style interaction.
    
    - **Modules:** Use large Serif titles (e.g., "Module 01: Algorithmic Aesthetics").
        
    - **Chapters:** List below each module with a clean, vertical timeline line, showing icons for video lessons and reading materials (e.g., "Chapter 1.1: Introduction to Visual Math", "Chapter 1.2: Creative Canvas Setup").
        
- **Interactive Quiz Component:** At the end of a chapter, transition to a dedicated Quiz view.
    
    - **The Question:** Displayed in an elegant Serif font: "How does the 'Creative Coding' canvas pattern optimize rendering loops for interactive visual art?"
        
    - **The Options:** Provide **4 distinct selection cards (A, B, C, D)**. Each card should have a minimalist border that turns into a crisp Champagne Gold line when selected.
        
    - **Action Button:** A sleek "Verify My Logic" button at the bottom of the quiz to submit answers.```

ตัวอย่างการออกแบบระบบคอร์สออนไลน์ด้วย Google Stitch

โดยเมื่อสั่งงาน Stitch แล้ว ระบบจะสร้าง Project มาให้ซึ่งสามารถปรับแต่ง Design จนกว่าจะพอใจ และดาวน์โหลดตาม Screen มา Save เก็บไว้ใน Vibe Coding Project โดยในการดาวน์โหลดแต่ละครั้ง ทำซ้ำขั้นตอนนี้ทีละหน้า (Home, Dashboard, Quiz ฯลฯ) จะมีไฟล์ดังนี้

• DESIGN.md (ถาดสี และ Icon ที่ใช้ในระบบ) สามารถคลิกขวาเพื่อ Download text file สำหรับ Brief AI ได้ต่อไป
• Code.html (ตัวอย่าง Website จริง) เป็น HTML file เป็นตัวอย่างสำหรับการสร้าง UI ต่อไป
• screen.png (ตัวอย่าง screenshot ของหน้านั้น ๆ)

ทำ Version Control บันทึก และย้อนการแก้ไขใน Code ด้วย Git

เก็บประวัติการทำงานและสำรองโค้ดด้วยการ Commit และ Push ไปยัง Main บน GitHub การทำ Versioning ด้วย GitHub และการตรวจสอบ Sourcecode

Vibe Coding สร้าง Database (Prompt)

สร้างโครงสร้างข้อมูล และตัวอย่างข้อมูล (ในการทำงาน แต่จะไม่มีบน Production) เพื่อเป็นโครงสำหรับสร้าง UI

[นำข้อความในส่วนของ ตัวอย่าง PRD ฉบับเต็มของ Project นี้ ใช้ตอนสร้าง Database]

สร้าง Database ตาม Project Standard โดยมีการ mock data ตัวอย่างเข้าไปใน Database ด้วย Script seed-mock.ts และตรวจสอบการทำงานหลังทำด้วย "npx prisma validate" และ "npx prisma migrate status"

Plan and Ask before coding

เบื้องหลังการทำงานของ Prompt (คำอธิบาย)

• แก้ไขไฟล์ Schema (โครงสร้างของ Database) ที่ prisma/schema.prisma
• แก้ไขไฟล์ ตัวอย่างข้อมูลทดสอบ ที่ seed-mock.ts
• เพิ่มข้อมูลทดสอบลงใน Database ด้วย
  npm run seed:mock
• สร้าง Migration file เพื่อบันทึกประวัติการสร้าง Database ด้วย
  npx prisma migrate dev --name <ชื่อที่อธิบายการเปลี่ยนแปลง>
• อัปเดต Schema file ให้ตรงกับใน Database ด้วย
  npx prisma generate
• ตรวจสอบผลการทำงานผ่าน
  npx prisma validate && npx prisma migrate status

ตรวจสอบผลการทำงานด้วยการตรวจสอบข้อมูลจำลองใน Database ผ่าน Database viewer

บทความที่เกี่ยวข้อง (ส่วนเสริม)

• การสร้าง Schema ของ Database ใหม่
• การ Migrate Database เมื่อต้องการเปลี่ยนแปลง Schema

Vibe Coding สร้าง Course Online UI ทั้งหมด (Prompt)

IN __(url, page)__, 

WHEN user do __(action)__ THEN __(result)__

__(condition)__

Plan and Ask before coding

ตัวอย่าง Prompt ที่ใช้งานจริง

สร้างหน้า UI โดยใช้ Database Schema ที่มีอยู่

## 1. ฝั่งผู้เรียน (ล็อกอินแล้ว)

### หน้า Dashboard (`/dashboard`)

- เห็นรายการคอร์ส (Module) ทั้งหมดที่มี
    
- แต่ละคอร์สจะโชว์: **ชื่อคอร์ส, คำอธิบายสั้นๆ, จำนวนบทเรียนทั้งหมด, และแถบความคืบหน้า (Progress Bar)** ว่าเรียนไปกี่เปอร์เซ็นต์แล้ว
    
- กดที่คอร์สแล้ว จะเด้งไปหน้าบทเรียนแรกสุดของคอร์สนั้นทันที (`/:module_slug/:lesson_slug`)
    

### หน้ารายละเอียดบทเรียน

- **เนื้อหา:** มีคำอธิบายบทเรียนและคลิปวิดีโอจาก YouTube
    
- **เมนูด้านซ้าย (Sidebar):** รายชื่อบทเรียนทั้งหมดในคอร์สนั้น บทไหนเรียนจบแล้วจะมีเครื่องหมายติ๊กถูก `✓` โชว์ให้เห็น
    
- **แบบทดสอบ (Quiz):** ถ้าบทไหนมีควิซ ผู้เรียนต้องทำควิซและกดส่งคำตอบก่อน ถึงจะกดจบสมบูรณ์ได้
    
- **ปุ่มควบคุม:** มีปุ่ม **"เรียนเสร็จแล้ว" (Mark as Complete)** และปุ่ม **"ย้อนกลับ / ถัดไป" (Prev / Next)** เพื่อเปลี่ยนบทเรียน
    

## 2. ฝั่งผู้ใช้ทั่วไป / ยังไม่ได้ล็อกอิน (Unverified / Unauthenticated)

### หน้าแรก (`/`)

- เห็นรายชื่อคอร์สและบทเรียนทั้งหมด (โชว์ทั้งบทเรียนฟรีและบทเรียน PRO) โดยไม่มีฟีเจอร์ Complete lesson
    
- จัดเรียงลำดับคอร์สและบทเรียนตามหมายเลข (Module 1, Module 2, ...) เป๊ะๆ
    
- **บทเรียนฟรี:** ขึ้นป้ายสีเขว่า "Free" กดเข้าไปดูเนื้อหาได้เลย
    
- **บทเรียน PRO:** ขึ้นป้ายสีเหลือง "PRO" และมีไอคอนกุญแจ `🔒` ไม่สามารถเข้าถึงเนื้อหาได้
    

### หน้าขายของ / ติดล็อก (Paywall)

- ถ้ากดเข้าบทเรียน PRO จะเจอหน้าล็อกเนื้อหา (Paywall) โชว์ไอคอนกุญแจ, คำว่า "Premium Content", รายละเอียดสิทธิประโยชน์, และปุ่มให้เลือกกด **"จ่ายเงินเพื่อปลดล็อก"** หรือ **"ดูบทเรียนฟรีอื่นๆ"**
    
- _ระบบหลังบ้าน:_ ห้ามส่งเนื้อหาของบทเรียน PRO มาที่หน้าบ้านเด็ดขาด (ป้องกันคนแอบแงะดูผ่าน Network Inspector)
    

### เมนูด้านซ้ายในหน้าบทเรียน (Sidebar)

- เห็นบทเรียนทั้งหมดเหมือนกัน แต่บทเรียนที่เป็น PRO จะเป็นตัวหนังสือสีเทา มีไอคอนกุญแจล็อก และมีป้าย PRO แปะไว้ข้างหลัง
    

## 3. ฝั่งผู้ดูแลระบบ (Admin)

### หน้าจัดการคอร์ส (`/dashboard/modules`)

- มีเมนูสำหรับจัดการคอร์สและบทเรียน โดยจะโชว์เลขลำดับนำหน้าชัดเจน (เช่น #1 ชื่อคอร์ส, #2 ชื่อบทเรียน) เพื่อให้จัดเรียงง่าย
    

### ระบบจัดการควิซ (Quiz) ในแต่ละบทเรียน

- ในแต่ละบทเรียนจะมีปุ่มรูปเครื่องหมายคำถาม `?` พอเปิดแล้วจะขยายฟอร์มให้แก้ไขได้ทันทีในหน้านั้นเลย (Inline) ไม่ต้องเปลี่ยนหน้าใหม่
    
- **ในฟอร์มประกอบด้วย:** ช่องใส่คำถาม, ช่องคำตอบ A / B / C / D, และปุ่มวงกลม (Radio button) ให้เลือกข้อที่ถูกต้อง
    
- **การบันทึก:** ถ้าบทเรียนนั้นยังไม่มีควิซ ระบบจะสร้างให้ใหม่ทันที แต่ถ้ามีอยู่แล้วจะเป็นการอัปเดตข้อมูลเก่า
    
- มีปุ่ม **"ลบควิซ" (Delete Quiz)** แยกต่างหาก สำหรับเอาควิซออกจากบทเรียนนั้นๆ
  
  
| User state | Free chapters | PRO chapters |
| --- | --- | --- |
| Not logged in | ✅ | ❌ Paywall |
| Logged in, unverified | ✅ | ❌ Paywall |
| Logged in, user/admin | ✅ | ✅ |

Vibe Coding ปรับ Design ตาม Google Stitch

หลักการคือ เมื่อได้ Design Reference จาก Stitch มาแล้ว (screen.png + DESIGN.md + Code.html) และเก็บไว้ในโฟลเดอร์ reference ของโปรเจกต์เรียบร้อยแล้ว ขั้นตอนต่อไปไม่ใช่การสร้าง UI ใหม่ทั้งหมดจากศูนย์ แต่เป็นการให้ Coding Agent ปรับสไตล์หน้าเพจที่มีอยู่แล้ว โดยอ้างอิงจาก Design System เดิมของโปรเจกต์ (สี, spacing, typography, radius, shadow) และเปลี่ยนไอคอนที่ไม่สอดคล้องกันให้เป็นชุดเดียวกันด้วย Lucide Icon เพื่อให้ภาพรวมของเว็บไซต์มีความสม่ำเสมอ ไม่ใช่แต่ละหน้าลอกสไตล์จาก Stitch มาแบบตรงๆ จนหน้าตาไม่เข้ากัน

Please apply design reference to page
by using design system in project and Lucide icon to implement it

เบื้องหลังการทำงาน

• Agent จะอ่าน Design Reference จาก Stitch (ภาพหน้าจอ / DESIGN.md) เพื่อทำความเข้าใจ layout, spacing, และโทนของดีไซน์
• แทนที่จะก็อปปี้สีหรือฟอนต์จาก HTML ของ Stitch ตรงๆ Agent จะ map ค่าต่างๆ เข้ากับ Design Token ที่มีอยู่แล้วในโปรเจกต์ (เช่น Tailwind theme variable, shadcn component variant) เพื่อให้การเปลี่ยนแปลงยังสอดคล้องกับส่วนอื่นของแอป
• ไอคอนที่ปรากฏใน mockup จะถูกแทนที่ด้วย Lucide Icon แทนการวาง SVG ดิบๆ ทำให้น้ำหนักเส้นและสไตล์ของไอคอนสม่ำเสมอทั้งเว็บไซต์
• เนื่องจากเป็นการปรับสไตล์หน้าที่มีอยู่แล้วเท่านั้น จึงมีความเสี่ยงต่ำ (ไม่แตะ logic หรือการดึงข้อมูล) ทำให้สามารถรันทีละหน้าและตรวจสอบผลลัพธ์ทีละหน้าได้

Tip: ควรระบุคู่ของหน้าเพจและ Reference ให้ชัดเจนเสมอ (เช่น @design_folder/home.png, @page: /) แทนการบอก Agent ว่า “ทำให้เหมือน Stitch” แบบกว้างๆ เพราะการอ้างอิงที่คลุมเครือจะทำให้แต่ละหน้าตีความไม่ตรงกัน

Vibe Coding ส่วนระบบจ่ายเงินอัติโนมัติ

สร้าง Payment Link ด้วย Stripe

สมัครสมาชิก Stripe และยืนยันตัวตนให้เรียบร้อย (กรอกข้อมูลธุรกิจ/บุคคล และบัญชีธนาคารสำหรับรับเงิน) ก่อนที่จะสร้าง Payment Link ที่ใช้งานจริง เพราะ Stripe จะยังไม่ปล่อยเงินหรือเปิดใช้บางช่องทางการจ่ายเงิน (เช่น PromptPay) จนกว่าการยืนยันตัวตนจะเสร็จสมบูรณ์

ขั้นตอน:

1. สมัครบัญชีและยืนยันตัวตน สมัครที่ stripe.com กรอกข้อมูลธุรกิจ/บุคคล และทำตามขั้นตอนยืนยันตัวตนให้ครบ ขั้นตอนนี้อาจใช้เวลาไม่กี่นาทีไปจนถึงหลายวันขึ้นอยู่กับเอกสารที่ต้องใช้
2. สร้าง Product และ Price ใน Stripe Dashboard (Products → Add product) เพื่อกำหนดว่าผู้ใช้กำลังจ่ายเงินเพื่อซื้ออะไร (เช่น สิทธิ์เข้าถึงคอร์ส, สมาชิกรายเดือน)
3. สร้าง Payment Link สำหรับ Product นั้น โดยเปิดใช้ทั้ง PromptPay และ Credit Card ในส่วนตั้งค่าช่องทางการจ่ายเงินของ Link
4. นำ Payment Link มาใส่ในเว็บไซต์ ในรูปแบบปุ่มหรือ CTA ที่พาผู้ใช้ไปยังหน้า Checkout ของ Stripe โดยตรง ไม่จำเป็นต้องสร้างหน้า Checkout เองในขั้นนี้
5. ตรวจสอบและ Approve ด้วยมือ (ก่อนทำ Automation): เมื่อผู้ใช้จ่ายเงินแล้ว ให้เข้าไปดูที่แท็บ Payments ใน Stripe Dashboard เพื่อยืนยันว่ารายการสำเร็จ จากนั้นเข้าไปที่ Dashboard/Backoffice ของแอปเพื่อ Approve role ของผู้ใช้คนนั้นด้วยตัวเอง

ขั้นตอนแบบ manual นี้เป็นจุดเริ่มต้นที่ดีในการตรวจสอบว่า flow การจ่ายเงินทำงานถูกต้องครบวงจรก่อนที่จะไปทำ automation ในขั้นต่อไป ซึ่งเป็นจุดเดียวกับที่หัวข้อถัดไป (Auto Update Role) จะเข้ามาแทนที่

อย่าลืม: ทดสอบด้วย Stripe Test mode ก่อน (การ์ดทดสอบของ Stripe, ไม่มีเงินโอนจริง) แล้วค่อยสลับไป Live mode ตอนพร้อมใช้งานจริง คนที่เพิ่งเริ่มมักสับสนว่าทำไมจ่ายเงินจริงแล้ว Role ไม่อัปเดต ทั้งที่จริงคือ Webhook ยังต่อกับ Test mode อยู่ (ดู FAQ ด้านล่าง)

Vibe Coding สร้าง Feature สำหรับ Update Role User ที่จ่ายเงินสำเร็จแบบอัติโนมัติ

ขั้นตอนนี้เป็นขั้นตอนที่มีความซับซ้อนสูงแต่สามารถลงมือทำเองได้

โดยแบ่งเป็น 2 ขั้นตอน

ขั้นตอนที่ 1 รับข้อมูลการจ่ายเงินจาก Stripe เข้ามาใน Activepieces

สร้าง flow ใน Activepieces ประกอบด้วย node ดังนี้:

Node Trigger Stripe: Checkout Session Completed
ทำงานทุกครั้งที่มีการจ่ายเงินสำเร็จบน Stripe (checkout session เสร็จสมบูรณ์)

Node Router
ตรวจสอบว่า payment_link ID ของ session ที่เสร็จสมบูรณ์นั้น ตรงกับ Payment Link ที่เราต้องการหรือไม่ (เนื่องจากบัญชี Stripe หนึ่งบัญชีอาจมีหลาย Product/Link จึงต้อง filter เฉพาะ Link ที่ควรทำให้เกิดการอัปเกรด role)

Node HTTP
ส่ง request กลับไปที่ API ของเว็บไซต์ พร้อมอีเมลของผู้จ่ายเงิน เมื่อ Router ยืนยันแล้วว่าเป็น Payment Link ที่ต้องการ โดยส่งเป็นเมื่อ Node Router ยืนยันแล้วว่าเป็น Payment Link ที่ต้องการ ให้ตั้งค่า Node HTTP ดังนี้:

• Method: POST
• Header: X-API-KEY: <ค่า webhook secret ของคุณ>
• Body:

{
  "email": "<EMAIL_FROM_STRIPE_NODE>"
}

หมายเหตุ:

• ค่า email ควร map มาจากข้อมูล billing detail ของ trigger Checkout Session Completed แบบ dynamic (คืออีเมลที่ผู้จ่ายเงินกรอกตอน checkout) ไม่ควรใส่แบบ hardcode
• ค่า X-API-KEY ต้องตรงกับค่าที่ API endpoint ต้องการ (USERS_WEBHOOK_API_KEY) ดังนั้นควรเก็บไว้เป็น environment variable/secret ใน Activepieces แทนการวางเป็น plain text
• Node นี้เป็นขั้นตอนสุดท้ายของ flow ซึ่งเป็นตัวที่ยิงไปเรียก POST /users ที่เว็บไซต์ของคุณ เพื่อให้ endpoint จัดการ logic การสร้าง/อัปเดต role ตามที่อธิบายไว้ในขั้นตอนก่อนหน้า

ขั้นตอนที่ 2 สร้าง API endpoint สำหรับรับข้อมูลจาก Activepieces

สร้าง API endpoint แบบ POST /users โดยมีรายละเอียดดังนี้:

**การยืนยันตัวตนและการจำกัดแหล่งที่มา**
- ต้องมี header `X-API-KEY` เพื่อยืนยันตัวตน ใช้ env : USERS_WEBHOOK_API_KEY
- หากไม่มี key หรือ key ไม่ถูกต้อง ให้ตอบกลับ 401 Unauthorized

**Request Body**
- รับ JSON body: { "email": string }
- ตรวจสอบว่ามี email และรูปแบบถูกต้อง (ถ้าไม่ถูกต้อง ตอบกลับ 400 Bad Request)

**Business Logic**
1. ค้นหา user จาก email ในฐานข้อมูล
2. ถ้าไม่พบ user:
   - สร้าง user ใหม่อัตโนมัติด้วย email นี้ และตั้ง role เป็น "user"
3. ถ้าพบ user:
   - ถ้า role ปัจจุบันเป็น "unverified" → เปลี่ยนเป็น "user"
   - ถ้า role ปัจจุบันเป็น "admin" → คงไว้เหมือนเดิม (ห้าม downgrade)
   - ถ้า role ปัจจุบันเป็น "user" → ไม่ต้องทำอะไร (no-op)
4. ปรับแก้ให้ Allow Account via Email

**Response**
- สำเร็จ: ส่งกลับ user object (id, email, role) พร้อม 200 OK
  (ไม่ว่าจะเป็นการสร้างใหม่หรืออัปเดต)
- กรณี error: ส่งกลับ status code และข้อความ error ที่เหมาะสม

เบื้องหลังการทำงาน

• การตรวจสอบ X-API-KEY ทำให้ endpoint นี้ถูกเรียกได้เฉพาะจาก flow ของ Activepieces เท่านั้น ไม่ใช่ใครก็ได้จากภายนอก ควรเก็บ key นี้เป็นความลับเช่นเดียวกับ secret อื่นๆ และห้าม expose ไว้ฝั่ง client เด็ดขาด
• การเปลี่ยน role ถูกออกแบบให้เป็นทิศทางเดียว (unverified → user เท่านั้น ไม่แตะ admin) เพื่อป้องกันไม่ให้ webhook ที่ยิงซ้ำหรือ event ซ้ำมาลด privilege ของ admin โดยไม่ตั้งใจ
• เนื่องจาก webhook จาก Stripe/Activepieces บางครั้งอาจยิง event ซ้ำสำหรับรายการเดียวกัน การทำ “no-op ถ้า role เป็น user อยู่แล้ว” ทำให้ endpoint นี้เป็น idempotent คือเรียกซ้ำกี่ครั้งด้วย email เดิม ผลลัพธ์ก็เหมือนเดิม
• ขั้นตอนนี้คือการปิดวงจรจากการตรวจสอบด้วยมือใน Stripe Dashboard ในหัวข้อก่อนหน้า เมื่อเชื่อมต่อเสร็จแล้ว การจ่ายเงินสำเร็จจะอัปเดต role ของผู้ใช้โดยอัตโนมัติ ไม่ต้อง Approve ด้วยมืออีกต่อไป

For the existing project structure, 
please create a markdown file containing test cases to help users test the app's functionality before launch.

Please run final check and fix issues to ensure that this app can build in production.

You are a pre-deployment verification agent. Your job is to run a complete 
pre-deploy check on this Next.js + Prisma + TypeScript project and report 
the results. 

Run the following checks in order.

---

## Stage 1 — Code Quality

1. [CRITICAL] Run TypeScript type check (no emit):
   npx tsc --noEmit
   → Report: number of errors, list each error with file:line

2. [CRITICAL] Run ESLint:
   npm run lint
   → Report: number of errors/warnings, list each with file:line

3. Run Prettier format:
   npm run format

---

## Stage 2 — Build

4. [CRITICAL] Run production build:
   npm run build
   → Report: whether build succeeded or failed
   → If failed: copy the exact error message and file:line
   → If succeeded: note any warnings (e.g. large bundle sizes, missing metadata)

---

## Stage 3 — Database

5. Check Prisma migration status:
   npx prisma migrate status
   → Report: whether schema is in sync or has pending migrations
   → List any unapplied migrations by name

6. Regenerate Prisma client:
   npx prisma generate
   → Report: success or failure


---

Security Checklist ก่อนใช้งานจริง

รวมจุดที่ต้องระวังตลอดทั้งบทความไว้ในที่เดียว เช็กให้ครบก่อน Deploy จริง:

• USERS_WEBHOOK_API_KEY และ Stripe secret ต้องไม่ hardcode ในโค้ด เก็บเป็น Environment Variable ทั้งใน GitHub Codespace, Railway และ Activepieces เท่านั้น
• endpoint POST /users ต้องปฏิเสธ request ที่ไม่มีหรือ header X-API-KEY ผิด ด้วย 401 เสมอ
• การอัปเกรด role ต้องเป็นทิศทางเดียว (unverified → user) ห้ามมี path ที่ทำให้ admin ถูก downgrade โดยไม่ตั้งใจจาก webhook ที่ยิงซ้ำ
• เนื้อหาบทเรียน PRO ต้องไม่ถูกส่งมาที่ฝั่ง Frontend ก่อนตรวจสิทธิ (เช็กที่ API layer ไม่ใช่แค่ซ่อนด้วย CSS) ป้องกันคนแอบดูผ่าน Network Inspector
• ทดสอบ Stripe ใน Test mode ให้ครบก่อนสลับเป็น Live mode แล้วอย่าลืมตั้งค่า Webhook/Payment Link ใหม่ให้ตรงกับ mode ที่ใช้งานจริง
• อย่า commit ไฟล์ที่มี Stripe key, Database URL, หรือ API key อื่น ๆ ขึ้น GitHub ตรวจสอบ .gitignore ให้ครอบคลุมไฟล์ env ก่อน push ทุกครั้ง

• จ่ายเงินสำเร็จแต่ Role ไม่เปลี่ยนเป็น User: เช็กก่อนว่า Payment Link ที่ใช้จ่ายจริงอยู่ใน Live mode หรือ Test mode ตรงกับที่ตั้ง Trigger ไว้ใน Activepieces หรือไม่ (สาเหตุที่พบบ่อยที่สุด) ถ้าตรงกันแล้วให้เช็ก log ใน Activepieces ว่า Router node ผ่านเงื่อนไข payment_link ID หรือไม่
• ปุ่ม PromptPay ไม่ขึ้นในหน้า Payment Link: มักเกิดจากการยืนยันตัวตนธุรกิจใน Stripe ยังไม่เสร็จสมบูรณ์ ให้เช็กสถานะใน Stripe Dashboard