@jakkrichm/create-nexus-devflow 2.0.11 → 2.0.13

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

@@ -1,55 +1,71 @@
 ---
 name: review
-description: "[Devflow] Two-axis review for changed work. Use inside 50-verify or 70-release when a branch, PR, or work-in-progress diff needs standards and spec review."
+description: "[Devflow] Multi-axis code and PR review. Reviews diffs against standards, specs, correctness, security, performance, and 9arm scrutinize discipline."
 ---
 
-# Review
+# Code Review, Quality & PR Analysis
 
-Use this support skill as one verification lane. `50-verify` owns validation evidence; this skill reviews a diff from two separate angles.
+## Overview
 
-## Axes
+This is the comprehensive review master skill for Nexus-DevFlow. It evaluates code modifications, local diffs, branches, and pull requests across multiple dimensions before merging or releasing. Every change gets reviewed before merge — no exceptions.
 
-- **Standards**: does the change follow documented repo conventions?
-- **Spec**: does the change implement the originating issue, PRD, spec, or stage artifact?
+**The approval standard**: Approve a change when it definitely improves overall code health and satisfies the specification, even if it isn't perfect.
 
-Keep the axes separate so one does not hide the other.
+---
+
+## 1. The Scrutinize Discipline (9arm Review Pattern)
+
+Before jumping into line-by-line comments, apply the 4-step Scrutiny check:
+1. **Intent Check**: What problem is this change truly trying to solve? Is this the right problem?
+2. **Safer / Smaller Alternative**: Could this be achieved with fewer lines, zero new dependencies, or less complexity?
+3. **Runtime Path Trace**: Trace the execution path through inputs, error handling, async boundaries, and state mutations.
+4. **Precision & Evidence**: Does the code contain unproven assumptions or missing test evidence?
 
-## Process
+---
+
+## 2. The Five-Axis Review Framework
 
-1. Pin the fixed point.
-   - Use the user-supplied commit, branch, tag, or merge-base.
-   - If none is supplied, default to the active branch merge-base with `main` when available.
-   - Confirm the diff is non-empty.
+Every review evaluates code across these 5 core axes:
 
-2. Identify the spec source.
-   - Prefer `devflow/runs/{ID}-*20-spec.md`, `30-plan.md`, issue brief, PRD, or explicit user path.
-   - If no spec exists, mark the Spec axis as skipped.
+```text
+┌──────────────────────────────────────────────────────────┐
+│                 FIVE-AXIS CODE REVIEW                    │
+├──────────────┬───────────────────────────────────────────┤
+│ 1. Correctness│ Logic, edge cases, error paths, races     │
+│ 2. Simplicity │ Readable, concise, no dead code, DAMP/DRY │
+│ 3. Architecture│ Boundaries, dependencies, design patterns │
+│ 4. Security   │ Input validation, auth, no secrets/XSS    │
+│ 5. Performance│ No N+1 queries, async I/O, memoization    │
+└──────────────┴───────────────────────────────────────────┘
+```
 
-3. Identify standards sources.
-   - Look for repo docs such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, workflow docs, or stage contracts.
+---
 
-4. Review standards.
-   - Cite the violated standard.
-   - Distinguish hard violations from judgment calls.
-   - Skip issues that tooling already enforces unless tooling is missing.
+## 3. Review Lenses & Finding Severities
 
-5. Review spec.
-   - Report missing or partial requirements.
-   - Report scope creep.
-   - Report implemented behavior that appears wrong against the spec.
+Categorize all findings into actionable severities:
 
-6. Aggregate findings.
-   - Present `Standards` and `Spec` separately.
-   - Lead with concrete findings and file references.
-   - Record residual risk and skipped axes.
+- **P0 (Critical Blocker)**: Security vulnerability, data loss, runtime crash, broken main functionality. (Blocks `70-release`)
+- **P1 (Major Blocker)**: Spec mismatch, broken error handling, severe regression risk. (Blocks `70-release`)
+- **P2 (Normal Improvement)**: Readability, missing edge-case test, minor performance optimization.
+- **P3 (Nit / Suggestion)**: Naming polish, optional refactor, comment clarity.
 
-## Output
+---
+
+## 4. PR Review Process
+
+1. **Load Context**: Pin fixed point (merge-base with `main`), read spec (`20-spec.md`) and coding standards.
+2. **Review Standards vs. Spec**: Check adherence to project instructions (`AGENTS.md`) and acceptance criteria.
+3. **Validate Findings**: Ensure every finding is reproducible and points to specific files and line numbers.
+4. **Generate Report**: Save substantial review reports under:
+   ```text
+   devflow/runs/{ID}-{slug}/pr_review.md
+   ```
+
+---
 
-Return:
+## Relationship To DevFlow 2.0
 
-- fixed point and diff scope
-- standards sources
-- spec source or skipped reason
-- findings by axis
-- worst issue per axis
-- recommended DevFlow route
+- **Classification**: Companion command & Verification support
+- **Mainline stages**: `50-verify` (QA & Code Review lane), `70-release` (Pre-merge review)
+- **Handoff**: `40-implement` (for fixes), `50-verify`, `70-release`

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

@@ -103,6 +103,7 @@ Present the rollback plan to the user:
 ## Rules
 
 - **Preserve History**: Never delete run folders under `devflow/runs/`. Historical reports must remain intact.
+- **Update History Ledger**: When the rollback is completed and verified, update the target entry's status in `devflow/history/HISTORY.md` to `Rolled Back` with reference to the reversal commit.
 - **No Destructive Git Commands**: Never execute `git reset --hard HEAD~N` or `git push --force`. All reversals must be applied as forward commits.
 - **One Target Per Rollback**: Avoid bundling multiple unrelated rollbacks into one pass.
 - **Explicit Human Gate**: Always wait for user approval before applying any reverse diffs to code.

package/template/.claude/skills/security-review/SKILL.md

@@ -1,166 +1,63 @@
----name: security-review
-
-description: "[Devflow] High-severity security code review and vulnerability audit for folders, projects, files, or diffs."
-argument-hint: "[target folder, project path, file list, or git diff] [--lang=en]"
 ---
-
-# Security Review
-
-$ARGUMENTS
-
-Perform a focused security-only review of a specified target (directory, project, list of files, or code diff) for **High Severity** and **Critical** security vulnerabilities.
-
-This workflow is a companion command in DevFlow 2.0. It creates a standardized stage artifact contract inside the active workspace.
-
-## Purpose
-
-Use this workflow to check an entire folder, project, or changed files for major security risks. It ensures your codebase does not introduce high-severity flaws before advancing to verification or release.
-
-## Behavior
-
-When `Security-Review` is triggered:
-
-1. **Resolve target and scope**:
-   - Determine the target folder, project, list of files, or git diff from the arguments.
-   - Scan all source files in the target directory recursively, or evaluate the specific list of files/diff.
-2. **Anchor the run**:
-   - Locate the active `running_id` from the workspace.
-   - If no active running ID is found, prompt the user or create a temporary run workspace (e.g., `sec-global` under `devflow/runs/sec-global/`).
-3. **Execute security-focused analysis**:
-   - Trace trust boundaries and inputs across the target files.
-   - Check only for **High Severity** and **Critical** security vulnerabilities (e.g., SQL/Command Injection, hardcoded secrets, authentication bypass, path traversal, RCE, data exposure).
-   - Ignore theoretical, style, low-impact, or medium/low severity findings for status blocking, but report them under Suggestions if present.
-4. **Load Template**:
-   - Inspect `.agent/resources/schemas/security_review.template.md`.
-   - Read the `artifact_language` configuration (framework default: `"th"`).
-   - Generate the report in English.
-5. **Write the Artifact**:
-   - Write the finalized security report to `devflow/runs/{ID}-{slug}/security-review.md`.
-   - Ensure the output strictly follows the template contract structure (Headings 1 to 11).
-
-## Output Contract & Formats
-
-The generated artifact must follow the English contract shape below.
-
-### English Output Template
-
-```markdown
+name: security-review
+description: "[Devflow] Security review, vulnerability scanner, and code hardening. Audits for OWASP vulnerabilities, secrets, injections, and auth flaws."
 ---
-id: "{running_id}-security-review"
-title: "Security Review: {Work Title}"
-doc_type: "companion"
-stage: "security-review"
-created: "{Date}"
-updated: "{Date}"
-owner: "{Owner}"
-status: "draft"
-artifact_language: "th"
-related_run: "{running_id}"
-related_files: []
----
-
-# Security Review: {Work Title}
-
-## 1. Objective
-
-- Perform a focused security review on the target directory, project, or files to detect High Severity and Critical security vulnerabilities.
-
-## 2. Source Inputs
-
-- Review Target: {Review Target}
-- Files Evaluated: []
-
-## 3. Project Context To Preserve
 
-- Global security constraints and authorization invariants.
-- Known exceptions or legacy patterns excluded from security flags.
+# Security Review, Hardening & Vulnerability Audit
 
-## 4. Stage-Specific Content
+## Overview
 
-### 🛡️ Security Review Result
-- **Status:** [pass | fail]
-- **Reason:** [Explain in detail with file and line references if fail, or "No high-severity or Critical security vulnerabilities found" if pass]
+This is the comprehensive security master skill for Nexus-DevFlow. It combines static vulnerability scanning, threat modeling, OWASP Top 10 defenses, and code hardening. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory.
 
-### 💡 Suggestions for Next Agent Action / Handoff
-[Provide concrete instructions and guidance for the subsequent Agent. If pass, list any medium/low security findings or recommendations for human consideration, directing the next verification/release Agent accordingly. If fail, list step-by-step remediation tasks for the implementer Agent to execute.]
-
-### 🔍 Detailed Scope Analysis
-- **Secrets & Configuration:** [Pass | Fail]
-- **Input Validation & Injection:** [Pass | Fail]
-- **Access Control & Auth:** [Pass | Fail]
-- **Data Protection & Cryptography:** [Pass | Fail]
-- **File System & Shell Safety:** [Pass | Fail]
-
-## 5. AI Actions Performed
-
-- Analyzed target codebase and traced untrusted inputs to critical sinks.
-- Scanned for hardcoded secrets, API keys, and environment leaks.
-
-## 6. Human Review Required
-
-- Verify findings and evaluate false positives if any.
-- Review medium/low risk suggestions for optional implementation.
-
-## 7. Approval Status
-
-- Pending
-
-## 8. Next Allowed Command
-
-- `40-implement {running_id}` (if fail, for code remediation)
-- `50-verify {running_id}` (if pass, to verify execution correctness)
-
-## 9. Nexus Event
-
-- `Debug` for deep-dive diagnostics or debugging.
-- `grill-with-docs` to clarify security guidelines.
-
-## 10. Change Log
-
-- {Date}: Initial English security review report created.
-
-## 11. Additional Notes
+---
 
-- [Add custom sub-headings below if needed]
-```
+## 1. The Three-Tier Security Boundary
 
-## Pass Response Requirements
+### Always Do (No Exceptions)
+- **Validate & sanitize all inputs** at the boundary (Zod, Yup, schema validation).
+- **Parameterize all queries** — never concatenate user input into SQL/NoSQL queries.
+- **Encode outputs** to prevent XSS (rely on framework auto-escaping).
+- **Hash credentials** using bcrypt, Argon2, or scrypt.
+- **Enforce secure cookies**: `httpOnly`, `secure`, `sameSite=lax/strict`.
 
-When no High Severity or Critical vulnerability is found, the sections under **Stage-Specific Content** must be formatted as:
+### Never Do
+- **Never commit secrets**, API keys, tokens, or credentials to git.
+- **Never trust client-side checks** as a security barrier.
+- **Never use `eval()`, `exec()`, or raw `innerHTML`** with untrusted user data.
+- **Never expose internal stack traces** or detailed database errors to users.
 
-```markdown
-### 🛡️ Security Review Result
-- **Status:** pass
-- **Reason:** No high-severity or Critical security vulnerabilities found
+---
 
-### 💡 Suggestions for Next Agent Action / Handoff
-[List any medium, low security findings or recommendations for human consideration, directing the next verification/release Agent accordingly]
-```
+## 2. OWASP & Critical Vulnerability Vectors
 
-## Fail Response Requirements
+| Category | Primary Risk | Mandatory Defense |
+| :--- | :--- | :--- |
+| **A01: Broken Access Control** | IDOR, missing role checks | Enforce server-side authorization on every endpoint/data fetch |
+| **A02: Cryptographic Failures** | Plaintext tokens/passwords, weak cipher | Use TLS 1.3, salted hashing, secret managers / `.env` |
+| **A03: Injection** | SQL, NoSQL, OS Command, Template | Parameterized queries, avoid shell spawning with user input |
+| **A04: Insecure Design** | Missing rate limits, business logic flaw | Defense-in-depth, token bucket throttling, safe defaults |
+| **A05: Security Misconfig** | Permissive CORS (`*`), exposed debug endpoints | Restrict CORS origins, disable debug/admin paths in production |
+| **A07: Identification & Auth** | Session fixation, brute-force | Account lockouts, secure session rotation, MFA support |
+| **A08: Software & Data Integrity**| Untrusted CI/CD packages, deserialization | Run `npm audit`, pin dependency hashes, validate payloads |
+| **A09: Logging & Monitoring** | Missing audit logs or logging secrets | Structured logging with PII masking, alert on repeated auth failure |
+| **A10: SSRF** | Fetching internal URLs from user input | Whitelist allowable destination protocols and domains |
 
-When a High Severity or Critical vulnerability is found:
+---
 
-- Use status `fail`.
-- Explain why the issue is High/Critical Severity with file and line references.
-- In **Suggestions for Next Agent Action / Handoff**, write a clear set of step-by-step remediation tasks for the Coder/Implementer Agent to resolve the vulnerability.
+## 3. Security Review Process
 
-## Security Scope & Rules
+1. **Target & Scope**: Inspect targeted files, PR diffs, or entire project directories.
+2. **Trace Trust Boundaries**: Follow untrusted data from entry (HTTP handlers, CLI arguments, file uploads) to sinks (DB, shell, HTML).
+3. **Scan for Secrets & Configs**: Detect hardcoded passwords, private keys, and environment variable leaks.
+4. **Generate Report**: Save formal security audits under:
+   ```text
+   devflow/runs/{ID}-{slug}/security-review.md
+   ```
 
-Evaluate high-severity risks including:
-- **Hardcoded secrets**: passwords, API keys, private keys, database strings.
-- **Injections**: SQL, NoSQL, OS Command, Template, or Path traversal.
-- **Unvalidated inputs**: dynamic evaluation (`eval`), shell execution, or raw unescaped HTML rendering.
-- **Insecure configuration**: broken authorization, sensitive exposure in public endpoints/logs.
+---
 
 ## Relationship To DevFlow 2.0
 
-- **Classification**: Companion command
-- **Mainline Status**: Not part of the linear Timeline. Can be run at any stage.
-- **Typical Entry Points**: Any stage, especially before `50-verify` or `70-release` to verify security health.
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/security_review.template.md`
-- `docs/workspace-artifacts.md`
+- **Classification**: Companion command & Safety gate
+- **Mainline integration**: Run during `40-implement` or `50-verify` before `70-release`.
+- **Handoff**: P0/P1 security findings block release and return to `40-implement` for immediate remediation.

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

@@ -3,77 +3,68 @@ name: simplify
 description: "[Devflow] Code simplification and refactoring for clarity and maintainability without altering runtime behavior."
 ---
 
----
-description: Simplify code for clarity and maintainability while preserving behavior.
----
-
-# Simplify - Code Simplification And Refactoring
+# Code Simplification & Refactoring
 
-Invoke the `code-simplification` skill.
+## Overview
 
-Primary behavior already lives in:
-
-```text
-.agents/skills/code-simplification/SKILL.md
-```
+This is the comprehensive code simplification master skill for Nexus-DevFlow. It reduces cognitive load, cleans up unnecessary abstractions, flattens deep nesting, and removes dead code while **preserving 100% exact runtime behavior**.
 
-Treat this workflow file as a wrapper around that skill.
+**Core Rule**: Every simplification must pass: *"Would a new team member understand this faster than the original, without any behavioral regression?"*
 
-Use this workflow when the code works but has grown harder to read, harder to change, or more general than necessary.
+---
 
-In DevFlow 2.0, `Simplify` is a supporting implementation workflow. It usually pairs with `40-implement` and should end in `50-verify`.
+## 1. The Five Principles of Simplification
 
-## Process
+1. **Preserve Behavior Exactly**: Same inputs, outputs, error conditions, side effects, and ordering.
+2. **Follow Project Conventions**: Consistency with neighboring files beats personal style preferences.
+3. **Delete Dead & Unused Code**: Remove abandoned helpers, dead branch paths, and leftover debugging code.
+4. **Flatten Control Flow**: Replace nested conditionals and callback pyramids with guard clauses and early returns.
+5. **Eliminate Speculative Generalization**: Replace single-use abstractions with clear, direct implementations.
 
-1. Read project instructions and study local conventions.
-2. Identify the target code: recent changes unless a broader scope is specified.
-3. Understand purpose, callers, edge cases, and test coverage before touching it.
-4. Scan for simplification opportunities:
-   - deep nesting to guard clauses or extracted helpers
-   - long functions to responsibility-based splits
-   - nested ternaries to clearer control flow
-   - vague names to descriptive names
-   - duplicated logic to shared helpers
-   - dead code to removal after confirmation
-   - speculative abstraction to simpler concrete flow
-5. Inspect `.agent/resources/schemas/refactoring.template.md` before generating a report.
-6. Apply each simplification incrementally and run verification after each meaningful change.
-7. Save the refactoring report to:
+---
 
-```text
-devflow/reports/{date}-refactoring-{slug}.md
+## 2. High-Impact Simplification Techniques
+
+### A. Guard Clauses Over Nested Conditionals
+```typescript
+// Before: Deep indentation
+function processOrder(order) {
+  if (order) {
+    if (order.isValid) {
+      if (order.isPaid) {
+        return fulfill(order);
+      }
+    }
+  }
+}
+
+// After: Early returns
+function processOrder(order) {
+  if (!order || !order.isValid) return;
+  if (!order.isPaid) return;
+  return fulfill(order);
+}
 ```
 
-8. Verify tests pass, the build succeeds, and the diff stays behavior-preserving.
-
-If tests fail after a simplification, revert that specific change and reconsider.
+### B. Inline Single-Use Helpers & Dead Shims
+If a helper function is only called once and adds indirection without semantic clarity, inline it directly.
 
-## Output
+### C. Remove Dead Code & Leftover Comments
+Delete commented-out code blocks, `// removed` notes, and unused variables (`_unused`). Version control (Git) remembers the history.
 
-Return:
-
-- what was simplified
-- what was intentionally left alone
-- validation evidence
-- remaining risks or debt
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: `40-implement`, `50-verify`, `PR-Review`, `Agent`
-- Typical handoff targets: `40-implement`, `50-verify`, `PR-Review`
+---
 
-## Sources
+## 3. Verification & Safety Loop
 
-- `AGENTS.md`
-- `.agents/skills/code-simplification/SKILL.md`
-- `.agent/resources/schemas/refactoring.template.md`
-- Related commands: `40-implement`, `50-verify`, `PR-Review`, `Agent`
+1. Run unit tests before touching code (`npm test` -> GREEN).
+2. Apply one small refactoring step at a time.
+3. Rerun tests immediately after each step. If tests break, revert and reconsider.
+4. Verify overall build and linter checks.
 
-## Next Workflow Recommendation
+---
 
-- **Primary**: `50-verify`
-- **Why**: simplification should finish with explicit proof that behavior did not regress
-- **Alternative**: `40-implement` when simplification exposed a deeper implementation change rather than a pure refactor
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Refactoring support
+- **Mainline integration**: Used during `40-implement` (Refactor step of TDD) or `50-verify`.
+- **Handoff**: `50-verify` (proves zero regressions).

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

@@ -1,82 +1,94 @@
 ---
 name: test
-description: "[Devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
+description: "[Devflow] Test-driven development, test generation, test execution, and coverage analysis across unit, integration, and smoke test suites."
 ---
 
----
-description: Test Generation and Execution - Generates missing tests, runs existing test suites, or checks test coverage for the project.
----
-# ๐Ÿงช Test Generation and Execution
-
-## Usage: `/13-Test [target]`
+# Test-Driven Development, Generation & Execution
 
-Generates missing tests, runs existing test suites, or checks test coverage for the project.
+## Overview
 
-Primary behavior now lives in:
+This is the comprehensive testing master skill for Nexus-DevFlow. It drives development with tests (TDD), handles test generation, execution, coverage analysis, and bug reproduction. Tests are proof — "seems right" is not done.
 
 ```text
-.agents/skills/test-execution-and-coverage/SKILL.md
+    RED                GREEN              REFACTOR
+ Write a test    Write minimal code    Clean up the
+ that fails  ──→  to make it pass  ──→  implementation  ──→  (repeat)
+      │                  │                    │
+      ▼                  ▼                    ▼
+   Test FAILS        Test PASSES         Tests still PASS
 ```
 
-Treat this workflow file as a compatibility wrapper around that skill.
+## Usage & Sub-Commands
+
+- `/test`                - Run all project test suites
+- `/test [file/feature]` - Generate tests for a specific target
+- `/test coverage`       - Show test coverage report
+- `/test watch`          - Run tests in watch mode
 
 ---
 
-## ๐Ÿ› ๏ธ Sub-commands
+## 1. The TDD Cycle
+
+### Step 1: RED — Write a Failing Test
+Write the test first. It must fail. A test that passes immediately proves nothing.
+
+### Step 2: GREEN — Make It Pass
+Write the minimum code to make the test pass. Avoid premature over-engineering.
 
-- `/13-Test`                - Run all tests
-- `/13-Test [file/feature]` - Generate tests for a specific target
-- `/13-Test coverage`       - Show test coverage report
-- `/13-Test watch`          - Run tests in watch mode
+### Step 3: REFACTOR — Clean Up
+Improve code readability, naming, structure, and eliminate duplication while keeping tests green.
 
 ---
 
-## ๐Ÿšฆ Internal Process
+## 2. The Prove-It Pattern (Bug Reproduction)
 
-### Scenario A: Generate Tests
-If the user requests tests for a target:
-1. **Analyze**: Identify functions, edge cases, and external dependencies.
-2. **Template Verification**: **MANDATORY:** Before generating the test plan, inspect `.agent/resources/schemas/test_report.template.md`, preserve its required layout, and replace placeholder text with concrete coverage, command output, failures, and gaps.
-3. **Generate Cases**: Develop Happy path, Error cases, Edge cases.
-4. **Write**: Implement the tests using the project's testing framework (Pytest, Jest, Vitest, etc.). Follow the `Arrange-Act-Assert` pattern and mock external dependencies.
-5. **Save Test Report**: Save the test plan and results to `devflow/reports/{date}-test-report-{target}.md` (where `{date}` is today's date in `YYYY-MM-DD` format and `{target}` is a slugified version of the file or feature name).
+When fixing any defect, **do not attempt a fix without proving the bug exists first**:
 
-### Scenario B: Execute Tests
-Use the project's native command (e.g., `npm test`, `pytest`) to run the tests and format the output clearly for the user. Highlight any failed tests with expected vs received values. Save the execution summary report matching the template to `devflow/reports/{date}-test-report-run.md` (where `{date}` is today's date in `YYYY-MM-DD` format).
+```text
+Bug report arrives ➔ Write reproduction test (FAILS) ➔ Implement fix ➔ Test PASSES ➔ Guard regression
+```
 
 ---
 
-## ๐Ÿ›ก๏ธ Key Principles
-- **Test behavior, not implementation.**
-- **One assertion per test** (when practical).
-- **Descriptive test names.**
-- **Arrange-Act-Assert pattern.**
-- **Save Report**: Always save the test plan or results to disk for persistent logging.
+## 3. The Test Pyramid & Resource Sizes
 
-## ๐Ÿ“ Output Formats
+| Level | Size | Target % | Scope & Characteristics |
+| :--- | :--- | :--- | :--- |
+| **Unit** | Small | ~80% | Pure logic, in-memory, single process, milliseconds each |
+| **Integration** | Medium | ~15% | API boundaries, database interaction, component seams |
+| **E2E** | Large | ~5% | Critical user journeys, full workflows, browser automation |
 
-### For Test Generation
-Generate a summary indicating:
-- **Test Plan**: Table of Test Case, Type, Coverage (Happy path, error case, validation)
-- **Generated Tests**: File path and the code block
-- **Report Location**: Confirm the report has been written to the specified workspace path.
-- **Run command**: e.g. `npm test`
+---
 
-### For Test Execution
-Display an organized output listing Passed/Failed files, and explicitly show the expectation vs received outcome for failed assertions.
+## 4. Key Testing Principles & Best Practices
 
-## Relationship To DevFlow 2.0
+1. **Test behavior, not implementation details**: Assert on output and state changes, not private method call sequences.
+2. **DAMP over DRY in tests**: Descriptive and meaningful test setup beats overly abstract shared helpers.
+3. **Arrange-Act-Assert**: Distinct setup, action, and verification phases in every test case.
+4. **Prefer real implementations & fakes over heavy mocks**: Mock only at boundaries where real dependencies are slow or non-deterministic.
+5. **One assertion concept per test**: Isolate test failure reasons clearly.
 
-- Classification: Companion command
-- Mainline status: Verification support command, not a numbered stage
-- Typical entry points: `40-implement`, `50-verify`, `Debug`
-- Typical handoff targets: `50-verify`, `Debug`, `QA-Orchestrate`
+---
+
+## 5. Browser Testing & Runtime Verification
+
+For browser and UI features, unit tests alone are insufficient:
+- **Console**: Zero errors and unhandled exceptions in production code.
+- **Network**: Accurate status codes, payload shapes, and CORS handling.
+- **DOM & Styles**: Verified layout rendering, accessibility tree, and responsive behaviors.
+
+---
+
+## 6. Test Generation & Persistent Execution Reports
 
-## Sources
+When generating or logging test runs during `40-implement` or `50-verify`:
+- Save summary reports to `devflow/reports/{date}-test-report-{slug}.md`
+- Include: Target, Test Cases (Happy Path, Error, Edge Cases), Pass/Fail statistics, and gaps/risks.
 
-- `AGENTS.md`
-- `.agents/skills/test-execution-and-coverage/SKILL.md`
-- `.agent/resources/schemas/test_report.template.md`
-- Related commands: `40-implement`, `50-verify`, `Debug`, `QA-Orchestrate`
+---
 
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Engineering standard
+- **Mainline stages**: `30-plan` (TDD decisions), `40-implement` (TDD execution), `50-verify` (QA gate)
+- **Handoff**: `50-verify`, `Debug`, `autopilot`

package/template/devflow/history/HISTORY.md

@@ -0,0 +1,27 @@
+# Nexus-DevFlow Master Release History Ledger
+
+This master ledger tracks all released delivery runs, milestones, and rollbacks in chronological order. Each entry is recorded during the `70-release` stage and links to its exact Git commit hash, release tag, and generated delivery artifacts.
+
+---
+
+## 📜 Release Log
+
+| Release Date | Running ID | Title | Git Tag / Commit | Release Status | Report Link |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| 2026-08-18 | `RUN-008` | ปรับปรุงโครงสร้าง Nexus-DevFlow ให้ Lean & Clean ยุบรวม Skills บริหารจัดการ History และ Safe Rollback | `be713ea` | `Released` | [`60-report.md`](../runs/RUN-008-lean-and-clean-devflow-optimization/60-report.md) |
+| 2026-08-18 | `RUN-007` | ยกระดับระบบ Nexus-DevFlow ด้วยวินัยและกลไกสำคัญจาก Blueprint | `e79528b` | `Released` | [`60-report.md`](../runs/RUN-007-integrate-blueprint-skills-enhancements/60-report.md) |
+| 2026-08-18 | `RUN-006` | Standardize Command Naming and Provider Invocation | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-006-standardize-command-naming-and-provider-invocation/60-report.md) |
+| 2026-08-18 | `RUN-005` | Add DevFlow Prefix to Skill Descriptions | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-005-add-devflow-prefix-to-skill-descriptions/60-report.md) |
+| 2026-08-18 | `RUN-004` | Add Autopilot Skill | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-004-add-autopilot-skill/60-report.md) |
+| 2026-08-18 | `RUN-003` | Add Try, Rollback, CI, Brief Skills | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-003-add-try-rollback-ci-brief-skills/60-report.md) |
+| 2026-08-18 | `RUN-002` | Add Onboard, Adopt, Doctor Skills | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-002-add-onboard-adopt-doctor-skills/60-report.md) |
+| 2026-08-18 | `RUN-001` | Align DevFlow with Blueprint Architecture | `HEAD` | `Released` | [`60-report.md`](../runs/RUN-001-align-devflow-blueprint/60-report.md) |
+
+---
+
+## 🗄️ Run Lifecycle States
+
+- **Active**: Currently executing in `devflow/runs/{running-id}-{slug}/` (tracked in `devflow/context/current-stage.md`).
+- **Released**: Finished `70-release`, merged, and logged in this master ledger.
+- **Archived**: Older historical runs moved to `devflow/history/archived-runs/` to maintain a clean workspace.
+- **Rolled Back**: Features safely reversed via `/rollback` with documented post-reversal verification.

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

@@ -35,5 +35,5 @@ All DevFlow framework context, active runs, templates, and history are consolida
 ## Mainline Lifecycle Rules
 
 1. Mainline stages move linearly: `/00-Discover` ➔ `/10-Define` ➔ `/20-Spec` ➔ `/30-Plan` ➔ `/40-Implement` ➔ `/50-Verify` ➔ `/60-Report` ➔ `/70-Release`.
-2. Companion commands (`Goal`, `Brainstorm`, `Research`, `Debug`, `PRD`, `Issue-Triage`, `Security-Review`, `Wiki`, `Check-For-Updates`, `Help`) provide supporting context without replacing mainline stage numbers.
+2. Companion commands (`Goal`, `Brainstorm`, `Research`, `Debug`, `PRD`, `Issue-Triage`, `Security-Review`, `Check-For-Updates`, `Help`) provide supporting context without replacing mainline stage numbers.
 3. Every stage produces markdown-first evidence in `devflow/runs/` before passing verification gates.