@oxygen-agent/cli 1.922.14 → 1.948.1

package/node_modules/@oxygen/shared/dist/product-analytics-core.js

@@ -0,0 +1,159 @@
+/**
+ * Product-analytics core — the TRANSPORT-FREE half of PostHog emission.
+ *
+ * Two runtimes emit product events: the web/API runtime (`apps/web/src/lib/
+ * product-analytics.ts`, `posthog-node` on Vercel) and the Fly worker
+ * (`apps/worker/src/product-analytics.ts`, `posthog-node` batching). What they
+ * must agree on lives here, once: property sanitization, the distinct-id
+ * chain, the person-profile posture, org grouping, and the runtime dimensions
+ * every event carries. Two copies of that logic drifted in the past — the
+ * worker would have minted a throwaway person per request while the web side
+ * did not — and PostHog cannot join what the emitters disagree about.
+ *
+ * Deliberately NO `posthog-node`, no fetch, no I/O: `packages/shared` is
+ * vendored into the published `@oxygen-agent/cli` tarball, so every runtime
+ * dependency added here lands on every customer's machine
+ * (`scripts/cli-package-dependencies.mjs`, the langfuse-class guard). The
+ * capture message is a plain object structurally compatible with
+ * `posthog-node`'s `EventMessage`; each runtime owns its own client.
+ */
+export const PRODUCT_ANALYTICS_MAX_PROPERTY_KEY_LENGTH = 80;
+export const PRODUCT_ANALYTICS_MAX_PROPERTY_STRING_LENGTH = 500;
+/**
+ * Byte ceiling for a structured (object/array) property value.
+ *
+ * Structured values pass through UNTOUCHED — see `sanitizeStructuredValue` — so
+ * this is the only thing standing between a careless caller and an unbounded
+ * ingest payload. Set well above `MCP_PAYLOAD_LIMITS.maxSerializedBytes` (8 KiB,
+ * in apps/web `analytics/mcp-analytics.ts`) so it can never re-cut a payload
+ * that module already bounded and marked; it exists for the callers that bound
+ * nothing.
+ */
+export const PRODUCT_ANALYTICS_MAX_STRUCTURED_PROPERTY_BYTES = 32_768;
+export function sanitizeProductAnalyticsProperties(properties) {
+    const sanitized = {};
+    for (const [rawKey, rawValue] of Object.entries(properties)) {
+        const key = sanitizePropertyKey(rawKey);
+        if (!key || rawValue === undefined)
+            continue;
+        const value = sanitizePropertyValue(rawValue);
+        if (value !== undefined)
+            sanitized[key] = value;
+    }
+    return sanitized;
+}
+function sanitizePropertyKey(key) {
+    const normalized = key
+        .trim()
+        .replace(/[^A-Za-z0-9_.$-]/g, "_")
+        .slice(0, PRODUCT_ANALYTICS_MAX_PROPERTY_KEY_LENGTH);
+    return normalized || null;
+}
+function sanitizePropertyValue(value) {
+    if (value === null || value === undefined)
+        return value;
+    if (typeof value === "boolean")
+        return value;
+    if (typeof value === "number")
+        return Number.isFinite(value) ? value : null;
+    if (typeof value === "string")
+        return value.slice(0, PRODUCT_ANALYTICS_MAX_PROPERTY_STRING_LENGTH);
+    return sanitizeStructuredValue(value);
+}
+/**
+ * Objects and arrays pass through UNTOUCHED, or not at all.
+ *
+ * Deliberately not walked, re-keyed, `String()`d, or cut at the string ceiling:
+ * the callers that send structured values (apps/web `analytics/mcp-analytics.ts`)
+ * have already redacted and bounded them, and a second pass here would either
+ * corrupt a payload into invalid JSON — which is exactly what an old
+ * `.slice(0, 500)` did to any array — or silently undo the marked truncation
+ * the first pass recorded.
+ *
+ * The only checks are the two that protect the pipe: it must be JSON-encodable
+ * (a cycle or a BigInt would otherwise throw inside the SDK, and `JSON.stringify`
+ * itself throws HERE, upstream of the emitter's try), and it must be under the
+ * byte ceiling. Failing either drops the one property, never the event.
+ */
+function sanitizeStructuredValue(value) {
+    try {
+        const serialized = JSON.stringify(value);
+        if (typeof serialized !== "string")
+            return undefined;
+        if (Buffer.byteLength(serialized, "utf8") > PRODUCT_ANALYTICS_MAX_STRUCTURED_PROPERTY_BYTES) {
+            return undefined;
+        }
+        return value;
+    }
+    catch {
+        return undefined;
+    }
+}
+export function normalizeProductAnalyticsIdentifier(value) {
+    if (typeof value === "string" && value.trim()) {
+        return value.trim().slice(0, PRODUCT_ANALYTICS_MAX_PROPERTY_STRING_LENGTH);
+    }
+    if (typeof value === "number" && Number.isFinite(value))
+        return String(value);
+    return null;
+}
+/**
+ * Build the capture message every runtime sends. Returns null when no distinct
+ * id can be derived — an event with no subject is dropped, never invented.
+ */
+export function buildProductAnalyticsCaptureMessage(input, context) {
+    const organizationId = normalizeProductAnalyticsIdentifier(input.organizationId);
+    const distinctIdSource = [
+        { value: input.distinctId, identifiesPerson: true },
+        { value: input.userId, identifiesPerson: true },
+        // Namespaced: a bare org UUID is indistinguishable from a human UUID at
+        // query time, so an unprefixed org fallback silently pollutes person-level
+        // counts (and any "users who…" cohort) with workspace rows. The `groups`
+        // attachment below keeps the RAW id — PostHog resolves group keys by exact
+        // match against the org id the rest of the product uses.
+        { value: organizationId ? `org:${organizationId}` : null, identifiesPerson: false },
+        { value: input.properties?.trace_id, identifiesPerson: false },
+        { value: input.properties?.request_id, identifiesPerson: false },
+    ].find((candidate) => candidate.value !== null && candidate.value !== undefined);
+    const distinctId = normalizeProductAnalyticsIdentifier(distinctIdSource?.value);
+    if (!distinctId)
+        return null;
+    const properties = sanitizeProductAnalyticsProperties({
+        product_analytics_environment: context.environment,
+        oxygen_version: context.oxygenVersion,
+        ...context.runtimeProperties,
+        organization_id: organizationId,
+        user_id: normalizeProductAnalyticsIdentifier(input.userId),
+        ...input.properties,
+        // Person profiles are a per-event decision on backend SDKs, not an init
+        // option. `posthog-node`'s client extends `PostHogCoreStateless`, which has
+        // no person-mode state at all — only the browser's stateful `PostHogCore`
+        // reads `personProfiles`. A `personProfiles: "identified_only"` passed to the
+        // constructor typechecks and is then read by nothing, so every event would
+        // get a person profile regardless.
+        //
+        // Without this, the `trace_id`/`request_id` tail of the distinct-id chain
+        // mints one throwaway person per request. Set last so a caller-supplied
+        // property can never flip the posture.
+        //
+        // `|| organizationId` is load-bearing, not defensive: PostHog cannot run
+        // group analytics on an anonymous event, and `@posthog/core`'s own
+        // `_hasPersonProcessing()` is `isIdentified || hasGroups || enabled` — the
+        // SDK forces person processing ON whenever `$groups` is attached. Emitting
+        // the inverse pairing would silently zero every org-grouped trend, funnel
+        // and retention on exactly the two highest-volume events
+        // (`cli_command_run`, `$mcp_tool_call`), because org-API-key traffic has no
+        // `userId` and falls through to the org-id candidate. The cost this whole
+        // switch targets is the per-REQUEST trace/request-id tail; one profile per
+        // ORG is cheap and is where the group data lives.
+        $process_person_profile: (distinctIdSource?.identifiesPerson ?? false) || Boolean(organizationId),
+    });
+    return {
+        distinctId,
+        event: input.event,
+        properties,
+        ...(organizationId ? { groups: { organization: organizationId } } : {}),
+        ...(input.uuid ? { uuid: input.uuid } : {}),
+        ...(input.timestamp ? { timestamp: input.timestamp } : {}),
+    };
+}

package/node_modules/@oxygen/shared/dist/product-analytics-environment.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The PROD / MAIN / DEV / LOCAL dimension stamped on every product event as
+ * `product_analytics_environment`. One resolver for both emitting runtimes:
+ *
+ * - explicit pins win (`POSTHOG_ENVIRONMENT`, its `NEXT_PUBLIC_` twin, and the
+ *   Sentry environment vars the web app already sets);
+ * - the web/API runtime has `VERCEL_ENV` (+ the branch for MAIN-preview);
+ * - the Fly worker has NO `VERCEL_ENV` and `NODE_ENV=production` on BOTH apps,
+ *   so — mirroring `apps/worker/src/worker-env.ts` and the Langfuse resolver —
+ *   the Fly-injected app name is the ground truth (`-dev` marks the dev app; a
+ *   cross-env Doppler drift cannot fake it), then `FLY_ENVIRONMENT`;
+ * - everything else is LOCAL. `NODE_ENV=production` is deliberately NOT read as
+ *   PROD: it is the default for any built Node process, a local one included.
+ */
+export type ProductAnalyticsEnvironment = "PROD" | "MAIN" | "DEV" | "LOCAL";
+type EnvSource = Record<string, string | undefined>;
+export declare function resolveProductAnalyticsEnvironmentFromEnv(env?: EnvSource): ProductAnalyticsEnvironment;
+export {};

package/node_modules/@oxygen/shared/dist/product-analytics-environment.js

@@ -0,0 +1,46 @@
+function normalizeProductAnalyticsEnvironment(value) {
+    if (!value)
+        return null;
+    switch (value.trim().toUpperCase()) {
+        case "PROD":
+        case "PRODUCTION":
+            return "PROD";
+        case "MAIN":
+            return "MAIN";
+        case "DEV":
+        case "DEVELOPMENT":
+        case "PREVIEW":
+            return "DEV";
+        case "LOCAL":
+            return "LOCAL";
+        default:
+            return null;
+    }
+}
+export function resolveProductAnalyticsEnvironmentFromEnv(env = process.env) {
+    const explicit = normalizeProductAnalyticsEnvironment(env.POSTHOG_ENVIRONMENT
+        ?? env.NEXT_PUBLIC_POSTHOG_ENVIRONMENT
+        ?? env.SENTRY_ENVIRONMENT
+        ?? env.NEXT_PUBLIC_SENTRY_ENVIRONMENT);
+    if (explicit)
+        return explicit;
+    const vercelEnv = env.VERCEL_ENV ?? env.NEXT_PUBLIC_VERCEL_ENV;
+    if (vercelEnv === "production")
+        return "PROD";
+    const branch = env.VERCEL_GIT_COMMIT_REF ?? env.NEXT_PUBLIC_VERCEL_GIT_COMMIT_REF;
+    if (vercelEnv === "preview" && branch === "main")
+        return "MAIN";
+    if (vercelEnv === "preview")
+        return "DEV";
+    if (vercelEnv === "development")
+        return "LOCAL";
+    const flyApp = (env.FLY_APP_NAME ?? env.FLY_APP)?.trim();
+    if (flyApp)
+        return flyApp.includes("-dev") ? "DEV" : "PROD";
+    const flyEnvironment = env.FLY_ENVIRONMENT?.trim().toLowerCase();
+    if (flyEnvironment === "production")
+        return "PROD";
+    if (flyEnvironment)
+        return "DEV";
+    return "LOCAL";
+}

package/node_modules/@oxygen/shared/dist/product-analytics-events.d.ts

@@ -0,0 +1,92 @@
+/**
+ * Every product-analytics event name OXYGEN emits, in one place — for BOTH
+ * emitting runtimes. The web/API runtime re-exports this from
+ * `apps/web/src/lib/analytics/event-names.ts` (which also owns PostHog's
+ * reserved `$mcp_*` vocabulary and the KPI-ledger translation); the Fly worker
+ * imports it directly.
+ *
+ * An event name is a contract shared by three things that cannot see each
+ * other: the emitter, its test, and the PostHog insight/funnel built on top. A
+ * literal typed at each call site drifts silently — the rename lands in the
+ * code, the dashboard keeps querying the old string, and the funnel reads zero
+ * without erroring. Import from here instead of typing the string.
+ *
+ * Names are unprefixed `subject_verb` snake_case; the web test pins the exact
+ * set, so adding one is a deliberate edit there too.
+ */
+export declare const PRODUCT_EVENTS: {
+    /** Acquisition. */
+    readonly USER_SIGNED_UP: "user_signed_up";
+    readonly WORKSPACE_CREATED: "workspace_created";
+    /** Activation. */
+    readonly ONBOARDING_COMPLETED: "onboarding_completed";
+    readonly ONBOARDING_RESET: "onboarding_reset";
+    readonly ACTIVATION_PATH_SELECTED: "activation_path_selected";
+    readonly AGENT_CONNECTED: "agent_connected";
+    readonly FIRST_RECORD_CREATED: "first_record_created";
+    /**
+     * The prescribed first play (inbound-led outbound), walked on ANY surface.
+     *
+     * These describe progress through a play, not a lifecycle moment — a founder
+     * who arms capture from the CLI and drafts the sequence in the browser
+     * produces one continuous series. Which is exactly why they are emitted from
+     * one watermark-guarded helper (apps/web `lib/activation/analytics.ts`)
+     * rather than from each surface: the same completed-step count read twice
+     * must emit once.
+     *
+     * Deliberately ABSENT from the web's KPI_TYPE_TO_EVENT. The headline
+     * activation KPI is CLI/MCP-sourced by design; wiring a web-observable play
+     * step into that ledger would silently redefine what the company reports as
+     * activation.
+     */
+    readonly FIRST_PLAY_STARTED: "first_play_started";
+    readonly FIRST_PLAY_STEP_COMPLETED: "first_play_step_completed";
+    readonly FIRST_PLAY_COMPLETED: "first_play_completed";
+    readonly FIRST_PLAY_SKIPPED: "first_play_skipped";
+    /**
+     * Usage — what was ASKED for. `mcp_tool_called` used to sit here as the
+     * second highest-volume event; it was REPLACED (not joined) by the reserved
+     * `$mcp_tool_call` in the web's MCP_ANALYTICS_EVENTS — see that block for why
+     * both cannot be emitted.
+     */
+    readonly CLI_COMMAND_RUN: "cli_command_run";
+    /**
+     * Outcomes — what actually HAPPENED, emitted by the Fly worker when a durable
+     * unit of work reaches a terminal state. `cli_command_run` and `$mcp_tool_call`
+     * see a run being requested; nothing on the web runtime ever sees it finish,
+     * because workflows, column runs, ingestions, agent runs and sequence steps
+     * complete on Fly minutes later. Without these, every "did it work" question
+     * (success rate, duration, credits per run, replies per enrollment) was
+     * unanswerable in PostHog and biased toward optimism — sweeps, repair passes
+     * and lease expiries settle runs invisibly.
+     *
+     * One event per terminal transition, `uuid` = the run/outbox id so a
+     * re-read after a worker restart dedupes, `timestamp` = when it settled.
+     * Properties are ids, enums and numbers only — never row values, prompts,
+     * or lead names (ADR 0021: PostHog stays sanitized).
+     */
+    readonly WORKFLOW_RUN_SETTLED: "workflow_run_settled";
+    readonly TABLE_ACTION_RUN_SETTLED: "table_action_run_settled";
+    readonly TABLE_INGESTION_RUN_SETTLED: "table_ingestion_run_settled";
+    readonly AGENT_RUN_SETTLED: "agent_run_settled";
+    readonly SEQUENCE_ENROLLMENT_SETTLED: "sequence_enrollment_settled";
+    /** Revenue lifecycle. */
+    readonly TRIAL_STARTED: "trial_started";
+    readonly SUBSCRIPTION_ACTIVATED: "subscription_activated";
+    readonly SUBSCRIPTION_CHURNED: "subscription_churned";
+    readonly TRIAL_CANCEL_SCHEDULED: "trial_cancel_scheduled";
+    readonly TRIAL_CANCEL_RESUMED: "trial_cancel_resumed";
+    readonly TRIAL_ENDED_UNCONVERTED: "trial_ended_unconverted";
+    /** Pipeline heartbeat: proves ingestion is alive when the product is quiet. */
+    readonly POSTHOG_CANARY: "posthog_canary";
+};
+export type ProductEventName = (typeof PRODUCT_EVENTS)[keyof typeof PRODUCT_EVENTS];
+/** Every name, for drift checks and dashboard provisioning. */
+export declare const PRODUCT_EVENT_NAMES: readonly ProductEventName[];
+/**
+ * The outcome events the worker emits, as a typed subset — so the worker's
+ * emitter cannot be handed a lifecycle event that only the control plane has
+ * the facts for.
+ */
+export declare const WORKER_RUN_OUTCOME_EVENTS: readonly ["workflow_run_settled", "table_action_run_settled", "table_ingestion_run_settled", "agent_run_settled", "sequence_enrollment_settled"];
+export type WorkerRunOutcomeEventName = (typeof WORKER_RUN_OUTCOME_EVENTS)[number];

package/node_modules/@oxygen/shared/dist/product-analytics-events.js

@@ -0,0 +1,96 @@
+/**
+ * Every product-analytics event name OXYGEN emits, in one place — for BOTH
+ * emitting runtimes. The web/API runtime re-exports this from
+ * `apps/web/src/lib/analytics/event-names.ts` (which also owns PostHog's
+ * reserved `$mcp_*` vocabulary and the KPI-ledger translation); the Fly worker
+ * imports it directly.
+ *
+ * An event name is a contract shared by three things that cannot see each
+ * other: the emitter, its test, and the PostHog insight/funnel built on top. A
+ * literal typed at each call site drifts silently — the rename lands in the
+ * code, the dashboard keeps querying the old string, and the funnel reads zero
+ * without erroring. Import from here instead of typing the string.
+ *
+ * Names are unprefixed `subject_verb` snake_case; the web test pins the exact
+ * set, so adding one is a deliberate edit there too.
+ */
+export const PRODUCT_EVENTS = {
+    /** Acquisition. */
+    USER_SIGNED_UP: "user_signed_up",
+    WORKSPACE_CREATED: "workspace_created",
+    /** Activation. */
+    ONBOARDING_COMPLETED: "onboarding_completed",
+    ONBOARDING_RESET: "onboarding_reset",
+    ACTIVATION_PATH_SELECTED: "activation_path_selected",
+    AGENT_CONNECTED: "agent_connected",
+    FIRST_RECORD_CREATED: "first_record_created",
+    /**
+     * The prescribed first play (inbound-led outbound), walked on ANY surface.
+     *
+     * These describe progress through a play, not a lifecycle moment — a founder
+     * who arms capture from the CLI and drafts the sequence in the browser
+     * produces one continuous series. Which is exactly why they are emitted from
+     * one watermark-guarded helper (apps/web `lib/activation/analytics.ts`)
+     * rather than from each surface: the same completed-step count read twice
+     * must emit once.
+     *
+     * Deliberately ABSENT from the web's KPI_TYPE_TO_EVENT. The headline
+     * activation KPI is CLI/MCP-sourced by design; wiring a web-observable play
+     * step into that ledger would silently redefine what the company reports as
+     * activation.
+     */
+    FIRST_PLAY_STARTED: "first_play_started",
+    FIRST_PLAY_STEP_COMPLETED: "first_play_step_completed",
+    FIRST_PLAY_COMPLETED: "first_play_completed",
+    FIRST_PLAY_SKIPPED: "first_play_skipped",
+    /**
+     * Usage — what was ASKED for. `mcp_tool_called` used to sit here as the
+     * second highest-volume event; it was REPLACED (not joined) by the reserved
+     * `$mcp_tool_call` in the web's MCP_ANALYTICS_EVENTS — see that block for why
+     * both cannot be emitted.
+     */
+    CLI_COMMAND_RUN: "cli_command_run",
+    /**
+     * Outcomes — what actually HAPPENED, emitted by the Fly worker when a durable
+     * unit of work reaches a terminal state. `cli_command_run` and `$mcp_tool_call`
+     * see a run being requested; nothing on the web runtime ever sees it finish,
+     * because workflows, column runs, ingestions, agent runs and sequence steps
+     * complete on Fly minutes later. Without these, every "did it work" question
+     * (success rate, duration, credits per run, replies per enrollment) was
+     * unanswerable in PostHog and biased toward optimism — sweeps, repair passes
+     * and lease expiries settle runs invisibly.
+     *
+     * One event per terminal transition, `uuid` = the run/outbox id so a
+     * re-read after a worker restart dedupes, `timestamp` = when it settled.
+     * Properties are ids, enums and numbers only — never row values, prompts,
+     * or lead names (ADR 0021: PostHog stays sanitized).
+     */
+    WORKFLOW_RUN_SETTLED: "workflow_run_settled",
+    TABLE_ACTION_RUN_SETTLED: "table_action_run_settled",
+    TABLE_INGESTION_RUN_SETTLED: "table_ingestion_run_settled",
+    AGENT_RUN_SETTLED: "agent_run_settled",
+    SEQUENCE_ENROLLMENT_SETTLED: "sequence_enrollment_settled",
+    /** Revenue lifecycle. */
+    TRIAL_STARTED: "trial_started",
+    SUBSCRIPTION_ACTIVATED: "subscription_activated",
+    SUBSCRIPTION_CHURNED: "subscription_churned",
+    TRIAL_CANCEL_SCHEDULED: "trial_cancel_scheduled",
+    TRIAL_CANCEL_RESUMED: "trial_cancel_resumed",
+    TRIAL_ENDED_UNCONVERTED: "trial_ended_unconverted",
+    /** Pipeline heartbeat: proves ingestion is alive when the product is quiet. */
+    POSTHOG_CANARY: "posthog_canary",
+};
+/** Every name, for drift checks and dashboard provisioning. */
+export const PRODUCT_EVENT_NAMES = Object.freeze(Object.values(PRODUCT_EVENTS));
+/**
+ * The outcome events the worker emits, as a typed subset — so the worker's
+ * emitter cannot be handed a lifecycle event that only the control plane has
+ * the facts for.
+ */
+export const WORKER_RUN_OUTCOME_EVENTS = Object.freeze([
+    PRODUCT_EVENTS.WORKFLOW_RUN_SETTLED,
+    PRODUCT_EVENTS.TABLE_ACTION_RUN_SETTLED,
+    PRODUCT_EVENTS.TABLE_INGESTION_RUN_SETTLED,
+    PRODUCT_EVENTS.AGENT_RUN_SETTLED,
+    PRODUCT_EVENTS.SEQUENCE_ENROLLMENT_SETTLED,
+]);

package/node_modules/@oxygen/shared/dist/provider-balance-signal.d.ts

@@ -0,0 +1,113 @@
+/**
+ * The managed-provider BALANCE signal — one contract shared by the two producers
+ * that can observe it and the one Axiom monitor that alerts on it.
+ *
+ * WHY THIS EXISTS. Until now the only way OXYGEN learned that one of its POOLED
+ * provider accounts had run out of money was a customer's call being refused.
+ * `provider.managed_credits_exhausted` fires at that moment — after the failure,
+ * never before it. Plain T-104 (Mentcape, 2026-08-24 and again 2026-08-31) is what
+ * that costs: `serper.places`, `serper.maps` and `parallel.search` refused live
+ * calls for a workspace holding 75,347 Oxygen credits, because OUR balance with
+ * those vendors was empty. Prod Axiom over the 16 days to 2026-09-05 shows the same
+ * refusal reaching >=6 orgs on serper, >=3 on parallel and >=5 on exa.
+ *
+ * The balance snapshot cron already read most of those balances every two hours and
+ * wrote them to `provider_balance_snapshots`. It emitted no per-provider log line at
+ * all, so a balance sliding toward zero was visible only to a human who opened
+ * /admin/costs. This module is the missing signal: one structured line per managed
+ * provider per snapshot, carrying the number AND the verdict.
+ *
+ * TWO PRODUCERS, ONE VOCABULARY.
+ *
+ *  - `provider_balance.snapshot` — the cron, for every provider whose balance we can
+ *    actually read. Proactive: it fires while there is still money left.
+ *  - `provider_balance.exhausted` — the tool runner, when a managed account actually
+ *    refuses a paid call. That is the ONLY balance evidence available for a provider
+ *    with no usable balance API, which is exactly the T-104 three (see
+ *    PROVIDERS_WITHOUT_BALANCE_API in @oxygen/providers). Without it the new monitor
+ *    would be structurally blind to the providers that caused the incident.
+ *
+ * Both carry the same `status` vocabulary so ONE monitor query covers both, and both
+ * put `status` and `provider` in flat fields because those are the two dimensions the
+ * monitor filters and groups on. Every other field rides in the `worker_fields` map
+ * at zero column cost — see AXIOM_STABLE_FIELDS in ./axiom-field-budget.ts, which is
+ * load-bearing in both directions.
+ */
+/** The proactive line, emitted per managed provider by the balance-snapshot cron. */
+export declare const PROVIDER_BALANCE_SNAPSHOT_MSG = "provider_balance.snapshot";
+/**
+ * The reactive line, emitted by the tool runner when a managed account refuses a paid
+ * call. Deliberately a SEPARATE msg from `provider.managed_credits_exhausted`: that
+ * one is the refusal event (a customer call failed), this one is the balance fact (our
+ * account is empty). The refusal monitor counts the former; conflating them would make
+ * one query mean two different things.
+ */
+export declare const PROVIDER_BALANCE_EXHAUSTED_MSG = "provider_balance.exhausted";
+/**
+ * The verdict on one managed balance.
+ *
+ * `unknown` is not a synonym for `ok`, and the distinction is the whole point: the
+ * pre-existing snapshot recorded status `ok` with `balance_remaining = null` for
+ * blitzapi and contactout on all 353 rows of the last 30 days, and would have
+ * recorded `ok` at a balance of 0 too. "We asked and got no number" must never read
+ * as "there is money".
+ */
+export type ProviderBalanceStatus = "ok" | "low" | "exhausted" | "unknown" | "not_monitored" | "auth_error" | "rate_limited" | "error";
+/** The statuses the P1 balance monitor alerts on. Anything else is informational. */
+export declare const ALERTING_PROVIDER_BALANCE_STATUSES: readonly ProviderBalanceStatus[];
+/**
+ * Default low-balance floor, in the provider's OWN unit (almost always provider
+ * credits). 1,000 is not a round number chosen for looking tidy — it is roughly
+ * three to eight days of measured burn for the credit providers OXYGEN funds,
+ * taken from `provider_balance_snapshots` in the prod control DB on 2026-09-07
+ * over the preceding 30 days:
+ *
+ *   bettercontact   10,130 -> 364    (~325/day)  ~3 days of head-room at 1,000
+ *   leadmagic        7,702 -> 903    (~227/day)  ~4 days
+ *   millionverifier 41,357 -> 37,695 (~122/day)  ~8 days
+ *   ai_ark          10,000 -> 9,813  (~6/day)    months
+ *
+ * A floor is a claim about how the account behaved when it was measured, nothing
+ * more. Re-measure it rather than nudging it when it turns out to be noisy — the
+ * monitor changelog exists for exactly that conversation.
+ */
+export declare const DEFAULT_MANAGED_BALANCE_FLOOR = 1000;
+/**
+ * Per-provider floors, and the providers that are deliberately NOT balance-monitored
+ * (`null`). Only entries that the default gets wrong are listed; everything else
+ * inherits DEFAULT_MANAGED_BALANCE_FLOOR.
+ */
+export declare const MANAGED_BALANCE_FLOORS: Readonly<Record<string, number | null>>;
+/** `OXYGEN_MANAGED_BALANCE_FLOOR_FIRECRAWL`, `..._AI_ARK`, ... */
+export declare function managedBalanceFloorEnvVar(provider: string): string;
+/**
+ * The floor in force for one provider. `null` means "do not judge this balance".
+ *
+ * The env override is the operator's escape hatch between deploys: a top-up that
+ * changes the plan size, or a provider that turns out to be noisy at the default,
+ * is one Doppler value away from being right. `off`/`none`/`disabled` switches the
+ * provider off the monitor entirely; an unparseable or negative value is IGNORED
+ * rather than obeyed, because a typo must not silently disarm an alert.
+ */
+export declare function managedBalanceFloor(provider: string, env?: Record<string, string | undefined>): number | null;
+export type ProviderBalanceVerdict = {
+    status: ProviderBalanceStatus;
+    /** The single boolean the monitor's description tells a responder to read. */
+    balanceLow: boolean;
+    /** The floor actually applied, after the env override. `null` = not monitored. */
+    floor: number | null;
+    level: "info" | "warn" | "error";
+};
+/**
+ * Turn one balance reading into the verdict both producers log.
+ *
+ * Pure on purpose: the thresholds are the alerting policy, so they are unit-testable
+ * without a provider, a cron, or a network.
+ */
+export declare function classifyManagedBalance(input: {
+    provider: string;
+    /** The balance fetcher's own status. Anything but "ok" means we are blind. */
+    fetchStatus: "ok" | "auth_error" | "rate_limited" | "error";
+    balanceRemaining: number | null;
+    env?: Record<string, string | undefined>;
+}): ProviderBalanceVerdict;