Presentation-only UI over the already-complete 015-reporting-dashboards backend:
four new dashboards (Management, Product, Support, AI) wired into a tabbed
Analytics & Reports page alongside the existing SLA Monitor/Escalation Matrix
views, plus the new stat-tile/ranked-bar-list/status-distribution/meter
primitives they share.
Applies the dataviz skill's methodology throughout (form before color, status
colors reserved and always paired with an icon + label, validated against
both light and dark mode) and fixes a real mobile overflow bug in the Tabs
primitive found via screenshot review, not just accessibility-tree checks.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Four new dataviz-informed UI primitives (stat tile, ranked bar list,
status distribution, meter) shared across all four dashboards, no new
charting dependency. 24 tasks across a shared Foundational phase and
4 independently-testable dashboard user stories.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Presentation-only follow-on to supporthub-api's already-complete
015-reporting-dashboards, per the same backend-first pattern used
throughout this session. Plan applies the dataviz skill methodology
given the user's explicit request for production-level design.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completes this feature's full P2/P3 scope, backed by supporthub-api's
012-admin-list-views feature. SLA & Calendar Configuration (US4) covers
business calendars with per-weekday working hours and holidays, and SLA
policies with a specificity indicator (which optional scope fields are
set) - never re-deriving the backend's own most-specific-match
resolution. Escalation Configuration (US5) covers policies and rules
(trigger type + target node). Monitoring Views (US6) covers a
filterable SLA run list and an escalation matrix, both linking back to
their tickets. Catalog & Knowledge Governance (US7) covers the product
catalog with integration status and publish/unpublish for knowledge
entries, including drafts (which the AI-consumption-only /knowledge/
retrieve endpoint can't show).
Fixed a real bug caught only by submitting a form against a live
backend: the calendar editor's default timezone ("UTC") isn't a valid
value under Intl.supportedValuesOf('timeZone'), which supporthub-api
validates against - no mocked test exercises that validation.
Verified with 3 additional real Playwright E2E scenarios against a
live, locally-running supporthub-api (creating a real calendar/holiday/
SLA-policy, a real escalation policy/rule targeting a real hierarchy
node, and reading the real product catalog), for 11 total across this
feature, plus 26 unit/integration tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backed by supporthub-api's new 012-admin-list-views feature (SLA-run,
escalation-event, product-catalog, and knowledge-governance list
endpoints) - the same lib/api function -> TanStack Query hook ->
features/* component -> page pattern established for User Stories 0-3
applies directly, so no new Foundational work or fresh research
decisions are needed for this continuation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completes this feature's P1 MVP scope. Agent dashboard (US1) consumes
011-agent-ticket-queue's new endpoint with a distinct "no agent profile
linked" state, never conflated with a genuine empty list. Ticket
workbench (US2) covers messages (customer-visible vs internal notes),
status transitions, manual escalation, and the full investigation ->
root-cause -> solution -> implementation -> verification -> resolution
workflow, every stage surfacing the backend's own 409/400 rejection
verbatim rather than pre-validating order client-side. Support-org admin
(US3) covers team/agent/skill CRUD, linking an agent's account (011's
new PATCH field), and a hierarchy-node editor with real cycle-detection
error surfacing.
Two real backend-contract mismatches caught and fixed before shipping,
found by re-verifying schemas directly against the actual branch after
an isolated research agent (run in a worktree based on stale main,
missing the unmerged 009-problem-resolution branch) reported wrong
information: getTicketMessages was hitting the customer-safe endpoint
instead of the agent-facing one that includes internal notes, and
postMessage's body shape didn't match the real {type, body} schema.
Verified with 8 real Playwright E2E scenarios against a live, locally-
running supporthub-api (not mocks), plus 18 unit/integration tests.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Configures both previously-empty test runners (vitest.config.ts,
playwright.config.ts) and adds the typed lib/api client layer (axios +
interceptors), the session-cookie plumbing (lib/auth), TanStack Query
infrastructure (lib/query, providers), and a real sign-in flow consuming
supporthub-api's own login (010-identity-auth) - the true foundation
every other user story in this feature depends on.
Two structural fixes to the existing scaffold, both found only by
running the app rather than by inspection: middleware.ts belongs at
src/middleware.ts under this project's src/ layout, not the repo root;
and next.config.mjs's output:'export' is incompatible with Next.js
Middleware outright (the dev server refuses to start it), so this app
now runs as a standard Next.js server - confirmed with the user before
making that deployment-mode change.
Verified end-to-end with a real, locally-running supporthub-api: all 5
Playwright scenarios (unauthenticated redirect, sign-in, wrong-password
generic error, non-admin role gating, sign-out) pass against a live
backend, not a mock.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Scopes this plan's immediate implementation target to Setup + User
Stories 0-3 (sign-in, agent dashboard, ticket workbench, support-org
admin) - the P1 MVP - given the feature's overall size (8 user stories
against a fully empty lib/api, lib/auth, lib/query, and empty test
configs). Key decisions: session token in a plain cookie (readable by
both Next.js middleware and client-side axios, since supporthub-api only
reads a Bearer header, never a cookie), middleware does a cheap
unverified presence/role check for UX redirects only - the real gate
stays supporthub-api's own token verification - and lib/api is the one
typed client layer per Constitution Principle IV.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
supporthub-api's 010-identity-auth (built after this spec's initial approval)
established that agent/admin login is supporthub-api's own authentication,
never SaaS-delegated — this spec and the project constitution's Principle I
still assumed the opposite. Adds User Story 0 (sign-in, P1) and FR-000/SC-006
for the login screen and session-guard this frontend must now own, and
rewords FR-011/the affected Edge Case to reference the supporthub-api
session role instead of a "SaaS-provided role." Only end-customer identity
remains SaaS-delegated.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Scopes supporthub-api's Phase 10 roadmap line ("Agent workspace...
admin configuration surfaces for every configurable subsystem above")
into this project's own first feature: the agent ticket workbench and
problem-resolution workflow, plus admin configuration for support
organization, SLA/business-calendars, and escalation -- the subsystems
an agent's own day-to-day work most directly depends on.
Deliberately defers the (public)/(customer) portals, real-time push
sync, analytics/reporting, audit-log viewing, platform settings, and
AI-confidence-policy administration to a follow-up feature, each
flagged explicitly in Assumptions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bootstraps GitHub Spec Kit (scripts, templates, workflow, speckit-*
skills) for this frontend project, mirroring the spec-driven workflow
already used in supporthub-api. Ratifies seven founding principles:
SaaS as the sole identity/access authority, the backend as the sole
source of business logic, strict portal boundaries ((public)/(customer)/
(support)/(admin)), a single typed API client layer (no ad hoc fetching),
configuration over hardcoding for anything the backend exposes as
admin-configurable, an accessible/responsive baseline for an
enterprise all-day tool, and required unit/integration/E2E testing
gates.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
saqib mir
maskantech