@codyswann/lisa 1.81.4 → 1.81.5

package/package.json

@@ -76,7 +76,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "1.81.4",
+  "version": "1.81.5",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -182,7 +182,7 @@
     "vitest": "^4.1.0"
   },
   "devDependencies": {
-    "@codyswann/lisa": "^1.81.0",
+    "@codyswann/lisa": "^1.81.3",
     "vite": "^8.0.5"
   },
   "type": "module"

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

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

package/plugins/lisa/agents/builder.md

@@ -26,7 +26,7 @@ If any of these are missing, ask the team for them before proceeding.
 1. **Write failing tests** — translate each acceptance criterion into one or more tests. This is your RED phase. Tests define the contract before any implementation exists.
 2. **Implement** — write the minimum code to make each test pass, one at a time. This is your GREEN phase.
 3. **Refactor** — clean up while keeping all tests green. Follow existing patterns identified in the architecture plan.
-4. **Run full verification** — run the proof command. Verify every acceptance criterion is met.
+4. **Run quality checks** — run tests, typecheck, and lint. These are quality gates (prerequisites), NOT verification. Empirical verification (running the actual system) is done separately by the `verification-specialist`.
 5. **Update documentation** — add/update JSDoc preambles explaining the "why" behind each new piece of code.
 6. **Commit atomically** — use the `/git-commit` skill. Group related changes into logical commits.
 
@@ -38,4 +38,4 @@ If any of these are missing, ask the team for them before proceeding.
 - One task at a time — complete the current task before moving on
 - If you discover a gap in the acceptance criteria, ask the team — don't guess
 - If a dependency is missing (API not built, schema not migrated), report it as a blocker
-- Never mark the task complete without running the proof command
+- Never mark the task complete without running quality checks (tests, typecheck, lint). Note: this is NOT verification — empirical verification is handled by the `verification-specialist`

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

@@ -15,17 +15,21 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 ## Core Philosophy
 
-**"If you didn't run it, you didn't verify it."** Code review is not verification. Reading a test file is not verification. Only executing the system and observing output counts as proof.
+**"If you didn't run it, you didn't verify it."** Code review is not verification. Reading a test file is not verification. **Running tests, typecheck, and lint is not verification either — those are quality gates (prerequisites).** Only executing the actual system and observing output counts as proof. Verification means making HTTP requests, clicking through the UI, running CLI commands, querying the database, or otherwise interacting with the running software as an end user would.
 
 ## Verification Process
 
-Follow the verification lifecycle: **classify, check tooling, fail fast, plan, execute, loop.**
+Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, loop.**
 
-### 1. Classify
+### 1. Confirm Quality Gates
 
-Read `.claude/rules/verification.md` to determine which verification types apply to the current change. Start with the three always-required types (Test, Type Safety, Lint/Format), then check each conditional type against the change scope.
+Confirm that quality gates (tests, typecheck, lint, format) pass. These are prerequisites — if they fail, fix them first. But passing quality gates does NOT mean the change is verified.
 
-### 2. Discover Available Tools
+### 2. Classify
+
+Read `.claude/rules/verification.md` to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
+
+### 3. Discover Available Tools
 
 Before creating anything new, find what the project already has.
 
@@ -46,7 +50,7 @@ Before creating anything new, find what the project already has.
 **MCP tools:**
 - Check available MCP server tools for browser automation, observability, issue tracking, and other capabilities
 
-### 3. Plan the Verification
+### 4. Plan the Verification
 
 For each required verification type, determine:
 
@@ -61,7 +65,7 @@ For each required verification type, determine:
 
 If any required verification type has no available tool and no reasonable alternative, escalate immediately.
 
-### 4. Execute and Report
+### 5. Execute and Report
 
 Run the verification and capture output. Always include:
 
@@ -113,7 +117,8 @@ If any verification fails, fix and re-verify. Do not declare done until all requ
 ## Rules
 
 - Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
-- Follow the verification lifecycle: classify, check tooling, fail fast, plan, execute, loop
+- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, loop
+- Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
 - Discover existing project scripts and tools before creating new ones
 - Every verification must produce observable output -- a status code, a response body, a UI state, a test result
 - Verification scripts must be runnable locally without CI/CD dependencies

package/plugins/lisa/rules/verification.md

@@ -16,11 +16,13 @@ No agent may claim success without evidence from runtime verification.
 
 Never assume something works because the code "looks correct." Run a command, observe the output, compare to expected result.
 
-**Verification is not linting, typechecking, or testing.** Those are quality checks. Verification is using the resulting software the way a user would — interacting with the UI, calling the API, running the CLI command, observing the behavior. Tests pass in isolation; verification proves the system works as a whole. Passing tests, linting, and typechecking does not constitute verification.
+**Verification is not linting, typechecking, or testing.** Those are **quality checks** — prerequisites that must pass before verification begins, but they are NOT verification themselves. Running `bun run test`, `bun run typecheck`, `bun run lint`, or `bun run format` is a quality check. Verification is using the resulting software the way a user would — interacting with the UI, calling the API, running the CLI command, observing the behavior. Tests pass in isolation; verification proves the system works as a whole.
+
+**If all you did was run tests, typecheck, and lint — you have NOT verified.** You have only confirmed quality checks pass. Verification requires running the actual system and observing the results: making HTTP requests, clicking through the UI, executing CLI commands, querying the database, or otherwise interacting with the running software as an end user would.
 
 Verification is mandatory. Never skip it, defer it, or claim it was unnecessary. Every task must be verified before claiming completion.
 
-Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. Do not begin implementation until the plan is confirmed.
+Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. A verification plan that only lists test/typecheck/lint commands is not a verification plan. Do not begin implementation until the plan is confirmed.
 
 After verifying a change empirically, encode that verification as automated tests. The manual proof that something works should become a repeatable regression test that catches future regressions. Every verification should answer: "How do I turn this into a test?"
 
@@ -56,19 +58,23 @@ Agents must label every task outcome with exactly one of these:
 
 ---
 
-## Verification Types
-
-Every change requires one or more verification types. Classify the change first, then verify each applicable type.
+## Quality Gates (Prerequisites)
 
-### Always Required
+These are NOT verification. They are prerequisites that must pass before verification begins. Running these does not constitute verification — it only confirms code quality.
 
-| Type | What to prove | Acceptable proof |
+| Gate | What to prove | Acceptable proof |
 |------|---------------|------------------|
 | **Test** | Unit and integration tests pass for all changed code paths | Test runner output showing all relevant tests green with no skips |
 | **Type Safety** | No type errors introduced by the change | Type checker exits clean on the full project |
 | **Lint/Format** | Code meets project style and quality rules | Linter and formatter exit clean on changed files |
 
-### Conditional
+Quality gates are enforced automatically by the self-correction loop (hooks, pre-commit, pre-push). Passing all quality gates is necessary but NOT sufficient — you must still verify empirically.
+
+---
+
+## Verification Types
+
+Every change requires one or more verification types. Classify the change first, then verify each applicable type by **running the actual system and observing results**.
 
 | Type | When it applies | What to prove | Acceptable proof |
 |------|----------------|---------------|------------------|
@@ -94,7 +100,8 @@ Every change requires one or more verification types. Classify the change first,
 
 Verification happens at two stages in the workflow:
 
-- **Local verification** (part of the Implement flow): Run the full test suite, typecheck, lint, and empirically verify the change in a local or preview environment. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
+- **Quality gates** (enforced automatically): Tests, typecheck, lint, and format run via hooks at write-time, commit-time, and push-time. These are prerequisites, not verification.
+- **Local verification** (part of the Implement flow): After quality gates pass, empirically verify the change by running the actual system in a local or preview environment — make HTTP requests, interact with the UI, execute CLI commands, query the database. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
 - **Remote verification** (part of the Verify flow): After the PR is merged and deployed, repeat the same empirical verification against the target environment. This proves the change works in production, not just locally. If remote verification fails, fix and re-deploy.
 
 Both levels use the same verification types table above. The difference is the environment, not the rigor.

package/plugins/lisa/skills/plan-execute/SKILL.md

@@ -77,9 +77,9 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "skills": ["..."],
   "learnings": ["..."],
   "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
+    "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
+    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
+    "expected": "what success looks like — observable system behavior"
   }
 }
 ```
@@ -91,8 +91,8 @@ Each task must have their learnings reviewed by the learner subagent.
 
 Before shutting down the team, execute the Verify flow:
 
-1. Run local validation: lint, typecheck, tests — all must pass
-2. `verification-specialist`: verify locally (empirical proof that the change works)
+1. Run quality gates: lint, typecheck, tests — all must pass. These are prerequisites, NOT verification.
+2. `verification-specialist`: verify locally by running the actual system and observing results (empirical proof that the change works). This is the real verification step.
 3. Write e2e test encoding the verification
 4. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
 5. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not

package/plugins/lisa/skills/tdd-implementation/SKILL.md

@@ -21,9 +21,9 @@ Each task you work on must have the following in its metadata:
   "skills": ["..."],
   "learnings": ["..."],
   "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
+    "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
+    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
+    "expected": "what success looks like — observable system behavior"
   }
 }
 ```

package/plugins/lisa/skills/verification-lifecycle/SKILL.md

@@ -1,42 +1,48 @@
 ---
 name: verification-lifecycle
-description: "Verification lifecycle: classify types, discover tools, fail fast, plan, execute, loop. Includes verification surfaces, proof artifacts, self-correction loop, escalation protocol, and definition of done."
+description: "Verification lifecycle: confirm quality gates, classify types, discover tools, fail fast, plan, execute, loop. Quality gates (tests/typecheck/lint) are prerequisites, NOT verification. Verification means running the actual system and observing results."
 ---
 
 # Verification Lifecycle
 
-This skill defines the complete verification lifecycle that agents must follow for every change: classify, check tooling, fail fast, plan, execute, and loop.
+This skill defines the complete verification lifecycle that agents must follow for every change: confirm quality gates, classify, check tooling, fail fast, plan, execute, and loop.
 
 ## Verification Lifecycle
 
 Agents must follow this mandatory sequence for every change:
 
-### 1. Classify
+### 1. Confirm Quality Gates
 
-Determine which verification types apply based on the change. Start with the three always-required types (Test, Type Safety, Lint/Format), then check each conditional type against the change scope.
+Confirm that quality gates (tests, typecheck, lint, format) pass. These are prerequisites, NOT verification. Do not count them as verification — they are enforced automatically by hooks and CI. If quality gates fail, fix them before proceeding.
 
-### 2. Check Tooling
+### 2. Classify
+
+Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in `.claude/rules/verification.md` against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
+
+### 3. Check Tooling
 
 For each required verification type, discover what tools are available in the project. Use the Tool Discovery Process below.
 
-Report what is available for each required type. If a required type has no available tool, proceed to step 3.
+Report what is available for each required type. If a required type has no available tool, proceed to step 4.
 
-### 3. Fail Fast
+### 4. Fail Fast
 
 If a required verification type has no available tool and no reasonable alternative, escalate immediately using the Escalation Protocol. Do not begin implementation without a verification plan for every required type.
 
-### 4. Plan
+### 5. Plan
 
 For each verification type, state:
-- The specific tool or command that will be used
+- The specific tool or command that will be used (NOT test/typecheck/lint — those are quality gates, not verification)
 - The expected outcome that constitutes a pass
 - Any prerequisites (running server, seeded database, auth token)
 
-### 5. Execute
+A verification plan that only lists `bun run test`, `bun run typecheck`, or `bun run lint` is NOT a verification plan. Those are quality gates handled in step 1.
+
+### 6. Execute
 
 After implementation, run the verification plan. Execute each verification type in order.
 
-### 6. Loop
+### 7. Loop
 
 If any verification fails, fix the issue and re-verify. Do not declare done until all required types pass. If a verification is stuck after 3 attempts, escalate.
 
@@ -166,15 +172,16 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 
 1. Restate goal in one sentence.
 2. Identify the end user of the change.
-3. Classify verification types that apply to the change.
-4. Discover available tools for each verification type.
-5. Confirm required surfaces are available, escalate if not.
-6. Plan verification: state tool, command, and expected outcome for each type.
-7. Implement the change.
-8. Execute verification plan.
-9. Collect proof artifacts.
-10. Summarize what changed, what was verified, and remaining risk.
-11. Label the result with a verification level.
+3. Confirm quality gates pass (tests, typecheck, lint, format) — these are prerequisites, NOT verification.
+4. Classify empirical verification types that apply to the change (UI, API, Database, etc.).
+5. Discover available tools for each verification type.
+6. Confirm required surfaces are available, escalate if not.
+7. Plan verification: state tool, command, and expected outcome for each type. Do NOT list test/typecheck/lint here — those are quality gates from step 3.
+8. Implement the change.
+9. Execute verification plan — run the actual system and observe results.
+10. Collect proof artifacts.
+11. Summarize what changed, what was verified, and remaining risk.
+12. Label the result with a verification level.
 
 ---
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "1.81.4",
+  "version": "1.81.5",
   "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.4",
+  "version": "1.81.5",
   "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.4",
+  "version": "1.81.5",
   "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.4",
+  "version": "1.81.5",
   "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.4",
+  "version": "1.81.5",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -26,7 +26,7 @@ If any of these are missing, ask the team for them before proceeding.
 1. **Write failing tests** — translate each acceptance criterion into one or more tests. This is your RED phase. Tests define the contract before any implementation exists.
 2. **Implement** — write the minimum code to make each test pass, one at a time. This is your GREEN phase.
 3. **Refactor** — clean up while keeping all tests green. Follow existing patterns identified in the architecture plan.
-4. **Run full verification** — run the proof command. Verify every acceptance criterion is met.
+4. **Run quality checks** — run tests, typecheck, and lint. These are quality gates (prerequisites), NOT verification. Empirical verification (running the actual system) is done separately by the `verification-specialist`.
 5. **Update documentation** — add/update JSDoc preambles explaining the "why" behind each new piece of code.
 6. **Commit atomically** — use the `/git-commit` skill. Group related changes into logical commits.
 
@@ -38,4 +38,4 @@ If any of these are missing, ask the team for them before proceeding.
 - One task at a time — complete the current task before moving on
 - If you discover a gap in the acceptance criteria, ask the team — don't guess
 - If a dependency is missing (API not built, schema not migrated), report it as a blocker
-- Never mark the task complete without running the proof command
+- Never mark the task complete without running quality checks (tests, typecheck, lint). Note: this is NOT verification — empirical verification is handled by the `verification-specialist`

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

@@ -15,17 +15,21 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 ## Core Philosophy
 
-**"If you didn't run it, you didn't verify it."** Code review is not verification. Reading a test file is not verification. Only executing the system and observing output counts as proof.
+**"If you didn't run it, you didn't verify it."** Code review is not verification. Reading a test file is not verification. **Running tests, typecheck, and lint is not verification either — those are quality gates (prerequisites).** Only executing the actual system and observing output counts as proof. Verification means making HTTP requests, clicking through the UI, running CLI commands, querying the database, or otherwise interacting with the running software as an end user would.
 
 ## Verification Process
 
-Follow the verification lifecycle: **classify, check tooling, fail fast, plan, execute, loop.**
+Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, loop.**
 
-### 1. Classify
+### 1. Confirm Quality Gates
 
-Read `.claude/rules/verification.md` to determine which verification types apply to the current change. Start with the three always-required types (Test, Type Safety, Lint/Format), then check each conditional type against the change scope.
+Confirm that quality gates (tests, typecheck, lint, format) pass. These are prerequisites — if they fail, fix them first. But passing quality gates does NOT mean the change is verified.
 
-### 2. Discover Available Tools
+### 2. Classify
+
+Read `.claude/rules/verification.md` to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
+
+### 3. Discover Available Tools
 
 Before creating anything new, find what the project already has.
 
@@ -46,7 +50,7 @@ Before creating anything new, find what the project already has.
 **MCP tools:**
 - Check available MCP server tools for browser automation, observability, issue tracking, and other capabilities
 
-### 3. Plan the Verification
+### 4. Plan the Verification
 
 For each required verification type, determine:
 
@@ -61,7 +65,7 @@ For each required verification type, determine:
 
 If any required verification type has no available tool and no reasonable alternative, escalate immediately.
 
-### 4. Execute and Report
+### 5. Execute and Report
 
 Run the verification and capture output. Always include:
 
@@ -113,7 +117,8 @@ If any verification fails, fix and re-verify. Do not declare done until all requ
 ## Rules
 
 - Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
-- Follow the verification lifecycle: classify, check tooling, fail fast, plan, execute, loop
+- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, loop
+- Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
 - Discover existing project scripts and tools before creating new ones
 - Every verification must produce observable output -- a status code, a response body, a UI state, a test result
 - Verification scripts must be runnable locally without CI/CD dependencies

package/plugins/src/base/rules/verification.md

@@ -16,11 +16,13 @@ No agent may claim success without evidence from runtime verification.
 
 Never assume something works because the code "looks correct." Run a command, observe the output, compare to expected result.
 
-**Verification is not linting, typechecking, or testing.** Those are quality checks. Verification is using the resulting software the way a user would — interacting with the UI, calling the API, running the CLI command, observing the behavior. Tests pass in isolation; verification proves the system works as a whole. Passing tests, linting, and typechecking does not constitute verification.
+**Verification is not linting, typechecking, or testing.** Those are **quality checks** — prerequisites that must pass before verification begins, but they are NOT verification themselves. Running `bun run test`, `bun run typecheck`, `bun run lint`, or `bun run format` is a quality check. Verification is using the resulting software the way a user would — interacting with the UI, calling the API, running the CLI command, observing the behavior. Tests pass in isolation; verification proves the system works as a whole.
+
+**If all you did was run tests, typecheck, and lint — you have NOT verified.** You have only confirmed quality checks pass. Verification requires running the actual system and observing the results: making HTTP requests, clicking through the UI, executing CLI commands, querying the database, or otherwise interacting with the running software as an end user would.
 
 Verification is mandatory. Never skip it, defer it, or claim it was unnecessary. Every task must be verified before claiming completion.
 
-Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. Do not begin implementation until the plan is confirmed.
+Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. A verification plan that only lists test/typecheck/lint commands is not a verification plan. Do not begin implementation until the plan is confirmed.
 
 After verifying a change empirically, encode that verification as automated tests. The manual proof that something works should become a repeatable regression test that catches future regressions. Every verification should answer: "How do I turn this into a test?"
 
@@ -56,19 +58,23 @@ Agents must label every task outcome with exactly one of these:
 
 ---
 
-## Verification Types
-
-Every change requires one or more verification types. Classify the change first, then verify each applicable type.
+## Quality Gates (Prerequisites)
 
-### Always Required
+These are NOT verification. They are prerequisites that must pass before verification begins. Running these does not constitute verification — it only confirms code quality.
 
-| Type | What to prove | Acceptable proof |
+| Gate | What to prove | Acceptable proof |
 |------|---------------|------------------|
 | **Test** | Unit and integration tests pass for all changed code paths | Test runner output showing all relevant tests green with no skips |
 | **Type Safety** | No type errors introduced by the change | Type checker exits clean on the full project |
 | **Lint/Format** | Code meets project style and quality rules | Linter and formatter exit clean on changed files |
 
-### Conditional
+Quality gates are enforced automatically by the self-correction loop (hooks, pre-commit, pre-push). Passing all quality gates is necessary but NOT sufficient — you must still verify empirically.
+
+---
+
+## Verification Types
+
+Every change requires one or more verification types. Classify the change first, then verify each applicable type by **running the actual system and observing results**.
 
 | Type | When it applies | What to prove | Acceptable proof |
 |------|----------------|---------------|------------------|
@@ -94,7 +100,8 @@ Every change requires one or more verification types. Classify the change first,
 
 Verification happens at two stages in the workflow:
 
-- **Local verification** (part of the Implement flow): Run the full test suite, typecheck, lint, and empirically verify the change in a local or preview environment. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
+- **Quality gates** (enforced automatically): Tests, typecheck, lint, and format run via hooks at write-time, commit-time, and push-time. These are prerequisites, not verification.
+- **Local verification** (part of the Implement flow): After quality gates pass, empirically verify the change by running the actual system in a local or preview environment — make HTTP requests, interact with the UI, execute CLI commands, query the database. This proves the change works before shipping. After local verification succeeds, encode it as an e2e test.
 - **Remote verification** (part of the Verify flow): After the PR is merged and deployed, repeat the same empirical verification against the target environment. This proves the change works in production, not just locally. If remote verification fails, fix and re-deploy.
 
 Both levels use the same verification types table above. The difference is the environment, not the rigor.

package/plugins/src/base/skills/plan-execute/SKILL.md

@@ -77,9 +77,9 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "skills": ["..."],
   "learnings": ["..."],
   "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
+    "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
+    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
+    "expected": "what success looks like — observable system behavior"
   }
 }
 ```
@@ -91,8 +91,8 @@ Each task must have their learnings reviewed by the learner subagent.
 
 Before shutting down the team, execute the Verify flow:
 
-1. Run local validation: lint, typecheck, tests — all must pass
-2. `verification-specialist`: verify locally (empirical proof that the change works)
+1. Run quality gates: lint, typecheck, tests — all must pass. These are prerequisites, NOT verification.
+2. `verification-specialist`: verify locally by running the actual system and observing results (empirical proof that the change works). This is the real verification step.
 3. Write e2e test encoding the verification
 4. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
 5. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not

package/plugins/src/base/skills/tdd-implementation/SKILL.md

@@ -21,9 +21,9 @@ Each task you work on must have the following in its metadata:
   "skills": ["..."],
   "learnings": ["..."],
   "verification": {
-    "type": "test|ui-recording|test-coverage|api-test|manual-check|documentation",
-    "command": "the proof command",
-    "expected": "what success looks like"
+    "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
+    "command": "the proof command — must run the actual system (NOT test/typecheck/lint, those are quality gates)",
+    "expected": "what success looks like — observable system behavior"
   }
 }
 ```

package/plugins/src/base/skills/verification-lifecycle/SKILL.md

@@ -1,42 +1,48 @@
 ---
 name: verification-lifecycle
-description: "Verification lifecycle: classify types, discover tools, fail fast, plan, execute, loop. Includes verification surfaces, proof artifacts, self-correction loop, escalation protocol, and definition of done."
+description: "Verification lifecycle: confirm quality gates, classify types, discover tools, fail fast, plan, execute, loop. Quality gates (tests/typecheck/lint) are prerequisites, NOT verification. Verification means running the actual system and observing results."
 ---
 
 # Verification Lifecycle
 
-This skill defines the complete verification lifecycle that agents must follow for every change: classify, check tooling, fail fast, plan, execute, and loop.
+This skill defines the complete verification lifecycle that agents must follow for every change: confirm quality gates, classify, check tooling, fail fast, plan, execute, and loop.
 
 ## Verification Lifecycle
 
 Agents must follow this mandatory sequence for every change:
 
-### 1. Classify
+### 1. Confirm Quality Gates
 
-Determine which verification types apply based on the change. Start with the three always-required types (Test, Type Safety, Lint/Format), then check each conditional type against the change scope.
+Confirm that quality gates (tests, typecheck, lint, format) pass. These are prerequisites, NOT verification. Do not count them as verification — they are enforced automatically by hooks and CI. If quality gates fail, fix them before proceeding.
 
-### 2. Check Tooling
+### 2. Classify
+
+Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in `.claude/rules/verification.md` against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
+
+### 3. Check Tooling
 
 For each required verification type, discover what tools are available in the project. Use the Tool Discovery Process below.
 
-Report what is available for each required type. If a required type has no available tool, proceed to step 3.
+Report what is available for each required type. If a required type has no available tool, proceed to step 4.
 
-### 3. Fail Fast
+### 4. Fail Fast
 
 If a required verification type has no available tool and no reasonable alternative, escalate immediately using the Escalation Protocol. Do not begin implementation without a verification plan for every required type.
 
-### 4. Plan
+### 5. Plan
 
 For each verification type, state:
-- The specific tool or command that will be used
+- The specific tool or command that will be used (NOT test/typecheck/lint — those are quality gates, not verification)
 - The expected outcome that constitutes a pass
 - Any prerequisites (running server, seeded database, auth token)
 
-### 5. Execute
+A verification plan that only lists `bun run test`, `bun run typecheck`, or `bun run lint` is NOT a verification plan. Those are quality gates handled in step 1.
+
+### 6. Execute
 
 After implementation, run the verification plan. Execute each verification type in order.
 
-### 6. Loop
+### 7. Loop
 
 If any verification fails, fix the issue and re-verify. Do not declare done until all required types pass. If a verification is stuck after 3 attempts, escalate.
 
@@ -166,15 +172,16 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 
 1. Restate goal in one sentence.
 2. Identify the end user of the change.
-3. Classify verification types that apply to the change.
-4. Discover available tools for each verification type.
-5. Confirm required surfaces are available, escalate if not.
-6. Plan verification: state tool, command, and expected outcome for each type.
-7. Implement the change.
-8. Execute verification plan.
-9. Collect proof artifacts.
-10. Summarize what changed, what was verified, and remaining risk.
-11. Label the result with a verification level.
+3. Confirm quality gates pass (tests, typecheck, lint, format) — these are prerequisites, NOT verification.
+4. Classify empirical verification types that apply to the change (UI, API, Database, etc.).
+5. Discover available tools for each verification type.
+6. Confirm required surfaces are available, escalate if not.
+7. Plan verification: state tool, command, and expected outcome for each type. Do NOT list test/typecheck/lint here — those are quality gates from step 3.
+8. Implement the change.
+9. Execute verification plan — run the actual system and observe results.
+10. Collect proof artifacts.
+11. Summarize what changed, what was verified, and remaining risk.
+12. Label the result with a verification level.
 
 ---