npm - @codyswann/lisa - Versions diffs - 1.66.2 → 1.67.0 - Mend

@codyswann/lisa 1.66.2 → 1.67.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (27) hide show

package/plugins/src/expo/rules/expo-verification.md DELETED Viewed

@@ -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.

package/plugins/src/rails/rules/lisa.md DELETED Viewed

@@ -1,42 +0,0 @@
-# Lisa-Managed Files
-The following files are managed by Lisa and will be overwritten on every `lisa` run. Never edit them directly. Where a local override exists, edit that instead.
-## Files with local overrides (edit the override, not the managed file)
-| Managed File (do not edit) | Local Override (edit this instead) |
-|---|---|
-| `.rubocop.yml` | `.rubocop.local.yml` |
-## Create-only files (edit freely, Lisa won't overwrite)
-- `.claude/rules/PROJECT_RULES.md`
-- `.rubocop.local.yml`
-- `.simplecov`
-- `.reek.yml`
-- `.rspec`
-- `simplecov.thresholds.json`
-- `rubocop.thresholds.yml`
-- `sonar-project.properties`
-- `spec/spec_helper.rb`
-- `spec/rails_helper.rb`
-- `.github/workflows/ci.yml`
-- `.github/workflows/claude-nightly-test-coverage.yml`
-- `.github/workflows/claude-nightly-code-complexity.yml`
-- `.github/workflows/claude-nightly-test-improvement.yml`
-- `VERSION`
-## Deep-merged by Lisa (Lisa wins conflicts, but project can add its own keys)
-- `.claude/settings.json`
-## Plugin-managed content (agents, skills, hooks, commands, rules)
-These resources are distributed via the stack Claude Code plugin (`rails@lisa`). Rules — including this file — are injected into each prompt automatically. Do not add these files to your project directory.
-## Copy-overwrite files (do not edit — full list)
-- `.safety-net.json`
-- `.rubocop.yml`, `.versionrc`, `lefthook.yml`, `Gemfile.lisa`
-- `config/initializers/version.rb`
-- `.coderabbit.yml`, `commitlint.config.cjs`

package/plugins/src/rails/rules/rails-conventions.md DELETED Viewed

@@ -1,176 +0,0 @@
-# Rails Coding Conventions
-This rule enforces Rails-specific coding standards for consistency, maintainability, and performance.
-## Fat Models, Skinny Controllers
-Controllers handle HTTP concerns only. Business logic belongs in models or service objects.
-```ruby
-# Correct — controller delegates to model
-class OrdersController < ApplicationController
-  def create
-    @order = Order.place(order_params, current_user)
-    redirect_to @order
-  end
-end
-# Wrong — business logic in controller
-class OrdersController < ApplicationController
-  def create
-    @order = Order.new(order_params)
-    @order.user = current_user
-    @order.total = @order.line_items.sum(&:price)
-    @order.apply_discount(current_user.discount_rate)
-    @order.save!
-    OrderMailer.confirmation(@order).deliver_later
-    redirect_to @order
-  end
-end
-```
-## Service Objects
-Extract complex business logic into service objects when a model method would be too large or spans multiple models.
-```ruby
-# app/services/order_placement_service.rb
-class OrderPlacementService
-  def initialize(user:, params:)
-    @user = user
-    @params = params
-  end
-  def call
-    order = Order.new(@params)
-    order.user = @user
-    order.calculate_total
-    order.save!
-    OrderMailer.confirmation(order).deliver_later
-    order
-  end
-end
-```
-## Concerns
-Use concerns to share behavior across models or controllers. Keep concerns focused on a single responsibility.
-```ruby
-# app/models/concerns/searchable.rb
-module Searchable
-  extend ActiveSupport::Concern
-  included do
-    scope :search, ->(query) { where("name ILIKE ?", "%#{query}%") }
-  end
-end
-```
-## ActiveRecord Patterns
-### Scopes over class methods for chainable queries
-```ruby
-# Correct — scope
-scope :active, -> { where(active: true) }
-scope :recent, -> { order(created_at: :desc) }
-# Wrong — class method for simple query
-def self.active
-  where(active: true)
-end
-```
-### Validations
-```ruby
-# Use built-in validators
-validates :email, presence: true, uniqueness: true, format: { with: URI::MailTo::EMAIL_REGEXP }
-validates :age, numericality: { greater_than: 0 }
-```
-### Callbacks — use sparingly
-Prefer explicit service objects over callbacks for complex side effects. Callbacks are acceptable for simple data normalization.
-```ruby
-# Acceptable — simple normalization
-before_validation :normalize_email
-private
-def normalize_email
-  self.email = email&.downcase&.strip
-end
-```
-## N+1 Query Prevention
-Always use `includes`, `preload`, or `eager_load` to prevent N+1 queries. The Bullet gem is included to detect these in development.
-```ruby
-# Correct — eager loading
-@posts = Post.includes(:author, :comments).where(published: true)
-# Wrong — N+1 query
-@posts = Post.where(published: true)
-@posts.each { |post| post.author.name } # N+1!
-```
-## Strong Parameters
-Always use strong parameters in controllers. Never use `permit!`.
-```ruby
-# Correct
-def order_params
-  params.require(:order).permit(:product_id, :quantity, :notes)
-end
-# Wrong — permits everything
-def order_params
-  params.require(:order).permit!
-end
-```
-## Database Migrations
-- Use `strong_migrations` gem constraints (included via Gemfile.lisa)
-- Never modify `db/schema.rb` directly
-- Always add indexes for foreign keys and commonly queried columns
-- Use `change` method when the migration is reversible; use `up`/`down` when it is not
-```ruby
-class AddIndexToOrdersUserId < ActiveRecord::Migration[7.2]
-  def change
-    add_index :orders, :user_id
-  end
-end
-```
-## Testing with RSpec
-- Use `let` and `let!` for test setup
-- Use `described_class` instead of repeating the class name
-- Use `factory_bot` for test data, not fixtures
-- Use `shoulda-matchers` for model validation tests
-- Keep tests focused — one assertion concept per example
-```ruby
-RSpec.describe Order, type: :model do
-  describe "validations" do
-    it { is_expected.to validate_presence_of(:user) }
-    it { is_expected.to validate_numericality_of(:total).is_greater_than(0) }
-  end
-  describe ".recent" do
-    it "returns orders in descending creation order" do
-      old_order = create(:order, created_at: 1.day.ago)
-      new_order = create(:order, created_at: 1.hour.ago)
-      expect(described_class.recent).to eq([new_order, old_order])
-    end
-  end
-end
-```

package/plugins/src/typescript/rules/lisa.md DELETED Viewed

@@ -1,37 +0,0 @@
-# Lisa-Managed Files
-The following files are managed by Lisa and will be overwritten on every `lisa` run. Never edit them directly. Where a local override exists, edit that instead.
-## Files with local overrides (edit the override, not the managed file)
-| Managed File (do not edit) | Local Override (edit this instead) |
-|---|---|
-| `eslint.config.ts` | `eslint.config.local.ts` |
-| `vitest.config.ts` | `vitest.config.local.ts` |
-| `tsconfig.json` | `tsconfig.local.json` |
-## Create-only files (edit freely, Lisa won't overwrite)
-- `.claude/rules/PROJECT_RULES.md`
-- `eslint.thresholds.json`
-- `vitest.thresholds.json`
-## Deep-merged by Lisa (Lisa wins conflicts, but project can add its own keys)
-- `.claude/settings.json`
-## Plugin-managed content (agents, skills, hooks, commands, rules)
-These resources are distributed via the stack Claude Code plugin (e.g., `typescript@lisa`). Rules — including this file — are injected into each prompt automatically. Do not add these files to your project directory.
-## Copy-overwrite files (do not edit — full list)
-- `.prettierrc.json`, `.prettierignore`, `.lintstagedrc.json`, `.versionrc`, `.nvmrc`
-- `.yamllint`, `.gitleaksignore`, `.coderabbit.yml`, `commitlint.config.cjs`, `sgconfig.yml`, `knip.json`
-- `.safety-net.json`, `audit.ignore.config.json`
-- `eslint.base.ts`, `eslint.typescript.ts` (+ `expo`/`nestjs`/`cdk` variants), `eslint.slow.config.ts`
-- `vitest.config.ts`
-- `tsconfig.base.json`, `tsconfig.typescript.json` (+ variants), `tsconfig.eslint.json`, `tsconfig.build.json`, `tsconfig.spec.json`
-- `.github/workflows/quality.yml`, `release.yml`, `claude.yml`, and all other Claude/CI workflows
-- `.github/dependabot.yml`, `.github/GITHUB_ACTIONS.md`
-- `ast-grep/rules/`, `ast-grep/utils/`, `ast-grep/rule-tests/`

/package/{plugins/lisa → all/copy-overwrite/.claude}/rules/coding-philosophy.md RENAMED Viewed

File without changes

/package/{plugins/lisa/rules/verfication.md → all/copy-overwrite/.claude/rules/verification.md} RENAMED Viewed

File without changes

/package/{plugins/lisa-expo → expo/copy-overwrite/.claude}/rules/expo-verification.md RENAMED Viewed

File without changes

/package/{plugins/lisa-rails → rails/copy-overwrite/.claude}/rules/rails-conventions.md RENAMED Viewed

File without changes