wineater-bot 4.24.1 → 4.24.3

package/package.json

@@ -1,9 +1,13 @@
 {
   "name": "wineater-bot",
-  "version": "4.24.1",
+  "version": "4.24.3",
   "description": "",
   "main": "dist/wineater-chatbot.mjs",
   "module": "src/index.js",
+  "files": [
+    "dist",
+    "README.md"
+  ],
   "type": "module",
   "scripts": {
     "dev": "vite",

package/.claude/settings.local.json

@@ -1,10 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(git remote *)"
-    ]
-  },
-  "disabledMcpjsonServers": [
-    "supabase"
-  ]
-}

package/.prettierignore

@@ -1,9 +0,0 @@
-# Package Managers
-package-lock.json
-pnpm-lock.yaml
-yarn.lock
-bun.lock
-bun.lockb
-
-# Miscellaneous
-/static/

package/.prettierrc

@@ -1,16 +0,0 @@
-{
-	"useTabs": true,
-	"singleQuote": true,
-	"trailingComma": "none",
-	"printWidth": 100,
-	"plugins": ["prettier-plugin-svelte", "prettier-plugin-tailwindcss"],
-	"overrides": [
-		{
-			"files": "*.svelte",
-			"options": {
-				"parser": "svelte"
-			}
-		}
-	],
-	"tailwindStylesheet": "./src/app.css"
-}

package/CLAUDE.md

@@ -1,115 +0,0 @@
-# Wineater Bot — Claude Context
-
-## What is this?
-
-This is **wineater-bot** — an embeddable wine recommendation widget that is part of the larger Wineater project. It gets either embedded into client websites via a `<script>` tag or offered as a standalone page hosted by Wineater.
-
-It renders a wine grid with search, hover/click popups, and analytics, all in a self-contained JS bundle.
-
-## Tech Stack
-
-- **Svelte 5** (runes-based reactivity: `$state`, `$derived`, `$effect`)
-- **TypeScript**
-- **Vite** (build tool, dev server on :3001)
-- Output: `dist/wineater-chatbot.mjs` (ESM) + `dist/wineater-chatbot.umd.js` (UMD)
-
-## How to Run
-
-```bash
-pnpm dev        # dev server at localhost:3001
-pnpm build      # produces dist/ bundles
-pnpm test       # unit + e2e
-pnpm test:unit  # Vitest (browser via Playwright/Chromium)
-pnpm test:e2e   # Playwright
-pnpm lint       # Prettier + ESLint
-```
-
-## Project Structure
-
-```
-src/
-├── index.js                      # Entry: mounts App.svelte to #wineater-widget-conteiner
-├── App.svelte                    # Root component (419 lines, core logic)
-├── components/
-│   ├── Header.svelte
-│   ├── Footer.svelte
-│   ├── Search.svelte             # Animated placeholder cycling search bar
-│   ├── WineTile.svelte           # Wine card: hover popup (desktop), click modal (mobile)
-│   ├── WinePopup.svelte          # Full wine detail modal
-│   ├── SkeletonTiles.svelte      # Placeholder cards (initial load + while searching)
-│   ├── ui/Action.svelte          # Reusable button/link
-│   └── icons/                   # SVG icon components (Budget, Diamond, Fish, Meat, Heart)
-└── services/
-    ├── api/api.ts                # WineaterApi class → Wineater backend
-    ├── cache.ts                  # localStorage stale-while-revalidate helpers
-    ├── api/deserialize.ts        # API response → Wine / RecommendedWine types
-    ├── analytics/analytics.ts   # Event tracking → admin-api.wineater.com
-    ├── analytics/constants.ts   # Widget event type constants
-    ├── store/app-store.svelte.ts # Global state (Svelte runes)
-    ├── i18n/i18n.ts             # Translations + OpenAI wine description translation
-    └── ui-config/               # Per-project branding/CSS/translations
-```
-
-## Key Concepts
-
-### Initialization
-Client page sets `window.wineaterData = { CLIENT_TOKEN, WIDGET_TYPE, COUNTRY_CODE }` before loading the script. The widget reads this on mount.
-
-### Widget Modes
-- `store` — retail wine shop, hover popups
-- `bar` — bar/restaurant, enables AI translation of wine descriptions
-
-### Multi-tenancy (Per-Project Config)
-Hardcoded in `src/services/ui-config/projects-config.ts` for projects 0, 21, 25, 26. Each project can have: custom brand color, logo, CSS, translations, button styling.
-
-CSS variables at runtime: `--wr-brand-color`, `--wr-wineater-color`, `--wineater-font-primary`
-
-### API Endpoints Used
-| Service | Endpoint |
-|---|---|
-| Wineater Backend | `https://wineater-backend.vercel.app/` |
-| Admin API (analytics) | `https://admin-api.wineater.com/api/widget-events` |
-| OpenAI | `https://api.openai.com/v1/chat/completions` (gpt-3.5-turbo, wine translation) |
-
-### Languages Supported
-`en, de, fr, es, it, ja, zh, ru, kk, pt`
-
-### DOM Mount Point
-```html
-<div id="wineater-widget-conteiner"></div>
-```
-Note the intentional typo in "conteiner" — it is used in production, do not fix it.
-
-## Performance Notes
-
-- Store config (24h) and instant recommendations (6h) are cached in localStorage (`wineater:v1:<token-hash>:…`); cached data paints immediately, the network response only refreshes the cache for the next visit
-- Config and instant requests start in parallel; search/more/similar requests start before the 220 ms card-slide animation
-- The `es` bundle is minified by the `minify-esm-bundle` plugin in `vite.config.js` (Vite skips whitespace minification for `es` lib builds)
-- `@import` in project `customCss` is converted to `<link rel="stylesheet">` by `generateInlineStyle`
-
-## Shopify mode (4.24+)
-
-On a Shopify storefront the Wineater app embed (repo `wineater-shopify`) sets `window.wineaterData.shopify`
-(`shop`, `locale`, `currency`, `root`, `config`, `color`) and `mountTarget` (a div inside a shadow root), then loads
-this bundle. `src/services/shopify/` switches the widget to `/shopify/storefront/{instant,search,events}`, BUY becomes
-"Add to cart" (`Shopify.actions` → `/cart/add.js` → cart permalink, cart attribute `_wineater_session`), 429
-`quota_exceeded` shows instant picks + "Our sommelier is resting", no footer link, no own cookies or web fonts, consent
-from the Shopify Customer Privacy API. Without `wineaterData.shopify` nothing changes for existing clients.
-
-## Important Gotchas
-
-
-- `#wineater-widget-conteiner` — this typo is intentional and load-bearing
-- Wine translations use OpenAI and require `open_ai_key` from store config (only in `bar` mode)
-- Analytics is only the first-party `trackWidgetEvent` (admin-api.wineater.com); OpenReplay session replay was removed
-- Per-project configs are hardcoded (not fetched) — changes require rebuild + redeploy
-- `dist/` files are committed to the repo (clients reference them directly or via npm)
-- Package manager: **pnpm**
-
-## Release Process
-
-```bash
-pnpm release:patch   # bump patch, publish to npm
-pnpm release:minor   # bump minor, publish to npm
-pnpm release:beta    # beta tag
-```

package/docs/CUSTOMIZATION.md

@@ -1,133 +0,0 @@
-# ADR: Widget Customization System
-
-**Date:** 26.11.2025  
-**PR:** https://github.com/Wineater/wineater-bot/pull/2
-
-## Context
-
-Clients increasingly request widget customization for their specific brands and use cases. Typical requests include:
-
-- Changing colors and overall color scheme.
-- Adjusting fonts and typography.
-- Tweaking styles of individual UI elements (buttons, inputs, popups, etc.).
-- Customizing translations and text copy.
-
-Previously, such changes were mostly implemented as one‑off, manual style overrides or ad‑hoc modifications in the codebase. This approach has several drawbacks:
-
-- Poor scalability when multiple clients require different customizations.
-- High risk of regressions when editing styles for a single client.
-- No clear system for naming, organizing, or reusing styles and components.
-- Limited ability to evolve towards a proper design system and reusable components.
-
-We want to move away from manual, one‑by‑one style hacking and instead provide:
-
-- A component library that can be configured at the level of components, not individual DOM elements.
-- A token‑based color scheme and shared design primitives.
-- A single configuration entry point where client‑specific overrides can be described declaratively.
-
-## Decision
-
-We introduced a **customization system** for the widget with the following key aspects:
-
-1. **Class naming system using BEM**
-   - A consistent naming convention was introduced for widget elements based on the BEM methodology.
-   - This makes it easier to:
-     - Identify and target elements for styling.
-     - Maintain styles over time.
-     - Reason about component structure and responsibilities.
-
-2. **Centralized client configuration**
-   - Client‑specific behavior and appearance are now configured from a single configuration object.
-   - The configuration contains:
-     - General options that control various parts of the system (e.g. feature toggles and UI behavior flags).
-     - A `customCss` field that allows providing custom CSS for a client.
-
-3. **Custom CSS entry point**
-   - The `customCss` property is designed for injecting client‑specific style overrides.
-   - To increase specificity and avoid conflicts with default styles, all overrides must start from the `#wr-Custom` root selector.
-   - Example pattern:
-     - `#wr-Custom .wr-Button { /* client-specific overrides */ }`
-
-4. **Direction towards tokens and components**
-   - The current implementation is a first step towards:
-     - A shared color system expressed via tokens.
-     - A reusable set of components that can support variants (e.g. primary/secondary buttons, different input styles).
-   - The long‑term goal is to customize **component variants and design tokens** rather than patching arbitrary DOM elements with manual CSS.
-
-## Alternatives
-
-1. **Styling approach: Tailwind instead of BEM**
-   - We considered using Tailwind CSS (utility‑first classes) instead of the BEM naming convention.
-   - Pros:
-     - Potentially smaller final CSS payload due to tree‑shaking.
-     - Easier merging of classes to avoid shipping unused styles.
-   - Cons:
-     - Would require a full rewrite of existing styles into utility classes.
-     - Requires an additional class‑merge utility and Tailwind tooling in the build pipeline.
-     - Makes the resulting HTML/CSS less predictable for client‑side overrides, especially when clients are not familiar with Tailwind.
-   - Given the current state of the project and the need for predictable element names for customization, BEM was chosen over Tailwind.
-
-2. **Configuration approach: separate CSS file per client**
-   - We also considered storing custom styles for each client in a dedicated CSS file.
-   - Pros:
-     - Clear physical separation of styles per client.
-     - Simpler for some hosting scenarios.
-   - Cons:
-     - Requires injecting a client identifier into the HTML to load the correct file.
-     - Increases deployment and configuration complexity (managing many CSS files per environment).
-     - Harder to keep styles and other configuration (translations, feature flags) in sync in a single place.
-   - Instead, we opted for a single configuration entry with an inline `customCss` field.
-
-## Expectations
-
-From this decision we expect the following benefits:
-
-1. **More flexible customization for clients**
-   - Ability to adjust translations, color schemes, and key UI elements (buttons, inputs, basic layout) per client.
-   - A clear mechanism for styling without touching internal implementation details of the widget.
-
-2. **Move towards a design‑system approach**
-   - Over time, introduce configurable component variants instead of ad‑hoc overrides.
-   - Establish color tokens and a configurable theme, instead of manually redefining colors in many places.
-
-3. **Safer and more maintainable styling changes**
-   - BEM class naming makes selectors more predictable and less fragile.
-   - Centralized configuration reduces the chance of forgetting to apply a setting in some part of the system.
-
-## Technical Debt and Planned Improvements
-
-The current customization system is intentionally minimal and leaves several areas as explicit technical debt:
-
-1. **Global configuration shared across projects**
-   - A single configuration model is used across multiple projects/clients, which means some unused options are shipped everywhere.
-   - We plan to introduce a more modular configuration structure so that clients only receive relevant settings.
-
-2. **Manual style rewrites and lack of a change strategy**
-   - Many styles are still written and updated manually without a clear evolution path.
-   - We need a defined process and guidelines for introducing and deprecating style rules.
-
-3. **Missing color system**
-   - There is no dedicated color token system yet.
-   - Colors are not centralized, making it hard to define themes and variants.
-
-4. **No component‑level design tokens**
-   - Components (buttons, inputs, etc.) do not expose design tokens for spacing, radii, typography, and interaction states.
-   - A future step is to define tokens per component and allow them to be configured per client.
-
-5. **Lack of component variants**
-   - Components do not yet expose standardized variants (e.g. `primary`, `secondary`, `ghost`).
-   - Introducing variants will make customization more structured and reduce the need for one‑off overrides.
-
-6. **Font customization limitations**
-   - At the moment, fonts are effectively tied to Google Fonts.
-   - There is no supported mechanism for loading custom font files or non‑Google font providers per client.
-
-7. **Icon customization limitations**
-   - It is not yet possible to change icon colors or replace icons via configuration.
-   - Future work should define an icon system (e.g. via tokens or an icon registry) that can be overridden per client.
-
-8. **No first‑class configuration for core UI elements**
-   - Core components such as buttons and inputs are not yet configurable via a structured theme API.
-   - Future improvements should expose configuration options for these components (sizes, radii, colors, typography, and states) instead of relying solely on `customCss`.
-
-These items are expected to be addressed iteratively as we mature the customization system and move closer to a full design‑system and token‑based theming approach.

package/docs/SVELTE.md

@@ -1,146 +0,0 @@
-# ADR: Migrating the Widget to Svelte
-
-**Date:** 23.11.2025  
-**PR:** https://github.com/Wineater/wineater-bot/pull/1
-
-## Context
-
-Historically, the Wineater widget was written in plain JavaScript. The code was rewritten multiple times while product hypotheses were being tested. As a result:
-
-- The widget became hard to maintain: the business logic was obscured by a large amount of DOM‑manipulation boilerplate.
-- The codebase contained a lot of legacy, unused code.
-- Making changes required deep knowledge of implementation details, raising the onboarding cost for new developers.
-
-To reduce project-specific knowledge and simplify maintenance, we decided to move to a framework with:
-
-- Clear documentation,
-- Declarative UI,
-- Built-in reactivity.
-
-At the time of the decision:
-
-- The widget must be embeddable on client sites (as a script) and stay very small in terms of JS bundle size.
-- We need to be able to quickly experiment with UI and business logic without accumulating more low-level DOM boilerplate.
-- Migration of services from JS to TS had already started, and a clear separation between business logic and the framework was important.
-
-Changes made as part of this migration:
-
-1. Removed unused code that was not referenced anywhere.
-2. Improved the “wine” entity handling:
-   - Previously, the instant/search APIs returned different shapes (e.g. instant: `ID`, `Title`; search: `id`, `title`), which caused many conditional checks and branches in the code.
-   - Introduced deserialization in the data access layer, so the UI layer always works with a consistent wine entity.
-3. Language switching no longer reloads the page; state is managed via a global store and Svelte reactivity.
-4. Currency formatting is now done via the standard browser `Intl` API, reducing custom code and localization bugs.
-5. All services were migrated from JS to TypeScript and rewritten to not depend on the framework (Svelte is used only at the UI layer).
-6. Introduced the global `app-store` for API‑loaded config and helper methods to access it.
-
-Current limitations / technical debt:
-
-- `App.svelte` is too large and holds too many responsibilities.
-- Popup translations and some animations (search placeholder) still manipulate the DOM directly instead of using Svelte’s reactive state.
-- A significant amount of code was migrated “as is” from the old codebase to avoid blocking the migration; it still needs structural refactoring.
-
-## Alternatives
-
-Framework options considered:
-
-1. **React**
-   - Pros:
-     - Already used in other products of the startup.
-     - Large ecosystem and community.
-   - Cons:
-     - Relatively heavy runtime and bundle size for a small embedded widget.
-     - DX (as of 2025) is not ideal for a lightweight embeddable widget.
-     - Typically requires more wiring (hooks, context, styling solutions), which leads to additional boilerplate.
-
-2. **Vue**
-   - Pros:
-     - Good DX, relatively low learning curve.
-     - Lighter and faster than React at runtime.
-   - Cons:
-     - Still relatively heavy for a very small, embeddable widget.
-     - Keeps a runtime library in the bundle, increasing overall JS size.
-
-3. **Svelte** (chosen)
-   - Pros:
-     - Compiles to “plain” JS and effectively disappears as a framework at runtime (no heavy runtime library).
-     - Much smaller JS payload, which is critical for a widget.
-     - Built-in reactivity, templating, and styling support, which reduces external boilerplate.
-     - Helps separate business logic (services, store) from the presentation layer.
-   - Cons:
-     - Smaller ecosystem compared to React/Vue.
-     - Fewer developers on the market with Svelte experience.
-
-4. **Stay on plain JS** (status quo)
-   - Pros:
-     - No framework dependency.
-     - Maximum control over DOM and the bundle.
-   - Cons:
-     - High volume of DOM‑manipulation boilerplate.
-     - Hard to maintain, high cost of change.
-     - Low readability of business logic.
-
-## Decision
-
-We decided to rewrite the widget’s client-side code using **Svelte**, while keeping:
-
-- Type‑safe business logic and services in TypeScript, independent from the framework.
-- A lightweight, compiled UI layer without a heavy runtime.
-
-Key aspects of the decision:
-
-- **Framework:** Svelte is chosen as the best compromise between DX, performance, and bundle size for an embeddable widget.
-- **Architecture:**
-  - Introduce a global `app-store` to keep config and shared state.
-  - Keep services (API calls, deserialization, etc.) outside of the UI layer and independent of Svelte.
-- **Compatibility:**
-  - We still generate a UMD bundle for historical reasons. If UMD is no longer used in the future, this format can be removed from the build configuration.
-- **Functional changes within this migration:**
-  - Unified wine data model.
-  - Language switching without full page reload.
-  - Currency formatting via `Intl`.
-
-## Expectations
-
-High-level expectations from this decision:
-
-1. **Simpler maintenance and onboarding**
-   - Business logic is easier to understand thanks to declarative Svelte UI and reactivity.
-   - New developers can rely on framework documentation instead of project-specific DOM patterns.
-
-2. **Smaller bundle and better performance for an embeddable widget**
-   - Svelte compiles away, reducing runtime overhead compared to heavier frameworks.
-   - Unified data model and removal of unused code reduce complexity and runtime branching.
-
-3. **Faster and safer product experimentation**
-   - Clear separation between services, store, and UI makes it easier to iterate on features without destabilizing the widget.
-   - Shared architecture across clients enables more customized UIs with controlled complexity.
-
-## Technical Debt and Planned Improvements
-
-The following items are explicitly acknowledged as technical debt or future improvement areas, not as part of the initial migration scope:
-
-1. **UI structure and DOM usage**
-   - `App.svelte` is too large and should be decomposed into smaller, focused components.
-   - Remaining direct DOM manipulations (popup translations, search placeholder animations, etc.) should be replaced with reactive Svelte patterns.
-
-2. **State management**
-   - Reduce coupling between the global state and other modules.
-   - Split the single global store into several domain-specific stores (e.g., language, config, session, search results).
-
-3. **Testing and typing**
-   - Increase end-to-end (E2E) test coverage for critical flows (embedding, search, language switching, recommendations).
-   - Gradually improve TypeScript typings at boundaries between services and UI to catch more issues at compile time.
-
-4. **Localization**
-   - Implement a translation mechanism that does not require passing the locale explicitly through every call, relying instead on a centralized locale context/store.
-
-5. **Logging and observability**
-   - Improve the logger so that events from local development do not pollute production analytics/logs (environment-aware logging).
-
-6. **Configuration and deployment hygiene**
-   - Move hardcoded `CLIENT_TOKEN` into environment variables, so credentials are not hardcoded in the HTML files.
-   - Introduce project/environment configurations and store `WIDGET_TYPE` and similar parameters there instead of hardcoding them in HTML/JS.
-   - Remove per-environment HTML files currently added for each Vercel environment and replace them with a single entry point plus configuration-driven behavior.
-
-These items should be addressed iteratively in follow-up work, once the Svelte migration is stable and validated in production.

package/e2e/demo.test.ts

@@ -1,6 +0,0 @@
-import { expect, test } from '@playwright/test';
-
-test('home page has expected h1', async ({ page }) => {
-	await page.goto('/');
-	await expect(page.locator('h1')).toBeVisible();
-});

package/eslint.config.js

@@ -1,41 +0,0 @@
-import prettier from 'eslint-config-prettier';
-import { fileURLToPath } from 'node:url';
-import { includeIgnoreFile } from '@eslint/compat';
-import js from '@eslint/js';
-import svelte from 'eslint-plugin-svelte';
-import { defineConfig } from 'eslint/config';
-import globals from 'globals';
-import ts from 'typescript-eslint';
-import svelteConfig from './svelte.config.js';
-
-const gitignorePath = fileURLToPath(new URL('./.gitignore', import.meta.url));
-
-export default defineConfig(
-	includeIgnoreFile(gitignorePath),
-	js.configs.recommended,
-	...ts.configs.recommended,
-	...svelte.configs.recommended,
-	prettier,
-	...svelte.configs.prettier,
-	{
-		languageOptions: {
-			globals: { ...globals.browser, ...globals.node }
-		},
-		rules: {
-			// typescript-eslint strongly recommend that you do not use the no-undef lint rule on TypeScript projects.
-			// see: https://typescript-eslint.io/troubleshooting/faqs/eslint/#i-get-errors-from-the-no-undef-rule-about-global-variables-not-being-defined-even-though-there-are-no-typescript-errors
-			'no-undef': 'off'
-		}
-	},
-	{
-		files: ['**/*.svelte', '**/*.svelte.ts', '**/*.svelte.js'],
-		languageOptions: {
-			parserOptions: {
-				projectService: true,
-				extraFileExtensions: ['.svelte'],
-				parser: ts.parser,
-				svelteConfig
-			}
-		}
-	}
-);

package/index.html

@@ -1,23 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-
-<head>
-    <meta charset="UTF-8">
-    <meta name="viewport" content="width=device-width, initial-scale=1.0">
-    <title>Chatbot</title>
-    <!-- TODO: replace later with __WINEATER_WIDGET_DATA__ -->
-    <script>window.wineaterData = { CLIENT_TOKEN: 'emZGQHlITdVpwvK2hLXRopFS2emvorRsHadgaKbJThiVCPRWRzD0JyZrxrtgt10a', WIDGET_TYPE: 'store' };</script>
-    <!-- Production build checks -->
-    <!-- <script type="module" src="./dist/wineater-chatbot.mjs"></script> -->
-    <!-- Production CDN -->
-    <!-- <script type="module" src="https://unpkg.com/wineater-bot@beta/dist/wineater-chatbot.mjs"></script> -->
-
-    <!-- Local development -->
-    <script type="module" src="./src/index.js"></script>
-</head>
-
-<body style="margin: 0;">
-    <div id="wineater-widget-conteiner"></div>
-</body>
-
-</html>

package/playwright.config.ts

@@ -1,9 +0,0 @@
-import { defineConfig } from '@playwright/test';
-
-export default defineConfig({
-	webServer: {
-		command: 'npm run build && npm run preview',
-		port: 4173
-	},
-	testDir: 'e2e'
-});

package/pnpm-workspace.yaml

@@ -1,2 +0,0 @@
-onlyBuiltDependencies:
-  - esbuild