# Technical Constraints and Integration

## Existing Technology Stack

**Languages**: Ruby 3.4.2, JavaScript, Vue.js 3, HTML, CSS
**Frameworks**: Rails 7.x, Shakapacker, Vue 3.3.2, TailwindCSS 3.4.17, DaisyUI 3.9.4
**Database**: SQLite (development), PostgreSQL/MySQL (production)
**Infrastructure**: Docker, Sidekiq for background jobs, Puma web server
**External Dependencies**: AWS S3, Google Cloud Storage, Azure Cloud (optional), SMTP for emails

## Integration Approach

**Database Integration Strategy**:
- Create new tables: `cohorts`, `cohort_enrollments`, `institutions`, `sponsors`, `document_verifications`
- Use foreign keys to link to existing `users`, `submitters`, `submissions` tables
- Maintain existing document relationships through `cohort_enrollments` → `submissions` mapping

**API Integration Strategy**:
- Extend existing DocuSeal API with new endpoints under `/api/v1/cohorts/*`
- Reuse existing authentication (Devise tokens, JWT)
- Leverage existing submission and document APIs for core signing workflows

**Frontend Integration Strategy**:
- Add new Vue components for cohort management
- Extend existing navigation to support role-based portal switching
- Reuse existing DocuSeal form builder and signing form components
- Implement portal-specific dashboards using existing UI patterns

**Testing Integration Strategy**:
- Extend existing RSpec test suite with new model and integration tests
- Add feature tests for all three portal workflows
- Maintain existing test patterns and helpers

## Code Organization and Standards

**File Structure Approach**:
- `app/models/cohort.rb`, `app/models/cohort_enrollment.rb`, etc. (new models)
- `app/controllers/api/v1/cohorts_controller.rb` (API endpoints)
- `app/controllers/cohorts_controller.rb` (web controllers)
- `app/views/cohorts/*` (cohort management views)
- `app/views/cohorts/portal/admin/*` (admin portal views)
- `app/views/cohorts/portal/student/*` (student portal views)
- `app/views/cohorts/portal/sponsor/*` (sponsor portal views)
- `app/javascript/cohorts/*` (Vue components for all portals)
- `app/jobs/cohort_*_job.rb` (background jobs)

**Naming Conventions**:
- Models: `Cohort`, `CohortEnrollment`, `CohortDocumentVerification`
- Controllers: `CohortsController`, `Admin::CohortsController`, `Api::V1::CohortsController`
- Views: `cohorts/index.html.erb`, `cohorts/portal/admin/show.html.erb`
- Vue components: `CohortDashboard.vue`, `StudentPortal.vue`, `SponsorPortal.vue`

**Coding Standards**:
- Follow existing RuboCop configuration
- Follow existing ESLint configuration for Vue components
- Use Rails conventions (fat models, thin controllers)
- Use Vue 3 Composition API for new components
- Maintain existing test coverage patterns

**Documentation Standards**:
- Document all new models with annotations
- Add API endpoint documentation following existing patterns
- Create user guides for each portal
- Update README with new features

## Deployment and Operations

**Build Process Integration**:
- No changes required to existing build process
- New Vue components will be bundled with existing Shakapacker configuration
- New Ruby code will be processed by existing Rails asset pipeline

**Deployment Strategy**:
- Deploy as incremental feature addition to existing DocuSeal deployment
- Use database migrations for new schema
- No infrastructure changes required beyond existing Docker setup

**Monitoring and Logging**:
- Extend existing Rails logging with cohort-specific events
- Add cohort workflow metrics to existing monitoring
- Use existing Sidekiq monitoring for background jobs

**Configuration Management**:
- Use existing environment variable system
- Add new configuration for cohort-specific features (notification templates, etc.)

## Risk Assessment and Mitigation

**Technical Risks**:
- **Risk**: Performance degradation with large cohorts (100+ students)
  - **Mitigation**: Implement pagination, lazy loading, and background processing
  - **Impact**: Medium | **Likelihood**: Medium

- **Risk**: State management complexity leading to race conditions
  - **Mitigation**: Use database transactions and optimistic locking
  - **Impact**: High | **Likelihood**: Low

- **Risk**: Integration conflicts with existing DocuSeal features
  - **Mitigation**: Thorough testing of existing workflows, maintain feature flags
  - **Impact**: High | **Likelihood**: Medium

**Integration Risks**:
- **Risk**: Authentication conflicts between portals and existing DocuSeal
  - **Mitigation**: **⚠️ REQUIRES ARCHITECT REVIEW** - See Winston for authentication strategy
  - **Impact**: High | **Likelihood**: Medium

- **Risk**: Document storage capacity with multiple document types per student
  - **Mitigation**: Monitor storage usage, implement retention policies
  - **Impact**: Medium | **Likelihood**: Low

**Deployment Risks**:
- **Risk**: Database migration failures with large existing datasets
  - **Mitigation**: Test migrations on production-like data, have rollback plan
  - **Impact**: High | **Likelihood**: Low

- **Risk**: User adoption challenges with new portal interfaces
  - **Mitigation**: Comprehensive user training, phased rollout, feedback collection
  - **Impact**: Medium | **Likelihood**: Medium

**Mitigation Strategies**:
1. **Architect Review**: Winston must review authentication, multi-tenancy, and state machine design
2. **Phased Rollout**: Implement one portal at a time (Admin → Student → Sponsor)
3. **Feature Flags**: Allow rollback of individual features without full deployment
4. **Comprehensive Testing**: Unit, integration, and end-to-end tests for all workflows
5. **Performance Testing**: Load test with realistic cohort sizes (50-200 students)
6. **User Acceptance Testing**: Real training institutions testing with actual workflows

---