kanban-audit

name	kanban-audit
description	4 óránkénti kanban-tábla audit. Tisztítás (7+ napos done archiválás) + beakadt task-ok számon kérése (előző audit óta nem mozdult in_progress -> ping az assignee-nek).

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.

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)
   • Egyébként csendben (heartbeat-stílus)

Buktatók

• 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 -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) vagy az ÉLŐ fájlban, (2) 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 Buktatók).

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 , 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. ne ird le, hogy "elmentve" vagy "atallitva", ha nem olvastad vissza -- a transzkriptben allo hamis kesz-jelentes tobbet art, mint a hianyzo iras, mert megszunteti a gyanut is. Rokon: [[feedback_save_confirmation_must_reread_server_state]].

Ellenőrzés

• A state-fájl frissült a futás végén.
• Inter-agent message-ek sikeresek (200 response).