notebook
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
---
|
||||
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]]
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: feedback-use-mcp-emaily
|
||||
description: "Pro statistiky/dotazy nad emaily/přílohami v Mongo používej MCP `emaily`, ne SSH+paramiko"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: feedback
|
||||
originSessionId: e6bd6ea2-647e-46c4-976e-dfcb5aa31269
|
||||
---
|
||||
|
||||
Když potřebuju zjistit cokoliv o emailech, schránkách nebo přílohách v Mongo `emaily` db, **první volba je MCP `emaily`** — ne SSH na tower + paramiko + temp script.
|
||||
|
||||
**Konkrétní příklad (2026-06-04):** Uživatel se ptal kolik příloh ve své schránce ještě nestaženo. Já jsem rovnou skočil na paramiko SSH → temp Python script → docker exec, zatímco `mcp__emaily__list_mailboxes` mi to dalo jedním voláním. Uživatel mě na to upozornil podruhé v té samé konverzaci.
|
||||
|
||||
**Why:** SSH+paramiko je oklika přes 3 vrstvy (Windows → SSH → docker exec), pomalá a navíc se mi pravidelně láme Unicode (Windows cp1252 vs UTF-8 výstup s diakritikou). MCP je přímý.
|
||||
|
||||
**How to apply:**
|
||||
|
||||
- **Vždy nejdřív** mrkni jestli to neumí jeden z MCP `emaily` tools:
|
||||
- `ping` → zdraví Mongo+PG
|
||||
- `list_mailboxes` → přehled schránek (counts, top senders, date range, with_attachments count)
|
||||
- `search` → fulltext (subject/body/recipients/attachments)
|
||||
- `find_attachment` → emaily s přílohou daného jména
|
||||
- `recent_emails` → poslední X dní
|
||||
- `read_email`, `by_sender`, `conversation_thread`, `top_senders`
|
||||
- **SSH/paramiko jen když:**
|
||||
- potřebuju raw `count_documents` s custom filtrem (např. „kolik emailů má `attachments.file_hash` chybějící" — interní stav download skriptu)
|
||||
- admin operace co MCP nevystavuje (DROP, create_index, update_many)
|
||||
- debugging samotné MCP serveru
|
||||
- Před paramiko skoč si vlastnoručně otázku: *„jde tohle přes MCP emaily?"* Pokud aspoň zhruba ano, jdi tudy.
|
||||
|
||||
Související: [[project_mcp_emaily]]
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: project-mcp-emaily
|
||||
description: "MCP server \"emaily\" - fulltext nad 9 schrankami z Microsoft Graph importu (~268k emailu)"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 49aa480f-6667-4832-b091-08f333c27872
|
||||
---
|
||||
|
||||
MCP server `emaily` v [mcp_emaily.py](EmailsImport/mcp_emaily.py), registrovan v `U:\janssen\.mcp.json` jako `emaily`.
|
||||
|
||||
**Architektura paralelni s [[project_mcp_soubory]]:**
|
||||
- Mongo `emaily.<mailbox>` (z [parse_emails_graph_v1.4.py](Python-runner/parse_emails_graph_v1.4.py)) = body_html / body_text + headers + recipients + attachments[]
|
||||
- PG `MongoEmaily.emails` (z [enrich_fulltext_emails_v1.1.py](Python-runner/enrich_fulltext_emails_v1.1.py)) = plain text + tsvector index
|
||||
|
||||
**Pipeline opraveny 2026-06-03:** v1.3 parseru ukladal plain-text emaily JEN jako prvnich 2000 znaku do body_preview a zbytek zahazoval (17 672 emailu, 6.2% korpusu). v1.4 uklada plne plain-text telo do noveho pole body_text. Pro stare zaznamy: [refetch_text_bodies_v1.0.py](Python-runner/refetch_text_bodies_v1.0.py) - prochazi Mongo, refetchne z Graph API jen tam kde body_html i body_text chybi (cca 80 min pro 17.7k emailu). Enrich v1.1 ma fallback poradi html -> body_text -> body_preview.
|
||||
|
||||
**9 schranek, ~268k emailu celkem:**
|
||||
vladimir.buzalka@buzalka.cz, vbuzalka@buzalka.cz, ordinace@buzalkova.cz, alica.buzalkova@buzalka.cz, mbuzalkova@buzalka.cz, jan.luxemburk@luxemburk.cz, vbuzalka@its.jnj.com, jarmila.kusinova@buzalka.cz, michaela.buzalkova@buzalka.cz
|
||||
|
||||
**Index tsv pokryva:** subject + sender_email + sender_name + to_addrs + cc_addrs + attachments_summary + body. Takze search najde i emaily kde slovo je jen v predmetu nebo jmene odesilatele.
|
||||
|
||||
**MCP tools:**
|
||||
- `ping`, `list_mailboxes` - prehled korpusu
|
||||
- `search(query, mailbox?, since?, until?, folder_contains?, sender_contains?, has_attachments?, limit)` - HLAVNI fulltext (websearch_to_tsquery), <<...>> snippet
|
||||
- `read_email(message_id, mailbox?, offset/length/around_match, include_html?)` - cely email, slice nebo okno
|
||||
- `by_sender(sender, mailbox?, since?, has_attachments?)` - regex na sender_email/name
|
||||
- `recent_emails(mailbox?, days, folder_contains?, has_attachments?)` - by received_at
|
||||
- `conversation_thread(conversation_id)` - cele Outlook vlakno chronologicky
|
||||
- `find_attachment(name_contains, mailbox?, since?)` - hledani podle nazvu prilohy
|
||||
- `top_senders(mailbox?, since?)` - kdo me nejvic email
|
||||
|
||||
**Why:** Mongo uz mela emaily (body_html), uzivatel se ptal jestli se musi znovu stahovat - nemusi. Stacilo z HTML udelat plain text pres BeautifulSoup a zaindexovat v PG.
|
||||
|
||||
**How to apply:**
|
||||
- Pred prvnim plnym importem 268k emailu spustit: `python U:\janssen\EmailsImport\enrich_fulltext_emails_v1.0.py` (~80 min). Pro test `--limit 500 --mailbox X`.
|
||||
- Sdileny TS config `soubory` (simple + unaccent) takze diakritika a case insensitive.
|
||||
- Pri reset/zmene parseru: bump `EXTRACTOR_VERSION` -> preparsuje vse.
|
||||
- Pri dotazu na "co poslal/posilam X" pouzivat `by_sender` namisto search - rychlejsi a vyhne se false matchum v tele.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: project-mcp-soubory
|
||||
description: "MCP server \"soubory\" - hybridni dotaz nad PG fulltextem a Mongo metadaty pro Dropbox souboru obou studii"
|
||||
metadata:
|
||||
node_type: memory
|
||||
type: project
|
||||
originSessionId: 49aa480f-6667-4832-b091-08f333c27872
|
||||
---
|
||||
|
||||
MCP server `soubory` v [mcp_soubory.py](soubory/mcp_soubory.py), registrovan v `U:\janssen\.mcp.json` jako `soubory`.
|
||||
|
||||
**Architektura:** Postgres `MongoSoubory.documents` (fulltext tsvector + body) + MongoDB `soubory.{42847922MDD3003,77242113UCO3001}` (metadata + content.*). Source skripty: [scan_files_v1.0.py](soubory/scan_files_v1.0.py), [enrich_files_v1.0.py](soubory/enrich_files_v1.0.py), [enrich_fulltext_v1.2.py](soubory/enrich_fulltext_v1.2.py).
|
||||
|
||||
**Tools:**
|
||||
- `ping` - health check + counts per studie
|
||||
- `list_studies` - prehled korpusu, ext breakdown, fulltext coverage
|
||||
- `search(query, study?, ext?, since?, folder?, limit, with_metadata)` - HLAVNI fulltext (websearch_to_tsquery), ranked + ts_headline snippet `<<...>>` + Mongo content.* enrichment
|
||||
- `read_document(path|mongo_id, offset, length, around_match)` - cele body, slice nebo okno kolem matche
|
||||
- `get_metadata(path)` - raw Mongo doc bez body
|
||||
- `recent_files(study?, days, ext?, limit)` - co se zmenilo (mtime)
|
||||
- `find_duplicates(study?, min_size_kb, limit)` - sha256 groups, wasted_mb_estimate
|
||||
- `by_author(name, study?, ext?)` - regex na content.author / last_modified_by
|
||||
- `browse_folder(folder, study?, ext?)` - regex na parent_folders
|
||||
|
||||
Pro EML/MSG pouzij `search(..., ext=["eml","msg"])` + `by_author(jmeno, ext=["eml","msg"])` - samostatny email tool je redundantni a navic by se pletl s [[project_graph_email_import]].
|
||||
|
||||
**Aliasy studii:** `MDD3003` -> `42847922MDD3003`, `UCO3001` -> `77242113UCO3001`. None = obe.
|
||||
|
||||
**Why:** [[project_claude_learning]] - chce se ptat v chatu ("najdi mi dokument o X", "co psal sponsor Y"), nikoli volat CLI.
|
||||
|
||||
**How to apply:** Po restartu Claude Code budou nastroje dostupne jako `mcp__soubory__*`. Pred volanim search radeji nejdriv `list_studies` aby clovek vedel co je v korpusu. Pri velkem body pouzij `around_match` misto stahovani celeho dokumentu.
|
||||
Reference in New Issue
Block a user