@codyswann/lisa 1.81.6 → 1.82.0

package/package.json

@@ -76,7 +76,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/agents/architecture-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: architecture-specialist
 description: Architecture specialist agent. Designs implementation approaches, traces data flow, identifies files to modify, maps dependencies, finds reusable code, evaluates design patterns, and flags breaking changes.
-tools: Read, Grep, Glob, Bash
 skills:
   - codebase-research
   - task-decomposition

package/plugins/lisa/agents/bug-fixer.md

@@ -1,7 +1,6 @@
 ---
 name: bug-fixer
 description: Bug fix agent. Reproduces bugs as failing tests, implements fixes via TDD, and verifies the fix resolves the issue without introducing regressions.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - bug-triage
   - tdd-implementation

package/plugins/lisa/agents/builder.md

@@ -1,7 +1,6 @@
 ---
 name: builder
 description: Feature build agent. Translates acceptance criteria into tests, implements features via TDD, and verifies all criteria are met.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - task-triage
   - tdd-implementation

package/plugins/lisa/agents/debug-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: debug-specialist
 description: Debug specialist agent. Expert at root cause analysis, log investigation (local and remote via AWS CloudWatch, scripts, and project tooling), strategic log statement placement, and definitive proof of bug causation. Finds what is causing the problem without a doubt.
-tools: Read, Grep, Glob, Bash
 skills:
   - reproduce-bug
   - root-cause-analysis

package/plugins/lisa/agents/git-history-analyzer.md

@@ -1,7 +1,6 @@
 ---
 name: git-history-analyzer
 description: Analyzes git commit history and pull request context to document the decision-making process behind file changes. Use when you need to understand why and how files evolved over time.
-tools: Read, Grep, Glob, Bash
 ---
 
 You are a git history documentarian specializing in extracting and organizing historical context from version control systems.

package/plugins/lisa/agents/jira-agent.md

@@ -1,7 +1,6 @@
 ---
 name: jira-agent
 description: JIRA lifecycle agent. Reads tickets, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion.
-tools: Read, Grep, Glob, Bash, Agent
 skills:
   - jira-sync
   - jira-evidence

package/plugins/lisa/agents/learner.md

@@ -1,7 +1,6 @@
 ---
 name: learner
 description: Post-implementation learning agent. Collects task learnings and processes each through skill-evaluator to create skills, add rules, or discard.
-tools: Read, Write, Edit, Grep, Glob, Bash, Skill, Agent, TaskList, TaskGet
 ---
 
 # Learner Agent

package/plugins/lisa/agents/performance-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: performance-specialist
 description: Performance specialist agent. Identifies N+1 queries, inefficient algorithms, memory leaks, missing indexes, unnecessary re-renders, bundle size issues, and other software performance problems. Recommends optimizations with evidence.
-tools: Read, Grep, Glob, Bash
 skills:
   - performance-review
 ---

package/plugins/lisa/agents/product-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: product-specialist
 description: Product/UX specialist agent. Defines user flows in Gherkin, writes acceptance criteria from user perspective, identifies UX concerns and error states, and empirically verifies behavior matches requirements.
-tools: Read, Grep, Glob, Bash
 skills:
   - acceptance-criteria
 ---

package/plugins/lisa/agents/quality-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: quality-specialist
 description: Code quality specialist agent. Reviews correctness, coding philosophy compliance (immutability, function structure), test coverage, and documentation. Explains findings in beginner-friendly plain English, ranked by severity.
-tools: Read, Grep, Glob, Bash
 skills:
   - quality-review
 ---

package/plugins/lisa/agents/security-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: security-specialist
 description: Security specialist agent. Performs threat modeling (STRIDE), reviews code for OWASP Top 10 vulnerabilities, checks auth/validation/secrets handling, and recommends mitigations.
-tools: Read, Grep, Glob, Bash
 skills:
   - security-review
   - security-zap-scan

package/plugins/lisa/agents/skill-evaluator.md

@@ -1,7 +1,6 @@
 ---
 name: skill-evaluator
 description: Evaluates instructions, rules, patterns, and knowledge to determine if they warrant creating a new skill. Use when discovering reusable patterns, receiving new guidelines, or identifying knowledge that could benefit future sessions. This agent decides whether content is broad and reusable enough to justify skill creation.
-tools: Read, Grep, Glob, Skill
 ---
 
 # Skill Evaluator Agent

package/plugins/lisa/agents/test-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: test-specialist
 description: Test specialist agent. Designs test strategy (matrix, edge cases, coverage targets, TDD sequence), writes comprehensive unit and integration tests, and reviews test quality. Tests behavior, not implementation details.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - test-strategy
 ---

package/plugins/lisa/agents/verification-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: verification-specialist
 description: Verification specialist agent. Discovers project tooling and executes verification for all required types. Plans and executes empirical proof that work is done by running the actual system and observing results.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - verification-lifecycle
   - jira-journey

package/plugins/lisa/rules/intent-routing.md

@@ -13,7 +13,12 @@ This protocol runs **once per session**, on the first user message. After that,
 3. If you cannot confidently classify the request:
    - **Interactive session** (user is present): present a multiple choice using AskUserQuestion with options: Research, Plan, Implement, Verify, No flow.
    - **Headless/non-interactive session** (running with `-p` flag, in a CI pipeline, or as a scheduled agent): do NOT ask the user. Classify to the best of your ability from available context (ticket content, prompt text, current branch state). If you truly cannot classify, default to "No flow" and proceed with the request as-is.
-4. Once a flow is selected, state it explicitly (e.g., *"Flow: Implement/Fix"*) and check its readiness gate before proceeding.
+4. Once a flow is selected, **echo it back explicitly** before doing anything else. State the flow, the work type (if applicable), and a one-sentence justification for why this flow was chosen. Example:
+
+   > **Flow: Implement/Fix**
+   > This is a bug report with a specific error and reproduction steps, so it routes to the Fix work type within the Implement flow.
+
+   This echo is mandatory. Do not skip it, abbreviate it, or bury it in other output. The user must see the flow classification before any work begins.
 5. If you are a subagent: your parent agent has already determined the flow -- do NOT ask the user to choose a flow. Execute your assigned work within the established flow context.
 
 ## Readiness Gate Protocol
@@ -45,9 +50,10 @@ Sequence:
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
 4. Synthesize findings into a PRD document containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
-5. `learner` -- capture discoveries for future sessions
+5. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
+6. `learner` -- capture discoveries for future sessions
 
-Output: A PRD document. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
+Output: A PRD document that includes a "Recommended Tooling for Plan Phase" section listing the skills and agents the Plan phase should use. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
 
 ### Plan
 
@@ -63,16 +69,17 @@ Sequence:
 1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
 2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
 3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
-4. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
+4. **Implement/Verify Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Implement and Verify phases will need for each work item. For each recommended skill or agent, state why it is needed and which work items it applies to. If no skills or agents beyond the defaults are identified for a work item, explicitly justify why the standard set is sufficient.
+5. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
    - Type (epic, story, task, spike, bug)
    - Acceptance criteria
    - Verification method
    - Dependencies
-   - Skills required
-5. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria and dependencies
-6. `learner` -- capture discoveries for future sessions
+   - Skills and agents required (from step 4)
+6. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria, dependencies, and recommended skills/agents
+7. `learner` -- capture discoveries for future sessions
 
-Output: Work items in a tracker with acceptance criteria, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
+Output: Work items in a tracker with acceptance criteria and recommended skills/agents, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
 
 ### Implement
 
@@ -93,7 +100,7 @@ Determine the work type and execute the matching variant:
 3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
 4. `test-specialist` -- design test strategy (coverage, edge cases, TDD sequence)
 5. `builder` -- implement via TDD (acceptance criteria become tests)
-6. Run validation: lint, typecheck, tests
+6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 7. `verification-specialist` -- verify locally (run the software, observe behavior)
 8. Write e2e test encoding the verification
 9. **Review sub-flow**
@@ -107,7 +114,7 @@ Determine the work type and execute the matching variant:
 4. `architecture-specialist` -- assess fix risk, identify files to change, check for ripple effects
 5. `test-specialist` -- design regression test strategy
 6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
-7. Run validation: lint, typecheck, tests
+7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 8. `verification-specialist` -- verify locally (prove the bug is fixed)
 9. Write e2e test encoding the verification
 10. **Review sub-flow**
@@ -119,7 +126,7 @@ Determine the work type and execute the matching variant:
 2. `architecture-specialist` -- identify target, plan approach
 3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)
 4. `builder` -- implement improvements via TDD
-5. Run validation: lint, typecheck, tests
+5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 6. `verification-specialist` -- measure again, prove improvement over baseline
 7. Write e2e test encoding the verification (if applicable)
 8. **Review sub-flow**
@@ -132,16 +139,16 @@ Determine the work type and execute the matching variant:
 3. Recommend next action (Research, Plan, Implement, or escalate)
 4. `learner` -- capture discoveries
 
-Output: Code passing all validation + local empirical verification + e2e test (except for spikes, which produce findings only).
+Output: Code passing all quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
 
 ### Verify
 
-When: Code is ready to ship. All local validation passes. Moving from "works on my machine" to "works in production".
+When: Code is ready to ship. All quality gates pass and local empirical verification is complete. Moving from "works on my machine" to "works in production".
 
 Gate:
-- Code must pass local validation (lint, typecheck, tests)
+- Code must pass quality gates (lint, typecheck, tests)
 - Local empirical verification must be complete
-- If local validation fails, go back to **Implement**
+- If quality gates fail, go back to **Implement**
 - If no code changes exist, there is nothing to verify
 
 Sequence:

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "1.81.6",
+  "version": "1.82.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/agents/architecture-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: architecture-specialist
 description: Architecture specialist agent. Designs implementation approaches, traces data flow, identifies files to modify, maps dependencies, finds reusable code, evaluates design patterns, and flags breaking changes.
-tools: Read, Grep, Glob, Bash
 skills:
   - codebase-research
   - task-decomposition

package/plugins/src/base/agents/bug-fixer.md

@@ -1,7 +1,6 @@
 ---
 name: bug-fixer
 description: Bug fix agent. Reproduces bugs as failing tests, implements fixes via TDD, and verifies the fix resolves the issue without introducing regressions.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - bug-triage
   - tdd-implementation

package/plugins/src/base/agents/builder.md

@@ -1,7 +1,6 @@
 ---
 name: builder
 description: Feature build agent. Translates acceptance criteria into tests, implements features via TDD, and verifies all criteria are met.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - task-triage
   - tdd-implementation

package/plugins/src/base/agents/debug-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: debug-specialist
 description: Debug specialist agent. Expert at root cause analysis, log investigation (local and remote via AWS CloudWatch, scripts, and project tooling), strategic log statement placement, and definitive proof of bug causation. Finds what is causing the problem without a doubt.
-tools: Read, Grep, Glob, Bash
 skills:
   - reproduce-bug
   - root-cause-analysis

package/plugins/src/base/agents/git-history-analyzer.md

@@ -1,7 +1,6 @@
 ---
 name: git-history-analyzer
 description: Analyzes git commit history and pull request context to document the decision-making process behind file changes. Use when you need to understand why and how files evolved over time.
-tools: Read, Grep, Glob, Bash
 ---
 
 You are a git history documentarian specializing in extracting and organizing historical context from version control systems.

package/plugins/src/base/agents/jira-agent.md

@@ -1,7 +1,6 @@
 ---
 name: jira-agent
 description: JIRA lifecycle agent. Reads tickets, determines intent (Bug → Implement/Fix, Story/Task → Implement/Build, Epic → Plan, Spike → Implement/Investigate), delegates to the appropriate flow, syncs progress at milestones, and posts evidence at completion.
-tools: Read, Grep, Glob, Bash, Agent
 skills:
   - jira-sync
   - jira-evidence

package/plugins/src/base/agents/learner.md

@@ -1,7 +1,6 @@
 ---
 name: learner
 description: Post-implementation learning agent. Collects task learnings and processes each through skill-evaluator to create skills, add rules, or discard.
-tools: Read, Write, Edit, Grep, Glob, Bash, Skill, Agent, TaskList, TaskGet
 ---
 
 # Learner Agent

package/plugins/src/base/agents/performance-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: performance-specialist
 description: Performance specialist agent. Identifies N+1 queries, inefficient algorithms, memory leaks, missing indexes, unnecessary re-renders, bundle size issues, and other software performance problems. Recommends optimizations with evidence.
-tools: Read, Grep, Glob, Bash
 skills:
   - performance-review
 ---

package/plugins/src/base/agents/product-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: product-specialist
 description: Product/UX specialist agent. Defines user flows in Gherkin, writes acceptance criteria from user perspective, identifies UX concerns and error states, and empirically verifies behavior matches requirements.
-tools: Read, Grep, Glob, Bash
 skills:
   - acceptance-criteria
 ---

package/plugins/src/base/agents/quality-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: quality-specialist
 description: Code quality specialist agent. Reviews correctness, coding philosophy compliance (immutability, function structure), test coverage, and documentation. Explains findings in beginner-friendly plain English, ranked by severity.
-tools: Read, Grep, Glob, Bash
 skills:
   - quality-review
 ---

package/plugins/src/base/agents/security-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: security-specialist
 description: Security specialist agent. Performs threat modeling (STRIDE), reviews code for OWASP Top 10 vulnerabilities, checks auth/validation/secrets handling, and recommends mitigations.
-tools: Read, Grep, Glob, Bash
 skills:
   - security-review
   - security-zap-scan

package/plugins/src/base/agents/skill-evaluator.md

@@ -1,7 +1,6 @@
 ---
 name: skill-evaluator
 description: Evaluates instructions, rules, patterns, and knowledge to determine if they warrant creating a new skill. Use when discovering reusable patterns, receiving new guidelines, or identifying knowledge that could benefit future sessions. This agent decides whether content is broad and reusable enough to justify skill creation.
-tools: Read, Grep, Glob, Skill
 ---
 
 # Skill Evaluator Agent

package/plugins/src/base/agents/test-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: test-specialist
 description: Test specialist agent. Designs test strategy (matrix, edge cases, coverage targets, TDD sequence), writes comprehensive unit and integration tests, and reviews test quality. Tests behavior, not implementation details.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - test-strategy
 ---

package/plugins/src/base/agents/verification-specialist.md

@@ -1,7 +1,6 @@
 ---
 name: verification-specialist
 description: Verification specialist agent. Discovers project tooling and executes verification for all required types. Plans and executes empirical proof that work is done by running the actual system and observing results.
-tools: Read, Write, Edit, Bash, Grep, Glob
 skills:
   - verification-lifecycle
   - jira-journey

package/plugins/src/base/rules/intent-routing.md

@@ -13,7 +13,12 @@ This protocol runs **once per session**, on the first user message. After that,
 3. If you cannot confidently classify the request:
    - **Interactive session** (user is present): present a multiple choice using AskUserQuestion with options: Research, Plan, Implement, Verify, No flow.
    - **Headless/non-interactive session** (running with `-p` flag, in a CI pipeline, or as a scheduled agent): do NOT ask the user. Classify to the best of your ability from available context (ticket content, prompt text, current branch state). If you truly cannot classify, default to "No flow" and proceed with the request as-is.
-4. Once a flow is selected, state it explicitly (e.g., *"Flow: Implement/Fix"*) and check its readiness gate before proceeding.
+4. Once a flow is selected, **echo it back explicitly** before doing anything else. State the flow, the work type (if applicable), and a one-sentence justification for why this flow was chosen. Example:
+
+   > **Flow: Implement/Fix**
+   > This is a bug report with a specific error and reproduction steps, so it routes to the Fix work type within the Implement flow.
+
+   This echo is mandatory. Do not skip it, abbreviate it, or bury it in other output. The user must see the flow classification before any work begins.
 5. If you are a subagent: your parent agent has already determined the flow -- do NOT ask the user to choose a flow. Execute your assigned work within the established flow context.
 
 ## Readiness Gate Protocol
@@ -45,9 +50,10 @@ Sequence:
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
 4. Synthesize findings into a PRD document containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
-5. `learner` -- capture discoveries for future sessions
+5. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
+6. `learner` -- capture discoveries for future sessions
 
-Output: A PRD document. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
+Output: A PRD document that includes a "Recommended Tooling for Plan Phase" section listing the skills and agents the Plan phase should use. If there is not enough context to produce a complete PRD, stop and report what is missing rather than producing an incomplete one.
 
 ### Plan
 
@@ -63,16 +69,17 @@ Sequence:
 1. **Investigate sub-flow** -- explore codebase for architecture, patterns, dependencies relevant to the spec
 2. `product-specialist` -- validate and refine acceptance criteria for the whole scope
 3. `architecture-specialist` -- map dependencies, identify cross-cutting concerns, determine execution order
-4. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
+4. **Implement/Verify Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Implement and Verify phases will need for each work item. For each recommended skill or agent, state why it is needed and which work items it applies to. If no skills or agents beyond the defaults are identified for a work item, explicitly justify why the standard set is sufficient.
+5. Decompose into ordered work items (epics, stories, tasks, spikes, bugs), each with:
    - Type (epic, story, task, spike, bug)
    - Acceptance criteria
    - Verification method
    - Dependencies
-   - Skills required
-5. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria and dependencies
-6. `learner` -- capture discoveries for future sessions
+   - Skills and agents required (from step 4)
+6. Create work items in the tracker (JIRA, Linear, GitHub) with acceptance criteria, dependencies, and recommended skills/agents
+7. `learner` -- capture discoveries for future sessions
 
-Output: Work items in a tracker with acceptance criteria, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
+Output: Work items in a tracker with acceptance criteria and recommended skills/agents, ordered by dependency. If the specification cannot be decomposed without further clarification, stop and report what is missing.
 
 ### Implement
 
@@ -93,7 +100,7 @@ Determine the work type and execute the matching variant:
 3. `architecture-specialist` -- design approach, map files to modify, identify reusable code
 4. `test-specialist` -- design test strategy (coverage, edge cases, TDD sequence)
 5. `builder` -- implement via TDD (acceptance criteria become tests)
-6. Run validation: lint, typecheck, tests
+6. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 7. `verification-specialist` -- verify locally (run the software, observe behavior)
 8. Write e2e test encoding the verification
 9. **Review sub-flow**
@@ -107,7 +114,7 @@ Determine the work type and execute the matching variant:
 4. `architecture-specialist` -- assess fix risk, identify files to change, check for ripple effects
 5. `test-specialist` -- design regression test strategy
 6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
-7. Run validation: lint, typecheck, tests
+7. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 8. `verification-specialist` -- verify locally (prove the bug is fixed)
 9. Write e2e test encoding the verification
 10. **Review sub-flow**
@@ -119,7 +126,7 @@ Determine the work type and execute the matching variant:
 2. `architecture-specialist` -- identify target, plan approach
 3. `test-specialist` -- ensure existing test coverage before refactoring (safety net)
 4. `builder` -- implement improvements via TDD
-5. Run validation: lint, typecheck, tests
+5. Run quality gates: lint, typecheck, tests (these are prerequisites, NOT verification)
 6. `verification-specialist` -- measure again, prove improvement over baseline
 7. Write e2e test encoding the verification (if applicable)
 8. **Review sub-flow**
@@ -132,16 +139,16 @@ Determine the work type and execute the matching variant:
 3. Recommend next action (Research, Plan, Implement, or escalate)
 4. `learner` -- capture discoveries
 
-Output: Code passing all validation + local empirical verification + e2e test (except for spikes, which produce findings only).
+Output: Code passing all quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
 
 ### Verify
 
-When: Code is ready to ship. All local validation passes. Moving from "works on my machine" to "works in production".
+When: Code is ready to ship. All quality gates pass and local empirical verification is complete. Moving from "works on my machine" to "works in production".
 
 Gate:
-- Code must pass local validation (lint, typecheck, tests)
+- Code must pass quality gates (lint, typecheck, tests)
 - Local empirical verification must be complete
-- If local validation fails, go back to **Implement**
+- If quality gates fail, go back to **Implement**
 - If no code changes exist, there is nothing to verify
 
 Sequence: