Build an Admin Reporting & Visibility System

Scan my entire app first so you fully understand how it currently works before making changes.

Audit existing app structure, pages, entities, data models, roles, backend functions, automations, navigation, admin area so you can integrate the following cleanly without breaking anything.

GOAL: Add a Reporting and Visibility section to admin that gives staff clear operational insight across support, feedback, clients, and system issues.

FIRST
1. Scan full app structure.
2. Identify all existing entities, relationships, backend functions, automations, forms, status fields, admin pages.
3. Find current systems for: support tickets, user feedback, client records, error logs, staff assignments, task tracking, internal operations.
4. Reuse existing tables, fields, components, logic wherever possible.
5. Only create new when truly needed.

REPORTING AND VISIBILITY REQUIREMENTS

1. OPEN SUPPORT TICKETS DASHBOARD
Total open, by priority, by status, overdue/aging, newly created, awaiting staff response, awaiting client response.

2. UNRESOLVED FEEDBACK DASHBOARD
Total unresolved, by status, by category, by priority, waiting for review, planned but not started, currently in progress.

3. ACTIVE CLIENTS DASHBOARD
Total active, status breakdown, recently onboarded, needing follow-up, with unresolved issues, with recent support activity, with no recent activity for health tracking.

4. ERROR TRENDS OVER TIME
Errors by day/week/month, by severity, by type, recurring errors, unresolved critical, trend direction vs prior period. Use existing error logs if available.

5. USER ISSUE TRENDS
Most common ticket categories, bug report categories, complaint types, issue volume over time, repeat issues from same users/accounts, trends by segment/plan/user type if data exists.

6. MOST REQUESTED FEATURES
Feature requests by count, by status, grouped duplicates, over time, high-demand from active/high-value clients.

7. STAFF WORKLOAD VIEW
Tickets/feedback assigned per staff, overdue by staff, avg response time by staff, avg resolution time by staff, open workload count per staff, unassigned work.

8. CLIENT HEALTH OVERVIEW
Use signals: unresolved support issues, unresolved feedback, recent errors affecting client, activity level, onboarding completion, follow-up status, last contact date, renewal risk. Labels: healthy, needs attention, at risk. If data doesn't support, create structure for manual management with room for automation later.

9. OPERATIONAL BOTTLENECK REPORTING
Tickets in one status too long, feedback stuck in review/planning, too many unassigned, overloaded queues, recurring unresolved errors, client issues taking too long to close, workflow step delays.

BUILD REQUIREMENTS
- Add inside existing admin area or create clean Reporting/Insights section
- Consistent design, protected for authorized roles, respect existing permissions
- Charts, summary cards, filters, tables where appropriate
- Filters for date range/status/priority/category/staff/client
- Useful, readable, actionable
- Empty states where no data yet
- Don't break existing workflows

DATA AND LOGIC
- Reuse existing statuses/priorities/categories
- If required fields missing, add carefully and wire to current workflows
- Calculate metrics only where data supports them
- If reporting can't be automated because tracking doesn't exist: explain gap, add missing structure, wire future-ready tracking

DELIVERABLES (before coding)
1. Short summary of how the app currently works
2. Entities/fields/workflows found relating to this request
3. What can be reused
4. What needs to be created
5. Implementation plan

Then implement.

RULES: Don't guess blindly. No duplicate systems. Don't overwrite without reason. Modular and scalable. Real app data, not fake placeholders (label sample data clearly if absolutely needed).

FINAL: list of everything added, new entities/fields, backend functions, admin pages/components, permissions/protected routes, limitations/recommended next improvements.