// The e2e worker's per-org hourly execution cap (EXECUTION_RATE_LIMIT_PER_HOUR).
// One constant with two consumers, the boot recipe env (cloud.boot.ts) and the
// rate-limit backstop scenario (cloud/mcp-execution-limits.test.ts), so they
// cannot drift apart.
//
// Picking the value is a squeeze from both sides. It must be LOW enough that
// the backstop scenario can exhaust it with real sequential executions (prod's
// 10,000/hour cannot be reached in a test), and HIGH enough that no other
// scenario trips it: the counter is per organization and every `execute` a
// scenario runs counts against its org, so this must exceed the busiest
// single-org scenario's execute count (currently toolkits-mcp at ~8) with
// comfortable headroom. If a scenario ever fails with the rate-limit backstop
// message, it outgrew this cap: raise it here, never in the boot env alone.
export const E2E_EXECUTION_RATE_LIMIT = 20;

// The e2e worker's counter-check budget (EXECUTION_RATE_LIMIT_CHECK_TIMEOUT_MS),
// same two consumers as the cap above.
//
// This exists to make the OVERRIDE ITSELF observable end to end. The budget is
// stamped on the `rate_limit.check` span, so a value that differs from the
// compiled-in default (RATE_LIMIT_CHECK_TIMEOUT_MS = 2000) is the difference
// between "the worker read the env var" and "the worker fell back to the
// constant and nobody noticed". A knob nothing reads is worse than no knob.
//
// It is deliberately LONGER than the default, not shorter: a shorter budget
// would time the check out and fail open on every execution, which would take
// the backstop scenario down with it. Longer only means a genuinely wedged
// counter stalls an execution 3s instead of 2s, which no scenario depends on.
export const E2E_EXECUTION_RATE_LIMIT_CHECK_TIMEOUT_MS = 3000;