@feedmepos/mf-order-setting 0.0.79 → 0.0.80

package/src/views/order-settings/queue/QueueSetting.vue

@@ -15,9 +15,10 @@ import { useCoreStore, useI18n } from '@feedmepos/mf-common'
 import { useSnackbarFunctions } from '@/components/snackbar'
 import { useDialog } from '@feedmepos/ui-library'
 import PresetRemarksSheet from './PresetRemarksSheet.vue'
+import { nextCodeSettingBand } from './code-setting-band'
 
 const { t } = useI18n()
-const { showSuccess } = useSnackbarFunctions()
+const { showSuccess, showError } = useSnackbarFunctions()
 const { currentRestaurant } = useCoreStore()
 const { isLoading, startAsyncCallWithErr, startLoading } = useLoading()
 
@@ -49,6 +50,11 @@ async function readOrderSetting(): Promise<OrderSettingsDto> {
 }
 
 async function updateOrderSetting() {
+  const problem = validateEstimates()
+  if (problem) {
+    showError(problem)
+    return
+  }
   await startAsyncCallWithErr(async () => {
     if (orderSettingDefault.value) {
       await OrderSettingApi.updateOrderSetting(
@@ -69,6 +75,7 @@ async function init() {
     orderSettingDefault.value = await readOrderSetting()
     if (orderSettingDefault.value?.queueSettings) {
       queueSettings.value = { ...defaultQueueSetting, ...orderSettingDefault.value.queueSettings }
+      normalizeEstimates()
     }
 
     // Load restaurant settings for preset remarks
@@ -94,12 +101,19 @@ function addCodeSetting() {
   if (!queueSettings.value.codeSettings) {
     queueSettings.value.codeSettings = []
   }
+  // Continue from the previous segment instead of defaulting to 1-99 again.
+  // A party is assigned to a segment by FIRST match, so two segments whose
+  // bands overlap are not two lines the server can tell apart: everything the
+  // earlier band covers is issued its prefix, and the customer's "parties
+  // ahead" would count a series they are not in. Seeding disjoint keeps the
+  // config in the shape the position count assumes.
+  const previous = queueSettings.value.codeSettings.at(-1)
   queueSettings.value.codeSettings.push({
     start: 0,
     end: 100,
     current: 0,
     prefix: '',
-    pax: { min: 1, max: 99 }
+    pax: nextCodeSettingBand(previous?.pax)
   })
 }
 
@@ -107,6 +121,178 @@ function removeCodeSetting(index: number) {
   queueSettings.value.codeSettings?.splice(index, 1)
 }
 
+// ---- Wait estimate -------------------------------------------------------
+//
+// One band table per code setting: "groups ahead in line" -> minutes. There is
+// deliberately no party-size axis inside it. A code setting already carries a
+// pax range, so subdividing pax AGAIN in here duplicated that partition and
+// read as if each row were a separate line — it is not. Position is counted
+// over the whole line (`beforeInLine`) and the auto-call picker is global FIFO,
+// so a large party that arrives fourth is still called fourth.
+//
+// A merchant who wants different estimates per party size adds a SECOND CODE
+// SETTING with its own pax range; that segment carries its own band table.
+// Which buys different minutes and its own code series — not a separate line.
+//
+// `upTo: null` on the last band means "no upper limit", so every position
+// resolves. `paxUpTo` stays on the stored row, pinned to null: the DTO still
+// has the field, and keeping it null is what makes `resolveWaitEstimate`'s
+// unknown-pax fallback land here.
+
+function estimateRows(index: number) {
+  return (queueSettings.value.codeSettings?.[index] as any)?.waitEstimate ?? []
+}
+
+/**
+ * The single row being edited.
+ *
+ * Tolerates a legacy multi-row config by preferring the open-ended row: that is
+ * the row `resolveWaitEstimate` falls back to, so it is the one whose numbers
+ * were actually reaching customers. `normalizeEstimates` collapses to it on
+ * load, so this only matters for the render between load and collapse.
+ */
+function estimateRow(index: number): any | null {
+  const rows = estimateRows(index)
+  if (!rows.length) return null
+  return rows.find((r: any) => r?.paxUpTo === null) ?? rows[rows.length - 1]
+}
+
+function estimateBands(index: number): any[] {
+  return estimateRow(index)?.bands ?? []
+}
+
+/**
+ * Collapse any stored config to the single open-ended row this editor supports.
+ *
+ * Called on load. The party-size axis is gone, so a multi-row config cannot be
+ * represented — and silently editing only one row while saving all of them
+ * would write back numbers the merchant could not see.
+ */
+function normalizeEstimates() {
+  for (const setting of (queueSettings.value.codeSettings ?? []) as any[]) {
+    const rows = setting?.waitEstimate
+    if (!Array.isArray(rows) || rows.length <= 1) continue
+    const keep = rows.find((r: any) => r?.paxUpTo === null) ?? rows[rows.length - 1]
+    setting.waitEstimate = [{ paxUpTo: null, bands: keep?.bands ?? [] }]
+  }
+}
+
+/**
+ * Lower edge of a band, derived from its predecessor's bound.
+ *
+ * Only the upper bound is stored — bands are contiguous, which validation
+ * enforces. Showing "3-4" rather than "Up to 4" saves the reader inferring
+ * where the band starts.
+ */
+function bandRangeStart(index: number, b: number): number {
+  if (b === 0) return 1
+  return (estimateBands(index)[b - 1]?.upTo ?? 0) + 1
+}
+
+function enableEstimate(index: number) {
+  const setting = queueSettings.value.codeSettings?.[index] as any
+  if (!setting) return
+  // A single open-ended band: the smallest configuration that is already valid.
+  // Seeded above zero so the row is valid on sight; `minutes: 0` would now be
+  // rejected on save, and a merchant should not have to discover that.
+  setting.waitEstimate = [{ paxUpTo: null, bands: [{ upTo: null, minutes: 5 }] }]
+}
+
+function disableEstimate(index: number) {
+  const setting = queueSettings.value.codeSettings?.[index] as any
+  if (!setting) return
+  // Explicit empty array, not undefined: the backend preserves an omitted
+  // waitEstimate, so clearing has to be stated to take effect.
+  setting.waitEstimate = []
+}
+
+function addEstimateBand(index: number) {
+  const row = estimateRow(index)
+  if (!row?.bands?.length) return
+  const last = row.bands[row.bands.length - 1]
+  // Seed from the PREVIOUS band's bound, not the band count. Counting produced
+  // a bound unrelated to what the merchant typed — with band 0 set to 50, the
+  // next seeded to 10 and rendered as "51-10", which save then rejected.
+  const prevBound = row.bands.length > 1 ? row.bands[row.bands.length - 2].upTo : null
+  last.upTo = last.upTo ?? (prevBound ?? 0) + 5
+  row.bands.push({ upTo: null, minutes: last.minutes })
+}
+
+function removeEstimateBand(index: number, bandIndex: number) {
+  const row = estimateRow(index)
+  if (!row?.bands) return
+  row.bands.splice(bandIndex, 1)
+  // The final band is always the open-ended one, whichever band that now is.
+  if (row.bands.length) row.bands[row.bands.length - 1].upTo = null
+}
+
+function updateBandBound(index: number, bandIndex: number, value: string) {
+  const row = estimateRow(index)
+  if (row?.bands?.[bandIndex]) row.bands[bandIndex].upTo = value === '' ? null : Number(value)
+}
+
+function updateEstimateMinutes(index: number, bandIndex: number, value: string) {
+  const row = estimateRow(index)
+  if (row?.bands?.[bandIndex]) row.bands[bandIndex].minutes = value === '' ? 0 : Number(value)
+}
+
+/**
+ * Save-time validation. Returns the first problem found, or null.
+ *
+ * Deliberately blocks the save rather than warning: a band table with a gap or
+ * a missing open-ended tail resolves to no estimate for some customers, which
+ * looks like the feature is broken rather than misconfigured.
+ */
+function validateEstimates(): string | null {
+  const settings = queueSettings.value.codeSettings ?? []
+  for (const [i, setting] of settings.entries()) {
+    const rows = (setting as any).waitEstimate
+    if (!rows?.length) continue
+
+    const label = (setting.prefix || `#${i + 1}`) as string
+    const bands = rows[0]?.bands ?? []
+    if (!bands.length) return t('order.waitEstimateNoBands', { segment: label })
+
+    let prevBound = -1
+    let prevMinutes = -1
+    for (const [b, band] of bands.entries()) {
+      const isLast = b === bands.length - 1
+      // The open-ended band must be last and nowhere else, or some positions
+      // resolve to nothing while others match two bands.
+      if (isLast !== (band.upTo === null)) {
+        return t('order.waitEstimateBandTail', { segment: label })
+      }
+      if (band.upTo !== null) {
+        // `minutes` already gets this; `upTo` only got the ascending compare.
+        // The server schema is z.number().int().nonnegative().nullable(), so
+        // `2.5` passed here and then failed the save with a raw 422 the
+        // merchant cannot act on. `0` also passed, because prevBound starts at
+        // -1, and rendered as the empty band "1-0".
+        if (!Number.isInteger(band.upTo) || band.upTo < 1) {
+          return t('order.waitEstimateBandOrder', { segment: label })
+        }
+        if (band.upTo <= prevBound) return t('order.waitEstimateBandOrder', { segment: label })
+        prevBound = band.upTo
+      }
+      if (!Number.isInteger(band.minutes) || band.minutes < 1) {
+        // Was `< 0`, which accepted 0. `enableEstimate` seeds a single band, so
+        // a merchant could flip the master switch, add an estimate, save
+        // without editing, and publish "0+ min" to every customer with
+        // `ahead > 0` — a fabricated number, which is the outcome the rest of
+        // this feature is careful to avoid. Silence beats a wrong estimate, so
+        // an unedited estimate must not save.
+        return t('order.waitEstimateMinutesInvalid', { segment: label })
+      }
+      // More groups ahead is never faster.
+      if (band.minutes < prevMinutes) {
+        return t('order.waitEstimateMinutesOrder', { segment: label })
+      }
+      prevMinutes = band.minutes
+    }
+  }
+  return null
+}
+
 function updateCodeSetting(index: number, key: string, value: any) {
   if (queueSettings.value.codeSettings && queueSettings.value.codeSettings[index]) {
     const setting = queueSettings.value.codeSettings[index] as any
@@ -243,6 +429,18 @@ async function saveAllowOverrideQueueCode(value: boolean) {
           label-placement="right"
         />
 
+        <!--
+          Master switch. Bands are configured per code setting below; this
+          decides whether customers see any of them. Off by default, because
+          with nothing configured there is no defensible number to show.
+        -->
+        <FmSwitch
+          :model-value="queueSettings.showWaitEstimate ?? false"
+          @update:model-value="(v: boolean) => updateQueueSetting('showWaitEstimate', v)"
+          :label="t('order.showWaitEstimate')"
+          label-placement="right"
+        />
+
         <div class="flex flex-col gap-2">
           <span class="fm-typo-en-body-md-600">{{ t('order.autoSendKitchen') }}</span>
           <FmSelect
@@ -372,6 +570,100 @@ async function saveAllowOverrideQueueCode(value: boolean) {
                 />
               </div>
             </div>
+
+            <!--
+              Wait estimate for this code setting: "groups ahead in line" ->
+              minutes. One vertical list, no party-size axis — see the script
+              block for why. The last band is always open-ended, so every
+              position resolves to something.
+            -->
+            <div class="border-t border-gray-200 pt-4 flex flex-col gap-3">
+              <!-- gap + min-w-0 on the text column and shrink-0 on the button: the
+                   hint is a full sentence, and without these it pushed the button
+                   until its own label truncated to "Clear...". -->
+              <div class="flex justify-between items-start gap-4">
+                <div class="flex flex-col min-w-0">
+                  <span class="fm-typo-en-body-md-600">{{ t('order.waitEstimate') }}</span>
+                  <span class="text-xs text-gray-500">{{ t('order.waitEstimateHint') }}</span>
+                </div>
+                <FmButton
+                  v-if="!estimateBands(index).length"
+                  variant="secondary"
+                  class="shrink-0"
+                  :label="t('order.waitEstimateEnable')"
+                  icon="add"
+                  @click="enableEstimate(index)"
+                />
+                <FmButton
+                  v-else
+                  variant="secondary"
+                  color="error"
+                  class="shrink-0"
+                  :label="t('order.waitEstimateClear')"
+                  @click="disableEstimate(index)"
+                />
+              </div>
+
+              <!-- Vertical, one band per line. A single axis does not need a
+                   table: this drops the horizontal scroller, the pinned first
+                   column and the hover-revealed controls the two-axis grid
+                   required, and it grows downward instead of sideways. -->
+              <div v-if="estimateBands(index).length" class="flex flex-col">
+                <div class="flex items-center gap-3 text-xs text-gray-500 pb-1">
+                  <span class="w-[150px] shrink-0">{{ t('order.waitEstimateAheadHeader') }}</span>
+                  <span>{{ t('order.waitEstimateMinutesHeader') }}</span>
+                </div>
+                <div
+                  v-for="(band, b) in estimateBands(index)"
+                  :key="b"
+                  class="flex items-center gap-3 py-2 border-t border-gray-200"
+                >
+                  <div class="w-[150px] shrink-0 flex items-center gap-0.5">
+                    <template v-if="band.upTo !== null">
+                      <span class="whitespace-nowrap">{{ bandRangeStart(index, b) }}–</span>
+                      <FmTextField
+                        type="number"
+                        class="w-[70px]"
+                        :model-value="band.upTo"
+                        @update:model-value="(v: string) => updateBandBound(index, b, v)"
+                      />
+                    </template>
+                    <span v-else class="whitespace-nowrap">
+                      {{ bandRangeStart(index, b) }}+
+                    </span>
+                  </div>
+                  <div class="flex items-center gap-1">
+                    <FmTextField
+                      type="number"
+                      class="w-[80px]"
+                      :model-value="band.minutes"
+                      @update:model-value="(v: string) => updateEstimateMinutes(index, b, v)"
+                    />
+                    <span class="text-xs text-gray-500">{{ t('order.waitEstimateMinutesUnit') }}</span>
+                  </div>
+                  <!-- Always visible: the two-axis grid hid these until hover to
+                       save width, which left them invisible but still tappable on
+                       touch. With one column per row there is room to just show
+                       them. -->
+                  <FmButton
+                    v-if="estimateBands(index).length > 1"
+                    color="error"
+                    icon="close"
+                    :aria-label="t('order.waitEstimateRemoveBand')"
+                    :title="t('order.waitEstimateRemoveBand')"
+                    @click="removeEstimateBand(index, b)"
+                  />
+                </div>
+              </div>
+              <FmButton
+                v-if="estimateBands(index).length"
+                variant="secondary"
+                icon="add"
+                class="self-start"
+                :label="t('order.waitEstimateAddBand')"
+                @click="addEstimateBand(index)"
+              />
+            </div>
           </div>
         </div>
       </div>

package/src/views/order-settings/queue/code-setting-band.spec.ts

@@ -0,0 +1,69 @@
+import { describe, expect, it } from 'vitest'
+import { nextCodeSettingBand, MAX_PAX } from './code-setting-band'
+
+/**
+ * Guards the config shape the customer position count assumes.
+ *
+ * Segments are matched FIRST-match, so overlapping pax bands are not two lines
+ * the server can tell apart. The previous default seeded every new segment as
+ * pax 1-99, which meant a merchant who narrowed segment 0 to 1-4 and then
+ * clicked "add segment" produced exactly the overlap that makes a large party's
+ * "parties ahead" count the small-party series too.
+ */
+describe('nextCodeSettingBand', () => {
+  it('starts the first segment at 1', () => {
+    expect(nextCodeSettingBand(null)).toEqual({ min: 1, max: 99 })
+    expect(nextCodeSettingBand(undefined)).toEqual({ min: 1, max: 99 })
+  })
+
+  it('starts after the previous segment, never overlapping it', () => {
+    expect(nextCodeSettingBand({ min: 1, max: 4 })).toEqual({ min: 5, max: 99 })
+  })
+
+  it('runs the tail segment to the ceiling, leaving no pax uncovered', () => {
+    // A naive max(min, 99) gives 100-100 here, so pax 101+ would match no
+    // segment at all and get orphaned onto its own line.
+    expect(nextCodeSettingBand({ min: 1, max: 99 })).toEqual({ min: 100, max: MAX_PAX })
+  })
+
+  it('leaves no gap between consecutive bands', () => {
+    const first = nextCodeSettingBand(null)
+    const second = nextCodeSettingBand(first)
+    expect(second.min).toBe(first.max + 1)
+  })
+
+  it('never proposes a min above the pax ceiling', () => {
+    const band = nextCodeSettingBand({ min: 1, max: MAX_PAX + 500 })
+    expect(band.min).toBe(MAX_PAX)
+    expect(band.max).toBeGreaterThanOrEqual(band.min)
+  })
+
+  it('chains disjointly while pax range remains', () => {
+    // 1-99 then 100-999 covers the realistic case: small parties, large
+    // parties. Two segments is what the pax ceiling affords disjointly.
+    const first = nextCodeSettingBand(null)
+    const second = nextCodeSettingBand(first)
+    const overlaps = second.min <= first.max && second.max >= first.min
+    expect(overlaps).toBe(false)
+    expect([first, second]).toEqual([
+      { min: 1, max: 99 },
+      { min: 100, max: MAX_PAX }
+    ])
+  })
+
+  it('clamps once the pax range is exhausted, and that is safe', () => {
+    // A third segment cannot be disjoint — there is no pax left above 999. It
+    // clamps to the ceiling and therefore overlaps the segment before it.
+    //
+    // Deliberately not treated as a failure. Under FIRST-match the earlier
+    // segment claims the whole overlap, so the third simply never issues a
+    // code, and `sameSegmentFilter` subtracts preceding bands, so the customer
+    // count stays correct regardless. The outcome is a dead segment the
+    // merchant can see and edit, not a wrong number — which is exactly why the
+    // backend defends against overlap instead of trusting this helper.
+    const second = nextCodeSettingBand(nextCodeSettingBand(null))
+    const third = nextCodeSettingBand(second)
+    expect(third.min).toBe(MAX_PAX)
+    expect(third.min <= second.max).toBe(true)
+  })
+})

package/src/views/order-settings/queue/code-setting-band.ts

@@ -0,0 +1,27 @@
+/**
+ * Where a newly added queue segment's pax band should start.
+ *
+ * A party is assigned to a segment by FIRST match — `getCodeAndUpdateSetting`
+ * uses `findIndex`, `matchSegment` uses `find` — so overlapping bands are not
+ * two lines the server can distinguish: everything the earlier band covers is
+ * issued the earlier prefix, and the customer's "parties ahead" would count a
+ * series they are not in. The backend defends against overlap it finds in
+ * stored data, but the UI should not mint it in the first place.
+ *
+ * This used to seed `{ min: 1, max: 99 }` for every segment, so a merchant who
+ * narrowed segment 0 and then clicked "add" got a total overlap by default.
+ */
+export const MAX_PAX = 999;
+
+export type PaxBand = { min: number; max: number };
+
+export function nextCodeSettingBand(previous?: PaxBand | null): PaxBand {
+  if (!previous) return { min: 1, max: 99 };
+  const min = Math.min(previous.max + 1, MAX_PAX);
+  // Run the tail segment up to the ceiling rather than stopping at 99. A naive
+  // `max(min, 99)` yields the single-pax band 100-100 after a 1-99 first
+  // segment, which leaves pax 101+ matching NO segment - and a party matching
+  // nothing is orphaned onto its own line by `segmentScopeOf`. Covering to the
+  // ceiling keeps the configuration total.
+  return { min, max: min <= 99 ? 99 : MAX_PAX };
+}

package/src/views/order-settings/queue/queue-wait-estimate-dto.spec.ts

@@ -0,0 +1,131 @@
+import { OrderSettingUpdateDto } from '@entity'
+import { describe, expect, it } from 'vitest'
+
+/**
+ * mf-order saves order settings by running `OrderSettingUpdateDto.parse(...)` on the
+ * CLIENT and PUTting the result. Zod's default mode is 'strip', so anything the
+ * compiled-in schema does not know about is deleted before the request is sent —
+ * silently, and on every save.
+ *
+ * That is the whole reason `codeSettings[].id` exists and the reason the backend
+ * re-attaches `waitEstimate` from storage. These tests pin the client half of that
+ * contract: if `waitEstimate` / `id` / `showWaitEstimate` were added to the DO but
+ * not reached the DTO this view parses with, the merchant's configuration would
+ * never leave the browser and no backend test would notice.
+ */
+
+const bands = [
+  { upTo: 5, minutes: 15 },
+  { upTo: 20, minutes: 30 },
+  { upTo: null, minutes: 45 }
+]
+
+/** The shape `updateOrderSetting()` builds: whole settings + the edited queueSettings. */
+function payload(overrides: Record<string, unknown> = {}) {
+  return {
+    queueSettings: {
+      enableOrder: true,
+      autoCalledLimit: 0,
+      duration: 20,
+      showWaitEstimate: true,
+      codeSettings: [
+        {
+          id: '6a8541df1ab7f55006729a0a',
+          prefix: 'A',
+          start: 1,
+          end: 99,
+          current: 42,
+          pax: { min: 1, max: 4 },
+          waitEstimate: [{ paxUpTo: null, bands }]
+        }
+      ]
+    },
+    ...overrides
+  }
+}
+
+describe('OrderSettingUpdateDto — the client-side round trip mf-order actually performs', () => {
+  it('keeps waitEstimate through a parse, rather than stripping it', () => {
+    const parsed: any = OrderSettingUpdateDto.parse(payload())
+    const segment = parsed.queueSettings.codeSettings[0]
+
+    expect(segment.waitEstimate).toEqual([{ paxUpTo: null, bands }])
+  })
+
+  it('keeps the stable segment id, which is what preservation matches on', () => {
+    const parsed: any = OrderSettingUpdateDto.parse(payload())
+
+    expect(parsed.queueSettings.codeSettings[0].id).toBe('6a8541df1ab7f55006729a0a')
+  })
+
+  it('keeps the showWaitEstimate master switch', () => {
+    const parsed: any = OrderSettingUpdateDto.parse(payload())
+
+    expect(parsed.queueSettings.showWaitEstimate).toBe(true)
+  })
+
+  it('preserves an empty waitEstimate array — that is how a merchant clears one', () => {
+    const p = payload()
+    p.queueSettings.codeSettings[0].waitEstimate = []
+
+    const parsed: any = OrderSettingUpdateDto.parse(p)
+    expect(parsed.queueSettings.codeSettings[0].waitEstimate).toEqual([])
+  })
+
+  /**
+   * The editor no longer offers a party-size axis — it writes exactly one row,
+   * `paxUpTo: null`. The SCHEMA still accepts several, deliberately: that is what
+   * makes a legacy multi-row document loadable rather than a parse error, and it
+   * is why `normalizeEstimates` exists to collapse one on load. If this ever
+   * starts failing, a legacy config would 422 on save instead of being migrated.
+   */
+  it('still accepts a legacy multi-row estimate, so old configs can be loaded', () => {
+    const p = payload()
+    p.queueSettings.codeSettings[0].waitEstimate = [
+      { paxUpTo: 2, bands: [{ upTo: null, minutes: 10 }] },
+      { paxUpTo: null, bands: [{ upTo: null, minutes: 40 }] }
+    ] as any
+
+    const parsed: any = OrderSettingUpdateDto.parse(p)
+    expect(parsed.queueSettings.codeSettings[0].waitEstimate).toHaveLength(2)
+    expect(parsed.queueSettings.codeSettings[0].waitEstimate[0].paxUpTo).toBe(2)
+  })
+
+  it('round-trips the single open-ended row the editor now writes', () => {
+    const p = payload()
+    p.queueSettings.codeSettings[0].waitEstimate = [
+      {
+        paxUpTo: null,
+        bands: [
+          { upTo: 2, minutes: 10 },
+          { upTo: 4, minutes: 15 },
+          { upTo: null, minutes: 15 }
+        ]
+      }
+    ] as any
+
+    const parsed: any = OrderSettingUpdateDto.parse(p)
+    const rows = parsed.queueSettings.codeSettings[0].waitEstimate
+    expect(rows).toHaveLength(1)
+    expect(rows[0].paxUpTo).toBeNull()
+    expect(rows[0].bands.map((b: any) => [b.upTo, b.minutes])).toEqual([
+      [2, 10],
+      [4, 15],
+      [null, 15]
+    ])
+  })
+
+  /**
+   * The hazard itself, demonstrated rather than asserted about. An unknown key is
+   * dropped without error — which is exactly what an older portal bundle does to
+   * `waitEstimate`, and why the backend cannot treat an absent field as "clear it".
+   */
+  it('silently drops unknown keys, which is why absent must mean inherit', () => {
+    const p: any = payload()
+    p.queueSettings.codeSettings[0].somethingTheBundleDoesNotKnow = 'gone'
+
+    const parsed: any = OrderSettingUpdateDto.parse(p)
+    expect(parsed.queueSettings.codeSettings[0].somethingTheBundleDoesNotKnow).toBeUndefined()
+    expect(parsed.queueSettings.codeSettings[0].waitEstimate).toBeDefined()
+  })
+})

package/vite.config.ts

@@ -18,7 +18,7 @@ export default defineConfig(async (env) => {
     plugins: [vue()],
     resolve: {
       preserveSymlinks: true,
-      dedupe: ['vue', 'pinia', 'vue-i18n'],
+      dedupe: ['vue', 'pinia', 'vue-router', 'vue-i18n'],
       alias: {
         '@': fileURLToPath(new URL('./src', import.meta.url)),
         // Frontend-safe allowlist barrel — keeps zod-openapi (and its zod-instance