tribunal-kit 2.4.6 → 3.1.0

package/.agent/workflows/api-tester.md

@@ -1,279 +1,151 @@
 ---
-description: Automated multi-stage API endpoint testing. Generates and runs auth-aware request sequences.
+description: Automated multi-stage API endpoint testing. Generates and runs auth-aware request sequences (login → use token → test CRUD → verify errors). Reports response codes, schema mismatches, and unexpected data.
 ---
 
-# /api-tester — Automated API Test Flows
+# /api-tester — Automated API Testing
 
 $ARGUMENTS
 
 ---
 
-This command generates and runs multi-stage API test sequences. It goes beyond single-endpoint testing by simulating realistic user sessions with chained requests, variable capture, and assertion verification.
+## When to Use /api-tester
 
----
-
-## When to Use This vs Other Commands
-
-| Use `/api-tester` when... | Use something else when... |
-|---|---|
-| Testing multi-step flows (auth + resource lifecycle) | Unit tests → `/test` |
-| Verifying endpoint contracts before deploy | Logic review → `/review` |
-| Debugging a specific flow returning wrong data | Root cause → `/debug` |
-| Security testing for injection/rate limits | Full security audit → `/audit` |
+|Use `/api-tester` when...|Use something else when...|
+|:---|:---|
+|Testing REST API endpoints manually|Unit tests needed → `/test`|
+|Verifying auth token flows end-to-end|Full security audit → `/audit`|
+|After generating new endpoints|Load testing → `/performance-benchmarker`|
+|Checking response schemas||
 
 ---
 
-## When to Use
-
-- After creating or modifying API routes.
-- Before deployment to validate endpoint contracts.
-- When debugging a multi-step flow (e.g., Register → Login → Create Resource → Verify).
-- When the user says "test api", "endpoint test", or "api flow".
-
----
+## Phase 1 — Endpoint Discovery
 
-## Pipeline Flow
+```bash
+# Find all defined routes
+grep -r "app.get\|app.post\|app.put\|app.delete\|app.patch" src/ --include="*.ts"
+grep -r "router.get\|router.post\|router.put" src/ --include="*.ts"
 
-```
-Your request (endpoint or flow description)
-    │
-    ▼
-Context read — route files, middleware, schema, auth config, package.json
-    │
-    ▼
-Route discovery — scan for all registered endpoints and methods
-    │
-    ▼
-Test Plan generated (sequence of requests with dependencies & captures)
-    │
-    ▼
-Environment check — server running? Base URL resolved? Auth available?
-    │
-    ▼
-Execution — each step runs, captures response, feeds next step
-    │
-    ▼
-Report — pass/fail per step, response times, payload diffs, coverage map
+# Next.js Route Handlers
+find src/app/api -name "route.ts" | sort
 ```
 
 ---
 
-## Step 1: Route Discovery
+## Phase 2 — Auth Flow (Token Acquisition)
 
-Before generating tests, scan the codebase for route definitions:
+Before testing protected endpoints, acquire auth token:
 
-| Framework | Scan Pattern | What to Extract |
-|---|---|---|
-| Express | `app.get/post/put/delete/patch` or `router.*` | Method, path, middleware |
-| Fastify | `fastify.route` or `fastify.get/post/...` | Method, path, schema |
-| Next.js API | `app/api/**/route.ts` | Exported functions (GET, POST) |
-| Django/DRF | `urlpatterns`, `@api_view` | Method, path, viewset |
-| FastAPI | `@app.get/post/put/delete` | Method, path, response model |
-| Go (Chi/Gin) | `r.Get/Post/Put/Delete` | Method, path, handler |
+```bash
+# Acquire JWT
+curl -X POST http://localhost:3000/api/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"test@example.com","password":"testpassword"}' \
+  -s | jq '.token'
 
-**Output a route map before generating tests:**
-```
-━━━ Route Map ━━━━━━━━━━━━━━━━━━━━━━━━━━
-GET    /api/users          → UserController.list    [auth: required]
-POST   /api/users          → UserController.create  [auth: admin]
-GET    /api/users/:id      → UserController.get     [auth: required]
-PUT    /api/users/:id      → UserController.update  [auth: owner]
-DELETE /api/users/:id      → UserController.delete  [auth: admin]
-POST   /api/auth/login     → AuthController.login   [auth: none]
-POST   /api/auth/register  → AuthController.register [auth: none]
+# Assign to variable
+TOKEN=$(curl -X POST http://localhost:3000/api/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"test@example.com","password":"testpassword"}' \
+  -s | jq -r '.token')
 ```
 
 ---
 
-## Step 2: Test Pattern Selection
+## Phase 3 — CRUD Sequence Testing
 
-### Pattern 1: CRUD Lifecycle
-Full create-read-update-read-delete-verify cycle:
-```
-Step 1: POST   /api/resource        → Create (capture: response.id → $RESOURCE_ID)
-Step 2: GET    /api/resource/$RESOURCE_ID  → Read (assert: 200, body matches creation)
-Step 3: PUT    /api/resource/$RESOURCE_ID  → Update (send modified fields)
-Step 4: GET    /api/resource/$RESOURCE_ID  → Read (assert: updated fields match)
-Step 5: DELETE /api/resource/$RESOURCE_ID  → Delete (assert: 204 or 200)
-Step 6: GET    /api/resource/$RESOURCE_ID  → Read (assert: 404)
-```
+Test endpoints in the correct order (create before read, read before delete):
 
-### Pattern 2: Auth Flow
-Full authentication lifecycle:
-```
-Step 1: POST   /api/auth/register   → Register (capture: $TOKEN)
-Step 2: POST   /api/auth/login      → Login (capture: $JWT, $REFRESH_TOKEN)
-Step 3: GET    /api/protected       → With JWT header (assert: 200)
-Step 4: GET    /api/protected       → Without JWT (assert: 401)
-Step 5: POST   /api/auth/refresh    → With $REFRESH_TOKEN (capture: $NEW_JWT)
-Step 6: GET    /api/protected       → With $NEW_JWT (assert: 200)
-Step 7: POST   /api/auth/logout     → Invalidate session
-Step 8: GET    /api/protected       → With invalidated JWT (assert: 401)
-```
+```bash
+# 1. CREATE (POST)
+CREATE_RESPONSE=$(curl -X POST http://localhost:3000/api/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Test User","email":"new@test.com"}')
+CREATED_ID=$(echo $CREATE_RESPONSE | jq -r '.id')
+echo "Created: $CREATED_ID"
 
-### Pattern 3: Edge Cases & Error Handling
-```
-Step 1: POST   /api/resource        → Missing required fields (assert: 400 + error message)
-Step 2: POST   /api/resource        → Invalid field types (assert: 400 + validation detail)
-Step 3: POST   /api/resource        → Duplicate unique field (assert: 409)
-Step 4: GET    /api/resource/99999  → Non-existent ID (assert: 404)
-Step 5: PUT    /api/resource/:id    → Unauthorized user (assert: 403)
-Step 6: DELETE /api/resource/:id    → Without auth (assert: 401)
-Step 7: GET    /api/resource?page=-1 → Invalid pagination (assert: 400)
-Step 8: POST   /api/resource        → Payload too large (assert: 413 or 400)
-```
+# 2. READ (GET)
+curl -X GET "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN" \
+  | jq .
 
-### Pattern 4: Pagination & Filtering
-```
-Step 1: POST   /api/resource  → Create 5 records (loop)
-Step 2: GET    /api/resource?page=1&limit=2   → (assert: 2 items, hasMore: true)
-Step 3: GET    /api/resource?page=2&limit=2   → (assert: 2 items, hasMore: true)
-Step 4: GET    /api/resource?page=3&limit=2   → (assert: 1 item, hasMore: false)
-Step 5: GET    /api/resource?sort=createdAt&order=desc → (assert: items in descending order)
-Step 6: GET    /api/resource?filter=name:test  → (assert: only matching items returned)
-```
+# 3. UPDATE (PATCH)
+curl -X PATCH "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Updated Name"}'
 
-### Pattern 5: Rate Limiting & Security
-```
-Step 1: POST   /api/auth/login × 10  → Rapid-fire login attempts
-Step 2: POST   /api/auth/login        → (assert: 429 Too Many Requests or similar)
-Step 3: Wait   [cooldown period]
-Step 4: POST   /api/auth/login        → (assert: allowed again)
-Step 5: POST   /api/resource           → With SQL injection in body (assert: 400, no SQL error exposed)
-Step 6: GET    /api/resource?id=1 OR 1=1 → (assert: 400 or filtered, no data leak)
+# 4. DELETE
+curl -X DELETE "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN"
 ```
 
 ---
 
-## Step 3: Variable Capture & Chaining
+## Phase 4 — Error Case Testing
 
-Tests are chained via captured variables:
+Test that errors are handled correctly:
 
-```
-$VAR_NAME = response.body.fieldPath
+```bash
+# 4xx errors (client errors — must NOT return 200!)
+echo "--- Unauthenticated request (expect 401) ---"
+curl -X GET http://localhost:3000/api/users -s -o /dev/null -w "%{http_code}\n"
 
-Examples:
-$USER_ID     = response.body.data.id
-$JWT         = response.body.token
-$CSRF_TOKEN  = response.headers['x-csrf-token']
-$TOTAL_COUNT = response.body.meta.total
-```
+echo "--- Invalid ID (expect 404 or 400) ---"
+curl -X GET "http://localhost:3000/api/users/not-a-real-id" \
+  -H "Authorization: Bearer $TOKEN" \
+  -s -o /dev/null -w "%{http_code}\n"
 
-Variables are passed forward:
-- **Headers**: `Authorization: Bearer $JWT`
-- **URL params**: `/api/users/$USER_ID`
-- **Body fields**: `{ "userId": "$USER_ID" }`
+echo "--- Invalid body (expect 400) ---"
+curl -X POST http://localhost:3000/api/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"invalid":"field"}' \
+  -s -o /dev/null -w "%{http_code}\n"
 
----
-
-## Step 4: Assertion Engine
-
-Each step can assert on:
-
-| Assertion Type | Example | Description |
-|---|---|---|
-| Status code | `assert: 200` | HTTP status |
-| Body field exists | `assert: body.id exists` | Field presence |
-| Body field value | `assert: body.name === "test"` | Exact match |
-| Body field type | `assert: body.items is Array` | Type check |
-| Header present | `assert: headers.content-type contains "json"` | Header check |
-| Response time | `assert: time < 500ms` | Performance gate |
-| Array length | `assert: body.items.length === 3` | Count check |
-| Negative match | `assert: body.password === undefined` | Field NOT present |
+echo "--- Rate limiting (expect 429 after N requests) ---"
+for i in {1..15}; do
+  STATUS=$(curl -X POST http://localhost:3000/api/auth/login \
+    -H "Content-Type: application/json" \
+    -d '{"email":"x","password":"wrong"}' \
+    -s -o /dev/null -w "%{http_code}")
+  echo "Attempt $i: $STATUS"
+done
+```
 
 ---
 
-## Output Format
+## Phase 5 — Test Report
 
 ```
 ━━━ API Test Report ━━━━━━━━━━━━━━━━━━━━━━
 
-Flow:    [Name of the flow tested]
-Base:    [base URL]
-Steps:   6 total | 5 passed | 1 failed
-Time:    1.2s total
-
-━━━ Execution ━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Step 1: POST /api/auth/login           ✅ 200  (142ms)
-        ↳ Captured: $JWT
-Step 2: GET  /api/users/me              ✅ 200  (89ms)
-        ↳ Asserted: body.email === "test@example.com"
-Step 3: PUT  /api/users/me              ✅ 200  (112ms)
-        ↳ Sent: { name: "Updated Name" }
-Step 4: GET  /api/users/me              ✅ 200  (78ms)
-        ↳ Asserted: body.name === "Updated Name"
-Step 5: DELETE /api/users/me            ✅ 204  (95ms)
-Step 6: GET  /api/users/me              ❌ FAIL (67ms)
-        ↳ Expected: 404
-        ↳ Received: 200 { name: "Updated Name", deletedAt: "2026-03-05T..." }
-
-━━━ Failure Analysis ━━━━━━━━━━━━━━━━━━━━
-
-Step 6: Soft-delete returning 200 instead of 404.
-  Root cause: GET route doesn't filter `deletedAt IS NOT NULL`.
-  File to check: controllers/user.controller.ts → findOne method
-  Suggested fix: Add `WHERE deletedAt IS NULL` condition to query.
-
-━━━ Coverage ━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Endpoints tested: 4 of 7 (57%)
-Methods tested:   GET ✅  POST ✅  PUT ✅  DELETE ✅  PATCH ❌
-Auth scenarios:  authenticated ✅  unauthenticated ❌  admin ❌
-```
-
----
-
-## Security Constraints
+Auth Flow:   ✅ Login → token acquired
+POST /users: ✅ 201 Created — id returned
+GET /users:  ✅ 200 — data matches expected schema
+PATCH /users: ✅ 200 — update reflected
+DELETE /users: ✅ 204 No Content
 
-- **Never hardcode** API keys, tokens, or passwords in generated test scripts.
-- **Use env vars**: `process.env.TEST_API_KEY`, `process.env.API_BASE_URL`.
-- **Sanitize test payloads** — no actual SQL injection payloads that could damage data.
-- **Never run destructive tests** against production URLs without explicit user confirmation.
-- **Clean up created resources** at the end of every test flow (DELETE what was POSTed).
-
----
+Error Cases:
+  Unauthenticated: ✅ 401 (expected)
+  Invalid ID:      ✅ 404 (expected)
+  Invalid body:    ✅ 400 (expected) — Zod error returned
+  Rate limiting:   ✅ 429 on attempt 11 (expected)
 
-## Abort Conditions
+━━━ Issues Found ━━━━━━━━━━━━━━━━━━━━━━━━
 
-| Condition | Action |
-|---|---|
-| Server is not running | Prompt to run `/preview start` before continuing |
-| Destructive test (DELETE) on a production URL | Stop and confirm explicitly before executing |
-| Test step fails with 5xx | Halt the flow — server error is not a test assertion failure |
-| Auth step fails | Halt and report — remaining steps are invalid without a token |
-
----
-
-## Cross-Workflow Navigation
-
-| After /api-tester reveals... | Go to |
-|---|---|
-| Soft-delete returning 200, should be 404 | `/fix` or `/debug` the query filter |
-| Endpoint returns 500 on valid input | `/debug` for root cause |
-| Security test: SQL injection returns 500 with DB error | ❌ CRITICAL → `/audit` immediately |
-| Rate limiting is missing | `/enhance` to add rate-limiting middleware |
-| All tests pass, ready for deploy | `/deploy` following pre-flight checklist |
-
----
-
-## Hallucination Guard
-
-- **Scan route files first** — only test endpoints that exist in the codebase.
-- **Verify HTTP methods** — only use methods the route actually supports.
-- **Never invent response fields** — verify against schema, types, or actual response.
-- **Flag assumptions**: `// ASSUMPTION: this endpoint requires JWT auth based on middleware scan`.
-- **Never fabricate response times** — only report measured values.
+  ❌ GET /api/users returns 200 with no auth (should be 401)
+  ⚠️ PATCH /api/users doesn't validate Content-Type (accepts any body)
+```
 
 ---
 
-## Usage
+## Usage Examples
 
 ```
-/api-tester CRUD flow for /api/posts
-/api-tester auth flow with JWT refresh
-/api-tester edge cases for /api/users
-/api-tester full lifecycle for /api/orders including payment
-/api-tester pagination for /api/products
-/api-tester rate limiting on /api/auth/login
+/api-tester POST /api/auth/login then test /api/users CRUD
+/api-tester test the /api/checkout flow with Stripe test card
+/api-tester verify all auth routes return 401 for unauthenticated requests
+/api-tester test rate limiting on /api/auth/login
 ```

package/.agent/workflows/audit.md

@@ -1,168 +1,127 @@
 ---
-description: Full project audit combining security, lint, schema, tests, dependencies, and bundle analysis
+description: Full project audit combining security scan, lint, schema validation, test coverage, dependency analysis, and bundle analysis. Runs all scripts in priority order. Human review required before applying any fixes.
 ---
 
-# /audit — Comprehensive Project Health Check
+# /audit — Complete Project Health Assessment
 
 $ARGUMENTS
 
 ---
 
-This command runs a full audit of the project, combining all available analysis scripts in priority order. Use it before major releases, after onboarding to a new codebase, or whenever you need a complete health check.
-
----
-
 ## When to Use /audit
 
-| Situation | Recommended |
-|---|---|
-| Before a production deploy | `/audit` (full) |
-| After a dependency upgrade | `/audit` — focus on deps + security |
-| When onboarding to a new codebase | `/audit` — full scan first |
-| Single file just changed | `/review [file]` is faster |
-| Suspected security issue | `/audit` — security runs first |
+|Use `/audit` when...|Use something else when...|
+|:---|:---|
+|Before a major release or launch|Single file review → `/review`|
+|After a security incident|Just lint errors → `/fix`|
+|Onboarding to a new codebase|Performance only → `/performance-benchmarker`|
+|Weekly/monthly health check|Testing only → `/test`|
+|Before major dependency updates||
 
 ---
 
-## What Happens
+## Execution Order (Fixed — Do Not Reorder)
 
-The audit runs in strict priority order. Critical issues block further checks:
+Security failures early in the pipeline halt subsequent steps. Lint/test failures continue with flags.
 
 ```
-Priority 1 → Security Scan         (CRITICAL: halts on failure)
-Priority 2 → Lint & Type Check     (BLOCKING for deploy on error)
-Priority 3 → Schema Validation     (advisory)
-Priority 4 → Test Suite            (advisory, marks task incomplete)
-Priority 5 → Dependency Analysis   (advisory)
-Priority 6 → Bundle Size Analysis  (advisory)
-```
+Priority 1 — Security (HALT if critical finding)
+  python .agent/scripts/security_scan.py .
 
-### Execution Commands
+Priority 2 — Dependencies (HALT if exploitable CVE found)
+  python .agent/scripts/dependency_analyzer.py . --audit
 
-Each priority maps to a script:
+Priority 3 — Type Checking (CONTINUE but flag)
+  npx tsc --noEmit
 
-```bash
-# Priority 1 — Security
-// turbo
-python .agent/scripts/security_scan.py .
+Priority 4 — Lint (CONTINUE but flag as deployment blocker)
+  python .agent/scripts/lint_runner.py .
 
-# Priority 2 — Lint
-// turbo
-python .agent/scripts/lint_runner.py .
+Priority 5 — Schema Validation (CONTINUE but flag)
+  python .agent/scripts/schema_validator.py .
 
-# Priority 3 — Schema
-// turbo
-python .agent/scripts/schema_validator.py .
+Priority 6 — Tests (CONTINUE but mark incomplete)
+  python .agent/scripts/test_runner.py . --coverage
 
-# Priority 4 — Tests
-// turbo
-python .agent/scripts/test_runner.py .
-
-# Priority 5 — Dependencies
-// turbo
-python .agent/scripts/dependency_analyzer.py . --audit
-
-# Priority 6 — Bundle
-// turbo
-python .agent/scripts/bundle_analyzer.py .
+Priority 7 — Bundle Analysis (INFORM only)
+  python .agent/scripts/bundle_analyzer.py . --build
 ```
 
-### Abort Conditions
+### Cascade Failure Rules
 
-| Priority | Condition | Action |
-|---|---|---|
-| Security (P1) | CRITICAL findings | **HALT** — report and stop. Do not proceed until resolved. |
-| Lint (P2) | Errors (not warnings) | Continue but flag as **deploy-blocking** |
-| Schema (P3) | Any failure | Continue, report as advisory |
-| Tests (P4) | Failures | Continue, mark task as **incomplete** |
-| Deps (P5) | Vulnerabilities | Continue, flag severity level |
-| Bundle (P6) | Oversized assets | Continue, note thresholds exceeded |
-
-### Script Failure Handling
-
-```
-Script exits 0     → Success, continue pipeline
-Script exits 1     → Failure, report and decide: retry or skip?
-Script not found   → Skip with ⚠️ warning, do not block pipeline
-Script times out   → Kill process, report timeout, continue with next check
-```
+|Check|Failure Behavior|
+|:---|:---|
+|Security scan (critical)|**HALT** — all subsequent steps cancelled|
+|Dependency audit (exploitable CVE)|**HALT** — fix before proceeding|
+|Lint + type errors|**CONTINUE** — flag as deployment blocker|
+|Tests failing|**CONTINUE** — mark task as incomplete|
+|Bundle analysis (large)|**INFORM** — no blocking|
 
 ---
 
-## Scoped Audit (Optional)
+## Script Retry Protocol
 
-To audit a specific concern only, pass a flag:
-
-```bash
-/audit security only          → runs Priority 1 only
-/audit deps                   → runs Priority 5 only
-/audit lint                   → runs Priority 2 only
-/audit before deploy          → runs P1 + P2 + P4 (blocking gates only)
-/audit fresh codebase         → runs full suite and flags all advisory items
+```
+Script exits 0:     Success — continue pipeline
+Script exits 1:     Failure — report and decide: retry or skip?
+Script not found:   Skip with warning — do not block pipeline
+Script times out:   Kill after 5 min — report timeout — continue
+Script crashes:     Catch exception — report stack trace — continue
 ```
 
+**Hard limit: 3 retries per script.** After 3 failures, report to human and continue with remaining scripts.
+
 ---
 
 ## Audit Report Format
 
-After running all checks, produce a structured report:
-
-```markdown
-## 🔍 Project Audit Report — [date]
-
-### Security: [PASS ✅ / FAIL ❌]
-- [findings summary with severity: CRITICAL / HIGH / MEDIUM / LOW]
-
-### Lint & Types: [PASS ✅ / FAIL ❌]
-- [findings summary — errors vs. warnings distinguished]
-
-### Schema: [PASS ✅ / WARN ⚠️ / N/A]
-- [findings summary]
-
-### Tests: [PASS ✅ / FAIL ❌ / N/A]
-- [pass/fail counts + names of failing tests]
-
-### Dependencies: [CLEAN ✅ / ISSUES ⚠️]
-- [phantom imports, unused deps, known vulnerabilities with CVE IDs]
-
-### Bundle: [OK ✅ / LARGE ⚠️ / N/A]
-- [total size, heavy deps, suggested optimizations]
-
-### Verdict:
-[DEPLOY-READY ✅ / BLOCKED ❌ — reason]
-[Next recommended action]
+```
+━━━ Audit Report: [Project Name] ━━━━━━━━━━━━━━━━━━━━
+
+Score: [N/7 checks passed]
+
+1. Security Scan:         ✅ PASSED | ❌ FAILED (CRITICAL — HALTED) | ⚠️ WARNINGS
+2. Dependency Audit:      ✅ PASSED | ❌ FAILED (CVE-XXXX-XXXX found) | ⚠️ WARNINGS
+3. TypeScript:            ✅ PASSED | ❌ FAILED (N errors)
+4. Lint:                  ✅ PASSED | ❌ FAILED (N errors, M warnings)
+5. Schema Validation:     ✅ PASSED | ❌ FAILED | N/A
+6. Test Coverage:         ✅ PASSED | ❌ FAILED (N% — below 80% threshold)
+7. Bundle Size:           ✅ GOOD (310kb) | ⚠️ LARGE (>500kb) | ❌ CRITICAL (>1mb)
+
+━━━ Critical Issues (Fix Before Deploy) ━━━━━━━━━━━━━
+- [CRITICAL] SQL injection in src/routes/users.ts:47
+- [HIGH] JWT secret from hardcoded fallback in src/lib/auth.ts:12
+
+━━━ Important Issues (Fix Before Release) ━━━━━━━━━━
+- [MEDIUM] 4 TypeScript 'any' types in src/components/
+- [MEDIUM] Test coverage: 58% (target: 80%)
+
+━━━ Recommendations ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+- Update lodash 4.17.20 → 4.17.21 (Prototype pollution CVE)
+- Add @types/node to devDependencies (missing)
+- Bundle size: chart library causes +240kb — use dynamic import
+
+━━━ Suggested Next Steps ━━━━━━━━━━━━━━━━━━━━━━━━━━
+Critical items → /tribunal-backend to fix injection and JWT issues
+Test gaps → /test to add coverage for checkout and auth flows
+Bundle → /enhance to add dynamic import for chart component
 ```
 
 ---
 
-## Quick Audit
+## Human Review Gate
 
-For a faster check that skips bundle and schema:
+After the audit report is produced:
 
-```bash
-// turbo
-python .agent/scripts/checklist.py .
 ```
+Human Gate required before any fixes are applied.
 
----
-
-## Cross-Workflow Navigation
+Approve a fix plan?
+Y = proceed with automated fixes where safe
+N = report only, no changes
+S = select specific items to fix
+```
 
-| If the audit reveals... | Go to |
-|---|---|
-| Security CRITICAL findings | `/review [file]` for targeted analysis, then fix with `/generate` |
-| Many lint errors | `/fix` to auto-resolve lint and formatting issues |
-| Test failures | `/debug` to find root cause, then `/test` to add coverage |
-| Outdated or vulnerable dependencies | `/migrate` for framework/dependency upgrades |
-| Bundle size too large | `/tribunal-performance` for optimization review |
+No files are modified without explicit approval.
 
 ---
-
-## Usage
-
-```
-/audit
-/audit this project before we deploy
-/audit focus on security and dependencies only
-/audit after upgrading to Next.js 15
-```