# Module Dependency Map

Shows build order — each module lists what it *requires to already exist*. This is also the recommended implementation phase order (Phases 1–7 referenced match the roadmap agreed with Hamid).

```
Phase 1 — FOUNDATION (no dependencies)
├── Auth & Identity (roles, permissions, users)
├── Multi-Tenant Core (agencies, TenantScope filter)
└── Settings Module (global config store)

Phase 2 — CORE PROFILES  (depends on: Foundation)
├── Agency Module (registration, verification docs, public profile)
│     depends on: Auth, Settings (verification workflow config)
├── Candidate Module (profile, experience, education, skills, resumes)
│     depends on: Auth
└── Job Categories / Skills master data
      depends on: none (seed data), used by Jobs + Candidate Skills

Phase 3 — HIRING CORE  (depends on: Core Profiles)
├── Job Management
│     depends on: Agency Module, Job Categories
├── Application System
│     depends on: Job Management, Candidate Module
├── ATS System (pipeline, notes, status history)
│     depends on: Application System
├── Search System (candidate + job filters)
│     depends on: Candidate Module, Job Management
│     optional accelerator: Redis for facet caching
└── Resume Database (talent pool, saved searches)
      depends on: Candidate Module, Search System

Phase 4 — MONETIZATION  (depends on: Hiring Core)
├── Subscription System
│     depends on: Agency Module, Settings
├── Credit System
│     depends on: Subscription System (plan-vs-credit interplay), Settings
├── Wallet System
│     depends on: Agency Module
├── Payment System (gateway adapters)
│     depends on: Wallet, Subscription, Credit (all three can trigger a payment)
└── Invoice Module
      depends on: Payment System

Phase 5 — ENGAGEMENT  (depends on: Hiring Core; billing NOT required but credit-gated features need Phase 4)
├── Messaging System
│     depends on: Application System (conversation can link to an application), Credit System (message costs credits)
├── Interview System
│     depends on: Application System
│     integrates with: Zoom API, Google Meet API (external)
└── Notification Engine
      depends on: Settings (SMTP/SMS/WhatsApp config), used by nearly every module above as a consumer

Phase 6 — INTELLIGENCE  (depends on: Engagement + Monetization data existing)
├── Reporting Module (admin + agency reports, exports)
│     depends on: all transactional modules (jobs, applications, payments, credits, wallet)
├── Activity Tracking
│     depends on: nothing structurally, but instrumented into every module's controllers
└── Audit Log System
      depends on: nothing structurally, instrumented into every Service's write methods

Phase 7 — PLATFORM OPS  (depends on: everything above being functional)
├── REST API Layer
│     depends on: all domain modules (wraps them), Auth (JWT)
├── SEO Layer (sitemap, meta, structured data, Google Jobs markup)
│     depends on: Job Management, Agency Module
├── Installation Wizard
│     depends on: entire schema (runs migrations for all modules above)
├── Cron Jobs
│     depends on: Subscription, Credit, Notification, Interview, Reporting modules (each cron calls into that module's service)
└── Security Hardening + Deployment
      depends on: entire application (cross-cutting pass)
```

## Cross-cutting modules (touch everything, built incrementally alongside each phase, not as a separate phase)

- **Auth/RBAC filters** — extended each time a new module adds routes/permissions.
- **Activity Logger** — a single middleware, but its list of tracked actions grows with each module.
- **Notification triggers** — each module registers its own trigger keys into the shared engine.
- **Audit hooks** — each Service class that performs sensitive writes calls `AuditService::log()`.

## Why this order

1. Nothing can be tenant-scoped before tenancy exists → **Foundation first**.
2. Jobs/Applications/ATS are the product's core value and have no billing dependency → build and validate them **before** monetization logic, so billing can be tested against real usage patterns rather than mocks.
3. Messaging/Interviews are **credit-gated**, so Monetization must land before Engagement is fully functional (though their schemas can be built in parallel).
4. Reporting/Audit/Activity are **read-side aggregations** over everything else — building them last avoids reporting against a moving target.
5. Installer, Cron, API, SEO, and Security are **platform-operational concerns** that wrap a functionally-complete system — attempting them first would mean building against modules that don't exist yet.