Dream Engine

Te most a "Dream Engine" éjszakai analízis-loopot futtatod. 02:07-kor vagy, {{OWNER_NAME}} alszik, NE küldj üzenetet a beállított csatornára.

A cél: az aznapi tudást átkonszolidálni és reggelre (07:30 Reggeli Napindító) felkészülni 4 priorizált javaslattal.

Mit kell csinálnod

Generálj egy {{INSTALL_DIR}}/DREAM.md fájlt az alábbi 5 bucket alapján. A formátum a fájl alján van.

Bucket 1 — 💡 Skill-javaslatok (flotta-szintű)

Nézz végig MINDEN agent (a fő-ágens és az összes sub-agent) tegnapi (24h) memóriáit és napi naplóját. Kerítsd ki:

• Volt-e 3+ szor visszatérő, manuálisan ismételt művelet ami skill-be illeszthető?
• Új, NEM lefedett pattern amit érdemes lenne skillbe önteni?

SQL minta:

sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "SELECT agent_id, content, keywords FROM memories WHERE created_at > strftime('%s', 'now', '-24 hours') AND category IN ('hot','warm') ORDER BY agent_id, created_at"

Output: 0-2 konkrét skill-javaslat. Mindegyikhez: cím + 1 mondat indoklás + "flotta-szintű" vagy "agent: <név>".

Bucket 2 — 🧹 Memória-egészség (NE delete, COLD-tier-be mozgatás)

# Vektorizálás ellenőrzés
sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "SELECT COUNT(*) as total, COUNT(embedding) as with_emb FROM memories"
# Ha NEM 100%, hívd meg a backfill endpoint-ot (Ollamaval embeddeli a hianyzo ID-kat):
curl -s -X POST http://localhost:{{WEB_PORT}}/api/memories/backfill -H "Authorization: Bearer $(cat {{INSTALL_DIR}}/store/.dashboard-token)"

# Antikvált hot-tier (>7 napos hot, nem hivatkozott a memories_fts-en az elmúlt 24h-ban)
# FIGYELEM -- a CAST és a COALESCE MINDKETTŐ KÖTELEZŐ, ne vedd ki:
#   a created_at/accessed_at INTEGER, a strftime('%s',...) viszont TEXT-et ad,
#   és SQLite-ban az `integer < text` MINDIG IGAZ (típus-sorrend: INTEGER < TEXT).
#   CAST nélkül ez a lekérdezés AZ ÖSSZES hot memóriát visszaadja, a mai aktívakat is.
#   Kétszer okozott kárt: 2026-07-30 (148 sor cold-ba, köztük aznapiak) és 2026-07-31 (35 sor).
#   A KOR dönt, nem az olvasottság (DREAMHOTKOR916): az accessed_at-et a memória-kereső
#   és a heartbeat minden olvasáskor frissíti, ezért a gyakran olvasott sorok sosem öregedtek
#   ki, a hot réteg nem ürült (2026-09-16: 57 hot sorból 38 ilyen). Az updated_at a tartalom-
#   vagy kategória-váltáskor frissül (memories_touch trigger), NULL is lehet -> COALESCE a
#   created_at-re, ami sosem NULL. Így a ma átírt régi sor sem esik ki.
sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "SELECT id, content, created_at, updated_at FROM memories WHERE category='hot' AND COALESCE(updated_at, created_at) < CAST(strftime('%s', 'now', '-7 days') AS INTEGER)"

A TÖMEGES UPDATE ELŐTT KÖTELEZŐ: először futtasd le a fenti SELECT-et, nézd meg a DARABSZÁMOT és egy MINTÁT (a legfrissebb találat dátumát!), és az UPDATE PONTOSAN azon az id-halmazon fusson (WHERE id IN (...)), ne a predikátumot ismételd meg. Ha a legfrissebb találat a mai nap, a predikátum hibás -- állj meg. (ID-lista nélkül a művelet nem fordítható vissza pontosan: 2026-07-31-én emiatt csak tartalmi mintára lehetett helyreállítani.)

Műveletek:

1. Vektorizálatlan memóriák: jelezd hányat találtál (a fire-and-forget embedding-job amúgy megcsinálja, de itt ellenőrzöd).
2. Antikvált hot/warm → COLD-tier-be PUT (UPDATE category='cold'). Sosem törlés.
3. Pontos dupla-content: jelezd, mozgass cold-ba.

A változtatásokat directly SQL-lel csináld:

sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "UPDATE memories SET category='cold' WHERE id IN (...)"

AZ UPDATE SIKERÉT NE A changes()-BŐL OLVASD (2026-08-07). A sqlite3 db "SELECT changes()" egy KÜLÖN kapcsolatot nyit, ott pedig a számláló mindig 0 -- akkor is, ha az UPDATE tökéletesen lefutott. Nálam 14 sikeresen átmozgatott sorra írt ki moved: 0-t, és egy pillanatig úgy nézett ki, hogy a művelet nem ment át. A bizonyíték a predikátum ÚJRAMÉRÉSE (a szűrő immár 0 találat) plusz a tételes ID-lista visszaolvasása (SELECT category, COUNT(*) ... WHERE id IN (...) GROUP BY category). Ugyanaz a család, mint a bucket többi mérési csapdája: a rossz műszer csendben hazudik, és itt történetesen a PESSZIMISTA irányba -- ilyenkor a kísértés az, hogy feleslegesen újra lefuttasd.

Output: rövid statisztika ("X memória cold-tier-be áthelyezve, Y vektorizálatlan rendezve").

Bucket 3 — 🎯 Project-priorítás (top-3 holnapi javaslat)

# Nyitott kanban-kártyák project + priority szerint
sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "SELECT id, title, status, project, priority, assignee FROM kanban_cards WHERE status IN ('planned','in_progress','waiting') AND archived_at IS NULL ORDER BY project, priority DESC"

Csoportosíts project szerint. A daily naplóban (utolsó 7 nap) nézd hogy melyik projekten van aktív mozgás (commit, PR, kanban-átmozgás). Hozz ki egy TOP-3 holnapi javaslatot prioritás+aktivitás súlyozva.

A NAPLÓ TÁBLA NEVE daily_logs, TÖBBES SZÁMBAN (2026-08-09 02:1x, saját elcsúszás). A daily_log NEM létezik, és az arra futó lekérdezés Error: in prepare, no such table sorral elszáll. Ez azért veszélyes, mert a hiba a kör KÖZEPÉN jön, egy head-elt kimenet aljára, és a kör simán továbbmegy: aznap a top-3 az aktivitási adat NÉLKÜL állt össze, csak a kanban-prioritásból. A helyes lekérdezés (oszlopok: agent_id, date, content, created_at):

sqlite3 {{INSTALL_DIR}}/store/claudeclaw.db "SELECT agent_id, date, substr(content,1,120) FROM daily_logs WHERE created_at > CAST(strftime('%s','now','-7 days') AS INTEGER) ORDER BY created_at DESC"

ELJÁRÁS: ha egy bucket lekérdezése HIBÁRA fut, az nem üres eredmény, hanem hiányzó bemenet. Vagy javítsd és futtasd újra ugyanabban a körben, vagy a DREAM.md ## ⚠️ Hibák szekciójában mondd ki, hogy az adott bucket csonka bemenetből dolgozott. Csendben továbbmenni a legrosszabb, mert a kimenet ugyanúgy magabiztosnak látszik.

Output: 3 sor, mindegyik formátum <project>: <kártya cím / akció> — <indok 1 mondatban>.

Bucket 4 — 🌐 External opportunities (új skill-repo ajánlások)

Hetente 1-2 alkalommal (NEM minden éjszaka — kerüljük a zajos napi javaslatot) végezz WebSearch-öt új Claude Code / agentic AI / produktivitás-skillekért. Szűrés:

• GitHub stars >100
• Recent activity (utolsó 90 napban commit)
• README clarity (skill mit csinál, hogyan kell telepíteni)

Limitáció: ha az utolsó 7 napban már volt ajánlás, skip-eld. A mérvadó forrás a DREAM.md ELŐZŐ éjszakai példánya (az "External opportunity" szekciója kimondja az utolsó futás dátumát), NEM egy .external-ops-last-run markerfájl: a markert semmi nem írja, tehát önmagában minden éjjel újrafuttatná a keresést (2026-07-27-én mérve: a marker 06-07-én megállt). Ha egyszer a markert tesszük hivatalossá, akkor a bucket végén ÍRNI is kell (date -u +%F > .external-ops-last-run), különben marad a DREAM.md archívum.

Fokozatos autonómia: ha találtál egy releváns external opportunity-t, OLVASD KI az external_skill_adoption kategóriát a {{INSTALL_DIR}}/store/autonomy-config.json fájlból. Ha a config vagy a kategória hiányzik, kezeld level 1-ként (fail closed).

• Level 1: csak jelez: kizárólag a repo URL-t és a relevancia indokát írd a DREAM.md-be. NE módosíts skillt.
• Level 2: javasol + jóváhagyás: a DREAM.md-ben adj konkrét, helyi skill-adaptációs tervet (melyik skill create/patch, mi változna), de NE írj skill-fájlt. A reggeli napindító ezt a tulajdonos elé viszi; csak későbbi tulajdonosi döntés után hajtható végre.

Az external_skill_adoption kategória legmagasabb engedélyezett szintje 2. A Dream Engine külső opportunity alapján nem hoz létre és nem módosít skill-fájlt önállóan. A tényleges adaptációhoz tulajdonosi döntés szükséges.

Output (max 1 opportunity): repo URL + relevancia + mode=report|propose.