- POST /approve: phishing:approve gated, validates actions array (D-03),
delegates to approveRemediationActions with actor from session
- POST /remediate: phishing:remediate gated, delegates to
remediateApprovedActions (idempotent completion, REMED-03/04)
- Both UUID-guard the campaign id and map RemediationValidationError->400,
RemediationConflictError->409
- Guards against marking false positive when any approved/completed
remediation exists for the campaign (RemediationConflictError, T-20-04)
- Sets campaigns.status='false_positive' and writes one atomic audit row
recording previousStatus + reason (REMED-05, REMED-06)
- Fixes test mock SQL substring match for the D-04 guard query
- Reworded a header comment to avoid a literal "not_implemented" string
that tripped the D-01 grep acceptance check
- approveRemediationActions validates each requested action against the
campaign's latest classification.recommended_actions and materializes
only recommended action types as status='approved' rows plus one
atomic audit row (REMED-01, REMED-02, REMED-06)
- remediateApprovedActions transitions approved rows to 'completed'
(D-01 simulated internal effect, no external provider call), is
idempotent via the status='approved' FOR UPDATE filter (REMED-04),
and fails explicitly on zero remediation_actions rows (REMED-03)
- RemediationValidationError / RemediationConflictError typed error classes
Note: markCampaignFalsePositive (referenced by the already-committed test
file) lands in the next commit (Task 3) — tsc will be clean again once
that lands.
- Single parameterized append-only INSERT into audit_events
- Supports optional injected transaction client for atomic writes
- Documents the four canonical event_type strings for this phase
- requirePermission('phishing','analyze') early-return (same action as /analyze, Phase 18 D-06)
- UUID_RE guard on campaign id before any DB query (T-19-05)
- 404 when campaign id is well-formed but not found
- delegates to classifyCampaign(id) from lib/services/campaign-classifier.ts (Plan 01), returns flat ClassifyResult payload
- gatherCampaignEvidence: bulk-fetches reports (earliest-first, joined to
contacts for requester email) -> messages (report_id = ANY) -> indicators
(message_id = ANY), parses messages.headers JSONB into bounded
ParsedMessage fields, and runs one getBlastRadius() lookup keyed off the
earliest report's sender/subject/±24h window (research A6); synthesizes
unavailable/not_configured with no Mimecast call when no report is linked
- evaluateThreatTier (D-03): blastRadius.status==='ok' AND
(delivered>0 OR clicked>0) AND (hasHardAuthFail via effectiveAuthResults
OR hasKnownBadIndicatorMatch — same attachment_hash/url value spanning
>=2 distinct messages, cross-report correlation only, no external
reputation lookup per research A4)
- evaluateSpamVsUnwanted (D-04): UNWANTED when any attachment/url indicator
matches or delivery is contained to the reporter(s) only; SPAM otherwise
- classifyCampaign: D-06 simulation short-circuit -> D-03 -> D-04 ->
computeConfidence -> mapVerdictToActions -> computeRequiresApproval ->
append-only INSERT into classifications (D-02, no ON CONFLICT), wrapped
in try/catch logging [CAMPAIGN-CLASSIFIER] + err.message and rethrowing
- isKnownSimulationSender relaxed to a narrower SenderIdentity shape so both
the full NormalizedMessage fixtures and the bounded ParsedMessage type
can share it
- All 39 tests green; tsc clean; full `npm test` suite green except 2
pre-existing, unrelated itglue-search.test.ts failures (see
deferred-items.md)
Documents the CR-03 own-campaign revalidation guard and CR-02 origin
decrement fix (Tasks 1-2, committed and green), ahead of the blocking
Task 3 human live-database-verification checkpoint.
Cross-campaign migration (a report moves from campaign A to a
different existing campaign B on re-analyze) never decremented A's
report_count, leaving it permanently stale. The same abandonment
happens on the signal-diverged create-new fall-through added for
CR-03 (Task 1) — landing on a brand-new campaign instead of an
existing sibling's, but the same class of staleness.
Add a shared decrementOriginCampaign() helper and call it in both
locations, guarded so it only fires when there is a real origin
(ownReport.campaign_id non-null) and the match doesn't resolve back to
the report's own campaign (the existing same-campaign no-op guard is
unchanged). D-08 sibling upgrades (never-grouped report -> sibling
campaign) increment the destination only, with no origin to
decrement.
- Test E: cross-campaign migration decrements origin, increments destination
- Test F: D-08 upgrade with no prior campaign increments destination only
- Test G (renamed from existing 18-04 test): same-campaign re-match remains zero mutations
- Test H: signal-diverged create-new also decrements the abandoned origin (plan-checker-flagged case)
Tests E and H failed against the pre-fix code (confirmed during RED).
Re-analyzing a single-report campaign (no sibling report exists yet)
fell through to "create new campaign" because every tier query
self-excludes the report's own row, so matchCampaignId stayed null and
the report's still-valid campaign was abandoned in favor of a
duplicate campaigns row sharing the same campaign_key.
Add a guard that runs only when no sibling matched and the report
already has campaign_id: recompute the report's current tier keys
once, look up its own campaign row, and reuse it (created:false) when
the stored campaign_key still matches. Falls through to create-new
unchanged when the campaign row is gone or the signal has genuinely
diverged. D-08 sibling upgrades are untouched (guard only runs when no
sibling matched).
- Tests A/B reproduce the exact CR-03 duplicate-campaign scenario and
failed against the pre-fix code (confirmed during RED)
- Tests C/D guard the create-new no-regression and signal-diverged
fall-through paths
The count query reused statusFilter (built with $3 against the list query's
3-element params array) but only passed a 1-element params array, causing a
Postgres bind-parameter mismatch (500) on any `?status=` filtered request.
Pre-existing since 18-03; surfaced by the 18-04 gap-closure code re-review.
Gives the count query its own independent param array/placeholder numbering.
