@jakkrichm/create-nexus-devflow 2.17.9 → 2.18.0

package/template/.agents/skills/explore/SKILL.md

@@ -1,78 +0,0 @@
----
-name: explore
-description: "[devflow] Explore an idea against the actual codebase without changing files. Investigate whether a change would help, compare alternatives and tradeoffs, and discuss uncertainty before deciding whether to plan anything. Use for /explore, considering an idea, or weighing options without writing a spec."
-argument-hint: "[<idea or question>]"
----
-
-# explore - investigate an idea before deciding to build
-
-**Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
-
-Explore is a read-only conversation grounded in the actual project. It can help
-with questions such as whether caching would help a dashboard, whether teams
-belong in the product, or which upload approach fits existing code.
-
-No plans or active feature are required. Do not require `/overview`, invent a
-plan, or treat missing DevFlow context as a blocker to discussing the idea.
-This command never writes activity state, including `devflow/.state/run.json`.
-
-## Start from the question
-
-Use the supplied topic or relevant conversation context. With neither, ask what
-the user wants to investigate. For a vague idea, state a tentative interpretation
-and ask a focused question only when its answer changes the investigation.
-
-Reuse context already loaded in the session. Read relevant project instructions,
-code, tests as text, manifests, and existing plans when they help answer the
-question. Follow the actual implementation far enough to support your claims;
-point to concrete files or symbols. Avoid scanning unrelated parts of the repo.
-Read-only Git inspection can establish what exists or is already in progress.
-
-Authoritative documentation lookup is appropriate when technical uncertainty
-needs it. Distinguish documented facts from what this project actually uses.
-Missing code or evidence is an uncertainty to explain, not permission to execute
-an experiment or to invent current behavior.
-
-## Discuss the options
-
-Keep the conversation proportional to the question. Compare plausible options
-against the user's needs and existing project constraints. Include doing nothing
-when the current behavior may already be sufficient. Do not invent scale,
-security requirements, or new abstractions to justify a change.
-
-Explain the strongest case against your recommendation and how confident you
-are. Separate observed facts, assumptions, and unanswered questions. Say what
-evidence could change the recommendation without gathering it through execution.
-An unresolved question or a recommendation to leave the project alone is a valid
-outcome.
-
-Use a small diagram in the response when it makes a relationship or tradeoff
-clearer. Do not create diagram files. There is no mandatory output template,
-report, question count, or next-step checklist. Follow the user's responses and
-let the discussion continue as long as useful.
-
-## Keep the boundaries clear
-
-- Never create, edit, or delete files, including specs, plans, notes, generated
-  output, and activity state. Do not save the conversation into the project.
-- Never install dependencies, execute product code, run tests or builds, start
-  servers, perform browser interactions, or call state-changing tools. Read
-  source and existing evidence instead of testing a hypothesis by execution.
-- Never create or switch branches, commit, merge, push, publish, or deploy.
-- Never turn a request to discuss an idea into approval to plan or implement it.
-  If the user asks for changes, explain the appropriate handoff and keep this
-  Explore invocation read-only. Do not invoke another command automatically.
-
-## Neighbors and handoff
-
-- `/brief` explains an existing build-plan item, its scope, dependencies, and
-  size. Explore can discuss an unplanned idea or question a planned approach.
-- `/discovery` develops broader product direction and reviewed planning drafts.
-  Explore does not draft either planning file.
-- `/debug` reproduces and isolates an actual failure. Explore discusses options
-  without executing code to diagnose or verify them.
-- `/feature` writes a buildable spec; `/fix` specifies a confirmed small change.
-  Suggest the appropriate command only when the user is ready to proceed.
-
-Do not force a handoff at the end of every response. Keep discussing the idea
-when that is what the user wants, and leave the project unchanged.

package/template/.claude/skills/check/reference/verify.md

@@ -1,129 +0,0 @@
-# Check verification
-
-**Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
-
-Verification activity was started by the dispatcher before loading this reference.
-
-Where this sits in the workflow:
-
-    /implement  ->  [check]  ->  /complete
-    (built a       (run the app,    (only once the
-     step or        prove each       done-whens are
-     the feature)   done-when)       proven)
-
-`/implement` builds and does a quick build-plus-screenshot check inline. `/check`
-is the deeper, repeatable gate for when a "done when" needs the *real running app*,
-not just a green build: a click that triggers a download, a route that returns a
-file, a flow across screens. Run it on a single step whose done-when is
-behavioral, or on the whole feature as the acceptance check before `/complete`.
-
-The point is evidence. A passing build proves the code compiles; `/check` proves
-the thing the spec promised actually happens. It changes no source and commits
-nothing - it runs the app and reports what it saw.
-
-## Input
-
-Optional: a specific thing to check (a step, a flow, a URL). With no argument,
-verify the whole current feature against every "done when" in
-`devflow/context/{xxx-slug}/spec.md`.
-
-## Step 1 - build the checklist
-
-Read `devflow/config.json` first. A missing file means the built-in defaults
-apply. If the file exists but is invalid, stop and point the user to `/doctor`.
-Configuration never grants permission to start a server or take any other action
-that the project instructions or user have not authorized.
-The quality-gate config controls automatic invocation only. An explicit `/check`
-or `$check` request always runs.
-
-Read `devflow/context/{xxx-slug}/spec.md`. Pull the observable "done when"
-criteria from the build steps (and any acceptance notes in the Testing section).
-Turn them into a concrete checklist of claims to prove - each one a specific,
-observable behavior, not "it works". If the user named one thing, scope to that.
-
-If there's no active feature spec, ask what to verify rather than guessing.
-
-## Step 2 - get the app running
-
-Use the project's real commands (see Commands in `AGENTS.md`). Match the project
-type:
-
-- **Web app** - start (or reuse) the dev/preview server, then drive a real browser
-  to the relevant routes. Prefer reusing an already-running server over starting a
-  duplicate. If `AGENTS.md` declares `Browser tests: <command>`, run that exact
-  command as repeatable evidence and use its harness for covered interactions.
-  Reuse runner-owned server lifecycle instead of starting a duplicate. A green
-  suite is one evidence source, not proof of claims it does not observe. If no
-  command is declared but Playwright is already installed, prefer it for browser
-  driving, screenshots, console errors, and failed request checks. Never install
-  it from `/check`; use another real-browser evidence path and report what you
-  used, or point to `/browser-tests` for later optional setup.
-- **CLI** - run the actual command(s) with representative inputs.
-- **Server/API** - start it and hit the endpoints.
-- **Library** - exercise the public API through an example or the test command.
-
-If a `test` command is declared in `AGENTS.md`, you may run it as *one* input, but
-`/check` is broader than unit tests: it checks real behavior, which is exactly the
-evidence UI and integration steps ride on instead of unit tests.
-
-## Step 3 - exercise each claim
-
-Drive the app to each checklist item and capture evidence as you go:
-
-- Navigate and interact for real (click, type, submit, download) - don't assert
-  from the code what the running app would do.
-- Capture **screenshots** for visual/UI claims, **output** for CLI/API claims.
-- Watch for **console errors and failed network requests**; a clean-looking screen
-  with errors in the console is not a pass.
-
-With `verification.uiEvidence: "required"`, every UI claim needs direct browser
-evidence, including a screenshot and the relevant console and network check. If
-that evidence path is unavailable, mark the claim unverifiable instead of
-passing it from build output. With `when-available`, use the strongest available
-evidence and report any gap plainly.
-
-### AC-to-Test Traceability Verification:
-Cross-reference each Acceptance Criterion (`- [ ] **AC-N**`) in `spec.md` against the test suite's executed assertions and observable evidence:
-- Match tagged test cases (e.g. `it('AC-1: ...')`) to their respective criteria.
-- Ensure 100% of defined acceptance criteria have empirical proof before issuing a `verified` status.
-
-
-## Step 4 - report
-
-Give a short, honest verdict, one line per checklist item:
-
-    [pass] Download PDF saves certificate-<slug>.pdf - file downloaded, opened to the cert
-    [pass] Both buttons show a loading state - screenshot: loading-state.png
-    [fail] PDF border missing - printBackground not set; screenshot: pdf-no-border.png
-    [skip] Vercel render - can't verify locally (feature 9)
-
-Then state the bottom line: are all the feature's done-whens proven, or not yet.
-
-- All proven -> update only the `**Status:**` line in
-  `devflow/context/{xxx-slug}/spec.md` to `verified`, then say it is ready for
-  `/complete`.
-- Anything failed -> update only that status line to `verification failed`, then
-  hand back to `/implement`; name what to fix. Do not fix it here.
-- Anything unverifiable -> update only that status line to `verification
-  incomplete`, then say why; never report it as a pass.
-
-The status-line update is generated workflow state, not a product-source edit.
-Do not change the spec, checkboxes, findings, or product files from `/check`.
-
-## Rules
-
-- **Observe product behavior, don't repair it.** `/check` changes only the
-  current spec's status line as described above. It never edits product source,
-  commits, or merges. Fixing is `/implement`'s job.
-- **Evidence or it didn't happen.** Every `pass` is backed by something observed -
-  a screenshot, output, a response. No assumed passes from reading the code.
-- **Honest over green.** "Couldn't verify" and "failed" are valid, useful results.
-  Faking a pass defeats the entire gate.
-- **Check the spec, not vibes.** Verify against the done-whens in
-  `spec.md`, so "works" means what the spec said it would do.
-
-## Formatting
-
-Format the output to match the project's conventions in
-`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
-enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/explore/SKILL.md

@@ -1,78 +0,0 @@
----
-name: explore
-description: "[devflow] Explore an idea against the actual codebase without changing files. Investigate whether a change would help, compare alternatives and tradeoffs, and discuss uncertainty before deciding whether to plan anything. Use for /explore, considering an idea, or weighing options without writing a spec."
-argument-hint: "[<idea or question>]"
----
-
-# explore - investigate an idea before deciding to build
-
-**Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
-
-Explore is a read-only conversation grounded in the actual project. It can help
-with questions such as whether caching would help a dashboard, whether teams
-belong in the product, or which upload approach fits existing code.
-
-No plans or active feature are required. Do not require `/overview`, invent a
-plan, or treat missing DevFlow context as a blocker to discussing the idea.
-This command never writes activity state, including `devflow/.state/run.json`.
-
-## Start from the question
-
-Use the supplied topic or relevant conversation context. With neither, ask what
-the user wants to investigate. For a vague idea, state a tentative interpretation
-and ask a focused question only when its answer changes the investigation.
-
-Reuse context already loaded in the session. Read relevant project instructions,
-code, tests as text, manifests, and existing plans when they help answer the
-question. Follow the actual implementation far enough to support your claims;
-point to concrete files or symbols. Avoid scanning unrelated parts of the repo.
-Read-only Git inspection can establish what exists or is already in progress.
-
-Authoritative documentation lookup is appropriate when technical uncertainty
-needs it. Distinguish documented facts from what this project actually uses.
-Missing code or evidence is an uncertainty to explain, not permission to execute
-an experiment or to invent current behavior.
-
-## Discuss the options
-
-Keep the conversation proportional to the question. Compare plausible options
-against the user's needs and existing project constraints. Include doing nothing
-when the current behavior may already be sufficient. Do not invent scale,
-security requirements, or new abstractions to justify a change.
-
-Explain the strongest case against your recommendation and how confident you
-are. Separate observed facts, assumptions, and unanswered questions. Say what
-evidence could change the recommendation without gathering it through execution.
-An unresolved question or a recommendation to leave the project alone is a valid
-outcome.
-
-Use a small diagram in the response when it makes a relationship or tradeoff
-clearer. Do not create diagram files. There is no mandatory output template,
-report, question count, or next-step checklist. Follow the user's responses and
-let the discussion continue as long as useful.
-
-## Keep the boundaries clear
-
-- Never create, edit, or delete files, including specs, plans, notes, generated
-  output, and activity state. Do not save the conversation into the project.
-- Never install dependencies, execute product code, run tests or builds, start
-  servers, perform browser interactions, or call state-changing tools. Read
-  source and existing evidence instead of testing a hypothesis by execution.
-- Never create or switch branches, commit, merge, push, publish, or deploy.
-- Never turn a request to discuss an idea into approval to plan or implement it.
-  If the user asks for changes, explain the appropriate handoff and keep this
-  Explore invocation read-only. Do not invoke another command automatically.
-
-## Neighbors and handoff
-
-- `/brief` explains an existing build-plan item, its scope, dependencies, and
-  size. Explore can discuss an unplanned idea or question a planned approach.
-- `/discovery` develops broader product direction and reviewed planning drafts.
-  Explore does not draft either planning file.
-- `/debug` reproduces and isolates an actual failure. Explore discusses options
-  without executing code to diagnose or verify them.
-- `/feature` writes a buildable spec; `/fix` specifies a confirmed small change.
-  Suggest the appropriate command only when the user is ready to proceed.
-
-Do not force a handoff at the end of every response. Keep discussing the idea
-when that is what the user wants, and leave the project unchanged.

package/template/devflow/reference/help-playbook-protocol.md

@@ -1,33 +0,0 @@
-# Contextual Help Playbook
-
-**Universal Contextual Help & Playbook Protocol (`help`, `--help`, `-h`, `?`)**:
-   Whenever any skill or command is invoked with a help keyword or flag (e.g., `/bughunter help`, `bughunter --help`, `/archify -h`, `/check ?`, `/feature help`):
-   - **Execution Safety Gate**: DO NOT execute the skill's primary or mutating actions (do not launch scans/attacks, do not modify source code, and do not initialize new task runs).
-   - **Dynamic Workspace Inspection**: Read the target skill in the active adapter. Inspect only workspace files and selected references needed to tailor its examples; reuse current context.
-   - **Persistent HTML Playbook & Token-Saving Cache**:
-      - **Output Location & Light Theme Mandate**: Compile and persist the tailored playbook as a standalone, styled HTML report at `devflow/reference/playbooks/{skill}.html` adhering to the **Paper/Ink Light Theme Standard** (`data-theme="light"`, teal accent, ruler corner, terminal mockup UI, and a real diagram). Build the standalone page using these conventions.
-      - **First Run**: Render the comprehensive 5W1H playbook in chat and write the complete HTML report to `devflow/reference/playbooks/{skill}.html`.
-      - **Subsequent Invocations (Delta Updates & Zero Token Bloat)**: If `devflow/reference/playbooks/{skill}.html` already exists:
-        - Inspect the existing HTML file and compute the diff/delta against the current repository state (e.g., new file paths, modified endpoints, or newly installed vendor assets).
-        - DO NOT repeat unchanged boilerplate or full static content in chat.
-        - Provide a concise **Delta Summary** in chat (highlighting what changed, new recommendations, or newly available commands).
-        - In-place update `devflow/reference/playbooks/{skill}.html` with the fresh timestamp and state.
-        - Provide a clickable link to the actual resolved output file using the active client's supported local-file link format.
-   - **Render the User-Friendly 5W1H Playbook**: Emit an easy-to-read, practical guide organized around the **5W 1H Framework** (rendered on initial run or updated in the HTML playbook):
-      1. **What (Concept & Capabilities)**: Clear, jargon-free summary of what this skill does, its core concept, and its bundled tools/capabilities.
-      2. **Why (Problems Solved & Key Benefits)**: The problems it solves, key advantages, and why you should use it instead of ad-hoc manual work.
-      3. **Who (Target Roles & Personas)**: Target audience or engineering role (e.g., Feature Developer, Senior QA, Security Auditor, Solo Dev, or Tech Lead).
-      4. **Where (Boundaries & Artifact Locations)**: Target workspace boundaries, affected directories, and generated artifact locations (e.g., `devflow/context/`, `devflow/discoveries/`, `findings.md`).
-      5. **When (Timing & Prerequisites/Next Steps)**:
-         - **Timing & Triggers**: Practical situations or milestones when this skill should be invoked.
-         - **Run Before (Prerequisites)**: What to check, prepare, or run beforehand to get the best result.
-         - **Run After (Next Steps)**: What DevFlow command or lifecycle stage should follow next (e.g., handing off to `/fix`, `/feature`, or `/complete`).
-      6. **How (Execution Lifecycle & Real Command Examples)**:
-         - **How It Works (Lifecycle)**: Simple, plain-language breakdown of the execution steps or phases.
-         - **Available Commands & Options**: Common sub-commands, arguments, and flags with brief explanations.
-         - **Safety, Guardrails & Precautions**: Operational boundaries, credential hygiene, read-only vs. mutating constraints, and explicit special safety constraints / precautions.
-      7. **Diagram Slot & Architecture Flow**:
-         - **Real Diagram Mandate**: MUST embed a real, verified vector SVG or interactive diagram reflecting actual skill lifecycle, state transitions, or threat models in Light Theme (`data-theme="light"`).
-         - **Thai Language & Legible Typography**: Architecture and flow diagrams must describe workflows and nodes in Thai language while preserving technical identifiers, paths, and commands in English. Typography must be sufficiently sized and legible for Thai script (Headers 13–14px, box content/descriptions 11–12px, line spacing 18–22px) to prevent tone marks and vowels from clipping or overlapping.
-         - **Strictly No Placeholders**: NEVER output empty placeholder cards, generic instruction text, or phrases like *"when invoking archify..."*. Every playbook must ship with a real visual architectural diagram.
-   - Always conclude the response with: `"Help menu displayed successfully"`.

package/template/devflow/reference/slicing-archetypes.md

@@ -1,105 +0,0 @@
-# 🧩 4 Slicing Archetypes Framework
-
-> คู่มือมาตรฐานการแบ่งขนาดฟีเจอร์ (Feature Slicing & Decomposition) ใน Nexus-DevFlow เพื่อให้แต่ละรอบการส่งมอบ (Feature Run) มีขนาดเล็ก ส่งมอบคุณค่าได้จริง และทดสอบได้รอบด้าน
-
----
-
-## 🎯 ทำไมต้องมี Slicing Archetypes?
-
-ในการพัฒนาซอฟต์แวร์และการทำงานร่วมกับ AI Coding Agents ปัญหาคลาสสิก 2 ประการคือ:
-1. **Slicing by Technical Layer** (เช่น ทำเฉพาะ Database หรือทำเฉพาะ Backend API ก่อน): ทำให้ในรอบนั้นไม่มี UI ให้ทดสอบ หรือไม่สามารถทดสอบแบบ End-to-End ได้
-2. **Oversized Features** (ก้อนใหญ่เกินไป): ทำให้ Context Window เต็มเร็ว AI เริ่มเพี้ยน และการ Review ทำได้ยาก
-
-**4 Slicing Archetypes** ช่วยให้คุณและ Agent เลือกกลยุทธ์การหั่นงานที่เหมาะสมที่สุดตามเป้าหมายของแต่ละ Milestone:
-
----
-
-## 🛹 1. Skateboard Archetype (Minimal Functional Loop)
-
-> *"อย่าเริ่มสร้างรถยนต์ด้วยการทำล้อ แต่ให้เริ่มด้วยการทำสเก็ตบอร์ดที่พาผู้ใช้เคลื่อนที่ได้จริง"*
-
-### นิยาม & วัตถุประสงค์:
-- สร้าง Core Business Logic & State Machine ที่ทำงานได้จริงครบ Loop แม้ UI จะเรียบง่ายที่สุด (Minimal UI หรือ Single Route / Basic Form / CLI interface)
-- เน้นความถูกต้องของ Logic, Validation, Edge Cases และ Data Flow
-
-### เหมาะสำหรับ:
-- ฟีเจอร์ที่ Logic ซับซ้อน มีการคำนวณ การแปลงข้อมูล หรือ State transitions หลายขั้นตอน
-- ต้องการพิสูจน์ว่าแนวคิดหลัก (Core Mechanism) ทำงานได้จริงก่อนลงทุนตกแต่งหน้าจอ
-
-### ตัวอย่าง:
-- **Search & Filter**: สร้างหน้าค้นหาที่มี Search Input เรียบๆ และแสดงผลลัพธ์แบบ Text List เพื่อทดสอบ Search Query, Debounce, Pagination และ Filter Logic
-- **Payment Processing**: ระบบคำนวณราคาสินค้า ส่วนลด ภาษี และสร้าง Transaction Record โดยยังไม่ต้องมี UI สวยหรู
-
----
-
-## 🎭 2. Facade Archetype (Rich UI / Mock-Backed DX)
-
-> *"สร้างประสบการณ์ใช้งานจริงที่สวยงามและจับต้องได้ โดยเชื่อมต่อกับ Mock Data ก่อนพัฒนา Backend จริง"*
-
-### นิยาม & วัตถุประสงค์:
-- สร้าง Full Rich Interactive UI, Component Interactions, Micro-animations และ Design System สมบูรณ์แบบ
-- จำลอง Data Source ด้วย In-Memory Mock หรือ JSON Fixtures เพื่อเก็บ Feedback เรื่อง UX/DX ทันที
-
-### เหมาะสำหรับ:
-- ฟีเจอร์ที่เน้นประสบการณ์ผู้ใช้ (UI/UX Heavy), Dashboard, Data Visualization, Complex Multi-step Wizards
-- ต้องการให้ Stakeholders / ผู้ใช้เห็นหน้าตาและสัมผัส Flow การกดจริงเพื่อสรุป Design ก่อนลงมือทำ Backend
-
-### ตัวอย่าง:
-- **Analytics Dashboard**: สร้างชาร์ต กราฟ และ Card KPIs สวยงาม Interactive เต็มรูปแบบโดยอ่านข้อมูลจาก Mock Dataset
-- **Interactive Kanban Board**: Drag & drop การ์ด ย้ายคอลัมน์ ปรับแท็กแบบ Real-time บน Local State ก่อนเชื่อมต่อ Database จริง
-
----
-
-## 🎯 3. Tracer Bullet Archetype (End-to-End Vertical Slice)
-
-> *"ยิงกระสุนส่องวิถี ทะลวงผ่านทุกเลเยอร์ของระบบจากบนลงล่าง สำหรับ 1 Happy Path ที่สมบูรณ์"*
-
-### นิยาม & วัตถุประสงค์:
-- สร้าง Full-Stack Vertical Slice ตั้งแต่ UI -> API Controller -> Service/Logic -> Database Model & Migration สำหรับ **1 Single Happy Path**
-- พิสูจน์ Contract, Network Protocol, Serialization, Type Safety และ Infrastructure ทั้งหมดว่าเชื่อมต่อกันได้จริง
-
-### เหมาะสำหรับ:
-- สถาปัตยกรรมใหม่ หรือเมื่อต้องต่อเชื่อม Third-Party Service, DB ใหม่, หรือ Auth Flow ใหม่
-- ต้องการลดความเสี่ยงด้าน Integration Risk ในช่วงต้นของโปรเจกต์
-
-### ตัวอย่าง:
-- **User Authentication**: สร้าง Registration Form -> Submit API -> Hash Password -> บันทึกลง PostgreSQL DB -> Issue JWT Token -> Redirect ไปหน้า Profile สำหรับกรณีข้อมูลถูกต้อง 1 กรณี
-- **Report Export**: กดปุ่ม Export -> Backend Query ข้อมูล -> สร้าง PDF Stream -> Browser ดาวน์โหลดไฟล์สำเร็จ
-
----
-
-## 🧭 4. Journey Archetype (Slice by User Workflow / Milestones)
-
-> *"แบ่งฟีเจอร์ตามขั้นตอนการเดินทางของผู้ใช้งาน (User Journey Steps)"*
-
-### นิยาม & วัตถุประสงค์:
-- หั่นงานตามลำดับขั้นตอนธรรมชาติของ Business Process (เช่น Stage 1: Onboarding -> Stage 2: Core Activity -> Stage 3: Summary & Export)
-- แต่ละชิ้นงานจบในตัว และปลดล็อคขั้นตอนถัดไปใน Journey ของผู้ใช้
-
-### เหมาะสำหรับ:
-- Workflow ขนาดใหญ่ที่มีหลายสเตจ, Checkout Flows, Multi-step Form Wizard, Approval Pipeline
-
-### ตัวอย่าง:
-- **E-Commerce Checkout**:
-  - *Slice 1 (Cart Review)*: หน้าสรุปรายการสินค้าและปรับจำนวน
-  - *Slice 2 (Shipping & Address)*: แบบฟอร์มกรอกที่อยู่จัดส่งและคำนวณค่าส่ง
-  - *Slice 3 (Payment & Order Confirmation)*: เลือกวิธีชำระเงินและสรุปใบสั่งซื้อ
-
----
-
-## 📊 ตารางเปรียบเทียบและการเลือกใช้งาน (Selection Matrix)
-
-| Archetype | จุดเน้นหลัก (Focus) | UI Level | Backend / DB | เมื่อไหร่ควรเลือก? |
-| :--- | :--- | :---: | :---: | :--- |
-| 🛹 **Skateboard** | Core Logic & Flow | Minimal | Real | Logic ซับซ้อน ต้องการความถูกต้องก่อนตกแต่ง |
-| 🎭 **Facade** | UX, DX & Interaction | Rich / Complete | Mocked | ต้องการทดสอบ UX / รับ Feedback จากผู้ใช้เร็ว |
-| 🎯 **Tracer Bullet** | Full Architecture Path | Functional | Real | ต้องการทดสอบ Integration & Pipeline ทะลุทุกชั้น |
-| 🧭 **Journey** | Step-by-Step Workflow | Balanced | Real | Workflow ยาว แบ่งทำทีละสเตจตามลำดับ |
-
----
-
-## 💡 แนวทางปฏิบัติใน DevFlow Workflow
-
-1. **ใน `/discovery` หรือ `/brainstorm`**: เมื่อวิเคราะห์ฟีเจอร์ใหญ่ ให้เสนอ Archetype ที่แนะนำในการแบ่ง Sub-features
-2. **ใน `/feature` (Step 2 Sizing & Splitting)**: หากต้องแยกฟีเจอร์ย่อย (เช่น 4a, 4b, 4c) ให้ระบุ Archetype กำกับ เช่น `4a. (Tracer Bullet) Core Export Engine` -> `4b. (Facade) Interactive Export Modal & Template Preview`
-3. **ใน Living Spec (`spec.md`)**: ระบุ Archetype ในส่วนหัวของ Spec เพื่อให้ Agent ในขั้นตอน `/implement` ทราบความคาดหวังเรื่องระดับ UI และ Data Source อย่างชัดเจน