perf: optimize application loading and workflows

.agents/skills/react-doctor/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: react-doctor
+description: Use after changing React code, when finishing a feature or bug fix, before committing React changes, or when the user asks to run, scan, triage, explain, configure, or clean up React Doctor diagnostics. Covers correctness, security, accessibility, performance, bundle size, and architecture.
+---
+
+# React Doctor
+
+Use React Doctor as a regression gate and as a guided cleanup workflow.
+
+## After React changes
+
+Run:
+
+```bash
+bunx react-doctor@latest --verbose --scope changed
+```
+
+Check that the score did not regress. Investigate and fix newly introduced
+issues before committing.
+
+## General cleanup
+
+Run the full scan:
+
+```bash
+bunx react-doctor@latest --verbose
+```
+
+Treat diagnostics as hypotheses. Read the affected code, confirm the root
+cause, and prioritize errors before warnings. Keep unrelated or risky fixes in
+separate branches.
+
+## Full triage
+
+When the user requests `/doctor`, a full React Doctor run, or a cleanup pass,
+fetch and follow the current canonical playbook:
+
+```bash
+curl --fail --silent --show-error \
+  --header 'Cache-Control: no-cache' \
+  https://www.react.doctor/prompts/react-doctor-agent.md
+```
+
+Use per-rule prompts from
+`https://www.react.doctor/prompts/rules/<plugin>/<rule>.md` when the playbook
+calls for them. The workflow edits the working tree directly; do not commit or
+open a pull request unless the user separately asks.
+
+## Explain or configure rules
+
+When the user asks why a rule fired or wants to tune diagnostics, read
+[references/explain.md](references/explain.md) before changing configuration.

.agents/skills/react-doctor/references/explain.md

@@ -0,0 +1,52 @@
+# Explain and configure React Doctor rules
+
+Use this workflow when the user wants to understand or configure a diagnostic,
+not when fixing the underlying code.
+
+1. Identify the full rule key from the diagnostic.
+2. Explain it before changing configuration:
+
+```bash
+bunx react-doctor@latest rules explain react-doctor/no-array-index-as-key
+```
+
+3. Apply the narrowest control matching the user's intent.
+4. Validate the result:
+
+```bash
+bunx react-doctor@latest --verbose --diff
+```
+
+## Commands
+
+```bash
+bunx react-doctor@latest rules list
+bunx react-doctor@latest rules list --configured
+bunx react-doctor@latest rules list --category Performance
+bunx react-doctor@latest rules explain <rule>
+bunx react-doctor@latest rules disable <rule>
+bunx react-doctor@latest rules enable <rule>
+bunx react-doctor@latest rules set <rule> warn
+bunx react-doctor@latest rules category "React Native" off
+bunx react-doctor@latest rules ignore-tag design
+bunx react-doctor@latest rules unignore-tag design
+```
+
+## Choose the narrowest control
+
+- One unwanted or false-positive rule: disable that rule.
+- Correct rule with the wrong severity: set it to `warn` or `error`.
+- Disabled-by-default rule that should run: enable it.
+- Unwanted category: turn off that category.
+- Noisy behavioral family: ignore its tag.
+- Keep the diagnostic locally but exclude it from a PR, score, or CI gate: edit
+  `surfaces` instead of disabling the rule.
+
+Tag ignores are applied before rule and category overrides. For rules that are
+not ignored by tag, rule settings override category settings, which override
+defaults. Surface exclusions only change visibility; they do not stop a rule
+from running.
+
+Prefer explaining the rule's impact before offering to disable it. Do not
+suppress a diagnostic without checking its code context and confirming why it
+does not apply.

.agents/skills/react-grab/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: react-grab
+description: Use when the user wants a hands-free loop where grabbing UI elements in the browser with React Grab feeds tasks to the agent automatically, with no copy-paste or manual handoff. Triggers include "watch React Grab", "monitor my grabs", "auto-process React Grab", and "watch my clipboard for grabs". Do not use for a one-off paste of a single grab.
+---
+
+# React Grab
+
+Use React Grab selections from the browser as a continuous task queue.
+
+## Watch loop
+
+Repeat until the user says stop:
+
+1. Wait for the next grab:
+
+```bash
+bunx react-grab@latest pull --max-age 0
+```
+
+`--max-age 0` delivers every grab, including grabs made while another task was
+in progress. If the command is interrupted, run it again; the watcher keeps its
+queue.
+
+2. Act on each JSON line returned.
+3. Return to step 1.
+
+## Handle newer grabs first
+
+While working, check for a newer grab between steps:
+
+```bash
+bunx react-grab@latest pull --max-age 0 --wait 0
+```
+
+Empty output means continue. A new grab supersedes the current task: stop work
+that has not been completed, terminate background processes started for it, and
+act on the newest grab.
+
+Run slow commands as background processes so the queue can still be checked.
+
+## Act on a grab
+
+Each grab has `content` with source references and may have a `prompt`:
+
+- When `prompt` is present, treat it as the task and use the references in
+  `content` to locate the source.
+- When `prompt` is absent, follow the user's standing instruction. If none was
+  provided, summarize the component and source location, then wait for direction.
+
+## Stop
+
+When the user says stop, run:
+
+```bash
+bunx react-grab@latest stop
+```
+
+Do not pull again after stopping. Run the watcher on the same machine as the
+browser because it reads the local clipboard.

.env.example

@@ -1,4 +1,6 @@
 VITE_VATSIM_CLIENT_ID=your_client_id_here
 VITE_MAPBOX_TOKEN=your_mapbox_token_here
 VITE_PUBLIC_POSTHOG_KEY=your_posthog_key_here
-VITE_PUBLIC_POSTHOG_HOST=your_posthog_host_here
+VITE_PUBLIC_POSTHOG_HOST=your_posthog_host_here
+VITE_ENABLE_REACT_GRAB=false
+VITE_ENABLE_REACT_SCAN=false

.gitignore

@@ -122,4 +122,7 @@ ehthumbs.db
 Thumbs.db
 
 # Runtime files
-*.log
+*.log
+
+# Local performance captures
+/performance-traces/

.impeccable/live/config.json

@@ -0,0 +1,6 @@
+{
+  "files": ["index.html"],
+  "insertBefore": "</body>",
+  "commentSyntax": "html",
+  "cspChecked": true
+}

CONTRIBUTING.md

@@ -87,6 +87,42 @@ Thank you for your interest in contributing to the BARS website! This guide will
    - `bun run build` - Build for production
    - `bun run preview` - Preview production build locally
    - `bun run lint` - Run ESLint to check code quality
+   - `bun run doctor` - Audit React correctness, accessibility, and performance patterns
+   - `bun run perf:trace` - Capture a Chrome performance trace for the home page
+
+### Performance Profiling
+
+Install the Playwright Chromium binary once after installing dependencies:
+
+```bash
+bunx playwright install chromium
+```
+
+Start the development server, then capture the route you want to investigate:
+
+```bash
+bun run perf:trace
+bun run perf:trace /global-status global-status
+bun run perf:trace http://localhost:5173/contribute contribute
+```
+
+Each run writes a full Chrome trace and a smaller `.summary.json` report to
+`performance-traces/`. The directory is ignored by Git.
+
+For authenticated routes, save a Playwright storage-state file locally and set
+`BARS_TRACE_STORAGE_STATE` to its path before running the trace command. Do not
+commit storage-state files because they can contain session credentials.
+
+React Grab and React Scan are opt-in development diagnostics. Enable either one
+in `.env.local`, then restart Vite:
+
+```bash
+VITE_ENABLE_REACT_GRAB=true
+VITE_ENABLE_REACT_SCAN=true
+```
+
+Keep both disabled during load traces unless you are specifically measuring the
+diagnostic tooling itself.
 
 ## Development Guidelines
 

PRODUCT.md

@@ -0,0 +1,33 @@
+# Product
+
+## Register
+
+product
+
+## Users
+
+VATSIM pilots, scenery contributors, division members, and BARS staff use the site to manage accounts, airport lighting data, contributions, operational status, and administrative workflows.
+
+## Product Purpose
+
+BARS provides the public entry point and authenticated management tools for its real-time airport-lighting platform. Success means users can understand the product quickly and complete detailed operational work confidently without the interface getting in their way.
+
+## Brand Personality
+
+Precise, calm, and technically credible. The experience should feel premium through speed, consistency, and restraint rather than decorative effects.
+
+## Anti-references
+
+Avoid generic SaaS dashboards, glass-heavy surfaces, flashy loading indicators, isolated glowing elements, intrusive progress bars, white flashes, and motion that makes the interface feel unstable.
+
+## Design Principles
+
+- Make complex aviation workflows feel dependable and legible.
+- Use consistent, familiar controls across public and authenticated surfaces.
+- Communicate state quietly and clearly without visual noise.
+- Preserve context and perceived speed during navigation and loading.
+- Let operational content and airport data remain the visual focus.
+
+## Accessibility & Inclusion
+
+Target WCAG AA contrast, keyboard-accessible controls, meaningful loading announcements, responsive layouts, and reduced-motion behavior for all non-essential animation.