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