diff --git a/.planning/phases/03-mini-app-shell-geolocation/03-DEVICE-MATRIX.md b/.planning/phases/03-mini-app-shell-geolocation/03-DEVICE-MATRIX.md
index 3126e9a..c934b26 100644
--- a/.planning/phases/03-mini-app-shell-geolocation/03-DEVICE-MATRIX.md
+++ b/.planning/phases/03-mini-app-shell-geolocation/03-DEVICE-MATRIX.md
@@ -207,3 +207,28 @@ readings:
 - plain browser: `WA unknown/unknown · q 0ch · s malformed/tampered`
 
 **Re-test:** the probe line is what to report, verbatim, in the next message.
+
+## 2026-10-23 debug round 6 (DEFINITIVE — `s tampered` on a real webview)
+
+**Probe reading:** `WA ... · s tampered · loc denied` — the session gate was
+rejecting the REAL initData (empty-initData theories were wrong; the webview
+is live and Telegram-native).
+
+**Root cause:** `bot/src/security/initdata.ts` excluded the Ed25519
+`signature` field from the HMAC data-check-string. Per the official spec
+(core.telegram.org/bots/webapps §Validating data received via the Mini App),
+the bot's own HMAC check excludes **only** `hash`; the signature exclusion
+belongs to THIRD-PARTY validation. Modern webviews append `signature`, so
+every real client failed as "tampered" while all signature-less suite
+vectors passed.
+
+**Fix (deploy `bedc8126`, 50 bot tests incl. new T2b signature-field
+regression vectors):** HMAC dcs = fields minus `hash` only, in
+initdata.ts + both test-side signing helpers. Erratum header updated.
+
+**Live post-fix proof:** a minted initData WITH a signature field → 200 at
+the deployed origin (pre-fix equivalent → 401/tampered).
+
+**Re-test:** app should now validate → chain runs → permission ask /
+LocationManager read → LIVE. Probe should read `s ok · loc live` on
+success.