@codyswann/lisa 2.6.3 → 2.7.0

package/oxlint/expo.json

@@ -12,9 +12,6 @@
     "react-perf",
     "jsx-a11y"
   ],
-  "categories": {
-    "correctness": "error"
-  },
   "ignorePatterns": [
     "build/**",
     "dist/**",

package/package.json

@@ -79,7 +79,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.6.3",
+  "version": "2.7.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": "2.6.3",
+  "version": "2.7.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
@@ -46,6 +46,15 @@
             "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code pre-task || true"
           }
         ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/block-no-verify.sh"
+          }
+        ]
       }
     ],
     "Stop": [

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

@@ -3,6 +3,7 @@ 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.
 skills:
   - verification-lifecycle
+  - codify-verification
   - jira-journey
   - spec-conformance
 ---
@@ -19,7 +20,7 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 ## Verification Process
 
-Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, loop.**
+Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop.**
 
 ### 1. Confirm Quality Gates
 
@@ -76,6 +77,10 @@ Run the verification and capture output. Always include:
 
 If any verification fails, fix and re-verify. Do not declare done until all required types pass.
 
+### 6. Codify
+
+For every empirical verification that produced PASS evidence, invoke the `codify-verification` skill to encode it as a regression test in the appropriate framework (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.). The new test must run, pass, and be committed in the same PR. Skipping codification is allowed only for non-behavioral types (PR, Documentation, Deploy) and Investigate-Only spikes — for everything else, codify or escalate.
+
 ## Output Format
 
 ```
@@ -117,7 +122,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: confirm quality gates, classify, check tooling, fail fast, plan, execute, loop
+- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
+- Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - 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

package/plugins/lisa/commands/codify-verification.md

@@ -0,0 +1,6 @@
+---
+description: "Convert empirical verification into a regression test (Playwright for UI, integration test for API/DB, benchmark for performance, etc.) so it doesn't regress. Mandatory step after verification passes — invoked from verification-lifecycle and from each Build/Fix/Improve flow."
+argument-hint: "<verification-type> <what-was-verified>"
+---
+
+Use the /lisa:codify-verification skill to encode the empirical verification that just passed as a regression test, in the appropriate framework for the verification type. $ARGUMENTS

package/plugins/lisa/hooks/block-no-verify.sh

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: blocks any command containing --no-verify.
+# --no-verify on git commit/push (and equivalents) bypasses pre-commit/pre-push
+# hooks that exist for a reason. The fix is to address the underlying issue,
+# not silence the check. See feedback_never_no_verify in user memory.
+#
+# Word-boundary match avoids false positives on flags like --no-verify-ssl,
+# --no-verify-host, etc.
+set -euo pipefail
+
+input="$(cat)"
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+if [ "$tool_name" != "Bash" ]; then
+  exit 0
+fi
+
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+if [ -z "$command_str" ]; then
+  exit 0
+fi
+
+# Match --no-verify bounded by non-token characters (not alphanumeric, _, or -).
+# This catches all syntactic positions including subshells (e.g. `(git commit --no-verify)`)
+# while excluding longer flags like --no-verify-ssl, --no-verify-host, etc.
+if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])'; then
+  cat >&2 <<'EOF'
+Blocked: --no-verify bypasses pre-commit/pre-push hooks. Fix the underlying
+issue (lint error, failing test, formatting) or ask the user before bypassing.
+
+If the user has explicitly authorized the bypass for this specific command,
+re-run after they confirm.
+EOF
+  exit 2
+fi
+
+exit 0

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

@@ -119,7 +119,7 @@ Determine the work type and execute the matching variant:
 5. `builder` -- implement via TDD (acceptance criteria become 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
+8. `verification-specialist` -- invoke `codify-verification` skill per passing verification (Playwright for UI, integration test for API/DB/auth, etc.); commit each test in the same PR
 9. **Review sub-flow**
 10. `learner` -- capture discoveries
 
@@ -133,7 +133,7 @@ Determine the work type and execute the matching variant:
 6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
 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
+9. `verification-specialist` -- invoke `codify-verification` skill to encode the fix as a regression test (mandatory for bug fixes — the test must fail against the pre-fix commit and pass against the fix); commit in the same PR
 10. **Review sub-flow**
 11. `learner` -- capture discoveries
 
@@ -145,7 +145,7 @@ Determine the work type and execute the matching variant:
 4. `builder` -- implement improvements via TDD
 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)
+7. `verification-specialist` -- invoke `codify-verification` skill (typically a benchmark asserting against baseline for performance work, or a regression test for behavioral refactors); commit in the same PR
 8. **Review sub-flow**
 9. `learner` -- capture discoveries
 
@@ -156,7 +156,7 @@ 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 quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
+Output: Code passing all quality gates + local empirical verification + codified regression test for each verification (except for spikes, which produce findings only, and non-behavioral verification types — PR / Documentation / Deploy — which carry their own proof).
 
 ### Verify
 
@@ -165,6 +165,7 @@ When: Code is ready to ship. All quality gates pass and local empirical verifica
 Gate:
 - Code must pass quality gates (lint, typecheck, tests)
 - Local empirical verification must be complete
+- Each passing local verification must be codified as a regression test (or carry a documented skip from the allowed set: PR / Documentation / Deploy / Investigate-Only). If verifications are not codified, return to the Implement flow's codify step before shipping
 - If quality gates fail, go back to **Implement**
 - If no code changes exist, there is nothing to verify
 

package/plugins/lisa/rules/verification.md

@@ -24,7 +24,7 @@ Verification is mandatory. Never skip it, defer it, or claim it was unnecessary.
 
 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?"
+After verifying a change empirically, encode that verification as an automated regression test via the `codify-verification` skill. The manual proof that something works must become a repeatable test that catches future regressions — Playwright for UI/browser flows, integration test for API/DB/auth, benchmark for performance, etc. Codification is mandatory for every empirical verification type except the inherently non-behavioral ones (PR, Documentation, Deploy) and Investigate-Only spikes. If codification is genuinely impossible, escalate via the Escalation Protocol — never silently skip.
 
 Every pull request must include step-by-step instructions for reviewers to independently replicate the verification. These are not test commands — they are the exact steps a human would follow to use the software and confirm the change works. If a reviewer cannot reproduce your verification from the PR description alone, the PR is incomplete.
 
@@ -101,7 +101,7 @@ Every change requires one or more verification types. Classify the change first,
 Verification happens at two stages in the workflow:
 
 - **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.
+- **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, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
 - **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/codify-verification/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: codify-verification
+description: "Convert empirical verification into a regression test so it never has to be re-proven manually. Runs after a verification passes — picks the appropriate test framework for the verification type (Playwright for UI/browser, integration test for API/DB/auth, benchmark for performance, etc.), generates the test, wires it into the project's test runner, and confirms it executes. Mandatory step in the verification lifecycle and in the Build/Fix/Improve flows."
+allowed-tools: ["Bash", "Read", "Edit", "Write", "Glob", "Grep", "Skill"]
+---
+
+# Codify Verification: $ARGUMENTS
+
+Take the empirical verification that just passed and encode it as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+This skill is invoked from the verification lifecycle (between Execute and Spec Conformance) and from each work-type sub-flow (Build / Fix / Improve) after the local verification step.
+
+## When to invoke
+
+Invoke once per empirical verification that produced PASS evidence. If a single change had three verifications (UI flow, API endpoint, DB query), this skill runs three times — or once with the three verifications batched, but each must produce its own committed test.
+
+## When to skip
+
+Skip codification only for verification types whose proof is inherently non-behavioral:
+
+- **PR** — proof is the PR description itself
+- **Documentation** — proof is content review
+- **Deploy** — proof is deployment output and health endpoints (already covered by ops-verify-health)
+- **Investigate-Only spikes** — produce findings, not shipped code
+
+For every other verification type, codification is mandatory. If the codification is not possible (e.g., the test framework doesn't exist and can't be installed in scope), escalate via the lifecycle's Escalation Protocol — do not silently skip.
+
+## Inputs
+
+The caller must provide:
+
+- The verification type (UI, API, Database, Auth, Security, Performance, Background Jobs, Cache, Configuration, Email/Notification, Observability, Infrastructure)
+- The exact steps that were performed (URL visited, request made, query run, etc.)
+- The expected outcome (status code, UI state, row count, log entry, etc.)
+- The proof artifact captured (screenshot path, response body, query output, log excerpt)
+
+If any of these are missing, ask the caller before generating a test — a test built on guesswork will not match the verification it claims to encode.
+
+## Process
+
+### 1. Discover existing test infrastructure
+
+Before creating anything new, find what the project already has. Use the Tool Discovery Process from `verification-lifecycle`. Specifically check for:
+
+- **Browser/E2E**: `playwright.config.*`, `cypress.config.*`, `e2e/` directory, `tests/e2e/`, Playwright/Cypress in `package.json` devDependencies
+- **API/integration**: `tests/integration/`, `spec/`, `test/integration/`, supertest/fetch helpers, Vitest/Jest integration configs
+- **Database**: integration test setup with migrations, factory files, seed scripts
+- **Performance**: existing benchmark suite (`benchmarks/`, `bench/`), `vitest bench`, k6 scripts
+- **Mobile (RN/Expo)**: Detox config, Maestro flows
+- **Backend jobs**: existing job-test harness, queue integration tests
+
+Do NOT install a new framework if one already exists for the verification type. Use what's there.
+
+### 2. Map verification type → framework
+
+| Verification type | Preferred framework (use whichever the project already has) |
+|---|---|
+| UI (web) | Playwright > Cypress > Selenium |
+| UI (mobile) | Maestro > Detox > Playwright (mobile emulation) |
+| API | project's integration test runner (Vitest / Jest / RSpec / pytest) with HTTP client (supertest / fetch / faraday) |
+| Database | integration test with real DB + migrations applied |
+| Auth | API or UI test asserting role-gated access (multi-role coverage) |
+| Security | regression test that reproduces the attack and asserts safe handling |
+| Performance | benchmark in the project's bench harness, asserting against the baseline captured in the verification |
+| Background Jobs | integration test that enqueues, drains the queue, and asserts terminal state |
+| Cache | integration test asserting hit/miss/invalidation behavior |
+| Configuration | integration test that loads config and asserts effect |
+| Email/Notification | test capturing outbound message via project's mailer test mode |
+| Observability | test asserting structured log/metric/trace emission |
+| Infrastructure | test or script asserting infra state (terraform plan diff, CDK snapshot test) |
+
+If the project lacks the preferred framework AND no acceptable substitute exists, escalate.
+
+### 3. Generate the test
+
+The generated test must:
+
+- **Encode the exact verification that passed**, not a paraphrase. Same URL, same input, same assertion target.
+- **Assert the observable outcome**, not implementation details. If the verification confirmed "user sees order confirmation", the test asserts that text/element is visible — not that a particular function was called.
+- **Be deterministic.** No reliance on timing, network flakiness, real third-party services, or mutable shared state. Use the project's existing fixtures, factories, mocks, and seed data conventions.
+- **Be self-contained.** Set up its own preconditions and clean up after itself, following the project's existing test isolation patterns.
+- **Be named after the behavior, not the bug/ticket.** `displays order confirmation after checkout` not `fixes PROJ-1234`.
+- **Live in the project's existing test directory** for that type. Do not create a parallel test tree.
+
+For Playwright UI tests specifically:
+- Use the project's existing `test` fixture / `page` fixture / auth helper if one exists
+- Prefer role/text selectors (`getByRole`, `getByText`) over CSS/XPath — they survive markup churn
+- Capture a trace or screenshot only if the project's existing tests do; do not invent a new artifact convention
+- Mirror the project's existing config for base URL, retries, and test isolation
+
+### 4. Run the test in isolation
+
+Run only the new test, using whatever per-test invocation the project supports:
+
+- Playwright: `npx playwright test path/to/new.spec.ts`
+- Vitest: `npx vitest run path/to/new.spec.ts`
+- Jest: `npx jest path/to/new.test.ts`
+- RSpec: `bundle exec rspec path/to/new_spec.rb`
+
+Confirm:
+1. The test PASSES against the current code (the change being shipped)
+2. The test would have FAILED before the change (sanity check by mentally reverting, or for bug fixes, by running against the pre-fix commit if cheap)
+
+For a bug fix, step 2 is mandatory and easy: check out the failing commit, run the new test, see it fail, return to the fix branch. This proves the test actually guards the regression.
+
+### 5. Wire it into the suite
+
+Confirm the test is picked up by the project's standard test command (the one CI runs). Run that command and confirm the count went up by exactly the number of tests added.
+
+If the test is in a directory the standard test command excludes (e.g., E2E suite that runs separately in CI), confirm the appropriate CI workflow includes it.
+
+### 6. Commit
+
+Commit the test in the same PR as the change it codifies, in its own atomic commit:
+
+- Build/feature: `test: add e2e for <behavior>`
+- Bug fix: `test: add regression test for <bug behavior>`
+- Performance: `test: add benchmark asserting <metric> <baseline>`
+
+The commit message body should reference the verification it encodes (one line linking to the proof artifact or the verification report section).
+
+### 7. Record evidence
+
+Append to the verification report (or PR description):
+
+```markdown
+### Codified Verifications
+
+| # | Verification | Framework | Test file | Status |
+|---|--------------|-----------|-----------|--------|
+| 1 | <description> | Playwright | `e2e/checkout.spec.ts::displays order confirmation after checkout` | PASS |
+```
+
+This evidence shows the verification is now guarded.
+
+## Output
+
+For each empirical verification passed in:
+
+- A new test file (or extension to an existing test file) committed to the PR
+- Confirmation that the test passes against the current branch
+- The test file path + test name recorded in the verification report
+
+If codification was skipped, an explicit reason recorded in the report (one of the skip conditions above) — never silent.
+
+## Rules
+
+- Never claim a verification is codified without running the new test and observing it pass
+- Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change
+- Never use `expect(true).toBe(true)` placeholders or smoke-only assertions that don't actually exercise the verified behavior
+- Never reuse the verification's manual artifact (screenshot, curl output) as a "test" — those are evidence, not regression coverage
+- If the project lacks the appropriate framework, escalate via Human Action Packet rather than installing one mid-task without approval

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

@@ -1,16 +1,26 @@
 ---
 name: verification-lifecycle
-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."
+description: "Verification lifecycle: confirm quality gates, classify types, discover tools, fail fast, plan, execute, codify (turn each passing verification into a regression test), spec conformance (verify shipped work matches the spec), 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: confirm quality gates, 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, codify (turn each passing verification into a regression test), spec conformance (verify shipped work matches the spec), and loop.
 
 ## Verification Lifecycle
 
 Agents must follow this mandatory sequence for every change:
 
+1. Confirm Quality Gates
+2. Classify
+3. Check Tooling
+4. Fail Fast (if blocked)
+5. Plan
+6. Execute
+7. Codify (turn each passing verification into a regression test)
+8. Spec Conformance
+9. Loop
+
 ### 1. Confirm Quality Gates
 
 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.
@@ -42,7 +52,17 @@ A verification plan that only lists `bun run test`, `bun run typecheck`, or `bun
 
 After implementation, run the verification plan. Execute each verification type in order.
 
-### 7. Spec Conformance
+### 7. Codify
+
+After each empirical verification produces PASS evidence, invoke the `codify-verification` skill to encode the verification as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+The `codify-verification` skill maps the verification type to the appropriate framework (Playwright for browser/UI, integration test for API/DB/auth, benchmark for performance, etc.), generates a deterministic test that asserts the same observable outcome the verification just confirmed, runs it in isolation to confirm PASS, and commits it in the same PR as the change.
+
+Codification is mandatory for every empirical verification type with one exception set: PR, Documentation, Deploy, and Investigate-Only spikes — those have inherently non-behavioral proof. For every other type, skipping codification is not allowed; if codification is genuinely impossible (e.g., the test framework does not exist and cannot be installed in scope), escalate via the Escalation Protocol rather than silently skipping.
+
+A change is not "verified" in the lifecycle sense until each empirical verification has both passed AND been codified.
+
+### 8. Spec Conformance
 
 After empirical verification produces evidence, run spec conformance as a separate, mandatory step. Invoke the `spec-conformance` skill (or delegate to the `spec-conformance-specialist` agent) with the spec source — plan file, JIRA/Linear/GitHub key, or PRD.
 
@@ -56,9 +76,9 @@ Required outputs:
 
 `PARTIAL` or `DIVERGES` blocks completion. Fix the gaps (implement the miss, remove the creep, capture the missing evidence) and re-run both empirical verification AND spec conformance. Never skip this step — it catches failures that empirical verification by itself does not, such as a feature that works but wasn't asked for, or a spec item that was quietly dropped.
 
-### 8. Loop
+### 9. Loop
 
-If any verification or spec-conformance check fails, fix the issue and re-verify. Do not declare done until all required types pass AND the spec-conformance verdict is `CONFORMS`. If a verification or conformance check is stuck after 3 attempts, escalate.
+If any verification, codification, or spec-conformance check fails, fix the issue and re-verify. Do not declare done until all required types pass, all empirical verifications are codified, AND the spec-conformance verdict is `CONFORMS`. If a verification, codification, or conformance check is stuck after 3 attempts, escalate.
 
 ---
 
@@ -194,9 +214,10 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 8. Implement the change.
 9. Execute verification plan — run the actual system and observe results.
 10. Collect proof artifacts.
-11. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
-12. Summarize what changed, what was verified, conformance verdict, and remaining risk.
-13. Label the result with a verification level.
+11. Codify — for each passing empirical verification, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
+12. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
+13. Summarize what changed, what was verified, what was codified, conformance verdict, and remaining risk.
+14. Label the result with a verification level.
 
 ---
 
@@ -305,9 +326,10 @@ A task is done only when:
 
 - End user is identified
 - All applicable verification types are classified and executed
-- Verification lifecycle is completed (classify, check tooling, plan, execute, spec conformance, loop)
+- Verification lifecycle is completed (classify, check tooling, plan, execute, codify, spec conformance, loop)
 - Required verification surfaces and tooling surfaces are used or explicitly unavailable
 - Proof artifacts are captured
+- Every passing empirical verification is codified as a regression test (or has an explicit, documented skip reason from the allowed set)
 - Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)
 - Verification level is declared
 - Risks and gaps are documented

package/plugins/lisa/skills/verify/SKILL.md

@@ -18,12 +18,13 @@ If you ARE already inside an agent team (e.g., a teammate invoked this skill via
 
 Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The flow includes:
 
-1. **Commit** any pending changes via `lisa:git-commit`
-2. **Push and PR** via `lisa:git-submit-pr`
-3. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
-4. **Merge** when CI is green
-5. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined)
-6. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter)
+1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. A change cannot ship until its verifications are guarded.
+2. **Commit** any pending changes via `lisa:git-commit`
+3. **Push and PR** via `lisa:git-submit-pr`
+4. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
+5. **Merge** when CI is green
+6. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined). If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
+7. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter), including the list of codified tests added on this branch.
 
 The rule contains the canonical step sequence. Change it there, propagate everywhere.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.6.3",
+  "version": "2.7.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": "2.6.3",
+  "version": "2.7.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": "2.6.3",
+  "version": "2.7.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/src/base/.claude-plugin/plugin.json

@@ -35,6 +35,12 @@
         "hooks": [
           { "type": "command", "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code pre-task || true" }
         ]
+      },
+      {
+        "matcher": "Bash",
+        "hooks": [
+          { "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/block-no-verify.sh" }
+        ]
       }
     ],
     "Stop": [

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

@@ -3,6 +3,7 @@ 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.
 skills:
   - verification-lifecycle
+  - codify-verification
   - jira-journey
   - spec-conformance
 ---
@@ -19,7 +20,7 @@ Read `.claude/rules/verification.md` at the start of every investigation for the
 
 ## Verification Process
 
-Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, loop.**
+Follow the verification lifecycle: **confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop.**
 
 ### 1. Confirm Quality Gates
 
@@ -76,6 +77,10 @@ Run the verification and capture output. Always include:
 
 If any verification fails, fix and re-verify. Do not declare done until all required types pass.
 
+### 6. Codify
+
+For every empirical verification that produced PASS evidence, invoke the `codify-verification` skill to encode it as a regression test in the appropriate framework (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.). The new test must run, pass, and be committed in the same PR. Skipping codification is allowed only for non-behavioral types (PR, Documentation, Deploy) and Investigate-Only spikes — for everything else, codify or escalate.
+
 ## Output Format
 
 ```
@@ -117,7 +122,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: confirm quality gates, classify, check tooling, fail fast, plan, execute, loop
+- Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
+- Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - 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

package/plugins/src/base/commands/codify-verification.md

@@ -0,0 +1,6 @@
+---
+description: "Convert empirical verification into a regression test (Playwright for UI, integration test for API/DB, benchmark for performance, etc.) so it doesn't regress. Mandatory step after verification passes — invoked from verification-lifecycle and from each Build/Fix/Improve flow."
+argument-hint: "<verification-type> <what-was-verified>"
+---
+
+Use the /lisa:codify-verification skill to encode the empirical verification that just passed as a regression test, in the appropriate framework for the verification type. $ARGUMENTS

package/plugins/src/base/hooks/block-no-verify.sh

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: blocks any command containing --no-verify.
+# --no-verify on git commit/push (and equivalents) bypasses pre-commit/pre-push
+# hooks that exist for a reason. The fix is to address the underlying issue,
+# not silence the check. See feedback_never_no_verify in user memory.
+#
+# Word-boundary match avoids false positives on flags like --no-verify-ssl,
+# --no-verify-host, etc.
+set -euo pipefail
+
+input="$(cat)"
+
+tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
+if [ "$tool_name" != "Bash" ]; then
+  exit 0
+fi
+
+command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
+if [ -z "$command_str" ]; then
+  exit 0
+fi
+
+# Match --no-verify bounded by non-token characters (not alphanumeric, _, or -).
+# This catches all syntactic positions including subshells (e.g. `(git commit --no-verify)`)
+# while excluding longer flags like --no-verify-ssl, --no-verify-host, etc.
+if printf '%s' "$command_str" | grep -Eq '(^|[^[:alnum:]_-])--no-verify($|[^[:alnum:]_-])'; then
+  cat >&2 <<'EOF'
+Blocked: --no-verify bypasses pre-commit/pre-push hooks. Fix the underlying
+issue (lint error, failing test, formatting) or ask the user before bypassing.
+
+If the user has explicitly authorized the bypass for this specific command,
+re-run after they confirm.
+EOF
+  exit 2
+fi
+
+exit 0

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

@@ -119,7 +119,7 @@ Determine the work type and execute the matching variant:
 5. `builder` -- implement via TDD (acceptance criteria become 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
+8. `verification-specialist` -- invoke `codify-verification` skill per passing verification (Playwright for UI, integration test for API/DB/auth, etc.); commit each test in the same PR
 9. **Review sub-flow**
 10. `learner` -- capture discoveries
 
@@ -133,7 +133,7 @@ Determine the work type and execute the matching variant:
 6. `bug-fixer` -- implement fix via TDD (reproduction becomes failing test)
 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
+9. `verification-specialist` -- invoke `codify-verification` skill to encode the fix as a regression test (mandatory for bug fixes — the test must fail against the pre-fix commit and pass against the fix); commit in the same PR
 10. **Review sub-flow**
 11. `learner` -- capture discoveries
 
@@ -145,7 +145,7 @@ Determine the work type and execute the matching variant:
 4. `builder` -- implement improvements via TDD
 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)
+7. `verification-specialist` -- invoke `codify-verification` skill (typically a benchmark asserting against baseline for performance work, or a regression test for behavioral refactors); commit in the same PR
 8. **Review sub-flow**
 9. `learner` -- capture discoveries
 
@@ -156,7 +156,7 @@ 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 quality gates + local empirical verification + e2e test (except for spikes, which produce findings only).
+Output: Code passing all quality gates + local empirical verification + codified regression test for each verification (except for spikes, which produce findings only, and non-behavioral verification types — PR / Documentation / Deploy — which carry their own proof).
 
 ### Verify
 
@@ -165,6 +165,7 @@ When: Code is ready to ship. All quality gates pass and local empirical verifica
 Gate:
 - Code must pass quality gates (lint, typecheck, tests)
 - Local empirical verification must be complete
+- Each passing local verification must be codified as a regression test (or carry a documented skip from the allowed set: PR / Documentation / Deploy / Investigate-Only). If verifications are not codified, return to the Implement flow's codify step before shipping
 - If quality gates fail, go back to **Implement**
 - If no code changes exist, there is nothing to verify
 

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

@@ -24,7 +24,7 @@ Verification is mandatory. Never skip it, defer it, or claim it was unnecessary.
 
 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?"
+After verifying a change empirically, encode that verification as an automated regression test via the `codify-verification` skill. The manual proof that something works must become a repeatable test that catches future regressions — Playwright for UI/browser flows, integration test for API/DB/auth, benchmark for performance, etc. Codification is mandatory for every empirical verification type except the inherently non-behavioral ones (PR, Documentation, Deploy) and Investigate-Only spikes. If codification is genuinely impossible, escalate via the Escalation Protocol — never silently skip.
 
 Every pull request must include step-by-step instructions for reviewers to independently replicate the verification. These are not test commands — they are the exact steps a human would follow to use the software and confirm the change works. If a reviewer cannot reproduce your verification from the PR description alone, the PR is incomplete.
 
@@ -101,7 +101,7 @@ Every change requires one or more verification types. Classify the change first,
 Verification happens at two stages in the workflow:
 
 - **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.
+- **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, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
 - **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/codify-verification/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: codify-verification
+description: "Convert empirical verification into a regression test so it never has to be re-proven manually. Runs after a verification passes — picks the appropriate test framework for the verification type (Playwright for UI/browser, integration test for API/DB/auth, benchmark for performance, etc.), generates the test, wires it into the project's test runner, and confirms it executes. Mandatory step in the verification lifecycle and in the Build/Fix/Improve flows."
+allowed-tools: ["Bash", "Read", "Edit", "Write", "Glob", "Grep", "Skill"]
+---
+
+# Codify Verification: $ARGUMENTS
+
+Take the empirical verification that just passed and encode it as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+This skill is invoked from the verification lifecycle (between Execute and Spec Conformance) and from each work-type sub-flow (Build / Fix / Improve) after the local verification step.
+
+## When to invoke
+
+Invoke once per empirical verification that produced PASS evidence. If a single change had three verifications (UI flow, API endpoint, DB query), this skill runs three times — or once with the three verifications batched, but each must produce its own committed test.
+
+## When to skip
+
+Skip codification only for verification types whose proof is inherently non-behavioral:
+
+- **PR** — proof is the PR description itself
+- **Documentation** — proof is content review
+- **Deploy** — proof is deployment output and health endpoints (already covered by ops-verify-health)
+- **Investigate-Only spikes** — produce findings, not shipped code
+
+For every other verification type, codification is mandatory. If the codification is not possible (e.g., the test framework doesn't exist and can't be installed in scope), escalate via the lifecycle's Escalation Protocol — do not silently skip.
+
+## Inputs
+
+The caller must provide:
+
+- The verification type (UI, API, Database, Auth, Security, Performance, Background Jobs, Cache, Configuration, Email/Notification, Observability, Infrastructure)
+- The exact steps that were performed (URL visited, request made, query run, etc.)
+- The expected outcome (status code, UI state, row count, log entry, etc.)
+- The proof artifact captured (screenshot path, response body, query output, log excerpt)
+
+If any of these are missing, ask the caller before generating a test — a test built on guesswork will not match the verification it claims to encode.
+
+## Process
+
+### 1. Discover existing test infrastructure
+
+Before creating anything new, find what the project already has. Use the Tool Discovery Process from `verification-lifecycle`. Specifically check for:
+
+- **Browser/E2E**: `playwright.config.*`, `cypress.config.*`, `e2e/` directory, `tests/e2e/`, Playwright/Cypress in `package.json` devDependencies
+- **API/integration**: `tests/integration/`, `spec/`, `test/integration/`, supertest/fetch helpers, Vitest/Jest integration configs
+- **Database**: integration test setup with migrations, factory files, seed scripts
+- **Performance**: existing benchmark suite (`benchmarks/`, `bench/`), `vitest bench`, k6 scripts
+- **Mobile (RN/Expo)**: Detox config, Maestro flows
+- **Backend jobs**: existing job-test harness, queue integration tests
+
+Do NOT install a new framework if one already exists for the verification type. Use what's there.
+
+### 2. Map verification type → framework
+
+| Verification type | Preferred framework (use whichever the project already has) |
+|---|---|
+| UI (web) | Playwright > Cypress > Selenium |
+| UI (mobile) | Maestro > Detox > Playwright (mobile emulation) |
+| API | project's integration test runner (Vitest / Jest / RSpec / pytest) with HTTP client (supertest / fetch / faraday) |
+| Database | integration test with real DB + migrations applied |
+| Auth | API or UI test asserting role-gated access (multi-role coverage) |
+| Security | regression test that reproduces the attack and asserts safe handling |
+| Performance | benchmark in the project's bench harness, asserting against the baseline captured in the verification |
+| Background Jobs | integration test that enqueues, drains the queue, and asserts terminal state |
+| Cache | integration test asserting hit/miss/invalidation behavior |
+| Configuration | integration test that loads config and asserts effect |
+| Email/Notification | test capturing outbound message via project's mailer test mode |
+| Observability | test asserting structured log/metric/trace emission |
+| Infrastructure | test or script asserting infra state (terraform plan diff, CDK snapshot test) |
+
+If the project lacks the preferred framework AND no acceptable substitute exists, escalate.
+
+### 3. Generate the test
+
+The generated test must:
+
+- **Encode the exact verification that passed**, not a paraphrase. Same URL, same input, same assertion target.
+- **Assert the observable outcome**, not implementation details. If the verification confirmed "user sees order confirmation", the test asserts that text/element is visible — not that a particular function was called.
+- **Be deterministic.** No reliance on timing, network flakiness, real third-party services, or mutable shared state. Use the project's existing fixtures, factories, mocks, and seed data conventions.
+- **Be self-contained.** Set up its own preconditions and clean up after itself, following the project's existing test isolation patterns.
+- **Be named after the behavior, not the bug/ticket.** `displays order confirmation after checkout` not `fixes PROJ-1234`.
+- **Live in the project's existing test directory** for that type. Do not create a parallel test tree.
+
+For Playwright UI tests specifically:
+- Use the project's existing `test` fixture / `page` fixture / auth helper if one exists
+- Prefer role/text selectors (`getByRole`, `getByText`) over CSS/XPath — they survive markup churn
+- Capture a trace or screenshot only if the project's existing tests do; do not invent a new artifact convention
+- Mirror the project's existing config for base URL, retries, and test isolation
+
+### 4. Run the test in isolation
+
+Run only the new test, using whatever per-test invocation the project supports:
+
+- Playwright: `npx playwright test path/to/new.spec.ts`
+- Vitest: `npx vitest run path/to/new.spec.ts`
+- Jest: `npx jest path/to/new.test.ts`
+- RSpec: `bundle exec rspec path/to/new_spec.rb`
+
+Confirm:
+1. The test PASSES against the current code (the change being shipped)
+2. The test would have FAILED before the change (sanity check by mentally reverting, or for bug fixes, by running against the pre-fix commit if cheap)
+
+For a bug fix, step 2 is mandatory and easy: check out the failing commit, run the new test, see it fail, return to the fix branch. This proves the test actually guards the regression.
+
+### 5. Wire it into the suite
+
+Confirm the test is picked up by the project's standard test command (the one CI runs). Run that command and confirm the count went up by exactly the number of tests added.
+
+If the test is in a directory the standard test command excludes (e.g., E2E suite that runs separately in CI), confirm the appropriate CI workflow includes it.
+
+### 6. Commit
+
+Commit the test in the same PR as the change it codifies, in its own atomic commit:
+
+- Build/feature: `test: add e2e for <behavior>`
+- Bug fix: `test: add regression test for <bug behavior>`
+- Performance: `test: add benchmark asserting <metric> <baseline>`
+
+The commit message body should reference the verification it encodes (one line linking to the proof artifact or the verification report section).
+
+### 7. Record evidence
+
+Append to the verification report (or PR description):
+
+```markdown
+### Codified Verifications
+
+| # | Verification | Framework | Test file | Status |
+|---|--------------|-----------|-----------|--------|
+| 1 | <description> | Playwright | `e2e/checkout.spec.ts::displays order confirmation after checkout` | PASS |
+```
+
+This evidence shows the verification is now guarded.
+
+## Output
+
+For each empirical verification passed in:
+
+- A new test file (or extension to an existing test file) committed to the PR
+- Confirmation that the test passes against the current branch
+- The test file path + test name recorded in the verification report
+
+If codification was skipped, an explicit reason recorded in the report (one of the skip conditions above) — never silent.
+
+## Rules
+
+- Never claim a verification is codified without running the new test and observing it pass
+- Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change
+- Never use `expect(true).toBe(true)` placeholders or smoke-only assertions that don't actually exercise the verified behavior
+- Never reuse the verification's manual artifact (screenshot, curl output) as a "test" — those are evidence, not regression coverage
+- If the project lacks the appropriate framework, escalate via Human Action Packet rather than installing one mid-task without approval

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

@@ -1,16 +1,26 @@
 ---
 name: verification-lifecycle
-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."
+description: "Verification lifecycle: confirm quality gates, classify types, discover tools, fail fast, plan, execute, codify (turn each passing verification into a regression test), spec conformance (verify shipped work matches the spec), 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: confirm quality gates, 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, codify (turn each passing verification into a regression test), spec conformance (verify shipped work matches the spec), and loop.
 
 ## Verification Lifecycle
 
 Agents must follow this mandatory sequence for every change:
 
+1. Confirm Quality Gates
+2. Classify
+3. Check Tooling
+4. Fail Fast (if blocked)
+5. Plan
+6. Execute
+7. Codify (turn each passing verification into a regression test)
+8. Spec Conformance
+9. Loop
+
 ### 1. Confirm Quality Gates
 
 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.
@@ -42,7 +52,17 @@ A verification plan that only lists `bun run test`, `bun run typecheck`, or `bun
 
 After implementation, run the verification plan. Execute each verification type in order.
 
-### 7. Spec Conformance
+### 7. Codify
+
+After each empirical verification produces PASS evidence, invoke the `codify-verification` skill to encode the verification as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
+
+The `codify-verification` skill maps the verification type to the appropriate framework (Playwright for browser/UI, integration test for API/DB/auth, benchmark for performance, etc.), generates a deterministic test that asserts the same observable outcome the verification just confirmed, runs it in isolation to confirm PASS, and commits it in the same PR as the change.
+
+Codification is mandatory for every empirical verification type with one exception set: PR, Documentation, Deploy, and Investigate-Only spikes — those have inherently non-behavioral proof. For every other type, skipping codification is not allowed; if codification is genuinely impossible (e.g., the test framework does not exist and cannot be installed in scope), escalate via the Escalation Protocol rather than silently skipping.
+
+A change is not "verified" in the lifecycle sense until each empirical verification has both passed AND been codified.
+
+### 8. Spec Conformance
 
 After empirical verification produces evidence, run spec conformance as a separate, mandatory step. Invoke the `spec-conformance` skill (or delegate to the `spec-conformance-specialist` agent) with the spec source — plan file, JIRA/Linear/GitHub key, or PRD.
 
@@ -56,9 +76,9 @@ Required outputs:
 
 `PARTIAL` or `DIVERGES` blocks completion. Fix the gaps (implement the miss, remove the creep, capture the missing evidence) and re-run both empirical verification AND spec conformance. Never skip this step — it catches failures that empirical verification by itself does not, such as a feature that works but wasn't asked for, or a spec item that was quietly dropped.
 
-### 8. Loop
+### 9. Loop
 
-If any verification or spec-conformance check fails, fix the issue and re-verify. Do not declare done until all required types pass AND the spec-conformance verdict is `CONFORMS`. If a verification or conformance check is stuck after 3 attempts, escalate.
+If any verification, codification, or spec-conformance check fails, fix the issue and re-verify. Do not declare done until all required types pass, all empirical verifications are codified, AND the spec-conformance verdict is `CONFORMS`. If a verification, codification, or conformance check is stuck after 3 attempts, escalate.
 
 ---
 
@@ -194,9 +214,10 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 8. Implement the change.
 9. Execute verification plan — run the actual system and observe results.
 10. Collect proof artifacts.
-11. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
-12. Summarize what changed, what was verified, conformance verdict, and remaining risk.
-13. Label the result with a verification level.
+11. Codify — for each passing empirical verification, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
+12. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
+13. Summarize what changed, what was verified, what was codified, conformance verdict, and remaining risk.
+14. Label the result with a verification level.
 
 ---
 
@@ -305,9 +326,10 @@ A task is done only when:
 
 - End user is identified
 - All applicable verification types are classified and executed
-- Verification lifecycle is completed (classify, check tooling, plan, execute, spec conformance, loop)
+- Verification lifecycle is completed (classify, check tooling, plan, execute, codify, spec conformance, loop)
 - Required verification surfaces and tooling surfaces are used or explicitly unavailable
 - Proof artifacts are captured
+- Every passing empirical verification is codified as a regression test (or has an explicit, documented skip reason from the allowed set)
 - Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)
 - Verification level is declared
 - Risks and gaps are documented

package/plugins/src/base/skills/verify/SKILL.md

@@ -18,12 +18,13 @@ If you ARE already inside an agent team (e.g., a teammate invoked this skill via
 
 Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The flow includes:
 
-1. **Commit** any pending changes via `lisa:git-commit`
-2. **Push and PR** via `lisa:git-submit-pr`
-3. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
-4. **Merge** when CI is green
-5. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined)
-6. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter)
+1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. A change cannot ship until its verifications are guarded.
+2. **Commit** any pending changes via `lisa:git-commit`
+3. **Push and PR** via `lisa:git-submit-pr`
+4. **Review loop** — handle CodeRabbit / human review comments via `lisa:pull-request-review`
+5. **Merge** when CI is green
+6. **Remote verification** — invoke the `lisa:monitor` skill against the target environment to confirm the deploy actually works (health endpoints, recent logs/errors, Validation Journey replay if defined). If remote verification surfaces a behavioral gap that the existing codified tests do not guard, invoke `codify-verification` to add coverage and open a follow-up PR.
+7. **Evidence** — post results to the originating ticket via `lisa:jira-evidence` (or equivalent tracker adapter), including the list of codified tests added on this branch.
 
 The rule contains the canonical step sequence. Change it there, propagate everywhere.