2.0 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| feedback-proactive-suggestions | Při auditu/refaktoru pipeline aktivně nabízej lepší API/postupy, ne jen popisuj stav |
|
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