Enhanced Client Status Workflow - Brownfield User Story

Story Overview

Epic: Client Management Enhancement
Story: Story 2 - Enhanced Client Status Workflow
Story Type: Enhancement (Brownfield)
Priority: High
Estimated Effort: 8 story points

User Story

As a client manager
I want to have enhanced client status workflow with validation rules, history tracking, automated notifications, and audit trails
So that I can efficiently manage client lifecycle states while maintaining compliance, transparency, and integration with document management requirements

Context & Integration

Current System Integration Points:

• Extends existing ClientService (/Users/ayoub/projects/emtb/apps/api/src/client/client.service.ts)
• Leverages existing updateStatus() method and ClientStatus enum (ACTIF, EN_ATTENTE_DOCUMENTS, ARCHIVE)
• Integrates with existing Client Prisma model and relationships
• Connects with Document Management System from Story 1
• Maintains compatibility with Client-Contact-Site-ApporteurAffaire-FacturePartenaire relationships

Existing Functionality to Preserve:

• All CRUD operations (GET /clients, POST /clients, PATCH /clients/:id, DELETE /clients/:id)
• Current status update API (PATCH /clients/:id/status) with same interface
• Reference generation (generateReference() method)
• Client statistics endpoint (GET /clients/stats) with status grouping
• Client lookup by reference (GET /clients/reference/:reference)
• Relationship loading (contact, apporteursAffaires, sites, facturesPartenaires, users)
• Existing status-based business logic throughout the system

Acceptance Criteria

AC1: Status Transition Validation & Business Rules

Given I am managing client status changes
When I attempt to update a client status
Then the system should:

• Validate transition rules: ACTIF ↔ EN_ATTENTE_DOCUMENTS ↔ ARCHIVE
• Prevent invalid direct transitions (ACTIF → ARCHIVE without document validation)
• Allow emergency override transitions with proper justification and elevated permissions
• Validate business rules: active clients must have validated documents, archived clients cannot have pending sites
• Check prerequisite conditions before allowing status changes
• Maintain existing updateStatus() method signature for backward compatibility

AC2: Enhanced Status History Tracking & Audit Trail

Given client status changes occur
When any status transition happens
Then the system should:

• Create comprehensive status history entries with previous status, new status, timestamp, and responsible user
• Track status change reason, business justification, and supporting documentation references
• Log automatic status changes triggered by document validation or system processes
• Store transition validation results and any business rule checks performed
• Maintain permanent audit trail with data integrity controls
• Provide status history API endpoint for reporting and compliance

AC3: Automated Status Change Notifications

Given client status transitions
When a status change occurs
Then the system should:

• Send notifications to assigned users, client managers, and relevant stakeholders
• Support multiple notification channels (email, in-app, webhook)
• Include status transition details, business impact, and required actions
• Handle notification preferences and user subscription management
• Queue notifications for reliable delivery with retry mechanisms
• Provide notification history and delivery confirmation tracking

AC4: Document Management Integration

Given the Document Management System from Story 1
When document-related events occur
Then the system should:

• Automatically transition client to EN_ATTENTE_DOCUMENTS when required documents are missing or expired
• Move client to ACTIF when all required documents are validated and approved
• Prevent status transitions that conflict with document requirements
• Trigger document validation workflows when status changes require compliance checks
• Maintain synchronization between document status and client status
• Log document-driven status changes with clear audit trails

AC5: Status Workflow Configuration & Business Rules

Given different client types and business requirements
When managing status workflows
Then the system should:

• Support configurable status transition rules based on client attributes
• Allow business rule definition for status prerequisites and validation
• Implement role-based permissions for status changes (manager override, admin emergency access)
• Provide status workflow templates for different client categories
• Support temporary status holds with automatic release conditions
• Enable workflow customization without code changes through configuration

AC6: Evolution Tracking & Comprehensive Audit

Given compliance and regulatory requirements
When status workflow operations occur
Then the system should:

• Track all status-related actions with full user context, IP address, and system state
• Maintain immutable audit logs with cryptographic integrity verification
• Record workflow rule evaluations, validation results, and decision rationales
• Log system-driven status changes with complete automation context
• Support audit report generation with regulatory compliance formatting
• Provide audit trail export capabilities for external compliance systems

AC7: Backward Compatibility & System Integration

Given existing client functionality throughout the system
When enhanced status workflow is implemented
Then it should:

• Maintain existing PATCH /clients/:id/status API with identical request/response format
• Preserve existing status enum values and database schema compatibility
• Keep existing client statistics calculation and status-based filtering
• Maintain performance of existing queries with efficient indexing
• Support existing status-dependent business logic in Sites, Reclamations, and Factures
• Ensure seamless integration with ApporteurAffaire and FacturePartenaire workflows

Technical Requirements

Database Schema Changes (Additive Only)

-- Client status history table
CREATE TABLE client_status_history (
  id SERIAL PRIMARY KEY,
  client_id INTEGER NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
  previous_status VARCHAR(30),
  new_status VARCHAR(30) NOT NULL,
  change_reason VARCHAR(200),
  business_justification TEXT,
  changed_by INTEGER REFERENCES users(id),
  changed_at TIMESTAMP DEFAULT NOW(),
  system_triggered BOOLEAN DEFAULT FALSE,
  validation_results JSONB,
  supporting_document_ids INTEGER[],
  approval_required BOOLEAN DEFAULT FALSE,
  approved_by INTEGER REFERENCES users(id),
  approved_at TIMESTAMP,
  created_at TIMESTAMP DEFAULT NOW()
);

-- Status workflow configuration
CREATE TABLE client_status_workflow_rules (
  id SERIAL PRIMARY KEY,
  from_status VARCHAR(30),
  to_status VARCHAR(30) NOT NULL,
  client_type VARCHAR(50),
  requires_approval BOOLEAN DEFAULT FALSE,
  required_role VARCHAR(50),
  prerequisite_conditions JSONB,
  validation_rules JSONB,
  auto_notification BOOLEAN DEFAULT TRUE,
  is_active BOOLEAN DEFAULT TRUE,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW(),
  CONSTRAINT unique_workflow_rule UNIQUE(from_status, to_status, client_type)
);

-- Status change notifications
CREATE TABLE client_status_notifications (
  id SERIAL PRIMARY KEY,
  client_id INTEGER NOT NULL REFERENCES clients(id) ON DELETE CASCADE,
  status_history_id INTEGER REFERENCES client_status_history(id) ON DELETE CASCADE,
  notification_type VARCHAR(50) NOT NULL, -- EMAIL, IN_APP, WEBHOOK
  recipient_user_id INTEGER REFERENCES users(id),
  recipient_email VARCHAR(255),
  webhook_url VARCHAR(500),
  subject VARCHAR(255),
  message TEXT,
  status VARCHAR(30) DEFAULT 'PENDING', -- PENDING, SENT, FAILED, DELIVERED
  sent_at TIMESTAMP,
  delivered_at TIMESTAMP,
  error_message TEXT,
  retry_count INTEGER DEFAULT 0,
  created_at TIMESTAMP DEFAULT NOW()
);

-- Status workflow audit (immutable)
CREATE TABLE client_status_audit (
  id SERIAL PRIMARY KEY,
  client_id INTEGER NOT NULL,
  status_history_id INTEGER,
  event_type VARCHAR(50) NOT NULL, -- STATUS_CHANGE, VALIDATION, NOTIFICATION, RULE_EVALUATION
  event_data JSONB NOT NULL,
  user_context JSONB,
  system_context JSONB,
  ip_address INET,
  user_agent TEXT,
  session_id VARCHAR(100),
  timestamp TIMESTAMP DEFAULT NOW(),
  audit_hash VARCHAR(64) -- For integrity verification
);

-- Indexes for performance
CREATE INDEX idx_client_status_history_client_id ON client_status_history(client_id);
CREATE INDEX idx_client_status_history_changed_at ON client_status_history(changed_at DESC);
CREATE INDEX idx_client_status_history_status ON client_status_history(new_status);
CREATE INDEX idx_client_status_workflow_rules_from_to ON client_status_workflow_rules(from_status, to_status);
CREATE INDEX idx_client_status_notifications_status ON client_status_notifications(status);
CREATE INDEX idx_client_status_notifications_recipient ON client_status_notifications(recipient_user_id);
CREATE INDEX idx_client_status_audit_client_id ON client_status_audit(client_id);
CREATE INDEX idx_client_status_audit_timestamp ON client_status_audit(timestamp DESC);
CREATE INDEX idx_client_status_audit_event_type ON client_status_audit(event_type);

Enhanced API Endpoints (Additive + Backward Compatible)

// Enhanced status management (maintains existing PATCH /clients/:id/status)
PATCH /clients/:id/status - Enhanced with validation, history, and notifications (backward compatible)
GET /clients/:id/status/history - Get status change history
GET /clients/:id/status/transitions - Get available status transitions
POST /clients/:id/status/validate-transition - Validate status change before applying

// Status workflow management
GET /clients/status/workflow-rules - Get status transition rules
POST /clients/status/workflow-rules - Create/update workflow rules
GET /clients/status/statistics - Enhanced statistics with transition metrics
GET /clients/status/audit - Get status workflow audit trail

// Notification management
GET /clients/:id/status/notifications - Get status change notifications
POST /clients/:id/status/notifications/resend - Resend failed notifications
PATCH /clients/notifications/preferences - Update notification preferences

// Bulk operations
POST /clients/status/bulk-update - Bulk status updates with validation
POST /clients/status/bulk-validate - Validate multiple status transitions
GET /clients/status/pending-approvals - Get status changes awaiting approval

// Monitoring and reporting
GET /clients/status/metrics - Status workflow performance metrics
GET /clients/status/compliance-report - Generate compliance audit report
GET /clients/status/workflow-health - System health for status workflows

Service Extensions

// Enhanced ClientService with preserved existing methods
class ClientService {
  // ... existing methods preserved exactly as they are ...
  
  // Enhanced status method (backward compatible)
  async updateStatus(
    id: number, 
    status: ClientStatus, 
    options?: StatusUpdateOptions
  ): Promise<Client> {
    // Maintains existing signature while adding enhanced functionality
    return this.enhancedUpdateStatus(id, status, options);
  }

  // New status workflow methods
  async enhancedUpdateStatus(
    id: number, 
    status: ClientStatus, 
    options?: StatusUpdateOptions
  ): Promise<Client>
  
  async validateStatusTransition(
    clientId: number, 
    fromStatus: ClientStatus, 
    toStatus: ClientStatus
  ): Promise<StatusValidationResult>
  
  async getStatusHistory(clientId: number): Promise<ClientStatusHistory[]>
  async getAvailableTransitions(clientId: number): Promise<StatusTransition[]>
  async createStatusWorkflowRule(rule: WorkflowRuleDto): Promise<WorkflowRule>
  async getStatusStatistics(): Promise<EnhancedStatusStatistics>
  
  // Notification methods
  async sendStatusChangeNotification(statusHistoryId: number): Promise<void>
  async getStatusNotifications(clientId: number): Promise<StatusNotification[]>
  async updateNotificationPreferences(userId: number, preferences: NotificationPreferences): Promise<void>
  
  // Audit and compliance methods
  async getStatusAuditTrail(clientId: number, options?: AuditOptions): Promise<StatusAudit[]>
  async generateComplianceReport(criteria: ComplianceCriteria): Promise<ComplianceReport>
  async validateWorkflowIntegrity(): Promise<WorkflowHealthReport>
}

// Integration with Document Management
interface DocumentStatusIntegration {
  onDocumentValidated(clientId: number, documentId: number): Promise<void>;
  onDocumentExpired(clientId: number, documentId: number): Promise<void>;
  onRequiredDocumentMissing(clientId: number, requiredCategory: string): Promise<void>;
  validateDocumentStatusCompatibility(clientId: number, targetStatus: ClientStatus): Promise<boolean>;
}

Status Workflow Configuration

interface StatusWorkflowConfig {
  transitionRules: {
    [fromStatus: string]: {
      allowedTransitions: ClientStatus[];
      requiresApproval: boolean;
      requiredRole: string[];
      prerequisiteChecks: string[];
      autoNotifications: boolean;
      documentValidationRequired: boolean;
    };
  };
  
  businessRules: {
    preventArchiveWithActiveSites: boolean;
    requireDocumentsForActive: boolean;
    autoTransitionOnDocumentValidation: boolean;
    maxDaysInPendingStatus: number;
  };
  
  notifications: {
    channels: ('EMAIL' | 'IN_APP' | 'WEBHOOK')[];
    templates: Record<string, NotificationTemplate>;
    retryPolicy: {
      maxRetries: number;
      backoffMultiplier: number;
      maxBackoffSeconds: number;
    };
  };
}

Test Automation Requirements

Unit Tests - Status Workflow Validation

describe('ClientStatusWorkflowService', () => {
  // Status transition validation tests
  describe('Status Transition Validation', () => {
    it('should validate allowed status transitions')
    it('should reject invalid status transitions')
    it('should validate business rules before status change')
    it('should check document requirements for status transitions')
    it('should handle emergency override with proper authorization')
    it('should validate prerequisite conditions')
  })

  // Status history tracking tests
  describe('Status History Tracking', () => {
    it('should create status history entry on every status change')
    it('should record user context and system information')
    it('should track automatic vs manual status changes')
    it('should maintain audit integrity with hash verification')
    it('should handle concurrent status changes safely')
  })

  // Notification system tests
  describe('Status Change Notifications', () => {
    it('should send notifications for status changes')
    it('should handle multiple notification channels')
    it('should retry failed notifications with exponential backoff')
    it('should respect user notification preferences')
    it('should queue notifications for reliable delivery')
  })

  // Document integration tests
  describe('Document Status Integration', () => {
    it('should auto-transition to EN_ATTENTE_DOCUMENTS when docs missing')
    it('should transition to ACTIF when all documents validated')
    it('should prevent status changes conflicting with document requirements')
    it('should synchronize document and client status changes')
  })

  // Backward compatibility tests
  describe('Backward Compatibility', () => {
    it('should preserve existing updateStatus method signature')
    it('should maintain existing API response format')
    it('should keep existing status enum behavior')
    it('should preserve client statistics calculation')
  })
})

Integration Tests - Workflow System

describe('Client Status Workflow Integration', () => {
  // Full workflow integration
  describe('Complete Status Workflow', () => {
    it('should handle full client lifecycle with status transitions')
    it('should integrate document validation with status changes')
    it('should maintain transaction integrity during complex workflows')
    it('should handle approval workflows with multiple stakeholders')
    it('should preserve existing client-site-apporteur relationships')
  })

  // Performance and concurrency
  describe('Workflow Performance', () => {
    it('should handle concurrent status changes without conflicts')
    it('should maintain performance with large audit trail data')
    it('should efficiently process bulk status updates')
    it('should handle notification queue processing under load')
  })

  // API integration
  describe('API Integration', () => {
    it('should maintain existing API contracts')
    it('should provide enhanced functionality through new endpoints')
    it('should handle error scenarios gracefully')
    it('should maintain proper HTTP status codes and error formats')
  })
})

End-to-End Tests - Business Workflows

describe('Client Status Workflow E2E', () => {
  // Complete business scenarios
  describe('Business Workflow Scenarios', () => {
    it('should complete client onboarding with document-driven status changes')
    it('should handle client archival with site closure validation')
    it('should manage emergency status overrides with audit trail')
    it('should process bulk client status updates with notifications')
    it('should maintain workflow integrity during system maintenance')
  })

  // Compliance and audit scenarios  
  describe('Compliance Scenarios', () => {
    it('should generate complete audit trail for regulatory compliance')
    it('should handle data retention policies for status history')
    it('should maintain audit integrity under various system conditions')
    it('should support compliance reporting and data export')
  })
})

Performance Tests - System Impact

describe('Status Workflow Performance', () => {
  // Load testing
  describe('System Load Tests', () => {
    it('should handle high volume status changes without performance degradation')
    it('should maintain response times for existing client operations')
    it('should process notification queues efficiently under load')
    it('should handle large audit trail queries with proper pagination')
  })

  // Resource utilization
  describe('Resource Utilization', () => {
    it('should maintain memory efficiency with status history storage')
    it('should optimize database queries for status-related operations')
    it('should handle notification processing without blocking main operations')
    it('should manage audit data growth with proper indexing')
  })
})

Regression Tests - Existing Functionality

describe('Status Workflow Regression Tests', () => {
  // Core functionality preservation
  describe('Existing API Preservation', () => {
    it('should preserve all existing client CRUD operations')
    it('should maintain existing status update API behavior')
    it('should keep client statistics calculation unchanged')
    it('should preserve existing relationship loading patterns')
    it('should maintain existing error handling and validation')
  })

  // System integration preservation
  describe('System Integration Preservation', () => {
    it('should maintain existing site-client status relationships')
    it('should preserve apporteur-affaire integration with client status')
    it('should keep facture-partenaire workflows unchanged')
    it('should maintain existing user permissions and access controls')
  })
})

Monitoring & Alerting Test Scenarios

describe('Status Workflow Monitoring', () => {
  // Workflow failure detection
  describe('Failure Detection', () => {
    it('should alert on status transition validation failures')
    it('should detect notification delivery failures')
    it('should monitor workflow rule configuration issues')
    it('should alert on audit integrity violations')
  })

  // Performance monitoring
  describe('Performance Monitoring', () => {
    it('should track status change processing times')
    it('should monitor notification queue depth and processing rates')
    it('should alert on excessive audit trail growth')
    it('should monitor database performance for status operations')
  })

  // Business metrics
  describe('Business Metrics', () => {
    it('should track status transition patterns and trends')
    it('should monitor client lifecycle duration metrics')
    it('should alert on unusual status change patterns')
    it('should track compliance reporting metrics')
  })
})

Change Tracking & Evolution

Version History

• v2.0.0: Enhanced Client Status Workflow implementation with full audit trail
• v2.1.0: Document Management System integration (dependent on Story 1)
• v2.2.0: Advanced notification system with multiple channels
• Track all schema changes with migration versioning
• Document API version compatibility matrix for status endpoints

Monitoring & Metrics

interface StatusWorkflowMetrics {
  // Core metrics
  statusTransitionsPerDay: number;
  averageTransitionTime: number;
  validationFailureRate: number;
  
  // Notification metrics
  notificationsSent: number;
  notificationDeliveryRate: number;
  averageNotificationDelay: number;
  
  // Audit and compliance metrics
  auditTrailSize: number;
  auditIntegrityViolations: number;
  complianceReportsGenerated: number;
  
  // Performance metrics
  statusQueryPerformance: number;
  workflowProcessingTime: number;
  concurrentTransactionConflicts: number;
  
  // Business metrics
  clientsInEachStatus: Record<ClientStatus, number>;
  averageStatusDuration: Record<ClientStatus, number>;
  emergencyOverrideUsage: number;
}

Configuration Management

interface StatusWorkflowConfiguration {
  // Workflow rules
  transitionValidation: {
    enabled: boolean;
    strictMode: boolean;
    allowEmergencyOverride: boolean;
    requireApprovalForCriticalTransitions: boolean;
  };
  
  // Notification settings
  notifications: {
    enabled: boolean;
    channels: NotificationChannel[];
    retryPolicy: RetryPolicy;
    templateCustomization: boolean;
  };
  
  // Audit configuration
  audit: {
    enabled: boolean;
    integrityVerification: boolean;
    retentionPeriodDays: number;
    compressionEnabled: boolean;
  };
  
  // Performance settings
  performance: {
    batchSize: number;
    maxConcurrentTransitions: number;
    auditQueryPagination: number;
    notificationQueueSize: number;
  };
  
  // Document integration
  documentIntegration: {
    enabled: boolean;
    autoStatusTransition: boolean;
    documentValidationTimeout: number;
    requireDocumentsForActiveStatus: boolean;
  };
}

Monitoring & Alerting Configuration

interface StatusWorkflowAlerting {
  // Critical alerts
  criticalAlerts: {
    auditIntegrityFailure: AlertConfig;
    massStatusTransitionFailure: AlertConfig;
    notificationSystemDown: AlertConfig;
    workflowRuleViolation: AlertConfig;
  };
  
  // Warning alerts
  warningAlerts: {
    highNotificationFailureRate: AlertConfig;
    slowStatusTransitions: AlertConfig;
    unusualStatusPatterns: AlertConfig;
    auditTrailGrowth: AlertConfig;
  };
  
  // Business alerts
  businessAlerts: {
    clientsStuckInPendingStatus: AlertConfig;
    highEmergencyOverrideUsage: AlertConfig;
    complianceReportingIssues: AlertConfig;
    documentStatusMismatch: AlertConfig;
  };
}

interface AlertConfig {
  enabled: boolean;
  threshold: number;
  escalationLevels: string[];
  channels: ('email' | 'slack' | 'webhook')[];
  suppressionPeriodMinutes: number;
}

Definition of Done

Functional Requirements

• Enhanced status transition validation with business rules working correctly
• Complete status history tracking and audit trail implemented
• Automated notification system operational with multi-channel support
• Document Management System integration functional (dependent on Story 1)
• Workflow configuration system allowing business rule customization
• Emergency override functionality with proper audit trail
• Bulk operations with validation and transaction integrity

Technical Requirements

• Database migrations applied and tested (additive only)
• Enhanced API endpoints documented in Swagger with backward compatibility
• Status workflow configuration system implemented
• Notification queue and delivery system operational
• Audit logging with integrity verification configured
• Performance optimizations implemented (indexing, query optimization)

Quality Assurance

• Unit test coverage ≥ 95% for status workflow functionality
• Integration tests verify complete workflow scenarios
• End-to-end tests cover business workflow scenarios
• Performance tests confirm no degradation in existing operations
• Regression tests verify existing functionality preservation
• Security audit passed for workflow and notification systems

Compatibility Verification

• Existing PATCH /clients/:id/status API maintains identical interface
• All existing client API endpoints return same response format
• Client statistics calculation includes enhanced status metrics
• Existing client-site-apporteur-facture relationships preserved
• Reference generation and lookup functionality intact
• Status-dependent business logic throughout system unchanged

Documentation

• Enhanced API documentation updated in Swagger
• Status workflow configuration guide created
• Audit trail and compliance reporting documentation
• Notification system configuration and troubleshooting guide
• Performance monitoring and alerting documentation
• Migration guide for existing status-dependent integrations

Monitoring & Alerting

• Status workflow monitoring dashboards implemented
• Alerting configured for workflow failures and performance issues
• Business metrics tracking operational
• Audit integrity monitoring active
• Notification system health monitoring configured
• Performance metrics collection and analysis ready

Risk Mitigation

Primary Risks & Mitigations

1. Breaking Existing Status-Dependent Functionality Risk

   • Impact: High - Status is used throughout the system for business logic
   • Mitigation: Backward compatible API, comprehensive regression testing, feature flags for new functionality
   • Detection: Automated integration tests, canary deployments

2. Performance Degradation Risk

   • Impact: Medium - Additional audit and history tracking could slow operations
   • Mitigation: Efficient indexing, asynchronous notification processing, optimized queries
   • Detection: Performance monitoring, load testing, query analysis

3. Data Integrity Risk for Audit Trail

   • Impact: High - Compliance requirements depend on audit integrity
   • Mitigation: Immutable audit tables, cryptographic hashing, transaction integrity
   • Detection: Automated integrity verification, audit trail validation

4. Notification System Reliability Risk

   • Impact: Medium - Critical status changes need reliable notification delivery
   • Mitigation: Retry mechanisms, multiple channels, monitoring and alerting
   • Detection: Delivery confirmation tracking, failure rate monitoring

5. Complex Workflow Configuration Risk

   • Impact: Medium - Overly complex rules could lead to unexpected behavior
   • Mitigation: Validation of workflow rules, testing framework, gradual rollout
   • Detection: Workflow rule testing, business logic validation

Rollback Strategy

1. Database Rollback

   • All migrations are reversible with data preservation
   • Status history and audit data can be archived before rollback
   • Core client status functionality isolated from enhanced features

2. API Rollback

   • Enhanced endpoints can be disabled via feature flags
   • Existing status update API remains fully functional
   • Notification system can be disabled without affecting core operations

3. Configuration Rollback

   • Workflow rules can be reverted to default simple transitions
   • Notification preferences can be reset to system defaults
   • Audit configuration can be simplified without data loss

4. Graceful Degradation

   • System can operate with basic status transitions if enhanced features fail
   • Existing client operations remain fully functional
   • Document integration can be temporarily disabled

Dependencies

Internal Dependencies

• Story 1: Document Management System (for document-status integration)
• Existing Client module structure and service methods
• User authentication and authorization system
• Audit logging infrastructure
• Configuration management system

External Dependencies

• Email service provider for notifications (SMTP/SendGrid/etc.)
• Message queue system for notification delivery (Redis/RabbitMQ)
• Monitoring and alerting infrastructure (Prometheus/Grafana)
• Webhook delivery system for external integrations
• Cryptographic library for audit hash generation

System Integration Dependencies

• Site status workflow (ensuring compatibility with site lifecycle)
• Reclamation processing (status-dependent business logic)
• Facture generation (client status validation)
• ApporteurAffaire commission processing (status-dependent)
• User management (role-based workflow permissions)

---

Story Status: Ready for Implementation (Dependent on Story 1 completion)
Last Updated: 2025-09-09
Reviewed By: Technical Lead
Approved By: Product Owner
Dependencies: Document Management System (Story 1) - 80% integration points