@jakkrichm/create-nexus-devflow 2.0.0

package/template/.agents/skills/pr-review-analysis/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: pr-review-analysis
+description: Review pull requests or local diffs with structured finding discipline, selective review lanes, and Nexus-DevFlow report templates. Use when the team needs a substantial review without turning review into a numbered workflow stage.
+---
+
+# PR Review Analysis
+
+## Overview
+
+This skill is the shared behavior layer behind `PR-Review`.
+
+It preserves the stronger PR review UX from the legacy workflow while fitting DevFlow 2.0 as a non-mainline support capability.
+
+## Related Foundation Skills
+
+This skill should reuse and align with:
+
+- `.agents/skills/9arm-skills/scrutinize/SKILL.md`
+- `.agent/resources/schemas/pr_review.template.md`
+
+## When to Use
+
+- after `/50-Verify` when the change needs structured review before `/60-Report` and `/70-Release`
+- when a local diff, branch, or pull request needs findings-first analysis
+- when the user wants review without directly editing code
+
+Do not use this skill as a substitute for implementation, debugging, or formal release packaging.
+
+## Process
+
+### 1. Load Review Context
+
+Read the minimum relevant context:
+
+- PR diff or local `git diff`
+- changed files
+- linked stage artifacts under the running workspace when available
+- nearby project patterns and affected runtime paths
+
+### 2. Apply Scrutiny First
+
+Start with the `scrutinize` discipline:
+
+- intent check
+- smaller or safer alternative
+- actual runtime path trace
+- precision and evidence check
+
+### 3. Select Review Lanes
+
+Use only the lanes that match scope:
+
+- correctness
+- maintainability
+- simplicity
+- testability and coverage
+- docs accuracy
+- AGENTS or instruction adherence
+- security
+- performance
+
+### 4. Validate Findings
+
+Before reporting a finding:
+
+- verify it against the changed code
+- confirm whether it is new or pre-existing
+- keep it actionable
+- include file and line references whenever possible
+
+### 5. Save Reusable Report
+
+When saving a substantial report, preserve:
+
+```text
+devflow/runs/{ID}-*/pr_review.md
+```
+
+Use `.agent/resources/schemas/pr_review.template.md` and replace all placeholder text with real findings, questions, risks, and evidence gaps.
+
+## Output
+
+Return:
+
+- findings ordered by severity
+- open questions or assumptions
+- residual risks or test gaps
+- where the review report was saved
+- the recommended next route such as `/40-Implement`, `/70-Release`, or `PR-Followup`

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

@@ -0,0 +1,127 @@
+---
+name: prd
+description: PRD workflow
+---
+
+---
+description: Strategic PRD Generator (Orchestration) - Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
+---
+# Phase 12: Strategic PRD Generator (Orchestration)
+
+## Feature Idea: $ARGUMENTS
+
+Transform a product or feature idea into a problem-first, hypothesis-driven Product Requirements Document (PRD).
+
+In DevFlow 2.0, this is a supporting workflow, not part of the numbered mainline state path. Use it when the idea is still too product-shaped for `/10-Define` or `/20-Spec` to proceed cleanly.
+Use `to-prd` when existing conversation, discovery, or codebase context is already sufficient and the job is synthesis rather than another interview.
+When invoked from `/00-Discover`, link the PRD to the Discovery ID and return to `/00-Discover {discovery_id}` for the final `Proceed`, `Defer`, or `Reject` decision. PRD does not create Running IDs.
+
+---
+
+## Internal Process
+
+You are an orchestrator. Your goal is to call the specialized PRD Architect agent and preserve the quality of discovery, framing, and scope decisions before the work enters the mainline execution flow.
+
+### Phase 1: Interactive Discovery
+**Call Agent**: `prp-core-prd-architect`
+
+- Provide the feature idea if one exists.
+- If no idea is provided, the agent should initiate discovery through targeted questions or structured prompting.
+- Support the agent in grounding the PRD around:
+  - **Who**: primary persona, context, environment, and trigger moment.
+  - **What**: the core problem or desired outcome.
+  - **Why**: limitations of the current process, product, or alternative solutions.
+  - **Success**: measurable outcomes, user signals, or business impact.
+
+### Phase 2: Grounding And Feasibility
+
+- Facilitate research into technical feasibility, domain context, and operational constraints.
+- Ensure the agent checks internal codebase or platform patterns when the idea must fit an existing system.
+- Apply `Research` or the relevant research agent/skill when the PRD mentions:
+  - external APIs
+  - SDKs
+  - databases
+  - cloud services
+  - auth providers
+  - payments
+  - browser or device dependencies
+- Apply competitor or market analysis only when differentiation, market positioning, or user pain points materially affect scope decisions.
+
+### Phase 3: Scope Definition
+
+- Review the agent's prioritization carefully.
+- Confirm:
+  - MVP definition
+  - non-goals
+  - explicit assumptions
+  - open questions
+  - risks that should remain visible before delivery planning
+- Do not let the PRD silently drift into implementation detail that belongs in `/20-Spec` or `/30-Plan`.
+
+### Phase 4: Output Generation
+
+- **MANDATORY:** Before generating the PRD, inspect `.agent/resources/schemas/prd.template.md` and use its required headings and table structure.
+- Before reporting completion, run:
+
+Review `{prd_path}` against `prd.template.md`, keep the required headings, and remove placeholder text before completion.
+
+- Replace any placeholder or template text with concrete product details, assumptions, risks, metrics, and open questions.
+- Save the PRD to:
+
+```text
+devflow/prds/{date}-{slug}.prd.md
+```
+
+- Verify the document includes:
+  - problem statement
+  - target user or actor
+  - key hypotheses
+  - success measures
+  - scope boundaries
+  - implementation phases at a product level, not task granularity
+
+### Phase 5: Map Into DevFlow 2.0
+
+Convert the PRD into explicit next steps for the Timeline flow:
+
+- `/00-Discover {discovery_id}` when the PRD belongs to an active discovery
+- `/10-Define` when product framing was created outside Discover and delivery has already been approved
+- `/20-Spec` when the delivery contract is ready to be locked
+- `/30-Plan {ID}` only after the spec is execution-ready
+
+The user should still approve the transition into execution work. Do not treat PRD generation as automatic task creation.
+
+---
+
+## Output
+
+Return:
+
+- where the PRD was saved
+- the short product thesis
+- major scope boundaries
+- the biggest open questions
+- the exact recommended next DevFlow 2.0 command
+
+---
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: product framing before implementation-ready scope exists
+- Typical handoff targets: `/00-Discover {discovery_id}`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
+
+## Sources
+
+- `AGENTS.md`
+- `.agent/resources/schemas/prd.template.md`
+- Related commands: `Brainstorm`, `Research`, `/10-Define`, `/20-Spec`, `Roadmap`, `Spec-Orchestrate`
+- Support skills: `to-prd`, `grill-with-docs`, `domain-modeling`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/00-Discover {discovery_id}` when invoked from discovery; otherwise `/10-Define`
+- **Why**: PRD shapes product intent, while Discover owns the delivery decision and Define owns Running ID creation.
+- **Alternative**: `Research` when technical feasibility or external dependencies are still unresolved.
+

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

@@ -0,0 +1,121 @@
+---
+name: preview
+description: Preview workflow
+---
+
+---
+description: Preview management and temporary runtime checks. Transitional compatibility path for the Preview companion command in DevFlow 2.0.
+---
+
+# Preview Management
+
+## Usage
+
+```text
+Preview
+Preview start
+Preview stop
+Preview restart
+Preview check
+```
+
+This file keeps its old numeric path for migration compatibility.
+
+In DevFlow 2.0, `Preview` is a companion command, not a numbered mainline workflow.
+
+Primary behavior now lives in:
+
+```text
+.agents/skills/preview-local-check/SKILL.md
+```
+
+Treat this workflow file as a compatibility wrapper around that skill.
+
+Manage the local preview development server or temporary runtime check.
+
+Use it when:
+
+- the team wants a quick visual or runtime check before formal verification
+- implementation needs a local smoke check
+- a temporary render helps clarify what changed
+- a human reviewer needs something concrete to inspect before giving feedback
+
+Preferred DevFlow 2.0 pairing:
+
+- from `/40-Implement`
+- from `/50-Verify`
+
+---
+
+## Sub-commands
+
+- `Preview` - show current preview status
+- `Preview start` - start the server
+- `Preview stop` - stop the server
+- `Preview restart` - restart the server
+- `Preview check` - run a health check
+
+---
+
+## Internal Process
+
+`Preview` manages the local preview workflow using the `preview-local-check` skill plus any available preview automation or equivalent project-local commands.
+
+When handling preview operations:
+
+1. detect the correct project or server command path
+2. report the current state clearly
+3. handle port conflicts gracefully
+4. keep the action scoped to preview management, not broader deployment
+5. distinguish between preview success and full verification success
+
+Commands should use the nearest equivalent project-local preview command for the project, such as `npm run dev`, `npm run preview`, framework-specific local servers, or other runtime helpers that already exist in the target project.
+
+### Resolving Port Conflicts
+
+If the port is in use, offer options:
+
+1. start on a different port
+2. terminate the process on the existing port
+3. specify a custom port
+
+### Status Format
+
+When displaying status, clearly state:
+
+- URL
+- project path
+- app type
+- health status
+- notes about blockers, missing dependencies, or startup warnings
+
+Example summary:
+
+```markdown
+## Preview Status
+
+- **URL**: `http://localhost:3000`
+- **Project Path**: `[absolute path]`
+- **App Type**: `Next.js | FastAPI | Odoo | PHP | Other`
+- **Health Status**: `OK | Warning | Failed`
+- **Notes**: [port conflict, startup issue, missing dependency, or none]
+```
+
+## Relationship To DevFlow 2.0
+
+- Classification: Companion command
+- Mainline status: Not a numbered stage
+- Typical entry points: `/40-Implement`, `/50-Verify`, UI or runtime checking
+- Typical handoff targets: `/50-Verify`, `Debug`, `/40-Implement`
+
+## Sources
+
+- `AGENTS.md`
+- `.agents/skills/preview-local-check/SKILL.md`
+- Related commands: `/40-Implement`, `/50-Verify`, `Debug`
+
+## Next Workflow Recommendation
+
+- **Primary**: `/50-Verify` when preview confirms the change is ready for formal checks
+- **Alternative**: `/40-Implement` when preview exposed implementation work
+

package/template/.agents/skills/preview-local-check/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: preview-local-check
+description: Manage local preview, smoke-check, and temporary runtime verification before formal verification. Use when implementation needs a quick visual or runtime check, when a reviewer needs a local URL, or when a change should be inspected before /50-Verify.
+---
+
+# Preview Local Check
+
+## Overview
+
+This skill handles preview management and lightweight runtime checks without pretending that preview success is the same as full verification success.
+
+Use it to:
+
+- start or stop a local preview server
+- report preview health and URL
+- run a quick smoke check before formal verification
+- give humans a concrete local artifact to inspect
+
+## When to Use
+
+- During `/40-Implement` when a quick runtime check is useful
+- During `/50-Verify` when the change needs visual or interactive confirmation
+- When a reviewer asks for a local preview URL
+
+Do not use this skill as a replacement for test evidence, verification evidence, or release readiness.
+
+## Process
+
+### 1. Detect Preview Path
+
+- identify the correct project-local preview command
+- detect the likely app type and default port
+- separate preview management from deployment logic
+
+### 2. Manage State
+
+- support `status`, `start`, `stop`, `restart`, and `check`
+- report port conflicts clearly
+- offer a safe alternate port when possible
+
+### 3. Report Health
+
+Always report:
+
+- URL
+- project path
+- app type
+- health status
+- blockers or warnings
+
+### 4. Route Back
+
+- return to `/50-Verify` when preview confirms the change is ready for formal checks
+- return to `/40-Implement` when preview reveals implementation issues
+- use `Debug` when the preview failure needs RCA
+
+## Output
+
+Return a concise preview status or action summary. When useful, save notes into the current stage artifact rather than inventing a separate contract.

package/template/.agents/skills/prompt-addons/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: prompt-addons
+description: Routes external prompt families into DevFlow 2.0 workflows, specialist agents, or thin skill aliases. Use when deciding whether a prompt-inspired behavior should become a mainline workflow, a companion command, a reusable skill, or remain legacy-only.
+---
+
+# Prompt Addons
+
+Use this skill when adapting outside prompt patterns into the DevFlow 2.0 system.
+
+## Core Rule
+
+Adapt intent, not old output contracts.
+
+DevFlow 2.0 uses a stage-based, markdown-first model:
+
+1. Mainline workflow stays minimal and ordered
+2. Companion commands exist for non-mainline help
+3. Specialist agents and skills handle reusable methods
+4. JSON-first orchestration is legacy and should not define new architecture
+
+## Mainline Routing
+
+| Need | Route to |
+| :--- | :--- |
+| Explore problem space | `/00-Discover` |
+| Clarify goal, scope, decisions | `/10-Define` |
+| Lock delivery contract | `/20-Spec` |
+| Break into execution plan | `/30-Plan` |
+| Build the change | `/40-Implement` |
+| Validate quality and evidence | `/50-Verify` |
+| Package release-ready outcome | `/70-Release` |
+| Summarize the full run | `/60-Report` |
+
+## Companion Command Routing
+
+| Command | Use when | Typical stage pairing |
+| :--- | :--- | :--- |
+| `Brainstorm` | โจทย์ยังไม่นิ่ง ต้องคิดทางเลือกก่อน lock | Discover, Define |
+| `Research` | ต้องหาหลักฐานหรือข้อมูลเพิ่ม | Discover, Define, Spec, Verify |
+| `Debug` | งานผิดปกติ ต้องหา root cause | Implement, Verify |
+| `Preview` | ต้องตรวจชิ้นงานระหว่างทาง | Implement, Verify |
+| `Wiki` | ต้องสกัดความรู้ reusable | Verify, Release, Report |
+| `Help` | ผู้ใช้ไม่แน่ใจว่าจะเริ่มตรงไหน | ก่อนเข้า stage หรือระหว่างทาง |
+
+## Classification Rule
+
+ก่อนสร้าง workflow ใหม่ ให้จัดประเภทก่อน:
+
+1. ถ้า intent เปลี่ยน stage ของงาน ให้ route เข้าสู่ mainline stage ที่มีอยู่
+2. ถ้าเป็นวิธีทำงานที่ใช้ซ้ำหลาย stage ให้เป็น skill
+3. ถ้าเป็นความเชี่ยวชาญเฉพาะด้าน ให้เป็น agent
+4. ถ้าเป็นแค่ตัวช่วยคิดหรือหาหลักฐานระหว่างทาง ให้เป็น companion command
+5. ถ้าอิง dashboard/json orchestration เดิมเป็นหลัก ให้คงไว้เป็น legacy หรือ migration note
+
+## Prompt Family Routing
+
+| Family | DevFlow 2.0 route | Keep as |
+| :--- | :--- | :--- |
+| Spec | `/10-Define`, `/20-Spec`, `/30-Plan` | workflow + `requirements-engineer` |
+| Complexity | `/10-Define`, `/30-Plan` | workflow content, not standalone mainline |
+| Roadmap | Discover/Define adjacent | skill or optional workflow outside core line |
+| Ideation | `Brainstorm`, `Research` | companion command |
+| Competitor | `Research` during Discover/Define | companion command or research skill |
+| Insight | `Wiki`, `/60-Report` | companion command + report content |
+| Coder | `/40-Implement` | workflow + specialist agents |
+| QA | `/50-Verify` | workflow + QA/test skills |
+| Follow-up | `/10-Define` or `/30-Plan` ของรอบใหม่ | stage reuse, not separate numbered mainline |
+| GitHub review | `/50-Verify`, `/70-Release` | workflow/agent support |
+| MCP tool validation | `/50-Verify` | tool-specific verification skill |
+
+## Borderline Rules
+
+| Idea | Route | Keep as | Rule |
+| :--- | :--- | :--- | :--- |
+| Validation fixer | `/50-Verify` แล้วค่อยย้อน `/40-Implement` ถ้าต้องแก้โค้ด | thin skill/process note | ให้ verification ชี้ failure ก่อนเสมอ |
+| Documentation ideation | `Brainstorm`, `Wiki`, `/60-Report` | skill-backed support | ไม่ต้องเปิด mainline ใหม่ |
+| Performance ideation | `/50-Verify` หรือ `/40-Implement` เมื่อมีหลักฐาน | specialist skill/agent | ต้องมี measurement |
+| Security ideation | `/50-Verify` หรือ `Debug` เมื่อมี incident symptom | specialist skill/agent | treat as finding-first |
+| Follow-up planning | `/10-Define` -> `/20-Spec` -> `/30-Plan` ของรอบใหม่ | mainline reuse | ไม่แยก workflow หมายเลขใหม่ |
+| Legacy dashboard orchestration | legacy note only | migration-only | ไม่ใช้เป็นแบบตั้งต้นของ DevFlow 2.0 |
+
+## Follow-Up Planning
+
+เมื่อผู้ใช้ต้องการต่อยอดงานเดิม:
+
+1. อ่าน stage artifacts ที่มีอยู่ของ running ID เดิม
+2. ระบุให้ชัดว่าอะไร lock แล้ว และอะไรจะเพิ่มใหม่
+3. เริ่มรอบใหม่จาก `/10-Define` ถ้าโจทย์เปลี่ยน หรือ `/30-Plan` ถ้า spec ยังใช้ได้
+4. ใช้ไฟล์ `.md` ของ stage ใหม่เป็นหลักในการบันทึกบริบท
+
+## Output Principle
+
+เมื่อ prompt family ถูกแปลงเข้าระบบ:
+
+1. อย่า copy contract เดิมเข้ามาตรง ๆ
+2. แปลงให้สอดคล้องกับ numbering rule ของ DevFlow 2.0
+3. อย่าทำให้ผู้ใช้ต้องเดาเลขย้อนกลับ
+4. ให้ mainline มีเฉพาะ state ของงาน
+5. ให้ความสามารถเสริมไปอยู่ใน skill, agent, หรือ companion command ตามความเหมาะสม

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

@@ -0,0 +1,44 @@
+---
+name: prototype
+description: Build a throwaway prototype to answer a design question during Discover, Define, Spec, Research, or Plan.
+disable-model-invocation: true
+---
+
+# Prototype
+
+A prototype is throwaway code that answers one question.
+
+Use this support skill behind `Research`, `Brainstorm`, `/00-Discover`, `/10-Define`, `/20-Spec`, or `/30-Plan` when conversation alone cannot settle the uncertainty.
+
+## Branches
+
+Choose one:
+
+- **Logic prototype**: use when the question is about state, business rules, parsing, scheduling, or algorithm behavior.
+- **UI prototype**: use when the question is about interaction, visual hierarchy, layout, or user flow.
+
+If the branch is ambiguous, state the assumption and choose the one closest to the surrounding code.
+
+## Rules
+
+- Mark it as throwaway.
+- Keep it close to the relevant module or task workspace.
+- Provide one command to run it.
+- Avoid persistence unless the question is specifically about persistence.
+- Skip polish, broad error handling, and abstractions.
+- Show state clearly after each action or variant switch.
+- Delete, absorb, or explicitly mark the prototype after it answers the question.
+
+## Durable Capture
+
+The answer is the artifact worth keeping.
+
+Capture:
+
+- the question
+- prototype path and command
+- what was learned
+- decision or remaining uncertainty
+- next DevFlow route
+
+Use an ADR only if the prototype resolves a hard-to-reverse, surprising trade-off.

package/template/.agents/skills/prp-dev-fastapi/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: prp-dev-fastapi
+description: Comprehensive skill for FastAPI development following the PRP Pure Agentic workflow. Includes project templates, async/await patterns, Pydantic validation, repository/service architecture, and automated validation loops. Use when designing, implementation, or refactoring FastAPI applications.
+---
+
+# 🚀 PRP Dev – FastAPI (Pure Agentic)
+
+This Skill operates to assist the AI Agent in systematically developing features for **FastAPI** following the PRP Framework standards, focusing on Architectural correctness, clean code, and automated Validation Loops.
+
+## 🎯 Scope of Work
+Apply this Skill when:
+- **Design**: Designing the API structure or Database Schema.
+- **Implementation**: Writing FastAPI code, Pydantic Models, or the Service Layer.
+- **Refactor**: Revamping legacy code for better organization or full Async compatibility.
+- **Workflow**: When engaging in tasks related to Backend APIs (spanning from planning to Verify).
+
+---
+
+## 1. 🔍 Platform & Stack Detection
+Always ascertain the environment prior to starting work:
+1. **Indicators**: Locate `FastAPI` in `main.py`, `requirements.txt`, or through `@app.get()` decorators.
+2. **Database/ORM**: Identify the utilization of `SQLAlchemy` (Async/Sync), `SQLModel`, or `Tortoise`.
+3. **Pydantic**: Confirm whether Version 1.x or 2.x is used (to guarantee proper Syntax).
+4. **Project Type**: Examine if the structure is Monolithic (Small) or Modular (Production-Ready).
+
+---
+
+## 2. 🏗️ Architecture & Organization
+Adhere to a Production-Ready architecture (strive to avoid files exceeding 500 lines):
+
+```text
+app/
+├── api/                    # API route handlers
+├── core/                   # config, security, database setup
+├── models/                 # Database models (ORM)
+├── schemas/                # Pydantic schemas (Request/Response)
+├── services/               # Business logic layer
+├── repositories/           # Data access layer (CRUD)
+├── utils/                  # Utility functions
+└── main.py                 # Application entry
+```
+
+### Naming Conventions
+- **Files**: `snake_case` (e.g., `auth_service.py`)
+- **Classes**: `PascalCase` (e.g., `UserUpdate`)
+- **Functions**: `snake_case` (e.g., `get_active_users`)
+- **Endpoints**: `kebab-case` (e.g., `/api/v1/user-profiles`)
+
+---
+
+## 3. 🛡️ Implementation Patterns (Best Practices)
+
+### 3.1 Async All The Way
+- Employ `async def` consistently for Endpoints.
+- Utilize `await` for all I/O operations (Database, API Call, File System).
+- **Prohibited**: Using Blocking code inside an Async function (e.g., `time.sleep`, `requests.get`). Employ `asyncio.sleep` or `httpx` instead.
+
+### 3.2 Dependency Injection (FastAPI `Depends`)
+Use `Depends` for managing Shared resources:
+```python
+@router.post("/", response_model=Item)
+async def create_item(
+    item_in: ItemCreate,
+    db: AsyncSession = Depends(get_db),
+    current_user: User = Depends(get_current_user)
+):
+    return await service.create(db, obj_in=item_in, user=current_user)
+```
+
+### 3.3 CRUD Repository Pattern
+Segregate Data management Logic from Business Logic:
+```python
+# repositories/base.py
+class BaseRepository(Generic[ModelType, CreateSchema, UpdateSchema]):
+    async def get(self, db: AsyncSession, id: Any) -> Optional[ModelType]:
+        result = await db.execute(select(self.model).where(self.model.id == id))
+        return result.scalars().first()
+```
+
+---
+
+## 4. 🔄 PRP Workflow Integration (Pure Agentic)
+For each Task, the Agent must adhere to these principles:
+
+### Phase: Planning (/30-Plan)
+- Designate the files to be created/modified in the `File & Directory Index`.
+- Formulate a comprehensive `Validation Loop`:
+    - **Step 1**: Lint & Type Check (`ruff`, `mypy`)
+    - **Step 2**: Unit Test (`pytest`)
+    - **Step 3**: Integration Test (Start the server and `curl` or use `httpx`)
+
+### Phase: Implement (/40-Implement)
+- Proceed with subtasks sequentially and update `implement.md` as the primary progress record.
+- When producing a new Endpoint, consistently generate the corresponding Pydantic Schema and Test simultaneously.
+
+### Phase: Verify (/50-Verify)
+- Execute all commands outlined in the `Validation Loop`.
+- Should an Error emerge, the AI must diagnose and rectify it promptly (Fix-Forward).
+
+---
+
+## 🧪 Testing & Validation
+- **Framework**: Utilize `pytest` alongside `pytest-asyncio`.
+- **Mocking**: Adopt `unittest.mock` or `pytest-mock` for External services.
+- **Async Client**: Use `httpx.AsyncClient` to dispatch Requests to FastAPI.
+- **Evidence**: Document passed outcomes in `verify.md` as the primary verification record.
+
+---
+
+## ⚡ Quick Reference: Common Gotchas
+- **Pydantic v2**: Employ `model_dump()` instead of `dict()` and `model_validate()` rather than `from_orm()`.
+- **SQLAlchemy Async**: Necessitates the `postgresql+asyncpg://` schema and requires `await session.commit()`.
+- **FastAPI Middleware**: Be cautious regarding the insertion sequence of Middleware (CORS should commonly be near the end or customized based on Auth requirements).
+- **Token Efficiency**: Should a file grow excessively long, propose Module Splitting as early as the Planning phase.