Skip to main content

๐Ÿค– AI Context Guide - Uptime Watcher (Comprehensive)

Complete AI Onboarding: This document provides exhaustive context for AI assistants to understand and work effectively with the Uptime Watcher codebase at every level.

๐Ÿ“‹ Project Overview & Missionโ€‹

Uptime Watcher is a sophisticated Electron desktop application for monitoring website uptime with real-time updates, response time tracking, and historical data visualization.

Core Purpose & Capabilitiesโ€‹

  • Multi-Service Monitoring: HTTP, port connectivity, and ping monitoring
  • Real-Time Status Updates: Live status changes with visual feedback
  • Historical Data Tracking: Comprehensive uptime history and response times
  • Advanced Notifications: Desktop notifications and sound alerts
  • Comprehensive Configuration: Per-monitor settings and global preferences
  • Data Management: Export/import functionality with SQLite database
  • Auto-Updates: Built-in update mechanism with restart coordination

Project Metadataโ€‹

๐Ÿ—๏ธ Technology Stack (COMPLETE)โ€‹

Frontend Stackโ€‹

Framework: React 18+ with TypeScript
Styling: Tailwind CSS + Custom Theme System
State Management: Zustand (modular stores)
Build Tool: Vite 5.4+
Development: Hot reload with React DevTools
Icons: React Icons (Heroicons, Lucide)
Charts: Chart.js with React-Chartjs-2

Desktop Frameworkโ€‹

Platform: Electron 32+ (main + renderer processes)
Security: Context isolation + preload scripts
Process Communication: IPC with typed safety
File System: Node.js APIs in main process
Native Features: System tray, notifications, auto-updater

Backend/Data Layerโ€‹

Database: SQLite with node-sqlite3-wasm
ORM Pattern: Custom repository pattern
Transactions: Automatic transaction wrapping
Migration: Built-in schema migration system
Backup: Export/import functionality

Development & Qualityโ€‹

Testing: Vitest (dual config: frontend + electron)
Type Checking: TypeScript 5.6+ (strict mode)
Linting: ESLint + Prettier + Biome
Code Quality: Cognitive complexity analysis
Documentation: TypeDoc + TSDoc standards
Coverage: Codecov integration with dual reporting

Build & Distributionโ€‹

Build: Vite + TypeScript compilation
Packaging: Electron Builder
Platform Support: Windows, macOS, Linux
Auto-Updates: electron-updater integration
Assets: Static file copying for WASM

๐Ÿ“ Complete Directory Structureโ€‹

Uptime-Watcher/
โ”œโ”€โ”€ ๐Ÿ“ฆ Root Configuration
โ”‚ โ”œโ”€โ”€ package.json # Dependencies, scripts, metadata
โ”‚ โ”œโ”€โ”€ vite.config.ts # Vite build configuration
โ”‚ โ”œโ”€โ”€ tsconfig.json # Frontend TypeScript config
โ”‚ โ”œโ”€โ”€ tsconfig.electron.json # Backend TypeScript config
โ”‚ โ”œโ”€โ”€ vitest.config.ts # Frontend test configuration
โ”‚ โ”œโ”€โ”€ vitest.electron.config.ts # Backend test configuration (moved to config/testing/)
โ”‚ โ”œโ”€โ”€ eslint.config.mjs # ESLint configuration
โ”‚ โ”œโ”€โ”€ tailwind.config.mjs # Tailwind CSS configuration
โ”‚ โ””โ”€โ”€ .env # Environment variables
โ”‚
โ”œโ”€โ”€ ๐Ÿ–ฅ๏ธ electron/ (Main Process - Node.js)
โ”‚ โ”œโ”€โ”€ main.ts # Application entry point
โ”‚ โ”œโ”€โ”€ preload.ts # IPC bridge & security layer
โ”‚ โ”œโ”€โ”€ constants.ts # Electron-specific constants
โ”‚ โ”œโ”€โ”€ electronUtils.ts # Electron utility functions
โ”‚ โ”œโ”€โ”€ types.ts # Electron-specific types
โ”‚ โ”œโ”€โ”€ UptimeOrchestrator.ts # Main application orchestrator
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐ŸŽฏ events/ # Event system
โ”‚ โ”‚ โ”œโ”€โ”€ eventTypes.ts # Complete event type definitions
โ”‚ โ”‚ โ””โ”€โ”€ TypedEventBus.ts # Type-safe event bus implementation
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ‘” managers/ # High-level business orchestrators
โ”‚ โ”‚ โ”œโ”€โ”€ ConfigurationManager.ts # App configuration management
โ”‚ โ”‚ โ”œโ”€โ”€ DatabaseManager.ts # Database lifecycle management
โ”‚ โ”‚ โ”œโ”€โ”€ MonitorManager.ts # Monitoring orchestration
โ”‚ โ”‚ โ””โ”€โ”€ SiteManager.ts # Site operations orchestration
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ”ง services/ # Service-oriented architecture
โ”‚ โ”‚ โ”œโ”€โ”€ ServiceContainer.ts # Dependency injection container
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ“Š application/ # Core application services
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ ApplicationService.ts # Main app lifecycle service
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ’พ database/ # Data persistence layer
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ DatabaseService.ts # Core database operations
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ HistoryRepository.ts # Status history data
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorRepository.ts # Monitor configuration data
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SettingsRepository.ts # Application settings data
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteRepository.ts # Site configuration data
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ utils/ # Database utilities
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ”Œ ipc/ # Inter-process communication
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ IpcService.ts # Main IPC handler service
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ types.ts # IPC message types
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ utils.ts # IPC utility functions
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ validators.ts # IPC message validation
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ“ก monitoring/ # Monitoring system
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ EnhancedMonitorChecker.ts # Main monitoring engine
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ EnhancedMonitoringServiceFactory.ts # Service factory
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ HttpMonitor.ts # HTTP monitoring service
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ PingMonitor.ts # Ping monitoring service
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ PortMonitor.ts # Port monitoring service
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorFactory.ts # Monitor service factory
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorScheduler.ts # Scheduled monitoring
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorOperationRegistry.ts # Race condition prevention
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorStatusUpdateService.ts # Status update handling
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ OperationTimeoutManager.ts # Timeout management
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ MonitorTypeRegistry.ts # Monitor type registration
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ constants.ts # Monitoring constants
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ types.ts # Monitoring type definitions
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ utils/ # Monitoring utilities
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ”” notifications/ # System notifications
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ NotificationService.ts # Desktop notification service
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐ŸŒ site/ # Site management services
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ SiteService.ts # Site business logic
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ๐Ÿ”„ updater/ # Auto-update functionality
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ AutoUpdaterService.ts # Update management
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ””โ”€โ”€ ๐ŸชŸ window/ # Window management
โ”‚ โ”‚ โ””โ”€โ”€ WindowService.ts # Electron window handling
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ› ๏ธ utils/ # Shared utilities
โ”‚ โ”‚ โ”œโ”€โ”€ logger.ts # Logging infrastructure
โ”‚ โ”‚ โ”œโ”€โ”€ cache/ # Caching utilities
โ”‚ โ”‚ โ”œโ”€โ”€ monitoring/ # Monitoring helper functions
โ”‚ โ”‚ โ””โ”€โ”€ operationalHooks.ts # Database operation hooks
โ”‚ โ”‚
โ”‚ โ””โ”€โ”€ โœ… test/ # Backend tests
โ”‚ โ”œโ”€โ”€ setup.ts # Test environment setup
โ”‚ โ””โ”€โ”€ **/*.test.ts # Test files
โ”‚
โ”œโ”€โ”€ ๐ŸŽจ src/ (Renderer Process - React)
โ”‚ โ”œโ”€โ”€ main.tsx # React application entry point
โ”‚ โ”œโ”€โ”€ App.tsx # Main App component
โ”‚ โ”œโ”€โ”€ index.css # Global styles
โ”‚ โ”œโ”€โ”€ constants.ts # Frontend constants
โ”‚ โ”œโ”€โ”€ types.ts # Frontend-specific types
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿงฉ components/ # React component tree
โ”‚ โ”‚ โ”œโ”€โ”€ AddSiteForm/ # Site creation forms
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ AddSiteModal.tsx # Modal wrapper
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ AddSiteForm.tsx # Main form component
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Form sub-components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ Dashboard/ # Main dashboard interface
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteList/ # Site listing components
โ”‚ โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteList.tsx # Main list component
โ”‚ โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # List sub-components
โ”‚ โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ SiteCard/ # Individual site cards
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteCard.tsx # Main card component
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteCardHeader.tsx # Card header
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Card sub-components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ Header/ # Application header
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ Header.tsx # Main header component
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Header sub-components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ Settings/ # Settings interface
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ Settings.tsx # Main settings component
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Settings sub-components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ SiteDetails/ # Site detail views
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ SiteDetails.tsx # Main details component
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Details sub-components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ common/ # Reusable components
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Shared UI components
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ””โ”€โ”€ error/ # Error handling components
โ”‚ โ”‚ โ””โ”€โ”€ **/*.tsx # Error boundary components
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐ŸŽฃ hooks/ # Custom React hooks
โ”‚ โ”‚ โ”œโ”€โ”€ useBackendFocusSync.ts # Backend focus synchronization
โ”‚ โ”‚ โ”œโ”€โ”€ useSelectedSite.ts # Site selection management
โ”‚ โ”‚ โ””โ”€โ”€ **/*.ts # Additional custom hooks
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿช stores/ # Zustand state management
โ”‚ โ”‚ โ”œโ”€โ”€ types.ts # Store type definitions
โ”‚ โ”‚ โ”œโ”€โ”€ utils.ts # Store utility functions
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ error/ # Error state management
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useErrorStore.ts # Error handling store
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ ErrorBoundary.tsx # React error boundary
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ monitor/ # Monitor type management
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ useMonitorTypesStore.ts # Monitor type configuration
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ settings/ # Application settings
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSettingsStore.ts # Settings state management
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ types.ts # Settings type definitions
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ sites/ # Site and monitoring data
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSitesStore.ts # Main sites store (modular)
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSitesState.ts # Core state management
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSiteOperations.ts # CRUD operations
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSiteMonitoring.ts # Monitoring lifecycle
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ useSiteSync.ts # Backend synchronization
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ types.ts # Site store types
โ”‚ โ”‚ โ”‚ โ”œโ”€โ”€ services/ # Site services
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ utils/ # Site utilities
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ”œโ”€โ”€ ui/ # UI state management
โ”‚ โ”‚ โ”‚ โ””โ”€โ”€ useUiStore.ts # UI state (modals, views)
โ”‚ โ”‚ โ”‚
โ”‚ โ”‚ โ””โ”€โ”€ updates/ # Update management
โ”‚ โ”‚ โ”œโ”€โ”€ useUpdatesStore.ts # Update state management
โ”‚ โ”‚ โ””โ”€โ”€ types.ts # Update type definitions
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐ŸŽจ theme/ # Theming system
โ”‚ โ”‚ โ”œโ”€โ”€ components.tsx # Themed component library
โ”‚ โ”‚ โ”œโ”€โ”€ types.ts # Theme type definitions
โ”‚ โ”‚ โ””โ”€โ”€ useTheme.ts # Theme management hook
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ› ๏ธ utils/ # Frontend utilities
โ”‚ โ”‚ โ”œโ”€โ”€ cacheSync.ts # Cache synchronization
โ”‚ โ”‚ โ””โ”€โ”€ **/*.ts # Additional utilities
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ”ง services/ # Frontend services
โ”‚ โ”‚ โ”œโ”€โ”€ logger.ts # Frontend logging
โ”‚ โ”‚ โ””โ”€โ”€ **/*.ts # Additional services
โ”‚ โ”‚
โ”‚ โ””โ”€โ”€ โœ… test/ # Frontend tests
โ”‚ โ”œโ”€โ”€ setup.ts # Test environment setup
โ”‚ โ””โ”€โ”€ **/*.test.tsx # Test files
โ”‚
โ”œโ”€โ”€ ๐Ÿค shared/ # Common code (frontend + backend)
โ”‚ โ”œโ”€โ”€ types.ts # Core domain types
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ“Š types/ # Shared type definitions
โ”‚ โ”‚ โ””โ”€โ”€ events.ts # Event type definitions
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ ๐Ÿ› ๏ธ utils/ # Shared utilities
โ”‚ โ”‚ โ”œโ”€โ”€ environment.ts # Environment detection
โ”‚ โ”‚ โ””โ”€โ”€ errorHandling.ts # Shared error handling
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ โœ… validation/ # Shared validation
โ”‚ โ”‚ โ”œโ”€โ”€ schemas.ts # Zod validation schemas
โ”‚ โ”‚ โ””โ”€โ”€ validatorUtils.ts # Validation utilities
โ”‚ โ”‚
โ”‚ โ””โ”€โ”€ โœ… test/ # Shared test utilities
โ”‚ โ””โ”€โ”€ **/*.ts # Shared test helpers
โ”‚
โ”œโ”€โ”€ ๐Ÿ“š docs/ # Comprehensive documentation
โ”‚ โ”œโ”€โ”€ AI-CONTEXT.md # This document
โ”‚ โ”œโ”€โ”€ DEVELOPER-QUICK-START.md # Quick start guide
โ”‚ โ”œโ”€โ”€ API-DOCUMENTATION.md # API reference
โ”‚ โ”œโ”€โ”€ TROUBLESHOOTING.md # Debug guide
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ Architecture/ # Architecture documentation
โ”‚ โ”‚ โ”œโ”€โ”€ ADRs/ # Architecture Decision Records
โ”‚ โ”‚ โ”œโ”€โ”€ Patterns/ # Development patterns
โ”‚ โ”‚ โ””โ”€โ”€ Templates/ # Code templates
โ”‚ โ”‚
โ”‚ โ”œโ”€โ”€ Guides/ # Implementation guides
โ”‚ โ”‚ โ”œโ”€โ”€ NEW_MONITOR_TYPE_IMPLEMENTATION.md
โ”‚ โ”‚ โ”œโ”€โ”€ UI-Feature-Development-Guide.md
โ”‚ โ”‚ โ”œโ”€โ”€ TESTING.md
โ”‚ โ”‚ โ””โ”€โ”€ **/*.md # Additional guides
โ”‚ โ”‚
โ”‚ โ””โ”€โ”€ Archive/ # Historical documentation
โ”‚
โ”œโ”€โ”€ ๐Ÿ—๏ธ assets/ # Static assets
โ”‚ โ””โ”€โ”€ node-sqlite3-wasm.wasm # SQLite WebAssembly binary
โ”‚
โ”œโ”€โ”€ ๐Ÿ–ผ๏ธ icons/ # Application icons
โ”‚ โ””โ”€โ”€ **/*.png # Icon files for different platforms
โ”‚
โ”œโ”€โ”€ ๐Ÿ“ฆ release/ # Build outputs
โ”œโ”€โ”€ ๐Ÿ“Š coverage/ # Test coverage reports
โ””โ”€โ”€ ๐Ÿ› ๏ธ dist-electron/ # Compiled Electron code

๐ŸŽฏ Core Architectural Patternsโ€‹

1. Service Container Pattern (Dependency Injection)โ€‹

Location: electron/services/ServiceContainer.ts

export class ServiceContainer {
private static instance: ServiceContainer | undefined;

// Service Categories:
// - Core Services: Infrastructure (Database, IPC, Events)
// - Application Services: Business orchestrators (Managers)
// - Feature Services: Domain functionality (Monitoring, Notifications)
// - Utility Services: Support functions (Window, Updater)

public getDatabaseService(): DatabaseService {
/* ... */
}
public getMonitorManager(): MonitorManager {
/* ... */
}
public getSiteManager(): SiteManager {
/* ... */
}
// ... all services accessible via getters
}

Service Categories:

  • Core Services: DatabaseService, IpcService, TypedEventBus
  • Application Services: ApplicationService, managers
  • Feature Services: MonitoringServices, NotificationService
  • Utility Services: WindowService, AutoUpdaterService

2. Repository Pattern (Database Access)โ€‹

All database access through repositories with dual method patterns:

// Public async methods (create transactions)
async addSite(site: Site): Promise<Site>
async updateSite(id: string, updates: Partial<Site>): Promise<void>

// Internal sync methods (within existing transactions)
addSiteSync(site: Site, db: Database): Site
updateSiteSync(id: string, updates: Partial<Site>, db: Database): void

Transaction Safety: All mutations wrapped in executeTransaction()

Repositories:

  • SiteRepository - Site configuration and metadata
  • MonitorRepository - Monitor configurations
  • HistoryRepository - Status history and metrics
  • SettingsRepository - Application preferences

3. Event-Driven Communicationโ€‹

TypedEventBus: electron/events/TypedEventBus.ts

interface UptimeEvents {
"monitor:status-updated": MonitorStatusUpdateEventData;
"site:monitoring-started": SiteMonitoringStartedEventData;
"database:operation-completed": DatabaseOperationEventData;
// ... 50+ typed events
}

// Type-safe event emission
eventBus.emit("monitor:status-updated", {
siteId: "site-123",
monitorId: "monitor-456",
oldStatus: "up",
newStatus: "down",
// ... automatic metadata injection
});

Event Categories: database, monitoring, system, ui

Automatic Metadata: Correlation IDs, timestamps, environment context

4. Manager Pattern (Business Orchestration)โ€‹

High-level orchestrators for complex business logic:

  • SiteManager: Site CRUD, validation, event coordination
  • MonitorManager: Monitoring lifecycle, scheduling, status updates
  • DatabaseManager: Schema migrations, backup/restore
  • ConfigurationManager: Settings management, validation

5. Enhanced Monitoring Systemโ€‹

Unified Architecture (no fallback systems):

// Operation Correlation for Race Condition Prevention
interface MonitorCheckOperation {
id: string; // UUID-based operation tracking
monitorId: string;
initiatedAt: Date;
cancelled: boolean;
}

// Enhanced monitoring components:
// - EnhancedMonitorChecker: Main monitoring engine
// - MonitorOperationRegistry: Operation correlation
// - MonitorStatusUpdateService: Safe status updates
// - OperationTimeoutManager: Timeout handling

6. Modular State Management (Zustand)โ€‹

Domain-specific stores with dependency injection:

export const useSitesStore = create<SitesStore>()((set, get) => {
// Modular composition
const stateActions = createSitesStateActions(set, get);
const syncActions = createSiteSyncActions({
/* deps */
});
const monitoringActions = createSiteMonitoringActions();
const operationsActions = createSiteOperationsActions({
/* deps */
});

return {
...initialSitesState,
...stateActions, // Core state management
...operationsActions, // CRUD operations
...monitoringActions, // Monitoring lifecycle
...syncActions, // Backend synchronization
};
});

Store Modules:

  • State Module: Core data manipulation
  • Operations Module: CRUD operations
  • Monitoring Module: Monitoring lifecycle
  • Sync Module: Backend synchronization

๐Ÿ’ป Development Conventions & Standardsโ€‹

TypeScript Configuration (Ultra-Strict)โ€‹

{
"compilerOptions": {
"strict": true, // All strict flags enabled
"exactOptionalPropertyTypes": true, // Exact optional properties
"noUncheckedIndexedAccess": true, // Safe array/object access
"noImplicitReturns": true, // All code paths return
"noUnusedLocals": true, // No unused variables
"noUnusedParameters": true, // No unused parameters
"isolatedModules": true, // Module isolation
"isolatedDeclarations": true, // Declaration isolation
// ... comprehensive strict configuration
},
}

Type Safety Rules:

  • โŒ No any, unknown, null, undefined when avoidable
  • โœ… Interface-first design for all IPC and events
  • โœ… Strict union types and discriminated unions
  • โœ… Comprehensive TSDoc documentation

Error Handling Patternโ€‹

Shared withErrorHandling Utility (shared/utils/errorHandling.ts):

// Frontend usage (with store integration)
await withErrorHandling(
async () => {
const result = await window.electronAPI.sites.addSite(siteData);
return result;
},
{
clearError: () => errorStore.clearStoreError("sites"),
setError: (error) => errorStore.setStoreError("sites", error),
setLoading: (loading) =>
errorStore.setOperationLoading("addSite", loading),
}
);

// Backend usage (with logging)
await withErrorHandling(
async () => {
return await this.repository.performOperation();
},
{
logger: logger,
operationName: "performOperation",
}
);

Validation Systemโ€‹

Shared Zod Schemas (shared/validation/schemas.ts):

export const baseMonitorSchema = z.object({
id: z.string().min(1),
type: z.enum([
"http",
"port",
"ping",
]),
status: z.enum([
"up",
"down",
"pending",
"paused",
]),
monitoring: z.boolean(),
checkInterval: z.number().min(5000).max(2_592_000_000), // 5s to 30 days
timeout: z.number().min(1000).max(300_000), // 1s to 5min
retryAttempts: z.number().min(0).max(10),
responseTime: z.number().min(-1), // -1 = never checked
lastChecked: z.date().optional(),
});

export const httpMonitorSchema = baseMonitorSchema.extend({
type: z.literal("http"),
url: z.string().refine((val) =>
validator.isURL(val, {
protocols: ["http", "https"],
require_protocol: true,
require_tld: true,
// ... comprehensive URL validation
})
),
});

Validation Utilities (shared/validation/validatorUtils.ts):

  • Consistent validation across frontend/backend
  • Security-focused patterns using validator.js
  • Type-safe validation with automatic TypeScript inference

Database Operation Patternsโ€‹

Repository Methods:

// Transaction-creating async methods (public API)
public async addSite(site: Site): Promise<Site> {
return this.databaseService.executeTransaction(async (db) => {
return this.addSiteSync(site, db);
});
}

// Sync methods for use within transactions (internal)
public addSiteSync(site: Site, db: Database): Site {
// Direct database operations within existing transaction
const statement = db.prepare(ADD_SITE_SQL);
const result = statement.run(siteData);
return { ...site, id: result.lastInsertRowid as string };
}

Event Emission: All database operations emit lifecycle events

IPC Communication Patternโ€‹

Type-Safe IPC (electron/preload.ts):

// Organized by functional domains
const electronAPI = {
sites: {
addSite: (site: Site) => ipcRenderer.invoke("add-site", site),
getSites: () => ipcRenderer.invoke("get-sites"),
updateSite: (id: string, updates: Partial<Site>) =>
ipcRenderer.invoke("update-site", id, updates),
// ... all site operations
},
monitoring: {
startMonitoring: () => ipcRenderer.invoke("start-monitoring"),
stopMonitoring: () => ipcRenderer.invoke("stop-monitoring"),
checkSiteNow: (siteId: string, monitorId: string) =>
ipcRenderer.invoke("check-site-now", siteId, monitorId),
// ... all monitoring operations
},
// ... other domains
};

IPC Handlers (electron/services/ipc/IpcService.ts):

  • Standardized registration with validators
  • Comprehensive error handling and logging
  • Type-safe message contracts

๐Ÿ”ง Critical Components Deep Diveโ€‹

MonitorCheckResult Interface (CURRENT)โ€‹

export interface MonitorCheckResult {
/** Optional human-readable details about the check result */
details?: string;

/** Optional error message if the check failed */
error?: string;

/** Response time in milliseconds (REQUIRED) */
responseTime: number;

/** Status outcome of the check (REQUIRED) */
status: "up" | "down";
}

Critical Notes:

  • responseTime is REQUIRED (not optional as some docs claim)
  • details should be populated for proper history tracking
  • Return status: "up" | "down" only (not "pending" or "paused")

Enhanced Monitoring Componentsโ€‹

Core Services:

  1. EnhancedMonitorChecker - Main monitoring engine

    • Operation correlation with UUID tracking
    • Race condition prevention
    • Advanced timeout management
    • Status update validation
  2. MonitorOperationRegistry - Operation tracking

    • UUID-based operation IDs with collision prevention
    • Active operation management per monitor
    • Automatic cleanup on completion/timeout
  3. MonitorStatusUpdateService - Safe status updates

    • Validates monitoring state before updates
    • Operation correlation prevents conflicting updates
    • Database transaction safety
  4. OperationTimeoutManager - Timeout handling

    • Buffer-based timeout management
    • Resource leak prevention
    • Automatic operation cancellation

Service Container Detailsโ€‹

Service Registration Categories:

// Core infrastructure services
private getDatabaseService(): DatabaseService
private getEventBus(): TypedEventBus<UptimeEvents>
private getIpcService(): IpcService

// Repository layer
private getHistoryRepository(): HistoryRepository
private getMonitorRepository(): MonitorRepository
private getSettingsRepository(): SettingsRepository
private getSiteRepository(): SiteRepository

// Business logic managers
public getConfigurationManager(): ConfigurationManager
public getDatabaseManager(): DatabaseManager
public getMonitorManager(): MonitorManager
public getSiteManager(): SiteManager

// Feature services
public getEnhancedMonitoringServices(): EnhancedMonitoringServices
public getNotificationService(): NotificationService
public getSiteService(): SiteService

// Utility services
public getAutoUpdaterService(): AutoUpdaterService
public getWindowService(): WindowService

Initialization Order: Infrastructure โ†’ Repositories โ†’ Managers โ†’ Features โ†’ Utilities

Complete Store Architectureโ€‹

Store Organization:

  1. useSitesStore (Modular Composition)

    • useSitesState - Core state management
    • useSiteOperations - CRUD operations with error handling
    • useSiteMonitoring - Monitoring lifecycle management
    • useSiteSync - Backend synchronization
  2. useSettingsStore - Application preferences

    • Theme management, notification settings
    • History limits, auto-start configuration
    • Persistent storage sync
  3. useErrorStore - Global error management

    • Store-specific error isolation
    • Operation-level error tracking
    • Automatic error clearing
  4. useUiStore - UI state management

    • Modal visibility, active views
    • Loading states, user interactions
  5. useUpdatesStore - Auto-update management

    • Update availability, download progress
    • Installation coordination

Event System Complete Referenceโ€‹

Event Categories & Examples:

interface UptimeEvents {
// Database Events
"database:operation-started": DatabaseOperationStartedEventData;
"database:operation-completed": DatabaseOperationCompletedEventData;
"database:migration-started": DatabaseMigrationStartedEventData;
"database:backup-created": DatabaseBackupCreatedEventData;

// Monitoring Events
"monitor:status-updated": MonitorStatusUpdateEventData;
"monitor:check-started": MonitorCheckStartedEventData;
"monitor:check-completed": MonitorCheckCompletedEventData;
"monitor:up": MonitorUpEventData;
"monitor:down": MonitorDownEventData;

// Site Events
"site:added": SiteAddedEventData;
"site:updated": SiteUpdatedEventData;
"site:deleted": SiteDeletedEventData;
"site:monitoring-started": SiteMonitoringStartedEventData;
"site:monitoring-stopped": SiteMonitoringStoppedEventData;

// System Events
"system:startup-completed": SystemStartupCompletedEventData;
"system:shutdown-initiated": SystemShutdownInitiatedEventData;
"system:focus-changed": SystemFocusChangedEventData;

// UI Events
"ui:modal-opened": UiModalOpenedEventData;
"ui:theme-changed": UiThemeChangedEventData;
"ui:view-changed": UiViewChangedEventData;

// ... 50+ total events with complete type safety
}

Event Metadata (Automatic):

  • correlationId - UUID for request tracing
  • timestamp - ISO string timestamp
  • environment - development/production
  • version - Application version
  • category - Event category for filtering

๐Ÿงช Testing Strategy & Configurationโ€‹

Dual Test Configurationโ€‹

Frontend Tests (vitest.config.ts):

export default defineConfig((configEnv) =>
mergeConfig(
viteConfig(configEnv),
defineConfig({
test: {
environment: "jsdom",
coverage: {
provider: "v8",
reporter: [
"text",
"json",
"lcov",
"html",
],
reportsDirectory: "./coverage/",
},
setupFiles: ["src/test/setup.ts"],
},
})
)
);

Backend Tests (config/testing/vitest.electron.config.ts):

export default defineConfig({
test: {
environment: "node",
coverage: {
provider: "v8",
reporter: [
"text",
"json",
"lcov",
"html",
],
reportsDirectory: "./coverage/electron/",
},
setupFiles: ["electron/test/setup.ts"],
},
});

Test Commands:

# Frontend tests
npm run test # Run frontend tests
npm run test:coverage # Frontend with coverage
npm run test:ui # Interactive UI
npm run test:watch # Watch mode

# Backend tests
npm run test:electron # Run electron tests
npm run test:electron:coverage # Electron with coverage
npm run test:electron:ui # Interactive UI
npm run test:electron:watch # Watch mode

# Combined
npm run test:all # Run all tests
npm run test:all:coverage # All tests with coverage
npm run test:all:coverage # All tests with coverage reporting

Coverage Integration:

  • Frontend Flag: frontend - covers src/ directory
  • Backend Flag: electron - covers electron/ directory
  • Codecov: Automatic dual-flag reporting via GitHub Actions

Test Patternsโ€‹

Repository Testing:

describe("SiteRepository", () => {
let repository: SiteRepository;
let mockDatabaseService: MockDatabaseService;

beforeEach(() => {
mockDatabaseService = createMockDatabaseService();
repository = new SiteRepository(mockDatabaseService);
});

it("should add site with transaction", async () => {
// Test async public methods
const site = await repository.addSite(mockSite);
expect(mockDatabaseService.executeTransaction).toHaveBeenCalled();
});
});

Store Testing:

describe("useSitesStore", () => {
let store: UseBoundStore<StoreApi<SitesStore>>;

beforeEach(() => {
store = useSitesStore;
store.getState().clearAllSites();
});

it("should handle async operations with error handling", async () => {
await store.getState().createSite(mockSiteData);
expect(store.getState().sites).toHaveLength(1);
});
});

Component Testing:

describe("SiteCard", () => {
it("should render site information correctly", () => {
render(<SiteCard site={mockSite} />);
expect(screen.getByText(mockSite.name)).toBeInTheDocument();
});

it("should handle monitoring toggle", async () => {
const user = userEvent.setup();
render(<SiteCard site={mockSite} />);

await user.click(
screen.getByRole("button", { name: /toggle monitoring/i })
);
// Assert monitoring state change
});
});

๐Ÿ› ๏ธ Build & Development Configurationโ€‹

Development Scriptsโ€‹

# Development
npm run dev # Start Vite dev server (port 5173)
npm run electron-dev # Concurrent Vite + Electron
npm run electron-dev:debug # With debugging enabled
npm run dev:with-sqlite3 # Copy WASM + start dev

# Building
npm run build # Full production build
npm run build:electron-main # Electron main process only
npm run build:prepublish # Lint + test + build
npm run dist # Build + package with Electron Builder

# Type Checking
npm run check:all # Check all TypeScript
npm run check:frontend # Frontend only
npm run check:electron # Backend only
npm run check:all:test # Include test configurations

# Quality
npm run lint # ESLint + Prettier
npm run lint:fix # Auto-fix issues
npm run cognitive-complexity # Complexity analysis
npm run dupes # Duplicate code detection

# Documentation
npm run docs:build # TypeDoc + Docusaurus
npm run docs:deploy # Deploy to GitHub Pages
npm run docusaurus:start # Local documentation server

Build Configuration Detailsโ€‹

Vite Configuration (vite.config.ts):

export default defineConfig(() => ({
base: "./", // Relative paths for Electron
target: "es2024", // Modern JavaScript
esbuild: {
target: "es2024",
keepNames: true, // Better coverage reports
include: ["**/*.{js,ts,jsx,tsx,mjs}"], // Comprehensive transpilation
},
build: {
emptyOutDir: true,
sourcemap: true, // Debugging support
outDir: "dist",
rollupOptions: {
// Optimized for Electron builds
},
},
plugins: [
react(), // React support
electron([
// Electron processes
{
entry: "electron/main.ts",
vite: electronMainConfig,
},
{
entry: "electron/preload.ts",
vite: electronPreloadConfig,
},
]),
ViteMcp(), // MCP integration
viteStaticCopy([
// Copy WASM files
{
src: "node_modules/node-sqlite3-wasm/dist/node-sqlite3-wasm.wasm",
dest: ".",
},
]),
codecovVitePlugin({
// Coverage integration
enableBundleAnalysis: true,
bundleName: "uptime-watcher",
}),
],
}));

Electron Builder Configuration (package.json):

{
"build": {
"appId": "io.github.uptimewatcher",
"productName": "Uptime Watcher",
"directories": {
"output": "release"
},
"files": [
"dist/**/*",
"dist-electron/**/*",
"!**/node_modules/**/*"
],
"extraFiles": [
{
"from": "node_modules/node-sqlite3-wasm/dist/node-sqlite3-wasm.wasm",
"to": "node-sqlite3-wasm.wasm"
}
],
"mac": {
/* macOS specific config */
},
"win": {
/* Windows specific config */
},
"linux": {
/* Linux specific config */
}
}
}

Environment & Path Configurationโ€‹

Path Aliases (tsconfig.json):

{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@shared/*": ["shared/*"], // Shared types and utilities
},
},
}

Environment Detection (shared/utils/environment.ts):

export const isDevelopment = process.env.NODE_ENV === "development";
export const isProduction = process.env.NODE_ENV === "production";
export const isTest = process.env.NODE_ENV === "test";

export function getEnvVar(name: string, defaultValue?: string): string {
const value = process.env[name];
if (value === undefined) {
if (defaultValue !== undefined) return defaultValue;
throw new Error(`Required environment variable ${name} is not set`);
}
return value;
}

๏ฟฝ Critical Knowledge for AI Assistantsโ€‹

Absolute Requirements โœ…โ€‹

  1. Type Safety First

    • All IPC messages must be typed
    • No any or unknown unless absolutely necessary
    • Strict TypeScript configuration must be maintained
    • Use discriminated unions for complex types
  2. Repository Pattern Compliance

    • All database access through repositories
    • Use executeTransaction() for all mutations
    • Implement both async (public) and sync (internal) methods
    • Emit appropriate events for database operations
  3. Error Handling Standards

    • Use withErrorHandling() for all async operations
    • Frontend: Include store error management
    • Backend: Include proper logging context
    • Always re-throw errors after handling
  4. Event-Driven Communication

    • Prefer events over direct method calls
    • Use TypedEventBus with proper type definitions
    • Include comprehensive metadata in events
    • Follow event naming conventions (domain:action-description)
  5. Store Architecture Compliance

    • Keep stores domain-specific (no global state)
    • Use modular composition pattern
    • Include error handling in all store actions
    • Follow dependency injection between store modules

Architecture Constraints โš ๏ธโ€‹

  1. Enhanced Monitoring Only

    • No fallback monitoring systems exist
    • MonitorManager requires enhanced services
    • All monitoring uses operation correlation
    • Return proper MonitorCheckResult interface
  2. Transaction Safety

    • All database mutations in transactions
    • Use repository patterns exclusively
    • Event emission within transaction scope
    • Proper rollback on errors
  3. IPC Security

    • All communication via contextBridge
    • Type-safe message contracts
    • Validation at IPC boundaries
    • No direct Node.js access from renderer
  4. Module Boundaries

    • Shared code only in shared/ directory
    • Frontend code in src/ directory
    • Backend code in electron/ directory
    • No cross-boundary imports outside shared

Common Pitfalls to Avoid โŒโ€‹

  1. Direct Database Access

    // โŒ WRONG - Direct database access
    const result = db.prepare("SELECT * FROM sites").all();

    // โœ… CORRECT - Repository pattern
    const sites = await siteRepository.getAllSites();
  2. Untyped IPC Communication

    // โŒ WRONG - Untyped IPC
    ipcRenderer.invoke("some-operation", data);

    // โœ… CORRECT - Typed IPC
    window.electronAPI.sites.addSite(siteData);
  3. Direct State Mutation

    // โŒ WRONG - Direct mutation
    store.sites.push(newSite);

    // โœ… CORRECT - Store actions
    store.addSite(newSite);
  4. Incorrect Error Handling

    // โŒ WRONG - Swallowing errors
    try {
    await operation();
    } catch (error) {
    console.log(error);
    }

    // โœ… CORRECT - Proper error handling
    await withErrorHandling(() => operation(), {
    logger,
    operationName: "operation",
    });

Performance Considerations ๐Ÿš€โ€‹

  1. Database Operations

    • Use prepared statements in repositories
    • Batch operations within single transactions
    • Implement proper indexing strategies
    • Use connection pooling appropriately
  2. Event System

    • Avoid excessive event emission in tight loops
    • Use event batching for bulk operations
    • Implement proper event cleanup
    • Monitor event listener memory usage
  3. State Management

    • Use selector patterns for computed state
    • Implement proper state normalization
    • Avoid unnecessary re-renders with proper memo
    • Use store subscriptions efficiently
  4. IPC Communication

    • Batch IPC calls when possible
    • Use streaming for large data transfers
    • Implement proper request/response correlation
    • Avoid blocking the main process

๐Ÿ”ง Common Development Tasksโ€‹

Adding a New Monitor Typeโ€‹

  1. Interface: Implement IMonitorService in electron/services/monitoring/
  2. Registration: Add to monitoring service factory
  3. Validation: Create validation schema in shared/validation/
  4. Frontend: Add UI components and form handling
  5. Testing: Unit tests for both backend and frontend

Adding IPC Handlersโ€‹

  1. Handler: Create in electron/services/ipc/ following domain pattern
  2. Validation: Add type guards in validators.ts
  3. Types: Define interfaces for parameters and responses
  4. Frontend: Use via window.electronAPI with type safety

Adding Database Entitiesโ€‹

  1. Repository: Create using repository template
  2. Migration: Add database schema changes
  3. Manager: Add business logic orchestration
  4. IPC: Expose operations via IPC handlers

Frontend Component Developmentโ€‹

  1. Store: Create Zustand store for state management
  2. Validation: Use shared validation schemas
  3. IPC Integration: Communicate with backend via typed IPC
  4. Error Handling: Use withErrorHandling() for async operations

๐Ÿ“š Essential Files Referenceโ€‹

Entry Pointsโ€‹

  • Electron Main: electron/main.ts - Application lifecycle
  • React Renderer: src/main.tsx - UI application entry
  • IPC Bridge: electron/preload.ts - Secure communication layer

Core Architectureโ€‹

  • Service Container: electron/services/ServiceContainer.ts - DI container
  • Event System: electron/events/TypedEventBus.ts - Type-safe events
  • Main Orchestrator: electron/UptimeOrchestrator.ts - Application coordinator

Database Layerโ€‹

  • Database Service: electron/services/database/DatabaseService.ts
  • Site Repository: electron/services/database/SiteRepository.ts
  • Monitor Repository: electron/services/database/MonitorRepository.ts
  • History Repository: electron/services/database/HistoryRepository.ts

Business Logicโ€‹

  • Site Manager: electron/managers/SiteManager.ts - Site operations
  • Monitor Manager: electron/managers/MonitorManager.ts - Monitoring logic
  • Enhanced Monitor Checker: electron/services/monitoring/EnhancedMonitorChecker.ts

State Managementโ€‹

  • Sites Store: src/stores/sites/useSitesStore.ts - Main data store
  • Settings Store: src/stores/settings/useSettingsStore.ts - Preferences
  • Error Store: src/stores/error/useErrorStore.ts - Error handling

Type Definitionsโ€‹

  • Shared Types: shared/types.ts - Core domain types
  • Event Types: electron/events/eventTypes.ts - Event definitions
  • Store Types: src/stores/types.ts - Frontend store types

Validationโ€‹

  • Schemas: shared/validation/schemas.ts - Zod validation schemas
  • Utilities: shared/validation/validatorUtils.ts - Validation helpers

Configurationโ€‹

  • TypeScript: tsconfig.json, tsconfig.electron.json
  • Build: vite.config.ts, package.json
  • Testing: vitest.config.ts, config/testing/vitest.electron.config.ts

For Architecture Understandingโ€‹

  • docs/Architecture/ADRs/ - Key architectural decisions
  • docs/Architecture/Patterns/Development-Patterns-Guide.md - Coding patterns
  • docs/Architecture/TSDoc-Standards.md - Documentation standards

For Implementationโ€‹

  • docs/Guides/NEW_MONITOR_TYPE_IMPLEMENTATION.md - Adding monitor types
  • docs/Guides/UI-Feature-Development-Guide.md - Frontend development
  • docs/Architecture/Templates/ - Code templates for common patterns

For Contextโ€‹

  • docs/Guides/Monitoring-Race-Condition-Solution-Plan.md - Monitoring architecture
  • docs/Guides/Fallback-System-Usage-Analysis.md - Migration history

๐ŸŽฏ AI Assistant Guidelinesโ€‹

When Helping with Codeโ€‹

  1. Check Documentation First: Most patterns are documented
  2. Follow Established Patterns: Don't invent new patterns
  3. Maintain Type Safety: All code must be properly typed
  4. Use Templates: Leverage existing templates for consistency
  5. Consider Events: Prefer event-driven communication
  6. Test Completeness: Ensure both frontend and backend are tested

Common AI Tasksโ€‹

  • Bug Fixes: Check error handling patterns and transaction safety
  • Feature Addition: Follow the service/repository/IPC pattern
  • Refactoring: Maintain existing interfaces and event contracts
  • Documentation: Use TSDoc standards for all new code

Integration Pointsโ€‹

  • IPC Communication: All frontend โ†” backend via typed IPC
  • Event System: Cross-service communication via TypedEventBus
  • Database: All access via repository pattern with transactions
  • State: Frontend state via Zustand, backend state via services

๐ŸŽฏ Final Note: This codebase emphasizes type safety, clean architecture, and comprehensive documentation. When working with this project, prioritize understanding the established patterns before making changes, and always maintain the high standards of type safety and error handling that are foundational to its design.