saqib mirandClaude Sonnet 5
95b5a1e03d
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>
4.3 KiB
4.3 KiB
Specification Quality Checklist: Agent and Admin UI
Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-09-07 Feature: spec.md
Content Quality
- No implementation details (languages, frameworks, APIs)
- Focused on user value and business needs
- Written for non-technical stakeholders
- All mandatory sections completed
Requirement Completeness
- No [NEEDS CLARIFICATION] markers remain
- Requirements are testable and unambiguous
- Success criteria are measurable
- Success criteria are technology-agnostic (no implementation details)
- All acceptance scenarios are defined
- Edge cases are identified
- Scope is clearly bounded
- Dependencies and assumptions identified
Feature Readiness
- All functional requirements have clear acceptance criteria
- User scenarios cover primary flows
- Feature meets measurable outcomes defined in Success Criteria
- No implementation details leak into specification
Notes
- Scope is Phase 10 per supporthub-api's
docs/10-implementation-roadmap.md, translated into this project's own first feature: the agent workspace and the admin configuration surfaces for support organization, SLA/business-calendars, and escalation — the subsystems an agent's own day-to-day workflow (User Stories 1-2) most directly depends on existing and being configurable first. - Deliberately excludes the
(public)/(customer)portals, real-time push sync, analytics/ reporting, audit-log viewing, platform settings, and AI-confidence-policy administration — each flagged explicitly in Assumptions as follow-up scope, not an oversight, to keep this first feature reviewable rather than attempting all of Phase 10's roadmap line in one spec. - FR-012 and Edge Cases both restate this project's own Constitution Principle II (the backend is the sole source of business logic) as testable requirements, not just governance — every acceptance scenario that touches a business-rule rejection (US2 scenario 2, US3 scenario 3, US5 scenario 3) exists specifically to keep that principle enforced, not merely aspirational.
- All items pass; no revision iterations were needed.
- Post-approval amendment: this spec originally assumed agent/admin identity arrived the same pre-authenticated way customer identity does (delegated from the parent SaaS host), with no frontend-owned login screen needed — FR-011 and an Edge Case both said "SaaS-provided role." supporthub-api's 010-identity-auth (built after this spec's initial approval) established that agent/admin login is supporthub-api's own, separate authentication, never SaaS-delegated — the same correction already made to both projects' constitutions. Added User Story 0 (sign-in, P1, more foundational than US1), FR-000, SC-006, a new Edge Case, and reworded FR-011/the existing Edge Case/the closing Assumption to say "supporthub-api session role" instead of "SaaS-provided role." This is a correction of a wrong premise, not new scope creep — nothing else in User Stories 1-7 changes.
- Implementation-time finding: two structural issues with this project's existing scaffold
only surfaced by actually running the app, not by inspection — (1) with this project's
src/directory layout, Next.js requiresmiddleware.tsto live atsrc/middleware.ts, not the repo root; the pre-existing emptymiddleware.tshad been scaffolded in the wrong location. (2)next.config.mjs'soutput: 'export'(static HTML export) is fundamentally incompatible with Next.js Middleware — the dev server refused to run it outright. Removing static export is a deployment-mode change (this app now needsnext build && next start, not a static file host), flagged to and confirmed by the user before making it, since it has real infrastructure implications beyond this feature's own code. - A second discovered blocker, upstream of this feature entirely: supporthub-api had no endpoint to list "tickets currently assigned to agent X" at all, and no way to resolve a logged-in session to its own agent roster row — User Story 1 had no data source without it. Resolved by a new supporthub-api feature, 011-agent-ticket-queue, built and merged into this feature's own data-model.md/contracts before Setup began.