requirementslisted

# Step 1: Requirements (คิดก่อนทำ) **Habit**: H2 — Begin with End in Mind | **Anti-pattern**: Starting to code without knowing what "done" looks like ## Process 0. **Choose requirements intake mode**: Before drafting the PRD, classify the request as one of two modes and state the mode in the PRD notes. | Mode | Use when | Discipline | | ---- | -------- | ---------- | | **Existing-system mode** | The user is changing, extending, integrating with, or debugging a real codebase, workflow, deployment, or documented system | Cite source evidence where available: files, docs, commands, issue links, logs, or user-provided facts. Mark anything not verified from the system as an assumption or open question. | | **Idea-mode** | The user is shaping a raw product, feature, or system idea before implementation exists | Preserve user intent, label assumptions before treating them as constraints, and ask architecture-impacting questions before presenting speculative details as requirements. | If the request mixes both, use **Existing-system mode** for the known system boundary and **Idea-mode** for new proposed behavior. Do not let proposed behavior masquerade as confirmed system fact. 1. **Discover requirements**: Before writing EARS criteria, follow the Interview Protocol (loaded below) to discover requirements through structured conversation. Use adaptive depth — Quick (3 questions) for small scope, Standard (5) by default, Deep (7+) for complex features. Core que