// The sandbox execution budget shared between a target's boot env and the
// sandbox-deadline scenario, so they cannot drift apart (same pattern as
// execution-limits.ts). The scenario proves a RATIO — approvals granted
// inside their own windows survive an execution that outlives the sandbox's
// absolute budget — so the budget's magnitude is free to shrink: on selfhost
// the boot recipe passes E2E_SANDBOX_TIMEOUT_MS through to the server as
// EXECUTOR_SANDBOX_TIMEOUT_MS and the scenario scales its approval delays to
// match, turning a ~6-minute real-time wait into seconds. Targets that cannot
// shrink the budget (cloud's dynamic-worker deadline is not env-tunable) run
// against the production default and skip via their paused-session window
// guard instead.
export const E2E_SANDBOX_TIMEOUT_MS = 20_000;

export const SANDBOX_TIMEOUT_ENV = "E2E_SANDBOX_TIMEOUT_MS";

const PRODUCTION_SANDBOX_TIMEOUT_MS = 5 * 60_000;

const positiveMilliseconds = (raw: string | undefined): number | undefined => {
  if (!raw) return undefined;
  const parsed = Number(raw);
  if (!Number.isFinite(parsed) || parsed <= 0) return undefined;
  return Math.floor(parsed);
};

/** The sandbox budget the current target enforces: the harness override when
 *  the target was booted with one, else the production default. */
export const configuredSandboxTimeoutMs = (): number =>
  positiveMilliseconds(process.env[SANDBOX_TIMEOUT_ENV]) ?? PRODUCTION_SANDBOX_TIMEOUT_MS;