@jakkrichm/create-nexus-devflow 2.2.2 → 2.5.0

package/template/devflow/reference/feature-spec-template.md

@@ -0,0 +1,110 @@
+# [ID-slug] Feature Title
+
+> **Template Type**: Single Living Spec (DevFlow 2.5.0)
+> **Active Location**: `devflow/context/current-feature.md`
+> **Archive Location**: `devflow/history/{features|fixes|rollbacks}/{ID-slug}.md`
+
+- **Feature ID**: `{xxx-slug}`
+- **Category**: `features` | `fixes` | `rollbacks`
+- **Target Branch**: `feature/{xxx-slug}`
+- **Status**: `Spec Ready` | `In-Progress` | `Verified` | `Completed`
+- **Track**: `Unified Fast-Track`
+- **Discovery Ref**: `devflow/discoveries/DISC-xxx.md` (Optional)
+- **ADR Ref**: `devflow/decisions/ADR-xxx.md` (Optional)
+
+---
+
+## 🎯 1. Define & Boundaries
+
+### Problem Statement & Goal
+- **Problem**: อธิบายปัญหาที่พบ หรือสิ่งที่ต้องการแก้ไข/ปรับปรุง
+- **Goal**: ผลลัพธ์หรือเป้าหมายที่ต้องการให้เกิดขึ้น
+
+### In-Scope & Out-of-Scope
+- **In-Scope**:
+  - สิ่งที่ต้องทำในรอบนี้
+- **Out-of-Scope**:
+  - สิ่งที่ไม่ทำในรอบนี้ หรือยกยอดไปทำในเฟสถัดไป
+
+### Risk & Mitigation Matrix
+| Risk | Severity | Mitigation |
+| :--- | :--- | :--- |
+| ความเสี่ยงที่อาจเกิดขึ้น | Low/Medium/High | แนวทางป้องกันหรือรับมือ |
+
+### Success Criteria
+1. เกณฑ์ชี้วัดความสำเร็จข้อที่ 1
+2. เกณฑ์ชี้วัดความสำเร็จข้อที่ 2
+
+---
+
+## 📐 2. Technical Spec & Contracts
+
+### Architecture & Component Design
+- อธิบายโครงสร้างหรือ Flow การทำงานของ Component/Module
+
+### Data Models & Schemas
+```typescript
+// Interface หรือ Type Definition
+```
+
+### API & Interface Contracts
+- **Endpoint / Function**: `methodName(params: Type): ReturnType`
+- **Error Handling**: รายละเอียด Error Codes และวิธีจัดการ
+
+### Non-Functional Constraints
+- **Security**: การตรวจสอบ Input, การจัดการสิทธิ์, Secrets
+- **Performance**: ข้อจำกัดเรื่องความเร็ว หรือ Resource Usage
+
+### Acceptance Criteria (AC)
+- [ ] **AC-1**: เงื่อนไขการยอมรับข้อที่ 1
+- [ ] **AC-2**: เงื่อนไขการยอมรับข้อที่ 2
+
+---
+
+## 📋 3. Execution Plan & TDD Checklist
+
+- [ ] **Task 1: Core Foundation & Types**
+  - [ ] 1.1 `[TDD-Red]` เขียน Unit Test สำหรับ Logic ส่วนที่ 1
+  - [ ] 1.2 `[TDD-Green]` Implement Logic ให้ผ่าน Test
+  - [ ] 1.3 `[TDD-Refactor]` Clean up และ Optimize โค้ด
+
+- [ ] **Task 2: Feature Implementation**
+  - [ ] 2.1 `[TDD-Red]` เขียน Test ครอบคลุม Edge Cases
+  - [ ] 2.2 `[TDD-Green]` Implement Feature ตาม Contract
+  - [ ] 2.3 `[TDD-Refactor]` ตรวจสอบความถูกต้องและ Architecture
+
+- [ ] **Task 3: Integration & QA Verification**
+  - [ ] 3.1 `[TDD-Green]` เชื่อมต่อ UI/API และตรวจสอบ End-to-End
+
+---
+
+## ⚡ 4. Implementation Log & Evidence
+
+*(จะถูกบันทึกและอัปเดตความคืบหน้าระหว่างรันคำสั่ง `/implement`)*
+
+- **Step 1**: ...
+- **Checkpoint Commit**: `feat(scope): ...`
+
+---
+
+## 🧪 5. Multi-Lane Verification Matrix
+
+*(จะถูกบันทึกผลการตรวจสอบระหว่างรันคำสั่ง `/check`)*
+
+| Lane | Command / Verification Target | Result | Notes / Proof |
+| :--- | :--- | :--- | :--- |
+| **Typecheck** | `npm run typecheck` | ⏳ PENDING | |
+| **Lint** | `npm run lint` | ⏳ PENDING | |
+| **Unit Tests** | `npm test` | ⏳ PENDING | |
+| **Manual Proof** | UI / CLI Behavioral Verification | ⏳ PENDING | |
+
+---
+
+## 📦 6. Release Digest & Retrospective
+
+*(จะถูกสรุปและบันทึกอัตโนมัติก่อนทำการ Squash Merge ในคำสั่ง `/complete`)*
+
+- **What Changed**: สรุปสิ่งที่เปลี่ยนแปลง
+- **Key Decisions**: การตัดสินใจสำคัญระหว่างพัฒนา
+- **Lessons Learned**: บทเรียนที่ได้รับ
+- **Known Limitations**: ข้อจำกัดที่ทราบและข้อเสนอแนะในอนาคต

package/template/devflow/reference/project-plan-template.md

@@ -0,0 +1,128 @@
+# Project Plan
+
+> **Document Type**: Project Plan (User-Owned)
+> **Purpose**: แหล่งความจริงหลัก (Single Source of Truth) สำหรับวิสัยทัศน์ผลิตภัณฑ์ สถาปัตยกรรมระบบ ขอบเขตการทำงาน และข้อกำหนดทางเทคนิค
+> **Workflow**: กรอกข้อมูลให้ครบถ้วนแล้วรัน `/overview` เพื่อประมวลผลเป็น `project-overview.md`
+
+---
+
+## 1. Problem - What problem are we solving?
+<!-- 
+อธิบายปัญหาที่ระบบนี้เข้ามาแก้ไข วัตถุประสงค์หลัก และทำไมโปรเจกต์นี้จึงควรมีอยู่ (2-4 ประโยค)
+- ปัญหาในปัจจุบันคืออะไร ทำไมวิธีเดิมถึงไม่ตอบโจทย์
+- ผลลัพธ์ที่ต้องการ (Desired Outcome) หลังระบบนี้สร้างเสร็จ
+-->
+
+- **Core Problem**: [ระบุปัญหาหลักที่ผู้ใช้กำลังเผชิญ เช่น การทำงานแบบ Manual ที่เสียเวลาและผิดพลาดง่าย]
+- **Main Purpose**: [ระบุเป้าหมายหลักของระบบ เช่น แปลง Input 3 อย่างเป็นผลลัพธ์พร้อมใช้งานในไม่กี่วินาที]
+
+---
+
+## 2. Users - Who is this for?
+<!-- 
+กลุ่มผู้ใช้งานเป้าหมายและ Use Cases หลัก
+- Primary Users: ผู้ใช้งานหลักกลุ่มแรก
+- Secondary / Later: กลุ่มผู้ใช้ในอนาคต
+- Access Tiers: สิทธิ์การเข้าถึง เช่น Guest / Registered / Admin
+-->
+
+- **Primary Audience**: [เช่น Solo Developers, Content Creators, นักเรียน/นักศึกษา]
+- **Secondary Audience (Later)**: [เช่น ทีมงานองค์กร, ลูกค้าปลายทาง]
+- **User Personas & Access Tiers**:
+  - `Anonymous / Guest`: [สิทธิ์การใช้งานทั่วไป เช่น ดูข้อมูลสาธารณะ, ทดลองเล่นแบบจำกัด]
+  - `Authenticated User`: [สิทธิ์การใช้งานหลัก เช่น จัดการข้อมูลตนเอง, บันทึกประวัติ]
+  - `Admin`: [สิทธิ์การจัดการระบบ เช่น ดูแลผู้ใช้, ตรวจสอบ Log]
+
+---
+
+## 3. Features - What does v1 need?
+<!-- 
+รายการฟีเจอร์ระดับสูงสำหรับเวอร์ชันแรก (MVP / v1)
+- เขียนสรุปสั้นๆ บรรทัดละ 1 ข้อ ไม่ต้องลงรายละเอียดทางเทคนิคลึก
+- แยกส่วน Out of Scope / Later ให้ชัดเจนเพื่อคุมขอบเขต (Prevent Scope Creep)
+-->
+
+### Core MVP Features (v1):
+- **Feature 1**: [คำอธิบายสั้นๆ เกี่ยวกับสิ่งที่ฟีเจอร์นี้ทำ]
+- **Feature 2**: [คำอธิบายสั้นๆ เกี่ยวกับสิ่งที่ฟีเจอร์นี้ทำ]
+- **Feature 3**: [คำอธิบายสั้นๆ เกี่ยวกับสิ่งที่ฟีเจอร์นี้ทำ]
+- **Feature 4**: [คำอธิบายสั้นๆ เกี่ยวกับสิ่งที่ฟีเจอร์นี้ทำ]
+
+### Later / Post-MVP (Not in v1):
+<!-- สิ่งที่เก็บไว้ทำในอนาคต แต่ยังไม่ทำในรอบแรก -->
+- [เช่น ระบบสมัครสมาชิกและจัดการ Billing ผ่าน Stripe]
+- [เช่น การส่งออกข้อมูลปริมาณมากแบบ Batch/CSV]
+- [เช่น Cloud Sync และการแชร์ข้อมูลข้ามอุปกรณ์]
+
+---
+
+## 4. Data - What are we storing?
+<!-- 
+โครงสร้างข้อมูลและ Entity หลักที่ระบบต้องจัดเก็บ
+- ข้อมูลที่อยู่ใน Code (Static / Config)
+- ข้อมูลที่เก็บใน Browser (LocalStorage / Session / Cookies)
+- ข้อมูลที่เก็บใน Database (Entities, Fields, Relationships)
+-->
+
+- **In-Code / Static**: [เช่น Template Definitions, App Constants, Fixed Options]
+- **Client Storage (LocalStorage/Session)**: [เช่น User Preferences, Form Draft, UI Settings]
+- **Database Entities (If applicable)**:
+  - **`User`**: `id` (String/UUID), `email` (String, Unique), `name` (String), `role` (Enum), `createdAt` (DateTime)
+  - **`Resource`**: `id` (UUID), `userId` (FK -> User.id), `title` (String), `status` (Enum), `metadata` (JSON), `updatedAt` (DateTime)
+- **Relationships**:
+  - `User` 1-to-Many `Resource`
+
+---
+
+## 5. Tech - What stack are we using?
+<!-- 
+เทคโนโลยี ไลบรารี และเครื่องมือที่เลือกใช้ พร้อมระบุหน้าที่
+-->
+
+- **Framework & Runtime**: [เช่น Next.js 15 (App Router), TypeScript, Node.js >=20]
+- **Styling & UI**: [เช่น Tailwind CSS v4, Shadcn UI / Radix Primitives, Lucide Icons]
+- **State & Data Access**: [เช่น Zustand, TanStack Query, Prisma ORM / Drizzle]
+- **Database**: [เช่น PostgreSQL on Neon / Supabase, SQLite on LibSQL]
+- **Authentication**: [เช่น NextAuth.js (Auth.js), Clerk, Supabase Auth, หรือ None in v1]
+- **Validation**: [เช่น Zod for Schema & Input Validation]
+- **Special Engines / Libraries**: [เช่น Puppeteer for Headless PDF/Image Export, Sharp for Image Processing]
+
+---
+
+## 6. Monetize - How will this make money?
+<!-- 
+โมเดลทางธุรกิจหรือแผนการสร้างรายได้ (หากเป็น Free Tool หรือ Internal App ให้ระบุให้ชัด)
+-->
+
+- **Model in v1**: [เช่น Free / Open-Source / Internal Utility (ไม่มีการเก็บเงินใน v1)]
+- **Future Monetization (If applicable)**: [เช่น Freemium, Subscription $10/mo, Usage-based API credits]
+
+---
+
+## 7. UI/UX - How should this look and feel?
+<!-- 
+ธีม โครงสร้างหน้าจอ สไตล์การออกแบบ และประสบการณ์ผู้ใช้
+-->
+
+- **Design Aesthetic**: [เช่น Clean & Modern, Dark-Mode First, Glassmorphism, Minimalist]
+- **Layout Structure**: [เช่น Single-page dashboard with Split View (Form on left, Live Preview on right)]
+- **Key Routes / Screens**:
+  - `/`: [หน้า Landing & Main Generator Workflow]
+  - `/dashboard`: [หน้าจัดการ Resource และดูประวัติย้อนหลัง]
+  - `/settings`: [หน้าตั้งค่า Profile และ Preferences]
+
+---
+
+## 8. Deployment - Where and how will this ship?
+<!-- 
+เป้าหมายการ Deploy, คำสั่ง Build/Start, และ Environment Variables
+-->
+
+- **Target Platform**: [เช่น Vercel, Render, Cloudflare Pages, Fly.io, Self-hosted Docker]
+- **Build Command**: `npm run build`
+- **Start Command / Output**: `npm run start` (หรือ Static Output `out/`)
+- **Required Environment Variables**:
+  - `DATABASE_URL`: Connection string สำหรับ Database
+  - `NEXTAUTH_SECRET`: Secret key สำหรับ Session signing
+  - `API_KEY`: Key สำหรับเชื่อมต่อ Third-party Service
+- **Health Check Endpoint**: `/api/health`

package/template/devflow/reference/running-id-contract.md

@@ -1,4 +1,4 @@
-# DevFlow 2.0 Running ID & 3-Pillars Workspace Contract
+# DevFlow 2.5.0 Running ID & 3-Pillars Workspace Contract
 
 ## The 3-Pillars Workspace Architecture
 
@@ -11,19 +11,20 @@ devflow/
 ├── ⚡ context/                  # [2. Present / Active] Living Source of Truth & Active Work
 │   ├── project-overview.md     # Primary source of truth for project architecture and tech stack
 │   ├── coding-standards.md     # Engineering, code quality, TDD, and testing standards
-│   ├── ai-interaction.md       # AI agent interaction rules, dual-track flow, and Thai defaults
+│   ├── ai-interaction.md       # AI agent interaction rules, unified living spec flow, and Thai defaults
 │   ├── findings.md             # Open and resolved audit findings ledger (P0-P3)
+│   ├── glossary.md             # Domain glossary and architecture vocabulary
 │   ├── current-stage.md        # Active state pointer and run tracker
-│   ├── current-feature.md      # Fast-Track Single Living Spec (Active work / stub when idle)
-│   └── current-run/            # Deep-Track Active Run folder (Temporary during 10-70 execution)
+│   └── current-feature.md      # Single Living Spec (Active work / stub when idle)
 │
 ├── 📦 history/                  # [3. Past / Completed] Permanent Delivery & Release Archives
-│   ├── features/               # Completed features, architecture migrations, tooling (xxx-slug.md or xxx-slug/)
+│   ├── features/               # Completed features, architecture migrations, tooling (xxx-slug.md)
 │   ├── fixes/                  # Completed bug fixes, hotfixes, security patches (xxx-slug.md)
 │   ├── rollbacks/              # Completed feature reversals (YYYY-MM-DD-xxx-slug.md)
 │   └── HISTORY.md              # Master release ledger summary table
 │
-└── 🔍 discoveries/              # Pre-delivery discovery records (DISC-YYYYMMDD-NNN-slug/00-explore.md)
+├── 🔍 discoveries/              # Pre-delivery discovery records (DISC-YYYYMMDD-NNN-slug/discovery.md)
+└── 🏛️ decisions/                # Architecture Decision Records (ADR-xxx-slug.md)
 ```
 
 ---
@@ -31,9 +32,9 @@ devflow/
 ## Running ID Naming Convention
 
 ### 1. Standard Running IDs
-- **Format**: `xxx-slug` (e.g. `001-setup-auth`, `021-categorized-history-and-clean-living-spec-architecture`)
+- **Format**: `xxx-slug` (e.g. `001-setup-auth`, `053-unify-deep-and-fast-track-model`)
 - **Prefix Removal**: The legacy `RUN-` prefix is discontinued in favor of clean 3-digit sequential numbering.
-- **Git Branch Standard**: `feature/{xxx-slug}` or `fix/{xxx-slug}`.
+- **Git Branch Standard**: `feature/{xxx-slug}` or `fix/{xxx-slug}` (or specific release branches such as `2.5.0`).
 
 ### 2. Sub-Feature Running IDs (`xxx[a-z]-slug`)
 - **Format**: `xxx[a-z]-slug` (e.g. `038a-backend-schema-and-api`, `038b-frontend-ui-and-state`)
@@ -56,6 +57,6 @@ When detected during `/feature` or `/brief`, the AI triggers the **Interactive S
 
 ## Single Active Run Rule (One Thing at a Time)
 
-1. Only **one active run** is permitted at any given time across both Fast-Track and Deep-Track.
-2. Before opening a new run (`/feature`, `/fix`, or `10-define`), the AI checks `current-stage.md` and `current-feature.md`.
-3. If an active run is in progress, the AI **blocks** starting a new task and requires closing the active run via `/complete` or `70-deliver` (or explicitly cancelling/rolling back).
+1. Only **one active run** is permitted at any given time in `current-feature.md`.
+2. Before opening a new run (`/feature` or `/fix`), the AI checks `current-stage.md` and `current-feature.md`.
+3. If an active run is in progress, the AI **blocks** starting a new task and requires closing the active run via `/complete` (or explicitly cancelling/rolling back).

package/template/.agents/skills/10-define/SKILL.md

@@ -1,54 +0,0 @@
----
-name: 10-define
-description: "[devflow][D] Define stage in DevFlow 2.0 - turn an approved discovery into a bounded delivery run in context/current-run with stable scope."
-argument-hint: "{approved discovery-id, discovery path, running-id, or run path}"
----
-
-# Phase 10: Define
-
-$ARGUMENTS
-
-Convert an approved `Proceed` discovery into a bounded delivery run. Checks the Single Active Run Guardrail, allocates a sequential ID without prefix (`xxx-slug`), and writes `devflow/context/current-run/10-define.md`.
-
-## Usage
-
-```text
-10-define {discovery-id or discovery path}
-10-define {id or run path}
-```
-
-## Markdown-First Contract
-
-For the active delivery run, write:
-
-```text
-devflow/context/current-run/10-define.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/define.template.md
-```
-
-## Process & Quality Gates
-
-### 1. Single Active Run Guardrail (One Thing at a Time)
-1. Inspect `devflow/context/current-stage.md`, `devflow/context/current-feature.md`, and `devflow/context/current-run/`.
-2. If an active uncompleted run exists:
-   - **HALT and reject opening a new define stage**.
-   - Warn the user to complete or close the active run with `/complete` or `70-deliver` first.
-
-### 2. Validate The Discovery Gate
-Require:
-- `Decision: Proceed`
-- `Approval Status: Approved`
-- A resolvable Discovery ID and `discovery.md` (or legacy `00-explore.md`)
-
-### 3. Allocate Sequential ID
-- Inspect `devflow/history/HISTORY.md` and allocate sequential ID without prefix (e.g. `022-{slug}`).
-- Create directory `devflow/context/current-run/` if it does not exist.
-- Write `devflow/context/current-run/10-define.md`.
-- Update `devflow/context/current-stage.md`:
-  - `Active Running ID`: `{ID}`
-  - `Current Stage`: `10-define (Completed -> Ready for 20-spec)`

package/template/.agents/skills/20-spec/SKILL.md

@@ -1,155 +0,0 @@
----
-name: 20-spec
-description: "[devflow][D] Spec stage in DevFlow 2.0 - write the formal markdown-first specification from a stable definition."
-argument-hint: "{running-id or workspace path}"
----
-
-# Phase 20: Spec
-
-$ARGUMENTS
-
-Turn the defined work into a specification that is concrete enough for planning and explicit enough to serve as the delivery contract.
-
-## Usage
-
-```text
-20-spec {running-id or workspace path}
-```
-
-Use this when:
-
-- the goal and scope are stable
-- the team needs testable or reviewable requirements
-- planning should not start until the contract is explicit
-
-## Markdown-First Contract
-
-Write the primary stage artifact to:
-
-```text
-devflow/runs/{ID}-{slug}20-spec.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/spec.template.md
-```
-
-Before writing `20-spec.md`, read `artifact_language` from `spec.template.md` and produce the artifact in that language.
-
-## Required Section Content
-
-Before completing any generated artifact:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
-
-## Process
-
-### Loop Contract
-
-Run specification as a contract-hardening loop, not as a prose expansion of the definition.
-
-- **Intent**: produce requirements and acceptance criteria that are concrete enough for planning and review.
-- **Context**: read the run's `10-define.md`, follow its `source_discovery` link when original framing matters, and read relevant research, hard constraints, and domain or codebase decisions that shape this run's delivery contract.
-- **Action**: write requirements, acceptance criteria, constraints, and out-of-scope items, then inspect whether each requirement is testable and unambiguous.
-- **Observation**: use concrete evidence such as ambiguous wording, unchecked assumptions, edge cases, missing acceptance criteria, conflicting constraints, and implementation details that are not true constraints.
-- **Adjustment**: if facts are missing, route to `Research`; if requirements need stress-testing, use `grill-with-docs`; if module or interface boundaries affect the contract, use `codebase-design`; if scope is unstable or still contains multiple independently deliverable contracts, return to `10-define` and split the run before continuing.
-- **Stop Condition**: stop when every requirement has checkable acceptance criteria, hard constraints are explicit, out-of-scope items are visible, and `30-plan` can break the work down without inventing intent.
-- **Handoff**: `20-spec.md` must tell `30-plan` what must be delivered, how success will be checked, what constraints cannot move, and what is intentionally excluded.
-
-### 1. Read Definition Artifacts
-
-Read:
-
-- `10-define.md`
-- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
-- research notes if they impose real constraints
-
-### 2. Write The Specification
-
-Define:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- explicit out-of-scope items
-
-The spec should be strong enough that planning can break it into executable units without guessing intent.
-
-### 3. Handle Missing Certainty
-
-If the spec cannot be written confidently:
-
-- call `Research` when facts are missing
-- use `grill-with-docs` when requirements, acceptance criteria, constraints, or out-of-scope items need to be stress-tested against scenarios and domain language
-- use `codebase-design` when requirements imply module boundaries, interface contracts, seams, or testability constraints
-- record assumptions explicitly when they are unavoidable
-
-Do not hide uncertainty inside vague requirement text.
-
-Do not combine sibling Running IDs into one spec. If this run still contains multiple independent acceptance, release, ownership, or context boundaries, stop and return to `10-define {running_id}` for an explicit split.
-
-### 4. Finalize `20-spec.md`
-
-- preserve the template headings
-- follow the `artifact_language` configured in `spec.template.md`
-- replace all placeholders
-- keep implementation details out unless they are true constraints
-- make sure the acceptance criteria can actually be checked
-
-### 5. Manual Review Soft Gate
-
-Before recommending `30-plan`, check whether the delivery contract has been human-reviewed.
-If `Approval Status` is not approved yet:
-
-- warn that planning may drift if the spec is still under review
-- recommend review of requirements, exclusions, and acceptance criteria first
-- keep `30-plan` as a soft recommendation only
-
-## Output
-
-Report:
-
-- core requirements
-- acceptance criteria
-- hard constraints
-- out-of-scope items
-- manual review warnings when the contract is still pending
-- recommended next step
-
-## Relationship To DevFlow 2.0
-
-- Classification: Mainline workflow
-- Previous state: `10-define`
-- Next state: `30-plan` when the contract is implementation-ready
-- Common companion commands: `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate` when product or integration context is still incomplete; support skills: `grill-with-docs`, `domain-modeling`, and `codebase-design` when the spec depends on precise domain language, durable decisions, or module/interface constraints
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/spec.template.md`
-- Related commands: `10-define`, `PRD`, `Spec-Research`, `Competitor`, `Spec-Orchestrate`, `30-plan`
-
-## Next Workflow Recommendation
-
-- **Primary**: `30-plan`
-- **Why**: The specification is now concrete enough to break into executable work.
-- **Alternatives**:
-  - `Research` - choose this when the spec still depends on missing facts.
-  - `grill-with-docs` - choose this when the spec is readable but not yet tough enough to plan from.
-  - `codebase-design` - choose this when interface shape or testability constraints must be settled before planning.
-  - `10-define` - choose this when the scope itself is still unstable.
-
-## Nexus Event
-
-- Use `Research` when a requirement, rule, or integration constraint still lacks evidence.
-- Use `Spec-Research`, `Competitor`, or `PRD` when the contract needs stronger external, product, or market framing before planning.
-- Use `grill-with-docs` when available if clarification could materially change acceptance criteria, edge cases, exclusions, or rules.