support_frontend/specs/001-agent-admin-ui/tasks-p2-p3.md

---
description: "Task list for 001-agent-admin-ui, continuation: User Stories 4-7 (P2/P3)"
---

# Tasks: Agent and Admin UI — User Stories 4-7

**Input**: Design documents from `specs/001-agent-admin-ui/` (plan.md, spec.md, research.md,
data-model.md — extended with US4-7 entities, contracts/api-client-contract.md — extended with
US4-7 functions, quickstart.md)

**Prerequisites**: `tasks.md` (Setup + Foundational + User Stories 0-3) already complete. This
continuation needs no new Foundational work — every US4-7 story follows the identical `lib/api`
function → TanStack Query hook → `features/*` component → page pattern already established.

**Backend dependency**: 012-admin-list-views (supporthub-api) — SLA-run/escalation-event/
product-catalog list endpoints, plus its own follow-up commit adding the knowledge-governance
list endpoint. Both already merged into this feature's own contracts before these tasks began.

## Format: `[ID] [P?] [Story] Description`

All file paths are relative to `supporthub-web/` (repo root).

---

## Phase 5: User Story 4 - SLA policies and business calendars (Priority: P2)

**Independent Test**: Quickstart Scenario 4 (see quickstart.md addendum below).

- [x] T042 [P] [US4] Add `lib/api/sla.ts` (`listSlaPolicies`, `createSlaPolicy`) and
      `lib/api/calendars.ts` (`listCalendars`, `createCalendar`, `addHoliday`) per
      contracts/api-client-contract.md
- [x] T043 [US4] Add `lib/api/types/sla.ts` (`SlaPolicy`, `BusinessCalendar`,
      `BusinessCalendarHoliday` — data-model.md) and export from `lib/api/types/index.ts`
- [x] T044 [US4] Add `features/settings/calendar-editor.tsx` (create a calendar with per-weekday
      working hours + add a holiday, US4 scenario 1) (depends on T042, T043)
- [x] T045 [US4] Add `features/settings/sla-policy-editor.tsx` (create a policy scoped to a
      product/category/priority with a calendar reference; each row in the list badges its own
      specificity — which optional scope fields are set — per contracts/api-client-
      contract.md's own note, US4 scenarios 2-3) (depends on T042, T043)
- [x] T046 [US4] Replace the placeholder `src/app/(admin)/admin/sla-policies/page.tsx` composing
      T044+T045 (both calendars and SLA policies live here — Key Entities' own "SLA & Calendar
      Configuration" grouping) (depends on T044, T045)
- [x] T047 [US4] Integration test (mocked `lib/api/sla.ts`/`lib/api/calendars.ts`) covering
      Quickstart Scenario 4 in `tests/integration/settings/sla-calendar-admin.test.tsx`
- [x] T048 [US4] Run Quickstart Scenario 4 locally against a real supporthub-api and confirm it
      passes

---

## Phase 6: User Story 5 - Escalation policies and rules (Priority: P2)

**Independent Test**: Quickstart Scenario 5.

- [x] T049 [P] [US5] Add `lib/api/escalation.ts` (`listEscalationPolicies`,
      `createEscalationPolicy`, `createEscalationRule`) per contracts/api-client-contract.md
- [x] T050 [US5] Add `lib/api/types/escalation.ts` (`EscalationPolicy`, `EscalationRule`,
      `ESCALATION_TRIGGER_TYPES` — data-model.md) and export from `lib/api/types/index.ts`
- [x] T051 [US5] Add `features/escalation/escalation-policy-editor.tsx` (create a policy, add a
      rule with trigger type + target node, both clearly shown in the list, US5 scenario 1)
      (depends on T049, T050)
- [x] T052 [US5] Replace the placeholder `src/app/(admin)/admin/escalation-policies/page.tsx`
      with T051 (depends on T051)
- [x] T053 [US5] Integration test (mocked `lib/api/escalation.ts`) covering Quickstart Scenario
      5's policy/rule creation, plus a stale-`targetNodeId` manual escalation from the ticket
      workbench (already-built `TicketHeader`, US5 scenario 3) rendering the backend's own
      rejection, in `tests/integration/escalation/escalation-admin.test.tsx`
- [x] T054 [US5] Run Quickstart Scenario 5 locally against a real supporthub-api and confirm it
      passes, including a manual escalation from a real ticket appearing in that ticket's own
      history (scenario 2)

---

## Phase 7: User Story 6 - SLA and escalation monitoring views (Priority: P2)

**Independent Test**: Quickstart Scenario 6.

- [x] T055 [P] [US6] Add `lib/api/monitoring.ts` (`listSlaRuns`, `listEscalationEvents`) per
      contracts/api-client-contract.md (012-admin-list-views)
- [x] T056 [US6] Add `features/reports/sla-monitor.tsx` (every SLA run, filterable by status,
      each row linking to its ticket via `ticketCode`/`ticketId`, US6 scenario 1) (depends on
      T055)
- [x] T057 [US6] Add `features/reports/escalation-matrix.tsx` (recent escalation events, each
      showing reason + rule-or-actor + target node, US6 scenario 2) (depends on T055)
- [x] T058 [US6] Replace the placeholder `src/app/(admin)/admin/reports/page.tsx` composing
      T056+T057 (depends on T056, T057)
- [x] T059 [US6] Integration test (mocked `lib/api/monitoring.ts`) covering Quickstart Scenario
      6 (status filter, automatic-vs-manual distinction) in
      `tests/integration/reports/monitoring-views.test.tsx`
- [x] T060 [US6] Run Quickstart Scenario 6 locally against a real supporthub-api and confirm it
      passes, using real SLA runs/escalation events from earlier stories' own test data

---

## Phase 8: User Story 7 - Product catalog and knowledge base governance (Priority: P3)

**Independent Test**: Quickstart Scenario 7.

- [x] T061 [P] [US7] Add `lib/api/catalog.ts` (`listProductCatalog`) and `lib/api/knowledge.ts`
      (`listKnowledgeEntries`, `publishKnowledgeEntry`, `unpublishKnowledgeEntry`) per
      contracts/api-client-contract.md
- [x] T062 [US7] Add `lib/api/types/catalog.ts`/`lib/api/types/knowledge.ts` (data-model.md) and
      export from `lib/api/types/index.ts`
- [x] T063 [US7] Add `features/products/product-catalog.tsx` (each product's integration status
      visible, US7 scenario 1) (depends on T061, T062)
- [x] T064 [US7] Add `features/knowledge/knowledge-governance.tsx` (list entries for a selected
      product including drafts, publish/unpublish action, status update reflected immediately,
      US7 scenario 2) (depends on T061, T062)
- [x] T065 [US7] Replace the placeholder `src/app/(admin)/admin/products/page.tsx` with T063 and
      `src/app/(admin)/admin/knowledge/page.tsx` with T064 (depends on T063, T064)
- [x] T066 [US7] Integration test (mocked `lib/api/catalog.ts`/`lib/api/knowledge.ts`) covering
      Quickstart Scenario 7 in `tests/integration/products/catalog-and-knowledge.test.tsx`
- [x] T067 [US7] Run Quickstart Scenario 7 locally against a real supporthub-api and confirm it
      passes

---

## Phase 9: Polish & Cross-Cutting Concerns (this continuation's own)

- [x] T068 [P] Update `specs/001-agent-admin-ui/checklists/requirements.md` Notes with any
      implementation-time findings from User Stories 4-7
- [x] T069 Run `npm run typecheck` and `npm run lint`
- [x] T070 Run `npm run test` (all unit + integration) and confirm Setup/US0-3's own tests still
      pass (no regression from US4-7's additions)
- [x] T071 Real end-to-end verification: run the app against a live, locally-running
      supporthub-api and manually (or via a Playwright addition) confirm all four of this
      continuation's Quickstart scenarios, matching Setup/US0-3's own established discipline of
      never claiming a scenario done without exercising it against real infrastructure

---

## Dependencies & Execution Order

- **User Stories 4-7 (Phases 5-8)**: Each depends only on User Story 0 (a session) — independent
  of each other and of Phases 5-8's own siblings, parallelizable in any order (matches the
  original tasks.md's own US1-3 independence)
- **Polish (Phase 9)**: Depends on all four

## Quickstart Addenda (this continuation's own scenarios)

**Scenario 4 — SLA policies and business calendars**: Create a business calendar with working
hours and a holiday; create an SLA policy referencing it, scoped to a product. Confirm both
retrievable/editable exactly as configured, and that a second, more general policy is visibly
marked less specific than a product-scoped one.

**Scenario 5 — escalation policies and rules**: Create an escalation policy and a
`resolution_breach` rule targeting a specific node. Confirm it's retrievable. From an existing
ticket's workbench, manually escalate to that node with a reason; confirm the escalation appears
in that ticket's own history. Attempt escalating to a nonexistent node; confirm the rejection is
shown clearly.

**Scenario 6 — SLA and escalation monitoring**: With SLA runs in different states and a recent
escalation event, open the SLA monitor and filter by status; open the escalation matrix and
confirm the triggering reason/rule-or-actor/target node are all shown.

**Scenario 7 — catalog and knowledge governance**: View the product list with integration
status visible. Open the knowledge governance screen for a product, publish a draft entry,
confirm its status updates immediately.