@codyswann/lisa 1.47.1 → 1.48.0

package/expo/copy-overwrite/.claude/skills/ops-run-local/SKILL.md

@@ -1,166 +0,0 @@
----
-name: ops-run-local
-description: Manage the local development environment for Expo + serverless backend projects. Supports start, stop, restart, and status for the full stack or individual services.
-allowed-tools:
-  - Bash
-  - Read
----
-
-# Ops: Run Local
-
-Manage the local development environment.
-
-**Argument**: `$ARGUMENTS` — `start`, `stop`, `restart`, `status`, `start-frontend`, `start-backend` (default: `start`)
-
-## Path Convention
-
-- **Frontend**: Current project directory (`.`)
-- **Backend**: `${BACKEND_DIR:-../backend-v2}` — set `BACKEND_DIR` in `.claude/settings.local.json` if your backend is elsewhere
-
-## Prerequisites (run before any operation)
-
-1. Verify backend directory exists:
-   ```bash
-   BACKEND_DIR="${BACKEND_DIR:-../backend-v2}"
-   test -d "$BACKEND_DIR" && echo "Backend dir OK: $BACKEND_DIR" || echo "ERROR: Backend dir not found at $BACKEND_DIR — set BACKEND_DIR"
-   ```
-2. Check port availability:
-   ```bash
-   lsof -i :8081 2>/dev/null | grep LISTEN
-   lsof -i :3000 2>/dev/null | grep LISTEN
-   ```
-3. Verify bun is installed:
-   ```bash
-   which bun && bun --version
-   ```
-
-## Discovery
-
-Read the frontend `package.json` to find available start scripts (e.g., `start:local`, `start:dev`, `start:staging`). Read the backend `package.json` to find backend start scripts (e.g., `start:local`, `start:dev`).
-
-## Operations
-
-### start (full stack)
-
-Start both backend and frontend for local development.
-
-1. **Start backend** (background):
-   ```bash
-   cd "${BACKEND_DIR:-../backend-v2}" && IS_OFFLINE=true bun run start:local
-   ```
-   Run this in the background using the Bash tool with `run_in_background: true`.
-
-2. **Wait for backend** (up to 30 seconds):
-   ```bash
-   for i in $(seq 1 30); do
-     curl -sf http://localhost:3000/graphql -X POST \
-       -H "Content-Type: application/json" \
-       -d '{"query":"{ __typename }"}' > /dev/null 2>&1 && echo "Backend ready" && break
-     sleep 1
-   done
-   ```
-
-3. **Start frontend** (background):
-   ```bash
-   bun run start:local
-   ```
-   Run this in the background using the Bash tool with `run_in_background: true`.
-
-4. **Verify frontend** (up to 60 seconds — Metro bundler can be slow):
-   ```bash
-   for i in $(seq 1 60); do
-     curl -sf http://localhost:8081 > /dev/null 2>&1 && echo "Frontend ready" && break
-     sleep 1
-   done
-   ```
-
-5. Report status table.
-
-### start-frontend (frontend only, pointing at remote backend)
-
-Use when the backend is already deployed and you only need the frontend.
-
-1. ```bash
-   bun run start:dev
-   ```
-   Run in background.
-
-2. Verify:
-   ```bash
-   for i in $(seq 1 60); do
-     curl -sf http://localhost:8081 > /dev/null 2>&1 && echo "Frontend ready" && break
-     sleep 1
-   done
-   ```
-
-### start-backend (backend only)
-
-1. Check AWS credentials (discover profile from backend `package.json` `aws:signin:*` scripts):
-   ```bash
-   aws sts get-caller-identity --profile {aws-profile} 2>/dev/null
-   ```
-   If expired, run the backend's `aws:signin:{env}` script.
-
-2. Start:
-   ```bash
-   cd "${BACKEND_DIR:-../backend-v2}" && IS_OFFLINE=true bun run start:local
-   ```
-   Run in background.
-
-3. Verify:
-   ```bash
-   for i in $(seq 1 30); do
-     curl -sf http://localhost:3000/graphql -X POST \
-       -H "Content-Type: application/json" \
-       -d '{"query":"{ __typename }"}' > /dev/null 2>&1 && echo "Backend ready" && break
-     sleep 1
-   done
-   ```
-
-### stop
-
-Kill all local services.
-
-```bash
-# Kill frontend (Metro bundler)
-lsof -ti :8081 | xargs kill -9 2>/dev/null || echo "No frontend process on :8081"
-
-# Kill backend (Serverless Offline)
-lsof -ti :3000 | xargs kill -9 2>/dev/null || echo "No backend process on :3000"
-
-# Stop Docker if running
-cd "${BACKEND_DIR:-../backend-v2}" && docker compose down 2>/dev/null || true
-```
-
-### restart
-
-1. Run **stop** (above).
-2. Wait 2 seconds: `sleep 2`
-3. Run **start** (above).
-4. Verify both services respond.
-
-### status
-
-Check what is currently running and responsive.
-
-```bash
-echo "=== Port Check ==="
-echo -n "Frontend :8081 — "; lsof -i :8081 2>/dev/null | grep LISTEN > /dev/null && echo "LISTENING" || echo "NOT LISTENING"
-echo -n "Backend  :3000 — "; lsof -i :3000 2>/dev/null | grep LISTEN > /dev/null && echo "LISTENING" || echo "NOT LISTENING"
-
-echo ""
-echo "=== Health Check ==="
-echo -n "Frontend :8081 — "; curl -sf -o /dev/null -w "%{http_code}" http://localhost:8081 2>/dev/null || echo "UNREACHABLE"
-echo -n "Backend  :3000 — "; curl -sf -o /dev/null -w "%{http_code}" http://localhost:3000/graphql -X POST -H "Content-Type: application/json" -d '{"query":"{ __typename }"}' 2>/dev/null || echo "UNREACHABLE"
-
-echo ""
-echo "=== Docker ==="
-docker compose -f "${BACKEND_DIR:-../backend-v2}/compose.yaml" ps 2>/dev/null || echo "No Docker services running"
-```
-
-Report results as a table:
-
-| Service | Port | Listening | Responsive |
-|---------|------|-----------|------------|
-| Frontend (Metro) | 8081 | YES/NO | YES/NO |
-| Backend (Serverless Offline) | 3000 | YES/NO | YES/NO |

package/expo/copy-overwrite/.claude/skills/ops-verify-health/SKILL.md

@@ -1,101 +0,0 @@
----
-name: ops-verify-health
-description: Health check all services across environments. Checks frontend URLs, backend GraphQL endpoints, and reports response times.
-allowed-tools:
-  - Bash
-  - Read
----
-
-# Ops: Verify Health
-
-Health check all services across environments.
-
-**Argument**: `$ARGUMENTS` — environment(s) to check (default: `all`). Options: `local`, `dev`, `staging`, `production`, `all`
-
-## Discovery
-
-Read these files to build the environment URL table:
-
-1. `e2e/constants.ts` — frontend URLs per environment
-2. `.env.localhost`, `.env.development`, `.env.staging`, `.env.production` — `EXPO_PUBLIC_GRAPHQL_BASE_URL` for backend GraphQL URLs
-
-## Health Checks
-
-For each environment, run these checks:
-
-### Frontend Check
-
-```bash
-curl -sf -o /dev/null -w "HTTP %{http_code} in %{time_total}s" {frontend_url}
-```
-
-Verify the response contains Expo/React markers:
-```bash
-curl -sf {frontend_url} | head -20
-```
-
-### Backend GraphQL Check
-
-```bash
-curl -sf {graphql_url} -X POST \
-  -H "Content-Type: application/json" \
-  -d '{"query":"{ __typename }"}' \
-  -w "\nHTTP %{http_code} in %{time_total}s\n"
-```
-
-### GraphQL Introspection (detailed check)
-
-```bash
-curl -sf {graphql_url} -X POST \
-  -H "Content-Type: application/json" \
-  -d '{"query":"{ __schema { queryType { name } } }"}' \
-  -w "\nHTTP %{http_code} in %{time_total}s\n"
-```
-
-## Full Health Check Script
-
-Run all checks for the specified environment(s):
-
-```bash
-check_env() {
-  local ENV=$1
-  local FE_URL=$2
-  local BE_URL=$3
-
-  echo "=== $ENV ==="
-
-  # Frontend
-  FE_STATUS=$(curl -sf -o /dev/null -w "%{http_code}" --max-time 10 "$FE_URL" 2>/dev/null || echo "000")
-  FE_TIME=$(curl -sf -o /dev/null -w "%{time_total}" --max-time 10 "$FE_URL" 2>/dev/null || echo "timeout")
-  echo "Frontend: HTTP $FE_STATUS ($FE_TIME s)"
-
-  # Backend
-  BE_RESULT=$(curl -sf --max-time 10 "$BE_URL" -X POST \
-    -H "Content-Type: application/json" \
-    -d '{"query":"{ __typename }"}' \
-    -w "\n%{http_code} %{time_total}" 2>/dev/null || echo -e "\n000 timeout")
-  BE_STATUS=$(echo "$BE_RESULT" | tail -1 | awk '{print $1}')
-  BE_TIME=$(echo "$BE_RESULT" | tail -1 | awk '{print $2}')
-  echo "Backend:  HTTP $BE_STATUS ($BE_TIME s)"
-  echo ""
-}
-```
-
-## EAS Update Status
-
-Check the latest OTA updates deployed to each branch:
-
-```bash
-eas update:list --branch {env} --limit 3
-```
-
-## Output Format
-
-Report results as a table:
-
-| Service | Environment | Status | Response Time | Details |
-|---------|-------------|--------|---------------|---------|
-| Frontend | dev | UP (200) | 0.45s | HTML contains React root |
-| Backend | dev | UP (200) | 0.32s | GraphQL responds `__typename` |
-
-Flag any service with status != 200 or response time > 5s as a concern.

package/expo/copy-overwrite/.claude/skills/owasp-zap/SKILL.md

@@ -1,56 +0,0 @@
-# OWASP ZAP Baseline Scanning
-
-OWASP ZAP (Zed Attack Proxy) performs DAST (Dynamic Application Security Testing) by scanning a running application for common security vulnerabilities from the OWASP Top 10.
-
-## When to Use
-
-- After making changes to HTTP headers, authentication, or security middleware
-- Before deploying to staging or production
-- When reviewing security scan results from CI
-- When triaging ZAP findings from pull request checks
-
-## Running Locally
-
-```bash
-# Requires Docker to be installed and running
-bash scripts/zap-baseline.sh
-```
-
-The scan builds the Expo web export, serves it locally, and runs ZAP against it. Reports are saved to `zap-report.html`, `zap-report.json`, and `zap-report.md`.
-
-## Interpreting Results
-
-ZAP findings are categorized by risk level:
-
-| Risk | Action |
-|------|--------|
-| **High** | Fix immediately — indicates exploitable vulnerability |
-| **Medium** | Fix before deployment — security best practice violation |
-| **Low** | Fix when convenient — minor security improvement |
-| **Informational** | Review — may be false positive or acceptable risk |
-
-## Common Findings and Fixes
-
-### Infrastructure-Level (fix at CDN/hosting, not in code)
-
-- **CSP Header Not Set**: Configure Content-Security-Policy at CDN or hosting platform. Expo web exports need `script-src 'self' 'unsafe-inline'` for hydration.
-- **HSTS Not Set**: Configure Strict-Transport-Security at CDN/load balancer.
-- **X-Frame-Options**: Use `frame-ancestors` in CSP at CDN level.
-
-### Application-Level (fix in code)
-
-- **Cookie flags missing**: Ensure all cookies set `HttpOnly`, `Secure`, and `SameSite` attributes.
-- **Debug error messages**: Ensure error boundaries don't leak stack traces in production.
-- **Server version disclosure**: Remove or mask the `Server` response header.
-
-## Configuration
-
-ZAP scan rules are configured in `.zap/baseline.conf`. Each line controls how ZAP treats a specific rule:
-
-- `IGNORE`: Skip the rule entirely
-- `WARN`: Report finding but don't fail the build
-- `FAIL`: Fail the build if this finding is detected
-
-## CI Integration
-
-ZAP runs automatically in CI via the `zap-baseline.yml` workflow. Results are uploaded as artifacts and the build fails on medium+ severity findings.

package/expo/copy-overwrite/.claude/skills/playwright-selectors/SKILL.md

@@ -1,223 +0,0 @@
----
-name: playwright-selectors
-description: Best practices for adding testID and aria-label selectors for Playwright E2E testing in Expo web applications. This skill should be used when adding E2E test coverage, creating new components that need test selectors, or reviewing code for testability.
----
-
-# Playwright Selectors Best Practices
-
-## Overview
-
-This skill provides guidance for adding effective selectors (testID, aria-labels) to Expo/React Native components for Playwright E2E testing. Proper selector strategy ensures tests are reliable, maintainable, and accessible.
-
-## Selector Priority
-
-Choose selectors based on their reliability and accessibility impact, in this priority order:
-
-| Priority | Selector Method | When to Use                               |
-| -------- | --------------- | ----------------------------------------- |
-| 1        | `getByRole`     | Interactive elements with semantic roles  |
-| 2        | `getByText`     | Visible text content                      |
-| 3        | `getByLabel`    | Form elements with labels                 |
-| 4        | `getByTestId`   | Fallback for elements without semantics   |
-
-### getByRole (Preferred)
-
-Use semantic roles when possible - they improve both accessibility and test resilience.
-
-```typescript
-// E2E test - preferred selector
-const submitButton = page.getByRole("button", { name: "Submit" });
-await expect(submitButton).toBeVisible();
-```
-
-### getByTestId (Fallback)
-
-Use testID when semantic selectors are not available, particularly for structural containers.
-
-```typescript
-// E2E test - fallback selector
-const container = page.getByTestId("home:container");
-await expect(container).toBeVisible();
-```
-
-## testID Naming Convention
-
-Use a namespaced pattern with colons as separators: `screen:element`
-
-### Format
-
-```
-{screen}:{element}
-```
-
-- **screen**: lowercase screen/feature name (e.g., `home`, `profile`, `settings`)
-- **element**: lowercase element identifier (e.g., `container`, `title`, `submit-button`)
-
-### Examples
-
-| testID                     | Description                      |
-| -------------------------- | -------------------------------- |
-| `home:container`           | Main container on home screen    |
-| `home:title`               | Title text on home screen        |
-| `profile:avatar`           | User avatar on profile screen    |
-| `settings:dark-mode-toggle`| Dark mode toggle in settings     |
-| `auth:login-button`        | Login button on auth screen      |
-
-### Rules
-
-1. Use lowercase only
-2. Use colons (`:`) to separate screen from element
-3. Use hyphens (`-`) for multi-word elements
-4. Be descriptive but concise
-5. Avoid redundant words (e.g., `home:home-title` should be `home:title`)
-
-## React Native to HTML Mapping
-
-Understanding how testID propagates from React Native to the web is essential.
-
-### How It Works
-
-1. React Native's `testID` prop is for native testing (XCUITest, Espresso)
-2. On web (via react-native-web), `testID` renders as `data-testid` in HTML
-3. Playwright's `getByTestId()` queries `data-testid` by default
-
-```typescript
-// React Native component
-<Box testID="home:container">...</Box>
-
-// Rendered HTML on web
-<div data-testid="home:container">...</div>
-
-// Playwright locator
-page.getByTestId("home:container")
-```
-
-### Gluestack UI Components
-
-Gluestack UI web components (Box, Text, etc.) require explicit testID handling because they use native HTML elements instead of react-native-web components. The web versions have been updated to:
-
-1. Accept a `testID` prop in the TypeScript type
-2. Map `testID` to `data-testid` on the rendered HTML element
-
-```typescript
-// Gluestack Box web implementation
-const Box = ({ testID, ...props }) => (
-  <div data-testid={testID} {...props} />
-);
-```
-
-## When to Add testID
-
-### Add testID To
-
-1. **Interactive elements** that E2E tests will click/interact with
-2. **Key structural containers** for page load verification
-3. **Dynamic content areas** that change based on state
-4. **Form elements** that lack semantic labels
-
-### Do Not Add testID To
-
-1. Every element (over-testing creates maintenance burden)
-2. Elements with good semantic selectors (use getByRole instead)
-3. Decorative elements not needed for testing
-4. Elements inside third-party components (may not propagate)
-
-## Accessibility Best Practices
-
-Prefer semantic selectors and aria-labels over testID when possible.
-
-### aria-label for Testing and Accessibility
-
-When adding labels for testing, use `aria-label` or `accessibilityLabel` to benefit screen reader users too.
-
-```typescript
-// Correct - benefits both testing and accessibility
-<Pressable
-  accessibilityLabel="Close dialog"
-  onPress={handleClose}
->
-  <XIcon />
-</Pressable>
-
-// E2E test uses accessible name
-await page.getByRole("button", { name: "Close dialog" }).click();
-```
-
-### accessibilityRole for Semantic Elements
-
-Use `accessibilityRole` to provide semantic meaning on web.
-
-```typescript
-// Correct - semantic role for assistive technology
-<Box accessibilityRole="banner" testID="header:container">
-  <Text accessibilityRole="heading">Welcome</Text>
-</Box>
-
-// E2E test can use role
-await expect(page.getByRole("banner")).toBeVisible();
-await expect(page.getByRole("heading", { name: "Welcome" })).toBeVisible();
-```
-
-## Implementation Checklist
-
-When adding E2E test coverage to a component:
-
-- [ ] Identify elements that need selectors for testing
-- [ ] Prefer semantic selectors (role, text, label) when available
-- [ ] Use namespaced testID pattern for elements without semantics
-- [ ] Verify testID propagates to `data-testid` on web (check Gluestack components)
-- [ ] Add accessibility labels where beneficial
-- [ ] Document testIDs in component JSDoc preamble
-
-## Example Component
-
-```typescript
-/**
- * Profile screen component.
- *
- * Test IDs for E2E testing:
- * - `profile:container` - Main container
- * - `profile:avatar` - User avatar image
- * - `profile:name` - User display name
- *
- * @module features/profile/screens/Main
- */
-export const ProfileScreen = () => (
-  <Box testID="profile:container" className="flex-1 p-4">
-    <Image
-      testID="profile:avatar"
-      source={{ uri: user.avatarUrl }}
-      accessibilityLabel={`${user.name}'s profile photo`}
-    />
-    <Text testID="profile:name" accessibilityRole="heading">
-      {user.name}
-    </Text>
-    <Pressable
-      accessibilityLabel="Edit profile"
-      onPress={handleEdit}
-    >
-      <Text>Edit</Text>
-    </Pressable>
-  </Box>
-);
-```
-
-## Corresponding E2E Test
-
-```typescript
-test.describe("Profile Screen", () => {
-  test("displays user information", async ({ page }) => {
-    await page.goto("/profile");
-
-    // Verify structural container
-    await expect(page.getByTestId("profile:container")).toBeVisible();
-
-    // Prefer accessible queries when available
-    await expect(page.getByRole("heading")).toHaveText("John Doe");
-    await expect(page.getByRole("button", { name: "Edit profile" })).toBeVisible();
-
-    // Use testID for elements without semantic roles
-    await expect(page.getByTestId("profile:avatar")).toBeVisible();
-  });
-});
-```