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:[e-mail] -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.