Implement Dart integration type registry class

epic-external-system-integration-configuration-foundation-task-006 — Implement the Dart IntegrationTypeRegistry class as a static/singleton infrastructure component. It must expose typed metadata for each supported integration: credential field definitions (name, type, required, placeholder), available field mapping targets per integration type, and display names. Load from compile-time constants; no network calls required.

high priority low complexity infrastructure pending backend specialist Tier 1

Acceptance Criteria

IntegrationTypeRegistry is implemented as a singleton (or all-static class) with no public constructor

Registry exposes typed metadata for all 5 integration types: xledger, dynamics, cornerstone, consio, bufdir

Each integration type entry includes: displayName (String), credentialFields (List<CredentialFieldDefinition>), and availableMappingTargets (List<String>)

CredentialFieldDefinition includes: name, type (enum: text, password, url, apiKey), required (bool), and placeholder (String?)

Registry values are defined as compile-time constants (const) — no async initialization, no network calls

Calling IntegrationTypeRegistry.getMetadata('xledger') returns the correct typed metadata object

Calling IntegrationTypeRegistry.getMetadata('unknown_type') throws an ArgumentError with a descriptive message

IntegrationTypeRegistry.supportedTypes returns an unmodifiable list of all 5 integration type string identifiers

All string identifiers match the PostgreSQL enum values exactly (lowercase snake_case)

Class has 100% unit test coverage for all public methods and edge cases

Technical Requirements

frameworks

Flutter

Dart

data models

IntegrationTypeMetadata

CredentialFieldDefinition

IntegrationType enum

performance requirements

All registry lookups must be O(1) — use a compile-time Map

No async initialization — registry must be immediately available on app start

Zero heap allocations per lookup — return const objects

security requirements

Do not include actual credential values or secrets in registry — only schema definitions

Mark password/apiKey type fields clearly so UI can render them as obscured inputs

Registry must be immutable — expose UnmodifiableListView or const lists only

Execution Context

Execution Tier

Tier 1

Tier 1 - 540 tasks

Can start after Tier 0 completes

Integration Task

Handles integration between different epics or system components. Requires coordination across multiple development streams.

View Full Execution Plan

Implementation Notes

Define an IntegrationType enum with values xledger, dynamics, cornerstone, consio, bufdir — use extension methods to expose the string identifier and displayName. Use a private static const Map _registry inside the class. Make IntegrationTypeMetadata and CredentialFieldDefinition @immutable value objects. Keep the registry in a single file (integration_type_registry.dart) under lib/infrastructure/integrations/.

This class will be consumed by the UI (credential form builder) and by task-010 (field mapping validation), so the public API surface matters — keep it minimal and typed. Avoid dynamic or Map in the public API.

Testing Requirements

Write unit tests using flutter_test. Test: (1) getMetadata() returns correct type for each of the 5 integration types; (2) getMetadata() throws ArgumentError for unknown type; (3) supportedTypes contains exactly the 5 expected identifiers; (4) all CredentialFieldDefinition fields are non-null for required entries; (5) availableMappingTargets is non-empty for each type. No mocking needed — registry is pure Dart with compile-time constants.

Component

Integration Type Registry

infrastructure low

Dependencies (1)

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. epic-external-system-integration-configuration-foundation-task-001

Epic Risks (3)

high impact medium prob technical

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.

high impact low prob security

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.

medium impact medium prob technical

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.

Quick Links

All Tasks Execution Plan