Reggeli Napindito

---
name: reggeli-napindito
description: Reggeli összefoglaló: email, naptár, AI hírek, plus Dream Engine top-of-message
---

Reggeli napindítót a CLAUDE.md formátum szerint. A beállított csatornára (chat_id: 0).

**FONTOS — Dream Engine override**: a napindító ELEJÉRE (még az email/naptár szekciók ELŐTT) tedd be a `{{INSTALL_DIR}}/DREAM.md` fájl tartalmából az 5 bucket-et — `💡 Skill-javaslatok`, `🧹 Memória-egészség`, `🎯 Top-3 holnapi javaslat`, `🌐 External opportunity`, `🛠 Skill-flotta health`. Ha a DREAM.md nem létezik vagy üres (pl. a Dream Engine valamiért nem futott le), kihagyod ezt a szekciót.

A `cat {{INSTALL_DIR}}/DREAM.md` parancs visszaadja a tartalmat, abból emeld ki a kulcs-szekciókat MarkdownV2-formátumra escape-elve.

**KRITIKUS -- a DREAM.md ELAVULT LEHET, ne másold vakon (2026-07-26, mérve).** A Dream Engine hajnali 2 körül ír, a napindító reggel megy ki. Ami közben megtörtént, arra a Top-3 javaslat HAMIS: a mért esetben a DREAM.md első két javaslata reggelre MÁR ELKÉSZÜLT, tehát javaslatként visszaadni azt jelentette volna, hogy kész munkát ajánlunk elvégzendőként. ELJÁRÁS: a Top-3 kiküldése ELŐTT minden tételre nézd meg a kész-állapotot (kanban-kártya státusza, hot memória, a ma reggel már elküldött üzenetek), és a teljesült tételeket CSERÉLD LE a valóban nyitott legfontosabbakra. Lásd `feedback_check_done_at_ideation`.

A többi szekció (email, naptár, AI hírek) maradnak a CLAUDE.md-ben leírt formátum szerint.

**AI hírek szekció -- CSAK a fő-ágensnél ({{MAIN_AGENT_ID}})**: ha NEM a fő-ágensként futsz (azaz sub-agentként), HAGYD KI az "🤖 AI HÍREK" szekciót -- sub-agenteknek nem releváns. Az email és naptár szekció marad mindenkinél.

**A `WebSearch` a fő-ágensből KÖZVETLENÜL működik -- ne vezesd le, hogy nem (2026-07-31, mérve; a gazda kérdezett rá a hiányra).** A hír-szekció egyszer kimaradt azzal a levezetéssel, hogy "külső lekérdezés kellene, azt ez a munkamenet nem futtathatja" -- csak épp a `WebSearch`-öt magát senki nem próbálta ki. Kipróbálva ELSŐRE lefutott: az elkülönített-olvasó (quarantine) szabály a NYERS oldal-tartalom behúzására vonatkozik, nem a kereső-hívásra. ELJÁRÁS: a szekciót CSAK akkor hagyd ki, ha a `WebSearch` ténylegesen HIBÁRA FUTOTT, és akkor a hibaüzenetet idézd, ne a levezetést. Két szabályból levezetett tiltás nem mérés; és sose pótold találgatással (`feedback_verify_facts_live_source`).

**Email szűrés -- NE listázz PR/CI/automata-értesítő emailt a napindítóban (tulajdonosi visszajelzésből, 2026-05-31).** A `search_emails` query-be tedd bele a kizárást: `-from:notifications@github.com -from:github.com -from:netlify.com -from:vercel.com` (és minden CI/deploy-bot). A PR-eket a flotta önállóan kezeli, a tulajdonoshoz csak kész eredmény megy -- a 📧 EMAIL szekcióba csak VALÓDI, ember-küldte / üzleti / pénzügyi levelek kerüljenek.

**A SAJÁT RENDSZEREINK TESZT-LEVELEI ÚGY NÉZNEK KI, MINT VALÓDI ÜGYFÉL-ESEMÉNYEK (2026-08-17, mérve).** A bot-kizárás a HARMADIK FELEK értesítőire készült (kód-tárhely, deploy-szolgáltató, CI). Van egy másik osztály, amit egyik szűrő sem fog meg: a SAJÁT terméked tranzakciós levelei, amiket néhány órája MI MAGUNK váltottunk ki egy teszttel. A postafiókban ezek életszerűek, mert azok is: valódi jelszó-visszaállító és valódi meghívó levelek, valódi időbélyeggel, a saját domainünkről. Aznap reggel négy ilyen ült a bejövőben egy hajnali végig-mérésből, és ha bekerülnek a napindítóba, a gazda új regisztrációt és jelszó-problémát lát ott, ahol csak a saját QA-nk nyoma van.
**ELJÁRÁS:** a levelek átnézésekor tedd fel a kérdést, hogy az adott levelet KIVÁLTOTTUK-E mi az elmúlt órákban (teszt-fiók, plus-címes cím, saját `noreply@` feladó a saját domainünkről, párban érkező meghívó és jelszó-levél). Ha igen, az nem hír, hanem melléktermék, és kimarad. A gyanú olcsón ellenőrizhető: a teszt-címeket és a mérés idejét a hozzá tartozó kanban-kártya tartalmazza. Rokon: `feedback_third_party_test_residue`.

**A FORMÁTUM: a MarkdownV2 itt kockázatos, és van rá bevált harmadik út.** Ez a műfaj (hosszú, több-szekciós, tele ponttal, kötőjellel, időponttal) többször elhalt kézi escape-eléssel. Ha KÉZZEL írod a szöveget a küldő hívásba, menj plain texttel, a szekciócímeket emoji és nagybetű adja. Ha mégis MarkdownV2 kell, GÉPI escape-et használj (minden foglalt karakter kivétel nélkül, a félkövért helyettesítő karakterpárból visszacserélve), és küldés előtt VALIDÁLJ: nulla escape-eletlen foglalt karakter, páros csillagszám. Részletek: `telegram-markdownv2-escape`.

**A HÍR-KERESÉS TÖBBSÉGE AGGREGÁTOR-BLOG, ÉS AZ NEM FORRÁS (2026-08-09, mérve).** A "AI news <dátum>" keresés első oldala jellemzően SEO-blogok listája, tele konkrétnak látszó modell-nevekkel és verziószámokkal (aznap: egy állítólagos GPT-verzió és két másik "kiadás"), amik EGYETLEN aggregátorból származnak, elsődleges bejelentés nélkül. Ezeket kimondani a napindítóban pontosan az a hiba, amit a `feedback_verify_facts_live_source` tilt: a gazda ténynek olvassa, és továbbadja.
**ELJÁRÁS:** csak azt a tételt vedd be, aminél a hírhez tartozik KONKRÉT, ellenőrizhető horgony (dátum + mérhető adat + megnevezett kiadó), a többit hagyd ki. A szekció végére írj EGY sort arról, honnan jött az anyag, és hogy mit hagytál ki verifikálatlanként. Modell-nevet, verziót, árat aggregátor-blogból SOHA ne állíts.

**ÉS A PROVENIENCIA-SOR AKKOR IS KÖTELEZŐ, HA SEMMIT NEM HAGYTÁL KI (2026-08-22, saját mulasztás, mérve).** A fenti bekezdés a KIHAGYÁSRÓL szól, ezért ha a keresés három használhatónak látszó hírt ad és egyiket sem dobod el, a záró sor természetes módon elmarad -- nálam pontosan ez történt. A következmény nem az, hogy hiányzik egy sor, hanem hogy **mind a három hír EGYFORMÁN biztosnak látszik**: az olvasó nem tudja megkülönböztetni a nevesített kiadóval alátámasztott tételt az aggregátorból jött harmadiktól. Aznap az első kettő (Bloomberg/CNBC/TechCrunch, illetve a gyártó saját bejelentő oldala) utólag kiállta a próbát, a harmadik (egy iparági arányszám) NEM volt visszavezethető elsődleges forrásra -- és a gazda pont az ilyen számot adja tovább előadáson.
**ELJÁRÁS: a záró sor a szekció KÖTELEZŐ része, nem a kihagyás melléklete.** Formája: honnan jött az anyag, melyik tételnél VAN nevesített kiadó, és melyiknél NINCS. Ha egy tételnél nincs, azt a napindítóban jelöld meg olvashatóan, ne csak a záró sorban.
**ÉS A HORGONY-KERESÉS OLCSÓ, HA A KOCKÁZATOS TÉTELRE FUT:** nem kell minden hírt visszakeresni, csak azt, ami SZÁMOT vagy TERMÉK-ÁLLÍTÁST tartalmaz (bevétel, arány, verzió, dátumhoz kötött funkció). Egy célzott keresés kiadó-névvel eldönti, és mellékesen a jobb tartalmat is meghozza: nálam a gyártó saját oldala adta meg azt a mechanizmus-részletet, amitől a hírből használható videó-téma lett.

**A DREAM.md "TÉNYADAT" SZEKCIÓI SEM MIND EGYFORMÁN TARTÓSAK (2026-08-22, mérve).** A fenti Dream-szabály úgy szól, hogy a Top-3-at újra kell mérni, a memória-egészség és a skill-flotta szekció viszont "változatlanul átvehető, azok tényadatok". Ez a mondat egy különbséget elfed: a mért ARÁNYOK (vektorizáltság, duplikátum-szám) tényleg állnak reggelig, de a DARABSZÁMOK közül azok, amiket A SAJÁT ÉJSZAKAI MUNKÁNK változtat, hajnalra elavulnak. Nálam a skill-szám: a Dream 227-et írt 02:07-kor, reggelre 229 volt, mert az éjjeli körök két skillt hoztak létre.
**ELJÁRÁS: minden olyan számot, amit mi magunk tudunk elmozdítani két óra alatt (skill-szám, kártya-szám, nyitott PR), a kiküldés előtt mérd újra egy paranccsal;** a külső mérésből jövő arányokat vedd át. Egy rossz szám a "tényadat" szekcióban rosszabb, mint egy hiányzó: az olvasó pont ott bízik benne, ahol nem ellenőrzi.