includio-cms 0.36.9 → 0.37.0

package/dist/types/config.d.ts

@@ -1,10 +1,43 @@
 import type { Field } from './fields.js';
 import type { IconName } from '../admin/components/icons/icon-map.js';
 import type { Layout } from './layout.js';
+import type { Localized } from './languages.js';
+/**
+ * A named preview target. The same entry is often rendered in more than one way
+ * on the front end — a full page and a teaser card in a listing — and each way
+ * is a view.
+ *
+ * The admin loads `{url}?preview={entryId}&view={name}` in the preview iframe,
+ * so a project may expose one route per view, or a single route that branches
+ * on the `view` query param. Views do not change what is fetched from the
+ * database — the entry always arrives whole.
+ *
+ * @public
+ * @example
+ * ```ts
+ * previews: [
+ *   { name: 'full', label: { pl: 'Pełny wpis' }, url: '/preview/blog-post' },
+ *   { name: 'teaser', label: { pl: 'Zajawka' }, url: '/preview/blog-post/teaser' }
+ * ]
+ * ```
+ */
+export interface PreviewView {
+    /** Stable identifier, referenced by `TabNode.preview`. */
+    name: string;
+    /** Switcher label. Defaults to `name`. */
+    label?: Localized;
+    /** Preview route, e.g. '/preview/blog-post/teaser'. */
+    url: string;
+    /** Start view. Defaults to the first entry of the array. */
+    default?: boolean;
+}
 export interface ConfigBase {
     sidebarIcon?: IconName;
     slug: string;
+    /** Shorthand for a single preview view. Mutually exclusive with `previews`. */
     previewUrl?: string;
+    /** Named preview views. Mutually exclusive with `previewUrl`. */
+    previews?: PreviewView[];
     fields: Field[];
     layout?: Layout;
     slugField?: string;

package/dist/types/layout.d.ts

@@ -81,6 +81,12 @@ export interface TabsNode extends LayoutNodeBase {
 export interface TabNode extends LayoutNodeBase {
     type: 'tab';
     label: Localized;
+    /**
+     * Name of a view from `previews[]`. Entering this tab switches the preview to
+     * that view, unless the user manually picked another view while on this tab.
+     * A tab without `preview` leaves the current view alone.
+     */
+    preview?: string;
     fields?: string[];
     children?: LayoutNode[];
 }

package/dist/types/modules.d.ts

@@ -0,0 +1,133 @@
+/**
+ * Module system — shop, booking, and future "overlays" on the CMS core.
+ *
+ * A module is registered via `defineConfig({ modules: [...] })`. It is split
+ * into a **serializable descriptor** (id/label/icon/context — safe to send to
+ * the admin client via a remote query) and **server-only `serverHooks`**
+ * (init logic that must never cross the wire). The module's dashboard
+ * component lives in a separate client-side registry keyed by `id`, never in
+ * the config — Svelte components are not serializable and the config is also
+ * validated server-side with Zod.
+ *
+ * @see {@link CMSModule}
+ */
+/** A label that is either a plain string or a `{ lang: text }` map. */
+export type LocalizedText = string | Record<string, string>;
+/**
+ * One sidebar entry contributed by a module's context. Icons are referenced
+ * by **name** (resolved client-side via the admin icon-map), never as a
+ * component, so the descriptor stays serializable and userland never needs an
+ * icon library as a dependency.
+ *
+ * @public
+ */
+export interface ModuleNavSection {
+    /** Stable key for keyed rendering and active-state checks. */
+    key: string;
+    /** Display title. */
+    title: LocalizedText;
+    /** Target route, e.g. `/admin/shop/orders`. */
+    url: string;
+    /** Icon name from the admin icon-map, e.g. `shopping-cart`. */
+    icon: string;
+    /**
+     * Optional remote-query name returning a `number`, rendered as a badge and
+     * resolved reactively on the client (same pattern as collection entry
+     * counts). Omit for sections without a count.
+     */
+    countSource?: string;
+}
+/**
+ * The curated workspace a module contributes: a landing (dashboard) target,
+ * its own nav sections, and optional **surfaced** core collections/singles
+ * pulled into the module's context (e.g. shop surfaces the `products`
+ * collection as "Products").
+ *
+ * @public
+ */
+export interface ModuleContext {
+    /** Switcher label for this context. Defaults to the module's `label`. */
+    contextLabel?: LocalizedText;
+    /** Where selecting this context navigates, e.g. `/admin/shop`. */
+    landingUrl: string;
+    /** Static nav sections owned by the module. */
+    sections: ModuleNavSection[];
+    /** Slugs of core collections surfaced inside this context. */
+    surfacedCollections?: string[];
+    /** Slugs of core singles surfaced inside this context. */
+    surfacedSingles?: string[];
+}
+/** Context passed to a module's `serverHooks.init`. */
+export interface ModuleInitContext {
+    /** Raw drizzle handle (`databaseAdapter._drizzle`), or `undefined`. */
+    drizzle: unknown;
+    /** The module's own resolved config (same reference as `CMSModule.config`). */
+    config: unknown;
+    /** The CMS default language code (first configured language). */
+    defaultLanguage: string;
+}
+/**
+ * Server-only module hooks. NEVER serialized or sent to the admin client —
+ * stripped from the descriptor returned by `getModules()`.
+ *
+ * @public
+ */
+export interface ModuleServerHooks {
+    /**
+     * Idempotent boot-time init run by `initCMS` (e.g. create indexes,
+     * smoke-test templates). Non-blocking: errors are logged, not thrown.
+     *
+     * Define this ONLY in a server-only module. A module whose factory (e.g.
+     * `defineBooking`) is re-exported from a client-safe barrel MUST NOT inline a
+     * server import here — bundlers create a chunk for it and break browser builds.
+     * Use {@link initModule} instead.
+     */
+    init?: (ctx: ModuleInitContext) => Promise<void> | void;
+    /**
+     * Bare package specifier of a SERVER-ONLY module exporting `serverInit(ctx)`,
+     * run by `initCMS` at boot. Prefer this over {@link init} when the module's
+     * factory lives in a client-safe barrel: it is a plain string (no import), so
+     * the client bundle stays free of server code. `initCMS` (server-only) resolves
+     * and imports it at runtime from node_modules. Ignored if {@link init} is set.
+     */
+    initModule?: string;
+}
+/**
+ * A CMS module ("overlay"): shop, booking, etc. Register via
+ * `defineConfig({ modules: [defineShop(...), defineBooking(...)] })`.
+ *
+ * @public
+ */
+export interface CMSModule {
+    /** Unique slug, e.g. `shop` | `booking`. */
+    id: string;
+    /** Display label (switcher + sidebar group label). */
+    label: LocalizedText;
+    /** Icon name from the admin icon-map, e.g. `building-store`. */
+    icon: string;
+    /** The curated workspace this module contributes. */
+    context: ModuleContext;
+    /** The module's typed resolved config — opaque to the framework. */
+    config?: unknown;
+    /** Server-only hooks (not part of the serialized descriptor). */
+    serverHooks?: ModuleServerHooks;
+}
+/**
+ * The serializable subset of a {@link CMSModule} sent to the admin client.
+ * Excludes `config` (may hold adapter functions) and `serverHooks`.
+ *
+ * @public
+ */
+export interface CMSModuleDescriptor {
+    id: string;
+    label: LocalizedText;
+    icon: string;
+    context: ModuleContext;
+}
+/**
+ * Strips a {@link CMSModule} down to its serializable {@link CMSModuleDescriptor}
+ * for transport to the admin client. Drops `config` and `serverHooks`.
+ *
+ * @public
+ */
+export declare function toModuleDescriptor(module: CMSModule): CMSModuleDescriptor;

package/dist/types/modules.js

@@ -0,0 +1,27 @@
+/**
+ * Module system — shop, booking, and future "overlays" on the CMS core.
+ *
+ * A module is registered via `defineConfig({ modules: [...] })`. It is split
+ * into a **serializable descriptor** (id/label/icon/context — safe to send to
+ * the admin client via a remote query) and **server-only `serverHooks`**
+ * (init logic that must never cross the wire). The module's dashboard
+ * component lives in a separate client-side registry keyed by `id`, never in
+ * the config — Svelte components are not serializable and the config is also
+ * validated server-side with Zod.
+ *
+ * @see {@link CMSModule}
+ */
+/**
+ * Strips a {@link CMSModule} down to its serializable {@link CMSModuleDescriptor}
+ * for transport to the admin client. Drops `config` and `serverHooks`.
+ *
+ * @public
+ */
+export function toModuleDescriptor(module) {
+    return {
+        id: module.id,
+        label: module.label,
+        icon: module.icon,
+        context: module.context
+    };
+}

package/dist/updates/0.37.0/index.d.ts

@@ -0,0 +1,2 @@
+import type { CmsUpdate } from '../index.js';
+export declare const update: CmsUpdate;

package/dist/updates/0.37.0/index.js

@@ -0,0 +1,52 @@
+export const update = {
+    version: '0.37.0',
+    date: '2026-06-17',
+    description: '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`.',
+    features: [
+        '`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.'
+    ],
+    fixes: [
+        '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`.'
+    ],
+    breakingChanges: [
+        '`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.'
+};

package/dist/updates/index.js

@@ -75,6 +75,7 @@ import { update as update0365 } from './0.36.5/index.js';
 import { update as update0367 } from './0.36.7/index.js';
 import { update as update0368 } from './0.36.8/index.js';
 import { update as update0369 } from './0.36.9/index.js';
+import { update as update0370 } from './0.37.0/index.js';
 export const updates = [
     update0065,
     update0066,
@@ -152,7 +153,8 @@ export const updates = [
     update0365,
     update0367,
     update0368,
-    update0369
+    update0369,
+    update0370
 ];
 export const getUpdatesFrom = (fromVersion) => {
     const fromParts = fromVersion.split('.').map(Number);

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "includio-cms",
-	"version": "0.36.9",
+	"version": "0.37.0",
 	"scripts": {
 		"dev": "vite dev",
 		"build": "vite build && npm run prepack",
@@ -111,6 +111,10 @@
 			"types": "./dist/db-postgres/schema-shop.d.ts",
 			"node": "./dist/db-postgres/schema-shop.js"
 		},
+		"./db-postgres/schema-booking": {
+			"types": "./dist/db-postgres/schema-booking.d.ts",
+			"node": "./dist/db-postgres/schema-booking.js"
+		},
 		"./auth-schema": {
 			"types": "./dist/server/db/schema/auth-schema.d.ts",
 			"node": "./dist/server/db/schema/auth-schema.js"
@@ -129,6 +133,20 @@
 			"types": "./dist/shop/http/index.d.ts",
 			"node": "./dist/shop/http/index.js"
 		},
+		"./booking": {
+			"types": "./dist/booking/index.d.ts",
+			"svelte": "./dist/booking/index.js",
+			"node": "./dist/booking/index.js"
+		},
+		"./booking/client": {
+			"types": "./dist/booking/client/index.d.ts",
+			"svelte": "./dist/booking/client/index.js",
+			"node": "./dist/booking/client/index.js"
+		},
+		"./booking/server": {
+			"types": "./dist/booking/server/index.d.ts",
+			"node": "./dist/booking/server/index.js"
+		},
 		"./files-local": {
 			"types": "./dist/files-local/index.d.ts",
 			"node": "./dist/files-local/index.js"

package/dist/admin/components/layout/nav-shop.svelte

@@ -1,33 +0,0 @@
-<script lang="ts">
-	import { useInterfaceLanguage } from '../../state/interface-language.svelte.js';
-	import { sidebarLang } from './lang.js';
-	import { getRemotes } from '../../../sveltekit/index.js';
-	import PackageIcon from '@tabler/icons-svelte/icons/package';
-	import ShoppingCartIcon from '@tabler/icons-svelte/icons/shopping-cart';
-	import TruckIcon from '@tabler/icons-svelte/icons/truck';
-	import TicketIcon from '@tabler/icons-svelte/icons/ticket';
-	import BuildingStoreIcon from '@tabler/icons-svelte/icons/building-store';
-	import { page } from '$app/state';
-	import NavSection, { type NavSectionItem } from './nav-section.svelte';
-
-	const interfaceLanguage = useInterfaceLanguage();
-	const lang = $derived(sidebarLang[interfaceLanguage.current].shop);
-	const remotes = getRemotes();
-	const enabledQuery = $derived(remotes.getShopEnabled());
-
-	function isActive(url: string) {
-		const pathname = page.url.pathname;
-		return pathname === url || pathname.startsWith(url + '/');
-	}
-
-	const items: NavSectionItem[] = $derived([
-		{ title: lang.products, url: '/admin/shop/products', icon: PackageIcon },
-		{ title: lang.orders, url: '/admin/shop/orders', icon: ShoppingCartIcon },
-		{ title: lang.shipping, url: '/admin/shop/shipping-methods', icon: TruckIcon },
-		{ title: lang.coupons, url: '/admin/shop/coupons', icon: TicketIcon }
-	]);
-</script>
-
-{#if enabledQuery.ready && enabledQuery.current}
-	<NavSection {items} label={lang.title} labelIcon={BuildingStoreIcon} {isActive} withTopBorder />
-{/if}

package/dist/admin/components/layout/nav-shop.svelte.d.ts

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