# Incremental Tasks (Summarize + Skeletons + Notifications)

## Design Notes
- Reuse existing green brand `#0b6e3e`.
- Skeletons: Tailwind `animate-pulse` with subtle shimmer gradient.
- AI model: `gemini-2.5-pro`.

## WHMCS Multi-Section Load Failure — Diagnostic (added)
The WHMCS API identifier/secret were rotated by the admin (stored in Atoms Cloud
secrets: `WHMCS_API_URL`, `WHMCS_API_IDENTIFIER`, `WHMCS_API_SECRET`). When
services / invoices / domains / tickets / emails all fail simultaneously the
root cause is almost always the **API Role** attached to the identifier:
specific actions (`GetClientsProducts`, `GetInvoices`, `GetClientsDomains`,
`GetTickets`, `GetEmails`) are not enabled on that role.

A new diagnostic has been added to pinpoint this:
- Backend: `GET /api/v1/whmcs/admin/system/actions-health?test_email=<email>`
  probes every action the dashboard uses and returns a per-action
  pass/fail / http status / whmcs-result / message row.
- Frontend: /admin/cms/whmcs-logs → "Per-action diagnostic" card with a
  "Probe all actions" button and optional test-client email input.
- `.env.example` documents the full list of required API Role permissions.

How to resolve a reported failure:
1. Update the rotated credentials in Atoms Cloud secrets.
2. Open `/admin/cms/whmcs-logs` → run "Probe all actions" (optionally with the
   affected user's email). Any row showing `fail` tells you the exact WHMCS
   action name and the permission you need to enable.
3. In WHMCS admin → Setup → Staff Management → API Roles → edit the role
   attached to the identifier → tick the missing actions → Save.
4. Re-run the probe — all rows should turn green.

## Development Tasks
- [x] F1 Backend: Create `ticket_summaries` entity via BackendManager.create_tables
- [x] F1 Backend: Add `/api/v1/ai/summarize-ticket` custom router (loads ticket via WHMCS connector, checks cache, calls AIHubService.gentxt, persists summary)
- [x] F1 Frontend: Add "Summarize thread" button + summary card in `Tickets.tsx` (visible when ≥ 2 messages)
- [x] F2 Frontend: Create `src/components/ui/Skeleton.tsx` primitive + compositions `DashboardSkeleton`, `TicketsSkeleton`, `TicketDetailSkeleton`
- [ ] F2 Frontend: Wire skeletons into `ClientDashboard.tsx` and `Tickets.tsx` replacing spinners (deferred - current spinners remain functional)
- [x] F3 Backend: Create `notifications`, `notification_preferences`, `ticket_sync_state` entities
- [x] F3 Backend: Add `/api/v1/notifications/sync-ticket-events` router that diffs WHMCS snapshot and inserts notifications
- [x] F3 Frontend: NotificationBell component in dashboard header with unread badge + dropdown
- [ ] F3 Frontend: `/dashboard/notifications` full page with filter (deferred - bell dropdown covers MVP)
- [ ] F3 Frontend: `/dashboard/settings/notifications` preferences page (deferred)
- [x] F3 Frontend: Poll sync endpoint on dashboard mount + every 45s (via NotificationBell)
- [x] Lint + build final checks
- [x] Changelog entry

## Changelog
- Add AI thread summarization (with caching) in Tickets page.
- Add persistent ticket notifications with NotificationBell dropdown in dashboard header.
- Server-side sync diff's WHMCS activity into `notifications` table on bell open + poll.

## WHMCS Admin Folder Note
- **Production WHMCS admin folder is renamed to `/_admin_/`** (not the default `/admin/`).
  Full admin URL: `https://client.doiteasy.net/_admin_/`.
- WHMCS **REST API** calls go to `/includes/api.php` and are **unaffected** by the admin path.
- Backend exposes `WHMCS_ADMIN_PATH` env var (default `_admin_`) and a
  `build_admin_url(path)` helper in `backend/services/whmcs.py`. Use it for any
  future admin deep-links (e.g. "Open ticket in WHMCS admin"). Do NOT hardcode `/admin/`.
- `.env.example` at project root documents `WHMCS_API_URL`, `WHMCS_API_IDENTIFIER`,
  `WHMCS_API_SECRET`, and `WHMCS_ADMIN_PATH` so future deployments don't regress.