captthirumalai/vyomsena

Purpose and Entry Points

This is a static, modular aviation operations application covering dashboard, crew, dispatch, flight operations, EFB, FDTL, maintenance, safety, training, weather, reporting, and settings. Browser startup is rooted at index.html, with application orchestration in js/app.js; Firebase initialization is separated in firebase-config.js and js/firebase.js.

Application Shell, Routing, and Module Lifecycle

The client shell appears to load feature modules dynamically through the router and shared module contract. js/router.js determines navigation, shared/routes.js defines route mappings, and shared/BaseModule.js provides a common module lifecycle. Each feature follows a deployable unit pattern: a manifest.js, HTML view, JavaScript controller, and CSS—for example modules/dashboard/manifest.js, modules/dashboard/dashboard.html, and modules/dashboard/dashboard.js.

UI Foundation and Cross-Cutting State

Reusable UI primitives are isolated from business modules: components/Button/button.js, components/Modal/modal.js, and components/Notification/index.js. Global layout, theme, loading, and notification behavior reside in core/layout.js, core/theme.js, core/loader.js, and core/notifications.js. Shared auth and theme state are represented by stores/authStore.js and stores/themeStore.js, while services/eventBus.js likely decouples cross-module events.

Authentication, Authorization, and Organization Boundary

Authentication and user/session handling are centered on js/auth.js, services/authService.js, and stores/authStore.js. Authorization is a distinct service layer via services/permissionService.js; organization/company context is handled through services/organizationService.js and services/companyService.js. This establishes a material tenant/security boundary before operational modules access data. Supporting design and policy references are in docs/permissions.md and docs/firestorerules.md.

Data, Documents, and Firebase Services

Firebase is the primary external platform, with service wrappers separating application code from Firestore and Storage: services/firebaseService.js, services/firestoreService.js, services/storageService.js, and services/documentService.js. Domain records are represented by model files such as models/Flight.js, models/Aircraft.js, and models/UserDocument.js. Crew-document synchronization and upload constraints are specialized concerns in services/crewDocumentSyncService.js and services/uploadLimits.js; Firebase access controls are documented in docs/firestorerules.md and docs/storagerules.md.

Operational Domain Modules

Feature modules own their page rendering and workflows. Crew management is the most decomposed domain, coordinated through modules/crew/crew.js and local state in modules/crew/state.js, with separate directory, profile, document, compliance, linking, bulk, and queue workflows. Flight-time/duty-limit processing is isolated as a service subsystem—services/fdtl/index.js, services/fdtl/fdpEngine.js, and services/fdtl/fatigue.js—and surfaced by modules/fdtl/fdtl.js. Other operational boundaries include dispatch (modules/dispatch/dispatch.js), flight operations (modules/flightops/flightops.js), and maintenance (modules/maintenance/maintenance.js).

Configuration and Documentation

Runtime/application settings are centralized in config/app.config.js and js/config.js. The repository includes architecture and data-contract documentation that should guide changes to the service and module boundaries: docs/architecture.md, docs/database.md, and services/schemaContract.js. A legacy standalone implementation remains under backup_v1/app.js and should not be treated as the current application path without verification.