Build a Complete Admin Foundation with Role-Based Access Control

You are updating an existing Base44 app.

Your task is to scan the current app structure, data models, pages, roles, routes, and workflows, then build a complete admin foundation into the existing app without breaking public or user-facing functionality.

GOAL

Create a secure, scalable admin system with role-based access control and an isolated admin experience.

WHAT TO DO

1. Scan the existing app first
- Review all current pages, layouts, entities, roles, navigation, and backend logic.
- Identify what admin-related functionality already exists.
- Reuse existing patterns where safe, but improve them where needed.
- Do not duplicate systems that already exist unless they are incomplete or insecure.

2. Create an admin foundation
Build a proper internal admin system that includes:
- Role-based admin access
- Separate admin dashboard
- Permission levels for: owner, admin, manager, support_staff
- Protected admin routes
- Internal notes on records
- Activity logs for admin actions

3. Role and permission system
Create a clear permission structure so each role only sees and does what they are allowed to.

- owner: full access to everything, manage roles and permissions, access all admin areas, logs, notes, settings, and records
- admin: manage most records and operational workflows, view logs, leave internal notes, cannot change owner-only controls unless explicitly allowed
- manager: manage day-to-day operational records, view limited dashboards and team-relevant records, leave internal notes, no access to sensitive settings or role management
- support_staff: limited access to support-related records only, can view assigned or approved records, can leave internal notes where allowed, no access to system settings, permission management, or sensitive admin controls

Implement this in a way that is easy to extend later.

4. Separate admin dashboard
- admin-only layout
- separate navigation/sidebar for admin
- dashboard summary cards
- recent activity area
- quick access to key record management sections
- clean operational layout focused on internal team use

5. Protected admin routes
- unauthorized users cannot access admin pages by URL
- users without sufficient permissions must be blocked from restricted sections
- show proper unauthorized/access denied states
- protect both frontend visibility and backend actions
- do not rely only on hiding buttons in the UI

6. Internal notes on records
- notes must be visible only to authorized staff
- notes must never appear on public or customer-facing views
- each note should store: content, related record, created by, created date/time, updated date/time if edited
- show notes in a clean admin-only panel inside record detail views

7. Activity logs
Track actions such as: record created, record updated, record status changed, internal note added, internal note edited, role changed, admin login or access event if supported, important operational actions taken by staff.

Each log should store: action type, user who performed it, target record or entity, timestamp, useful before/after detail where appropriate, optional metadata for troubleshooting.

Create a log viewer in the admin area with filtering by user, action type, date, and record/entity type.

8. UI requirements
- Keep the admin UI clean, simple, and professional
- Make permission-based visibility consistent across navigation, pages, actions, and data access
- Add badges, labels, or indicators for roles where useful
- Make record detail pages useful for staff by including notes, history, and operational context

9. Data and architecture requirements
- Use clean entity relationships
- Avoid hardcoding permissions in scattered places
- Centralize permission logic so it is easy to maintain
- Build in a way that supports future expansion such as more staff roles, more admin modules, approval workflows, audit history, staff assignment systems

10. Important rules
- Do not break existing user flows
- Do not remove existing functionality unless replacing it with a better version
- Do not expose internal notes or admin logs to non-admin users
- Do not assume current role logic is secure; verify and improve it
- If the app has no existing role system, create one properly
- If tables/entities are needed, create them
- If route guards, helpers, utilities, or permission wrappers are needed, create them
- If the admin dashboard needs its own layout and navigation, create them

DELIVERABLES
1. A summary of what was found in the existing app
2. What was created or improved
3. The roles and permissions structure
4. Which routes/pages were protected
5. Which entities/tables were added
6. What actions are now logged
7. Any assumptions made

FINAL QA REQUIREMENTS
Before finishing, perform 3 full rounds of checks:

Round 1: verify all admin routes are protected, verify role restrictions work correctly, verify unauthorized users cannot access admin data
Round 2: verify internal notes only appear for authorized staff, verify activity logs are being created correctly, verify dashboard and admin navigation behave correctly
Round 3: review for broken links, missing permissions, inconsistent role checks, and unsafe exposure of internal data, clean up UI issues, confirm the system is production-ready

Do not stop at partial setup. Fully implement the admin foundation into the existing Base44 app.