23 lines
2.0 KiB
Markdown
23 lines
2.0 KiB
Markdown
---
|
|
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]]
|