diff --git a/.planning/REQUIREMENTS.md b/.planning/REQUIREMENTS.md index 375c678..15cf071 100644 --- a/.planning/REQUIREMENTS.md +++ b/.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* diff --git a/.planning/ROADMAP.md b/.planning/ROADMAP.md index e9b2816..5c9f1e6 100644 --- a/.planning/ROADMAP.md +++ b/.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. -### 📋 v2.0 PAX8 Integration (Planned) +
+✅ v2.0 PAX8 Integration (Phases 10-14) - SHIPPED 2026-07-12 **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 +
+ +### 🚧 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`* diff --git a/.planning/STATE.md b/.planning/STATE.md index 5e039b0..15bdfa6 100644 --- a/.planning/STATE.md +++ b/.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`