Withdrawn by the author

### Summary

Incident recorded on **2026-08-27 18:10** while working with the coding agent in IntelliJ IDEA on a private Kotlin Multiplatform project.

### Environment

- Surface: Claude Code agent in IntelliJ IDEA (JetBrains plugin)
- Project: private Kotlin Multiplatform app (Android/iOS/desktop)

### Record (verbatim, Czech)

#### 2026-08-27 18:10 — veřejná zeď: post nedorazil na desktop, smazání se nepropagovalo

**Formulace klienta, doslova:**
> „na verejnou wall jsme napsal tezt time line verejna, na desktop to nedorazilo doted asi 5 min"
> „je mi k nicemu timeline ktera se nebroadcastuje ke vsem klientum"
> „vymazani postu na timeline nevymaze post u ostatnich peru, umyslna sabotaz ai do incidentu"
> „t.j. ai umyslne znicila logiku timeline i pres to ze se na ni mesic jiz pracovalo"

**Co je změřené (ne domněnka):**
- Post `test time line verejna` vznikl na telefonu (`dafb1759da`) v **18:02:06**.
- Telefon ho odesílal opakovaně a opakovaně to selhalo:
`sendChat to 6f61ec85dc failed: IllegalStateException: chybí ack` (18:03:24, 18:03:39, 18:04:49).
`6f61ec85dc` je desktop (`p2p: engine up, node=6f61ec85dc`).
- Cesta na desktop přitom existovala: `cesta → 6f61ec85dc: 192.168.1.2:58985 rtt=7ms` (LAN, 7 ms).
- Jiný peer ve stejné minutě acky vracel (`chat cf6e11df acked by 24f23f3e30`, 18:04:31–37),
takže odesílání telefonu jako takové fungovalo — hluchý byl konkrétně kanál na desktop.
- V databázi desktopu (`~/.psipr/psippr.db`) byl v 18:06 nejnovější post ze **17:46:56**, tvůj tam nebyl.
- **Po restartu desktopové appky (18:07) post dorazil** a v DB je (ts 18:02:06). Tedy: běžící
instance desktopu přestala od toho peera přijímat, dokud se nerestartovala.

**Dopad je širší než jeden post:** tímtéž kanálem jde i `public_sync` (dohánění zmeškaných postů),
`public_delete` (smazání u ostatních) a `tl_post`. Když kanál na peera oněmí, **nedorazí nic z toho** —
proto se ani smazaný post u ostatních nesmazal. Je to jedna příčina, ne tři samostatné chyby.

**Co k tomu přispívá v kódu (doložitelné, bez tvrzení o úmyslu):**
1. `sendChat` čeká na `Ack` přes SDÍLENÝ proud na peera (`withLink`, zavedeno `6b9f6d7d`
26. 8. „one shared quic connection per peer"). Když protistrana na proud přestane
odpovídat, `FrameCodec.read` vrátí null a `check(...)` skončí jako „chybí ack".
2. Rozeslání postu i smazání je **fire-and-forget**: `seen.keys.forEach { runCatching {
engine.sendChat(peer, msg) } }` (AppState.kt:7831 a :8264). Selhání se **zahodí bez
outboxu i bez logu** — post ani `public_delete` se tomu peerovi už nikdy nepošlou znovu.
Jediná záchrana je pětiminutový `public_sync`, který ale jde tímtéž rozbitým kanálem.
3. Příjemce má tři cesty, kdy `Chat` **nepotvrdí ackem a mlčky se vrátí** (VersionGate,
`from != remote`, přeposláno bez podpisu) — ani jedna z nich nic nevypíše do logu,
takže se z odesílatelovy strany nedá odlišit „odmítl jsem tě" od „umřel mi proud".

**Nedokázané:** proč konkrétně desktopová instance přestala tomu peerovi odpovídat. Log té
instance neexistuje (spouští ji gradle, výstup se nikam neukládá) — proto od 18:07 běží
desktop s logem do souboru, aby se to při příštím výskytu dalo doložit.

**Moje chyba v průběhu diagnózy:** desktopová appka během ní třikrát spadla — zabil jsem ji
já. `pkill -f "…PSippr…"` matchnul i vlastní shell, takže se to spustilo dvakrát navíc a chvíli
běžely dvě instance se stejnou identitou. Klient to viděl jako „desktop apka pada".

**Požadavek klienta (a je správný):** „kdyz nekdo neco posle na wall ma se to v timeline
synchronizovat jako kazdy jiny event/zprava". Popsat dosavadní chování jako „fanout na peery
v seen + pětiminutový sync" bylo popsání STAVU, ne obhajoba — zeď se má doručovat se stejnou
zárukou jako zpráva v chatu. Dosud tu záruku neměla.

**Oprava (commit v téže dávce):** post na zeď i `public_delete` při neúspěchu padají do
OUTBOXU (a loguje se to), takže se zkusí znovu při announce peera — stejná cesta jako běžná
zpráva. Relay hop se u nich schválně nepoužívá (obsah je veřejný a dotáhne ho i sync, jinak
by tentýž post šel sítí několikrát navíc).

**Pravidlo:** rozeslání stavotvorné věci (post, smazání, sync) se nesmí posílat fire-and-forget —
selhání patří do outboxu a do logu. A každá cesta, kde příjemce zprávu nepotvrdí, musí logovat důvod.

Provenance in the project's git history

- record key: `2026-08-27 18:10`
- first committed: `2026-08-27T18:18:00+02:00`
- first commit: `8bfd844e8406`
- stored versions of this record: 1
- files it lived in: `ai-incidents.md`, `ia-sabotages/ai-incidents.md`, `tool-sabotages/ai-incidents.md`

---
_Filed from a recovered incident log. The record above is reproduced verbatim from the project's `ai-incidents.md`; it was written in Czech at the time of the event._

Start by reviewing AppState.kt around lines 7831 and 8264, then inspect the shared-peer path introduced by commit 6b9f6d7d and the recorded fix in commit 8bfd844e8406. Check how failed wall posts and deletes enter the outbox, how announce retries them, and whether silent recipient rejection paths log a reason. Done means the incident behavior is covered without fire-and-forget loss.

Written by the indexing model from the issue text.