/**
 * Helpers reutilizables para resolver datos derivados de la sesion MCP en curso.
 *
 * Usan AsyncLocalStorage (`utils/sessionContext.js`) para recuperar el
 * `mcpSessionId` activo y leer informacion asociada desde
 * `auth/credentials.js`. En modo stdio (sin HTTP) devuelven `null` y el caller
 * decide como actuar.
 */
import { getCurrentSessionId } from "../../utils/sessionContext.js";
import { getMcpSessionCredentials } from "../../auth/credentials.js";

/**
 * Recupera el `acai_user` de la sesion HTTP activa (si existe).
 *
 * Se usa para inyectar el header `X-Acai-User` en llamadas al server Python,
 * evitando asi depender de Authorization Basic y permitiendo que los endpoints
 * autenticados (p.ej. `/api/generate-image`, `/api/files/write`) identifiquen
 * al usuario propietario del proyecto.
 *
 * @returns {string|null}
 */
export function resolveCurrentAcaiUser() {
    const sessionId = getCurrentSessionId();
    if (!sessionId) return null;
    const creds = getMcpSessionCredentials(sessionId);
    return creds?.acai_user || null;
}

/**
 * Modo efectivo (X-Acai-Mode) para las llamadas al server Python.
 *
 * Regla de seguridad: una sesion MCP HTTP (mcpSessionId presente) es SIEMPRE un
 * cliente externo — en la practica el plugin VS Code Acai Forge — y solo puede
 * operar sobre TEST. Por eso forzamos "local" pase lo que pase el .acai del
 * proyecto. El server Python honra este header para decidir el destino real
 * (BD y ficheros), de modo que vscode nunca toca produccion.
 *
 * Las sesiones stdio (chat del dashboard / cronjobs) NO tienen mcpSessionId:
 * mantienen el override de entorno (ACAI_MODE_OVERRIDE), que puede ser
 * "production" cuando corresponde (chat en modo produccion, cron de prod).
 *
 * @returns {string} "local" | "production" | "" (vacio = usar .acai)
 */
export function resolveCurrentModeOverride() {
    if (getCurrentSessionId()) return "local";
    return process.env.ACAI_MODE_OVERRIDE || process.env.ACAI_MODE || "";
}