docs(phase-19): update tracking after wave 2 — phase complete

.planning/ROADMAP.md

@@ -334,7 +334,7 @@ and parse original-message evidence, classify each as `SPAM` / `UNWANTED` / `THR
 group duplicate reports into campaigns, and prepare (never auto-execute) remediation
 actions behind an explicit human-approval gate.
 
-Seven phases follow the domain's natural dependency chain rather than a generic
+Eight phases follow the domain's natural dependency chain rather than a generic
 foundation→features→polish template. Phase 15 lands the durable data model
 (campaigns/reports/messages/indicators/classifications/remediation_actions/
 audit_events, migration 097+) together with ticket detection and basic ticket-level
@@ -353,15 +353,21 @@ approval/audit) depends on campaigns existing (Phase 18) and classifications
 existing (Phase 19), since you can't approve or gate an action that doesn't
 reference either. Phase 21 (Autotask triage note) is last because its note content
 summarizes classification, blast radius, and recommended/approved remediation state
-— it has nothing to summarize until Phases 19 and 20 exist.
+— it has nothing to summarize until Phases 19 and 20 exist. Phase 22 (Approval UI)
+depends on the same Phase 19/20 outputs as Phase 21 but is otherwise independent of
+it — a LiveLink button in Autotask is a separate configuration surface from the
+triage note's content, so Phase 22 does not need Phase 21 to land first; it is
+sequenced last only because it is the newest addition to this milestone, not because
+of a functional dependency on Phase 21.
 
 - [x] **Phase 15: Data Model, Detection & Ticket Evidence** — New phishing schema (migration 097) + idempotent Autotask ticket scanner + base ticket evidence capture (completed 2026-07-15)
 - [x] **Phase 16: EML/MIME Evidence Parser** — Pure RFC822/MIME parser: `.eml` selection (`rfc.eml` over `OriginatingEmail.eml`), normalized headers/URLs/attachments, sanitized body preview, synthetic-fixture tests (completed 2026-07-15)
 - [x] **Phase 17: Mimecast Blast Radius Lookup** — Blast-radius abstraction with graceful `unavailable` degradation when Mimecast isn't configured (completed 2026-07-15)
 - [x] **Phase 18: Campaign Grouping & Phishing Analysis API** — Message-ID-first dedupe/grouping, on-demand single-ticket analysis, and the first `/api/phishing/*` routes with the ACCESS-01 auth convention (blocking gap CR-03 found via live verification 2026-07-16 — duplicate campaign on single-report re-analyze — see 18-VERIFICATION.md) (completed 2026-07-16)
-- [ ] **Phase 19: Classification Engine** — Deterministic SPAM/UNWANTED/THREAT rule classifier over bounded structured evidence, KnowBe4-simulation guard, (re-)trigger API
+- [x] **Phase 19: Classification Engine** — Deterministic SPAM/UNWANTED/THREAT rule classifier over bounded structured evidence, KnowBe4-simulation guard, (re-)trigger API (completed 2026-07-16)
 - [ ] **Phase 20: Remediation, Approval & Audit Safety** — Proposed-only remediation actions, approve/remediate/mark-false-positive APIs, idempotent re-run, full audit trail
 - [ ] **Phase 21: Autotask Triage Note** — Sanitized internal triage note posted via existing safe note-write path, or returned via API if no such path exists
+- [ ] **Phase 22: Approval UI (LiveLink)** — Ticket-ID-addressable Pulse page (Autotask LiveLink target) showing campaign timeline, evidence, and classification, with approve/remediate/mark-false-positive wired to the Phase 20 APIs
 
 ## Phase Details
 
@@ -436,7 +442,7 @@ summarizes classification, blast radius, and recommended/approved remediation st
   5. `POST /api/phishing/campaigns/{id}/classify` (re-)triggers classification, enforces the Phase 18 auth convention, and the classifier only ever receives structured, size-bounded evidence — long bodies are redacted/truncated before reaching any AI layer, and IT Glue-sourced evidence (if referenced) goes through the existing redacted `lib/services/analyzer/itglue-search.ts` path
 **Plans**: 2 plans (2 waves)
 - [x] 19-01-PLAN.md — campaign-classifier.ts deterministic rule engine (evidence gather + D-03/D-04/D-06 rules + D-05 confidence + D-08 actions + append-only INSERT) + vitest suite + synthetic KnowBe4/BSN fixtures (CLASSIFY-01, CLASSIFY-02, CLASSIFY-03, CLASSIFY-04, CLASSIFY-06)
-- [ ] 19-02-PLAN.md — POST /api/phishing/campaigns/[id]/classify route (requirePermission analyze + UUID guard + classifyCampaign delegation) (CLASSIFY-05)
+- [x] 19-02-PLAN.md — POST /api/phishing/campaigns/[id]/classify route (requirePermission analyze + UUID guard + classifyCampaign delegation) (CLASSIFY-05)
 **UI hint**: no
 
 ### Phase 20: Remediation, Approval & Audit Safety
@@ -466,7 +472,7 @@ summarizes classification, blast radius, and recommended/approved remediation st
 ## Progress
 
 **Execution Order:**
-Phases execute in numeric order. v1.0 (Phases 1-9.1) shipped 2026-07-10. v2.0 (Phases 10-14) shipped 2026-07-12. v3.0 phases run 15 → 16 → 17 → 18 → 19 → 20 → 21 in strict sequence — Phase 17 has no functional dependency on Phase 16 and could run in parallel with it if split across two workstreams, but both must complete before Phase 19.
+Phases execute in numeric order. v1.0 (Phases 1-9.1) shipped 2026-07-10. v2.0 (Phases 10-14) shipped 2026-07-12. v3.0 phases run 15 → 16 → 17 → 18 → 19 → 20 → 21 → 22 in strict sequence — Phase 17 has no functional dependency on Phase 16 and could run in parallel with it if split across two workstreams, but both must complete before Phase 19; Phase 22 depends only on Phase 19 and Phase 20 and could equally run in parallel with Phase 21.
 
 | Phase | Milestone | Plans Complete | Status | Completed |
 |-------|-----------|----------------|--------|-----------|
@@ -490,14 +496,29 @@ Phases execute in numeric order. v1.0 (Phases 1-9.1) shipped 2026-07-10. v2.0 (P
 | 16. EML/MIME Evidence Parser | v3.0 | 3/3 | Complete   | 2026-07-15 |
 | 17. Mimecast Blast Radius Lookup | v3.0 | 1/1 | Complete   | 2026-07-15 |
 | 18. Campaign Grouping & Phishing Analysis API | v3.0 | 5/5 | Complete    | 2026-07-16 |
-| 19. Classification Engine | v3.0 | 1/2 | In Progress|  |
+| 19. Classification Engine | v3.0 | 2/2 | Complete   | 2026-07-16 |
 | 20. Remediation, Approval & Audit Safety | v3.0 | 0/TBD | Not started | - |
 | 21. Autotask Triage Note | v3.0 | 0/TBD | Not started | - |
+| 22. Approval UI (LiveLink) | v3.0 | 0/TBD | Not started | - |
+
+### Phase 22: Approval UI (LiveLink)
+**Goal**: A security operator opens an Autotask ticket, clicks a LiveLink button, and lands on a Pulse page scoped to that ticket showing the campaign's timeline, evidence, and classification — with approve/remediate/mark-false-positive actions right there, so no one is calling the Phase 20 APIs by hand.
+**Depends on**: Phase 19 (classification + recommended action to display), Phase 20 (approve/remediate/mark-false-positive APIs the page calls)
+**Requirements**: REVIEW-01, REVIEW-02, REVIEW-03, REVIEW-04, REVIEW-05, REVIEW-06
+**Success Criteria** (what must be TRUE):
+  1. A stable, ticket-ID-addressable Pulse route (e.g. `/phishing/tickets/{ticketId}`) resolves the ticket to its campaign and renders that campaign's review page — suitable as an Autotask LiveLink target (LiveLink supplies the ticket ID as dynamic content; it does not know the internal campaign UUID), using the existing Better Auth session with no separate token/query-param auth
+  2. The page shows the campaign's timeline — linked reports, classification history, and audit events (classify/approve/remediate/mark-false-positive) — in chronological order
+  3. The page shows the gathered evidence — parsed EML headers/URLs/attachments (Phase 16), sanitized body preview, and Mimecast blast-radius data (Phase 17, including an explicit `unavailable` state when Mimecast isn't configured) — never rendering a raw/unsanitized body or unredacted secrets
+  4. The page shows the current classification (SPAM/UNWANTED/THREAT), confidence, reasons, and recommended remediation action(s) from Phase 19
+  5. Approve, remediate, and mark-false-positive buttons call the Phase 20 APIs directly from the page and reflect the resulting state (e.g. a remediated campaign shows as remediated, not re-offered for approval)
+  6. An operator without the elevated permission REMED-02/ACCESS-01 already require sees the approve/remediate actions disabled or hidden rather than a failed request; the page never uses a relaxed or separate permission check from the underlying APIs
+**Plans**: TBD
+**UI hint**: yes
 
 ---
 *Roadmap created: 2026-05-03*
 *v2.0 phases added: 2026-07-10*
-*v3.0 phases added: 2026-07-14*
+*v3.0 phases added: 2026-07-14 (Phases 15-21), 2026-07-16 (Phase 22)*
 *Source spec (v1.0): `docs/superpowers/specs/2026-05-03-mobile-shell-design.md`*
 *Source seed (v2.0): `.planning/seeds/SEED-002-pax8-integration.md`*
 *Source requirements (v3.0): `.planning/REQUIREMENTS.md`*

.planning/STATE.md

@@ -91,6 +91,14 @@ Recent decisions affecting current work:
   classification + blast radius + recommended/approved remediation state,
   so it has nothing to summarize until Phases 19-20 exist
 
+### Roadmap Evolution
+
+- Phase 22 added: Approval UI (LiveLink) — ticket-ID-addressable Pulse page
+  (Autotask LiveLink target) showing campaign timeline, evidence, and
+  classification, with approve/remediate/mark-false-positive wired to the
+  Phase 20 APIs. Depends on Phase 19 + Phase 20 only; not functionally
+  dependent on Phase 21 despite being numbered after it.
+
 ### Pending Todos
 
 None yet.