/**
 * The plans a licence can grant.
 *
 * Reconciled 2026-09-09 against the code that actually mints keys, editor-api's
 * `common/license-utils.js`, and revised 2026-09-14 when the tier vocabulary was
 * settled. `requiresLicense` issues a key for exactly the paid plans, lowercased
 * from the Stripe product's `plan_type` metadata, falling back to `pro`.
 *
 * `community` is in this type but will never appear in a key, deliberately:
 * that tier is issued none, so the Community state IS the unlicensed state.
 * Keeping it in the ordering gives `planAtLeast('community')` the useful
 * meaning "holds any licence at all", which is a real gate even though no
 * payload carries the word.
 *
 * `oem` was called `enterprise` until 2026-09-14. It was renamed because
 * "Enterprise" already names a shipped package, `apex-grid-enterprise`, which is
 * sold one tier lower on Premium, so the word pointed at two different things.
 * See `docs/licence-naming-audit.md` in the `apexcharts/website` repo. Old keys are covered by PLAN_ALIASES.
 *
 * `embedded` and `oem` are in this type but should not appear in a key issued
 * from now on, for the same reason `community` never does: neither is a feature
 * tier. They are redistribution overlays sold alongside a per-developer licence,
 * and it is that licence the key carries. They stay in the vocabulary so a key
 * that does carry one is ranked rather than fail-opened. See `RANK`.
 */
export type ApexPlan = 'community' | 'embedded' | 'oem' | 'premium' | 'pro';
/**
 * Every plan string a key may carry, in commercial ladder order.
 *
 * This is NOT the gating order. `RANK` is, and the last three entries share a
 * rank. See the note on `RANK` for why.
 */
export declare const PLAN_ORDER: readonly ApexPlan[];
/**
 * Plan strings that may exist in already-issued keys but are not plan names.
 *
 * Exactly one entry, and the bar for a second one is high.
 *
 * `enterprise` is the old name for `oem`, renamed 2026-09-14. This is the one
 * kind of entry that belongs here: a mapping we performed ourselves and can
 * state exactly, not an inference about what a string looks like it ought to
 * mean. It is cheap insurance for hand-minted keys, which
 * `libs/commons/LICENSING.md` section 5 documents being issued with
 * `--plan enterprise` for offline contracts, comps and conference demos, and
 * which never touch the database and so can never be enumerated. Without it
 * such a key would still work, via the fail-open branch in `planAtLeast`, but
 * it would be granted everything rather than its actual rank.
 *
 * The other known source of off-vocabulary strings stays unmapped, on purpose:
 * `tools/scripts/licence-generator.js`, the manual signing tool, whose `--plan`
 * used to default to `standard` and accept any string at all. Production never
 * emitted `standard` or `trial`, and the script now requires an explicit plan
 * and validates it, so no new key can carry one. Nothing records which customer
 * holds an old one, so mapping `standard` to a rank would be a guess that could
 * lock someone out of what they paid for. The fail-open branch handles those.
 *
 * Add an entry only from the issued-key record, never from what a string looks
 * like it ought to mean.
 */
export declare const PLAN_ALIASES: Readonly<Record<string, ApexPlan>>;
/**
 * Resolve a raw `LicenseData.plan` string to a known plan.
 *
 * Case and surrounding space are ignored, because a plan string is typed by a
 * human at issuance. Returns `null` for anything not a SKU name or a mapped
 * alias; callers must decide what an unknown plan means rather than guess here.
 */
export declare function normalisePlan(raw: null | string | undefined): ApexPlan | null;
/**
 * The plan the current licence grants, or `null` when there is no valid licence
 * or its plan string is not recognised.
 *
 * `null` is two different situations on purpose: use `planAtLeast` to gate, and
 * this only to display. Anything that renders this must cope with `null`.
 */
export declare function currentPlan(): ApexPlan | null;
/**
 * Whether the current licence covers a feature needing at least `required`.
 *
 * Three outcomes, and the third is the important one:
 *
 * 1. No valid licence: `false`, always. This is the one hard boundary, and it
 *    is the same verdict that already drives the watermark.
 * 2. Valid licence with a recognised plan: rank comparison.
 * 3. Valid licence with an UNRECOGNISED plan: `true`, and the string is warned
 *    about once.
 *
 * Case 3 is fail-open by choice. The holder has a signed, unexpired key, so
 * they paid for something; denying them a feature over a string we failed to
 * map is a support incident and a refund conversation, while granting one is a
 * feature given to an existing customer. Client-side gating here is deterrence
 * and honest-customer compliance, not DRM, so the asymmetry is not close. It
 * also means switching gating on cannot downgrade anyone before PLAN_ALIASES is
 * reconciled against the issued-key record.
 *
 * Never throws, and never awaits: products call this during render.
 */
export declare function planAtLeast(required: ApexPlan): boolean;
//# sourceMappingURL=tier.d.ts.map