Implement completeness rule evaluator
epic-bufdir-report-preview-core-logic-task-002 — Implement the completeness rule class within BufdirFieldValidationService. For each required field in a BufdirReportSectionModel, check that the value is non-null and non-empty. Return a ValidationIssue with severity 'error', ruleClass 'completeness', the field key, and an English message such as 'Field X is required and must not be empty.' Ensure field keys map to human-readable Bufdir field names via a configurable lookup map.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Define a sealed class hierarchy for ValidationIssue if not already done in task-001 (severity as enum: error, warning, info; ruleClass as String or enum). The lookup map type should be Map
The class should implement an abstract RuleEvaluator interface defined in task-001 so the orchestrator (task-005) can treat all evaluators uniformly via polymorphism.
Testing Requirements
Unit tests using flutter_test (dart:test). Test class: CompletenessRuleEvaluatorTest. Required scenarios: (1) null value on required field → error issued, (2) empty string on required field → error issued, (3) whitespace-only string on required field → error issued, (4) valid value on required field → no issue, (5) null value on optional field → no issue, (6) human-readable label used in message when key present in map, (7) raw key used as fallback when key absent from map, (8) multiple required fields with multiple nulls → one issue per field, (9) section with zero required fields → empty list returned. Minimum 90% line coverage on evaluator class.
No mocking of Supabase or Flutter required — pure unit tests.
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.