@aglyn/aglyn 1.0.0-beta.143

package/src/lib/app-utils/plan-entitlements.js

@@ -0,0 +1,4085 @@
+/**
+ * @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.
+ */ import { _ as _extends } from "@swc/helpers/_/_extends";
+import { _ as _object_without_properties_loose } from "@swc/helpers/_/_object_without_properties_loose";
+import { isOrgOverrideReasonCode } from "./org-override-reason.js";
+import { PLATFORM_BRAND_NAME, PLATFORM_BRANDING_PROFILE } from "./platform-brand.js";
+import { listPluginFeatures, listPluginSeatAddons, pluginSeatAddon } from "../plugin-manager/plugin-entitlements.js";
+/** Sentinel for quotas a plan does not cap; `checkQuota` always allows. */ export const UNLIMITED = Number.POSITIVE_INFINITY;
+/**
+ * How many saved form definitions one site may hold, on every plan that can
+ * build them at all.
+ *
+ * ⛔ **Not a tier lever, and must not become one.** The website-building field
+ * does not meter form COUNT: Squarespace, HubSpot and Mailchimp publish no cap
+ * whatsoever, Webflow abandoned the lever above its free tier, and of the two
+ * that do meter it one is Wix (4/10/25/75) and the other is Jotform
+ * (5/25/50/100), a form-first product where a form IS the billable unit. What
+ * this platform meters on the forms axis is `formSubmissionsPerMonth`, which
+ * is tiered, metered and part of a charged price.
+ *
+ * So this is an abuse ceiling wearing an entitlement's clothes. It rides
+ * `formsPerHost` because that is where `checkQuota` can refuse a create inside
+ * the counting transaction, not because the number is sold — and it resolves
+ * to the same value on Starter through Enterprise. Only Free differs, and only
+ * because the form entity rides `reusableComponents`, which Free lacks.
+ *
+ * The value clears every published competitor number by 5x and the largest
+ * real catalog by far, and it stays STRICTLY below `FORMS_MAX_PER_HOST` — the
+ * page size two listing reads use. The gap is deliberate: a catalog can sit
+ * above this ceiling when a per-org override is withdrawn, and the two
+ * numbers must stay tellable apart so a surface reading the window where it
+ * means the ceiling is never accidentally right. `forms.spec.ts` pins both
+ * halves.
+ *
+ * A per-org `entitlements.formsPerHost` override still resolves ahead of this,
+ * so a contract can raise or lower it for one org without moving the ceiling
+ * everyone else is measured against.
+ */ export const FORMS_PER_HOST_CEILING = 500;
+/**
+ * Is this quota value "no cap"? (AGL-2482; AGL-2223 is the same class.)
+ *
+ * WHY A PREDICATE AND NOT `x === UNLIMITED`. `UNLIMITED` is
+ * `Number.POSITIVE_INFINITY`, and `JSON.stringify(Infinity)` is **`null`** —
+ * so the moment an entitlement crosses a route boundary the sentinel is gone
+ * and `=== UNLIMITED` is false for a plan that really is uncapped. Worse, the
+ * client then reads `Number(null)`, which is `0`, and `Number.isFinite(0)` is
+ * TRUE: the value sails through every guard written to reject a payload that
+ * cannot state the terms, and the console renders a cap of zero for the most
+ * expensive plan on the price list.
+ *
+ * So: `Infinity`, `null`, `undefined` and `NaN` all read as unlimited here.
+ *
+ * THIS IS A BACKSTOP, NOT THE FIX. `null` on the wire genuinely cannot
+ * distinguish "unlimited" from "the field is missing", and answering
+ * "unlimited" for a missing field is the permissive direction — the same
+ * shape as `checkQuota(undefined)` resolving to Free. A route that serialises
+ * a quota must therefore send a FINITE number plus an explicit boolean flag
+ * (see `/api/billing/storage-overage`), and the client must rebuild the
+ * sentinel from the flag with `restoreQuotaLimit` before it does arithmetic.
+ * This predicate exists so that a surface which has not been given the flag
+ * still renders "Unlimited" instead of `0`, `null` or `Infinity`.
+ */ export function isUnlimitedQuota(limit) {
+    return limit == null || !Number.isFinite(limit);
+}
+/**
+ * A quota cap, written the way every surface in the console must write it:
+ * `Unlimited` for an uncapped plan, the number otherwise.
+ *
+ * ONE implementation on purpose. Six surfaces had grown their own copy of the
+ * `limit === UNLIMITED ? 'Unlimited' : String(limit)` line and a seventh
+ * category — the ones that interpolated the raw number — shipped
+ * "Every site can run null registers on your current plan" and
+ * "Screen limit reached (Infinity)" to customers.
+ *
+ * @param limit The cap. Non-finite, `null` and `undefined` are unlimited.
+ * @param unit Appended to a finite number only — `MB`, `registers`. Never
+ *   appended to `Unlimited`, because "Unlimited MB" reads as a typo.
+ */ export function formatQuotaLimit(limit, unit) {
+    if (isUnlimitedQuota(limit)) return 'Unlimited';
+    return unit ? `${limit} ${unit}` : String(limit);
+}
+/**
+ * Rebuild the `UNLIMITED` sentinel a JSON round-trip flattened, from the
+ * explicit flag the route sent alongside the number.
+ *
+ * The client half of the wire contract. Once this has run, every comparison
+ * downstream is ordinary arithmetic that happens to be correct: `used >
+ * Infinity` is false, `Math.max(0, used - Infinity)` is `0`, and nothing has
+ * to remember that this particular number might be a `null` in disguise.
+ *
+ * That mattered more than the display did. `1 > null` is **true**, so a site
+ * on an unlimited plan was reported "1 over the limit" while the readout
+ * beside it said `1/∞` — a false limit warning on a plan that has no limit.
+ *
+ * @param value The finite number the route sent (or the `null` it sent for a
+ *   pre-fix payload).
+ * @param unlimited The route's explicit flag. `undefined` means the route has
+ *   not been taught to send one, and then `value` decides — non-finite reads
+ *   as unlimited, which is the `isUnlimitedQuota` backstop.
+ */ export function restoreQuotaLimit(value, unlimited) {
+    if (unlimited === true) return UNLIMITED;
+    if (unlimited === false) return Number(value);
+    return isUnlimitedQuota(value) ? UNLIMITED : Number(value);
+}
+/**
+ * Campaign emails an Enterprise agreement includes per month, before the
+ * contract says otherwise.
+ *
+ * ## Why the one Enterprise quota that is a number
+ *
+ * Every other Enterprise band is `UNLIMITED` because the thing behind it is
+ * infrastructure we already meter and price into the deal — storage, page
+ * views, seats. Email is not that. It is a per-message charge from a third
+ * party, so an unbounded allowance is an unbounded liability with no meter
+ * underneath it and no ceiling a negotiation ever had to name.
+ *
+ * `UNLIMITED` was also unrepresentable off-process. It is
+ * `Number.POSITIVE_INFINITY`, `JSON.stringify(Infinity)` is `null`, and
+ * `Number(null)` is `0` — so the most expensive plan on the price list
+ * serialised to a cap of ZERO through any route that did not also send the
+ * explicit flag `restoreQuotaLimit` rebuilds from. A finite number crosses
+ * the wire as itself.
+ *
+ * ## Why this number
+ *
+ * Twice Agency's band — the rule every Enterprise fallback follows since the
+ * 2026-09-07 pricing decision (see the `enterprise` row of
+ * `PLAN_ENTITLEMENTS`) — and inside what the sending platform can actually
+ * deliver to one workspace with room to spare. At the shipped constants a
+ * workspace's share is 500 messages an hour and a projected month is 720
+ * hours, so 360,000 is the ceiling nothing can exceed however it is sold.
+ * 260,000 spends 520 of those 720 hours, leaving the rest for bursts, retries
+ * and domain warm-up — `email-ceiling-dimensioning.spec.ts` holds that
+ * relation, and holds the platform rate still so the gap cannot be closed by
+ * quietly raising it.
+ *
+ * Selling more than that would be selling mail that cannot leave the
+ * building: the hourly ceiling DEFERS rather than refuses, so the excess does
+ * not bounce, it simply never sends.
+ *
+ * ## It is a DEFAULT, and a contract raises it
+ *
+ * `resolveOrgEntitlements` applies a per-org `entitlements.emailSendsPerMonth`
+ * override ahead of this, so a deal that buys more email buys it on that org
+ * without moving the figure every other agreement is measured against — the
+ * same mechanism every numeric entitlement uses.
+ */ export const ENTERPRISE_EMAIL_SENDS_PER_MONTH = 260000;
+/**
+ * Aglyn Assist credits an Enterprise agreement includes per month, before the
+ * contract says otherwise.
+ *
+ * ## Never `UNLIMITED`, and the reason is not stylistic
+ *
+ * `UNLIMITED` is `Number.POSITIVE_INFINITY`, `JSON.stringify(Infinity)` is
+ * `null`, and `Number(null)` is `0`. An unbounded assist band therefore
+ * serialises to a band of ZERO through every route that does not also send
+ * the explicit flag `restoreQuotaLimit` rebuilds from — which would hand the
+ * only customers with a signed contract the one budget that refuses
+ * everything. A finite number crosses the wire as itself.
+ *
+ * The band is also a real liability rather than a capacity we already own.
+ * Storage and page views are infrastructure metered into the deal; assist is
+ * a per-token charge from a third party, and generative building spends it in
+ * units two orders of magnitude apart.
+ *
+ * ## Why this number
+ *
+ * Enterprise carries no list price, so the band cannot be sized the way every
+ * self-serve tier's is — against what that tier's other cost terms leave out
+ * of a known price. It is anchored to the top of the ladder instead: 116,000
+ * credits is twice Agency's band, the rule every Enterprise fallback follows
+ * since the 2026-09-07 pricing decision (see the `enterprise` row of
+ * `PLAN_ENTITLEMENTS`). In cost that is $116 of provider spend a month, or
+ * under 9% of any deal priced at or above the self-serve top. A deal below
+ * that is sold as Agency, not written as an Enterprise agreement.
+ *
+ * ## It is a DEFAULT, and a contract raises it
+ *
+ * `resolveOrgEntitlements` applies a per-org `entitlements.assistCreditsPerMonth`
+ * override ahead of this, so a deal that buys more assist buys it on that org
+ * without moving the figure every other agreement is measured against — the
+ * same mechanism the other contracted bands use.
+ */ export const ENTERPRISE_ASSIST_CREDITS_PER_MONTH = 116000;
+/**
+ * The Free AI taste (AGL-2925): the assist credits a Free workspace draws
+ * on each month, behind a hard wall.
+ *
+ * ## Why it exists
+ *
+ * So the AI landing pages can say "generate your first page free" and mean
+ * it. Three hundred credits is one or two generated sections or a handful
+ * of copy rewrites — enough to see what the assistant does, not enough to
+ * build a site on. The band is a WALL: `PLAN_PRICING.free
+ * .extraAssistCreditsUsdPer1k` stays `null`, so `assistBandRefuses` answers
+ * true and the reservation refuses at 100% with no overage, no switch and no
+ * invoice. Nothing about a Free workspace can produce a charge.
+ *
+ * ## What it costs, and why that is the number
+ *
+ * A credit is `ASSIST_CREDIT_COST_USD` of provider spend, so the band costs
+ * at most **$0.30 per Free workspace per month** — asserted by
+ * `apps/console/specs/tier-margin-floor.spec.ts`. It is the one AI band with
+ * no invoice behind it, which is why the same issue closes every multiplier
+ * a script could use before the flag flips:
+ *
+ *  - it is metered per ACCOUNT as well as per workspace, so the three free
+ *    workspaces an account may hold (AGL-2265) share one 300-credit
+ *    allowance rather than tripling it (`reserveAssistMessage`);
+ *  - a fresh account waits `AI_FREE_MIN_ACCOUNT_AGE_HOURS` before it can
+ *    spend, and every free request is bounded per IP, per uid and per
+ *    account per day;
+ *  - a platform-wide daily ceiling on free spend pauses the taste for
+ *    everyone until the UTC day rolls, paid workspaces untouched.
+ *
+ * The account allowance reads THIS constant rather than the workspace's
+ * resolved band, because a staff override that widens one workspace's band
+ * is a decision about that workspace, not about how much one person may
+ * draw across all of theirs.
+ */ export const FREE_AI_TASTE_CREDITS_PER_MONTH = 300;
+export const PLAN_ENTITLEMENTS = {
+    free: {
+        hostLimit: 1,
+        screensPerHost: 5,
+        sharedLayoutsPerHost: 1,
+        templatesPerHost: 10,
+        storagePerHostMb: 250,
+        membersPerHost: 1,
+        managersPerOrg: 1,
+        maxManagersPerOrg: 1,
+        maxMembersPerHost: 1,
+        bandwidthGb: 2,
+        formSubmissionsPerMonth: 20,
+        // No saved-form CATALOG on Free: the form entity rides
+        // `reusableComponents`, which is Starter-and-above, so
+        // `/api/hosts/resources` refuses the create on the entitlement before it
+        // ever reaches this number. Zero is what a Free site actually gets.
+        //
+        // It does NOT mean a Free site has no forms. A `Form` node placed on a
+        // page needs no definition to collect, and the 20 submissions above are
+        // the band those replies spend.
+        //
+        // Every other plan carries `FORMS_PER_HOST_CEILING`. This is the one
+        // number on the axis that differs, and it differs because the entitlement
+        // gate above it says so, not because the catalog is sold by the tier.
+        formsPerHost: 0,
+        variablesPerHost: 3,
+        functionsPerHost: 1,
+        workflowsPerHost: 0,
+        workflowRunsPerMonth: 0,
+        servicesPerHost: 0,
+        redirectsPerHost: 0,
+        contactsPerHost: 100,
+        // No one-to-one email on Free, which has no CRM (below): the send lives
+        // on a record's page, and Free opens no record. Zero here is what
+        // `checkCrmEmailQuota` refuses
+        // against, so a per-org grant of `features.crm` alone still sends
+        // nothing until the band is raised with it.
+        crmEmailsPerDay: 0,
+        emailSendsPerMonth: 0,
+        actionRunsPerMonth: 0,
+        // The Free AI taste (AGL-2925): a real band, and a wall. See the
+        // constant for what it buys, what it costs and the precautions that
+        // keep one person from drawing it three times over.
+        assistCreditsPerMonth: FREE_AI_TASTE_CREDITS_PER_MONTH,
+        apiRequestsPerMonth: 0,
+        datasetsPerOrg: 0,
+        maxDatasetsPerOrg: 0,
+        recordsPerDataset: 0,
+        dataStorageMbPerOrg: 0,
+        productsPerHost: 0,
+        inventoryLocations: 1,
+        posRegisters: 0,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 0,
+        // Marketplace take rate (AGL-46/1543): free-plan sellers pay a higher
+        // share. `marketplaceSelling` is false here, so this rate only prices
+        // an org GRANTED selling via a per-org feature override — and any org
+        // whose dead subscription resolved it down to free.
+        marketplaceFeePct: 30,
+        features: {
+            abTesting: false,
+            versioning: false,
+            reusableComponents: false,
+            customDomain: false,
+            // Sending as a domain the customer owns starts at Pro, with campaign
+            // email. Free sends no marketing at all — `emailSendsPerMonth` is 0 —
+            // and its transactional mail leaves on the shared pool, which needs no
+            // DNS from anybody.
+            customSendingDomain: false,
+            // The expensive shape, and the one Free must never reach by default: a
+            // provider slot, three records in the platform's own zone and a place
+            // in the re-verification sweep, spent per site on a tier that pays
+            // nothing. The pool carries this tier's mail at no per-site cost.
+            dedicatedSendingDomain: false,
+            removeBranding: false,
+            scheduledPublishing: false,
+            marketplaceSelling: false,
+            // The two AI flags point opposite ways on Free, on purpose (AGL-2925).
+            // `aiAssist` is the guided rung of the console assistant — page-aware
+            // level-2 answers and the copy assistant — and stays Pro and up; Free
+            // keeps the docs-grounded level-1 chat it always had. `aiGenerative`
+            // is the generative door the taste is FOR: a Free workspace may
+            // generate against its 300-credit band, behind the wall and every
+            // precaution the constant lists, so the landing page's "generate your
+            // first page free" is a thing the product does.
+            aiAssist: false,
+            aiGenerative: true,
+            workflows: false,
+            dataStore: false,
+            videoMedia: false,
+            bookings: false,
+            // The CRM starts at Starter (AGL-2611), whole, and Free has none of it
+            // (AGL-2851): no Leads, Contacts, Companies, Deals, Tasks, Reports,
+            // Fields or Settings, no CRM automation step and no CRM REST resource.
+            // What Free's sites capture still counts against its 100-record band,
+            // and exporting and erasing those people stay on every plan.
+            // The Drive pricing decision of 2026-09-05 records why Starter and
+            // not Pro: the field prices a CRM seat at $14–25 a month, so Starter
+            // with the suite included is the competitive entry, and gating a
+            // tier higher hands the small-business buyer to a free CRM elsewhere.
+            crm: false,
+            // Sequences (AGL-2974) is on NO plan, this one through Enterprise: which
+            // tiers carry sequences and connected mailboxes, and at what caps, is
+            // an owner decision still to be made. Until then an organization gets
+            // it only through the per-org `entitlements.features.outreach`
+            // override, and the Firestore rules read that override alone.
+            outreach: false,
+            interactions: true,
+            actions: false,
+            webhooks: false,
+            apiAccess: false,
+            siteExport: false,
+            multilingual: false,
+            eventCalendar: false,
+            redirects: false,
+            screenAnalytics: false,
+            /**
+       * CDN delivery and responsive image variants, on every plan (AGL-1152).
+       *
+       * Without this, media is addressed by its absolute
+       * `firebasestorage.googleapis.com` URL: a visitor fetches the full-size
+       * original from Storage egress on every request, with no shared edge
+       * cache in front of it. With it, media is served over the CDN path,
+       * which is edge-cacheable and returns a resized WebP variant.
+       *
+       * The ungated path therefore costs more to run, on both bytes per
+       * request and origin requests per byte. Gating this would raise the cost
+       * of the tier that pays nothing.
+       */ mediaCdn: true,
+            marketingOverlays: false,
+            commerce: false,
+            pos: false,
+            storefrontSubscriptions: false,
+            contentGating: false,
+            giftCards: false,
+            productReviews: false,
+            abandonedCart: false,
+            dropshipRouting: false,
+            commerceAnalytics: false,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    starter: {
+        hostLimit: 1,
+        screensPerHost: 25,
+        sharedLayoutsPerHost: 3,
+        templatesPerHost: 50,
+        storagePerHostMb: 2048,
+        membersPerHost: 3,
+        managersPerOrg: 2,
+        maxManagersPerOrg: 5,
+        maxMembersPerHost: 10,
+        bandwidthGb: 50,
+        formSubmissionsPerMonth: 200,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: 25,
+        functionsPerHost: 10,
+        workflowsPerHost: 3,
+        workflowRunsPerMonth: 500,
+        servicesPerHost: 1,
+        redirectsPerHost: 25,
+        contactsPerHost: 1000,
+        // One-to-one email from a CRM record, per UTC day (AGL-2611). A hard
+        // daily pace rather than a monthly meter — see `crmEmailsPerDay` on
+        // `OrgEntitlements` — sized so the whole day spent at $0.0009 a message
+        // leaves the tier's CRM axis inside the 20% cost share the Drive
+        // pricing decision of 2026-09-05 sets. 50 a day is $1.35 a month against
+        // a $16 annual price. Every send still lands on the `emailSends` cost
+        // meter beside the transactional mail this tier already sends.
+        crmEmailsPerDay: 50,
+        // Campaign email starts at Pro. A site that may send campaigns needs its
+        // own verified provider sending domain, and provisioning one is a real
+        // per-site operational cost that a campaign allowance commits the platform
+        // to the moment the tier includes it. Holding the allowance at 0 here
+        // keeps that cost attached to the tiers that carry it.
+        //
+        // Zero is a REFUSAL, not a formality: `reserveCampaignEmailSends` compares
+        // `used + count > limit` inside its transaction, so any campaign of one or
+        // more recipients is refused before a message leaves.
+        //
+        // It does NOT stop transactional mail. Receipts, invites, booking
+        // reminders, workflow notifications and password resets are refused by no
+        // quota at any tier (see `emailSendsPerMonth` on `OrgEntitlements`), so a
+        // Starter store still confirms its orders. Those sends still count on the
+        // `emailSends` cost meter; they are simply not billable here, because
+        // `emailSendsOverage` yields 0 against a non-positive band.
+        //
+        // The contacts band above is untouched: holding an audience is not sending
+        // to it, and the CRM is what a Starter site builds before it upgrades.
+        emailSendsPerMonth: 0,
+        actionRunsPerMonth: 0,
+        // The first paid rung of the assist ladder (AGL-3203). Starter banded at
+        // 0 until 2026-09-20, which put a PAYING workspace below the Free taste's
+        // 300 on the one axis a visitor compares straight down the column — the
+        // `/pricing` row read `300 / mo` for Free and `—` for Starter. A paid
+        // plan that includes less of something than the free plan is not a
+        // packaging subtlety; it is the comparison table arguing against the
+        // upgrade.
+        //
+        // 750 is deliberately small: 2.5x the taste, enough that the assistant is
+        // a thing the tier HAS rather than a thing it is shown, and $0.75 of
+        // provider spend a month at `ASSIST_CREDIT_COST_USD` against a $16 annual
+        // price — a twentieth of the $8.81 the tier's other metered bands already
+        // cost, and the widest margin on the ladder absorbs it with room left
+        // (`tier-margin-floor.spec.ts` carries the arithmetic).
+        //
+        // It is NOT a wall, unlike Free's: `PLAN_PRICING.starter
+        // .extraAssistCreditsUsdPer1k` is $3.00, so past 750 the tier meters and
+        // bills like every paid plan above it. The two fields move together by
+        // rule — a positive band with no rate beside it is usage past a bound
+        // that is silently free, which `plan-entitlements.spec.ts` forbids.
+        //
+        // `features.aiAssist` stays false: the band is credits, not the guided
+        // rung of the console assistant, exactly as on Free. The AI add-on adds
+        // `AI_ADDON_CREDITS_PER_MONTH.starter` on top and switches both flags on.
+        assistCreditsPerMonth: 750,
+        apiRequestsPerMonth: 0,
+        datasetsPerOrg: 3,
+        maxDatasetsPerOrg: 10,
+        recordsPerDataset: 1000,
+        dataStorageMbPerOrg: 1024,
+        productsPerHost: 100,
+        inventoryLocations: 1,
+        posRegisters: 0,
+        transactionFeePhysicalPct: 2,
+        // Pricing v3 (2026-07): softened 7→5 — a 7% digital fee stacked on the
+        // ~2.9%+30¢ processor was ~10% all-in, far above the website-builder
+        // norm (Wix/BigCommerce/Squarespace-Core = 0% platform fee). See the
+        // Pricing Decision Log + Competitive Benchmark.
+        transactionFeeDigitalPct: 5,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: false,
+            versioning: false,
+            reusableComponents: true,
+            customDomain: true,
+            // Starter's allowance is 0 campaign sends, so a verified domain of the
+            // customer's own would carry receipts and nothing else — the one class
+            // of mail the shared pool already delivers with no DNS work at all. The
+            // capability arrives with the sends that need it.
+            customSendingDomain: false,
+            // Same tier as the customer-owned shape and for the stronger reason:
+            // this one draws on a provider allowance that cannot be bought past a
+            // certain size, so it is rationed above the tier that carries no
+            // campaign sends at all.
+            dedicatedSendingDomain: false,
+            removeBranding: true,
+            scheduledPublishing: false,
+            marketplaceSelling: false,
+            aiAssist: false,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: false,
+            bookings: true,
+            // The whole CRM, from the first paid tier (AGL-2611). At 100% of
+            // its band and its one-to-one email cap this costs $1.73 a month
+            // against a $16 annual price — the Drive pricing decision of
+            // 2026-09-05 has the arithmetic — and it is the upgrade motive from
+            // Free, not a line on top of a plan.
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: false,
+            webhooks: false,
+            apiAccess: false,
+            siteExport: false,
+            multilingual: false,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: false,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: false,
+            storefrontSubscriptions: false,
+            contentGating: false,
+            giftCards: false,
+            productReviews: false,
+            abandonedCart: false,
+            dropshipRouting: false,
+            commerceAnalytics: false,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    pro: {
+        hostLimit: 3,
+        screensPerHost: 100,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 10240,
+        membersPerHost: 10,
+        managersPerOrg: 5,
+        maxManagersPerOrg: 20,
+        maxMembersPerHost: 25,
+        // Page views are the largest term of this tier's modeled COGS — one GB
+        // is 1,035 views at `ESTIMATED_PAGE_TRANSFER_BYTES`, or $0.167 of
+        // measured cost — so the bandwidth band is what decides whether the tier
+        // survives a customer spending the whole allowance it was sold.
+        //
+        // The invariant the band is sized against is the ANNUAL price ($39 a
+        // month) net of Stripe's fee, with every band at 100% and the CRM seat
+        // and one-to-one email terms counted — the 2026-09-07 pricing decision.
+        // At 225 GB that price was 44% under water; 125 GB is what it carries.
+        // `tier-margin-floor.spec.ts` holds the model and pins the figure.
+        //
+        // `meteredInfraPassThrough` is true here, so traffic past the band BILLS
+        // at the page-view pass-through rather than being refused or absorbed.
+        bandwidthGb: 125,
+        formSubmissionsPerMonth: 1000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: 100,
+        functionsPerHost: 50,
+        workflowsPerHost: 25,
+        workflowRunsPerMonth: 5000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: 100,
+        contactsPerHost: 10000,
+        crmEmailsPerDay: 150,
+        emailSendsPerMonth: 5000,
+        actionRunsPerMonth: 5000,
+        // $2.75 of provider spend, against the $8.35 the tier's other seven cost
+        // terms leave out of $56. See `OrgEntitlements.assistCreditsPerMonth` for
+        // why the remainder and not the price is what sizes this.
+        assistCreditsPerMonth: 2750,
+        apiRequestsPerMonth: 0,
+        datasetsPerOrg: 15,
+        maxDatasetsPerOrg: 50,
+        recordsPerDataset: 10000,
+        dataStorageMbPerOrg: 5120,
+        productsPerHost: 2500,
+        inventoryLocations: 2,
+        posRegisters: 1,
+        transactionFeePhysicalPct: 0,
+        // Pricing v3 (2026-07): softened 5→3 to smooth the digital fee ladder
+        // (Starter 5 → Pro 3 → Business 2 → Scale 1 → Advanced/Agency 0).
+        transactionFeeDigitalPct: 3,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: false,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            // The tier campaign email starts at, and therefore the tier a domain
+            // whose reputation belongs to the merchant starts at: marketing may not
+            // leave on the shared pool, because one merchant's complaint rate would
+            // be charged against every other site's password resets.
+            //
+            // It costs the platform nothing in our own zone — the customer
+            // publishes the records — which is what keeps the platform's domain
+            // count flat as the customer base grows. The platform subdomain a site
+            // is issued is the expensive half and stays an optimization on top of
+            // the pool.
+            customSendingDomain: true,
+            // The floor for the platform subdomain too, and the tier this one is
+            // sized against: a merchant who may send campaigns is a merchant whose
+            // mail needs a name of its own, and Pro is where the revenue starts
+            // covering a provider slot and three zone records.
+            //
+            // A flag rather than a tier comparison, so a single org can be granted
+            // one through `entitlements.features` without being moved up a plan —
+            // the support case this capability meets most often, answered without
+            // repricing an account. What the grant does not do is provision: it
+            // admits a REQUEST, and the provider ceiling still decides whether the
+            // request is filled.
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: false,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: false,
+            apiAccess: false,
+            siteExport: true,
+            multilingual: false,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: false,
+            contentGating: false,
+            giftCards: false,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    business: {
+        hostLimit: 10,
+        screensPerHost: UNLIMITED,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 20480,
+        membersPerHost: 50,
+        managersPerOrg: 15,
+        maxManagersPerOrg: 100,
+        maxMembersPerHost: 100,
+        // Sized by the same annual-price invariant as Pro's — see that band.
+        bandwidthGb: 185,
+        formSubmissionsPerMonth: 8000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: 1000,
+        functionsPerHost: 250,
+        workflowsPerHost: 100,
+        workflowRunsPerMonth: 50000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: UNLIMITED,
+        contactsPerHost: 50000,
+        crmEmailsPerDay: 200,
+        emailSendsPerMonth: 25000,
+        actionRunsPerMonth: 50000,
+        // $7.50, against the $22.69 the other seven terms leave out of $139.
+        assistCreditsPerMonth: 7500,
+        apiRequestsPerMonth: 100000,
+        datasetsPerOrg: 100,
+        maxDatasetsPerOrg: 250,
+        recordsPerDataset: 100000,
+        dataStorageMbPerOrg: 25600,
+        productsPerHost: 10000,
+        inventoryLocations: 4,
+        posRegisters: 2,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 2,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: true,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            customSendingDomain: true,
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: true,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: true,
+            apiAccess: true,
+            siteExport: true,
+            multilingual: true,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: true,
+            contentGating: true,
+            giftCards: true,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    // Scale (Pricing v3, 2026-07): fills the $139→$399 gap. Feature set equals
+    // Business/Advanced (all commerce features); limits interpolate between
+    // Business and Advanced; digital platform fee drops to 1%.
+    scale: {
+        hostLimit: 15,
+        screensPerHost: UNLIMITED,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 30720,
+        membersPerHost: 75,
+        managersPerOrg: 25,
+        maxManagersPerOrg: 150,
+        maxMembersPerHost: 150,
+        bandwidthGb: 290,
+        formSubmissionsPerMonth: 25000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: 5000,
+        functionsPerHost: 500,
+        workflowsPerHost: 250,
+        workflowRunsPerMonth: 150000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: UNLIMITED,
+        contactsPerHost: 100000,
+        crmEmailsPerDay: 300,
+        emailSendsPerMonth: 40000,
+        actionRunsPerMonth: 100000,
+        // $10.00, against the $30.62 the other seven terms leave out of $249.
+        assistCreditsPerMonth: 10000,
+        apiRequestsPerMonth: 300000,
+        datasetsPerOrg: 250,
+        maxDatasetsPerOrg: 500,
+        recordsPerDataset: 500000,
+        dataStorageMbPerOrg: 51200,
+        productsPerHost: 25000,
+        inventoryLocations: 6,
+        posRegisters: 3,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 1,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: true,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            customSendingDomain: true,
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: true,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: true,
+            apiAccess: true,
+            siteExport: true,
+            multilingual: true,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: true,
+            contentGating: true,
+            giftCards: true,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    advanced: {
+        hostLimit: 25,
+        screensPerHost: UNLIMITED,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 40960,
+        membersPerHost: 100,
+        managersPerOrg: 50,
+        maxManagersPerOrg: 250,
+        maxMembersPerHost: 250,
+        bandwidthGb: 345,
+        formSubmissionsPerMonth: 40000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: UNLIMITED,
+        functionsPerHost: 1000,
+        workflowsPerHost: 500,
+        workflowRunsPerMonth: 500000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: UNLIMITED,
+        contactsPerHost: 150000,
+        crmEmailsPerDay: 500,
+        emailSendsPerMonth: 65000,
+        actionRunsPerMonth: 250000,
+        // $13.00, against the $39.74 the other seven terms leave out of $399 —
+        // the thinnest remainder on the ladder, and the tier that binds the
+        // whole assist ladder's share of it.
+        assistCreditsPerMonth: 13000,
+        apiRequestsPerMonth: 1000000,
+        datasetsPerOrg: 500,
+        maxDatasetsPerOrg: 1000,
+        recordsPerDataset: 1000000,
+        dataStorageMbPerOrg: 102400,
+        productsPerHost: UNLIMITED,
+        inventoryLocations: 10,
+        posRegisters: 5,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 0,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: true,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            customSendingDomain: true,
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: true,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: true,
+            apiAccess: true,
+            siteExport: true,
+            multilingual: true,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: true,
+            contentGating: true,
+            giftCards: true,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            whiteLabel: false,
+            ssoEnabled: false
+        }
+    },
+    // Agency (Pricing v3, 2026-07): high-volume multi-site tier above Advanced.
+    // 100 sites, 0% fees, top-of-ladder capacity. Positioned for agencies /
+    // resellers — white-label, SSO, and an SLA are the follow-on product work
+    // that will further differentiate it (see the Pricing Decision Log).
+    agency: {
+        hostLimit: 100,
+        screensPerHost: UNLIMITED,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 61440,
+        membersPerHost: 250,
+        managersPerOrg: 100,
+        maxManagersPerOrg: 500,
+        maxMembersPerHost: 1000,
+        bandwidthGb: 1540,
+        // FINITE, where every other capacity row on this tier is unbounded.
+        // `formSubmissionsPerMonth` is multiplied by `hostLimit` to get the
+        // org-wide band, so at 100 hosts an unbounded figure was not merely
+        // large — it made this tier's cost model unbounded, and an unbounded
+        // term reads as ZERO in any analysis that scores an absent band as
+        // nothing. That is how it stayed invisible: the biggest line item on the
+        // most expensive self-serve plan, contributing 0 to every total.
+        //
+        // Metering makes it safe to bound. `meteredInfraPassThrough` is true
+        // here, so submissions past the band BILL at the pass-through rate
+        // rather than being refused — a merchant's lead form does not stop
+        // working at 25,000.
+        formSubmissionsPerMonth: 25000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: UNLIMITED,
+        functionsPerHost: UNLIMITED,
+        workflowsPerHost: UNLIMITED,
+        workflowRunsPerMonth: 2000000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: UNLIMITED,
+        contactsPerHost: 500000,
+        crmEmailsPerDay: 1000,
+        emailSendsPerMonth: 130000,
+        actionRunsPerMonth: 1000000,
+        // $58.00, against the $176.71 the other seven terms leave out of $1,299.
+        assistCreditsPerMonth: 58000,
+        apiRequestsPerMonth: 5000000,
+        datasetsPerOrg: 2000,
+        maxDatasetsPerOrg: 5000,
+        recordsPerDataset: UNLIMITED,
+        dataStorageMbPerOrg: 512000,
+        productsPerHost: UNLIMITED,
+        inventoryLocations: 50,
+        posRegisters: 20,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 0,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: true,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            customSendingDomain: true,
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: true,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: false,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: true,
+            apiAccess: true,
+            siteExport: true,
+            multilingual: true,
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: true,
+            contentGating: true,
+            giftCards: true,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            // White-Label Phase 1: the Agency-tier ($1,299) differentiator. Only
+            // this tier and Enterprise ship white-label by default.
+            whiteLabel: true,
+            ssoEnabled: false
+        }
+    },
+    // Enterprise (AGL-1118): the top of the ladder and the ONLY custom-priced
+    // tier — staff-provisioned per deal (AGL-1110), never sold self-serve, so it
+    // is excluded from `SELF_SERVE_PLANS` and carries no list price in
+    // `PLAN_PRICING`. White-label AND SSO ship on the plan itself rather than
+    // through the per-org `entitlements` override that Enterprise-as-a-label
+    // needed.
+    //
+    // ## Every band here is a FALLBACK, and it is FINITE (2026-09-07)
+    //
+    // The row used to read UNLIMITED on every axis that costs infrastructure,
+    // on the theory that the deal prices the usage. It does not, unless the
+    // deal says so: `meteredInfraPassThrough` is false here and every overage
+    // rate is the "not for sale" sentinel, so an Enterprise org provisioned
+    // without per-org figures was the one org on the platform whose cost had no
+    // bound at all — the pricing soundness audit of 2026-09-07 found its worst
+    // case unbounded on every axis. A default that a contract must OVERRIDE to
+    // become finite is the wrong way round.
+    //
+    // So the rule is Agency's band × 2 on every axis Agency bounds, and
+    // UNLIMITED only where Agency is already UNLIMITED (screens, layouts,
+    // templates, variables, functions, workflows, services, redirects, records
+    // per dataset, products). `plan-entitlements.spec.ts` holds that relation
+    // key by key, so moving an Agency band without moving this one goes red.
+    //
+    // A contracted per-org `entitlements.*` value still wins on every one of
+    // these — `resolveOrgEntitlements` honors a numeric override on every
+    // axis, which is the instrument a deal that needs more is written with. A
+    // fallback is what an agreement gets before anybody has written it down.
+    //
+    // These are CAPS, not prices: with no rate and no pass-through the quota
+    // gates refuse at the line (`checkContactQuota`, `checkApiRequestQuota`,
+    // `checkFormSubmissionQuota`, `mediaStorageGate` …), exactly as Free's do.
+    // At twice the largest self-serve tier's bands that line is one a deal
+    // reaches only by being written without its numbers. The bandwidth abuse
+    // ceiling still flags and pages staff at 3× the band, and does NOT degrade
+    // the render on this plan — see `bandwidthCeilingDegradesRender`.
+    //
+    // `formsPerHost` is the same flat ceiling every plan carries; it bounds a
+    // collection, not a tier, and the 2026-08-30 decision withdrew the ladder.
+    enterprise: {
+        hostLimit: 200,
+        screensPerHost: UNLIMITED,
+        sharedLayoutsPerHost: UNLIMITED,
+        templatesPerHost: UNLIMITED,
+        storagePerHostMb: 122880,
+        membersPerHost: 500,
+        managersPerOrg: 200,
+        maxManagersPerOrg: 1000,
+        maxMembersPerHost: 2000,
+        bandwidthGb: 3080,
+        formSubmissionsPerMonth: 50000,
+        formsPerHost: FORMS_PER_HOST_CEILING,
+        variablesPerHost: UNLIMITED,
+        functionsPerHost: UNLIMITED,
+        workflowsPerHost: UNLIMITED,
+        workflowRunsPerMonth: 4000000,
+        servicesPerHost: UNLIMITED,
+        redirectsPerHost: UNLIMITED,
+        contactsPerHost: 1000000,
+        // Finite like the campaign allowance beside it, and for the same reason
+        // one-to-one mail is capped on every other tier: a rep with a template
+        // and a list can put thousands of messages onto the platform's sending
+        // reputation in an afternoon. A negotiated agreement whose reps need more
+        // than 2,000 a day says so, and the override is what carries it.
+        crmEmailsPerDay: 2000,
+        emailSendsPerMonth: ENTERPRISE_EMAIL_SENDS_PER_MONTH,
+        actionRunsPerMonth: 2000000,
+        assistCreditsPerMonth: ENTERPRISE_ASSIST_CREDITS_PER_MONTH,
+        apiRequestsPerMonth: 10000000,
+        datasetsPerOrg: 4000,
+        maxDatasetsPerOrg: 10000,
+        recordsPerDataset: UNLIMITED,
+        dataStorageMbPerOrg: 1024000,
+        productsPerHost: UNLIMITED,
+        inventoryLocations: 100,
+        posRegisters: 40,
+        transactionFeePhysicalPct: 0,
+        transactionFeeDigitalPct: 0,
+        marketplaceFeePct: 20,
+        features: {
+            abTesting: true,
+            versioning: true,
+            reusableComponents: true,
+            customDomain: true,
+            customSendingDomain: true,
+            dedicatedSendingDomain: true,
+            removeBranding: true,
+            scheduledPublishing: true,
+            marketplaceSelling: true,
+            aiAssist: true,
+            aiGenerative: true,
+            workflows: true,
+            dataStore: true,
+            videoMedia: true,
+            bookings: true,
+            crm: true,
+            outreach: false,
+            interactions: true,
+            actions: true,
+            webhooks: true,
+            apiAccess: true,
+            siteExport: true,
+            multilingual: true,
+            // Event Calendar stays an add-on purchase, as on every other tier.
+            eventCalendar: false,
+            redirects: true,
+            screenAnalytics: true,
+            mediaCdn: true,
+            marketingOverlays: true,
+            commerce: true,
+            pos: true,
+            storefrontSubscriptions: true,
+            contentGating: true,
+            giftCards: true,
+            productReviews: true,
+            abandonedCart: true,
+            dropshipRouting: true,
+            commerceAnalytics: true,
+            whiteLabel: true,
+            // SSO (AGL-1101) is the Enterprise differentiator — the only plan that
+            // carries it by default. Lower tiers still need a per-org override.
+            ssoEnabled: true
+        }
+    }
+};
+/**
+ * The tiers a customer can buy themselves — every plan EXCEPT `enterprise`
+ * (AGL-1118), which is priced per deal and provisioned by staff (AGL-1110).
+ * Any surface that offers plans for sale (the console plan-cards grid, the
+ * marketing pricing table, the plan-change dialog) MUST iterate this rather
+ * than `Object.keys(PLAN_ENTITLEMENTS)`, so a custom-priced tier can never
+ * show a self-serve Upgrade button or a $0 headline price.
+ */ export const SELF_SERVE_PLANS = [
+    'free',
+    'starter',
+    'pro',
+    'business',
+    'scale',
+    'advanced',
+    'agency'
+];
+/**
+ * Whether the plan has no list price and is quoted per deal (AGL-1118).
+ * `PLAN_PRICING` still carries a row for it — the record is exhaustive by
+ * type — but every figure there is 0/null and means "no list price", NOT
+ * "free". Revenue for such an org comes from `subscription.customMonthlyUsd`.
+ */ export function isCustomPricedPlan(plan) {
+    return plan === 'enterprise';
+}
+/** Human plan names — the ONE source every plan badge/label reads. */ export const PLAN_LABELS = {
+    free: 'Free',
+    starter: 'Starter',
+    pro: 'Pro',
+    business: 'Business',
+    scale: 'Scale',
+    advanced: 'Advanced',
+    agency: 'Agency',
+    enterprise: 'Enterprise'
+};
+/**
+ * Event Calendar add-on (AGL-145): first-party, Aglyn-supported, $9/mo
+ * **per organization** — cost×1.3 floor honored (mostly Firestore reads).
+ * Enabled via the `eventCalendar` entitlement override at purchase.
+ *
+ * NOT per host, despite what this comment said until AGL-1279. AGL-145
+ * shipped it per host; AGL-526 then made add-ons self-serve and capped this
+ * one at `return 1` in `app/api/billing/addons/route.ts`, and
+ * `resolveOrgEntitlements` flips a single org-level `features.eventCalendar`
+ * boolean from any quantity >= 1. One purchase covers every host in the org.
+ * The marketing copy on /pricing is written against that behaviour.
+ */ export const EVENT_CALENDAR_ADDON_MONTHLY_USD = 9;
+/**
+ * POS Pro register add-on (AGL-329): $89/mo per extra register/location
+ * (Shopify POS Pro parity). Purchased add-ons land as a per-org
+ * `posRegisters` entitlement override, which
+ * `resolveOrgEntitlements` already applies over the plan default.
+ */ export const POS_REGISTER_ADDON_MONTHLY_USD = 89;
+/**
+ * The Aglyn AI add-on's credit band (AGL-2896): the credits a month the
+ * add-on ADDS to the plan's `assistCreditsPerMonth` when
+ * `seatAddons.aiAddon` is set. One pool and one meter — the add-on widens
+ * the band the assist meter already draws on rather than opening a second
+ * one, so `resolveAssistCreditBudget`, the overage price and the hard-cap
+ * switch all see one number.
+ *
+ * ## Sized against the add-on's own price
+ *
+ * A credit is `ASSIST_CREDIT_COST_USD` of provider spend, so each band is a
+ * cost figure: 1,000 credits are $1.00. Every band here costs at most 50% of
+ * `PlanPricing.aiAddonMonthlyUsd` at full consumption — Starter $4 of $9,
+ * Pro $9 of $19, Business $19 of $39, Scale $34 of $69, Advanced $49 of
+ * $99, Agency $149 of $299 — which is the same line-margin floor
+ * (`ASSIST_CREDIT_MIN_MARGIN_PCT`) every retail assist rate clears.
+ * `tier-margin-floor.spec.ts` holds the whole tier non-negative with the
+ * add-on band at 100% and the add-on's revenue counted, and pins each band's
+ * share of its price.
+ *
+ * ## Free and Enterprise
+ *
+ * Free is 0: the plan sells no add-on (`aiAddonMonthlyUsd` is null), so a
+ * quantity written onto a Free org adds nothing. Enterprise is finite at
+ * twice Agency's, the rule every Enterprise fallback follows since the
+ * 2026-09-07 decision (AGL-2654) — never `UNLIMITED`, for the reason
+ * `ENTERPRISE_ASSIST_CREDITS_PER_MONTH` gives: an unbounded band reads back
+ * as zero off the wire. Enterprise carries `aiGenerative` in the agreement
+ * and its price is null too, so this figure is what a contract that names
+ * the add-on starts from before its own number is written.
+ */ export const AI_ADDON_CREDITS_PER_MONTH = {
+    free: 0,
+    starter: 4000,
+    pro: 9000,
+    business: 19000,
+    scale: 34000,
+    advanced: 49000,
+    agency: 149000,
+    enterprise: 298000
+};
+/**
+ * The generative add-on's name as a person sees it (AGL-2896): the brand,
+ * then "AI". Read from the platform brand by default and from the org's
+ * resolved `productName` where the surface has one, for the reason every
+ * rendered product name is: a self-host operator renames the product by
+ * configuration, and a white-label org must not see ours.
+ */ export const aiAddonName = (brand = PLATFORM_BRAND_NAME)=>`${brand} AI`;
+/**
+ * Purchase ceilings for the two add-on kinds that have NO per-plan hard max
+ * (AGL-1738). They live here, beside the bands and the resolver they bound,
+ * because they ARE the bound — and until now they were two private literals
+ * in `app/api/billing/addons/route.ts`, seventeen hundred lines and one
+ * project away from the `+` they cap.
+ *
+ * That distance is why AGL-1738 read `resolveOrgEntitlements` as unbounded
+ * and proposed a `maxPosRegistersPerHost` clamp. Do not add one. Seats and
+ * datasets clamp at `checkSeatQuota` / `checkDatasetQuota` because their
+ * plans genuinely refuse to sell past a band (`upgradeRequired` flips and
+ * the answer is a plan change). Registers and extra sites are sold flat
+ * instead: `addonMax()` will sell an org up to these quantities on ANY plan
+ * carrying the feature, so a band-shaped clamp in the resolver would take
+ * back registers the merchant is being invoiced $89/mo each for — the
+ * expensive direction of a wrong clamp, and the reason the add stays open.
+ *
+ * The self-serve route is the only path that writes `seatAddons` from a
+ * purchase, so these are the real ceilings: a plan's band plus at most
+ * `POS_REGISTERS_ADDON_MAX` registers, or plus `EXTRA_HOSTS_ADDON_MAX` sites.
+ * Any console surface that windows a head-count must clear the SUM, not the
+ * band (`registers-card.component.tsx` still windows at 25; AGL-1738).
+ */ export const EXTRA_HOSTS_ADDON_MAX = 100;
+/** @see EXTRA_HOSTS_ADDON_MAX — the flat register ceiling, per org. */ export const POS_REGISTERS_ADDON_MAX = 50;
+/**
+ * Flat subscription pricing per tier (AGL-68). Kept beside the entitlements
+ * so price changes ride the same review path; Stripe price ids map to plans
+ * via `STRIPE_PRICE_*` env vars on the billing API routes.
+ */ export const PLAN_PRICING = {
+    free: {
+        basePriceMonthlyUsd: 0,
+        basePriceAnnualMonthlyUsd: 0,
+        extraHostMonthlyUsd: null,
+        extraSeatMonthlyUsd: null,
+        extraCollaboratorMonthlyUsd: null,
+        extraDatasetMonthlyUsd: null,
+        extraDataGbMonthlyUsd: null,
+        extraApiRequestsUsdPer1k: null,
+        extraAssistCreditsUsdPer1k: null,
+        aiAddonMonthlyUsd: null,
+        extraContactsUsdPer1k: null,
+        extraEmailSendsUsdPer1k: null,
+        meteredInfraPassThrough: false
+    },
+    starter: {
+        basePriceMonthlyUsd: 25,
+        basePriceAnnualMonthlyUsd: 16,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 5,
+        extraCollaboratorMonthlyUsd: 3,
+        extraDatasetMonthlyUsd: 2,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: null,
+        // The top of the retail ladder, which Starter JOINS rather than steps
+        // above (AGL-3203): the ladder descends with the tier, and Starter is the
+        // rung below Pro, not a new one over it. Moves in lockstep with the 750
+        // credit band on the Starter entitlements — the band without this rate is
+        // the silent free overage, and this rate without the band is a fee
+        // advertised on a quantity the plan never sold.
+        extraAssistCreditsUsdPer1k: 3,
+        aiAddonMonthlyUsd: 9,
+        extraContactsUsdPer1k: 1,
+        // No email band to be "over" — see `emailSendsPerMonth` on the Starter
+        // entitlements. `emailSendsOverage` returns 0 for any non-positive band,
+        // so a rate here would price volume that can never be computed, which is
+        // the same defect as a rate beside an UNLIMITED band.
+        extraEmailSendsUsdPer1k: null,
+        meteredInfraPassThrough: true
+    },
+    pro: {
+        basePriceMonthlyUsd: 56,
+        basePriceAnnualMonthlyUsd: 39,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 4,
+        extraCollaboratorMonthlyUsd: 2,
+        extraDatasetMonthlyUsd: 2,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: null,
+        extraAssistCreditsUsdPer1k: 3,
+        aiAddonMonthlyUsd: 19,
+        extraContactsUsdPer1k: 0.75,
+        extraEmailSendsUsdPer1k: 2.25,
+        meteredInfraPassThrough: true
+    },
+    business: {
+        basePriceMonthlyUsd: 139,
+        basePriceAnnualMonthlyUsd: 99,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 3,
+        extraCollaboratorMonthlyUsd: 1,
+        extraDatasetMonthlyUsd: 1,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: 0.5,
+        extraAssistCreditsUsdPer1k: 2.75,
+        aiAddonMonthlyUsd: 39,
+        extraContactsUsdPer1k: 0.5,
+        extraEmailSendsUsdPer1k: 2,
+        meteredInfraPassThrough: true
+    },
+    scale: {
+        basePriceMonthlyUsd: 249,
+        basePriceAnnualMonthlyUsd: 179,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 2,
+        extraCollaboratorMonthlyUsd: 1,
+        extraDatasetMonthlyUsd: 1,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: 0.35,
+        extraAssistCreditsUsdPer1k: 2.5,
+        aiAddonMonthlyUsd: 69,
+        extraContactsUsdPer1k: 0.4,
+        extraEmailSendsUsdPer1k: 1.9,
+        meteredInfraPassThrough: true
+    },
+    advanced: {
+        basePriceMonthlyUsd: 399,
+        basePriceAnnualMonthlyUsd: 299,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 2,
+        extraCollaboratorMonthlyUsd: 1,
+        extraDatasetMonthlyUsd: 1,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: 0.2,
+        extraAssistCreditsUsdPer1k: 2.25,
+        aiAddonMonthlyUsd: 99,
+        // FLOORED at the 50% retail margin, not stepped down again. The ladder
+        // above it descends $1.00 → $0.75 → $0.50 → $0.40, and one more step
+        // would have reached $0.25 against a `perContactMonth` cost of $0.20 per
+        // 1,000 — a 20% line margin on a retail price, thinner than the 23% the
+        // infrastructure pass-through earns while being sold as cost recovery.
+        extraContactsUsdPer1k: 0.4,
+        extraEmailSendsUsdPer1k: 1.85,
+        meteredInfraPassThrough: true
+    },
+    // Agency is the one tier whose PRICE moved. It included 100 hosts, 20 TB of
+    // bandwidth and an unbounded form-submission band against $799, which made
+    // it both the worst margin on the ladder and the most underpriced against
+    // the field: Duda charges ~$1,396-1,493/mo for 100 sites, BigCommerce
+    // Enterprise starts at $1,499 and Shopify Plus at $2,300. $1,299 still
+    // undercuts all three for the buyer this architecture is built for.
+    agency: {
+        basePriceMonthlyUsd: 1299,
+        // $1,049/mo is $12,588 a year, which is what the live Stripe yearly price
+        // charges. Stripe prices are immutable, so the constant every surface
+        // quotes has to match the one a customer is actually billed by — a
+        // ratio-derived figure that no price object backs would quote one number
+        // and charge another. It lands within a dollar of holding the previous
+        // 18.8% annual discount across the rise, which is what stops the annual
+        // interval becoming the cheap way past a repricing.
+        basePriceAnnualMonthlyUsd: 1049,
+        extraHostMonthlyUsd: 20,
+        extraSeatMonthlyUsd: 2,
+        extraCollaboratorMonthlyUsd: 1,
+        extraDatasetMonthlyUsd: 1,
+        extraDataGbMonthlyUsd: 0.36,
+        extraApiRequestsUsdPer1k: 0.15,
+        extraAssistCreditsUsdPer1k: 2,
+        aiAddonMonthlyUsd: 299,
+        // $0.40, because the band it meters is now FINITE.
+        //
+        // This row has been wrong in both directions. It shipped $0.20 against an
+        // UNLIMITED band, advertising a fee that could not be charged —
+        // `checkContactQuota` computes `Math.max(0, used - Infinity)`, which is 0
+        // at every usage level (AGL-2439) — and was corrected to `null` to stop
+        // publishing a claim the code could not honour. Bounding the band inverts
+        // the problem: a finite band with no rate is usage past a bound that is
+        // silently free, and the bound achieves nothing.
+        //
+        // $0.40 rather than a further step down the ladder because that is the
+        // 50% retail floor against a `perContactMonth` cost of $0.20 per 1,000 —
+        // the same figure Scale and Advanced carry, and the same floor that moved
+        // Advanced off $0.25.
+        //
+        // It METERS rather than walls: a rate is what makes `checkContactQuota`
+        // return `allowed: true` past the band, so a growing audience is billed
+        // and never dropped. That is what makes bounding this band safe here and
+        // NOT safe on enterprise, whose every rate is the "not for sale"
+        // sentinel.
+        extraContactsUsdPer1k: 0.4,
+        extraEmailSendsUsdPer1k: 1.8,
+        meteredInfraPassThrough: true
+    },
+    // Enterprise (AGL-1118) has NO list price — every figure here is the
+    // "not for sale" sentinel, not a $0 offer (`isCustomPricedPlan`). The org's
+    // real price is the negotiated `subscription.customMonthlyUsd` the
+    // enterprise-billing flow writes (AGL-1110), which `orgListPriceMonthlyUsd`
+    // already prefers over the plan default; a comped enterprise org genuinely
+    // bills $0, and that is what this row then reports. Nulls also mean the
+    // plan sells no self-serve add-on seats — enterprise capacity is unlimited,
+    // so there is nothing to buy.
+    enterprise: {
+        basePriceMonthlyUsd: 0,
+        basePriceAnnualMonthlyUsd: 0,
+        extraHostMonthlyUsd: null,
+        extraSeatMonthlyUsd: null,
+        extraCollaboratorMonthlyUsd: null,
+        extraDatasetMonthlyUsd: null,
+        extraDataGbMonthlyUsd: null,
+        extraApiRequestsUsdPer1k: null,
+        extraAssistCreditsUsdPer1k: null,
+        aiAddonMonthlyUsd: null,
+        extraContactsUsdPer1k: null,
+        extraEmailSendsUsdPer1k: null,
+        meteredInfraPassThrough: false
+    }
+};
+/**
+ * The price list a plan's row becomes when a staff COMP is what grants it
+ * (AGL-3034): the list prices kept, and nothing for sale.
+ *
+ * Every other figure on a row prices something sold on top of a subscription —
+ * an add-on item, or usage past a band billed onto that subscription's next
+ * invoice. A comp has no subscription to add an item to or to invoice, so
+ * every one of them is `null` and the pass-through is off. That is `free`'s
+ * reasoning (`meteredInfraPassThrough`: "there is no subscription to hang a
+ * metered item on"), and it turns each band into a wall rather than a line
+ * past which usage is sold to nobody.
+ *
+ * It is also what keeps a comp away from Stripe without a check anyone could
+ * forget: the AI overage charge claims only what `assistMonthOverage` prices,
+ * the usage sweep bills only what these rates price, and a `null` rate prices
+ * zero. A comp that needs more of something gets a quota override beside it,
+ * or is uncapped outright (AGL-3049) — and an uncapped comp reads THIS row
+ * too, so lifting every band sells nothing past any of them.
+ *
+ * Derived from the row rather than written out, so a rate added to
+ * `PlanPricing` later is withheld from a comp on the day it ships.
+ */ function compPricing(pricing) {
+    const withheld = {};
+    for (const [key, value] of Object.entries(pricing)){
+        if (key === 'basePriceMonthlyUsd' || key === 'basePriceAnnualMonthlyUsd') {
+            withheld[key] = value;
+        } else if (typeof value === 'boolean') {
+            withheld[key] = false;
+        } else {
+            withheld[key] = null;
+        }
+    }
+    return withheld;
+}
+const PLAN_COMP_PRICING = Object.fromEntries(Object.entries(PLAN_PRICING).map(([plan, pricing])=>[
+        plan,
+        compPricing(pricing)
+    ]));
+/**
+ * The prices the org's usage and add-ons are sold at (AGL-3034): its
+ * effective plan's row, or that row with nothing for sale when a staff comp
+ * is what grants the plan — see `compPricing`.
+ *
+ * EVERY reader that decides whether something past a band is sold, or what a
+ * purchasable seat costs, reads this rather than indexing `PLAN_PRICING` by
+ * the effective plan. Indexing it directly is how a comp would be quoted a
+ * rate nobody can be invoiced at.
+ */ export function resolvePlanPricing(org) {
+    const plan = resolveEffectivePlan(org);
+    return resolvePlanComp(org) ? PLAN_COMP_PRICING[plan] : PLAN_PRICING[plan];
+}
+/**
+ * Subscription states that stop paying for the plan (AGL-247). `past_due`
+ * keeps working as a dunning grace period; these do not.
+ *
+ * `incomplete_expired` is the state a signup reaches when its first payment
+ * never completes — an abandoned SCA challenge, a card that never
+ * authenticated — and Stripe stamps it about a day later. It has charged
+ * nothing and never will, so it belongs here beside `incomplete`, which is the
+ * same subscription an hour earlier. `LIVE_SUBSCRIPTION_STATUSES` in
+ * `org-billing-doc.ts` already excludes it and `DEAD_STATUSES` in
+ * `utils/subscription-period-notice.ts` already names it; this set is the one
+ * that decides both what a workspace GETS and whether we count it as revenue,
+ * so it is the one place the omission cost money in both directions at once.
+ *
+ * THE DENYLIST FORM IS THE HAZARD, and it is why the omission was silent: an
+ * allowlist of live statuses cannot rot when Stripe adds a status, whereas a
+ * denylist of dead ones silently grants the plan — and books the MRR — for
+ * every status nobody has enumerated yet. The three readers below keep the
+ * denylist anyway, because the direction they fail in is not the same as the
+ * live-side question's: an unrecognized status here must not revoke a paying
+ * workspace's features, while `isLiveSubscriptionStatus` refusing to call an
+ * unrecognized status live only ever declines to sell a second subscription.
+ * A new Stripe status therefore has to be added HERE by hand, which is a
+ * standing obligation rather than a property of the code.
+ */ const DEAD_SUBSCRIPTION_STATUSES = new Set([
+    'canceled',
+    'unpaid',
+    'incomplete',
+    'incomplete_expired'
+]);
+/**
+ * The subscription status entitlement resolution runs on (AGL-1028).
+ *
+ * `subscription` moved to `orgs/{orgId}/billing/stripe`, behind
+ * `canManageOrg()` — but the status word is an ENTITLEMENT input, not a
+ * commercial secret: `resolveEffectivePlan` downgrades a paid plan to free on a
+ * dead subscription, and `resolvePurchasedAddons` stops counting add-ons on
+ * one. Both resolve in the tenant runtime and in console components belonging
+ * to members who cannot read a manager-gated doc, so the webhook mirrors the
+ * bare status string back onto the org doc as `billingStatus`.
+ *
+ * Reads the mirror first, then the inline `subscription` — the fallback is what
+ * keeps entitlements correct for orgs the backfill has not reached yet, and for
+ * any caller still passing a whole billing doc rather than an org doc.
+ */ function subscriptionStatusOf(org) {
+    var _org_subscription;
+    const mirrored = org == null ? void 0 : org.billingStatus;
+    if (typeof mirrored === 'string' && mirrored) return mirrored;
+    return org == null ? void 0 : (_org_subscription = org.subscription) == null ? void 0 : _org_subscription.status;
+}
+export function orgSubscriptionState(org) {
+    const status = subscriptionStatusOf(org);
+    if (!status) return 'none';
+    return DEAD_SUBSCRIPTION_STATUSES.has(status) ? 'dead' : 'live';
+}
+/**
+ * An instant off a stored value in whichever form it reached this reader: a
+ * Firestore `Timestamp` from either SDK, the `{ seconds }`/`{ _seconds }`
+ * shape a timestamp takes after crossing JSON, a `Date`, or an ISO string.
+ */ function instantOf(value) {
+    var _record_seconds;
+    if (value instanceof Date) {
+        return Number.isNaN(value.getTime()) ? null : value.toISOString();
+    }
+    if (typeof value === 'string') {
+        const millis = Date.parse(value);
+        return Number.isFinite(millis) ? new Date(millis).toISOString() : null;
+    }
+    if (!value || typeof value !== 'object') return null;
+    const toDate = value.toDate;
+    if (typeof toDate === 'function') {
+        const date = toDate.call(value);
+        return date instanceof Date && !Number.isNaN(date.getTime()) ? date.toISOString() : null;
+    }
+    const record = value;
+    const seconds = Number((_record_seconds = record.seconds) != null ? _record_seconds : record._seconds);
+    if (!Number.isFinite(seconds)) return null;
+    // Out of `Date`'s range is Invalid Date, whose `toISOString` throws.
+    const date = new Date(seconds * 1000);
+    return Number.isNaN(date.getTime()) ? null : date.toISOString();
+}
+function trimmedOrNull(value) {
+    return typeof value === 'string' && value.trim() ? value.trim() : null;
+}
+/**
+ * The org's STORED comp (`entitlements.planComp`), whether or not it is in
+ * force, or `null` when there is none (AGL-3034).
+ *
+ * Strict about the one field that grants anything: `plan` must be a paid plan
+ * this build knows. A comp of `free` grants nothing and an unknown plan could
+ * grant anything, so both read as no comp at all — the org then resolves
+ * exactly as it would without one, which is the direction a malformed grant
+ * must fail in. The descriptive fields are narrowed and never block the plan:
+ * a comp whose note or stamp did not read back is still the comp staff wrote.
+ *
+ * `uncapped` is strict in the same direction (AGL-3049): it lifts every cap,
+ * so only a literal `true` does. A `"true"`, a `1` or a map written by hand
+ * reads as a capped comp — the plan still stands, and its bands stay walls.
+ */ export function readOrgPlanComp(org) {
+    const entitlements = org == null ? void 0 : org.entitlements;
+    const raw = entitlements && typeof entitlements === 'object' ? entitlements.planComp : undefined;
+    if (!raw || typeof raw !== 'object' || Array.isArray(raw)) return null;
+    const record = raw;
+    const plan = record['plan'];
+    if (typeof plan !== 'string' || plan === 'free' || !Object.prototype.hasOwnProperty.call(PLAN_ENTITLEMENTS, plan)) {
+        return null;
+    }
+    const reason = record['reason'];
+    return {
+        plan: plan,
+        uncapped: record['uncapped'] === true,
+        reason: isOrgOverrideReasonCode(reason) ? reason : null,
+        note: trimmedOrNull(record['note']),
+        grantedBy: trimmedOrNull(record['grantedBy']),
+        grantedAt: instantOf(record['grantedAt'])
+    };
+}
+/**
+ * The comp IN FORCE: the stored comp while no subscription decides the plan,
+ * and `null` otherwise (AGL-3034).
+ *
+ * A live subscription always wins. The comp is not removed by one starting —
+ * nothing but the staff override writes it — so it waits, dormant, and
+ * applies again if that subscription ends. Staff views say so.
+ */ export function resolvePlanComp(org) {
+    if (orgSubscriptionState(org) === 'live') return null;
+    return readOrgPlanComp(org);
+}
+/**
+ * Whether an UNCAPPED comp is in force (AGL-3049): every band and quota the
+ * org resolves reads as `UNLIMITED`, whatever its plan row and its per-org
+ * overrides say — see `withEveryCapLifted`.
+ *
+ * In force only, like the comp itself. A live subscription decides the plan
+ * and its bands, so a dormant uncapped comp lifts nothing, and a canceled one
+ * lifts every cap again the moment the subscription ends.
+ *
+ * What it does NOT lift is anything that is not a plan band: the fee
+ * percentages (`PRICE_ENTITLEMENT_KEYS`) are prices, and the platform's own
+ * guards live outside the entitlements map and are not the plan's to give
+ * away — the form-submission and bandwidth abuse ceilings (which read an
+ * unlimited band as `FORM_ABUSE_CEILING_UNLIMITED` and
+ * `BANDWIDTH_ABUSE_CEILING_UNLIMITED`), the flat per-site caps on webhooks,
+ * actions and collection entries, the email send pacing, the assist runaway
+ * message cap, an operator's explicit spend ceiling, and staff pauses and
+ * lockdowns. It never sells anything either: the pricing stays the comp's,
+ * with every rate withheld, so an unbounded band is still billed nothing.
+ *
+ * The lifted value is `UNLIMITED` in process and nowhere else. Every route
+ * that sends a band off-process sends a finite number with an explicit flag,
+ * or `null` with a documented meaning, because `JSON.stringify(Infinity)` is
+ * `null` — and the comp itself is stored and sent as a boolean.
+ */ export function isUncappedPlanComp(org) {
+    var _resolvePlanComp;
+    return ((_resolvePlanComp = resolvePlanComp(org)) == null ? void 0 : _resolvePlanComp.uncapped) === true;
+}
+/**
+ * How a staff chip names a stored comp (AGL-3049): the plan, then whether it
+ * is uncapped and whether a live subscription holds it dormant —
+ * `Enterprise (uncapped)`, `Pro (dormant)`, `Agency (uncapped, dormant)`.
+ *
+ * One reading of the terms, so the orgs list, the org summary and the
+ * override dialog cannot describe the same grant differently. `name` is the
+ * plan as the surface already writes plans: the label by default, the stored
+ * key on the surfaces whose other chips show keys.
+ */ export function planCompLabel(comp, inForce, name = PLAN_LABELS[comp.plan]) {
+    const terms = [
+        comp.uncapped ? 'uncapped' : null,
+        inForce ? null : 'dormant'
+    ].filter(Boolean).join(', ');
+    return terms ? `${name} (${terms})` : name;
+}
+/**
+ * A stored comp as a sentence names it (AGL-3049): `uncapped Enterprise
+ * comp`, `Pro comp`. Shared by the plan description and the override route's
+ * account of what it changed.
+ */ export function planCompPhrase(comp) {
+    return `${comp.uncapped ? 'uncapped ' : ''}${PLAN_LABELS[comp.plan]} comp`;
+}
+/** "A Pro comp", "An uncapped Enterprise comp": the article a phrase takes. */ function withArticle(phrase) {
+    return `${/^[aeiou]/i.test(phrase) ? 'An' : 'A'} ${phrase}`;
+}
+/**
+ * The org's plan, described rather than only resolved (AGL-3034) — the ONE
+ * reading the staff override route answers with and the staff override
+ * dialog renders, so the response and the dialog cannot tell staff two
+ * different stories about the same document.
+ */ export function describeOrgPlan(org) {
+    const subscription = orgSubscriptionState(org);
+    const status = subscriptionStatusOf(org);
+    const stored = org == null ? void 0 : org.plan;
+    const storedPlan = typeof stored === 'string' && Object.prototype.hasOwnProperty.call(PLAN_ENTITLEMENTS, stored) ? stored : null;
+    const comp = readOrgPlanComp(org);
+    const compInForce = comp !== null && subscription !== 'live';
+    const decidedBy = subscription === 'live' ? 'subscription' : compInForce ? 'comp' : subscription === 'dead' ? 'lapsed' : storedPlan && storedPlan !== 'free' ? 'stored-plan' : 'no-plan';
+    return {
+        effectivePlan: resolveEffectivePlan(org),
+        storedPlan,
+        subscriptionStatus: typeof status === 'string' && status ? status : null,
+        subscription,
+        comp,
+        compInForce,
+        uncapped: compInForce && (comp == null ? void 0 : comp.uncapped) === true,
+        decidedBy
+    };
+}
+/**
+ * One sentence for staff saying what decides the plan and what a plan set in
+ * the override dialog would do (AGL-3034). Shared by the route's response and
+ * the dialog, for the reason `describeOrgPlan` is.
+ *
+ * A comp in force also says whether its bands are walls or lifted
+ * (AGL-3049), because that is the question a comped workspace refused at a
+ * band brings to staff.
+ */ export function orgPlanDescriptionSentence(description) {
+    var _description_subscriptionStatus;
+    const label = (plan)=>plan ? PLAN_LABELS[plan] : 'no plan';
+    const status = (_description_subscriptionStatus = description.subscriptionStatus) != null ? _description_subscriptionStatus : 'none';
+    const dormant = description.comp && !description.compInForce ? ` ${withArticle(planCompPhrase(description.comp))} is stored and ` + 'dormant: it takes effect if the subscription ends.' : '';
+    switch(description.decidedBy){
+        case 'subscription':
+            return `The live subscription (${status}) decides the plan: ` + `${label(description.effectivePlan)}. Stripe's next subscription ` + `event rewrites a plan set here.${dormant}`;
+        case 'comp':
+            return `${label(description.effectivePlan)} is in force as ` + `${description.uncapped ? 'an uncapped' : 'a'} staff comp, ` + (description.subscription === 'dead' ? `because the subscription is ${status}. ` : 'because no subscription pays for this workspace. ') + (description.uncapped ? 'It bills nothing, every band and quota reads as unlimited, ' : 'It bills nothing, every band is a hard limit that a quota ' + 'override can raise, ') + 'and it lasts until it is removed or a live subscription starts.';
+        case 'lapsed':
+            return `The subscription is ${status}, so this workspace resolves as ` + `${label('free')}` + (description.storedPlan && description.storedPlan !== 'free' ? ` — the stored ${label(description.storedPlan)} grants nothing` : '') + '. A plan set here is written as a staff comp.';
+        case 'stored-plan':
+            return `No subscription: the plan stored directly, ` + `${label(description.storedPlan)}, decides it. A plan set here is ` + 'written as a staff comp.';
+        default:
+            return `No subscription and no paid plan, so this workspace resolves as ` + `${label('free')}. A plan set here is written as a staff comp.`;
+    }
+}
+/**
+ * Whether the org is actually being charged for its plan right now.
+ *
+ * This is deliberately stricter than `resolveEffectivePlan`: entitlement
+ * asks "what does this org get", revenue asks "who is paying us". A staff
+ * plan override (`/admin/orgs`) never writes `subscription` — before AGL-3034
+ * it wrote `plan`, and now it writes a comp — so a comped or dark-launched
+ * org resolves to a paid plan while billing nothing, and counting it inflates
+ * MRR (AGL-925). No subscription mirror means no Stripe subscription means no
+ * revenue.
+ *
+ * A comp never reaches this answer: it reads the stored `plan` and the
+ * status, never `entitlements.planComp`, and a comp is only ever in force
+ * where the status is dead or absent — both of which answer false here.
+ *
+ * `past_due` counts: Stripe is still retrying and the plan is still owed.
+ */ export function isBillingSubscription(org) {
+    const plan = org == null ? void 0 : org.plan;
+    if (!plan || plan === 'free' || !(plan in PLAN_ENTITLEMENTS)) return false;
+    const status = subscriptionStatusOf(org);
+    if (!status) return false;
+    return !DEAD_SUBSCRIPTION_STATUSES.has(status);
+}
+/**
+ * The org's monthly LIST price in USD — plan base plus every purchased add-on
+ * (manager/collaborator seats, datasets, extra hosts, POS registers, Event
+ * Calendar), BEFORE any applied discount, and 0 for anyone not actually
+ * billing. This is the sticker price the plan + add-ons would bill at.
+ *
+ * Annual subscriptions contribute their per-month equivalent
+ * (`basePriceAnnualMonthlyUsd`), not the month-to-month price, so a mixed
+ * book does not read high by the size of the annual discount. Add-ons bill
+ * per-month (annual variants are ×12 with no discount), so each contributes
+ * its monthly price on either interval.
+ *
+ * Pricing-v3 fix (2026-07): previously omitted the host, POS-register, and
+ * Event-Calendar add-ons, understating the total for every org carrying them.
+ *
+ * AGL-1105: split out of `orgMonthlyRevenueUsd`, which now subtracts an
+ * applied per-org discount on top of this. Callers wanting the pre-discount
+ * sticker (the margin guardrail, a "what would this bill at" quote) use this;
+ * callers wanting the actual money collected use `orgMonthlyRevenueUsd`.
+ */ export function orgListPriceMonthlyUsd(org) {
+    var _ref;
+    var _org_subscription, _org_subscription1;
+    if (!isBillingSubscription(org)) return 0;
+    // Custom enterprise price (AGL-1110): a negotiated amount is the list price
+    // outright — it already reflects the whole deal, so it overrides the plan
+    // default AND the seat/host add-on math (those are folded into the quote).
+    // Stored monthly-normalized, so it is used as-is.
+    const custom = org == null ? void 0 : (_org_subscription = org.subscription) == null ? void 0 : _org_subscription.customMonthlyUsd;
+    if (typeof custom === 'number' && custom > 0) {
+        return Math.round(custom * 100) / 100;
+    }
+    const pricing = PLAN_PRICING[org == null ? void 0 : org.plan];
+    if (!pricing) return 0;
+    const annual = (org == null ? void 0 : (_org_subscription1 = org.subscription) == null ? void 0 : _org_subscription1.interval) === 'year';
+    const addons = (_ref = org == null ? void 0 : org.seatAddons) != null ? _ref : {};
+    const seats = (quantity, price)=>Math.max(0, quantity != null ? quantity : 0) * (price != null ? price : 0);
+    return (annual ? pricing.basePriceAnnualMonthlyUsd : pricing.basePriceMonthlyUsd) + seats(addons.managers, pricing.extraSeatMonthlyUsd) + seats(addons.members, pricing.extraCollaboratorMonthlyUsd) + seats(addons.datasets, pricing.extraDatasetMonthlyUsd) + seats(addons.hosts, pricing.extraHostMonthlyUsd) + seats(addons.posRegisters, POS_REGISTER_ADDON_MONTHLY_USD) + seats(addons.eventCalendar, EVENT_CALENDAR_ADDON_MONTHLY_USD) + // A toggle, not a quantity: one purchase covers the org, so a stored
+    // quantity above one bills once.
+    seats(aiAddonUnits(addons), pricing.aiAddonMonthlyUsd);
+}
+/**
+ * How many Aglyn AI add-ons a purchase map counts as: 0 or 1 (AGL-2896).
+ * The add-on is org-wide like Event Calendar, so a quantity above one — a
+ * hand edit, a doubled webhook item — is one purchase, and a non-number,
+ * `NaN` or a negative is none.
+ */ export function aiAddonUnits(addons) {
+    var _ref;
+    const quantity = Number((_ref = addons == null ? void 0 : addons.aiAddon) != null ? _ref : 0);
+    return Number.isFinite(quantity) && quantity >= 1 ? 1 : 0;
+}
+/**
+ * A list price net of a discount (AGL-1105). Percentage discounts scale the
+ * whole bill; fixed discounts subtract a flat USD amount. Never below 0, and
+ * a percentage is clamped to 0–100. Prefers `percentOff` when both are
+ * somehow set (Stripe coupons carry only one). Rounds to whole cents.
+ */ export function applyDiscountUsd(listPriceUsd, discount) {
+    if (!(listPriceUsd > 0) || !discount) return Math.max(0, listPriceUsd);
+    if (typeof discount.percentOff === 'number') {
+        const pct = Math.min(100, Math.max(0, discount.percentOff));
+        return Math.round(listPriceUsd * (1 - pct / 100) * 100) / 100;
+    }
+    if (typeof discount.amountOffUsd === 'number') {
+        return Math.max(0, Math.round((listPriceUsd - discount.amountOffUsd) * 100) / 100);
+    }
+    return listPriceUsd;
+}
+/**
+ * Whether an org should read as **"Enterprise"** everywhere the plan is shown.
+ * Three ways to qualify:
+ *  - **`plan === 'enterprise'`** — the real plan (AGL-1118). This is the path
+ *    every new enterprise org takes, and the only one that also grants
+ *    Enterprise *entitlements*; the two below are display-only overlays on a
+ *    lower base plan;
+ *  - a billing org on a **negotiated custom price** (`customMonthlyUsd > 0`) —
+ *    a paying enterprise deal still parked on its pre-AGL-1118 base plan; or
+ *  - an explicit **`org.enterprise`** marker — a *comped* enterprise account,
+ *    100%-discounted so it collects $0 while infra cost is still metered.
+ *
+ * ⚠️ This function answers ONE question — "does this org read as Enterprise" —
+ * and it is not the same question as "what does this org get". Only the first
+ * bullet grants anything: `resolveEffectivePlan` reads `org.plan` and nothing
+ * else, so `org.enterprise` and `customMonthlyUsd` are read NOWHERE but here.
+ * A comped or custom-priced org resolves its BASE plan's entitlements, and
+ * gets Enterprise capability through a per-org `entitlements` override — see
+ * `ssoEnabled`, whose docblock calls that "how enterprise orgs provisioned
+ * before that plan existed still get it".
+ *
+ * This paragraph replaces a parenthetical claiming the comped marker carried
+ * "full Enterprise capability + SSO" (AGL-2297). It never did, and the billing
+ * page believed it: the Enterprise card ticked five entitlements against any
+ * org this function marked, so a comped org whose overrides granted SSO but
+ * not white-label was shown a green tick for full white-label while the
+ * branding card correctly refused it.
+ *
+ * The last two are kept for orgs provisioned before `enterprise` was a plan;
+ * migrating such an org to `plan: 'enterprise'` is the clean end state and
+ * changes nothing about how it reads here. List-priced orgs with none of the
+ * three are not enterprise.
+ *
+ * A staff comp in force names the plan instead of the stored one (AGL-3034),
+ * exactly as it does for entitlements: a workspace comped to Enterprise reads
+ * as Enterprise, and one comped to a lower tier does not read as Enterprise
+ * because of a plan stored before the comp. The explicit marker still counts.
+ */ export function isEnterpriseOrg(org) {
+    var _ref;
+    var _org_subscription;
+    const comp = resolvePlanComp(org);
+    if (comp) return comp.plan === 'enterprise' || (org == null ? void 0 : org.enterprise) === true;
+    if ((org == null ? void 0 : org.plan) === 'enterprise') return true;
+    if ((org == null ? void 0 : org.enterprise) === true) return true;
+    return isBillingSubscription(org) && ((_ref = org == null ? void 0 : (_org_subscription = org.subscription) == null ? void 0 : _org_subscription.customMonthlyUsd) != null ? _ref : 0) > 0;
+}
+/**
+ * Human label shown for `enterprise` in plan badges. Kept as a named export
+ * for the surfaces that label a custom-priced org whose stored `plan` is still
+ * a lower tier; a real `plan: 'enterprise'` org gets the same string from
+ * `PLAN_LABELS`.
+ */ export const ENTERPRISE_PLAN_LABEL = PLAN_LABELS.enterprise;
+/**
+ * The org's monthly recurring revenue in USD — its LIST price
+ * (`orgListPriceMonthlyUsd`) net of any applied per-org discount
+ * (`org.discount`, AGL-1105), and 0 for anyone who is not actually billing. A
+ * comped enterprise deal genuinely collects less, so the discount belongs in
+ * MRR; the pre-discount sticker stays available as `orgListPriceMonthlyUsd`.
+ */ export function orgMonthlyRevenueUsd(org) {
+    const listPrice = orgListPriceMonthlyUsd(org);
+    if (listPrice <= 0) return 0;
+    return applyDiscountUsd(listPrice, org == null ? void 0 : org.discount);
+}
+/**
+ * Stripe's standard processing fee on Aglyn's OWN subscription charges
+ * (AGL-1108) — 2.9% + $0.30 per charge. This is the fee Aglyn pays Stripe to
+ * collect a subscription; it is DISTINCT from the storefront platform fee
+ * (`transactionFee*Pct`, the Connect `application_fee`) that a seller's own
+ * Stripe pays on their storefront sales. Revenue/margin should be reasoned on
+ * the NET figure, not gross.
+ */ export const STRIPE_PROCESSOR_FEE_PCT = 0.029;
+export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
+/**
+ * A gross monthly USD amount net of Stripe's processing fee. Annual
+ * subscriptions are charged once per year, so the fixed 30¢ amortizes to
+ * $0.30/12 per month; monthly subscriptions pay it every month. Never
+ * returns below 0.
+ */ export function netOfProcessorFee(grossMonthlyUsd, annual = false) {
+    if (!(grossMonthlyUsd > 0)) return 0;
+    const fixedPerMonth = annual ? STRIPE_PROCESSOR_FEE_FIXED_USD / 12 : STRIPE_PROCESSOR_FEE_FIXED_USD;
+    const net = grossMonthlyUsd * (1 - STRIPE_PROCESSOR_FEE_PCT) - fixedPerMonth;
+    return Math.max(0, Math.round(net * 100) / 100);
+}
+/**
+ * The org's monthly recurring revenue NET of Stripe's processing fee
+ * (AGL-1108) — what Aglyn actually keeps before infra COGS, and the correct
+ * base for margin/discount reasoning. Gross is `orgMonthlyRevenueUsd`; this
+ * subtracts ~2.9%+30¢, interval-aware. 0 for anyone not actually billing.
+ */ export function orgNetMonthlyRevenueUsd(org) {
+    var _org_subscription;
+    const gross = orgMonthlyRevenueUsd(org);
+    if (gross <= 0) return 0;
+    return netOfProcessorFee(gross, (org == null ? void 0 : (_org_subscription = org.subscription) == null ? void 0 : _org_subscription.interval) === 'year');
+}
+/**
+ * Net-margin floor for discount underwriting (AGL-1105). Mirrors the
+ * Enterprise-Pricing-Calculator's ~75% gross-margin target: a discounted
+ * subscription should still keep ≥75% of its net (post-processor-fee) revenue
+ * after infrastructure COGS. Below the floor a discount is warned; well below
+ * it is blocked without explicit sign-off.
+ *
+ * WHAT THIS IS A FLOOR ON (AGL-1930): net revenue less INFRASTRUCTURE COGS,
+ * and nothing else. It is a contribution margin — see `MARGIN_SCOPE_NOTE`,
+ * which is the sentence every staff surface quoting this number has to print
+ * beside it.
+ *
+ * Read as a dollar guard it says: net revenue must be at least
+ * `cogs / (1 − floor)` = **4 × COGS**, and blocks below
+ * `cogs / (1 − floor + band)` ≈ **2.86 × COGS**. That restatement is the point
+ * of AGL-1930 — the percentage is scale-invariant, so the only thing that
+ * moves the real guard line in dollars is the COGS figure fed into it, and on
+ * production today that figure is `INFRA_COGS_PER_SITE_USD × sites` for
+ * **every** org (14 of 14 usage rollups across all 6 orgs, measured
+ * 2026-08-24). Re-tuning this constant therefore re-tunes a multiplier on the
+ * flat floor, not on anything measured. Calibrate the floor first.
+ */ export const NET_MARGIN_FLOOR_PCT = 0.75;
+/**
+ * How far under the floor a discount may sit and still only WARN (AGL-1105).
+ * Within `[floor − band, floor)` staff see a caution; below `floor − band`
+ * the guardrail blocks unless overridden. 10 points, matching the
+ * calculator's soft/hard split.
+ */ export const NET_MARGIN_WARN_BAND_PCT = 0.1;
+/**
+ * What every "net margin" figure in the staff console actually measures
+ * (AGL-1930).
+ *
+ * `checkDiscountMargin`, the enterprise quote card and the coupon badge all
+ * compute `(net revenue − infrastructure COGS) / net revenue`. Support,
+ * acquisition and overhead are not in the model anywhere — no meter records
+ * them and no constant estimates them — so "net margin 78%" is a CONTRIBUTION
+ * margin, and a staff member signing a deal on it is reading a ceiling, not a
+ * profit.
+ *
+ * One exported string rather than three literals: the three surfaces that
+ * print a margin already drifted apart once (AGL-1134), and a caveat that is
+ * true on one screen and absent on the next is worse than none.
+ */ export const MARGIN_SCOPE_NOTE = 'Contribution margin: net revenue less infrastructure COGS only. ' + 'Support, customer acquisition (CAC) and overhead are not in this figure.';
+/**
+ * The `ok` / `warn` / `block` band a cost-recovery margin falls in (AGL-1930).
+ *
+ * Extracted so `NET_MARGIN_FLOOR_PCT` and `NET_MARGIN_WARN_BAND_PCT` have ONE
+ * reader. The staff org page's enterprise quote card had `>= 0.75` and
+ * `>= 0.65` written into its JSX, so re-tuning either constant — the whole
+ * subject of AGL-1930 — would have moved the discount guardrail and left that
+ * card rating deals against the old numbers, silently and with money on the
+ * line.
+ */ export function netMarginRating(marginPct) {
+    return marginPct >= NET_MARGIN_FLOOR_PCT ? 'ok' : marginPct >= NET_MARGIN_FLOOR_PCT - NET_MARGIN_WARN_BAND_PCT ? 'warn' : 'block';
+}
+/**
+ * Per-site monthly infrastructure COGS in USD (AGL-1105). The
+ * Enterprise-Pricing-Calculator's ~$2/site figure — Firebase + Vercel at
+ * cost — charged against every host the org runs. The margin guardrail
+ * subtracts this from net revenue before rating a discount.
+ */ export const INFRA_COGS_PER_SITE_USD = 2;
+/**
+ * Platform markup on passed-through infrastructure costs (AGL-41).
+ *
+ * DEFINED HERE, not in `apps/console/utils/usage-metering.ts`, and re-exported
+ * from there — the same move AGL-2155 made for `pageViewsFromBandwidthGb`, and
+ * for the same reason (AGL-2194). The published `/pricing` pass-through table
+ * states both a cost column and a "you pay (+30%)" column, and
+ * `tools/marketing/build-pricing-tables.mts` must generate both from code so
+ * `npm run check:pricing-tables` can fail on drift. That generator resolves no
+ * `@aglyn/*` path alias, so it can import `plan-entitlements.ts` and nothing
+ * under `apps/console`. A constant the published page depends on must live
+ * where the page's generator can read it.
+ *
+ * The console keeps importing it from `usage-metering` unchanged.
+ */ export const METERED_MARKUP = 1.3;
+/**
+ * Monthly unit costs for the meters the rollup already records (AGL-1134).
+ *
+ * These are OUR costs, not prices — the org is billed at cost × 1.30
+ * (`METERED_MARKUP`, AGL-41). Storage/page-view/form rates match
+ * `METERED_UNIT_RATES_USD` in the metering module on purpose: two files
+ * disagreeing about what a page view costs is exactly the drift this function
+ * exists to remove.
+ *
+ * The three added here are operator-tuned estimates of the same quality as
+ * the existing three — Firestore-backed dataset storage is priced well above
+ * object storage because it is, and API requests and contacts are priced off
+ * the reads behind them. Treat every operator-tuned figure here as
+ * provisional until validated against a real Firebase + Vercel invoice month;
+ * AGL-1134 says so out loud rather than implying the numbers are derived.
+ * `perEmailSend` is the exception and carries its own basis below.
+ *
+ * ## Three of these are shared with the billed table. The rest are NOT.
+ *
+ * `storagePerGbMonth`, `perPageView` and `perFormSubmission` are the metered
+ * infrastructure pass-through, and the customer is charged those figures
+ * times `METERED_MARKUP`. They therefore appear in `METERED_UNIT_RATES_USD`
+ * as well, with identical values, and must be changed in both places at once.
+ *
+ * Everything else here is a cost-model input ONLY. `dataStoragePerGbMonth`,
+ * `perApiRequest`, `perContactMonth` and `perEmailSend` price what an org
+ * costs us; what an org is CHARGED on those axes is a retail rate on
+ * `PLAN_PRICING` that descends with the tier and is not derived from cost.
+ * Adding one of them to `METERED_UNIT_RATES_USD` would put it inside the
+ * "at cost + 30%" claim, which is true of exactly three meters.
+ *
+ * The first three were corrected 2026-08-09 (AGL-1280) — storage $0.03 →
+ * $0.026 and form submissions $0.0005 → $0.00005 — and `perPageView` was
+ * re-pegged 2026-09-09 (AGL-2711), from $0.0001 to $0.00016153846. All three
+ * MUST be changed here and in `METERED_UNIT_RATES_USD` together. See that
+ * table for each figure's basis; it is the one a customer is billed against,
+ * so it is the one that carries the working.
+ *
+ * The page-view basis is no longer an open gap. The rate priced a 627 KB page
+ * against one that measured far more for weeks; the weight reduction that was
+ * preferred over a re-peg has now shipped, the page was re-measured at
+ * 976.1 KB, and the rate is pegged to a 1012.8 KB basis that sits ABOVE it.
+ * `npm run check:page-view-rate` holds that peg, and now fails if the basis
+ * ever drops back below what a published page measures.
+ *
+ * Raising the two here raises measured COGS, which changes no guardrail
+ * verdict: `INFRA_COGS_PER_SITE_USD × sites` is the floor, and it still
+ * outruns measured cost by orders of magnitude at real traffic.
+ */ export const ORG_COGS_UNIT_RATES_USD = {
+    storagePerGbMonth: 0.026,
+    /**
+   * ⛔ HALF OF A PAIR — see ESTIMATED_PAGE_TRANSFER_BYTES, which states the
+   * same page in bytes as this states it in dollars. Both are calibrated
+   * against a 1012.8 KB page and neither may move alone: their quotient is
+   * the cost of a gigabyte, and that is what every bandwidthGb band on the
+   * ladder was sized against.
+   */ perPageView: 0.00016153846,
+    perFormSubmission: 0.00005,
+    /** Firestore-backed dataset bytes — an order pricier than object storage. */ dataStoragePerGbMonth: 0.18,
+    perApiRequest: 0.000002,
+    perContactMonth: 0.0002,
+    /**
+   * One delivered email, whatever produced it — $0.90 per 1,000.
+   *
+   * Unlike its five neighbours this is not an operator-tuned estimate. It is
+   * the provider's own blended rate at the tier above the account's current
+   * one ($90 / 100,000) and also the marginal overage rate on both that tier
+   * and the current one, so it does not fall as volume grows and is the
+   * conservative figure at any usage the platform can reach.
+   *
+   * It prices EVERY send on the cost meter — campaigns, receipts, invites,
+   * password resets — because every one of them is a message the provider
+   * charges for. The band on the plan and the retail overage rate beside it
+   * both concern a smaller quantity; this is the whole bill.
+   */ perEmailSend: 0.0009,
+    /**
+   * One workflow or action run — $12 per million.
+   *
+   * Derived from the run paths at list prices (2026-09-07), because nothing
+   * measurable exists yet: runs execute inside the Vercel request that fired
+   * the event, not in a function of their own, so Cloud Logging carries no
+   * per-run entry to count, and Firestore's operation counts are platform-wide
+   * and cannot be attributed to a run. Over the 14 days to 2026-09-07 the
+   * project logged no run at all.
+   *
+   * The ledger, for an event that executes one workflow on a site holding a
+   * handful of functions, variables and workflows (`runEventWorkflows`,
+   * `runEventActions` and the inbound-webhook run are the same shape):
+   *
+   *   - reads: the triggered query, the workflow map, the host → org lookup,
+   *     the run counter, the functions and the variables — about 12, at
+   *     nam5's $0.06 per 100,000 = $0.0000072
+   *   - writes: the activity row and the counter increment — 2, at $0.18 per
+   *     100,000 = $0.0000036
+   *   - compute: a few milliseconds of active CPU and memory on Fluid compute
+   *     for the expression evaluation, about $0.000001
+   *
+   * $0.0000118, carried as $0.000012. It scales with the catalog a site holds
+   * — every `limit(100)` read above is a query that costs one read per
+   * document returned — and a step that writes a dataset record or calls a
+   * webhook adds to it, so this is the typical figure, not the ceiling.
+   *
+   * It is a COST, not a price: no plan bills runs, and none refuses past the
+   * band on a metered plan. It exists so a tier's run bands reach
+   * `orgMonthlyCogsUsd` and `tier-margin-floor.spec.ts` — Agency's 3,000,000
+   * runs are $36 a month that read as nothing while this was absent.
+   */ perRun: 0.000012
+};
+/**
+ * One org's monthly infrastructure COGS — the single cost model (AGL-1134).
+ *
+ * Replaces two things that had drifted apart: the discount guardrail read the
+ * rollup's `costUsd`, and the staff MRR views read the same field separately,
+ * so neither could be changed without silently changing the other's meaning.
+ *
+ * `costUsd` was also incomplete. The rollup records `dataStorageMb`,
+ * `apiRequests` and `contactsCount`, and `estimateMonthlyUsageCost` prices
+ * none of them — it sums storage, page views and form submissions only. So
+ * the "measured" cost omitted three meters the platform was already at the
+ * trouble of recording.
+ *
+ * The flat per-site figure stays a FLOOR rather than a fallback: measured
+ * cost wins only when it exceeds the estimate. A rollup that has not run, or
+ * an org with genuinely tiny usage, must not make the guardrail more generous
+ * — that is the one direction that costs money.
+ *
+ * Measured against production 2026-07-30, that floor is doing all the work:
+ * the largest real org's `costUsd` was **$0.0000054** against a $4.00 floor
+ * for two sites. Five orders of magnitude. So this function changes no verdict
+ * today, and will not until there is real traffic — which is the honest
+ * reason to build it now, while nothing depends on the answer.
+ */ export function orgMonthlyCogsUsd(rollup, siteCount) {
+    var _ref;
+    const num = (value)=>{
+        const parsed = Number(value != null ? value : 0);
+        return Number.isFinite(parsed) && parsed > 0 ? parsed : 0;
+    };
+    const rates = ORG_COGS_UNIT_RATES_USD;
+    const breakdown = {
+        storage: num(rollup == null ? void 0 : rollup.storageGb) * rates.storagePerGbMonth,
+        pageViews: num(rollup == null ? void 0 : rollup.pageViews) * rates.perPageView,
+        formSubmissions: num(rollup == null ? void 0 : rollup.formSubmissions) * rates.perFormSubmission,
+        // Megabytes on the doc, gigabytes in the rate — the unit mismatch is in
+        // the stored field name, so convert here rather than in each caller.
+        dataStorage: num(rollup == null ? void 0 : rollup.dataStorageMb) / 1024 * rates.dataStoragePerGbMonth,
+        apiRequests: num(rollup == null ? void 0 : rollup.apiRequests) * rates.perApiRequest,
+        // The records band (AGL-2611), under the axis name every breakdown reader
+        // already keys on. `??` and not `||`: a rollup that measured ZERO records
+        // has answered, and must not fall back to a contacts figure from a month
+        // written under the narrower basis.
+        contacts: num((_ref = rollup == null ? void 0 : rollup.crmRecordsCount) != null ? _ref : rollup == null ? void 0 : rollup.contactsCount) * rates.perContactMonth,
+        // Every send, not the overage — the provider bills the first message of
+        // the month as much as the last, so a cost model that started counting at
+        // the plan's included band would report an org that stayed inside its
+        // allowance as free.
+        emailSends: num(rollup == null ? void 0 : rollup.emailSends) * rates.perEmailSend,
+        /*==========================================
+     * AGLYN ASSIST PROVIDER SPEND (AGL-2280).
+     *
+     * Already dollars, so ×1 — see `OrgUsageRollupInput.assistCostUsd`.
+     *
+     * This is the ONE meter on the platform whose unit cost is not a fraction
+     * margin model read it: the discount guardrail priced six meters that
+     * together measured $0.0000054 for the largest real org, and ignored the
+     * only line item that can plausibly clear the $2/site floor on its own.
+     * A 93%-off coupon on an org burning $40/month of tokens rated green.
+     *
+     * It is deliberately NOT in `billedCents` — what an org is charged is a
+     * separate decision with a price sheet behind it. This is what the org
+     * COSTS US, which is the only question the guardrail asks.
+     *=========================================*/ assist: num(rollup == null ? void 0 : rollup.assistCostUsd),
+        // Both run counters on one line: one rate, one cost, whichever builder
+        // produced the run. Unpriced until 2026-09-07 — the two bands were
+        // recorded on every rollup and read as nothing.
+        runs: (num(rollup == null ? void 0 : rollup.workflowRuns) + num(rollup == null ? void 0 : rollup.actionRuns)) * rates.perRun
+    };
+    const measuredUsd = Object.values(breakdown).reduce((sum, x)=>sum + x, 0);
+    const floorUsd = Math.max(0, siteCount) * INFRA_COGS_PER_SITE_USD;
+    return {
+        cogsUsd: Math.max(measuredUsd, floorUsd),
+        basis: measuredUsd > floorUsd ? 'measured' : 'floor',
+        measuredUsd,
+        floorUsd,
+        breakdown
+    };
+}
+/**
+ * Pluck the fields `orgMonthlyCogsUsd` prices out of a raw usage rollup
+ * (AGL-1134) — a Firestore `snapshot.data()`, or the JSON a staff endpoint
+ * served from one. ONE list of field names, in one place.
+ *
+ * The hazard this closes is silent. Every caller previously hand-listed the
+ * six fields at its own call site — the discount route, the anomaly detector,
+ * the staff org page — and `/api/admin/org-usage` projected only three of
+ * them. A projection that drops a priced field does not error; the model just
+ * returns a smaller number, and a smaller COGS is the direction that APPROVES
+ * a discount. Same shape as the API projection that starved a predicate in
+ * AGL-1355, and the two-units usage figure that read 20-45% wrong for years
+ * in AGL-1402.
+ *
+ * UNITS, because the field names do not all say: `storageGb` and
+ * `dataStorageMb` are gigabytes and MEGABYTES respectively (the conversion
+ * lives in `orgMonthlyCogsUsd`, with its own test); `pageViews`,
+ * `formSubmissions`, `apiRequests` and `emailSends` are counts FOR THE MONTH;
+ * `contactsCount` and `crmRecordsCount` are point-in-time levels, not monthly
+ * flows.
+ */ export function orgCogsInputFrom(source) {
+    const read = (field)=>{
+        const value = source == null ? void 0 : source[field];
+        return value == null ? undefined : value;
+    };
+    return {
+        hostCount: read('hostCount'),
+        storageGb: read('storageGb'),
+        pageViews: read('pageViews'),
+        formSubmissions: read('formSubmissions'),
+        dataStorageMb: read('dataStorageMb'),
+        apiRequests: read('apiRequests'),
+        contactsCount: read('contactsCount'),
+        // AGL-2611. The band's own figure, forwarded for the reason `assistCostUsd`
+        // is: a projection that drops it prices the CRM at its contacts alone,
+        // which is the direction that approves a discount.
+        crmRecordsCount: read('crmRecordsCount'),
+        companiesCount: read('companiesCount'),
+        dealsCount: read('dealsCount'),
+        emailSends: read('emailSends'),
+        // AGL-2280. Dollars, not a meter — the projection still has to forward it
+        // or the model prices Assist at nothing, which is the direction that
+        // approves a discount.
+        assistCostUsd: read('assistCostUsd'),
+        // Priced since 2026-09-07 (`perRun`); a projection that drops them prices
+        // the org's automations at nothing, the same direction as every other
+        // omission on this list.
+        workflowRuns: read('workflowRuns'),
+        actionRuns: read('actionRuns')
+    };
+}
+/**
+ * `orgMonthlyCogsUsd` behind an explicit readiness flag (AGL-1134).
+ *
+ * The staff org page loads its rollup asynchronously, and an unfinished read
+ * and an absent document are the same `undefined`. Priced directly, both
+ * yield `basis: 'floor'` — so the enterprise pricing card printed "per-site
+ * floor — no usage recorded yet" during the loading window, a
+ * measurement-shaped sentence about an org whose measurements had simply not
+ * arrived. That is the AGL-1380 / AGL-1422 defect exactly: a question
+ * answered before its data is ready, and answered in the cheap direction.
+ *
+ * Returning a discriminated union rather than a nullable number is what makes
+ * the window unrepresentable — a caller cannot reach a cost without first
+ * handling `pending`, so the next call site cannot re-introduce this by
+ * forgetting a flag it was handed.
+ */ export function orgCogsPreview(ready, rollup, siteCount) {
+    // Gated on the caller's flag alone. Deriving readiness from `rollup` being
+    // truthy would re-create the bug: the org with no rollup yet is precisely
+    // the one whose value stays falsy after the read completes.
+    if (!ready) return {
+        status: 'pending'
+    };
+    return {
+        status: 'ready',
+        cogs: orgMonthlyCogsUsd(rollup, siteCount)
+    };
+}
+/**
+ * Where a cost figure came from, in a sentence a staff member can act on
+ * (AGL-1930).
+ *
+ * The staff quote card said `per-site floor — no usage recorded yet` for
+ * EVERY `basis: 'floor'` org. Measured against production 2026-08-24 that
+ * sentence is false on most of them: all 14 usage rollups across all 6 orgs
+ * price under the floor, and 9 of the 14 carry genuinely non-zero usage — the
+ * largest real org measured **$0.22** against its $2.00 floor. "No usage
+ * recorded" and "usage recorded, and it came in under the floor" are opposite
+ * facts about the cost model, and only the second one is evidence the meters
+ * are working at all.
+ *
+ * Same failure family as AGL-1380 / AGL-1422 — a measurement-shaped sentence
+ * printed over a measurement that was never consulted — one layer further in:
+ * here the measurement exists and the copy denies it.
+ */ export function orgCogsBasisSummary(cogs, month) {
+    const when = month != null ? month : 'the latest';
+    if (cogs.basis === 'measured') return `measured from ${when} usage`;
+    // Absent and zero are NOT the same claim, and with `strictNullChecks` off an
+    // absent meter reads as 0 all the way down — so this leans on the caller's
+    // `orgCogsPreview` readiness gate for "has a rollup arrived", and reports
+    // only what the priced total says.
+    if (!(cogs.measuredUsd > 0)) return 'per-site floor — no usage recorded yet';
+    // Cents are the wrong precision for these figures and rounding to them
+    // prints `$0.00`, which reads as the "no usage" claim this function exists
+    // to stop making. Every real org's measured month is under a cent.
+    const measured = cogs.measuredUsd < 0.01 ? cogs.measuredUsd.toFixed(4) : cogs.measuredUsd.toFixed(2);
+    return `per-site floor — ${when} usage measured ` + `$${measured}, under the $${cogs.floorUsd.toFixed(2)} floor`;
+}
+/**
+ * Percent-off at or above which creating a coupon needs explicit staff
+ * sign-off (AGL-1105). A ≥40%-off coupon is a real revenue commitment, so the
+ * creation route rejects it unless the caller passes a confirm flag; the UI
+ * surfaces a checkbox at this threshold.
+ */ export const DISCOUNT_APPROVAL_THRESHOLD_PCT = 40;
+/**
+ * Discount DEPTH bands (AGL-1120) — how much of list price is being given
+ * away, which is a different question from whether the remainder covers
+ * infrastructure.
+ *
+ * The original guardrail asked only the second question, so a **93% off**
+ * coupon rated "OK — net margin 78.1% vs a 75% floor": $9.15 left against $2
+ * of infra really is a 78% contribution margin. The ratio is scale-invariant,
+ * so as long as the leftover dwarfs $2 the verdict stays green no matter how
+ * little is left. Depth never entered the verdict at all.
+ *
+ * Warn at the threshold that already requires sign-off, so the badge and the
+ * approval checkbox stop disagreeing with each other; block at 70%, where a
+ * deal is being given away rather than discounted.
+ */ export const DISCOUNT_DEPTH_WARN_PCT = DISCOUNT_APPROVAL_THRESHOLD_PCT;
+export const DISCOUNT_DEPTH_BLOCK_PCT = 70;
+/** How many sites (hosts) the org runs — at least 1 for a billing org. */ export function orgSiteCount(org) {
+    var _ref;
+    return Math.max(1, Object.keys((_ref = org == null ? void 0 : org.hosts) != null ? _ref : {}).length);
+}
+/**
+ * Rate a proposed discount (AGL-1105, re-shaped in AGL-1120) — the guardrail
+ * behind staff coupon creation and per-org application.
+ *
+ * Two independent questions, and the verdict is the WORSE of them:
+ *
+ *  1. **How deep is it?** `depthPct` against `DISCOUNT_DEPTH_WARN_PCT` /
+ *     `DISCOUNT_DEPTH_BLOCK_PCT`. This is the one that was missing. Cost
+ *     recovery alone is scale-invariant — 93% off $139 leaves $9.15 against
+ *     $2 of infra, a genuine 78% contribution margin — so the old verdict
+ *     rated a give-away "OK" and only warned at 94%.
+ *  2. **Does the remainder cover the cost of serving them?** `marginPct`
+ *     against `NET_MARGIN_FLOOR_PCT`, with `NET_MARGIN_WARN_BAND_PCT` below
+ *     it, and an automatic block once the discount drives net ≤ 0.
+ *
+ * Neither subsumes the other: a shallow discount on an org running twenty
+ * sites can still fail cost recovery, and a deep one on a cheap org can still
+ * clear it. `reason` reports which test bound, so the UI never shows a
+ * healthy-looking margin beside a red badge without explanation.
+ *
+ * `discount` is the PROPOSED change, independent of any discount already on
+ * the org — `grossUsd` is always the list price (`orgListPriceMonthlyUsd`),
+ * so this never double-counts an existing `org.discount`. A non-billing org
+ * (list price 0) has no revenue to protect and rates `ok`.
+ */ export function checkDiscountMargin(org, discount, options = {}) {
+    var _options_measuredCogsUsd;
+    var _org_subscription;
+    const floorPct = NET_MARGIN_FLOOR_PCT;
+    const grossUsd = orgListPriceMonthlyUsd(org);
+    const flatCogsUsd = Math.round(INFRA_COGS_PER_SITE_USD * orgSiteCount(org) * 100) / 100;
+    // Measured cost wins only when it EXCEEDS the flat estimate. A rollup that
+    // has not run yet reads as a low number, and a guardrail that got looser
+    // because the meter was behind would fail in the one direction that costs
+    // money.
+    const measured = Number((_options_measuredCogsUsd = options.measuredCogsUsd) != null ? _options_measuredCogsUsd : 0);
+    const cogsMeasured = Number.isFinite(measured) && measured > flatCogsUsd;
+    const infraCogsUsd = cogsMeasured ? Math.round(measured * 100) / 100 : flatCogsUsd;
+    if (grossUsd <= 0) {
+        return {
+            grossUsd: 0,
+            discountedUsd: 0,
+            netUsd: 0,
+            infraCogsUsd,
+            cogsMeasured,
+            marginPct: 1,
+            depthPct: 0,
+            rating: 'ok',
+            reason: 'none',
+            floorPct
+        };
+    }
+    const discountedUsd = applyDiscountUsd(grossUsd, discount);
+    const annual = (org == null ? void 0 : (_org_subscription = org.subscription) == null ? void 0 : _org_subscription.interval) === 'year';
+    const netUsd = netOfProcessorFee(discountedUsd, annual);
+    const depthPct = Math.round((grossUsd - discountedUsd) / grossUsd * 10000) / 10000;
+    const marginPct = netUsd > 0 ? Math.round((netUsd - infraCogsUsd) / netUsd * 10000) / 10000 : -1;
+    const depthRating = depthPct * 100 >= DISCOUNT_DEPTH_BLOCK_PCT ? 'block' : depthPct * 100 >= DISCOUNT_DEPTH_WARN_PCT ? 'warn' : 'ok';
+    // Same bands the staff quote card renders — one reader for the two
+    // constants (AGL-1930), so a re-tune cannot reach the guardrail and miss
+    // the UI.
+    const cogsRating = netMarginRating(marginPct);
+    const severity = {
+        ok: 0,
+        warn: 1,
+        block: 2
+    };
+    const rating = severity[depthRating] >= severity[cogsRating] ? depthRating : cogsRating;
+    const reason = rating === 'ok' ? 'none' : netUsd <= 0 ? 'underwater' : severity[depthRating] >= severity[cogsRating] ? 'depth' : 'cogs';
+    return {
+        grossUsd,
+        discountedUsd,
+        netUsd,
+        infraCogsUsd,
+        cogsMeasured,
+        marginPct,
+        depthPct,
+        rating,
+        reason,
+        floorPct
+    };
+}
+/**
+ * The plan the org actually gets (AGL-247): missing/unknown plans resolve
+ * as `free`, and a paid plan whose subscription is canceled/unpaid/
+ * incomplete downgrades to `free` until the webhook restores it — plan
+ * fields alone are not entitlement.
+ *
+ * A STAFF COMP comes first (AGL-3034), and only where no subscription decides
+ * the plan: `resolvePlanComp` answers `null` while one is live, so a paying
+ * workspace's plan is always its subscription's. The comp is its own marker,
+ * never the stored `plan` — a canceled customer whose `plan` still names what
+ * they paid for resolves as Free exactly as before, because nothing about
+ * their document is a comp.
+ */ export function resolveEffectivePlan(org) {
+    const comp = resolvePlanComp(org);
+    if (comp) return comp.plan;
+    const plan = org == null ? void 0 : org.plan;
+    if (!plan || !(plan in PLAN_ENTITLEMENTS)) return 'free';
+    const status = subscriptionStatusOf(org);
+    if (plan !== 'free' && status && DEAD_SUBSCRIPTION_STATUSES.has(status)) {
+        return 'free';
+    }
+    return plan;
+}
+function resolvePlan(org) {
+    return resolveEffectivePlan(org);
+}
+/**
+ * Purchased add-on quantities that currently apply (AGL-524): add-ons
+ * bill as items on the org's Stripe subscription, so a dead subscription
+ * (the `resolveEffectivePlan` set) stops them counting until the webhook
+ * restores it. Orgs with no subscription state keep staff-set quantities
+ * (comped add-ons predating self-serve billing).
+ */ function resolvePurchasedAddons(org) {
+    var _ref;
+    const status = subscriptionStatusOf(org);
+    if (status && DEAD_SUBSCRIPTION_STATUSES.has(status)) return {};
+    return (_ref = org == null ? void 0 : org.seatAddons) != null ? _ref : {};
+}
+/**
+ * Whether the org's Aglyn AI add-on currently applies (AGL-2896): bought,
+ * and on a subscription that is still paying for it. The ONE reading of
+ * `seatAddons.aiAddon` — the entitlement fold and the assist overage rate
+ * both ask this, so a dead subscription drops the band and the rate
+ * together rather than leaving a rate on a band that has gone.
+ */ export function hasAiAddon(org) {
+    return aiAddonUnits(resolvePurchasedAddons(org)) === 1;
+}
+/**
+ * Numeric entitlement keys that were REMOVED from `PLAN_ENTITLEMENTS` and
+ * must never be resolved again from a stored override (AGL-2133).
+ *
+ * `totalSiteSizeMb` is the first. It carried a value on all 8 plans and was
+ * enforced by nothing — no gate, no meter, no alert. AGL-1107 added it and
+ * AGL-1370 deleted its meter and its alert on measurement rather than taste:
+ * `measure-node-map.ts` refuses any node map over 900 KB (AGL-678), so the
+ * measurable org total tops out at 2.3–20.9% of the cap depending on plan.
+ * What survived was a WRITABLE staff override field for a number nothing
+ * read, so a support engineer resolving a "this site is too big" ticket
+ * raised it, got a success and an audit row, and changed nothing.
+ *
+ * WIRING IT WAS THE OTHER OPTION AND IT IS WORSE. A cap the measurement can
+ * reach a fifth of is a gate that refuses nobody — the same "reports success,
+ * does nothing" shape, moved from the staff dialog to the enforcement point,
+ * plus a new hard wall introduced days before launch. The per-site size
+ * ceiling that actually binds is AGL-678's 900 KB node map, and it is real.
+ *
+ * The rollup's `siteSizeMb` MEASUREMENT stays — host-usage and the usage
+ * audit read it, and it is a genuine internal signal. Only the entitlement
+ * goes.
+ */ export const RETIRED_ENTITLEMENT_KEYS = new Set([
+    'totalSiteSizeMb'
+]);
+/**
+ * The numeric entitlements that are PRICES rather than caps (AGL-3049): the
+ * platform's percentage of a storefront or marketplace sale.
+ *
+ * Every other numeric key is a band — a count, a size, a monthly or daily
+ * allowance — and an uncapped comp lifts it to `UNLIMITED`. These three it
+ * must never touch. `transactionFee*Pct` becomes Stripe's
+ * `application_fee_amount` at checkout, so an unlimited one is a fee larger
+ * than the charge and every sale on the storefront fails; and "no cap" has
+ * no meaning for a price in the first place. An uncapped workspace pays its
+ * plan's percentages, or whatever a per-org override sets them to.
+ *
+ * Named rather than derived from the `Pct` suffix, so a new numeric key is a
+ * band unless someone decides here that it is a price. `plan-comp.spec.ts`
+ * pins these three by name and proves every other numeric key is lifted.
+ */ export const PRICE_ENTITLEMENT_KEYS = new Set([
+    'transactionFeePhysicalPct',
+    'transactionFeeDigitalPct',
+    'marketplaceFeePct'
+]);
+/**
+ * The entitlements with every band lifted (AGL-3049): `UNLIMITED` on each
+ * numeric key but the prices, features untouched. What an uncapped comp in
+ * force resolves to — see `isUncappedPlanComp`.
+ *
+ * Applied LAST, over the plan row, the per-org overrides and the folded
+ * add-ons alike: "every band reads as unlimited" means an override written
+ * before the comp was uncapped does not quietly cap it again. The overrides
+ * stay stored, and apply once more if the comp is capped or removed.
+ */ function withEveryCapLifted(entitlements) {
+    const lifted = _extends({}, entitlements);
+    for (const [key, value] of Object.entries(entitlements)){
+        if (typeof value === 'number' && !PRICE_ENTITLEMENT_KEYS.has(key)) {
+            lifted[key] = UNLIMITED;
+        }
+    }
+    return lifted;
+}
+/**
+ * Effective entitlements for an org: plan defaults with the org doc's
+ * per-key overrides applied (features merge key-by-key too), then
+ * purchased add-ons stacked on top (AGL-524): `seatAddons.hosts` raises
+ * `hostLimit`, `seatAddons.eventCalendar` switches the `eventCalendar`
+ * feature on, and every seat add-on a plugin declared through
+ * `registerPluginEntitlements` (AGL-2940) widens the quota it names by its
+ * per-plan figure per unit and switches its features on — the Aglyn AI
+ * add-on (AGL-2896) is the first such declaration. (Seat/dataset add-ons
+ * instead fold in at `checkSeatQuota` / `checkDatasetQuota`, where the
+ * per-plan hard max clamps them.)
+ * Missing or unknown plans resolve as `free`.
+ *
+ * EVERY NUMERIC KEY of `OrgEntitlements` is an override axis, not a chosen
+ * few: the loop below copies any number it finds under the org's
+ * `entitlements`, so a contracted `bandwidthGb`, `apiRequestsPerMonth` or
+ * `workflowRunsPerMonth` resolves ahead of the plan default exactly as the
+ * long-documented `emailSendsPerMonth`, `formsPerHost` and
+ * `assistCreditsPerMonth` overrides do. Since 2026-09-07 this is what makes
+ * Enterprise's finite fallbacks safe to hold: the row in `PLAN_ENTITLEMENTS`
+ * is what an agreement gets before its numbers are written down, and the
+ * override is where they are written. `plan-entitlements.spec.ts` proves
+ * the precedence on every axis, so a resolver that started honoring a list
+ * would fail by the name of the axis it dropped.
+ *
+ * `hostLimit` is DELIBERATELY unclamped here (AGL-1738): there is no
+ * `maxHostsPerOrg` to clamp against, because extra sites are sold flat rather
+ * than up to a band. Their bound is the purchase ceiling,
+ * `EXTRA_HOSTS_ADDON_MAX`, and a band-shaped `Math.min` added here would
+ * silently disable sites the org is invoiced for. See that constant before
+ * "fixing" this add.
+ *
+ * `posRegisters` IS NOT ADDED HERE, and this is the fix, not an omission
+ * (AGL-1775). The register add-on is priced "per
+ * extra register/location" and enforced PER SITE, so folding the org-wide
+ * purchase into an org-level value every site inherits sold one register and
+ * delivered `hostLimit` of them. `seatAddons.posRegisters` is now a POOL and
+ * `org.registerAllocations` says which site holds each seat. The number this
+ * function returns for `posRegisters` is therefore **the plan's cap alone** —
+ * exactly what an unallocated site must resolve to. Per-site capacity comes
+ * from `resolveHostRegisterCap(org, hostId)`; nothing else may add the pool
+ * back in.
+ *
+ * (`eventCalendar` is still org-wide on purpose: it is documented and priced
+ * as "one purchase covers every host in the org". The register add-on never
+ * was, which is the whole difference.)
+ *
+ * AN UNCAPPED COMP IN FORCE (AGL-3049) resolves every band as `UNLIMITED`
+ * on top of all of the above — `withEveryCapLifted` — and leaves the
+ * features and the fee percentages exactly as resolved.
+ */ export function resolveOrgEntitlements(org) {
+    const resolved = resolveCappedOrgEntitlements(org);
+    return isUncappedPlanComp(org) ? withEveryCapLifted(resolved) : resolved;
+}
+/** `resolveOrgEntitlements` before an uncapped comp lifts anything. */ function resolveCappedOrgEntitlements(org) {
+    var _purchased_hosts, _purchased_eventCalendar;
+    const defaults = withPluginFeatureDefaults(PLAN_ENTITLEMENTS[resolvePlan(org)], resolvePlan(org));
+    const overrides = org == null ? void 0 : org.entitlements;
+    let resolved = defaults;
+    if (overrides) {
+        const { features: featureOverrides, datasetsPerHost: legacyDatasets, maxDatasetsPerHost: legacyMaxDatasets } = overrides, quotaOverrides = _object_without_properties_loose(overrides, [
+            "features",
+            "datasetsPerHost",
+            "maxDatasetsPerHost"
+        ]);
+        const merged = _extends({}, defaults);
+        for (const [key, value] of Object.entries(quotaOverrides)){
+            // A RETIRED quota's stored override is dropped, not merged (AGL-2133).
+            // This loop copies any numeric key it finds, so removing a key from
+            // `PLAN_ENTITLEMENTS` alone would leave the value that staff already
+            // wrote onto live org documents still appearing on the resolved
+            // entitlements — a number with no default behind it and no reader in
+            // front of it, which is a worse artefact than the field that produced
+            // it. `tools/scripts/strip-retired-entitlements.mjs` clears them from
+            // Firestore; this makes the resolver correct before it has run, and
+            // stays correct if a document is restored from an old backup.
+            if (RETIRED_ENTITLEMENT_KEYS.has(key)) continue;
+            if (typeof value === 'number') merged[key] = value;
+        }
+        // Pre-AGL-240 override docs keyed datasets per host; resolve them into
+        // the org keys unless an org-keyed override is present.
+        if (typeof legacyDatasets === 'number' && overrides.datasetsPerOrg == null) {
+            merged.datasetsPerOrg = legacyDatasets;
+        }
+        if (typeof legacyMaxDatasets === 'number' && overrides.maxDatasetsPerOrg == null) {
+            merged.maxDatasetsPerOrg = legacyMaxDatasets;
+        }
+        resolved = _extends({}, merged, {
+            features: _extends({}, defaults.features, featureOverrides)
+        });
+    }
+    const purchased = resolvePurchasedAddons(org);
+    const extraHosts = Math.max(0, (_purchased_hosts = purchased.hosts) != null ? _purchased_hosts : 0);
+    const eventCalendar = ((_purchased_eventCalendar = purchased.eventCalendar) != null ? _purchased_eventCalendar : 0) >= 1;
+    // A declared add-on's quota is added AFTER the per-org override, so a
+    // contracted figure and a purchased add-on stack the way a raised
+    // `hostLimit` and purchased sites do. The per-unit figure is the PLAN's,
+    // read off the effective plan rather than the stored one, so a dead
+    // subscription that resolved to free adds free's figure.
+    const folded = foldPluginSeatAddons(resolved, purchased, resolvePlan(org));
+    if (!extraHosts && !eventCalendar && folded === resolved) return resolved;
+    return _extends({}, folded, {
+        hostLimit: folded.hostLimit + extraHosts,
+        features: _extends({}, folded.features, eventCalendar ? {
+            eventCalendar: true
+        } : {})
+    });
+}
+/**
+ * How many units of a plugin-declared seat add-on a purchase map counts as
+ * (AGL-2940): the stored quantity, capped at the declaration's `maxUnits`
+ * — 1 for an org-wide add-on, where a doubled webhook item or a hand edit
+ * above one is still one purchase. A non-number, `NaN`, a negative, or a
+ * key nothing declared is none.
+ */ export function pluginSeatAddonUnits(addons, key) {
+    var _ref;
+    const declared = pluginSeatAddon(key);
+    if (!declared) return 0;
+    const quantity = Number((_ref = addons == null ? void 0 : addons[key]) != null ? _ref : 0);
+    if (!Number.isFinite(quantity) || quantity < 1) return 0;
+    const units = Math.floor(quantity);
+    return declared.maxUnits != null ? Math.min(units, declared.maxUnits) : units;
+}
+/**
+ * Whether a plugin-declared seat add-on currently applies to the org: bought,
+ * and on a subscription that is still paying for it — the one reading every
+ * surface that shows or charges for the add-on goes through, so a dead
+ * subscription drops the quota and the feature together.
+ */ export function hasPluginSeatAddon(org, key) {
+    return pluginSeatAddonUnits(resolvePurchasedAddons(org), key) > 0;
+}
+/**
+ * Every declared seat add-on the org holds, folded in catalog order: the
+ * quota each names gains its per-plan figure per unit, and its features
+ * switch on. Returns the input object untouched when nothing applies, so a
+ * caller can tell "nothing folded" from "folded to the same numbers".
+ */ function foldPluginSeatAddons(resolved, purchased, plan) {
+    let out = resolved;
+    for (const addon of listPluginSeatAddons()){
+        var _addon_features;
+        const units = pluginSeatAddonUnits(purchased, addon.key);
+        if (!units) continue;
+        const next = _extends({}, out, {
+            features: _extends({}, out.features)
+        });
+        if (addon.quota) {
+            var _addon_quota_perUnitByPlan_plan, _bag_addon_quota_key;
+            const perUnit = (_addon_quota_perUnitByPlan_plan = addon.quota.perUnitByPlan[plan]) != null ? _addon_quota_perUnitByPlan_plan : 0;
+            const bag = next;
+            const current = Number((_bag_addon_quota_key = bag[addon.quota.key]) != null ? _bag_addon_quota_key : 0);
+            bag[addon.quota.key] = (Number.isFinite(current) ? current : 0) + perUnit * units;
+        }
+        const features = next.features;
+        for (const feature of (_addon_features = addon.features) != null ? _addon_features : [])features[feature] = true;
+        out = next;
+    }
+    return out;
+}
+/**
+ * The plan row with every plugin-declared feature's default filled in
+ * (AGL-2940). A feature the plan tables already carry keeps the table's
+ * answer; a feature only a declaration knows reads its `defaultByPlan`, or
+ * `false`. Returns the row itself when no declaration adds anything.
+ */ function withPluginFeatureDefaults(row, plan) {
+    const features = row.features;
+    let out;
+    for (const declared of listPluginFeatures()){
+        var _ref;
+        var _declared_defaultByPlan;
+        if (features[declared.key] !== undefined) continue;
+        out = out != null ? out : _extends({}, features);
+        out[declared.key] = (_ref = (_declared_defaultByPlan = declared.defaultByPlan) == null ? void 0 : _declared_defaultByPlan[plan]) != null ? _ref : false;
+    }
+    return out ? _extends({}, row, {
+        features: out
+    }) : row;
+}
+/**
+ * The org's POS register pool (AGL-1775): how many seats were purchased, how
+ * many are assigned to a site, and how many are left to assign.
+ *
+ * `purchased` runs through `resolvePurchasedAddons`, so a dead subscription
+ * empties the pool exactly as it empties every other add-on — the seats stop
+ * counting when they stop billing.
+ *
+ * `byHost` is the SANITISED allocation, and it never sums past `purchased`.
+ * The write path validates before it stores, so an over-allocated map means
+ * the data is stale or corrupt (a purchase reduced without the allocation
+ * being trimmed, a partial write, a hand edit). Both directions of getting
+ * that wrong cost money, so it is resolved rather than trusted: hosts are
+ * walked in sorted-id order and granted what remains of the pool, which is
+ * deterministic — the same host gets the same answer on every reader — and
+ * cannot hand out capacity nobody paid for.
+ *
+ * Every value is coerced: a non-number, `NaN`, `Infinity` or a negative reads
+ * as zero seats. An `Infinity` in this map would otherwise become an
+ * unbounded per-site register cap, which is the one outcome the guard in
+ * `resolveHostRegisterCap` exists to make impossible.
+ */ export function resolveRegisterSeatPool(org) {
+    const rawPurchased = resolvePurchasedAddons(org).posRegisters;
+    const purchased = Number.isFinite(rawPurchased) && rawPurchased > 0 ? Math.floor(rawPurchased) : 0;
+    const raw = org == null ? void 0 : org.registerAllocations;
+    const byHost = {};
+    let allocated = 0;
+    if (raw && typeof raw === 'object') {
+        for (const hostId of Object.keys(raw).sort()){
+            if (allocated >= purchased) break;
+            const value = Number(raw[hostId]);
+            if (!Number.isFinite(value) || value <= 0) continue;
+            const seats = Math.min(Math.floor(value), purchased - allocated);
+            if (seats <= 0) continue;
+            byHost[hostId] = seats;
+            allocated += seats;
+        }
+    }
+    return {
+        purchased,
+        allocated,
+        available: purchased - allocated,
+        byHost
+    };
+}
+/**
+ * How many POS registers one SITE may run (AGL-1775): the plan's per-site cap
+ * plus whatever the org has assigned to that site out of the pool.
+ *
+ * THE GUARD, and the reason this is a function rather than a lookup. An
+ * unallocated host — no entry in `registerAllocations`, a missing map, a
+ * missing org, an org still loading — resolves to `resolveOrgEntitlements(org)
+ * .posRegisters`, which since AGL-1775 is the PLAN's cap and nothing else.
+ * Never the pooled total, and never `Infinity` unless the plan itself is
+ * `UNLIMITED` (enterprise, where an unbounded cap is what was sold).
+ *
+ * `checkQuota(undefined)` resolving to the Free tier is the lesson this
+ * inverts: an absent input there quietly answered a question in the
+ * PERMISSIVE direction on the day it mattered. Here the absent input answers
+ * in the direction of the plan, which is the conservative one — a site that
+ * has been assigned seats and whose allocation failed to load runs fewer
+ * registers than it paid for, which the console can say out loud, rather than
+ * more than it paid for, which nothing would ever notice.
+ *
+ * There is deliberately no separate read: the allocation lives on the org doc
+ * beside the entitlements, so a caller holding one holds the other.
+ */ export function resolveHostRegisterCap(org, hostId) {
+    var _resolveRegisterSeatPool_byHost_hostId;
+    const planCap = resolveOrgEntitlements(org).posRegisters;
+    if (!hostId) return planCap;
+    // An UNLIMITED plan cap plus anything is still UNLIMITED; short-circuit so
+    // `Infinity + n` never has to be reasoned about downstream.
+    if (planCap === UNLIMITED) return UNLIMITED;
+    return planCap + ((_resolveRegisterSeatPool_byHost_hostId = resolveRegisterSeatPool(org).byHost[hostId]) != null ? _resolveRegisterSeatPool_byHost_hostId : 0);
+}
+/**
+ * The org's COLLABORATOR seat pool (AGL-2439): how many per-site collaborator
+ * seats were purchased, how many are assigned to a site, and how many are
+ * left to assign.
+ *
+ * The AGL-1775 register mechanism, applied to the key it was never applied to.
+ * `seatAddons.members` is bought once, org-wide; `membersPerHost` is enforced
+ * PER SITE. Adding one to the other handed the whole purchase to every site,
+ * so an org with 20 sites that bought ONE extra collaborator seat received 20.
+ * The quantity is now the size of an org-level pool and
+ * `org.collaboratorAllocations` says which site holds each seat.
+ *
+ * Everything about the resolution is deliberately identical to
+ * `resolveRegisterSeatPool` — the same clamp, the same sorted-id determinism,
+ * the same coercion of a non-number / `NaN` / `Infinity` / negative to zero.
+ * This is ONE mechanism used twice, not a second mechanism that happens to
+ * rhyme: a reader who has understood the register pool has understood this,
+ * and a fix to one is a fix to both.
+ *
+ * `purchased` runs through `resolvePurchasedAddons`, so a dead subscription
+ * empties the pool exactly as it empties every other add-on.
+ */ export function resolveCollaboratorSeatPool(org) {
+    const rawPurchased = resolvePurchasedAddons(org).members;
+    const purchased = Number.isFinite(rawPurchased) && rawPurchased > 0 ? Math.floor(rawPurchased) : 0;
+    const raw = org == null ? void 0 : org.collaboratorAllocations;
+    const byHost = {};
+    let allocated = 0;
+    if (raw && typeof raw === 'object') {
+        for (const hostId of Object.keys(raw).sort()){
+            if (allocated >= purchased) break;
+            const value = Number(raw[hostId]);
+            if (!Number.isFinite(value) || value <= 0) continue;
+            const seats = Math.min(Math.floor(value), purchased - allocated);
+            if (seats <= 0) continue;
+            byHost[hostId] = seats;
+            allocated += seats;
+        }
+    }
+    return {
+        purchased,
+        allocated,
+        available: purchased - allocated,
+        byHost
+    };
+}
+/**
+ * How many console COLLABORATORS one SITE may hold (AGL-2439): the plan's
+ * per-site allowance plus whatever the org has assigned to that site out of
+ * the pool, clamped to the plan's hard `maxMembersPerHost`.
+ *
+ * THE GUARD, and the reason this is a function rather than a lookup. An
+ * unallocated host — no entry in `collaboratorAllocations`, a missing map, a
+ * missing org, an org still loading — resolves to the PLAN's `membersPerHost`
+ * and nothing else. Never the pooled total, and never `Infinity` unless the
+ * plan itself is `UNLIMITED` (enterprise, where an unbounded cap is what was
+ * sold). `checkQuota(undefined)` resolving to the Free tier is the lesson
+ * this inverts: the absent input answers in the direction of the plan, which
+ * is the conservative one.
+ *
+ * The clamp is what `checkSeatQuota` always did and is kept: collaborator
+ * seats are sold up to a BAND (`maxMembersPerHost`), unlike registers, which
+ * are sold flat. Assigning more pool seats to a site than the band allows
+ * cannot lift it past the band — the org must upgrade the plan.
+ *
+ * There is deliberately no separate read: the allocation lives on the org doc
+ * beside the entitlements, so a caller holding one holds the other.
+ */ export function resolveHostCollaboratorCap(org, hostId) {
+    var _resolveCollaboratorSeatPool_byHost_hostId;
+    const entitlements = resolveOrgEntitlements(org);
+    const included = entitlements.membersPerHost;
+    const maxSeats = entitlements.maxMembersPerHost;
+    if (!hostId) return Math.min(included, maxSeats);
+    // An UNLIMITED plan cap plus anything is still UNLIMITED; short-circuit so
+    // `Infinity + n` never has to be reasoned about downstream.
+    if (included === UNLIMITED) return UNLIMITED;
+    const assigned = (_resolveCollaboratorSeatPool_byHost_hostId = resolveCollaboratorSeatPool(org).byHost[hostId]) != null ? _resolveCollaboratorSeatPool_byHost_hostId : 0;
+    return Math.min(included + assigned, maxSeats);
+}
+/**
+ * Quota answer for a site's console COLLABORATORS (AGL-2439) — the
+ * host-scoped `checkSeatQuota`, in the same `SeatQuotaResult` shape so the
+ * existing call sites and refusal copy read identically.
+ *
+ * `checkSeatQuota(org, 'members', …)` is WRONG for a site now and this exists
+ * so nobody has to remember why: since AGL-2439 that helper no longer folds
+ * the org-wide purchase into a per-site number, so it answers the PLAN's cap
+ * and would refuse a site the seats it holds.
+ *
+ * ## THE GRANDFATHER BOUNDARY — explicit, and this field is it
+ *
+ * The cap is corrected, and no org already above it is evicted or locked
+ * out.
+ *
+ * The boundary is drawn between two different questions, and they are
+ * different lines of code rather than one number used for two purposes:
+ *
+ *   `allowed`           — may this site take on ANOTHER collaborator? Bound
+ *                         by `limit`, the corrected cap. This is the ONLY
+ *                         thing the cap decides.
+ *   `retainedOverCap`   — how many seats this site holds ABOVE `limit`. They
+ *                         are RETAINED. Nothing in this repo revokes a
+ *                         collaborator for being over a cap, and nothing may
+ *                         be added that does: the cap binds ALLOCATION, never
+ *                         ACCESS.
+ *
+ * So an over-cap site keeps every collaborator it has, cannot add another,
+ * and returns to normal by attrition, by buying pool seats and assigning them
+ * here, or by upgrading — at which point `limit` recomputes from the new plan
+ * or allocation and the retention lapses on its own. That is what "they keep
+ * what they have until they next change plan or seat count" means, resolved
+ * rather than stored: a stored floor would need a backfill over live orgs and
+ * would be a defaulted field on a `merge`-written document, which is the
+ * converter hazard that destroys the real value it was meant to protect.
+ *
+ * `retainedOverCap` is non-zero ONLY when the site is already over. It is not
+ * headroom and cannot be spent: it is a count the console says out loud so
+ * the customer sees why the next Add is refused while nobody loses access.
+ */ export function checkHostCollaboratorQuota(org, hostId, currentUsage) {
+    var _resolveCollaboratorSeatPool_byHost_;
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const included = entitlements.membersPerHost;
+    const maxSeats = entitlements.maxMembersPerHost;
+    const addonPriceUsd = pricing.extraCollaboratorMonthlyUsd;
+    const assignedSeats = (_resolveCollaboratorSeatPool_byHost_ = resolveCollaboratorSeatPool(org).byHost[hostId != null ? hostId : '']) != null ? _resolveCollaboratorSeatPool_byHost_ : 0;
+    const limit = resolveHostCollaboratorCap(org, hostId);
+    return {
+        allowed: currentUsage < limit,
+        limit,
+        remaining: Math.max(0, limit - currentUsage),
+        included,
+        purchased: assignedSeats,
+        maxSeats,
+        upgradeRequired: addonPriceUsd === null || limit >= maxSeats,
+        addonPriceUsd,
+        // THE GRANDFATHER. `Math.max(0, …)` so a site under its cap reports zero
+        // rather than a negative that a caller could add and turn into headroom.
+        retainedOverCap: Math.max(0, currentUsage - limit),
+        assignedSeats
+    };
+}
+/**
+ * Quota answer for a site's POS registers (AGL-1775) — the register-shaped
+ * `checkQuota`, in the same `{ allowed, limit, remaining }` shape so callers
+ * read identically.
+ *
+ * `checkQuota(org, 'posRegisters', used)` is WRONG for registers now and this
+ * exists so nobody has to remember why: that helper resolves the org-level
+ * value, which is the plan cap with no pool in it, so it would refuse a site
+ * the seats it holds. Everything that gates a register creation calls this.
+ */ export function checkHostRegisterQuota(org, hostId, currentUsage) {
+    const limit = resolveHostRegisterCap(org, hostId);
+    return {
+        allowed: currentUsage < limit,
+        limit,
+        remaining: Math.max(0, limit - currentUsage)
+    };
+}
+/**
+ * Platform transaction fee % for a storefront sale (AGL-278): resolved
+ * from the effective plan (with per-org overrides) by product type.
+ * Digital and service sales use the digital rate; AGL-307 turns this into
+ * the Stripe Connect `application_fee_amount` at charge time.
+ */ export function resolveTransactionFeePct(org, productType) {
+    var _org_entitlements;
+    const entitlements = resolveOrgEntitlements(org);
+    const key = productType === 'physical' ? 'transactionFeePhysicalPct' : 'transactionFeeDigitalPct';
+    // A MALFORMED value falls back to the PLAN'S OWN rate, never to zero
+    // (AGL-2114). `resolveOrgEntitlements` merges any numeric override
+    // indistinguishably from the default, and `strictNullChecks` is off
+    // repo-wide, so a `NaN`, an `Infinity`, a stringly-typed number or a
+    // negative can reach here from a hand-edited or partially-written org doc.
+    // This used to answer 0 for every one of them — silently zeroing the
+    // platform's cut on a PAYING merchant's storefront, which on a destination
+    // charge is not "no take rate" but a loss (see below).
+    //
+    // The sibling `resolveMarketplaceFeePct` has forbidden exactly this since
+    // AGL-1543, in as many words: "A malformed override must never zero the
+    // platform's cut." This is the storefront half of the same rule. The plan
+    // table is a literal and cannot itself be malformed, so it is the honest
+    // floor — and it preserves the tiers whose 0% is a DELIBERATE, advertised
+    // rate rather than a data fault.
+    const raw = entitlements[key];
+    const pct = typeof raw === 'number' && Number.isFinite(raw) && raw >= 0 ? raw : PLAN_ENTITLEMENTS[resolvePlan(org)][key];
+    if (Number.isFinite(pct) && pct > 0) return pct;
+    // The free plan's 0% prices a plan that CANNOT SELL: `features.commerce` is
+    // false there, so on an ordinary free org this rate is never consulted. It
+    // IS consulted for the one org shape that can reach a storefront on the free
+    // entitlement set — a per-org `features.commerce` override — and 0% on a
+    // DESTINATION charge is not "no take rate", it is a loss: Stripe's
+    // processing fee (2.9% + 30¢) and any $15 dispute fee are debited from the
+    // PLATFORM's balance, so every sale costs Aglyn money (AGL-2071).
+    //
+    // `marketplaceFeePct: 30` on the free row is the same decision already made
+    // for marketplace selling, and its comment says so in as many words: the
+    // rate exists to price "an org GRANTED selling via a per-org feature
+    // override". This is the missing equivalent for storefront sales, expressed
+    // here rather than in the table because the plan CARDS render the table —
+    // `billing-plan-cards.component.tsx:444` — and a Free card advertising a
+    // transaction fee for selling it does not permit would be a pricing lie.
+    //
+    // A staff fee override wins even at 0: `resolveOrgEntitlements` merges any
+    // numeric override indistinguishably from the default, so the raw doc is
+    // what separates "nobody set a rate" from a deliberately comped one. That
+    // decision has a name and a reason attached (`org-override-reason.ts`), and
+    // this floor must not silently overrule it.
+    if (resolvePlan(org) === 'free' && entitlements.features.commerce && typeof (org == null ? void 0 : (_org_entitlements = org.entitlements) == null ? void 0 : _org_entitlements[key]) !== 'number') {
+        return PLAN_ENTITLEMENTS.starter[key];
+    }
+    return 0;
+}
+/**
+ * Stripe's processing cost on ONE storefront destination charge, in cents
+ * (AGL-2152) — the dearest enabled method's percentage plus the fixed 30¢,
+ * rounded UP on the percentage so the answer is never a cent short of what
+ * Stripe actually debits.
+ *
+ * WHO PAYS THIS. Every storefront charge is a DESTINATION charge:
+ * `payment_intent_data[transfer_data][destination]` names the merchant's
+ * connected account and no `transfer_data[amount]` is sent, so Stripe moves
+ * the whole charge to the merchant and debits its processing fee from the
+ * PLATFORM's balance. Aglyn's net on an order is therefore
+ *
+ *     application_fee_amount − (processing% × charge + 30¢)
+ *
+ * and with `application_fee_amount` at 0 — which is what
+ * `transactionFeePhysicalPct: 0` produced on Pro, Business, Scale, Advanced,
+ * Agency and Enterprise — that net is NEGATIVE on every single sale. A flat
+ * percentage cannot repair it either: Starter's 2% is below even the cheapest
+ * processing rate, so Starter lost money at every order size too, and any rate
+ * above it still loses until the order clears `30¢ ÷ (take − processing)`. The
+ * fixed 30¢ is why a percentage alone can never reach break-even on small
+ * orders, and why this returns a CENTS amount rather than a rate.
+ *
+ * WHY THE DEAREST METHOD AND NOT 2.9%. The shopper picks how to pay AFTER the
+ * session is created, and `application_fee_amount` is a fixed number Stripe
+ * will not let us revise once the charge settles. No storefront path pins
+ * `payment_method_types`, so the platform's payment method configuration
+ * decides the set — and per AGL-2343 that configuration has `klarna` and
+ * `affirm` on beside the card family. Pricing this at the card rate would be
+ * wrong exactly on the orders where it cost the most, which is the same
+ * reasoning `marketplaceBreakEvenUsd` already applies to the listing floor;
+ * these are deliberately the SAME two constants so the two cannot drift.
+ *
+ * THE ONE-LINE LEVER. On a card-family order this over-recovers by the spread
+ * between the two rates. Pinning `payment_method_types` on the storefront
+ * sessions to the card family would make 2.9% the true binding rate, and
+ * `STOREFRONT_PROCESSING_PERCENT` below is then the single identifier to
+ * repoint. That is a product decision about which payment methods a storefront
+ * offers, not this one; it is recorded on AGL-2152 and in the Pricing Decision
+ * Log so it can be taken deliberately.
+ */ // `STOREFRONT_PROCESSING_PERCENT` and `STOREFRONT_PROCESSING_FIXED_CENTS` are
+// declared beside the marketplace processing constants they are defined from,
+// further down this file — a `const` cannot be read before its declaration is
+// evaluated, and this function is only ever CALLED, never evaluated at import.
+export function storefrontProcessingCostCents(chargeCents) {
+    if (!Number.isFinite(chargeCents) || chargeCents <= 0) return 0;
+    return Math.ceil(chargeCents * STOREFRONT_PROCESSING_PERCENT / 100) + STOREFRONT_PROCESSING_FIXED_CENTS;
+}
+/**
+ * The Stripe Connect `application_fee_amount` for ONE storefront sale
+ * (AGL-2152) — the platform's advertised take PLUS Stripe's processing cost,
+ * passed through at cost.
+ *
+ *     fee = take%(feeBaseCents) + processing%(chargeCents) + 30¢
+ *
+ * so Aglyn's net per order is AT LEAST the advertised take, at every order
+ * size down to Stripe's own 50¢ charge minimum, and never negative. The
+ * September-1 price lock was lifted for this one change; see the Pricing
+ * Decision Log entry of 2026-08-19. No advertised PLATFORM rate moved — a 0% tier is still 0%
+ * platform take — what changed is that the card cost stops being absorbed
+ * silently by Aglyn.
+ *
+ * `feeBaseCents` is the GOODS the take is a cut of (discounts already applied,
+ * tax and shipping excluded — that has always been the basis, AGL-2317).
+ * `chargeCents` is what Stripe will actually run the card for, which is goods
+ * + tax + shipping, and defaults to `feeBaseCents` for the paths where they
+ * are the same number. Passing the goods figure for a charge that also carries
+ * tax would under-recover by the processing rate on the difference.
+ *
+ * Clamped to `chargeCents` because Stripe rejects an application fee larger
+ * than the charge. That clamp can only bind below ~32¢, under Stripe's own 50¢
+ * charge minimum, so it never trims a real order's fee.
+ */ export function resolveTransactionFeeCents(org, productType, feeBaseCents, chargeCents = feeBaseCents) {
+    const charge = Number.isFinite(chargeCents) && chargeCents > 0 ? Math.round(chargeCents) : 0;
+    if (charge <= 0) return 0;
+    const base = Number.isFinite(feeBaseCents) && feeBaseCents > 0 ? Math.round(feeBaseCents) : 0;
+    const pct = resolveTransactionFeePct(org, productType);
+    // The `Math.max(1, …)` every door already applied: a rate above zero on
+    // goods the shopper pays for is a fee however small it rounds to.
+    const take = pct > 0 && base > 0 ? Math.max(1, Math.round(base * pct / 100)) : 0;
+    return Math.min(charge, take + storefrontProcessingCostCents(charge));
+}
+/**
+ * Stripe's processing cost on a RECURRING charge of `amountCents`, as the
+ * percent a Subscription's `application_fee_percent` can carry (AGL-2655).
+ *
+ * A Stripe Subscription accepts no `application_fee_amount` — only
+ * `application_fee_percent`, a rate with at most two decimal places — so the
+ * fixed 30¢ that `storefrontProcessingCostCents` adds in cents has to be
+ * folded into the rate. `(rate × amount + fixed) ÷ amount` is, with the
+ * amount cancelled,
+ *
+ *     percent = rate + fixed ÷ amount
+ *
+ * which is why a smaller recurring price carries a HIGHER percent: the 30¢
+ * is a bigger share of it. At 6% + 30¢ a $10 price carries 9%, $25 carries
+ * 7.2% and $100 carries 6.3%.
+ *
+ * Computed in hundredths of a percent on integers and rounded UP to the next
+ * hundredth. Up, for the reason the one-time helper rounds its percentage
+ * up: rounding to nearest would leave the recovery a fraction of a cent
+ * short of what Stripe debits half the time, and Stripe rejects a third
+ * decimal outright, so the only honest direction is over. Integers, because
+ * `0.09 * 100` is not `9` in floating point and a percent one ulp above a
+ * whole hundredth would round up to the next one. The same two constants as
+ * the one-time path, so repointing `STOREFRONT_PROCESSING_PERCENT` moves
+ * both surfaces together. Zero for a charge that is not a charge.
+ */ export function storefrontProcessingPassThroughPercent(amountCents) {
+    const amount = Number.isFinite(amountCents) && amountCents > 0 ? Math.round(amountCents) : 0;
+    if (amount <= 0) return 0;
+    const rateHundredths = Math.round(STOREFRONT_PROCESSING_PERCENT * 100);
+    // 30¢ ÷ amount is a fraction; × 100 makes it a percent, × 100 again makes
+    // it hundredths of one.
+    const fixedHundredths = STOREFRONT_PROCESSING_FIXED_CENTS * 10000 / amount;
+    return Math.min(100, Math.ceil(rateHundredths + fixedHundredths) / 100);
+}
+/**
+ * The `application_fee_percent` for ONE storefront subscription (AGL-2655):
+ * the plan's advertised take PLUS Stripe's processing cost as a percent —
+ * the recurring twin of `resolveTransactionFeeCents`, under the same rule.
+ * Every tier carries the pass-through, a 0% tier included, because the
+ * tier's 0% is a platform take and the pass-through is not one; it is what
+ * Stripe charges to take the payment, which on a destination charge is
+ * debited from the platform's balance whatever the tier.
+ *
+ * `amountCents` is the recurring items the percent will be applied to —
+ * the goods after any discount, tax and shipping excluded, the AGL-2317
+ * basis. Stripe applies the percent to the whole invoice and the paid-invoice
+ * correction scales it back to items, so sizing on items is what makes the
+ * recovery come out at cost rather than under.
+ *
+ * Composed in hundredths so two decimals stay two decimals (`2 + 6.34` is
+ * not always `8.34` in floating point), and capped at 100, Stripe's ceiling
+ * for the parameter — the recurring twin of the clamp to the charge.
+ */ export function resolveSubscriptionFeePercent(org, productType, amountCents) {
+    const amount = Number.isFinite(amountCents) && amountCents > 0 ? Math.round(amountCents) : 0;
+    if (amount <= 0) return 0;
+    const take = resolveTransactionFeePct(org, productType);
+    const passThrough = storefrontProcessingPassThroughPercent(amount);
+    return Math.min(100, (Math.round(take * 100) + Math.round(passThrough * 100)) / 100);
+}
+/**
+ * Platform take rate % for a MARKETPLACE listing sale (AGL-1543), priced
+ * off the SELLER org. Resolved through `resolveOrgEntitlements` — so a
+ * dead subscription prices as free-plan (30%) even while the stale `plan`
+ * field still names a paid tier, and a negotiated per-org
+ * `entitlements.marketplaceFeePct` override wins over the plan default.
+ * Resolve per request from the org doc; never cache the answer.
+ *
+ * An out-of-range or missing value falls back to the FREE-plan rate — the
+ * conservative direction. A malformed override must never zero the
+ * platform's cut.
+ */ export function resolveMarketplaceFeePct(org) {
+    const pct = resolveOrgEntitlements(org).marketplaceFeePct;
+    return Number.isFinite(pct) && pct >= 0 && pct <= 100 ? pct : PLAN_ENTITLEMENTS.free.marketplaceFeePct;
+}
+/**
+ * The marketplace take rate that breaks even LATEST, derived from the plan
+ * table rather than copied from it (AGL-2343).
+ *
+ * The lowest rate is the binding one: a smaller cut of the same price against
+ * the same processing cost needs a dearer listing to cover it, so advice quoted
+ * at this band holds for every publisher on every plan. Derived on each call
+ * because a hand-written second copy of a rate is exactly the artifact that
+ * decays into wrong money copy shown to a publisher — the same reason
+ * `planGrantingFeature` reads the table instead of a map.
+ */ export function bindingMarketplaceFeePct() {
+    return Math.min(...Object.values(PLAN_ENTITLEMENTS).map((plan)=>plan.marketplaceFeePct).filter((pct)=>Number.isFinite(pct) && pct > 0));
+}
+/**
+ * What one marketplace sale costs the PLATFORM to process (AGL-2343).
+ *
+ * NONE OF THESE IS AN AGLYN PRICE. They are Stripe's published US rates and
+ * the Texas rate the platform remits, and they exist only as inputs to a
+ * figure shown to a publisher while they type. Nothing is billed from them —
+ * the charged amounts are `resolveMarketplaceFeePct` and Stripe's own
+ * invoicing — so changing one changes a sentence, never a bill.
+ *
+ * WHY THE PLATFORM PAYS THE PROCESSING FEE AT ALL. Marketplace checkout is a
+ * DESTINATION charge with a fixed `transfer_data[amount]` and deliberately no
+ * `application_fee_amount`, so that the sales tax stays with the platform that
+ * owes it (AGL-1544). On a destination charge Stripe debits its fee from the
+ * PLATFORM's balance, and it is charged on `amount_total` — the listing price
+ * plus the tax added on top of it.
+ *
+ * So a $1 listing at a 20% take rate is a loss: the buyer pays $1.08, the
+ * seller is transferred $0.80, $0.08 is owed to the state, Aglyn keeps $0.20
+ * and pays Stripe about $0.33. Net −$0.13.
+ *
+ * THE BNPL RATE IS THE ONE THAT BINDS, and it is not hypothetical: the live
+ * default payment method configuration has `klarna` and `affirm` enabled
+ * alongside `card`, `cashapp`, `link`, `amazon_pay` and `apple_pay`, and the
+ * marketplace session pins no `payment_method_types`, so a buyer may pay by
+ * either. Break-even is computed from the dearest enabled method, because a
+ * figure computed from the cheapest would be wrong exactly when it mattered.
+ * IF BNPL IS EVER TURNED OFF FOR MARKETPLACE SESSIONS, this constant is what
+ * has to move with it.
+ */ export const MARKETPLACE_PROCESSING_PERCENT_CARD = 2.9;
+/** Klarna/Affirm, roughly. See the note above — this is the binding one. */ export const MARKETPLACE_PROCESSING_PERCENT_BNPL = 6;
+/** Stripe's per-transaction fixed component, in cents. */ export const MARKETPLACE_PROCESSING_FIXED_CENTS = 30;
+/**
+ * The tax rate the break-even figure assumes. Tax is added ON TOP of the
+ * listing price and enlarges the base Stripe charges its percentage against,
+ * so it makes the platform's cost slightly worse; the real rate is whatever
+ * `automatic_tax` computes for the buyer's address, and this is the
+ * platform's own Texas rate as a representative figure.
+ */ export const MARKETPLACE_ASSUMED_TAX_PERCENT = 8.25;
+/**
+ * The processing rate a STOREFRONT destination charge is priced against
+ * (AGL-2152), and the one identifier to repoint if the storefront's payment
+ * method set changes.
+ *
+ * Deliberately its OWN name rather than a direct use of the marketplace
+ * constants, while being defined as one of them: the two surfaces share
+ * Stripe's published rates and today share the platform's payment method
+ * configuration, but they are separate product decisions. A future choice to
+ * pin `payment_method_types` on storefront sessions to the card family — and
+ * so to recover at `MARKETPLACE_PROCESSING_PERCENT_CARD` — must not silently
+ * lower the marketplace listing floor, which is derived from the same figure
+ * for a different flow.
+ */ export const STOREFRONT_PROCESSING_PERCENT = MARKETPLACE_PROCESSING_PERCENT_BNPL;
+/** Stripe's per-transaction fixed component, in cents. Not rate-dependent. */ export const STOREFRONT_PROCESSING_FIXED_CENTS = MARKETPLACE_PROCESSING_FIXED_CENTS;
+/**
+ * The funds flow for one sale, mirroring what `checkout.ts` actually builds
+ * (AGL-2343): tax exclusive and on top, a fixed transfer of the seller's share
+ * of the PRE-tax price, and Stripe's fee charged on the buyer's total.
+ */ export function marketplaceSaleEconomics(priceUsd, feePercent, processingPercent = MARKETPLACE_PROCESSING_PERCENT_BNPL) {
+    const priceCents = Math.max(0, Math.round(priceUsd * 100));
+    const taxCents = Math.round(priceCents * MARKETPLACE_ASSUMED_TAX_PERCENT / 100);
+    const buyerPaysCents = priceCents + taxCents;
+    const platformFeeCents = Math.round(priceCents * feePercent / 100);
+    const sellerReceivesCents = priceCents - platformFeeCents;
+    // A zero-price listing takes no payment at all, so there is no fee to pay.
+    const processingCents = priceCents === 0 ? 0 : Math.round(buyerPaysCents * processingPercent / 100 + MARKETPLACE_PROCESSING_FIXED_CENTS);
+    return {
+        priceCents,
+        taxCents,
+        buyerPaysCents,
+        sellerReceivesCents,
+        platformFeeCents,
+        processingCents,
+        platformNetCents: platformFeeCents - processingCents
+    };
+}
+/**
+ * The cheapest WHOLE-DOLLAR price at which the platform does not lose money on
+ * a sale (AGL-2343).
+ *
+ * Whole dollars because every publish route rounds `priceUsd` to one, so a
+ * fractional break-even is not a price anyone can actually set. Searched
+ * rather than solved algebraically so that it can never disagree with
+ * `marketplaceSaleEconomics` — the rounding in there is what decides the
+ * answer at these amounts, and a closed form would drift from it silently.
+ *
+ * THIS IS THE ENFORCED FLOOR: `marketplaceMinPriceUsd` returns this figure
+ * and every publish door refuses a paid listing under it. Recorded in the Pricing
+ * Decision Log and on AGL-2343.
+ */ export function marketplaceBreakEvenUsd(feePercent = bindingMarketplaceFeePct(), processingPercent = MARKETPLACE_PROCESSING_PERCENT_BNPL) {
+    // The listing price ceiling is the marketplace plugin's
+    // `MARKETPLACE_MAX_PRICE_USD`, which this library may not import (an app-tier
+    // lib cannot depend on an addon). The loop only needs SOME bound, and the
+    // answer is single digits at every rate the table holds, so a generous local
+    // one costs nothing and cannot drift into a wrong figure.
+    const searchCeilingUsd = 1000;
+    for(let priceUsd = 1; priceUsd <= searchCeilingUsd; priceUsd += 1){
+        if (marketplaceSaleEconomics(priceUsd, feePercent, processingPercent).platformNetCents >= 0) {
+            return priceUsd;
+        }
+    }
+    return searchCeilingUsd;
+}
+/**
+ * THE MINIMUM PRICE a paid marketplace listing may carry (AGL-2343).
+ *
+ * The floor is not a chosen round number — it is the break-even price itself,
+ * the
+ * cheapest whole dollar at which `marketplaceSaleEconomics` stops returning a
+ * negative platform net, computed at the take rate that breaks even LATEST and
+ * the dearest payment method the live configuration enables. Today that is $3.
+ *
+ * DERIVED, NEVER RESTATED. A second hand-written copy of this number in a
+ * publish route or a form is the artifact that decays into a route refusing a
+ * price a form invited, so both the server-side validator
+ * (`MARKETPLACE_MIN_PRICE_USD` in the marketplace model) and every price field
+ * read this. If the payment method set changes, or the plan table's lowest
+ * take rate moves, the floor moves with them on the next call.
+ *
+ * ZERO IS NOT BELOW THE FLOOR. A free listing takes no payment at all, so it
+ * costs nothing to process; the floor is a minimum on PAID listings only.
+ */ export function marketplaceMinPriceUsd() {
+    return marketplaceBreakEvenUsd();
+}
+/**
+ * Whether a price is a PAID price that the floor refuses (AGL-2343) — the one
+ * predicate a form uses to mark its price field in error and hold its publish
+ * button, so that the button and the server agree about what is publishable.
+ *
+ * Rounds first because every publish route does, and a form's value is a
+ * string mid-type: `'2.6'` is stored as $3 and must read as allowed here, or
+ * the button would refuse a price the route accepts.
+ */ export function isBelowMarketplacePriceFloor(priceUsd) {
+    const price = Math.round(Number(priceUsd) || 0);
+    return price > 0 && price < marketplaceMinPriceUsd();
+}
+/**
+ * The sentence a publish form shows under its price field when the price is
+ * below the floor (AGL-2343), or `undefined` when there is nothing to say.
+ *
+ * NOT ADVISORY ANY MORE. The same figure is enforced by every publish route
+ * through `publishPreconditionRefusal`, so this text has to read as a
+ * requirement rather than a warning — a publisher who is told "consider
+ * raising it" and then refused has been lied to by the form. It still explains
+ * WHY, because a bare minimum with no arithmetic behind it reads as an
+ * arbitrary tax on cheap listings.
+ *
+ * Shared by every publish form rather than written into each, because the
+ * figure has to be the same one in all of them and the wording is the only
+ * place a publisher ever sees it.
+ *
+ * Quoted at the take rate that breaks even LATEST, so the sentence holds for a
+ * free-plan publisher too.
+ */ export function marketplacePriceCostNote(priceUsd) {
+    const price = Math.round(Number(priceUsd) || 0);
+    const minimum = marketplaceMinPriceUsd();
+    // A free listing takes no payment, so it costs nothing to process and has
+    // nothing to warn about — silence there is the point, not an oversight.
+    if (!isBelowMarketplacePriceFloor(price)) return undefined;
+    const { processingCents, platformFeeCents } = marketplaceSaleEconomics(price, bindingMarketplaceFeePct());
+    const usd = (cents)=>`$${(cents / 100).toFixed(2)}`;
+    return `Too low to publish. Processing a $${price} payment costs about ` + `${usd(processingCents)}, more than the ${usd(platformFeeCents)} platform ` + `fee — the sale would lose money. The minimum paid price is ` + `$${minimum}, and a free listing ($0) takes no payment at all.`;
+}
+/**
+ * The standing helper sentence a price field shows when there is nothing wrong
+ * (AGL-2343): the minimum stated up front, so a publisher meets it while
+ * typing instead of discovering it as a refusal.
+ *
+ * A capability that is not surfaced in the console does not count as shipped,
+ * and that applies to a REFUSAL as much as to a feature: a floor only a route
+ * knows about is a trap.
+ *
+ * @param suffix whatever else that particular form needs to say, appended.
+ */ export function marketplacePriceFloorHint(suffix) {
+    return `0 for free, or $${marketplaceMinPriceUsd()} and up for a paid listing.` + (suffix ? ` ${suffix}` : '');
+}
+/**
+ * The cheapest plan whose BASE features include `feature`, in ladder order —
+ * the answer to "which plan do I need for this?", which is the one thing an
+ * upsell has to say and the one thing no gate can hard-code without drifting
+ * from the table it is quoting.
+ *
+ * Returns `undefined` when NO plan carries it on the base tier. That is not
+ * an error: `eventCalendar` is an add-on purchased through
+ * `resolveOrgEntitlements`' override path and is false on all eight tiers, so
+ * "upgrade to X" is the wrong sentence for it. Callers must handle undefined
+ * rather than defaulting to a tier name.
+ *
+ * Derived from PLAN_ENTITLEMENTS on every call rather than from a
+ * hand-written map: a table of "feature → plan" is exactly the artifact that
+ * decays silently when a tier's flags are re-cut, and it would decay into
+ * pricing copy shown to a customer.
+ *
+ * Ladder order is `SELF_SERVE_PLANS` then `enterprise` — the same order the
+ * plan grid renders — so an enterprise-only feature (`ssoEnabled`) reports
+ * Enterprise rather than nothing.
+ */ export function planGrantingFeature(feature) {
+    return [
+        ...SELF_SERVE_PLANS,
+        'enterprise'
+    ].find((plan)=>Boolean(PLAN_ENTITLEMENTS[plan].features[feature]));
+}
+/**
+ * The plan name an upsell should name, ready to interpolate — "Business",
+ * or undefined when {@link planGrantingFeature} has no answer.
+ */ export function planLabelGrantingFeature(feature) {
+    const plan = planGrantingFeature(feature);
+    return plan ? PLAN_LABELS[plan] : undefined;
+}
+/**
+ * True when the org's plan (or overrides) enables the boolean feature. A
+ * key outside `OrgFeatureFlags` is one a plugin declared (AGL-2940) and is
+ * answered the same way.
+ */ export function checkEntitlement(org, feature) {
+    const features = resolveOrgEntitlements(org).features;
+    return Boolean(features[feature]);
+}
+export { PLATFORM_BRANDING_PROFILE } from "./platform-brand.js";
+/** A non-empty trimmed string, else undefined — blanks never override a default. */ function cleanBrandString(value) {
+    const trimmed = typeof value === 'string' ? value.trim() : '';
+    return trimmed.length ? trimmed : undefined;
+}
+/**
+ * The effective brand for an org (White-Label Phase 1). EVERY branded
+ * surface — published-site branding, transactional email, console chrome —
+ * MUST read the brand through this one resolver so a white-label org can
+ * never partly-render as Aglyn (the multi-surface drift that dogged
+ * `removeBranding`, which each surface re-derived on its own).
+ *
+ * When the org carries the `whiteLabel` entitlement (Agency tier, or an
+ * Enterprise per-org override), the org's `brandingProfile` values win and
+ * any field it leaves blank falls back to the Aglyn default. Without the
+ * entitlement the stored profile is ignored entirely and the full Aglyn
+ * brand is returned — so an org that white-labeled and then downgraded
+ * reverts cleanly.
+ */ export function resolveBrandingProfile(org) {
+    var _ref, _cleanBrandString, _cleanBrandString1, _cleanBrandString2, _cleanBrandString3, _cleanBrandString4, _cleanBrandString5, _cleanBrandString6, _cleanBrandString7, _cleanBrandString8;
+    if (!checkEntitlement(org, 'whiteLabel')) return PLATFORM_BRANDING_PROFILE;
+    const profile = (_ref = org == null ? void 0 : org.brandingProfile) != null ? _ref : {};
+    return {
+        productName: (_cleanBrandString = cleanBrandString(profile.productName)) != null ? _cleanBrandString : PLATFORM_BRANDING_PROFILE.productName,
+        // NO FALLBACK — and this became load-bearing the moment
+        // `PLATFORM_BRANDING_PROFILE.logoUrl` stopped being null. Inheriting it
+        // would stamp the PLATFORM's mark on a white-label org's published sites,
+        // which is precisely the disclosure white-label is sold to prevent. A
+        // white-label org that set no logo shows none.
+        logoUrl: (_cleanBrandString1 = cleanBrandString(profile.logoUrl)) != null ? _cleanBrandString1 : null,
+        faviconUrl: (_cleanBrandString2 = cleanBrandString(profile.faviconUrl)) != null ? _cleanBrandString2 : PLATFORM_BRANDING_PROFILE.faviconUrl,
+        primaryColor: (_cleanBrandString3 = cleanBrandString(profile.primaryColor)) != null ? _cleanBrandString3 : PLATFORM_BRANDING_PROFILE.primaryColor,
+        // NO FALLBACK, and this is the one field that gets none (AGL-2428).
+        //
+        // Only a white-label org reaches this line — the guard above hands every
+        // other org the platform profile whole. So a blank here belongs to an
+        // organization whose transactional mail reads as *theirs* to a recipient
+        // who is *their* customer, and filling the gap with Aglyn's desk sends
+        // that person to a support team that cannot help them, while disclosing
+        // a vendor they were never told about. `platform-brand.ts` calls the
+        // same substitution in the self-host case "a trap dressed as a default";
+        // this is that trap with a different victim.
+        //
+        // Blank therefore means NO LINK, exactly as `emailLogoUrl` one field
+        // down already means no logo. An email with a gap where a link should be
+        // reads as broken; an email with no support line reads as plain, which
+        // is the right appearance for an organization that has not set one.
+        supportUrl: (_cleanBrandString4 = cleanBrandString(profile.supportUrl)) != null ? _cleanBrandString4 : null,
+        // A white-label org has no separate "home" field to store, and the same
+        // no-fallback rule applies for the same reason: `PLATFORM_HOME_URL` here
+        // would put a link to the platform's marketing site on the badge of an
+        // org that pays to conceal the platform exists. Their support URL is the
+        // only destination they have told us about, which is exactly what this
+        // badge already linked to before the split — so white-label badges are
+        // unchanged, and only the platform's own badge stops opening a mail
+        // client.
+        homeUrl: (_cleanBrandString5 = cleanBrandString(profile.supportUrl)) != null ? _cleanBrandString5 : null,
+        fromName: (_cleanBrandString6 = cleanBrandString(profile.fromName)) != null ? _cleanBrandString6 : PLATFORM_BRANDING_PROFILE.fromName,
+        emailLogoUrl: (_cleanBrandString7 = cleanBrandString(profile.emailLogoUrl)) != null ? _cleanBrandString7 : PLATFORM_BRANDING_PROFILE.emailLogoUrl,
+        customConsoleDomain: (_cleanBrandString8 = cleanBrandString(profile.customConsoleDomain)) != null ? _cleanBrandString8 : PLATFORM_BRANDING_PROFILE.customConsoleDomain
+    };
+}
+/**
+ * The brand as MERGE TOKENS, for a staff-designed system-email template
+ * (AGL-2139).
+ *
+ * White-label inverted precisely when staff published a template, which is
+ * that feature's normal steady state. Every org-context sender has the shape
+ * `subject: designed?.subject ?? <branded fallback>` — the DESIGNED template
+ * wins — and the catalog copy hard-coded "Aglyn" throughout. There was no
+ * brand token to design against either: the merge maps carried `org.name`,
+ * `invite.role`, `signInUrl` and friends and nothing about the brand, and
+ * `blankUnresolvedTokens` BLANKS any token the caller did not supply. So a
+ * designer who reached for `{{brand.productName}}` would have shipped an
+ * email with a hole in the sentence.
+ *
+ * Token bodies are namespaced `brand.*` so a designer can tell them from the
+ * per-send values, and they resolve for EVERY org — Aglyn's own included,
+ * since `PLATFORM_BRANDING_PROFILE.productName` is `'Aglyn'`. That is what makes
+ * a single template correct for both populations instead of one hard-coded
+ * for the majority.
+ *
+ * The email LOGO is deliberately absent. It is structural — `renderEmailHtml`
+ * emits it as a header row above the designed body, or emits nothing — so it
+ * travels as an option rather than as a token a template could forget to
+ * place, and there is no sample URL a staff test-send could render without
+ * showing a broken image.
+ */ export function brandMergeTokens(branding) {
+    var _branding_supportUrl;
+    return {
+        'brand.productName': branding.productName,
+        'brand.fromName': branding.fromName,
+        // EMPTY, never omitted, when the org has no Support URL (AGL-2428).
+        //
+        // `renderLoadedSystemEmail` merges these OVER `DEFAULT_BRAND_TOKENS`,
+        // which carries the platform's own support URL for the genuinely
+        // org-less senders. Dropping the key here would let that default show
+        // through and mail a white-label org's customer a link to Aglyn — the
+        // exact leak this closes — so the key must be present and empty in order
+        // to overwrite it. A designed template that interpolates the token
+        // renders nothing where it sits.
+        'brand.supportUrl': (_branding_supportUrl = branding.supportUrl) != null ? _branding_supportUrl : ''
+    };
+}
+/**
+ * The value of the `<meta name="generator">` tag and of the `x-powered-by`
+ * header on published sites (AGL-2088) — the canonical CMS signal WordPress,
+ * Squarespace, Drupal and Ghost all ship, and the thing tech-stack detectors
+ * key on.
+ *
+ * Deliberately VERSIONLESS. The accidental headers this replaced carried
+ * `1.0.0-alpha.0` and a Node version, which dated every deployment and named
+ * our runtime to no consumer. A detector needs the product name and nothing
+ * else.
+ */ export const PLATFORM_GENERATOR_NAME = PLATFORM_BRAND_NAME;
+/**
+ * May this org's published pages say they were built with Aglyn? (AGL-2088)
+ *
+ * The gate for the `<meta name="generator">` tag and the `x-powered-by`
+ * header. It reads the SAME entitlement `resolveBrandingProfile` reads —
+ * `whiteLabel` — rather than inventing a parallel one, so an agency's
+ * concealment promise has exactly one definition.
+ *
+ * WHY `whiteLabel` AND NOT `showBranding`. The "Made with Aglyn" badge is
+ * gated on `removeBranding`, which every plan above free grants, so reusing
+ * that gate would confine the signal to free-tier sites — the corpus this
+ * exists to build would be almost empty on day one. The two promises are also
+ * different in kind: `removeBranding` buys a page with no Aglyn credit on it,
+ * an aesthetic commitment about what a VISITOR sees; `whiteLabel` buys
+ * concealment of who built the site, which is the promise a machine-readable
+ * fingerprint actually breaks. A paying customer on a mid plan has bought a
+ * clean page, not anonymity.
+ *
+ * ⚠️ AN UNRESOLVED ORG SUPPRESSES, and this is the whole reason the function
+ * exists instead of a bare `!checkEntitlement(org, 'whiteLabel')` at each call
+ * site. `resolveOrgEntitlements(null)` resolves to the FREE plan — a loading
+ * default answering a question it was never asked — so a null org reads as
+ * "no white-label" and would EMIT. That null is not hypothetical: the tenant's
+ * `getOrgBilling` fails open with `org: null` on a Firestore error, so a
+ * transient read failure on an Agency site would have stamped the generator
+ * tag onto it. The asymmetry decides the direction: suppressing wrongly costs
+ * us one detection sample, emitting wrongly breaks a paid promise on a
+ * customer's own domain. So the org must be PRESENT and lack the entitlement;
+ * absent is not the same as free here.
+ */ export function showsPlatformAttribution(org) {
+    // `{}` is treated as unresolved alongside `null`, and that is not
+    // pedantry: no org doc that was actually READ is empty — the converter
+    // yields `$id` at minimum — so an empty object only ever arrives from a
+    // placeholder or a loading default, the same shape `useBranding` hands back
+    // before its read lands. It resolves to the free plan like every other
+    // absent org, which is the right default for a quota and the wrong one for
+    // a disclosure.
+    if (!org || Object.keys(org).length === 0) return false;
+    return !checkEntitlement(org, 'whiteLabel');
+}
+/**
+ * Whether the org has actually **configured** a white-label brand (AGL-1110) —
+ * a non-empty product name or logo. White-label chrome should activate only
+ * when this is true, not merely because the plan grants the `whiteLabel`
+ * entitlement: an Agency org (or a comped Enterprise org) that never set up a
+ * brand keeps the plain Aglyn wordmark — no product-name-text render, no
+ * flash — until it opts in on the branding page.
+ */ export function hasBrandingProfile(org) {
+    const profile = org == null ? void 0 : org.brandingProfile;
+    if (!profile) return false;
+    return !!(cleanBrandString(profile.productName) || cleanBrandString(profile.logoUrl));
+}
+/**
+ * Seat quota check (AGL-112): seats differ from plain quotas because orgs
+ * can buy addon seats (`org.seatAddons`) up to a per-plan hard max —
+ * beyond the max the only path is upgrading the plan. `managers` counts
+ * org-manager seats org-wide; `members` counts per-site COLLABORATORS
+ * (`hosts/{id}/members`, viewer/editor/admin — legacy key name, AGL-888).
+ * End-user member accounts (`siteMembers`) are unlimited and never pass
+ * through here.
+ *
+ * SINCE AGL-2439 THIS IS THE PLAN'S CAP FOR `members`, with no purchased
+ * seats in it — see the comment at the add below. A per-site answer must come
+ * from `checkHostCollaboratorQuota(org, hostId, used)`, which is the only
+ * thing that knows which site holds which pool seat. Every caller that has a
+ * `hostId` must use that one; this stays correct for a plan-level readout
+ * (what the plan includes per site, before anything is assigned).
+ */ export function checkSeatQuota(org, kind, currentUsage) {
+    var _resolvePurchasedAddons_kind;
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const included = kind === 'managers' ? entitlements.managersPerOrg : entitlements.membersPerHost;
+    const maxSeats = kind === 'managers' ? entitlements.maxManagersPerOrg : entitlements.maxMembersPerHost;
+    const addonPriceUsd = kind === 'managers' ? pricing.extraSeatMonthlyUsd : pricing.extraCollaboratorMonthlyUsd;
+    // `members` IS NOT ADDED HERE, and this is the fix, not an omission
+    // (AGL-2439) — the AGL-1775 shape, applied to
+    // the key that never got it. `seatAddons.members` is an ORG-LEVEL purchased
+    // quantity and `membersPerHost` is enforced PER SITE, so folding one into
+    // the other handed every site the whole purchase: an org with 20 sites that
+    // bought ONE extra collaborator seat received 20 seats for one seat's price.
+    // The quantity is now a POOL and `org.collaboratorAllocations` says which
+    // site holds each seat. What this function returns for `members` is
+    // therefore **the plan's cap alone** — exactly what an unallocated site must
+    // resolve to. Per-site capacity comes from `checkHostCollaboratorQuota`;
+    // nothing else may add the pool back in.
+    //
+    // `managers` is unaffected and still adds: `managersPerOrg` really is
+    // org-level, so an org-level purchase raising an org-level cap is correct
+    // there. That difference is the whole reason this is a `kind` switch rather
+    // than one rule.
+    const purchased = kind === 'managers' ? Math.max(0, (_resolvePurchasedAddons_kind = resolvePurchasedAddons(org)[kind]) != null ? _resolvePurchasedAddons_kind : 0) : 0;
+    const limit = Math.min(included + purchased, maxSeats);
+    return {
+        allowed: currentUsage < limit,
+        limit,
+        remaining: Math.max(0, limit - currentUsage),
+        included,
+        purchased,
+        maxSeats,
+        upgradeRequired: addonPriceUsd === null || limit >= maxSeats,
+        addonPriceUsd
+    };
+}
+export function checkQuota(org, quota, currentUsage) {
+    const limit = resolveOrgEntitlements(org)[quota];
+    return {
+        allowed: currentUsage < limit,
+        limit,
+        remaining: Math.max(0, limit - currentUsage)
+    };
+}
+/**
+ * Dataset quota check (AGL-132/240), mirroring `checkSeatQuota`: orgs can
+ * buy addon datasets (`org.seatAddons.datasets`, org-wide) up to the
+ * plan's hard max; beyond the max the only path is upgrading.
+ */ export function checkDatasetQuota(org, currentUsage) {
+    var _resolvePurchasedAddons_datasets;
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const included = entitlements.datasetsPerOrg;
+    const maxDatasets = entitlements.maxDatasetsPerOrg;
+    const addonPriceUsd = pricing.extraDatasetMonthlyUsd;
+    const purchased = Math.max(0, (_resolvePurchasedAddons_datasets = resolvePurchasedAddons(org).datasets) != null ? _resolvePurchasedAddons_datasets : 0);
+    const limit = Math.min(included + purchased, maxDatasets);
+    return {
+        allowed: currentUsage < limit,
+        limit,
+        remaining: Math.max(0, limit - currentUsage),
+        included,
+        purchased,
+        maxDatasets,
+        upgradeRequired: addonPriceUsd === null || limit >= maxDatasets,
+        addonPriceUsd
+    };
+}
+/**
+ * Org dataset-storage meter (AGL-240): aggregate stored document bytes
+ * across `orgs/{orgId}/datasets`. Plans with an `extraDataGbMonthlyUsd`
+ * rate meter the overage onto the monthly invoice (cost-plus, AGL-41);
+ * plans without one (free) hard-block at the included size.
+ */ export function checkDataStorageQuota(org, usedMb) {
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const includedMb = entitlements.dataStorageMbPerOrg;
+    const overageRateUsd = pricing.extraDataGbMonthlyUsd;
+    const used = Math.max(0, usedMb);
+    const overageMb = Math.max(0, used - includedMb);
+    const overageGb = overageMb / 1024;
+    return {
+        allowed: overageRateUsd !== null ? true : used < includedMb,
+        includedMb,
+        usedMb: used,
+        remainingMb: Math.max(0, includedMb - used),
+        overageGb,
+        overageMonthlyUsd: overageRateUsd === null ? 0 : Math.round(overageGb * overageRateUsd * 100) / 100,
+        overageRateUsd
+    };
+}
+/**
+ * Customer REST API request meter (AGL-634): the monthly request count for an
+ * org. Business and every tier above it carry `apiAccess` and an
+ * `extraApiRequestsUsdPer1k` rate, so requests past the included quota meter
+ * onto the monthly invoice
+ * (cost-plus, like storage overage — never a hard wall mid-integration); plans
+ * without API access have `included: 0` and always block.
+ */ export function checkApiRequestQuota(org, usedRequests) {
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const included = entitlements.apiRequestsPerMonth;
+    const overageRateUsd = pricing.extraApiRequestsUsdPer1k;
+    const used = Math.max(0, usedRequests);
+    const overageRequests = Math.max(0, used - included);
+    return {
+        allowed: overageRateUsd !== null ? true : used < included,
+        included,
+        used,
+        remaining: Math.max(0, included - used),
+        overageRequests,
+        overageMonthlyUsd: overageRateUsd === null ? 0 : Math.round(overageRequests / 1000 * overageRateUsd * 100) / 100,
+        overageRateUsd
+    };
+}
+/**
+ * CRM records band meter (AGL-890, widened in AGL-2611): contacts, companies
+ * and deals, counted together across the org and measured against the ONE
+ * band `contactsPerHost` names. Paid plans carry an `extraContactsUsdPer1k`
+ * rate, so records past the included band meter onto the monthly invoice
+ * (cost-plus, like storage and API overage — a growing audience is never
+ * dropped); free has no rate and hard-bands at the included count, refusing
+ * the next record of any of the three kinds.
+ *
+ * ONE band for three collections, and not three bands, because a company or
+ * a deal costs less to hold than a contact — a ~2 KB document with few index
+ * entries and no dynamic-list scan — so counting them at the contacts rate
+ * over-covers them, and a second and third number to explain would buy
+ * nothing a customer could act on. The caller passes the SUM; the server
+ * helper that takes the three aggregate reads is `countCrmRecords`, and the
+ * billing meter shows the three components in its caption so the sum is
+ * legible rather than opaque. Tasks and activities are not counted: they
+ * are bounded by human effort, and the activity log is capped per record by
+ * `CRM_ACTIVITIES_PER_RECORD_CEILING` instead.
+ *
+ * End-user member ACCOUNTS are unlimited on every plan (AGL-889) — this
+ * meters only the CRM record.
+ */ export function checkCrmRecordsQuota(org, usedRecords) {
+    const entitlements = resolveOrgEntitlements(org);
+    const pricing = resolvePlanPricing(org);
+    const included = entitlements.contactsPerHost;
+    const overageRateUsd = pricing.extraContactsUsdPer1k;
+    const used = Math.max(0, usedRecords);
+    const overageRecords = Math.max(0, used - included);
+    return {
+        allowed: overageRateUsd !== null ? true : used < included,
+        included,
+        used,
+        remaining: Math.max(0, included - used),
+        overageRecords,
+        overageMonthlyUsd: overageRateUsd === null ? 0 : Math.round(overageRecords / 1000 * overageRateUsd * 100) / 100,
+        overageRateUsd
+    };
+}
+/**
+ * The name the band's gate carried while it counted contacts alone. The SAME
+ * function — every caller that still says "contact" is measuring the records
+ * band and must hand it the summed count, not the contacts aggregate.
+ * @deprecated Call `checkCrmRecordsQuota`.
+ */ export const checkContactQuota = checkCrmRecordsQuota;
+/**
+ * `orgs/{orgId}/crmEmailUsage/{YYYY-MM-DD}` — the durable per-day counter of
+ * one-to-one CRM emails, `{ count, day, updatedAt }`, server-written only and
+ * member-readable, exactly as `apiUsage/{month}` is for API requests.
+ */ export const CRM_EMAIL_USAGE_COLLECTION = 'crmEmailUsage';
+/**
+ * The document id of today's one-to-one email counter, `YYYY-MM-DD` in UTC.
+ *
+ * UTC rather than the workspace's zone, for the reason `apiUsageMonth` keys
+ * the API counter in UTC: the cap is enforced on a server that has no zone
+ * of the customer's to read, and a boundary that moved with a browser's
+ * clock would let one day's sends be counted against two.
+ */ export function crmEmailUsageDayKey(now = new Date()) {
+    return now.toISOString().slice(0, 10);
+}
+/**
+ * One-to-one CRM email cap (AGL-2611): how many messages a workspace may
+ * still send from CRM records today, mirroring `checkApiRequestQuota`.
+ *
+ * A HARD cap with no overage rate, on every tier — the one respect in which
+ * it differs from the API meter it is shaped after. `allowed` is therefore
+ * `used < included` outright. Every paid tier's cap is finite, Enterprise's
+ * 2,000 included, and 0 on Free makes it false at zero, so a per-org
+ * `features.crm` grant does not send until `crmEmailsPerDay` is raised
+ * beside it.
+ *
+ * ## The contract for the send route
+ *
+ * The route that sends a one-to-one email takes the send as a SLOT on
+ * `orgs/{orgId}/crmEmailUsage/{crmEmailUsageDayKey()}` inside one Firestore
+ * transaction — `reserveCrmEmailSend` in `@aglyn/tenant-data-admin` reads
+ * `count`, calls this with that figure, REFUSES with the plan reason when
+ * `allowed` is false and otherwise writes `used + 1` in the same transaction
+ * (AGL-2645). A read-then-write cap let two reps at the last slot both pass
+ * one reading of it; the transaction re-runs the second on the raised
+ * figure. The slot is taken before the message leaves and handed back by
+ * `releaseCrmEmailSend` when the provider refuses it. A delivered send is
+ * then recorded on the org's `emailSends` cost meter through
+ * `recordEmailSends` as `transactional`, because every message the provider
+ * charged for is priced into COGS and the campaign cap does not govern it.
+ * The count enforced is the count billed, from one document, the way the
+ * API meter works.
+ *
+ * Read the counter with `used` from the server: the console meter on the
+ * billing page reads the same document, member-readable, so a rep is never
+ * told their limit by being refused.
+ */ export function checkCrmEmailQuota(org, usedToday, now = new Date()) {
+    const included = resolveOrgEntitlements(org).crmEmailsPerDay;
+    const used = Math.max(0, Math.floor(Number(usedToday) || 0));
+    const resetsAt = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), now.getUTCDate() + 1));
+    return {
+        allowed: used < included,
+        included,
+        used,
+        remaining: Math.max(0, included - used),
+        resetsAt
+    };
+}
+/**
+ * Volume above the plan's included band, in emails.
+ *
+ * Transactional mail is never refused, so an org CAN and will finish a month
+ * over its included allowance. That is not an error and not a failed send —
+ * it is the overage the cap chose not to enforce, and recording it is what
+ * keeps it from being a surprise at invoicing. `UNLIMITED` (and any
+ * non-positive limit, which is how "no included allowance" is expressed)
+ * yields 0 rather than the whole month's volume.
+ *
+ * DEFINED HERE and re-exported from `email-metering.ts` (AGL-2155's move):
+ * the billing page renders this figure before anything is invoiced, and it
+ * is a client component that cannot pull in the Admin SDK. One subtraction,
+ * so the readout and the invoice cannot disagree.
+ */ export function emailSendsOverage(total, limit) {
+    const sends = Number(total);
+    const included = Number(limit);
+    if (!Number.isFinite(sends) || sends <= 0) return 0;
+    if (!Number.isFinite(included) || included <= 0) return 0;
+    return Math.max(0, sends - included);
+}
+/**
+ * Prices email volume past a plan's included band.
+ *
+ * ## No `allowed`, deliberately
+ *
+ * Every other meter's helper here answers "may this proceed" alongside "what
+ * does it cost", because on those axes one gate decides both. Email has two
+ * gates that are not the same gate: `reserveCampaignEmailSends` refuses a
+ * CAMPAIGN at the band inside a transaction, and nothing at all refuses
+ * transactional mail at any tier. A field named `allowed` on this result
+ * would be a plausible-looking thing for a sender to consult, and a
+ * transactional sender consulting it is how a password reset stops going out.
+ * So the result carries money and nothing else.
+ *
+ * ## Takes the overage, does not recompute it
+ *
+ * `emailSendsOverage` already derives the excess from the cost meter and the
+ * resolved band, on the path that records it. Re-deriving it here from a raw
+ * total would be a second overage model to drift from the first — which is
+ * the shape AGL-1402 documented, where two figures that should have been one
+ * disagreed by 20-45% for years.
+ *
+ * A null rate yields zero, structurally rather than by a check, which is what
+ * keeps free at zero on this axis for the same reason it is zero on the other
+ * three.
+ */ export function priceEmailSendOverage(org, overageSends) {
+    const overageRateUsd = resolvePlanPricing(org).extraEmailSendsUsdPer1k;
+    const sends = Number(overageSends);
+    const over = Number.isFinite(sends) && sends > 0 ? sends : 0;
+    return {
+        overageSends: over,
+        overageMonthlyUsd: overageRateUsd === null ? 0 : Math.round(over / 1000 * overageRateUsd * 100) / 100,
+        overageRateUsd
+    };
+}
+/**
+ * Is this org's plan subject to the metered infrastructure pass-through
+ * (AGL-1280)? The single answer behind three otherwise-unrelated behaviours:
+ * whether storage/bandwidth/form usage past the included band is BILLED, and
+ * whether the form-submission cap is a wall or a meter.
+ *
+ * Deliberately a plan-level question, not an org-level one — an org with no
+ * plan resolves as free, so an unknown org meters nothing. Billing usage to
+ * someone with no subscription is the one error direction with no recovery.
+ * A staff comp is that someone too (AGL-3034): it grants a paid plan with no
+ * subscription behind it, so `resolvePlanPricing` answers `false` for it and
+ * its bands are walls.
+ */ export function planMetersInfraOverage(org) {
+    return resolvePlanPricing(org).meteredInfraPassThrough;
+}
+/**
+ * Monthly form-submission meter (AGL-76, made coherent in AGL-1280).
+ *
+ * Submissions were BOTH hard-capped at `formSubmissionsPerMonth` (429) and
+ * metered — which made the published promise that usage past the
+ * included band is billed rather than cut off false for the one meter where
+ * being cut off costs the customer a lead. Now it mirrors the other three
+ * overage meters exactly: a plan with the metered pass-through always accepts
+ * and prices the excess (`estimateMonthlyUsageCost`); free has no
+ * subscription to bill, so its included count stays a hard wall.
+ *
+ * Priced per ORG at cost-plus, but capped per SITE, because that is where the
+ * counter lives (`hosts/{id}/counters/formSubmissions`). Callers gating a
+ * single submission pass that site's month count.
+ */ export function checkFormSubmissionQuota(org, usedThisMonth) {
+    const included = resolveOrgEntitlements(org).formSubmissionsPerMonth;
+    const metered = planMetersInfraOverage(org);
+    const used = Math.max(0, usedThisMonth);
+    return {
+        allowed: metered ? true : used < included,
+        included,
+        used,
+        remaining: Math.max(0, included - used),
+        overageSubmissions: Math.max(0, used - included),
+        metered
+    };
+}
+/**
+ * How far past a plan's own included band the abuse ceiling sits (AGL-1655).
+ * Ten times what the customer bought is not growth — a site that legitimately
+ * outgrows its band by an order of magnitude has an upgrade conversation
+ * waiting, not a silent invoice.
+ */ export const FORM_ABUSE_CEILING_MULTIPLE = 10;
+/**
+ * Absolute floor for the abuse ceiling, so the small plans get real headroom
+ * rather than a second, tighter plan limit wearing a different name. Starter
+ * includes 200/month; 10× would be 2,000, which a genuinely busy site could
+ * reach. 5,000 is ~167 submissions a day on ONE site — no legitimate site on
+ * a small plan reaches that, and no small customer can be billed past
+ * 5,000 × $0.000065 ≈ $0.33 of abuse.
+ */ export const FORM_ABUSE_CEILING_FLOOR = 5000;
+/**
+ * Ceiling for plans whose included count is UNLIMITED (Agency, Enterprise),
+ * where a multiple has nothing to multiply. Kept at or above the ceiling of
+ * every finite plan below it (Advanced includes 100,000 → 1,000,000) so the
+ * ladder never inverts and a bigger plan never gets the smaller ceiling.
+ */ export const FORM_ABUSE_CEILING_UNLIMITED = 1000000;
+/**
+ * Per-site monthly abuse ceiling for form submissions (AGL-1655).
+ *
+ * Deliberately NOT part of `checkFormSubmissionQuota`. That function answers
+ * a plan question — "did the customer buy this?" — and AGL-1280 correctly
+ * made its answer on a metered plan always yes, because usage past the band
+ * bills rather than blocks. This one answers a different question: "is this
+ * still a customer's traffic at all?" Conflating them is how the plan gate
+ * ended up as the anti-abuse control it was never designed to be, and how
+ * `allowed: metered ? true : …` came to mean an unbounded bill.
+ *
+ * So the ceiling is containment, not capacity. It is far above anything a
+ * legitimate site reaches, it is the same shape on every plan, and crossing
+ * it is an INCIDENT: the caller is expected to refuse the write, leave the
+ * billable counter alone, and make the trip visible to the site's managers
+ * and to staff. A ceiling that silently absorbed submissions would only move
+ * the free plan's lost-lead failure up to a bigger number.
+ *
+ * Evaluated against the same month counter the plan gate reads — which is
+ * Admin-SDK-only (`counters` is excluded from every client write in
+ * `cloud/firebase-firestore.rules`), so the count behind the ceiling cannot
+ * be lowered to launder past it.
+ */ export function checkFormSubmissionAbuseCeiling(org, usedThisMonth) {
+    const included = resolveOrgEntitlements(org).formSubmissionsPerMonth;
+    const ceiling = Number.isFinite(included) ? Math.max(FORM_ABUSE_CEILING_FLOOR, included * FORM_ABUSE_CEILING_MULTIPLE) : FORM_ABUSE_CEILING_UNLIMITED;
+    const used = Math.max(0, usedThisMonth);
+    return {
+        exceeded: used >= ceiling,
+        ceiling,
+        used
+    };
+}
+/**
+ * Average transfer per page view (HTML + JS + a few images), the constant
+ * that turns the analytics view counter into a bandwidth number and back.
+ *
+ * ## ⛔ HALF OF A PAIR. It moves with `perPageView`, or neither moves.
+ *
+ * This is the BYTES one page view weighs;
+ * {@link ORG_COGS_UNIT_RATES_USD}`.perPageView` is the DOLLARS the same page
+ * view costs. They are one physical measurement written in two units, and
+ * what every `bandwidthGb` band is actually sized against is neither of them
+ * alone but their quotient — `(1 GB ÷ this) × perPageView`, the cost of a
+ * gigabyte. That quotient is stable even while the page's weight is not,
+ * which is precisely why moving one half re-prices every band on the ladder
+ * without touching a band: a heavier page costs more per view and buys fewer
+ * views per gigabyte, and the two cancel.
+ *
+ * Both are therefore stated against the SAME weight — **1012.8 KB**, the
+ * basis recorded in `tools/tenant-page-budget.json` and recoverable from the
+ * rate itself — and `npm run check:page-view-rate` compares the two and
+ * refuses a mismatch. There is no version of this constant that is correct
+ * against a `perPageView` calibrated for a different page.
+ *
+ * The basis is FIRST-PARTY encoded bytes at settle, because that is what an
+ * egress bill is denominated in: third-party tags leave someone else's
+ * network and cost the platform nothing, so counting them here would inflate
+ * a customer's measured bandwidth with bytes nobody pays us for.
+ *
+ * Lives HERE rather than beside the metering rates (AGL-2155). It used to sit
+ * in `apps/console/utils/usage-metering.ts`, which the console imports and the
+ * tenant app cannot — and the bandwidth ceiling below has to be evaluated in
+ * the tenant app, at the beacon that writes the counter. Re-deriving the
+ * conversion there would have been a fourth hand-rolled copy of
+ * `× 1024³ / page weight`, which is the exact drift AGL-1371 collapsed into
+ * one function. `usage-metering` now re-exports these three, so every existing
+ * importer is unchanged and there is still one definition.
+ */ export const ESTIMATED_PAGE_TRANSFER_BYTES = 1012.8 * 1024;
+/**
+ * Bandwidth ⇄ page views: the one conversion three surfaces used to each
+ * write out by hand (AGL-1371).
+ *
+ * `bandwidthGb` is not a second cap next to metered page views — it IS the
+ * included band of the page-view meter, expressed in the unit customers
+ * understand. It is therefore used in both directions: forward by
+ * `meteredIncludedAllowance` to size the band the invoice subtracts, backward
+ * by the usage-alerts cron and the console meter to render live page views as
+ * GB.
+ */ export function pageViewsFromBandwidthGb(bandwidthGb) {
+    return bandwidthGb * 1024 * 1024 * 1024 / ESTIMATED_PAGE_TRANSFER_BYTES;
+}
+/** @see pageViewsFromBandwidthGb — the same constant, the other way. */ export function bandwidthGbFromPageViews(pageViews) {
+    return Math.max(0, Number(pageViews) || 0) * ESTIMATED_PAGE_TRANSFER_BYTES / (1024 * 1024 * 1024);
+}
+/**
+ * How far past a plan's own included bandwidth the abuse ceiling sits
+ * (AGL-2155). Three times the bandwidth the customer bought is not growth; it
+ * is an upgrade conversation, or it is not the customer's traffic at all.
+ *
+ * It is a CAP, not a price, and it is lower than {@link
+ * FORM_ABUSE_CEILING_MULTIPLE} because bandwidth is the largest cost line the
+ * platform carries and the one a stranger can spend on the customer's behalf.
+ * Past the band every 1,000 views bills $0.21 against about $0.16 of real
+ * cost, so the tail is no longer a loss — but a scraper, a hotlinked asset or
+ * a botnet still bills the account holder for traffic they did not ask for,
+ * and the ceiling is what bounds that before staff look at it. At 10× the
+ * band that tail was open-ended on Agency; at 3× it is bounded.
+ */ export const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
+/**
+ * Absolute floor for the bandwidth ceiling, in PAGE VIEWS per month, so the
+ * small plans get real headroom instead of a second, tighter plan limit
+ * wearing a different name.
+ *
+ * Free includes 2 GB ≈ 2,071 views; 3× would be ~6,212, which a genuinely
+ * successful hobby site (a post that lands on Hacker News) reaches in an
+ * afternoon and would be a miserable first experience of the platform.
+ * 100,000 views/month ≈ 96.6 GB ≈ **$16 of real COGS** at
+ * `METERED_UNIT_RATES_USD.perPageView` — well above the free band, and an
+ * order of magnitude below the $162 a million views costs. It is the number
+ * that makes "free stays free" true without making it stingy.
+ */ export const BANDWIDTH_ABUSE_CEILING_FLOOR = 100000;
+/**
+ * Ceiling for an org whose bandwidth band resolves to UNLIMITED — a
+ * contracted per-org override, since no plan row carries the sentinel any
+ * more — where a multiple has nothing to multiply. Kept at or above the
+ * ceiling of every finite band below it so the ladder never inverts and a
+ * bigger plan never inherits a smaller ceiling.
+ */ export const BANDWIDTH_ABUSE_CEILING_UNLIMITED = 500000000;
+/**
+ * Machine-readable marker for a bandwidth containment, so a capped response
+ * is distinguishable from the maintenance/lockdown notices it shares a shell
+ * with. Deliberately NOT a {@link LockdownReasonCode}: a lockdown is a staff
+ * takedown, this is a billing containment that clears itself at the month
+ * boundary with nobody doing anything.
+ */ export const BANDWIDTH_CEILING_CODE = 'bandwidth_ceiling';
+/**
+ * Per-site monthly bandwidth abuse ceiling (AGL-2155).
+ *
+ * ## The hole this closes
+ *
+ * Every other free dimension had a runtime brace — `mediaStorageGate`,
+ * `checkFormSubmissionQuota`, a zero band for dataset storage and API, a
+ * hard band for contacts. Bandwidth had **none**: nothing anywhere refused a
+ * page view, so a free site that went viral served a million views — roughly
+ * **$162 of real COGS** — with no wall, no throttle and no alert. It was
+ * protected only by the structural zero on the billing side (free carries no
+ * rate, so the invoice stays $0), which protects the *bill* and not the
+ * *bleeding*. `free-tier-never-billed.spec.ts` said so in its own table.
+ *
+ * ## Why an abuse ceiling and not a plan gate
+ *
+ * Exactly the distinction {@link checkFormSubmissionAbuseCeiling} draws, and
+ * for the same reason. A plan gate answers "did the customer buy this?" — and
+ * for a metered plan the answer past the band is *yes, and we bill it*. This
+ * answers "is this still a customer's traffic at all?", and crossing it is an
+ * INCIDENT rather than a quota: the site is flagged, staff are told, and the
+ * render path degrades to a static notice instead of paying ~40 Firestore
+ * reads and ~1,013 KB of egress per view.
+ *
+ * ## Where it is evaluated
+ *
+ * NOT in the render path. The page-view counter is written *after* the render
+ * by `/api/analytics/collect`; that route evaluates this on a sampled cadence
+ * and stamps `bandwidthCeiling` onto the host document. The render path reads
+ * that field off a host doc **it already loads** (`load-page-data.ts` reads
+ * `hostRes.host` for the lockdown branch), so the containment costs the happy
+ * path exactly zero extra reads.
+ *
+ * An edge/CDN rule would be the other natural home and is deliberately not
+ * the answer here: it is not a repo change, nothing in this suite could
+ * verify it, and it cannot see which plan a host is on.
+ */ export function checkBandwidthAbuseCeiling(org, usedPageViewsThisMonth) {
+    var _resolveOrgEntitlements_bandwidthGb;
+    const includedGb = (_resolveOrgEntitlements_bandwidthGb = resolveOrgEntitlements(org).bandwidthGb) != null ? _resolveOrgEntitlements_bandwidthGb : 0;
+    const includedViews = pageViewsFromBandwidthGb(includedGb);
+    const ceiling = Number.isFinite(includedViews) ? Math.max(BANDWIDTH_ABUSE_CEILING_FLOOR, Math.round(includedViews * BANDWIDTH_ABUSE_CEILING_MULTIPLE)) : BANDWIDTH_ABUSE_CEILING_UNLIMITED;
+    const used = Math.max(0, Number(usedPageViewsThisMonth) || 0);
+    return {
+        exceeded: used >= ceiling,
+        ceiling,
+        used
+    };
+}
+/**
+ * Does crossing the ceiling **degrade what visitors see**, or only raise the
+ * incident? (AGL-2155)
+ *
+ * Only on a plan that does NOT meter the infra pass-through — which today is
+ * free/hobby, where the requirement is that free always actually stays free.
+ * On free the traffic is uncompensated, so serving it is a
+ * straight loss and the least destructive way to stop the bleeding is to stop
+ * paying for the expensive render.
+ *
+ * On a metered plan the same traffic is *invoiced*, so taking a paying
+ * customer's site off the air would trade a bill they agreed to for an outage
+ * they did not. Their ceiling still trips, still flags the host and still
+ * escalates to staff — it just does not change what a visitor gets. Whether a
+ * paying host past its OWN ceiling should also be degraded is a product call
+ * and is left open on purpose; flipping it is this one function.
+ *
+ * Enterprise does not meter either, and is NOT degraded, for the same reason
+ * a metered plan is not: its traffic is paid for, by agreement rather than by
+ * invoice. Since 2026-09-07 its bandwidth band is a finite fallback (twice
+ * Agency's), so without this exclusion the ceiling an agreement never named
+ * would have taken a contracted customer's site off the air three times past
+ * a default nobody chose for them. It still trips, flags and pages.
+ */ export function bandwidthCeilingDegradesRender(org) {
+    return !planMetersInfraOverage(org) && !isCustomPricedPlan(resolvePlan(org));
+}
+/**
+ * Read the host document's containment flag, tolerantly. Returns null unless
+ * the flag is present, well-formed AND belongs to `month` — an August trip
+ * must not silence a September visitor.
+ */ export function normalizeHostBandwidthCeiling(host, month) {
+    var _raw_month, _raw_ceiling, _raw_used, _raw_trippedAtMs;
+    const raw = host == null ? void 0 : host['bandwidthCeiling'];
+    if (!raw || typeof raw !== 'object') return null;
+    if (String((_raw_month = raw.month) != null ? _raw_month : '') !== month) return null;
+    const ceiling = Number((_raw_ceiling = raw.ceiling) != null ? _raw_ceiling : 0);
+    if (!Number.isFinite(ceiling) || ceiling <= 0) return null;
+    return {
+        month,
+        ceiling,
+        used: Math.max(0, Number((_raw_used = raw.used) != null ? _raw_used : 0) || 0),
+        trippedAtMs: Math.max(0, Number((_raw_trippedAtMs = raw.trippedAtMs) != null ? _raw_trippedAtMs : 0) || 0),
+        degraded: raw.degraded === true
+    };
+}
+/**
+ * Is the render path required to serve the capped notice instead of the page?
+ *
+ * Both halves must hold: the flag is for THIS month, and the trip was
+ * recorded as one that degrades. `degraded` is written by the evaluator from
+ * {@link bandwidthCeilingDegradesRender} at trip time rather than re-derived
+ * here, so a host that upgrades mid-month is not still being degraded by a
+ * flag written while it was free — and, in the other direction, a flag from a
+ * paying host can never take that host down.
+ */ export function bandwidthCeilingDegradesHost(host, month) {
+    var _normalizeHostBandwidthCeiling;
+    return ((_normalizeHostBandwidthCeiling = normalizeHostBandwidthCeiling(host, month)) == null ? void 0 : _normalizeHostBandwidthCeiling.degraded) === true;
+}
+/** UTC `YYYY-MM`, the key both the beacon and the render path agree on. */ export function bandwidthCeilingMonthKey(now = new Date()) {
+    return now.toISOString().slice(0, 7);
+}
+/**
+ * Visitor-facing copy for a contained site. Says what happened and that it
+ * ends, and names nothing about the plan, the count or the owner — this is
+ * read by a stranger to the site, exactly like the form ceiling's refusal
+ * body (AGL-1666).
+ */ export function bandwidthCeilingNotice() {
+    return {
+        title: 'This site is temporarily unavailable',
+        body: 'It has served more traffic this month than its plan includes. It will be back at the start of next month, or sooner if the owner upgrades.'
+    };
+}
+function enforcementShape(atZero, atCeiling) {
+    if (!atZero && !atCeiling) return 'always-blocks';
+    if (atZero && atCeiling) return 'never-blocks';
+    return 'measure';
+}
+/**
+ * Enforcement shape of {@link checkDataStorageQuota} for this org, before
+ * anything has been measured. @see QuotaEnforcementShape
+ */ export function dataStorageEnforcementShape(org) {
+    return enforcementShape(checkDataStorageQuota(org, 0).allowed, checkDataStorageQuota(org, Number.MAX_SAFE_INTEGER).allowed);
+}
+/**
+ * Enforcement shape of {@link checkApiRequestQuota} for this org, before
+ * anything has been measured. @see QuotaEnforcementShape
+ */ export function apiRequestEnforcementShape(org) {
+    return enforcementShape(checkApiRequestQuota(org, 0).allowed, checkApiRequestQuota(org, Number.MAX_SAFE_INTEGER).allowed);
+}
+
+//# sourceMappingURL=plan-entitlements.js.map