docs: create milestone v3.0 roadmap (7 phases)

.planning/REQUIREMENTS.md

@@ -149,38 +149,39 @@ Populated during roadmap creation.
 
 | Requirement | Phase | Status |
 |-------------|-------|--------|
-| DETECT-01 | TBD | Pending |
-| DETECT-02 | TBD | Pending |
-| DETECT-03 | TBD | Pending |
-| EVID-01 | TBD | Pending |
-| EVID-02 | TBD | Pending |
-| EVID-03 | TBD | Pending |
-| EVID-04 | TBD | Pending |
-| CAMP-01 | TBD | Pending |
-| CAMP-02 | TBD | Pending |
-| CAMP-03 | TBD | Pending |
-| BLAST-01 | TBD | Pending |
-| BLAST-02 | TBD | Pending |
-| CLASSIFY-01 | TBD | Pending |
-| CLASSIFY-02 | TBD | Pending |
-| CLASSIFY-03 | TBD | Pending |
-| CLASSIFY-04 | TBD | Pending |
-| CLASSIFY-05 | TBD | Pending |
-| CLASSIFY-06 | TBD | Pending |
-| REMED-01 | TBD | Pending |
-| REMED-02 | TBD | Pending |
-| REMED-03 | TBD | Pending |
-| REMED-04 | TBD | Pending |
-| REMED-05 | TBD | Pending |
-| REMED-06 | TBD | Pending |
-| NOTE-01 | TBD | Pending |
-| ACCESS-01 | TBD | Pending |
+| DETECT-01 | Phase 15 | Pending |
+| DETECT-02 | Phase 15 | Pending |
+| DETECT-03 | Phase 18 | Pending |
+| EVID-01 | Phase 15 | Pending |
+| EVID-02 | Phase 16 | Pending |
+| EVID-03 | Phase 16 | Pending |
+| EVID-04 | Phase 16 | Pending |
+| CAMP-01 | Phase 18 | Pending |
+| CAMP-02 | Phase 18 | Pending |
+| CAMP-03 | Phase 18 | Pending |
+| BLAST-01 | Phase 17 | Pending |
+| BLAST-02 | Phase 17 | Pending |
+| CLASSIFY-01 | Phase 19 | Pending |
+| CLASSIFY-02 | Phase 19 | Pending |
+| CLASSIFY-03 | Phase 19 | Pending |
+| CLASSIFY-04 | Phase 19 | Pending |
+| CLASSIFY-05 | Phase 19 | Pending |
+| CLASSIFY-06 | Phase 19 | Pending |
+| REMED-01 | Phase 20 | Pending |
+| REMED-02 | Phase 20 | Pending |
+| REMED-03 | Phase 20 | Pending |
+| REMED-04 | Phase 20 | Pending |
+| REMED-05 | Phase 20 | Pending |
+| REMED-06 | Phase 20 | Pending |
+| NOTE-01 | Phase 21 | Pending |
+| ACCESS-01 | Phase 18 | Pending |
 
 **Coverage:**
 - v1 requirements: 26 total
-- Mapped to phases: 0 (pending roadmap)
-- Unmapped: 26 ⚠️ (resolved by roadmapper)
+- Mapped to phases: 26 (Phases 15-21)
+- Unmapped: 0 ✓
 
 ---
 *Requirements defined: 2026-07-14*
+*Traceability populated: 2026-07-14 — ROADMAP.md Phases 15-21*
 *Last updated: 2026-07-14 after initial definition*

.planning/ROADMAP.md

@@ -3,7 +3,8 @@
 ## Milestones
 
 - ✅ **v1.0 Mobile Shell Redesign** — Phases 1-9.1 (shipped 2026-07-10)
-- 📋 **v2.0 PAX8 Integration** — Phases 10-14 (planned)
+- ✅ **v2.0 PAX8 Integration** — Phases 10-14 (shipped 2026-07-12)
+- 🚧 **v3.0 Phishing Triage Automation** — Phases 15-21 (in progress)
 
 ## Phases
 
@@ -218,7 +219,8 @@ under `/mobile/*` — no `/mobile-v2`, no parallel routes.
 
 </details>
 
-### 📋 v2.0 PAX8 Integration (Planned)
+<details>
+<summary>✅ v2.0 PAX8 Integration (Phases 10-14) - SHIPPED 2026-07-12</summary>
 
 **Milestone Goal:** Sync PAX8 licensing/subscription data into Pulse, read-only,
 mapped to Autotask companies, so managers can see subscription costs and seat
@@ -241,9 +243,7 @@ render, including the manual-resolution workflow for flagged companies.
 - [x] **Phase 11: Company, Catalog & Subscription Sync** — Read-only sync of current-state companies, product catalog, and subscriptions into Postgres (completed 2026-07-11)
 - [x] **Phase 12: Orders/Invoices & Company Matching** — Historical cost sync plus fuzzy-name auto-matching (with flagging) of PAX8 companies to Autotask companies (completed 2026-07-11)
 - [x] **Phase 13: Scheduler & Admin Toggle** — Daily `pax8-daily` cron entry and an on/off switch in `/admin/integrations` (completed 2026-07-11)
-- [x] **Phase 14: /pax8 UI Surface** — New page listing companies/subscriptions/cost breakdown, plus manual resolution of flagged company matches (completed 2026-07-11)
-
-## Phase Details
+- [x] **Phase 14: /pax8 UI Surface** — New page listing companies/subscriptions/cost breakdown, plus manual resolution of flagged company matches (completed 2026-07-12)
 
 ### Phase 10: PAX8 Client & Auth Foundation
 **Goal**: Pulse can authenticate to the PAX8 API via OAuth2 client-credentials, and the Postgres schema for all four PAX8 entities exists — proving the integration pattern before any sync logic is built on top of it.
@@ -325,10 +325,136 @@ render, including the manual-resolution workflow for flagged companies.
 - [x] 14-06-PLAN.md — Automated gates + human verification of all 4 SCs and the view/resolve permission split (PAX8-12, PAX8-13, PAX8-14)
 **UI hint**: yes
 
+</details>
+
+### 🚧 v3.0 Phishing Triage Automation (In Progress)
+
+**Milestone Goal:** Detect candidate phishing/spam report tickets in Autotask, extract
+and parse original-message evidence, classify each as `SPAM` / `UNWANTED` / `THREAT`,
+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
+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
+evidence, since every later service writes to that schema. Phase 16 is the pure,
+testable RFC822/MIME `.eml` parser — it has no dependency on detection beyond the
+schema, but campaign grouping depends on its output (Message-ID, indicators), so it
+must land before Phase 18. Phase 17 (Mimecast blast-radius) has no dependency on the
+parser or on campaigns — it only needs the Phase 15 schema — so it's sequenced here
+as an independent unit that could equally have been built in parallel with Phase 16
+by a second workstream. Phase 18 is the first phase to expose `/api/phishing/*`
+routes (campaign list/get, on-demand ticket analysis) and is where ACCESS-01's
+auth convention is established for every phishing endpoint that follows. Phase 19
+(classification) depends on both Phase 17's blast-radius output and Phase 18's
+campaign data as inputs — it cannot run before either. Phase 20 (remediation/
+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.
+
+- [ ] **Phase 15: Data Model, Detection & Ticket Evidence** — New phishing schema (migration 097) + idempotent Autotask ticket scanner + base ticket evidence capture
+- [ ] **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
+- [ ] **Phase 17: Mimecast Blast Radius Lookup** — Blast-radius abstraction with graceful `unavailable` degradation when Mimecast isn't configured
+- [ ] **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
+- [ ] **Phase 19: Classification Engine** — Deterministic SPAM/UNWANTED/THREAT rule classifier over bounded structured evidence, KnowBe4-simulation guard, (re-)trigger API
+- [ ] **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 Details
+
+### Phase 15: Data Model, Detection & Ticket Evidence
+**Goal**: The durable phishing-triage schema exists in Postgres, and Pulse can scan Autotask/Pulse tickets for known phishing/spam-report patterns idempotently, capturing base ticket-level evidence for each candidate.
+**Depends on**: Nothing (first phase of v3.0)
+**Requirements**: DETECT-01, DETECT-02, EVID-01
+**Success Criteria** (what must be TRUE):
+  1. A new migration (`migrations/097_*.sql` or next available number) creates `campaigns`, `reports`, `messages`, `indicators`, `classifications`, `remediation_actions`, and `audit_events` tables with `IF NOT EXISTS`, ready for every later phase to read/write
+  2. Running the ticket scanner against Autotask/Pulse tickets flags candidates matching the known title/body patterns ("Phishing Report", "Spam Alert", "Phishing Alert - Email Security Report", "KnowBe4 Phish Alert Report", "Source: KnowBe4 Phish Alert Button", "userSubmissionsReportMessage", "reported message destinations", "Microsoft directly") and persists a `reports` row per candidate
+  3. Re-scanning tickets that haven't changed since last processed does not reprocess or duplicate their `reports` rows; a ticket whose Autotask data changed since last processed IS reprocessed (idempotent on ticket state, not just ticket ID)
+  4. Each flagged ticket's stored evidence includes ticket ID/number, company, requester/reporter, title, description, notes, relevant time entries, and attachment metadata (EVID-01)
+**Plans**: TBD
+**UI hint**: no
+
+### Phase 16: EML/MIME Evidence Parser
+**Goal**: Given a ticket's attachments, Pulse selects the correct original reported message and parses its RFC822/MIME structure into normalized, actionable evidence — without ever executing or fetching anything from the message.
+**Depends on**: Phase 15 (messages/indicators tables to persist output into)
+**Requirements**: EVID-02, EVID-03, EVID-04
+**Success Criteria** (what must be TRUE):
+  1. Given synthetic fixtures with both `rfc.eml` and `OriginatingEmail.eml` present, the selection logic picks `rfc.eml` as the original reported message, matching case-insensitively and by `message/rfc822` content-type — not filename alone
+  2. Parsing a synthetic `.eml` fixture produces normalized headers (From, display name, sender email/domain, Reply-To, Return-Path, To, Cc, Subject, Date, Message-ID, Received chain, SPF/DKIM/DMARC results), a list of extracted URLs, and attachment metadata (name, content-type, size, hash)
+  3. The parser never executes or fetches any URL found in a message — verified by tests asserting no outbound network calls happen during parsing
+  4. Parsed output includes a sanitized/truncated body preview stored alongside the raw evidence, distinct from the full raw body
+  5. `npx vitest run` for the new parser test file passes using synthetic fixtures only (no real customer email)
+**Plans**: TBD
+**UI hint**: no
+
+### Phase 17: Mimecast Blast Radius Lookup
+**Goal**: Pulse can ask "how far did this message spread" via a Mimecast blast-radius abstraction when Mimecast is configured, and gets a clean `unavailable` signal — never a crash or a block — when it isn't.
+**Depends on**: Phase 15 (schema to store lookup results against)
+**Requirements**: BLAST-01, BLAST-02
+**Success Criteria** (what must be TRUE):
+  1. When Mimecast is configured, querying the blast-radius abstraction for a message (keyed on message ID, sender, recipient/reporter, subject, and date window) returns normalized delivery data — matched/delivered/held/rejected/clicked counts and per-recipient status
+  2. When Mimecast is not configured, the same lookup call returns `status: unavailable` synchronously rather than throwing, timing out, or blocking the caller
+  3. The lookup follows the existing `lib/services/` factory convention (`getMimecastClient()` + `isMimecastConfigured()`-equivalent) so Phase 19's classifier can call it without knowing whether Mimecast is present
+**Plans**: TBD
+**UI hint**: no
+
+### Phase 18: Campaign Grouping & Phishing Analysis API
+**Goal**: Duplicate reports of the same phishing/spam campaign are automatically grouped and accumulate over time, and an operator can trigger analysis of a specific ticket or browse campaigns through a properly access-controlled `/api/phishing/*` surface.
+**Depends on**: Phase 16 (parsed Message-ID/indicators to key grouping on)
+**Requirements**: CAMP-01, CAMP-02, CAMP-03, DETECT-03, ACCESS-01
+**Success Criteria** (what must be TRUE):
+  1. Two reports sharing the same original Message-ID are grouped into the same campaign; absent a shared Message-ID, reports sharing attachment-hash/URL-domain + subject + sender within a time window are grouped instead; absent that too, sender + normalized subject + client + time-window groups them as the final fallback
+  2. A campaign accumulates additional linked ticket reports and recipients as new duplicate reports arrive over time, without ever creating a second campaign for the same underlying report
+  3. `POST /api/phishing/tickets/{ticket_id}/analyze` runs detection + evidence extraction + campaign grouping for one specific ticket on demand and returns the resulting campaign linkage, instead of waiting for the next scheduled scan
+  4. `GET /api/phishing/campaigns` lists campaigns and `GET /api/phishing/campaigns/{id}` returns full detail (linked reports, messages, indicators, classification history)
+  5. Every `/api/phishing/*` route introduced in this phase calls `requireAuth()` (or `requirePermission()`) and rejects an unauthenticated/unauthorized request with 401/403 — establishing the auth convention every later phishing endpoint (Phases 19-21) must also follow
+**Plans**: TBD
+**UI hint**: no
+
+### Phase 19: Classification Engine
+**Goal**: Every campaign gets a deterministic SPAM/UNWANTED/THREAT verdict, built from bounded structured evidence (never raw unbounded email), that correctly flags destructive-action recommendations for approval and doesn't cry wolf on routine KnowBe4 simulations.
+**Depends on**: Phase 17 (blast-radius input), Phase 18 (campaign data input + auth convention)
+**Requirements**: CLASSIFY-01, CLASSIFY-02, CLASSIFY-03, CLASSIFY-04, CLASSIFY-05, CLASSIFY-06
+**Success Criteria** (what must be TRUE):
+  1. Classifying a campaign returns exactly one of `SPAM` / `UNWANTED` / `THREAT` with confidence, a short summary, evidence-backed reasons, recommended actions, and a `requires_approval` flag
+  2. A classification whose recommended actions include any destructive action (purge/block/delete/reset) always has `requires_approval: true` — proven by a test asserting the invariant can't be produced any other way
+  3. Classifying a campaign with incomplete evidence (no Mimecast data, no `.eml`) lowers confidence and names the specific missing evidence in the reasons
+  4. A synthetic KnowBe4 security-awareness-simulation fixture is not classified as `THREAT` absent contrary evidence
+  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**: TBD
+**UI hint**: no
+
+### Phase 20: Remediation, Approval & Audit Safety
+**Goal**: Remediation actions are proposed, never auto-executed, and every approve/remediate/mark-false-positive action is gated by elevated permission, idempotent on re-run, and fully audited.
+**Depends on**: Phase 18 (campaigns to act against), Phase 19 (classifications to approve/act on)
+**Requirements**: REMED-01, REMED-02, REMED-03, REMED-04, REMED-05, REMED-06
+**Success Criteria** (what must be TRUE):
+  1. Recommended remediation actions are persisted with status `proposed`, and no code path in this milestone executes one automatically
+  2. `POST /api/phishing/campaigns/{id}/approve` records approver, timestamp, and the exact approved action parameters, and is gated behind a permission level above plain read access (beyond the Phase 18 baseline)
+  3. `POST /api/phishing/campaigns/{id}/remediate` proceeds only for already-approved actions against a configured, non-destructive-by-default provider path; otherwise it returns `not_implemented`/an explicit failure and never silently succeeds without taking or logging an action
+  4. Re-running remediation against an already-completed action does not duplicate the destructive effect — proven by a test that calls remediate twice and asserts a single effect/log entry
+  5. `POST /api/phishing/campaigns/{id}/mark-false-positive` exists, and every state-changing action (classify, approve, remediate, mark-false-positive) writes an `audit_events` row recording actor, event type, and payload
+**Plans**: TBD
+**UI hint**: no
+
+### Phase 21: Autotask Triage Note
+**Goal**: Once a campaign is classified, a human-readable, sanitized internal triage note either gets posted to the Autotask ticket (if a safe write path already exists) or is returned via API for manual use — never a raw/unsanitized dump, never a silent no-op.
+**Depends on**: Phase 19 (classification content to summarize), Phase 20 (recommended/approved remediation state to include)
+**Requirements**: NOTE-01
+**Success Criteria** (what must be TRUE):
+  1. If Pulse has a safe existing Autotask note-writing method, triggering note generation for a classified campaign posts an internal triage note summarizing classification, evidence, blast radius, and recommended actions to the originating ticket
+  2. The posted (or returned) note text is sanitized — no raw secrets/tokens/full malicious URL query strings appear in it
+  3. If no safe note-writing path exists, the same note content is returned via the API response instead of attempting any Autotask write, and no partial/unsanitized write is ever attempted as a fallback
+**Plans**: TBD
+**UI hint**: no
+
 ## Progress
 
 **Execution Order:**
-Phases execute in numeric order. v1.0 (Phases 1-9.1) shipped 2026-07-10. v2.0 phases run 10 → 11 → 12 → 13 → 14 — each is a hard dependency on the previous within this milestone (no parallelization: auth → current-state sync → historical sync + matching → scheduling → UI, in that 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.
 
 | Phase | Milestone | Plans Complete | Status | Completed |
 |-------|-----------|----------------|--------|-----------|
@@ -343,15 +469,24 @@ Phases execute in numeric order. v1.0 (Phases 1-9.1) shipped 2026-07-10. v2.0 ph
 | 8. Engagement User Profile | v1.0 | 2/2 | Complete | 2026-07-10 |
 | 9. User Profile & Preferences | v1.0 | 6/6 | Complete | 2026-07-10 |
 | 9.1. ntfy Backend Fix | v1.0 | 1/1 | Complete | 2026-07-10 |
-| 10. PAX8 Client & Auth Foundation | v2.0 | 3/3 | Complete    | 2026-07-10 |
-| 11. Company, Catalog & Subscription Sync | v2.0 | 3/3 | Complete    | 2026-07-11 |
-| 12. Orders/Invoices & Company Matching | v2.0 | 5/5 | Complete    | 2026-07-11 |
-| 13. Scheduler & Admin Toggle | v2.0 | 3/3 | Complete    | 2026-07-11 |
-| 14. /pax8 UI Surface | v2.0 | 6/6 | Complete    | 2026-07-12 |
+| 10. PAX8 Client & Auth Foundation | v2.0 | 3/3 | Complete | 2026-07-10 |
+| 11. Company, Catalog & Subscription Sync | v2.0 | 3/3 | Complete | 2026-07-11 |
+| 12. Orders/Invoices & Company Matching | v2.0 | 5/5 | Complete | 2026-07-11 |
+| 13. Scheduler & Admin Toggle | v2.0 | 3/3 | Complete | 2026-07-11 |
+| 14. /pax8 UI Surface | v2.0 | 6/6 | Complete | 2026-07-12 |
+| 15. Data Model, Detection & Ticket Evidence | v3.0 | 0/TBD | Not started | - |
+| 16. EML/MIME Evidence Parser | v3.0 | 0/TBD | Not started | - |
+| 17. Mimecast Blast Radius Lookup | v3.0 | 0/TBD | Not started | - |
+| 18. Campaign Grouping & Phishing Analysis API | v3.0 | 0/TBD | Not started | - |
+| 19. Classification Engine | v3.0 | 0/TBD | Not started | - |
+| 20. Remediation, Approval & Audit Safety | v3.0 | 0/TBD | Not started | - |
+| 21. Autotask Triage Note | v3.0 | 0/TBD | Not started | - |
 
 ---
 *Roadmap created: 2026-05-03*
 *v2.0 phases added: 2026-07-10*
+*v3.0 phases added: 2026-07-14*
 *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`*
 </content>

.planning/STATE.md

@@ -3,10 +3,10 @@ gsd_state_version: 1.0
 milestone: v3.0
 milestone_name: Phishing Triage Automation
 status: planning
-last_updated: "2026-07-15T03:33:51.575Z"
-last_activity: 2026-07-15
+last_updated: "2026-07-14T00:00:00.000Z"
+last_activity: 2026-07-14
 progress:
-  total_phases: 0
+  total_phases: 7
   completed_phases: 0
   total_plans: 0
   completed_plans: 0
@@ -17,50 +17,39 @@ progress:
 
 ## Project Reference
 
-See: .planning/PROJECT.md (updated 2026-07-10)
+See: .planning/PROJECT.md (updated 2026-07-14)
 
-**Core value:** Managers can see PAX8 subscription costs and seat counts alongside existing Autotask company data in Pulse, without manually cross-referencing PAX8's own portal.
-**Current focus:** Milestone complete
+**Core value:** A manager/security operator can see every phishing/spam report ticket automatically triaged, deduplicated into campaigns, and classified — with any destructive remediation gated behind explicit human approval.
+**Current focus:** Phase 15: Data Model, Detection & Ticket Evidence
 
 ## Current Position
 
-Phase: Not started (defining requirements)
-Plan: —
-Status: Defining requirements
-Last activity: 2026-07-15 — Milestone v3.0 started
+Phase: 15 of 21 (Data Model, Detection & Ticket Evidence)
+Plan: — (not yet planned)
+Status: Roadmap approved, ready to plan Phase 15
+Last activity: 2026-07-14 — v3.0 ROADMAP.md created, 26/26 requirements mapped across Phases 15-21
+
+Progress: [░░░░░░░░░░] 0%
 
 ## Performance Metrics
 
 **Velocity:**
 
-- Total plans completed: 50 (all from v1.0 Mobile Shell Redesign)
+- Total plans completed: 50 (v1.0: 42, v2.0: 20 across phases 10-14 — see per-phase table)
 - Average duration: —
-- Total execution time: 0.0 hours (v2.0)
+- Total execution time: 0.0 hours (v3.0)
 
 **By Phase:**
 
 | Phase | Plans | Total | Avg/Plan |
 |-------|-------|-------|----------|
-| 01 | 2 | - | - |
-| 02 | 2 | - | - |
-| 03 | 2 | - | - |
-| 04 | 3 | - | - |
-| 05 | 2 | - | - |
-| 06 | 3 | - | - |
-| 07 | 3 | - | - |
-| 07.1 | 5 | - | - |
-| 08 | 2 | - | - |
-| 09 | 6 | - | - |
-| 09.1 | 1 | - | - |
-| 10 | 3 | - | - |
-| 11 | 3 | - | - |
-| 12 | 5 | - | - |
-| 13 | 3 | - | - |
-| 14 | 6 | - | - |
+| 01-09.1 (v1.0) | 34 | - | - |
+| 10-14 (v2.0) | 20 | - | - |
+| 15-21 (v3.0) | TBD | - | - |
 
 **Recent Trend:**
 
-- Last 5 plans: — (v1.0 closed; v2.0 not yet executed)
+- Last 5 plans: — (v2.0 closed 2026-07-12; v3.0 not yet executed)
 - Trend: —
 
 *Updated after each plan completion*
@@ -72,22 +61,27 @@ Last activity: 2026-07-15 — Milestone v3.0 started
 Decisions are logged in PROJECT.md Key Decisions table.
 Recent decisions affecting current work:
 
-- v2.0 roadmap: 5 phases (10-14), strictly sequential — auth foundation →
-  current-state sync → historical sync + company matching → scheduler/admin
-  toggle → UI — each phase is a hard dependency on the previous, no
-  parallelization within this milestone
-
-- Phase 10 isolates OAuth2 client-credentials auth + the full PAX8 schema
-  migration before any sync logic is written, to de-risk the new external
-  integration early
-
-- PAX8-08 (read-only guarantee) and PAX8-11 (flag don't guess) are treated as
-  constraints verified within their natural sync phase (11 and 12
-  respectively), not standalone phases
-
-- PAX8-12 (admin resolves flagged matches) is delivered on the `/pax8` page
-  itself (Phase 14) rather than a separate `/admin` surface — `/pax8` is the
-  dedicated home for this integration's data and review workflow
+- v3.0 roadmap: 7 phases (15-21), each a hard dependency on at least one
+  predecessor except Phase 17 (Mimecast blast-radius), which only depends on
+  the Phase 15 schema and could be built in parallel with Phase 16 (EML
+  parser) if split across two workstreams — sequenced after 16 here for a
+  single execution thread
+- The durable schema (campaigns/reports/messages/indicators/classifications/
+  remediation_actions/audit_events) lands in Phase 15, before any service
+  that writes to it — new migration, next number after 096 (097+)
+- ACCESS-01 is mapped to Phase 18 (the first phase introducing
+  `/api/phishing/*` routes) rather than a standalone terminal phase; every
+  later phishing endpoint (19, 20, 21) is expected to continue enforcing the
+  same `requireAuth`/`requirePermission` convention as a success-criteria
+  carry-forward, not a re-mapped requirement
+- Classification (Phase 19) is sequenced after both Phase 17 (blast-radius)
+  and Phase 18 (campaigns) since it needs both as inputs
+- Remediation/approval/audit (Phase 20) is sequenced after Phase 18
+  (campaigns) and Phase 19 (classifications) — can't approve/gate an action
+  that doesn't reference either
+- Autotask triage note (Phase 21) is last — its content summarizes
+  classification + blast radius + recommended/approved remediation state,
+  so it has nothing to summarize until Phases 19-20 exist
 
 ### Pending Todos
 
@@ -115,7 +109,7 @@ Items acknowledged and carried forward from previous milestone close:
 
 ## Session Continuity
 
-Last session: 2026-07-11T17:25:07.458Z
-Stopped at: Phase 14 UI-SPEC approved
-Resume file: .planning/phases/14-pax8-ui-surface/14-UI-SPEC.md
+Last session: 2026-07-14T00:00:00.000Z
+Stopped at: v3.0 ROADMAP.md and STATE.md created; REQUIREMENTS.md traceability populated
+Resume file: None — next step is `/gsd:plan-phase 15`
 </content>