From 7b727cec53d6eccdd278a0bf77f59e1c75f13aa5 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 10:12:10 +0330
Subject: [PATCH 01/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20Mini=20App=20c?=
 =?UTF-8?q?art=20FAB=20(v2.8.60)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 43e484f..3dffdde 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -689,6 +689,19 @@ TON-only, no EVM; backend already has tonProofService).
 
 ---
 
+### 2026-06-03 — frontend@HEAD — Mini App floating cart FAB (v2.8.60)
+
+**Why:** User wants the web shop's small edge-docked basket (count badge) in the Mini App too.
+New `TelegramCartFab` component pinned above the tab bar, shown on shop tab + in-shell seller
+shop, opens the in-shell cart. Replaced the header cart chip + bottom cart bar.
+**Pending next (user requests):** (1) Mini App «تنظیمات» — dark/light mode for the Telegram shell
+(needs a dark palette variant of telegram-shell-css + toggle; should follow webApp.colorScheme);
+(2) «درخواست جدید» button font — it is Telegram's NATIVE MainButton, font cannot be customized;
+option is replacing it with an in-shell button using the project font.
+**Verification:** tsc + eslint clean.
+
+---
+
 ### 2026-06-02 — backend@7c4dedf — complete dual-write repos, migrations pipeline, TTL scheduler, address reconciliation
 
 **Commits:** `7c4dedf` (backend v2.8.44), frontend v2.8.44

From 3cac5bd45ecbc00945611826a78dac14e276229d Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 10:35:17 +0330
Subject: [PATCH 02/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20Mini=20App=20s?=
 =?UTF-8?q?upport=20bubble=20(v2.8.61)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 3dffdde..b08294e 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -712,4 +712,16 @@ option is replacing it with an in-shell button using the project font.
 
 ---
 
+### 2026-06-03 — frontend@HEAD — Mini App floating support bubble (v2.8.61)
+
+**Why:** Parity with the web dashboard's green floating chat widget. New `TelegramSupportFab`
+(edge-docked, green bubble) on home/shop/requests tabs + in-shell seller shop; opens/creates the
+support chat. Stacks above the cart FAB in shop contexts.
+**Verification:** tsc + eslint clean.
+**In progress / queued:** Points & Referral audit (background agent — bugs observed: values render
+as "·", Bronze level claims "highest level"); Mini App dark mode (تنظیمات); buyer-parity phase 2
+(offers view/accept).
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From c663c657e298e6bdcce2e3d3be88e1a7fb7a71fc Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 10:54:04 +0330
Subject: [PATCH 03/50] =?UTF-8?q?docs:=20sync=20from=20backend=20c5d6490?=
 =?UTF-8?q?=20=E2=80=94=20points=20level=20fixes=20(v2.8.62)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index b08294e..d88465a 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -724,4 +724,19 @@ as "·", Bronze level claims "highest level"); Mini App dark mode (تنظیما
 
 ---
 
+### 2026-06-03 — backend@c5d6490 — Points & Referral audit fixes (v2.8.62)
+
+**Why (from points audit):** /dashboard/points showed "·" instead of numbers and told Bronze users
+they are at "the highest level". Root causes: (1) level boundary off-by-one — seeds define
+inclusive maxPoints (Bronze 0–999) but PG used `>` and Mongo `<`, so exact-boundary users resolved
+to no level; (2) `level_configs` table in Postgres was created but NEVER seeded → zero levels →
+null next-level → "highest level" message. Fixes: inclusive comparisons in both repos +
+self-seeding of the 5 default levels (برنز/نقره/طلا/پلاتین/الماس) in ensurePostgresLevelConfigSchema.
+**Remaining from audit:** frontend points page swallows API errors (shows zeros instead of an
+error state); integration ideas: award points on completed escrow, show points in Mini App.
+**Verification:** tsc clean, 8 tests green. Admin verifies after deploy: /dashboard/points shows
+real numbers and Bronze shows progress toward نقره.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From c61028f880f7023562b830f5bda2992e5fdd311b Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 10:57:27 +0330
Subject: [PATCH 04/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20compact=20Mini?=
 =?UTF-8?q?=20App=20FABs=20(v2.8.63)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index d88465a..ee2c76f 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -739,4 +739,12 @@ real numbers and Bronze shows progress toward نقره.
 
 ---
 
+### 2026-06-03 — frontend@131700b — compact floating cart/support FABs (v2.8.63)
+
+**Why:** User feedback — the two edge-docked FABs were too large. Compacted paddings, icons,
+badge, and stack positions.
+**Verification:** tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 23c4a717bae70b201dc0c46c063f9d987d841888 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 11:18:48 +0330
Subject: [PATCH 05/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20Mini=20App=20p?=
 =?UTF-8?q?oints=20+=20email=20verify=20(v2.8.64)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ee2c76f..ab59fec 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -747,4 +747,15 @@ badge, and stack positions.
 
 ---
 
+### 2026-06-03 — frontend@d64e194 — Mini App points view + tap-to-verify email (v2.8.64)
+
+**Why:** Buyer parity — امتیازات و رفرال now in-shell (TelegramPointsView: points cards, level
+progress, referral code copy + stats; account-tab row). Email verification from the Mini App:
+unverified badge is tappable → sends code → code-entry sheet → verifyProfileEmail → session
+refresh. Reuses existing account.ts actions.
+**Verification:** tsc + eslint clean. Test after deploy: account tab → امتیازات row; unverified
+user → tap red badge → enter emailed code → badge turns green.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From f68b54a9eff8e2963f7ac6f0c3e719cf607aa981 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 11:41:21 +0330
Subject: [PATCH 06/50] =?UTF-8?q?docs:=20sync=20from=20backend=2091877ae?=
 =?UTF-8?q?=20=E2=80=94=20points=20legacy-id=20fix=20(v2.8.63)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ab59fec..b92d80e 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -758,4 +758,13 @@ user → tap red badge → enter emailed code → badge turns green.
 
 ---
 
+### 2026-06-03 — backend@91877ae — points lookups accept legacy user ids (v2.8.63)
+
+**Why:** Mini App points view (v2.8.64) failed: every user lookup in DrizzlePointsRepo compared
+users.id (uuid) against the JWT legacy 24-hex id → uuid cast error → 500. All lookups now match
+either format (id::text = $n OR legacy_object_id = $n).
+**Verification:** tsc clean, tests green. Test after deploy: Mini App → حساب → امتیازات shows data.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From a28bcff4f42e79532085e03955f85bd02aa9ae3a Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 11:55:10 +0330
Subject: [PATCH 07/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20v2.8.65=20+=20?=
 =?UTF-8?q?Mini=20App=20UX=20queue?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index b92d80e..f4622c8 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -767,4 +767,17 @@ either format (id::text = $n OR legacy_object_id = $n).
 
 ---
 
+### 2026-06-03 — frontend@HEAD — remove MainButton, in-tab CTA, sign-in retry (v2.8.65)
+
+**Why (user requests):** (1) native Telegram MainButton removed — wrong font, duplicated CTAs;
+«+ درخواست جدید» button added inside the requests tab header instead. (2) Intermittent 503 on
+Telegram sign-in (backend redeploy windows) — sign-in now retries transient 502/503/504 3x with
+backoff and shows the Persian message.
+**Queued (user, with screenshots):** cart −=remove at qty 1; seller-shop card redesign (+ icon,
+template detail view, search/filter/sort); requests search + status-chip filters + sort; shop
+search; seller chat button; referral signup points; dark mode.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 773e2e23c4ff32103a246adddfac460516196a62 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 12:44:27 +0330
Subject: [PATCH 08/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20v2.8.66-67=20+?=
 =?UTF-8?q?=20review=20system=20audit?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index f4622c8..032d84a 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -780,4 +780,20 @@ search; seller chat button; referral signup points; dark mode.
 
 ---
 
+### 2026-06-03 — frontend v2.8.66–67 — seller chat, header bell, cart UX + review system audit
+
+**v2.8.66:** seller rows in the Mini App shop get a chat icon (direct conversation with the
+seller); header gets a notification bell opening the in-shell notifications list.
+**v2.8.67 fixes:** seller chat gave "Validation failed" (backend expects ONE participant for
+direct chats — current user auto-added; we sent two). Cart «−» at qty 1 now removes the item
+(separate remove button dropped). Bell: borderless + red dot instead of count.
+**Review/rating system audit completed (agent):** backend schema/API/store fully working
+(reviews table, /api/marketplace/reviews). Broken: seller rating HARDCODED 4.5 in
+DrizzleMarketplaceRepo.findSellersWithActiveRequestTemplates (never reads real reviews);
+review form never sends purchaseRequestId (verified-buyer badge never set); Step 6
+post-delivery has NO review prompt; Mini App has no reviews. Full phased plan in agent output —
+next work items.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 32a033869bf6a3d2383b74a5730b346aa62449ce Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 13:17:29 +0330
Subject: [PATCH 09/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20backend=20v2.8?=
 =?UTF-8?q?.64-65=20ratings=20+=20chat=20names?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 032d84a..5b8c76b 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -796,4 +796,18 @@ next work items.
 
 ---
 
+### 2026-06-03 — backend v2.8.64–65 — real seller ratings + chat participant names
+
+**v2.8.64:** seller list ratings now aggregated from published reviews (was hardcoded 4.5);
+exposes rating/ratingCount per seller.
+**v2.8.65:** PG chats showed "Unknown User" — participants (JSONB ids) are now populated with
+firstName/lastName/email/avatar from the users table (uuid OR legacy id matched), in
+findByIdWithParticipants and findForUser. Parity with Mongo .populate().
+**In progress:** background agent fixing seeds for the PG database + creating complete mock shops
+(categories in PG → fixes template-creation 500) — will be reviewed and shipped when it reports.
+**Queued (user):** in-shell تنظیمات عمومی (profile editing) in Mini App; post-delivery review
+prompt; template detail view + search/filter/sort in shop and requests; dark mode.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From c39e89b266394e35c1a36628643fa0243bfc860a Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 13:38:34 +0330
Subject: [PATCH 10/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20PG=20seeds,=20?=
 =?UTF-8?q?mock=20shops,=20template-creation=20fix=20(backend=20v2.8.65-66?=
 =?UTF-8?q?)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 5b8c76b..1f27691 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -810,4 +810,26 @@ prompt; template detail view + search/filter/sort in shop and requests; dark mod
 
 ---
 
+### 2026-06-03 — backend v2.8.65–66 — PG seeds, mock shops, template-creation fix
+
+**Template-creation 500 root cause (agent):** categories table column conflict (Drizzle "order"
+vs categoryStore order_num) + random legacy ids per seed → category ids served by the API were
+unresolvable by createRequestTemplate. Fixed: categoryStore aligned to canonical "order" column
+(with one-time order_num migration), deterministic category legacy ids, hardened categories
+fallback (id::text match). Also fixed: the v2.8.64 rating aggregation queried Drizzle reviews
+columns but the physical table (written by reviewStore) has different columns — rewritten
+against the real columns (seller_user_id).
+**New seed:** src/seeds/seedMockShops.ts — Persian categories, 5 sellers + shop settings,
+templates with picsum product images, published reviews. npm scripts fixed (paths) + added
+seed:levels / seed:templates / seed:mock-shops.
+**⚠️ DEV ENV REQUIREMENT:** CATEGORY_STORE=postgres (and ideally REVIEW_STORE / 
+SHOP_SETTINGS_STORE = postgres) must be set in dev .env.local when REPO_MARKETPLACE=postgres —
+docker-compose.dev.yml still defaults these to mongo. Without this, template creation keeps
+failing.
+**Run on dev after deploy:** docker exec <backend-container> npm run seed:categories && npm run
+seed:mock-shops
+**Verification:** tsc clean, 14 tests green (3 suites).
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 128945f0e979119872b27f89ffc82164cb5dee2d Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 14:01:47 +0330
Subject: [PATCH 11/50] =?UTF-8?q?docs:=20sync=20=E2=80=94=20template=20car?=
 =?UTF-8?q?ds=20redesign=20+=20detail=20view=20(frontend=20v2.8.68)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 1f27691..ee4ac27 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -832,4 +832,18 @@ seed:mock-shops
 
 ---
 
+### 2026-06-03 — frontend v2.8.68 — product-style template cards + in-shell template detail
+
+**Why (user reference design):** seller-shop template cards redesigned image-first (photo +
+circular add-to-cart overlay + title/price); tapping opens a new in-shell template detail view
+(image gallery with thumbnails/counter, product-type chip, price, description, specs, tags,
+sticky add-to-cart/order). New view: telegram-template-detail-view.tsx; shell openTemplate
+overlay.
+**Dev env (user applied):** CATEGORY_STORE/REVIEW_STORE/SHOP_SETTINGS_STORE=postgres set;
+backend v2.8.66 restarted healthy; 24 categories auto-seeded into PG. seed:mock-shops still to
+be run by the user for demo data.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 22b1ad4f2b45b5116ce7ff4f32adac7d0e271ed1 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 14:42:52 +0330
Subject: [PATCH 12/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.67=20(auto-seed=20flag),=20frontend=20v2.8.69=20(web?=
 =?UTF-8?q?-parity=20shop=20UI)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ee4ac27..59d21c1 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -846,4 +846,27 @@ be run by the user for demo data.
 
 ---
 
+### 2026-06-03 — backend v2.8.67 — auto-seed mock shops on startup
+
+**Feature:** new env flag `SEED_MOCK_SHOPS_ON_START=true` runs seedMockShops() during backend
+boot (after migrations/levels). Idempotent — existing rows are skipped — so the flag can stay
+on permanently in dev.
+**Action for dev env:** add `SEED_MOCK_SHOPS_ON_START=true` next to the other store flags and
+restart the backend container; demo shops/templates/reviews appear automatically.
+**Verification:** tsc clean.
+
+---
+
+### 2026-06-03 — frontend v2.8.69 — web-app-parity shop cards + template detail gallery
+
+**Per user screenshots:** (1) shop cards — circular «+» add-to-cart moved OFF the photo, now
+sits beside the title/price row; (2) template detail — web-style carousel: rounded image,
+‹ n/m › arrow/counter pill, touch-swipe navigation, centered thumbnails; (3) removed «سفارش این
+قالب» everywhere (product logic: buyer either creates a request or buys via cart) — add-to-cart
+is the single full-width CTA in the detail sticky bar.
+Files: telegram-seller-shop-view.tsx, telegram-template-detail-view.tsx.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 17755b97e027dc5856c7490cf24e91f52dfa3a41 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 17:45:58 +0330
Subject: [PATCH 13/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.70=20(in-shell=20settings/addresses,=20central=20th?=
 =?UTF-8?q?eme=20+=20dark=20mode)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 59d21c1..86337b4 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -869,4 +869,34 @@ Files: telegram-seller-shop-view.tsx, telegram-template-detail-view.tsx.
 
 ---
 
+### 2026-06-03 — frontend v2.8.70 — in-shell settings + addresses, central theme + dark mode
+
+**In-shell account screens (were opening the web dashboard):**
+- تنظیمات عمومی → telegram-settings-view.tsx: name/email/bio edit form via
+  updateUserProfile; session refresh on save.
+- آدرس‌های تحویل → telegram-addresses-view.tsx: full address CRUD (list / add /
+  edit / delete / set-primary) on the addresses API + use-telegram-addresses SWR hook.
+- Account rows switched from href→onClick; new overlay states 'settings'/'addresses'
+  in the shell. (Passkey stays web — WebAuthn limitation.)
+
+**Theme overhaul — Mini App now uses the CENTRAL web-app theme:**
+- constants.ts: TG_PALETTE_LIGHT / TG_PALETTE_DARK derived from
+  src/theme/theme-config.ts (primary green, grey ramp, status colors) instead of
+  the ad-hoc cream/saffron palette; font stack aligned with AMANEH_FONT
+  (IBM Plex Sans / Vazirmatn).
+- telegram-shell-css.ts: emits both palettes; `.tg-shell--dark` flips every token —
+  components keep the same CSS-var names.
+- use-telegram-theme hook: auto (follow Telegram colorScheme) | light | dark,
+  persisted in localStorage; syncs Telegram native header/background colors.
+- Theme toggle row (auto/light/dark) added to the account tab.
+- Hero headers (account / seller-shop / welcome banner / unlinked) use new
+  --header-bg/--header-fg/--header-fg-muted vars so they stay legible in both modes.
+- Removed the inline themeParams background/text override in getTelegramShellStyle
+  that forced a navy shell under light components on dark-mode Telegram clients
+  (the bad bg/font the user reported).
+**Verification:** tsc + eslint clean (one pre-existing no-constant-condition
+warning in telegram-webapp.ts, untouched).
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From d6628db325018ff2e45997956cba0bc09fa52a8c Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 18:05:36 +0330
Subject: [PATCH 14/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.71=20(solar=20icons,=20avatar=20upload,=20achieveme?=
 =?UTF-8?q?nts,=20theme-toggle=20fix)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 86337b4..ef5d03c 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -899,4 +899,29 @@ warning in telegram-webapp.ts, untouched).
 
 ---
 
+### 2026-06-03 — frontend v2.8.71 — Mini App: solar icons, avatar upload, achievements, theme-toggle fix
+
+**Icons:** telegram-icons.tsx redrawn to mirror the dashboard's Solar "linear"
+set (home-2 / document-add / chat-round-dots / user / shop-2 / wallet-money /
+rounded arrows). Added sun, moon, themeAuto, camera, trophy, lock.
+**Theme toggle now icon-based** (sun=light, moon=dark, half-disc=auto) instead
+of text labels — per user request.
+**BUGFIX — theme toggle didn't respond:** TelegramListRow rendered a *disabled*
+<button> wrapper whenever it had no onClick; a disabled button swallows clicks
+from nested children, so the language AND theme toggles (rendered inside the
+row's `value` slot) never received taps. Non-interactive rows (no onClick, no
+href) now render a <div>.
+**Avatar upload in settings:** telegram-settings-view gained a tappable avatar
+with a camera badge → file picker → uploadUserAvatar + updateUserProfile
+(persists immediately + session refresh); 3 MB / JPG-PNG-GIF validation; relative
+/uploads paths resolved to full backend URL.
+**Achievements in points view:** milestone badges (joined / verify email / first
+referral / 5 active referrals / 1000 points) derived client-side from the user's
+points + referral + isEmailVerified data; unlocked (trophy + "earned") vs locked
+(lock + "+N" reward) with an N/total counter. Display-layer gamification over the
+existing server-side point grants.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From d962807c4f28ebb9a4ad0c1fae697659cdc24f7e Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 18:27:58 +0330
Subject: [PATCH 15/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.72=20(avatar/email/web-link=20fixes=20+=20search/so?=
 =?UTF-8?q?rt)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ef5d03c..7854dc4 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -924,4 +924,31 @@ existing server-side point grants.
 
 ---
 
+### 2026-06-03 — frontend v2.8.72 — Mini App fixes (avatar/email/web-links) + search/sort
+
+**Bug fixes (user testing on v2.8.71):**
+- **Avatar broken in account header** — it rendered the raw relative `/uploads`
+  path against the frontend origin (404 inside the Telegram WebView). New shared
+  `resolveTelegramAvatar` (sections/telegram/avatar-url.ts) rebases avatars onto
+  the backend origin; used in both the account header and the settings uploader.
+- **Inline email verification in settings** — changing the email now surfaces a
+  code field + verify/resend buttons (resendProfileEmailVerification +
+  verifyProfileEmail) whenever the saved email is unverified, instead of forcing
+  the user back to the account-tab badge.
+- **Passkey/Wallet rows broke the Mini App** — `href` replaced the whole WebView
+  with the web dashboard and the Telegram back button couldn't return. They now
+  open in Telegram's in-app browser via `webApp.openLink`
+  (openTelegramExternalLink in telegram-webapp.ts), keeping the Mini App mounted.
+
+**Feature — search / filter / sort (queued item):**
+- Requests: search + status filter chips (all / active / completed / cancelled)
+  + sort (newest / highest budget).
+- Shop sellers: search + sort (top rated / most templates / newest).
+- Seller-shop templates: search + sort (newest / cheapest / priciest), shown
+  when the shop has > 3 templates.
+- New reusable `TelegramListControls` component + `controls` locale section.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From c2b6adcf6460421c3a6572bf5f44e36b5b45ba56 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 19:07:07 +0330
Subject: [PATCH 16/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.68=20(pending-email=20+=20referral=20bonus)=20+=20fr?=
 =?UTF-8?q?ontend=20v2.8.73?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 7854dc4..a8d9acd 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -951,4 +951,32 @@ existing server-side point grants.
 
 ---
 
+### 2026-06-03 — backend v2.8.68 + frontend v2.8.73 — pending-email flow, referral signup bonus, Mini App cleanups
+
+**Backend v2.8.68 — email change now requires verification before it applies:**
+- New `pendingEmail` field. Changing email parks the new address in pendingEmail
+  (NOT email) and sends a code to the NEW address; the account email + its
+  verified status stay intact until the code is confirmed, then pendingEmail is
+  promoted to email (with a re-check nobody else claimed it). Resend targets the
+  pending address. Implemented in the Mongoose User model AND the Postgres
+  authStore path (PgAuthUser field + constructor + toObject + savePgUser
+  INSERT/ON CONFLICT params + mirrorUserToMongo + `pending_email` column via
+  idempotent ALTER in postgresAuthSchema). userController.updateUserProfile /
+  resendCurrentUserEmailVerification / verifyCurrentUserEmail updated.
+- **Referral signup bonus:** referrer gets +50 points the moment someone signs
+  up with their code (email + Google paths) via PointsService.addPoints (source
+  'referral'), referralStats.totalEarned kept in step, 'referral-reward' socket
+  event. Best-effort, never blocks signup. Separate from the 2% purchase commission.
+
+**Frontend v2.8.73 — Mini App:**
+- Removed the «وضعیت‌های امانت» escrow-states legend from Home.
+- Removed the Passkey row from the account tab (not wanted in the Mini App).
+- Welcome-banner greeting uses the AMN account name before the Telegram profile
+  name, so an in-app rename updates it (was stuck on Telegram's "Anonymous …").
+- Settings email verify aligned with the pending-email flow: inline code panel
+  shows whenever a change is pending or the email is unverified; clears on verify.
+**Verification:** backend tsc clean; frontend tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From d2cfe63132521d459c93cce172267e48856784ec Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 19:28:07 +0330
Subject: [PATCH 17/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.74=20(chat=20alignment=20+=20read-only=20email)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index a8d9acd..2b6ddd9 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -979,4 +979,22 @@ existing server-side point grants.
 
 ---
 
+### 2026-06-03 — frontend v2.8.74 — Mini App chat alignment fix + read-only email field
+
+- **Chat both-sides bug:** in the Mini App chat every bubble rendered on the
+  same side in one colour. Root cause: `isMine = senderId === selfId` — when
+  `selfId` was undefined it matched system/welcome messages (no senderId), so
+  all bubbles looked "mine". Fixed: ids normalised (string | populated object),
+  a match now requires BOTH ids non-empty, and `selfId` falls back from `_id`
+  to `id`. Own = right/primary green, support/system = left/neutral grey.
+  (telegram-chat-bubble.tsx + selfId hardening in telegram-mini-app-view.tsx.)
+- **Read-only email:** the email field is now disabled by default with an
+  explicit «تغییر ایمیل» toggle, in BOTH the Mini App settings and the web
+  account-general form. Together with the backend pending-email flow (v2.8.68),
+  email can only change after the code sent to the NEW address is verified —
+  no silent change by typing + save.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From f35ab6cbe771fc5fde98fddf523d3c30d5f7ccf6 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 21:34:30 +0330
Subject: [PATCH 18/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.75=20(self-contained=20email-change=20code=20entry)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 2b6ddd9..4f21fa7 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -997,4 +997,19 @@ existing server-side point grants.
 
 ---
 
+### 2026-06-03 — frontend v2.8.75 — self-contained email-change flow (visible code entry)
+
+After enabling «تغییر ایمیل» there was no obvious place to send/enter the code.
+Reworked into a dedicated flow on both surfaces:
+- Mini App settings: editing the email reveals a «ارسال کد تأیید» button beside
+  it; pressing it parks the new address (pending) + emails the code and
+  immediately reveals the code-entry panel. Email is no longer bundled into the
+  name/bio Save (handleRequestEmailChange).
+- Web account-general: submitting an email change reveals the verification Alert
+  (code field + verify/resend) even though the account email stays on the old
+  verified address until the code is confirmed (pendingEmailVerify state).
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 7b99c66348dac62c8d503242e8a552054b107582 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 21:46:16 +0330
Subject: [PATCH 19/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.76=20(email=20send-code=20reveals=20verify=20panel)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 4f21fa7..872ff7d 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1012,4 +1012,16 @@ Reworked into a dedicated flow on both surfaces:
 
 ---
 
+### 2026-06-03 — frontend v2.8.76 — email send-code always reveals the verify panel
+
+Bugfix: «ارسال کد تأیید» was disabled when the email was unchanged and
+handleRequestEmailChange early-returned silently for the same address — so after
+"sending" nothing appeared. Now the button is enabled whenever an email is
+present; a changed email parks it as pending + codes the new inbox, an unchanged
+email (re)sends a code to verify the current address. Either way pendingVerify
+flips on and the inline code-entry panel renders.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From afc0c81c2dcd9b309df17c388bfeeb929180c8c0 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 21:52:50 +0330
Subject: [PATCH 20/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.77=20(email=20verify=20panel=20stays=20mounted)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 872ff7d..302cd1b 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1024,4 +1024,18 @@ flips on and the inline code-entry panel renders.
 
 ---
 
+### 2026-06-03 — frontend v2.8.77 — keep email verify panel mounted after sending code
+
+Bugfix: pressing «ارسال کد تأیید» reverted the settings view to its initial
+(non-edit, no-panel) state — the code field never appeared. Root cause:
+handleRequestEmailChange awaited onSaved (checkUserSession), which sets the auth
+provider's `loading` flag true; the Mini App shell gates the entire linked block
+on `!loading`, so it unmounted + remounted the settings view, wiping its local
+pendingVerify/emailEditable state. Removed the session refresh from the send-code
+path (the email is only pending then — nothing to refresh until verified;
+handleVerify still refreshes after a successful confirm).
+**Verification:** tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 9823194125af62fbc81c3c86a2b30dbbb7c913b7 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 22:23:03 +0330
Subject: [PATCH 21/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.69=20+=20frontend=20v2.8.78=20(chat=20system=20msgs?=
 =?UTF-8?q?=20+=20review)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 302cd1b..ece6d21 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1038,4 +1038,23 @@ handleVerify still refreshes after a successful confirm).
 
 ---
 
+### 2026-06-03 — backend v2.8.69 + frontend v2.8.78 — chat system messages + post-delivery review
+
+**Chat both-sides (round 2 — real root cause):** support welcome/greeting and
+group "chat created" messages are authored on the backend with
+`chat.metadata.createdBy` (the buyer) as senderId, so they rendered as the
+buyer's own. Backend (v2.8.69): `sendSystemMessage` now takes an optional
+senderId and createSupportChat passes the support user's id. Frontend (v2.8.78):
+any `messageType:'system'` message renders as a neutral centred note regardless
+of sender — robust fix for all system messages.
+**Post-delivery seller review (frontend v2.8.78):** buyer viewing a
+delivery/delivered/seller_paid/completed request sees a star + comment prompt
+(TelegramReviewPrompt). Seller resolved from the request's selected offer
+(getOffers → selectedOfferId → sellerId); submits createReview({subjectType:
+'seller', subjectId, rating, comment, purchaseRequestId}); 409 → "already
+reviewed" handled gracefully.
+**Verification:** backend + frontend tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 18c280cbb0acab18dc424b5f3a32872416501029 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 22:43:04 +0330
Subject: [PATCH 22/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.70=20(persist=20telegram=20user=20updates=20on=20sig?=
 =?UTF-8?q?n-in)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ece6d21..77cf256 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1057,4 +1057,20 @@ reviewed" handled gracefully.
 
 ---
 
+### 2026-06-03 — backend v2.8.70 — persist telegram user updates on sign-in (new-user login)
+
+Investigating "new Telegram account / new device can't log in (existing works)".
+telegramAuth mutates the user after the TelegramLink lookup (telegramVerified
+flip, lazily backfilled referralCode, lastLoginAt) but only NEW users hit
+user.save(); existing/half-created users were never re-persisted → a backfilled
+referralCode never landed and subsequent sign-ins kept tripping the non-sparse
+users.referralCode index. Added a best-effort user.save() before linking.
+**Note:** background logs in the user's screenshots show "Backend 2.6.49" — the
+deployed dev backend may be far behind (none of the 2.8.x auth/email/chat fixes
+live). Asked the user to confirm/redeploy the backend and share the exact error
+the new device shows (frontend surfaces backend message verbatim).
+**Verification:** backend tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 5ec1b6d55b4730c12b034f88a9b502a5d75262d9 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 23:14:06 +0330
Subject: [PATCH 23/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.71=20(template-creation=20500=20/=20CHECK=20constrai?=
 =?UTF-8?q?nts)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 77cf256..f388c14 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1073,4 +1073,22 @@ the new device shows (frontend surfaces backend message verbatim).
 
 ---
 
+### 2026-06-03 — backend v2.8.71 — fix template-creation 500 (blank optional fields vs CHECK constraints)
+
+Seller "create request template" returned HTTP 500 whenever optional fields were
+left empty. The request_templates table has CHECK constraints that allow only
+NULL or a valid pattern — product_link (`~ '^https?://.+'`) and delivery_email
+(email regex) — and the nullable service_session_type enum rejects ''. Both
+DrizzleMarketplaceRepo.createRequestTemplate and updateRequestTemplate passed the
+form's empty strings straight into the INSERT/UPDATE, tripping the constraints.
+Added a `blank()` coercion: blank optional strings → NULL/undefined for
+product_link, delivery_email, size/color/brand, service_location/notes,
+proposal_title/description, service_session_type; enum columns (product_type,
+delivery_type, urgency, budget_currency, metadata_source) fall back to their
+defaults instead of receiving ''.
+(Confirmed deployed backend is now on the 2.8.x line — logs show v2.8.70.)
+**Verification:** backend tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 43ae7f39e12250aa98ccebb5496e01aa6859adc1 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Wed, 3 Jun 2026 23:40:04 +0330
Subject: [PATCH 24/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.79=20(template=20maxUsage=20optional)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index f388c14..c839db9 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1091,4 +1091,17 @@ defaults instead of receiving ''.
 
 ---
 
+### 2026-06-03 — frontend v2.8.79 — request-template maxUsage truly optional
+
+The «حداکثر تعداد استفاده (اختیاری)» field threw a ZodError ("Invalid input") and
+blocked the template form submit. It was wrapped in schemaHelper.nullableInput —
+a helper for REQUIRED fields that adds an issue on null/undefined — so an empty
+optional value failed. Replaced with zod.preprocess (blank/null/NaN → undefined,
+validate int ≥ 1 only when present); default null → undefined. Together with
+backend v2.8.71 (blank → NULL for product_link/delivery_email/enums), optional
+template fields can now be left empty end-to-end.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 8253ec0659fca952dc962657f2c7633001d70f99 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 00:23:24 +0330
Subject: [PATCH 25/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20chat?=
 =?UTF-8?q?=20participant=20fix=20revert=20(v2.8.73)=20+=20template=20vali?=
 =?UTF-8?q?dation=20(frontend=20v2.8.80)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index c839db9..d532389 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1104,4 +1104,23 @@ template fields can now be left empty end-to-end.
 
 ---
 
+### 2026-06-04 — backend v2.8.72→v2.8.73 (chat participant fix reverted) + frontend v2.8.80 (template validation visibility)
+
+**Backend chat — attempted + reverted.** v2.8.72 tried to canonicalize chat
+participant ids (userRepo.findById) so a buyer (marketplace uuid for the seller)
+and seller (legacy ObjectId session) would share one direct thread. It backfired:
+findById returns an id format (Mongo ObjectId / PG uuid) that no longer matches
+the session JWT id, so the membership check rejected everyone ("User is not a
+participant"). v2.8.73 reverts to storing ids as passed (restores chat access).
+**Open issue:** buyer↔seller messages still don't cross — they land in separate
+direct conversations because the seller is referenced by a uuid while the session
+id is a legacy ObjectId (users in Mongo, chats in Postgres). Needs a correct
+uuid→legacyObjectId resolution (via marketplace id_map), not the session-breaking
+findById path. Deferred for a careful fix.
+**Frontend v2.8.80:** template-form onInvalid now expands all collapsed accordion
+sections and toasts the actual nested error messages, so validation errors are
+visible under their fields instead of only in the console.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 37c715980146fec746f7b96f219a650e0b76e1fc Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 00:40:16 +0330
Subject: [PATCH 26/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.74=20(chat=20uuid=E2=86=92session=20ObjectId=20parti?=
 =?UTF-8?q?cipant=20fix)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index d532389..41f5d77 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1123,4 +1123,20 @@ visible under their fields instead of only in the console.
 
 ---
 
+### 2026-06-04 — backend v2.8.74 — chat: map uuid participants → session ObjectId (buyer↔seller fix)
+
+Root cause confirmed from logs: a buyer opens a chat "with seller X" using X's
+marketplace **Postgres uuid** (669c0dac-…), but X's session/JWT id is their
+**legacy ObjectId** (e0527…). Conversations key participants by the session id,
+so buyer and seller landed in two separate direct threads (each saw only their
+own messages). ChatService.createChat now normalises any uuid participant (and
+createdBy) → users.legacy_object_id via a direct PG lookup BEFORE dedup/create —
+resolving TOWARD the session-id format (the reverted v2.8.72 resolved toward uuid
+and broke membership). Both sides now converge on one conversation + socket room.
+Note: pre-existing mismatched conversations are orphaned; a freshly opened chat
+dedups correctly for both parties.
+**Verification:** backend tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 5b43a9b783dc294179cb03d8a91f9ad6ea4250bf Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 01:09:33 +0330
Subject: [PATCH 27/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.81=20(in-shell=20checkout)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 41f5d77..70f68ff 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1139,4 +1139,21 @@ dedups correctly for both parties.
 
 ---
 
+### 2026-06-04 — frontend v2.8.81 — in-shell checkout (Mini App no longer hands off to web)
+
+Cart «ادامه و پرداخت» previously navigated the Telegram WebView to the web
+checkout (taking over the Mini App). New TelegramCheckoutView keeps it in-shell:
+order summary + delivery-address picker (reuses saved addresses; "add address"
+opens the in-shell addresses manager) → places the order via
+convertTemplatesToRequests({paymentConfirmed:false}) so requests are created in
+`pending_payment` (escrow model — NO on-chain/web3 transaction needed inside the
+Mini App). Cart cleared on success and the shell jumps to Requests, where the
+buyer completes the escrow payment. New 'checkout' shell overlay + cart `clear()`
+on the cart hook. Verified the deferred path exists (status 'pending_payment'
+when paymentConfirmed is false) rather than requiring batch-convert's
+paymentConfirmed:true on-chain flow.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From c3a4fdf204d7ce4cd25a469c3118a4bea69eef7e Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 01:32:55 +0330
Subject: [PATCH 28/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.82=20(digital=20checkout=20no-address=20+=20pending?=
 =?UTF-8?q?=5Fpayment=20stepper)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 70f68ff..61bf0b3 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1156,4 +1156,22 @@ paymentConfirmed:true on-chain flow.
 
 ---
 
+### 2026-06-04 — frontend v2.8.82 — checkout: digital skips address; fix buyer pending_payment stepper
+
+- In-shell checkout: only PHYSICAL products require a delivery address; digital
+  products / services / consultations are delivered online (email/link) so the
+  address picker is hidden. Cart items now carry productType; needsAddress is
+  derived from it (deliveryType fallback for older items).
+- Buyer stepper fix (request-config determineBuyerStep): pending_payment /
+  payment / payment_pending were grouped with the PAID states and returned step
+  4 ("awaiting shipment"), so a just-placed unpaid order looked like the payment
+  step was skipped. Those un-paid statuses now return step 3 ("select & pay"),
+  so the request correctly shows the payment step as current.
+**Open:** the actual on-chain escrow payment step inside the Mini App still needs
+a wallet rail (TON Connect / WalletConnect) — order placement is in-shell, the
+pay action is the remaining web3 piece.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 524dd52cf54049be403a6a2fca9c6251d58ff5ba Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 02:07:34 +0330
Subject: [PATCH 29/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.83=20(pay=20CTA=20+=20stepper=20line=20fix)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 61bf0b3..ecaf101 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1174,4 +1174,24 @@ pay action is the remaining web3 piece.
 
 ---
 
+### 2026-06-04 — frontend v2.8.83 — Mini App pay CTA (wallet + manual deposit) + stepper line fix
+
+- Request detail: buyers on a payable status (pending_payment/payment) get a
+  «پرداخت با کیف پول» button that opens the web payment page for that request in
+  Telegram's in-app browser (openTelegramExternalLink). That page already offers
+  BOTH WalletConnect/wagmi AND the in-house manual deposit-address (backend
+  auto-detects the on-chain transfer via request-network webhook), so the user
+  pays without the Mini App being torn down. The generic "open in web" link also
+  uses the in-app browser now.
+- Stepper green line "broken" fix: the two half-connectors per cell left a seam,
+  and the active dot's saffron halo overlapped the line. Replaced with one
+  continuous connector per gap (green once the step is reached) and a solid
+  paper ring on the active dot — the progress line is now continuous.
+**Note:** this reuses the existing web WalletConnect + deposit flow via the
+in-app browser; a fully native in-shell wallet/deposit screen remains a larger
+follow-up.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From ec6e9022dd3afc7f0c30f3f7f4db0efa7184a09e Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 08:15:47 +0330
Subject: [PATCH 30/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.84=20(chat=20archive)=20+=20deploy=20branch=20now?=
 =?UTF-8?q?=20main?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index ecaf101..cdf52da 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1194,4 +1194,18 @@ follow-up.
 
 ---
 
+### 2026-06-04 — frontend v2.8.84 — archive conversations from the chat list (DEPLOY BRANCH NOW main)
+
+⚠️ Deploy branch changed: pushes now go to `main` (CI: "push to main builds dev-*
+image and deploys to Arcane dev env"). integrate-main-into-development is retired.
+- Chat list: each row gained an archive button → confirm sheet → PATCH
+  /chat/:id/archive (archiveConversation) + list refresh. Archived chats are
+  excluded from the default getUserChats query, so the row disappears. Row
+  restructured from a single <button> into a div wrapping the open-button + a
+  sibling archive button (nested buttons are invalid HTML). New archive icon +
+  chat archive locale strings.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 59670f7c743efc5a018602c274105c545a2b6685 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 09:40:08 +0330
Subject: [PATCH 31/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20chat?=
 =?UTF-8?q?=20search/archive=20(fe=202.8.85/86,=20be=202.8.75)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index cdf52da..47c2c34 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1208,4 +1208,20 @@ image and deploys to Arcane dev env"). integrate-main-into-development is retire
 
 ---
 
+### 2026-06-04 — backend v2.8.75 + frontend v2.8.85/86 — chat search + archive view, template→checkout fix
+
+**backend v2.8.75:** archiveChat is now two-way — PATCH /chat/:id/archive accepts
+`{archived}` (default true); archived:false restores. Powers unarchive.
+**frontend v2.8.85:** template detail — once an item is in the cart the sticky bar
+shows «حذف از سبد» + a primary «مشاهدهٔ سبد و پرداخت» (onOpenCart) so the buyer
+can actually reach checkout (previously the single button just toggled).
+**frontend v2.8.86:** chat list gained a search box (counterpart name + last
+message) and a «گفتگوهای آرشیوشده» row → TelegramArchivedChatsView (lazy
+isArchived=true fetch; per-row unarchive via archiveConversation(id,false)).
+getConversations/archiveConversation actions + useTelegramConversations(archived)
+updated.
+All on the new `main` deploy branch. **Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From fef46f2f96c57583c63401b1494eed39e8285592 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 10:20:05 +0330
Subject: [PATCH 32/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20arch?=
 =?UTF-8?q?ive=20boolean-filter=20fix=20(be=202.8.76)=20+=20archived=20sea?=
 =?UTF-8?q?rch=20(fe=202.8.87)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 47c2c34..94f1e1d 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1224,4 +1224,19 @@ All on the new `main` deploy branch. **Verification:** tsc + eslint clean.
 
 ---
 
+### 2026-06-04 — backend v2.8.76 + frontend v2.8.87 — fix archive filter (boolean) + archived-view search
+
+**Root cause of "archived chats not removed from main + archived view shows
+everything":** DrizzleChatRepo.matchesCondition routed BOOLEAN query conditions
+through idEquals, and asStringId() coerces both true and false to '' — so
+idEquals(false,true) === true, making the `settings.isArchived` filter match
+every chat. Booleans now compare strictly (Boolean(value) === condition); a
+missing value counts as false. (Also corrects participants.isActive matching.)
+**frontend v2.8.87:** the archived chats view gained the same search box as the
+main list (+ no-results state). Unarchive already worked (archiveConversation
+(id,false)).
+**Verification:** backend + frontend tsc/eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 8f865c97a71fa71a70ea280b95f5fd5b26e260d6 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 12:54:04 +0330
Subject: [PATCH 33/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.88=20(in-shell=20direct-transfer=20payment)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 94f1e1d..fc35925 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1239,4 +1239,23 @@ main list (+ no-results state). Unarchive already worked (archiveConversation
 
 ---
 
+### 2026-06-04 — frontend v2.8.88 — in-shell direct-transfer payment (no wallet connection)
+
+Buyers can now pay a pending_payment request entirely inside the Mini App, with
+NO web3 wallet connection — mirroring the web «انتقال مستقیم» rail.
+TelegramPaymentView: resolves the selected offer (seller + amount) →
+getPaymentOptions for chain/token → createDirectBalanceIntent (provider
+amn.scanner, rail direct_balance, mode check) → shows a copyable derived deposit
+address + exact amount + a strong "send only this token on this network" warning
+→ «پرداخت کردم» calls checkDirectBalancePayment.
+Edge cases (all surfaced): OVERPAYMENT accepted (backend delta>=expected →
+paid); UNDERPAYMENT shows "received X of Y, send the rest" (paidDelta vs
+expectedAmount); WRONG TOKEN — the check flow can't detect a foreign token, so a
+prominent on-screen warning is shown (backend webhook rejects token/chain
+mismatch). Wired from the request-detail pay CTA via a new openPaymentRequestId
+shell overlay + BackButton. (Replaces the earlier "open web payment" hand-off.)
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From eafa3941b42190a69a2597f7fc01ee8fd02abaed Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 13:43:57 +0330
Subject: [PATCH 34/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.89=20(checkout=20=E2=86=92=20payment=20step,=20shop?=
 =?UTF-8?q?=20model)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index fc35925..8704a62 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1258,4 +1258,18 @@ shell overlay + BackButton. (Replaces the earlier "open web payment" hand-off.)
 
 ---
 
+### 2026-06-04 — frontend v2.8.89 — Mini App checkout flows straight into payment (shop model)
+
+Per the shop model (pay as part of ordering, not place-then-pay-later), the
+in-shell checkout now, after «ادامه و پرداخت», creates the request(s) (template
+conversion already mints + accepts an offer and sets selectedOfferId, status
+pending_payment) and for a SINGLE-request order jumps directly into the in-shell
+direct-transfer payment step (openPaymentRequestId) rather than dropping the
+buyer on the Requests list. Multi-request orders still go to Requests. Checkout
+reads the created request id from batch-convert's data[]; button relabeled to
+«ادامه و پرداخت». (The normal request→offers→pay escrow flow is unchanged.)
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 98fa717f7db2ebbd3fb873441a462733e8b77363 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 14:47:05 +0330
Subject: [PATCH 35/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.90=20(checkout=20stepper=20+=20paid-step=20advance)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 8704a62..3efd4c7 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1272,4 +1272,24 @@ reads the created request id from batch-convert's data[]; button relabeled to
 
 ---
 
+### 2026-06-04 — frontend v2.8.90 — checkout stepper + paid-step advance fix
+
+- In-shell checkout shows a 3-step progress header (cart → address → payment),
+  reusing TelegramRequestStepper (new optional `title` prop): cart step 1,
+  checkout step 2, payment step 3 (only when reached from checkout via the new
+  `checkoutFlow` prop + `paymentCheckoutFlow` shell state). BackButton steps
+  checkout→cart and checkout-payment→cart.
+- Stepper fix: a PAID request (status 'payment' = escrow funded — confirmed
+  working end-to-end via the AMN scanner: `[direct-balance] check paid … delta`)
+  was stuck on step 3 because 'payment' was grouped with the unpaid statuses.
+  determineBuyerStep now maps 'payment' → 4 (awaiting shipment), 'confirming' →
+  5; only pending_payment/payment_pending stay on 3. Request-detail «پرداخت»
+  CTA hidden once status is 'payment'.
+**Note:** in-shell direct-transfer payment is confirmed working — a real 0.01
+USDC BSC transfer to the derived address was auto-detected and advanced the
+request to 'payment'.
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 824663bcaab3f30d6eb87965c782a1949afba4bc Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 15:11:08 +0330
Subject: [PATCH 36/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20fron?=
 =?UTF-8?q?tend=20v2.8.91=20(seller=20stepper=20paid=E2=86=92ship)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 3efd4c7..2e90ca1 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1292,4 +1292,19 @@ request to 'payment'.
 
 ---
 
+### 2026-06-04 — frontend v2.8.91 — seller stepper: paid/shop request shows "ship goods"
+
+Buyer stepper confirmed correct (paid shop request → step 4 «انتظار ارسال»).
+Seller side was wrong: a paid shop (template) purchase showed seller step 1
+(«ارسال پیشنهاد») because determineSellerStep gated the step on an
+accepted/hasOffer context the seller view couldn't reliably compute (id seam).
+Since a funded escrow implies an accepted offer for that seller, post-payment
+seller steps are now FIXED/unconditional: pending_payment/payment_pending → 2
+(awaiting payment), payment/processing/paid → 3 (ship goods), delivery → 4,
+delivered/confirming → 5, seller_paid/completed → 6. Removed the unreliable
+`accepted` flag. (Pre-payment states keep the hasOffer 1/2 logic.)
+**Verification:** tsc + eslint clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 485929509c26c4aa8ce830102c4525fbe2c33aca Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 16:01:11 +0330
Subject: [PATCH 37/50] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20back?=
 =?UTF-8?q?end=20v2.8.77=20(seller=20delivery=20403=20/=20uuid-ObjectId=20?=
 =?UTF-8?q?seam)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 2e90ca1..07ceac3 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -1307,4 +1307,18 @@ delivered/confirming → 5, seller_paid/completed → 6. Removed the unreliable
 
 ---
 
+### 2026-06-04 — backend v2.8.77 — seller can't ship: delivery 403 (uuid↔ObjectId seam)
+
+The selected seller got HTTP 403 on PUT /marketplace/purchase-requests/:id/delivery
+(«تأیید ارسال کالا») for a paid shop request. The auth compared the seller's
+session id (legacy ObjectId e0527…) against the selected offer's sellerId, which a
+TEMPLATE-created offer stores as a PG uuid (669c0dac…) → never equal → 403. Added a
+`sameUser(a,b)` helper that resolves both ids via the user repo (accepts either
+format) and compares every id form (_id/id/pgId/legacyObjectId). Applied to
+updateDeliveryInfo, verifyDeliveryCode, and the delivery-code-status buyer/seller
+gate. (Buyer step labels already matched the web — no change.)
+**Verification:** backend tsc clean.
+
+---
+
 <!-- Add new entries above this line. Newest at top. -->

From 5523bf7774e64f21b8512733e96067938ceb73ff Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 16:21:56 +0330
Subject: [PATCH 38/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.92=20?=
 =?UTF-8?q?=E2=80=94=20buyer=20receive-goods/confirm=20+=20stepper=20fix?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 07ceac3..7133db8 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — frontend@v2.8.92 — Telegram Mini App: buyer receive-goods/confirm + checkout stepper line fix
+
+**Commits:** frontend only (v2.8.92); backend stays at v2.8.77
+**Touched:** `telegram-request-detail-view.tsx` (buyer receive-goods flow), `components/telegram-request-stepper.tsx` (row width cap/centre), `locales/{fa,en,types}.ts` (delivery-code + confirm-receipt strings)
+**Why:** (1) The buyer had no way to confirm receipt inside the Mini App — once the seller shipped (status `delivery`, fixed in backend v2.8.77's `sameUser` patch), the buyer was stuck at step 5 «دریافت کالا» with no action. Mirrored the web `step-5-receive-goods`: on `status === 'delivery'` for a buyer, auto-load/generate the delivery code (`getDeliveryCode` → fallback `generateDeliveryCode`) shown dashed/monospace for the buyer to hand the seller, plus a «تایید دریافت کالا» button calling `confirmDelivery(requestId)` then `refresh()` so the stepper advances to «تایید نهایی». (2) The 3-step checkout stepper stretched each cell across the full Telegram width, leaving a long connector stub past the last dot — capped the steps row at `steps.length * 96` and centred it (`margin: 0 auto`), so both the 3-step checkout and 6-step request steppers render tight, even connectors.
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` clean. Admin verifies after deploy: buyer opens a `delivery`-status request → sees delivery code + «تایید دریافت کالا» → tap → request advances to تایید نهایی; checkout stepper line is clean (no stub).
+
+---
+
 ### 2026-06-03 — frontend@9bafbbb — Telegram Mini App: full in-shell shop, account tab parity, and shopping cart (v2.8.57–v2.8.59)
 
 **Commits:** `a8ae1e3` (v2.8.57), `6dc3918` (v2.8.58), `9bafbbb` (v2.8.59) — frontend only; backend stays at v2.8.56

From cd8991e8213fb59bec88438dd6565a4b80c4ba72 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 16:33:34 +0330
Subject: [PATCH 39/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.78=20+?=
 =?UTF-8?q?=20frontend=20v2.8.93=20=E2=80=94=20gate=20shop=20orders=20on?=
 =?UTF-8?q?=20payment?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 7133db8..b3c17a7 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — backend@v2.8.78, frontend@v2.8.93 — Gate shop orders on payment: abandon-cancel + 30-min TTL sweep
+
+**Commits:** backend v2.8.78, frontend v2.8.93
+**Touched:** backend `services/admin/dataCleanupService.ts` (new `cancelStaleUnpaidRequests`), `services/admin/ttlCleanupJob.ts` (schedule it every 5 min); frontend `telegram-payment-view.tsx` (abandon-cancel on unmount)
+**Why:** Shop checkout creates the purchase request in `pending_payment` *before* the buyer pays — unavoidable because the direct-balance deposit address is derived per-request, so the request must exist for the AMN scanner to credit it (the payment-intent route requires `purchaseRequestId`/`sellerOfferId`/`sellerId`). That left unpaid orders lingering. Now, per the user's choice (both mechanisms, 30-min window, only cancel orders with **no** deposit): (1) **Frontend abandon-cancel** — when the buyer leaves the in-shell checkout payment screen without completing, the just-created order is set to `cancelled` via `updateRequestStatus`; two refs (`paidRef`, `depositRef`) suppress the cancel if the deposit was confirmed *or* a partial deposit was detected, so funds are never orphaned. (2) **Backend TTL sweep** — `cancelStaleUnpaidRequests` runs every 5 min, cancels `pending_payment` requests older than 30 minutes that have **no** active payment (`findActivePaymentForRequest === null`); any active/slow on-chain payment is left untouched. The sweep is the backstop for app-closed cases the frontend unmount can't catch.
+**Verification:** backend `npx tsc --noEmit` clean; frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. Admin verifies after deploy: shop checkout → reach payment step → press back without paying → order shows `cancelled` (not lingering pending_payment); a paid/underpaid order is NOT cancelled.
+
+---
+
 ### 2026-06-04 — frontend@v2.8.92 — Telegram Mini App: buyer receive-goods/confirm + checkout stepper line fix
 
 **Commits:** frontend only (v2.8.92); backend stays at v2.8.77

From b509d8403d69980cb6a8e0f02b9e78605ae25d73 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 16:45:07 +0330
Subject: [PATCH 40/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.79=20?=
 =?UTF-8?q?=E2=80=94=20delivery=20code=20sameUser=20buyer=20auth=20fix?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index b3c17a7..c6436f2 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — backend@v2.8.79 — Delivery code: apply `sameUser` to buyer auth gates (Mini App showed "—")
+
+**Commits:** backend v2.8.79 (frontend stays v2.8.93)
+**Touched:** `services/marketplace/marketplaceController.ts` (`generateDeliveryCode`, `getDeliveryCode`)
+**Why:** In the Mini App receive-goods step the delivery code rendered as «—»: both `getDeliveryCode` and `generateDeliveryCode` returned 403. Root cause is the recurring Mongo↔PG id seam — these two handlers still used the strict `request.buyerId !== userId` comparison (session legacy ObjectId vs PG-uuid `buyerId`), unlike `verifyDeliveryCode` which was already moved to the async `sameUser` helper in v2.8.77. Replaced both buyer checks with `!(await sameUser(userId, toIdString(request.buyerId)))`. Added an explicit `!userId` unauthorized guard in `getDeliveryCode` to restore the `string` narrowing the removed `!==` previously provided (so `getDeliveryCode(id, userId)` still type-checks). The repo layer (`getDeliveryCodeForUser`) already resolves the seam via `resolveEntityId`, so once the code exists it loads without regenerating.
+**Verification:** backend `npx tsc --noEmit` clean. Admin verifies after deploy: buyer opens a `delivery`-status request in the Mini App → a 6-digit delivery code appears (no «—», no 403); seller can verify it.
+
+---
+
 ### 2026-06-04 — backend@v2.8.78, frontend@v2.8.93 — Gate shop orders on payment: abandon-cancel + 30-min TTL sweep
 
 **Commits:** backend v2.8.78, frontend v2.8.93

From 02d933d737e33e08fe073964167ce8308cfb4ed1 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 16:54:59 +0330
Subject: [PATCH 41/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.94=20?=
 =?UTF-8?q?=E2=80=94=20seller=20delivery-code=20entry=20field?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index c6436f2..4603890 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — frontend@v2.8.94 — Telegram Mini App: seller delivery-code entry field
+
+**Commits:** frontend only (v2.8.94); backend stays v2.8.79
+**Touched:** `telegram-request-detail-view.tsx` (seller code-entry card), `locales/{fa,en,types}.ts` (`seller_code_*` strings)
+**Why:** The escrow handover is two-sided: the buyer generates a 6-digit delivery code (shown in v2.8.92) and the **seller enters it** to confirm delivery. The Mini App seller had no field for this — at status `delivery` the seller only saw «منتظر تایید خریدار» with nowhere to type the code. Added a code-entry card for `role === 'seller' && status === 'delivery'`: a numeric 6-digit input (digit-filtered, monospace, centred) + «تایید تحویل کالا» button calling `verifyDeliveryCode(requestId, code)` then `refresh()` so the status advances to `delivered`. Backend `verifyDeliveryCode` already uses the `sameUser` seller gate (v2.8.77), so this composes with the id-seam fix.
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. Admin verifies after deploy: buyer opens `delivery` request → sees code; seller opens same request in Mini App → enters that code → «تایید تحویل کالا» → status → delivered.
+
+---
+
 ### 2026-06-04 — backend@v2.8.79 — Delivery code: apply `sameUser` to buyer auth gates (Mini App showed "—")
 
 **Commits:** backend v2.8.79 (frontend stays v2.8.93)

From 3982a167ace60acc27fa9cef0375b5117ccf9579 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 22:23:04 +0330
Subject: [PATCH 42/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.80=20?=
 =?UTF-8?q?=E2=80=94=20shop=20sellers=20list=20cache=20invalidation=20fix?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 76a2c19..96c8f9f 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — backend@v2.8.80 — Shop sellers list cache: invalidate global `templates:list` on per-seller change
+
+**Commits:** backend v2.8.80
+**Touched:** `services/redis/cacheService.ts` (`invalidateTemplatesCache`)
+**Why:** Found while seeding shops for three sellers via API: after creating templates for `seller1@amn.gg`/`seller2@amn.gg`, the public shop endpoint (`GET /marketplace/request-templates/sellers`) still returned only the first seller. Root cause — the global sellers list is cached under Redis key `templates:list`, but `RequestTemplateService` create/update/delete call `invalidateTemplatesCache(sellerId)` which only deleted `templates:seller:<id>`, never `templates:list`. So a newly-onboarded seller didn't appear in `/shop` until the 5-minute TTL elapsed. Fix: when invalidating with a `sellerId`, also `del('templates:list')` since the aggregated list changes whenever any seller adds/edits/removes a template.
+**Verification:** backend `npx tsc --noEmit` clean. After deploy: a brand-new seller's first template appears in `GET …/request-templates/sellers` (and dev.amn.gg/shop) immediately, not after TTL. (Seeded data: seller/seller1/seller2 @amn.gg each have 3 active templates — two at 0.01 USDT, one at 0.05 — with images, BSC USDT/USDC payment config.)
+
+---
+
 ### 2026-06-04 — frontend@v2.8.94 — Telegram Mini App: seller delivery-code entry field
 
 **Commits:** frontend only (v2.8.94); backend stays v2.8.79

From 39e2cd18e2382cd4e3fbc3d47fa41785c7963851 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 22:47:55 +0330
Subject: [PATCH 43/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.81=20?=
 =?UTF-8?q?=E2=80=94=20public=20shop=20settings=20uuid->legacy=20resolve?=
 =?UTF-8?q?=20fix?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 96c8f9f..60d8f16 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — backend@v2.8.81 — Public shop settings: resolve uuid→legacy ObjectId (name/avatar were blank publicly)
+
+**Commits:** backend v2.8.81
+**Touched:** `services/marketplace/shopSettingsStore.ts` (`getSellerShopSettings` + new `resolveSellerLegacyId`)
+**Why:** Found while setting shop name/avatar/cover for the three seed sellers. After PUT-ing settings, the seller's OWN `GET /marketplace/shop/settings` returned them correctly, but the PUBLIC `GET /marketplace/shop/settings/:sellerId` (what the shop page shows buyers) returned `data:null` — blank name, no avatar/cover. Root cause: the recurring Mongo↔PG id seam. `shop_settings` rows are keyed by `seller_legacy_object_id` (the seller's legacy Mongo ObjectId, which is what `req.user.id` is on the own-settings path), but the public sellers list returns each seller by their PG **uuid**, so `getSellerShopSettings(uuid)` queried `where seller_legacy_object_id = <uuid>` and matched nothing. Fix: when the direct lookup misses, resolve the incoming id via `select legacy_object_id from users where id=$1` (a 24-hex id is treated as already-legacy) and retry. Mirrors the existing reverse `resolveSellerUuid` helper.
+**Verification:** backend `npx tsc --noEmit` clean. After deploy: `GET /marketplace/shop/settings/<pg-uuid>` returns the saved name/avatar/cover for all three sellers (was null). Seeded: seller/seller1/seller2 @amn.gg each have a shop name, description, avatar, cover image, social links, and 3 active products.
+
+---
+
 ### 2026-06-04 — backend@v2.8.80 — Shop sellers list cache: invalidate global `templates:list` on per-seller change
 
 **Commits:** backend v2.8.80

From 209c6f03da37308378682fce07025f2871ac11fb Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 23:15:52 +0330
Subject: [PATCH 44/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.95=20?=
 =?UTF-8?q?=E2=80=94=20seller-entered=20delivery=20code,=20buyer=20confirm?=
 =?UTF-8?q?=20removed?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 60d8f16..3e4472b 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — frontend@v2.8.95 — Delivery confirmation: code is entered by the seller, buyer's «تایید دریافت کالا» removed
+
+**Commits:** frontend only (v2.8.95)
+**Touched:** `sections/telegram/view/telegram-request-detail-view.tsx` (Mini App buyer: drop confirm button), `sections/request/components/buyer-steps/step-5-receive-goods.tsx` (web buyer: drop confirm button), `sections/request/components/seller-steps/step-4-waiting-for-confirmation.tsx` (web seller: code display → code input)
+**Why:** The handover flow was wrong/duplicated: the buyer had a «تایید دریافت کالا» button (`confirmDelivery`) AND the seller was shown the expected code. Per the user, the single correct mechanism is: the **buyer gives the 6-digit code, the seller enters it** to confirm — and that 403'd anyway (`confirmDelivery` compared session ObjectId `!==` PG-uuid buyerId — same id seam). Changes: (1) Mini App buyer (`status delivery`) now only displays the code to hand over — the `confirmDelivery` button/handler/import removed. (2) Web buyer step-5: removed the «تایید دریافت کالا» button (kept the code display + an explanatory note). (3) Web seller step-4: replaced the code **display** (`getDeliveryCode`, which leaked the code to the seller and 403s post-v2.8.79) with a 6-digit **input** + «تایید تحویل کالا» calling `verifyDeliveryCode(id, code)`. Both `confirmDelivery` and `verifyDeliveryCode` reach the same `delivered` state, so no escrow-release regression. (Mini App seller already had the input from v2.8.94.)
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. After deploy: buyer sees only the code (no confirm button); seller enters the buyer's code → status → delivered; no 403.
+
+---
+
 ### 2026-06-04 — backend@v2.8.81 — Public shop settings: resolve uuid→legacy ObjectId (name/avatar were blank publicly)
 
 **Commits:** backend v2.8.81

From e83942413c573cf14a2e36d1b97a4cae38b82e68 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 23:22:47 +0330
Subject: [PATCH 45/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.96=20?=
 =?UTF-8?q?=E2=80=94=20no=20false=20email-verified=20badge=20for=20no-emai?=
 =?UTF-8?q?l=20users?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 3e4472b..01b9911 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — frontend@v2.8.96 — Mini App account: don't show "email verified" when the user has no email
+
+**Commits:** frontend only (v2.8.96)
+**Touched:** `sections/telegram/view/telegram-account-view.tsx`, `sections/telegram/locales/{fa,en,types}.ts` (`email_not_set`)
+**Why:** A Telegram sign-up has `isEmailVerified=true` but no email address, so the account header showed a green «ایمیل تأیید شده» badge even though the email field was empty. Gated the verified badge on `user?.email && user?.isEmailVerified`. Added a third state for the no-email case: a «ایمیل ثبت نشده» badge that opens the in-shell settings (`onOpenSettings`) to add an email. The not-verified (has-email-but-unverified) branch is unchanged.
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. After deploy: a Telegram user with no email sees «ایمیل ثبت نشده» (→ settings), not a false «ایمیل تأیید شده».
+
+---
+
 ### 2026-06-04 — frontend@v2.8.95 — Delivery confirmation: code is entered by the seller, buyer's «تایید دریافت کالا» removed
 
 **Commits:** frontend only (v2.8.95)

From 5998acabddf4b5e9f031dbb1b7433c59b7f3bf99 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Thu, 4 Jun 2026 23:50:17 +0330
Subject: [PATCH 46/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.82=20+?=
 =?UTF-8?q?=20frontend=20v2.8.97=20=E2=80=94=20stepper=20advance=20fixes?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 01b9911..cb3dafa 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-04 — backend@v2.8.82, frontend@v2.8.97 — Stepper advances: offer→step, seller offer detection, real-time on code-verify
+
+**Commits:** backend v2.8.82, frontend v2.8.97
+**Touched:** backend `services/marketplace/marketplaceController.ts` (`getOffersForRequest` sellerId filter, `verifyDeliveryCode` socket emit); frontend `sections/request/request-config.tsx` (buyer `received_offers`→3), `actions/marketplace.ts` (`getSellerOfferForRequest` fallback)
+**Why:** Three related stepper bugs surfaced while testing an offer end-to-end. (1) **Buyer stepper stuck at "awaiting offers" (2)** after an offer arrived: `determineBuyerStep('received_offers')` returned `offersCount>0 ? 3 : 2`, but callers that don't thread `offersCount` (the Mini App) got 2. The status itself means an offer arrived on the buyer's own request, so it now returns 3 unconditionally. (2) **Seller stuck on "send offer" (1)** after submitting: `getSellerOfferForRequest` matched offers by `o.sellerId === user._id`, but `o.sellerId` is a PG uuid and `user._id` is the legacy ObjectId (the seam) → no match → `sellerOfferStatus` undefined → step 1. Backend `getOffersForRequest` now filters to the seller's own offers via `sameUser` when `?sellerId=` is passed, and the client returns `data[0]` as a fallback. (3) **Seller needed a manual refresh** to go from "awaiting buyer" (4) to "receive funds" (5): the seller's code entry (`verifyDeliveryCode`) replaced the buyer's `confirmDelivery` in v2.8.95 but never emitted a socket event, so no live update. Added the `purchase-request-update` / `status-changed` emit on successful verify (matching what `confirmDelivery` did).
+**Verification:** backend `npx tsc --noEmit`; frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint — all clean. After deploy: buyer sees step 3 once an offer arrives; seller sees step 2 right after sending an offer; seller's stepper advances to "receive funds" without a manual refresh after entering the code.
+
+---
+
 ### 2026-06-04 — frontend@v2.8.96 — Mini App account: don't show "email verified" when the user has no email
 
 **Commits:** frontend only (v2.8.96)

From e848be0a902afcc6409b1390d48710d19b2d390b Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Fri, 5 Jun 2026 00:02:43 +0330
Subject: [PATCH 47/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.98=20?=
 =?UTF-8?q?=E2=80=94=20seller=20shop=20product-type=20filter=20+=20small-s?=
 =?UTF-8?q?hop=20controls?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index cb3dafa..5ae70fc 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-05 — frontend@v2.8.98 — Mini App seller shop: product-type filter + show controls for small shops
+
+**Commits:** frontend only (v2.8.98)
+**Touched:** `sections/telegram/view/telegram-seller-shop-view.tsx`
+**Why:** The seller shop (per-seller template list) already had search + sort but (1) no filter, and (2) the controls bar was gated on `allTemplates.length > 3`, so a typical 3-template shop showed no controls at all. Added a product-type filter (chips built only for the types the seller actually sells — physical/digital/service/consultation, plus «همه») wired through `TelegramListControls`, and lowered the controls threshold to `> 1` so shops with 2–3 templates still get search/filter/sort.
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. After deploy: opening a seller shop with ≥2 templates shows the controls bar; the filter chips reflect the seller's product types and narrow the list.
+
+---
+
 ### 2026-06-04 — backend@v2.8.82, frontend@v2.8.97 — Stepper advances: offer→step, seller offer detection, real-time on code-verify
 
 **Commits:** backend v2.8.82, frontend v2.8.97

From 25abdbffe4bd1f03017931b8561407f573984fef Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Fri, 5 Jun 2026 00:21:55 +0330
Subject: [PATCH 48/50] =?UTF-8?q?Activity=20Log:=20frontend=20v2.8.99=20?=
 =?UTF-8?q?=E2=80=94=20Mini=20App=20buyer=20offers=20list=20+=20select=20&?=
 =?UTF-8?q?=20pay?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 5ae70fc..69f56ac 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-05 — frontend@v2.8.99 — Mini App buyer: see received offers + select & pay in-shell
+
+**Commits:** frontend only (v2.8.99)
+**Touched:** `sections/telegram/view/telegram-request-detail-view.tsx`, `sections/telegram/locales/{fa,en,types}.ts` (`offers_title`, `offer_select_pay`, `offer_delivery_days`, `offer_accepting`)
+**Why:** When the buyer's stepper reached «انتخاب و پرداخت» (step 3, status `received_offers`) the Mini App had no way to act — the pay CTA only showed for `pending_payment`. Now, for a buyer on an offer-selection status, the detail view fetches and lists the received offers (seller, price, delivery days, description) and each has a «انتخاب و پرداخت» button → `acceptOffer(requestId, offerId)` (sets `selectedOfferId`, moves to `pending_payment`) → `refresh()` → opens the in-shell direct-transfer payment screen via `onPay`. Reused the existing offers SWR (broadened from review-only to also fire on `received_offers`/`offers_received`/`in_negotiation`).
+**Verification:** frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint clean. After deploy: buyer opens a request with an offer → sees the offer card → «انتخاب و پرداخت» → in-shell payment opens; paying advances the stepper.
+
+---
+
 ### 2026-06-05 — frontend@v2.8.98 — Mini App seller shop: product-type filter + show controls for small shops
 
 **Commits:** frontend only (v2.8.98)

From de3d61b11d76477e79453abfb37839c353d19693 Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Fri, 5 Jun 2026 00:45:59 +0330
Subject: [PATCH 49/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.83=20+?=
 =?UTF-8?q?=20frontend=20v2.8.100=20=E2=80=94=20select-offer=20403=20+=20d?=
 =?UTF-8?q?elivery-time=20fix?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 69f56ac..9f947b9 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-05 — backend@v2.8.83, frontend@v2.8.100 — Select-offer 403 (id seam) + offer delivery-time `[object Object]`
+
+**Commits:** backend v2.8.83, frontend v2.8.100
+**Touched:** backend `services/marketplace/marketplaceController.ts` (`selectOffer`); frontend `sections/telegram/view/telegram-request-detail-view.tsx`
+**Why:** Testing the new Mini App «انتخاب و پرداخت» surfaced two bugs. (1) **403 on select-offer**: `selectOffer` gated buyer ownership with `toIdString(purchaseRequest.buyerId) !== buyerId` — the session legacy ObjectId vs the PG-uuid buyerId (the recurring seam) → the real buyer got 403. Switched to `!(await sameUser(buyerId, toIdString(purchaseRequest.buyerId)))`. (2) **Delivery time rendered `[object Object]`**: the offer card assumed `offer.deliveryTime` was a number, but it can be an object (`{amount, unit}`). Now extracts `dt.amount ?? dt.value ?? offer.deliveryTimeAmount` when it isn't a plain number.
+**Verification:** backend `npx tsc --noEmit`; frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint — clean. After deploy: buyer taps «انتخاب و پرداخت» → offer accepted (no 403) → in-shell payment opens; delivery time shows a number of days, not `[object Object]`.
+
+---
+
 ### 2026-06-05 — frontend@v2.8.99 — Mini App buyer: see received offers + select & pay in-shell
 
 **Commits:** frontend only (v2.8.99)

From 010bf2be1e0a4853d199a6d1ed7c629469cbbd0e Mon Sep 17 00:00:00 2001
From: moojttaba <mo.heidari@outlook.com>
Date: Fri, 5 Jun 2026 07:14:48 +0330
Subject: [PATCH 50/50] =?UTF-8?q?Activity=20Log:=20backend=20v2.8.84=20+?=
 =?UTF-8?q?=20frontend=20v2.8.101=20=E2=80=94=20notifications=20wired=20en?=
 =?UTF-8?q?d-to-end?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---
 09 - Audits/Activity Log.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md
index 9f947b9..b5c3f94 100644
--- a/09 - Audits/Activity Log.md	
+++ b/09 - Audits/Activity Log.md	
@@ -11,6 +11,15 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
 
 ---
 
+### 2026-06-05 — backend@v2.8.84, frontend@v2.8.101 — Notifications wired end-to-end (id-seam normalize + Mini App joins user room)
+
+**Commits:** backend v2.8.84, frontend v2.8.101
+**Touched:** backend `services/notification/NotificationService.ts`; frontend `sections/telegram/hooks/use-telegram-notifications.ts`
+**Why:** No notifications reached the Mini App (in-app, real-time, or Telegram push). Two root causes. (1) **Id seam:** notifications were created with whatever id the event carried — usually a Postgres uuid (`sellerId`/`buyerId`) — but everything that *consumes* a notification keys on the user's session legacy ObjectId: the in-app fetch (`req.user.id`), the `user-<id>` socket room, and `TelegramLink.userId`. So a notification stored under a uuid was invisible to fetch, never reached the room, and `sendTelegramNotificationToUser(uuid)` found `no_link`. Fix: `NotificationService.createNotification`/`createNotificationsBulk` now normalise `userId` via `toCanonicalUserId` (uuid → `users.legacy_object_id`) before persist + real-time emit + Telegram forward, so all three line up. (2) **Mini App never joined its room:** the socket connected but `use-telegram-notifications` only registered listeners — it never emitted `join-user-room`, so the backend's targeted `new-notification` emits had no subscriber. Added a `joinUserRoom(userId)` effect that (re)joins on every connect. `selfId` is the session ObjectId, matching the socket's authed id and the now-normalised emit target.
+**Verification:** backend `npx tsc --noEmit`; frontend `npx tsc --noEmit --ignoreDeprecations 6.0` + eslint — clean. After deploy: a marketplace event (offer received/accepted, payment, delivery) creates a notification that (a) shows in the Mini App bell list, (b) bumps the unread badge live, and (c) arrives as a Telegram bot message for linked users.
+
+---
+
 ### 2026-06-05 — backend@v2.8.83, frontend@v2.8.100 — Select-offer 403 (id seam) + offer delivery-time `[object Object]`
 
 **Commits:** backend v2.8.83, frontend v2.8.100