/**
 * Hard limits imposed by the gateways this app talks to.
 *
 * These are not our numbers — they are deployment facts, and getting them wrong
 * is expensive because the failure is opaque. `wspace-public-gateway` sets
 * `MAX_REQUEST_BODY_SIZE: 256kb` in BOTH environments (burdenoff-gitops,
 * `apps/config-workspace/wspace-public-gateway-config.yaml:21` and
 * `apps/config-workspace-prod/…:21`). It compares Content-Length and answers
 * 413 *before* authenticating and before forwarding, and fe-libs' `graphqlFetch`
 * discards the status — so the user is told "The request could not be processed.
 * Please refresh and try again." with nothing in it to suggest the payload was
 * simply too big.
 *
 * Anything that POSTs base64 from the browser has to be sized against this.
 */
export declare const MAX_REQUEST_BODY_BYTES = 262144;
/**
 * What the person is told when a turn cannot be made to fit.
 *
 * ★ Shared by the planner that sizes a turn and by the dispatch belt in
 * `api.ts`, because they are the same refusal seen from two places and must not
 * drift into two different sentences. It names the two things the person can
 * actually do — the gateway's own 413 reaches `graphqlFetch` as "The request
 * could not be processed. Please refresh and try again.", which names neither.
 */
export declare const REQUEST_TOO_LARGE_REFUSAL = "This message is too large to send. Shorten it or send fewer attachments.";
/**
 * What is left for a base64 image once the rest of a GraphQL request is paid
 * for: the query document, operation name, variables, and the workspace/org
 * context envelope. 32 KB is deliberately generous — the point is to fail in
 * OUR code with a sentence the user can act on, rather than at the gateway with
 * one they cannot.
 */
export declare const MAX_INLINE_IMAGE_BASE64_BYTES: number;
//# sourceMappingURL=gatewayLimits.d.ts.map