@percayso-community/cayso-contracts 0.23.0

package/dist/marketplace-settlement.d.ts

@@ -0,0 +1,298 @@
+/**
+ * `marketplace-settlement` — the two money-grade marketplace operations Piper calls,
+ * their requests, their answers and their closed refusal unions (CAY-0082 §7,
+ * CAY-0083 §3).
+ *
+ * Piper presents Store Platform's signed order to settle a marketplace sale
+ * (`settle-marketplace-order`), and Store Platform's signed refund decision to
+ * refund one (`settle-marketplace-refund`), each under the buyer's assertion (Store
+ * decision V, `STO-0040`). Store Platform never calls either. Both are money-grade in
+ * `ASSURANCE_POLICY`, which is an allowlist, so `dev-bypass` is never admissible and
+ * a future method is not admissible without a policy decision (CAY-0029).
+ *
+ * **This is the contract surface only.** No route serves either operation, and
+ * nothing here settles anything. The sale table, the registry of Store Platform order
+ * keys and the ledger stay in this proprietary tree (CAY-0083 §3).
+ *
+ * ## Two operations, because two authorities are checked
+ *
+ * A sale moves the buyer's cents on the buyer's say, with Store Platform's signed
+ * order saying what is being bought and who is paid. A refund moves cents *from* a
+ * publisher on Store Platform's authority, backed by the publisher's consent in
+ * advance through the offer's terms, and the buyer is the payee (CAY-0083 §3). One
+ * operation with a mode flag would blur which authority is being checked, so each
+ * has its own request, its own answer and its own refusal union, and a credential
+ * minted for one does not carry the other.
+ *
+ * ## What Piper presents is exactly what Store Platform signed
+ *
+ * {@link StoreSignedStatement} carries the bytes Store Platform's order key signed,
+ * and the signature over them. Cayso verifies the signature over those bytes as
+ * they arrived, and reads nothing from them as a fact until it has. So there is no
+ * second encoding of Store Platform's statement on this side of the boundary, and
+ * no way for a re-encoding to disagree with the signer by a space. Piper produces
+ * the bytes with Store Platform's own published encoder
+ * (`encodeSignedOrderStatement`, `encodeRefundDecisionStatement` in
+ * `@percayso/store-contracts`), and never edits them.
+ *
+ * The statements' fields are Store Platform's to define (`STO-0043`) and are not
+ * restated here: a second copy of another pillar's format is two formats that
+ * disagree eventually. What Cayso reads from them, once verified, is CAY-0082's
+ * list — the order digest, the checkout's idempotency key, the price, the paying
+ * wallet, the payee wallet or the house-publisher fact, and the allocation-policy
+ * version.
+ *
+ * **Nothing about the sale is taken from the caller's word.** The house-publisher
+ * fact, the payee wallet, the price and the idempotency key are all inside the
+ * signed bytes (CAY-0076, CAY-0082 §2), and there is no request field beside them.
+ * In particular the key is not presented twice: a request whose key disagrees with
+ * its signed order is not a request these types can express. The status read asks
+ * with the same key, read from the same order (`MarketplaceReceiptReadRequest`).
+ *
+ * A statement that decodes to something other than the statement the operation
+ * takes — a refund decision presented as an order, or the reverse — is
+ * `invalid_request`, and is never read as the other.
+ *
+ * ## One answer or nothing, so there is no status
+ *
+ * A settlement is one movement, written or not (CAY-0023): its answer is a signed
+ * receipt or one refusal, and a refusal means nothing was written. There is no
+ * pending, failed or reversed sale on these shapes. A caller that lost the answer
+ * asks the status read, or presents the same signed order again: **a replay under
+ * the same key and the same order answers the receipt already written**, in the same
+ * shape as the first answer, and is not a second sale (CAY-0082 §4).
+ *
+ * The receipt each answer carries is narrowed to the operation. An order is answered
+ * with a marketplace settlement's or a house-publisher charge's receipt, and a refund
+ * with a marketplace refund's, so an order answered with a refund receipt is not a
+ * value of {@link MarketplaceOrderResponse}. Both are `MarketplaceReceipt`s,
+ * the same one the status read returns, and Store Platform verifies them the same
+ * way.
+ *
+ * ## The paying wallet is the verified subject's own
+ *
+ * The buyer's wallet is resolved through the holders mapping from the verified
+ * assertion's subject, which is then discarded (CAY-0054, CAY-0082 §1). The order
+ * names the wallet the Citizen confirmed paying from, and an order naming any other
+ * wallet is refused rather than paid from either: Cayso never trusts a statement
+ * about who the caller is (CAY-0021), including Store Platform's.
+ *
+ * ## What is not here
+ *
+ *   - **No unconfigured adapter in either union.** A seam this deployment has not
+ *     been told about is a `503` in the refusal envelope's own code (`errors.ts`),
+ *     never a member here (CAY-0082 §7). No receipt key is
+ *     `receipt_signing_not_configured`. CAY-0083 §4's registry of Store Platform
+ *     order keys, empty by default, closes both operations and the status read
+ *     with a `503` too; its spelling is published by the slice that builds it.
+ *   - **No figure.** The allocation between publisher and Community is Store
+ *     Platform's canon's, named by the version the order carries. The refund window
+ *     and the restricted-refund period are canon figures too, and an unset one
+ *     closes the refund it gates rather than defaulting.
+ *   - **No second payee.** A paid sale has exactly one publisher leg (CAY-0082 §8),
+ *     and a split among publishers is not designed (CAY-0079 §6).
+ *   - **No Percayso identity**, in any request, answer or refusal (CAY-0006).
+ */
+import type { HousePublisherChargeReceiptStatement, HousePublisherRefundReceiptStatement, MarketplaceSettlementReceiptStatement, ThirdPartyRefundReceiptStatement } from './marketplace-receipt.js';
+/**
+ * A statement Store Platform signed with its order key, exactly as it was signed.
+ * Opaque to Piper: carried, never edited.
+ */
+export interface StoreSignedStatement {
+    /** The exact bytes Store Platform's order key signed, as unpadded base64url. */
+    readonly statement: string;
+    /** Store Platform's ES256 signature over those bytes: `r || s`, 64 bytes, as unpadded base64url. */
+    readonly signature: string;
+}
+/**
+ * Piper presenting Store Platform's signed order to settle a marketplace sale, under
+ * the buyer's assertion (`settle-marketplace-order`). The idempotency key, the price
+ * and who is paid are all inside the signed order, and nowhere beside it.
+ */
+export interface MarketplaceOrderRequest {
+    readonly signedOrder: StoreSignedStatement;
+}
+/**
+ * Piper presenting Store Platform's signed refund decision, under the buyer's
+ * assertion (`settle-marketplace-refund`). The decision names the sale by its order
+ * digest and carries its own idempotency key, never the sale's (`STO-0043`). There is
+ * no amount: a refund is of the whole sale it names.
+ */
+export interface MarketplaceRefundRequest {
+    readonly signedRefundDecision: StoreSignedStatement;
+}
+/**
+ * The receipt an order is answered with: a third-party sale's marketplace
+ * settlement, or a house-publisher sale's charge (CAY-0082 §1, §2). Never a refund's.
+ * It is a `MarketplaceReceipt`.
+ */
+export interface MarketplaceOrderReceipt {
+    readonly statement: MarketplaceSettlementReceiptStatement | HousePublisherChargeReceiptStatement;
+    /** Cayso's ES256 signature over `encodeMarketplaceReceiptStatement(statement)`. */
+    readonly signature: string;
+}
+/**
+ * The receipt a refund is answered with: the marketplace refund of a third-party
+ * sale or of a house-publisher sale (CAY-0082 §5). Never a sale's. It is a
+ * `MarketplaceReceipt`.
+ */
+export interface MarketplaceRefundReceipt {
+    readonly statement: ThirdPartyRefundReceiptStatement | HousePublisherRefundReceiptStatement;
+    /** Cayso's ES256 signature over `encodeMarketplaceReceiptStatement(statement)`. */
+    readonly signature: string;
+}
+/**
+ * The sale was written. Answered for the presentation that wrote it and for every
+ * replay of its key with the same order, in the same shape.
+ */
+export interface MarketplaceOrderSettled {
+    readonly outcome: 'settled';
+    readonly receipt: MarketplaceOrderReceipt;
+}
+/** The order was refused, with one member of the closed union. Nothing was written. */
+export interface MarketplaceOrderRefused {
+    readonly outcome: 'refused';
+    readonly error: MarketplaceOrderRefusal;
+}
+/**
+ * The ONE declared answer to `settle-marketplace-order`, discriminated by `outcome`.
+ * A consumer switches on `outcome` and never sniffs which fields are present.
+ */
+export type MarketplaceOrderResponse = MarketplaceOrderSettled | MarketplaceOrderRefused;
+/**
+ * Why a marketplace sale was refused: CAY-0082 §7's set for a sale, closed, spelled
+ * here. Every member means the same thing about money: nothing moved.
+ *
+ * A consumer renders a member by its name and never pattern-matches on prose. A new
+ * reason is a new member and a contract version, never a free-text field.
+ */
+export type MarketplaceOrderRefusal = 
+/**
+ * The verification method is outside the money-grade assurance profile
+ * (`ASSURANCE_POLICY['settle-marketplace-order']`). `dev-bypass` is never inside it.
+ */
+'assurance_not_money_grade'
+/**
+ * No wallet is bound to the verified subject now, for example after erasure, so
+ * there is no buyer's wallet to pay from. A sale never provisions one.
+ */
+ | 'wallet_has_no_live_binding'
+/** The order is signed by a key the registry of Store Platform order keys does not hold (CAY-0083 §4). */
+ | 'order_key_not_recognised'
+/** The order's signature does not verify over the bytes presented. */
+ | 'order_signature_invalid'
+/** The order's digest is not the digest of the order facts it carries. */
+ | 'order_digest_mismatch'
+/**
+ * The order names a paying wallet that is not the verified subject's own. Refused,
+ * and never paid from either wallet: Store Platform's statement about who is
+ * paying does not stand in for the assertion (CAY-0021).
+ */
+ | 'order_payer_wallet_not_the_buyers'
+/**
+ * The key already landed something else for this buyer's wallet: a sale of a
+ * different order, or a refund. The key is unique per paying wallet across both
+ * sale kinds (CAY-0082 §4), and the two orders cannot both be what the buyer asked
+ * for, so neither is answered.
+ */
+ | 'idempotency_key_reused_for_a_different_order'
+/**
+ * The allocation-policy version the order names has no figure configured here, so
+ * a third-party sale's split cannot be computed. A closed door, never a default
+ * split. A house-publisher sale has no split and never meets it.
+ */
+ | 'allocation_policy_version_not_configured'
+/** No wallet has the payee's id. */
+ | 'payee_wallet_not_found'
+/** The payee's wallet is an Organisation Wallet or the Treasury. A paid sale's publisher is a Citizen (CAY-0082 §8). */
+ | 'payee_wallet_not_a_citizens'
+/** No Citizen is bound to the payee's wallet now, for example because the binding was erased. */
+ | 'payee_wallet_has_no_live_binding'
+/**
+ * A third-party sale: the buyer's unrestricted cents are short. Restricted cents
+ * are never counted and never drawn for one (CAY-0076), so a wallet holding enough
+ * only once restricted cents are included is still short.
+ */
+ | 'unrestricted_cents_insufficient'
+/**
+ * A house-publisher sale: the buyer's cents are short, restricted and unrestricted
+ * together. It is a charge, the one act a restricted lot may pay for (CAY-0082 §2),
+ * so it is kept apart from `unrestricted_cents_insufficient`: telling a buyer to
+ * look at their unrestricted cents would be wrong here.
+ */
+ | 'cents_insufficient'
+/** A holding the draw needs is frozen. A freeze is not restriction. */
+ | 'cents_frozen'
+/**
+ * Too many concurrent draws on the buyer's wallet, and the compare-and-swap retries
+ * ran out. Nothing moved, and the same signed order may be presented again.
+ */
+ | 'carve_contended';
+/**
+ * The refund was written. Answered for the presentation that wrote it and for every
+ * replay of its key with the same refund decision, in the same shape.
+ */
+export interface MarketplaceRefundSettled {
+    readonly outcome: 'refunded';
+    readonly receipt: MarketplaceRefundReceipt;
+}
+/** The refund was refused, with one member of the closed union. Nothing was written. */
+export interface MarketplaceRefundRefused {
+    readonly outcome: 'refused';
+    readonly error: MarketplaceRefundRefusal;
+}
+/**
+ * The ONE declared answer to `settle-marketplace-refund`, discriminated by `outcome`.
+ */
+export type MarketplaceRefundResponse = MarketplaceRefundSettled | MarketplaceRefundRefused;
+/**
+ * Why a marketplace refund was refused: CAY-0082 §7's set for a refund, closed,
+ * spelled here. Every member means nothing moved, and the sale is untouched whatever
+ * the answer.
+ */
+export type MarketplaceRefundRefusal = 
+/**
+ * The verification method is outside the money-grade assurance profile
+ * (`ASSURANCE_POLICY['settle-marketplace-refund']`). `dev-bypass` is never inside it.
+ */
+'assurance_not_money_grade'
+/** No wallet is bound to the verified subject now, so there is no buyer's wallet to refund. */
+ | 'wallet_has_no_live_binding'
+/** The decision is signed by a key the registry of Store Platform order keys does not hold (CAY-0083 §4). */
+ | 'refund_decision_key_not_recognised'
+/** The decision's signature does not verify over the bytes presented. */
+ | 'refund_decision_signature_invalid'
+/**
+ * The order digest the decision names is not a marketplace sale this buyer's wallet
+ * paid for. Somebody else's sale is not found either: the answer does not say
+ * whether one exists.
+ */
+ | 'sale_not_found'
+/**
+ * The key already landed something else for this buyer's wallet: a refund on a
+ * different decision, or a sale. A refund carries its own key, never the sale's.
+ */
+ | 'idempotency_key_reused_for_a_different_refund'
+/** The refund window after the sale has passed (CAY-0082 §5). */
+ | 'refund_window_passed'
+/** This listing was already refunded to this Citizen. A Citizen gets at most one refund per listing (CAY-0082 §5). */
+ | 'listing_already_refunded'
+/**
+ * A canon figure the refund needs — the refund window, or the period a restricted
+ * refund's new expiry runs for — is not configured. A closed door, never a
+ * default: the refund is refused (CAY-0082 §5).
+ */
+ | 'refund_figure_not_configured'
+/**
+ * A third-party sale's refund: the publisher's unrestricted cents cannot meet their
+ * leg. Refused, never covered: the Treasury never makes up a publisher's shortfall,
+ * and Store Platform raises an operator case (CAY-0082 §5).
+ */
+ | 'publisher_unrestricted_cents_insufficient'
+/** A holding the draw needs is frozen. A freeze is not restriction. */
+ | 'cents_frozen'
+/**
+ * Too many concurrent draws, and the compare-and-swap retries ran out. Nothing
+ * moved, and the same signed refund decision may be presented again.
+ */
+ | 'carve_contended';

package/dist/marketplace-settlement.js

@@ -0,0 +1,16 @@
+/*
+ * Copyright 2026 Percayso Community
+ *
+ * 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.
+ */
+export {};

package/dist/money.d.ts

@@ -0,0 +1,84 @@
+/**
+ * The amount a movement may carry, as a type that cannot express the violation —
+ * the second layer CLAUDE.md requires beside the schema's own rule, at the one
+ * place cents actually move (CAY-0045).
+ *
+ * ## Why this is here and not beside the carve
+ *
+ * CLAUDE.md: "Every money invariant is enforced twice: a rule in the schema, AND a
+ * type that cannot express the violation. One layer does not count." For the amount
+ * a carve accepts there was one layer. The branded money types that WOULD have been
+ * the second — `HoldingCents` and `MovementCents` in `apps/api/src/db` — are
+ * unreachable from `packages/ledger`, which may not depend on an app (CLAUDE.md, the
+ * coupling scan). So the one module that moves cents could not reach the one module
+ * that types them, and the gap was architectural rather than careless (pen-test
+ * C3-1). This package is the module BOTH already depend on, which is why the brand
+ * lives here.
+ *
+ * ## Why `Cents` is not itself branded
+ *
+ * `Cents` (`./wallet`) stays the permissive wire alias it has always been, and that
+ * is deliberate:
+ *
+ *   - A brand is a compile-time discipline of this repository. JSON has no brands, so
+ *     the served contract schema would have to describe a branded `Cents` as a plain
+ *     number anyway — a generator exception written to keep the published schema
+ *     truthful is an admission that the brand is not part of the wire contract.
+ *   - The wire's cents are REPORTED figures, and one of them is legitimately signed:
+ *     `Headroom.headroomCents` is `ceiling − unrestricted` and is negative when
+ *     outstanding Cayso sits above the ceiling, which an operator must be able to
+ *     see. A type meaning "safe to move as money" is the wrong type for that field.
+ *   - `Cents` is Apache-2.0 and published (CAY-0026). Branding it would stop a
+ *     consumer building a `Balance` from a plain number compiling, for a distinction
+ *     that consumer cannot observe.
+ *
+ * So there are two money types on purpose: `Cents` describes what crosses the wire,
+ * and {@link PositiveCents} describes what a caller may ask the economy to MOVE. The
+ * distinction is the one `apps/api/src/db/holdings.ts` already drew — the wire keeps a
+ * permissive shape, the write path keeps an unforgeable one — and what C3-1 found was
+ * that the unforgeable one was in the wrong package to be used.
+ *
+ * ## What is published here, and what is not
+ *
+ * A brand and its constructor, over the unit this contract already speaks in. No
+ * holding, no carve and no movement: those nouns are not Piper's business (CAY-0026),
+ * and `HoldingCents` — which admits zero, because a lot carved to nothing is still a
+ * row — stays in `apps/api` where the holdings table is. Nothing here changes the wire
+ * surface: no type on this module appears in a request or a response, and the served
+ * contract schema is unchanged by its arrival.
+ *
+ * There are no figures in this file. The safe-integer edge is decided against
+ * `Number.MAX_SAFE_INTEGER` — a limit of the language, not an amount — and every
+ * amount, rate, tier and threshold lives in the canon PRD.
+ */
+import type { Cents } from './wallet.js';
+/**
+ * A strictly-positive, safe-integer count of cents: the amount a movement may
+ * carry, and the type half of `movements.cents BIGINT NOT NULL CHECK (cents > 0)`.
+ *
+ * The brand is a private symbol, so the ONLY way to obtain one is
+ * {@link positiveCents}. A negative, a fraction, a zero and anything past the safe
+ * integer range are therefore unspellable on the money path rather than merely
+ * refused late — which is what "enforced twice" asks for (CAY-0018, CAY-0045).
+ *
+ * It refines `Cents` rather than sitting beside it, so a validated amount is still
+ * an ordinary cents figure everywhere a cents figure is read, reported or rendered.
+ * The narrowing goes one way only: every `PositiveCents` is a `Cents`, and no
+ * `Cents` is a `PositiveCents` without passing the constructor.
+ */
+declare const positiveCentsBrand: unique symbol;
+export type PositiveCents = Cents & {
+    readonly [positiveCentsBrand]: true;
+};
+/**
+ * The only way to obtain a {@link PositiveCents}. Refuses everything a movement's
+ * amount must never be: a fraction, a `NaN`, an infinity, a magnitude past the range
+ * where a JS number still represents an integer exactly, and anything at or below
+ * zero — a zero-value movement is not a movement.
+ *
+ * It throws and never rounds. Rounding a money amount to make it acceptable is how a
+ * cent goes missing, and the caller that handed over a fraction has a defect this
+ * hides.
+ */
+export declare function positiveCents(value: number): PositiveCents;
+export {};

package/dist/money.js

@@ -0,0 +1,34 @@
+/*
+ * Copyright 2026 Percayso Community
+ *
+ * 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.
+ */
+/**
+ * The only way to obtain a {@link PositiveCents}. Refuses everything a movement's
+ * amount must never be: a fraction, a `NaN`, an infinity, a magnitude past the range
+ * where a JS number still represents an integer exactly, and anything at or below
+ * zero — a zero-value movement is not a movement.
+ *
+ * It throws and never rounds. Rounding a money amount to make it acceptable is how a
+ * cent goes missing, and the caller that handed over a fraction has a defect this
+ * hides.
+ */
+export function positiveCents(value) {
+    if (!Number.isInteger(value) || !Number.isSafeInteger(value)) {
+        throw new Error(`cents must be a safe whole number, not ${value} — money is integer cents.`);
+    }
+    if (value <= 0) {
+        throw new Error(`a movement's cents must be strictly positive, not ${value}.`);
+    }
+    return value;
+}

package/dist/organisation.d.ts

@@ -0,0 +1,60 @@
+/**
+ * `organisation` — what `POST /api/organisation/provision` answers (CAY-0059).
+ *
+ * An Organisation Wallet is keyed by the **Organisation ID** Percayso ID holds and
+ * attests, never by a Piper Instance. An Organisation OWNS an Instance, a
+ * possession cannot be the permanent identity of its owner, one Organisation may
+ * own several, and an Instance moves between Hosts without the Organisation or its
+ * Wallet changing. Naming the owner after the possession inverts the relationship
+ * and breaks on the second Instance (CAY-0059 §2).
+ *
+ * ## The request carries NOTHING
+ *
+ * This file declares no request shape, and that absence is the decision rather
+ * than an omission. The Organisation ID comes from the organisation-authority
+ * claim on the verified assertion (`AssertionClaims.organisationAuthority`) and
+ * from nowhere else — not a path, not a body, not a query (CAY-0059 §4). A
+ * downloadable Instance is a public client and an identifier a caller supplies is
+ * a request rather than evidence (CAY-0057), so a request shape naming the
+ * organisation would be a wallet-creation oracle: anybody able to name a UUID
+ * could bring an Organisation Wallet into being, or select one. The decision
+ * REMOVES the oracle rather than guarding it, which means there is no parameter to
+ * guard.
+ *
+ * ## It is IDEMPOTENT, and there is no "already provisioned" answer
+ *
+ * Calling it twice provisions once and answers the same wallet both times
+ * (CAY-0059 §4.6, the shape CAY-0031 set for citizenship). So {@link
+ * OrganisationView} carries no `state` discriminator: a call that reaches this
+ * answer has an Organisation Wallet, whether this call made it or an earlier one
+ * did. A caller cannot tell the two apart and has no decision that turns on it.
+ *
+ * ## No grant, no cents, no figures
+ *
+ * Provisioning an organisation moves no cents. The sign-up grant is a citizen's
+ * (CAY-0031) and nothing here has an amount, a rate, a tier, a schedule or a
+ * threshold — every economic figure lives in the canon PRD (CLAUDE.md). This
+ * answer is a wallet and nothing else.
+ *
+ * ## The Organisation ID is not echoed back, and that is deliberate
+ *
+ * The answer carries the {@link WalletRecord} — the opaque, operator-facing handle
+ * (CAY-0017) — and not the Organisation ID the claim carried. The caller already
+ * holds that value; repeating it here would make this response a second home for
+ * an external identity, and the mapping from an identity to a wallet lives in the
+ * holders mapping and nowhere else (CAY-0006, CLAUDE.md).
+ */
+import type { WalletRecord } from './wallet.js';
+/**
+ * The answer to `POST /api/organisation/provision`: the Organisation Wallet bound
+ * to the attested Organisation ID.
+ *
+ * One field, and an object rather than a bare {@link WalletRecord}, for the reason
+ * every other view on this surface is an object: a response that is a record has
+ * nowhere to grow a second field without breaking every consumer that decoded it
+ * as one.
+ */
+export interface OrganisationView {
+    /** The Organisation Wallet. `holderType` is always `'organisation'` here. */
+    readonly wallet: WalletRecord;
+}

package/dist/organisation.js

@@ -0,0 +1,16 @@
+/*
+ * Copyright 2026 Percayso Community
+ *
+ * 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.
+ */
+export {};