Define ExportResult type and AccountingExporterService interface
epic-accounting-system-export-orchestration-task-001 — Define the ExportResult data model (covering signed URL path, API push confirmation, export run ID, status, and error details) and the AccountingExporterService abstract interface. Establish the contract that all downstream pipeline steps will depend on, including the method signature for triggerExport(orgId, dateRange, requestingUserId).
Acceptance Criteria
Technical Requirements
Implementation Notes
Use Dart 3's sealed classes for ExportStatus if the project targets Dart >= 3.0 — this gives compiler-enforced exhaustive switches. If targeting Dart 2.x, use a regular enum and add a lint rule requiring exhaustive switch coverage via the exhaustive_cases lint. Keep DateRange in the same file as the interface since it is exclusively used as a parameter type. Avoid adding methods to ExportResult beyond factory constructors and equality/hashCode — keep it a pure data class.
Consider using package:equatable or implementing == and hashCode manually for reliable value equality in tests. The interface should be in lib/src/accounting/export/accounting_exporter_service.dart and re-exported via lib/accounting_export.dart. This file is the contract that both the foundation epic and orchestration epic tasks depend on — merge it before any dependent tasks begin.
Testing Requirements
Unit tests (dart test): (1) ExportResult.duplicate() sets status=duplicate and exportRunId correctly. (2) ExportResult.failure() sets status=failed with errorCode and errorDetail. (3) ExportResult.empty() sets status=empty and recordCount=0. (4) DateRange.fromIso8601() parses valid ISO strings correctly.
(5) DateRange.validate() throws ArgumentError when start > end. (6) DateRange.validate() passes when start == end (single-day export). (7) Verify that ExportStatus switch is exhaustive by compiling a switch over all values — failing to handle any value should be a compile error. All tests must pass with dart test and zero linter warnings.
The Edge Function may exceed Supabase's execution time limit (default 150 seconds, but effectively constrained by the 10-second client SLA) when processing large batches of claims with complex chart-of-accounts mapping, causing the export to fail after partial processing.
Mitigation & Contingency
Mitigation: Implement the export pipeline with early termination on timeout and an in-progress export run status. Add a benchmark test in CI that runs the full pipeline against 500 claims and fails if it exceeds 8 seconds. Optimize the approved claims query with indexes on status, org_id, and date fields.
Contingency: If performance targets cannot be met synchronously, convert the Edge Function to an async job pattern: the function queues the export and returns a job ID immediately; the client polls a status endpoint and downloads the file when ready. This requires a job queue table and a polling UI state.
Supabase Vault access from the Edge Function may require specific service role key configuration that differs between staging and production environments, causing credential retrieval to fail silently and producing export runs that appear successful but have no valid accounting system target.
Mitigation & Contingency
Mitigation: Test Vault read access in the Edge Function in staging before implementing any business logic. Add an explicit credential validation step at Edge Function startup that fails fast with a clear error if Vault is unreachable or the secret is missing.
Contingency: If Vault access fails in production, fall back to environment variable-based credentials temporarily (never returned to client) while the Vault configuration is corrected. Alert on-call via a monitoring rule that fires if credential retrieval fails.
AccountingExporter Service may become tightly coupled to specific exporter implementations if the factory pattern is not implemented cleanly, making it difficult to add a third exporter in the future without modifying the orchestrator.
Mitigation & Contingency
Mitigation: Define an AccountingExporter abstract class with a strict interface contract before implementing any concrete class. Use a registry pattern (Map<orgType, AccountingExporter>) in the factory rather than conditionals. Code review should verify no concrete class is imported directly in the orchestrator.
Contingency: If tight coupling is discovered after implementation, refactor the factory before the Edge Function epic ships so the interface is stable before any external callers are wired in.