@jakkrichm/create-nexus-devflow 2.17.8 → 2.18.0

package/template/devflow/docs/quickstart.md

@@ -0,0 +1,124 @@
+# Quickstart Guide
+
+Getting started with **Nexus-DevFlow 2.13.0** — an enterprise agentic workflow layer supporting **The 3-Pillars Workspace Architecture & Pure Task-Isolated Living Spec Model** for Google Antigravity, OpenAI Codex, Claude Code, Cursor, GitHub Copilot, and other AI IDEs.
+
+---
+
+## 1. Client Installation
+
+In your terminal, navigate to your target project folder (either a fresh scaffold or an existing codebase):
+
+```bash
+# Automated install (Recommended)
+npx -y @jakkrichm/create-nexus-devflow@latest -y
+
+# Interactive install (Select specific tool adapters)
+npx @jakkrichm/create-nexus-devflow@latest
+```
+
+This overlays the `.agents/`, `.claude/`, and `devflow/` workflow structures into your repository without modifying your existing application source code.
+
+---
+
+## 2. Project Baseline Setup
+
+Open your AI IDE (Antigravity, Claude Code, Codex, or Cursor) and run the appropriate starting command in the chat:
+
+| Situation | Starting Command | Purpose |
+| :--- | :--- | :--- |
+| **Existing Codebase (Brownfield)** | `/adopt` *(or `$adopt`)* | Surveys your codebase, creates baseline planning docs, coding standards, and registers project context. |
+| **Fresh Project (Scaffolded)** | `/onboard` *(or `$onboard`)* | Configures project metadata, stack commands, coding standards, and tool adapters. |
+| **Health & Setup Check** | `/doctor` *(or `$doctor`)* | Read-only diagnostic checking adapters, config files, commands, and workflow integrity. |
+| **Interactive Navigation** | `/devflow` *(or `$devflow`)* | Flagship guide that analyzes workspace state and recommends the exact next action. |
+
+---
+
+## 3. The Unified 4-Stage Task-Isolated Living Spec Lifecycle
+
+All development tasks (from small UI fixes to deep architectural features) execute through the 4-stage task-isolated living spec lifecycle:
+
+```text
+/feature (or /fix) ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+1. **`/feature {title}`** (or **`/fix {bug}`**): Allocates sequential ID (`xxx-slug`) and initializes the Task-Isolated Living Spec in `devflow/context/{xxx-slug}/spec.md`, stage pointer (`stage.md`), and dedicated audit ledger (`findings.md`).
+2. **`/implement [id]`**: Incrementally executes checklist tasks in `devflow/context/{xxx-slug}/spec.md` with strict TDD discipline (Red-Green-Refactor).
+3. **`/check [id]`**: Senior QA multi-lane verification (Typecheck, Lint, Test suites, and behavioral manual proof), records empirical proof into `spec.md` and findings into `findings.md`.
+4. **`/complete [id]`**: Final safety audit, records Release Digest, auto-archives to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`, cleanly removes `devflow/context/{xxx-slug}/`, updates `HISTORY.md` and `build-plan.md`, and manages git squash-merge.
+
+---
+
+## 4. Pre-Flight Discovery, SA & Architectural Alignment
+
+For debugging, TDD, and independent review, see the
+[English JIT reference guides](USAGE.md#debugging-tdd--review-reference-guides).
+Use them through `debug`, `implement`, and `audit`; they are bundled supporting
+files, not additional commands or a separate plugin installation.
+
+Before committing to delivery, use specialized companion skills to refine complex requirements:
+
+```text
+/analyze ──▶ /idea (Inbox) ──▶ /grill (Socratic ADR) ──▶ /discovery (Explore) ──▶ /feature (Deliver)
+```
+
+- **`/analyze`**: Multi-format requirement ingestion (PDF, Word, Excel, Images) and codebase impact scan.
+- **`/idea`**: Quick idea capture in `devflow/ideas.md` with instant AI feasibility scoring.
+- **`/grill`** (or **`/align`**): Socratic alignment & domain modeling; records Architecture Decision Records (`devflow/decisions/ADR-xxx.md`).
+- **`/brainstorm`**: Structured ideation with trade-off analysis.
+- **`/discovery`**: Deep inception and exploratory discovery (`devflow/discoveries/DISC-xxx.md`).
+
+---
+
+## 5. The 3-Pillars Workspace Architecture
+
+```text
+devflow/
+├── ideas.md                    # 🔮 Future (Backlog): Idea Inbox with AI scoring
+├── project-plan.md             # 🔮 Future (Backlog): Product Vision & Architectural Roadmap
+├── build-plan.md               # 🔮 Future (Backlog): Master Feature Delivery Sequence
+├── context/                    # ⚡ Present (Active Context): Global Truth & Task Workspaces
+│   ├── project-overview.md     # Single Source of Truth
+│   ├── coding-standards.md     # Engineering standards & conventions
+│   ├── ai-interaction.md       # AI interaction guidelines
+│   ├── glossary.md             # Domain glossary & architecture terms
+│   └── {xxx-slug}/             # Active Task-Isolated Workspace
+│       ├── spec.md             # Living Spec & Task Breakdown
+│       ├── stage.md            # Stage pointer & status
+│       └── findings.md         # Dedicated audit & quality ledger
+├── decisions/                  # 🏛️ Decisions: Architecture Decision Records (ADR-xxx.md)
+├── history/                    # 📦 Past (History Archive): Categorized delivery archives
+│   ├── features/               # Shipped features ({xxx-slug}.md)
+│   ├── fixes/                  # Resolved bug fixes ({xxx-slug}.md)
+│   ├── rollbacks/              # Reversal audit logs (YYYY-MM-DD-{xxx-slug}.md)
+│   └── HISTORY.md              # Master release ledger
+└── discoveries/                # 🔍 Discoveries: Pre-delivery discovery records (DISC-xxx.md)
+```
+
+---
+
+## 6. Maintenance & CLI Commands
+
+```bash
+# Launch interactive Real-Time Local Dashboard (0ms SSR Hydration & Git Cache)
+npx @jakkrichm/create-nexus-devflow dashboard
+
+# Check active project status across 3-Pillars
+npx @jakkrichm/create-nexus-devflow status
+
+# Automated Quality Gatekeeper
+npx @jakkrichm/create-nexus-devflow gate [--strict]
+
+# Model Context Protocol (MCP) Server Hub
+npx @jakkrichm/create-nexus-devflow mcp
+
+# Multi-Agent Swarm & Code Graph RAG
+npx @jakkrichm/create-nexus-devflow swarm
+npx @jakkrichm/create-nexus-devflow graph --file src/index.ts
+
+# JIT Context Slicing Engine
+npx @jakkrichm/create-nexus-devflow slice --stage implement
+
+# Manage vendor skills (e.g. bughunter, matt-pocock)
+npx nexus-devflow skill list
+npx nexus-devflow skill restore
+```

package/template/devflow/docs/release-process.md

@@ -0,0 +1,52 @@
+# Release Process
+
+This guide is for framework maintainers preparing a Nexus-DevFlow release. Keep the flow manual-first, use only the commands that already exist in this repository, and treat validation evidence as the release gate.
+
+---
+
+## 1. Pre-Release Readiness
+
+- Confirm the intended release scope before changing version or release wording.
+- Confirm that maintainer-facing and user-facing docs (`README.md`, `README.th.md`, `devflow/docs/`) stay aligned.
+- Review `ROADMAP.md` only for a status refresh when the release changes roadmap milestones.
+- Decide whether the release is patch, minor, or major according to Semantic Versioning.
+
+---
+
+## 2. Validation Suite
+
+Run baseline checks from the framework root:
+
+```bash
+npm run check
+npm run check:static
+npm test
+npm run test:package
+```
+
+Release only after all validation steps pass with exit code 0.
+
+---
+
+## 3. Install & Upgrade Verification
+
+Verify that the overlay package builds and updates cleanly:
+
+```bash
+npx @jakkrichm/create-nexus-devflow update --dry-run
+```
+
+---
+
+## 4. Release Notes
+
+- Summarize user-facing changes separately from maintainer-only changes in `CHANGELOG.md`.
+- Call out changes to release, install, or upgrade guidance explicitly.
+- State whether the release is patch, minor, or major and why.
+
+---
+
+## 5. Tagging & Release Policy
+
+- **Commits to `main`**: Internal maintenance, documentation tweaks, or minor refactoring that does not affect the npm overlay package should be pushed directly to `main` without creating a git tag.
+- **Git Tag Releases (`v*`)**: Create and push git tags (`v2.5.x`) only when there is a functional update to `@jakkrichm/create-nexus-devflow` or a new release intended for npm publishing and GitHub Releases.

package/template/devflow/docs/skill-selection-policy.md

@@ -0,0 +1,64 @@
+# Skill Selection Policy
+
+Use this policy when deciding which skill or companion tool to activate for a given task in **Nexus-DevFlow 2.13.0**.
+
+---
+
+## 1. Lifecycle Selection Policy
+
+Nexus-DevFlow 2.13.0 uses the **Task-Isolated Living Spec Lifecycle** for all development work:
+
+```text
+/feature (or /fix) ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+- **Choose `/feature`**: For all planned features, new capabilities, refactorings, or architecture upgrades. Supports intake from Idea Inbox (`/feature IDEA-xxx`) or Discovery (`/feature DISC-xxx`).
+- **Choose `/fix`**: For ad-hoc bug repairs, regressions, or hotfixes.
+- **Choose `/implement`**: To execute checklist tasks with strict TDD discipline (Red-Green-Refactor).
+- **Choose `/check`**: For Dual-Axis verification before delivery: observable spec fidelity plus independent standards, architecture, security, and quality gates.
+- **Choose `/complete`**: For final safety audit, Release Digest, archiving, and branch delivery gate.
+
+---
+
+## 2. Pre-Flight Discovery & Architectural Alignment Policy
+
+Use pre-flight skills before committing to delivery when exploring new ideas or resolving ambiguity:
+
+```text
+/idea (Inbox) ──▶ /grill (Socratic ADR) ──▶ /discovery (Explore) ──▶ /feature (Deliver)
+```
+
+- **Choose `/idea`**: When capturing raw thoughts or feature proposals with AI feasibility scoring.
+- **Choose `/grill`** (or **`/align`**): When complex domain concepts need pressure-testing and Architecture Decision Records (ADRs).
+- **Choose `/brainstorm`**: When exploring 2–3 viable approaches with trade-off matrices.
+- **Choose `/discovery`**: For deep multi-turn inception research and exploration before speccing.
+
+---
+
+## 3. Companion Tools & Quality Gates Mapping
+
+| Need | Recommended Command | Behavior |
+| :--- | :--- | :--- |
+| **System Diagnostics** | `/doctor` | Read-only check of adapters, configs, and workflow drift. |
+| **Workspace Navigation** | `/devflow` | Flagship state inspector and next action router. |
+| **Root-Cause Analysis** | `/debug` | Scientific six-phase diagnosis using a deterministic red-capable feedback loop without modifying source. |
+| **Architecture & Spec Verification** | `/check` | Reviews Deep Modules, documented standards, and behavioral acceptance as independent axes. |
+| **Manual QA Guide** | `/try` | Generates click-by-click human manual test guide. |
+| **Code & Security Audit** | `/audit` | Branch-aware or full-project code and security audit. |
+| **Feature Reversal** | `/rollback` | Analyzes dependency risks and drafts safe rollback spec. |
+| **CI Setup** | `/ci` | Configures `.github/workflows/verify.yml` with detected package manager. |
+| **Unit Test Setup** | `/setup-tests` / `/test` | Runs test suites or scaffolds missing unit tests. |
+| **Autonomous Pass** | `/autopilot` | Bounded Single Living Spec execution loop (`feature`/`fix` -> `implement` -> `check`) stopping before merge. |
+| **Visual Mockup** | `/prototype` | Throwaway HTML/CSS mockups sharing design tokens. |
+| **Cloud Readiness** | `/release` | Deployment readiness check (Render / Vercel). |
+| **Interactive Report** | `/report-html` | Generates standalone HTML dashboard on demand. |
+
+---
+
+## 4. Selection Boundaries & References
+
+- The **32 bundled Core Skills** are the names in `agent-bundle.manifest.json#core_skills`; Local or Personal Skills are workspace extensions, not automatic public commands.
+- Prefer an existing Core Skill before adding a new public surface. Follow [governance rules](governance-rules.md) for promotion and placement decisions.
+- Generated artifacts follow the [Markdown metadata contract](markdown-metadata-contract.md).
+- Human review responsibilities are defined in the [manual review workflow](manual-review-workflow-spec.md).
+- Use [Living Spec examples](examples/living-spec/) as structural references, not as copy-paste requirements.

package/template/devflow/docs/workflow-surface-map.md

@@ -0,0 +1,85 @@
+# Workflow Surface Map (32 Core Skills)
+
+This document outlines the active workflow surfaces and command taxonomy in **Nexus-DevFlow 2.13.0**.
+
+The canonical surface contains **32 Core Skills** from
+`agent-bundle.manifest.json#core_skills`. Additional Local or Personal Skills
+may exist in a workspace, but are not bundled product commands until explicitly
+promoted into that inventory.
+
+---
+
+## 1. Universal Command Invocations
+
+Each command in DevFlow has exactly **one canonical name** and can be invoked across AI IDEs:
+- **Slash Prefix (`/`)**: For Google Antigravity, Claude Code, Gemini CLI (e.g. `/feature`, `/devflow`, `/discovery`).
+- **Dollar Prefix (`$`)**: For OpenAI Codex (e.g. `$feature`, `$devflow`, `$discovery`).
+- **Plain Canonical Name**: Direct tool/skill calling in generic terminals or non-native agents (e.g. `feature`, `implement`, `check`, `complete`).
+
+---
+
+## 2. Canonical Surface Taxonomy (32 Core Skills)
+
+### ⚡ 1. The 4-Stage Living Spec Lifecycle Skills (7 Skills)
+| Command | Category | Purpose | Primary Artifact |
+| :--- | :--- | :--- | :--- |
+| `feature` | Spec & Plan | Combines discovery, specification, and task breakdown for planned work. | `devflow/context/{xxx-slug}/spec.md` |
+| `fix` | Spec & Plan | Documents and specs ad-hoc bug repairs or small changes. | `devflow/context/{xxx-slug}/spec.md` |
+| `implement` | Execution | Incrementally executes checklist tasks with strict TDD discipline. | `devflow/context/{xxx-slug}/spec.md` |
+| `check` | Quality Gate | Dual-Axis review of empirical spec fidelity and independent standards/architecture quality. | `devflow/context/{xxx-slug}/spec.md` |
+| `complete` | Delivery | Final safety audit, records Release Digest, branch merge, and archiving. | `devflow/history/{features\|fixes\|rollbacks}/` |
+| `continuous` | Delivery | Autonomous serial multi-feature delivery loop with local branches, quality gates, and squash-merges. | `devflow/history/features/` |
+| `rollback` | Delivery | Safe feature reversal with dependency risk analysis preserving history. | `devflow/history/rollbacks/` |
+
+---
+
+### 🔮 2. Pre-Flight Discovery, SA & Alignment Suite (5 Skills)
+| Command | Category | Purpose | Primary Artifact |
+| :--- | :--- | :--- | :--- |
+| `analyze` | SA Ingestion | Multi-format requirement ingestion (PDF, Word, Excel, Images), Codebase Impact scan & Socratic Gap checklist. | `devflow/inbox/` & `devflow/analysis/` |
+| `idea` | Backlog | Idea inbox capture and AI feasibility scoring. | `devflow/ideas.md` |
+| `grill` / `align` | Alignment | Socratic alignment interview, domain glossary extraction, and ADR generation. | `devflow/decisions/` & `glossary.md` |
+| `brainstorm` | Ideation | Structured divergent & convergent ideation with trade-off matrices. | Interactive session |
+| `discovery` | Exploration | Deep multi-turn inception exploration and discovery records. | `devflow/discoveries/DISC-xxx.md` |
+
+---
+
+### 🧰 3. Workspace Governance & Operations (20 Skills)
+| Command | Category | Purpose |
+| :--- | :--- | :--- |
+| `devflow` | Navigation | Flagship interactive guide, state inspector, and intent router. |
+| `doctor` | Diagnostics | Read-only health check for setup, adapters, and workflow drift. |
+| `overview` | Context | Regenerate and validate `project-overview.md` from planning docs. |
+| `brief` | Planning | Scope and dependency briefing before speccing a feature. |
+| `debug` | Diagnostics | Scientific six-phase diagnosis using a deterministic red-capable feedback loop. |
+| `onboard` | Onboarding | Setup baseline context on fresh or scaffolded projects. |
+| `adopt` | Onboarding | Survey existing codebase and bootstrap DevFlow context into brownfield apps. |
+| `try` | Quality Gate | Generate step-by-step human manual QA review guide. |
+| `audit` | Quality Gate | Branch-aware or full-project code and security audit. |
+| `bughunter` | Security | Offensive security orchestrator, 83 vulnerability patterns & CVE payloads. |
+| `ci` | Automation | Configure GitHub Actions verify workflow (`.github/workflows/verify.yml`). |
+| `test` | Quality Gate | Test runner, missing test generation, and coverage check. |
+| `setup-tests` | Quality Gate | Add or normalize unit test suite. |
+| `browser-tests` | Quality Gate | Add or normalize Playwright browser test harness & connect with MCP browseros-neo. |
+| `autopilot` | Autonomous | Bounded Living Spec execution loop (`feature`/`fix` -> `implement` -> `check`) stopping before merge. |
+| `prototype` | Ideation | Throwaway pre-build static HTML/CSS mockups sharing design tokens. |
+| `release` | Deployment | Cloud deployment readiness check (Render / Vercel). |
+| `status` | State | Progress summary and next action inspector. |
+| `report-html` | Reporting | Generate interactive standalone HTML report dashboard. |
+| `convert-any-to-md` | Utility | Document conversion utility into markdown in `devflow/reference/`. |
+
+---
+
+## 3. Bundled Core vs Local Extensions
+
+- **Bundled Core Skill**: listed in `agent-bundle.manifest.json#core_skills`, mirrored across both adapters, validated, and included in the package template.
+- **Local/Personal Skill**: present in a maintainer workspace but absent from the canonical inventory; allowed locally and excluded from package output.
+- **Promotion rule**: adding a directory does not promote a command. Promotion requires an explicit inventory, documentation, adapter, test, and release decision.
+
+## 4. Review & Authoring References
+
+- [Skill selection policy](skill-selection-policy.md)
+- [Governance rules](governance-rules.md)
+- [Markdown metadata contract](markdown-metadata-contract.md)
+- [Manual review workflow](manual-review-workflow-spec.md)
+- [Living Spec examples](examples/living-spec/)

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

@@ -1,90 +1,110 @@
-# 📐 [{xxx-slug}] {title}
+# [ID-slug] Feature Title
 
-> **Status**: In-Progress  
-> **Track**: Fast-Track (Task-Isolated Living Spec Mode - Feature)  
-> **Category**: Feature  
-> **Source**: `devflow/build-plan.md: Feature {n}` & `devflow/discoveries/{DISC-ID}/discovery.md`  
-> **Branch**: `feature/{xxx-slug}`  
-> **Started Date**: {YYYY-MM-DD}  
-> **Delivered Date**: TBD  
-> **Owner**: DevFlow Core Framework Team & AI  
+> **Template Type**: Task-Isolated Living Spec
+> **Active Location**: `devflow/context/{xxx-slug}/spec.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. Specification & Scope
+## 🎯 1. Define & Boundaries
 
-### 1.1 Problem Statement
-{Description of the problem, background, and rationale for developing this feature}
+### Problem Statement & Goal
+- **Problem**: อธิบายปัญหาที่พบ หรือสิ่งที่ต้องการแก้ไข/ปรับปรุง
+- **Goal**: ผลลัพธ์หรือเป้าหมายที่ต้องการให้เกิดขึ้น
 
-### 1.2 In-Scope
-1. {In-scope item 1}
-2. {In-scope item 2}
+### In-Scope & Out-of-Scope
+- **In-Scope**:
+  - สิ่งที่ต้องทำในรอบนี้
+- **Out-of-Scope**:
+  - สิ่งที่ไม่ทำในรอบนี้ หรือยกยอดไปทำในเฟสถัดไป
 
-### 1.3 Out-of-Scope
-- {Items deliberately excluded or deferred to future features}
+### Risk & Mitigation Matrix
+| Risk | Severity | Mitigation |
+| :--- | :--- | :--- |
+| ความเสี่ยงที่อาจเกิดขึ้น | Low/Medium/High | แนวทางป้องกันหรือรับมือ |
 
-### 1.4 Acceptance Criteria
-- [ ] **AC-1**: {Acceptance criterion 1}
-- [ ] **AC-2**: {Acceptance criterion 2}
+### Success Criteria
+1. เกณฑ์ชี้วัดความสำเร็จข้อที่ 1
+2. เกณฑ์ชี้วัดความสำเร็จข้อที่ 2
 
 ---
 
-## 2. Plan & Test Strategy
+## 📐 2. Technical Spec & Contracts
+
+### Architecture & Component Design
+- อธิบายโครงสร้างหรือ Flow การทำงานของ Component/Module
 
-### 2.1 Files Modified / Created
-- `{file-path}` [NEW | MODIFY | DELETE]
+### Data Models & Schemas
+```typescript
+// Interface หรือ Type Definition
+```
 
-### 2.2 Quality Gates & Sensitivity Check
-- **Quality Gate Policy (`independentReview`)**: `manual` | `always` | `when-sensitive`
-- **UI Evidence / Browser Tests**: {Not applicable | Playwright / BrowserOS Neo}
-- **Review Strategy**: One feature-level review packet at completion
+### API & Interface Contracts
+- **Endpoint / Function**: `methodName(params: Type): ReturnType`
+- **Error Handling**: รายละเอียด Error Codes และวิธีจัดการ
 
-### 2.3 Test Decision: Required (TDD) | Optional
-- **Rationale**: {Reason for requiring Unit Tests / TDD}
+### Non-Functional Constraints
+- **Security**: การตรวจสอบ Input, การจัดการสิทธิ์, Secrets
+- **Performance**: ข้อจำกัดเรื่องความเร็ว หรือ Resource Usage
+
+### Acceptance Criteria (AC)
+- [ ] **AC-1**: เงื่อนไขการยอมรับข้อที่ 1
+- [ ] **AC-2**: เงื่อนไขการยอมรับข้อที่ 2
 
 ---
 
-## 3. Implementation Checklist (Strict TDD)
+## 📋 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 1: {Task 1 title}**
-  - [ ] 1.1 `[TDD-Red]`: {Write failing unit or behavioral test}
-  - [ ] 1.2 `[TDD-Green]`: {Write minimal implementation to pass test}
-  - [ ] 1.3 `[TDD-Refactor]`: {Refactor and ensure 100% tests green}
+- [ ] **Task 2: Feature Implementation**
+  - [ ] 2.1 `[TDD-Red]` เขียน Test ครอบคลุม Edge Cases
+  - [ ] 2.2 `[TDD-Green]` Implement Feature ตาม Contract
+  - [ ] 2.3 `[TDD-Refactor]` ตรวจสอบความถูกต้องและ Architecture
 
-- [ ] **Task 2: {Task 2 title}**
-  - [ ] 2.1 `[TDD-Red]`: ...
-  - [ ] 2.2 `[TDD-Green]`: ...
-  - [ ] 2.3 `[TDD-Refactor]`: ...
+- [ ] **Task 3: Integration & QA Verification**
+  - [ ] 3.1 `[TDD-Green]` เชื่อมต่อ UI/API และตรวจสอบ End-to-End
 
 ---
 
-## 4. Verification Evidence Matrix
+## ⚡ 4. Implementation Log & Evidence
 
-### ⚖️ Axis 1: Standards, Architecture & Quality Gate
-- **Type Safety & Build Integrity**: TBD
-- **Automated Test Matrix**: TBD
-- **Static Contract Verification**: TBD
-- **Package Smoke Test**: TBD
-- **Findings Ledger**: Verify `findings.md` is 100% clean
+*(จะถูกบันทึกและอัปเดตความคืบหน้าระหว่างรันคำสั่ง `/implement`)*
 
-### 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
-- [ ] **AC-1**: {Empirical proof for AC-1}
-- [ ] **AC-2**: {Empirical proof for AC-2}
+- **Step 1**: ...
+- **Checkpoint Commit**: `feat(scope): ...`
 
-### 🔗 Axis 3: AC-to-Test Traceability Matrix
+---
+
+## 🧪 5. Multi-Lane Verification Matrix
 
-| Acceptance Criterion | File Tier | Automated Test Case / Assertion | Verification Command | Status |
-| :--- | :--- | :--- | :--- | :---: |
-| **AC-1** | Tier 1 (Logic) / Tier 2 (UI) | `it('AC-1: ...')` | `npm test` | ⏳ Pending |
-| **AC-2** | Tier 3 (API) / Tier 4 (Tooling) | `it('AC-2: ...')` | `npm run check:static` | ⏳ Pending |
+*(จะถูกบันทึกผลการตรวจสอบระหว่างรันคำสั่ง `/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 | |
 
 ---
 
-## 5. Delivery Verification & Independent Receipt
+## 📦 6. Release Digest & Retrospective
+
+*(จะถูกสรุปและบันทึกอัตโนมัติก่อนทำการ Squash Merge ในคำสั่ง `/complete`)*
 
-- **Delivery Date**: TBD
-- **Verification Verdict**: TBD
-- **Framework Tests**: TBD
-- **Static Contract**: TBD
-- **Package Smoke Test**: TBD
+- **What Changed**: สรุปสิ่งที่เปลี่ยนแปลง
+- **Key Decisions**: การตัดสินใจสำคัญระหว่างพัฒนา
+- **Lessons Learned**: บทเรียนที่ได้รับ
+- **Known Limitations**: ข้อจำกัดที่ทราบและข้อเสนอแนะในอนาคต

package/template/devflow/runs/.gitkeep

@@ -0,0 +1 @@
+

package/template/.agents/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.