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

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

@@ -223,7 +223,7 @@ export const PLAN_ENTITLEMENTS = {
             scheduledPublishing: 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
+            // level-2 answers and the copy assistant — and starts at Starter; 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
@@ -294,7 +294,8 @@ export const PLAN_ENTITLEMENTS = {
         managersPerOrg: 2,
         maxManagersPerOrg: 5,
         maxMembersPerHost: 10,
-        bandwidthGb: 50,
+        // Sized by the same annual-price invariant as Pro's — see that band.
+        bandwidthGb: 20,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: 25,
         functionsPerHost: 10,
@@ -398,20 +399,26 @@ export const PLAN_ENTITLEMENTS = {
         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.
+        // Page views are the largest term of this tier's modeled COGS. One GB is
+        // 1,035 views at `ESTIMATED_PAGE_TRANSFER_BYTES`, priced where the CDN is
+        // dearest because it bills in the region that serves a visitor: $0.367 of
+        // weight (`perPageView`, transfer at $0.35 a GB) and $0.190 of CDN
+        // requests once the hosting plan's monthly allowance is spent
+        // (`PAGE_VIEW_CDN_REQUEST_COST_USD`, $3.20 per million). So a GB of
+        // included bandwidth costs $0.557, and 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.
+        // and one-to-one email terms counted — the 2026-09-07 pricing decision —
+        // at that all-in gigabyte (AGL-3444). 35 GB is what it carries; every
+        // paid band on the ladder is sized the same way.
         // `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,
+        bandwidthGb: 35,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: 100,
         functionsPerHost: 50,
@@ -503,7 +510,7 @@ export const PLAN_ENTITLEMENTS = {
         maxManagersPerOrg: 100,
         maxMembersPerHost: 100,
         // Sized by the same annual-price invariant as Pro's — see that band.
-        bandwidthGb: 185,
+        bandwidthGb: 55,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: 1000,
         functionsPerHost: 250,
@@ -574,7 +581,8 @@ export const PLAN_ENTITLEMENTS = {
         managersPerOrg: 25,
         maxManagersPerOrg: 150,
         maxMembersPerHost: 150,
-        bandwidthGb: 290,
+        // Sized by the same annual-price invariant as Pro's — see that band.
+        bandwidthGb: 90,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: 5000,
         functionsPerHost: 500,
@@ -642,7 +650,8 @@ export const PLAN_ENTITLEMENTS = {
         managersPerOrg: 50,
         maxManagersPerOrg: 250,
         maxMembersPerHost: 250,
-        bandwidthGb: 345,
+        // Sized by the same annual-price invariant as Pro's — see that band.
+        bandwidthGb: 105,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: UNLIMITED,
         functionsPerHost: 1000,
@@ -714,7 +723,8 @@ export const PLAN_ENTITLEMENTS = {
         managersPerOrg: 100,
         maxManagersPerOrg: 500,
         maxMembersPerHost: 1000,
-        bandwidthGb: 1540,
+        // Sized by the same annual-price invariant as Pro's — see that band.
+        bandwidthGb: 485,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: UNLIMITED,
         functionsPerHost: UNLIMITED,
@@ -823,7 +833,7 @@ export const PLAN_ENTITLEMENTS = {
         managersPerOrg: 200,
         maxManagersPerOrg: 1000,
         maxMembersPerHost: 2000,
-        bandwidthGb: 3080,
+        bandwidthGb: 970,
         formsPerHost: FORMS_PER_HOST_CEILING,
         variablesPerHost: UNLIMITED,
         functionsPerHost: UNLIMITED,
@@ -1758,6 +1768,74 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
  *
  * The console keeps importing it from `usage-metering` unchanged.
  */ export 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 const PAGE_VIEW_CDN_REQUEST_COST_USD = 0.00018374681;
 /**
  * Monthly unit costs for the meters the rollup already records (AGL-1134).
  *
@@ -1781,6 +1859,23 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.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
@@ -1790,9 +1885,11 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.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.
  *
@@ -1812,10 +1909,10 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
    * ⛔ 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,
+   * 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: 0.00035471473,
+    perFormSubmission: 0.000053846154,
     /** Firestore-backed dataset bytes — an order pricier than object storage. */ dataStoragePerGbMonth: 0.18,
     perApiRequest: 0.000002,
     perContactMonth: 0.0002,
@@ -1834,7 +1931,7 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
    * both concern a smaller quantity; this is the whole bill.
    */ perEmailSend: 0.0009,
     /**
-   * 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
@@ -1853,9 +1950,11 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
    *   - 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.
@@ -1864,7 +1963,7 @@ export const STRIPE_PROCESSOR_FEE_FIXED_USD = 0.3;
    * 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
+   */ perRun: 0.000013
 };
 /**
  * The unit rate a declared cost axis names, or 1 where it names none (the
@@ -2773,10 +2872,10 @@ function resolvePlan(org) {
     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.
+ * 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
@@ -2802,23 +2901,23 @@ function resolvePlan(org) {
  * 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.
- */ // `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) {
+ */ // `SALE_PROCESSING_PERCENT` and `SALE_PROCESSING_FIXED_CENTS` are declared
+// beside the 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 saleProcessingCostCents(chargeCents) {
     if (!Number.isFinite(chargeCents) || chargeCents <= 0) return 0;
-    return Math.ceil(chargeCents * STOREFRONT_PROCESSING_PERCENT / 100) + STOREFRONT_PROCESSING_FIXED_CENTS;
+    return Math.ceil(chargeCents * SALE_PROCESSING_PERCENT / 100) + SALE_PROCESSING_FIXED_CENTS;
 }
 /**
  * The Stripe Connect `application_fee_amount` for ONE storefront sale
@@ -2852,7 +2951,7 @@ export function storefrontProcessingCostCents(chargeCents) {
     // 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));
+    return Math.min(charge, take + saleProcessingCostCents(charge));
 }
 /**
  * Stripe's processing cost on a RECURRING charge of `amountCents`, as the
@@ -2860,7 +2959,7 @@ export function storefrontProcessingCostCents(chargeCents) {
  *
  * 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,
  *
@@ -2877,15 +2976,15 @@ export function storefrontProcessingCostCents(chargeCents) {
  * 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 function storefrontProcessingPassThroughPercent(amountCents) {
+ */ export function saleProcessingPassThroughPercent(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);
+    const rateHundredths = Math.round(SALE_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;
+    const fixedHundredths = SALE_PROCESSING_FIXED_CENTS * 10000 / amount;
     return Math.min(100, Math.ceil(rateHundredths + fixedHundredths) / 100);
 }
 /**
@@ -2910,7 +3009,7 @@ export function storefrontProcessingCostCents(chargeCents) {
     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);
+    const passThrough = saleProcessingPassThroughPercent(amount);
     return Math.min(100, (Math.round(take * 100) + Math.round(passThrough * 100)) / 100);
 }
 /**
@@ -2960,180 +3059,40 @@ export function storefrontProcessingCostCents(chargeCents) {
     }).filter((pct)=>Number.isFinite(pct) && pct > 0));
 }
 /**
- * What one marketplace sale costs the PLATFORM to process (AGL-2343).
+ * 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.
  *
- * 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.
+ * 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 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}` : '');
-}
+ * 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 const CARD_PROCESSING_PERCENT = 2.9;
+/** Klarna/Affirm, roughly. See the note above — this is the binding one. */ export const BNPL_PROCESSING_PERCENT = 6;
+/** Stripe's per-transaction fixed component, in cents. */ export 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 const SALE_PROCESSING_PERCENT = BNPL_PROCESSING_PERCENT;
+/** Stripe's per-transaction fixed component, in cents. Not rate-dependent. */ export const SALE_PROCESSING_FIXED_CENTS = PROCESSING_FIXED_CENTS;
 /**
  * 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
@@ -3193,10 +3152,22 @@ export { PLATFORM_BRANDING_PROFILE } from "./platform-brand.js";
  * 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 function resolveBrandingProfile(org) {
     var _ref, _cleanBrandString, _cleanBrandString1, _cleanBrandString2, _cleanBrandString3, _cleanBrandString4, _cleanBrandString5, _cleanBrandString6, _cleanBrandString7, _cleanBrandString8, _cleanBrandString9, _cleanBrandString10;
     if (!checkEntitlement(org, 'whiteLabel')) return PLATFORM_BRANDING_PROFILE;
     const profile = (_ref = org == null ? void 0 : org.brandingProfile) != null ? _ref : {};
+    if (!Object.values(profile).some((value)=>cleanBrandString(value) !== undefined)) {
+        return PLATFORM_BRANDING_PROFILE;
+    }
     return {
         productName: (_cleanBrandString = cleanBrandString(profile.productName)) != null ? _cleanBrandString : PLATFORM_BRANDING_PROFILE.productName,
         // NO FALLBACK — and this became load-bearing the moment
@@ -3781,7 +3752,9 @@ export function checkQuota(org, quota, currentUsage) {
  * 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.
@@ -3830,11 +3803,13 @@ export function checkQuota(org, quota, currentUsage) {
  * 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 const BANDWIDTH_ABUSE_CEILING_MULTIPLE = 3;
 /**
  * Absolute floor for the bandwidth ceiling, in PAGE VIEWS per month, so the
@@ -3844,9 +3819,10 @@ export function checkQuota(org, quota, currentUsage) {
  * 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 const BANDWIDTH_ABUSE_CEILING_FLOOR = 100000;
 /**