@feedmepos/mf-menu 0.32.72-dev.1 → 0.32.73-dev.1

package/dist/app.js

@@ -1,4 +1,4 @@
-import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-D1p44Rbf.js";
+import { F as e, i as r, j as o, o as t, r as i, u as p } from "./app-C2sqVqgY.js";
 export {
   e as FmApp,
   r as i18nMessages,

package/dist/apps/mf-menu/src/api/media.d.ts

@@ -119,8 +119,8 @@ export declare const mediaService: {
      * alone. For rewriting the original itself, see `updateOriginal` — same endpoint,
      * different mode, and the only one that is not AI generation.
      *
-     * Both modes here are AI generation, and which one runs is decided by the field that
-     * is filled (either, or both):
+     * Normally this endpoint runs AI generation, and which mode runs is decided by the
+     * field that is filled:
      * - `base64` stores the supplied bytes as the *source* and queues generation from
      *   them. It is not a passthrough: the service trims uniform bars off the source and
      *   hands it to the model, so what lands is a redraw of the merchant's image at this
@@ -129,9 +129,13 @@ export declare const mediaService: {
      * - `instruction` queues a re-edit of the variant's *current* image (with
      *   `regenerateFromOrigin`, of the original instead, discarding previous edits).
      *
-     * Either way the ratio drops back to `pending` for ~40s and the request consumes one
-     * AI generation from the business's license allowance. The service rejects an update
-     * carrying neither field with `400 INVALID_PARAM`.
+     * - `directUpload: true` together with `base64` stores those bytes directly as the
+     *   named ratio. It is synchronous, does not use an AI-generation allowance, and is
+     *   the mode used when a merchant uploads the final ratio image.
+     *
+     * The two AI modes drop the ratio back to `pending` for ~40s and consume one AI
+     * generation from the business's license allowance. The service rejects an update
+     * carrying neither `base64` nor `instruction` with `400 INVALID_PARAM`.
      *
      * Unlike an upload these bytes do pass through the service pod — there is no
      * variant-level `upload-intent` — so callers must send a cropped, re-encoded image
@@ -146,6 +150,8 @@ export declare const mediaService: {
         aspectRatio: AspectRatio;
         base64?: string;
         instruction?: string;
+        /** Store `base64` as this ratio's final bytes instead of using it as an AI source. */
+        directUpload?: boolean;
         /**
          * Instruction-mode modifier: re-derive from the original instead of the current
          * variant. Sent only when true — the service reads the mode off which key is

package/dist/apps/mf-menu/src/components/feature/TreeEditor/composable/productImages.d.ts

@@ -251,21 +251,11 @@ export declare function generateAspectRatios(itemId: string, image: FdoMenuV4Ite
 /** `/images/update` carries its bytes inline, so the file has to become a data URL. */
 export declare function readFileAsDataUrl(file: File): Promise<string>;
 /**
- * Queues one ratio to be generated from a photo the merchant supplies, and marks it
- * custom.
- *
- * Named "replace" after what it does for the merchant, not after what reaches storage:
- * media-service stores these bytes as the generation *source* and hands them to the
- * model (`/images/update` with `base64`), so the variant ends up a redraw of the
- * supplied photo rather than the photo itself. Cropping to `ratio` in the editor is what
- * frames the subject for the model. It no longer pads the source to the ratio first: the
- * service trims uniform bars off a generation source, so the bars were discarded before
- * the model ever saw them — a real crop at least lets the merchant choose what survives.
- *
- * So this is asynchronous and billable, exactly like `regenerateAspectRatio`: the ratio
- * drops back to `pending` for ~40s and one AI generation is consumed. Callers must show
- * the ratio as generating and poll `listImages` — treating the returned image as final
- * shows the merchant the old variant and calls it done.
+ * Replaces one ratio with the merchant's final image and marks it custom.
+ *
+ * The image editor crops to the requested ratio, then `/images/update` stores those
+ * bytes directly with `directUpload: true`. This is synchronous and never invokes AI,
+ * so the preview can refresh immediately rather than entering the generation poll.
  *
  * The variant keeps its URL, so the only difference between the input image and the
  * returned one is `imageSet[ratio]`: it now carries the variant URL as a marker meaning