/**
 * Orchestrator Status Service
 *
 * Provides utilities to check the status of the orchestrator.
 * Used by Chat and Slack services to provide appropriate feedback
 * when the orchestrator is not running.
 *
 * @module services/orchestrator/orchestrator-status.service
 */
import { type UsageLimitedView } from '../runtime-fallback/usage-limit-state.js';
/**
 * Result of an orchestrator status check
 */
export interface OrchestratorStatusResult {
    /** Whether the orchestrator is active and ready to receive messages */
    isActive: boolean;
    /** The current agent status of the orchestrator */
    agentStatus: string | null;
    /** Human-readable status message */
    message: string;
    /**
     * Set while the orchestrator's runtime is out of usage (e.g. Claude Code's
     * weekly limit). `isActive` stays true — the session is running and must
     * not be restarted — but it takes no turn before `until` / `retryAt`.
     */
    usageLimited?: UsageLimitedView;
}
/**
 * Check if the orchestrator is currently active and ready to receive messages.
 *
 * @returns Promise resolving to true if orchestrator is active
 *
 * @example
 * ```typescript
 * if (await isOrchestratorActive()) {
 *   // Safe to send message to orchestrator
 * } else {
 *   // Show user-friendly offline message
 * }
 * ```
 */
export declare function isOrchestratorActive(): Promise<boolean>;
/**
 * Get detailed orchestrator status information.
 *
 * Uses the storageService.getOrchestratorStatus() method which reads the
 * orchestrator data directly from storage (not from the teams array).
 *
 * @returns Promise resolving to status details including active state and message
 *
 * @example
 * ```typescript
 * const status = await getOrchestratorStatus();
 * if (!status.isActive) {
 *   showError(status.message);
 * }
 * ```
 */
export declare function getOrchestratorStatus(): Promise<OrchestratorStatusResult>;
/**
 * Check if a specific agent is currently active.
 *
 * Two liveness paths, checked in order:
 * 1. **PTY path (unchanged)** — the agent's PTY session exists AND its child
 *    process (the AI runtime) is alive. This is the ground truth for
 *    `claude-code`, `gemini-cli` and `codex-cli` runtimes.
 * 2. **In-process fallback** — in-process Crewly Agent runtimes have no PTY
 *    session at all, so `sessionExists()` always returns `false` for them.
 *    When the in-process registry reports a ready runtime for this session
 *    AND the session's configured runtime type is `crewly-agent`, the agent
 *    is alive. This mirrors the B0 hot-fix fallback in
 *    {@link getOrchestratorStatus}.
 *
 * The fallback is deliberately narrow: it requires BOTH a ready registry
 * entry and a `crewly-agent` runtime type. A PTY-less `claude-code` agent
 * still reports inactive — widening the gate would let dead agents claim
 * work from the task pool, which is worse than the bug this fixes.
 *
 * The registry probe runs before the storage lookup because it is a
 * synchronous map hit; when it misses (the common case for a genuinely dead
 * PTY agent) no storage I/O happens at all.
 *
 * @param sessionName - The agent's session name to check
 * @returns Promise resolving to true if the agent's runtime is alive
 *
 * @example
 * ```typescript
 * // crewly-orc runs in-process with no PTY session
 * await isAgentActive('crewly-orc'); // true when its runtime is registered and ready
 * ```
 */
export declare function isAgentActive(sessionName: string): Promise<boolean>;
/**
 * Get a user-friendly message for when the orchestrator is offline.
 * Useful for Slack and Chat responses.
 *
 * @param includeUrl - Whether to include the dashboard URL in the message
 * @returns A user-friendly offline message
 */
export declare function getOrchestratorOfflineMessage(includeUrl?: boolean): string;
//# sourceMappingURL=orchestrator-status.service.d.ts.map