includio-cms 0.36.9 → 0.37.1

package/API.md

@@ -1,8 +1,8 @@
-# includio-cms — Public API v0.36.9
+# includio-cms — Public API v0.37.1
 
 > Auto-generated by `scripts/generate-api-md.ts`. Do not edit by hand.
 
-Entry points: **19** · Stable: **502** · Experimental: **4**
+Entry points: **23** · Stable: **665** · Experimental: **4**
 
 Tags:
 - `@public` — frozen for v1.0; semver-protected.
@@ -148,6 +148,8 @@ Tags:
 - `const AdminLayout: LegacyComponentType`
 - `interface AdminNavItem` — One additional sidebar entry rendered below built-in nav sections
 - `const Badge: LegacyComponentType`
+- `const BookingReservationDetailPage: LegacyComponentType`
+- `const BookingReservationsPage: LegacyComponentType`
 - `interface Breadcrumb`
 - `class Breadcrumbs`
 - `buildCsv(opts: { headers: string[]; rows: (string | number | null ...): string` — Build a CSV string from `headers` and `rows`. Values are escaped per
@@ -177,6 +179,7 @@ Tags:
 - `const MaintenancePage: LegacyComponentType`
 - `const MediaPage: LegacyComponentType`
 - `const MediaSelector: LegacyComponentType`
+- `const ModuleDashboardPage: LegacyComponentType`
 - `const PageHeader: LegacyComponentType`
 - `interface PaginationState`
 - `const ResetPasswordPage: LegacyComponentType`
@@ -205,11 +208,16 @@ Tags:
 
 ### `includio-cms/admin/remote`
 
+- `const addAdjustment: <inferred>`
+- `const addPaymentLink: <inferred>`
 - `const archiveEntryCommand: <inferred>`
 - `const bulkDeleteMediaFiles: <inferred>`
 - `const bulkSetMediaFileTags: <inferred>`
+- `const cancelBooking: <inferred>`
 - `const cancelShipmentForOrderCmd: <inferred>`
+- `const changeBookingStatus: <inferred>`
 - `const countMediaFiles: <inferred>`
+- `const createBookingStaff: <inferred>`
 - `const createCouponCmd: <inferred>`
 - `const createEntry: <inferred>`
 - `const createMediaTag: <inferred>`
@@ -225,6 +233,7 @@ Tags:
 - `const deleteShippingMethodCmd: <inferred>`
 - `const deleteShopDataForEntry: <inferred>`
 - `const duplicateEntryCommand: <inferred>`
+- `const editBookingStaff: <inferred>`
 - `const exportFormSubmissions: <inferred>`
 - `const exportOrdersCsv: <inferred>`
 - `const findMediaReferences: <inferred>`
@@ -232,6 +241,9 @@ Tags:
 - `const generateBalanceLinkForOrder: <inferred>`
 - `const getAdminExtraNavItems: <inferred>`
 - `const getAltOverview: <inferred>`
+- `const getBooking: <inferred>`
+- `const getBookingEnabled: <inferred>`
+- `const getBookingStats: <inferred>`
 - `const getCollection: <inferred>`
 - `const getCollections: <inferred>`
 - `const getCouponAdmin: <inferred>`
@@ -251,6 +263,7 @@ Tags:
 - `const getMediaFiles: <inferred>`
 - `const getMediaTags: <inferred>`
 - `const getMediaTagsWithCounts: <inferred>`
+- `const getModules: <inferred>`
 - `const getOrderForAdmin: <inferred>`
 - `const getOrderInvoiceAdmin: <inferred>`
 - `const getOrderRefundsAdmin: <inferred>`
@@ -267,12 +280,16 @@ Tags:
 - `const getSubmissionsOverview: <inferred>`
 - `const isAIAvailable: <inferred>`
 - `const issueInvoiceCmd: <inferred>`
+- `const listBookingCatalog: <inferred>`
+- `const listBookings: <inferred>`
 - `const listCouponsAdmin: <inferred>`
 - `const listOrdersAdmin: <inferred>`
 - `const listShippingMethodsAdmin: <inferred>`
 - `const listShopableCollections: <inferred>`
 - `const listShopProductEntries: <inferred>`
 - `const populatePreviewData: <inferred>`
+- `const recordCashPayment: <inferred>`
+- `const refundBookingPayment: <inferred>`
 - `const refundOrderCmd: <inferred>`
 - `const regenerateVideoPoster: <inferred>`
 - `const renameMediaFile: <inferred>`
@@ -282,6 +299,7 @@ Tags:
 - `const restoreOrderCmd: <inferred>`
 - `const searchEntries: <inferred>`
 - `const searchLinkableEntries: <inferred>`
+- `const sendBookingEmailCmd: <inferred>`
 - `const setFocalPoint: <inferred>`
 - `const setMediaFileAlt: <inferred>`
 - `const setMediaFileTags: <inferred>`
@@ -293,8 +311,10 @@ Tags:
 - `const updateMediaAccessibility: <inferred>`
 - `const updateMediaTag: <inferred>`
 - `const updateOrderStatusCmd: <inferred>`
+- `const updateParticipantData: <inferred>`
 - `const updateShippingMethodCmd: <inferred>`
 - `const upsertShopDataForEntry: <inferred>`
+- `const voidAdjustment: <inferred>`
 
 ### `includio-cms/sveltekit`
 
@@ -351,6 +371,14 @@ Tags:
 
 - `const account: <inferred>`
 - `const accountRelations: <inferred>`
+- `const bookingAdjustmentsTable: <inferred>`
+- `const bookingItemPersonsTable: <inferred>`
+- `const bookingItemsTable: <inferred>`
+- `const bookingPaymentsTable: <inferred>`
+- `const bookingPersonsTable: <inferred>`
+- `const bookingRemindersTable: <inferred>`
+- `const bookingsTable: <inferred>`
+- `interface BookingTotals` — Computed money snapshot kept on the booking for fast list/detail reads.
 - `const consentLogsTable: <inferred>`
 - `type DatabaseAdapterWithDrizzle = DatabaseAdapter & { _drizzle: ReturnType<typeof drizzle<typeof schema>>; }`
 - `const entriesTable: <inferred>`
@@ -433,6 +461,17 @@ Tags:
 - `const shopStockReservationsTable: <inferred>`
 - `const shopWebhookEventsTable: <inferred>`
 
+### `includio-cms/db-postgres/schema-booking`
+
+- `const bookingAdjustmentsTable: <inferred>`
+- `const bookingItemPersonsTable: <inferred>`
+- `const bookingItemsTable: <inferred>`
+- `const bookingPaymentsTable: <inferred>`
+- `const bookingPersonsTable: <inferred>`
+- `const bookingRemindersTable: <inferred>`
+- `const bookingsTable: <inferred>`
+- `interface BookingTotals` — Computed money snapshot kept on the booking for fast list/detail reads.
+
 ### `includio-cms/auth-schema`
 
 - `const account: <inferred>`
@@ -451,7 +490,7 @@ Tags:
 - `interface ConsentConfig`
 - `interface CouponRef`
 - `type Currency = 'PLN'`
-- `defineShop(config: ShopConfig): ResolvedShopConfig`
+- `defineShop(config: ShopConfig): CMSModule` — Defines the shop module. Returns a {@link CMSModule} for
 - `type DepositAmount = { type: 'percent'; value: number } | { type: 'amount'; value: number }` — Deposit amount specifier. `percent` charges `floor(base * value / 100)` of
 - `interface EmailContext` — Context passed to a {@link SubjectPlaceholderResolver}. Currently carries
 - `fakturowniaAdapter(opts: FakturowniaAdapterOptions): InvoicingAdapter` — Invoicing adapter backed by Fakturownia (fakturownia.pl). Issues a paid VAT
@@ -552,6 +591,142 @@ Tags:
 - `createShipmentLabelHandler(): { GET: RequestHandler }` — Admin-only PDF proxy that streams the carrier label without exposing the
 - `createShippingMethodsHandler(): { GET: RequestHandler }`
 
+### `includio-cms/booking`
+
+- `type AdjustmentKind = 'manual_surcharge' | 'manual_discount'` — Manual booking adjustments — staff-entered surcharges (e.g. e-bike +200) and
+- `interface AdjustmentSums`
+- `ageAt(dob: string, anchor: Date): number | null` — Pełne lata między `dob` a `anchor`. `null` gdy data niepoprawna.
+- `interface AgeBand` — A global age band: participants aged [minAge, maxAge] pay `pct`% of adult price.
+- `interface AgeFlagConfig` — Generyczna flaga wieku: oznacza uczestnika, którego wiek (liczony z pola roli
+- `interface AppliedRule`
+- `assertAdjustmentMagnitude(magnitude: number): void` — Reject a zero/negative magnitude at the write boundary.
+- `assertGrossNotBelowPaid(newGross: number, payments: PaymentEntry[]): void` — Asserts an edit's new gross does not drop below the already-paid total.
+- `assertTransition(from: BookingStatus, to: BookingStatus): void` — Asserts a legal transition, throwing {@link BookingStateError} otherwise.
+- `balance(gross: number, payments: PaymentEntry[]): number` — Outstanding balance: `gross − paid` (never below 0).
+- `bandPctFor(age: number | null, bands: AgeBand[]): number` — Resolve the age-band percent for an age; 100 when null/unmatched (full price).
+- `const BOOKING_STATUSES: readonly BookingStatus[]`
+- `interface BookingAdjustment`
+- `interface BookingConfig` — User-facing booking configuration. Passed to `defineBooking` and registered
+- `class BookingStateError` — Thrown when an illegal status transition is attempted.
+- `type BookingStatus = | 'draft' | 'reserved' | 'partially_paid' | 'paid' | 'completed' | 'cancelled'` — Booking state machine — pure, deterministic. Two concerns:
+- `interface BookingValidationContext` — Context handed to the client-supplied {@link BookingValidator} seam.
+- `type BookingValidator = (ctx: BookingValidationContext) => void | Promise<void>` — Client-specific validation seam (e.g. weekly-model term conflicts). Throws to
+- `buildPricingInputs(persons: PersonRow[], items: ItemRow[], assignments: ItemPersonRow[], identityFields: FieldDef[]): PricingInputs`
+- `canFill(field: FieldDef, audience: 'customer' | 'staff'): boolean` — Whether a given audience may fill/edit a field. Default `whoFills` is `'both'`.
+- `canReduceGrossTo(newGross: number, payments: PaymentEntry[]): boolean` — Whether the gross may be reduced to `newGross` without going below paid.
+- `canTransition(from: BookingStatus, to: BookingStatus): boolean` — Whether `from → to` is a legal transition (self-transitions are allowed).
+- `completeness(data: Record<string, unknown>, fields: FieldDef[]): Completeness`
+- `interface Completeness`
+- `type Condition = | { kind: 'minTripCount'; value: number } // distinct trip refs >= value | { kind: 'minParticipan...` — Booking discount rules engine — a pure, deterministic, module-agnostic
+- `daysUntil(departureDate: Date, now: Date): number` — Whole days from `now` until `departureDate` (negative if departure is past).
+- `defineBooking(config: BookingConfig): CMSModule` — Defines the booking module — a long-lived, mutable reservation system with a
+- `deriveAgeFlag(data: Record<string, unknown>, fields: FieldDef[], config: AgeFlagConfig | null, anchorDate: Date | null): { flagged: boolean; age: number | null }` — Generyczna flaga wieku — bez magicznego klucza. Bierze pole z rolą `birthDate`,
+- `deriveStatus(input: DeriveStatusInput): BookingStatus` — Derives the payment-progress status from the ledger.
+- `interface DiscountRule` — A serializable discount rule.
+- `interface EarlyBird` — Early-bird: `percent`% off a full-price participant's gross when booked early.
+- `type Effect = | { kind: 'percentOff'; value: number } // % off gross (0–100) | { kind: 'amountOff'; value: numb...` — An effect applied when a rule wins its group.
+- `const FIELD_TYPES: <inferred>`
+- `interface FieldDef` — Serializowalna definicja pojedynczego pola uczestnika.
+- `interface FieldError`
+- `interface FieldGroup`
+- `type FieldRole = 'name' | 'birthDate'` — Generyczna „rola" pola — opcjonalna wskazówka semantyczna, którą UI/logika
+- `type FieldType = (typeof FIELD_TYPES)[number]`
+- `groupBySection(fields: FieldDef[]): FieldGroup[]`
+- `isFieldType(v: unknown): v is FieldType`
+- `isFullyPaid(gross: number, payments: PaymentEntry[]): boolean` — Whether the booking is fully settled (`gross > 0` and balance reached 0).
+- `interface ItemPersonRow` — Assignment (junction) row.
+- `interface ItemRow` — Trip-line row (subset needed for pricing). `unitPrice` = adult price (minor units).
+- `interface LadderTier` — One ladder tier: from `minTrips` trips, the cheapest trip gets `percent`% off.
+- `ladderTierFor(tripCount: number, ladder: LadderTier[]): LadderTier | null` — Highest ladder tier whose `minTrips` ≤ tripCount; null when none qualifies.
+- `class LedgerError` — Thrown when an edit would push the gross below what has already been paid.
+- `ledgerSummary(gross: number, payments: PaymentEntry[]): LedgerSummary` — Full ledger snapshot for a given gross.
+- `interface LedgerSummary`
+- `const NO_ADJUSTMENTS: AdjustmentSums`
+- `interface ParticipantBreakdown`
+- `interface ParticipantLine`
+- `interface ParticipantPriceResult`
+- `interface ParticipantPricingConfig` — Serializable per-participant pricing config (sourced from client globalSettings).
+- `interface PaymentEntry`
+- `type PaymentKind = 'deposit' | 'installment' | 'cash' | 'online'` — Booking payment ledger — pure helpers over a list of payment entries. The
+- `type PaymentStatus = 'pending' | 'paid' | 'failed' | 'refunded'`
+- `interface Perk`
+- `interface PersonRow` — Person row (subset needed for pricing).
+- `price(lines: PricingLine[], now: Date, config: PricingConfig): PriceResult`
+- `priceByParticipant(participants: PricingParticipant[], trips: PricedTrip[], anchor: Date | null, now: Date, config: ParticipantPricingCo...): ParticipantPriceResult`
+- `interface PricedTrip` — A trip available in the booking, with its full (adult) price (minor units).
+- `interface PriceResult`
+- `interface PricingConfig`
+- `interface PricingInputs`
+- `interface PricingLine` — A single priced line that retains trip identity (for cheapest/distinct-count).
+- `interface PricingParticipant` — A participant and the trips they take.
+- `interface ReminderRule` — One scheduled reminder rule, relative to the earliest departure date.
+- `interface ResolvedBookingConfig` — Fully-defaulted booking config, carried on `CMSModule.config`.
+- `signedAmount(kind: AdjustmentKind, magnitude: number): number` — Convert a UI-entered positive magnitude + kind into a signed stored amount.
+- `sumAdjustments(rows: Pick<BookingAdjustment, 'amount' | 'voidedAt'>[]): AdjustmentSums` — Fold active (non-voided) adjustments into totals contributions. By sign.
+- `totalPaid(payments: PaymentEntry[]): number` — Sum of entries currently in `paid` state.
+- `totalPending(payments: PaymentEntry[]): number` — Sum of entries still pending (links generated, not yet settled).
+- `totalRefunded(payments: PaymentEntry[]): number` — Sum of entries that were refunded.
+- `validateAgainstSchema(data: Record<string, unknown>, fields: FieldDef[]): FieldError[]`
+- `type WhoFills = 'customer' | 'staff' | 'both'` — Kto wypełnia pole. Default 'both'.
+
+### `includio-cms/booking/client`
+
+- `class BookingClientError` — Error thrown on a non-2xx response; `code` carries the server's error code.
+- `interface BookingClientOptions` — Browser SDK for the booking storefront + self-service portal. Thin fetch
+- `createBookingClient(opts: BookingClientOptions = {}): <inferred>` — Create a booking API client bound to a base URL + fetch.
+- `useBooking(token: string, opts: BookingClientOptions = {}): <inferred>` — Reactive self-service portal state for a booking access token. Loads the view
+
+### `includio-cms/booking/server`
+
+- `interface AddAdjustmentInput`
+- `addBookingAdjustment(bookingId: string, input: AddAdjustmentInput, opts: { actor: string; now?: Date }): Promise<BookingAdjustment>` — Add a manual adjustment (surcharge/discount) and recompute the booking totals
+- `applyWebhookPayment(event: PaymentEvent): Promise<{ applied: boolean; bookingId: string | null; kind: PaymentKind | nul...` — Apply a provider webhook event to the ledger, idempotently. Locks the payment
+- `interface BookingEditChanges` — Edit payload: replace people + items (+assignments) and/or customer details.
+- `type BookingEmailKind = | 'booking-received' | 'deposit-paid' | 'payment-received' | 'payment-link' | 'balance-due' | 'ba...` — The transactional emails the booking module can send.
+- `interface BookingStatus`
+- `bookingStatusByToken(token: string): Promise<BookingStatus | null>`
+- `interface BookingStatusItem`
+- `type BookingTx = Parameters<Parameters<ReturnType<typeof getBookingDb>['transaction']>[0]>[0]` — Exact drizzle transaction handle, derived from the booking db's `transaction`.
+- `class BookingValidationError` — Thrown when a booking fails capacity (core) or the client `validateBooking` seam.
+- `createBooking(input: CreateBookingInput, opts: { now?: Date; actor?: PriceActor } = {}): Promise<{ booking: typeof bookingsTable.$inferSelect; accessToken: string }>` — Create a booking (public self-serve or staff). Validates catalog capacity +
+- `createBookingHandler(): { POST: RequestHandler }` — Public self-serve booking creation. Mount at `POST /api/booking`.
+- `createDepositPayment(bookingId: string): Promise<{ redirectUrl: string | null; status: 'redirect' | 'manual' | 'error'...` — Create the deposit payment for a freshly-created booking: ask the first
+- `createInstallmentPayment(bookingId: string, amount: number): Promise<{ paymentLink: string | null }>` — Generate an installment/balance payment link for an arbitrary amount (staff or
+- `createMaintenanceHandler(): { POST: RequestHandler }` — Secured external trigger for booking maintenance — the swap-in for the
+- `createPortalHandler(): { GET: RequestHandler; POST: RequestHandler }` — Self-service portal. Mount at `GET|POST /api/booking/portal/[token]`.
+- `createWebhookHandler(): { POST: RequestHandler }` — Payment-provider webhook. Mount at `POST /api/booking/webhook/[provider]`.
+- `editBooking(bookingId: string, changes: BookingEditChanges, opts: { actor: 'staff' | 'portal'; now?: Date }): Promise<typeof bookingsTable.$inferSelect>` — Edit a booking (staff or portal). Recomputes totals per-participant + derived
+- `getBookingDb(): <inferred>` — Returns the Drizzle handle, asserting the postgres adapter is in use.
+- `getBookingMaintenanceStatus(): { running: boolean; lastRun: Date | null }`
+- `listBookingAdjustments(bookingId: string): Promise<BookingAdjustment[]>` — List all adjustments (active + voided) for a booking, newest first.
+- `pickEmailTemplate(kind: BookingEmailKind): string` — Template file name for a kind (1:1 — kept as a function for future indirection).
+- `portalAddTrips(token: string, additions: Array<{ tripRef: string; assignments: string[] }>): <inferred>` — Self-service dobieranie wycieczki: doczytaj obecny stan, scal z `additions`
+- `portalEdit(token: string, changes: BookingEditChanges): <inferred>` — Portal self-service edit (actor:'portal' guards). Throws → handler maps to 409/400.
+- `portalPay(token: string, amount: number): <inferred>` — Portal: create an installment/balance payment link.
+- `portalUpdateParticipant(token: string, assignmentId: string, data: Record<string, unknown>): <inferred>` — Portal self-service: customer fills their own participant data. Verifies the
+- `portalView(token: string): <inferred>` — Portal view: booking + items + participants + ledger (no staff data).
+- `priceFromExistingRows(tx: BookingTx, bookingId: string, config: ResolvedBookingConfig): Promise<ParticipantPriceResult>` — Price a booking from its CURRENTLY persisted people/items/assignments (no
+- `processDueExpirations(now: Date = new Date()): Promise<{ abandoned: number; forfeited: number }>` — Auto-cancel expired bookings: abandoned drafts (deposit hold lapsed) and
+- `processDueReminders(now: Date = new Date()): Promise<number>` — Send all due reminders (unsent, `scheduledFor <= now`) via the email adapter,
+- `readTripCapacity(tripRef: string): Promise<number | null>` — Read a trip's seat capacity from the catalog collection.
+- `recordCash(bookingId: string, amount: number): Promise<void>` — Record a manual cash payment (staff). Settles immediately and recomputes status.
+- `refundPayment(paymentId: string, amount?: number): Promise<void>` — Refund a paid ledger entry via the adapter (staff-only manual action), then
+- `renderBookingEmail(kind: BookingEmailKind, lang: string, context: Record<string, unknown>): Promise<string>` — Render a booking email's HTML body for the given language + context.
+- `requireBookingConfig(): ResolvedBookingConfig` — Returns the resolved booking config, throwing when the module is not registered.
+- `rescheduleReminders(tx: BookingTx, bookingId: string, dates: Array<Date | null>): Promise<void>` — Recompute the reminder schedule for a booking after a departure-date change:
+- `resolveByToken(token: string): Promise<BookingRow | null>` — Resolve a booking by its unguessable portal access token (active only).
+- `runBookingMaintenance(now: Date = new Date()): Promise<void>` — Run one maintenance pass (reminders + expirations), guarded against overlap.
+- `runCapacityCheck(items: Array<{ tripRef: string; participantsCount: number }>, excludeBookingId?: string): Promise<void>` — Generic seat-capacity check (core). Sums requested participants per trip and
+- `runValidateBooking(ctx: BookingValidationContext): Promise<void>` — Invoke the client-supplied validation seam, wrapping failures uniformly.
+- `sendBookingEmail(bookingId: string, kind: BookingEmailKind, extra: Record<string, unknown> = {}): Promise<void>` — Send a transactional booking email to the booker. No-op when no email adapter
+- `serverInit(): void` — Conventional server-init entry run by `initCMS` via `serverHooks.initModule`
+- `startBookingMaintenance(): void` — Start the in-process loop (config-gated). Idempotent. Called from serverHooks.init.
+- `stopBookingMaintenance(): void`
+- `subjectFor(kind: BookingEmailKind, lang: string): string` — Localised subject for a kind, falling back to English.
+- `toPortalView(booking: BookingRow, items: ItemRow[], participants: FlatParticipant[], payments: Array<PaymentEntry & { paidAt?: Dat...): <inferred>` — Pure: shape a portal-safe DTO. Explicitly whitelists fields — `staffNotes`,
+- `verifyPhone(token: string, phone: string): Promise<BookingRow | null>` — Drugi czynnik: zwraca booking gdy podany numer pasuje do `customer.phone`.
+- `voidBookingAdjustment(adjustmentId: string, opts: { actor: string; now?: Date }): Promise<void>` — Soft-void an adjustment (kept for audit) and recompute the booking totals +
+
 ### `includio-cms/files-local`
 
 - `const fullDir: <inferred>`

package/CHANGELOG.md

@@ -3,6 +3,83 @@
 All notable changes to includio-cms are documented here.
 Generated from `src/lib/updates/` — do not edit manually.
 
+## 0.37.1 — 2026-07-14
+
+Dwie łatki cenowe w bookingu. (1) Cena rezerwacji przestaje pochodzić z żądania HTTP — do 0.37.0 publiczne endpointy przyjmowały `unitPrice` prosto z ciała żądania i nikt nie konfrontował go z katalogiem, więc wyprawę dało się zarezerwować za grosz. (2) Data wyceny zostaje zamrożona na rezerwacji — dotąd każde jej dotknięcie (edycja, ale też zaksięgowanie korekty) przeliczało reguły zależne od czasu wg DZISIEJSZEJ daty, przez co early-bird sprzed miesięcy cicho znikał i klient robił się winien pieniądze.
+
+### Added
+- `defineBooking({ resolvePrice })` — serwerowy szew zwracający cenę bazową (dorosłego) pozycji katalogu w groszach. Rdzeń nie zna kształtu katalogu, więc cenę podaje projekt: `resolvePrice: async (tripRef) => Math.round(Number((await resolveEntry({ id: tripRef, status: "published" }))?.price ?? 0) * 100)`.
+- Model zaufania oparty na aktorze: `createBooking(input, { actor })` przyjmuje `public | portal | staff`. Domyślny aktor to `public` (niezaufany) — pominięcie parametru nie otwiera dziury. Zalogowana obsługa (`staff`) nadal może podać cenę ręcznie: korekta i rabat negocjowany telefonicznie zostają możliwe.
+- Typ `PricedCreateInput` wymusza kolejność: rezerwacji nie da się zbudować z pozycji, której nie wyceniła bramka — pilnuje tego kompilator, nie dyscyplina.
+
+### Fixed
+- **Bezpieczeństwo (data wyceny).** Nowa kolumna `bookings.priced_at` zamraża moment wyceny. `editBooking` i `priceFromExistingRows` (ścieżka korekt — `adjustments.ts:65` i `:155`) liczą teraz early-bird na tę datę, nie na `new Date()`. Wcześniej wystarczyło, że obsługa zaksięguje dopłatę ustaloną telefonicznie tydzień przed wylotem, a rabat za wczesną rezerwację przepadał. `priceFromExistingRows` straciło parametr `now` — kompilator nie pozwoli już podać tam zegara.
+- Rezerwacje sprzed 0.37.1 mają `priced_at = NULL` i wyceniają się z `created_at` — dokładnie tym, czym było wtedy `now`. Zero migracji danych, zero zmiany zachowania.
+- **Bezpieczeństwo (ceny).** Trzy publiczne drogi wpuszczały cenę z zewnątrz: tworzenie rezerwacji (`createBookingHandler`), dokładanie wycieczki przez portal (`add-trips`) i portalowa edycja pozycji (`portalEdit` → `editBooking`). Bramka stoi teraz w rdzeniu (`createBooking`/`editBooking`), nie w handlerach, więc każdy przyszły publiczny endpoint jest chroniony domyślnie.
+- Cena pozycji już zapisanej w rezerwacji jest brana z jej `unitPriceSnapshot`, a nie przeliczana z katalogu — dotknięcie rezerwacji przez portal nie podniesie klientowi ceny, gdy cennik w międzyczasie poszedł w górę.
+- Odczyt katalogu w `editBooking` odbywa się przed otwarciem transakcji: szew klienta robi własne I/O, a wołany pod blokadą `FOR UPDATE` trzymałby wiersz rezerwacji i sięgał po drugie połączenie z tej samej puli.
+- Ceny ujemne i niecałkowite (ułamek grosza) są odrzucane — również dla obsługi.
+
+### Breaking
+- Nowa kolumna `bookings.priced_at` — wymagana migracja (`drizzle-kit push`). Nullable, bez backfillu.
+- **`defineBooking({ resolvePrice })` jest teraz wymagany, gdy booking wystawia publiczne endpointy** (`createBookingHandler`, portal). Bez niego rdzeń odmawia wyceny (fail-closed) zamiast po cichu zaufać cenie z żądania. Instalacje używające wyłącznie panelu admina działają bez zmian.
+- `BookingItemInput.unitPrice` jest opcjonalne i **honorowane wyłącznie dla `actor: "staff"`**. Dla klienta końcowego jest ignorowane — cenę ustala katalog.
+- Publiczne API klienta: `createBookingClient().addTrips(token, additions)` oraz `useBooking().addTrips(additions)` nie przyjmują już `unitPrice` w pozycjach (`{ tripRef, assignments }`). Storefronty przekazujące cenę muszą ją usunąć z ładunku — była i tak ignorowana po stronie serwera.
+
+## 0.37.0 — 2026-06-17
+
+Moduły-nakładki + context switcher: shop i booking jako równorzędne, opcjonalne moduły rozszerzające rdzeń CMS (model „WooCommerce na WordPressie"). Zunifikowany rejestr `config.modules`, przełącznik kontekstu w adminie (Treści / Sklep / Rezerwacje) dla czytelniejszego UI, per-moduł dashboard. Shop przepięty na nowy kontrakt `CMSModule` (dowód generyczności #1), booking dodany jako drugi moduł biblioteki z pełnym rdzeniem domenowym (wycena/state machine/księga płatności) — dowód #2. Booking write-flow + portal self-service domknięte: tworzenie (public+staff), zadatek + webhook idempotentny, pełna edycja self-service (recompute/pojemność/„nie poniżej wpłaconego”), maile + przypomnienia, cron bez-infra (in-process loop + secured endpoint), strefa obsługi w adminie, scaffold `--booking`. Plan: `docs/superpowers/plans/2026-06-18-booking-write-flow-portal.md`, spec: `docs/superpowers/specs/2026-06-18-booking-write-flow-portal-design.md`.
+
+### Added
+- `CMSModule` (`includio-cms` — `$lib/types/modules.ts`, `@public`) — kontrakt modułu-nakładki w 3 warstwach: serializowalny deskryptor (id/label/icon-string/context z nav sections + surfaced collections), server-only `serverHooks` (init), oraz client-side dashboard rejestrowany po `id`. Nav = dane (ikony jako nazwy z icon-map), nie komponenty.
+- `config.modules: CMSModule[]` — zunifikowany rejestr modułów w `defineConfig`. CMS dostaje `getModule(id)` / `getModuleConfig<T>(id)` / `hasModule(id)` + `modules` Map. `initCMS` odpala `serverHooks.init` każdego modułu (idempotentnie, fire-and-forget).
+- `moduleSchema` w `cms.schema.ts` — walidacja Zod modułów (unikalny `id`, wymagane icon/sections, `surfacedCollections`/`surfacedSingles` muszą referować zadeklarowane kolekcje/single).
+- Context switcher (`context-switcher.svelte` w `site-header`) — przełącznik widoku admina: Treści (rdzeń CMS) / Sklep / Rezerwacje. Renderuje się tylko gdy ≥1 moduł; zero zmian wizualnych dla projektów bez modułów. Aktywny kontekst rozstrzygany przez `resolveActiveContext` (`?ctx` query > PersistedState sticky > ścieżka), ścieżki modułowe i content-core mają pierwszeństwo (poprawny deep-linking).
+- Generyczny sidebar wg kontekstu (`nav-module.svelte`) — kontekst modułu pokazuje jego sekcje + „wciągnięte" kolekcje/single rdzenia (prop `filterSlugs` + `?ctx` w linkach na `nav-collections`/`nav-singletons`). Opcjonalne reaktywne badge przez `countSource`.
+- Per-kontekst dashboard (`ModuleDashboardPage` + `dashboard-registry` po `id`, `@public` przez `includio-cms/admin/client`) — landing `/admin/shop` i `/admin/booking`. `shop-dashboard` (liczba zamówień + skróty), `booking-dashboard` (aktywne rezerwacje / zaległe salda / do potwierdzenia).
+- `defineShop()` zwraca teraz `CMSModule` (id `shop`, ikona `building-store`, sekcje Produkty/Zamówienia/Wysyłka/Kupony). Pełna warstwa server/http/remote shopa nietknięta (363 testy zielone).
+- `defineBooking(config): CMSModule` (`includio-cms/booking`, `@public`) — moduł rezerwacji. Config: `currency`, `catalogCollection` (surfaced), `depositAmount`, `pricing` (rabaty), `payment`, `adminEmail`.
+- Booking rdzeń domenowy (pure, w pełni testowalny): `price()` — silnik wyceny (rabat ilościowy + early-bird, kompozycja largest-wins/sumowanie); `deriveStatus()` + `assertTransition()` — state machine `draft→reserved→partially_paid→paid→completed/cancelled` (status liczony z salda); `ledger` — saldo = gross − Σpaid, guard „nie poniżej wpłaconego". 37 testów.
+- 5 tabel Drizzle bookingu (`bookings`/`booking_items`/`booking_participants`/`booking_payments`/`booking_reminders`) + eksport `includio-cms/db-postgres/schema-booking`. Kwoty w groszach, soft-delete, jsonb totals/customer/participants.
+- `includio-cms/booking` + `includio-cms/db-postgres/schema-booking` — nowe entry points w `package.json` exports.
+- Admin: lista Rezerwacje (`/admin/booking/reservations`) + remote `listBookings`/`getBookingEnabled`.
+- Booking write-flow: `createBooking()` (public self-serve + staff, walidacja pojemności + seam `validateBooking`, snapshot ceny, harmonogram przypomnień), `createDepositPayment()` (link zadatku przez wstrzyknięty adapter), public handler `POST /api/booking`. Status zawsze liczony z księgi (`deriveStatus`).
+- Webhook płatności (`POST /api/booking/webhook/[provider]`) — `applyWebhookPayment()` idempotentny przez row-lock (`SELECT … FOR UPDATE` po `providerRef`), przeliczenie salda + statusu, czyszczenie holdu zadatku, mail `deposit-paid`/`payment-received`. Czysta logika `applyPaymentEvent` testowana jednostkowo.
+- Edycja rezerwacji (`editBooking()`, wspólna dla obsługi i portalu): recompute ceny, guardy wg actora, `portal` blokuje zejście poniżej wpłaconego (`LedgerError` → HTTP 409 „skontaktuj się z obsługą”), reschedule przypomnień przy zmianie wylotu. Refundy = ręczna akcja obsługi przez adapter (`refundPayment`, przeliczenie salda).
+- Portal self-service (`GET|POST /api/booking/portal/[token]`, `?action=edit|pay`) + SDK `createBookingClient` i reaktywny `useBooking` (`includio-cms/booking/client`). `toPortalView` whitelistuje pola (brak `staffNotes`). Strony storefront/portalu buduje repo klienta na SDK.
+- Maile bookingu: lokalny Handlebars registry (override projektem → package default → fallback lang) + 6 szablonów PL/EN (`booking-received`/`deposit-paid`/`payment-received`/`payment-link`/`balance-due`/`balance-overdue-cancelled`).
+- Cron bez-infra: czyste `processDueReminders`/`processDueExpirations` (draft-expiry + balance-due forfeiture z przepadkiem zadatku) napędzane in-process loopem (`serverHooks.init`, interwał z configu, domyślnie 15 min) ORAZ secured endpointem `POST /api/booking/maintenance` (Bearer token) jako trigger wymienny.
+- Strefa obsługi w adminie: detal rezerwacji `/admin/booking/reservations/[id]` (księga, pozycje, uczestnicy, akcje) + remote mutacje (`createBookingStaff`/`editBookingStaff`/`addPaymentLink`/`recordCashPayment`/`refundBookingPayment`/`changeBookingStatus`/`cancelBooking`/`sendBookingEmailCmd`).
+- `includio-cms/booking/client` (SDK + `useBooking`) i `includio-cms/booking/server` (serwisy + HTTP handlery, node-only — kod serwerowy poza bundlem klienta) — nowe entry points.
+- `defineBooking` config rozszerzony: `depositTtlMinutes` (TTL porzuconego draftu, def. 60), `balanceDueDaysBefore` (termin dopłaty), `capacityField` (pojemność z wpisu katalogu), `reminders[]`, `validateBooking(ctx)` (seam client-specific), `maintenance` (autoRun/intervalMinutes), `maintenanceToken`. Kolumny `bookings`: `balanceDueAt`/`holdExpiresAt`/`cancelReason`.
+- Scaffold: `includio scaffold admin` emituje też trasy bookingu (api/booking/*, strony admina, portal `rezerwacja/[token]`) gdy wykryje `defineBooking(` — flagi `--booking`/`--no-booking`. Generyczny helper rate-limit podniesiony do core (`$lib/server/security/rate-limit-handler`, współdzielony shop+booking).
+- Redesign kontekstów (admin context workspaces): context switcher przeniesiony do nagłówka sidebara obok loga (inline pill, w trybie zwiniętym sama ikona kontekstu), nawigacja scoped per kontekst — każdy kontekst pokazuje wyłącznie swoje sekcje + własny „Pulpit" (Treści→`/admin`, moduł→`landingUrl` z ikoną modułu). Globalne narzędzia (Biblioteka mediów + admin: Użytkownicy/Konserwacja) przyklejone do dołu sidebara w każdym kontekście. Trasy neutralne (`/admin/media|users|maintenance|account`) zachowują aktywny kontekst zamiast wracać do Treści. Tożsamość kontekstu przez ikonę, Plum jednolity (`data-context` na korzeniu sidebara jako forward-compat hook pod ewentualne akcenty). Spec: `docs/superpowers/specs/2026-06-18-admin-context-workspaces-design.md`.
+- Silnik reguł rabatowych bookingu (`price()` przepisany, `includio-cms/booking`): rabaty jako serializowalne reguły `when`→`then` z grupami wykluczającymi (w grupie wygrywa największy rabat, między grupami sumują się). Zastępuje `quantityDiscounts`/`earlyBird`/`combine`. Nowe efekty: `percentOffCheapestLine` (100 = najtańsza pozycja gratis) + `grantPerk` (prezent — notka dla obsługi). `PriceResult.perks` + per-linia `appliedDiscounts` (targetRef). Typy: `DiscountRule`/`Condition`/`Effect`/`Perk`/`PricingLine`. Silnik czysty, bez sprzężenia z domeną (gotowy pod współdzielenie z shop).
+- Generyczny seam wyceny per linia: `PricingLine.subtotal?` — gdy podany, jest grossem linii (zamiast `unitPrice×quantity`), używany też przez „najtańsza pozycja gratis" (cheapest wg subtotalu). Snapshot na `booking_items.subtotalSnapshot` (nullable) zapewnia wierny recompute przy edycji. Wstecznie kompatybilne (brak subtotalu = zachowanie bez zmian). Pozwala klientowi naliczać dowolną nie-płaską cenę linii (np. cena wg wieku uczestników, stawki grupowe) bez logiki klienta w rdzeniu — wartości/obliczenia po stronie projektu. Spec: `docs/superpowers/specs/2026-06-18-booking-participants-fields-child-pricing-design.md`.
+- Booking + PayU (i każdy adapter shopu) bez modułu shop: `PaymentCreateContext` zyskuje `continueUrl` (pełny absolutny URL powrotu) + `buyer` ({firstName,lastName,phone}). Adapter PayU `createPayment` preferuje ctx i pomija `requireShopConfig`/`getOrderById` gdy `continueUrl` podane (ścieżka shop bez zmian, wstecznie zgodna). `defineBooking` zyskuje `portalUrlTemplate` (placeholder `{token}` → `accessToken`); `createDepositPayment`/`createInstallmentPayment` budują ctx przez czysty `buildPaymentContext` i przekazują do adaptera. Pozwala wpiąć realny PayU w booking bez shopu. Spec: `docs/superpowers/specs/2026-06-19-booking-payu.md` (repo klienta).
+- Treść maili transakcyjnych bookingu dopracowana (PL/EN, wszystkie 6 rodzajów) we wspólnym layoucie — nowe partials `_partials/{header,footer}` (rejestrowane przed każdym renderem, kolizyjnie-bezpieczne wobec identycznych nazw w module shop), styling AriaCMS + przycisk do panelu rezerwacji (`portalUrl` z `accessToken`+`portalUrlTemplate`). `balance-due` podaje termin dopłaty z datą i przybliżoną liczbą dni oraz ostrzega o przepadku zadatku; nowe helpery Handlebars `date`/`daysUntil`. Link do płatności wysyłany mailem do bookera po akcji obsługi `addPaymentLink`. Nowe pole `defineBooking({ brand })` — nazwa firmy w stopce maila (override per-projekt nadal przez `src/emails/booking/`). Spec/plan: `docs/superpowers/specs/2026-06-19-booking-email-content-design.md`.
+- Widoki podglądu (`previews[]` w kolekcji/singlu, `@public`) — jedno entry może mieć kilka celów podglądu (pełny wpis, zajawka/karta w liście). Przełącznik „Widok" w pasku podglądu (ukryty przy jednym widoku), a `preview: '<nazwa>'` na tabie przełącza widok automatycznie przy wejściu na ten tab; tab bez powiązania nie rusza podglądu, a ręcznie wybrany widok jest zapamiętywany per tab. Podgląd ładuje `{url}?preview={id}&view={name}` — projekt może mieć route per widok albo jeden route rozgałęziający się na `view`. Stary `previewUrl` działa bez zmian (normalizowany do jednego widoku). `defineConfig` waliduje spójność: unikalne nazwy, max jeden `default`, `previewUrl`/`previews` wykluczają się, każde `tab.preview` musi wskazywać istniejący widok (literówka wywala build). Spec: `docs/superpowers/specs/2026-07-13-preview-views-design.md`.
+- Admin bookingu — lista rezerwacji na wspólnym `DataTable`: wyszukiwanie po numerze oraz po danych klienta, filtr statusu, paginacja serwerowa (`listBookings({status, search, limit, offset})` → `{items, total}`; było: `SELECT *` bez limitu, czyli cała baza rezerwacji do przeglądarki). Statystyki pulpitu liczy nowy `getBookingStats()` — agregat SQL, bo sumowanie stronicowanej listy pokazywałoby po cichu liczby z pierwszej strony.
+- Admin bookingu — czytelne statusy (`StatusBadge variant="booking"`): „Czeka na zaliczkę", „Zarezerwowane", „Częściowo opłacone", … zamiast surowych wartości technicznych (`draft`, `partially_paid`) na liście i w detalu.
+- Admin bookingu — pozycje rezerwacji pokazują NAZWĘ wycieczki, nie jej uuid. `getBooking` rozwiązuje wpis katalogu zawsze, gdy katalog jest skonfigurowany (wcześniej tylko gdy `participantFields` było funkcją) i wystawia `tripTitle`; picker pozycji i detal używają jednego helpera `catalogTitle`, więc nazywają wycieczkę tak samo.
+- `defineBooking({ customerFields })` (`@experimental`) — etykiety worka `customer` w panelu admina (`FieldDef[]`: `key`, `label`, opcjonalna `role`). Rdzeń nie zna nazw pól projektu, więc bez tego panel pokazuje uczłowieczone klucze („Referral source"). Klucze zagnieżdżone adresuje się kropką (`people.birthDate`). Wyłącznie prezentacja — nie waliduje i nie zmienia danych.
+- Admin bookingu — data urodzenia uczestnika pokazuje skończone lata w nawiasie („1990-05-05 (36 l.)"). Rozpoznanie po ROLI pola (`role: 'birthDate'`), nie po nazwie — z samej wartości nie odróżnisz daty urodzenia od daty przylotu.
+- `defineBooking({ surfacedCollections })` (`@experimental`) — dodatkowe kolekcje wciągane do kontekstu „Rezerwacje" w adminie obok katalogu (np. kolekcja definiująca typy wypraw i pola uczestnika). Bez tego mieszkają w kontekście „Treści" i wyglądają jak doszyta kolekcja CMS-a, choć obsługują rezerwacje.
+- Admin bookingu — nowa sekcja „Klient" w detalu rezerwacji. Wcześniej dane osoby rezerwującej (imię, e-mail, telefon, okno pobytu, odpowiedzi z formularza) były zapisywane, ale **nigdzie nie pokazywane** — obsługa nie mogła oddzwonić do klienta z panelu. Renderer jest generyczny: rozpoznaje typ po WARTOŚCI (e-mail → `mailto:`, telefon → `tel:`, data ISO → format lokalny), nie po nazwie pola, więc działa dla dowolnego kształtu `customer` bez zmian w rdzeniu; tablice obiektów (np. manifest uczestników) renderują się tabelką. `getBooking` wystawia `arrivalDateField` z konfiguracji.
+
+### Fixed
+- Pole `relation` — dwa wpisy o tej samej nazwie przestają się zlewać w jeden. `Command.Item` dostawał `value={label}`, a `value` jest w bits-ui tożsamością pozycji (filtrowanie, nawigacja klawiaturą, podświetlenie), więc identyczne nazwy dawały `aria-selected=true` na obu wierszach naraz. Teraz tożsamość to `id` wpisu, a wyszukiwanie po nazwie zapewnia `keywords` (domyślny scorer skleja `value` + `keywords`). Zaznaczenie (`isSelected`) zawsze szło po `id` — psuło się wyłącznie podświetlenie.
+- Ścieżka wpisu (`_url`, lista kolekcji) zawsze bezwzględna, z dokładnie jednym wiodącym slashem. `applyPathTemplate` zwracało szablon 1:1, więc `pathTemplate: 'blog/{slug}'` dawało `_url: 'blog/x'` — URL **względny** (z podstrony prowadził w złe miejsce), mimo że docs obiecują `/blog/x`. Projekty pisały więc `pathTemplate: '/blog/{slug}'`, a wtedy lista kolekcji w adminie pokazywała `//blog/x`, bo `entry-link` doklejał własny slash. Teraz szablon i slug są składane bez podwojenia (`//` → `/`), obie formy szablonu działają, a URL-e bezwzględne (`https://…`) zostają nietknięte. `EntryLink` przyjmuje `path` (gotowa ścieżka) zamiast `slug`.
+
+### Breaking
+- `config.shop` USUNIĘTY. Shop rejestruje się teraz przez `config.modules`: `defineConfig({ modules: [defineShop({...})] })` zamiast `defineConfig({ shop: defineShop({...}) })`. `defineShop()` zwraca `CMSModule` (nie `ResolvedShopConfig`). Wewnętrznie `getCMS().shopConfig` działa nadal (shim → `getModuleConfig('shop')`), więc warstwa server/http/remote shopa pozostaje kompatybilna.
+- Tabela `bookings` ma nowe kolumny (`balance_due_at`, `hold_expires_at`, `cancel_reason`) oraz `booking_items` kolumnę `subtotal_snapshot` (nullable) wymagane przez write-flow. Po aktualizacji uruchom `pnpm db:push` (lub migrację) w projekcie używającym bookingu.
+- `PricingConfig` bookingu przepisany na `{ rules: DiscountRule[] }` — `quantityDiscounts`/`earlyBird`/`combine` USUNIĘTE. `price(lines, now, config)` ma nową sygnaturę (linie z `ref`/`departureDate` zamiast płaskich `{unitPrice,quantity}` + osobnej daty). `BookingTotals` zyskuje `perks`/`appliedRules` (jsonb `totals` — bez migracji DB). Zaktualizuj `defineBooking({ pricing: { rules: [...] } })`.
+
+### Notes
+
+Pre-1.0: zmiana dozwolona bez okresu deprecacji (jednoosobowy konsument). Migracja: (1) w `cms.config.ts` zamień `shop: defineShop({...})` na `modules: [defineShop({...})]`; (2) jeśli używasz bookingu — `pnpm db:push` (nowe kolumny) i przescaffolduj trasy (`includio scaffold admin` wykryje `defineBooking(`). Provider płatności (Stripe/PayU) konfigurowalny przez `defineBooking({ payment: [...] })` — core adapter-agnostyczny.
+
 ## 0.36.9 — 2026-07-02
 
 Duplikacja wpisu z tabeli kolekcji + serwerowa normalizacja pól slug przy zapisie. Menu wiersza zyskuje „Duplikuj" — tworzy nieopublikowany szkic z tą samą treścią (wszystkie języki), z prefiksem tytułu „Kopia — " i unikalnym slugiem („-kopia"), i przenosi do edytora duplikatu. Media i relacje są współdzielone przez referencje (bez głębokiego klonu). Niezależnie od duplikacji: każde pole typu slug (SlugField oraz slug w polu SEO) jest przy zapisie normalizowane przez slugify — „Singapur"/„Hello World" zapisują się jako „singapur"/„hello-world", transparentnie dla użytkownika. Spec: `docs/superpowers/specs/2026-07-02-duplicate-entry-and-slug-normalization-design.md`, plan: `docs/superpowers/plans/2026-07-02-duplicate-entry-and-slug-normalization.md`.

package/DOCS.md

@@ -1,4 +1,4 @@
-# Includio CMS Documentation (v0.36.9)
+# Includio CMS Documentation (v0.37.1)
 
 > This file is auto-generated from the docs site. For the latest version, update the package.
 
@@ -587,7 +587,8 @@ const posts = defineCollection({
 | `labels` | `{ singular?: Localized; plural?: Localized }` | No | Display labels in admin |
 | `entryAdminTitle` | `string` | No | Field slug used as entry title in admin list |
 | `sidebarIcon` | `IconName` | No | Icon for the admin sidebar |
-| `previewUrl` | `string` | No | URL pattern for previewing entries |
+| `previewUrl` | `string` | No | URL pattern for previewing entries (shorthand for one view) |
+| `previews` | `PreviewView[]` | No | Named [preview views](#preview-views) — mutually exclusive with `previewUrl` |
 | `orderable` | `boolean` | No | Enable manual drag-and-drop ordering |
 | `listColumns` | `string[]` | No | Field slugs to display as columns in admin list |
 | `layout` | `Layout` | No | Admin editor [layout](/docs/getting-started/layout) |
@@ -596,6 +597,29 @@ const posts = defineCollection({
 
 > **entryAdminTitle:** Set `entryAdminTitle` to a text field slug (like `'title'`) so entries show meaningful names in the admin list instead of IDs.
 
+## Preview views
+
+One entry is often rendered in more than one way on the front end — a full page, and a teaser card in a listing. Declare each way as a view:
+
+```typescript
+previews: [
+  { name: 'full', label: { pl: 'Pełny wpis' }, url: '/preview/blog-post' },
+  { name: 'teaser', label: { pl: 'Zajawka' }, url: '/preview/blog-post/teaser' }
+]
+```
+
+The admin loads `{url}?preview={entryId}&view={name}`, so you may expose one route per view, or a single route that branches on the `view` query param. A **Widok / View** switcher appears in the preview toolbar; with a single view it stays hidden. `previewUrl: '/preview/blog-post'` is the shorthand for exactly one view, and keeps working as before.
+
+Bind a view to a tab and the preview follows the editor:
+
+```typescript
+{ type: 'tab', label: { pl: 'Zajawka' }, preview: 'teaser', fields: ['thumbnail', 'featured'] }
+```
+
+A tab **without** `preview` leaves the current view alone, and a view the editor picks by hand is remembered for that tab. Views do not change what is fetched — the entry always arrives whole; they only change how it is rendered in the preview.
+
+> **Typos fail the build:** `defineConfig` checks that view names are unique, that at most one is `default`, that `previewUrl` and `previews` are not both set, and that every `tab.preview` points at a declared view.
+
 ## Usage in Config
 
 ```typescript
@@ -674,7 +698,8 @@ const homepage = defineSingle({
 | `fields` | `Field[]` | Yes | Array of field definitions |
 | `label` | `Localized` | No | Display label in admin |
 | `sidebarIcon` | `IconName` | No | Icon for admin sidebar |
-| `previewUrl` | `string` | No | URL for previewing |
+| `previewUrl` | `string` | No | URL for previewing (shorthand for one view) |
+| `previews` | `PreviewView[]` | No | Named [preview views](/docs/collections#preview-views) — mutually exclusive with `previewUrl` |
 | `layout` | `Layout` | No | Admin editor [layout](/docs/getting-started/layout) |
 | `slugField` | `string` | No | Dot-path to slug field (default: `'seo.slug'`) |
 | `pathTemplate` | `string` | No | URL path template, e.g. `'about'` |

package/ROADMAP.md

@@ -19,6 +19,9 @@
 - [x] `[chore]` `[P1]` Faza 10 — Documentation Pass (0.23.0): DOCS.md uzupełnione (number/boolean/date edge cases, REST cURL + error codes, Entries error handling + transactions, Admin UI a11y, Adapter Contracts), nowe sekcje (Stability Promise, Security Model), Migration Guide v0.x → v1.0 master cheatsheet (0.16-0.22), ROADMAP cleanup (pre-v1.0 → ROADMAP-ARCHIVE.md) <!-- files: src/routes/docs/{stability-promise,security}/+page.svx, src/routes/docs/migration/+page.svx, src/routes/docs/_config/nav.ts, scripts/compile-docs.ts, ROADMAP-ARCHIVE.md, src/lib/updates/0.23.0/ -->
 - [x] `[chore]` `[P1]` Faza 11 — Performance Pass (0.24.0): N+1 elimination (`getImageStyle` batch IN query, `getRawEntries` batch entry versions), Sharp srcset `Promise.allSettled` (one timeout doesn't kill batch), background maintenance in-process lock verified + tested, bench infra (`pnpm bench` + representative benchmarks), lazy adapter imports verified <!-- files: src/lib/core/server/media/styles/operations/, src/lib/core/server/fields/resolveImageFields.ts, src/lib/core/server/entries/operations/get.ts, src/lib/db-postgres/index.ts, src/lib/core/server/media/operations/backgroundMaintenance.spec.ts, src/lib/updates/0.24.0/ -->
 - [x] `[feature]` `[P0]` Faza 11.5 — Shop polish (0.25.0): Stripe adapter (Checkout Session, sig verify, idempotency), refund infra (full + partial cross-adapter), webhook idempotency table (`shop_webhook_events`), coupons (% / fixed, expiresAt, maxUses, minOrder), low-stock email alert, order export CSV, default email templates (PL/EN), SDK JSDoc + `@public`, pełna dokumentacja shopa <!-- files: src/lib/shop/adapters/stripe/, src/lib/shop/server/{refund,coupons}.ts, src/lib/db-postgres/schema/shop/{refunds,webhookEvents,coupons,couponRedemptions}.ts, src/lib/admin/client/shop/, src/lib/updates/0.25.0/ -->
+- [x] `[feature]` `[breaking]` `[P1]` Moduły-nakładki + context switcher (0.37.0) — zunifikowany `config.modules` (`CMSModule`: deskryptor + serverHooks + client dashboard), przełącznik kontekstu admina (Treści/Sklep/Rezerwacje), per-moduł dashboard; shop przepięty na kontrakt modułu (`config.shop` usunięty, shim `shopConfig`); booking jako 2. moduł biblioteki — rdzeń domenowy (wycena/state-machine/księga, 37 testów) + 5 tabel Drizzle + lista Rezerwacje. Booking write-flow + portal self-service domknięte: create (public+staff), zadatek + webhook idempotentny (row-lock), pełna edycja self-service (recompute/pojemność/„nie poniżej wpłaconego” → 409), maile + przypomnienia, cron bez-infra (in-process loop + secured endpoint), strefa obsługi, SDK `./booking/client` + node-only `./booking/server`, scaffold `--booking`. <!-- files: src/lib/types/modules.ts, src/lib/core/cms.ts, src/lib/admin/state/active-context*, src/lib/admin/components/layout/{context-switcher,nav-module}.svelte, src/lib/booking/, src/lib/db-postgres/schema/booking/, src/lib/admin/remote/booking.remote.ts, src/lib/admin/client/booking/, src/lib/cli/scaffold/booking.ts, docs/superpowers/specs/2026-06-18-booking-write-flow-portal-design.md, docs/superpowers/plans/2026-06-18-booking-write-flow-portal.md -->
+- [x] `[feature]` `[breaking]` `[P1]` Silnik reguł rabatowych bookingu (0.37.0) — `price()` przepisany na data-driven reguły `when`→`then` z grupami wykluczającymi; zastępuje qty/early-bird; `percentOffCheapestLine` + `grantPerk` (prezent); drabinka bundle pod-zwrotnikami jako dane w configu klienta. Spec: `docs/superpowers/specs/2026-06-18-booking-discount-rules-engine-design.md`, plan: `docs/superpowers/plans/2026-06-18-booking-discount-rules-engine.md`. <!-- files: src/lib/booking/pricing.ts, src/lib/booking/{draft,recompute}.ts, src/lib/booking/server/bookings.ts, src/lib/db-postgres/schema/booking/bookings.ts, src/lib/booking/templates/booking-received.*.html, src/lib/admin/client/booking/reservation-detail-page.svelte -->
+- [x] `[feature]` `[P1]` Widoki podglądu (0.37.0) — `previews[]` w kolekcji/singlu (nazwa + label + url, `previewUrl` = skrót na jeden widok), przełącznik „Widok" w pasku podglądu, `tab.preview` przełącza widok przy wejściu na tab (ręczny wybór zapamiętywany per tab), URL podglądu `{url}?preview={id}&view={name}`, walidacja spójności w `defineConfig`. Spec: `docs/superpowers/specs/2026-07-13-preview-views-design.md`, plan: `docs/superpowers/plans/2026-07-13-preview-views.md`. <!-- files: src/lib/types/{config,layout,cms.schema}.ts, src/lib/core/config/validatePreviews.ts, src/lib/admin/client/entry/{preview-views.ts,preview-views-context.svelte.ts,entry.svelte,hybrid/hybrid-preview.svelte}, src/lib/admin/components/layout/{layout-tabs,layout-renderer}.svelte -->
 - [ ] `[fix]` `[P1]` Select field — `defaultValue` propagacja do zod schema (full repro: `ideas/post-v1/select-field-defaultvalue-bug.md`); fix planowany w Fazie 12 (RC)
 - [x] `[chore]` `[P2]` Demo orchestrator — `pnpm demo` startuje czystą instancję na tmpfs DB :5436, seeduje 12 blog postów / 6 projektów / 5 contact submissions / 8 gradient PNG-ów, włącza `demo-site` frontend pod `/demo-site`, każdy start = czysty stan <!-- files: scripts/demo.ts, scripts/seed-demo.ts, src/routes/demo-site/, docker-compose.yml, .env.demo -->
 - [x] `[feature]` `[P1]` Shop platformowy 0.27.0 — schema-driven variants + booking deposit (envet pilot). Plan: 7 faz. <!-- files: docs/superpowers/specs/2026-05-28-shop-platformowy-design.md, /Users/patryk/.claude/plans/implementacja-ariacms-0-27-partitioned-kahn.md -->
@@ -32,6 +35,33 @@
 - [x] `[feature]` `[P1]` Slug first-class + SEO v1.0 freeze (0.26.0) — `resolveSeo` public (`includio-cms/core`), `seoFieldDescriptor` SSOT (Zod+TS drift-guard), admin URL un-hardcode (`slugPath.ts` pure resolver, no `seo`-field requirement), `SlugField`/`SeoField`/`SeoFieldData` `@public` v1.0-frozen <!-- files: src/lib/core/fields/slugPath.ts, src/lib/core/fields/seoFieldDescriptor.ts, src/lib/core/fields/resolveSeo.ts, src/lib/types/fields.ts, src/lib/admin/client/collection/collection-entries.svelte, src/lib/updates/0.26.0/ -->
 - [x] `[feature]` `[P2]` Soft-delete zamówień admin-only (0.34.0) — ukrycie zamówienia z listy bez utraty danych (`deleted_at`/`deleted_by`), kosz + przywracanie, guard `decideOrderDeletion` (safe-statuses + faktura), auto-restore przy płatności, zwolnienie rezerwacji stocku, `requireRole('admin')` <!-- files: src/lib/shop/server/orders.ts, src/lib/db-postgres/schema/shop/order.ts, src/lib/admin/remote/shop.remote.ts, src/lib/admin/client/shop/{shop-order-detail-page,shop-orders-list-page,restore-order-cell}.svelte, src/lib/updates/0.34.0/ -->
 
+## 0.37.1 — Bramka cenowa (bezpieczeństwo)
+
+- [x] `[fix]` `[breaking]` `[P0]` **Data wyceny zamrożona na rezerwacji** (`bookings.priced_at`). Dotąd cena bazowa była zamrożona, ale data — nie: `editBooking` i `priceFromExistingRows` (ścieżka **korekt**) przeliczały reguły zależne od czasu wg `new Date()`. Obsługa księgowała dopłatę ustaloną telefonicznie tydzień przed wylotem → `daysUntil(anchor, now)` spadało poniżej progu → **early-bird sprzed miesięcy cicho znikał, a klient robił się winien pieniądze**. Bomba tykała sama, bez żadnej zmiany cennika. Rezerwacje sprzed 0.37.1: `priced_at = NULL` → fallback na `created_at` (zero migracji danych). Pełny snapshot **wartości** polityki (`pricing_snapshot`) zostaje w 0.38.0 §4.4 — wymaga świadomej zmiany cennika przez klientkę, więc da się ją uprzedzić.
+- [x] `[fix]` `[breaking]` `[P0]` **Cena rezerwacji przestaje pochodzić z żądania HTTP.** Do 0.37.0 trzy publiczne drogi wpuszczały `unitPrice` z ciała żądania i nikt nie konfrontował go z katalogiem (`create-handler.ts:37`, portalowe `add-trips`, portalowe `edit` → `editBooking`) — wyprawę dało się zarezerwować za grosz. Bramka stoi teraz w rdzeniu (`createBooking`/`editBooking`), oparta na aktorze: `public`/`portal` nie dyktują ceny (nowa pozycja → szew `resolvePrice` z katalogu, istniejąca → jej `unitPriceSnapshot`), `staff` nadal może korygować ręcznie. Domyślny aktor to `public`, więc przyszły publiczny endpoint jest bezpieczny bez pamiętania o niczym. Fail-closed: brak `resolvePrice` = odmowa wyceny.
+
+## 0.38.0 — Moduły: kontrakt vs polityka
+
+> **WSTRZYMANE (2026-07-14).** Łuk jest dojrzały, ale klientka nie zobaczy z niego nic, a produktyzacja
+> (`module_settings`, `AdminRouter`, kupony) zwraca się dopiero przy **drugim kliencie z bookingiem**.
+> Wracamy, gdy taki się pojawi — wtedy abstrakcje wyjdą z dwóch realnych przypadków, nie z jednego.
+> Wyjątek już zrobiony: kawałek 3a (jądro reguł) leży zrebase'owany na `feat/pricing-rules-kernel`.
+> Poprawka do wprowadzenia przy powrocie: pozycja o typach wypraw twierdzi, że „moduł ma wnosić je sam" —
+> **to jest błędne**. `tripType` to pojęcie domenowe klienta (klient nr 3 może wynajmować kajaki).
+> Moduł może wnieść MECHANIZM (rejestr typów pól + generator pola `blocks` + adapter + headless front),
+> nie POJĘCIE.
+
+Spec: `docs/superpowers/specs/2026-07-13-moduly-kontrakt-vs-polityka-design.md`. Kolejność i uzasadnienia tam.
+
+- [x] `[feature]` `[P0]` Kawałek 3a — jądro reguł w rdzeniu (`core/rules`) + cennik jako kategorie uczestnika; golden testy parytetu ze starym silnikiem. Branch `feat/pricing-rules-kernel`.
+- [ ] `[feature]` `[P0]` Kawałek 1 — fundament: `module_settings` (polityka w bazie) + system migracji (`aria migrate` + guard) + `AdminRouter` (routes admina jako dane, koniec z plikami w repo klienta) + `PaymentAdapter` wyprowadzony z shopu do rdzenia.
+- [ ] `[feature]` `[P0]` Kawałek 2 — polityka bookingu: strona „Ustawienia rezerwacji", builder reguł (generowany z rejestru, pole `blocks`), symulator ceny, **snapshot polityki na rezerwacji** (dziś dotknięcie starej rezerwacji przelicza early-bird wg dzisiejszej daty i potrafi podnieść cenę klientowi), kasacja `pricing.ts`.
+- [ ] `[feature]` `[P0]` **Typy wypraw / kategorie uczestnika wracają do modułu.** Dziś kolekcja `tripType` (bloki-dane) + adapter `mapTripTypeFields` (dane→`FieldDef`) mieszkają w repo KLIENTA — każdy kolejny klient przepisuje ~100 linii, a kolekcja wyświetla się w kontekście „Treści", bo moduł nie umie wnieść własnej. Wzorzec jest poprawny (Payload form-builder: stała kolekcja + pola jako bloki; zero DDL, odpowiedzi w `booking_persons.data`) — zły jest tylko adres. Moduł ma wnosić to pojęcie sam (dane w ustawieniach modułu), mapować na `FieldDef` w rdzeniu i pokazywać w kontekście „Rezerwacje". Efekt: klient N nie pisze ani linijki. Obejście na 0.37.0: `defineBooking({ surfacedCollections })` (`@experimental`).
+- [ ] `[feature]` `[P1]` **`customer` dostaje prawdziwy schemat**, nie tylko etykiety. Dziś `defineBooking({ customerFields })` (`@experimental`) opisuje worek `customer` WYŁĄCZNIE do prezentacji, a walidacja tego samego worka żyje w repo klienta (`assertManifest`, `validateSurveyAnswers`) — dwie deklaracje jednej rzeczy, gotowy dryf. Docelowo jedna deklaracja napędza walidację, render w adminie i formularz publiczny (jak `participantFields`).
+- [ ] `[feature]` `[P0]` Kawałek 4 — kody rabatowe: wspólna tabela `coupons` + `coupon_redemptions` w rdzeniu; **port kuponu shopu na jądro reguł** (twardy warunek: jądro z jednym konsumentem to generalizacja bez dowodu).
+- [ ] `[feature]` `[P1]` Kawałek 5 — braki domenowe: `weekdays[]` → dodatki (extras) → overrides per data `{date, capacity?, price?, status?}`.
+- [ ] `[chore]` `[P1]` Konsolidacja pól: `booking/FieldDef` → koperta nad core `Field`. Usuwa import `VariantAttribute` z shopu w `core/server/generator/fields.ts` (dziś **rdzeń importuje z modułu** — odwrócona zależność).
+
 ## v1.x — Post-v1.0 deferred
 
 - [ ] `[feature]` `[P1]` SEO module — SERP preview, char limits, global settings, frontend components, sitemap (full plan: `ideas/post-v1/seo-aeo-geo-module.md`)
@@ -56,6 +86,8 @@
 
 ## Backlog
 
+- [ ] `[fix]` `[P1]` Wyciek puli połączeń DB w dev (HMR) — pojedynczy proces `vite dev` konsumenta trzymał **100 połączeń** do Postgresa (cały `max_connections`), po czym baza odbijała wszystko: `FATAL: sorry, too many clients already` (zaobserwowane 2026-07-13 na pod-zwrotnikami). Hipoteza: każde przeładowanie modułu przez HMR tworzy nowy klient `postgres.js` (pula domyślnie 10), a stary nie jest zamykany — 10 przeładowań wyczerpuje limit. Sprawdzić zamykanie klienta w `import.meta.hot.dispose` / singleton na `globalThis` w adapterze. Dotyka każdego, kto dłużej pracuje w dev. <!-- files: src/lib/db-postgres/index.ts -->
+- [ ] `[chore]` `[P1]` CMS doctor — `validateLayout()` jest napisany i przetestowany, ale nie jest wołany z żadnego miejsca produkcyjnego: literówka w nazwie pola w tabie przechodzi po cichu (pole ląduje w orphanach). Podpiąć go do `defineConfig` obok `validatePreviews`, dołożyć `pnpm cms check` w CLI i zestaw reguł zdrowia configu (martwe pola, `pathTemplate` bez `previewUrl`/`previews`, itp.). <!-- files: src/lib/core/fields/layoutUtils.ts, src/lib/sveltekit/config.ts, src/lib/core/config/, src/lib/cli/index.ts -->
 - [ ] `[feature]` `[P2]` Date/datetime field — przebudowa na shadcn-svelte (bits-ui Calendar/DatePicker) zamiast natywnego inputu. Zgłoszone w QA Etap 5a (4/5); funkcjonalnie OK, odłożone jako osobny redesign pola daty. <!-- files: src/lib/admin/components/fields/date-field.svelte, datetime-field.svelte -->
 - [ ] `[feature]` `[P2]` `<Video>` — eksponować ref wewnętrznego `<video>` (np. bindable `element` prop lub forward `bind:this`). Obecnie konsument potrzebujący programowej kontroli (play/pause, scrub, mute toggle) musi owijać w `<div bind:this>` + `querySelector('video')` — boilerplate i kruche. Zgłoszone przy customowym hero-wideo (autoplay + przycisk pauzy). <!-- files: src/lib/sveltekit/components/video.svelte -->
 - [ ] `[feature]` `[P1]` Re-introduce entry autosave with strict draft-only guard (opt-in via `cms.config.ts`, never touch published versions, debounced + visual countdown). Removed in 0.26.0 / S8 because old impl could touch published data ambiguously.

package/dist/admin/client/booking/booking-dashboard.svelte

@@ -0,0 +1,40 @@
+<script lang="ts">
+	import { getRemotes } from '../../../sveltekit/index.js';
+	import { useInterfaceLanguage } from '../../state/interface-language.svelte.js';
+	import StatCard from '../modules/stat-card.svelte';
+	import { Button } from '../../../components/ui/button/index.js';
+	import { formatCentsPrice } from '../../utils/formatters.js';
+
+	const remotes = getRemotes();
+	const interfaceLanguage = useInterfaceLanguage();
+
+	// Agregaty liczone w SQL — lista rezerwacji jest stronicowana, więc sumowanie jej wierszy
+	// dawałoby po cichu statystyki wyłącznie z pierwszej strony.
+	const statsQuery = $derived(remotes.getBookingStats());
+	const stats = $derived(statsQuery.current);
+
+	const active = $derived(stats?.active ?? 0);
+	const outstanding = $derived(stats?.outstanding ?? 0);
+	const toConfirm = $derived(stats?.toConfirm ?? 0);
+	const currency = $derived(stats?.currency ?? 'PLN');
+
+	const t = $derived(
+		interfaceLanguage.current === 'pl'
+			? { active: 'Aktywne rezerwacje', outstanding: 'Zaległe salda', toConfirm: 'Do potwierdzenia', manage: 'Rezerwacje' }
+			: { active: 'Active bookings', outstanding: 'Outstanding balances', toConfirm: 'To confirm', manage: 'Reservations' }
+	);
+</script>
+
+<div class="flex flex-col gap-4 px-4 pb-6 sm:px-6">
+	<div class="grid grid-cols-2 gap-3 sm:grid-cols-3">
+		<StatCard label={t.active} value={statsQuery.ready ? active : '—'} />
+		<StatCard
+			label={t.outstanding}
+			value={statsQuery.ready ? formatCentsPrice(outstanding, currency) : '—'}
+		/>
+		<StatCard label={t.toConfirm} value={statsQuery.ready ? toConfirm : '—'} />
+	</div>
+	<div class="flex flex-wrap gap-2">
+		<Button href="/admin/booking/reservations" variant="outline" size="sm">{t.manage}</Button>
+	</div>
+</div>

package/dist/admin/client/booking/booking-dashboard.svelte.d.ts

@@ -0,0 +1,3 @@
+declare const BookingDashboard: import("svelte").Component<Record<string, never>, {}, "">;
+type BookingDashboard = ReturnType<typeof BookingDashboard>;
+export default BookingDashboard;