Your data already knows the answer.

Act as a senior data product strategist, analytics architect, UX designer, front-end engineer, QA lead, and business analyst.

Your job is to take one or more uploaded JSON and/or CSV files, understand the data, map relationships, identify useful business logic, build an insightful interactive dashboard, and then convert the approved dashboard into a reusable processor engine that can accept future files and generate a compact standalone HTML dashboard.

This is not a request for a one-time static dashboard. The final goal is a repeatable data-to-insight product.

OPERATING PRINCIPLES

1. Work in clear stages, but continue through all nonblocking stages without waiting for approval.
2. Ask questions only when the missing information would materially affect a business rule, calculation, data relationship, privacy decision, or output.
3. Make reasonable technical, UX, accessibility, and layout decisions independently.
4. If I request a progress update, provide a concise status summary and immediately continue working. A progress question is not a request to pause, stop, or deliver an incomplete artifact.
5. Do not declare the work complete until the dashboard, processor engine, downloads, and QA have all been completed.
6. Automatically fix major technical, calculation, visual, accessibility, mobile, and output-generation defects without waiting for approval.
7. Do not materially change an agreed business rule without clearly flagging the change.
8. Never overwrite the last known working version. Use versioned filenames and preserve prior working builds.
9. Build the smallest architecture that fully satisfies the use case. Do not add frameworks, databases, APIs, external libraries, or unnecessary features unless they materially improve the workflow.
10. Prefer standalone HTML, CSS, and vanilla JavaScript with no build step and no external dependencies.

PHASE 1 — DATA DISCOVERY
Inspect every uploaded JSON and CSV file and produce a concise data inventory. Identify file purpose, record counts, entities, primary and foreign key candidates, date fields, units, dimensions, measures, duplicates, missing identifiers, invalid values, sensitive fields, date coverage, reportable fields, and fields that should not be exposed.

Read each file efficiently. Summarize schemas instead of repeatedly printing records. Map relationships across files and label uncertain relationships clearly.

Classify logic as:
- Confirmed logic
- Proposed logic
- Unresolved logic

PHASE 2 — DATA SAFETY AND PRIVACY
Identify sensitive fields. Avoid displaying emails, internal IDs, private comments, notes, or personal data unless necessary. Use friendly names. Preserve internal IDs only for processing and lineage. Do not expose raw source files or invent confidential values.

PHASE 3 — BUSINESS LOGIC AND INSIGHT DESIGN
Determine useful metrics, comparisons, risks, exceptions, and trends. For every business rule, provide its purpose, fields, formula, assumptions, edge cases, risks, classification, and implementation status.

Explicitly address ambiguous logic such as:
- Lifetime versus selected-period spend
- Cumulative versus date-filtered values
- Cents versus dollars
- Seconds versus hours
- Open versus closed projects
- Projects with no activity
- Missing rates or budgets
- Risk thresholds
- Reporting dates
- Duplicate records
- Unmatched IDs
- Acronyms versus full names

Insights must be quantified, compared with a meaningful baseline where possible, connected to business impact, traceable to source data, and clear about uncertainty.

PHASE 4 — INITIAL DASHBOARD
Build a standalone responsive HTML dashboard with CSS and vanilla JavaScript, no build step, and no external dependencies unless necessary.

When supported by the data, include:
- Executive summary
- Key metrics
- Plain-English narrative insights
- Risk and exception identification
- Trends or comparisons
- Date controls
- Entity filters and search
- Sortable detail
- Drill-down
- Methodology
- Coverage period
- Generated timestamp
- Owner and contact
- Source lineage

Use progressive disclosure:
1. Executive insight
2. Summary metrics
3. Attention items
4. Supporting visuals
5. Detailed records

PHASE 5 — DASHBOARD QA AND CRITICAL FIXES
Perform and document data QA, functional QA, visual QA, and output QA.

Data QA must include record counts, duplicates, missing IDs, unmatched relationships, invalid dates and numbers, missing budgets and rates, date coverage, reconciliation, and unit conversions.

Functional QA must include uploads, file detection, filters, date changes and reversals, calculation-method switching, search, acronym matching, selection, empty states, preview, download, and regeneration.

Visual QA must include contrast, screen-share readability, mobile layout, overflow, long names, large values, table behavior, button visibility, states, form controls, touch targets, and reduced motion.

Output QA must confirm that the standalone file opens directly, has no missing dependencies or syntax errors, contains no broken controls, downloads the dashboard rather than the processor, and reports file size.

Automatically fix all major defects unless a fix changes an agreed business rule.

PHASE 6 — USER REVIEW
After QA, provide the working file, logic summary, assumptions, limitations, and proposed improvements. Ask only about unresolved business decisions or desired visual refinements.

PHASE 7 — PROCESSOR ENGINE
Build a separate reusable processor that:
- Accepts JSON and CSV
- Supports drag-and-drop
- Detects file types from structure
- Validates schemas
- Deduplicates records
- Maps relationships
- Surfaces unmatched and missing data
- Supports client, project, date, method, threshold, title, owner, and contact configuration
- Supports search, acronym matching, selection, preview, and download
- Includes instructions and validation summary
- Processes locally when practical
- Clearly distinguishes lifetime and selected-period calculations

The generated dashboard must be standalone, Vercel-ready as index.html, use relative paths, avoid raw source data and secrets, embed only required aggregates, remain compact, and work independently.

PHASE 8 — OUTPUT-SIZE OPTIMIZATION
Target:
- Preferred: under 1 MB
- Acceptable: under 3 MB
- Warn above 5 MB

Avoid raw-file embedding, base64 images, large libraries, unused code, and development logs. Reuse shared functions. Minify only after QA. Report final file size and explain excess size.

PHASE 9 — PROCESSOR QA
Test valid and invalid JSON/CSV, multiple monthly files, duplicates, missing budgets and rates, unknown IDs, empty files, bad rows, date changes and reversals, method changes, search, selection, preview, download, repeated generation, mobile layout, and standalone output.

PHASE 10 — FINAL DELIVERY
Do not declare completion until all of the following are delivered:
- Final dashboard HTML
- Final processor-engine HTML or Vercel-ready app
- Standalone generated dashboard
- README or operating instructions
- Versioned filenames
- Final file sizes
- Business-logic summary
- Assumptions
- Known limitations
- Recommended improvements
- Data QA summary
- Functional QA summary
- Visual QA summary
- Output QA summary
- Processor QA summary
- Changelog
- Recommended final version

DEPLOYMENT REQUIREMENTS
The app must work as index.html, use relative paths, avoid server requirements and secrets, include deployment instructions, explain authentication needs, and state that client-side password gates are not secure authentication.

LOW-CREDIT AND EFFICIENCY RULES
- Read each file once where possible
- Summarize schemas instead of printing records
- Avoid lengthy progress narration
- Patch safely instead of rewriting for minor changes
- Rebuild only for material architecture changes
- Create downloadable files instead of pasting long code
- Prefer compact vanilla HTML/CSS/JavaScript
- Avoid unnecessary assets and libraries
- Reuse shared functions
- Preserve working versions
- Batch related actions
- Ask only blocking questions
- Do not stop after a plan, prototype, or progress update
- Do not stop before QA is complete

COMMUNICATION STYLE
Be concise during execution. Use progress updates only when useful:
- Completed
- In progress
- Issues found
- Next action

A progress update must not interrupt continued execution. State assumptions clearly. Distinguish recommendations from confirmed rules. If a real limitation prevents completion, explain it precisely and complete all remaining feasible work.

START NOW
Begin by inspecting the uploaded JSON and CSV files. Produce a concise inventory, relationship map, data-quality findings, privacy findings, proposed business logic, and blocking questions. Then continue through dashboard creation, QA, processor development, optimization, and final delivery without stopping for nonblocking approvals.