docs: ack-gate gefalsifieerd (2026-10-05); permanente-fix-richting overruled; JPEG+PAGE_SEND_DELAY als werkende mitigatie

.env.example

@@ -22,8 +22,9 @@ DIENSTEN_DIR=../Whatsapp_Dienst/diensten
 MAX_REQUESTS_PER_DAY=5
 
 # Pauze tussen pagina-sends (ms). Staged-ghost-race-mitigatie: maakt elke pagina
-# een effectief losse send (enkele sends falen nooit). 0 = geen pauze.
-PAGE_SEND_DELAY_MS=15000
+# een effectief losse send (enkele sends falen nooit). Gemeten transmissie-latentie
+# naar ontvanger ≈ 0.83 s (2026-10-05); default = 3 x ~3.5. 0 = geen pauze.
+PAGE_SEND_DELAY_MS=3000
 
 # Admin notifications
 ADMIN_NUMBER=31612345678@c.us

AGENTS.md

@@ -188,12 +188,14 @@ getransmitteerd was) — ze zijn géén bezorgbewijs en gaven verkeerde signalen
   **`MEDIA_SEND_DELAY_MS`** (bridge-`.env`: `/home/aiaiaiaiagent/wwebjs-api/.env`, nu `500`
   sinds 2026-09-28 teruggezet van 1000; delay lost de race niet op, zie RCA)
   ná elke media-send.
-- **Bot-side pagina-pacing (`PAGE_SEND_DELAY_MS`, bot-`.env`, nu `15000`)**: sinds
+- **Bot-side pagina-pacing (`PAGE_SEND_DELAY_MS`, bot-`.env`, nu `3000`)**: sinds
   2026-10-05 wacht de bot ná elke pagina (behalve de laatste) voordat de volgende
   gestuurd wordt. Reden: ook verse single-sends van een "verloren" blz komen aan, maar
   de paarsgewijze flow (blz 2 direct na blz 1, brug-delay 500 ms) verliest blz 2 steeds
   opnieuw (casus 4027: 3 botruns + herhaalde opvraag na re-render). De pauze maakt elke
   pagina een effectief losse send — enige sends falen empirisch niet. `0` zet uit.
+  Waarde gemeten (2026-10-05): transmissie-latentie naar ontvanger-sessie ≈ 0.83 s
+  (848/833/827 ms via zelf-send + sessie-Eddy-poll); 3000 = 0.83 × ~3.5 marge.
   De brug-delay zelf NIET verhogen (delay loss effect, RCA 26-09).
 - **Bridge-`.env`-wijzigingen**: `env_file` wordt bij container-create gelezen → een
   `MEDIA_SEND_DELAY_MS`-wijziging werkt pas na een **recreate**
@@ -207,6 +209,8 @@ getransmitteerd was) — ze zijn géén bezorgbewijs en gaven verkeerde signalen
 
 **Ack-semantiek (wwebjs 1.34.7):** ack 1 = verstuurd naar server (één grijs vinkje), ack 2 = bezorgd op apparaat (twee vinkjes), ack 3 = geopend/gelezen. Let op: eerdere notities die "één grijs vinkje (ack 2)" noemden, zaten er dus naast. **Let op 2 (2026-09-26):** óók deze acks zijn geen leveringsbewijs — zie RCA hieronder.
 
+> **Verificatie 2026-10-05 — de "permanente fix"-richting is hiermee gefalsifieerd overruled.** Gemeten (live webhook-instrumentatie) dat **geghoste sends wél ack=1 én ack=2 events afgeven** (055.png/jpg ghosten met acks 1+2; alleen ack=3 bleef uit doordat het bericht nooit zichtbaar was). Daardoor: (1) een `ack ≥ 1`-gate (upstream-advies #201849/#201727) vangt ghosts **niet**; (2) `await sendMsgResultPromise` stond al aan — `waitUntilMsgSent:true` in de fork (clientController.js `sendOptions`) en wordt al geawait (Utils.js) maar resolved óók optimistisch (= no-op). Er is **geen server-zijdig signaal dat ghost vs. bezorgd discrimineert** (store, live acks, getInfo/read, ontvangende sessie — alles fabricerbaar of gebruikersafhankelijk). Enige waarheid = apparaat. De geplande fork-patch is daarom afgeblazen vóór bouwen/recreate. Werkende mitigaties i.p.v. daarvan: **alle dienstafbeeldingen als JPEG** (convert_png_to_jpg.sh in Whatsapp_Dienst/diensten/png/, json op `.jpg`; PNG-versies behouden) + bot `PAGE_SEND_DELAY_MS=3000` (gemeten transmissie-L ≈ 0.83 s × 3.5). Verlies blijft positioneel/contextafhankelijk (4027-blz2 verliest vaker dan bv. 4427), beeldstatistiek discrimineert níet (4027-055 ≈ 4427-202 qua mean/std/entropy). Bij gemist: blz los opnieuw sturen (werkt).
+
 ### RCA 2026-09-26: staged-ghost = race-conditie, géén bestandprobleem
 
 Casus: dienst 5219 (2 pagina's), 09:29 gevraagd in de groep, bot stuurt beide pagina's