D_Test

Local Testing, Debugging and Troubleshooting

Prompting > Files

This is where I think we might want to have claude-flow comb meticulously though the entire application for errors, bugs, potential issues, refactoring, all of it, lets come up with a stellar prompt for this. Then it will document all issues, WE SHOULD THEN VALIDATE ANY POSSIBLE BREAKING CHANGES, break it up into bite sized development phases, and knock them out one at a time, ANOTHER STELLAR PROMPT.

Claude Teams [Agents in parallel] : https://code.claude.com/docs/en/agent-teams#enable-agent-teams

We may need to revise this prompt so its geared toward initially FIXING errors with the goal of having all features work correctly, THEN perform a deep audit for improvements.

Effectively 2 stages of testing, fix and then optimize.

START DEBUG PROMPT

--- START FUNCTIONALITY PROMPT ---

Application Debugging & Functional Audit — Agent Team Prompt

Objective: Find every error preventing this application from functioning properly. Test all pages, functions, connections, and features. Identify root causes and provide minimal, surgical fixes.

Development Principle: Make minimal, surgical edits—use existing systems and avoid new dependencies unless absolutely necessary.

AGENT TEAM STRUCTURE

Deploy the following specialist agents in parallel. Each agent operates independently, logs findings, and reports back to a central triage document.

Agent	Role	Focus Area
Agent 1: Mapper	Discovery & Dependency Tracer	Project structure, entry points, dependency graph, import chains
Agent 2: Boot Tester	Startup & Build Agent	Can the app install, build, and start without errors?
Agent 3: Route Walker	Page & Route Tester	Hit every route/page, log status codes, crashes, and render failures
Agent 4: Function Prober	Feature & Logic Tester	Test every interactive feature, form, button, CRUD operation, and workflow
Agent 5: Connection Auditor	API & Data Layer Tester	Test every API call, database query, external service connection, and auth flow
Agent 6: Console Watcher	Error Log Collector	Capture every console error, warning, unhandled rejection, and stack trace
Agent 7: Config Checker	Environment & Config Validator	Validate all env vars, config files, secrets, ports, and connection strings

PHASE 0: DISCOVERY & MAPPING (Agent 1)

Before any testing begins, build the map.

0.1 — Project Structure Scan

bash

# Generate full project tree (exclude node_modules, .git, dist, build)
find . -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' | head -500

Recursively list every file and directory
Identify the tech stack: frameworks, languages, libraries, build tools
Read ALL dependency files (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, pom.xml, etc.)
Read ALL config files (.env, .env.example, docker-compose, tsconfig, vite.config, webpack.config, CI/CD pipelines, etc.)
Identify every entry point (main files, index files, server files, app files)
Read any existing README, CONTRIBUTING, or docs

0.2 — Dependency & Import Map

Trace which files import which other files
Flag any broken import paths (file referenced but doesn't exist)
Flag any circular dependencies
Flag any orphan files (exist but are never imported/used)
Flag any missing dependencies (imported but not in package manifest)
Flag any mismatched versions between lockfile and manifest

0.3 — Architecture Snapshot

Produce a brief summary:

Architecture pattern (MVC, monolith, microservices, serverless, etc.)
Data flow: how does data move from user → frontend → API → database → response?
Authentication method (JWT, sessions, OAuth, etc.)
State management approach
Routing structure (file-based, config-based, etc.)

Output: A PROJECT_MAP.md file with the full structure, tech stack, entry points, and dependency graph.

PHASE 1: STARTUP & BUILD TEST (Agent 2)

Can the app actually start? Test every step of the startup chain.

1.1 — Dependency Installation Test

bash

# Log the FULL output — every warning matters
npm install 2>&1 | tee install_log.txt
# or: pip install -r requirements.txt 2>&1 | tee install_log.txt
# or: bundle install 2>&1 | tee install_log.txt

Record every warning and error from the install step
Check for peer dependency conflicts
Check for deprecated packages
Check for platform-specific failures

1.2 — Build Test

bash

npm run build 2>&1 | tee build_log.txt

Record the full build output
Capture every compilation error, warning, and failure
Check for TypeScript errors (if applicable)
Check for missing environment variables referenced at build time
Check for broken paths in build config

1.3 — Server Start Test

bash

npm run dev 2>&1 | tee server_log.txt &
# Wait for startup, then check
sleep 10
curl -s -o /dev/null -w "%{http_code}" http://localhost:PORT

Does the dev server start without crashing?
Does it respond on the expected port?
Capture the full startup log including all warnings
Check for port conflicts
Check for missing database connections at startup
Check for missing env vars that cause immediate crash

1.4 — Startup Error Classification

For every error found, classify:

Error	File	Line	Blocks Startup?	Error Message

Output: STARTUP_LOG.md with pass/fail for each step and full error logs.

PHASE 2: ROUTE & PAGE TESTING (Agent 3)

Systematically hit every route in the application.

2.1 — Route Inventory

Extract every route from the router config, file-based routing, or route definitions
Include both frontend routes (pages) and backend routes (API endpoints)
List expected auth requirements per route

2.2 — Page Render Test

For EVERY frontend route:

Route: /dashboard
Expected: Renders dashboard page
Actual: [PASS | FAIL | CRASH | BLANK | REDIRECT]
Console Errors: [list any]
Network Errors: [list any failed requests]
Screenshot/Description: [what actually renders]

2.3 — API Endpoint Test

For EVERY backend endpoint:

Endpoint: GET /api/users
Expected: Returns user list (200)
Actual: [status code] [response body or error]
Auth Required: [yes/no, tested both ways]
Response Time: [ms]

Click through every link and navigation element
Test browser back/forward behavior
Test direct URL access (deep linking)
Test 404/error pages
Test redirects (auth redirects, role-based redirects)

Output: ROUTE_TEST_LOG.md — a table of every route with pass/fail status and error details.

PHASE 3: FEATURE & FUNCTION TESTING (Agent 4)

Test every interactive feature in the application.

3.1 — Feature Inventory

Before testing, list every feature:

User authentication (register, login, logout, password reset, session management)
CRUD operations (create, read, update, delete for every data type)
Forms (every form in the app — submission, validation, error handling)
File uploads/downloads
Search/filter functionality
Notifications (email, push, in-app)
Payment/billing flows (if applicable)
Admin functions
Any third-party integrations

3.2 — Feature Test Protocol

For EACH feature, run this test:

Feature: User Login
Steps:
  1. Navigate to /login
  2. Enter valid credentials → Expected: redirect to dashboard
  3. Enter invalid credentials → Expected: error message shown
  4. Submit empty form → Expected: validation errors
  5. Check "remember me" (if exists) → Expected: persistent session
Result: [PASS | PARTIAL | FAIL]
Errors Found: [specific errors with file, line, stack trace]

3.3 — Edge Case Testing

For every feature:

Empty inputs
Extremely long inputs
Special characters (<script>, SQL injection strings, unicode)
Rapid repeated submissions (double-click, spam)
Concurrent operations (two tabs, same action)
Missing data scenarios (what if the API returns empty?)
Network failure during operation

3.4 — State Management Testing

Does state persist correctly across page navigations?
Does state reset when it should (logout, etc.)?
Are loading/error/empty states handled?
Does the UI reflect the actual data state after mutations?

Output: FEATURE_TEST_LOG.md — every feature with pass/fail, exact errors, and reproduction steps.

PHASE 4: API & DATA CONNECTION TESTING (Agent 5)

Test every connection the application makes.

4.1 — Database Connection Test

bash

# Test the database connection directly
# Example for PostgreSQL:
psql $DATABASE_URL -c "SELECT 1;" 2>&1
# Example for MongoDB:
mongosh $MONGO_URI --eval "db.runCommand({ping:1})" 2>&1

Can the app connect to the database?
Are all expected tables/collections present?
Are migrations up to date?
Do schema definitions match the actual database?

4.2 — API Integration Test

For every external API the app calls:

Service: Stripe API
Endpoint Called: POST /v1/charges
Config Location: .env → STRIPE_SECRET_KEY
Connection Test: [PASS | FAIL]
Error: [if any]

4.3 — Internal API Contract Test

For every internal API route:

Does the frontend call match what the backend expects? (method, path, body shape, headers)
Does the backend response match what the frontend expects? (status code, body shape)
Are there mismatched field names between frontend and backend?
Are there endpoints the frontend calls that don't exist in the backend?
Are there backend routes that nothing calls?

4.4 — Auth Flow Test

Test the full authentication cycle: register → verify → login → access protected → refresh token → logout
Test expired tokens/sessions
Test accessing protected routes without auth
Test role-based access (if applicable)
Check token storage (where is it stored? Is it secure?)

4.5 — File & Asset Test

Do all referenced static assets (images, fonts, icons) exist and load?
Are uploaded files stored and retrieved correctly?
Are CDN/external resource links valid?

Output: CONNECTION_TEST_LOG.md — every connection with status and error details.

PHASE 5: ERROR COLLECTION & ANALYSIS (Agent 6)

5.1 — Console Error Harvest

Capture ALL console output across every page and interaction:

Error Type: TypeError
Message: Cannot read property 'map' of undefined
File: src/components/UserList.jsx
Line: 42
Triggered By: Navigating to /users when API returns null
Frequency: Every page load

5.2 — Server-Side Error Harvest

Capture ALL server logs:

Error Type: UnhandledPromiseRejection
Message: Connection refused to localhost:5432
File: src/db/connection.js
Line: 15
Triggered By: Server startup without database running
Frequency: Every startup

5.3 — Network Error Harvest

Capture ALL failed network requests:

Request: POST /api/auth/login
Status: 500
Response: {"error": "relation \"users\" does not exist"}
Cause: Database migration not run

5.4 — Error Deduplication & Root Cause Mapping

Group duplicate errors
Trace each error to its root cause (not just where it throws, but WHY)
Map error chains: Error A in file X is CAUSED BY Error B in file Y
Identify the minimum set of root causes that would fix the maximum number of errors

Output: ERROR_LOG.md — every unique error with root cause, file, line, and reproduction steps.

PHASE 6: ENVIRONMENT & CONFIG VALIDATION (Agent 7)

6.1 — Environment Variable Audit

Variable: DATABASE_URL
Referenced In: src/db/connection.js (line 5), docker-compose.yml (line 12)
Set In .env: [YES | NO | WRONG FORMAT]
Set In .env.example: [YES | NO]
Required For: Database connection
What Breaks Without It: App crashes on startup with "CONNECTION_REFUSED"

Do this for EVERY environment variable referenced anywhere in the codebase.

6.2 — Config File Validation

Is every config file valid syntax? (JSON, YAML, TOML, etc.)
Do config files reference files/paths that exist?
Are port numbers consistent across configs?
Do database connection strings match between app config and docker-compose?
Are API base URLs correct for the current environment?

6.3 — Dockerfile & Container Check (if applicable)

Does the Dockerfile build successfully?
Does docker-compose up start all services?
Are volumes mounted correctly?
Are ports mapped correctly?
Are environment variables passed correctly to containers?

Output: CONFIG_VALIDATION_LOG.md — every config item with status and issues.

FINAL OUTPUT: TRIAGE REPORT

After all agents complete, compile into a single document:

markdown

# [Application Name] — Debugging & Functional Audit Report
## Generated: [Date]

## Executive Summary
[2-3 paragraphs: What the app does, what's broken, and the overall diagnosis.
Rate the app: 🟢 Working | 🟡 Partially Working | 🔴 Non-Functional]

## Root Cause Summary
[The top 3-5 root causes that explain the majority of failures.
Example: "80% of errors trace back to (1) missing database migration and (2) incorrect API base URL in .env"]

---

## Tier 1: Blocking Errors (App Cannot Start or Function)
These must be fixed first. The app is broken without them.

### Error 1.1: [Short descriptive title]
**Root Cause File(s):** `path/to/file.js` (line XX)
**Category:** [Crash | Build Failure | Missing Config | Broken Connection]
**Severity:** 🔴 App-Breaking

**What's Happening (Plain English):**
[Explain it like you're telling a non-technical person. Use an analogy.
Example: "The app is trying to open a door that doesn't exist. It's looking
for a database at an address that's wrong, like trying to mail a letter
to a house that was demolished."]

**Technical Root Cause:**
[Exact technical explanation with code references]

**The Fix (Step by Step):**

Step 1: Open path/to/file.js Step 2: On line XX, change:

OLD: const db = connect("localhost:5432")

NEW: const db = connect(process.env.DATABASE_URL) Step 3: Add to your .env file: DATABASE_URL=postgresql://user:pass@localhost:5432/mydb Step 4: Run npm run migrate to create the database tables Step 5: Restart the server with npm run dev


**Verify the Fix:**
[How to confirm the fix worked]

After fixing, you should see:

Server starts without "CONNECTION_REFUSED" error
GET /api/users returns 200 instead of 500
/users page renders the user list instead of blank screen


**Side Effects:**
[What else changes when you apply this fix?
Example: "None — this only corrects the connection string. No other
files reference this variable."]

**Estimated Effort:** [Quick fix (< 15 min) | Small task (< 1 hr) | Medium (< 4 hrs) | Large (full day)]

---

## Tier 2: Functional Errors (App Starts But Features Are Broken)
Features that crash, return wrong data, or fail silently.

[Same format as Tier 1]

---

## Tier 3: Data & State Errors (Incorrect Behavior, Wrong Output)
Things that run without crashing but produce wrong results.

[Same format as Tier 1]

---

## Tier 4: UI & Display Errors (Visual Bugs, Layout Breaks)
Things that look wrong or don't render correctly.

[Same format as Tier 1]

---

## Tier 5: Edge Cases & Reliability Issues
Things that only break under specific conditions.

[Same format as Tier 1]

---

## Appendix A: Full Error Log
| # | Error Message | File | Line | Root Cause | Tier | Fixed By |
|---|---------------|------|------|------------|------|----------|
| 1 | Cannot read property 'map' of undefined | UserList.jsx | 42 | API returns null instead of [] | Tier 2 | Error 2.3 |
| 2 | ... | ... | ... | ... | ... | ... |

## Appendix B: Route Test Results
| Route | Method | Expected | Actual | Status |
|-------|--------|----------|--------|--------|
| / | GET | Home page | ✅ Renders | PASS |
| /login | GET | Login form | ✅ Renders | PASS |
| /dashboard | GET | Dashboard | 🔴 Blank screen | FAIL |
| POST /api/users | POST | Create user | 🔴 500 error | FAIL |

## Appendix C: Feature Test Results
| Feature | Status | Errors | Details |
|---------|--------|--------|---------|
| Login | 🟡 Partial | 1 | Works but no error handling for wrong password |
| Register | 🔴 Broken | 3 | Form submits but API returns 500 |
| Dashboard | 🔴 Broken | 2 | Blank screen, console TypeError |

## Appendix D: Environment Variable Checklist
| Variable | Required | Set | Correct | Used In |
|----------|----------|-----|---------|---------|
| DATABASE_URL | ✅ | ❌ | — | db/connection.js |
| API_KEY | ✅ | ✅ | ✅ | services/api.js |
| JWT_SECRET | ✅ | ❌ | — | auth/jwt.js |

## Appendix E: Dependency Status
| Package | Installed | Imported | Version | Issues |
|---------|-----------|----------|---------|--------|
| express | ✅ | ✅ | 4.18.2 | None |
| react | ✅ | ✅ | 18.2.0 | None |
| bcrypt | ✅ | ❌ | 5.1.0 | Installed but unused |

## Appendix F: Fix Dependency Order
[Which fixes must be applied before others]
1. Fix DATABASE_URL env var (Error 1.1) — prerequisite for everything
2. Run database migrations (Error 1.2) — prerequisite for all API routes
3. Fix API base URL (Error 1.3) — prerequisite for all frontend data
4. Then Tier 2 fixes can be applied in any order
5. Then Tier 3-5 fixes can be applied in any order

CRITICAL RULES

Test everything, assume nothing. Do not assume a file works because it looks correct. Run it. Call it. Verify the output.
Trace to root cause. Don't just report "blank screen on /dashboard." Trace the chain: blank screen → missing component render → API call fails → 500 error → database table doesn't exist → migration not run. Report the ROOT.
Minimal, surgical fixes only. Every fix must use existing systems. Do NOT suggest new libraries, frameworks, or rewrites. Fix what's there.
Plain language is mandatory. Every error must have an explanation a non-developer could understand. Use analogies.
Exact file paths and line numbers. Never say "somewhere in the auth module." Say src/auth/jwt.js line 23.
Show the fix, not just the problem. Every error must include step-by-step fix instructions with before/after code.
Document the fix order. Some fixes depend on others. Provide a clear dependency order so devs don't waste time fixing downstream symptoms before upstream causes.
Log everything. Create actual debug scripts and capture real output. Don't guess what errors might occur — trigger them and record them.
Verify fixes. For every fix, include a verification step — how to confirm the fix actually worked.
Don't hallucinate errors. If something works correctly, say so. False positives waste developer time and erode trust.

END DEBUG PROMPT

--- END FUNCTIONALITY PROMPT ---

_TEMP/AUDIT (Prompts to fix functionality)

Please read _TEMP/CLAUDE.md for project context. Development principles: Make minimal, surgical edits—use existing systems and avoid new dependencies unless absolutely necessary. Warn me before any changes that could break functionality or layouts. Don't create user guides unless I ask. Our dev server is already running. Also, Review all files in _TEMP/AUDIT we will be deciding on these fixes and suggestions this one phase at a time. Keep the documents updated with our progress as we go, so we can pick up from where we left off. Verify documentation is updated and complete. This should be the last thing that you say. Keep _TEMP\STATUS.md updated with: - Our objective - What were working on now.

Lets talk about ___ What are the chances this fix could break functionality? What negative impact could this have on the application?

Lets fix Phase 4. Be surgical, meticulous, and precise. Verify fixes, run tests, keep code minimal and ensure site wide functionality. Keep the documents updated with our progress as we go, so we can pick up from where we left off. Verify documentation is updated and complete. This should be the last thing that you say. Keep _TEMP\STATUS.md updated with: - Our objective - What were working on now.

--- START OPTIMIZATION PROMPT ---

START OPTIMIZATION PROMPT

Create an agent team of full-stack engineers, QA specialists, and technical writers performing a complete audit of this application. Your job is to systematically scan every single file, directory, configuration, and dependency in this project — leaving nothing unexamined — and produce comprehensive, phased documentation that any developer (even a beginner) can follow.

PHASE 0: DISCOVERY & MAPPING

Before analyzing anything, build a complete picture of the application:

Map the entire project structure
- Recursively list every file and directory in the project
- Identify the tech stack (frameworks, languages, libraries, build tools)
- Identify the package manager and read all dependency files (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, etc.)
- Read all configuration files (.env, .env.example, config files, docker-compose, CI/CD pipelines, etc.)
- Read all README, CONTRIBUTING, and documentation files
- Identify the entry points of the application (main files, index files, app files, server files)
Create a dependency graph
- Map which files import/require which other files
- Identify circular dependencies
- Identify unused files (files that are never imported anywhere)
- Identify unused dependencies (packages installed but never imported)
Identify the architecture pattern
- Is it MVC, MVVM, microservices, monolith, serverless, etc.?
- How is state managed?
- What is the routing structure?
- What is the data flow?

PHASE 1: CODE QUALITY & ERROR SCAN

Go through EVERY file in the project and check for:

1.1 Syntax & Runtime Errors

Syntax errors, typos in variable/function names
Undefined variables or functions being called
Missing imports or broken import paths
Type mismatches (if typed language)
Uncaught exceptions or missing error handling
Race conditions or async/await misuse
Memory leaks (event listeners not cleaned up, subscriptions not unsubscribed, intervals not cleared)

1.2 Logic Errors

Off-by-one errors in loops
Incorrect conditional logic (wrong operators, missing edge cases)
Functions that never return a value when they should
Dead code (code that can never execute)
Unreachable code after return/break/continue
Switch statements missing break or default cases
Null/undefined not being checked before use

1.3 Security Vulnerabilities

Hardcoded secrets, API keys, passwords, or tokens in source code
SQL injection vulnerabilities
Cross-site scripting (XSS) vulnerabilities
Cross-site request forgery (CSRF) missing protections
Insecure direct object references
Missing input validation and sanitization
Insecure authentication or authorization patterns
Exposed sensitive data in console logs or error messages
Missing CORS configuration or overly permissive CORS
Insecure cookie settings (missing httpOnly, secure, sameSite)
Dependencies with known vulnerabilities (check versions against CVE databases)

1.4 Configuration Issues

Missing or incorrect environment variable handling
Hardcoded URLs, ports, or environment-specific values
Missing .env.example or documentation for required env vars
Misconfigured build/bundler settings
Incorrect or missing TypeScript/ESLint/Prettier configurations
Docker or deployment configuration issues

PHASE 2: ARCHITECTURE & DESIGN REVIEW

2.1 Code Organization

Files that are too long and should be split
Functions that do too many things (violating Single Responsibility)
Duplicated code that should be extracted into shared utilities
Inconsistent naming conventions (camelCase mixed with snake_case, etc.)
Inconsistent file/folder naming and organization
Missing or inconsistent barrel exports (index files)
God components/classes (doing too much)

2.2 Design Patterns

Anti-patterns being used
Prop drilling that should use context/state management
Business logic in UI components that should be separated
Missing abstraction layers (direct database calls from route handlers, etc.)
Tight coupling between modules that should be loosely coupled
Missing interfaces or type definitions

2.3 API & Data Layer

Inconsistent API response formats
Missing API versioning
N+1 query problems
Missing database indexes for frequently queried fields
Missing pagination on list endpoints
Inconsistent error response formats
Missing request validation/schema validation
Improper HTTP methods being used (GET for mutations, etc.)

PHASE 3: PERFORMANCE AUDIT

3.1 Frontend Performance

Large bundle sizes (identify what's bloating the bundle)
Missing code splitting or lazy loading
Unoptimized images (missing compression, wrong formats, missing width/height, no lazy loading)
Missing caching strategies (service workers, HTTP cache headers, memoization)
Unnecessary re-renders in React/Vue/Svelte components
Large lists not using virtualization
Blocking the main thread with heavy computations
Missing loading states and skeleton screens
Layout shifts (missing dimensions on images/embeds)
Unused CSS or JavaScript being loaded
Too many HTTP requests that could be batched
Missing preloading/prefetching for critical resources
Fonts causing FOUT/FOIT (flash of unstyled/invisible text)

3.2 Backend Performance

Slow database queries (missing indexes, unoptimized queries, SELECT *)
Missing connection pooling
No caching layer (Redis, in-memory, etc.)
Synchronous operations that should be async
Missing rate limiting
Missing compression (gzip/brotli)
Large payloads being sent when partial data would suffice
Missing background job processing for heavy tasks

3.3 Network Performance

Unnecessary API calls on every render/mount
Missing debouncing/throttling on frequent events (scroll, resize, input)
No optimistic UI updates
Missing request deduplication
WebSocket connections not being managed properly

PHASE 4: UI/UX & MOBILE RESPONSIVENESS

4.1 Responsive Design

Scan EVERY component/page for mobile responsiveness issues
Fixed widths that should be fluid (px that should be %, vw, rem, etc.)
Missing or incorrect media queries
Text that overflows containers on small screens
Touch targets smaller than 44x44px (minimum for mobile accessibility)
Horizontal scrolling on mobile
Images that don't scale properly
Navigation that doesn't collapse to mobile-friendly format
Forms that are unusable on mobile (tiny inputs, no appropriate input types)
Modals/popups that don't work on mobile
Tables that don't have a mobile strategy (scroll, stack, or collapse)
Font sizes that are too small on mobile (minimum 16px for body text)

Missing alt text on images
Missing ARIA labels on interactive elements
Incorrect heading hierarchy (skipping h1 to h3, multiple h1s)
Insufficient color contrast ratios (minimum 4.5:1 for normal text)
Missing focus indicators
Keyboard navigation not working
Missing form labels
Dynamic content changes not announced to screen readers
Missing skip navigation link
Missing lang attribute on HTML element

4.3 Cross-Browser Compatibility

CSS features not supported in target browsers
JavaScript APIs not available in target browsers
Missing vendor prefixes where needed
Inconsistent form styling across browsers

PHASE 5: TESTING & RELIABILITY

5.1 Test Coverage

Files/functions with no test coverage
Tests that exist but are skipped or broken
Missing edge case testing
Missing integration tests
Missing end-to-end tests for critical user flows
Tests that test implementation details instead of behavior
Flaky tests (tests with race conditions or timing issues)
Missing error/failure path testing

5.2 Error Handling & Resilience

Missing global error boundary (React) or error handler
API calls without try/catch or .catch()
Missing user-friendly error messages (showing raw errors to users)
No retry logic for flaky network requests
Missing timeout handling
No graceful degradation when services are unavailable
Missing loading and empty states

PHASE 6: DEVELOPER EXPERIENCE & MAINTENANCE

6.1 Documentation

Missing or outdated README
Missing setup/installation instructions
Missing API documentation
Missing component documentation or storybook
Missing inline comments for complex logic
Outdated comments that don't match the code

6.2 Development Workflow

Missing or incomplete linting configuration
Missing formatting configuration (Prettier, etc.)
Missing pre-commit hooks
Missing CI/CD pipeline or incomplete pipeline
Missing containerization (Dockerfile, docker-compose)
Inconsistent scripts in package.json

6.3 Dependency Health

Outdated dependencies (major versions behind)
Dependencies with known security vulnerabilities
Dependencies that are abandoned/unmaintained
Too many dependencies for what they do (could be replaced with simple utility functions)
Conflicting dependency versions
Missing lock file (package-lock.json, yarn.lock, etc.)

OUTPUT FORMAT: DOCUMENTATION REQUIREMENTS

After completing ALL phases above, produce a single comprehensive document structured as follows. This is the MOST IMPORTANT PART — the documentation must be:

Document Structure

# [Application Name] — Complete Audit Report
## Generated: [Date]
## Application Overview
[2-3 paragraph summary of what the app does, the tech stack, and overall health assessment with a letter grade A-F]

---

## Development Phase 1: Critical Fixes (Do These First)
[Issues that are actively causing bugs, crashes, security vulnerabilities, or data loss]

### Issue 1.1: [Short descriptive title]
**File(s):** `path/to/file.js` (line XX-XX)
**Category:** [Bug | Security | Crash | Data Loss]
**Severity:** 🔴 Critical

**What's wrong (Simple Explanation):**
[Explain the issue as if you're talking to a 12-year-old. Use analogies. No jargon. Example: "Right now, the app saves your password like writing it on a sticky note and putting it on the fridge — anyone who walks by can read it. It needs to be locked in a safe instead."]

**Technical Details:**
[Precise code reference, what's wrong, and the exact fix with code snippets showing before/after]

**What happens if you fix this:**
[Explain every possible side effect, dependency, or thing that could break. Be specific. Example: "Fixing this will change how passwords are stored. Any users who are currently logged in will be logged out and will need to reset their passwords. The login page will need to be updated to use the new password format. If you have a mobile app that connects to this API, it will also need to be updated."]

**What happens if you DON'T fix this:**
[Explain the risk of leaving it as-is. Example: "If a hacker gets access to your database, they can read every user's password in plain text. This could lead to a data breach, legal liability, and loss of user trust."]

**Estimated effort:** [Quick fix (< 30 min) | Small task (1-2 hours) | Medium task (half day) | Large task (full day) | Major refactor (multi-day)]

---

### Issue 1.2: [Next issue...]
[Same format as above]

---

## Development Phase 2: High-Priority Improvements
[Issues that significantly degrade user experience, performance, or developer productivity but aren't actively causing crashes]

[Same issue format as Phase 1]

---

## Development Phase 3: Mobile & Responsive Fixes
[All issues related to mobile responsiveness, touch interactions, and small-screen layouts]

[Same issue format as Phase 1]

---

## Development Phase 4: Performance Optimizations
[Issues that make the app slow but don't break functionality]

[Same issue format as Phase 1]

---

## Development Phase 5: Code Quality & Refactoring
[Issues that make the code harder to maintain, read, or extend — but don't affect users directly]

[Same issue format as Phase 1]

---

## Development Phase 6: Accessibility & Compliance
[Issues related to accessibility, browser compatibility, and standards compliance]

[Same issue format as Phase 1]

---

## Development Phase 7: Testing & Documentation
[Missing tests, documentation gaps, and developer experience improvements]

[Same issue format as Phase 1]

---

## Development Phase 8: Nice-to-Have Enhancements
[Suggestions that would improve the app but are entirely optional]

[Same issue format as Phase 1]

---

## Appendix A: File-by-File Summary
[A table listing EVERY file in the project with a one-line status]
| File | Status | Issues Found | Phase |
|------|--------|-------------|-------|
| src/index.js | ⚠️ Issues | 3 issues | Phase 1, 2 |
| src/App.js | ✅ Clean | 0 issues | — |
| ... | ... | ... | ... |

## Appendix B: Dependency Audit
[Table of all dependencies with version, latest version, vulnerability status, and whether it's actively used]

## Appendix C: Quick Wins
[A prioritized list of the top 10 easiest fixes that would have the biggest positive impact, sorted by effort-to-impact ratio]

CRITICAL RULES FOR THE AUDIT

Scan EVERY file. Do not skip any file. Do not assume a file is fine without reading it. If there are hundreds of files, scan them all systematically.
Be specific. Every issue must reference exact file paths, line numbers, and include code snippets. Never say "there might be an issue somewhere in the codebase."
Plain language is mandatory. Every issue MUST have a "Simple Explanation" that a 12-year-old could understand. Use analogies and everyday language. Technical details go in a separate section.
Impact analysis is mandatory. Every issue MUST explain what could break or change if fixed. Developers need this to make informed decisions. Never say "this is a safe change" without explaining WHY it's safe and what to verify after making it.
Phases must be bite-sized. Each phase should contain issues that can be worked on independently. No single issue should require more than a day of work — if it does, break it into sub-tasks.
Don't just find problems — provide solutions. Every issue must include a clear, actionable fix with code examples where applicable.
Preserve working functionality. If something works but isn't ideal, explain the tradeoff. The developer should always be able to choose "leave it as is" with full understanding of the consequences.
Check file relationships. When you find an issue in one file, check all files that import or depend on it. Document the ripple effects.
Test configurations matter. Check Jest, Vitest, Cypress, Playwright, or whatever test config exists. Check if tests actually pass.
Don't hallucinate issues. If a file is genuinely well-written and has no issues, say so. Not every file needs criticism. Credit good patterns when you see them.

BEGIN THE AUDIT NOW. Start with Phase 0 (Discovery) and work through every phase methodically. Output the final documentation in the format specified above.

`---
 END OPTIMIZATION PROMPT 
---`

## END OPTIMIZATION PROMPT

D_Test ​

Local Testing, Debugging and Troubleshooting ​

START DEBUG PROMPT ​

Application Debugging & Functional Audit — Agent Team Prompt ​

AGENT TEAM STRUCTURE ​

PHASE 0: DISCOVERY & MAPPING (Agent 1) ​

0.1 — Project Structure Scan ​

0.2 — Dependency & Import Map ​

0.3 — Architecture Snapshot ​

PHASE 1: STARTUP & BUILD TEST (Agent 2) ​

1.1 — Dependency Installation Test ​

1.2 — Build Test ​

1.3 — Server Start Test ​

1.4 — Startup Error Classification ​

PHASE 2: ROUTE & PAGE TESTING (Agent 3) ​

2.1 — Route Inventory ​

2.2 — Page Render Test ​

2.3 — API Endpoint Test ​

2.4 — Navigation Flow Test ​

PHASE 3: FEATURE & FUNCTION TESTING (Agent 4) ​

3.1 — Feature Inventory ​

3.2 — Feature Test Protocol ​

3.3 — Edge Case Testing ​

3.4 — State Management Testing ​

PHASE 4: API & DATA CONNECTION TESTING (Agent 5) ​

4.1 — Database Connection Test ​

4.2 — API Integration Test ​

4.3 — Internal API Contract Test ​

4.4 — Auth Flow Test ​

4.5 — File & Asset Test ​

PHASE 5: ERROR COLLECTION & ANALYSIS (Agent 6) ​

5.1 — Console Error Harvest ​

5.2 — Server-Side Error Harvest ​

5.3 — Network Error Harvest ​

5.4 — Error Deduplication & Root Cause Mapping ​

PHASE 6: ENVIRONMENT & CONFIG VALIDATION (Agent 7) ​

6.1 — Environment Variable Audit ​

6.2 — Config File Validation ​

6.3 — Dockerfile & Container Check (if applicable) ​

FINAL OUTPUT: TRIAGE REPORT ​

CRITICAL RULES ​

END DEBUG PROMPT ​

_TEMP/AUDIT (Prompts to fix functionality) ​

START OPTIMIZATION PROMPT ​

PHASE 0: DISCOVERY & MAPPING ​

PHASE 1: CODE QUALITY & ERROR SCAN ​

1.1 Syntax & Runtime Errors ​

1.2 Logic Errors ​

1.3 Security Vulnerabilities ​

1.4 Configuration Issues ​

PHASE 2: ARCHITECTURE & DESIGN REVIEW ​

2.1 Code Organization ​

2.2 Design Patterns ​

2.3 API & Data Layer ​

PHASE 3: PERFORMANCE AUDIT ​

3.1 Frontend Performance ​

3.2 Backend Performance ​

3.3 Network Performance ​

PHASE 4: UI/UX & MOBILE RESPONSIVENESS ​

4.1 Responsive Design ​

4.2 Accessibility (a11y) ​

4.3 Cross-Browser Compatibility ​

PHASE 5: TESTING & RELIABILITY ​

5.1 Test Coverage ​

5.2 Error Handling & Resilience ​

PHASE 6: DEVELOPER EXPERIENCE & MAINTENANCE ​

6.1 Documentation ​

6.2 Development Workflow ​

6.3 Dependency Health ​

OUTPUT FORMAT: DOCUMENTATION REQUIREMENTS ​

Document Structure ​

CRITICAL RULES FOR THE AUDIT ​

D_Test

Local Testing, Debugging and Troubleshooting

START DEBUG PROMPT

Application Debugging & Functional Audit — Agent Team Prompt

AGENT TEAM STRUCTURE

PHASE 0: DISCOVERY & MAPPING (Agent 1)

0.1 — Project Structure Scan

0.2 — Dependency & Import Map

0.3 — Architecture Snapshot

PHASE 1: STARTUP & BUILD TEST (Agent 2)

1.1 — Dependency Installation Test

1.2 — Build Test

1.3 — Server Start Test

1.4 — Startup Error Classification

PHASE 2: ROUTE & PAGE TESTING (Agent 3)

2.1 — Route Inventory

2.2 — Page Render Test

2.3 — API Endpoint Test

2.4 — Navigation Flow Test

PHASE 3: FEATURE & FUNCTION TESTING (Agent 4)

3.1 — Feature Inventory

3.2 — Feature Test Protocol

3.3 — Edge Case Testing

3.4 — State Management Testing

PHASE 4: API & DATA CONNECTION TESTING (Agent 5)

4.1 — Database Connection Test

4.2 — API Integration Test

4.3 — Internal API Contract Test

4.4 — Auth Flow Test

4.5 — File & Asset Test

PHASE 5: ERROR COLLECTION & ANALYSIS (Agent 6)

5.1 — Console Error Harvest

5.2 — Server-Side Error Harvest

5.3 — Network Error Harvest

5.4 — Error Deduplication & Root Cause Mapping

PHASE 6: ENVIRONMENT & CONFIG VALIDATION (Agent 7)

6.1 — Environment Variable Audit

6.2 — Config File Validation

6.3 — Dockerfile & Container Check (if applicable)

FINAL OUTPUT: TRIAGE REPORT

CRITICAL RULES

END DEBUG PROMPT

_TEMP/AUDIT (Prompts to fix functionality)

START OPTIMIZATION PROMPT

PHASE 0: DISCOVERY & MAPPING

PHASE 1: CODE QUALITY & ERROR SCAN

1.1 Syntax & Runtime Errors

1.2 Logic Errors

1.3 Security Vulnerabilities

1.4 Configuration Issues

PHASE 2: ARCHITECTURE & DESIGN REVIEW

2.1 Code Organization

2.2 Design Patterns

2.3 API & Data Layer

PHASE 3: PERFORMANCE AUDIT

3.1 Frontend Performance

3.2 Backend Performance

3.3 Network Performance

PHASE 4: UI/UX & MOBILE RESPONSIVENESS

4.1 Responsive Design

4.2 Accessibility (a11y)

4.3 Cross-Browser Compatibility

PHASE 5: TESTING & RELIABILITY

5.1 Test Coverage

5.2 Error Handling & Resilience

PHASE 6: DEVELOPER EXPERIENCE & MAINTENANCE

6.1 Documentation

6.2 Development Workflow

6.3 Dependency Health

OUTPUT FORMAT: DOCUMENTATION REQUIREMENTS

Document Structure

CRITICAL RULES FOR THE AUDIT