Define integration type registry static declarations
epic-external-system-integration-configuration-foundation-task-001 — Create the static integration type registry that declares all supported external systems (Xledger, Dynamics, Cornerstone, Consio, Bufdir). Each entry must define the system name, credential field schema (required fields, field types, validation rules), and available mapping targets for field_mappings JSONB. This registry serves as the source of truth for all downstream components.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 0 - 440 tasks
Handles integration between different epics or system components. Requires coordination across multiple development streams.
Implementation Notes
Implement as a pure Dart class with no Flutter dependencies so it can be used in both Flutter app and any future server-side Dart context. Use a sealed class hierarchy for IntegrationTypeDefinition if Dart version supports it (Dart 3+), otherwise use a plain class with const constructors. Define integration type string constants in a separate IntegrationTypes class (e.g., IntegrationTypes.xledger = 'xledger') to prevent magic strings. For credential schemas, Xledger requires API endpoint URL + API key; Dynamics requires tenant ID + client ID + client secret + resource URL; Cornerstone requires domain + API key; Consio requires base URL + bearer token; Bufdir requires organization number + reporting period format.
Map these to the CredentialFieldDefinition structure. Keep mapping targets generic at this layer — specific field-level mapping is the concern of the FieldMappingResolver, not the registry.
Testing Requirements
Unit tests using flutter_test. Test file: test/integration/integration_type_registry_test.dart. Required test cases: (1) Each of the 5 integration types resolves successfully from the registry. (2) Unknown integration type throws/returns typed error.
(3) All 5 entries have at least one required credential field. (4) All 5 entries have at least one available mapping target. (5) All constant identifiers match their corresponding registry key. Target 100% line coverage for the registry class since it is a foundation dependency for the entire integration system.
Supabase Vault API has limited documentation for Dart/Flutter clients; wrapping it correctly for credential rotation and secret reference management may require significant trial and error, delaying the vault component and blocking all downstream credential-dependent work.
Mitigation & Contingency
Mitigation: Spike the Vault integration in the first sprint using a minimal proof-of-concept (store, retrieve, rotate one secret). Document the API surface before building the full vault client. Identify any missing Dart SDK bindings early.
Contingency: If Supabase Vault is too complex, fall back to Supabase's encrypted column approach (pgcrypto) for credential storage as a temporary measure, with a planned migration path to Vault once the API is understood.
Incorrect RLS policy configuration on organization_integrations could allow org admins of one organization to read or modify another organization's integration credentials, creating a serious data breach and compliance violation.
Mitigation & Contingency
Mitigation: Write integration tests that explicitly attempt cross-org data access using different JWT tokens and assert 0 rows returned. Include RLS policy review in PR checklist. Use Supabase's local development stack for policy validation before deployment.
Contingency: If a breach is discovered post-deployment, immediately revoke all integration credentials, rotate vault secrets, notify affected organizations, and apply emergency RLS patches.
JSONB columns for field_mappings and sync_schedule lack database-level schema enforcement; AI-generated or malformed JSON could silently corrupt integration configurations, causing export failures that are hard to diagnose.
Mitigation & Contingency
Mitigation: Define TypeScript/Dart model classes with strict deserialization and validation. Add database check constraints or triggers that validate JSONB structure at write time. Version the JSONB schema to enable forward-compatible migrations.
Contingency: Build a repair script that scans organization_integrations for invalid JSONB and resets corrupted records to a safe default state, alerting the admin of the affected organization.