@v-office/website-sdk 2.11.0 → 2.13.0

package/dist/instructions/versions/2.12.0/MIGRATION.md

@@ -0,0 +1,194 @@
+# Migration: 2.11.0 to 2.12.0
+
+2.12.0 adds optional discount information to priced legacy v9 search results,
+normalizes empty quote booking-card lines across v9 and v10, and completes v10
+card-level pre-modifier totals across all modifier presentation paths. It also
+rejects unsupported v9 flexible-period searches before transport and restores
+empty-query inventory browsing on v9. Existing supported calls remain valid
+without changes.
+
+## 1. Reuse the Shared Discount Output
+
+Legacy v9 now uses the same optional shape introduced for v10 in 2.11.0:
+
+```ts
+type SearchDiscount = {
+  readonly formattedOriginalTotal: string;
+  readonly applied: readonly {
+    readonly label: string;
+    readonly formattedAmount: string;
+  }[];
+};
+```
+
+For exact-period results, read `discount` from the item:
+
+```ts
+result.items[0]?.discount;
+```
+
+For nearby suggestions, read it from the individual alternative period:
+
+```ts
+result.alternatives?.[0]?.alternativePeriods[0]?.discount;
+```
+
+## 2. Understand the Legacy v9 Mapping
+
+For priced v9 results:
+
+- `calc.total` remains the final `formattedTotal`.
+- `discount` is present only when `calc.oTotal` is greater than `calc.total`.
+- `discount.formattedOriginalTotal` is formatted from `calc.oTotal`.
+- A non-empty `calc.discountName` becomes the label of the single applied entry.
+- The applied amount is the formatted negative difference
+  `calc.total - calc.oTotal`.
+- If the backend supplies no usable discount name, `applied` is empty while the
+  formatted original total remains available.
+
+The SDK omits `discount` when there is no final total or when the original total is
+not greater than the final total.
+
+## 3. Account for Backend Detail Differences
+
+v9 exposes one aggregated discount name and therefore returns at most one
+`discount.applied` entry. v10 search can expose multiple `discount.applied`
+entries. Consumers should render the array without assuming a fixed length.
+
+Both backends return presentation-ready localized strings. Backend numeric amounts
+and internal modifier keys are not part of the public output.
+
+## 4. Account for Booking-Card Cleanup
+
+Quote booking cards on both backends now omit numeric zero-value lines without
+subitems from the `other` section, matching the existing handling of included and
+tax sections.
+
+- A zero-only `other` section is omitted.
+- A mixed `other` section retains its non-zero lines unchanged.
+- Lines with subitems remain available because they still carry descriptive
+  content.
+
+No required booking-card property was added and the public schema remains
+source-compatible. Runtime output can contain fewer empty rows. Sites that used a
+zero-value row to represent a declined service should use explicit selection or
+service state instead of inferring that state from the price breakdown.
+
+## 5. Render v10 Quote Modifiers
+
+On v10, an item at `bookingCardInformation.sections[].lines[].item` can include:
+
+```ts
+{
+  modifiers?: readonly {
+    label: string;
+    amount: string;
+  }[];
+  totalBeforeModifiers?: string;
+}
+```
+
+The card can also include `bookingCardInformation.totalBeforeModifiers`.
+`appliedCharge` and `total` are the final amounts after modifiers. The
+corresponding `totalBeforeModifiers` is the formatted amount before modifiers and
+is omitted when there is no non-zero net modifier effect. `modifiers` is omitted
+when the item has none; entries with the same localized label are grouped and
+their amounts are summed before formatting.
+
+Included, tax, and other lines attach their adjustments to `item.modifiers`.
+Negative modifiers from backend lines that do not map to those sections may
+instead appear as dedicated booking-card lines. In 2.12.0, card-level
+`totalBeforeModifiers` accounts for both forms. v9 quote cards omit these fields.
+
+Example for `de-DE`:
+
+```json
+{
+  "bookingCardInformation": {
+    "sections": [
+      {
+        "lines": [
+          {
+            "item": {
+              "position": "Inklusivpreis",
+              "appliedCharge": "1.554,00 €",
+              "modifiers": [
+                {
+                  "label": "Frühbucher/Last-Minute",
+                  "amount": "-140,00 €"
+                }
+              ],
+              "totalBeforeModifiers": "1.694,00 €"
+            }
+          }
+        ]
+      }
+    ],
+    "total": "1.596,70 €",
+    "totalBeforeModifiers": "1.736,70 €"
+  }
+}
+```
+
+Do not assume a voucher appears as its own section line. Use
+`quote.voucher.status` for voucher application status and the booking-card fields
+for price presentation. To keep price arithmetic visible, render the pre-modifier
+amount, modifier rows, and final amount separately. Whether to display or strike
+through a reference price remains the consuming site's product and legal
+decision.
+
+## 6. Keep Flexible Search Disabled on v9
+
+No configuration or supported request migration is required. Legacy v9 now rejects
+the unsupported flexible-period keys `month`, `dates`, `nights`, and `weekend`
+before transport instead of silently returning an unpriced item list. Keep
+flexible search unavailable on v9 sites and use fixed `start`/`end` period
+queries. v10 flexible search is unchanged.
+
+The rejection is a `CoreSDKError` with operation `v9.search` and occurs before a
+GraphQL request is sent. The public `SearchSearchInput` type remains unchanged
+because its `query` field is an opaque query string.
+
+This release enriches v9 search output when its existing response contains
+sufficient discount data, removes empty quote breakdown rows from both backends,
+and can return the existing optional card-level `totalBeforeModifiers` in
+additional v10 cases.
+
+## 7. Remove Dummy Occupancy from Empty v9 Searches
+
+Legacy v9 now sends an empty backend-filter set as GraphQL `data: null` instead of
+`data: []`. An empty query can therefore browse the first page of searchable
+inventory under the configured rental scope:
+
+```ts
+await sdk.live.search.search({
+  locale: "de-DE",
+  query: "",
+});
+```
+
+Remove workarounds that inject `adults=1` only to make an empty query return
+results. Real occupancy, period, and non-empty backend filters keep their existing
+mapping. Pagination and `limit` still apply, and an undated result does not assert
+availability for a particular stay.
+
+## Recommended Verification
+
+1. Run a priced v9 exact-period search where the original total exceeds the final
+   total and verify the formatted values and label.
+2. Verify discounted v9 alternative periods independently.
+3. Run a v9 search without a discount and confirm existing rendering is unchanged.
+4. Verify a missing v9 discount name produces an empty `applied` array.
+5. Verify v9 rejects `month`, `dates`, `nights`, and `weekend` before transport.
+6. Run an empty v9 query and confirm it returns searchable inventory without a
+   dummy occupancy value.
+7. Recheck a discounted v10 search and confirm its existing multi-entry behavior
+   remains unchanged.
+8. Quote a v9 and v10 rental with a zero-value `other` service and confirm the
+   empty section is absent.
+9. Confirm a mixed `other` section retains only its non-zero lines.
+10. Quote a discounted v10 rental and render `item.modifiers`, item-level
+    `totalBeforeModifiers`, and card-level `totalBeforeModifiers`.
+11. Confirm a v9 quote continues to omit the modifier fields.
+12. Verify a v10 modifier rendered as a dedicated line still contributes to the
+    card-level `totalBeforeModifiers`.

package/dist/instructions/versions/2.13.0/CHANGELOG.md

@@ -0,0 +1,87 @@
+# Changelog: 2.13.0
+
+This release adds static backend search capability discovery and replaces the
+ambiguous flat booking payment schedule with a shared, presentation-ready payment
+model for v9 and v10. It preserves every known remaining payment step, separates
+contractual steps from full-payment alternatives, and keeps backend credentials
+out of the public booking output.
+
+## Added
+
+- `@v-office/website-sdk/capabilities/search` exposes pure, instance-independent
+  helpers for checking flexible-period support and the supported period query keys
+  for a backend.
+- `BookingOutput.payment.schedule` contains the remaining contractual payment
+  steps known after booking.
+- `BookingOutput.payment.alternatives` contains optional ways to settle the
+  complete outstanding balance.
+- Schedule entries have a stable `kind`: `prepayment`, `remaining_payment`,
+  `installment`, or `deposit`.
+- Full-payment alternatives use `kind: "full_amount"`.
+- v10 booking output includes all remaining online, on-site, and external payment
+  steps instead of exposing only the next online step.
+- v10 schedule entries can include translated `paymentAt` text derived from the
+  backend payment location and recipient.
+- Legacy v9 now preserves its independently supplied remaining-payment amount and
+  deadline.
+
+## Changed
+
+- `dueOn` is now a complete translated, long-form display string such as
+  `Zahlbar bis zum 6. Februar 2027`.
+- Schedule and alternative amounts use the `amount` field and remain
+  locale-formatted display strings.
+- `paymentOptions` is present on a schedule entry only when the SDK can currently
+  perform that payment. Informational future, on-site, and external steps remain
+  visible without payment options.
+- A synthesized v9 full-payment alternative no longer copies the prepayment
+  deadline. An explicit backend total deadline can still be retained.
+- v10 initializes Adyen only for the next payable online step and the
+  full-outstanding alternative.
+- v9 initializes Stripe only for currently payable choices.
+- Post-booking insurance now receives the opaque booking result:
+
+  ```ts
+  await sdk.live.quote.bookInsurance({ quote, booking });
+  ```
+
+## Removed
+
+- `BookingOutput.paymentSchedules`
+- Public `BookingOutput.guestToken`
+- ISO-like or locale-short date assumptions for booking payment output
+
+The private v9 guest token remains attached to the live opaque booking object and
+is used internally when completing insurance. It is not enumerable or
+serializable.
+
+## Backend Mapping
+
+- v9 `prepayment` becomes `kind: "prepayment"`.
+- v9 `rest` becomes `kind: "remaining_payment"`.
+- v9 `total` becomes a `full_amount` alternative.
+- v10 `INSTALLMENT` becomes `kind: "installment"`.
+- v10 `DEPOSIT` becomes `kind: "deposit"`.
+- v10 `financials.outstanding` becomes a `full_amount` alternative when it is a
+  distinct payable choice.
+
+## Migration Impact
+
+This is a breaking output and insurance-input change. Consumers must:
+
+1. Replace reads of `paymentSchedules` with `payment.schedule` and
+   `payment.alternatives`.
+2. Read `amount` instead of the former schedule `total`.
+3. Treat schedule `paymentOptions` as optional.
+4. Render `dueOn`, `paymentAt`, labels, amounts, and line amounts directly without
+   reparsing or reformatting them.
+5. Pass the live `booking` object to `bookInsurance` instead of passing
+   `bookingNumber` and `guestToken`.
+6. Keep the booking object in memory until optional v9 insurance booking is
+   complete; private credentials do not survive JSON serialization.
+
+The search capability API is additive. Consumers with hardcoded backend period-key
+tables can replace them with the new helpers.
+
+See `versions/2.13.0/MIGRATION.md`, `../../search.md`, `../../booking.md`, and
+`../../quote.md`.

package/dist/instructions/versions/2.13.0/MIGRATION.md

@@ -0,0 +1,315 @@
+# Migration: 2.12.0 to 2.13.0
+
+2.13.0 introduces a breaking, shared booking-payment output for v9 and v10. The
+new model is intentionally presentation-oriented: labels, amounts, deadlines,
+payment locations, and breakdown lines are already translated and formatted for
+the booking locale.
+
+## 1. Replace the Flat Payment Schedule
+
+Before 2.13.0:
+
+```ts
+booking.paymentSchedules;
+```
+
+From 2.13.0:
+
+```ts
+booking.payment.schedule;
+booking.payment.alternatives;
+```
+
+`payment.schedule` contains contractual payment steps. `payment.alternatives`
+contains distinct alternatives such as paying the complete outstanding balance.
+
+Example:
+
+```json
+{
+  "bookingNumber": "B-2026-0001",
+  "payment": {
+    "schedule": [
+      {
+        "kind": "prepayment",
+        "label": "Anzahlung",
+        "amount": "76,00 €",
+        "dueOn": "Zahlbar bis zum 19. August 2026",
+        "paymentOptions": [
+          {
+            "kind": "bank_transfer",
+            "label": "Überweisung",
+            "holder": "Ferienvermietung Muster GmbH",
+            "iban": "DE02 1203 0000 0000 2020 51",
+            "remittanceText": "Buchungsnummer: B-2026-0001"
+          }
+        ]
+      },
+      {
+        "kind": "remaining_payment",
+        "label": "Restzahlung",
+        "amount": "304,00 €",
+        "dueOn": "Zahlbar bis zum 6. Februar 2027"
+      }
+    ],
+    "alternatives": [
+      {
+        "kind": "full_amount",
+        "label": "Gesamtzahlung",
+        "amount": "380,00 €",
+        "paymentOptions": [
+          {
+            "kind": "bank_transfer",
+            "label": "Überweisung",
+            "holder": "Ferienvermietung Muster GmbH",
+            "iban": "DE02 1203 0000 0000 2020 51",
+            "remittanceText": "Buchungsnummer: B-2026-0001"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+## 2. Read `amount` Instead of `total`
+
+The old schedule-level `total` field has been renamed to `amount`:
+
+```ts
+for (const entry of booking.payment.schedule) {
+  renderAmount(entry.amount);
+}
+```
+
+The value remains a localized display string. Do not parse it for arithmetic or
+payment initiation.
+
+Optional `lines` continue to contain translated labels and formatted amounts:
+
+```ts
+for (const line of entry.lines ?? []) {
+  renderBreakdownLine(line.label, line.amount);
+}
+```
+
+## 3. Render Schedule and Alternative Entries
+
+To render every payment entry:
+
+```ts
+const paymentEntries = [...booking.payment.schedule, ...booking.payment.alternatives];
+
+for (const entry of paymentEntries) {
+  renderPaymentEntry(entry);
+}
+```
+
+Use the stable `kind` only for programmatic behavior. Use `label` for visible
+text.
+
+Schedule kinds:
+
+- `prepayment`: a named v9 down payment.
+- `remaining_payment`: a named v9 remaining payment.
+- `installment`: a v10 installment step.
+- `deposit`: a v10 deposit step.
+
+Alternative kinds:
+
+- `full_amount`: settle the complete currently outstanding balance.
+
+Do not infer v9 semantics from v10 step order. A v10 installment is not
+automatically a prepayment or remaining payment.
+
+## 4. Treat `paymentOptions` as Capability Data
+
+`paymentOptions` is optional on scheduled steps. Its absence means the entry is
+informational and is not currently payable through the SDK.
+
+```ts
+for (const option of entry.paymentOptions ?? []) {
+  if (option.kind === "bank_transfer") {
+    renderBankTransfer(option);
+  } else {
+    renderSubmitButton(() => sdk.live.booking.submitPaymentOption(option));
+  }
+}
+```
+
+Do not attach payment buttons to future, on-site, or external entries merely
+because they appear in `payment.schedule`.
+
+`full_amount` alternatives always contain a `paymentOptions` array. The array can
+be empty when the backend supplies no executable method.
+
+## 5. Render Dates and Payment Locations Directly
+
+Before 2.13.0, `dueOn` was locale-short text even though older documentation
+showed an ISO value. Consumers sometimes attempted to parse it as
+`YYYY-MM-DD`.
+
+From 2.13.0, `dueOn` is a complete localized phrase:
+
+```text
+Zahlbar bis zum 6. Februar 2027
+Payable until February 6, 2027
+```
+
+Render it directly:
+
+```ts
+if (entry.dueOn) renderSupportingText(entry.dueOn);
+if (entry.paymentAt) renderSupportingText(entry.paymentAt);
+```
+
+Do not prepend another due-date label and do not parse or reformat these fields.
+`paymentAt` is currently populated by v10 when payment-step location information
+is available.
+
+## 6. Account for the Corrected v9 Schedule
+
+Legacy v9 now emits both authoritative contractual steps:
+
+- `prepayment` with its own amount and deadline.
+- `remaining_payment` with its own amount and deadline.
+
+The `full_amount` alternative is separate. When the SDK synthesizes it from
+prepayment plus remaining payment, it has no deadline. The SDK no longer copies
+the prepayment deadline onto that alternative.
+
+Consequently, code must not derive a remaining-payment deadline from
+`payment.alternatives`.
+
+## 7. Account for the Expanded v10 Schedule
+
+v10 now preserves all remaining backend payment steps in
+`payment.schedule`, including:
+
+- `ONLINE`
+- `ON_SITE`
+- `EXTERN`
+
+Only the next eligible online step receives an initialized Adyen option. Later
+steps remain available as informational entries. The complete outstanding amount
+can appear separately under `payment.alternatives`.
+
+The alternative amount is the current outstanding balance, not necessarily the
+original booking total.
+
+## 8. Migrate Post-Booking Insurance
+
+Before 2.13.0:
+
+```ts
+await sdk.live.quote.bookInsurance({
+  quote,
+  bookingNumber: booking.bookingNumber,
+  guestToken: booking.guestToken,
+});
+```
+
+From 2.13.0:
+
+```ts
+await sdk.live.quote.bookInsurance({
+  quote,
+  booking,
+});
+```
+
+`guestToken` is no longer public. For v9, it is stored as private state on the
+opaque booking object and consumed internally by the SDK.
+
+Keep the same live booking object until insurance booking is complete:
+
+```ts
+const booking = await sdk.live.booking.book(input);
+
+// Do not JSON round-trip `booking` before this call.
+const insurance = await sdk.live.quote.bookInsurance({ quote, booking });
+```
+
+Spreading, serializing, reconstructing, or transferring the booking object loses
+its private backend context. If the application must cross a page reload or
+process boundary, complete insurance before that boundary.
+
+## 9. Update Payment-Option Selection
+
+Before 2.13.0:
+
+```ts
+const option = booking.paymentSchedules[0]?.paymentOptions.find(
+  (candidate) => candidate.kind !== "bank_transfer",
+);
+```
+
+From 2.13.0:
+
+```ts
+const option = [...booking.payment.schedule, ...booking.payment.alternatives]
+  .flatMap((entry) => entry.paymentOptions ?? [])
+  .find((candidate) => candidate.kind !== "bank_transfer");
+```
+
+Continue passing the selected structured option unchanged to
+`submitPaymentOption`.
+
+## 10. Handle Optional Insurance Output
+
+`insurancePaymentOptions` is omitted when no post-booking insurance payment is
+available:
+
+```ts
+for (const option of booking.insurancePaymentOptions ?? []) {
+  renderInsurancePaymentOption(option);
+}
+```
+
+This keeps v10 and bookings without selected insurance minimal.
+
+## 11. Replace Hardcoded Search Capability Tables
+
+This migration is optional and additive. Search UI that needs to decide which
+period controls to render can query backend support without constructing an SDK:
+
+```ts
+import {
+  getSupportedPeriodQueryKeys,
+  supportsFlexiblePeriodSearch,
+  type BackendKind,
+} from "@v-office/website-sdk/capabilities/search";
+
+const shouldRenderFlexiblePeriod = (backend: BackendKind) => supportsFlexiblePeriodSearch(backend);
+
+const supportedPeriodKeys = getSupportedPeriodQueryKeys("v9");
+supportedPeriodKeys.has("month"); // false
+```
+
+Remove local v9/v10 period-key tables in favor of these helpers. Both helpers are
+derived from the same core definitions used by SDK search parsing, so backend
+support changes do not require consumers to update a copied matrix.
+
+The returned `ReadonlySet` includes supported aliases such as `from`, `till`,
+`nights_min`, and `nights_max`. It describes individual key support; normal
+search validation still determines whether a complete combination of keys and
+values is executable.
+
+## Recommended Verification
+
+1. Book a v9 reservation with distinct prepayment and remaining-payment dates.
+2. Confirm both entries retain their own translated long-form deadline.
+3. Confirm a synthesized v9 `full_amount` alternative has no deadline.
+4. Confirm future v9 remaining payment has no payment button unless the SDK
+   supplies a payment option.
+5. Book a v10 reservation with multiple online and on-site/external payment steps.
+6. Confirm every remaining v10 step is rendered in backend order.
+7. Confirm only the next payable online step has an Adyen option.
+8. Confirm the full-payment alternative displays the outstanding balance without
+   an inferred deadline.
+9. Render both supported locales and verify all amounts, dates, locations, labels,
+   and breakdown lines are presentation-ready.
+10. Complete v9 insurance with the live booking object and verify the private
+    credential is not present in serialized output.
+11. If replacing a local search capability table, confirm flexible-period controls
+    remain hidden for v9 and visible for v10.

package/dist/instructions/versions/2.5.0/MIGRATION.md

@@ -124,6 +124,9 @@ The public output type is unchanged, but v10 search cards now reflect the REST p
 Starting with 2.11.0, priced v10 items and alternative periods may also include
 optional localized `discount` details. See `../../search.md`.
 
+Starting with 2.12.0, legacy v9 maps the same optional shape from its aggregated
+original total and discount name when the original total exceeds the final total.
+
 ## Backend Behavior
 
 - Fixed-period and flexible searches are priced by the REST backend; occupancy is required for priced searches.

package/dist/{quote-Cs6jGoRS.mjs → quote-Qy_affum.mjs}

@@ -241,12 +241,12 @@ const toSections = ({ input, guestQuoteResult, locale, translations }) => Effect
 		locale,
 		translations
 	});
-	const sectionsOther = yield* toSectionsOther({
+	const sectionsOtherWithContent = (yield* toSectionsOther({
 		input,
 		guestQuoteResult,
 		locale,
 		translations
-	});
+	})).filter(hasSectionLineContent);
 	if (hasSectionLineContent(sectionsIncluded)) sections.push({
 		lines: [sectionsIncluded],
 		displayOrder: GuestQuoteBookingCardDisplayOrder.inclusive
@@ -255,8 +255,8 @@ const toSections = ({ input, guestQuoteResult, locale, translations }) => Effect
 		lines: [sectionsTax],
 		displayOrder: GuestQuoteBookingCardDisplayOrder.tax
 	});
-	if (sectionsOther.length > 0) sections.push({
-		lines: sectionsOther,
+	if (sectionsOtherWithContent.length > 0) sections.push({
+		lines: sectionsOtherWithContent,
 		displayOrder: GuestQuoteBookingCardDisplayOrder.other
 	});
 	return sections;

package/dist/{rentals-CFod9H4m.mjs → rentals-BG1diZoo.mjs}

@@ -1,4 +1,4 @@
-import { c as VofficeUnitDataFieldSchemas, d as VofficeUnitDataPropertyMetadata, f as parseVofficeFacilityData, i as toLocalizedString, l as VofficeUnitDataPropertyCategoryLabelKeys, m as parseVofficeUnitData, n as toImages, o as rentalsAllFeedbacksQuery, p as parseVofficeFeedbackData, r as toAddress, s as rentalsAllWithoutFeedbacksQuery, t as toRentalHighlights, u as VofficeUnitDataPropertyCategoryValues } from "./to-rental-highlights-B6a_fi0j.mjs";
+import { c as VofficeUnitDataFieldSchemas, d as VofficeUnitDataPropertyMetadata, f as parseVofficeFacilityData, i as toLocalizedString, l as VofficeUnitDataPropertyCategoryLabelKeys, m as parseVofficeUnitData, n as toImages, o as rentalsAllFeedbacksQuery, p as parseVofficeFeedbackData, r as toAddress, s as rentalsAllWithoutFeedbacksQuery, t as toRentalHighlights, u as VofficeUnitDataPropertyCategoryValues } from "./to-rental-highlights-BVikT4Iz.mjs";
 import { makeTranslate, renderLabeledAttributeValue, renderResolvedCustomAttribute, toCustomAttributeList, toResolvedCustomAttributeCategoryTranslationKey } from "@v-office/sdk-core";
 import { Effect } from "effect";
 //#region src/legacy-v9/parser/rentals/to-description.ts
@@ -91,9 +91,10 @@ const toRentalAttributes = ({ locale, translations, attributes, customAttributes
 	for (const { key, metadata } of PROPERTY_METADATA_ENTRIES) {
 		const value = knownAttributes[key];
 		if (!canRenderLabeledAttributeValue$1(value)) continue;
+		const label = yield* translate(metadata.labelKey, key);
 		const attribute = renderLabeledAttributeValue({
 			key,
-			label: yield* translate(metadata.labelKey, key),
+			label,
 			locale,
 			value
 		});
@@ -154,9 +155,10 @@ const toRentalVicinity = ({ locale, translations, attributes }) => Effect.gen(fu
 	for (const { key, metadata } of LOCATION_METADATA_ENTRIES) {
 		const value = knownAttributes[key];
 		if (!canRenderLabeledAttributeValue(value)) continue;
+		const label = yield* translate(metadata.labelKey, key);
 		const item = renderLabeledAttributeValue({
 			key,
-			label: yield* translate(metadata.labelKey, key),
+			label,
 			locale,
 			value
 		});
@@ -200,7 +202,8 @@ const toReviews = ({ locale, translations, rental }) => Effect.gen(function* ()
 		}];
 	}) ?? [];
 	if (parsedItems.length === 0) return void 0;
-	const summaryRating = roundRatingUp(parsedItems.reduce((ratingSum, item) => ratingSum + item.rating, 0) / parsedItems.length);
+	const averageRating = parsedItems.reduce((ratingSum, item) => ratingSum + item.rating, 0) / parsedItems.length;
+	const summaryRating = roundRatingUp(averageRating);
 	const summaryRatingTemplate = yield* translations.translate(locale, "reviews.summary.rating");
 	const summaryCountTemplate = yield* translations.translate(locale, "reviews.summary.count");
 	const classification = toClassification(summaryRating);