diff --git a/.gitignore b/.gitignore
index f5faf15aa..95c2bb928 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,4 +6,5 @@ __pycache__/
 *.pyc
 *.pyo
 *.pyd
-
+evals/**/results/
+evals/**/outputs/
diff --git a/CHANGELOG.md b/CHANGELOG.md
index ca421f766..62c5f303e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -5,6 +5,37 @@ All notable changes to the sdlc-workflow plugin are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Added
+
+- `performance-setup` skill for configuration and optimization target scaffolding
+- `performance-baseline` skill for workflow discovery, browser-based metric capture, and baseline reporting
+- `performance-analyze-module` skill for source-level anti-pattern detection (bundle, API, component, resource, backend)
+- `performance-plan-optimization` skill for optimization planning with Jira Epic/Task generation
+- `performance-implement-optimization` and `performance-verify-optimization` skills
+- Backend anti-pattern detection: N+1 queries, missing pagination/caching, inefficient queries, cross-repo over-fetching
+- Deep service chain analysis, wasted computation detection, and missing index detection
+- Migration SQL analysis (Steps 7.8.1–7.8.4): missing ANALYZE, non-materialized CTEs, uniform processing, expensive PL/pgSQL patterns
+- Migration SQL optimization handling (Step 5.6) for patching existing migration files
+- Scale-oriented detection steps (staleTime, spread-in-reduce, zero-result, redundant index, recursive CTE)
+- `db-migration` and `migration-sql-optimization` task types with Jira label support
+- DOM Interactive metric and config path normalization
+- Shared templates: baseline capture script, analysis report, optimization task, common patterns
+- Eval infrastructure for performance skills with mock fixtures
+- Performance workflow documentation and conventions
+
+### Changed
+
+- Unified workflow-first setup: merged workflow discovery into setup, single workflow selection
+- Migrated performance config from Markdown to JSON
+- Consolidated and refactored optimization skills
+- Full self-verification for performance tasks with N+1/pre-fetch detection
+
+### Fixed
+
+- Resolved 42 cross-skill inconsistencies, phantom tools, and broken flows
+
 ## [0.11.0] - 2026-06-19
 
 ### Added
diff --git a/CONVENTIONS.md b/CONVENTIONS.md
index d28ec4f22..6ffef61e2 100644
--- a/CONVENTIONS.md
+++ b/CONVENTIONS.md
@@ -127,3 +127,25 @@ Not applicable — this is a documentation repository with no runtime code.
 - **Version synchronization**: The plugin version must be kept in sync between:
   - `.claude-plugin/marketplace.json` (required for update detection)
   - `plugins/sdlc-workflow/.claude-plugin/plugin.json` (required by CI validation)
+
+## Performance Optimization
+
+- **Documentation style**: Quick reference format — tables, bullet points, minimal prose
+  - Core principles: Scannable, concise, actionable
+  - Avoid: Long paragraphs, verbose examples, extensive troubleshooting prose
+  - Prefer: Tables for structured data, bullet lists for procedures, diagrams for workflows
+- **Commit message type**: Use `perf(scope): description` for performance optimization features
+  - Example: `feat(performance): add baseline capture skill with test data verification`
+- **Skill distinctions**: Make explicit which skills inspect source code vs read reports
+  - Skills that inspect code: `performance-analyze-module` (analyzes source code for anti-patterns)
+  - Skills that read reports: `performance-plan-optimization` (reads analysis reports), `verify-pr` in perf mode (reads implementation results)
+  - Document this distinction in skill descriptions and documentation
+- **Metrics conventions**:
+  - Default aggregation: p95 (95th percentile) across 20 iterations (configurable via `baseline_settings.iterations`)
+  - Core Web Vitals: LCP (2500ms), FCP (1800ms), TTI (3500ms), Total Load Time (4000ms)
+  - Regression threshold: 5% degradation in non-target scenarios
+- **Baseline capture**:
+  - Tool: Playwright for browser automation
+  - Security: Validate user input, use timeouts, graceful degradation
+  - Configuration: Store in `performance-config.json` in target repository
+- **Anti-pattern detection**: 9 standard patterns (over-fetching, N+1 queries, waterfall loading, render-blocking, unused code, expensive re-renders, long tasks, layout thrashing, missing lazy loading)
diff --git a/README.md b/README.md
index 5e118fa51..db694252a 100644
--- a/README.md
+++ b/README.md
@@ -26,10 +26,10 @@ implementing tasks, and verifying pull requests:
 
 - **implement-task** — Implement a Jira task by reading its structured
   description, modifying code, running tests, committing, opening a PR, and
-  updating Jira.
+  updating Jira. (includes performance optimization support)
 
 - **verify-pr** — Verify a PR against its Jira task's acceptance criteria and
-  deterministic guardrails.
+  deterministic guardrails. (includes performance optimization support)
 
 - **report-bug** — Interactively define a Jira Bug by walking through
   project-configured template sections, or accept structured input
@@ -45,6 +45,20 @@ implementing tasks, and verifying pull requests:
 
 - **run-evals** — Run structured eval suites against skills to measure output
   quality and catch regressions.
+- **performance-setup** — Initialize performance optimization workflow
+  configuration for a target repository (workflow discovery, baseline capture
+  settings, target directories).
+
+- **performance-baseline** — Capture performance baseline metrics for selected
+  workflow scenarios using automated browser testing.
+
+- **performance-analyze-module** — Analyze a workflow module for performance
+  anti-patterns (over-fetching, N+1 queries, waterfall loading, render-blocking
+  resources, etc.) and generate an analysis report.
+
+- **performance-plan-optimization** — Generate structured optimization plan from
+  analysis reports, creating Jira Epic and Tasks for optimization work.
+
 
 ## Installation
 
diff --git a/docs/performance-metrics-guide.md b/docs/performance-metrics-guide.md
new file mode 100644
index 000000000..36ae37b5e
--- /dev/null
+++ b/docs/performance-metrics-guide.md
@@ -0,0 +1,218 @@
+# Performance Metrics Guide
+
+Quick reference for performance metrics, thresholds, and severity classification.
+
+---
+
+## Core Web Vitals
+
+| Metric | Definition | Good | Needs Improvement | Poor | Default Target |
+|---|---|---|---|---|---|
+| **LCP** (Largest Contentful Paint) | Time until largest content visible | ≤ 2.5s | 2.5 - 4.0s | > 4.0s | 2500 ms |
+| **FCP** (First Contentful Paint) | Time until any content visible | ≤ 1.8s | 1.8 - 3.0s | > 3.0s | 1800 ms |
+| **DOM Interactive** (Time to Interactive) | Time until page fully interactive | ≤ 3.8s | 3.8 - 7.3s | > 7.3s | 3500 ms |
+| **Total Load Time** | Time until all resources loaded | ≤ 4.0s | 4.0 - 7.0s | > 7.0s | 4000 ms |
+
+**Thresholds:** p75 for Web Vitals standard, p95 for internal targets (default in skills)
+
+---
+
+## Industry Benchmarks by Application Type
+
+| Application Type | LCP Target | FCP Target | DOM Interactive Target |
+|---|---|---|---|
+| Simple dashboard | 2000 ms | 1200 ms | 2500 ms |
+| Data-heavy admin | 2500 ms | 1800 ms | 3500 ms |
+| Public-facing SPA | 1500 ms | 1000 ms | 2000 ms |
+| E-commerce site | 1800 ms | 1200 ms | 2500 ms |
+
+---
+
+## Anti-Pattern Severity Thresholds
+
+### Over-Fetching
+
+| Severity | Unused Fields % | Payload Increase | Impact |
+|---|---|---|---|
+| High | > 70% | > 100 KB | > 300 ms |
+| Medium | 40-70% | 30-100 KB | 100-300 ms |
+| Low | < 40% | < 30 KB | < 100 ms |
+
+**Detection:** Compare API response fields with frontend code usage
+
+---
+
+### N+1 Queries
+
+| Severity | Sequential Calls | Time Impact |
+|---|---|---|
+| High | > 10 | > 1000 ms |
+| Medium | 5-10 | 300-1000 ms |
+| Low | 2-4 | < 300 ms |
+
+**Impact formula:** `Sequential time = N × avg latency`, `Parallel time = 1 × avg latency`
+
+---
+
+### Waterfall Loading
+
+| Severity | Sequential Depth | Time Impact |
+|---|---|---|
+| High | > 5 levels | > 800 ms |
+| Medium | 3-5 levels | 300-800 ms |
+| Low | 2 levels | < 300 ms |
+
+**Detection:** Count sequential dependency chains in resource timing
+
+---
+
+### Render-Blocking Resources
+
+| Severity | Blocking Resources | LCP Impact |
+|---|---|---|
+| High | > 3 | > 500 ms |
+| Medium | 2-3 | 200-500 ms |
+| Low | 1 | < 200 ms |
+
+**Detection:** `<script>` without `async`/`defer` or `<link rel="stylesheet">` without `media`/`preload`
+
+---
+
+### Unused Code
+
+| Severity | Unused Code % | Bundle Size Impact |
+|---|---|---|
+| High | > 30% | > 100 KB |
+| Medium | 15-30% | 50-100 KB |
+| Low | < 15% | < 50 KB |
+
+**Impact formula:** `Parse time ≈ bundle KB × 3ms/KB`
+
+---
+
+### Expensive Re-Renders
+
+| Severity | Re-Render Count | Time Impact |
+|---|---|---|
+| High | > 20 | > 300 ms |
+| Medium | 10-20 | 100-300 ms |
+| Low | 5-10 | < 100 ms |
+
+**Impact formula:** `Wasted time = render time × unnecessary re-renders`
+
+---
+
+### Long Tasks
+
+| Severity | Task Duration | Occurrence |
+|---|---|---|
+| High | > 250 ms | Multiple |
+| Medium | 100-250 ms | Multiple |
+| Low | 50-100 ms | Few |
+
+**Threshold:** Tasks > 50ms block user interaction
+
+**Impact formula:** `DOM Interactive delay = sum(task durations > 50ms)`
+
+---
+
+### Layout Thrashing
+
+| Severity | Forced Reflows | Time Impact |
+|---|---|---|
+| High | > 20 | > 200 ms |
+| Medium | 10-20 | 80-200 ms |
+| Low | 5-10 | < 80 ms |
+
+**Detection:** Read-write-read pattern (e.g., `offsetHeight` → `style.height = X`)
+
+**Impact formula:** `Reflow time ≈ 10ms × reflow count`
+
+---
+
+### Missing Lazy Loading
+
+| Severity | Component Size | LCP Impact |
+|---|---|---|
+| High | > 150 KB | > 600 ms |
+| Medium | 80-150 KB | 300-600 ms |
+| Low | 40-80 KB | < 300 ms |
+
+**Detection:** Large components in main bundle used below-the-fold
+
+---
+
+## Resource Timing
+
+| Resource Type | Typical Size | Optimization |
+|---|---|---|
+| Scripts (`.js`) | 10-500 KB | Code splitting, tree shaking, minification |
+| Stylesheets (`.css`) | 5-100 KB | Critical CSS inlining, unused CSS removal |
+| Images (`.png`, `.jpg`) | 10-500 KB | Compression, WebP format, lazy loading |
+| API calls (JSON) | 1-100 KB | Reduce payload, caching, batching |
+
+**Good compression ratio:** > 70% for text resources (HTML, CSS, JS, JSON)
+
+---
+
+## Metrics Aggregation
+
+| Percentile | Use Case |
+|---|---|
+| **p50** (median) | Quick sanity checks, typical user experience |
+| **p75** | Google Web Vitals standard, public monitoring |
+| **p95** (default) | Internal targets, regression detection, worst-case typical |
+| **p99** | Identifying outliers, debugging edge cases |
+
+**Default in skills:** p95 across 5 iterations
+
+---
+
+## Regression Threshold
+
+**5% degradation** in non-target scenarios triggers investigation
+
+**Example:**
+```
+Optimization target: SBOM List
+Non-target: Home Dashboard baseline 2000ms
+
+After optimization:
+- 2120ms (6% regression) → ⚠️ Flagged
+- 2090ms (4.5% regression) → ✅ Acceptable drift
+```
+
+---
+
+## Optimization Impact Formulas
+
+| Optimization | Impact Formula |
+|---|---|
+| Over-fetching | `KB saved / bandwidth × 1000 = ms saved` |
+| N+1 queries | `(N - 1) × avg latency = ms saved` |
+| Waterfall loading | `Sequential time - max(parallel) = ms saved` |
+| Render-blocking | `Resource load time = ms saved` |
+| Unused code | `KB removed × 3ms/KB = parse time saved` |
+| Long tasks | `sum(task > 50ms) = DOM Interactive delay reduced` |
+| Layout thrashing | `reflow count × 10ms = ms saved` |
+| Lazy loading | `Component KB × 3ms/KB = LCP improvement` |
+
+---
+
+## Navigation Timing Metrics
+
+| Metric | Typical Range | Optimization |
+|---|---|---|
+| DNS Lookup | 20-120 ms | DNS prefetching, fast DNS provider |
+| TCP Connection | 50-200 ms | HTTP/2, connection keep-alive, CDN |
+| TLS Handshake | 50-300 ms | TLS 1.3, session resumption |
+| TTFB (Time to First Byte) | 100-600 ms | CDN, server caching, query optimization |
+| DOM Processing | 100-500 ms | Minimize DOM size, avoid deep nesting |
+
+---
+
+## See Also
+
+- [Performance Workflow Guide](performance-workflow-guide.md) - End-to-end workflow
+- [Performance Skills Reference](performance-skills-reference.md) - Skill documentation
+- [Workflow Documentation](workflow.md) - Full skill catalog
diff --git a/docs/performance-skills-reference.md b/docs/performance-skills-reference.md
new file mode 100644
index 000000000..05f44f599
--- /dev/null
+++ b/docs/performance-skills-reference.md
@@ -0,0 +1,222 @@
+# Performance Skills Reference
+
+Quick reference for all performance optimization skills.
+
+---
+
+## Overview
+
+| # | Skill | Purpose | Key Action |
+|---|---|---|---|
+| 1 | performance-setup | Initialize infrastructure (dirs, settings, backend) | Creates minimal `performance-config.json` (no workflow) |
+| 2 | performance-baseline | **Discover workflows**, select workflow, capture metrics | Workflow selection + Playwright automation → `baseline-report.md` + config update |
+| 3 | performance-analyze-module | Detect anti-patterns | **Inspects source code** → `workflow-analysis-report.md` |
+| 4 | performance-plan-optimization | Create Jira tasks | **Reads analysis report** → Jira Epic/Tasks |
+| 5 | implement-task (perf mode) | Execute optimization | Implements + validates → PR |
+| 6 | verify-pr (perf mode) | Verify PR | Review feedback + validation → report |
+
+---
+
+## performance-setup
+
+**Invocation:** `/sdlc-workflow:performance-setup [path]`
+
+**One-time infrastructure setup. Does NOT select workflow (that happens in baseline).**
+
+| Input | Output |
+|---|---|
+| Target repository path (optional) | Minimal `performance-config.json` (no workflow selected) |
+| User responses (backend config, baseline settings, targets) | Target directories created |
+
+**What it does:**
+1. Determines target frontend repository
+2. **Discovers and configures backend repository** (upfront)
+3. Detects existing configuration (offers update or skip)
+4. Creates directories: `baselines/`, `analysis/`, `plans/`, `verification/`
+5. Collects baseline capture settings (iterations, warmup runs)
+6. Collects optimization targets
+7. Generates minimal config with:
+   - Backend configured
+   - Settings configured
+   - Empty Performance Scenarios (populated by baseline)
+   - Empty Module Registry (populated by baseline)
+   - Empty Selected Workflow (populated by baseline)
+   - `workflow_selected: false`
+
+**Default targets:** LCP 2500ms, FCP 1800ms, DOM Interactive 3500ms, Total Load 4000ms
+
+**Next step:** Run `/sdlc-workflow:performance-baseline` to discover workflows and capture metrics
+
+---
+
+## performance-baseline
+
+**Invocation:** `/sdlc-workflow:performance-baseline [path]`
+
+**Discover workflows, select target workflow, and capture performance metrics.**
+
+| Input | Output |
+|---|---|
+| Target repository path (optional) | `baseline-report.md` + config updated with selected workflow |
+| User responses: workflow selection, mode selection, test data confirmation | Metrics: LCP, FCP, DOM Interactive, Total Load Time |
+
+**Prerequisites:**
+- Application running locally
+- Playwright installed: `npm install -D @playwright/test && npx playwright install`
+
+**What it does:**
+
+**IF workflow not yet selected (first run):**
+1. **Discovers routes from router configuration**
+2. **Infers workflows by grouping related routes**
+3. **Prompts user to select ONE workflow**
+4. **Auto-populates scenarios from workflow's key screens**
+5. **Discovers modules (lazy-loaded components)**
+6. **Updates config** with selected workflow, scenarios, modules
+7. Sets `workflow_selected: true`
+
+**Always (whether workflow just selected or already selected):**
+8. Verifies test data availability
+9. Checks for existing baseline (prompts to replace or cancel)
+10. Executes baseline capture using **cold-start mode** (Playwright automation with direct URL navigation, cold cache)
+11. Generates baseline report with p95 metrics
+12. Updates config with baseline metadata
+
+**Key metrics captured:**
+- LCP (Largest Contentful Paint)
+- FCP (First Contentful Paint)
+- DOM Interactive (Time to Interactive)
+- Total Load Time
+- Resource breakdown (scripts, CSS, images, API calls)
+
+---
+
+## performance-analyze-module
+
+**Invocation:** `/sdlc-workflow:performance-analyze-module [path]`
+
+**Inspect source code to detect performance anti-patterns.**
+
+| Input | Output |
+|---|---|
+| Target repository path (optional) | `workflow-analysis-report.md` |
+| Baseline data | `findings-validation.json`, `query-ledger.json`, `analysis-progress.json` |
+
+**Key distinction:** This skill **inspects source code**. The next skill (plan-optimization) **reads this report**.
+
+**Artifacts:**
+- `workflow-analysis-report.md` — full analysis report with validated findings
+- `findings-validation.json` — all findings with disposition (confirmed/discarded) for audit trail
+- `query-ledger.json` — structured backend query inventory (consumed by live SQL analysis)
+- `analysis-progress.json` — step completion tracker; Step 9.0 gates on all steps being `done`/`skipped`/`not_applicable`
+
+**What it does:**
+1. Reads baseline data
+2. **Analyzes source code** (components, API calls, resources)
+3. Detects 9 anti-patterns (see table below)
+4. Classifies severity (High/Medium/Low)
+5. Estimates impact (time or KB savings)
+6. Locates code instances (file paths, line numbers)
+7. Generates recommendations
+
+**Anti-patterns detected:**
+
+| Anti-Pattern | What It Detects |
+|---|---|
+| Over-fetching | API responses with unused fields |
+| N+1 queries | Sequential API calls in loops |
+| Waterfall loading | Sequential resource dependencies |
+| Render-blocking resources | Synchronous scripts/styles in critical path |
+| Unused code | Dead code, unreachable branches |
+| Expensive re-renders | Missing React.memo, useMemo, useCallback |
+| Long tasks | Main thread blocking > 50ms |
+| Layout thrashing | Forced reflows in loops |
+| Missing lazy loading | Large components loaded eagerly |
+
+---
+
+## performance-plan-optimization
+
+**Invocation:** `/sdlc-workflow:performance-plan-optimization [path]`
+
+**Read analysis report and create Jira Epic + Tasks.**
+
+| Input | Output |
+|---|---|
+| Target repository path (optional) | Jira Epic + Tasks |
+| Analysis report | `optimization-plan.md` |
+
+**Key distinction:** This skill **reads the analysis report**. It does NOT inspect source code.
+
+**What it does:**
+1. **Reads** `workflow-analysis-report.md`
+2. Groups optimizations by category (bundle size, API, render, resource, long task)
+3. Calculates effort estimates
+4. Creates Jira Epic: "Performance Optimization: {workflow}"
+5. Creates Jira Tasks (one per category)
+6. Links tasks with dependencies
+7. Generates `optimization-plan.md`
+
+**Task categories:**
+
+| Category | Optimizations Included |
+|---|---|
+| Bundle Size Reduction | Code splitting, tree shaking, lazy loading, dead code removal |
+| API Optimization | Reduce over-fetching, eliminate N+1 queries, parallel fetching |
+| Render Optimization | Memoization, virtual scrolling, layout thrashing fixes |
+| Resource Optimization | Async/defer scripts, parallel loading, compression |
+| Long Task Mitigation | Code splitting, web workers, async patterns |
+
+---
+
+## implement-task (perf mode)
+
+Performance optimization behavior is **auto-detected** when the Jira task contains Baseline Metrics and Target Metrics sections (created by `performance-plan-optimization`). No separate skill invocation is needed — use `/sdlc-workflow:implement-task TC-XXXX` as usual.
+
+See [Workflow Documentation — Optimization Implementation](workflow.md#optimization-implementation) for the full workflow.
+
+---
+
+## verify-pr (perf mode)
+
+Performance verification behavior is **auto-detected** when the Jira task contains Baseline Metrics and Target Metrics sections. No separate skill invocation is needed — use `/sdlc-workflow:verify-pr TC-XXXX` as usual.
+
+See [Workflow Documentation — Optimization Verification](workflow.md#optimization-verification) for the full workflow.
+
+---
+
+## Skill Dependencies
+
+```
+setup (infrastructure) → baseline (workflow discovery) → analyze-module → plan-optimization → implement-task (perf) → verify-pr (perf)
+         ↓                           ↓                          ↓                  ↓                       ↓                      ↓
+  minimal config          config updated with workflow     analysis        Jira Epic/Tasks            PR with         Verification
+  (no workflow)           + baseline report                 report                                    metrics          report
+```
+
+---
+
+## Config Field Ownership
+
+Which config sections each consumer reads and for what purpose.
+
+| Config Section | Read By | Purpose |
+|---|---|---|
+| `scenarios`, `baseline_settings` | `capture-baseline.mjs` | Measurement loop (iterations, warmup, scenario URLs) |
+| `optimization_targets` | Skills + report comparison | Target thresholds (seconds for frontend, ms for backend) |
+| `analysis_assumptions` | `analyze-module` / `plan-optimization` skills only | **Not applied at capture time** — used for static cost estimates |
+| `metadata.capture_*` | Skills (CLI construction) | **Not read by capture script** — skills use these to construct CLI args |
+| `dev_environment` | `performance-baseline` skill | Dev server startup; not read by capture script |
+| `workflow`, `modules` | `performance-baseline`, `analyze-module` skills | Workflow selection and code analysis scope |
+| `directories` | All performance skills | Output path resolution |
+| `repositories` | `performance-setup`, `analyze-module` skills | Repository detection and code analysis |
+
+**Unit convention:** `capture-baseline.mjs` emits all timing values in **milliseconds** (from browser `performance` APIs). The `optimization_targets.frontend.*` section stores targets in **seconds**. Skills are responsible for converting ms→s when writing captured p95 values to `optimization_targets.frontend.*.baseline` and `.latest`.
+
+---
+
+## See Also
+
+- [Performance Workflow Guide](performance-workflow-guide.md) - End-to-end workflow
+- [Performance Metrics Guide](performance-metrics-guide.md) - Metric definitions
+- [Workflow Documentation](workflow.md) - Full skill catalog
diff --git a/docs/performance-workflow-guide.md b/docs/performance-workflow-guide.md
new file mode 100644
index 000000000..414ed9d96
--- /dev/null
+++ b/docs/performance-workflow-guide.md
@@ -0,0 +1,218 @@
+# Performance Optimization Workflow Guide
+
+Quick reference for using the performance optimization workflow in sdlc-workflow plugin.
+
+---
+
+## Overview
+
+**Purpose:** Measure, analyze, and improve cold-start page load and API endpoint performance across full-stack applications using automated metrics collection, anti-pattern detection, and Jira-integrated planning.
+
+**When to use:**
+- ✅ Feature is functionally complete but has performance issues
+- ✅ Establishing performance baseline before changes
+- ✅ Identifying bottlenecks in a user journey
+- ✅ Preparing for release (validate targets)
+
+**When NOT to use:**
+- ❌ Building new features from scratch → use `plan-feature`
+- ❌ Fixing non-performance bugs → use `implement-task`
+
+---
+
+## Prerequisites
+
+| Requirement | Details |
+|---|---|
+| Playwright installed | `npm install -D @playwright/test && npx playwright install` |
+| Application running | Localhost (e.g., `http://localhost:3000`) |
+| Test data loaded | Representative data for accurate measurements |
+| Stable environment | Close unnecessary apps, disable browser extensions |
+
+---
+
+## Workflow Steps
+
+```
+setup (infrastructure only) → baseline (workflow discovery + metrics) → analyze → plan → implement → verify
+```
+
+| Step | Skill | Purpose | Output |
+|---|---|---|---|
+| 1 | `performance-setup` | Initialize infrastructure (dirs, settings, backend config) | Minimal `performance-config.json` (no workflow) |
+| 2 | `performance-baseline` | **Discover workflows**, **select workflow**, **select mode**, capture metrics | `baseline-report.md` with Core Web Vitals, config updated with workflow |
+| 3 | `performance-analyze-module` | **Inspect source code** to detect anti-patterns | `workflow-analysis-report.md` with findings |
+| 4 | `performance-plan-optimization` | **Read analysis report** and create Jira tasks | Jira Epic + Tasks, `optimization-plan.md` |
+| 5 | `implement-task` (perf mode) | Execute optimization with validation | PR with before/after metrics |
+| 6 | `verify-pr` (perf mode) | Verify PR and detect regressions | Verification report (PASS/WARN/FAIL) |
+
+**Key distinction:** Step 4 analyzes code, Step 5 reads the report.
+
+---
+
+## Workflow Diagram
+
+```mermaid
+graph TD
+    A[performance-setup<br/>Infrastructure only] --> B[performance-baseline<br/>Discover + select workflow]
+    B --> C[performance-analyze-module<br/>Source code inspection]
+    C --> D[performance-plan-optimization<br/>Read report, create tasks]
+    D --> E[implement-task<br/>perf mode]
+    E --> F{Targets<br/>met?}
+    F -->|Regression| G[Stop - investigate]
+    F -->|Improvement| H[Create PR]
+    H --> I[verify-pr<br/>perf mode]
+    I --> J{Overall?}
+    J -->|PASS| K[Merge]
+    J -->|WARN/FAIL| E
+    K --> L{More<br/>tasks?}
+    L -->|Yes| E
+    L -->|No| M[Done]
+```
+
+---
+
+## Baseline Capture Mode
+
+All baseline captures use **cold-start** mode: direct URL navigation with an empty browser cache. This measures worst-case (first-visit) performance and provides a stable, reproducible baseline.
+
+> **Note:** e2e and both modes are not implemented. Only cold-start is supported.
+
+---
+
+## Quick Example
+
+```bash
+# 1. Setup infrastructure (one-time)
+/sdlc-workflow:performance-setup
+# Creates directories, configures settings and backend
+
+# 2. Start app and discover workflows + capture baseline
+npm start  # Start app first
+/sdlc-workflow:performance-baseline
+# Discovers workflows → User selects "Product Catalog Browse"
+# Output: LCP 3200ms (target 2500ms) ⚠️
+
+# 3. Analyze source code
+/sdlc-workflow:performance-analyze-module
+# Output: 3 anti-patterns detected, 900ms improvement estimated
+
+# 4. Create Jira tasks
+/sdlc-workflow:performance-plan-optimization
+# Output: Epic TC-5001, Tasks TC-5002, TC-5003, TC-5004
+
+# 5. Implement optimization (performance sections auto-detected from Jira task)
+/sdlc-workflow:implement-task TC-5002
+# Output: PR created, optimization report saved, LCP improved 3200ms → 2900ms
+
+# 6. Verify PR (performance sections auto-detected from Jira task)
+/sdlc-workflow:verify-pr TC-5002
+# Output: PASS (Partial Success - continue with remaining tasks)
+
+# 7. After PR merge to main, update config with fresh baseline
+git checkout main && git pull
+/sdlc-workflow:performance-baseline
+# Output: Config "Latest Verified" column updated with current main metrics
+
+# 8. Repeat steps 5-7 for TC-5003, TC-5004 until targets met
+```
+
+---
+
+## Optimization Result Reports
+
+Each optimization task creates an isolated report file for audit trail and parallel-safe development:
+
+**Location:** `performance/optimization-results/{jira-key}-{timestamp}.md`
+
+**Contents:**
+- Performance impact table (baseline → after optimization → delta)
+- Test scenarios measured
+- Code changes (commit, PR, files modified)
+- Validation checks performed
+- Verification results (added by verify-pr in perf mode)
+
+**Status lifecycle:**
+1. `pending_verification` — created by implement-task in perf mode
+2. `verified` — updated by verify-pr in perf mode if PASS
+3. `verified_with_warnings` — if WARN (partial success)
+
+**Benefits:**
+- ✅ **Parallel-safe:** Multiple developers can optimize different tasks simultaneously without conflicts
+- ✅ **Audit trail:** Full history of every optimization attempt preserved
+- ✅ **Traceability:** Each report links to task → PR → commit → metrics
+
+**Config update flow:**
+- Optimization reports track per-task results (isolated, parallel-safe)
+- Config "Latest Verified" column tracks main branch state (updated by re-running baseline after merge)
+- This separation eliminates race conditions while preserving full history
+
+---
+
+## Anti-Patterns Detected (Step 3)
+
+| Anti-Pattern | Detection |
+|---|---|
+| Over-fetching | API responses with unused fields |
+| N+1 queries | Sequential API calls in loops |
+| Waterfall loading | Sequential resource dependencies |
+| Render-blocking | Synchronous scripts/styles in `<head>` |
+| Unused code | Dead code, unreachable branches |
+| Expensive re-renders | Missing React.memo, useMemo |
+| Long tasks | Main thread blocking > 50ms |
+| Layout thrashing | Forced reflows in loops |
+| Missing lazy loading | Large components loaded eagerly |
+
+---
+
+## Common Issues
+
+| Issue | Solution |
+|---|---|
+| "ECONNREFUSED" during baseline | Start application: `npm start` |
+| "Cannot find module @playwright/test" | Install: `npm install -D @playwright/test && npx playwright install` |
+| Metrics vary >10% between runs | Close background apps, clear cache, use consistent test data |
+| "Performance regression detected" | Review implementation, check for unintended side effects |
+| "Atlassian MCP failed" | Choose "Use REST API" when prompted, or skip Jira operations |
+
+---
+
+## Best Practices
+
+**Re-baseline when:**
+- Before starting optimization (establish baseline)
+- **After each optimization PR merge** (update "Latest Verified" metrics on main)
+- After major features (validate no regressions)
+- After library upgrades (detect version-related slowdowns)
+- Before releases (ensure targets met)
+
+**Post-merge workflow:**
+1. Merge optimization PR to main
+2. Checkout main and pull latest
+3. Re-run `/sdlc-workflow:performance-baseline` (skips workflow discovery, just re-measures)
+4. Config "Latest Verified" column updated with fresh main metrics
+5. Continue with next optimization task
+
+**Prioritization:**
+- Quick wins first (low effort, high impact)
+- Dependencies (tasks that unblock others)
+- Low-risk before high-risk
+
+**Target setting:**
+- Use industry benchmarks (see [Performance Metrics Guide](performance-metrics-guide.md))
+- Set intermediate targets if baseline is far from benchmark
+- Adjust for application complexity and user expectations
+
+**Iteration pattern:**
+- **Incremental:** One task → verify → merge → repeat (lower risk)
+- **Batched:** Multiple tasks → verify → merge (fewer PRs)
+
+**Regression threshold:** 5% degradation in non-target scenarios triggers investigation
+
+---
+
+## See Also
+
+- [Performance Skills Reference](performance-skills-reference.md) - Detailed skill documentation
+- [Performance Metrics Guide](performance-metrics-guide.md) - Metric definitions and thresholds
+- [Workflow Documentation](workflow.md) - Full workflow catalog
diff --git a/docs/project-config-contract.md b/docs/project-config-contract.md
index 0db92ff14..91da74bd3 100644
--- a/docs/project-config-contract.md
+++ b/docs/project-config-contract.md
@@ -342,6 +342,109 @@ sections are absent — they adapt gracefully.
 
 ---
 
+## Optional Section: Performance Analysis Configuration
+
+Performance optimization skills use a separate configuration file in the
+**target repository** (not in the sdlc-plugins project). This file is
+created by the `performance-setup` skill (minimal scaffold) and populated by
+the `performance-baseline` skill (workflow selection). It lives at
+`performance-config.json` in the target repository.
+
+### Location
+
+**Target repository root**: `performance-config.json`
+
+**Created by**: `/sdlc-workflow:performance-setup` (minimal scaffold)  
+**Populated by**: `/sdlc-workflow:performance-baseline` (workflow selection)
+
+### Schema
+
+The Performance Analysis Configuration file contains:
+
+1. **Metadata** — Config version, workflow selection status, baseline capture status
+2. **Selected Workflow** — The user-selected workflow to optimize (added by `performance-baseline`)
+3. **Workflow Scenarios** — List of scenarios (routes) in the selected workflow (added by `performance-baseline`)
+4. **Module Registry** — Lazy-loaded routes and code-split chunks (added by `performance-baseline`)
+5. **Backend Repository Configuration** — Backend repo configuration (added by `performance-setup`)
+6. **Baseline Settings** — Configuration for performance baseline capture (added by `performance-setup`)
+7. **Target Directories** — Where to save baselines, analysis reports, optimization plans (created by `performance-setup`)
+8. **Optimization Targets** — Target metrics for LCP, FCP, DOM Interactive, Total Load Time (added by `performance-setup`)
+
+### Example Configuration
+
+```markdown
+# Performance Analysis Configuration
+
+## Selected Workflow
+
+**Workflow Name:** Home Dashboard  
+**Scenarios:**
+- Home page load (`http://localhost:3000/home`)
+- SBOM list (`http://localhost:3000/sboms`)
+
+---
+
+## Baseline Settings
+
+- **Browser:** Chromium (headless)
+- **Viewport:** 1920x1080
+- **Network:** Fast 3G throttling
+- **Iterations:** 5
+
+**Baseline Capture Mode** (set during baseline execution):
+- `cold-start` (only supported mode): Direct URL navigation with empty browser cache
+
+---
+
+## Target Directories
+
+- **Baselines:** `performance/baselines/`
+- **Analysis:** `performance/analysis/`
+- **Plans:** `performance/plans/`
+- **Verification:** `performance/verification/`
+
+---
+
+## Optimization Targets
+
+| Metric | Target (p95) |
+|---|---|
+| LCP | < 2500 ms |
+| FCP | < 1800 ms |
+| DOM Interactive | < 3500 ms |
+| Total Load Time | < 4000 ms |
+
+---
+
+## Module Registry
+
+**Lazy-loaded routes:**
+- `/home` → `src/components/Home.tsx`
+- `/sboms` → `src/components/SBOMList.tsx`
+
+**Code-split chunks:**
+- `vendors~home`
+- `vendors~sboms`
+```
+
+### How Skills Use It
+
+Performance skills read `performance-config.json` from the target
+repository to:
+
+- **performance-setup**: Creates minimal config with backend, settings, targets; does NOT discover workflows
+- **performance-baseline**: Discovers workflows (if not yet selected), saves user-selected workflow, scenarios, modules; captures baseline metrics
+- **performance-analyze-module**: Read selected workflow and baseline data
+- **performance-plan-optimization**: Read analysis reports and target metrics
+- **implement-task** (perf mode): Read baseline metrics and targets
+- **verify-pr** (perf mode): Read targets for validation
+
+**Note**: This configuration is **per-repository**, not per-project. Each
+repository that undergoes performance optimization has its own
+`performance-config.json` file.
+
+---
+
 ## Template
 
 The canonical template for the `# Project Configuration` section is
diff --git a/docs/templates/conventions.md b/docs/templates/conventions.md
index bbac3d63c..f050c1dee 100644
--- a/docs/templates/conventions.md
+++ b/docs/templates/conventions.md
@@ -69,3 +69,22 @@
      - Prefer standard library over external crates when reasonable
      - All new npm packages require team review
      - Pin exact versions in Cargo.toml -->
+
+## Performance Optimization
+
+<!-- TODO: Document when and how to run performance optimization workflow.
+     Example:
+     - Run `/sdlc-workflow:performance-setup` once per repository to initialize configuration
+     - Capture baseline before starting optimization work
+     - Re-capture baseline after major feature additions or library upgrades
+     - Target metrics for this repository:
+       * LCP (p95): < 2500 ms
+       * FCP (p95): < 1800 ms
+       * DOM Interactive (p95): < 3500 ms
+       * Bundle size: < 500 KB (main bundle)
+     - Anti-pattern severity thresholds:
+       * High: Impacts LCP by > 500ms or bundle size by > 100KB
+       * Medium: Impacts LCP by 200-500ms or bundle size by 50-100KB
+       * Low: Impacts LCP by < 200ms or bundle size by < 50KB
+     - Baseline capture frequency: weekly, before/after optimization, before release
+     - Performance budget enforcement: CI fails if LCP > 3000ms or bundle > 600KB -->
diff --git a/docs/tools.md b/docs/tools.md
index 448b97a61..dfe8e42dd 100644
--- a/docs/tools.md
+++ b/docs/tools.md
@@ -130,3 +130,46 @@ If no Serena instance is available for a repository, skills fall back to Read, G
 ### Limitations
 
 Check the **Code Intelligence** > **Limitations** section in your project's CLAUDE.md for per-instance limitations (e.g., language server features that are not supported).
+
+---
+
+## Playwright
+
+**Purpose:** Browser automation for performance baseline capture.
+
+**Installation:**
+
+```bash
+npm install -D @playwright/test
+npx playwright install
+```
+
+**Used By:** performance-baseline skill
+
+### How It Works
+
+The `performance-baseline` skill uses Playwright to:
+1. Launch a headless Chromium browser
+2. Navigate to each scenario in the selected workflow
+3. Measure Web Vitals (LCP, FCP, DOM Interactive) and total load time
+4. Capture resource timing (scripts, stylesheets, images)
+5. Generate a baseline report with metrics and waterfall visualization
+
+**Baseline Capture Mode:**
+
+Baseline capture uses **cold-start mode**: direct URL navigation with empty browser cache using Playwright. This measures worst-case (first-visit) performance and provides stable, reproducible baseline metrics.
+
+### Requirements
+
+- **Application running:** The target application must be running on localhost before capturing baseline
+- **Test data loaded:** Scenarios must have test data available for accurate measurements
+- **Valid URLs:** Scenario URLs must be valid localhost addresses (e.g., `http://localhost:3000/home`)
+
+### Graceful Degradation
+
+If Playwright is not installed or cannot run, the skill:
+1. Detects the missing dependency
+2. Provides installation instructions
+3. Offers to exit gracefully and resume after installation
+
+**Alternative:** Manual performance testing using browser DevTools and manual metric recording (skill does not support this flow, but users can capture baseline manually if needed).
diff --git a/docs/workflow.md b/docs/workflow.md
index 6666ab58b..254169b3b 100644
--- a/docs/workflow.md
+++ b/docs/workflow.md
@@ -448,6 +448,521 @@ flowchart TD
 - **Task dependencies** — all intermediate tasks depend on the create-branch task; the merge-branch task depends on all intermediate tasks.
 
 **Jira state transitions:** New → In Progress → Done (create-branch bookend) | New → In Progress → In Review (intermediate + merge-branch tasks) → Done (human merge)
+## Performance Optimization Workflow
+
+The performance optimization workflow is a specialized workflow for discovering, analyzing, and optimizing **cold-start page load and API endpoint performance** across full-stack applications (frontend + backend). It operates independently of the main SDLC workflow but follows a similar structured approach.
+
+### Analysis Capabilities
+
+**Supported Architecture Modes:**
+1. **Frontend-only** - Frontend analysis capabilities only
+2. **Backend-only** - Backend analysis capabilities only
+3. **Full-stack (separate repos)** - Frontend + Backend capabilities + cross-repository integration
+4. **Full-stack monorepo** - Frontend + Backend capabilities + cross-repository integration
+
+**Frontend Analysis Capabilities:**
+- Bundle composition analysis (third-party vs application code, code-splitting opportunities)
+- Component render optimization (missing memoization, expensive re-renders)
+- Resource loading patterns (waterfall loading, render-blocking resources)
+- Client-side anti-patterns (long tasks, layout thrashing, unused code)
+- API call patterns from frontend (N+1 queries, sequential vs parallel fetching)
+- Supported frameworks: React, Vue, Angular, Svelte, Next.js, Nuxt, SvelteKit
+- Supported bundlers: webpack, Vite, Rollup, esbuild, Parcel
+
+**Backend Analysis Capabilities:**
+- Database N+1 query detection (queries in loops)
+- Deep service chain analysis (recursive call graph tracing to detect hidden N+1, wasted computation, and anti-patterns below the handler layer)
+- Wasted computation detection (handlers fetching more data than they use)
+- Missing database index detection (WHERE/JOIN columns lacking indexes, cross-referenced against migration files)
+- Missing pagination on collection endpoints
+- Missing caching for expensive operations
+- Inefficient queries (SELECT *, unnecessary columns)
+- Unused table JOINs (joined tables with no field access)
+- Response schema extraction for over-fetching analysis
+- Supported frameworks: Rust (actix-web, axum, rocket), Java (Spring Boot), Python (FastAPI, Django, Flask), Node (Express, Fastify, Nest.js), Ruby (Rails), C# (ASP.NET Core)
+- Supported ORMs: sqlx, SeaORM, Diesel, JPA/Hibernate, SQLAlchemy, Django ORM, TypeORM, Prisma, Sequelize, ActiveRecord, Entity Framework
+
+**Full-Stack Analysis:**
+
+When both frontend and backend are configured, combines **Frontend Analysis Capabilities** + **Backend Analysis Capabilities** with additional cross-repository integration:
+- **Workflow-scoped backend measurement:** Backend baseline measures only the API endpoints that the selected frontend workflow calls, enabling direct correlation of frontend load time with specific backend API latency
+- **Comprehensive over-fetching detection:** Cross-reference backend response schemas with frontend field usage to identify unused fields
+- **N+1 impact multiplier:** Calculate combined impact of frontend N+1 patterns × backend query overhead
+- **End-to-end optimization planning:** Coordinate API response size reduction (backend) with API call pattern improvements (frontend)
+
+**Code Intelligence Strategy:**
+- **Serena MCP** (preferred): High-confidence semantic code analysis
+- **Grep fallback**: Medium-confidence pattern matching (used when Serena unavailable)
+- All findings document detection method and confidence level
+
+---
+
+### Performance Setup (One-time)
+
+**Skill:** `/sdlc-workflow:performance-setup`
+
+Initializes Performance Analysis infrastructure by creating directories, configuring backend repository, and setting baseline capture settings and optimization targets. **Does NOT select workflow** (workflow discovery happens in baseline skill).
+
+**Invocation:**
+
+```
+/sdlc-workflow:performance-setup
+/sdlc-workflow:performance-setup /path/to/target/repo
+```
+
+**Workflow:**
+
+**Step 0.5: Repository Architecture Selection (Interactive)**
+
+Prompts user to select repository architecture:
+1. Full-stack (separate repositories) - Frontend + backend in different repos
+2. Full-stack monorepo - Frontend + backend in same repo
+3. Frontend-only - No backend analysis
+4. Backend-only - No frontend analysis
+5. Not sure - Auto-detect based on repository patterns
+
+**Step 1: Detect Repository Patterns and Validate Choice**
+
+Based on selection, validates target repository contains expected patterns:
+
+**Step 1.2: Validate Architecture Choice (Branching Logic)**
+- **Full-stack/monorepo:** Verify BOTH frontend AND backend patterns exist
+- **Full-stack (separate repos):** Verify frontend in current repo, prompt for backend repo path, validate backend patterns
+- **Frontend-only:** Verify frontend patterns exist (skip if backend detected, offer to reconfigure as full-stack)
+- **Backend-only:** Verify backend patterns exist (skip if frontend detected, offer to reconfigure as full-stack)
+- **"Not sure":** Auto-detect and recommend architecture based on discovered patterns
+
+**Step 1.3: Backend Framework Configuration (Interactive Detection Flow)**
+
+Runs ONLY if backend detected or provided:
+1. **Framework detection:** Auto-detect from patterns (Rust: Cargo.toml, Java: pom.xml, Python: requirements.txt, etc.)
+2. **Framework confirmation:** Present detected framework to user for confirmation
+3. **API base path prompting:** Request API base URL/path for backend
+4. **Serena instance lookup:** Check CLAUDE.md Repository Registry for Serena MCP configuration
+5. **Registry fallback:** If Serena not in registry, set to "none" (Grep fallback mode)
+6. **User approval:** Confirm final backend configuration before saving
+
+**Main Flow:**
+
+1. Determine target repository (argument or current directory)
+2. Detect existing configuration (update or skip if exists)
+4. Create target directories (`performance/baselines/`, `/analysis/`, `/plans/`, `/optimization-results/`, `/verification/`)
+5. Collect baseline capture settings (iterations, warmup runs, metrics)
+6. Collect optimization targets (LCP, FCP, DOM Interactive, Total Load Time)
+7. Initialize metadata section with `workflow_selected: false`
+8. Generate minimal `performance-config.json` with:
+   - Backend configured
+   - Baseline settings configured
+   - Optimization targets configured
+   - **Empty** Performance Scenarios (will be populated by baseline)
+   - **Empty** Module Registry (will be populated by baseline)
+   - **Empty** Selected Workflow section (will be populated by baseline)
+9. Validate configuration and output summary
+
+**Output:**
+- Minimal `performance-config.json` created in target repository with:
+  - Backend Repository Configuration (configured upfront)
+  - Baseline Capture Settings (configured)
+  - Optimization Targets (configured)
+  - Performance Scenarios: empty (note: "populated by baseline")
+  - Module Registry: empty (note: "populated by baseline")
+  - Selected Workflow: empty (note: "run baseline to select")
+  - Metadata: `workflow_selected: false`
+- Target directories created:
+  - `performance/baselines/` - Baseline performance reports
+  - `performance/analysis/` - Module and application analysis reports
+  - `performance/plans/` - Optimization plan documents
+  - `performance/optimization-results/` - Individual optimization result reports
+  - `performance/verification/` - Verification reports for optimization PRs
+
+**Guardrails:**
+- Idempotent — running multiple times offers to update or skip
+- Does NOT modify source code — only creates configuration file
+- Does NOT select workflow — that happens in baseline skill
+- Backend configuration is interactive detection flow (Steps 1.2-1.3): pattern detection → framework confirmation → API base path prompting → Serena lookup → Registry fallback
+
+**Next step:** Run `/sdlc-workflow:performance-baseline` to discover workflows and capture metrics
+
+---
+
+### Baseline Capture
+
+**Skill:** `/sdlc-workflow:performance-baseline`
+
+**Discovers workflows from the codebase, prompts user to select a target workflow, auto-populates configuration, then captures performance baseline metrics** by executing browser automation to measure page load times and resource loading, and generating a baseline report.
+
+**Invocation:**
+
+```
+/sdlc-workflow:performance-baseline
+/sdlc-workflow:performance-baseline /path/to/target/repo
+```
+
+**Interactive Prompts:**
+- **Workflow selection** (first run only): User selects ONE workflow from discovered list
+- Test data availability confirmation
+- Capture mode: `cold-start` (direct URL navigation with cold cache) - only supported mode
+
+**Workflow:**
+
+**IF workflow not yet selected (first run, `workflow_selected: false`):**
+
+**Frontend Workflow Discovery:**
+1. **Discover routes from router configuration**
+2. **Infer workflows by grouping related routes** (path prefixes, list→detail patterns, navigation structure)
+3. **Auto-populate scenarios from workflow's key screens**
+4. **Discover modules for selected workflow pages**
+
+**Backend Workflow Discovery (Step 3):**
+- **Step 3.1 - Locate API route definitions** using framework-specific patterns:
+  - Rust: actix-web (`#[get("/api/...")]`), axum (`.route("/", get(handler))`), poem
+  - Java: Spring Boot (`@GetMapping`, `@PostMapping`, `@RestController`)
+  - Python: FastAPI (`@app.get`), Django (`path()`), Flask
+  - Node: Express (`app.get`, `router.post`), Fastify, Nest.js
+  - Ruby: Rails, C#: ASP.NET Core
+  - Discovery: Serena MCP → Grep fallback
+  - Extract: HTTP method, path, handler function, file location
+- **Step 3.1.1 - Validate endpoint safety via impact analysis:**
+  - Count references using Serena `find_referencing_symbols` or Grep
+  - Classify: Low (<5 refs), Medium (5-10), High (>10)
+  - Flag high-impact endpoints, exclude destructive operations
+- **Step 3.2 - Group endpoints into workflows:**
+  - Resource-based: `/api/v2/products/*` → "Product Management"
+  - Controller-based: `ProductController` → "Product Management"
+  - OpenAPI tags: Use spec tags if available
+  - Calculate complexity: Simple (1-2 endpoints), Moderate (3-4), Complex (5+)
+- **Step 3.3 - Present workflows and prompt selection:**
+  - Display table: Workflow Name, Entry Endpoint, Key Endpoints, Complexity, Impact
+  - Warn on high-impact workflows
+  - User selects one workflow from list
+- **Step 3.4 - Auto-populate scenarios from selected workflow:**
+  - Generate scenarios from workflow endpoints
+  - Naming: `GET /api/v2/products` → `products-get-list`
+  - Each scenario: name, endpoint (method + path), description
+- **Step 3.5 - Discover modules:**
+  - Locate handler functions/service classes for workflow endpoints
+  - Serena `get_symbols_overview` → Grep fallback
+- **Step 3.6 - Update config:**
+  - Performance Scenarios table, Module Registry table, Selected Workflow metadata
+  - Set `workflow_selected: true`, `backend_endpoint_discovery_method`
+
+**Workflow Selection by Architecture Mode:**
+
+- **Frontend-only:** Run **Frontend Workflow Discovery**, present workflows, user selects ONE
+- **Backend-only:** Run **Backend Workflow Discovery**, present workflows, user selects ONE
+- **Full-stack:** Run **Frontend Workflow Discovery**, present workflows, user selects ONE frontend workflow. Then **trace backend API calls** from that workflow's components (Step 4.8) to identify which backend endpoints to measure. Backend scenarios are scoped to the APIs the selected frontend workflow actually calls.
+
+**Frontend-to-Backend API Tracing (Step 4.8, full-stack only):**
+- After frontend workflow selection, scan the workflow's component files for API call patterns
+- Extract API endpoint URLs from `fetch()`, `axios`, `useQuery`, `useSWR`, and custom API client calls
+- Resolve frontend API paths against the backend's `api_base_path` and verify endpoints exist in backend route definitions
+- Generate backend scenarios scoped to the traced API endpoints (GET only; POST/PUT/DELETE traced for analysis but not benchmarked)
+- User confirms the traced endpoints before measurement proceeds
+- Best-effort trace: one level of local imports from module entry points; user edits expected for complex codebases
+
+**Final Steps (all modes):**
+- **Update config** with selected workflow, scenarios, modules
+- Set `workflow_selected: true`
+
+**ALWAYS (whether workflow just selected or already selected):**
+1. Determine target repository (argument or current directory)
+2. Verify Performance Analysis Configuration exists
+3. Prompt user to confirm test data availability
+4. Baseline capture mode confirmation (cold-start only)
+5. Check if baseline already exists (prompt to replace or cancel)
+6. Copy capture-baseline.template.mjs from plugin cache to target directory
+7. **Dev command discovery and approval:**
+   - Check if dev command already configured (with SHA-256 hash verification)
+   - If not configured: Discover from package.json (`"dev"`, `"start"` scripts), README.md, CONTRIBUTING.md, Makefile, justfile, framework defaults
+   - Extract port from: command flags (`--port`, `-p`), `.env` files, config files, framework defaults
+   - Present discovered command to user for approval (allow modification)
+   - Update config with approved command and SHA-256 hash
+   - Verify application is actually running on discovered port before proceeding
+8. Execute script with mode-specific parameters
+9. Parse JSON output and generate baseline-report.md from template
+10. Filter scenarios to include only those in selected workflow
+11. **Update config with baseline metadata** (`baseline_captured: true`, `baseline_mode`, etc.)
+12. Save report to configured location (`performance/baselines/baseline-report.md`)
+13. Output summary with key metrics and threshold warnings
+
+**Output:**
+- **Config updated** (first run only):
+  - Performance Scenarios (auto-derived from selected workflow)
+  - Module Registry (lazy-loaded pages from workflow)
+  - Selected Workflow metadata
+  - Metadata: `workflow_selected: true`
+- `baseline-report.md` created in configured baseline directory with per-scenario metrics captured via cold-start mode (cold cache, direct URL navigation)
+- Summary output with aggregate metrics and warnings for exceeded thresholds
+
+**Guardrails:**
+- Workflow discovery only runs if `workflow_selected: false` (first run)
+- Subsequent runs skip discovery and use existing workflow
+- Verifies test data availability before capturing baseline
+- Does NOT modify source code — only creates/updates configuration and measurement artifacts
+- Scenarios and modules automatically derived from selected workflow (no separate selection)
+- Filters scenarios to include only those in selected workflow
+
+**Error Handling:**
+- **Application not running:** Detects ECONNREFUSED and prompts user to start application
+- **Playwright not installed:** Detects missing dependency and provides installation commands
+- **Invalid URLs:** Validates localhost URLs and prompts user to fix configuration
+- **Missing performance marks:** Detects metric collection failures and suggests checking browser console
+
+---
+
+### Module-Level Analysis
+
+**Skill:** `/sdlc-workflow:performance-analyze-module`
+
+Performs deep analysis of the selected workflow by examining bundle composition, component render times, and detecting common performance anti-patterns.
+
+**Invocation:**
+
+```
+/sdlc-workflow:performance-analyze-module
+/sdlc-workflow:performance-analyze-module /path/to/target/repo
+```
+
+**Workflow:**
+1. Determine target repository (argument or current directory)
+2. Verify Performance Analysis Configuration exists and contains selected workflow
+3. Verify baseline report exists for selected workflow
+4. Read baseline data (per-scenario metrics, resource timing, aggregate metrics)
+5. Analyze bundle composition:
+   - Locate bundle stats (webpack/vite) if available
+   - Identify third-party libraries vs application code
+   - Calculate module-specific vs shared code ratio
+6. Detect frontend performance anti-patterns (Frontend-Only and Full-Stack modes):
+   - **Over-fetching:** API responses include unused fields
+   - **N+1 queries:** Sequential API calls in loops
+   - **Waterfall loading:** Sequential resource dependency chains
+   - **Render-blocking resources:** Synchronous scripts or non-async CSS
+   - **Unused code:** Imported modules never called
+   - **Expensive re-renders:** Components missing memoization
+   - **Long tasks:** JavaScript execution blocks > 50ms
+   - **Layout thrashing:** Interleaved DOM read-write operations
+   - **Missing lazy loading:** Large components loaded eagerly
+7. **Backend Source Code Analysis (Backend-Only and Full-Stack modes):**
+   - **Step 7.1 - Locate backend handler:** Find handler function serving the endpoint (Serena MCP `find_symbol` → Grep fallback)
+   - **Step 7.2 - Extract backend response schema:** Read handler implementation to extract complete response schema
+   - **Step 7.3 - Detect backend database N+1 queries:** Identify queries executed in loops instead of batch fetching
+     - Supported ORMs: sqlx, SeaORM, Diesel (Rust), JPA/Hibernate (Java), SQLAlchemy, Django ORM (Python), TypeORM, Prisma, Sequelize (Node)
+     - Pattern detection: Queries inside `for`/`forEach`/`map` loops
+   - **Step 7.4 - Detect missing pagination:** Identify endpoints returning unbounded result sets without pagination
+     - Check for: Missing `LIMIT`/`OFFSET` clauses, no page size parameter, collection returned without bounds
+   - **Step 7.5 - Detect missing caching:** Find expensive operations (complex queries, external API calls) executed on every request without caching
+   - **Step 7.6 - Detect inefficient queries:** Identify queries fetching unnecessary data
+     - `SELECT *` instead of specific columns
+     - Fetching unused columns
+     - Missing database indexes on WHERE/JOIN clauses
+   - **Step 7.6.1 - Detect unused table JOINs:** Find queries JOINing tables but never accessing joined table fields (waste database resources)
+     - Most extensive check: Analyzes 7 ORM frameworks with specific patterns
+     - Calculates impact: JOIN cost × query frequency
+8. Generate workflow-analysis-report.md with severity classification and quantified impact
+9. Save report to configured location (`performance/analysis/workflow-analysis-report.md`)
+
+**Output:**
+- `workflow-analysis-report.md` created in configured analysis directory
+- Report includes: overall performance rating, bundle composition breakdown, anti-pattern analysis with code snippets, prioritized optimization recommendations
+- Summary output with key findings and top optimization opportunities
+
+**Guardrails:**
+- Requires Performance Analysis Configuration with selected workflow and existing baseline (prompts user to run prerequisite skills if missing)
+- Does NOT modify source code — only creates analysis artifacts
+- All anti-pattern detection based on actual code search results — no fabricated findings
+- Scope limited to selected workflow only
+- If anti-pattern detection fails, documents failed steps in report rather than halting
+
+---
+
+### Optimization Planning
+
+**Skill:** `/sdlc-workflow:performance-plan-optimization`
+
+Generates a structured optimization plan by reviewing module-level analysis reports, creating Jira Epic and Tasks for optimization work, and producing an optimization-plan.md document with sequenced implementation steps.
+
+**Invocation:**
+
+```
+/sdlc-workflow:performance-plan-optimization
+/sdlc-workflow:performance-plan-optimization /path/to/target/repo
+```
+
+**Workflow:**
+1. Determine target repository (argument or current directory)
+2. Verify Performance Analysis Configuration exists
+3. Verify workflow-analysis-report.md exists (from analyze-module)
+4. Read and parse analysis report (extract anti-patterns, optimizations, metrics)
+5. **Conduct Cross-Functional Impact Analysis (determines which optimizations become tasks):**
+   - **Step 5.1 - Identify affected code modules:** For each optimization, use Serena MCP `find_referencing_symbols` (or Grep fallback) to find usage and classify scope:
+     - **Isolated:** Single file/component (no imports found)
+     - **Low:** 2-3 files, same module/layer
+     - **Medium:** 4-7 files OR cross-layer (frontend + backend)
+     - **High:** ≥8 files OR core infrastructure (routing, auth, state management)
+   - **Step 5.2 - Assess cross-functional impact severity:** Count affected workflows and classify severity:
+     - **None:** No other workflows affected (isolated to target workflow)
+     - **Low:** 1-2 workflows affected
+     - **Medium:** 3-4 workflows affected
+     - **High:** 5-10 workflows affected
+     - **Critical:** All workflows affected OR core business logic change
+     - Identify risk factors: Breaking Change, Behavioral Change, Performance Trade-off, Cosmetic Change, Infrastructure Change
+   - **Step 5.3 - Make rational decision** using 9-rule decision framework:
+     - **RECOMMEND:** Create Jira task (safe, high-benefit optimizations)
+     - **RECOMMEND WITH CAUTION:** Create task + add safeguards (regression tests, staging requirements)
+     - **CONDITIONAL:** Document requirements, don't create task yet (prerequisites not met)
+     - **DEFER:** Document for future review (risk > benefit currently)
+     - **REJECT:** Document reasoning (not worth pursuing)
+   - **Step 5.4 - Document impact analysis** per optimization with: scope, severity, affected components/workflows, risk factors, decision, rationale
+   - **CRITICAL:** Only RECOMMEND and RECOMMEND WITH CAUTION optimizations proceed to become Jira tasks
+6. Group optimizations (RECOMMEND + RECOMMEND WITH CAUTION only) into logical tasks using 3-layer taxonomy:
+   - **Layer 1 - Frontend:** 1A Bundle Size, 1B Render Optimization, 1C Resource Loading
+   - **Layer 2 - Backend:** 2A Query Optimization, 2B Response Optimization
+   - **Layer 3 - Integration:** 3A API Communication
+7. Generate optimization-plan.md with:
+   - Executive summary with Impact Analysis Summary (total evaluated, recommended, deferred, rejected counts)
+   - Task sequence and implementation plan (RECOMMEND + CAUTION tasks only)
+   - Deferred and Rejected Optimizations section (documented for future reference)
+   - Risk assessment and rollback strategy
+8. Create Jira Epic for performance optimization work (with performance-optimization label)
+9. Create Jira Tasks for each optimization (RECOMMEND + CAUTION only) with performance-specific sections:
+   - Baseline Metrics
+   - Target Metrics
+   - Performance Test Requirements
+   - Cross-Functional Impact Assessment (from Step 5.4)
+   - Required Safeguards (if RECOMMEND WITH CAUTION)
+10. Link tasks to Epic via "Relates" relationship and create dependency links
+11. Post optimization plan as comment on Epic
+
+**Output:**
+- `optimization-plan.md` created in configured plans directory
+- Jira Epic created with performance-optimization label
+- Jira Tasks created for each optimization (linked to Epic)
+- Plan document posted as comment on Epic
+- Summary output with Epic key, task keys, and effort estimate
+
+**Guardrails:**
+- Requires Performance Analysis Configuration and existing workflow-analysis-report.md (prompts user to run prerequisite skills if missing)
+- Does NOT modify source code — only creates planning artifacts and Jira issues
+- All Jira issues include `ai-generated-jira` label
+- Uses Atlassian MCP first, falls back to REST API with user consent
+- If Jira operations fail and user declines REST API, saves plan locally and continues
+- Task descriptions include performance-specific sections (Baseline Metrics, Target Metrics, Performance Test Requirements)
+
+---
+
+### Optimization Implementation
+
+**Skill:** `/sdlc-workflow:implement-task` (performance sections auto-detected from Jira task)
+
+Executes performance optimization tasks by implementing code changes, running functional and performance tests, and comparing results against targets.
+
+**Invocation:**
+
+```
+/sdlc-workflow:implement-task TC-XXXX
+```
+
+**Workflow:**
+1. Validate Project Configuration in CLAUDE.md
+2. Fetch and parse Jira task (with performance-specific sections: Baseline Metrics, Target Metrics, Performance Test Requirements)
+3. Verify dependencies are Done
+4. Transition task to In Progress and assign to current user
+5. Inspect code using Serena or Read/Grep/Glob
+6. Create feature branch (named after Jira issue ID)
+7. Implement optimization following task's Implementation Notes
+8. Run functional tests:
+   - Try `npm test` first
+   - If tests not available, prompt user for test script path and instructions
+   - If no tests exist, recommend manual regression verification
+9. Performance testing phase:
+   - **Validate baseline freshness:** Check commits since baseline (read `baseline_commit_sha` from config, compare against current branch base, identify changed workflow files). If baseline may be stale, prompt: Continue / Re-baseline / Cancel
+   - Re-run baseline capture for affected scenarios
+   - Compare current metrics against baseline and targets
+   - Generate before/after comparison report
+   - Verify listed target metrics achieved; if a listed metric regresses beyond noise tolerance, prompt to stash and stop or proceed with `regression_acknowledged`
+10. Commit changes using Conventional Commits format (`perf` type) with performance impact in commit body
+11. Push branch and create PR with before/after comparison table
+12. Update Jira with PR link and performance results
+13. Transition task to In Review
+
+**Output:**
+- Code changes committed to feature branch
+- PR created with performance impact summary
+- **Optimization result report** created: `performance/optimization-results/{jira_key}-{timestamp}.md` (primary data handoff to verify-pr perf mode)
+- Before/after comparison report posted to Jira (summary from local report file)
+- Jira task updated with PR link and transitioned to In Review
+
+**Guardrails:**
+- Extends implement-task workflow with performance-specific steps
+- Follows all implement-task constraints (scope containment, code inspection before modification, conventional commits)
+- Always attempts functional tests before performance tests
+- If no automated tests exist, requires manual regression verification
+- Stops execution if any **listed** target metric regresses beyond noise tolerance (user may acknowledge and proceed, setting `regression_acknowledged`)
+- Does NOT modify files outside task scope
+- Does NOT skip functional tests or manual verification
+- Does NOT fabricate performance metrics — always runs actual baseline capture
+
+---
+
+### Optimization Verification
+
+**Skill:** `/sdlc-workflow:verify-pr` (performance sections auto-detected from Jira task)
+
+Verifies a performance optimization PR by reading review feedback, validating acceptance criteria, optionally re-running performance baseline, and creating sub-tasks for change requests.
+
+**Invocation:**
+
+```
+/sdlc-workflow:verify-pr TC-XXXX
+```
+
+**Workflow:**
+1. Validate Project Configuration in CLAUDE.md
+2. Fetch and parse Jira task (with performance-specific sections)
+3. Identify PR from Git Pull Request custom field or user input
+4. Check out PR branch locally
+5. Review feedback resolution:
+   - Fetch and enumerate all comment threads
+   - Classify feedback (code change request, suggestion, question, nit)
+   - Perform convention check to upgrade suggestions to code change requests
+   - Create sub-tasks for code change requests
+   - Reply to every review comment with classification
+6. Read implementation results from optimization result report file (`performance/optimization-results/{jira_key}-*.md`), fallback to PR description/comments if file not found
+7. Optional baseline re-run (prompt user):
+   - Re-run baseline capture for all scenarios
+   - Compare with implementation results (flag > 10% drift)
+8. Validate target achievement:
+   - Compare metrics against targets
+   - Classify as Full Success, Partial Success, Insufficient Improvement, or Regression
+9. Scope containment check (files match task scope)
+10. Diff size check (proportional to task scope)
+11. Commit traceability check (`perf` type, performance impact section, Jira ID)
+12. Sensitive pattern scan (credentials, secrets, API keys)
+13. CI status check (with sub-task creation for failures)
+14. Acceptance criteria verification (inspect code with Serena or Read/Grep/Glob)
+15. Test quality check (parameterization opportunities, missing doc comments)
+16. Generate verification report with Overall result (PASS/WARN/FAIL)
+17. Post report to GitHub PR and Jira task
+18. **Update Optimization Result Report Status:**
+    - Read report from `performance/optimization-results/{jira_key}-*.md`
+    - Update frontmatter metadata: `status` (verified), `verification_timestamp`, `verification_result` (PASS/WARN/FAIL)
+    - Append "Verification Results" section with: acceptance criteria results, review feedback summary, CI status, target achievement status
+
+**Output:**
+- Verification report posted to PR as comment
+- Verification report posted to Jira task as comment
+- Sub-tasks created for review feedback or CI failures
+- Overall result: PASS / WARN / FAIL
+
+**Guardrails:**
+- Extends verify-pr workflow with performance-specific verification
+- Does NOT modify code (follows verify-pr Constraint 1.11)
+- Does NOT auto-merge (follows verify-pr Constraint 1.13)
+- Regression detection is NOT primary responsibility (happens in implement-task Step 9-Perf)
+- Baseline re-run is optional — used as redundant validation
+- Target Achievement result affects Overall result (unlike Test Quality which is advisory)
+- If baseline re-run shows significant drift (> 10%), flags for investigation but does not block verification
+- Sub-tasks use labels `["ai-generated-jira", "review-feedback"]` for review comments or `["ai-generated-jira", "ci-failure"]` for CI check failures, with "Blocks" issue links
 
 ---
 
diff --git a/evals/implement-task/evals.json b/evals/implement-task/evals.json
index f3528cbed..4f60453e7 100644
--- a/evals/implement-task/evals.json
+++ b/evals/implement-task/evals.json
@@ -99,6 +99,21 @@
         "The response offers the user a choice: (1) proceed with the current description, or (2) stop so they can re-run plan-feature",
         "The response stops execution and does not proceed to Step 2 or implementation planning until the user responds — following the same pause-and-ask pattern as the incomplete description handling"
       ]
+    },
+    {
+      "id": 8,
+      "prompt": "Implement task TC-9208. The task description is in task-performance.md, the target repository structure is in repo-backend.md, the project CLAUDE.md is in claude-md-mock.md, the project's CONVENTIONS.md content is in conventions-mock.md, and the project's performance-config.json is in perf-config-mock.json. Do NOT actually modify repository files or call external tools (Jira, git, Serena). Instead, write your implementation plan to the workspace outputs/ directory: write outputs/plan.md describing which files you would modify and create, what changes you would make to each, what CI/formatting checks you would run before committing, and the commit message you would use. Write outputs/perf-verification.md describing how you would verify performance metrics against the baseline and targets.",
+      "expected_output": "A structured implementation plan for a performance optimization task that demonstrates the skill runs the full verification pipeline: functional tests (Step 8.5), self-verification including CI checks from CONVENTIONS.md and scope containment (Step 9), and performance metric verification against baseline and target metrics (Step 9-Perf). The plan should use perf as the commit type and scope changes to the task's specified files.",
+      "files": ["files/task-performance.md", "files/repo-backend.md", "files/claude-md-mock.md", "files/conventions-mock.md", "files/perf-config-mock.json"],
+      "assertions": [
+        "The plan identifies the task as task_type = performance based on the performance-optimization label or the presence of Baseline Metrics, Target Metrics, and Performance Test Requirements sections (SKILL.md lines 144-145)",
+        "The plan includes running functional tests (Step 8.5) for the performance task before proceeding to self-verification",
+        "The plan includes running CI check commands from CONVENTIONS.md (e.g., cargo xtask precommit or formatting/linting commands) — proving Step 9 is NOT skipped for performance tasks",
+        "The plan includes verifying that modified files match the Files to Modify section — a Step 9 scope containment sub-step that confirms full self-verification runs for performance tasks",
+        "The plan references comparing implementation results against the Target Metrics from the task description (Response Time p95 < 200ms, Queries per request < 5) — confirming Step 9-Perf metric verification still runs after Step 9",
+        "The planned commit message uses perf as the commit type following the performance task commit convention (SKILL.md line 1220, Step 10)",
+        "All files listed in the plan are within the scope defined by the task's Files to Modify and Files to Create sections — no unrelated files are modified (constraint 1.4, 5.1)"
+      ]
     }
   ]
 }
diff --git a/evals/implement-task/files/conventions-mock.md b/evals/implement-task/files/conventions-mock.md
new file mode 100644
index 000000000..cd7a8575d
--- /dev/null
+++ b/evals/implement-task/files/conventions-mock.md
@@ -0,0 +1,38 @@
+<!-- SYNTHETIC TEST DATA — mock CONVENTIONS.md for implement-task eval testing -->
+
+# Coding Conventions
+
+## Language and Framework
+
+- Rust (edition and MSRV are defined in the workspace `Cargo.toml`)
+- Web framework: Axum
+- ORM: SeaORM with `DeriveEntityModel`
+- Database: PostgreSQL
+
+## Code Style
+
+- Follow `rustfmt` defaults — run `cargo fmt --check` before committing
+- Clippy is enforced with strict flags (see the exact invocation in Pre-commit checks)
+- `unwrap()` and `expect()` are forbidden in production code; they are allowed in tests
+
+## Pre-commit checks
+
+Before committing any changes, run:
+
+```sh
+cargo xtask precommit
+```
+
+This command performs the following steps in order:
+
+1. **Runs clippy** (`cargo clippy --all-targets --all-features -- -D warnings`)
+2. **Runs `cargo fmt`** — applies standard Rust formatting
+3. **Runs `cargo check`** (`--all-targets --all-features`) — verifies the project compiles cleanly
+
+Any files modified by these steps must be included in the commit.
+
+## Testing Conventions
+
+- Integration tests use `#[test_context(TrustifyContext)]` from the `trustify_test_context` crate
+- Test functions are `async fn` annotated with `#[test(actix_web::test)]`
+- Tests return `anyhow::Result<()>` for ergonomic error handling
diff --git a/evals/implement-task/files/perf-config-mock.json b/evals/implement-task/files/perf-config-mock.json
new file mode 100644
index 000000000..9b3716384
--- /dev/null
+++ b/evals/implement-task/files/perf-config-mock.json
@@ -0,0 +1,33 @@
+{
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "backend",
+    "baseline_timestamp": "2026-06-10T10:00:00Z",
+    "baseline_commit_sha": "a1b2c3d4e5f67890a1b2c3d4e5f67890abcdef01",
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "metric_type": "backend"
+  },
+  "baseline_settings": {
+    "iterations": 3,
+    "warmup": 1
+  },
+  "dev_environment": {
+    "backend": {
+      "port": 8080,
+      "framework": "axum"
+    }
+  },
+  "directories": {
+    "performance": "performance",
+    "optimization_results": "performance/results",
+    "baselines": "performance/baselines"
+  },
+  "optimization_targets": {}
+}
diff --git a/evals/implement-task/files/task-performance.md b/evals/implement-task/files/task-performance.md
new file mode 100644
index 000000000..47dea1a23
--- /dev/null
+++ b/evals/implement-task/files/task-performance.md
@@ -0,0 +1,72 @@
+<!-- SYNTHETIC TEST DATA — performance optimization task description for implement-task eval testing -->
+
+# Mock Jira Task
+
+**Key**: TC-9208
+**Summary**: Batch advisory queries in SBOM detail endpoint to eliminate N+1
+**Status**: To Do
+**Labels**: ai-generated-jira, performance-optimization, backend, query-optimization
+**Linked Issues**: is incorporated by TC-9001
+
+---
+
+## Repository
+trustify-backend
+
+## Target Branch
+main
+
+## Description
+Replace the sequential per-advisory query loop in the SBOM detail endpoint with a single
+batched query. Currently, `SbomService::fetch_details` loads the SBOM, then iterates over
+linked advisories calling `AdvisoryService::fetch` individually for each one. With SBOMs
+linked to 200+ advisories, this produces ~200 sequential DB queries and pushes response
+time above the 200ms target.
+
+**Implementation approach:**
+
+1. Add a `fetch_advisories_batch` method to `AdvisoryService` that accepts `Vec<Uuid>`
+   and returns all matching advisories in a single `WHERE id IN (...)` query.
+2. Update `SbomService::fetch_details` to collect advisory IDs first, then call the
+   batch method once instead of looping.
+
+## Files to Modify
+- `modules/fundamental/src/advisory/service/advisory.rs` — add `fetch_advisories_batch` method
+- `modules/fundamental/src/sbom/service/sbom.rs` — replace per-advisory loop with batch call
+
+## Files to Create
+- `tests/api/sbom_advisory_batch.rs` — integration test verifying batch loading produces same results
+
+## Implementation Notes
+- Follow the existing `fetch` method pattern in `advisory/service/advisory.rs` for the batch variant
+- Use SeaORM's `.is_in()` filter for the batch query (see `common/src/db/query.rs` for examples)
+- The `sbom_advisory` join table in `entity/src/sbom_advisory.rs` links SBOMs to advisories
+- Error handling: return `AppError` with `.context()` wrapping, matching existing patterns
+- Ensure the batch method preserves the same `AdvisoryDetails` response shape as the individual `fetch`
+
+## Acceptance Criteria
+- [ ] SBOM detail endpoint returns identical advisory data as before (no behavioral change)
+- [ ] Response time for SBOMs with 200+ advisories is under 200ms p95
+- [ ] All existing SBOM and advisory endpoint tests pass
+- [ ] No increase in error rate
+
+## Test Requirements
+- [ ] Test that batch loading returns the same advisory details as individual loading
+- [ ] Test that an SBOM with no advisories returns an empty list (not an error)
+- [ ] Test that duplicate advisory IDs are handled gracefully
+
+## Baseline Metrics
+- **Response Time (p95):** 850ms (`GET /api/v2/sbom/{id}` with 200+ advisories)
+- **Queries per request:** ~200 sequential
+
+## Target Metrics
+- **Response Time (p95):** < 200ms
+- **Queries per request:** < 5
+
+## Performance Test Requirements
+- [ ] Run performance baseline after implementation
+- [ ] Verify SBOM detail response time is under 200ms p95 for 200+ advisory SBOMs
+- [ ] Compare against baseline metrics and confirm improvement
+
+## Dependencies
+None — this task can start immediately.
diff --git a/evals/performance-analyze-module/README.md b/evals/performance-analyze-module/README.md
new file mode 100644
index 000000000..f1ac1473b
--- /dev/null
+++ b/evals/performance-analyze-module/README.md
@@ -0,0 +1,69 @@
+# performance-analyze-module evals
+
+Evaluates the performance analysis skill's ability to detect anti-patterns, validate findings, enforce the progress completion gate, and halt on missing prerequisites.
+
+## Test cases
+
+| ID | Name | Tests |
+|---|---|---|
+| 1 | Frontend-only happy path | Frontend detection + validation + report (≥2 confirmed findings) |
+| 2 | Hybrid analysis | Frontend + backend detection, query ledger, cross-layer analysis |
+| 3 | Progress gate enforcement | Pre-seeded progress with Step 6.5 pending — gate completes step with findings ≥ 1 |
+| 4 | False positive rejection | SeaORM `load_one` batch call vs true N+1 — validation discards false positive |
+| 5 | Missing config halt | No performance config → halt, suggest `performance-setup` |
+| 6 | Missing baseline halt | Config present, baseline missing → halt, suggest `performance-baseline` |
+
+## Output layout
+
+Evals use the same flat pattern as `performance-setup` evals. All artifacts are written under the target repository tree:
+
+```
+outputs/
+└── mock-repo/                    # or mock-backend/ for eval 4
+    ├── performance-config.json
+    └── performance/
+        ├── baselines/
+        └── analysis/
+            ├── analysis-progress.json
+            ├── findings-validation.json
+            ├── workflow-analysis-report.md
+            └── query-ledger.json
+```
+
+Stop-path evals (5–6) write halt messages to `outputs/response.md` and must not produce analysis artifacts.
+
+## Fixtures
+
+- `files/mock-repo/` — React+Vite frontend with planted anti-patterns in `.tsx` files
+- `files/mock-backend/` — Rust/actix-web backend with planted issues in `.rs` files
+- Config files at `files/mock-repo/performance/config-*.json` and `files/mock-backend/performance/config-backend-only.json`
+- Baseline data at `files/mock-repo/performance/baselines/` and `files/mock-backend/performance/baselines/`
+- Pre-seeded progress file at `files/pre-seeded-progress.json` (Eval 3)
+- Unused-import target at `files/mock-repo/src/utils/unused-imports.ts` (Eval 3 Step 6.5)
+
+## Planted patterns
+
+| Location | Step | Pattern |
+|---|---|---|
+| `Dashboard.tsx` | 6.2 | N+1 fetch in loop |
+| `Dashboard.tsx` / `HeavyChart.tsx` | 6.9 | Missing lazy loading |
+| `Dashboard.tsx` | 6.5 | Unused imports from `unused-imports.ts` |
+| `useProducts.ts` | 6.1 | Over-fetching (3 of 12 fields used) |
+| `products.rs::list_products` | 7.4 | Missing pagination |
+| `products.rs::get_product_details` | 7.3 | True N+1 sequential queries |
+| `product.rs::load_product_vendors` | 7.3 | False positive (SeaORM `load_one` batch) |
+
+## Running
+
+```
+/sdlc-workflow:run-evals Run evals for performance-analyze-module.
+Evals path: evals/performance-analyze-module/evals.json
+Workspace: /tmp/performance-analyze-module-eval
+```
+
+## Notes
+
+- Evals use grep-based detection (no Serena) — assertions account for Medium confidence
+- No live SQL, Jira, or server startup — all fixture-based
+- Eval 4 specifically tests the Step 9.1-B2 technology-specific invalidator for SeaORM batch semantics
+- Phase 0 (first end-to-end run + baseline commit) is required before assertion hardening beyond current checks
diff --git a/evals/performance-analyze-module/evals.json b/evals/performance-analyze-module/evals.json
new file mode 100644
index 000000000..4d9bfef80
--- /dev/null
+++ b/evals/performance-analyze-module/evals.json
@@ -0,0 +1,219 @@
+{
+  "skill_name": "performance-analyze-module",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on the mock repo. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/. Copy files/mock-repo/performance/config-frontend-only.json to outputs/mock-repo/performance-config.json. Copy baselines to outputs/mock-repo/performance/baselines/. Write analysis artifacts to outputs/mock-repo/performance/analysis/. Do NOT call Serena, Jira, or live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. This is a frontend-only analysis (no backend). Run Steps 2–6.9 and Step 9 (validation + report). Mark Step 9.7 as not_applicable (no backend). Treat outputs/mock-repo/ as the target repository and read source files from there.",
+      "expected_output": "A complete frontend-only analysis with analysis-progress.json showing all frontend steps done and backend steps not_applicable, findings-validation.json with validated findings, and workflow-analysis-report.md with Anti-Pattern Analysis section. At least 2 anti-patterns should be detected from the planted issues in Dashboard.tsx (N+1 fetch in loop) and Dashboard.tsx/HeavyChart.tsx (missing lazy loading for HeavyChart).",
+      "files": [
+        "files/mock-repo/performance/config-frontend-only.json",
+        "files/mock-repo/performance/baselines/baseline-report.md",
+        "files/mock-repo/package.json",
+        "files/mock-repo/vite.config.ts",
+        "files/mock-repo/src/pages/Dashboard.tsx",
+        "files/mock-repo/src/components/HeavyChart.tsx",
+        "files/mock-repo/src/hooks/useProducts.ts",
+        "files/mock-repo/src/utils/unused-imports.ts"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance/analysis/analysis-progress.json exists and contains no step with status 'pending'",
+        "outputs/mock-repo/performance/analysis/analysis-progress.json shows backend steps (6.B, 7.1-7.7, 7.6.1-7.6.6, 8.A-D, 8.F) with status 'not_applicable'",
+        "outputs/mock-repo/performance/analysis/findings-validation.json exists and contains 'validation_run': true or validation_run: true",
+        "outputs/mock-repo/performance/analysis/findings-validation.json contains at least 2 findings with disposition 'Confirmed' or 'Confirmed (Low Confidence)'",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md exists and contains an 'Anti-Pattern Analysis' heading or section",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md does NOT contain 'Backend Source Code Analysis' heading or section",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md contains 'Validation Status: passed' or 'Validation Status: Passed'",
+        "outputs/mock-repo/performance-config.json directories.baselines value starts with 'performance/' (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on mock repos. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/ and copy files/mock-backend/ to outputs/mock-backend/. Copy files/mock-repo/performance/config-hybrid.json to outputs/mock-repo/performance-config.json. Ensure repositories.backend.path is '../mock-backend' (relative from outputs/mock-repo/). Copy baselines to outputs/mock-repo/performance/baselines/. Write analysis artifacts to outputs/mock-repo/performance/analysis/. Do NOT call Serena, Jira, or live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. This is a hybrid (full-stack) analysis with backend_available=true. Run all detection steps (5-8) and Step 9 (validation + report). Mark Step 9.7 as not_applicable (no live database). Use grep fallback (no Serena). Treat outputs/mock-repo/ as the frontend repository and outputs/mock-backend/ as the backend repository. Read source files from both paths.",
+      "expected_output": "A hybrid analysis with both frontend and backend steps completed. The analysis-progress.json should show all applicable steps as done. The query-ledger.json should exist from Step 7.6.2. The report should contain both frontend Anti-Pattern Analysis and Backend Source Code Analysis sections, plus Cross-Repository Over-Fetching or Cross-Layer Computation Waste. At least 1 backend finding (missing pagination in products.rs) and 1 frontend finding (N+1 fetch in Dashboard.tsx) should be confirmed.",
+      "files": [
+        "files/mock-repo/performance/config-hybrid.json",
+        "files/mock-repo/performance/baselines/baseline-report.md",
+        "files/mock-repo/performance/baselines/benchmark-results.json",
+        "files/mock-repo/package.json",
+        "files/mock-repo/vite.config.ts",
+        "files/mock-repo/src/pages/Dashboard.tsx",
+        "files/mock-repo/src/components/HeavyChart.tsx",
+        "files/mock-repo/src/hooks/useProducts.ts",
+        "files/mock-repo/src/utils/unused-imports.ts",
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/products.rs",
+        "files/mock-backend/src/models/product.rs"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance/analysis/analysis-progress.json exists and shows both frontend steps (5.x, 6.x) and backend steps (6.B, 7.x) as 'done'",
+        "outputs/mock-repo/performance/analysis/query-ledger.json exists and is valid JSON (contains at least one query entry)",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md contains 'Backend Source Code Analysis' heading or section",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md contains 'Cross-Repository Over-Fetching' or 'Cross-Layer Computation Waste' heading or section",
+        "outputs/mock-repo/performance/analysis/findings-validation.json contains at least 1 backend finding with disposition 'Confirmed' (missing pagination or N+1 from products.rs)",
+        "outputs/mock-repo/performance/analysis/findings-validation.json contains at least 1 frontend finding with disposition 'Confirmed' (N+1 fetch or missing lazy load from Dashboard.tsx)",
+        "outputs/mock-repo/performance-config.json directories.baselines value starts with 'performance/' (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on the mock repo. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/. Copy files/mock-repo/performance/config-frontend-only.json to outputs/mock-repo/performance-config.json. Copy baselines to outputs/mock-repo/performance/baselines/. IMPORTANT: copy files/pre-seeded-progress.json to outputs/mock-repo/performance/analysis/analysis-progress.json before starting. This progress file has Step 6.5 (Unused Code Detection) still in 'pending' status while all other frontend steps are 'done'. Start from Step 9.0 (Pre-Report Completeness Gate). The gate should detect the pending step, complete Step 6.5, update the progress file, then proceed to validation and report generation. Write analysis artifacts to outputs/mock-repo/performance/analysis/. Do NOT call Serena, Jira, or live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "files": [
+        "files/mock-repo/performance/config-frontend-only.json",
+        "files/mock-repo/performance/baselines/baseline-report.md",
+        "files/mock-repo/package.json",
+        "files/mock-repo/src/pages/Dashboard.tsx",
+        "files/mock-repo/src/components/HeavyChart.tsx",
+        "files/mock-repo/src/hooks/useProducts.ts",
+        "files/mock-repo/src/utils/unused-imports.ts",
+        "files/pre-seeded-progress.json"
+      ],
+      "expected_output": "The agent detects Step 6.5 is pending in analysis-progress.json, completes the unused code detection step on the mock source files, updates the progress file to mark 6.5 as done with findings >= 1, then proceeds to generate the validation artifact and report.",
+      "assertions": [
+        "outputs/mock-repo/performance/analysis/analysis-progress.json exists and Step 6.5 has status 'done' (not 'pending')",
+        "outputs/mock-repo/performance/analysis/analysis-progress.json Step 6.5 has findings >= 1",
+        "outputs/mock-repo/performance/analysis/analysis-progress.json has no steps with status 'pending'",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md exists (report was generated after the gate passed)",
+        "outputs/mock-repo/performance/analysis/findings-validation.json exists (validation was run after completing the missing step)",
+        "outputs/mock-repo/performance-config.json directories.baselines value starts with 'performance/' (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on mock-backend. Bootstrap: copy files/mock-backend/ to outputs/mock-backend/. Copy files/mock-backend/performance/config-backend-only.json to outputs/mock-backend/performance-config.json. Copy baselines to outputs/mock-backend/performance/baselines/. Write analysis artifacts to outputs/mock-backend/performance/analysis/. Do NOT call Serena (use grep). Do NOT run live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. The backend contains two patterns that look similar but have different dispositions: (1) A TRUE N+1 sequential query loop in src/handlers/products.rs (get_product_details function — Product::find_by_id in a for loop), and (2) A FALSE POSITIVE in src/models/product.rs (load_product_vendors function — SeaORM load_one which is a batch query using WHERE id IN (...), NOT N+1). Run Steps 6.B, 7, and 9. Mark frontend steps and Step 9.7 as not_applicable. Treat outputs/mock-backend/ as the target repository.",
+      "files": [
+        "files/mock-backend/performance/config-backend-only.json",
+        "files/mock-backend/performance/baselines/benchmark-results.json",
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/products.rs",
+        "files/mock-backend/src/models/product.rs"
+      ],
+      "expected_output": "The true N+1 query in products.rs::get_product_details (find_by_id in a loop) should be confirmed as a finding. The SeaORM load_one call in product.rs::load_product_vendors should be discarded as a false positive because load_one is a batch operation (single WHERE id IN query), not N+1. The findings-validation.json should contain both findings — one Confirmed and one Discarded with a reason mentioning batch semantics or load_one.",
+      "assertions": [
+        "outputs/mock-backend/performance/analysis/findings-validation.json contains a finding for the load_one/load_product_vendors pattern with disposition 'Discarded' and reason mentioning 'batch' or 'load_one' or 'WHERE id IN'",
+        "outputs/mock-backend/performance/analysis/findings-validation.json contains a finding for the get_product_details N+1 pattern with disposition 'Confirmed'",
+        "outputs/mock-backend/performance/analysis/workflow-analysis-report.md does NOT mention load_product_vendors or load_one in any anti-pattern findings section (discarded findings excluded from report body)",
+        "outputs/mock-backend/performance/analysis/findings-validation.json validation summary or statistics shows at least 1 discarded finding",
+        "outputs/mock-backend/performance-config.json directories.baselines value starts with 'performance/' (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on the mock repo. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/ but do NOT copy or create any performance config file (no outputs/mock-repo/performance-config.json). The skill should halt when config is missing. Write the halt/remediation message to outputs/response.md. Do NOT write analysis artifacts. Do NOT call Serena, Jira, or live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill detects missing performance config and halts with remediation directing user to run performance-setup first. No analysis report written.",
+      "files": [
+        "files/mock-repo/package.json",
+        "files/mock-repo/vite.config.ts",
+        "files/mock-repo/src/pages/Dashboard.tsx",
+        "files/mock-repo/src/components/HeavyChart.tsx",
+        "files/mock-repo/src/hooks/useProducts.ts"
+      ],
+      "assertions": [
+        "outputs/response.md exists",
+        "outputs/response.md mentions 'performance-setup' or '/performance-setup' as the remediation step",
+        "outputs/response.md references missing performance config or performance-config.json",
+        "outputs/mock-repo/performance-config.json does NOT exist",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md does NOT exist",
+        "outputs/mock-repo/performance/analysis/findings-validation.json does NOT exist"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on the mock repo. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/. Copy files/mock-repo/performance/config-frontend-only.json to outputs/mock-repo/performance-config.json but do NOT copy any baseline files (no outputs/mock-repo/performance/baselines/baseline-report.md). The skill should halt at Step 3 when the baseline report is missing. Write the halt/remediation message to outputs/response.md. Do NOT write analysis artifacts. Do NOT call Serena, Jira, or live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill detects config present but baseline report missing and halts with remediation directing user to run performance-baseline first. No analysis report written.",
+      "files": [
+        "files/mock-repo/performance/config-frontend-only.json",
+        "files/mock-repo/package.json",
+        "files/mock-repo/vite.config.ts",
+        "files/mock-repo/src/pages/Dashboard.tsx",
+        "files/mock-repo/src/components/HeavyChart.tsx",
+        "files/mock-repo/src/hooks/useProducts.ts"
+      ],
+      "assertions": [
+        "outputs/response.md exists",
+        "outputs/response.md mentions 'performance-baseline' or '/performance-baseline' as the remediation step",
+        "outputs/response.md references missing baseline or baseline-report.md",
+        "outputs/mock-repo/performance/analysis/workflow-analysis-report.md does NOT exist",
+        "outputs/mock-repo/performance/analysis/findings-validation.json does NOT exist"
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on mock-backend-scale. Bootstrap: copy files/mock-backend-scale/ to outputs/mock-backend-scale/. Copy files/mock-backend-scale/performance/config-backend-only.json to outputs/mock-backend-scale/performance-config.json. Copy baselines to outputs/mock-backend-scale/performance/baselines/. Write analysis artifacts to outputs/mock-backend-scale/performance/analysis/. Do NOT call Serena (use grep). Do NOT run live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. Mark frontend steps and Step 9.7 as not_applicable (backend-only). The backend contains these planted patterns: (1) search.rs: Cross-Table OR Filter — .columns().add_columns() with filtering_with() across LEFT JOINed entities, (2) data_loader.rs: Load-All-Then-Search — loads all items by category then .iter().find() with search_term that was available before the query, (3) components.rs: Unbounded Query-Driving Iteration — for loop over unbounded query result with DB queries per item and no .take() guard, (4) components.rs: Late Pagination — paginate_array() applied after loading all results, (5) migration/m001_create_tables.rs: Redundant Index — PK on (sbom_id, node_id) plus duplicate btree index on same columns, (6) deep_service.rs: 4-level delegation chain requiring chain depth auto-extension (chain_depth=3 is too shallow), (7) ancestor_walker.rs: WITH RECURSIVE on item_relates_to_item junction table with depth limit 50. Run Steps 6.B, 7 (including 7.3.2, 7.4.1, 7.6.2, 7.6.4.1, 7.6.7, 7.6.8), and 9. Treat outputs/mock-backend-scale/ as the target repository.",
+      "expected_output": "All 7 planted patterns should be detected. Cross-Table OR, Late Pagination, Unbounded Iteration, Redundant Indexes, and Load-All-Then-Search should have Confirmed findings. The query ledger should contain a recursive CTE entry for item_relates_to_item and entries from deep_service.rs at depth > 3 (proving auto-extension worked). At least 5 confirmed findings total.",
+      "files": [
+        "files/mock-backend-scale/performance/config-backend-only.json",
+        "files/mock-backend-scale/performance/baselines/benchmark-results.json",
+        "files/mock-backend-scale/Cargo.toml",
+        "files/mock-backend-scale/src/lib.rs",
+        "files/mock-backend-scale/src/models/mod.rs",
+        "files/mock-backend-scale/src/handlers/mod.rs",
+        "files/mock-backend-scale/src/handlers/search.rs",
+        "files/mock-backend-scale/src/handlers/data_loader.rs",
+        "files/mock-backend-scale/src/handlers/components.rs",
+        "files/mock-backend-scale/src/handlers/deep_service.rs",
+        "files/mock-backend-scale/src/handlers/ancestor_walker.rs",
+        "files/mock-backend-scale/migration/m001_create_tables.rs",
+        "files/mock-backend-scale/migration/m002_add_indexes.rs"
+      ],
+      "assertions": [
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Cross-Table OR Filter' and disposition 'Confirmed'",
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Late Pagination' and disposition 'Confirmed'",
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Unbounded Query-Driving Iteration' and disposition 'Confirmed'",
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Redundant Database Indexes' and disposition 'Confirmed'",
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Load-All-Then-Search' and disposition 'Confirmed'",
+        "outputs/mock-backend-scale/performance/analysis/query-ledger.json contains an entry with is_recursive_cte true or is_recursive_cte: true, and target_table containing 'item_relates_to_item'",
+        "outputs/mock-backend-scale/performance/analysis/query-ledger.json contains entries from deep_service.rs at depth greater than 3 (proving chain depth auto-extension worked)",
+        "outputs/mock-backend-scale/performance/analysis/findings-validation.json statistics show at least 5 confirmed findings"
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on mock-backend-fp-scale. Bootstrap: copy files/mock-backend-fp-scale/ to outputs/mock-backend-fp-scale/. Copy files/mock-backend-fp-scale/performance/config-backend-only.json to outputs/mock-backend-fp-scale/performance-config.json. Copy baselines to outputs/mock-backend-fp-scale/performance/baselines/. Write analysis artifacts to outputs/mock-backend-fp-scale/performance/analysis/. Do NOT call Serena (use grep). Do NOT run live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. Mark frontend steps and Step 9.7 as not_applicable (backend-only). The backend contains patterns that should NOT be flagged as anti-patterns: (1) valid_or.rs: OR across INNER JOINed small reference table (status_code) — optimizer handles INNER JOIN OR well, should not be flagged as Cross-Table OR, (2) graph_builder.rs: load all nodes then build petgraph and run Dijkstra — graph traversal IS the output, should be Discarded by Load-All-Then-Search guard, (3) bounded_loop.rs: loop with .take(100) before iteration — NOT unbounded, (4) db_pagination.rs: pagination via .limit().offset() on the query — correct placement, NOT late pagination, (5) migration/m001_create_tables.rs: single-column index (name) + composite index (name, category_id) — different query coverage, NOT redundant. Run Steps 6.B, 7 (including 7.3.2, 7.4.1, 7.6.2, 7.6.4.1, 7.6.7, 7.6.8), and 9. Treat outputs/mock-backend-fp-scale/ as the target repository.",
+      "expected_output": "All false-positive patterns should be correctly handled: INNER JOIN OR not flagged, graph_builder discarded by traversal guard, bounded loop not flagged, DB pagination not flagged, prefix indexes not flagged. The graph_builder finding should have disposition Discarded with reason mentioning graph traversal.",
+      "files": [
+        "files/mock-backend-fp-scale/performance/config-backend-only.json",
+        "files/mock-backend-fp-scale/performance/baselines/benchmark-results.json",
+        "files/mock-backend-fp-scale/Cargo.toml",
+        "files/mock-backend-fp-scale/src/lib.rs",
+        "files/mock-backend-fp-scale/src/models/mod.rs",
+        "files/mock-backend-fp-scale/src/handlers/mod.rs",
+        "files/mock-backend-fp-scale/src/handlers/valid_or.rs",
+        "files/mock-backend-fp-scale/src/handlers/graph_builder.rs",
+        "files/mock-backend-fp-scale/src/handlers/bounded_loop.rs",
+        "files/mock-backend-fp-scale/src/handlers/db_pagination.rs",
+        "files/mock-backend-fp-scale/migration/m001_create_tables.rs"
+      ],
+      "assertions": [
+        "outputs/mock-backend-fp-scale/performance/analysis/findings-validation.json does NOT contain a confirmed finding with anti_pattern 'Cross-Table OR Filter' (INNER JOIN OR is not flagged or is Discarded)",
+        "outputs/mock-backend-fp-scale/performance/analysis/findings-validation.json contains a finding for graph_builder.rs with disposition 'Discarded' and reason mentioning 'graph traversal' or 'full structure' or 'petgraph' or 'BFS' or 'Dijkstra'",
+        "outputs/mock-backend-fp-scale/performance/analysis/findings-validation.json does NOT contain a confirmed finding for bounded_loop.rs (take(100) guard recognized)",
+        "outputs/mock-backend-fp-scale/performance/analysis/findings-validation.json does NOT contain a confirmed finding with anti_pattern 'Late Pagination' (DB-level pagination correctly recognized)",
+        "outputs/mock-backend-fp-scale/performance/analysis/findings-validation.json does NOT contain a confirmed finding with anti_pattern 'Redundant Database Indexes' (prefix index with distinct query coverage not flagged)"
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "Run /sdlc-workflow:performance-analyze-module on mock-backend-migration. Bootstrap: copy files/mock-backend-migration/ to outputs/mock-backend-migration/. Copy files/mock-backend-migration/performance/config-backend-only.json to outputs/mock-backend-migration/performance-config.json. Copy baselines to outputs/mock-backend-migration/performance/baselines/. Write analysis artifacts to outputs/mock-backend-migration/performance/analysis/. Do NOT call Serena (use grep). Do NOT run live SQL. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/. Mark frontend steps and Step 9.7 as not_applicable (backend-only). The backend contains migration SQL with planted anti-patterns in the migration/ directory: (1) migration/m001_backfill.sql: Missing ANALYZE before bulk INSERT...SELECT on large tables with JOINs, (2) migration/m001_backfill.sql: Non-materialized CTE with expand_license_expression_with_mappings() function call referenced in both INSERT columns and md5() JOIN, (3) migration/m002_normalize.sql: Uniform processing — expand_license_expression_with_mappings() applied to all rows via UPDATE, but function has early-exit guard for rows without 'LicenseRef-' (see m000_functions.sql), (4) migration/m000_functions.sql: PL/pgSQL function with regexp_replace using dynamic pattern concatenation ('\\m' || mapping.license_id || '(?![a-zA-Z0-9.\\-])') inside FOREACH loop. Run Steps 6.B, 7 (including 7.8.1-7.8.4), and 9. Treat outputs/mock-backend-migration/ as the target repository.",
+      "expected_output": "All 4 planted migration SQL anti-patterns should be detected. Missing Statistics Refresh, Non-Materialized CTE Re-evaluation, and Expensive PL/pgSQL Function Pattern should have Confirmed findings. Uniform Processing of Partitionable Data should have Confirmed (Low Confidence) disposition. At least 3 confirmed findings total.",
+      "files": [
+        "files/mock-backend-migration/performance/config-backend-only.json",
+        "files/mock-backend-migration/performance/baselines/benchmark-results.json",
+        "files/mock-backend-migration/Cargo.toml",
+        "files/mock-backend-migration/src/lib.rs",
+        "files/mock-backend-migration/src/handlers/mod.rs",
+        "files/mock-backend-migration/migration/m000_functions.sql",
+        "files/mock-backend-migration/migration/m001_backfill.sql",
+        "files/mock-backend-migration/migration/m002_normalize.sql"
+      ],
+      "assertions": [
+        "outputs/mock-backend-migration/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Missing Statistics Refresh' and disposition 'Confirmed'",
+        "outputs/mock-backend-migration/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Non-Materialized CTE Re-evaluation' and disposition 'Confirmed'",
+        "outputs/mock-backend-migration/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Expensive PL/pgSQL Function Pattern' and disposition 'Confirmed'",
+        "outputs/mock-backend-migration/performance/analysis/findings-validation.json contains a finding with anti_pattern 'Uniform Processing of Partitionable Data' and disposition containing 'Confirmed'",
+        "outputs/mock-backend-migration/performance/analysis/analysis-progress.json shows steps 7.8.1, 7.8.2, 7.8.3, and 7.8.4 with status 'done'",
+        "outputs/mock-backend-migration/performance/analysis/workflow-analysis-report.md contains 'Migration SQL' heading or section",
+        "outputs/mock-backend-migration/performance/analysis/findings-validation.json statistics show at least 3 confirmed or confirmed_low_confidence findings"
+      ]
+    }
+  ]
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/Cargo.toml b/evals/performance-analyze-module/files/mock-backend-fp-scale/Cargo.toml
new file mode 100644
index 000000000..2f0d0ac8f
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/Cargo.toml
@@ -0,0 +1,13 @@
+[package]
+name = "mock-fp-scale-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+tokio = { version = "1", features = ["full"] }
+petgraph = "0.6"
+uuid = { version = "1", features = ["v4"] }
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/migration/m001_create_tables.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/migration/m001_create_tables.rs
new file mode 100644
index 000000000..05a28f980
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/migration/m001_create_tables.rs
@@ -0,0 +1,66 @@
+// SYNTHETIC TEST DATA — Migration for false-positive guard eval
+// FALSE POSITIVE 7.6.4.1: Single-column index + multi-column index on same table
+// The single-column index (component_name_idx on name) serves different
+// query patterns than the composite index (component_name_category_idx on
+// name, category_id). Both are legitimate and NOT redundant.
+
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.create_table(
+            Table::create()
+                .table(Component::Table)
+                .col(ColumnDef::new(Component::Id).uuid().not_null().primary_key())
+                .col(ColumnDef::new(Component::Name).string().not_null())
+                .col(ColumnDef::new(Component::CategoryId).uuid().not_null())
+                .to_owned(),
+        ).await?;
+
+        manager.create_table(
+            Table::create()
+                .table(StatusCode::Table)
+                .col(ColumnDef::new(StatusCode::Id).integer().not_null().primary_key())
+                .col(ColumnDef::new(StatusCode::Label).string().not_null())
+                .to_owned(),
+        ).await?;
+
+        // Single-column index: used by queries filtering ONLY on name
+        manager.create_index(
+            Index::create()
+                .name("component_name_idx")
+                .table(Component::Table)
+                .col(Component::Name)
+                .to_owned(),
+        ).await?;
+
+        // Composite index: used by queries filtering on name + category_id
+        // NOT redundant — serves different query patterns than the single-column index
+        manager.create_index(
+            Index::create()
+                .name("component_name_category_idx")
+                .table(Component::Table)
+                .col(Component::Name)
+                .col(Component::CategoryId)
+                .to_owned(),
+        ).await?;
+
+        Ok(())
+    }
+
+    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.drop_table(Table::drop().table(Component::Table).to_owned()).await?;
+        manager.drop_table(Table::drop().table(StatusCode::Table).to_owned()).await?;
+        Ok(())
+    }
+}
+
+#[derive(Iden)]
+enum Component { Table, Id, Name, CategoryId }
+
+#[derive(Iden)]
+enum StatusCode { Table, Id, Label }
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/baselines/benchmark-results.json b/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..c3fb2f7e8
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/baselines/benchmark-results.json
@@ -0,0 +1,48 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — baseline benchmark for eval 8 (false-positive guards)",
+  "workflow": "fp-scale-api",
+  "timestamp": "2026-06-18T10:00:00Z",
+  "scenarios": {
+    "by-status": {
+      "url": "/api/v2/components/by-status",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 50, "p95": 120, "p99": 200, "min": 20, "max": 250},
+        "throughput_rps": 200,
+        "error_rate_pct": 0.0
+      }
+    },
+    "dependencies": {
+      "url": "/api/v2/sbom/:id/dependencies",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 80, "p95": 150, "p99": 300, "min": 30, "max": 400},
+        "throughput_rps": 150,
+        "error_rate_pct": 0.0
+      }
+    },
+    "enriched": {
+      "url": "/api/v2/components/enriched",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 60, "p95": 130, "p99": 250, "min": 25, "max": 300},
+        "throughput_rps": 180,
+        "error_rate_pct": 0.0
+      }
+    },
+    "paginated": {
+      "url": "/api/v2/components/paginated",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 30, "p95": 80, "p99": 150, "min": 10, "max": 200},
+        "throughput_rps": 300,
+        "error_rate_pct": 0.0
+      }
+    }
+  },
+  "aggregate": {
+    "p95_response_time_ms": 150,
+    "avg_throughput_rps": 207,
+    "avg_error_rate_pct": 0.0
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/config-backend-only.json b/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/config-backend-only.json
new file mode 100644
index 000000000..ad42c370a
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/performance/config-backend-only.json
@@ -0,0 +1,84 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only config for eval 8 (false-positive guards)",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-18T10:00:00Z",
+    "last_updated": "2026-06-18T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-18T10:00:00Z",
+    "baseline_commit_sha": "ghi789",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "grep",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": { "name": null, "path": null, "framework": null, "bundler": null },
+    "backend": {
+      "name": "mock-fp-scale-api",
+      "path": ".",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-18T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "fp-scale-api",
+    "entry_point": "/api/v2/components",
+    "key_screens": ["/api/v2/components"],
+    "complexity": "Simple",
+    "selected_on": "2026-06-18T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "by-status", "url": "/api/v2/components/by-status", "description": "Find by status", "type": "backend"},
+    {"name": "dependencies", "url": "/api/v2/sbom/:id/dependencies", "description": "Get dependencies", "type": "backend"},
+    {"name": "enriched", "url": "/api/v2/components/enriched", "description": "List enriched", "type": "backend"},
+    {"name": "paginated", "url": "/api/v2/components/paginated", "description": "List paginated", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "ValidOR", "entry_point": "src/handlers/valid_or.rs"},
+    {"name": "GraphBuilder", "entry_point": "src/handlers/graph_builder.rs"},
+    {"name": "BoundedLoop", "entry_point": "src/handlers/bounded_loop.rs"},
+    {"name": "DbPagination", "entry_point": "src/handlers/db_pagination.rs"}
+  ],
+  "baseline_settings": { "iterations": 20, "warmup_runs": 2 },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 150, "latest": 150, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 300, "latest": 300, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 200, "latest": 200, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.01, "latest": 0.01, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 20, "latest": 20, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5, "api_latency_ms": 100, "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8, "chain_depth": 3, "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/bounded_loop.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/bounded_loop.rs
new file mode 100644
index 000000000..72e33a148
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/bounded_loop.rs
@@ -0,0 +1,37 @@
+// SYNTHETIC TEST DATA — FALSE POSITIVE guard for eval 8
+// FALSE POSITIVE 7.3.2: Loop with .take(100) guard — NOT unbounded
+//
+// This handler iterates query results but limits the iteration to 100 items
+// via .take(). The skill should recognize this as a bounded loop and
+// NOT flag it as Unbounded Query-Driving Iteration.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+#[get("/api/v2/components/enriched")]
+pub async fn list_enriched_components(
+    db: web::Data<DatabaseConnection>,
+) -> actix_web::Result<impl Responder> {
+    let components = component::Entity::find()
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Bounded: .take(100) limits iteration
+    let mut enriched = Vec::new();
+    for component in components.iter().take(100) {
+        let detail = component_detail::Entity::find_by_id(component.id)
+            .one(db.get_ref())
+            .await
+            .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+        enriched.push(serde_json::json!({
+            "id": component.id,
+            "name": component.name,
+            "detail": detail,
+        }));
+    }
+
+    Ok(HttpResponse::Ok().json(enriched))
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/db_pagination.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/db_pagination.rs
new file mode 100644
index 000000000..7b0cf3a2a
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/db_pagination.rs
@@ -0,0 +1,45 @@
+// SYNTHETIC TEST DATA — FALSE POSITIVE guard for eval 8
+// FALSE POSITIVE 7.4.1: Pagination flows into SQL .limit().offset()
+//
+// This handler correctly applies pagination at the database level.
+// The .limit() and .offset() calls are on the query itself, not on
+// an in-memory collection. The skill should NOT flag this as Late Pagination.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+
+#[get("/api/v2/components/paginated")]
+pub async fn list_paginated_components(
+    db: web::Data<DatabaseConnection>,
+    params: web::Query<PaginationParams>,
+) -> actix_web::Result<impl Responder> {
+    let total = component::Entity::find()
+        .count(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Correct: pagination applied at DB level
+    let results = component::Entity::find()
+        .limit(params.limit as u64)
+        .offset(params.offset as u64)
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(serde_json::json!({
+        "items": results,
+        "total": total,
+        "limit": params.limit,
+        "offset": params.offset,
+    })))
+}
+
+#[derive(serde::Deserialize)]
+pub struct PaginationParams {
+    #[serde(default = "default_limit")]
+    pub limit: usize,
+    #[serde(default)]
+    pub offset: usize,
+}
+
+fn default_limit() -> usize { 20 }
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/graph_builder.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/graph_builder.rs
new file mode 100644
index 000000000..43441ca00
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/graph_builder.rs
@@ -0,0 +1,65 @@
+// SYNTHETIC TEST DATA — FALSE POSITIVE guard for eval 8
+// FALSE POSITIVE 7.6.8: Load all nodes → build petgraph → BFS traversal
+//
+// This handler loads all nodes for an SBOM, builds a petgraph dependency
+// graph, and performs BFS traversal to find all transitive dependencies.
+// The graph traversal IS the primary output — it cannot be expressed as
+// a SQL WHERE clause. The skill should Discard this finding via the
+// graph traversal false-positive guard.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use petgraph::Graph;
+use petgraph::algo::dijkstra;
+use uuid::Uuid;
+use std::collections::HashMap;
+
+#[get("/api/v2/sbom/{id}/dependencies")]
+pub async fn get_transitive_dependencies(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+) -> actix_web::Result<impl Responder> {
+    let sbom_id = path.into_inner();
+
+    // Load all nodes for this SBOM
+    let nodes = sbom_node::Entity::find()
+        .filter(sbom_node::Column::SbomId.eq(sbom_id))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Load all edges
+    let edges = package_relates_to_package::Entity::find()
+        .filter(package_relates_to_package::Column::SbomId.eq(sbom_id))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Build petgraph — graph traversal requires full structure
+    let mut graph = Graph::new();
+    let mut node_indices = HashMap::new();
+
+    for node in &nodes {
+        let idx = graph.add_node(node.node_id.clone());
+        node_indices.insert(node.node_id.clone(), idx);
+    }
+
+    for edge in &edges {
+        if let (Some(&from), Some(&to)) = (
+            node_indices.get(&edge.left_node_id),
+            node_indices.get(&edge.right_node_id),
+        ) {
+            graph.add_edge(from, to, edge.relationship.clone());
+        }
+    }
+
+    // BFS/Dijkstra traversal — this IS the output, not a search filter
+    let root = node_indices.values().next().unwrap();
+    let distances = dijkstra(&graph, *root, None, |_| 1);
+
+    let dependency_count = distances.len();
+    Ok(HttpResponse::Ok().json(serde_json::json!({
+        "sbom_id": sbom_id,
+        "total_dependencies": dependency_count,
+    })))
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/mod.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/mod.rs
new file mode 100644
index 000000000..2a271ceb3
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/mod.rs
@@ -0,0 +1,5 @@
+// SYNTHETIC TEST DATA — Handler module for false-positive guard eval
+pub mod valid_or;
+pub mod graph_builder;
+pub mod bounded_loop;
+pub mod db_pagination;
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/valid_or.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/valid_or.rs
new file mode 100644
index 000000000..f582652c9
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/handlers/valid_or.rs
@@ -0,0 +1,33 @@
+// SYNTHETIC TEST DATA — FALSE POSITIVE guard for eval 8
+// FALSE POSITIVE 7.6.7: OR across INNER JOINed small reference tables
+//
+// This handler uses OR conditions spanning an INNER JOINed table (status_code),
+// which is a small reference table (~50 rows). INNER JOIN OR conditions are
+// handled well by the optimizer. The skill should NOT flag this as Cross-Table OR.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+
+#[get("/api/v2/components/by-status")]
+pub async fn find_by_status(
+    db: web::Data<DatabaseConnection>,
+    query: web::Query<StatusQuery>,
+) -> actix_web::Result<impl Responder> {
+    let results = component::Entity::find()
+        .join(JoinType::InnerJoin, component::Relation::StatusCode.def())
+        .filter(
+            Condition::any()
+                .add(component::Column::Name.contains(&query.q))
+                .add(status_code::Column::Label.contains(&query.q))
+        )
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(results))
+}
+
+#[derive(serde::Deserialize)]
+pub struct StatusQuery {
+    pub q: String,
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/lib.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/lib.rs
new file mode 100644
index 000000000..9da67d268
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/lib.rs
@@ -0,0 +1,3 @@
+// SYNTHETIC TEST DATA — False-positive guard eval fixture
+pub mod handlers;
+pub mod models;
diff --git a/evals/performance-analyze-module/files/mock-backend-fp-scale/src/models/mod.rs b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/models/mod.rs
new file mode 100644
index 000000000..c2c522736
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-fp-scale/src/models/mod.rs
@@ -0,0 +1,20 @@
+// SYNTHETIC TEST DATA — Model stubs for false-positive guard eval
+use sea_orm::entity::prelude::*;
+use serde::{Deserialize, Serialize};
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "component")]
+pub struct ComponentModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub name: String,
+    pub category_id: Uuid,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "status_code")]
+pub struct StatusCodeModel {
+    #[sea_orm(primary_key)]
+    pub id: i32,
+    pub label: String,
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/Cargo.toml b/evals/performance-analyze-module/files/mock-backend-migration/Cargo.toml
new file mode 100644
index 000000000..0a55fc548
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/Cargo.toml
@@ -0,0 +1,12 @@
+# SYNTHETIC TEST DATA — Minimal Cargo.toml for eval
+[package]
+name = "mock-migration-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "1", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+sea-orm-migration = "1"
+serde = { version = "1", features = ["derive"] }
+uuid = { version = "1", features = ["v4"] }
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/migration/m000_functions.sql b/evals/performance-analyze-module/files/mock-backend-migration/migration/m000_functions.sql
new file mode 100644
index 000000000..5b18d1409
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/migration/m000_functions.sql
@@ -0,0 +1,47 @@
+-- SYNTHETIC TEST DATA — Migration with planted anti-patterns for eval
+-- PLANTED ANTI-PATTERN: Step 7.8.4 — Expensive PL/pgSQL Function Pattern
+--
+-- The expand_license_expression_with_mappings function uses regexp_replace()
+-- with dynamically concatenated patterns inside a FOREACH loop. The regex is
+-- recompiled on every iteration because the pattern includes a loop variable.
+
+DO $$
+BEGIN
+    CREATE TYPE license_mapping AS (license_id TEXT, name TEXT);
+EXCEPTION WHEN duplicate_object THEN NULL;
+END $$;
+
+CREATE OR REPLACE FUNCTION expand_license_expression_with_mappings(
+    license_text TEXT,
+    license_mappings license_mapping[]
+) RETURNS TEXT AS $$
+DECLARE
+    result_text TEXT := license_text;
+    mapping license_mapping;
+BEGIN
+    IF license_text IS NULL
+       OR POSITION('LicenseRef-' IN license_text) = 0
+       OR license_mappings IS NULL
+       OR array_length(license_mappings, 1) IS NULL THEN
+        RETURN license_text;
+    END IF;
+
+    FOREACH mapping IN ARRAY license_mappings
+    LOOP
+        IF POSITION('LicenseRef-' IN result_text) = 0 THEN
+            EXIT;
+        END IF;
+        -- PLANTED: Dynamic regexp pattern concatenation inside loop
+        -- The regex '\m' || mapping.license_id || '(?![a-zA-Z0-9.\-])' is
+        -- recompiled on every FOREACH iteration because the pattern includes
+        -- the loop variable mapping.license_id.
+        result_text := regexp_replace(
+            result_text,
+            '\m' || mapping.license_id || '(?![a-zA-Z0-9.\-])',
+            mapping.name, 'g'
+        );
+    END LOOP;
+
+    RETURN result_text;
+END;
+$$ LANGUAGE plpgsql IMMUTABLE PARALLEL SAFE;
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/migration/m001_backfill.sql b/evals/performance-analyze-module/files/mock-backend-migration/migration/m001_backfill.sql
new file mode 100644
index 000000000..dd84b00d4
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/migration/m001_backfill.sql
@@ -0,0 +1,82 @@
+-- SYNTHETIC TEST DATA — Migration with planted anti-patterns for eval
+-- PLANTED ANTI-PATTERN: Step 7.8.1 — Missing Statistics Refresh (Missing ANALYZE)
+-- PLANTED ANTI-PATTERN: Step 7.8.2 — Non-Materialized CTE Re-evaluation
+--
+-- This migration creates a dictionary table and backfills it from existing
+-- SBOM license data. It has two planted issues:
+-- 1. No ANALYZE before the bulk INSERT...SELECT (stale planner statistics)
+-- 2. A CTE with a function call that is referenced twice without MATERIALIZED
+
+-- Step 1: Create dictionary table
+CREATE TABLE IF NOT EXISTS expanded_license (
+    id SERIAL PRIMARY KEY,
+    expanded_text TEXT NOT NULL,
+    text_hash TEXT GENERATED ALWAYS AS (md5(expanded_text)) STORED UNIQUE
+);
+
+-- Step 2: Create junction table
+CREATE TABLE IF NOT EXISTS sbom_license_expanded (
+    sbom_id UUID NOT NULL,
+    license_id INTEGER NOT NULL,
+    expanded_license_id INTEGER NOT NULL REFERENCES expanded_license(id),
+    PRIMARY KEY (sbom_id, license_id)
+);
+
+CREATE INDEX IF NOT EXISTS idx_sle_expanded_license_id
+ON sbom_license_expanded (expanded_license_id);
+
+-- PLANTED (7.8.1): No ANALYZE statement before the backfill queries.
+-- The sbom_package_license and license tables may have stale statistics
+-- (especially if recently bulk-loaded), causing the planner to misestimate
+-- row counts for the JOIN and produce a suboptimal plan.
+
+-- Backfill Step 1: Insert unique expanded texts into dictionary
+INSERT INTO expanded_license (expanded_text)
+SELECT DISTINCT expand_license_expression_with_mappings(
+    l.text,
+    COALESCE(lim.license_mapping, ARRAY[]::license_mapping[])
+)
+FROM sbom_package_license spl
+JOIN license l ON l.id = spl.license_id
+LEFT JOIN (
+    SELECT array_agg(ROW(license_id, name)::license_mapping) AS license_mapping, sbom_id
+    FROM licensing_infos
+    GROUP BY sbom_id
+) lim ON lim.sbom_id = spl.sbom_id
+WHERE NOT EXISTS (
+    SELECT 1 FROM sbom_license_expanded sle
+    WHERE sle.sbom_id = spl.sbom_id
+)
+ON CONFLICT (text_hash) DO NOTHING;
+
+-- PLANTED (7.8.2): Non-materialized CTE with function call, referenced twice.
+-- The CTE 'license_expansions' calls expand_license_expression_with_mappings()
+-- and is used in both the INSERT target columns (ne.expanded) and the JOIN
+-- condition (md5(ne.expanded)). Without MATERIALIZED, PostgreSQL 12+ may
+-- inline the CTE and evaluate the function twice per row.
+WITH license_expansions AS (
+    SELECT DISTINCT
+        spl.sbom_id,
+        spl.license_id,
+        expand_license_expression_with_mappings(
+            l.text,
+            COALESCE(lim.license_mapping, ARRAY[]::license_mapping[])
+        ) AS expanded
+    FROM sbom_package_license spl
+    JOIN license l ON l.id = spl.license_id
+    LEFT JOIN (
+        SELECT array_agg(ROW(license_id, name)::license_mapping) AS license_mapping, sbom_id
+        FROM licensing_infos
+        GROUP BY sbom_id
+    ) lim ON lim.sbom_id = spl.sbom_id
+    WHERE NOT EXISTS (
+        SELECT 1 FROM sbom_license_expanded sle
+        WHERE sle.sbom_id = spl.sbom_id AND sle.license_id = spl.license_id
+    )
+)
+INSERT INTO sbom_license_expanded (sbom_id, license_id, expanded_license_id)
+SELECT ne.sbom_id, ne.license_id, el.id
+FROM license_expansions ne
+JOIN expanded_license el ON el.text_hash = md5(ne.expanded)
+ON CONFLICT (sbom_id, license_id) DO UPDATE
+SET expanded_license_id = EXCLUDED.expanded_license_id;
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/migration/m002_normalize.sql b/evals/performance-analyze-module/files/mock-backend-migration/migration/m002_normalize.sql
new file mode 100644
index 000000000..b6adf58c8
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/migration/m002_normalize.sql
@@ -0,0 +1,32 @@
+-- SYNTHETIC TEST DATA — Migration with planted anti-patterns for eval
+-- PLANTED ANTI-PATTERN: Step 7.8.3 — Uniform Processing of Partitionable Data
+--
+-- This migration normalizes license text by expanding LicenseRef- references.
+-- The expand_license_expression_with_mappings function is applied to ALL rows,
+-- but its early-exit guard shows that rows without 'LicenseRef-' are returned
+-- unchanged. The expensive LEFT JOIN + function call could be limited to the
+-- minority of rows that actually contain LicenseRef-.
+
+-- PLANTED: Uniform processing — function applied to all rows via UPDATE,
+-- but expand_license_expression_with_mappings has an early-exit guard:
+--   IF POSITION('LicenseRef-' IN license_text) = 0 THEN RETURN license_text;
+-- This means most rows (those without LicenseRef-) pass through unchanged.
+-- The expensive LEFT JOIN with licensing_infos is also applied to all rows,
+-- even though it is only consumed by the function for LicenseRef- rows.
+
+UPDATE normalized_license nl
+SET expanded_text = expand_license_expression_with_mappings(
+    nl.original_text,
+    COALESCE(lim.license_mapping, ARRAY[]::license_mapping[])
+)
+FROM (
+    SELECT nl2.id, nl2.original_text, nl2.sbom_id
+    FROM normalized_license nl2
+    WHERE nl2.expanded_text IS NULL
+) src
+LEFT JOIN (
+    SELECT array_agg(ROW(license_id, name)::license_mapping) AS license_mapping, sbom_id
+    FROM licensing_infos
+    GROUP BY sbom_id
+) lim ON lim.sbom_id = src.sbom_id
+WHERE nl.id = src.id;
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/performance/baselines/benchmark-results.json b/evals/performance-analyze-module/files/mock-backend-migration/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..099b5085d
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/performance/baselines/benchmark-results.json
@@ -0,0 +1,32 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — Minimal baseline for eval 9",
+  "timestamp": "2026-06-30T10:00:00Z",
+  "commit_sha": "abc123",
+  "endpoints": [
+    {
+      "name": "list-licenses",
+      "url": "/api/v2/licenses",
+      "method": "GET",
+      "cold": {
+        "p50": 250,
+        "p95": 500,
+        "p99": 2000,
+        "mean": 300,
+        "min": 100,
+        "max": 2500,
+        "samples": 20
+      },
+      "warm": {
+        "p50": 150,
+        "p95": 300,
+        "p99": 800,
+        "mean": 180,
+        "min": 80,
+        "max": 1000,
+        "samples": 20
+      },
+      "throughput_rps": 50,
+      "error_rate": 0.0
+    }
+  ]
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/performance/config-backend-only.json b/evals/performance-analyze-module/files/mock-backend-migration/performance/config-backend-only.json
new file mode 100644
index 000000000..5a2b22fdf
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/performance/config-backend-only.json
@@ -0,0 +1,90 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only config for eval 9 (migration SQL detection)",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-30T10:00:00Z",
+    "last_updated": "2026-06-30T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-30T10:00:00Z",
+    "baseline_commit_sha": "abc123",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "grep",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": {
+      "name": null,
+      "path": null,
+      "framework": null,
+      "bundler": null
+    },
+    "backend": {
+      "name": "mock-migration-api",
+      "path": ".",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-30T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "license-api",
+    "entry_point": "/api/v2/licenses",
+    "key_screens": ["/api/v2/licenses"],
+    "complexity": "Simple",
+    "selected_on": "2026-06-30T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "list-licenses", "url": "/api/v2/licenses", "description": "List licenses", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "Handlers", "entry_point": "src/handlers/mod.rs"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 500, "latest": 500, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 2000, "latest": 2000, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 50, "latest": 50, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.0, "latest": 0.0, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 300, "latest": 300, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/src/handlers/mod.rs b/evals/performance-analyze-module/files/mock-backend-migration/src/handlers/mod.rs
new file mode 100644
index 000000000..528123d0c
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/src/handlers/mod.rs
@@ -0,0 +1,12 @@
+// SYNTHETIC TEST DATA — Minimal handler module for eval
+
+use actix_web::{get, web, HttpResponse};
+
+#[get("/api/v2/licenses")]
+async fn list_licenses() -> HttpResponse {
+    HttpResponse::Ok().json(serde_json::json!({"licenses": []}))
+}
+
+pub fn configure(cfg: &mut web::ServiceConfig) {
+    cfg.service(list_licenses);
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-migration/src/lib.rs b/evals/performance-analyze-module/files/mock-backend-migration/src/lib.rs
new file mode 100644
index 000000000..732ed36ed
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-migration/src/lib.rs
@@ -0,0 +1,2 @@
+// SYNTHETIC TEST DATA — Minimal lib for eval
+pub mod handlers;
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/Cargo.toml b/evals/performance-analyze-module/files/mock-backend-scale/Cargo.toml
new file mode 100644
index 000000000..6ea81ab71
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/Cargo.toml
@@ -0,0 +1,14 @@
+[package]
+name = "mock-scale-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+sea-query = "0.30"
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+tokio = { version = "1", features = ["full"] }
+petgraph = "0.6"
+uuid = { version = "1", features = ["v4"] }
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/migration/m001_create_tables.rs b/evals/performance-analyze-module/files/mock-backend-scale/migration/m001_create_tables.rs
new file mode 100644
index 000000000..62e5069d9
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/migration/m001_create_tables.rs
@@ -0,0 +1,80 @@
+// SYNTHETIC TEST DATA — Migration with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.4.1 — Redundant Index
+//
+// The sbom_node table has a PRIMARY KEY on (sbom_id, node_id) AND a
+// separate btree index on the same columns. The duplicate index wastes
+// disk space and buffer cache.
+
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.create_table(
+            Table::create()
+                .table(SbomNode::Table)
+                .col(ColumnDef::new(SbomNode::SbomId).uuid().not_null())
+                .col(ColumnDef::new(SbomNode::NodeId).string().not_null())
+                .col(ColumnDef::new(SbomNode::Name).string().not_null())
+                .primary_key(Index::create().col(SbomNode::SbomId).col(SbomNode::NodeId))
+                .to_owned(),
+        ).await?;
+
+        // PLANTED: This index duplicates the primary key exactly
+        manager.create_index(
+            Index::create()
+                .name("sbom_node_sbom_id_node_id_idx")
+                .table(SbomNode::Table)
+                .col(SbomNode::SbomId)
+                .col(SbomNode::NodeId)
+                .to_owned(),
+        ).await?;
+
+        // item_relates_to_item — junction table for recursive CTE detection
+        manager.create_table(
+            Table::create()
+                .table(ItemRelatesToItem::Table)
+                .col(ColumnDef::new(ItemRelatesToItem::ParentId).uuid().not_null())
+                .col(ColumnDef::new(ItemRelatesToItem::ChildId).uuid().not_null())
+                .col(ColumnDef::new(ItemRelatesToItem::Relationship).string().not_null())
+                .primary_key(
+                    Index::create()
+                        .col(ItemRelatesToItem::ParentId)
+                        .col(ItemRelatesToItem::ChildId)
+                )
+                .to_owned(),
+        ).await?;
+
+        manager.create_table(
+            Table::create()
+                .table(Component::Table)
+                .col(ColumnDef::new(Component::Id).uuid().not_null().primary_key())
+                .col(ColumnDef::new(Component::Name).string().not_null())
+                .col(ColumnDef::new(Component::Version).string().not_null())
+                .col(ColumnDef::new(Component::CategoryId).uuid().not_null())
+                .col(ColumnDef::new(Component::Active).boolean().not_null().default(true))
+                .to_owned(),
+        ).await?;
+
+        Ok(())
+    }
+
+    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.drop_table(Table::drop().table(SbomNode::Table).to_owned()).await?;
+        manager.drop_table(Table::drop().table(ItemRelatesToItem::Table).to_owned()).await?;
+        manager.drop_table(Table::drop().table(Component::Table).to_owned()).await?;
+        Ok(())
+    }
+}
+
+#[derive(Iden)]
+enum SbomNode { Table, SbomId, NodeId, Name }
+
+#[derive(Iden)]
+enum ItemRelatesToItem { Table, ParentId, ChildId, Relationship }
+
+#[derive(Iden)]
+enum Component { Table, Id, Name, Version, CategoryId, Active }
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/migration/m002_add_indexes.rs b/evals/performance-analyze-module/files/mock-backend-scale/migration/m002_add_indexes.rs
new file mode 100644
index 000000000..f38d9904c
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/migration/m002_add_indexes.rs
@@ -0,0 +1,49 @@
+// SYNTHETIC TEST DATA — Valid indexes (non-redundant) to ensure no false positives
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        // Valid: GIN trigram index on sbom_node.name (different type from PK btree)
+        manager.exec_stmt(
+            sea_query::Query::select()
+                .expr(sea_query::Expr::cust(
+                    "CREATE INDEX sbomnodenameginidx ON sbom_node USING gin ((name) gin_trgm_ops)"
+                ))
+                .to_owned(),
+        ).await?;
+
+        // Valid: index on component.category_id (not a duplicate)
+        manager.create_index(
+            Index::create()
+                .name("component_category_id_idx")
+                .table(Component::Table)
+                .col(Component::CategoryId)
+                .to_owned(),
+        ).await?;
+
+        // Valid: index on item_relates_to_item.child_id for reverse lookups
+        manager.create_index(
+            Index::create()
+                .name("item_relates_child_id_idx")
+                .table(ItemRelatesToItem::Table)
+                .col(ItemRelatesToItem::ChildId)
+                .to_owned(),
+        ).await?;
+
+        Ok(())
+    }
+
+    async fn down(&self, _manager: &SchemaManager) -> Result<(), DbErr> {
+        Ok(())
+    }
+}
+
+#[derive(Iden)]
+enum Component { Table, CategoryId }
+
+#[derive(Iden)]
+enum ItemRelatesToItem { Table, ChildId }
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/performance/baselines/benchmark-results.json b/evals/performance-analyze-module/files/mock-backend-scale/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..606e80d4e
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/performance/baselines/benchmark-results.json
@@ -0,0 +1,57 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — baseline benchmark for eval 7",
+  "workflow": "analysis-api",
+  "timestamp": "2026-06-18T10:00:00Z",
+  "scenarios": {
+    "search-component": {
+      "url": "/api/v2/analysis/component",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 2500, "p95": 4500, "p99": 30000, "min": 800, "max": 35000},
+        "throughput_rps": 10,
+        "error_rate_pct": 5.0
+      }
+    },
+    "list-components": {
+      "url": "/api/v2/components",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 1200, "p95": 2800, "p99": 5000, "min": 400, "max": 6000},
+        "throughput_rps": 25,
+        "error_rate_pct": 0.5
+      }
+    },
+    "category-search": {
+      "url": "/api/v2/categories/:id/components",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 800, "p95": 1500, "p99": 3000, "min": 200, "max": 4000},
+        "throughput_rps": 40,
+        "error_rate_pct": 0.1
+      }
+    },
+    "graph-load": {
+      "url": "/api/v2/analysis/graph/:id",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 500, "p95": 1200, "p99": 2500, "min": 100, "max": 3000},
+        "throughput_rps": 50,
+        "error_rate_pct": 0.0
+      }
+    },
+    "ancestors": {
+      "url": "/api/v2/components/:id/ancestors",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 300, "p95": 800, "p99": 1500, "min": 50, "max": 2000},
+        "throughput_rps": 80,
+        "error_rate_pct": 0.0
+      }
+    }
+  },
+  "aggregate": {
+    "p95_response_time_ms": 4500,
+    "avg_throughput_rps": 41,
+    "avg_error_rate_pct": 1.12
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/performance/config-backend-only.json b/evals/performance-analyze-module/files/mock-backend-scale/performance/config-backend-only.json
new file mode 100644
index 000000000..34005f9e4
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/performance/config-backend-only.json
@@ -0,0 +1,98 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only config for eval 7 (scale-aware detection)",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-18T10:00:00Z",
+    "last_updated": "2026-06-18T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-18T10:00:00Z",
+    "baseline_commit_sha": "def456",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "grep",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": {
+      "name": null,
+      "path": null,
+      "framework": null,
+      "bundler": null
+    },
+    "backend": {
+      "name": "mock-scale-api",
+      "path": ".",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-18T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "analysis-api",
+    "entry_point": "/api/v2/analysis/component",
+    "key_screens": ["/api/v2/analysis/component"],
+    "complexity": "Complex",
+    "selected_on": "2026-06-18T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "search-component", "url": "/api/v2/analysis/component", "description": "Search components", "type": "backend"},
+    {"name": "list-components", "url": "/api/v2/components", "description": "List components with details", "type": "backend"},
+    {"name": "category-search", "url": "/api/v2/categories/:id/components", "description": "Search in category", "type": "backend"},
+    {"name": "graph-load", "url": "/api/v2/analysis/graph/:id", "description": "Load component graph", "type": "backend"},
+    {"name": "ancestors", "url": "/api/v2/components/:id/ancestors", "description": "Get component ancestors", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "Search", "entry_point": "src/handlers/search.rs"},
+    {"name": "Components", "entry_point": "src/handlers/components.rs"},
+    {"name": "DataLoader", "entry_point": "src/handlers/data_loader.rs"},
+    {"name": "DeepService", "entry_point": "src/handlers/deep_service.rs"},
+    {"name": "AncestorWalker", "entry_point": "src/handlers/ancestor_walker.rs"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 4500, "latest": 4500, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 30000, "latest": 30000, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 10, "latest": 10, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 5.0, "latest": 5.0, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 2000, "latest": 2000, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/ancestor_walker.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/ancestor_walker.rs
new file mode 100644
index 000000000..41206db41
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/ancestor_walker.rs
@@ -0,0 +1,60 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.2 enhancement — Recursive CTE Risk Flagging
+//
+// This handler uses a WITH RECURSIVE query on item_relates_to_item,
+// which is a junction/relationship table (compound PK with 2 FK columns).
+// The depth limit is 50, which the skill should detect as Medium severity
+// (junction table + depth limit present).
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+#[get("/api/v2/components/{id}/ancestors")]
+pub async fn get_ancestors(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+) -> actix_web::Result<impl Responder> {
+    let component_id = path.into_inner();
+
+    let sql = r#"
+WITH RECURSIVE ancestors AS (
+    SELECT
+        p.parent_id,
+        p.child_id,
+        p.relationship,
+        1 AS depth,
+        ARRAY[p.child_id] AS visited
+    FROM item_relates_to_item p
+    WHERE p.child_id = $1
+      AND p.relationship != 'ancestor_of'
+
+    UNION ALL
+
+    SELECT
+        p.parent_id,
+        p.child_id,
+        p.relationship,
+        a.depth + 1,
+        a.visited || p.child_id
+    FROM item_relates_to_item p
+    JOIN ancestors a ON p.child_id = a.parent_id
+    WHERE a.depth < 50
+      AND NOT (p.child_id = ANY(a.visited))
+)
+SELECT DISTINCT parent_id, child_id, relationship
+FROM ancestors
+ORDER BY parent_id
+"#;
+
+    let result = ItemRelation::find_by_statement(Statement::from_sql_and_values(
+        DatabaseBackend::Postgres,
+        sql,
+        [component_id.into()],
+    ))
+    .all(db.get_ref())
+    .await
+    .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(result))
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/components.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/components.rs
new file mode 100644
index 000000000..afdd8b048
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/components.rs
@@ -0,0 +1,72 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.3.2 — Unbounded Query-Driving Iteration
+// PLANTED ANTI-PATTERN: Step 7.4.1 — Late Pagination
+//
+// This handler has two issues:
+// 1. It loads an unbounded result set from the database (no LIMIT, no size guard)
+//    and iterates each item, executing a DB query per item.
+// 2. Pagination parameters exist at the API layer but are applied via
+//    paginate_array() AFTER loading all results into memory.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+use crate::models::{ComponentModel, PaginatedResults, paginate_array};
+
+#[get("/api/v2/components")]
+pub async fn list_components_with_details(
+    db: web::Data<DatabaseConnection>,
+    paginated: web::Query<PaginatedParams>,
+) -> actix_web::Result<impl Responder> {
+    // No LIMIT on this query — loads all matching components
+    let all_components = component::Entity::find()
+        .filter(component::Column::Active.eq(true))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // PLANTED: Unbounded iteration — no .take(N) or size guard
+    // Each iteration triggers a DB query to fetch related data
+    let mut enriched = Vec::new();
+    for component in &all_components {
+        let details = component_detail::Entity::find_by_id(component.id)
+            .one(db.get_ref())
+            .await
+            .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+        let vendors = vendor::Entity::find()
+            .filter(vendor::Column::ComponentId.eq(component.id))
+            .all(db.get_ref())
+            .await
+            .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+        enriched.push(EnrichedComponent {
+            component: component.clone(),
+            details,
+            vendors,
+        });
+    }
+
+    // PLANTED: Late pagination — applied AFTER loading all results
+    let result = paginate_array(&enriched, paginated.offset, paginated.limit);
+
+    Ok(HttpResponse::Ok().json(result))
+}
+
+#[derive(serde::Deserialize)]
+pub struct PaginatedParams {
+    #[serde(default)]
+    pub offset: usize,
+    #[serde(default = "default_limit")]
+    pub limit: usize,
+}
+
+fn default_limit() -> usize { 20 }
+
+#[derive(serde::Serialize, Clone)]
+pub struct EnrichedComponent {
+    pub component: ComponentModel,
+    pub details: Option<component_detail::Model>,
+    pub vendors: Vec<vendor::Model>,
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/data_loader.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/data_loader.rs
new file mode 100644
index 000000000..084ec40ab
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/data_loader.rs
@@ -0,0 +1,45 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.8 — Load-All-Then-Search
+//
+// This handler loads ALL items for a category from the database, then
+// searches the in-memory collection for items matching the user's search
+// term. The search term is known before the query and could be added as
+// a WHERE clause, but instead the code loads everything and filters in
+// memory. This is NOT a graph traversal case — it's a simple linear search.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+use crate::models::ComponentModel;
+
+#[get("/api/v2/categories/{category_id}/components")]
+pub async fn search_components_in_category(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+    query: web::Query<SearchParams>,
+) -> actix_web::Result<impl Responder> {
+    let category_id = path.into_inner();
+    let search_term = &query.name;
+
+    // Load ALL components for this category — no search filter in query
+    let all_components = component::Entity::find()
+        .filter(component::Column::CategoryId.eq(category_id))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Search in memory — search_term was available before the query!
+    let matching: Vec<_> = all_components
+        .iter()
+        .filter(|c| c.name.contains(search_term))
+        .cloned()
+        .collect();
+
+    Ok(HttpResponse::Ok().json(matching))
+}
+
+#[derive(serde::Deserialize)]
+pub struct SearchParams {
+    pub name: String,
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/deep_service.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/deep_service.rs
new file mode 100644
index 000000000..4145cd646
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/deep_service.rs
@@ -0,0 +1,78 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.2 enhancement — Chain Depth Auto-Extension
+//
+// This handler delegates through 4 levels of pure delegation before reaching
+// the actual DB query. With chain_depth=3, the skill would stop at level 3
+// and miss the query. The auto-extension rule should detect that each
+// intermediate function is a pure delegation (single call, returns result)
+// and extend the depth to reach the actual query at level 4.
+//
+// Call chain:
+//   get_component_graph (handler, depth 0)
+//     → service.load_graphs(conn, ids) (depth 1)
+//       → self.inner.load_graphs(conn, ids) (depth 2, pure delegation)
+//         → self.load_graphs_inner(conn, ids) (depth 3 = DEFAULT LIMIT, pure delegation)
+//           → self.perform_load(conn, id) (depth 4, ACTUAL QUERY — only reachable with auto-extension)
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+pub struct GraphService {
+    inner: InnerGraphService,
+}
+
+impl GraphService {
+    pub async fn load_graphs(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        self.inner.load_graphs(conn, ids).await
+    }
+}
+
+pub struct InnerGraphService;
+
+impl InnerGraphService {
+    pub async fn load_graphs(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        self.load_graphs_inner(conn, ids).await
+    }
+
+    async fn load_graphs_inner(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        let mut results = Vec::new();
+        for id in ids {
+            results.push(self.perform_load(conn, id).await?);
+        }
+        Ok(results)
+    }
+
+    async fn perform_load(&self, conn: &DatabaseConnection, id: Uuid) -> Result<GraphData, DbErr> {
+        let nodes = sbom_node::Entity::find()
+            .filter(sbom_node::Column::SbomId.eq(id))
+            .all(conn)
+            .await?;
+
+        let edges = package_relates_to_package::Entity::find()
+            .filter(package_relates_to_package::Column::SbomId.eq(id))
+            .all(conn)
+            .await?;
+
+        Ok(GraphData { nodes, edges })
+    }
+}
+
+pub struct GraphData {
+    pub nodes: Vec<sbom_node::Model>,
+    pub edges: Vec<package_relates_to_package::Model>,
+}
+
+#[get("/api/v2/analysis/graph/{id}")]
+pub async fn get_component_graph(
+    service: web::Data<GraphService>,
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+) -> actix_web::Result<impl Responder> {
+    let id = path.into_inner();
+    let graphs = service.load_graphs(db.get_ref(), vec![id])
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(graphs.len()))
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/mod.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/mod.rs
new file mode 100644
index 000000000..87574e6f5
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/mod.rs
@@ -0,0 +1,6 @@
+// SYNTHETIC TEST DATA — Handler module for scale detection eval
+pub mod search;
+pub mod data_loader;
+pub mod components;
+pub mod deep_service;
+pub mod ancestor_walker;
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/search.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/search.rs
new file mode 100644
index 000000000..ca2d5f933
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/handlers/search.rs
@@ -0,0 +1,46 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.7 — Cross-Table OR Filter
+//
+// This handler builds a search query that registers columns from multiple
+// entities (sbom_node, cpe, qualified_purl) and applies a bare-value filter
+// via filtering_with(). When the user passes q=openssl without a field
+// qualifier, the filter generates ILIKE OR conditions across ALL string
+// columns from ALL registered entities, including LEFT JOINed tables.
+// This defeats index usage on sbom_node.name because PostgreSQL cannot
+// use the GIN trigram index when OR spans LEFT JOINed tables.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use sea_query::JoinType;
+
+use crate::models::{SbomNodeModel, CpeModel, PaginatedResults, paginate_array};
+
+fn q_columns() -> Columns {
+    sbom_node::Entity
+        .columns()
+        .add_columns(cpe::Entity.columns())
+        .add_columns(qualified_purl::Entity.columns())
+}
+
+#[get("/api/v2/analysis/component")]
+pub async fn search_component(
+    db: web::Data<DatabaseConnection>,
+    query: web::Query<SearchQuery>,
+    paginated: web::Query<Paginated>,
+) -> actix_web::Result<impl Responder> {
+    let search_subquery = sbom_node::Entity::find()
+        .join(JoinType::Join, sbom_node::Relation::Package.def())
+        .join(JoinType::LeftJoin, sbom_package::Relation::Purl.def())
+        .join(JoinType::LeftJoin, sbom_package::Relation::Cpe.def())
+        .join(JoinType::LeftJoin, sbom_package_cpe_ref::Relation::Cpe.def())
+        .join(JoinType::LeftJoin, sbom_package_purl_ref::Relation::Purl.def())
+        .select_only()
+        .column(sbom_node::Column::SbomId)
+        .filtering_with(query.q.clone(), q_columns())?
+        .distinct()
+        .into_query();
+
+    let results = load_all_matching(db.get_ref(), search_subquery).await?;
+
+    Ok(HttpResponse::Ok().json(results))
+}
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/lib.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/lib.rs
new file mode 100644
index 000000000..3914c2089
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/lib.rs
@@ -0,0 +1,3 @@
+// SYNTHETIC TEST DATA — Scale-aware detection eval fixture
+pub mod handlers;
+pub mod models;
diff --git a/evals/performance-analyze-module/files/mock-backend-scale/src/models/mod.rs b/evals/performance-analyze-module/files/mock-backend-scale/src/models/mod.rs
new file mode 100644
index 000000000..568f99ce1
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend-scale/src/models/mod.rs
@@ -0,0 +1,65 @@
+// SYNTHETIC TEST DATA — Model stubs for eval fixture
+use sea_orm::entity::prelude::*;
+use serde::{Deserialize, Serialize};
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "component")]
+pub struct ComponentModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub name: String,
+    pub version: String,
+    pub sbom_id: Uuid,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "sbom_node")]
+pub struct SbomNodeModel {
+    #[sea_orm(primary_key)]
+    pub sbom_id: Uuid,
+    #[sea_orm(primary_key)]
+    pub node_id: String,
+    pub name: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "cpe")]
+pub struct CpeModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub vendor: String,
+    pub product: String,
+    pub version: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "category")]
+pub struct CategoryModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub name: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "item_relates_to_item")]
+pub struct ItemRelationModel {
+    #[sea_orm(primary_key)]
+    pub parent_id: Uuid,
+    #[sea_orm(primary_key)]
+    pub child_id: Uuid,
+    pub relationship: String,
+}
+
+pub struct PaginatedResults<T> {
+    pub items: Vec<T>,
+    pub total: usize,
+}
+
+pub fn paginate_array<T: Clone>(items: &[T], offset: usize, limit: usize) -> PaginatedResults<T> {
+    let total = items.len();
+    let end = (offset + limit).min(total);
+    PaginatedResults {
+        items: items[offset..end].to_vec(),
+        total,
+    }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend/Cargo.toml b/evals/performance-analyze-module/files/mock-backend/Cargo.toml
new file mode 100644
index 000000000..794dbd6fd
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend/Cargo.toml
@@ -0,0 +1,11 @@
+[package]
+name = "mock-product-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+tokio = { version = "1", features = ["full"] }
diff --git a/evals/performance-analyze-module/files/mock-backend/performance/baselines/benchmark-results.json b/evals/performance-analyze-module/files/mock-backend/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..7301c0759
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend/performance/baselines/benchmark-results.json
@@ -0,0 +1,44 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend baseline for eval 4",
+  "workflow": "product-api",
+  "endpoints": {
+    "/api/v2/products": {
+      "first_request_ms": 250,
+      "p50_ms": 45,
+      "p95_ms": 180,
+      "p99_ms": 320,
+      "mean_ms": 65,
+      "warm_cache_mean_ms": 42,
+      "cache_effectiveness_pct": 83.2,
+      "cache_status": "Effective",
+      "error_count": 0,
+      "iterations": 20
+    },
+    "/api/v2/products/prod-001": {
+      "first_request_ms": 310,
+      "p50_ms": 55,
+      "p95_ms": 210,
+      "p99_ms": 420,
+      "mean_ms": 78,
+      "warm_cache_mean_ms": 52,
+      "cache_effectiveness_pct": 83.2,
+      "cache_status": "Effective",
+      "error_count": 0,
+      "iterations": 20
+    }
+  },
+  "aggregate": {
+    "mean_ms": 71,
+    "p50_ms": 50,
+    "p95_ms": 195,
+    "p99_ms": 370
+  },
+  "config": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "errors": {
+    "failed_count": 0,
+    "failed_endpoints": []
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend/performance/config-backend-only.json b/evals/performance-analyze-module/files/mock-backend/performance/config-backend-only.json
new file mode 100644
index 000000000..12a227b69
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend/performance/config-backend-only.json
@@ -0,0 +1,91 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only config for eval 4",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-01T10:00:00Z",
+    "last_updated": "2026-06-01T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-01T10:00:00Z",
+    "baseline_commit_sha": "abc123",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "grep",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": {
+      "name": null,
+      "path": null,
+      "framework": null,
+      "bundler": null
+    },
+    "backend": {
+      "name": "mock-product-api",
+      "path": ".",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-01T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "product-api",
+    "entry_point": "/api/v2/products",
+    "key_screens": ["/api/v2/products"],
+    "complexity": "Simple",
+    "selected_on": "2026-06-01T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "api-get-products", "url": "/api/v2/products", "description": "List all products", "type": "backend"},
+    {"name": "api-get-product-detail", "url": "/api/v2/products/:id", "description": "Get product with related items", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "Products", "entry_point": "src/handlers/products.rs"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 180, "latest": 180, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 420, "latest": 420, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 120, "latest": 120, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.05, "latest": 0.05, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 35, "latest": 35, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend/src/handlers/products.rs b/evals/performance-analyze-module/files/mock-backend/src/handlers/products.rs
new file mode 100644
index 000000000..e17342cd6
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend/src/handlers/products.rs
@@ -0,0 +1,52 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+use actix_web::{web, HttpResponse};
+use sea_orm::{EntityTrait, DatabaseConnection};
+
+use crate::models::product::{Entity as Product, Model as ProductModel};
+
+// PLANTED ANTI-PATTERN: Missing pagination (Step 7.4)
+// Returns all products without limit/offset
+pub async fn list_products(
+    db: web::Data<DatabaseConnection>,
+) -> HttpResponse {
+    let products: Vec<ProductModel> = Product::find()
+        .all(db.get_ref())
+        .await
+        .unwrap_or_default();
+
+    HttpResponse::Ok().json(products)
+}
+
+// PLANTED ANTI-PATTERN: True N+1 query (Step 7.3)
+// Sequential query in loop — each iteration hits the database
+pub async fn get_product_details(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<String>,
+) -> HttpResponse {
+    let product_id = path.into_inner();
+    let product = Product::find_by_id(&product_id)
+        .one(db.get_ref())
+        .await
+        .unwrap();
+
+    if let Some(p) = product {
+        // N+1: fetch related items one by one
+        let mut related = Vec::new();
+        let related_ids = vec!["rel-1", "rel-2", "rel-3", "rel-4", "rel-5"];
+        for id in related_ids {
+            let item = Product::find_by_id(id)
+                .one(db.get_ref())
+                .await
+                .unwrap();
+            if let Some(r) = item {
+                related.push(r);
+            }
+        }
+        HttpResponse::Ok().json(serde_json::json!({
+            "product": p,
+            "related": related
+        }))
+    } else {
+        HttpResponse::NotFound().finish()
+    }
+}
diff --git a/evals/performance-analyze-module/files/mock-backend/src/models/product.rs b/evals/performance-analyze-module/files/mock-backend/src/models/product.rs
new file mode 100644
index 000000000..c139e357a
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-backend/src/models/product.rs
@@ -0,0 +1,49 @@
+// SYNTHETIC TEST DATA — SeaORM model with false positive for eval
+use sea_orm::entity::prelude::*;
+
+#[derive(Clone, Debug, DeriveEntityModel)]
+#[sea_orm(table_name = "products")]
+pub struct Model {
+    #[sea_orm(primary_key)]
+    pub id: String,
+    pub name: String,
+    pub description: String,
+    pub price: f64,
+    pub category: String,
+    pub vendor_id: String,
+    pub sku: String,
+    pub weight_kg: f64,
+    pub created_at: DateTimeUtc,
+    pub updated_at: DateTimeUtc,
+}
+
+#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
+pub enum Relation {}
+
+impl ActiveModelBehavior for ActiveModel {}
+
+// FALSE POSITIVE: SeaORM load_one is a batch query (single WHERE id IN (...))
+// This is NOT N+1 — it collects all IDs and issues one query
+// Step 9.1-B2 should discard this as false positive
+pub async fn load_product_vendors(
+    db: &DatabaseConnection,
+    products: Vec<Model>,
+) -> Vec<(Model, Option<VendorModel>)> {
+    products
+        .load_one(Vendor, db)
+        .await
+        .unwrap()
+        .into_iter()
+        .zip(products)
+        .map(|(vendor, product)| (product, vendor))
+        .collect()
+}
+
+// Minimal vendor entity for the load_one call
+#[derive(Clone, Debug, DeriveEntityModel)]
+#[sea_orm(table_name = "vendors")]
+pub struct VendorModel {
+    #[sea_orm(primary_key)]
+    pub id: String,
+    pub name: String,
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/package.json b/evals/performance-analyze-module/files/mock-repo/package.json
new file mode 100644
index 000000000..8cdbd2308
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/package.json
@@ -0,0 +1,19 @@
+{
+  "name": "mock-dashboard-app",
+  "version": "1.0.0",
+  "type": "module",
+  "scripts": {
+    "dev": "vite",
+    "build": "tsc && vite build"
+  },
+  "dependencies": {
+    "react": "^18.2.0",
+    "react-dom": "^18.2.0",
+    "@tanstack/react-query": "^5.0.0"
+  },
+  "devDependencies": {
+    "typescript": "^5.0.0",
+    "vite": "^5.0.0",
+    "@vitejs/plugin-react": "^4.0.0"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/performance/baselines/baseline-report.md b/evals/performance-analyze-module/files/mock-repo/performance/baselines/baseline-report.md
new file mode 100644
index 000000000..2cc191074
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/performance/baselines/baseline-report.md
@@ -0,0 +1,37 @@
+<!-- SYNTHETIC TEST DATA — Mock baseline report for eval -->
+# Performance Baseline Report
+
+## Configuration Summary
+- **Capture Date:** 2026-06-01T10:00:00Z
+- **Iterations:** 20
+- **Warmup Runs:** 2
+- **Scenarios Measured:** 1
+
+## Summary Metrics
+
+| Metric | Mean | p50 | p95 | p99 | Unit |
+|---|---|---|---|---|---|
+| **LCP** | 2800 | 2600 | 3200 | 3500 | ms |
+| **FCP** | 1900 | 1800 | 2100 | 2300 | ms |
+| **DOM Interactive** | 4000 | 3800 | 4500 | 4800 | ms |
+| **Total Load Time** | 5200 | 5000 | 5800 | 6200 | ms |
+
+## Per-Scenario Metrics
+
+### /dashboard
+| Metric | Mean | p50 | p95 | p99 | Unit |
+|---|---|---|---|---|---|
+| LCP | 2800 | 2600 | 3200 | 3500 | ms |
+| FCP | 1900 | 1800 | 2100 | 2300 | ms |
+| DOM Interactive | 4000 | 3800 | 4500 | 4800 | ms |
+| Total Load Time | 5200 | 5000 | 5800 | 6200 | ms |
+
+## Resource Timing Breakdown
+
+| Resource | Type | Duration (ms) | Size (KB) | Scenario |
+|---|---|---|---|---|
+| /assets/vendor.js | Script | 1200 | 450 | /dashboard |
+| /assets/app.js | Script | 800 | 280 | /dashboard |
+| /assets/chart-lib.js | Script | 600 | 350 | /dashboard |
+| /api/v2/products | Fetch/XHR | 320 | 12 | /dashboard |
+| /assets/styles.css | Stylesheet | 150 | 45 | /dashboard |
diff --git a/evals/performance-analyze-module/files/mock-repo/performance/baselines/benchmark-results.json b/evals/performance-analyze-module/files/mock-repo/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..e6b819e25
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/performance/baselines/benchmark-results.json
@@ -0,0 +1,42 @@
+{
+  "endpoints": {
+    "/api/v2/products": {
+      "first_request_ms": 250,
+      "p50_ms": 45,
+      "p95_ms": 180,
+      "p99_ms": 320,
+      "mean_ms": 65,
+      "warm_cache_mean_ms": 42,
+      "cache_effectiveness_pct": 83.2,
+      "cache_status": "Effective",
+      "error_count": 0,
+      "iterations": 20
+    },
+    "/api/v2/products/prod-001": {
+      "first_request_ms": 310,
+      "p50_ms": 55,
+      "p95_ms": 210,
+      "p99_ms": 420,
+      "mean_ms": 78,
+      "warm_cache_mean_ms": 52,
+      "cache_effectiveness_pct": 83.2,
+      "cache_status": "Effective",
+      "error_count": 0,
+      "iterations": 20
+    }
+  },
+  "aggregate": {
+    "mean_ms": 71,
+    "p50_ms": 50,
+    "p95_ms": 195,
+    "p99_ms": 370
+  },
+  "config": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "errors": {
+    "failed_count": 0,
+    "failed_endpoints": []
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/performance/config-frontend-only.json b/evals/performance-analyze-module/files/mock-repo/performance/config-frontend-only.json
new file mode 100644
index 000000000..15c8d2c10
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/performance/config-frontend-only.json
@@ -0,0 +1,89 @@
+{
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-01T10:00:00Z",
+    "last_updated": "2026-06-01T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-01T10:00:00Z",
+    "baseline_commit_sha": "abc123",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": false,
+    "analysis_scope": "frontend-only",
+    "backend_endpoint_discovery_method": null,
+    "serena_status": "not-configured",
+    "metric_type": "frontend"
+  },
+  "repositories": {
+    "frontend": {
+      "name": "mock-dashboard-app",
+      "path": ".",
+      "framework": "React",
+      "bundler": "vite"
+    },
+    "backend": {
+      "name": null,
+      "path": null,
+      "framework": null,
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": false,
+      "last_validated": null
+    }
+  },
+  "workflow": {
+    "name": "dashboard",
+    "entry_point": "/dashboard",
+    "key_screens": ["/dashboard"],
+    "complexity": "Simple",
+    "selected_on": "2026-06-01T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "dashboard", "url": "/dashboard", "description": "Main dashboard page", "type": "frontend"}
+  ],
+  "modules": [
+    {"name": "Dashboard", "entry_point": "src/pages/Dashboard.tsx"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": 3.2, "latest": 3.2, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": 2.1, "latest": 2.1, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": 4.5, "latest": 4.5, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": 5.8, "latest": 5.8, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": null, "latest": null, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": null, "latest": null, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": null, "latest": null, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": null, "latest": null, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": null, "latest": null, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": "npm run dev", "source": "package.json", "port": 3000, "command_approved": true, "last_validated": null},
+    "backend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/performance/config-hybrid.json b/evals/performance-analyze-module/files/mock-repo/performance/config-hybrid.json
new file mode 100644
index 000000000..b53f53001
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/performance/config-hybrid.json
@@ -0,0 +1,94 @@
+{
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-01T10:00:00Z",
+    "last_updated": "2026-06-01T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "hybrid",
+    "baseline_timestamp": "2026-06-01T10:00:00Z",
+    "baseline_commit_sha": "abc123",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "full-stack",
+    "backend_endpoint_discovery_method": "frontend-trace",
+    "serena_status": "not-configured",
+    "metric_type": "hybrid"
+  },
+  "repositories": {
+    "frontend": {
+      "name": "mock-dashboard-app",
+      "path": ".",
+      "framework": "React",
+      "bundler": "vite"
+    },
+    "backend": {
+      "name": "mock-product-api",
+      "path": "../mock-backend",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-01T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "dashboard",
+    "entry_point": "/dashboard",
+    "key_screens": ["/dashboard"],
+    "complexity": "Moderate",
+    "selected_on": "2026-06-01T10:00:00Z",
+    "traced_api_endpoints": [
+      {"path": "/api/v2/products", "method": "GET", "frontend_source": "src/hooks/useProducts.ts:25", "backend_handler": "src/handlers/products.rs:list_products", "verified": true},
+      {"path": "/api/v2/products/:id", "method": "GET", "frontend_source": "src/pages/Dashboard.tsx:15", "backend_handler": "src/handlers/products.rs:get_product_details", "verified": true}
+    ]
+  },
+  "scenarios": [
+    {"name": "dashboard", "url": "/dashboard", "description": "Main dashboard page", "type": "frontend"},
+    {"name": "api-get-products", "url": "/api/v2/products", "description": "API called by dashboard", "type": "backend"},
+    {"name": "api-get-product-detail", "url": "/api/v2/products/:id", "description": "API called by dashboard", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "Dashboard", "entry_point": "src/pages/Dashboard.tsx"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": 3.2, "latest": 3.2, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": 2.1, "latest": 2.1, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": 4.5, "latest": 4.5, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": 5.8, "latest": 5.8, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 180, "latest": 180, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 420, "latest": 420, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 120, "latest": 120, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.05, "latest": 0.05, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 35, "latest": 35, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": "npm run dev", "source": "package.json", "port": 3000, "command_approved": true, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/src/components/HeavyChart.tsx b/evals/performance-analyze-module/files/mock-repo/src/components/HeavyChart.tsx
new file mode 100644
index 000000000..2843d957e
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/src/components/HeavyChart.tsx
@@ -0,0 +1,30 @@
+<!-- SYNTHETIC TEST DATA — Large component missing React.memo for eval -->
+import React from 'react';
+
+interface ChartProps {
+  data: Array<{ id: string; name: string; price: number }>;
+}
+
+// PLANTED ANTI-PATTERN: Missing memoization (Step 6.6)
+// This component receives complex props without React.memo
+export function HeavyChart({ data }: ChartProps) {
+  // Expensive render: iterates full dataset on every render
+  const sorted = [...data].sort((a, b) => b.price - a.price);
+  const labels = sorted.map(d => d.name);
+  const values = sorted.map(d => d.price);
+
+  return (
+    <div className="chart-container">
+      <svg viewBox="0 0 400 200">
+        {values.map((v, i) => (
+          <rect key={i} x={i * 40} y={200 - v} width={30} height={v} fill="#4A90D9" />
+        ))}
+      </svg>
+      <div className="labels">
+        {labels.map((l, i) => (
+          <span key={i}>{l}</span>
+        ))}
+      </div>
+    </div>
+  );
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/src/hooks/useProducts.ts b/evals/performance-analyze-module/files/mock-repo/src/hooks/useProducts.ts
new file mode 100644
index 000000000..5300c282a
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/src/hooks/useProducts.ts
@@ -0,0 +1,31 @@
+<!-- SYNTHETIC TEST DATA — Over-fetching hook for eval -->
+import { useQuery } from '@tanstack/react-query';
+
+interface ProductResponse {
+  id: string;
+  name: string;
+  description: string;
+  price: number;
+  inventory: { quantity: number; warehouse_location: string };
+  created_at: string;
+  updated_at: string;
+  category: string;
+  tags: string[];
+  vendor_id: string;
+  sku: string;
+  weight_kg: number;
+}
+
+// PLANTED ANTI-PATTERN: Over-fetching (Step 6.1)
+// Fetches 12 fields but Dashboard only uses id, name, price (3 of 12)
+export function useProducts() {
+  const { data, isLoading } = useQuery({
+    queryKey: ['products'],
+    queryFn: () => fetch('/api/v2/products').then(r => r.json()),
+  });
+
+  return {
+    products: (data || []) as ProductResponse[],
+    isLoading,
+  };
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/src/pages/Dashboard.tsx b/evals/performance-analyze-module/files/mock-repo/src/pages/Dashboard.tsx
new file mode 100644
index 000000000..efaaf710c
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/src/pages/Dashboard.tsx
@@ -0,0 +1,47 @@
+<!-- SYNTHETIC TEST DATA — Dashboard page with planted anti-patterns for eval -->
+import React from 'react';
+import { HeavyChart } from '../components/HeavyChart';
+import { useProducts } from '../hooks/useProducts';
+// PLANTED ANTI-PATTERN: Unused imports (Step 6.5)
+import { formatCurrency, parseTimestamp, deepClone, DEFAULT_PAGE_SIZE } from '../utils/unused-imports';
+
+interface Product {
+  id: string;
+  name: string;
+  price: number;
+}
+
+// PLANTED ANTI-PATTERN: N+1 fetch in loop (Step 6.2)
+async function loadProductDetails(products: Product[]) {
+  const details = [];
+  for (const product of products) {
+    const response = await fetch(`/api/v2/products/${product.id}`);
+    const data = await response.json();
+    details.push(data);
+  }
+  return details;
+}
+
+// PLANTED ANTI-PATTERN: Missing lazy loading (Step 6.9)
+// HeavyChart is imported statically instead of React.lazy
+export default function Dashboard() {
+  const { products } = useProducts();
+
+  React.useEffect(() => {
+    if (products.length > 0) {
+      loadProductDetails(products);
+    }
+  }, [products]);
+
+  return (
+    <div>
+      <h1>Dashboard</h1>
+      <HeavyChart data={products} />
+      <ul>
+        {products.map((p: Product) => (
+          <li key={p.id}>{p.name} - ${p.price}</li>
+        ))}
+      </ul>
+    </div>
+  );
+}
diff --git a/evals/performance-analyze-module/files/mock-repo/src/utils/unused-imports.ts b/evals/performance-analyze-module/files/mock-repo/src/utils/unused-imports.ts
new file mode 100644
index 000000000..411fdb7b8
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/src/utils/unused-imports.ts
@@ -0,0 +1,14 @@
+// SYNTHETIC TEST DATA — Planted unused exports for Step 6.5 eval
+export function formatCurrency(value: number): string {
+  return `$${value.toFixed(2)}`;
+}
+
+export function parseTimestamp(iso: string): Date {
+  return new Date(iso);
+}
+
+export function deepClone<T>(obj: T): T {
+  return JSON.parse(JSON.stringify(obj));
+}
+
+export const DEFAULT_PAGE_SIZE = 25;
diff --git a/evals/performance-analyze-module/files/mock-repo/vite.config.ts b/evals/performance-analyze-module/files/mock-repo/vite.config.ts
new file mode 100644
index 000000000..5327fa038
--- /dev/null
+++ b/evals/performance-analyze-module/files/mock-repo/vite.config.ts
@@ -0,0 +1,7 @@
+import { defineConfig } from 'vite';
+import react from '@vitejs/plugin-react';
+
+export default defineConfig({
+  plugins: [react()],
+  server: { port: 3000 },
+});
diff --git a/evals/performance-analyze-module/files/pre-seeded-progress.json b/evals/performance-analyze-module/files/pre-seeded-progress.json
new file mode 100644
index 000000000..282157ef4
--- /dev/null
+++ b/evals/performance-analyze-module/files/pre-seeded-progress.json
@@ -0,0 +1,38 @@
+{
+  "metric_type": "frontend",
+  "backend_available": false,
+  "initialized_at": "2026-06-01T10:00:00Z",
+  "steps": {
+    "5.1": {"status": "done", "findings": 0},
+    "5.2": {"status": "done", "findings": 0},
+    "5.3": {"status": "done", "findings": 0},
+    "6.1": {"status": "done", "findings": 1},
+    "6.2": {"status": "done", "findings": 1},
+    "6.3": {"status": "done", "findings": 0},
+    "6.4": {"status": "done", "findings": 0},
+    "6.5": {"status": "pending"},
+    "6.6": {"status": "done", "findings": 1},
+    "6.7": {"status": "done", "findings": 0},
+    "6.8": {"status": "done", "findings": 0},
+    "6.9": {"status": "done", "findings": 1},
+    "6.B": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.1": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.2": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.3": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.4": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.5": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.1": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.2": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.3": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.4": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.5": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.6.6": {"status": "not_applicable", "reason": "frontend-only"},
+    "7.7": {"status": "not_applicable", "reason": "frontend-only"},
+    "8.A": {"status": "not_applicable", "reason": "frontend-only"},
+    "8.B": {"status": "not_applicable", "reason": "frontend-only"},
+    "8.C": {"status": "not_applicable", "reason": "frontend-only"},
+    "8.D": {"status": "not_applicable", "reason": "frontend-only"},
+    "8.F": {"status": "not_applicable", "reason": "frontend-only"},
+    "9.7": {"status": "not_applicable", "reason": "frontend-only"}
+  }
+}
diff --git a/evals/performance-baseline/README.md b/evals/performance-baseline/README.md
new file mode 100644
index 000000000..4eaebcfc1
--- /dev/null
+++ b/evals/performance-baseline/README.md
@@ -0,0 +1,56 @@
+# performance-baseline evals
+
+Evaluates the performance-baseline skill's ability to discover workflows from source code, auto-populate configuration (scenarios, modules, workflow), and trace frontend-to-backend API calls.
+
+**Scope limitation:** Baseline capture steps (8-10) require a running application and Playwright browser automation. These cannot be fixture-tested and are out of scope. These evals cover only workflow discovery (Steps 2-4.8) and config writing.
+
+See [IMPROVEMENT-PLAN.md](IMPROVEMENT-PLAN.md) for the hardening roadmap and convention alignment notes.
+
+## Test cases
+
+| ID | Name | Steps | Tests |
+|---|---|---|---|
+| 1 | Frontend route discovery + config write | 2–4.7 | Route extraction from App.tsx router, workflow grouping, user selection, scenario/module auto-population, config write + validation |
+| 2 | Full-stack API tracing | 2–4.8 | Frontend discovery + API call tracing from component files, backend endpoint verification via grep, scenario type tagging, traced_api_endpoints metadata, POST exclusion from scenarios |
+| 3 | Missing config stop path | 2 halt | Skill detects missing config, halts with performance-setup remediation, no config written |
+| 4 | Backend-only discovery | 2–3.6, 4.7 | Grep-based endpoint discovery from products.rs, workflow selection, GET scenarios only, POST excluded |
+| 5 | Skip backend at 4.8.6 | 2–4.8 | Full-stack tracing then user skips backend; analysis_scope downgraded to frontend-only |
+| 6 | Corrupt workflow_selected | 2.0 halt | workflow_selected=true with null workflow fields; skill halts with re-discover prompt |
+
+## Fixtures
+
+- `files/mock-frontend/` — React SPA with 4 routes (Home, Packages, PackageDetail, Settings), react-router-dom, @tanstack/react-query
+- `files/mock-backend/` — Rust/actix-web API with 3 endpoints (list, get, scan vulnerabilities)
+- `files/mock-frontend/performance/config-pre-discovery.json` — Frontend-only config with `workflow_selected: false`
+- `files/mock-frontend/performance/config-pre-discovery-fullstack.json` — Full-stack config with `backend_available: true`
+- `files/mock-backend/performance/config-pre-discovery-backend-only.json` — Backend-only config for eval 4
+- `files/mock-frontend/performance/config-workflow-selected-incomplete.json` — Corrupt workflow seed for eval 6
+
+## Output layout
+
+Eval prompts specify the full output path (`outputs/mock-repo/performance-config.json`) for sandbox isolation:
+
+```
+outputs/
+├── mock-repo/
+│   └── performance-config.json       # evals 1, 2, 3, 5, 6
+├── mock-backend/
+│   └── performance-config.json       # eval 4
+├── config-validation.txt             # config-producing evals
+└── response.md                       # stop-path evals 3, 6
+```
+
+## Running
+
+```
+/sdlc-workflow:run-evals performance-baseline
+```
+
+## Notes
+
+- Evals use grep-based discovery (no Serena) — `serena_status: "not-configured"`
+- No live app, Playwright, Jira, or server startup — all fixture-based
+- Eval 1 tests Steps 2-4.7 (frontend-only discovery and config write)
+- Eval 2 tests Steps 2-4.8 (full-stack discovery with API tracing from frontend components to backend handlers)
+- The POST `/api/v2/packages/:id/vulnerabilities` endpoint is intentionally included as a trace-only endpoint (appears in `traced_api_endpoints` but NOT in `scenarios`) per Step 4.8.4 rules
+- Settings route (`/settings`) is present in the router but excluded from workflow `key_screens` in eval 1
diff --git a/evals/performance-baseline/evals.json b/evals/performance-baseline/evals.json
new file mode 100644
index 000000000..b34448850
--- /dev/null
+++ b/evals/performance-baseline/evals.json
@@ -0,0 +1,135 @@
+{
+  "skill_name": "performance-baseline",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run /sdlc-workflow:performance-baseline on the mock frontend repo. Bootstrap: copy files/mock-frontend/ to outputs/mock-repo/. Copy files/mock-frontend/performance/config-pre-discovery.json to outputs/mock-repo/performance-config.json (rename — do not leave as config-pre-discovery.json). Execute ONLY Steps 2–4.7 (workflow discovery and config write). Do NOT attempt Steps 8-10 (baseline capture — no app running). When the skill reaches the Step 4.4 workflow selection prompt, do NOT call AskUserQuestion — select workflow #3 'Settings' (the /settings route) and continue executing Steps 4.5, 4.6, and 4.7 to completion. Treat outputs/mock-repo/ as the target repository. Write config to outputs/mock-repo/performance-config.json. After config write, run perf-config.py validate --phase baseline against the config path and save output to outputs/config-validation.txt. Do NOT call MCP tools (Serena, Jira). Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "Workflows discovered from App.tsx router, user selects Settings, scenario and module auto-populated for /settings, config written to canonical path and validated.",
+      "files": [
+        "files/mock-frontend/package.json",
+        "files/mock-frontend/src/App.tsx",
+        "files/mock-frontend/src/pages/Packages.tsx",
+        "files/mock-frontend/src/pages/PackageDetail.tsx",
+        "files/mock-frontend/src/pages/Settings.tsx",
+        "files/mock-frontend/src/components/Home.tsx",
+        "files/mock-frontend/performance/config-pre-discovery.json"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/mock-repo/performance-config.json has metadata.workflow_selected set to true",
+        "outputs/mock-repo/performance-config.json scenarios array includes a URL containing '/settings'",
+        "outputs/mock-repo/performance-config.json modules array includes an entry_point value containing 'Settings.tsx'",
+        "outputs/mock-repo/performance-config.json workflow.entry_point is '/settings'",
+        "outputs/mock-repo/performance-config.json workflow.key_screens includes '/settings' and does NOT include '/packages'",
+        "outputs/config-validation.txt contains 'Validation passed' or 'passed'"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Run /sdlc-workflow:performance-baseline on mock repos. Bootstrap: copy files/mock-frontend/ to outputs/mock-repo/ and copy files/mock-backend/ to outputs/mock-backend/. Copy files/mock-frontend/performance/config-pre-discovery-fullstack.json to outputs/mock-repo/performance-config.json. Ensure repositories.backend.path in the config is '../mock-backend' (relative from outputs/mock-repo/). Execute Steps 2–4.8 (discovery + API tracing). Do NOT attempt Steps 8-10. When the skill reaches Step 4.4, do NOT call AskUserQuestion — select workflow #2 'Package Management' and continue. When the skill reaches Step 4.8.6, do NOT call AskUserQuestion — answer 'yes' to continue with the traced endpoints and proceed to write the config. Use grep for backend verification (no Serena). Treat outputs/mock-repo/ as the target repository. Write config to outputs/mock-repo/performance-config.json. After config write, run perf-config.py validate --phase baseline against the config path and save output to outputs/config-validation.txt. Do NOT call MCP tools (Serena, Jira). Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "Frontend workflows discovered, API calls traced from Packages.tsx and PackageDetail.tsx, backend endpoints verified via grep, scenarios tagged with type fields, traced_api_endpoints written, POST mutation excluded from scenarios.",
+      "files": [
+        "files/mock-frontend/package.json",
+        "files/mock-frontend/src/App.tsx",
+        "files/mock-frontend/src/pages/Packages.tsx",
+        "files/mock-frontend/src/pages/PackageDetail.tsx",
+        "files/mock-frontend/src/pages/Settings.tsx",
+        "files/mock-frontend/src/components/Home.tsx",
+        "files/mock-frontend/performance/config-pre-discovery-fullstack.json",
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/products.rs"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/mock-repo/performance-config.json scenarios array contains entries with type 'frontend' AND entries with type 'backend'",
+        "outputs/mock-repo/performance-config.json workflow.traced_api_endpoints includes GET endpoints for '/api/v2/packages' and '/api/v2/packages/:id' with verified true",
+        "outputs/mock-repo/performance-config.json workflow.traced_api_endpoints includes the POST endpoint '/api/v2/packages/:id/vulnerabilities'",
+        "The POST /api/v2/packages/:id/vulnerabilities endpoint appears in traced_api_endpoints but NOT in the scenarios array (trace-only for mutating endpoints per Step 4.8.4)",
+        "outputs/mock-repo/performance-config.json metadata.backend_endpoint_discovery_method is 'frontend-trace'",
+        "outputs/config-validation.txt contains 'Validation passed' or 'passed'"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Run /sdlc-workflow:performance-baseline on the mock frontend repo. Bootstrap: copy files/mock-frontend/ to outputs/mock-repo/ but do NOT copy or create any performance config file (no performance-config.json). The skill should halt at Step 2 when config is missing. Write the halt/remediation message to outputs/response.md. Do NOT write outputs/mock-repo/performance-config.json. Do NOT call MCP tools (Serena, Jira). Do NOT start servers. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill detects missing performance config and halts with remediation directing user to run performance-setup first. No config file written.",
+      "files": [
+        "files/mock-frontend/package.json",
+        "files/mock-frontend/src/App.tsx",
+        "files/mock-frontend/src/pages/Packages.tsx",
+        "files/mock-frontend/src/pages/PackageDetail.tsx",
+        "files/mock-frontend/src/pages/Settings.tsx",
+        "files/mock-frontend/src/components/Home.tsx"
+      ],
+      "assertions": [
+        "outputs/response.md exists",
+        "outputs/response.md mentions 'performance-setup' or '/performance-setup' as the remediation step",
+        "outputs/response.md references missing performance config or performance-config.json",
+        "outputs/mock-repo/performance-config.json does NOT exist"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Run /sdlc-workflow:performance-baseline on the mock backend repo. Bootstrap: copy files/mock-backend/ to outputs/mock-backend/. Copy files/mock-backend/performance/config-pre-discovery-backend-only.json to outputs/mock-backend/performance-config.json. Execute ONLY Steps 2–3.6 and Step 4.7 (backend-only endpoint discovery, workflow selection, config write). Do NOT attempt frontend discovery or Steps 8-10. Use grep for endpoint discovery (no Serena). When the skill reaches the Step 3.3 workflow selection prompt, do NOT call AskUserQuestion — select workflow #1 'Package API' (the /api/v2/packages endpoints) and continue executing Steps 3.4, 3.5, 3.6, and 4.7 to completion. Treat outputs/mock-backend/ as the target repository. Write config to outputs/mock-backend/performance-config.json. After config write, run perf-config.py validate --phase baseline against the config path and save output to outputs/config-validation.txt. Do NOT call MCP tools (Serena, Jira). Do NOT start servers. Do NOT modify files outside outputs/.",
+      "expected_output": "Backend endpoints discovered from products.rs via grep, user selects Package API workflow, GET endpoint scenarios populated, no frontend scenarios, config validated.",
+      "files": [
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/products.rs",
+        "files/mock-backend/performance/config-pre-discovery-backend-only.json"
+      ],
+      "assertions": [
+        "outputs/mock-backend/performance-config.json exists",
+        "outputs/mock-backend/performance-config.json has metadata.workflow_selected set to true",
+        "outputs/mock-backend/performance-config.json metadata.analysis_scope is 'backend-only'",
+        "outputs/mock-backend/performance-config.json scenarios array includes URLs for GET '/api/v2/packages' and GET '/api/v2/packages/:id' or equivalent dynamic path",
+        "outputs/mock-backend/performance-config.json scenarios array does NOT include the POST '/api/v2/packages/:id/vulnerabilities' endpoint",
+        "outputs/mock-backend/performance-config.json modules array has at least 1 entry referencing handlers/products.rs",
+        "outputs/config-validation.txt contains 'Validation passed' or 'passed'"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Run /sdlc-workflow:performance-baseline on mock repos. Bootstrap: copy files/mock-frontend/ to outputs/mock-repo/ and copy files/mock-backend/ to outputs/mock-backend/. Copy files/mock-frontend/performance/config-pre-discovery-fullstack.json to outputs/mock-repo/performance-config.json. Ensure repositories.backend.path is '../mock-backend'. Execute Steps 2–4.8 (discovery + API tracing). Do NOT attempt Steps 8-10. When the skill reaches Step 4.4, do NOT call AskUserQuestion — select workflow #2 'Package Management' and continue. When the skill reaches Step 4.8.6, do NOT call AskUserQuestion — answer 'skip backend' to downgrade to frontend-only analysis, then write the config. Treat outputs/mock-repo/ as the target repository. Write config to outputs/mock-repo/performance-config.json. After config write, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. Do NOT call MCP tools (Serena, Jira). Do NOT start servers. Do NOT modify files outside outputs/.",
+      "expected_output": "Full-stack discovery and tracing complete, user skips backend measurement at Step 4.8.6, analysis_scope downgraded to frontend-only, backend scenarios removed, frontend scenarios retained.",
+      "files": [
+        "files/mock-frontend/package.json",
+        "files/mock-frontend/src/App.tsx",
+        "files/mock-frontend/src/pages/Packages.tsx",
+        "files/mock-frontend/src/pages/PackageDetail.tsx",
+        "files/mock-frontend/src/pages/Settings.tsx",
+        "files/mock-frontend/src/components/Home.tsx",
+        "files/mock-frontend/performance/config-pre-discovery-fullstack.json",
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/products.rs"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/mock-repo/performance-config.json metadata.analysis_scope is 'frontend-only'",
+        "outputs/mock-repo/performance-config.json metadata.metric_type is 'frontend'",
+        "outputs/mock-repo/performance-config.json scenarios array has NO entries with type 'backend'",
+        "outputs/mock-repo/performance-config.json scenarios array includes frontend route URLs for '/packages' and a package detail route",
+        "outputs/config-validation.txt contains 'Validation passed' or 'passed'"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Run /sdlc-workflow:performance-baseline on the mock frontend repo. Bootstrap: copy files/mock-frontend/ to outputs/mock-repo/. Copy files/mock-frontend/performance/config-workflow-selected-incomplete.json to outputs/mock-repo/performance-config.json. This config has metadata.workflow_selected=true but workflow.name, workflow.entry_point, and workflow.key_screens are all null/empty. The skill should halt at Step 2.0 and prompt the user to re-discover or enter workflow details manually. The halt message in outputs/response.md must be prose markdown — explain that workflow_selected is true but workflow fields (name, entry_point, key_screens) are null/empty, and offer two options: reset workflow_selected to false to re-discover, or manually enter workflow details. Do NOT dump raw JSON config into response.md. Do NOT proceed with null workflow data. Do NOT overwrite the config with incomplete workflow fields. Do NOT call MCP tools (Serena, Jira). Do NOT start servers. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill detects workflow_selected=true with missing workflow fields and halts with prompt to reset workflow_selected or enter details manually. No partial config write with null workflow data.",
+      "files": [
+        "files/mock-frontend/package.json",
+        "files/mock-frontend/src/App.tsx",
+        "files/mock-frontend/src/pages/Packages.tsx",
+        "files/mock-frontend/src/pages/PackageDetail.tsx",
+        "files/mock-frontend/src/pages/Settings.tsx",
+        "files/mock-frontend/src/components/Home.tsx",
+        "files/mock-frontend/performance/config-workflow-selected-incomplete.json"
+      ],
+      "assertions": [
+        "outputs/response.md exists",
+        "outputs/response.md mentions workflow_selected or missing workflow data (name, entry_point, or key_screens)",
+        "outputs/response.md offers re-discover or manual entry options (references resetting workflow_selected or entering workflow details)",
+        "outputs/mock-repo/performance-config.json workflow.name is null or empty"
+      ]
+    }
+  ]
+}
diff --git a/evals/performance-baseline/files/mock-backend/Cargo.toml b/evals/performance-baseline/files/mock-backend/Cargo.toml
new file mode 100644
index 000000000..04e25e9b0
--- /dev/null
+++ b/evals/performance-baseline/files/mock-backend/Cargo.toml
@@ -0,0 +1,9 @@
+# SYNTHETIC TEST DATA — Rust actix-web backend for performance-baseline eval testing
+[package]
+name = "mock-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres"] }
diff --git a/evals/performance-baseline/files/mock-backend/performance/config-pre-discovery-backend-only.json b/evals/performance-baseline/files/mock-backend/performance/config-pre-discovery-backend-only.json
new file mode 100644
index 000000000..800102737
--- /dev/null
+++ b/evals/performance-baseline/files/mock-backend/performance/config-pre-discovery-backend-only.json
@@ -0,0 +1,56 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only pre-discovery seed for eval 4",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": false,
+    "baseline_captured": false,
+    "baseline_mode": null,
+    "baseline_timestamp": null,
+    "baseline_commit_sha": null,
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": null,
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": {"name": null, "path": null, "framework": null, "bundler": null},
+    "backend": {"name": "mock-api", "path": ".", "framework": "actix-web", "serena_instance": null, "api_base_path": "/api/v2", "available": true, "last_validated": "2026-06-10T10:00:00Z"}
+  },
+  "workflow": {"name": null, "entry_point": null, "key_screens": [], "complexity": null, "selected_on": null, "traced_api_endpoints": []},
+  "scenarios": [],
+  "modules": [],
+  "baseline_settings": {"iterations": 20, "warmup_runs": 2},
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": null, "latest": null, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": null, "latest": null, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": null, "latest": null, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": null, "latest": null, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": null, "latest": null, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {"bandwidth_mbps": 5, "api_latency_ms": 100, "reflow_cost_ms": 5, "cache_hit_rate": 0.8, "chain_depth": 3, "db_latency_ms": 10},
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": null, "source": null, "port": 8080, "command_approved": false, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-baseline/files/mock-backend/src/handlers/products.rs b/evals/performance-baseline/files/mock-backend/src/handlers/products.rs
new file mode 100644
index 000000000..8d3a35de2
--- /dev/null
+++ b/evals/performance-baseline/files/mock-backend/src/handlers/products.rs
@@ -0,0 +1,18 @@
+// SYNTHETIC TEST DATA — Backend handlers with GET + POST endpoints for tracing eval
+use actix_web::{web, HttpResponse};
+
+#[get("/api/v2/packages")]
+pub async fn list_packages() -> HttpResponse {
+    HttpResponse::Ok().json(vec!["pkg-1", "pkg-2", "pkg-3"])
+}
+
+#[get("/api/v2/packages/{id}")]
+pub async fn get_package(path: web::Path<String>) -> HttpResponse {
+    let id = path.into_inner();
+    HttpResponse::Ok().json(format!("Package {}", id))
+}
+
+#[post("/api/v2/packages/{id}/vulnerabilities")]
+pub async fn scan_vulnerabilities(path: web::Path<String>) -> HttpResponse {
+    HttpResponse::Ok().json("scan started")
+}
diff --git a/evals/performance-baseline/files/mock-frontend/package.json b/evals/performance-baseline/files/mock-frontend/package.json
new file mode 100644
index 000000000..e1c75d808
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/package.json
@@ -0,0 +1,7 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — minimal React SPA for performance-baseline eval testing",
+  "name": "mock-spa",
+  "version": "1.0.0",
+  "scripts": {"dev": "vite"},
+  "dependencies": {"react": "^18.2.0", "react-dom": "^18.2.0", "react-router-dom": "^6.0.0", "@tanstack/react-query": "^5.0.0"}
+}
diff --git a/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery-fullstack.json b/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery-fullstack.json
new file mode 100644
index 000000000..68b973885
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery-fullstack.json
@@ -0,0 +1,56 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — full-stack pre-discovery seed for evals 2 and 5",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": false,
+    "baseline_captured": false,
+    "baseline_mode": null,
+    "baseline_timestamp": null,
+    "baseline_commit_sha": null,
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "full-stack",
+    "backend_endpoint_discovery_method": null,
+    "serena_status": "not-configured",
+    "metric_type": "hybrid"
+  },
+  "repositories": {
+    "frontend": {"name": "mock-spa", "path": ".", "framework": "React", "bundler": "vite"},
+    "backend": {"name": "mock-api", "path": "../mock-backend", "framework": "actix-web", "serena_instance": null, "api_base_path": "/api/v2", "available": true, "last_validated": "2026-06-10T10:00:00Z"}
+  },
+  "workflow": {"name": null, "entry_point": null, "key_screens": [], "complexity": null, "selected_on": null, "traced_api_endpoints": []},
+  "scenarios": [],
+  "modules": [],
+  "baseline_settings": {"iterations": 20, "warmup_runs": 2},
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": null, "latest": null, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": null, "latest": null, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": null, "latest": null, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": null, "latest": null, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": null, "latest": null, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {"bandwidth_mbps": 5, "api_latency_ms": 100, "reflow_cost_ms": 5, "cache_hit_rate": 0.8, "chain_depth": 3, "db_latency_ms": 10},
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": 3000, "command_approved": false, "last_validated": null},
+    "backend": {"command": null, "source": null, "port": 8080, "command_approved": false, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery.json b/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery.json
new file mode 100644
index 000000000..00a07d92c
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/performance/config-pre-discovery.json
@@ -0,0 +1,56 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — frontend-only pre-discovery seed for eval 1",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": false,
+    "baseline_captured": false,
+    "baseline_mode": null,
+    "baseline_timestamp": null,
+    "baseline_commit_sha": null,
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": false,
+    "analysis_scope": "frontend-only",
+    "backend_endpoint_discovery_method": null,
+    "serena_status": "not-configured",
+    "metric_type": "frontend"
+  },
+  "repositories": {
+    "frontend": {"name": "mock-spa", "path": ".", "framework": "React", "bundler": "vite"},
+    "backend": {"name": null, "path": null, "framework": null, "serena_instance": null, "api_base_path": "/api/v2", "available": false, "last_validated": null}
+  },
+  "workflow": {"name": null, "entry_point": null, "key_screens": [], "complexity": null, "selected_on": null, "traced_api_endpoints": []},
+  "scenarios": [],
+  "modules": [],
+  "baseline_settings": {"iterations": 20, "warmup_runs": 2},
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": null, "latest": null, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": null, "latest": null, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": null, "latest": null, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": null, "latest": null, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": null, "latest": null, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {"bandwidth_mbps": 5, "api_latency_ms": 100, "reflow_cost_ms": 5, "cache_hit_rate": 0.8, "chain_depth": 3, "db_latency_ms": 10},
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": 3000, "command_approved": false, "last_validated": null},
+    "backend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-baseline/files/mock-frontend/performance/config-workflow-selected-incomplete.json b/evals/performance-baseline/files/mock-frontend/performance/config-workflow-selected-incomplete.json
new file mode 100644
index 000000000..ea5eacdf3
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/performance/config-workflow-selected-incomplete.json
@@ -0,0 +1,56 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — corrupt workflow_selected seed for eval 6 halt path",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": false,
+    "baseline_mode": null,
+    "baseline_timestamp": null,
+    "baseline_commit_sha": null,
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": false,
+    "analysis_scope": "frontend-only",
+    "backend_endpoint_discovery_method": null,
+    "serena_status": "not-configured",
+    "metric_type": "frontend"
+  },
+  "repositories": {
+    "frontend": {"name": "mock-spa", "path": ".", "framework": "React", "bundler": "vite"},
+    "backend": {"name": null, "path": null, "framework": null, "serena_instance": null, "api_base_path": "/api/v2", "available": false, "last_validated": null}
+  },
+  "workflow": {"name": null, "entry_point": null, "key_screens": [], "complexity": null, "selected_on": null, "traced_api_endpoints": []},
+  "scenarios": [],
+  "modules": [],
+  "baseline_settings": {"iterations": 20, "warmup_runs": 2},
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": null, "latest": null, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": null, "latest": null, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": null, "latest": null, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": null, "latest": null, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": null, "latest": null, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {"bandwidth_mbps": 5, "api_latency_ms": 100, "reflow_cost_ms": 5, "cache_hit_rate": 0.8, "chain_depth": 3, "db_latency_ms": 10},
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": 3000, "command_approved": false, "last_validated": null},
+    "backend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-baseline/files/mock-frontend/src/App.tsx b/evals/performance-baseline/files/mock-frontend/src/App.tsx
new file mode 100644
index 000000000..e15c68b83
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/src/App.tsx
@@ -0,0 +1,23 @@
+<!-- SYNTHETIC TEST DATA — React SPA router with lazy-loaded routes for workflow discovery eval -->
+import React, { lazy, Suspense } from 'react';
+import { BrowserRouter, Routes, Route } from 'react-router-dom';
+import Home from './components/Home';
+
+const Packages = lazy(() => import('./pages/Packages'));
+const PackageDetail = lazy(() => import('./pages/PackageDetail'));
+const Settings = React.lazy(() => import('./pages/Settings'));
+
+export default function App() {
+  return (
+    <BrowserRouter>
+      <Suspense fallback={<div>Loading...</div>}>
+        <Routes>
+          <Route path="/" element={<Home />} />
+          <Route path="/packages" element={<Packages />} />
+          <Route path="/packages/:id" element={<PackageDetail />} />
+          <Route path="/settings" element={<Settings />} />
+        </Routes>
+      </Suspense>
+    </BrowserRouter>
+  );
+}
diff --git a/evals/performance-baseline/files/mock-frontend/src/components/Home.tsx b/evals/performance-baseline/files/mock-frontend/src/components/Home.tsx
new file mode 100644
index 000000000..822384fa3
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/src/components/Home.tsx
@@ -0,0 +1,4 @@
+<!-- SYNTHETIC TEST DATA — Home page component for eval -->
+export default function Home() {
+  return <div>Welcome</div>;
+}
diff --git a/evals/performance-baseline/files/mock-frontend/src/pages/PackageDetail.tsx b/evals/performance-baseline/files/mock-frontend/src/pages/PackageDetail.tsx
new file mode 100644
index 000000000..9df9e664b
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/src/pages/PackageDetail.tsx
@@ -0,0 +1,17 @@
+<!-- SYNTHETIC TEST DATA — Package detail page with GET + POST API calls for tracing eval -->
+import { useParams } from 'react-router-dom';
+import { useQuery } from '@tanstack/react-query';
+
+export default function PackageDetail() {
+  const { id } = useParams();
+  const { data } = useQuery({
+    queryKey: ['package', id],
+    queryFn: () => fetch(`/api/v2/packages/${id}`).then(r => r.json()),
+  });
+
+  async function scanVulnerabilities() {
+    await fetch(`/api/v2/packages/${id}/vulnerabilities`, { method: 'POST' });
+  }
+
+  return <div>{JSON.stringify(data)}<button onClick={scanVulnerabilities}>Scan</button></div>;
+}
diff --git a/evals/performance-baseline/files/mock-frontend/src/pages/Packages.tsx b/evals/performance-baseline/files/mock-frontend/src/pages/Packages.tsx
new file mode 100644
index 000000000..6de2a5b41
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/src/pages/Packages.tsx
@@ -0,0 +1,10 @@
+<!-- SYNTHETIC TEST DATA — Package list page with planted GET API call for tracing eval -->
+import { useQuery } from '@tanstack/react-query';
+
+export default function Packages() {
+  const { data: packages } = useQuery({
+    queryKey: ['packages'],
+    queryFn: () => fetch('/api/v2/packages').then(r => r.json()),
+  });
+  return <div>{JSON.stringify(packages)}</div>;
+}
diff --git a/evals/performance-baseline/files/mock-frontend/src/pages/Settings.tsx b/evals/performance-baseline/files/mock-frontend/src/pages/Settings.tsx
new file mode 100644
index 000000000..aec390179
--- /dev/null
+++ b/evals/performance-baseline/files/mock-frontend/src/pages/Settings.tsx
@@ -0,0 +1,4 @@
+<!-- SYNTHETIC TEST DATA — Settings route for workflow exclusion testing -->
+export default function Settings() {
+  return <div>Settings</div>;
+}
diff --git a/evals/performance-plan-optimization/README.md b/evals/performance-plan-optimization/README.md
new file mode 100644
index 000000000..359f32c1c
--- /dev/null
+++ b/evals/performance-plan-optimization/README.md
@@ -0,0 +1,40 @@
+# performance-plan-optimization evals
+
+Evaluates the optimization planning skill's ability to read analysis reports, apply the decision framework, generate optimization plans, and produce mock Jira artifacts.
+
+See [IMPROVEMENT-PLAN.md](IMPROVEMENT-PLAN.md) for the gate workflow and backlog.
+
+## Test cases
+
+| ID | Name | Tests |
+|---|---|---|
+| 1 | Mixed recommendations with db-migration | 6 findings with mixed dispositions. Verifies plan + Jira mock output, task count range (3–6), db-migration labels, CAUTION safeguards, deferred/rejected documentation, hedged impact language, and layer labels. |
+| 2 | Zero actionable findings | All 3 findings discarded during validation. Skill halts with `outputs/response.md`; no plan or Jira artifacts. |
+| 3 | Unvalidated report | `validation_run` is false. Skill halts at validation check with `outputs/response.md`; no plan or Jira artifacts. |
+
+## Fixtures
+
+- `files/config-fullstack.json` — Full-stack performance config (actix-web + SeaORM backend, `backend.path: ../mock-backend`)
+- `files/analysis-report-mixed.md` — Mock analysis report with 6 findings (mixed dispositions)
+- `files/findings-validation-mixed.json` — Validation artifact with 5 Confirmed + 1 Downgraded
+- `files/analysis-report-zero.md` — Mock analysis report with all findings discarded
+- `files/findings-validation-zero.json` — Validation artifact with 3 Discarded findings
+- `files/findings-validation-unvalidated.json` — Validation artifact with `validation_run: false`
+- `files/conventions-rust.md` — Rust/SeaORM migration conventions for db-migration task generation
+- `files/mock-repo/` — Frontend source stubs for Step 5 grep (F2 N+1, F6 layout thrashing)
+- `files/mock-backend/` — Backend source stubs for Step 5 grep (F1 over-fetch, F3 missing index, F4 deep chain, F5 unused JOIN)
+
+## Running
+
+```
+/sdlc-workflow:run-evals performance-plan-optimization
+```
+
+Evals path: `evals/performance-plan-optimization/evals.json`
+
+## Notes
+
+- All evals mock Jira output to JSON files instead of calling Jira MCP
+- Outputs use the skill's canonical layout under `outputs/mock-repo/performance/`
+- Stop-path evals write halt messages to `outputs/response.md` (graders read files, not chat)
+- db-migration script generation (Step 5.5) is not asserted until gate passes and migration assertions are added
diff --git a/evals/performance-plan-optimization/evals.json b/evals/performance-plan-optimization/evals.json
new file mode 100644
index 000000000..a6bfaa678
--- /dev/null
+++ b/evals/performance-plan-optimization/evals.json
@@ -0,0 +1,106 @@
+{
+  "skill_name": "performance-plan-optimization",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run /sdlc-workflow:performance-plan-optimization. Bootstrap: copy files/mock-repo/ to outputs/mock-repo/ and files/mock-backend/ to outputs/mock-backend/. Copy files/config-fullstack.json to outputs/mock-repo/performance-config.json, files/analysis-report-mixed.md to outputs/mock-repo/performance/analysis/workflow-analysis-report.md, files/findings-validation-mixed.json to outputs/mock-repo/performance/analysis/findings-validation.json, and files/conventions-rust.md to outputs/mock-repo/CONVENTIONS.md. Ensure repositories.backend.path is '../mock-backend' (relative from outputs/mock-repo/). Treat outputs/mock-repo/ as the target repository. Write the optimization plan to outputs/mock-repo/performance/plans/optimization-plan.md. Mock Jira: write Epic to outputs/jira-epic.json and tasks to outputs/jira-tasks.json (JSON array with summary, description, labels fields). Do NOT call Jira MCP, Serena, or any external services. Do NOT modify files outside outputs/.",
+      "expected_output": "An optimization plan with 3–6 tasks covering RECOMMEND/CAUTION findings, db-migration labels for F3, deferred/rejected documentation for F4/F5, and mock Jira output.",
+      "files": [
+        "files/config-fullstack.json",
+        "files/analysis-report-mixed.md",
+        "files/findings-validation-mixed.json",
+        "files/conventions-rust.md",
+        "files/mock-repo/package.json",
+        "files/mock-repo/src/pages/PackageList.tsx",
+        "files/mock-repo/src/components/PackageCard.tsx",
+        "files/mock-backend/Cargo.toml",
+        "files/mock-backend/src/handlers/packages.rs",
+        "files/mock-backend/src/handlers/advisories.rs",
+        "files/mock-backend/migration/src/m20260101_000001_create_advisories.rs"
+      ],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/mock-repo/performance/plans/optimization-plan.md exists",
+        "outputs/jira-tasks.json exists and contains between 3 and 6 task entries",
+        "At least one task in outputs/jira-tasks.json has labels containing both 'performance-optimization' and 'db-migration'",
+        "The CAUTION task (for F3 Missing Index) includes text about safeguards such as feature flag, rollback, or staging validation",
+        "outputs/mock-repo/performance/plans/optimization-plan.md documents at least one deferred or rejected finding with reconsideration conditions",
+        "Impact estimates in outputs/mock-repo/performance/plans/optimization-plan.md use language like 'estimated' or 'up to' rather than stating exact improvement percentages as certain",
+        "outputs/jira-epic.json exists and contains labels including 'performance-optimization'",
+        "outputs/jira-epic.json contains label 'ai-generated-jira'",
+        "Every task in outputs/jira-tasks.json has label 'ai-generated-jira'",
+        "At least one task in outputs/jira-tasks.json has a layer label 'backend' and at least one has 'frontend'",
+        "outputs/mock-repo/performance/plans/optimization-plan.md references at least 4 of the finding IDs F1, F2, F3, F4, F5, and F6 in disposition or task mapping",
+        "At least one task description in outputs/jira-tasks.json includes migration-related content (index DDL, SeaORM migration, or idx_advisories_package_id)"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Run /sdlc-workflow:performance-plan-optimization. Bootstrap: copy files/config-fullstack.json to outputs/mock-repo/performance-config.json, files/analysis-report-zero.md to outputs/mock-repo/performance/analysis/workflow-analysis-report.md, and files/findings-validation-zero.json to outputs/mock-repo/performance/analysis/findings-validation.json. Treat outputs/mock-repo/ as the target repository. Write the halt message to outputs/response.md and do NOT create plan or Jira artifacts. Do NOT call Jira MCP, Serena, or any external services. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill halts with message about all findings discarded, no plan or Jira artifacts created.",
+      "files": [
+        "files/config-fullstack.json",
+        "files/analysis-report-zero.md",
+        "files/findings-validation-zero.json"
+      ],
+      "assertions": [
+        "outputs/response.md exists and mentions discarded findings or zero actionable findings",
+        "outputs/response.md references finding IDs or the validation artifact",
+        "outputs/mock-repo/performance/plans/optimization-plan.md does NOT exist",
+        "outputs/jira-epic.json does NOT exist",
+        "outputs/jira-tasks.json does NOT exist"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Run /sdlc-workflow:performance-plan-optimization. Bootstrap: copy files/config-fullstack.json to outputs/mock-repo/performance-config.json, files/analysis-report-mixed.md to outputs/mock-repo/performance/analysis/workflow-analysis-report.md, and files/findings-validation-unvalidated.json to outputs/mock-repo/performance/analysis/findings-validation.json (note: validation_run is false). Treat outputs/mock-repo/ as the target repository. Write the halt message to outputs/response.md and do NOT create plan or Jira artifacts. Do NOT call Jira MCP, Serena, or any external services. Do NOT modify files outside outputs/.",
+      "expected_output": "Skill halts at validation check because validation_run is false.",
+      "files": [
+        "files/config-fullstack.json",
+        "files/analysis-report-mixed.md",
+        "files/findings-validation-unvalidated.json"
+      ],
+      "assertions": [
+        "outputs/response.md exists",
+        "outputs/response.md mentions validation_run is false, validation not completed, or re-run analyze-module",
+        "outputs/mock-repo/performance/plans/optimization-plan.md does NOT exist",
+        "outputs/jira-epic.json does NOT exist",
+        "outputs/jira-tasks.json does NOT exist"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Run /sdlc-workflow:performance-plan-optimization. Bootstrap: copy files/mock-backend-scale/ to outputs/mock-backend-scale/. Copy files/config-backend-query.json to outputs/mock-backend-scale/performance-config.json, files/analysis-report-query.md to outputs/mock-backend-scale/performance/analysis/workflow-analysis-report.md, files/findings-validation-query.json to outputs/mock-backend-scale/performance/analysis/findings-validation.json, and files/conventions-rust.md to outputs/mock-backend-scale/CONVENTIONS.md. Treat outputs/mock-backend-scale/ as the target repository. Write the optimization plan to outputs/mock-backend-scale/performance/plans/optimization-plan.md. Mock Jira: write Epic to outputs/jira-epic.json and tasks to outputs/jira-tasks.json (JSON array with summary, description, labels fields). Do NOT call Jira MCP, Serena, or any external services. Do NOT modify files outside outputs/. This is a backend-only analysis with query restructuring findings (Cross-Table OR, Late Pagination, Unbounded Iteration, Redundant Indexes, Recursive CTE).",
+      "expected_output": "An optimization plan with 3-5 tasks. The Cross-Table OR task (F1) must follow the Query Restructuring Mandate: Implementation Notes must specify the decomposed pattern (per-entity branches), equivalence constraint, and edge case handling. The task's Test Requirements must include equivalence tests and edge case tests per the template rules. The Redundant Index task (F4) must have db-migration label. The Recursive CTE finding (F5) should be CAUTION or DEFER since it was downgraded.",
+      "files": [
+        "files/config-backend-query.json",
+        "files/analysis-report-query.md",
+        "files/findings-validation-query.json",
+        "files/conventions-rust.md",
+        "files/mock-backend-scale/Cargo.toml",
+        "files/mock-backend-scale/src/lib.rs",
+        "files/mock-backend-scale/src/handlers/mod.rs",
+        "files/mock-backend-scale/src/handlers/search.rs",
+        "files/mock-backend-scale/src/handlers/components.rs",
+        "files/mock-backend-scale/src/handlers/ancestor_walker.rs",
+        "files/mock-backend-scale/src/handlers/deep_service.rs",
+        "files/mock-backend-scale/src/handlers/data_loader.rs",
+        "files/mock-backend-scale/src/models/mod.rs",
+        "files/mock-backend-scale/migration/m001_create_tables.rs",
+        "files/mock-backend-scale/migration/m002_add_indexes.rs"
+      ],
+      "assertions": [
+        "outputs/mock-backend-scale/performance/plans/optimization-plan.md exists",
+        "outputs/jira-tasks.json exists and contains between 3 and 5 task entries",
+        "At least one task in outputs/jira-tasks.json has description mentioning 'decomposed' or 'per-entity' or 'per-branch' (Query Restructuring Mandate point 2)",
+        "At least one task in outputs/jira-tasks.json has description mentioning 'equivalence' or 'same result set' (Query Restructuring Mandate point 4)",
+        "At least one task in outputs/jira-tasks.json has description mentioning 'edge case' or 'all branches fail' or 'single branch' (Query Restructuring Mandate point 5)",
+        "At least one task in outputs/jira-tasks.json has Test Requirements or Acceptance Criteria mentioning 'equivalence' (template rule for query decomposition tasks)",
+        "At least one task in outputs/jira-tasks.json has labels containing both 'performance-optimization' and 'db-migration'",
+        "outputs/jira-epic.json exists and contains labels including 'ai-generated-jira'",
+        "Every task in outputs/jira-tasks.json has label 'ai-generated-jira'",
+        "Every task in outputs/jira-tasks.json has a layer label 'backend'"
+      ]
+    }
+  ]
+}
diff --git a/evals/performance-plan-optimization/files/analysis-report-mixed.md b/evals/performance-plan-optimization/files/analysis-report-mixed.md
new file mode 100644
index 000000000..7b771e0de
--- /dev/null
+++ b/evals/performance-plan-optimization/files/analysis-report-mixed.md
@@ -0,0 +1,335 @@
+<!-- SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION -->
+
+# Performance Analysis Report
+
+**Generated:** 2026-06-09T10:30:00Z
+**Workflow:** package-listing
+**Baseline Date:** 2026-06-08T14:00:00Z
+**Validation Artifact:** `performance/analysis/findings-validation.json`
+**Validation Status:** passed
+
+---
+
+## Workflow Metrics
+
+| Metric | Current (p95) | Target | Status |
+|---|---|---|---|
+| LCP (Largest Contentful Paint) | 3400 ms | 2500 ms | Needs Improvement |
+| FCP (First Contentful Paint) | 2200 ms | 1800 ms | Needs Improvement |
+| DOM Interactive | 4800 ms | 3500 ms | Needs Improvement |
+| Total Load Time | 6100 ms | 4000 ms | Needs Improvement |
+
+---
+
+## Bundle Composition
+
+**Total JavaScript Size:** 1080 KB
+**Third-Party Libraries:** 800 KB (74%)
+**Application Code:** 280 KB (26%)
+
+**Top Third-Party Libraries by Size:**
+
+| Library | Size | Used In |
+|---|---|---|
+| chart.js | 350 KB | /packages/:id |
+| lodash | 120 KB | /packages, /packages/:id |
+| moment.js | 95 KB | /packages |
+
+---
+
+## Finding Validation Summary
+
+**Validation Step:** Step 9.1 re-verified all findings against source code before report generation.
+
+| # | Finding | Anti-Pattern | Step | Disposition | Confidence | Severity | Timeline | Notes |
+|---|---|---|---|---|---|---|---|---|
+| F1 | API response includes 50KB of unused advisory metadata | Over-Fetching | 8.A | Confirmed | Medium | Low | 1-4 hours | Response includes full advisory objects but frontend only uses id and title |
+| F2 | Sequential fetch calls for package details in listing loop | N+1 Frontend Query | 6.3 | Confirmed | High | Low | 1-3 days | 5 sequential fetches in useEffect loop instead of batch endpoint |
+| F3 | Missing index on advisories.package_id column | Missing Index | 7.6.4 | Confirmed | High | High | 1-4 hours | WHERE clause filters on package_id without index; sequential scan on 120K rows |
+| F4 | 3-level deep service chain through advisory resolver | Deep Service Chain | 7.6.2 | Downgraded | Medium | Low | 1-3 days | Chain depth verified but effective query count lower than estimated |
+| F5 | Unused LEFT JOIN on package_metadata table | Unused JOINs | 7.6.5 | Confirmed | Medium | Low | 1-4 hours | JOIN fetches metadata but handler only returns name and version |
+| F6 | DOM reads/writes interleaved in package card render loop | Layout Thrashing | 6.4 | Confirmed | Medium | Low | 0.5-1 day | offsetHeight read followed by style.height write inside map() |
+
+**Validation Statistics:**
+- Findings submitted: 6
+- Confirmed: 5 (83%)
+- Confirmed (Low Confidence): 0 (0%)
+- Downgraded: 1 (17%)
+- Discarded: 0 (0%)
+
+---
+
+## Anti-Pattern Analysis
+
+### Over-Fetching
+
+**Severity:** Low
+**Confidence:** Medium (Grep -- response field analysis)
+**Instances Found:** 1
+**Estimated Impact:** ~50 KB payload reduction per request, estimated up to 12% load time improvement
+
+**Description:**
+The backend API returns full advisory objects in the package listing response, but the frontend only destructures `id` and `title` from each advisory. The remaining fields (description, cvss_score, affected_versions, references, timestamps) are transferred but never rendered.
+
+**Detected Instances:**
+
+1. **src/handlers/packages.rs:19**
+   **Finding ID:** F1
+   ```rust
+   let advisories = advisory::Entity::find()
+       .filter(advisory::Column::PackageId.eq(pkg_id))
+       .all(&db)
+       .await?;
+   // Returns full Advisory model with 12 fields
+   ```
+   **Issue:** Response includes 12 fields per advisory but frontend uses only 2 (id, title). Approx 50KB unused data per listing page.
+   **Recommended Fix:** Create a `AdvisoryBriefDto` with only `id` and `title`, or implement field projection in the query.
+   **Verification Checklist:**
+   - [ ] Confirm frontend destructuring pattern in PackageList.tsx
+   - [ ] Verify no other consumer uses the full advisory fields
+   **Validation Status:** Confirmed
+   **Confidence:** Medium -- "Detection: Grep, Evidence: Response schema vs frontend usage, Risk: Low => Final: Medium"
+   **Severity:** Low
+   **Timeline:** 1-4 hours
+
+---
+
+### N+1 Frontend Query
+
+**Severity:** Low
+**Confidence:** High (Grep -- clear sequential fetch pattern)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 35% improvement in DOM Interactive time by batching 5 sequential requests
+
+**Description:**
+The package listing page fetches individual package details in a useEffect loop, creating 5 sequential network requests where a single batch request would suffice.
+
+**Detected Instances:**
+
+1. **src/pages/PackageList.tsx:21**
+   **Finding ID:** F2
+   ```tsx
+   useEffect(() => {
+     packages.forEach(async (pkg) => {
+       const details = await fetch(`/api/v1/packages/${pkg.id}`);
+       setPackageDetails(prev => [...prev, await details.json()]);
+     });
+   }, [packages]);
+   ```
+   **Issue:** 5 sequential fetch calls in forEach loop. Each call waits for the previous to complete due to state update pattern.
+   **Recommended Fix:** Use `Promise.all()` with a batch endpoint `/api/v1/packages?ids=1,2,3,4,5` or parallelize with `Promise.all(packages.map(...))`.
+   **Verification Checklist:**
+   - [ ] Verify the forEach pattern is not already parallelized
+   - [ ] Check if a batch endpoint exists
+   **Validation Status:** Confirmed
+   **Confidence:** High -- "Detection: Grep, Evidence: Sequential forEach with await, Risk: Low => Final: High"
+   **Severity:** Low
+   **Timeline:** 1-3 days
+
+---
+
+### Missing Database Indexes
+
+**Severity:** High
+**Confidence:** High (Grep -- migration file analysis)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 22% improvement in backend response time (p95); index lookup vs sequential scan on 120K rows
+
+**Description:**
+The `advisories` table is queried with a WHERE clause on `package_id`, but no index exists on that column. This causes PostgreSQL to perform a sequential scan on 120,000 rows.
+
+**Detected Instances:**
+
+1. **Table:** `advisories`
+   **Column:** `package_id`
+   **Table Source:** `migration/src/m20260101_000001_create_advisories.rs`
+   **Used In:** Advisory lookup by package (`src/handlers/advisories.rs:10`)
+   **Query Type:** WHERE filter
+   **Loop Multiplier:** 1 (single query per request)
+   **Finding ID:** F3
+   **Estimated Impact:** Sequential scan on 120,000 rows vs. index lookup
+   **Recommended Fix:**
+   ```sql
+   CREATE INDEX idx_advisories_package_id ON advisories(package_id);
+   ```
+   **Verification Checklist:**
+   - [ ] Verify no existing index covers this column
+   - [ ] Run EXPLAIN ANALYZE on the query before and after
+   **Validation Status:** Confirmed
+   **Confidence:** High -- "Detection: Grep, Evidence: Migration files show no index, Risk: Medium => Final: High"
+   **Severity:** High
+   **Timeline:** 1-4 hours
+
+---
+
+### Deep Service Chain
+
+**Severity:** Low
+**Confidence:** Medium (Grep -- call graph analysis)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 8% improvement in response time by flattening call chain
+
+**Description:**
+The advisory resolution endpoint passes through 3 service layers, each adding a database query. While the chain is real, the effective query count after downgrade is lower than initially estimated.
+
+**Detected Instances:**
+
+1. **src/handlers/advisories.rs:11**
+   **Finding ID:** F4
+   ```rust
+   pub async fn get_advisories(db: &DatabaseConnection, pkg_id: i32) -> Result<Vec<Advisory>> {
+       let pkg = package::Entity::find_by_id(pkg_id).one(&db).await?;
+       let advisories = advisory_service::resolve_advisories(&db, &pkg).await?;
+       let enriched = enrichment_service::enrich(&db, &advisories).await?;
+       Ok(enriched)
+   }
+   ```
+   **Issue:** 3-level chain: handler -> advisory_service -> enrichment_service, each with DB queries
+   **Recommended Fix:** Combine queries into a single JOIN query or use batch loading
+   **Verification Checklist:**
+   - [ ] Trace full call chain to count actual queries
+   - [ ] Verify enrichment queries cannot be batched
+   **Validation Status:** Downgraded
+   **Confidence:** Medium -- "Detection: Grep, Evidence: Call chain verified but effective count lower, Risk: Medium => Final: Medium"
+   **Severity:** Low (downgraded from Medium)
+   **Timeline:** 1-3 days
+
+---
+
+### Unused Table Joins
+
+**Severity:** Low
+**Confidence:** Medium (Grep -- query and response analysis)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 3% improvement in query time by removing unnecessary JOIN
+
+**Description:**
+The package listing query includes a LEFT JOIN on `package_metadata` but the handler only returns `name` and `version` from the packages table. The joined metadata fields are never accessed.
+
+**Detected Instances:**
+
+1. **Endpoint:** GET /api/v1/packages
+   **Handler:** src/handlers/packages.rs:7
+   **Finding ID:** F5
+   **Query:**
+   ```rust
+   let packages = package::Entity::find()
+       .find_also_related(package_metadata::Entity)
+       .all(&db)
+       .await?;
+   // Only pkg.name and pkg.version used in response
+   ```
+   **Unused Join:** `package_metadata` (via find_also_related)
+   **Reason:** No fields from `package_metadata` accessed in SELECT or response schema
+   **Join Type:** LEFT JOIN
+   **Table Size:** 45,000 rows
+   **Index Status:** Indexed on foreign key
+   **Estimated Overhead:** 3ms per query
+   **Call Frequency:** single
+   **Total Impact:** 3ms per request
+   **Recommended Fix:**
+   ```rust
+   let packages = package::Entity::find()
+       .all(&db)
+       .await?;
+   ```
+   **Verification Checklist:**
+   - [ ] Confirm package_metadata fields are not used anywhere in response construction
+   - [ ] Verify no downstream logic depends on the joined data
+   **Validation Status:** Confirmed
+   **Confidence:** Medium -- "Detection: Grep, Evidence: Response construction analysis, Risk: Low => Final: Medium"
+   **Severity:** Low
+   **Timeline:** 1-4 hours
+
+---
+
+### Layout Thrashing
+
+**Severity:** Low
+**Confidence:** Medium (Grep -- DOM read/write pattern)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 40% improvement in render performance for package card list by batching DOM operations
+
+**Description:**
+The package card rendering loop interleaves DOM reads and writes, forcing the browser to perform layout recalculation on each iteration.
+
+**Detected Instances:**
+
+1. **src/components/PackageCard.tsx:20**
+   **Finding ID:** F6
+   ```tsx
+   {packages.map((pkg, i) => {
+     const height = cardRef.current[i]?.offsetHeight; // DOM read
+     if (height && height < 200) {
+       cardRef.current[i].style.height = '200px'; // DOM write
+     }
+     return <PackageCardItem key={pkg.id} package={pkg} />;
+   })}
+   ```
+   **Issue:** `offsetHeight` read followed by `style.height` write inside `map()` loop. Each iteration triggers forced synchronous layout.
+   **Recommended Fix:** Batch all reads first using `requestAnimationFrame` or `ResizeObserver`, then apply writes in a separate pass.
+   **Verification Checklist:**
+   - [ ] Confirm the interleaved read/write pattern exists in production code
+   - [ ] Verify the component renders in a list context
+   **Validation Status:** Confirmed
+   **Confidence:** Medium -- "Detection: Grep, Evidence: Clear read-write interleave in loop, Risk: Low => Final: Medium"
+   **Severity:** Low
+   **Timeline:** 0.5-1 day
+
+---
+
+## Backend Source Code Analysis
+
+**Backend Repository:** package-listing-api (actix-web)
+**Analysis Coverage:** 3 endpoints analyzed
+**Serena Status:** Grep fallback
+
+### Backend Anti-Patterns Detected
+
+See findings F1, F3, F4, F5 above for backend-specific anti-patterns (Over-Fetching, Missing Index, Deep Service Chain, Unused JOINs).
+
+---
+
+## Recommended Optimizations
+
+**Note:** Optimizations are categorized by layer (Frontend / Backend / Integration) when backend analysis is available.
+
+### Tactical Optimizations
+
+| Priority | Optimization | Confidence | Severity | Timeline | Prerequisite | Estimated Impact | Effort |
+|---|---|---|---|---|---|---|---|
+| 1 | F6: Batch DOM reads/writes in PackageCard render loop | Medium | Low | 0.5-1 day | None | Estimated up to 40% render improvement | Low |
+| 2 | F2: Replace sequential fetches with batch/parallel pattern | High | Low | 1-3 days | None | Estimated up to 35% DOM Interactive improvement | Medium |
+| 3 | F3: Add index on advisories.package_id | High | High | 1-4 hours | None | Estimated up to 22% backend p95 improvement | Low |
+| 4 | F1: Create AdvisoryBriefDto for listing endpoint | Medium | Low | 1-4 hours | None | Estimated up to 12% load time improvement | Low |
+| 5 | F4: Flatten advisory resolution service chain | Medium | Low | 1-3 days | F3 | Estimated up to 8% response time improvement | Medium |
+| 6 | F5: Remove unused package_metadata JOIN | Medium | Low | 1-4 hours | None | Estimated up to 3% query time improvement | Low |
+
+### Strategic / Architectural Optimizations
+
+No strategic/architectural optimizations identified -- tactical fixes are sufficient to reach target SLAs.
+
+---
+
+## Executive Summary
+
+**Overall Performance Rating:** Needs Improvement
+
+**Key Findings:**
+- Frontend N+1 fetch pattern causes 5 sequential requests on package listing page
+- Missing database index on advisories.package_id causes sequential scans on 120K rows
+- Layout thrashing in package card rendering degrades render performance
+- Backend over-fetching transfers ~50KB of unused advisory data per request
+
+**Top 3 Optimization Opportunities:**
+1. Layout Thrashing fix (F6) -- Estimated up to 40% render improvement
+2. N+1 Frontend Query fix (F2) -- Estimated up to 35% DOM Interactive improvement
+3. Missing Index fix (F3) -- Estimated up to 22% backend p95 improvement
+
+---
+
+## Next Steps
+
+1. Review this report with the team and prioritize optimizations
+2. Create optimization plan and Jira Epic/Tasks using `/sdlc-workflow:performance-plan-optimization`
+3. After implementing optimizations, re-run `/sdlc-workflow:performance-baseline` to capture new baseline and measure improvements
diff --git a/evals/performance-plan-optimization/files/analysis-report-query.md b/evals/performance-plan-optimization/files/analysis-report-query.md
new file mode 100644
index 000000000..5274127c5
--- /dev/null
+++ b/evals/performance-plan-optimization/files/analysis-report-query.md
@@ -0,0 +1,262 @@
+<!-- SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION -->
+
+# Performance Analysis Report
+
+**Generated:** 2026-06-15T12:00:00Z
+**Workflow:** component-search
+**Baseline Date:** 2026-06-15T10:00:00Z
+**Validation Artifact:** `performance/analysis/findings-validation.json`
+**Validation Status:** passed
+
+---
+
+## Workflow Metrics
+
+| Metric | Current (p95) | Target | Status |
+|---|---|---|---|
+| Response Time (p95) | 35000 ms | 2000 ms | Poor |
+| Response Time (p99) | 60000 ms | 5000 ms | Poor |
+| Throughput | 2 req/s | 50 req/s | Poor |
+| Error Rate | 0.5% | 0.1% | Needs Improvement |
+| DB Query Time (p95) | 30000 ms | 1000 ms | Poor |
+
+---
+
+## Finding Validation Summary
+
+**Validation Step:** Step 9.1 re-verified all findings against source code before report generation.
+
+| # | Finding | Anti-Pattern | Step | Disposition | Confidence | Severity | Timeline | Notes |
+|---|---|---|---|---|---|---|---|---|
+| F1 | Cross-table OR filter defeats GIN index on sbom_node.name | Cross-Table OR Filter | 7.6.7 | Confirmed | High | High | 1-3 days | Bare-value filter generates ILIKE OR across 3 LEFT JOINed entities |
+| F2 | Pagination applied after loading all results into memory | Late Pagination | 7.4.1 | Confirmed | High | High | 1-3 days | paginate_array() after full materialization |
+| F3 | Unbounded loop with 2 DB queries per iteration | Unbounded Query-Driving Iteration | 7.3.2 | Confirmed | High | High | 1-3 days | No size guard on query result, 2N queries |
+| F4 | Duplicate btree index on sbom_node(sbom_id, node_id) | Redundant Database Indexes | 7.6.4.1 | Confirmed | High | Medium | 1-4 hours | 52 GB redundant index identical to PK |
+| F5 | Recursive CTE on 383M-row junction table with depth 50 | Recursive CTE Risk | 7.6.2 | Downgraded | Medium | Medium | 1-3 days | Depth limit exists but generous |
+
+**Validation Statistics:**
+- Findings submitted: 5
+- Confirmed: 4 (80%)
+- Confirmed (Low Confidence): 0 (0%)
+- Downgraded: 1 (20%)
+- Discarded: 0 (0%)
+
+---
+
+## Anti-Pattern Analysis
+
+### Cross-Table OR Filter
+
+**Severity:** High
+**Confidence:** High (Grep — ORM filter composition analysis)
+**Instances Found:** 1
+**Estimated Impact:** Estimated overhead: High — cross-table OR on LEFT JOINed tables typically forces sequential scan, defeating indexes. Actual impact depends on table sizes (verify with EXPLAIN).
+
+**Description:**
+The search handler registers columns from three entities (sbom_node, cpe, qualified_purl) via `q_columns()` and applies a bare-value filter via `filtering_with()`. When `q=openssl` is used without a field qualifier, the filter generates ILIKE OR conditions across ALL string columns from ALL registered entities, including LEFT JOINed tables. PostgreSQL abandons the 12 GB GIN trigram index on `sbom_node.name` because OR spans LEFT JOINed entities, falling back to sequential scans of `sbom_node` (38 GB) and `sbom_package` (31 GB).
+
+**Detected Instances:**
+
+1. **src/handlers/search.rs:31**
+   **Finding ID:** F1
+   ```rust
+   let search_subquery = sbom_node::Entity::find()
+       .join(JoinType::Join, sbom_node::Relation::Package.def())
+       .join(JoinType::LeftJoin, sbom_package::Relation::Purl.def())
+       .join(JoinType::LeftJoin, sbom_package::Relation::Cpe.def())
+       .join(JoinType::LeftJoin, sbom_package_cpe_ref::Relation::Cpe.def())
+       .join(JoinType::LeftJoin, sbom_package_purl_ref::Relation::Purl.def())
+       .select_only()
+       .column(sbom_node::Column::SbomId)
+       .filtering_with(query.q.clone(), q_columns())?
+       .distinct()
+       .into_query();
+   ```
+   **Issue:** `q_columns()` registers columns from sbom_node + cpe + qualified_purl. Bare `q=openssl` produces: `WHERE sbom_node.name ILIKE '%openssl%' OR cpe.vendor ILIKE '%openssl%' OR cpe.product ILIKE '%openssl%' OR ...` across LEFT JOINed tables. Optimizer cannot use GIN index when OR includes columns from different tables.
+   **Recommended Fix:** Split into per-entity queries — one per column set (sbom_node, cpe, qualified_purl) — each using its optimal index. Merge results via UNION DISTINCT or in-application dedup.
+   **Verification Checklist:**
+   - [ ] Verify split queries return same result set as original
+   - [ ] Verify EXPLAIN shows index scan (not seq scan) after fix
+   **Validation Status:** Confirmed
+   **Confidence:** High
+   **Severity:** High
+   **Timeline:** 1-3 days
+
+---
+
+### Late Pagination
+
+**Severity:** High
+**Confidence:** High (Grep — pagination flow analysis)
+**Instances Found:** 1
+**Estimated Impact:** Estimated up to 90% reduction in memory usage and response time for paginated requests
+
+**Description:**
+The component listing endpoint accepts pagination parameters (offset, limit) but applies them via `paginate_array()` after loading and enriching ALL components into memory. All rows are fetched, per-row queries executed, and results collected before slicing to the requested page.
+
+**Detected Instances:**
+
+1. **src/handlers/components.rs:52**
+   **Finding ID:** F2
+   ```rust
+   let result = paginate_array(&enriched, paginated.offset, paginated.limit);
+   ```
+   **Issue:** Pagination applied post-load. All components loaded and enriched (2 queries per component) before slicing.
+   **Recommended Fix:** Push LIMIT/OFFSET into the initial query. Load only the requested page of components before enrichment.
+   **Validation Status:** Confirmed
+   **Confidence:** High
+   **Severity:** High
+   **Timeline:** 1-3 days
+
+---
+
+### Unbounded Query-Driving Iteration
+
+**Severity:** High
+**Confidence:** High (Grep — loop and query analysis)
+**Instances Found:** 1
+**Estimated Impact:** N x 20ms per request, where N is unbounded (could be thousands)
+
+**Description:**
+The component listing handler loads all active components without a size guard and iterates each one, executing 2 DB queries per iteration (detail lookup + vendor filter).
+
+**Detected Instances:**
+
+1. **src/handlers/components.rs:32**
+   **Finding ID:** F3
+   ```rust
+   for component in &all_components {
+       let details = component_detail::Entity::find_by_id(component.id)
+           .one(db.get_ref()).await?;
+       let vendors = vendor::Entity::find()
+           .filter(vendor::Column::ComponentId.eq(component.id))
+           .all(db.get_ref()).await?;
+       // ...
+   }
+   ```
+   **Loop Source:** `component::Entity::find().filter(...).all(db)` — unbounded query result
+   **Guard Check:** absent — no `.take(N)` or `if len > MAX`
+   **Query Count Per Iteration:** 2
+   **Recommended Fix:** Add a size guard and batch the per-item queries.
+   **Validation Status:** Confirmed
+   **Confidence:** High
+   **Severity:** High
+   **Timeline:** 1-3 days
+
+---
+
+### Redundant Database Indexes
+
+**Severity:** Medium
+**Confidence:** High (Grep — migration file analysis)
+**Instances Found:** 1
+**Estimated Impact:** 52 GB disk savings, improved buffer cache efficiency
+
+**Description:**
+The `sbom_node` table has a btree index `idx_sbom_node_sbom_id_node_id` on `(sbom_id, node_id)` that is identical to the primary key `sbom_node_pkey` on the same columns. The duplicate wastes 52 GB of disk and competes for buffer cache space.
+
+**Detected Instances:**
+
+1. **Table:** `sbom_node`
+   **Duplicate Index:** `idx_sbom_node_sbom_id_node_id (sbom_id, node_id)`
+   **Primary Key:** `sbom_node_pkey (sbom_id, node_id)`
+   **Index Source:** `migration/m002_add_indexes.rs:8`
+   **Finding ID:** F4
+   **Estimated Impact:** 52 GB disk savings
+   **Recommended Fix:**
+   ```sql
+   DROP INDEX IF EXISTS idx_sbom_node_sbom_id_node_id;
+   ```
+   **Validation Status:** Confirmed
+   **Confidence:** High
+   **Severity:** Medium
+   **Timeline:** 1-4 hours
+
+---
+
+## Backend Source Code Analysis
+
+**Backend Repository:** analysis-api (actix-web)
+**Analysis Coverage:** 2 endpoints analyzed
+**Serena Status:** Grep fallback
+
+### Backend Anti-Patterns Detected
+
+See findings F1–F5 above for all backend anti-patterns.
+
+### Recursive CTE Risk
+
+**Severity:** Medium
+**Confidence:** Medium (Grep — SQL analysis)
+**Instances Found:** 1
+**Estimated Impact:** Scale risk — performance degrades proportionally with table size
+
+**Description:**
+A recursive CTE walks the `item_relates_to_item` junction table (383M rows) for ancestor resolution. Depth limit is 50, which prevents runaway recursion but is generous for a junction table where each level can fan out significantly.
+
+**Detected Instances:**
+
+1. **src/handlers/ancestor_walker.rs:15**
+   **Finding ID:** F5
+   ```sql
+   WITH RECURSIVE ancestors AS (
+       SELECT child_id, parent_id, 1 AS depth
+       FROM item_relates_to_item WHERE child_id = $1
+       UNION ALL
+       SELECT r.child_id, r.parent_id, a.depth + 1
+       FROM item_relates_to_item r JOIN ancestors a ON r.child_id = a.parent_id
+       WHERE a.depth < 50
+   )
+   SELECT * FROM ancestors;
+   ```
+   **Target Table:** `item_relates_to_item` (junction, 383M rows)
+   **Depth Limit:** 50
+   **Table Pattern:** junction
+   **Recommended Fix:** Reduce depth limit to 10-20, or pre-compute transitive closure for hot paths.
+   **Validation Status:** Downgraded (from High to Medium — depth limit exists)
+   **Confidence:** Medium
+   **Severity:** Medium
+   **Timeline:** 1-3 days
+
+---
+
+## Recommended Optimizations
+
+### Tactical Optimizations
+
+| Priority | Optimization | Confidence | Severity | Timeline | Prerequisite | Estimated Impact | Effort |
+|---|---|---|---|---|---|---|---|
+| 1 | F1: Split cross-table OR into per-entity queries | High | High | 1-3 days | None | Eliminates 69 GB sequential scan | High |
+| 2 | F2: Push pagination into SQL query | High | High | 1-3 days | F3 | Estimated up to 90% memory reduction | Medium |
+| 3 | F3: Add size guard and batch per-item queries | High | High | 1-3 days | None | Eliminates 2N sequential queries | Medium |
+| 4 | F4: Drop redundant index | High | Medium | 1-4 hours | None | 52 GB disk + buffer cache savings | Low |
+| 5 | F5: Reduce recursive CTE depth limit | Medium | Medium | 1-3 days | None | Scale risk mitigation | Medium |
+
+### Strategic / Architectural Optimizations
+
+No strategic optimizations identified — tactical fixes address the primary bottlenecks.
+
+---
+
+## Executive Summary
+
+**Overall Performance Rating:** Poor
+
+**Key Findings:**
+- Cross-table OR filter defeats GIN trigram index, forcing 69 GB sequential scan on bare queries
+- Pagination applied after full materialization — all rows loaded and enriched before slicing
+- Unbounded iteration executes 2N DB queries with no size guard
+- Redundant 52 GB index wastes buffer cache space
+
+**Top 3 Optimization Opportunities:**
+1. Cross-Table OR fix (F1) — eliminates 69 GB sequential scan per bare query
+2. Late Pagination fix (F2) — estimated up to 90% memory reduction
+3. Unbounded Iteration fix (F3) — eliminates 2N sequential query pattern
+
+---
+
+## Next Steps
+
+1. Review this report with the team and prioritize optimizations
+2. Create optimization plan and Jira Epic/Tasks using `/sdlc-workflow:performance-plan-optimization`
+3. After implementing optimizations, re-run `/sdlc-workflow:performance-baseline` to capture new baseline and measure improvements
diff --git a/evals/performance-plan-optimization/files/analysis-report-zero.md b/evals/performance-plan-optimization/files/analysis-report-zero.md
new file mode 100644
index 000000000..76c36ee49
--- /dev/null
+++ b/evals/performance-plan-optimization/files/analysis-report-zero.md
@@ -0,0 +1,93 @@
+<!-- SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION -->
+
+# Performance Analysis Report
+
+**Generated:** 2026-06-09T11:00:00Z
+**Workflow:** package-listing
+**Baseline Date:** 2026-06-08T14:00:00Z
+**Validation Artifact:** `performance/analysis/findings-validation.json`
+**Validation Status:** passed
+
+---
+
+## Workflow Metrics
+
+| Metric | Current (p95) | Target | Status |
+|---|---|---|---|
+| LCP (Largest Contentful Paint) | 2400 ms | 2500 ms | Good |
+| FCP (First Contentful Paint) | 1700 ms | 1800 ms | Good |
+| DOM Interactive | 3300 ms | 3500 ms | Good |
+| Total Load Time | 3800 ms | 4000 ms | Good |
+
+---
+
+## Bundle Composition
+
+**Total JavaScript Size:** 680 KB
+**Third-Party Libraries:** 420 KB (62%)
+**Application Code:** 260 KB (38%)
+
+**Top Third-Party Libraries by Size:**
+
+| Library | Size | Used In |
+|---|---|---|
+| react-dom | 130 KB | /packages, /packages/:id |
+| date-fns | 45 KB | /packages |
+
+---
+
+## Finding Validation Summary
+
+**Validation Step:** Step 9.1 re-verified all findings against source code before report generation.
+
+| # | Finding | Anti-Pattern | Step | Disposition | Confidence | Severity | Timeline | Notes |
+|---|---|---|---|---|---|---|---|---|
+| F1 | API response includes 50KB of unused advisory metadata | Over-Fetching | 8.A | Discarded | Low | Low | 1-4 hours | Source file was refactored since baseline capture |
+| F2 | Unused utility function formatCurrency | Unused Code | 6.5 | Discarded | Low | Low | < 1 hour | Function referenced in test files and storybook |
+| F3 | PackageCard component missing React.memo | Missing Memoization | 6.2 | Discarded | Low | Low | < 1 hour | Component already wrapped in React.memo |
+
+**Validation Statistics:**
+- Findings submitted: 3
+- Confirmed: 0 (0%)
+- Confirmed (Low Confidence): 0 (0%)
+- Downgraded: 0 (0%)
+- Discarded: 3 (100%)
+
+### Discarded Findings (Audit Trail)
+
+| # | Original Claim | Step | File:Line | Discard Reason |
+|---|---|---|---|---|
+| F1 | Over-fetching in advisory response | 8.A | src/handlers/packages.rs:87 | FAILED: code pattern not found at recorded location -- handler refactored |
+| F2 | Unused formatCurrency function | 6.5 | src/utils/formatters.ts:12 | FAILED: function is referenced in test files and storybook |
+| F3 | PackageCard missing memoization | 6.2 | src/components/PackageCard.tsx:15 | FAILED: component already wrapped in React.memo at line 45 |
+
+---
+
+## Anti-Pattern Analysis
+
+No confirmed anti-patterns detected after validation.
+
+---
+
+## Recommended Optimizations
+
+No optimizations recommended -- all findings were discarded during validation.
+
+---
+
+## Executive Summary
+
+**Overall Performance Rating:** Good
+
+**Key Findings:**
+- All 3 initial findings were discarded during validation (source changes, false positives)
+- Current metrics meet all target thresholds
+- No performance issues identified after validation
+
+---
+
+## Next Steps
+
+1. No immediate optimization actions required
+2. Consider re-running analysis after next significant feature addition
+3. Continue monitoring performance baselines with `/sdlc-workflow:performance-baseline`
diff --git a/evals/performance-plan-optimization/files/config-backend-query.json b/evals/performance-plan-optimization/files/config-backend-query.json
new file mode 100644
index 000000000..5a9ab4921
--- /dev/null
+++ b/evals/performance-plan-optimization/files/config-backend-query.json
@@ -0,0 +1,75 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-15T10:00:00Z",
+    "last_updated": "2026-06-15T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "backend",
+    "baseline_timestamp": "2026-06-15T10:00:00Z",
+    "baseline_commit_sha": "a1b2c3d",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "config-scenarios",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "backend": {
+      "name": "analysis-api",
+      "path": ".",
+      "framework": "actix-web",
+      "orm": "SeaORM",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-15T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "component-search",
+    "entry_point": "/api/v2/analysis/component",
+    "key_screens": [],
+    "complexity": "High",
+    "selected_on": "2026-06-15T10:00:00Z"
+  },
+  "scenarios": [
+    {"name": "search-component", "url": "/api/v2/analysis/component?q=openssl", "description": "Search component by name", "type": "backend"},
+    {"name": "list-components", "url": "/api/v2/components", "description": "List components with details", "type": "backend"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "backend": {
+      "response_time_p95": {"baseline": 35000, "latest": 35000, "target": 2000, "unit": "ms"},
+      "response_time_p99": {"baseline": 60000, "latest": 60000, "target": 5000, "unit": "ms"},
+      "throughput": {"baseline": 2, "latest": 2, "target": 50, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.5, "latest": 0.5, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 30000, "latest": 30000, "target": 1000, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-plan-optimization/files/config-fullstack.json b/evals/performance-plan-optimization/files/config-fullstack.json
new file mode 100644
index 000000000..875b102de
--- /dev/null
+++ b/evals/performance-plan-optimization/files/config-fullstack.json
@@ -0,0 +1,117 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-08T14:00:00Z",
+    "last_updated": "2026-06-08T14:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "hybrid",
+    "baseline_timestamp": "2026-06-08T14:00:00Z",
+    "baseline_commit_sha": "f7a2e3c",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "full-stack",
+    "backend_endpoint_discovery_method": "frontend-trace",
+    "serena_status": "not-configured",
+    "metric_type": "hybrid"
+  },
+  "repositories": {
+    "frontend": {
+      "name": "package-listing-ui",
+      "path": ".",
+      "framework": "React",
+      "bundler": "vite"
+    },
+    "backend": {
+      "name": "package-listing-api",
+      "path": "../mock-backend",
+      "framework": "actix-web",
+      "orm": "SeaORM",
+      "serena_instance": null,
+      "api_base_path": "/api/v1",
+      "available": true,
+      "last_validated": "2026-06-08T14:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "package-listing",
+    "entry_point": "/packages",
+    "key_screens": ["/packages", "/packages/:id"],
+    "complexity": "Moderate",
+    "selected_on": "2026-06-08T14:00:00Z",
+    "traced_api_endpoints": [
+      {
+        "path": "/api/v1/packages",
+        "method": "GET",
+        "frontend_source": "src/hooks/usePackages.ts:18",
+        "backend_handler": "src/handlers/packages.rs:list_packages",
+        "verified": true
+      },
+      {
+        "path": "/api/v1/packages/:id",
+        "method": "GET",
+        "frontend_source": "src/pages/PackageList.tsx:21",
+        "backend_handler": "src/handlers/packages.rs:get_package_with_advisories",
+        "verified": true
+      },
+      {
+        "path": "/api/v1/packages/:id/advisories",
+        "method": "GET",
+        "frontend_source": "src/pages/PackageList.tsx:22",
+        "backend_handler": "src/handlers/advisories.rs:get_advisories",
+        "verified": true
+      }
+    ]
+  },
+  "scenarios": [
+    {"name": "package-listing", "url": "/packages", "description": "Package listing page", "type": "frontend"},
+    {"name": "api-list-packages", "url": "/api/v1/packages", "description": "List packages API", "type": "backend"},
+    {"name": "api-get-package", "url": "/api/v1/packages/:id", "description": "Get package detail API", "type": "backend"},
+    {"name": "api-get-advisories", "url": "/api/v1/packages/:id/advisories", "description": "Get advisories API", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "PackageList", "entry_point": "src/pages/PackageList.tsx"},
+    {"name": "PackageDetail", "entry_point": "src/pages/PackageDetail.tsx"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": 3.4, "latest": 3.4, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": 2.2, "latest": 2.2, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": 4.8, "latest": 4.8, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": 6.1, "latest": 6.1, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 210, "latest": 210, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 480, "latest": 480, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 95, "latest": 95, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 0.03, "latest": 0.03, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 42, "latest": 42, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": "npm run dev", "source": "package.json", "port": 3000, "command_approved": true, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-plan-optimization/files/conventions-rust.md b/evals/performance-plan-optimization/files/conventions-rust.md
new file mode 100644
index 000000000..30aa423b2
--- /dev/null
+++ b/evals/performance-plan-optimization/files/conventions-rust.md
@@ -0,0 +1,38 @@
+<!-- SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION -->
+
+# Project Conventions
+
+## General
+
+- Language: Rust (edition 2021)
+- Framework: actix-web 4.x with SeaORM 1.x
+- Database: PostgreSQL 15
+
+## Database Migrations
+
+- Tool: SeaORM Migration
+- Naming: `migration/src/m{YYYYMMDD}_{HHMMSS}_{name}.rs`
+- Index naming: `idx_{table}_{columns}`
+- FK index policy: All foreign keys must have indexes
+- Rollback: Every `up()` must have a matching `down()`
+- Concurrency: Use `IF NOT EXISTS` and `CONCURRENTLY` for production
+- Transaction safety: Wrap multi-statement migrations in explicit transactions
+- Testing: All migrations must pass `cargo test` in the migration crate
+
+## Code Style
+
+- Use `clippy` with default lints
+- Format with `rustfmt`
+- Error handling: Use `anyhow` for application errors, `thiserror` for library errors
+
+## CI Checks
+
+- `cargo fmt --check`
+- `cargo clippy -- -D warnings`
+- `cargo test`
+- `cargo sqlx prepare --check` (for offline query verification)
+
+## Performance Testing
+
+- Backend benchmarks: `cargo bench`
+- Load testing: `wrk -t4 -c100 -d30s`
diff --git a/evals/performance-plan-optimization/files/findings-validation-mixed.json b/evals/performance-plan-optimization/files/findings-validation-mixed.json
new file mode 100644
index 000000000..72d724b24
--- /dev/null
+++ b/evals/performance-plan-optimization/files/findings-validation-mixed.json
@@ -0,0 +1,106 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "schema_version": "1.0",
+  "generated_at": "2026-06-09T10:30:00Z",
+  "workflow": "package-listing",
+  "validation_run": true,
+  "statistics": {
+    "submitted": 6,
+    "confirmed": 5,
+    "confirmed_low_confidence": 0,
+    "downgraded": 1,
+    "discarded": 0
+  },
+  "findings": [
+    {
+      "id": "F1",
+      "anti_pattern": "Over-Fetching",
+      "step": "8.A",
+      "file": "src/handlers/packages.rs",
+      "line": 19,
+      "detection_method": "Grep",
+      "evidence_excerpt": "advisory::Entity::find().filter(...).all(&db) returns 12 fields; frontend uses 2",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "Medium",
+      "severity": "Low",
+      "timeline": "1-4 hours",
+      "reason": "Response schema includes 12 advisory fields; frontend destructures only id and title. ~50KB waste per listing request."
+    },
+    {
+      "id": "F2",
+      "anti_pattern": "N+1 Frontend Query",
+      "step": "6.3",
+      "file": "src/pages/PackageList.tsx",
+      "line": 21,
+      "detection_method": "Grep",
+      "evidence_excerpt": "packages.forEach(async (pkg) => { const details = await fetch(`/api/v1/packages/${pkg.id}`) })",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "Low",
+      "timeline": "1-3 days",
+      "reason": "Sequential forEach with await creates 5 waterfall fetches. No batch endpoint exists. Promise.all or batch endpoint needed."
+    },
+    {
+      "id": "F3",
+      "anti_pattern": "Missing Index",
+      "step": "7.6.4",
+      "file": "src/handlers/advisories.rs",
+      "line": 10,
+      "detection_method": "Grep",
+      "evidence_excerpt": "find_by_id(pkg_id) -- no index found in migration files for advisories.package_id",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "High",
+      "timeline": "1-4 hours",
+      "reason": "Migration file m20260101_000001_create_advisories.rs creates table but defines no index on package_id. WHERE filter on 120K rows triggers sequential scan."
+    },
+    {
+      "id": "F4",
+      "anti_pattern": "Deep Service Chain",
+      "step": "7.6.2",
+      "file": "src/handlers/advisories.rs",
+      "line": 11,
+      "detection_method": "Grep",
+      "evidence_excerpt": "get_advisories -> advisory_service::resolve_advisories -> enrichment_service::enrich (3 levels)",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Downgraded",
+      "confidence": "Medium",
+      "severity": "Low",
+      "timeline": "1-3 days",
+      "reason": "Call chain verified at 3 levels deep. However, effective query count is 4 (not 8 as initially estimated) because enrichment_service uses batch loading for 2 of its 3 queries. Severity downgraded from Medium to Low."
+    },
+    {
+      "id": "F5",
+      "anti_pattern": "Unused JOINs",
+      "step": "7.6.5",
+      "file": "src/handlers/packages.rs",
+      "line": 7,
+      "detection_method": "Grep",
+      "evidence_excerpt": "find_also_related(package_metadata::Entity) -- no metadata fields in response struct",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "Medium",
+      "severity": "Low",
+      "timeline": "1-4 hours",
+      "reason": "LEFT JOIN on package_metadata via find_also_related but response struct PackageListItem has no metadata fields. 3ms overhead per query on 45K row table."
+    },
+    {
+      "id": "F6",
+      "anti_pattern": "Layout Thrashing",
+      "step": "6.4",
+      "file": "src/components/PackageCard.tsx",
+      "line": 20,
+      "detection_method": "Grep",
+      "evidence_excerpt": "offsetHeight read -> style.height write inside map() loop",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "Medium",
+      "severity": "Low",
+      "timeline": "0.5-1 day",
+      "reason": "DOM read (offsetHeight) followed by DOM write (style.height) inside packages.map() loop. Each iteration forces synchronous layout recalculation."
+    }
+  ]
+}
diff --git a/evals/performance-plan-optimization/files/findings-validation-query.json b/evals/performance-plan-optimization/files/findings-validation-query.json
new file mode 100644
index 000000000..dadd9b887
--- /dev/null
+++ b/evals/performance-plan-optimization/files/findings-validation-query.json
@@ -0,0 +1,91 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "schema_version": "1.1",
+  "generated_at": "2026-06-15T12:00:00Z",
+  "workflow": "component-search",
+  "validation_run": true,
+  "statistics": {
+    "submitted": 5,
+    "confirmed": 4,
+    "confirmed_low_confidence": 0,
+    "downgraded": 1,
+    "discarded": 0
+  },
+  "findings": [
+    {
+      "id": "F1",
+      "anti_pattern": "Cross-Table OR Filter",
+      "step": "7.6.7",
+      "file": "src/handlers/search.rs",
+      "line": 31,
+      "detection_method": "Grep",
+      "evidence_excerpt": "sbom_node::Entity.columns().add_columns(cpe::Entity.columns()).add_columns(qualified_purl::Entity.columns()) with filtering_with(query.q, q_columns()) across LEFT JOINed tables",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "High",
+      "timeline": "1-3 days",
+      "reason": "Bare-value filter generates ILIKE OR across sbom_node, cpe, and qualified_purl columns from LEFT JOINed tables. PostgreSQL abandons GIN trigram index on sbom_node.name when OR spans LEFT JOINed entities, forcing sequential scan on 38 GB table."
+    },
+    {
+      "id": "F2",
+      "anti_pattern": "Late Pagination",
+      "step": "7.4.1",
+      "file": "src/handlers/components.rs",
+      "line": 52,
+      "detection_method": "Grep",
+      "evidence_excerpt": "paginate_array(&enriched, paginated.offset, paginated.limit) applied after loading all results into memory",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "High",
+      "timeline": "1-3 days",
+      "reason": "Pagination parameters exist at API layer but paginate_array() applies them after loading and enriching all components into memory. All rows are fetched and processed before slicing."
+    },
+    {
+      "id": "F3",
+      "anti_pattern": "Unbounded Query-Driving Iteration",
+      "step": "7.3.2",
+      "file": "src/handlers/components.rs",
+      "line": 32,
+      "detection_method": "Grep",
+      "evidence_excerpt": "for component in &all_components { component_detail::Entity::find_by_id(component.id).one(db).await? ... vendor::Entity::find().filter(...).all(db).await? }",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "High",
+      "timeline": "1-3 days",
+      "reason": "Loop iterates unbounded query result (no .take() or size guard). Each iteration executes 2 DB queries (find_by_id + vendor filter). Total query count = 2N where N is unbounded."
+    },
+    {
+      "id": "F4",
+      "anti_pattern": "Redundant Database Indexes",
+      "step": "7.6.4.1",
+      "file": "migration/m002_add_indexes.rs",
+      "line": 8,
+      "detection_method": "Grep",
+      "evidence_excerpt": "CREATE INDEX idx_sbom_node_sbom_id_node_id ON sbom_node(sbom_id, node_id) duplicates primary key sbom_node_pkey(sbom_id, node_id)",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "Medium",
+      "timeline": "1-4 hours",
+      "reason": "Btree index idx_sbom_node_sbom_id_node_id has identical column set to sbom_node_pkey. Duplicate index wastes 52 GB disk and competes for buffer cache."
+    },
+    {
+      "id": "F5",
+      "anti_pattern": "Recursive CTE Risk",
+      "step": "7.6.2",
+      "file": "src/handlers/ancestor_walker.rs",
+      "line": 15,
+      "detection_method": "Grep",
+      "evidence_excerpt": "WITH RECURSIVE ancestors AS (...) on item_relates_to_item junction table with depth limit 50",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Downgraded",
+      "confidence": "Medium",
+      "severity": "Medium",
+      "timeline": "1-3 days",
+      "reason": "Recursive CTE on junction table item_relates_to_item (383M rows) has depth limit 50. Depth limit exists but is generous for a junction table. Downgraded from High to Medium because depth limit prevents runaway recursion."
+    }
+  ]
+}
diff --git a/evals/performance-plan-optimization/files/findings-validation-unvalidated.json b/evals/performance-plan-optimization/files/findings-validation-unvalidated.json
new file mode 100644
index 000000000..5c70c2775
--- /dev/null
+++ b/evals/performance-plan-optimization/files/findings-validation-unvalidated.json
@@ -0,0 +1,46 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "schema_version": "1.0",
+  "generated_at": "2026-06-09T09:00:00Z",
+  "workflow": "package-listing",
+  "validation_run": false,
+  "statistics": {
+    "submitted": 2,
+    "confirmed": 2,
+    "confirmed_low_confidence": 0,
+    "downgraded": 0,
+    "discarded": 0
+  },
+  "findings": [
+    {
+      "id": "F1",
+      "anti_pattern": "N+1 Frontend Query",
+      "step": "6.3",
+      "file": "src/pages/PackageList.tsx",
+      "line": 21,
+      "detection_method": "Grep",
+      "evidence_excerpt": "packages.forEach(async (pkg) => { const details = await fetch(...) })",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "Low",
+      "timeline": "1-3 days",
+      "reason": "Sequential forEach with await in useEffect loop. Validation step was not executed -- findings are preliminary."
+    },
+    {
+      "id": "F2",
+      "anti_pattern": "Missing Index",
+      "step": "7.6.4",
+      "file": "src/handlers/advisories.rs",
+      "line": 10,
+      "detection_method": "Grep",
+      "evidence_excerpt": "find_by_id(pkg_id) -- no index on advisories.package_id in migration files",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "PASS"},
+      "disposition": "Confirmed",
+      "confidence": "High",
+      "severity": "High",
+      "timeline": "1-4 hours",
+      "reason": "No index on advisories.package_id found in migration files. Validation step was not executed -- findings are preliminary."
+    }
+  ]
+}
diff --git a/evals/performance-plan-optimization/files/findings-validation-zero.json b/evals/performance-plan-optimization/files/findings-validation-zero.json
new file mode 100644
index 000000000..16393d0f7
--- /dev/null
+++ b/evals/performance-plan-optimization/files/findings-validation-zero.json
@@ -0,0 +1,61 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "schema_version": "1.0",
+  "generated_at": "2026-06-09T11:00:00Z",
+  "workflow": "package-listing",
+  "validation_run": true,
+  "statistics": {
+    "submitted": 3,
+    "confirmed": 0,
+    "confirmed_low_confidence": 0,
+    "downgraded": 0,
+    "discarded": 3
+  },
+  "findings": [
+    {
+      "id": "F1",
+      "anti_pattern": "Over-Fetching",
+      "step": "8.A",
+      "file": "src/handlers/packages.rs",
+      "line": 87,
+      "detection_method": "Grep",
+      "evidence_excerpt": "advisory::Entity::find().filter(...).all(&db)",
+      "checks": {"9.1-B": "FAILED: code pattern not found at recorded location", "9.1-B2": "PASS"},
+      "disposition": "Discarded",
+      "confidence": "Low",
+      "severity": "Low",
+      "timeline": "1-4 hours",
+      "reason": "Source file was refactored since baseline capture. The advisory query at line 87 no longer exists; handler now uses a DTO projection introduced in commit abc1234."
+    },
+    {
+      "id": "F2",
+      "anti_pattern": "Unused Code",
+      "step": "6.5",
+      "file": "src/utils/formatters.ts",
+      "line": 12,
+      "detection_method": "Grep",
+      "evidence_excerpt": "export function formatCurrency(amount: number)",
+      "checks": {"9.1-B": "PASS", "9.1-B2": "FAILED: function is referenced in test files and storybook"},
+      "disposition": "Discarded",
+      "confidence": "Low",
+      "severity": "Low",
+      "timeline": "< 1 hour",
+      "reason": "Function appears unused in production code but is referenced in 3 test files and 1 Storybook story. Removing it would break tests."
+    },
+    {
+      "id": "F3",
+      "anti_pattern": "Missing Memoization",
+      "step": "6.2",
+      "file": "src/components/PackageCard.tsx",
+      "line": 15,
+      "detection_method": "Grep",
+      "evidence_excerpt": "const PackageCard = ({ pkg }: Props) => {",
+      "checks": {"9.1-B": "FAILED: component already wrapped in React.memo", "9.1-B2": "PASS"},
+      "disposition": "Discarded",
+      "confidence": "Low",
+      "severity": "Low",
+      "timeline": "< 1 hour",
+      "reason": "Component is already wrapped in React.memo at line 45 (export default React.memo(PackageCard)). Initial grep missed the memo wrapper at the bottom of the file."
+    }
+  ]
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/Cargo.toml b/evals/performance-plan-optimization/files/mock-backend-scale/Cargo.toml
new file mode 100644
index 000000000..6ea81ab71
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/Cargo.toml
@@ -0,0 +1,14 @@
+[package]
+name = "mock-scale-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+sea-query = "0.30"
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+tokio = { version = "1", features = ["full"] }
+petgraph = "0.6"
+uuid = { version = "1", features = ["v4"] }
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/migration/m001_create_tables.rs b/evals/performance-plan-optimization/files/mock-backend-scale/migration/m001_create_tables.rs
new file mode 100644
index 000000000..62e5069d9
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/migration/m001_create_tables.rs
@@ -0,0 +1,80 @@
+// SYNTHETIC TEST DATA — Migration with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.4.1 — Redundant Index
+//
+// The sbom_node table has a PRIMARY KEY on (sbom_id, node_id) AND a
+// separate btree index on the same columns. The duplicate index wastes
+// disk space and buffer cache.
+
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.create_table(
+            Table::create()
+                .table(SbomNode::Table)
+                .col(ColumnDef::new(SbomNode::SbomId).uuid().not_null())
+                .col(ColumnDef::new(SbomNode::NodeId).string().not_null())
+                .col(ColumnDef::new(SbomNode::Name).string().not_null())
+                .primary_key(Index::create().col(SbomNode::SbomId).col(SbomNode::NodeId))
+                .to_owned(),
+        ).await?;
+
+        // PLANTED: This index duplicates the primary key exactly
+        manager.create_index(
+            Index::create()
+                .name("sbom_node_sbom_id_node_id_idx")
+                .table(SbomNode::Table)
+                .col(SbomNode::SbomId)
+                .col(SbomNode::NodeId)
+                .to_owned(),
+        ).await?;
+
+        // item_relates_to_item — junction table for recursive CTE detection
+        manager.create_table(
+            Table::create()
+                .table(ItemRelatesToItem::Table)
+                .col(ColumnDef::new(ItemRelatesToItem::ParentId).uuid().not_null())
+                .col(ColumnDef::new(ItemRelatesToItem::ChildId).uuid().not_null())
+                .col(ColumnDef::new(ItemRelatesToItem::Relationship).string().not_null())
+                .primary_key(
+                    Index::create()
+                        .col(ItemRelatesToItem::ParentId)
+                        .col(ItemRelatesToItem::ChildId)
+                )
+                .to_owned(),
+        ).await?;
+
+        manager.create_table(
+            Table::create()
+                .table(Component::Table)
+                .col(ColumnDef::new(Component::Id).uuid().not_null().primary_key())
+                .col(ColumnDef::new(Component::Name).string().not_null())
+                .col(ColumnDef::new(Component::Version).string().not_null())
+                .col(ColumnDef::new(Component::CategoryId).uuid().not_null())
+                .col(ColumnDef::new(Component::Active).boolean().not_null().default(true))
+                .to_owned(),
+        ).await?;
+
+        Ok(())
+    }
+
+    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager.drop_table(Table::drop().table(SbomNode::Table).to_owned()).await?;
+        manager.drop_table(Table::drop().table(ItemRelatesToItem::Table).to_owned()).await?;
+        manager.drop_table(Table::drop().table(Component::Table).to_owned()).await?;
+        Ok(())
+    }
+}
+
+#[derive(Iden)]
+enum SbomNode { Table, SbomId, NodeId, Name }
+
+#[derive(Iden)]
+enum ItemRelatesToItem { Table, ParentId, ChildId, Relationship }
+
+#[derive(Iden)]
+enum Component { Table, Id, Name, Version, CategoryId, Active }
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/migration/m002_add_indexes.rs b/evals/performance-plan-optimization/files/mock-backend-scale/migration/m002_add_indexes.rs
new file mode 100644
index 000000000..f38d9904c
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/migration/m002_add_indexes.rs
@@ -0,0 +1,49 @@
+// SYNTHETIC TEST DATA — Valid indexes (non-redundant) to ensure no false positives
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        // Valid: GIN trigram index on sbom_node.name (different type from PK btree)
+        manager.exec_stmt(
+            sea_query::Query::select()
+                .expr(sea_query::Expr::cust(
+                    "CREATE INDEX sbomnodenameginidx ON sbom_node USING gin ((name) gin_trgm_ops)"
+                ))
+                .to_owned(),
+        ).await?;
+
+        // Valid: index on component.category_id (not a duplicate)
+        manager.create_index(
+            Index::create()
+                .name("component_category_id_idx")
+                .table(Component::Table)
+                .col(Component::CategoryId)
+                .to_owned(),
+        ).await?;
+
+        // Valid: index on item_relates_to_item.child_id for reverse lookups
+        manager.create_index(
+            Index::create()
+                .name("item_relates_child_id_idx")
+                .table(ItemRelatesToItem::Table)
+                .col(ItemRelatesToItem::ChildId)
+                .to_owned(),
+        ).await?;
+
+        Ok(())
+    }
+
+    async fn down(&self, _manager: &SchemaManager) -> Result<(), DbErr> {
+        Ok(())
+    }
+}
+
+#[derive(Iden)]
+enum Component { Table, CategoryId }
+
+#[derive(Iden)]
+enum ItemRelatesToItem { Table, ChildId }
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/performance/baselines/benchmark-results.json b/evals/performance-plan-optimization/files/mock-backend-scale/performance/baselines/benchmark-results.json
new file mode 100644
index 000000000..606e80d4e
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/performance/baselines/benchmark-results.json
@@ -0,0 +1,57 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — baseline benchmark for eval 7",
+  "workflow": "analysis-api",
+  "timestamp": "2026-06-18T10:00:00Z",
+  "scenarios": {
+    "search-component": {
+      "url": "/api/v2/analysis/component",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 2500, "p95": 4500, "p99": 30000, "min": 800, "max": 35000},
+        "throughput_rps": 10,
+        "error_rate_pct": 5.0
+      }
+    },
+    "list-components": {
+      "url": "/api/v2/components",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 1200, "p95": 2800, "p99": 5000, "min": 400, "max": 6000},
+        "throughput_rps": 25,
+        "error_rate_pct": 0.5
+      }
+    },
+    "category-search": {
+      "url": "/api/v2/categories/:id/components",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 800, "p95": 1500, "p99": 3000, "min": 200, "max": 4000},
+        "throughput_rps": 40,
+        "error_rate_pct": 0.1
+      }
+    },
+    "graph-load": {
+      "url": "/api/v2/analysis/graph/:id",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 500, "p95": 1200, "p99": 2500, "min": 100, "max": 3000},
+        "throughput_rps": 50,
+        "error_rate_pct": 0.0
+      }
+    },
+    "ancestors": {
+      "url": "/api/v2/components/:id/ancestors",
+      "iterations": 20,
+      "metrics": {
+        "response_time_ms": {"p50": 300, "p95": 800, "p99": 1500, "min": 50, "max": 2000},
+        "throughput_rps": 80,
+        "error_rate_pct": 0.0
+      }
+    }
+  },
+  "aggregate": {
+    "p95_response_time_ms": 4500,
+    "avg_throughput_rps": 41,
+    "avg_error_rate_pct": 1.12
+  }
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/performance/config-backend-only.json b/evals/performance-plan-optimization/files/mock-backend-scale/performance/config-backend-only.json
new file mode 100644
index 000000000..34005f9e4
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/performance/config-backend-only.json
@@ -0,0 +1,98 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — backend-only config for eval 7 (scale-aware detection)",
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-18T10:00:00Z",
+    "last_updated": "2026-06-18T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "cold-start",
+    "baseline_timestamp": "2026-06-18T10:00:00Z",
+    "baseline_commit_sha": "def456",
+    "capture_target": "localhost",
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "backend_endpoint_discovery_method": "grep",
+    "serena_status": "not-configured",
+    "metric_type": "backend"
+  },
+  "repositories": {
+    "frontend": {
+      "name": null,
+      "path": null,
+      "framework": null,
+      "bundler": null
+    },
+    "backend": {
+      "name": "mock-scale-api",
+      "path": ".",
+      "framework": "actix-web",
+      "serena_instance": null,
+      "api_base_path": "/api/v2",
+      "available": true,
+      "last_validated": "2026-06-18T10:00:00Z"
+    }
+  },
+  "workflow": {
+    "name": "analysis-api",
+    "entry_point": "/api/v2/analysis/component",
+    "key_screens": ["/api/v2/analysis/component"],
+    "complexity": "Complex",
+    "selected_on": "2026-06-18T10:00:00Z",
+    "traced_api_endpoints": []
+  },
+  "scenarios": [
+    {"name": "search-component", "url": "/api/v2/analysis/component", "description": "Search components", "type": "backend"},
+    {"name": "list-components", "url": "/api/v2/components", "description": "List components with details", "type": "backend"},
+    {"name": "category-search", "url": "/api/v2/categories/:id/components", "description": "Search in category", "type": "backend"},
+    {"name": "graph-load", "url": "/api/v2/analysis/graph/:id", "description": "Load component graph", "type": "backend"},
+    {"name": "ancestors", "url": "/api/v2/components/:id/ancestors", "description": "Get component ancestors", "type": "backend"}
+  ],
+  "modules": [
+    {"name": "Search", "entry_point": "src/handlers/search.rs"},
+    {"name": "Components", "entry_point": "src/handlers/components.rs"},
+    {"name": "DataLoader", "entry_point": "src/handlers/data_loader.rs"},
+    {"name": "DeepService", "entry_point": "src/handlers/deep_service.rs"},
+    {"name": "AncestorWalker", "entry_point": "src/handlers/ancestor_walker.rs"}
+  ],
+  "baseline_settings": {
+    "iterations": 20,
+    "warmup_runs": 2
+  },
+  "optimization_targets": {
+    "frontend": {
+      "lcp": {"baseline": null, "latest": null, "target": 2.5, "unit": "seconds"},
+      "fcp": {"baseline": null, "latest": null, "target": 1.8, "unit": "seconds"},
+      "dom_interactive": {"baseline": null, "latest": null, "target": 3.5, "unit": "seconds"},
+      "total_load_time": {"baseline": null, "latest": null, "target": 4.0, "unit": "seconds"}
+    },
+    "backend": {
+      "response_time_p95": {"baseline": 4500, "latest": 4500, "target": 200, "unit": "ms"},
+      "response_time_p99": {"baseline": 30000, "latest": 30000, "target": 500, "unit": "ms"},
+      "throughput": {"baseline": 10, "latest": 10, "target": 100, "unit": "req/sec"},
+      "error_rate": {"baseline": 5.0, "latest": 5.0, "target": 0.1, "unit": "%"},
+      "db_query_time_p95": {"baseline": 2000, "latest": 2000, "target": 50, "unit": "ms"}
+    }
+  },
+  "analysis_assumptions": {
+    "bandwidth_mbps": 5,
+    "api_latency_ms": 100,
+    "reflow_cost_ms": 5,
+    "cache_hit_rate": 0.8,
+    "chain_depth": 3,
+    "db_latency_ms": 10
+  },
+  "dev_environment": {
+    "frontend": {"command": null, "source": null, "port": null, "command_approved": false, "last_validated": null},
+    "backend": {"command": "cargo run", "source": "Cargo.toml", "port": 8080, "command_approved": true, "last_validated": null}
+  },
+  "directories": {
+    "baselines": "performance/baselines/",
+    "analysis": "performance/analysis/",
+    "plans": "performance/plans/",
+    "optimization_results": "performance/optimization-results/",
+    "verification": "performance/verification/",
+    "test_data": "performance/test-data/"
+  }
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/ancestor_walker.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/ancestor_walker.rs
new file mode 100644
index 000000000..41206db41
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/ancestor_walker.rs
@@ -0,0 +1,60 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.2 enhancement — Recursive CTE Risk Flagging
+//
+// This handler uses a WITH RECURSIVE query on item_relates_to_item,
+// which is a junction/relationship table (compound PK with 2 FK columns).
+// The depth limit is 50, which the skill should detect as Medium severity
+// (junction table + depth limit present).
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+#[get("/api/v2/components/{id}/ancestors")]
+pub async fn get_ancestors(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+) -> actix_web::Result<impl Responder> {
+    let component_id = path.into_inner();
+
+    let sql = r#"
+WITH RECURSIVE ancestors AS (
+    SELECT
+        p.parent_id,
+        p.child_id,
+        p.relationship,
+        1 AS depth,
+        ARRAY[p.child_id] AS visited
+    FROM item_relates_to_item p
+    WHERE p.child_id = $1
+      AND p.relationship != 'ancestor_of'
+
+    UNION ALL
+
+    SELECT
+        p.parent_id,
+        p.child_id,
+        p.relationship,
+        a.depth + 1,
+        a.visited || p.child_id
+    FROM item_relates_to_item p
+    JOIN ancestors a ON p.child_id = a.parent_id
+    WHERE a.depth < 50
+      AND NOT (p.child_id = ANY(a.visited))
+)
+SELECT DISTINCT parent_id, child_id, relationship
+FROM ancestors
+ORDER BY parent_id
+"#;
+
+    let result = ItemRelation::find_by_statement(Statement::from_sql_and_values(
+        DatabaseBackend::Postgres,
+        sql,
+        [component_id.into()],
+    ))
+    .all(db.get_ref())
+    .await
+    .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(result))
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/components.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/components.rs
new file mode 100644
index 000000000..afdd8b048
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/components.rs
@@ -0,0 +1,72 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.3.2 — Unbounded Query-Driving Iteration
+// PLANTED ANTI-PATTERN: Step 7.4.1 — Late Pagination
+//
+// This handler has two issues:
+// 1. It loads an unbounded result set from the database (no LIMIT, no size guard)
+//    and iterates each item, executing a DB query per item.
+// 2. Pagination parameters exist at the API layer but are applied via
+//    paginate_array() AFTER loading all results into memory.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+use crate::models::{ComponentModel, PaginatedResults, paginate_array};
+
+#[get("/api/v2/components")]
+pub async fn list_components_with_details(
+    db: web::Data<DatabaseConnection>,
+    paginated: web::Query<PaginatedParams>,
+) -> actix_web::Result<impl Responder> {
+    // No LIMIT on this query — loads all matching components
+    let all_components = component::Entity::find()
+        .filter(component::Column::Active.eq(true))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // PLANTED: Unbounded iteration — no .take(N) or size guard
+    // Each iteration triggers a DB query to fetch related data
+    let mut enriched = Vec::new();
+    for component in &all_components {
+        let details = component_detail::Entity::find_by_id(component.id)
+            .one(db.get_ref())
+            .await
+            .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+        let vendors = vendor::Entity::find()
+            .filter(vendor::Column::ComponentId.eq(component.id))
+            .all(db.get_ref())
+            .await
+            .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+        enriched.push(EnrichedComponent {
+            component: component.clone(),
+            details,
+            vendors,
+        });
+    }
+
+    // PLANTED: Late pagination — applied AFTER loading all results
+    let result = paginate_array(&enriched, paginated.offset, paginated.limit);
+
+    Ok(HttpResponse::Ok().json(result))
+}
+
+#[derive(serde::Deserialize)]
+pub struct PaginatedParams {
+    #[serde(default)]
+    pub offset: usize,
+    #[serde(default = "default_limit")]
+    pub limit: usize,
+}
+
+fn default_limit() -> usize { 20 }
+
+#[derive(serde::Serialize, Clone)]
+pub struct EnrichedComponent {
+    pub component: ComponentModel,
+    pub details: Option<component_detail::Model>,
+    pub vendors: Vec<vendor::Model>,
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/data_loader.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/data_loader.rs
new file mode 100644
index 000000000..084ec40ab
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/data_loader.rs
@@ -0,0 +1,45 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.8 — Load-All-Then-Search
+//
+// This handler loads ALL items for a category from the database, then
+// searches the in-memory collection for items matching the user's search
+// term. The search term is known before the query and could be added as
+// a WHERE clause, but instead the code loads everything and filters in
+// memory. This is NOT a graph traversal case — it's a simple linear search.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+use crate::models::ComponentModel;
+
+#[get("/api/v2/categories/{category_id}/components")]
+pub async fn search_components_in_category(
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+    query: web::Query<SearchParams>,
+) -> actix_web::Result<impl Responder> {
+    let category_id = path.into_inner();
+    let search_term = &query.name;
+
+    // Load ALL components for this category — no search filter in query
+    let all_components = component::Entity::find()
+        .filter(component::Column::CategoryId.eq(category_id))
+        .all(db.get_ref())
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    // Search in memory — search_term was available before the query!
+    let matching: Vec<_> = all_components
+        .iter()
+        .filter(|c| c.name.contains(search_term))
+        .cloned()
+        .collect();
+
+    Ok(HttpResponse::Ok().json(matching))
+}
+
+#[derive(serde::Deserialize)]
+pub struct SearchParams {
+    pub name: String,
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/deep_service.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/deep_service.rs
new file mode 100644
index 000000000..4145cd646
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/deep_service.rs
@@ -0,0 +1,78 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.2 enhancement — Chain Depth Auto-Extension
+//
+// This handler delegates through 4 levels of pure delegation before reaching
+// the actual DB query. With chain_depth=3, the skill would stop at level 3
+// and miss the query. The auto-extension rule should detect that each
+// intermediate function is a pure delegation (single call, returns result)
+// and extend the depth to reach the actual query at level 4.
+//
+// Call chain:
+//   get_component_graph (handler, depth 0)
+//     → service.load_graphs(conn, ids) (depth 1)
+//       → self.inner.load_graphs(conn, ids) (depth 2, pure delegation)
+//         → self.load_graphs_inner(conn, ids) (depth 3 = DEFAULT LIMIT, pure delegation)
+//           → self.perform_load(conn, id) (depth 4, ACTUAL QUERY — only reachable with auto-extension)
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use uuid::Uuid;
+
+pub struct GraphService {
+    inner: InnerGraphService,
+}
+
+impl GraphService {
+    pub async fn load_graphs(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        self.inner.load_graphs(conn, ids).await
+    }
+}
+
+pub struct InnerGraphService;
+
+impl InnerGraphService {
+    pub async fn load_graphs(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        self.load_graphs_inner(conn, ids).await
+    }
+
+    async fn load_graphs_inner(&self, conn: &DatabaseConnection, ids: Vec<Uuid>) -> Result<Vec<GraphData>, DbErr> {
+        let mut results = Vec::new();
+        for id in ids {
+            results.push(self.perform_load(conn, id).await?);
+        }
+        Ok(results)
+    }
+
+    async fn perform_load(&self, conn: &DatabaseConnection, id: Uuid) -> Result<GraphData, DbErr> {
+        let nodes = sbom_node::Entity::find()
+            .filter(sbom_node::Column::SbomId.eq(id))
+            .all(conn)
+            .await?;
+
+        let edges = package_relates_to_package::Entity::find()
+            .filter(package_relates_to_package::Column::SbomId.eq(id))
+            .all(conn)
+            .await?;
+
+        Ok(GraphData { nodes, edges })
+    }
+}
+
+pub struct GraphData {
+    pub nodes: Vec<sbom_node::Model>,
+    pub edges: Vec<package_relates_to_package::Model>,
+}
+
+#[get("/api/v2/analysis/graph/{id}")]
+pub async fn get_component_graph(
+    service: web::Data<GraphService>,
+    db: web::Data<DatabaseConnection>,
+    path: web::Path<Uuid>,
+) -> actix_web::Result<impl Responder> {
+    let id = path.into_inner();
+    let graphs = service.load_graphs(db.get_ref(), vec![id])
+        .await
+        .map_err(|e| actix_web::error::ErrorInternalServerError(e))?;
+
+    Ok(HttpResponse::Ok().json(graphs.len()))
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/mod.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/mod.rs
new file mode 100644
index 000000000..87574e6f5
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/mod.rs
@@ -0,0 +1,6 @@
+// SYNTHETIC TEST DATA — Handler module for scale detection eval
+pub mod search;
+pub mod data_loader;
+pub mod components;
+pub mod deep_service;
+pub mod ancestor_walker;
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/search.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/search.rs
new file mode 100644
index 000000000..ca2d5f933
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/handlers/search.rs
@@ -0,0 +1,46 @@
+// SYNTHETIC TEST DATA — Backend handler with planted anti-patterns for eval
+// PLANTED ANTI-PATTERN: Step 7.6.7 — Cross-Table OR Filter
+//
+// This handler builds a search query that registers columns from multiple
+// entities (sbom_node, cpe, qualified_purl) and applies a bare-value filter
+// via filtering_with(). When the user passes q=openssl without a field
+// qualifier, the filter generates ILIKE OR conditions across ALL string
+// columns from ALL registered entities, including LEFT JOINed tables.
+// This defeats index usage on sbom_node.name because PostgreSQL cannot
+// use the GIN trigram index when OR spans LEFT JOINed tables.
+
+use actix_web::{get, web, HttpResponse, Responder};
+use sea_orm::*;
+use sea_query::JoinType;
+
+use crate::models::{SbomNodeModel, CpeModel, PaginatedResults, paginate_array};
+
+fn q_columns() -> Columns {
+    sbom_node::Entity
+        .columns()
+        .add_columns(cpe::Entity.columns())
+        .add_columns(qualified_purl::Entity.columns())
+}
+
+#[get("/api/v2/analysis/component")]
+pub async fn search_component(
+    db: web::Data<DatabaseConnection>,
+    query: web::Query<SearchQuery>,
+    paginated: web::Query<Paginated>,
+) -> actix_web::Result<impl Responder> {
+    let search_subquery = sbom_node::Entity::find()
+        .join(JoinType::Join, sbom_node::Relation::Package.def())
+        .join(JoinType::LeftJoin, sbom_package::Relation::Purl.def())
+        .join(JoinType::LeftJoin, sbom_package::Relation::Cpe.def())
+        .join(JoinType::LeftJoin, sbom_package_cpe_ref::Relation::Cpe.def())
+        .join(JoinType::LeftJoin, sbom_package_purl_ref::Relation::Purl.def())
+        .select_only()
+        .column(sbom_node::Column::SbomId)
+        .filtering_with(query.q.clone(), q_columns())?
+        .distinct()
+        .into_query();
+
+    let results = load_all_matching(db.get_ref(), search_subquery).await?;
+
+    Ok(HttpResponse::Ok().json(results))
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/lib.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/lib.rs
new file mode 100644
index 000000000..3914c2089
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/lib.rs
@@ -0,0 +1,3 @@
+// SYNTHETIC TEST DATA — Scale-aware detection eval fixture
+pub mod handlers;
+pub mod models;
diff --git a/evals/performance-plan-optimization/files/mock-backend-scale/src/models/mod.rs b/evals/performance-plan-optimization/files/mock-backend-scale/src/models/mod.rs
new file mode 100644
index 000000000..568f99ce1
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend-scale/src/models/mod.rs
@@ -0,0 +1,65 @@
+// SYNTHETIC TEST DATA — Model stubs for eval fixture
+use sea_orm::entity::prelude::*;
+use serde::{Deserialize, Serialize};
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "component")]
+pub struct ComponentModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub name: String,
+    pub version: String,
+    pub sbom_id: Uuid,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "sbom_node")]
+pub struct SbomNodeModel {
+    #[sea_orm(primary_key)]
+    pub sbom_id: Uuid,
+    #[sea_orm(primary_key)]
+    pub node_id: String,
+    pub name: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "cpe")]
+pub struct CpeModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub vendor: String,
+    pub product: String,
+    pub version: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "category")]
+pub struct CategoryModel {
+    #[sea_orm(primary_key)]
+    pub id: Uuid,
+    pub name: String,
+}
+
+#[derive(Clone, Debug, PartialEq, DeriveEntityModel, Serialize, Deserialize)]
+#[sea_orm(table_name = "item_relates_to_item")]
+pub struct ItemRelationModel {
+    #[sea_orm(primary_key)]
+    pub parent_id: Uuid,
+    #[sea_orm(primary_key)]
+    pub child_id: Uuid,
+    pub relationship: String,
+}
+
+pub struct PaginatedResults<T> {
+    pub items: Vec<T>,
+    pub total: usize,
+}
+
+pub fn paginate_array<T: Clone>(items: &[T], offset: usize, limit: usize) -> PaginatedResults<T> {
+    let total = items.len();
+    let end = (offset + limit).min(total);
+    PaginatedResults {
+        items: items[offset..end].to_vec(),
+        total,
+    }
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend/Cargo.toml b/evals/performance-plan-optimization/files/mock-backend/Cargo.toml
new file mode 100644
index 000000000..8e7878605
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend/Cargo.toml
@@ -0,0 +1,12 @@
+# SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION
+[package]
+name = "package-listing-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres", "runtime-tokio-native-tls"] }
+serde = { version = "1", features = ["derive"] }
+serde_json = "1"
+tokio = { version = "1", features = ["full"] }
diff --git a/evals/performance-plan-optimization/files/mock-backend/migration/src/m20260101_000001_create_advisories.rs b/evals/performance-plan-optimization/files/mock-backend/migration/src/m20260101_000001_create_advisories.rs
new file mode 100644
index 000000000..74c1a21e9
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend/migration/src/m20260101_000001_create_advisories.rs
@@ -0,0 +1,42 @@
+// SYNTHETIC TEST DATA — SeaORM migration without index on package_id (F3)
+use sea_orm_migration::prelude::*;
+
+#[derive(DeriveMigrationName)]
+pub struct Migration;
+
+#[async_trait::async_trait]
+impl MigrationTrait for Migration {
+    async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager
+            .create_table(
+                Table::create()
+                    .table(Advisories::Table)
+                    .if_not_exists()
+                    .col(
+                        ColumnDef::new(Advisories::Id)
+                            .integer()
+                            .not_null()
+                            .auto_increment()
+                            .primary_key(),
+                    )
+                    .col(ColumnDef::new(Advisories::PackageId).integer().not_null())
+                    .col(ColumnDef::new(Advisories::Title).string().not_null())
+                    .to_owned(),
+            )
+            .await
+    }
+
+    async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {
+        manager
+            .drop_table(Table::drop().table(Advisories::Table).to_owned())
+            .await
+    }
+}
+
+#[derive(DeriveIden)]
+enum Advisories {
+    Table,
+    Id,
+    PackageId,
+    Title,
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend/src/handlers/advisories.rs b/evals/performance-plan-optimization/files/mock-backend/src/handlers/advisories.rs
new file mode 100644
index 000000000..2263397e9
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend/src/handlers/advisories.rs
@@ -0,0 +1,48 @@
+// SYNTHETIC TEST DATA — Advisory handler with missing index query (F3) and deep chain (F4)
+use sea_orm::*;
+
+pub async fn get_advisories(
+    db: &DatabaseConnection,
+    pkg_id: i32,
+) -> Result<Vec<Advisory>, DbErr> {
+    // F3: Missing Index — WHERE filter on package_id without index
+    // F4: Deep Service Chain — 3-level handler -> service -> enrichment
+    let pkg = package::Entity::find_by_id(pkg_id).one(&db).await?;
+    let advisories = advisory_service::resolve_advisories(&db, &pkg).await?;
+    let enriched = enrichment_service::enrich(&db, &advisories).await?;
+    Ok(enriched)
+}
+
+struct Advisory;
+mod package {
+    pub mod Entity {
+        pub fn find_by_id(_id: i32) -> FindByIdBuilder {
+            FindByIdBuilder
+        }
+    }
+}
+mod advisory_service {
+    use super::*;
+    pub async fn resolve_advisories(
+        _db: &DatabaseConnection,
+        _pkg: &Option<PackageModel>,
+    ) -> Result<Vec<Advisory>, DbErr> {
+        Ok(vec![])
+    }
+}
+mod enrichment_service {
+    use super::*;
+    pub async fn enrich(
+        _db: &DatabaseConnection,
+        _advisories: &Vec<Advisory>,
+    ) -> Result<Vec<Advisory>, DbErr> {
+        Ok(vec![])
+    }
+}
+struct PackageModel;
+struct FindByIdBuilder;
+impl FindByIdBuilder {
+    async fn one(self, _db: &DatabaseConnection) -> Result<Option<PackageModel>, DbErr> {
+        Ok(None)
+    }
+}
diff --git a/evals/performance-plan-optimization/files/mock-backend/src/handlers/packages.rs b/evals/performance-plan-optimization/files/mock-backend/src/handlers/packages.rs
new file mode 100644
index 000000000..d38188bd6
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-backend/src/handlers/packages.rs
@@ -0,0 +1,25 @@
+// SYNTHETIC TEST DATA — Backend handlers with over-fetching (F1) and unused JOIN (F5)
+use sea_orm::*;
+
+pub async fn list_packages(db: &DatabaseConnection) -> Result<Vec<PackageModel>, DbErr> {
+    // F5: Unused LEFT JOIN — handler only returns name and version from packages table
+    let packages = package::Entity::find()
+        .find_also_related(package_metadata::Entity)
+        .all(db)
+        .await?;
+
+    Ok(packages.into_iter().map(|(pkg, _meta)| pkg).collect())
+}
+
+pub async fn get_package_with_advisories(
+    db: &DatabaseConnection,
+    pkg_id: i32,
+) -> Result<Vec<AdvisoryModel>, DbErr> {
+    // F1: Over-Fetching — returns full Advisory model with 12 fields
+    let advisories = advisory::Entity::find()
+        .filter(advisory::Column::PackageId.eq(pkg_id))
+        .all(db)
+        .await?;
+
+    Ok(advisories)
+}
diff --git a/evals/performance-plan-optimization/files/mock-repo/package.json b/evals/performance-plan-optimization/files/mock-repo/package.json
new file mode 100644
index 000000000..553290507
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-repo/package.json
@@ -0,0 +1,10 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — DO NOT USE IN PRODUCTION",
+  "name": "package-listing-ui",
+  "version": "0.1.0",
+  "private": true,
+  "dependencies": {
+    "react": "^18.2.0",
+    "react-dom": "^18.2.0"
+  }
+}
diff --git a/evals/performance-plan-optimization/files/mock-repo/src/components/PackageCard.tsx b/evals/performance-plan-optimization/files/mock-repo/src/components/PackageCard.tsx
new file mode 100644
index 000000000..5c3052526
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-repo/src/components/PackageCard.tsx
@@ -0,0 +1,32 @@
+// SYNTHETIC TEST DATA — PackageCard with planted layout thrashing (F6)
+import React, { useRef } from 'react';
+
+interface Package {
+  id: number;
+  name: string;
+}
+
+interface PackageCardProps {
+  packages: Package[];
+}
+
+export function PackageCard({ packages }: PackageCardProps) {
+  const cardRef = useRef<(HTMLDivElement | null)[]>([]);
+
+  return (
+    <div className="package-grid">
+      {packages.map((pkg, i) => {
+        // F6: Layout Thrashing — DOM read/write interleaved in map()
+        const height = cardRef.current[i]?.offsetHeight;
+        if (height && height < 200) {
+          cardRef.current[i]!.style.height = '200px';
+        }
+        return (
+          <div key={pkg.id} ref={(el) => (cardRef.current[i] = el)}>
+            {pkg.name}
+          </div>
+        );
+      })}
+    </div>
+  );
+}
diff --git a/evals/performance-plan-optimization/files/mock-repo/src/pages/PackageList.tsx b/evals/performance-plan-optimization/files/mock-repo/src/pages/PackageList.tsx
new file mode 100644
index 000000000..a36f920db
--- /dev/null
+++ b/evals/performance-plan-optimization/files/mock-repo/src/pages/PackageList.tsx
@@ -0,0 +1,37 @@
+// SYNTHETIC TEST DATA — PackageList with planted N+1 fetch pattern (F2)
+import React, { useEffect, useState } from 'react';
+
+interface Package {
+  id: number;
+  name: string;
+}
+
+export default function PackageList() {
+  const [packages, setPackages] = useState<Package[]>([]);
+  const [packageDetails, setPackageDetails] = useState<unknown[]>([]);
+
+  useEffect(() => {
+    fetch('/api/v1/packages')
+      .then((res) => res.json())
+      .then(setPackages);
+  }, []);
+
+  // F2: N+1 Frontend Query — sequential fetches in forEach loop
+  useEffect(() => {
+    packages.forEach(async (pkg) => {
+      const details = await fetch(`/api/v1/packages/${pkg.id}`);
+      setPackageDetails((prev) => [...prev, await details.json()]);
+    });
+  }, [packages]);
+
+  return (
+    <div>
+      <h1>Packages</h1>
+      <ul>
+        {packageDetails.map((detail, index) => (
+          <li key={index}>{JSON.stringify(detail)}</li>
+        ))}
+      </ul>
+    </div>
+  );
+}
diff --git a/evals/performance-setup/README.md b/evals/performance-setup/README.md
new file mode 100644
index 000000000..90c5222e6
--- /dev/null
+++ b/evals/performance-setup/README.md
@@ -0,0 +1,36 @@
+# performance-setup evals
+
+Evaluates the performance setup skill's ability to detect project architecture, configure analysis scope, handle Serena discovery, and produce a valid performance config.
+
+## Test cases
+
+| ID | Name | Tests |
+|---|---|---|
+| 1 | Frontend-only greenfield | Architecture 3, no Serena, CONVENTIONS.md missing warning, frontend-only scope |
+| 2 | Full-stack monorepo + Serena | Architecture 1, actix-web detection, Serena onboarded, hybrid metrics |
+| 3 | Separate repos, no Serena | Architecture 2, manual express entry, cross-repo paths, grep-based fallback |
+| 4 | Backend-only | Architecture 4, backend-only scope, no frontend repository |
+| 5 | Serena skip | Serena discovered but not onboarded, user skips, serena_status='skipped' |
+
+## Fixtures
+
+- `files/mock-frontend-next/` — Minimal Next.js project (package.json, next.config.js, page.tsx)
+- `files/mock-backend-rust/` — Rust/actix-web backend with sea-orm (strong detection indicators)
+- `files/mock-backend-node/` — Express backend (low-confidence detection, tests manual entry)
+- `files/mock-backend-only/` — Standalone Rust backend for backend-only architecture
+- `files/mcp-tools-no-serena.md` — MCP tool listing without Serena
+- `files/mcp-tools-with-serena.md` — MCP tool listing with onboarded Serena instance
+- `files/mcp-tools-serena-not-onboarded.md` — Serena present but not onboarded
+
+## Running
+
+```
+/sdlc-workflow:run-evals performance-setup
+```
+
+## Notes
+
+- Evals cover Steps 0–8 of the setup skill (no workflow selection or baseline capture)
+- Every config-producing eval requires `perf-config.py validate` output in `config-validation.txt`
+- No live MCP calls, server startup, or dependency installation — all fixture-based
+- Assertions focus on skill-owned contract (scope, framework, Serena status, repo paths), not `perf-config.py` defaults
diff --git a/evals/performance-setup/evals.json b/evals/performance-setup/evals.json
new file mode 100644
index 000000000..515d78b1c
--- /dev/null
+++ b/evals/performance-setup/evals.json
@@ -0,0 +1,95 @@
+{
+  "skill_name": "performance-setup",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Initialize performance analysis configuration for a frontend-only Next.js project. Bootstrap: copy files/mock-frontend-next/ to outputs/mock-repo/. The available MCP tools are listed in files/mcp-tools-no-serena.md — there are NO Serena tools available. Simulate tool discovery using the listing — do NOT call any actual MCP tools. Architecture choice: Frontend-only (analysis_scope='frontend-only', metric_type='frontend'). Detect the frontend framework from package.json and next.config.js (should detect Next.js with webpack bundler). Use recommended defaults for baseline settings (iterations=20, warmup=2) and frontend optimization targets (LCP=2.5s, FCP=1.8s, DOM Interactive=3.5s, Total Load Time=4.0s). Set backend_available=false, serena_status and serena_instance to null. Write config to outputs/mock-repo/performance-config.json following the perf-config.py init output schema (metadata, repositories, baseline, optimization_targets, workflow, scenarios, modules sections). Create directories under outputs/mock-repo/performance/{baselines,analysis,plans,optimization-results,verification}/. Check for CONVENTIONS.md at outputs/mock-repo/ root — it won't exist, so note the warning in the summary. Write setup summary to outputs/setup-summary.md. After writing config, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. To find perf-config.py, resolve: plugin_root=$(ls -d \"${HOME}/.claude/plugins/cache/\"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1). Do NOT call MCP tools. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "A performance-config.json at outputs/mock-repo/performance-config.json with analysis_scope='frontend-only', metric_type='frontend', backend_available=false, repositories.frontend.framework is a Next.js variant (next/next.js/nextjs). The setup summary warns about missing CONVENTIONS.md. config-validation.txt shows validation passed. Directory structure performance/{baselines,analysis,plans,optimization-results,verification} created under outputs/mock-repo/.",
+      "files": ["files/mock-frontend-next/package.json", "files/mock-frontend-next/next.config.js", "files/mock-frontend-next/src/app/page.tsx", "files/mcp-tools-no-serena.md"],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/config-validation.txt exists and contains 'passed'",
+        "outputs/setup-summary.md exists",
+        "outputs/mock-repo/performance/baselines/ directory exists",
+        "performance-config.json contains analysis_scope set to 'frontend-only'",
+        "performance-config.json contains metric_type set to 'frontend'",
+        "performance-config.json shows backend_available as false",
+        "performance-config.json shows repositories.frontend.framework as a Next.js variant (next, next.js, or nextjs)",
+        "outputs/setup-summary.md warns about missing CONVENTIONS.md",
+        "performance-config.json all directories values use 'performance/' prefix (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Initialize performance analysis configuration for a full-stack monorepo with Serena onboarded. Bootstrap: copy files/mock-frontend-next/ to outputs/mock-repo/ and copy files/mock-backend-rust/ to outputs/mock-repo/backend/. The available MCP tools are listed in files/mcp-tools-with-serena.md — simulate Serena discovery (find mcp__serena_backend__check_onboarding_performed in the listing) and assume onboarding is complete (serena_status='onboarded', serena_instance='serena_backend'). Do NOT call actual MCP tools. Architecture choice: Full-stack monorepo (analysis_scope='full-stack-monorepo', metric_type='hybrid'). Detect frontend framework from package.json/next.config.js (Next.js, webpack bundler). Detect backend framework from Cargo.toml (actix-web). API base path: '/api/v1'. Set backend_available=true. Use recommended defaults for baseline settings (iterations=20, warmup=2) and all optimization targets (frontend: LCP=2.5s, FCP=1.8s, DOM Interactive=3.5s, Total Load Time=4.0s; backend: Response Time p95=200ms, p99=500ms, Throughput=100 req/s, Error Rate=0.1%, DB Query Time p95=50ms). Write config to outputs/mock-repo/performance-config.json following the perf-config.py init output schema. Create directories under outputs/mock-repo/performance/{baselines,analysis,plans,optimization-results,verification}/. Write setup summary to outputs/setup-summary.md showing full-stack monorepo with Serena enabled. After writing config, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. To find perf-config.py, resolve: plugin_root=$(ls -d \"${HOME}/.claude/plugins/cache/\"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1). Do NOT call MCP tools. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "A performance-config.json at outputs/mock-repo/performance-config.json with analysis_scope='full-stack-monorepo', metric_type='hybrid', backend_available=true, repositories.frontend.framework='Next.js', repositories.backend.framework='actix-web', repositories.backend.api_base_path='/api/v1', serena_status='onboarded', serena_instance='serena_backend'. Both frontend and backend optimization targets included. Setup summary shows full-stack monorepo architecture with Serena enabled.",
+      "files": ["files/mock-frontend-next/package.json", "files/mock-frontend-next/next.config.js", "files/mock-frontend-next/src/app/page.tsx", "files/mock-backend-rust/Cargo.toml", "files/mcp-tools-with-serena.md"],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/config-validation.txt exists and contains 'passed'",
+        "outputs/setup-summary.md exists",
+        "outputs/mock-repo/performance/baselines/ directory exists",
+        "performance-config.json contains analysis_scope set to 'full-stack-monorepo'",
+        "performance-config.json contains metric_type set to 'hybrid'",
+        "performance-config.json shows repositories.backend.framework as 'actix-web'",
+        "performance-config.json shows repositories.backend.api_base_path as '/api/v1'",
+        "performance-config.json shows serena_status as 'onboarded' and serena_instance as 'serena_backend'",
+        "performance-config.json all directories values use 'performance/' prefix (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Initialize performance analysis configuration for separate frontend and backend repositories. Bootstrap: copy files/mock-frontend-next/ to outputs/mock-frontend/ and copy files/mock-backend-node/ to outputs/mock-backend/. MCP tools listed in files/mcp-tools-no-serena.md — no Serena available. Do NOT call actual MCP tools. Architecture choice: Separate repos (analysis_scope='full-stack', metric_type='hybrid'). Frontend path: outputs/mock-frontend/ — detect Next.js from package.json/next.config.js (webpack bundler). Backend path: outputs/mock-backend/ — framework is 'express' (manually specified, auto-detection has low confidence for this package.json). API base path: '/api'. Set backend_available=true, serena_status='not_running', serena_instance=null. Use recommended defaults for baseline settings (iterations=20, warmup=2) and all optimization targets. Treat outputs/mock-frontend/ as the primary target repository for config placement. Write config to outputs/mock-frontend/performance-config.json following the perf-config.py init output schema. Create directories under outputs/mock-frontend/performance/{baselines,analysis,plans,optimization-results,verification}/. Write setup summary to outputs/setup-summary.md noting no Serena available and recommending grep-based analysis. After writing config, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. To find perf-config.py, resolve: plugin_root=$(ls -d \"${HOME}/.claude/plugins/cache/\"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1). Do NOT call MCP tools. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "A performance-config.json at outputs/mock-frontend/performance-config.json with analysis_scope='full-stack', metric_type='hybrid', repositories.backend.framework='express', repositories.backend.api_base_path='/api', serena_status='not_running', serena_instance=null. Both frontend and backend optimization targets included. The setup summary notes no Serena available and recommends grep-based analysis.",
+      "files": ["files/mock-frontend-next/package.json", "files/mock-frontend-next/next.config.js", "files/mock-frontend-next/src/app/page.tsx", "files/mock-backend-node/package.json", "files/mcp-tools-no-serena.md"],
+      "assertions": [
+        "outputs/mock-frontend/performance-config.json exists",
+        "outputs/config-validation.txt exists and contains 'passed'",
+        "outputs/setup-summary.md exists",
+        "outputs/mock-frontend/performance/baselines/ directory exists",
+        "performance-config.json contains analysis_scope set to 'full-stack'",
+        "performance-config.json contains metric_type set to 'hybrid'",
+        "performance-config.json shows repositories.backend.framework as 'express'",
+        "performance-config.json shows repositories.backend.api_base_path as '/api'",
+        "performance-config.json shows serena_status as 'not_running' and serena_instance as null",
+        "performance-config.json all directories values use 'performance/' prefix (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Initialize performance analysis configuration for a backend-only Rust repository. Bootstrap: copy files/mock-backend-only/ to outputs/mock-backend/. MCP tools listed in files/mcp-tools-no-serena.md — no Serena available. Do NOT call actual MCP tools. Architecture choice: Backend-only (analysis_scope='backend-only', metric_type='backend'). Detect backend framework from Cargo.toml (actix-web). API base path: '/api'. Set backend_available=true, serena_status='not_running', serena_instance=null. No frontend repository — repositories.frontend fields should be null/unconfigured. Use recommended defaults for baseline settings (iterations=20, warmup=2) and backend optimization targets only (Response Time p95=200ms, p99=500ms, Throughput=100 req/s, Error Rate=0.1%, DB Query Time p95=50ms). No frontend targets. Write config to outputs/mock-backend/performance-config.json following the perf-config.py init output schema. Create directories under outputs/mock-backend/performance/{baselines,analysis,plans,optimization-results,verification}/. Write setup summary to outputs/setup-summary.md. After writing config, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. To find perf-config.py, resolve: plugin_root=$(ls -d \"${HOME}/.claude/plugins/cache/\"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1). Do NOT call MCP tools. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "A performance-config.json at outputs/mock-backend/performance-config.json with analysis_scope='backend-only', metric_type='backend', backend_available=true, no frontend repository configured, repositories.backend.framework='actix-web', repositories.backend.api_base_path='/api'. Backend optimization targets included. No frontend optimization targets. config-validation.txt shows validation passed.",
+      "files": ["files/mock-backend-only/Cargo.toml", "files/mcp-tools-no-serena.md"],
+      "assertions": [
+        "outputs/mock-backend/performance-config.json exists",
+        "outputs/config-validation.txt exists and contains 'passed'",
+        "outputs/setup-summary.md exists",
+        "outputs/mock-backend/performance/baselines/ directory exists",
+        "performance-config.json contains analysis_scope set to 'backend-only'",
+        "performance-config.json contains metric_type set to 'backend'",
+        "performance-config.json shows backend_available as true",
+        "performance-config.json shows repositories.backend.framework as 'actix-web'",
+        "performance-config.json shows repositories.frontend values are all null (no frontend configured)",
+        "performance-config.json all directories values use 'performance/' prefix (not '.claude/performance/')"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Initialize performance analysis configuration for a full-stack monorepo where Serena is discovered but NOT onboarded. Bootstrap: copy files/mock-frontend-next/ to outputs/mock-repo/ and copy files/mock-backend-rust/ to outputs/mock-repo/backend/. The available MCP tools are listed in files/mcp-tools-serena-not-onboarded.md — Serena tools are present but check_onboarding_performed would return 'Onboarding not performed yet'. Simulate this discovery — do NOT call actual MCP tools. Architecture choice: Full-stack monorepo (analysis_scope='full-stack-monorepo', metric_type='hybrid'). Detect frontend framework from package.json/next.config.js (Next.js, webpack bundler). Detect backend framework from Cargo.toml (actix-web). API base path: '/api/v1'. Set backend_available=true. Serena onboarding: user chooses to skip (serena_status='skipped', serena_instance=null) — will use grep-based analysis instead. Use recommended defaults for baseline settings (iterations=20, warmup=2) and all optimization targets. Write config to outputs/mock-repo/performance-config.json following the perf-config.py init output schema. Create directories under outputs/mock-repo/performance/{baselines,analysis,plans,optimization-results,verification}/. Write setup summary to outputs/setup-summary.md noting Serena was discovered but user skipped onboarding, recommending grep-based analysis. After writing config, run perf-config.py validate against the config path and save output to outputs/config-validation.txt. To find perf-config.py, resolve: plugin_root=$(ls -d \"${HOME}/.claude/plugins/cache/\"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1). Do NOT call MCP tools. Do NOT start servers or install dependencies. Do NOT modify files outside outputs/.",
+      "expected_output": "A performance-config.json at outputs/mock-repo/performance-config.json with analysis_scope='full-stack-monorepo', metric_type='hybrid', backend_available=true, repositories.backend.framework='actix-web', serena_status='skipped'. The setup summary notes Serena was discovered but user skipped onboarding, recommending grep-based analysis. config-validation.txt shows validation passed.",
+      "files": ["files/mock-frontend-next/package.json", "files/mock-frontend-next/next.config.js", "files/mock-frontend-next/src/app/page.tsx", "files/mock-backend-rust/Cargo.toml", "files/mcp-tools-serena-not-onboarded.md"],
+      "assertions": [
+        "outputs/mock-repo/performance-config.json exists",
+        "outputs/config-validation.txt exists and contains 'passed'",
+        "outputs/setup-summary.md exists",
+        "outputs/mock-repo/performance/baselines/ directory exists",
+        "performance-config.json contains analysis_scope set to 'full-stack-monorepo'",
+        "performance-config.json contains metric_type set to 'hybrid'",
+        "performance-config.json shows serena_status as 'skipped'",
+        "performance-config.json shows repositories.backend.framework as 'actix-web'",
+        "outputs/setup-summary.md mentions grep-based analysis or skipped Serena onboarding",
+        "performance-config.json all directories values use 'performance/' prefix (not '.claude/performance/')"
+      ]
+    }
+  ]
+}
diff --git a/evals/performance-setup/files/mcp-tools-no-serena.md b/evals/performance-setup/files/mcp-tools-no-serena.md
new file mode 100644
index 000000000..34c644934
--- /dev/null
+++ b/evals/performance-setup/files/mcp-tools-no-serena.md
@@ -0,0 +1,5 @@
+<!-- SYNTHETIC TEST DATA — MCP tools listing without Serena -->
+## Available MCP Tools
+
+No Serena MCP instances discovered.
+Available tools: Bash, Read, Write, Edit, WebFetch, WebSearch.
diff --git a/evals/performance-setup/files/mcp-tools-serena-not-onboarded.md b/evals/performance-setup/files/mcp-tools-serena-not-onboarded.md
new file mode 100644
index 000000000..0012a9bd9
--- /dev/null
+++ b/evals/performance-setup/files/mcp-tools-serena-not-onboarded.md
@@ -0,0 +1,14 @@
+<!-- SYNTHETIC TEST DATA — Serena present but not onboarded -->
+## Available MCP Tools
+
+### serena_backend
+- mcp__serena_backend__get_symbols_overview
+- mcp__serena_backend__find_symbol
+- mcp__serena_backend__find_declaration
+- mcp__serena_backend__find_referencing_symbols
+- mcp__serena_backend__find_implementations
+- mcp__serena_backend__check_onboarding_performed
+- mcp__serena_backend__initial_instructions
+
+Simulate: check_onboarding_performed returns "Onboarding not performed yet"
+User choice: Skip onboarding (grep-based analysis)
diff --git a/evals/performance-setup/files/mcp-tools-with-serena.md b/evals/performance-setup/files/mcp-tools-with-serena.md
new file mode 100644
index 000000000..1a7b28988
--- /dev/null
+++ b/evals/performance-setup/files/mcp-tools-with-serena.md
@@ -0,0 +1,11 @@
+<!-- SYNTHETIC TEST DATA — MCP tools listing with Serena instances -->
+## Available MCP Tools
+
+### serena_backend
+- mcp__serena_backend__get_symbols_overview
+- mcp__serena_backend__find_symbol
+- mcp__serena_backend__find_declaration
+- mcp__serena_backend__find_referencing_symbols
+- mcp__serena_backend__find_implementations
+- mcp__serena_backend__check_onboarding_performed
+- mcp__serena_backend__initial_instructions
diff --git a/evals/performance-setup/files/mock-backend-node/package.json b/evals/performance-setup/files/mock-backend-node/package.json
new file mode 100644
index 000000000..20542760a
--- /dev/null
+++ b/evals/performance-setup/files/mock-backend-node/package.json
@@ -0,0 +1,7 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — minimal Express backend for eval testing",
+  "name": "mock-api",
+  "version": "1.0.0",
+  "scripts": {"start": "node server.js"},
+  "dependencies": {"express": "^4.18.0"}
+}
diff --git a/evals/performance-setup/files/mock-backend-only/Cargo.toml b/evals/performance-setup/files/mock-backend-only/Cargo.toml
new file mode 100644
index 000000000..bce2212fe
--- /dev/null
+++ b/evals/performance-setup/files/mock-backend-only/Cargo.toml
@@ -0,0 +1,11 @@
+# SYNTHETIC TEST DATA — standalone Rust backend for eval testing (backend-only architecture)
+[package]
+name = "backend-service"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres"] }
+serde = { version = "1", features = ["derive"] }
+tokio = { version = "1", features = ["full"] }
diff --git a/evals/performance-setup/files/mock-backend-rust/Cargo.toml b/evals/performance-setup/files/mock-backend-rust/Cargo.toml
new file mode 100644
index 000000000..8546f61b6
--- /dev/null
+++ b/evals/performance-setup/files/mock-backend-rust/Cargo.toml
@@ -0,0 +1,10 @@
+# SYNTHETIC TEST DATA — minimal Rust backend for eval testing
+[package]
+name = "mock-api"
+version = "0.1.0"
+edition = "2021"
+
+[dependencies]
+actix-web = "4"
+sea-orm = { version = "0.12", features = ["sqlx-postgres"] }
+serde = { version = "1", features = ["derive"] }
diff --git a/evals/performance-setup/files/mock-frontend-next/next.config.js b/evals/performance-setup/files/mock-frontend-next/next.config.js
new file mode 100644
index 000000000..7c27a4573
--- /dev/null
+++ b/evals/performance-setup/files/mock-frontend-next/next.config.js
@@ -0,0 +1,3 @@
+// SYNTHETIC TEST DATA — minimal Next.js config for eval testing
+/** @type {import('next').NextConfig} */
+module.exports = { reactStrictMode: true };
diff --git a/evals/performance-setup/files/mock-frontend-next/package.json b/evals/performance-setup/files/mock-frontend-next/package.json
new file mode 100644
index 000000000..de5c83e86
--- /dev/null
+++ b/evals/performance-setup/files/mock-frontend-next/package.json
@@ -0,0 +1,7 @@
+{
+  "_comment": "SYNTHETIC TEST DATA — minimal Next.js project for eval testing",
+  "name": "mock-frontend",
+  "version": "1.0.0",
+  "scripts": {"dev": "next dev", "build": "next build"},
+  "dependencies": {"next": "^14.0.0", "react": "^18.2.0", "react-dom": "^18.2.0"}
+}
diff --git a/evals/performance-setup/files/mock-frontend-next/src/app/page.tsx b/evals/performance-setup/files/mock-frontend-next/src/app/page.tsx
new file mode 100644
index 000000000..0faf8c465
--- /dev/null
+++ b/evals/performance-setup/files/mock-frontend-next/src/app/page.tsx
@@ -0,0 +1,9 @@
+// SYNTHETIC TEST DATA — minimal Next.js page for eval testing
+export default function Home() {
+  return (
+    <main>
+      <h1>Mock Frontend App</h1>
+      <p>This is a minimal Next.js page component for eval testing.</p>
+    </main>
+  );
+}
diff --git a/evals/verify-pr/evals.json b/evals/verify-pr/evals.json
index 571bc17cf..af6b6eb2e 100644
--- a/evals/verify-pr/evals.json
+++ b/evals/verify-pr/evals.json
@@ -115,6 +115,22 @@
         "The skill does NOT modify any code files — it only reads, verifies, creates sub-task descriptions, and reports (constraint 1.11)",
         "Non-eval checks (Scope Containment, Sensitive Patterns, Acceptance Criteria) are unaffected by eval processing — Scope Containment compares the diff files against the task's Files to Modify, Sensitive Patterns scans the diff for secrets, and Acceptance Criteria evaluates each criterion against the diff content independently of the eval results"
       ]
+    },
+    {
+      "id": 7,
+      "prompt": "Verify PR #801 for task TC-9107. The task description is in task-performance.md, the PR diff is in pr-diff-performance.md, the target repository structure is in repo-backend.md, the optimization result report is in optimization-result-mock.md (treat it as if located at performance/optimization-results/TC-9107-2026-06-15.md), and the project's performance-config.json is in perf-config-mock.json. There are no review comments on this PR and all CI checks pass. Write your verification report to outputs/report.md. For each acceptance criterion, write your detailed reasoning to outputs/criterion-N.md (where N is the criterion number).",
+      "expected_output": "A verification report that includes performance-specific rows (Target Achievement, Environment Match, Baseline Re-run) in addition to standard verification rows. Target Achievement should be PASS since all target metrics are met (Response Time p95 150ms < 200ms target, Queries 3 < 5 target). Environment Match should be MATCH since both config and report use localhost (capture_target: null). The report should include a Performance Results section with the before/after comparison table.",
+      "files": ["files/task-performance.md", "files/pr-diff-performance.md", "files/optimization-result-mock.md", "files/repo-backend.md", "files/perf-config-mock.json"],
+      "assertions": [
+        "The report or verification process identifies the task as task_type = performance based on the performance-optimization label or the presence of Baseline Metrics, Target Metrics, and Performance Test Requirements sections (SKILL.md lines 139-140)",
+        "The report contains a Target Achievement row with PASS — all target metrics (Response Time p95 < 200ms, Queries per request < 5) are met in the optimization result (150ms, 3 queries)",
+        "The report contains an Environment Match row with MATCH — both performance-config.json capture_target (null/localhost) and the optimization result report capture_target (null) match",
+        "The report contains a Baseline Re-run row with SKIPPED or N/A — no live environment is available for re-running the baseline in the eval context",
+        "The report includes a Performance Results section with the before/after comparison table showing baseline (850ms, ~200 queries) vs current (150ms, 3 queries) metrics",
+        "The report still contains standard verification rows (Scope Containment, Acceptance Criteria, Sensitive Patterns) — performance-specific steps add to, not replace, standard verification",
+        "Scope Containment is PASS — all files in the diff (advisory/service/advisory.rs, sbom/service/sbom.rs, tests/api/sbom_advisory_batch.rs) match the task's Files to Modify and Files to Create",
+        "The skill does NOT modify any code files — it only reads, verifies, and reports (constraint 1.11)"
+      ]
     }
   ]
 }
diff --git a/evals/verify-pr/files/optimization-result-mock.md b/evals/verify-pr/files/optimization-result-mock.md
new file mode 100644
index 000000000..608d38076
--- /dev/null
+++ b/evals/verify-pr/files/optimization-result-mock.md
@@ -0,0 +1,60 @@
+<!-- SYNTHETIC TEST DATA — mock optimization result report for verify-pr eval testing -->
+
+---
+metadata:
+  jira_key: TC-9107
+  workflow: SBOM Advisory Loading
+  timestamp: 2026-06-15T14:30:00Z
+  branch: TC-9107
+  commit_sha: e7b9d4a3f2c1b8d6a5e4f3c2b1a0d9e8f7c6b5a4
+  baseline_commit_sha: a1b2c3d4e5f67890a1b2c3d4e5f67890abcdef01
+  capture_mode: backend
+  capture_target: null
+  capture_base_url: null
+  status: pending_verification
+---
+
+# Optimization Result: TC-9107
+
+**Task:** Batch advisory queries in SBOM detail endpoint to eliminate N+1
+**Workflow:** SBOM Advisory Loading
+**Executed:** 2026-06-15 14:30 UTC
+**Branch:** TC-9107
+
+## Performance Impact
+
+### Backend Metrics
+| Metric | Before | After | Change | Target |
+|---|---|---|---|---|
+| Response Time (p95) | 850ms | 150ms | -700ms (-82%) | < 200ms |
+| Queries per request | ~200 | 3 | -197 (-98.5%) | < 5 |
+| Throughput (req/s) | 12 | 45 | +33 (+275%) | — |
+| Error Rate | 0.0% | 0.0% | 0% | — |
+
+**Performance Summary:**
+- Response time reduced by 82% (850ms → 150ms), well under the 200ms target
+- Query count reduced from ~200 to 3 by batching advisory lookups
+
+## Test Scenarios Measured
+
+- SBOM detail endpoint with 200+ linked advisories (primary scenario)
+- SBOM detail endpoint with 0 advisories (edge case)
+- SBOM detail endpoint with 50 advisories (moderate load)
+
+## Code Changes
+
+- Commit: e7b9d4a3f2c1b8d6a5e4f3c2b1a0d9e8f7c6b5a4
+- PR: https://github.com/trustify/trustify-backend/pull/801
+- Files modified: advisory/service/advisory.rs, sbom/service/sbom.rs, tests/api/sbom_advisory_batch.rs
+
+## Validation
+
+- [x] All functional tests pass
+- [x] No new warnings introduced
+- [x] Response time meets target (150ms < 200ms)
+- [x] Query count meets target (3 < 5)
+
+## Next Steps
+
+- Verify PR passes acceptance criteria with `/sdlc-workflow:verify-pr TC-9107`
+- After PR merge to main, re-run `/sdlc-workflow:performance-baseline` to update configuration with fresh metrics
diff --git a/evals/verify-pr/files/perf-config-mock.json b/evals/verify-pr/files/perf-config-mock.json
new file mode 100644
index 000000000..1d82f0aa3
--- /dev/null
+++ b/evals/verify-pr/files/perf-config-mock.json
@@ -0,0 +1,34 @@
+{
+  "metadata": {
+    "version": "1.0",
+    "created": "2026-06-10T10:00:00Z",
+    "last_updated": "2026-06-10T10:00:00Z",
+    "workflow_selected": true,
+    "baseline_captured": true,
+    "baseline_mode": "backend",
+    "baseline_timestamp": "2026-06-10T10:00:00Z",
+    "baseline_commit_sha": "a1b2c3d4e5f67890a1b2c3d4e5f67890abcdef01",
+    "capture_target": null,
+    "capture_base_url": null,
+    "backend_available": true,
+    "analysis_scope": "backend-only",
+    "metric_type": "backend"
+  },
+  "baseline_settings": {
+    "iterations": 3,
+    "warmup": 1
+  },
+  "dev_environment": {
+    "backend": {
+      "port": 8080,
+      "framework": "axum"
+    }
+  },
+  "directories": {
+    "performance": "performance",
+    "optimization_results": "performance/optimization-results",
+    "verification": "performance/verification",
+    "baselines": "performance/baselines"
+  },
+  "optimization_targets": {}
+}
diff --git a/evals/verify-pr/files/pr-diff-performance.md b/evals/verify-pr/files/pr-diff-performance.md
new file mode 100644
index 000000000..540632597
--- /dev/null
+++ b/evals/verify-pr/files/pr-diff-performance.md
@@ -0,0 +1,158 @@
+<!-- SYNTHETIC TEST DATA — mock PR diff for eval testing; simulates `gh pr diff` output for a performance optimization -->
+
+```diff
+diff --git a/modules/fundamental/src/advisory/service/advisory.rs b/modules/fundamental/src/advisory/service/advisory.rs
+index 2a1f3c8..e7b9d4a 100644
+--- a/modules/fundamental/src/advisory/service/advisory.rs
++++ b/modules/fundamental/src/advisory/service/advisory.rs
+@@ -1,6 +1,7 @@
+ use anyhow::Context;
+ use sea_orm::{ColumnTrait, ConnectionTrait, EntityTrait, QueryFilter};
++use sea_orm::QuerySelect;
+ use uuid::Uuid;
+
+ use crate::advisory::model::details::AdvisoryDetails;
+@@ -45,6 +46,30 @@ impl AdvisoryService {
+         Ok(AdvisoryDetails::from_entity(advisory, &tx).await?)
+     }
+
++    /// Fetches multiple advisories by their IDs in a single batched query.
++    pub async fn fetch_advisories_batch(
++        &self,
++        ids: Vec<Uuid>,
++        tx: &Transactional<'_>,
++    ) -> Result<Vec<AdvisoryDetails>, AppError> {
++        if ids.is_empty() {
++            return Ok(vec![]);
++        }
++
++        let advisories = advisory::Entity::find()
++            .filter(advisory::Column::Id.is_in(ids.clone()))
++            .all(&tx.connection())
++            .await
++            .context("Failed to batch-fetch advisories")?;
++
++        let mut results = Vec::with_capacity(advisories.len());
++        for advisory in advisories {
++            let details = AdvisoryDetails::from_entity(advisory, tx).await?;
++            results.push(details);
++        }
++
++        Ok(results)
++    }
++
+     /// Lists advisories with optional filtering and pagination.
+     pub async fn list(
+         &self,
+diff --git a/modules/fundamental/src/sbom/service/sbom.rs b/modules/fundamental/src/sbom/service/sbom.rs
+index 5c3a1b2..8d4e7f9 100644
+--- a/modules/fundamental/src/sbom/service/sbom.rs
++++ b/modules/fundamental/src/sbom/service/sbom.rs
+@@ -82,16 +82,14 @@ impl SbomService {
+             .context("Failed to find SBOM")?
+             .ok_or_else(|| AppError::NotFound(format!("SBOM {} not found", id)))?;
+
+-        // Load linked advisories one at a time
+-        let advisory_links = sbom_advisory::Entity::find()
++        // Batch-load all linked advisories in a single query
++        let advisory_ids: Vec<Uuid> = sbom_advisory::Entity::find()
+             .filter(sbom_advisory::Column::SbomId.eq(sbom.id))
+             .all(&tx.connection())
+-            .await?;
+-
+-        let mut advisories = Vec::new();
+-        for link in &advisory_links {
+-            let advisory = self.advisory_service.fetch(link.advisory_id, tx).await?;
+-            advisories.push(advisory);
+-        }
++            .await?
++            .into_iter()
++            .map(|link| link.advisory_id)
++            .collect();
++        let advisories = self.advisory_service.fetch_advisories_batch(advisory_ids, tx).await?;
+
+         Ok(SbomDetails {
+             summary: SbomSummary::from_entity(sbom, &tx).await?,
+diff --git a/tests/api/sbom_advisory_batch.rs b/tests/api/sbom_advisory_batch.rs
+new file mode 100644
+index 0000000..a3c1d2e
+--- /dev/null
++++ b/tests/api/sbom_advisory_batch.rs
+@@ -0,0 +1,62 @@
++use test_context::test_context;
++use trustify_test_context::TrustifyContext;
++
++/// Verifies that batch advisory loading returns the same results as individual loading.
++#[test_context(TrustifyContext)]
++#[test(actix_web::test)]
++async fn test_batch_advisory_matches_individual(
++    ctx: &TrustifyContext,
++) -> Result<(), anyhow::Error> {
++    // Given: an SBOM with multiple linked advisories
++    let sbom_id = ctx.ingest_test_sbom_with_advisories(5).await?;
++
++    // When: fetching SBOM details (uses batch loading internally)
++    let resp = ctx
++        .call_service(
++            actix_web::test::TestRequest::get()
++                .uri(&format!("/api/v2/sbom/{}", sbom_id))
++                .to_request(),
++        )
++        .await;
++
++    // Then: response contains all 5 advisories
++    assert_eq!(resp.status(), actix_web::http::StatusCode::OK);
++    let body: serde_json::Value = actix_web::test::read_body_json(resp).await;
++    let advisories = body["advisories"].as_array().unwrap();
++    assert_eq!(advisories.len(), 5);
++
++    Ok(())
++}
++
++/// Verifies that an SBOM with no advisories returns an empty list.
++#[test_context(TrustifyContext)]
++#[test(actix_web::test)]
++async fn test_sbom_no_advisories(ctx: &TrustifyContext) -> Result<(), anyhow::Error> {
++    // Given: an SBOM with no linked advisories
++    let sbom_id = ctx.ingest_test_sbom_with_advisories(0).await?;
++
++    // When: fetching SBOM details
++    let resp = ctx
++        .call_service(
++            actix_web::test::TestRequest::get()
++                .uri(&format!("/api/v2/sbom/{}", sbom_id))
++                .to_request(),
++        )
++        .await;
++
++    // Then: advisories list is empty (not an error)
++    assert_eq!(resp.status(), actix_web::http::StatusCode::OK);
++    let body: serde_json::Value = actix_web::test::read_body_json(resp).await;
++    let advisories = body["advisories"].as_array().unwrap();
++    assert_eq!(advisories.len(), 0);
++
++    Ok(())
++}
++
++/// Verifies that duplicate advisory IDs are handled gracefully.
++#[test_context(TrustifyContext)]
++#[test(actix_web::test)]
++async fn test_batch_deduplicates_advisories(ctx: &TrustifyContext) -> Result<(), anyhow::Error> {
++    // Given: an SBOM with duplicate advisory links
++    let sbom_id = ctx.ingest_test_sbom_with_duplicate_advisories(3).await?;
++
++    // When: fetching SBOM details
++    let resp = ctx
++        .call_service(
++            actix_web::test::TestRequest::get()
++                .uri(&format!("/api/v2/sbom/{}", sbom_id))
++                .to_request(),
++        )
++        .await;
++
++    // Then: advisories are deduplicated
++    assert_eq!(resp.status(), actix_web::http::StatusCode::OK);
++
++    Ok(())
++}
+```
diff --git a/evals/verify-pr/files/task-performance.md b/evals/verify-pr/files/task-performance.md
new file mode 100644
index 000000000..8384b91df
--- /dev/null
+++ b/evals/verify-pr/files/task-performance.md
@@ -0,0 +1,71 @@
+<!-- SYNTHETIC TEST DATA — mock Jira task description for eval testing; names, URLs, and identifiers are fictional -->
+
+# Jira Task: TC-9107
+
+**Key**: TC-9107
+**Summary**: Batch advisory queries in SBOM detail endpoint to eliminate N+1
+**Status**: In Review
+**Labels**: ai-generated-jira, performance-optimization, backend, query-optimization
+**PR URL**: https://github.com/trustify/trustify-backend/pull/801
+**Web URL**: https://redhat.atlassian.net/browse/TC-9107
+**Parent Feature**: TC-9001
+
+---
+
+## Repository
+trustify-backend
+
+## Target Branch
+main
+
+## Description
+Replace the sequential per-advisory query loop in the SBOM detail endpoint with a single
+batched query. Currently, `SbomService::fetch_details` loads the SBOM, then iterates over
+linked advisories calling `AdvisoryService::fetch` individually for each one. With SBOMs
+linked to 200+ advisories, this produces ~200 sequential DB queries and pushes response
+time above the 200ms target.
+
+**Implementation approach:**
+
+1. Add a `fetch_advisories_batch` method to `AdvisoryService` that accepts `Vec<Uuid>`
+   and returns all matching advisories in a single `WHERE id IN (...)` query.
+2. Update `SbomService::fetch_details` to collect advisory IDs first, then call the
+   batch method once instead of looping.
+
+## Files to Modify
+- `modules/fundamental/src/advisory/service/advisory.rs` — add `fetch_advisories_batch` method
+- `modules/fundamental/src/sbom/service/sbom.rs` — replace per-advisory loop with batch call
+
+## Files to Create
+- `tests/api/sbom_advisory_batch.rs` — integration test verifying batch loading produces same results
+
+## Implementation Notes
+- Follow the existing `fetch` method pattern in `advisory/service/advisory.rs` for the batch variant
+- Use SeaORM's `.is_in()` filter for the batch query (see `common/src/db/query.rs` for examples)
+- The `sbom_advisory` join table in `entity/src/sbom_advisory.rs` links SBOMs to advisories
+- Error handling: return `AppError` with `.context()` wrapping, matching existing patterns
+- Ensure the batch method preserves the same `AdvisoryDetails` response shape as the individual `fetch`
+
+## Acceptance Criteria
+- [ ] SBOM detail endpoint returns identical advisory data as before (no behavioral change)
+- [ ] Response time for SBOMs with 200+ advisories is under 200ms p95
+- [ ] All existing SBOM and advisory endpoint tests pass
+- [ ] No increase in error rate
+
+## Test Requirements
+- [ ] Test that batch loading returns the same advisory details as individual loading
+- [ ] Test that an SBOM with no advisories returns an empty list (not an error)
+- [ ] Test that duplicate advisory IDs are handled gracefully
+
+## Baseline Metrics
+- **Response Time (p95):** 850ms (`GET /api/v2/sbom/{id}` with 200+ advisories)
+- **Queries per request:** ~200 sequential
+
+## Target Metrics
+- **Response Time (p95):** < 200ms
+- **Queries per request:** < 5
+
+## Performance Test Requirements
+- [ ] Run performance baseline after implementation
+- [ ] Verify SBOM detail response time is under 200ms p95 for 200+ advisory SBOMs
+- [ ] Compare against baseline metrics and confirm improvement
diff --git a/plugins/sdlc-workflow/scripts/perf-benchmark.sh b/plugins/sdlc-workflow/scripts/perf-benchmark.sh
new file mode 100755
index 000000000..823e278aa
--- /dev/null
+++ b/plugins/sdlc-workflow/scripts/perf-benchmark.sh
@@ -0,0 +1,258 @@
+#!/usr/bin/env bash
+#
+# perf-benchmark.sh — API endpoint benchmarking with percentile calculation
+#
+# Runs curl loops against backend endpoints, computes p50/p95/p99 latencies,
+# measures cache effectiveness (cold vs warm), and outputs structured JSON.
+#
+# Usage:
+#   perf-benchmark.sh --port PORT --iterations N --manifest PATH --output PATH
+#
+# Prerequisites: curl, jq (both verified at startup)
+# No bc dependency — all floating-point math uses awk.
+#
+# Manifest schema (JSON, keyed by endpoint path):
+#   {
+#     "endpoints": {
+#       "/api/v2/products": {
+#         "test_url": "/api/v2/products",
+#         "parameters": {"id": "abc-123"}
+#       }
+#     }
+#   }
+#
+# Output schema (JSON):
+#   {
+#     "endpoints": { "<path>": { p50_ms, p95_ms, p99_ms, mean_ms, ... } },
+#     "aggregate": { mean_ms, p50_ms, p95_ms, p99_ms },
+#     "config": { iterations, warmup_runs },
+#     "errors": { failed_count, failed_endpoints: [] }
+#   }
+
+set -euo pipefail
+
+# --- Argument parsing ---
+
+usage() {
+  cat >&2 <<EOF
+Usage: perf-benchmark.sh --port PORT --iterations N --manifest PATH --output PATH
+
+Arguments:
+  --port PORT          Localhost port where backend is running
+  --iterations N       Number of warm-cache requests per endpoint (default: 20)
+  --manifest PATH      Path to test-data manifest JSON
+  --output PATH        Path to write results JSON
+
+Example:
+  perf-benchmark.sh --port 8080 --iterations 20 \\
+    --manifest performance/test-data/manifest.json \\
+    --output performance/baselines/benchmark-results.json
+EOF
+  exit 1
+}
+
+PORT=""
+ITERATIONS=20
+MANIFEST=""
+OUTPUT=""
+
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --port) PORT="$2"; shift 2 ;;
+    --iterations) ITERATIONS="$2"; shift 2 ;;
+    --manifest) MANIFEST="$2"; shift 2 ;;
+    --output) OUTPUT="$2"; shift 2 ;;
+    --help|-h) usage ;;
+    *) echo "Unknown argument: $1" >&2; usage ;;
+  esac
+done
+
+if [[ -z "$PORT" || -z "$MANIFEST" || -z "$OUTPUT" ]]; then
+  echo "Error: --port, --manifest, and --output are required" >&2
+  usage
+fi
+
+# --- Prerequisite checks ---
+
+for cmd in curl jq; do
+  if ! command -v "$cmd" &>/dev/null; then
+    echo "Error: $cmd not found. Install it and retry." >&2
+    exit 1
+  fi
+done
+
+if ! timeout 2 bash -c "</dev/tcp/localhost/$PORT" 2>/dev/null; then
+  echo "Error: Nothing listening on localhost:$PORT" >&2
+  exit 1
+fi
+
+if [[ ! -f "$MANIFEST" ]]; then
+  echo "Error: Manifest not found at $MANIFEST" >&2
+  exit 1
+fi
+
+# --- Percentile function ---
+# Uses nearest-rank method: p = sorted[ceil(n * percentile/100) - 1]
+# Input: sorted array (via nameref), percentile (0-100)
+# Correct for n=20: p95 = sorted[ceil(20*0.95)-1] = sorted[18] (second-highest)
+
+percentile_index() {
+  local n="$1"
+  local pct="$2"
+  # ceil(n * pct / 100) - 1, clamped to [0, n-1]
+  local idx
+  idx=$(awk -v n="$n" -v p="$pct" 'BEGIN {
+    raw = n * p / 100
+    ceiled = (raw == int(raw)) ? raw : int(raw) + 1
+    idx = ceiled - 1
+    if (idx < 0) idx = 0
+    if (idx >= n) idx = n - 1
+    printf "%d", idx
+  }')
+  echo "$idx"
+}
+
+# --- Benchmark loop ---
+
+endpoint_results='{}' # jq accumulator
+failed_endpoints='[]'
+failed_count=0
+total_endpoints=0
+
+while IFS='|' read -r endpoint_path test_url; do
+  total_endpoints=$((total_endpoints + 1))
+  url="http://localhost:${PORT}${test_url}"
+
+  echo "Benchmarking: $endpoint_path ($url)"
+
+  # 1. Cold-cache request (first request, measures worst-case)
+  first_request_s=$(curl -o /dev/null -s -w '%{time_total}' --max-time 30 "$url" 2>/dev/null || echo "")
+  if [[ -z "$first_request_s" ]]; then
+    echo "  Warning: First request failed, skipping endpoint"
+    failed_count=$((failed_count + 1))
+    failed_endpoints=$(echo "$failed_endpoints" | jq --arg ep "$endpoint_path" '. + [$ep]')
+    continue
+  fi
+  first_request_ms=$(awk -v t="$first_request_s" 'BEGIN { printf "%.0f", t * 1000 }')
+
+  # 2. Warm-cache requests
+  times=()
+  for i in $(seq 1 "$ITERATIONS"); do
+    t=$(curl -o /dev/null -s -w '%{time_total}' --max-time 30 "$url" 2>/dev/null || echo "")
+    if [[ -n "$t" ]]; then
+      ms=$(awk -v t="$t" 'BEGIN { printf "%.0f", t * 1000 }')
+      times+=("$ms")
+    fi
+  done
+
+  if [[ ${#times[@]} -eq 0 ]]; then
+    echo "  Warning: All warm-cache requests failed, skipping endpoint"
+    failed_count=$((failed_count + 1))
+    failed_endpoints=$(echo "$failed_endpoints" | jq --arg ep "$endpoint_path" '. + [$ep]')
+    continue
+  fi
+
+  # 3. Sort and compute percentiles
+  sorted=($(printf '%s\n' "${times[@]}" | sort -n))
+  n=${#sorted[@]}
+
+  p50_idx=$(percentile_index "$n" 50)
+  p95_idx=$(percentile_index "$n" 95)
+  p99_idx=$(percentile_index "$n" 99)
+
+  p50=${sorted[$p50_idx]}
+  p95=${sorted[$p95_idx]}
+  p99=${sorted[$p99_idx]}
+  mean=$(printf '%s\n' "${times[@]}" | awk '{ s += $1 } END { printf "%.0f", s/NR }')
+
+  # 4. Cache effectiveness (awk instead of bc)
+  cache_improvement="0"
+  cache_status="N/A"
+  if [[ "$first_request_ms" -gt 0 ]]; then
+    cache_improvement=$(awk -v cold="$first_request_ms" -v warm="$mean" \
+      'BEGIN { printf "%.2f", (cold - warm) / cold * 100 }')
+    cache_status=$(awk -v imp="$cache_improvement" 'BEGIN {
+      if (imp + 0 > 50) print "Effective"
+      else if (imp + 0 > 20) print "Moderate"
+      else print "Minimal"
+    }')
+  fi
+
+  # 5. Build endpoint result via jq
+  endpoint_json=$(jq -n \
+    --arg url "$test_url" \
+    --argjson iters "$ITERATIONS" \
+    --argjson p50 "$p50" \
+    --argjson p95 "$p95" \
+    --argjson p99 "$p99" \
+    --argjson mean "$mean" \
+    --argjson first "$first_request_ms" \
+    --arg cache_pct "$cache_improvement" \
+    --arg cache_stat "$cache_status" \
+    --argjson samples "$n" \
+    '{
+      test_url: $url,
+      iterations: $iters,
+      samples_collected: $samples,
+      p50_ms: $p50,
+      p95_ms: $p95,
+      p99_ms: $p99,
+      mean_ms: $mean,
+      first_request_ms: $first,
+      subsequent_mean_ms: $mean,
+      cache_improvement_pct: $cache_pct,
+      cache_status: $cache_stat
+    }')
+
+  endpoint_results=$(echo "$endpoint_results" | jq --arg key "$endpoint_path" --argjson val "$endpoint_json" '. + {($key): $val}')
+
+  echo "  p50: ${p50}ms  p95: ${p95}ms  p99: ${p99}ms  cache: ${cache_improvement}% (${cache_status})"
+
+done < <(jq -r '.endpoints | to_entries[] | "\(.key)|\(.value.test_url)"' "$MANIFEST")
+
+# --- Compute aggregate stats ---
+
+if [[ $(echo "$endpoint_results" | jq 'length') -gt 0 ]]; then
+  aggregate=$(echo "$endpoint_results" | jq '{
+    mean_ms: ([.[].mean_ms] | add / length | floor),
+    p50_ms: ([.[].p50_ms] | add / length | floor),
+    p95_ms: ([.[].p95_ms] | add / length | floor),
+    p99_ms: ([.[].p99_ms] | add / length | floor)
+  }')
+else
+  aggregate='{"mean_ms": 0, "p50_ms": 0, "p95_ms": 0, "p99_ms": 0}'
+fi
+
+# --- Write output ---
+
+mkdir -p "$(dirname "$OUTPUT")"
+
+jq -n \
+  --argjson endpoints "$endpoint_results" \
+  --argjson aggregate "$aggregate" \
+  --argjson iterations "$ITERATIONS" \
+  --argjson failed_count "$failed_count" \
+  --argjson failed_endpoints "$failed_endpoints" \
+  --argjson total "$total_endpoints" \
+  '{
+    endpoints: $endpoints,
+    aggregate: $aggregate,
+    config: {
+      iterations: $iterations,
+      warmup_runs: 0,
+      mode: "api-benchmark"
+    },
+    summary: {
+      total_endpoints: $total,
+      successful_endpoints: ($total - $failed_count),
+      failed_endpoints: $failed_endpoints,
+      failed_count: $failed_count
+    }
+  }' > "$OUTPUT"
+
+echo ""
+echo "Benchmark complete: $((total_endpoints - failed_count))/$total_endpoints endpoints profiled"
+echo "Results: $OUTPUT"
+if [[ $failed_count -gt 0 ]]; then
+  echo "Warning: $failed_count endpoint(s) failed"
+fi
diff --git a/plugins/sdlc-workflow/scripts/perf-config.py b/plugins/sdlc-workflow/scripts/perf-config.py
new file mode 100755
index 000000000..67bef68c2
--- /dev/null
+++ b/plugins/sdlc-workflow/scripts/perf-config.py
@@ -0,0 +1,705 @@
+#!/usr/bin/env python3
+"""Performance configuration manager for sdlc-workflow performance skills.
+
+Manages performance-config.json — the structured configuration file
+used by all performance skills (performance-setup, performance-baseline,
+performance-analyze-module, performance-plan-optimization, implement-task, verify-pr).
+
+Uses only Python stdlib — no external dependencies required.
+
+Subcommands:
+    init            Create a new config from CLI arguments
+    get             Read a value by dotpath (e.g., metadata.baseline_mode)
+    get-section     Dump a top-level section as JSON
+    set             Write a scalar value by dotpath
+    set-json        Write structured data by dotpath
+    validate        Check required fields and value constraints
+    resolve-scope   Resolve analysis_scope to capability flags
+    resolve-module-path  Pick module directory with most handlers
+"""
+
+import argparse
+import json
+import os
+import sys
+import tempfile
+from collections import Counter
+from datetime import datetime, timezone
+from typing import Any, Dict, List, Optional
+
+
+DEFAULT_CONFIG_PATH = "performance-config.json"
+
+DEFAULT_CONFIG = {
+    "metadata": {
+        "version": "1.0",
+        "created": None,
+        "last_updated": None,
+        "workflow_selected": False,
+        "baseline_captured": False,
+        "baseline_mode": None,
+        "baseline_timestamp": None,
+        "baseline_commit_sha": None,
+        "capture_target": None,
+        "capture_base_url": None,
+        "backend_available": False,
+        "analysis_scope": "frontend-only",
+        "backend_endpoint_discovery_method": None,
+        "serena_status": None,
+        "metric_type": "frontend",
+    },
+    "repositories": {
+        "frontend": {
+            "name": None,
+            "path": None,
+            "framework": None,
+            "bundler": None,
+        },
+        "backend": {
+            "name": None,
+            "path": None,
+            "framework": None,
+            "serena_instance": None,
+            "api_base_path": "/api/v2",
+            "available": False,
+            "last_validated": None,
+        },
+    },
+    "workflow": {
+        "name": None,
+        "entry_point": None,
+        "key_screens": [],
+        "complexity": None,
+        "selected_on": None,
+        "traced_api_endpoints": [],
+    },
+    "scenarios": [],
+    "modules": [],
+    "baseline_settings": {
+        "iterations": 20,
+        "warmup_runs": 2,
+    },
+    "optimization_targets": {
+        "frontend": {
+            "lcp": {"baseline": None, "latest": None, "target": 2.5, "unit": "seconds"},
+            "fcp": {"baseline": None, "latest": None, "target": 1.8, "unit": "seconds"},
+            "dom_interactive": {"baseline": None, "latest": None, "target": 3.5, "unit": "seconds"},
+            "total_load_time": {"baseline": None, "latest": None, "target": 4.0, "unit": "seconds"},
+        },
+        "backend": {
+            "response_time_p95": {"baseline": None, "latest": None, "target": 200, "unit": "ms"},
+            "response_time_p99": {"baseline": None, "latest": None, "target": 500, "unit": "ms"},
+            "throughput": {"baseline": None, "latest": None, "target": 100, "unit": "req/sec"},
+            "error_rate": {"baseline": None, "latest": None, "target": 0.1, "unit": "%"},
+            "db_query_time_p95": {"baseline": None, "latest": None, "target": 50, "unit": "ms"},
+        },
+    },
+    "analysis_assumptions": {
+        "bandwidth_mbps": 5,
+        "api_latency_ms": 100,
+        "reflow_cost_ms": 5,
+        "cache_hit_rate": 0.8,
+        "chain_depth": 3,
+        "db_latency_ms": 10,
+    },
+    "dev_environment": {
+        "frontend": {
+            "command": None,
+            "source": None,
+            "port": None,
+            "command_approved": False,
+            "last_validated": None,
+        },
+        "backend": {
+            "command": None,
+            "source": None,
+            "port": None,
+            "command_approved": False,
+            "last_validated": None,
+        },
+    },
+    "directories": {
+        "baselines": "performance/baselines/",
+        "analysis": "performance/analysis/",
+        "plans": "performance/plans/",
+        "optimization_results": "performance/optimization-results/",
+        "verification": "performance/verification/",
+        "test_data": "performance/test-data/",
+    },
+}
+
+
+def now_iso() -> str:
+    return datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
+
+
+def resolve_config_path(args_config: Optional[str]) -> str:
+    if args_config:
+        return args_config
+    # Walk up from CWD to find the config, like git finds .git
+    current = os.path.abspath(".")
+    while True:
+        candidate = os.path.join(current, DEFAULT_CONFIG_PATH)
+        if os.path.isfile(candidate):
+            return candidate
+        parent = os.path.dirname(current)
+        if parent == current:
+            break
+        current = parent
+    return DEFAULT_CONFIG_PATH
+
+
+def read_config(path: str) -> Dict[str, Any]:
+    try:
+        with open(path, "r") as f:
+            return json.load(f)
+    except FileNotFoundError:
+        print(f"Error: Config not found at {path}", file=sys.stderr)
+        print("Run: perf-config.py init  — or —  /sdlc-workflow:performance-setup", file=sys.stderr)
+        sys.exit(1)
+    except json.JSONDecodeError as e:
+        print(f"Error: Invalid JSON in {path}: {e}", file=sys.stderr)
+        sys.exit(1)
+
+
+def write_config(path: str, config: Dict[str, Any]) -> None:
+    """Atomic write: write to temp file then rename."""
+    dir_name = os.path.dirname(path) or "."
+    os.makedirs(dir_name, exist_ok=True)
+    fd, tmp_path = tempfile.mkstemp(dir=dir_name, suffix=".json.tmp")
+    try:
+        with os.fdopen(fd, "w") as f:
+            json.dump(config, f, indent=2)
+            f.write("\n")
+        os.rename(tmp_path, path)
+    except Exception:
+        os.unlink(tmp_path)
+        raise
+
+
+class _KeyNotFound(Exception):
+    """Raised when a dotpath key is missing and the caller wants to handle it."""
+
+
+def get_by_dotpath(obj: Any, dotpath: str, raise_on_missing: bool = False) -> Any:
+    """Traverse a nested dict/list by dot-separated path.
+
+    Supports integer indices for lists: scenarios.0.name
+
+    If raise_on_missing is True, raises _KeyNotFound instead of calling sys.exit(1)
+    when a dict key is absent. Use this when a default value should be printed instead.
+    """
+    parts = dotpath.split(".")
+    current = obj
+    for part in parts:
+        if isinstance(current, dict):
+            if part not in current:
+                if raise_on_missing:
+                    raise _KeyNotFound(dotpath)
+                print(f"Error: Key '{part}' not found in path '{dotpath}'", file=sys.stderr)
+                sys.exit(1)
+            current = current[part]
+        elif isinstance(current, list):
+            try:
+                idx = int(part)
+                current = current[idx]
+            except (ValueError, IndexError):
+                print(f"Error: Invalid list index '{part}' in path '{dotpath}'", file=sys.stderr)
+                sys.exit(1)
+        else:
+            print(f"Error: Cannot traverse into {type(current).__name__} at '{part}' in '{dotpath}'", file=sys.stderr)
+            sys.exit(1)
+    return current
+
+
+def set_by_dotpath(obj: Dict, dotpath: str, value: Any) -> None:
+    """Set a value in a nested dict by dot-separated path, creating intermediate dicts as needed."""
+    parts = dotpath.split(".")
+    current = obj
+    for part in parts[:-1]:
+        if isinstance(current, dict):
+            if part not in current:
+                current[part] = {}
+            current = current[part]
+        elif isinstance(current, list):
+            try:
+                current = current[int(part)]
+            except (ValueError, IndexError):
+                print(f"Error: Invalid list index '{part}' in path '{dotpath}'", file=sys.stderr)
+                sys.exit(1)
+        else:
+            print(f"Error: Cannot traverse into {type(current).__name__} at '{part}'", file=sys.stderr)
+            sys.exit(1)
+
+    last_key = parts[-1]
+    if isinstance(current, dict):
+        current[last_key] = value
+    elif isinstance(current, list):
+        try:
+            current[int(last_key)] = value
+        except (ValueError, IndexError):
+            print(f"Error: Invalid list index '{last_key}' in path '{dotpath}'", file=sys.stderr)
+            sys.exit(1)
+
+
+def parse_scalar(value_str: str) -> Any:
+    """Parse a CLI string into a typed Python value."""
+    if value_str.lower() == "null" or value_str.lower() == "none":
+        return None
+    if value_str.lower() == "true":
+        return True
+    if value_str.lower() == "false":
+        return False
+    try:
+        return int(value_str)
+    except ValueError:
+        pass
+    try:
+        return float(value_str)
+    except ValueError:
+        pass
+    return value_str
+
+
+# --- Subcommands ---
+
+
+def cmd_init(args: argparse.Namespace) -> None:
+    """Create a new performance config from CLI arguments."""
+    path = resolve_config_path(args.config)
+    if os.path.exists(path) and not args.force:
+        print(f"Error: Config already exists at {path}. Use --force to overwrite.", file=sys.stderr)
+        sys.exit(1)
+
+    config = json.loads(json.dumps(DEFAULT_CONFIG))
+    ts = now_iso()
+    config["metadata"]["created"] = ts
+    config["metadata"]["last_updated"] = ts
+
+    if args.analysis_scope:
+        config["metadata"]["analysis_scope"] = args.analysis_scope
+        config["metadata"]["metric_type"] = _resolve_metric_type(args.analysis_scope)
+
+    if args.frontend_path:
+        config["repositories"]["frontend"]["path"] = args.frontend_path
+    if args.frontend_framework:
+        config["repositories"]["frontend"]["framework"] = args.frontend_framework
+    if args.frontend_name:
+        config["repositories"]["frontend"]["name"] = args.frontend_name
+    if args.bundler:
+        config["repositories"]["frontend"]["bundler"] = args.bundler
+
+    if args.backend_path:
+        config["repositories"]["backend"]["path"] = args.backend_path
+        config["repositories"]["backend"]["available"] = True
+        config["repositories"]["backend"]["last_validated"] = ts
+        config["metadata"]["backend_available"] = True
+    if args.backend_framework:
+        config["repositories"]["backend"]["framework"] = args.backend_framework
+    if args.backend_name:
+        config["repositories"]["backend"]["name"] = args.backend_name
+    if args.api_base_path:
+        config["repositories"]["backend"]["api_base_path"] = args.api_base_path
+    if args.serena_instance:
+        config["repositories"]["backend"]["serena_instance"] = args.serena_instance
+    if args.serena_status:
+        config["metadata"]["serena_status"] = args.serena_status
+
+    if args.lcp_target is not None:
+        config["optimization_targets"]["frontend"]["lcp"]["target"] = args.lcp_target
+    if args.fcp_target is not None:
+        config["optimization_targets"]["frontend"]["fcp"]["target"] = args.fcp_target
+    if args.dom_target is not None:
+        config["optimization_targets"]["frontend"]["dom_interactive"]["target"] = args.dom_target
+    if args.total_target is not None:
+        config["optimization_targets"]["frontend"]["total_load_time"]["target"] = args.total_target
+
+    if args.resp_p95_target is not None:
+        config["optimization_targets"]["backend"]["response_time_p95"]["target"] = args.resp_p95_target
+    if args.resp_p99_target is not None:
+        config["optimization_targets"]["backend"]["response_time_p99"]["target"] = args.resp_p99_target
+    if args.throughput_target is not None:
+        config["optimization_targets"]["backend"]["throughput"]["target"] = args.throughput_target
+    if args.error_rate_target is not None:
+        config["optimization_targets"]["backend"]["error_rate"]["target"] = args.error_rate_target
+    if args.db_query_time_target is not None:
+        config["optimization_targets"]["backend"]["db_query_time_p95"]["target"] = args.db_query_time_target
+
+    if args.iterations is not None:
+        config["baseline_settings"]["iterations"] = args.iterations
+    if args.warmup_runs is not None:
+        config["baseline_settings"]["warmup_runs"] = args.warmup_runs
+
+    write_config(path, config)
+    print(f"Config created at {path}")
+
+
+def cmd_get(args: argparse.Namespace) -> None:
+    """Read a value by dotpath and print to stdout."""
+    config = read_config(resolve_config_path(args.config))
+    try:
+        value = get_by_dotpath(config, args.dotpath,
+                               raise_on_missing=(args.default_value is not None))
+    except _KeyNotFound:
+        print(args.default_value)
+        return
+    if isinstance(value, (dict, list)):
+        print(json.dumps(value, indent=2))
+    elif value is None:
+        print("null")
+    elif isinstance(value, bool):
+        print("true" if value else "false")
+    else:
+        print(value)
+
+
+def cmd_get_section(args: argparse.Namespace) -> None:
+    """Dump a top-level section as JSON."""
+    config = read_config(resolve_config_path(args.config))
+    if args.section not in config:
+        print(f"Error: Section '{args.section}' not found", file=sys.stderr)
+        print(f"Available sections: {', '.join(config.keys())}", file=sys.stderr)
+        sys.exit(1)
+    print(json.dumps(config[args.section], indent=2))
+
+
+def cmd_set(args: argparse.Namespace) -> None:
+    """Write a scalar value by dotpath."""
+    path = resolve_config_path(args.config)
+    config = read_config(path)
+    value = parse_scalar(args.value)
+    set_by_dotpath(config, args.dotpath, value)
+    if args.dotpath == "metadata.analysis_scope" and isinstance(value, str):
+        resolved = _resolve_metric_type(value)
+        if resolved:
+            config["metadata"]["metric_type"] = resolved
+    config["metadata"]["last_updated"] = now_iso()
+    write_config(path, config)
+
+
+def cmd_set_json(args: argparse.Namespace) -> None:
+    """Write structured JSON data by dotpath."""
+    path = resolve_config_path(args.config)
+    config = read_config(path)
+    try:
+        value = json.loads(args.json_value)
+    except json.JSONDecodeError as e:
+        print(f"Error: Invalid JSON value: {e}", file=sys.stderr)
+        sys.exit(1)
+    set_by_dotpath(config, args.dotpath, value)
+    if args.dotpath == "metadata.analysis_scope" and isinstance(value, str):
+        resolved = _resolve_metric_type(value)
+        if resolved:
+            config["metadata"]["metric_type"] = resolved
+    config["metadata"]["last_updated"] = now_iso()
+    write_config(path, config)
+
+
+def _resolve_metric_type(scope: str) -> Optional[str]:
+    """Map analysis_scope to expected metric_type."""
+    return {
+        "frontend-only": "frontend",
+        "backend-only": "backend",
+        "full-stack": "hybrid",
+        "full-stack-monorepo": "hybrid",
+    }.get(scope)
+
+
+def cmd_validate(args: argparse.Namespace) -> None:
+    """Validate config structure and value constraints.
+
+    --phase baseline: additionally checks that config is ready for baseline capture.
+    Default (no --phase): structural validation only.
+    """
+    config = read_config(resolve_config_path(args.config))
+    errors: List[str] = []
+    phase = getattr(args, "phase", None)
+
+    # --- Structural validation (always runs) ---
+
+    required_sections = ["metadata", "repositories", "workflow", "scenarios",
+                         "modules", "baseline_settings", "optimization_targets",
+                         "analysis_assumptions", "dev_environment", "directories"]
+    for section in required_sections:
+        if section not in config:
+            errors.append(f"Missing required section: {section}")
+
+    if "metadata" in config:
+        m = config["metadata"]
+        valid_scopes = ["frontend-only", "backend-only", "full-stack", "full-stack-monorepo"]
+        scope = m.get("analysis_scope")
+        if scope and scope not in valid_scopes:
+            errors.append(f"metadata.analysis_scope must be one of {valid_scopes}, got '{scope}'")
+
+        valid_types = ["frontend", "backend", "hybrid", None]
+        mt = m.get("metric_type")
+        if mt not in valid_types:
+            errors.append(f"metadata.metric_type must be one of {valid_types}, got '{mt}'")
+
+        # metric_type ↔ analysis_scope consistency
+        if scope and mt:
+            expected = _resolve_metric_type(scope)
+            if expected and mt != expected:
+                errors.append(f"metadata.metric_type '{mt}' inconsistent with analysis_scope '{scope}' (expected '{expected}')")
+
+        valid_targets = ["localhost", "hosted", None]
+        ct = m.get("capture_target")
+        if ct not in valid_targets:
+            errors.append(f"metadata.capture_target must be one of {valid_targets}, got '{ct}'")
+
+    if "baseline_settings" in config:
+        bs = config["baseline_settings"]
+        iters = bs.get("iterations", 0)
+        if not isinstance(iters, int) or iters < 1:
+            errors.append(f"baseline_settings.iterations must be a positive integer, got {iters}")
+
+    if "analysis_assumptions" in config:
+        aa = config["analysis_assumptions"]
+        if aa.get("bandwidth_mbps", 0) <= 0:
+            errors.append("analysis_assumptions.bandwidth_mbps must be > 0")
+        if aa.get("api_latency_ms", 0) <= 0:
+            errors.append("analysis_assumptions.api_latency_ms must be > 0")
+        if aa.get("reflow_cost_ms", 0) <= 0:
+            errors.append("analysis_assumptions.reflow_cost_ms must be > 0")
+        hit_rate = aa.get("cache_hit_rate", -1)
+        if not (0.0 <= hit_rate <= 1.0):
+            errors.append(f"analysis_assumptions.cache_hit_rate must be 0.0-1.0, got {hit_rate}")
+        depth = aa.get("chain_depth", 0)
+        if not isinstance(depth, int) or not (1 <= depth <= 5):
+            errors.append(f"analysis_assumptions.chain_depth must be int 1-5, got {depth}")
+        if aa.get("db_latency_ms", 0) <= 0:
+            errors.append("analysis_assumptions.db_latency_ms must be > 0")
+
+    # --- Baseline-readiness validation (--phase baseline) ---
+
+    if phase == "baseline":
+        scenarios = config.get("scenarios", [])
+        if not scenarios:
+            errors.append("scenarios must contain at least 1 entry for baseline capture")
+        else:
+            for i, s in enumerate(scenarios):
+                if not s.get("name"):
+                    errors.append(f"scenarios[{i}].name is empty")
+                if not s.get("url"):
+                    errors.append(f"scenarios[{i}].url is empty")
+                st = s.get("type")
+                if st is not None and st not in ("frontend", "backend"):
+                    errors.append(f"scenarios[{i}].type must be 'frontend' or 'backend', got '{st}'")
+
+        scope = config.get("metadata", {}).get("analysis_scope", "frontend-only")
+        if scope in ("full-stack", "full-stack-monorepo") and scenarios:
+            types_found = {s.get("type", "frontend") for s in scenarios}
+            if "backend" not in types_found:
+                errors.append(
+                    "full-stack scope requires at least one scenario with type='backend'"
+                    " — run baseline Step 4.8 or use 'skip backend' to downgrade to frontend-only"
+                )
+            traced = config.get("workflow", {}).get("traced_api_endpoints", [])
+            if traced:
+                traced_paths = {e["path"] for e in traced if "path" in e}
+                backend_urls = {s["url"] for s in scenarios if s.get("type") == "backend" and s.get("url")}
+                orphans = backend_urls - traced_paths
+                if orphans:
+                    errors.append(f"Backend scenarios not in traced_api_endpoints: {orphans}")
+
+        dev = config.get("dev_environment", {})
+        # Determine which components need a valid port based on scope
+        if scope in ("backend-only",):
+            components_needed = ["backend"]
+        elif scope in ("full-stack", "full-stack-monorepo"):
+            components_needed = ["frontend", "backend"]
+        else:
+            components_needed = ["frontend"]
+        # Support flat dev_environment (backward compat): flat config is valid
+        # for single-component scopes, but hybrid requires nested structure
+        is_flat = "command" in dev and "frontend" not in dev and "backend" not in dev
+        if is_flat and len(components_needed) > 1:
+            errors.append("dev_environment uses flat format but analysis_scope requires both frontend and backend — re-run /performance-setup")
+        elif is_flat:
+            port = dev.get("port")
+            if port is not None:
+                if not isinstance(port, int) or port < 1 or port > 65535:
+                    errors.append(f"dev_environment.port must be integer 1-65535, got {port}")
+        else:
+            for comp in components_needed:
+                comp_dev = dev.get(comp, {})
+                port = comp_dev.get("port")
+                if port is not None:
+                    if not isinstance(port, int) or port < 1 or port > 65535:
+                        errors.append(f"dev_environment.{comp}.port must be integer 1-65535, got {port}")
+
+        bs = config.get("baseline_settings", {})
+        iters = bs.get("iterations", 0)
+        warmup = bs.get("warmup_runs", 0)
+        if isinstance(warmup, int) and warmup < 0:
+            errors.append(f"baseline_settings.warmup_runs must be >= 0, got {warmup}")
+        if isinstance(warmup, int) and warmup > 10:
+            errors.append(f"baseline_settings.warmup_runs must be <= 10, got {warmup}")
+        if isinstance(iters, int) and iters < 20:
+            print(f"Warning: {iters} iterations — p95 may not be statistically reliable (≥20 recommended).", file=sys.stderr)
+
+        if config.get("metadata", {}).get("workflow_selected"):
+            wf = config.get("workflow", {})
+            if not wf.get("name"):
+                errors.append("workflow.name required when workflow_selected is true")
+            if not wf.get("entry_point"):
+                errors.append("workflow.entry_point required when workflow_selected is true")
+            modules = config.get("modules", [])
+            if not modules:
+                errors.append("modules must be non-empty when workflow_selected is true")
+            else:
+                for i, mod in enumerate(modules):
+                    if not mod.get("name"):
+                        errors.append(f"modules[{i}].name is empty")
+                    if not mod.get("entry_point"):
+                        errors.append(f"modules[{i}].entry_point is empty")
+
+    if errors:
+        print("Validation FAILED:", file=sys.stderr)
+        for err in errors:
+            print(f"  - {err}", file=sys.stderr)
+        sys.exit(1)
+    else:
+        print("Validation passed")
+
+
+def cmd_resolve_scope(args: argparse.Namespace) -> None:
+    """Resolve analysis_scope into capability flags."""
+    config = read_config(resolve_config_path(args.config))
+    scope = config.get("metadata", {}).get("analysis_scope", "frontend-only")
+
+    flags = {
+        "scope": scope,
+        "frontend_capture": scope in ("frontend-only", "full-stack", "full-stack-monorepo"),
+        "backend_capture": scope in ("backend-only", "full-stack", "full-stack-monorepo"),
+        "browser_metrics": scope in ("frontend-only", "full-stack", "full-stack-monorepo"),
+        "api_metrics": scope in ("backend-only", "full-stack", "full-stack-monorepo"),
+        "same_repo": scope == "full-stack-monorepo",
+    }
+    print(json.dumps(flags))
+
+
+def cmd_resolve_module_path(args: argparse.Namespace) -> None:
+    """Pick the module directory containing the most handler files.
+
+    Precondition: config must have workflow_selected=true and modules populated.
+    Returns empty string if no modules found.
+    """
+    config = read_config(resolve_config_path(args.config))
+    handlers = config.get("modules", [])
+    if not handlers:
+        print("")
+        return
+
+    dirs: List[str] = []
+    for h in handlers:
+        entry = h.get("entry_point", "")
+        parts = entry.split("/")
+        if len(parts) > 1:
+            dir_path = "/".join(parts[:-1])
+            dirs.append(dir_path)
+
+    if not dirs:
+        print("")
+        return
+
+    counts = Counter(dirs)
+    print(counts.most_common(1)[0][0])
+
+
+# --- CLI ---
+
+
+def build_parser() -> argparse.ArgumentParser:
+    parser = argparse.ArgumentParser(
+        prog="perf-config.py",
+        description="Performance configuration manager for sdlc-workflow",
+    )
+    parser.add_argument("--config", "-c", help=f"Config file path. Default: walks up from CWD to find {DEFAULT_CONFIG_PATH}")
+    sub = parser.add_subparsers(dest="command", required=True)
+
+    # init
+    p_init = sub.add_parser("init", help="Create a new performance config")
+    p_init.add_argument("--analysis-scope", choices=["frontend-only", "backend-only", "full-stack", "full-stack-monorepo"])
+    p_init.add_argument("--frontend-path")
+    p_init.add_argument("--frontend-framework")
+    p_init.add_argument("--frontend-name")
+    p_init.add_argument("--bundler")
+    p_init.add_argument("--backend-path")
+    p_init.add_argument("--backend-framework")
+    p_init.add_argument("--backend-name")
+    p_init.add_argument("--api-base-path")
+    p_init.add_argument("--serena-instance")
+    p_init.add_argument("--serena-status")
+    p_init.add_argument("--lcp-target", type=float)
+    p_init.add_argument("--fcp-target", type=float)
+    p_init.add_argument("--dom-target", type=float)
+    p_init.add_argument("--total-target", type=float)
+    p_init.add_argument("--resp-p95-target", type=float)
+    p_init.add_argument("--resp-p99-target", type=float)
+    p_init.add_argument("--throughput-target", type=float)
+    p_init.add_argument("--error-rate-target", type=float)
+    p_init.add_argument("--db-query-time-target", type=float)
+    p_init.add_argument("--iterations", type=int)
+    p_init.add_argument("--warmup-runs", type=int)
+    p_init.add_argument("--force", action="store_true", help="Overwrite existing config")
+
+    # get
+    p_get = sub.add_parser("get", help="Read a value by dotpath")
+    p_get.add_argument("dotpath", help="Dot-separated path (e.g., metadata.baseline_mode)")
+    p_get.add_argument("--default", default=None, dest="default_value",
+                       help="Value to print if dotpath not found (instead of exiting 1)")
+
+    # get-section
+    p_gs = sub.add_parser("get-section", help="Dump a top-level section as JSON")
+    p_gs.add_argument("section", help="Section name (e.g., workflow, scenarios)")
+
+    # set
+    p_set = sub.add_parser("set", help="Write a scalar value")
+    p_set.add_argument("dotpath", help="Dot-separated path")
+    p_set.add_argument("value", help="Value to set (auto-typed: null, true, false, int, float, string)")
+
+    # set-json
+    p_sj = sub.add_parser("set-json", help="Write structured JSON data")
+    p_sj.add_argument("dotpath", help="Dot-separated path")
+    p_sj.add_argument("json_value", help="JSON string to set")
+
+    # validate
+    p_val = sub.add_parser("validate", help="Validate config structure and constraints")
+    p_val.add_argument("--phase", choices=["baseline"], default=None,
+                       help="Additional phase-specific checks (baseline: ready-to-capture)")
+
+    # resolve-scope
+    sub.add_parser("resolve-scope", help="Resolve analysis_scope to capability flags")
+
+    # resolve-module-path
+    sub.add_parser("resolve-module-path", help="Pick module directory with most handlers")
+
+    return parser
+
+
+def main() -> None:
+    parser = build_parser()
+    args = parser.parse_args()
+
+    commands = {
+        "init": cmd_init,
+        "get": cmd_get,
+        "get-section": cmd_get_section,
+        "set": cmd_set,
+        "set-json": cmd_set_json,
+        "validate": cmd_validate,
+        "resolve-scope": cmd_resolve_scope,
+        "resolve-module-path": cmd_resolve_module_path,
+    }
+
+    cmd_func = commands.get(args.command)
+    if cmd_func:
+        cmd_func(args)
+    else:
+        parser.print_help()
+        sys.exit(1)
+
+
+if __name__ == "__main__":
+    main()
diff --git a/plugins/sdlc-workflow/shared/jira-access-strategy.md b/plugins/sdlc-workflow/shared/jira-access-strategy.md
index 08c17cfc6..849c1707d 100644
--- a/plugins/sdlc-workflow/shared/jira-access-strategy.md
+++ b/plugins/sdlc-workflow/shared/jira-access-strategy.md
@@ -69,36 +69,133 @@ export JIRA_API_TOKEN="your-api-token"
 
 ```bash
 # Get issue
-cd <plugin-root> && \
-  python3 scripts/jira-client.py get_issue TC-123 --fields "summary,status,description"
+python3 "$plugin_root/scripts/jira-client.py" get_issue TC-123 --fields "summary,status,description"
 
 # Create issue
-cd <plugin-root> && \
-  python3 scripts/jira-client.py create_issue \
-    --project TC \
-    --summary "Issue summary" \
-    --description-md "Issue description in **markdown**" \
-    --issue-type Task \
-    --labels ai-generated-jira
+python3 "$plugin_root/scripts/jira-client.py" create_issue \
+  --project TC \
+  --summary "Issue summary" \
+  --description-md "Issue description in **markdown**" \
+  --issue-type Task \
+  --labels ai-generated-jira
 
 # Add comment
-cd <plugin-root> && \
-  python3 scripts/jira-client.py add_comment TC-123 \
-    --comment-md "Comment text in markdown"
+python3 "$plugin_root/scripts/jira-client.py" add_comment TC-123 \
+  --comment-md "Comment text in markdown"
 
 # Transition issue
-cd <plugin-root> && python3 scripts/jira-client.py transition_issue TC-123 --transition-id 31
+python3 "$plugin_root/scripts/jira-client.py" transition_issue TC-123 --transition-id 31
 
 # Create issue link
-cd <plugin-root> && \
-  python3 scripts/jira-client.py create_link \
-    --inward TC-123 \
-    --outward TC-456 \
-    --link-type Blocks
+python3 "$plugin_root/scripts/jira-client.py" create_link \
+  --inward TC-123 \
+  --outward TC-456 \
+  --link-type Blocks
 ```
 
 For full API reference, see `shared/jira-rest-fallback.md`.
 
+---
+
+## Performance Optimization JIRA Workflow
+
+Performance optimization skills use a specialized JIRA workflow involving Epics and Tasks to group optimization work.
+
+### Issue Hierarchy
+
+```
+Epic (Performance Optimization: {workflow-name})
+  ├── Task (Bundle Size Reduction: ...)
+  ├── Task (API Optimization: ...)
+  ├── Task (Render Optimization: ...)
+  └── Task (Resource Optimization: ...)
+```
+
+### Epic Usage
+
+**Created by**: `performance-plan-optimization`
+
+**Purpose**: Group all optimization tasks for a single workflow
+
+**Issue Type**: Epic (standard Jira Epic issue type)
+
+**Labels**:
+- `ai-generated-jira` (standard label for all AI-generated issues)
+- `performance-optimization` (identifies this as performance work)
+- `{workflow-name}` (the workflow being optimized, e.g., `home`, `sbom-list`)
+
+**Link Type**: **Incorporates** (Epic incorporates Tasks)
+
+### Task Usage
+
+**Created by**: `performance-plan-optimization`
+
+**Purpose**: Individual optimization work item (e.g., "Reduce bundle size by lazy loading", "Eliminate N+1 queries in SBOM list")
+
+**Issue Type**: Task (standard Jira Task issue type)
+
+**Labels**:
+- `ai-generated-jira` (standard label)
+- `performance-optimization` (identifies as performance work)
+- `{workflow-name}` (the workflow being optimized)
+- `{category}` (optimization category: `bundle-size`, `api-optimization`, `render-optimization`, `resource-optimization`, `long-task-mitigation`)
+- Layer labels: `frontend`, `backend`, or `integration` (based on where the optimization is applied)
+
+**Link Type**: **Blocks** (for task dependencies — e.g., Task 2 depends on Task 1 completing first)
+
+### Task Description Template Extensions
+
+Performance optimization tasks extend the standard task description template with three additional sections:
+
+1. **Baseline Metrics** — Current performance metrics before optimization (LCP, FCP, DOM Interactive, bundle size)
+2. **Target Metrics** — Expected metrics after optimization
+3. **Performance Test Requirements** — How to verify the optimization worked (e.g., "Re-run baseline capture, verify LCP < 2500ms")
+
+These sections are read by `implement-task` and `verify-pr` (auto-detected via task_type) to validate target achievement.
+
+### Label Conventions
+
+**Standard labels** (applied to all performance issues):
+- `ai-generated-jira`
+- `performance-optimization`
+
+**Workflow labels** (the workflow being optimized):
+- Workflow name in lowercase (e.g., `home`, `sbom-list`, `advisory-detail`)
+
+**Category labels** (optimization type):
+- `bundle-size` — Code splitting, lazy loading, dead code elimination
+- `api-optimization` — Reduce over-fetching, eliminate N+1 queries, parallel fetching
+- `render-optimization` — Component memoization, virtual scrolling, layout thrashing fixes
+- `resource-optimization` — Async/defer scripts, parallel loading, image compression
+- `long-task-mitigation` — Web workers, async patterns, code splitting for large modules
+
+**Layer labels** (where optimization is applied):
+- `frontend` — Client-side optimizations (React components, lazy loading, bundle splitting)
+- `backend` — Server-side optimizations (API response trimming, query optimization)
+- `integration` — Cross-layer optimizations (parallel API calls, resource hints)
+
+### Link to Feature Issues
+
+Performance optimization Epics/Tasks can be linked to Feature issues using the **Relates** link type to show that performance work is related to a specific feature development effort. This is optional and depends on whether the optimization is feature-driven or general improvement.
+
+### Example Workflow
+
+1. User runs `performance-plan-optimization` for "Home Dashboard" workflow
+2. Skill creates:
+   - **Epic**: "Performance Optimization: Home Dashboard"
+     - Labels: `ai-generated-jira`, `performance-optimization`, `home`
+   - **Task 1**: "Bundle Size Reduction: Lazy load charts library"
+     - Labels: `ai-generated-jira`, `performance-optimization`, `home`, `bundle-size`, `frontend`
+     - Link: Epic **incorporates** Task 1
+   - **Task 2**: "API Optimization: Reduce over-fetching in dashboard stats"
+     - Labels: `ai-generated-jira`, `performance-optimization`, `home`, `api-optimization`, `backend`
+     - Link: Epic **incorporates** Task 2
+     - Link: Task 1 **blocks** Task 2 (dependency)
+3. User runs `implement-task TC-XXXX` for Task 1 (performance sections auto-detected)
+4. User runs `verify-pr TC-XXXX` to verify Task 1 (performance sections auto-detected)
+
+---
+
 ## Implementation Pattern for Skills
 
 ### Standard JIRA Operation Flow
diff --git a/plugins/sdlc-workflow/shared/jira-rest-fallback.md b/plugins/sdlc-workflow/shared/jira-rest-fallback.md
index eecdfd8b5..45303464b 100644
--- a/plugins/sdlc-workflow/shared/jira-rest-fallback.md
+++ b/plugins/sdlc-workflow/shared/jira-rest-fallback.md
@@ -14,36 +14,43 @@ Skills must implement a graceful fallback pattern:
 
 **IMPORTANT**: The `scripts/jira-client.py` script is located in the plugin cache, not your current working directory.
 
-When a skill is invoked, Claude Code provides the skill base directory in the invocation message:
-```
-Base directory for this skill: /path/to/.claude/plugins/cache/sdlc-plugins/sdlc-workflow/<version>/skills/<skill-name>
-```
+### Resolving Plugin Root
 
-The **plugin root** is 2 directory levels up from the skill base:
-- Skill base: `.../sdlc-workflow/0.6.0/skills/define-feature`
-- Plugin root: `.../sdlc-workflow/0.6.0` (go up 2 levels)
+Before any script invocation, resolve the plugin root directory using this platform-agnostic approach:
 
-**All script invocations must use this pattern:**
 ```bash
-cd <plugin-root> && python3 scripts/jira-client.py <command>
+# Resolve plugin root — works for any registry name and any version
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null \
+  | sort -V | tail -1)
+
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then
+  echo "❌ sdlc-workflow plugin not found in ~/.claude/plugins/cache/"
+  echo "   Ensure the plugin is installed and try again."
+  exit 1
+fi
 ```
 
-Where `<plugin-root>` is extracted from the skill base directory shown in the invocation header.
+**Why this works:**
+- Glob `cache/*/sdlc-workflow/*/` matches any registry name (sdlc-plugins-local, sdlc-plugins, marketplace names)
+- Matches any version number in the plugin cache
+- `sort -V | tail -1` selects the latest version if multiple are present
+- Uses `$HOME` for cross-platform compatibility
 
-**Example:**
-If the skill invocation shows:
-```
-Base directory for this skill: /home/user/.claude/plugins/cache/sdlc-plugins/sdlc-workflow/0.6.0/skills/define-feature
+**All script invocations must use this pattern:**
+```bash
+python3 "$plugin_root/scripts/jira-client.py" <command>
 ```
 
-Then plugin root is: `/home/user/.claude/plugins/cache/sdlc-plugins/sdlc-workflow/0.6.0`
+**Example:**
+If plugin is installed at: `/home/user/.claude/plugins/cache/sdlc-plugins-local/sdlc-workflow/0.6.1/`
 
 Use:
 ```bash
-cd /home/user/.claude/plugins/cache/sdlc-plugins/sdlc-workflow/0.6.0 && \
-  python3 scripts/jira-client.py get_user_info
+python3 "$plugin_root/scripts/jira-client.py" get_user_info
 ```
 
+**Note:** The `$plugin_root` variable should be resolved once at skill initialization and reused for all script invocations.
+
 ## Credential Storage
 
 Credentials are stored in **`.env` file** (recommended) or **CLAUDE.md** (legacy):
@@ -154,7 +161,7 @@ export JIRA_EMAIL="<email>"
 export JIRA_API_TOKEN="<api-token>"
 
 # Test with get_user_info
-cd <plugin-root> && python3 scripts/jira-client.py get_user_info
+python3 "$plugin_root/scripts/jira-client.py" get_user_info
 ```
 
 On success:
@@ -264,8 +271,7 @@ export JIRA_API_TOKEN="<from-CLAUDE.md-or-env-var>"
 
 **Get Issue:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py get_issue TC-123 --fields "summary,status,description,labels,assignee"
+python3 "$plugin_root/scripts/jira-client.py" get_issue TC-123 --fields "summary,status,description,labels,assignee"
 ```
 
 Returns JSON:
@@ -284,13 +290,12 @@ Returns JSON:
 
 **Create Issue:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py create_issue \
-    --project TC \
-    --summary "New feature request" \
-    --description-md "This is the **description** in markdown." \
-    --issue-type "10142" \
-    --labels ai-generated-jira,feature
+python3 "$plugin_root/scripts/jira-client.py" create_issue \
+  --project TC \
+  --summary "New feature request" \
+  --description-md "This is the **description** in markdown." \
+  --issue-type "10142" \
+  --labels ai-generated-jira,feature
 ```
 
 Returns JSON:
@@ -303,53 +308,49 @@ Returns JSON:
 
 **Update Issue:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py update_issue TC-123 \
-    --fields-json '{"labels": ["ai-generated-jira", "updated"]}'
+python3 "$plugin_root/scripts/jira-client.py" update_issue TC-123 \
+  --fields-json '{"labels": ["ai-generated-jira", "updated"]}'
 ```
 
 **Add Comment:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py add_comment TC-123 \
-    --comment-md "This is a comment with **bold** text."
+python3 "$plugin_root/scripts/jira-client.py" add_comment TC-123 \
+  --comment-md "This is a comment with **bold** text."
 ```
 
 **Transition Issue:**
 ```bash
 # First, get available transitions
-cd <plugin-root> && python3 scripts/jira-client.py get_transitions TC-123
+python3 "$plugin_root/scripts/jira-client.py" get_transitions TC-123
 
 # Then transition using the ID
-cd <plugin-root> && python3 scripts/jira-client.py transition_issue TC-123 --transition-id 31
+python3 "$plugin_root/scripts/jira-client.py" transition_issue TC-123 --transition-id 31
 ```
 
 **Search with JQL:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py search_jql \
-    --jql "project = TC AND status = 'In Progress'" \
-    --fields "summary,status,assignee" \
-    --max-results 50
+python3 "$plugin_root/scripts/jira-client.py" search_jql \
+  --jql "project = TC AND status = 'In Progress'" \
+  --fields "summary,status,assignee" \
+  --max-results 50
 ```
 
 **Create Issue Link:**
 ```bash
-cd <plugin-root> && \
-  python3 scripts/jira-client.py create_link \
-    --inward TC-123 \
-    --outward TC-456 \
-    --link-type Incorporates
+python3 "$plugin_root/scripts/jira-client.py" create_link \
+  --inward TC-123 \
+  --outward TC-456 \
+  --link-type Incorporates
 ```
 
 **Get User Info:**
 ```bash
-cd <plugin-root> && python3 scripts/jira-client.py get_user_info
+python3 "$plugin_root/scripts/jira-client.py" get_user_info
 ```
 
 **Get Project Metadata:**
 ```bash
-cd <plugin-root> && python3 scripts/jira-client.py get_project_metadata TC
+python3 "$plugin_root/scripts/jira-client.py" get_project_metadata TC
 ```
 
 **Get Priorities:**
diff --git a/plugins/sdlc-workflow/skills/implement-task/SKILL.md b/plugins/sdlc-workflow/skills/implement-task/SKILL.md
index bb62a66ed..671db5831 100644
--- a/plugins/sdlc-workflow/skills/implement-task/SKILL.md
+++ b/plugins/sdlc-workflow/skills/implement-task/SKILL.md
@@ -132,6 +132,24 @@ Parse the structured description expecting these sections:
 - **Review Context** — the original review comment that triggered this task (optional)
 - **Bookend Type** — `create-branch` or `merge-branch` for feature branch bookend tasks (optional)
 - **Dependencies** — prerequisite tasks (verify they are Done)
+- **Baseline Metrics** — performance baseline captured at optimization start (optional, performance tasks only)
+- **Target Metrics** — performance targets for this optimization (optional, performance tasks only)
+- **Performance Test Requirements** — scenarios and measurement criteria (optional, performance tasks only)
+- **Database Migration** — migration framework, migration script (source code), before/after SQL (manual verification), migration up/down SQL (manual verification), rollback, safety checks, manual verification command, storage impact (optional, db-migration tasks only)
+
+### Task Type Detection
+
+Set `task_type` using these checks in priority order:
+
+1. **`db-migration`**: The issue labels include `db-migration`, OR the description contains a **Database Migration** section with **Migration Script (Source Code)** and **Before/After SQL** subsections
+2. **`performance`**: The issue labels include `performance-optimization`, OR the description contains **Baseline Metrics**, **Target Metrics**, and **Performance Test Requirements** sections
+3. **`standard`**: Otherwise
+
+`db-migration` is a specialization of `performance` — it runs all performance steps (including Step 9-Perf) plus migration-specific implementation and self-verification substeps. db-migration tasks carry the `performance-optimization` label for Epic grouping.
+
+Label-based detection covers tasks created by `performance-plan-optimization`. Description-based detection is the fallback for manually created tasks.
+
+Performance and db-migration tasks follow the same implementation flow as standard tasks, with additional performance testing after functional tests (Step 9-Perf) and performance-aware commit/PR formatting.
 
 Also capture the issue's `webUrl` field from the API response (e.g. `https://redhat.atlassian.net/browse/PROJ-231`). This URL will be used later to create a clickable link in the PR description.
 
@@ -321,7 +339,13 @@ Registry (e.g., `<Path>/CONVENTIONS.md`). If present, read it and follow its con
 throughout implementation. This includes naming rules, directory structure for new files,
 code patterns, and test conventions.
 
-This step is optional — if `CONVENTIONS.md` does not exist, proceed normally.
+**Standard tasks (`task_type = standard`):** This step is optional — if `CONVENTIONS.md` does not exist, proceed normally.
+
+**Performance tasks (`task_type = performance`):** CONVENTIONS.md is **mandatory**. If the file does not exist at the repository root, halt immediately:
+
+> "Performance optimization requires CONVENTIONS.md with at minimum: CI check commands, performance test commands, and regression thresholds. Create it before proceeding."
+
+**Stop execution immediately.** Do not proceed with any subsequent steps.
 
 #### Verification commands extraction
 
@@ -489,6 +513,13 @@ code (utilities, helpers, shared modules). If they do, use or extend the existin
 discover additional reusable code during implementation that was not listed, prefer reusing it
 over creating duplicated logic.
 
+**Prefer idiomatic types:** Before building behavior manually on a general-purpose container
+(e.g., sort + dedup on a list), check if the language's standard library has a type that
+provides that behavior directly (e.g., `BTreeSet` for sorted unique elements, `set` for
+uniqueness, `map`/`dict` for keyed lookup). Use the type that matches the actual requirement.
+When indexed access, insertion order, or duplicates are needed, the general-purpose container
+is correct.
+
 **Follow conventions:** Apply the conventions discovered during Step 4's convention conformance
 analysis. When writing new code, match the patterns found in sibling files rather than inventing
 new approaches. If any Implementation Notes or task instructions conflict with a discovered
@@ -590,6 +621,18 @@ on the backend repo to perform the same verification.
 > - `DELETE /api/v2/sbom/{id}` — path ✗ — **MISMATCH** (backend uses `/api/v2/sboms/{id}` with trailing 's', see `modules/fundamental/src/sbom/endpoints/mod.rs:48`)
 > - `GET /api/v2/risk-assessment/group/{groupId}` — sort order ✗ — **MISMATCH** (frontend picks `assessments[0]` expecting newest, but backend returns `ORDER BY created_at ASC` — oldest first, see `modules/risk/src/assessment/endpoints/mod.rs:92`)
 
+### Database migration implementation (db-migration tasks only)
+
+When `task_type = db-migration`: the task description contains both raw SQL (for manual verification) and framework migration code (for implementation). Write the **framework-level code**, not the raw SQL.
+
+1. **Read CONVENTIONS.md** — mandatory for `db-migration` tasks. Extract migration conventions: naming patterns, file structure, index naming, transaction handling, registration patterns. If CONVENTIONS.md is missing → halt with: "CONVENTIONS.md is required for db-migration tasks. Document migration patterns before proceeding."
+2. **Validate task migration against conventions** — compare the migration script from the task's **Migration Script (Source Code)** section against CONVENTIONS.md patterns. If the task script deviates from documented conventions, adapt the script to match conventions rather than writing it verbatim. Log any adaptations made.
+3. **Scan existing migrations for pattern consistency** — read 2-3 recent migration files in the repository. If CONVENTIONS.md and existing practice diverge, follow existing practice and flag the convention gap.
+4. **Create migration file** at the convention-aligned path. Register with the framework (e.g., add to SeaORM's `lib.rs` migration list, chain Alembic revision, register in TypeORM config).
+5. **Apply ORM/query builder rewrites** if the task includes query changes (not just index additions) — translate the Before/After SQL into equivalent framework code at the source locations specified in Files to Modify.
+6. **Run test suite** to verify no regressions. Run migration locally if a dev database is available.
+7. **Present manual verification to user (BLOCKING)** — extract the Before/After SQL, Migration Up/Down SQL, EXPLAIN ANALYZE verification command, and **Storage Impact** queries from the task description's **Database Migration** section. Present all available artifacts to the user in a single block so they can run them against their database to validate the change. If any artifacts are missing from the task description, warn about the missing artifacts but still present what is available. This step is mandatory — prompt the user to confirm before proceeding: (1) Verified — proceed, (2) Need to run queries — pause, (3) Skip verification. Do not continue to code quality checks, self-verification, or commit without the user's explicit response.
+
 ### Code quality practices
 
 After implementing code changes, verify the following quality practices:
@@ -614,6 +657,8 @@ After implementing code changes, evaluate whether documentation needs updating:
 
 ## Step 7 – Write Tests
 
+**If the task has no Test Requirements section:** Skip test writing. Proceed to Step 8.
+
 Implement the tests described in Test Requirements.
 
 **Follow test conventions:** Apply the test conventions discovered during Step 4's test
@@ -680,9 +725,23 @@ Fix any failures before proceeding.
 
 ## Step 8 – Verify Acceptance Criteria
 
+**If `task_type = performance`:** Skip — acceptance is verified via performance target checking in Step 9-Perf. Proceed to Step 8.5.
+
 Go through each Acceptance Criterion and verify it is satisfied.
 If any criterion cannot be met, stop and explain to the user.
 
+## Step 8.5 – Run Functional Tests (Performance Tasks)
+
+**If `task_type = standard`:** Skip — tests were already run in Step 7.
+
+**If `task_type = performance`:** Run functional tests to verify the optimization doesn't break existing behavior.
+
+**Test command resolution (in priority order):**
+1. **CONVENTIONS.md CI checks section** (extracted in Step 4) — use these commands first if available. CONVENTIONS.md is mandatory for performance tasks, so this section should exist.
+2. **Framework fallback** — if CONVENTIONS.md has no test command, determine from `metadata.analysis_scope` and backend framework: Frontend/Node.js: `npm test`, Rust: `cargo test`, Java: `./gradlew test` or `mvn test`, Python: `pytest`.
+
+**Do not proceed to Step 9-Perf until functional tests pass.** Fix failures and re-run.
+
 ## Step 9 – Self-Verification
 
 Before committing, verify that all changes are in scope and free of common errors.
@@ -1058,6 +1117,129 @@ Output the contract verification, sibling parity, cross-module shared entity, an
 >   - New code uses `window.location.reload()` — **ANOMALY** (0 of 3 callers use this pattern)
 >   - Error handling ✓ (all callers including new code use `onError` toast)
 
+### Migration safety verification (db-migration tasks only)
+
+When `task_type = db-migration`, verify each migration file created:
+
+1. **No destructive DDL** — scan for `DROP TABLE`, `DROP COLUMN`, `DELETE FROM`, `TRUNCATE`. Any of these is a blocking issue — fix before proceeding.
+2. **Rollback/down exists** — verify the migration has a corresponding rollback (SeaORM `down()`, Diesel `down.sql`, Alembic `downgrade()`, TypeORM `down()`, Flyway: note rollback is not natively supported — document as known limitation).
+3. **Naming convention** — verify migration file name and index names follow CONVENTIONS.md patterns and match existing migration naming in the repository.
+4. **Query equivalence** — if query rewrites were applied (not just index additions), verify the new query produces equivalent results: same columns, same filtering logic, same ordering. Cross-reference with the Before/After SQL from the task description.
+5. **Regression test execution (MANDATORY)** — run the existing test suite (unit, integration, e2e) that covers the affected table(s). If CI check commands from CONVENTIONS.md already include test execution, no separate run is needed. If they do not, run the project's test suite explicitly. This is a hard stop — do not proceed to commit if any test fails.
+
+Do NOT require `CONCURRENTLY` in framework migration files — most migration runners wrap in transactions where `CONCURRENTLY` is invalid. `CONCURRENTLY` belongs in the manual verification SQL only.
+
+### Root cause elimination check (performance tasks only)
+
+When `task_type = performance` or `task_type = db-migration`, verify that the specific
+root cause described in the task is actually eliminated:
+
+1. **Extract root cause pattern**: re-read the task's **Description** section and identify
+   the stated root cause (e.g., "iterates sequentially over all matched SBOM rows",
+   "loads ALL matching nodes into memory then slices", "per-node DB query in loop").
+   Extract the concrete code pattern described (function name, loop structure, query
+   call site).
+2. **Search for root cause pattern**: search for the root cause pattern in the files
+   named in the task's **Files to Modify** section and any files matching the root
+   cause function name — not only files in `git diff --name-only`. The failure mode
+   this check catches is precisely the case where the root cause loop was *not*
+   modified (new batch code was added elsewhere while the original sequential code
+   remained untouched). Use Grep or Serena `search_for_pattern`.
+3. **Evaluate**:
+   - **Pattern eliminated**: proceed silently.
+   - **Pattern still present**: flag to the user: "The root cause pattern described in
+     the task — `{pattern}` at `{file}:{line}` — still exists after implementation.
+     The implementation added optimizations inside the pattern but did not eliminate
+     the pattern itself. This may mean the optimization is incomplete." Present
+     options: (1) Refactor to eliminate the pattern, (2) Proceed — the remaining
+     pattern is acceptable, (3) Stop for review.
+   - **Pattern moved/renamed**: if the pattern was refactored but an equivalent
+     sequential structure exists, flag it the same way.
+
+Do not auto-block — present the finding and let the user decide. This check catches
+the class of error where batch helpers are added inside a sequential loop without
+eliminating the loop itself.
+
+## Step 9-Perf – Performance Testing Phase
+
+**Runs after Step 9 when `task_type = performance` or `task_type = db-migration`.** Standard tasks skip this section. Performance and db-migration tasks complete Step 9 (self-verification, CI checks, scope containment) first, then continue here for metric verification.
+
+**CONVENTIONS.md cross-reference:** The regression thresholds, performance test commands, and CI check commands extracted from CONVENTIONS.md in Step 4 apply throughout this phase. If CONVENTIONS.md defines custom regression thresholds (e.g., under a "Performance Thresholds" or "Regression Limits" section), use those instead of the defaults in Step 9-Perf.4. If CONVENTIONS.md defines performance test commands, run them after functional tests and before metrics capture.
+
+### Step 9-Perf.0 – Baseline Freshness Check
+
+Read `metadata.baseline_commit_sha` from `performance-config.json`. If workflow files changed since that commit, prompt: (1) Continue with existing baseline, (2) Re-baseline first (`/sdlc-workflow:performance-baseline`), (3) Cancel.
+
+### Step 9-Perf.1 – Capture Current Performance Metrics
+
+Read `metadata.baseline_mode` and `metadata.metric_type` from config. Use the same capture mode as the original baseline.
+
+**Plugin root resolution** for all bash blocks in this section:
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then echo "❌ sdlc-workflow plugin not found"; exit 1; fi
+```
+
+**Frontend/hybrid (Playwright):** Copy `capture-baseline.template.mjs` from plugin cache to baseline directory. Read `metadata.capture_target` from config before `dev_environment.frontend.port`.
+
+- **null/missing/`localhost`:** use `--port` from `dev_environment.frontend.port` (backward compatible with pre-hosted configs)
+- **`hosted`:** read `metadata.capture_base_url`. If null/empty → halt: "Re-run `/sdlc-workflow:performance-baseline` or `perf-config.py set metadata.capture_base_url <url>`." If present → **blocking prompt**: "Baseline captured against hosted environment (`{url}`). (1) Continue with hosted target — will prompt for auth, (2) Switch to localhost — uses `dev_environment.frontend.port`, metrics may not be comparable to hosted baseline, (3) Cancel." If switch: use localhost for this capture only, do NOT overwrite `metadata.capture_target`. Prompt for auth (`--storage-state` or `--user`/`--pass`) and `--insecure` when continuing with hosted.
+
+Construct command mirroring performance-baseline Step 9.3 — absolute `--config` path, `--storage-state`/`--user`/`--pass` mutual exclusivity, omit auth for public hosted apps, `BASELINE_PASS` env var. Parse JSON output for LCP, FCP, DOM Interactive, Total Load Time.
+
+Verification failed → display script diagnostics, halt. Do not retry.
+
+**Backend/hybrid:** Use `perf-benchmark.sh` — the same tool baseline uses, ensuring apples-to-apples comparison:
+```bash
+"$plugin_root/scripts/perf-benchmark.sh" \
+  --port "$(python3 "$plugin_root/scripts/perf-config.py" get dev_environment.backend.port)" \
+  --iterations "$(python3 "$plugin_root/scripts/perf-config.py" get baseline_settings.iterations)" \
+  --manifest performance/test-data/manifest.json \
+  --output "$(python3 "$plugin_root/scripts/perf-config.py" get directories.optimization_results)/${jira_key}-benchmark.json"
+```
+
+**Prerequisites:** Verify manifest exists and backend is running on configured port before executing. If either is missing, halt with remediation.
+
+### Step 9-Perf.2 – Compare Against Baseline and Targets
+
+Compare only metrics listed in the task's **Target Metrics** section (from Step 1 parsing). Do not compare metrics that are not listed — they are out of scope for this optimization.
+
+**Unit note:** Task metrics are in milliseconds. If reading baseline values from `optimization_targets` in config, multiply by 1000 (config stores frontend metrics in seconds).
+
+For each listed metric: calculate improvement (`baseline - current` for latency/size, `current - baseline` for throughput) and progress to target (`improvement / (baseline - target) × 100`).
+
+### Step 9-Perf.3 – Generate Comparison Table
+
+```markdown
+| Metric | Baseline | Current | Target | Improvement | Progress |
+|---|---|---|---|---|---|
+| {metric} | {baseline} | {current} | {target} | {delta} ({pct}%) | {progress}% |
+```
+
+### Step 9-Perf.4 – Verify Targets and Handle Regressions
+
+Apply target and regression checks **only to metrics listed in the task's Target Metrics section** (same scope as Step 9-Perf.2). Metrics not listed are out of scope — do not flag regressions on them.
+
+**Noise tolerance (both gates must be exceeded to flag regression):**
+
+Check CONVENTIONS.md first — if it defines a "Performance Thresholds" or "Regression Limits" section with custom thresholds, use those values. Otherwise use these defaults:
+
+| Category | Relative | Absolute |
+|---|---|---|
+| Frontend time (LCP, FCP, DOM Interactive) | >5% | >50ms |
+| Frontend size (bundle, transfer) | >5% | >10KB |
+| Backend response time (p95, p99) | >10% | >50ms |
+| Backend throughput | >20% decrease | — |
+| Backend error rate | — | >1% increase |
+
+**Results:** All targets met → proceed. Improved but not all met → proceed, flag in Jira. Regression beyond noise → execute recovery:
+
+**Regression Recovery:** Save regression report to `{opt_results_dir}/{jira_key}-regression-{timestamp}.md`. Prompt user (blocking): (1) Stash changes and stop (recommended), (2) Proceed with warning. If stash: `git stash push -m "perf-regression-stash: ${jira_key}"` and stop. If proceed: set `status: regression_acknowledged`.
+
+### Step 9-Perf.5 – Create Optimization Result Report
+
+Read template from `${plugin_root}skills/performance/optimization-result.template.md`. Populate with: jira_key, workflow, timestamp, branch, commit SHA, baseline commit SHA, capture mode, capture target (`localhost` or `hosted`), capture base URL (URL only, null for localhost), status (`pending_verification` or `regression_acknowledged`), before/after metrics, scenarios measured, files changed. Write to `{opt_results_dir}/{jira_key}-{timestamp}.md`.
+
 ## Step 10 – Commit and Push
 
 Commit following the Conventional Commits specification (https://www.conventionalcommits.org/en/v1.0.0/):
@@ -1073,6 +1255,10 @@ Use a scope when relevant (e.g. `feat(api): add AIBOM endpoint`).
 The footer MUST reference the Jira issue ID.
 Always include `--trailer="Assisted-by: Claude Code"` to attribute AI assistance.
 
+**Performance task commit format (`task_type = performance`):** Use `perf` as the commit type and include a "Performance impact:" section in the body listing each metric and its improvement (e.g., `- LCP p95: 2400ms → 1800ms (-25%)`).
+
+**Database migration commit format (`task_type = db-migration`):** Use `perf(db)` as the commit type and include a "Migration:" section in the body listing each migration file and its purpose (e.g., `- m20260609_add_index_sbom_packages_sbom_id: CREATE INDEX on sbom_packages(sbom_id)`).
+
 **Default flow (no Target PR, no Bookend Type):**
 
 Push the branch and open a pull request. Always specify `--base <target-branch>`
@@ -1094,6 +1280,8 @@ line to the PR description body. GitHub recognizes this keyword and will auto-cl
 linked issue when the PR is merged. Do **not** add this to the commit message — only the
 PR description.
 
+**Performance task PR body (`task_type = performance`):** Additionally include a "Performance Impact" section with the before/after comparison table from Step 9-Perf.3, and a "Testing" checklist noting functional tests pass, baseline re-captured, and metrics compared against targets.
+
 **Target PR flow:**
 
 When Target PR is present, push to the existing branch and update the PR description
@@ -1147,6 +1335,8 @@ Include:
 - Summary of changes made
 - Any deviations from the plan
 
+**Performance task comment (`task_type = performance`):** Additionally include the before/after comparison table from Step 9-Perf.3, target achievement status, and next step: "Run `/sdlc-workflow:verify-pr {jira-key}` to verify results."
+
 Transition the task:
 
 jira.transition_issue → In Review
diff --git a/plugins/sdlc-workflow/skills/performance-analyze-module/SKILL.md b/plugins/sdlc-workflow/skills/performance-analyze-module/SKILL.md
new file mode 100644
index 000000000..aed8b7467
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance-analyze-module/SKILL.md
@@ -0,0 +1,886 @@
+---
+name: performance-analyze-module
+description: |
+  Inspect source code to detect performance anti-patterns by examining bundle composition, API call patterns, component structure, and resource loading.
+argument-hint: "[target-repository-path]"
+---
+
+# performance-analyze-module skill
+
+Source code analysis to detect performance anti-patterns in a user-selected workflow. Examines bundle composition, API call patterns, render logic, and resource loading.
+
+**Key Distinction:** This skill inspects source code. The `performance-plan-optimization` skill reads this analysis report and creates Jira tasks.
+
+## Guardrails
+
+- Creates files in `performance/analysis/` — does NOT modify source code
+- Requires Performance Analysis Configuration with a selected workflow and baseline report
+- Blocking step: Step 1 (target repository path, if not provided)
+- Missing config → halt, suggest `performance-setup`. Missing baseline → halt, suggest `performance-baseline`
+- Serena probe failure → do NOT halt; set `serena_mode = down`, continue with Grep
+- Finding validation (Step 9) is mandatory. Precision over volume: 10 correct findings beats 50 with 40% noise
+- Detection steps (5–8) may be delegated to subagents for parallelism. Validation (Step 9) may not — subagent output is input to validation, not input to the report
+- When delegating detection steps, the parent agent must update `analysis-progress.json` with each subagent's results before proceeding to Step 9
+- `findings-validation.json` must exist before the report is written
+
+### Plugin Root Resolution
+
+Every bash block that calls `perf-config.py` must begin with:
+
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null \
+  | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then
+  echo "❌ sdlc-workflow plugin not found"; exit 1
+fi
+```
+
+## Step 1 – Determine Target Repository
+
+Use the user-provided repository path, or the current working directory.
+
+If `performance-config.json` exists, read `metadata.analysis_scope` and verify the repository matches:
+- `backend-only`: backend indicators (Cargo.toml, pom.xml, requirements.txt, etc.)
+- `frontend-only`: frontend indicators (package.json with frontend deps, framework config)
+- `full-stack`/`full-stack-monorepo`: both sets of indicators
+
+If config doesn't exist, skip validation.
+
+## Step 2 – Verify Configuration and Selected Workflow
+
+### Step 2.0 – Read Analysis Assumptions
+
+Read `analysis_assumptions` from `performance-config.json`:
+
+```bash
+assumptions=$(python3 "$plugin_root/scripts/perf-config.py" get-section analysis_assumptions)
+```
+
+| Field | Variable | Default |
+|---|---|---|
+| `bandwidth_mbps` | `analysis_bandwidth_mbps` | 5 |
+| `api_latency_ms` | `analysis_api_latency_ms` | 100 |
+| `reflow_cost_ms` | `analysis_reflow_cost_ms` | 5 |
+| `cache_hit_rate` | `analysis_cache_hit_rate` | 0.8 |
+| `chain_depth` | `analysis_chain_depth` | 3 |
+| `db_latency_ms` | `analysis_db_latency_ms` | 10 |
+
+Validate each value (positive numbers, `cache_hit_rate` 0.0–1.0, `chain_depth` 1–5). Use defaults for invalid values with a warning.
+
+### Step 2.1 – Check for Selected Workflow
+
+Extract workflow name, entry point, key screens from config. If no workflow selected → halt: "Run `performance-baseline` first."
+
+### Step 2.2 – Read Backend/Frontend Configuration
+
+Read `metadata.backend_available`. If `true`: read backend config (name, path, framework, `serena_instance`, api_base_path) + frontend config if scope includes frontend. If `false`: log frontend-only mode; backend steps (6.B, 7) will be skipped. Serena availability is determined by live probe in Step 6.B, not here.
+
+### Step 2.3 – Initialize Progress Checklist
+
+Write `{analysis_dir}/analysis-progress.json` based on `(metric_type, backend_available)`:
+
+| metric_type | backend_available | Steps → `pending` | Steps → `not_applicable` |
+|---|---|---|---|
+| `frontend` | any | 5.1-5.3, 6.1-6.9 | 6.B, 7.1-7.7, 7.3.2, 7.4.1, 7.6.1-7.6.8, 7.6.4.1, 7.8.1-7.8.4, 8.A-D, 8.F, 9.7 |
+| `backend` | `true` | 6.B, 7.1-7.7, 7.3.2, 7.4.1, 7.6.1-7.6.8, 7.6.4.1, 7.8.1-7.8.4, 9.7 | 5.1-5.3, 6.1-6.9, 8.A-D, 8.F |
+| `hybrid` | `true` | 5.1-5.3, 6.1-6.9, 6.B, 7.1-7.7, 7.3.2, 7.4.1, 7.6.1-7.6.8, 7.6.4.1, 7.8.1-7.8.4, 8.A-D, 8.F, 9.7 | (none) |
+| `hybrid` | `false` | 5.1-5.3, 6.1-6.9 | 6.B, 7.1-7.7, 7.3.2, 7.4.1, 7.6.1-7.6.8, 7.6.4.1, 7.8.1-7.8.4, 8.A-D, 8.F, 9.7 |
+
+Status values: `pending` (not yet run), `done` (completed — requires `findings` count, 0 = "no instances"), `skipped` (runtime scope guard excluded a step that could apply — requires `reason`), `not_applicable` (step does not apply to this `metric_type`/`backend_available` combo — use for all steps initialized as `not_applicable` in the table above), `optional_skipped` (user declined or prerequisites not met — requires `reason`). Use `not_applicable` (not `skipped`) for steps excluded by metric_type at initialization.
+
+Optional step rules: Step 5.1 (no bundle stats found) → `done` with `findings: 0` (estimation fallback runs). Step 7.7 (service not running) → `optional_skipped`. Step 7.8 (no DML-containing migration files found) → all 7.8.x sub-steps set to `skipped` with reason "no DML-containing migration files found." Step 9.7 guard failure → `not_applicable`; user declines → `optional_skipped`.
+
+At the end of each detection step (5.x, 6.x, 7.x, 8.x): update `analysis-progress.json` with the step's status and findings count.
+
+## Step 3 – Verify Baseline Report Exists
+
+Read `metadata.metric_type` to determine which baselines to check:
+- `frontend`/`hybrid`: check `{baseline-directory}/baseline-report.md`
+- `backend`/`hybrid`: check `{baseline-directory}/benchmark-results.json`
+
+Halt if any required baseline is missing. Verify workflow name matches between baseline and config.
+
+## Step 4 – Read Baseline Data
+
+**Frontend baseline** (if metric_type includes frontend): Extract per-scenario metrics (LCP, FCP, DOM Interactive, Total Load Time), resource timing breakdown, aggregate metrics.
+
+**Backend baseline** (if metric_type includes backend): Parse `benchmark-results.json` for per-endpoint metrics (response time percentiles, throughput, error rate, cache effectiveness).
+
+## Step 5 – Analyze Bundle Composition
+
+**Scope:** Skip if `metric_type = "backend"` (bundle composition is frontend-only). Proceed to Step 6.
+
+### Step 5.1 – Locate Bundle Stats (Optional)
+
+Check for webpack/vite bundle stats (`dist/stats.json`, `build/stats.json`, `.vite/stats.json`). If found, extract module names/sizes, third-party dependencies, code-split chunk boundaries.
+
+### Step 5.2 – Identify Third-Party Libraries
+
+From baseline resource timing, classify each JavaScript file as third-party (node_modules, vendor, CDN) or application code. Calculate size ratios. List top 10 by size.
+
+### Step 5.3 – Module-Specific vs Shared Code Ratio
+
+From bundle stats (or import pattern estimation), calculate the ratio of workflow-specific code to shared code.
+
+## Anti-Pattern Severity Reference
+
+All detection steps (6.x and 7.x) classify findings using this table. Each step says "classify per severity table" rather than restating thresholds.
+
+| Anti-Pattern | High | Medium | Low |
+|---|---|---|---|
+| Over-Fetching (6.1) | >50% unused OR >100KB+30% | 25-50% unused | <25% unused |
+| N+1 Frontend (6.2) | >10 iter sequential | 5-10 iter | <5 iter |
+| Waterfall (6.3) | depth>5 OR >1000ms chain | depth 4-5 OR 500-1000ms | depth 3 OR <500ms |
+| Render-Blocking (6.4) | load time >50% FCP OR >200KB | 25-50% FCP OR 100-200KB | <25% FCP OR <100KB |
+| Unused Code (6.5) | >100KB or >10 imports | 50-100KB or 5-10 imports | <50KB or <5 imports |
+| Re-Renders (6.6) | Critical path + DOM >3500ms | Critical path + DOM 2500-3500ms | Non-critical OR DOM <2500ms |
+| Long Tasks (6.7) | >200ms or multiple >100ms | 100-200ms | 50-100ms |
+| Layout Thrashing (6.8) | R/W in loops >10 iter | R/W in loops 5-10 iter | <5 iter or isolated |
+| Missing Lazy Load (6.9) | Route >100KB eager OR >5 routes | 50-100KB OR 3-5 routes | <50KB OR <3 routes |
+| N+1 Backend (7.3) | >10 sequential queries | 5-10 sequential | <5 or partial mitigation |
+| Missing Pagination (7.4) | No pagination, >100 items | 50-100 items | <50 items |
+| Missing Caching (7.5) | >100ms op, high traffic, static data | 20-100ms, medium traffic | <20ms or low traffic |
+| Inefficient Queries (7.6) | SELECT * >10 cols >1000 rows | Unnecessary JOINs or >50% unused cols | Minor, <25% unused |
+| Unused JOINs (7.6.1) | Large table (>10K rows) or 3+ unused | Medium table (1K-10K) | Small table (<1K) with indexes |
+| Missing Indexes (7.6.4) | JOIN/WHERE on loop query (multiplier>1) | Range filter on large table | ORDER BY or small table |
+| SQL Duplication (7.6.5) | Same CTE 3+ times or table scans | Same CTE 2 times | >50% overlap across 2 queries |
+| Seq Scan (9.7) | >10K rows in loop query | 1K-10K rows or single query | <1K rows |
+| Row Estimate Mismatch (9.7) | >100x mismatch | 10x-100x mismatch | <10x mismatch |
+| Nested Loop on Large Table (9.7) | Inner scan >10K rows | Inner 1K-10K rows | Inner <1K rows |
+| Unbounded Iteration (7.3.2) | No guard + DB queries with multiplier > 1 per iteration | No guard + single DB query per iteration | Guard exists but generous (> 1000) |
+| Cross-Table OR (7.6.7) | OR spans 3+ LEFT JOINed entities on likely-large tables | OR spans 2 LEFT JOINed entities | Small reference tables only |
+| Load-All-Then-Search (7.6.8) | Simple search criteria, known at query time, user-facing | Partially known criteria | Bounded data or reused collection |
+| Late Pagination (7.4.1) | Unbounded load + post-load slice | Bounded load + post-load slice | Small collection or admin-only |
+| Redundant Indexes (7.6.4.1) | Exact duplicate on junction/relationship table | Exact duplicate on regular table | Exact duplicate on small table |
+| Recursive CTE Risk (7.6.2) | Junction table, no depth limit | Junction table, depth limit present | Entity table or tight limit (< 10) |
+| Missing Statistics Refresh (7.8.1) | Backfill on >1M rows or 3+ table JOIN | Backfill on 2 tables or with function | Simple single-table INSERT...SELECT |
+| Non-Materialized CTE (7.8.2) | CTE with function call, 3+ references | CTE with function, 2 references | CTE with simple aggregate, 2 references |
+| Uniform Processing (7.8.3) | >1M rows, <10% need processing | Medium table, <50% need processing | Skip ratio unclear |
+| Expensive PL/pgSQL Pattern (7.8.4) | Dynamic regexp in loop on >10K rows | Dynamic regexp unclear N, or EXECUTE in loop | RAISE NOTICE in loop or small-N |
+
+**Impact formulas** (use throughout):
+- Over-fetching: `(unused/total) × response_size ÷ (bandwidth_mbps × 125000)`
+- N+1: `(iterations - 1) × api_latency_ms` (frontend) or `× db_latency_ms` (backend)
+- Waterfall: `chain_time - (slowest × 1.2)`
+- Layout thrashing: `(iterations - 1) × reflow_cost_ms`
+- Caching: `operation_time × cache_hit_rate`
+- Cross-Table OR: heuristic only — "Actual impact depends on table sizes (verify with EXPLAIN in Step 9.7)." Do not produce numeric `impact_ms`
+
+## Step 6 – Detect Frontend Anti-Patterns
+
+**Scope:** Skip if `metric_type = "backend"` (jump to Step 6.B). Run for `frontend` or `hybrid`.
+
+Impact estimates are heuristics for prioritization — verify after implementation.
+
+### Step 6.1 – Over-Fetching Detection
+
+Search workflow components for API calls (`fetch(`, `axios.get(`, `useQuery(`). For each endpoint, identify the response schema and grep for field usage in consuming components. Flag fields in the response that are never referenced.
+
+Confidence: Low (grep cannot track destructuring, prop drilling, or dynamic access).
+
+**Advisory drift check (hybrid only):** If `workflow.traced_api_endpoints` exists, compare endpoints discovered here against that list. Log as informational notes (not findings, not blocking):
+- Endpoint in Step 6.1 but NOT in traced list → "API call `{url}` in `{file}` not in baseline trace — baseline may need refresh"
+- Endpoint in traced list but NOT in Step 6.1 → "Traced API `{path}` not found in current source — may have been removed"
+
+These are advisory only. Code changes between baseline and analysis are normal. Do not halt or create findings from drift.
+
+### Step 6.2 – N+1 Query Detection (Frontend)
+
+Search for loops (`.forEach(`, `.map(`, `for (`) with API calls (`fetch(`, `axios.`) within 10 lines. Check if `await` is inside the loop (sequential) vs `Promise.all` (parallel). Also check `useQuery`/`useQueries` calls without `staleTime` — default `0` causes refetch on every mount.
+
+### Step 6.3 – Waterfall Loading Detection
+
+From baseline resource timing, build a dependency graph. Identify chains of >3 sequential resources. Calculate waterfall depth and total chain time.
+
+### Step 6.4 – Render-Blocking Resources Detection
+
+Search HTML entry points for `<script src=` without `async`/`defer` and `<link rel="stylesheet"` without non-blocking attributes. Cross-reference blocking resource load times against FCP/LCP.
+
+### Step 6.5 – Unused Code Detection
+
+Extract all `import` statements from workflow components. Search for usage of each imported symbol in the file body. Flag imports never referenced. Estimate unused bundle size from stats or typical module sizes.
+
+### Step 6.6 – Expensive Re-Render Detection
+
+Identify component hierarchy in workflow routes. Search for missing memoization (React: `React.memo`, `useMemo`, `useCallback`; Vue: `computed`, `watch`). Flag components receiving complex props without memoization, inline functions as props, missing `key` in lists. Prioritize components in the critical render path.
+
+### Step 6.7 – Long Task Detection
+
+Check baseline for resource timing data. Grep for expensive patterns — synchronous loops over large datasets, JSON.parse of large payloads, DOM manipulation in loops, spread inside `.reduce()` (O(n²) memory: `[...prev,` patterns).
+
+### Step 6.8 – Layout Thrashing Detection
+
+Search for DOM read-write patterns: reading layout properties (`offsetWidth`, `getBoundingClientRect`) followed by writes (`style.width =`, `classList.add`) inside loops. Static analysis cannot determine execution ordering — only flag patterns where read-write appears inside a loop.
+
+### Step 6.9 – Missing Lazy Loading Detection
+
+Check route configuration for dynamic imports (React: `React.lazy`, Vue: `() => import(...)`, Next.js: `dynamic()`). Flag routes using static imports for large components. Estimate component sizes from bundle stats or file size.
+
+## Step 6.B – Serena Availability Probe
+
+Runs for `metric_type = "backend"` or `"hybrid"` when `backend_available = true`.
+
+Read `serena_instance` from config. If non-empty, call `mcp__{serena_instance}__get_symbols_overview` with `relative_path="."`:
+- Response received → `serena_mode = live`
+- Error → `serena_mode = down`, log error
+- No serena_instance → `serena_mode = not-configured`
+
+`serena_mode` applies to all of Step 7. Use Serena when `live`, grep/Read otherwise.
+
+## Step 7 – Backend Source Code Analysis
+
+**Runs when `backend_available = true` and `metric_type` is `backend` or `hybrid`.**
+
+**Endpoint source (scope-aware):** Step 7 does not run for `metric_type = "frontend"` (frontend-only skips backend analysis).
+- `metric_type = "backend"`: Iterate endpoints from `performance-config.json` scenarios (populated by baseline's Step 3 backend discovery). Step 6.1 was skipped; config scenarios are the authoritative endpoint list.
+- `metric_type = "hybrid"`: Iterate endpoints from `workflow.traced_api_endpoints` (populated by baseline Step 4.8 frontend-to-backend API tracing). These are the specific backend APIs that the selected frontend workflow calls. Fallback: if `traced_api_endpoints` is empty (backward compat with older configs), use config scenarios with `type: "backend"` instead.
+
+For EACH endpoint from the source above:
+
+### Tool Selection (applies to all Step 7.x sub-steps)
+
+| serena_mode | Tool | Confidence |
+|---|---|---|
+| `live` | `mcp__{serena_instance}__find_symbol(...)` with `include_body=true` | High |
+| `down` / `not-configured` | Grep across backend_path + Read tool | Medium |
+
+### Step 7.1 – Locate Backend Handler
+
+Search for handler by endpoint path fragment. Extract handler function name and file location. If not found, document limitation and skip to next endpoint.
+
+### Step 7.2 – Extract Backend Response Schema
+
+Read handler implementation and identify return type from function signature. Find and read the response struct/class definition. Extract ALL fields recursively including nested objects.
+
+Document complete response schema:
+```
+Endpoint: GET /api/v2/products/:id
+Response Type: ProductResponse
+Fields: id, name, description, price, inventory{quantity, warehouse_location}, created_at, ...
+```
+
+### Step 7.3 – Detect Backend N+1 Queries
+
+Read handler implementation. Search for query patterns inside loops:
+
+| Framework | N+1 Pattern |
+|---|---|
+| Rust (sqlx) | `for item in items { query!(..., item.id).fetch_one(&pool).await }` |
+| Rust (SeaORM) | `for item in items { Entity::find_by_id(item.id).one(&db).await? }` |
+| Rust (Diesel) | `for item in items { table.find(item.id).first::<Model>(&conn)? }` |
+| Java (JPA) | `for (Item item : items) { repository.findById(item.getId()) }` |
+| Python (SQLAlchemy) | `for item in items: session.query(Model).filter(...).first()` |
+| Node (TypeORM/Prisma) | `for (const item of items) { await db.model.findUnique({...}) }` |
+
+**NOT N+1** (concurrent execution — do NOT flag):
+- JS: `Promise.all([...])`, `Promise.allSettled([...])`
+- Rust: `tokio::try_join!`, `join_all(futures)`, `buffer_unordered(n)`, `for_each_concurrent`, `FuturesUnordered`
+- Java: `CompletableFuture.allOf(...)`, `.parallelStream()`
+- Python: `asyncio.gather(...)`, `ThreadPoolExecutor.map(...)`
+
+**Partial mitigation:** Sequential outer loop with concurrent inner calls — classify as N+1 with note about inner concurrency.
+
+**Loop origin identification:** For each N+1 finding, identify the **outermost loop that drives the query multiplication** — not just the inner query call site. Record:
+- `loop_function`: the function containing the loop (name, file, line)
+- `loop_variable`: what is being iterated (e.g., `rows`, `items`, `matches`)
+- `loop_source`: what produces the iteration set (e.g., "result of `load_graphs_query`", "parameter `rows: Vec<Row>`")
+- `loop_nesting`: whether the N+1 query is in the outermost loop or a nested inner loop
+
+Include this as `loop_origin` in the finding output. This distinguishes "the loop itself must be eliminated" from "only the inner query needs batching."
+
+### Step 7.3.1 – Detect Pre-Fetchable Concurrent Query Patterns
+
+Concurrent execution patterns (`buffer_unordered`, `Promise.all`, `asyncio.gather`, etc.) are correctly exempt from N+1 classification — they don't cause sequential latency stacking. However, they can still generate **O(N) DB queries** when each concurrent task makes per-item database calls. These are pre-fetch opportunities: the per-item queries could be replaced by a single batch pre-fetch before the concurrent processing starts.
+
+**Detection:** This check runs as part of deep chain analysis (Step 7.6.2) when a concurrent iteration construct is encountered — it is placed here for classification context, but executes during Step 7.6.2's recursive tracing. For each concurrent iteration pattern found, check whether the concurrent body contains DB queries:
+
+| Framework | Concurrent Per-Item Pattern |
+|---|---|
+| Rust | `stream::iter(items).map(async \|item\| { Entity::find().filter(...item...).one(conn).await }).buffer_unordered(n)` |
+| Rust | `stream::iter(items).map(async \|item\| { resolve_something(item.id, conn).await }).buffer_unordered(n)` |
+| JS | `Promise.all(items.map(async item => { await db.model.findOne({...item...}) }))` |
+| Python | `asyncio.gather(*[fetch_one(item.id) for item in items])` |
+| Java | `items.parallelStream().map(item -> repository.findById(item.getId()))` |
+
+**Classification:** Flag as anti-pattern type `Pre-Fetchable Concurrent Queries` with severity based on the query count:
+- High: >50 concurrent per-item queries (estimated from collection size × queries per item)
+- Medium: 10-50 concurrent per-item queries
+- Low: <10 concurrent per-item queries
+
+**Finding output:** Include `prefetch_opportunity: true`, the concurrent construct (e.g., `buffer_unordered(self.concurrency)`), the per-item queries (function names and DB entities accessed), and the data source that produces the iteration set. This is consumed by plan-optimization to generate a pre-fetch mandate.
+
+**Distinguish from fixed-set concurrency:** Do NOT flag concurrent execution over a **fixed, small set** of known operations (e.g., `tokio::try_join!(query_a, query_b, query_c)` or `Promise.all([fetchUser(), fetchProfile(), fetchSettings()])`). Only flag concurrent iteration over a **dynamic collection** whose size scales with input data.
+
+### Step 7.3.2 – Detect Unbounded Query-Driving Iteration
+
+Detects loops iterating a query result set of unknown/unbounded size where each iteration triggers DB queries, with no `.take(N)`, `if len > MAX`, or LIMIT guard.
+
+**Detection:** Find loops (`for item in collection`) where `collection` is a query result (Vec from `.all()`, `.fetch_all()`, etc.) and the loop body calls DB queries (direct or via function calls). Check for size guards before the loop.
+
+| Framework | Unbounded Iteration Pattern |
+|---|---|
+| Rust (SeaORM) | `let items = Entity::find().all(conn).await?; for item in items { OtherEntity::find_by_id(item.ref_id).one(conn).await? }` |
+| Rust (sqlx) | `let rows = query!(...).fetch_all(&pool).await?; for row in rows { query!(..., row.id).fetch_one(&pool).await? }` |
+| Java (JPA) | `List<Item> items = repo.findAll(); for (Item i : items) { repo2.findById(i.getRefId()) }` |
+| Python (SQLAlchemy) | `items = session.query(Model).all(); for item in items: session.query(Other).get(item.ref_id)` |
+| Node (TypeORM) | `const items = await repo.find(); for (const i of items) { await repo2.findOne(i.refId) }` |
+
+**NOT unbounded:** Loop has `.take(N)` or `[..N]` before iteration, or an `if collection.len() > MAX { return Err(...) }` guard, or collection comes from a query with explicit `.limit()`.
+
+**Severity:** Classify per severity table.
+
+**Finding output:** Include `loop_source` (what produces the unbounded collection), `guard_check` (present/absent/generous), `query_count_per_iteration`.
+
+### Step 7.4 – Detect Missing Pagination
+
+Check if collection endpoints (`Vec<T>`, `List<T>`) have pagination parameters (`page`, `limit`, `offset`) and query methods (`.limit()`, `.offset()`, `setMaxResults()`).
+
+### Step 7.4.1 – Late Pagination Detection
+
+If pagination parameters are found (Step 7.4), trace where they are consumed. If they flow into a post-load slicing operation (`paginate_array()`, `[offset..offset+limit]`, `.skip(n).take(n)` on an in-memory collection) rather than into the SQL query (`.limit()`, `.offset()`, `LIMIT $1 OFFSET $2`), flag as "Late Pagination."
+
+| Framework | Late Pagination Pattern |
+|---|---|
+| Rust | `let all = service.load_all(conn).await?; paginated.paginate_array(&all)` |
+| Java | `List<T> all = service.findAll(); return all.subList(offset, offset + limit)` |
+| Python | `all_items = service.get_all(); return all_items[offset:offset+limit]` |
+| Node | `const all = await service.findAll(); return all.slice(offset, offset + limit)` |
+
+**NOT late pagination:** Pagination parameters flow into `.limit()`, `.offset()`, or `LIMIT $1 OFFSET $2` in the SQL query itself.
+
+**Evidence:** Identify both (a) the pagination parameter source and (b) the consumption point. Report the gap: "Pagination exists at API layer but is applied after loading N items into memory."
+
+**Severity:** Classify per severity table.
+
+### Step 7.5 – Detect Missing Caching
+
+Identify expensive operations (DB queries for static data, external API calls, complex computations). Check for cache usage by framework:
+
+| Framework | Cache Indicators |
+|---|---|
+| Rust | `moka`, `redis-rs`, `cached` crate, `Cache`, `lazy_static!` with HashMap |
+| Java | `@Cacheable`, `Caffeine`, `Redis` |
+| Python | `@lru_cache`, `@cached`, `Redis` |
+| Node | `node-cache`, `Redis`, `memory-cache` |
+
+### Step 7.6 – Detect Inefficient Queries
+
+Extract SQL queries or ORM calls from handler. Flag `SELECT *` or equivalent. Cross-reference queried fields with response schema (Step 7.2). Check for missing indexes on WHERE/JOIN columns.
+
+### Step 7.6.1 – Detect Unused Table Joins
+
+For each query with JOINs:
+
+1. **Extract** base table, joined tables, join type, join condition
+2. **Check field usage** from joined tables: SELECT clause, WHERE/HAVING, handler code, response schema
+3. **Classify:**
+   - **UNUSED** — no fields from joined table used anywhere → remove JOIN
+   - **FILTER-ONLY** — joined table used only in WHERE → replace with subquery/EXISTS
+4. **Estimate impact:** INNER JOIN +10-30ms, LEFT JOIN +15-40ms, unindexed JOIN +50-500ms per request
+
+### Step 7.6.2 – Deep Service Chain Analysis
+
+Trace function calls from each handler into service methods, model builders, and utilities to detect anti-patterns hidden below the handler layer.
+
+**Depth:** Use `analysis_chain_depth` (default 3) from config.
+
+**Auto-extension on pure delegation:** When the depth limit is reached on a function that consists entirely of delegating to another function — i.e., it calls a single other function and returns its result without transformation (e.g., `self.inner.method(args)`, `self.0.method(args)`) — extend the depth limit by 1 for that call path. Apply recursively up to `chain_depth + 3` (hard cap). This ensures deeply layered architectures (common in Rust with inner/outer service patterns) don't hide the actual query site. **Delegation indicators:** Function body has ≤ 3 statements, the last of which is a return/tail-call to another method. No loops, no conditionals branching to different query paths.
+
+**For each handler**, initialize `call_graph = []`, `visited = {handler}`, `query_ledger = []`, `depth = 0`.
+
+**Recursive tracing:** For each call site in function body, resolve the callee (`self.method` → same impl, `service.method` → resolve type, trait methods → concrete impl). Use Serena `find_symbol`/`find_declaration` when live, grep+Read otherwise.
+
+For each resolved callee: check cycle/depth limit, read body, apply anti-pattern checks (N+1, unused JOINs, SELECT *, missing caching). Special cases:
+- **Cache-guarded paths:** `.get(key)` + early return + `.insert(key, value)` on miss → annotate as `cache_gated: true`. Confirm it's a cache (type contains Cache/Lru/Ttl, known crate), not a dedup set
+- **Conditional queries:** `Memo<T>`/`Option<T>` params where one branch triggers a query — check what caller passes
+- **Model builders:** Always trace into `from_entity`/`from_row`/`from_model`/`new`
+- Add queries to `query_ledger` with depth, loop multiplier, source. Recurse at `depth + 1`
+
+**Persist Query Ledger:**
+
+After building the query ledger, write `{analysis_dir}/query-ledger.json`. This structured artifact is consumed by Step 9.7 (live SQL analysis) and must exist before Step 9.7 runs.
+
+Schema: `[{query_id, description, source_file, source_line, depth, loop_multiplier, orm_snippet, raw_sql, query_type, is_literal_sql, is_recursive_cte, target_table, depth_limit, table_pattern}]`
+- `is_literal_sql`: `true` for `query!()` macros, `@Query`, raw SQL strings. `false` for ORM builder chains.
+- `query_type`: SELECT, INSERT, UPDATE, DELETE, or UNKNOWN.
+- `is_recursive_cte`: `true` when raw SQL contains `WITH RECURSIVE`. Default `false`.
+- `target_table`: The table referenced in the recursive CTE's base case (e.g., `package_relates_to_package`). Only set when `is_recursive_cte: true`.
+- `depth_limit`: The depth limit extracted from the SQL (e.g., `100` from `WHERE depth < 100`), or `"none"` if no limit found. Only set when `is_recursive_cte: true`.
+- `table_pattern`: `"junction"` if the target table appears to be a junction/relationship table (compound PK with 2+ FK columns, or table name containing `relates`, `relationship`, `edge`, `link`, `closure`), otherwise `"entity"`. Only set when `is_recursive_cte: true`.
+
+**Recursive CTE risk flagging:** When `is_recursive_cte: true`, flag as a scale risk finding with anti-pattern type `Recursive CTE Risk`. Classify severity per the severity table. Include `target_table`, `depth_limit`, and `table_pattern` in the finding output.
+
+**Outputs:** Call graph (tree format: `endpoint → service → model [file:line] ← N queries`) and query ledger table (per-query: description, source, depth, loop multiplier, conditional†, cache-gated‡, effective count; totals for all and warm-cache).
+
+**Multiplier propagation:** Walk call_graph root→query; multiply by all loop multipliers on the path. **Estimated total DB latency:** `total_queries × db_latency_ms`.
+
+**Zero-result check:** If a bulk fetch (`WHERE id IN (?)`) is keyed on IDs from a preceding query that can return zero results, check whether the fetch is guarded (`if ids.is_empty() { return }`) or fires unconditionally. Flag unconditional empty-set queries as wasted computation (Medium severity).
+
+### Step 7.6.3 – Wasted Computation Detection
+
+For each handler, compare fields accessed from the service call return value against the full return type. If handler uses <50% of returned fields and unused portion involves queries (from call graph), flag as wasted computation with the query cost.
+
+### Step 7.6.4 – Missing Index Detection
+
+Cross-reference WHERE/JOIN/ORDER BY columns from query_ledger against migration files. Build an index registry from `CREATE INDEX`, `.create_index()`, primary keys. Flag columns with no covering index.
+
+**Table registry validation:** Also build a **table registry** from migration DDL (`CREATE TABLE` statements and `.create_table()` calls). Before flagging a missing index, confirm the target table exists in the table registry. If not found, record the gap in the finding's reason (e.g., "table `foo` not found in migration files — verify manually"). This feeds into Step 9.1-B check 5 which greps migration files for factual claims.
+
+Tables from live EXPLAIN findings (Step 9.7.4) are inherently validated — the query executed successfully against the database.
+
+### Step 7.6.4.1 – Redundant Index Detection
+
+After building the index registry (Step 7.6.4), compare all index entries for the same table. Flag as redundant when:
+
+1. Two indexes have **identical column sets** (regardless of name)
+2. A non-PK index duplicates the primary key columns exactly
+
+**NOT redundant (do not flag):**
+- A shorter single-column index that is a prefix of a multi-column index. The shorter index can be legitimately faster for queries filtering only on that column (smaller index, index-only scans). Only flag prefix indexes as redundant when the query ledger shows zero queries that use the shorter index without also using the additional columns of the longer one.
+- Indexes with different column orderings (different leading columns serve different query patterns).
+
+**Severity:** Classify per severity table. Base severity on table pattern: junction/relationship tables (compound FK columns) are likely large, regular entity tables are medium, small reference/lookup tables are low.
+
+### Step 7.6.5 – Inter-Query Duplication Detection
+
+Collect raw SQL for all queries in each handler's ledger. Extract CTE names and subquery aliases. Flag CTEs/subqueries appearing in 2+ queries with identical or semantically equivalent SQL bodies. Estimate overhead: `(occurrences - 1) × db_latency_ms`.
+
+### Step 7.6.6 – Cache Effectiveness Analysis
+
+For endpoints with a confirmed cache AND baseline cache data: partition query_ledger into cache-gated vs cache-bypass queries. If `bypass_ratio > 0.5`, cache-bypass queries dominate — the cache delivers minimal improvement. List the anti-pattern findings producing bypass queries; these must be fixed before cache improvements are worthwhile.
+
+### Step 7.6.7 – Detect Cross-Table OR Filter Patterns
+
+Detects ORM query builders that compose filter expressions across multiple LEFT JOINed entities, producing OR conditions that span tables and defeat index usage.
+
+**Detection:** Find ORM filter-composition calls that register columns from multiple entities. For each:
+
+1. Identify the entities whose columns are registered (e.g., `Entity.columns().add_columns(OtherEntity.columns())`)
+2. Check if those entities are joined via LEFT JOIN in the query builder
+3. If a bare-value filter (no field qualifier) generates ILIKE/OR across ALL registered columns, including columns from LEFT JOINed tables → flag
+
+| Framework | Cross-Table OR Pattern |
+|---|---|
+| Rust (SeaORM) | `.columns().add_columns(other::Entity.columns())` with `.filtering_with(query, columns)` where query has no field qualifier |
+| Rust (Diesel) | `.or_filter()` spanning columns from `.left_join()` tables |
+| Java (JPA) | `CriteriaBuilder.or()` with predicates from joined entities |
+| Python (SQLAlchemy) | `or_()` with columns from `.outerjoin()` tables |
+| Node (TypeORM) | `Or()` conditions spanning `leftJoinAndSelect()` relations |
+
+**NOT cross-table OR:** OR conditions within a single table. OR conditions on INNER JOINed tables (optimizer can handle these better). Explicit field-qualified filters (`q=name~openssl`) targeting a single entity.
+
+**Severity:** Classify per severity table. Infer table size from data model: junction/relationship tables (compound FK columns) are likely large. Reference/lookup tables with simple PKs are likely small.
+
+**Impact estimate:** Label as heuristic: "Estimated overhead: High — cross-table OR on LEFT JOINed tables typically forces sequential scan, defeating indexes. Actual impact depends on table sizes (verify with EXPLAIN in Step 9.7)." Do not produce a numeric `impact_ms` — this anti-pattern's cost is data-volume-dependent and cannot be estimated from source code alone.
+
+### Step 7.6.8 – Detect Load-All-Then-Search
+
+Detects patterns where all data for a key is loaded into memory and then searched/filtered for a specific subset, when the search criteria are known at query time and could be pushed to the database.
+
+**Detection:** Find functions that:
+
+1. Execute a query with only a parent-key filter (`WHERE parent_id = $1`) loading all children
+2. Collect results into a Vec/HashMap/collection
+3. Then search/filter that collection for items matching criteria that were available before the query
+
+The anti-pattern is: the search criteria exist at the call site, but the query doesn't include them.
+
+**Key distinction — what IS and IS NOT this anti-pattern:**
+- **IS:** Load all products for a category → iterate to find products matching a user's search term. The search term was known before the query; it should be a WHERE clause.
+- **IS NOT:** Load all nodes for an SBOM → build a dependency graph → traverse the graph to find ancestors. Graph traversal requires the full structure; the traversal operation itself can't be expressed as a SQL WHERE clause.
+
+| Framework | Load-All-Then-Search Pattern |
+|---|---|
+| Rust (SeaORM/sqlx) | `Entity::find().filter(Column::ParentId.eq(id)).all(conn)` → `.iter().find(\|x\| x.name == search_term)` |
+| Java (JPA) | `findByParentId(id)` → `stream().filter(x -> x.getName().equals(term))` |
+| Python (SQLAlchemy) | `session.query(M).filter_by(parent=id).all()` → `[x for x in results if x.name == term]` |
+
+**False-positive guards:**
+1. If the in-memory structure is used for graph/tree traversal (petgraph operations, BFS/DFS, recursive walks) → **discard**. The full structure is necessary for traversal.
+2. If the loaded data set is used by multiple downstream consumers with different filter criteria → **downgrade to Low**. Pre-loading avoids N separate queries.
+3. If the filter criteria require application logic not expressible in SQL (regex, custom comparators, cross-record calculations) → **discard**.
+
+**Severity:** Classify per severity table.
+
+### Step 7.7 – Backend Dynamic Performance Testing
+
+**Runs automatically when:** backend service is running on configured port, test data manifest exists, `curl` is available. Otherwise skips gracefully.
+
+Wrap API profiling in a shell function: benchmark each endpoint (cold + warm runs), measure percentiles, detect cache effectiveness. Compare current metrics against `benchmark-results.json` baseline if it exists. Regression thresholds: p95 > 50ms AND > 10% = regression.
+
+### Step 7.8 – Migration SQL Analysis
+
+**Scope:** Runs when `backend_available = true` and `metric_type` is `backend` or `hybrid`. Scans migration files for performance anti-patterns in backfill/DML queries.
+
+**Migration file discovery:** Reuse the migration path discovered by Step 7.6.4 (same directory used for index/table registry). If Step 7.6.4 was skipped or found no migration files, attempt discovery using the framework-to-path mapping (Cargo.toml → `migration/`, pom.xml → `src/main/resources/db/migration/`, requirements.txt → `migrations/` or `alembic/`, package.json → `src/migration/` or `prisma/migrations/`). If no migration files found, mark all 7.8.x sub-steps as `skipped` with reason "no migration files found."
+
+**Scope filter:** Only analyze migration files containing DML statements (INSERT, UPDATE, DELETE) or PL/pgSQL function definitions (CREATE FUNCTION, CREATE OR REPLACE FUNCTION). Skip pure DDL-only migrations (CREATE TABLE, CREATE INDEX, ALTER TABLE ADD COLUMN). Build a **function registry** from all CREATE [OR REPLACE] FUNCTION statements across migration files — this is needed by Steps 7.8.3 and 7.8.4 when the function is defined in a different file than the one calling it.
+
+**Scope independence:** Unlike Steps 7.1–7.6 (which analyze only the selected workflow's endpoints), Step 7.8 scans ALL DML-containing migration files in the backend codebase — not just those related to the selected workflow's runtime API endpoints. Migration anti-patterns affect deployment performance, ingestion pipelines, and data consistency regardless of which API workflow was selected for analysis.
+
+**scope_context assignment:** Tag each migration finding with a `scope_context` field determined by tracing where the affected code is called from:
+
+| scope_context | Condition | Example |
+|---|---|---|
+| `"runtime"` | Function/query is called by endpoint handlers at request time | Function referenced in `modules/fundamental/src/*/endpoints/` |
+| `"ingestion"` | Function/query is called during data ingestion | Function referenced in `modules/ingestor/` or ingestion pipeline code |
+| `"migration"` | Function/query runs only within migration SQL files — no references in any application source code (grep all `modules/`, `src/`, application crates excluding `migration/`) | Backfill INSERT that is never re-executed after migration |
+| `"shared"` | Function is referenced from BOTH migration SQL AND application source code (any combination of runtime/ingestion callers) | Function defined in migration, called from both ingestor and endpoint handler |
+
+**Caller search scope:** Search ALL application source code (`modules/`, `src/`, and any other application crates), excluding `migration/` itself. Do not limit the search to a single module — a function defined in a migration file may be called from any application crate.
+
+**Assignment rules:**
+1. For **named functions** (CREATE FUNCTION): grep application source for the function name. If found in any application source → `"ingestion"` or `"runtime"` based on the caller's location. If found in both endpoint handlers and ingestion code → `"shared"`. If found only in other migration SQL → `"migration"`.
+2. For **inline SQL patterns** (CTEs, INSERT...SELECT without a named function): these are self-contained within the migration file. Default to `"migration"` unless the migration is designed to be re-run periodically (check for idempotency guards like `ON CONFLICT`, `WHERE NOT EXISTS`). Idempotent migrations that run during deployment → `"migration"`. One-time backfills → `"migration"`.
+3. When uncertain, default to `"ingestion"` (over-report rather than suppress).
+
+Do NOT suppress findings based on scope_context. All contexts produce valid findings. The scope_context is used by plan-optimization (Step 5) for prioritization, not for filtering.
+
+**Backward compatibility:** Findings from prior analysis runs that lack `scope_context` should be treated as `scope_context = "unknown"` by downstream steps.
+
+#### Step 7.8.1 – Missing Statistics Refresh
+
+Detect bulk INSERT...SELECT or UPDATE...FROM operations that write to or read from tables without a preceding ANALYZE statement in the same migration file.
+
+**Detection:** For each migration file containing INSERT...SELECT or UPDATE...FROM:
+
+1. Extract the target table (INSERT INTO) and source tables (FROM/JOIN in the SELECT)
+2. Check whether `ANALYZE {table};` appears before the DML statement in the same file for any of the involved tables
+3. Flag when: the DML operates on a table that was just created or bulk-loaded in a prior migration step, AND no ANALYZE precedes the DML
+
+| Pattern | Example |
+|---|---|
+| Missing ANALYZE before backfill | `CREATE TABLE new_table (...); INSERT INTO new_table SELECT ... FROM large_table;` — no `ANALYZE large_table;` or `ANALYZE new_table;` before the INSERT |
+| Missing ANALYZE between steps | Step 1 bulk-inserts into `dict_table`, Step 2 JOINs `dict_table` — no `ANALYZE dict_table;` between steps |
+
+**NOT missing ANALYZE (do not flag):**
+- Small reference table inserts (INSERT INTO ... VALUES (...), ...) with fewer than 100 literal rows
+- Migrations that only CREATE TABLE + CREATE INDEX (no DML)
+- INSERT...SELECT where the source query has explicit LIMIT < 1000
+
+**Severity:** Classify per severity table.
+
+**Finding output:** Include `scope_context` per Step 7.8 Scope independence. For inline SQL patterns (INSERT...SELECT, CTE), default to `"migration"`. If the migration contains idempotency guards (ON CONFLICT, WHERE NOT EXISTS) suggesting periodic re-execution during deployments, note this in the finding but keep `scope_context = "migration"`.
+
+#### Step 7.8.2 – Non-Materialized CTE Re-evaluation
+
+Detect CTEs in migration DML that contain expensive operations AND are referenced multiple times in the outer query without the MATERIALIZED keyword.
+
+**Detection:** For each CTE in migration SQL (`WITH ... AS (...)`):
+
+1. Parse CTE name and body
+2. Check if CTE body contains expensive operations: function calls (including PL/pgSQL functions from the function registry), JOINs, subqueries, aggregate functions (GROUP BY, array_agg, etc.)
+3. Count references to the CTE name in the outer query (SELECT, INSERT, UPDATE statements after the CTE definition)
+4. Flag when: reference count >= 2 AND CTE body is expensive AND no MATERIALIZED keyword
+
+**PostgreSQL version context:** PostgreSQL 12+ may inline CTEs when they are non-recursive and referenced once. For CTEs referenced multiple times, the planner MAY still inline them (evaluating the body at each reference site). The MATERIALIZED keyword forces a single evaluation. Prior to PostgreSQL 12, all CTEs were implicitly materialized.
+
+| Pattern | Example |
+|---|---|
+| Non-materialized CTE with function call, used in INSERT + md5 JOIN | `WITH expansions AS (SELECT expand_fn(col, mappings) AS expanded ...) INSERT INTO target SELECT e.sbom_id, el.id FROM expansions e JOIN dict el ON el.hash = md5(e.expanded)` — function evaluated once for the SELECT, again for the md5 JOIN |
+| Non-materialized CTE referenced in two INSERTs | `WITH cte AS (SELECT ... FROM a JOIN b ...) INSERT INTO t1 ... FROM cte; INSERT INTO t2 ... FROM cte;` |
+
+**NOT a problem (do not flag):**
+- CTE referenced exactly once in the outer query
+- CTE body is a simple SELECT from a single table with no function calls or JOINs
+- CTE already has MATERIALIZED keyword
+- Recursive CTEs (`WITH RECURSIVE`) — these are always materialized by PostgreSQL
+
+**Severity:** Classify per severity table.
+
+**Finding output:** Include `scope_context` per Step 7.8 Scope independence. For inline SQL patterns (INSERT...SELECT, CTE), default to `"migration"`. If the migration contains idempotency guards (ON CONFLICT, WHERE NOT EXISTS) suggesting periodic re-execution during deployments, note this in the finding but keep `scope_context = "migration"`.
+
+#### Step 7.8.3 – Uniform Processing of Partitionable Data
+
+Detect queries that apply an expensive operation to all rows when a filterable predicate could partition the work, allowing most rows to skip the expensive path.
+
+**Detection scope:** Limited to specific high-confidence patterns to minimize false positives.
+
+**Pattern 1 — Function call with early-exit guard:** For each migration DML that calls a PL/pgSQL function:
+
+1. Read the function body (from CREATE FUNCTION in the same or earlier migration file, or from the function registry built during Step 7.8 initialization)
+2. Check if the function contains an early-exit guard: `IF POSITION('X' IN param) = 0 THEN RETURN param; END IF;` or `IF param !~ 'pattern' THEN RETURN param; END IF;` or `IF param NOT LIKE '%pattern%' THEN RETURN param; END IF;`
+3. Check if the calling query applies the function to all rows without filtering by the guard condition
+4. Flag when: function has early-exit guard AND calling query processes all rows AND the guard condition could be used as a WHERE clause to skip the majority of rows
+
+| Pattern | Example |
+|---|---|
+| Unconditional function application | `INSERT INTO target SELECT id, expand_fn(text, mappings) FROM source LEFT JOIN mapping_table ...;` where `expand_fn` returns input unchanged for rows without 'LicenseRef-' (early-exit guard) |
+| LEFT JOIN + function on all rows | `INSERT INTO target SELECT src.id, expand_fn(src.text, lim.data) FROM src LEFT JOIN (SELECT ... FROM mappings GROUP BY sbom_id) lim ON ...;` where expand_fn has early-exit and the LEFT JOIN is only consumed by the function |
+
+**Pattern 2 — CASE-expressible partitioning:** For each migration DML with a LEFT JOIN + function call:
+
+1. Check if the LEFT JOIN is only needed by the function call (i.e., the JOIN's fields are only consumed by the function, not by the INSERT/UPDATE target columns directly)
+2. If so, the query could be split: rows matching the guard condition go through the expensive path, the rest skip the JOIN and function entirely
+
+**False-positive guards:**
+1. If the function has no early-exit guard (every row needs processing) → **discard**. Without evidence that rows are skippable, uniform processing may be correct.
+2. If the calling query already has a WHERE clause filtering to the relevant subset → **discard**. The query is already partitioned.
+3. If the function modifies every row differently (no skip-able subset; guard checks a different concern than the expensive path) → **discard**.
+4. If the function's early-exit guard percentage is unclear (no way to estimate skip ratio from code alone) → **downgrade to Low Confidence**. Route to "Candidates for Manual Review" in the report.
+5. If the query is inside a transaction that already filters upstream (e.g., a temp table was populated with only matching rows) → **discard**. The upstream filter serves the same purpose as a WHERE clause.
+
+**Confidence:** Low by default — this pattern requires understanding function semantics. Upgrade to Medium only when the early-exit guard uses a simple string predicate (POSITION/LIKE) that maps directly to a SQL WHERE clause.
+
+**Severity:** Classify per severity table.
+
+**Finding output:** Include `scope_context` per Step 7.8 Scope independence. For named PL/pgSQL functions, grep all application source code (excluding `migration/`) for the function name to determine caller context. A function defined in migration SQL that is referenced from application source code (e.g., `modules/ingestor/`) is NOT a "migration-only" function — it runs at ingestion time and its performance matters beyond the initial migration.
+
+#### Step 7.8.4 – Expensive PL/pgSQL Function Patterns
+
+Detect known slow patterns inside CREATE [OR REPLACE] FUNCTION definitions found in migration files.
+
+**Detection:** For each PL/pgSQL function in migration SQL (from the function registry):
+
+1. **Dynamic regexp in loop:** `regexp_replace(text, '\m' || variable || '...', replacement, 'g')` inside a FOREACH or FOR loop — the regex is recompiled on every iteration because it includes a concatenated variable. Flag when the concatenation uses a loop variable.
+   - **Fix indicator:** If the pattern uses word boundaries (`\m`, `\M`, `(?![...])`) for delimiter matching in a known-delimiter context (SPDX expressions, CSV, space-delimited tokens), `replace()` with boundary-aware splitting would work — enumerate all valid boundary pairs instead of compiling a regex.
+
+2. **Dynamic SQL in loops:** `EXECUTE 'SELECT ...' || variable` or `EXECUTE format('...', variable)` inside a LOOP — dynamic SQL prevents plan caching across iterations.
+
+3. **Per-row database queries inside functions:** `SELECT ... INTO variable FROM table WHERE id = loop_var` inside a LOOP within a function body — this is the PL/pgSQL equivalent of N+1.
+
+4. **Unnecessary RAISE NOTICE in hot paths:** `RAISE NOTICE` inside a LOOP that processes data rows — logging overhead per row (I/O + string formatting).
+
+| Pattern | Example |
+|---|---|
+| Dynamic regexp in loop | `FOREACH mapping IN ARRAY mappings LOOP result := regexp_replace(result, '\m' \|\| mapping.license_id \|\| '(?![a-zA-Z0-9.-])', mapping.name, 'g'); END LOOP;` |
+| EXECUTE in loop | `FOR r IN SELECT * FROM t LOOP EXECUTE format('INSERT INTO %I VALUES ...', r.name); END LOOP;` |
+| Per-row query in function | `FOR r IN SELECT * FROM parent LOOP SELECT count(*) INTO cnt FROM child WHERE parent_id = r.id; END LOOP;` |
+
+**NOT expensive (do not flag):**
+- `regexp_replace` with a static (literal) pattern — the regex is compiled once
+- EXECUTE outside a loop (one-time dynamic SQL)
+- RAISE NOTICE outside a loop (diagnostic, not hot path)
+- A loop with a small fixed-size input (e.g., `FOREACH mapping IN ARRAY mappings` where `mappings` has bounded cardinality < 10 from the calling context)
+
+**Severity:** Classify per severity table.
+
+**Finding output:** Include `scope_context` per Step 7.8 Scope independence. For named PL/pgSQL functions, grep all application source code (excluding `migration/`) for the function name to determine caller context. A function defined in migration SQL that is referenced from application source code (e.g., `modules/ingestor/`) is NOT a "migration-only" function — it runs at ingestion time and its performance matters beyond the initial migration.
+
+## Step 8 – Cross-Reference Over-Fetching
+
+For each endpoint from Step 6.1:
+
+**A. Extract backend response fields** (from Step 7.2 schema — must be complete).
+
+**B. Analyze frontend field usage** — grep for property accesses across frontend `src/`. Mark each field USED or UNUSED.
+
+**C. Calculate waste:**
+- Field-level: `unused / total × 100`
+- If N+1: multiply by call count
+- Payload: `(unused / total) × response_size × call_count`
+
+**D. Severity:** Critical if N+1 (10+) with >50% over-fetching. High if single call >50%. Medium if 25-50%. Low if <25%.
+
+### Step 8.F – Cross-Layer Computation Waste Detection
+
+**Skip if:** `backend_available = false`, scope is backend-only or frontend-only, or no query_ledger exists.
+
+Map response fields to their computation cost (queries from call graph). Cross-reference with frontend field usage. Sum query costs for frontend-unused fields. If unused fields account for >50% of total query cost, flag as cross-layer waste.
+
+## Step 9 – Generate Workflow Analysis Report
+
+### Step 9.0 – Pre-Report Completeness Gate
+
+Read `{analysis_dir}/analysis-progress.json`. Verify:
+1. No step has status `pending` — if any do, go back and complete them
+2. Each `done` step has an explicit findings count (0 is valid)
+3. No endpoints were silently dropped (compare analyzed endpoints vs config)
+4. Query ledger was consumed by Steps 7.6.3-7.6.6 when it exists
+
+Do not proceed to Step 9.1 until all checks pass.
+
+### Step 9.1 – Finding Validation
+
+**Mandatory.** Process all findings from Steps 5–8.
+
+#### Step 9.1-A – Build Findings Inventory
+
+Table with columns: #, Anti-Pattern, Step, File:Line, Detection Method, Evidence Excerpt, Original Confidence, Original Severity. Assign unique IDs (F1, F2, ...).
+
+#### Step 9.1-B – Source Code Re-Verification
+
+For each finding: re-read the source at the reported location (use the same tool as the detection method — do NOT use Serena for frontend findings). Verify the file exists, the code matches the evidence excerpt, and the pattern is locally present. Record PASS or FAILED with reason.
+
+#### Step 9.1-B2 – Deep Analysis
+
+**Mandatory for every finding with 9.1-B: PASS.** Pattern existence ≠ valid finding.
+
+For each finding, apply these checks:
+
+1. **Trace call chain** — Who calls this function? What bounds exist upstream? Is output reused downstream? If upstream bounds or downstream reuse invalidate the finding → FAILED: context invalidates pattern
+2. **Question fix premise** — Does the recommended fix work for this technology/runtime?
+   - PostgreSQL: one query per connection per transaction → `try_join!` on shared connection = zero parallelism
+   - SeaORM `load_one` on `Vec<Model>` = batch query (single `WHERE id IN (...)`), NOT N+1
+   - `serde_json` 128-level recursion limit → depth limits on deserialized data is dead code
+   - If fix provides no benefit → FAILED: fix premise invalid
+3. **Assess real-world impact** — Check actual cardinality, pagination limits, FK constraints. A query filtered by parent FK with bounded cardinality is NOT "unbounded." A table with <1000 rows doesn't need an index. If negligible → FAILED or downgrade to Low
+4. **Challenge conclusion** — Construct the strongest counterargument. Common invalidators: data reused by multiple consumers, N is a small constant, function is linear despite length, extraction creates cross-module coupling, fire-and-forget is correct for telemetry
+5. **Verify factual claims** — grep ALL migration files for claimed missing indexes. Trace full pipeline for claimed missing depth limits. Verify no FK/pagination constraint bounds a "unbounded" query
+
+**False-positive risk factors by anti-pattern:**
+
+| Anti-Pattern | Key Risk Factors |
+|---|---|
+| Over-Fetching | Field used via spread, passed to library, computed property access |
+| N+1 | `Promise.all`/batch variant, fixed small set (<3), ORM `load_one`/`load_many` is batch |
+| Waterfall | Cache-warm resources, unavoidable auth dependency |
+| Unused Code | Dynamic import, reflection, shared library |
+| Unused JOINs | JOIN for filtering (WHERE), ordering (ORDER BY), ORM lazy-loading |
+| Missing Pagination | Known small table (<50 rows), admin-only endpoint |
+| Missing Indexes | Small table (<1K rows), admin/ingestion path only, existing composite index covers it |
+| Wasted Computation | Shared service method, unused fields are cheap (no queries) |
+| Cross-Layer Waste | Fields needed for future feature, SEO/meta tags |
+| Missing Statistics Refresh (7.8.1) | Small table (<1K rows), single INSERT...VALUES (not INSERT...SELECT), migration is re-run idempotent |
+| Non-Materialized CTE (7.8.2) | CTE referenced once (planner won't inline), PostgreSQL < 12 (CTEs always materialized), CTE body is trivial (no JOINs/functions) |
+| Uniform Processing (7.8.3) | Function has no early-exit guard, upstream transaction already filters, query has WHERE clause partitioning, skip ratio unclear |
+| Expensive PL/pgSQL Pattern (7.8.4) | Regex pattern is static literal (compiled once), loop bound is small constant (<10), scope_context confirmed as "migration" after full caller trace (no references in application source outside migration/) |
+
+#### Step 9.1-C – Assign Confidence
+
+Confidence = min(Detection Method, Evidence Strength) adjusted by false-positive risk. Base: High (Serena/raw SQL), Medium (grep + structural context, depth-0), Low (dynamic queries, depth>0, control flow ambiguity). Downgrade one level per unresolvable risk factor.
+
+#### Step 9.1-D – Assign Severity
+
+Apply the Anti-Pattern Severity Reference table using actual quantified values from detection. Recalculate if values changed during re-verification.
+
+#### Step 9.1-E – Assign Implementation Timeline
+
+`<1h` (single-line/config) · `1-4h` (single-file refactor) · `0.5-1d` (multi-file, one module) · `1-3d` (cross-module/API change) · `3-5d` (architectural) · `>5d` (major restructuring)
+
+#### Step 9.1-F – Assign Disposition
+
+| Disposition | Criteria |
+|---|---|
+| **Confirmed** | Passed 9.1-B and 9.1-B2, confidence ≥ Medium |
+| **Confirmed (Low Confidence)** | Passed both, confidence = Low → report with "requires manual verification" flag |
+| **Downgraded** | Passed both, but impact corrected downward |
+| **Discarded** | Failed any check in 9.1-B or 9.1-B2 → exclude from report (log with reason) |
+
+#### Step 9.1-G – Validation Summary
+
+Produce summary table: Finding, Anti-Pattern, Disposition, Confidence, Severity, Timeline, Reason.
+
+Include statistics: submitted, confirmed, low-confidence, downgraded, discarded (with percentages).
+
+Only Confirmed, Confirmed (Low Confidence), and Downgraded findings proceed to the report.
+
+#### Step 9.1-H – Persist Validation Artifact
+
+Write `{analysis_dir}/findings-validation.json` with all findings (including discarded for audit trail). Set `validation_run: true` only after all validation steps complete. See [finding-validation.md](../performance/finding-validation.md) for schema.
+
+### Step 9.2 – Report Location
+
+Report path: `{analysis_dir}/workflow-analysis-report.md`.
+
+### Step 9.3 – Report Structure
+
+Read template from `${plugin_root}skills/performance/performance-analysis-report.template.md`. Populate with metrics/bundle/baseline from Steps 2–8 and findings exclusively from `findings-validation.json` (never raw detection output). Include frontend sections for `frontend`/`hybrid`, backend sections for `backend`/`hybrid`.
+
+For migration findings (Step 7.8.x), include a **Migration & Ingestion Performance** section after the Backend Anti-Patterns section. Group findings by `scope_context`. Each finding must note its scope so readers understand whether it affects API response time, ingestion throughput, or deployment speed. Findings with `scope_context = "unknown"` (from prior runs without scope tagging) go into a separate "Unscoped Migration Findings" subsection.
+
+### Step 9.4 – Overall Performance Rating
+
+Compare metrics against Optimization Targets: Excellent (all within), Good (1-2 slightly above, ≤20%), Needs Improvement (2-3 above, >20%), Poor (all above or any >50%). Hybrid: worst of frontend and backend.
+
+### Step 9.5 – Prioritize Optimizations
+
+Sort validated findings by estimated impact descending. Use query ledger totals as primary impact metric for backend optimizations.
+
+**Cache-bypass priority:** Findings producing cache-bypass queries rank ABOVE cache improvements.
+
+**Priority table:**
+
+| Priority | Optimization | Confidence | Severity | Timeline | Prerequisite | Impact | Effort |
+|---|---|---|---|---|---|---|---|
+| 1 | {optimization} | {conf} | {sev} | {time} | {prereq or —} | {impact} | {effort} |
+
+Prerequisites: use "Fix #N first" when an optimization delivers no benefit until another is applied. Prerequisite fixes must appear before dependent optimizations in the table.
+
+**Strategic optimizations** (materialized views, background jobs, data model changes, ingestion pipeline changes) go in a separate table with S1, S2, ... numbering. For each, explain what scaling limit tactical fixes cannot address.
+
+### Step 9.7 – Live SQL Analysis (Optional)
+
+**Guard:** `backend_available = true` AND `metric_type` is `backend` or `hybrid` AND `{analysis_dir}/query-ledger.json` exists and is non-empty. Skip entirely when any guard condition is false.
+
+#### Step 9.7.0 – Prompt User
+
+Offer: (1) Automated — provide connection details, (2) Manual — receive EXPLAIN commands to run yourself, (3) Skip → proceed to Step 9.8. Warn: use dev/staging DB only.
+
+#### Step 9.7.1 – Prepare Queries
+
+Read `{analysis_dir}/query-ledger.json`. Only eligible queries proceed:
+
+- `is_literal_sql = true` AND `query_type = "SELECT"` → EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
+- Mutation queries (INSERT/UPDATE/DELETE) → EXPLAIN without ANALYZE only, or skip
+- `is_literal_sql = false` or dynamic SQL → skip, document as Phase 1 limitation
+
+Parameterize eligible queries with representative values from test data manifest or safe defaults.
+
+#### Step 9.7.2 – Collect Connection Details (Automated Mode Only)
+
+Prompt for PostgreSQL connection details. Verify connectivity. On failure: offer re-entry, switch to manual mode, or skip.
+
+**Security:** Connection details held in session memory only — never written to any file or artifact.
+
+#### Step 9.7.3 – Obtain EXPLAIN Results
+
+**Automated:** Execute EXPLAIN on eligible queries with a 30-second statement timeout. Never execute mutation queries via EXPLAIN ANALYZE — use EXPLAIN without ANALYZE or skip. On timeout: prompt user to run the timed-out query manually and share the result, or skip that query. On other errors: record and continue.
+
+**Manual:** Present numbered EXPLAIN commands for each eligible query (with source location and parameterized SQL). User executes on their database and shares results back. Accept partial results — analyze whatever is provided. Determine `detection_method` from whether output contains execution timing.
+
+#### Step 9.7.4 – Analyze Bottlenecks
+
+Parse EXPLAIN output for: sequential scans on large tables, missing indexes, nested loop joins on large inner relations, row estimate mismatches, sorts spilling to disk, high-cost nodes, hash batch overflow. Classify severity per the Anti-Pattern Severity Reference table.
+
+#### Step 9.7.5 – Create and Validate Findings
+
+Create findings with `detection_method: "EXPLAIN ANALYZE"` (or `"EXPLAIN"`), `step: "9.7.4"`, confidence: High. Include `explain_data` per [finding-validation.md](../performance/finding-validation.md) schema. Finding IDs continue the existing F-sequence.
+
+Pass each finding through the Step 9.1 validation flow (9.1-B source re-verification, 9.1-B2 fix premise validation, 9.1-C–F confidence/severity/disposition assignment). Update `findings-validation.json`.
+
+If Step 9.7 added any new Confirmed or Downgraded findings, re-run Step 9.5 to incorporate them into the priority table before proceeding to Step 9.8.
+
+#### Step 9.7.6 – Heuristic vs Measured Comparison
+
+Compare static estimates (`db_latency_ms` × effective query count) against measured execution times. Label clearly as "Heuristic Estimate vs Measured" with the formula — these are not comparable methodologies.
+
+### Step 9.8 – Validate and Write Report
+
+**Step 9.8-A:** Confirm `findings-validation.json` exists. Assemble report content (including Live SQL Analysis section if Step 9.7 was performed). Run validation checklist from [finding-validation.md](../performance/finding-validation.md). All rules must PASS.
+
+**Step 9.8-B:** Only when 9.8-A shows all PASS: set `Validation Status: passed`, write to `{analysis_dir}/workflow-analysis-report.md`.
+
+## Step 10 – Output Summary
+
+```
+✅ Performance analysis complete!
+
+Workflow: {name}
+Overall Rating: {rating}
+Report: performance/analysis/workflow-analysis-report.md
+Validation: {confirmed} confirmed, {downgraded} downgraded, {discarded} discarded
+
+Key Findings:
+- {finding-1}
+- {finding-2}
+- {finding-3}
+
+Top Optimization: {top} — Impact: {impact}
+
+{if Step 9.7 was performed}
+Live SQL Analysis: {analyzed} queries analyzed, {skipped} skipped, {bottlenecks} bottlenecks found
+Top bottleneck: {description} — {execution_time}ms
+{end if}
+
+Next: Run /sdlc-workflow:performance-plan-optimization to create Jira tasks
+```
+
+## Important Rules
+
+- All detection must be based on actual code search results — never fabricate findings
+- Impact estimates should be conservative; scope analysis to the selected workflow only
+- Zero instances = report "No instances detected" — don't omit the step
+- Detection failures → document in report limitations; validation gate (Step 9.8) still applies
+- Live SQL credentials: session-only, NEVER written to any file/artifact. Use env vars for passwords — never CLI args
+- Live SQL: NEVER execute mutation queries via EXPLAIN ANALYZE. Use EXPLAIN without ANALYZE, or skip
diff --git a/plugins/sdlc-workflow/skills/performance-baseline/SKILL.md b/plugins/sdlc-workflow/skills/performance-baseline/SKILL.md
new file mode 100644
index 000000000..f387f50ef
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance-baseline/SKILL.md
@@ -0,0 +1,632 @@
+---
+name: performance-baseline
+description: |
+  Discover workflows from the codebase, prompt user to select a target workflow, auto-populate configuration, then capture performance baseline metrics via browser automation and generate a baseline report.
+argument-hint: "[target-repository-path]"
+---
+
+# performance-baseline skill
+
+Discovers user workflows from the codebase, prompts user to select a target, auto-populates configuration, captures baseline metrics (browser automation for frontend, HTTP benchmarking for backend), and generates a baseline report.
+
+## Guardrails
+
+- Creates files in `performance/baselines/` — does NOT modify source code
+- Requires Performance Analysis Configuration (run `performance-setup` first)
+- Blocking steps: Step 4.4 (workflow selection), Step 8.3 (script review), Step 8.4.B4.3 (test data confirmation)
+- If config missing → halt with remediation. If script error → halt with actionable error message
+- **Fast-path to first blocking prompt:** On entry, immediately read `performance-config.json` and evaluate which step contains the first user-blocking question. Skip all non-blocking verification (repo type checks, file existence probes, Serena probes) until after that blocking question is answered. The goal is to surface the first question to the user in the very first response.
+- Credentials passed via CLI args or `BASELINE_PASS` env var only — never written to config files or disk
+- Verification iteration runs before measurement; halts on failure with actionable diagnostics
+- Hosted mode (`--base-url`) applies to frontend Playwright capture only; backend `perf-benchmark.sh` is unchanged
+
+### Plugin Root Resolution
+
+Every bash block that calls `perf-config.py` must begin with:
+
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null \
+  | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then
+  echo "❌ sdlc-workflow plugin not found"; exit 1
+fi
+```
+
+### perf-config.py CLI (read help before use)
+
+**Do not guess argument syntax.** Before the first `perf-config.py` invocation in this skill run, and again before each subcommand you have not used yet, run its `--help` and follow the documented positional arguments:
+
+```bash
+python3 "$plugin_root/scripts/perf-config.py" --help
+python3 "$plugin_root/scripts/perf-config.py" set-json --help
+python3 "$plugin_root/scripts/perf-config.py" set --help
+```
+
+Global option: `--config PATH` (default: `performance-config.json`). Subcommands use **positional** arguments — there are no `--dotpath` or `--value` flags.
+
+| Subcommand | Syntax | Use for |
+|---|---|---|
+| `set-json` | `set-json <dotpath> <json_value>` | Arrays/objects: `scenarios`, `modules`, `workflow`, `dev_environment` |
+| `set` | `set <dotpath> <value>` | Scalars: `metadata.workflow_selected`, `metadata.baseline_captured`, `dev_environment.frontend.port` |
+| `get` | `get <dotpath>` | Read a single value |
+| `get-section` | `get-section <section>` | Dump a top-level section as JSON |
+| `validate` | `validate` | Verify config after writes |
+
+**`set-json` pitfalls:** The second argument is a JSON **string** (object or array), not a file path. Wrong: `set-json --dotpath scenarios --json '...'`. Right: `set-json scenarios '[...]'`. For multi-line JSON, use a quoted heredoc: `set-json scenarios "$(cat <<'EOF' ... EOF)"`.
+
+After Step 4.7 writes, run `validate` and confirm with `get-section` on `workflow`, `scenarios`, and `modules`.
+
+### Tool Selection (Serena / Grep)
+
+`serena_mode` is set once by a Serena probe (call `get_symbols_overview` with `relative_path="."`). Use Serena when `live`, grep/Read otherwise.
+
+| serena_mode | Tool | Confidence |
+|---|---|---|
+| `live` | `mcp__{serena_instance}__find_symbol(...)` | High |
+| `down` / `not-configured` | Grep + Read | Medium |
+
+## Step 1 – Determine Target Repository
+
+Use the user-provided path, or the current working directory. Verify it contains appropriate project indicators for the configured `analysis_scope`.
+
+## Step 2 – Verify Performance Configuration
+
+Read `performance-config.json`. Verify config exists (halt if missing). Initialize `stored_mode = null`, `baseline_already_captured = false`.
+
+### Step 2.0 – Check if Workflow Selection Required
+
+Read `metadata.workflow_selected`:
+- **false:** Proceed to Step 2.0.5 (scope check), then workflow discovery (Steps 3 or 4)
+- **true:** Validate that `workflow.name`, `workflow.entry_point`, and `workflow.key_screens` are non-null and non-empty. If any are missing, prompt user to either reset `workflow_selected` to false (re-discover) or enter workflow details manually. Do NOT proceed with null workflow data.
+
+### Step 2.0.5 – Check Analysis Scope
+
+Read `metadata.analysis_scope`:
+- `backend-only` → Step 3 (backend endpoint discovery)
+- `frontend-only` → Step 4.1 (frontend route discovery)
+- `full-stack` / `full-stack-monorepo` → Step 4.1 (frontend route discovery), then Step 4.8 (frontend-to-backend API tracing)
+
+### Step 2.1 – Read Selected Workflow
+
+Extract workflow name, entry point, key screens, complexity. Store for baseline capture. Skip to Step 2.2.
+
+### Step 2.2 – Read Baseline Mode from Metadata
+
+Extract `metadata.baseline_mode` → `stored_mode` and `metadata.baseline_captured` → `baseline_already_captured`.
+
+## Step 3 – Backend API Endpoint Discovery
+
+**Runs ONLY if `analysis_scope = "backend-only"` AND `workflow_selected = false`.**
+
+### Step 3.0 – Serena Availability Probe
+
+Read `serena_instance` from backend config. Run the Serena probe to set `serena_mode`.
+
+### Step 3.1 – Locate API Route Definitions
+
+Search backend codebase for API endpoint definitions using framework-specific patterns.
+
+**Serena path:** For each endpoint module file, call `find_symbol` with `include_kinds=[12]`, `include_body=true`. Extract HTTP method, path, handler name, file.
+
+**Grep path:** Run one grep per framework with `-A 3` context lines:
+
+| Framework | Grep pattern |
+|---|---|
+| actix-web (Rust) | `'#\[get\|#\[post\|#\[put\|#\[delete'` |
+| axum (Rust) | `'\.route("'` |
+| Spring Boot (Java) | `'@GetMapping\|@PostMapping\|@PutMapping'` |
+| FastAPI (Python) | `'@app\.get\|@router\.\(get\|post\)'` |
+| Express (Node) | `'router\.\(get\|post\)\|app\.\(get\|post\)'` |
+
+Parse grep output in-context — do NOT write to /tmp or shell variables.
+
+**Output as in-context table:**
+
+| # | HTTP Method | Path Pattern | Handler | File | Impact | Discovery Method |
+|---|---|---|---|---|---|---|
+
+**Coverage self-check:** List files scanned, compare against `find` results for the framework extension. Scan any missing files before proceeding. Verify raw result count matches table row count.
+
+### Step 3.1.1 – Validate Endpoint Safety
+
+For each handler, count references (Serena `find_referencing_symbols` or grep). Classify: <5 refs = Low, 5-10 = Medium, >10 = High impact.
+
+### Step 3.2 – Group Endpoints into Workflows
+
+Group by resource prefix (primary), controller/file (secondary), or OpenAPI tags (tertiary). Present ALL workflows. Estimate complexity: 1-2 endpoints = Simple, 3-4 = Moderate, 5+ = Complex.
+
+**Verify grouping completeness:** Count table rows from Step 3.1 vs endpoints in groups. If mismatch, redo grouping. After 2 retries, prompt user.
+
+### Step 3.3 – Present Workflows and Prompt Selection
+
+Display ALL discovered workflows in numbered table with name, entry endpoint, key endpoints, complexity, impact. Prompt: "Enter the number of the workflow to optimize (1-N):"
+
+### Step 3.4 – Auto-Populate Scenarios
+
+**GET endpoints only** → create scenario entry with name derived from method+path, endpoint path, description.
+
+**POST/PUT/DELETE endpoints** → do NOT create a scenario. Mutating endpoints risk side effects on test data and require sample request bodies. Record them in the in-context table for reference but exclude from the scenarios array written in Step 4.7.
+
+### Step 3.5 – Discover Modules
+
+For each handler file in selected workflow, extract functions/methods (Serena `get_symbols_overview` or grep for function signatures).
+
+### Step 3.6 – Stage Config Changes
+
+Collect scenarios, modules, workflow, metadata updates. Do NOT write config yet — deferred to Step 4.7.
+
+## Step 4 – Frontend Workflow Discovery
+
+### Step 4.1 – Find Router Configuration
+
+**Skip if `workflow_selected = true`.**
+
+Find router files with `find` (patterns: `*routes*.ts*`, `*router*.ts*`, `App.ts*`). Cross-check with framework-specific grep. Ensure all router files are identified.
+
+### Step 4.2 – Extract Route Definitions
+
+**Skip if `workflow_selected = true`.**
+
+Read router files (Serena `get_symbols_overview` + `find_symbol`, or Read/Grep with `-A 2`). Extract route path, component, lazy-load status. Output as in-context table with row count.
+
+### Step 4.3 – Infer Workflows from Routes
+
+**Skip if `workflow_selected = true`.**
+
+Group routes by: path prefix, list-to-detail patterns, feature directory, upload/action patterns. Standalone routes become single-route workflows. Estimate complexity. **Verify completeness** (table row count vs grouped count).
+
+### Step 4.4 – Present Workflows and Prompt Selection
+
+**Skip if `workflow_selected = true`.**
+
+Display ALL workflows in numbered table. Prompt selection. Store workflow details.
+
+### Step 4.5 – Auto-Populate Scenarios
+
+**Skip if `workflow_selected = true`.**
+
+Generate scenario per route: name derived from path, URL, description.
+
+**Dynamic segment substitution:** For routes with dynamic segments (`:id`, `:slug`, etc.), substitute with real values from the test data manifest (generated in Step 8.4.B4, if available) or from sample IDs discovered during backend endpoint probing. If no manifest or sample data is available, prompt the user for representative values.
+
+After auto-population, scan all scenario URLs for unresolved `:param` segments. If any remain, list them and prompt the user before proceeding — do not proceed to capture with unresolved segments.
+
+### Step 4.6 – Discover Modules
+
+**Skip if `workflow_selected = true`.**
+
+Find lazy-loaded components for each route. Extract module entry points and names.
+
+### Step 4.7 – Consolidated Config Write
+
+Run `set-json --help` and `set --help` first (see **perf-config.py CLI** above). Write all staged changes to `performance-config.json` via `perf-config.py`:
+
+1. `set-json scenarios` — JSON array from Step 4.5 (or Step 3.4 for backend-only)
+2. `set-json modules` — JSON array from Step 4.6 (or Step 3.5 for backend-only)
+3. `set-json workflow` — JSON object with `name`, `entry_point`, `key_screens`, `complexity`, `selected_on`
+4. `set metadata.workflow_selected true`
+5. `set metadata.backend_endpoint_discovery_method` — `"serena"`, `"grep"`, or discovery method used
+
+Example (replace staged values; keep JSON on one line or use a heredoc):
+
+```bash
+python3 "$plugin_root/scripts/perf-config.py" set-json scenarios '[{"name":"list-packages","url":"/packages","description":"Package listing"}]'
+python3 "$plugin_root/scripts/perf-config.py" set-json modules '[{"name":"PackagesPage","entry_point":"src/pages/Packages.tsx"}]'
+python3 "$plugin_root/scripts/perf-config.py" set-json workflow '{"name":"package-listing","entry_point":"/packages","key_screens":["/packages"],"complexity":"Moderate","selected_on":"2026-06-05T12:00:00Z"}'
+python3 "$plugin_root/scripts/perf-config.py" set metadata.workflow_selected true
+python3 "$plugin_root/scripts/perf-config.py" set metadata.backend_endpoint_discovery_method grep
+python3 "$plugin_root/scripts/perf-config.py" validate
+```
+
+If a command fails, re-run that subcommand's `--help` — do not pause waiting for user input to debug syntax.
+
+### Step 4.8 – Trace Backend API Calls from Selected Workflow
+
+**Runs ONLY when `analysis_scope` is `full-stack` or `full-stack-monorepo` AND `workflow_selected` was just set to true (fresh selection in this run, not a re-run with existing workflow).**
+
+Purpose: Identify which backend API endpoints the selected frontend workflow's components actually call. These become the backend scenarios for hybrid baseline capture.
+
+**Best-effort trace:** Follows one level of local imports from module entry points. Barrel files (`index.ts` re-exports), monorepo cross-package imports (`@myorg/api-client`), and deeply abstracted API clients (3+ import levels) may not be traced. User edits at the confirmation step (Step 4.8.6) are expected for non-trivial codebases.
+
+#### Step 4.8.1 – Locate Workflow Component Files
+
+From the `modules` array (just written in Step 4.7), resolve file paths for each module's `entry_point`. Then find locally-imported files:
+
+1. Read each module's `entry_point` file.
+2. Extract import statements to find local files imported by each entry point (ignore `node_modules` imports).
+3. For `@/` or `~/` path aliases, read `tsconfig.json` `compilerOptions.paths` or `vite.config.ts` `resolve.alias` to resolve.
+4. Build `workflow_files` list = entry point files + their locally-imported files.
+
+#### Step 4.8.2 – Extract API Call URLs
+
+Search `workflow_files` for API call patterns (single pass):
+
+```
+grep -rn "fetch(\|axios\.\|useQuery\|useSWR\|useMutation\|api\.\(get\|post\|put\|delete\|patch\)" <workflow_files>
+```
+
+For each match, extract URL string:
+
+| URL form | Extraction | Example |
+|---|---|---|
+| String literal | Direct | `fetch('/api/v2/packages')` → `/api/v2/packages` |
+| Template literal | Static prefix + dynamic marker | `` fetch(`/api/v2/packages/${id}`) `` → `/api/v2/packages/:id` |
+| Variable | Trace one level to assignment; skip with note if unresolvable | `fetch(apiUrl)` |
+
+Infer HTTP method from the pattern: `axios.get` → GET, `axios.post` → POST, `useMutation` → POST (default), plain `fetch` with no options or `method: 'GET'` → GET, `fetch` with `method: 'POST'` → POST.
+
+**Output as in-context table:**
+
+| # | HTTP Method | API Path | Dynamic | Source File:Line |
+|---|---|---|---|---|
+
+If zero API calls found: warn user, offer to manually enter endpoints or skip backend.
+
+#### Step 4.8.3 – Resolve and Verify Against Backend Routes
+
+1. Read `repositories.backend.api_base_path` from config (e.g., `/api/v2`).
+2. For each discovered API path, normalize (prepend `api_base_path` if the path does not already start with it).
+3. If the frontend uses environment variables for the base URL (e.g., `process.env.API_URL`), check `.env` or `.env.local` to resolve.
+4. Verify each endpoint exists in the backend codebase using the same framework-specific grep patterns from Step 3.1 (`#[get|`, `@GetMapping`, `@app.get`, `router.get`, etc.).
+5. Mark each endpoint as `verified: true` or `verified: false`. Record the backend handler file and function name for verified endpoints.
+
+**Output as in-context table:**
+
+| # | Frontend API Path | Resolved Backend Path | HTTP Method | Handler | Backend File | Verified |
+|---|---|---|---|---|---|---|
+
+#### Step 4.8.4 – Generate Backend Scenarios
+
+**GET endpoints only** → create scenario entry:
+```json
+{"name": "api-get-packages", "url": "/api/v2/packages", "description": "API called by {workflow_name}", "type": "backend"}
+```
+
+**POST/PUT/DELETE endpoints** → record in `traced_api_endpoints` metadata but do NOT create a scenario. Mutating endpoints are traced for analyze-module coverage but not benchmarked — measuring POST/PUT requires sample request bodies and risks side effects on test data.
+
+Dynamic segments stay as-is (e.g., `/api/v2/packages/:id`) — resolved during Step 8.4.B4 manifest generation.
+
+#### Step 4.8.5 – Write to Config
+
+1. Read current `scenarios` (frontend routes from Step 4.5). Tag each with `"type": "frontend"`.
+2. Append backend scenarios from Step 4.8.4 (already tagged `"type": "backend"`).
+3. Write merged array:
+   ```bash
+   python3 "$plugin_root/scripts/perf-config.py" set-json scenarios '[{"name":"list-packages","url":"/packages","description":"Package listing","type":"frontend"},{"name":"api-get-packages","url":"/api/v2/packages","description":"API called by package-listing","type":"backend"}]'
+   ```
+4. Write traced endpoints (all methods, including POST/PUT/DELETE):
+   ```bash
+   python3 "$plugin_root/scripts/perf-config.py" set-json workflow.traced_api_endpoints '[{"path":"/api/v2/packages","method":"GET","frontend_source":"src/pages/Packages.tsx:42","backend_handler":"src/handlers/packages.rs:get_packages","verified":true}]'
+   ```
+5. Set discovery method:
+   ```bash
+   python3 "$plugin_root/scripts/perf-config.py" set metadata.backend_endpoint_discovery_method frontend-trace
+   ```
+6. Validate:
+   ```bash
+   python3 "$plugin_root/scripts/perf-config.py" validate
+   ```
+
+#### Step 4.8.6 – Present Summary and Confirm
+
+Display tracing results:
+
+```
+API Tracing Results for workflow "{name}":
+- Frontend routes: {N}
+- Backend API endpoints traced: {M}
+  - GET (will measure): {G}
+  - POST/PUT/DELETE (trace only): {P}
+  - Verified against backend routes: {V}
+  - Unverified: {U}
+
+| # | Endpoint | Method | Frontend Source | Verified | Measurement |
+|---|---|---|---|---|---|
+| 1 | /api/v2/packages | GET | Packages.tsx:42 | Yes | Benchmark |
+| 2 | /api/v2/packages/:id | GET | PackageDetail.tsx:18 | Yes | Benchmark |
+| 3 | /api/v2/packages/:id/vulnerabilities | POST | PackageDetail.tsx:55 | Yes | Trace only |
+```
+
+**Blocking prompt:** "Continue with these backend API endpoints for measurement? (yes / edit / skip backend)"
+
+- **yes** → proceed to Step 5
+- **edit** → allow adding/removing endpoints (user can manually add POST/PUT with payloads)
+- **skip backend** → remove `type: "backend"` scenarios from config, set `analysis_scope` → `frontend-only`, `metric_type` → `frontend`. This is the intended escape hatch.
+
+## Step 5 – Discover Test Data
+
+### Step 5.0 – Check Analysis Scope
+
+- `frontend-only` → Step 5.3 (prompt)
+- `backend-only` / `full-stack` → Step 5.0.5
+
+### Step 5.0.5 – Serena Probe (if not already set)
+
+Run probe if `serena_mode` was not set in Step 3.0 (happens for full-stack scope).
+
+### Step 5.1 – Extract Workflow-Specific Scope
+
+Read workflow name and endpoint URLs from config. Resolve module directory. Discovery must be workflow-specific.
+
+For `full-stack` / `full-stack-monorepo`: read `workflow.traced_api_endpoints` to scope test data discovery to traced GET endpoints only.
+
+### Step 5.2 – Discover List Endpoints
+
+**backend-only:** Find GET endpoints without path parameters in `workflow_module_path` (Serena `find_symbol` or grep). Cross-reference against workflow endpoints. Store as `list_endpoints`.
+
+**full-stack / full-stack-monorepo:** Restrict to GET endpoints in `workflow.traced_api_endpoints` that have no dynamic segments (no `:id`, `:slug`, etc.). These are the list endpoints that provide sample IDs for dynamic segment resolution in other traced endpoints.
+
+**Dynamic segment resolution rules:**
+1. GET endpoints with no dynamic segments → direct manifest entry (`test_url` = path)
+2. GET endpoints with dynamic segments (`:id`, `:slug`) → find a corresponding list endpoint in `traced_api_endpoints` (e.g., `/api/v2/packages` provides IDs for `/api/v2/packages/:id`). Curl the list endpoint, extract sample IDs from response JSON (first 3 items). If no matching list endpoint exists, prompt user for sample values.
+3. POST/PUT/DELETE → not in manifest (traced for analysis only, per Step 4.8.4)
+
+### Step 5.3 – Frontend-Only Test Data Prompt
+
+Prompt user to confirm test data availability for the workflow. If no → halt. If yes → proceed.
+
+## Step 6 – Select Baseline Capture Mode
+
+### Step 6.0 – Check for Existing Mode
+
+If `stored_mode` is set (from Step 2.2): offer to use stored mode, reset, or cancel. If null (first run): proceed to Step 6.1.
+
+### Step 6.1 – Mode Selection
+
+Baseline uses **cold-start mode** (direct navigation, empty cache, fresh browser context per iteration). Inform user.
+
+### Step 6.2 – Read Baseline Settings
+
+Read `baseline_settings.iterations` (must be ≥ 20 for valid p95) and `warmup_runs` from config. Warn if iterations < 20.
+
+## Step 7 – Check for Existing Baseline
+
+Check for `{baseline-directory}/baseline-report.md`. If exists: offer Replace or Cancel. If replacing, read old metrics for comparison in Step 10.3. If not exists: set `old_metrics = null`.
+
+## Step 8 – Prepare Capture Script
+
+### Step 8.1 – Locate and Copy Template
+
+Verify `capture-baseline.template.mjs` exists in plugin cache. Copy to `{baseline-directory}/capture-baseline.mjs`.
+
+### Step 8.1.5 – Verify Playwright
+
+**Skip if backend-only.** ESM imports resolve relative to the script file, not CWD. If `{baseline-directory}/node_modules/@playwright/test` is missing:
+
+1. Read `repositories.frontend.path` from config
+2. If `{frontend_path}/node_modules/@playwright/test` exists → `ln -sf "{frontend_path}/node_modules" "{baseline-directory}/node_modules"`
+3. Else → halt: `npm install @playwright/test`
+
+Verify Chromium binary is installed. Halt if missing with `npx playwright install chromium`.
+
+### Step 8.3 – Script Review Prompt
+
+Explain: Playwright browser automation, Web Performance APIs, verification pass before measurement, localhost (default) or hosted (`--base-url`) with `--storage-state` (SSO/Keycloak) or `--user`/`--pass` (simple forms). Offer user review. **Blocking step.**
+
+### Step 8.3.5 – Application Startup
+
+Prompt user:
+1. **Already running** — provide URL(s) manually
+2. **Auto-discovery** — discover and start commands automatically
+3. **Hosted environment** — remote URL, not localhost
+4. **Exit** — cancel
+
+**If "Already running":** For each component in `analysis_scope`:
+
+| Component | Default Port |
+|---|---|
+| Frontend | 3000 |
+| Backend | 8080 |
+
+Prompt for URL (default or custom). Verify port is listening (`nc -z localhost {port}`). If fails → halt. If succeeds → store URL/port, skip to Step 9.
+
+**If "Hosted environment":** Prompt for base URL, auth method (`--storage-state <path>` for SSO/Keycloak — generate via `npx playwright codegen --save-storage=auth.json <url>`, or `--user`/`--pass` for simple forms, or none), and whether `--insecure` is needed. Verify reachable with `curl -ksI`. Store as in-memory variables — never write credentials to config. Skip to Step 9.
+
+**If "Auto-discovery":** Proceed to Step 8.4.
+
+### Step 8.4 – Dev Command Discovery (Auto-Discovery Only)
+
+For each component required by `analysis_scope` (backend first for full-stack):
+
+#### Step 8.4.1 – Check if Command Already Configured
+
+Check the component-specific sub-key: `dev_environment.backend` for backend, `dev_environment.frontend` for frontend. If that sub-key has `command_approved: true` → skip this component to Start step.
+
+**Backward compatibility:** If `dev_environment` is a flat object (has `command` at top level, no `frontend`/`backend` sub-keys), treat it as the single component matching `analysis_scope`. If scope is hybrid and config is flat → halt: "Re-run `/performance-setup` to update config for hybrid scope."
+
+#### Step 8.4.2 – Discover, Approve, and Save Command
+
+**Command discovery (first-match-wins):**
+
+| Priority | Frontend Source | Backend Source |
+|---|---|---|
+| 1 | `package.json` scripts: `dev`, `start:dev`, `start` | README/CONTRIBUTING: first `cargo run`/`mvn`/`uvicorn`/`npm start` line |
+| 2 | README/CONTRIBUTING: first `npm run` line | `Cargo.toml` `[[bin]]` → `cargo run --bin {name}` |
+| 3 | Makefile: `dev`/`start`/`run` target | `pom.xml` → `./mvnw spring-boot:run` |
+| 4 | Framework config presence → `npm run dev` | `build.gradle` → `./gradlew bootRun` |
+| 5 | Ask user | `manage.py`/`pyproject.toml` → `python manage.py runserver`/`uvicorn` |
+| 6 | — | `package.json` scripts → `npm run start` |
+| 7 | — | Ask user |
+
+**Port discovery (first-match-wins):** command flags → `.env` files → framework config → framework default (frontend: 3000, backend: 8080).
+
+**Approval prompt:** Show discovered command, source, port. User: approve / modify / exit.
+
+**Save:** Write to the component-specific sub-key (`dev_environment.frontend` or `dev_environment.backend`):
+
+```bash
+python3 "$plugin_root/scripts/perf-config.py" set-json dev_environment.frontend '{"command":"npm run dev","source":"package.json","port":3000,"command_approved":true,"last_validated":"2026-06-05T12:00:00Z"}'
+```
+
+Or scalars: `set dev_environment.frontend.command "npm run dev"`, `set dev_environment.frontend.port 3000`, `set dev_environment.frontend.command_approved true`.
+
+#### Step 8.4.3 – Start and Verify
+
+Start in background. Check port with `nc -z localhost {port}` every 2s for up to 60s. On timeout: offer extend 30s or abort.
+
+#### Step 8.4.B4 – Query and Confirm Test Data (Backend)
+
+If `manifest.json` doesn't exist, build it. **Endpoint source depends on scope:**
+
+**backend-only:** Discover list endpoints generically (grep backend codebase), curl each to extract sample IDs, generate manifest.
+
+**full-stack / full-stack-monorepo:** Build manifest from `type: "backend"` scenarios only (these were traced from the frontend workflow in Step 4.8). Do NOT run generic list endpoint discovery. For each `type: "backend"` scenario:
+1. URL has no dynamic segments → add to manifest directly: `{"test_url": "<url>", "parameters": {}}`
+2. URL has dynamic segments (`:id`, `:slug`) → substitute with sample IDs from Step 5.2 test data. If no sample IDs, prompt user.
+3. Verify each manifest endpoint: `curl -s -o /dev/null -w "%{http_code}" http://localhost:{port}{test_url}`. Flag non-200 responses.
+
+Display verification table:
+
+| Endpoint | Status | Time | Sample |
+|---|---|---|---|
+
+Flag SLOW (>5s), TIMEOUT, AUTH ERROR, NOT FOUND endpoints. Prompt: yes / edit / abort.
+
+**Full-stack: backend first, 5s initialization delay, then frontend.**
+
+## Step 9 – Execute Baseline Capture
+
+### Step 9.0 – Pre-Capture Validation
+
+Validate `workflow.name`, `workflow.entry_point`, and `workflow.key_screens` are non-null and non-empty. Halt if any are missing.
+
+### Step 9.1 – Config Validation
+
+Run `validate --phase baseline` before any capture. This catches missing scenarios, invalid ports, and missing base URLs before a 2-minute capture run fails.
+
+```bash
+python3 "$plugin_root/scripts/perf-config.py" validate --phase baseline
+```
+
+If validation fails, halt and report the errors — do not proceed to capture.
+
+### Step 9.2 – Scope-Based Capture
+
+Branch based on `analysis_scope`. Follow exactly ONE path:
+
+**Frontend-only:** Run Playwright capture (Steps 9.3–9.5).
+
+**Backend-only:** Run `perf-benchmark.sh` with `dev_environment.backend.port`, iterations, manifest path. Output: `{baseline-dir}/benchmark-results.json`.
+
+**Full-stack / full-stack-monorepo (hybrid):**
+1. Verify backend still running and manifest exists
+2. Verify manifest contains only endpoints from `workflow.traced_api_endpoints` (filter out any extra endpoints)
+3. Run Playwright frontend capture (Steps 9.3–9.5) → `baseline-report-frontend.json`. The capture script automatically filters to `type !== 'backend'` scenarios.
+4. Run `perf-benchmark.sh` with `dev_environment.backend.port` → `benchmark-results.json`
+5. Merge into hybrid `baseline-report.md` with frontend metrics, backend metrics, and API Correlation sections (see Step 10.3)
+6. Update metadata: `baseline_mode: "hybrid"`
+
+### Step 9.3 – Construct Playwright Command (Frontend/Hybrid)
+
+Auto-detect `performance-config.json` by walking up directory tree. Always use the absolute config path.
+
+**Localhost:**
+```
+node {baseline-directory}/capture-baseline.mjs --config "$config_path" --port {dev_environment.frontend.port}
+```
+
+**Hosted:** Include only the args the user provided in Step 8.3.5. Omit `--user`/`--pass` if not provided, omit `--insecure` if not needed.
+```
+node {baseline-directory}/capture-baseline.mjs --config "$config_path" --base-url "{base_url}" [--storage-state "{path}"] [--user "{user}" --pass "{pass}"] [--insecure]
+```
+
+### Step 9.4 – Execute and Handle Errors
+
+Run capture script. Handle errors:
+- Verification failed → display failed checks from script output; do NOT retry measurement
+- Connection refused → application not running
+- Playwright not found → install instructions
+- Invalid URLs → review config
+- Missing metrics → check browser console
+- Other → display error and halt
+
+### Step 9.5 – Parse JSON Output
+
+Parse script JSON output: scenarios (metrics per scenario), aggregate metrics, config.
+
+## Step 10 – Generate Baseline Report
+
+### Step 10.1 – Report Structure
+
+Read `baseline-report.template.md` from plugin cache.
+
+### Step 10.2 – Filter Scenarios by Workflow
+
+Match scenario URLs against selected workflow's key screens. Halt if no matches.
+
+### Step 10.3 – Populate Template
+
+**Frontend metrics** (from `capture-baseline.mjs` JSON output — all modes except backend-only):
+Replace placeholders: metadata (timestamp, repo, iterations), per-scenario metrics (LCP, FCP, DOM Interactive, Total Load Time), resource timing breakdown (top 10 by duration), ASCII waterfall per scenario. For the summary table, compute mean-of-scenario-p95s from per-scenario data (capture JSON has no cross-scenario aggregate).
+
+**Backend metrics** (from `benchmark-results.json` — backend-only and hybrid):
+Read the benchmark output JSON: `{"endpoints": {"<path>": {"p50_ms", "p95_ms", "p99_ms", "mean_ms", "cold_ms", "warm_cache_mean_ms", "cache_effectiveness_pct"}}, "aggregate": {...}}`. Per-endpoint: populate backend metrics table with response time percentiles and cache effectiveness. Aggregate: compute mean across all endpoint p95s for the summary table.
+
+**API Correlation section** (hybrid only, when `workflow.traced_api_endpoints` is non-empty):
+1. For each frontend scenario (route), look up which `traced_api_endpoints` have `frontend_source` files belonging to that route's module.
+2. Cross-reference with Playwright resource timing: extract Fetch/XHR entries from the capture output that match traced API paths. These represent actual in-page API wait time.
+3. If resource timing fetch data is available → use those durations for the "In-Page Fetch Time" column.
+4. If resource timing fetch data is unavailable (e.g., deferred fetches not captured during cold-start) → use `perf-benchmark.sh` p95 as "Isolated API p95" with a disclaimer.
+5. Do NOT compute "API % of Load" as a simple ratio — APIs may run in parallel, and page load includes rendering, fonts, JS parse. Present as a correlation table, not a causation table.
+
+**If re-baseline:** Include comparison table with old vs new p95 deltas.
+
+### Step 10.4 – Write Report
+
+Write to `{baseline-directory}/baseline-report.md`.
+
+### Step 10.5 – Update Configuration
+
+Run `set --help` if not already run this session. Update metadata and optimization targets with `set` (scalars only — use captured values from Step 10):
+
+```bash
+python3 "$plugin_root/scripts/perf-config.py" set metadata.baseline_captured true
+python3 "$plugin_root/scripts/perf-config.py" set metadata.baseline_mode cold-start
+python3 "$plugin_root/scripts/perf-config.py" set metadata.baseline_timestamp "2026-06-05T12:00:00Z"
+python3 "$plugin_root/scripts/perf-config.py" set metadata.baseline_commit_sha "<git-sha>"
+python3 "$plugin_root/scripts/perf-config.py" set metadata.capture_target hosted  # or "localhost"
+python3 "$plugin_root/scripts/perf-config.py" set metadata.capture_base_url "{base_url}"  # null for localhost
+# Compute summary p95: mean of per-scenario p95 values (ms), then divide by 1000 for seconds
+# First baseline: set optimization_targets.frontend.lcp.baseline AND .latest (repeat per metric)
+# Re-baseline: update .latest only, preserve original .baseline
+python3 "$plugin_root/scripts/perf-config.py" validate
+```
+
+- **First baseline:** Set both `baseline` and `latest` to captured p95 values (convert ms→seconds: divide by 1000)
+- **Re-baseline:** Update only `latest`, preserve original `baseline`
+- **Unit conversion:** Capture JSON emits ms; `optimization_targets.frontend.*` stores seconds. Always divide by 1000 before writing.
+
+## Step 11 – Output Summary
+
+```
+✅ Baseline captured successfully!
+
+Workflow: {name}
+Scenarios: {count}
+Report: performance/baselines/baseline-report.md
+
+Key Metrics:
+- LCP: {mean}ms (p95: {p95}ms)
+- FCP: {mean}ms (p95: {p95}ms)
+- DOM Interactive: {mean}ms (p95: {p95}ms)
+- Total Load Time: {mean}ms (p95: {p95}ms)
+
+{threshold-warnings}
+
+Next: Run /sdlc-workflow:performance-analyze-module
+```
+
+## Important Rules
+
+- Before any `perf-config.py` subcommand, run that subcommand's `--help` — never guess flags or argument order
+- Never modify source code — only create measurement artifacts
+- Each Bash invocation is isolated — re-derive values from config at each block
+- Never skip steps or produce partial output
+- Never auto-answer blocking prompts
+- URLs are localhost-only by default; remote URLs require explicit `--base-url` (Step 8.3.5 option 3)
+- Hosted mode applies to frontend Playwright capture only; backend `perf-benchmark.sh` is unchanged
+- Credentials never persisted to config files — pass via CLI args or `BASELINE_PASS` env var
+- `--insecure` is opt-in, not automatic with `--base-url`
+- Filter scenarios to selected workflow only
+- Generate ASCII waterfall visualization per scenario
+- Include comparison section with deltas when re-baselining
diff --git a/plugins/sdlc-workflow/skills/performance-plan-optimization/SKILL.md b/plugins/sdlc-workflow/skills/performance-plan-optimization/SKILL.md
new file mode 100644
index 000000000..4fe5ed61a
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance-plan-optimization/SKILL.md
@@ -0,0 +1,482 @@
+---
+name: performance-plan-optimization
+description: |
+  Read analysis reports and generate structured optimization plan with Jira Epic and Tasks. Primarily organizes findings from performance-analyze-module; limited source inspection in Step 5 for impact analysis.
+argument-hint: "[target-repository-path]"
+---
+
+# performance-plan-optimization skill
+
+You are an AI optimization planning assistant. You generate a structured optimization plan by **reading** module-level analysis reports (created by `performance-analyze-module`), grouping optimization recommendations into logical tasks, creating Jira Epic and Tasks, and producing an optimization-plan.md document.
+
+**Key Distinction:** This skill primarily reads analysis reports and creates Jira tasks. Limited source code inspection occurs in Step 5 (cross-functional impact analysis) for scope and effort estimation.
+
+### Plugin Root Resolution
+
+Every bash block that references `$plugin_root` must begin with:
+
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then echo "❌ sdlc-workflow plugin not found"; exit 1; fi
+```
+
+## Guardrails
+
+- Creates files in `performance/plans/` only -- does NOT modify source code
+- Requires an existing `workflow-analysis-report.md` from analyze-module
+- All RECOMMEND and CAUTION optimizations get Jira tasks (none silently skipped)
+- All cross-functional impacts documented in Epic description
+- Plan document saved locally even if Jira operations fail
+
+**Blocking steps:** Step 4 zero-findings decision | Step 8 Epic credential confirmation | Step 9 per-task credential confirmation
+
+**Error handling:** Missing report -> halt at Step 3, run analyze-module | Jira MCP unavailable -> REST fallback per `shared/jira-rest-fallback.md` | Jira credential failure -> retry once, then halt
+
+## Step 1 -- Determine Target Repository
+
+Use user-provided path or current working directory. Verify repository type matches `metadata.analysis_scope` in `performance-config.json`.
+
+## Step 2 -- Verify Performance Configuration
+
+Read `performance-config.json`. Stop if missing. Extract: selected workflow name, target directories (plans directory location).
+
+## Step 3 -- Resolve Analysis Report Path
+
+Extract `analysis_dir` from config `directories.analysis`. Construct path: `{analysis_dir}/workflow-analysis-report.md`.
+
+## Step 4 -- Read and Parse Analysis Report
+
+Read `metadata.metric_type` from config to determine which anti-pattern sections to parse.
+
+Read the analysis report. Validate in order:
+
+1. **Report exists** -- if not, halt: run `/sdlc-workflow:performance-analyze-module` first
+2. **Anti-Pattern Analysis section present** -- if not, halt: report incomplete, re-run analyze-module
+3. **Validation artifact exists** -- read `{analysis_dir}/findings-validation.json`; if missing, halt: re-run analyze-module
+4. **Run validation checklist** -- apply rules A1-A7 and R1-R5 from [Finding Validation](../performance/finding-validation.md) against artifact + report. Accept schema_version `"1.0"` or `"1.1"`. Output checklist table. If any rule FAIL, halt
+5. **Reject unvalidated** -- if report header shows `Validation Status: not validated`, halt
+6. **Zero actionable findings:**
+
+   | Condition | Action |
+   |---|---|
+   | `submitted == 0` | Offer: (1) empty-state Epic, or (2) cancel and re-run |
+   | `submitted > 0`, zero Confirmed + Downgraded | Halt: all discarded, point to artifact |
+   | One or more Confirmed/Downgraded | Proceed to Step 5 |
+
+Parse findings using artifact dispositions -- Jira tasks only for Confirmed or Downgraded IDs.
+
+**Extract from validated report:** workflow metrics (name, current/target values, rating), anti-pattern findings (name, severity, instances, estimated impact, code locations, fixes), prioritized optimizations (sorted by impact with effort estimates).
+
+## Step 5 -- Cross-Functional Impact Analysis
+
+Analyze potential impact of each optimization on other functionalities before task grouping.
+
+**Scaling:** If >15 findings, full analysis on top 10 by impact. Remainder noted as "Cross-functional impact not analyzed -- manual review recommended."
+
+### Step 5.1 -- Identify Affected Code Modules
+
+Use Serena MCP first for symbol/reference discovery; fall back to Grep if unavailable. Always record which method was used and confidence level.
+
+For each optimization target:
+- Find references to affected component/function
+- Store: file paths, line numbers, usage context
+- Classify scope: Isolated (0 files) | Low (1-2) | Medium (3-5) | High (6+)
+
+### Step 5.2 -- Assess Cross-Functional Impact
+
+For each optimization with scope >= Low:
+
+**Count affected workflows** by searching for workflow entry points (route/page components) that import affected code. Cross-reference with workflows in config.
+
+**Classify severity:** None | Low (1-2 workflows) | Medium (3-4) | High (5-10) | Critical (all workflows or core infrastructure)
+
+**Identify risk factors:**
+
+| Risk Factor | Examples |
+|---|---|
+| Breaking Change | API contract change, removed parameter |
+| Behavioral Change | Caching changes data freshness, retry logic changes |
+| Performance Trade-off | Caching reduces latency but increases memory |
+| Cosmetic Change | Layout shifts, animation timing |
+| Infrastructure Change | Adding Redis, new service dependency |
+
+### Step 5.3 -- Decision Framework
+
+Apply rules in order to determine each optimization's disposition:
+
+| Rule | Condition | Decision |
+|---|---|---|
+| 1 | Scope = Isolated AND Severity = None | RECOMMEND |
+| 2 | Benefit >= 20% AND Scope <= Medium AND Severity <= Medium | RECOMMEND |
+| 3 | Benefit 10-20% AND Scope <= Low AND Severity <= Medium | CAUTION |
+| 4 | Benefit >= 20% AND Scope = Medium AND Severity = High | CAUTION |
+| 5 | Benefit >= 20% AND Scope = High AND Severity = Critical | CONDITIONAL |
+| 6 | Benefit < 10% AND Severity >= High | DEFER |
+| 7 | Risk includes Infrastructure Change AND infra not deployed | CONDITIONAL |
+| 8 | Benefit < 5% AND Scope >= Medium | REJECT |
+| 9 | Default | DEFER |
+
+**Decision outcomes:**
+
+- **RECOMMEND** -- create Jira task, standard process
+- **CAUTION** (RECOMMEND WITH CAUTION) -- create Jira task + safeguards: feature flag for gradual rollout, regression testing for affected workflows, staging validation, rollback plan, rollback trigger (any Core Web Vital degrades >10% OR error rate >2%)
+- **CONDITIONAL** -- document requirements, do NOT create task yet (prerequisites not met)
+- **DEFER** -- document for future review, do NOT create task (risk > benefit currently)
+- **REJECT** -- document reasoning, do NOT create task (risk far outweighs benefit)
+
+Every decision must include transparent rationale based on this framework.
+
+### Step 5.4 -- Document Impact Analysis
+
+For each optimization, document: performance benefit (quantified), impact scope/severity, detection method + confidence, affected components and workflows, risk factors, decision + rationale, required safeguards (if CAUTION), prerequisites (if CONDITIONAL), conditions for reconsideration (if DEFER), alternatives (if REJECT).
+
+**Impact calculation formulas (use as applicable):**
+- Bundle size reduction: `size_reduction_kb / (bandwidth_mbps * 125) * 1000` ms
+- N+1 fix: `(n_queries - 1) * db_latency_ms` (default 10ms)
+- Deep service chain N+1: use effective query count from call graph
+- Missing index: assume 80-95% reduction for affected query
+- Wasted computation: `(wasted_fields / total_fields) * avg_service_latency_ms`
+- Caching: `operation_time * cache_hit_rate`
+- Over-fetching fix: `(unused_fields / total_fields) * response_size_kb`
+
+Store all impact analysis data for Steps 5.5-9.
+
+### Step 5.5 -- Database Migration Script Generation (New Migrations)
+
+**Guard:** Runs when any RECOMMEND or CAUTION finding has anti-pattern type in: Missing Index, Sequential Scan, Nested Loop, Row Estimate Mismatch, Unused JOINs, Inefficient Queries, SQL Duplication. Key off anti-pattern type, not step numbers — covers findings from both static analysis (Steps 7.6, 7.6.1, 7.6.4, 7.6.5) and live analysis (Step 9.7.4).
+
+**Skip when:** no database-related findings exist among RECOMMEND/CAUTION dispositions.
+
+#### Step 5.5.1 -- Read CONVENTIONS.md
+
+**Mandatory.** Read the target repository's `CONVENTIONS.md`. If CONVENTIONS.md is missing, halt with: "CONVENTIONS.md is required for database migration planning. Document migration patterns (naming, index naming, file structure, FK index policy) before proceeding."
+
+Extract migration-related conventions: naming patterns, file structure, index naming, transaction handling, FK index policy, rollback requirements. Scan 2-3 existing migration files in the repository to validate conventions match practice.
+
+Any migration pattern found in existing files but NOT documented in CONVENTIONS.md → flag as a recommended convention addition in the plan output.
+
+#### Step 5.5.2 -- Detect Migration Framework
+
+Read `repositories.backend.framework` from config. Map to migration tool and path pattern:
+
+| Framework | Migration Tool | Path Pattern |
+|---|---|---|
+| Rust (SeaORM) | SeaORM Migration | `migration/src/m{YYYYMMDD}_{HHMMSS}_{name}.rs` |
+| Rust (Diesel) | Diesel | `migrations/{date}_{name}/up.sql` + `down.sql` |
+| Rust (sqlx) | sqlx migrate | `migrations/{timestamp}_{name}.sql` |
+| Python (Django) | Django | `{app}/migrations/{NNNN}_{name}.py` |
+| Python (SQLAlchemy) | Alembic | `alembic/versions/{rev}_{name}.py` |
+| Java (Spring) | Flyway | `src/main/resources/db/migration/V{N}__{name}.sql` |
+| Node (TypeORM) | TypeORM | `src/migration/{timestamp}-{name}.ts` |
+| Node (Prisma) | Prisma | `prisma/migrations/{timestamp}_{name}/migration.sql` |
+
+If the detected framework is not in the table, default to raw SQL migration files and document the limitation.
+
+#### Step 5.5.3 -- Generate Manual Verification Artifacts
+
+For each database finding, produce raw SQL artifacts the user can run directly against their database:
+
+- **Before SQL** — the current query, with its EXPLAIN ANALYZE output if live analysis (Step 9.7) was performed
+- **After SQL** — the optimized query for manual `EXPLAIN ANALYZE` verification
+- **Migration up SQL** — the DDL change (e.g., `CREATE INDEX CONCURRENTLY ...` for production use)
+- **Migration down SQL** — the rollback DDL (e.g., `DROP INDEX IF EXISTS ...`)
+
+Manual verification SQL recommends `CREATE INDEX CONCURRENTLY` for production safety. Framework migration scripts (Step 5.5.4) do not use CONCURRENTLY because most migration runners wrap in transactions where CONCURRENTLY is invalid.
+
+- **Storage impact queries** — for each migration, include before/after size queries so the user can measure storage cost:
+  - Queries must show: total relation size, table data size, total index size, and per-index size breakdown.
+  - Derive SQL dialect from the migration framework detected in Step 5.5.2 (e.g., PostgreSQL for SeaORM/Diesel/sqlx, MySQL for TypeORM with MySQL). Example for PostgreSQL: `pg_total_relation_size()`, `pg_relation_size()`, `pg_indexes_size()`, `pg_stat_user_indexes`.
+  - If the finding's reason mentions the table was not found in migration files, prepend a warning: "Confirm table name before running — table not found in migration DDL."
+
+#### Step 5.5.4 -- Generate Framework Migration Script
+
+Produce the migration in the framework's idiomatic format, following CONVENTIONS.md patterns from Step 5.5.1. This is the source code that implement-task will write to the codebase.
+
+Include before/after comments referencing the raw SQL from Step 5.5.3.
+
+#### Step 5.5.5 -- Present to User
+
+For each migration, present both layers:
+
+1. **Manual verification block:** Before SQL + EXPLAIN output, After SQL, Migration up/down SQL (with CONCURRENTLY), and verification command (`EXPLAIN ANALYZE {optimized_query}`)
+2. **Source code block:** Framework migration script that implement-task will apply
+3. **Storage impact block:** Before/after size queries for the affected table(s)
+
+#### Step 5.5.6 -- Safety Checks
+
+Verify for each migration:
+- No column drops or data loss operations (DELETE, TRUNCATE, ALTER COLUMN DROP)
+- Rollback/down migration is non-destructive
+- Migration follows CONVENTIONS.md patterns
+
+### Step 5.6 -- Migration SQL Optimization Handling (Existing Migrations)
+
+**Guard:** Runs when any RECOMMEND or CAUTION finding has anti-pattern type in: Missing Statistics Refresh, Non-Materialized CTE Re-evaluation, Uniform Processing of Partitionable Data, Expensive PL/pgSQL Function Pattern. Key off anti-pattern type — these come from analyze-module Steps 7.8.1-7.8.4.
+
+**Skip when:** no migration-SQL-optimization findings exist among RECOMMEND/CAUTION dispositions.
+
+**Key distinction from Step 5.5:** Step 5.5 generates NEW migration files (e.g., CREATE INDEX for a missing index). Step 5.6 generates patches to EXISTING migration files (e.g., adding ANALYZE before a backfill, materializing a CTE, rewriting a PL/pgSQL function). The implementation approach differs: Step 5.5 produces a complete new migration script; Step 5.6 produces before/after diffs of existing files.
+
+#### Step 5.6.1 -- Read Existing Migration File
+
+For each migration SQL optimization finding, locate and read the specific migration file containing the anti-pattern. The finding's `file` field from `findings-validation.json` provides the path. Verify the file exists and the evidence excerpt matches.
+
+#### Step 5.6.2 -- Generate Fix Artifacts
+
+For each finding, produce:
+
+- **Before SQL** — the current migration code (exact excerpt from the file)
+- **After SQL** — the corrected migration code with the anti-pattern resolved
+- **Explanation** — why the change improves performance, with estimated impact
+- **Verification SQL** — a runnable command to confirm the fix works
+
+Fix patterns by anti-pattern type:
+
+| Anti-Pattern | Fix Pattern | Verification |
+|---|---|---|
+| Missing Statistics Refresh | Insert `ANALYZE {table};` before the backfill DML | `EXPLAIN ANALYZE {backfill_query}` — verify planner row estimates are within 10x of actual |
+| Non-Materialized CTE | Add `MATERIALIZED` keyword to CTE definition | `EXPLAIN {query}` — verify CTE appears as "CTE Scan" (not inlined) |
+| Uniform Processing | Split query into two passes: one for rows matching the partition predicate (with JOIN + function), one for the rest (direct insert without JOIN/function) | Run both passes and verify combined result matches original single-pass result |
+| Expensive PL/pgSQL Pattern | Replace `regexp_replace()` with boundary-aware `replace()` calls; eliminate per-row queries with batch operations | Timing comparison: `\timing` + `SELECT expand_fn_old(...)` vs `SELECT expand_fn_new(...)` on representative data |
+
+#### Step 5.6.3 -- Safety Checks
+
+Verify for each fix:
+- Fix preserves the migration's semantic correctness (same data outcome after migration completes)
+- Fix is idempotent if the migration is re-run (ON CONFLICT handling preserved)
+- No data loss operations introduced
+- For function rewrites: verify the new function produces identical output for all input patterns (boundary cases, edge cases, NULL handling)
+
+## Step 6 -- Group Optimizations into Logical Tasks
+
+Group only **RECOMMEND** and **CAUTION** optimizations into tasks. CONDITIONAL/DEFER/REJECT are documented in the plan but do NOT become Jira tasks.
+
+**If all filtered out:** Create Epic with summary note, document deferred items, skip to Step 11.
+
+### Task Grouping by Layer + Type
+
+**Layer 1 -- Frontend:** 1A Bundle Size (splitting, tree shaking, lazy loading) | 1B Render (memoization, virtual scrolling, layout thrashing) | 1C Resource (async/defer scripts, parallel loading, image optimization)
+
+**Layer 2 -- Backend** (when configured): 2A Query (N+1, deep chain N+1, pagination, indexes, query rewrites) | 2B Response (over-fetching, wasted computation, caching)
+
+Database migration findings (Missing Index, Sequential Scan, Unused JOINs, Inefficient Queries, SQL Duplication) are grouped under Layer 2A with the `db-migration` label in addition to `performance-optimization`. Index-related findings go into one migration task; query rewrite findings go into a separate task. Each migration task includes the generated migration script (from Step 5.5.4) in Implementation Notes and the manual verification artifacts (from Step 5.5.3) in the Database Migration extension section.
+
+Migration SQL optimization findings (Missing Statistics Refresh, Non-Materialized CTE Re-evaluation, Uniform Processing of Partitionable Data, Expensive PL/pgSQL Function Pattern) are grouped under Layer 2A with the `migration-sql-optimization` label in addition to `performance-optimization`. These are distinct from `db-migration` tasks — they fix EXISTING migration files rather than generating new ones. Group by migration file: findings in the same migration file go into one task. Each task includes the before/after SQL (from Step 5.6.2) in Implementation Notes and the verification commands in the Migration SQL Optimization extension section.
+
+**Strategic materialization promotion:** When the analysis report's Strategic Optimizations section (S1, S2, ...) identifies a materialized view, denormalized table, or pre-computed column that would eliminate a join chain appearing in 2+ N+1/query findings (cross-reference by finding ID in the analysis report's prioritized findings table, e.g., F1, F2, ...), promote it to a **separate db-migration task** under Layer 2A with the `db-migration` label. The task description must include: the target table schema (columns, types, constraints), the source query being materialized, the migration script (up/down) generated via Step 5.5, and which findings it resolves (by ID). This task should be sequenced before the N+1 fix tasks that depend on it, since the materialized table simplifies those fixes.
+
+**Layer 3 -- Integration:** 3A API Communication (batch calls, parallel fetching, client-side caching)
+
+### Task Structure
+
+Each task includes: summary ("{Category}: {Description}"), description, files to modify, baseline/target metrics, acceptance criteria, performance test requirements, dependencies.
+
+### N+1 Loop Elimination Mandate
+
+When a task addresses an N+1 or sequential-loop finding, the task's Implementation Notes MUST:
+
+1. **Identify the outermost iteration boundary** — the specific loop (`for`/`while`/`.map`), its location (function, file, line), and the data source it iterates over. If `loop_origin` is present in the finding (from analyze-module Step 7.3), use it directly. If `loop_origin` is not available (older analysis runs), inspect the finding's code location and trace outward to the enclosing loop using Serena or Grep.
+2. **State explicitly:** "This loop must be eliminated or replaced with a batch operation that processes all items together. Adding batch helpers inside the loop body while retaining the sequential loop is insufficient — it reduces per-iteration cost but preserves the O(N) sequential query pattern."
+3. **Specify the batch entry point** — which function should accept all items at once and process them in bulk (e.g., "Replace `for matched in rows { resolve_sbom_cpe(matched, ...) }` with a single `batch_resolve_sbom_cpes(rows, ...)` call").
+
+This ensures implement-task understands that the loop itself is the optimization target, not just the code inside it.
+
+### Pre-Fetch Mandate for Concurrent Per-Item Queries
+
+When a task addresses a `Pre-Fetchable Concurrent Queries` finding (from analyze-module Step 7.3.1), the task's Implementation Notes MUST:
+
+1. **Identify the data accessed per-item** — which DB entities or queries are called inside the concurrent body, and what keys they use (e.g., `sbom_id`, `node_id`, `checksum_value`).
+2. **Design a pre-fetch cache** — specify a cache struct that holds the pre-fetched data (e.g., `HashMap<(Uuid, String), Vec<Model>>`). The cache should be:
+   - Built once before the concurrent processing starts (immutable after construction — no locks during concurrent reads)
+   - Scoped to the request lifetime (dropped at end of request, no TTL management)
+   - Populated via batch queries (1-3 queries total, not per-item)
+3. **Specify the integration point** — where the pre-fetch call should be inserted (before the concurrent iteration starts), how the cache should be passed to the concurrent body (e.g., `Arc<Cache>` cloned per task), and how per-item code should use the cache (cache-first with DB fallback for cache misses).
+4. **State explicitly:** "The per-item DB queries inside the concurrent iteration must be replaced with cache lookups. The concurrent structure itself (`buffer_unordered`, `Promise.all`, etc.) should be preserved — only the DB calls inside it should be eliminated."
+
+### Query Restructuring Mandate
+
+When a task addresses a `Cross-Table OR Filter` (7.6.7), `Load-All-Then-Search` (7.6.8), or `Inefficient Queries` (7.6) finding that involves decomposing a single query with cross-table OR/ILIKE conditions into per-entity queries, the task's Implementation Notes MUST:
+
+1. **Document the original query pattern** — the single query with cross-table OR conditions, which tables are joined, and why the optimizer abandons indexes (e.g., OR across LEFT JOINed tables forces sequential scan).
+2. **Specify the decomposed pattern** — how many per-entity branches, and what each branch's join/filter scope is (e.g., "node branch: base table only, no joins; cpe branch: base table → cpe_ref → cpe; purl branch: base table → purl_ref → qualified_purl").
+3. **Define the result merging strategy** — for subquery paths: UNION DISTINCT via query builder folding; for materialized paths: in-application sort + dedup on the composite key.
+4. **State the equivalence constraint explicitly:** "The decomposed queries MUST return the same result set as the original single query for both bare queries (e.g., `q=openssl`) and field-qualified queries (e.g., `q=name~openssl`). Field-qualified queries must route to the correct single branch without behavioral change. Verify equivalence with the repository's existing integration test harness."
+5. **Specify edge case handling** — each branch applies the filter to its column set; branches whose columns do not match the query fields fail filter parsing and are silently excluded. When all branches fail, the original combined column set must be used to produce the user-facing error message. When at least one branch succeeds but returns zero rows, the result is empty (not an error).
+
+### Migration SQL Fix Mandate
+
+When a task addresses a migration SQL optimization finding (from analyze-module Steps 7.8.1-7.8.4), the task's Implementation Notes MUST:
+
+1. **Identify the exact migration file and line range** — the specific `.sql` or `.rs` migration file, the DML statement(s) or function definition affected, and the line numbers from the analysis finding.
+2. **Show before/after SQL** — the exact current code and the corrected code from Step 5.6.2. For PL/pgSQL function rewrites, show the complete function body before and after.
+3. **State the deployment status constraint explicitly:** "This migration file may have already been applied to production databases. The fix must be delivered as a NEW migration file that corrects the data state and replaces the function definition, OR as a modification to the existing migration file if it has not yet been deployed. Confirm deployment status before implementation."
+4. **Specify verification:** For Missing Statistics Refresh fixes, provide `EXPLAIN ANALYZE` commands to verify the planner uses correct row estimates after ANALYZE. For CTE materialization fixes, provide `EXPLAIN` to verify single CTE evaluation. For function rewrites, provide a timing comparison query (old function vs new function on representative data). For query splits, provide a result-equivalence check query.
+
+### Task Sequencing
+
+1. Quick wins first (low effort, high impact)
+2. Dependencies (tasks that unblock others)
+3. Risk (low-risk before high-risk)
+
+## Step 7 -- Generate Optimization Plan Document
+
+### Step 7.1 -- Location
+
+Read plans directory from config `directories.plans`. Filename: `optimization-plan.md`.
+
+### Step 7.2 -- Populate Template
+
+Read the plan template from `$plugin_root/skills/performance/performance-plan.template.md` and populate with calculated values from Steps 5-6.
+
+### Step 7.3 -- Calculate Expected Impact
+
+Based on `metric_type`: sum estimated improvements across all optimizations, calculate percentage reduction, use conservative (lower bound) estimates. Summed impact is a rough upper bound — individual improvements are not necessarily additive. Present as "estimated up to X improvement" not "will save X."
+
+### Step 7.4 -- Calculate Total Effort
+
+Low = 0.5 day | Medium = 2 days | High = 5 days. Sum across all tasks.
+
+### Step 7.5 -- Write Plan
+
+Write to `{plans-directory}/optimization-plan.md`.
+
+## Step 8 -- Create Jira Epic
+
+### Step 8.1 -- Epic Content
+
+**Summary:** `Performance Optimization: {workflow-name}`
+
+**Description** includes: workflow name, current/target rating, executive summary (task count, total effort, expected impact by metric_type), risk profile (total evaluated, tasks created, deferred/rejected counts, risk distribution), task sequence list.
+
+Footer: `_This Epic was AI-generated by sdlc-workflow/performance-plan-optimization v{version}._`
+
+### Step 8.2 -- Create Epic via Jira
+
+**Attempt MCP first:**
+
+```
+mcp__atlassian__createJiraIssue(
+  project_key, summary, description, issue_type="Epic",
+  labels=["ai-generated-jira", "performance-optimization", workflow-name]
+)
+```
+
+**If MCP fails**, prompt user with standard fallback (see `shared/jira-access-strategy.md`):
+1. Yes -- use REST API via `python3 "$plugin_root/scripts/jira-client.py" create_issue ...`
+2. No -- skip Jira, save plan locally, skip to Step 11
+3. Retry -- retry MCP once
+
+### Step 8.3 -- Capture Epic Key
+
+Store Epic key (e.g., `TC-5001`) for task creation and linking.
+
+## Step 9 -- Create Jira Tasks
+
+For each grouped task from Step 6:
+
+### Step 9.1 -- Task Description
+
+Read the task template from `$plugin_root/skills/performance/optimization-task.template.md` and populate with: repository, description, files to modify, baseline/target metrics (by metric_type), implementation notes, cross-functional impact assessment (decision, scope, severity, detection method, confidence, affected workflows/components, risk factors, safeguards if CAUTION, testing requirements), acceptance criteria, performance test requirements, dependencies.
+
+**Query safety constraints from CONVENTIONS.md:** When generating Implementation Notes for tasks that involve batch queries or dynamic SQL, search the target repository's `CONVENTIONS.md` for documented query safety patterns:
+- Parameter limit handling (e.g., PostgreSQL's 65535 bind parameter limit)
+- Chunking utilities (e.g., `chunked_with`, `batch_execute`)
+- Preferred SQL patterns for bulk operations (e.g., `UNNEST` arrays vs inline `VALUES` clauses vs `Condition::any()` chains)
+
+If CONVENTIONS.md documents a utility for parameter-safe batching (e.g., `trustify_common::db::chunk::chunked_with`), reference it by path in the Implementation Notes and state: "All batch queries MUST use `{utility}` or an equivalent parameter-safe pattern. Do not generate unbounded parameter lists (inline `VALUES` with 2*N params or `Condition::any()` with N compound filters) — these will hit PostgreSQL's 65535 parameter limit at scale."
+
+**Target Metrics scoping:** When populating the Target Metrics section of each task, include ONLY the metrics that the specific optimization is expected to affect:
+- Bundle size tasks: only frontend size metrics (bundle size, transfer size)
+- N+1 query tasks: only backend response time metrics (p95, p99)
+- Render optimization tasks: only DOM Interactive, LCP
+- Cross-layer tasks: both frontend and backend metrics
+
+Do NOT copy all workflow-level metrics into every task.
+
+**Unit conversion:** `optimization_targets` stores frontend metrics in seconds; reports and Jira tasks use milliseconds. Multiply by 1000 when populating task Baseline/Target Metrics from config values.
+
+### Step 9.2 -- Create Task via Jira
+
+**MCP first**, same fallback flow as Epic (Step 8.2).
+
+```
+mcp__atlassian__createJiraIssue(
+  project_key, summary, description, issue_type="Task",
+  labels=["ai-generated-jira", "performance-optimization", workflow-name, layer, category]
+)
+```
+
+**Labels:** layer = "frontend" | "backend" | "integration". Category = "bundle-size" | "render-optimization" | "resource-optimization" | "query-optimization" | "response-optimization" | "api-communication" | "db-migration" | "migration-sql-optimization".
+
+For `db-migration` tasks: include both `performance-optimization` and `db-migration` labels. The `performance-optimization` label maintains Epic grouping; the `db-migration` label enables task type detection in implement-task and verify-pr.
+
+For `migration-sql-optimization` tasks: include both `performance-optimization` and `migration-sql-optimization` labels. The `performance-optimization` label maintains Epic grouping; the `migration-sql-optimization` label distinguishes "fix existing migration SQL" from "create new migration" (`db-migration`). These tasks fix performance anti-patterns in existing migration files (backfill queries, PL/pgSQL functions) rather than generating new DDL migrations.
+
+### Step 9.3 -- Set Epic as Parent
+
+Set Epic as parent using Jira hierarchy (not issue links):
+
+**At creation time (preferred):** pass `parent=<epic-key>` in `createJiraIssue`.
+
+**After creation (fallback):** `mcp__atlassian__editJiraIssue(issue_key, fields={"parent": {"key": epic-key}})`.
+
+**REST fallback:** `python3 "$plugin_root/scripts/jira-client.py" update_issue {task-key} --fields-json '{"parent": {"key": "{epic-key}"}}'`
+
+**Legacy Jira:** fall back to `customfield_10014` (Epic Link) if parent field unsupported.
+
+### Step 9.4 -- Link Task Dependencies
+
+For tasks with dependencies, create "Blocks" links:
+
+```
+mcp__atlassian__createIssueLink(inward=prerequisite-key, outward=dependent-key, type="Blocks")
+```
+
+REST fallback: `python3 "$plugin_root/scripts/jira-client.py" create_link --inward {key} --outward {key} --link-type "Blocks"`
+
+## Step 10 -- Post Plan as Epic Comment
+
+Read `{plans-directory}/optimization-plan.md` and post as comment on the Epic.
+
+**MCP:** `mcp__atlassian__addCommentToJiraIssue(epic-key, plan-content)`
+
+**REST fallback:** `python3 "$plugin_root/scripts/jira-client.py" add_comment {epic-key} --comment-md "{content}"`
+
+Append footer: `_This comment was AI-generated by sdlc-workflow/performance-plan-optimization v{version}._`
+
+## Step 11 -- Output Summary
+
+Report to the user:
+
+> **Optimization plan created successfully!**
+>
+> **Workflow:** {workflow-name}
+> **Expected Impact:** {metric improvements by metric_type}
+> **Plan:** `performance/plans/optimization-plan.md`
+> **Epic:** {epic-key} -- "Performance Optimization: {workflow-name}"
+> **Tasks:** {task-count} tasks (list each key + summary)
+> **Effort:** {total-effort-days} days
+>
+> **Next Steps:**
+> 1. Review plan and tasks with your team
+> 2. Implement: `/sdlc-workflow:implement-task {task-key}` (performance sections auto-detected)
+> 3. After each task's PR merges to the target branch, re-baseline on the target branch: `/sdlc-workflow:performance-baseline`
+
+If Jira was skipped, adjust: note plan saved locally, Jira not created.
+
+> ⚠️ **Before implementing:** Ensure CONVENTIONS.md exists in the target repository with CI check commands and performance test commands. implement-task will halt without it.
+
+## Important Rules
+
+- Never modify source code -- only planning artifacts and Jira issues
+- Always verify analysis report exists before proceeding
+- Group optimizations into logical tasks with clear boundaries (not one task per finding)
+- Task sequencing must follow dependencies (quick wins first)
+- All Jira issues include `ai-generated-jira` label
+- Use conservative effort estimates (upper bound)
+- Impact analysis (Step 5) is mandatory before task grouping
+- Use Serena MCP first for code analysis, Grep fallback; always document which method used
+- Only RECOMMEND and CAUTION become Jira tasks; CONDITIONAL/DEFER/REJECT documented in plan with rationale
+- If all optimizations deferred/rejected, create Epic with summary, document in plan
+- If impact analysis fails for an optimization, default to DEFER with "Manual review required"
+- Deferred/rejected optimizations must include conditions for reconsideration
diff --git a/plugins/sdlc-workflow/skills/performance-setup/SKILL.md b/plugins/sdlc-workflow/skills/performance-setup/SKILL.md
new file mode 100644
index 000000000..59941d3c7
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance-setup/SKILL.md
@@ -0,0 +1,230 @@
+---
+name: performance-setup
+description: |
+  Initialize Performance Analysis Configuration by setting up directories, baseline settings, backend configuration, and optimization targets. Workflow selection happens in performance-baseline.
+argument-hint: "[target-repository-path]"
+---
+
+# performance-setup skill
+
+You are an AI performance setup assistant. You initialize the performance analysis infrastructure for a project: creating directories, configuring baseline capture settings, backend repository (if any), and creating a minimal `performance-config.json` with empty workflow, scenarios, and module sections. Workflow discovery and selection happen in `performance-baseline`, not here.
+
+## Plugin Root
+
+Every bash block that calls `perf-config.py` or references `$plugin_root` must begin with:
+
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then echo "❌ sdlc-workflow plugin not found"; exit 1; fi
+```
+
+Before calling `perf-config.py`, run `python3 "$plugin_root/scripts/perf-config.py" init --help` (or the relevant subcommand's `--help`). Use documented flags only — do not guess argument names.
+
+## Guardrails
+
+- Creates `performance-config.json` and `performance/` directory structure. Never modifies source code.
+- Idempotent — re-running on configured repo offers update or skip.
+- **Blocking steps:** 0.5 (architecture), 1.2 (validation), 1.3 (backend config), 4 (targets confirmation).
+- **Completeness:** All 5 directories created; all config sections populated; all paths validated before writing.
+- **Errors:** Architecture detection failure → halt Step 1.1; path validation failure → halt Step 3; config write failure → halt Step 7.
+- **Fast-path to first blocking prompt:** On entry, immediately check for existing config (Step 0) and jump to the first user-blocking question (Step 0.5 architecture prompt). Skip all non-blocking verification until after that blocking question is answered. The goal is to surface the first question to the user in the very first response.
+
+## Step 0 – Detect Existing Configuration
+
+Check if `performance-config.json` exists. If yes, prompt: *"Config exists. (1) Update (2) Skip?"* — if Skip, stop. If not exists, proceed.
+
+## Step 0.5 – Prompt for Repository Architecture
+
+Prompt the user:
+
+> 1. **Full-stack/monorepo** — Frontend + backend in same repo (browser + API + DB metrics)
+> 2. **Separate repositories** — Frontend and backend in different repos (you'll provide paths)
+> 3. **Frontend-only** — Browser metrics, bundle size, component rendering only
+> 4. **Backend-only** — API endpoints, database queries, response schemas only
+> 5. **Cancel**
+
+Store selection as `repository_architecture_choice`.
+
+## Step 1 – Detect Repository Patterns and Validate Choice
+
+### Step 1.1 – Detection Functions
+
+**Frontend detection** (require 2+ indicators): `package.json`, `src/` dir, framework configs (`next.config.{js,ts}`, `vite.config.{ts,js}`, `webpack.config.js`, `rsbuild.config.{ts,js}`), router files (`src/routes.tsx`, `src/router/index.ts`, `src/App.tsx`, `app/` dir). Returns `is_frontend`, `detected_framework`, `confidence` (high=3+, medium=2, low=1).
+
+**Bundler mapping:** Next.js→webpack, Vite→vite, Rsbuild→rsbuild, Webpack→webpack, Angular→webpack, CRA→webpack, Unknown→unknown.
+
+**Backend detection** (require 1+ strong indicator): Rust (`Cargo.toml` with actix-web/axum/poem/rocket), Java (`pom.xml`/`build.gradle` with spring-boot/micronaut), Python (`manage.py` or requirements with fastapi/flask/django), Node.js (`package.json` with express/koa/nestjs), Ruby (`Gemfile` with rails), C# (`.csproj`/`.sln`). Returns `is_backend`, `detected_framework`, `confidence`.
+
+### Step 1.2 – Validate Architecture Choice
+
+After frontend detection, assign `bundler` from the mapping table. Store for Step 6.
+
+| Choice | Action |
+|---|---|
+| 1 (Monorepo) | Detect both in cwd. Both found → `analysis_scope="full-stack-monorepo"`, go to 1.3. Only one → prompt: switch scope, provide other path, or cancel. Neither → error, return to 0.5. |
+| 2 (Separate) | Prompt for frontend path, detect. Prompt for backend path, detect. On failure: (1) configure manually (2) different path (3) cancel. Set `analysis_scope="full-stack"`, go to 1.3. |
+| 3 (Frontend) | Detect in cwd or user path. On failure: (1) manual (2) different path (3) cancel. Set `analysis_scope="frontend-only"`, skip to Step 2. |
+| 4 (Backend) | Prompt for path. Detect. On failure: (1) manual (2) different path (3) cancel. Set `analysis_scope="backend-only"`, go to 1.3. |
+| 5 (Cancel) | Exit immediately. |
+
+### Step 1.3 – Backend Framework Configuration
+
+Runs only when backend is in scope (`full-stack-monorepo`, `full-stack`, or `backend-only`).
+
+1. **Framework confirmation:** If auto-detected with high confidence, confirm with user (yes/no). If not detected or low confidence, prompt manually (examples: actix-web, axum, spring-boot, express, fastapi, django, rails, asp.net; user may include ORM).
+
+2. **API base path:** Prompt with default `/api/v2`. Validate starts with `/`.
+
+3. **Serena MCP availability:**
+
+   > Sentinel contract: `serena_instance = null` (JSON null) means not configured. `perf-config.py get` prints empty string for null. Downstream bash treats empty string, `null`, and missing key as unconfigured.
+
+   a. Discover Serena instances — look for MCP tools matching `mcp__*__check_onboarding_performed`, extract instance names from prefix.
+
+   b. **No instances found:** `serena_instance=null`, `serena_status="not_running"`, proceed to Step 2.
+
+   c. **Instance(s) found:** Call `mcp__<instance>__check_onboarding_performed` for each.
+      - "Onboarding not performed yet" → `serena_status="not_onboarded"`
+      - Success/memory count → `serena_status="onboarded"`
+      - Call fails → try next instance
+
+   d. **If not_onboarded:** Prompt user — (1) Complete onboarding now (~2-3 min, enables semantic N+1/over-fetching/unused-JOIN detection) or (2) Skip, use grep-based analysis.
+      - Choice 1: Call `mcp__<instance>__onboarding`, follow instructions, write memories (project_overview, tech_stack, code_style, suggested_commands, task_completion_checklist, codebase_structure), verify, set `serena_instance=<instance>`, `serena_status="onboarded"`.
+      - Choice 2: `serena_instance=null`, `serena_status="skipped"`.
+
+   e. **If onboarded:** Set `serena_instance=<instance>`, no prompts needed.
+
+4. **Store:** backend repo name, absolute path, framework, serena_instance, serena_status, API base path.
+
+## Step 2 – Validate Repository Paths
+
+For each configured path (frontend, backend): verify directory exists and is readable. Set `{role}_available=true/false` and `{role}_last_validated` to ISO 8601 timestamp (or `"-"` if not configured). **If a configured path fails validation, halt and prompt user to fix.**
+
+## Step 3 – Set Up Target Directories
+
+```bash
+mkdir -p performance/{baselines,analysis,plans,optimization-results,verification}
+```
+
+Verify creation. On failure, inform user and stop.
+
+### Step 3.5 – CONVENTIONS.md Check
+
+Check if `CONVENTIONS.md` exists at the repository root.
+
+**If missing:** Display warning:
+> ⚠️ CONVENTIONS.md not found. The `implement-task` skill requires it for performance optimization tasks.
+>
+> Create CONVENTIONS.md with at minimum:
+> - CI check commands (lint, type-check, build)
+> - Performance test commands
+> - Regression thresholds (or use defaults)
+>
+> You can create it now or before running implement-task.
+
+**If exists:** Log "✓ CONVENTIONS.md found" and proceed.
+
+## Step 4 – Collect Configuration Values
+
+**Baseline Settings (all scopes):** iterations (default: 20, min 20 for statistically valid p95), warmup runs (default: 2).
+
+> Why 20 minimum: p95 with n=10 is statistically identical to maximum. With n=20, p95 is 19th value with meaningful distribution. Recommended 30+ for stable comparisons.
+
+**Optimization Targets by scope:**
+
+| Metric | Default | Scope |
+|---|---|---|
+| LCP | 2.5s | frontend, full-stack |
+| FCP | 1.8s | frontend, full-stack |
+| DOM Interactive | 3.5s | frontend, full-stack |
+| Total Load Time | 4.0s | frontend, full-stack |
+| Response Time p95 | 200ms | backend, full-stack |
+| Response Time p99 | 500ms | backend, full-stack |
+| Throughput | 100 req/s | backend, full-stack |
+| Error Rate | 0.1% | backend, full-stack |
+| DB Query Time p95 | 50ms | backend, full-stack |
+
+Offer: *"Use recommended defaults? (yes/no)"* — if yes, skip individual prompts.
+
+## Step 5 – Initialize Metadata
+
+Prepare metadata values:
+
+| Field | Value |
+|---|---|
+| version | "1.0" |
+| created / last_updated | Current ISO 8601 timestamp |
+| workflow_selected | false |
+| baseline_captured | false |
+| baseline_mode / baseline_timestamp / baseline_commit_sha | null |
+| analysis_scope | From Step 1.2 |
+| backend_available | From Step 2 |
+| backend_endpoint_discovery_method | null |
+| serena_status / serena_instance | From Step 1.3 (null if frontend-only) |
+| metric_type | "frontend" / "backend" / "hybrid" based on scope |
+
+## Step 6 – Generate Configuration File
+
+Run `init --help` first. The `init` subcommand accepts optional `--flag value` pairs (not positional JSON).
+
+```bash
+# <Plugin Root — see top of skill>
+python3 "$plugin_root/scripts/perf-config.py" init \
+  --analysis-scope "$analysis_scope" \
+  --frontend-path "$frontend_path" \
+  --frontend-framework "$frontend_framework" \
+  --frontend-name "$frontend_repo_name" \
+  --bundler "$bundler" \
+  --backend-path "$backend_path" \
+  --backend-framework "$backend_framework" \
+  --backend-name "$backend_repo_name" \
+  --api-base-path "$api_base_path" \
+  --serena-instance "$serena_instance" \
+  --serena-status "$serena_status" \
+  --lcp-target "$lcp_target" \
+  --fcp-target "$fcp_target" \
+  --dom-target "$dom_target" \
+  --total-target "$total_target" \
+  --iterations "$iterations" \
+  --warmup-runs "$warmup_runs" \
+  --resp-p95-target "$resp_p95_target" \
+  --resp-p99-target "$resp_p99_target" \
+  --throughput-target "$throughput_target" \
+  --error-rate-target "$error_rate_target" \
+  --db-query-time-target "$db_query_time_target"
+```
+
+Omit arguments not collected for the scope. Add `--force` for idempotent updates (Step 0). Verify with `perf-config.py validate` (resolve plugin root again before calling).
+
+The generated config sets `workflow_selected: false`, leaves scenarios/modules/workflow empty (populated by baseline skill), sets targets per scope, and creates standard directory paths.
+
+## Step 7 – Validate Configuration
+
+Verify: (1) target directories created, (2) frontend path exists if configured, (3) backend path exists if configured, (4) config file written. On failure, inform user and offer to fix.
+
+## Step 8 – Output Summary
+
+> **Performance Analysis Configuration created!**
+>
+> **Architecture:** {type} | **Config:** `performance-config.json`
+> **Frontend:** {Enabled (framework, bundler) | Disabled} | **Backend:** {Enabled (framework) | Disabled}
+> **Baseline:** {iterations} iterations, {warmup} warmup | **Targets:** LCP {t}s, FCP {t}s, DOM {t}s
+
+**Serena recommendation (if backend enabled):**
+- `serena_status="not_running"`: Recommend installing Serena MCP for semantic N+1/over-fetching/unused-JOIN detection. Current analysis uses grep-based matching (medium confidence). Re-run setup after installing.
+- `serena_status="skipped"`: Note Serena is available. Re-run setup and choose "Complete onboarding" to enable.
+- `serena_status="onboarded"`: No recommendation needed.
+
+> **Single-workflow mode:** Selecting a different workflow in `performance-baseline` replaces current workflow and baseline data. Back up `performance/baselines/` before switching.
+
+> **Next Steps:** Run `/sdlc-workflow:performance-baseline` — it will discover dev commands, discover workflows, prompt for workflow selection, auto-populate scenarios/modules, and capture initial metrics.
+
+## Important Rules
+
+- Never modify source code — only create/update `performance-config.json`
+- Do NOT populate scenarios, modules, or workflow sections — baseline skill handles those
+- Set `metadata.workflow_selected = false` — baseline skill sets true after selection
+- Always prompt for backend config — never silently default to frontend-only
+- When reading target repo's CLAUDE.md, only extract structured data (Repository Registry)
+- Metadata timestamps use ISO 8601 format
+- Step 7 validation checks directories and paths only, not scenarios/modules
diff --git a/plugins/sdlc-workflow/skills/performance/baseline-report.template.md b/plugins/sdlc-workflow/skills/performance/baseline-report.template.md
new file mode 100644
index 000000000..3396b4027
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/baseline-report.template.md
@@ -0,0 +1,157 @@
+---
+generated_by: {skill-name}
+timestamp: {iso-8601-timestamp}
+repository: {repository-name}
+capture_mode: {capture-mode}
+---
+
+# Performance Baseline Report
+
+## Configuration Summary
+
+- **Capture Date:** {capture-date}
+- **Iterations:** {iterations}
+- **Warmup Runs:** {warmup-runs}
+- **Scenarios Measured:** {scenario-count}
+
+## Capture Mode
+
+**Mode:** {capture-mode}
+
+{mode-description}
+
+**Mode descriptions:**
+- **cold-start:** Direct URL navigation with cold cache. Measures worst-case/first-visit performance.
+
+---
+
+## Summary Metrics
+
+**Capture Mode:** {capture-mode}
+
+**Frontend Performance Metrics** (if capture-mode includes "cold-start" or "hybrid"):
+
+Mean of per-scenario values (not a statistically pooled aggregate).
+
+| Metric | Mean | p50 (Median) | p95 | p99 | Unit |
+|---|---|---|---|---|---|
+| **LCP** (Largest Contentful Paint) | {lcp-mean} | {lcp-p50} | {lcp-p95} | {lcp-p99} | ms |
+| **FCP** (First Contentful Paint) | {fcp-mean} | {fcp-p50} | {fcp-p95} | {fcp-p99} | ms |
+| **DOM Interactive** | {domInteractive-mean} | {domInteractive-p50} | {domInteractive-p95} | {domInteractive-p99} | ms |
+| **Total Load Time** | {total-mean} | {total-p50} | {total-p95} | {total-p99} | ms |
+
+**Backend API Performance Metrics** (if capture-mode includes "api-benchmark" or "hybrid"):
+
+Overall API performance across all endpoints.
+
+| Metric | Mean | p50 (Median) | p95 | p99 | Unit |
+|---|---|---|---|---|---|
+| **Response Time** | {response-mean} | {response-p50} | {response-p95} | {response-p99} | ms |
+| **Throughput** | - | - | {throughput-p95} | - | req/sec |
+| **Error Rate** | - | - | {error-rate-p95} | - | % |
+| **Cache Effectiveness** | - | - | {cache-improvement-pct} | - | % improvement |
+
+## API Correlation
+
+**Included when:** capture-mode = "hybrid" AND workflow.traced_api_endpoints is non-empty.
+
+Frontend routes and their traced backend API calls for the selected workflow.
+
+| Frontend Route | Route Load p95 (ms) | Traced APIs | Slowest Traced API | In-Page Fetch Time (ms) | Isolated API p95 (ms) |
+|---|---|---|---|---|---|
+| {route-url} | {route-load-p95} | {api-count} | {slowest-api-path} | {fetch-resource-timing-ms} | {benchmark-p95-ms} |
+
+**Notes:**
+- "In-Page Fetch Time" is from Playwright resource timing (Fetch/XHR entries) — actual duration during page load.
+- "Isolated API p95" is from perf-benchmark.sh — latency without browser overhead.
+- Large gap between in-page and isolated time may indicate parallel API loading or frontend processing overhead.
+- APIs are not necessarily sequential — do not sum API times to explain route load time.
+
+## Per-Scenario Metrics
+
+{per-scenario-sections}
+
+## Resource Timing Breakdown
+
+Top resources by load duration across all scenarios:
+
+| Resource | Type | Duration (ms) | Size (KB) | Scenario |
+|---|---|---|---|---|
+| {resource-1-name} | {resource-1-type} | {resource-1-duration} | {resource-1-size} | {resource-1-scenario} |
+| {resource-2-name} | {resource-2-type} | {resource-2-duration} | {resource-2-size} | {resource-2-scenario} |
+| {resource-3-name} | {resource-3-type} | {resource-3-duration} | {resource-3-size} | {resource-3-scenario} |
+
+## Waterfall Visualization
+
+Resource load timeline for {waterfall-scenario-name}:
+
+```
+{waterfall-ascii-chart}
+```
+
+**Legend:**
+- `[====]` Script
+- `[----]` Stylesheet
+- `[****]` Image
+- `[++++]` Fetch/XHR
+
+## Comparison with Previous Baseline
+
+{comparison-section}
+
+## Known Limitations
+
+**Frontend Baselines** (if capture-mode = "cold-start" or "hybrid"):
+
+This baseline measures **cold-start performance** (initial page load with empty cache). It does **not** capture:
+
+- **Interactive workflow performance:** Multi-step user journeys (e.g., login → search → view details → edit)
+- **Client-side navigation:** Route transitions within single-page applications
+- **Runtime performance:** JavaScript execution time, memory usage, or long tasks
+- **User interaction latency:** Click-to-response time, form submission delays, or scroll performance
+- **Progressive enhancement:** Performance improvements from service workers, prefetching, or caching strategies
+
+**What frontend baselines are useful for:**
+
+✅ First-visit experience (e.g., users arriving from search engines, direct links, or bookmarks)  
+✅ Bundle size analysis (identifying large scripts, stylesheets, or vendor libraries)  
+✅ Resource loading waterfall (detecting sequential loading or render-blocking resources)  
+
+**What frontend baselines don't measure:**
+
+❌ **Interactive workflows:** Use Chrome DevTools Performance panel or Lighthouse User Flows  
+❌ **Runtime performance:** Use Chrome DevTools Performance profiler or Web Vitals library  
+❌ **Repeat-visit performance:** Re-run baseline with warm cache mode (future enhancement)
+
+**Backend Baselines** (if capture-mode = "api-benchmark" or "hybrid"):
+
+This baseline measures **API endpoint performance** under controlled load (curl/bc HTTP benchmarking). It does **not** capture:
+
+- **Database query-level profiling:** Individual query execution times (use database slow query logs or APM tools)
+- **Connection pool saturation:** Maximum concurrent connection limits or pool exhaustion behavior
+- **Memory profiling:** Heap usage, garbage collection pauses, or memory leaks
+- **Actual cache hit rates:** Only measures latency difference between cold and warm, not true cache effectiveness
+- **Concurrent load behavior:** Uses serial requests (c=1) for consistent measurement, not realistic concurrent traffic
+
+**What backend baselines are useful for:**
+
+✅ API response time percentiles (p50, p95, p99) for each endpoint  
+✅ Throughput capacity baseline (requests/second per endpoint)  
+✅ Error rate baseline (4xx/5xx response percentages)  
+✅ Cache effectiveness (cold vs warm latency comparison)
+
+**What backend baselines don't measure:**
+
+❌ **Query-level profiling:** Use database APM tools (Prometheus, DataDog, New Relic, etc.)  
+❌ **Resource profiling:** Use runtime profilers (perf for Rust/C++, pprof for Go, py-spy for Python, etc.)  
+❌ **Realistic load patterns:** Use dedicated load testing tools (k6, Gatling, JMeter) for production-like traffic
+
+**Percentile Method Note:**
+
+Frontend metrics use linear interpolation percentiles (capture-baseline.mjs); backend metrics (perf-benchmark.sh) use nearest-rank. Values are not directly comparable across frontend and backend legs in hybrid baselines.
+
+## Next Steps
+
+1. Review scenarios with LCP > 2.5s or DOM Interactive > 3.5s
+2. Identify heavy resources (> 500KB scripts, > 200KB stylesheets)
+3. Run module-level analysis for your selected workflow: `/sdlc-workflow:performance-analyze-module`
diff --git a/plugins/sdlc-workflow/skills/performance/capture-baseline.template.mjs b/plugins/sdlc-workflow/skills/performance/capture-baseline.template.mjs
new file mode 100644
index 000000000..c834c5291
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/capture-baseline.template.mjs
@@ -0,0 +1,780 @@
+#!/usr/bin/env node
+
+/**
+ * Performance Baseline Capture Script
+ *
+ * Collects frontend performance metrics via Playwright browser automation.
+ *
+ * MODES:
+ *   Localhost: node capture-baseline.mjs --config <path> --port 3000
+ *   Hosted:   node capture-baseline.mjs --config <path> --base-url https://host [auth] [--insecure]
+ *
+ * AUTH OPTIONS (hosted mode only, mutually exclusive):
+ *   --storage-state auth.json   Playwright saved session (primary — works with SSO/Keycloak/OIDC)
+ *   --user admin --pass secret  Form-login (Cognito, Keycloak, and standard HTML forms)
+ *
+ *   Form-login tries visible username/password fields first, then falls back to
+ *   auth-type-specific selectors (Cognito signInForm*, Keycloak #username/#password).
+ *   For multi-step or non-standard flows, use --storage-state instead:
+ *     npx playwright codegen --save-storage=auth.json https://your-host
+ *
+ * VERIFICATION:
+ *   Before measurement, one verification iteration per scenario checks HTTP status,
+ *   final URL (SPA auth redirect detection), navigation timing, FCP, LCP (with element
+ *   attribution), and JS errors. Halts immediately with actionable diagnostics on failure.
+ *
+ * OUTPUT:
+ *   JSON to stdout with per-scenario metrics. All timing values in milliseconds.
+ *   No cross-scenario aggregate — consumers compute summaries from per-scenario data.
+ *   Percentile method: linear interpolation (output config.percentile_method).
+ *
+ * LIMITATIONS:
+ *   LCP is collected via a PerformanceObserver injected before navigation
+ *   (addInitScript). After load, waits for LCP to stabilize (no new candidates
+ *   for 2s, up to 10s) before reading the final entry. LCP may still be null
+ *   on pages without a qualifying largest-contentful-paint element (e.g.,
+ *   canvas-only rendering) or when content appears after the stabilization window.
+ *   No network throttling — uses Playwright defaults (no preset).
+ *   Viewport is fixed at 1280×720 for reproducible baselines.
+ *   FCP/LCP may be null for pages without qualifying paint events.
+ *   Dynamic route segments (:id) must be substituted with real values before config entry.
+ *
+ * SECURITY:
+ *   - Localhost mode: only navigates to 127.0.0.0/8, ::1
+ *   - Hosted mode: navigates to the user-provided --base-url only
+ *   - TLS errors rejected by default; --insecure opts in to accepting invalid certs
+ *   - Absolute config paths always accepted; relative paths enforce CWD containment
+ *   - Iterations bounded (max 50); warmup bounded (max 10)
+ *   - Query strings stripped from resource URLs before output (prevents token leakage)
+ *   - WARNING: --pass is visible in process listings and shell history.
+ *     Use --storage-state or BASELINE_PASS env var for sensitive environments.
+ */
+
+import { chromium } from '@playwright/test';
+import { readFile, realpath, access } from 'fs/promises';
+import { URL } from 'url';
+import { resolve, relative, isAbsolute } from 'path';
+
+// Module-level variables (set in validateAndRun)
+let configPath;
+let portOverride;
+let baseUrl;
+const captureMode = 'cold-start'; // fresh browser context per iteration, same browser process
+let storageStatePath;
+let authUser;
+let authPass;
+let insecureFlag;
+
+const AUTH_PATH_PATTERNS = ['/login', '/auth', '/signin', '/oauth', '/sso'];
+
+// ── Config ──────────────────────────────────────────────────────────────
+
+async function parseConfig(path) {
+  const raw = JSON.parse(await readFile(path, 'utf-8'));
+  const scenarios = (raw.scenarios || [])
+    .filter(s => (s.type || 'frontend') !== 'backend')
+    .map(s => ({
+      name: s.name, path: s.url, description: s.description || ''
+    }));
+  if (!scenarios.length) throw new Error('No frontend scenarios in config. Check scenario types or run /sdlc-workflow:performance-baseline first.');
+  const iterations = Math.min(Math.max(raw.baseline_settings?.iterations ?? 20, 1), 50);
+  const warmupRuns = Math.min(Math.max(raw.baseline_settings?.warmup_runs ?? 2, 0), 10);
+  return { scenarios, iterations, warmupRuns };
+}
+
+// ── URL Resolution ──────────────────────────────────────────────────────
+
+function validateLocalhostUrl(urlPath, defaultPort) {
+  let fullUrl;
+  const pathPattern = /^[a-zA-Z0-9\/_\-.:?&=%]+$/;
+  if (!urlPath.startsWith('http://') && !urlPath.startsWith('https://') && !pathPattern.test(urlPath)) {
+    throw new Error(`Invalid characters in URL path: ${urlPath}`);
+  }
+  if (urlPath.startsWith('http://') || urlPath.startsWith('https://')) {
+    fullUrl = urlPath;
+  } else {
+    if (!defaultPort) throw new Error(`URL "${urlPath}" needs a port. Use --port.`);
+    fullUrl = `http://localhost:${defaultPort}${urlPath.startsWith('/') ? '' : '/'}${urlPath}`;
+  }
+  const parsed = new URL(fullUrl);
+  const hostname = parsed.hostname.toLowerCase();
+  const isLocalhost = hostname === 'localhost';
+  const isIPv4Loopback = /^127\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/.test(hostname) &&
+    hostname.split('.').slice(1).every(o => { const n = parseInt(o, 10); return n >= 0 && n <= 255; });
+  const isIPv6Loopback = hostname === '[::1]' || hostname === '::1';
+  if (hostname === '0.0.0.0') throw new Error('0.0.0.0 not allowed. Use localhost or 127.0.0.1.');
+  if (hostname.includes('::ffff:')) throw new Error('IPv6-mapped addresses not allowed.');
+  if (!isLocalhost && !isIPv4Loopback && !isIPv6Loopback) {
+    throw new Error(`Only localhost URLs allowed. Got: ${hostname}`);
+  }
+  if (!parsed.port) throw new Error(`Port required in URL: ${fullUrl}. Use --port.`);
+  return fullUrl;
+}
+
+function resolveUrl(scenarioPath) {
+  if (scenarioPath.startsWith('http://') || scenarioPath.startsWith('https://')) return scenarioPath;
+  if (baseUrl) {
+    const base = baseUrl.replace(/\/+$/, '');
+    return `${base}${scenarioPath.startsWith('/') ? '' : '/'}${scenarioPath}`;
+  }
+  return validateLocalhostUrl(scenarioPath, portOverride);
+}
+
+function stripQueryString(url) {
+  try { const u = new URL(url); return `${u.origin}${u.pathname}`; } catch { return url; }
+}
+
+function isAuthRedirect(url) {
+  try {
+    const path = new URL(url).pathname.toLowerCase();
+    return AUTH_PATH_PATTERNS.some(p => path.includes(p));
+  } catch { return false; }
+}
+
+// ── Auth ─────────────────────────────────────────────────────────────────
+
+async function attemptFormLogin(page) {
+  await page.goto(baseUrl, { waitUntil: 'networkidle', timeout: 30000 });
+
+  if (!isAuthRedirect(page.url())) {
+    await page.waitForURL(url => isAuthRedirect(url.toString()), { timeout: 5000 }).catch(() => {});
+  }
+
+  // Primary: visible username/password fields + Enter — covers most standard forms
+  let primaryFilled = false;
+  try {
+    await page.fill('input[name="username"]:visible', authUser);
+    await page.fill('input[name="password"]:visible', authPass);
+    primaryFilled = true;
+    await page.keyboard.press('Enter');
+    // Wait for the full redirect chain (e.g. Cognito → callback → app) to settle
+    await page.waitForURL(
+      url => url.toString().startsWith(baseUrl) && !isAuthRedirect(url.toString()),
+      { timeout: 30000 }
+    ).catch(() => {});
+    await page.waitForLoadState('networkidle', { timeout: 10000 }).catch(() => {});
+
+    if (!isAuthRedirect(page.url())) {
+      return { success: true };
+    }
+    // Enter didn't submit or redirect chain didn't complete — fall through
+  } catch {
+    // Primary selectors failed — fall through to auth-type-specific selectors
+  }
+
+  // Fallback: detect auth type from URL and use specific selectors + submit button
+  const currentUrl = page.url().toLowerCase();
+
+  if (currentUrl.includes('cognito')) {
+    if (!primaryFilled) {
+      const userField = await page.$('input[name="signInFormUsername"]:visible');
+      const passField = await page.$('input[name="signInFormPassword"]:visible, input[type="password"]:visible');
+      if (!userField || !passField) return { success: false, reason: 'no-form' };
+      await userField.fill(authUser);
+      await passField.fill(authPass);
+    }
+    const submitBtn = await page.$('input[name="signInSubmitButton"]:visible, button[type="submit"]:visible');
+    if (submitBtn) {
+      await submitBtn.click();
+    } else {
+      return { success: false, reason: 'no-form' };
+    }
+  } else if (currentUrl.includes('keycloak') || currentUrl.includes('/auth/realms')) {
+    if (!primaryFilled) {
+      const userField = await page.$('input[id="username"]:visible');
+      const passField = await page.$('input[id="password"]:visible');
+      if (!userField || !passField) return { success: false, reason: 'no-form' };
+      await userField.fill(authUser);
+      await passField.fill(authPass);
+    }
+    const submitBtn = await page.$('input[id="kc-login"]:visible, button[type="submit"]:visible');
+    if (submitBtn) {
+      await submitBtn.click();
+    } else {
+      return { success: false, reason: 'no-form' };
+    }
+  } else {
+    if (!primaryFilled) {
+      const userField = await page.$('input[id="username"], input[name="user"]');
+      const passField = await page.$('input[id="password"], input[type="password"]');
+      if (!userField || !passField) return { success: false, reason: 'no-form' };
+      await userField.fill(authUser);
+      await passField.fill(authPass);
+    }
+    const submitBtn = await page.$('button[type="submit"], input[type="submit"]');
+    if (submitBtn) {
+      await submitBtn.click();
+    } else {
+      return { success: false, reason: 'no-form' };
+    }
+  }
+
+  await page.waitForLoadState('networkidle', { timeout: 30000 });
+
+  if (isAuthRedirect(page.url())) {
+    return { success: false, reason: 'login-failed' };
+  }
+  return { success: true };
+}
+
+async function setupAuth(browser, firstScenarioUrl) {
+  if (!baseUrl) return null;
+
+  if (storageStatePath) {
+    const stored = JSON.parse(await readFile(storageStatePath, 'utf-8'));
+    const context = await browser.newContext(contextOptions(stored));
+    const page = await context.newPage();
+    await page.goto(firstScenarioUrl, { waitUntil: 'load', timeout: 30000 });
+    if (isAuthRedirect(page.url())) {
+      await context.close();
+      console.error(`\n✗ Session expired in ${storageStatePath}`);
+      console.error(`  Re-run: npx playwright codegen --save-storage=${storageStatePath} ${baseUrl}`);
+      process.exit(1);
+    }
+    console.error('  ✓ Storage state loaded and validated');
+    const state = await context.storageState();
+    await context.close();
+    return state;
+  }
+
+  if (authUser && authPass) {
+    const context = await browser.newContext(contextOptions(null));
+    const page = await context.newPage();
+    const result = await attemptFormLogin(page);
+    if (!result.success) {
+      await context.close();
+      if (result.reason === 'no-form') {
+        console.error('\n✗ No login form found at ' + baseUrl);
+        console.error('  For SSO/Keycloak/OIDC, use --storage-state instead of --user/--pass');
+        console.error('  Generate with: npx playwright codegen --save-storage=auth.json ' + baseUrl);
+      } else {
+        console.error('\n✗ Login failed — still on login page after submit');
+        console.error('  Check credentials or use --storage-state for complex login flows');
+      }
+      process.exit(1);
+    }
+    console.error('  ✓ Form login succeeded');
+    const state = await context.storageState();
+    await context.close();
+    return state;
+  }
+
+  // No auth args — check if public
+  const context = await browser.newContext(contextOptions(null));
+  const page = await context.newPage();
+  await page.goto(firstScenarioUrl, { waitUntil: 'load', timeout: 30000 });
+  if (isAuthRedirect(page.url())) {
+    await context.close();
+    console.error('\n✗ Redirected to login page: ' + page.url());
+    console.error('  Provide --storage-state or --user/--pass for authenticated environments');
+    console.error('  Generate storage state: npx playwright codegen --save-storage=auth.json ' + baseUrl);
+    process.exit(1);
+  }
+  console.error('  ✓ No auth required (public)');
+  const state = await context.storageState();
+  await context.close();
+  return state;
+}
+
+// ── LCP Observer ────────────────────────────────────────────────────────
+
+const CAPTURE_VIEWPORT = { width: 1280, height: 720 };
+const LCP_SETTLE_MS = 2000;
+const LCP_MAX_WAIT_MS = 10000;
+
+const LCP_INIT_SCRIPT = `
+  window.__lcpEntries = [];
+  window.__lcpElements = [];
+  new PerformanceObserver((list) => {
+    for (const entry of list.getEntries()) {
+      window.__lcpEntries.push(entry.startTime);
+      const el = entry.element;
+      window.__lcpElements.push({
+        tag: el?.tagName || null,
+        url: entry.url || null,
+        size: entry.size ?? null
+      });
+    }
+  }).observe({ type: 'largest-contentful-paint', buffered: true });
+`;
+
+function contextOptions(storageState) {
+  return {
+    viewport: CAPTURE_VIEWPORT,
+    ...(insecureFlag ? { ignoreHTTPSErrors: true } : {}),
+    ...(storageState ? { storageState } : {})
+  };
+}
+
+async function waitForLcpStable(page) {
+  await page.evaluate(async ({ settleMs, maxWaitMs }) => {
+    const start = performance.now();
+    let lastLen = window.__lcpEntries?.length ?? 0;
+    let lastChange = performance.now();
+    while (performance.now() - start < maxWaitMs) {
+      const len = window.__lcpEntries?.length ?? 0;
+      if (len !== lastLen) {
+        lastLen = len;
+        lastChange = performance.now();
+      }
+      if (len > 0 && performance.now() - lastChange >= settleMs) break;
+      await new Promise(r => setTimeout(r, 100));
+    }
+  }, { settleMs: LCP_SETTLE_MS, maxWaitMs: LCP_MAX_WAIT_MS });
+}
+
+// ── Metrics Collection ──────────────────────────────────────────────────
+
+async function collectMetrics(page) {
+  return page.evaluate(() => {
+    const nav = performance.getEntriesByType('navigation')[0];
+    const paints = performance.getEntriesByType('paint');
+    const lcpEntries = window.__lcpEntries || [];
+    const lcpElements = window.__lcpElements || [];
+    const lcp = lcpEntries.length ? lcpEntries[lcpEntries.length - 1] : null;
+    const lcpElement = lcpEntries.length ? lcpElements[lcpEntries.length - 1] : null;
+    const resources = performance.getEntriesByType('resource');
+    return {
+      navigationTiming: nav ? {
+        dns: nav.domainLookupEnd - nav.domainLookupStart,
+        tcp: nav.connectEnd - nav.connectStart,
+        request: nav.responseStart - nav.requestStart,
+        response: nav.responseEnd - nav.responseStart,
+        domProcessing: nav.domComplete - nav.domInteractive,
+        loadComplete: nav.loadEventEnd - nav.loadEventStart,
+        totalTime: nav.loadEventEnd - nav.fetchStart
+      } : null,
+      fcp: paints.find(e => e.name === 'first-contentful-paint')?.startTime || null,
+      lcp,
+      lcpElement,
+      domInteractive: nav ? nav.domInteractive : null,
+      resources: resources.map(r => ({
+        name: r.name, type: r.initiatorType,
+        duration: r.duration, size: r.transferSize || 0, startTime: r.startTime
+      })),
+      resourceSummary: {
+        scripts: resources.filter(r => r.initiatorType === 'script').length,
+        stylesheets: resources.filter(r => r.initiatorType === 'link' || r.initiatorType === 'css').length,
+        images: resources.filter(r => r.initiatorType === 'img').length,
+        fetch: resources.filter(r => r.initiatorType === 'fetch' || r.initiatorType === 'xmlhttprequest').length,
+        total: resources.length
+      }
+    };
+  });
+}
+
+// ── Navigation Stabilization ────────────────────────────────────────────
+
+async function waitForNavigationSettle(page, timeoutMs = 8000) {
+  const start = Date.now();
+  while (Date.now() - start < timeoutMs) {
+    try {
+      await page.waitForURL(/.*/, { timeout: 3000, waitUntil: 'load' });
+    } catch {
+      break;
+    }
+  }
+  await page.waitForLoadState('load').catch(() => {});
+}
+
+// ── Verification Pass ───────────────────────────────────────────────────
+
+async function runVerificationPass(browser, scenarios, storageState) {
+  console.error('\n── Verification pass ──');
+  for (const scenario of scenarios) {
+    const url = resolveUrl(scenario.path);
+    const context = await browser.newContext(contextOptions(storageState));
+    const page = await context.newPage();
+    await page.addInitScript(LCP_INIT_SCRIPT);
+    const jsErrors = [];
+    page.on('pageerror', e => jsErrors.push(e.message));
+
+    try {
+      const response = await page.goto(url, { waitUntil: 'load', timeout: 30000 });
+      await waitForNavigationSettle(page);
+      await waitForLcpStable(page);
+      const status = response?.status() ?? 0;
+      const finalUrl = page.url();
+      const errors = [];
+
+      if (status >= 400) errors.push(`HTTP ${status}`);
+      if (isAuthRedirect(finalUrl)) errors.push(`Redirected to auth page: ${finalUrl}`);
+
+      const metrics = await collectMetrics(page);
+      if (!metrics.navigationTiming) errors.push('No navigation timing data');
+      if (jsErrors.length) errors.push(`${jsErrors.length} JS error(s): ${jsErrors[0]}`);
+      if (!metrics.lcp) console.error(`  ⚠ ${scenario.name}: LCP not available (no candidates during ${LCP_MAX_WAIT_MS/1000}s window)`);
+
+      if (errors.length) {
+        console.error(`\n✗ Verification FAILED: ${scenario.name}`);
+        errors.forEach(e => console.error(`  - ${e}`));
+        if (isAuthRedirect(finalUrl)) {
+          console.error('  → Provide --storage-state or --user/--pass');
+        }
+        process.exit(1);
+      }
+
+      const resourceCount = metrics.resources?.length ?? 0;
+      const lcpStr = metrics.lcp ? Math.round(metrics.lcp) + 'ms' : 'n/a';
+      const lcpUrl = metrics.lcpElement?.url ? stripQueryString(metrics.lcpElement.url) : null;
+      const lcpEl = metrics.lcpElement?.tag
+        ? ` (${metrics.lcpElement.tag}${lcpUrl ? ', ' + lcpUrl : ''})`
+        : '';
+      console.error(`  ✓ ${scenario.name}: HTTP ${status}, FCP ${metrics.fcp ? Math.round(metrics.fcp) + 'ms' : 'n/a'}, LCP ${lcpStr}${lcpEl}, ${resourceCount} resources`);
+    } catch (err) {
+      console.error(`\n✗ Verification FAILED: ${scenario.name}`);
+      console.error(`  ${err.message}`);
+      if (baseUrl) {
+        console.error('  → Check network connectivity and VPN');
+        if (!insecureFlag) console.error('  → For self-signed certs, add --insecure');
+      } else {
+        console.error(`  → Is the app running on localhost:${portOverride}?`);
+      }
+      process.exit(1);
+    } finally {
+      await context.close();
+    }
+  }
+  console.error('── All scenarios verified ✓ ──\n');
+}
+
+// ── Measurement ─────────────────────────────────────────────────────────
+
+async function measureScenario(browser, scenario, iterations, warmupRuns, storageState) {
+  const url = resolveUrl(scenario.path);
+  const allMetrics = [];
+  let failCount = 0;
+  const maxFailures = Math.ceil((iterations + warmupRuns) * 0.2);
+
+  for (let i = 0; i < iterations + warmupRuns; i++) {
+    const context = await browser.newContext(contextOptions(storageState));
+    const page = await context.newPage();
+    await page.addInitScript(LCP_INIT_SCRIPT);
+    const jsErrors = [];
+    page.on('pageerror', e => jsErrors.push(e.message));
+
+    try {
+      await page.goto(url, { waitUntil: 'load', timeout: 30000 });
+      await waitForNavigationSettle(page);
+      await waitForLcpStable(page);
+      const metrics = await collectMetrics(page);
+      if (metrics.resources) {
+        metrics.resources = metrics.resources.map(r => ({ ...r, name: stripQueryString(r.name) }));
+      }
+      if (i >= warmupRuns) allMetrics.push(metrics);
+      if (i === warmupRuns - 1 && warmupRuns > 0) console.error('    Warmup done');
+      if (jsErrors.length && i >= warmupRuns) {
+        console.error(`    Iteration ${i - warmupRuns + 1}: ${jsErrors.length} JS error(s)`);
+      }
+      if (i >= warmupRuns && (i - warmupRuns + 1) % 5 === 0) {
+        console.error(`    ${i - warmupRuns + 1}/${iterations}`);
+      }
+    } catch (error) {
+      failCount++;
+      console.error(`    Iteration ${i + 1} failed: ${error.message}`);
+      if (failCount > maxFailures) {
+        await context.close();
+        throw new Error(`Too many failures (${failCount}/${iterations + warmupRuns}). Halting "${scenario.name}".`);
+      }
+    } finally {
+      await context.close();
+    }
+  }
+
+  const aggregated = aggregateMetrics(allMetrics);
+  if (aggregated && aggregated.lcpSamples < aggregated.iterations) {
+    console.error(`    ⚠ LCP available in ${aggregated.lcpSamples}/${aggregated.iterations} iterations`);
+  }
+  return aggregated;
+}
+
+// ── Statistics ───────────────────────────────────────────────────────────
+
+function percentile(sorted, p) {
+  if (!sorted.length) return null;
+  const idx = (sorted.length - 1) * p;
+  const lo = Math.floor(idx), hi = Math.ceil(idx);
+  if (lo === hi) return sorted[lo];
+  return Math.round((sorted[lo] + (sorted[hi] - sorted[lo]) * (idx - lo)) * 100) / 100;
+}
+
+function calculateStats(values) {
+  if (!values.length) return null;
+  const sorted = values.slice().sort((a, b) => a - b);
+  const sum = values.reduce((a, b) => a + b, 0);
+  return {
+    mean: Math.round(sum / values.length * 100) / 100,
+    p50: percentile(sorted, 0.5),
+    p95: percentile(sorted, 0.95),
+    p99: percentile(sorted, 0.99)
+  };
+}
+
+function aggregateMetrics(arr) {
+  if (!arr.length) return null;
+  const lcpValues = arr.map(m => m.lcp).filter(v => v !== null);
+  return {
+    iterations: arr.length,
+    lcpSamples: lcpValues.length,
+    fcp: calculateStats(arr.map(m => m.fcp).filter(v => v !== null)),
+    lcp: calculateStats(lcpValues),
+    domInteractive: calculateStats(arr.map(m => m.domInteractive).filter(v => v !== null)),
+    totalTime: calculateStats(arr.map(m => m.navigationTiming?.totalTime).filter(v => v != null)),
+    resources: categorizeResources(arr)
+  };
+}
+
+function categorizeResources(metricsArray) {
+  const all = metricsArray.flatMap(m => m.resources || []);
+  const byType = (type) => all.filter(r =>
+    type === 'stylesheets' ? (r.type === 'link' || r.type === 'css') :
+    type === 'fetch' ? (r.type === 'fetch' || r.type === 'xmlhttprequest') :
+    r.type === type
+  );
+  const avgResources = (resources) => {
+    const grouped = {};
+    resources.forEach(r => {
+      if (!grouped[r.name]) grouped[r.name] = { durations: [], sizes: [], startTimes: [] };
+      grouped[r.name].durations.push(r.duration);
+      grouped[r.name].sizes.push(r.size);
+      grouped[r.name].startTimes.push(r.startTime);
+    });
+    return Object.entries(grouped).map(([name, d]) => ({
+      name,
+      duration: Math.round(d.durations.reduce((a, b) => a + b, 0) / d.durations.length),
+      size: Math.round(d.sizes.reduce((a, b) => a + b, 0) / d.sizes.length),
+      startTime: Math.round(d.startTimes.reduce((a, b) => a + b, 0) / d.startTimes.length)
+    }));
+  };
+  const n = metricsArray.length;
+  const make = (items) => ({ count: Math.round(items.length / n), items: avgResources(items) });
+  return {
+    scripts: make(byType('script')),
+    stylesheets: make(byType('stylesheets')),
+    images: make(byType('img')),
+    fetch: make(byType('fetch'))
+  };
+}
+
+// ── Main ─────────────────────────────────────────────────────────────────
+
+async function main() {
+  let browser;
+  try {
+    const config = await parseConfig(configPath);
+
+    console.error('Launching Chromium (headless)...');
+    browser = await chromium.launch({ headless: true });
+
+    // Auth setup (once for the entire run)
+    const firstUrl = resolveUrl(config.scenarios[0].path);
+    console.error('Setting up authentication...');
+    const storageState = await setupAuth(browser, firstUrl);
+
+    // Verification pass
+    await runVerificationPass(browser, config.scenarios, storageState);
+
+    // Pre-compute sanitized names
+    const safeNames = new Map();
+    for (const scenario of config.scenarios) {
+      const safeName = String(scenario.name).replace(/[^a-zA-Z0-9_\- ]/g, '_');
+      if (safeName !== scenario.name) console.error(`  Name sanitized: "${scenario.name}" → "${safeName}"`);
+      safeNames.set(scenario.name, safeName);
+    }
+
+    // Measurement loop
+    const results = Object.create(null);
+    for (const scenario of config.scenarios) {
+      const safeName = safeNames.get(scenario.name);
+      console.error(`  Measuring: ${safeName} (${config.warmupRuns} warmup + ${config.iterations} measured)`);
+      results[safeName] = await measureScenario(browser, scenario, config.iterations, config.warmupRuns, storageState);
+    }
+
+    const scenarios = config.scenarios.map(s => {
+      const safeName = safeNames.get(s.name);
+      const r = results[safeName];
+      return r ? {
+        name: safeName, url: stripQueryString(resolveUrl(s.path)),
+        metrics: {
+          lcp: r.lcp, lcpSamples: r.lcpSamples, fcp: r.fcp,
+          domInteractive: r.domInteractive, totalLoadTime: r.totalTime
+        },
+        resources: r.resources
+      } : null;
+    }).filter(Boolean);
+
+    console.log(JSON.stringify({
+      timestamp: new Date().toISOString(),
+      mode: captureMode,
+      unit: 'ms',
+      config: {
+        iterations: config.iterations,
+        warmupRuns: config.warmupRuns,
+        port: portOverride,
+        baseUrl: baseUrl || null,
+        captureTarget: baseUrl ? 'hosted' : 'localhost',
+        viewport: CAPTURE_VIEWPORT,
+        lcp_settle_ms: LCP_SETTLE_MS,
+        lcp_max_wait_ms: LCP_MAX_WAIT_MS,
+        headless: true,
+        percentile_method: 'linear'
+      },
+      scenarios
+    }, null, 2));
+
+  } catch (error) {
+    console.error(`\nFatal: ${error.message}`);
+    console.error('\nChecklist:');
+    if (baseUrl) {
+      console.error(`  1. Is ${baseUrl} reachable?`);
+      console.error('  2. Are credentials / storage-state valid?');
+      if (!insecureFlag) console.error('  3. For self-signed certs, add --insecure');
+    } else {
+      console.error(`  1. Is the app running on localhost:${portOverride}?`);
+      console.error('  2. Is @playwright/test installed?');
+      console.error('  3. Are Playwright browsers installed? (npx playwright install chromium)');
+    }
+    process.exit(1);
+  } finally {
+    if (browser) await browser.close();
+  }
+}
+
+// ── Arg Parsing ──────────────────────────────────────────────────────────
+
+function getArg(args, flag) {
+  const i = args.indexOf(flag);
+  return i !== -1 && args[i + 1] ? args[i + 1] : null;
+}
+
+function hasFlag(args, flag) {
+  return args.includes(flag);
+}
+
+async function validateAndRun() {
+  const args = process.argv.slice(2);
+
+  // Config path
+  const configRaw = getArg(args, '--config');
+  if (!configRaw) {
+    console.error('Usage:');
+    console.error('  Localhost: node capture-baseline.mjs --config <path> --port <port>');
+    console.error('  Hosted:   node capture-baseline.mjs --config <path> --base-url <url> [--storage-state <path>] [--user <u> --pass <p>] [--insecure]');
+    process.exit(1);
+  }
+
+  const configPathResolved = resolve(configRaw);
+
+  if (isAbsolute(configRaw)) {
+    try { configPath = await realpath(configPathResolved); }
+    catch (e) { if (e.code !== 'ENOENT') { console.error(`Config path error: ${e.message}`); process.exit(1); } configPath = configPathResolved; }
+  } else {
+    const relPath = relative(process.cwd(), configPathResolved);
+    if (relPath.startsWith('..') || isAbsolute(relPath)) {
+      console.error('Config path must be within CWD for relative paths. Use an absolute path instead.');
+      process.exit(1);
+    }
+    try {
+      const real = await realpath(configPathResolved);
+      const realRel = relative(process.cwd(), real);
+      if (realRel.startsWith('..') || isAbsolute(realRel)) {
+        console.error('Config symlink points outside CWD. Use an absolute path instead.');
+        process.exit(1);
+      }
+      configPath = real;
+    } catch (e) {
+      if (e.code !== 'ENOENT') { console.error(`Config path error: ${e.message}`); process.exit(1); }
+      configPath = configPathResolved;
+    }
+  }
+
+  // Port
+  const portRaw = getArg(args, '--port');
+  portOverride = portRaw ? parseInt(portRaw, 10) : null;
+  if (portRaw && (isNaN(portOverride) || portOverride < 1 || portOverride > 65535)) {
+    console.error(`Invalid port: ${portRaw}`); process.exit(1);
+  }
+
+  // Base URL
+  baseUrl = getArg(args, '--base-url');
+  if (baseUrl) {
+    try {
+      const parsed = new URL(baseUrl);
+      if (parsed.protocol !== 'https:' && parsed.protocol !== 'http:') {
+        console.error(`Invalid protocol: ${parsed.protocol}. Use http: or https:.`); process.exit(1);
+      }
+      baseUrl = baseUrl.replace(/\/+$/, '');
+    } catch (e) {
+      console.error(`Invalid --base-url: ${e.message}`); process.exit(1);
+    }
+    if (portOverride) {
+      console.error('Warning: --port ignored when --base-url is provided.');
+      portOverride = null;
+    }
+  }
+
+  // Insecure
+  insecureFlag = hasFlag(args, '--insecure');
+  if (insecureFlag && !baseUrl) {
+    console.error('--insecure requires --base-url.'); process.exit(1);
+  }
+  if (insecureFlag) {
+    console.error('Warning: --insecure bypasses TLS certificate validation. Use only for self-signed certs in dev/test.\n');
+  }
+
+  // Storage state
+  storageStatePath = getArg(args, '--storage-state');
+  if (storageStatePath) {
+    if (!baseUrl) { console.error('--storage-state requires --base-url.'); process.exit(1); }
+    const storageResolved = resolve(storageStatePath);
+    if (!isAbsolute(storageStatePath)) {
+      const storageRel = relative(process.cwd(), storageResolved);
+      if (storageRel.startsWith('..') || isAbsolute(storageRel)) {
+        console.error('--storage-state path must be within CWD for relative paths. Use an absolute path instead.');
+        process.exit(1);
+      }
+    }
+    // Resolve symlinks and re-check containment (matches --config behavior)
+    if (!isAbsolute(storageStatePath)) {
+      try {
+        const real = await realpath(storageResolved);
+        const realRel = relative(process.cwd(), real);
+        if (realRel.startsWith('..') || isAbsolute(realRel)) {
+          console.error('--storage-state symlink points outside CWD. Use an absolute path instead.');
+          process.exit(1);
+        }
+        storageStatePath = real;
+      } catch (e) {
+        if (e.code !== 'ENOENT') { console.error(`--storage-state path error: ${e.message}`); process.exit(1); }
+        storageStatePath = storageResolved;
+      }
+    } else {
+      storageStatePath = storageResolved;
+    }
+    try {
+      await access(storageStatePath);
+      JSON.parse(await readFile(storageStatePath, 'utf-8'));
+    } catch (e) {
+      console.error(`Invalid --storage-state: ${e.message}`);
+      console.error(`Generate with: npx playwright codegen --save-storage=${storageStatePath} ${baseUrl}`);
+      process.exit(1);
+    }
+  }
+
+  // User/pass
+  authUser = getArg(args, '--user');
+  authPass = getArg(args, '--pass') || process.env.BASELINE_PASS || null;
+  if (authUser && !baseUrl) { console.error('--user requires --base-url.'); process.exit(1); }
+  if (authPass && !authUser) { console.error('--pass requires --user.'); process.exit(1); }
+  if (storageStatePath && (authUser || authPass)) {
+    console.error('--storage-state and --user/--pass are mutually exclusive.'); process.exit(1);
+  }
+  if (getArg(args, '--pass')) {
+    console.error('Warning: --pass is visible in process listings and shell history.');
+    console.error('  Prefer --storage-state or BASELINE_PASS env var.\n');
+  }
+
+  await main();
+}
+
+validateAndRun();
diff --git a/plugins/sdlc-workflow/skills/performance/finding-validation.md b/plugins/sdlc-workflow/skills/performance/finding-validation.md
new file mode 100644
index 000000000..f8bfa16b7
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/finding-validation.md
@@ -0,0 +1,151 @@
+# Finding Validation Reference
+
+Used by: performance-analyze-module (write + validate), performance-plan-optimization (read + validate).
+
+## Validation Artifact Schema
+
+Path: `{analysis_dir}/findings-validation.json`
+
+```json
+{
+  "schema_version": "1.1",
+  "generated_at": "ISO-8601",
+  "workflow": "workflow-name",
+  "validation_run": true,
+  "statistics": {
+    "submitted": 12, "confirmed": 5, "confirmed_low_confidence": 2,
+    "downgraded": 1, "discarded": 4
+  },
+  "findings": [{
+    "id": "F1",
+    "anti_pattern": "N+1 Queries",
+    "step": "7.3",
+    "file": "src/handlers/packages.rs",
+    "line": 142,
+    "detection_method": "Serena",
+    "evidence_excerpt": "for pkg in ids { db.query(...).await }",
+    "checks": { "9.1-B": "PASS", "9.1-B2": "PASS" },
+    "disposition": "Confirmed",
+    "confidence": "High",
+    "severity": "High",
+    "timeline": "1-3 days",
+    "reason": "Loop-bound query verified; no batch alternative"
+  },
+  {
+    "id": "F13",
+    "anti_pattern": "Sequential Scan",
+    "step": "9.7.4",
+    "file": "src/handlers/sbom.rs",
+    "line": 142,
+    "detection_method": "EXPLAIN ANALYZE",
+    "evidence_excerpt": "Seq Scan on sbom_packages (actual rows=45000)",
+    "checks": { "9.1-B": "PASS", "9.1-B2": "PASS" },
+    "disposition": "Confirmed",
+    "confidence": "High",
+    "severity": "High",
+    "timeline": "1-4 hours",
+    "reason": "Live EXPLAIN ANALYZE confirms sequential scan on 45K rows",
+    "explain_data": {
+      "execution_time_ms": 234.5,
+      "planning_time_ms": 1.2,
+      "bottleneck_type": "seq_scan",
+      "table": "sbom_packages",
+      "estimated_rows": 1000,
+      "actual_rows": 45000,
+      "row_mismatch_ratio": 45.0
+    }
+  }]
+}
+```
+
+**Schema Version:** `"1.1"`. Readers must accept both `"1.0"` (no `explain_data`) and `"1.1"`.
+
+## Field Rules
+
+| Field | Rule |
+|---|---|
+| `schema_version` | `"1.0"` or `"1.1"` |
+| `validation_run` | Must be `true`. Do not write file if Step 9.1 was not executed |
+| `findings[].id` | Unique F1, F2, ... matching Step 9.1-A inventory. Live SQL findings use the same F-sequence (no separate namespace) |
+| `findings[].checks` | Both `9.1-B` and `9.1-B2` required for every row. For EXPLAIN-backed findings (step 9.7.4), 9.1-B confirms the query exists at the recorded source location; 9.1-B2 verifies the recommended fix is valid for the framework |
+| `findings[].disposition` | Confirmed, Confirmed (Low Confidence), Downgraded, or Discarded |
+| `findings[].detection_method` | `"Serena"`, `"Grep"`, `"EXPLAIN ANALYZE"`, or `"EXPLAIN"` |
+| `findings[].reason` | Required for all dispositions |
+| `findings[].explain_data` | Optional. Required when `step` is `"9.7.4"`. Must be absent for non-EXPLAIN findings. Contains: `execution_time_ms`, `planning_time_ms`, `bottleneck_type`, `table`, `estimated_rows`, `actual_rows`, `row_mismatch_ratio` |
+
+## Registered Anti-Pattern Types
+
+The `anti_pattern` field must use one of the following values:
+
+| Anti-Pattern Type | Detection Step | Scope |
+|---|---|---|
+| Over-Fetching | 6.1, 8.A | Frontend / Cross-Layer |
+| N+1 Queries (Frontend) | 6.2 | Frontend |
+| N+1 Queries (Backend) | 7.3 | Backend |
+| Pre-Fetchable Concurrent Queries | 7.3.1 | Backend |
+| Unbounded Query-Driving Iteration | 7.3.2 | Backend |
+| Waterfall Loading | 6.3 | Frontend |
+| Render-Blocking Resources | 6.4 | Frontend |
+| Unused Code | 6.5 | Frontend |
+| Expensive Re-Renders | 6.6 | Frontend |
+| Long Tasks | 6.7 | Frontend |
+| Layout Thrashing | 6.8 | Frontend |
+| Missing Lazy Loading | 6.9 | Frontend |
+| Missing Pagination | 7.4 | Backend |
+| Late Pagination | 7.4.1 | Backend |
+| Missing Caching | 7.5 | Backend |
+| Inefficient Queries | 7.6 | Backend |
+| Unused Table Joins | 7.6.1 | Backend |
+| Missing Database Indexes | 7.6.4 | Backend |
+| Redundant Database Indexes | 7.6.4.1 | Backend |
+| SQL Duplication | 7.6.5 | Backend |
+| Cross-Table OR Filter | 7.6.7 | Backend |
+| Load-All-Then-Search | 7.6.8 | Backend |
+| Recursive CTE Risk | 7.6.2 | Backend |
+| Missing Statistics Refresh | 7.8.1 | Backend (Migration) |
+| Non-Materialized CTE Re-evaluation | 7.8.2 | Backend (Migration) |
+| Uniform Processing of Partitionable Data | 7.8.3 | Backend (Migration) |
+| Expensive PL/pgSQL Function Pattern | 7.8.4 | Backend (Migration) |
+| Sequential Scan | 9.7.4 | Backend (EXPLAIN) |
+| Row Estimate Mismatch | 9.7.4 | Backend (EXPLAIN) |
+| Nested Loop on Large Table | 9.7.4 | Backend (EXPLAIN) |
+| Cross-Layer Computation Waste | 8.F | Cross-Layer |
+| Wasted Computation | 7.6.3 | Backend |
+
+## Disposition ↔ Checks Consistency
+
+| Disposition | Required outcomes |
+|---|---|
+| Confirmed / Downgraded | `9.1-B: PASS` and `9.1-B2: PASS` |
+| Confirmed (Low Confidence) | Both PASS + `confidence` = Low |
+| Discarded | At least one starts with `FAILED:` |
+
+## Validation Checklist
+
+Read `findings-validation.json`. All rules must PASS before writing report or creating optimization plan.
+
+### Artifact Rules (A1–A7)
+
+| Rule | Check | FAIL when |
+|---|---|---|
+| A1 | Artifact exists and parses as JSON | Missing, invalid, or schema_version not in `["1.0", "1.1"]` |
+| A2 | `validation_run` is `true` | false or absent |
+| A3 | Every row complete | Missing id, disposition, checks, or reason |
+| A4 | Dispositions valid | Not in allowed enum |
+| A5 | Disposition ↔ checks consistent | Violates consistency table above |
+| A6 | Statistics consistent | submitted ≠ len(findings) or counts don't sum |
+| A7 | EXPLAIN findings have `explain_data` | `step` is `"9.7.4"` but `explain_data` is missing, OR `explain_data` present but `detection_method` not in `["EXPLAIN ANALYZE", "EXPLAIN"]` |
+
+### Report Crosswalk Rules (R1–R5)
+
+Extract Finding IDs from scannable report regions (Anti-Pattern Analysis through Live SQL Analysis, excluding code fences, Finding Validation Summary, and Executive Summary). The scannable region includes: Anti-Pattern Analysis, Backend Source Code Analysis, Cross-Repository Over-Fetching Analysis, Cross-Layer Computation Waste, Dynamic Performance Testing, and Live SQL Analysis (EXPLAIN ANALYZE).
+
+| Rule | Check | FAIL when |
+|---|---|---|
+| R1 | Scannable IDs are Confirmed/Downgraded | ID has other disposition |
+| R2 | Low Confidence in correct section | Low Confidence ID in scannable regions instead of Candidates for Manual Review |
+| R3 | Discarded absent from body | Discarded ID in scannable regions |
+| R4 | No orphans | Report ID not in artifact |
+| R5 | No ghosts | Confirmed/Downgraded artifact row not in report |
+
+**Blocking:** If any rule is FAIL, fix and re-run.
diff --git a/plugins/sdlc-workflow/skills/performance/optimization-result.template.md b/plugins/sdlc-workflow/skills/performance/optimization-result.template.md
new file mode 100644
index 000000000..7afb15226
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/optimization-result.template.md
@@ -0,0 +1,62 @@
+---
+metadata:
+  jira_key: {jira-key}
+  workflow: {workflow-name}
+  timestamp: {iso-timestamp}
+  branch: {git-branch}
+  commit_sha: {commit-sha}
+  baseline_commit_sha: {baseline-commit-sha}
+  capture_mode: {capture-mode}
+  capture_target: {capture-target}
+  capture_base_url: {capture-base-url}
+  status: pending_verification
+---
+
+# Optimization Result: {jira-key}
+
+**Task:** {task-summary}  
+**Workflow:** {workflow-name}  
+**Executed:** {formatted-timestamp}  
+**Branch:** {git-branch}
+
+## Performance Impact
+
+| Metric | Baseline (p95) | After Optimization (p95) | Delta | Target | Status |
+|---|---|---|---|---|---|
+| LCP | {baseline-lcp}ms | {current-lcp}ms | {delta-lcp} | {target-lcp}ms | {status-lcp} |
+| FCP | {baseline-fcp}ms | {current-fcp}ms | {delta-fcp} | {target-fcp}ms | {status-fcp} |
+| DOM Interactive | {baseline-dom}ms | {current-dom}ms | {delta-dom} | {target-dom}ms | {status-dom} |
+| Total Load Time | {baseline-total}ms | {current-total}ms | {delta-total} | {target-total}ms | {status-total} |
+
+(if metric-type is "backend" or "hybrid")
+### Backend Metrics
+| Metric | Before | After | Change | Target |
+|---|---|---|---|---|
+| Response Time (p95) | {before-resp-p95} | {after-resp-p95} | {resp-p95-change} | {target-resp-p95} |
+| Throughput (req/s) | {before-throughput} | {after-throughput} | {throughput-change} | {target-throughput} |
+| Error Rate | {before-error-rate} | {after-error-rate} | {error-rate-change} | {target-error-rate} |
+| DB Query Time (p95) | {before-db-query} | {after-db-query} | {db-query-change} | {target-db-query} |
+(end if)
+
+**Performance Summary:**
+- {summary-line}
+
+## Test Scenarios Measured
+
+{scenarios-list}
+
+## Code Changes
+
+- Commit: {commit-sha}
+- PR: {pr-url}
+- Files modified: {files-changed}
+
+## Validation
+
+{validation-checks}
+
+## Next Steps
+
+- Verify PR passes acceptance criteria with `/sdlc-workflow:verify-pr {jira-key}`
+- After PR merge to main, re-run `/sdlc-workflow:performance-baseline` to update configuration with fresh metrics
+- Continue with remaining optimization tasks if targets not fully met
diff --git a/plugins/sdlc-workflow/skills/performance/optimization-task.template.md b/plugins/sdlc-workflow/skills/performance/optimization-task.template.md
new file mode 100644
index 000000000..060bdee76
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/optimization-task.template.md
@@ -0,0 +1,245 @@
+# Performance Optimization Task Template
+
+This template extends the base `task-description-template.md` with performance-specific sections.
+
+## Template
+
+```
+## Repository
+<repository-name>
+
+## Description
+<What optimization this task achieves and why>
+
+## Baseline Metrics
+
+Current performance metrics before optimization (from baseline-report.md):
+
+| Metric | Current (Baseline) | Unit |
+|---|---|---|
+| LCP (Largest Contentful Paint) | {baseline-lcp} | ms |
+| FCP (First Contentful Paint) | {baseline-fcp} | ms |
+| DOM Interactive (Time to Interactive) | {baseline-domInteractive} | ms |
+| Total Load Time | {baseline-total} | ms |
+(if analyze Step 5 produced bundle stats)
+| Bundle Size | {baseline-bundle-size} | KB |
+(end if)
+(if metric-type is "backend" or "hybrid")
+| Response Time (p95) | {baseline-response-time-p95} | ms |
+| Throughput | {baseline-throughput} | req/s |
+| Error Rate | {baseline-error-rate} | % |
+| DB Query Time (p95) | {baseline-db-query-time-p95} | ms |
+(end if)
+
+## Target Metrics
+
+Performance targets to achieve with this optimization:
+
+| Metric | Target | Improvement | Unit |
+|---|---|---|---|
+| LCP (Largest Contentful Paint) | {target-lcp} | {lcp-improvement}% | ms |
+| FCP (First Contentful Paint) | {target-fcp} | {fcp-improvement}% | ms |
+| DOM Interactive (Time to Interactive) | {target-domInteractive} | {domInteractive-improvement}% | ms |
+| Total Load Time | {target-total} | {total-improvement}% | ms |
+(if analyze Step 5 produced bundle stats)
+| Bundle Size | {target-bundle-size} | {bundle-improvement}% | KB |
+(end if)
+(if metric-type is "backend" or "hybrid")
+| Response Time (p95) | {target-response-time-p95} | {response-time-improvement}% | ms |
+| Throughput | {target-throughput} | {throughput-improvement}% | req/s |
+| Error Rate | {target-error-rate} | {error-rate-improvement}% | % |
+| DB Query Time (p95) | {target-db-query-time-p95} | {db-query-time-improvement}% | ms |
+(end if)
+
+## Files to Modify
+- `path/to/file.ext` — <brief reason>
+
+## Files to Create
+- `path/to/new_file.ext` — <purpose>
+
+## API Changes
+- `GET /v2/endpoint` — NEW: <description>
+- `PUT /v2/endpoint/{id}` — MODIFY: <what changes in request/response>
+
+## Implementation Notes
+<Specific guidance: patterns to follow, existing code to reuse,
+key functions/structs/components to interact with.
+Reference actual file paths and symbol names found during repository analysis.>
+
+## Reuse Candidates
+- `path/to/file.ext::symbol_name` — <what it does and how it relates to this task>
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Target metrics achieved (LCP ≤ {target-lcp}ms, FCP ≤ {target-fcp}ms)
+- [ ] No performance regressions in non-target scenarios (< 5% degradation)
+
+## Test Requirements
+- [ ] Functional test description 1
+- [ ] Functional test description 2
+
+## Performance Test Requirements
+
+- [ ] Re-run baseline capture for ALL scenarios (not just affected ones)
+- [ ] Verify target scenario meets target metrics
+- [ ] Verify non-target scenarios have no regressions (< 5% degradation in LCP, FCP, DOM Interactive, Total Load Time)
+- [ ] Generate before/after comparison report
+- [ ] If regression detected in non-target scenarios, prompt user for approval before committing
+
+## Verification Commands
+- `<command>` — <expected outcome>
+- `node capture-baseline.mjs --config performance-config.json` — Should show improved metrics for target scenario
+
+## Documentation Updates
+- `path/to/doc.md` — <what content to add or revise>
+
+## Dependencies
+- Depends on: Task N — <task title> (if any)
+```
+
+## Database Migration Extension
+
+When the task involves database migrations (Layer 2A with `db-migration` label), add these sections after Performance Test Requirements:
+
+```
+## Database Migration
+
+### Migration Framework
+{framework_name} (e.g., SeaORM Migration, Alembic, Flyway, TypeORM)
+
+### Before/After SQL (Manual Verification)
+
+#### Before (Current Query)
+```sql
+{original_query}
+```
+
+#### Before EXPLAIN (if live analysis was performed)
+```
+{explain_output_before}
+```
+
+#### After (Optimized Query)
+```sql
+{optimized_query}
+```
+
+### Migration Up/Down SQL (Manual Verification)
+
+#### Up (Apply)
+```sql
+{migration_up_sql — e.g., CREATE INDEX CONCURRENTLY idx_table_col ON table(col);}
+```
+
+#### Down (Rollback)
+```sql
+{migration_down_sql — e.g., DROP INDEX IF EXISTS idx_table_col;}
+```
+
+**Note:** Manual verification SQL uses `CONCURRENTLY` for production safety. Framework migration scripts below do not, because most migration runners wrap in transactions where `CONCURRENTLY` is invalid.
+
+### Migration Script (Source Code)
+
+The framework-idiomatic migration that implement-task will write to the codebase:
+
+```{language}
+{generated_migration_code — e.g., SeaORM Migration struct, Alembic revision, Flyway SQL file}
+```
+
+### Safety Checks
+- [ ] No column drops or data loss operations
+- [ ] Rollback/down migration is non-destructive
+- [ ] Migration follows CONVENTIONS.md patterns
+
+### Manual Verification
+
+Run against your database to verify improvement:
+```sql
+EXPLAIN ANALYZE {optimized_query};
+```
+Compare execution time with the Before EXPLAIN output above.
+
+### Storage Impact
+
+Before/after size queries for the affected table(s), dialect derived from Migration Framework.
+```
+
+## Database Migration Extension Rules
+
+- **Migration Script** section is required for `db-migration` tasks
+- **Before/After SQL** must show the exact SQL change for manual verification
+- **Migration Up/Down SQL** must be runnable directly against the database
+- **Rollback/Down** must be provided for every migration
+- **Safety Checks** must be pre-verified before task creation (plan-optimization Step 5.5.6)
+- **Manual Verification** command must be runnable directly by the developer
+- Migration scripts must follow CONVENTIONS.md patterns. If CONVENTIONS.md documents migration naming, index naming, or file structure conventions, the script must match exactly
+- **Storage Impact** is always included with before/after size queries for the affected table(s)
+
+---
+
+## Migration SQL Optimization Extension
+
+When the task involves fixing existing migration SQL (Layer 2A with `migration-sql-optimization` label), add these sections after Performance Test Requirements:
+
+```
+## Migration SQL Fix
+
+### Target Migration File
+{migration_file_path} (line {start_line}–{end_line})
+
+### Deployment Status
+**CONFIRM BEFORE IMPLEMENTING:** Has this migration been applied to production/staging databases?
+- If YES: Create a NEW corrective migration file that applies the optimized SQL (e.g., re-runs the backfill with the fix, replaces the function definition)
+- If NO: Modify the existing migration file directly
+
+### Before (Current Migration SQL)
+```sql
+{original_migration_sql}
+```
+
+### After (Corrected Migration SQL)
+```sql
+{corrected_migration_sql}
+```
+
+### Performance Impact
+{explanation_of_improvement — e.g., "Adding ANALYZE before the backfill fixes a 170x row overestimate, reducing query plan cost from ~1.8B to ~21M"}
+
+### Verification
+```sql
+{verification_query — e.g., EXPLAIN ANALYZE for planner estimates, timing comparison for function rewrites}
+```
+
+### Safety Checks
+- [ ] Fix preserves semantic correctness (same data outcome after migration)
+- [ ] Fix is idempotent if migration re-runs (ON CONFLICT handling preserved)
+- [ ] No data loss operations introduced
+- [ ] For function rewrites: new function produces identical output for all input patterns
+```
+
+## Migration SQL Optimization Extension Rules
+
+- **Target Migration File** must point to the exact file and line range from the analysis finding
+- **Deployment Status** check is mandatory — determines whether to modify existing migration or create a new corrective migration
+- **Before/After SQL** must show the complete affected code section, not just a snippet
+- **Verification** must include a runnable command the developer can use to confirm the fix
+- Migration SQL optimization tasks are distinct from `db-migration` tasks (which create new DDL migrations)
+- For PL/pgSQL function rewrites: the Before/After must show the complete function body, and verification must include a correctness check (both functions produce identical output) in addition to a timing comparison
+
+---
+
+## Rules
+
+Follows all base template rules (from `shared/task-description-template.md`), plus:
+
+- **Baseline Metrics** section is required — must reference actual baseline data
+- **Target Metrics** section is required — targets must be realistic and measurable
+- **Performance Test Requirements** section is required — defines regression testing criteria
+- Omit non-applicable sections (API Changes, Files to Create, Documentation Updates, etc.) as per base template rules
+- Target metrics should follow Google's Core Web Vitals "Good" thresholds unless application-specific requirements dictate otherwise:
+  - LCP: ≤ 2.5s
+  - FCP: ≤ 1.8s
+  - DOM Interactive: ≤ 3.5s
+- Improvement percentages help communicate expected impact clearly
+- For query decomposition tasks (Cross-Table OR Filter, Load-All-Then-Search, or Inefficient Queries findings involving query splitting), **Test Requirements** MUST include equivalence tests (decomposed queries return the same result set as the original) and edge case tests (single-branch success, all-branch error path, cross-branch dedup)
diff --git a/plugins/sdlc-workflow/skills/performance/performance-analysis-report.template.md b/plugins/sdlc-workflow/skills/performance/performance-analysis-report.template.md
new file mode 100644
index 000000000..3b232003d
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/performance-analysis-report.template.md
@@ -0,0 +1,747 @@
+# Performance Analysis Report
+
+**Generated:** {iso-8601-timestamp}  
+**Workflow:** {workflow-name}  
+**Baseline Date:** {baseline-capture-date}  
+**Validation Artifact:** `{analysis_dir}/findings-validation.json`  
+**Validation Status:** {not validated | passed}
+
+---
+
+## Workflow Metrics
+
+| Metric | Current (p95) | Target | Status |
+|---|---|---|---|
+| LCP (Largest Contentful Paint) | {lcp-p95} ms | 2500 ms | {status} |
+| FCP (First Contentful Paint) | {fcp-p95} ms | 1800 ms | {status} |
+| DOM Interactive | {domInteractive-p95} ms | 3500 ms | {status} |
+| Total Load Time | {total-p95} ms | 4000 ms | {status} |
+
+---
+
+## Bundle Composition
+
+**Total JavaScript Size:** {total-js-size} KB  
+**Third-Party Libraries:** {third-party-size} KB ({third-party-percentage}%)  
+**Application Code:** {application-code-size} KB ({application-code-percentage}%)
+
+**Top Third-Party Libraries by Size:**
+
+| Library | Size | Used In |
+|---|---|---|
+| {library-1} | {size-1} KB | {scenarios-1} |
+| {library-2} | {size-2} KB | {scenarios-2} |
+| ... | ... | ... |
+
+---
+
+## Finding Validation Summary
+
+**Validation Step:** Step 9.1 re-verified all findings against source code before report generation.
+
+| # | Finding | Anti-Pattern | Step | Disposition | Confidence | Severity | Timeline | Notes |
+|---|---|---|---|---|---|---|---|---|
+| F1 | {description} | {type} | {step} | {Confirmed / Confirmed (Low Confidence) / Downgraded} | {High / Medium / Low} | {Critical / High / Medium / Low} | {estimate} | {reason chain or correction notes} |
+| ... | ... | ... | ... | ... | ... | ... | ... | ... |
+
+**Validation Statistics:**
+- Findings submitted: {total}
+- Confirmed: {confirmed} ({pct}%)
+- Confirmed (Low Confidence): {low_conf} ({pct}%)
+- Downgraded: {downgraded} ({pct}%)
+- Discarded: {discarded} ({pct}%)
+
+{if discarded > 0}
+
+### Discarded Findings (Audit Trail)
+
+| # | Original Claim | Step | File:Line | Discard Reason |
+|---|---|---|---|---|
+| {id} | {original-description} | {step} | {file}:{line} | {FAILED: code not found / FAILED: pattern mismatch — {details}} |
+
+{end if}
+
+---
+
+## Anti-Pattern Analysis
+
+### {Anti-Pattern-Name}
+
+**Severity:** {High / Medium / Low}  
+**Confidence:** {High (Serena MCP) / Medium (Grep — good pattern) / Low (Grep — requires manual verification)}  
+**Instances Found:** {count}  
+**Estimated Impact:** {quantified-impact}
+
+**Description:**
+{brief-explanation-of-anti-pattern}
+
+**Detected Instances:**
+
+1. **{file-path}:{line-number}**
+   **Finding ID:** F{n}
+   ```{language}
+   {code-snippet}
+   ```
+   **Issue:** {specific-issue-description}
+   **Recommended Fix:** {actionable-recommendation}
+   **Verification Checklist:**
+   - [ ] {verification-step-1 from detection step}
+   - [ ] {verification-step-2 from detection step}
+   **Validation Status:** {Confirmed / Confirmed (Low Confidence) / Downgraded}
+   **Confidence:** {High / Medium / Low} — {reason chain: "Detection: X, Evidence: Y, Risk: Z => Final: result"}
+   **Severity:** {Critical / High / Medium / Low}
+   **Timeline:** {< 1 hour / 1-4 hours / 0.5-1 day / 1-3 days / 3-5 days / > 5 days}
+
+{... repeat for each anti-pattern ...}
+
+---
+
+## Backend Source Code Analysis
+
+**Note:** This section is included only if backend repository is configured (`backend_available = true`). Otherwise, omit this section entirely.
+
+**Backend Repository:** {backend-repo-name} ({backend-framework})  
+**Analysis Coverage:** {endpoints-analyzed} endpoints analyzed  
+**Serena Status:** {serena-instance-name or "Grep fallback"}
+
+### Backend Anti-Patterns Detected
+
+#### Database N+1 Queries
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}  
+**Estimated Latency Impact:** {(n_queries - 1) * 10ms}
+
+**Detected Instances:**
+
+1. **{handler-file-path}:{line-number}**
+   ```{language}
+   {code-snippet-showing-loop-with-queries}
+   ```
+   **Issue:** {count} queries executed sequentially in loop  
+   **Recommended Fix:**
+   - **SQL:** Use batch query: `SELECT * FROM table WHERE id IN (...)`
+   - **SeaORM:** Use `.find()` with `filter(column.is_in(ids))` or `.find_with_related()` for eager loading
+   - **Diesel:** Use `.filter(id.eq_any(ids))` for batch query
+   - **JPA/Hibernate:** Use `@EntityGraph`, `JOIN FETCH` in JPQL, or `findAllById(ids)`
+   - **SQLAlchemy:** Use `.filter(Model.id.in_(ids))` for batch query
+   - **Django ORM:** Use `Model.objects.filter(id__in=ids)` or `.select_related()`
+
+{... repeat for each N+1 instance ...}
+
+#### Missing Pagination
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}  
+**Estimated Payload Waste:** {(total_items - 20) * avg_item_size}
+
+**Detected Instances:**
+
+1. **Endpoint:** GET {endpoint-path}
+   **Handler:** {handler-file-path}  
+   **Issue:** Returns {item-count} items without pagination  
+   **Recommended Fix:** Add `page` and `limit` query parameters, implement `.limit()` and `.offset()` in query
+
+{... repeat for each pagination issue ...}
+
+#### Missing Caching
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}  
+**Estimated Latency Reduction:** {operation_time × analysis_cache_hit_rate}
+
+**Detected Instances:**
+
+1. **Endpoint:** GET {endpoint-path}
+   **Handler:** {handler-file-path}  
+   **Issue:** {expensive-operation-description} on every request (no cache detected)  
+   **Data Change Frequency:** {static / slow-changing / fast-changing}  
+   **Recommended Fix:** Implement cache layer (Redis, in-memory) with appropriate TTL
+
+{... repeat for each caching issue ...}
+
+#### Inefficient Queries
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}  
+**Estimated Impact:** 30-50% query time reduction
+
+**Detected Instances:**
+
+1. **Query:** {query-snippet}
+   **Handler:** {handler-file-path}:{line-number}  
+   **Issue:** SELECT * fetches {column-count} columns but only {used-count} used in response  
+   **Recommended Fix:** Specify exact columns: `SELECT id, name, price FROM products WHERE ...`
+
+{... repeat for each inefficient query ...}
+
+#### Unused Table Joins
+
+**Severity:** {Critical / High / Medium / Low}  
+**Instances Found:** {count}  
+**Estimated Impact:** {total_latency_saved}ms saved per request
+
+**Description:** Database queries that JOIN tables but never access fields from the joined tables, wasting database CPU, I/O, and memory resources.
+
+**Detected Instances:**
+
+1. **Endpoint:** {endpoint_method} {endpoint_path}
+   **Handler:** {handler-file-path}:{line-number}  
+   **Query:**
+   ```{language}
+   {full_query_with_highlighted_join}
+   ```
+   **Unused Join:** `{joined_table}` (alias: `{alias}`)  
+   **Reason:** No fields from `{joined_table}` accessed in SELECT, WHERE, or response schema  
+   **Join Type:** {INNER/LEFT/RIGHT JOIN}  
+   **Table Size:** {estimated_row_count} rows  
+   **Index Status:** {Indexed/Not Indexed} on foreign key  
+   **Estimated Overhead:** {overhead_ms}ms per query  
+   **Call Frequency:** {single/N+1 with count calls}  
+   **Total Impact:** {total_impact}ms per request  
+   **Recommended Fix:**
+   ```{language}
+   {optimized_query_without_unused_join}
+   ```
+
+{... repeat for each unused join instance ...}
+
+**Total Estimated Impact:** {sum_of_all_impacts}ms reduction across {count} endpoints
+
+#### Service Chain Analysis (Deep Call Graph)
+
+**Depth Analyzed:** {chain_depth} levels  
+**Total Handlers Traced:** {handler_count}  
+**Analysis Method:** {Serena MCP (High Confidence) / Grep (Fallback - Medium Confidence)}
+
+{... for each handler with call chain findings ...}
+
+##### Endpoint: {endpoint_method} {endpoint_path}
+
+**Call Graph:**
+```
+{endpoint_method} {endpoint_path}
+  └─ {callee_1}          [{file}:{line}]
+       ├─ {callee_2}     [{file}:{line}]    ← {query_annotation}
+       └─ {callee_3}     [{file}:{line}]
+            ├─ {callee_4}  [{file}:{line}]  ← {query_annotation}
+            └─ {callee_5}  [{file}:{line}]  ← {query_annotation}
+```
+
+**Query Ledger:**
+
+| # | Query | Source | Depth | Loop Mult. | Cond? | Cache? | Effective Count |
+|---|---|---|---|---|---|---|---|
+| {n} | {description} | {file:line} | {depth} | {multiplier} | | | {effective} |
+| **Total (all)** | | | | | | | **{total}** |
+| **Total (warm)** | | | | | | | **{warm_total}** |
+| **Total (cold)** | | | | | | | **{cold_total}** |
+
+**Estimated Total DB Latency:** {total_queries * db_latency_ms}ms  
+
+**Anti-Patterns Found at Depth:**
+- Depth {N}: {anti-pattern-description} in `{symbol_name}` ({file}:{line})
+
+{... end for each handler ...}
+
+---
+
+#### Wasted Computation
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}
+
+**Description:** Handlers that call service methods returning substantial data but only use a subset of the result. The unused portion may involve database queries that execute needlessly.
+
+**Detected Instances:**
+
+1. **Endpoint:** {endpoint_method} {endpoint_path}
+   **Handler:** {handler-file-path}:{line-number}  
+   **Service Call:** `{service.method_name(...)}`  
+   **Returns:** `{ReturnType}` with {total_field_count} fields  
+   **Handler Uses:** {used_field_count} fields ({used_field_list})  
+   **Wasted Fields:** {unused_field_list}  
+   **Wasted Queries:** {count} queries ({wasted_query_latency}ms estimated)  
+   **Recommended Fix:** Create `{optimized_method_name}()` that returns only needed data, or add a field projection parameter
+
+{... repeat for each wasted computation instance ...}
+
+---
+
+#### Conditional Query Patterns (Memo/Option)
+
+**Severity:** {High / Medium / Low}
+**Instances Found:** {count}
+**Estimated Impact:** {total_conditional_queries} additional queries per request
+
+**Description:** Functions that accept lazy-load parameters (`Memo<T>`, `Option<T>`) and fire
+database queries when callers pass the un-provided variant instead of pre-loading the data.
+
+**Detected Instances:**
+
+1. **Function:** `{function_name}` ({file}:{line})
+   **Parameter:** `{param_name}: Memo<{Type}>`
+   **Conditional Query:** `{query_description}` — fires when `Memo::NotProvided` is passed
+   **Callers passing NotProvided:**
+   - `{caller_1}` ({file}:{line}) — inside loop (×{iterations}) = {effective_count} queries
+   - `{caller_2}` ({file}:{line}) — single call = 1 query
+   **Total Impact:** {sum_effective} conditional queries per request
+   **Recommended Fix:** Pre-load `{Type}` in batch at the caller level and pass via `Memo::Provided`
+
+{... repeat for each instance ...}
+
+---
+
+#### Inter-Query SQL Duplication
+
+**Severity:** {High / Medium / Low}
+**Instances Found:** {count}
+**Estimated Impact:** {redundant_executions} redundant CTE/subquery executions per request
+
+**Description:** Multiple queries within the same handler chain that contain identical or
+semantically equivalent CTEs/subqueries, causing the database to compute the same intermediate
+results multiple times.
+
+**Detected Instances:**
+
+1. **Duplicated CTE:** `{cte_name}`
+   **Appears in:** {count} queries within handler for {endpoint}
+   **Queries:**
+   - Query #{n1}: {description_1} ({source_1})
+   - Query #{n2}: {description_2} ({source_2})
+   **Shared SQL:**
+   ```sql
+   {shared_sql_fragment}
+   ```
+   **Estimated Overhead:** {(count-1)} redundant executions × {est_time}ms = {total_overhead}ms
+   **Recommended Fix:** {Extract to materialized temp table / Refactor to single query}
+
+{... repeat for each instance ...}
+
+---
+
+#### Missing Database Indexes
+
+**Severity:** {High / Medium / Low}  
+**Instances Found:** {count}  
+**Migration Directory:** {migration_path}
+
+**Description:** Query WHERE/JOIN columns (found at any depth in the call chain) that lack database indexes, causing sequential scans instead of index lookups.
+
+**Detected Instances:**
+
+1. **Table:** `{table_name}`  
+   **Column:** `{column_name}`  
+   **Table Source:** `{migration_file_path}` or "Not found in migration files — verify manually"  
+   **Used In:** {query_description} (`{source_file}:{line}`)  
+   **Query Type:** {WHERE filter / JOIN condition / ORDER BY}  
+   **Loop Multiplier:** {from query_ledger — how many times this query fires per request}  
+   **Estimated Impact:** Sequential scan on {estimated_rows} rows vs. index lookup  
+   **Recommended Fix:**
+   ```sql
+   CREATE INDEX idx_{table}_{column} ON {table}({column});
+   ```
+
+{... repeat for each missing index ...}
+
+---
+
+#### Cache Effectiveness Analysis
+
+**Severity:** {High / Medium / Low}
+**Instances Found:** {count}
+**Estimated Impact:** Fixing bypass queries is a prerequisite for {improvement}ms cache benefit
+
+**Note:** Requires baseline cache data from Step 4. If no baseline exists, record:
+"No baseline data; run `/sdlc-workflow:performance-baseline` first."
+
+**Description:** Endpoints where an application-level cache exists but provides minimal
+improvement because cache-bypass queries dominate warm-cache response time.
+
+**Detected Instances:**
+
+1. **Endpoint:** {method} {path}
+   **Cache Type:** {description}
+   **Baseline Improvement:** {improvement_pct}% ({cold_ms}ms → {warm_ms}ms)
+   **Query Breakdown:**
+   | Category | Queries | Estimated Latency |
+   |---|---|---|
+   | Cache-gated (cold only) | {count} | {latency}ms |
+   | Cache-bypass (every request) | {count} | {latency}ms |
+   | **Total** | **{total}** | **{total_latency}ms** |
+   **Bypass Dominance:** {bypass_pct}% of queries fire regardless of cache state
+   **Blocking Findings:** {finding_names_and_ids}
+   **Recommendation:** {actionable_recommendation}
+
+{... repeat for each instance ...}
+
+---
+
+#### Migration SQL Anti-Patterns
+
+**Migration Directory:** {migration_path}
+**Migration Files Scanned:** {file_count}
+**DML-Containing Migrations:** {dml_file_count}
+
+**Description:** Performance anti-patterns detected in migration file DML (backfill queries, function definitions). These affect deployment time and database load during migration execution.
+
+{if any 7.8.x findings}
+
+##### Missing Statistics Refresh
+
+{if 7.8.1 findings}
+
+**Finding ID:** F{n}
+**Severity:** {severity}
+**Migration File:** `{migration_file_path}`
+
+```sql
+{backfill_query_snippet}
+```
+
+**Issue:** Bulk {INSERT/UPDATE} operates on `{table_name}` without preceding ANALYZE. Stale statistics may cause planner to misestimate row counts, leading to suboptimal query plans (e.g., nested loops instead of hash joins).
+**Tables Affected:** {table_list}
+**Recommended Fix:** Add `ANALYZE {table_name};` before the backfill query.
+**Validation Status:** {disposition}
+
+{... repeat for each instance ...}
+
+{end if}
+
+##### Non-Materialized CTE Re-evaluation
+
+{if 7.8.2 findings}
+
+**Finding ID:** F{n}
+**Severity:** {severity}
+**Migration File:** `{migration_file_path}`
+
+```sql
+{cte_query_snippet}
+```
+
+**Issue:** CTE `{cte_name}` contains {expensive_operation_description} and is referenced {ref_count} times without MATERIALIZED keyword. PostgreSQL 12+ may inline the CTE, causing the expensive operations to be evaluated {ref_count} times instead of once.
+**Recommended Fix:** Add MATERIALIZED keyword: `WITH {cte_name} AS MATERIALIZED (...)`
+**Validation Status:** {disposition}
+
+{... repeat for each instance ...}
+
+{end if}
+
+##### Uniform Processing of Partitionable Data
+
+{if 7.8.3 findings}
+
+**Finding ID:** F{n}
+**Severity:** {severity}
+**Confidence:** {confidence}
+**Migration File:** `{migration_file_path}`
+
+```sql
+{uniform_query_snippet}
+```
+
+**Issue:** Function `{function_name}` is applied to all rows, but its early-exit guard (`{guard_condition}`) indicates most rows are returned unchanged. The expensive path (JOIN + function evaluation) could be limited to rows matching `{partition_predicate}`.
+**Guard Condition:** `{guard_condition_in_function}`
+**Recommended Fix:** Split into two passes — one for rows matching `{partition_predicate}` (with JOIN + function), one for the rest (direct insert without JOIN/function).
+**Validation Status:** {disposition}
+
+{... repeat for each instance ...}
+
+{end if}
+
+##### Expensive PL/pgSQL Function Patterns
+
+{if 7.8.4 findings}
+
+**Finding ID:** F{n}
+**Severity:** {severity}
+**Migration File:** `{migration_file_path}`
+**Function:** `{function_name}`
+
+```sql
+{function_snippet}
+```
+
+**Issue:** {pattern_description — e.g., "regexp_replace() with dynamically concatenated pattern inside FOREACH loop — regex is recompiled on every iteration"}
+**Recommended Fix:** {fix_description — e.g., "Replace regexp_replace() with boundary-aware replace() calls using SPDX delimiter pairs (space, parentheses, +)"}
+**Estimated Speedup:** {speedup_estimate if available, otherwise "Benchmark required"}
+**Validation Status:** {disposition}
+
+{... repeat for each instance ...}
+
+{end if}
+
+{else: "No migration SQL anti-patterns detected."}
+
+---
+
+### Cross-Repository Over-Fetching Analysis
+
+**Note:** This analysis cross-references backend response schemas with frontend field usage.
+
+#### Per-Endpoint Analysis
+
+##### Endpoint: GET {endpoint-path}
+
+**Backend Handler:** {handler-file-path}  
+**Response Type:** {ResponseStructName}  
+**Total Fields:** {total-field-count}  
+**Used by Frontend:** {used-field-count}  
+**Unused Fields:** {unused-field-list}  
+**Over-Fetching Percentage:** {waste-percentage}%  
+**Call Pattern:** {Single call / N+1 (count calls)}  
+**Payload Waste:** {waste-bytes} KB per request × {call-count if N+1} calls = {total-waste} KB  
+**Recommendation:** {Create specialized DTO / Use GraphQL / Field projection}
+
+{... repeat for each endpoint ...}
+
+---
+
+### Cross-Layer Computation Waste
+
+**Note:** This section is included only when `analysis_scope` is `full-stack` or `full-stack-monorepo`
+AND backend chain analysis (Step 7.6.2) completed successfully.
+
+**Severity:** {Critical / High / Medium / Low}
+**Instances Found:** {count}
+**Estimated Impact:** {total_wasted_queries} wasted queries per dashboard load
+
+**Description:** Backend endpoints compute expensive response fields (requiring database queries)
+that the frontend never reads. Unlike handler-level waste (Wasted Computation section above),
+this detects waste at the HTTP API boundary — where the backend serves fields the frontend discards.
+
+**Detected Instances:**
+
+1. **Endpoint:** {method} {path}
+   **Total Backend Query Cost:** {total_queries} queries ({total_latency}ms)
+   **Frontend-Used Fields:** {field_list} — Cost: {used_queries} queries
+   **Frontend-Unused Fields:** {field_list} — Cost: {wasted_queries} queries
+   **Cross-Layer Waste:** {waste_pct}% of backend computation serves no frontend purpose
+   **Call Pattern:** {single / N+1 (×count)}
+   **Total Wasted Queries:** {wasted × call_count}
+   **Recommended Fix:** {recommendation}
+
+{... repeat for each instance ...}
+
+---
+
+## Dynamic Performance Testing
+
+**Note:** This section is included only if dynamic testing was executed (backend running + test data manifest exists).
+
+**Status:** Service running on localhost:{port}  
+**Methodology:** curl loop — cold-cache first request + {iterations} warm-cache requests for p50/p95/p99 percentiles  
+**Iterations:** {iterations} requests per endpoint
+
+### Endpoint Performance Metrics
+
+{... for each endpoint in dynamic_results ...}
+
+#### Endpoint: {endpoint_method} {endpoint_path}
+
+**Test URL:** {test_url}
+
+**Response Time (milliseconds)**:
+| Metric | Value |
+|---|---|
+| p50 (Median) | {p50}ms |
+| p95 | {p95}ms |
+| p99 | {p99}ms |
+| Mean | {mean}ms |
+
+**Cache Effectiveness**:
+- First request: {first_request_ms}ms (cache miss)
+- Subsequent mean: {mean}ms (cache hits)
+- Improvement: {cache_improvement_pct}% faster
+- **Status**: {cache_status} ✅/⚠️
+
+**Dynamic vs Static Comparison**:
+| Source | Estimate | Notes |
+|---|---|---|
+| Static Analysis | **[Manual: See Backend Source Code Analysis section]** | Check N+1 query findings, estimated overhead |
+| Dynamic Actual | {p95}ms (p95) | Measured with curl loop |
+| Variance | **[Manual: Calculate]** | If >200ms: Database profiling needed |
+
+**Recommendation**: Review static analysis estimates. If variance >200ms, database query optimization is critical priority.
+
+{... end for each endpoint ...}
+
+### Summary
+
+**Total Endpoints Tested:** {count}  
+**Cache-Effective Endpoints:** {count with "Effective" status}  
+**Slow Endpoints (p95 > 500ms):** {count}  
+**Recommended Actions:**
+- Endpoints with >200ms variance: Profile with database query analyzer
+- Minimal cache effectiveness: Review caching strategy
+- Slow endpoints: Prioritize for optimization
+
+---
+
+## Live SQL Analysis (EXPLAIN ANALYZE)
+
+**Note:** This section is included only when live SQL analysis was performed (Step 9.7). If the user skipped live analysis, omit this section entirely.
+
+**Database:** {database_name} (connection details redacted)
+**Queries Analyzed:** {analyzed_count}
+**Queries Skipped:** {skipped_count}
+**Skip Reasons:** {ORM derivation not yet supported: {orm_skip_count}, Mutation query: {mutation_skip_count}, Dynamic SQL: {dynamic_skip_count}}
+**Analysis Method:** EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) for SELECT queries; EXPLAIN (FORMAT TEXT) for mutation queries
+
+### SQL Query Ledger
+
+| # | Query Description | Source | Query Type | Derived SQL | Execution Time | Planning Time |
+|---|---|---|---|---|---|---|
+| {n} | {description} | {file}:{line} | {SELECT/INSERT/...} | `{sql_snippet_truncated}` | {exec_time}ms | {plan_time}ms |
+
+### Execution Plan Bottlenecks
+
+{... for each bottleneck found ...}
+
+#### Query #{n}: {query_description}
+
+**Source:** {file}:{line}
+**Finding ID:** F{n}
+**Execution Time:** {exec_time}ms (Planning: {plan_time}ms)
+
+**Derived SQL:**
+```sql
+{derived_sql}
+```
+
+**EXPLAIN Output:**
+```
+{full_explain_output}
+```
+
+**Bottlenecks Detected:**
+
+| Bottleneck | Node | Table | Est. Rows | Actual Rows | Mismatch | Impact |
+|---|---|---|---|---|---|---|
+| {type} | {node_description} | {table} | {est} | {actual} | {ratio}x | {impact_description} |
+
+**Recommended Fix:**
+```sql
+{recommended_sql_or_index}
+```
+
+**Validation Status:** {Confirmed / Downgraded}
+**Confidence:** High — live execution plan evidence
+**Severity:** {Critical / High / Medium / Low}
+**Timeline:** {estimate}
+
+{... end for each bottleneck ...}
+
+### Heuristic vs Measured Comparison
+
+**Method:** Static estimates use `db_latency_ms` ({db_latency_ms}ms) × effective query count from the query ledger. Measured values are actual EXPLAIN ANALYZE execution times. These are not comparable methodologies — the heuristic is a rough cost model, not a per-query prediction.
+
+| Query # | Heuristic Estimate | Formula | Measured Time | Notes |
+|---|---|---|---|---|
+| {n} | {heuristic_ms}ms | {db_latency_ms}ms × {effective_count} | {measured_ms}ms | {notes} |
+
+**Summary:** {N} of {total} analyzed queries show >10x variance between heuristic and measured — indicating the heuristic under/overestimates for those query shapes.
+
+### Phase 1 Limitations
+
+- ORM-derived queries (SeaORM builders, SQLAlchemy chains, TypeORM QueryBuilder) were skipped. Only queries with literal SQL in source code were analyzed.
+- Mutation queries (INSERT/UPDATE/DELETE) used EXPLAIN without ANALYZE (plan only, no execution) or were skipped.
+- Query parameters were substituted with representative values — actual runtime parameters may produce different execution plans due to data distribution.
+
+---
+
+## Candidates for Manual Review (Low Confidence)
+
+> Findings below were detected via grep-based pattern matching without semantic analysis.
+> They have a high false-positive rate and require manual verification with browser DevTools
+> or runtime profiling before investing optimization effort.
+
+### Over-Fetching (Grep-Based)
+
+{if over-fetching grep findings exist}
+
+| # | Endpoint | Unused Fields (Estimated) | Response Size | Confidence | Verification |
+|---|---|---|---|---|---|
+| {n} | {endpoint} | {field_list} | {size} | Low | Requires destructuring/prop-drilling review |
+
+{else: "No grep-based over-fetching candidates detected."}
+
+### Layout Thrashing (Grep-Based)
+
+{if layout thrashing grep findings exist}
+
+| # | File:Line | Pattern | Loop Context | Confidence | Verification |
+|---|---|---|---|---|---|
+| {n} | {file}:{line} | {read} → {write} | {loop_info} | Low | Requires Chrome DevTools Performance profiling |
+
+{else: "No grep-based layout thrashing candidates detected."}
+
+---
+
+## Recommended Optimizations
+
+**Note:** Optimizations are categorized by layer (Frontend / Backend / Integration) when backend analysis is available.
+
+Tactical optimizations are prioritized by estimated impact (time or size savings) and ordered
+so that prerequisite fixes appear before the optimizations that depend on them.
+Strategic optimizations are listed separately and represent architectural changes that set
+the long-term performance ceiling.
+
+### Tactical Optimizations
+
+| Priority | Optimization | Confidence | Severity | Timeline | Prerequisite | Estimated Impact | Effort |
+|---|---|---|---|---|---|---|---|
+| 1 | {optimization-1} | {confidence-1} | {severity-1} | {timeline-1} | {prerequisite-1 or —} | {impact-1} | {effort-1} |
+| 2 | {optimization-2} | {confidence-2} | {severity-2} | {timeline-2} | {prerequisite-2 or —} | {impact-2} | {effort-2} |
+| 3 | {optimization-3} | {confidence-3} | {severity-3} | {timeline-3} | {prerequisite-3 or —} | {impact-3} | {effort-3} |
+| ... | ... | ... | ... | ... | ... | ... | ... |
+
+### Strategic / Architectural Optimizations
+
+> These changes define the long-term performance ceiling. They require more coordination
+> but are the only path to guaranteeing target SLAs at production dataset sizes.
+
+| Priority | Optimization | Confidence | Severity | Timeline | Prerequisite | Estimated Impact | Effort |
+|---|---|---|---|---|---|---|---|
+| S1 | {optimization} | {confidence} | {severity} | {timeline} | {prerequisite or —} | {impact} | {effort} |
+| ... | ... | ... | ... | ... | ... | ... | ... |
+
+{if no strategic optimizations: "No strategic/architectural optimizations identified — tactical fixes are sufficient to reach target SLAs."}
+
+**Effort Legend (shared with Executive Summary):**
+- **Low:** < 1 day of work
+- **Medium:** 1-3 days of work
+- **High:** > 3 days of work
+
+**Timeline Legend (per-finding implementation estimate):**
+- **< 1 hour:** Single-line or config change
+- **1–4 hours:** Single-file straightforward refactor
+- **0.5–1 day:** Multi-file change within one module
+- **1–3 days:** Cross-module refactor or new service method
+- **3–5 days:** Architectural change or new infrastructure
+- **> 5 days:** Major restructuring
+
+---
+
+## Executive Summary
+
+**Overall Performance Rating:** {rating} (Excellent / Good / Needs Improvement / Poor)
+
+**Key Findings:**
+- {summary-bullet-1}
+- {summary-bullet-2}
+- {summary-bullet-3}
+
+**Top 3 Optimization Opportunities:**
+1. {opportunity-1} — Estimated impact: {impact-1}
+2. {opportunity-2} — Estimated impact: {impact-2}
+3. {opportunity-3} — Estimated impact: {impact-3}
+
+---
+
+## Next Steps
+
+1. Review this report with the team and prioritize optimizations
+2. Create optimization plan and Jira Epic/Tasks using `/sdlc-workflow:performance-plan-optimization`
+3. After implementing optimizations, re-run `/sdlc-workflow:performance-baseline` to capture new baseline and measure improvements
diff --git a/plugins/sdlc-workflow/skills/performance/performance-plan.template.md b/plugins/sdlc-workflow/skills/performance/performance-plan.template.md
new file mode 100644
index 000000000..90ad6257e
--- /dev/null
+++ b/plugins/sdlc-workflow/skills/performance/performance-plan.template.md
@@ -0,0 +1,218 @@
+# Performance Optimization Plan
+
+**Workflow:** {workflow-name}  
+**Generated:** {iso-8601-timestamp}  
+**Overall Rating:** {current-rating} → Target: Excellent
+
+---
+
+## Executive Summary
+
+**Current State:**
+- LCP (p95): {current-lcp} ms (Target: 2500 ms)
+- FCP (p95): {current-fcp} ms (Target: 1800 ms)
+- DOM Interactive (p95): {current-domInteractive} ms (Target: 3500 ms)
+- Total Load Time (p95): {current-total} ms (Target: 4000 ms)
+
+(if metric-type is "backend" or "hybrid")
+- Response Time (p95): {current-response-time-p95} ms
+- Throughput: {current-throughput} req/s
+- Error Rate: {current-error-rate}%
+- DB Query Time (p95): {current-db-query-time-p95} ms
+(end if)
+
+**Expected Impact:**
+- Estimated LCP improvement: {lcp-improvement} ms ({lcp-percentage}% reduction)
+- Estimated FCP improvement: {fcp-improvement} ms ({fcp-percentage}% reduction)
+- Estimated DOM Interactive improvement: {domInteractive-improvement} ms ({domInteractive-percentage}% reduction)
+- Estimated bundle size reduction: {bundle-size-reduction} KB
+
+**Total Effort Estimate:** {total-effort-days} days
+
+---
+
+## Impact Analysis Summary
+
+**Total Optimizations Evaluated:** {total-count}  
+**Recommended:** {recommend-count} optimizations → {task-count} tasks  
+**Recommended with Caution:** {caution-count} optimizations (extra safeguards required)  
+**Conditional:** {conditional-count} optimizations (prerequisites not met)  
+**Deferred:** {defer-count} optimizations (documented for future review)  
+**Rejected:** {reject-count} optimizations (risk > benefit)
+
+### Decision Distribution
+
+| Decision | Count | Reason |
+|---|---|---|
+| RECOMMEND | {recommend-count} | Safe, high-benefit optimizations |
+| RECOMMEND WITH CAUTION | {caution-count} | High benefit but medium-high risk, extra safeguards required |
+| CONDITIONAL | {conditional-count} | Prerequisites not met (infrastructure, feature flags, etc.) |
+| DEFER | {defer-count} | Risk currently outweighs benefit |
+| REJECT | {reject-count} | Not worth pursuing |
+
+---
+
+## Task Sequence
+
+| # | Task | Category | Impact | Effort | Dependencies |
+|---|---|---|---|---|---|
+| 1 | {task-1-summary} | {category-1} | {impact-1} | {effort-1} | None |
+| 2 | {task-2-summary} | {category-2} | {impact-2} | {effort-2} | Task 1 |
+| ... | ... | ... | ... | ... | ... |
+
+---
+
+## Task Details
+
+### Task 1: {task-1-summary}
+
+**Category:** {category}  
+**Impact:** {quantified-impact}  
+**Effort:** {effort-estimate}  
+**Risk:** {High / Medium / Low}
+
+**Description:**
+{what-this-task-achieves}
+
+**Files to Modify:**
+- `{file-path-1}` — {reason}
+- `{file-path-2}` — {reason}
+
+**Baseline Metrics:**
+- LCP: {current-lcp} ms
+- Bundle size: {current-bundle-size} KB
+(if metric-type is "backend" or "hybrid")
+- Response Time (p95): {baseline-response-time-p95} ms
+- Throughput: {baseline-throughput} req/s
+- Error Rate: {baseline-error-rate}%
+- DB Query Time (p95): {baseline-db-query-time-p95} ms
+(end if)
+
+**Target Metrics:**
+- LCP: < {target-lcp} ms
+- Bundle size: < {target-bundle-size} KB
+(if metric-type is "backend" or "hybrid")
+- Response Time (p95): < {target-response-time-p95} ms
+- Throughput: > {target-throughput} req/s
+- Error Rate: < {target-error-rate}%
+- DB Query Time (p95): < {target-db-query-time-p95} ms
+(end if)
+
+**Acceptance Criteria:**
+- [ ] {criterion-1}
+- [ ] {criterion-2}
+
+**Performance Test Requirements:**
+- [ ] Re-run baseline capture after implementation
+- [ ] Verify LCP improvement of at least {improvement} ms
+- [ ] Ensure no regressions in other metrics
+
+**Dependencies:** {prerequisite-tasks}
+
+**Rollback Strategy:** {how-to-undo-if-needed}
+
+---
+
+{... repeat for each task ...}
+
+---
+
+## Deferred and Rejected Optimizations
+
+### Deferred for Future Review
+
+{For each DEFER or CONDITIONAL decision:}
+
+#### {optimization-name}
+
+**Performance Benefit:** {quantified-impact} ({percentage}% improvement)  
+**Decision:** {DEFERRED | CONDITIONAL}  
+**Reason:** {why deferred or what prerequisites are missing}
+
+**Impact Analysis:**
+- **Impact Scope:** {scope}
+- **Impact Severity:** {severity}
+- **Affected Workflows:** {list}
+- **Risk Factors:** {list}
+
+**Conditions for Reconsideration:**
+- {condition-1}
+- {condition-2}
+
+{If CONDITIONAL, list prerequisites:}
+**Prerequisites:**
+- {prerequisite-1}
+- {prerequisite-2}
+- **Estimated time to satisfy:** {estimate}
+
+---
+
+### Rejected Optimizations
+
+{For each REJECT decision:}
+
+#### {optimization-name}
+
+**Performance Benefit:** {quantified-impact} ({percentage}% improvement)  
+**Decision:** REJECTED  
+**Reason:** {why rejected - explain risk/benefit analysis}
+
+**Impact Analysis:**
+- **Impact Scope:** {scope}
+- **Impact Severity:** {severity}
+- **Risk Factors:** {list}
+
+**Rationale:** {detailed explanation of why risk far outweighs benefit}
+
+**Alternative Approaches:** (if any)
+- {alternative-1}
+- {alternative-2}
+
+---
+
+## Risk Assessment
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| {risk-1} | {likelihood} | {impact} | {mitigation-strategy} |
+| {risk-2} | {likelihood} | {impact} | {mitigation-strategy} |
+| ... | ... | ... | ... |
+
+**Common Risks:**
+- **Breaking changes:** Optimizations may introduce regressions. Mitigation: Comprehensive testing before merging.
+- **Performance measurement noise:** Baseline variability may obscure small improvements. Mitigation: Run multiple baseline iterations.
+- **Third-party library constraints:** Some optimizations may be blocked by library limitations. Mitigation: Evaluate alternative libraries.
+
+---
+
+## Rollback Strategy
+
+If an optimization causes issues:
+
+1. **Immediate rollback:** Revert the commit and redeploy previous version
+2. **Root cause analysis:** Investigate what caused the issue
+3. **Revised approach:** Update the optimization plan and re-attempt with fixes
+4. **Re-baseline:** Capture new baseline to measure impact of rollback
+
+---
+
+## Jira Epic and Tasks
+
+**Epic:** {epic-jira-key} - {epic-title}
+
+**Tasks:**
+- {task-1-jira-key}: {task-1-summary}
+- {task-2-jira-key}: {task-2-summary}
+- {task-3-jira-key}: {task-3-summary}
+
+All tasks linked to Epic via parent hierarchy relationship.
+
+---
+
+## Next Steps
+
+1. **Review this plan** with the team and adjust task sequencing if needed
+2. **Create Jira Epic and Tasks** — This skill will create these automatically
+3. **Implement tasks** in sequence using `/sdlc-workflow:implement-task {task-id}` (performance sections auto-detected)
+4. **Re-baseline after each task** using `/sdlc-workflow:performance-baseline` to measure improvements
+5. **Final verification** using `/sdlc-workflow:verify-pr` to validate all targets met (performance sections auto-detected)
diff --git a/plugins/sdlc-workflow/skills/setup/conventions.template.md b/plugins/sdlc-workflow/skills/setup/conventions.template.md
index 7942a545a..0d5b7fcc0 100644
--- a/plugins/sdlc-workflow/skills/setup/conventions.template.md
+++ b/plugins/sdlc-workflow/skills/setup/conventions.template.md
@@ -111,3 +111,20 @@
      - Pin exact versions in Cargo.toml -->
 
 {{dependencies}}
+
+## Performance Optimization
+
+<!-- Document performance optimization conventions for your project.
+     This section guides performance workflow usage and metrics expectations.
+     See the Performance Workflow documentation for details on the performance
+     optimization workflow (setup, baseline, analyze, plan, implement, verify).
+     
+     Example:
+     - Baseline capture frequency: Before major releases, after library upgrades
+     - Target metrics: LCP < 2500ms (p95), FCP < 1800ms (p95), DOM Interactive < 3500ms (p95)
+     - Anti-pattern severity thresholds: Follow default thresholds in performance-metrics-guide.md
+     - Commit message type: Use `perf(scope): description` for performance optimizations
+     - Performance documentation: Quick reference style (tables, bullets, minimal prose)
+     - Regression threshold: 5% degradation in non-target scenarios triggers investigation -->
+
+{{performance-optimization}}
diff --git a/plugins/sdlc-workflow/skills/verify-pr/SKILL.md b/plugins/sdlc-workflow/skills/verify-pr/SKILL.md
index 401864a96..c148bb054 100644
--- a/plugins/sdlc-workflow/skills/verify-pr/SKILL.md
+++ b/plugins/sdlc-workflow/skills/verify-pr/SKILL.md
@@ -127,6 +127,19 @@ Parse the structured description expecting these sections:
 - **Test Requirements** — tests to write or update
 - **Verification Commands** — commands with expected outcomes (optional)
 - **Dependencies** — prerequisite tasks (verify they are Done)
+- **Baseline Metrics** — performance baseline (optional, performance tasks only)
+- **Target Metrics** — performance targets (optional, performance tasks only)
+- **Performance Test Requirements** — scenarios and criteria (optional, performance tasks only)
+
+### Task Type Detection
+
+Set `task_type` using these checks in priority order:
+
+1. **`db-migration`**: The issue labels include `db-migration`, OR the description contains a **Database Migration** section with **Migration Script (Source Code)** and **Before/After SQL** subsections
+2. **`performance`**: The issue labels include `performance-optimization`, OR the description contains **Baseline Metrics**, **Target Metrics**, and **Performance Test Requirements** sections
+3. **`standard`**: Otherwise
+
+`db-migration` inherits all `performance` verification steps (4.5, 4.6, 4.7, 10) plus Step 4.8 (migration safety verification).
 
 If any required section is missing or the description doesn't follow the template, stop and ask the user for clarification.
 
@@ -280,8 +293,15 @@ inform classification decisions.
    yet — that happens in the Style/Conventions sub-agent. The goal here is only to load
    CONVENTIONS.md once for reuse across comment classification and sub-agent dispatch.
 
-If `CONVENTIONS.md` does not exist, proceed normally — the Style/Conventions sub-agent
-will check for implicit conventions demonstrated by codebase usage patterns.
+**Standard tasks (`task_type = standard`):** If `CONVENTIONS.md` does not exist, proceed normally — the Style/Conventions sub-agent will check for implicit conventions demonstrated by codebase usage patterns.
+
+**Performance tasks (`task_type = performance`):** CONVENTIONS.md is **mandatory**. If the file does not exist at the repository root, halt immediately:
+
+> "Performance optimization verification requires CONVENTIONS.md with at minimum: CI check commands, performance test commands, and regression thresholds. Create it before proceeding."
+
+**Stop execution immediately.** Do not proceed with any subsequent steps.
+
+If CONVENTIONS.md exists, extract any "Performance Thresholds" or "Regression Limits" section for use in Step 4.6 (drift detection thresholds).
 
 ### Step 4c – Classify Feedback
 
@@ -303,6 +323,138 @@ Record all classifications. Only **code change requests** trigger sub-task creat
 in Step 6. Convention upgrades from Step 6b may later elevate suggestions to code
 change requests before sub-task creation.
 
+## Step 4.5 – Read Implementation Results (Performance Tasks Only)
+
+**If `task_type = standard`:** Skip to Step 5.
+
+Find the optimization result report in `performance/optimization-results/{jira_key}-*.md` (most recent by timestamp). Read and extract: jira_key, timestamp, branch, commit_sha, baseline_commit_sha, capture_mode, capture_target, capture_base_url, status, and before/after metrics by metric_type (frontend: LCP, FCP, DOM Interactive; backend: Response Time p95/p99, Throughput, Error Rate).
+
+If report not found, check the PR description for a before/after table as fallback. If neither source has results, record "Implementation results not found" and proceed.
+
+## Step 4.6 – Environmental Drift Detection (Performance Tasks Only)
+
+**If `task_type = standard`:** Skip to Step 5.
+
+**Environment mismatch check (run before re-run prompt):** Read `metadata.capture_target` from config (null → treat as `localhost`). Compare against `capture_target` from the optimization result report (Step 4.5). If they differ → record `Environment Match: MISMATCH` for the report. Skip numeric drift thresholds for frontend metrics — "Baseline used {config target}, implementation used {report target} — metrics not comparable." This check runs even if the user skips re-run.
+
+Prompt user: (1) Re-run baseline now (recommended), (2) Skip and rely on implementation results.
+
+**If re-run:** Read `metadata.baseline_mode`, `metadata.capture_target`, `metadata.capture_base_url`, `dev_environment.frontend.port`, `dev_environment.backend.port`, `baseline_settings.iterations` from `performance-config.json`. Use same capture mode as original baseline.
+
+Copy `capture-baseline.template.mjs` from plugin cache to baseline directory (always fresh copy).
+
+**Frontend/hybrid:** Read `capture_target` (null/missing → `localhost`).
+- **`localhost`:** use `--port` from `dev_environment.frontend.port`
+- **`hosted`:** read `capture_base_url` (halt if null/empty — "Re-run `/sdlc-workflow:performance-baseline` or `perf-config.py set metadata.capture_base_url <url>`."). Prompt for auth (`--storage-state` or `--user`/`--pass`) and `--insecure`.
+
+Construct command mirroring performance-baseline Step 9.3 — absolute `--config` path, auth flag mutual exclusivity, `BASELINE_PASS` env var. Playwright leg follows `capture_target`; backend leg always uses `perf-benchmark.sh` + `dev_environment.backend.port`.
+
+Verification failed → display script diagnostics, halt. Do not retry.
+
+**Backend/hybrid:** Use `perf-benchmark.sh`:
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1)
+"$plugin_root/scripts/perf-benchmark.sh" \
+  --port "$(python3 "$plugin_root/scripts/perf-config.py" get dev_environment.backend.port)" \
+  --iterations "$(python3 "$plugin_root/scripts/perf-config.py" get baseline_settings.iterations)" \
+  --manifest performance/test-data/manifest.json \
+  --output "$(python3 "$plugin_root/scripts/perf-config.py" get directories.verification)/benchmark-results-verify.json"
+```
+
+Compare re-run results against implementation results.
+
+**Drift thresholds (both gates must be exceeded to flag):**
+
+Check CONVENTIONS.md first — if it defines a "Performance Thresholds" or "Regression Limits" section with custom thresholds (extracted in Step 4b), use those values. Otherwise use these defaults:
+
+| Category | Relative | Absolute |
+|---|---|---|
+| Frontend time | >5% | >50ms |
+| Frontend size | >5% | >10KB |
+| Backend response time | >10% | >50ms |
+| Backend throughput | >20% decrease | — |
+| Backend error rate | — | >1% increase |
+
+If significant drift found, flag for investigation with a comparison table. Record findings for report.
+
+## Step 4.7 – Validate Target Achievement (Performance Tasks Only)
+
+**If `task_type = standard`:** Skip to Step 5.
+
+Evaluate ONLY the metrics listed in the task's **Target Metrics** section. Metrics not listed in the task are not evaluated — they belong to other tasks in the same Epic.
+
+Compare current metrics (from Step 4.5 or 4.6) against the listed target metrics from the Jira task.
+
+**Check for acknowledged regression:** If the optimization result report (Step 4.5) has `status: regression_acknowledged`, classify as **Partial Success** (WARN), not Regression (FAIL). Note in details: "Regression was acknowledged during implementation — see regression report for context."
+
+- **Full Success:** All listed targets met → PASS
+- **Partial Success:** Progress toward target >20% (calculated as `(baseline - current) / (baseline - target) × 100`) but not all targets met → WARN
+- **Insufficient Improvement:** Progress <20% and targets not met → FAIL
+- **Regression:** Any listed metric worse than baseline (and NOT `regression_acknowledged`) → FAIL
+
+## Step 4.8 – Migration Safety Verification (Database Migration Tasks Only)
+
+**If `task_type` is not `db-migration`:** Skip to Step 5.
+
+**Scope:** Code-level verification only — DDL inspection, convention compliance, intent comparison. Live database execution (EXPLAIN, running migrations) is out of scope. Manual verification SQL in the task description is for the developer to run independently.
+
+### Step 4.8.1 – Identify Migration Files
+
+Filter the PR diff for migration files matching known framework path patterns:
+- `migration/src/m*.rs` (SeaORM)
+- `migrations/*/up.sql`, `migrations/*/down.sql` (Diesel)
+- `migrations/*.sql` (sqlx)
+- `alembic/versions/*.py` (Alembic)
+- `**/migrations/*.py` (Django)
+- `src/main/resources/db/migration/V*__*.sql` (Flyway)
+- `prisma/migrations/*/migration.sql` (Prisma)
+- `src/migration/*-*.ts` (TypeORM)
+
+If no migration files found in the diff, record "Migration Safety: N/A — no migration files in diff" and proceed.
+
+### Step 4.8.2 – Destructive DDL Scan
+
+For each migration file, scan for destructive operations:
+
+| Pattern | Result |
+|---|---|
+| `DROP TABLE`, `DROP COLUMN`, `DELETE FROM`, `TRUNCATE` | FAIL — blocks merge |
+| `ALTER COLUMN ... DROP NOT NULL`, `ALTER COLUMN ... TYPE` | WARN — flag for review |
+| `CREATE INDEX` without `CONCURRENTLY` | PASS — framework migrations run in transactions where CONCURRENTLY is invalid. Informational note: "For manual production rollout, use CONCURRENTLY." |
+| `CREATE INDEX CONCURRENTLY` | PASS |
+| `DROP INDEX` in rollback/down migration only | PASS |
+
+### Step 4.8.3 – Verify Rollback Exists
+
+Check that each migration has a corresponding rollback:
+- SeaORM: `down()` method in the migration struct
+- Diesel: `down.sql` alongside `up.sql`
+- Alembic: `downgrade()` function
+- Flyway: WARN — Flyway does not natively support rollback
+- TypeORM: `down()` method
+- Django: auto-generated rollback (PASS unless manual migration)
+
+### Step 4.8.4 – DDL Intent Comparison
+
+If the task description contains a **Database Migration** section with **Before/After SQL**, compare the planned DDL operations against the actual PR diff. Compare **intent** — what DDL operations are performed (create index on which table/column, rewrite which query) — not verbatim SQL, since implement-task may adapt scripts per CONVENTIONS.md.
+
+### Step 4.8.5 – CONVENTIONS.md Compliance
+
+Read CONVENTIONS.md migration-related sections. Verify:
+- Migration file naming matches documented convention
+- Index naming follows documented pattern
+- Migration structure matches established patterns (scan 2-3 existing migrations as reference)
+- FK index policy compliance if documented
+
+Flag convention violations as code change requests (same upgrade behavior as the Style/Conventions sub-agent — e.g., "N migrations use X pattern; CONVENTIONS.md §Y documents this").
+
+### Step 4.8 Verdict
+
+Record overall Migration Safety result:
+- **PASS**: No destructive DDL, rollback exists, conventions followed
+- **WARN**: Non-blocking issues (Flyway rollback, non-CONCURRENTLY index)
+- **FAIL**: Destructive DDL detected — blocks merge
+
 ## Step 5 – Dispatch Domain Sub-Agents
 
 Dispatch four domain sub-agents in parallel for comprehensive PR analysis. Each
@@ -912,6 +1064,10 @@ are assembled from sub-agent results (Step 6a) and orchestrator checks (Steps 6g
 | Test Quality | PASS/WARN/N/A | <summary> |
 | Test Change Classification | ADDITIVE/REDUCTIVE/MIXED/NEUTRAL/N/A | <summary> |
 | Verification Commands | PASS/FAIL/N/A | <summary> |
+| Target Achievement | PASS/WARN/FAIL/N/A | <performance tasks only> |
+| Environment Match | MATCH/MISMATCH/N/A | <performance tasks only> |
+| Baseline Re-run | PASS/WARN/SKIPPED/N/A | <performance tasks only> |
+| Migration Safety | PASS/WARN/FAIL/N/A | <db-migration tasks only> |
 
 ### Overall: PASS / WARN / FAIL
 
@@ -933,6 +1089,13 @@ are assembled from sub-agent results (Step 6a) and orchestrator checks (Steps 6g
 | Test Quality | Style/Conventions sub-agent (Repetitive Test Detection + Test Documentation + Eval Quality combined) |
 | Test Change Classification | Style/Conventions sub-agent |
 | Verification Commands | Correctness sub-agent |
+| Target Achievement | Orchestrator (Step 4.7) — N/A for standard tasks |
+| Environment Match | Orchestrator (Step 4.6) — N/A for standard tasks |
+| Baseline Re-run | Orchestrator (Step 4.6) — N/A for standard tasks |
+
+**Performance tasks (`task_type = performance`):** Additionally include a "Performance Results" section after the report table with the before/after comparison table from Step 4.5/4.6, achievement status from Step 4.7, and recommendations.
+
+**Performance report affects Overall:** Target Achievement PASS/WARN/FAIL counts toward Overall result. Baseline Re-run and Environment Match are informational (do not affect Overall). Environment MISMATCH skips numeric drift thresholds — note "metrics not comparable" in the Baseline Re-run details.
 
 When eval results are present (Eval Quality is not N/A), include the eval pass
 rate and any failing assertion details in the Test Quality Details column of
@@ -1000,6 +1163,39 @@ Include the Comment Footnote at the end of the Jira comment.
 **Important:** This skill does NOT merge the PR and does NOT transition the Jira issue.
 The report is informational — a human reviewer decides whether to merge.
 
+## Step 10 – Update Optimization Result Report (Performance Tasks Only)
+
+**If `task_type = standard`:** Skip this step.
+
+If the optimization result report was found in Step 4.5, update it with verification results.
+
+### Step 10.1 – Determine Status
+
+Map Overall Result: PASS → `verified`, WARN (partial success) → `verified_with_warnings`, FAIL → `verification_failed`.
+
+### Step 10.2 – Update Report Metadata
+
+Confirm `report_file` exists. Update metadata frontmatter: set `status`, `verification_timestamp`, `verification_result`.
+
+### Step 10.3 – Append Verification Section
+
+Append to report: Verification Results section with timestamp, overall result, acceptance criteria summary, review feedback summary, CI status, target achievement, and recommendations.
+
+### Step 10.4 – Update Latest Metrics in Config
+
+**Only when** Overall Result is PASS or WARN (confirmed improvement). Skip on FAIL.
+
+Use `perf-config.py set` to update `.latest` fields for each metric based on `metric_type`:
+- Frontend/hybrid: lcp, fcp, dom_interactive, total_load_time
+- Backend/hybrid: response_time_p95, response_time_p99, throughput, error_rate
+- Always: `metadata.last_updated` to current UTC timestamp
+
+Plugin root resolution for bash blocks:
+```bash
+plugin_root=$(ls -d "${HOME}/.claude/plugins/cache/"*/sdlc-workflow/*/ 2>/dev/null | sort -V | tail -1)
+if [ -z "$plugin_root" ] || [ ! -d "$plugin_root" ]; then echo "❌ sdlc-workflow plugin not found"; exit 1; fi
+```
+
 ## Important Rules
 
 - This skill does **NOT** modify code. It only verifies, creates sub-tasks, and reports.