@codyswann/lisa 1.67.2 → 1.68.0

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

@@ -0,0 +1,292 @@
+---
+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."
+---
+
+# 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.
+
+## Verification Lifecycle
+
+Agents must follow this mandatory sequence for every change:
+
+### 1. Classify
+
+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.
+
+### 2. 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.
+
+### 3. 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
+
+For each verification type, state:
+- The specific tool or command that will be used
+- The expected outcome that constitutes a pass
+- Any prerequisites (running server, seeded database, auth token)
+
+### 5. Execute
+
+After implementation, run the verification plan. Execute each verification type in order.
+
+### 6. 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.
+
+---
+
+## Tool Discovery Process
+
+Agents must discover available tools at runtime rather than assuming what exists. Check these locations in order:
+
+1. **Project manifest** — Read the project manifest file for available scripts (build, test, lint, deploy, start, etc.) and their variants
+2. **Script directories** — Search for shell scripts, automation files, and task runners in common locations (`scripts/`, `bin/`, project root)
+3. **Configuration files** — Look for test framework configs, linter configs, formatter configs, deployment configs, and infrastructure-as-code definitions
+4. **MCP tools** — Check available MCP server tools for browser automation, observability, issue tracking, and other capabilities
+5. **CLI tools** — Check for available command-line tools relevant to the verification type (database clients, HTTP clients, cloud CLIs, container runtimes)
+6. **Environment files** — Read environment configuration for service URLs, connection strings, and feature flags that indicate available services
+7. **Documentation** — Check project README, CLAUDE.md, and rules files for documented verification procedures
+
+If a tool is expected but not found, report the gap rather than assuming it doesn't exist — it may need to be installed or configured.
+
+---
+
+## Verification Surfaces
+
+Agents may only self-verify when the required verification surfaces are available.
+
+Verification surfaces include:
+
+### Action Surfaces
+
+- Build and test execution
+- Deployment and rollback
+- Infrastructure apply and drift detection
+- Feature flag toggling
+- Data seeding and state reset
+- Load generation and fault injection
+
+### Observation Surfaces
+
+- Application logs (local and remote)
+- Metrics (latency, errors, saturation, scaling)
+- Traces and correlation IDs
+- Database queries and schema inspection
+- Browser and device automation
+- Queue depth and consumer execution visibility
+- CDN headers and edge behavior
+- Artifact capture (video, screenshots, traces, diffs)
+
+If a required surface is unavailable, agents must follow the Escalation Protocol.
+
+---
+
+## Tooling Surfaces
+
+Many verification steps require tools that may not be available by default.
+
+Tooling surfaces include:
+
+- Required CLIs (cloud, DB, deployment, observability)
+- Required MCP servers and their capabilities
+- Required internal APIs (feature flags, auth, metrics, logs, CI)
+- Required credentials and scopes for those tools
+
+If required tooling is missing, misconfigured, blocked, undocumented, or inaccessible, agents must treat this as a verification blocker and escalate before proceeding.
+
+---
+
+## Proof Artifacts Requirements
+
+Every completed task must include proof artifacts stored in the PR description or linked output location.
+
+Proof artifacts must be specific and re-checkable. A proof artifact should contain enough detail that another agent or human can reproduce the verification independently.
+
+Acceptable proof includes:
+- Automated session recordings and screenshots for UI work
+- Request/response captures for API work
+- Before/after query outputs for data work
+- Metrics snapshots for performance and scaling work
+- Log excerpts with correlation IDs for behavior validation
+- Benchmark results with methodology for performance work
+
+Statements like "works" or "should work" are not acceptable.
+
+---
+
+## Self-Correction Loop
+
+Verification is not a one-shot activity. Agents operate within a three-layer self-correction architecture that catches errors at increasing scope. Each layer is enforced automatically — agents do not need to invoke them manually.
+
+### Layer 1 — Inline Correction
+
+**Trigger:** Every file write or edit.
+
+Hooks run formatting, structural analysis, and linting on the single file just written. Errors are reported immediately so the agent can fix them before writing more files. This prevents error accumulation across multiple files.
+
+**Agent responsibility:** When a hook blocks, fix the reported errors in the same file before proceeding to other files. Do not accumulate errors.
+
+### Layer 2 — Commit-Time Enforcement
+
+**Trigger:** Every commit.
+
+Checks run on staged files: linting, formatting, secret detection, commit message validation, and branch protection. This layer catches errors that span multiple files or involve staged-but-not-yet-checked changes.
+
+Commit-time checks cannot be bypassed. Agents must discover what specific checks are enforced by reading the project's hook configuration.
+
+### Layer 3 — Push-Time Enforcement
+
+**Trigger:** Every push.
+
+The full project quality gate runs: test suites with coverage thresholds, type checking, security audits, unused export detection, and integration tests. This is the last automated checkpoint before code reaches the remote.
+
+**Handling failures:** When a push fails, read the error output to determine which check failed. Fix the root cause rather than working around it. Agents must discover what specific checks are enforced by reading the project's hook configuration.
+
+### Regeneration Over Patching
+
+When the root cause of errors is architectural (wrong abstraction, incorrect data flow, fundamentally broken approach), delete and regenerate rather than incrementally patching. Incremental patches on a broken foundation accumulate tech debt faster than the self-correction loop can catch it.
+
+Signs that regeneration is needed:
+- The same file has been edited 3+ times in the same loop without converging
+- Fixing one error introduces another in the same file
+- The fix requires disabling a lint rule or adding a type assertion
+
+---
+
+## Standard Workflow
+
+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.
+
+---
+
+## Task Completion Rules
+
+1. **Run the proof command** before marking any task complete
+2. **Compare output** to expected result
+3. **If verification fails**: Fix and re-run, don't mark complete
+4. **If verification blocked** (missing tools, 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 the project manifest, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
+
+---
+
+## Escalation Protocol
+
+Agents must escalate when verification is blocked, ambiguous, or requires tools that are missing or inaccessible.
+
+Common blockers:
+
+- VPN required
+- MFA, OTP, SMS codes
+- Hardware token requirement
+- Missing CLI, MCP server, or internal API required for verification
+- Missing documentation on how to access required tooling
+- Production-only access gates
+- Compliance restrictions
+
+When blocked, agents must do the following:
+
+1. Identify the exact boundary preventing verification.
+2. Identify which verification surfaces and tooling surfaces are missing.
+3. Attempt safe fallback verification (local, staging, mocks) and label it clearly.
+4. Declare verification level as PARTIALLY VERIFIED or UNVERIFIED.
+5. Produce a Human Action Packet.
+6. Pause until explicit human confirmation or tooling is provided.
+
+Agents must never proceed past an unverified boundary without surfacing it to the human overseer.
+
+### Human Action Packet Format
+
+Agents must provide:
+
+- What is blocked and why
+- What tool or access is missing
+- Exactly what the human must do
+- How to confirm completion
+- What the agent will do immediately after
+- What artifacts the agent will produce after access is restored
+
+Example:
+
+- Blocked: Cannot reach DB, VPN required.
+- Missing: Database client access to `db.host` and internal logs viewer.
+- Human steps: Connect VPN "CorpVPN", confirm access by running connectivity check to `db.host`, provide credentials or endpoint.
+- Confirmation: Reply "VPN ACTIVE" and "ACCESS READY".
+- Next: Agent runs migration verification script and captures schema diff and query outputs.
+
+Agents must pause until explicit human confirmation.
+
+Agents must never bypass security controls to proceed.
+
+---
+
+## Environments and Safety Rules
+
+### Allowed Environments
+
+- Local development
+- Preview environments
+- Staging
+- Production read-only, only if explicitly approved and configured for safe access
+
+### Prohibited Actions Without Human Approval
+
+- Writing to production data stores
+- Disabling MFA or security policies
+- Modifying IAM roles or firewall rules beyond scoped change requests
+- Running destructive migrations
+- Triggering external billing or payment flows
+
+If an operation is irreversible or risky, escalate first.
+
+---
+
+## Artifact Storage and PR Requirements
+
+Every PR must include:
+
+- Goal summary
+- Verification level
+- Proof artifacts links or embedded outputs
+- How to reproduce verification locally
+- Known limitations and follow-up items
+
+Preferred artifact locations:
+
+- PR description
+- Repo-local scripts under `scripts/verification/`
+- CI artifacts linked from the build
+
+---
+
+## Definition of Done
+
+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, loop)
+- Required verification surfaces and tooling surfaces are used or explicitly unavailable
+- Proof artifacts are captured
+- Verification level is declared
+- Risks and gaps are documented
+
+If any of these are missing, the work is not complete.

package/typescript/copy-overwrite/eslint.ignore.config.json

@@ -33,6 +33,7 @@
     ".claude-active-project/**",
     ".claude-active-plan/**",
     "coverage/**",
+    "**/coverage/**",
     "**/*spec.ts",
     "resolver-test.setup.ts",
     "**/*.factory.ts",

package/expo/copy-overwrite/.claude/rules/expo-verification.md

@@ -1,261 +0,0 @@
-# Expo Verification Capabilities
-
-This rule documents the native and web verification surfaces available in Expo projects. Agents must use these tools when verifying UI changes, features, and bugs.
-
----
-
-## Environment Strategy
-
-Frontend changes are typically verified against the **remote dev backend**, not a local backend. The backend is generally deployed before the frontend, so the dev environment is the default target for verification.
-
-Use `:local` variants only when explicitly running the companion backend repo locally. Use `:dev` for most verification work.
-
----
-
-## Native Simulator Testing
-
-Expo manages simulator and emulator lifecycle directly. Never use `xcrun simctl` or manual emulator commands.
-
-### Start Dev Server with Simulator
-
-These commands copy the target environment file, launch the Expo dev server, and open the app in the simulator automatically:
-
-```bash
-# iOS Simulator
-bun run start:simulator:ios:local       # Against local backend
-bun run start:simulator:ios:dev         # Against dev backend (default for verification)
-bun run start:simulator:ios:staging     # Against staging backend
-bun run start:simulator:ios:production  # Against production backend
-
-# Android Emulator
-bun run start:simulator:android:local       # Against local backend
-bun run start:simulator:android:dev         # Against dev backend (default for verification)
-bun run start:simulator:android:staging     # Against staging backend
-bun run start:simulator:android:production  # Against production backend
-```
-
-### Build Native Binary and Run on Simulator
-
-These commands compile a full native binary and install it on the simulator. Slower than dev server but closer to production:
-
-```bash
-# iOS Simulator
-bun run build-and-run:simulator:ios:local       # Against local backend
-bun run build-and-run:simulator:ios:dev         # Against dev backend
-bun run build-and-run:simulator:ios:staging     # Against staging backend
-bun run build-and-run:simulator:ios:production  # Against production backend
-
-# Android Emulator
-bun run build-and-run:simulator:android:local       # Against local backend
-bun run build-and-run:simulator:android:dev         # Against dev backend
-bun run build-and-run:simulator:android:staging     # Against staging backend
-bun run build-and-run:simulator:android:production  # Against production backend
-```
-
-Use `build-and-run` when testing native modules, push notifications, deep linking, or any feature that requires a full native build.
-
-### Dev Server Only (Manual Simulator Selection)
-
-```bash
-bun run start:local   # Start dev server, then press 'i' for iOS or 'a' for Android
-```
-
----
-
-## Native E2E Testing with Maestro
-
-Maestro provides automated native UI testing on simulators and emulators.
-
-### Run All Flows
-
-```bash
-bun run maestro:test
-```
-
-### Run Smoke Tests Only
-
-```bash
-bun run maestro:test:smoke
-```
-
-### Interactive Flow Development
-
-```bash
-bun run maestro:studio
-```
-
-Maestro flows live in `.maestro/flows/`. Tag flows with `smoke` for the smoke test subset.
-
----
-
-## Web Testing with Playwright
-
-### Run Playwright Tests
-
-```bash
-bun run playwright:test          # Build and run all tests
-bun run playwright:test:ui       # Build and run with interactive UI
-```
-
-### Ad-Hoc Browser Verification
-
-Use the Playwright MCP tools (`browser_snapshot`, `browser_click`, `browser_take_screenshot`, `browser_navigate`, `browser_console_messages`, `browser_network_requests`) for interactive browser verification without writing test files.
-
----
-
-## Cross-Repo Log Correlation
-
-When debugging frontend issues, errors often originate on the server side. Agents must check both client and server logs to diagnose problems.
-
-### Client-Side Logs
-
-Use the Playwright MCP tools to capture browser logs during verification:
-
-- `browser_console_messages` — Console output (errors, warnings, info, debug)
-- `browser_network_requests` — Failed API calls, status codes, response payloads
-
-For native simulators, check the Expo dev server terminal output for Metro bundler errors and React Native logs.
-
-### Server-Side Logs
-
-When the frontend is configured as an additional working directory alongside a companion backend repo (or vice versa), agents have access to both codebases. Use this to:
-
-1. **Read the backend's CLAUDE.md and verification rules** to understand how to check server logs
-2. **Check backend logs locally** if the backend is running via `bun run start:local` in the companion repo
-3. **Check remote logs** using whatever observability tools the backend documents (CloudWatch, Sentry, etc.)
-
-### Debugging Workflow
-
-When a frontend action produces an error:
-
-1. **Capture the client error** — Use `browser_console_messages` and `browser_network_requests` to identify the failing request (URL, status code, error body)
-2. **Correlate with server logs** — Use the companion backend repo's documented log-checking tools to find the corresponding server-side error
-3. **Identify the root cause** — Determine whether the issue is a frontend bug (bad request, missing field, wrong query) or a backend bug (server error, schema mismatch, auth failure)
-4. **Document both sides** — Include client and server log excerpts in proof artifacts
-
-This cross-repo correlation is especially valuable for:
-
-- GraphQL query errors (client sends bad query vs. server resolver failure)
-- Authentication failures (expired token vs. misconfigured auth)
-- Data inconsistencies (frontend cache staleness vs. backend data issue)
-- Network errors (frontend timeout vs. backend performance)
-
----
-
-## Deployment
-
-### Authentication
-
-Before deploying, ensure you are logged into EAS:
-
-```bash
-bun run eas:whoami    # Check current login status
-bun run eas:login     # Log in to Expo account (interactive)
-```
-
-### EAS Build (Full Native Deploy)
-
-`eas:deploy` triggers a full native build in the EAS cloud. Use this when native code has changed (new native modules, SDK upgrades, native config changes). Builds take several minutes.
-
-```bash
-bun run eas:deploy:dev           # Build for dev environment
-bun run eas:deploy:staging       # Build for staging environment
-bun run eas:deploy:production    # Build for production environment
-```
-
-Build profiles are defined in `eas.json`. Each profile specifies its channel, environment variables, and distribution settings.
-
-### EAS Update (OTA Publish)
-
-`eas:publish` pushes an over-the-air JavaScript bundle update. Use this for JS-only changes (bug fixes, UI tweaks, logic changes) that don't require a new native build. Updates are fast (seconds, not minutes).
-
-```bash
-bun run eas:publish:dev          # Publish OTA update to dev channel
-bun run eas:publish:staging      # Publish OTA update to staging channel
-bun run eas:publish:production   # Publish OTA update to production channel
-```
-
-### When to Use Build vs Update
-
-| Scenario | Command |
-|----------|---------|
-| New native module added | `eas:deploy` (full build required) |
-| SDK version upgrade | `eas:deploy` (full build required) |
-| Native config change (`app.json`, `eas.json`) | `eas:deploy` (full build required) |
-| JS bug fix | `eas:publish` (OTA update) |
-| UI change (styles, layout, text) | `eas:publish` (OTA update) |
-| New screen or feature (JS-only) | `eas:publish` (OTA update) |
-
-### Deployment Verification
-
-After deploying, verify the deployment landed:
-
-1. **For OTA updates**: Check the EAS dashboard or run `eas update:list` to confirm the update was published to the correct channel
-2. **For full builds**: Check the EAS dashboard or run `eas build:list` to confirm the build completed successfully
-3. **End-to-end**: Open the app on a device/simulator pointed at the target environment and verify the changes are present
-
----
-
-## Verification Quick Reference
-
-| Change Type | Verification Method | Command |
-|-------------|-------------------|---------|
-| UI feature (web) | Playwright MCP tools or tests | `bun run playwright:test` |
-| UI feature (native) | Maestro flows | `bun run maestro:test` |
-| Unit/integration logic | Jest | `bun run test -- path/to/file` |
-| Type safety | TypeScript compiler | `bun run typecheck` |
-| Code quality | ESLint | `bun run lint` |
-| Native module integration | Build and run on simulator | `bun run build-and-run:simulator:ios:dev` |
-| Full native E2E | Maestro smoke suite | `bun run maestro:test:smoke` |
-| Client-side errors | Playwright browser logs | `browser_console_messages` MCP tool |
-| Server-side errors | Companion backend repo logs | Check backend CLAUDE.md for log commands |
-| Deploy (native change) | EAS Build | `bun run eas:deploy:dev` |
-| Deploy (JS-only change) | EAS Update (OTA) | `bun run eas:publish:dev` |
-| Check EAS auth | EAS CLI | `bun run eas:whoami` |
-
----
-
-## Verification Patterns for Native Changes
-
-### UI Feature on Native
-
-End user: human on iOS or Android device.
-
-Required proof:
-
-- Maestro flow recording or screenshots from simulator
-- Console output showing flow passed
-
-```bash
-# Start the app on iOS simulator against dev backend
-bun run start:simulator:ios:dev
-
-# Run Maestro verification
-bun run maestro:test
-```
-
-### Native Module or Platform-Specific Code
-
-End user: application on device.
-
-Required proof:
-
-- Successful native build (no build errors)
-- App launches and target feature is functional
-
-```bash
-# Build and install native binary against dev backend
-bun run build-and-run:simulator:ios:dev
-
-# Verify with Maestro
-bun run maestro:test:smoke
-```
-
-### Cross-Platform Verification
-
-For changes that affect both web and native, agents must verify on both surfaces:
-
-1. **Web**: Playwright MCP tools or `bun run playwright:test`
-2. **Native**: `bun run start:simulator:ios:dev` + `bun run maestro:test`
-
-If only one surface is available, label the result as **PARTIALLY VERIFIED** with explicit gap documentation.