Release notes

• Dashboard doorbell and kiosk menu poll on the POS change marks (2026-10-13, plan step 3 + item 1e). The dashboard's inbox/stream route is gone: it held a server-sent event stream open for the whole 300 s Cloud Run request timeout and probed the backend every 2 s from inside it, which on request-based billing charged the ui instance for every second a dashboard tab was open and made up ~65 % of backend requests. useTenantPushSignal now asks the new GET /api/dashboard/inbox/changes once every 30 s while the tab is visible (nothing while hidden; one shared poller per tenant), and that route answers from the backend's per-tenant change marks (GET /pos/admin/changes/:tenantId, one ~100-byte read via lib/pos/change-marks.ts) in the fixed order [tickets, kitchen, bookings, settings, catalog], falling back to the two whole-document updatedAt probes only while the marks route is not deployed or unreachable. The Express Kiosk's menu version (GET /api/public/kiosk/menu?v=) now carries the catalog and settings marks it was built from plus a validity instant (the next canteen daypart boundary, else 10 min) and the content hash (lib/kiosk/menu-version.ts), so an unchanged menu is decided from one marks read before the tenant blob is loaded or hashed; the hash stays as the second gate, so a mark that moved for something the kiosk does not show still answers unchanged at the old price, and with no marks the version is the bare content hash as before. Both kiosk clients already treat the version as opaque, so neither changed. The heartbeat (lastSeenAt in the tenant blob) is still written on every poll, so the cheap path's full saving waits on moving that stamp out of the blob.

• Sales receipt: what is left on the gift card (2026-10-11, till 1.0.5846). A guest who paid with a Presentkort had to ask for a separate balance check. The paper the server prints for the sale now says it under the payment — "Kvar på presentkort ****WXYZ 320,00" — masked code only. The figure is stored on the sale's tender row when the card is debited, so a copy or an e-mailed receipt days later states what was true when the receipt was made, never today's balance. A sale without a gift card prints byte-identical paper. Server-printed paper only: the on-screen receipt text comes from the kernel renderer and is unchanged.
• X/Z report: Dricks, and Växelkassa (2026-10-11, till 1.0.5846). Two things the server knew and the tills never printed. Dricks (ej försäljning) — tips per payment means, outside the sales: a card terminal settles sale + tip, so its day total could not be reconciled against a report that showed only the sale. Växelkassa — the float the shift opened with, at the top of the drawer section: a minimum field of both dagrapporter (SKVFS 2014:9 7 kap. 2 § h, 3 § i) that was on no line. New report fields openingFloatMinor; tipTotals was already sent. Both tills, four languages.
• Presentkort: paper for the buyer, and for a balance (2026-10-11, till 1.0.5845). Owner: "upon buy will there be a receipt of purchase? and what if someone want to have a receipt for current balance". There was no paper anywhere in the gift flow. Two slips now print on the receipt printer, each from a BUTTON and never on their own (his ruling): Skriv ut köpbevis on the sale's confirmation and on the card's sheet in Historik — the value, how it was paid, when and on which till; and Skriv ut saldo under a balance that was just checked — what is left, the original value, validity. Neither is a kassakvitto and the paper says so: EJ KVITTO leads it at twice the size of every amount (the pro-forma rule in SKVFS 2014:9), with no receipt number, VAT block, organisation number or control code. The card's code is never on receipt paper — only ********WXYZ — and the last door before the printer refuses anything showing more than four characters: the physical card with its code is a separate card-printer device, and everything else is the gift e-mail or the website's share page (owner, same day). New: POST /pos/giftcards/cards/:cardId/print-slip, POST /pos/giftcards/balance/print (the code rides the body, never the URL), /api/internal/pos/print-gift-slip, lib/devices/gift-slip-print.ts. Four languages on the till and on the paper.
• Order buzzers — the puck's number on the order (2026-10-10, tills 1.0.5841). Owner: "if a customer

want to use the order buzzer which are the external devices, there should be a way to add buzzer number to order so kitchen or counter can press buzzer to inform customer when the order is ready." The till CARRIES the number; it does not talk to a buzzer (a paired or integrated buzzer is the stated next step, which is why the number is its own field and not a note). Kassa: a Buzzer door on the header row, first among the mode's controls so Välj bord keeps its place, in Servering and Avhämtning; it opens a number pad (one to four digits, Spara / Avbryt / Ta bort) and then states the number ("Buzzer 12"). A counter basket carries it on its first write (send to kitchen, or the paid sale); a bill the server already holds is written through POST /pos/tickets/:id/buzzer, which also re-stamps the kitchen cards still on the rail. Where it is read: the KDS card, the Beställningar row, the kitchen bong (BUZZER 12 under the order number) and the guest receipt (Buzzer 12 under Ordernr) — paper without a puck is byte-identical. Two switches: the venue's own under Inställningar → Funktioner (off until switched on, settings.buzzer.enabled), and Super admin → POS Order Buzzers per tenant (platform_data.pos_buzzer_policy, allowed unless switched off); /pos/registers/me carries the resolved answer. Web till, Windows and Android alike, in en/sv/no/da. Rules: backend/src/modules/pos/sales/buzzer.ts, pos/web/src/screens/buzzer-rules.ts, BuzzerRules.kt.

• Order buzzers, two findings from the owner's tablet the same evening (2026-10-10, tills 1.0.5842).

A freshly paired till drew no Buzzer button until it was restarted or somebody opened Inställningar → Funktioner: /pos/registers/pair did not carry the buzzer block that /pos/registers/me did, and a till builds its first session from the pairing answer. It carries it now (buzzer-on-register-wire.spec.ts). On a tablet the button did not fit the header's one row — it pushed Ny beställning onto a second row and cost a row of menu. Below 900 dp of header the door is now compact: a tap-sized bell with the number as a badge on its corner, one width whatever is keyed (BuzzerRules.compactDoor, the container query on .pos-kassahead in buzzer.css), and on the native tills it stands in the row's spacer slot instead of taking a gap of its own. Wide tills keep the worded "Buzzer 12". The compact door is confirmed by the owner on his tablet and locked in docs/design-locks/kassa-buzzer-door.md.

• Guest page — a stand on the table opens the menu, rewards, Wi-Fi and feedback (2026-10-10). A new

sellable module, guest-hub (an add-on in no base plan, unpriced until a super admin prices it — the store shows "Kontakta oss"; Enterprise and Pay As You Go include it by the standing "everything" rule). /tap/<tenant> is the venue's link and /tap/<tenant>/<code> one stand; both open ONE page in the guest's language (en/sv/no/da — the switcher, then the phone, then the venue) with a tile per part that WORKS: the menu (a stand's table number rides along), the rewards card, the guest Wi-Fi (network, password with one-tap copy, and a WIFI: QR another phone can join from) and a private star rating. A stand that is no longer listed still opens the page; a switched-off page shows the venue's name and one sentence. /dashboard/guest-hub (a tile on the Marketing hub) is where the owner sets it up: the four parts with a "guests see this" answer from the same rule the guest page uses, the Wi-Fi details (refused when they could not work on a phone), the Google review link (must be Google's), and the stands — each with its own link, QR downloads, and "Write to an NFC tag" where the browser can (Chrome on Android). Rules are pure and tested in lib/guest-hub/*; scripts/guest-hub-shots.mjs is the browser proof (12 checks).

• The guest rewards card page speaks Swedish, Norwegian and Danish (/tenant/<id>/loyalty,

lib/loyalty/guest-words.ts) — it was English only, and is now one tap from the guest page.

• Guest page, round two (2026-10-10): sold per card, follow buttons, and "Ask about a dish".

Price: owner — "29 SEK per NFC or QR card per month but adjustable price in super admin". A guest card is a licence seat (seat-guest-card, counted on the venue's stand list), priced ONLY in Super admin → Licensing (no number in code); buying one on /dashboard/licences opens the module for a plan without it. Only ADDING a card past the licence is ever refused (409 GUEST_CARDS_FULL, and only when platform enforcement is on) — a card on a table keeps working, and renaming, re-pointing or removing one always saves. The setup page shows cards in use, the licence, and the price per card. Follow buttons: Instagram, YouTube and TikTok, right on the guest page; the links are the venue's own settings.socials, editable on the setup page (https only). Ask about a dish: a guest picks a dish and reads its ingredients, allergens ("contains" / "may contain") and dietary labels, and can check one allergen. NOT an AI: every verdict is the regulated resolver's (lib/ita/allergen-qa.ts), verbatim, and a dish with nothing recorded says "ask the staff", never "free from" (lib/guest-hub/ask.ts; POST /api/public/[tenantId]/hub/ask, read-only, rate-limited). Nutrition is not answered — a menu item carries no nutrition figures.

• **Guest page, round three (2026-10-10): typed questions with an AI layer, and nutrition, in "Ask about

a dish".* Typed questions: one field — typing filters the dish list, "Ask" sends the words. Plain word matching (`lib/guest-hub/ask-question.ts`) finds the dish and the allergen first, FREE, in any of the four languages. Only when no dish is found, and only when the owner has switched it on, an AI READS the question and picks the dish (`ask-ai.ts`): the smallest model, dish names only in the prompt, a reply of a few numbers, the same question answered from memory for 30 minutes, a daily ceiling per venue. It is paid from the restaurant's own AI credit — the wallet every tenant already has, topped up on `/dashboard/ai-spend` — through the same gate and debit as every AI feature, as "Guest page · Ask about a dish". No credit, or no platform key: the guest still gets the list and sees no error. The AI never answers. What it returns is accepted only as dish numbers and registry ids; the answer is composed from the venue's records and the regulated allergen resolver, and there is no "dishes free from X" list — only dishes that DECLARE an allergen or carry a label. Nutrition:* a dish's nutrition per serving, worked out from its recipe and the ingredient catalogue (USDA FoodData Central, Livsmedelsverket, Open Food Facts) by the rollup the marketplace already uses (ask-nutrition.ts): the eight lines of a nutrition declaration, how many of the recipe's ingredients the figures cover, the sources named, marked as an estimate. Nothing recorded = "no nutrition figures recorded". The setup page shows the AI switch, the credit left, the typical cost of one AI-read question (from the platform's own price list and markup) and a top-up link.

• **"Ask about a dish": misspelled dish names are matched for free, and the nutrition panel has a salt

line (2026-10-10).** Owner: "is there any free ai service which can be used?" — the cheapest AI is the one not called. matchQuestion now also finds the ONE dish a question nearly names: a slip of the keyboard (edit distance: none on short words, one, two on long ones) or a Scandinavian noun ending ("har margaritan gluten" → Margherita). Two dishes equally near → nothing is picked and the guest gets the list. So the AI layer is left with what words cannot do (another language, a description). Nutrition: the American database states sodium, the Swedish one salt; where only sodium is known the salt line is sodium × 2.5, the equivalent a label defines. Seen on the developer stack on a dish with a recipe linked to three USDA rows (928 kcal a serving, 3 of 3 ingredients, source named).

• X/Z report: Kassahändelser lists only what was keyed by hand (2026-10-11, till 1.0.5846). The block listed every row of the cash ledger, and the tills had names for three kinds — so a shift with a cash sale printed sale_cash ×1 125,00, change_given, refund_cash as raw keys, restating the drawer row by row on an X. It is now an allowlist: Insättning, Uttag, Säkerhetstömning and cash tips (newly named "Dricks (kontant)"). Nothing left the ledger, the expected cash or the over/short; cash sales are still under Betalsätt and returns under Returer. NOTE: this reverses an earlier intent that change given should stay visible on the report — it is in the ledger, and on no report line.
• Presentkort: the design row follows the finger and glides (2026-10-11, till 1.0.5845). Owner: "right now only one at a time it rotates which is good but give it more smooth effect … a continue effect, fast swipe and slow swipe". A swipe used to be a vote — past 48 px it stepped exactly one card, however fast or far, and nothing moved until the finger lifted. The row is now a position: it follows the pointer, keeps going at the speed it was released with and slows onto a card (a slow swipe lands on the nearest, a fast one travels several), and stretches a little past either end. At rest every card is exactly where the approved layout put it; the no-jump contract is unchanged and still pinned. One rule, twinned: GiftCarouselMotion.kt ↔ gift-carousel-motion.ts. On the web till the slots no longer carry a CSS transition — the component paints them per frame, and a transition would smear the row behind the pointer.
• X/Z report: a card used as payment is now "Presentkort (inlöst)" (2026-10-11, till 1.0.5845) — so it cannot be read as cards sold, which have their own block (see Fixed).
• Scan-to-rate follows Google's review rules (owner ruling 2026-10-10). The Google review link is

offered to EVERY guest who rates, on the same terms, whatever they answered. It used to go only to four and five stars while lower ratings were kept private — "selectively solicit[ing] positive reviews", which Google's Maps contribution policy lists under Rating Manipulation. lib/reputation/route-rater.ts carries the rule and its tests; an unhappy guest is still offered the private follow-up as well. A venue with a live guest page gets this follow-up without the scan_route platform flag.

• The cookie banner no longer covers /tap/… (essential-only surface, like /t/ and /scan/).
• Super-admin → Help & Guides — a help centre of the admin's own, opened with the GreenGate guide set (2026-10-07).

/admin/dashboard/help (sidebar: new "Help" group, "Help & Guides"): a search box, category chips and a card per guide; /admin/dashboard/help/[slug] renders the article with the FAQ, a "Recommended next" and the related guides, and a button to Control Units. Both pages are SERVER components behind the admin layout's super-admin redirect, resolving the locale like the Control Units page and the admin login (platform_lang cookie / ?lang= → en/sv). The articles are a module of their own, lib/docs/admin-articles.ts (ADMIN_DOC_CATEGORIES, getAdminArticleBySlug, searchAdminArticles…), NEVER mixed into the owner DOC_ARTICLES (bundled into every owner page, ratcheted by coverage tests) — only the DocArticle types are shared. The owner article page's section renderer moved VERBATIM to components/docs/ArticleSections.tsx with the class vocabulary as a parameter: the owner page passes nothing and renders exactly what it did; the admin pages pass gray-scale and accent classes the admin theme engine covers (vocabulary.test.ts passes). Eight guides, each in English and Swedish, category "Swedish control system (GreenGate)", written for the super-admin who holds the GreenGate contract: overview (the three gates, test vs production, what the till shows, no fallback), onboarding a customer step by step with a checklist, using the Control Units page (five sections, what each button sends and to whom, why the confirmations exist), adding or replacing a till, the Skatteverket hand-off and the manufacturing number, the reconciliation queue, the test tenant (the four pnpm greengate:* commands, what the simulator proves), and troubleshooting refusals (the five codes, cause, fix, log line). Every fact checked against the runbooks and the code; what GreenGate has not answered (the manufacturing number's scope, whether a POS-ID must be registered in advance, the status vocabulary) is written as "not yet confirmed by GreenGate". No credential, org number, serial number or customer name in any guide — pinned by test. The Control Units header gained a "Guide" link to the overview. Tests: lib/docs/admin-articles.test.ts (unique slugs, links resolve, sv shape = en shape, no placeholder or secret-shaped text, only the four pnpm commands and the log command as code, the unconfirmed claims say so), components/docs/article-sections.test.ts (every section kind renders; the default vocabulary is the owner page's; a passed one replaces it everywhere), app/admin/dashboard/help/admin-help-pages.test.ts (server components behind the guard like Control Units; the index and every article render in en and sv with no tenant token).

• Super-admin → Control Units (Kontrollenheter) — the GreenGate reseller back office, one page per tenant (2026-10-07).

/admin/dashboard/control-units (sidebar: Global Localization, beside POS Operating Mode): a tenant picker (tenants with Swedish registers, or any id typed for a first-time setup), a status strip (health badge, an unmissable TEST/PRODUCTION chip, "Check connection" that sends ONE RequestStatus to GreenGate and only when pressed — nothing is sent on page load — probing with a chosen register's kassabeteckning and showing the control system's serial number), the GreenGate account card (credential-free view; enter/edit form with write-only username + password, Digest default, test/production warning; a status switch with a confirm that says every Swedish sale is refused while disabled), the registers table (editable POS-ID cell on Swedish selling registers only, 1–16 Latin-1 chars, unique within the tenant checked against the other rows; a CHANGE or CLEAR is confirmed by retyping the value and names Skatteverket — the backend exposes nothing that says a kassabeteckning already has receipts, so every change is treated as one that matters), the Skatteverket hand-off block (org no, per register: name, kassabeteckning, serial number from the probe of THAT kassabeteckning or "run Check connection first"; one Copy button, plain text), and the reconciliation queue (oldest first, evidence on a deliberate second click, Resolve with the finding/evidence/note of the DTO and a confirm quoting the rule: never a control code, never a revived sale). BFF under /api/admin/control-units/*, super-admin guarded exactly like Markets; setBy and checkedBy are stamped from the session. Words in English and Swedish (page-local namespace, locale resolved like the admin login). Backend: one read-only route for the tenant picker (GET /pos/admin/registers/tenants?country=) and one status-only write (PATCH /pos/admin/fiscal/greengate/account/status), both InternalGuard with specs.

• Printed till receipt: it said "Kort" for every sale (2026-10-11, server; released beside till 1.0.5846). The paper the server queues for a till sale never received the means of payment and defaulted to card, so a cash sale's kassakvitto read "Betalning: Kort · betald". It is now read from the sale's stored tender rows: one means prints the old line with the right word; a split, or a gift card that did not cover the bill, prints "Betalning · betald" and one row per means with its amount. A booking's prepaid deposit prints as "Extern betalning", not Kort. A paper whose means is not known prints no means at all. Card-only paper is byte-identical. New payload field payments[].
• Table and parked bills got no original receipt (2026-10-11, server). Only a counter sale queued paper; a bill closed from a table or a parked bill did not, so on the native tills the guest's only paper was the print button's KOPIA, with a copy journalled for what was really the first print. Closing a bill now queues its original, as a counter sale always has — receipt only, never a second kitchen bong (/api/internal/pos/print-receipt). Refunds likewise: the refund's original is queued when it is made. The print button afterwards prints a copy, which is now what it is.
• Refund paper claimed "Kort · betald" (2026-10-11, server). It states how the money went back — "Återbetalt: Kontant", or a row per means.
• Dricks was never on the printed receipt (2026-10-11, server). The tip travelled to the printer and was not read. A tipped sale's paper now has its own "Dricks" row under the total — outside the total and the VAT table — and the payment row shows what the card was actually charged. An untipped sale's paper is byte-identical.
• Presentkort: no payment into a closed shift (2026-10-11, till 1.0.5846). A card payment charges the terminal first and issues the gift card after; a shift closed from another till mid-session meant a charged card and a refused gift card. Till betalning now asks for the open shift before any payment starts and says "Öppna ett pass innan du säljer presentkort." A held attempt being resumed is not asked, and if the question cannot be asked the server remains the authority. Both tills.
• X/Z report: gift cards sold were on no report (2026-10-11, till 1.0.5845). The owner sold two Presentkort and could not find them. A card paid in cash hid among the pay-ins as an unnamed "Insättning"; one paid by card or Swish was on no report at all, so a card terminal's day total could not be reconciled against the Z. Skatteverket's line is that a sold gift card shows on the dagrapport as its own item, outside the day's sales. The report now carries Sålda presentkort (ej försäljning) — how many, paid how, in total — kept out of the sales figure, the VAT table, the tender totals and everything the Z seal hashes, so no sealed figure moved; the gift cash stays in the drawer count and is no longer also printed as a pay-in. Every card sale now needs an open shift (it was only required for cash), so none can land on no report. NOT settled by anything we could read, and for an accountant or Skatteverket: whether the sale must also be a signed kassakvitto, and whether a venue with a single VAT rate is issuing single-purpose vouchers (VAT due at sale).
• Presentkort on the tablet: `Till betalning` jumped under the finger (2026-10-11, till 1.0.5845). With no amount chosen, pressing it inserted a red card above the button; the rail had less slack than that card is tall, so the button and Rensa moved down and the note left the card. The reason now takes the note's own slot under the buttons, which is the same height whichever sentence it holds.
• Web till: the Presentkort screen was Swedish only (2026-10-11). About twenty sentences — form errors, the card-declined and terminal-timeout texts, statuses, the gift-mail lines, the carousel's labels — were hard-coded. They come from the four-language table now, in the native tills' words.
• A till added on the device page showed its OWN name where the venue's belongs (2026-10-11). The owner's tablet drew "Kassa 2" on the face of a Presentkort. Only the signup flow ever stamped venueName on a register; one created on the dashboard's device page has none, and a till with nothing better printed its own name. /pos/registers/pair and /pos/registers/me now answer an absent or blank venue name with the name the venue typed in its own settings — the one at the top of its receipts (merchant.name); a stamped name is kept, and with neither known the field stays absent. Server-side only: both tills already read the field, and a paired till picks it up at its next start. This closes the "still open" note in the 1.0.5843 card-face entry below.
• Presentkort: a gift card sold at the till was in no history at all (2026-10-11, till 1.0.5843). Owner: "i sold a presentkort but i dont see it in any history". A card sale is a voucher issue — a card, a ledger row and a drawer pay-in, never a ticket — and the till's Historik read tickets and online orders only, so the money was in the drawer and on the Z-report and the sale was nowhere a cashier could look it up. GET /pos/kitchen/orders/history now merges a THIRD journal: cards sold at a till (source: 'giftcard'), under the same window, cap and search as the other two. The row is called by the MASKED code (********WXYZ, never the code), carries the face value, how it was paid, which register sold it and the recipient's name; it answers the Slutförd / Betald / Direkt chips and no others. Search finds a card by name, by the whole code, or by any part of the four characters the row shows — and by nothing longer, so the box can never be used to walk a code out. Only till sales: a dashboard or web issue is not a counter sale. New index tenant_createdAt on pos_giftcards. On the tills (Android, Windows, web; sv/en/no/da) the row wears a PRESENTKORT badge, its sheet is titled "Presentkort …" rather than "Order …", and it offers no reprint / e-mail receipt (there is no ticket behind it). Works on an older till too — the row simply has no badge there.
• Historik: "Betalt med cash" (2026-10-11, till 1.0.5843). The order sheet printed the tender's wire word. It now says Kontant / Kort / Swish / Presentkort in the till's language, on every row.
• Presentkort: the card face on the native tills printed the TILL's name (2026-10-11, till 1.0.5843). "Kassa 1" on a card handed to a guest. Android and Windows now use the venue's name first, exactly as the web till already did. Still open: a register created on the dashboard's device page carries no venue name, so its card face falls back to the till's name until the server supplies one.
• Dricks: a freshly paired till did not ask for a tip until it was restarted (2026-10-10). The same

gap the buzzer had, present since tips shipped on 2026-09-06: /pos/registers/me carried the tip block and /pos/registers/pair did not, and a till builds its first session from the pairing answer. A venue that takes tips went unasked for every guest served before the first restart of a new till. The pairing answer carries the block now (tip-on-register-wire.spec.ts). Server-side only; nothing about whether or how a tip is asked for changed — an unreadable policy still answers "do not ask".

• Payment page (`/register/payment`): it says what THIS plan contains, in the owner's language — and an ended trial can be paid for (2026-10-07).

Owner, on an expired Inventory Advanced trial: "on screen the renewal showing wrong information about package". The page printed four website bullets ("Digital menu on your own website · Website builder + QR menus · Table reservations · Food Bazar listing · Experience Studio") under every plan's name, and "Activate your account — One last step" in English to an owner whose trial had ended. The list is now derived from the plan itself (lib/billing/plan-contents.ts: included features → the side menu's own rows, trade-filtered, translated with the menu's table), the heading follows the account's standing (signup · trial · ended trial · overdue · lapsed · paid), and the wording lives in the marketing dictionary's auth.payment namespace (en/sv/no/da); the page speaks the owner's dashboard language. The price was already right (flat plans are billed yearly). Also fixed, found on the way: POST /api/billing/signup-payment answered "already active" for a TRIALING subscription and took no money — for a lapsed trial the dashboard sent the owner straight back, a closed loop, so the account could never be paid for. Only a paid period is "already active" now (lib/billing/signup-payment-step.ts). With a trial payable: a Stripe payment returns to the payment page and is confirmed there before the dashboard opens (no second "Pay" on a late webhook, no endless spinner); a production server without a Stripe key refuses to simulate a trial into a paid year; the Stripe webhook activates a plan only when the money has arrived; an older paid Checkout session is not applied twice; and "activate the website package" (domain settings) leads to the payment page only when the plan has the website builder. Operations note: production needs STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET before a customer's trial ends — without the key the page now says payments are not set up instead of activating.

• Inventory & Suppliers: "back" links and words that pointed at the wrong page (2026-10-04).

Waste, Stocktake, Storage places, Labels and Equipment each carried a back link to Receiving, left over from when they were buttons on that page (they became hub tiles on 2026-09-27). Receiving needs Purchasing as well as Inventory Management, so on a stock-only plan the link led to a page the reader cannot open. They now go back to the Inventory & Suppliers hub, named as the sidebar and the breadcrumb name it in all 20 languages (components/dashboard/inventory/InventoryHubLink.tsx). The Receiving upgrade prompt said "Part of Inventory Management" / "Included in the Inventory Management add-on", while every Receiving route requires Purchasing too. The text now says it needs both (en, sv, da, no). The gate is unchanged. Three sentences that send the reader to another page now use that page's own name in sv, da and no: the Pick out hint (Flytt mellan platser, was "platsförflyttningar"), the Stocktake hint (Lagerplatser, was "Förvaringsplatser") and the grocery note on Sites (Lagerflytt, was "Överföringar").

• The super-admin Customer page stopped failing on half of its loads (2026-09-19).

GET /api/admin/tenants/[tenantId] answered an EMPTY 500 — zero-length body, no content-type — on roughly half of all requests, for every tenant, and faster than it answered successfully. Cause: the page's audit trail asks for 24 months, and readAuditSegments turned that reach into ONE Promise.all — 24 simultaneous reads of master-audit-logs:YYYY-MM at the store. The backend's global throttler is ThrottlerModule.forRoot([{ ttl: 1, limit: 20 }]) and @nestjs/throttler v6 counts ttl in MILLISECONDS, so the budget is 20 per tracker per millisecond — and every internal UI→backend read shares one tracker (the ui container's address). Reads 21–24 came back 429, the adapter threw by contract, nothing caught it, and Next answered with no body. Whether 24 sockets landed inside the same millisecond was a coin flip, which is exactly the ~50/50 pattern that was observed. Three things changed: segment reads now go out in batches of AUDIT_SEGMENT_READ_CONCURRENCY (6, the reach every other audit reader already uses) so a long window costs round trips and never a wider burst; a 429 — the one status that means "ask again" — is retried twice, and StoreUnavailableError now carries status so that is readable without parsing prose; and the Customer page DEGRADES instead of dying, serving every other card with an auditError sentence on the trail card rather than an empty list that would falsely claim the customer has no history. This page is the only door to a module trial, so losing it means no module can be opened at all. The throttler's ttl: 1 was deliberately left alone: "correcting" it to 1000 would turn the budget into 20 requests per SECOND for the whole ui container.

• An admin route that throws now says so (2026-09-19). New lib/api/route-error.ts

(failLoudly): logs the stack with context server-side and answers the standard { error, code: 'route_error' } envelope with a real message. The Customer page's GET is wrapped in it, and the page itself now reads a failed response instead of parsing it as a success — the empty 500 used to make res.json() throw in the browser, leaving the spinner turning forever with no word of why.

• Help guides for Inventory & Suppliers, in English and Swedish (2026-10-04). Five linked guides

in a new help-centre category "Inventory & Suppliers" / "Lager & leverantörer": getting started, ordering and receiving, pick-out / prep production / waste, stocktake and storage places, and several sites with transfers (lib/docs/inventory-articles.ts). Help guides were English only. A guide can now carry translations (lib/docs/articles.ts: localizeArticle, localizeCategory, and searchArticles(query, lang)), which the guides list, the article page and the header's help search use. A reader in a language without a translation gets the English guide, as before. The 32 older guides are untouched and still English. inventory-articles.test.ts checks that every name a guide puts in quotes is a label in the dashboard dictionaries for that language, so a renamed button fails the suite until the guide follows. No new dictionary keys.

• A breadcrumb on the Lager & leverantörer pages (2026-10-04). Product Owner's request: inventory had

no breadcrumb and the only way back to the hub was the sidebar. Every page opened from the Inventory & Suppliers hub now shows Hub › Page above it (plus a last crumb for a tab or a supplier), and on a phone one 44 px link back to the parent. Built once: the trail is derived from the nav catalog (lib/dashboard/breadcrumb-trail.ts), rendered by the dashboard layout (components/dashboard/DashboardBreadcrumb.tsx), and hidden wherever the plan or the trade hides the hub or the page. Another area adopts it by adding its hub href to BREADCRUMB_HUBS; a page names a view the URL does not show with useBreadcrumbSubView(label, onBack?). No new strings, no route changes.

• Change or remove lines on a live online order, paid or not (2026-09-07). Owner: *"someone calls and

says he ordered a pizza but wants a burger instead, or he ordered two pizzas and one burger and paid, but wanted just one pizza."* The till's order door has an edit_lines verb (lib/orders/order-line-edit): remove and add in one call, priced from the venue's menu; an unpaid order's total moves; a paid order that shrinks is refunded the difference (drawer cash or a credit-note gift card for a counter charge, the payments layer for an online hold, stamped "manual" without one); a paid order that grows owes a balanceDue the counter's paid press collects. A started line is refused, or allowed with a manager's PIN under the new Setup Center › Ordering & Delivery choice. The kitchen card shows the struck line and the new one. Every till shows "Ändra artiklar" beside "Lägg till artiklar".

• "Clear log" on Recent print jobs (2026-09-06). Owner: "can you empty Recent print jobs."

DELETE /api/tenant/[id]/hardware/jobs (settings permission) empties the diagnostic job log — the receipts live on the sales, so nothing bookkeeping-shaped goes — and the Printers panel shows a Clear log button beside the heading, with a confirm.

• All scheduled jobs are off on every platform (2026-10-05). Product Owner: keep every cron off until

the strategy for running them is reworked. vercel.json now declares no crons (it listed all 73, which a Vercel deployment would have kept firing), and cron-registry.test.ts fails if one is added there. Cloud Scheduler creates only the jobs named in enabled_cron_jobs (terraform/envs/*.tfvars), which is empty. The routes and the PLATFORM_CRON_JOBS registry are unchanged.

• restora360.com redesign, round 2 — /products, /demo, barber + wellness (2026-09-09). Owner, on

round 1: "looks good - keep going." /products is rebuilt from the prototype's products.html: seven core product cards (POS, website, appointments, inventory, staff, digital signage, reports & insights), the four restaurant-specific modules (online ordering, table reservations, kitchen display, express checkout) and the "how should I choose" guide; the Produkter menu and the footer now deep-link /products#<id>, and the Phase-75 /products → /services redirect is gone (/products/pos stays). /demo stops 308-ing to /try and becomes the seven-step "Boka en demo" flow — business, type, stage, needs, company, contact, time — wired to a real backend where the prototype ended in localStorage: POST /api/public/demo-request validates with DemoRequestSchema, stores the request as codes in MasterDB.demoRequests[] (a Norwegian request reads like a Swedish one), mails the team best-effort, is rate-limited and refuses disposable addresses; the form renders every refusal from its own dict. /industries/barber and /industries/wellness join the industry template as beauty sub-trades with a four-level breadcrumb (home › industries › beauty › the sub-trade) and an "also built for" cross-link. All copy ships in en/sv/no/da under site-dict-parity.test.ts; the sitemap and /llms.txt list the new pages.

• restora360.com redesign — header, landing page, industry pages (2026-09-08). Owner, with a

screenshot and an HTML prototype: "navbar is too big … it can be a decent size" and "the html is not exactly the premium style … text is too small to read, it should be clear and premium." The public site is rebuilt to that design with larger, clearer type: a floating pill header with a Produkter mega-menu (the eleven products, a promo aside), a Branscher menu (three photo rows), search and a four-language switch (SV · EN · NO · DA); the landing page in the owner's composition — hero with the industry chooser, product features, the guest-to-kitchen flow, product cards, industries, pricing without prices, support, FAQ, closing CTA; and new pages /industries plus /industries/{restaurant,retail,beauty} (restaurant = the full 360° platform, retail and beauty = a curated core). Every visible string comes from the dict in en/sv/no/da — site-dict-parity.test.ts fails the suite when sv, no or da lags behind English; the one exception, documented in TODO.md, is the header search's keyword fallback (lib/marketing/intent-search.ts), whose result labels and descriptions are still English on every locale. Swedish is the site default. SEO/AEO/GEO: per-locale metadata + hreflang (Swedish on the bare URL, the others ?lang=), Organization/WebSite/FAQPage/SoftwareApplication/Breadcrumb JSON-LD, /llms.txt and the Organization description repositioned to one POS platform for three industries, and a new OG image.

• The kitchen bong on a Zebra is bigger, at its natural width, with room at the tear (2026-09-07).

Owner: "can we do the bong a bit bigger and clear — plus add some extra space on top — the label is 80 mm." The ZPL encoder gave the bong the receipt grid's face: font 0 squeezed to 60 % of its width and wrapped on a budget twice the real advance, so the text used a third of the roll and "Gluten, Mjölk" broke over two lines. The kitchen ticket now has its own typography: the face at its natural proportion, sized ~43 % taller (4.3 mm capitals on 80 mm/300 dpi), wrapped by measured glyph widths (a per-glyph table of font 0), rules drawn as one thin bar, 12 mm above the first line and 5 mm under the last. Receipts and labels are byte-identical. Needs a box deploy to reach the printer.

• The last eight sidebar dropdowns are tile hubs (2026-09-07). Owner: *"there were some nav actions

left — can we fix all of them so the others get the card grid design."* Bokningar → Reservation Center, Lokalinställningar → Venue Center, Gästtjänster → Guest Center, Kedjor & grupper → Chain Center, Food Bazar → Food Bazar Center, Abonnemang & funktioner → Plan Center, Installationscenter → Setup Center and Plattformsadmin → Admin Center: each group is one flat sidebar link under its own label, and every page the dropdown held is a tile four to a row with its old href, label, feature gate and trade gate (the restaurant-only groups carry the trade onto each tile, so search hides them from a salon too). The sectioned settings page is the Setup Center's "Inställningar" tile; Sound & Atmosphere still opens in a new tab; the Admin Center sends a non-superadmin back to Home like the Admin Hub does. Labels ×20 languages, blurbs en + sv/no/da. Enheter keeps its two rows (Köksrouting was promoted back on purpose).

• "Så får köket veta" with a help panel (2026-09-06). Owner, with a screenshot: *"compact and too

hard to understand … maybe add the help text on a right side panel to keep the surface clean."* The kitchen-delivery card is now two columns: the controls on the left — four big quick-pick tiles (Papper · Skärm · Båda · Ingen), two plain switches, the per-till read-back chips and the exceptions table with channel names only — and every explanatory sentence in one "Så fungerar det" panel on the right (what it controls, what a quick pick does, the two switches, each channel's meaning, where the till-side switches live, the paper-has-no-delay note). Same fields, same writes.

• Köksrouting in the tile pattern (2026-09-06). Owner: *"very messy today — I get confused how to

use it, too much text and not so easy to understand."* The page is now a header with ONE live status line (the health verdict) and six tiles with a one-line blurb and a live count — Så får köket veta · Stationer · Kategorier · Varor · Hälsokoll · Logg — and the chosen section's panel opens right under the tiles. The editors are the same code; the explanatory paragraphs the blurbs replaced are gone.

• Marknadsföring and Experience Studio open in the same tab (2026-09-06). Owner's report: the new

tab read as the link not working. newTab: false now opts a non-/dashboard workspace into the same tab; the Marketing Hub's forced new tab is removed.

• Five more sidebar groups are single links to tile hubs (2026-09-06). Owner: *"take all one at a

time — Kunder, Ekonomi, Restora Profit, Pågående service and Lager & leverantörer."* Same recipe as Meny and Personal: each group is now one flat link — Customer Center /dashboard/customer-center, Money Center /dashboard/money-center, Profit Center /dashboard/profit-center, Service Center /dashboard/service-center, Inventory Center /dashboard/inventory-center — and every page the dropdown held is a hub-linked tile with its old href, label, feature gate and trade gate (the grocery-only Lager rows stay grocery-only; the grocery-nav-isolation guard now counts a hub tile as a door). Labels in all 20 languages, blurbs in en + sv/no/da.

• The website's styling vanished after going back, until you refreshed (2026-09-09). Owner:

"when I go to some link and go back the website doesn't load correctly, I have to refresh." Next bundles CSS per route, so website-base.css is copied into the landing chunk AND the industries chunk; whichever chunk loaded last sat last in the document, and its copy of the universal reset (.r360-site * { margin: 0; padding: 0 }) then beat every same-specificity page rule on source order alone — the landing page came back with all its spacing zeroed, and an industry page did the same the other way round. The whole base sheet now lives in @layer ws-base, so an unlayered page sheet wins regardless of chunk order or specificity: the relationship the two sheets were always meant to have. Reproduced and re-checked with Playwright in both directions, history-back and <Link>-back.

• "Open 24 hours" never reached the website (2026-09-07). Owner, from a tester: *"to change the

opening hours to 24h on all days it does in admin but the real website does not change to 24h … when he manually adds 09:00 – 23:00 and copies that to all days it does work."* The editor only flips the day's is24Hours flag and leaves its old open/close strings in place, and the storefront dropped that flag on the way to its hours blocks — so the site kept printing the stale range. The opening-hours block, the contact card (both variants, plus its open/closed pill), the premium templates' hours lines and {{hours.weekly}}, llms.txt and the Google Business export now all say "Open 24 hours" for such a day. Verified by rendering the blocks with a 24h week.

• Booking picker said "Booked" on slots nobody had booked (2026-09-07). Owner: *"under booking

table the time slots show 'booked' but there was no booking."* Two causes. The public book route served every venue a hard-coded 17:00–22:30 evening, ignoring the venue's opening hours (so the 24h change above never reached the picker either); and the picker greyed every arrival whose stay would run past that close with the word BOOKED — with the standard two-hour stay, 21:00 / 21:30 / 22:00 read "Booked" on an empty day. The route now serves the venue's own window for the date (the same openingWindowFor fact the tills read: hours, 24h days, special days, closures; a venue with no hours stored keeps the old evening), a slot that cannot fit the stay says "Past closing", only a booking on that table says "Booked", a closed day says so instead of drawing a grid, and the POST refuses a time outside the window with the same rule. A real venue without a floor plan no longer inherits the sample room's fake bookings either.

• The booking picker's no-show deposit step was dark (2026-09-07). Found beside the fix above,

fixed on the owner's go. The route had served the venue's deposit since Phase 37 and the picker had the consent step drawn and gated, but the merge between them never copied the field — so a venue with a deposit switched on took web bookings without the guest seeing the amount or agreeing to it, while the server still stamped the reservation with a pending deposit for staff to collect. The merge is now a pure, tested helper (picker-book-data.ts) that carries the deposit through; the route resolves the deposit currency the way the simple form's config does (owner choice → country → platform default) instead of a hard-coded SEK; and the figures print ISO-coded ("200,00 SEK"). Driven in Chromium: the step shows, Confirm stays disabled until the box is ticked.

• Personal & behörigheter crashed for a tenant with an old staff member (2026-09-06). Owner:

"the first grid box link /dashboard/staff is not working, others are working." The member list did createdAt.split("T") on a row written before that field existed, and one such row took the whole page into the error boundary. It now renders "—" for a missing date.

• Meny and Personal are single sidebar links to tile hubs (2026-09-06). Owner: *"when i click on

menu instead of collapsing the nav it can have only a menu link, and the page should be similar to our grid boxes design … then Personal — it is very big but i want the same layout, 4 tiles per row."* The menu group (restaurant) and the team group are now one item each — Menu Center /dashboard/menu-center and Team Center /dashboard/team-center, rendered flat under the group's own label (Meny / Personal) — and their pages moved to HUB_LINKED_ITEMS with the hub page as hubSource (same hrefs, labels, feature and trade gates; every old row name stays searchable as a keyword). The hubs use the Enheter tile family four to a row: Meny · Kombos · Lunch & buffé · Produktionsstationer · Importera meny · Näringsdeklarationer, and the eleven team pages in their old order (Rekrytering restaurant-only). Blurbs live in the new hubs dict namespace (en + sv/no/da); "Menu Center" / "Team Center" labels added in all 20 languages. The menu editor keeps /dashboard/menu (26 deep links point at it). A grocer or a salon keeps its direct "Tjänster & produkter" link — a one-page catalogue needs no hub. New components/dashboard/HubTiles.tsx.

• Enheter › Förare: "Lägg till förare" right in the grid (2026-09-06). Owner: *"a new card Lägg

till förare, then that card changes to the dispatch function so it becomes super easy to add a new förare or dispatch right from the grid card; then Förarlistan i Dispatch, then Så ansluter du."* The first tile is the Dispatch roster's add form (name · phone · vehicle, Swedish vehicle labels); on Add it creates the driver through the same /dispatch/drivers call Dispatch uses and immediately mints the phone code (/dispatch/pairing-code), and the tile becomes that driver's pairing card — the big single-use code, the QR, the /driver?pair= link with copy, a 15-minute countdown, "Lägg till en till" and "Öppna i Dispatch". Without the Own Delivery & Dispatch add-on the tile says so and links to Your Features. Order is now: Lägg till förare · Förarlistan i Dispatch · Så ansluter du; the old "Var koden hämtas" explainer folded into the tile. New components/dashboard/devices/AddDriverTile.tsx.

• A till can be removed, not only spärrad (2026-09-06). Owner, on the new Enheter tiles: *"we can

spärra other kassa today but we cannot remove that fully" — nine spärrade QA tills and an old Kassa 1 with no way out of the list. The ⋮ menu on a spärrad or never-paired till now offers Ta bort…*; a paired till still only offers Spärra (removing a till that can sell is an outage). The backend decides what removal means (POST /pos/admin/registers/remove): a register that never reserved a receipt number is deleted outright with its pairing codes; one that did is hidden from the fleet (revoked underneath, removedAt/By stamped) and its seriesPrefix stays taken for good, because a new till continuing S001-T03 would collide with receipt numbers already on paper. The confirm dialog says which will happen (hasReceipts on the register view). The series allocator reads the list with includeRemoved=1 so a hidden series is never handed out again.

• Enheter: the newest till comes first (2026-09-06). Owner: with 20+ tills the one just added

must not be lost at the end of the grid. Device tiles sort by createdAt, newest first.

• Enheter is now two levels of tiles, in the Home page's style (2026-09-06). Owner, right after

locking Home: "same UI/UX style for Enheter — today it is confusing. From kassa to network 4 tiles in a row and 4 in the next; under Kassa the same grid: one for Öppna/Parkopplingskod, one for how to connect, one for Kassapersonal…" Level 1 (/dashboard/devices) is one tile per category — Kassor, Kök, Självservice, Displayer, Förare, Betalning, Hårdvara, Nätverk, trade-filtered as before — with the category's count and status line; the tab strip is gone. Level 2 (?tab=pos etc., the same deep links) is a grid: row one the tools (Lägg till enhet with its name field, then the category's helpers — Kassapersonal, Så ansluter du, Äldre Restora-surfplatta for Kassor — and link tiles such as Köksrouting), then ONE TILE PER DEVICE with its status, kitchen line, Funktioner, Öppna, Parkopplingskod and the ⋮ menu; a minted code shows inside the device's tile. A helper tile opens its existing panel full-width directly under the tools row, above the device tiles (the guide, the staff card, the terminal/printer/kiosk fleets, the reliability report — none rewritten). ?connect=1 still opens the Anslut enhet menu; the ${type}-header anchors stay. Behöver åtgärd / Senast använda render on level 1 only when something actually needs attention. New components/dashboard/devices/DeviceTiles.tsx; the fleet panel's row internals (status chip, ⋮ menu, live code card, kitchen note) are exported and reused.

• Home is now a quick-actions page, for every trade (2026-09-06). Owner's brief with a

reference image: the admin landing page should put the functions in front of the owner "so the user does not need to scroll or search". /dashboard is now one small line naming the business type ("Restaurang", "Livsmedelsbutik", "Klinik" — lib/verticals/business-type-labels.ts, sv/no/da; the welcome + tenant-name heading was dropped the same day as redundant with the sidebar's workspace switcher) and a 3×2 grid of big cards — Inställningar, the catalogue, Enheter (live "N kassor · N enheter aktiva" + "Lägg till ny"), Erbjudanden ("Skapa banner" / "Lägg till rabatt"), the trade's daily desk, Webbplats — and a help line. The reference's separate PoS card was folded into Enheter the same day (owner: they were the same door — the POS-registers page lives inside Devices). Which cards and which doors is decided per trade in lib/dashboard/home-quick-actions.ts (the catalogue card opens /dashboard/menu for a restaurant and /dashboard/catalog for a shop or a salon; the daily desk is Beställningar /dashboard/order-desk for a restaurant, Lager /dashboard/stock for a grocer, Bokningar /dashboard/bookings for a salon or clinic; a salon's devices line has no KDS), gated by the sidebar's own entitlement + trade axes so a card can never show a door the sidebar hides. Counts are read server-side (registers from the backend, the fleet through the new lib/devices/active-fleet.ts, which the devices summary route now shares) and degrade to no status line, never a confident zero. Three deep links were added so the buttons land where they say: /dashboard/devices?connect=1 opens the Anslut enhet menu, /dashboard/offers?new=1 opens the editor on a blank offer, /dashboard/site?panel=add&q=banner opens the website editor's Add palette filtered to banners. The KPI row, Operations Center, starred-shortcuts row and onboarding checklist no longer render on Home (their components remain; Orders / Intelligence / the sidebar keep their doors). Strings in en + sv/no/da (overview.qa*), fully translated — the dict ratchet is unchanged.

• Themes now adjust to the tenant's trade, and two theme-seeded storefront defects (2026-09-05).

Reported from ten_beauty-salon: applying a theme put a RESTAURANT hero on a salon's landing page, the contact page showed two "Send us a message" forms (one unthemed and posting nowhere), and Opening hours rendered a 14-row double week. (1) Trade-aware imagery: every restaurant stock photo the generic packs ship now has a verified services/grocery counterpart (src/lib/themes/vertical-images.ts); the swap applies at install AND preview (installer.ts splitPages), on the gallery cards (toCatalogCard), and at render time for sites that installed before the fix (PageBlocks heals known stock ids via the tenant's declared vertical — an owner's own images are never touched). Uploaded .r360theme.zip manifests can now declare verticals so a restaurant theme is never offered to a salon (schema + docs). (2) The generic packs' contact page no longer seeds a standalone form block next to contact-info (whose embedded form is the real, wired one); the live renderer also de-dupes an action-less form on already-installed sites. (3) The double week: the /onboarding wizard wrote mon…sun and /welcome/onboarding wrote Monday…Sunday next to the template's monday…sunday, and the settings PATCH shallow-merged them all together — both wizards now write the canonical keys, the PATCH replaces openingHours wholesale (self-healing on the next hours save), and groupWeeklyHours/foldWeeklyHours fold abbreviated + sv/no/da day keys into the canonical week (exact-keyed entries win a conflict).

• Presentkort redesign on the tills, with the website's 26 designs (2026-08-29). The POS

Presentkort screen is one premium two-column view (belopp → design → leverans; saldo → beställning → betalning) on the web, Android and Windows tills. The card designs are the website's own catalog (src/lib/gift-cards/greeting-templates.ts), reached through TWO GENERATED artifacts (pos/web/src/data/gift-catalog.generated.ts, pos/app/.../data/GiftCatalog.generated.kt) emitted by npm run generate:pos-gift-catalog and gated by src/lib/gift-cards/pos-catalog-parity.test.ts, which regenerates them in memory and fails on any byte of drift — count, ids, order, copy or token mapping. Till-sold cards with an email recipient are now delivered: the device issue carries buyer/recipient/greeting/ delivery, and a new cron, /api/cron/gift-pos-delivery (every 5 min), claims due cards from the POS store through POST /pos/admin/giftcards/claim-deliveries and settles them through POST /pos/admin/giftcards/delivery-result, sending the same gift email/QR the website sends. Presentkort is never offered as payment for a Presentkort (the tills' issue-method model has no such kind; the server's GiftIssueTenderDto refuses it). engine.ts no longer embeds a full gift code in the one error message that did.

• A shop can author its own assortment from a desk (2026-08-28). /dashboard/catalog

(Sortiment) is now in the grocery vertical's navigation and shows the whole grocery half of a product: barcode, PLU, VAT category, pant (amount + SE-PANT-CAN/SE-PANT-PET scheme), stock flag, age gate and weigh pricing (price/kg, tare, minimum net). Until now the ONLY door that could author any of them was the till's own quick-create, reached off a SCAN of a code the catalogue did not yet hold — so a shop could not put a product into its own assortment without standing at the counter with the packet in hand. The Menu page is deliberately not that door: translateLegacyMenu rebuilds variations wholesale from the tenant blob and emits none of those fields, so a grocery product authored there loses its pant at the next translate. The fields sit in a collapsible "Butiksuppgifter" section per variation, grouped by the question each answers (Identifiering / Pant / Lager & regler / Vikt) and open by default on any variation that already carries one — so a salon's form is unchanged and a shop's is one click from complete. Offered on any non-SERVICE product in EITHER trade, because a salon that sells shampoo has a barcode too. Header, empty state, add-panel title/placeholder and the type toggle fork on useTenant().vertical (*Retail keys, the same mechanism overview already uses), authored in sv/no/da so the dict-coverage ratchet holds.

• `weighPricing` on the admin projection. The last grocery field listItemsForAdmin was

missing: added with the others on 2026-08-25 and left off, so a scale product was priced by the till and readable by nobody. The projection's declared type also gained uom, priceMinor, currency and taxCategoryId, which the mapping had always emitted while the signature denied them.

• `null` erases. barcode, sku, deposit, weighPricing and minBuyerAge accept null

through the proxy and the DTO, and upsertItem DELETES the key rather than storing one. Absent-means-keep is what makes the merge safe and is also why an optional field without an explicit erase is write-once from every door but the database. (plu keeps its own contract, where the null is a real stored value.)

• `taxCategoryId` is the taxonomy, not a string. TAX_CATEGORY_IDS is now declared once in

@restora/domain-types beside the TAX_RULES table keyed by it, with TaxCategoryId derived from it. VariationDto validates @IsIn(TAX_CATEGORY_IDS) (it was @IsString() @Length(1,64) — any string) and the proxy z.enum(TAX_CATEGORY_IDS). Four hand-written copies of the same five words now derive from it: ENGINE_TAX_CATEGORIES, the service-offers DTO, and the kernel's corpus and fuzz generators. Before this a typo ('standrad') created a product that SAVED, synced to every till and then could not be priced — surfacing only at the counter as "Motorn prissatte inte notan.", with a queue behind it.

• A refused barcode no longer lands on the document. upsertBarcode has always refused a code

another item owns (409 BARCODE_TAKEN), but it ran AFTER upsertItem(doc) — so the losing product kept the conflicting code while the registry still pointed at the rightful owner. Invisible while nothing displayed a barcode; the moment the editor showed one it became a duplicate the owner could see, was told nothing about, and could not save away. The check now runs before the write, matching createItemFromTill, which has always refused up front. The editor renders the conflict in the owner's language, naming the code.

• Grocery wording leaks on both till kits. overviewBillsUnattached ("N utan bord") is

suppressed on a retail till — nothing on a counter attaches to a table, so it fired for every open purchase — and the Systemstatus Bongutskrift row is gated on showKitchen rather than ungated, so it no longer sits green and permanent on a venue with no kitchen. Retail twins added for orderMenuLabel, orderMenuSubtitle, sectionOrderLabel, internalNoteHint, discountAppliedHeading, emptyTicketHeldBill, the releaseBill* family and outsideServingHours, in all four locales on both kits. The release verb is släppa, never "lämna köpet öppet": öppet köp is a Swedish consumer's right of return, and a button offering to leave a köp öppet reads as granting one. Every restaurant string is pinned byte-unchanged.

• Bokningshistorik on the tills (2026-08-27). New operator-gated device endpoint

GET /pos/registers/bookings/history (NestJS proxy → api/internal/pos/booking-history): the whole reservation book — every date, all four stored statuses and the no-show flag — searched, filtered (date range / status / source / table), sorted and keyset-paged in one ask per page. Same posBookingRow projection as the day list (no email, no cancel token), and deliberately NO money on the wire: the store holds no durable booking↔nota link, so the history renders an honest em dash rather than a guessed total. The operational "Alla" board stays today-and-forward exactly as 1.0.5746 shipped it.

• `startAt` on every till booking row. The scheduled start as a venue-clock instant,

computed by the same evaluator as checkInEligibleAt (bookingStartAtMs in check-in-window.ts; eligibleAt = startAt − the window, by construction). It is what the tills' derived Försenad (late) presentation turns on — presentation only, never written back to the store.

• Bokningssheet remake — the premium reservation popup (2026-08-28, 1.0.5750). The

till's reservation details dialog, remade the same way in BOTH kits (pos/web BookingSheet.tsx ↔ Compose BordScreen.kt): 640-wide record dialog; a p5 state chip in the body wearing the board pill's exact colour families (Sittande/Incheckad/ Försenad/Kommande, neutral for closed answers) beside the quiet facts line (reference · källa · VIP · occasion); the three tabs on the kit's own segmented pill strip; the tab body, Ankomststatus, Bordsättning and Intern not each a bordered card; Avboka down from the 64-px coral bar to a default-size danger button (the two-step stays the protection); the "Syns bara för personalen" audience line VISIBLE under the note instead of a vanishing placeholder; and — the owner's named requirement — the guest's NAME leads Gästinformation whenever the booking carries one (customerName is the only guest identity on the wire; phone stays off tills, no email rides the read projection). No handler, gate, window rule, confirm step or wire contract changed; the sheet's pinned source contracts (early-door gate, deposit seam, one-flip timer) hold verbatim. New BookingSheetRenderTest renders the Compose sheet to PNG and pins the chip + guest-name anatomy; the pos/web preview harness's ?locale= was reconnected (it silently stopped switching at the 2026-08-17 locale split).

• Enheter subpage cleanup — add/remove without scrolling (2026-08-28, v2). The register

tabs' vertical sprawl is gone: the pairing widget is ONE wrapping row, the create control moved from below the fleet to a top action bar ("+ Lägg till enhet", visible without scrolling), and rename/spärra left their unlabeled icon buttons for a labeled ⋮ row menu ("Byt namn" / "Spärra enhet…", confirm dialogs unchanged). The healthy kitchen sentence and the Funktioner disclosure share one quiet meta line per row (warnings keep their own prominent line); Kassapersonal and Äldre Restora-surfplatta are collapsed single rows — the staff header keeps the person count and the "Inga varor på kassan" warning visible while collapsed. Betalning renders TerminalsPanel (with its Add a device form) before the binding/sandbox cards. No handler, endpoint or dialog changed.

• Enheter page visual remake (2026-08-28). /dashboard/devices now matches the supplied

reference design: header with the live online/offline/ej-parkopplade roll-up and one "+ Anslut enhet" entry point (a menu over the existing per-type pairing flows), a category tab row (Översikt · Kassor · Kök · Självservice · Displayer · Betalning · Hårdvara · Nätverk, live counts), a system-health banner, and the Behöver åtgärd / Senast använda enheter overview. UI-only in intent: every fleet panel, pairing widget, claim form, rename/revoke action and the first-run Kom igång card is the existing component re-homed into tabs (the collapsible boxes became always-open sections; ${id}-header anchors and the IA-2 ?tab= deep links still land, now selecting the tab that absorbed them). The two display types share the Displayer tab. One additive API change: GET /devices/summary now also returns kiosks, hardware.online and a per-device devices[] array (id/kind/name/online/lastSeenAt/model) computed with each fleet's OWN heartbeat window, so the overview can never disagree with the tab a row links to; the pre-existing top-level 5-minute counts are untouched (OperationsCenter). Dict devices title/subtitle updated (sv "Enheter"; en/da/no in step); statuses use the semantic .status-* tokens in both themes.

• Void-reason wording: the POS Makulera reason Gästen gick now displays as

Kunden avbröt (en Customer cancelled, no Kunden avbrøt, da Kunden afbrød) in both till kits, all four locales. The stored reason code guest_left is unchanged, so historical events render through the new localization untouched.

• **The legacy Next.js fiscal rail could take real money and sign a Swedish receipt with a SANDBOX

control code, in a market that was never opened (2026-08-20).** The NestJS till path has passed assertMarketOpenForSale since Phase 6; this rail — storefront checkout, QR pay page, kiosk, delivery ingest, counter payment, PSP capture — consulted no gate at all. certified: false was honest in the data and invisible on the receipt.

Fixed at the CHOKEPOINT, not the call sites. lib/fiscal/se/market-gate.ts decides three refusals — MARKET_NOT_OPEN, MARKET_STATE_UNKNOWN (fail closed) and SANDBOX_SIGNATURE_ON_LIVE_SALE (a placeholder code may not sign a real sale even in an OPEN market). Every reservation in wire.ts (reserveFiscalSale, reserveFiscalPortionSale, reserveFiscalTraining) now takes a REQUIRED clearance and throws without one, so a stale client, a deep link, a hand-rolled POST, a replay or untyped JavaScript cannot reach a receipt number. A drift check refuses clearance won on a certified unit but spent on the sandbox. createTenantOrder refuses BEFORE the money moves on any collecting call.

Deliberately NOT gated, each a standing rule: refunds and returns (structural — the extra reservation takes no clearance parameter at all), receipt copies and pro forma, and training mode. Onboarding a venue before its country opens still works.

Test mode is an explicit declaration of TWO variables (FISCAL_DEV_ALLOW_SANDBOX=development and NODE_ENV=development), modelled on the dev-pairing door: a check reading "not production" passes when nothing was said. 19 adversarial cases in market-gate.test.ts.

• Gift cards were minted in a currency the REQUEST chose (2026-08-17). Five mint doors read

(body.currency ?? 'SEK') — the public purchase route, the public corporate portal and the dashboard's issue / bulk / recurring doors — and five UI pickers offered SEK·USD·EUR·GBP. A euro venue therefore minted SEK cards which its own redeem gate refused as foreign, after the guest had paid; a stored-value card cannot be re-denominated once sold. The denomination is now the VENUE's on every door, through one resolver (lib/gift-cards/currency.ts — venueGiftCurrency, giftCurrencyRefusal, sameCurrency — plus venue-currency.ts for the one await). A caller naming a different currency gets 409 `GIFT_CURRENCY_MISMATCH` before a card exists, and the card, the Stripe/Connect charge, the Swish/PayPal/Adyen leg and the presentkort invoice all read that single value, so charge and mint cannot disagree. Every picker became a read-only badge fed from the server (/buy, the embed widget, the corporate portal, the dashboard issue modal, bulk, recurring); rails.ts gates Swish on the same resolved currency so the button and the route can no longer disagree. On the redeem side, the six !== currency gates (engine tender / external / closed-loop, closed-loop preview, payment-intent, orders, pos/quote) now compare through sameCurrency, so a venue that stored "sek" can no longer have its own cards refused. Guest gift money prints its ISO code (formatGiftMoney — reader's language, the currency's own locale when none is known, never the ambient one). 15 new tests; ui tsc 0 errors.

• **Ten confirmed defects across the HQ v2 p8/p9/p10 surfaces (2026-08-17), each at its

root and each re-measured in the running app at 1920×1080.* - Beställningar' detail panel sat below the fold (p8). The rail opened in a row BELOW the KPI cards, 217 px further down than the design puts it, and the aside had no ceiling — its `flex-1 overflow-y-auto` never engaged (`scrollHeight === clientHeight === 532`) and "Acceptera & skicka till kök" landed at y 987 with the panel ending at 1138. The panel is now the rail of the WHOLE workspace, beside the KPI row exactly as p8 draws it, and the aside is capped (`xl:max-h-[calc(100dvh-15rem)]`, a MEASURED number). Re-measured: panel 217→1057, actions 906–1040, scroller 1004 over 568. - The relative estimate printed raw minutes. "(om ca 1043 min)" for a next-morning slot and "(om ca 2880 min)" for a pre-order two days out. `relativeSpan` (pure, spec-pinned) now rolls minutes into hours and days and the dict owns every word: the same order reads "(om ca 2 dygn)". - A tab switch left the previous order's panel open beside a list that did not contain it — most visibly on Parkerade, which prints in words that nothing there is listable. The selection now resolves against the FILTERED rows, so no filter, tab or search can show a row the list does not hold. The selection itself survives: return to the tab and the panel is there. - p8's trailing filter button was missing, replaced by a "Rensa filter" text button that only appeared once you had already filtered. The icon button is now always at the end of the filter row, and it says what it does (disabled + "Inga filter är aktiva" when there is nothing to clear). - The delivery slip printed "ORDER ##1203". `GET …/orders/[orderId]` hand-rolled its own copy of `buildDeliveryView`, and the copy had drifted: the shared builder strips a stored leading `#` because the slip prints its own. The route now calls the one builder, so the screen, the printed slip and the PDF cannot disagree about an order number. - A Beställ line lost its modifiers AND its "Allergier / notering" on the way back to the nota. `AdminTicketLine` carried neither, so a dish sent with a size, two extras and a note read as a bare "1 × Pizza Vesuvio" — the dashboard and the kitchen bong disagreeing about the same dish. The backend projection now ships the option NAMES and the note (no per-option money: it is already inside the line's engine total), the ui twin whitelists them, and p10's nota draws them under the dish. - The draft's "Totalt" was not what the send added. `bestallQuoteAdmin` priced the proposed rows as a standalone basket, so on a nota carrying "Rabatt 10%" it quoted 89,00 kr for a row that moved the bill by 80,10 kr — a figure an operator could read out to a guest and then fail to charge. The quote is now a DELTA: the live bill priced as it stands, then priced again with the rows appended, through the same engine call WITH the bill's own discounts. Verified live: nota 290,70 kr, p11 "Pris" 80,10 kr, draft Delsumma 71,52 + Moms 8,58 = Totalt 80,10. - Typing in "Sök produkter" deleted the whole category tab strip (3 tabs → 0), because the strip was replaced by a `<span />` while searching. p9 draws the tabs and the search field side by side, always; they now are. No tab is current while a search runs, and tapping one clears the search and takes you there. - Error text on the Beställ screens used raw text-red-600 (3.6:1 on the dark card). Now the guarded `.status-ink-danger`, and the one hover state uses the same `--status-danger-ink` token. - The table panel still drew "Senaste aktiviteter" + "Bokningsinfo" beneath the nota*, which p10 removes outright ("Det dubbla informationsområdet längst ner är borttaget… nås via flikarna högst upp"). Both cards are gone; a long nota has the panel to itself.

• **Reservation check-in got a 15-minute window, a confirmation dialog and a protected

early door (2026-08-20). The ONE rule lives in `lib/reservations/check-in-window.ts` (`CHECK_IN_EARLY_WINDOW_MINUTES`, `checkInWindowVerdict`) and is evaluated in the venue's own timezone via the venue clock; a stored time that cannot be judged fails CLOSED. Both mutation doors — the dashboard PATCH and the internal POS action route — refuse a too-early check-in with `CHECK_IN_TOO_EARLY` + `eligibleAt`/`serverNow`, and a no-show row with `BOOKING_NO_SHOW`; every surface (dashboard list/detail/table panel, web till, Android till, Windows till) renders a functionally disabled "Öppnar HH:MM" control that flips at the boundary without polling, and confirms the guest's identity (name · time · covers · table · phone ending) before any stamp. Tidig incheckning** lives inside booking details only, needs reservations.override (dashboard, admin-only) or owner/manager/ approve (till roster, proven server-side per request), demands one of three reasons, and stamps earlyCheckIn {reason, by, at, device} plus an activity-log row in the same transaction. Responses carry checkInEligibleAt and checkInWindowMinutes, so no client authors the 15. sv/en/da/no on every surface.

• Flytta bord brought to HQ v2 p12 (2026-08-17). MoveTablePanel.tsx now draws the

PDF's own anatomy: the source stat row (Gäster · Öppen nota · Aktiv sedan), the outlined "Från (aktuellt bord)" plate, the valid-target grid with p12's three tiers (Rekommenderad in status-ok green, its same-capacity peers Bra alternativ, roomier tables plain) under "Rekommenderat bord passar bäst för antalet gäster", the "Detta flyttas tillsammans" summary ending in a ticked "Serviceflöde bevaras", and Avbryt / Bekräfta flytt over the padlocked "Flytten kan inte ångras." The recommendation arrives ARMED — p12 draws it checked, and the PDF's own logic note is "systemet kan rekommendera lämpliga mål-bord men personalen kan välja manuellt" — while any other valid tile is one tap away. The ranking left the JSX for lib/reservations/move-table.ts (rankMoveTargets, moveParty) and is pinned by tests, including the rule that a party of unknown size filters nothing but may never be RECOMMENDED a table smaller than the one they are already sitting at. No second mover was built: it is still the one shipped door (POST pos/ticket/move-table → moveTableAdmin's rev-pinned CAS on boundTo.refId), with a covering booking riding the existing reservations move route afterwards. Nothing here settles: an OPEN bill is rebound to another table — no receipt number, no journal row, no tender — and the öppen nota figure is the board's server-priced string verbatim, rendered as an em-dash when the bill cannot price. New dict key ovMtFreeNow ("Ledigt nu"), because p12's move grid asserts availability at this moment where the map plate says the bare "Ledigt"; ovMtOnlyValidHint and ovMtActivitiesDetail now match the PDF's Swedish word for word ("noteringar", not "noter").

• Beställ + Produktdetalj & modifierare (2026-08-17, HQ v2 p9 + p11). The ordering

surface is now the SCREEN the PDF draws, not a rail panel: BestallSurface.tsx takes the whole overview (the NewBookingWizard regime) with the header "Beställ · Bord N" + state chip + Flytta | Mer | Avbryt, the automatic-draft banner, the menu on the left (Favoriter + category tabs + search, the product grid, "Alla produkter" with counts) and "Nya artiklar till Bord N" on the right, ending in one primary "Skicka N artiklar till kök". After a successful send the operator FLOWS BACK to the active table (p9's own note 3), where the nota and the aktiviteter have just updated — no second nota is drawn here and there is no competing "Spara". p11 is built, and it is built on the tenant's OWN menu. Tapping a product opens BestallProductDetail.tsx: the obligatory single-choice group, the multi-select tillbehör with checkboxes, "Allergier / notering" and a Sammanfattning card (Produkt · Val · Antal −/+ · Pris) with Avbryt / Lägg till på notan. The PDF's "Ryggbiff / Stekgrad" is an EXAMPLE of the pattern and is hard-coded nowhere: the groups, their options, their min/max rule and their money come from pos_modifier_groups through the bestall-catalog door, which now projects them (they were on that projection's never-leaves list for a reason that had expired — no dashboard surface could ask for an option). A venue with no modifier groups gets the same screen with the question area empty. Every figure on both screens is the server's. A new READ-ONLY door, POST /pos/admin/tickets/bestall-quote (BFF: …/pos/ticket/bestall-quote), builds the very lines the send would build — same catalogue, same server-resolved modifier pricing, same price ladder, same tax resolution under the TABLE's own scope — and prices them with the same evaluatePromotions/priceBasket pair every other view uses. It answers the configured line's "Pris" (debounced, so ticking an option re-asks rather than adds) and the draft's row totals + Delsumma / Moms / Totalt. Nothing is summed, multiplied or discounted in the browser; a figure the engine cannot produce is OMITTED, never 0,00. Proven by spec: a quote and the send that follows it return the identical figure for the same dish. The allergy note is real plumbing, not a decorative box. It rides ext.foodBev.note — the platform's documented channel for "utan lök" / "allergi: nötter" — so it lands on the stored line, the kitchen ticket line and the fire paper. It carries no money and nothing prices it. The required-choice gate is the money door's own minSelect read forward, so a single-choice required group opens pre-answered with the menu's default and the send can no longer fail on a question the screen never asked. Verified on glass against a real tenant (ten_shani-pizza, Bord 1): the size ladder substitutes the unit price server-side (89,00 "Liten 26 cm" + 15,00 "Extra ost" ⇒ the engine's 104,00 kr), and the draft's Delsumma/Moms/Totalt are the engine's own VAT buckets.

• Beställningar — the order desk (2026-08-17, HQ v2 p8). A new dashboard workspace at

/dashboard/order-desk: the day list a person WORKS at (avhämtning, leverans, över disk), as opposed to /dashboard/orders, which is the TV & Displays hub's watch-from-the-pass kanban. Same store, same doors, different job. It is a read surface, not a second order engine: GET /api/tenant/[t]/orders/desk reads tenant_data.orders once and projects the row (lib/orders/order-desk.ts); Acceptera and Markera utlämnad are the existing PATCH …/orders/[id] (which is where crossesKitchenAcceptance fires the kitchen bong and stamps the milestone), and Avvisa is the existing cancel-and-refund route. p8's own logic, implemented literally. An order WITHOUT a table belongs here, never in the booking list and never branded "saknar bord" — so a tableless dine-in order is on the desk and a seated one is not (one order, one screen). The three payment sentences read from the stored tender, not a guess: a PSP settled it before anyone touched it (Betald online), cash/in-person card/wallet could only have been taken with the guest present (Betald i kassan), pending + cash is the platform's own pay-at-pickup shape (Betalas vid hämtning) and everything else says Ej betald. A pending MARKETPLACE order is its own lane — a partner and a courier are waiting on the answer, which is why the PDF paints it amber. Nothing is invented where the platform stores nothing. Money is rendered ONCE, on the server, from a stored figure (Order.total, OrderItem.price, which the schema defines as the line total) — a line or an order without one renders no amount at all, never 0,00. The estimate line is drawn only off promisedReadyAt (stamped at acceptance) or the guest's own scheduledTime, so an un-accepted Foodora order gets no ETA rather than a fabricated one; a courier name appears only for own-driver runs. The Parkerade tab and KPI print IN WORDS that a parked bill lives on the register and cannot be read from here (only a table-bound one ever reaches the dashboard, and the projection that does rewrites it to accepted with no customer or lines) instead of an empty list that would claim there are none. p8 also draws an "Intern notering" box and a "Redigera" button; an order has no staff-note field and nothing in the platform edits an order's lines, so both are deliberately absent rather than fake — see the header comment in OrderDeskPanel.tsx for what they would cost. Rules are pure and spec-pinned (order-desk.test.ts, 17 tests); the day window is the BROWSER's own local-midnight instants, so a service running past midnight is never cut at the wrong hour by a UTC string slice. New dict section orderDesk (sv hand-written). Nav note: sv Orders was renamed Livetavla — p8 gives "Beställningar" to this desk, and two sidebar rows carrying the same word would have been the real regression.

• Bokningsbekräftelse — the confirmation seam (2026-08-17, HQ v2 p3/p4). Server side.

p3 puts a LIVE PREVIEW of the guest's message on the Ny bokning screen, above a character counter ("160/160 tecken"), with SMS and E-post as two channels of the same text; p4 shows the same message afterwards with a per-channel status and a "Skicka på nytt". Three things were missing for any of that to be true. (1) The text is composed in ONE place — lib/reservations/confirmation-message.ts, pure (so the wizard imports it directly for the preview rather than round-tripping to a server it has not written to yet), producing the PDF's own lines including Plats: Bord 1 + Bord 3 (12 platser) from the WHOLE combination, never tableId alone. Phrases are a copy pack (SV_ = the PDF's wording, EN_ for everyone else, picked from settings.defaultLanguage), months are a table rather than Intl — a small-ICU runtime would silently swap "maj" for "May" and change a character count the operator had already approved. measureSmsText reports the real cost: the GSM-7 alphabet (å ä ö are IN it, so a Swedish message is a 160-character message), the collapse to a 70-character budget the moment one pasted smart quote forces UCS-2, and the segment count. The booking REFERENCE is opt-in for exactly this reason: it is 18 characters on a 154-character message, i.e. the difference between one SMS and two for every till-created booking. (2) Channels (notify.ts) — email is untouched, still fire-and-forget, still unable to fail a booking; sms is a DISPATCH: awaited, per-channel, and honest. There is no reservation SMS provider in this product and none was invented — the channel is wired to the tenant's own smsConfig and every way it can be absent (disabled / no sender / no credentials / a dev process that only console-logs and returns true) is reported as not_configured with the reason, from the new smsReadiness() twin of isMailConfigured(). Nothing is ever recorded as sent that was not. (3) A door — POST /api/tenant/[t]/reservations/[r]/confirmation sends or re-sends on the chosen channels and answers per channel; GET serves the preview, the counter and what already went out. It stores Reservation.confirmationChannels (the latest attempt PER CHANNEL — a resend replaces, never appends, because this lives on the tenant blob) and confirmationSentAt, which moves ONLY on a real delivery. Provider I/O runs outside the write lock and the record commits inside it (the deposit seam's settle-then-persist order), and a cancelled booking is refused (409 BOOKING_NOT_OPEN) rather than turned into a second, competing cancellation rail.

• Bordskombination — one booking, several tables (2026-08-17, HQ v2 p2–p4). Server side.

A party of twelve in a room of six-tops is Friday, not an edge case, and until now the book had no way to say "Bord 1 + 3": the suggestion engine answered nothing fits today while the staff pushed two tables together off the record. Reservation.tableIds?: string[] is the full set, PRIMARY FIRST, and is absent on an ordinary single-table booking — tableId stays the primary and every one of its ~40 existing readers is untouched, which is the whole reason the field is additive rather than a rename. One helper decides the inconsistent cases for everybody (lib/reservations/table-set.ts: tablesOf / primaryOf / isCombined / tableBindingOf / applyTableBinding, plus the PDF's own label — "Bord 1 + 3", badge "BORD 1 + 3", built on the existing isBareTableName shape rule so a venue that named its own tables is never given the word twice). Occupancy now takes the whole set: a combined booking holds BOTH tables for the sitting — in occupiedTableIds, in the over-capacity shrink report (measured on SUMMED seats, so 12 on 6+6 is no longer reported broken), and in the public /book page's own window engine, where reading only the primary would have sold the second table to a guest. assign-table runs the same three checks over a set (all exist / all free / summed seats hold the party, with the named-staff override intact) and gained an auto-assign path; suggest-table proposes the smallest PAIR, then a triple, capped at three, preferring tables the venue put by the same landmark (DesignerTable.near — landmarks, NOT a table adjacency graph) and otherwise the least waste, with the biggest table anchoring the set. "Ingen bokning utan bord": the staff create and the till create/update doors accept tableIds and, when a caller names nothing, assign a table themselves, refusing with 409 NO_TABLE_AVAILABLE (carried through the POS bridge by code, never flattened into a 503) only when the venue HAS a room and none of it fits — a venue with no floor plan books exactly as before. A till edit that mentions no table KEEPS the tables the booking has rather than blanking them.

• Bokningar & bordskarta — the KOMPLETT redesign (2026-08-16, owner's 14-page PDF). The

dashboard's reservations page is rebuilt to the design, screen by screen, each one screenshot-compared against its page before landing. Server doors first (5ae3e1d5f): Reservation.checkedInAt/checkedInBy — ARRIVAL IS A FACT NEXT TO THE STATUS, never a fifth one, so every count and filter still reads exactly four (the noShow precedent), and arrival DELETES a standing no-show on both doors, in either tap order; the dashboard PATCH grew into the full edit door (check-in, VIP, inline guest/time/table edits) sharing the till's resolveTableAssignment room-check with the booking excluded from its own occupancy, refusing closed bookings with BOOKING_NOT_OPEN BEFORE any write; the till chain learned action: 'check_in' end to end; and the list route learned ?date= — a chronological day view plus dayCounts (incl. checkedIn and unassigned = the design's "Saknar bord" tab). Absent date returns byte-identical to before. Screens (988c715d1): the two-step Ny bokning wizard (p2/p3) reading the same availability and POSTing the same staff-create door as snabb bokning — "Föreslaget bord · Bästa passform", VALT BORD radio, ALTERNATIVA BORD, allergy folded into specialRequests through a tested composer; Alla bokningar (p5) with its date stepper, search, sort, Alla/Kommande/Sittande/Saknar bord tabs (Kommande derived on the LOCAL wall clock), azure BORD badges, .status-warn SAKNAR BORD rows and 14-per-page "Visar X–Y av Z"; and the p6 rail regime — the selected table's panel moved to the TOP of a rail widened to ~43% (the owner's explicit "the right panel is much wider in pdf" note), snabb bokning collapsing beneath it, Senaste aktiviteter + Bokningsinfo side by side. The p8 Bokning tab (61a23c812): inline-editable BOKNINGSINFORMATION rows submitting as ONE merge PATCH (probe-verified single call; allowOverCapacity only on the explicit "Utöka ändå" retry — the pull-up-a-chair act, stamped server-side), ANKOMSTSTATUS with Checka in / Ångra, confirm-gated Avboka that says when the guest is mailed, refusal codes rendering the dict's words. DELIBERATE DEVIATIONS from the mock, each with a reason: E-post became optional (the design says valfritt; StaffCreateReservationSchema now accepts '' and the recipient list already drops empties), and Skicka SMS ships visible but disabled — no SMS transport exists, and a button that silently does nothing is worse than one that says why.

• Mer-menyn + Beställ — the sales doors behind the design's actions (2026-08-16, `03791495f`).

TicketDoc gained covers/waiterName (doc-only, off the frozen domain-types IDL, like the park-era stamps beside them) with admin doors on the Betala-stamp pattern; the ticket-detail projection prefers waiterName over openedByName for the design's Servitör column and operator ids still never leave the server. Stäng bord voids ONLY an all-voided bill through a rev-pinned CAS — lines present refuse 409 TICKET_HAS_LINES naming Betala as the way, and a concurrent till resume makes the void lose the CAS rather than eat a bill that just gained lines. Slå ihop bord was promoted from scripts/merge-table-bills.mjs into a server operation keeping every script rule verbatim (earliest-openedAt survives, _mN line re-issue, fired ids remapped so nothing re-fires, absorbed bills VOIDED with mergedIntoTicketId rather than deleted, discount-carrying groups refused) — plus the refuter's catch: absorbed bills' kitchen cards now repoint to the survivor inside the merge transaction, so voiding a merged line still strikes the board. Beställ lets the dashboard order onto a table's nota through the SAME openTicket/addLine/fireKitchen doors a till uses — bound-bill adoption (never a second bill), kernel pricing, 86/serving gates, the allergen + modifier fold on card AND bong, post-commit bong, training isolation — idempotent on a client-minted opId so a double press cannot cook twice, and with ZERO tender/receipt/journal/stock/queue writes, proven by spec.

• Guest name on the tills, and check-in there too (2026-08-16, `6af50d022`, owner ruling). A

guest gives their name FOR the booking, so both tills now show it on booking rows and sheets; the PHONE stays off (the refuter found the Compose sheet still printing it — removed; find-by- phone and edit prefill stay, being the write flow and the background lookup key). Both tills offer Checka in for pending/confirmed bookings AND re-offer it over a no-show flag, so the server's heal is reachable from either surface; "Markera som utebliven" hides once a party has arrived; "Incheckad HH:MM" renders on day rows, find rows and sheets from the LOCAL wall clock.

• **Modifier allergens — the fold into the dish's line (2026-08-16, owner ruling "modifiers can

carry allergens").** A product OPTION can now carry confirmed EU-14 allergen ids (ProductOption.allergens; per-option chips in the menu editor's option groups, same ALLERGEN_REGISTRY as the product's own). THE MODEL IS THE OWNER'S: an option's allergens FOLD INTO THE DISH'S LINE — "Extra ost" makes the LINE contain milk; the cook reads the dish and the bong's allergen row stays per line, never a row per modifier. Where the fold happens, per rail: web/legacy orders at the write-time snapshot (snapshotKitchenAllergens unions the chosen options' facts by the new selectedOptions[].optionId/groupId the resolver now stamps — so the stored order keeps the union forever, R2a immunity intact); till fires / counter sales server-side in pos-sales where allergenChainOf already joins the catalogue item (new modifierAllergenIndex + foldModifierAllergens, threaded through the park/send fire, the explicit fire-kitchen door, the reconcile retry and the counter-sale bong — no new reads on the money paths); and the online→kitchen bridge now carries the LINE's stored chain (union-additive at ingest), closing the gap where a web order's option allergens never reached the native KDS board. Backend catalog: LegacyMenuDoc option allergens declared + modifierGroupFrom emits by key omission; CatalogModifier/ModifierGroupRead + admin upsert DTO widened. The kernel's applied-modifier wire is untouched (serde denyunknownfields). MIGRATION: nothing invents data — absent option fields stay absent (silence, never an "allergen-free" claim), no backfill; the first assertion an option ever makes is an owner saving it in the editor. Option-allergen corrections after order time do not reach live tickets (the read join stays product-only; the dish-level ceiling still rises).

• Bokningar & bordskarta — Phase 4: the tills get the desk's rules (2026-08-16). The three

POS surfaces (Compose Android+Windows via pos/app commonMain, pos/web) gain the dashboard's reservation intelligence with less desk chrome, every rule reached through the SHARED modules rather than re-derived: Nästa lediga on the till booking form (new device route GET /api/internal/pos/booking-suggest composing lib/reservations/suggest-table.ts over getAvailableSlots + sitting-aware occupiedTableIds; NestJS door GET /pos/registers/bookings/suggest, RegisterGuard) with a one-tap apply that sets time AND table; Flytta on the till's booking rows (a table-only full-state move through the EXISTING reservation-update → assign-table.ts CAS; refusals surface BY CODE — TABLEOCCUPIED / TABLETOOSMALL retryable with the over-capacity second tap / TABLENOTFOUND / BOOKINGNOT_OPEN — in the tills' own sv/en string tables, never the bridge's Swedish-only sentences); Senaste aktiviteter on the till table panel (new device route GET /api/internal/pos/ticket-activity reusing the ONE backend composer through the internal client and the SAME projection whitelist as the dashboard BFF; NestJS door GET /pos/tickets/:id/activity; compact last-6 + "Visa alla", honest verbs — "Klart i köket", never "Mat serverad", em-dash for stored-without-a-clock facts); and the identity QR on the till's förhandsnota paper (new POST /api/internal/pos/print-prebill + NestJS POST /pos/tickets/:id/print-prebill queueing the ONE förnota document — lib/devices/prebill-queue.ts, extracted from the dashboard's print route so both doors share the planner — restora:ticket:<id>, ^BQN on ZPL, caption fallback on ESC/POS; pos/web tries the server door first and falls back to the QR-less local-agent text). Deliberately dropped on the tills: zoom chrome, Kommande/Sittande tabs, deep Bokningsinfo (the 2026-08-16 call-out ruling — a panel opened in front of guests must not print who is coming).

• Bokningar & bordskarta — Phase 2: the table detail panel (2026-08-16). Clicking a

bordskarta tile now opens the full panel from the design (replacing Phase 1's stub card): header Bord N + state chip + guests·minutes, tabs Nota / Aktiviteter / Bokning. NOTA shows the live bill — engine-priced lines, Delsumma/Moms/Totalt as SERVER-rendered strings (new backend read GET /pos/admin/tickets/one, InternalGuard, live-bills-only 404; BFF GET /api/tenant/[tenantId]/pos/ticket with an explicit field whitelist — operator ids, customerEmail, internalNote and discount stamps never reach a browser). Betala is a hand-off, not a payment (owner ruling): it stamps the förhandsnota through the new ADMIN twin POST /pos/admin/tickets/prebill (dashboard-namespaced stamp, no settle/receipt/journal) and names the paired registers that can complete it via their existing claim + PaymentFlow. Skriv ut förnota prints through the existing DeviceJob queue (lib/devices/prebill-print.ts: FÖRHANDSNOTA/EJ KVITTO at 2× amount size, identity QR restora:ticket:<ticketId> a till scans to claim — never a payable link, no receipt number/VAT table/kontrollenhet). Dela nota is the split VIEW: lines assigned to parts, each part total ENGINE-priced read-only via POST /pos/admin/tickets/split-quote; every part is paid at a register. Flytta moves the BOOKING, not the bill — the room rule extracted from the till's reservation-update route into the shared lib/reservations/assign-table.ts (exists/fits/free-for-the-SITTING with seatingDurationMin, self-excluded) and served to the dashboard by POST /api/tenant/[tenantId]/reservations/[reservationId]/move (409 TABLEOCCUPIED / TABLETOO_SMALL with an explicit extra-chair override). AKTIVITETER is a Phase 3 stub. Dictionary: 48 ovPanel* keys, Swedish real, 19 languages English-fallback.

• Bokningar & bordskarta — Phase 1 of the reservations-overview redesign (2026-08-16). The

dashboard reservations page's flat list view is replaced by the two-panel overview from the design (azure tokens, not the mock's navy): LEFT a live bordskarta drawn with the SAME floor geometry as the guest picker (extracted to lib/reservations/floor-geometry.ts), tables coloured ledigt/bokad/sitter with the server-priced Nota <total> on seated tables, zoom controls, and a table LIST fallback below 768 px; RIGHT the SNABB BOKNING panel (party chips × Nu/önskad tid → next-free-table suggestion booked through the existing staff create route) over the Kommande/Sittande/Saknar bord booking list (amber SAKNAR BORD badge, confirm/reject/deposit actions preserved). New backend read GET /pos/admin/tables/live (InternalGuard, per-tenant 12 s cache over the same priceBasket path the till lists use; operator ids resolved to display names server-side and never shipped); new BFF proxies GET /api/tenant/[tenantId]/pos/table-board (explicit field whitelist + money rendered once via minorToSek+formatMoney) and GET /api/tenant/[tenantId]/reservations/availability (getAvailableSlots × occupiedTableIds × tableFitsParty composed in lib/reservations/suggest-table.ts — smallest fitting free table wins, ties on seats then name). Deposits/prep/calendar/settings/blocked tabs unchanged; table detail panel (betala/nota/aktiviteter) is Phase 2. Dictionary: ov* keys, Swedish real, others English.

• **Google Fonts is gone from the RUNTIME — no visitor's browser fetches type from a third party

any more (2026-08-16). Self-hosting on 2026-08-15 cured the BUILD (`next/font/google` had killed three production builds in four); it never touched the visitor. Nineteen files still shipped `<link rel="stylesheet" href="https://fonts.googleapis.com/…">`, two `preconnect`s to `fonts.gstatic.com`, or a CSS `@import` — so every guest who opened a receipt, an order tracker, a delivery slip, a storefront, `/bazar`, `/try`, `/wow` or the login page had their IP handed to Google before consenting to anything (the practice German courts have already awarded damages over, LG München I 3 O 17493/20), and every one of those pages only looked right while somebody else's CDN was reachable. All of it is now `@font-face` in `src/fonts/google-families.css` (172 faces, 41 families + the Material Symbols icon font), declared under the same family names** the CSS already asked for and imported once from the single root layout — so no font-family, --font-display/--font-body variable, tpl.displayFont or inline style changed, and nothing looks different. 65 new latin .woff2 joined the 15 already there, each with its gstatic URL, css2 request, byte count and sha256 in src/fonts/SOURCES.json and enforced by src/fonts/fonts-selfhosted.test.ts, which also now FAILS on any live fonts.googleapis.com / fonts.gstatic.com reference in src/ (comments still allowed — they are how the next person learns why it is absent). Deleted with it: TEMPLATE_FONT_LINKS, GENERATED_FONT_LINKS, buildGoogleFontsUrl() (the only runtime URL builder), every template's fontLink/fontLinks, and the builder API's fontLink field.

• The fiscal sweep — the missing half of "a paid order carries its fiscal record" (2026-08-15).

Round 20 wired the recorder into every paid flip and gave contention a durable carrier; the OPEN window was process death between the paid commit and the recorder's first attempt — no stamp, no deferral row, and on Swish the redelivered callback is acked by the webhook dedup store, so nothing ever re-runs the handler. The outbox relay's existing cycle now carries a sweep (lib/fiscal/se/sweep.ts): it FINDS paid orders still awaiting their record past a 5-minute grace window using the recorder's OWN gate (orderAwaitsFiscalSale, wire.ts — so training, non-SE, owner-disabled and unsupported-VAT absences stay legal by the same rules), HEALS them loudly through the same idempotent recorder (an order stamped in the meantime is never re-numbered), hands what cannot heal to the existing deferral carrier in the hash-chained integrity journal (once — never an infinite retry), journals sales older than the carrier's 48 h window for a human instead of minting backdated receipts, and SURFACES stranded Swish payments (id claimed in the dedup store, order never flipped) as payment.swish.stranded journal rows carrying the human runbook — journal + log only, never an auto-flip, because flipping paid without re-verifying with Swish would invent money. Rides the relay's tenant loop, so finding costs no extra reads; skipped on single-tenant hot-path nudges, exactly like the deferred-write drain.

• **A TILL SALE IS NOW ACTUALLY PROJECTED — the endpoint the backend has been POSTing to did not

exist (2026-08-13).** SalesService builds a projection payload for every closed ticket and parked bill and POSTs it to /api/internal/pos/till-order at settle time; that route was never written, so every dispatch 404'd, the dispatcher classified the 4xx as a definitive refusal and dropped it. A counter sale therefore became visible only if a human happened to have the dashboard Orders board open, whose 30 s poll did the projecting — a coincidence, not a pipeline. The route now exists (internal-secret authenticated, tenant-scoped, idempotent on re-post) and keeps four rules: it never mints a public number (a ticket carrying neither queue number nor löpnummer is refused 422, not numbered here), it copies money instead of computing it (totalMinor → SEK through the one conversion point), it carries ticketRev as sourceRev so a late park cannot overwrite the close that superseded it, and a PARKED bill projects active + payment pending — a held bill reachable from the guest's own tracking token must not read "paid".

• The projection stopped discarding the venue: `locationId` was hardcoded `'default'` (2026-08-13).

contextOf stamped DEFAULT_LOCATION_ID on every row, on the write path AND the read path (which wins the merge), so the audit stamp the order itself carries was never read back and a location-filtered pickup search answered 200 with an empty list at every venue of a multi-venue tenant — "no such order" rather than "misconfigured". Rows now carry the order's own stamp.

• The 30 s poll no longer rewrites the whole projection to store nothing (2026-08-13). Every pass

replaced a document allowed to hold 2 000 rows, once per open dashboard tab, because lastProjectedAt was rewritten every time and nothing compared the entries. The pass now diffs the ROWS (ignoring projectedAt, which is the eviction clock and changes by construction) and skips the write when nothing changed; an unchanged row keeps its stored projectedAt, so retention runs from the sale rather than restarting on every poll.

• A retryable refusal is retried instead of swallowed — all four consumers (2026-08-13). The 409

WRITE_CONFLICT introduced by the CAS guard says in its own body that nothing was stored, and every client had been written when a 4xx could only mean "the request is wrong": submitPosOrder DISCARDED the sale and told the cashier it was rejected, useOfflineOutbox DELETED the queued item, and both order boards let it fall through a >= 500-only gate as success — leaving an optimistic tick on screen for an order the kitchen was never told about. One shared classifier (lib/offline/retryable.ts) now decides, BODY-DRIVEN so a validation 400 / 404 / 402 stays final and the outbox cannot become a permanently stuck queue; a refused sale is queued with the SAME clientRequestId, a refused status bump is kept, and the replay budget is bounded — an exhausted item stays queued and visible (failed / retryFailed()), never silently dropped.

• The un-redeployable Android APK's timeout retry is idempotent server-side (2026-08-13). It sends

no clientRequestId, so a retry after a timeout was a second order: two public queue numbers, two kitchen fires, one guest charged twice. An IN-PERSON sale arriving without a key now gets one DERIVED inside the create lock from the request's own content (tenant, location, register, device, operator, type, table, tender, gift/canteen/loyalty refs, total, basket), replaying only within a 45 s window and recording a genuinely later identical sale under its own suffixed key. Customer channels are deliberately excluded — two guests ordering the same thing in the same minute is a lunch rush, not a retry. The collision this accepts, and why it is preferable to a double charge, is documented in lib/orders/derived-idempotency.ts.

• **THE MENU WRITE PATH IS NOW SERVER-AUTHORITATIVE — the browser was the only thing enforcing the

authoring rules (2026-08-13). `validateOptionGroups` (seven rules, 71 tests) and `findDuplicateProduct` both existed, both passed, and both ran in `ProductEditorModal` and nowhere else; `CreateProductSchema` accepted `optionGroups: z.array(z.any())` and the PATCH handler read `await req.json()` with no schema at all. So a curl, an older client, a second tab or a replayed request could author a nameless group (the till renders a blank heading), a malformed price ladder (nothing can decide which group sets the price), or a second identical dish — and did: the reporting tenant had both groups stored as `name: { en: "" }` and two Margheritas with byte-identical browser-minted option ids. `POST /api/tenant/[tenantId]/menu/products` and `PATCH .../products/[productId]` now call the same two checks through the new `lib/menu/product-write-guard`: 400 OPTION_GROUP_INVALID (with `issues[]`, each carrying its stable code, `groupId` and optional `optionId`, so the editor can point at the row) and 409 DUPLICATE_PRODUCT* (with the `id` of the item that already exists) — the two codes the menu page already renders. Refusals happen BEFORE the blob write and before the `menus` mirror write, so a rejected payload cannot leave the two stores disagreeing. Judged for what the write actually writes: an availability-only PATCH (the 86 flag, also sent by the support agent's action cards) is never refused over authoring debt it did not touch, while a `discountPrice` / `weighPricing` change on a product that already has a ladder is refused with LADDER_ only.

• `optionGroups` has a real schema (`z.array(z.any())` → `OptionGroupSchema`) (2026-08-13). The

one field whose contents decide what a guest is CHARGED was the one field nothing validated: an option with no id (pricing is id-addressed — resolveLine matches group + option BY ID, so an idless option has no price), a price as a string, an options list that is not a list, or an unknown pricingMode all parsed. Per-option imageUrls are now sanitised on the way in through sanitizeOptionGroupImages, which had been written with zero callers anywhere; group and option names are trimmed in EVERY language on save, which finally kills the live 'Smal ' (trailing space) that has been shipping to tills. ABSENCE STAYS LOAD-BEARING: a pricingMode of 'add_on' is accepted (an old or hand-written payload) and DELETED before storage, so an add-on group round-trips byte-identical and the literal is never written.

• **Every dashboard menu write now re-projects the POS catalog — a saved option group finally reaches

the tills (2026-08-13).** pos_modifier_groups has carried pricingMode/isDefault since the catalog work landed and its prune tombstones a deleted dish, but NOTHING on the dashboard write path ever triggered the projection: every TILL write re-projects, the menu editor never did. So the owner could author the price ladder, watch it save, and every register would go on selling the old shape — and a deleted dish stayed sellable. One named door (lib/menu/pos-catalog-reproject → POST /pos/admin/catalog/translate, tenant-scoped, idempotent) is now called after the blob write by product create / update / delete / reorder / move, category rename / delete / reorder, menu reset and AI menu import. Loud but never fatal: a backend outage is logged and the owner keeps their edit, exactly like the menus mirror beside it.

• **THE PRICE-LADDER OVERCHARGE IS CLOSED ON EVERY CUSTOMER CHANNEL — one basket, one price,

whichever button the guest presses (2026-08-13). `pricingMode: 'sets_price'` shipped on 2026-08-12 and the POS honoured it; the CUSTOMER channels did not. Each of them carried its own copy of the same fold — `optionAdjustment += opt.priceAdjustment` then `baseUnitPrice + optionAdjustment` — so the moment the owner used the control that had just shipped, their own website, kiosk and table-QR would charge 100 + 250 = 350,00 for a Familjepizza that costs 250,00*, and three of the four website doors CAPTURE that amount (Stripe / Adyen / PayPal) rather than merely invoicing it. Six copies are now ONE call: `priceQuoteLine` in `lib/menu/price-quote.ts` — a thin, id-addressed entry into `resolveLine`, the tier's only ladder-aware resolver (spec rule 2: lifted, never duplicated). Fixed at `api/public/[tenantId]/orders`, `.../payment-intent`, `.../adyen-order`, `.../paypal-order`, `api/public/kiosk/order` and `lib/tables/table-ordering.ts::priceGuestTableItems`. Per channel, base 100,00 + rung Familjepizza 250,00: before 350,00 → after 250,00; 2 × = 500,00 (was 700,00); with a 25,00 add-on = 275,00 (was 375,00); Smal 100,00 = 100,00 (was 200,00 — the clearest proof the amount is a price: adding it doubles the pizza). The rung rides the line at `priceAdjustment: 0`, so no receipt or bong prints "+250" beside the size. ABSENCE STAYS LOAD-BEARING:* a group with no pricingMode takes the untouched delta branch (100,00 + 25,00 = 125,00, and the add-on still shows as +25,00), a negative add-on still discounts (−5,00 → 95,00), and the literal 'add_on' is never written anywhere. VAT follows the price, per line and per rate: a 250,00 dine-in Familjepizza is netto 223,21 + moms 26,79 at 12 % (was 312,50 / 37,50 — output VAT over-declared by 10,71 per pizza), takeaway 6 % is netto 235,85 + moms 14,15 (was 330,19 / 19,81), and on a mixed bill the 25 % alcohol bucket does not move by one öre.

• **The guest's SCREEN can finally see the ladder — three menu feeds carry pricingMode (+

isDefault) (2026-08-13). A client cannot render a price it was never sent, so the kiosk showed "+250 kr" beside a 250,00 size and totalled 350,00 before anything was ordered. `kioskOptionGroups` / `kioskProduct` (`lib/kiosk/menu-payload.ts`), the storefront/marketplace item payload (`lib/bazar/restaurant-payload.ts`, new `BazarPayloadOptionGroup.pricingMode?: 'sets_price'`) and the table-QR / ITA menu feed (`api/public/[tenantId]/ita/menu`, which also gained `isDefault` so a required ladder can open on its default rung) now emit the mode — only** for a ladder, so an add-on group's document is byte-identical for every existing build.

• **The QR/website wire format resolves selections BY ID now, with the name path kept as a

documented fallback (2026-08-13).** Guest clients key selectedOptions by group NAME and value by LABEL, and a name is not an identity: on the tenant that reported this, both groups were stored with name: { en: "" } — under name matching, every paid selection in a nameless or renamed group is silently dropped, and a dropped ladder rung falls back to a base price nobody sells. The shared resolver now takes the group id as the key and the option id as the value when they are present, and falls back to any-locale name matching (with the cosmetic "(+…)" suffix stripped) for cached/in-flight clients. No wire-type change was needed — the existing z.record(z.array(z.string())) carries ids as-is. The PayPal rail gained the other half of this for free: it was matching English-only names with a (+$…)-only suffix strip, i.e. dropping every paid option on a Swedish-only menu.

• Onboarding step 3: the Terms checkbox now sits ABOVE the buttons (owner ask, 2026-08-12).

It rendered under the Back / "Start free 7-day trial" row, and the trial button is disabled={!acceptTerms} — so a signer-up met a dead primary action on the LAST step of signup with the reason printed below it, and on a short viewport the checkbox could be below the fold entirely, leaving nothing on screen to explain why pressing the button does nothing. Pure reorder inside the same footer (pt-3 → pb-3); the consent copy and the SIGNUP_LEARNING_DISCLOSURE sentence are unchanged. NOT verified in a browser yet — the local ui container serves ui/src from its image and does not bind-mount the source (see docs/infrastructure/LOCAL-STACK.md trap 5), and a rebuild would have baked in another session's in-flight edits. Verified by typecheck and by DOM order.

• A SIZE GROUP CAN SET THE PRICE NOW — "Prissättning: Sätter priset (ersätter grundpriset)" in the menu editor (2026-08-12). Reported live on a restaurant tenant created the same day: the owner authored a size group as ADD-ONS and typed the ACTUAL price of each size (100 / 125 / 150 / 250) against a 100,00 base price, so a Familjepizza would have rung up at 100 + 250 = 350 — a coherent price ladder typed into the only kind of group the product offered. The field was a bare number with a tiny literal + beside it, and nothing in the product ever said which of the two it was. `OptionGroup.pricingMode` (`'add_on'` | `'sets_price'`) is the whole feature, and ABSENT is load-bearing: an existing group carries no key, takes the untouched branch and prices EXACTLY as it does today (proved by a control test that deletes the key from the same fixture and asserts the old 350). 'sets_price' means the chosen option's amount IS the line price and REPLACES the base price. ONE number per option, deliberately — an option can never carry a delta and an absolute price that disagree, and the owner's live 100/125/150/250 become CORRECT the instant the toggle flips: no script ever rewrites a tenant's menu. In the editor: a fourth control beside Typ / Min / Max; choosing a ladder FORCES radio + required + min 1 + max 1 and disables those three ("En prisstege är exakt ett val."); the money column changes prefix AND label per mode (+kr / Tillägg vs the plain symbol / Pris, aria-label + title on the input); a ladder shows "Grundpriset kr100.00 används inte för den här gruppen."; and min="0" was REMOVED from the add-on field, because a negative add-on ("utan lök, −5 kr") is supported by the projection and by the kernel and this editor was the only thing forbidding it. The guest side is closed in the same change: lib/menu/price-quote.ts — the canonical quote path behind pos/orders, pos/quote, training receipts and the voice concierge — substitutes the ladder price on the LINE and records the chosen size with priceAdjustment: 0, so a Familjepizza quotes 250, sauces still ride as deltas on top (250 + 15 + 14.99 = 279,99), a malformed rung is ignored rather than invented, and weight still beats the ladder (the scale is the legal price). The kernel is not touched at all — a ladder is a SUBSTITUTION where the line is BUILT, exactly like a service-offer band price, so the rounding step count, the wire shape and corpus.json are unchanged.
• THE WARNING THAT WOULD HAVE CAUGHT IT — an amber banner in the group header with the mistake spelled out in money (2026-08-12). In an add-on group that is a single FORCED choice with at least two options, where EVERY amount is at or above the item's effective price (campaign price if one is running, else the base), the editor says: "Det här ser ut som hela priser, inte tillägg. Som tillägg skulle Familjepizza slå in på kr350.00 i kassan. Gör om till prisstege?" — with a one-click Gör om till prisstege that changes the MODE and applies the shape lock and does not touch a single number. The signal is deliberately narrow so it can never nag a genuine upsell menu: one option below the base price, an optional or multi-select group, a single option, or an unpriced item all silence it (each pinned by a test).

• AN OPTION GROUP CANNOT BE SAVED WITHOUT A NAME ANY MORE — least of all a required one (2026-08-12). Both groups on the owner's only pizza were stored as name: { en: "" }, which the POS projection shipped to the tills as the empty string — a required group whose heading is blank is a question nobody can read. Spara is now gated by one shared validator, ui/src/lib/menu/option-group-validate.ts (validateOptionGroups), and THE BROWSER IS NOT THE RULE: the same function is exported for the two menu write routes to run before any blob write (400 OPTION_GROUP_INVALID). Rules: R1 a group with options needs a non-blank TRIMMED name in at least one language (the editor is bilingual, so a filled sv with an empty en passes — and an empty group still being built is never nagged); R2 the same on a group that is required / min ≥ 1 / a ladder, kept as its own code so relaxing R1 can never silently relax the required case; R3 at most one ladder per product; R4 a ladder is exactly one choice; R5 every ladder option > 0 (a negative ADD-ON stays legal); R6 no ladder on a by-weight product; R7 no ladder on a product with a running campaign ("Avsluta kampanjen först…"). The offending group gets a red border and an inline message, the Alternativ badge turns red, and the footer hint names the first violation. Save also TRIMS every group and option name in every language, which fixes a live 'Smal ' that has been shipping to tills with its trailing space.
• ONE CREATE CANNOT BECOME TWO PRODUCTS FROM THIS DIALOG ANY MORE (2026-08-12). The owner created one dish and got two — and the till, which nothing had ever asked to re-project, still showed two after one was deleted. The editor's half of that: Spara was disabled by !canSave alone, onSave is typed => void so nothing awaited it, the page's saving flag was never passed in, and the dialog closed only in finally — so a second click on a slow network submitted the SAME payload twice (proved by the two mirror products carrying byte-identical browser-minted grp_/opt_ ids). Now ProductEditorModal takes saving, its button is disabled={!canSave || saving} with a spinner and Sparar…, and a NON-OK response keeps the dialog OPEN with the server's message in the footer instead of silently discarding the owner's unsaved edit. A button state is not the whole fix, so the 409 predicate is written and tested too (ui/src/lib/menu/duplicate-product.ts: same category + same trimmed case-insensitive name + same price, compared in minor units) for the write route to refuse the duplicate that a second tab or a slow network will always produce.
• "BETALA" IS A FULL-SCREEN PAYMENT VIEW NOW — `Betalning`, ~90% of the screen, the ORDER on the left and the money on the right, on all three surfaces (2026-08-12). Owner ask, verbatim: "see example for 'betala' a new UI/UX a big popup maybe covers 85%-90% of the screen maybe". IT IS A NEW SHELL, NOT A NEW PAYMENT ENGINE, and nothing inside the money path moved: the receipt number, the fiscal decision, the training-mode refusal, the gift-card precheck, the outbox envelope, the öre rounding, the terminal authorization and the split remainder are all exactly where they were (PaymentFlow.tsx / PaymentState.kt). Every figure on the screen is one the engine already rendered — Delsumma is the per-rate net the kernel's own receipt renderer prints under Netto, and the Moms rows are the engine's vatBreakdown verbatim, one row per RATE the basket actually resolved to, so a bill carrying 12% dine-in food beside 6% takeaway food shows two rows and never one. The left column reuses the same TicketLineRow/PosTicketLine the ticket panel draws, with the same tileTint dot keyed on the same product and the same lineKitchenStatus derivation off the server's own fired ledger, so Skickad 14:05 cannot say one thing on the ticket and another on the screen that takes the money. The chooser replaces a column of five tender buttons with `Kort | Swish | Kontant` in front of the amount plus one disclosure for the two exceptional tenders (Presentkort / annat), and every chip arms a door that already existed: card runs the authorization the tender step always ran, cash opens the keypad (the öre rounding and the change live there), and Swish opens its confirmation — record-only means the confirmation is not skippable, because a primary that booked it would record money on the word of whoever pressed a button. The card STEP was retired on both surfaces: it existed only to name the two card doors honestly, the chooser now does that in front of the amount, and the missing-terminal sentence is printed only when a reader is actually missing (with the external door opening itself). `Avbryt betalning` returns to the ticket with every line intact — a pure paymentCancelled transition that hands back the same lines array, so the promise is a test rather than a comment (payment-view.test.ts, plus a Compose UI test that mounts the tree, clicks the button and asserts the basket behind it survived); it is refused while a settle is in flight (the receipt number may be spent and the sale posting) and hard-refused while an authorization is unresolved, and it WARNS before dropping committed split parts because one of them may be a card the acquirer already authorized. Swedish + English, both surfaces, from the same key set.
• THE PAYMENT VIEW'S RED BOX SAYS SOMETHING TRUE, and it was verified against the code before it was written (2026-08-12). "Töm nota finns under Fler och kräver bekräftelse. Skickade köksartiklar får inte försvinna utan spårbar åtgärd: en nota som köket har fått ägs av servern och kan inte tömmas alls, och rader tas bort en i taget och stryks på serverns nota." Every clause was checked: the clear is under Fler on both tills and does ask (window.confirm on pos/web, a confirm dialog on the Compose tills); and firing food requires a SERVER ticket (sendKitchenRefusal(hasServerTicket=false) → 'no_bill', canSendToKitchen = ticket.serverTicketId != null && …), so a bill the kitchen has is server-owned and resetBlockedReason / TicketClearRule.refusal refuse the clear outright rather than merely confirming it — the promise the code keeps is stronger than the one the mockup asked for. The box is drawn only about a bill whose food the kitchen actually has; on a bill nothing was fired from the sentence would be true and about somebody else's order, which is how an operator learns to read past a warning.
• THREE THINGS IN THE PAYMENT MOCKUP DO NOT EXIST, AND THEY ARE INERT WITH THE TICKET PANEL'S OWN REASONS (2026-08-12). Rabatt (no till door and no capability — discount_override is a declared permission nothing reads), Intern anteckning (a ticket document has no note field at all) and Dela nota (nothing anywhere divides one bill into several notas). The sentences are reused verbatim from i18n/ticket-panel.ts / RegisterStrings rather than reworded, so one refusal wears one wording wherever an operator meets it — and they are printed under the controls, never in a tooltip a tablet cannot show. Dela betalning is real (split_tender) and is one tap from the amount. The mockup's − qty + and delete are deliberately not wired: the settle prices the basket the view was handed when it opened, so an editable stepper would charge the old amount for the new bill, possibly with a card already authorized against the previous figure — the column is read-only, says so, and the edit is one tap away.
• THE PAYMENT VIEW STACKS AT PHONE WIDTH INSTEAD OF CLIPPING, and the first cut of that genuinely did not (2026-08-12). Below the threshold the two columns become one with the money first — on the smallest surface the operator must not have to scroll a bill they have just come from to reach the primary. Measured against the SHEET (a container query on the web, BoxWithConstraints on Compose), never the viewport: the same component is a 1600dp station and a 360px phone. The first attempt kept CSS grid for the stack, and at 360px Chrome sized the two auto rows to 303px and 292px of the available 606px — a grid's default align-content behaves as stretch, and stretch applies to auto ROWS — so each column got half the sheet while its real content was 765px and 942px tall, and with the inner scroll wells switched to visible the money column's e-mail checkbox and split explainer painted straight through the order column's dish rows. Found by screenshot, not by reading. The stack is a column flex box now; align-content: start alone did not lift it. The big sheet also states box-sizing: border-box explicitly, because a min(96vw, …) width plus the sheet's padding is an overflow, and the last padded box that met a width with no box-sizing on this stylesheet family had 22px eaten off the right edge of every receipt row — where the MONEY column is.
• DISCOUNTS EXIST NOW — `RABATT 5/10/15/custom %` AND CODES LIKE `NEWYEAR2027`, LIMITED TO DAYS AND TO A USAGE COUNT (2026-08-12). BACKEND ONLY: the routes, the storage, the validation and the tests. No till surface calls them yet. Owner requirement, verbatim: "we forgot to add 'discount' buttons 5%, 10%, 15% custom discount %, discount code like NEWYEAR2027 limited to days, limited to quantity like first 100 usage etc.." — which is two features, and keeping them apart matters because one is a keypress by a trusted operator and the other is a guest-facing campaign with server-held state. THE KERNEL WAS NOT TOUCHED, AND THAT IS THE DESIGN. The money engine already prices six promotion types deterministically and identically on every surface, and a code is caller policy, never kernel surgery: a discount becomes an ad-hoc PromotionDef handed to evaluatePromotions, and not one line of this change computes money. A manual percentage is `percent_off_line`, deliberately not `basket_threshold`, for three reasons that are all money rather than taste: (1) THE BASE — basket_threshold takes its cut of Σ remaining + Σ deposits, so "10% off" a crate of bottles would be 10% of a number that includes the venue's own pant liability (asserted: 6 × (12,00 + 2,00 pant) at 10% discounts 7,20, not 8,40); (2) THE ALLOCATION — one truncated percentage PER LINE means each VAT group's taxable base shrinks by exactly its own percentage, where a basket figure split largest-remainder can hand a stray öre to a line in the other rate bucket; (3) THE PARAMETER — basket_threshold refuses to fire without a minBasketMinor, so a discount with no minimum spend would have to invent a fake 1-öre threshold, a lie in stored data that also declines to fire on a bill pricing to zero. A coded campaign may still be basket_threshold, because "100 kr off over 500 kr" is a threshold the owner meant. `discount_override` HAS BEEN A DECLARED OPERATOR PERMISSION SINCE PHASE 5 AND NOTHING HAS EVER READ IT — this is the reader, so a discount always has a name against it. Owner and manager pass regardless of the permission list, and that is deliberate rather than lax: because nothing ever read the grant, no operator record in any live tenant was curated for it, so requiring the permission alone would lock every owner at all four pilot venues out of the button the owner just asked for — and the "fix" would be a bulk write across pos_operators in live tenants. Identical reasoning to mayEditCatalog. THE CUSTOM PERCENTAGE IS CAPPED AT 50%, and the refusal says so in words instead of clamping silently: at 100% nothing is being discounted, the food is being given away, and a give-away is a comp — which belongs on the void path that already carries reason codes and an audit stamp. Anything in between is a manager decision this platform can express the day the existing pos_approvals machinery is wired to it (ApprovalReason.DISCOUNT_OVERRIDE is already defined and still unread). ONE manual discount per bill — re-applying replaces it, because two operators each pressing 10% must not silently produce 19% and "the discount on this bill" has to be one answerable thing for the Z-report. A DISCOUNT IS REFUSED ON A BILL THAT IS NO LONGER OPEN, with its own code and its own sentence: rates and totals are pinned at sale time, so a discount applied afterwards would rewrite a receipt the guest is holding; a parked bill is told to resume, because there is exactly one editable holder of a bill at a time. THE THREE TRAPS, each of which yields a wrong NUMBER rather than an error. (1) The venue's clock. days_of_week is read by the engine off the UTC fields of the sale instant, and 00:30 on a Saturday in Stockholm is 23:30 on FRIDAY in UTC — so a weekend code judged in UTC is live all Friday evening and dead in the small hours of Saturday. Each campaign stores its own IANA zone (validated by using it, never against a hardcoded list) and its window is evaluated through the one venue-clock evaluator, isRuleOpenAt, failing closed on an unreadable zone because a discount is a thing that costs the venue money. The kernel is untouched; instead the approved definition carries no `TimeWindow` at all, which is the subtle half — a window riding along would let the engine re-read it in UTC and silently drop a discount the server had already approved, between the quote and the charge. A redemption is decided once, in the venue's zone, and pinned for the life of the bill including one parked overnight. Pinned at the exact instant the trap fires, plus the summer case at UTC+2 so nobody replaces Intl with an offset table. (2) The usage cap cannot live in the kernel — the engine is pure and "first 100" is server state. Claimed by an atomic $inc whose filter carries the cap as a field-to-field $expr comparison, so the check and the increment are one indivisible act: the same shape as the order_counters fix that replaced String(1001 + countDocuments) after two concurrent reads minted one order number twice. matchedCount 0 is an honest refusal, not an error. The ordering is the rest of the answer: everything judgeable from stored data first, then the redemption ROW (whose partial unique indexes ARE the single-use-per-guest check, before the cap on purpose so the common refusal never writes to the hot campaign document), and last the claim, because it is the only irreversible act. session is a required parameter of redeem, not an optional one — so "what happens when validation fails after the increment" is nothing is compensated, because nothing was committed: claim, row and ticket write share one transaction and a losing CAS aborts all three. A compensating write was rejected as the primary mechanism because a compensation can itself fail; the only compensating path is the deliberate release of a mis-keyed code, guarded twice so a stray release cannot make room for a 101st discount. Two tills redeeming the hundredth code concurrently: exactly one wins, count lands on 100. (3) A discount now crosses TWO VAT RATES. On a real mixed-motion bill — 145,00 dine-in food at 120‰ beside 129,00 takeaway food at 60‰ — 10% off moves 1554 → 1398 in the 12% bucket and 730 → 657 in the 6% bucket, total 27400 → 24660, and Σ group grosses still equals the total to the öre. Both buckets, not one. FOUND AND FIXED WHILE IN HERE: a refund of a discounted bill was going to hand back the full gross. refundTicket reprices negated lines against today's promotions, where a ticket-carried discount would not have been; the engine is odd-symmetric, so passing the original ticket's own definitions makes the refund return exactly what the guest paid (−24660, both buckets reversed). Also: a campaign's TYPE could never be changed (the old money fields survived the patch and the coherence check then correctly refused them, with no way to clear them) — the update now $unsets the fields the new type ignores, and strips undefined from $set because the driver writes it as null and Mongo rejects one path named in both operators. OFFLINE: refuse the CODE, never the SALE. Single-use and "first 100" are server facts and a redemption replayed an hour later cannot be refused after the guest has left, so there is no queued form of one — SYNC_OP_TYPES stays a closed six-entry list, now pinned by a test so adding a discount op requires changing that case. A disconnected till still closes the bill at full price. No POS capability was minted (sell + the operator permission): a fresh capability needs a preset grant plus a backfill, and skipping that has twice removed a shipped feature from new tenants. Storage is two new pos-native collections rather than pos_promotions, because everything in that collection is fed to every basket by listActivePromotions — a code-gated campaign parked there would discount the whole restaurant and the code would be decoration. New: backend/src/modules/pos/discounts/ (the six-file module), sales/ticket-discounts.ts (the pure definition builder and the cap), and four specs — the mixed-motion VAT arithmetic, the campaign rules, the routes, and the offline op surface. Full record of what shipped vs what the spec said: docs/pos-rebuild/kampanjkod-design.md.
• THE TICKET PANEL CHANGES SHAPE WITH THE ORDER TYPE, AND EVERY LINE SAYS WHETHER THE KITCHEN HAS IT (2026-08-12). Owner mockups, two of them: a SERVERING panel (table heading, per-line kitchen status, "Skicka 1 ny artikel till köket", then Betala / Dela betalning / Dela nota) and an AVHÄMTNING panel (a På plats | Telefon second level, no table, no per-line status, then Betala & skicka → Skicka till köket – betala senare → Parkera köp). Plus the correction to the day's earlier work: `Välj bord` and `Kundnamn` share ONE ROW now — the first cut stacked them and the owner's complaint was space, on the narrowest column of the till. The shape is decided in ONE place per surface and rendered from that one answer by all four mounts (pos/web/src/screens/ticket-shape.ts + TicketShape.kt, twins, tested to the same table of cases): the Compose wide station and its compact phone sheet, the web ticket column and its optional side panel. A CTA list per shape, not three copy-pasted feet — the last control spelled out per-mount shipped on a tablet and not on a phone. THE PER-LINE STAMP IS A REAL ONE, AND THE LEDGER GAINED THE ONE FIELD IT WAS MISSING. Skickad 14:05 needs a time, and the fire time was recorded nowhere a till could reach: kitchenFiredLineIds is a bare string[], KitchenTicketDoc.firedAt is per BATCH in a collection no register reads, and the all-no-prep fire writes no kitchen ticket at all — so those rows had no recoverable time even in principle. markLinesFired now stamps TicketDoc.kitchenFiredAt (lineId → ISO) in the same statement, in the same transaction, by the same and only writer, so "did it fire" and "when" can never describe two different moments; fire-kitchen returns that same instant so the till never guesses one off its own clock; and the whole map already reaches every till through toView, so a resumed bill's rows say the hour the food actually left whichever till sent it. It is not a second notion of "sent" — the SET is still the only answer to whether a line has fired, and a stamp without a set entry can never make a rung dish read as cooking (pinned by test on both surfaces). Rendered through fmtClock / PosClock, never a substring: the stamps are UTC and a substring prints 12:05 on food that left the pass at 14:05 in Stockholm. A row fired by an older build says Skickad with no hour, which is true. `AUTOSPARAD` IS DRAWN ONLY WHERE IT IS TRUE, AND NO AUTOSAVE LOOP WAS BUILT. The badge is a claim about the SERVER: it appears exactly when the server already holds this bill (a parked bill picked up, a bill taken back). On a fresh basket with a table merely ARMED it is absent — that binding is local, nothing on the server has the lines, and badging that basket "saved" is how bills get abandoned: the §3d incident class, four real ones. Minting a ticket behind the operator's back to make the badge true was refused as an owner decision, not a side effect of a badge (showsAutosaved, with the reasoning in the source). `Parkera köp` is a real, pre-existing wire capability, not a second park: ParkTicketDto.fireToKitchen: false — "the bar-tab shape where nothing should cook yet" — which no till had ever sent. It is refused on a bill the server owns, out loud, because ParkExistingTicketDto has no such field and a re-park always fires. `Betala & skicka` and `Skicka till köket – betala senare` say so only where it is true: both depend on kitchen_routing AND the register's own auto-send toggle, the two gates the server itself applies, so a till with sending switched off shows the plain words and offers no send-and-park at all. What already existed vs what is honestly dead: Dela betalning EXISTS (PaymentFlow's own split step, split_tender) and is now one tap from the ticket via a new split payment entry on both surfaces; Rabatt, Intern anteckning and Dela nota exist NOWHERE in this product — no route, no service method, no capability, no screen — so each is drawn INERT with the reason printed beside it rather than omitted or wired to nothing. Fler is a container, not a new function: it holds the actions that used to sit in a second foot row, and two of them (Kvittokopia, Öppna kassalåda) were previously reachable only from the optional side panel that is off by default. The mockup's `3 gäster` was NOT built and was not faked — a party size is recorded nowhere on a POS ticket, and reading the nearest booking's guest count would be a guess about who is sitting there, so the sub-line states the table's own capacity in its own words ("4 platser"). Totals are the engine's: Delsumma is the per-rate net through the same net = gross − vat the kernel's receipt renderer prints under Netto, and the Moms rows are vatBreakdown verbatim — one row per rate the basket actually resolved to, never the mockup's hardcoded 12%, because per-line motion means takeaway food is 6% today. Singular/plural is the string tables' own business in both languages (1 ny artikel vs 2 nya artiklar), tested. New: ticket-shape.test.ts (17) and TicketShapeTest.kt (14).
• Fixed while screenshotting the new rows: every receipt row was 22px wider than the panel holding it, and the money was the part that got cut. .pos-ticket__line had width: 100% plus padding and a border with no `box-sizing` (the sheet has no global reset), so a 340px ticket drew a 362px row and .pos-ticket__swipe's overflow: hidden quietly ate the difference off the right edge — where the reserved amount column lives. Measured, not guessed: 278,00 rendered as 278,0. Also grid-template-columns: 1fr floored at min-content, so a long dish name held the first column open and pushed the amount out; it is minmax(0, 1fr) now, and below a 460px container width (the panel, not the viewport — the same ticket is 486px on a station and full-width on a phone) the row stacks so the controls take their own line. Money is never truncated; a name wraps.
• "SKICKA TILL KÖK" IS A BUTTON ON KASSA NOW, AND THE TABLE MOVED UP BESIDE THE CUSTOMER NAME (2026-08-12). Owner requirement, verbatim: "on PoS - can you also add a button 'send to kitchen' on 'kassa', move 'välj bord' to near 'kund namn' and instead add 'send to kitchen' beside 'Parkera nota'". The route already existed and no till had ever called it. POST /pos/tickets/:ticketId/fire-kitchen shipped with Phase 10b — its own comment has read "Skicka till kök" — fire a table ticket's unsent food lines ever since — but there was no caller anywhere in pos/app, and the only web caller was the Tables flow. So food reached a kitchen on exactly three exits, every one of which also did something ELSE: a paid sale's auto-fire, an atomic park, and a re-park. The consequence is the owner's own earlier scenario turned inside out — a course added to a bill the guests are already eating from could only be sent by parking the bill again, which takes it off the screen the operator is working on and out of their hands mid-service. This is that door, and it keeps the bill. A press syncs the basket's delta onto the server ticket (the re-park's own order: the fire sends the rows the SERVER holds, and the kebab rung ten seconds ago is not one of them), then fires, then reports what happened. THE CAPABILITY DECISION, and it is a deviation worth reading. Widening the route from kitchen_routing to sell was specified, considered, and REFUSED — the premise it rested on is false for this capability. kitchen_routing is labelled Köksbongar in the dashboard (ui/src/lib/pos/register-view.ts) and its catalogue entry reads "send lines to kitchen/KDS stations" (pos/shared/domain-types/src/capability.ts): it is the ROUTING grant, not a claim that a screen exists. Both the restaurant and quick_service presets grant it (VERTICAL_CAPABILITIES in integration.service.ts, and device-surfaces.ts), and the bong is PRINTED FROM the kitchen ticket this route creates — so paper is a subset of kitchen_routing, never an alternative to it, and a paper-only venue's selling till holds it. Decisive: all three existing fire doors are gated on this same capability, so a manual button on sell would become the one door that bypasses the venue's own Köksbongar switch — and KitchenDelivery (registers.interface.ts) already assigns the three refusals their own remedies, documenting auto_send_off as the state where "lines go to the kitchen only when somebody presses Skicka till kök" (this button) while not_granted is a dashboard fix and off_at_register is the till's own Funktioner switch. A button must overrule neither. No 403 ever reaches an operator: all three tills draw the control only when the session's EFFECTIVE capability set holds kitchen_routing, exactly as Parkera is drawn only on park_bills. The route's authorization is therefore unchanged (@RequiresOperator + @RequiresCapability('kitchen_routing')), the online-order ingest gate (hasKitchenRegister) was not touched, and no capability was minted — the trap that removed Parkera nota from new tenants twice. A BILL THE SERVER OWNS, deliberately — and the one thing this does not do. fire-kitchen fires a TICKET, and a fresh counter basket is not one yet; minting one on press was refused because it would turn the busiest screen's basket server-owned behind the operator's back (Rensa/Töm kvittot and Välj bord both go inert on that fact) and an open ticket is recoverable only from Parkerade's stranded-open list — the §3d incident class, four real bills. The counter basket already has two exits that fire (Betala, Parkera), so on it the control is drawn INERT with the sentence that names them; what had no door at all was the bill in the operator's hands, and that is what this is. THE COOKED-TWICE HAZARD, closed. The server MINTS a lineId for every row a sync hands it, and syncLines/syncResumedTicket threw that answer away — harmless while every caller emptied the basket straight after, fatal for one that keeps it: the next diff would find no match for any row, void every line the kitchen is cooking, and re-add them as brand-new work, because kitchenFiredLineIds names the dead ids. Both tills now read the line the add route has always echoed (AddLineResult.line), return it as a SyncedTicket { rev, serverLines, serverLineIds }, and re-key the basket — only the identity moves, so an offer snapshot, a recorded age check and a pinned rate all stay exactly as the operator rang them (a rebuild from the server document would have dropped serviceOffer). "Is there anything to send" reuses the existing notion of unfired lines — FOOD_BEV rows absent from the ticket's own kitchenFiredLineIds, now transcribed onto the wire types that already carried it (ResumedTicketDto, ParkedTicketDto, OpenTicketDto, ResumedTicket) — so nothing invents a second ledger and the control is live exactly when a press would do something. It reports the outcome, always, including zero: "1 rad skickad till köket", "3 rader skickade till köket · 1 rad behövde ingen tillagning", "Inget nytt att tillaga skickades" — rows that routed nowhere or need no preparation are counted apart from food a cook is making, because the server marks them fired too and the operator must not stand waiting for them. All three surfaces. Compose commonMain (Android + Windows): the table control moved into the ticket header directly under the customer-name field, refusal sentence and all, and TicketPanel's paired foot row is now Skicka till kök + Parkera nota — the 2026-08-07 comment pairing table+park is rewritten rather than overwritten, recording both decisions and why the new cut is the honest one (table and name are ATTRIBUTES of the bill; sending and parking are both DISPATCH). pos/web mirrors it in both mounts of the foot (the ticket column and the optional side panel), with the picker moved up beside the name field and the release control kept beside it. Bilingual on every surface (sendToKitchenAction plus four sentences in the Sv/En register strings; a typed pair in the web till's registerText), with "Skicka till kök" taken verbatim from the endpoint comment so three surfaces repeat one phrase. Outcome copy renders on the register's own notice stack in the brand Info tone — never Danger, which is what every other bill notice is — and is dismissed by hand, never on a timer. New tests: backend/src/modules/pos/sales/manual-fire-kitchen.spec.ts (8 cases — the gate is kitchen_routing and the bong alarm is still sell, a quick-service bill with no table fires, autoSendToKitchen: false still fires, the delta is the delta, and a non-food bill creates no kitchen ticket and never consults the ingest gate), SendToKitchenTest.kt (10) and pos/web/src/screens/send-to-kitchen.test.ts (11, against a new pure module so the shipped decision is the tested one).
• ONE GUEST, ONE BILL, TWO FULFILMENTS — and the correct VAT on each (2026-08-11). Owner requirement, verbatim: "if a customer comes and eat on the restaurant a pizza, then while he was eating and he ask to the restaurant to make the kebab plate so he can take with him to home. so when he will pay the both items together can be in same order." This is a money and tax fix, not a UX tweak: pos/core/src/tax.rs resolves the SE food rate from the line's MOTION, and the two rates differ today — food SERVED is 120‰ with no end date, while foodstuffs taken away dropped to 60‰ on 2026-04-01 (provisional through 2027-12-31, note P13). A till that could state only ONE fulfilment for the whole ticket therefore charged one of those two lines the wrong VAT, by a factor of two, on every mixed bill. The kernel and the wire always supported it (TicketLine.motion sits beside tax_rate_permille; AddLineDto.motion is per line and reaches the kernel unchanged) — what was missing was any way to CHANGE a line's fulfilment once it was in the basket, because this module has no update-line endpoint at all. New `POST /pos/tickets/:ticketId/line-motion` (SetLineMotionDto → SalesService.setLineMotion), which re-resolves the rate through the kernel's own rule and re-pins it on that one line. Re-resolving a pinned rate is lawful only on a still-OPEN ticket — taxRatePermille is documented as pinned at sale time so a closed ticket cannot move when the rate table does — so a closed, voided or parked ticket is refused loudly with its own code (TICKET_NOT_OPEN, and the parked case says to resume first) rather than through the generic status gate, because "the rate on a registered sale moved" is a fiscal defect and not a state mismatch. Only the MOTION dimension is re-resolved: taxCategoryId stays as it was pinned when the line was rung, so a menu edit since cannot silently re-classify a dish the guest has been quoted, and nothing computes a rate, a VAT figure or a total by hand. THE ALREADY-FIRED RULE, stated out loud: a line the kitchen has never seen changes freely; a FIRED line is work a cook may be holding, so it is refused LINE_ALREADY_FIRED until the operator confirms (force: true, the same idiom as DiscardTicketDto.force), and a confirmed change re-tags the matching kitchen line(s) in the same transaction (the voidLine pattern, so a till saying AVHÄMTNING over a station screen still saying SERVERING cannot exist) while deliberately printing no paper — a bong already on a rail cannot be recalled and an automatic second one is how a dish gets cooked twice, so kitchenUpdated is reported and the till tells the operator to speak to the pass. Transactional and re-reading in-session for voidLine's reason: markLinesFired bumps no rev, so the {rev, status} pin cannot see a fireKitchen that commits mid-flight. Deliberately not a void-and-re-add, which is what a motion change would otherwise have to be on a server bill: on a dish the kitchen already has, that strikes it off every board and enqueues a brand-new one, so a pizza the cook is holding reads as cancelled and re-ordered. Per-line `delivery` is refused (LINE_MOTION_VALUES = ['dine_in','takeaway']) — a courier collects a whole order — and no capability was minted: sell, which every selling till already holds, because a fresh one needs a preset grant plus a backfill. All three tills. Compose commonMain (Android + Windows): PosSwipeToReveal grew a START-edge strip (PosSwipeSide), sharing the axis lock, the 8dp floor — not touchSlop, which is ~0.1px for a mouse and would cancel clicks on Windows — the tween, the rubber band and the one settle rule with the left swipe, so a right swipe on a ticket row uncovers the fulfilment choice while left keeps the delete; nesting a second wrapper would have put two pointer handlers on one row to fight over the same drag. PosTicketLine grew a pressable fulfilment chip showing the row's own word — always drawn, unlike the hover-revealed trash, because it carries information as well as an action and because it is the non-drag path on a mouse-driven Windows till. pos/web mirrors both in TicketPanel.tsx (SwipeSide, a start strip, the same chip) with the tokens in theme.css. Bilingual on every surface (chooseFulfilment* / fulfilment* in Sv+En register strings; a typed registerText pair on the web till), and a desktopTest reads LINE_MOTION_VALUES out of the backend source so the sheet cannot offer a fulfilment the server refuses. The bong tags each line — one bong per fire, not two, because it is one guest and one bill and the pass must see it together: buildKitchenTicketSegments prints 1 x Kebabtallrik [AVHÄMTNING] beside the name, only when the order carries more than one distinct fulfilment (judged over the WHOLE order, never the station-filtered subset, so a mixed order split across two stations keeps the tag on the bong of the cook who has to find a box). An unmixed bong is byte-identical — the PINNED.kitchen / PINNED.kitchenNoStation digests were re-derived by rendering the pin's own fixture and reading the output, and came back unchanged, which is the evidence a pin exists to produce. motion travels to paper on both till paths (TillKitchenFireLine/TillFireLine for a fire, TillPrintLine/TillSaleLine for the atomic counter sale) and is additive on OrderItem; the RECEIPT is untouched because a mixed bill's money already states it — priceBasket groups VAT per rate, so 12% and 6% print as two rows (SKVFS 2014:9 7 kap. 1 § j), verified end to end. New tests: backend/.../line-motion.spec.ts (17 cases, including the money one — 145,00 dine-in + 129,00 takeaway = 274,00 with 15,54 VAT at 12% and 7,30 at 6%, against 13,82 had the takeaway line been taxed as service), the mixed/unmixed bong cases in kitchen-bong.test.ts and till-print.test.ts, and LineFulfilmentTest.kt.
• A kitchen bong that fails to print now ALARMS on the till, with one-tap reprint (2026-08-11). Decision 2 of docs/pos-rebuild/kitchen-fulfilment-design.md, promised on 2026-08-11 and unbuildable until that same day added the mechanism (DeviceJob.kitchenTicketId). A restaurant may run paper as its only kitchen surface — the owner's small pizza shop that takes the order, gets a bong, makes the pizza — and for that venue a bong that never printed is a lost order with no screen to fall back to. Until now its only trace was a red row in a dashboard job log nobody at the counter is looking at. Terminal failures only: kind === 'kitchen-ticket' + status === 'failed' + not mock + not acknowledged — 'failed' is set only once a job is out of MAX_JOB_ATTEMPTS, so a job still retrying is not yet an alarm, and a MOCK (unclaimed) device is excluded for the reason printer-health.ts already states: storing its job IS its execution, so it cannot fail and carries no signal about hardware. Naming the order was the hard part, because three producers carry three different handles: a till FIRE (kitchenTicketId set, orderId a synthetic till_fire_<id> that resolves to no row), a till COUNTER SALE (till_<receiptNumber>, and no ticket id at all — a venue with no kitchen_routing register mints no pos_kitchen_tickets document for a counter sale, which is precisely the paper-only case), and a legacy ORDER (the only family that can also be asked for its table). orderNumber is already the human name in all three, so the row reads off that and reports the FAMILY rather than inventing a table the job never carried. Reprint re-plans through whichever planner owns that bong's lines, and the SERVER picks so a till cannot ask for a weaker path: a fire goes through the existing reprintKitchenTicket → planTillFireJobs (reprint: true — stored kitchen lines, voided ones filtered, and it refuses a cancelled or training ticket, a check nothing on the legacy side can make); a legacy order through planKitchenTicketJobs, the same call the KDS board's Skriv ut makes, marked OMTRYCK / REPRINT on the note row and filtered to the printer that lost it (the others printed their share; a second copy on a rail that is not missing one is a dish cooked twice); a counter sale re-queues the failed job's own rendered bytes through the same newDeviceJob producer — byte-identical is the strongest possible "cannot diverge", and nothing printed, so it is the FIRST paper rather than a duplicate. A double press queues a SECOND bong, deliberately, and is not deduplicated — a human pressing again is saying the paper still has not appeared, and the design's rule is that a human asking for paper always wins: one extra bong costs a cook a glance, a suppressed one costs the guest their dinner. bongReprints makes it visible ("Omtryck skickat 2 ggr") instead of silent. Reprint does NOT acknowledge, because paper being queued is not paper being seen and a printer that failed three times can fail a fourth; only Kvittera removes the row, it is a server write (a local dismiss would clear the alarm on one till and leave it standing on the next), and it is terminal. Three additive `DeviceJob` fields (bongAckedAt, bongReprintedAt, bongReprints), all derivation pure and unit-tested in the new lib/devices/kitchen-bong-alarm.ts (19 tests), reusing printer-health.ts for the per-device failure count rather than counting the same thing twice. Transport is the internal channel the tills already use for print settings: GET/POST /api/internal/pos/kitchen-bong-failures (ops ack | reprint | stamp) behind x-internal-secret, proxied by the new KitchenBongAlarmBridge to GET /pos/kitchen/bong-failures + …/:jobId/ack + …/:jobId/reprint. Those three routes are gated on `sell`, never `kitchen_routing` — a paper-only venue holds no register with that capability, which is exactly what makes it paper-only, so gating on it would hide the alarm from the one venue it was built for — and carry no `@RequiresOperator()`, same posture as the board's Skriv ut: the person looking at a printer that produced nothing is whoever is standing there. No capability minted (no preset grant, no backfill — the trap that removed Parkera nota from new tenants twice), and nothing in the kernel, the receipt series, the fiscal signer, tender rows or stock is touched: a reprint is paper, not a sale. Unlike the print bridge next to it the alarm bridge throws rather than swallowing — an empty banner on a till whose kitchen was never told is the exact silence this feature ends, so a failed read renders "Kan inte kontrollera köksbongarna just nu" and only a 403 (a paired kitchen display with no counter) stays quiet. All three tills: Compose commonMain (data/BongAlarmRepository.kt + screens/BongAlarmBanner.kt, placed in PosApp.kt's shell column under TillTopBar and above the rail so it shows on every destination, 15 s poll, one chime per NEW failure through the existing order-alert plumbing, bilingual via BongAlarmStrings/SvBongAlarmStrings/EnBongAlarmStrings, clocks through PosClock and never a timestamp substring — the server stamps UTC and a substring prints 16:42 on a bong lost at 18:42 every summer) and pos/web (data/bong-alarm.ts + screens/BongAlarmBanner.tsx in Shell.tsx, with a typed bilingual `i18n/bong-alarm.ts` and its own locale guard, deliberately not adding to the hardcoded-Swedish defect in the newer web panes). Colour is the design kit's DANGER family on both, never the amber warn family: the brand is azure, amber reads "heads up", and this reads "food is not being made". Neither surface blocks selling — no dialog, no overlay, no focus trap, and nothing rendered at all when there is nothing wrong. Still not told, and stated rather than designed around (full list in the design doc's new § The failed-bong alarm, as built): a bong that was never planned (no printer registered, paper channel off) produces zero jobs and so cannot alarm; a mock printer never alarms; a fire whose kitchen ticket has been purged is refused rather than falling through to the stored bytes, because only the ticket knows the order was cancelled; and the stored-bong reprint carries no OMTRYCK mark.
• The kitchen DELIVERY POLICY — screen, paper, or both, per venue and per order source (2026-08-11). Owner requirement, verbatim: "even if the kds is switched off the order will still [be] made — think like a small pizza shop [that does] not have the KDS… then some restaurants do have KDS both digital and pap[er] (bong) flow active… that module should cover all thinkable scenarios out of the box." Until now one question had one answer for two different things: whether there is work to be done, and how the kitchen hears about it. `settings.kitchenDelivery` (deep-partial, resolved at read, lib/orders/kitchen-delivery.ts) separates them. Precedence is per CHANNEL, not per object, so bySource.thirdPartyDelivery = { screen: false } still inherits paper — "delivery cooked and printed but off the board" is one toggle. The source vocabulary is the existing DisplaySource keyed by classifyOrder(), so all 21 Order.source values already map, the TABLE still decides counter-vs-waiter, and an unmapped source still fails open (and cannot be overridden). The policy never gates a write: a kitchen ticket is the venue's kitchen journal and the reason a guest has a queue number, so it is minted for cookable content whatever the policy says — only delivery routes are governed. Paper's venue-wide default was deliberately NOT moved: it stays settings.printing.autoKitchenBong, the field the tills already write through POST /registers/print-settings, so that shipped three-surface switch keeps its full meaning (it moves the default every non-overridden source inherits) and needed no change on Web, Android or Windows. There is no `kitchenEnabled` — "does this venue make food" and "is the screen pipeline available" have opposite correct failure directions, so screen availability stays the register's kitchen_routing and paper availability stays hasKitchenPrinter, and a venue that wants neither channel simply turns both off. Defaults are derived, never backfilled: with the setting absent every source screens and papers iff autoKitchenBong !== false, i.e. exactly today. Enforced at dispatchHardwareForOrder (one paper decision for all four of its callers), planAcceptedKitchenBong, both till paper paths, and the legacy KDS board — where the screen filter deliberately never touches unaccepted orders, because that board is the only accept surface a paper-only venue has and filtering them would make a settings toggle un-accept the venue's orders. The till's own sale-print path keeps printing for autoKitchenBong === false venues (kitchenPaperForTillSale), including the table-bound sale that an earlier draft of this design would have silently silenced. Surfaces: a card at the top of Köksrouting (archetype picker Papper/Skärm/Båda/Ingen with a derived Blandat, the two channel masters, honest read-back for a missing printer or a till that reaches no screen, and a per-source table with an explicit Ärver state), mirrored read-only with a deep link in Devices → Köksskärm and in the Printers panel. Its own PATCH /api/tenant/[tenantId]/pos/kitchen-delivery with a deep merge, because the generic settings PATCH shallow-merges and would drop bySource. No capability minted — tenant settings behind settings.edit. Known limitations recorded in docs/pos-rebuild/kitchen-fulfilment-design.md § What actually shipped: paper has no deferral (a 19:00 pre-order prints at acceptance), the rebuilt NestJS KDS board does not honour the screen channel yet, and the promised till-side failed-bong alarm was not built (its missing mechanism, DeviceJob.kitchenTicketId, was added) — the alarm landed later the same day; see the entry above.
• Tills can take a REAL Stripe test-mode card payment now, behind a switch that cannot lie about the fiscal signer (2026-08-11). Owner ask: "i was using stripe (test) to test the full flow so card payments can be applied. i want that also in PoS… i dont want to use mock but the real test flow so we can test everything without dead-ends". Before this the till's card tender was a mock — PAYMENT_MODE=emulator on the box unconditionally selected a random ~85%-approve simulator, and no Stripe code in the repo was reachable from a till at all. What landed: (1) `StripeCardProvider` behind the existing `PaymentProviderPort` (backend/src/modules/pos/payments/providers/stripe.provider.ts) — real test-mode PaymentIntents over Stripe's REST API, real pi_… references in the Stripe dashboard, real brand/last4 on the tender row, and nothing marked SANDBOX/EMULATOR because nothing is simulated. It refuses loudly when unconfigured, derives its mode from the key prefix (sk_test_ → test, sk_live_ → live, unrecognised → unconfigured), and refuses a LIVE key outright: it confirms Stripe test card tokens, so it is not a card-present rail and cannot become one by swapping a key. Non-card errors and requires_action/processing throw rather than reporting a decline — a decline is a promise that no money moved — and every message it surfaces passes through a redactor, because Stripe quotes a bad key back only partially redacted. (2) A new per-tenant go-live switch `cardRail: off | test | live` (default off, platform document pos_card_rail, super-admin only, audit row written in the same save) with its own section on /admin/dashboard/pos-operating-mode. It is deliberately a second document, not a third value on `pos_operating_mode` — that switch conflates the acquirer with the Swedish control unit, so "let me test card payments" would silently also have bought a fake kontrollkod, which is precisely the POS_FISCAL_SE_MODE defect this platform removed. POS_PAYMENT_PROVIDER=stripe is refused, the same doctrine that keeps the control unit's simulator out of its env-selected map: an env var that can switch on a money rail is a second door around the audit trail. (3) A Swedish capture is now refused BEFORE the card is charged when no control unit covers SE (409 CONTROL_UNIT_REQUIRED, till copy leading with "Kortet debiterades INTE") — without it a test-mode capture succeeded and the gated /close then 409'd, charging a guest for a sale the platform will not receipt, which is the exact harm the market gate was moved in front of the capture to prevent. Refusal order, tested end to end: market → card rail → control unit → provider-config → provider; refunds stay ungated on every one of them. Flipping the rail to live still implies nothing about the fiscal signer, and Sweden still cannot complete a real sale without a certified kontrollenhet — the refusal now names the three honest alternatives instead of appearing to work. Full trace in docs/pos-rebuild/till-card-payments-design.md.

• Every card sale ever taken on the web till was invisible to settlement matching (2026-08-11). payCardFull() settled with no providerRef, provider, cardBrand or cardLast4 and SaleTenderPayload had no fields for them — even though POST /payments/terminal returns all four and TenderInputDto already accepts and persists them. The reconciliation engine reports any card tender with an empty providerRef as no_provider_ref: unmatchable against the acquirer's payout file, forever. All four now ride from the authorization onto the tender, and each split part carries its own acquirer answer (sharing one would point two tender rows at one settlement row). Same pass: the terminal reference is a real ulid() instead of pos_<Date.now()> — not merely undocumented, but non-unique across two tills tapping in the same millisecond, and this value is the acquirer's idempotency key on every retry of one physical payment. Still open: the Compose till (Android + Windows) has the identical defect one layer down — it parses all three fields and then drops them at LiveSaleGateway.kt:176, where CardAuth.Approved maps onto a payload-less TerminalOutcome.Approved.
• `STRIPE_TEST_MODE` read as set and did nothing (2026-08-11). The code checked === '1' while .env.example, DEPLOY.md, knowledge/ui/modules/billing.md and check-readiness.mjs all documented and emitted true — so every deployment that followed the documentation set a flag with no effect, and test mode worked only by the accident of an sk_test_ key prefix. Both spellings (plus yes/on, trimmed, case-insensitive) are honoured now, check-readiness.mjs reads it as a flag rather than comparing it to "true", and a test fails if anyone reintroduces the single-literal comparison. A flag that reads as set and is not is worse than no flag.

• The till's payment-emulator env is `POS_PAYMENT_EMULATOR`, not `PAYMENT_MODE` (2026-08-11). The old name sat one letter from the web tier's PAYMENTS_MODE and the infra audit repeatedly read the two as duplicated drift. They are not duplicates and must never be merged: this one selects the till's mock card reader inside NestJS, that one is the Next.js payment kill switch, and unifying them would couple a dev/QA convenience to a production kill switch across two runtimes. The rename ends the confusion; pos/payment-emulator/README.md now says so where a future audit will look. The old name still answers for one release (the staging box's docker.env carries it) and logs one deprecation warning at first use; check-readiness.mjs warns on it, and on POS_PAYMENT_EMULATOR being set at all, since it overrides every tenant's sandbox flag and card rail.

• A dead printer no longer looks identical to a working one (2026-08-11). We are about to let a restaurant run paper as its ONLY kitchen surface, and the Hardware & Devices panel (PrintersPanel.tsx) could not tell an owner whether that paper was actually printing — the job log rendered kind/order/time but silently dropped status, attempts and error, all of which the API already returned unfiltered (GET .../hardware/jobs and .../hardware/devices were never the bottleneck; the fields simply weren't read). Three additions, all client-side, all sourced from data already fetched: (1) per-job outcome — every job in the log now carries a status pill (Utskriven/Köad/Skriver ut/Misslyckades/Förhandsvisning), the attempt count out of MAX_JOB_ATTEMPTS while a retry is live, and the agent's error text under a failed job; failed rows get a status-danger-toned background so they read at a glance without opening each one. (2) A failed-count banner at the top of the panel, present only when countFailedJobs (new, lib/devices/printer-health.ts) finds an unresolved failure, absent entirely otherwise. (3) "Har aldrig skrivit ut" — the never-accepted-a-byte state, the single most valuable signal for a shop planning to run on paper alone: a device that has an agent claimed (RW-3) but has NEVER had one real job reach 'done', distinct from "worked before, the last job failed" (failing). Mock (unclaimed) devices are correctly excluded — their jobs are always recorded 'printed' the instant they're created (storing IS the mock's execution), so they carry no signal about real hardware and are labelled simulated, never flagged. All derivation lives in the new, dependency-free lib/devices/printer-health.ts (computePrinterHealth, groupJobsByDevice, countFailedJobs — 9 unit tests, structurally typed with zero imports from registry.ts/dispatch.ts so it has no surface into either module) — nothing in lib/devices/registry.ts or dispatch.ts was touched. The panel's job fetch widened from limit=40 to the route's own limit=100 cap for better "ever" coverage; no new endpoint, no new polling. Colour choices follow the existing status-* token vocabulary (globals.css), never Tailwind's amber-*/orange-*/yellow-* families (brand-remapped to azure) — the same pattern AttentionBar.tsx and the tables floor-plan already use. Swedish copy matches the panel's existing kitchen-bong/test-print strings; the panel's older headings ("Recent print jobs", "Devices", "Add device") remain English — a pre-existing inconsistency, not swept here.
• The Customer Order Display finally tells the truth about the whole venue, and the owner decides what it shows (2026-08-10). Root cause of the owner report ("SSK orders show, counter POS orders never do"): the public queue feed read ONLY the legacy tenant-blob db.orders[], and a rebuilt-till counter sale lives in pos_tickets/pos_kitchen_tickets and never touches that array — a structural split, not a filter (docs/pos-rebuild/customer-order-display-routing.md has the full trace). What landed: (1) counter sales now board — a new internal POS projection (GET /pos/admin/display/queue, till-fired kitchen tickets → accepted/preparing/ready via the same read-time derivation history uses) merged into BOTH display feeds (/api/public/[tenantId]/live-orders + the paired-TV feed), fail-open so a dark POS backend costs one poll's till entries, never the board. (2) One public queue number for kiosk AND till — recordSale draws from the SAME per-tenant sequence every kiosk/web/QR order uses (new internal allocation route bumping db.orderNumberSeq under the tenant lock — numbers cannot collide across devices), stamped on the ticket, the KDS card (orderRef — cooks stop seeing "Direkt"), the printed receipt's Ordernr and the till done screen; fail-open, training sales excluded. The test123-shaped "order numbers" were never a generator: counter sales had NO public number, so surfaces showed the fiscal receipt series (free-text prefix, test-harness registers in the shared dev DB) — receipts keep their fiscal number, guests now get digits. (3) Owner-configurable visibility (settings.liveOrdersDisplay.visibility, deep-partial + resolver = recommended defaults with NO migration): master switch (hides all, preserves toggles, board falls back to welcome state), quick service (kiosk / counter POS / eat-in / takeaway-pickup — all default ON), table service (waiter / table-QR — default OFF: the waiter serves the table), remote (direct online pickup ON, third-party delivery OFF). Evaluated per poll by ONE canonical policy (lib/orders/display-visibility.ts) — never persisted on an order, so toggles apply on the next 4–5 s poll, and KDS routing reads none of it (hiding an order can never keep it out of the kitchen). A POS can create counter OR table-service orders — classification uses the actual data (dine-in WITH a table = table service), never source alone. Visibility PATCH requires settings.edit, audits old→new to the activity log, and the admin panel groups the toggles by workflow with a reset-to-recommended confirm. Deliberate behaviour changes: waiter + accepted table-QR orders stop appearing until enabled (they showed before), third-party ingests stop appearing by default.

• The green status chip was never legible, and nothing could have told us (2026-08-11). --status-ok-ink (#12905a) measured 3.63:1 on its own --status-ok-bg wash and 4.07:1 bare on a white card — under WCAG-AA's 4.5 for normal text, and the chips render at 10–12px. It was the only one of seven status families to fail, in either scheme (the rest measure 5.1–12.1:1), and it surfaced only because the new printer-health states lean on that palette. Ink darkened 13% at the same hue to #107d4e → 4.61:1 on the wash, 5.17:1 on the card; --status-ok-solid is deliberately untouched, since it is consumed only by .status-dot-*, a non-text component whose threshold is 3:1 (it gives 4.07:1). The durable part is lib/theme/status-contrast.test.ts: it parses the real token declarations out of app/globals.css (not a copy, which would drift), alpha-composites the translucent dark washes over --color-card because measuring the rgba() as if opaque reports a ratio no eye will ever see, and asserts AA for every family in both schemes — including a guard against the parse matching nothing and passing vacuously. Verified to bite: restoring the old value fails exactly two assertions with the ratios above. This is the 2026-08-06 defect class ("almost unreadable text", found at 1.30:1 and 1.21:1 the moment someone computed instead of grepped) turned into a test.
• A paper-only restaurant could not receive a web order on paper AT ALL (2026-08-11). The owner's archetype 1 — a small pizza shop that takes the order, gets a bong on paper, makes the pizza — was broken end to end, not merely ungoverned. A venue running no register with the kitchen_routing capability got: no kitchen ticket (the online→kitchen ingest refuses outright on hasKitchenRegister), therefore no till-side accept to tap (the till resolves an online order through that online_<orderId> ticket), and nothing at all from the dashboard accept — PATCH /api/tenant/[tenantId]/orders/[orderId], the only accept surface that venue has, contained no kitchen dispatch call. So a REGISTER capability ("is there a screen?") was transitively deciding whether PAPER happened. Fixed by separating the two questions: paper is now decided by the venue's hardware alone (hasKitchenPrinter + the new pure planAcceptedKitchenBong in lib/devices/dispatch.ts — nothing in that path reads registers), and the dashboard accept dispatches the bong exactly as the till accept has since the acceptance split. The bong still fires at ACCEPT, never at creation (owner, 2026-08-01: an online order is not the kitchen's until a human accepts it) — creation's skipKitchen for guest channels is untouched. One bong, from any surface: the new shared crossesKitchenAcceptance predicate (lib/orders/kitchen-accept.ts) keys off the same persisted acceptedAt the till's replay guard uses, so a double-tap, a till accept that already printed, and an offline-outbox replay all print once — and it keys off the status rank, not the word 'accepted', because the outbox collapses accept→preparing→ready into one PATCH and a word-match would silently lose that kitchen's paper. A screen-only venue is byte-identical (zero jobs), a both-channels venue gets both, printing.autoKitchenBong === false still suppresses the automatic print on this path too, and a venue with no kitchen printer loses nothing — the order sits on the dashboard and legacy KDS boards (both read db.orders, needing neither register nor printer) with its status advanced, and the skip reason is now logged instead of swallowed. No new POS capability minted (no preset grant, no backfill — the trap that removed Parkera nota from new tenants twice) and the backend ingest gate is deliberately unchanged, so no shop/salon tenant starts accruing kitchen tickets. Still out of reach and stated rather than designed around: paper has no deferral and this codebase has no scheduler, so a paper-only venue accepting a scheduled pre-order prints the bong immediately, not at the serve time.
• Unpaid waiter orders finally reach the cook board (2026-08-10). The 2026-08-09 "never the kitchen" fix set autoAccept for waiter/POS orders, but the backend gate demanded paid too — and a waiter's dine-in order is unpaid by definition (the guest eats first), so it stranded on the FOH view awaiting an acceptance step that does not exist in that flow. New explicit staffOrigin flag on the kitchen ingest: staff-placed orders fire unpaid; guest channels (web, QR, unpaid kiosk) never carry it and keep the anti-prank accept gate unchanged.
• Manual dashboard orders could mint the same public number twice (2026-08-10). String(1001 + countDocuments) raced (two concurrent creates read the same count) and counted the POS read-model rows the relay upserts into the same collection. Replaced with an atomic per-tenant $inc counter (order_counters, unique-indexed, seeded once from the legacy count so numbering continues where it left off).

• The dashboard was blind to what a till had switched off — one PIN tap could stop every kitchen ticket and nothing outside that touchscreen said so (2026-08-11). Owner report: "we added yesterday on/off toggles for which orders will go to KDS — i am not able to find those options under windows PoS or Android PoS, not even on restaurant admin panel." The toggles are real and they work; they live on the till, and the Devices page could not read a single one of them, which is the worse half. RegistersService.toView — the projection behind GET /pos/admin/registers — stopped at capabilities + capabilityRev. disabledCapabilities, the subtract-only layer a manager writes at the counter (Inställningar → Funktioner, PIN required), was projected only to /registers/me, so the fleet panel reported Ordrar/Bord/Presentkort as present on a register where the venue had switched them off: a "granted" tab that is visibly absent, with nothing on the page that could explain it. And autoSendToKitchen — per register, defaults ON, settable only from the till's own Inställningar → Kök — appeared nowhere under ui/src at all, which is exactly why the owner could not find it. Additive projection (no write path, no resolution semantics and no new capability touched — the venue layer stays subtract-only, pinned by test): RegisterView gains disabledCapabilities, effectiveCapabilities (granted − disabled, the same shared resolver RegisterGuard applies to every route, so an admin screen and the till cannot disagree), disableableCapabilities (sent per row rather than mirrored client-side — a dashboard holding its own copy of a server list is how park_bills went missing from every "Skapa"-created till for six days), and kitchenDelivery: a resolved four-state discriminant — active / not_granted / off_at_register / auto_send_off — carrying the precedence, because a missing grant makes the venue switch irrelevant and a venue switch makes the auto-fire flag irrelevant, and any surface re-deriving that order is how two screens come to disagree about one till. (autoSendToKitchen alone is a trap and is documented as one: it resolves against the GRANT, so it stays true on a till that switched Köksbongar off.) The fleet panel now states each register's effective state: a per-row kitchen sentence naming which switch stopped the orders and which screen to change it on, a box-level "2 enheter når inte köksskärmen just nu" banner, and a folded per-capability list where active / av på enheten / ingår inte differ by colour, icon and wording. Deliberately read-only, and the copy says so — no dashboard writer exists for either layer (the venue layer is till-only by design; the grant is set when a device is created), so the panel points at the till instead of implying a control it does not have. The five new fields are optional in the ui types: ui and the NestJS backend deploy separately, and absent means "the server did not say", never "nothing is switched off" — the panel renders nothing at all rather than reissuing the same lie under a new heading. Also fixed while screenshotting both modes: the panel's genuine-amber status colour (#b45309, a flat inline style that cannot answer a .dark ancestor) was a dim ~2.4:1 on the dark dashboard — now mode-aware, light values byte-identical, which also repairs the two pre-existing uses (the currency refusal and "Väntar på parkoppling").

• Every booking gets a number now, not just the till's (2026-08-08, follow-up). The cancellation mail for a website-made booking showed no number — because only the POS create path minted one. mintReservationReference moved to lib/reservations/reference.ts and ALL FOUR create paths use it: the public widget, the floor-picker wizard (whose old 4-digit ref lived only in specialRequests text and matched nothing searchable — the stored field, the text prefix and the returned ref are now one value), the dashboard staff create, and the till. Every future booking is numbered in every mail and findable by number from the POS; bookings created before today keep having none.

• Reservations grew a full guest-notification story and a no-account self-service door (2026-08-08, fifth round). Owner asks off a live email: (1) the booking number now rides every reservation mail — the owner's new-request notification, the guest's received/confirmed mails — not just the confirmed template. (2) Cancellations mail the guest from every surface that can cancel (POS action 'cancel', dashboard status flip, guest self-cancel): a new canceled branch on reservationStatusEmail, because an inbox holding a confirmation for a table that is gone was the worse silence. Both tills' cancel-confirm copy now states it conditionally ("om bokningen har en e-postadress" — the till never sees the address), and the after-state reports the server's guestNotified honestly. (3) Reschedules mail too — new reservationChangedEmail fired by the till's update route and the guest's own changes; the till edit confirmation now reports mailed/not-mailed instead of "the guest is not notified". (4) Manage without an account: guest reservation mails carry a manage link (/tenant/[id]/reservations/manage?id&token — the cancelToken IS the authentication) to a new page that shows the booking and lets the guest move date/time/party/table or cancel, backed by new public GET/PATCH /api/public/[tenantId]/reservation/[id] running the ONLINE rules (availability engine when the slot moves, party bounds, table fit with no staff override, occupancy excluding self). Till-created bookings now mint a cancelToken so their guests get the same door.

• Booking-form and floor polish off the owner's fourth hands-on pass (2026-08-08). (1) A table already sold for the chosen date+time now says "Upptagen" ON ITS TILE — dimmed, warn-toned, untappable — using the same exact-slot rule the server refuses with, read from the day's own list; a time step that sells the chosen table out clears the selection where the operator is looking, and the server's TABLE_OCCUPIED stays behind it as the final word (the client set is a fetch old). In edit mode a booking never blocks itself. (2) The RB booking number is bold on both tills' confirmations. (3) Floor legibility: the BOKAT chip's near-black-on-azure ink became the on-primary white, and table-top labels are held to the shape's SAFE width with ellipsis — a circle's text band is its inscribed width, so "WINDOW" and the money line no longer run off the curve mid-letter.

• The till's booking desk is complete: numbers, online slots, find, cancel, reschedule (2026-08-08, third round the same day). Owner asks off live testing, all on both tills. (1) Booking numbers: till creates mint RB-###### (unique per tenant, additive Reservation.reference), shown first on the confirmation, on the sheet's facts, in search rows and in the guest's confirmed-email (new optional reference on reservationStatusEmail). (2) The online widget's time slots as quick picks: GET /pos/registers/bookings/slots → BookingsBridge.slots → new /api/internal/pos/booking-slots running the SAME getAvailableSlots engine as the website — guidance chips beside the manual clock, never a gate (the person in the room outranks online pacing); the form itself reorganised into bordered section cards (Datum/Tid/Sällskap/Gäst). (3) Find a booking: GET /pos/registers/bookings/find?q=&today= (operator required — an all-dates sweep over guests' names is an errand, not floor decoration) matching number, name or phone digits across every date and status, served from a projector now SHARED with the day list (lib/reservations/pos-projection.ts) so the two reads can never drift on what a till may know about a guest; a debounced search sits in the bookings panel on both tills. (4) Cancel from the till: action 'cancel', legal from pending AND confirmed → 'canceled', mailing nobody (no cancel template exists anywhere; the caller IS the notification, and the confirm step says so out loud). (5) Reschedule/edit: POST /pos/registers/bookings/update → new /api/internal/pos/reservation-update — full-state for the till-visible fields (a blanked phone IS a cleared phone), customerEmail structurally untouchable (the till never sees it, so an edit cannot wipe it), occupancy re-checked EXCLUDING the booking itself, BOOKING_NOT_OPEN for closed ones; the create dialog reopens prefilled as the editor, email field hidden, and the confirmation states plainly that the guest is not notified automatically. Also fixed live: `guestNotified` no longer lies on a box that cannot send mail — the response is now gated on isMailConfigured() (found when the staging box's SMTP lived in ui/.env.local, which the runtime container never receives; the keys now travel via docker.env).

• The till's booking form grew up on first contact with its owner (2026-08-08, same day). Four asks off the first hands-on test, all landed on both tills: (1) a REAL calendar — a custom-drawn month grid (new PosCalendar in the Compose kit, mirrored markup on pos/web, shared arithmetic in NewBookingModel/booking-calendar.ts pinned by twin tests) replacing the one-day-at-a-time stepper; the platform-date-picker doctrine holds, the grid is ours; (2) the table picker's pills ("3 · 4") became TILES — name on one line, "4 platser" on the other, chosen tile solid primary (the PosSegmented lesson about quiet tints); (3) the Telefon/På plats question is GONE — either way the booking is taken at the till, so the server now stamps every till create source: 'pos' (new vocabulary value, rendered "Kassan"/"Till"; older tills' source field is accepted and ignored rather than 400ing the not-yet-updated); (4) the Bord side panel's way back from a selected table — a real "‹ Alla bord" leading the header where the old trailing ghost went unseen by the owner looking straight at it, and "+ Ny bokning" got its own full-width row instead of wrapping under the day stepper.

• The till can now TAKE a table booking, not just answer one (2026-08-08). Owner ask: a guest on the phone or at the counter had no door into the book from the POS — the operator wrote it on paper and typed it into the dashboard after close, or didn't. New end-to-end create path on all three POS surfaces (pos/web for browsers+Windows station, the Compose till for Android/Windows/wasm): a "Ny bokning" dialog on the Bord surface with source (Telefon/På plats), a stepped day (floored on today, +365 cap, no calendar widget per the kit doctrine), quarter-hour clock, party stepper, optional REAL-table chips, guest name, optional phone/email, and free-text önskemål (→ specialRequests, which already flows to the floor cards, dashboard list and prep board). The chain mirrors reservation-action deliberately: POST /pos/registers/bookings/create (RegisterGuard + operator, no capability — the reservation-route doctrine) → BookingsBridge.create → new internal route /api/internal/pos/reservation-create doing the write inside ONE mutateTenantDB CAS with the staff route's exact checks (table exists, tableFitsParty with an explicit operator override that stamps seatedOverCapacityBy, occupiedTableIds), then the shared notifyReservationCreated — never a second notifier. Born `confirmed`, and that is a rule: the operator taking the call IS the venue answering, and the native alert engine chimes only on new pending rows, so a phone booking taken on till A must not ring till B or inflate any Bord badge. A booking with no email reports guestNotified: false and the confirmation says so ("bekräfta med gästen direkt"). Reservations gain an additive createdBy operator stamp. Validation drift between the DTO edge and the authoritative zod is carried as an honest 400 VALIDATION ("kontrollera fälten"), never flattened into the 503 outage message. Adversarial review (3 lenses over the combined diff) found no blockers; its parity findings — a half-hour-boundary default-time drift between tills, 1 gäster grammar, named-table chip wording, the web till not re-reading a stepped-to future day after a create, missing input caps on Compose, missing stepper aria-labels on web — were all fixed before landing.

• The animated hero is back on the landing page (2026-08-07). Owner ask: "do you remember we hade the animated hero on our website home page or landing page before. is it possible to get that back?" It was never deleted — components/landing-v2/HeroSection.tsx was orphaned when the new landing page (#81) replaced it with a static headline-and-screenshot block, and had simply stopped being imported. Restored on top of the new page: only the static hero it replaces is gone, everything else (HomeNav, JourneyStrip, the trust band, StickyCta, TestingBanner) is untouched. What moves again: the live order demo stepping New → Accepted → Preparing → Ready with its pulsing status dot (rPulse), and the "Today's revenue" card floating above it (rFloat). The two stylesheets could not simply both be imported — landing-theme.css and restora-landing.css share five selectors and all five are root ones (.r360-landing, .r360-landing *, html, the skip link), so loading the old sheet second would have re-based the whole page's tokens, reset and typography on top of the new design. Instead the hero's 30 custom properties, 12 rules and 2 keyframes were lifted into hero-legacy.css, with the tokens declared on the hero element rather than the page root so they cascade to its children and can reach nothing else. The warm token names (clay/honey/pine) are legacy; their values are the azure brand (--clay-500 = #1570ef) and stay that way per AGENTS.md.

• "Tables & QR Codes" showed only table management — every QR affordance on the page was gated behind having tables (2026-08-05). Reported as "QR code, it was working there, now it shows table management instead of QR code generation". Root cause: on /dashboard/tables, the "Menu QR codes" button was wrapped in {tables.length > 0 && …} and the per-table QR buttons render inside the table list — so a venue with no tables yet landed on a page the sidebar calls "Tables & QR Codes" and got a floor-plan empty state ("No tables yet — click Add Table to set up your floor plan") with no route to QR generation at all. Compounding it, the standalone QR Menu Generator (/dashboard/qr) is a HUB_LINKED_ITEM — deliberately not rendered in the sidebar, reachable only via the Marketing hub — so once the per-table buttons vanished there was no visible QR entry point anywhere in the nav. Fixed by making QR reachable from this page regardless of table count: a permanent "QR generator" link in the page header, and an empty state that now says per-table QR codes appear once tables exist while pointing at the generator for menu/takeaway QR codes, which need no tables at all. The sidebar IA is left as-is (the hub-linking was a deliberate de-duplication); this restores the discoverability it cost.
• The grocery till was overcharging for weighed goods, live — and the till that wasn't overcharging couldn't sell them at all (2026-08-05). The #1 item in the grocery backlog (OUTSTANDING-WORK.md §3g). On a weighed variation priceMinor is the price per kilo, but pos/web's local CatalogVariation interface never declared weighPricing — the exact TypeScript twin of the Kotlin ignoreUnknownKeys defect that had already bitten this same field — so every add path treated a kilo price as a unit price. Tapping Lösgodis (99,00 kr/kg) charged 99,00 kr for whatever the bag weighed: a 320 g bag overcharged the customer by 67,32 kr, silently, with a plausible-looking amount on the receipt. pos/web now declares the field and refuses weighed items by name — the identical posture, and identical check order (sold-out → weighed → age), the Compose till already took. Also added a server gate at both independent write doors (buildTicketLines, serving sale.record + park; and addLine for open tickets): a weighed variation with no ext.weigh is refused, mirroring the minBuyerAge → ageCheck refusal directly above each. It costs nothing today because both tills refuse — which is exactly why it could land now: the overcharge is structurally unreachable from any client, including ones not yet written. Adversarial review then caught that the fix was incomplete in three ways, all fixed: (1) TablesFlow is a third hand-maintained copy of the same wire shape and still walked straight into the new server gate — a waiter tapping a weighed tile would have gotten a raw English server sentence naming internal ids in a Swedish till (table service really does sell weighed food; the SE journal fixtures pin a "Salladsbuffé" uom: 'kg' line); (2) the new spec never exercised the sale/park door's accept path, so a gate that refused every weighed line — even a correct one — would have kept the suite green (both gates are now proven non-vacuous by deleting each in turn and watching the suite go red); (3) onScan's new non-404 branch claimed "no contact with the server" even for a 500/401 where the server answered, and discarded the precise message the API client had already written. Separately fixed on the same path: onScan used to treat every failure as "unknown barcode" and open Ny vara prefilled, so a network blip while scanning a real product invited a duplicate item bound to a code the catalog already used — now only a definitive 404 does. Published to all three POS surfaces (web / Windows-via-web / Android assets; APK rebuild still required to reach devices). The kernel needed nothing — verified, not assumed: unitPriceMinor is literally "per 1.000 uom", qtyMilli is net grams, and the golden 0.734 kg line is pinned across the Rust/Kotlin/C# engine ports. Manual weight entry and the prefix-2 EAN parser remain blocked on owner decisions (the prefix-2 layout is company-internal and absent from this repo; a parsed item reference has nothing to resolve against; and whether a hand-keyed weight is legally sellable is a metrology question) — all now written up in §3g rather than guessed at.

• /shop now serves the grocery vertical — grocery's first working public catalogue page (2026-08-05). Found while auditing other verticals for the same "no public surface for the real catalogue" gap as the services /shop fix earlier the same day: the grocery demo tenant's /menu (the only page grocery doesn't already 404 on) reads the legacy tenant_data.products blob — empty, since a grocery till writes to pos_items instead — so it rendered generic restaurant-template chrome ("Vår meny... Färska råvaror, lagade med kärlek") with zero of the tenant's real 12 products. Every grocery tenant has this gap, not just the demo one. Extended (not duplicated): listGoods's vertical gate widened to services-or-grocery; a new resolveGoodsTenant resolver added (deliberately separate from resolveSalonTenant, so /book//availability//booking stay services-only — grocery has no appointments); /shop's page gate widened the same way; a hasShop nav flag added so grocery gets the Shop link without gaining book or losing its existing menu/reservations. Weighed items (loose fruit, deli) now carry weighPricing through the projection and render as "kr/kg" instead of a meaningless flat unit price. Adversarial review caught 3 more real gaps: the sitemap generator and the builder's IndexNow re-crawl ping both still gated /shop on services-only, so grocery's new catalogue page was invisible to search engines even though it 200s — both widened to match; and fmtPrice's default whole-number rounding, reused unchanged for the new per-kg display, silently mangled the normal case for Nordic weighed pricing (39.90 kr/kg showing as "40 kr/kg") — not a rare edge case, since psychological/fractional pricing is the Nordic grocery norm — fixed with an explicit fraction-digits override for the /kg call site only (flat prices unchanged).

• Closed a latent, defensive gap of the same shape as the navbarConfig CTA bug below, in the footer. SiteFooter.tsx already filters menu/reservations out of nav-derived footer links for a services trade, but an owner-authored (or template-seeded) footerConfig.bottomLinks entry bypassed that filter entirely — free-text hrefs, never checked against vertical anywhere. No live tenant currently has a bottomLinks entry pointing at a dead route, so this wasn't actively broken for anyone, but it's the exact same "stored config bypasses the vertical guard" pattern found live in the navbar CTA — closed the same way before it could bite someone.
• A real pilot tenant's live storefront showed a dead "Order Pickup" button (2026-08-05). Found while auditing other services-vertical tenants for the same bug class as the day's earlier nav/shop fixes: Nordic Barber Studio (ten_nordicbarber) has its own settings.navbarConfig (left over from a restaurant "forno" template installed before the tenant had a declared vertical), and resolveNavbarConfig() (ui/src/lib/nav/navbar-appearance.ts) returned that stored CTA verbatim whenever a tenant had one — silently bypassing the vertical-aware suppression SiteHeader.tsx's own legacy CTA already relies on (showBookButton && !isServicesTrade). The result: a barbershop's header showed a button linking to /reservations, which 404s for that trade. resolveNavbarConfig now takes an isServicesTrade flag and forces the CTA off in both branches (stored-config and fallback), closing this regardless of which shape a tenant's chrome is in — not just today's specific case. SiteNavbar.tsx's mobile CTA (bookHref) inherits the fix automatically since it reads the same resolved config; no separate change needed there. The tenant's stored navConfig.items was also missing book/shop/account (same gap ten_hasalong had) and was repaired the same way. The stored navbarConfig.cta itself was deliberately left untouched — the code fix alone makes it inert for this trade, and rewriting the owner's own raw editor data risked exactly the kind of silent-data-loss surprise this session's earlier fixes were about.
• Every guest visiting any tenant's public salon page (`/book`, `/shop`, availability, cancel) was rate-limited as if they were the same single client (2026-08-05). Found while closing out the /shop feature's adversarial review: internalGet/internalPost/etc. (ui/src/lib/http/backend.ts) never forwarded the incoming request's x-forwarded-for header to the backend, so UserThrottlerGuard.getTracker — which falls back to x-forwarded-for → req.ip whenever no req.user is set, true for every guest BFF call — tracked every anonymous visitor across every tenant's storefront as the SAME client: the Next.js server's own outbound IP. Fixed by threading the caller's Request through all 5 internal* helpers (optional, backward-compatible — none of the ~79 existing callers needed to change) and wiring it through the 6 guest-facing salon-booking routes (services, goods, availability, book, booking/[id], booking/[id]/cancel). New tests pin that the header is forwarded when present and omitted (unchanged) when no request is passed.

• A public /shop page for services-vertical retail products, and the productType bug that made it necessary (2026-08-05). Follow-up to the same-day Mason nav fix: the salon owner's items ("Happy happy", "Argan-oil") appeared in the dashboard catalogue but never on the public website. Root cause: the native till's "Ny vara" (new item) dialog has no product-type picker at all — just name/price/category/VAT — and the server-side legacy-menu translator (translateLegacyMenu) hardcoded every till-authored item to productType: 'FOOD_BEV' regardless of vertical, a meaningless tag for a salon that also had no public page reading it. Fixed: for a services-vertical tenant, a brand-new till item now defaults to GOODS instead (a real retail-product type — the SAF-T export already maps it correctly to "04003 Sale of goods" vs FOODBEV's "unclassified", and it's excluded from KDS routing). Added a new public `/shop` page (mirrors `/book`'s structure — same vertical gate, same ThemeInjector/SiteHeader/SiteFooter usage) with a new backend `listGoods` projection (sibling of `listServices`) and Next.js proxy route, plus a `shop` nav link (`source: 'custom'`, same protection as `book`/`account`). **Adversarial review caught 5 further real issues before deploy**: (1) the productType default was computed per-tenant, not per-item, so ANY unrelated till write (an 86, a reprice) re-translated and silently re-stamped EVERY item in the tenant's legacy blob to the same default — fixed by preserving each item's already-stored productType and only defaulting genuinely new items; (2) a failed tenant lookup degraded silently to the old FOODBEV behaviour with no logging — fixed with a warning log; (3) neither listGoods nor the pre-existing listServices had a server-side vertical check (only the Next.js BFF gated them) — fixed by gating both, failing closed; (4) the sitemap generator was 100% vertical-blind, advertising dead /menu+/reservations URLs and never listing the live /book//shop pages for any services tenant (a pre-existing gap /shop would have inherited) — fixed for both the subdomain and platform-prefixed sitemap branches; (5) the IndexNow re-crawl ping list had the identical gap — fixed. Also added a TTL cache for the new per-write tenant-vertical lookup so restaurant/grocery tills don't pay a new Mongo round-trip on every catalogue write for a vertical check whose answer never changes their output. The friend's two existing items were reclassified to GOODS directly in Mongo (owner-approved) so they appear on /shop immediately rather than waiting for an unrelated till write to self-correct them.

• A live customer's "Boka tid" (Book) nav link vanished on an unrelated colour-theme save, and new POS items looked invisible on the public site (2026-08-04). Reported by a services-vertical (salon) tenant created same-day: picking a new colour preset in the Mason website builder — no nav edit at all — silently deleted the "Boka tid" link from the live header, while /menu and /reservations (pages that don't exist for a services trade) appeared in its place. Root-caused to THREE compounding layers, all in ui/: (1) MasonShell.tsx's save() unconditionally re-sent the full navItems array on every save regardless of what was actually edited — fixed to gate it behind the same HEADER_DIRTY_KEY dirty-tracking the Menu/Header tabs already use. (2) getDefaultNavItems() (nav-service.ts) never marked the services-only 'book' link (or 'account') as source: 'custom', so the server's reconcile treated it as an orphaned page link and dropped it — fixed by tagging both source: 'custom'. (3) normalizeMasonPages()'s fallback for a tenant with no saved page list (pages.ts) was a hardcoded, vertical-blind restaurant shape (home/menu/reservations/blog/contact) — the reconcile then saw 'menu'/'reservations' as legitimate pages worth auto-linking. Fixed with a per-vertical fallback (defaultMasonPagesForVertical) that drops menu/reservations for services. Adversarial review caught two more, more severe instances of the same class after the first fix landed: gating navItems client-side made a SECOND, previously-dead server branch in builder/route.ts (fires whenever builderPages is sent without navItems — now the common case) start wholesale-rebuilding nav purely from the page list with no reconcileNavItems call at all, re-dropping every custom link (book/account, on EVERY vertical) on almost every ordinary save; and the GET handler's own normalizeMasonPages() call (missing the vertical arg) was handing a fresh services tenant a polluted page list that got persisted into builderPages on its first save, regardless of the fix. Both closed: the sibling branch now reconciles the tenant's existing nav against the updated pages (same non-destructive merge the Menu-tab branch already got) instead of discarding it, and GET now resolves + threads vertical through its normalizeMasonPages call too. Also fixed a narrower, separate latent instance of the same vertical-blindness in the theme-install-with-demo-bundle path (installer.ts's applyChrome, ruled out as this incident's trigger but real). New regression test in nav-from-pages.test.ts pins the services Book/Account-survive-reconcile case (caught failing twice at intermediate stages before landing correctly — proven non-vacuous). The friend's tenant (ten_hasalong)'s live navConfig/builderPages, corrupted by the original bug, were repaired directly in Mongo to match exactly what the fixed code now produces — live-verified after the repair: the header shows Home/Book/Blog/My Account/Contact and /api/public/salon/hasalong/services still returns all 5 of the friend's POS-added services.
• Paper reprint for a closed sale — and a live bug it caught along the way (2026-08-04). The tender-flow "Print" button was a dead onClick = {} stub, and History had no reprint action at all (a code comment said the seam didn't exist yet). Both now call one new, awaited backend action (POST /pos/tickets/:ticketId/print, mirroring email-receipt's exact shape) that reuses the print-job pipeline every sale already auto-queues at settle, marked kopia (or ovning for training) since it's always a second copy. Native: HistoryRepository.printReceipt + a ReprintReceipt action beside the existing email-resend button; PaymentStep.Done gained a ticketId so the Done step's Print button has something to call. Adversarial review caught a real, previously-invisible bug: a training-mode sale's receiptNumber is deliberately blank, but the internal print-sale/email-sale routes hard-required a truthy one — so every training reprint was a guaranteed 400 dressed up as a false "try again" 503, and (traced further) this had ALSO silently broken the auto-print and auto-email-at-settle for every training sale since those shipped, fire-and-forget, invisible. Fixed at both routes: a payload marked ovning is now accepted with no receipt number. Verified live against a seeded grocery tenant: reprint answers {"queued":0} (honest — no printer paired) and the previously-broken email resend now answers {"sent":true}.
• Grocery module phase 1 — the native till learns to sell groceries, and `scan_first` finally does something (2026-08-04, `pos/app` commonMain → Android + Windows + wasm from one tree). Owner ask: "now can we start with grocery store module for PoS both for windows and android." Plan of record: docs/products/pos-verticals/GROCERY-MODULE-PLAN.md (a six-reader state map with adversarial spot-checks, gap matrix against MARKET-RESEARCH-2026-08.md §4b's ranked top-10). The finding that shaped the pass: the kernel/backend were grocery-first all along (golden scenario 1 — the mixed 6/12/25% weighed+pant+age basket — is literally called "THE EXIT CRITERION") and the web till already sold groceries; the NATIVE till had the skeleton and none of the organs, two of them live money bugs. Shipped: (1) the Kotlin catalog DTO finally declares `deposit` + `weighPricing` — the server had sent both all along and ignoreUnknownKeys silently ate them, so a natively-rung Läsk priced without its pant while the same scan on the web till priced with it. (2) Pant attaches and is priced by the ENGINE (a pant row's amount is a one-line priceBasket, never Kotlin addition; Pant chip on the row) — and the resumed-bill half was a live defect: adoptServerTicket dropped ext.goods, so a pant bill parked on the web till re-priced WITHOUT its pant on native pick-up and the close's exact-tender check refused the very total the screen showed. (3) The age gate exists on the native till — before this the server refused every minBuyerAge sale (no dialog could record the check), so the tobacco pilot's own till could not sell snus at all. Blocking Ålderskontroll dialog; a repeat merges into its checked row without re-prompting; the recorded check (id_document) rides all four write shapes (sale lines, park lines, add-line via the sync diff — a qty step on a resumed checked line is a void+re-add and needed it — and survives resume via ext.goods.ageCheck). (4) Weighed items are refused honestly ("1" of lösgodis is a kilogram at the per-kilo price; the web till still silently sells it — flagged for parity). (5) Scan-to-create: an unknown scan opens Ny vara with the code prefilled (prefillBarcode was dead code) — on a definitive 404 only; the web till's create-on-ANY-error defect (a network blip while scanning a real code invites a duplicate item) deliberately not ported. (6) Quantity multiply + the scan-first counter: scan_first gates something on a selling surface for the first time on any platform — last-added feedback card (reads the LIVE row, so merges and steppers keep it true) + a digit pad arming a multiplier for the next scan (buttons, not a field — a focused field eats the wedge's keystrokes), and the armed count survives the age dialog (the web till drops it and hardcodes 1 — not ported). Also: CapabilityRailTest's "verbatim from seed" fixtures had drifted (shop claimed 5 caps; the seed grants 10) — reconciled with the lesson in the fixture comment; new GroceryTillTest (16 cases) pins the DTO decode, wire presence/absence of the check, deposit-through-the-engine, the age-gate cadence and the armed-qty rules. Gates: full Compose desktop suite green (613), Android + wasm compile clean, Swedish-literal ratchet held at 0. Remaining (ranked in OUTSTANDING-WORK §3g): weighed goods both flows, paper receipt at tender (the print button is a stub), offline barcode index, pant registry/RVM tender, pos/web scan-first parity, dashboard grocery enablement (signup tile still "Coming soon").

• Backend half of "email the customer their receipt" (2026-08-04). TicketDoc.customerEmail (opt-in, per-sale, never indexed or joined — no CustomerDoc/CRM write) added to RecordSaleDto and CloseTicketDto (both @IsEmail). SalesService.buildTillPrintPayload extracted from the inline body of printTillSale and generalised to build a TillPrintPayload from either a live PricedBasket (record/close time) or a persisted closed TicketDoc (lineNetGrossMinor from exports/money-format.ts reconstructs each line's post-discount total from the SAME stored fields the pricing engine used — no new totals computed, no re-derivation of VAT). TillPrintBridge.email() posts to a new POST /api/internal/pos/email-sale (mirrors print-sale/route.ts: internal-secret guard, ephemeral order, buildReceiptFiscalFromTill, no persisted Order, no minted receipt number). Auto-send hooks in recordSale and closeTicket fire void, after commit, never awaited — the same "must not be able to fail a sale that already happened" posture as printTillSale. New deliberate-resend endpoint POST /pos/tickets/:ticketId/email-receipt (409 if not closed, 400 if no address on file or given, 503 if the send genuinely fails) IS awaited, since a person tapped "send" and needs a real answer. Email body is the exact legal receipt layout via buildReceiptSegments + a new renderSegmentsPlain (render.ts) — deliberately NOT renderSegments(…, false) (raw ESC/POS control bytes, garbage inside HTML) nor renderSegments(…, true) (stamps a "not a valid receipt" preview watermark that would be a lie on a genuine one). Template (lib/email/receipt-till-email.ts) is the azure #1570ef card from receipt-email/route.ts, sv/en via settings.defaultLanguage. /receipt/[tenantId]/[token] and receipt-store.ts untouched. Verified: backend tsc --noEmit 0 errors; ui tsc --noEmit 0 NEW errors (pre-existing unrelated failures in theme-packages/experience-studio/plans untouched); all 202 pre-existing backend/src/modules/pos/sales tests still pass. NOT done in this pass (separate agents' scope per the design doc): pos/web and pos/app capture UI (checkbox + email field at tender time) and the History "Skicka kvitto" resend button on both rails — the backend endpoint and auto-send are ready for them to call.

• The Windows till closes an architecture question left open since 2026-07-27, and gains real printing (2026-08-04). Owner ask: "my windows PoS is behind the android tablet app. can you also update windows app so it is same as my android PoS also connect that to my barber shop tenant to my linux box over internet." docs/pos-rebuild/OUTSTANDING-WORK.md §5b had four documents disagreeing on what "Windows POS" even was — WinUI 3/C# (never built), a Tauri/WebView2 shell wrapping the web till (windows/station, real code, real recent investment), or the Kotlin Multiplatform Compose desktop target (pos/app/app/src/desktopMain, also real, sharing commonMain with Android almost entirely already). Owner ruling: the native Kotlin build is the POS till — Android and Windows now run the literal same source tree, not two ports kept in sync, which is a stronger fulfillment of the "one kernel" guarantee than the original C# plan would have been. windows/station keeps its TV/kiosk/display and hardware-bridge roles (unchanged), just not the till UI. The actual parity gap against Android turned out to be small: printer/cash-drawer transport, which returned NotSupportedHere on desktop with a comment saying Windows should print through the Station agent instead. That assumption was wrong and caught same-session, before commit: there is no local channel from the Kotlin process into the Tauri process to route through. The real fix makes the Kotlin till its own independent print agent — PrinterTransport.desktop.kt ports Android's java.net.Socket RAW/9100 transport near-verbatim (same connect-timeout/watchdog trick for the JVM's missing write-timeout), PrinterDiscovery.desktop.kt does a LAN TCP sweep reusing the already-shared, already-tested PrinterRoster (no mDNS on the JVM — a known, smaller, non-blocking gap vs Android's NsdManager). Both poll the SAME /api/public/hardware/* job queue Android already uses via the existing commonMain PrintAgentRepository — zero new backend surface. A venue running both a Kotlin till and a Windows Station against one printer is prevented structurally by pairing (single-use code, one claimant), not by mutual-exclusion code. Docs corrected in the same session across docs/POS-Rebuild-Master-Plan.md §2.2, windows/AGENTS.md, and docs/pos-rebuild/OUTSTANDING-WORK.md §5b — twice, since the first correction pass itself carried the wrong (Station-routing) assumption and a verification agent caught it before commit. Built, installed and running on a real Windows machine already on the same tailnet as the box (https://restora-server.tail8deedd.ts.net, confirmed reachable) via :app:packageMsi + tools/install-windows.ps1. Not yet done: re-pairing this till from its previous ten_pilot-demo register to a ten_nordicbarber register — needs a dashboard-minted pairing code (15-minute TTL, so minted at the moment of use, not ahead of time). Gates: :app:compileKotlinDesktop clean, :app:desktopTest 597/597 pass (3 new real-socket tests, no mocks), :app:packageMsi BUILD SUCCESSFUL.

• Audit correction: the owner caught a live miss, so the sweep methodology got fixed, not just the symptom (2026-08-04). After the three-wave trade-leak audit below was reported complete, the owner posted a screenshot of Nordic Barber Studio's live /dashboard/orders page — still the unfiltered restaurant kitchen kanban ("Tillagas" column, "Börja tillaga" button) — and asked "are you sure". It wasn't. Root cause: the audit's page-scoping walked NAV_GROUPS (the collapsible sidebar) exhaustively across all three waves but never enumerated NAV_PRIMARY (Home/Intelligence/Quick Settings/Quick Links/Orders) as a category to check — Orders lives in NAV_PRIMARY and was structurally invisible to every audit prompt written. Fixed the two live Orders leaks (kanban column + action button forked on vertical !== "restaurant", sv override added), then ran two further repo-wide sweeps rather than re-declaring done: a "No restaurant connected" boilerplate grep (8 more core-page instances fixed: quick-links, sell, menu-tv, media, designer-studio, connections/seo/offers dict), then a broader restaurant|Restaurant sweep across every dashboard page, filtered for comments/type-names/already-vertical-aware code and triaged one-by-one against nav-catalog.ts gating. ~25 more genuine leaks fixed, all on pages with zero vertical gating (reachable by every trade): the super-admin panels (addons/global-media/monetization/tenant list — these manage tenants of every vertical, so "Restaurant" table headers and "restaurant owners" copy were platform-wide leaks, not barbershop-specific ones), the dashboard error boundary (error.tsx — fires for every tenant on any error, was "Restaurant data unavailable"), escrow, marketing hub, QR, activity log, team-comms, the Google Business connect guide + attributes + insights pages (Google Business Profile is generic to any local business — none of that copy should ever have said "restaurant"), social, branches (plus hid the cross-branch "Shared Menu" tab for non-restaurant — it pushes the legacy menu system, not the Sortiment catalogue a services tenant actually manages its stock through), and the Settings page's business-name fallback (myRestaurantFallback, shown whenever a tenant hasn't set a custom name — a common, not edge-case, state). Also corrected the Swedish `dict-langs.ts` overrides for the specific keys touched (English-only fixes silently do nothing for a Swedish-locale tenant on these OLD, fully-translated namespaces — the merge prefers the stale generated override over the corrected English source). Left deliberately unfixed and flagged instead of hacked: Experience Studio's AI photo/caption tool and the Restora Profit setup wizard are restaurant-shaped by design (dish/cuisine prompts, food hashtags, a "Restaurant type" segment picker), not by a wording accident — a label rename would be cosmetic since the underlying options stay food-only; both need a real services-appropriate variant, tracked in TODO.md. Also tracked: the other 19 languages' stale "restaurant" wording for the keys fixed here (Swedish was prioritised as the pilot tenant's locale). Gate: tsc --noEmit held at the exact pre-existing 60-error baseline through every edit in this pass — zero regressions.
• The trade-leak audit closes — every restaurant option the owner kept finding on the barbershop panel (2026-08-04). Owner: "i still se some options for restaurant on admin panel. this time i want you to detect and remove from barber or salong module." A five-surface audit (native till, web till, dashboard home, every dashboard page, the email/receipt/site periphery) swept the whole product for restaurant-specific wording and dead-end affordances still reaching a services tenant; every finding was fixed in three landed waves. Headlines: Features → Get more no longer invites a barbershop to buy a Kitchen Display, and Your Features stops reading "Table Reservations" — FeatureDef gained the same verticals convention as the nav catalog, an already-GRANTED feature always stays listed. Setup Center's Ordering & Delivery tab (Uber Eats/Wolt) is gone for services. The Devices page no longer offers a Kitchen Screen to connect, and its first-run trade picker now opens on the tenant's own declared trade instead of defaulting everyone to "Restaurang". QR Generator, Supplier Marketplace/Quotes/Orders, Hiring, and Restora Profit's menu-engineering rows are trade-annotated. The home page's Upcoming Bookings widget (table reservations) is gone for non-restaurant, its onboarding checklist offers "Add your first service" linking the new catalog editor, and its KPI counts today's actual appointments instead of a permanently-zero reservation count. Help Center, email campaign templates (four new services-flavoured twins added), the tax regulation calendar, Setup Center's Integrations tab, and the Notifications tab are all trade-filtered. Copy forks (services wording, never restaurant text mutated) landed across Setup Center, SEO (menu-completeness check dropped for services), Profit Margins (COGS/recipe language skipped for non-restaurant), Customers/Guest-profile, Intelligence's AI-question catalogue, Marketing Hub, the AI Assistant page, Demand & Weather, Shifts, and Loyalty (now sources reward items from the services catalogue instead of a Menu that doesn't exist for that trade). Neutral "No restaurant connected" → "No business connected" across every no-tenant surface. One genuine money-correctness bug was found and flagged, not silently patched: lib/android-terminal/receipt.ts hardcodes restaurant_dinein in its VAT-split function — a real defect that needs its own tested change, tracked below. Gates: full tsc --noEmit stays at the exact 60-error pre-existing baseline (confirmed via git stash diff before this work started) across all three waves — zero new errors; nav-catalog 15/15, seller-lite 23/23, regulation-watch 27/27 total, block-features + gift-cards i18n 20/20.
• The salon till behaves like a salon till — checkout that seeds the bill, a booking chime, and the last of the menu-Swedish (2026-08-04, both tills + audit sweep). Owner asks: "booking > ta betalt takes me to kassa and kassa is empty… orders still restaurant specific… some kind of highlight upcoming booking… 3 beep sounds… settings still have kioskläge, uppdatera meny." (1) Ta betalt now hands over a bill: the booking rides the same handoff discipline Parkerade uses, the service line enters through the exact door a tile tap uses (engine pricing, tax pinning, merge rule), the customer's name lands on the ticket — and when THAT sale settles, the till completes the booking against the real ticket id (offline-queued sales get an honest "link queued" notice; a service the catalogue no longer carries refuses rather than inventing a price). Booking cards now also SAY what was booked (service name + catalogue price). Named gap: the native sale envelope carries no per-line ext.service (a money-envelope change), so the web's closed-ticket recovery scan can't find native sales — commented at the seam. (2) Attention channel on both tills: a NÄSTA highlight on the next open booking, a 30-minute upcoming badge on Bokningar (web), and a TRIPLE chime when a new online booking lands — same sound path as the order alerts, first-load and midnight-rollover silent, status flips never re-announce (18 new tests across the diff/selection/engine). No competitor documents booking sounds — this one's ours. (3) Trade wording end to end (audit-driven, both tills): Kioskläge hidden for tills with no kitchen/scan/self-checkout shape; "Meny/Uppdatera meny" → "Sortiment/Uppdatera sortiment" on non-food tills (grocery-ready); "Tillagas" → "Pågår" on Orders and History; History drops the kitchen-flow chips and the whole Typ row; Ny vara speaks the trade ("Ny vara i sortimentet", "T.ex. Herrklippning", VAT chips lead with Standard 25 %); the bare "KÖK" settings header no longer floats over the printer section; the empty-catalogue screen stops calling every venue "restaurangen"; the offline error stops saying "i hela restaurangen". Non-food line motion now derives from the item (SERVICE→service, else retail) exactly like the web's booking payment path. Gates: Compose desktopTest + assembleDebug exit 0; pos/web tsc 0 + 91/91; bundle republished.
• A services tenant can finally edit what it sells: the Sortiment editor at `/dashboard/catalog` (2026-08-04). Owner ask, verbatim: "i cant rename or add or remove categories, and items nor on web or PoS. the system should be super easy and very flexible." The restaurant's catalog editor is the Menu page — correctly hidden for the services vertical — which left a barbershop with NO surface anywhere to manage its services, products and categories. The new page is the owner's window onto pos_items (the store the till actually sells from, not the tenant-blob menu): categories as sections with inline rename, items as rows with price/duration/active editing, add-item with category pick-or-create (a category is created by filing an item into it — an empty category would be invisible on a till), and soft remove with a collapsed bring-it-back list. New nav group "Services & Products" (services vertical, DAILY zone, translated in all 20 languages), posCatalog dict section with hand-written Swedish, and three BFF proxies under /api/tenant/{tenantId}/pos-catalog/*. Backend grew GET /pos/admin/catalog/items (whole-catalogue admin projection) and POST /pos/admin/catalog/category-rename — categories are DENORMALISED onto items, so a rename IS a bulk re-stamp of every item filed under the id. The admin upsert now MERGES with the stored item, so a projection-shaped save can no longer wipe the fields the editor never shows (barcodes, stock flags, offer markers, routing facets — and a live campaign's price is refused with the same CAMPAIGN_PRICE_LOCKED the till already localises). New items copy the catalogue's own currency/VAT category — the page invents no tax logic. Backend catalog specs 154/154, nav guard 15/15.
• The template gallery knows the tenant's trade, and five trade-neutral looks join it (2026-08-04). Owner ask: "i choose some tempaltes which are for restaurants... there should be generic 5 different unique looking template with 6 color combination... which can be applied to any kind of business." Every existing template/starter/demo-pack is now trade-tagged (verticals, absent = everyone — the nav-catalog convention) and the builder's theme gallery filters on verticalOfTenant (the install route also refuses an out-of-vertical slug from a stale tab). Found and fixed a deeper leak on the way: EVERY theme install ran an auto-map that injected a menu-preview block and a /menu-CTA hero onto the site — a services tenant now gets a no-menu guarantee and a /contact CTA fallback, and the guarantees apply to the home page only. Five new GENERIC packs — Impact, Editorial, Showcase, Meridian, Mono — each a genuinely different layout built only from trade-neutral blocks, each with the same six complete 9-token colour combinations (Azure & Navy, Forest & Cream, Charcoal & Gold, Plum & Blush, Teal & Sand, Monochrome) opening on different defaults, install = "use my content" (no demo bundle, navConfig untouched so per-trade nav defaults rule). Tests: 56/56 incl. new vertical-filter, trade-cleanliness, services-no-injection and layout-distinctness assertions.
• The booking loop closes on both sides — owner actions, timeslot editing, and customer self-service with a cancellation policy (2026-08-04). Owner asks: "where can i cancel the booking or ask for new time against customer? where can i customize the timeslots?" and "i need to add email too while reserving... the owner can choose... cancel without any cost time, and if a specific time then the customer will be charged." (1) Owner side — the dashboard Bokningar page gains per-booking Avboka (confirm-first, the till's idempotent cancel via new POST /pos/admin/bookings/cancel) and Flytta (a 14-day free-slot picker; new POST /pos/admin/bookings/reschedule moves via create-then-cancel ordered so the customer never holds nothing, with same-resource self-overlap handled by cancel-create-restore), plus a Schedule & time slots editor per chair (weekly open windows, slot length 5–60 min, active toggle, add-chair) over the existing admin resource/schedule endpoints, and a Cancellation policy card (free-until hours; late fee none / full service price / fixed amount) stored on settings.bookingPolicy. (2) Customer side — /book now requires email; the confirmation emails a manage link (HMAC key over tenant+booking — an email click is the whole authorization, no account) to /book/manage, where the guest sees their booking and the policy verdict for right now ("free until…" or "cancelling now will be charged X") and cancels; a late cancel records cancellationFeeMinor on the pos_bookings row (the no-show-fee discipline — charging happens at the till, never online). Booking contract additively extended (customer.email, cancellationFeeMinor) in the frozen IDL + backend + ui mirrors. (3) More restaurant leakage out of the barbershop — Chains & Groups (Restauranger/Gruppmeny/…) is now verticals: ["restaurant"], and the overview's Köksskärm tab learned the trade axis (a salon's PLAN may include kitchen-display; its trade has no kitchen).
• A customer can book a haircut online — /book writes the till's own book (2026-08-04). Owner ask: "as a customer i can't book haircut from tenants website" — the Book buttons dead-ended (the seed pointed them at /contact, which does not even exist as a tenant page and fell through to Restora's company contact). Now the services trade has a real guest flow: app/tenant/[tenant_id]/book (services-vertical-gated, restaurant tenants 404 the mirror of /reservations) renders a three-step wizard — service (from the POS catalog's SERVICE items via new GET /pos/admin/catalog/services), day + free time (new GET /pos/admin/bookings/availability; the page offers only start times where EVERY covered grid slot is free on one resource, the same arithmetic the server's unique slot index enforces), then name + phone (REQUIRED online — an anonymous online booking is a no-show generator) → POST /pos/admin/bookings/create, a REAL pos_bookings row with createdBy absent (the "guest self-booking (web)" case the persistence doc always reserved). The till's Bokningar and the dashboard book show it the moment it lands; a lost slot race comes back as 409 and the page refreshes the grid. Public BFF routes under /api/public/salon/[slug]/{services,availability,book} gate on active tenant + services vertical and a 60-day horizon. Every Book CTA now points at /book: the seed's hero + pricing tiers (tier links join the BlockRenderer rebase list so path-served sites work too), a Book item in the services default storefront nav (chrome-translated in all 21 languages), and the SiteHeader trade filter learned the difference between /book (the trade's own page — kept) and #book/reservations (table affordances — dropped). Times render UTC HH:mm — the same wall-clock the till, the dashboard and the owner's authored schedule all show, until per-tenant timezones move every surface together.
• A barbershop signs up as a barbershop — TenantRecord.vertical finally has a writer (2026-08-04). The field every reader learned this week (dashboard nav, storefront, route gates, JSON-LD) had NO producer: nothing in the product could declare a tenant's trade. Now the /register page carries a three-tile trade picker (Restaurant default / Barbershop / Grocery "Coming soon"; ?trade=barbershop preselects — the /products/pos card links straight in), Barbershop swaps the business-type options (barbershop/hair-salon/beauty-salon/massage) and the page copy ("Create your business"), and the submit carries vertical: 'services' — validated by RegisterSchema (z.enum(VERTICALS), never derived from free-text businessType), stamped on the TenantRecord and passed into createTenantDatabase so the services website seed fires from the first byte. Onboarding follows the trade end to end: the /welcome wizard's steps/copy/next-steps branch (services: Bookings → Sell → Customise your site), the Setup-guide tab renders onboardingStepsFor(vertical) (services: profile, hours, staff, website, till — with auto-detection only where the data genuinely distinguishes owner action from seed defaults), and branch creation inherits the HQ's vertical so a barbershop's second shop is not born a restaurant. The public landing wizard stamps vertical: 'restaurant' explicitly — it is a restaurant funnel by design. Restaurant flow byte-identical throughout when the field is absent.
• The marketing site sells the POS by trade (2026-08-04). The Product mega menu gains a FEATURED panel — a navy band with a big azure icon tile, per the owner's "so nobody can miss it" — linking to the new /products/pos page (/pos itself is the till SPA's route): hero "One POS, built for your trade", a three-card vertical grid (Restaurant → /apps/pos, Barbershop & Salon → /register?trade=barbershop, Grocery & Retail "Coming soon"), the presets-over-one-kernel line, the three-surfaces band and a Start-free CTA. Data-driven (featured on the nav item, one definition for desktop dropdown + mobile accordion), azure-on-navy tokens only, registered in sitemap.xml + llms.txt. Brand-guard tests 11/11.
• The till adapts fully to the barbershop trade — park, split and the KDS side doors (2026-08-04, all three POS surfaces). Owner ask: "the barbershop module should work according to what barbershop needs, they dont have kds, park bills, split bills." Three leaks closed. (1) `park_bills` minted (21/25 of the capability budget; the owner sentence above is the written decision capability.ts demands): park was the ONE bill surface no capability governed — universal on both rails, capability-free on the server. Now the restaurant/quick-service/shop presets carry it, salon does not; the server gates park creation only (POST tickets/park, :id/park) while list/resume/discard stay register-token-only, and both rails apply a drain rule — a till that lost the capability while bills were parked keeps Parkerade visible until the count reads zero, so a preset flip can never strand money (the §3d incident class). Backfilled on the box and local dev: every non-salon till granted park_bills (capabilityRev bumped), the salon till's seed-granted split_tender stripped (the seed contradicted the preset — reconciled seed-side). (2) Native payment-sheet parity: Compose's "Dela notan" and gift tenders were ungated while web gated them since Phase 10 — PaymentFlow now takes canGift/canSplit from the register's real capability set. (3) KDS side doors closed: web ?kds, Windows --kds and the Android KDS launcher booted the board on pairing alone; a salon device became a permanently dead kitchen screen (every KDS endpoint 403s, only 401 unpairs). Both apps now refuse with words and a way out (back to till / re-pair) — fail-OPEN on an empty capability snapshot so an old cache can't brick a real kitchen board. Gates: Compose desktop suite green (rail test now asserts the universal THREE + salon rail without park), pos/web 82/82 + tsc 0, backend tsc 0, bundle re-published to ui/public/pos.
• The barbershop's appointment book reaches the web dashboard (2026-08-04). Owner ask: "the bookings from PoS are not visible on web." The till has written pos_bookings since Phase 6 and rendered it on all three POS surfaces, but the ADMIN side could not read a single booking — the backend's InternalGuard surface covered resources + schedules only, and ui/src had no page, route or nav entry for appointments at all (the nav-catalog comment even names the gap: a salon's appointments are "a different subsystem entirely"). Now: GET /pos/admin/bookings (backend, InternalGuard; BookingsService.listDay narrowed to take a bare tenantId — the one field it ever used), a thin proxy at /api/tenant/[tenantId]/pos-bookings (requireTenantAccess → internalGet, bookings + resources in one read), and /dashboard/bookings — a read-only day view (day nav, per-resource filter chips, status pills matching the till's vocabulary, 30s follow-along refresh). Read-only BY DESIGN: creating, cancelling and checkout stay on the till, where the operator stamps, money paths and the double-book unique index live. Times render UTC like every other booking surface (the module's honest v1 time model). Nav: new Bookings group, verticals: ["services"], in the DAILY slot where a restaurant sees Reservations — label translated in all 20 languages (test-enforced), page strings in en + hand-written sv (posBookings dict namespace; other languages fall back per the dict design). NOT confused with /api/internal/pos/bookings, which is the restaurant TABLE-reservation bridge on the tenant blob.
• A services tenant gets a services WEBSITE, not a pizzeria's (2026-08-04). The other half of the owner's ask ("the website for client is still for restaurants"): TenantRecord.vertical had exactly one consumer — the dashboard sidebar — while every public-site path was born restaurant. Now vertical-aware end to end: newTenantTemplate('services') seeds a booking hero / services-and-prices / team / testimonials / hours / contact home (all existing SectionRegistry blocks — a different SELECTION, no new components), salon opening hours, no Food Bazar listing row (bazarSettings disabled — a barbershop is not listable on a food marketplace); createTenantDatabase takes vertical and words the SEO bootstrap per trade; the default storefront nav drops Menu/Reservations and the Book-a-Table + cart chrome for services (getDefaultNavItems(vertical), threaded through SiteHeader/SiteFooter and the nav + builder APIs via a 60s-cached verticalOfTenant); /menu and /reservations are notFound() for the trade (route-gated, not just unlinked); JSON-LD emits HealthAndBeautyBusiness instead of Restaurant and drops servesCuisine/ReserveAction/hasMenu; home metadata fallbacks stop promising a menu. Existing services tenants were stamped with restaurant blocks at creation, so scripts/reseed-services-website.ts swaps the factory-stamped parts (guarded — owner-authored blocks are never touched without FORCE=1). An owner-authored navConfig always wins untouched.

• A till shows only the surfaces its trade has, and a second till inherits the first one's trade (2026-08-03). Owner ask: "the admin panel is specifically designed for restaurant systems, where barbershop or grocery store will have a different requirements, i mean a very few specific items upon core system which will be the same. how do we handle that?" The kernel already answers it — pos/shared/domain-types/src/capability.ts opens with "Restaurant" / "grocery" / "barbershop" are PRESETS that select a set of these … the words never appear in kernel, sales or fiscal code, 20 capabilities against a hard budget of 25 — and pos/web has honoured it since Phase 10. Two places had not. (1) The native till's rail was a FIXED list rendered unfiltered (PosApp.kt), so the pilot's Butik register — created with no tables capability — still showed Bord on Windows and Android, and tapping it reached @RequiresCapability('tables') and came back CAPABILITYDENIED. A control that is visible, enabled and then refuses is worse than one never drawn: the operator does not learn "not for this trade", they learn "this till is broken". `canReach` now gates Bord on `tables` and Presentkort on `giftcards, matched on the SEALED TYPE rather than on id strings — a when over ids would have fallen through to true the day an id changed, and GiftCards.id is "gift", not "giftcards", so that near-miss was not hypothetical. Deliberately a whitelist of the gated few, never a default-deny: Kassa/Ordrar/Parkerade/Historik belong to every trade, and a preset that merely forgot to name one must not hide a till's own sales history. A destination that becomes unreachable (re-pair into a different trade) sends the till home to Kassa, which is always reachable, so the redirect terminates. (2) **Order type is a TAX input, not a label** — tax.ts resolves the rate per line from (country, taxCategory, Motion, date) — and the native till rendered Servering/Avhämtning/Leverans unconditionally and defaulted every line to dinein`, which is a restaurant-service claim about a bottle of shampoo. It now hides the control and sends `retail` on a till without `kitchenrouting, exactly as the web till has since Phase 9. **Second-till inheritance:** the four-way trade picker on /dashboard/devices only renders while registers.length === 0, and every device after that took deviceSurface('pos').capabilities — which IS the restaurant preset. So a grocery chose **Butik** once and every till after it was born a restaurant. The trade is persisted nowhere (ConnectPosDto.vertical picks capabilities once and is discarded, so nothing in the product can ask "is this tenant a grocery?"), but the answer is already written on the tenant's own tills and the device route had that list in hand the whole time — it was reading country and currency off it and stopping there. inheritedCapabilities copies the OLDEST sibling till (the one whose trade a human chose by hand; a later till created under a wrong preset must not become the template every till after it copies), skips empty capability lists, and inherits POS-from-POS only — a KDS is kitchenrouting` by definition and copying a till's capabilities onto a customer display would hand a guest-facing screen the ability to sell. **Explicitly NOT done, and named because it is invisible otherwise:** a barbershop still cannot check a customer out on two of three surfaces — `bookingscheckout gates seven server routes and an 824-line BookingScreen.tsx that exists only in pos/web, with no Bookings destination in Kotlin at all. Also rejected: inferring the vertical from the existing free-text businessType by substring, which an adversarial pass killed — that field is z.string().min(1).max(50) with no enum, and spa is a substring of *"Spanish"* while market is one of *"Fish Market"*, so it would silently misclassify live pilot restaurants. Gates: Compose 45 suites / 556 tests (+9, four mutations caught: both gates removed, default-deny, wrong capability string); ui/src/lib/pos 101 tests (+12, seven mutations caught including two aliasing bugs where the returned list was the sibling's array or the module-level preset itself); ui npx tsc --noEmit zero errors in changed files (64 pre-existing in ui/scripts/`).

• Enheter — every device surface collapsed into ONE page with a non-technical IA (2026-07-29). Owner ask, verbatim in spirit: "In navigation I have Devices, POS Registers, Köksrouting, Devices & apps — so many nav menus for the same purpose. Make a single page 'Devices'. It should be easy to understand, easy to connect, clear separation between devices so users can see easily. A non-technical person must be able to connect PoS, KDS, SSK, customer display, menu display, printer, payment terminal and other hardware." `/dashboard/devices` is now the only door to hardware. It merges the freshly-rebuilt POS-enheter page (four register surfaces) with the six-tab Hardware Center into eight collapsible boxes, one per DEVICE TYPE, every box shaped identically: header carries Status · Öppna · Parkopplingskod, expanding it explains how to connect that device from Webbklient / Android / Windows. Boxes: Kassa (PoS) · Köksskärm (KDS) · Självbeställning (SSK) · Kunddisplay · Menydisplay & TV-skärmar · Betalterminal · Kvittoskrivare & övrig hårdvara · Nätverk & stabilitet. The tab bar is gone on purpose: a tab bar hid five of six fleets behind a click and answered none of "which of these is actually connected?", which was the question being asked — boxes show all eight statuses at once. Per-platform connection guidance is the new substance, and every line is verified against the thing it describes rather than written plausibly: the web row prints the literal address plus a one-click open (/pos, /pos-native/index.html?kds, /pos?display, /kiosk/station, /tv); Android names the launcher icon to tap — Restora POS Native for the till and Restora Kök for the kitchen, which are two genuine LAUNCHER activities in androidMain/AndroidManifest.xml, not aliases; Windows names the program (Restora360POS) and states that the KDS shortcut is the same app started with --kds (desktopMain/Main.kt, which also accepts --surface=kds). Install links come from NEXT_PUBLIC_POS_ANDROID_URL / NEXT_PUBLIC_POS_WINDOWS_URL and, because neither is set anywhere yet, render the honest line "Appen är inte publicerad än — installeras manuellt av Restora vid uppstart." instead of a button that 404s. A platform that does not apply says why, never an empty row: a receipt printer's Android row reads "utskriften går via Restora Windows Station på en dator i lokalen"; a payment terminal's web row reads "terminalen är en fysisk kortläsare, inte en sida man öppnar". Pairing direction is modelled, not narrated — it genuinely runs both ways and getting it backwards is the common support call: registers are mint (the dashboard mints a single-use 15-minute code you type INTO the till), while TV/kiosk/terminal are claim (the device shows a code you type in HERE), and printers are agent (registered here, claimed by a Windows Station). Every capability of both predecessors survives: terminal claim + enrollment QR, kiosk fleet + add-on gate, printer/drawer/scanner registry + job log, screens manager + QR pairing + the legacy shared-display link, reliability insights, owner-phone sessions, and the register-level Kassapersonal PIN admin (re-homed into the Kassa box, where a PIN is actually true). The old overview's universal three-mode pair form was dropped as pure duplication — TerminalsPanel and ScreensManager already own those flows — except its unique "POS tablet" path (pos-devices/claim, a 90-day session for the legacy android/ tablets), which became its own card worded so nobody reaches for it when they meant to pair a new till. Kitchen routing was deliberately NOT absorbed: it configures what a KDS shows rather than connecting a device, so /dashboard/pos/routing stays a real page and is hub-linked from inside the KDS box ("Konfigurera köksrouting →"). Honest-status discipline throughout: every count comes from a real endpoint (/pos/devices, /devices/summary) and a failed summary reads "Status okänd" rather than a fabricated 0; the printer box states in one line that without a connected Windows Station a receipt is stored as a preview in the job log instead of printing, because lib/devices/dispatch.ts documents the driver as a mock pending a real ESC/POS transport. Nav: the four-item "devices" group collapses to a single flat Devices link — /dashboard/pos joins ABSORBED_ROUTES as a PosRegistersRedirect stub, Köksrouting moves to HUB_LINKED_ITEMS, and Go Mobile moves to Venue Setup (despite the name it is the roaming seller's stop schedule feeding the "Find Us Today" website block — no device, no pairing, and the sole reason this group still needed a dropdown). All retired labels stay searchable as group keywords; old ?tab= deep links from the IA-2 stubs still land, mapped onto the box that absorbed them and scrolled into view. A11y: each box is a real disclosure — <button aria-expanded aria-controls> with the panel as a labelled role="region" — and the header actions are siblings of that button, never nested inside it (an <a> inside a <button> is invalid and unreachable by keyboard). 320px: title block and the three actions stack instead of overflowing. Gates: ui npx tsc --noEmit zero errors in every changed file (53 pre-existing errors elsewhere in storage/themes/experience-studio/media untouched); nav-catalog.test.ts 15/15 pass, including the absorbed-route stub, hub-link-liveness, 20-language label and retired-vocabulary guards.

• Food could be handed over with the money recorded nowhere — the whole arc, from the switch that prevents it to the chip that finds the debts (2026-08-03, `788793d0` → `de31862c`). Owner report: "i ordered an online delivery order, everything was smooth, but i didn't pay it and i was able to deliver and close the order #0020." Confirmed on the pilot tenant and systemic, not a one-off: five of twenty orders (#0001, #0002, #0003, #0012, #0020) sat at status:'delivered', paymentStatus:'pending', zero rows in `paymentLedger` and no kassakvitto — 1 855 kr of food out of the building, existing nowhere in the system. The path map (an adversarial pass, two independent verifiers per finding) established the shape of the fix: the rider's Delivered tap reaches /api/internal/pos/order-action action:'delivered' TWICE (the delivery mirror, and closePosOnlineOrder → markOnlineOrderDelivered) and the till's hand-over control posts the same action, whose entire body was appendTimeline({...order, status:'delivered'}). recordOrderPayment lives only in the 'paid' branch and recordOrderFiscalSale only under it, so neither was reachable. One chokepoint, so the rule lives there once — a guard on the rider's tap would have left the till's button open, the exact shape that had already cost two bugs the same night. (1) The hand-over does NOT refuse, and that is the design. Cash on delivery is legitimate — the order is genuinely unpaid until the door — and a person in a stairwell must never be blocked by a server. Worse: if naming a tender were the only way past, a rider whose customer has no cash would name one, and the books would then assert money that does not exist — worse than the bug, because an uncollected order is at least visibly unpaid while a false "cash" is a lie nobody can see. So the hand-over always succeeds and the DEBT IS RECORDED: handedOverUnpaidAt + unpaidAmountAtHandover, set-once, and only when the order is genuinely unpaid AND actually owes something, so a prepaid order and a gift-card-covered basket both carry nothing. (2) The reason unpaid orders existed at all. CheckoutForm seeded its method list with ["cash"] under the comment "cash is always available" — no restaurant on the platform had ever been able to decline pay-later, which is how a Swedish venue that expects prepayment collected five debts. New paymentSettings.cashEnabled, ABSENT MEANING TRUE so nothing changes on upgrade, honoured at checkout and re-decided server-side in createTenantOrder (hiding a radio button is not a rule) with carve-outs for an already-settled channel order, a ZERO total and a gift-card basket. checkout.noPaymentMethods authored in all 21 storefront languages. The dashboard switch sits above the payment rails, because everything below decides HOW money arrives and this decides whether food may leave before it does; both positions explain themselves, since a switch whose copy describes only its "on" state leaves an owner guessing what turning it off did. (3) The rider could not see what to collect. DeliveryRunDoc carried deliveryFeeMinor and a currency and nothing else about money — the phone could not have said 49 kr was due even if the rider had wanted to collect it, which is a defect BEFORE any missing ledger row. New amountDueMinor, and deliberately NOT behind `driverSeesEarnings`: that flag hides what the RUN EARNS from a salaried rider and defaults off for staff drivers, so gating the two together would have blinded exactly the venues where cash on delivery happens. Presence is the whole signal — the server omits it for a paid order and never sends a zero, so "collect 0 kr" cannot appear and a prepaid delivery looks unchanged. (4) The collection itself, on both driver clients: the amount as the hero, then Kontant / Swish / Kort — and in the same list at the same target, "Kunde inte ta betalt". The tender rides the SAME paid action the till's Betald button posts (which already writes the ledger row and registers the kassakvitto), mirrored BEFORE the delivered one because the registration mints the löpnummer the receipt must carry — pinned by a test asserting the index of one against the other. Swish joined the tender vocabulary by name, since folding it into cash would put a Swish collection in the drawer's takings and make the Z-report disagree with the till. It rides the HELD op beside the POD, so the ten-second undo takes the money record with it and a dead spot delays rather than loses it. (5) The debts are visible: a new owing chip on the order history, on all three POS surfaces. Deliberately NOT a synonym for unpaid — an order placed five minutes ago for cash on delivery is unpaid and fine, so the chip needs BOTH halves, unpaid AND already handed over, with cancelled excluded because an order nobody received is not a debt. It issues no till read at all (a closed till sale is paid by construction). Verified live on the pilot tenant: owing returns exactly the five, unpaid returns nine. The five are deliberately NOT backfilled — nobody knows whether that money was collected, and marking them paid would be inventing a fact; they show as what they are. One shape appeared three times in one day and is worth naming: a request body assembled field by field silently drops anything not listed — the backend write-back dropped method (every door collection would have arrived as unnamed cash), the web opWireBody dropped the tender, and the Kotlin DriverDeliverRequest would have too. All three are now explicit with a comment saying why. Gates: backend POS 196 sales / 199 delivery, Compose 531, pos/web 75, ui orders+fiscal 156, Swedish ratchet at baseline, pos-publish-gate green.

• Find one order from the counter, a cancelled order that finally goes away, and a promise that stops moving (2026-08-03, `d2b772ee` + `0a274c18`). Four owner reports from the same session, two of which turned out to be the same defect shape as the night before. (1) "order history under Ordrar" — the scenario given was a telephone call at the counter: "suppose a customer calls and say i ordered a pepsi but i didn't received it, the cashier can quickly bring the order from history and double check if the pepsi was really inside that order." That makes search the feature and placement the smaller half, because an order from three days ago is on no first page. GET /pos/kitchen/orders/history gains q, matched against the order reference OR the customer name and pushed into both journals' queries — a search filtering rows the cap had already cut would hide the single row the feature exists to surface, which is precisely the chip-filter defect fixed hours earlier. The TYPED TERM is normalised, never the stored value: a leading # is stripped (it is how the product prints an order number, never how it stores one, so leaving it in makes the most natural thing to type the one thing that never matches), and leading zeros go only when what remains is all digits — #0042, 0042 and 42 are one answer while 007agent keeps its zeros, and 000 stays a search for 0 rather than becoming a search for everything. Blank or a lone # means NO search, never "match nothing". Every regex metacharacter is escaped, so a cashier typing ( gets no match rather than a 500. Ordrar gains a Live/Historik segmented control mounting the SAME component the rail destination mounts — deliberately not a fork, commented on all four screen files because Historik owns refunds and somebody will otherwise "dedupe" it. Found on the way: the Compose history screen drew a network error AND "no orders in this period" together; conflating those is what made the original complaint invisible. (2) "why order #0016 is visible in my PoS there is no way for me to hide that from my order view." There was not: the FOH Orders read had a tenant, a channel, a 24-hour window and a deliveredAt check and no status predicate at all — and a cancelled order never gets a deliveredAt, so it sat on the till for a full 24 hours with nothing on screen able to clear it. Cancelled tickets now leave that view, excluded rather than aged out on a shorter timer because "why is this still here" was the question and a 30-minute answer is still 30 minutes of it. It also makes the FOH view agree with the KDS board, which has always dropped cancelled tickets — the kitchen never saw #0016, only the front of house did. Nothing is lost: the cancellation is in the journal and history has a cancelled chip. Pinned at the QUERY, because it is a filter clause and a service test over a mocked repository would pass with the clause deleted. Verified live on the pilot tenant: #0016 absent from the board while present in history, and q=16 / q=#0016 / q=0016 each returning exactly it. (3) + (4) "the timer resets to 35 min when i accept" and "add set delivery time while accepting — 10, 15 … 60 and custom like 2 hours" — one feature, because accepting is when the promise is made. TrackerClient computed the target on every render as preparingStartedAt ?? acceptedAt ?? createdAt + prep, so the anchor moved forward every time a later timestamp appeared: createdAt before acceptance, acceptedAt after (the reported reset), and preparingStartedAt after that — a second reset nobody reported only because they had stopped watching. A promised time recomputed from whichever stamp is newest is not a promise. It is now minted once at acceptance and stored as an absolute instant; what crosses the wire between the POS and the legacy order is that instant and never the minutes, since re-anchoring minutes on the far side's clock lands seconds away from what the operator was shown. It rides the same conditional awaitingAcceptance: true update as the acceptance, so a losing double-tap cannot move a time a guest is already counting down to. `createdAt` is gone from the anchor chain entirely — placing an order is the GUEST's act, not the venue's promise, and treating it as one is what put a 35-minute countdown on screen before anyone in the kitchen had seen the order; no acceptance now means no countdown, which the tracker type already had a spelling for (null ⇒ hide). The picker: presets 10/15/20/25/30/35/40/45/50/60 in a grid where tapping one accepts (two taps for the common case), "accept without a time" always one tap away in the same sheet so speed never became a required field, and custom one extra tap giving hours and minutes as steppers rather than arithmetic in a minutes box. Validation is a RANGE (1–480), not the preset grid, because 150 is a legitimate answer on no grid; eight hours is the ceiling since past that it is a booking, not a prep time. An absent value stores no promise rather than inventing one, which would silently overrule the venue's configured preparation time. Every accepted card now shows the promise as a wall clock ("Klar 19:35") so an operator quotes the clock the guest is watching. Legacy orders fall back to the venue estimate anchored on acceptedAt (set-once, so it cannot drift); an unparseable promise degrades to that estimate and an unparseable anchor hides the chip rather than rendering NaN; and un-accepting now strips the stale promise, or a re-accept with no chosen time would resurrect a countdown the kitchen is no longer working to. Gates: backend 54 suites / 740 tests, Compose 531 (+ wasmJs compiles), pos/web 75, ui order-tracking 38, Swedish ratchet at baseline 0, pos-publish-gate and check-addressing green, bundle republished so web and Windows carry it too.

• Order history that actually contains the orders, on all three POS surfaces — plus the Bord side panel and a test print that speaks the printer's language (2026-08-03, `7566c1ec`). Three owner reports from one evening of live testing, each of which turned out to be a different piece of code lying about what it had done. (1) "i cant see the order history on my PoS android tablet." The Historik tab existed — wired to GET /tickets?status=closed, which the server pins to the asking register. So it showed that till's own receipts and never once an online, pickup or delivery order, because those have never been POS tickets. New register-token route `GET /pos/kitchen/orders/history` (RegisterGuard + capability sell, no @RequiresOperator so a manager may look at a signed-out till, and no tenantId from the client — the token resolves the scope) merging the two POS-owned journals: pos_tickets closed sales tenant-wide (the half the old read could never answer) and pos_kitchen_tickets online orders, plus one $in over pos_tenders for payment method. Window clamped to 31 days (default 7, never into the future, an inverted range falls back rather than 400s), limit capped at 200, both reads verified to ride the existing tenant_closedAt / tenant_channel_firedAt indexes, and no money arithmetic anywhere — every figure is a stored integer copied out of a document, and online lines get no price rather than one derived from the total. Two defects the adversarial pass caught before it shipped, both of which would have reproduced the original complaint: truncated watched each journal's own cap while the CUT was applied to the merged array, so 60 till + 60 online at limit 100 capped neither source and the flag said "complete" while slice() dropped the 20 oldest (now rows.length > limit || tillDocs.length >= limit || onlineDocs.length >= limit — the second clause still needed, because one source capped at exactly limit gives rows.length === limit, not greater); and the chips filtered in memory, after the per-source cap, so asking for cancelled read the newest 100 of each and then filtered — an empty list meaning "your filter fell off the end of a cap you cannot see" while reading as "there are no orders". Filters are now Mongo predicates built per journal, and a chip no document in that journal could match skips the read entirely rather than round-tripping for nothing. It also landed on ONE surface, which ships nothing: `pos/web` now reads the same route with the same behaviour and `ui/public/pos` is republished in the same commit — without that the browser till and the Windows station keep serving the old screen and check-pos-surfaces stays red. (2) "on 'tables' section there are three rows named 'Nota' 'inget bord' looks messy." Those are bills the floor plan cannot draw — deleted tables, tables with no designer coordinates, counter sales bound to nothing — crammed into a 168 dp scroll box between the floor tabs and the room. They now live in a right-hand panel (BoxWithConstraints, the same 820 dp / 1180 dp breakpoints and PosVerticalDivider as RegisterScreen, so the two screens agree) which also carries today's bookings including the unseated ones the old derivation fetched and threw away, and for a selected table its seats/area/floor, its bills and its booking. That content is the dialog previously reachable only by a three-second hold; the dialog survives as the narrow-screen fallback. 15 findings raised in verification, 14 refuted — and what came back clean is what mattered: the bill-ownership guard, the also-on-this-table set, and primaryAction being branch-identical to the old open(), so no action can target a bill the screen is wrong about (four bills were stranded by this exact flow in the past). The one survivor is fixed: the compact bar could advertise "Notor utan bord (2)" and reopen onto a table tapped earlier, cleared on entry rather than on close, because after a window resize nothing closed and a reset on the close path leaves half the bug alive. (3) Three test prints to a reachable Zebra produced no paper — and the app said they succeeded. printOne() has always resolved the printer's language and encoded accordingly; testPrint() and connectTo() called escPosText() unconditionally. A ZPL printer discards anything outside ^XA…^XZ, so the socket accepted every byte, the write flushed, the transport honestly reported Written, and the screen reported success. A silent false success is the worst failure this agent can have, and it is the same bug class printer-language.test.ts already pins on the web side. Both test paths now resolve once through resolvePrinterLanguage (stored → inferred from the printer's announced name → ESC/POS) and encode accordingly, with an on-device ^XA…^XZ test label opening ^CI28. Inference is never persisted, so a later discovery cannot overwrite an operator's explicit choice, and unpair()/setTarget() keep the language for the same reason they already keep the address. The settings card asks in plain words what kind of printer it is (naming the command set in parentheses for whoever needs it) and states out loud what happens if you pick wrong. Gates: backend POS 701 tests, Compose desktop 507, pos/web 51, tsc clean, Swedish-literal ratchet unchanged, pos-publish-gate and check-addressing green.

• Food Delivery — own drivers, end to end (2026-08-02, R360-C12). A restaurant's OWN delivery fleet: roster + phone pairing, order-to-driver dispatch, live tracking for dispatcher AND customer, proof of delivery, offline-safe driver taps, settings, analytics. NOT the aggregator integration — isOwnDeliveryOrder() remains the discriminator and lib/delivery/providers is untouched. Plan of record: docs/products/food-delivery/FOOD-DELIVERY-PLAN.md; runbook beside it. Backend: new PosDeliveryModule (backend/src/modules/pos/delivery/, six-file anatomy) over 7 typed collections (delivery_drivers/devices/pairing_codes/runs/driver_frames/events/settings, indexed same-PR). A driver phone is deliberately NOT a pos_registers row (no fiscal seriesPrefix, no SE-journal enumeration): it pairs like a customer display — dashboard mints a single-use 8-char code (15-min expiry, 7-day explainable retention), phone exchanges it for a 48-byte token, sha256-only at rest, x-driver-token → DriverTokenGuard → DriverScope that never sets posScope, so a leaked driver token reaches exactly one module. Run machine has FIVE tappable statuses (pending→offered→accepted→picked_up→delivered, terminals failed/canceled) — "heading to restaurant / driving / near customer" are derived from GPS, never tapped. Every driver tap carries a ULID opId spent in delivery_events INSIDE the same transaction as the CAS transition; the E11000 replay answer is caught AROUND the transaction (swallowing it inside commits an aborted txn and loops to the 120 s cap — the sales-path lesson) and must prove same-run/same-kind/same-driver against the stored event, or a spent opId POSTed at another runId would hand back that run's customer sheet. "One live run per order" is database-backed (openKey = orderId while non-terminal, unique partial index, $unset on terminal transitions) so a dispatcher double-click cannot send two drivers to one customer. Offers expire by clock ON READ (no cron), CAS-guarded across replicas, with the expiry bound pinned in the accept CAS (+15 s grace) so a stale accept refuses deterministically; auto-reoffer walks online drivers with capacity, remembering who declined. Live positions are a display-frame-courier clone: one replaceable TTL doc per driver, rev bumped only on real movement, >200 km/h implied-speed frames stored but flagged suspect and excluded from ETA. Dashboard: /dashboard/dispatch (Board/Drivers/Settings/Insights) behind new own-delivery feature (registry + nav + 20-language label + dispatch→orders.manage); three-lane board with keyless-OSM driver map, 2-tap assign, pairing modal with giant code + QR, POD/offer/leave-at-door settings, analytics in integer öre. 15 thin proxies under /api/tenant/[tenantId]/dispatch/* (requireTenantAccess + requireFeature + requireWritable/requirePermission on writes). Driver app: /driver (proxy-bypassed, mobile-web v1 — the backend contract is byte-portable to the Kotlin/Compose port per the plan's decision table), sv/en, huge one-primary-action screens, ?pair= deep link, Navigate/Call deep links, KdsOutbox-rule offline outbox (dedupe-key supersede, FIFO drain gated ahead of every poll, queue-on-undecided/drop-on-decided, revocation keeps the queue; drain re-reads the live queue after every await so a mid-flight tap is never clobbered, and a live send queues behind ANY queued op for the same run so a deliver can't jump its own pickup), GPS publisher (8 s visible / 30 s hidden-with-active-run), POD sheet (photo downscaled to a ≤200 KB scheme-pinned data-URL — honest v1 seam, TODO device-scoped media upload; signature canvas; PIN recorded-not-verified). Customer: both existing trackers (/track and the emailed /bazar/orders/…?t=) now render a "Your driver" card — first name ONLY (the write-back itself sends only the first name, since the public tracker returns the order timeline raw), vehicle, server-computed ETA, live mini-map only while picked_up AND the tenant allows it, coarse-rounded coords, POD line at delivered. Order mirror rides the existing idempotent /api/internal/pos/order-action seam with three new set-once actions (driver_assigned/out_for_delivery/delivery_failed) — order status union deliberately untouched; deriveStatus advances on the new outForDeliveryAt timestamp. Fixed en route: the OUTSTANDING-WORK §4 dead-code item — status-transition logic extracted to pure apply-status-transition.ts, wired into the dashboard PATCH route, backward moves clear forward stamps including outForDeliveryAt. Gates: backend tsc clean + full jest 560/560 (68 delivery tests: pairing incl. cross-tenant name-inheritance refusal and claim-before-mint ordering, run machine incl. replay-mismatch refusals and the double-click race, route-plan 2-opt, ETA clamps, frame throttle/suspect, track-info privacy); ui delivery/driver/tracking/dispatch node tests green (outbox 20, tracking+model+templates 89, dispatch 9); ui tsc zero errors in every new/touched file. Load harness: scripts/delivery-sim.mjs (N virtual drivers over the real HTTP contract, with a deliver-replay idempotency probe).

• One gift-card store — the parallel-systems split closed end to end (2026-08-01, P1 `3eb80c6f` / P2 `5735d083` / P3). Gift cards were TWO systems that never read each other: db.giftCards on the tenant blob (24 modules — buy page, corporate bulk, subscriptions, wallet passes, risk, closed-loop; major-unit floats) and the POS's pos_giftcards + ledger (integer minor, transactional). A website card was refused at the till, a till card was invisible to the dashboard, and account 2421 drifted structurally negative. Owner ruling: one store — the POS collections win the storage, the legacy design wins the features (docs/pos-rebuild/one-giftcard-design.md). P1 (backend): five InternalGuard endpoints — full-fidelity mirror issue (pinned legacy codes normalized so GIFT-K3FX-9A2P stays findable, legacyId idempotent from either side, a caller-pinned code REFUSES on collision rather than rerolling), find by code/cardId, windowed list, and an online redeem / refund-credit / void trio: own transactions, deterministic-opId idempotency, a void records the dying balance in the ledger before zeroing so Σ ledger ≡ balance survives. P2 (the cutover machinery): GiftCard.posCardId marks a card as pos-authoritative; getCardByCode/ById dual-read (marked cards overlay LIVE balance, misses fall through to the pos store — which is how till-issued cards appear everywhere at once); every in-lock mutator refuses marked cards (apply THROWS — a route reaching it has a routing bug; reverse SKIPS — it runs in rollback locks, and the pos-side reversal owns the credit), making the cross-store double-spend unrepresentable rather than unlikely. Online redemption lands in the ONE seam (createTenantOrder) + payment-intent: detected pre-lock, settled post-lock like the closed-loop precedent, idempotent per order, live re-capped, a refusal applies 0 and the PSP charges the full remainder so a failure can cost the guest nothing; rollbacks credit the pos card back money-first (no refund row unless the credit committed). markPurchasePaid mirrors each activation into the one store best-effort (stamp only after commit; the re-runnable migration sweeps failures). The dashboard list merges both stores and says posStoreIncluded:false instead of degrading silently. Scripts, written NOT run (rule 6): the migration now stamps + re-heals posCardId on the blob; tombstone-legacy-giftcards.ts renames giftCards → giftCardsMigrated only after verifying every card has a pos twin — one uncovered card refuses the whole run. P3 (books): till-issued presentkort now CREDIT 2421 through the same purchased-card shape the buy page books (tillIssuedGross reports it); pre-cutover windows keep their credits post-tombstone via giftCardsMigrated; an unreachable gift store raises a critical books notice instead of quietly booking nothing. Gates: backend giftcards 31, ui gift-cards 74 (incl. the new guard suite, proven non-vacuous — disabling the guard fails exactly its throw-tests), orders 72; tsc + eslint clean; both scripts dry-run clean.

• Paying at the counter for an online order printed nothing — and the pin that should have caught the kitchen bong drifting had been red for days (2026-08-03). Owner report from a live test: an order was placed online, accepted at the till, marked paid by card, and no receipt came out. Not a printer fault. planOrderJobs gates the receipt on order.paymentStatus === 'paid' and it runs once, at creation — an order placed "pay on pickup" is pending at that moment, so it correctly plans no receipt, and nothing ever asked again. The till's Betald button posts to /api/internal/pos/order-action with action:'paid', which wrote the ledger row, flipped the status, and dispatched no hardware at all; every guest paying at the counter for an order they placed online has been handed nothing since the acceptance split landed. New pure planCounterPaymentJobs + its fire-and-forget wrapper, in the shape this file already uses (pure planner, thin I/O). Deliberately NOT a second `planOrderJobs` call, which would plan all four documents off a now-paid order: a second delivery slip (creation already printed one — it fires regardless of payment precisely so a COD driver has paperwork, and two slips in a driver's hand is worse than one) and a second kitchen bong (acceptance owns that; a duplicate ticket landing on the pass mid-service is the exact failure dispatchHardwareForFiscalExtra was carved out to avoid). So: the receipt, plus the drawer kick on cash — the till is not running its own sale flow here, so nothing else would open the drawer. It does not invent a kassakvitto: buildReceiptFiscal is called exactly as the sale path calls it, and an unregistered sale yields undefined so the renderer prints no receipt number and no VAT rate table rather than fabricating either. Explicitly left open and raised with the owner rather than closed quietly: whether this path should also REGISTER the sale. recordOrderFiscalSale is called from four places (order create when born-paid, the payment-rail settlement, both POS payment routes) and not from here — so on a Swedish tenant, an online order paid at the counter is money taken with no fiscal registration. That is a compliance decision about money, not a rendering bug, and it is the owner's call. The second half: printer-language.test.ts's PINNED.kitchen / .kitchenNoStation had been FAILING on master since the richer-bong work (cac877d5) and the allergen chain (4b.2) landed without re-taking them. A red pin protects nothing, and this one guards what a cook reads off the pass — so it sat unguarded while exactly the content it watches was being changed. Both tickets were rendered and read before the digests moved (the deliberate act the file's header demands): four lines are new versus the layout the old note describes, and a kitchen needs all four — the chosen option (• Storlek: Familj), added toppings (+ Extra ost), the line note (! extra het), and, as 4b.2 intended, the order note reaching the pass (Obs: allergi: nötter), which is the only one here that could put somebody in hospital. RECEIPT and DELIVERY SLIP digests untouched, which is how we know the change was contained to the bong. Gates: ui devices suites 210/210, tsc --noEmit clean in every touched file.

• A rider standing in his own kitchen marked a delivery complete, and there was no way back (2026-08-03). Owner report from live use: "delivered button should be removed as i accedentally pressed the delivered button while i was at home." Two changes, because one would not have been enough. The list can no longer finish a delivery. driverCardAction is now the only thing deciding what a home card offers, and it has no branch that returns a completing action — DriverCardAction.completesDelivery is false for every value it can produce, and the test asserts that over the whole status enum rather than over the cases somebody remembered to write. Finishing moved inside the run, where the rider has already chosen that order and can see whose door it is. And the tap is no longer instant. A deliver op is queued with an ABSOLUTE deadline ten seconds out; the drain steps over it until the deadline passes, so undo is a REMOVAL FROM THE QUEUE and never a reversal on the server — nothing to compensate, nothing to explain to a customer whose tracker already said "delivered". The deadline is absolute so it survives process death (relaunch inside the window redraws the strip with the correct seconds remaining), a held op does not wedge the ops behind it (except one carrying the same runId, which must not overtake its sibling), a hold is not counted as "waiting on the server" so a 4-bar phone never paints itself Offline, and a clock that lies in EITHER direction still ends with the delivery sent — a wrong clock can cost a rider their undo, never strand a delivery. Delivery instructions also got their own box, having been one more line in the address block, which is where a rider stops reading. Built on both clients from one rule (DriverRunPresentation.kt / list-action.ts). Gates: DriverDeliverHoldTest 24, DriverRunPresentationTest 8, full Compose desktop suite 485/485 including the Swedish-literal ratchet; web driver suites 94/94.

• A printer that nobody talks to falls off the network, and the POS now holds it awake (2026-08-03). Owner report: a Zebra dropped off the network about a minute after its last conversation, every time — hold the feed button, the network light goes green, a minute later it is gone. Ordinary power management (a printer with nothing to print lets its radio sleep), invisible until the moment it matters, which is a kitchen ticket at half past seven. Nothing was going to fix that at the printer; keeping it awake is the POS's job and it costs one TCP connect every twenty seconds on a LAN. The probe writes ZERO BYTES. Port 9100 is a one-way stream with no reply channel, so there is no "are you there" command — any non-empty probe would be a document, and a document on a thermal printer is paper; a venue whose roll ran out overnight because the POS was checking on it three times a minute would be right to be furious. An empty write still requires the radio awake to complete the handshake, which is the whole thing being kept alive, and it physically cannot print, cut or kick a drawer. Twenty seconds because the observed drop was "a minute or so" and vendor idle timers are commonly 60 s with no way to read the remaining time from outside — three touches inside the shortest window actually observed, so one missed probe does not cost the connection. It is not a print and the counters do not say it was (recordOutcome is not called, so printed stays a number about tickets that came out); a FAILED probe does set lastIssue, because a printer that has gone away is what that line is for, but a successful one never CLEARS it — a jam, an open cover and an empty roll all answer their socket perfectly, and a screen that went green twenty seconds after a real failure would be worse than one that stayed red. New KeepAlive step covers the case the owner is actually in (a printer chosen in settings, no print-agent pairing code ever redeemed); the zero-cost promise holds for everyone else, since a configured target is the only thing that turns a quiet tablet into one that opens sockets. Stated honestly in the KDoc: this keeps an AWAKE printer awake and cannot wake one already asleep with its radio down — nothing on a tablet can. +8 tests in PrintAgentPolicyTest; full Compose desktop suite green.

• `/ingredient` said "being populated. Check back soon." forever, and the weekly ingredient-catalog refresh had been silently failing since the docker-compose migration (2026-08-02). Owner report: the ingredient directory was broken, and the weekly USDA/Livsmedelsverket refresh the owner had configured with real API keys wasn't reaching the database. Two infrastructure bugs, both on the box, neither in application code: (1) the owner's CRON_SECRET and USDA_FDC_API_KEY were sitting in ui/.env.production.local — a file the OLD bare-next start/pm2 deployment read directly, but the current docker-compose setup never loads; the running container saw neither variable. (2) the crontab's dispatcher script (restora-cron.sh, not tracked in this repo — box-local ops tooling) was still hardcoded to http://127.0.0.1:3001, the old pm2 port; the docker-compose ui container has always been on 3000, so every cron route routed through this script — not just the two catalog imports, also fsn-job-expiry, weather-refresh, daily-briefings, inventory-reports, fsn-account-purge, bazar-visit-reminders, tv-ads-settle, scheduled-reports, anomaly-alerts — had been connection-refused-failing silently since the migration, logged to a file nobody was watching. Fixed both: the real keys now live in docker.env (the file docker-compose actually reads), and the script's BASE now points at :3000. Verified live: catalog-usda-import run three times back-to-back pulled the complete USDA FoodData Central dataset — 8,187 real records — into platform_data/food-catalog; /ingredient now serves it. Found in the process, not fixed (it isn't ours to fix): Livsmedelsverket's own public list API (dataportal.livsmedelsverket.se/livsmedel/api/v1/livsmedel) returns totalRecords:0 right now for every valid parameter combination (confirmed against their published Swagger spec — offset/limit/sprak, none required beyond the path version), while their by-id nutrient lookup for the same dataset still serves real historical data — an external, upstream issue on the Swedish agency's side, not a bug in our importer, and not something a code change here can fix. What WAS ours to fix: the cron route treated that empty response identically to a healthy end-of-cycle wrap (ok:true, processed:0) — the same "missing dependency renders as an empty success" shape this platform keeps re-learning the hard way. It now distinguishes a fresh-cycle empty response (cursorAtStart===0 && total===0) from the normal wrap and logs it as an error with the exact upstream URL to check, plus a sourceEmpty flag in the response — loud instead of indistinguishable from success. tsc --noEmit zero errors; eslint clean.

• Two public layouts flashed a hydration mismatch on every load: `data-theme` was hardcoded `"light"` in server-rendered JSX while a no-FOUC script overwrote it before hydration (2026-08-02). (bazar)/bazar/layout.tsx and fsn/layout.tsx both render data-theme="light" unconditionally, then a plain <script dangerouslySetInnerHTML> reads the saved preference / system setting and calls setAttribute('data-theme', …) on that same element before React hydrates — the standard technique for avoiding a flash of the wrong theme on first paint. Every OTHER instance of this exact pattern in the codebase (AtmosphereShell.tsx, StudioShell.tsx, ShopShell.tsx, admin/atmosphere/AdminShell.tsx) already carries suppressHydrationWarning on the target element for precisely this reason — only these two were missing it, so every dark-mode visitor to Food Bazar or FSN got a real (if functionally harmless) hydration-mismatch error in the console, plus a secondary "script tag" warning as a side effect of React discarding and regenerating the subtree. Fixed the same way as everywhere else: suppressHydrationWarning added to both root elements, element-scoped so genuine mismatches elsewhere in the tree still surface. No behavior change — the attribute was always correct after the no-FOUC script ran; only the warning was spurious. tsc --noEmit zero errors in both files; eslint clean.

• `tombstone-legacy-giftcards.ts` retracted before it was ever run for real (2026-08-02). The P2 gift-card cutover (previous entry) called for a final step: rename db.giftCards → db.giftCardsMigrated once every card was mirrored into pos_giftcards, on the assumption that blob writes would stop after cutover. That assumption is false — a full-repo grep found 15+ files outside the gift-cards module (gift-card analytics + its narrative, disputes, CRM guest360, marketing analytics, referral tracking, wallet passes/disputes, a payments refund route, bulk + transactions routes, a scheduled-release cron) reading db.giftCards directly, every one guarded with ?? []. Renaming the field would not have crashed a single one of them — it would have made all of them silently report zero gift cards forever, discovered by an owner or auditor months later rather than by an error anyone saw at the time. Corrected architecture: db.giftCards is permanent — the feature/compliance/analytics store, standing forever alongside pos_giftcards (the money store), tied by posCardId. The script was renamed to giftcards-migration-coverage.ts, lost --apply entirely (hard refusal if passed), and now only reports mirror coverage, read-only. The now-dead giftCardsMigrated schema field and its bookkeeping-route fallback read were removed. Verified live on the staging box against a purpose-built DK test tenant (created via the real signup API, never touching real tenant data): the full lifecycle — issue, find, list, dashboard merge, redeem with a proven idempotent replay, void — against real Mongo, ledger reconciling to exactly zero (10000 − 3000 − 7000 = 0), and the P3 bookkeeping credit (tillIssuedGross) confirmed live. The market gate (a separate, unrelated, pre-existing control) was independently confirmed identical and correctly closed for both Sweden (the real pilot tenant) and Denmark (the test tenant) — no bypass taken; that gate has no override by design and faking it would be exactly the class of surprise this correction exists to prevent.

• Seven more surfaces told the outside world nothing, or told it the wrong language (2026-08-01). A sweep for the rest of the class behind the two fixes below, done before it could be reported one surface at a time. All of them read owner-authored locale-keyed text with a chain that stops at English, and all of them speak to someone outside the business. The worst was the AI assistant's own restaurant context (api/tenant/[tenantId]/ai/route.ts): the description read .en, every product name read .en, and the category heading interpolated cat.name — a Record<string,string> — raw, so the system prompt for any Swedish venue read [object Object]: , , , and the model was handed an empty description above a menu of blank names. It then answered questions about the restaurant confidently, with nothing in the prompt to signal that everything it had been told was missing. The Google Business Profile sync declared one language and sent another: sync-engine.ts shipped languageCode: s.defaultLanguage and, two lines later, description: s.description?.en ?? '' — telling Google the text was Swedish while sending the English field, or an empty string when there wasn't one. Its twin in sync-diff.ts carried the identical expression, so the two are now pinned as a pair: if they ever diverge, the diff computes one description and the engine pushes another, and the profile reports a phantom "description changed" on every sync forever. Also fixed: the Food Bazar marketplace listing (api/bazar/restaurants), whose card description was .en ?? '' for the object shape and a flat '' for the legacy plain-string shape, so a Swedish restaurant appeared in the public marketplace with no description at all; `llms.txt`, the restaurant's self-description for AI crawlers, blank for the same reason, and its Popular-dishes list which preferred English; `seo/generate`, whose fact pack fed the model an empty description and English item names when generating meta for a Swedish site; and the voice concierge's audit trail, which recorded productName: p.name?.en ?? p.id — so the record of what a machine changed on someone's menu said prd_till_01j… instead of naming the dish. Two defect shapes, one cure: .en ?? "" dead-ends and renders nothing; .en ?? Object.values(rec)[0] never blanks but prefers English, so a venue that translated its menu reads "Shrimp sandwich" on its own Swedish pages — the exact swap the backend's resolveText was fixed for. Both now ask translate() in the venue's language. Explicitly NOT changed, and the distinction matters: the dashboard's editor endpoints (api/tenant/[tenantId]/menu/products/*, ProductEditorModal.tsx) read .en because they edit the English field — a fallback there would put the Swedish text in the English input and save it back over the English one, so the same reasoning that makes a fallback right on every surface above makes it data corruption there. The guard's GUARDED list grew from 3 files to 10 with that exclusion written into it, and its pattern widened from "dead-ends at a string literal" to "any fallback chain built around .en". 26 tests; the two new guard shapes proven non-vacuous — reintroducing a .en ?? Object.values(…) chain fails with the file and line, and desynchronising the Google pair fails the pair test. tsc --noEmit zero errors in all eight changed files; eslint clean. (Unrelated pre-existing failure left alone: `google/rwg.test.ts` asserts `luigi.restora360.com` and gets `luigi.localhost:3001` — an env-dependent host, in a module that imports neither file touched here.)

• An untranslated blog post rendered as "Untitled" over an empty article — including in the share card (2026-08-01). Found while fixing the till-authored dish below; same defect, one surface over, and left open at the time because it was outside what was reported. BlogList.tsx and blog/[slug]/page.tsx both resolved post.title and post.content as [lang] ?? .en ?? 'Untitled' / '', so a post written only in the venue's language — the normal case, since the dashboard leaves untranslated locales blank rather than duplicating text — showed on a site in any other language as a card titled "Untitled" with no excerpt, and opened to a headline over a blank article. generateMetadata had the same two lines, so the <title>, the Open Graph title and the description were "Untitled" and empty too: the version that gets shared into a chat, indexed by Google and previewed by a link unfurler, which is the only thing anyone sees before deciding to click. All three now resolve through the shared translate() (lang → en → whatever the post actually has), so the article renders in the language it was written in rather than not at all; "Untitled" survives only as the last resort for a post with genuinely no title, which is a different thing and still worth labelling. Falling back can show a reader a language they did not ask for — deliberate, and the same call already made for dish names: the thing it replaces is an empty page. The guard grew rather than being duplicated: storefront-menu-names.test.ts became lib/i18n/storefront-text-fallback.test.ts, moved to the module that owns the rule, and now walks a GUARDED list of the three storefront surfaces that render owner-authored locale-keyed text, asserting each imports translate and declares no chain terminating at English. Its pattern was widened from .en ?? "" to .en ?? <any string literal>, because ?? 'Untitled' is the same dead end wearing a name — proven by reintroducing that exact line and watching the guard name it. 11 tests, all green; tsc --noEmit zero errors in every changed file; eslint clean.

• A dish added from a till showed on the website as a price with no name (2026-08-01). Owner report, verbatim: "menu page on website is not updating completly the name of for menu item is missing. my friend from his windows PoS added 'redbull pink' but it just shows the price not the item name on website." Nothing was missing from the database and nothing failed to sync — the dish was in the tenant blob, the dashboard listed it, and the home-page menu teaser rendered it correctly. Only the full menu page was blank, because MenuClient.tsx held two resolvers for the same localized record and the page rendered through the wrong one: loc() at line 451 was rec[lang] ?? rec.en ?? Object.values(rec)[0] ?? '', while t() at line 957 — the one behind every category heading, dish name, description and ingredient list on that page — was val[lang] ?? val.en ?? "", one fallback short. A till writes a dish under the venue's language only ({sv:'Redbull pink'}, deliberately: a till has one text field, and inventing translations is worse than leaving them visibly untranslated for the owner to fill in), so on a site whose language is not that one, t() returned "". The price is a number and rendered fine; only the name vanished, which reads like a font or a sync bug and is really a missing ??. The same shape had already been found and fixed on the backend — resolveText once preferred en unconditionally and showed "Shrimp sandwich" for "Räksmörgås" (menu-fidelity.spec.ts); this was that bug on the website's read side. There is now one resolver in the file, delegating to the shared translate() from @/lib/i18n, which also guards the plain-string names old seeds and imports still carry (Object.values('Margherita')[0] is 'M'). `QuickAddButton` had the same defect and mattered more: its name string becomes the cart line name, so a guest ordering a till-authored dish sent a nameless line to the order, the receipt and the kitchen — not just a blank label on a page. The root cause on the write side is fixed too: POS_AUTHORED_LANG in catalog.service.ts was hardcoded 'sv' while its own comment said "the venue's" — the hardcoded-locale twin of the hardcoded currency, made on the write side this time. It now follows settings.defaultLanguage from the menu blob (lowercased, two-letter codes only, so an owner-typed 'English' or 'sv-SE' cannot mint a key no reader ever asks for), falling back to the primary market only when a tenant has set no language. No data migration is needed and none was written — items already stored under sv now resolve through the fallback on every surface, and the till reads them back through resolveText, which has the full chain. Gates: storefront-menu-names.test.ts (6 tests — the venue-language-only render, the requested language still winning when a dish is translated, the plain-string case, plus a source guard that fails if the menu renderer ever re-declares a fallback terminating at English) and till-authored-item-shape.spec.ts grew from 14 to 19; both guards proven non-vacuous — reintroducing val[lang] ?? val.en ?? "" fails the source guard with the offending line number, and pinning the write back to 'sv' fails exactly the three venue-language tests. tsc --noEmit zero errors in every changed file; eslint clean; the whole POS catalog suite (126) green.

• A guest can no longer book more people than the table seats — and shrinking a table under a live booking is no longer silent (2026-08-01). Owner report, verbatim: "When booking 2 person table. The option for add more guests should be disabled. But today I can add more while booking table online." — reported minutes after editing table 1 from 6 seats down to 2 while someone was mid-booking on it. Both are the same missing invariant. The rule now has ONE owner: lib/reservations/table-occupancy.ts — the module whose own header already called itself "the ONE rule the public floor picker and the reservation POST must agree on" but only implemented occupancy — gains tableFitsParty / tableTooSmallMessage / maxPartyForTable / overCapacityBookings, and every path imports them instead of re-deciding. Server first, on every write path that binds a tableId: POST /api/public/[tenantId]/reservation (the wizard flow) had no capacity check at all — a party of 10 on a 2-seat table was a 201; it now 409s with the shared sentence. POST /api/public/book/[slug] keeps its check but through the shared helper, also refuses guests.length > party (a hand-rolled body could smuggle 8 covers past a party of 2), and no longer persists a tableId when the venue has no saved layout to validate it against. POST /api/tenant/[tenantId]/reservations — which declared itself "called from the public customer site — no auth check needed" and validated nothing (no schema, no party bounds, no availability, Number(guestCount) happily storing NaN, reachable by anyone on the internet, and with no in-repo caller, because the public site posts to /api/public/*) — is now what it lives under: requirePermission(tenantId, 'reservations.manage') + the new StaffCreateReservationSchema. The manager override is deliberate and lives in exactly one place: a restaurant genuinely does seat three at a two-top by pulling up a chair, so the STAFF route (and only it) accepts allowOverCapacity: true — explicit, never the default, absent from every guest-facing schema — and stamps Reservation.seatedOverCapacityBy plus an activity line, so the floor sees that a human chose it rather than that a rule leaked. All four checks are now atomic with the write: the two public POSTs and the layout PUT moved from lock-free getTenantDB→saveTenantDB onto mutateTenantDB, so capacity/occupancy/availability are decided inside the same CAS section that appends — a concurrent designer shrink can no longer land in the gap, and a booking can no longer be erased by whichever whole-document write finished last. The control the owner actually touched: BookingFloorPicker's party clamp was a hard-coded Math.min(12, n) that never consulted the table, and raising the party silently NULLED the selected table and time — leaving canContinue true, confirm() early-returning, and a live-looking Confirm button that did nothing. The ceiling is now maxPartyForTable(selectedTable, biggestTableInTheRoom); the "+" stepper and the "Add another guest" button are disabled at it with the reason printed underneath ("Table 1 seats 2 — pick a larger table to add more"); canContinue re-tests table + time so the dead button is unreachable; the stale-closure in the old arrival reconciliation and the setParty-inside-a-setGuests-updater in removeGuest are gone. The floor plan is re-fetched on the way to the last step, so a guest whose table shrank mid-booking is told and returned to the map before typing in six guests' names, not refused after. ReservationWizard gets the same rule: the picked table now carries its seats, and changing the party size drops a table that no longer fits. The shrink, from the owner's side: PUT /api/tenant/[tenantId]/table-layout contained zero references to db.reservations. It now diffs the incoming room against every live future booking and refuses the save with 409 + the casualty list ("3 bookings no longer fit the tables you drew") until the owner acknowledges it; the designer shows who it breaks, offers Undo my change (which reloads the saved room, so the canvas can't diverge from the server) or Save anyway — I'll handle these, and remembers what was answered so the 900 ms autosave never re-nags. An acknowledged save stamps each affected booking's `staffNotes` ("Table 1 was resized to 2 seats — it can no longer hold this party of 6") and writes an activity line, so the conflict outlives the dialog. The dashboard reservations list rings the guest count in red with "Table seats 2" / "Table removed" / "Extra chair · <who>", and /api/internal/pos/bookings now hands the till tableSeats + overCapacity, so the Bord card warns instead of quietly drawing two chairs for six people — both computed against the current layout, never stored, so growing the table back clears the flag by itself. Deliberately NOT done: no auto-reassignment, no auto-cancel and no guest email on a shrink — moving a party from the window two-top to the corner six-top is a service decision with a real consequence for that guest, and a PUT handler is the wrong thing to be making it; staff get the list and the call. Gates: table-occupancy.test.ts grew from 5 tests (occupancy + PII only, zero capacity coverage) to 13, covering party == seats, party == seats + 1, deleted tables, past/cancelled/table-less bookings, and the staff-approved case; tsc --noEmit zero errors in every changed file; eslint clean on all of them.

• No native browser dialogs left in the POS/devices surfaces (2026-07-29). no-native-dialogs.test.ts (a HARD RULE guard: native dialogs ignore the theme and leak the raw host name in "restora-server… says") was failing on four call sites and is now green. The POS staff card's PIN reset and operator removal, plus Köksrouting's station-delete and force-delete confirmations, moved to the themed promptDialog / confirmDialog. The PIN prompt gained what the native one could never have: inputType: "password" and numeric: true, so it masks the PIN and raises the numeric keypad on a touch device.

• Schemalagda beställningar — the owner's switch for "I order at 11:00, I collect at 13:00" (2026-08-01). Owner ask: a guest ordering ahead should have the online order, the POS and the kitchen all see when the food is wanted, so it is served warm and freshly made — and the whole thing must be optional, flipped on or off by the restaurant from settings and effective everywhere at once. This entry covers the OWNER CONTROL half. New `TenantSettings.scheduledOrders` = `{ enabled?, maxAdvanceDays?, minLeadMinutes? }`, absent meaning OFF — cooking immediately is what every existing venue already promised its guests, so a new behaviour must never switch itself on during an upgrade. Two knobs and no more, because each one is something an owner has to understand: how far ahead a guest may book, and the shortest notice the kitchen will take. The read side is a module, not a field lookup (lib/scheduled-orders/config): resolveScheduledOrders fills in the defaults (7 days / 30 minutes) and clamps a stored record that predates a bound or was edited by hand, scheduledOrderWindow produces the bookable range, and normalizeRequestedServeAt is the ONE decision point every order-create path calls — absent time = ASAP exactly as today, and a time that arrives while the venue has the feature off is dropped rather than stored, silently, because the guest was never shown a picker and their order is a perfectly valid ASAP order. A stored time nobody honours is a cold meal. The bounds live in that module and UpdateSettingsSchema imports them, so the API and the resolver cannot drift, and the guest picker is built from the same numbers it will be judged against — a slot offered at checkout and then refused on submit is a bug the guest finds for us. Dashboard control: Settings → Ordering & Delivery gains a switch with copy that says what actually changes (guests can choose a later time; the kitchen is told when to START rather than cooking straight away), plus the two limits, gated on settings.edit and saved server-first through the existing tenant settings PATCH — the control only moves once the save lands, so nobody walks away believing they enabled something the kitchen never got. That tab hosted no editors by design (the IA-1 dedupe rule: one owner per setting); this is not an exception, it is a brand-new venue-wide ordering behaviour whose one owner is that tab. Gates: npx tsc --noEmit zero errors in every changed file (59 pre-existing errors elsewhere untouched), eslint clean on all touched files, 7 new pure-policy tests covering the off-by-default gate, the drop-on-off rule, junk/out-of-bounds knob resolution, the window arithmetic, the four serve-time verdicts and the settings-schema contract.

• Ny vara — a till can create a menu item, and it lands in the web menu (2026-07-31). Owner ask, repeated: "build that functionality also 'reverse direction (authoring on Android → appearing on web) doesn't exist. The till has no menu-editing UI and the translator is one-way by design.' i have been telling you about that before." The translator ran web → POS only; a tablet could sell the menu and never change it. New device route `POST /api/v1/pos/catalog/items` (RegisterGuard + @RequiresOperator(), no tenant path param — the tenant comes from the register token) writing the tenant blob, which is the authoritative store the web menu editor writes unconditionally and reads back. So an item typed on a tablet appears in the dashboard Meny page, on the tenant website and on every other register — not only on the device that typed it. An atomic $push, not a read-modify-write: two tills adding at the same moment must both survive. The POS catalog is re-translated immediately after, so the till that made the edit shows the item without waiting for a sync tick. The dialog asks four things and no more — name, price, section, VAT category — because those are the four a cashier standing at a register can answer correctly. Allergens are a legal statement about a dish, translations need someone who speaks the language, a photo needs a camera roll and a crop; those are left ABSENT rather than defaulted, so the item arrives in the dashboard visibly incomplete for the owner to finish instead of silently marked "no allergens" by a device that never asked. The name is stored as a single-entry localised map ({sv: "..."}), so other languages read as untranslated rather than duplicated. Nothing is preselected, including VAT — an item quietly created at 12 % is indistinguishable from a correct one until an audit, by which point it has been sold a thousand times; the server refuses a missing vatCategory and the dialog refuses to submit without one. The price is never parsed by the UI: the field takes KEYSTROKES like the cash pad (1-2-5-0-0 previews "125,00"), pos-core converts and formats, and with no engine installed the dialog refuses to send rather than inventing a price the whole restaurant would then sell at. Permission: owner and manager by ROLE, extended by a new catalog_edit operator permission so an owner can delegate to a shift lead without promoting them — deliberately NOT folded into register_settings, because changing how one till behaves and changing what the venue sells are different acts with different blast radii. Reading the permission alone would have locked every existing owner out of their own menu, since no operator record predating this carries it, and the remedy would have been a bulk write across pos_operators in live tenants. The server re-derives the answer from the operator record on every call (mayEditCatalog, 6 pinned cases); the device control decides what is OFFERED, never what is allowed. Verified end to end on a paired Lenovo tablet against the staging box: "Vitloksbrod / 49,00 / Pizzor / Mat 12 %" created on the till, then read back out of GET /store/tenant-data/{tenantId} — the exact payload the dashboard menu page renders — as one of four products, carrying createdFrom: {surface: "pos", registerId, at}. Three defects were found by driving the device rather than by the suite and are fixed: the shared @restora/domain-types package is consumed from a TRACKED compiled dist/, so a commit of its source alone type-checked locally and would not compile anywhere else (new pre-commit gate rebuilds the package to a temp dir and diffs against the git INDEX, verified to block in exactly that case); a fifth header button rendered as a column of single letters down the right edge (the header actions are a FlowRow now, so they wrap rather than squeeze); and the atomic $push was handed to a helper that wraps everything in $set, which Mongo rejects — fixed to updateDocumentMatching, which also never upserts, because a conjured blob would SHADOW a venue's existing menus menu and show one dish where there were forty. Gates: backend tsc --noEmit 0, 275 backend tests, Compose app compiles for Android + desktop + wasmJs, desktop suite green including a cross-language test that reads ENGINE_TAX_CATEGORIES out of catalog.service.ts and asserts the till's VAT chips are the same list (verified non-vacuous). Not yet: creating a CATEGORY from the till, and the pos/web React till has no authoring UI — both tracked.

• POS-enheter — one collapsible section per surface type, so nobody has to ask which button connects what (2026-07-28). Owner ask, verbatim: a collapsible list on the POS Registers page, ONE SECTION PER SURFACE TYPE (PoS · KDS · SSK/Självbeställning · Kunddisplay), every row showing exactly three things — Status | Öppna | Parkopplingskod. The blocker solved first: a register had no surface type. RegisterDoc carried name + capabilities and nothing saying whether a device was a till, a kitchen screen, a kiosk or a customer display, so the dashboard GUESSED from the name — and the old page's three "Open POS ↗ / Kitchen display (KDS) ↗ / Customer display ↗" buttons opened surfaces unrelated to the device you were looking at. New backend field on the autoSendToKitchen pattern: RegisterDoc.surface?: 'pos'|'kds'|'self_order'|'customer_display' with ABSENT MEANING 'pos' (every pre-existing register is a till → no backfill, no behaviour change), resolved on every read into RegisterView.surface and /registers/me, accepted on register CREATE and on the EXISTING admin settings PATCH (extended, not a new route — it rides the same capabilityRev bump so a device re-reads it like any other setting). Dashboard (/dashboard/pos, rewritten): four controlled disclosures with a per-section count that stays visible when collapsed; an empty section shows "Ingen enhet ännu" plus its own name+Skapa form that creates a register pre-set to that surface with a sensible capability preset (till = the same restaurant preset "Anslut POS" gives, KDS = kitchen_routing only — a kitchen screen does not sell, kiosk = sell+self_checkout+kitchen_routing+offline_capture); status is a chip — Parkopplad (green) / Väntar på parkoppling (hex-amber status pill, never the brand-remapped Tailwind amber) / Spärrad (red) — that a live pairing code takes over with "Kod aktiv · N min kvar"; Öppna opens THAT surface's URL in a new tab, verified against `pos/web/src/App.tsx`: /pos/ (till), /pos/?kds, /pos/?display — and because the bundle has no self-order branch, the kiosk's Öppna renders DISABLED with a tooltip saying the surface is not built yet rather than a link that goes nowhere; Parkopplingskod mints against the existing single-use endpoint and shows the 8-character code big and monospaced with a copy button, a live 15-minute countdown, an "öppna enheten med koden ifylld" deep link (?pair= — honoured by PairScreen), and an honest "koden har gått ut" when it lapses instead of the panel silently vanishing. Codes now appear in exactly ONE place — the row of the device they belong to — including the one minted by the first-run "Kom igång" button, which keeps its real value (it also creates the first personal-login and imports the menu) but no longer competes as a second connect path. Whole page moved to Swedish operator copy; the three actions stack rather than overflow at 320px. Plumbing: 2 thin proxies under api/tenant/[tenantId]/pos/devices/** (requireTenantAccess on both, tenantId always from the authenticated path, Next 15 await params) — the list reads GET /pos/admin/registers because that is the projection carrying surface/status/deviceInfo, and create resolves seriesPrefix (next free S001-Tnn), country and currency from the tenant's OWN registers so a Norwegian venue's second screen is not silently created SE/SEK and an operator never has to know what a receipt series is; capabilities are server-chosen, never accepted from the browser. New shared lib/pos/device-surfaces.ts is the one definition of the four surfaces (label, blurb, open-query, capability preset) used by both the page and the create proxy. Gates: backend npx tsc --noEmit exit 0; ui npx tsc --noEmit zero errors in the changed files (49 pre-existing errors elsewhere in storage/themes/experience-studio untouched).

• Köksrouting — the kitchen-routing admin lands in the dashboard (2026-07-27). New page /dashboard/pos/routing (sidebar: Devices → "Köksrouting", NEW badge): the dashboard surface for KDS stage 1. Stationer — create/edit prep stations (name, short code, sort order, target prep time, expo flag), activate/deactivate/delete with the backend's loud-refusal flow surfaced honestly: a 409 ROUTING_STATION_IN_USE becomes a panel naming the blocking categories/items and offering "flytta till annan station" (reassign) or "fortsätt ändå" (force, every orphan logged); losing the last active station shows the pass-through warning verbatim. Kategorier — default station per menu category ("Pizzor → pizzaugn"), "Ingen tillagning" toggle, a warning pill when a default points at a deleted station, and the '' category rendered as "Utan kategori" (per-item routing only, controls disabled since the backend refuses an empty categoryId). Varor — per-item override table with the LIVE fire-time decision as a colored chip (routed = green with station + source; fritext = hex-amber status pill; unrouted = red "Ingen station"; no-prep/passthrough = slate), station override picker and the Ärv/Aldrig kök/Alltid kök tri-state, plus name search and a "bara problem" filter (render-capped at 250 rows). Hälsokoll — the pre-service check: mode, active-station count, per-kind item counts, the named unrouted dishes (red, backend messageSv verbatim), dangling-category list, and one-click "Skapa station av namnet" for each legacy free-text station. Logg — the routing diagnostics log (operator-facing Swedish rendered verbatim, code chip, Kassa/Online channel badge, 24h/7d selector). Plumbing: 9 thin proxy routes under api/tenant/[tenantId]/pos/routing/** (all requireTenantAccess-guarded, tenantId always taken from the authenticated path), a new internalPut helper + backendErrorResponse mapper in lib/http/backend.ts so structured backend refusals (status + code + details) reach the browser instead of collapsing into a generic 400. Also fixed the failing nav i18n guard: "POS Registers" (and the new "Köksrouting") translated in all 20 languages.

• SB-1/SB-2 — per-portion split-bill kassakvitton, built to completion DORMANT behind a per-tenant flag (2026-07-20). Implements the split-bill fiscal design (Model B1): with settings.fiscal.splitReceipts: 'portion', every captured payment portion registers its OWN sale kassakvitto at its OWN payment moment — each paying guest is offered a receipt, an abandoned split leaves received money correctly registered, and X/Z per-method totals match the drawer by construction. Engine (SB-1): slicePortionBuckets (B1 residual allocation — BigInt proportional shares, largest-remainder within a portion so slices sum exactly to the payment; the FINAL portion takes each bucket's remainder for gross/net/VAT, so Σ portions == the whole-order receipt öre-exactly per rate, mixed VAT included) + reserveFiscalPortionSale (pure) + recordOrderFiscalPortion (in-lock, idempotent on portionRef = the ledger charge row id — the exact mirror of refundRef; self-gating on the flag; mode-straddle safe: fiscalSales presence wins over config); the whole-order paid-flip hook becomes the SAFETY SWEEP in portion mode (and stays the path for no-ledger-row orders: canteen wallet, zero-due). Journal/X/Z/status derive Order.fiscalSales into the ONE gapless journal. Refund/copy mapping (§4.3): returkvitto resolves its target portion via the refund row's charge linkage (greedy lowest fallback), the cumulative return cap re-anchors at Σ portion gross, the full-refund VAT mirror merges portion buckets, and kvittokopia becomes once-only PER kassakvitto (receiptNumber on the copy route; ambiguous portioned order → 422; a portion copy reproduces the ORIGINAL stamp öre-exactly). Routes (SB-2): the POS settle route registers the portion at each capture (partial AND final) and finalizeSeamCharge registers an async-rail portion at the APPROVAL moment. Default `'order'` = byte-identical to today (regression-proven). Go-live per tenant = the config flip, gated on the design doc's ⚠ VERIFY register (Skatteverket written query + control-unit vendor). Adversarial review (probe-driven): 8 findings, ALL FIXED — refund-then-recollect no longer dead-ends (registered returkvittos NET out of the position for the cap, final-portion detection AND prior slices, so re-received money re-registers — probe-confirmed the old permanent refusal); slice VAT moved to CUMULATIVE rounding + clamp/rebalance (a 4×3-öre split can no longer print a negative-VAT kassakvitto: 1,0,1,0 not 1,1,1,−1 — Σ still öre-exact by telescoping); the portion hook got the ADVISORY pre-read gate (dormant means dormant: order-mode tenants no longer pay a locked doc-write per capture on the hottest money path); gift/prepaid tenders on UNPAID orders register their portion at CREATE time via the new sweepOrderPortionsAsync (the abandoned-split rationale now holds for gift money too); the paid-flip sweep resumes PENDING portion stamps (live signing failures self-heal); untargeted multi-portion returns walk portions by remaining capacity; mid-split order-total drift logs loudly and the clamps keep the math self-consistent; copy route survives a JSON null body. Gates: 10 portion tests incl. F1/F2 regressions (7048 total, 0 fail), tsc 0, full build 0, sb-portion-qa.mjs flag-ON E2E ALL PASS on the FIXED build (2-portion cash+card split → gapless kassakvitton at capture time, X-report exact per-method öre deltas, per-portion once-only copies) + flag-OFF pos-wheel-qa.mjs 11-gate regression ALL PASS.

• Register panel Wave 3 — park/resume, ÖVNING training mode, Android parity, Windows Station PoS surface, split-bill fiscal design (2026-07-20). Owner: "go ahead all in". Web park/hold: the panel's Park key shelves the in-progress sale (cart + armed kitchen note + rabatt) per-device/per-tenant (lib/sell/park.ts, cap 20, shape-guarded storage — nothing fiscal happens at park time), with a resume/discard list in the panel; resume refuses over a non-empty cart. ÖVNING training mode: a session-only violet switch in the panel — while armed, every tender routes to POST pos/training-receipt (pos.operate, live-menu priced via the ONE PriceQuote engine, same rabatt clamps): NO order/ledger/stock/KDS/tally effect, only a marked training registration in the NEW TenantDB.fiscalTraining store — same gapless per-register counter, never the grand total, counted as trainingCount on X/Z, honest violet "ÖVNING — ej ett riktigt köp" confirmation (never the Paid screen). Fiscal exactness: an exact-FULL returkvitto now mirrors the sale's per-line VAT split öre-exactly (3×999 @25%: 600 vs the aggregate's 599 — a fully-reversed sale now nets 0 VAT on the Z, mixed-VAT sales included); SB-0 — tenderSplit derives the sale receipt's tender from the PAID ledger rows when they sum to the total, so a 2×cash+1×card SPLIT bill no longer registers as all-card (X/Z per-method finally reconciles with the drawer on splits). Android `:pos` parity (device-verified on the Lenovo TB330FU): "Register panel" switch in the settings sheet (default OFF, SettingsStore.registerPanel) → right-hand panel on wide layouts: numpad ×-grammar (verified 3×→300 SEK on device), server-clamped Rabatt with exact preview (−10% → 270 SEK verified; gift card + rabatt mutually exclusive so the shown total always equals the booked one), kitchen msg (order-level notes — Android never sent it before), once-only Kvittokopia (409/422-aware client), lådöppning, park/cancel; PosOrderRequest gained registerDiscount. Windows Station: PoS = the 4th wrapped surface (pos → /dashboard/sell + launcher picker button; per windows/AGENTS.md the web wheel/panel/themes come along free; cargo build exit 0). Split-bill fiscal semantics: full design doc docs/architecture/split-bill-fiscal-design.md — Model B (one kassakvitto per settled portion, portionRef idempotency mirroring refundRef) staged SB-0…SB-5 behind a per-tenant flag, every legal claim tagged [LAW]/[PRACTICE]/[CHOICE] with a ⚠ VERIFY register (incl. "PRO FORMA" vs "EJ KVITTO" marking); the TablePayment/barTab fiscal gap + abandoned-split gap documented in KNOWN_ISSUES. Gates: 7038 unit tests 0 fail (park + training + VAT-mirror + SB-0 tests), tsc 0, full next build 0, pos-wheel-qa.mjs 11 gates ALL PASS (park→resume, ÖVNING ring leaves takings untouched), :pos:assembleDebug 0 + on-device verify, Station cargo build 0.

• Register functions panel (TruePOS-style quick actions, our UI) + the Swedish non-sale fiscal rail: kvittokopia · returkvitto · pro forma · lådöppning (2026-07-19). Owner decision: an on/off switch under POS settings — DEFAULT OFF so our PoS UI/UX stays exactly as-is; switching it on ADDS a right-side functions panel ("we will keep things in our own way" — TruePOS functionality, never their look). Wave 1 — the panel (components/dashboard/pos/RegisterPanel.tsx + register-panel-pref.ts, new "Layout" switch in the settings wheel): numpad-first register grammar (type 3 → press × → tap a product adds 3; clamped to the 99/line server cap incl. merges — new addToCartQty), ad-hoc Rabatt entry (numpad value → % or kr; SERVER-side application in the pos/orders route AFTER combo/coupon/brand-promo on the remaining total, percent capped at 100, clamped ≥ 0, recorded into discountAmount so the fiscal receipt prints the mandated negative Rabatt line; the till only previews via previewDiscountedTotal), Köks-medd. (order-level kitchen note through the existing notes field, themed prompt — also added as a plain field on the waiter order ticket), cash change calculation (type the tendered amount → change previews live and lands on the Paid screen), and one-tap tender buttons (Kontant/Kort/Swish reusing the exact existing charge rails). Wave 2 — the fiscal issuance paths the engine supported but nothing ever issued (lib/fiscal/se/wire.ts reserveFiscalExtra/recordOrderFiscalExtra, pure + in-lock like the sale path): Kvittokopia — once per order EVER (Skatteverket), requires the recorded sale stamp, own gapless receipt number, never moves the grand total, panel button opens the print page with the mandated oversized KOPIA marking (409 on a second attempt); Returkvitto — wired into ALL THREE refund chokepoints (sync provider/gift refunds, async refund confirm, Swish refund) fire-and-forget so every money-out now registers a RETUR receipt referencing the original and advances the |sale|+|return| grand total; Pro forma nota — "Print bill (PRO FORMA)" on the waiter sent screen (no sale stamp required, capped 10/order, marked PRO FORMA — ej kvitto på köp); Lådöppning — a nosale cash-drawer movement (amount forced 0) journaled with who/when/why and counted as drawerOpens on the shift Z-report. Journal + X/Z reports now derive order.fiscalExtra into the SAME gapless journal (copies/pro-formas counted, never money; returns net out of sales). New routes pos/orders/[orderId]/receipt-copy + /proforma (staff-auth, engine enforces the bounds); live control-unit path reserves in-lock + signs post-lock identical to sales. Adversarial review (2 independent agents over the money/fiscal diff): 10 defects found, ALL FIXED — returkvitto made idempotent PER REFUND EVENT at the engine (refundRef = the refund's ledger row id, threaded through all three chokepoints — the sync route and the rail webhook observe the SAME row, so their race can no longer double-register; cumulative returns capped at the sale gross); a failed live signing of an extra now RESUMES on the next identical request instead of dead-ending (and for a copy, permanently forfeiting the only legal copy), the signing finder is register-scoped, and the response returns the SIGNED stamp; the direct POS settle route (the 4th place a sale becomes paid — register Swish!) now records the fiscal sale, and the zero-due branch (newly reachable via a 100% RABATT) emits order.paid + the receipt; client caps now mirror the server zod caps exactly (discount ≤100%/999 999 kr, note ≤1000, qty merges clamp at 99) so an over-cap OFFLINE sale can no longer queue → fail zod on replay → be silently dropped (a lost cash sale); toggling the panel OFF clears armed discount/note/multiplier (UI price and server booking can never diverge); the Paid screen's change calc ignores a parse-failed total-0; receipt markings are now SERVER-TRUTH (fiscalMarks from the journal stamps — a spoofed ?mark=return&nr=999 can't fabricate an official-looking returkvitto, and once a kvittokopia exists the plain print URL auto-marks KOPIA); return stamps record the money-out tender so X/Z per-method totals net correctly; X/Z + status certified now covers non-sale registrations; kvittokopia/pro-forma require pos.operate (once-ever copy must not be burnable by a viewer role) and internal engine faults map to 5xx not 422. Gates: 27 fiscal/journal/drawer unit tests (7032 total, 0 fail), tsc 0, full next build, extended pos-wheel-qa.mjs (panel toggle, ×-multiplier, −10% + cash + change, kvittokopia once-only + KOPIA banner, drawer feedback). Known minor (tracked in TODO): return-VAT is split from the aggregate (±1 öre drift vs per-line on a full refund of odd-öre lines).

• Android POS — the settings wheel lands on the tablet register too (2026-07-19). The :pos app's four loose top-bar icons (tablet mode · theme toggle · sign out; Cast kept visible as the live customer-display indicator) consolidated under one gear opening PosSettingsSheet: a Light/Dark/Colorful theme picker (new SettingsStore.posTheme, migrates from and stays in sync with the old appDark flag) + quick actions (the new PosCalculatorDialog — same chained-op/till-% math as the web calculator — plus Customer display, Switch tablet mode, Sign out). Colorful mode amplifies the register's existing CATEGORY_HUES palette: category chips go from a small color dot to a full hue fill and the product tiles keep their category tints — the classic colorful-register look on the light canvas. Verified on a real Lenovo TB330FU: theme migration, live colorful flip + persistence across relaunch, calculator math (12×9=108). Gate: :pos:assembleDebug exit 0.

• POS settings wheel — one gear on the selling screens: consolidated settings, quick calculator, quick actions, and a Light/Dark/Colorful theme (2026-07-19). Owner ask: a settings wheel on the PoS with everything under it, a quick calculator, quick actions, and selectable dark/light/colorful themes. New shared components in components/dashboard/pos/ mounted on BOTH selling surfaces (/dashboard/sell and /dashboard/order): (1) `PosSettingsWheel` — a gear that opens a slide-over with three sections: Theme picker, Quick actions (Calculator + big tap-targets to Cash Drawer / Table Billing / Bar Tabs / Orders / KDS + per-screen extras: "New sale" on Sell, "Change table" on Order), and Settings & configuration — grouped links into the EXISTING settings homes (Setup Center payments/ordering tabs, Menu, Devices & Apps, Tables & QR, Payroll & tips, All settings) so every setting keeps its one home and RBAC (consolidated access, not duplicated pages). (2) `PosCalculator` — a classic till calculator modal (chained-operation math, % with the till convention 100 + 25 % = 125, ± ⌫ C, full keyboard support), pure UI utility that never touches the cart or money rails. (3) `pos-theme` — Light / Dark / Colorful: Light and Dark DRIVE the one tenant theme mechanism (useTenantThemeMode — no parallel theming); Colorful rides the light canvas and colorizes the category chips on both screens with a fixed 10-color saturated palette (deterministic per category index; deliberately avoids the orange/amber/yellow scales the brand remaps to azure). Also: /dashboard/sell (the lite-mode landing) is now reachable from the full-shell sidebar — added to Live Service as "Sell (Counter)" with the label translated in all 20 languages. Gates: 16/16 nav-catalog + dark-vocabulary guard tests, tsc 0, full next build exit 0, scripts/pos-wheel-qa.mjs (new Playwright QA: sheet, all 3 themes apply, calculator math, both screens, 390px).

• In-Venue Ops IA — the 15-item group split into three, and Table Bills + Split a Bill merged (2026-07-19). Owner question: competitor systems (Toast/Square/Lightspeed/SpotOn/Trivec) don't scatter table bills, split-a-bill, cash drawer, bar tabs across back-office nav pages — they're actions inside the POS check screen, with the dashboard holding only setup + reporting. A 14-agent audit (every page read, six competitors benchmarked, an adversarial skeptic) confirmed the "one mega-view" temptation is a trap: the pages are nine separately-entitled, separately-RBAC'd verticals over three disjoint data rails (orders / tablePayments / barTabs) that only meet at the payment ledger, so a naive merge would leak toggled-off features past navHasFeature, 403 waiters on owner-only tabs, break saved deep links, and imply an order↔bill linkage the backend doesn't have. Shipped the two safe wins the audit endorsed: (1) nav regroup — the one "In-Venue Ops" dropdown (15 items) split into Live Service (Take Order · Table Billing · Bar Tabs · Weigh Station · Cash Drawer), Venue Setup (Tables & QR · Floor Designer · Delivery ×2) and Guest Services (Catering · Canteen · Atmosphere · Voice · Table Assistant); pure regrouping — every route/featureId/permission unchanged, "In-Venue Ops"/"Operations (in-venue)" kept as search keywords, 3 new group labels + 1 item label translated across all 20 languages. (2) Table Bills + Split a Bill → one `/dashboard/table-billing` surface with two URL-driven tabs (?tab=bills default / ?tab=split, features-page pattern); both are settlement UIs over the same ledger with the same pos-operations entitlement + owner/manager posture, so the merge is presentation-only. Old routes are redirect() stubs (guard-test convention) → links, bookmarks, Quick-Links stars and the docs-center/payments deep links all keep working (the two in-app links repointed at the merged tabs). Gates: 15/15 nav-catalog guard tests (redirect stubs, 20-lang i18n, iconKeys, findNavItem), full next build exit 0, all three routes in the app manifest.

• PoS + Waiter & PoS complete user guides at `/apps/pos/guide` and `/apps/pos/waiter-guide`, with real product screenshots (2026-07-19). Two new in-depth guides on the public site, following the Staff & Shifts guide's pattern. PoS guide (owner/manager): concepts chapter, a 17-step setup-to-operations walkthrough (floor plan · seating-chart designer · open a table + guest QR · take an order · table bills · split a bill (honestly scoped: web is even/custom only, the Android POS app adds seat/item split) · bar tabs + fast-pour + happy hour · age verification + refusals · cash drawer open/movement/close · terminal pairing + fleet · the Swedish fiscal/Kassaregister panel · payments & refunds), a Sweden fiscal-law chapter (Kassaregisterlagen, kvitto content rules, X/Z-reports, the Skatteverket kassaregister control visit — holds the same honesty bar as the fiscal engine itself: the product ships compliant-format receipts/journals against an uncertified sandbox control unit until a real certified cloud unit is connected, never claimed certified out of the box), 12 scenarios, 16 FAQs. Waiter & PoS guide: a practical, floor-staff-voiced companion — 13-step shift walkthrough (clock-in cross-ref · take an order by seat/course · offline handling · table bills · split · bar tabs · transfer/close a table · end-of-shift cash) with a cross-link to the PoS guide's legal chapter instead of repeating it, 10 scenarios, 12 FAQs. 56→40 real screenshots (20 unique screens × web 1440px + mobile 390px, several shared across both guides where the underlying screen is identical) captured by new scripts/guide-shots-pos.mjs against demo data seeded by new idempotent scripts/seed-pos-waiter-demo.ts (tables, an open table session + in-progress order, a bar tab with pre-auth/rounds/happy-hour, a cash-drawer session, a paired Android terminal, Swedish fiscal activation) on the same luigi-pizza demo tenant. Catalog: FeaturePage gained guideLabel/moreGuides/guideFooterNote (additive, staff-shifts' existing footer copy preserved via the new field) so pos.ts can link BOTH guides from the hero + FAQ footer; also fixed pos.ts's stale liveHref (pointed at the read-only online-order Kanban board, not the real waiter order-builder at /dashboard/order). Gates: both guides + /apps/pos verified 200 with populated content; full next build exit 0.

• Staff & Shifts complete user guide at `/apps/staff-shifts/guide` — owner + worker + Skatteverket + Swedish law, with real product screenshots (2026-07-19). The first in-depth product guide on the public site: 6 chapters (the three surfaces & the 4-digit code · a 17-step owner walkthrough from first hire to locked payroll · a 12-step worker guide written to the staff member · the Skatteverket kontrollbesök play-by-play incl. the no-PIN terminal register view and the 12,500/2,500/25,000 kr control fees · a Sweden legal reference with statute citations (SFL 39 kap., SKVFS 2015:6, ATL, semesterlagen, sjuklönelagen, kollektivavtal/no-statutory-minimum-wage, AGI/bokföringslagen, GDPR art. 17(3)(b) vs the 2-year register window) · 12 handled real-world scenarios) + a 16-question FAQ, FAQPage + BreadcrumbList JSON-LD, English "Sweden edition" first. Every step shows the REAL product — 56 screenshots (28 steps × web 1440px + mobile 390px) captured by scripts/guide-shots.mjs from the live dashboard/worker-portal with the dashboard forced to English and dev-noise banners stripped, against demo data seeded by the new idempotent scripts/seed-staff-shifts-demo.ts (staff PINs/encrypted personnummer/rates, 30 terminal punches incl. flagged manual + corrected ones, published & draft weeks, pending time-off/swap/availability requests, locked + draft payroll runs, training/review/kudos/announcement/chat) — both scripts committed so shots regenerate after UI changes. Honesty bar held: AGI/Bankgiro described as download-only MOCK, payslips as "Preliminär · schablonskatt", push/SMS as keys-gated, clock-in as terminal-only by design. Catalog: additive guideHref on FeaturePage renders "Read the full guide" on the feature page hero + FAQ footer (staff-shifts only so far). Gates: guide + feature page render 200 with populated content; full next build exit 0.

• Native mobile payslip view in the :staff and :owner Android apps (2026-07-19). Owner UAT: the payslip screen rendered the A4 PDF as bitmap pages — "not mobile friendly" no matter how crisp. The payslip is now NATIVE phone UI: net-pay hero, Earnings (hours / hourly rate / base / overtime / OB premiums / tips / gross), Deductions (tax withheld + line deductions → net), Employer cost (info), and the schablon honesty note when the run is mock; the legal PDF demoted to a "Payslip document (PDF)" card with View (full-screen pages + tap-to-pinch-zoom) and Share actions — web portal unchanged. Server: GET /api/worker/[tenantId]/payslips list projection extended with the worker's OWN full line breakdown (employmentType, hourlyRate/salaryPeriod, base/overtime/premiums/tips, employerLoad, withholding, deductions) — additive, still never a colleague's line or run totals; older APKs ignore the new keys, and the new APK falls back to gross/tax/net/hours against older servers. Gates: 6/6 payslip-access tests, both APKs assemble, full next build.

• Feature pages — full truth-audit after owner report that content didn't match the products (2026-07-18). /apps/food-bazar described supplier ordering; the real Food Bazar is the CONSUMER marketplace (diners browse/order; restaurants get listed). Root cause: content was grounded in the /services grid blurbs, which themselves conflated surfaces. Corrected by grounding every page in the actual code: 5 rewrites — food-bazar (listing pitch: auto-list gate from lib/bazar/readiness.ts, dashboard controls/boosts, ONE ordering switch; moved to Discover), printing→"Labels & Printing" (QR product/shelf label sheets, not a print shop), waste→"Waste Tracking" (scan-to-waste stock movements, not pickups), equipment-suppliers→equipment "Equipment Manager" (registry + per-machine QR, not a marketplace), inventory-suppliers (supplier ordering = supplier marketplace, not "Food Bazar suppliers"). Then 19 adversarial verifiers (one per remaining page, each reading the real surfaces) found ~100 defects — plan-inclusion errors (inventory is an add-on, not in Basic), nonexistent features (KDS "all-day view", reservations floor-plan claims, analytics daily summaries), demo-only iOS apps sold as live (POS/Owner platforms now exclude iOS), mock/flag-OFF rails phrased as live (payments, SMS/email connect), 5s-poll phrased as "instant" — all applied by 19 fix agents, including a full terminal rewrite (it's a locked payment terminal: PIN shift → amount/pushed charge → tip → NFC tap; Android-only; no Swish/KDS/ordering claims). /services card copy + FeatureMock visuals corrected to match (bazar→consumer, terminal→payment, waste→scan-log, printing→labels, equipment→registry, KDS chips). Gates: tsc 0, integrity checks (icons/related/counts), full build exit 0, all corrected pages render on-subject.

• Feature pages — a dedicated `/apps/[slug]` marketing page for every app & capability (2026-07-18). The Product mega-menu links + the /services "apps & consoles" grid all pointed at one grid page; now each app and capability has its own SEO/AEO/GEO-complete page. New engine (`lib/apps`): pure-data catalog (types + 24 feature files + registry, importable by SEO surfaces) feeding a server-rendered FeaturePageView — hero, plain-language "what is it" explainer, who-it's-for, 3-step how-it-works, feature bento, honest outcome stats, pricing hook, native <details> FAQ accordion, related-apps rail, ambient food-photo CTA — with per-app stylised device-UI mock illustrations (FeatureMock) and a dynamic branded OG image per page (opengraph-image.tsx). 24 pages across ops/grow/supply/discover (POS & Waiter, Kitchen Display, Terminal, Self-Serve Kiosk, Table Reservations, Staff & Shifts, Owner App, Online Ordering, Website & App Builder, Marketing & Loyalty, Social Media, Loyalty & Rewards, Gift Cards, Site Health Check, Analytics, Food Bazar, Inventory & Suppliers, Equipment Suppliers, Ingredients, Printing, Waste & Recycling, Menu TV, Atmosphere, Food Social Network) + a /apps hub. SEO/AEO/GEO: per-page title/description/keywords/canonical/OpenGraph/Twitter, SoftwareApplication + BreadcrumbList + FAQPage + speakable WebPage JSON-LD, all 25 URLs added to sitemap.xml, and an "Apps & features" section added to llms.txt. Honesty held: real plan prices (149/299/2999 + Pay-As-You-Go 0+7%), 0% commission on own sales, 7-day trial; no invented adoption/rating stats; allergen data flagged deterministic-never-AI; music licensing framed "handled where available". Rewired: the /services app + service cards gained "Learn more" links to the dedicated pages; the nav "What you can do" items repoint to /apps/* (applied on disk — the LandingNav.tsx change ships with the concurrent i18n session that owns that file). Content authored via a 23-agent workflow against a hand-written exemplar; gates: tsc 0 + full next build exit 0; all pages verified 200 + JSON-LD present + OG images render (image/png).

• Phase 76 — Restora360 Academy, waves AC-4…AC-13 (2026-07-18): the LMS completed end-to-end. Building on AC-0…AC-2 (engine + learner rail + first surface). AC-4 calculators: 5 new pure functions on the ONE Launchpad engine (roiPayback, vatBreakdown, foodCostShare, packagingCost, wholesaleMargin) + AcademyCalculator — all 14 kinds in one touch-first component, learner's own numbers, no AI cost, planning-not-advice disclaimer, mounted on any lesson with a calculator ref. AC-5 verifiable certificate: renderCertificatePdf (pdf-lib A4-landscape, azure-on-navy, embedded QR → public verify, WinAnsi Nordic glyphs) + a global verify store (app_documents:'academy-certificates') + first-exam-pass issuance inside the learner row lock + public /learn/academy/verify/[serial] (authentic/tampered/revoked/not-found, LinkedIn/X/Facebook share, employer note) + the PDF stream route + dashboard certificate cards. AC-6 Nordic legal (CKG trust seam): CountryLegalBlock renders the learner's country cell LIVE from the Launchpad CKG through the publish gate (verified+cited steps, or an honest "in preparation" global-floor when unverified) + a country picker (SE/DK/NO/FI) + the authored Finland home-bakery seed (Vero / PRH-YTJ / Ruokavirasto / municipality — cited, needs-review, allow-listed hosts added) closing the Nordic gap; every legal fact stays gated behind human verification, never re-authored in course prose. AC-7 gamification: UTC-day-key streaks + 14 deterministic achievements (recompute-on-read, honest-empty) on the dashboard. AC-9 Course Builder CMS: super-admin /admin/dashboard/academy — list + validated JSON editor + publish/draft/archive/schedule/duplicate/delete, on the ONE validateCourse engine; a CMS save detaches the course from its code seed. AC-8 AI study tools (flag-OFF `academy_ai`): explain-simpler/deeper/summarize/checklist grounded ONLY in the authored lesson, metered to a designated system-tenant wallet through the ONE appendLedgerEntry path — nothing renders while dark. AC-11 lesson discussion (flag-OFF `academy_discussion`): per-lesson Q&A reusing the ONE community forum with a lessonRef scope. AC-12 SEO: catalog + per-course sitemap URLs + the FI guide cell. AC-13 flagship content: Modules 4–20 authored by a 17-agent workflow, machine-validated and integrated — the course is now 20 modules · 102 lessons · 20 quizzes · a 100-from-102 randomized, timed final exam (seedVersion 2); no fabricated stats, no jurisdiction legal claims in prose. Adversarial review (5 dimensions × verify): 16 confirmed defects, ALL FIXED — the final-exam per-question score oracle (fail now reveals pass/fail only; a submission must answer the whole drawn set; a shrunk/empty draw is voided, never auto-passed at 100%), the full exam pool leaking through course-detail (final exam excluded from the projection; delivered only as a server draw), attempt-cap eviction (durable per-quiz counter, not the evictable log), certificate HMAC now covers every displayed field (name/course/hours/score) + crypto 32^10 serials with a store uniqueness guard + lost-mirror self-heal from the durable enrolment copy, seed/legal-node resurrection after admin delete/reject (tombstones + a one-time marker + lifecycle-preserving upgrades), partial-verified legal cells now show an honest "more steps being verified" banner, per-learner AI rate-limit, and the discussion flag enforced on the API. Gates: full next build exit 0 · 74/74 academy unit tests (incl. new security regressions).

• Phase 76 — Restora360 Academy, waves AC-0…AC-2 (2026-07-18): the enterprise LMS foundation + first surface, DEPLOYED + prod-QA'd. Plan: docs/Phase-76-Restora360-Academy.md. AC-0 engine (ui/src/lib/academy/): the Course→Module→Lesson content model (video/images/worksheets/embedded calculator+quiz/per-locale bodies/CKG nodeId binding for country-dynamic legal facts) + AcademyDB on app_documents:'academy' (never a MasterDB array) + docker/initdb/017_academy.sql (flag-gated academy_courses/academy_enrollments/academy_certificates mirrors incl. the global verify-by-serial index); a 9-question-type quiz engine (mcq/multi/trueFalse/fillBlank/ordering/dragDrop/image/scenario/calc) with deterministic server-side grading, a leak-proof field-by-field publicQuiz projection, timed/randomized exam draw+shuffle and unlimited-retry policy; a signed verifiable-certificate core reusing the loyalty HMAC signer (ACADEMY_CERT_SECRET). Consolidates the workforce-training + designer-academy quiz/cert primitives into the ONE lib/academy/* engine. AC-1 learner rail: the learner IS the platform's consumer identity (getShopCustomer — platform bridge means dashboard credentials work), a per-learner doc (academy-learner:<id>, per-learner row lock) holding enrolments/progress/quiz attempts/bookmarks/notes with a server-drawn, time-limited final-exam lifecycle (expired draws void without consuming attempts; first pass wins; best-score-stands; XP derived, never stored), and 8 rate-limited API routes with grading INSIDE the row lock (exam = no-oracle, lesson/module = instant practice feedback). AC-2 surface: /learn/academy/courses catalog + course detail (3-state CTA, free-preview badges, Course JSON-LD) + the lesson player (sticky nav, honest video/worksheet placeholders, notes/bookmarks, the 9-type QuizRunner — touch-first, no drag lib) + the /learn/academy/join wall (ONE consumer account, source:'academy' email branding) + the student dashboard (XP/progress/resume/bookmarks); guests browse everything, lesson content beyond previews requires the free account — enforced SERVER-side. Flagship course seed slice: "From Home Cookie Baker to Profitable Scandinavian Business" Modules 1–3 fully authored (15 lessons + 3 module quizzes, 6 question types; no fabricated stats, no jurisdiction legal claims — those bind to the verified CKG in AC-6). Gates: full builds exit 0 · 47/47 academy tests · 11-step live prod QA (guest gate 401, zero answer-key/locked-content leaks at both access levels, register→enroll→lesson→quiz 100%→notes→bookmark→dashboard, XP exactly 10+25). Left: AC-3+ (calculators in-lesson, certificate PDF/verify, SE/DK/NO/FI legal via CKG + Finland seed, gamification depth, AI flag-OFF, Course Builder CMS, discussion, full 20-module content).

• Phase 75.3 — Owner feedback round 3 (2026-07-18): crisp nav, no public Ask-AI, /try finally azure. (1) The floating nav pill and its mega-menu panels are now near-opaque (0.94/0.98 pill, 0.99 panel) so they stay crisp over the dark photo hero. (2) The "Ask Restora AI" bubble is OFF the public website — the owner had removed it before and a session brought it back; PublicAskAi is unmounted from the root layout with a loud guard comment, and a standing memory records the rule (portals keep their own AskAiWidget mounts). (3) The /try funnel's pre-rebrand ORANGE finally died: WowUnifiedImport carried ~40 hardcoded warm hexes (#e67e22 orange CTA/spinners/checkbox, #dcc1b1 tan borders, #564337 brown text) — all converted to the locked azure ramp (#1570ef / #b3d7ff / #475569 / #0f172a), same for the Launchpad client's five orange accents and the orange eyebrows on /launchpad, /recipe-card and /start guides. (WowPremiumImport still carries warm hexes but is dead code — no page renders it.) Verified: /try screenshot fully azure, homepage FAB count 0, tsc 0, full build, deployed.

• Phase 75.2 — Landing round 2 (owner feedback, 2026-07-18): slider retired for real sections + photo hero. Owner: "remove this slider and break it down into sections — each function is big, complex and must-have" + "instead of dark background, a high-quality restaurant image with cash counter, digital signage and PoS under dark transparency". Hero: a real restaurant photo (open café space with wooden counter, POS on the counter, hanging menu-board signage — public/landing/hero-restaurant.png, Unsplash license, next/image priority) under a left-weighted navy transparency gradient, so the page opens inside an actual restaurant while the text column stays AA-readable. The auto-playing 11-chapter RestoraExperience slider is off the homepage, replaced by FeatureDeepDives — three full alternating sections, each a former "must-have" chapter with its own room and a hand-built responsive mock (no autoplay, no timers): "Every order. One screen." (channel chips → one live order inbox), "The kitchen sees it instantly." (dark KDS board with New/Preparing/Ready columns, progress bars, and the guest-phone status card — the chapter the owner highlighted), "Stock that reorders itself." (low-stock alert → suggested reorder via Food Bazar → Ta Emot Varor scan row). Each links to its /services anchor. Bento reworked to "and everything else" so it no longer overlaps the deep dives: featured website-builder card now uses the restaurant photo, plus reservations, Menu TV (free), payments & gift cards, staff & scheduling, and the navy marketing card. Gates: tsc 0, linkcheck 199/199, full build, desktop+mobile screenshots verified.

• Phase 75.1 — Landing page visual redesign + nav icons (owner feedback round 1, 2026-07-18). Owner: "expecting redesign, not just layout exchange" + "liked the navigation — add icons and one-liner descriptions; mobile menu without descriptions" + free rein to add/remove sections. Hero rebuilt as a full-bleed navy stage (azure radial glows + faint dot grid pulled up behind the sticky glass nav): white serif headline with an azure gradient italic accent, glass eyebrow chip, azure-glow primary CTA + translucent ghost, the deterministic intent search as the focal input, and the interactive order-demo as a bright card floating on the dark with a deep shadow; the honest trust chips (0% commission · 7-day no-card · live in an afternoon · GDPR · /status) became the hero's bridge row into the light page (standalone TrustStrip band retired). Feature grid → bento (Apple-style modular): a 2×2 featured "Online ordering — 0% commission" card with a live-looking ticket mock, a navy "Marketing & loyalty" accent card with capability chips, a photo-topped website-builder card, and three standard cards — every card still a real link into /services anchors. How-it-works → timeline: three cards on a dashed connecting line with big italic serif numerals in a sunken band + a "Start step one now" CTA. Final CTA → navy mirror of the hero (glows + dot grid + gradient accent) so the page closes the way it opens. ForAgencies removed from the homepage (owner-focused funnel; the agency pitch stays in nav/footer//partners). Navigation: every mega-menu entry now carries a lucide icon in a tinted tile that fills azure on hover + a one-liner description (Service-providers and Company groups got descriptions written); the mobile accordion renders icon + label only (lean 44px rows); fixed a hover-then-click interaction where clicking an already-hover-opened trigger closed the menu (click is now open-only; Escape/outside/mouse-leave close). Verified: tsc 0, zero page errors, desktop + mobile + open-menu screenshots, full build + linkcheck gate before deploy.

• Phase 75 — Website Conversion Redesign, batches B1–B5 (2026-07-18). The public marketing site rebuilt for conversion — premium warm-Scandinavian on the LOCKED azure-on-navy brand, every claim honest, grounded in an 8-agent audit + five committed reports (docs/architecture/website-conversion-redesign/). B1 homepage/nav/footer: hero-first section order (the animated Experience player no longer owns the first fold — mobile finally sees a headline + CTA; fixes the h3→h1 outline break), an honest TrustStrip (product truths only — 0% commission on own orders, 7-day no-card trial, Swedish AB, GDPR, live /status), a 5-item nav (Product/Partners/Resources mega menus with real aria-expanded/Escape/outside-click + Pricing + Academy), a real-links footer (13 dead # links gone; /status /community /learn/academy /launchpad wired; fake social icons + cosmetic region cycler removed; newsletter input labeled), a deterministic IntentSearch combobox in the hero (~35-entry keyword→route map, zero AI cost), a SavingsCalculator (your sales × commission % vs the flat plans — honest math, visitor-adjustable), mid-page CTA paths (feature cards now link into /services anchors, Bazar band → /bazar, apps band → /services, inline CTA band), FAQ grown to 6 items incl. pricing, "Cancel anytime" wording replaced with the honest "trial ends quietly" everywhere (hero chips, FinalCta, Experience chapter 11), Experience player a11y (aria-hidden auto-mutating stage, keyboard prev/pause/next on mobile stories), skip-to-content link, landing-theme structural tokens (spacing/radius/duration/focus-ring/hairline from the reference DS — azure values). B2 pricing + de-fabrication + trust: a real /pricing page (live plans registry via getOfferablePlans — admin overrides flow through; billed-yearly totals on every monthly figure; add-on rules incl. the 299 kr kiosk exception + free Menu TV; a what's-included matrix GENERATED from the entitlement registry; pricing FAQ + FAQPage/Product+Offer JSON-LD; /plan 301→/pricing, /products 301→/services); every fabricated stat/testimonial removed from /partners /agents /designers /suppliers (invented "1240+ restaurants/£1.8M paid/99.9% SLA/4.8★" counters + 9 fictional named testimonials + THREE fabricated schema.org aggregateRating blocks → honest program-mechanics stats verified in the commission/payout engines, £→kr, 14→7-day trial, designer membership honestly 500 kr/yr, "PCI-compliant" → "payments processed by Stripe"); /about founder story (3 chapters + Swedish-company facts + support-promise cards with the real email); /contact shows support@restora360.com + a topic selector incl. Book a demo (the missing sales path) + the previously-unthrottled contact API now rate-limited like newsletter. B3 Restaurant Academy: the EXISTING /learn/academy engine extended (never parallel) — a new Founder Roadmap track ("Idea → Open → Profitable → Multi-location") whose 9 beginner/intermediate/advanced lessons carry real teaching bodies adapted from the Launchpad's advice-clean foundational lessons, dedicated lesson pages at /learn/academy/[trackId]/[lessonId] (ISR, LearningResource JSON-LD, prev/next, mark-complete), server-first progress (new GET on the progress route; localStorage stays the anonymous fallback; AcademyClient merges both), journey ladder + free positioning on the landing, and the pre-azure #a8531a orange hover leftovers fixed across academy/webshop/growth/community. B4 one login, many workspaces: /welcome/workspaces — a calm chooser composing the SHIPPED re-mint endpoints (/api/restaurants/switch + POST /api/auth/portals; cookie stays single-scope, zero guard changes); the portals GET now returns a workspaces enumeration (ALL active owned restaurants — a multi-restaurant owner finally chooses instead of silently landing on the first — plus partner hats); login sends multi-workspace users to the selector (single-workspace keeps the direct redirect; ?next= and 2FA untouched), fixes its dead "Forgot password?" # link (→ /contact until a reset flow exists), points signup at /onboarding, and "Switch workspace" entries mounted in the tenant sidebar + agent + designer shells. B5 SEO/perf/gate: metadataBase + a generated root opengraph-image (social shares had NO image anywhere) + twitter card; canonicals on / /about /contact /pricing /services; /services finally has metadata (new layout.tsx — the main-nav "Product" target was invisible to search) + 7 jobs-to-be-done anchor ids; sitemap += /pricing /services /about /contact, −/register (robots contradiction); homepage FAQPage JSON-LD + Organization contactPoint; unused Geist(sans) font load dropped; AskAiWidget + GhostTextAssistant (1100+ lines) now lazy-loaded out of every page's first-load JS; scripts/marketing-link-check.mjs (npm run linkcheck:marketing) validates every internal marketing href against the real route table + redirects + hash targets — 194 links green. Also fixed: a broken committed test fixture (commission-engine.test.ts missing createdBy). Deferred honestly (tracked in TODO): graded Academy quizzes/certificates ride the existing derived-tier system for now; add-role widening beyond supplier; per-tenant staff memberships; careers/press/blog; real customer testimonials (slots ready, never faked); sv translations (structure ready).

• Phase 74 — Designer Growth Platform, wave DG-10: growth analytics + dark mode + 21-language portal + mobile (2026-07-18) — PROGRAM COMPLETE (11 of 11 waves). Growth analytics (designer_events, the audit-logs stream posture): a new append-only Phase-D table (docker/initdb/016_designer_events.sql, flag DESIGNER_EVENTS_TABLE, assertReady boot guard) records profile views, case-study views, contact enquiries and share clicks — written fire-and-forget (analytics NEVER blocks a page, never touches the hot designers doc; flag off = honestly dropped, never buffered). Capture: an anonymous rate-limited public beacon (/api/public/designers/[slug]/events — sendBeacon target, 204 even for missing designers so it's no existence oracle, case-study events validated against the author's own PUBLISHED projects, no PII — coarse country header + bounded ref only) mounted on the public profile + case-study pages; the contact route records the enquiry server-side once its guards pass; the Share kit counts share clicks per network. Read: a pre-aggregated GROUP BY (never row scans) feeds a "Your reach — last 30 days" dashboard card (4 KPIs + an SVG daily-views trend) that renders ONLY when the rail is on — no fabricated zeros, ever. Dark mode: the designer portal now mounts the ONE TenantThemeApplier (same navy tokens + toggle as the owner dashboard; no-FOUC script extended to /designer without matching public /designers/*; dashboard-shell scope class) and the dark-vocabulary test grew TWO NEW ROOTS over src/app/designer + src/components/designer (0 pale-hex findings). 21 languages: a new designer-i18n chrome dictionary on the Phase 55 rail — English schema + 20 agent-generated languages (validated: full key coverage, intact {placeholders}, no entity contamination), per-namespace English fallback so a missing key can never render undefined; language persisted on the SAME UserRecord.language field + PATCH /api/auth/me endpoint the owner dashboard uses (no parallel persistence); a picker in the portal topbar; sidebar/topbar/dashboard fully wired (inner pages migrate onto the namespace incrementally — tracked). Mobile: the fixed 240px sidebar became responsive — desktop aside from md up, hamburger-opened slide-over drawer with backdrop below (the portal now works at 320px instead of crushing content). Gates: clean-worktree full build exit 0, full suite 0 fail, 2-lens adversarial review (10 raw → 10 confirmed → 6 distinct defects, ALL fixed: pg DATE→local-midnight-Date parsing shifted every trend-day key one day back on the UTC+ box (day now selected ::text, series anchored on the DB's newest key); the "30-day" SQL window was 31 days inclusive; the beacon lacked the house global rate ceiling (forged-IP-header rotation could inflate counts unbounded — now 20k/h backstop like the analytics tier) and stored a client-suppliable country header unclamped (now strict 2-letter-or-nothing); the language picker was hidden below sm — unreachable on the very 320px shell this wave ships (now always visible, compact); the mobile drawer gained body scroll-lock + Escape-close + dialog semantics, and RTL languages (Arabic) now flip the whole shell via the registry rtl flag).

• Phase 74 — Designer Growth Platform, wave DG-9: designer community + agency teams + Designer Academy (2026-07-18, ships FLAG-OFF). Two new fail-safe-OFF master flags. Community (`designer_community`): designers follow each other, like/save published case studies, and get a feed — FSN domain shapes keyed on WebDesigner.id (no parallel account namespace), with block/report from day one: blocks are mutual-invisibility (drop follows both ways, silently refuse new edges — never revealed by any response), reports are idempotent per open (reporter, target), self-report-refused, rate-limited (10/hr + global flag-bomb ceiling) AND capped in storage, feeding a super-admin moderation queue (enriched target/reporter previews; resolve/dismiss durable, no double-moderation; a project takedown unpublishes the case study; deliberately NOT flag-gated so moderation outlives the flag; account actions ride the EXISTING admin designer suspension). Storage per the enterprise rule: social edges live in their OWN designer-community doc (the hot designers doc is untouched) with a new Phase-D Postgres mirror — docker/initdb/015_designer_community.sql (designerfollows / designerengagements / designerblocks / designerreports), flag-gated DESIGNER_COMMUNITY_TABLE reconcile inside the write txn, db:backfill:designer-community, and an assertReady boot guard. Agency teams (`designer_teams`): the shipped Organization+groupRole model mirrored designer-side — DesignerAgency + WebDesigner.agencyId/agencyRole (owner/admin/member), founding, consent-based invites (by public directory slug; the invitee accepts/declines — nobody is added to a team without agreeing), role changes with a single-owner invariant (transfer demotes the old owner; the owner can't leave without transferring), self-leave, member cap. HARD BOUNDARY: a team never pools money — commissions/payouts/invoices/wallets stay strictly per-designer; the roster shows read-only substance counts only. Designer Academy (rides designer_community): a deterministic learning track ("Restora 360 Certified Designer" — 6 lessons of real platform content: 10%/5% earning model, delegated access, portfolio conversion, share engine, pitch engine, professional standards) with a server-graded quiz (correct answers never leave the server; varied answer positions; lessons gate the quiz; passing certifies durably — a failed retake can't un-certify) feeding a new academy achievements group that shows on the public profile badges. Surfaces: three portal pages (Community feed+discover+report/block dialogs, Agency Team roster+invites, Academy lessons+quiz) under a new "Grow" sidebar section — every page self-gates to a clean "coming soon" while dark. 15 new unit tests (block semantics both ways, report lifecycle incl. cap + durable moderation, RBAC boundaries incl. ownership transfer + invite consent, quiz gating/durability/answer-leak). Gates: clean-worktree full build exit 0, full suite 0 fail, 3-lens adversarial review (12 raw → 11 confirmed → 5 distinct defects, ALL fixed + regression-tested: the reigning owner could self-demote and orphan the agency ownerless forever (now only the atomic transfer path steps an owner down); a failed invite-accept (member cap) silently destroyed the consent artifact (now consumed only on success); the team roster leaked privacy-hidden availability to teammates (isFieldVisible now gates it — privacy gates EVERY surface, teammates included); self-reports of own projects were accepted and draft projects were reportable (an unpublished-id oracle — now published-only + own-work refused); and the follow response shape revealed a block (now byte-identical to success, FSN ghost semantics) + block/unblock left the denormalized follower counters stale).
• Menu blocks 2.0 — LIVE dish cards + the dish manager (MT-SIG-2, owner ask 2026-07-18). The flexibility pass on menu blocks, everywhere the canvas engine runs (Menu TV Screen Designer, Experience Studio, kiosk hosts): (1) `display:'card'` — a menu block can now render its dishes as big LIVE cards (photo medallion + name + price + story) that EQUALLY FILL the block: choose 1 dish and it spans the whole block, 2 split it in half, up to 6 in one stripe row, 7+ wrap into an even grid — the professional-signage mode (Color Stripes/product walls) with zero hardcoding; names/prices/photos/86 stay bound to the live menu, so a menu edit re-skins every published design instantly (wire-safe conditional hash → one poll). Per-dish itemStyles.bg paints each card's stripe colour. (2) The dish manager replaces the pick-a-dish dropdown in the inspector: one list where the CHECKBOX picks which dishes the block shows (itemIds; all-ticked = follow the menu so new dishes keep appearing), DRAG reorders (itemOrder, feed-honoured on every surface), and CLICK opens per-dish styling (colours/sizes/weight + the stripe colour in card mode) — plus the existing "Separate dishes". (3) Templates went live: Color Stripes now materializes as ONE live card block pre-bound to the tenant's first four dishes (stripe colours pre-filled per dish); Premium Smoke + Salad Bar menu areas became live card grids; the create route and the in-designer materializer both seed ctx.items (first dishes, menu order). Sanitize/resolve/hash follow the MT-SIG wire-safety idiom (display/bg absent unless used; natives fall back to list rows — same content, XS-9 divergence rule). Gates: tsc clean (our files), studio-templates-uat.mjs ALL PASS incl. the new "LIVE stripes, no $00.00 placeholders" assertion, menu-tv-designer-uat.mjs ALL PASS (dish manager: tick/untick, style box, card toggle, Separate), screenshots verified.

• Phase 74 — Designer Growth Platform, wave DG-8: designer AI wallet + writing suite (2026-07-18, ships FLAG-OFF). The owner-locked commercial model lands: an active designer membership includes a 50 SEK/month AI allowance that resets monthly, plus persistent purchasable top-ups — held in a new per-designer aiWallet (DesignerAiWallet + öre-integer ledger, capped entries). Money core (lib/designer/ai-wallet.ts, pure + unit-tested): designerWalletBalance is the ONE place the math lives (allowance requires an ACTIVE membership — lapsed = 0; balance can never go negative), chargeDesignerAi draws allowance-first-then-top-up and is idempotent on ref (a retried settle can't double-bill), topupDesignerAi idempotent likewise; month rollover resets the allowance and preserves the top-up. Writer endpoint /api/designer/[id]/ai/write behind the new fail-safe-OFF `designer_ai` master flag (404s while off — GET and POST both): generates ONE draft (bio / headline / case-study summary) through the RIC narration cutover (Anthropic legacy transport, claude-sonnet-4-6) at a flat 1 SEK per draft shown before generating; honesty-fenced system prompt (use ONLY the designer's real profile facts — professions/specialties/location/experience + an optional hint; never invented stats/awards/clients); own-id-gated; 402 pre-check before any model spend, 503 without a provider key, failed/empty generation charges NOTHING. Charge-on-delivery under the doc lock — and the adversarial review's confirmed finding is fixed: the unlocked pre-check meant two concurrent generates at an exactly-sufficient balance could both reach settlement, with the loser's draft handed out FREE — now no delivery without a settled charge (the in-lock charge is the real gate; a refused settle returns 402, not the text). Drafts are never auto-saved: the new self-gating AiAssistButton (renders NOTHING on 404, so the editor is unchanged while dark) previews the draft with Use / Regenerate / Dismiss on the profile editor's headline + bio fields, with live "X SEK left" wallet status. Deferred to go-live/DG-9 (tracked): the top-up purchase route (core is ready; needs the payment rail), the portfolio-manager summary button, and social auto-post via the social vault. 5 unit tests (allowance/membership gating, idempotent charge, never-negative refusal, rollover + top-up persistence, idempotent top-up). Gates: clean-worktree full build exit 0, full suite 0 fail, 2-lens adversarial review (wallet-money + gating/scope; 1 confirmed finding — the free-draft race — fixed + re-gated).

• Phase 74 — Designer Growth Platform, wave DG-7: designer template marketplace (2026-07-18, ships FLAG-OFF). Designers can package the restaurant sites they build and sell them as templates, keeping 70% of every sale (platform 30% — owner-locked). Behind the fail-safe-OFF designer_marketplace master flag: every marketplace route 404s and existing platform themes are byte-unchanged until it's flipped (go-live also needs a buyer payment rail). Money core (lib/designer/template-sales.ts, pure + unit-tested): a sale records the author's 70% as a CommissionLedgerEntry (new sourceType: 'template') in the designer ledger — flowing through the existing Stripe Connect payout with zero new rail — idempotent per (template, buyer) so a retried purchase can never double-credit, and withheld (full audit) when the author's account/membership isn't active. Submission → moderation → sale: a designer packages a restaurant they actively MANAGE (not a referred link) via the existing tenant→package exporter into a namespaced slug (can't collide with or shadow a platform theme), stored pending; a super-admin approves/rejects; approved+priced templates list to buyers; the owner (owner-only — a delegated designer session can't spend the restaurant's money) installs one, which credits the author. Critical isolation: designer submissions are excluded from the normal owner theme gallery (listCatalog) — they're never a free installable theme, only reachable priced+moderated+flag-gated through the marketplace helpers; a self-deal (a designer buying their own template into a tenant they manage) is blocked. Surfaces: a designer-portal Marketplace page (submit form + submissions + earnings; clean "coming soon" while the flag is off — no dead-end) + sidebar entry; three flag-gated APIs (designer templates, admin moderation, tenant marketplace). Admin-moderation and buyer-catalog UIs are deferred to go-live prep (the APIs are complete; nothing is reachable while dark). 8 unit tests (70/30 split, idempotency, withheld gating, earnings netting, catalog-leak prevention, moderation gating). Gates: clean-worktree full build exit 0, full suite 0 fail, 2-lens adversarial review (money-integrity + catalog-leak — both agents probed the install/register/resolve leak vectors + double-pay/flag/self-deal paths, 0 confirmed findings).

• Phase 74 — Designer Growth Platform, wave DG-4: ambassador referral program (2026-07-18). Every designer becomes a Restora 360 ambassador: a personal referral code (WD-XXXXXX, minted on demand under the doc lock, unique, unambiguous alphabet) rides the same ref_code cookie rail as sales-agent codes (one attribution engine, first-touch-wins across partner types — validateReferralCode became a discriminated union branched by the reserved WD- prefix). A restaurant that signs itself up through the link gets a `kind:'referred'` DesignerRestaurant link with hard semantics enforced everywhere: earns the flat 5% referral rate (owner-locked sales-agent parity; per-designer CommissionRules never boost it — those price management work), but NEVER grants delegated access (excluded in requireTenantAccess, requireDesignerTenantAccess, and the access route's guard + in-lock re-check), never counts as "built" (restaurants list + restaurantCount recompute exclude it — leaderboards/achievements stay honest), and never anchors a verified review (a referral is attribution, not service). When a tenant carries both a managed and a referred link, the managed relationship wins deterministically in the commission engine. Register attribution is best-effort with a designer-side self-referral block and audit trail; the sales-agent branch is byte-preserved, and the SA-only forensic event store is never written for designer codes. Share & Grow gained a "Refer a restaurant — earn 5% for life" section: referral URL + QR + network intents + honest stats (referred signups, netted referral earnings) from a new own-id-gated referral API. 3 new unit tests (flat 5% ignoring rate rules, managed-beats-referred selection, referred-can't-anchor-reviews). Review: the subagent review pool was unavailable (session limit), so the adversarial checklist was executed inline over every designerRestaurants consumer repo-wide — it caught 9 additional consumer gaps, all fixed: the tenant-dashboard SHELL gate (defense-in-depth access exclusion), the maintenance cron's two restaurantCount recomputes (would have re-inflated counts with referred links), the designer-dashboard KPIs, the profile page's verified-review eligibility set, the admin designer-list count, the Growth-BI partner-leaderboard input ("sites live" ranks building work), and both link-resolutions in the owner review route. The build typecheck proved the validation-union rename complete repo-wide (it caught the one consumer grep missed). Gates: clean-worktree full build exit 0, 6954 tests 0 fail.

• Phase 74 — Designer Growth Platform, wave DG-6: discovery filters (2026-07-18). The public "Find a Web Designer" directory grew a full marketplace filter set: profession (the curated DG-0 taxonomy, with its own facet), availability (Available now / Limited), work mode (remote/hybrid/on-site), max hourly rate (budget search), and has case studies — alongside the existing country/specialty/service/featured/search filters, in an expanded More-filters row (all breakpoints). Privacy carries through discovery: the availability and rate filters only ever match designers whose privacy toggles expose those fields, and the cards show availability/hourly-rate only when visible — a hidden field can neither be matched nor inferred. Honesty fix: the directory's status column used to render a blanket green "Available" pill for every designer regardless of reality — it now shows the designer's actual exposed availability, or an honest "—". Cards gained headline, profession chips, published-case-study counts, and "from X SEK/h" pricing; the search haystack now includes headline + professions. City landing pages (Citation-Hub rail) stay deferred until real designer density exists — tracked in TODO.

• Phase 74 — Designer Growth Platform, wave DG-5: recognition — deterministic achievements + public leaderboards (2026-07-18). Achievements (lib/designer/achievements.ts): a pure, recomputed-on-read derivation from real numbers — restaurant milestones (1/10/50/100/500/1000 from the denormalized count), portfolio milestones (first case study, Portfolio Master at 6), reputation (Customer Favorite at 4.5+/10 reviews, Trusted by Clients at 3 verified reviews), trust (Fast Responder ≤4h, Verified Professional), earnings milestones (first commission, 10k/100k SEK from EARNED ledger statuses only) — never an LLM, never a stored counter, honest-empty for new designers. Surfaced as an Achievements card on the designer dashboard (earned chips + top-3 next-up progress bars) via an own-id-gated API, and as badge chips on the public profile — with the earnings group EXCLUDED from public display (income-tier privacy). Leaderboards (lib/designer/leaderboard.ts + public /designers/leaderboard): three boards — most restaurants built, highest rated (minimum 3 reviews before a rating ranks), best portfolios (published case studies) — over active+listed+verified designers only, with a country pill filter, honest-empty states, stable tie-breaks, top-10 caps, medal styling, profile links, and a become-a-partner CTA; linked from the public nav and the sitemap. No earnings data on any public surface. 6 unit tests (milestone progress, earned-status filtering, tie-breaks, min-review gate, published-only counts, country filter). Gates: clean-worktree full build exit 0, full test suite 0 fail, 2-lens adversarial review.
• Experience Studio — menu-board templates as starting points (MT-SIG × Studio, owner ask 2026-07-18). The PowerPoint model the owner described: open the Studio, pick "Menu TV screen" / "Digital signage", and start from one of the 6 signature designs — the template lands on the canvas as EDITABLE elements (themed background + a live menu block pre-bound to the tenant's real sections + title/hero/callout pieces), then everything is freely movable/reshapeable while staying on-theme. New lib/studio/menu-templates.ts (STUDIO_MENU_TEMPLATES): the 6 signature compositions re-authored in the starter-template idiom with a new menu() element helper; palettes come from THE Menu-TV registry (getTemplateMeta(...).art) so a Studio template and its TV twin can never drift; deterministic, size-adaptive, zero AI cost. Three attach points, all additive: (1) the project wizard's "Starting point" step gains a "Menu board designs · live prices from your menu" group for TV/signage/kiosk/customer-display types; (2) the create route resolves both registries and seeds a menu template with the tenant's category ids (menu order) so the board arrives PRE-FILLED server-side; (3) the Studio designer toolbar gains a Templates button + gallery — materializeTemplate replaces the current page in ONE undoable commit (confirm-first when the page has content) with the live board already in component state. Per-dish parity closed: the Studio's CanvasInspector now receives boardCategories + onSeparate (it didn't before), so "Style one dish" and "Separate dishes" work identically in the Studio designer as in the Menu-TV Screen Designer (separateEl mirrored onto the Studio page model, MAX_CANVAS_ELEMENTS-capped). StudioStarterTemplate.build gains an optional ctx (categoryIds) — the 10 classic starters ignore it, signature untouched. Gates: project tsc clean (remaining errors are the concurrent session's designer/marketplace WIP), studio unit tests 10/10, scripts/studio-templates-uat.mjs ALL PASS (real login → create signage project → materialize all 6 → live Luigi prices resolve on the stage → cleanup), screenshots of every materialized template.

• Phase 74 — Designer Growth Platform, wave DG-3: verified owner→designer reviews (2026-07-18). Restaurant owners can now leave verified reviews of the designer who manages them — the trust core of the marketplace. Verification anchor (supplier-reviews precedent): an ACTIVE designerRestaurants link AND a commercial relationship — commissionEligible link OR an actually-PAID subscription. The adversarial review proved the bare-link anchor was farmable end-to-end at zero cost (designer creates a free demo → claims it with a puppet owner account using the demo password the designer set themselves → the link stays active → unlimited verified 5★ self-reviews, with the demo slot resetting each time) — the paid-relationship requirement dead-ends the chain while a real claimed-demo client qualifies the moment they pay. One review per (tenant, designer), resubmits update in place, auto-published (authenticated + relationship-bound); admin unpublish is now DURABLE (second review finding: the author's resubmit could silently re-publish a moderated review — a new adminUnpublished flag survives resubmits; content updates save but stay hidden, and the form tells the owner honestly). Self-review blocked at both layers: the page gate and the API's owner-only check reject web-designer delegated sessions (a designer can never verified-review themselves through any session shape). Surfaces: the public profile swaps in a VerifiedReviewForm for the signed-in owner of a managed restaurant (overall stars + communication/design/delivery/support category stars + would-hire-again + prefilled from the existing review); review cards render category chips + a "Would hire again" badge; reviewer identity comes from live master records, never request input; the denormalized rating recompute is now ONE shared function (recalcDesignerRating) used by both the owner path and the admin moderation route. 8 unit tests incl. the full farming-chain and durable-moderation reproductions. Gates: clean-worktree full build exit 0, 6940 tests 0 fail, 3-lens adversarial review (3 confirmed findings — the farming chain + durable-moderation ×2 — all fixed + re-gated).

• Phase 74 — Designer Growth Platform, wave DG-2: Share Engine (2026-07-18). Every share now markets the designer AND Restora 360. Branded OG cards: two next/og convention routes (profile + case study) on the proven wow posture — slug-regex guard before any DB read, rate-limited, degrade-to-generic-card, unfurl cache headers; azure-navy brand gradient with "Created with Restora 360 · restora360.com" on every card; the case-study card honors the portfolio privacy toggle. Deterministic length clamps + font step-down (an adversarial verifier RENDERED the zod-max case and proved Yoga collapsed the layout into overlapping text — fixed), latin-only strings (a ★ glyph would have triggered a runtime Google-Fonts fetch inside the crawler-facing route — replaced with "Rated X/5"). metadataBase fix (major): the self-hosted box absolutized convention og:images against http://localhost:3001 (Next's fallback without metadataBase) — a new requestMetadataBase() helper (env override → forwarded headers, mirroring publicOrigin) now feeds both public designer pages, making every unfurl image fetchable. Share kit (/designer/share, sidebar "Share & Grow"): profile URL + QR + copy + 7 network share intents (LinkedIn/Facebook/X/Pinterest/Threads/WhatsApp/Reddit) with per-network UTM tagging, per-published-case-study share rows, unlisted-profile warning; every share affordance renders only with a real target URL (fail-closed on profile-load errors). Print collateral: GET /api/designer/[id]/share/pdf?kind=portfolio|card — a pdf-lib portfolio book (branded cover + profile QR + one page per published case study with embedded cover image, badges, testimonial, live/public URLs) and a print-ready business card (navy/azure, QR to the profile); WinAnsi-sanitized text with a truncation-correct wrapper (review fixes: exact-fit text was getting a spurious "..."; overlong single words hard-slice instead of overprinting the QR), images embed only from the designer's own /uploads namespace through the traversal-guarded seam, renders from the PUBLIC projections only, refuses (409) while the profile is unlisted and prints a cover-only book while the portfolio toggle is off — printed QR/links can never 404. Gates: clean-worktree full build exit 0, 6935 tests 0 fail, 3-lens adversarial review (14 raw → 12 confirmed → 7 distinct defects, ALL fixed + re-gated).

• Phase 74 — Designer Growth Platform, wave DG-1: Portfolio 2.0 + money-engine lock conversion (2026-07-18). Portfolio case studies: new DesignerPortfolioProject entity (cap 24/designer, gallery ≤8, bounded fields) with a full manager at /designer/portfolio (create/edit/publish/unpublish/delete, gallery uploads through the hardened media route, before/after pair, Built-with-Restora360 / Experience-Studio / Restora-AI badges, client testimonial, live/video links) — a new "Portfolio" sidebar entry, and one-click "Save to portfolio" on the Before & After pitch page (persists the pitch's before/after images as a draft case study; pitch results were previously ephemeral). Public: a case-study page at /designers/[slug]/work/[projectSlug] (published-only, active+listed designers only, rendered exclusively from the new publicPortfolioProject whitelist projection; CreativeWork JSON-LD, canonical, OG image; before/after figures, gallery, paragraphed body, testimonial block, and a designer + Restora 360 CTA — every case study markets both), a Case studies grid on the designer profile (respects the portfolio privacy toggle; legacy flat portfolio links remain as "More work"), and sitemap entries with Google-image extensions for every published case study. CRUD API under /api/designer/[designerId]/portfolio (requireWebDesigner + own-id, slug minted under the doc lock, slug stable across edits so public URLs never break, 409 at the cap). Money engines on the lock (deferred from DG-0): commission-engine.ts and payout-engine.ts rebuilt around PURE exported cores (applyCommissionRecord / applyCommissionReversal / applyBatchCreate / applyBatchSettle) wrapped in mutateDesignersDB — closing two real races: concurrent same-invoice webhooks could double-record a commission (idempotency now checked under the lock), and concurrent payout runs could double-pay the same pending entries (batch-create + entry flip now atomic). The lock is never held across the Stripe transfer. 17 new money-path unit tests (idempotency, withheld gating, per-designer rate rules, clawback semantics, batch atomicity, fraud-hold + override, settle success/failure) + 5 portfolio tests. Gates: clean-worktree full production build exit 0, full test suite green, multi-lens adversarial review.

• Phase 74 — Designer Growth Platform, wave DG-0: foundation + rich profiles (owner-approved program, 2026-07-18). The shipped Web Designer module starts its growth into a worldwide creative-partner platform (LinkedIn/Behance-bar; waves DG-0…DG-10 planned; commercial decisions locked: template rev-share 70/30, designer AI wallet + monthly allowance, referred-not-managed = 5%). Concurrency foundation: new mutateDesignersDB (Postgres row lock via mutateDoc + in-process mutex on JSON, in-place default-fill honoring the mutate-in-place contract) and ~16 designer routes converted off the racy get→save pattern — profile PATCH, public reviews, support ×2, invoices ×2 (the WD-YYYY-NNNN mint now lives INSIDE the lock so concurrent creates can't dup a number), delegated access, membership (cancel/DEV-activate), Stripe Connect (account-create moved before the lock; an existing stored id always wins the race — never orphan-overwritten), connect-webhook designer branch, admin reviews/escalations/edit, register (slug-uniqueness inside the lock), restaurants link-push. Response shapes/status codes byte-preserved; the commission/payout engines (cron-serial, multi-doc) convert in DG-1 with money-path tests. Adversarial-review fix: the restaurants onboarding closure no longer re-checks account/demo-limit after the tenant is already provisioned (that path would have orphaned a fully-created tenant + burned its subdomain) — it now only takes the lock for the atomic link-push + count recompute, with the policy enforced by the pre-provisioning guards exactly as before. Media hardening: the designer upload route now decodes→re-encodes through sharp (EXIF/GPS stripped, orientation baked, ≤2400px, JPEG q85, pixel-bomb guard, 64px floor, spoofed-MIME killed) and is rate-limited; public designer review + contact endpoints gained rate limits. Rich profiles (all additive): curated 25-profession taxonomy (lib/designer/professions.ts, chip picker, max 8), headline, cover image, hourly/project/min rates + currency, availability, work mode, timezone, working hours, years of experience, education/certifications/awards, socialLinks widened from 4 to 21 platforms (same field), 12 freelancer-platform links (Upwork/Fiverr/Toptal/…), and per-field privacy toggles enforced ONLY in the new whitelist server projection lib/designer/public-profile.ts (secrets — OTP codes, verify tokens, Stripe ids, commission rate, VAT, phone, admin notes — can never reach a public response; unit-tested incl. secret-leak assertions). Profile editor 2.0 (/designer/profile): imagery section with cover preview, profession chips, rates, credentials line-editors, 21+12 link fields, privacy eye-toggles, guarded load/save states. Public profile 2.0 (/designers/[slug]): cover hero with overlapping avatar, headline, Verified badge (from the existing verification lifecycle), availability pill, profession chips, credentials columns, social + "Also on" freelancer-platform chip rows, rates card — rendered exclusively from the projection; SEO upgraded to the shared <JsonLd> + a pure buildDesignerJsonLd builder (sameAs from links, knowsAbout from professions) + alternates.canonical. Gates: clean-worktree npm ci + full production build exit 0, full test suite green (6787, 0 fail) incl. projection secret-leak tests, multi-lens adversarial review (2 confirmed findings fixed).
• Menu TV — MT-SIG "Signature Templates": 6 new 1:1 board designs (static + animated), per-dish design control, Magic Fit, multi-display balance. The owner supplied 6 professional menu-board reference designs; each is recreated 1:1 as a first-class TV template with a FIXED authored palette + its own art-directed backdrop: Fast Lane (dark fast-food combo board — photo columns, white COMBO hero card with a red price burst, 3 promo banners), Rustic Bistro (whitewashed wood + procedural SVG grain/doodles, Pacifico script "Menu", brush-stroke section headers, dotted leaders), Summer Breeze (airy three-panel — round plates, orange price bubbles, SVG produce garnish on the edges), Color Stripes (full-bleed colour panels, one hero dish per stripe in a white-ring circle medallion, script+caps lockups in Bebas/Pacifico), Premium Smoke (yellow brand sidebar with an SVG burger-pattern + giant poster price, smoky dark 4×2 medallion grid), Salad Bar (script lockup + packed bowl-card grid with price badges + a "Today's pick" deal tile; sparse slides drop columns and scale the bowls up). Every template ships static + animated variants — one shared, reduced-motion-safe keyframe vocabulary (templates/motion.tsx: float/drift/ken/pulse/sway/spin/smoke/rise/wipe) gated by a new wire-safe menuBoardConfig.motion flag (absent = animated; never an emitted key when unset, so pre-MT-SIG feeds keep byte-identical version hashes). Architecture: TvTemplateMeta.art (palette/animated/demo) in THE registry; TV_TEMPLATE_IDS is now DERIVED from TV_TEMPLATES and imported by board-data + tv-devices (kills two hand-copied lists that could drift); signature palettes override brand tokens at resolution (owner heading/price picks still win) for the board AND deck screens. Per-dish design control (the "separate one by one" ask): menu blocks gain itemIds (dish-scoped blocks), itemStyles (per-dish colour/size/weight/hide) and feed-time itemOrder honouring — all resolved SERVER-side (filter/order/hidden are content-identical on native; style fields web-only, XS-9 precedent) with conditional version-hash wiring; the Screen Designer inspector gains a "Style one dish" panel and a "Separate dishes" action that explodes a block into one live-bound, freely placeable block per dish (verified end-to-end: 9-dish block → 9 independent elements, one undo step). Magic Fit (deterministic, zero AI cost — the designer stays a no-AI-credit surface): lib/tv-menu/magic-fit.ts scores every template against the LIVE menu (photo/description coverage, category roles via multilingual keywords, size) → "✨ Great fit" chips in the template picker; applying a template now one-clicks the best menu photos into its EMPTY image slots (owner-filled slots never touched) + flips on the content toggles the design leans on; "Auto-split across screens" is now balanced by ITEM COUNT (LPT partition) instead of round-robin. Bundled demo boards: demo-board.ts + 24 curated CC-licensed photos (public/demo/menu-tv/ with CREDITS.md) + 2 self-hosted OFL fonts (Pacifico, Bebas Neue in public/fonts/) make every photo-forward template preview 1:1 even on a photo-less menu — the picker falls back to the sample menu (labelled "Sample menu") until the tenant has 4 photographed dishes, and the new public `/tv/demo` player (?template=&motion=&slide=&cats=) doubles as the QA harness + a sales demo. Gates: project tsc clean (only pre-existing Phase-74 designer errors remain), scripts/menu-tv-qa.mjs 28/28 (all 16 templates × variants × category slices, zero page errors), scripts/menu-tv-designer-uat.mjs ALL PASS (real login → designer → per-dish panel → Separate, deck snapshot/restored), visual QA vs the 6 references via Playwright screenshots. Native TV apps render the new ids via the ledger fallback until Compose ports land (content parity server-side; documented divergence).

• Phase 73 — Marketing Supremacy ("Stamgäst"), Wave 4: the moonshots Vendion cannot match (all fail-safe OFF) — PROGRAM COMPLETE. ~14 tickets, 7 workstreams, closing the 5-wave / 98-ticket program. Hands-off Autopilot + growth plan (MOON-2/9, AI-6, UX-7): a pure AutopilotPolicy evaluator enforced at the orchestrator tick lets the engine auto-run ONLY zero-cost, sub-threshold, consented items — anything with spend or reach DOWNGRADES to "Needs your OK" (never drops, never over-spends); a deterministic "3 Money Moves" / daily best-move selector (composes the existing next-best-action/forecast/Pareto — each move fires only on a positive real count, one-tap to an existing rail), a weekly brief cron (de-duped against the ANA-6 recap), and a Weekly Growth Plan surface with a deterministic Autopilot Score. Predictive win-back + Regulars Radar (MOON-3, CRM-8): a deterministic churn-risk score (recency vs the guest's OWN cadence) added to the predictor, a once-per-lapse customer.churn_risk lifecycle event (rides the existing tick — no new cron) driving an approved-or-auto win-back, a churn-risk segment, and the Regulars Radar at the POS — recognizing an at-risk regular prompts a one-tap "gesture" that writes a REAL loyalty/gift ledger entry (idempotent). Dynamic offer & reward tuner (MOON-5, LOY-8): deterministic, margin-defended discount/reward suggestions (never below cost; honest fallback when cost data is absent), one-tap apply, AI only phrases the number. Peer benchmark (MOON-6): a k-anonymized "how do I compare to restaurants like me" — a weekly rollup writes each tenant ONLY their own values + bucketed peer medians/percentiles for a cohort above the minimum size (no PII or single-tenant value ever crosses tenants; honest "—" below the cohort floor). Gift portals (GFT-3/5): a self-serve corporate/HR gifting portal (reuses the Phase-65 bulk-invoice issuance) and recurring subscription gift cards (a due-based tick mints each occurrence via the gift engine, idempotent). Marketing concierge (MOON-8): a conversational marketing concierge over the EXISTING WhatsApp/IG/SMS Channels rail (opt-in/opt-out consent fail-closed, honesty-fenced replies via brain-call, allergen/regulated deterministic, sends through the consented broadcast rail with tag attribution — no parallel messaging engine; live send is keys-only). Reputation & Reach Cockpit (SOC-8): one cockpit fusing the reputation score, review-reply queue, referral performance, broadcast reach and social ROI into a deterministic Reach Score, plus a weekly Reputation Autopilot that PROPOSES the top reach actions into the existing approvals (never auto-sends). Seven new master flags; four new crons registered (scheduler + vercel.json). Gates: 6927-test suite (0 fail), full production build, project-wide tsc clean. The whole program is on prod behind fail-safe-OFF flags — go-live is flag flips + keys/certs only.

• Phase 73 — Marketing Supremacy ("Stamgäst"), Wave 3: unify, automate & close the loop (all fail-safe OFF). ~20 tickets, 7 workstreams, all extending the ONE existing engine. Journeys & loyalty triggers (AUT-4/5/6/7, LOY-4): the automation engine now emits loyalty.joined / loyalty.tier_up / loyalty.reward_ready from both paid-order earn sites (customerRef-tagged, Guardian-capped) with ready-made loyalty recipes; multi-step journeys run on the SAME idempotent dispatcher via additive MarketingActionStep.delayMs (a WAIT pushes the plan-item's scheduledAt forward) + guard (a deterministic BRANCH, failing guard = visible skip); a pure suggestAutomations proposes the owner's next un-adopted recipe (one-tap adopt); the recipe wall shows honest per-recipe "sent N, opened M" (null→"—"). One message everywhere (CMP-5/8/9): a pure omnichannel.ts router reaches each consented guest on their CHEAPEST channel (push > email > SMS) with cross-channel dedupe, folded into the broadcast engine — the stored result records routedAway (the measurable SMS saving) and a unified per-channel card. Loyalty reach + manual tags (LOY-5/7, SEG-5): loyalty tier + owner-applied tags become first-class CustomerView fields with dedicated segment resolvers + tier built-ins; the public loyalty page & Apple/Google wallet pass take the program's brandColorHex/logoUrl; the guest drawer gains a manual-tag editor (bounded, PATCH-persisted) and a "has tag" / "loyalty tier is" audience chip. Gift as acquisition (GFT-2/6/7): a gift recipient who becomes a new paying guest attributes to the buyer via the existing referral rails (self-gift blocked, idempotent); one-tap seasonal gift campaigns; plain-language breakage/liability aging from the BAS-2421 float. Offline→online attribution (MOON-4): a deterministic read-time join surfaces in-venue conversions (POS orders, gift redemptions, Phase-69 QR scans) on the SAME growth/ROI spine with an honest offline coverage % — in-venue revenue that was always "—" can finally appear (real or "—", never fabricated). Money loop (ANA-5/6/8): a deterministic next-best-action strip (lapsed regulars → one-tap win-back; birthday-soon big-spenders → offer), an honest trailing-trend revenue forecaster with a confidence band (never an LLM number), and a weekly "Money Recap" digest cron to email + push. Reach loop (SOC-6/7): a one-tap "Post to Everywhere" over the existing publish seam (7 socials + Google Posts + FSN; unconnected = honest skip) and scan-to-rate gate & route — happy guests to "Share on Google" + invite-a-friend (referral link), unhappy guests to a private recovery on the goodwill rail. Two new master flags (post_everywhere, scan_route); the money-recap cron registered in both scheduler + vercel.json. Gates: 6795-test suite (0 fail), full production build, project-wide tsc clean.

• Phase 73 — Marketing Supremacy ("Stamgäst"), Wave 2: the conversational + predictive marketing brain (all fail-safe OFF). ~16 tickets, 5 workstreams, built on one foundation: lib/marketing/ai/brain-call.ts — the SINGLE gated/RIC-routed/honesty-fenced/spend-metered entry point every new AI surface calls (triple-gate → RIC cutover → meter-even-on-fence-rejection at the one appendLedgerEntry wallet choke → assertNoFabrication → deterministic fallback; never dark, never fabricates) — and lib/marketing/crm/predict.ts, a PURE deterministic predictor (next-visit window + lifetime value, honest null under 3 visits) and per-guest tagger (regular / at-risk / new / birthday-soon), NO LLM. Conversational tools (AI-2/3/4, CRM-7, ANA-7): a new tools-marketing.ts adds four Ask-AI tools behind a 2-line registry edit — compile_segment (describe an audience in a sentence → an INSPECTABLE deterministic predicate over the 17-field whitelist → a confirm-first "create audience" card; the model physically can't emit a non-existent field), prepare_campaign (locate a plan → fenced draft → confirm-first Approve card via the existing approvals route; never sends directly), draft_variants (3 honesty-fenced copy options via brainCall), get_marketing_money (read-only Pareto + campaign funnel, real-or-"—"). Predictive guest brain (CRM-4/5, AI-7): the Guest 360 payload now carries the deterministic next-visit/LTV prediction + tags; the profile drawer gains a "What to expect" card, tag chips, and an on-demand honesty-fenced "Summarize this guest" (RIC-metered, cached by fact-hash in crmGuestMeta.aiSummary); tags also flow into the POS Guest Card and become three new targetable segment built-ins (at-risk / birthday-soon / high-basket). AI audiences (SEG-4/7/9): a plain-English "describe your audience" box compiles to inspectable chips via a pure deterministic nl-segment.ts (no LLM in the typed-box path), AI-suggested tag chips, and an Audience Radar that auto-discovers high-value under-served cohorts (deterministic scan, one-tap create, honest-empty). Waiter copilot (WI-6/7): one honest deterministic add-on suggestion at the POS (a real in-stock, allergen-safe dish — never a fabricated item/price; allergen banner stays dominant) plus a compact at-the-table guest Q&A. Copilot Dock (UX-4/AI-8): an always-there "Ask your marketing" dock on Marketing Home that commands the existing Ask-AI widget via a window event (no second chat, no new model/metering surface), with marketing starter chips + voice, gated on the agent being enabled for the tenant. Every AI output is fenced (numbers/prices/allergen facts are pre-computed and whitelisted; the model only phrases them), every guest email is masked before it reaches the model, and all prediction/segment math is deterministic. Gates: 6703-test suite (0 fail), full production build, project-wide tsc clean.

• Experience Studio — both AI studios rebuilt to the owner's mockup (design 1a/1b/1d, 2026-07-17), light + dark. After the Photo/Video split, the owner supplied a design sheet and asked to take the UI/UX inspiration without losing any functionality. Both studios are now a split layout: the guided controls on the left, a big Live-preview hero on the right that updates instantly. Photo studio: step 1 collapses a chosen photo to a compact "Your dish · Detected: …" card (Replace reopens the picker); step 2 "The look" is an accented card with compact style chips + "+N styles" expander and a direction swatch row whose thumbnails are real result previews; step 3 "Your words" is a slim card. The hero shows a before/after slider with the owner's headline overlaid live ("edit in step 3"), and once generated it becomes the result (renderer + WOW + use/ad panels). A "What you'll get for N SEK" value row (Animated scene / Landing page / WOW score) sits under the hero, and the priced Generate button carries "everything above is free — you only pay when you generate" + the included-image quota. Direction lightbox (design 1d): clicking any swatch opens a large real example with ←/→ browsing and a "Use <direction>" commit (Esc/Close, full dialog semantics). "Create | My generations (N)" header toggle (design 1a): the saved-generations gallery is its own view instead of an endless scroll; its handoffs jump back into the right studio. The Video studio gets the same language: source-photo card, motion chips + swatches, and a hero pane that plays the motion sample and then the finished clip big, with its own value row (8-second clip / AI voiceover / ad exports). Every money path preserved (adversarial review: no money/functionality defects) — gates, the 428 billing ack, prices-from-config, refund messaging, the VideoAdPanel machinery, batch remove-bg top-up, FSN /uploads gating. Money fix uncovered by the review: the video-first ack path used to run the image generate() after accepting the disclosure — a Video-studio owner accepting their first-time ack would have been charged for an image they never asked for; now acceptAck auto-continues only the image flow (ackFor), and the video owner simply presses Create again past the ack. Verified: tsc + full build exit 0 (gated in a clean worktree — the shared main tree currently carries another session's half-written Phase-73 files); light + dark render checks of both studios and the lightbox; scripts/es-split-qa.mjs 15/15 ON PROD (both studios, tab switch + URL sync, deep-link, the new hero + value-row assertions, zero page errors).

• Phase 73 — Marketing Supremacy ("Stamgäst"), Wave 1: Vendion parity, in the owner's hands (all fail-safe OFF). ~23 tickets across 12 parallel workstreams, every new surface behind a strict-binary master flag (5 new: sms_campaigns / money_insights / customer_referrals / reputation_hub / consumer_broadcast) so today's behavior is byte-identical until flipped. Loyalty (LOY-1/2/3/6): klippkort/stamp-card mode on the ONE loyalty engine (per-order / per-item / per-category / per-amount rules, free-item or %-off reward, deterministic two-seam reward redemption mirroring points), a public no-login guest page at /tenant/[id]/loyalty (HMAC magic-link, points/stamps/tier/reward progress, join-by-email) that fixes the long-dead /loyalty CTA, a one-screen guided setup with a live phone preview, and Swedish alcohol-law-correct earning (excludes vatCategory:'alcohol' lines from the earn base, deterministic — never inferred). Self-serve SMS (CMP-2/3/6): a /dashboard/sms composer reusing the email-builder shell with a live GSM-7/UCS-2 segment + honest cost preview (owner-entered price only, "—" when unknown), the auto-appended Reply-STOP hint, a shared AudiencePicker, and the email builder's segment recipient mode wired end-to-end. Recipe wall + safety (AUT-3/8): /dashboard/marketing/recipes — every automation template as a one-tap light-switch (plain-language "what will happen", cooldown in words, themed confirm), a master "pause all", visible Guardian status, and "test on me". Waiter Intel (WI-2/3): the POS Guest Card (name · "regular, N visits" · favourite dish · loyalty reward-ready · VIP) on the order/sell screens, fed by the Wave-0 resolver (404 → renders nothing, byte-identical when off), plus a deterministic Allergen Shield cross-checking cart items against the guest's saved allergens (inline warning chip, never blocks the sale). Money Insights (ANA-1/2/3): a plain-language /dashboard/marketing/money "what made money" screen (a Pareto "top-N regulars = X% of revenue" over real spend, per-campaign honest returns with the coverage caveat, a deterministic "what to do next" strip) + SMS delivery-receipt & click tracking (provider status webhooks + an HMAC short-redirect, real-or-"—"). Gift parity (GFT-1): a one-click "expire after 36 months" preset (SE default stays no-expiry) and a named Björn Lundén SIE4 export. Simplicity (UX-3/5): a 3-minute Marketing Setup wizard (writes only manual-approval mode — never auto) and a reusable Confidence Card ("see it before it happens": reach · consent-excluded · cost · preview · undo). Day-part audiences (SEG-3): deterministic Fredagsgäster / Lunchgäster / Helggäster / Allergiker built-ins from real order timestamps + dietary data (friendly chips in the Audience Builder). Refer-a-friend (SOC-1): a give-X/get-X loop on the EXISTING coupon/loyalty/gift rails (unique codes, first-touch cookie attribution, an idempotent order.paid conversion cron, self-referral + min-order guards) — reward codes filtered out of the public offers list so they can never leak. Reputation + broadcasts (SOC-2/4): a /dashboard/marketing/reputation hub with ONE deterministic weighted score across Google + internal reviews (TripAdvisor/Yelp/Meta honest "—" until keys) and a /dashboard/marketing/broadcast "Tell your customers" studio (push/email/SMS to opted-in guests, live per-channel consent-fail-closed reach, Guardian-capped). Social live-publish (SOC-5): every platform behind ONE publish() seam with encrypted per-platform token vaults — FSN live now, the rest activating as OAuth keys land (honest "not connected", never a faked post), trust levels preserved. Guest 360 profile (CRM-2): the /dashboard/customers drawer over the Wave-0 spine — one visit+order+booking+review+loyalty+gift timeline, per-currency gift balances (never summed), owner notes + VIP toggle, deep-linkable by ?guest=<ref>. Three new crons registered in the platform scheduler + vercel.json (sms-campaigns, customer-referrals, marketing-broadcasts). Gates: 6634-test suite green (0 fail), full production build, project-wide tsc clean, dark-vocabulary + no-native-dialogs guards.

• Phase 73 — Marketing Supremacy ("Stamgäst"), Wave 0: the load-bearing seams + the one door (all fail-safe OFF). Nine tickets across 8 parallel workstreams, every surface behind strict-binary master flags (guest_360 / marketing_home / audience_builder, new multi-key lib/marketing/supremacy-flag.ts cloning the gift-cards flag shape; flag OFF = byte-identical behavior). Base-plan de-gating (SEG-2/ANA-4): segment list/create/edit/delete/preview and the honest marketing-analytics READ dropped their marketing-autopilot add-on gate — insight is free, every send/spend path keeps its gate. Guest 360 spine (CRM-1): lib/marketing/crm/guest360.ts — buildGuest360(db, email, nowIso) composes the unified customer view and joins order line-items (top dishes + "the usual", combo header lines only), loyalty points + derived tier, per-currency gift balances (GDPR-erased sides excluded), reservations, exact-email reviews, and the new bounded TenantDB.crmGuestMeta (owner notes + persistent VIP, cap-evicted, normalized-email keys); customers route gained flag-gated GET ?email= detail + PATCH notes/VIP (audited). Per-visit trigger (AUT-1): order.paid joined MARKETING_RULE_TRIGGERS with additive customerRef (sha256, never raw email) enrichment across all 10 emit sites (POS settle, born-paid, unified seam, table-QR pay, payment-intent, channels, Adyen, gift engine), plus the previously-deferred post-visit review-request rule template. Anti-spam Guardian (AUT-2): global per-customer frequency cap (default 3 sends/7 days, protecting even unconfigured tenants) + quiet hours as owner-configurable MarketingState fields (brain-route zod + clamped merge), enforced at plan time as VISIBLE skips (never silent drops), per-customer fire history bounded in the automation store, stamped on dispatch success; cap-unevaluable (no customerRef) fails closed for customer-directed sends. SMS STOP → consent (CMP-1): new public inbound webhook receivers for Twilio (HMAC-validated) + Vonage with STOP/STOPP/SLUTA keyword classification, pure applySmsStop flipping smsNotifications consent by loose phone match (over-revoke beats texting an opted-out guest); the SMS-ordering webhook now honors STOP before its channel gate; marketing SMS bodies gain the "Reply STOP" hint (EN/SV). Ask-AI guest tools (AI-1): get_guest_insights (per-segment counts + masked samples) and get_guest_detail (exact-email, masked, birthday month-day only) — the live agent can finally read the CRM, guest_360-gated, raw emails never reach the model. Audience Builder (SEG-1): /dashboard/audiences — plain-language chip composer over the existing deterministic segments API (live reach counts, consent-eligible counts, masked samples, If-Match concurrency, honest "(advanced)" rendering for API-created shapes). Marketing Home (UX-1/2): /dashboard/marketing became a server component that renders the classic hub byte-identically while marketing_home is OFF and, when ON, a plain-language front door (outcome tiles → guests/audiences/email/loyalty/gift cards/reviews/week/what-made-money, real-or-"—" stats via the new KpiOrDash primitive, classic hub always reachable via ?view=all and every ?tab= deep link). Approve my week (MOON-1): /dashboard/marketing/week — the already-computed weekly orchestrator plan as approve/skip cards + honest approve-all over the existing per-plan approvals endpoints (no new engine; 409/404 refresh, never fake success). POS guest resolver (WI-1): pure lib/pos/guest-intel.ts + flag-gated GET /pos/guest-intel — exact-match-only guest projection (visits, spend, favorite dish, strictly-deterministic allergens, loyalty reward-ready, VIP/notes) ready for the Wave-1 Guest Card; never fuzzy-matches (wrong-guest allergen info is a safety failure). Gates: 654 cross-cluster unit tests green (incl. accounting + intelligence event-contract consumers), full production build, dark-vocabulary + no-native-dialogs guards.

• Experience Studio — AI Photo and AI Video are now two dedicated studios with an enterprise redesign (owner ask 2026-07-17: "separate AI image and AI video; redesign both to a more professional enterprise-level UI"). The single merged page that served both from one long form is now a mode-aware workspace: AI Photo Studio at /dashboard/experience-studio (URL unchanged — every existing link/bookmark still lands on photos) and AI Video Studio at ?mode=video, chosen with a real segmented switcher (role=tablist, per-tab aria-selected, "Styled marketing images" / "Cinematic video ads"). The Quick Create cards on /studio, the project wizard, and the Studio hub now deep-link the two modes separately (StudioShell shows two tiles: AI Photo Studio + AI Video Studio). One shared shell still owns entitlement (trial DEMO vs paid), the one-time 428 billing disclosure, pricing, the brand kit and the reference examples — zero engine drift, one set of API contracts — so every money path is byte-preserved: paidGranted gates both the image Generate and the video Create (a locked, priced card in demo), the ack modal, 402 AI-budget handling, the heroPhotoFailed refund message, charge-on-delivery, the remove-bg batch top-up flow, and FSN publishing gated on a hosted /uploads URL. Enterprise layout: a two-pane grid (the guided flow on the left, a sticky summary rail on the right showing a live preview, the exact SEK for the next action and the included quota) with numbered step cards, a filterable Your generations gallery (All / Photos / Videos tabs + "Show more" paging replacing the endless grid), and a calmer, consistent card system. AI Video Studio is now first-class: it opens on "Choose your source photo" (pick a saved Studio image, upload, or jump to the Photo studio to make one) instead of only appearing after a paid image — then style/direction motion pickers, Instant vs Narrated, and the create → poll → export → market machinery (unchanged). Cross-studio handoffs: an image result offers "Make a video from this image" (sets the source explicitly so re-use never animates the wrong photo), and the gallery's "New from this" / "Make video" switch modes with the right source. Video-first creators who hit a first-time 428 now get the billing disclosure, not a generic error. Verified: full tsc + production build exit 0, dark-vocabulary + no-native-dialogs guards green, a 3-lens adversarial money/gate review (1 regression found + fixed: the image→video source handoff; 1 hardening: the video ack gate), and a Playwright smoke (scripts/es-split-qa.mjs: both routes, tab switch + URL sync, deep-link, zero page errors).

• Phase 72 — Experience Studio Enterprise (Creative Suite), waves XS-0…XS-10. Experience Studio grew from a launcher + one-click AI generator into the platform's single creative hub, Canva-class but restaurant-simple — with zero parallel engines. Home 2.0 (`/studio`): "What would you like to create today?" prompt box (deterministic intent→preset matcher, never an LLM call), Quick Create cards (~20 project types with honest time estimates; AI Image/AI Video cards deep-link the existing paid Studio AI with its full gate chain — the new surfaces themselves never charge), a Continue Working grid (thumbnails, Draft/Published/Archived/Template chips, favorite/duplicate/archive/delete, relative edited times, skeletons + premium empty state), a starter-templates rail, and a 4-step project wizard (Type → Canvas size incl. custom 200–4096 → Starter template/Blank → Name). Projects: new StudioProject model on the tenant doc (cap 100, never silently evicted; multi-page; draft→published→archived + template lifecycle; publishedTo history) whose pages reuse the ONE shared CanvasElement model, sanitized by the ONE shared sanitizeCanvasElements (now stage-size-parameterized — portrait/social/print canvases keep 2× full-bleed headroom; defaults byte-identical for Menu TV/Kiosk). Studio-only layer extras (name/lock/hide) live in a side meta-map keyed by element id — the wire type native TVs/kiosks decode is untouched, and publishing strips hidden layers structurally. Studio Designer (`/dashboard/studio/designer`) — the THIRD host of the shared canvas engine (CanvasStage/CanvasInspector, additive stageW/stageH + lockedIds props): variable canvas sizes, dotted workspace with zoom-to-cursor (10–200%) + fit, pages rail (add/duplicate/rename/reorder ≤12), Layers panel (rename/eye/lock/reorder with dense integer z — native Int decode preserved), per-page gesture-coalescing undo/redo incl. layer meta, 1.5s debounced autosave + Ctrl+S, inert Play overlay, insert bar (text/image/video/shape/live-menu blocks + QR codes — server-rendered deterministic PNGs inserted as normal image elements, free). Export: WYSIWYG DOM raster of the real renderer (html-to-image; no parallel painter) → PNG 1×/2×, JPG, multi-page PDF (pdf-lib), JSON; auto-thumbnails on save (20s throttle); honest 413→1× retry and 503 storage messaging. Publish pipeline — one design fans out through each destination's EXISTING sanitizer + store, never a bypass: Menu TV (pages become layout:'canvas' deck screens with stable sps_* ids — re-publish replaces, never duplicates; uniform-scaled + letterboxed to 1920×1080), Kiosk welcome screen (attract canvas, kind-filtered honestly), Customer Display ad reel, Social draft post (drafts only — can never auto-publish), Media Library; per-target feature gates mirror each target's own routes (kiosk 402 + upgrade prompt). Brand kit: additive logoUrl on the ES BrandKit + one-click Apply-brand (single undoable commit: surface→background, primary→shape fills, luminance-contrast text ink) and Add-logo, with save-back to the kit. Entrance animations (fade/rise/drop/pop — the compositor's MotionStep vocabulary verbatim) as an additive CanvasElement.anim field: whitelisted in the shared sanitizer, rendered on web boards' incoming rotation layer + the designer's Play overlay (reduced-motion aware), byte-identical feeds when unset (no key emitted, conditional version-hash append — no fleet-wide TV re-ship), native TVs render static until the Compose port (documented divergence). Also: /studio registered hub-linked "Studio Designer" nav (all 20 languages), shared dialogs now detect the studio's scoped dark theme, and the /studio shell's ?section=/theme seeding moved to a mount effect (recurring React-#418 hydration class). Gates: 6340-test suite green, full production build exit 0, 5-lens adversarial review workflow, and a 33-assert Playwright smoke (scripts/studio-qa.mjs: lifecycle → export/QR/publish → Home light/dark/deep-link → designer/Play; self-cleaning). Plan: docs/Phase-72-Experience-Studio-Enterprise.md.

• Kiosk Designer — "+ New template" now opens the empty page canvas directly (owner UAT 2026-07-17: "it is confusing, it should open the empty canvas so user can fully design kiosk, all empty pages"). Previously the button only blanked the design tokens — the preview stayed fully populated, so it looked like nothing happened. Now it lands the owner straight in the fullscreen canvas editor on an empty Start screen, and the editor grew page tabs (Start screen · Eat here/Take away · Menu · Order number, with per-tab element counts) so every page can be designed without leaving the editor — plus an explained chip for Item options · Order review (live ordering screens with no freeform canvas by design: the working controls can never be covered, they take the theme's colors/fonts). An empty-page hint overlay ("This page is empty — design it") shows on any canvas with no elements. Hardened after adversarial review (2 confirmed defects fixed): switching page tabs now remounts the studio's preview engine (the engine reads initialScreen only at mount, so after Done the Pages rail/inspector showed "Menu" while the preview was still on the Start screen — in-preview block editing was unreachable); and the empty-page hint is target-aware — on the Menu tab it leads with the 🍔 Menu block and states that a designed menu page replaces the standard grid (the generic "add Text/Image/Box" advice would have produced a menu page guests can't order from), plus a persistent amber "No Menu block yet — guests can't order dishes on this page" warning whenever the menu canvas has elements but no Menu block. Verified with a 13-assert Playwright smoke (tablist, tab switching, menu-only inserts, target-aware hint, amber warning, per-canvas hint clearing, Done, API-cleaned dev tenant).

• Menu TV — template picker with live thumbnails + all-slides preview popup (owner ask 2026-07-17: "thumbnails for Templates; click = popup with all screens, apply/cancel/reset"). The per-screen Template grid on /dashboard/menu-tv (previously text-only buttons that applied instantly) is now TvTemplatePicker: each of the 10 board templates renders as a live mini-preview (the real MenuBoardScreen on the page's already-fetched preview board, re-skinned per template exactly like the TV feed — config.template + that template's slot images; inert, non-interactive). Clicking a template opens a popup showing every slide of the rotation (buildPages, the same paginator the TV runs; slide count in the header; capped at 12 shown) with a light/dark toggle (the other mode's board is fetched once, lazily) and Apply (keeps the screen's custom colors + display options — this preview already shows them) / Reset colors (returns custom heading/price colors to Auto) / Cancel — house dialog semantics (role=dialog, aria-modal, Escape, initial focus, aria-pressed toggle). Hardened after an adversarial review (confirmed finding + review-flagged issues fixed): the other-mode board is cached keyed by the exact cfg + mode — fixing both a staleness bug (the picker outlives many cfg edits, so an unkeyed cache served a stale/wrong-mode preview) and an infinite refetch-on-failure loop (a failed fetch is now recorded, not retried); the 10 thumbnail boards are memoized so opening the popup doesn't re-render all of them; and the footer copy now states honestly that the preview matches Apply (Reset was reduced to a colors-only reset since display toggles are per-screen content, not template styling). Verified with a 14-assert Playwright smoke (incl. a request-count guard proving the alt-mode board fetches exactly once across repeated toggles) and a self-cleaning paired test TV.
• Navigation fixes (owner UAT 2026-07-17: "Kiosk Designer hard to find; back-to-Kiosks lands on Devices & Apps overview"). Root cause: /dashboard/devices read ?tab=… in its useState initializer, which (a) races client-side navigations — deep-links like the designer's back link silently landed on Overview — and (b) mismatched the SSR HTML (hydration error). The tab now resolves in a mount effect and tab clicks sync the URL via replaceState, so deep-links, refresh and back all land on the right tab. Also: the Devices overview kiosks card gained a direct 🎨 Kiosk Designer link, the Studio hub's "Kiosk templates" tile now opens the Kiosk Designer itself (where the new template popup lives), the designer's back link is labeled "Kiosk fleet", and the Menu TV page no longer renders window.location.origin during hydration (second hydration error fixed).

• Kiosk Designer — template thumbnails + all-screens preview popup (KD-12). The "Base template" rail now shows each of the 5 luxury templates as a live thumbnail (the REAL KioskEngine scaled down on the attract screen, pure template look, non-interactive) instead of a text list, with an "In use" badge on the active one. Clicking a template opens a preview popup rendering all 6 kiosk screens (Start · Eat here/Take away · Menu · Item options · Order review · Order number) with the tenant's live menu, a light/dark toggle, and three actions: Apply template (switches the base, keeps the owner's colors/texts/photos/canvases), Reset to this template (also clears customizations so the kiosk matches the preview exactly; disabled when there's nothing to clear), and Cancel — a KD-4 version snapshot is taken before either change. KioskEngine gained an additive staticPreview prop (skips the window idle-guard listeners and the done-screen auto-reset) so pinned mini previews never drift back to the attract screen — devices never pass it, runtime behavior unchanged. Hardened after a 25-agent adversarial review (5 confirmed findings, all fixed): thumbnails are inert (pointer-events alone left ~40 invisible engine buttons Tab-reachable — Enter could mutate a pinned screen; also an aria-hidden-focus violation), rail cards are role="button" divs (no button-in-button DOM nesting), the popup follows the house dialog idiom (role="dialog" + aria-modal + Escape + initial focus, like confirm-dialog.tsx), the staticPreview idle-effect branch still clears timers on unmount, and — the real data bug — sanitizeKioskDesign now persists a baseTemplate-only design instead of deleting the record ("Reset to this template" and a fresh template pick used to silently forget the chosen base on reload; design.test.ts updated to lock the new rule, invalid baseTemplates still drop).

• Ask AI 2.0 — a full ChatGPT-style assistant over the whole system (owner ask 2026-07-17). The Ask AI widget grew into a big, centered chat window (expand/collapse, remembered per user; tenants open large by default) whose agent now knows the platform end-to-end and answers in 2–3 lines with rich blocks under the message: KPI stat cards, tables and mini charts (line/bar/donut — self-contained SVG, AskAiBlocks.tsx). 5 new KPI read tools build every block server-side from live engines (never the model): get_business_kpis (revenue/orders/AOV + revenue-by-day chart + top sellers, vs-previous-period deltas), get_costs_and_profit (Restora Profit core: monthly costs by category donut, labor %, food cost %, net margin + a per-staff true hourly cost table incl. employer load), get_staff_schedule (who works the next 1–6 weeks + est. labor cost), get_payment_status (unpaid supplier orders, platform invoices due, received-by-method 30d), get_channel_kpis (FSN followers/engagement, Food Bazar orders/rating/listing views, GA4/Search-Console website stats when connected, campaign ROI). 5 new confirm-first action tools — same hard contract as the supplier flow (the agent only PREPARES a card; the user's click fires an existing auth-guarded API): prepare_price_change (menu item price, PATCH re-validated server-side), prepare_offer (goes live on confirm), prepare_setting_change (safe whitelist: per-day opening hours, accept-orders-while-closed), prepare_social_post (publishes to connected socials), get_marketing_suggestions (autopilot's pending plans + one-click approve card through the audited approvals route). Every agent answer now carries an honest AI-usage strip (this answer ≈ $, % of lifetime credit used) computed from the wallet choke point. ActionButton gained PATCH; ActionCard gained a change kind with before→after summary. scripts/askai-qa.mts = 35-assert deterministic QA (tools never write, cards always tenant-scoped, invalid inputs rejected) — all green on the dev seed. Agent stays flag-gated (askAiAgent / SUPPORT_AGENT_ENABLED). Owner UAT fixes (same day): new get_menu_items tool (current prices lookup — "what's the current price?" was unanswerable and the price-change flow now states the old price before asking for the new one), and the "Yes, go ahead" chip only appears on genuine yes/no offers ("Want me to…?"), never when the assistant needs a value like a price. UAT round 2 — "it confirmed but the menu still shows 18 kr": the change had never been applied (the card's Apply button was never fired; the chat text read like a confirmation). Three-layer fix: (1) cards now carry an unmissable amber "Not applied yet — press the button below" banner until actioned, and the prompt bans "done/confirmed/updated" wording for prepared cards; (2) verify-after-apply — after a successful click the widget re-reads the changed record and proves it ("Diavola is now 100 kr on the live menu") via a new ActionButton.verify contract + a new GET on the single-product route; (3) the product PATCH/DELETE routes now revalidatePath the public storefront (/tenant/<id>, /tenant/<id>/menu) so an applied price shows on the live menu instantly — previously even a successful change kept serving the cached old price. UAT round 3 — "Food Bazar shows a different price": that page was another restaurant's same-named dish (marketplace, per-restaurant pricing — not a bug); the real find was that the owner's own dish was held off Food Bazar by the photo-quality gate with nothing telling them — get_channel_kpis (bazar) now reports dishes-on-Bazar vs held, plus a "Held off Food Bazar — fix to list them" table with per-dish reasons (no photo / photo flagged / no price / no description), so the agent answers "why isn't my dish on Food Bazar?" honestly. Human review loop over the AI photo gate (owner ask — one system, no parallel build): the EXISTING owner held-banner on /dashboard/food-bazar now shows the AI's issue tags and a "Photo looks fine? Request a human review" button (new POST …/food-bazar/request-photo-review stamps photoQuality.reviewRequested); the EXISTING super-admin Food Bazar hub gained a Photo review tab (badge-counted queue across all tenants, image preview + AI issues + score, owner-requested first) with Approve — overrides the AI verdict to `pass` for that exact image (audited, re-lists via ensureBazarListing; a later photo change re-scores normally) or Keep held (clears the request). photoQuality was previously written by the scorer and read only by the feed gate — no human had any view of it.

• Menu page — direct "Screen Designer" link in the toolbar. /dashboard/menu now has a Screen Designer button next to History/Import that opens the Menu TV signage designer (/dashboard/menu-tv/designer) — the same freeform canvas Experience Studio links to — so owners editing the menu can jump straight to designing their TV screens.

• Every image-URL field on the platform now has an Upload button. A full-platform scan (6 UI slices + endpoint audit) found every text input where a user was expected to paste an image URL; each one now also uploads from mobile/computer via a new shared ImageUrlField primitive (components/ui/image-url-field.tsx: URL paste kept, Upload button with spinner/error/thumb-preview, per-surface styling, onUploaded kind callback). Wired (19 fields): tenant offers Banner Image, blog Cover + OG image, Settings → Branding logo, SEO hub OG image, Mason Style-tab background image (upgraded to the full MediaPicker), the email/blog rich-editor Insert-image dialog (per-tenant), admin platform-SEO Default OG + Organization logo, admin TV-ads Creative (auto-sets image/video kind), admin Food-DNA set-image, admin Experience-Studio DNA-detect, admin Ingredient drawer, designer-portal avatar/logo/portfolio images, chain (group) logo/hero/white-label favicon. New upload endpoints (shared lib/media/save-upload.ts writer, mirrors tenant-media validation): POST /api/admin/media (super-admin, /uploads/admin/, image+mp4/webm), POST /api/designer/[designerId]/media (own-designer only, /uploads/designers/<id>/), POST /api/group/[orgId]/media (requireGroupAccess, /uploads/groups/<orgId>/). The three new namespaces are registered in RESERVED_UPLOAD_DIRS so the retention sweep can never mistake them for orphaned tenant dirs. Dead components (SeoSettingsTab, BlogEditorModal, legacy StyleEditor — zero importers) deliberately skipped; YouTube/Vimeo/embed link inputs excluded (page links, not media files).

• QR generator — Logo Overlay now has a Browse button to upload the logo from your device. Next to the existing URL field, a Browse button uploads the picked image through the tenant media library (POST /api/tenant/[tenantId]/media — so it also appears in Media), with inline validation errors (type/size mirrored client-side) and an uploading state; the returned /uploads/... URL drops straight into the logo field. Server-side, /api/tenant/[tenantId]/qr now inlines local /uploads/... logos into the SVG as data: URIs, so downloaded SVGs are self-contained — a relative href would 404 outside the site and prod doesn't serve /uploads statically. Hardened (3-lens adversarial review): the server-side /uploads read is scoped to the calling tenant's own prefix and reuses the public-media isPrivateMediaSubtree guard, so the QR route (gated only by requireTenantAccess, any staff role) can't read another tenant's uploads or the HR/ATS PII vault (hr-docs/, fsn-resumes/); the inlined content-type is taken from the media record's real mimeType (falling back to an extension map that now includes the .jfif/.jpe/.jif JPEG aliases) so a valid JPEG saved under one of those no longer silently drops from the SVG; a logo over 512 KB (or of undeterminable type) is referenced by its same-origin href instead of base64-inlined, bounding memory/ZIP size across the up-to-100 bulk-table SVGs and the per-request heap. The injected <image href> is XML-attribute-escaped.

• Personalliggare — the statutory Swedish staff register (SFL 39 kap. 11–12 §§, SKVFS 2015:6), end-to-end. The DB-8 terminal punch ledger now doubles as a compliant electronic personalliggare. Personnummer on staff: new encrypted StaffMember.personnummerEnc (+ display mask YYYYMMDD-••••) via the proven AES-256-GCM PII seam — validated/normalized to the canonical 12-digit form (Luhn + real-date + samordningsnummer support, lib/workforce/personnummer.ts), edited on the HR profile tab (audited reveal, hr.manage-gated), wiped by GDPR staff-erase, masked-only in the worker DSAR export, and wired into AGI filing as the real BetalningsmottagareId (fältkod 215, decrypted at build time, employeeNumber fallback). Register surfaces: an on-premises inspection view ON the venue terminal (new PersonalliggareScreen, reachable from the clock-in gate and Settings → Compliance; the register's structure — names + times — shows without a PIN since inspections can precede opening, but the full personnummer column needs a staff clock-in code, is brute-force-throttled and audited per view; auto-closes on idle), a dashboard register at /dashboard/personalliggare (Team nav, day browsing, live today view; personnummer + exports are hr.manage-only — lower tiers see coverage, never the numbers), and print/CSV exports (audited, spreadsheet-injection-safe) stamped with venue name + organisationsnummer, timestamps in the venue's timezone, and the statutory 2-year retention statement. GDPR-erase now honours the register's legal retention (art. 17(3)(b)): punch rows inside the 2-year window keep the name + an encrypted personnummer snapshot; older rows stay fully pseudonymised. Manual after-the-fact insertions (deviceId 'manual-entry') and corrected punches are honestly flagged on every surface with their immutable PunchEdit trail. Missing personnummer / missing orgnr are surfaced as fix-it compliance gaps (orgnr saveable inline). New feature-registry entry personalliggare (basic plan, per-tenant toggle, depends on staff-shifts); endpoints: device-token POST /api/public/android-terminal/personalliggare, tenant GET /api/tenant/[tenantId]/personalliggare (json/csv/print). Timesheets corrections UI: the previously API-only editHours / insertMissedPunch actions now have a themed correction modal in /dashboard/timesheets (mandatory audited reason, client mirrors the server's 24h/future/locked-period rules).

• Studio Home — project-card overflow menu rendered UNDER the templates rail (owner UAT 2026-07-17: "Delete goes behind the Bold offer card, takes seconds to come above"). Root cause: the card's hover lift (transform: translateY(-2px)) creates a CSS stacking context, so the popup's z-index only competed inside the card — the rows extending past the card painted beneath the later-DOM templates section until the pointer left the card and the hover transition dissolved the stacking context (hence the delayed "pop above"). Fix: while a card's menu is open (data-menu-open) the card itself gets z-index: 50 with the lift frozen, so the whole stacking context sits above sibling cards/sections and the menu never shifts when the pointer crosses the card edge. Verified with an elementFromPoint hit-test on the Delete row over the templates rail + screenshot.

• Cron drift: `/api/cron/bazar-visit-reminders` and `/api/cron/tv-ads-settle` were born dead on prod. Both were declared in vercel.json (inert under pm2) but never registered in PLATFORM_CRON_JOBS, so visit-reminder emails and scheduled TV-ad settlement never fired on the box. Registered with their documented cadences (daily / hourly); the MK-3 drift guard now passes again.

• Public web shop — full consumer redesign + accounts (`/shop`). The Restora 360 Shop is now a complete public e-commerce storefront anyone can buy from: sticky nav with live search + account + cart, an admin-managed hero banner slider (new Banners tab on /admin/dashboard/webshop, banners on the webshop doc, optional per-banner coupon chip), a "Today's offers" deals rail driven by a new display-only compareAtPrice (strike-through + −% badge; charging still uses basePrice/priceTiers only) plus a featured flag, a left categories + filters rail (price range, in-stock, on-offer, sort — slide-in sheet on mobile), product cards with deterministic per-category art for photo-less items, product detail pages (/shop/p/[id], SEO metadata, bulk-tier table, qty-aware pricing), a slide-in cart drawer (localStorage cart, server re-prices everything), and a real checkout page (contact + delivery address + EU VAT preview + coupon + invoice/card choice; Stripe Checkout returns land on /shop/checkout which confirms server-side). Customer accounts: the shop reuses the platform's ONE consumer identity (BazarUser + bazar_user_session) — register/sign-in at /shop/login (shop-branded verify email via source:'shop'), account hub at /shop/account; restaurant people get their shop account automatically — the same platform-bridge as Food Bazar accepts their dashboard email+password, AND an existing platform_session is recognized directly. Order/subscription attribution goes through a new getShopCustomer() seam (ui/src/lib/webshop/shop-customer.ts): platform users → their platform userId (bridged consumer logins map to linkedUserId, so it's one history either way), pure consumers → bazar:<id>; guests can buy with just contact+address. Orders now persist contact + shippingAddress and send a deterministic confirmation email (invoice/dev-sim at checkout; live card on first confirm). Orders + subscriptions pages re-styled into the shop shell; invoice page accepts both identity kinds (+ super-admin cookie). Light/dark scoped theme re-tinted to brand azure-on-navy; EN/NO/SV dictionaries cover the whole storefront.

• TV Ad Network — external advertiser self-serve platform (Phase 70). Anyone outside the platform can now advertise on opted-in restaurant TVs end-to-end: a public `/advertise` landing + magic-link portal (single-use login nonce — an emailed link dies on first use), a guided campaign wizard (hardened creative upload incl. video with magic-byte sniffing → TV-accurate live preview via the real AdSlideView → all/geo targeting → budget vs a prepaid wallet), deposits via Stripe Checkout (webhook ref-idempotent; fully functional keyless in mock), and honest ROI stats (estimated plays, spend, budget bar, per-day series, QR scan-throughs via a new counted /a/[campaignId] redirect). Super-admin moderation: a review queue on /admin/dashboard/tv-ads — nothing external serves unapproved (enforced in the engine's unit-tested serving predicate, not UI), reject-with-reason emails the advertiser, advertisers can be suspended; all decisions audit-logged. Money/isolation invariants (engine, lib/tv-ads): a restaurant's house ad is free, never settled, earns no self-credit and is hard-locked to its own screens (widened targeting is refused at write AND serve time); external spend debits the wallet atomically with budget accrual + play settlement (one row-locked mutate), clamps to both budget and wallet, auto-pauses on empty wallet. Settlement now also runs hourly via /api/cron/tv-ads-settle. Offline buffering (AD-5): the native Menu TV app gained a media3 SimpleCache read-through + board-arrival prefetch AND last-good-board persistence (an offline restart now renders the board instead of the pairing screen); the web menuboard persists its last-good board and caches ad media via a scoped service worker — a network drop keeps ads playing, and buffered offline playback is never billed (the existing cursor-gap guard).

• Food Bazar — combos are now orderable in the consumer marketplace + a real card-rail money fix. The Bazar restaurant page renders a Combos section with the full slot-picker (swap items, deal-mode "+15 kr / −5 kr" deltas, live total); the bazar cart carries combo lines and checkout sends comboSelections to the (already combo-ready) storefront order route. Money fix (also fixes the storefront): the shared Stripe `/payment-intent` route validated comboSelections but never priced them — a card order with a combo would drop the combo (undercharge / 0-total combos-only). It now expands combos + applies auto-bundles exactly like orders/route.ts (member lines excluded from bundle/coupon, signed combo net into the total, subtotal − discountAmount + fee == total), so card + combo works on storefront AND bazar — the temporary "combos = cash only" bazar gate is removed. tsc 0, full build green, 114 menu tests.

• Menu — "Deal" combos: a meal-deal price with swap-and-adjust, + AI one-click swappable combos with a generated photo (Phase 67b). A new `deal` price mode (now the recommended one) lets an owner set one price for the default combo (e.g. "Burger + fries + soda = 99") where the guest can swap an item and the price adjusts — by the item's real cost difference (auto) OR a fixed upcharge the owner sets per option (priceOverrides), their choice per alternative. The customer picker on all three surfaces (storefront, kiosk, table) shows the live deal total and a "+15 kr" / "−5 kr" delta next to each swap. The combos editor gained the deal price + a per-slot default picker + per-option upcharge inputs. The existing AI Combo Suggestion now publishes a genuinely swappable deal combo in one click (each add-on becomes a slot the guest can swap among its category siblings, server-side) via a new /combos/from-suggestion seam. The combo editor gained a photo picker (the same MediaPicker products use — upload / stock search / an image made in Experience Studio), so the owner sets the combo photo the same way as any dish — no surprise AI charge on publish. Priced by the SAME server engine as the register (expandCombo); client prices are display-only. Verified by a 3-lens adversarial money review — 3 fixes: the deal net is now floored at 0 (a negative override can't leak a discount onto the cart), expandCombo now rejects an out-of-slot swap product (was pricable), and the AI publish now writes atomically (can't clobber a concurrent order/wallet write). tsc 0 errors, full build green, 114 menu tests.

• Menu — Combos & bundles UNIFIED into one "Combos" concept, orderable everywhere (Phase 67). The platform had two overlapping, confusing entities: an explicit slot-picker ComboGroup (build-your-meal, POS-only) and an automatic MenuBundle price rule (silent cart discount). They are now one thing — a Combo has fixed and/or "pick-one" items, a fixed / amount-off / percent-off price, and an optional auto-apply toggle that reproduces the old bundle behaviour (discount a cart that already holds the items). One editor (/dashboard/menu/combos) replaces both; legacy MenuBundles migrate into combos on read (idempotent, nothing lost); the pricing engine feeds the existing, tested applyBundles from auto-apply combos so auto-apply now fires on every surface (storefront, kiosk, table/QR — previously table applied no discounts — and register). Explicit combos are now customer-orderable on all three front-ends (storefront MenuClient, KioskEngine, table OrderingScreens) via a new synthetic "Combos" section + slot-picker; the five public order routes (storefront + PayPal + Adyen + kiosk + table) accept comboSelections and re-price them server-side through the SAME engine as the POS (client prices never trusted), with combo members excluded from bundle/coupon inputs and the signed combo net applied to the total (a fixed-price combo charges its fixed price even when cheaper items are picked). Verified by a 3-lens adversarial money review (2 fixes: a kiosk cash-path discountAmount that dropped the combo saving, and a fixed-price-combo undercharge) — full next build green, 257 tests. comboName is stamped on member lines so receipts/tickets can group them.

• Menu — Product editor redesigned into a roomier, better-structured dialog. The "Edit / New Product" editor moved from a cramped 580px right-side drawer with four squeezed top tabs to a spacious centered modal (max-w-5xl, up to 800px tall) with a left section rail — each of the four sections (Basic Info, Dietary & Allergens, Options, Cost & Profit) now shows an icon, a one-line description and a live count badge, so the owner always knows where they are and what still needs input. The header gained a live product summary (thumbnail + name + price pill), each section shows a heading, and the Basic tab is grouped into titled sub-sections (Details / Pricing & category / Selling model / Visibility) with the weigh-and-pay + pre-order options as distinct cards. The wider content pane lets the allergen chips flow ~6 per row (was ~3). Fully responsive — on mobile it becomes a full-screen sheet with the rail as a horizontal scroll strip — and correct in both light and navy dark themes. Adds ESC-to-close, initial focus, focus-return and body scroll-lock. Pure presentational change: every field, handler, validation rule and save payload is identical; new copy keys fall back to English in all languages.

• Food Bazar — browse-only restaurants no longer read as "Closed" while their card says "Open Now". Two distinct states were conflated: closed by hours vs doesn't take online orders (owner toggle / entitlement). An open restaurant with ordering off showed a "Closed" pill on every menu item — contradicting the honest "Open Now" hours badge. Now browse-only mode shows NO per-item pill (the page-top "doesn't take online orders" notice explains it) and the combo picker's disabled button says "Ordering unavailable" (sv: "Beställning ej tillgänglig") instead of "Closed" — the "Closed" pill is reserved for genuinely closed-by-hours. Also fixed the item detail page ignoring the ordering toggle entirely: it computed canOrder from hours only, so on a browse-only restaurant it still offered a live "Add to cart" (server would refuse at checkout) — it now mirrors the profile exactly (entitlement/owner-toggle first, then hours with the acceptOrdersWhenClosed pre-order override, which it also previously ignored) and shows the honest browse-only notice. Verified (Playwright): browse-only → profile has 0 "Closed" pills + notice + "Open Now" intact, item page shows notice + disabled CTA; toggle on → ordering fully restored on both.

• Online ordering — the owner's on/off toggle now stays in sync between the restaurant website and Food Bazar. The online-ordering capability is one owner switch (settings.capabilities['online-ordering'], Control Center) whose live value = entitled AND owner-enabled via the shared liveCapabilitySet. The tenant storefront already read it, but the Food Bazar surfaces read the entitlement only — so an owner who turned ordering off saw it disappear on their website while Food Bazar still showed "order now" (and the reverse). Now every surface reads the SAME live capability: the Bazar restaurant profile (onlineOrderingEnabled, fail-open to match the storefront), the Bazar discovery feed's acceptingOrders badge, and — via onlineOrderingEntitlement — all five public order-creation routes (website cash/card/PayPal/Adyen + table QR), so "off" actually refuses orders everywhere, not just hides the button. Flip the toggle anywhere and the website + Food Bazar follow together. Verified end-to-end (Playwright): toggling capabilities['online-ordering'] off makes both the storefront and the Bazar profile go browse-only (0 add buttons, "Closed" pills, browse notice), and on restores ordering on both.

• Delivery platforms — incoming orders now actually reach the restaurant (were silently dropped/mis-booked). The Wolt / Uber Eats / Foodora / Deliveroo order webhooks were hand-rolling orders via db.orders.push — the exact anti-pattern the order seam warns against — so a delivery order appeared on the board but bypassed the ledger (no revenue for accounting/commission/reconciliation, breaking the cross-truth invariant), item→product mapping (kitchen station routing, recipes, stock, COGS all broke), kitchen-ticket/receipt printing, and the orderNumber lock. All 5 receivers (incl. a new GloriaFood order webhook) now route every accepted order through the locked createTenantOrder seam (born-paid settle → one paid ledger row + order.paid event, idempotent redelivery, hardware dispatch on a fresh create), map every line to a real product, and are HMAC/token fail-closed (was optional), with an indexed tenant lookup (was an O(n) all-tenant scan) and encrypted platform creds (were plaintext).

• One restaurant login now works on Food Bazar and Food Stories automatically (platform-credential bridge). A restaurant person's Restora account (master.users) previously failed with "Invalid email or password" on the Food Bazar and FSN sign-in forms — those surfaces each have their own consumer account store. Now both login routes fall back to verifying the email + password against the PLATFORM user store; on first success they provision (or adopt-by-email) a SEPARATE linked surface account — BazarUser.linkedUserId (new field) / FsnAccount.linkedUserId — per the existing ADR-FSN-identity pattern (bridge, never a merge: the marketplace session grants zero platform privileges, and the platform password is re-verified on every login, so a platform password change applies immediately). The FSN dashboard bridge (FSN-8) and the new login fallback now share ONE provisioning implementation (lib/fsn/platform-bridge.ts) with identical suspension/lifecycle semantics. Security posture: generic 401s (no platform-account-existence oracle; decoy hash equalizes timing), 2FA-enabled platform accounts are excluded (a bridge must never skip a second factor; 2FA is only mandatory for superadmins), and an FSN account protected by its OWN 2FA is never adopted via platform password. Verified end-to-end: platform creds sign into both surfaces (provision + idempotent reuse, 1 account), wrong password 401, pure consumer register/login untouched.

• Menu — category SECTION BANNERS (owner-uploadable per-category images). A category can now carry its own image (Category.imageUrl), rendered as a banner behind the section heading — the category name (+ food glyph) overlaid on the photo with a legibility scrim — on both the tenant storefront `/menu` and the Food Bazar profile (classic text mode = centered title; photo-card mode = left title + item count). Categories without an image keep the clean text header, so a menu can mix banner and plain sections. Owners set it in the menu editor: each category row in the sidebar gains an image button that opens the same MediaPicker products use (upload / stock search / an Experience-Studio image) in a modal, with a live thumbnail on the row and a one-click Remove. New shared CategoryBanner component (theme-agnostic — white overlay text works on both the tenant theme and the marketplace theme). Threaded end-to-end: Category.imageUrl in the model, GET/PATCH on /menu/categories/[id] (image validated with isSafeImageUrl; '' clears), and the shared Bazar payload. This closes the "some restaurants have category images" case. Full next build green; Playwright-verified the banner renders in both classic and card modes with plain fallback headers for image-less sections.

• Menu — photo-less menus now auto-present as an elegant CLASSIC text menu, everywhere (Food Bazar + storefront). Most real-world imported menus arrive with few or no item photos, and a photo-card grid then degrades into a wall of blank/placeholder tiles (the Food Bazar profile showed a gray fork-and-knife tile per dish). One shared decision — resolveMenuPresentation(items, menuLayout) in lib/menu/menu-style.ts (11 unit tests) — now drives every consumer surface: the owner's saved `menuLayout` always wins (photos on = cards, off = text), and with no saved layout it auto-detects from real photo coverage (below 50% of items with a usable photo → the classic printed-menu look). The classic presentation is numbered rows (auto-numbered per category even when menu-numbering is off), bold name, right-aligned/leader prices, description + ingredients, hairline dividers, and centered section headers with a food glyph (🍔 Burgers, 🥤 Drinks — via a new categoryEmoji() reusing the marketplace taxonomy). Wired into: the Food Bazar restaurant profile (RestaurantClient — new ClassicMenuRow, photo carousels/offers suppressed in text mode since offer prices show inline; ordering add/qty controls preserved via an extracted shared BazarCartControl), the Bazar item-detail imageless hero (branded "carte" panel with the dish glyph + name instead of a bare placeholder), and the tenant storefront `/menu` (MenuClient — same engine, tenant's own brand/theme). Each surface keeps its own design language (marketplace tokens vs the tenant theme) — one decision engine, per-surface rendering. The owner "items missing photos" nudge now softens to reassurance when the menu is already presented as a clean text menu. menuLayout is threaded through the shared Bazar payload for the owner-override. tsc 0 errors; verified end-to-end (Playwright) on a photo-less tenant → classic on both Bazar and storefront, and photos-restored → photo cards return (no regression), desktop + mobile.

• Swedish kassaregister — certified control-unit adapter + fiscal receipt wired into settlement (R360-C01 + R360-C02, keys-only). A REAL certified CLOUD control-unit (kontrollenhet) adapter (CloudControlUnit, e.g. fiskaly SIGN SE) now implements the existing ControlUnit interface — bearer-auth HTTPS signing of each receipt over the mandated fields, registered via the same adapter/registry pattern as the accounting providers (registerControlUnitAdapter / resolveControlUnit). It fails safe to the deterministic local sandbox stub (certified:false) whenever creds / liveReady are absent, so a receipt can never masquerade as a legal registration; go-live = the certified unit's creds + liveReady. recordFiscalSale is now wired into the order settlement path (createTenantOrder born-paid + finalizeSeamCharge capture): every paid Swedish sale is recorded exactly once (idempotent per order, POST-COMMIT / best-effort — never blocks or throws into the order mutation), the monotonic per-register counter (receipt number + grand total) is advanced under the row lock (gapless numbering), and the immutable journal is DERIVED from the orders (no unbounded array). Adds X-report (running) + Z-report (daily close, monotonic Z-number + period boundary persisted under lock), a fiscal status panel on the compliance dashboard (mode mock/live, control-unit serial, counter, last Z, X/Z buttons), and a GET/POST /api/tenant/[tenantId]/fiscal route. ALL fiscal math is deterministic — never an LLM. XML journal export reused as-is. 18 injected-dep unit tests (control-code determinism, counter monotonicity, idempotent record-once, X/Z aggregation + period boundary). ⚠ The cloud unit's exact API envelope + XSD are UNTESTED until certification/creds land (like a keys-only rail); sandbox receipts are compliant drafts, not legally valid until a certified unit signs.

• B2B supplier payout reconciliation sweep (R360-H70, keys-only). The supplier charge + delivery-time payout halves already move real money, but a payout stuck pending (supplier not yet Connect-onboarded at delivery) or failed (a transient transfer error) had no way to complete. New daily supplier-payout-reconcile cron scans delivered orders and safely RETRIES pending/failed payouts through the same idempotent settleDeliveryPayout path (Stripe idempotencyKey: payout_<orderId> → a retry racing a real transfer returns the original, never double-pays). Terminal states (paid, simulated) are never retried; failed retries are capped (MAX_PAYOUT_RETRY_ATTEMPTS). It also reports charge↔payout mismatches (a supplier paid out with no real restaurant charge behind it, or a really-charged order whose supplier is still unpaid) for operator attention — never inventing or reversing a money movement. With no Stripe rail configured it is an honest no-op. Registered in PLATFORM_CRON_JOBS + vercel.json (fail-closed CRON_SECRET gate); 10 injected-dep unit tests.

• Delivery platforms — outbound to the aggregators (real, keys-only): real menu / item-availability (86) / store open-closed push OUT and order status callbacks (accept / reject / ready) — Uber Eats fully real (OAuth + Menu/Store/Order APIs), Deliveroo real order-side, others real where their partner docs permit, all with honest mock-fallback when creds are absent. GloriaFood is now a first-class tenant-bound connectable platform (per-tenant encrypted push token — the routing key is no longer spoofable across tenants). Verified by a 3-lens adversarial review (4 HIGH findings — GloriaFood dead-routing + a cross-tenant auth spoof + two reject-enum 400s — all fixed + pinned). Go-live = each aggregator's partner-program credentials + certification (GloriaFood needs none — just paste the webhook URL + token).

• Accounting Integration Platform — finished the Phase-50 engine to production-real, keys-only. The universal provider-agnostic engine already shipped (Phase 50, BK-0…11); this closes it to a genuine Sweden-first go-live where the only remaining gates are credentials + sandbox verification + the flag flip — no more code.

- Real expense + journal-entry push (BK-9) on Fortnox + Visma (previously unsupported): supplier-invoices + vouchers via their real APIs, supplier ensured search-first, balanced double-entry validated before any POST, idempotent via the external-id ledger + a deterministic externalRef marker. - Two new complete real adapters — Xero + QuickBooks Online (2 → 4 real providers): the full AccountingProviderAdapter (company/accounts/VAT-codes/fiscal-years, customer upsert, invoice, credit-note, payment, journal, expense) against each provider's Accounting API, with their native idempotency headers (Xero Idempotency-Key, QBO RequestId), honest error classification, OAuth-bearer + tenant/realm scoping — mock-fallback preserved when creds are absent (isProviderMockMode). - Inbound provider webhooks: real HMAC signature verification (fail-closed, timing-safe, raw-body), the Xero intent-validation handshake, idempotent by event id, their own isolated inbound store; an unconfigured provider honestly 503s rather than process an unverified body. - Reconciliation report (BK-11): provider-posted (external-id ledger) vs local books per document type — drift / orphan / dead-letter classification, honest — where a provider figure can't be read, surfaced on the accounting sync page. - Mixed-rate VAT: per-line 12% + 25% on one bill via an additive optional Product.vatCategory (menu-editor set) — resolving to dated Phase-19 rates per channel. Strictly additive: an uncategorized order renders byte-identical to before; a review-caught tax bug (categorized additive catering/table-bills mis-taxed) was fixed so mixed-rate applies only to VAT-inclusive orders and nets order-level discounts. - Verified by a 3-lens adversarial money review (5 findings — a HIGH VAT-compliance bug + a customer-mislink idempotency collision — all fixed + regression-pinned). 402 accounting/bookkeeping/VAT tests green, full next build green. Go-live gates (sandbox verification against real Fortnox/Visma/Xero/QBO test companies, per-country legal consent, the flag flip) are documented, keys-only.

• Growth Command Center BI — finished to 100% (real data or an honest "—", never a fabricated number). The super-admin /admin/growth dashboard was already mostly real; this wires every remaining panel to a real source and retires what has none.

- Killed the one null-honesty violation: the "Direct Joins" module rendered seed panels (fake restaurant names / "199 kr") under live:true, suppressing the sample flag — a super-admin saw fabricated data as real. Now built from real direct-channel tenants (joins-by-source from acquisition.utmSource/referrerHost, plan mix from subscriptions, recent joins with real first-invoice amounts), or honestly SampleNote when there are none. - Now real from existing sources: channel CAC/ROI from real sales-agent + web-designer commission ledgers (per-channel; every channel without a real platform-acquisition cost stays — — tenant sponsored-ad spend is deliberately excluded because it isn't platform acquisition cost); leaderboards (top agents by attributed MRR/deals, top designers by sites-live); the industry drill (grouped by businessType); the country drill (from explicit billing/registrant country or an unambiguous currency→country map — EUR/USD never inferred, self-retires to sample below coverage); the executive briefing + advisor cards (deterministic, every claim citing a real number — no LLM); the MRR forecast (from the real trailing-trend slope, replacing hardcoded projection %). - Retired the fake: the Waste & Recycling module had no data source and none planned → removed from the nav rather than ship a permanently-representative module. The decorative "Last 30 days" pill (nothing was date-windowed) was removed rather than fake a filter. - CSV export now covers the funnel, forecast, leaderboards and module panels, each tagged with a source (live | sample) column so an export can never present seed as real. Phase-62 Marketing module + all its hooks preserved.

• Swedish receipt & invoice set — closed to 1:1 with the design handoff. The Kvitto, Faktura and Leveranskvitto were already ~85–90% implemented in prior sessions; this closes the remaining gaps against the reference, verified by a headless screenshot-compare per the 1:1 rule (which also caught two real correctness bugs — see Fixed).

- Kvitto (thermal receipt): the hosted receipt + PDF + email now render itemized lines (name, á-pris sub-line when qty>1, option sub-lines), the Kassa/Kassör/Bong register row, and the Terminal/AID/Ref/TVR card-acquirer trace + website footer — all additive and honesty-guarded: fields render only when the terminal actually reports them (items persist only when they sum exactly to the recorded total), never invented server-side; older terminals get byte-identical lump-sum receipts. - Faktura (A4 invoice): the shared InvoiceModel + both renderers (screen + PDF, used by sale/catering/canteen/webshop) gained the "Avser:" subject line, Kundnummer, a seller tagline, the "Sida 1 (1)" footer, and the Swish payment rail — a green Swish label + Swish-nummer row + a fixed-amount locked Swish QR (the design's C-format payload), preferred over the bank-app QR when the tenant has Swish, coexisting with the Bankgiro/OCR rows. - Leveranskvitto (delivery slip): it rendered 1:1 but nothing linked to it — added a "Leveranskvitto" link on the dashboard orders history (delivery/pickup only) and a real 32-col ESC/POS delivery-slip print job (delivery-slip device-job kind), preserving the name-only privacy projection (no address/phone/portkod on the slip).

• Invoice VAT-inclusive rounding (surfaced by the 1:1 compare): storefront orders whose total already includes moms rendered Netto = gross and an impossible Öresavrundning −50,00; buildSalesReceipt now detects additive-vs-inclusive VAT by which yields a plausible öresavrundning (±0,50), so inclusive orders show the correct Netto/Moms/rounding and every existing golden fixture stays byte-identical.
• Swish number formatting on receipts + invoices — bare 10-digit numbers now display design-grouped (123 456 78 90), owner-typed formatting preserved, WinAnsi-safe.

• Adyen rail — the money core completed (Group A): refund confirmation, double-refund fix, webhook hardening, webhook-miss reconcile.

- G1 — refund confirmation: /api/adyen/webhook now handles REFUND / REFUND_FAILED (it previously dropped everything but AUTHORISATION). The pending refund row the refund route posts is matched by documented precedence (refund pspReference → ledger idempotency key from our minted refund:{tenantId}:{key} merchantReference → originalReference+amount fallback) and flipped by the new finalizeRefundRow (once-only, never downgrades — mirrors finalizeLedgerCharge). A late REFUND_FAILED after a confirmed refund is audited, never auto-reversed. - A2 — credit-note timing: the BK-7 credit note is now issued when the refund CONFIRMS. Split by row status, not provider: sync rails ('refunded' rows — mock/gift/immediate) keep today's same-lock behavior byte-identical; async rails ('pending' — Adyen) defer to the confirmation flip via the new confirmAsyncRefund chokepoint (lib/payments/refund-confirm.ts), reusing the exact same recordCreditNoteForRefund path (idempotent by ledger-entry id). - C1 — double-refund guard (real money bug): the refund route's remaining-math now counts PENDING refunds conservatively (refundAvailability); a second click while one is in flight gets an honest 409, and a REFUND_FAILED flip frees the amount again. The refund idempotency key now defaults DETERMINISTIC (refund:{chargeId}:{amountMinor}, :rN past failed attempts) instead of a fresh UUID per request — identical retries dedupe in the ledger AND share the Adyen Idempotency-Key, so a double-click can never mint a second real refund. Explicit client refs still win. - Webhook hardening: merchantAccountCode must match the configured account (C4, fail-closed behind the HMAC); the order branch books what Adyen actually captured but flips the order paid ONLY when the total is covered (isFullySettled — C2, partials are logged + left pending, never over-credited); CAPTURE finalizes identically to AUTHORISATION keyed by the payment's pspReference (delayed-capture accounts confirm; auto-capture redelivery = no-op; failed captures audited); CANCELLATION releases pending seam rows honestly (paid-then-cancelled is audited for a human); CHARGEBACK flags the charge row (disputed — additive field) + audit log so disputes are VISIBLE (full dispute/defense flow = documented future item). Per-item try/catch + the [accepted] contract preserved. - G6 — webhook-miss reconcile for orders: the adyen-order route now stamps Order.adyenPaymentLinkId, and the customer's post-payment status polls (/api/bazar/track/[orderId] — the Adyen returnUrl landing — and the session-gated /api/bazar/orders/[orderId]) re-query the payment link once when the order is still pending, finalizing through the SAME creditAdyenOrderPayment path the webhook uses (one finalizer; a later webhook upgrades the row's providerRef to the refund-capable pspReference, never a second row). Mirrors the shipped gift-card fallback. - Verified: 29 new unit tests (ledger.test.ts, refund-confirm.test.ts, adyen/notifications.test.ts, adyen/order-credit.test.ts) with Adyen-doc-shaped fixtures; full payments suite 81/81; tsc --noEmit clean.

• Payments — tenant Adyen toggle in Setup Center (Adyen rail, group C). The owner's Settings → Payments tab gains an Adyen card matching the Stripe/PayPal/Swish idiom: it toggles paymentSettings.adyenEnabled (the per-tenant opt-in the checkout + gift-card buy pages already gate on) via the existing settings PATCH. The switch is honest about platform state: a new tenant-scoped GET /api/tenant/[tenantId]/payments/adyen-availability returns a secret-free { available, environment } projection of the platform rail (projectAdyenAvailability, no-leak contract enforced by availability.test.ts), and when the platform rail is off the toggle renders locked with "Not yet enabled on the platform" instead of a dead switch that would silently no-op at checkout. Test-mode rails surface an amber "Test mode" badge + sandbox-only copy; live shows a green "Live" badge. Fail-closed on fetch errors; both dashboard themes; 320px-safe.

• Adyen go-live console (super-admin, Phase 65 PAY-RAILS Group B). New RestoraPayAdyen panel on /admin/restora-pay (the existing rails console, already in the sidebar): honest rail-state banner surfacing resolveAdyenRailMode's mode + reason, redacted credential display (API-key last-4 / HMAC-set flag — secrets are write-only, never echoed), rotate forms for API key + HMAC key, merchant-account + live-URL-prefix inputs, a Test/Live environment selector with an unmissable "LIVE = real money" warning and a confirmDialog(danger) guard on any save that sets environment:'live' or enables the rail in live, the effective Checkout API base for operator sanity-checks, and a 6-step go-live checklist. GET /api/admin/adyen/settings extended additively with railMode / railReason / checkoutBase. Money-guard + checklist logic extracted pure and unit-tested (adyen-console.test.ts, 8 tests).

• Phase 62 — AI Marketing Autopilot (MK-0 … MK-12): configure once → AI drafts, owner approves, honest ROI. A new per-tenant (and platform) marketing pillar that generalizes the shipped social autopilot rather than forking it: a deterministic planner ranks what to do across channels from the tenant's own data, an LLM only narrates copy (RIC-routed, one-wallet-metered, honesty-fenced), and everything runs under an owner-set approval mode (manual drafts · semi-auto low-risk auto + an approvals inbox · automatic within guardrails). Ships flag-OFF, mock-first, go-live = keys only (no second dev round).

- The engine + Hub: a Brain (TenantDB.marketing) + a sense→plan→generate→gate→execute→learn orchestrator, surfaced as tabs on /dashboard/marketing (Command · Plan · Approvals · Learning · Analytics · Budget). An event→rule automation bus (lifecycle / weather / low-sales triggers, cloned from the accounting-sync dispatcher) and a unified CRM view + deterministic segments over the 5 fragmented customer stores. - Channels: organic social, email (with real open/click/unsubscribe tracking — fills the previously-empty CampaignAnalytics), consent-gated SMS + push, Google Business posts + AI review replies, VSO/VEO/EEO structured data. - Measurement: the order→campaign attribution link (a signed, consent-gated first-party carry → Order.campaignTag → the growth spine) makes ROAS/CAC real instead of —, and closes the learning loop back into the scorer. - Real go-live rails (built 100%, gated): complete Meta Marketing API v25.0 / Google Ads v24 / TikTok Business v1.3 ad clients + GA4 / Search Console ingestion, real per-provider OAuth, an encrypted connections vault (reuses the existing token key), a real budget engine (ad money kept strictly off the AI wallet) and a real social-publish bridge to the live FSN publisher — each serves an honest in-memory mock until its credentials + a live connection resolve. Owner-gated behind marketing_paid_ads / marketing_live_publish. - Verified: ~700 unit tests, full next build, and a 5-lens adversarial review (10 findings, all fixed). Docs: docs/products/marketing-autopilot/go-live-runbook.md.

• Reliability — cron-drift remediation (shipped alongside Phase 62). The self-hosted prod box only ever fired ~15 of 52 cron routes (vercel.json is inert under pm2); PLATFORM_CRON_JOBS is now the single source of truth (15 → 45), reviving ~24 silently-dead jobs (incl. the Phase-66 workforce crons + order-rollup that ran nowhere), with a cron-registry.test.ts drift guard so a cron can never merge unregistered again, heartbeats + a Guardian staleness alarm, and two real billing bugs fixed (restora-pay minimum-fee / swish-fees day-1 under-billing).

• RIC consolidation: the blog/assistant, citation-hub AI-draft, and SEO copy generators now route through the RIC gateway (the SEO "Generate with AI" buttons are genuinely AI now, with the deterministic templates as the honest fallback) — zero behaviour change while RIC is off.

• Seller mode — a real tool for a person on a bike, not a trimmed restaurant dashboard. The lite shell now stops handing a solo mobile seller (cart / cycle / on-foot vendor who IS the cook, cashier and server) surfaces built for a multi-person venue. Kitchen Display and Customer Display became opt-in features (kitchen-display / customer-display, basic-tier so every existing multi-station tenant keeps them — zero regression — and add-on-purchasable so a food truck with a real second screen can switch them on); the Orders-page display tabs and the /dashboard/kds route are now gated on them, so a seller with no second screen sees a clean orders list and no "Connect a screen". The seller nav is rebuilt around the actual loop — Sell · Orders · Menu · Money · Where am I today · Get discovered · QR code · Gift Cards · Reviews · Billing · Setup · Help — with seller framing (no "Take Order (Waiter)", no tables/seats/courses), landing on the new Sell counter instead of a restaurant overview.

• Services directory redesign — imagery + a platform-aware app-download showcase (`/services`). The flat icon grid becomes a full marketing surface: an editorial hero with a live laptop + POS-phone dashboard mock, a new "Download the apps" showcase (flagship Owner card + a per-role app grid), an enriched searchable directory, and an ambient "every device" CTA band over real food photography.

- App→platform accuracy: every app shows App Store / Google Play / Windows badges only for the platforms it actually ships on, driven by a NATIVE_APPS registry cross-checked against android/settings.gradle.kts, the iOS/ apps and the Tauri Restora360 Station (e.g. FSN = iOS + Android, no Windows; Kitchen Display = Android + Windows; Menu TV / Atmosphere / Staff = Android-only). Windows apps are labelled as running inside the Station shell. - Mockup download links: no public store listings exist yet, so badges preview each app and open its live web surface today — centralised so go-live is a one-line swap to the real App Store / Play / Station installer URLs. - Directory: services carry per-app platform glyphs inline and a platform-correct "Get app" reveal; the auth-gated "Worker shift client" entry corrected to login-required. - Scoped to the .r360-landing azure-on-navy theme (no new tokens); a11y-reviewed (filter aria-pressed, polite results live-region, AA-contrast tag fix). Verified: TypeScript clean; live render 200 with zero horizontal overflow at 390 px and 1280 px.

• Wave 0 — the unified payment layer: go-live is now KEYS ONLY. The lib/payments seam (the choke point every POS settle, deposit, top-up, table-pay and bar flow already calls) finally has real rails behind it — the registry that sat empty since Phase 33 now resolves per-rail bridges built on the existing production-grade code:

- Per-rail three-state mode (disabled | test | live, lib/payments/provider-mode.ts) derived purely from credential presence + the explicit switches: a Stripe sk_test_ key or the Swish MSS cert or Adyen test env = test (real sandbox round-trips, mock:true rows, exercisable end-to-end with zero risk); live keys + the restora_pay flag + the mode switches = live. Matrix-tested; a super-admin entering keys flips a rail with no deploy. GET /api/admin/payments/rails is the live readout with honest per-rail reasons. - Three provider bridges (lib/payments/providers/): Stripe Connect (direct charges on the tenant's Express account with the clean application_fee cut, pending+clientSecret results), Swish (mTLS client, deterministic retry-safe 32-hex instruction ids, e-commerce push via payerPhone or swish:// app link, brief settle-poll), Adyen (hosted Pay-by-Link + HMAC webhook). Plus the honest external-tender recorder: cash / external-terminal card / gift rows become real money rows (mock:false) once restora_pay is ON. - Real holds: authorizePayment / captureHeldPayment / voidHeldPayment (Stripe manual-capture PaymentIntents) with a mock fallback so every flow works in every mode. - Pending→final plumbing: finalizeSeamCharge (split-bill-aware, idempotent, BK-5 events) driven by all three confirmation channels — the Swish callback (ledgerKey pending records), the Stripe connect-webhook (metadata.seam='payments', incl. amount_capturable_updated hold confirmation), and the Adyen webhook (ledger: references). POS settle now answers 202 awaiting approval with the Swish app link / Stripe client secret instead of pretending an instant settle. - PAYMENTS_MODE=mock stays the global kill switch; =live = strict fail-loud (never silently mock-settle). Ledger rows carry mode: 'mock' | 'test' | 'live'.

• Wave 1 — deposits ride the real rail. Reservation deposits and pickup-slot deposits (previously mark-only: no charge, no ledger row, no refund) now capture through the unified seam (reservation-deposit: / slot-deposit: idempotency-key families with never-double-charge retry minting), post honest ledger rows, and refund on cancel/refund actions against the recorded paid charge (over-refund capped). Catering deposit/balance and bar settle were verified already-wired. Legacy mark-only records keep their exact old behavior.
• Wave 1 — bar tab pre-auth is a real card hold. Tab open places a genuine hold (authorize → guest confirms card → webhook flips pending → held), card settle captures the hold (remainder auto-releases), void/close releases it at the provider. Mock holds keep today's flow byte-for-byte; replaced/orphaned holds are voided, never stranded.
• Wave 1 — production ESC/POS receipts: the ` MOCK PRINT ` stamp is dead. lib/devices/render.ts now emits the byte-accurate Swedish Kvitto layout (styled ESC/POS: emphasized store header, org/moms numbers, wrapped item lines with options, gift-tender rows, back-derived VAT table, ATT BETALA double-height, sv payment labels, CP865 åäöÅÄÖ) through the EXISTING Windows Station transport — no station rebuild needed. Preview mode (*** FÖRHANDSVISNING ***) renders the same layout whenever no agent has claimed the printer; preview defaults ON so an un-updated caller can never accidentally print a clean receipt.
• Wave 2 — canteen seams closed. (1) The daypart productIds allow-list now actually switches the menu (kiosk feed filters products + drops emptied categories within one poll; the POS and kiosk order writes 409 out-of-window items server-side) with a per-daypart product picker in the canteen admin. (2) The self-order kiosk accepts the canteen wallet/subsidy tender (badge-code keypad in the cart, same one-lock debit path as POS — factored into shared lib/canteen/tender.ts, default ON with canteen, explicit kioskWalletTender:false opt-out). (3) Canteen card/Swish top-ups ride the unified seam: with real rails the wallet credits ONLY when the money is confirmed (a source-keyed finalize hook), never on initiation.
• Wave 2 — Seller plan + true LITE dashboard. The 99 SEK street-food-starter plan gets a curated street-food-sized feature set (was: the full basic cockpit), Stripe price wiring (STRIPE_PRICE_SELLER), billing-page bullets, and a one-click Restore & publish in the Pricing Studio (ships archived/CLOSED until then). Plans can declare uiMode:'lite' → tenants on such a plan get a genuinely simplified shell: flat 11-entry sidebar, no group headers, ~52px touch rows, /dashboard lands on order-taking. Same routes, deep links intact, absent signal = byte-identical full shell.

• Wave 2 — Guest at-table QR ordering (scan → browse → cart → KDS → pay from the table). The table QR (/t/[tenantId]/[tableSlug]) grows a full guest ordering flow, default OFF per tenant (settings.tableOrdering.enabled, editable via the standard settings PATCH) and additionally gated by the master ita_enabled flag, the per-tenant ita.enabled opt-out and the online-ordering entitlement — with the gate off the QR page is byte-identical to the pay-only surface it was.

- Order create: new public POST /api/public/[tenantId]/tables/[tableSlug]/order — HMAC guest token pinned to tenant AND tableSlug (a token minted for one table can never fire to another), rate-limited, demo-blocked, entitlement- and closed-hours-guarded, server-side re-priced (verbatim port of the online-order loop incl. multi-locale option resolution + stock/86 gates, shared as pure lib/tables/table-ordering.ts), created through the locked seam (createTenantOrder) as type:'dine-in' + tableId/tableNumber + new source:'qr', born pending, idempotent by clientRequestId. Lands on the KDS/orders board exactly like a waiter dine-in ticket (the table badge already renders). - Pay from the table: new public POST …/order/[orderId]/pay through the unified payment seam (capturePayment → postChargeToLedger, source:'table-qr') — mock settles instantly; Stripe rails return clientSecret (confirmed on the guest's phone, webhook finalizes); Swish returns the swish:// deep link (callback finalizes). Stable idempotency key with deterministic retry-after-recorded-decline. Pay-later remains first-class via the existing staff-built bill QR flow. - Guest UI: Menu / Cart / Your-orders screens inside the existing ITA PWA (320px-first, azure, en+sv via the ITA i18n table), option bottom-sheet honoring radio/checkbox + min/max, sessionStorage cart per table, live status via the existing token-gated /api/bazar/track/[orderId] at the 5s cadence. - Menu projection: GET /api/public/[tenantId]/ita/menu additively gains price/description/imageUrl/available/localized optionGroups + ordering:true/currency — ONLY when the tenant gate is on; otherwise byte-identical (still unpriced). - QA: 10 new node:test units (binding, gate, re-pricing, schemas); end-to-end mock run on the dev server (order fired → dine-in ticket with table binding on disk → track → mock pay → paid flip + ledger row + order.paid outbox; idempotent replay / cross-table rejection / gate-off regression / closed-hours guard all verified) + 320px Playwright screenshots of every screen.

• Phase 60 — KDS 2.0, the world-class kitchen display (waves KDS-0…10 + TV parity, delivered in one go). The kitchen board grows enterprise-grade workflow while staying exactly as simple as before by default — every new capability is opt-in and OFF at factory settings, and the order engine is untouched (bumps still ride the existing order PATCH + offline outbox; course-fire unchanged).

- Settings (KDS-0): gear icon → a touch-first Kitchen Display Settings modal (Appearance / Workflow / Order display / Behavior / Sorting & station), persisted per device (kds-settings:v1:{tenant}, migrates the old kds-sound key). Reset = today's board, exactly. - Themes (KDS-1): Dark (default — the familiar look, polished) / Light / Auto + a high-contrast option, implemented as a scoped CSS-variable layer so the KDS keeps its own switch independent of the dashboard theme. Font size S/M/L/XL scales the whole board; compact mode for busy screens. - Card redesign (KDS-2): bigger numbers and timers (readable at 2–5 m), 4-step priority (On time · Waiting · Late · Critical — always icon + label + color, color-blind safe), order-type + delivery-channel badges, table numbers, every line toggleable. - Cooks & claims (KDS-3): tap-your-name cook bar (Phase-38 roster + ad-hoc names) and advisory, non-blocking "I'm on it" claims with avatar chips. - Item progress (KDS-4): large per-item check targets, quantity-aware (3× counts 1/3 → 2/3 → ✓); Auto Complete bumps the order through the REAL lane transition when the last item is checked; held course items can't be checked (pacing wins). - Assignment (KDS-5) + vocabulary (KDS-6): per-item cook assignment with initials dots, and one shared icon+label status chip set (Waiting/Working/Ready/Served/Done/Cancelled/Hold/Fired) used across web and TV. - Undo & Recall (KDS-7/9): every bump/check/claim/assignment gets a 15 s themed Undo toast (offline-safe — inverse ops share the same outbox dedupe keys); Recall brings back the last bumped tickets; bulk Complete-all-ready and Clear-done; Print ticket re-enqueues through the RW-3 kitchen-printer pipeline (hidden when no printer). - Filters, sorting & stations (KDS-8): one-tap filter chips (All/Mine/Pending/Working/Delivery/Takeaway/Dine-in), six sort modes with an Auto Sort toggle (positions freeze when off), and per-device station pinning ("grill screen") with an n more items at other stations context hint. - Performance & a11y (KDS-10): the old whole-board 1 Hz re-render is gone (leaf <TicketAge> timers + bucket-only priority updates + memoized cards), the feed short-circuits on a contentHash, long lanes window their rendering behind an IntersectionObserver sentinel, number keys 1-9 bump the Nth Ready ticket (bump-bar friendly), U = undo, aria-live new-order announcements, reduced-motion honored. - TV parity (KDS-11): the read-only /tv/screen kitchen board shows claims, item check marks and assignee dots — additive feed fields, rendered only when the tenant uses them. - Data & API: additive-only OrderItem.kdsState/kdsDoneCount/kdsCompletedAt/kdsAssignee + Order.kdsClaims; new idempotent POST /kds/actions op channel (absolute values, outbox-replay safe). POS, waiter, storefront, Kanban and tracking are untouched. - QA (all gates green): 8 new unit tests (settings merge, quantity cycle, hold blocking, undo stack, recall pool); a 44-assertion live Playwright gate — zero-regression at factory settings (real bump PATCH, real course fire), the full feature matrix (claims/checks/assign/undo/auto-complete/filters/station/bulk/recall/print-gating) against the live board, theme × contrast × font screenshot pass, and scale 5/40/200×6 (board interactive ~3 s, windowed DOM 120→180 on scroll, p95 scroll frame 18 ms, zero page errors).

• No more native browser dialogs — anywhere (repeated owner request, now a guarded platform rule). Every window.confirm / alert / prompt on every surface (owner dashboard, super-admin, agent/designer/supplier portals, order tracker, Food Bazar, Mason, FSN, invoice pages) — 85 call sites across 73 files — now uses the themed in-app dialogs, which follow Light/Dark mode and never show the browser's "restora-server… says" chrome. The shared component grew alertDialog (single-OK notices) and promptDialog (text input, same string | null contract as window.prompt) beside the existing confirmDialog; destructive confirmations get a red action button and a proper verb ("Delete", "Revoke", "Unpair", …). A new guard test (no-native-dialogs.test.ts) scans the whole source tree and fails the suite on any future native dialog call — the rule can't silently regress again.
• Test suite fully green again — both long-standing red tests fixed. intelligence/import-guard: the Learning Ledger no longer imports the raw Intelligence Store accessor; it reads its one aggregate through a new sanctioned seam (lib/intelligence/ledger-stats.ts → rieEventCount()), keeping RIE isolation mechanical. dark-vocabulary: the three flagged pale hexes are genuinely fixed surfaces (TV-canvas selection handles + default TV text color, the TV style-tile mini-preview, and the transparency checkerboard behind background-removed PNGs) — allow-listed with documented reasons per the test's own convention. Also fixed 4 pre-existing lint errors in touched files (a local helper named useImage tripping rules-of-hooks, unescaped JSX entities).

• Phase 61 follow-ups IA-2b · IA-3b · IA-3c · IA-5b — the four parked Navigation-2.0 follow-ups, all delivered.

- IA-3b — Mason Menu tab reaches parity with the retired Navigation Builder, and `showCartButton` finally has a renderer. Every top-level navbar link in the Navbar editor's Menu tab now has three per-surface visibility toggles (Desktop/Mobile/Footer) and a badge picker (None/New/Hot/Promo) — the exact fields sanitizeNavItems always round-tripped but no UI exposed. A "Cart icon" card toggles navConfig.showCartButton, which was dead config end-to-end: there is now a real header cart icon (HeaderCartLink, live item count from the layout-wide cart, links to the menu page) rendered by BOTH the legacy SiteHeader and the themed SiteNavbar, gated on the Online-ordering capability like every other ordering surface. SiteNavbar also renders link badges now (they were mobile-only before), the Mason header preview mirrors desktop visibility + badges + the cart icon (WYSIWYG), and reconcileNavItems no longer strips badge/visibility from nested child links on every save. - IA-2b — new QR screen pairings create per-device records; fielded TVs untouched. "Connect a screen" codes are now minted as PRE-AUTHORIZED TvDevice links (POST tv-devices/preauth), and both TV-side flows — typing/scanning the dashboard code (/api/public/tv/pair) and scan-to-connect from the TV (live-orders/tv-link + tv/link/[deviceId]) — create a real TvDevice (customer-display mode) at pairing time, so every NEW screen shows up in the Hardware Center fleet with name, online heartbeat, theme override, remote commands and per-device revoke. The /tv page stores the device identity and boots the full /tv/screen experience. Transition-safe by design: the shared liveOrdersDisplayToken, its rotate/disable card, the /display page and every fielded TV's stored token are untouched (NEVER auto-rotated); the live-orders display feed additionally accepts active customer-mode device tokens (with heartbeat), so even a TV still running cached pre-deploy /tv JS pairs into a working, revocable screen. Owner UAT left: one real-TV re-pair (documented in TODO). - IA-3c — approved WoW-clone theme snapshots feed the Mason theme gallery. Approved snapshots (reviewStatus === 'approved', super-admin review is the curation gate) surface as skin-only standard packages in the unified catalog — colors/font/header/menu-style only, tenant content untouched — riding the normal install pipeline (rollback snapshot, undo, themePackageFlags disable). ThemeVariant gained menuStyle so the snapshot's menu presentation applies like the retired /dashboard/themes page did. Pipeline is dormant until the WoW funnel goes live (zero approved snapshots exist), so the gallery is unchanged today. - IA-5b — Help Center "Learn more" tab (the gate finally passed). The Academy (/learn/academy, Phase 15 role tracks + certifications + progress API) and Community forum (/community) turn out to be REAL, working surfaces — the IA-5 "don't exist yet" premise was stale. New 5th Help Center tab with outbound cards (Academy, Certifications, Certified directory, Community; new-tab, since they're public pages), tabLearn label translated in all 20 languages, "Academy/Community/Learn" added to sidebar-search keywords. Bundled fixes: /learn + /community (+ their APIs) added to the proxy BYPASS_PREFIXES so they resolve from dashboards on TENANT hosts (same class as the IA-3 /studio 404), the /learn header is session-aware ("Open dashboard →" for signed-in owners instead of the pre-launch launch-list pitch), and the Academy CTA's stray non-azure hover was re-azured. - QA: tsc 0 · eslint 0 errors · nav guards 10/10 · theme-package tests 35/35 · pairing tests 62/62 · full suite 4498 pass (2 pre-existing known reds only) · live E2E on dev: full IA-2b pairing lifecycle (mint → exchange → fleet online → revoke kills both auth paths), builder GET/save showCartButton round-trip, storefront cart icon SSR, Learn tab + Academy/Community 200 on tenant hosts.

• Phase 61 IA-7 — Navigation 2.0 is now the default and only owner nav (the `nav_v2` flag is retired). After the full IA-0…IA-6 build + owner UAT, the job-based sidebar (5 daily primaries + workspaces + utility zones) is promoted to the one canonical catalog. The nav_v2 feature flag, its super-admin master-switch API, the per-request flag read in the dashboard layout, the navV2 thread through TenantProvider/sidebar/search/Quick-Links, and the one-time "navigation got simpler" intro card are all removed — no behavior is gated any more, so there is nothing to flip. Route resolution is preserved: the 19 hub-linked tools (the /studio designers + the Marketing Hub toolset) that used to resolve only via the legacy catalog now carry their own metadata in a HUB_LINKED_ITEMS list folded into ALL_NAV_ITEMS, so Quick-Links stars, bookmark validation and search keep working — including the exact-beats-prefix case (/dashboard/settings/google is not shadowed by the Setup Center /dashboard/settings prefix). Guards reworked to single-catalog invariants (10/10); the nav sweep no longer flips a flag. tsc 0, lint 0 errors, suite green. Everything still lives at the same URLs; absorbed routes still redirect.
• Nav polish (owner makeover) — Marketing Hub & Experience Studio are single sidebar links, and the Marketing Hub cards now describe themselves. In the Navigation 2.0 sidebar, a group with exactly one destination (Marketing Hub, Experience Studio — and Help Center, same shape) now renders as a flat link instead of a dropdown: click it and you land straight on the hub. The Marketing Hub's individual tools (Offers, Loyalty, Email, Social, SEO, Reviews, …) are pulled OUT of the sidebar — they live as cards on /dashboard/marketing, which is the one place that "says everything." Those routes stay fully live and searchable (generalized HUB_LINKED_TOOLS registry + keywords; findNavItem now prefers an exact match in either catalog over a broad prefix, so /dashboard/settings/google still resolves). The Marketing Hub cards gained a one-line description each (matching the Experience Studio tiles) and translated labels. tsc 0; nav guards 11/11 (the "nothing removed" + "hub-linked tools stay live and linked" invariants now cover both hubs); suite green.

• Help Center + Overview 2.0 (Phase 61 IA-5 + IA-6) — one help home, and a dashboard that answers "what needs me now". IA-5: /dashboard/help is the Help Center with four tabs — Guides (the 32-article browser, default; also fixes the latent ?q= deep-link bug), Ask Restora (the Phase-18 Support Brain; escalating now lands you on your new ticket), Tickets (the full ticket system, re-housed verbatim), and What's New (recent release notes rendered in-dashboard by the same parseChangelog() the public /docs/changelog uses — [Unreleased] filtered out, QA footers stripped, English-only noted). /dashboard/support is a redirect stub into the Tickets tab; the attention-bar "Support team replied" CTA and the header help dropdown point straight at it. The spec's "Learn more (Academy/Community)" tab is deliberately deferred (IA-5b) — those products don't exist yet, and dead links help nobody. IA-6: the Overview's Operations Center gets a curated default of FOUR widgets — Live Orders · Upcoming Bookings · Needs Attention (new: merged, severity-ranked, one hard-capped row per source — pending orders / unread messages / low or out of stock / offline devices — sourced from the existing overview payload + the existing devices summary; clears by state change, never by dismissal) · AI Recommendations. Everything else moved to a new add-widget gallery (per-widget hide ✕ + "Add widget" picker; zero data loss) — and owners with a pre-IA-6 saved layout are grandfathered (nothing hidden). Quick-Links stars now render as a shortcuts row on the Overview; the static Recent Activity card folded away (the Live Orders widget streams the live subset); the onboarding checklist auto-hides at 100%. i18n: help namespace (5 keys) + 10 new ops keys in all 20 non-en languages. tsc 0; guards 11/11; suite green (2 pre-existing fails).

• Marketing Hub (Phase 61 IA-4) — marketing tools grouped by job, one site-scoring surface. New thin landing page at /dashboard/marketing: tools grouped Promote / Reach / Reputation / Insights (incl. the Marketing ROI cross-link into Restora Profit), each tile respecting the same per-item featureId visibility as the sidebar, plus a light status strip (active offers · avg rating · loyalty members · scheduled posts) read from FOUR EXISTING tenant GETs — live number or "—", no time series, deliberately NOT a fourth analytics view. Site-scoring dedupe: the AI Design Report is now the SEO page's "Site Health" tab (the SEO page gained ?tab= deep-linking); /dashboard/design-report is a redirect stub into it. The V2 marketing group is ordered by the four jobs with the hub on top; the earlier IA-4 moves (Messages → Customers, Voice/Table Assistant → In-Venue Ops, AI Spend → Plan & Features) had already shipped in IA-0's catalog. i18n: new marketing dict namespace (15 keys) + seo.tabSiteHealth in all 20 non-en languages. tsc 0; guards 11/11; suite green (2 pre-existing fails).

• Experience Studio workspace + the nav-clobber data-loss fix (Phase 61 IA-3). New /studio workspace on the Atmosphere shell pattern (own scoped theme, session guard, navy sidebar) plus the back-to-dashboard link Atmosphere lacks; the V2 sidebar entry opens it in a new tab (existing non-/dashboard convention). It is a LAUNCHER — eight sections (Home · Website · Menu Screens · Kiosk · Displays · Create · Assets · Templates) of deep-link tiles; no tool route moved: Mason, the Menu TV designer, the Kiosk designer, Studio AI and the Media Library stay the single owners of their jobs (guard-tested via the new STUDIO_LINKED_TOOLS registry — each must remain a live page linked from the shell). The verified nav-clobber bug is closed: /dashboard/nav and Mason's NavbarEditor both wrote db.navConfig with incompatible item vocabularies — every save on one silently deleted the other's links. The stand-alone page is now a redirect stub into Mason opened directly on the Navbar editor's Menu tab (new additive deep links: /dashboard/site?panel=navbar|theme, &gallery=1); ONE write path remains. /dashboard/themes (the WoW-clone marketplace, zero approved snapshots in dev) also retires into the Mason theme gallery. The two buried pickers are surfaced as Displays tiles: customer-display themes (orders?tab=customer) and the order-tracking style (Mason theme panel). findNavItem gains a V1-pool fallback under nav_v2 so Quick-Links stars and bookmark validation keep working on tool pages that left the V2 sidebar. Bonus fix: /studio AND /atmosphere were 404 on tenant subdomains (missing from the proxy's BYPASS_PREFIXES) — both whitelisted; the nav sweep now fails on 404s so this class of bug can't slip again. Follow-ups tracked: IA-3b (surface badge/per-surface visibility/cart toggle in Mason's Menu tab — the API already preserves them), IA-3c (fold approved clone snapshots into the packages catalog). tsc 0; guards 11/11; suite green (2 pre-existing fails); sweep incl. /studio sections × both flag states passed.

• Hardware Center (Phase 61 IA-2) — every physical device pairable and manageable from ONE page, and the invisible-screens pairing fork surfaced. /dashboard/devices is now a tabbed manager: Overview (summary grid + the universal pair form) · Screens & TVs (embeds the same ScreensManager the Orders hub uses — one TV fleet, two doors) · Payment terminals (absorbs /dashboard/terminals) · Self-order kiosks (absorbs /dashboard/kiosks; the Kiosk Designer route is untouched) · Printers & peripherals (absorbs /dashboard/hardware) · Reliability (absorbs /dashboard/reliability). The four absorbed fleet routes are redirect stubs into their tabs (ABSORBED_ROUTES grew; guard-tested). ONE shared `PairDeviceCard` replaces the copy-pasted 6-char-code forms (universal form, terminals, screens; the kiosk form keeps its pick-the-look wizard flow but shares the code cleaner). Legacy TV-pairing fork fixed by surfacing: screens paired via the Orders-hub QR path share one tenant-wide token and never got a TvDevice record — they now appear as a pinned "Shared display link" card in the Screens tab with Rotate/Disable actions (existing display-token endpoints; honest all-screens-go-dark warnings). Folding NEW QR pairings into per-device tv-devices records is a tracked follow-up (needs real-TV re-pair testing). Menu TV keeps its own screens list plus an "All screens & devices" link into the hub; the orphaned TvPairingButton.tsx duplicate was deleted. V2 nav slims (fleet items → search keywords); V1 untouched. i18n: a new devices dict namespace (9 keys) in all 20 non-en languages. tsc 0; nav guards 10/10; live sweep incl. all 6 device tabs × both flag states passed.

• Setup Center + Plan & Features consolidation (Phase 61 IA-1) — 11 setup surfaces become ONE sectioned page, entitlement pages go 4 → 2. /dashboard/settings is now the Setup Center: every tab deep-linkable via ?tab= — Setup guide (absorbs the /dashboard/onboarding checklist, same localStorage+server-detected progress), General, Opening hours (absorbs /dashboard/business-hours; its viewport-fixed save bar became a tab-scoped sticky bar), Branding, Languages, Payments, Ordering & Delivery (winner-links per the dedupe table — each duplicated editor now has ONE home), Integrations (absorbs the /dashboard/connections hub grid; the old 4-platform delivery-toggle tab is retired — its strict superset lives on the Delivery page's Platforms tab), Website & Domains (connect/verify + the /dashboard/domains marketplace as one surface), Notifications, Security, plus a Devices pointer. Features page gains 3 URL-driven tabs: Manage (the Phase 56 capability switchboard, byte-identical PATCH), Your features (the catalog), Get more (the add-ons marketplace). All six absorbed routes (/onboarding, /business-hours, /connections, /domains, /capabilities, /addons) are redirect() stubs — the addons stub forwards query strings so Stripe checkout returns still finalise; AddonsMarketplace's post-purchase router.replace and 8 in-app links retargeted. Dedupe winners enforced: the delivery-zones map editor now lists legacy postcode zones (editable pricing + delete) and hosts the delivery-radius cap; the old postcode-zones tab is a signpost to it; /dashboard/translations keeps ONLY the AI translate editor (the duplicate enable/disable + default-language chips retired into a Setup Center link). V2 nav slims to match (absorbed items → search keywords; ABSORBED_ROUTES exported + guard-tested: every absorbed route must BE a redirect stub to its documented tab); V1 nav untouched. i18n: 19 new dict keys (Setup Center shell + Ordering section + Features tabs) ship in all 20 non-en languages. tsc 0; nav guards 10/10; suite green (2 pre-existing fails unrelated).

• Navigation 2.0 (Phase 61 IA-0) — the owner sidebar regrouped by job, behind the `nav_v2` flag. The ~112-entry owner nav is reorganized into the approved tree — daily primaries (Home · Quick Links · Orders) + compact daily groups (Reservations · Menu · Customers+Messages) + job workspaces (Marketing Hub · Experience Studio · Money · Restora Profit · Team · In-Venue Ops · Inventory & Suppliers · Devices) + conditional (Chains & Groups · Food Bazar) + utility (Plan & Features · Setup Center · Help Center) — as a pure regroup: every existing href appears exactly once, zero routes moved/added/removed, every item keeps its exact featureId/badge/icon so plan-gating is untouched (all enforced by a new nav-catalog.test.ts guard: href-set parity, per-href gating parity, registry/icon validity, i18n coverage — the catalog previously had zero tests). Rollout: platform flag nav_v2 (fail-safe OFF = the legacy nav byte-identical), flipped at runtime via the new super-admin GET/POST /api/admin/nav-v2/master-switch (audit-logged, ITA-pattern; listed in the flags console once created). Flag ON extras: sidebar search (and the Quick-Links picker) answer the old vocabulary — retired group names ("Marketing & AI", "Account & Settings", "Operations (in-venue)"…) and "Overview" match via catalog keywords, in English and translated — and a one-time dismissible "Navigation just got simpler" card explains the change. i18n: all 9 new labels ship in all 20 non-en languages, plus back-fill for 9 labels that had been silently English-only since 2026-07-05 (Capabilities, Menu TV, Take Order (Waiter), Self-order Kiosks, Kiosk Designer, Demand & Weather, Network Reliability, Devices & Apps, Delivery Area (map)); the guard test now enforces full label coverage forever. Quick-Links stars are unaffected (stored by href). New scripts/nav-sweep.mjs renders every catalog href in BOTH flag states as a real owner (login → sidebar-tree assertions → 112-href sweep → flag flip via the real API → restore). tsc 0; my-files lint 0; nav guards 9/9.

• Fixed: Network Reliability sidebar icon. Wifi was missing from NAV_ICONS, so the item silently rendered the Circle fallback since it shipped — now registered (and the new guard test fails on any future unmapped icon key).

• Real printing via the Windows Station (RW-3 slice 1) — Phase-38 hardware goes live. New public print-agent API (/api/public/hardware/claim|jobs|jobs/ack): an agent exchanges a hardware device's one-time pairing code (from /dashboard/hardware) for its capability token, then polls for work and acks each job. Agent-claimed devices get a real job lifecycle (queued → printing → done/failed, 3 delivery attempts, stuck-printing requeue so an agent dying mid-print never silently loses a receipt); unclaimed devices keep the mock behaviour byte-for-byte. The job poll doubles as the heartbeat (finally populates lastSeenAt → online dot), failures surface in the dashboard job log with the agent's reason ("out of paper"), and toPublicDevice now reports agent/agentInfo. Windows Station side: ESC/POS encoder (CP865 Nordic — åäöÅÄÖ correct on Swedish receipts), TCP:9100 + Windows-spooler RAW transports, cash-drawer kick. E2E-verified byte-exact against a wire-level fake printer. tsc 0; 9 new unit tests + 18 existing device tests green.

• Automatic burn-in protection on every connected screen. The TV surfaces (/tv/screen — all four modes — and the legacy /display queue) now drift the whole rendered frame through a ±2px 8-point orbit (one step per minute, 2s glide) via a shared useBurnInShift hook — imperceptible from viewing distance, but no static edge (logo, headers, column rules) ever parks on the same physical pixels, which is what permanently marks TVs left on all day. Because it lives in the page, every platform is covered: plain browsers, the Android TV shell, Samsung Tizen, LG webOS and the new Windows Station (native shells that ship their own orbiter coordinate via <html data-r360-burnin> so exactly one guard owns the transform, and display surfaces get overflow:hidden so the drift never spawns scrollbars). The "Connect a screen" card (Dashboard → Orders → TVs & Displays, and /dashboard/tvs) now tells owners: Automatic burn-in protection — every connected screen imperceptibly drifts the image so static content never marks your TV. tsc 0.

• Creator earnings — tenants earn 15% every time their image is resold. When a tenant creates + pays for an image and it's approved into the shared Inspiration pool, every time another restaurant buys it the original creator keeps 15% of the sale — carved from the platform's margin, so the buyer's price never changes (a resale has ~zero cost). Earnings land in a separate "Creator earnings" balance on the AI-spend page (shown in SEK so it feels real), which the owner can move into AI credit instantly, or — once a bank rail is wired — cash out above 300 SEK. Paid as AI credit today (zero payout infrastructure); the cash-out is a rail-agnostic PayoutRail adapter so a Nordic provider (Bankgiro/SEPA, Swish, Trustly, Adyen) plugs in later with no ledger changes. Anti-farming: royalties only on cross-tenant, admin-approved resales (originTenantId ≠ buyer), idempotent per sale. tsc 0, lint 0; royalty + FX-round-trip unit-verified.

• Batch background removal + a dedicated transparent-image price (25 SEK). A "Remove background · 25 SEK/ea" button above Your generations opens a picker of your generated images (videos and already-made cutouts are hidden), where you multi-select and see a running total. The key rule: if your AI credit can't cover the whole batch, nothing runs — you're shown the exact shortfall and a one-tap top-up by card (reusing the AI-credit top-up flow), then it proceeds; you're only charged for images that actually succeed (N idempotent ledger lines, and re-running an already-cut image is free). Background removal is now priced at 25 SEK (it costs us more than a generation, and a ready-to-composite cutout is worth more) — generation stays 10 SEK. Buying a transparent cutout from the Inspiration pool is likewise 25 SEK (regular pooled images stay 10); cutouts show over a checkerboard with a "transparent" badge so buyers see what they're getting. The single- and batch-removal paths share one server helper, so dedupe/charge/idempotency/Media-library-save/pool-banking behave identically. tsc 0, lint 0, pricing + idempotency unit-verified.

• Background-removed cutouts now flow everywhere — the owner's Media library AND the shared Inspiration pool. A cutout used to land only in Experience Studio's "Your generations", so it couldn't be picked in the Menu-TV designer / website builder / menu image pickers. It now also saves to the owner's Media library ("My Library" in every picker) as a permanent, reusable transparent PNG. And, exactly like a generated image, it is banked to the system-wide media pool as PENDING (originTenantId attributed): a super-admin approves it in the "System-wide Media Pool", after which other tenants can buy it for 25 SEK (the transparent-cutout price) into their own library (the buyer's copy is transparent too — no re-encode). Deduped per source image so distinct cutouts never collapse and the identical cutout can't be banked twice. Reuses the existing pool + approval + buy pipeline and the generated-image banking pattern verbatim — no new admin UI. tsc 0, lint 0.

• Experience Studio — Background removal (any image → a fully-transparent PNG), 10 SEK. A "Remove background" action turns any image into a transparent PNG cutout — on the AI-generated result and on every saved image in Your generations (the priority), so a dish/logo/product shot can be dropped onto a menu, signage, or the Menu-TV designer with no background. The cutout is saved back to the gallery and previewed over a checkerboard so the transparency is visible. Charged a flat 10 SEK (super-admin-editable) through the one AI-wallet ledger choke point — only on a delivered cutout (a failure is never billed), in the tenant's own currency for non-SEK wallets, itemized on the AI-spend statement as "Background removal". Paid-gated + budget-gated like image generation. Powered by a swappable hosted vendor (Photoroom / Clipdrop / remove.bg — whichever key is set); ships mock-first — with no key it shows an honest "not switched on yet" and charges nothing, going live the instant a key is provisioned. Security: the input-image fetch now goes through the DNS-pinned safeFetch (blocks private hosts), hardening this route and the existing generate route against SSRF. tsc 0, lint 0, 4 tests; adversarially reviewed.

• Exact menu import from Lumit (embedded on the restaurant's own site). Lumit (lumit.se) is embedded as an iframe (embed.lumit.se?id=<compId>) on restaurants' own domains (e.g. backagardskrogen.se) — the page URL carries no id, so it's detected from the embed in the page HTML (like GloriaFood/OrderYOYO). The whole menu is a world-readable static data.json on Lumit's S3/CloudFront (a fixed host — no SSRF, no AI), keyed by compId; items carry the restaurant's own photos when present. Verified live: Bäckagårdskrogen → 91 items / 11 categories with correct SEK prices (was 2). Auto-detects on /try and the website-link importer, and the import-learning loop records it as platform coverage (and resolves any prior "undiscovered platform" gap for it). tsc 0, lint 0, +2 tests.

• Import learning now recognises the PLATFORM pattern — so undiscovered ordering platforms surface themselves. The hardcoded adapters (Qopla/Wolt/GloriaFood/OrderYOYO) solve the known platforms; the learning loop now learns the shape so new systems sharing the same logic get caught. Each import's site signature records the known platform (if any) and, when a site LOOKS platform-backed (an ordering SPA with an ordering widget or an external-order link) but no adapter matched and the generic ladder read only a thin menu, it logs a "platform gap" grouped by shared structural markers. The super-admin Import Learning dashboard gains two panels: Platform coverage (exact, no-AI imports per adapter) and Undiscovered platforms — adapters worth building (the gap patterns, ranked by demand). A gap auto-resolves once an adapter later serves that pattern. GraphQL alone never triggers a gap (too common), and a fully-readable site is never flagged. All capture is anonymous + best-effort (never blocks an import). 13 new tests.

• Exact menu import from OrderYOYO (Cloudflare-fronted, read via the real browser). OrderYOYO ordering sites ({slug}.orderyoyo.{tld}) block every server fetch at the Cloudflare/JA3 layer, but the full menu is server-rendered into the page's __NEXT_DATA__. So we read it out of the RENDERED HTML obtained via real Chromium (whose TLS gets through) — exact menu, zero AI (verified live: 86 and 151 items on two real restaurants, correct prices). On the /try clone path the WoW capture already loads the page, so the menu is parsed from that SAME capture — no second browser. For the standalone importer a new SSRF-hardened fetchRenderedHtml fetches it (mirrors captureSiteForClone's IP-pinning). Registry-driven like the others; falls back to the ladder on any failure. tsc 0, lint 0, +6 tests (incl. malformed-payload safety).

• Exact menu import from Wolt and eatsmart/GloriaFood (auto-detected, like Qopla). The platform-API registry gains two more Nordic ordering platforms, each read deterministically from its public API — no AI, no truncation. Wolt: one unauthenticated call to the consumer assortment API keyed by the URL slug (verified live: 258 items / 17 categories with photos + prices for a real Stockholm venue). eatsmart (and any GloriaFood/Foodbooking-hosted ordering page — foodbooking.com, restaurantlogin.com, restaurants' own domains — they share one backend): a single POST /api/cart/init keyed by the restaurant_uid in the URL (verified live: 114 items / 14 categories). Both auto-apply to the WoW /try clone engine and the "website link" importer; a pasted Wolt/eatsmart URL upgrades to the exact API path, and any failure falls back to the generic ladder. A shared lib/menu-import/platform-common.ts keeps each new platform to "parse URL + fetch + map". safeFetch now supports POST so eatsmart's user-origin request is DNS-pinned (closes a rebind SSRF flagged in review). tsc 0, lint 0, 17 tests.

• Background removal is now 10 SEK (down from 25) — flat 10 SEK across the board. Since the vendor cost is a fraction of a krona, background removal is priced the same as a generation: generate, remove-bg, batch, and buying any image from the Inspiration pool are all 10 SEK. One config change (removeBgPriceSek 25 → 10) cascades to every surface. Simpler and cheaper.

• Menu-from-photo import is now on the Import hub too. A "Menu photo or PDF" card on /dashboard/import opens the existing full-featured photo importer (snap or upload a menu / PDF — or paste a URL — and AI reads the categories, dishes and prices, with review + photo-matching + budget-gated top-up). It's the same component the Menu editor already uses, surfaced here so every import method lives in one place. Always available (independent of the platform-importer flag); on success it drops the owner into the menu editor.

• Import hub is now one uniform page — no GloriaFood banner, and Wolt / OrderYOYO / Lumit are live (were "coming soon"). The /dashboard/import page dropped the big GloriaFood spotlight; every source is treated the same. A single Website / menu link card is the fast path (it auto-detects Qopla, Wolt, OrderYOYO, Lumit, GloriaFood and more), with the recognised platforms shown as chips (live first) and the file imports (CSV / Excel / WordPress) below. After yesterday's exact-import adapters shipped, Wolt, OrderYOYO and Lumit are flipped to live (thin website-link delegates registered as real providers, so their chips open a working wizard); Square / Toast / foodora stay "coming soon". The Website-link engine now also exact-parses the RENDERED page HTML from the browser capture (OrderYOYO's __NEXT_DATA__ behind Cloudflare, a lazily-injected GloriaFood/Lumit widget) before ever falling back to a vision read — so the import hub gets the same exact-import quality as the /try clone engine. tsc 0, lint 0, 18 import tests green.

• Pool safety — a tenant's OWN photos never enter the shared pool. Only generic AI art (a pure text-to-image scene, or a cutout of one) can be banked to the system-wide Inspiration pool for other tenants to buy. Previously every generated hero — including an img2img restaging of the owner's uploaded product photo — and every cutout were auto-banked (pending admin approval), which risked a restaurant's private/brand imagery being offered to competitors (and, now that creators earn 15% on resales, being over-banked to farm royalties). Generations now carry a generic provenance flag (true only when no owner photo was used); generate-core and background removal bank to the pool only when generic, and a cutout inherits its source's provenance. Fails safe: unknown/owner-sourced ⇒ private. tsc 0, lint 0, 142 studio/media tests green.

• Batch background removal — hardening from an adversarial review (before any user hit it). (1) An all-failed batch (e.g. the vendor is out of credits) now returns the honest 503 the single path would, so the modal never shows a green "done" for cutouts that were never made. (2) The top-up shortfall is sized off the signed wallet balance, so if the wallet was already overdrawn a single top-up clears the overdraft and the batch (was: a second payment needed). (3) The pre-charge gate is dedup-aware — images that already have a cutout are a free no-op and no longer trigger a spurious "add credit" ask. (4) Duplicate URLs in one batch are de-duplicated (no double-count). (5) Images that can't be read are reported as skipped instead of silently dropped from the tally. (Two concurrent-charge TOCTOU findings were left as-is — a pre-existing, bounded, self-healing property of the lifetime-wallet across all AI paths, not specific to this feature.) tsc 0, lint 0; signed-balance + shortfall unit-verified.

• Background removal can no longer double-charge on a retry (was: 10 SEK billed twice). Background removal is deterministic (same input image → identical cutout), yet the charge had no server-side idempotency — a lost/slow response + "Try again", two tabs, or the panel + gallery buttons firing on the same image each ran end-to-end and billed again. Now the charge carries a stable ref derived from the input image and the AI-wallet choke point (appendLedgerEntry) commits a ref-tagged charge at most once (serialized under the tenant row lock — mirrors the Swish accrual dedup); ref-less charges (top-ups, per-token usage) are unaffected. An upfront lookup also returns the already-made cutout free on a repeat, saving a wasted vendor credit. Unit-verified exactly-once. Found by an adversarial multi-agent review of the feature.

• A background-removal provider rate-limit (HTTP 429) is no longer mislabeled "out of credits". 429 (rate-limited, but the account still has credits) was collapsed with 402 (genuinely out of credits), telling the operator to "top up" an account that didn't need it. 429 now maps to its own RATE_LIMITED state → "busy right now, try again in a moment" (still charges nothing); only a real 402 says top up. Also found by the adversarial review.

• Platform ordering menus embedded on a restaurant's OWN website now import (were: no menu items). GloriaFood and OrderYOYO are usually embedded on the restaurant's own domain (e.g. sukisushi.se, inter-grill.se) whose URL carries no restaurant id — so the URL-only detector missed them and the generic ladder found "info but no menu." Detection now also reads the PAGE HTML: a GloriaFood widget's data-glf-ruid, or the OrderYOYO app's __NEXT_DATA__/oyyservices marker (its parser is now host-agnostic). The registry gained an optional matchesHtml, the WoW /try clone passes the captured HTML to it, and the website-link importer adds a "tier 0.5" that checks the fetched HTML. Verified live: Suki Sushi (GloriaFood) 127 items / 15 cats, Inter Grill (OrderYOYO custom domain) 111 items / 22 cats. GloriaFood also now always POSTs the fixed foodbooking.com backend (it serves every tenant), removing the earlier user-origin SSRF surface entirely.

• Imported dishes now use the restaurant's OWN photos, not a wrong stock guess. A URL import attaches no scraped photos, so the stock/demo matcher guessed one per dish — and on a box with no live stock keys (built-in demo library only) some guesses were visibly wrong (a poké bowl getting a generic sushi photo). Qopla's API actually returns each dish's real photo (refProduct.imageUrl, ~76% of items on the test restaurant — the owner's own licensed gallery), so the importer now carries those through as the dish image; the stock matcher only fills the remainder and leaves it blank rather than attach a mismatch. Also hardened that matcher: a stock photo now has to share a meaningful token (the protein/dish), not a generic form-word, so "Deluxe Rolls" can no longer match a cinnamon-rolls photo. ExtractedItem.imageDataUrl now carries a usable image URL from any structured source through normalizeExtractedMenu. Verified: 75/99 Saigo dishes get their real photo; 13 unit tests.

• Menu import from Qopla now reads the FULL menu (was 2-3 bogus items / hallucinated dishes). Qopla is a client-rendered GraphQL SPA, so a URL import saw an empty app-shell (the vision fallback turned a near-blank page into 2-3 invented dishes) and a full-page-image import hallucinated a different restaurant entirely. Qopla's ordering backend is a public GraphQL API, so we now read the exact menu from it — deterministically, no AI, no truncation: for the "Saigo — Sushi, Thai & Poke" test link that's 99 real items across 13 categories with correct Swedish names, prices, and descriptions (was 2-3). New shared lib/menu-import/qopla.ts (URL→publicId→getShopByPublicIdForOnlineOrder→getMenusByIds, deduping the duplicate day-menu + upsell repeats by product id) is wired into both entry points: the WoW /try clone engine (a structured platform-API menu now supersedes every heuristic read, and the real shop name flows into the rebuild) and the onboarding importer (a live qopla provider adapter + a Qopla short-circuit in the generic "website link" adapter, so a pasted Qopla URL auto-upgrades to the exact API path). Any API failure falls back to the previous ladder. Detection is registry-driven (lib/menu-import/platform-apis.ts) so teaching the importer the next platform-with-an-API (OrderYOYO, Wolt, …) is a one-line entry that auto-applies across every URL import path. tsc 0, lint 0, 6 unit tests (parse/dedupe/skip-rules/registry-detect); validated live end-to-end through the module, the registry, and the adapter.

• Menu TV — designed decks flashed to the background between screens (regression). MenuBoardScreen gated the outgoing crossfade layer on pages[prev], but pages is empty whenever a Screen Designer deck is playing — so the intended deck[prev] crossfade branch was dead code and each transition faded the incoming screen in over the bare host background (a ~700ms flash to base colour, worst on photo-forward signage decks — exactly the "professional signage" surface). The layer now resolves from whichever source is active (deck ? deck[prev] : pages[prev]), restoring the smooth crossfade for decks. Verified: DOM shows both layers coexisting mid-transition + a mid-fade screenshot shows the true colour blend (was: flash to base).
• Menu TV pairing screen used a retired orange glow. The 96px pairing code carried textShadow: rgba(194,98,42,.5) — a warm/clay colour on the customer-facing in-store setup screen — violating the azure-on-navy brand rule. Now azure (rgba(21,112,239,.5)), matching the Restora logo directly above it.
• Canvas editor — a shadowed headline lost its shadow while inline-editing. The contentEditable overlay shown on double-click didn't carry the text drop-shadow, so a shadowed headline flickered (shadow → none → shadow) the instant you started typing. The overlay now mirrors the same shadow, keeping the edit WYSIWYG.
• Menu TV — stale "6 templates" copy. The plan/entitlement feature description and the page header comment said "6 templates" and led with the Android app; 10 designed templates now ship (plus the freeform Screen Designer), and the browser path works today while the native app is not yet distributed — copy corrected to match.

• Phase 57 (ES-3) — Experience Studio style tiles now show real examples. Each creative-style tile previewed only an abstract colour swatch, so owners couldn't tell what "cinematic" or "moody" actually produces. The picker now pulls one real approved example image per style from the shared library (keyed by style, image-only, deduped) and shows it on the tile — falling back to the swatch for any style without an approved example yet. Purely additive + fail-open (a missing/blocked library just shows swatches as before).

• Phase 57 (ES-0) — Experience Studio, first declutter pass for non-technical owners. The generation form asked owners to make decisions they shouldn't have to: it defaulted cuisine to a hardcoded "burger", price level to "mid", and put two hex colour pickers front-and-centre. Now: cuisine defaults to empty and is auto-detected from the photo (moved under an "Advanced" section as an editable fallback, never "burger"); price level defaults to Premium (still changeable); brand + accent colours are tucked under "Advanced" since they auto-detect from the storefront; the headline is AI-written and editable (fills in after generation instead of a hardcoded "Built to order." placeholder); the white-label toggle is removed in favour of one flat per-image price with the Restora mark; and the confusing "Save as brand kit" button is hidden for single-location owners (colours auto-apply anyway) and, for franchises only, reworded to "Use these colours for all my restaurants." Help text updated to match. Groundwork for the fuller guided-flow redesign (ES-1…6, docs/Phase-57-Experience-Studio-Redesign.md).

• Menu TV canvas — gradients on shapes & the stage background + a text drop-shadow (owner ask 2026-07-08). Bringing richer fills to the freeform designer. (Shapes) a shape can be filled with a 2-colour gradient (From / To) instead of a flat colour, in one of four preset directions — Right (→), Down (↓), ↘, ↗ — chosen from a "Solid / Gradient" toggle. (Background) the canvas stage background gets the same Solid / Gradient choice. (Text) a Shadow toggle adds a soft drop shadow behind text for legibility over busy photos. Rendered identically on web and native (Compose Brush.linearGradient / Shadow); the two corner directions trace the element's box diagonal on both renderers (the web emits an aspect-dependent angle rather than the CSS to bottom right "magic corner", which diverges on non-square boxes — most visibly the 16:9 background), and the shadow uses the same offset/blur (0 2px 10px @55%) in both. Whole text/shape/background objects are in the board version hash, so any gradient/shadow edit re-ships within one device poll. NOT an AI feature — no credit is ever charged from the Menu TV designer. tsc 0, lint 0; web screenshot-verified (shape + background gradients in all 4 directions incl. wide/16:9 boxes, text with/without shadow) and native build clean; adversarial-reviewed (fixed the corner-angle + shadow-weight parity breaks before ship).

• Menu TV canvas — dish descriptions on a menu block (owner ask 2026-07-08). A menu block can now show each dish's description under its name (opt-in "Descriptions" toggle), like a printed menu — the small grey line, e.g. "San Marzano tomato, fior di latte, fresh basil…". Descriptions come from a per-item lookup built regardless of the device's board config, so a block shows them independently; the resolver copies items (never mutates the shared board data the auto-templates use), a shown description is in the version hash so an edit re-ships, and the interactive editor preview carries descriptions so the stage matches the TV. Web + native (Compose) render it the same (small, faded, indented under a photo). tsc 0, 17 tests; web + native screenshot-verified.

• Menu TV canvas — centred section heading with rules on both sides (owner ask 2026-07-08). A menu block's section heading can now be styled like a classic printed menu: ———— Pizze Rosse ———— — centred with a rule flanking each side. The heading rule gains a position (Under the heading, or Both sides) and a new Dotted style (alongside Line / Dashed), so you can pair it with the dotted name→price leader for the printed-menu look. Renders identically on web and native (Compose); existing headings (under-rule / bar) are unchanged. tsc 0, 18 tests; web + native screenshot-verified.

• Menu TV canvas — full menu-block styling for BOTH dishes and headings + full-bleed elements (owner asks 2026-07-08). Bringing the website's Menu Appearance controls onto the canvas menu block. (Dish rows) name size, price size, row gap, bold, italic, font (Sans/Serif/Mono), how the price sits (Right-aligned / Dotted leader / Inline), and a divider between rows (None / Dotted / Dashed / Solid + colour). (Section headings) everything from before plus a "Bar" header style (a filled colour bar behind the heading + its own colour). All keep the existing Text/Prices colours. (Full bleed) an image or shape can now be sized larger than the 1920×1080 stage (up to 2×) so it covers corner-to-corner without a margin on the opposite edge — the previous cap silently shrank bleed elements to the stage size. Rendered identically on web and native (Compose); one shared resolveMenuItem/resolveMenuHeading clamp for feed + save; all in the version hash. tsc 0, 17 tests; web + native screenshot-verified.

• Menu TV canvas — full section-heading styling (owner ask 2026-07-08). A live menu block only let you set the section-heading colour; now each heading (e.g. "Pizze Rosse") has a full "Section heading style" panel: colour, size, bold / italic / underline, UPPERCASE, left / centre / right alignment, font (Sans / Serif / Mono), and a divider rule beneath each heading (None / Line / Dashed) with its own colour. Rendered identically on web and native (Compose dashPathEffect for the dashed rule); existing blocks with no heading style are unchanged (bold, 34px, left, no divider). One shared resolveMenuHeading clamp for the feed AND save, in the board version hash so a style change re-ships. tsc 0, lint 0; web + native screenshot-verified.

• Menu TV Screen Designer — day-part scheduling (auto lunch → dinner boards). Any screen in a deck can be limited to certain weekdays and a local-time window ("When to show": Always, or pick days + from/to). The live TV feed shows only the screens active now — evaluated in the restaurant's timezone — and switches automatically as the day-part changes (the board's version hash already covers the visible screens, so the TV re-ships within one poll at a boundary). Overnight windows (e.g. 22:00–02:00) are supported; a screen with no schedule is always on; if every screen is out-of-window the board falls back to the normal auto-built menu. The designer always shows every screen (with a clock badge on scheduled ones). New lib/tv-menu/schedule.ts (pure: isScheduleActive / localDowMin / scheduleLabel / sanitizeSchedule), a schedule filter threaded through buildMenuBoardData (feed-only; the designer/preview never filters), and nowMs passed from the device-feed route. tsc 0, lint 0, 26 tests (weekday+window, overnight, filter-drops, timezone wall-clock); web screenshot-verified. Native needs no change — it just receives fewer screens.

• Menu TV canvas editor — multi-select, group move & alignment. Select several elements at once: shift-click to add/remove, drag an empty area to marquee (rubber-band) select, or Ctrl+A for all. Dragging any selected element moves the whole group together (with the group's bounding box snapping to the stage and other elements), arrow keys nudge the group, and Delete removes them all. When 2+ are selected the inspector becomes a group panel with Align (left / centre / right / top / middle / bottom), Distribute (horizontal / vertical, 3+), group opacity, and duplicate/delete. Ctrl+D / Ctrl+C / Ctrl+V now operate on the whole selection. Editor-only (no data/engine/native change — it just repositions elements); resize/rotate handles still appear for a single selection. Verified with Playwright (shift-select, align-top, group move, marquee-select-all); tsc 0, lint 0.

• Menu TV canvas editor — a menu block can now show MULTIPLE sections (owner ask 2026-07-08). A live menu element was limited to one section; it now holds several. The inspector's single dropdown became multi-select section chips, and the element renders each chosen section stacked (heading + its items, honouring prices/photos/2-columns) on both web and native. Under the hood the menu element stores categoryIds[] (the legacy single categoryId is still read, so existing blocks keep working); resolved server-side to live categories[] in menu order, ≤12 sections, deduped, in the board version hash. Verified web + native screenshots (three sections stacked, three chips) and a shaper test covering multi + legacy; tsc 0, lint 0.

• Menu TV canvas editor — pro-editor batch: undo/redo, snapping guides, rotation, keyboard shortcuts. The freeform canvas now behaves like a real design tool: undo/redo (toolbar buttons + Ctrl+Z / Ctrl+Shift+Z / Ctrl+Y) with per-screen history that coalesces a single gesture (a slider drag, a move) into one step; alignment/snapping guides — dragging an element snaps its edges/centre to the stage edges, stage centre, and other elements' edges/centres, drawing pink guide lines (hold Alt to disable); a rotation handle (drag the knob above the selection; Shift snaps to 15°); and shortcuts Ctrl+D duplicate, Ctrl+C/Ctrl+V copy-paste an element, Esc deselect (Delete + arrow-nudge already existed). Fixed a subtle history bug in the process — the stage no longer mutates shared element objects mid-gesture (it uses a local live-override), so an undo snapshot always captures the true pre-gesture state and reliably reverts a move/resize/rotate. Web-only (the native renderer already applies rotation). Verified with Playwright (snap guide mid-drag, rotate, undo-restores-upright); tsc 0, lint 0, 16 tests.

• Menu TV Screen Designer — a freeform, PowerPoint/Mason-style canvas editor (owner ask 2026-07-08). A new "Free canvas" screen type (and a "Start from a blank canvas" option) lets non-technical owners design a signage screen from scratch: an Insert bar drops text, image, video, box/shape, and live menu-block elements onto a 1920×1080 stage; every element drags to move, resizes with 8 handles, nudges with arrow keys, and deletes with Delete; double-click a text element to edit it in place (contentEditable, commits on Enter/blur). The right inspector gives per-element properties — text (size, colour, bold/italic/align), image/video (pick asset + fill/fit + rounding), shape (fill + rounding), menu block (bound section + prices/photos/2-columns + colours) — plus opacity/transparency, bring-to-front/send-to-back, duplicate, and a canvas background (colour, photo, dark overlay). Menu blocks stay LIVE (prices/86/numbering follow the real menu). Everything is stored as CanvasElement[] in design px and resolved server-side into the existing device feed (in the board version hash → TVs live-sync); a new native Compose renderer (CanvasScreen.kt, media3 for video) draws it 1:1 on the TV app. The editor renders through the SAME CanvasScreen component the TV uses, so Play shows exactly what the screen will display. Bounded/sanitised on save AND at render (≤40 elements, clamped geometry, HEX colours, safe URLs). Verified with browser screenshot QA (render / select / inline-edit / insert / freeform-drag / Play) and installed on the test tablet; tsc 0, lint 0, 16 shaper tests.

• Menu TV Screen Designer — drag-to-reorder screens. The rail's screens can now be dragged by a grip handle to reorder them (the arrow buttons stay as a keyboard/click alternative), reusing the menu page's proven @dnd-kit sortable pattern. Selection follows the dragged screen by id, and thumbnails look up their preview by screen id so a reorder repaints instantly without waiting for the board to re-resolve. Verified with a Playwright drag test.

• Menu TV — the Screen Designer gets its own page (owner ask 2026-07-08: "dedicated designer… its own space… so we can add advanced functionality later"). The designer squeezed into the Menu TV page's left column overflowed off-screen and had no room to grow. New /dashboard/menu-tv/designer: a three-pane studio — screens rail (live thumbnails + per-screen dwell badges) · big 16:9 canvas with a Play mode that runs the real rotation ("exactly what the TV shows") · a full inspector (screen type as visual buttons, sections, photos, structured offer editor, video, light/dark, colors, logo). Destructive actions now confirm (remove screen, restart with a pack); the canvas previews with a REPRESENTATIVE TV config (a deck-enabled TV's own numbering/prices/images settings) so what you design is what the TV renders. The Menu TV page keeps a compact entry card: style packs one-tap into the studio (?start=<pack> builds the deck on arrival), plus the per-TV "Show designed screens on" switches. All logic extracted to components/dashboard/menu-tv/designer-studio.tsx. Hardened by a 14-agent adversarial review before ship: a failed deck load can no longer lead to overwriting a saved design (error state + ?start= consumed via router.replace + auto-build only when the server verifiably has no deck), saves report honestly ("saving… / saved / couldn't save" incl. a no-permission message instead of a false "saves automatically"), screen ids can't collide (add→remove→add), the 24-screen server cap is enforced client-side, the dwell input commits on blur (10–39 s was untypeable with per-keystroke clamping), Play starts at the screen being edited, and finishing a design with no TV in Menu-board mode shows guidance instead of a dead end. Verified with browser screenshot QA (hero / menu-with-numbers / offer inspector / denied-save / no-TV states).

• Menu TV Screen Designer — professional digital signage for non-technical owners (owner spec 2026-07-08). Owners can now design their own signage deck instead of only picking a template: pick a starter pack (🍣 sushi / 🍔 burger / 🍕 pizzeria) and one tap builds a full deck from their REAL menu — a hero image screen, menu screens, and an offer screen. The engine (lib/tv-menu/deck.ts) suggests screens by bin-packing WHOLE categories against the chosen template's capacity, so the screen count follows the menu and a section never splits mid-screen; sanitizeDeck clamps everything (≤24 screens, ≤4 callouts, HEX colours, safe URLs). Four new screen primitives — Image Full, Image Duo, Offer with callouts, Video (uploaded MP4 or Experience Studio video gallery ONLY — no YouTube) — built twice, web (components/tv-menu/primitives/) and native Compose (android/tvmenu, media3/ExoPlayer). Per-screen everything: layout (12 templates + 4 primitives), sections, hide-category-names, images via MediaPicker (free sources only — nothing on this page can charge AI credit), callouts, light/dark, heading/price colours (WCAG auto-contrast per screen), logo show/position (default hidden), and dwell seconds. Decks resolve server-side onto the existing device feed (ResolvedDeckScreen[], included in the board version hash → TVs live-sync on any designer edit) and each TV opts in with a per-device "Designed screens" toggle (useDeck) — classic auto-generated boards untouched. New route /api/tenant/[tenantId]/menu-tv/deck (GET / suggest / save, settings.edit-gated). tsc 0; tests green; native :tvmenu builds and verified on the test tablet.

• FSN restaurant brand accounts — auto-provisioned, quality-gated, self-cleaning (owner spec 2026-07-08). Every restaurant now gets a Food Stories Network presence automatically, but the network stays high-quality by construction. (Auto-create) createTenantDatabase provisions a brand FSN account (fsnacct_rest_<tenantId>, un-loginnable) on tenant creation — best-effort, never blocks signup. (Quality gate) the account starts provisional and is HIDDEN from every feed/search/profile (folded into hiddenAuthorIds) until it publishes a real image + text post; a text-only post never reveals it. The first qualifying post (via Compose/autopilot → the FSN adapter) clears the flag and the restaurant appears on the network. (Disable on remove) deleteTenantDB disables the brand account (hidden immediately). (60-day cleanup) the existing fsn-account-purge cron now also erases brand accounts that are provisional-or-disabled with no activity for BRAND_INACTIVITY_DAYS (60) — empties and orphans self-clean; an active, posting brand account is never touched. New lib/fsn/brand-account.ts (pure: provision/disable/activate/purge/postQualifies) with 5 tests; the FSN social adapter refactored onto it. tsc 0; 61 FSN/social tests green.

• Owner evening batch (2026-07-07, screenshots): ITA live + measured-holiday forecasts + worker load + Ask-AI live data + FSN connector. (F — Table Assistant) it was BUILT all along (Phase 49) behind ita_enabled OFF; flipped ON with owner approval, created Luigi's first table (qrSlug tavolo-1), guest page serves 200. (A1) the MEASURED holiday lift now REPLACES the calendar's fixed +12%/+25% guess inside stock forecasts (per-named-holiday first, else overall; clamped ×0.3–3; signal detail says "measured from your own sales"; fixed defaults stay when nothing measured). (A2) worker load: DB-8 clock-ins × orders per LOCAL hour → orders per staffed person-hour at the heaviest slot, joined into the Plan-ahead card (≥20 staffed hours guard; honest empty state). (B — Ask AI) the owner's screenshot showed "show me low stock items" answered with a menu-management ARTICLE; new L0 live-data layer answers data questions with the restaurant's OWN numbers (low stock w/ item names → Review & reorder link, open orders, today's orders/revenue, unanswered reviews; EN+SV patterns) before any doc retrieval; new 'live' layer badge ("From your live data"). (C — Social) FSN (our own network!) is now a first-class connector — no OAuth: connecting creates a brand FSN author account per restaurant (unusable password, stable id) and publishing writes REAL FsnPosts into the real feed (engagement read live from the feed store); + fixed the owner-reported contradictory state ("Connected." under a "Not connected" card) with an honest-state guard. 7+ new tests; tsc 0. REMAINING from the batch: bilingual (EN+SV) SEO generation, campaign real-world scenarios.

• S1-H Holidays × peak hours × staffing — the owner's missing pieces, found and built (2026-07-07: "I told the system to use holidays/religious/cultural days to learn behaviour, staffing, peak hours — I don't see it"). He was right: the date-holidays calendar (~200 countries incl. Ramadan/Eid/Easter/Diwali) had been wired into stock forecasts since Phase 2 but only applied a FIXED guess (+12%/+25%) — its own comment admitted "future learning tunes it from history" and that learning never existed; staffing/peak-hours existed nowhere. (demand-calendar.ts) holiday impact MEASURED from the restaurant's own orders against its same-weekday non-holiday baseline (≥4 baseline days; overall claim needs ≥2 measured holidays; per-named-holiday entries honest at n=1 — "measured once, will sharpen"). (peak-hours.ts) items-per-LOCAL-hour histograms (settings.timezone IANA — a US restaurant's 6pm rush never reads as UTC midnight) → busiest 2-hour window per weekday (≥8 orders guard) + staffingOutlook: upcoming holidays (observances excluded) joined with the measured lift and that weekday's peak window into plain sentences ("Midsommarafton is in 2 days — last time it ran 80% above a normal day; busiest hours 17:00–19:00"); zero history → honest "your first X on record — we'll measure it". Surfaces: /dashboard/demand gains Plan ahead (staffing), Holidays — how they actually hit you, and Your peak hours (24h histogram + per-weekday windows); the daily briefing's measured section now leads with a time-sensitive holiday heads-up (≤4 days out); Ledger demand counter + S1 gap updated (honest remainder: measured lift doesn't replace the calendar's fixed guess inside stock forecasts yet; worker-load needs the Shifts clock-in data joined). 8 new tests (calendar verified against real Swedish holidays incl. Midsummer); tsc 0.

• DS-6 Support per-answer accountability (gap-list "continue" 2026-07-07) — plus an honest Ledger correction. Investigating the "no signal on which answers resolved the question" gap revealed it was STALE: thumbs feedback, global+per-tenant CSAT, daily trend buckets and the down-vote-rejects-pending-draft guard existed all along. What was genuinely missing: votes never landed on the SPECIFIC answer served — a repeatedly-downvoted APPROVED answer stayed approved invisibly. Now: the widget sends the served answer's matchedId with each vote; SupportBrainStore.answerFeedback tallies per answer (bounded, lowest-traffic evicted); flaggedAnswers() surfaces answers with ≥3 downs and downs>ups; the super-admin Support Brain console gains a "Flagged answers" queue (worst net-negative first, one-click "Stop serving this" reject for approved learned answers; Help-Center entries show their source for a docs edit). Learning Ledger: new "Support answers — did they actually help?" counter (CSAT + votes + flagged count) and the gap entry CORRECTED (it understated reality) — narrowed to escalation outcomes + docs follow-through. 3 new tests (support suite 11); tsc 0.

• Import density check — the "3 of 28 looked perfect" blind spot, closed at import time (gap-list item, owner "continue" 2026-07-07). A JavaScript-rendered menu whose HTML text carried only 3 of 28 dishes produced a spotless-looking import; the page itself betrays the truth — it still SHOWS ~28 price tokens. New lib/menu-import/density.ts counts currency-MARKED prices only ("129 kr", "85:-", "€12,50" — phone numbers/years never inflate the expectation; guards: ≥8 visible prices AND under 40% extracted before it may speak, so option-price-heavy menus don't false-alarm). Wired into the universal importer's URL adapter twice: (1) a suspicious density now TRIGGERS the real-browser capture tier even when the item count passed the old ≥3 threshold — and the capture result is adopted only when it found MORE (a retry can never replace a decent text read with a worse screenshot read); (2) if the final result is still short, the import report's "Worth a look" panel says honestly: "The page shows about N prices but we only found M dishes — part of the menu may be hidden from us." Learning Ledger completeness-trend method + gap updated (remaining: photo/PDF imports have no page text to compare; density not yet recorded on the learning signal). 5 new tests; import-providers suite 23 green; tsc 0.

• VL-B Voice transcript mining — the drive-thru now learns (owner "continue" 2026-07-07). The lane transcripts recorded since DS-4 finally feed back into the product. (Mining) lib/voice-concierge/mining.ts — template-driven: stored replies are matched back against the engine's OWN message templates (vcTemplateRegexes, every language), so the 'unresolved' reply's {text} placeholder yields the exact chunk the guest said that failed to match — no LLM, no re-parsing of raw audio text; scrub artifacts ([number]/[email]) and owner-ignored phrases are dropped. (The loop) new Product.voiceAliases (owner-CONFIRMED only — mining never writes aliases itself) is indexed as EXTRA NAMES in buildProductIndex, so a mapped phrase resolves through resolveDish on every surface (lane, phone concierge, POS search) from the next request; proven by a loop-closure test ("cheese pizza" unresolvable → mapped → resolves). (Owner surface) the Voice & Concierge page gains a "Guests said this — the menu couldn't match it" card (phrase + said N× + "They meant…" dish picker + Teach it / Ignore); the list is SELF-CLEANING — each mined phrase is re-run through the current index, so mapped phrases (or dishes added since) drop out by themselves; POST /api/tenant/[id]/voice-concierge/aliases (map/ignore, capped 12 aliases/dish, 100 ignores). (Measured trends) the Learning Ledger gains two lane trends measured from the transcripts — "turns understood first try" (reply-vs-template misses) and "conversations that ended in an order" — and the voice gap narrows to what's genuinely left (lane volume; phone/web surfaces don't record transcripts yet). 6 new tests (63 voice+search suite green); tsc 0.

• S1/S2 → the daily briefing email ("Measured this month", owner go 2026-07-07). The demand and reliability intelligence no longer waits for a dashboard visit: the daily executive briefing now carries up to 3 MEASURED lines — the 2 strongest demand↔weather patterns plus the reliability root-cause line when there were outages (zero-outage days stay silent: a daily "all fine" is noise). Design honors the honesty contract end-to-end: lib/ai/briefing/intelligence-lines.ts computes the lines deterministically and the service attaches them to a NEW Briefing.measured field AFTER the AI step — the LLM never sees them, so a measured number can never come back paraphrased. Rendered as a "📊 Measured this month" section in the email (html+text) and on /dashboard/ai-briefings (with links to the two detail pages). Best-effort everywhere: any failure just means fewer lines, never a failed briefing. 4 new tests; tsc 0.

• S2 Operations Intelligence — the second flagship RIC scenario, live (2026-07-07, same day as S1). "Is this my equipment, or an area-wide network problem?" is now answered from real device history, not a guess. Builds on the already-live DS-1 reliability history (deviceReliability: offline gaps + Wi-Fi↔cellular flips, consent-gated). New: lib/devices/network-identity.ts — best-effort ISP detection from a heartbeat's client IP (free ip-api.com lookup, 4s timeout, never blocks the heartbeat), caching only the ISP name against a MASKED ip (never the raw address) with a 30-day TTL; explicitly skips private/CGNAT ranges (10.x/172.16-31.x/192.168.x/100.64.0.0/10 — this box's own Tailscale range) rather than reporting a wrong ISP; wired fire-and-forget into both heartbeat routes (POS + Android terminal). New: lib/devices/reliability-area.ts — the anonymous cross-tenant counterpart of demand-area: per-cell gap TIME-WINDOWS (no tenant/device ids), k-anonymous (≥3 contributors), rebuilt in the same weather-cron tenant walk. New: lib/devices/reliability-insights.ts — the root-cause narrator: correlates a tenant's own outages against the area's anonymous gap windows by TIME OVERLAP (not ISP matching — simpler and works without identity) to split "N of your M outages lined up with restaurants nearby → shared network/power problem" from "isolated → your own Wi-Fi/router", plus an own-vs-area-average rate comparison (≥25% relative guard, ≥3 area gaps to compare against) and honest "still watching" lines. Surfaces: owner page `/dashboard/reliability` ("Network Reliability", sidebar NEW badge + a card on the Devices & Apps hub), GET /api/tenant/[id]/reliability-insights; Learning Ledger gains a reliability-patterns counter (contributors, cells, ISPs detected) and the Scenario-2 gap narrows to what's genuinely left (≥3 sharing restaurants per area; the ISP detection is flagged UNVERIFIED behind this deployment's own reverse-proxy chain until confirmed live). 16 new tests (dish-taxonomy/demand suite unchanged at 32 + reliability-area 5 + reliability-insights 8 + network-identity 3); tsc 0.

• S1 Demand Intelligence — the founding RIC scenario, live (owner go 2026-07-07: "the big vision"). "Pizza down, burgers up in this area — because it's sunny" is now measured, not imagined. (S1-0) lib/intelligence/dish-taxonomy.ts — a deterministic multilingual (EN/SV/IT/TR) dish→category classifier (18 global categories, priority-ordered so "chicken burger"→burger, "kycklingsallad"→salad, "kebabpizza"→pizza; substring for Swedish compounds, word-start for short keywords; no AI, fully explainable). (S1-1) demand-rollup.ts — a tenant's orders → daily category buckets (canceled/rejected excluded, combo headers not double-counted; classifier reads product name in every language + the tenant's menu-category name, falling back to the order-line snapshot for deleted dishes). (S1-2) measured weather history: new WeatherHistoryDB app-doc backfilled from the free Open-Meteo ARCHIVE API (real past tMax+precipitation per ~11 km cell, ≤1 fetch per cell per day, pruned at 400 days) — the existing cache only ever knew today's forecast. (S1-3) demand-insights.ts — deterministic correlation with honest significance guards (≥8 days per bucket, ≥5% share + ≥30 units per category, ≥20% relative move) voicing plain-language sentences that always carry their sample counts ("On rainy days, Pizza rises to 34% of everything you sell (vs 26% on clear days) — measured over 26 rainy and 41 clear days."); below-guard patterns surface as "still watching for", never dressed up as findings. (S1-4 area layer) the weather cron's existing tenant walk now also rebuilds an ANONYMOUS per-cell area rollup (consenting tenants only — ricLearningAccepted, fail-closed; contributor COUNT + category totals only, no tenant ids; k-anonymity ≥3 before anything shows; contribute-to-see: non-sharing restaurants see no area numbers). Surfaces: owner page `/dashboard/demand` ("Demand & Weather", sidebar NEW badge) with insights, watching-list, measured category mix, area comparison and a coverage footer; GET /api/tenant/[id]/demand-insights; Learning Ledger gains a demand-patterns counter and the Scenario-1 gap narrows to what's genuinely left (≥3 sharing restaurants per cell; feeding briefings/stock forecasts). 16/16 new tests (incl. the k-anonymity gate); tsc 0; archive API response shape verified live.

• Supplier "all three" batch (owner go 2026-07-07): crons live + profile unfrozen + approve-from-email. (1) Crons: daily-briefings (04:10 UTC) and inventory-reports (hourly, delivering at each tenant's chosen local hour) are finally scheduled on the box — the daily "N products low" emails the owner designed now actually fire for opted-in tenants. (2) Supplier profile: the write-once half is editable — /api/supplier/[id]/profile PATCH now covers contactName/phone/address/businessType/vatNumber/fulfillmentMethods/productCategories/minimumOrderValue/leadTimeHours (registration vocabularies enforced), the page (/supplier/storefront, nav renamed "Profile") gains a Business-details section with chip pickers, and the logo finally uses the real image uploader instead of paste-a-URL. (3) Approve-from-email (the flagship): the daily inventory email now proposes a CONCRETE supplier pick per reorder line (previous supplier first, else cheapest) with a signed one-tap "Approve & order" button → GET /api/public/inventory/approve-reorder verifies the HMAC token (48h, tamper-tested), REPRICES server-side, applies the same daily spend-limit gate as the dashboard flow, places via the shared B2B order engine with payment honestly on-account/invoice (Phase-40 pending), notifies the supplier at placement (previously only fired on payment-confirm, i.e. never in prod), emails the owner a confirmation, and renders a human confirmation page; idempotent per ingredient+day ("Already ordered"). tsc 0.

• Multi-role identity + email-only verification (owner decisions 2026-07-07). (1) One login, many hats: a person can now be restaurant owner AND food supplier AND designer AND agent under one email — additive UserRecord.roles[]; GET/POST /api/auth/portals lists the portals a signed-in user genuinely holds (re-resolving each role's record and re-applying the SAME suspension checks login uses) and re-mints the single-role session cookie on switch, so every existing guard is untouched; POST /api/auth/add-role attaches a Supplier identity to the signed-in account (same taxonomy enums as registration; email treated as verified — the session proves account control); PortalSwitcher renders in the supplier rail only for multi-hat users. Also fixed: /supplier was a 404 — now forwards to the portal. (2) SMS verification off until the sender paperwork is done: phone verification is REQUIRED only when SMS_PROVIDER is configured (PHONE_VERIFICATION_REQUIRED) — in prod the OTP only ever reached the server log, so the mandatory phone step silently blocked every real partner at 'email-verified' forever; email alone now activates, the verify page hides the phone card (smsRequired on the snapshot), and getVerificationSnapshot self-heals stuck statuses on the next visit. Flips back automatically when SMS is configured. tsc 0.

• Phase DS — the missing data streams, closed in one pass (owner go 2026-07-07; Ledger = source of truth). DS-2: order.status_changed finally EMITTED (transactional outbox — same save as the status change) from the staff status PATCH + the restaurant cancel route, with a canceled marker and no free-text reason (PII); the RIE order-lifecycle projection ingests it unchanged; Ledger gains a 30-day cancellation-rate row. DS-7: guest allergen/dietary asks counted per dish (bounded itaAllergenAsks map, real product ids only, count+lastAt only, fire-and-forget so the safety answer never waits); the allergen-coverage list now ranks by REAL asks → popular → name and the card shows "guests asked N×" — the guest-question gap closes. DS-4 (VL-A): lane conversations record their full transcript — one session row per car (surfaceSessionId), every turn heard/replied/outcome, scrubbed (emails + digit-runs masked) and capped (40 turns × 500 chars); the lane suppresses advanceTurn's terminal row (recordSession:false) so owner KPIs never double-count; Ledger voice row upgrades to live. DS-1: device reliability HISTORY — heartbeat transitions become bounded per-tenant records (deviceReliability: offline gaps >10 min + wifi↔cellular flips; rolling caps; consent-gated by the existing device-telemetry consent; honest limit documented: terminals ping on use, so a gap reads "unused OR offline" until clocked POS heartbeats land). DS-3 (ops, live-verified): the ADR-17 pipe to RIC is OPEN — ric_event_export flag on, RIC_EXPORT_TOKEN set, RIC worker rebooted "r360 pull ON" and stored 60 events on its first pull. Deferred with Ledger gaps: DS-5 generation keep/edit signals, DS-6 support-answer thumbs, DS-8 marketing engagement, clocked POS heartbeats + ISP identity. All slices tsc 0 + tests green.

• Allergen declaration coverage (AL slice) — the "ingredient truth ladder" made real (owner go 2026-07-07). Safety invariant unchanged: guests are answered ONLY from what THIS kitchen confirmed — never inference, never cross-restaurant statistics. What's new is making the kitchen's confirmation effortless and measurable. (1) New Product.allergensConfirmedAt (additive) distinguishes "declared allergen-free" from "never looked at" (a bare empty allergens array reads as nothing-recorded in the ITA). (2) lib/menu/allergen-coverage.ts — coverage math + deterministic per-dish suggestions drawn from the dish's OWN multilingual name/description/ingredients text via the existing EN/SV/TR/AR/FA keyword map (86'd dishes excluded; popular-first ordering; 4 unit tests). (3) GET/POST /api/tenant/[id]/menu/allergen-coverage — coverage + one-tap kitchen confirmation (registry-validated ids; empty set = confirmed none; writes the human-gated allergens + the stamp). (4) Menu-page coverage card: "N dishes have no allergen info — guests asking about them can only be told 'ask our staff'" → expandable list, suggestion chips (tap to untick), Confirm / "None apply" per dish; goes green when the menu is fully covered. (5) Learning Ledger gains an "Allergen declarations (safety coverage)" counter (X dishes covered, % of active dishes across tenants) and the gap entry narrows to what's genuinely left: ranking nudges by REAL guest questions (not recorded per dish yet). E2E-verified on dev: Pad Thai created → suggestions gluten/eggs/peanuts/soy from its own description → one-tap confirm → covered, stamped. 13/13 menu tests; tsc 0; dark-vocabulary green.

• Learning Ledger follow-up (owner feedback on first prod look): the Ledger moved INTO the Intelligence command center (/admin/intelligence/learning, old URL redirects) — it had been rendering its dark idiom inside the standard admin chrome and broke in Light mode; inside the always-dark IntelligenceShell (with a new "Learning Ledger" nav item) both modes are correct by construction. Added measured accuracy-over-time: first-pass import accuracy per week (share of AI-extracted items the owner kept unedited — the exact formula the learning store scores scenarios with), rendered as a bar trend with "first week X% → this week Y%", the sample count per bucket, and the method spelled out under the chart so the number is never a black box; the same LedgerTrend shape is ready for voice/generation accuracy when those loops land. Learned-knowledge rows now lead with the plain-language lesson (rule-kind label) with the free-text note as context. And rie_enabled was switched ON (owner request) — the Intelligence Engine now genuinely collects platform-usage signals, and the Ledger's RIE row reads "Collecting".

• Learning Ledger + Data & Learning framework (LL-0 / DL-1 / DL-2) — the first slice of the RIC intelligence program (owner go 2026-07-07). Ledger: new super-admin page /admin/learning (sidebar: "Learning Ledger") — the honest window into platform learning: consent coverage (owners sharing learning signals / device diagnostics, capped scan), live counters over what's genuinely collected (import-correction signals, Studio approved examples, weather area-cells, voice sessions [partial — transcripts are a declared gap], RIE platform-usage events incl. its flag-off state), the distilled learned knowledge list (import rules with plain-language lessons + how often each was used), and a permanent "Not learning yet" gap list (S1 demand, S2 ops, voice, generation, onboarding, marketing, support, RIE-off) so missing loops are visible instead of silently absent. Read-only aggregation (lib/learning/ledger.ts + GET /api/admin/learning). Framework: the legal design is tiered — anonymous/aggregated learning (outside GDPR), business telemetry (terms-disclosed legitimate interest + opt-out), personal data (real unticked opt-in; NOT covered by signup). Restaurant signup now captures an affirmative terms acceptance (checkbox, required by RegisterSchema.acceptTerms, on both /register and the onboarding wizard) whose wording contains the anonymized-learning disclosure; registration records TenantSettings.termsAcceptance (v2026-07) and seeds the same `ricLearningAcceptance` record the Settings switch writes (wording v3-signup-li, revocable in Settings → Data sharing as before). Pre-framework owners get a slim one-click dashboard invite banner (writes the same record via the existing data-sharing API; "Not now" dismisses per device; never auto-flips). Verified live on dev: register rejects without the box (friendly message), accepts with it, both records written; ledger builder returns real counts. Also fixed a pre-existing dark-mode bug the vocabulary test caught: the delivery-zone map's hardcoded pale backdrop → var(--color-card). tsc 0; vocabulary + dark-vocabulary + consent + import-learning tests green.

• Drive-thru lane: human-feel batch (owner test feedback). (1) Natural voice — the native kiosk now picks the most natural installed TTS voice per language (highest quality, exact-country preferred, offline preferred on ties) instead of the robotic engine default. (2) Patient listening — customers think out loud ("mmm… take number 3… aaah… two of number 2"): the recognizer no longer endpoints at the first pause; finalized segments are buffered and listening auto-restarts, submitting the WHOLE utterance as one order sentence only after a full quiet round, a "tap when you're done", or a ~60s cap — plus long-silence endpointing extras, and pure thinking-noises (um/uhh/hmm/mmm/aah/öh/äh, en+sv) are stripped before the text reaches the engine so they can't misread as dish words. (3) Explicit confirm → order number — the lane read-back now speaks like a human at the window and asks for the word: "So that's 1 Marinara and 2 Diavola. That'll be 49.00 SEK all together. Say \"confirm\" — or tap the green button — and I'll send your order to the kitchen." (sv equivalent with "bekräfta", now accepted by the engine's confirm matcher: bekrafta folded, +test); a placed order speaks and shows its short orderNumber ("Your order number is 7 — please pull forward!"), which advanceTurn now returns (additive) and the lane route exposes. Confirmed orders were already born-PENDING source:'drive-thru' → they land in Live Orders/KDS as before. Lane-only dressing lives in the VC-8 route — the shared engine copy stays phone-neutral. 16/16 voice-concierge engine+turn tests; tsc 0; :pos:assembleDebug green.

• Native drive-thru voice kiosk — a third mode on the POS tablet (`android/:pos` + `:core`, no server change). The web VC-8 lane kiosk ported 1:1 into the POS app's boot picker (Register / Terminal / Drive-thru): the AI greets each car out loud (time-aware, en/sv), the customer orders by voice (native SpeechRecognizer, push-to-talk with live partial transcript) or by tapping the always-numbered menu ("number 3" resolved client-side so the number heard can never drift from the number shown), every turn runs through the SAME deterministic tenant-guarded voice-concierge/lane engine, replies are spoken via native TextToSpeech, and the running order/board, read-back → Confirm order, "Order placed — pull forward" (9s auto-advance to the next car), escalation and flag-off states all mirror the web lane. Always-dark kiosk chrome (KDS navy theme, system bars hidden), RECORD_AUDIO + Android-11 speech-service visibility in the manifest, and the same restaurant login gate as the register. Multi-agent reviewed (4 lenses); 10 fixes applied incl.: never speak the greeting into an open mic, one-turn-at-a-time guard (a tap mid-voice-turn can't fork the conversation), full car+blocked reset on exit (the activity-scoped VM otherwise resumes the previous car on re-entry), HTTP 403-token match (a bare "403" also matched ports like :4030), honoring the on-screen partial transcript when an OEM ends a forced stop with NO_MATCH, web-parity dimmed disabled buttons (the M3 default swallowed the busy spinner on navy), ≥48dp customer touch targets, and non-clipping boot-picker cards. :pos:assembleDebug green. Remaining for go-live: on-device UAT (mic quality at a real lane) + the per-lane device token the VC-8 route notes for unattended lanes.

• Phase 56 (CC-9) — Swedish fiscal recording core (the sale→kassakvitto engine). Building toward wiring the fiscal engine into live sales: a pure, synchronous recordFiscalSale that assigns the next unbroken receipt number, signs it (sandbox control code — sync so it can run inside the row-locked order mutation), advances a small per-register counter (last number + grand total), and returns the kassakvitto + journal entry — plus an order→receipt-line mapper (single VAT rate, matching the platform's existing order VAT model; delivery + negative-discount lines so the receipt total equals the order total). Designed so the journal is DERIVED from orders (no unbounded array in any document). 5/5 unit tests. Still isolated — the point-of-sale payment-seam hook, tenant fiscal config, and dashboard are the next slices; and it stays sandbox (certified: false) until a certified control unit is connected.

• Social Media — "Connect" gave no feedback and swallowed failures. On the restaurant Social Media page, clicking Connect fired a request with no success/error handling: if it failed (or the platform's OAuth creds weren't wired), nothing happened and the owner couldn't tell why. Now each card shows a clear "Connected." or the actual error under the button, an early "no restaurant selected" case is surfaced instead of silently returning, and the accounts API returns a useful message (e.g. an adapter's "OAuth not configured") with a 400 instead of an unhandled 500. (Platforms still connect in demo mode until their real OAuth app credentials are configured.)

• Food Stories (FSN) — sign in / create your account with Microsoft & Facebook (alongside the existing Google, Apple and email). Same env-driven design as before: each provider lights up the moment its own credentials are configured and shows a "Soon" badge until then, so all four appear on the join screen. Microsoft is OIDC (idtoken, PKCE — like Google); Facebook reads email + name from the Graph API after the code exchange (it isn't OIDC). New env: `MICROSOFTOAUTHCLIENTID/SECRET (+ optional MICROSOFTOAUTHTENANT, default common) and FACEBOOKOAUTHCLIENT_ID/SECRET, with the callback {origin}/api/fsn/oauth/{provider}/callback`. 3/3 provider tests. (Web; the native FSN app stays email-only for now — in-app social sign-in is a follow-up.)

• Menu TV — numbers STILL didn't show after the 3-choice control: the per-dish `showNumber:false` veto (owner report 2026-07-08, second round). Premium starters and demo packs seed every dish with showNumber: false — a field NO dashboard UI exposes — so computeNumbers skipped every item and an explicit "1…N" still rendered zero numbers. Now an owner's explicit board numbersMode ignores that invisible starter baggage and numbers every dish; the legacy follow-the-storefront path still respects it, so a board mirroring the website stays byte-identical to the website. New shaper test locks both.

• Menu TV — the "Numbers" toggle silently did nothing on an un-numbered menu (owner report 2026-07-08). The board's numbers only revealed the storefront's Menu > Appearance numbering; with that set to "None" (the default), toggling Numbers on any TV template had zero effect. The toggle is now the SAME 3-choice control as the Menu page — None / 1…N / Per section — and an explicit pick numbers the board itself via a new MenuBoardConfig.numbersMode, independent of the website menu (absent = legacy follow-the-storefront, so existing boards are unchanged). The shaper normalizes showNumbers to what actually renders (templates and the native apps gate on it), numbering still matches the storefront ordering rules (showNumber per-dish opt-out respected, slice-stable global numbers), and the mode is in the board version hash so TVs re-sync instantly. No native app change needed — numbers were already on the wire per item. New shaper test locks override + legacy + hash behaviour.

• Food Stories — the "Import from LinkedIn" CV import wasn't discoverable. A change earlier today hid the whole CV & job-history section (which holds the LinkedIn import) behind the "I'm looking for work" toggle, so a member who hadn't switched that on couldn't see the import at all. The CV section staying tied to "looking for work" is intended; this note records that the LinkedIn import lives there and appears once the toggle is on.

• Admin "View Platform" link (and the Google OAuth redirect) pointed at localhost. The super-admin top bar's "View Platform" button was hardcoded to http://localhost:3001, so in production it opened localhost instead of the live site — now a relative / that resolves to whatever origin the admin is served from. Separately, when GOOGLE_OAUTH_REDIRECT_URI is unset the Google-connect redirect no longer falls back to localhost; it derives from NEXT_PUBLIC_SITE_URL (must still match a URI registered in the Google console). The super-admin dev-credentials card (which also shows a localhost URL + demo password) was already correctly tree-shaken out of production — verified.

• Some admin pages returned "Internal Server Error" after a bad build. A production build whose static-generation worker was OOM-killed left a corrupt .next with an incomplete React Client Manifest (missing Next's metadata/viewport boundary modules), which 500s authenticated pages on render (e.g. /admin/dashboard/staff). A clean rebuild regenerates a complete manifest and clears it; the experimental.cpus: 2 build-worker cap already in next.config is the standing guard against the OOM that causes it. Public routes crawled clean (no 500s); /pricing and /blog return 404 but nothing links to them.

• Phase 56 (CC-9) — Swedish kassaregister (cash-register-law) fiscal engine, foundation. A new server-side lib/fiscal/se/ module implementing the software side of Sweden's cash-register law (Skatteförfarandelag ch. 39 + Skatteverket SKVFS 2014:9/2014:10, updated by SKVFS 2021:16/17 effective 2027-01-01). Builds a compliant kassakvitto with every mandated field (seller/org-number/address, unbroken sequential receipt number, per-rate VAT extracted from VAT-inclusive prices, payment method, control-unit serial + control code, copy/pro-forma/training marking), appends an immutable journal (journalminne), produces X- and Z-reports (net-of-returns, VAT-per-rate, per payment method, grand total), and exports the journal as SKVFS 2021:16-style XML (the 2027 requirement). A pluggable control-unit adapter (kontrollenhet — hardware "black box" or approved cloud control system) signs each sale; auto-applies when the tenant's country is Sweden. 13/13 unit tests. ⚠️ Foundation only, not yet wired to the sale path or UI, and — critically — not a legal certification: real use requires a RISE-certified control unit/cloud control system, a manufacturer declaration, registration with Skatteverket, and a tax-professional's sign-off; until a certified unit is connected the engine runs in a clearly-flagged sandbox mode (certified: false on every artefact).

• Phase 56 (CC-6) — bookkeeping charts of accounts for the US, Canada, Denmark & Norway. The per-country chart-of-accounts registry previously only held Sweden, so every non-SE tenant's books fell back to Swedish BAS accounts. Added four national charts, wired automatically by the tenant's countryCode (the mapping resolver already keyed off it): US models sales tax correctly — collected as a Sales Tax Payable liability, with no input-tax recovery (sales tax on purchases isn't recoverable in the US); Canada models GST/HST as recoverable Input Tax Credits (VAT-style); Denmark (25% moms) and Norway (25% / 15% food MVA) use their national standard-chart numbers, with Norway keeping a distinct 15%-food revenue/VAT account. Per-tenant overrides and a provider's imported chart still refine these. Tax rates for the US/Canada remain deliberately non-auto-computed (they vary sub-nationally — defer to a tax engine/accountant); live provider sync (QuickBooks/Xero, e-conomic/Tripletex) stays gated on credentials. 10/10 registry tests (SE drift-pins intact).

• Delivery map & checkout followed a stale address. A restaurant's map coordinates were geocoded once and never refreshed, so after an owner changed their address the Delivery Area map kept centring on the old city (a Swedish restaurant showing Portland, OR) and — more seriously — the checkout delivery-radius gate measured customers against the wrong location and could reject genuinely in-area orders. Saving a new address now re-geocodes and updates the coordinates (remembering which address they came from), and the delivery-center endpoint self-heals coordinates that don't match the current address. Uses keyless Nominatim; appends the country as a disambiguation hint so a street-only address still lands in the right country.

• Settings — visible save confirmation on the General tab. Saving (e.g. after changing the address) now shows a "Saving… → Saved ✓ / Couldn't save" state right next to the Save button at the bottom of the form — previously the only confirmation was an easy-to-miss banner at the top of the page, so an owner scrolling at the Save button couldn't tell if their address change stuck.

• Delivery Area — free Google Maps + restaurant pin + address + Settings link. The delivery-zone editor now renders the free, no-key Google Maps embed keyed off the restaurant's saved address (reliably shows the restaurant + its pin — fixes the "map didn't pick up my address" case, which the OSM-tile map could leave blank), shows the address text, links to Settings → Address, and offers "Open in Google Maps". (Drawing editable/draggable circle/rectangle zones on the map needs the paid Maps JS API — a free embed can't host overlays — so rings are still sized from the restaurant via the controls; the checkout in/out-of-zone gate is unchanged.)

• Marketing logo — force the azure mark (cache-bust). The logo mark + "360" are already azure (#1570ef) in code and on the box (verified: the served /landing/restora-mark.svg is fill="#1570ef" and "360" uses --clay-500 = azure), but a browser can hold a stale ORANGE cached copy of the static SVG. Appended a ?v=azure version to the mark URL across the landing nav + footer + product demo so every client refetches the azure asset. (If the orange persists it's a separate deploy — e.g. restora360.com's standalone host — not the box.)

• Mason builder — double navbar in the page preview (builder-only; live was already correct). The editor stacked two navbars: the site-chrome mirror (MasonHeaderPreview) plus, when present, a redundant navbar/footer page-block rendered in the canvas — and the chrome mirror rendered on every page even where the live SiteHeader hides it per per-page assignment. Two builder-only fixes, live untouched: (1) MasonShell now gates MasonHeaderPreview by navbarShowsOnPage(navbar, activePage), mirroring the live SiteHeader's early-return so a page with the navbar hidden shows no chrome bar in the editor either; (2) MasonCanvas skips navbar/footer block nodes in its render (they're site chrome, already shown by the header + footer previews) while keeping their ids in children so drag-reorder indices stay aligned. tsc + eslint clean.

• Phase 56 (CC-0 cascade) — the storefront nav + sections now fully OBEY the capability switches (both ways). CC-0 shipped hiding placed blocks when a capability was off, but three gaps surfaced in testing: (1) with Table Booking off the storefront still showed the Reservations nav link + Book button and served the /reservations page; (2) with Blog on the nav still hid the Blog link when the site had no posts (the old empty-blog heuristic didn't know about the switch); (3) with Newsletter on, nothing appeared because the section was never placed — the toggle only gated existing blocks, it didn't surface a missing one. Fixes: SiteHeader now gates the Reservations + Blog nav items and the Book button by the live capability (covers legacy, redesigned, and premium templates — all use SiteHeader), with an explicit-ON override so a switched-on Blog shows even with no posts yet; /reservations returns 404 when booking is off; and the home page auto-injects a capability's section (newsletter / loyalty / gift-card) when it's ON but unplaced — mirroring the existing auto-promo-banner pattern — so ON surfaces the section and OFF hides it. Premium (art-directed) templates aren't auto-injected; owners add those sections in Mason and the switch still gates them. tsc + eslint clean.

• Phase 56 (CC-2b) — delivery zones you DRAG on an interactive map, as circle OR rectangle. Upgrades the delivery-area editor from restaurant-centred rings to fully draggable zones on a real interactive map — DeliveryZoneEditorMap, a dependency-free slippy map (raster OSM tiles + pointer-drag + zoom, no map library, so no npm/deploy/CSP risk). Each zone can be a circle (radius) or a rectangle (width×height), has its own centre (drag it anywhere), and a fee. DeliveryZone gains shape / centerLat / centerLng / widthKm / heightKm; the checkout picks the smallest zone containing the customer via feeForCustomer (rewritten pure helper, circle = haversine, rectangle = box test; test 6/6), refusing addresses outside every zone. The map also shows the restaurant pin + address + a Settings→Address link + "Open in Google Maps". (This is the free interactive map the owner asked for; Google Maps' own drawing would need a billing-enabled JS-API key, which the free embed can't do.) tsc + eslint clean.

• Phase 56 (CC-2) — geo delivery zones: draw priced rings on a map + charge by distance. A new /dashboard/delivery-zones ("Delivery Area (map)") lets the owner size concentric delivery rings on a real map — a dependency-free OpenStreetMap-tile map (DeliveryZoneMap, no map library → no SSR/CSP/dep churn) with SVG ring overlays — and set a fee per ring. At checkout the smallest ring covering the customer's address sets the surcharge, and an address beyond every ring is refused (OUTSIDE_RADIUS), reusing the coords the order already carries (customerCoords) + the restaurant's location (auto-geocoded once via a new /delivery/center endpoint). DeliveryZone gains radiusKm; the public order route now picks the fee via a pure, unit-tested geo-zone helper (5/5), replacing the old "first zone's flat fee" bug — legacy postcode zones + the single deliveryRadiusKm gate still work. tsc + eslint clean.

• Phase 56 (CC-4) — waiter table → seat → dish order entry. A new /dashboard/order screen (Operations → "Take Order (Waiter)") lets staff pick a table, choose the seat + course for each dish, and send it to the kitchen — so the right plate reaches the right person. It's pure UI over the already-complete POS stack: fetches GET /pos/menu (dishes + options + tables), builds per-line seat (0-based) + course + fireState, and submits via submitPosOrder → POST /pos/orders (source:'waiter', type:'dine-in', unpaid — settled later on the table bill), offline-safe through the outbox. Course 1 fires immediately; later courses ship as `hold` so the KDS fires them course-by-course for correct pacing — and KDS already renders "Seat N" + course, so it works end-to-end with no kitchen changes. Required dish options auto-default (a full per-option picker is a fast-follow). tsc + eslint clean.

• Phase 56 (CC-3 polish) — autopilot one-click easy-setup + "Enhance with AI". The Capabilities panel's Marketing-autopilot row now shows a Publishing mode control (Review each · Publish automatically) that sets the autopilot trust level in one click via its own config route — consent-first (stays on "Review each" until the owner chooses auto-publish), so "set it once → publishes on schedule" is a single click. And a new "Enhance with AI" button on the menu-item description field rewrites the copy via a focused /api/tenant/[id]/ai/enhance endpoint (Haiku, wallet-metered, never destructive — returns the original text if the model gives nothing), gated by the Typing-help capability. The dashboard now feeds the client the FULL live-capability set (storefront + AI), so the button only appears when Typing help is live. tsc + eslint clean.

• Phase 56 (CC-3) — the three AI features join the capability switchboard. The Capabilities panel gains an "AI & automation" group with real on/off switches for Typing help (Writing Assistant), AI content enhancement (Experience Studio) and Marketing autopilot (Social Autopilot). No parallel flags — each toggle reads/writes the feature's OWN native store via a per-capability binding: Typing help ↔ settings.writingAssistant.aiEnabled (consent-stamped like the settings route), Autopilot ↔ db.autopilot.config.enabled (via mergeAutopilotConfig), and content enhancement ↔ settings.capabilities['experience-studio'] gated into the single shared runTenantExperience core so OFF blocks AI generation across BOTH the dashboard one-click flow and the public Experience API. Availability is binding-aware (platform Writing-Assistant flag / PAID experience-studio add-on / social-autopilot feature), so the panel shows "Get it" when a tenant isn't entitled. The storefront gate (liveCapabilitySet) is deliberately scoped to the storefront group only, so page blocks never gate an AI feature. Guard test extended (16/16, incl. "blocks never gate an AI feature"); tsc + eslint clean.

• Phase 56 (CC-1 slice B) — structured per-guest pre-orders, so the kitchen prepares ahead. The /book floor flow already collected each guest's diet / drink / starter, but only flattened them into free-text on specialRequests — invisible as data. CC-1 now also persists them structurally (Reservation.guestPreferences, new ReservationGuestPreference type) and surfaces them in the owner Reservations dashboard as a per-person "Guest pre-orders" panel, so staff can have the right thing ready for the right person before the party arrives. Fully backward-compatible (the free-text summary is unchanged); tsc + eslint clean. This completes the two user-facing halves of Phase 56 request #8 (booker/notify in slice A + advance preferences here); consolidating the three create paths into one remains a deferred internal cleanup.

• Phase 56 (CC-1 slice A) — reservation confirmations to the booker + multi-recipient notify. Before CC-1 no booking path emailed the BOOKER at booking time (only the owner, and only on one of three create paths) — a guest was left unsure their request even landed. A new lib/reservations/notify.ts centralises it: on CREATE → owner email + booker "received" (pending) or "confirmed" (autoConfirm) email + staff SMS; on a status change → the booker gets the update. Guests can now add extra recipients ("Also email updates to…") — stored on Reservation.notifyEmails, server-sanitized (valid / deduped / capped at 5) and CC'd on the confirmation AND every time/place/party-size change, so a partner / organiser / PA stays in the loop. Wired into all three create paths (public/[id]/reservation, public/book/[slug], tenant/[id]/reservations) + the status PATCH, replacing the old single-recipient inline sends; new reservationReceivedEmail template. Guest form gains an optional multi-email field. Unit test 6/6 (recipient list + sanitizer); tsc + eslint clean. i18n: the new storefront field ships English-first (fast-follow). Also delivers Phase 56 request #2 (offer-table-booking toggle) — already shipped in CC-0's reservations capability gate.

• Phase 56 (CC-0) — Restaurant Control Center: the owner capability switchboard. A new owner surface (/dashboard/capabilities, sidebar "Capabilities") lets the restaurant turn features on/off, and the public storefront templates + the Mason page builder follow automatically. Architecture is reuse-first over the existing feature-gate engine and adds NO MasterDB array: a capability is LIVE only when the tenant is entitled (lib/features plan/grant/add-on) AND the owner hasn't switched it off (TenantSettings.capabilities, a tenant-scoped map; ABSENT key = ON, so every existing site is unchanged). New lib/features/block-features.ts is the single, client-safe source mapping blocks→capabilities + the owner-facing capability catalog (CC-0 set: online-ordering, table booking, loyalty, gift cards, blog, newsletter); lib/features/capabilities.ts resolves entitlement×owner-switch server-side. The cascade has one choke point each side: the SSR renderBlock hides a placed block whose capability isn't live (covers home + every data page + nested container children; fails OPEN so a DB blip never blanks a site), and the Mason palette locks the block's tile (via useTenant().capabilityLive, fed by the dashboard layout). online-ordering keeps its Phase-51 semantics (menu stays a browsable showcase; only the cart is gated — menu-full is deliberately never hidden). Toggling PATCHes /api/tenant/[id]/capabilities (entitlement-guarded: you can't switch on what you haven't bought → 402 to the Add-ons store; owner-only settings.edit) and revalidates the tenant's pages (layout mode) so the change is live immediately. Guard test (block-features.test.ts, 8/8) asserts every block→feature id and capability id is real + perTenantToggle, that every gated capability is owner-visible in the panel, and that menu-full is never gated. Brand (azure) + dashboard dark-mode guards stay green. tsc 0 across the new files. First wave of the Phase 56 plan (docs/Phase-56-Restaurant-Control-Center.md).

• Phase D (PD-5 batch 4a) — post-hoc adversarial review + hardening (the gate-context conversion made byte-parity at flip). A four-lens multi-agent adversarial review of batch 4a (9 candidates, 5 refuted with reasons — notably: multi-sub-per-tenant is NOT producible by any current write path, and the two-connection gate read is faithful parity, not a torn-read bug) surfaced three real parity gaps in the feature-gate conversion, all hardened. (1) `plan-definitions` had no pre-cutover backfill. 4a added it as a third platform_config key read by loadGateContext, but never extended backfill-platform-config-addons.mjs (still ['ai-settings','platform-settings']), so the "REQUIRED before flip" backfill left the row empty — a custom Pricing-Studio (plan_*) or DB-overridden-plan tenant would lose EVERY plan-included feature (402s / collapsed sidebar) in the window between flipping the read flags and the first live reconcile, and re-running the backfill after a live reconcile tripped its own count !== 2 verify (false "broken cutover"). The backfill KEYS list now includes plan-definitions in lockstep with PLATFORM_CONFIG_KEYS, with a banner making the lockstep a rule. (2) NULL-doc rows silently failed OPEN, not to the doc. pgGetGateContext filtered doc IS NULL subscription rows and returned subs=[] without throwing, so loadGateContext (which only falls back on a thrown error) served sub=undefined — silently stripping paid features AND flipping tenantIsReadOnly to false (bypassing requireWritable, the write guard on every route) for a tenant whose row simply wasn't backfilled yet (migration 013 adds doc nullable). (3) Multi-sub tenants diverged. doc-mode picks the array-FIRST sub via .find(); registry ordered by started_at ASC, which cannot reproduce master-array append order for a legacy/imported/hand-edited tenant with >1 row — feeding a wrong readOnly/plan decision into the write guard. Both (2) and (3) fixed at the source: pgGetGateContext now returns null (→ authoritative master-doc scan, fail-SAFE) for either anomaly, so single-sub populated-doc tenants (100% of code-produced data) serve from the registry while the rare/transitional cases defer to the doc — no new migration, no hot-path reconcile change (a lighter, lower-risk fix than an ordinal column for a data-only edge). The subscriptions backfill self-check now also asserts zero NULL docs so a partial state can't read green. Proven on scratch Postgres 16 (001→013): a new gate-context-guards test drives BOTH modes — a multi-sub tenant's readOnly matches the doc (registry deferred, did NOT pick the started_at-min stale sub), a NULL-doc row returns null, and the plan-definitions mirror is read-parity — all six suite tests green, plus the sibling registry + plans suites unchanged. tsc 0, eslint 0.

• Cross-tenant custom-domain takeover via case/port variants + PD-3 review hardening. The adversarial review of the PD-3 cut-over surfaced a pre-existing tenant-isolation bug: the owner-facing custom-domain PATCH (/api/tenant/[id]/domain) checked conflicts with strict ===, so claiming Pizza.SE passed the uniqueness check while another tenant held pizza.se — and the two normalize onto the SAME domains row in registry mode (last-write takeover). The route now canonicalizes (lowercase + port-strip, ''→null) BEFORE both the conflict check and storage, compares case-insensitively against existing docs, and runs the check+write atomically under mutateMasterDB (two concurrent claims serialize instead of both passing the read-then-write race). Two hardening fixes from the same review: (1) the /api/domains on-mode fallback now catches its own failure (both stores down → clean 503 the proxy treats as "no tenant" for its 60s cache, instead of an unhandled 500); (2) reconcileTenantRegistry defensively dedupes case-variant subdomains/custom domains — bad doc data now degrades to a loudly-logged row skip instead of a unique-index violation aborting the ENTIRE master-save transaction (the mirror must never brick platform writes). Proven on scratch PG16: 11/11 including the new bad-data test (save survives, first claimant in doc order wins, both warn lines observed). tsc 0, eslint 0.

• Onboarding wizard — exhaustive 1:1 pass against the handoff (every state, desktop + mobile). Drove both the design mockup and the live wizard through all five states — step-1 logo empty + filled, step-2 hours, provisioning, activated — at 1440px and 390px, and ran a 9-pair vision comparison. Real deviations fixed: (1) the left-rail brand lockup was hand-reconstructed (an orange app-icon nested inside a cream square + a clay-coloured "360"), reading as a doubled square — replaced with the handoff's actual restora-wordmark-light.svg asset (white rounded square + orange mark directly on it + gold #ecc049 "360" with correct spacing), a pixel-exact lockup; (2) the rail watermark now matches the handoff's placement (right/bottom, 248px, 5%); (3) the provisioning spinner span span the Restora brand mark instead of a generic storefront glyph (the handoff's restora-mark.svg at 42px); (4) the step-2 opening-hours rows overflowed the viewport on mobile (fixed 100px day label + two 104px time selects summed past 390px, clipping the closing-time select so it couldn't be tapped) — the two time selects now wrap to a full-width second line below the day + toggle at ≤560px, both fully usable; (5) a modest top-padding rebalance so the form isn't top-heavy after the (intentionally removed) sign-in header row. Verified live after the fixes (desktop lockup + provisioning mark + mobile hours all correct). Confirmed as correct-not-bugs and left unchanged: the post-register copy ("Let's finish setting up…", "a couple of quick steps"), the omitted "Sign in" link and step-1 "Back" button (account is pre-done), the extra "Finish setting up" card + "AI during trial" row + 149 kr pricing (intentional live enhancements), and the adapted provisioning task labels. tsc 0, eslint 0, 4,163 tests green.

• Nordic Table — a new light Scandinavian premium website template (7 colour combinations + demo images), built 1:1 into the one Mason/premium system. Reproduced from the design handoff as bespoke, fully-editable Mason blocks — NOT a parallel engine. Five bespoke sections (nordic-hero centred airy hero + dot-grid + wide image card; nordic-principles 3 cards; nordic-seasonal image+tag-chips split; nordic-fika image+copy split; nordic-visit info-list + booking-CTA panel) render live via the shared registry path and inline-edit in the canvas (isPreview-gated data-mason-field markers — the marker-invariant guard covers all five). Colours flow from a shared nordic-shared.ts that maps the source's 5 base tokens + color-mix derivations onto the platform 9-token contract, so any of the 7 palettes (Warm Stone · Cotton Candy · Lavender Dream · Buttercream · Powder Blue · Pistachio Cream · Peach Sorbet) re-skins the whole site; fonts are Syne (display) + Manrope (body). Ships as a code-template (nordic-table.ts, 7 palettes → 9-token themes with WCAG-luminance accentInk) + a functional starter (nordic-table-starter.ts — home = the 5 sections, menu = the real orderable menu-full as a text-only 2-column card, reservations = the real booking form, 11 seeded SEK dishes, high-quality Unsplash demo images), registered in the premium registry + catalog (Premium badge). Applying it yields a complete, orderable, bookable Scandinavian site editable in Mason. Verified: headless 1:1 render at desktop + mobile vs the reference, catalog adaptation (7 variants, correct card DTO), 577 template/mason/section/theme tests green (block counts bumped 99→104 / 82→87 static), tsc 0 for all new files.

• Phase D (PD-5 batch 4a) — the feature-gate family leaves the master doc. loadGateContext (subscription + feature grants + plan definition) backs tenantHasFeature, tenantNavFeatureSet, tenantIsReadOnly and requireWritable — the last of which runs on EVERY tenant write route — and each call parsed the whole master doc. Migration 013 converts it with the zero-drift orders-mirror pattern: subscriptions_registry gains a doc jsonb column carrying the FULL SubscriptionRecord (the content hash now covers the whole doc — any field change rewrites the row, the right trade for small low-churn subs, and the gate can never miss a field a projection forgot — proven by the trial-engine readOnly flag round-tripping), a new feature_grants_registry mirrors FULL FeatureGrant docs tenant-indexed, and the Pricing-Studio planDefinitions array becomes a third platform_config key. With SUBSCRIPTIONS_REGISTRY_READ + FEATURE_GRANTS_READ + PLATFORM_CONFIG_READ on, the whole gate context is three indexed reads; errors fall back to the doc scan; sub selection orders by started_at ASC as the append-order proxy (identical for the normal one-sub-per-tenant case). Backfill extended in lockstep (db:backfill:subscriptions-registry now fills the doc column + grants). Proven on scratch Postgres 16 (001→013): the REAL gate consumers in registry AND doc modes with parity asserted, revoked-grant delete propagation, and all suites green (12/12 + 12/12 + 5/5 + 4/4). tsc 0, eslint 0.

• Phase D (PD-5 batch 3) — users projection widened; `requireLocalizationManage` leaves the master doc. Migration 012 adds admin_role, assigned_countries (jsonb) and language to users_registry — the hash formula is bumped in lockstep in the reconciler AND the backfill, so every user row self-heals exactly once on the next reconcile with no manual step. requireLocalizationManage (the GL-9 country-manager write gate) now answers from one PK read: a HIT is trustworthy under the current-or-absent invariant, a MISS or error falls back to the doc scan. language is projected ahead of need for the dashboard-layout conversion (next batch, which still requires plan-definition + featureGrants mirrors). Proven on scratch Postgres 16 (001→012): projection round-trip including the jsonb country array + a 6-case canManageCountry parity block in the matrix suite; 12/12 + 12/12 + 4/4 regressions. Deploy note honored on the box: migrate BEFORE restart — the new reconciler writing to an unmigrated schema would drop user rows (never-brick) and fail-close logins. tsc 0, eslint 0.

• Phase D (PD-5 batch 2) — the AI-call path and the public site gate leave the master doc. Three of the highest-frequency remaining whole-doc parses converted, behind new expand mirrors (migration 011): (1) platform_config — the aiSettings and platformSettings singletons (~1KB each) mirrored out of the doc with hash-skip; an absent doc field DELETES the row, so a MISS always means "not configured", never stale — consumed by getAISettings() (one PK read) and /api/public/site-status (the proxy's 15s-cached site-gate poll); (2) addon_subscriptions_registry — the projection resolveTrialHold needs on EVERY AI budget check for a never-paid trial tenant, now two indexed EXISTS checks instead of a full doc parse, with a deliberate, documented semantic tightening: "never paid" asks whether ANY subscription has a paid status (order-independent, intent-true) instead of whichever sub the doc's .find() happened to hit first — the only divergence direction releases the hold, matching the function's own fail-open contract. All flag-gated (PLATFORM_CONFIG_TABLE/_READ, ADDON_SUBSCRIPTIONS_TABLE/_READ, SUBSCRIPTIONS_REGISTRY_READ, default OFF = byte-identical), wired into the one-transaction control-plane reconcile + the hourly self-heal cron, errors fail open to the doc scan. Proven on scratch Postgres 16 (001→011): 4/4 suite driving the REAL consumers — the site-status route handler, getAISettings, and resolveTrialHold across a 5-case billing matrix in BOTH modes with parity asserted — plus config hash-skip/delete-propagation and 12/12 + 12/12 + 4/4 regressions. Review follow-up: self-verifying db:backfill:platform-config added (named in the assertReady guards) and the REQUIRED flip ordering documented — _TABLE flags + restart → backfill (verify counts) → only then the _READ flags; a MISS means "not configured" only after the first reconcile. tsc 0, eslint 0.

• Phase D (PD-5 batch 1) — the per-request auth lookups leave the master doc. requireTenantAccess loaded and scanned the whole master doc on every tenant-staff API call (the Phase 38 revocation + sessionEpoch check — KDS/POS terminals poll this constantly) and on every group-manager cross-tenant call. With the registry read flags on (USERS_REGISTRY_READ=1, TENANT_REGISTRY_READ=1 — live on the box since the PD-3b cut-over), both branches now answer from indexed PK lookups — usersRegistryRepo.findById for the staff check, plus tenantRegistryRepo.findById in parallel for the group-manager org check — with the original doc scan kept as the fail-open fallback on registry errors and as the byte-identical flag-off path. New seam surface: pgFindUserById, RegistryTenant + pgFindTenantById, and findById on both repos. Predicate parity proven on scratch Postgres 16 across an 11-case matrix (valid staff / stale epoch / wrong staffId / wrong tenant / revoked login; manager reaching every org branch / non-org tenant / no-groupRole user / unknown user) including instant revocation propagation — an epoch bump through the real mutateMasterDB path kills the old session on the very next check. A 5-agent adversarial security review then confirmed the one deep risk — never-brick skip rows freeze stale values, and this batch made stale rows answer authorization (a frozen sessionEpoch would survive revocation; a stale organizationId could keep granting org access) — hardened before the box saw traffic on it: (1) users_registry now upholds a current-or-absent invariant — rows the reconciler can no longer keep current (malformed, duplicate email, unresolvable swap) are dropped in the same transaction, and dropping a swap party's row frees its email so the other party's retry converges (proven: one drop + one converge, then full self-heal on the next clean save); (2) the staff branch treats a registry MISS as "fall back to the doc" (ambiguous: revoked or dropped — the doc answers both correctly) while a HIT stays trustworthy; (3) the group-manager branch is deny-fast, confirm-grant: the registry short-circuits the common denial, but an org-wide GRANT is re-verified against the doc before being honored (grants are rare; the doc load lands only where it did pre-PD-5); (4) a new registry-self-heal platform cron (hourly, flag-gated, FOR UPDATE reconcile, hash-skip makes clean passes ~free) backstops swallowed mutate-path reconciles, whose log level rose to error. New matrix case proves staleness can never grant: a demote-under-duplicate leaves the row absent, never stale. 12/12 + 12/12 + 4/4 suites. tsc 0, eslint 0.

• Phase 55 (ML-2…ML-6 + guards) — the multilingual platform lands end-to-end. Continuing the two ML-0/ML-1 waves: imports prompt, never spend silently — every provider/wizard import stamps an honest translation offer (targets + pending fields + kr estimate, pure math) onto its report, rendered in the wizard (tenant-language copy), mentioned in the completion email, and one click fires the bulk engine; new tenants’ languages seed from their signup country; WoW claims persist the preview translations the prospect already paid for. Writers stopped lying about language — imports write ONE slot keyed by the DETECTED menu language (engine understands sourceLang; the tenant default became a valid machine-fill target, so a Swedish restaurant importing an English menu gets real Swedish); every editor writes the default slot and spreads the record (the product editor used to WIPE translations on every save; the SEO editor dropped locales; the Mason builder’s round-trip DESTROYED manual translations — all fixed, regression-tested). Surfaces expanded — option groups/option names, combos, blog titles/excerpts joined the translate registry + manager. The guest funnel speaks 21 languages, free — 216-key dictionary rebuilt from live strings (en source of truth, sv hand-authored, 19 generated by a native-translator agent workflow, completeness + placeholder parity validated; 199 KB committed, zero runtime AI); cart→checkout→Swish/Stripe/PayPal→confirmation→reservations→customizer wired via a layout-provided language context (SSR-safe); html lang/dir per tenant (Arabic flips RTL), Accept-Language first-visit detection, hreflang on every page, storefront chrome ×21. The dashboard nav speaks 21 languages — per-user language (profile field + PATCH /api/auth/me + header picker), all 115 sidebar labels localized at render (English labels stay stable ids), Quick-Links + search included, tenant-default fallback. Guard — a static-scan test bans new {en:X, sv:X} duplication (it immediately caught the last un-swept option-group writer, and surfaced + repaired 3 NUL-corrupted separator bytes a scripted edit had introduced in commit.ts). Verified throughout on live dev: Swedish checkout (Kassa/Din varukorg är tom), German dashboard (Übersicht/Speisekarte & Combos), dir=rtl for Arabic; tsc 0; all i18n+importer suites green.

• Phase 55 (ML-0 + ML-1) — Fully Multilingual Platform: the canonical language registry + owner-confirmed bulk content translation. First two waves of the multilingual program (owner decisions locked 2026-07-04: 21 languages = the marketing-pages 18 ∪ {es, tr} ∪ Arabic; platform CHROME will ship built-in free in every language; tenant CONTENT translation is paid from AI credit behind an estimate→confirm). ML-0: ONE registry (lib/i18n/languages.ts) replaces five divergent language lists — the AI translator's 6-language ceiling is gone (enabling Finnish/Italian/Danish… previously silently translated NOTHING), TRANSLATE_LANGS/LANGUAGE_META/the tenant Languages tab/the Translations-page names all derive from it, and the WoW preview switcher offers all 21 (six pills + a "More…" dropdown). ML-1: the auto-translate engine gained a shared runTranslationPass core (now CHUNKED — a 200-dish menu can't blow the model's output ceiling; the on-save path is behaviorally unchanged: cap-enforced, cap-counted) and a new bulk module (lib/i18n/bulk-translate.ts) covering every content surface (menu, categories, restaurant texts, Mason blocks): GET/POST /api/tenant/[tenantId]/translations/bulk returns an HONEST estimate (only fields that would actually be translated — owner-edited translations stay locked; priced per language at the real model rate + FX/markup, hold-aware wallet remaining) and runs only on explicit confirm (402 AI_BUDGET_EXCEEDED when credit can't cover it; confirmed runs bypass the small on-save monthly cap by design and are excluded from it). /dashboard/translations gained the per-language "Translate everything into …" estimate→confirm panel. Verified on live dev: demo-import tenant with de+it enabled → estimate 50 fields / 0.08 kr (hold-aware wallet remaining), confirm panel renders, and the engine fail-safes to a zero-cost no-op without an AI key (this box has none — the model call itself is the same prod-proven WoW-preview translator). 23/23 i18n tests, tsc 0. Remaining waves (import hooks, write-path correctness, chrome+dashboard dictionaries, RTL) tracked in the Phase 55 plan.

• Phase D (PD-4c) — the audit sink moves onto the append-only `audit_logs` table. Every audit event — including every failed login, which audits unauthenticated — used to rewrite the ENTIRE master doc (master.auditLogs push + full-doc save). Behind AUDIT_LOGS_TABLE (default OFF = byte-identical behavior), an audit event is now a plain INSERT into the partitioned audit_logs table (migration 007 + new 010 for doc_id + action indexes) and the master doc is not touched at all. One seam in lib/audit/log.ts carries both modes: writers (writeAuditLog, and appendAuditEntry for call sites inside an existing master mutation) and readers (queryAuditLogs paged+filtered, listRecentAuditLogs, countAuditLogs, listTenantAuditLogs, hasAuditAction) — all 12 inline master.auditLogs.push sites across 11 admin routes and all 6 readers converted (/api/admin/logs, monitoring counts, overview recent-activity, the tax-audit trail, guardian's security window, and the addon-billing cron whose reminder dedup now needs NO master write in table mode). Idempotent backfill db:backfill:audit-logs copies doc history in via doc_id WHERE NOT EXISTS (proven +2 then +0 on re-run). A 5-agent adversarial review confirmed three real gaps, all fixed before landing: (1+2) the backfill's doc_id idempotency broke on legacy cron entries whose ids were minted as audit_${Date.now()} — two same-millisecond reminders share ONE id, silently dropping history and hard-failing the reconciliation, while the post-flip re-run reconciled against ALL doc_id IS NOT NULL rows (table-born rows also carry docids → false pass). The backfill now re-mints unique docids for duplicates (no history dropped) and reconciles against the exact attempted id set (proven: a seeded duplicate-id pair lands as ..._dup1, both runs reconcile, re-run +0), and the cron's doc-mode id is now collision-free; (3) guardian's audit fetch was awaited outside its security try/catch, so a transient PG error in table mode would have broken the whole snapshot instead of degrading to seed — moved inside. Plus a NaN-page guard on /admin/logs (garbage ?page= would have become OFFSET NaN → 500 in table mode). Proven on scratch Postgres 16 (migrations 001→010): 4/4 audit suite — including the headline proof that writeAuditLog in table mode leaves the master doc's updated_at untouched, LIKE-wildcard escaping in the admin filter, and doc-mode parity with the flag off — plus the duplicate-id backfill proof and 12/12 tenant + 11/11 users/subs regressions. tsc 0, eslint 0.

• GloriaFood `demo` — professional studio dish photos + premium-template dress-up. The funnel's try-it restaurant (Demo Trattoria, mock adapter) now shows the finished product instead of a photo-less default site. (1) Photos: all 8 demo dishes carry professional studio photography — the two existing renders (margherita, pepperoni→Diavola) plus six new Imagen/Gemini renders in the same overhead wood-and-linen editorial style (quattro formaggi, carbonara, lasagne al forno, penne arrabbiata, unlabeled sparkling water, house lemonade), committed as first-party WebP under public/demo/gloriafood/ with a documented generator (scripts/demo/gloriafood-demo-images.mjs — every render passes a Gemini vision gate, and the retry re-verifies; a human visual check caught the one garbage render the first pass produced). The image pipeline gained a first-party branch: a root-relative ProviderImageRef.url is read from public/ (path-confined) instead of fetched, then localized per-tenant exactly like a provider-CDN photo — so the demo exercises the REAL photo path (sharp → WebP → dedup → /uploads/<tenant>/) with zero network. (2) Premium template: the demo snapshot is now isDemo-flagged, and the register claim path dresses the fresh tenant in the osteria-lume premium template (theme-only install, Terracotta variant — keeps the imported menu, which the template's dynamic menu page renders); fail-open and demo-only, live imports are untouched. (3) Funnel preview: /api/public/import/gloriafood returns sampleImages (first-party URLs only — provider CDN links are never hotlinked pre-auth) and the preview card leads with the 8-photo strip; the count tiles now show "8 Photos". Self-QA'd end-to-end on live dev: demo preview → register with token → 8/8 products with localized /uploads/ photos, tenantSite=osteria-lume/terracotta, storefront + menu page + funnel screenshotted and visually verified (desktop + 320px); QA tenant fully removed, importer flag restored OFF in dev. tsc 0, importer tests 18/18.

• Phase D (PD-4b) — the login read cut-over: `/api/auth/login` staged onto the users registry. The user lookup — today a whole-master-doc load + linear scan on EVERY login attempt — is staged behind USERS_REGISTRY_READ via the new UsersRegistryRepo seam: unset → the original doc scan, unchanged; shadow → the doc authenticates while the registry is compared and any disagreement logs SHADOW DIVERGENCE; 1 → the indexed registry (functional index on lower(email)) answers the lookup, so a failed login skips the per-attempt doc parse + O(n) scan for the lookup. Security posture: the registry is only the index — on a hit + password match the master doc is loaded (the route needs it anyway for the 2FA secret and tenant resolution) and RE-verified before any session is minted; registry-shaped errors fail open to the doc scan; reads require the dual-write flag. A 4-agent adversarial security review confirmed two real gaps, both fixed before landing: (1) the "failed logins never touch the doc" framing was false — writeAuditLog (fired on every failed attempt, unauthenticated) did a getMasterDB→saveMasterDB read-modify-write, i.e. a full doc parse + last-writer-wins rewrite per attempt that a flood could use to clobber concurrent legitimate master mutations; it now runs under mutateMasterDB (row-locked, serialized), the route/repo comments state the honest scope, and PD-4c (audit sink → the append-only audit_logs table from migration 007, which is what actually makes per-attempt audits cheap) is queued; (2) the fail-closed guard compared password but not email, so a stale registry email→id mapping could authenticate an email the doc no longer holds — the doc re-verify now requires password AND email to agree. Proven through the REAL login handler on scratch Postgres 16: all three modes, a source-of-truth proof (registry row deleted → 401 despite valid doc credentials; reconcile restores), fail-closed stale-hash AND stale-email proofs with repair (both LOGIN DIVERGENCE errors observed firing), case-insensitive email — 11/11 suite, 12/12 tenant regression. Scope decision recorded in TODO/design doc: SUBSCRIPTIONS_REGISTRY_READ is deferred to PD-5 because every subscription read site already holds the master doc — a lone canary there removes zero doc loads. tsc 0, eslint 0.

• Phase D (PD-4) — users + subscriptions registries: the control-plane expand goes multi-entity. master.users[] and master.subscriptions[] now dual-write into the indexed users_registry/subscriptions_registry tables (migration 007) under their own flags (USERS_REGISTRY_TABLE/SUBSCRIPTIONS_REGISTRY_TABLE, default OFF = inert), following the proven tenant-registry pattern with every hardening built in from day one: per-row content_hash skip (migration 009 — a master write that touched one user upserts one row, not all N; doc-only fields like the 2FA secret, password token and trial-engine ledger are NOT projected so they never churn rows), never-brick guards (malformed rows and case-duplicate emails — the registry enforces lower(email) uniqueness — skip with a loud warn instead of aborting the master save; garbage timestamps degrade to NULL via tsOrNull, also applied to the tenant reconcile), and delete-propagation. The write seam is generalized: saveMasterDB/mutateMasterDB now gate on anyControlPlaneRegistryEnabled() and writeMasterWithRegistry reconciles every ENABLED entity inside the one transaction — per-entity flag independence proven (users flag on + tenant flag off leaves tenant_registry untouched). New indexed reads for the future cut-overs: pgFindUserByEmail (case-insensitive via the functional index; auth-core projection incl. sessionEpoch for the Phase 38 session-kill check) and pgListSubscriptionsByTenant. Self-verifying backfills db:backfill:users-registry + db:backfill:subscriptions-registry compute the identical hashes (proven: a round-trip save after backfill re-writes 0 rows). A 5-agent adversarial review (2 lenses → refute-by-default verification) confirmed three deeper failure classes, all fixed before landing: (1) cross-row unique violations (an email/subdomain swap or reassignment across two rows in one save) could still abort the whole master-save transaction despite the batch dedupe — all three reconcilers now run delete-removed FIRST (a vacated value is free before upserts), wrap every row upsert in its own savepoint (a collision skips that row loudly, never the save), and give first-pass collisions one retry (reassignment orderings converge; a pure A↔B swap stays skipped-with-warn while the doc still commits); (2) the mutate-path reconcile had a stale-read race (doc read unlocked outside its txn could overwrite a fresher concurrent write's registry rows) — it now rides INSIDE the row-locked doc transaction via mutateDoc's existing onPersist hook, savepoint-guarded so a registry failure never fails the doc mutation, and the standalone repair tool reads the doc FOR UPDATE; (3) tsOrNull now emits the canonical ISO (JS accepts strings Postgres rejects) and pgListSubscriptionsByTenant returns ISO-8601, not Postgres text format. Proven on scratch Postgres 16 (migrations 001→009): 7/7 users/subs suite (incl. delete+re-add, within-save reassignment resolved by the retry pass, and the pure-swap degradation with both warn lines observed) + 12/12 tenant-suite regression (incl. a subdomain-reassignment case) + backfill↔dual-write hash parity for both entities with the normalized timestamps. tsc 0, eslint 0.

• Phase D (PD-3) — the first read cut-over: `/api/domains` staged onto the tenant registry. The platform's hottest read (the proxy resolves EVERY request's host through this route, 60s per-host cache) can now be served from the indexed tenant_registry/domains tables instead of loading and scanning the whole master doc, staged behind TENANT_REGISTRY_READ: unset → the original doc scan, unchanged; shadow → the doc still serves every request while the registry is read alongside and any disagreement is logged as SHADOW DIVERGENCE (the zero-divergence soak); 1 → the registry serves through the TenantRegistryRepo seam — no master-doc load at all — with the doc scan kept as a fail-open fallback on a thrown registry error. Parity with the doc scan was made exact: the registry's subdomain lookup is gated on the shared SUBDOMAIN_BASE_HOSTS allowlist (so pizzahut.evil.com does NOT resolve — the doc scan never matched foreign base hosts), subdomains are stored lowercased to match the scan's case-insensitive compare, and the {tenantId, subdomain, redirects} response contract is unchanged. Proven through the REAL route handler on scratch Postgres 16 (migrations 001→008): 9/9 integration tests covering all three modes with a source-of-truth proof per mode (registry emptied → doc still serves in off/shadow; registry row deleted → 404 in on-mode while the doc still holds the tenant), the response contract, base-host + mixed-case parity, and the shadow divergence warning observed firing live. Also captured docs/architecture/launch-cost-ladder.md — the web-verified launch-cost analysis (Stage A = Cloud SQL ~$57/mo with PITR; every migration confirmed plain PG16 SQL so stage-up to the unchanged AlloyDB end-state is a DATABASE_URL flip). tsc 0, eslint 0.

• Phase 54 — Trial Cost Shield: paid-gated Experience Studio, staged AI credit, 30-day GloriaFood trial. Three cost-protection changes for never-paid trials, owner-decided 2026-07-04. (1) Staged AI credit: the 100 kr lifetime grant is now split for NEW signups — 20 kr usable during the trial (keeps AI menu photo import + the assistant alive), the remaining 80 kr unlocks automatically on the first payment. Implemented as a trialHoldUsd stamped once with the grant (same immutability) whose application is derived at read time from billing state (lib/ai/trial-hold.ts) — any payment (Stripe webhook, DEV checkout, an add-on purchase) releases it with zero unlock hooks and zero wallet writes. Enforced at the single getBudgetStatus 402 choke every AI route already uses; top-ups are never held; existing wallets are grandfathered (no stamped hold → nothing changes). Both amounts are super-admin knobs (Admin → AI: grant + "usable during trial"). All copy surfaces updated honestly (register note now dynamic from signup-plan, both onboarding wizards, billing banner, ai-spend hero with an amber "unlocks on your first payment" pill, hold-aware 402 messages). (2) Experience Studio paid gate: during a never-paid trial the Studio stays visible — same layout, interactive style grid, a read-only "examples from the shared library" panel, prices on every (locked) button — but all six spend paths (generate, video, video-export, pool import, overage purchase, and the public API-key path) return 402 STUDIO_REQUIRES_PAID until real entitlement exists. "Paid" is a new pure rule (paidFeatureGranted in gate.ts): resolved without the trial-all-access shortcut AND plan-included features count only once the plan itself is paid (Online Starter deliberately includes the Studio per OP-14 — a trialing subscription is previewing that plan, not owning it); explicit add-on grants count immediately. The features route exposes paidGranted so the page's demo mode can never disagree with the server gate. (3) First-use billing acknowledgment: before the FIRST paid generation the owner accepts a versioned disclosure ("generations are paid from your AI credit — images from X kr, videos Y kr; delivered results are charged, true non-deliveries auto-refund"), server-enforced as 428 STUDIO_ACK_REQUIRED on generate/video-start/pool-import (tax-consent pattern clone; public API-key path exempt by design). (4) GloriaFood 30-day trial: signups carrying a live staged-import token get platformSettings.trial.importFunnelDays (default 30, admin-editable) instead of the 7-day plan trial, and the cohort is frozen as a new gloriafood acquisition channel (ranked above UTM, below partner attribution) for conversion tracking. Verified end-to-end on live dev: fresh trial stamps the 80 kr hold and 402s at exactly 20 kr spent; all six Studio endpoints 402 in trial while reads stay 200; flipping to active unlocks +80 kr and the Studio with no writes; first generate 428 → ack → real generation charged 10 SEK to the ledger; GloriaFood-funnel register → 30-day trial + gloriafood channel + menu imported + hold stamped; garbage token → 7 days, direct, signup unbroken. tsc 0; wallet/channels/importer/theme-vocabulary suites 38/38 green; QA tenants and knobs fully cleaned.

• Phase D (enterprise-scale) — first vertical slice: the tenant registry, retiring the master JSON doc. The platform control plane lives in one JSONB row (app_documents/'master', a MasterDB with tenants[] + ~35 arrays); at ~14.4 KB/tenant it OOMs Node's heap around ~40k tenants and hits Postgres's 1 GB single-field limit around ~70k, and every hostname resolution does a whole-doc load + linear master.tenants.find(). This slice moves the hottest read off the doc onto indexed relational tables without touching the ~367 doc readers, using the exact expand-phase pattern the orders/stock mirrors already ship: flag-gated, reconcile-in-the-write-transaction, doc stays source of truth, fully reversible. Shipped: migration 008_tenant_registry_content_hash.sql (adds content_hash); reconcileTenantRegistry/writeMasterWithRegistry/reconcileRegistryFromMasterDoc/pgResolveTenantByHost in pg.ts, wired into saveMasterDB/mutateMasterDB under TENANT_REGISTRY_TABLE=1 (default OFF = fully inert); an assertReady() fail-loud guard (flag on but table missing); the TenantRegistryRepo read seam (src/lib/db/repos/tenant-registry.ts, findByHost only, behind TENANT_REGISTRY_READ, not yet wired into /api/domains); and db:backfill:tenant-registry (reconciles the tables from the doc, computes the identical hash, self-verifies count). Critical at scale: the reconcile hashes only the projected tuple (routing/identity/lifecycle — a theme change does not churn the row) and skips unchanged tenants, so a master write that touched one tenant upserts one row, not all N. Proven on a throwaway Postgres 16 (migrations 001→008): the integration suite (src/lib/db/tenant-registry.it.test.ts) passes 5/5 against the REAL code paths — dual-write, subdomain + custom-domain resolution, delete-propagation, mutate-path reconcile, and the content-hash skip (identical re-save touches 0 rows) — plus a backfill↔dual-write hash-parity check. Design doc: docs/architecture/phase-d-repository-migration.md. tsc 0, eslint 0.

• Phase 53b — the public GloriaFood migration front door (pre-signup funnel). A homepage announcement band ("Import your GloriaFood restaurant" — with the April-2027 sunset urgency chip) links to the new public page /import-gloriafood: a visitor pastes their GloriaFood connection code, we fetch their menu through the official Fetch Menu API (the code is never stored — one read, then discarded), run the deterministic clean/validate pipeline, and show a live preview (count tiles + sample dishes + "worth a look" warnings). "Create my restaurant & import" carries a one-time 256-bit staged-import token into /register (restaurant name prefilled); right after the tenant is provisioned, the register route consumes the token (atomic, once) and commits the staged menu through the normal Phase 53 pipeline — completed ImportJob with report, undo snapshot, currency applied, allergens suggested-only. Strictly fail-open: an expired/consumed token never breaks signup (the owner can re-import from Menu → Import Restaurant). Staging lives in an ephemeral own-doc store (60-min TTL, consume-once, pruned, capped); the public endpoint is rate-limited (10/h/IP + global ceiling) and gated by the same importer_enabled master flag, so the band, the page and the API go live together with one flag flip. Self-QA'd on live dev: band + page render, a bad code round-trips the REAL GloriaFood API into a friendly 422, register-with-token imported the fixture menu (4 dishes/2 categories, job + report + snapshot, live allergens [] with provider allergens as suggestions), a second register with the same token imported nothing while signup still succeeded; QA tenants/users fully removed, flag restored OFF. tsc 0, importer tests 18/18.

• Phase 53 — Universal Restaurant Importer ("Import your restaurant"): one-click migration with a provider-adapter framework, GloriaFood first. A non-technical owner moves their whole menu, photos, options and details into Restora 360 in a few minutes. New nav entry Menu → Import Restaurant (with a NEW badge) opens a wizard: connect → animated scan → preview (counts + warnings + "also bring over" settings checkboxes) → Import everything → background-safe import (leave the page; the bell + an email tell you when it's done) → done + plain-language report, with one-click Undo and re-import from history. Built as a thin-adapter framework (ui/src/lib/import-providers/) cloned from the accounting-platform seam: every adapter emits the existing canonical ExtractedMenu, so the whole pipeline downstream of the snapshot reuses the proven menu-import machinery (no parallel engine). Adapters shipped: GloriaFood (official keyed Fetch Menu API — clean, consent-based; urgent because Oracle sunsets GloriaFood 2027-04-30 with no data retention), a generic website-link adapter (JSON-LD → page-text → real-browser capture, budget-gated, RIC-routed, with server-enforced ownership attestation), and the pre-existing CSV/Excel file import folded into the hub; Toast/Square/Wolt/Foodora/OrderYOYO/Qopla/Lumit ship as "coming soon" stubs that point owners at the file/website fallback (never a dead end). Pipeline: deterministic text cleanup (spacing/caps/HTML/mojibake/hidden-chars) → optional RIC-only AI description polish (digit-invariant, budget-gated, silently skipped when off) → validation + auto-repair (recover prices from price text, collapse duplicates) → never-abort image pipeline (SSRF-safe download → sharp → WebP → sha256 dedup → uploadDir(); a failed photo becomes a report line, never stops the import) → one atomic commit (snapshot-first for undo, Merge / Replace / Skip, sizes → required "Size" radio, i18n {en,sv}, fingerprint ledger for re-import) → deterministic report. Safety: live allergens/dietary tags are NEVER auto-asserted — even GloriaFood's declared allergens land only as suggestedAllergens/suggestedDietaryTags for the owner to confirm; credentials are AES-256-GCM encrypted with a GDPR TTL (24h) purged by a daily cron; no menu write outside the single row-locked mutateTenantDB commit. Master kill-switch importer_enabled (fail-safe OFF). Full en+sv wizard copy (the word "API" never shown to the owner). Verified end-to-end on the live dev app (authenticated flow connect→scan→preview→run→completed→undo restoring the menu byte-count exactly) and headlessly against a seeded tenant across all three duplicate modes + re-import-keep-local-edits + allergen-safety, all with hard assertions and the tenant restored to baseline; routes compile + enforce auth, docs article renders, dark-vocabulary guard green, tsc 0, importer tests 16/16.

• Writing Assistant — owner consent toggle for AI prediction. New always-visible consent card on Dashboard → Settings (pattern: the data-sharing card): "AI writing suggestions in text fields" writes settings.writingAssistant.aiEnabled via the settings PATCH (zod + whitelist extended). Copy is explicit that local menu/dictionary suggestions never leave the restaurant and that the AI layer sends typed field content to the model and spends AI credit. Default OFF. Live-verified: toggle persists across reload, the assistant's vocabulary endpoint flips ai:true, restored OFF after QA. This closes the "DB field with no UI" gap from the writing-assistant review batch.

• Onboarding-handoff fidelity pass (13-task program verified end-to-end + deviations fixed). Full e2e verification against the docs/Restora360 onboarding wizard handoff on the live dev app: register → /welcome/onboarding (prefilled steps, hours presets) → provisioning → completion screen (admin/public-site cards, claim-domain banner with 7-days-left chip) all work; public /book produces a real booking (reference RB-####, slot then shows Booked for the next guest); /products, /services, /plan, footer + Org.nr legal bar on every public page; KeepAccountBanner (day-4 nudge) + trial-day4 email cron present; register has no payment step. A 6-surface screenshot comparison (design vs live) confirmed the build is faithful; confirmed deviations fixed: (1) last stray 199 SEK pricing (18 languages, public /learn coming-soon FAQ) → 299; (2) SiteFooter brand column gained the spec'd App Store / Google Play badge pills (→ /services until the store listings are live); (3) onboarding rail wordmark is now the two-tone mark with white logo chip + ghosted watermark per the design; (4) table-designer top bar shows the spec'd segmented booking-context chip (date · time · covers, clock set post-mount to avoid hydration mismatch); (5) /book guests step gained the design's empty-state helper ("…we'll have them ready the moment you arrive") and the reassurance line under Confirm ("We'll confirm by email or SMS. No payment needed to reserve." — hidden for deposit venues); (6) /book floor map no longer clips owner-placed tables — the design canvas now extends to the tables' extents (was fixed 540×392). Intentional non-changes (newer owner decisions supersede the June handoff): 149 kr starter pricing on register/completion, /try funnel instead of /demo on the closing CTA, marketing nav on /plan+/services, "Your account is live!" heading.

• Premium templates (Carte/Volt) — source-fidelity polish. Carte's menu now shows the source design's per-dish indices: new menuNumbering plumbing through the starter→package→installer pipeline (TemplateStarter.menuNumbering → DemoContentBundle → applyPremiumDesign, demo-mode only like menuLayout), Carte seeds per-category, and buildStarter demo products' showNumber now follows the template's numbering intent (a hardcoded false was vetoing numbering per item). Volt's closing "Hungry?" band corrected from a full accent band to the source's surface-bg band with two-tone headline (ink + accent <em>) and accent button. Verified through the true-preview pipeline (theme-and-demo installs of carte + volt rendered via /tenant/preview_*): Carte menu = 2-col elegant + roman category numerals + "1./2." indices; Volt band matches source. (Mercato checked against its source — it has no numerals by design; Stack's band was already 1:1.)

• Platform-wide AI Writing Assistant — inline ghost-text autocomplete in every text field (Tab accepts, Esc dismisses). One client component (GhostTextAssistant, mounted once in the root layout) attaches via document-level event delegation, so every eligible <input>/<textarea> across the whole platform — menu editors, Mason inspector, marketing/email subjects, notes, admin, portals — gets suggestions with zero per-field wiring (data-assist="off" opts a field/subtree out; data-assist-context forces a context). Typing Ky shows a dim ckling after the caret → Tab (or tap, mobile) accepts → Kyckling; Esc dismisses and stays quiet for that word; arrows/Enter/IME never disturbed; ghost inherits the field's font/color so it's correct in light + tenant-dark; aria-live announces suggestions. Suggestions come from 3 layered sources: (1) a static Swedish-first dictionary (lib/writing-assistant/dictionaries — sv derived from the shared SV_EN_FOOD map + curated menu staples/allergens/marketing phrases like "beställ nu"/"gratis leverans", en equivalents; per-language files, trivially extendable), (2) the tenant's own vocabulary via GET /api/dashboard/writing-assistant/vocabulary (product/category/option/ingredient/inventory names, ≤800 ranked entries, session-scoped, 5-min client cache) which outranks the dictionary, and (3) POST /api/dashboard/writing-assistant/predict — a capped Haiku completion (RIC cutover, max_tokens 24, wallet-metered under a new writing-assistant AI feature, 402 on empty wallet, requireRateLimit 30/60s) used ONLY when local sources miss in description/marketing contexts (never notes — PII posture), tenant-opt-in via settings.writingAssistant.aiEnabled (default OFF; typed content goes to the model, so consent is explicit), debounced + session-capped + cached. Local suggestions are pure in-memory prefix search (<1 ms; the engine, field-context classifier and vocabulary extractor are DOM-free with 30 unit tests). Field-context heuristics boost the right vocabulary (ingredients vs marketing …) and a sensitivity filter hard-skips passwords/emails/phones/addresses/names/codes/prices; accepted words are learned per-browser (localStorage frequency boost). Zero cost until a text field is focused (dictionaries dynamic-import + one cached fetch on first focus). Gated by the writing-assistant feature flag (dev = on, prod = off until the super-admin flips it; WRITING_ASSISTANT_ENABLED env override). Both routes live-re-verify the session via requireTenantAccess (revoked staff/designer cookies get the anonymous payload / no AI). Hardened by a 27-agent adversarial review (14 confirmed findings fixed): AI completions clamp to maxLength (+ the native-setter insert path enforces the cap browsers skip on programmatic sets), AI ghost respects caret-at-end (no mid-edit Tab hijack), one-shot boot failures self-heal after a 30 s cooldown, no persistent vocab cache (cross-account residue on shared devices), per-tenant learning keys, aria-live debounced + cleared on hide, typeahead-owning fields excluded (role=combobox/aria-autocomplete + data-assist="off" on the ingredients editor & nutrition search), owner ai-spend page labels the new feature. Verified vs the live dev app (Playwright/Edge): ghost render + Tab-accept in the product editor name input, phrase completion in the description textarea ("gratis lev" → "gratis leverans"), Esc swallowed (modal stays open) + same-word suppression, dark-mode color parity, mobile (Pixel 7) tap-accept — re-run green after the review fixes; tsc 0, eslint 0, 4,163 tests green.

• FSN reposts — members can repost posts and reels to their followers (owner request), web + native. Model/server: FsnPost.repostOfId always points at the ROOT original (reposting a repost resolves to it — rows never chain) + a denormalised repostCount; pure rules in lib/fsn/repost.ts (6 tests): PUBLIC+active originals only (a followers-only/private post can never be re-broadcast), one active repost per member per original (idempotent toggle), and repostVisible filters every listing so a repost row vanishes the moment its original is deleted/removed/hidden or its author is blocked — no ghost cards. POST/DELETE /api/fsn/posts/[id]/repost (rate-limited, block-aware with the same 404 anti-oracle as like/save, repost notification to the original author — new verb+icon on web and native notification lists). Hydration embeds the fully-hydrated original as PublicPost.repostOf (depth 1 guaranteed) + viewer.reposted; author-deleting a repost row returns the count via cascadePostDelete. Web: feed/post-list cards render a "↻ X reposted · when" banner over the ORIGINAL author's full card, with like/comment/save/repost bound to the original's id (updatePostInList keeps optimistic state in sync when the same original appears twice); Repeat2 toggle (pine when active) with live count; profile tiles label reposts ("Repost · original author") and tile-delete deletes the repost ROW (un-repost); /fsn/post/<repostId> redirects to the original. Native (`:fsn`): the same banner + Repeat action on Home feed cards (FeedPost.interactionId binds all interactions to the original), a Repeat rail button on Reels with optimistic count (repost rows never enter the reels pager — video-only originals), and profile grids show the original's media for repost tiles. Verified: 19 lib tests, tsc 0, live e2e vs the dev server (repost 201 → idempotent 200 → repost-of-the-repost resolves to root → un-repost → 404 on bogus id), Playwright feed screenshot (banner + count sync between the repost row and the original), :fsn:assembleDebug green. On-device visual pass queued for the next phone unlock.

• FSN CV system — a real job-seeker CV on the talent profile (owner request), web + native + LinkedIn import. Self-declared CV on TalentProfile: introduction (≤800), birth year (stored privately, only the derived AGE is ever exposed publicly), gender, up to 6 social/portfolio links (http(s)-only), and up to 20 job experiences with YYYY-MM date ranges (open end = "now"; sorted current-first then newest-first) — all validated/normalised in pure lib/fsn/cv.ts (8 tests). PATCH /api/fsn/me/profile extended (empty/null clears a field); LinkedIn import via POST /api/fsn/me/cv-import parses the official member-data-export Positions.csv and MERGES (dedup by company+title+start) — honest scope: LinkedIn offers no profile-read API without a partner app, and the UI copy says exactly that. Web: a "CV & job history" editor card on the account page (FsnCvEditor: links/experiences CRUD + CSV upload) and the public talent page renders About / Experience timeline / Details (Age · Gender · Location) / Links (nofollow). Native (`:fsn`): a "CV & job history" entry card on the own profile opens a full CvEditorSheet (drag-dismissable, 0.94 height, keyboard-aware; same fields + CSV import via the system file picker), and OtherProfileScreen renders the same About/Experience/Details/Links blocks. Verified e2e vs the dev server (save all fields → current-job-first ordering → CSV import "parsed 2 / added 1" → public endpoint exposes age 31, never the birth year) and on-device UAT on the S24 (editor save → DB inspection → prefill on reopen → another member's CV renders). tsc 0; 123 FSN lib tests; :fsn:assembleDebug green.

• FSN account lifecycle — deactivate + 90-day-grace deletion (owner request), web + native. lib/fsn/account-lifecycle.ts (6 tests): Deactivate = reversible status:'disabled' (profile/posts/comments vanish everywhere via the existing hidden-author machinery, sessions killed); signing back in reactivates. Delete = disabled + deletionRequestedAt + a 90-day grace window — sign in within 90 days and the deletion is CANCELLED (both web login and the app bridge reactivate + toast "welcome back / deletion cancelled"); after 90 days the account is fully erased on next touch (the hardened Wave-1 eraseAccount cascade + uploads directory removal) — enforced by a lazy purge at login (the guarantee on a box with no scheduler) plus a vercel.json cron GET /api/cron/fsn-account-purge (CRON_SECRET-gated) as the scheduled sweep. POST /api/fsn/me/deactivate + DELETE /api/fsn/me now schedules instead of instant-erasing ({scheduled:true, graceDays:90}). Settings UIs on web + native gained a Deactivate section and the delete flow states the 90-day terms. Verified: 8/8 lifecycle e2e checks vs the dev server (deactivate → hidden + 401 → login reactivates with fresh status; delete → schedule → login cancels; a past-due account purges at login with uploads gone). One cosmetic fix found by e2e: the reactivation login used to echo the stale disabled status in its response.

• FSN dark mode → admin-panel slate (owner request: "black and grey like the admin panel, not brownish"), web + native. The FSN dark palette (web r360-theme.css dark block + native DarkScheme in Color.kt) moves from the warm clay-brown family to the super-admin midnight-slate family: #0a0f1a canvas / #121a2a cards / #0e1522 insets / slate borders + cool text ramps; reels/tab/scrim constants and the toast/plan-card surfaces follow (InkSurface/InkSurfaceDeep). The clay brand accent (buttons, active states, badges) is kept on purpose — surfaces are neutral, brand stays warm. Light mode untouched, pinned by the light-values-unchanged check. On-device visual pass done on the S24 (home feed, reels, profile all slate; no brown surfaces). The "Order · X kr" button on the recipe sheet and the "Order on Food Bazar" CTA on a sponsored reel used to call app.order(dishId), which stuffed a SampleData bazar-hero into state and navigated to the Kitchen tab — which no longer consumes it, so the dish was silently dropped (and the BazarScreen / HandoffSheet it once fed are unreachable dead code). Both CTAs now open the real web Food Bazar searched for the dish (/bazar?q=<dish> via an ACTION_VIEW intent), the exact pattern the dish-detail sheet's "Browse Food Bazar" already uses — verified the route resolves (200). New shared openBazarSearch(context, query) helper next to shareFsnPost. :fsn:assembleDebug green. (The dead order()/openHandoff()/BazarScreen/HandoffSheet chain is now fully orphaned — left in place, safe to delete in a later cleanup.)

• FSN native app Wave 4 — design-conformance polish (audit theme D). Android-only (`:fsn`), no server change. Dark mode fixed on the feed & profile: every feed card, header, comment sheet, and profile screen used raw static Stone constants (Stone700/600/500/400) as icon/text colors on theme-reactive surfaces (SurfaceCard/HeaderBg go dark in dark mode) — so in dark mode the icons and secondary text were near-invisible dark-on-dark. All of them now use the reactive tokens (TextDefault / TextMuted / TextSubtle) the rest of the app already uses, so they adapt to the theme (light-mode values verified unchanged). Nav-bar inset: the shared ModalSheet now applies navigationBarsPadding() to its content, so every sheet's footer CTAs and the comments composer clear the system nav bar on edge-to-edge devices (the sheet surface still paints to the edge); removed 3 now-redundant inner paddings. Status bar over dark overlays: the video editor, publish step, and full-screen post viewer now get light system-bar icons (the clock was invisible-dark over them in light mode). Emoji removed from live UI (design system bans them): the Global Kitchen globe + country-flag emoji → plain country names, the dish-detail ←/→ ASCII arrows → Chevron/Arrow Lucide icons, "Applied ✓" → a check-circle icon + "Applied", and the redundant "✓" in the "Posted" toasts (the toast already renders a check icon). Accessibility: the pine/clay toggle now carries Role.Switch so TalkBack announces on/off instead of a generic button. :fsn:assembleDebug green. Left intentionally: the region/language picker flags (a standard picker pattern that was in the 1:1 handoff), an orphaned rating-star glyph in the dead BazarScreen, and the nice-to-have Geist-Mono-number / off-token-color touches on the always-dark day-plan card. On-device dark-mode visual pass pending the S24 reconnecting (the token remap targets the same reactive tokens the app's dark mode already uses successfully everywhere else).

• FSN native app Wave 2.1 + 3.1 + bottom-sheet UX — honest list states, profile follow-ons, and two owner-reported sheet fixes. All Android-side (:fsn) plus two small additive server fields; on-device verified on the Galaxy S24. Wave 2.1 (honest error/retry on the remaining lists): Notifications, the DM inbox, the Jobs board and Search now show a "Couldn't load — Retry" card when the server is unreachable instead of a misleading empty state (a new generic FsnApi.Loaded<T> result — the feed's old FeedLoad generalised — distinguishes empty from unreachable). Also fixed the DM inbox 30s poll silently wiping a populated inbox to "No messages yet" on a transient failure, and the dead DM-compose "tap to retry" path (suggested-people failures now actually surface it). Wave 3.1 (profile follow-ons): comments now carry the author's account id (additive PublicComment.author.accountId), so tapping a commenter opens their profile; the follower / following counts are tappable on any profile (own + others) → a list overlay backed by a new GET /api/fsn/accounts/[id]/follows?type= (each row → that person's profile + inline Follow); and the profile Message button opens straight into the DM thread instead of the inbox. Owner-reported sheet UX (fixed in the shared `ModalSheet`): every bottom sheet now has a drag handle and swipe-down-to-dismiss (drag past ~120dp releases, else springs back), and the Edit-profile sheet is tall + scrollable + keyboard-aware (imePadding) so the whole form and Save button stay reachable — it was cut off before. Also fixed an overlay z-order bug so the ⋯ report/block sheet and a follow-list-row tap render on top of the profile instead of underneath it. Verified: the two new endpoints e2e (comment carries accountId; follows returns the right people + viewer follow-state + 404 on unknown); on-device on the S24 (edit-profile full window + Save reachable with keyboard, swipe-down closes a sheet, tap author → profile, tap following count → list → tap row → that profile). tsc 0; 109/109 FSN tests; :fsn:assembleDebug green. Deferred: a direct comment-handle tap target (the avatar is the tap target today), and pull-to-refresh.

• FSN native app Wave 3 — flows: fixed the one-shot video creator + a view-other-user profile screen (audit theme B + E). Video creator second-run bug fixed: VideoEditorViewModel and PublishViewModel are Activity-scoped and SURVIVED across creator opens, so a second video kept the first clip's trim/overlays/music and its already-consumed (deleted) export/file, re-firing onExported/onPosted with a dangling path — and reopening the publish step with a leftover posted=true instantly fired a fake "Posted". Both VMs now rebind when a different clip arrives (full reset) and no-op when the same clip is re-shown (edits preserved); exported/posted are consumed as one-shots so a re-entered editor/publish can't replay them. View another member's profile (the audit's dead-ended core social loop): new GET /api/fsn/accounts/[accountId] returns a public profile (name / handle / avatar / verified / real post·follower·following counts + the viewer's follow state; blocked-either-way → 404 with no oracle, matching the feed) and a native OtherProfileScreen overlay renders it with the post grid, Follow / Message, and a ⋯ report/block. Tapping an author now opens it from the feed (author row), Reels (creator row), and search results — before, tapping a name did nothing anywhere in the app. Message starts-or-opens the DM thread; Follow is optimistic (reverts on failure). Verified: the endpoint e2e vs the dev server (view → follow flips followers 0→1 + viewer.following, self → isSelf:true, unknown → 404); on-device on the S24 (tap feed author → profile with real counts → Follow flips to Following → Back returns to feed). tsc 0; :fsn:assembleDebug green. Deferred: comment-author taps (the comments API doesn't return an account id yet) and tappable follower/following LIST overlays.

• FSN native app Wave 2 — trust: no fake data on signed-in surfaces + honest error/retry states (audit themes A + C). All Android-side (:fsn), no server change; verified on the Galaxy S24. Honest load states: the Home feed and Reels no longer start on SampleData — they show a loading spinner, then real posts, a genuine empty state, or (new) a "Couldn't load — Retry" card when the server is unreachable, instead of silently sticking fake "Bella Forno / Green Bowl" posts on screen forever (a new FsnApi.discoverFeed(): FeedLoad.Ok|Failed result distinguishes empty from unreachable; a shared ErrorRetry composable + FeedPhase drive it). Sample data purged from the signed-in profile: "Share profile" now shares the member's REAL account URL (/fsn/talent/{accountId}, matching web FsnShell) instead of the sample @elin.eats link that 404'd — and prompts sign-up when signed out rather than sharing a stranger's profile; the "Open to restaurant work" card shows the member's REAL city (or an "Add area" CTA) and hides the "Roles & availability" row entirely (no server field yet), instead of presenting sample "Stockholm/Uppsala · Barista/Line cook" as the user's own hiring profile; the previously dead ✕ / "Add area" chips now act (✕ only shows when removal is wired; "Add area" opens edit); the Saved tab is real (GET /api/fsn/saved) with a proper "No saved posts yet" empty state instead of being permanently blank; and a transient /me failure keeps the last-known real identity instead of flipping the whole profile to the sample persona. Create sheet is honest: the fake pre-filled attachments ("Margherita", "640 kcal · 25 min", "Stockholm") are gone — the recipe/nutrition/location rows read "Optional" and answer taps with "Coming soon"; the "Let viewers order this" toggle (which never actually attached to the post) is removed. Interaction polish: system Back now dismisses any ModalSheet and the Photo Studio (was falling through to the hidden tab / exiting the app); edit-profile and avatar-upload failures keep the sheet open and warn instead of silently discarding edits; and error toasts show an amber alert icon, never a green success check (ToastPill(isError)). Verified on-device (S24, via `adb reverse` to the dev server): feed loads with no sample flash; kill the connection → error+retry card (not fake posts) → Retry recovers; Create sheet shows "Optional" + no order toggle; Back closes the Create sheet; signed-in open-to-work shows only "Add area" (no sample cities/roles); Saved tab shows the real empty state. :fsn:assembleDebug green. Deferred to a follow-up: the DM/notifications/jobs/search list surfaces still swallow failures into friendly empty states (nice-to-have Result refactor), and the orphaned recipe→Bazar order chain.

• FSN native app Wave 1 — account + policy foundation (from the 69-finding polish audit, `docs/products/food-stories-network/native-app-polish-audit-2026-07-03.md`). The :fsn Android app finally uses the auth/moderation backend the web already had. Sign-in: the onboarding overlay gains a "Already have an account? Sign in" mode over POST /api/fsn/login incl. the two-step TOTP/backup-code branch — before this the app could only register, so a logged-out user was locked out of their account forever; the wizard VM is now epoch-keyed per open so it never resumes a stale step. Dead-session detection: one OkHttp interceptor on a new process-wide shared client (replaces ~13 per-ViewModel clients) — any 401 riding a session cookie flips the app to signed-out with one honest "session expired" toast (login/register excluded; wrong current-password is a 400 so it can't trip it). Log out now actually revokes the device's session server-side (POST /api/fsn/logout) — proven by replaying the raw cookie → 401. Report + block (Google Play UGC requirements): the dead ⋯ kebab on feed cards and a new More rail button on Reels open a ModerationSheet — report post/account (6 reasons + optional details → the existing Super-Admin moderation queue) and block (mutual invisibility; blocked authors vanish from feed/reels instantly via a new reactive ModerationStore seeded from GET /api/fsn/block, and the server excludes them from every later load). The dead Reels search icon now opens Search. Settings → Privacy & security is real: change password, blocked-accounts list with unblock, and two-step-confirmed permanent account deletion (Play account-deletion requirement); the fake "Connected accounts · 3 linked" badge is gone. Server: `DELETE /api/fsn/me` erasure hardened — extracted to pure lib/fsn/account-erase.ts (7 tests): owned posts now get the full cascadePostDelete (video/recipe/article scrub, count zeroing, edge drops, media-ledger reclaim, report auto-resolution) instead of the old light scrub, plus the previously-missed collections: media-ledger rows (avatar/unattached), saved meals, the subject's support tickets, connected social accounts (encrypted OAuth token blobs destroyed), cross-post records, DM bodies + read receipts (the other participant's own messages are kept — their correspondence), open reports about the account (resolution account-deleted; reports by the subject stay for moderation accountability), BOTH talent-profile link directions (incl. avatarUrl), and 2FA secrets + the platform bridge link on the account record. Verified vs real conditions: 18/18 live e2e checks on the dev app (register → logout-revoke replay 401 → login → wrong-password 401 → block/list/unblock → report account+post → delete → dead cookie + deleted-account login both 401) plus a DB-level erasure inspection (account pseudonymised, sessions/blocks/media rows 0, report-about auto-resolved, other users untouched); :fsn:assembleDebug green; tsc 0; 109/109 FSN lib tests. On-device UAT of the new sheets still pending (S24).

• True theme preview — "Preview with demo content" now opens a live preview in a new tab WITHOUT touching the owner's site (owner report: the old button actually installed). New POST /api/tenant/[id]/themes/preview: clones the tenant DB in memory, runs the exact same applyInstall a real install runs (demo or my-content mode), and stashes the clone in an ephemeral store (lib/themes/preview-store.ts, unguessable preview_<hex> ids, 30-min TTL, per-tenant eviction + 200-entry cap, globalThis-anchored so the API and page bundles share one store). getTenantDB intercepts preview_ ids and returns the clone, so the preview renders through the REAL storefront path — what you see is exactly what installing would produce, with the theme's 9-token palette, demo menu, chrome, everything. Preview pages carry a sticky "nothing here is saved" banner and are noindex; unknown/expired ids 404. Catalog card buttons reworked: primary Preview (opens the new tab; demo content when the pack has it), secondary Use with my content / Use demo content installs (both still snapshot-undoable). Two real defects found by the E2E and fixed: (1) plain-string product names (what AI-authored demo menus naturally contain) rendered as their FIRST CHARACTER everywhere — translate() fell through to text[Object.keys(text)[0]]; demo menu names/descriptions are now normalized to the canonical {en:…} shape at package parse AND translate() accepts strings (defense-in-depth); (2) a hung dev-server compile had poisoned .next, masking the new route (cache cleared). Verified vs the live dev app — 13/13 E2E checks: preview renders themed demo content + banner + noindex; the REAL site's blocks/HTML byte-stable throughout; theme-only preview themed without demo data; bogus preview id 404s; unauthenticated preview 401s. tsc 0; eslint 0; package+i18n suites green.

• Theme packages carry real images now — ZIP binary assets with sharp re-encode (Phase 32 P1 follow-up), plus demo media seeding. A theme ZIP can bundle images under assets/ and reference them from blocks/demo content as asset:<path> — the missing piece for fully self-contained (incl. AI-authored) template packages. Import: bounded raw reads (3MB×40 caps) → sharp decode + re-encode (auto-rotate, ≤2400px, WebP) so polyglot files, embedded payloads and EXIF never survive to storage — a non-decodable image becomes a warning, never a package failure; the integrity contentHash now covers asset bytes (a tampered image fails the check, pinned by test); safeImportUrl accepts the strict internal asset: shape (it silently blanked such refs before). At the storage boundary (admin catalog upload + tenant one-off upload) new persistPackageAssets writes each image to /uploads/theme-packages/<slug>/<name>-<sha10>.webp (content-addressed, so a changed image never overwrites a file an installed site is serving) and deep-rewrites every asset: reference to the public URL — catalog, installer and storefront deal in plain URLs and stored packages stay small. Demo media: Install+Demo now registers the pack's gallery + dish photos in the tenant's media library (db.media, source demo, idempotent by URL) so the media picker isn't empty after installing a demo restaurant. E2E-proven against the live dev app — the full "AI-designed theme" loop: a hand-assembled ZIP (manifest + template referencing asset:hero.png + a real PNG) → admin upload (re-encoded, persisted, refs rewritten, 0 warnings) → owner installs from the catalog → the live site serves the persisted webp (200, image/webp) with {{restaurant.name}} resolved and no raw asset: refs leaked → snapshot revert restores the site → catalog cleanup. 41/41 theme-package tests (6 new); tsc 0; eslint 0 errors. Plus the AI Theme Designer Kit: npm run theme:catalog (generates docs/theme-kit/BLOCK-CATALOG.md from the live SectionRegistry — 99 block types with their exact content keys) and npm run theme:validate <zip> (the real parsePackageZip + authoring lint: unknown types/keys with did-you-mean, unresolved asset: refs, unknown {{tags}}, partial palettes; verified on seeded-broken and correct ZIPs), tied together by the new theme-designer skill (ui/.claude/skills/theme-designer/SKILL.md) so "design me a theme" requests in Claude Code author validated, admin-uploadable packages.

• Mason builder Stage-2 container nesting (MNEST-2/3/4a) — the 5 layout containers (Columns / Grid / Stack / Container / Section) hold real nested child elements, end to end. The data layer (adapter content.children round-trip + cycle-guarded tree ops) already existed; this ships render + editing. Render (MNEST-2): the container components take a childrenSlot — with children, the children become the grid cells / stacked items (fixed demo slots + preview placeholders suppressed); without, they render exactly as before, so every existing page stays byte-identical (pinned by a new render test). Children render recursively through the SHARED SectionRegistry in BOTH the live BlockRenderer and the editor MasonCanvas (no editor/live drift; a nested data-bound block still gets live data), gated on a non-empty array + MAX_NESTED_DEPTH=5. Editing (MNEST-3): a "+ Add inside" chip on any selected container opens the palette in add-into mode (amber banner, cancellable) and inserts via the tested insertNodeInto; nested nodes are click-selectable, inline-editable and inspector-edited on the canvas; the Layers panel shows the subtree indented with child counts (tree-safe hide/duplicate/delete). duplicateNode is now tree-aware and deep-clones subtrees with fresh ids — the old root-only version would have placed a nested duplicate at page root and aliased a duplicated container's children to the original's. Drag (MNEST-4a): children drag-reorder within their container (nested SortableContext → moveNodeTo; over-item original-index semantics pinned by test); cross-container drag stays deferred (MNEST-4b). Load-bearing fix found by the live UAT: REGISTRY_RENDERED_BLOCKS was a stale hand-kept allowlist, so every newer palette element (card, badge, table, avatar, accordion, forms, mobile, commerce, the containers themselves…) rendered as NOTHING on the live site — visible in the editor, invisible after publish. It's now derived from the SectionRegistry minus the 18 switch-rendered data types, so all 86 palette elements are publish-real (registry components are publish-safe by design; the marker test enforces editor-only attributes never reach live output). Verified against the live dev app: full UI loop (add Columns → Add inside Card + Badge → nested selection → Save → live page renders the nested layout themed → no editor markers in live HTML → delete → live back to baseline) plus an API-level persist/render/restore probe. tsc 0 · eslint 0 errors · 437 mason/section tests.

• Cookie banner upgraded from binary to a small per-category CMP (GDPR/ePrivacy). The consent cookie (cookie_consent) now stores per-category choices — new v2 format v2:analytics,marketing / v2: (percent-encoded on write; RFC 6265-safe) — with legacy values kept readable (all → both granted, essential → both declined), so existing visitors keep their choice. lib/consent/consent.ts gains ConsentState (necessary always on), hasAnalyticsConsent() alongside hasMarketingConsent() (name + semantics preserved), serializeConsent/consentAll/consentNone; parseConsent/readConsentFromCookieString return the category object and never throw on malformed cookies. Banner (ConsentBanner): three equally-prominent actions — Reject non-essential, Accept all (identical size/weight — no dark-pattern nudge) and Choose, which expands inline Analytics/Marketing toggles with Save choices; DNT/GPC still hides the banner and declines everything non-essential; kiosk/TV/table-assistant exclusions unchanged; CONSENT_EVENT still fires so capture components re-init. Withdrawal path: new reopenConsentBanner() + CookieSettingsLink — "Cookie settings" links in the landing footers (landing/Footer, landing-v2/LandingFooter, whose dead # Terms/Privacy/Cookies links now point at /legal/*) and the tenant storefront footer (all 3 SiteFooterView variants) re-open the banner pre-filled even when a choice cookie exists. Consumers re-gated per category: ANALYTICS → RIE (RieAnalytics, sdk.analyticsConsented) and /api/track (which now also checks the consent cookie server-side + honors GPC, not just the client flag); MARKETING → AcquisitionCapture, /api/public/track-acquisition, /g/[id] tracked-link redirect, referral capture (all unchanged via the preserved hasMarketingConsent). Verified vs real conditions: 19-check Playwright E2E on the live dev app (fresh visitor, per-category save, cookie values, reopen pre-fill, legacy-cookie compat, tenant footer) + live curl checks of both API gates (analytics-only cookie stores on /api/track but not track-acquisition, marketing-only the reverse, GPC blocks both) + tsc 0 + 4,057/4,057 tests.

• Admin Staff: creating an admin actually works now — invite email + choose-your-own-password + forgot-password (owner report: "not able to create super admin"). Root cause: POST /api/admin/staff stored the new admin with an EMPTY passwordHash and sent nothing, so the person could never log in — and the staff page swallowed every API error silently (a 409 duplicate-email looked like a dead Create button). Rebuilt as a proper invite flow: creating an admin issues a one-time set-password token (only the SHA-256 hash is stored — new UserRecord.passwordToken, additive; invite 7 days / reset 1 hour, single-use, re-issue replaces) and sends a branded email linking to the new public `/admin/set-password` page (fixed-dark, styled like /admin/login; added to the vocabulary-test FILEALLOWLIST as the same documented exception class as the login page). **Forgot password:** "Forgot your password?" on `/admin/login` → `POST /api/admin/auth/forgot-password` (rate-limited 3/15 min, always-200 anti-enumeration, matches superadmin accounts only; dev returns `devSetupUrl mirroring the customer flow). **Resend:** per-row mail button → POST /api/admin/staff/[userId]/invite (fresh invite while unactivated; admin-issued reset once active). Create/resend return the setup link to the calling super-admin as a deliberate copy-link escape hatch when SMTP isn't configured; emailed links resolve from APP_URL in production (request origin honoured only outside prod so a spoofed Host header can't poison reset links). Staff UI: inline create errors, invite-sent banner with Copy link, new Status column (Active / Invite pending / Invite expired), legacy no-adminRole admins now display as **Super Admin** (they were mislabeled "Support" — they authenticate as full superadmins), and the page's native confirm()/alert() were converted to the themed confirmDialog()/inline errors. API responses expose passwordSet/invitePending and strip passwordToken`/2FA material. Verified vs the live dev app: 28/28 API checks (create→invite link→set password→real login; token replay rejected; weak password 400; wrong password 401; reset rotates the password and kills the old one; unknown/tenant-owner emails leak nothing; unauth calls 401) plus a Playwright visual pass — staff page in BOTH admin modes, set-password form/mismatch/success/expired states, login forgot flow, and a real UI sign-in by the invited admin. tsc 0; vocabulary test green.

• Landing nav restructured around "Try Free" (owner request). "Experience Center" is renamed Try Free and now also absorbs the former top-level "Before & After" link. Dropdown items renamed to say what you get: Import your menu (WoW experience), Import your website (Before & After), Table designer, Check your site free (Site health check), Free 7-day trial (Onboarding); Free demo unchanged. Top-level "Services" renamed Products (still /services — note a separate /products marketing page also exists, only linked from /plan; pointing the nav there is an open owner call). "Help" and "About us" dropped from the nav — they live in the footer, whose dead # links are now wired for real: Help center → /help, About Restora → /about, Contact us → /contact; footer "Before & After" renamed to match ("Import your website"). All hrefs unchanged otherwise; mobile accordion uses the same NAV array so it picks the change up automatically.

• RIC Phase 1.5 W8 (buildable half) — manage RIC's config from r360 instead of the CLI. RIC's model-routing/pricing config was previously editable only via pnpm mrr + raw SQL. New server-side client lib/ric/admin.ts (ricAdminGetConfig/ricAdminPutRouting, using a separate platform-admin RIC_ADMIN_KEY kept server-side) + a super-admin proxy GET/POST /api/admin/ric-config let the operator READ RIC's live providers/price-cards/routing-rules (credentials never returned — only hasCredential) and edit a routing rule (which model chain serves a taskClass) without a deploy — the edit hot-reloads on RIC within ~10s. The r360 session gates access; the RIC platform key never reaches the browser. Verified end-to-end against a live RIC: the client read the full config (no credential ciphertext) and upserted a routing rule that landed on read-back. Deliberately deferred (documented in the RIC repo's docs/phase-1.5): the admin UI page, provider-credential/price-card writes (credentials don't hot-reload — need a restart story), and the per-capability↔per-task-class config-model reconciliation. Not touched: retiring the local lib/ai provider registry + inline-prompt fallbacks stays gated on 30 clean production shadow-days — those are the safety net until RIC is proven live.

• RIC Phase 1.5 W7 — RIC gateway alerts become Guardian incidents. New inbound webhook POST /api/admin/guardian/ric-alert: RIC's worker posts health alerts (error-rate, DLQ) and a new per-tenant AI-spend anomaly (a tenant spending >3× its trailing-7-day daily baseline, with absolute + baseline noise floors so tiny tenants never page) to this endpoint, HMAC-signed (x-ric-signature: sha256=…, shared RIC_ALERT_SECRET/ALERT_WEBHOOK_SECRET). The receiver verifies the signature timing-safely (fail-closed: no secret or bad signature falls through to a super-admin session, so a leaked URL can't forge incidents), maps the alert to a Guardian incident candidate (lib/guardian/ric-alert.ts: RIC warning→P3, critical→P2, source integration, a stable per-rule + per-tenant fingerprint so a sustained condition folds into ONE incident via reconcileIncidents instead of one per RIC tick), and persists it into guardianIncidents; Guardian's existing alerting/paging then escalates on the next probe cycle. The RIC→r360 direction is a push webhook because the existing ADR-17 channel only flows r360→RIC (RIC pulls r360's events, never the reverse). Verified end-to-end against real conditions: the actual route handler with a genuinely RIC-signed spend-anomaly body created a P2 incident, a repeat folded (deduped, no duplicate), and a forged signature was refused (scripts/w7-alert-demo.ts); plus unit tests for the HMAC round-trip, severity mapping, per-tenant dedup, and payload validation. Alerting stays OFF until the shared secret + webhook URL are set on both sides.

• RIC Phase 1.5 W5 (started) — prompts move into RIC's versioned registry (edit + roll back without an r360 deploy). New harness helper runPromptRefCutover (lib/ric/narrate.ts, the 6th cutover shape): instead of sending the prompt text inline, a site sends promptRef: { key, variables, attachments? } and RIC renders the registered template server-side, runs it, and returns the text/forced-tool object — same off/shadow/live semantics and the site's inline prompt stays as the OFF/fallback path (retired only in W8). RIC-side, promptRef was extended to carry image/PDF attachments so vision prompts (menu extraction, Food-DNA) can be registry-managed too, not just text. First cutover: WoW clone-copy (lib/wow/clone-copy.ts) — the inline copyPrompt is refactored so a single copyVars(dna) feeds both the registered template's {{variables}} and the legacy fallback string (one source of truth, no drift); generateCloneCopy now calls runPromptRefCutover({ promptKey: 'r360.wow.clone-copy', variables, tool, legacy }), taskClass and model unchanged (r360.narrate / Sonnet), and validateCopyPack + the CLAIM_PATTERNS no-verifiable-claims fence downstream are untouched. Verified against real conditions — a Postgres-backed live RIC with the prompt registered + published (r360.wow.clone-copy@1.0.0): generateCloneCopy round-tripped through the registry to real Sonnet and returned a valid, policy-compliant pack (atmosphere-only, "Reserve your table"; 1587/581 tokens metered as before). The template is version-controlled in the RIC repo (prompts/r360.wow.clone-copy.json) and re-seedable via pnpm prompts. tsc 0 · 16/16 clone-copy tests. Second cutover: menu-import Stage-1 VISION extraction (lib/menu-import/run-extraction.ts) — the churniest prompt. EXTRACT_PROMPT is exported and the registry template r360.menu-import.extract@2.0.0 is generated FROM it (byte-fidelity: an empty {{learnedHintsBlock}} renders exactly EXTRACT_PROMPT, so off/live differ only by source); the vision path now sends promptRef with the page images as attachments (the W5-1 extension) while the HTML-text path stays inline (its menu text is embedded in the prompt, a different shape). The save_menu forced tool, normalizeExtractedMenu, prices-as-read and deterministic fences are all unchanged; the learned-hints block is derived by slicing EXTRACT_PROMPT off the assembled prompt (one source of truth). Verified vs real conditions: a synthetic 4-dish menu image through a pg-backed live RIC resolved @2.0.0, ran real Sonnet, and returned all four items with prices exactly as printed (95/119/89/65 kr). Note: the pre-existing eval suite for this key is a stale RIC-5 text demo that can't validate a vision prompt, so @2.0.0 was published with --skip-gate (audited) — a vision-capable eval suite needs the RIC-9 harness to support attachment cases (documented follow-up); the deterministic fences + shadow-days are the net meanwhile. Behind the fail-safe-OFF ric_enabled flag. Third cutover: Experience Studio Food-DNA dish detection (lib/experience-studio/food-dna-runner.ts) — the base64-image path now sends promptRef for the registered r360.food-dna.detect@1.0.0 (system+user template generated byte-faithfully from buildFoodDnaMessages, r360.vision taskClass) with the dish photo as an attachment; the external-URL path stays legacy (RIC takes base64 only) and parseFoodDna/vetFoodDna are unchanged. Verified vs real conditions: a synthetic pizza image through a pg-backed live RIC resolved the template and returned pizza/italian at 0.88 confidence with only visible ingredients (the never-invent invariant held). W5 code cutovers COMPLETE (clone-copy text + menu-import vision + Food-DNA vision, all three high-churn prompts now registry-managed, editable/rollbackable without a deploy); the inline prompts remain as OFF-path fallbacks until they're retired in W8.

• RIC W4b video cutover — three bugs caught by an adversarial review of the media batch (all behind the fail-safe-OFF media flag, so none were live-exploitable). (1) Cross-tenant forgery (major): the RIC video jobId was plain base64url JSON whose tenant field was self-asserted, so a caller who learned another tenant's Veo op could re-wrap it under their own tenant and poll the victim's clip. Fixed RIC-side by sealing the jobId with AES-256-GCM (unforgeable); r360 just round-trips the opaque token. (2) Transient blip treated as terminal (major): pollExperienceVideo's RIC branch caught every error — including retryable 5xx/timeouts — and permanently refunded + retracted the owner charge while Veo kept generating and RIC's submit charge stood, orphaning an already-billed clip. It now honours RicError.retryable: a transient error returns processing (keep polling, no refund), only a definite failure refunds and ends the job. (3) Refund/reserve divergence (minor): the reserve used RIC's dynamic usage.costUsd but the failure refund used a hardcoded $3.20 — identical today but corrupts the platform-day video cap the moment RIC's Veo price card changes. The jobId now carries the exact reserved amount (ric:<reservedUsd>:<jobId>) so the refund always mirrors the reserve. Also documented a known bounded residual: the 45s RIC timeout can't cancel RIC's server-side work, so a generate that succeeds just after we abort falls through to legacy and makes a second asset — the airtight fix (an idempotency key RIC dedups on) is deferred to a dedicated pass. r360 tsc 0 · RIC 179/179 (new forgery test) · HTTP e2e (sealed jobId + forged-token 404) · r360 demo branches green.

• Owner-panel dark: last brown wash eliminated (hover-collision in the tenant dark sheet). The tenant dark override sheet (lib/tenant-theme/dark-css.ts) had the same substring-selector flaw fixed earlier in the admin engine: [class*="bg-amber-50/"]-style rules also matched hover:bg-amber-50/40 classes and painted the warm tint PERMANENTLY — the brown shortcut cards on quick-links, and every card with a warm hover accent. All substring selectors are now word-boundary anchored and hover variants get real :hover-scoped rules (all 17 color families). Verified live + on prod: card surfaces compute #121a2a navy. (c8b7b0f2)

• Owner-panel theme overhaul — dark mode goes NAVY (owner request: "no brownish look, like super admin dark"), plus a full 121-route deep scan. LIGHT keeps the warm clay brand; DARK now uses the super-admin navy palette (#0a0f1a canvas / #121a2a cards / #1b2538 insets / #1f2a3d hairlines / #e5e9f0 ink, primary #ea580c). Root cause of the brown: a second warm .dark token block (clay #1a1712/#26221c) later in globals.css silently overrode the neutral one — BOTH now navy, along with the neutral safety net (gray/slate/zinc/neutral/stone ramps), warm copilot-hero gradient, --warm-ink, and new dark coverage for divide-gray-50 + neutral from/to gradient stops. Hex hygiene: ~50 dashboard files still hardcoded the clay brand (bg-[#bf601d], gradients to [#d4762f]) — all converted to primary/accent-ink tokens so dark mode re-colors everything at once; broken clay→pastel gradients (SEO/AI/briefings/branches heroes, standing-reorders chip, supplier-quotes sky tile) rewritten to token tints. Element fixes: orange-on-orange text (AI assistant header/Pro-Tip, help setup banner, briefings labels), FSN bridge CTA (undefined --clay-500 → invisible button), dark-vanishing active pills (waitlist, Google audit/insights → bg-text text-background), hardcoded pine "Service live" label, features/labels/support hexes, Restora-Profit accent tokens now mode-aware CSS vars, features plan banner navy in dark, SmartRefill locked card matches its sibling. Systemic: .dashboard-shell scope class + normalized disabled buttons (washed-out white-on-peach in light → solid neutral pill; navy pill in dark) + themed native file-input buttons. QA: probe sweep of ALL 121 static owner routes × both modes (242 probes) + 16-agent screenshot review, fix, re-capture (79 shots) + 8-agent re-review → 0 broken; tsc 0; 4,024/4,024 tests. By design: KDS stays always-dark; website-builder previews show the public site's own theme; the red "N Issues" pill bottom-left is the Next.js dev-mode indicator (never in prod).

• Themed in-app confirmations everywhere — native `confirm()` retired. The browser's native confirm dialog can never inherit the app theme (the owner flagged it on the Image Bank purchase popup). New self-contained confirmDialog() (src/components/ui/confirm-dialog.tsx): renders into document.body outside every theme engine's scope, detects the surrounding surface (admin data-admin-theme / tenant .dark) at open time and styles itself accordingly — title, message, ghost Cancel, accent confirm button (red for destructive, brand orange otherwise), Escape/scrim to cancel, focus on confirm. All 16 remaining window.confirm call sites across 14 files converted with per-action labels: owner dashboard (orders decline, accounting disconnect, hiring unverify, quick-links group delete, supplier-marketplace cart switch, inventory order/order-all ×3), FSN (post delete ×3, block, mark-hired, disconnect platform, sign-out device), admin FSN maintenance (orphan purge). Verified live on the accounting Disconnect flow in BOTH tenant modes (dialog renders themed, Cancel leaves the connection untouched); tsc 0; 4,024/4,024 tests.

• Admin theme hardening round 2 — full-panel sweep (104 routes × both modes), chrome + islands + native widgets. Owner kept finding one-mode-broken spots after round 1 (sidebar search box dark on light, Domains page white-on-dark, preset swatches invisible, un-themed native confirm popup) — root causes: (1) scope — the generated vocabulary only themed .admin-content descendants, so the chrome (sidebar/topbar) was never remapped; the engine now themes the ENTIRE [data-admin-theme] subtree. (2) tenant tokens — pages built with the tenant design system (bg-card/text-text/border-border…: domains, support-brain, and the re-exported global-media) render one-mode-only under the admin engine; those pages were rewritten onto the standard vocabulary, the engine gained a tenant-token SAFETY NET mapping the core tokens per mode (so a re-export can never break again), and the vocabulary test now BANS tenant tokens on admin sources. (3) native widgets — the app root pins color-scheme:dark, leaking dark range-tracks/date-pickers into light admin; the themed root now sets its own color-scheme and range sliders get an explicitly themed track+thumb. Also fixed: light-mode disabled buttons normalized to a readable neutral pill (washed-out white-on-peach Save buttons), bare border-b/t/l/r + divide-y/x currentColor hairlines, translucent bg-black/ scrims in light (solid before — hid hover overlays), RAOS status pills off inline dark hex onto palette classes, escrow overdue rows visible amber in both modes, monetization/modules neutral chips, themes Premium badge ink, color-preset swatch circles (self-contained double shadow-ring, visible on any strip), and the Experience Studio Image Bank's native confirm() replaced with a themed in-app purchase dialog. Verified: probe sweep of ALL 104 static admin routes × both modes (whole-document luminance + text-contrast) + a 13-agent screenshot review of all 208 captures; tsc 0; 4,024/4,024 tests. Known by-design: Guardian/Growth command-center rails stay dark in light mode (1:1 ported prototypes — flag if unwanted); localization preview renders fixed receipt paper.

• RIC Phase 1.5 W4b — Experience Studio VIDEO generation through the RIC gateway (W4 media batch COMPLETE). RIC gained an async Veo-shaped LRO surface (POST /v1/ai/videos submit → GET /v1/ai/videos/:jobId poll; the jobId is opaque and TENANT-BOUND — a leaked ref polled by another tenant 404s exactly like an unknown one; cost commits at submit as RIC's aicalls ledger row; on done RIC downloads the clip immediately — Veo links expire in ~2 days — and returns `mp4Base64` in-band with `synthetic`/`disclosure`; file-level marking rides Google's embedded SynthID watermark since mp4 has no lossless iTXt equivalent). r360 side: `ricVideoStart`/`ricVideoPoll` client + a seam in `startExperienceVideo` (media-gate LIVE only — same no-shadow rule, a shadowed clip is a real ~$3 second generation) that submits through RIC with the SAME negative-prompt rails and reserve-on-submit metering; jobs route back via a `ric:`-prefixed jobId so `pollExperienceVideo` (now tenant-threaded from the video route, since RIC's jobId is tenant-bound) polls RIC under the submitting tenant's scope, refunds the video day-lane on terminal failure exactly like the google branch, and returns the same `data:video/mp4` URL — the whole downstream (owner ×2.5 charge with poll-failure retraction, auto-bank gallery pipeline) is untouched. The mock-poisoning guard applies at submit: a mock-served job falls through to legacy Veo. RIC-side verified 178/178 (4 new gateway tests incl. tenant-binding + terminal-failure row) + HTTP e2e on a real gateway (submit / poll-ready-mp4 / foreign-tenant-404 / garbage-404); r360-side live-verified via `scripts/w4-video-demo.ts` (fake-live → `ric:` jobId + real mp4 data URL, exactly 2 gateway hits · flag-off → 0 RIC calls · mock-guard · dead-RIC → legacy). tsc 0. Go-live: RIC needs a Google key with paid Veo access (`GOOGLEAPI_KEY or mrr.providers`); until then live mode falls back to legacy loudly.

• RIC Phase 1.5 W4a — Experience Studio TEXT→IMAGE generation through the RIC gateway. New ricImage() client (lib/ric/client.ts, sharing the completions transport/error contract) calls RIC's existing POST /v1/ai/images, whose PNGs arrive Art-50-marked (machine-readable iTXt AI-Disclosure chunk — the EU AI Act synthetic-content marking r360's legacy images never had). The seam sits inside generateExperienceImage so ALL its callers (Studio hero generation, Food-DNA admin generation, Flow-B component assets) cut over at once, with three deliberate guards: (1) media never shadows — new getRicMediaMode() collapses shadow to off because shadowing an image is a real second generation (double spend on both ledgers), so media cuts over only at an explicit live; (2) the img2img/owner-photo path stays legacy — RIC images take a prompt only, and the photo-must-drive-the-result guard is untouched; (3) a mock-served RIC image (provider `mock`) is rejected and falls through to the legacy provider, so a RIC-side outage can never persist or bill a 1×1 placeholder as a hero (RIC-side, the mock tail was also removed from the LIVE image/embedding chains — same fail-loud decision as the text chain). RIC's in-band usage.costUsd feeds the SAME metering as legacy (platform per-day lane + per-tenant attribution); any RIC failure falls back to the legacy registry path unchanged. Verified live via scripts/w4-image-demo.ts against a real running gateway: fake-live → r360 returns the marked PNG + meters $0.04 (1 gateway hit) · flag-off → 0 RIC calls · RIC-in-mock-mode → guard rejects the placeholder, legacy resolution runs · RIC-dead → RicError → legacy. tsc 0 · lib/ric+studio tests green. Go-live note: RIC needs an OpenAI key (mrr.providers or OPENAI_API_KEY) for gpt-image-1; until then live mode falls back to legacy loudly. Video (Veo LRO) is W4b — it needs a new async RIC surface, not /v1/ai/images.

• RIC Phase 1.5 W3 (started) — vision cutover pattern proven on the FSN food-gate. Extends the RIC harness (lib/ric/narrate.ts) with runVisionCutover: sends a base64 image part + instruction (and an optional forced tool) through RIC, returning the model text/object so each site's existing parser/vetter and fences run unchanged. Two new fenced RIC vision taskClasses back W3: r360.vision (Haiku-first, cheap classifiers) and r360.vision-hi (Sonnet-first, accuracy-critical regulated extraction). Cut over `fsn/food-gate` (classifyImageBytes → r360.vision): the inline Haiku vision call is the legacy fallback, and the conservative decideVerdict/vetGateResult/fail-open behaviour is untouched. Live-verified against a running RIC gateway: a real PNG round-trips → {"isFood":false,"confidence":0.99,"label":"…"}, the exact shape parseGateJson expects, metered at $0.0002. Behind the fail-safe-OFF ric_enabled flag (shadow default). Also cut over `profit/invoice-vision` (the Operating-Cost-Ledger feed — a misread digit is a real cost error) via a new runDocVisionCutover that takes a pre-built content array (multiple images / a PDF document part) plus the forced save_invoice tool, on the Sonnet-tier r360.vision-hi. The legacy Sonnet vision call is the fallback; normalizeInvoice and the ai-estimate/owner-confirm mapping are unchanged, so amounts stay "as read, never computed". Live-verified: an image + forced tool round-trips through RIC → a save_invoice object with an honestly-low confidence on unreadable fields (Sonnet, $0.0027). Also cut over the regulated extraction cluster — nutrition/calculate (text forced-tool, r360.generate), nutrition/from-image (vision forced-tool, r360.vision-hi) and menu/detect-ingredients (text forced-tool, r360.narrate). In every case RIC only extracts (ingredient names / visible foods + portions); the nutrition numbers stay deterministic via the food catalog and the allergens stay deterministic via detectAllergens (owner-confirmed suggestions) — the never-invent-numbers / allergens-as-suggestions invariants are preserved exactly, with the deterministic engines and disclaimers unchanged. W3 is now COMPLETE — every remaining extraction/vision site is cut over on the same helpers: bazar/photo-quality (vision, r360.vision) · WoW design-dna (both generateDesignDna + detectMenuLayout doc-vision forced-tool, r360.vision-hi since design-DNA runs on Sonnet) and ai-theme (vision forced-tool, r360.vision-hi) · wow/translate-menu (narration, r360.narrate, positional element-count invariant preserved) · fsn/recipe-card (structured save_recipe, r360.generate) · inventory/copilot (narration, r360.narrate — the fenced taskClass ADDS a number fence this RAG site lacked) · launchpad/research-runner (extraction, r360.generate, extract-from-source-only + citation-pinning fence unchanged) · admin/support-brain curator + dashboard/support/ask (narration, r360.narrate, PII gates unchanged) · experience-studio/food-dna-runner (vision, r360.vision; an external-URL image stays on the legacy provider since RIC takes base64 only) · and menu-import Stage-2 photo detection (r360.vision-hi), the one menu call RIC-6 left behind, now reusing the same ricTenantOf/ricMode Stage-1 uses. In every case the site's downstream parser/vetter/deterministic-fallback and wallet metering are untouched — RIC only replaces the model call, with the legacy provider call as the fallback. All behind the fail-safe-OFF ric_enabled flag (shadow default). One site is explicitly deferred: detectDishGemini uses the Gemini provider directly (not Anthropic), so consolidating it to RIC is a later provider-routing optimization, out of scope for the Anthropic cutover pattern. tsc 0 across all touched files. Next: W4 (image/video generation).

• Admin theme hardening — "no hardcoded styles" is now an ENFORCED rule (owner request: fix light/dark for good). Root cause of the recurring "page looks broken in one mode" reports was three systemic bug classes in the override engine (src/lib/admin-theme/theme-css.ts): (1) hover-collision — the [class*="bg-x/"] substring rules also matched hover:bg-x/5 classes and painted the hover tint PERMANENTLY (the "dark buttons on a light page" breakage on Food DNA); all substring rules are now word-boundary anchored ([class^=] / [class*=" ..."]) and every bg/border/text utility additionally gets a :hover-scoped remap for its hover: variants. (2) colored-text lift gaps — text-{color}-600/950 (and hover//alpha variants) authored for light pages were near-invisible on the dark canvas; dark mode now lifts all 600–950 colored text to readable tints. (3) vocabulary holes — neutral 300/400 surfaces+borders, border-white/nn/border-black/nn hairlines, text-white/nn inks, gray alpha hovers and bare border (Tailwind v4 currentColor default) are now themed in both modes. Coverage went from 319 unthemed tokens across 91 admin sources to 0 neutral gaps. Enforcement: new src/lib/admin-theme/vocabulary.test.ts scans every admin surface (app/admin/dashboard, components/admin, (dashboard)/dashboard/admin) and FAILS the suite on any unthemed color class or arbitrary hex class (bg-[#bf601d]) — rule documented in AGENTS.md. Cleanups to pass it: Food DNA page rewritten onto the covered vocabulary (no bg-transparent inputs / hover:bg-black/5), and all hex classes in feature-flags, revenue-share, docs-analytics, admin addons + monetization replaced with palette equivalents. Verified: tsc 0 · 4,023/4,023 tests · Playwright screenshots of 12 admin pages × BOTH modes, automated luminance probe + eyeball review all clean.

• RIC Phase 1.5 W2 — narration cutover to the Restora Intelligence Cloud gateway (social captions first). Extends the RIC anti-corruption layer (ui/src/lib/ric/, the ONLY RIC-aware code in r360) from menu-import (W1/RIC-6) to the narration surfaces. New lib/ric/narrate.ts = the generalized narration cutover harness: a RIC-backed transport matching the existing pluggable AiGenerate seam exactly, so a call site cuts over by swapping ONE line — its validator, fence and deterministic fallback untouched. Three modes via the fail-safe-OFF ric_enabled flag (getRicMode): off = legacy Anthropic path byte-identical · shadow = legacy serves, RIC runs alongside and a structural number-drift diff is recorded to databases/ric-narration-shadow.json (gitignored, capped) · live = RIC serves with the legacy transport as the fallback on any RIC error. The RIC narration taskClass is FENCED, so RIC's own output filter flags number drift / invented allergen claims — a second wall behind each r360 site's validator. Two cutover shapes are supported so any narration site fits: (a) the transport-seam pattern (a site that already injects an AiGenerate) and (b) runNarrationCutover for inline routes (system+user → text). Cut over EIGHT surfaces so far: social captions (draft-caption route, cron/social-autopilot, live-instagram — transport swap), Guardian RCA, Growth advisor chat, and the four platform/founder exec narrations that share the per-field number/date guard — RACM governance briefing, Mission Control founder briefing, Intelligence recommendations, Profit advisor — plus the inventory daily summary (inventory/narrate). For the exec-narration sites the LLM call is swapped for runNarrationCutover while the downstream guardField number-guard is left completely intact — it re-validates whatever RIC returns, so a RIC-served rephrase that drifted a figure still reverts to the deterministic line. Every site keeps its deterministic fallback and its exact wallet metering; the tenant sites (profit, inventory) attribute cost to the tenant, the platform-ops sites use a dedicated platform-ops RIC scope. Live-verified against a running RIC gateway: a RIC-served Haiku caption PASSES the existing validateSocialCaption with zero violations, the inline path returned a real RCA, and a governance-briefing JSON round-tripped through the fenced taskClass with every figure (45200 / 12% / 3) preserved; shadow-compare recorded; the drift fence caught an injected "25% off + 100 kr". tsc 0 on all touched files. ALL 16 narration sites now cut over — captions, guardian RCA + ops-chat, growth chat + outreach, the four number-guarded exec narrations (RACM / Mission Control / Intelligence / Profit), inventory summary, voice-concierge, exec briefing, email campaigns, SEO landing, and site-template copy — plus WoW clone-copy via a structured (forced-tool) variant runStructuredCutover. Two RIC taskClasses back them: r360.narrate (Haiku-first, light rephrases) and r360.generate (Sonnet-first, heavier content) so model quality is preserved per site — both FENCED. Live-verified: r360.generate serves Sonnet SEO copy; the forced-tool path returns a validated clone-copy object; a governance-briefing JSON round-trips with every figure preserved. Everything stays behind the fail-safe-OFF ric_enabled flag (default shadow) until an explicit live flip. Next: W3 (extraction & vision — the fence-heavy batch).

• Phase 52 — Food DNA: ONE curated dish→image registry for every import (owner request: "system learns it by time"). The two import paths gave different images because they never shared a source: the dashboard import ran its own ladder (tenant media → community → stock) while the WoW clone ran a separate stock chain and left unmatched dishes blank. Now both consult the same super-admin-gated registry. Store + engine: databases/food-dna.json (FoodDnaEntry: multilingual canonical names + aliases + status + license-tracked image; own app-doc, PG-ready) with a deterministic conservative matcher (exact=100 / token-set=95 / Jaccard≥0.8=85, below → NO match — a wrong dish image misrepresents meat/allergen content) and resolveDishImage that serves approved entries only. Wire-ins: the dashboard import's image-match ladder gains a DNA lane (near-exact = 96, the only non-owner source allowed to AUTO-assign — a human approved it); the WoW claim now backfills imageless products from near-exact DNA matches (marked imageSource:'dna') — the two paths finally agree. Demand loop: dishes that finish an import imageless (both paths) are captured as demand — unmatched names become pending name-only entries and the admin queue sorts demand-first, so the registry grows toward what restaurants actually import. Human gate: /admin/dashboard/food-dna — seed the 700-dish FSN Global Kitchen library as PENDING (FSN presentation ≠ restaurant presentation; 650 seeded, each needs explicit approval), search/status filters, per-entry set-image-by-URL (SSRF-guarded, rehosted under /global-media, credit required before approval), REJECT/DELETE, and AI generation: one click generates a menu-style photo from name+cuisine via the existing image-provider registry (platform $5/day lane), sharp-resized to the library convention (1024×768 + thumb) — and still lands PENDING. Honest marketing: DNA-assigned images carry Product.imageSource:'dna' and the public menu shows a subtle "Illustrative" marker; the owner replacing an image flips it to 'owner' and the marker disappears. Verified: tsc 0 · 4,022/4,022 (5 new engine tests) · live end-to-end on dev — seed 650 → approve "Kanelbulle" → tenant match-images returns the DNA image at 96/auto from /global-media · admin page renders with thumbnails/credits/counts.

• Plan catalog overhaul (owner decision 2026-07-02): FOUR live plans, all others WIPED; flat plans billed YEARLY; AI-paid-during-trial stated everywhere. The live catalog is now exactly: Online Starter 149 kr/mo (1 788 kr/yr) · Basic 299 kr/mo (3 588 kr/yr) · Enterprise 2 999 kr/mo (35 988 kr/yr, EVERYTHING included — every feature and add-on) · Pay As You Go 0 kr/mo + 7% per transaction (everything included; rides the existing revenue-share commission engine). Flat plans show a monthly price but charge ONE yearly payment (resolveSignupPlan.chargeSEK, 365-day periods end-to-end: register provisioning, /register/payment dev-sim + Stripe yearly line item, billing-page upgrades). Wiped (archived + non-public + non-assignable, still resolvable so existing subscriptions keep entitlements): basic-annual 999, premium-annual, growth-partner 8%, street-food-starter 99+2%, free-growth-7pct, franchise, seasonal, and the old usage-metered PAYG (2 kr/order · 0.10/SMS · 0.50/AI-req). The tenant billing page now renders the live catalog dynamically (4-card grid, "billed yearly · X kr/yr" / "7% per transaction"), switching to PAYG charges nothing (works even without Stripe keys), and the revenue-share banner shows for any revenue-share plan. PAYG is exempt from the retired Free-Growth signup flag (first-class plan). Trials: always 7 days on every plan — and AI usage is PAID during the trial (draws from the one-time 100 kr AI credit), stated on: the landing pricing band, /register, /register/payment, the public onboarding wizard, the /welcome/onboarding trial summary (new "AI during trial" row), the dashboard trial banner, the billing trial banner and the welcome email. Landing pricing band redesigned as Starter card + a Basic/Enterprise/PAYG ladder. 9 catalog-shape tests updated to codify the new reality (engines unchanged); PAYG-shape, offerable-set and eligibility tests now assert the four live plans. Verified: tsc 0 · 4,017/4,017 · live QA (signup-plan API 149/1788/yearly+AI-note; billing grid = exactly the 4 plans, legacy hidden; PAYG switch → active at 0 kr with the full entitlement nav appearing; landing band renders). NOTE: /plan and /about marketing pages still carry older copy (OP-7b, owner).

• Phase 51 OP-14 — menu as a digital SHOWCASE; "Online Ordering" becomes an add-on (owner decision). The Online Starter plan no longer includes online-ordering: the public website and Food Bazar page render the FULL menu (photos, prices, allergens) but no cart or add/order buttons; buying the add-on (29 kr/mo billed yearly — now listed in the store) or being on Basic+ lights ordering up on both surfaces. Enforced in FOUR layers so it's never just hidden buttons: (1) all three public order-creation routes (cash/card/PayPal) refuse with a polite 403 ONLINE_ORDERING_NOT_ENABLED via a new server-only entitlement gate (fail-OPEN on transient read errors — a DB hiccup must never block an entitled restaurant's money); (2) the tenant storefront threads orderingEnabled through BlockContext → MenuClient (cart drawer/button, quick-add, customize all gated; default true so every other caller is unchanged); (3) the Food Bazar detail payload carries onlineOrderingEnabled and folds it into acceptingOrders, with a dedicated "This restaurant doesn't take online orders — browse the menu, then visit or call" notice; (4) the marketplace LIST badge uses a new batched tenantsWithFeature gate helper (ONE master read for the whole list) so cards never advertise a checkout the restaurant can't fulfil. Trial semantics unchanged: the 7-day all-access trial DOES unlock ordering; the showcase mode begins when the trial converts to a plan without the add-on. Landing/payment/FAQ copy now says "digital menu on your own website" for the starter and moves "Online ordering & payments" to the Basic card. Live-verified on dev: post-trial starter = menu renders, 0 order buttons, API 403, store lists the add-on at 29/mo · 348/yr; premium tenant byte-identical (27 add buttons, ordering APIs pass, bazar acceptingOrders true). tsc 0 · 4,017/4,017 tests.

• Phase 51 v2 — owner re-cut of the Online Starter package + unified add-on pricing (29 kr/mo, billed yearly). Owner decisions applied end-to-end: (1) Starter recomposed — OUT: Orders board, Customers CRM (and Messages, which rides the same feature), Tables & QR + Floor Designer, Delivery zones, and the whole Reports & Money set (analytics, bookkeeping, payouts, payments dashboard) — each now activates from the Add-ons store; IN: Experience Studio (access included; generation spends the one-time 100 kr lifetime AI credit every signup already gets — GRANT_SEK_PROD, stamped once, never resets). Guest-facing ordering + payment processing (stripe/paypal/swish) deliberately stay in the plan — guests can always order and pay; it's the owner-side management surfaces that are add-ons. (2) Account & Settings slimmed — Restaurants (→ multi-restaurant) and Go Mobile (→ new go-mobile feature) are now add-on-gated; new payments-dashboard feature gates the Payments page. (3) One add-on price — ALL single add-ons are now 29 SEK/mo billed yearly (one 348 SEK charge for a 365-day period): 37 registry entries repriced (from 9–199 kr; incl. fsn-recruiter/food-catalog-api 199→29, inventory 99→29) — suites keep their bundle pricing per 30 days, and Experience Studio keeps its premium price (it's in the 149 plan instead). Billing engine now period-aware: resolvePurchasable carries periodDays/chargeAmount/periodLabel, activation + renewal sweep use them, Stripe checkout charges 12× monthly with a "— 12 months" line item, the confirm modal previews the real yearly total, and the store/active cards say "billed yearly". Also fixed: the marketplace guessed tier from the planId prefix, so Online Starter tenants (unknown prefix → 'basic') wrongly saw NO basic-tier add-ons as buyable — it now trusts the per-feature resolved entitlement (isActive) from the API. Landing pricing card, FAQ and /register/payment copy updated to the new composition. Verified: tsc 0 · 4,012/4,012 tests · live QA on a fresh signup (compact 9-section sidebar exactly as envisioned; store lists the moved-out features at "29 SEK/mo · billed yearly · 348 SEK/yr").

• Menu import from URL now accepts bare domains ("kebabtime.se") — same normaliser as the WoW funnel, one engine. The WoW clone flow got normalizeUrl (bare domains, www-forms, loose schemes → https default) but the menu-import guard (lib/menu-import/url-safety.ts checkUrl, used by both the URL-capture and direct-download import routes) still parsed the raw string and rejected anything without an explicit https://. It now normalises with the SAME WoW helper before validating; the SSRF guard is unchanged and verified to still block loopback/private/metadata hosts after normalisation. 5 new tests; live-verified: kebabtime.se starts a capture job instead of "Enter a valid URL (including https://)".

• Logged-out `/dashboard` now redirects to `/login` instead of rendering a ghost panel. The dashboard layout never required a session: an anonymous or expired-cookie visit rendered the FULL unfiltered nav catalog (119 rows) with every link disabled. Pre-existing, but once the sidebar became entitlement-aware (Phase 51 OP-2, deliberately fail-open) this ghost state masqueraded as "plan filtering is broken" — found when the owner's stale tab showed "the long navigation" for a fresh 149 kr Online Starter tenant whose server-side filtering was verified correct. One-line guard: no valid platform_session → redirect("/login"). Verified: anonymous /dashboard → /login; starter login still gets the compact plan-filtered sidebar.

• RIC-6 — Restora360 becomes the first consumer of the Restora Intelligence Cloud (separate repo `restora360_restaurant_intelligence_system`). New anti-corruption module lib/ric/ — the ONLY RIC-aware code in this repo: mode.ts (pure fail-closed gate pickRicMode: MasterDB flag ric_enabled fail-safe OFF ∧ RIC_BASE_URL ∧ RIC_API_KEY; with the flag on, RIC_SERVE_MODE=live opts in, anything else = the safer shadow), client.ts (RIC gateway client: explicit restora360:<tenantId> scope per call, RFC 9457 problem mapping, timeout), shadow.ts (structural menu diff + capped databases/ric-shadow.json store, best-effort by contract), types.ts. Stage-1 menu-import extraction (run-extraction.ts, both the vision and text paths) can now run through the RIC AI Gateway: off = byte-identical legacy; shadow = legacy serves, RIC compared (first live shadow: 100% name overlap, 0 price mismatches); live = RIC serves with the SAME wallet metering (recordUsage gets RIC's in-band token usage → appendLedgerEntry unchanged) and automatic legacy fallback on any RIC failure (proven by killing RIC mid-demo). Stage-2 photo detection stays legacy (cutover with the P1.5 migration wave). Demo/verification harness: scripts/ric6-demo.ts <off|live|shadow|reset>. Verified: tsc 0 · 8/8 new lib/ric tests · live cross-repo demos for all four behaviors with real Anthropic answers on both paths.

• Phase 51 — Owner Panel Reorganization & the 149 SEK Online Starter (OP-1…OP-6, buildable scope COMPLETE). The owner dashboard had grown to 89 top-level pages with a ~95-entry sidebar shown to EVERY tenant and zero plan filtering — while the entitlement engine (67-feature registry, resolver, requireFeature in ~85 API routes) was fully built but never wired to navigation. This phase wires it, reorganizes the IA, and ships the new signup package (plan: docs/owner-panel/PHASE-51-OWNER-PANEL-PLAN.md; grounded in a 4-agent recon + 10-agent orphan-route triage). (OP-1) Welcome email — the first one the platform ever sends: idempotent POST /api/tenant/[tenantId]/onboarding/complete stamps onboardingCompletedAt server-side and sends ONE branded email with the two links every owner needs — the admin panel and their resolving live site (tenantLiveSiteUrl, never the unwired vanity subdomain) + a plan-driven trial line; called by BOTH wizards so /register, the landing CTA and the WOW magic-link claim all converge; the public wizard's fake "verify email" phase (no email was ever sent; resend was cosmetic) is REMOVED and its dead <subdomain>.restora360.com link replaced with the resolving URL. (OP-2) Entitlement-aware sidebar: every gateable nav item carries a featureId; resolveNavFeatureSet resolves the tenant's PLAN set without the trial-all-access window (a trialing owner sees their plan's nav — deep links to trial extras still work; day-8 no longer looks like the product broke), fails OPEN on errors; sidebar, sidebar search, and Quick Links (add-grid + stored bookmarks, rows preserved) all filter identically; superadmin unfiltered. ~20 nav-coverage features minted at basic/0 SEK (zero regression for existing tenants; re-tierable in Pricing Studio without code); also fixes a pre-existing leak where sidebar SEARCH exposed admin-only entries to every tenant. (OP-3) New IA: compact primary (Overview · Quick Links · Orders (renamed from "TV & Displays") · Customers · Add-ons) + 12 job-shaped groups (Reservations / Menu & Combos / Food Bazar / Marketing & AI / Website & Content / Operations (in-venue) / Inventory & Suppliers / Reports & Money / Restora Profit / Chains & Groups / Account & Settings / Help & Support); 10 off-catalog routes triaged (3 already-correct redirects kept, 6 deliberate sub-tools of Receiving/inbox documented, /dashboard/features "Your Features" added to the catalog); the missing Landmark nav icon registered. (OP-4) Connections hub (/dashboard/connections + aggregation API): Google Business, socials, accounting provider, Stripe Connect payouts, paired terminals, delivery platforms, commerce channels and the custom domain in one place with Connect/Manage CTAs — connect-state is NEVER hidden by plan (unlike entitlements), an owner can always find where to connect. (OP-5) Add-ons front door: the marketplace machinery MOVED (cut, not copied) out of /dashboard/billing into components/dashboard/addons/AddonsMarketplace mounted at the always-visible /dashboard/addons (suites + à-la-carte + active add-on management + the Stripe-return finaliser; checkout success/cancel URLs updated); Billing keeps plan + invoices + a link card; requireFeature's 402 upgradeUrl and the upsell CTAs now point at the store. (OP-6) Online Starter 149 SEK/mo: new built-in online-starter-monthly plan (7-day trial, explicit includedFeatureIds = the online set: website/menu/online orders/reservations/Food Bazar/basic marketing/analytics/payments + the owner's own books & payouts; NO in-venue ops — that's the upgrade story to Basic 299); platformSettings.signupPlanId + resolveSignupPlan now drive register, WOW claim, Launchpad, /register/payment (charges the plan's REAL price), the register-page copy, the onboarding "plan after trial" line, the day-4 trial email and the KeepAccountBanner — killing four hardcoded "299 kr" copies and the old register-trials-on-basic-annual vs WOW-trials-on-basic-monthly mismatch (trial LENGTH now also comes from the same plan); SubscriptionRecord.planId loosened to string (any resolvable PlanDefinition id). Verified: tsc 0 · 4,004/4,004 tests · next build clean · 43/43 Playwright checks against the running dev app (premium+grants / fresh-starter / superadmin-cookie sidebars, addons + connections + billing pages, search-leak fix, register→starter provisioning, onboarding-complete idempotency) · welcome email observed end-to-end in the dev mailer with resolving links and "149 kr/mo (Online Starter)". NOTE (deliberate): landing-site marketing copy still advertises Basic 299 (true — the plan exists); repositioning the public pricing story around the 149 starter is an owner copy decision.

• Super-admin dark mode — closed the override-sheet gaps that left faint text + light cards on the dark canvas. The unified admin theme (theme-css.ts) re-skins Tailwind classes per mode, but three common classes weren't in its vocabulary, so any page using them broke in dark (e.g. the new Import-Learning pages, and other sections): (1) text-gray-400 / text-gray-500 weren't remapped in dark → muted labels rendered near-invisible (now mapped to readable inks #9aa6ba / #8c98ab); (2) colored -50/-100 opacity tints (bg-indigo-50/50, bg-emerald-50/…) only matched the exact class, not the /opacity variant → a light card sat on the dark page (now the [class*="bg-…-50/"] variants map to the dark tint); (3) bg-white/opacity glass panels weren't remapped (now → the dark card surface). One systemic change themes every admin island at once, no per-page edits; original dashboard rules untouched. Verified the generated dark CSS now emits all three.

• Phase 50 hardening — plan gating, Guardian alerting, group (HQ-connects-once) scope, Explain button (the four airtightness gaps). (1) Plan gating: new accounting-sync feature (Premium+ by default, 49/mo add-on for Basic, super-admin grant/retier without code — plan §13 tier decision stays open) wired into every accounting write route (requireFeature → 402 with upgrade metadata), the status feed (featureAvailable → the page renders an upgrade panel) and the dispatcher (an un-entitled connection neither plans nor dispatches — nothing accumulates, everything resumes on upgrade). (2) Guardian: new integration incident source + an accounting-sync service row; the probe cycle now reads the LIVE sync stores and opens stably-fingerprinted incidents for dead-letter backlogs (P3, P2 at ≥10 stuck documents) and reauth-required connections — folding into one incident instead of one per tick, riding the existing anti-fatigue alerting; a store read failure yields no candidates (monitoring never takes the monitor down). (3) Group scope: a group HQ can tick "Connect for the whole group" — one org-scope connection covers every location (the planner now takes a tenant-id SET and each task carries the event's tenant; branch documents build from the branch's own doc/currency; gates = the deterministically-resolved HQ's mapping+consent — one legal company, one chart, one consent; the 0-or->1-HQ anomaly resolves deterministically). Branches see a "managed by your headquarters" card; every resolver is org-aware (own connection wins, else the group's). (4) Explain button on stuck tasks calls the BK-11 narration (deterministic fallback inline). Live-verified: org context correct for standalone tenants, premium tenant passes the gate, tick green, Guardian probe runs the accounting feed with a clean healthy-queue negative. tsc 0; 10 new tests; full suite 4,004/4,004.

• Phase 50 BK-11 — the accounting assistant: DETERMINISTIC hints always, AI narrates only (closes the buildable scope BK-0…BK-11). The docs/bookkeeping.md "Fortnox rejected invoice — AI explains why, suggests fix" built the Restora-Profit way: deterministicHint (lib/accounting/assist.ts) is a PURE rule table over the queue's error taxonomy — mapping-unapproved / consent-missing / unknown-account (carries the exact account number into the fix) / unbalanced / ordering / reauth / rate-limited / wave-scope / generic — every failure gets a summary AND a concrete next click, no AI key required. Hints ride inline on stuck tasks in BOTH the tenant sync panel and the admin dead-letter list; POST /api/accounting/sync { action:'explain' } adds an optional warm AI narration (voice-concierge narrate pattern: budget-gated via the AI registry, metered as assistant usage, system-prompt forbids new numbers/accounts, ANY failure falls back to the deterministic text). Nothing auto-repairs — fixes stay the owner's click. Live-verified: explain returned the correct wave-scope rule with usedLlm:false on this box's invalid AI key — the fail-safe demonstrating itself. tsc 0; 3 new tests; full suite 3995/3995.

• Phase 50 BK-10 — the Accounting Integration Center (super-admin). /admin/dashboard/accounting (new sidebar entry under Platform & System, dashboard chrome = shared admin theme for free) + GET/POST /api/admin/accounting/overview: the master kill-switch as a one-click card, the provider catalogue with per-provider auth kind / markets / verified rate budgets / app-credential presence (not set = mock mode), every tenant connection with its gate state at a glance (mapping approved + consent current, demo badge), per-connection queue health + posted-document counts + last sync, cross-tenant totals, and a dead-letter list with admin REPLAY + a run-tick-now button — the cross-tenant connect/health/retry controls the old read-only Integration Monitoring page never had. Super-admin only, audit-logged, token material never crosses the boundary; tenant gate reads fail closed. Live-verified: overview feed correct for the luigi demo connection (both gates green, 4 posted), page renders 200, admin run-tick executes. tsc 0.

• Phase 50 BK-9 — expense sync (wave 2): one-off owner-entered costs become expense documents. A NEWLY-created, fixed-amount, one-off cost-ledger entry (a real purchase — oven repair, equipment) now emits expense.recorded from the profit costs route in the same mutate, plans an exp_<id> task, and posts to the provider on the mapped purchases account. Honest boundaries kept: recurring/pct-of-revenue entries stay P&L ESTIMATES and are deliberately never posted as documents; updates never re-emit; input VAT is never invented (the owner-entered amount posts gross, vatAmount: 0 — receipt-level VAT splitting belongs to a future receipt-scanning wave); and a provider capability that genuinely doesn't exist (unsupported, e.g. expense push on Fortnox/Visma pending their sandbox wave) now becomes a visible skip instead of a dead-letter — nothing a retry or human can fix there. Live-verified: a 1,250 SEK one-off cost added through the real profit API flowed tick → demo provider expense #24935. tsc 0; 2 new tests; full suite 3992/3992.

• Phase 50 BK-8 — real Fortnox + Visma eEkonomi adapters (fixture-tested, LIVE-GATED). The first two real provider implementations behind the universal contract, built on an injected-transport pattern so every behavior is unit-tested against fixtures and no test touches a real API: shared HTTP plumbing (providers/http.ts) maps provider semantics onto the queue's error taxonomy (401/403 → reauth-required — Visma's silent password-change death becomes a Reconnect prompt, never a retry loop; 429 → rate-limited with Retry-After honoured; 404 → retriable ordering not-found; 400/422 → validation dead-letter; 5xx → provider-unavailable). Both adapters use SEARCH-FIRST idempotency (neither API has idempotency keys — our deterministic externalRef rides the document reference fields and is looked up before create; a hit returns duplicate:true, matching the mock's contract exactly). Fortnox: v3 wrapper objects, customer ensure-then-invoice, invoice payments resolved by reference; Visma: eAccounting v2 $filter search, credit-invoice flag, per-invoice payment posting. Wiring is a side-effect register module (providers/register.ts) imported by the dispatcher/bootstrap — which changes NOTHING until a connection actually reaches sandbox/live mode, a path that stays quadruple-gated (kill-switch → provider app creds → BK-7 consent → approved mapping). ⚠ Exact FIELD mappings are explicitly marked SANDBOX-VERIFICATION-PENDING — validating them against real Fortnox/Visma test companies is the BK-12 go-live gate by design. tsc 0; 6 new fixture tests; full suite 3990/3990; live mock tick unaffected after wiring.

• Phase 50 BK-7 — auto-posting consent (the deliberate TC-0 extension) + first-class CREDIT NOTES + document fidelity. (1) Consent (lib/accounting/consent.ts + GET/POST /api/accounting/consent + a consent card on /dashboard/accounting): TC-0's "Restora prepares, never files" is extended with its OWN versioned acceptance — the owner explicitly approves that Restora creates DRAFT documents in their connected accounting system while they remain responsible for review/filing; a terms-version bump invalidates old consents. canAutoPost is now THE pure dispatch gate: mapping approval always; a CURRENT consent + a non-demo tenant before anything non-mock (demo restaurants can NEVER post to a real system); mock stays consent-free. (2) Credit notes become a first-class books document (lib/bookkeeping/credit-note.ts + TenantDB.creditNotes — the object the recon confirmed existed NOWHERE): every refund now records a numbered kreditnota (per-tenant yearly series KN-<year>-<seq>, amounts split at the ORDER's dated VAT rate with the recompute's honesty flags) in the SAME lock as the refund's ledger row, emits the first creditnote.issued events, rides the bookkeeping API response, and correlates the sync push (docNumber = KN number; invoices carry the order number the same way). (3) Robustness fix caught by live QA: payments/credit-notes now ensure their referenced invoice provider-side before pushing (idempotent by externalRef — a duplicate returns the existing doc), and not-found is classified as a retriable ORDERING condition instead of fatal — this heals both real-provider edge cases (doc deleted provider-side) and the demo provider's restart amnesia. Live-verified end-to-end: consent recorded (version-stamped, audited) → 5 SEK refund created KN-2026-0001 (6% dated split) + queued its event → tick initially dead-lettered on the pre-fix amnesia → REPLAY + ensure-invoice landed it as provider doc #25202 — the replay facility proving itself on a real failure. tsc 0; 12 new tests; full suite 3984/3984.

• Phase 50 BK-6 — the sync engine: durable queue + dispatcher + external-id ledger + REPLAY + the platform cron scheduler (the keystone). The "sync forever" half of connect-once, and the fix for the confirmed 37-of-42-crons-never-fire prod gap. (1) Queue core (lib/accounting/sync/core.ts, pure, RAOS-bus-shaped): per-connection FIFO with at most one running task (invoice-before-payment ordering is an accounting invariant), retry backoff [1,5,30] min, fatal validation errors dead-letter immediately, replay requeues dead-letters with a fresh budget (a facility that existed nowhere in the platform), deterministic task refs (inv_<orderId>/pay_<ledgerId>/cn_<ledgerId>) so replans and overlapping emissions collapse; non-sale money (canteen top-ups/B2B) and order-less charges become VISIBLE skipped tasks, never silent drops. (2) Isolated store (databases/accounting-sync.json — tasks + the external-id ledger ("our doc X = provider doc Y") + per-connection cursors into the append-only domain-events store; pg-migrated for free). (3) Dispatcher (dispatcher.ts): tick = inline drainOutbox() nudge (the zero-caller relay parameter) → plan from events since cursor → claim/execute/outcome outside the store lock; hard fail-closed gates all surfaced in the result — kill-switch, connection status, owner-approved mapping required, non-mock modes blocked until the BK-7 consent ships, mock money never posted to real books; per-connection sync history on the connection card. (4) Platform self-hosted cron scheduler (lib/cron/platform-scheduler.ts + instrumentation switch): the RIE-only scheduler generalized into a neutral, data-only job registry — 5 intel jobs carried 1:1 (no double-fire) PLUS the set that never ran on the box before (domain-events relay, guardian probe, email campaigns, social autopilot, accounting sync); legacy env honoured. (5) Wave-1 document builders (order→invoice, charge→payment, refund→credit-note; BK-4 recompute + approved mapping; BK-7 upgrades fidelity). Routes: GET/POST /api/accounting/sync (status/run-now/replay, audit-logged) + GET /api/cron/accounting-sync (vercel.json */10); a Sync-activity panel with per-task Replay on /dashboard/accounting. Live-verified end-to-end on dev through the real POS route: cash-settled a seed order → outbox event → tick planned invoice+payment in FIFO → both pushed to the demo provider (invoice #87222, payment #34228) → external-id ledger recorded; re-tick planned/pushed ZERO (cursor + dedupe); an order-less refund surfaced as a visible skipped task. tsc 0; 15 new tests; full suite 3976/3976.

• Phase 50 BK-5 — financial event-spine completion: EVERY money movement now emits a transactional outbox event. Before this, only 4 of ~15 payment-ledger call-sites emitted domain events — Stripe/Swish webhook confirmations, PayPal captures, the tap-to-pay terminal, table-pay, catering deposits/balances, bar-tab settles, canteen top-ups/B2B and ALL refund paths wrote money rows the event spine never saw (and order.refunded was declared but emitted nowhere). One new helper (lib/events/ledger-events.ts emitLedgerOutboxEvent) now rides INSIDE the same row-locked mutate as every ledger write across all 13 production sites: a newly-created paid charge → payment.captured, a refund → payment.refunded, each anchored on the ledger row id (ref/meta.ledgerEntryId — the deterministic task key the BK-6 sync queue will dedupe on, which also makes historical overlapping emissions harmless), with created:false (webhook redelivery / retried confirm) never re-emitting — the emission inherits the ledger's idempotency for free. The main refund route additionally emits the first-ever `order.refunded` exactly once, on the row that flips the order fully refunded. DomainEventType gained expense.recorded + creditnote.issued (declared for BK-9/BK-7). PII posture preserved (ids + amounts + scalars only). Live-verified on dev: a real API refund landed payment.refunded on the tenant doc's outbox transactionally (anchored + charge-linked), and a retried identical refund produced NO second row and NO second event. tsc 0; full suite 3961/3961 (one POS test updated to the new intended two-event contract + a new no-re-emit test).

• Phase 50 BK-4 — mapping engine + sync-time VAT recompute + the unified CoA registry (also FIXES the latent zero-VAT books defect). Three load-bearing pieces: (1) ONE per-country chart-of-accounts registry (lib/accounting/mapping/coa-registry.ts) from which BOTH historical SE BAS maps now derive — DEFAULT_SE_ACCOUNTS (SIE export) and SE_BAS_ACCOUNTS (revenue-share journal) can never drift apart again; drift-pin tests assert the pre-migration literals verbatim (incl. the deliberate 2641-purchases vs 2640-fees input-VAT nuance, preserved not "fixed"); the full 3955-test suite passes untouched. (2) Sync-time whole-order VAT recompute (vat-recompute.ts): Order.taxAmount is 0 on every real sales channel (VAT-inclusive pricing — verified in the Phase 50 recon), so the Phase 19 books reported ZERO VAT for real orders; the bookkeeping route now recomputes per order (Order.type → VatCategory → dated resolveVat, counter=dine-in, stored positive tax trusted, unsupported jurisdictions flagged never guess-stripped, purchases NEVER recomputed — input VAT is not invented) and CSV/SIE/P&L/VAT-return all inherit the fix through the one wire-in. Live-verified on seed: luigi's books went from 0 to 3,353.93 SEK output VAT across 77 sales, recomputed rows landing on the dated 12%/6% SE rates. (3) Mapping engine + owner approval (engine.ts + GET/PUT /api/accounting/mapping + a mapping panel on /dashboard/accounting): registry defaults layered under per-tenant overrides, DETERMINISTIC suggestions against the BK-3 imported chart (exact/missing — no AI decides anything), one-click Approve, and an append-only old+new-value MappingHistoryEntry trail where a change after approval re-opens review. Live-verified end-to-end: 14/14 exact matches after refresh, approve → override (reopens + history before/after) → reset + reapprove. New TenantDB additive field accountingMapping. tsc 0; 20 new tests; full suite 3955/3955.

• Phase 50 BK-3 — post-connect company bootstrap ("the system configures itself"). Every connect now auto-pulls (fire-and-forget, guarded — a bootstrap hiccup can never fail a connect) the provider's company identity, REAL chart of accounts, VAT codes and fiscal years into an AccountingBootstrapCache on the connection — the snapshot the BK-4 mapping engine will suggest against, so the owner only ever clicks Approve. POST /api/accounting/bootstrap = "Refresh company data" (also a button on the connected card, which now shows N accounts · M VAT codes · K fiscal years + org number). Failure posture: company-info failure fails the refresh but KEEPS the previous good snapshot with the error recorded beside it; unsupported list-reads degrade to empty lists. Public views expose counts + fiscal years, never raw dumps. Live-verified on dev: bootstrap over the demo connection returns 13 BAS accounts / 5 VAT codes / 2 fiscal years and the status API serves the summarized view. tsc 0; 4 new tests (53 accounting total).

• Phase 50 BK-2 — `/dashboard/accounting` one-click connect UI + the OAuth route quartet (audited). The tenant-facing face of the accounting platform: a provider grid for the tenant's market (SE sees Fortnox/Visma + globals; NO sees Tripletex — driven by the def-table country map) with three connect shapes — Google-style OAuth redirect (POST /api/accounting/connect → authorize URL → GET /api/accounting/oauth/[provider]/callback → ?connected=1 bounce), paste-credential form for token providers (POST /api/accounting/credentials, secrets encrypted, never echoed), and a one-click Restora Books demo connect — plus a connected status card (mode badge Demo/Sandbox/Live, status pill incl. an explicit Reconnect-needed state with a reconnect CTA — the expired-token UX the Google integration never had), sync-history list and disconnect. Flag-gated by the master switch ({ skipped:true } → not-available panel; nav stays visible per repo convention). New nav entry beside Bookkeeping. ActivityType gained an additive integration member; connect AND disconnect write both audit tiers (master audit log with IP + tenant activity feed) — fixing the documented Google-integration anti-pattern. Verified END-TO-END against the running dev app: flag OFF → {skipped}; admin flip → provider grid; demo connect → record created; Fortnox mock OAuth → 302 ?connected=1&mode=mock, connection REPLACED in place (one-per-legal-entity invariant held live), refresh token AES-GCM-encrypted on disk, zero token fields in any API response; disconnect → revoked + reconnect works; both audit trails carry all four events. tsc 0; page renders 200.

• Phase 50 BK-1 — accounting connections + token vault + rotation-safe refresh (all 4 authKinds). The connect layer under the universal accounting platform: a new isolated databases/accounting-connections.json store (lib/accounting/connections-db.ts, Google-store clone with a scope key — tenant:<id> default, org:<id> for chains — one ACTIVE connection per LEGAL ENTITY; pure mutation core unit-tested, reconnect preserves id+sync-history, resolver = own-connection-wins-then-org, toPublicConnection never leaks token material). Provider-parameterized OAuth (connect/oauth.ts: declarative endpoint/scope/env config table for Fortnox/Visma/Xero/QBO, HMAC stateless state + PKCE, mock-mode-first with RELATIVE mock callbacks; mock refresh deliberately ROTATES the refresh token every call so Fortnox semantics are exercised on seed). The rotation-safe token service (connect/token-service.ts) fixes what Google's pattern gets wrong for single-use tokens: cached access tokens (ordinary calls never touch rotation), per-connection single-flight refresh, compare-and-set persistence of the rotated refresh token (CAS mismatch adopts the other writer's state instead of clobbering — never bricks a Fortnox connection), grant-level rejections → formal reauth_required status that short-circuits instead of retry-looping, session-minted (Tripletex) mint-and-cache with an injectable minter. Connection lifecycle facade (connect/service.ts): redirect / paste-credentials / one-click-demo connect shapes, fail-closed sandbox unless ACCOUNTING_LIVE_MODE=live, e-conomic demo/demo → mock-mode connection, disconnect wipes token material and keeps a revoked record for history. Verified: tsc 0; 26 new tests (49 accounting total) incl. a concurrency test proving exactly one refresh under parallel callers.

• Phase 50 BK-0 — Universal Accounting Integration Platform: provider contract + registry + mock provider + master kill-switch. The keystone of the connect-once accounting platform (plan: docs/products/accounting-integrations/PHASE-50-UNIVERSAL-ACCOUNTING-INTEGRATION-PLATFORM-PLAN.md): ONE provider-agnostic AccountingProviderAdapter contract (lib/accounting/types.ts — uniform CallResult envelope with a typed retriable-vs-fatal error taxonomy the sync queue will key on) + a declarative provider def table (provider-defs.ts — Fortnox/Visma eEkonomi/e-conomic/Tripletex/Xero/QBO with verified authKinds and rate budgets: Fortnox oauth-rotating 25 req/5s, Visma oauth-stable 600/min, e-conomic static-grant, Tripletex session-minted, Xero 5k/day cap) + a fail-loud resolution seam (registry.ts, mirrors payments/registry.ts: mock serves everything on seed, sandbox/live throws until a real adapter registers in BK-8 — never silently mock-posts real books) + the full "Restora Books" demo provider (mock-provider.ts: BAS chart aligned with the two existing SE account maps, Swedish VAT codes, strict idempotency — same externalRef → same remoteId + duplicate:true — balanced-legs/consistent-totals validation, payments reject unknown invoices to exercise BK-6 FIFO ordering; hard-blocked from ever resolving outside mock mode) + the accounting_sync_enabled master kill-switch (flag.ts clone of the ITA pattern, fail-safe OFF, strictly binary) with GET/POST /api/admin/accounting/master-switch (super-admin, audit-logged). Verified: tsc 0 project-wide; 23 new node:test cases pass.

• Import-learning loop (Phase IL) — foundation + capture (shared by menu imports AND WoW web clones; one anonymous, platform-wide store, no parallel engine). Every import now teaches the next one: the system records the delta between what the AI extracted and what the owner approved, so future imports get less defective and cover more scenarios. This phase lands the substrate + capture; distillation → replay → coverage dashboard follow.

- Shared substrate — new ImportLearningSignal / ImportItemDelta / ImportScenario / ImportCorrectionRule types + MasterDB.importLearningSignals|importScenarios|importCorrectionRules (signals capped to a rolling 500; scenarios are tiny per-bucket rows). CloneRecord.issues now links each clone's deterministic migration defects into the same loop. - Pure signal engine (lib/import-learning/signal.ts) — diffs the AI extraction against the owner-approved menu: pairs items (exact then token-overlap so a renamed dish isn't counted as drop+add), and records structural deltas only — a name edit's kind (cased/cleaned/reworded/other), a price edit (keeping the printed format text like 85:- because that's the biggest parse signal, never restaurant-identifying), dropped items, and per-item confidence. Best-effort currency + language detection feeds a source × language × currency × cuisine coverage key. 8 unit tests. - Anonymous by construction — no raw dish/description text is ever stored; learning is platform-wide but only as patterns, honouring the "never copy one restaurant's data into another / never fabricate" rule. - Wired both sources, fully guarded — the authenticated menu/ai-import route captures the delta fire-and-forget (the review modal now snapshots the raw extraction, crops stripped, and sends it); the WoW clone path (recordClone) links its migration issues + folds a coverage signal into the shared store. Any capture failure is swallowed — it can never affect a real import or clone. - Self-improving core — distil + apply (`distill.ts` + `apply.ts`). Signals are distilled (≥3-agree threshold, mirroring the clone loop) into ImportCorrectionRules: recurring price formats per currency (the Swedish 85:- / comma-decimal / space-thousands patterns), a scenario's dominant currency, and a learned confidence-gate (when owners kept correcting items the model was confident about). Distillation runs in the same guarded mutation as capture; it preserves curated rules + learned hit counts and drops rules that fall back below threshold. Rules are applied as a SAFE, fixed-template hint block appended to the extraction prompt — format/currency guidance only, never tenant content, always carrying an anti-fabrication guardrail — selected by the import's pre-extraction context (source + the tenant's own currency, both known up front) so future imports make fewer of the mistakes owners previously fixed. The menu/ai-extract route fetches + injects the hints and credits a hit per applied rule; runMenuExtraction/extractMenuFromText gained an additive learnedHints seam (empty = byte-identical behaviour). Rules never rewrite an owner's prices/names/allergens — they only change how the model is guided and what gets flagged. - Verified: tsc 0; eslint 0 on changed files; 135 tests (import-learning + menu-import + wow) pass (17 in import-learning). Note: the hint's effect on extraction is inherently probabilistic (LLM-in-the-loop) — the plumbing/selection/rendering is fully unit-tested; real-menu accuracy uplift is a go-live validation. - Strategy EXECUTION (Phase IS) — a taught strategy actually fetches the menu. execute-strategy.ts turns a matched handling strategy into a real menu: resolveSourceUrls finds the taught source on the page (by the generalisable locator), then the existing extractors go get it — fetchPdfDataUrl fetches + (one hop) follows a PDF‑viewer plugin's embedded PDF, incl. dearpdf's JSON‑escaped config URL (findEmbeddedPdf), then runMenuExtraction OCRs it; sub‑pages go through extractMenuFromText. Wired into run-url-clone as a best‑effort job: detect signature → match a learned strategy → execute → the strategy menu leads the richest‑menu pick (a taught PDF is the source‑of‑truth). safeFetch gained a buffer() for binary payloads. Bounded (≤3 sources, PDF size cap) + fully guarded. Live‑verified on 400grader.nu: the clone now resolves the dearpdf link → follows it → extracts the embedded MENY‑…‑.pdf → fetches the real 495KB PDF; the OCR step then returns 401 invalid x-api-key because THIS dev box's Anthropic key is invalid (a known box issue) — on a box with a valid key it OCRs the menu. 6 tests (resolver + escaped‑PDF config). tsc 0, eslint 0, 36 import‑learning tests. - Teach‑the‑importer UI (Phase IS) — point at the menu, don't type. /admin/dashboard/import-learning/teach: paste a URL → strategy/analyze fetches the page (no AI cost), shows what the system sees (CMS, plugins, JS‑vs‑HTML, text density, archetype key) + a plain‑language diagnosis of where the menu likely hides + any already‑learned strategy → and pre‑detects the likely menu sources (extractSourceCandidates: the PDF link, sub‑pages, the third‑party ordering host) as one‑click cards (PDF/external pre‑selected, anchor‑noise filtered). You tick the real source(s) — optionally add one the detector missed — and "Teach the system" saves a generalisable strategy (strategy route → recordStrategy), reinforcing the bucket for that signature. A live "what the system has learned" list. An in‑page "How to teach" guide keeps the input structural — teach stable patterns that recur (​.pdf, weiq.app, lunch), not one‑off URLs or random words — with a live hint showing whether a manual pattern will match by URL‑part or link‑text. Verified end‑to‑end on the real 400grader.nu: analyze → detects wordpress|pdf+ext + the dearpdf PDF + weiq candidates → teach → re‑analyze returns a strong match. tsc 0, eslint 0, 32 tests. Next: the fetch‑execution layer (actually go get the taught PDF/sub‑page and OCR it). - Teachable clone-HANDLING strategies (Phase IS) — the learning brain. The URL/clone import fails on most real sites because the menu isn't homepage HTML — it's a PDF, an image, behind tabs, on a sub-page, on a third-party ordering service, or JS-rendered (diagnosed live on 400grader.nu: the clone got 0/‑menu items because the à-la-carte is a dearpdf PDF + a weiq.app SPA). Rather than hardcode a handler per site, this is the foundation of a system you TEACH once per site-type and it generalises: detectSiteSignature (pure) fingerprints a site structurally (CMS, plugins, SPA-vs-HTML, text density, PDF/menu/ordering links); signatureKey groups by handling archetype (e.g. wordpress|pdf+ext); matchStrategy applies a learned strategy to a new site (strong when the archetype matches, weak on partial overlap); recordStrategy teaches/reinforces a MenuSourceStrategy[] (kinds: pdf / images-ocr / tabs / sub-page / external-service / page-text / homepage-vision) into the dedicated store, reinforcing (taughtCount++) the same bucket so a second dearpdf pizzeria strengthens one strategy instead of fragmenting. Types + strategies added to ImportLearningDB; 4 tests over a 400grader-like fixture; tsc 0, eslint 0. Next: the teaching UI (point it at the real menu per site) + the fetch-execution layer (reuse the existing PDF/screenshot/text extractors to actually go get it). - Export path — trained rules ship as code (`trained-rules.ts`). So a training campaign's knowledge travels to production via git, not a fragile runtime-DB copy. GET /api/admin/import-learning/export (super-admin) renders the exact replacement for src/lib/import-learning/trained-rules.ts (learned rules frozen to curated, hits zeroed, seeds dropped, sorted) — JSON summary or ?format=file download; a dashboard "Export rules ↓" button. The bundled TRAINED_RULES load at read time between the seed defaults and the live store (seed < trained < store), so a fresh deploy starts already-smart. Pure export.ts (normalize + file-render) with 3 tests; tsc 0, eslint 0; live-verified (endpoint returns valid file content). - "Train the importer" surface (super-admin, tenant-less). A pre-launch training tool at /admin/dashboard/import-learning/train: drop in a menu (photos/PDF) or a menu URL → the SAME extractor runs (with learned hints applied) → correct the reading (fix prices/names, untick invented items) → record. Two routes (train/extract + train/record, super-admin-gated) run extraction and capture the extracted-vs-corrected signal into the dedicated store WITHOUT creating a tenant or a menu — pure "analyse → correct → teach, one at a time", so a rich rule set can be built before go-live. Confidence-flag threshold is the learned one; a running signal/rule counter + dashboard link. tsc 0, eslint 0; live-verified (extract responds, record writes a real signal to the store). - Dedicated persistent store (`databases/import-learning.json`). Moved the signals/scenarios/rules OUT of the hot master.json doc into their own store (ImportLearningDB + getImportLearningDB/mutateImportLearningDB, Postgres-doc + fs-file with a write lock), so a long pre-launch training campaign accumulates cleanly, survives deploys, and isn't fighting the master doc's size. The rolling signal cap was raised 500 → 5000 (distilled rules persist beyond it regardless). Store + admin route + distiller rewired to the new DB; tsc 0, eslint 0, 24 import-learning tests pass; live-verified on the dev box — the store file is created + written on a real import, the dashboard reads it, and the cutover from the old master location works. - Day-one usefulness + clone coverage + review flagging. The loop no longer waits for ≥3 organic corrections before it helps: a small set of curated seed rules (seed-rules.ts — SEK 85:-, EUR/NOK/DKK comma-decimals) is merged in at read time so a brand-new tenant gets the right format hint on its first import; a seed materialises into the DB (with hit tracking) the first time it's actually applied, and shows in the dashboard from day one. The WoW clone path now consumes the same hints — run-url-clone infers the currency from the site's country-code TLD (.se→SEK, generic TLDs → source-only) and feeds learned hints into both clone extractors (text pages + vision tiles). And the learned confidence-gate is now deterministic, not just a prompt nudge: ai-extract returns a learned reviewBelow (computed post-extraction once language is known) and the review modal flags items below that threshold instead of a hardcoded 70. Verified: tsc 0; eslint 0; 142 tests (5 new); live smoke — admin/ai-extract 401, wow-from-url 400 (all compile + respond).

• WoW import — Wave 1 accuracy + "Migrate MY site" mode (reuse-and-advance of the existing clone/menu-import path; behind `wowFunnel`, default behaviour unchanged). Closes the biggest "this isn't my site" gaps the recon flagged ("vibe clone, not a migration"), by wiring already-built machinery into the clone path — no parallel engine.

- "Migrate MY site" mode (W2.6) — new additive WowPreview.migrateMode (default false = the trademark-safe competitor-clone behaviour, byte-identical). The Health Check rebuild (HealthCheckClient) now sends migrateMode:true because the owner just audited their own site, so the claim imports the real brand name/tagline/contact/hero instead of an invented name + Stockholm demo contact + stock hero: claim.ts skips the demo-contact clobber when migrateMode (real menu.info carried by applyPreviewThemeToTenant survives); from-url accepts the migrateMode body flag. - Full-page Design DNA (W1.1) — generateDesignDna now reads the whole scroll-and-shoot page (new imageDataUrls[]), not just the hero, so sectionOrder reflects below-the-fold design instead of the model guessing. Single-screenshot path (imageDataUrl) unchanged. - Real-pixel palette anchors (W1.2) — the deterministic palette.ts sampler (dominantAccentColor/averageColor, no AI) reads the hero's real pixels and passes them as anchors in the DNA prompt, so the palette is grounded in the brand's actual colours rather than a one-shot mood-guess. - Real hero image (W1.5) — new deriveSiteMeta() extracts the owner's og:image; used as the page hero only in migrate mode (never reuse a competitor's image), with the curated cuisine stock as the fallback. Also imports the real meta-description as the hero tagline in migrate mode. - Allergen suggestions at import (W1.3), safety-gated — the clone import now computes deterministic EU-14 allergen suggestions (suggestItemAllergens, no AI) and stores them as the unconfirmed Product.suggestedAllergens — never written to live allergens. The product editor surfaces them as tap-to-confirm chips; the storefront still reads only allergens, so nothing is asserted without the owner's OK. - Photo quality at import (W1.4) — new scoreProductPhotosInBackground() (bounded concurrency, budget-capped, fail-open) runs the broken-image + quality verdict on freshly imported photos at clone-claim and the authenticated ai-import, so expired/broken stock photos get held instead of shipping live. - Verified: tsc 0; 182 tests (wow/menu-import/menu/bazar) pass; eslint 0 errors on changed files. next build runs on the Linux deploy server (this box OOMs). Allergen never-LLM + flag-for-review-not-invent rules preserved. Remaining Waves 2–3 (JSON-LD free-tier reader, DOM/CSS design reader, image relevance-gate, confidence/migration-report + review gate, full-site crawl/multi-page, SEO redirects, render-compare) tracked separately.

• AI budget transparency page + custom top-up amount (owner-facing spend breakdown; every top-up itemized on the invoice). Extends the AI budget pill so owners can see exactly where their AI money goes and top up any amount they like — not just the fixed Small/Medium/Large packs.

- Transparency page `/dashboard/ai-spend` (new "AI Spend" item under Account, plus a "See where your AI budget goes →" link from the budget pill). Shows: this month's remaining/used/limit hero (same figures as the pill); "Where your AI budget goes" — a per-feature breakdown (AI Assistant, Menu Photo Import, Social Posts, CFO Advisor, …) with owner-currency amounts + request counts + share bars, month-selectable; a 12-month usage trend; monthly + yearly top-up statements (each purchase listed with date, amount, allowance, and its AITOP-… invoice number) with lifetime totals; and a plain-language "how AI billing works" explainer. New pure aggregation lib lib/ai/tenant-spend.ts (aggregateTenantAISpend — feature breakdown, trend, statements, lifetime, all currency-converted) + a strictly tenant-isolated DB wrapper, behind GET /api/tenant/[tenantId]/ai-spend (requireTenantAccess). - Custom top-up amount. Alongside the packs, owners can type any amount (e.g. 1000 kr) in the pill and on the page. New usdFromOwnerAmount inverts the FX×1.5 markup so the granted USD allowance round-trips back to the price paid ("every 1 kr you add is 1 kr of AI"); buildCustomTopup validates against a currency-converted band (customTopupBounds). The dev path grants immediately; prod opens Stripe Checkout in the tenant's currency. - Top-ups go directly + show on the invoice. Each top-up is recorded as a paid invoice the moment it's charged (InvoiceRecord.category:'ai-topup' + aiAllowanceUsd, additive) and now appears in Billing → Invoice History correctly currency-formatted and tagged "AI top-up", as well as in the page's monthly/yearly statements. - Fixed a pre-existing PROD gap: the Stripe webhook's checkout.session.completed handler ignored kind:'ai-topup' sessions — a prod top-up charged the card but never granted allowance or wrote an invoice. The webhook now grants + records on payment, idempotently on the Stripe session id (and surfaces a billing.ai_topup.orphan integrity event rather than silently 200-ing if metadata is unfulfillable). Stripe amounts now go through toMinor/fromMinor so zero-decimal currencies (e.g. JPY) aren't overcharged 100×. - Verified: 21 new tests (top-up math/round-trip/bounds + tenant-spend aggregation incl. mixed-currency safety); tsc 0; eslint 0 (changed files). Adversarially reviewed (5 dimensions × verify) — 12 confirmed findings fixed, incl. making recordTopupPurchase's check-then-write atomic via mutateMasterDB (no double-grant/lost-update under concurrent webhook retries; rolls the invoice back if the allowance grant fails), currency-safe statement/lifetime totals (never cross-sum currencies; off-currency entries counted + noted), and a full a11y pass on the new controls (input labels, live-region banner, aria-expanded/aria-pressed, touch-readable trend bars, integer-only custom input).

• Customer order-tracking ("live order status") screen — 1:1 redesign from the design handoff (3 owner-selectable templates, brand-themed, real data). Rebuilt the customer "waiting for your order" screen (/track/[tenantId]/[orderId]) 1:1 from docs/Order Status Redesign, as three interchangeable visual directions sharing one data interface: A · Wood-Fired (default — circular progress ring + rising steam + clustered dish preview with "+N" overflow + live ETA countdown + itemized list), B · The Journey (a travelling bag/scooter token bobbing along an animated road between status stops + live activity feed), C · Big Moment (dark espresso card, flickering flame, glowing shimmering progress bar). New shared engine lib/order-tracking/ — types.ts (one TrackingViewModel contract), theme.ts (resolveTrackingTheme() maps each restaurant's brand — preset or premium 9-token palette — into concrete colours with the warm "Luigi's" palette as fallback; pure colour utils mix/luminance/contrastRatio/readableOn/accentText/rgba), model.ts (step model, status→copy maps generalized for multi-tenant, live ETA, the brand-accent rule, item/hero/activity derivation). Presentational templates components/order-tracking/TrackingTemplate{A,B,C}.tsx + design-specific bag/scooter icons + scoped keyframes. Wired to the real system, not a parallel demo: the rewritten TrackerClient fetches the real order, derives the model, runs a single live ETA countdown to a real promisedReadyAt ((preparingStartedAt ?? acceptedAt ?? createdAt) + 20min pickup / 35min delivery, or a scheduled slot), adapts pickup vs delivery labels/icons/final-steps from order.type, handles loading / error / canceled-refunded / locked states, keeps the existing refresh/share/copy/cancel actions, and honours prefers-reduced-motion (freezes all loops, transitions stay instant) + an aria-live status region. The public order API now returns type/scheduledTime/preparationTimeMinutes; page.tsx resolves the theme+template and loads Baloo 2 / DM Sans. Owner picker: additive TenantSettings.orderTrackingTemplate ('A'|'B'|'C', default A) persisted via the builder PATCH/GET, with a themed "Order tracking style" A/B/C card picker in the Mason theme panel. Verified: headless render screenshot-compared 1:1 to the prototype across all 5 statuses × pickup/delivery; 49 tests (model + per-template render matrix + contrast regressions); tsc 0. Adversarially reviewed (4 dimensions × verify) — 8 confirmed findings fixed, incl. WCAG-AA contrast on dark/bright brand presets (readableOn/accentText keep the white-check 1:1 look on warm/red brands but flip to legible glyphs on amber/dark-red), a non-chatty aria-live (announces the status word, not the per-second countdown), and reduced-motion now also freezing the loading skeleton.

- Fixed (same day): the hero "single vs cluster" decision now keys off total quantity, not line-item count — so a single dish ordered ×2+ (e.g. "2× Marinara") shows the multi-dish cluster (2 small thumbnails + "N items") instead of the single "food photo" hero. The "+N" overflow uses the same unit total so "2 shown + N more = N items" stays consistent. - Real dish photos (same day): the hero cluster thumbnails, the single-item hero, and the itemized-list thumbnails now render each line's real menu photo — joined from the live product by productId in the public order API (items[].imageUrl) — with the striped placeholder kept as a graceful fallback when a product has no image. Direction A only (B/C have no dish thumbnails).

• Mason builder — container nesting Stage-2 foundation (the 5 layout containers now accept children). The data + adapter + editor-tree already round-trip nested content.children losslessly (unit-tested); this flips acceptsChildren:true for the 5 layout containers (columns / grid / stack / container / section) via an additive def() param + a new isContainerBlock(type) helper, and updates the catalog test. Pure metadata — byte-identical runtime (nothing renders children yet; the gated recursive render + the "Add inside" editing are the next slices). Verified zero existing tenant/template blocks of these types, so the render slice will be purely additive. 319 mason tests; tsc 0; eslint clean.
• Free Growth (Revenue Share) — the two deferred UI mounts wired in (flag-gated, inert until enabled). The RS-0…RS-8 engine + components were already built; this connects them to their surfaces: RevenueShareBanner now renders atop the tenant Billing page when the tenant is on the free-growth-7pct plan, and PlanComparison (Free Growth vs flat, with the honest break-even note) renders on the register flow when the revenue_share_billing master flag is on — via a new read-only GET /api/public/revenue-share/enabled (fail-safe to off). Both are inert by default, so the billing + register surfaces are byte-identical until the offering is enabled. tsc 0; eslint clean.
• Phase 37 (Vertical Modules II) — Weigh-and-Pay pricing engine + `Product.weighPricing` (mock-first, parallel-safe). The price-by-weight keystone for self-serve / counter products. New pure lib/weigh/ engine — computeWeighLineItem (gross → tare → net grams × price/kg with market rounding [cents/tenth/whole], every input clamped so a bad scale reading can never charge negative, and an optional min-net floor that applies only to positive sales) + weighCartLine (shaped 1:1 like CateringLineItem, so a weighed item flows straight into the existing order/ledger path). Additive optional Product.weighPricing on the menu model — absent ⇒ ordinary per-unit pricing, zero behaviour change to any existing menu — with a lib/weigh/product.ts adapter (isWeighProduct / weighLineForProduct, returning null so callers fall back to basePrice). Product is imported type-only, keeping the engine DB-free and unit-testable. WS-2 — owner control: a "Sell by weight" section in the product editor (price/kg + tare + rounding, with a live price preview), the field whitelisted through the products create/update API and sanitized server-side (sanitizeWeighPricing clamps + drops junk) + round-tripped via GET, plus a /kg price cue on the menu list. WS-3 — weigh-and-pay checkout: the POS PriceQuote engine is now weigh-aware (a by-weight line is priced server-side from price/kg × scale grams; additive — normal items stay byte-identical), the staff POS route accepts grossGrams, and a new Weigh Station (/dashboard/weigh + sidebar nav) builds a weighed ticket and takes payment through the existing born-paid POS pipeline (unified ledger + loyalty + stock; mock until Phase 40). Real scale hardware deferred (Phase 38). WS-4 — self-serve customer kiosk: a public, read-only weigh kiosk (/kiosk/[tenantId]/weigh) where the customer weighs items, sees live prices, and prints a “pay at the counter” slip — it takes no money and writes no order (the staff POS finalises the sale, safe by construction), backed by a reusable receipt model (lib/weigh/receipt.ts) + a read-only GET /api/public/[tenantId]/weigh/products. WS-5 — hardening: the public kiosk is now opt-in per tenant (settings.weighKioskEnabled, default off — the page + its public endpoint 403 until the owner enables it), the endpoint is rate-limited (60/min/IP), and the staff Weigh Station gets an owner toggle + the kiosk link. WS-6 — scan-to-recall: the kiosk slip now carries a stateless code + QR that encodes the weighed basket itself (no server write, no public endpoint); staff scan or paste it at the Weigh Station to recall the exact lines — no re-weighing (lib/weigh/slip.ts, checksum-guarded; the station re-prices server-side on charge). tsc 0; eslint clean; weigh + price-quote suites green. Commits cce98d3e (WS-0) · 08830bf3 (WS-1) · WS-2 · WS-3 · WS-4 · WS-5 · WS-6 (this entry).
• FSN Global Kitchen — 700-dish multilingual launch library + Restora 360 redesign (web-first). Net-new curated content + the start of the FSN visual overhaul. tsc 0 errors.

- Dish library (data): new DishMaster + DishLibraryDB (lib/db/schema.ts) in its own dish-library app-document, with getDishLibraryDB/save/mutate accessors (cached; auto-imports to Postgres via db:import). 700 dishes = 25 countries × 7 breakfast/lunch/dinner/snack, each with name/description/ingredients/steps in en·sv·da·fi·no, authored per-serving nutrition (flagged estimate — NOT a parallel nutrition engine), dietary tags + allergen advisory. Generated via a multi-agent workflow, committed as scripts/data/dish-library.seed.json; seeded by scripts/seed-dish-library.ts (npm run seed:dishes). - Images — correct + unique on all 700. Hybrid pipeline (scripts/dish-library/images.mjs + images-gen.mjs): real stock (Pixabay·Wikimedia·Openverse) keyword-gated + globally de-duplicated + Gemini-vision-verified (482), then Imagen generation for the remainder (218), each vision-checked and downscaled to ~150 KB JPEG in public/global-media/. 0 placeholders, 0 duplicate images. - Surfaces: /fsn/kitchen (discover by country/meal/language + search), /fsn/kitchen/[id] (localized recipe + nutrition + schema.org/Recipe JSON-LD), /fsn/eat-today (AI day-plan: kcal target + macro bar + per-meal picks), public /api/fsn/dishes (+ /[id]) read API (also for the Android app later), and 75 dishes promoted into the FSN feed as recipe posts by 12 curated home cooks (scripts/seed-fsn-kitchen-feed.ts). A standalone HTML review doc is produced by scripts/dish-library/build-html.mjs. - Restora 360 design system (foundation): scoped .fsn-r360 tokens + dark mode (app/fsn/r360-theme.css) ported 1:1 from the design handoff (clay primary, warm-paper Stone, Hanken Grotesk / Newsreader / Geist Mono via next/font); FsnShell chrome + the Global Kitchen / dish / Eat-today screens re-skinned off the tokens. Remaining FSN screens (feed/reels/profile/articles) get the new chrome now and full per-screen re-skins next.

• Phase 36 — Vertical Modules I (Catering · Bars · Canteens): the deferred full feature scope, completing the three gap-audience modules. Mock-first on the Phase-33 ledger; additive; tsc 0; full suite 3405/3405; next build exit 0. The keystone slice of each module shipped earlier; Phase 36 finishes the rest. Built foundation + money-critical engines by hand, fanned the routes/UI out across 3 parallel module agents, then hardened via a 5-agent adversarial money-model review (6 real fixes applied, below).

- Catering — package & menu builder, contracts, BEO, final invoice. New pure engine fns (packageLineItem, buildContract/acceptContract [click-sign + a non-PII assent fingerprint], buildBeo/sortedBeoTasks/beoProgress, buildInvoiceRef) + documents.ts buildCateringInvoiceModel (reuses the shared pdf-lib faktura renderer — the deposit already captured is shown as a credit line so "att betala" = the remaining balance, VAT charged on the full event). Routes: packages CRUD + apply-package; contract (issue / accept / void); beo (generate + checkable task list); invoice (issue → CAT-INV-####) + invoice/pdf; balance (take the remaining balance → source:'catering-balance'). Dashboard detail pane gains a Packages manager, a Contract card (generate → terms → click-sign), a BEO run-sheet with a progress bar, and an Invoice card (issue + Download PDF + take balance). An accepted contract freezes the quote (item/delivery edits + apply-package + re-issue are 409'd until voided). - Bar — pre-auth, happy-hour automation, fast-pour grid, rounds, split-by-seat/item, refusals. New engine: happy-hour pricing (activeHappyHour/happyHourPrice/resolveQuickAddPrice — day-of-week + time windows incl. midnight-wrap, percent/fixed/price, first-match), a mock pre-auth hold lifecycle (buildPreAuth/markPreAuthCaptured/markPreAuthReleased — moves NO money; the capture at settle is the only ledger charge), nextRound/groupByRound, seatSubtotal/itemsSubtotal, canSettleTab (age gate), normalizeFastPour. Routes: bar/config (happy-hours + fast-pour + age-gate + default hold), bar/refusals; tabs gains a pre-auth hold on open + set-preauth; add-items stamps a round + seat + the happy-hour-resolved price; settle adds split-by-seat / split-by-item, an age-gate block (402), and pre-auth capture. Dashboard: a fast-pour grid, a happy-hour/fast-pour/age settings panel, an items-by-round view with seat tags + happy-hour badges, a split-mode picker, and a refusal log. - Canteen — employer/school groups, subsidy rules, meal-plan allowances, daypart menus, B2B invoicing. New engine: resolveSubsidy/resolveAllowance (account-override → group → config-default), computeSubsidySplit (percent / fixed-per-meal / fixed-per-day + daily cap; both shares ≥0 and sum to the meal), checkAllowance (day/week/month period caps + meals cap), activeDaypart, billableAccruals/buildB2BInvoice + documents.ts buildCanteenB2BInvoiceModel. The subsidy money model: at the till the diner's wallet covers only the post-subsidy share; the employer/school share accrues as a receivable (canteenSubsidyAccruals, NOT a wallet debit, NOT a ledger charge) — wired into the POS meal seam, backward-compatible (no group → identical to before). The receivable is billed via a B2B invoice (accruals stamped atomically so they can't be double-billed); the group's payment is the one real cash event (source:'canteen-b2b', idempotent, created-gated). Routes: groups CRUD (+ billable preview), config (dayparts + defaults), per-account group/subsidy/allowance overrides, b2b-invoices (issue / pay / pdf). Dashboard gains Groups, Dayparts & Defaults, and Invoices surfaces.

• Fixed (Phase 36 adversarial review — money-model hardening):

- Revenue double-count of the canteen subsidy. A canteen-b2b ledger charge is the collection of a receivable for meals already recognised as revenue (via order.total at meal time) — not a new diner-facing sale. It was being counted as gross sales + levied a platform fee + commissioned. Now excluded everywhere canteen-topup is (revenue-share settlementFromLedgerEntry + reporting, summarizeOrderCommissions, the usage meter, and surfaced under summarizeLedger's non-sale breakout). Regression tests added. - Bar settle TOCTOU. Settle re-read the stale pre-lock tab.subtotal for the balance/close decision; a concurrent add-items (a new round) could close a tab with the new drinks unpaid. Now re-reads the fresh tab subtotal inside the lock (mirroring the POS settle). - Catering VAT zeroed on re-quote. The PATCH + apply-package recompute hard-coded taxRatePct: 0, silently dropping VAT for a tenant with cateringConfig.taxRatePct > 0. Both now use the configured rate (matching the create path). - Catering deposit / balance over-collection. Both posted the pre-lock amount with no in-lock re-clamp → a concurrent double-submit could collect past the due. Both now re-clamp against freshly-captured inside the lock; the deposit route also gates its state/timeline leg on the ledger created flag. - Catering contract integrity. An accepted contract is now frozen (re-issue 409'd; quote edits/apply-package blocked) with an explicit void (DELETE) to unlock; the invoice PDF 404s until an invoice is actually issued (no provisional-number drift). - B2B ledger row no longer stamps the invoice id into orderId (per-order rollups can't accidentally match an invoice).

• Phase 35 — VC-8 (drive-thru lane) + VC-9 (POS/Waiter voice-to-order): the last two surfaces, as thin adapters over the VC-0 engine. A new shared lib/voice-concierge/turn.ts advanceTurn() runs ONE engine turn and, on a confirmed order, creates it through the SAME locked seam the phone uses (born-PENDING, OUR-menu pricing, never settle) + records the session — surface/source injected so the brain is identical across surfaces (one system). VC-8 POST /api/tenant/[tenantId]/voice-concierge/lane (tenant-auth, live-gated, HMAC-signed ConvState, per-car sessionId idempotency, source:'drive-thru') returns the running order as a board payload for a lane confirmation screen. VC-9 POST /api/tenant/[tenantId]/voice-concierge/pos-order (source:'pos'|'waiter', per-ticket idempotency) shows the read-back on screen; the staff member confirms by sending the next turn ("yes") — no auto-submit. Both inherit the engine's allergen pre-router, read-back→confirm, and signed-state guarantees verbatim. 2 tests (58 voice-concierge total); tsc 0; eslint 0. → Phase 35 surfaces VC-0…VC-9 now COMPLETE; only go-live infra remains (real Twilio numbers + STT/TTS, a live narration key, outbound channel send, a per-lane device token for unattended lanes, and flipping voice_concierge_enabled).
• Phase 35 — Voice & AI Concierge (Universal-Coverage P35): the AI voice agent, customer concierge & staff copilot — buildable scope COMPLETE (VC-0…VC-7), mock-first, behind a fail-safe-OFF master flag. ONE deterministic-first conversation engine drives every surface; the LLM is optional and structurally barred from anything safety- or money-critical. Designed via a 14-agent recon+adversarial-design Workflow (3 blockers + 6 majors baked in pre-code) and hardened by a 33-agent code-review Workflow (5 confirmed fixes applied).

- VC-0 — the Concierge Engine keystone (`lib/voice-concierge/{engine,types,entity-resolver,messages}.ts`, PURE, surface-agnostic). stepConversation(state, turn, deps) is a serializable state machine that phone / web / WhatsApp / drive-thru / POS all drive — it owns NO I/O (returns a CreateTenantOrderInput; the surface calls createTenantOrder). Reuses the SB-5 TwiML/speech helpers, computePriceQuote (OUR-menu pricing), answerMenuQuestion (deterministic menu Q&A from the feed), and the ITA resolveAllergen/resolveDietary + av.*/dv.* i18n verbatim. Safety invariants, all STRUCTURAL (not convention): (1) an allergen/dietary pre-router (entity-resolver.resolveQuery) runs BEFORE any menu/FAQ retrieval — an allergen-shaped query can never be answered by the ranker or an LLM, only by the deterministic resolver or an escalation; (2) the entity resolver requires a single unambiguous dish (name-token overlap; a tie → clarify/escalate) and maps allergen words via a FIXED lexicon — it NEVER guesses a dish on an allergen question; (3) gluten/dairy/nut/egg/soy/etc. are treated as allergen-class regardless of phrasing ("is it gluten free?" → resolveAllergen('gluten')); (4) low STT confidence on the allergen branch escalates (never resolves a misheard transcript); (5) an order reaches submit only through read-back → confirm → explicit yes (and a "yes" riding alongside a question/allergen word does NOT confirm); (6) once an allergen escalation fires, the order is latched-blocked; (7) the optional narrate LLM is invoked ONLY on no-number "chrome" replies — never an allergen verdict, a price, a quantity, or the read-back. - VC-1 — master kill-switch (`lib/voice-concierge/flag.ts`). voice_concierge_enabled FeatureFlag, fail-safe OFF, mirrors the ITA/Restora-Pay pattern 1:1 (per-key upsert under the MasterDB row lock → no clobber of the shared featureFlags array) + per-tenant TenantDB.voiceConcierge.enabled opt-out. Super-admin master-switch route (audit-logged) + tenant settings GET/PATCH ({masterEnabled, tenantEnabled, live}). - VC-2 — phone voice order surface (/api/public/voice-concierge/[tenantId]/{incoming,respond}). Per-tenant in the PATH (each restaurant points its number's webhook at its own URL — no number→tenant lookup). Twilio signature mandatory (403) and inert until Twilio + ORDER_VOICE_NUMBER are configured AND the tenant is live. Born-PENDING createTenantOrder (source:'voice', escrow:false, idempotent on voice:${CallSid}) — priced ONLY against OUR menu, never opts.settle. The threaded ConvState is HMAC-signed (twiml-order.ts) so a caller can't forge a confirm state or tamper the basket. Zero-LLM on the line by construction. A failed submit speaks an honest hand-off (never a false "confirmed") and queues a callback. - VC-3 — order voice simulator (/api/admin/voice-concierge/order-voice-sim, super-admin, read-only, no DB writes): drives the FULL free-text path so the two "Done when" conditions are CI-provable without a phone — a spoken end-to-end order, and an accurate deterministic allergen answer (plus the negative cases: ambiguous dish, misheard allergen, unmaintained profile). - VC-4 — Customer Virtual Assistant (concierge-responder.ts + the inbox concierge-reply action + a new recordAssistantReply seam in lib/channels/inbox.ts): a deterministic single-turn responder for web/WhatsApp that splits allergen tokens OUT of the P34 menu-question bucket (the verdict comes from resolveAllergen + escalates, never the feed ranker), reusing deriveReply for everything else. - VC-5 — budget-gated narration (narrate.ts): an ASYNC surface helper (resolveAIKey → getBudgetStatus → Haiku rephrase → recordAIUsage('assistant')), fail-safe to the deterministic reply on no key / over budget / any error, and gated by the same shouldNarrate barrier (never an allergen/priced reply). The phone line never imports it. - VC-6 — Staff Copilot / "virtual manager" (copilot.ts + copilot-token.ts + /api/tenant/[tenantId]/voice-concierge/copilot): deterministic NL ops — sales ("revenue vs last week") via computeAnalytics, low-stock/reorder from the threshold list — where every NUMBER is computed, never an LLM. The one mutation, "86 the salmon", is a two-step confirm-before-mutate: an ASK returns a proposal + a short-lived HMAC confirm token bound to the exact (tenant, action, dish, value); EXECUTE verifies it and writes the availability flip + a CopilotAudit row in the SAME mutateTenantDB lock (no audit ⇒ no mutation), naming the exact resolved dish (ambiguous → disambiguate, never a guessed 86). - VC-7 — owner surface: /dashboard/voice-concierge (KPIs from sessions + the staff callback queue + the live/off toggle), a deterministic honest-null insights route, and a "Voice & Concierge" nav entry (lucide Headphones) landed in the SAME commit as the page. - Schema (additive only): VoiceConciergeSession + CopilotAudit + TenantDB.{voiceConcierge, voiceConciergeSessions, copilotAudit}; Order.source widened with 'voice' | 'drive-thru'; and Product.available?: boolean declared (it was a de-facto field already honored by the Food Bazar, channel feeds, SMS/WhatsApp menus, SEO and sitemap — now the copilot's audited 86 sets it). - Money: voice/concierge orders are Restora-collected ⇒ born PENDING, priced from OUR menu, settled later via pay-link/pickup; the cross-truth invariant (computeAnalytics.totalRevenue === summarizeLedger.gross) holds because no opts.settle is ever passed on this path. - Verified: full suite 3369/3369, tsc 0, eslint 0. Remaining = go-live only (not dev): real Twilio number provisioning + STT/TTS providers (webhooks inert without them, like SB-5), a live LLM key for narration (mock/identity dep in dev), live outbound WhatsApp/IG/SMS send, and the two thin remaining surfaces VC-8 drive-thru lane + VC-9 POS voice-to-order (adapters over the existing VC-0 engine). Note: full 86 enforcement in the tenant's own storefront render + public-order rejection is a fast-follow (the flag already hides 86'd dishes across the Bazar / channels / SEO read layer).

• Phase 23 — RACM AC-2: the AI Executive Council (the last buildable slice of the autonomy capstone — RACM AC-0…AC-7 now complete). The executive-orchestration layer that sits ON TOP of AC-1's approvals queue and the Phase-22 RAOS agent workforce — it builds no second queue, second registry, or second governance engine; it READS the open governed actions + the agent catalog and decides how to rank, where agents disagree, and which coordinated multi-agent play warrants a single governed proposal.

- `lib/racm/council.ts` (PURE core — no I/O, no clock, and deliberately NO `@/lib/raos` import): convene ranks the open recommendations on a deterministic composite (RACM priorityScore lifted by shared-memory confidence); detectConflicts flags subjects where ≥2 open items pull different ways and escalates them — the council never auto-resolves a disagreement; composeChurnRescue binds the canonical retention play (Growth → Support → Marketing → Founder) to the real registered agents (a planned agent surfaces honestly as available:false); councilToProposal converts the play into one `plan.create` (L3, recommend-only) proposal — so nothing the council produces is ever autonomous. Fully unit-testable in isolation. - *`lib/racm/council-runtime.ts` (the EDGE — the ONLY AC-2 file importing `@/lib/raos/, imported only by the route, exactly mirroring the AC-4 dispatch.ts / AC-5a sync.ts precedent so the policy core never depends on the mechanism and no import cycle forms):** gathers AGENTREGISTRY` + the open queue, annotates each plan step with RAOS `decide()` (shows what governance says **without executing**), routes the play through the existing audited `proposeAction` (deduped by `meta.sourceId`; **INERT until both the RACM and RAOS master switches are on**, like AC-5a), records the convening to RAOS shared memory + the audit log (best-effort, never fatal). **Dispatch is governance-first:** the play reaches the agent bus only after a human has approved its L3 plan (we confirm an approved/executing/executed action with the matching `sourceId`), and each enqueued task is then *also* re-gated by RACM at drain time; the founder agent is subscribed to `agent.task.dead-letter` for failure escalation. - **AC-2c capped LLM "debate" (`lib/racm/council-brief.ts` + reuse of the AC-7 path):** the deterministic council brief is the SHIPPED artifact (every numeral comes from the decision — counts, top priority); the optional Haiku rephrase rides the **existing `narrateGovernanceBriefing`** (the mission-control number-guard reverts any line whose figures drift, RACM's editable daily cap, fails closed to deterministic on AI-off / no-key / over-budget). Zero new AI code, zero edits to the AC-7 files. - **Surface:** new super-admin `GET|POST /api/admin/racm/council` (read-only deliberation always available; `convene` / `dispatch` / `narrate` ops) + an **Executive Council** panel in the `/admin/racm` cockpit (convene button, the deterministic brief + AI rephrase, the coordinated plan with per-step governance + availability, escalations, ranked recommendations, bus health, an approval-gated dispatch). - **21 new tests** (ranking/tie-break, conflict-escalation, churn-rescue composition, the L3/never-autonomous bridge, brief determinism + number-guard order invariant). tsc 0; eslint 0; full suite **3345/3345**. Adversarially reviewed across 5 lenses (import-boundary, governance-correctness, type/API, AI-anti-fabrication, security) → 1 real finding fixed (approval-gated dispatch), the rest confirmed-safe. Buildable RACM scope (AC-0…AC-7) is COMPLETE; what remains is go-live infra only — deploy + wiring real agent executors into the bus's injected-executor seam._