docs: add backend diff-vs-main + sales guide, document editor motion & HTML editor

- docs/BACKEND-DIFF-VS-MAIN.md: backend handoff summary framing BACKEND.md
- docs/SALES-GUIDE.md: non-technical demo/enablement guide
- docs/EDITOR.md: document interaction/motion pass and HTML editor status

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/BACKEND-DIFF-VS-MAIN.md

@@ -0,0 +1,50 @@
+# Backend Handoff — B2B branch vs `main`
+
+Audience: backend developer. This is the "what changed and what you need to build" summary for the `B2B` branch compared to `main`. It frames the detailed punch list in [`BACKEND.md`](BACKEND.md) — read that file for exact endpoint shapes and the frontend files that change once each endpoint exists.
+
+## TL;DR
+
+`B2B` is **~138 commits ahead of `main`**. Almost all of it is **frontend that has been built ahead of the backend**: a full admin backoffice, a project editor, a media manager, and a design-system component library. Every data-writing feature runs today against an **in-memory / `localStorage` mock gateway** that is already designed to be swapped for a real API via an injection token — the UI, facades, and pages do **not** change when you wire a real backend; you implement one gateway/provider class per domain and rebind its token.
+
+**You are not changing any existing contract.** Existing auth, payments, `GET /bootstrap`, and `GET /category` are frozen. Everything below is *new* backend surface the frontend is waiting on.
+
+## What `B2B` adds over `main` (feature-level)
+
+| Area | What's new on the frontend | Backend today | Priority |
+|---|---|---|---|
+| Design system | Reusable primitives (Button, Input, Card, Badge, Dialog, Table, Pagination, Skeleton, EmptyState, FormField) + editor primitives (Toggle, Select, ColorPicker, SectionCard, LocaleTabs, KeyValueEditor) | n/a (pure UI) | — |
+| Project Editor | Full tenant `BootstrapConfig` editor (11 sections, draft/publish, validation, per-locale content, HTML editor for static pages) | **mock**: draft/publish is `localStorage` only, no persistence | **High** |
+| Media manager | Upload / grid / delete + reusable media picker | **mock**: IndexedDB adapter, nothing server-side | High |
+| Categories admin | List + create/edit, hierarchy, drag reorder, soft delete/restore, draft/publish, SEO/translations | **mock**: in-memory, no write path | High |
+| Products admin | List + editor (variants, barcode, archive, related products, bulk actions) | **mock**: in-memory gateway | High |
+| Orders admin | List/detail, status changes, refund, cancel, notes, CSV, invoice | **mock**: 24 synthetic orders | High |
+| Transactions admin | List, retry, fraud flag, audit log, CSV | **mock**: derived from mock orders | Medium |
+| Users / roles admin | Users, roles, invitations, sessions, audit log | **mock**: synthetic; ties to auth gap below | High |
+| Dashboard metrics | Counts, status, health, activity feed | **partial**: counts composed client-side; activity is `localStorage` | Medium |
+| Monitoring | Health (real) + event/queue/webhook feeds | **mock** except Health | Medium |
+| Analytics | Revenue/orders/top-products (from mock orders) + visitors/funnels/heatmaps | **no data source** for traffic/funnels | Low |
+| SEO | Tenant-driven meta tags, `sitemap.xml` / `robots.txt` baseline | **static baseline** only, not per-tenant | Low |
+
+## The two things to do first
+
+1. **Admin authorization (security).** Admin and customer login currently share **one** Telegram QR session backend, so the server has no concept of "this is an admin session." Any Telegram user who completes the QR flow on the admin login screen gets an `adminSessionID`. **Server-side authorization keyed off the session id is required** — nothing on the frontend can substitute. See [`BACKEND.md`](BACKEND.md) §1.
+
+2. **Bootstrap draft / publish persistence.** The Project Editor edits the same `BootstrapConfig` the storefront consumes, but Save is `localStorage`-only and Publish is in-memory — no backend call. Needs `GET/PUT /builder/bootstrap/draft`, `POST /builder/bootstrap/publish`, optional `POST /builder/bootstrap/validate`, and **server-side re-validation** (the client validator is not a trust boundary). See [`BACKEND.md`](BACKEND.md) §2.
+
+## The pattern for every mocked domain
+
+For categories, products, orders, transactions, users, monitoring, dashboard metrics:
+
+1. A `*LocalGateway` (or `*Provider`) implements a gateway interface and is bound via an Angular injection token.
+2. You implement a `*ApiGateway` against the **same interface**, hitting real endpoints matching the domain model in `features/admin/<area>/models/*.model.ts`.
+3. You rebind the token in DI config. **Facades and page components do not change.**
+
+Model shapes to build against are named per area in [`BACKEND.md`](BACKEND.md) §5–§16.
+
+## Known production issue not fixable here
+
+Intermittent `502`/`504` on refresh / back-navigation in production originates from the **backend API's own reverse proxy** (`api.dexarmarket.ru:445`, `users.vitanova.network:456`) — the frontend calls those absolute URLs directly, bypassing this repo's nginx. Needs DevOps/backend investigation of upstream health and timeouts around session-check + bootstrap endpoints. See [`BACKEND.md`](BACKEND.md) "Known reliability issues".
+
+## Verifying the frontend locally without a backend
+
+`environment.ts` ships `useMockBootstrapOnLocal: true` and mock gateways are the default bindings, so `npm run dexar` runs the whole thing offline. Admin routes are reachable in dev via `?devBypassAdmin=true`. Flipping a domain to a real API is the gateway-swap above — no mock removal needed to start.

docs/EDITOR.md

@@ -69,6 +69,22 @@ All 11 section components (`sections/*.component.html`) share these 6 `shared/ui
 
 `section.shared.scss`'s `.editor-grid.*` classes are unchanged and still used inside `SectionCard` bodies; only the outer `.editor-section-card` shell and per-section `<h2>` were replaced (that rule has been removed from the shared stylesheet since it has no remaining consumers).
 
+## Interaction / motion pass (2026-07-16)
+
+Interaction feedback + motion applied consistently, all gated behind `prefers-reduced-motion`:
+
+- `section.shared.scss` `button`/`button.secondary` gained hover/active/`focus-visible`/`disabled` states (previously flat, no feedback across all 11 sections).
+- `project-editor-page.component.scss`: the active section fades/slides in (220ms) when the `@switch` swaps components; the "reset section" button got matching hover/focus states.
+- `project-editor-save-bar` buttons now use the shared `app-button` primitive (danger / secondary / primary variants) instead of unstyled native `<button>`s.
+
+## HTML editor (Static Pages)
+
+`MarketplaceHtmlEditorComponent` (`components/html-editor/marketplace-html-editor.component.ts`) is a `contenteditable` WYSIWYG used inside the Static Pages editor (`features/content-management/.../static-pages-editor.component.html`), one instance per locale, bound `[html]` / `(htmlChange)`.
+
+**Status: working.** Verified live 2026-07-16 — typing captured, toolbar commands functional (bold toggles, `insertUnorderedList` wraps `<ul><li>`, H2/H3/link/image/table), `htmlChange` emits on every edit, and a "Код" toggle swaps to raw-HTML editing.
+
+**Caveat:** implemented on the deprecated `document.execCommand` API. It works in all current browsers today but is a legacy web API with no modern drop-in replacement; if a future browser drops it, this component needs a rewrite (e.g. a maintained rich-text library). By design it emits **raw, unsanitized** HTML — sanitization is a storefront-render concern, not an authoring one (see `docs/BACKEND.md` item 4 on server-side content moderation on publish).
+
 ## Field-description / dropdown UX (Sprint 19+)
 
 Every field across the 10 editor section templates now carries a one-line, i18n'd description under its label explaining what it does in plain language (all new copy routed through `TranslateService`/`TranslatePipe`, added to `Translations` + `en.ts`/`ru.ts`/`hy.ts` following the existing `builder.*` key pattern — see `src/app/i18n/translations.ts`).

docs/SALES-GUIDE.md

@@ -0,0 +1,79 @@
+# Sales Guide — How to Use & Demo the Marketplace Platform
+
+Audience: sales team. Plain-language guide to what the product does and how to show it. No code. When something isn't live yet, it's marked **Coming soon** so you never over-promise in a demo.
+
+## What we're selling in one sentence
+
+A **multi-tenant marketplace platform**: one codebase runs many branded marketplaces, and each customer gets their own storefront + a self-service admin panel to run it — no developer needed for day-to-day changes.
+
+## The two halves of the product
+
+1. **The storefront** — what shoppers see: homepage, catalog, product pages, search, cart, wishlist, compare, multi-language, multi-currency.
+2. **The admin / editor** — what the marketplace owner uses to run and customize it, without touching code.
+
+## The headline demo: "change your whole store without a developer"
+
+This is the strongest pitch. Open the **Project Editor** and show that a marketplace owner can restyle and reconfigure the entire storefront themselves. It has 11 tabs:
+
+| Tab | What you show the prospect |
+|---|---|
+| General | Set the marketplace name, domain, description, and languages |
+| Branding | Upload logo, small logo, favicon |
+| Theme | Pick brand colors with a color picker, light/dark mode, choose a site layout |
+| Header | Toggle which features appear in the top bar (search, cart, wishlist, languages…) |
+| Footer | Company info, address, contacts, payment icons, social links |
+| Homepage | Drag-and-drop the order of homepage sections, choose layouts |
+| Widgets | Configure homepage blocks (hero banner, category grid, product rows) |
+| Marketplace Features | Turn features on/off (reviews, recommendations, recently-viewed, search history…) |
+| Languages | Add or remove a language for the whole store |
+| Navigation | Edit the menu links, per language |
+| Static Pages | Write pages like "About Us" with a rich text editor |
+
+**Demo flow that lands well:**
+1. Change the brand color in **Theme** → show the store instantly reflecting it in **Preview**.
+2. Reorder homepage sections in **Homepage** by dragging.
+3. Edit an "About Us" page in **Static Pages** using the text editor (bold, headings, lists, links, images, tables).
+4. Point out the **Save / Publish** bar: work is saved as a **draft** first, and only goes live when they hit **Publish** — safe to experiment.
+
+> The rich-text editor for static pages **works today**: type text, make it bold, add headings, bullet lists, links, images, and tables, or switch to a "Code" view for raw HTML.
+
+## The admin backoffice (running the business)
+
+Beyond styling, there's a full back-office. In demos, show the **layout and workflow** — the screens are built and polished. Be aware most of these currently run on **sample data** for demo purposes; real live data connects during onboarding (that's a backend integration step, not missing product).
+
+| Area | What it does | Demo note |
+|---|---|---|
+| Dashboard | At-a-glance status: store status, theme, languages, counts, health, recent activity | Cards are live for config; sales counts show "pending backend" until integrated |
+| Products | Add/edit products: price, variants, images, categories, badges, bulk actions | **Sample data** in demo |
+| Categories | Category tree with drag-reorder, SEO, translations, soft-delete/restore | **Sample data** in demo |
+| Orders | Order list/detail, status changes, refunds, cancel, notes, CSV export, invoices | **Sample data** in demo |
+| Transactions | Payment records, retry failed, fraud flags, audit log, CSV | **Sample data** in demo |
+| Users & Roles | Team members, roles/permissions, invitations, session/audit history | **Sample data** in demo |
+| Monitoring | System health + security/event feeds, queues, webhooks | Health is live; feeds are sample |
+| Analytics | Revenue, orders, top products, plus visitors/funnels | Revenue/orders demo from sample; traffic analytics **Coming soon** |
+
+## What's polished and worth showing off
+
+A full UX pass was done across storefront, dashboard, admin, and editor:
+- Clean, consistent buttons and controls everywhere (one design system).
+- Smooth, tasteful motion — cards and sections animate in, buttons respond to hover/press — and it automatically respects "reduce motion" accessibility settings.
+- Works responsively down to phone size.
+
+## Honest "coming soon" list (don't promise these as live)
+
+- **Live business data** (real products/orders/customers) — connects per-customer during onboarding; demos use sample data.
+- **Saving edits to the cloud** — today the editor saves drafts in the browser; server-side save/publish is an onboarding integration.
+- **Traffic analytics** (visitors, funnels, heatmaps) — the screens exist; the data pipeline is not built yet.
+- **Per-customer sitemaps / advanced SEO automation** — baseline SEO is in; full automation is roadmap.
+
+## Quick answers to likely prospect questions
+
+- **"Do we need a developer to change our store?"** No — the Project Editor covers branding, colors, layout, pages, menus, languages, and feature toggles self-service.
+- **"Can we have our own domain and branding?"** Yes — each marketplace is its own tenant with its own domain, logo, colors, and content.
+- **"Multiple languages?"** Yes — add/remove languages in the editor; content is editable per language.
+- **"Is it safe to experiment?"** Yes — changes are drafts until Published.
+- **"Is it mobile-friendly?"** Yes — responsive across phone/tablet/desktop.
+
+## One rule for demos
+
+If a screen shows sample/placeholder data or a "pending backend" label, say **"this connects to your live data during onboarding"** — it's a real, built screen waiting on integration, not a gap in the product.