@nuanu-ai/agentify-contracts 0.3.2

package/dist/quote.d.ts

@@ -0,0 +1,79 @@
+/**
+ * The question "how much is this and is it there", and the merchant's answer.
+ *
+ * One shape, two transports. By default the question rides the same outgoing
+ * channel as the orders and is answered by a handler in the merchant's own
+ * process; a merchant whose prices come from a separate service answers the
+ * same question over https at an address their card names. The fields do not
+ * differ between the two, which is what lets a merchant switch transports
+ * without touching the code that answers.
+ *
+ * What the schema deliberately does not describe is silence. A missing answer,
+ * a timeout, a broken connection and an answer that did not parse against the
+ * shape below are all the same thing to the gateway, and what it does about
+ * them depends on the card's mode rather than on the shape of anything on this
+ * page.
+ *
+ * One field an order has and this does not: a price question carries no test
+ * marker. For a card with a price check the question rides the same channel as
+ * the order it precedes, and it arrives looking like every other question — so
+ * a handler that routes test orders to a test environment, which the portal
+ * tells merchants they may do, has nothing to route the question by. Whether that wants a field here or is better
+ * answered by however the sandbox is eventually separated from live is not
+ * decided, and inventing the field ahead of that decision would answer it.
+ */
+import { z } from "zod";
+/**
+ * Why we are asking.
+ *
+ * `purchase` means an agent is standing at the till right now; `poll` means we
+ * are refreshing what we know between purchases and nobody is buying. The
+ * distinction is there so an expensive stock lookup can be spent on the first
+ * and skipped on the second.
+ */
+export declare const QuotePurposeSchema: z.ZodEnum<{
+    purchase: "purchase";
+    poll: "poll";
+}>;
+export declare const QuoteRequestSchema: z.ZodObject<{
+    merchant_item_id: z.ZodString;
+    params: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
+    price_id: z.ZodString;
+    purpose: z.ZodEnum<{
+        purchase: "purchase";
+        poll: "poll";
+    }>;
+    expires_at: z.ZodISODateTime;
+}, z.core.$strict>;
+/**
+ * The answer, in the only two shapes it has.
+ *
+ * A price and an availability of `false` cannot travel together, and neither
+ * can availability of `true` and no price. Both would be two answers at once:
+ * whichever the gateway then acted on, the merchant would have grounds to say
+ * it acted on the wrong one — and in the first case the sale would quietly
+ * fall back to the price in the card, at a price the merchant never quoted.
+ *
+ * `as_of` is on both branches because it is what separates "I went and looked"
+ * from "here is what was in the cache". The gateway carries that moment and
+ * does not weigh it: it travels into the order the handler is given and into
+ * the record of the sale, so whoever reconciles a charge afterwards can see how
+ * old the number behind it was, and nothing anywhere compares it against
+ * anything. A price's life runs from the moment the answer reached us rather
+ * than from the moment it says it was true, so an answer stamped a year ago is
+ * honoured exactly as long as one stamped a second ago.
+ */
+export declare const QuoteResponseSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
+    available: z.ZodLiteral<true>;
+    price: z.ZodObject<{
+        amount: z.ZodString;
+        currency: z.ZodString;
+    }, z.core.$strict>;
+    as_of: z.ZodISODateTime;
+}, z.core.$strict>, z.ZodObject<{
+    available: z.ZodLiteral<false>;
+    as_of: z.ZodISODateTime;
+}, z.core.$strict>], "available">;
+export type QuotePurpose = z.infer<typeof QuotePurposeSchema>;
+export type QuoteRequest = z.infer<typeof QuoteRequestSchema>;
+export type QuoteResponse = z.infer<typeof QuoteResponseSchema>;

package/dist/quote.js

@@ -0,0 +1,92 @@
+/**
+ * The question "how much is this and is it there", and the merchant's answer.
+ *
+ * One shape, two transports. By default the question rides the same outgoing
+ * channel as the orders and is answered by a handler in the merchant's own
+ * process; a merchant whose prices come from a separate service answers the
+ * same question over https at an address their card names. The fields do not
+ * differ between the two, which is what lets a merchant switch transports
+ * without touching the code that answers.
+ *
+ * What the schema deliberately does not describe is silence. A missing answer,
+ * a timeout, a broken connection and an answer that did not parse against the
+ * shape below are all the same thing to the gateway, and what it does about
+ * them depends on the card's mode rather than on the shape of anything on this
+ * page.
+ *
+ * One field an order has and this does not: a price question carries no test
+ * marker. For a card with a price check the question rides the same channel as
+ * the order it precedes, and it arrives looking like every other question — so
+ * a handler that routes test orders to a test environment, which the portal
+ * tells merchants they may do, has nothing to route the question by. Whether that wants a field here or is better
+ * answered by however the sandbox is eventually separated from live is not
+ * decided, and inventing the field ahead of that decision would answer it.
+ */
+import { z } from "zod";
+import { ParamNameSchema } from "./param-spec.js";
+import { IdentifierSchema, MoneySchema, TimestampSchema } from "./primitives.js";
+/**
+ * Why we are asking.
+ *
+ * `purchase` means an agent is standing at the till right now; `poll` means we
+ * are refreshing what we know between purchases and nobody is buying. The
+ * distinction is there so an expensive stock lookup can be spent on the first
+ * and skipped on the second.
+ */
+export const QuotePurposeSchema = z.enum(["purchase", "poll"]);
+export const QuoteRequestSchema = z.strictObject({
+    /** The merchant's own key for the product being asked about. */
+    merchant_item_id: IdentifierSchema,
+    /**
+     * The purchase parameters, where the price depends on them. Absent for a
+     * card that takes no input, and for a scheduled poll of such a card.
+     */
+    // Same dropped key as everywhere this contract parses free-form names; see
+    // `PROTOTYPE_KEY_IS_DROPPED` in `param-spec.ts`.
+    params: z.record(ParamNameSchema, z.unknown()).optional(),
+    /**
+     * The identifier of this question, which comes back attached to the order.
+     *
+     * It is good for one order: a merchant who set stock aside under it can
+     * release it when the order arrives or when the price expires. That "one
+     * order" is a rule the gateway keeps — no schema can see a second use of an
+     * identifier it is shown once.
+     */
+    price_id: IdentifierSchema,
+    purpose: QuotePurposeSchema,
+    /**
+     * Until when the price the merchant names will be honoured, so a merchant
+     * holding stock against it knows when to stop. There is no separate message
+     * when it passes; this moment is the whole notice.
+     */
+    expires_at: TimestampSchema,
+});
+/**
+ * The answer, in the only two shapes it has.
+ *
+ * A price and an availability of `false` cannot travel together, and neither
+ * can availability of `true` and no price. Both would be two answers at once:
+ * whichever the gateway then acted on, the merchant would have grounds to say
+ * it acted on the wrong one — and in the first case the sale would quietly
+ * fall back to the price in the card, at a price the merchant never quoted.
+ *
+ * `as_of` is on both branches because it is what separates "I went and looked"
+ * from "here is what was in the cache". The gateway carries that moment and
+ * does not weigh it: it travels into the order the handler is given and into
+ * the record of the sale, so whoever reconciles a charge afterwards can see how
+ * old the number behind it was, and nothing anywhere compares it against
+ * anything. A price's life runs from the moment the answer reached us rather
+ * than from the moment it says it was true, so an answer stamped a year ago is
+ * honoured exactly as long as one stamped a second ago.
+ */
+export const QuoteResponseSchema = z.discriminatedUnion("available", [
+    z.strictObject({
+        available: z.literal(true),
+        price: MoneySchema,
+        as_of: TimestampSchema,
+    }),
+    z.strictObject({
+        available: z.literal(false),
+        as_of: TimestampSchema,
+    }),
+]);

package/dist/receipt.d.ts

@@ -0,0 +1,79 @@
+/**
+ * The receipt: the record left by a purchase that was paid for.
+ *
+ * It exists from the moment the money moves, which in two of the three modes
+ * is before the product is delivered — so a receipt has to be able to say
+ * "paid, delivery still running" without that being mistaken for either "you
+ * have it" or "you paid and never got it". A purchase that ends before any
+ * payment leaves no receipt at all: nothing moved, and there is nothing for it
+ * to be proof of. Which of the order's endings a receipt can carry is worked
+ * out at `ReceiptOutcomeSchema` below.
+ *
+ * The price on a receipt is the price the sale went through at, and it stays
+ * what it was even after the merchant's price changes.
+ */
+import { z } from "zod";
+/**
+ * What became of the purchase behind this receipt.
+ *
+ * The words are the order's own — a receipt saying `pending` where the order
+ * said `in_progress` would be two names for one state, and whichever an agent
+ * happened to read would look like the whole truth.
+ *
+ * The set is narrower than the order's, and the reason is what a receipt is: a
+ * record of a payment that executed. Work through the endings and six of the
+ * ten cannot reach one. `rejected`, `declined` and `expired` all close before
+ * any money moves. `cancelled` is the merchant leaving, which for a paid order
+ * is a debt and arrives here as `refund_due` instead. `delivered_unpaid` is
+ * the case where the merchant produced the goods and the charge came back
+ * failed — no payment, so no receipt to carry the outcome.
+ *
+ * `payment_unresolved` is the one worth arguing rather than asserting, because
+ * the purchase behind it can have a verified payment behind it and still end
+ * there. It is excluded, and the reason is the receipt's own job. That value
+ * means nobody can say whether the buyer was charged; a receipt is the
+ * evidence that they were. A receipt carrying it would be a proof of payment
+ * whose own outcome says it does not know there was a payment — the one
+ * artifact in this contract that cannot hold that sentence. So no receipt is
+ * written while the question is open. If the answer arrives and the money did
+ * move, the receipt is written then and carries whatever the delivery reached;
+ * if it did not, there was never anything to record. That is the same promise
+ * the portal makes to the buyer in words: we say so when we learn.
+ *
+ * That leaves four: paid and still running, paid and delivered, paid and owed
+ * back, paid and paid back.
+ *
+ * What this list does not say is when a receipt is written at all, and a reader
+ * should not infer it from here. That is the gateway's, and a gateway that
+ * writes one only as goods are released will only ever produce `delivered` —
+ * so a consumer must not read the presence of these four as a promise that a
+ * receipt exists for every payment that executed.
+ */
+export declare const ReceiptOutcomeSchema: z.ZodEnum<{
+    delivered: "delivered";
+    in_progress: "in_progress";
+    refund_due: "refund_due";
+    refunded: "refunded";
+}>;
+export declare const ReceiptSchema: z.ZodObject<{
+    id: z.ZodString;
+    order_id: z.ZodString;
+    item_id: z.ZodString;
+    price: z.ZodObject<{
+        amount: z.ZodString;
+        currency: z.ZodString;
+        at: z.ZodISODateTime;
+        as_of: z.ZodISODateTime;
+    }, z.core.$strict>;
+    price_id: z.ZodOptional<z.ZodString>;
+    paid_at: z.ZodISODateTime;
+    outcome: z.ZodEnum<{
+        delivered: "delivered";
+        in_progress: "in_progress";
+        refund_due: "refund_due";
+        refunded: "refunded";
+    }>;
+    test: z.ZodBoolean;
+}, z.core.$strict>;
+export type ReceiptOutcome = z.infer<typeof ReceiptOutcomeSchema>;
+export type Receipt = z.infer<typeof ReceiptSchema>;

package/dist/receipt.js

@@ -0,0 +1,83 @@
+/**
+ * The receipt: the record left by a purchase that was paid for.
+ *
+ * It exists from the moment the money moves, which in two of the three modes
+ * is before the product is delivered — so a receipt has to be able to say
+ * "paid, delivery still running" without that being mistaken for either "you
+ * have it" or "you paid and never got it". A purchase that ends before any
+ * payment leaves no receipt at all: nothing moved, and there is nothing for it
+ * to be proof of. Which of the order's endings a receipt can carry is worked
+ * out at `ReceiptOutcomeSchema` below.
+ *
+ * The price on a receipt is the price the sale went through at, and it stays
+ * what it was even after the merchant's price changes.
+ */
+import { z } from "zod";
+import { IdentifierSchema, SalePriceSchema, TimestampSchema } from "./primitives.js";
+/**
+ * What became of the purchase behind this receipt.
+ *
+ * The words are the order's own — a receipt saying `pending` where the order
+ * said `in_progress` would be two names for one state, and whichever an agent
+ * happened to read would look like the whole truth.
+ *
+ * The set is narrower than the order's, and the reason is what a receipt is: a
+ * record of a payment that executed. Work through the endings and six of the
+ * ten cannot reach one. `rejected`, `declined` and `expired` all close before
+ * any money moves. `cancelled` is the merchant leaving, which for a paid order
+ * is a debt and arrives here as `refund_due` instead. `delivered_unpaid` is
+ * the case where the merchant produced the goods and the charge came back
+ * failed — no payment, so no receipt to carry the outcome.
+ *
+ * `payment_unresolved` is the one worth arguing rather than asserting, because
+ * the purchase behind it can have a verified payment behind it and still end
+ * there. It is excluded, and the reason is the receipt's own job. That value
+ * means nobody can say whether the buyer was charged; a receipt is the
+ * evidence that they were. A receipt carrying it would be a proof of payment
+ * whose own outcome says it does not know there was a payment — the one
+ * artifact in this contract that cannot hold that sentence. So no receipt is
+ * written while the question is open. If the answer arrives and the money did
+ * move, the receipt is written then and carries whatever the delivery reached;
+ * if it did not, there was never anything to record. That is the same promise
+ * the portal makes to the buyer in words: we say so when we learn.
+ *
+ * That leaves four: paid and still running, paid and delivered, paid and owed
+ * back, paid and paid back.
+ *
+ * What this list does not say is when a receipt is written at all, and a reader
+ * should not infer it from here. That is the gateway's, and a gateway that
+ * writes one only as goods are released will only ever produce `delivered` —
+ * so a consumer must not read the presence of these four as a promise that a
+ * receipt exists for every payment that executed.
+ */
+export const ReceiptOutcomeSchema = z.enum(["in_progress", "delivered", "refund_due", "refunded"]);
+export const ReceiptSchema = z.strictObject({
+    /**
+     * The receipt's own identifier. In the modes where the payment goes first,
+     * this is what an agent repeats a purchase by.
+     */
+    id: IdentifierSchema,
+    /** The order this purchase produced. */
+    order_id: IdentifierSchema,
+    /** Our catalog identifier for the card that was bought. */
+    item_id: IdentifierSchema,
+    /** The price the sale went through at, with the moment behind it. */
+    price: SalePriceSchema,
+    /** The price question the sale came out of, absent when there was none. */
+    price_id: IdentifierSchema.optional(),
+    /**
+     * When the payment executed — which is neither of the moments in `price`. In
+     * the synchronous mode the payment is the last step, after the delivery, and
+     * on a card with a price check the agent can spend as long as it likes
+     * between the price being struck and paying it, so folding any two of the
+     * three together would misdate one of them.
+     */
+    paid_at: TimestampSchema,
+    outcome: ReceiptOutcomeSchema,
+    /**
+     * Whether the money behind this receipt was real. A receipt is proof of
+     * payment, and an unmarked receipt for a test purchase is proof of a payment
+     * that never happened.
+     */
+    test: z.boolean(),
+});

package/dist/results.d.ts

@@ -0,0 +1,230 @@
+/**
+ * What our calls hand back — the successes as well as the failures.
+ *
+ * None of it travels as an exception. A merchant's integration code has to
+ * read these, branch on them and write some of them down, and an exception is
+ * the wrong shape for something you are expected to handle rather than to be
+ * surprised by. That is a rule about the whole surface, which is why publishing
+ * a card and answering for an order share a file even though they are
+ * different calls.
+ *
+ * The words below are wire names, not prose: a merchant's code branches on
+ * them, so rewording one is changing the contract.
+ *
+ * Every one of those answers arrives in one envelope. `ok` is `true` or it is
+ * `false` and nothing else says which; a success carries its own fields beside
+ * it, and a failure carries `error`. That `ok` is a value and not a key that
+ * may or may not be present is the part worth arguing, because the two look
+ * alike from inside TypeScript and do not behave alike anywhere else. A key
+ * with an object under it reads as false in Python and in PHP — `{"ok": {}}`
+ * is falsy in both — so the one idiom an engineer would write says yes to one
+ * answer and no to another, and the JSON Schema export exists for exactly that
+ * engineer. As a literal it is also a discriminator: it crosses into the export
+ * as a `const` on each branch, which a generator can switch on, where
+ * "whichever key happens to be present" is something a reader has to work out.
+ *
+ * Two words carry what went wrong, and they are not two names for one thing.
+ * `error` is why a call did not go through: one object, always, with a code to
+ * branch on, a sentence to print, and a flag saying whether repeating the call
+ * could change the outcome. `problems` is the list of findings about what was
+ * sent — the fields at fault — and it rides inside `error` wherever there are
+ * any. A call fails for one reason; a document can be wrong in several places
+ * at once, and that is the whole of the difference between the singular and the
+ * plural here.
+ */
+import { z } from "zod";
+/**
+ * How answering for an order can succeed.
+ *
+ * "Answering" rather than "delivering or refusing", because two of these reach
+ * us from a third surface — a handler's own return — rather than from either
+ * call. `accepted` is how an asynchronous handler answers while the delivery
+ * is still ahead of it, and `purchase_already_closed` belongs to the
+ * synchronous mode, where neither `deliver` nor `refuse` exists at all, as the
+ * error code `not_applicable_in_mode` says from the other direction.
+ *
+ * Each one is a different thing for the merchant to do next, which is why none
+ * of them collapses into another. `accepted` is a handler taking the order on: the
+ * goods are owed and will follow through the separate `deliver` call, and the
+ * merchant's own record of the order should say it is under way. It is a
+ * success and belongs among these rather than among the error codes, and that
+ * placement is the whole of what it does for a merchant: every handler answer
+ * is posted to the answer route by the SDK without being asked to, and an
+ * integration that reads anything but a success as trouble would otherwise
+ * open a case on every asynchronous order it sells.
+ *
+ * `delivered` is the sale closing. `already_delivered` is their own retry
+ * landing twice — safe, and no second delivery is wanted.
+ *
+ * That one is worth a warning, because the merchant-facing pages say a
+ * repeated call returns "the same success" and this returns a different word
+ * for it. Both are true of the effect — nothing is delivered twice and nothing
+ * is charged twice — but a merchant who reads that sentence and writes
+ * `if (result === "delivered")` turns their own safe retry into a failure
+ * branch. The answer these words travel in is built so that nobody has to: a
+ * consumer branches on `ok` and records the word, which stays right when this
+ * list grows another entry.
+ *
+ * One kind of consumer it does not stay right for, said here because the list
+ * has grown once already and will again. A client that checks the answer
+ * against its own copy of this schema — our own SDK does, and so does anything
+ * generated from the JSON Schema export — reads an unknown word as a document
+ * it cannot parse rather than as a success it cannot name, and reports the
+ * call as having gone wrong. So a word added here has to reach those clients
+ * before the gateway starts sending it. The version handshake would be the
+ * place to catch that. The published SDK keeps this schema strict, and every
+ * new word moves `CONTRACT_VERSION` before the gateway sends it. An old worker
+ * then stops at its version handshake rather than calling a successful answer
+ * unreadable after the merchant has already acted on it (ADR-0006).
+ *
+ * `debt_closed_by_delivery` says the delivery deadline had already passed and
+ * the goods went out anyway, closing a debt instead of completing a sale; the
+ * merchant may want to know that happened. `refused` is the refusal taking
+ * effect. `purchase_already_closed` is the synchronous handler that came back
+ * after its deadline: not an error, because nothing went wrong on their side —
+ * the work exists and a repeat purchase will collect it, and the only thing to
+ * do is write the case down.
+ */
+export declare const ORDER_CALL_RESULTS: readonly ["accepted", "delivered", "already_delivered", "debt_closed_by_delivery", "refused", "purchase_already_closed"];
+export declare const OrderCallResultSchema: z.ZodEnum<{
+    refused: "refused";
+    delivered: "delivered";
+    accepted: "accepted";
+    already_delivered: "already_delivered";
+    debt_closed_by_delivery: "debt_closed_by_delivery";
+    purchase_already_closed: "purchase_already_closed";
+}>;
+/**
+ * The error codes those calls answer with.
+ *
+ * A list of what we promise to mean the same way, not a gate: the code below
+ * stays an open string, because an error nobody anticipated has to reach the
+ * merchant in its own words rather than be flattened into the nearest of
+ * three. `refund_already_settled` — the debt was paid back, so there is
+ * nothing left to deliver against. `order_already_closed` — the order reached
+ * an ending that no call reopens. `not_applicable_in_mode` — the call does not
+ * exist for this card's mode, as refusing separately does not in the
+ * synchronous one, where the handler's own answer is the refusal.
+ * `delivery_does_not_match_card` — the goods are not the ones the card for
+ * this order declares it delivers, so nothing was written down; the message
+ * says whether the order still stands or has already ended, and the fields
+ * that did not fit are named one by one in the error's `problems`.
+ *
+ * The fourth is the only one of them a merchant fixes rather than records, and
+ * it is the reason it is promised rather than left to the open set. It is
+ * marked retryable where the order is still open, and that retry is not the
+ * same retry the other three mean: those say "the call may not have reached
+ * us, send it again", while this says the call arrived and was understood and
+ * the goods in it were wrong. Sending the same delivery again produces the
+ * same refusal until the goods change, and a merchant told only "retryable"
+ * would loop on it — which is why the code is named and the message says which
+ * field is wrong.
+ *
+ * On an order that has already ended it is not retryable, and the message says
+ * the ending. The goods being wrong and the sale being over are both true
+ * there, and only the second decides what he can do next: told the order still
+ * stood, a merchant would make the goods a second time for a purchase nobody
+ * can complete.
+ *
+ * Adding to this list is safe in a way that adding a success word is not: the
+ * code is an open string on the wire, so an older client parses an unfamiliar
+ * one and reads it as the failure it is. What it loses is the meaning, which is
+ * what this list and the dictionary below carry.
+ */
+export declare const ORDER_CALL_ERROR_CODES: readonly ["refund_already_settled", "order_already_closed", "not_applicable_in_mode", "delivery_does_not_match_card"];
+/**
+ * One thing wrong with what was sent, in a place, in a code and in words.
+ *
+ * This is one finding and never a whole answer. Wherever a call refuses what it
+ * was handed, the findings travel as a list of these under `problems` inside
+ * the error: a card that could not be published names every field standing
+ * between it and the catalog, a delivery that is not what its card declares
+ * names the fields that did not fit, and the local check a merchant runs before
+ * publishing — `checkCard` in the SDK — answers in this same shape, so a
+ * finding read on their own machine and a finding read off the wire need no
+ * two readers.
+ *
+ * The empty path is the part two readers were left to infer differently, so it
+ * is said in the exported description as well as here.
+ */
+export declare const ProblemSchema: z.ZodObject<{
+    path: z.ZodArray<z.ZodString>;
+    code: z.ZodString;
+    message: z.ZodString;
+}, z.core.$strict>;
+/**
+ * Why a call did not go through: a code to branch on, a sentence to print, and
+ * whether repeating it could change the outcome.
+ *
+ * One shape for every call on the merchant's surface. Publishing a card and
+ * delivering an order fail for entirely different reasons, and a merchant who
+ * had to learn two shapes for "this did not happen" would be learning the same
+ * lesson twice.
+ *
+ * The flag is the reason this shape exists at all. "The connection dropped,
+ * call again — the call is idempotent" and "nothing you do will change this,
+ * write the case down" need different code on the merchant's side, and a
+ * merchant left to guess turns one of them into a retry loop and the other into
+ * an order nobody comes back to. The refund that has already been paid out is
+ * the example of the second kind. It is required rather than defaulted for the
+ * same reason: both readings of a missing flag are expensive.
+ *
+ * `problems` is present where the call is refusing what it was handed rather
+ * than reporting a state of the world, and it is the field that turns "no" into
+ * an edit. It is optional because most failures have nothing to point at: a
+ * refund already settled is about the order and not about a field of the
+ * request. Where it is there it is never empty, and a call whose whole answer
+ * is "refused, and here is nothing" — a publish — requires it.
+ */
+export declare const CallErrorSchema: z.ZodObject<{
+    code: z.ZodString;
+    message: z.ZodString;
+    retryable: z.ZodBoolean;
+    problems: z.ZodOptional<z.ZodArray<z.ZodObject<{
+        path: z.ZodArray<z.ZodString>;
+        code: z.ZodString;
+        message: z.ZodString;
+    }, z.core.$strict>>>;
+}, z.core.$strict>;
+/**
+ * The code a refused publish comes back under.
+ *
+ * Promised rather than left to the open set, because it is the one refusal of
+ * this surface a merchant meets on their first afternoon, and every one of them
+ * writes the branch that reads it.
+ */
+export declare const CARD_REJECTED = "card_rejected";
+/**
+ * The answer to publishing a card: the catalog id, or what stands in its way.
+ *
+ * `ok` says which, as it does on every other call of this surface, and the
+ * catalog identifier sits at the top level of the success beside it rather than
+ * nested under a word. There is one fact in a successful publish and this is
+ * it.
+ *
+ * The refusal is `CARD_REJECTED` and it is not retryable: publishing the same
+ * card again gets the same answer, and what changes the outcome is fixing what
+ * the findings name. That is a different thing from the retry a dropped
+ * connection asks for, which is why the flag says no here rather than being
+ * left for the merchant to infer from the code.
+ */
+export declare const PublishResultSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
+    ok: z.ZodLiteral<true>;
+    id: z.ZodString;
+}, z.core.$strict>, z.ZodObject<{
+    ok: z.ZodLiteral<false>;
+    error: z.ZodObject<{
+        code: z.ZodString;
+        message: z.ZodString;
+        retryable: z.ZodBoolean;
+        problems: z.ZodArray<z.ZodObject<{
+            path: z.ZodArray<z.ZodString>;
+            code: z.ZodString;
+            message: z.ZodString;
+        }, z.core.$strict>>;
+    }, z.core.$strict>;
+}, z.core.$strict>], "ok">;
+export type Problem = z.infer<typeof ProblemSchema>;
+export type PublishResult = z.infer<typeof PublishResultSchema>;
+export type OrderCallResult = z.infer<typeof OrderCallResultSchema>;
+export type CallError = z.infer<typeof CallErrorSchema>;