@jakkrichm/create-nexus-devflow 2.0.11 → 2.0.13

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

@@ -1,131 +1,42 @@
----name: insight
-
-description: "[Devflow] Extract reusable lessons, patterns, file insights, and post-mortem learning from completed work."
+---
+name: insight
+description: "[Devflow] Extract reusable lessons, architectural patterns, post-mortem incident learning, and token optimizations from completed work."
 ---
 
-# Phase 54: Insight Extraction
-
-## Target: $ARGUMENTS
-
-Use this workflow after implementation, QA, human approval, PR review, or a debugging session to preserve useful knowledge for future work.
-
-Primary behavior now lives in the `insight-capture` skill. Keep this workflow as the compatibility wrapper and knowledge-capture entry point.
-
-## Prompt Source
-
-Adapted from:
-
-- `insight_extractor.md`
-
-Additional credited discipline when the source work is a bug, regression, or incident:
-
-- `.agents/skills/9arm-skills/post-mortem/SKILL.md`
-- Source pack: `9arm-skills`
-- Credit: `thananon/9arm-skills`
-- Upstream: https://github.com/thananon/9arm-skills
-- Adapted for: Antigravity IDE / Nexus-DevFlow
-
-## Process
-
-### 1. Load Evidence
-
-Inspect the available evidence:
-
-- git diff or recent commits
-- `40-implement.md`
-- `50-verify.md`
-- `70-release.md`
-- `60-report.md`
-- modified files
-- human feedback or PR comments
-
-### 2. Extract Reusable Knowledge
-
-Capture only actionable knowledge:
-
-- file purpose and important changes
-- reusable patterns
-- gotchas and triggers
-- approach outcome
-- alternatives tried
-- context or token usage notes that explain avoidable overhead
-- recommendations for future sessions
-
-Avoid generic notes that do not help future work.
-
-For bug, regression, or incident work, apply the `post-mortem` lens only after fix and validation evidence exist:
-
-- what broke
-- impact
-- reliable repro or timeline
-- root cause
-- fix
-- validation evidence
-- why it slipped through
-- prevention or follow-up
-
-### 3. Save Or Route Insights
-
-Use the smallest durable destination:
+# Insight Extraction & Post-Mortem Learning
 
-- stage artifacts when the lesson is specific to the current run
-- `devflow/lessons.md` for project-wide lessons
-- `60-report` for final narrative communication before release
-- `70-release` for release-facing notes and execution details
+## Overview
 
-For token/context learning, prefer the smallest concrete note:
+This is the insight and knowledge extraction master skill for Nexus-DevFlow. It captures reusable engineering lessons, architectural patterns, gotchas, post-mortem incident analyses, and token-efficiency notes from completed implementation and verification work.
 
-- what context was loaded unnecessarily
-- which file, artifact, or agent handoff caused repeated reading
-- what should be passed as minimal context next time
-- exact token counts only when they are available from the runtime or provider
+**9arm Post-Mortem Pattern**:
+```text
+What Broke ➔ Business Impact ➔ Root Cause ➔ Fix Evidence ➔ Prevention & Guardrails
+```
 
-When updating `devflow/lessons.md`, inspect `.agent/resources/schemas/lessons.template.md` first and replace any placeholder text with concrete incident facts, insight, prevention, and follow-up action.
+---
 
-If task logs are appropriate:
+## 1. Types of Knowledge Extracted
 
-If this insight must be tied back to the running work item, record it in `50-verify.md`, `60-report.md`, `70-release.md`, or `devflow/lessons.md` rather than a legacy task log command.
+1. **Architectural Patterns**: Reusable structural patterns, data transformations, or component designs.
+2. **Gotchas & Hidden Invariants**: Subtle platform bugs, async timing issues, ORM quirks, or browser edge cases.
+3. **Incident Post-Mortems**: Rigorous root cause analysis and why tests/checks failed to catch the bug initially.
+4. **Context & Token Optimization**: Notes on avoidable context reading or redundant artifact parsing.
 
-## Output
+---
 
-Return:
+## 2. Process & Recording Destinations
 
-- file insights
-- patterns discovered
-- gotchas discovered
-- approach outcome
-- context usage notes
-- recommendations
-- where the insight was recorded or should be recorded
+1. **Load Evidence**: Review `git diff`, `40-implement.md`, `50-verify.md`, or test logs.
+2. **Distill Insights**: Formulate clear, actionable, non-generic takeaways.
+3. **Save to Persistent Memory**:
+   - Save project-wide engineering lessons to `devflow/context/lessons.md` (or `knowledge/lessons.md`).
+   - Feed run-specific learnings into `60-report.md` and `70-release.md`.
 
-If `post-mortem` was applied, include a short `Source Discipline` note crediting `9arm-skills/post-mortem`.
+---
 
 ## Relationship To DevFlow 2.0
 
-- Classification: Companion command
-- Mainline status: Knowledge capture command, not a numbered stage
-- Typical entry points: after `Debug`, `50-verify`, incident work, or review findings
-- Typical handoff targets: `Wiki`, `60-report`, `Help`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/resources/schemas/lessons.template.md`
-- Related commands: `Debug`, `50-verify`, `Wiki`, `60-report`, `Help`
-
-## Next Workflow Recommendation
-
-- **Primary**: `Wiki project ingest {source}` when the insight is reusable project knowledge.
-- **Why**: `Insight` extracts lessons; `Wiki` compiles selected lessons into navigable knowledge pages.
-- **Alternatives**:
-  - `60-report {ID}` - choose this when the insight should become the final communication summary before release.
-  - `70-release {ID}` - choose this when the insight should shape release packaging or execution details.
-  - `Help {ID}` - choose this when the next route is unclear.
-
-## Wiki Update Recommendation
-
-- **Needed**: `yes` for reusable lessons, gotchas, decisions, validated root causes, or token/context optimizations.
-- **Scope**: `project` for target-project lessons, `framework` for DevFlow workflow lessons.
-- **Reason**: Insight extraction is the safest handoff point for wiki compilation.
-- **Suggested Command**: `Wiki project ingest {source}`
-
+- **Classification**: Companion command & Continuous learning
+- **Mainline integration**: Invoked after `50-verify` or `60-report`.
+- **Handoff**: `60-report`, `70-release`

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

@@ -3,119 +3,40 @@ name: preview
 description: "[Devflow] Local preview server management, smoke-check, and temporary runtime inspection before formal verification."
 ---
 
----
-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
-```
+# Preview Management & Local Runtime Inspection
 
-Treat this workflow file as a compatibility wrapper around that skill.
+## Overview
 
-Manage the local preview development server or temporary runtime check.
+This is the preview master skill for Nexus-DevFlow. It manages local development/preview servers (`npm run dev`, `npm run preview`, `vite`, `next dev`), handles port conflicts, and executes smoke checks before formal verification.
 
-Use it when:
+## Usage & Sub-Commands
 
-- 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`
+- `/preview`         - Inspect current preview status and health
+- `/preview start`   - Start the local preview/dev server
+- `/preview stop`    - Stop the running server process
+- `/preview restart` - Restart the preview server
+- `/preview check`   - Perform runtime smoke check against `http://localhost:<port>`
 
 ---
 
-## Sub-commands
+## 1. Process & Runtime Management
 
-- `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
+1. **Detect Framework & Command**: Identify the project runtime (`npm run dev`, `vite preview`, `pnpm start`, `python -m http.server`).
+2. **Handle Port Conflicts**: Check if the standard port (3000, 5173, 8080) is occupied; auto-select fallback port or terminate stale background processes.
+3. **Health & Smoke Check**: Query local endpoint via HTTP GET to verify HTTP 200 OK and asset loading.
+4. **Report Status**:
+   ```markdown
+   ## Preview Status
+   - **URL**: `http://localhost:3000`
+   - **App Type**: Next.js / Vite / Node.js
+   - **Health Status**: `OK` (200 OK)
+   - **Console / Network**: Zero fatal runtime errors
+   ```
 
 ---
 
-## 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
-
+- **Classification**: Companion command & Runtime support
+- **Mainline stages**: `40-implement` (interactive visual check), `50-verify` (smoke test check)
+- **Handoff**: `50-verify`

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