@aglyn/aglyn 1.0.0-beta.218 → 1.0.0-beta.220

package/src/lib/app-utils/plan-entitlements.d.ts

@@ -189,11 +189,13 @@ type NonQuotaEntitlementKeys = 'planComp';
  * `Required` is over the CORE halves on purpose (AGL-3124). It is what keeps
  * a plan table honest — a plan that forgets a platform quota or a platform
  * gate does not compile — and that reasoning does not carry to a plugin's
- * key: a plugin's band comes from its own seat-add-on declaration, and
- * requiring it here would mean every plan row in the core naming every
- * installed plugin's keys, which is the arrangement the seam retires. So the
- * plugin halves join as declared: present once a plugin declares them, and
- * optional, because a workspace without the plugin has no value for them.
+ * key: a plugin's figure per plan comes from its own `plan-entitlements`
+ * declaration (AGL-3080), whose rows are typed per plan and so cannot forget
+ * one either, and requiring it here would mean every plan row in the core
+ * naming every installed plugin's keys, which is the arrangement the seam
+ * retires. So the plugin halves join as declared: present once a plugin
+ * declares them, and optional, because core compiles without the plugin's
+ * type and a workspace without the plugin has no value for them.
  *
  * They join in their MAPPED form (`PluginOrgQuotas`, `PluginOrgFeatures`)
  * because an intersection with a bare interface has no implicit string index
@@ -204,80 +206,6 @@ type NonQuotaEntitlementKeys = 'planComp';
 export type ResolvedOrgEntitlements = Required<Omit<CoreOrgEntitlements, 'features' | LegacyEntitlementKeys | RetiredEntitlementKeys | NonQuotaEntitlementKeys>> & PluginOrgQuotas & {
     features: Required<CoreOrgFeatureFlags> & PluginOrgFeatures;
 };
-/**
- * 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 declare 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 declare const FREE_AI_TASTE_CREDITS_PER_MONTH = 300;
 export declare const PLAN_ENTITLEMENTS: Record<OrgPlan, ResolvedOrgEntitlements>;
 /**
  * The tiers a customer can buy themselves — every plan EXCEPT `enterprise`
@@ -1002,6 +930,75 @@ export declare const INFRA_COGS_PER_SITE_USD = 2;
  * The console keeps importing it from `usage-metering` unchanged.
  */
 export declare const METERED_MARKUP = 1.3;
+/**
+ * What the CDN requests behind ONE page view cost once the platform is past
+ * its hosting plan's included request allowance, at the DEAREST region the
+ * CDN bills, in USD per view (AGL-1879, AGL-3444). A page view billed past a
+ * plan's band is priced at `(perPageView + this) × METERED_MARKUP` — $0.70
+ * per 1,000 — and every `bandwidthGb` band is sized with it counted.
+ *
+ * ## Why a page view needs a second cost term
+ *
+ * `perPageView` prices what a view WEIGHS: the bytes it transfers at the
+ * CDN's per-GB rate, plus the Firestore reads behind the render. The CDN also
+ * charges per REQUEST once the team's monthly allowance is spent — Vercel Pro
+ * includes 10,000,000 a month, then bills $2.00 to $3.20 per million by
+ * region. A cold load of `aglyn.com/` makes 57 first-party requests to settle
+ * (`tools/tenant-page-budget.json`, `wireCalibration.measuredAgainst`), so the
+ * allowance is about 175,000 views of that page a month, platform-wide —
+ * about 169 GB of included bandwidth — where the 1 TB transfer allowance
+ * lasts about 1.4 million. The request allowance runs out first.
+ *
+ * ## Why the dearest region
+ *
+ * The CDN bills a request, and the bytes it transfers, in the region that
+ * SERVES it — the one nearest the visitor — so a site whose audience is in
+ * São Paulo or Cape Town costs what those regions cost, and nothing about a
+ * plan can choose otherwise. The platform's rule is that no plan is under
+ * water at any utilization and that "at cost + 30%" is true of every billed
+ * unit, so both terms of a page view are priced where the CDN is dearest:
+ * transfer at $0.35 per GB (in `perPageView`) and requests at $3.20 per
+ * million (here). Past the allowance a view then costs:
+ *
+ * |                                   | weight     | requests  | cost / 1k | margin at $0.70 |
+ * |-----------------------------------|------------|-----------|-----------|-----------------|
+ * | the page as measured (748.5 KB)   | $0.262148  | $0.182400 | $0.4445   | +36.5%          |
+ * | the priced basis (1012.8 KB)      | $0.354715  | $0.182400 | $0.5371   | +23.3%          |
+ *
+ * — at least 30% over cost in every region, which is the claim `/pricing`
+ * makes.
+ *
+ * ## The figure
+ *
+ * $0.00018374681 is 57.42 requests at $3.20 per million — the measured 57,
+ * with the basis set ABOVE the measurement as the weight basis is — pinned so
+ * the billed price lands on a whole cent: ($0.354715 + $0.1824) × 1.3 is
+ * $0.6982 per 1,000, rounded up to $0.70, and ($0.354715 + $0.183747) × 1.3
+ * is exactly $0.70. Published as "Our cost $0.538462 / You pay $0.70", the
+ * "at cost + 30%" claim stays true of the cost a billed view incurs in the
+ * dearest region, and so in every other.
+ *
+ * ## ⛔ Not in {@link ORG_COGS_UNIT_RATES_USD}, deliberately
+ *
+ * `perPageView` is half of a pair with `ESTIMATED_PAGE_TRANSFER_BYTES` — one
+ * page weight in dollars and in bytes — and `npm run check:page-view-rate`
+ * recovers that weight from the rate. A per-request charge is not
+ * proportional to weight, so folding it into `perPageView` would make the
+ * gate read a page nobody serves.
+ *
+ * ## The INCLUDED bands carry it too
+ *
+ * A view inside a plan's band makes the same requests as one past it, and
+ * once the platform is past the allowance the CDN bills them either way, so
+ * the `bandwidthGb` bands are sized with this term counted: $0.190 per
+ * included GB on top of $0.367 of weight. `tier-margin-floor.spec.ts`
+ * multiplies it in and pins every tier at 100% of every band.
+ *
+ * Lives HERE, beside the markup, for the reason the markup does: the
+ * `/pricing` generator publishes the cost column from it and cannot import
+ * anything under `apps/console`.
+ */
+export declare const PAGE_VIEW_CDN_REQUEST_COST_USD = 0.00018374681;
 /**
  * Monthly unit costs for the meters the rollup already records (AGL-1134).
  *
@@ -1025,6 +1022,23 @@ export declare const METERED_MARKUP = 1.3;
  * 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.
+ * A page view billed past its band also carries
+ * {@link PAGE_VIEW_CDN_REQUEST_COST_USD}, which neither table holds: it is
+ * the per-request CDN charge past the hosting plan's allowance, and this
+ * table's `perPageView` is the weight-proportional half of what a band is
+ * sized against — the request term is the other.
+ *
+ * ## Every Vercel-billed input is priced at Vercel's dearest region
+ *
+ * The CDN and functions bill by region, from $0.15 to $0.35 per GB of
+ * transfer, $2.00 to $3.20 per million requests, and $0.128 to $0.221 per
+ * hour of active CPU (memory $0.0106 to $0.0183 per GB-hour), and a plan
+ * cannot choose where its visitors are. So the Vercel share of every rate
+ * here is priced at the dearest region (AGL-3444): the transfer inside
+ * `perPageView`, the function invocation inside `perFormSubmission`, and the
+ * compute inside `perRun`. The GCP shares — object and Firestore storage, and
+ * the Firestore reads and writes behind a render, a submission or a run —
+ * are priced as they were.
  *
  * Everything else here is a cost-model input ONLY. `dataStoragePerGbMonth`,
  * `perApiRequest`, `perContactMonth` and `perEmailSend` price what an org
@@ -1034,9 +1048,11 @@ export declare const METERED_MARKUP = 1.3;
  * "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
+ * $0.026 and form submissions $0.0005 → $0.00005 — `perPageView` was
+ * re-pegged 2026-09-09 (AGL-2711), from $0.0001 to $0.00016153846, and the
+ * last two were re-priced at Vercel's dearest region on 2026-10-01
+ * (AGL-3444): page views $0.00035471473, form submissions $0.000053846154.
+ * 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.
  *
@@ -1057,8 +1073,8 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      * ⛔ 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.
+     * the cost of a gigabyte's weight, and that — with the request term — is
+     * what every bandwidthGb band on the ladder is sized against.
      */
     perPageView: number;
     perFormSubmission: number;
@@ -1082,7 +1098,7 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      */
     perEmailSend: number;
     /**
-     * One workflow or action run — $12 per million.
+     * One workflow or action run — $13 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
@@ -1101,9 +1117,11 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      *   - 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
+     *     for the expression evaluation, about $0.000001 in the cheapest
+     *     region and $0.0000017 in the dearest ($0.221 against $0.128 an
+     *     hour of active CPU), which is where it is priced
      *
-     * $0.0000118, carried as $0.000012. It scales with the catalog a site holds
+     * $0.0000125, carried as $0.000013. 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.
@@ -1115,36 +1133,24 @@ export declare const ORG_COGS_UNIT_RATES_USD: {
      */
     perRun: number;
 };
-/** The rollup fields `orgMonthlyCogsUsd` prices. All optional and all absent-safe. */
+/**
+ * The rollup fields `orgMonthlyCogsUsd` prices. All optional and all
+ * absent-safe.
+ *
+ * The named fields are the platform's own meters. A plugin's meter rides the
+ * index signature under the rollup field its declaration names
+ * (`plugin-usage-axes.ts`): the AI plugin's provider spend, the CRM's
+ * records, the forms plugin's submissions, the workflows plugin's runs.
+ */
 export interface OrgUsageRollupInput {
     hostCount?: number | null;
     storageGb?: number | null;
     pageViews?: number | null;
-    formSubmissions?: number | null;
     dataStorageMb?: number | null;
     apiRequests?: number | null;
-    /**
-     * Contacts alone — the figure every rollup carried before AGL-2611 widened
-     * the band, kept so a month written under the old basis still prices.
-     * Read only when `crmRecordsCount` is absent; see it.
-     */
-    contactsCount?: number | null;
-    /**
-     * Contacts + companies + deals, the CRM records band's own figure
-     * (AGL-2611). Priced at `perContactMonth` — the rate was measured on a
-     * contact, which is the most expensive of the three to hold, so it
-     * over-covers a company or a deal rather than under-pricing one. When
-     * present it REPLACES `contactsCount` in the model rather than adding to
-     * it: the contacts are inside this sum, and a model that priced both
-     * would charge the same people twice.
-     */
-    crmRecordsCount?: number | null;
-    /** The components of `crmRecordsCount`, recorded so the sum is legible. */
-    companiesCount?: number | null;
-    dealsCount?: number | null;
     /**
      * Every email the org sent this month, campaigns and transactional alike —
-     * the `emailSends` cost meter, not `campaignEmailSends`.
+     * the `emailSends` cost meter, not the campaign meter.
      *
      * The cost meter is the right input precisely because the campaign meter is
      * the one with a cap on it. What this org cost us is every message the
@@ -1153,24 +1159,13 @@ export interface OrgUsageRollupInput {
      */
     emailSends?: number | null;
     /**
-     * Aglyn Assist provider spend for the month, ALREADY IN DOLLARS (AGL-2280).
-     *
-     * Unlike every other field here this is not a meter to be priced — it is
-     * `orgs/{id}/assistUsage/{month}.estCostUsd`, our own cost estimate at the
-     * provider's list rates, computed where the tokens were counted. So it
-     * enters the model at ×1 and has no entry in `ORG_COGS_UNIT_RATES_USD`;
-     * inventing a second per-token rate here is precisely the drift AGL-1134
-     * removed.
+     * A plugin's meter, by the rollup field its declaration names. `unknown`
+     * because a rollup document carries its month and its audit fields beside
+     * the meters, and a caller may hand the document over whole; every meter
+     * is read through `declaredMeterReading`, which prices only a positive
+     * finite number.
      */
-    assistCostUsd?: number | null;
-    /**
-     * Workflow and action runs this month — the two counters `report-usage`
-     * sums across the org's hosts. Priced together at `perRun`: a run is the
-     * same handful of reads, two writes and a moment of compute whichever
-     * builder produced it, and the bands differ only in which tier sells them.
-     */
-    workflowRuns?: number | null;
-    actionRuns?: number | null;
+    [field: string]: unknown;
 }
 export interface OrgCogsResult {
     /** What the guardrail should charge against revenue. */
@@ -1226,9 +1221,9 @@ export declare function orgMonthlyCogsUsd(rollup: OrgUsageRollupInput | null | u
  * 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.
+ * `apiRequests` and `emailSends` are counts FOR THE MONTH. A plugin's fields
+ * carry the unit its cost-axis declaration states — a monthly count, a
+ * point-in-time level, or dollars.
  */
 export declare function orgCogsInputFrom(source: Record<string, unknown> | null | undefined): OrgUsageRollupInput;
 /**
@@ -1678,10 +1673,10 @@ export declare function checkHostRegisterQuota(org: Partial<AglynOrgBilling> | n
  */
 export declare function resolveTransactionFeePct(org: Partial<AglynOrgBilling> | null | undefined, productType: 'physical' | 'digital' | 'service'): number;
 /**
- * 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.
+ * Stripe's processing cost on ONE destination-charge sale, in cents
+ * (AGL-2152) — a storefront order, a booking deposit — 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
@@ -1707,18 +1702,18 @@ export declare function resolveTransactionFeePct(org: Partial<AglynOrgBilling> |
  * 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.
+ * reasoning the marketplace listing floor applies; both are defined from the
+ * SAME processing 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
+ * `SALE_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.
  */
-export declare function storefrontProcessingCostCents(chargeCents: number): number;
+export declare function saleProcessingCostCents(chargeCents: number): number;
 /**
  * The Stripe Connect `application_fee_amount` for ONE storefront sale
  * (AGL-2152) — the platform's advertised take PLUS Stripe's processing cost,
@@ -1751,7 +1746,7 @@ export declare function resolveTransactionFeeCents(org: Partial<AglynOrgBilling>
  *
  * 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
+ * fixed 30¢ that `saleProcessingCostCents` adds in cents has to be
  * folded into the rate. `(rate × amount + fixed) ÷ amount` is, with the
  * amount cancelled,
  *
@@ -1768,10 +1763,10 @@ export declare function resolveTransactionFeeCents(org: Partial<AglynOrgBilling>
  * 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
+ * the one-time path, so repointing `SALE_PROCESSING_PERCENT` moves
  * both surfaces together. Zero for a charge that is not a charge.
  */
-export declare function storefrontProcessingPassThroughPercent(amountCents: number): number;
+export declare function saleProcessingPassThroughPercent(amountCents: number): number;
 /**
  * The `application_fee_percent` for ONE storefront subscription (AGL-2655):
  * the plan's advertised take PLUS Stripe's processing cost as a percent —
@@ -1818,163 +1813,45 @@ export declare function resolveMarketplaceFeePct(org: Partial<AglynOrgBilling> |
  */
 export declare function bindingMarketplaceFeePct(): number;
 /**
- * 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.
+ * What one destination-charge sale costs the PLATFORM to process (AGL-2343):
+ * a storefront order, a booking deposit, a marketplace listing. On a
+ * destination charge Stripe debits its fee from the PLATFORM's balance, so
+ * every surface that sells through the platform's account prices its take
+ * against these.
  *
- * 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.
+ * NONE OF THESE IS AN AGLYN PRICE. They are Stripe's published US rates, and
+ * they exist only as inputs to a platform take and to figures a seller reads;
+ * changing one never changes a price list.
  *
  * 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 declare const MARKETPLACE_PROCESSING_PERCENT_CARD = 2.9;
+ * alongside `card`, `cashapp`, `link`, `amazon_pay` and `apple_pay`, and no
+ * checkout session pins `payment_method_types`, so a buyer may pay by either.
+ * A cost computed from the cheapest method would be wrong exactly when it
+ * mattered.
+ */
+export declare const CARD_PROCESSING_PERCENT = 2.9;
 /** Klarna/Affirm, roughly. See the note above — this is the binding one. */
-export declare const MARKETPLACE_PROCESSING_PERCENT_BNPL = 6;
+export declare const BNPL_PROCESSING_PERCENT = 6;
 /** Stripe's per-transaction fixed component, in cents. */
-export declare 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 declare 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 declare const STOREFRONT_PROCESSING_PERCENT = 6;
+export declare const PROCESSING_FIXED_CENTS = 30;
+/**
+ * The processing rate a storefront or booking destination charge is priced
+ * against (AGL-2152), and the one identifier to repoint if those sessions'
+ * payment method set changes.
+ *
+ * Deliberately its OWN name rather than a direct use of the binding rate,
+ * while being defined as it: every seller shares Stripe's published rates and
+ * today shares the platform's payment method configuration, but each surface
+ * is a separate product decision. A future choice to pin
+ * `payment_method_types` on storefront sessions to the card family — and so
+ * to recover at `CARD_PROCESSING_PERCENT` — must not silently lower the
+ * marketplace listing floor, which is derived from the binding rate for a
+ * different flow.
+ */
+export declare const SALE_PROCESSING_PERCENT = 6;
 /** Stripe's per-transaction fixed component, in cents. Not rate-dependent. */
-export declare const STOREFRONT_PROCESSING_FIXED_CENTS = 30;
-/** Where the money goes on one sale of a paid listing (AGL-2343). */
-export interface MarketplaceSaleEconomics {
-    /** The listing price. */
-    priceCents: number;
-    /** Added on top, and owed to the state. */
-    taxCents: number;
-    /** What the buyer is charged. */
-    buyerPaysCents: number;
-    /** `transfer_data[amount]` — the seller's share of the pre-tax price. */
-    sellerReceivesCents: number;
-    /** The platform's take. */
-    platformFeeCents: number;
-    /** Stripe's fee, debited from the platform on a destination charge. */
-    processingCents: number;
-    /** `platformFeeCents - processingCents`. Negative is a loss on the sale. */
-    platformNetCents: number;
-}
-/**
- * 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 declare function marketplaceSaleEconomics(priceUsd: number, feePercent: number, processingPercent?: number): MarketplaceSaleEconomics;
-/**
- * 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 declare function marketplaceBreakEvenUsd(feePercent?: number, processingPercent?: number): number;
-/**
- * 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 declare function marketplaceMinPriceUsd(): number;
-/**
- * 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 declare function isBelowMarketplacePriceFloor(priceUsd: unknown): boolean;
-/**
- * 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 declare function marketplacePriceCostNote(priceUsd: unknown): string | undefined;
-/**
- * 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 declare function marketplacePriceFloorHint(suffix?: string): string;
+export declare const SALE_PROCESSING_FIXED_CENTS = 30;
 /**
  * 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
@@ -2033,6 +1910,15 @@ export { PLATFORM_BRANDING_PROFILE } from './platform-brand';
  * 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.
+ *
+ * An org WITH the entitlement that has stored no brand value at all gets the
+ * full Aglyn brand too (AGL-3440). The entitlement is the right to a brand,
+ * not a brand: until the org sets one, every name it shows is the platform's
+ * anyway, so the white-label profile's blanks — no logo, no support link, no
+ * home — conceal nothing and only strip the platform's own header and footer
+ * from mail whose every line already names the platform. Every Enterprise
+ * org carries the entitlement, Aglyn's own included. One field set, and the
+ * rules below apply.
  */
 export declare function resolveBrandingProfile(org: Partial<AglynOrgBilling> | null | undefined): ResolvedBrandingProfile;
 /**
@@ -2545,7 +2431,9 @@ export declare function checkFormSubmissionAbuseCeiling(org: Partial<AglynOrgBil
  * 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,
+ * gigabyte's WEIGHT, to which the band sizing adds the CDN requests the same
+ * views make ({@link PAGE_VIEW_CDN_REQUEST_COST_USD}). 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.
@@ -2593,11 +2481,13 @@ export declare function bandwidthGbFromPageViews(pageViews: number): number;
  * 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.
+ * Past the band every 1,000 views bills $0.70 against at most $0.54 of real
+ * cost — the dearest region's — once the CDN's request allowance is spent
+ * ({@link PAGE_VIEW_CDN_REQUEST_COST_USD}), so the tail is not 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 declare const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
 /**
@@ -2608,9 +2498,10 @@ export declare const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
  * 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
+ * 100,000 views/month ≈ 96.6 GB ≈ **$54 of real COGS** at the dearest
+ * region (`METERED_UNIT_RATES_USD.perPageView` plus
+ * `PAGE_VIEW_CDN_REQUEST_COST_USD`) — well above the free band, and an order
+ * of magnitude below the $538 a million views costs. It is the number
  * that makes "free stays free" true without making it stingy.
  */
 export declare const BANDWIDTH_ABUSE_CEILING_FLOOR = 100000;
@@ -2731,14 +2622,24 @@ export declare function normalizeHostBandwidthCeiling(host: Record<string, any>
 /**
  * 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.
+ * Three things must hold: the flag is for THIS month, the trip was recorded
+ * as one that degrades, and the org's CURRENT plan still degrades.
+ *
+ * The stored `degraded` alone cannot answer the last one. It is written once,
+ * at trip time, and nothing rewrites it: the beacon stops evaluating a host
+ * once it has tripped this month, and a contained site serves no pages to
+ * beacon from. So a host that upgraded mid-month stayed on the notice until
+ * the 1st, while the owner notice and the visitor notice both promised an
+ * upgrade would bring it back. Re-deriving from `org` on every read releases
+ * it on the next org-doc TTL with no write, the same asymmetry
+ * `bandwidthCapEngaged` keeps for the plan band.
+ *
+ * Both halves still hold in the other direction: a flag written for a paying
+ * host (`degraded: false`) can never take that host down, whatever its plan
+ * becomes later. An unknown org (`null`) resolves as unmetered, so a lookup
+ * failure keeps the containment rather than lifting it.
  */
-export declare function bandwidthCeilingDegradesHost(host: Record<string, any> | null | undefined, month: string): boolean;
+export declare function bandwidthCeilingDegradesHost(host: Record<string, any> | null | undefined, month: string, org: Partial<AglynOrgBilling> | null | undefined): boolean;
 /** UTC `YYYY-MM`, the key both the beacon and the render path agree on. */
 export declare function bandwidthCeilingMonthKey(now?: Date): string;
 /**