@brunosps00/dev-workflow 0.13.0 → 1.0.0

package/scaffold/skills/dw-ui-discipline/references/visual-slop.md

@@ -0,0 +1,152 @@
+# Visual slop — 14 patterns + 17 default values to avoid
+
+Two parts:
+1. **Fourteen patterns** an ungrounded UI agent produces.
+2. **Seventeen specific values** that signal "no thought went into this."
+
+Used by `/dw-review --code-only` against UI diffs and by `/dw-redesign-ui` as a self-check during proposal.
+
+## The 14 patterns
+
+### 1. Uniform-section flatness
+
+Every section uses the same card style, same padding, same text size, same emphasis weight. The eye finds no anchor.
+
+- **Why it happens:** Default of "consistent = good" without realizing hierarchy needs deliberate variation.
+- **Fix:** One primary section per scroll height. Differentiate by size, weight, color saturation, or whitespace by ≥30%. Everything else recedes.
+- **Example violation:** Dashboard with 6 identical metric cards.
+- **Example fix:** One hero metric (largest, top); 3 supporting metrics; 2 minor metrics in a different visual treatment.
+
+### 2. Soft hierarchy
+
+Headings barely larger than body. Primary CTA same color as secondary. The user can't tell what to look at first.
+
+- **Why it happens:** "Elegant restraint" applied without ensuring guidance still works.
+- **Fix:** Squint at the design (literally). What jumps out? If nothing jumps out, increase contrast in size, weight, or color for the primary element.
+
+### 3. Decorative hover
+
+Hover effects on elements that have no click handler. Cards that fade slightly but don't link anywhere.
+
+- **Why it happens:** Default "apply hover to anything card-shaped."
+- **Fix:** Hover effect lives only on elements with an on-click. Non-interactive shapes get `cursor: default`. If it's hoverable, it must do something.
+
+### 4. Emoji as ornament
+
+Emojis in headers and section labels where they add no information: 🎯 Goals · 🚀 Launch · ✨ Features · 📊 Analytics · 🔥 Trending.
+
+- **Why it happens:** Training data has many "emoji-in-headers = engaging" patterns.
+- **Fix:** Use icons (lucide, heroicons, tabler) for semantic meaning. Reserve emojis for genuinely emotive contexts (celebrations, errors needing empathy). If removing the emoji preserves the meaning, remove it.
+
+### 5. Gradient cover
+
+Hero with diagonal purple-to-pink gradient. Buttons with subtle gradient. Card backgrounds with mesh gradients. Gradient as visual fallback for weak composition.
+
+- **Why it happens:** AI-art aesthetics leak into UI; gradients hide compositional weakness.
+- **Fix:** A gradient must earn its place — usually for hero zones with poetic copy. Solid colors with strong hierarchy beat gradients in utility surfaces.
+
+### 6. Glass-on-everything
+
+Frosted-glass effect on modals, cards, dropdowns, side panels — anywhere a surface can be layered. Including on top of plain backgrounds where the blur effect has nothing to blur.
+
+- **Why it happens:** macOS aesthetic. Looks premium without effort.
+- **Fix:** Glass only when there's meaningful content visible behind the surface. Glass over plain backgrounds adds visual noise without semantic gain.
+
+### 7. Center-aligned by default
+
+Body paragraphs center-aligned. Headlines centered. Forms with labels centered above inputs. Tabular data centered instead of column-aligned.
+
+- **Why it happens:** Marketing-page training data biases toward center.
+- **Fix:** Center for hero headlines and small CTA labels only. Body text and forms read better left-aligned in LTR scripts. Tabular data reads in columns.
+
+### 8. Grayscale wash
+
+Neutral gray palette everywhere — `slate-50`, `gray-100`, `zinc-200` — for backgrounds, borders, text, accents. No accent color, no character.
+
+- **Why it happens:** "Neutral = safe" plus shadcn/ui's neutral starting point.
+- **Fix:** Establish ONE accent color (from brand or curated defaults). Use it intentionally on the primary CTA, the active state, the one place the user looks first. Gray is the canvas, not the painting.
+
+### 9. Verb-less CTAs
+
+"Get Started" · "Learn More" · "Click Here" · "Submit" · "OK" buttons. Generic verbs that say nothing.
+
+- **Why it happens:** Default LLM verb library.
+- **Fix:** Use the verb the user is actually doing. "Approve refund" not "Submit". "Start free trial" not "Get Started". "Schedule a call" not "Contact us".
+
+### 10. Stock-illustration hero
+
+Figure-with-laptop hero art. Diverse-team-around-table illustration. Abstract floating shapes. Generic figures from illustration kits.
+
+- **Why it happens:** "Illustration = friendly" default. Cheap to produce.
+- **Fix:** Use product screenshots (real screens, real data, sanitized) or skip illustration entirely. A clean hero with strong typography beats generic illustration.
+
+### 11. Shadow soup
+
+Cards with shadow. Buttons with shadow. Inputs with shadow. Tooltips with shadow on shadows. Borders AND shadows AND gradients on one element.
+
+- **Why it happens:** Material Design leftover; depth as decoration.
+- **Fix:** Pick one depth mechanism per layer. If cards have shadow, buttons inside should not. If you use elevation systematically (Material 3), enforce the elevation hierarchy.
+
+### 12. Generic spinner
+
+Spinner overlay for every async operation, regardless of duration or context.
+
+- **Why it happens:** Default fallback in every UI library.
+- **Fix granularity:**
+  - <300ms: show nothing (spinner appearing then vanishing is flicker).
+  - 300ms–2s: skeleton loader matching content shape.
+  - 2s–10s: spinner + status text ("Loading orders...").
+  - 10s+: progress bar or step indicator + cancel button.
+
+### 13. Silent empty state
+
+"No items found." Centered. Nothing else. User has no idea what to do.
+
+- **Why it happens:** Empty state treated as edge case, not as a real screen.
+- **Fix:** Every empty state answers two questions: WHY is it empty (no data yet vs filter excluded everything vs error)? WHAT should the user do (CTA, like "Create your first invoice")?
+
+### 14. Toast spam
+
+Every UI event becomes a toast. Save successful → toast. Validation error → toast. Network slow → toast. Five stack up and the user reads none.
+
+- **Why it happens:** Toast is the default feedback mechanism in component libraries.
+- **Fix:** Toasts only for actions that need confirmation AWAY from the originating surface (background save, undo-able deletion). Inline feedback for form validation. Modal/banner for blocking errors. Cap at 2 stacked toasts.
+
+## The 17 anti-default values
+
+Specific values that signal "no thought went into this." Avoid unless you can articulate WHY you picked exactly this one:
+
+| Anti-default | Tell |
+|--------------|------|
+| `#3B82F6` (Tailwind blue-500) | The internet's default blue |
+| `rounded-lg` everywhere | Universal default; no surface character |
+| `shadow-md` on every card | Universal default; no depth hierarchy |
+| `bg-gradient-to-br from-purple-500 to-pink-500` | "AI startup landing page" gradient |
+| Inter as the only font choice | Default font of ~60% of new SaaS |
+| `font-bold` for every emphasis | Bold is one tool, not the only tool |
+| Lucide icons exclusively | One icon family is fine; signature is none |
+| Generic "happy team" hero illustration | Placeholder energy |
+| "Get Started" / "Learn More" CTA copy | Verb-less; says nothing |
+| 4 / 8 / 12 / 16 spacing exclusively | The default 4-step scale; no rhythm |
+| `border-gray-200` for every divider | Visual whisper; no intent |
+| Sans-serif headlines + sans-serif body | No typographic contrast |
+| Center-aligned everything | See pattern #7 |
+| Animated CSS confetti on success | Cheesy; mismatches most brands |
+| `bg-white dark:bg-gray-900` only | No real dark-mode design pass |
+| Single-column form on a wide screen | Vertical scroll where horizontal fits |
+| Modal for every interaction | Most modals should be inline editing |
+
+## How to apply this catalog
+
+In `/dw-redesign-ui` step 4 (propose) — before presenting design directions, self-check against this list. If you're using a pattern, say why explicitly ("gradient crutch — intentional for marketing hero"). Sometimes the pattern IS the right call; the discipline is awareness, not absolutism.
+
+In `/dw-review --code-only` UI section — grep the diff for the anti-default values and the patterns. Each hit becomes a finding under `dw-review-rigor`:
+- Pattern on a NEW surface → `medium` severity.
+- Pattern propagating EXISTING slop further → `low` severity (consistency wins).
+- Pattern on a redesign that was supposed to fix slop → `high` severity (regression).
+
+## When the patterns bend
+
+- **Marketing pages** can use gradients and emojis with more freedom — different surface job.
+- **Brand-mandated** values override this list (if your brand IS `#3B82F6`, use it).
+- **Component libraries** like shadcn ship neutral defaults — the discipline is to ADD character on top, not remove the neutrality.

package/scaffold/skills/dw-verify/SKILL.md

@@ -171,11 +171,11 @@ If no verification command exists for the project, state that explicitly in the
 
 This skill is invoked transparently from:
 
-- `/dw-run-task` — before committing the task's changes
-- `/dw-run-plan` — before Level 2 review and before declaring the plan complete
-- `/dw-fix-qa` — before marking a bug as resolved in `QA/bugs.md`
+- `/dw-run` — before committing the task's changes
+- `/dw-run` — before Level 2 review and before declaring the plan complete
+- `/dw-qa --fix` — before marking a bug as resolved in `QA/bugs.md`
 - `/dw-bugfix` — before claiming the bug is fixed (original symptom no longer reproduces)
-- `/dw-code-review` — before emitting an APPROVED verdict
+- `/dw-review --code-only` — before emitting an APPROVED verdict
 - `/dw-generate-pr` — blocks PR creation if the session has no passing VERIFICATION REPORT post-last-edit
 
 Callers should mention this skill in their "Skills Complementares" section so the user sees the dependency.

package/scaffold/skills/humanizer/SKILL.md

@@ -1,13 +1,7 @@
 ---
 name: humanizer
 version: 2.2.0
-description: |
-  Remove signs of AI-generated writing from text. Use when editing or reviewing
-  text to make it sound more natural and human-written. Based on Wikipedia's
-  comprehensive "Signs of AI writing" guide. Detects and fixes patterns including:
-  inflated symbolism, promotional language, superficial -ing analyses, vague
-  attributions, em dash overuse, rule of three, AI vocabulary words, negative
-  parallelisms, and excessive conjunctive phrases.
+description: Use when editing AI-generated text. Detects 24 'signs of AI writing' (em-dashes, rule-of-three, AI vocab, vague attributions). Triggers on docs, READMEs, blog posts, captions, marketing copy.
 allowed-tools:
   - Read
   - Write

package/scaffold/skills/remotion-best-practices/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: remotion-best-practices
-description: Best practices for Remotion - Video creation in React
+description: Use for video composition with Remotion + React. 25+ rules for composition, transitions, FFmpeg, performance. Triggers on .tsx Remotion files, video rendering, motion design, captions.
+allowed-tools:
+  - Read
 metadata:
   tags: remotion, video, react, animation, composition
 ---

package/scaffold/skills/security-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security-review
-description: Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.
+description: Use for security code review. OWASP patterns (injection, XSS, auth, authz, crypto, SSRF, secrets). Confidence-based reporting. Triggers on 'security review', auth/payment code, or /dw-secure-audit.
 allowed-tools: Read, Grep, Glob, Bash, Task
 license: LICENSE
 ---

package/scaffold/skills/security-review/languages/csharp.md

@@ -1,6 +1,6 @@
 # C# / .NET Security Patterns
 
-Covers **ASP.NET Core, ASP.NET (Framework), Blazor, Razor Pages, Minimal APIs, Entity Framework Core, ADO.NET, Dapper, Identity, NuGet**. Used by `/dw-security-check` as the primary reference when C# is detected in scope.
+Covers **ASP.NET Core, ASP.NET (Framework), Blazor, Razor Pages, Minimal APIs, Entity Framework Core, ADO.NET, Dapper, Identity, NuGet**. Used by `/dw-secure-audit` as the primary reference when C# is detected in scope.
 
 ---
 

package/scaffold/skills/security-review/languages/rust.md

@@ -1,6 +1,6 @@
 # Rust Security Patterns
 
-Covers **Actix Web, Axum, Rocket, Warp, Tonic (gRPC), Tower, Tokio, sqlx, Diesel, SeaORM, serde, reqwest, hyper, std::process, std::fs, unsafe blocks, FFI, and cargo supply chain**. Used by `/dw-security-check` as the primary reference when Rust is detected in scope.
+Covers **Actix Web, Axum, Rocket, Warp, Tonic (gRPC), Tower, Tokio, sqlx, Diesel, SeaORM, serde, reqwest, hyper, std::process, std::fs, unsafe blocks, FFI, and cargo supply chain**. Used by `/dw-secure-audit` as the primary reference when Rust is detected in scope.
 
 > Rust's ownership and borrow checker eliminate **memory-safety** classes of bugs (use-after-free, data races, buffer overflows) — but **logic bugs, misuse of `unsafe`, DoS via panic, injection into string-APIs, and supply-chain compromise are still present**. Do not assume "Rust = secure".
 

package/scaffold/skills/security-review/languages/typescript.md

@@ -2,7 +2,7 @@
 
 This file complements `javascript.md` (which already covers React/Vue/Express/Next/Angular/Node XSS, injection, DOM sinks, prototype pollution). Here we focus on **TypeScript-specific** vulnerability classes: type-system abuses, runtime vs compile-time gap, TS-native ORMs, TS-native validators, and framework-specific patterns unique to TS ecosystems.
 
-> Used by `/dw-security-check` as the primary reference when TS is detected in scope.
+> Used by `/dw-secure-audit` as the primary reference when TS is detected in scope.
 
 ---
 

package/scaffold/skills/vercel-react-best-practices/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: vercel-react-best-practices
-description: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
+description: Use for React/Next.js performance optimization. 67 rules across async, bundle, client, render, JS micro-perf. Triggers on React components, Next.js pages, data fetching, perf review, hydration issues.
+allowed-tools:
+  - Read
 license: MIT
 metadata:
   author: vercel

package/scaffold/templates-overrides-readme.md

@@ -23,7 +23,7 @@ git add .dw/templates/overrides/prd-template.md
 git commit -m "chore(templates): customize PRD template for our team"
 ```
 
-The override takes effect immediately. Commands that consume the template (`/dw-create-prd`, etc.) will read from `.dw/templates/<name>.md`, which is preserved as your edited copy.
+The override takes effect immediately. Commands that consume the template (`/dw-plan prd`, etc.) will read from `.dw/templates/<name>.md`, which is preserved as your edited copy.
 
 ## How to revert an override
 
@@ -46,9 +46,9 @@ npx @brunosps00/dev-workflow update
 
 - Removing critical-path sections like FR numbering or test plans — downstream commands rely on these.
 - Adding fields that conflict with the YAML frontmatter schema.
-- Anything that breaks `/dw-create-techspec` or `/dw-create-tasks` cross-references.
+- Anything that breaks `/dw-plan techspec` or `/dw-plan tasks` cross-references.
 
-If in doubt, run the workflow end-to-end after editing — the consistency check at the end of `/dw-create-tasks` will surface most structural breakages.
+If in doubt, run the workflow end-to-end after editing — the consistency check at the end of `/dw-plan tasks` will surface most structural breakages.
 
 ## Versioning your overrides
 

package/scaffold/en/commands/dw-code-review.md

@@ -1,385 +0,0 @@
-<system_instructions>
-You are an AI assistant specialized in formal Code Review (Level 3). Your task is to perform a deep analysis of the produced code, verify conformance with project rules, adherence to the TechSpec, code quality, and generate a formal persisted report.
-
-## When to Use
-- Use when performing a formal Level 3 code review before PR that includes PRD compliance, code quality, rules conformance, and test verification
-- Do NOT use when only checking PRD compliance (use `/dw-review-implementation` for Level 2)
-- Do NOT use when code has not been implemented yet
-
-## Pipeline Position
-**Predecessor:** `/dw-review-implementation` or `/dw-run-plan` | **Successor:** `/dw-generate-pr`
-
-Typically invoked before creating PR via `/dw-generate-pr`
-
-<critical>Use git diff to analyze code changes</critical>
-<critical>Verify if the code conforms to the rules in .dw/rules/</critical>
-<critical>ALL tests must pass before approving the review</critical>
-<critical>The implementation must follow the TechSpec and Tasks</critical>
-<critical>Generate the report at {{PRD_PATH}}/dw-code-review.md</critical>
-
-## Complementary Skills
-
-When available in the project under `./.agents/skills/`, use these skills as analytical support without replacing this command:
-
-- `dw-review-rigor`: **ALWAYS** — applies de-duplication (same pattern in N files = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, and signal-over-volume. The report's "Issues Found" table follows this discipline.
-- `dw-verify`: **ALWAYS** — invoked before emitting an `APPROVED` or `APPROVED WITH CAVEATS` verdict. Without a VERIFICATION REPORT PASS (test + lint + build), the verdict cannot be APPROVED.
-- `/dw-security-check`: **ALWAYS for TS/Python/C#/Rust projects** — invoked as step 6.7 (Security Layer) before emitting a verdict. If the project uses a supported language and `security-check.md` is missing OR has REJECTED status, the verdict is **REJECTED** — no exception.
-- `dw-simplification`: use when the diff touches dense or twisty code — applies Chesterton's Fence (understand WHY before flagging removal), behavior-preserving refactor protocol (test gate before/after), and complexity metrics (cyclomatic, cognitive, depth, fan-out) so that "simplify this" findings are concrete, not vibes-based.
-- `security-review`: use when auth, authorization, external input, upload, SQL, external integration, secrets, SSRF, XSS, or sensitive surfaces are present
-- `vercel-react-best-practices`: use when the diff touches React/Next.js to review rendering, fetching, bundle, hydration, and performance patterns
-
-## Codebase Intelligence
-
-<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY before reviewing. Do NOT skip this step.</critical>
-- Internally run: `/dw-intel "documented conventions and anti-patterns"`
-- Prioritize findings that violate documented conventions
-- Check if questionable architectural decisions are intentional (documented in `.dw/rules/`)
-
-If `.dw/intel/` does NOT exist:
-- Use `.dw/rules/` as context, falling back to grep
-- Suggest running `/dw-map-codebase` after the review for richer downstream context
-
-## Input Variables
-
-| Variable | Description | Example |
-|----------|-------------|---------|
-| `{{PRD_PATH}}` | Path to the PRD folder | `.dw/spec/prd-user-onboarding` |
-
-## Position
-
-This is **Review Level 3**:
-
-| Level | Command | When | Report |
-|-------|---------|------|--------|
-| 1 | *(embedded in /dw-run-task)* | After each task | No |
-| 2 | `/dw-review-implementation` | After all tasks | Terminal output |
-| **3** | **`/dw-code-review`** | **Before PR** | **`code-review.md`** |
-
-Level 3 includes EVERYTHING from Level 2 (PRD compliance) plus code quality analysis.
-
-## Objectives
-
-1. Verify PRD compliance (all RFs implemented)
-2. Verify adherence to TechSpec (architecture, endpoints, schemas)
-3. Analyze code quality (SOLID, DRY, complexity, security)
-4. Verify conformance with project rules
-5. Execute tests and verify coverage
-6. Generate formal `code-review.md` report
-
-## File Locations
-
-- PRD: `{{PRD_PATH}}/prd.md`
-- TechSpec: `{{PRD_PATH}}/techspec.md`
-- Tasks: `{{PRD_PATH}}/tasks.md`
-- Project Rules: `.dw/rules/`
-- Refactoring Catalog: `.dw/references/refactoring-catalog.md`
-- Output Report: `{{PRD_PATH}}/dw-code-review.md`
-
-## Process Steps
-
-### 1. Documentation Analysis (Required)
-
-- Read the PRD and extract functional requirements (RF-XX)
-- Read the TechSpec to understand expected architectural decisions
-- Read the Tasks to verify implemented scope
-- Read the relevant project rules (`.dw/rules/`)
-
-<critical>DO NOT SKIP THIS STEP - Understanding context is fundamental for the review</critical>
-
-### 2. Code Change Analysis (Required)
-
-Execute git commands to understand what was changed:
-
-```bash
-# See modified files
-git status
-
-# See diff of all changes
-git diff
-
-# See staged diff
-git diff --staged
-
-# See commits on current branch vs main
-git log main..HEAD --oneline
-
-# See full diff of branch vs main
-git diff main...HEAD
-
-# See statistics
-git diff main...HEAD --stat
-```
-
-For each modified file:
-1. Analyze changes line by line
-2. Verify they follow project patterns
-3. Identify potential issues
-4. If the diff includes sensitive surfaces, also run a review guided by the `security-review` skill
-5. If the diff includes React/Next.js, also review with `vercel-react-best-practices`
-
-### 3. PRD Compliance - Level 2 (Required)
-
-For EACH functional requirement from the PRD:
-```
-| RF-XX | Description | Status | Evidence |
-|-------|-------------|--------|----------|
-| RF-01 | User must... | ✅/❌/⚠️ | file.ts:line |
-```
-
-For EACH endpoint from the TechSpec:
-```
-| Endpoint | Method | Implemented | File |
-|----------|--------|-------------|------|
-| /api/xxx | GET | ✅/❌ | controller.ts |
-```
-
-For EACH task:
-```
-| Task | Doc Status | Real Status | Gaps |
-|------|------------|-------------|------|
-| 1.0 | ✅ | ✅ | - |
-```
-
-### 4. Rules Conformance (Required)
-
-For each impacted project, verify project-specific rules from `.dw/rules/`:
-
-**General Patterns (all projects):**
-- [ ] Explicit types (no `any`)
-- [ ] No `console.log` in production (only in dev/debug)
-- [ ] Adequate error handling
-- [ ] Multi-tenancy respected
-- [ ] Organized imports
-- [ ] Clear and descriptive names (no abbreviations)
-
-**Backend patterns (check .dw/rules/ for specifics):**
-- [ ] Architecture patterns respected (Clean Architecture, DDD, etc.)
-- [ ] Use Cases return proper result types
-- [ ] DTOs follow project conventions
-- [ ] Parameterized queries (no SQL injection)
-- [ ] Co-located unit tests (`*.spec.ts`)
-
-**Frontend patterns (check .dw/rules/ for specifics):**
-- [ ] Server Components by default (if Next.js)
-- [ ] `'use client'` only when necessary
-- [ ] Forms follow project form patterns
-- [ ] API calls use project fetch utilities
-- [ ] UI follows project design system
-
-### 4.1. Constitution Compliance (Required when `.dw/constitution.md` exists)
-
-<critical>**Auto-create if missing**: if `.dw/constitution.md` does NOT exist, copy `templates/constitution-template.md` (project-local `.dw/templates/constitution-template.md` first, falling back to bundled scaffold) verbatim with frontmatter `mode: defaults`. Print in chat: "Installed defaults constitution at `.dw/constitution.md` (all principles at `severity: info` — reported but not blocking this review). Continuing." Then proceed.</critical>
-
-For each principle in `.dw/constitution.md`, check the diff for violations:
-
-1. **Parse principles**: read each `**P-NNN — <name>** (severity: <S>)` entry; capture `P-NNN`, `severity`, and the `Enforcement` description.
-2. **Apply enforcement**: for each principle, run the enforcement check against the diff (grep, file inspection, or pattern match per the Enforcement line).
-3. **Classify violations**:
-   - Principle severity `info` → add row to "Issues Found" table with severity `low`. **Does not block** the verdict.
-   - Principle severity `high` → add row with severity `critical`. **Blocks** the verdict to `REJECTED` UNLESS an ADR in the same PRD's `adrs/` directory documents the deviation (look for `Deviates: P-NNN` in any ADR body).
-   - Principle severity `critical` → add row with severity `critical` AND require the ADR to have a non-empty `Approved by:` field. Missing field = still `REJECTED`.
-4. **No silent skips**: if the diff is too large to analyze every principle, report which were checked and which were skipped due to scope.
-
-**Output format in the report:**
-
-```markdown
-## Constitution Compliance
-
-| Principle | Severity | Status | Evidence | ADR escape |
-|-----------|----------|--------|----------|------------|
-| P-001 — No `any` casts | info | VIOLATED | src/foo.ts:42 | n/a |
-| P-009 — Server-side auth | high | VIOLATED | src/api/order.ts:18 missing auth middleware | none → BLOCKS |
-| P-010 — Secrets in repo | critical | PASS | — | — |
-```
-
-If any `high`/`critical` violation has no ADR escape: append to the verdict line "REJECTED — constitution violation(s) without ADR (see Constitution Compliance section)".
-
-### 5. Code Quality Analysis (Required)
-
-| Aspect | Verification |
-|--------|-------------|
-| **DRY** | Code not duplicated across files |
-| **SOLID** | Single Responsibility, Interface Segregation |
-| **Complexity** | Short functions, low cyclomatic complexity |
-| **Naming** | Clear names, no abbreviations, verbs for functions |
-| **Error Handling** | Proper try/catch, typed errors, no silencing |
-| **Security** | No SQL injection, XSS, secrets in code, input validation |
-| **Performance** | No N+1 queries, pagination, lazy loading |
-| **Testability** | Injectable dependencies, no hidden side effects |
-
-When the `security-review` skill is applied, report only high-confidence findings, clearly distinguishing:
-- Confirmed vulnerabilities
-- Items needing additional verification
-
-### 6. Test Execution (Required)
-
-For each impacted project, run the test suite:
-
-```bash
-# Check .dw/rules/ or project config for the correct test command
-pnpm test
-# or
-npm test
-```
-
-Verify:
-- [ ] All tests pass
-- [ ] New tests were added for new code
-- [ ] Tests are meaningful (not just for coverage)
-
-<critical>THE REVIEW CANNOT BE APPROVED IF ANY TEST FAILS</critical>
-
-### 6.5. Apply `dw-review-rigor` (Required)
-
-Before writing the "Issues Found" table, invoke the `dw-review-rigor` skill and apply the five rules:
-
-1. **De-duplicate**: if the same pattern appears in N files, emit 1 finding with the list of affected files — never N identical findings.
-2. **Severity ordering**: always present in critical → high → medium → low order (not by file).
-3. **Verify intent before flagging**: check adjacent comments, ADRs in `.dw/spec/*/adrs/`, test coverage, rules in `.dw/rules/`. Do not flag patterns with documented justification.
-4. **Skip what the linter catches**: run the project linter first; anything it already reports is not a finding.
-5. **Signal over volume**: ~8 precise findings beats 30 marginal ones. Keep all critical/high; prune medium/low to the most impactful.
-
-If prior reviews exist in `{{PRD_PATH}}/reviews/` or a previous `{{PRD_PATH}}/dw-code-review.md` round, read them and emit **only NEW findings** — do not re-flag items already tracked.
-
-### 6.6. Final Verification (Required before verdict)
-
-<critical>Invoke `dw-verify` and include the VERIFICATION REPORT at the start of the report. Without PASS, the verdict can only be `REJECTED` — never `APPROVED` or `APPROVED WITH CAVEATS`.</critical>
-
-### 6.7. Security Layer (Required for TS/Python/C#/Rust projects)
-
-<critical>For TypeScript/JavaScript, Python, C#, or Rust projects whose diff touches code, invoke `/dw-security-check` with the same `{{PRD_PATH}}`. Without a `security-check.md` present in the PRD OR with a status other than CLEAN / PASSED WITH OBSERVATIONS, the verdict is **REJECTED** — no exception.</critical>
-
-- If `/dw-security-check` returns **REJECTED**: automatic verdict **REJECTED**. Include the security-check's CRITICAL/HIGH findings with appropriate severity in the final report's "Issues Found" section.
-- If it returns **PASSED WITH OBSERVATIONS**: may proceed to APPROVED WITH CAVEATS, listing medium/low observations as caveats.
-- If it returns **CLEAN**: proceeds normally to a verdict based on the remaining criteria.
-- Projects in languages not supported by security-check (Go, Java, PHP, Ruby, etc.) → skip this step with a visible note in the code-review report.
-
-### 7. Generate Code Review Report (Required)
-
-Save to `{{PRD_PATH}}/dw-code-review.md`:
-
-```markdown
-# Code Review - [Feature Name]
-
-## Summary
-- **Date:** [YYYY-MM-DD]
-- **Branch:** [branch name]
-- **Status:** APPROVED / APPROVED WITH CAVEATS / REJECTED
-- **Files Modified:** [X]
-- **Lines Added:** [Y]
-- **Lines Removed:** [Z]
-
-## PRD Compliance (Level 2)
-
-### Status by Functional Requirement
-| RF | Description | Status | Evidence |
-|----|-------------|--------|----------|
-| RF-01 | [desc] | ✅/❌/⚠️ | [file:line] |
-
-### Status by Endpoint
-| Endpoint | Method | Status | File |
-|----------|--------|--------|------|
-| [endpoint] | [method] | ✅/❌ | [file] |
-
-### Status by Task
-| Task | Status | Gaps |
-|------|--------|------|
-| [task] | ✅/⚠️/❌ | [gaps] |
-
-## Rules Conformance
-| Rule | Project | Status | Notes |
-|------|---------|--------|-------|
-| Architecture | [project] | ✅/⚠️/❌ | [notes] |
-| Multi-tenancy | [project] | ✅/⚠️/❌ | [notes] |
-| Server Components | [project] | ✅/⚠️/❌ | [notes] |
-
-## Code Quality
-| Aspect | Status | Notes |
-|--------|--------|-------|
-| DRY | ✅/⚠️/❌ | [notes] |
-| SOLID | ✅/⚠️/❌ | [notes] |
-| Error Handling | ✅/⚠️/❌ | [notes] |
-| Security | ✅/⚠️/❌ | [notes] |
-
-## Tests
-- **Total Tests:** [X]
-- **Passing:** [Y]
-- **Failing:** [Z]
-- **New Tests:** [W]
-
-## Issues Found
-| Severity | File | Line | Description | Suggestion |
-|----------|------|------|-------------|------------|
-| CRITICAL/MAJOR/MINOR | [file] | [line] | [desc] | [fix] |
-
-## Positive Points
-- [positive points identified]
-
-## Recommendations
-1. [priority action]
-2. [secondary action]
-
-## Conclusion
-[Final review assessment with next steps]
-```
-
-## Approval Criteria
-
-**APPROVED**: All RFs implemented, tests passing, code conforms to rules and TechSpec, no security issues.
-
-**APPROVED WITH CAVEATS**: RFs implemented, tests passing, but there are recommended non-blocking improvements (MINOR issues).
-
-**REJECTED**: Tests failing, RFs not implemented, serious rules violations, security issues, or CRITICAL issues.
-
-## Next Steps by Status
-
-<critical>The suggested next step MUST match the review status. NEVER suggest /dw-fix-qa after code-review — that command is exclusively for bugs found by /dw-run-qa.</critical>
-
-- **APPROVED**: Suggest `/dw-commit` followed by `/dw-generate-pr`
-- **APPROVED WITH CAVEATS**: List the caveats. Suggest fixing the caveats, re-running build + lint with --fix, then re-running `/dw-code-review`
-- **REJECTED**: List the findings that caused rejection. The correct flow is:
-  1. Fix the findings listed in the report
-  2. Run build and lint with `--fix` until they pass
-  3. Re-run `/dw-code-review`
-  4. Repeat until APPROVED
-  - Do NOT suggest `/dw-fix-qa` (that is for visual QA bugs)
-  - Do NOT suggest `/dw-run-qa` before resolving code-review findings
-
-**Approval Decision Flow:**
-```dot
-digraph approval {
-  "Tests pass?" -> "Rules violations?" [label="yes"];
-  "Tests pass?" -> "REJECTED" [label="no"];
-  "Rules violations?" -> "Critical violations?" [label="yes"];
-  "Rules violations?" -> "APPROVED" [label="no"];
-  "Critical violations?" -> "REJECTED" [label="yes"];
-  "Critical violations?" -> "APPROVED WITH CAVEATS" [label="no"];
-}
-```
-
-## Quality Checklist
-
-- [ ] PRD read and RFs extracted
-- [ ] TechSpec analyzed
-- [ ] Tasks verified
-- [ ] Project rules reviewed
-- [ ] Git diff analyzed
-- [ ] PRD compliance verified (Level 2)
-- [ ] Rules conformance verified
-- [ ] Code quality analyzed
-- [ ] Tests executed and passing
-- [ ] Report `code-review.md` generated
-- [ ] Final status defined
-
-## Important Notes
-
-- Always read the complete code of modified files, not just the diff
-- Check if there are files that should have been modified but were not
-- Consider the impact of changes on other parts of the system
-- Be constructive in criticism, always suggesting alternatives
-- For multi-project setups, verify integration contracts between projects
-
-<critical>THE REVIEW IS NOT COMPLETE UNTIL ALL TESTS PASS</critical>
-<critical>ALWAYS check the project rules before flagging issues</critical>
-<critical>Generate the report at {{PRD_PATH}}/dw-code-review.md</critical>
-</system_instructions>