/**
 * Schedule Service
 *
 * Manages scheduled update checks, tracking check history,
 * and generating external scheduler commands.
 *
 * Persistence (fixed in Phase 4.1): BOTH config and state round-trip through
 * the same file. Before this fix only state was saved, so
 * `schedule --enable` / `--interval` never survived the process —
 * `isDue()` returned false forever and `schedule --run` always skipped.
 * `updateConfig()` persists synchronously so CLI flag paths that don't
 * call save() still round-trip.
 *
 * @since v1.24.0
 */
import { type MaintenanceWindow, type ScheduleCheckRecord, type ScheduleCommand, type ScheduleConfig, type ScheduleState, type ScheduledCheckResult } from './schedule-types.js';
/**
 * Whether `date` falls inside a maintenance window (Phase 4.4 — scheduled
 * promotions are gated to this window; manual promotions ignore it with a
 * printed note).
 *
 * Semantics:
 * - No window configured → always true (no gate).
 * - Empty `days` array → the window applies every day.
 * - Overnight windows (endHour < startHour, e.g. 22→04) match the pre-midnight
 *   part on a listed day and the post-midnight part on the day FOLLOWING a
 *   listed day (a Saturday 22:00–04:00 window includes Sunday 03:00).
 * - `startHour === endHour` is treated as a zero-length window (never matches)
 *   rather than all-day — an explicit window that gates nothing is more likely
 *   a configuration mistake than an intentional 24h window.
 */
export declare function isWithinMaintenanceWindow(window: MaintenanceWindow | undefined, date?: Date): boolean;
/**
 * Schedule service for managing update scheduling
 */
export declare class ScheduleService {
    private config;
    private state;
    private statePath;
    private loaded;
    constructor(statePath: string, config?: Partial<ScheduleConfig>);
    /**
     * Apply a parsed on-disk payload to in-memory config + state.
     * Persisted config wins over defaults/constructor overrides — it is the
     * user's saved truth.
     */
    private applyPersisted;
    /**
     * Serialize config + state for persistence.
     */
    private toPersisted;
    /**
     * Load config + state from disk
     */
    load(): Promise<void>;
    /**
     * Synchronous load used by updateConfig() when the caller mutates config
     * before ever calling load() — prevents clobbering existing on-disk
     * history with a fresh default state.
     */
    private loadSync;
    /**
     * Save config + state to disk (atomic write)
     */
    save(): Promise<void>;
    /**
     * Check if a scheduled check is due
     */
    isDue(): boolean;
    /**
     * Check if currently in quiet hours
     */
    isQuietHours(): boolean;
    /**
     * Get the next scheduled check time
     */
    getNextScheduledTime(): Date;
    /**
     * Record a check.
     *
     * `state.lastCheck` doubles as the last-run stamp surfaced by the
     * ScheduleView and `schedule --status`.
     */
    recordCheck(result: ScheduledCheckResult): Promise<void>;
    /**
     * Record a download
     */
    recordDownload(): Promise<void>;
    /**
     * Get check history
     */
    getHistory(): ScheduleCheckRecord[];
    /**
     * Get current state
     */
    getState(): ScheduleState;
    /**
     * Get current config
     */
    getConfig(): ScheduleConfig;
    /**
     * Update configuration AND persist it (synchronously, atomic write).
     *
     * Persisting here — not just in save() — is what makes
     * `schedule --enable` / `--interval` real: those CLI paths call
     * updateConfig() and return without calling save(). Pre-4.1 this method
     * mutated memory only, so enablement could never survive the process.
     *
     * If load() hasn't run yet, the existing file is read first so a
     * config-only write can't clobber on-disk history with default state.
     */
    updateConfig(updates: Partial<ScheduleConfig>): void;
    /**
     * Generate cron expression for the schedule
     */
    generateCronExpression(): string;
    /**
     * Generate schedule commands for external schedulers.
     *
     * Every entry invokes `pluginator auto-update --json` — the one
     * non-interactive command that works end-to-end today (scan → check →
     * download to TEST). The previous generator emitted
     * `pluginator --check-updates --quiet`, a flag that does not exist, so
     * every user who followed the setup instructions had a scheduler entry
     * erroring on every tick (audit cli-headless F1).
     */
    generateScheduleCommands(pluginatorPath: string): ScheduleCommand[];
    /**
     * Generate systemd user unit + timer file contents
     */
    private generateSystemdUnits;
    /**
     * Generate Windows Task Scheduler command
     */
    private generateWindowsTaskCommand;
    /**
     * Generate macOS launchd plist
     */
    private generateLaunchdPlist;
    /**
     * Clear history
     */
    clearHistory(): Promise<void>;
}
/**
 * Get the singleton schedule service instance
 */
export declare function getScheduleService(statePath?: string): ScheduleService;
/**
 * Reset the singleton (for testing)
 */
export declare function resetScheduleService(): void;
//# sourceMappingURL=schedule-service.d.ts.map