@burdenoff/fe-libs 2026.904.3 → 2026.904.4

package/dist/shared/assistant/attachments.d.ts

@@ -0,0 +1,340 @@
+import { DocumentExtraction, DocumentFormat } from './documentText';
+import { AssistantPromptPart } from './types';
+export declare const MAX_ATTACHMENTS = 5;
+/** Per-file ceiling before downscaling (images) / rejection (everything else). */
+export declare const MAX_FILE_BYTES: number;
+/** Per-file inline budget for text-like content, in characters. */
+export declare const MAX_INLINE_CHARS_PER_FILE = 8000;
+/** Total inline budget across all attachments in one turn. */
+export declare const MAX_INLINE_CHARS_TOTAL = 20000;
+export type AssistantAttachmentKind = "image" | "text" | "document";
+export type AssistantAttachmentStatus = "pending" | "uploading" | "ready" | "error";
+export type AttachmentRejection = "too-many" | "too-large" | "empty" | "unreadable" | "unsupported-image";
+/**
+ * Thrown while PREPARING a file (after it passed `validateFile`) to reject it
+ * with a specific reason rather than the generic 'unreadable'.
+ *
+ * `validateFile` runs before the bytes have been touched, so it cannot know
+ * whether an oversized image will actually survive the downscale — that verdict
+ * only exists once the browser has tried to rasterise it.
+ */
+export declare class AttachmentRejectedError extends Error {
+    readonly reason: AttachmentRejection;
+    constructor(reason: AttachmentRejection);
+}
+export interface AssistantAttachment {
+    /** Client-side id; stable for the lifetime of the draft + the sent message. */
+    id: string;
+    filename: string;
+    mimeType: string;
+    /** Size of the bytes we actually kept (post-downscale for images). */
+    size: number;
+    kind: AssistantAttachmentKind;
+    status: AssistantAttachmentStatus;
+    /** Object/data URL for the composer thumbnail. Images only; never persisted. */
+    previewUrl?: string;
+    /**
+     * A smaller `data:` URL of the same image, sized for the request body rather
+     * than for the eye. Preferred over `previewUrl` when building the multimodal
+     * parts; see `MAX_TURN_BODY_BYTES`. Images only; never persisted.
+     */
+    inlineDataUrl?: string;
+    /** wspace-files-svc id, once the upload lands. */
+    fileId?: string;
+    /** Short-lived presigned URL, resolved at send time. */
+    downloadUrl?: string;
+    /**
+     * Inlined content for this attachment, already truncated to
+     * `MAX_INLINE_CHARS_PER_FILE`. Text files carry the file itself; PDF/DOCX/XLSX
+     * carry whatever `extractDocumentText` pulled out of them (BOFF-6291).
+     */
+    textContent?: string;
+    /** True when `textContent` is a prefix of a longer file. */
+    textTruncated?: boolean;
+    /**
+     * Outcome of the client-side document extraction. Present on every `document`
+     * we ATTEMPTED to read — including the failures, which is the point: a scanned
+     * or encrypted PDF has to reach the model as a sentence rather than as
+     * nothing. Absent means no extractor exists for the type.
+     */
+    extraction?: DocumentExtraction;
+    /**
+     * Per-page text for a PDF, kept so the SHARED inline budget can also cut on a
+     * page boundary rather than mid-sentence. Already trimmed to the per-file
+     * budget at prepare time, so this never holds a whole 50-page document.
+     * Draft-only; `toMessageAttachment` never carries it to storage.
+     */
+    documentPages?: string[];
+    /** Human-readable failure reason when `status === 'error'`. */
+    error?: string;
+    /**
+     * Why an upload that is still `uploading` is taking so long — e.g. "File service
+     * is starting up — retry 2 of 3".
+     *
+     * wspace-files-svc runs at minReplicas 0 and needs >=51s to bind its port against
+     * the gateway's 15s budget, so the first attachment after a quiet period
+     * legitimately sits for about a minute while fe-libs walks its retry ladder. A
+     * spinner alone reads as a hang. Draft-only, and NEVER a failure: `status` is still
+     * `uploading` and `error` is still unset.
+     */
+    progressNote?: string;
+}
+/**
+ * The slice of an attachment that is safe to keep on a sent message.
+ *
+ * Conversations are persisted to (profile-scoped) localStorage by the assistant
+ * store, so the heavy fields — the base64 `previewUrl` and the inlined
+ * `textContent` — MUST NOT travel here: five 1280px JPEG data URLs would exhaust
+ * the ~5 MB quota on their own and take the whole conversation history down with
+ * them. The bubble re-resolves a thumbnail from `fileId` on demand instead, the
+ * same way the pest-scan list does.
+ */
+export interface AssistantMessageAttachment {
+    id: string;
+    filename: string;
+    mimeType: string;
+    size: number;
+    kind: AssistantAttachmentKind;
+    fileId?: string;
+}
+export declare function toMessageAttachment(attachment: AssistantAttachment): AssistantMessageAttachment;
+export declare function getExtension(filename: string): string;
+export declare function classifyAttachment(mimeType: string, filename: string): AssistantAttachmentKind;
+/**
+ * Document formats we can turn into text in the browser (BOFF-6291).
+ *
+ * Anything else stays a `document` with no extraction, and the prompt block
+ * says so — the honest fallback that used to be the ONLY behaviour.
+ */
+export type { DocumentFormat } from './documentText';
+/**
+ * Which extractor (if any) can read this file.
+ *
+ * MIME first, extension second — same order as `classifyAttachment`, and for
+ * the same reason: Windows reports `application/octet-stream` for plenty of
+ * files whose extension is perfectly informative.
+ */
+export declare function detectDocumentFormat(mimeType: string, filename: string): DocumentFormat | null;
+/**
+ * The composer's `<input accept>` — DERIVED from what we can actually read.
+ *
+ * It used to be a hand-written list (`…,.pdf,.csv,.json,.md,.txt,.xlsx,.docx`)
+ * that invited exactly the files the model could not see: a farmer picked a
+ * soil-test PDF because the picker offered it, and the assistant then asked
+ * them to paste it as text. Building the list from `TEXT_EXTENSIONS` and
+ * `DOCUMENT_EXTENSIONS` makes that class of mismatch a compile-time
+ * impossibility rather than a thing to remember.
+ */
+export declare const ATTACHMENT_ACCEPT: string;
+export declare function formatBytes(bytes: number): string;
+/**
+ * Is there attachment work in flight that must block sending?
+ *
+ * `preparingCount` counts files the user has ALREADY dropped/picked but whose
+ * image-downscale or text-read has not resolved yet. Those files have no id and
+ * no row in `attachments`, so a check that looked only at `attachments` reported
+ * "idle" during the whole preparation window — the composer stayed sendable, the
+ * turn went out without the photo, and the photo then attached itself to the
+ * user's NEXT message. Both halves must be counted.
+ */
+export declare function hasAttachmentWorkInFlight(preparingCount: number, attachments: AssistantAttachment[]): boolean;
+/**
+ * The attachments a send would ACTUALLY carry to the model.
+ *
+ * This is the single definition of "sendable" — `buildAttachmentPromptBlock`,
+ * `buildPromptParts`, `countInlineImageCandidates` and the composer's send
+ * handler all route through it, so the set the user is shown and the set the
+ * model receives cannot drift apart by one of them being updated and the others
+ * not.
+ *
+ * `status` is the whole test, and that is deliberate rather than lazy: an
+ * attachment whose content is already inlined does not need its upload to have
+ * worked, so `useAssistantAttachments` marks a text file — and, since
+ * BOFF-6291, a document whose text WAS extracted — `ready` even when the upload
+ * failed. Such a file is sendable and does not block: its contents travel in
+ * the prompt block, and all it lost is the URL. Only attachments with nothing
+ * left to send (an image, or a document that could not be read) reach 'error',
+ * and those are exactly the ones worth stopping a turn for.
+ */
+export declare function getSendableAttachments(attachments: AssistantAttachment[]): AssistantAttachment[];
+/** Why a draft cannot be sent yet, as far as its attachments are concerned. */
+export type AttachmentSendBlocker = "in-flight" | "failed";
+/**
+ * Whether the attachments block sending, and why — `null` when they do not.
+ *
+ * Two distinct reasons, deliberately not collapsed into one boolean:
+ *
+ * - `'in-flight'` is momentary and resolves itself; the composer shows a
+ *   spinner and the user just waits.
+ * - `'failed'` never resolves on its own. It is the case this function was
+ *   added for: a failed attachment is omitted from the outgoing turn by
+ *   `getSendableAttachments`, but send used to stay enabled as long as there
+ *   was message text, and `clear()` then wiped the failed chip along with the
+ *   draft. So the user watched their photo's chip vanish into a sent message
+ *   that never contained it, and the assistant answered a question about an
+ *   image it was never given. Blocking is the honest response: the chip offers
+ *   both retry and remove, so the user picks whether the file matters, and
+ *   whichever they pick the UI and the model end up agreeing.
+ *
+ * In-flight is reported first: while an upload is still running the failure is
+ * not yet final, and "wait" is better advice than "retry or remove".
+ *
+ * Nothing here needs to special-case text files or extracted documents: they
+ * never reach 'error' in the first place (see `getSendableAttachments`), so a
+ * soil-test PDF the browser read but the file library refused still sends, with
+ * its text, and never blocks.
+ */
+export declare function getAttachmentSendBlocker(preparingCount: number, attachments: AssistantAttachment[]): AttachmentSendBlocker | null;
+/**
+ * Gate a candidate file. Images over the ceiling are still accepted — the
+ * composer downscales them before upload, so a 12 MB phone photo is fine while
+ * a 12 MB PDF is not.
+ *
+ * That exemption is a PROMISE, not a fact: it holds only if the browser can
+ * actually rasterise the image. When it cannot (HEIC), `prepareFile` re-applies
+ * this ceiling to the original bytes and rejects there instead.
+ */
+export declare function validateFile(file: File, currentCount: number): AttachmentRejection | null;
+/**
+ * Truncate on a line boundary where possible, so an inlined CSV/JSON prefix ends
+ * at a row rather than mid-token (which reads as corrupt data to the model).
+ */
+export declare function truncateForInline(content: string, limit: number): {
+    text: string;
+    truncated: boolean;
+};
+/**
+ * What the modelled body genuinely misses: `buildPromptForMode` prepends its
+ * preambles AFTER this block is built, and `parts[0]` duplicates the whole
+ * prompt, so each is charged twice.
+ *
+ *   api-calls preamble   ~493 bytes  x2 = ~986
+ *   language directive   ~290 bytes  x2 = ~580   (BOFF-7107)
+ *                                    total ~1,566
+ *
+ * The old 1,024 covered only the api-calls preamble, so adding the language
+ * directive could push a turn that `fitInlineBudget` promised would keep its
+ * pixels over the cap — and `buildPromptParts` would then demote the very image
+ * the question was about.
+ *
+ * The GraphQL document and page context remain covered many times over by
+ * `TURN_BODY_HEADROOM_BYTES`. Still deliberately tight: every byte here is a
+ * byte of document text a farmer does not get.
+ */
+export declare const PROMPT_ENVELOPE_RESERVE_BYTES = 2048;
+/**
+ * Render the attachment block appended to the outgoing prompt. Returns '' when
+ * there is nothing to say, so callers can concatenate unconditionally.
+ *
+ * `userText` is the user's own message — the rest of the prompt this block will
+ * be concatenated with. It is optional only so existing callers and tests keep
+ * compiling; passing it is what lets the budget be measured against the real
+ * turn rather than against the block alone.
+ *
+ * Attachments that failed to upload are omitted: the user already sees the
+ * failure in the composer, and a half-described file only confuses the model.
+ */
+export declare function buildAttachmentPromptBlock(attachments: AssistantAttachment[], userText?: string): string;
+/**
+ * Compose the text actually sent to the agent: the user's words, then the
+ * attachment block. The user-facing bubble keeps the raw text (attachments are
+ * rendered as chips there), matching how `buildPromptForMode` already separates
+ * agent-only preamble from displayed content.
+ */
+export declare function buildPromptWithAttachments(content: string, attachments: AssistantAttachment[]): string;
+export type { AssistantPromptPart };
+/**
+ * How many images may travel INLINE in one turn.
+ *
+ * Inline bytes are what make vision work without the sandbox needing egress to
+ * our storage. Images beyond the budget still travel, by URL only, and the
+ * prompt block still describes them.
+ */
+export declare const MAX_INLINE_IMAGE_PARTS = 3;
+/**
+ * Belt-and-braces per-turn ceiling on base64 characters.
+ *
+ * Kept as a cheap guard against a pathological single image, but it is NO
+ * LONGER the operative limit — `MAX_TURN_BODY_BYTES` is. See below for why the
+ * previous 1.5M-character budget was a fiction.
+ */
+export declare const MAX_INLINE_IMAGE_BASE64_CHARS = 1500000;
+/**
+ * The real ceiling: what the gateway will accept as a request body.
+ *
+ * `wspace-public-gateway` enforces `MAX_REQUEST_BODY_SIZE`, and both the alpha
+ * and prod configs set it to **256kb** (`burdenoff-gitops`
+ * `apps/config-workspace{,-prod}/wspace-public-gateway-config.yaml`). It is
+ * checked against `Content-Length` before authentication and before anything is
+ * forwarded, and it answers 413 with a JSON body — which fe-libs' `graphqlFetch`
+ * maps to the generic 4xx sentence, discarding the status. So an oversized turn
+ * does not degrade: it dies, and the user is told to refresh.
+ *
+ * The old budget (1.5M base64 characters ≈ 1.43 MB) was ~5.7x that cap, so a
+ * single ordinary 1280px photo — 150-400 KB, i.e. 200-530 KB of base64 — was
+ * enough to lose the whole turn. Measure the body instead of guessing at it.
+ */
+export declare const MAX_TURN_BODY_BYTES = 262144;
+/**
+ * Headroom left for everything `estimateTurnBodyBytes` does not model: the
+ * GraphQL query document, the operation name, the sandbox id / path / method,
+ * the context input and the page context.
+ *
+ * Measured, that overhead is under 1 KB — the ProxySandboxRequest document is
+ * ~150 bytes and the page context a few hundred. 32 KB is therefore deliberately
+ * ~30x the real figure, because the two ways of being wrong are not
+ * symmetrical: reserve too much and one photo travels as a link instead of as
+ * pixels; reserve too little and the entire turn is rejected and the farmer's
+ * question is lost.
+ */
+export declare const TURN_BODY_HEADROOM_BYTES = 32768;
+/** What the modelled part of the body must fit inside. */
+export declare const MAX_INLINE_TURN_BODY_BYTES: number;
+/**
+ * Encode settings for the copy of an image that travels INSIDE the turn.
+ *
+ * Separate from the upload encode (1280px / q0.72) on purpose: the file that
+ * lands in the farmer's file library should not be degraded to fit a transport
+ * limit. At 768px / q0.6 a photo is typically 40-90 KB — 53-120 KB of base64 —
+ * so one image fits inside `MAX_INLINE_TURN_BODY_BYTES` with room for the
+ * prompt, and often two do. Vision models downsample to roughly this size
+ * anyway, so the diagnostic detail that matters survives.
+ */
+export declare const INLINE_IMAGE_MAX_DIM = 768;
+export declare const INLINE_IMAGE_QUALITY = 0.6;
+/**
+ * Estimate the bytes the prompt + parts will occupy in the POSTed body.
+ *
+ * Shaped like the JSON fe-libs actually builds (`{ mode, prompt, pageContext,
+ * parts }` inside `proxySandboxRequest.body`), so the number tracks the thing
+ * being limited rather than a proxy for it. Deliberately an UNDER-estimate of
+ * the full request — `TURN_BODY_HEADROOM_BYTES` covers the difference.
+ */
+export declare function estimateTurnBodyBytes(promptText: string, parts?: AssistantPromptPart[]): number;
+/**
+ * How many attachments COULD have travelled as pixels — i.e. are ready images
+ * that have a `data:` URL to inline.
+ *
+ * Compared against how many actually did, this is what tells the user their
+ * photo was demoted to a link. Without it the deterministic budget path is
+ * silent, and only the transport-rejection path ever admits to anything.
+ */
+export declare function countInlineImageCandidates(attachments: AssistantAttachment[]): number;
+/** How many parts actually carry image bytes. */
+export declare function countInlinedImageParts(parts: AssistantPromptPart[] | undefined): number;
+/** Split a `data:<mime>;base64,<payload>` URL. Returns null for anything else. */
+export declare function parseDataUrl(dataUrl: string): {
+    mimeType: string;
+    base64: string;
+} | null;
+/**
+ * Build the structured multimodal turn.
+ *
+ * `promptText` MUST be the exact string also sent as `prompt`, so the two
+ * channels are equivalent: a bridge that understands `parts` sees everything a
+ * text-only bridge sees, plus the images. Returns `undefined` when there is
+ * nothing an image/file part could add, which keeps the wire body byte-identical
+ * to a pre-multimodal client for every ordinary text turn.
+ */
+export declare function buildPromptParts(promptText: string, attachments: AssistantAttachment[]): AssistantPromptPart[] | undefined;
+//# sourceMappingURL=attachments.d.ts.map

package/dist/shared/assistant/attachments.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"attachments.d.ts","sourceRoot":"","sources":["../../../src/shared/assistant/attachments.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAIH,OAAO,EAIL,KAAK,kBAAkB,EACvB,KAAK,cAAc,EACpB,MAAM,gBAAgB,CAAC;AAExB,eAAO,MAAM,eAAe,IAAI,CAAC;AAEjC,kFAAkF;AAClF,eAAO,MAAM,cAAc,QAAmB,CAAC;AAE/C,mEAAmE;AACnE,eAAO,MAAM,yBAAyB,OAAQ,CAAC;AAE/C,8DAA8D;AAC9D,eAAO,MAAM,sBAAsB,QAAS,CAAC;AAE7C,MAAM,MAAM,uBAAuB,GAAG,OAAO,GAAG,MAAM,GAAG,UAAU,CAAC;AAEpE,MAAM,MAAM,yBAAyB,GACjC,SAAS,GACT,WAAW,GACX,OAAO,GACP,OAAO,CAAC;AAEZ,MAAM,MAAM,mBAAmB,GAC3B,UAAU,GACV,WAAW,GACX,OAAO,GACP,YAAY,GACZ,mBAAmB,CAAC;AAExB;;;;;;;GAOG;AACH,qBAAa,uBAAwB,SAAQ,KAAK;IACpC,QAAQ,CAAC,MAAM,EAAE,mBAAmB;gBAA3B,MAAM,EAAE,mBAAmB;CAIjD;AAED,MAAM,WAAW,mBAAmB;IAClC,+EAA+E;IAC/E,EAAE,EAAE,MAAM,CAAC;IACX,QAAQ,EAAE,MAAM,CAAC;IACjB,QAAQ,EAAE,MAAM,CAAC;IACjB,sEAAsE;IACtE,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,uBAAuB,CAAC;IAC9B,MAAM,EAAE,yBAAyB,CAAC;IAClC,gFAAgF;IAChF,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB;;;;OAIG;IACH,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,kDAAkD;IAClD,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,wDAAwD;IACxD,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB;;;;OAIG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,4DAA4D;IAC5D,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB;;;;;OAKG;IACH,UAAU,CAAC,EAAE,kBAAkB,CAAC;IAChC;;;;;OAKG;IACH,aAAa,CAAC,EAAE,MAAM,EAAE,CAAC;IACzB,+DAA+D;IAC/D,KAAK,CAAC,EAAE,MAAM,CAAC;IACf;;;;;;;;;OASG;IACH,YAAY,CAAC,EAAE,MAAM,CAAC;CACvB;AAED;;;;;;;;;GASG;AACH,MAAM,WAAW,0BAA0B;IACzC,EAAE,EAAE,MAAM,CAAC;IACX,QAAQ,EAAE,MAAM,CAAC;IACjB,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,uBAAuB,CAAC;IAC9B,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;AAED,wBAAgB,mBAAmB,CACjC,UAAU,EAAE,mBAAmB,GAC9B,0BAA0B,CAS5B;AA+BD,wBAAgB,YAAY,CAAC,QAAQ,EAAE,MAAM,GAAG,MAAM,CAGrD;AAED,wBAAgB,kBAAkB,CAChC,QAAQ,EAAE,MAAM,EAChB,QAAQ,EAAE,MAAM,GACf,uBAAuB,CAYzB;AAED;;;;;GAKG;AACH,YAAY,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAgBrD;;;;;;GAMG;AACH,wBAAgB,oBAAoB,CAClC,QAAQ,EAAE,MAAM,EAChB,QAAQ,EAAE,MAAM,GACf,cAAc,GAAG,IAAI,CAMvB;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,iBAAiB,QAKnB,CAAC;AAEZ,wBAAgB,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAIjD;AAED;;;;;;;;;GASG;AACH,wBAAgB,yBAAyB,CACvC,cAAc,EAAE,MAAM,EACtB,WAAW,EAAE,mBAAmB,EAAE,GACjC,OAAO,CAQT;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,sBAAsB,CACpC,WAAW,EAAE,mBAAmB,EAAE,GACjC,mBAAmB,EAAE,CAEvB;AAED,+EAA+E;AAC/E,MAAM,MAAM,qBAAqB,GAAG,WAAW,GAAG,QAAQ,CAAC;AAE3D;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,wBAAgB,wBAAwB,CACtC,cAAc,EAAE,MAAM,EACtB,WAAW,EAAE,mBAAmB,EAAE,GACjC,qBAAqB,GAAG,IAAI,CAM9B;AAED;;;;;;;;GAQG;AACH,wBAAgB,YAAY,CAC1B,IAAI,EAAE,IAAI,EACV,YAAY,EAAE,MAAM,GACnB,mBAAmB,GAAG,IAAI,CAM5B;AAED;;;GAGG;AACH,wBAAgB,iBAAiB,CAC/B,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,GACZ;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,OAAO,CAAA;CAAE,CAQtC;AA8ZD;;;;;;;;;;;;;;;;;GAiBG;AACH,eAAO,MAAM,6BAA6B,OAAQ,CAAC;AA+FnD;;;;;;;;;;;GAWG;AACH,wBAAgB,0BAA0B,CACxC,WAAW,EAAE,mBAAmB,EAAE,EAClC,QAAQ,SAAK,GACZ,MAAM,CAUR;AAED;;;;;GAKG;AACH,wBAAgB,0BAA0B,CACxC,OAAO,EAAE,MAAM,EACf,WAAW,EAAE,mBAAmB,EAAE,GACjC,MAAM,CAIR;AAID;;;;;;GAMG;AAIH,OAAO,KAAK,EAAE,mBAAmB,EAAE,MAAM,SAAS,CAAC;AAEnD,YAAY,EAAE,mBAAmB,EAAE,CAAC;AAEpC;;;;;;GAMG;AACH,eAAO,MAAM,sBAAsB,IAAI,CAAC;AAExC;;;;;;GAMG;AACH,eAAO,MAAM,6BAA6B,UAAY,CAAC;AAEvD;;;;;;;;;;;;;;GAcG;AACH,eAAO,MAAM,mBAAmB,SAAyB,CAAC;AAE1D;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,wBAAwB,QAAS,CAAC;AAE/C,0DAA0D;AAC1D,eAAO,MAAM,0BAA0B,QACS,CAAC;AAEjD;;;;;;;;;GASG;AACH,eAAO,MAAM,oBAAoB,MAAM,CAAC;AACxC,eAAO,MAAM,oBAAoB,MAAM,CAAC;AAWxC;;;;;;;GAOG;AACH,wBAAgB,qBAAqB,CACnC,UAAU,EAAE,MAAM,EAClB,KAAK,CAAC,EAAE,mBAAmB,EAAE,GAC5B,MAAM,CAIR;AAED;;;;;;;GAOG;AACH,wBAAgB,0BAA0B,CACxC,WAAW,EAAE,mBAAmB,EAAE,GACjC,MAAM,CAMR;AAED,iDAAiD;AACjD,wBAAgB,sBAAsB,CACpC,KAAK,EAAE,mBAAmB,EAAE,GAAG,SAAS,GACvC,MAAM,CAIR;AAED,kFAAkF;AAClF,wBAAgB,YAAY,CAC1B,OAAO,EAAE,MAAM,GACd;IAAE,QAAQ,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GAAG,IAAI,CAG7C;AAiGD;;;;;;;;GAQG;AACH,wBAAgB,gBAAgB,CAC9B,UAAU,EAAE,MAAM,EAClB,WAAW,EAAE,mBAAmB,EAAE,GACjC,mBAAmB,EAAE,GAAG,SAAS,CA4DnC"}