@aglyn/aglyn 1.0.0-beta.143

package/src/lib/app-utils/health-report.js

@@ -0,0 +1,2072 @@
+/**
+ * @license
+ * Copyright 2026 Aglyn LLC
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */ /**
+ * Shared shape for the `/api/health` endpoints (AGL-1102).
+ *
+ * Both the console and the tenant runtime answer this, and they must answer it
+ * IDENTICALLY — an uptime series is only comparable across services if the
+ * status codes and the field names agree. Two near-identical route files would
+ * have drifted the first time one of them was touched.
+ *
+ * The rules encoded here, each of which is a way health checks routinely lie:
+ *
+ * **The status code is the contract.** Most uptime monitors read nothing else,
+ * so a degraded dependency has to be a 503. A 200 whose body says "degraded"
+ * is a signal nobody receives.
+ *
+ * **Never cacheable.** A cached health check returns 200 from the edge while
+ * the origin is on fire, and the graph stays green straight through the
+ * outage. Three separate caches have faked a green check in this repo already,
+ * so this sets `no-store` on every response including the failures — an error
+ * response is the one you least want served from a cache.
+ *
+ * **No internals in the body.** It is public and unauthenticated, so a failing
+ * check reports a CODE and never the underlying message, which can carry
+ * project ids, paths or credentials fragments.
+ */ import { _ as _extends } from "@swc/helpers/_/_extends";
+export const HEALTH_NO_STORE = 'no-store, no-cache, must-revalidate, max-age=0';
+/** Degraded if ANY check failed. There is no partial credit for uptime. */ export function healthStatus(checks) {
+    return Object.values(checks).every((check)=>check.ok) ? 'ok' : 'degraded';
+}
+export function healthBody(report) {
+    var _report_commit, _report_version, _report_environment, _report_region, _report_at;
+    return {
+        status: healthStatus(report.checks),
+        service: report.service,
+        checks: report.checks,
+        commit: (_report_commit = report.commit) != null ? _report_commit : null,
+        version: (_report_version = report.version) != null ? _report_version : null,
+        environment: (_report_environment = report.environment) != null ? _report_environment : null,
+        region: (_report_region = report.region) != null ? _report_region : null,
+        at: (_report_at = report.at) != null ? _report_at : new Date().toISOString()
+    };
+}
+export function healthHeaders(status) {
+    return _extends({
+        'Cache-Control': HEALTH_NO_STORE,
+        // Readable from any origin, deliberately.
+        //
+        // A status page must not live on the thing it reports on, so it is served
+        // from a DIFFERENT deployment and reads these cross-origin. Without this
+        // header the browser blocks the read and the page renders every service as
+        // down during a perfectly healthy day — a status page that cries outage is
+        // worse than none.
+        //
+        // Safe to open: the body is already public and unauthenticated, carries no
+        // secrets, and a failing check reports a code rather than a message.
+        'Access-Control-Allow-Origin': '*'
+    }, status === 'ok' ? {} : {
+        'Retry-After': '30'
+    });
+}
+export function healthHttpStatus(status) {
+    return status === 'ok' ? 200 : 503;
+}
+/**
+ * A HEAD response for a health endpoint: the SAME status and headers its GET
+ * would return, with no body (AGL-1148).
+ *
+ * ## Why this exists
+ *
+ * Every health route used to answer HEAD with a hardcoded `200` and the
+ * comment "cheap liveness for monitors that only issue HEAD. Touches
+ * nothing." Touching nothing is precisely the problem: **a HEAD that knows
+ * nothing is a health check that cannot go red.** A monitor configured with
+ * HEAD — which several uptime providers use by default — would have reported
+ * green through any outage that left the function able to boot, which is most
+ * of them. `/api/health/crons` sat at 503 for fifty-one hours; a HEAD monitor
+ * pointed at it would have agreed with the green board the whole time.
+ *
+ * It also violated the contract this file opens with. "The status code is the
+ * contract" cannot hold for one method and not another, and HTTP requires a
+ * HEAD response to carry the same status and headers its GET would.
+ *
+ * ## The cost argument, which is why this is safe
+ *
+ * Delegating to GET means HEAD runs the dependency probe. Every route
+ * memoizes that probe (`memoizeWithTtl`, 15s on the root and 5 minutes on the
+ * subsystems) explicitly so a public unauthenticated endpoint cannot be made
+ * to read in a loop — the same bound that already lets a fifteen-minute probe
+ * hit seven endpoints for nearly nothing. HEAD now costs exactly what GET
+ * costs, which is a memo lookup between refreshes, and it serializes no body.
+ *
+ * Headers are carried over rather than rebuilt so `Cache-Control: no-store`,
+ * the open CORS origin and `Retry-After` reach a HEAD client identically — a
+ * HEAD response that was cacheable while its GET was not would be the same
+ * lie one layer down.
+ */ export async function healthHeadOf(get) {
+    const response = await get();
+    return new Response(null, {
+        status: response.status,
+        headers: response.headers
+    });
+}
+/**
+ * Weekly Sunday schedule + one day of slack. A healthy cadence never exceeds
+ * 7; day 8 means the last run produced nothing usable.
+ */ export const MAX_BACKUP_AGE_DAYS = 8;
+/**
+ * States in which a backup has not FAILED — it is simply not usable yet.
+ *
+ * `STATE_UNSPECIFIED` is a real member of the API's `Backup.State` enum ("The
+ * state is unspecified"), and proto3 JSON omits a default-valued field, so a
+ * backup in it arrives with **no `state` key at all**. Treating that absence
+ * as a failure is the `strictNullChecks`-off trap this file is otherwise
+ * careful about: a missing field must never fold into a red.
+ */ const BACKUP_IN_FLIGHT = new Set([
+    'CREATING',
+    'STATE_UNSPECIFIED'
+]);
+/**
+ * `backups` is the listing, or `null` when it could not be read at all.
+ *
+ * `options.unreachable` is `ListBackupsResponse.unreachable` — the locations
+ * the API could not reach. Non-empty means the listing is a PARTIAL result
+ * set. `options.code` is the code to report when `backups` is `null`.
+ */ export function backupsHealth(backups, ms, now = Date.now(), options = {}) {
+    var _options_unreachable;
+    // ## THE THREE STATES (AGL-1843, second pass)
+    //
+    // This check used to have two: healthy, and failed. Everything it could not
+    // establish — an upstream that errored, a partial listing, a run that had
+    // not finished — collapsed into "backup failed", which is the loudest thing
+    // it can say and was, in every one of those cases, false. It reported 503
+    // `backup-failed` continuously for four and a half days while the backups
+    // were fine, against a monitor that emails on a five-minute interval.
+    //
+    // ### Why `NOT_AVAILABLE` is not a failure — measured, not assumed
+    //
+    // The API documents the state as "The backup is not available **at this
+    // moment**", and that temporal wording is literal. The same three backup
+    // ids, read from `gcloud firestore backups list` on three dates:
+    //
+    //   id          2026-08-13      2026-08-17/18    2026-08-24
+    //   3b5238df…   NOT_AVAILABLE   NOT_AVAILABLE    READY
+    //   eb4d21e3…   READY           NOT_AVAILABLE    READY
+    //   d14ce827…   —               READY            READY
+    //
+    // `NOT_AVAILABLE` flips in BOTH directions, on backups whose `expireTime`
+    // is months away, independent of age. The 2026-08-02 backup that AGL-1490
+    // was filed about — "half the Firestore backups are NOT_AVAILABLE" — is
+    // READY today, twenty-two days old. It was never broken. Neither was the
+    // 2026-08-09 one, which went READY → NOT_AVAILABLE → READY. And the
+    // predicted permanent day-7 degradation did not happen: d14ce827 is READY
+    // at day 8. So every rule that reads a `NOT_AVAILABLE` count as damage is
+    // reading a maintenance window as an outage.
+    //
+    // ### What the check actually needs to answer
+    //
+    // "Can we restore, and is the restore point recent?" That question is
+    // answered ENTIRELY by the age of the newest READY backup. No other row in
+    // the listing can make a fresh READY backup un-restorable. So a fresh READY
+    // backup is unconditionally green, and everything below it is the taxonomy
+    // of why we could not find one.
+    //
+    // ### Why indeterminate answers 200, and why that is not fail-open
+    //
+    // Three things bound it, because a backups check that cannot go red is
+    // worse than no backups check:
+    //   1. It is time-bounded. Indeterminacy is only tolerated while a backup
+    //      younger than `MAX_BACKUP_AGE_DAYS` exists. A schedule that stops, or
+    //      that never produces anything usable, crosses the budget and goes red
+    //      within eight days whatever the states say.
+    //   2. It never overrides staleness. If a READY backup exists and is over
+    //      budget, that is `backup-stale` — a newer CREATING or NOT_AVAILABLE
+    //      row earns no freshness credit, so a run that hangs every week cannot
+    //      hold the check green.
+    //   3. The route classifies PERMANENT upstream failures (no credential,
+    //      401/403/404) as hard red rather than indeterminate, so a revoked IAM
+    //      role cannot silence this forever. And `checks.exports` in the same
+    //      endpoint is an independent, still-hard-red probe of the GCS copy:
+    //      "we cannot read the managed backups" answers 200 only while we can
+    //      still prove a fresh independent copy exists.
+    //
+    // State 3a — the listing could not be read AT ALL. That is not a verdict;
+    // it is the absence of one, and reporting it as `backup-failed` is the
+    // defect this pass exists to remove.
+    if (backups === null) {
+        var _options_code;
+        return {
+            ok: true,
+            ms,
+            code: (_options_code = options.code) != null ? _options_code : 'backups-unreadable',
+            states: {},
+            newestReadyAgeDays: null,
+            determinate: false
+        };
+    }
+    const states = {};
+    for (const backup of backups){
+        var _backup_state, _states_state;
+        const state = (_backup_state = backup.state) != null ? _backup_state : 'STATE_UNSPECIFIED';
+        states[state] = ((_states_state = states[state]) != null ? _states_state : 0) + 1;
+    }
+    const snapshotMsOf = (backup)=>backup.snapshotTime ? Date.parse(backup.snapshotTime) : Number.NaN;
+    const newestOf = (keep)=>backups.filter(keep).map(snapshotMsOf).filter((time)=>Number.isFinite(time)).reduce((newest, time)=>Math.max(newest != null ? newest : time, time), null);
+    const ageDaysOf = (time)=>Math.round((now - time) / 86400000 * 10) / 10;
+    const newestReadyMs = newestOf((backup)=>backup.state === 'READY');
+    const newestAnyMs = newestOf(()=>true);
+    const newestReadyAgeDays = newestReadyMs === null ? null : ageDaysOf(newestReadyMs);
+    const newestAnyAgeDays = newestAnyMs === null ? null : ageDaysOf(newestAnyMs);
+    // State 1 — HEALTHY. A restore point exists and it is recent. Nothing else
+    // in the listing can falsify that, so nothing else is consulted.
+    if (newestReadyAgeDays !== null && newestReadyAgeDays <= MAX_BACKUP_AGE_DAYS) {
+        return {
+            ok: true,
+            ms,
+            states,
+            newestReadyAgeDays
+        };
+    }
+    // State 2a — FAILED. A backup that is neither READY nor in flight and that
+    // carries no usable `snapshotTime` cannot be aged at all, so we cannot even
+    // say when the last run was. That is positive evidence of something wrong,
+    // and "assume it aged out" is the assumption that hides a broken run.
+    const undateable = backups.some((backup)=>{
+        var _backup_state;
+        return backup.state !== 'READY' && !BACKUP_IN_FLIGHT.has((_backup_state = backup.state) != null ? _backup_state : 'STATE_UNSPECIFIED') && !Number.isFinite(snapshotMsOf(backup));
+    });
+    if (undateable) {
+        return {
+            ok: false,
+            ms,
+            code: 'backup-failed',
+            states,
+            newestReadyAgeDays
+        };
+    }
+    // State 3b — the listing is a PARTIAL result set. `ListBackupsResponse`
+    // carries `unreachable`: rather than failing the request when one location
+    // cannot be reached, the API returns the backups it could see and names the
+    // ones it could not. Positive evidence survives that (state 1 above already
+    // returned); negative evidence does not — "we saw no fresh READY backup" is
+    // not a finding when we did not see everything.
+    if (((_options_unreachable = options.unreachable) != null ? _options_unreachable : []).length > 0) {
+        return {
+            ok: true,
+            ms,
+            code: 'backups-partial',
+            states,
+            newestReadyAgeDays,
+            determinate: false
+        };
+    }
+    // State 3c — a recent run exists, it simply is not usable AT THIS MOMENT:
+    // mid-creation on a Sunday, or inside one of the `NOT_AVAILABLE` windows
+    // measured above. Only reachable when NOTHING is READY — a stale READY
+    // backup falls through to `backup-stale` below, so this can never buy a
+    // hanging schedule more than the eight-day budget.
+    if (newestReadyAgeDays === null && newestAnyAgeDays !== null && newestAnyAgeDays <= MAX_BACKUP_AGE_DAYS) {
+        return {
+            ok: true,
+            ms,
+            code: 'backups-not-ready-yet',
+            states,
+            newestReadyAgeDays,
+            determinate: false
+        };
+    }
+    // State 2b — FAILED on freshness. Either nothing has ever been READY and
+    // nothing recent exists to be waiting on, or the newest READY backup is
+    // past the budget. Both mean the same operational thing: there is no recent
+    // restore point, which is the only fact this check exists to protect.
+    return {
+        ok: false,
+        ms,
+        code: newestReadyAgeDays === null ? 'no-ready-backup' : 'backup-stale',
+        states,
+        newestReadyAgeDays
+    };
+}
+/**
+ * Weekly cadence (Mondays, `scheduled-crons.yml`) + one day of slack — the
+ * same budget as `MAX_BACKUP_AGE_DAYS`, for the same reason: a schedule that
+ * stops producing is as broken as one that fails.
+ */ export const MAX_EXPORT_AGE_DAYS = 8;
+export function exportsHealth(markers, ms, now = Date.now()) {
+    // A failed listing is degraded, not ok — same rule as `signupsHealth` and
+    // `rateLimitsHealth`: an alarm that cannot see the thing it watches must
+    // say so rather than report calm.
+    if (markers === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'exports-unavailable',
+            exportCount: null,
+            newestExportAgeDays: null
+        };
+    }
+    const newestMs = markers.map((marker)=>{
+        var _marker_timeCreated;
+        return Date.parse((_marker_timeCreated = marker.timeCreated) != null ? _marker_timeCreated : '');
+    }).filter((time)=>Number.isFinite(time)).reduce((newest, time)=>Math.max(newest != null ? newest : time, time), null);
+    const newestExportAgeDays = newestMs === null ? null : Math.round((now - newestMs) / 86400000 * 10) / 10;
+    // The cron exists, so "no exports" is a failure, not a fresh start — the
+    // first export ran 2026-08-17, before this check first deployed.
+    const code = newestExportAgeDays === null ? 'no-export' : newestExportAgeDays > MAX_EXPORT_AGE_DAYS ? 'export-stale' : undefined;
+    return _extends({
+        ok: code === undefined,
+        ms
+    }, code === undefined ? {} : {
+        code
+    }, {
+        exportCount: markers.length,
+        newestExportAgeDays
+    });
+}
+/** Trailing window the org-creation count covers. */ export const ORG_CREATION_WINDOW_MINUTES = 60;
+/**
+ * Degraded above 10 creations/hour. Calibrated against two facts: production
+ * holds 4 orgs TOTAL (2026-08), so the organic baseline is ~zero per hour;
+ * and the AGL-1534 per-IP cap is 10/h, so a single maxed-out address can
+ * never trip this — 11+/h necessarily means multiple addresses, which is
+ * exactly the distributed signature the rate limiter cannot see. If a launch
+ * day legitimately beats this, the alert asks a human to glance at the orgs
+ * list and enjoy the view; that is the correct outcome, not a false positive.
+ */ export const MAX_ORG_CREATIONS_PER_WINDOW = 10;
+export function signupsHealth(recentOrgCreations, ms, threshold = MAX_ORG_CREATIONS_PER_WINDOW) {
+    // A failed count is degraded, not ok — an alarm that cannot see the thing
+    // it watches must say so rather than report calm.
+    const code = recentOrgCreations === null ? 'count-unavailable' : recentOrgCreations > threshold ? 'signup-wave' : undefined;
+    return _extends({
+        ok: code === undefined,
+        ms
+    }, code === undefined ? {} : {
+        code
+    }, {
+        recentOrgCreations,
+        windowMinutes: ORG_CREATION_WINDOW_MINUTES,
+        threshold
+    });
+}
+/**
+ * Trailing window the refusal count covers. One hour, matching the limiter's
+ * own window (`org-create` is 3/h and 10/h) so the number is readable against
+ * the caps that produced it.
+ */ export const SIGNUP_REFUSAL_WINDOW_MINUTES = 60;
+/**
+ * Degraded above 50 refusals/hour.
+ *
+ * Not zero, unlike the limiter-degradation alarm: a refusal is the system
+ * working, and a real person who fumbles a workspace slug four times in an
+ * hour produces one. The number that means something is *sustained* refusal.
+ * Calibrated the same way AGL-1536's was: production holds single-digit orgs
+ * (2026-08), so organic refusals are ~zero per hour, and 50 is far above any
+ * plausible human while being reached in under a minute by a script. One
+ * determined address can generate this alone — that is intended, because "one
+ * address is hammering the signup door" is worth an email even though the
+ * limiter is containing it.
+ */ export const MAX_SIGNUP_REFUSALS_PER_WINDOW = 50;
+/**
+ * The marker field the blocking function counts blind decisions under
+ * (AGL-2583).
+ *
+ * `signupsCreationVerdict` answers `locked` when a completed read found the
+ * lever pulled, `held` when a failed read fell back on an earlier one that
+ * had, and — the case this names — admits the account when the read failed
+ * and nothing remembered said the lever was pulled. That last one refuses
+ * nobody, so it is not a `byReason` entry; it is the platform deciding the
+ * signups question without being able to consult it, which is the visible
+ * edge of a Firestore read outage on the account-creation path. AGL-2581 was
+ * three days of that same read failing, and its only trace was a
+ * `logger.warn` nothing alerts on.
+ */ export const SIGNUP_LOCK_UNREADABLE_FIELD = 'unreadable';
+/**
+ * Blind signups-lock decisions tolerated per window: NONE.
+ *
+ * Deliberately not calibrated like `MAX_SIGNUP_REFUSALS_PER_WINDOW` above,
+ * which is a volume threshold over refusals that mean the system is working.
+ * A blind decision is never routine — a single one says the signups lock was
+ * unreadable at least once, and the lock is unenforceable for as long as that
+ * lasts. False positives here cost a glance at one endpoint.
+ */ export const MAX_UNREADABLE_SIGNUP_DECISIONS_PER_WINDOW = 0;
+export function signupRefusalsHealth(markers, ms, now = Date.now(), threshold = MAX_SIGNUP_REFUSALS_PER_WINDOW, windowMinutes = SIGNUP_REFUSAL_WINDOW_MINUTES, unreadableThreshold = MAX_UNREADABLE_SIGNUP_DECISIONS_PER_WINDOW) {
+    // A failed query is degraded, not ok — the same rule `signupsHealth` and
+    // `rateLimitsHealth` follow. An alarm that cannot see the thing it watches
+    // must not report calm.
+    if (markers === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'refusals-unavailable',
+            refusedSignups: null,
+            refusedByReason: null,
+            lockUnreadable: null,
+            minutesSinceLast: null,
+            windowMinutes,
+            threshold
+        };
+    }
+    let refusedSignups = 0;
+    let lockUnreadable = 0;
+    let newestAtMs = null;
+    const refusedByReason = {};
+    for (const marker of markers){
+        var _marker_refusals, _marker_byReason;
+        refusedSignups += (_marker_refusals = marker.refusals) != null ? _marker_refusals : 0;
+        // `Number(...) || 0` for the reason the split below gives: a corrupt
+        // Firestore field must not turn this into NaN, which compares false
+        // against every threshold and would report calm forever.
+        lockUnreadable += Number(marker.unreadable) || 0;
+        for (const [reason, count] of Object.entries((_marker_byReason = marker.byReason) != null ? _marker_byReason : {})){
+            var _refusedByReason_reason;
+            // `Number(...) || 0` rather than a bare add: these come out of Firestore
+            // and a corrupt field must not turn the total into NaN, which compares
+            // false against the threshold and would report calm forever.
+            refusedByReason[reason] = ((_refusedByReason_reason = refusedByReason[reason]) != null ? _refusedByReason_reason : 0) + (Number(count) || 0);
+        }
+        const at = marker.refusedAtMs;
+        if (typeof at === 'number' && (newestAtMs === null || at > newestAtMs)) {
+            newestAtMs = at;
+        }
+    }
+    const over = refusedSignups > threshold;
+    // The blind count is graded FIRST and reported over the volume code. A wave
+    // and an unreadable lock call for opposite responses — leave the limiter
+    // alone and go read the refusal reasons, versus go find out why Firestore
+    // is unreadable from the account-creation path — so the code has to name
+    // the one that is actually happening.
+    const blind = lockUnreadable > unreadableThreshold;
+    const code = blind ? 'signups-lock-unreadable' : over ? 'signup-refusal-wave' : undefined;
+    return _extends({
+        ok: code === undefined,
+        ms
+    }, code === undefined ? {} : {
+        code
+    }, {
+        refusedSignups,
+        refusedByReason,
+        lockUnreadable,
+        minutesSinceLast: newestAtMs === null ? null : Math.max(0, Math.floor((now - newestAtMs) / 60000)),
+        windowMinutes,
+        threshold
+    });
+}
+/**
+ * Trailing window the drought verdict covers. One hour, matching the sibling
+ * checks so the three numbers on this endpoint are all read against the same
+ * clock — and long enough that a single slow afternoon does not page anyone.
+ */ export const SIGNUP_DROUGHT_WINDOW_MINUTES = 60;
+/**
+ * Attempts in the window below which zero accounts means nothing.
+ *
+ * Three, against attempts rather than the five it once meant against serves
+ * (AGL-2714). The unit changed, so the number had to be re-argued rather than
+ * carried over.
+ *
+ * Not one: a browser can lose a request, and a person can start the form and
+ * abandon it between authenticating and the org write. Not ten either — at a
+ * handful of signups a week, waiting for ten attempts to fail would mean
+ * waiting days to notice a door that stopped opening, which is the failure
+ * this check exists to catch inside an hour.
+ *
+ * Three distinct requests to create an org, none of which produced one and
+ * none of which was refused, is a door that does not open. That reading has
+ * no quiet-hour interpretation: nobody attempts three times by browsing.
+ */ export const MIN_SIGNUP_TRAFFIC_FOR_DROUGHT = 3;
+export function signupDroughtHealth(markers, attemptMarkers, orgCreations, ms, minimumTraffic = MIN_SIGNUP_TRAFFIC_FOR_DROUGHT, windowMinutes = SIGNUP_DROUGHT_WINDOW_MINUTES) {
+    // Serves are context, not the verdict, so they are summed wherever they are
+    // readable and reported as null when they are not — a missing context line
+    // must not decide anything on its own.
+    let signupPagesServed = null;
+    if (markers !== null) {
+        signupPagesServed = 0;
+        for (const marker of markers){
+            // `Number(...) || 0` for the reason the sibling gives: a corrupt
+            // Firestore field must not turn the total into NaN, which compares
+            // false against every threshold and would report calm forever.
+            signupPagesServed += Number(marker.serves) || 0;
+        }
+    }
+    // A failed ATTEMPT query is degraded, not ok — the same rule the siblings
+    // follow. Without the denominator this check has no opinion at all, and a
+    // check with no opinion must not spend it saying everything is fine.
+    if (attemptMarkers === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'traffic-unavailable',
+            signupPagesServed,
+            signupAttempts: null,
+            orgCreations,
+            windowMinutes,
+            minimumTraffic
+        };
+    }
+    let signupAttempts = 0;
+    for (const marker of attemptMarkers){
+        signupAttempts += Number(marker.attempts) || 0;
+    }
+    if (orgCreations === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'count-unavailable',
+            signupPagesServed,
+            signupAttempts,
+            orgCreations: null,
+            windowMinutes,
+            minimumTraffic
+        };
+    }
+    // The whole verdict: people ASKED for an org and NOT ONE of them got it.
+    const drought = signupAttempts >= minimumTraffic && orgCreations === 0;
+    return _extends({
+        ok: !drought,
+        ms
+    }, drought ? {
+        code: 'signup-drought'
+    } : {}, {
+        signupPagesServed,
+        signupAttempts,
+        orgCreations,
+        windowMinutes,
+        minimumTraffic
+    });
+}
+/**
+ * Trailing window the degradation counts cover.
+ *
+ * Bounded from below by the alert path, not by taste. The probe memoizes for
+ * `HEALTH_PROBE_TTL_MS` (2 minutes), the slowest check on this door runs
+ * every 15, and the alert policy wants a minute of sustained failure — so a
+ * window shorter than ~18 minutes can go red and green again before that
+ * check tells anyone, which is a check that reports nothing while looking
+ * like it works. 30 leaves margin and still clears itself inside half an hour.
+ */ export const RATE_LIMIT_DEGRADED_WINDOW_MINUTES = 30;
+/**
+ * Any fallback at all is worth an email. Unlike the signup alarm there is no
+ * organic baseline to clear: a healthy deployment produces exactly zero of
+ * these, and one is already the statement "for some requests, the global cap
+ * was not the cap". Firestore retries transactions internally, so a failure
+ * that reaches this code is not a single unlucky contention.
+ */ export const MAX_DEGRADED_CALLS_PER_WINDOW = 0;
+export function rateLimitsHealth(markers, ms, now = Date.now(), threshold = MAX_DEGRADED_CALLS_PER_WINDOW, windowMinutes = RATE_LIMIT_DEGRADED_WINDOW_MINUTES) {
+    // A failed query is degraded, not ok — same rule as `signupsHealth`. An
+    // alarm that cannot see the thing it watches must not report calm, and this
+    // one reads the collection that just failed for the limiter.
+    if (markers === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'markers-unavailable',
+            degradedCalls: null,
+            degradedEpisodes: null,
+            minutesSinceLast: null,
+            windowMinutes,
+            threshold
+        };
+    }
+    const cutoff = now - windowMinutes * 60000;
+    // The window is re-applied here rather than trusted from the query, so the
+    // rule lives in one spec-covered place and a marker whose `lastAtMs` is
+    // missing cannot silently count as recent.
+    const recent = markers.filter((marker)=>typeof marker.lastAtMs === 'number' && marker.lastAtMs >= cutoff);
+    const degradedCalls = recent.reduce((total, marker)=>total + (Number(marker.calls) || 0), 0);
+    const degradedEpisodes = recent.reduce((total, marker)=>total + (Number(marker.episodes) || 0), 0);
+    const lastAtMs = recent.reduce((latest, marker)=>Math.max(latest != null ? latest : -Infinity, marker.lastAtMs), null);
+    return _extends({
+        ok: degradedCalls <= threshold,
+        ms
+    }, degradedCalls <= threshold ? {} : {
+        code: 'rate-limiter-degraded'
+    }, {
+        degradedCalls,
+        degradedEpisodes,
+        minutesSinceLast: lastAtMs === null ? null : Math.round((now - lastAtMs) / 60000 * 10) / 10,
+        windowMinutes,
+        threshold
+    });
+}
+/**
+ * Trailing window the error count covers.
+ *
+ * Bounded from below by the alert path, not by taste — the same arithmetic as
+ * `RATE_LIMIT_DEGRADED_WINDOW_MINUTES`: the probe memoizes for 2 minutes, the
+ * slowest external check runs every 15, and an alert policy wants a minute of
+ * sustained failure, so a window under ~18 minutes can go red and green again
+ * before that check tells anyone. 30 leaves margin and still clears itself
+ * inside half an hour of the last error.
+ */ export const SERVER_ERROR_WINDOW_MINUTES = 30;
+/**
+ * Errors tolerated in the window.
+ *
+ * NOT zero, unlike the rate-limiter and billing alarms, and the difference is
+ * real rather than a matter of nerve. Those two watch controls that a healthy
+ * deployment exercises exactly never. This one watches a count that a single
+ * cold-start Firestore deadline, or one visitor's malformed request reaching a
+ * route that throws instead of 400ing, can make non-zero on a perfectly good
+ * day — and an alarm that pages on the first of those gets muted before the
+ * one that matters arrives.
+ *
+ * Five over thirty minutes is chosen against the only two facts available.
+ * Production serves single-digit orgs (2026-08), so the organic rate of
+ * UNCAUGHT server errors is ~zero — the codebase answers its expected failures
+ * with 4xx, and reaching this hook means nothing handled it. And the shape
+ * being caught is "a route is failing for real users", which does not produce
+ * six errors an hour; it produces six in a minute. There is deliberately no
+ * pretence of calibration: the beta window exists to produce a baseline, and
+ * `SERVER_ERROR_ALARM_MAX_ERRORS` moves this without a deploy when it does.
+ */ export const MAX_SERVER_ERRORS_PER_WINDOW = 5;
+export function serverErrorsHealth(markers, ms, now = Date.now(), threshold = MAX_SERVER_ERRORS_PER_WINDOW, windowMinutes = SERVER_ERROR_WINDOW_MINUTES) {
+    // ⚠️ THE MEASURED ZERO. A failed query is degraded, never calm, and on this
+    // check that is not a convention borrowed from its siblings — it is the
+    // whole reason the check is trustworthy. "We could not count the errors"
+    // and "there were no errors" are the same JSON if this branch is missing,
+    // and the first is most likely precisely when the second is false.
+    if (markers === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'errors-unavailable',
+            serverErrors: null,
+            byService: null,
+            minutesSinceLast: null,
+            windowMinutes,
+            threshold
+        };
+    }
+    const cutoff = now - windowMinutes * 60000;
+    // The window is re-applied here rather than trusted from the query, so the
+    // rule lives in one spec-covered place and a marker whose `erroredAtMs` is
+    // missing cannot silently count as recent. `strictNullChecks` is off
+    // repo-wide, so an absent field would otherwise compare as 0 and fall
+    // outside every window forever — a marker that can never be counted.
+    const recent = markers.filter((marker)=>typeof marker.erroredAtMs === 'number' && marker.erroredAtMs >= cutoff);
+    const byService = {};
+    let serverErrors = 0;
+    let lastAtMs = null;
+    for (const marker of recent){
+        var _marker_byService;
+        // `Number(...) || 0` rather than a bare add: these come out of Firestore
+        // and a corrupt field must not turn the total into NaN, which compares
+        // false against the threshold and would report calm forever.
+        serverErrors += Number(marker.errors) || 0;
+        for (const [service, count] of Object.entries((_marker_byService = marker.byService) != null ? _marker_byService : {})){
+            var _byService_service;
+            byService[service] = ((_byService_service = byService[service]) != null ? _byService_service : 0) + (Number(count) || 0);
+        }
+        const at = marker.erroredAtMs;
+        if (lastAtMs === null || at > lastAtMs) lastAtMs = at;
+    }
+    const over = serverErrors > threshold;
+    return _extends({
+        ok: !over,
+        ms
+    }, over ? {
+        code: 'server-error-spike'
+    } : {}, {
+        serverErrors,
+        byService,
+        minutesSinceLast: lastAtMs === null ? null : Math.max(0, Math.round((now - lastAtMs) / 60000 * 10) / 10),
+        windowMinutes,
+        threshold
+    });
+}
+/**
+ * How long a health door may reuse its verdict (AGL-2947).
+ *
+ * Cut from one budget: an outage must reach a person within ten minutes. A
+ * green verdict computed just before the onset keeps being served for this
+ * long, and only then can a prober see red. The fastest prober on most doors
+ * is UptimeRobot, every five minutes, which then confirms before it notifies.
+ * So the worst case is this + 5 + that confirmation: at two minutes the budget
+ * holds for any confirmation delay up to three. The five minutes every door
+ * used before spent the whole ten minutes before a notification could leave.
+ *
+ * It still bounds what a public door can be made to cost: at most one
+ * computation per instance per two minutes, and {@link memoizeWithTtl} shares
+ * a computation among the callers that arrive while it runs.
+ */ export const HEALTH_PROBE_TTL_MS = 2 * 60000;
+/**
+ * Reuse a probe result for `ttlMs`, per instance.
+ *
+ * The endpoint is public and unauthenticated, so an unthrottled dependency
+ * check is a free amplifier: anyone could turn a loop into database reads on
+ * our account. This bounds the cost to one probe per instance per interval
+ * however hard it is hit.
+ *
+ * Callers that arrive while a probe is running share it rather than starting
+ * their own. The uptime check's regions, UptimeRobot and a HEAD twin routinely
+ * land within the same second of an expired entry, and each used to pay for a
+ * full probe.
+ *
+ * FAILURES ARE CACHED TOO, deliberately. A dependency that is down will be
+ * down for the next caller as well, and re-probing per request turns an
+ * outage into a stampede against the thing that is already failing. A probe
+ * that THROWS is not cached: its callers all see the throw, and the next
+ * caller probes again.
+ */ export function memoizeWithTtl(ttlMs, probe, now = Date.now) {
+    let cached = null;
+    let inFlight = null;
+    return async ()=>{
+        const at = now();
+        const elapsed = cached ? at - cached.at : Infinity;
+        // `elapsed >= 0` is not paranoia. A plain `elapsed < ttlMs` treats a
+        // BACKWARDS clock as permanently fresh — the entry never expires and the
+        // endpoint reports a stale verdict forever, which on a health check means
+        // reporting healthy through an outage. Serverless instances outlive more
+        // clock weirdness than a local run suggests.
+        if (cached && elapsed >= 0 && elapsed < ttlMs) return cached.value;
+        if (inFlight) return inFlight;
+        const flight = (async ()=>{
+            const value = await probe();
+            cached = {
+                at,
+                value
+            };
+            return value;
+        })();
+        inFlight = flight;
+        // Cleared once settled, and only if it is still this flight. Clearing
+        // inside the flight would run BEFORE the assignment above when `probe`
+        // throws synchronously, and leave a rejected promise in the slot forever.
+        const clear = ()=>{
+            if (inFlight === flight) inFlight = null;
+        };
+        flight.then(clear, clear);
+        return flight;
+    };
+}
+/**
+ * Codes that mean the heartbeat got no ANSWER, as opposed to a refusal
+ * (AGL-2713).
+ *
+ * The distinction is the whole of the tolerance below, so it is named once
+ * and asserted directly rather than being spelled inline at the branch.
+ *
+ * - `credential-unavailable` — the admin app is configured and its credential
+ *   simply did not mint a token on this attempt. On a cold lambda that is the
+ *   first outbound TLS of the instance's life, and it is the measured shape of
+ *   both 2026-09-09 blips.
+ * - `transport-*` — the Logging write never came back inside its 4s deadline,
+ *   or the fetch layer failed. Same class: nothing was decided.
+ *
+ * Everything else is a DECISION and must never be tolerated. `http-401` and
+ * `http-403` are a lost `logging.logEntries.create` grant, `http-429` is
+ * quota, and `no-credential` is a deployment whose `FIREBASE_*` env is absent
+ * — every one of them permanent until a person fixes it, and every one of
+ * them a state in which browser errors are being collected by nothing. So is
+ * `heartbeat-unavailable`, which means a writer documented never to throw
+ * threw.
+ */ export function isTransientBeaconCode(code) {
+    return code === 'credential-unavailable' || (code != null ? code : '').startsWith('transport-');
+}
+/**
+ * ## Tolerating ONE miss without becoming a door that cannot red (AGL-2713)
+ *
+ * `/api/health/error-beacon` on the console answered `503 no-credential` twice
+ * on 2026-09-09 — 15:12 and 17:22 UTC, each shortly after new capacity from
+ * the 15:08 deploy, each self-clearing within minutes, with the beacon code
+ * path changed by one comment line since the previous release. Between them
+ * they took the 15-minute uptime workflow red and opened four GCP alert
+ * events, on a monitor whose entire value is that somebody believes it.
+ *
+ * The tolerance is deliberately NOT "forgive a failure". It is three
+ * conditions that must all hold, and each one is what keeps the door able to
+ * go red:
+ *
+ *  1. the code says nothing was decided ({@link isTransientBeaconCode});
+ *  2. a heartbeat is PROVEN to have landed within `graceMs` — proof being a
+ *     durable marker a successful write left behind, so a deployment whose
+ *     credential never worked has nothing to forgive with and reds on its
+ *     first probe;
+ *  3. that proof is not from the future, because a clock that ran backwards
+ *     must not mint an unbounded grace.
+ *
+ * Absence of proof reds. A marker store that cannot be read reds. That is the
+ * same rule the `*-unavailable` arms of every sibling grader apply, pointed at
+ * the evidence for calm rather than at the evidence for alarm.
+ */ export function beaconHealth(write, logId, service, ms, tolerance = {}) {
+    var _write_code;
+    const { attempts = 1, landedAtMs = null, graceMs = 0, now = Date.now() } = tolerance;
+    const sinceLanded = landedAtMs === null ? null : now - landedAtMs;
+    const base = {
+        ms,
+        logId,
+        service,
+        attempts,
+        minutesSinceHeartbeat: sinceLanded === null ? null : Math.max(0, Math.round(sinceLanded / 60000 * 10) / 10),
+        graceMinutes: Math.round(graceMs / 60000)
+    };
+    // A null result is degraded by contract, the same rule `signupsHealth` and
+    // `rateLimitsHealth` follow: an alarm that cannot see the thing it watches
+    // must not report calm. Here it is stronger than a convention — "we could
+    // not determine whether the beacon works" IS the AGL-1923 condition.
+    if (write === null) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'heartbeat-unavailable'
+        });
+    }
+    if (write.ok) return _extends({}, base, {
+        ok: true
+    });
+    const code = (_write_code = write.code) != null ? _write_code : 'heartbeat-failed';
+    if (isTransientBeaconCode(code) && sinceLanded !== null && sinceLanded >= 0 && sinceLanded <= graceMs) {
+        // Green, and saying so out loud. A tolerance nobody can see on the board
+        // is indistinguishable from a door that was widened until it stopped
+        // reporting, which is the failure this whole change had to avoid being.
+        return _extends({}, base, {
+            ok: true,
+            code: 'heartbeat-missed'
+        });
+    }
+    return _extends({}, base, {
+        ok: false,
+        code
+    });
+}
+export function renderHealth(outcome, host, ms) {
+    const base = {
+        ms,
+        host
+    };
+    switch(outcome.kind){
+        case 'rendered':
+            // Both halves are load-bearing. A host that resolved but composed
+            // nothing is a blank page served with a 200 — the exact outage a
+            // reachability ping calls healthy.
+            if (!outcome.hostResolved) {
+                return _extends({}, base, {
+                    ok: false,
+                    code: 'host-unresolved',
+                    nodeCount: outcome.nodeCount
+                });
+            }
+            if (outcome.nodeCount <= 0) {
+                return _extends({}, base, {
+                    ok: false,
+                    code: 'rendered-empty',
+                    nodeCount: 0
+                });
+            }
+            return _extends({}, base, {
+                ok: true,
+                nodeCount: outcome.nodeCount
+            });
+        case 'not-found':
+            return _extends({}, base, {
+                ok: false,
+                code: 'not-found',
+                nodeCount: 0
+            });
+        case 'redirect':
+            return _extends({}, base, {
+                ok: false,
+                code: 'redirected',
+                nodeCount: 0
+            });
+        case 'not-configured':
+            return _extends({}, base, {
+                ok: false,
+                code: 'not-configured',
+                nodeCount: 0
+            });
+        case 'unavailable':
+        default:
+            // Same rule as `beaconHealth`: "we could not determine whether the page
+            // renders" is a failure, never calm.
+            return _extends({}, base, {
+                ok: false,
+                code: 'render-unavailable',
+                nodeCount: 0
+            });
+    }
+}
+/**
+ * Trailing window the delivery counts cover.
+ *
+ * Bounded from below by the alert path, not by taste, exactly like
+ * `RATE_LIMIT_DEGRADED_WINDOW_MINUTES`: the probe memoizes for 5 minutes, the
+ * uptime check runs every 5, and the policy wants ~10 minutes of sustained
+ * failure before it emails — so a window under ~20 minutes can go red and
+ * green again before anyone is told. Bounded from ABOVE by Stripe's retry
+ * schedule: an event that fails and then succeeds on retry stops counting, so
+ * a window much longer than an hour would hold transient blips red past their
+ * own recovery.
+ */ export const WEBHOOK_FAILURE_WINDOW_MINUTES = 60;
+/**
+ * Failed deliveries tolerated in the window.
+ *
+ * Zero, and unlike the signup alarm there is no organic baseline to clear: a
+ * healthy account produces exactly zero, and one is already the statement
+ * "Stripe tried to tell us something about money and could not". Stripe
+ * retries on its own, so a failure visible here is not one unlucky packet.
+ */ export const MAX_FAILED_DELIVERIES_PER_WINDOW = 0;
+/**
+ * Inert deliveries tolerated in the window (AGL-1954).
+ *
+ * Zero — and unlike `processed`, the count this check reports but refuses to
+ * gate on because no defensible floor exists before the beta produces a
+ * baseline, this one's floor follows from the definition. A delivery is
+ * counted inert only when a required event type produced neither a committed
+ * effect nor a NAMED deliberate skip (`classifyWebhookDelivery`). No
+ * legitimate traffic pattern generates one: a tenant shopper's subscription,
+ * a marketplace refund, a `won` dispute nobody claimed all name their reason
+ * and classify as `ignored`. So any at all is the statement "Stripe told us
+ * about money and nothing here moved" — the same "any at all" rule the
+ * rate-limiter degradation markers use (AGL-1679).
+ */ export const MAX_INERT_DELIVERIES_PER_WINDOW = 0;
+/**
+ * Retried deliveries tolerated in the window (AGL-2039).
+ *
+ * Zero, and the reasoning is `MAX_FAILED_DELIVERIES_PER_WINDOW`'s: a delivery
+ * counted here is one whose FIRST attempt did not get through, which is a
+ * failed attempt that happened, not a statistical wobble. The healthy band
+ * measured against the live account is 1.0–3.7 seconds against a 120-second
+ * bar, so nothing organic sits anywhere near it.
+ *
+ * Cheap to be wrong in the safe direction, because this cannot latch: the
+ * window is trailing and the marker is on the event's own claim, so a single
+ * blip reds for at most one window and then clears itself — an event, not a
+ * condition (the AGL-1843 rule). It is a parameter rather than a literal so
+ * that if beta traffic turns out to produce organic retries, the knob is one
+ * argument and not a rewrite.
+ */ export const MAX_RETRIED_DELIVERIES_PER_WINDOW = 0;
+export function billingWebhookHealth(facts, ms, windowMinutes = WEBHOOK_FAILURE_WINDOW_MINUTES, threshold = MAX_FAILED_DELIVERIES_PER_WINDOW, inertThreshold = MAX_INERT_DELIVERIES_PER_WINDOW, retriedThreshold = MAX_RETRIED_DELIVERIES_PER_WINDOW) {
+    // A null census is degraded, the same rule `signupsHealth` and
+    // `rateLimitsHealth` follow: an alarm that cannot see the thing it watches
+    // must not report calm. Here it is also the AGL-1906 lesson — `unknown` was
+    // read as `healthy` on 2026-08-14 and the endpoint was 400ing every
+    // delivery at the time.
+    if (facts === null) {
+        return {
+            ok: false,
+            ms,
+            code: 'stripe-unavailable',
+            endpointStatus: null,
+            undelivered: null,
+            emitted: null,
+            processed: null,
+            inert: null,
+            retried: null,
+            unsubscribedEvents: null,
+            connectEndpoint: null,
+            unsubscribedConnectEvents: null,
+            windowMinutes
+        };
+    }
+    const base = {
+        ms,
+        endpointStatus: facts.endpointStatus,
+        undelivered: facts.undelivered,
+        emitted: facts.emitted,
+        processed: facts.processed,
+        inert: facts.inert,
+        retried: facts.retried,
+        unsubscribedEvents: facts.unsubscribedEvents,
+        connectEndpoint: facts.connectEndpoint,
+        unsubscribedConnectEvents: facts.unsubscribedConnectEvents,
+        windowMinutes
+    };
+    // Order matters: a missing or disabled destination explains any delivery
+    // count that follows, and is the more actionable statement. An endpoint
+    // deleted or switched off in the dashboard is TOTAL silent failure — Stripe
+    // stops attempting, so `undelivered` would read zero and a delivery-only
+    // rule would call it healthy.
+    if (facts.endpointStatus === 'missing') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'endpoint-missing'
+        });
+    }
+    if (facts.endpointStatus === 'disabled') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'endpoint-disabled'
+        });
+    }
+    // A required event the destination does not carry (AGL-1948 / AGL-1798),
+    // ABOVE the delivery counts because it explains a silence they cannot see.
+    // An unsubscribed event produces no delivery to fail, no request to reject
+    // and no inert handler either — Stripe simply stops sending, and every
+    // count below reads a perfectly healthy zero for as long as it lasts. It
+    // also outranks `deliveries-failing` on actionability: this one names the
+    // exact event to re-add, and `npm run setup:stripe` fixes it in a minute.
+    //
+    // `null` — the endpoint did not state its subscriptions — is deliberately
+    // NOT red. It is a question that went unanswered, not an answer, and the
+    // check already has `stripe-unavailable` for a census it could not take.
+    if (facts.unsubscribedEvents && facts.unsubscribedEvents.length > 0) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'events-unsubscribed'
+        });
+    }
+    if (facts.undelivered > threshold) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'deliveries-failing'
+        });
+    }
+    // THE 200-THAT-DID-NOTHING (AGL-1954), and it is LAST on purpose: every
+    // code above explains why a handler would have had nothing to do, so
+    // reporting inertness over one of them would name the symptom instead of
+    // the cause. Reached only when Stripe holds an enabled destination
+    // subscribed to everything we asked for and delivered successfully — at
+    // which point "a delivery moved nothing" has no innocent explanation left.
+    if (facts.inert !== null && facts.inert > inertThreshold) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'handlers-inert'
+        });
+    }
+    /*==========================================
+   * THE ATTEMPTS NOTHING ELSE HERE CAN COUNT (AGL-2039).
+   *
+   * `undelivered` above is `delivery_success=false`, a TERMINAL-state filter
+   * over EVENTS. An event that 400s three times and then succeeds on the
+   * fourth reads back `true`, so it is zero there and zero in `emitted`,
+   * `processed` and `inert` too — the handler DID eventually run. Every
+   * number on this check reports a healthy window while three real delivery
+   * attempts failed. That is not a hypothetical: it is the exact reading
+   * AGL-1906 produced, 0.00% against the Stripe Dashboard's 30%, and the
+   * three attempts the Dashboard was counting were AGL-1551's.
+   *
+   * BELOW `deliveries-failing` because an event failing every attempt
+   * explains an event that needed several, and below `handlers-inert`
+   * because a delivery that landed late and then moved nothing is worse than
+   * one that landed late and worked. ABOVE the Connect codes because this is
+   * this hour's revenue path and those are a slower rot.
+   *
+   * Null is not red: the marker is ours, so an unread Firestore is an
+   * unanswered question, and `stripe-unavailable` already covers a census we
+   * could not take.
+   *=========================================*/ if (facts.retried !== null && facts.retried > retriedThreshold) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'deliveries-retried'
+        });
+    }
+    /*==========================================
+   * THE CONNECT DESTINATION (AGL-1948, closing AGL-2122's blind spot).
+   *
+   * A SECOND destination, and every code above is about the first one. The
+   * platform destination can be enabled, fully subscribed, delivering and
+   * acting — the whole check green — while connected-account events reach
+   * nothing at all, because they are delivered only to a destination created
+   * with `connect: true`. AGL-2122 measured exactly that against the live
+   * account on 2026-08-18: one destination, correct URL, all ten events, and
+   * no Connect destination in existence. `account.updated` was handled in two
+   * plugins and could never be delivered, so `syncConnectAccountStatus` never
+   * ran and every merchant's charge-eligibility flag rotted where it stood.
+   *
+   * LAST on purpose, and for a different reason than `handlers-inert` above:
+   * not because the codes above explain it, but because they do not. It is an
+   * independent destination whose failure is slower — merchant readiness
+   * drifting out of date — while everything above is this hour's revenue. The
+   * facts ride in the body either way, so the staff board shows the Connect
+   * state even when a louder code takes the headline; only the single `code`
+   * is exclusive.
+   *
+   * `missing` IS red. Before AGL-2122 that would have been wrong, because
+   * nothing created the destination and a permanently-red check teaches
+   * people to ignore the board. Now that setup-stripe creates it, its absence
+   * is a real regression with a one-line remedy.
+   *=========================================*/ if (facts.connectEndpoint === 'missing') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'connect-endpoint-missing'
+        });
+    }
+    if (facts.connectEndpoint === 'disabled') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'connect-endpoint-disabled'
+        });
+    }
+    if (facts.unsubscribedConnectEvents && facts.unsubscribedConnectEvents.length > 0) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'connect-events-unsubscribed'
+        });
+    }
+    return _extends({}, base, {
+        ok: true
+    });
+}
+export function meteredPricingHealth(facts, ms) {
+    const base = {
+        ms,
+        stripeConfigured: facts.stripeConfigured,
+        monthly: facts.monthly,
+        yearly: facts.yearly
+    };
+    // Unprovisioned: no Stripe, no money, no alarm.
+    if (!facts.stripeConfigured) {
+        return _extends({}, base, {
+            ok: true,
+            code: 'stripe-unconfigured',
+            unbilledInterval: null
+        });
+    }
+    if (facts.monthly && facts.yearly) {
+        return _extends({}, base, {
+            ok: true,
+            unbilledInterval: null
+        });
+    }
+    if (!facts.monthly && !facts.yearly) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'metered-price-missing',
+            unbilledInterval: 'both'
+        });
+    }
+    // Exactly one. The AGL-1931 shape.
+    return _extends({}, base, {
+        ok: false,
+        code: 'metered-price-asymmetric',
+        unbilledInterval: facts.yearly ? 'month' : 'year'
+    });
+}
+/*==========================================
+ * SCHEDULED JOBS, WATCHED BY ABSENCE (AGL-1955).
+ *
+ * ## The failure this exists for
+ *
+ * `Cloud Scheduler job run failed (aglyn-main)` is a log-match on
+ * `resource.type="cloud_scheduler_job" AND severity >= ERROR`, and the
+ * `scheduled-crons.yml` workflow goes red on a non-200. Both of those are
+ * triggered BY A RUN. A job that is deleted, paused, or whose `- cron:` line
+ * is edited away produces no attempt, therefore no error entry, therefore no
+ * red workflow, therefore nothing. Quiet reads as healthy — the same shape
+ * AGL-1923 closed for the error beacon, one subsystem over.
+ *
+ * What is downstream of these jobs is not cosmetic: `report-usage` is the
+ * only writer that meters a closed month into Stripe, `run-erasures` is the
+ * GDPR deletion runner, `audit-archive` moves and then DELETES audit rows,
+ * and `plugin-jobs-beat` is the only thing that makes scheduled publishing
+ * and booking-hold expiry happen at all. A silently unscheduled job means
+ * customers are not billed, or data is not reaped, behind a green board.
+ *
+ * ## The two properties that make this work
+ *
+ * **It does not need the job to be alive to fire.** That is the whole bug.
+ * The verdict is computed by the READER — `/api/health/crons`, wound by the
+ * uptime probe and by any staff member opening the Health page — against
+ * marks the jobs left behind. Nothing here is on a schedule that could
+ * itself stop; that would only move the problem one layer out, which is the
+ * AGL-1923 argument for a graded switch over a `conditionAbsent` policy.
+ *
+ * **It cannot false-alarm on a legitimately idle period.** The mark is
+ * stamped by the INVOCATION, not by the work: a `finish-domain-attachments`
+ * run with no pending host still beats, and a quiet week for
+ * `reap-plugin-artifacts` still beats. And the expected time is computed
+ * from the job's own cron expression rather than from a fixed interval, so
+ * `usage-email` — hourly, but only on the 1st and 2nd of the month — is
+ * green for the twenty-nine days it is deliberately not running. A fixed
+ * "expect one every hour" rule would have paged on the 3rd, every month.
+ *
+ * ## Why an output age rule was not enough on its own
+ *
+ * AGL-1843's `exportsHealth` watches the weekly export by the age of what it
+ * PRODUCES, and that is the better rule where an output exists — it catches
+ * "ran and failed" as well as "never ran". Most of these jobs have no such
+ * output. `backfill-scope` is detect-only and deliberately writes nothing.
+ * `usage-alerts` produces a notification only when somebody is over budget.
+ * `reap-plugin-artifacts` deletes nothing in a normal week. For those, the
+ * only honest thing whose age moves on every run is a mark the run itself
+ * leaves — so that is what this reads. `exportsHealth` stays where it is:
+ * the two are complementary, and `firestore-export` is watched by both.
+ *
+ * ## It must be able to go GREEN
+ *
+ * Nothing latches. A job that missed a fire and then runs again stamps a
+ * fresh mark and reads healthy on the next probe — the AGL-1843 rule, whose
+ * clearing event here is named and is "the next invocation of that job".
+ *=========================================*/ /** Where the marks live. One document per job id, written by the job. */ export const CRON_BEAT_COLLECTION = 'platformCronBeats';
+/**
+ * The document that records when this deployment STARTED watching.
+ *
+ * Without it a job that has never reported cannot be told apart from a job
+ * that has stopped reporting, and every board would come up red on the day
+ * the feature deploys — for `usage-email`, red until the 1st of the next
+ * month. The rule this enables is stated once, in `cronJobsHealth`: a job
+ * with no mark is only silent once a scheduled fire time has passed SINCE
+ * we started watching.
+ *
+ * Not a reserved id: Firestore reserves `__.*__`, and this is a plain slug
+ * that no job id can collide with (job ids never contain the word `watch`,
+ * and the wiring spec asserts the inventory's ids against the workflow).
+ */ export const CRON_BEAT_WATCH_DOC = 'watch-window';
+/**
+ * Where a degraded verdict is recorded, so a red window survives it.
+ *
+ * The response body names the late job, but only to whoever is holding it,
+ * and the uptime probe reads the status and discards the body. Vercel's
+ * runtime log keeps a `console.error` for about an hour, and the Cloud
+ * Logging drain deliberately does not forward one — `isServerErrorEntry`
+ * drops `level: 'error'`, because that is every fail-soft line the beacons
+ * write and forwarding it is what a self-feeding bill is made of. So the
+ * only sink that outlives the window is the one the endpoint already holds
+ * a handle to.
+ *
+ * Written by the READER, like the verdict itself. One document, replaced on
+ * each degraded probe, holding the failing rows and when the window opened.
+ * Same collision argument as the watch document: a plain slug, and no job id
+ * contains `degraded`.
+ */ export const CRON_BEAT_DEGRADED_DOC = 'last-degraded';
+/**
+ * Every job's latest mark in one document, `{ beats: { [jobId]: atMs } }`.
+ *
+ * The reader's fast path (AGL-2946). Listing the collection costs one read per
+ * job on every uncached probe — ~23 reads, several hundred times a day, on a
+ * project that pays for reads past the free tier — to answer a question this
+ * one document answers.
+ *
+ * A COPY, never the authority. `writeCronBeat` writes it second, so a job
+ * whose own mark landed can still be missing or stale here, and the reader
+ * confirms any job this document calls late against that job's own mark
+ * before reporting it. Stale costs a read; it never costs a false red.
+ *
+ * Same collision argument as the other two: a plain slug no job id equals.
+ */ export const CRON_BEAT_SUMMARY_DOC = 'summary';
+/** The reserved documents in `CRON_BEAT_COLLECTION` that are not job marks. */ export const CRON_BEAT_RESERVED_DOCS = new Set([
+    CRON_BEAT_WATCH_DOC,
+    CRON_BEAT_DEGRADED_DOC,
+    CRON_BEAT_SUMMARY_DOC
+]);
+/**
+ * How long a gap may be before the next degraded probe counts as a NEW
+ * window rather than a continuation of the one on file.
+ *
+ * Three probe TTLs. Long enough that an instance answering intermittently
+ * does not split one outage into a dozen, short enough that yesterday's
+ * window is never mistaken for today's. The comparison is against the
+ * failing set as well, so a different set always opens a new window.
+ */ export const CRON_DEGRADED_WINDOW_CONTINUITY_MS = 15 * 60000;
+/**
+ * THE INVENTORY.
+ *
+ * Seven GitHub Actions schedules (`.github/workflows/scheduled-crons.yml`) —
+ * the weekly jobs, the month-boundary usage-email sweep and the hourly CRM
+ * task reminders, for which an hour of drift is nothing — and the rows
+ * driven by Cloud Scheduler out of
+ * `cloud/functions/src/index.ts`: `pluginJobsBeat` and `consoleAiJobsBeat`
+ * (every minute), the routes the `consoleFastCrons` job carries every
+ * fifteen (AGL-1617), and one `consoleDailyCron` export per daily job.
+ *
+ * `scheduled-crons-wiring.spec.ts` holds BOTH runners against their source —
+ * the workflow for the `github-actions` rows, the functions file for the
+ * `cloud-scheduler` ones — in both directions. An inventory row for a job
+ * nobody schedules and a scheduled job nobody watches are the same bug seen
+ * from opposite ends, and both fail the build.
+ *
+ * `report-usage` appears TWICE and is two jobs, not one. The 02:00 run
+ * rolls up the closed month and is the only run that ever reaches Stripe;
+ * the 07:00 `?month=current` run writes the in-progress figure every usage
+ * budget reads (AGL-2219). Either can stop without the other, and folding
+ * them into one row would hide exactly that.
+ */ /*
+ * ⚠️ GRACE IS A PROPERTY OF THE RUNNER, not of the job.
+ *
+ * The five daily console jobs carried a SIX-HOUR grace because GitHub
+ * Actions dispatches scheduled workflows on a best-effort basis and routinely
+ * drifted by an hour or two. That grace bought tolerance and paid for it in
+ * blindness: on 2026-08-27 GitHub dropped the whole day, and three of these
+ * were thirty hours silent before anything said so.
+ *
+ * They run on Cloud Scheduler now, which has been punctual to the minute
+ * since AGL-1617, and each function's own ceiling is 540 seconds. Ninety
+ * minutes is therefore ten times the longest a healthy run can take and still
+ * catches a dead job inside the working day, instead of most of a day later.
+ */ export const SCHEDULED_JOBS = [
+    {
+        id: 'report-usage',
+        label: 'Metered usage rollup (closed month)',
+        cron: '0 2 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/billing/report-usage',
+        graceMinutes: 90,
+        drives: 'The only run that meters a closed month into Stripe. If it stops, customers are not billed for what they used.'
+    },
+    {
+        id: 'audit-archive',
+        label: 'Audit archive',
+        cron: '0 3 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/admin/audit-archive',
+        graceMinutes: 90,
+        drives: 'Moves adminAudit rows past the 90-day window into Storage and deletes them from Firestore. If it stops, the retention promise is not being kept.'
+    },
+    {
+        id: 'run-erasures',
+        label: 'GDPR erasure runner',
+        cron: '0 4 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/admin/run-erasures',
+        graceMinutes: 90,
+        drives: 'Executes accepted erasure requests. If it stops, personal data a customer asked us to delete is still here, and the clock on that request is still running.'
+    },
+    {
+        id: 'report-usage-current',
+        label: 'Metered usage rollup (current month)',
+        cron: '0 7 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/billing/report-usage?month=current',
+        graceMinutes: 90,
+        drives: 'Writes the in-progress month figure (AGL-2219). If it stops, every usage budget on the platform is structurally unable to fire and the Billing card stops totalling.'
+    },
+    {
+        id: 'usage-alerts',
+        label: 'Usage budget alerts',
+        cron: '0 8 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/billing/usage-alerts',
+        graceMinutes: 90,
+        drives: 'Evaluates usage budgets and notifies. If it stops, an org sails past its budget with no warning and finds out on the invoice.'
+    },
+    {
+        id: 'reap-sending-domains',
+        label: 'Orphaned sending-domain reaper',
+        // An hour after `run-erasures`, which is what produces most of its work:
+        // an erasure records what it could not release rather than waiting on a
+        // vendor, and this is the only thing that settles that debt.
+        cron: '0 5 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/admin/reap-sending-domains',
+        graceMinutes: 90,
+        drives: 'Releases the provider domain object and the zone records of every sending domain whose site or workspace is gone. If it stops, each deleted site keeps one of a bounded number of provider domain slots forever — until the ceiling is reached and a site that asks for a domain of its own is refused one, which leaves it on the shared pool rather than stopping its mail — and leaves a live DKIM key in our zone under a label a future site can claim and inherit a stranger’s signature from.'
+    },
+    {
+        id: 'reap-unverified-orgs',
+        label: 'Unverified signup reaper',
+        // 06:00, after `run-erasures` and the sending-domain sweep and before the
+        // billing pair. It calls `eraseOrg` itself, so it wants the erasure runner
+        // to have already finished with whatever it was holding.
+        cron: '0 6 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/admin/reap-unverified-orgs?dryRun=0',
+        graceMinutes: 90,
+        drives: 'Erases workspaces whose sole owner never confirmed an email address, releasing the workspace address they took, and promotes the held address of every owner who has since verified. If it stops, a name claimed with a throwaway inbox is held until its reservation expires — and, worse, a real customer who verified keeps a pending address that becomes claimable by anyone on day twenty-one.'
+    },
+    {
+        id: 'ai-insights-digest',
+        label: 'Weekly insights',
+        // 06:00 and 14:00 every day (AGL-2915): Monday's first run makes the
+        // week's digests and every run after it delivers the ones the AI jobs beat
+        // has written. Served by the AI plugin.
+        cron: '0 6,14 * * *',
+        runner: 'cloud-scheduler',
+        target: '/api/admin/ai-insights-digest',
+        graceMinutes: 90,
+        drives: 'Each Monday, makes the weekly insights people asked for, and delivers them once they are written. If it stops, nobody who asked is sent their insights, and a digest parked for credits is never given up.'
+    },
+    {
+        id: 'usage-email',
+        label: 'Monthly usage summaries',
+        // Hourly across the FIRST TWO DAYS only (AGL-2409). The idle-period case
+        // this whole check had to get right: for twenty-nine days a month this
+        // job is correctly doing nothing, and must read green while it does.
+        cron: '0 * 1-2 * *',
+        runner: 'github-actions',
+        target: '/api/billing/usage-email',
+        graceMinutes: 360,
+        drives: "Mails each org last month's usage summary, chunked across 48 hourly windows. If it stops, the month's summaries are simply never sent."
+    },
+    {
+        id: 'crm-task-reminders',
+        label: 'CRM task reminders',
+        // Hourly, all month (AGL-2659). The grace is `usage-email`'s, for the
+        // reason that row gives about this runner: GitHub's dispatch is
+        // best-effort, and a reminder stays owed on the task until a run
+        // handles it, so a dropped hour costs lateness rather than silence.
+        cron: '0 * * * *',
+        runner: 'github-actions',
+        target: '/api/crm/task-reminders',
+        graceMinutes: 360,
+        drives: 'Sends each CRM task’s reminder at its own time — a console notification and an email to the assignee (AGL-2659). If it stops, every reminder a person set in the task drawer is silently late, and nothing but the morning digest says a task was due.'
+    },
+    {
+        id: 'firestore-export',
+        label: 'Weekly Firestore export',
+        cron: '0 5 * * 1',
+        runner: 'github-actions',
+        target: '/api/admin/firestore-export',
+        graceMinutes: 1440,
+        drives: 'Starts the independent GCS export — the restore point that exists because the managed backups kept flipping to NOT_AVAILABLE (AGL-1843). Also watched by output age on /api/health/backups.'
+    },
+    {
+        id: 'reap-plugin-artifacts',
+        label: 'Plugin artifact reaper',
+        cron: '30 5 * * 1',
+        runner: 'github-actions',
+        target: '/api/admin/reap-plugin-artifacts',
+        graceMinutes: 1440,
+        drives: 'Deletes orphaned plugin bundles from the artifacts bucket. If it stops, storage grows without bound and nothing says so.'
+    },
+    {
+        id: 'reverify-plugin-versions',
+        label: 'Plugin verdict re-verification',
+        cron: '0 6 * * 1',
+        runner: 'github-actions',
+        target: '/api/admin/reverify-plugin-versions',
+        graceMinutes: 1440,
+        drives: 'Re-checks stored plugin verdicts against the current verifier (AGL-1086). If it stops, a regression on a live version is never noticed.'
+    },
+    {
+        id: 'reverify-sso-domains',
+        label: 'SSO domain re-verification',
+        // Mondays 07:30 UTC, after the rest of the weekly block. Weekly is the
+        // right cadence because the threat needs a domain to lapse, clear a
+        // registrar grace period and be re-bought — months, not days — and a
+        // daily sweep would multiply DNS traffic by seven to learn nothing sooner.
+        cron: '30 7 * * 1',
+        runner: 'github-actions',
+        target: '/api/admin/reverify-sso-domains',
+        graceMinutes: 1440,
+        drives: 'Re-checks that every live SSO domain still publishes its DNS ownership token (AGL-1210). If it stops, a domain that changed hands keeps routing another company sign-ins and nothing notices. It reports only — it never revokes, because a revoke logs out an entire enterprise.'
+    },
+    {
+        id: 'backfill-scope',
+        label: 'Scope-drift detection',
+        cron: '30 6 * * 1',
+        runner: 'github-actions',
+        target: '/api/admin/backfill-scope',
+        graceMinutes: 1440,
+        drives: 'Reports documents with no visibleTo — invisible to every site-scoped read (AGL-1478). Detect-only by construction, so it has no output whose age could stand in for this mark.'
+    },
+    {
+        id: 'campaigns-process-scheduled',
+        label: 'Scheduled email campaigns',
+        cron: '*/15 * * * *',
+        // MOVED OFF GITHUB ACTIONS (AGL-1617), with the row below it. See the
+        // grace note on `graceMinutes` for why that let the bar go UP.
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons → console /api/campaigns/process-scheduled',
+        graceMinutes: 45,
+        drives: 'Claims and sends due campaigns. If it stops, a campaign the composer showed as Scheduled sits there and never sends — the AGL-2134 shape, which is sold on /product/marketing.'
+    },
+    {
+        id: 'lists-materialize',
+        label: 'Dynamic email lists',
+        // Shares the `consoleFastCrons` job with the two rows around it — one
+        // Cloud Scheduler job driving three routes, which is why adding this cost
+        // no scheduler quota.
+        cron: '*/15 * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons \u2192 console /api/lists/materialize',
+        graceMinutes: 45,
+        drives: 'Re-evaluates every dynamic list against its rule. If it stops, a list keeps whatever membership it last had, and a campaign sent to it reaches an audience that silently stopped tracking the rule the merchant wrote — which looks exactly like a rule that matched nobody new.'
+    },
+    {
+        id: 'finish-domain-attachments',
+        label: 'Custom domain re-check',
+        // Every fifteen minutes rather than twenty since AGL-1617: it shares one
+        // Cloud Scheduler job with the campaign processor, and AGL-2010's argument
+        // was always that a customer is sitting there waiting for their site.
+        cron: '*/15 * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons → console /api/admin/finish-domain-attachments',
+        graceMinutes: 45,
+        drives: 'Re-checks pending custom domains after the certificate or DNS settles (AGL-2010). If it stops, a correctly-configured domain stays dark until a human presses Re-attach.'
+    },
+    {
+        id: 'provision-sending-domains',
+        label: 'Sending domain provisioning',
+        // The fourth route on the `consoleFastCrons` job, sharing its schedule
+        // with the three rows above. It is a console route rather than a job on
+        // the platform beat because issuing a DKIM key needs a full-access
+        // provider credential the tenant runtime must never hold.
+        cron: '*/15 * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons → console /api/admin/provision-sending-domains',
+        graceMinutes: 45,
+        drives: 'Turns a site’s sending-domain claim into a DKIM key and the DNS records that carry it. If it stops, every site that has ASKED for a domain of its own waits on a claim with no records to publish. Their mail keeps leaving on the shared pool throughout, which makes this a stall in reputation isolation rather than stopped mail — and it is invisible to the merchant, who sees only a domain that never finishes.'
+    },
+    {
+        id: 'drain-publish-outbox',
+        label: 'Publish outbox drain',
+        // The fifth route on the `consoleFastCrons` job. Fifteen minutes is the
+        // bound on how long a publish whose tab went away can stay invisible,
+        // and it is the schedule this shares rather than one chosen for it —
+        // buying a tighter one would mean a second Cloud Scheduler job against a
+        // free-tier allowance of three.
+        cron: '*/15 * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons \u2192 console /api/admin/drain-publish-outbox',
+        graceMinutes: 45,
+        drives: 'Fires the cache-drop announce for publishes whose tab closed before it landed (AGL-2575). Publishing is a client Firestore write, so the announce is a fetch from the browser and a closed tab strands it; this is the only thing that finishes one. If it stops, a stranded publish is invisible on the live site for the full hour-long document TTL, and the pending entry that records it is never read by anything.'
+    },
+    {
+        id: 'plugin-console-crons',
+        label: 'Plugin console jobs',
+        // The sixth route on the `consoleFastCrons` job (AGL-2981). One route for
+        // every job a plugin declares on `plugin-console-crons`, so a plugin's
+        // job needs no route of its own in this list; each declared job has its
+        // own row beside this one, added by `/api/health/crons` from the
+        // declarations. This row answers the question under all of them: is the
+        // route being posted at all.
+        cron: '*/15 * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleFastCrons → console /api/admin/plugin-crons',
+        graceMinutes: 45,
+        drives: 'Runs every console job a plugin declares, each with its own row on this board. If it stops, every one of those jobs stops with it — a plugin’s scheduled sends and syncs among them — and each of their rows goes silent too.'
+    },
+    {
+        id: 'ai-jobs-beat',
+        label: 'AI jobs beat',
+        // Its own Cloud Scheduler job, every minute (AGL-3026): the console route
+        // runs steps for most of five minutes at a time, and a page waits a beat
+        // between sections. The grace is the other every-minute job's, below.
+        cron: '* * * * *',
+        runner: 'cloud-scheduler',
+        target: 'consoleAiJobsBeat → console /api/admin/ai-jobs-beat',
+        graceMinutes: 30,
+        drives: 'Runs the AI generation steps the doors leave queued: every plan, every page pass, the passes of a site scaffold, and any step an inline door’s budget handed back (AGL-3026). It runs on the console because only the console holds the AI provider key. If it stops, a generation job that plans never gets its plan and a page is never built — the job sits queued, spending nothing, and never finishes.'
+    },
+    {
+        id: 'plugin-jobs-beat',
+        label: 'Plugin job beat',
+        // Cloud Scheduler says `every 1 minutes`; the equivalent five-field
+        // expression is what this check evaluates against.
+        cron: '* * * * *',
+        runner: 'cloud-scheduler',
+        target: 'firebase-schedule-pluginJobsBeat-us-central1 → tenant /api/plugins/run-jobs',
+        graceMinutes: 30,
+        drives: 'The only thing that runs scheduled publishing and booking-hold expiry (AGL-1159). It is also the one job that can fail by pointing at the WRONG deployment (AGL-2176) — the mark is stamped by the tenant runner that answers, so a beat aimed elsewhere reads as silence here.'
+    }
+];
+/**
+ * A cron field, expanded to the set of values it matches.
+ *
+ * Supports a star, `a`, `a-b`, `a,b,c` and a trailing `/n` step on any of
+ * them — every form the inventory and `scheduled-crons.yml` use, and nothing
+ * else. An unparsable field returns null, which the caller treats as "matches
+ * nothing". A schedule that can never fire then produces a null `dueAt` and
+ * a green row rather than a permanent red one, and the wiring spec is what
+ * catches the typo — a monitor that reds on its own parse bug teaches people
+ * to ignore it.
+ */ function expandCronField(field, min, max) {
+    const values = new Set();
+    for (const part of field.split(',')){
+        const [range, stepRaw] = part.split('/');
+        const step = stepRaw === undefined ? 1 : Number.parseInt(stepRaw, 10);
+        if (!Number.isFinite(step) || step <= 0) return null;
+        let from;
+        let to;
+        if (range === '*') {
+            from = min;
+            to = max;
+        } else if (range.includes('-')) {
+            const [a, b] = range.split('-');
+            from = Number.parseInt(a, 10);
+            to = Number.parseInt(b, 10);
+        } else {
+            from = Number.parseInt(range, 10);
+            to = stepRaw === undefined ? from : max;
+        }
+        if (!Number.isFinite(from) || !Number.isFinite(to)) return null;
+        if (from < min || to > max || from > to) return null;
+        for(let value = from; value <= to; value += step)values.add(value);
+    }
+    return values.size ? values : null;
+}
+function parseCron(expression) {
+    const fields = expression.trim().split(/\s+/);
+    if (fields.length !== 5) return null;
+    const [minute, hour, dayOfMonth, month, dayOfWeek] = fields;
+    const parsed = {
+        minute: expandCronField(minute, 0, 59),
+        hour: expandCronField(hour, 0, 23),
+        dayOfMonth: expandCronField(dayOfMonth, 1, 31),
+        month: expandCronField(month, 1, 12),
+        dayOfWeek: expandCronField(dayOfWeek, 0, 6),
+        domRestricted: dayOfMonth !== '*',
+        dowRestricted: dayOfWeek !== '*'
+    };
+    if (!parsed.minute || !parsed.hour || !parsed.dayOfMonth || !parsed.month || !parsed.dayOfWeek) {
+        return null;
+    }
+    return parsed;
+}
+/**
+ * Does this UTC date fall on a day the expression can fire?
+ *
+ * The day-of-month / day-of-week OR is the standard cron rule: when BOTH are
+ * restricted the job fires on either, not on both. No expression in the
+ * inventory restricts both, and the rule is implemented anyway so that one
+ * added later is not silently misjudged.
+ */ function cronDayMatches(parsed, date) {
+    if (!parsed.month.has(date.getUTCMonth() + 1)) return false;
+    const domHit = parsed.dayOfMonth.has(date.getUTCDate());
+    const dowHit = parsed.dayOfWeek.has(date.getUTCDay());
+    if (parsed.domRestricted && parsed.dowRestricted) return domHit || dowHit;
+    if (parsed.domRestricted) return domHit;
+    if (parsed.dowRestricted) return dowHit;
+    return true;
+}
+/**
+ * The latest time at or before `atMs` that `expression` fires, UTC.
+ *
+ * Null when the expression is unparsable, or when it does not fire inside
+ * the lookback — 45 days, which comfortably clears the longest gap any
+ * inventory entry has (`usage-email`'s twenty-nine idle days).
+ *
+ * Whole non-matching DAYS are skipped rather than walked minute by minute,
+ * so the worst case is ~45 day checks plus 1,440 minute checks rather than
+ * 64,800 of them.
+ */ export function previousCronFire(expression, atMs, lookbackDays = 45) {
+    const parsed = parseCron(expression);
+    if (!parsed) return null;
+    // Floor to the minute: a fire at 05:00:00 counts as due at 05:00:30.
+    let cursor = Math.floor(atMs / 60000) * 60000;
+    const floor = cursor - lookbackDays * 86400000;
+    while(cursor >= floor){
+        const date = new Date(cursor);
+        if (!cronDayMatches(parsed, date)) {
+            // Jump to 23:59 of the previous UTC day.
+            const startOfDay = Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate());
+            cursor = startOfDay - 60000;
+            continue;
+        }
+        if (parsed.hour.has(date.getUTCHours()) && parsed.minute.has(date.getUTCMinutes())) {
+            return cursor;
+        }
+        cursor -= 60000;
+    }
+    return null;
+}
+/**
+ * The scheduled jobs, reduced to one health check per job (AGL-1955).
+ *
+ * `beats` null means the marks could not be read at all — degraded for every
+ * row, the same rule `signupsHealth`, `rateLimitsHealth` and `beaconHealth`
+ * follow. An alarm that cannot see the thing it watches must say so rather
+ * than report calm; here it is the literal condition the issue is about.
+ *
+ * `watchStartedAtMs` is when this deployment first read the marks. A job with
+ * no mark is silent only once a fire time has passed SINCE then — otherwise
+ * every row would be red on the day this deploys, and `usage-email` would
+ * stay red until the 1st.
+ *
+ * Pure on purpose, like its siblings: the route reads, this decides, the
+ * spec exercises every branch without a network.
+ */ export function cronJobsHealth(beats, watchStartedAtMs, ms, now = Date.now(), jobs = SCHEDULED_JOBS) {
+    const byId = new Map((beats != null ? beats : []).map((beat)=>[
+            beat.jobId,
+            beat.atMs
+        ]));
+    const checks = {};
+    for (const job of jobs){
+        var _byId_get;
+        const lastBeatMs = (_byId_get = byId.get(job.id)) != null ? _byId_get : null;
+        const lastBeatAgeMinutes = lastBeatMs === null ? null : Math.round((now - lastBeatMs) / 60000);
+        // The most recent fire time that is already past its grace. Everything
+        // more recent than that is a run we are still waiting for, on time.
+        const dueMs = previousCronFire(job.cron, now - job.graceMinutes * 60000);
+        const base = {
+            ms,
+            schedule: job.cron,
+            runner: job.runner,
+            lastBeatAgeMinutes,
+            dueAt: dueMs === null ? null : new Date(dueMs).toISOString(),
+            graceMinutes: job.graceMinutes
+        };
+        if (beats === null) {
+            checks[job.id] = _extends({}, base, {
+                ok: false,
+                code: 'beats-unavailable'
+            });
+            continue;
+        }
+        if (dueMs === null) {
+            // Nothing was due inside the lookback. Green, and honestly so.
+            checks[job.id] = _extends({}, base, {
+                ok: true
+            });
+            continue;
+        }
+        if (lastBeatMs === null) {
+            // Never reported. Only a defect once a fire time has passed since we
+            // started watching — before that it is a job we have not met yet.
+            const overdue = dueMs > watchStartedAtMs;
+            checks[job.id] = overdue ? _extends({}, base, {
+                ok: false,
+                code: 'job-never-reported'
+            }) : _extends({}, base, {
+                ok: true,
+                code: 'awaiting-first-run'
+            });
+            continue;
+        }
+        checks[job.id] = lastBeatMs < dueMs ? _extends({}, base, {
+            ok: false,
+            code: 'job-silent'
+        }) : _extends({}, base, {
+            ok: true
+        });
+    }
+    return checks;
+}
+export async function writeCronBeat(store, jobId, now = Date.now()) {
+    try {
+        const beats = store.collection(CRON_BEAT_COLLECTION);
+        await beats.doc(jobId).set({
+            jobId,
+            atMs: now,
+            at: new Date(now).toISOString()
+        }, {
+            merge: true
+        });
+        try {
+            await beats.doc(CRON_BEAT_SUMMARY_DOC).set({
+                beats: {
+                    [jobId]: now
+                }
+            }, {
+                merge: true
+            });
+        } catch (unused) {
+        // The reader confirms a stale summary entry against the mark above.
+        }
+        return true;
+    } catch (unused) {
+        return false;
+    }
+}
+/**
+ * The beats a summary document holds, ignoring anything malformed.
+ *
+ * `raw` is the document's `beats` field as Firestore returns it — a plain map,
+ * or undefined when the document does not exist yet.
+ */ export function cronBeatsFromSummary(raw) {
+    if (!raw || typeof raw !== 'object') return [];
+    return Object.entries(raw).map(([jobId, atMs])=>({
+            jobId,
+            atMs: Number(atMs)
+        })).filter((beat)=>!CRON_BEAT_RESERVED_DOCS.has(beat.jobId)).filter((beat)=>Number.isFinite(beat.atMs));
+}
+/**
+ * How old the last successful walk may be before this reds.
+ *
+ * Two hours against an hourly schedule — one missed run is tolerated, two are
+ * not. A canary that runs hourly and reds at 61 minutes would page on every
+ * GitHub Actions queue delay, and an alarm that cries wolf on infrastructure
+ * latency is one nobody reads by the time signup actually breaks. Two misses
+ * is a pattern rather than a hiccup.
+ *
+ * This is deliberately NOT generous enough to sleep through AGL-2581: three
+ * days of refused signups would red this inside two hours.
+ */ /**
+ * Workspace-slug prefix the signup canary owns, and the one piece of the
+ * product that has to know the canary exists (AGL-2715).
+ *
+ * ## Why an exclusion is not optional
+ *
+ * The canary creates a real org and then deletes it. `signupDrought` compares
+ * durable ATTEMPT markers against a live COUNT of orgs — and a deleted org
+ * leaves the count while its attempt marker stays. So every canary walk adds
+ * 1 to the denominator and 0 to the numerator, and after three walks the
+ * platform reports `signup-drought` with nothing wrong.
+ *
+ * That is not theoretical. It fired on 2026-09-09 at six attempts against
+ * zero creations — six walks that had each just proved, end to end, that a
+ * stranger could sign up. A monitor that manufactures the outage it watches
+ * for is worse than no monitor, and it is the same alarm fatigue AGL-2714
+ * removed, arriving from inside the house.
+ *
+ * ## Why the slug, and what that costs
+ *
+ * `/api/orgs/create` receives the requested slug before it does anything, so
+ * this needs no secret, no header and no second code path — the canary is
+ * excluded by being what it says it is.
+ *
+ * The cost is that the prefix is caller-supplied: someone naming their
+ * workspace `signup-canary-…` would not be counted in the drought's
+ * denominator. That is bounded to one uncounted attempt per such workspace,
+ * and it cannot hide an outage, because an outage is many attempts by many
+ * people and only the oddly-named ones would go missing.
+ *
+ * The canary declares the same prefix in `tools/e2e/signup-canary.mjs`, which
+ * cannot import this file — it runs outside the workspace. They are held
+ * together by `apps/console/specs/signup-canary-marker-wiring.spec.ts`.
+ */ export const SIGNUP_CANARY_ORG_SLUG_PREFIX = 'signup-canary-';
+/**
+ * Is this org creation the canary's own?
+ *
+ * Exported as a function rather than leaving callers to compare strings, so
+ * the one place that decides is the one place to read when asking why a
+ * number looks wrong.
+ */ export function isSignupCanaryOrgSlug(slug) {
+    return typeof slug === 'string' && slug.startsWith(SIGNUP_CANARY_ORG_SLUG_PREFIX);
+}
+/**
+ * How old the last walk may be before the check goes red.
+ *
+ * Six hours, far wider than the schedule that writes it, and deliberately so.
+ * GitHub Actions serves `schedule` from a best-effort queue that drops most
+ * requests under load: measured 2026-09-10, `uptime-probe.yml` asks for every
+ * fifteen minutes and actually fired at gaps of 1h55m to 4h38m across the
+ * preceding day and a half. A window sized to the cron expression rather than
+ * to that behavior reds on ordinary queue depth.
+ *
+ * Widening it costs no detection speed, because staleness is not how a broken
+ * signup surfaces. A walk that cannot sign up FAILS and still writes its
+ * marker, which reads `signup-walk-failed` on the next poll. Staleness can
+ * only mean the walker never reported — a CI condition, not a product one —
+ * so this window's whole job is to notice a canary that has genuinely stopped,
+ * and it must not fire before then: this check grades the monitor that must
+ * never be muted.
+ */ export const SIGNUP_CANARY_STALE_AFTER_MS = 6 * 60 * 60 * 1000;
+/**
+ * Grade the last recorded signup walk.
+ *
+ * Pure, like every sibling: the route reads the marker, this decides. Ordered
+ * by which mistake costs most — a missing marker is treated as failure, never
+ * as calm, because "no evidence" and "evidence of success" are the two
+ * readings this whole issue exists to stop anyone from confusing.
+ */ export function signupCanaryHealth(marker, ms, nowMs = Date.now(), staleAfterMs = SIGNUP_CANARY_STALE_AFTER_MS) {
+    const base = {
+        ms,
+        ageMs: null,
+        failedStep: null,
+        walkMs: null,
+        reapedCleanly: null,
+        staleAfterMs
+    };
+    // No marker at all, or a store that would not answer. The canary has never
+    // run, or cannot be read — either way nothing here has demonstrated that a
+    // stranger can sign up, and this check exists to say so out loud.
+    if (!marker || typeof marker.walkedAtMs !== 'number') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'canary-unavailable'
+        });
+    }
+    const ageMs = Math.max(0, nowMs - marker.walkedAtMs);
+    const walkMs = typeof marker.elapsedMs === 'number' ? marker.elapsedMs : null;
+    const reapedCleanly = typeof marker.reapedCleanly === 'boolean' ? marker.reapedCleanly : null;
+    const failedStep = typeof marker.failedStep === 'string' ? marker.failedStep : null;
+    const carried = _extends({}, base, {
+        ageMs,
+        walkMs,
+        reapedCleanly,
+        failedStep
+    });
+    // A stale PASS is not a pass. A walk that succeeded long enough ago says
+    // nothing about the door now, and the whole point of a canary is currency.
+    // Checked before the verdict so a stale failure reports as stale rather
+    // than as a failure that may since have healed.
+    if (ageMs > staleAfterMs) {
+        return _extends({}, carried, {
+            ok: false,
+            code: 'canary-stale'
+        });
+    }
+    if (marker.ok !== true) {
+        return _extends({}, carried, {
+            ok: false,
+            code: 'signup-walk-failed'
+        });
+    }
+    // Walked fine, did not clean up. Red anyway — see the docblock.
+    if (reapedCleanly === false) {
+        return _extends({}, carried, {
+            ok: false,
+            code: 'canary-left-residue'
+        });
+    }
+    return _extends({}, carried, {
+        ok: true
+    });
+}
+/**
+ * How long metered page views may sit still before the edge is presumed shut.
+ *
+ * Twelve hours, and the width is deliberate rather than lazy.
+ *
+ * The quietest full day in the sampled week carried 57 views — about 2.4 an
+ * hour on average, which would make six hours of zero look damning. But the
+ * average is the wrong statistic here: measured 2026-09-10, the day's 62 views
+ * came from ONE host of thirteen. Traffic that concentrated arrives in bursts,
+ * and a burst distribution produces long empty stretches with nothing wrong.
+ * A window sized to the average would page on one of them, which is how the
+ * monitor that must never be ignored gets ignored.
+ *
+ * Twelve hours of exactly zero, on a platform serving 57 to 563 views a day,
+ * is not a quiet stretch. It is slower to fire than anyone would like, and it
+ * is the only thing that catches a fully blocked edge at all — nothing else
+ * would ever fire, because every other check rides the bypass.
+ *
+ * ⚑ Tighten it once the real quiet-period distribution is known: the sampler
+ * stamps `advancedAtMs` on every run, so a week of markers says what the true
+ * maximum gap is. Do not tighten it from the daily average.
+ */ export const EDGE_ADMISSION_QUIET_AFTER_MS = 12 * 60 * 60 * 1000;
+/**
+ * How old the sampler's own reading may be before it stops being evidence.
+ *
+ * Six hours, sized like `SIGNUP_CANARY_STALE_AFTER_MS` to a scheduler that
+ * drops most of what it is asked for (AGL-2723) rather than to the cron
+ * expression. Shorter than the quiet window on purpose: a stalled sampler
+ * should be named as one BEFORE its frozen reading has had time to look like
+ * an edge outage.
+ */ export const EDGE_ADMISSION_SAMPLE_STALE_AFTER_MS = 6 * 60 * 60 * 1000;
+/**
+ * Grade the last recorded metered-traffic sample.
+ *
+ * Pure, like every sibling. The sampler decides when the total last MOVED and
+ * stamps it; this only asks how long ago that was. Keeping the movement
+ * detection in the writer is what lets the door stay a read: a day rollover
+ * resets the counter to zero, and a grader looking at one sample could not
+ * tell that from traffic stopping.
+ */ export function edgeAdmissionHealth(marker, ms, nowMs = Date.now(), quietAfterMs = EDGE_ADMISSION_QUIET_AFTER_MS, sampleStaleAfterMs = EDGE_ADMISSION_SAMPLE_STALE_AFTER_MS) {
+    const base = {
+        ms,
+        quietMs: null,
+        day: null,
+        total: null,
+        quietAfterMs,
+        sampleAgeMs: null
+    };
+    // No marker, or one that cannot be read. Absence of proof reds here for the
+    // same reason it does on every sibling: "nobody measured" and "traffic is
+    // arriving" are the two readings this exists to keep apart.
+    if (!marker || typeof marker.advancedAtMs !== 'number') {
+        return _extends({}, base, {
+            ok: false,
+            code: 'edge-admission-unavailable'
+        });
+    }
+    const sampleAgeMs = typeof marker.sampledAtMs === 'number' ? Math.max(0, nowMs - marker.sampledAtMs) : null;
+    const carried = _extends({}, base, {
+        quietMs: Math.max(0, nowMs - marker.advancedAtMs),
+        day: typeof marker.day === 'string' ? marker.day : null,
+        total: typeof marker.total === 'number' ? marker.total : null,
+        sampleAgeMs
+    });
+    // ⛔ CHECKED FIRST, AND THE ORDER IS THE POINT.
+    //
+    // `advancedAtMs` only moves when the sampler runs, so a sampler that has
+    // stopped looks exactly like traffic that has stopped — and the responder
+    // would go looking at the firewall while the real fault was a job that
+    // never fired. That is the confusion `canary-stale` was built to avoid on
+    // the check next door, and it costs one comparison to avoid here too.
+    if (sampleAgeMs === null || sampleAgeMs > sampleStaleAfterMs) {
+        return _extends({}, carried, {
+            ok: false,
+            code: 'edge-sample-stale'
+        });
+    }
+    if (carried.quietMs !== null && carried.quietMs > quietAfterMs) {
+        return _extends({}, carried, {
+            ok: false,
+            code: 'edge-admits-nobody'
+        });
+    }
+    return _extends({}, carried, {
+        ok: true
+    });
+}
+/** The service signup depends on. See the docblock for why it is the only one. */ export const APP_CHECK_GRADED_SERVICE = 'identitytoolkit.googleapis.com';
+/**
+ * Window the attestation rate is taken over.
+ *
+ * Six hours, not one. This metric is aggregated by Google on its own schedule
+ * and arrives late, so a one-hour window reads empty for reasons that have
+ * nothing to do with attestation. Six hours is long enough to always carry
+ * traffic on this platform and short enough that a real collapse is caught the
+ * same working day.
+ */ export const APP_CHECK_WINDOW_MINUTES = 6 * 60;
+/**
+ * Requests below which the rate is not graded.
+ *
+ * A ratio over three requests is noise wearing a percentage. Twenty is a
+ * fraction of the ~940 a day Identity Platform sees, so a healthy platform
+ * always clears it, and a platform quiet enough not to is a platform where
+ * this check has nothing to say.
+ */ export const APP_CHECK_MIN_REQUESTS = 20;
+/**
+ * The floor the allow rate must clear.
+ *
+ * 0.90, against a measured 0.997. The gap is deliberate: a handful of genuine
+ * denials is ordinary — a stale tab, a bot, a browser that failed its
+ * reCAPTCHA — and a floor set near the observed rate would page on those.
+ *
+ * What this is built to catch is not a drift of a few percent; it is the
+ * documented failure mode of `recaptcha-allowlist.ts`, where an origin that is
+ * attached and routed but not allowlisted renders a console that can never
+ * sign anyone in. That reads as ~0%, not 85%.
+ */ export const APP_CHECK_MIN_ALLOW_RATE = 0.9;
+/**
+ * Grade attestation for real visitors.
+ *
+ * Pure, like every sibling: something else reads Cloud Monitoring, this
+ * decides. Null samples are degraded rather than calm — an unreadable metric
+ * is not evidence that attestation works, and this check exists precisely
+ * because "we did not look" was being reported as "it is fine".
+ */ export function appCheckAttestationHealth(samples, ms, service = APP_CHECK_GRADED_SERVICE, minimumRequests = APP_CHECK_MIN_REQUESTS, minimumAllowRate = APP_CHECK_MIN_ALLOW_RATE, windowMinutes = APP_CHECK_WINDOW_MINUTES) {
+    const base = {
+        ms,
+        allowRate: null,
+        allowed: 0,
+        denied: 0,
+        minimumRequests,
+        minimumAllowRate,
+        service,
+        deniedBy: {},
+        windowMinutes
+    };
+    if (samples === null) {
+        return _extends({}, base, {
+            ok: false,
+            code: 'attestation-unavailable'
+        });
+    }
+    let allowed = 0;
+    let denied = 0;
+    const deniedBy = {};
+    for (const sample of samples){
+        if (sample.service !== service) continue;
+        // `Number(...) || 0` for the reason every sibling gives: a corrupt count
+        // must not turn the total into NaN, which compares false against every
+        // threshold and would report calm forever.
+        const count = Number(sample.count) || 0;
+        if (sample.result === 'ALLOW') allowed += count;
+        else if (sample.result === 'DENY') {
+            var _deniedBy_why;
+            denied += count;
+            const why = sample.security || 'UNKNOWN';
+            deniedBy[why] = ((_deniedBy_why = deniedBy[why]) != null ? _deniedBy_why : 0) + count;
+        }
+    }
+    const total = allowed + denied;
+    const carried = _extends({}, base, {
+        allowed,
+        denied,
+        deniedBy
+    });
+    // Too little traffic to say anything. Reported, not hidden: an on-call
+    // person reading a green body deserves to know this one abstained.
+    if (total < minimumRequests) {
+        return _extends({}, carried, {
+            ok: true,
+            code: 'not-enough-traffic',
+            allowRate: null
+        });
+    }
+    const allowRate = allowed / total;
+    return _extends({}, carried, {
+        allowRate,
+        ok: allowRate >= minimumAllowRate
+    }, allowRate >= minimumAllowRate ? {} : {
+        code: 'attestation-failing'
+    });
+}
+
+//# sourceMappingURL=health-report.js.map