---
name: feedback-proactive-suggestions
description: "Při auditu/refaktoru pipeline aktivně nabízej lepší API/postupy, ne jen popisuj stav"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: e6bd6ea2-647e-46c4-976e-dfcb5aa31269
---

Když uživatel ukazuje existující pipeline a já mám kontext o (a) co dělá, (b) jak často to běží, (c) na jakém objemu dat, a (d) vím o standardním lepším řešení v daném ekosystému (Graph delta, CDC, webhooks, server-side filtry…), **mám to proaktivně navrhnout**, ne čekat až se uživatel zeptá.

**Konkrétní příklad (2026-06-04):** Při auditu emailové pipeline jsem viděl `--mode sync` který projde celou schránku jen aby přes `mid in existing` zahodil 99 % zpráv, a 9 schránek s ~268k mailů spouštěných pravidelně. Microsoft Graph `messages/delta` API je přesně pro tenhle scénář (vrací jen změny + smazání od posledního deltaLink). Neudržel jsem to a uživatel se musel zeptat sám — "proč jsem se musel ptát já?".

**Why:** Reaktivní režim ("user se ptá → odpovídám") nestačí, když mám víc kontextu než uživatel. Pokud uvidím evidentně optimalizovatelný kus pipeline a znám standardní lepší nástroj, **mlčení je škoda** — uživatel pak žije s neoptimálním řešením, dokud na to nepřijde sám.

**How to apply:**
- Po dokončení popisu stavu (audit, rename, doc) udělat krok zpátky: *"co tady chybí / co by se dalo udělat líp?"*
- Když popisuju jak něco funguje a vidím, že existuje server-side API které by udělalo to samé efektivněji (delta queries, CDC, webhooks, server-side filter, batch endpoint), **nabídnout to ve stejné odpovědi**, ne čekat.
- Skryté problémy (jako "smazané zprávy v Mongo nikdy nemažeme") nezmiňovat jako poznámku pod čarou — vytáhnout je jako věc k rozhodnutí.
- Stačí 1-2 věty: *"mimochodem, tohle by šlo udělat přes X — chceš to?"* Není to plánování, je to upozornění.

Související: [[project_graph_email_import]]