Implement anomaly detection rule evaluator
epic-bufdir-report-preview-core-logic-task-004 — Implement the anomaly detection rule class. For each numeric field, compare the current period value to the prior-period equivalent (passed in as context). If the deviation exceeds a configurable percentage threshold (default 50%), emit a ValidationIssue with severity 'warning', ruleClass 'anomaly', and a message such as 'Activity count dropped from 42 to 0, a 100% decrease from the previous period.' Handle null prior-period values gracefully (skip anomaly check, do not emit false positives).
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Keep the deviation formula consistent: when prior == 0 and current == 0, deviation = 0%; when prior == 0 and current != 0, deviation = 100% (special case to avoid divide-by-zero). Use (current - prior).abs() / prior.abs() * 100 for all other cases. Round to nearest integer for display: deviation.round(). The direction of change (increase vs decrease) should be determined by comparing current to prior and using 'increased' or 'dropped' in the message accordingly.
AnomalyConfig is a simple injectable class: class AnomalyConfig { final double deviationThresholdPercent; const AnomalyConfig({this.deviationThresholdPercent = 50.0}); }. This evaluator's evaluate() signature differs slightly from completeness/threshold because it requires both current and prior BufdirReportSectionModel — define a nullable priorSection parameter on the RuleEvaluator interface or use a subtype.
Testing Requirements
Unit tests using flutter_test. Test class: AnomalyDetectionRuleEvaluatorTest. Required scenarios: (1) null prior → no issue, (2) both zero → no issue, (3) deviation below threshold → no issue, (4) deviation at threshold → no issue, (5) deviation above threshold → warning with correct message, (6) current null + prior non-null + deviation > threshold → warning (null treated as 0), (7) prior zero + current > 0 → 100% increase triggers warning, (8) positive spike (increase) above threshold → warning, (9) negative drop (decrease) above threshold → warning, (10) custom threshold via injected AnomalyConfig applied correctly, (11) field present in current but absent in prior → skip (no false positive). Assert message content includes prior value, current value, and rounded percentage.
Minimum 90% line coverage.
The exact minimum threshold values required by Bufdir guidelines (e.g., minimum participant counts per section) may not be formally documented in machine-readable form. If thresholds must be researched or negotiated during implementation, the validation service will be delayed and may launch with incomplete rules, reducing its effectiveness.
Mitigation & Contingency
Mitigation: Compile threshold rules from the Bufdir reporting guidelines PDF before sprint start. Store rules in a separate configuration file (not hardcoded in the service class) so they can be updated without a service rewrite. Treat unknown thresholds as 'no minimum' to avoid false errors.
Contingency: Launch with completeness and anomaly validation only, shipping threshold compliance rules as a follow-on config update once rules are confirmed with Bufdir. Flag this as a known limitation in the coordinator help text.
BufdirPreviewService coordinates three async operations (fetch aggregated data, map structure, run validation). Race conditions or partial failures in this chain could produce an inconsistent preview model — e.g., a model with field values but no validation results — which would silently mislead coordinators into thinking the report is clean.
Mitigation & Contingency
Mitigation: Model the orchestration as a single BLoC/Cubit state machine with explicit states (Loading, Loaded, Error) and ensure validation is always run atomically after mapping, never in parallel. Write integration tests that simulate network failure at each step of the chain.
Contingency: If a partial failure state reaches production, detect it via the missing validation summary field in the preview model and show a full-screen error state rather than an incomplete preview, prompting the coordinator to retry.