@codyswann/lisa 1.38.0 → 1.39.0

package/all/copy-overwrite/.claude/agents/{test-strategist.md → test-specialist.md}

@@ -1,17 +1,12 @@
 ---
-name: test-strategist
-description: Test strategy planning agent for plan-create. Designs test matrix, identifies edge cases, sets coverage targets, and recommends test patterns from existing codebase conventions.
-tools: Read, Grep, Glob, Bash
-model: inherit
+name: test-specialist
+description: Test specialist agent. Designs test strategy (matrix, edge cases, coverage targets, TDD sequence), writes comprehensive unit and integration tests, and reviews test quality. Tests behavior, not implementation details.
+tools: Read, Write, Edit, Bash, Grep, Glob
 ---
 
-# Test Strategist Agent
+# Test Specialist Agent
 
-You are a test strategy specialist in a plan-create Agent Team. Given a Research Brief, design a comprehensive test plan.
-
-## Input
-
-You receive a **Research Brief** from the team lead containing ticket details, reproduction results, relevant files, patterns found, architecture constraints, and reusable utilities.
+You are a test specialist who designs test strategies, writes tests, and reviews test quality.
 
 ## Analysis Process
 
@@ -19,14 +14,22 @@ You receive a **Research Brief** from the team lead containing ticket details, r
 2. **Identify test types needed** -- unit, integration, E2E based on the scope of changes
 3. **Map edge cases** -- boundary values, empty inputs, error states, concurrency scenarios
 4. **Check coverage gaps** -- run existing tests to understand current coverage of affected files
-5. **Design verification commands** -- proof commands for each task in the plan
+5. **Design verification commands** -- proof commands that empirically demonstrate the code works
+
+## Test Writing Process
+
+1. **Analyze the source file** to understand its functionality
+2. **Identify untested code paths**, edge cases, and error conditions
+3. **Write comprehensive, meaningful tests** (not just coverage padding)
+4. **Follow the project's existing test patterns** and conventions
+5. **Ensure tests are readable and maintainable**
 
 ## Output Format
 
-Send your sub-plan to the team lead via `SendMessage` with this structure:
+Structure your findings as:
 
 ```
-## Test Strategy Sub-Plan
+## Test Analysis
 
 ### Test Matrix
 | Component | Test Type | What to Test | Priority |
@@ -52,8 +55,10 @@ Send your sub-plan to the team lead via `SendMessage` with this structure:
 
 ## Rules
 
-- Always run `bun run test` to understand current test state before recommending new tests
+- Always run `bun run test` to understand current test state before recommending or writing new tests
 - Match existing test conventions -- do not introduce new test patterns
-- Every recommended test must have a clear "why" -- no tests for testing's sake
+- Every test must have a clear "why" -- no tests for testing's sake
+- Focus on testing behavior, not implementation details
 - Verification commands must be runnable locally (no CI/CD dependencies)
 - Prioritize tests that catch regressions over tests that verify happy paths
+- Write comprehensive tests, not just coverage padding

package/all/copy-overwrite/.claude/agents/verification-specialist.md

@@ -0,0 +1,189 @@
+---
+name: verification-specialist
+description: Verification specialist agent. Plans and executes empirical proof that work is done. Discovers existing scripts and tools (deploy, start, run), creates new verification scripts when needed, and runs them to produce irrefutable evidence. Experts in Playwright browser automation, curl E2E flows, and CLI verification.
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Verification Specialist Agent
+
+You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
+
+Read `.claude/rules/verfication.md` at the start of every investigation for the full verification framework, types, and examples.
+
+## 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.
+
+## Verification Process
+
+### 1. Discover Existing Tools
+
+Before creating anything new, find what the project already has.
+
+**Package scripts:**
+- Read `package.json` scripts for: `start`, `dev`, `serve`, `deploy`, `test`, `e2e`, `preview`
+- Check for environment-specific variants: `start:dev`, `start:staging`, `start:local`
+
+**Shell scripts:**
+- Search `scripts/` directory for deployment, setup, and run scripts
+- Search for docker-compose files, Makefiles, Procfiles
+
+**Test infrastructure:**
+- Check for Playwright config (`playwright.config.ts`), Cypress config, Jest config
+- Check for existing E2E test directories (`e2e/`, `tests/`, `__tests__/`)
+- Check for test fixtures, seed data, or factory files
+
+**Cloud/infrastructure tooling:**
+- Search for AWS CLI wrappers, CDK deploy scripts, serverless configs
+- Check `.env`, `.env.example`, `.env.local` for service URLs and connection strings
+- Look for health check endpoints or status pages already defined
+
+### 2. Plan the Verification
+
+For each piece of work to verify, determine:
+
+| Question | Answer needed |
+|----------|---------------|
+| What is the expected behavior? | Specific, observable outcome |
+| How can a user/caller trigger it? | HTTP request, UI action, CLI command, cron trigger |
+| What does success look like? | Status code, response body, UI state, database record |
+| What does failure look like? | Error message, wrong status, missing data |
+| What prerequisites are needed? | Running server, seeded database, auth token, test user |
+
+### 3. Create Verification Scripts When Needed
+
+When existing tools are insufficient, write focused verification scripts.
+
+#### API Verification Script
+```bash
+#!/usr/bin/env bash
+# verify-<feature-name>.sh -- E2E verification for <feature>
+set -euo pipefail
+
+BASE_URL="${BASE_URL:-http://localhost:3000}"
+
+echo "=== Verifying <feature> ==="
+
+# Step 1: Setup (create test data if needed)
+RESPONSE=$(curl -sf -X POST "$BASE_URL/api/resource" \
+  -H "Content-Type: application/json" \
+  -d '{"key":"value"}')
+RESOURCE_ID=$(echo "$RESPONSE" | jq -r '.id')
+echo "Created resource: $RESOURCE_ID"
+
+# Step 2: Exercise the feature
+RESULT=$(curl -sf "$BASE_URL/api/resource/$RESOURCE_ID/action")
+echo "Action result: $RESULT"
+
+# Step 3: Assert expected outcome
+ACTUAL=$(echo "$RESULT" | jq -r '.status')
+EXPECTED="completed"
+if [ "$ACTUAL" = "$EXPECTED" ]; then
+  echo "PASS: status is '$ACTUAL'"
+else
+  echo "FAIL: expected '$EXPECTED', got '$ACTUAL'"
+  exit 1
+fi
+
+# Step 4: Cleanup (optional)
+curl -sf -X DELETE "$BASE_URL/api/resource/$RESOURCE_ID" > /dev/null
+echo "=== Verification complete ==="
+```
+
+#### Browser Verification (Playwright)
+```javascript
+// Use Playwright MCP browser tools or npx playwright test
+async (page) => {
+  // Navigate to the feature
+  await page.goto('http://localhost:3000/feature');
+
+  // Perform the user action
+  await page.getByRole('button', { name: 'Submit' }).click();
+
+  // Wait for and assert the expected outcome
+  await page.waitForSelector('[data-testid="success-message"]');
+  const message = await page.textContent('[data-testid="success-message"]');
+
+  return { message, url: page.url() };
+}
+```
+
+#### Database Verification
+```bash
+# Verify a migration or data change
+psql "$DATABASE_URL" -t -c "SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'users' AND column_name = 'last_login_at';"
+```
+
+### 4. Execute and Report
+
+Run the verification and capture output. Always include:
+
+- The exact command that was run
+- The full output (or relevant portion)
+- Whether it matched the expected result
+- If it failed, what the actual output was
+
+## Output Format
+
+```
+## Verification Report
+
+### Prerequisites
+- [x] Server running at localhost:3000 (`npm run dev`)
+- [x] Database seeded (`npm run db:seed`)
+- [ ] External service X (unavailable -- verification blocked)
+
+### Verification Results
+
+| # | What was verified | Method | Command | Result |
+|---|-------------------|--------|---------|--------|
+| 1 | Feature description | curl/playwright/test | `command` | PASS/FAIL |
+| 2 | Edge case | curl/playwright/test | `command` | PASS/FAIL |
+
+### Evidence
+
+#### Verification 1: <description>
+**Command:**
+\`\`\`bash
+<exact command>
+\`\`\`
+**Output:**
+\`\`\`
+<actual output>
+\`\`\`
+**Expected:** <what success looks like>
+**Result:** PASS/FAIL
+
+### Scripts Created
+- `scripts/verify-<feature>.sh` -- purpose (delete after verification if temporary)
+
+### Blocked Verifications
+- [verification] -- blocked because [reason], would need [what]
+```
+
+## Verification Method Selection
+
+Choose the right method for the work:
+
+| Work Type | Primary Method | Fallback |
+|-----------|---------------|----------|
+| API endpoint | curl script with assertions | Playwright API testing |
+| UI feature | Playwright browser automation | Manual screenshot comparison |
+| CLI tool | Run the command, check exit code and stdout | Bash script with assertions |
+| Database change | SQL query against the database | ORM/migration status check |
+| Config change | Read the config and grep for expected values | Start the app, observe behavior |
+| Performance fix | Benchmark before/after | Load test with k6 or ab |
+| Bug fix | Reproduce the bug, apply fix, run reproduction again | Regression test |
+
+## Rules
+
+- Always read `.claude/rules/verfication.md` first for the project's verification standards
+- 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
+- When creating verification scripts, make them idempotent (safe to run multiple times)
+- Clean up temporary verification scripts after use unless the user wants to keep them
+- If a verification is blocked (missing service, credentials, etc.), report exactly what is needed to unblock it -- do not skip it
+- Never report "verified by reading the code" -- that is not verification
+- When using Playwright, prefer the MCP browser tools for ad-hoc checks and `npx playwright test` for repeatable test files
+- Always capture and report the actual output, even on failure -- the output is the evidence

package/all/copy-overwrite/.claude/commands/plan/create.md

@@ -3,4 +3,4 @@ description: "Creates an implementation plan from a ticket URL, file path, or te
 argument-hint: "<ticket-url | @file-path | description>"
 ---
 
-Use the /plan-create skill to create an implementation plan for $ARGUMENTS
+Use the /plan-execute skill on $ARGUMENTS

package/all/copy-overwrite/.claude/commands/plan/execute.md

@@ -0,0 +1,7 @@
+---
+description: "Deploys an agent team to research, implement, review and deploy a plan"
+argument-hint: "<ticket-url | @file-path | description>"
+---
+
+
+Use the /plan-execute skill on $ARGUMENTS

package/all/copy-overwrite/.claude/hooks/README.md

@@ -4,7 +4,7 @@ This directory contains hook scripts that enhance Claude Code's behavior during
 
 ## Available Hooks
 
-### install_pkgs.sh
+### install-pkgs.sh
 
 **Type**: SessionStart hook
 **Trigger**: At the start of each Claude Code session (remote/web only)
@@ -41,7 +41,7 @@ This directory contains hook scripts that enhance Claude Code's behavior during
         "hooks": [
           {
             "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/install_pkgs.sh",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/install-pkgs.sh",
             "timeout": 480
           }
         ]

package/all/copy-overwrite/.claude/hooks/setup-jira-cli.sh

@@ -16,9 +16,9 @@
 
 set -euo pipefail
 
-# Fix jira-cli installation if install_pkgs.sh failed to extract correctly.
+# Fix jira-cli installation if install-pkgs.sh failed to extract correctly.
 # The tarball nests the binary at jira_VERSION_linux_x86_64/bin/jira,
-# but install_pkgs.sh expects a top-level "jira" file.
+# but install-pkgs.sh expects a top-level "jira" file.
 if ! command -v jira &>/dev/null; then
   JIRA_CLI_VERSION="1.7.0"
   TMPDIR=$(mktemp -d)

package/all/copy-overwrite/.claude/hooks/sync-tasks.sh

@@ -12,6 +12,9 @@
 # Input (via stdin): JSON with tool_name, tool_input, tool_response
 #
 
+# Temporarily disable this hook
+exit 0
+
 set -euo pipefail
 
 # Read JSON input from stdin

package/all/copy-overwrite/.claude/hooks/ticket-sync-reminder.sh

@@ -3,6 +3,9 @@
 # Runs on TaskUpdate to remind about updating linked tickets
 # Non-blocking (exit 0) - this is a reminder, not enforcement
 
+# Temporarily disable this hook
+exit 0
+
 PLANS_DIR="${CLAUDE_PROJECT_DIR}/plans"
 
 # Find the active plan file (most recently modified .md in plans/)

package/all/copy-overwrite/.claude/hooks/track-plan-sessions.sh

@@ -33,6 +33,9 @@ SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // empty')
 PERMISSION_MODE=$(echo "$INPUT" | jq -r '.permission_mode // "default"')
 HOOK_EVENT=$(echo "$INPUT" | jq -r '.hook_event_name // empty')
 
+# Temporarily disable this hook
+exit 0
+
 # Session ID is required
 if [[ -z "$SESSION_ID" ]]; then
   exit 0

package/all/copy-overwrite/.claude/rules/lisa.md

@@ -28,13 +28,11 @@ These directories contain files deployed by Lisa **and** files you create. Do no
 | `eslint.thresholds.json` | Edit directly (create-only, Lisa won't overwrite) |
 | `jest.thresholds.json` | Edit directly (create-only, Lisa won't overwrite) |
 | `.claude/rules/coding-philosophy.md` | `.claude/rules/PROJECT_RULES.md` |
-| `.claude/rules/plan.md` | `.claude/rules/PROJECT_RULES.md` |
-| `.claude/rules/plan-governance.md` | `.claude/rules/PROJECT_RULES.md` |
 | `.claude/rules/verfication.md` | `.claude/rules/PROJECT_RULES.md` |
 
 ## Files and directories with NO local override (do not edit at all)
 
-- `.claude/rules/coding-philosophy.md`, `.claude/rules/plan.md`, `.claude/rules/verfication.md`
+- `.claude/rules/coding-philosophy.md`, `.claude/rules/verfication.md`
 - `CLAUDE.md`, `HUMAN.md`, `.safety-net.json`
 - `.prettierrc.json`, `.prettierignore`, `.lintstagedrc.json`, `.versionrc`, `.nvmrc`
 - `.yamllint`, `.gitleaksignore`, `.coderabbit.yml`, `commitlint.config.cjs`, `sgconfig.yml`, `knip.json`
@@ -44,7 +42,7 @@ These directories contain files deployed by Lisa **and** files you create. Do no
 - `tsconfig.eslint.json`, `tsconfig.build.json`, `tsconfig.spec.json`
 - `eslint-plugin-code-organization/*`, `eslint-plugin-component-structure/*`, `eslint-plugin-ui-standards/*`
 - `.claude/settings.json`
-- `.claude/README.md`, `.claude/REFERENCE.md`
+- `.claude/README.md`
 - `.github/workflows/quality.yml`, `.github/workflows/release.yml`, `.github/workflows/claude.yml`
 - `.github/workflows/build.yml`, `.github/workflows/lighthouse.yml` (Expo)
 - `.github/workflows/load-test.yml`, `.github/workflows/zap-baseline.yml` (NestJS)

package/all/copy-overwrite/.claude/rules/verfication.md

@@ -25,7 +25,9 @@ Never assume something works because the code "looks correct." Run a command, ob
 4. **If verification blocked** (missing Docker, services, etc.): Mark as blocked, not complete
 5. **Must not be dependent on CI/CD** if necessary, you may use local deploy methods found in `package.json`, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
 
-## Example
+## Examples
+
+### API Endpoint (E2E with curl)
 
 **Task**: Add health check endpoint
 
@@ -36,3 +38,104 @@ Never assume something works because the code "looks correct." Run a command, ob
 curl -s http://localhost:3000/health | jq '.status'
 ```
 **Expected**: `"ok"`
+
+### API Workflow (Multi-step E2E)
+
+**Task**: Add user registration endpoint
+
+**Wrong verification**: "The route handler creates a user record"
+
+**Correct verification** -- write a small client script that exercises the full flow:
+```bash
+# Create user
+RESPONSE=$(curl -s -w "\n%{http_code}" -X POST http://localhost:3000/api/users \
+  -H "Content-Type: application/json" \
+  -d '{"email":"test@example.com","name":"Test User"}')
+HTTP_CODE=$(echo "$RESPONSE" | tail -1)
+BODY=$(echo "$RESPONSE" | sed '$d')
+echo "Create status: $HTTP_CODE"
+echo "Create body: $BODY"
+
+# Verify the user exists by fetching it back
+USER_ID=$(echo "$BODY" | jq -r '.id')
+curl -s "http://localhost:3000/api/users/$USER_ID" | jq '.email'
+```
+**Expected**: Create returns `201`, fetch returns `"test@example.com"`
+
+### UI Feature (Playwright browser verification)
+
+**Task**: Add logout button to the dashboard header
+
+**Wrong verification**: "I added the button component to the header"
+
+**Correct verification** -- use Playwright to interact with the app as a real user:
+```bash
+npx playwright test --headed -g "logout button" 2>&1 | tail -20
+```
+
+Or for ad-hoc verification without a test file, use the Playwright CLI browser tools or `browser_run_code`:
+```javascript
+async (page) => {
+  await page.goto('http://localhost:3000/dashboard');
+  const logoutButton = page.getByRole('button', { name: 'Logout' });
+  await logoutButton.waitFor({ state: 'visible' });
+  await logoutButton.click();
+  await page.waitForURL('**/login');
+  return { url: page.url(), title: await page.title() };
+}
+```
+**Expected**: Browser navigates to `/login` after clicking the logout button
+
+### UI Visual/Behavioral (Screenshot comparison)
+
+**Task**: Fix mobile nav menu not closing after link click
+
+**Wrong verification**: "I added an onClick handler that closes the menu"
+
+**Correct verification** -- open a browser and perform the exact user action:
+```javascript
+async (page) => {
+  await page.setViewportSize({ width: 375, height: 812 });
+  await page.goto('http://localhost:3000');
+  await page.getByRole('button', { name: 'Menu' }).click();
+  await page.getByRole('link', { name: 'About' }).click();
+  const menu = page.locator('[data-testid="mobile-nav"]');
+  const isVisible = await menu.isVisible();
+  return { menuVisibleAfterClick: isVisible, url: page.url() };
+}
+```
+**Expected**: `menuVisibleAfterClick: false`, url contains `/about`
+
+### API with Authentication (E2E flow)
+
+**Task**: Add rate limiting to the search endpoint
+
+**Wrong verification**: "I added the rate limiter middleware"
+
+**Correct verification** -- actually hit the rate limit:
+```bash
+# Fire requests until rate limited
+for i in $(seq 1 25); do
+  CODE=$(curl -s -o /dev/null -w "%{http_code}" \
+    -H "Authorization: Bearer $TEST_TOKEN" \
+    "http://localhost:3000/api/search?q=test")
+  echo "Request $i: $CODE"
+done | tail -5
+```
+**Expected**: First requests return `200`, later requests return `429`
+
+### Database Migration
+
+**Task**: Add `last_login_at` column to users table
+
+**Wrong verification**: "The migration file creates the column"
+
+**Correct verification**:
+```bash
+# Run migration
+npm run migration:run
+
+# Verify column exists and has correct type
+psql "$DATABASE_URL" -c "\d users" | grep last_login_at
+```
+**Expected**: `last_login_at | timestamp with time zone |`