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 (alapért). 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 vagy a kulcs nincs benne → default level 3 (régi viselkedés).

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:

   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)"
   

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

   curl -s -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban" | python3 -c "
   import json,sys,time
   cut=int(time.time())-7*86400
   for c in json.load(sys.stdin):
    if c.get('status')=='done' and not c.get('archived_at') and (c.get('updated_at') or 0) < cut:
        print(c['id'])
   

" | while read -r id; do curl -s -X POST -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban/$id/archive" >/dev/null done

3. **Beakadt task detection** (előző audit óta nem mozdult): in_progress kártyák amik `updated_at < last_audit_at`:
```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)
")"
curl -s -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban" | python3 -c "
import json,sys,time
last=int('''$LAST''' or 0); now=int(time.time())
rows=[c for c in json.load(sys.stdin)
   if c.get('status')=='in_progress' and not c.get('archived_at') and (c.get('updated_at') or 0) < last]
rows.sort(key=lambda c: c.get('updated_at') or 0)
for c in rows:
 print(c['id'], '|', (c.get('assignee') or '-'), '|', round((now-(c.get('updated_at') or now))/3600.0,1), 'h |', c.get('title'))
"

4. 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:

   python3 -c "import sqlite3
   

for r in sqlite3.connect('{{INSTALL_DIR}}/store/claudeclaw.db').execute(''''''): 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, ez eddig HIANYZOTT az eljarasbol)**: az audit
eddig CSAK az `in_progress` beakadast nezte, a `waiting`-et sosem. Emiatt 12 kartya ult
30+ napja eszrevetlenul, koztuk egy biztonsagi fix (34 nap) es egy kulso embernek jaro
valasz (5 nap ota jovahagyasra varva).
```sql
SELECT id, assignee, date(updated_at,'unixepoch','localtime'), substr(title,1,60)
  FROM kanban_cards
 WHERE archived_at IS NULL AND status='waiting'
   AND updated_at < strftime('%s','now','-30 days')
 ORDER BY updated_at

(Futtatas a fenti python3-sqlite wrapperrel.)

• A puszta szamot NE jelentsd a tulajdonosnak minden korben (az is zajja valna). Akkor szolj, ha a szam NO az elozo audit ota, vagy ha van kozte olyan ami KULSO emberre/biztonsagra vonatkozik.

• DE A NOVEKEDESNEK KET KULON OKA LEHET, ES CSAK AZ EGYIK LELET (2026-08-08, merve). A 16:00-as audit 3-rol 4-re novo szamot mert -- es a negyedik NEM uj problema volt: a cbe2a240 (update-rendszer overhaul) AZNAP lepte at a 30 napot, valtozatlan tartalommal. Ha a puszta szam-novekedesre jelentesz, akkor minden alkalommal riasztasz, amikor egy regi kartya egyszeruen megoregszik -- a jelzes igy a naptartol fugg, nem a valosagtol. ELJARAS: bontsd KET reszre, mielott jelentesz. (a) UJ BELEPO: az elozo audit ota KERULT waiting-be es mar 30+ napos -- ritka, es valodi lelet. (b) ATLEPO: mar waiting-en ult, csak most erte el a 30 napot -- ez a naptar muve, nem valtozas. Jelentes CSAK az (a)-ra, illetve a kulso-ember/biztonsagi kiemelesre; az (b) a transzkriptbe megy, es a helye a kovetkezo prioritas-merlegeles. A megkulonboztetes egy lekerdezes: ha a kartya updated_at-ja REGEBBI mint az elozo last_audit_at, akkor ATLEPO.

  DE A FENTI MONDATBOL EGY OLYAN LEKERDEZES KOVETKEZIK, AMI SOSEM TUD TUZELNI -- ELSULT NALAM (2026-08-19 11:5x, sajat hiba, elkapva a kor kozben). A szoveget ugy olvastam, hogy az UJ BELEPO az, aminek az updated_at-ja az elozo audit UTANI, es ezt irtam: updated_at >= LAST AND updated_at < now-30 days. Ez a ket feltetel egyszerre SOSEM igaz: ami negy oraja frissult, az nem lehet 30 napja allo. A lekerdezes tehat MINDIG nullat ad, es a nulla ugy nez ki, mint egy megnyugtato mereseredmeny. Pontosan az a fajta metrika, amit semmilyen valosag nem tud megcafolni (lasd [[feedback_a_metric_needs_a_refuter]]). A HELYES ATLEPO-LEKERDEZES, masolhatoan:

  -- azok, akik az ELOZO AUDIT OTA leptek at a 30 napos hataron
  SELECT id, assignee, datetime(updated_at,'unixepoch','localtime'), substr(title,1,45)
    FROM kanban_cards
   WHERE archived_at IS NULL AND status='waiting'
     AND updated_at <  strftime('%s','now','-30 days')   -- MA mar 30+ napos
     AND updated_at >= <LAST> - 30*86400;                -- az ELOZO auditkor MEG NEM volt az
  

  Ez 2026-08-19-en ket kartyat adott (E728AE14, E3702858, mindketto 2026-07-20 11:25) -- vagyis a muszer tuzel, amikor van mit talalnia. ES AZ (a) AG A GYAKORLATBAN MAJDNEM URES HALMAZ: ahhoz, hogy egy kartya az elozo audit ota KERULJON waiting-be ES rogton 30+ napos legyen, az kellene, hogy a statusz-valtas NE frissitse az updated_at-ot. Nalunk frissiti. Ezert az (a)-t ne detektorral keresd, hanem a statusz-valtas pillanataban -- a jelentes valodi targya az ATLEPO-lista es a kulso-ember/biztonsagi kiemeles.

• A backlog-metszes GAZDA-DONTES, ne csinald magadtol (lasd a deep-clean buktatot). A te dolgod a lista eloallitasa + a ket kiemelt kategoria megjelolese.

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.

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)
")"

-- 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. 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.

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.
2. 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.

A FELTETEL SZANDEKOSAN BARMILYEN uzenetet elfogad, ami a kartya ID-jet emliti, nem csak a marveen -> gazda iranyt. Ha a gazda MAGA hozta szoba (sajat kartyazas, visszajelzes), akkor tud rola, es a kikuldes celja teljesult. Ne "javitsd" ki kimeno-only szuresre: azzal a sajat maga altal felvett kartya minden korben hamis riasztast adna. DE A 117-ET NE JELENTSD LELETKENT: SZETBONTVA MAST MOND (ugyanaz a meres). planned 110/244, waiting 7/98. A regi planned halmaz BACKLOG -- ott a nulla uzenet a VART allapot, nem mulasztas. Ezert szur a lekerdezes a friss ablakra: a lelet az UJ kartya megnevezett gazdaval, nem a backlog.

5. State-fájl frissítés (a futás VÉGÉN): store/kanban-audit-state.json -> {"last_audit_at": <current Unix timestamp>}.

6. Delegálatlan kártyák: in_progress/waiting/planned amiknek assignee NULL/üres -> log + Telegram csak akkor ha 3+ ilyen van.

6b. ELŐRE-DATÁLT CÍM-BÉLYEG detektor (2026-08-25-én vezetve be, mert a hiba negyedszer fordult elő): a kártyacímbe írt óra BECSÜLT lehet, és hosszú munkamenetben MONOTON NÖVEKVŐ eltérést halmoz (mért eset: 17 kártya, +16 perctől +189 percig). A updated_at hiteles, a címbe másolt idő nem -- ez denormalizálás, és a másolat el tud csúszni.

curl -s -H "Authorization: Bearer $TOKEN" "http://localhost:$PORT/api/kanban" | python3 -c "
import json,sys,datetime,re
# FONTOS: a mintának a 'HH:1x' alakra IS illeszkednie kell, különben néma nulla
pat=re.compile(r'(\d{4}-\d{2}-\d{2})\s+(\d{2}):(\d)[\dxX]')
for c in json.load(sys.stdin):
 if c.get('archived_at') or not c.get('updated_at'): continue
 real=datetime.datetime.fromtimestamp(c['updated_at']); m=pat.search(c.get('title') or '')
 if not m or m.group(1)!=real.strftime('%Y-%m-%d'): continue
 d=(real.replace(hour=int(m.group(2)),minute=int(m.group(3))*10,second=0)-real).total_seconds()/60
 if d>10: print(c['id'],'| cim allit',m.group(0)[-5:],'| valodi',real.strftime('%H:%M'),'| +%d perc'%d)
"

Ha van találat: javítsd a CÍMET a valódi updated_at-re (az updated_at-ot NE mozgasd, ez bélyeg-javítás, nem állapot-változás), és a kör jelentésébe írd bele a darabszámot. A kommenteket NE írd át -- a történet maradjon olvasható, a cím viszont állapot, amiből a heartbeat dolgozik. Kontroll, hogy a nulla ne legyen vak: ha 0 a találat, futtasd le egy ismert pozitívra is (bármely kártya címébe ideiglenesen írt jövőbeli idő), különben a minta-hiba nullának látszik.

7. Telegram csak akkor írj ha:
   • 3+ beakadt task van (kritikus)
   • Új blokker (waiting > 48h)
   • TULAJDONOSRA VÁRÓ KEMÉNY BLOKKOLÓ, státusztól és kortól függetlenül. A fenti két küszöb szűk, mert mindkettő ÁLLAPOTOT vagy KORT néz, a blokkoló viszont lehet friss és lehet planned is. 2026-08-11: egy kártya arról, hogy elfogyott egy szolgáltató előrefizetett kerete és minden hívás 429-cel tér vissza, planned státuszban, 100 perce létezett, tehát SEM a "3+ beakadt", SEM a "waiting > 48h" nem fogta meg. Közben négy szálat állított meg, és csak a tulajdonos tudta feloldani, mert számlázás. A szabály: ha egy kártya (a) kemény megállást ír le, (b) az assignee-je a tulajdonos, vagy a leírása szerint csak ő tudja elvégezni, és (c) nem látszik, hogy szólt volna neki bárki, akkor kimegy Telegramon. A (c) ellenőrzése: nézd meg, kérte-e valaki inter-agent üzenetben a továbbítást, és fusd át a saját kimenő üzeneteidet. Ha kétséges, inkább szólj: a kétszer elmondott blokkoló olcsóbb, mint a négy órát álló flotta.
   • Egyébként csendben (heartbeat-stílus)

Buktatók

• A saját kommentelésed elrejti a kártyát a kor-alapú metrikák elől. Egy komment (és minden kártya-írás) frissíti az updated_at-et, tehát a waiting > 48h lista ÜRESRE válthat attól, hogy az előző körben te magad írtál a kártyára. 2026-08-11, saját mérés: egy kártya 307 órája várt, 12:00-kor kommenteltem rá, és a 16:00-s auditon már 0 volt a waiting > 48h -- nem azért, mert megoldódott, hanem mert én nyúltam hozzá. A hiba iránya megnyugtató, és ettől veszélyes: néma nulla, ami sikernek látszik. Ha "0 blokkolót" mérsz, nézd meg, mozgott-e a kártya az előző audit óta ÉS ki mozgatta:

  python3 -c "
  import sqlite3
  c=sqlite3.connect('store/claudeclaw.db')
  r=c.execute(\"select author from kanban_comments where card_id=? order by created_at desc limit 1\", ('<id>',)).fetchone()
  print(r[0] if r else '(nincs komment)')"
  

  Az updated_at az utolsó ÍRÁS ideje, nem a munka utolsó valódi mozgásáé. A VALÓS kort a created_at-tel vesd össze, ha az updated_at a te írásod. 2026-08-25: egy kártya 162,5 órásnak mérődött, de az updated_at egy héttel korábbi saját kommentem volt; a kártya 14 napja készült. A kétszeres eltérés eldönti, halasztható-e még egy napot, ezért a jelentésben a valós kort mondd, a mérttel együtt. Ebből következik egy tartózkodás is: ne kommentelj a kártyára pusztán azért, hogy rögzítsd, hogy megnézted. Ha csak ellenőriztél, a csatornán jelezd, ne a táblán. Kommentet akkor írj, ha MÉRTÉL valamit, ami a kártyán maradandó.

• NE sqlite3 CLI-t és NE jq-t használj. Egyik sincs telepítve egy átlagos Linux gépen (a telepítő függőségei: ffmpeg, git, tmux, lsof, curl, python3, pipx, unzip), és a hívás ott exit 127-tel elhal -- ez a lépés némán kimarad, miközben az audit sikeresnek látszik. Élő gépen mérve 2026-08-04: két külön Linux telepítésen sqlite3 és jq egyaránt hiányzott, python3 mindkettőn ott volt. A macOS gépeken azért nem tűnt fel, mert ott a sqlite3 gyárilag van.

• A 300 KARAKTERES CIM-KAPUT NE UTKOZD MEG, ES HA MEGIS, NE TOROLD A NYOMAT (2026-08-26, sajat meres a Dream Engine-ben). A kanban_cards_title_gate_* trigger 300 felett levagja a cimet, es a teljes szoveget egy cim-kapu (trigger) kommentbe teszi. Egyetlen esti munkamenetben HETSZER futottam bele (MIOAGENTSZO825, INSTPWURES825 ketszer, INSTROOTDESKTOP825, MACHW825, DIGESTSTALE825, MIOPIN825), es mindannyiszor ugyanaz volt a javitas: ujrairni rovidebbre. AZ ELSODLEGES FIX A SZERKESZTESI SZOKAS, NEM A JAVITAS: a CIM egy sor legyen (lelet + gazda + hatarido), a hosszu leirast pedig ELEVE kommentbe ird, sajat kezuleg. Igy a trigger el sem sul. ES A MERESI CSAPDA, AMI EBBOL A LEGERTEKESEBB: a hetbol MA MAR CSAK KETTO merheto, mert a cim rendbe tetele utan minden alkalommal kitoroltem a trigger sajat kommentjet. A takaritas elmosta azt a jelet, amibol egy kesobbi kor kimerhetne, hogy ez visszatero problema -- a length(title)=300 ujjlenyomat is eltunik, amint a cimet javitod. Ha a trigger elsult, a kommentjet ne torold szo nelkul: vagy hagyd ott, vagy cserelj a helyere EGY sort arrol, hogy mikor es melyik kartyan sult el. AZ ALTALANOS SZABALY: ha egy automatizmus NYOMOT hagy a sajat mukodeserol, azt a nyomot ne toroljuk ugyanabban a korben, amiben a hibat javitjuk -- kulonben minden egyedi javitas utan ugy nez ki, mintha a problema nem letezne. Ugyanaz a csalad, mint amikor a bizonyitek az indexbe kerul es elvakitja a detektort.

• EGY waiting KÁRTYA NEM BIZONYÍTÉK ARRA HOGY A BUG MÉG FENNÁLL -- élő kód, ne kártya-szöveg (2026-07-25, 5F996CBC, saját hiba): a "Dashboard vault-save UI nem nézi a res.ok-ot -> csendes hamis siker" kártya waiting-en ült, én ezt ténynek vettem, blokkolónak eszkaláltam (prioritás high) és MEGKÉRTEM A TULAJDONOST hogy várjon a credential-beírással. A fix valójában egy hónappal korábban bement (af48837 / PR #430, 06-21) és rajta volt a developen; a web/app.js vault-add ágában ott a res.ok-check + hibatoast. A kártyát senki nem zárta le, ezért "élt". ELJÁRÁS mielőtt egy kártyát blokkolóként eszkalálsz vagy a gazdát fékezed vele: (1) git log --oneline --all -S"<a hibás minta>" vagy grep az ÉLŐ fájlban, (2) git branch --contains <fix-sha> hogy a deployolt ágon van-e, (3) csak ezután eszkalálj. Ha kiderül hogy stale: zárd a kártyát ÉS korrigálj a gazdánál kimondva hogy rossz infón fékezted. Ugyanez a családba tartozik mint a PR-kártyák premissza-avasodása (lásd pr-auto-process Buktatók).

• Az "előző audit óta nem mozdult" feltétel azt jelenti: updated_at < last_audit_at. NE használj abszolút 24h-os küszöböt.

• Ne archiválj done-t ha <7 nap (a tulajdonos még látni akarja). KIVÉTEL: explicit "nézd át és tisztítsd" / "tisztítsd a kanbant" tulajdonosi kérésnél archiváld az ÖSSZES done-t (a <7-nap standing default-ot az explicit kérés felülírja, 2026-06-17).

• DEEP-CLEAN ("tisztítsd") extra lépések a sima archive-on túl (2026-06-17): (1) waiting/planned PR-kártyáknál verifikáld a PR tényleges állapotát (gh pr view <n> --json state,mergedAt) -- a MERGED/CLOSED PR-ek kártyái done+archiválandók (pl. #368 merged, #351 closed maradt waiting/planned-en). (2) DEDUP TÉMA-alapon, NEM csak PR-szám-alapon: ugyanarra a munkára gyakran van EGY task-kártya ÉS egy PR-kártya (pl. frontend-tax-validáció task vs aiam #73 PR), vagy két ágens kártyázza ugyanazt (pl. a 015-hardening B6E4CB76 [én] vs 876ec002 [Samu PR] -- a pr-auto-process PR-szám-dedup ezt NEM fogja el). A duplikátumot archiváld, a kanonikus trackert tartsd. (3) NE zárj legit nyitott backlogot (Samu tech-debt/repro queue, roadmap, decision-backlog) -- a deep-clean a done+obsolete+duplikátum, nem a backlog-pruning; azt KÜLÖN, tulajdonos-egyeztetéssel.

• HARMADIK DUPLIKÁTUM-FORMA: két ágens reagál UGYANARRA A FRISS megfigyelésre, perceken belül (2026-07-29, saját hiba): az eddigi dedup-szabály a „téma vs PR-szám" és a „két ágens kártyázza ugyanazt a RÉGI munkát" esetet fedte. A harmadik gyorsabb és alattomosabb: küldtem egy megfigyelést a fejlesztőnek azzal, hogy „vedd fel low-prio kártyára", és KÖZBEN én is felvettem egyet -- két kártya, ugyanaz a munka, percek alatt. A dedup-check itt nem segít, mert a másik kártya a lekérdezés pillanatában még nem létezett. A megelőzés nyelvi, nem lekérdezéses: ha ÉN veszem fel, azt KIMONDOM („felvettem X néven, nincs teendőd") és NEM kérem meg a másikat ugyanarra; ha ő vegye fel, én NEM veszem fel. Ha mégis megtörtént: a VÉGREHAJTÓ kártyája legyen a kanonikus (abból fog dolgozni), a másikat archiváld, az indoklást emeld át kommentként, és mondd ki, kié volt a hiba. UGYANEZ MEGISMÉTLŐDÖTT EGY ÓRÁN BELÜL (2026-07-29, BRIDGENET1) -- tehát nem figyelmetlenség, hanem hiányzó lépés a folyamatban. A második eset pontosan úgy nézett ki, mint az első: a levél végén megkértem a fejlesztőt hogy „vedd fel kártyára", majd ugyanabban a körben magam vettem fel. A MECHANIZMUS, ami megfogja: a kártya-gazdát MIELŐTT az üzenetet megírod döntsd el, ne a végén -- és egyetlen üzenetben SOHA ne szerepeljen egyszerre a „felvettem" és a „vedd fel". Ha egy megfigyelésből kártya lesz, a mondat vagy az egyik, vagy a másik; harmadik lehetőség nincs. Írás után, küldés előtt: grep a saját szövegedre mindkét fordulatra.

  HARMADSZOR IS MEGTÖRTÉNT (2026-08-04, két párban egyszerre: MIGGATE804/UPDMAINTGATE804 és UPDSTASH804/UPDCONFL804) -- és ekkor derült ki, hogy a rés KÉTOLDALÚ. Az előző két eset után a szabály és mellé az ellenőrzés is le volt írva; a hiba mégis megismétlődött, mert a leírt grep-et nem futtattam le. Ugyanabban az üzenetben szerepelt a „nyiss külön kártyát" és -- pár perccel később, ugyanabban a körben -- a saját felvételem. AMI ÚJ, ÉS AMIÉRT NEM ELÉG A SAJÁT OLDALADAT JAVÍTANI: a végrehajtó is nyit kártyát a saját leletére, és ő sem keres rá a meglévőkre. Aznap három kártyát nyitott, egyszer sem futtatott előtte címkeresést. Vagyis a duplikátum akkor is megszületik, ha az ÉN üzenetem tiszta -- a két oldal egymástól függetlenül ugyanarra a leletre kártyáz. A KÉTOLDALÚ MECHANIZMUS, amiben megegyeztünk: (1) nálam a küldés előtti grep a saját szövegre, ténylegesen lefuttatva, nem csak leírva; (2) a végrehajtónál kártyanyitás előtt egy grep a nem-archivált kártyák CÍMÉRE a lelet kulcsszavaival (nem a saját megfogalmazására -- lásd feedback_search_the_concept_not_the_sentence), és találat esetén komment a meglévőre, nem új kártya. RENDEZÉS, ha mégis megtörtént: a VÉGREHAJTÓ kártyája a kanonikus (abból dolgozik), az enyém archiválandó a tartalom átvezetésével -- és a rendezésben mondd ki, melyik oldalon keletkezett a hiba. Itt mindkettőn.

• A DEDUP-CHECK NEM CSAK KÁRTYÁZÁS ELŐTT KELL, HANEM DELEGÁLÁS ELŐTT IS (2026-07-29, saját hiba, drága): a szabály eddig a kártya-létrehozásra vonatkozott. Aznap egy ügyfél-bejelentésből fél napos nyomozást indítottam két ágensnek -- és a végén derült ki, hogy három hete állt egy planned kártya ugyanerről a bugról, ami a fő mechanizmust már leírta, sőt egy kommentjében a másodikat is. A munka nagy része újrafelfedezés volt. A kártya-keresést a munka UTÁN futtattam le, nem előtte. ELJÁRÁS: mielőtt bármilyen felderítést vagy javítást KIADSZ, keress rá a témára a táblán -- ne csak ID-re, hanem tárgyszóra és rendszernévre (title LIKE '%<rendszer>%' OR title LIKE '%<tunet>%'), és nézd meg a planned állapotúakat is, ne csak az aktívakat. Ha van találat, az legyen a kanonikus kártya, és a briefben MONDD MEG az ágensnek, hogy onnan induljon. AMI ILYENKOR MÉGSEM VESZETT KÁRBA, és ezt mondd is ki: a régi kártya tipikusan HIPOTÉZIST rögzít; az új mérés BIZONYÍTÉKKÁ teszi, és gyakran hoz olyan ágat, ami a régiben nincs. A kettő együtt több, mint külön -- de a sorrend fordítva olcsóbb lett volna.

• Kártya-létrehozás ELŐTT dedup-check (a duplikátum-megelőzés): mielőtt task-kártyát hozol létre delegált munkára, nézd meg van-e már kártya ugyanarra (téma + PR-szám), különben dupla keletkezik (mint a 015-hardening fent).

• NE pingelj saját magadat (skip ha assignee a fő-ágens ({{MAIN_AGENT_ID}})). DE A SKIP NEM AZT JELENTI HOGY ÁTUGROD -- ez strukturális vakfolt (2026-07-28, saját eset). A ping-mechanizmus minden ágenst figyel, EGYETLEN kivétellel: engem. Ha a saját kártyám ragad be, nincs aki szóljon, tehát csendben ül tovább, akár hetekig. Konkrét: a connectors.hu MVP kártyám 28 órája állt in_progress-en, holott aznap végig másokon dolgoztunk -- a tábla azt állította, hogy valaki épp csinálja. ELJÁRÁS: a fő-ágens-assignee beakadt kártyáknál a ping helyett MAGAM döntök még ugyanabban a körben -- vagy folytatom (és kommentelem, hogy hol tart), vagy waiting-re állítom az indokkal. A ping kihagyása a helyes; a döntés kihagyása nem. Ugyanaz az elv, mint a delegált-figyelő 5. pontjában: az in_progress azt állítja, hogy valaki EPP dolgozik rajta -- ha nem dolgozik, a tábla hazudik.

• A NULLA-MÉRÉS A LEGGYORSABBAN AVULÓ ÁLLÍTÁS EGY KÁRTYÁN -- és semmi nem szól, amikor elavul (2026-08-04, GOOGLEVERIF1 + A475A648): két kártyánk azt rögzítette, hogy a Google-konnektoron nulla külső bekötés van, illetve hogy a konnektor dormant és a gazda döntésére vár. Mindkettő IGAZ volt a 07-27-i méréskor. A napi connectors-kör kötelező nyitó mérése viszont megmutatta, hogy 08-02 óta egy külső ember aktívan hívja, ma is, Gmail-küldéssel együtt, nulla hibával. Senki nem tévedett; az állítás magától romlott el, mert egyetlen új felhasználó megfordítja, és arról semmilyen jelzés nem érkezik. MIÉRT KÜLÖN OSZTÁLY: egy "sok van belőle" állítás lassan mozdul, egy "nulla van belőle" állítás egy darabbal megdől. És pont a nulla-állításokra épülnek a legerősebb következtetések ("nincs rá kereslet", "nem kell vele foglalkozni", "a gazdára vár"), tehát a legdrágább, ha csendben elavul. ELJÁRÁS: ha egy kártya nulla-mérést rögzít, a szövegbe kerüljön bele a MÉRÉS DÁTUMA és az, hogy MI dönti el újra (melyik lekérdezés, melyik táblán). Amikor egy ilyen kártyához hozzáérsz, a mérést futtasd le újra, ne a szöveget olvasd -- ez pár másodperc, és pont azt a következtetést védi, amire a legtöbbet építjük. Ugyanaz a család, mint a "kártya premisszája megavasodik", csak itt a bukás iránya rögzített: a nulla mindig FELFELÉ tud elmozdulni, és sosem jelez.

• A 30+ napos waiting-lista nem csak adósság, hanem TUDÁS-FORRÁS (2026-07-28): az aznapi audit valódi haszna egy mellékhozam volt. A 3BB2E738 (WSL2-telepítés, „Windows-claude-WSL csapda") 53 napja ült érintetlenül -- és aznap este vált relevánssá, mert a tulajdonos épp a Windows/WSL-ágat kérte. Átadva a fejlesztőnek, megspórolt egy újra-felderítést. Ezért a listát ne csak számként nézd: fusd át a CÍMEKET az aznapi aktív témák szemüvegén, és ha valamelyik egy most futó munkához input, add át annak, aki dolgozik rajta. Az öreg kártya nem feltétlenül halott -- lehet, hogy csak korán érkezett. DE: A TÉMA-KÖZELSÉG NEM INPUT (2026-07-31, ugyanennek a szabálynak a másik éle). A AFBDE2AD (#470 delivery-intent gate, security) 33 napja ült, és aznap a fejlesztő ÉPP kapu-biztonságon dolgozott (#770 Bash auto-approve + egy friss bypass-kártya). Kézenfekvő lett volna „kontextusként" átadni. Nem tettem: az egy másik kapu, rokon család, de nem input a futó körhöz -- és aznap a P0 egy 10:00-s ügyfél-telepítés megfigyelése volt. Adjacens anyagot P0-napon átadni nem szolgáltatás, hanem költség. A KÜLÖNBSÉGTÉTEL: input az, amiből a futó munka MOST merít (ugyanaz a fájl, ugyanaz a kapu, ugyanaz a hibajelenség, egy már megmért adat). Adjacens az, ami ugyanabba a TÉMÁBA esik. Ha bizonytalan vagy: input-e annyira, hogy a másik ember MOST abbahagyná miatta amit csinál? Ha nem, akkor nem input. AMIT ADJACENCIÁNÁL CSINÁLJ HELYETTE: ne a személynek add át, hanem a KÁRTYÁRA írd fel a mintázatot. Aznap ez lett belőle: három nyitott kapu-biztonsági szál egyszerre (33 napos conflicting draft, futó review, friss bypass-lelet), és mindhárom ugyanarról szól -- hogy egy automatikus kapu mit enged át. Ez nem sürgősség-emelés: attól lesz hasznos, hogy a következő prioritás-mérlegelésnél már mintázat áll ott, nem három külön tétel. (Rokon: az „erősítsd a bizonyítékot eszkaláció nélkül" pont lentebb.) ÉS ELŐTTE MÉRD LE AZ ÉLŐ ÁLLAPOTOT: a 33 napos kártyaszöveg helyett gh pr view -- kiderült, hogy a PR időközben CONFLICTING lett. A kártya nem elavult, a helyzet romlott; enélkül „változatlan"-t írtam volna.

  A gh pr view VISZONT NEM MONDJA MEG, HOGY KIMENT-E -- külön mérés kell rá (2026-08-01, 20d70901): a kártya azt állította, hogy három fix „a developen vár, hátra van a release develop->main". A gh pr view mindháromra MERGED-et adott, ami csak annyit jelent, hogy a developre bement -- a kártya állítását ez sem nem igazolja, sem nem cáfolja. A kimenetel-kérdésre EGY parancs válaszol: gh api "repos/<o>/<r>/compare/main...<merge-sha>" -q .status -> behind = a main MÁR tartalmazza (kiment), ahead/diverged = még nem. Mindhárom fix behind volt, 2026-06-29 óta élesben; a kártya release-része tehát hetek óta halott premissza volt, miközben a HOST-VERIFY része valóban nyitva maradt. ELJÁRÁS: ha egy régi kártya „kiadásra vár"-t állít, a merge-állapot NEM elég bizonyíték -- a compare/main...<sha> a mérés. És ha a kártya részben avult el, a címet is javítsd, ne csak a törzset (lásd feedback_merged_is_not_live_for_security_fix).

• EGY RÉGI KOCKÁZAT-KÁRTYÁT MEG LEHET ERŐSÍTENI ANÉLKÜL, HOGY ESZKALÁLNÁD (2026-07-29): a 56dd56bf (fleet-wide Supabase prod-write zárás) 36 napja waiting, és tegnap már helyesen NEM eszkaláltam, mert az élő állapot szerint a technikai zár kész, csak a vault-PAT áthelyezése maradt. A csábítás ilyenkor az, hogy a következő auditban ugyanazt írod le újra ("változatlan"), és a kártya lassan háttérzajjá válik. Amit helyette csinálj: keresd meg, hogy AZNAP történt-e olyan, ami a kártya kockázatát KONKRÉTABBÁ teszi. Aznap három külön feladatban használtam ugyanazt a megosztott MARVEEN-CONNECTORS-PAT-ot, két olyan Supabase-projekten is, aminek semmi köze a napi munkához -- vagyis a "megosztott helyen ül egy teljes DDL/DML jogú Management API kulcs" nem elméleti, hanem NAPI HASZNÁLATÚ kitettség. Ez nem sürgősség-emelés és nem eszkaláció: egy komment, ami a következő prioritás-mérlegelésnél tény lesz, nem érzés. Elv: a waiting státusz megtartása mellett a BIZONYÍTÉK erősödhet -- és épp ez különbözteti meg az élő kockázat-nyilvántartást a temetőtől. DE A BIZONYÍTÉK-ERŐSÍTÉSNEK IS VAN TELÍTÉSI PONTJA (2026-08-04, 5E0A32B0, a 20:00-s audit): a fenti szabály arra bátorít, hogy mérj és kommentelj a régi kártyán. Aznap ezt a 63 napos naptár-auth kártyát a 08:00-s, a 12:00-s ÉS a 16:00-s audit is átmérte, mindhárom kommentelt is rá, és a 20:00-s körben ott volt a késztetés a negyedikre -- ugyanazzal a tartalommal ("a heartbeat naptár-szekciója ma is hibás"). Az ilyen negyedik komment már nem erősíti a bizonyítékot, csak hosszabbá teszi a kártyát, és pont azt a hatást éri el, ami ellen a szabály született: a kártya háttérzajjá válik, csak most a saját kommentjeimtől. ELJÁRÁS: mielőtt bizonyítékot írsz egy régi kártyára, nézd meg a MAI kommentjeit (SELECT date(created_at,'unixepoch','localtime'), substr(content,1,120) FROM kanban_comments WHERE card_id='<id>' ORDER BY created_at DESC LIMIT 3). Ha ma már szerepel ugyanaz a mérés, a helyes lépés a hallgatás. Új komment csak akkor, ha a mérés EREDMÉNYE változott (a tünet eltűnt, súlyosbodott, vagy más okra vezethető vissza), nem akkor, ha csak megint lefuttattad.

• Ne re-pingelj 4 órán belül ugyanazt: a state-fájlban tárolt last_audit_at automatikusan kezeli ezt (a 16:00-os audit nem fogja újra pingelni a 12:00-os állapotút mert az updated_at>=12:00).

• Első futáskor (state-fájl üres) → ne pingelj, csak inicializáld a state-et.

• A státuszváltozás (in_progress -> done) is updated_at frissítést jelent, így a következő audit nem fogja megfogni a most-még-aktív taskokat.

• KOMMENT HOZZÁADÁS NEM frissíti az updated_at-ot (2026-05-23 incident): a kanban_comments insert csak a comment-row created_at-ját állítja, NEM a kanban_cards.updated_at-ot. Ezért ha egy task aktívan kommentes (pl. Samu/Boni delegálási láncolat), DE státusz nem mozdul, akkor false-positive stuck-listára kerül. Megoldás-pattern a query-ben: a stuck-detekciónál vedd az MAX(c.created_at) és cards.updated_at MAXIMUMÁT mint effective_last_activity, és AHHOZ hasonlítsd a last_audit_at-ot:

SELECT k.id, k.title, k.assignee,
  ROUND((strftime('%s','now') - MAX(k.updated_at, COALESCE((SELECT MAX(created_at) FROM kanban_comments WHERE card_id=k.id), 0))) / 3600.0, 1) AS hrs
FROM kanban_cards k
WHERE k.status='in_progress' AND k.archived_at IS NULL
  AND MAX(k.updated_at, COALESCE((SELECT MAX(created_at) FROM kanban_comments WHERE card_id=k.id), 0)) < <LAST>

Vagy alternatíva (gyorsabb): minden ping előtt query-old a komment-count-ot az utolsó audit óta -- ha van, skip a ping-et és manuálisan bump-old a cards.updated_at-ot. Még jobb: a kanban_comments insert ELŐTT/UTÁN trigger-rel auto-bump-old a parent cards.updated_at-ját (storage-szintű megoldás, de schema-change kell).

• changes() KÜLÖN sqlite3-hívásban MINDIG 0 (2026-06-15): ha az UPDATE után sqlite3 ... "SELECT changes()" külön invokációban fut, az egy ÚJ kapcsolat -> 0-t ad akkor is ha az UPDATE sikeres volt (false-negative, "0 sor módosult" látszat). NE erre alapozz. Verifikáld a hatást előtte/utána count-tal (pl. unassigned darabszám 11->5), vagy tedd a SELECT changes();-t UGYANABBA a sqlite3 hívásba az UPDATE után (sqlite3 db "UPDATE ...; SELECT changes();").
• Batch-UPDATE { ... } | sqlite3 szubshell-pipe + loop-épített $SQL string CSENDBEN visszagördülhet (2026-07-20): sok kártya egyszerre zárásakor a for id in ...; do SQL="$SQL UPDATE...;INSERT..."; done; sqlite3 db "$SQL ..." minta némán 0 sort módosított (a záró SELECT lefutott és normál számot adott, de SEMMI nem íródott -- valószínű egy statement a loop-épített stringben elrontotta a parse-t, hibaüzenet nélkül a capture-ben). MEGBÍZHATÓ MINTA: (1) NE { } | sqlite3 szubshell-pipe; (2) az összes statement EGYETLEN sqlite3 db "..." argumentumban, explicit egymás után (ne shell-loopból konkatenálva), pontosvesszővel; (3) UTÁNA verifikáld a hatást count-tal (waiting-darabszám előtte/utána), ne a 0-exitre hagyatkozz. Kis (2-3 statementes) hívások megbízhatóan mennek; a nagy loop-string a rizikós.
• ES A TAGABB SZABALY, AMIT KET KULON ESET EGY ORAN BELUL TANITOTT (2026-08-16): EGY IRAST, AMIT KIADTAL, NEM SZABAD ELVEGZETTNEK TEKINTENI VISSZAOLVASAS NELKUL -- FUGGETLENUL A CSATORNATOL. A fenti pont a batch-sqlite mintarol szol. Aznap ket TOVABBI, egymastol fuggetlen alakban jott elo, es egyik sem batch volt:
  1. KANBAN-STATUSZ: kiadtam egy UPDATE ... SET status='done'-t a PR973-ra; a cim atirodott, az assignee atirodott, a STATUSZ nem. A kartya 45 percig ugy allt, hogy a cime MERGELVE-t mondott, a statusza waiting-et. A sopres fogta meg, nem en.
  2. MEMORIA-API: a curl -X POST /api/memories URES kimenetet adott, en tovabbmentem, es a sor NEM keletkezett meg. A DB-bol visszaolvasva derult ki; ujrakuldve HTTP=200, id megvan. A KOZOS MAG: mindket esetben a parancs LEFUTOTT, hibauzenet nem volt, es a kovetkezo lepesem a sikert felteteleztе. A kulonbseg csak annyi, hogy az egyiket egy kesobbi kor talalta meg, a masikat en, mert VELETLENUL ranezetem. ELJARAS, ket olcso szokas: (a) allapot-valtoztato hivasnal (UPDATE, memoria-POST, uzenet-POST, fajl-iras) MINDIG kerd el a bizonyitekot ugyanabban a korben -- curl -w "HTTP=%{http_code}", a beszuras utan egy SELECT, vagy a fajl visszaolvasasa; (b) ha a kimenet URES ott, ahol valaszt vartal, az NEM siker, hanem MERETLEN allapot. Az ures kimenet a leggyakoribb csendes hiba-alak, mert semmi nem hivja fel ra a figyelmet. ES A JELENTESBEN IS: ne ird le, hogy "elmentve" vagy "atallitva", ha nem olvastad vissza -- a transzkriptben allo hamis kesz-jelentes tobbet art, mint a hianyzo

…(truncated)