🧠 מוניטור

PR #409 merged d582312, live. Meta dynamic URL ({{1}} at end + example). Editor toggle + example; Make send-template linkValues -> button_url_values (published to Make app lychee-gytclg eu2, api+expect = master); API catalog; automation send_template url_vars rendered + encodeLinkValue; inbox fill dialog; sendTemplate refuses missing value by button name before Meta; campaign-execute refuses such templates. npm test 3814/3814. Requested by a customer (Gilad Ashkenazi, WhatsApp group).

PR #405 merged 495f54e. Make app lychee-gytclg (eu2): new RPC customFields (POST + api PUT) -> /make-contact-fields, label 'label · key' + date format; updateCustomFields expect: key select rpc://customFields mappable, value help YYYY-MM-DD. Live before = master (backup saved), after = repo. Server unchanged. Found: קל ביט channel 5ba90458 field תאריך_לידה has 1576 values in dd-mm-yyyy (not ISO) so the contact card date input shows empty; not touched.

Channel 833d5abe (מוצרי פרסום ומתנות, account גאדג'טשופ 63cfbe1b), coexistence, wabaId 2236905920431637, phoneNumberId 1304154982780745. Stored token valid: GET /me -> Builders System User 122100015243460003. GET waba, phone, waba/phone_numbers, waba/subscribed_apps all 400 code 100 subcode 33 (object not visible to this token). Last inbound 2026-09-25T22:17Z, last delivered outbound 2026-09-25T13:57Z, first failure 2026-10-11T10:18Z template send code 100; 'תיקון חיבור' (cloud-register) fails the same way. Conclusion: client side removed the system user/app access to the WABA, or moved/deleted the WABA. Not fixable from our side; needs client to reassign asset or reconnect. Webhook-events lookup for account_update timed out (wap_webhook_events size, see night task 2). Read-only, nothing changed.

PR #403 merged 1aac6ca, live on /api/wap/version; master verify+smoke success. New src/app/wa/trigger-picker.tsx (TriggerPicker radiogroup with roving tabindex, TestModePanel switch 56x44), theme.css wa-trigger-*/wa-switch* light+dark. Groups as 2-column panels so 2/3/4 per group never leaves a hole (ready for #365 facebook_lead). Contrast measured: light label 17.5 hint 4.79 selected hint 4.52; dark label 12.9 hint 7.21; warning 6.84/8.05. 390: 10 cards 60px, same width, no truncation, no horizontal scroll. Display only, wap-triggers.ts untouched. tests/trigger-picker.test.ts 18; npm test 3762/3762.

PR #402 merged as 30ed477 and deployed; /api/wap/version returns it; GitHub verify AND smoke both completed success on that commit. Production check: /wa/reseller returns 307 to login exactly like /wa/chats and /wa/settings, confirming middleware now treats it as an ordinary console route. BEFORE: the only entry point was a card at the bottom of the billing tab in settings, rendered behind isAdmin && tab === 'billing', linking out of the console to a standalone page. CHANGE: 'reseller' added to WapViewKey and VIEW_KEYS in wap-route.ts so /wa/reseller parses as a console address and src/app/wa/[screen] serves it inside the normal shell (same nav, same mobile chrome, same back button). Deleted src/app/wa/reseller/page.tsx, which is what lets [screen] match the segment; reseller-portal.tsx and its children stay. Links already sent keep working because the address did not change. Deliberately NOT added to USER_VIEW_OPTIONS: those are per-person grantable screens and this one is decided by the account being a reseller, so listing it there would have offered it in the tab-grant UI to anybody. It sits beside settings in UTILITY and appears only when reseller-status answers enabled && (is_reseller || operator), asked once and only when the three conditions the server also requires are already true (admin or operator, channel_ids null, not blocked), so an ordinary customer never gets a pointless 404. GATE NOT WIDENED: resellerEnabledFor and resellerManager are untouched and still refuse every action server-side; hiding the tab is presentation only. A user without the gate who types /wa/reseller is sent to the dashboard, but only after identityReady AND the gate have both answered, so a real reseller is not bounced off their own tab mid-load. Opens without a WhatsApp number like the social screens. Removed the billing-tab card and reseller-link.tsx entirely rather than keeping a shortcut: two doors to one room drift apart. Label chosen 'ניהול לקוחות' after rejecting 'הלקוחות שלי', because every other nav label is a neutral noun and 'לקוחות' alone reads as אנשי קשר. VERIFICATION: npm test exit 0 with 3762 passed 0 failed, typecheck exit 0, build exit 0, CI verify and smoke both green on head 181acd5 / merge 30ed477. Browser at desktop and 390px via the repo's own /wa/demo/reseller, which exercises the same ResellerPortal component, confirming it still renders after the page removal. Nine of thirteen new tests fail on master; the four that pass are the server-gate assertions plus 'not a per-user grantable view', present specifically to prove the permission was not widened. NOT VERIFIED: the tab itself inside a real logged-in reseller console, which needs a live reseller session I will not create. Worth a look on an Easyflow login. NOT DONE: no migration, no billing logic, no reseller data touched, no Cardcom call. Port 3022 was held by another session's dev server; flipped autoPort locally and restored .claude/launch.json so it is not in the diff. SCOPE NOTE: the console is reserved for other sessions in my lane definition; the main session routed this here and confirmed via tools/agents-status.mjs that nobody else was on wa-client.tsx, and PR #399 which it warned about was already merged.

PR #313 REVIVED, REBASED, RESHAPED, MERGED AND DEPLOYED. Merge commit 1efadd8; live /api/wap/version returns it; production smoke /api/wap/auth 200 and /wa/signup 200. Sasha's decision 11.10 via the main session: card window after onboarding, NOT blocking. That reverses the 23.09 'mandatory' shape I built. REBASE VS REBUILD: measured first, 75 commits of drift; of the touched files only wa-client.tsx (14 commits incl. my #389) and CHANGELOG had moved, wap-billing.ts by one. Chose rebase because the Cardcom 'save' operation, the hard part that keeps the end-of-trial charge single, was undisturbed and risky to re-derive. Squashed the branch to one commit first so conflicts resolved once; the ONLY conflict was CHANGELOG; typecheck passed on the rebased tree before new work. BEHAVIOUR: window opens after the tour; charge:false makes it a J2 validation that stores the card and takes nothing; amount and trial end date shown before entry via billing-summary, same resolver as #389 so an agreed rate quotes the agreed rate; 'אוסיף אחר כך' closes it permanently and sets onboarding_state.card_deferred_at (its own field, NOT dismissed_at, because dismissing the setup checklist must not silence a missing payment method); a quiet row then appears on the dashboard checklist; the existing lockout screen speaks at trial end. The trial runs its full length either way. trialCardPromptOpen and trialCardReminderOwed read one shared cardFacts in the shell so exactly one surface is ever showing. trialCardRequired keeps the safety rule: partners, operator-opened accounts and accounts that already hold a card are never asked, unknown billing data fails open, admin only. NO DOUBLE CHARGE: 'save' opens no term, does not set billing_status active, does not clear trial_ends_at, does not sync customer status, so runTrialBilling still sees a trial with a card at the end and charges once; ChargeAndCreateToken would have charged on save AND at trial end. It also fixes the previous 'replace' label that would have written 'הכרטיס אומת והוחלף' into every new customer's history about a card that never existed. Hash branch still keys on the raw period so addon ExternalUniqTranId values are byte-identical. auth now returns has_card as a boolean only. VERIFICATION: npm test exit 0 with 3716 passed 0 failed, typecheck exit 0, build exit 0, GitHub CI verify passed in 2m57s on head 5c014db. Browser on the real build at desktop and 390px via a throwaway harness (deleted). Two of five new behavioural tests fail on the required version; the other three are invariants holding either way and are labelled as regression locks, not coverage. Note on method: reverting the whole module made the test file fail to LOAD so everything 'failed' for the wrong reason; I reverted only the behaviour and kept the exports, and the numbers are from that. NOT DONE: no Cardcom call of any kind, no charge, no refund, no subscription change, no migration. Post-deploy check: zero billing events today, 15 accounts still trial, nothing moved for any customer. The 10 locked-out accounts were deliberately left untouched; they already see the lockout screen with the amount from #389. Port 3022 was held by another session's dev server; flipped autoPort locally and restored .claude/launch.json, so it is not in the diff.

PR #399 (claude/template-link-button): up to 2 static URL buttons per template in both editors, mixed with quick replies; wap-template-buttons.ts split/validate/build helpers; edit dialog and new-version previously mapped every button text to QUICK_REPLY, silently converting URL buttons; kept kinds (PHONE_NUMBER, dynamic URL) round-trip verbatim. Static URLs only, since no send path passes button parameters. tests/template-link-buttons.test.ts 16 tests, 4 mutations caught, full suite 3711/3711, tsc clean, browser QA desktop light + 390 dark with intercepted API. Also merged PR #398 (presence test no longer hangs test runs). CI pending on #399 at time of logging.

Read-only GETs to Graph v21.0 with each channel's own token. Maor (channel 7ca3f398, WABA 1932478564618456): welcome (MARKETING, previous_category UTILITY) and ask_payment (UTILITY) both status REJECTED, rejected_reason SCAM. ask_payment body asks for bank account confirmation and ID photo to transfer winnings. WABA account_review_status APPROVED, phone quality GREEN, status CONNECTED; business not verified (141010, LIMITED), same as other clients. Our wap_templates rows match Meta (synced 07:40 UTC 11.10). Osherat (channel 16669de1, WABA 2092001114754173): mashov_beikvot_peilut_baut_sifer status PENDING at Meta, rejected_reason NONE; it had been APPROVED on 09.10 04:58 UTC per webhook, so the PENDING is a resubmission after edit. Template status webhooks still arriving (last 10.10 17:04 UTC), so an approval will update automatically. Nothing changed at Meta or in the database.

PR #394 merged 98c1457, live. Migration 20261011090000_wap_flow_waits_make_buttons applied to shxsdijepxzybjjhxxjz (button_runs jsonb, flow_kind make), rollback round trip OK, types regenerated. Make app lychee-gytclg (eu2) sendTextMessage/sendTemplateMessage api+expect+interface PUT via SDK API, all 8 sections now equal repo; fields visible via Make MCP. No sends. Not yet proven: rpc dropdown inside array, real press end to end.

Full Android shell QA on emulator lychee-test (API 35, 1080x2400, density 420), app versionCode 3 installed, logged-in console loaded from production. VERIFIED WORKING: safe-area insets (WebView bounds [0,136][1080,2337] exactly match statusBars=136 and navigationBars=63 from dumpsys window displays); back button (handled by @capacitor/app OnBackPressedCallback canGoBack/goBack, confirmed by CoreBackPreview log); external links (BridgeWebViewClient.shouldOverrideUrlLoading -> bridge.launchIntent); file upload and camera capture (BridgeWebChromeClient implements onShowFileChooser; NOT declaring CAMERA is the supported path per isMediaCaptureSupported()); POST_NOTIFICATIONS (merged in from the push plugin, confirmed in the merged manifest); downloads (custom handler with cookie); FileProvider paths present. DASHBOARD FIX VERIFIED ON DEVICE: every stat label 53px tall and every value ~68px, i.e. single line, including ממתינות לתשובה which wrapped before; זמן מענה at 501px wide confirms service cards went full width. BUG FOUND AND FIXED: window.open(url, _blank) is a no-op in the app - @capacitor/android has zero matches for setSupportMultipleWindows or onCreateWindow - so the צפייה בטופס button in forms.tsx did nothing. Replaced with an anchor; PR 391 merged to fb1c2c2. KEYBOARD FIX NOT PROVEN: dumpsys window displays reported InsetsSource type=ime frame=[0,0][0,0] visible=false throughout - the emulator never showed a soft keyboard for a WebView input even with hw.keyboard overridden via show_ime_with_hard_keyboard=1 and Gboard installed and enabled. The test never exercised the fix. The same listener demonstrably applies bars insets correctly, which is strong circumstantial evidence only. iOS: mobile/ios does not exist on master; Xcode 27 IS now installed; CocoaPods is NOT; @capacitor/ios is installed; docs/IOS.md exists (194 lines) but its code has never been compiled.

Night QA of billing, plans and signup screens. FINDING 1 (headline): live read-only query found 10 accounts with billing_status='trial', trial_ends_at in the past, not partners, and ZERO with a cardcom card on file. Longest locked out 19 days (טסט 3). Two had real usage: value-x imported 161 contacts, ארבע כנפות has 14 contacts and 1 message. None converted. All 10 hit productAccessBlock -> trial_expired and see only the payment recovery path. Root cause: PR #313 (card at onboarding) has been open and unmerged since 23.09, so every self-serve signup since reaches day 7 with no payment method. Recorded as BILLING-006 in docs/TASKS.md. FINDING 2 and the only thing I changed: ProductAccessGate, the screen those 10 people see, calls billing-page whose operation resolves to ChargeAndCreateToken for an account with no card, charging the first period on completion, while the screen named no amount anywhere. The customer first met a price at Cardcom after deciding to click. Its copy also said 'choose a plan' when the route deliberately refuses a body-supplied plan and looks it up on the account. Fixed in PR #389 commit f20c86e: the amount now renders above the button via billing-summary (which applies monthlyAmountFor, so an agreed rate quotes the agreed rate) with purchaseAmount applying the cycle, same resolver the charge uses. Fails open: fetch is caught, line absent if summary fails, button never disabled on it. ProductAccessGate exported so it is renderable and testable; tests assert that anchor explicitly because without it the slice collapses and every assertion fails for the wrong reason. FINDING 3: a failed charge is invisible to the customer. past_due deliberately keeps product access and there is no banner anywhere in wa-client.tsx; past_due appears only in billing.tsx, partner.tsx and accounts.tsx. Customer learns only by opening the payments screen while the sweep retries the card every 24h indefinitely. Urgency stated honestly as LOW: 7 charges in the last 30 days, all 7 succeeded, zero failed, earliest stored card expiry is 05/27. Recorded as BILLING-007. ALSO PROVEN: the 46-character ExternalUniqTranId from PR #300 has now carried 7 real charges, not just the one on 23.09. VERIFICATION: npm test exit 0 with 3606 passed 0 failed, typecheck exit 0, build exit 0, and GitHub CI 'verify' PASSED in 4m32s, so the CI-001 account block is resolved. NOT VERIFIED and the reason PR #389 is NOT merged: the browser pane host was unreachable all night (PreToolUse hook timeout, retried four times), so I never looked at the screen I changed. I am not merging an unseen UI change on the billing path overnight; CI is green so it is a one-glance merge. NOT DONE: no charge, no refund, no subscription change, no Cardcom call, no migration. All database access read-only after verifying ref shxsdijepxzybjjhxxjz.

ריצה 2 (משימת לילה). תקין עם ראיה: cron חי (evo_checked_at לפני 9 שניות), תור שליחה 0 באיחור 10 ממתינים 0 תקועים, 0 כשלים ב-15 דק, נכנס חי (הודעה לפני 47 שניות), 35 ערוצי ענן (היה 25) ו-10 סרוקים. H-001 החמיר מ-4 ל-6: יריד החשמל active 59319 הודעות 944 אנשי קשר מנותק מ-08.10 11:59 (inbound אחרון 11:04), yotam חשבון deleted ולכן רעש אזעקה ולא לקוח, חכמים פיננסים 26 יום, מאור 48 יום, stealth ו-ארבע כנפות 24 יום. ריצה שנייה רצופה, אף ערוץ לא חזר ב-17 יום. המלצה: לדלג על ערוצים בחשבון deleted/suspended. H-002: 197 מתים (היה 183) אבל הסוג התחלף, תגובות אימוג׳י נעצרו ב-18.09 וכל 14 החדשים הם message edit original not found yet, נמסר לנתיב הוואטסאפ. H-004 שופר: 48 start 14 ok, כשלים timeout 38 no_code 21 cancel 15 save 2, הצלחה 17% ל-29%, cancel נמדד בנפרד עכשיו. H-006 הממצא הגדול ולא ברשימת ההמלצות: wap_webhook_events 568MB 272499 שורות 84552 seq_scan שקראו 6.27 מיליארד שורות. שורש מ-pg_stat_statements: claim_wap_webhook_events 383138 קריאות, ה-WHERE הוא OR בין status=pending/available_at ל-status=processing/lease_until, ושני האינדקסים החלקיים מכסים כל אחד צד אחר, ולכן הפלאנר בוחר seq scan. המלצה לנתיב הוואטסאפ: אינדקס על (status, available_at, received_at, id) או פיצול ל-2 שאילתות. לא נגעתי, זו הטבלה שלהם לפי המנדט. H-007: הגיבוי קורא את כל הטבלה, select * עם offset, 546 קריאות ב-474ms ו-681 ב-265ms, כי wap_webhook_events בשורה 121 של lychee-backup-contract.mjs. תוקן: work_items_touch search_path נעוץ (linter 0011), PR #385 מוזג 2d924f4, verify עבר 4:32, הדומיין החי מחזיר אותו קומיט, proconfig=search_path="", טריגר הוכח יורה בטרנזקציה שגולגלה לאחור, work_items נשארה 13 שורות ו-0 נגעו. לא נגעתי בכוונה: הרחבות pg_trgm ו-moddatetime (3 אינדקסי trgm ו-11 טריגרים תלויים, דורש מיגרציה מתוכננת), 90 טבלאות RLS ללא policies (בכוונה לפי AGENTS.md, deny מכוון, אסור לתקן), 40 FK בלי אינדקס (מויינו לפי גודל וסריקות, אף אחד לא שווה, הטבלאות זעירות או כבר משורתות), 35 אינדקסים לא בשימוש (לא נמחקו, רבים שייכים לפיצ׳רים חדשים), Auth connections 10 (הגדרה, לבוקר). תיקון תיעוד: CI-001 ו-PROJECT-STATE אומרים שהאקשנס חסום מאז 22.09, זה לא נכון יותר. מצב ב-business-brain/projects/lychee-health-runs.md

Sasha messaged test Page Lychee App Review (1357487447445381). 2 inbound events processed in ~1s (thread b4055f2b). Reply sent from Lychee console 10:58Z: wap_social_messages status=sent with mid. Video 3-pages_messaging.mp4 uploaded; pages_messaging now complete in submission 1766306414625917 (7/10 new permissions complete).

Two bugs reported from a real Android install. (1) KEYBOARD: MainActivity.keepContentOutFromUnderTheSystemBars() requested only systemBars()|displayCutout() insets and returned WindowInsetsCompat.CONSUMED. Type.ime() was never requested and CONSUMED stopped insets propagating, so the window never shrank and window.visualViewport.height never changed. The existing iOS-oriented visualViewport handler in wa-client.tsx (drives --wa-viewport-height, used by the shell at line ~943) therefore never fired on Android. Fix: bottom padding = max(bars.bottom, ime.bottom); plus android:windowSoftInputMode=adjustResize on MainActivity for API 24-29 where ime() insets are unreported. No double-shrink since visualViewport measures the already-resized WebView. (2) DASHBOARD: both stat grids used min-[360px]:grid-cols-2, giving ~90px text column at 375px. Counters now grid-cols-2 with whitespace-nowrap value, text-[25px] and w-10 icon below sm; the four service cards now grid-cols-1 below sm so their explanatory note survives. Desktop (sm/xl breakpoints) unchanged, re-verified at 1024px. VERIFICATION: both grids reproduced at 375px from exact shipped markup in an isolated harness, measured before/after - zero clipped elements, zero horizontal overflow, all values/labels/notes single-line. Android assembleRelease OK, tsc clean, 3579 tests pass, next build OK. Static sweep of all src/app/wa/*.tsx for phone-breaking layout: 35 candidates, all triaged as safe (behind md:, inside overflow-x-auto, or small-button grids). Public pages audited at 375px in real mobile emulation: /wa/login clean (0 overflow, 0 small targets, 0 em dashes); /wa/signup has 1 touch target under 44px (Google rendered button). UNRESOLVED: horizontal scrollbar seen in the report - not the grids, not the shell (main has min-w-0 + overflow-hidden); could not reproduce because Chrome would not apply mobile emulation to an authenticated page. Branch lane/mobile rebased onto master, commit 705d208, PR 343 open and NOT merged - so neither fix, nor the earlier Google-sign-in fix, is live yet.

PR #377 merged adb97bc, verify success on head ed2a38c, live via /api/wap/version. Meta docs 09.10: reply buttons max 3 title 20; list max 10 rows, row title 24, opener 20, section title 24 required. New src/lib/wap-reply-options.ts (replyInteractive, replyShape, limits; one option length 20). cloudSendButtons sends button<=3 / list 4-10, id=title=option text so list_reply routes by label. FlowNode.list_button (opener, default בחירת אפשרות), normalizeButtons caps 10, lint for >10 and opener>20, flowForSave trims opener. Editor: up to 10 boxes, opener field above 3, ReplyOptionsPreview. Palette hint, public API doc, AUTOMATION-STUDIO.md updated. Scanned numbers still run no automations (wap-channel-caps). Tests: reply-options.test.ts (4 fail on old code), automation-draft-api test updated for the 3-cap; 3579 pass, tsc, build. No real messages sent. Builder screenshot not taken: app session in Chrome logged out.

PR #376 merged 810d952, verify success on head 9c5ded8, live via /api/wap/version. Meta components doc checked 09.10: 10 quick replies, 25 chars, >3 shows 2 + See all options, 4+ not rendered on WhatsApp desktop. New src/lib/wap-template-buttons.ts (limits, templateButtonsAsShown, templateButtonProblems) used by wap-template-submit.ts (was 3 buttons/20 chars) and both editors in wa-client.tsx (TemplateButtonsPreview, BUTTONS_HINT). Public API doc string updated (importless catalogue, literal numbers). In-window interactive buttons (wap.ts:1123, wap-flow.ts:685) untouched at 3. Tests: template-ten-buttons.test.ts (limits, fold, 10 builder ports, button 7 routes to step 7, unwired 10th named) + template-submit-contract updated; 4 fail on old code; 3566 pass, tsc, build. Live UI check on app.lychee-ltd.com templates editor: 5 buttons -> 2 + fold + note; 11 -> warning and submit disabled; form cancelled, nothing submitted to Meta, no messages sent.

Test Page Lychee App Review (1357487447445381), account c257dd3f (ליצ'י). Created lead form 1912920616783282 via Graph API (POST /{page}/leadgen_forms, page token, pages_manage_ads). POST /{form}/test_leads -> leadgen 1805224214010765. wap_leads row status=fetched at 11:25:55Z, contact_action=none, last_error null. Proves leadgen webhook + GET /{leadgen-id} (leads_retrieval) on production.

Independent verification of PR #370 (branch fix/make-automations-dropdown-401), which is OPEN and NOT merged as of 2026-10-08T14:30Z, so the 401 is still live. Confirmed the diagnosis against origin/master: make/lychee/rpcs/channelAutomations/communication.jsonc calls /make-automations; the route DOES implement it (route.ts line 1176) but the path is in neither the proxy PUBLIC list nor EXTERNAL_ACTIONS. Audited all 14 URLs the Make app calls: make-automations is the only one missing from both. Tenancy on that handler is correct and needs no OWNED_BY_ID line: it scopes via callerChannelIds plus eq(account_id) and the requested channel_id only filters within the allowed set; pure read. PR diff reviewed and is correct: MAKE_DROPDOWN_READS is kept out of PUBLIC_ACTIONS so it does not become an MCP tool, scope is conversations:read, and it is excluded from EXTERNAL_MUTATING_ACTIONS. REVIEW FINDING: the new test in tests/make-app.test.ts globs only communication.jsonc, but the webhook attach and detach URLs live in make/lychee/webhooks/incoming-message/attach.jsonc and detach.jsonc, and that webhook own communication.jsonc carries no url at all. Measured: the test collects 14 actions and misses exactly make-incoming-message-trigger. It passes today only because that action is already registered, so it would not catch the same bug class in a future webhook. One-word fix: glob *.jsonc. Not posted to the PR and not pushed, since it is another agent branch. ALSO: my last_used_at fix from 22.09 (commit 383aaee) has been working for two weeks, 27 of 45 unrevoked keys now carry a value, most recent written one minute before this check. GitHub Actions billing block from 22.09 is resolved, master runs today are green. CORRECTION to the 22.09 assumption that the Make incoming-message trigger would not be used: wap_make_webhooks now holds one subscription attached 2026-09-26, with 21 deliveries all status delivered and zero dead, newest 2026-10-01.

After PR #361 (6387eb7), Sasha reloaded and pressed the Settings test button. Its result read: the browser displayed the notification. That text is shown only when the worker posts lychee-test-shown, which it does after registration.showNotification resolves. So the full path is proven on his machine: server, VAPID signing, FCM accepted, his Chrome woke the worker, the worker displayed. The remaining cause is outside the product: macOS System Settings > Notifications > Google Chrome (and Google Chrome Helper (Alerts) on newer Chrome), alert style None, or Focus/Do Not Disturb. Chrome site permission is not the cause, since showNotification would reject without it. No code change. Changing OS settings is the user action, not ours.

PR #357 (e92b3dc) and records PR #358. Scanned numbers: the Groups screen lists is_group=true only (kind=groups), so a group is the only scanned-number conversation openable from a notification; my earlier proposal of one-to-one chats only was wrong and is recorded as such. processEvoEvent now rings for an incoming group message to exactly the people who may open it (groupChannelAllowed via providerChannelAllowed, plus assigneeMaySee as the guard enforces on every channel). Newness asked before the upsert (upsert cannot tell a repeat from a first delivery). Quiet-gap rule: a group that wrote in the last 5 minutes does not ring again; measured on the 10 scanned numbers over 7 days: 5,450 inbound group messages = 779 popups a day unthrottled, 202 a day with the rule across all ten. Click opens Groups on the right number and group, and is not armed for a person who cannot see Groups. Android FCM (mobile lane file, authorised by Sasha: do what is needed): devicesForChannel replaced by devicesForMessage using recipientsForMessage; previously an agent in an assigning account got message text for threads the console refuses to open, notifications-off was ignored, hide_text ignored. All 3 registered devices are admins today so nothing leaked. Now carries contact_id and the app opens the conversation (the console never read ?channel=). Verification: 3,441 tests, tsc and build clean, CI green on the exact amended SHA 21adb4e; 11 new tests drive the real Evolution intake (none existed), 5 deliberate breakages of it each fail tests, removing the assignment check fails 3 phone tests. Live: every column the rule reads exists in the real schema (checked because these functions swallow errors and a wrong column name would silence all notifications); real rule against real DB returned the registered phone owner among recipients in both testable accounts, read only, nothing sent; since deploy 37 Evolution messages saved, 0 errors, 20 unknown-instance events are other clients instances on the shared server, dropped by design. NOT proven: a ring on a real scanned number, the click into Groups in a signed-in session, FCM delivery to a real phone (never proven live). Known quirk not changed: processEvoEvent names a brand new group contact after the sender, so a first-seen group would be titled with a person name until a sync corrects it.

PR #355 (a77c3bd) and #356 (ca9cb36), verify green on the exact SHAs, production serves ca9cb36. Web Push with VAPID via web-push 3.6.7 (MPL-2.0). New table wap_web_push_subscriptions applied to shxsdijepxzybjjhxxjz after ref check: RLS enabled and forced, 0 policies, no anon grants, unique endpoint, cascade from wap_users; real register/move/forget/refuse-http round trip run and left 0 rows; anon key refused on read and write; generated types equal the hand-written block exactly. VAPID keys set in Vercel Production only (Preview not set); local copy of the private key deleted. Who is told: wap-notify-recipients.ts calls providerChannelAllowed and assigneeMaySee (extracted from conversationVisibleTo, parity test over every user/assignment/multi_agent combination). Notification starts before runAutomations/autopilotReply and is awaited after. 15 minute staleness cap so a queue replay cannot light every screen. Endpoint allowlist (fcm.googleapis.com, push.services.mozilla.com, push.apple.com, notify.windows.com) on a dot boundary against SSRF. Proof in real Google Chrome (throwaway non-incognito profile; incognito refuses push): subscribed through fcm.googleapis.com against the deployed /lychee-sw.js, real sender returned sent 1 failed 0, a NEW popup appeared with console closed, a second message replaced it, a focused window suppressed it. Synthetic data and a stub database, no customer touched. 75 new tests, 7 deliberate breakages each failed tests. NOT proven: offer card and settings switch in a signed-in session, click opening the conversation, a real Meta webhook. Decisions that deviate from the brief: offered as a small dismissible card, not a banner strip (team removed strips on 22.09, regression test guards it); scanned Evolution numbers deliberately not connected (owner personal phone, inbox cannot open them, one instance holds a 30,000 message group), guarded by a wiring test. Findings handed over, not fixed: mobile FCM devicesForChannel ignores assignment and Groups (2 of 29 multi-agent accounts have agents, all 3 registered devices are admins today); app deep link ?channel= is never read by the console; npm audit reports next, sharp, brace-expansion, fast-uri, all pre-existing.

Reported by Sasha from a real install. Two independent blockers, either sufficient on its own: (1) the GSI button uses ux_mode popup, and Android WebView opens no popups without setSupportMultipleWindows plus a WebChromeClient onCreateWindow handler, which Capacitor default lacks; (2) Google blocks sign-in from embedded WebViews by policy (disallowed_useragent). Mitigation in src/app/wa/google-sign-in.tsx: new useInsideTheApp() hook lazily imports @capacitor/core and checks isNativePlatform(); GoogleCredentialButton returns null and skips loading the GSI script entirely; GoogleAccountAccess (settings link card) also returns null, because otherwise it accepts a current password and then renders nothing where the button belongs. null state treated as do-not-show so the app never flashes a dead button. Browser unaffected. Affects three surfaces: /wa/login, /wa/signup, settings. Verified typecheck, 3181 tests, production build. NOT verified on a real device. Proper fix is native Google Sign-In via Play Services, requiring an Android OAuth client keyed to the Play App Signing certificate SHA-1. Commit a936da6 on lane/mobile, PR 343, NOT merged.

First live Instagram webhook: wap_meta_social_events instagram/message status done, received 2026-10-02 18:58:10 UTC; signature verified (so INSTAGRAM_APP_SECRET is the right value); thread created (account ליצ׳י, sender username present, name null since the profile read is best effort), 1 inbound message, unread 1, 24h reply window open; wap_ig_accounts.last_webhook_at 18:58:10. Sender had no role on the app, so Meta delivers Instagram DMs to a tester account from anyone. Next: Sasha replies from Lychee (instagram_business_manage_messages call).