szotasz/marveen/kanban-audit

Kanban 4 órás audit

Mikor fut

• 8:00, 12:00, 16:00, 20:00 (kanban-audit cron 0 8,12,16,20)

Autonómia-szint (config-vezérelt, KÖTELEZŐ ELŐSZÖR)

Olvasd be (python3-mal, mert jq NINCS telepítve egy átlagos Linux gépen):

python3 -c "
import json
d=json.load(open('{{INSTALL_DIR}}/store/autonomy-config.json'))
for c in d.get('categories',[]):
    if c.get('key') in ('kanban_archive_done','kanban_stuck_nudge'):
        print(c['key'], c.get('level'))
" 2>/dev/null

A két kategória szintje szabályozza a 2. és 4. lépést:

• `kanban_archive_done` (2. lépés): level 3 → archiváld magától. level 2 → NE archiválj, Telegramon javasold ("X db 7+ napos done archiválásra vár, mehet?") és várj jóváhagyást. level 1 → csak jelezd a számot.
• `kanban_stuck_nudge` (4. lépés): level 3 → pingeld az assignee-t magától, és CSAK 2 eredménytelen audit-kör után eszkalálj a tulajdonoshoz ({{OWNER_NAME}}) (a komment-történetből látod hányszor pingelted). level 2 → ne pingelj magadtól, Telegramon javasold a tulajdonosnak ({{OWNER_NAME}}). level 1 → csak listázd a beakadt taskokat.

Ha a config hiányzik, nem olvasható, vagy a kulcs nincs benne (a fenti parancs semmit nem ír ki) → level 1: csak jelezz, ne archiválj és ne pingelj. Ez a seed-config szintje; egy hiányzó config ne a legmegengedőbb viselkedést élesítse.

Eljárás

1. State-fájl beolvasás: store/kanban-audit-state.json tartalmazza last_audit_at Unix timestampet. Első futáskor null -> ne pingelj senkit, csak állítsd be a state-et.

A tábla eléréséhez a dashboard API-t használd, NE a sqlite3 CLI-t (lásd a Buktatókat). A port a .env-ből jön, hogy nem-alapértelmezett porton is működjön: ``bash PORT="$(sed -n 's/^WEB_PORT=//p' {{INSTALL_DIR}}/.env 2>/dev/null | head -1 | tr -d '"')"; PORT="${PORT:-3420}" TOKEN="$(cat {{INSTALL_DIR}}/store/.dashboard-token)" ``

1. Tisztítás: 7+ napos done kártyák archiválása (előbb listázd, aztán archiváld egyesével):

``bash curl -s -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban" | python3 -c " import json,sys,time cut=int(time.time())-7*86400 d=[c for c in json.load(sys.stdin) if c.get('status')=='done' and not c.get('archived_at')] o=[c for c in d if (c.get('updated_at') or 0) < cut] print(f'Tisztítás: vizsgált={len(d)}, találat={len(o)}' + ('' if d else ' (nem tudott mérni)')) for c in o: print(c['id']) " | tail -n +2 | while read -r id; do curl -s -X POST -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban/$id/archive" >/dev/null done ``

1. Beakadt task detection (megkezdett, nem mozdult -- nem csak in_progress; a logika a /api/kanban/stuck-ban él):

``bash curl -s -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban/stuck?planned_days=7&active_days=3" | python3 -c " import json,sys,time d=json.load(sys.stdin) print(f\"Beakadás: vizsgált={d['examined']}, találat={len(d['stuck'])}\" + ('' if d['examined'] else ' (nem tudott mérni)')) now=int(time.time()) for c in sorted(d['stuck'], key=lambda c: -c['last_activity']): print(' ', c['id'], '|', (c.get('assignee') or '-'), '|', round((now-c['last_activity'])/3600.0,1), 'h |', c['title']) w=d['waiting'] print(f\"Várakozó: {w['examined']}, határidőn túl: {len(w['overdue'])}, határidő nélkül: {w['without_deadline']}\") for c in w['overdue']: print(' ', c['id'], '|', (c.get('assignee') or '-'), '|', c['overdue_days'], 'nap késés |', c['title']) " ` Munka-nyom csak a felelős saját, nem gépi kommentje. Tömeges vagy gépi kommentet "automated": true-val írj (POST /api/kanban/<id>/comments). A waiting` nem tétlenség: a határidőn túliakat a tulajdonosnak jelezd, ne pingeld.

1. Beakadt task -> ping: minden beakadt kártyához küldj inter-agent message-t az assignee-nek (kivéve {{MAIN_AGENT_ID}}-nek és üres assignee-nek):

`` "Kanban-audit: a {card_id} ({title}) {hours_stale}h-ja in_progress mozgás nélkül (előző audit óta). Frissítsd a státuszt (done/waiting) vagy adj komment-et hogy mit blokkol." ``

FUTTATASI MEGJEGYZES az alabbi SQL-ekhez: a sqlite3 CLI nincs telepitve minden gepen (lasd Buktatok), ezert az SQL-t a python3 beepitett sqlite3-moduljaval futtasd: ``bash python3 -c "import sqlite3 for r in sqlite3.connect('{{INSTALL_DIR}}/store/claudeclaw.db').execute('''<IDE AZ SQL>'''): print(*r, sep=' | ')" ` Az alabbi blokkok az SQL-t dokumentaljak; a sqlite3 db "..."` alak a peldakban a LOGIKAT mutatja, a futtatas a fenti python3-wrapperrel megy.

4b. WAITING-KOR ELLENORZES (2026-07-27-tol, a teljes szoveg a referenciafajlban): ~/.claude/scheduled-tasks/kanban-audit/references/kanban-audit-step4b-waiting.md. KOTELEZO beolvasni a 4. lepes vegrehajtasakor -- az SQL-ek es a dontesi szabalyok (ATLEPO/UJ BELEPO) ott vannak, nem hagyhatok ki.

4c. KIKULDES-DETEKTOR A FRISS KARTYAKRA (2026-08-24-tol, AUDITKIKULD823 -- ez eddig HIANYZOTT, es egy ugyfel-bejelentes 4,5 orat ult miatta). A fenti harom halo (done-archivalas, beakadt in_progress, 30+ napos waiting) EGYIKE SEM fogja meg azt a kartyat, ami MA keletkezett, planned-en all, MEGNEVEZETT flotta-gazdaja van, es SOSEM lett kikuldve neki. A kivalto eset: a 01ABD89F connectors-bejelentes 15:12-kor keletkezett planned/samu-n, 19:4x-ig nulla uzenet ment rola, es a GAZDA kerdezett ra Telegramon, nem mi vettuk eszre. ``bash LAST="$(python3 -c " import json try: print(json.load(open('{{INSTALL_DIR}}/store/kanban-audit-state.json')).get('last_audit_at') or 0) except Exception: print(0) ")" ` `sql -- futtatas a python3-sqlite wrapperrel; a $LAST erteket helyettesitsd be SELECT k.id, k.status, k.assignee, datetime(k.created_at,'unixepoch','localtime'), substr(k.title,1,60) FROM kanban_cards k WHERE k.archived_at IS NULL AND k.status IN ('planned','waiting') AND k.created_at >= $LAST AND lower(k.assignee) IN (<a telepites sub-agent nevei kisbetuvel, az agents/ konyvtar szerint>) -- ALLOWLIST, NEM "NOT IN" AND NOT EXISTS (SELECT 1 FROM agent_messages m WHERE m.from_agent <> 'heartbeat' AND (m.content LIKE '%'||k.id||'%' OR (k.id GLOB 'PR[0-9]*' AND m.content LIKE '%#'||substr(k.id,3)||'%')) AND m.created_at >= k.created_at) ORDER BY k.created_at ``

A `NOT IN` SZURO NEM ELEG, ALLOWLIST KELL -- ES EZT A SAJAT SZOVEGEM MAR KIMONDTA, A LEKERDEZES MEGSEM KOVETTE (2026-08-26 08:00, merve). A lenti bekezdes 2026-08-10 ota irja, hogy KULSO szerzonel a nulla inter-agent uzenet a VART allapot (nekik PR-komment vagy email megy). A lekerdezesben viszont NOT IN ('', '<fo-agens>', '<tulajdonos>') alaku kizaro lista allt, vagyis minden kulso nev ATCSUSZOTT rajta. A 08:00-s teljes-halmazos futas OT waiting tetelt jelentett kikuldetlennek, es MIND AZ OT kulso emberhez tartozott (zollak, stivi1g-gif, tekt, szuszupaks, zsuzsa). Nulla valodi lelet, ot sor zaj -- pont az a fajta, ami mellett a valodi lelet elveszne. Jelentsd: vizsgált=N,találat=K,0→nemmért. A TAGABB TANULSAG: egy leirt szabaly, ami mellett a LEKERDEZES a regi marad, annyit er, mint a le nem irt szabaly. A szoveget es a kodot EGYSZERRE kell javitani, kulonben a skill sajat maganak mond ellent. Talalat eseten a kartya NEM keszult el magatol: kuldd ki a gazdajanak, es a kartyara menjen komment, hogy a kikuldes az auditbol pótolva lett. A NULLA TALALAT ONMAGABAN NEM BIZONYITEK -- FUTTASS POZITIV KONTROLLT (2026-08-23 20:2x, merve). A friss ablak tipikusan ures, es az ures halmaz ugyanugy nez ki, mint egy sosem-tuzelo lekerdezes. Ezert a detektort a TELJES nyitott halmazon is futtasd le egyszer (a created_at >= $LAST sort elhagyva): ha ott sem talal semmit, a MUSZER a hibas, nem a vilag. A fenti lekerdezes 2026-08-24 05:5x-kor lefuttatva: friss ablak 0 talalat, teljes halmaz planned 77 + waiting 9 -- tehat a detektor tuzel, es a friss nulla VALODI nulla. DE A KARTYA-ID-RE ILLESZTES MINDEN PR-KARTYARA HAMIS POZITIVOT AD (2026-08-24 16:0x, merve). A lekerdezes a kartya ID-jet keresi az uzenetekben (content LIKE '%'||k.id||'%'), a PR-kartyak ID-je viszont PR1059 alaku -- mi viszont a PR-t a beszelgetesben SOHA nem igy hivjuk, hanem #1059-kent. Emiatt a mai kor a PR1058-at es a PR1059-et kikuldetlennek jelentette, holott mindkettorol irtam az assignee-nek ugyanabban az oraban. A hamis pozitiv itt dragabb a szokasosnal: ELREJTI A VALODI LELETET -- aznap egy 30 napos, tenylegesen kikuldetlen kartyat (9D766E19) --, mert a lista tele lesz zajjal, es a zajos listat az ember atfutja. JAVITAS: PR-kartyanal a `#<szam>` alakot IS fogadd el. ``sql AND NOT EXISTS (SELECT 1 FROM agent_messages m WHERE m.from_agent <> 'heartbeat' AND (m.content LIKE '%'||k.id||'%' OR (k.id GLOB 'PR[0-9]*' AND m.content LIKE '%#'||substr(k.id,3)||'%')) AND m.created_at >= k.created_at) ` A substr(k.id,3) a PR prefixet vagja le. A GLOB` feltetel nelkul egy nem-PR kartya ID-jenek toredeke is veletlenul illeszkedne.

DE A SAJAT HEARTBEAT-DIGESTEM IS "EMLITI" A KARTYA-ID-T -- ES EZ HAMIS POZITIV (2026-08-25, merve). Az orankenti digest felsorolja a kartya-azonositokat (az urgent lista ES a 8 legfrissebb waiting), tehat minden ilyen kartyara talal a content LIKE '%<ID>%', es a detektor kikuldesnek olvassa. A MERT ESET: az INSTPWURES825 (urgent, holnapi hataridovel) harom oraig allt kikuldetlenul, es a uzenet-nyoma NEM nulla volt, hanem NEGY -- mind a negy a sajat digestem, ami visszaolvasta nekem a kartya ID-jet. A nyom tehat letezett, csak nem a gazdahoz vezetett. JAVITAS, egy sor: AND m.from_agent <> 'heartbeat' a NOT EXISTS belsejebe. Ez NEM mond ellent a lenti "barmilyen uzenet" szabalynak: a digest nem egy ember vagy agens emlitese, hanem egy automatikus visszaolvasas NEKEM. A HATOKORE SZUK, ES EZT IS MERD, NE FELTETELEZD: a 2026-08-25 20:00-s korben a ket valtozat (heartbeat-tel es nelkule) AZONOS eredmenyt adott, mert az akkori talalat planned volt, a digest pedig csak az urgent es a legfrissebb waiting kartyakat sorolja. Vagyis a vaksag CELZOTT: pont a legfontosabb kartyakra all fenn.

KET TOVABBI RES UGYANEBBEN A DETEKTORBAN (2026-08-25, ugyanaz a kor):

1. A STATUSZ-VALTAS KIEJTI AZ ABLAKBOL. A lekerdezes status IN ('planned','waiting'). Ha egy

kikuldetlen kartyat barki in_progress-re allit, a detektor TOBBE nem keresi -- pont az a kartya esik ki, amirol a tabla azt allitja, hogy valaki EPP dolgozik rajta. Ha a kikuldes-nyom hianyzik, az in_progress allitas maga a gyanus.

1. A FRISS ABLAK EGYSZERI ESELYT AD. A created_at >= $LAST szuro a backlog-zaj miatt indokolt

(a regi planned halmazon a nulla uzenet a VART allapot), de ha egy kartya EGY kort atcsuszik, soha tobbe nem kerul a lathatoba. Kell melle egy ritkabb, TELJES halmazos futas (napi egyszer, pl. a 08:00-s korben), es annak a kimenete NE a puszta szam legyen: 2026-08-25-en a teljes halmaz 76 planned + 5 waiting kikuldetlent adott, es ebbol a 76 nagy resze legitim backlog. A lelet a MEGNEVEZETT GAZDAS, FRISS kartya, nem a darabszam.