Megbízott vezérigazgatói átmenet · build status

NRÜ átmeneti tervező

Heti terv, megbeszélések, leirat és elemzés a tízhetes átmenethez. A ledger az authority; ez az oldal abból generálódik.

generated 2026-09-28 05:41 UTC tree 18cbf2a 286 slices from docs/BUILD-LEDGER.md

Overall

78%complete
223 kész, próbával igazolva63 élesben, kézzel igazolva 286 total

Phases

Phase A — a tervező

N1 – N9 · 9 slices

8 kész, próbával igazolva · 1 élesben, kézzel igazolva

Phase B — a felület

N10 – N16 · 7 slices

4 kész, próbával igazolva · 3 élesben, kézzel igazolva

Phase C — éles üzem

N17 – N19 · 3 slices

3 kész, próbával igazolva

Phase D — leirat és elemzés

N20 – N27 · 8 slices

1 kész, próbával igazolva · 7 élesben, kézzel igazolva

Phase E — kontaktok

N28 – N31 · 4 slices

2 kész, próbával igazolva · 2 élesben, kézzel igazolva

Phase F — szerkesztés és átadás

N32 – N40 · 9 slices

8 kész, próbával igazolva · 1 élesben, kézzel igazolva

Phase G — hozzáférés

N41 – N43 · 3 slices

2 kész, próbával igazolva · 1 élesben, kézzel igazolva

Egyéb

N44 – N303 · 243 slices

195 kész, próbával igazolva · 48 élesben, kézzel igazolva

Every module

SliceNameStatusThe ledger’s note
Phase A — a tervező
N1Adatmodell és tároláscompleteHetek, projektek, munkatársak, feladatok, megbeszélések egyetlen JSON dokumentumban. A kezdeti tartalom hivatkozási épségét minden futáskor ellenőrzi a teszt.
N2Megosztott API-rétegcompleteapi.js web-szabványos Request→Response; server.js (fájl) és worker.js (KV) csak adapter. A helyi és az éles változat nem tud elcsúszni.
N3Heti tervcompleteÁllapotváltás kattintással, hét-léptetés, fogd-és-vidd. Az őre a folyamatőr 19. folyamata (npm run folyamat): valódi DragEvent és DataTransfer, ÜRES átvitellel ejtve, hogy a visszaesési út ne menthesse meg a mérést. Külön állítás mondja ki, hogy a dragover elveszi az alapértelmezést — enélkül valódi húzásnál ide nem lehetne ejteni, és minden más állítás zöld maradna. Három szabotázzsal igazolva.
N4ProjektekcompleteFeladatok, megbeszélések és a projekthez rendelt kontaktok egy helyen.
N5Munkatársakcomplete95 kontakt, kereső, kétszintű csoportosítás, ragadós adatlap.
N6MegbeszélésekcompleteNapirend, előkészítő ellenőrzőlista, résztvevők, jegyzetek, döntések.
N7Döntésből feladaton productionEgy gombbal feladat lesz a döntésből, viszi a projektet és a hetet.
N8Mentés és visszatöltéscompleteExport/import kör tesztelve, a nem-gyűjtemény kulcsok (szótár) megmaradnak.
N9Önellenőrzéscompletenpm test — adatépség, CRUD, jelszókapu, sorrend, séma, telefonszám. 2026-08-10: a hét-folytonosság ellenőrzése ezredmásodperc-kivonással készült, és az óraátállítás hetén (25 óra két éjfél közt) hamisan bukott. Naptári napléptetésre cserélve, plusz minden hét hosszát is méri.
Phase B — a felület
N10Teljes magyar nyelvon productionFelület, kezdeti tartalom, súgó, szerverüzenetek. A tárolt állapot- és prioritásértékek szándékosan angolok maradtak.
N11Tipográfiai skálacompleteHárom token (11,5 / 15 / 20 px), a másodlagos szöveget szín, a mikrócímkéket nagybetű különbözteti meg. Az őre a geometriai őr (npm run geometria): a három token értéke, minden tartalék nélküli var() feloldódása, és a kirajzolt betűméretek nevesített halmaza 9 lapon, 4 szélességen. Első futásán talált egy valódi hibát: a --t-small öt helyen hivatkozva, sehol definiálva. Három szabotázzsal igazolva.
N12Mobil elrendezéscompleteiPhone 11 (414 pt) mérve: nincs vízszintes görgés, a táblázat kártyákká alakul, 40 pt koppintás.
N13Fejléc és menüanimációon productionNagybetűs menü, alsó vonal 0,15 mp átmenettel — az event.clinic site mintája.
N14Beállítások, fogaskerékcompleteMentés/visszatöltés, szótár, súgó a főmenüből kivéve.
N15Törlés elrejtésecompleteÖsszecsukott „Veszélyes műveletek"; zárt állapotban nem is kattintható. Az őre a geometriai őr (npm run geometria): a sáv AHOGY ÉRKEZIK csukott, a gombja találatvizsgálattal nem elérhető, nyitva viszont elérhető (pozitív kontroll), és egyetlen button.danger sem áll a sávon kívül. Öt sávot mér négy lapon; kevesebb már lelet. Három szabotázzsal igazolva.
N16Csoportosítás és összecsukáson productionSzervezet → egység, magyar ábécérend, nyilak, ragadós adatlap, görgetés-megőrzés újrarajzoláskor.
Phase C — éles üzem
N17Cloudflare Worker és KVcompleteA felület szövegmodulként a Workerbe fordul, nem statikus eszközként — így a jelszókapu az oldalra is érvényes.
N18JelszókapucompleteSüti HttpOnly + Secure + SameSite=Strict, a jelszót nem tartalmazza. Hamisított süti elutasítva. A Worker jelszó nélkül semmit nem szolgál ki és a tárolóba sem ír.
N19nruceo.event.cliniccompleteEgyéni domain, HTTPS. Telepítés után szórványos Cloudflare 1104 jelentkezhet néhány percig — propagáció, magától elmúlik.
Phase D — leirat és elemzés
N20Böngészős hangfelvételon productionMediaRecorder, biztonságos kapcsolat kell (localhost vagy https).
N21Több hangfájl feltöltésecompleteSorrendhelyes összefűzés, hozzáfűzés sosem felülírás, hibás fájl nem akasztja meg a mögötte lévőket — mind tesztelve.
N22Soniox átiraton productionÉlesben lefutott: két munka completed, 30 806 és 10 498 karakter.
N23Beszélők szétválasztásaon productionJavítva 2026-08-08, azóta nem futott le újra. A régi kód a Soniox sima text mezőjét részesítette előnyben, és eldobta a token szintű beszélőadatot — 41 358 karakter érkezett nulla beszélőjelöléssel. Most a tokenek élveznek elsőbbséget. Egy új felvétel igazolná.
N24Szigorú magyar és szótáron productionTelepítve 2026-08-08, azóta nem futott le újra. language_hints_strict bekapcsolva; a context.terms a valódi kontakt- és projektnevekből épül, plusz a kézi szólista. A felismerés minőségére még nincs mérés.
N25Meglévő leirat beillesztéseon productionBeillesztés vagy szövegfájl (.txt, .md); Word nem olvasható, másolni kell belőle.
N26Claude elemzéson productionLefutott élesben, de 0 döntést és 0 feladatjavaslatot adott (1301 karakteres összefoglaló mellett). A valószínű ok az N23/N24 rossz minőségű leirata, amit azóta javítottunk — újrafuttatás nélkül ez feltételezés, nem tény.
N27Résztvevők felismeréseon productionA séma és a beillesztés kész és telepítve; egyetlen valódi hívás sem futott le rajta. Csak hozzáad, sosem vesz ki, és zárt listából választhat.
Phase E — kontaktok
N28NRÜ névsorcomplete49 fő a hivatalos listából, nyolc szervezeti egység, telefonszám/e-mail/szobaszám. Generálva, nem kézzel gépelve.
N29Külső kontaktokon production46 fő a levelezésből, kilenc külső szervezet. 16 rekordnál csak e-mail-cím ismert — a nevet szándékosan nem vezettük le a címből.
N30Szervezet és projekt szerinti bontáson productionHáromféle csoportosítás; a projektkapcsolat kétirányú (személynél jelölhető, projektnél listázódik).
N31Telefonszám egységesítéscomplete+36 30 335 8792 alak. A mentés útjába építve, tehát új szám is rendbe jön. Tíz eset tesztelve, a 06-os, 0036-os, vezetékes és külföldi alakkal együtt.
Phase F — szerkesztés és átadás
N32Mentetlen módosítás őrzésecompleteGépeléskor a rekord „mentetlen" lesz; továbblépéskor rákérdez, ablakbezáráskor a böngésző kérdez. A jelölés a küldés ELŐTT kerül le, és hiba esetén visszakerül. Mért korlát: a mezők kilépéskor amúgy is mentődnek, ezért a figyelmeztetés ritkán szólal meg — biztonsági háló, nem a mentés fő útja.
N33Mentés gomb csak változáskorcompleteA gomb és a „Mentetlen módosítás" felirat alapból nincs jelen; leütésre jelenik meg, mentés után eltűnik. Böngészőben mérve: mentetlenül hidden=true, gépelés után false.
N34Szervezet és egység elkülönítéseon productionHáttérsáv a csoportfejléceken: a szervezet sötétebb (#e7ebf1), az egység halványabb (#f1f4f8), a nevek fehéren. Bal oldali kiemelő csík.
N35Mobil névsor kártyák nélkülcomplete414 pt-en mérve: a névsor függőleges lista marad (a többi lapé vízszintes csík), a csoportfejlécek ragadósak, a sávok teljes szélességűek, nincs vízszintes görgés, 44/54 pt koppintás. Korábban a szervezet és az egység is külön csempévé vált, és elszakadt a hozzá tartozó nevektől.
N36Projektek a menü végéncompleteSorrend: Heti terv, Munkatársak, Megbeszélés, Átadás-átvétel, Projektek.
N37Több felelős egy feladatoncompleteownerPersonIds tömb; a régi ownerPersonId tükörként megmarad és az elsőt mutatja. A felhozatal minden olvasásnál lefut, tehát a régi mentés és az éles adat is igazodik. A választóban a kattintás kapcsolgat, mert a natív Ctrl-kattintás néma adatvesztés annak, aki nem ismeri.
N38Napirend és döntések soronkéntcompleteEnter új sort nyit, Shift+Enter sortörést; a ✕ töröl, az üresre törölt sor magától kiesik (kivéve, ha feladat tartozik hozzá). A mezők a tartalommal nőnek és zsugorodnak — 33→75 px, illetve a jegyzeteknél 120→558→120 px, valódi nézetablakban mérve.
N39Döntésenkénti felelős és feladatcompleteMinden döntés saját felelőst kap; a belőle készült feladat viszi a felelőst és a megbeszélés projektjét, ezért megjelenik a munkatárs és a projekt feladatai között is. Végigpróbálva.
N40Átadás-átvétel modulcompleteHét fajta tétel (állapot, döntés, kockázat, kapcsolat, folyamat, dokumentum, feljegyzés), „kész az átadásra" jelölés és számláló, mellékletek húzd-és-ejtsd módon. A melléklet tartalma külön tárolóba kerül (KV-kulcs, illetve helyben külön fájl), NEM a db dokumentumba: egyben a KV 25 MB-os kulcsmérete pár melléklet után elfogyna. A tétel törlése a tartalmat is elviszi — teszttel igazolva.
Phase G — hozzáférés
N41Jogosultsági mátrixcompleteauthz.js: 17 kulcs <család>.<levél> alakban, öt szerep. Az event.clinic konvencióit követi, hogy a két rendszer később összeilleszthető legyen. A korlátozás a kiszolgálón él, minden végponton; a felület elrejtése csak kényelem.
N42Személyes adatok maszkolásacompleteA tiltott mező KIMARAD a válaszból, nem nullázódik — a null azt állítaná, nincs adat. Véd: más telefonszáma, e-mailje, szobaszáma, jegyzete; és a megbeszélés leirata, elemzése, jegyzete. A saját adatlapját mindenki teljesen látja. Amit nem lát, azt nem is írhatja felül.
N43E-mailes belépési linkon productionEgyszer használatos, fél óráig élő token, csak hasítva tárolva; aláírt munkamenet-süti szerveroldali lista nélkül. Brevón megy ki, az event.clinic végpontjával és feladójával. Éles hívás még nem futott le rajta: a BREVO_API_KEY nincs beállítva a Workeren (lásd Q8). A token- és aláírás-logika teszttel fedve.
Egyéb
N44Tükrözés az event.clinic adatbázisábacompletedb/001-nru-schema.sql + scripts/sync-to-eventclinic.mjs. Additív nru séma, hat tábla, minden soron raw jsonb a teljes eredeti rekorddal. Egyirányú és idempotens; a forrásból eltűnt sort törli is. 2026-08-28-án ÉLESBEN mérve (ep-lingering-leaf = PROD_OWNER_URL): 12 hét, 8 projekt, 789 fő, 250 feladat, 38 megbeszélés, 25 átadási tétel, 280 futás. A ledger korábban „in progress / DEV adatbázis"-t mondott — az elavult volt, a com.nruceo.mirror óránkénti munka azóta az éles adatbázisba ír. Amit a tükör NEM visz: signals (217) és decisions (155). És a futás a gép ébrenlétén múlik: naponta 11–18 futás a 24 helyett, mert alvó laptopon a launchd nem pótol. 280 futásból 19 elhasalt (13 KV-olvasás, utoljára 08-12; 5 Neon kapcsolatbontás, utoljára 08-26), egy pedig 08-17 óta félbemaradtként áll.
N45Visszaszámlálócompleteinsights.js, tiszta függvények. Hányadik hét, hány nap maradt, mi csúszik, mi akadt el, hány feladat felelős nélkül, hol tart az átadás. A jelzőkre kattintva a heteken átnyúló lista jön.
N46Átadási tételjavaslatokcompleteHat szabály a meglévő adatból: döntés feladat nélkül, egyetlen emberen álló projekt, egy hétnél régebben csúszó feladat, elakadás, három hete csendes projekt, felelős nélküli feladatok. Első futáskor magától megtalálta a ledger Q7-es nyitott kérdését (World Athletics = Fülöp György). Az elutasítás megjegyződik.
N47Átadás exportjacompleteEgyetlen Markdown dokumentum: kész tételek fajta szerint, mellékletek felsorolva, plusz a nyitott feladatok az átadás pillanatában. Javítva: üres tétellistánál idő előtt kilépett, és a nyitott feladatokat sem írta ki.
N48Áttekintő irányítópultcompleteNégy kérdés: mi ég most, mi jön két napon belül, hol áll meg a munka, hol tart az átadás. Ez lett az alapértelmezett nyitólap.
N49Rendezhető feladattáblázat és összesített nézetcompleteMind a nyolc oszlop szerint, oda-vissza; az állapot és a prioritás a saját sorrendje szerint, nem betűrendben. „Minden hét" a hetek listája fölött, ugyanazokkal a szűrőkkel.
N50Névsorrend és megbeszélés-időrendcompleteA titulus („dr.", „Kiss Marianna dr.") már nem sorolja át a nevet — 18 csoportból 3 volt rossz. A megbeszélések időrendben, ragadós hónapfejlécekkel.
N51Hash-váltás és Vissza gombcompleteAz alkalmazás eddig nem reagált a cím megváltozására: a Vissza gomb látszólag nem csinált semmit, és a cím mást mutatott, mint a képernyő.
N52Levélfigyelőcompletescripts/mail-scan.mjs + /api/signals. Javaslatok: feladat, döntés kell, választ várnak, határidő; felelőssel és projekttel. Levéltörzs nem kerül a tárolóba, csak következtetés és hivatkozás — a levelező skill köti ki, és a teszt is ellenőrzi. Ismételt futás nem duplikál és az eldöntött javaslatot nem támasztja fel (szabotázzsal igazolva). Az eredeti jegyzet két állítása MEGDŐLT; 2026-09-06-án újramérve: valódi levélen az N72 óta fut (2026-08-10 óta 325 jelzés keletkezett), és a félóránkénti ütemezés BE VAN TÖLTVE — a com.nruceo.mailscan ma 07:48-kor lefutott, failedAt: null, error: null. A régi mondat a megírása napján igaz volt; azóta fosszília (lásd az N289 zárását).
N53Résztvevői leirat-hozzáféréscompleteA leiratot látja, aki ott volt — de csak azét. Rekordhoz kötve, nem szerephez. Az írási mentesség a TÁROLT rekordból dől el: a beküldött törzsből döntve bárki beírhatná magát résztvevőnek. Az első szabotázs nem bukott el, mert member szerepnél a hatókör már 404-gyel zár; a teszt most a teljes hatókörű szerepet méri, ahol tényleg a maszkoló őr az egyetlen védelem.
N54Éles event.clinic tüköron productionAz nru séma felvive az ÉLES adatbázisra (additív; az app séma 175 táblája érintetlen), az éles adat tükrözve: 93 fő, 44 feladat, 6 megbeszélés. Óránként fut (launchd, betöltve, próbaindítással igazolva). Nem kell hozzá új titok: a KV-t a wrangler bejelentkezése éri el.
N55Feladat-előzménycompleteMi mikor változott: állapot, hét, felelős, prioritás, határidő, projekt. Csak szerkezetes mezők — szabad szöveg egy soha nem törlődő naplóban kezelhetetlen személyes adattá válna. A változatlan mentés nem naplóz. Az átadási dokumentum kiírja, hányszor lett halasztva egy feladat.
N56Felkészítő a megbeszélés eléon productionMúltkori döntés feladat nélkül, a résztvevőknél csúszó munka, a napirenden lévő feladatok, és ki az, akitől nem lesz beszámoló. Minden összetevő megvolt, csak három lapon szétszórva.
N57Levélfigyelés ütemezéseon productionA tulajdonos félóránkéntit kért. Nem tölthető be: nincs ANTHROPIC_API_KEY a gépen, és egy félóránként hibára futó munka csak naplót szemetel. A szkript ezt előre, érthetően megmondja. A kulcs beírása után egy parancs a bekapcsolás.
N58Levélfigyelő beállítójacompletenpm run levelfigyelo-beallitas: végigkérdez, MINDENT ellenőriz futás közben (postaláda, kulcs valódi hívással, Worker-titok, próbafutás), és a végén megmondja, mi sikerült. Az előző változat egy néma cp volt, ami sikeres futáskor semmit nem ír ki — a tulajdonos szempontjából megkülönböztethetetlen attól, hogy nem történt semmi.
N59A figyelő saját kulcsacompleteSCAN_TOKEN: szűk jogú gépi szerep, hogy a háttérfolyamatnak ne kelljen a tulajdonos jelszavát fájlban tartania. Lát: névsor (a feladó párosításához), projektek, feladatok, jelzések. Nem lát: megbeszélés (és benne a leirat), átadási anyag, beállítások, hozzáférés-osztás. Élesben mérve.
N60A teljes adatbázis kapujacompleteÉlesben derült ki, hogy hiányzott: a /api/people 403-at adott a figyelőnek, a /api/db viszont kiadta mind a 93 főt. Két ajtó ugyanabba a szobába, egy zárral. A gyűjteményszintű kapu most a teljes adatbázisra is érvényes; szabotázzsal igazolva.
N61A mailwatch valódi mezőneveicompleteA szkript from/date mezőket olvasott; a valóságban sender_name, sender_email, date_received. Minden hivatkozás üresen jött volna létre — a javaslat ott lenne, de nem lehetne visszakeresni, melyik levélből. Csak valódi adaton derült ki. A has_attachments bekötve: a mellékletek 1. lépcsője kész.
N62Névsor és címtár szétválasztásaon productionA napi névsor 93 fő; a levelezésből begyűjtött címtár 540 cím. Két fül, külön számlálóval; a címtárból egy gombbal emelhető valaki a névsorba. Az elemzés sémája csak a névsorból választhat felelőst — enélkül a modell egy hírlevél-feladóra is kioszthatott volna feladatot.
N63Kontaktok begyűjtése a levelezésbőlon productionscripts/kontakt-gyujtes.mjs: tíz hónap, 915 egyedi feladó, gépi feladók kiszűrve, küszöb legalább két levél. Eredmény: 540 új címtári kontakt, és 2 névtelen rekord kapott nevet (a maradék 12 nem írt ebben az ablakban). Csak FEJLÉCADAT: név, cím, dátum, darabszám. A db 202-ről 363 kB-ra nőtt.
N64Szűk jogú címtár-végpontcompletepeople.import_directory: a figyelő kulcsa bővítheti a címtárat és pótolhatja a hiányzó nevet, de a névsor rekordjaihoz nem érhet hozzá. A végpont az új rekordot MINDIG directory szintre teszi, akkor is, ha a hívó mást kér; kulcsembernek jelölni és telefonszámot írni sem tud rajta. Teszttel fedve.
N65Hozzáférési mátrix képernyőcompleteBeállítások → Hozzáférési mátrix. A kódból generálódik, nem kézzel karbantartott táblázat: egy leírt mátrix néhány hét alatt eltér attól, amit a rendszer csinál, és akkor rosszabb, mintha nem lenne — hamis biztonságot ad. Mutatja a 20 jogosultságot hat szerepre bontva, a hatókört, az elrejtett mezőket, és hogy ma kinek van ténylegesen hozzáférése (jelenleg 0 fő).
N66A tükrözés hibája is naplóba kerülcompleteÉlesben derült ki: a forrás olvasásának hibája eddig SEMMI nyomot nem hagyott, mert a sync_run sor csak akkor keletkezett, ha a szkript eljutott az adatbázisig. A tükör napokig halott lehetett volna, miközben a napló csupa sikeres futást mutat. Most a forráshiba is beíródik, okkal együtt. Szabotázzsal igazolva.
N67Mandátumvég a hetektől különon productionÚjraszámolva: 2026-08-03-tól október 31-ig 90 nap = 12,86 hét. Tizenkét hét hat nappal rövid, tizenhárom egy nappal túlnyúlik — egyik sem esik egybe. Ezért a hetek maradnak kerek tervezési rácsnak (most 13, az utolsó 10-26 – 11-01), a visszaszámlálás viszont a mandateEndDate = 2026-10-31 dátumhoz igazodik. Élesben: 82 nap van hátra.
N68A beállító beragadt a titok feltöltésénélcompleteAz execFile nem ismeri az input opciót (az az execFileSync-é), ezért a wrangler örökre várt a szabványos bemenetre: a képernyőn ott állt a „Beállítom a Workeren…", és semmi nem történt. Kifejezett spawn + stdin lezárás, két perces felső korláttal. A kulcs bevitele mostantól rejtett — az előző változat kiírta a képernyőre, és onnan ki is került.
N69Rejtett kulcsbevitel — harmadik nekifutásracompleteAz első változat visszhangozta a kulcsot; a második, javított változat ROSSZABB lett: readline-t ÉS nyers stdin-figyelőt is ráakasztott ugyanarra a bemenetre, a kettő egymás ellen dolgozott, újrarajzolta a kérdést, és beillesztéskor elvágta a kulcsot — az Anthropic ezért utasította el 401-gyel. Két valódi kulcs került ki emiatt a képernyőre. Most külön modul (scripts/hidden-input.mjs), tiszta nyers mód, egyetlen olvasó, és a nyers mód a kérdés kiírása ELŐTT kapcsol be. Valódi pszeudoterminálon mérve: 109 karakteres kulcs hiánytalanul megérkezik, és egyszer sem jelenik meg a kimenetben.
N70A hetek egy héttel el voltak csúszvaon productionA tulajdonos mobilon azt látta, hogy a lap teteje rossz hetet mutat. Nem a felület hibázott: az 1. hét 2026-08-03-mal indult, ezért augusztus 10-e a 2. hétre esett. Az 1. hét valójában a mai hétfő, 2026-08-10. Eltolva: 12 hét, 2026-08-10 – 2026-11-01, ma az 1. hét, és október 31. a 12. hétbe esik — így a tizenkét hét és az október 31. egyszerre igaz. Ezzel a tegnapi számtan is megoldódott: akkor még két rossz lehetőség közt osztottam (12 hét hat nappal rövid, 13 egy nappal túlnyúlik), pedig a valódi ok az volt, hogy rossz napról számoltam. A tegnap felvett 13. hét törölve, nem volt rajta feladat. 44 feladat, 0 árva hét-hivatkozás. Mentés az eltolás előtt.
N71Titok beírása ellenőrzésselcompletenpm run titok BREVO_API_KEY — rejtett bevitel (a letesztelt nyers módú olvasóval), és a kulcsot VALÓDI hívással ellenőrzi, mielőtt feltöltené. Rossz kulcsnál a Workeren a régi érték marad: nem írunk felül rosszal. Brevo, Anthropic és Soniox kulcsra van ellenőrzés. Az elutasítási út mérve.
N72A levélfigyelő először futott le valódi levélenon production7 nap, 24 szál, 4 javaslat — konkrét, a névsorból helyesen párosított felelősökkel (Molnár Brigitta; Szentmiklósi Bernadett; dr. Molnár Péter és Horváth Viktória). Egynapos ablakon 2 szálból 0 javaslat, ami a kis mintán elfogadható. A jel-zaj arány jónak tűnik: nem áraszt el. Az N26-os „0 döntés" probléma itt NEM ismétlődött meg.
N73Második e-mail-címek egy profilba vonvacompletePOST /api/people/merge: a második cím secondaryEmails bejegyzésként átkerül a megmaradó profilba, a levélszámmal és az utolsó levél dátumával együtt; a projektkapcsolatok egyesülnek, a hiányzó telefonszám pótlódik, a meglévő beosztást viszont NEM írja felül. A kiesőre mutató feladat, résztvevő és döntés-felelős átirányítódik. A belépés a másodlagos címet is elfogadja — enélkül az összevonás csendben elvenné valakitől a bejutást. A secondaryEmails a mezőházirendbe is bekerült: elérhetőségi adat, tehát maszkolt. Élesben: 9 rekord összevonva, 9 cím átemelve, névsor 93, címtár 540 -> 531. Három szabotázs (cím nem kerül át, hivatkozás nem mutat át, belépés csak az elsődlegest nézi) mind a helyes ponton bukik.
N74Az ütemezett levélfigyelő csendben elhasaltcompleteBe volt kapcsolva, és minden futása 127-es kóddal elhasalt 2026-08-10 23:32 óta: a plist a héjjal forrásolta a beállításfájlt (. ./scripts/mail-scan.env), amire az ütemezett munkának nincs joga — „operation not permitted". Egyetlen jelzés sem keletkezett, és semmi nem jelezte. Most a Node olvassa a fájlt (--env-file), egy réteggel kevesebb. Újratöltve, próbaindítással igazolva: 0-s kód.
N75Ugyanaz a szál ne kerüljön a modell elé kétszercompleteFélóránként futva ugyanazok a szálak mennének el újra és újra elemzésre — a beírásnál a kulcs kiszűrné a duplikátumot, de a hívás ára akkor is megvan. A futás most kihagyja azt a szálat, amiről már van jelzés, és ha nem marad új, meg sem hívja a modellt. Mérve: 24 szálból 4 kihagyva.
N76A levélfigyelő élesben íron production6 jelzés keletkezett valódi levelekből, névsorból párosított felelősökkel (Molnár Brigitta, Szentmiklósi Bernadett, dr. Molnár Péter, Csáky Dániel Bálint). Az Áttekintés lapon jelennek meg, jóváhagyásra várva. Megfigyelés: egynapos ablakon 2 szálból 0 javaslat — a napi termés csendes napokon üres lehet.
N77UX-átvizsgálás: érthetőség és elérhetőségon productionMinden lap egy mondatban megmondja, mire való és mi a következő lépés (.lead, sima alcímként — nem dobozban és színes oldalcsík nélkül: az első változatomon egy 3 px-es kiemelő csík volt, ami díszként került rá és jelentést nem hordozott. A jelentést hordozó sávok — sürgős, közeli, nyugodt — maradnak az irányítópulton.) — aki nem akar szoftvert tanulni, annak ez a teljes dokumentáció. Fókuszgyűrű billentyűzetes navigációhoz (:focus-visible, valódi Tab-bal mérve: solid 2px, 2px eltartás) — eddig NEM volt, a Tab-bal haladó vakon kattintott. prefers-reduced-motion tiszteletben tartva. Koppintási felületek 360 px-en: 36 px alatti vezérlő 15-ről 0-ra minden lapon; a listák szövegbeli hivatkozásai betűméret-növelés nélkül kaptak függőleges teret. Vízszintes görgés egy lapon sincs.
N78Mobil fejléc sorrendjecompleteA kilépés és a névkijelzés a CÍM ELÉ került a bal felső sarokba: a fejléc mobilon flex-sorrenddel tördel, az újonnan hozzáadott elemeknek viszont nem adtam order-t, és az alapértelmezett nulla megelőzi a cím 1-esét. Minden fejlécelem kifejezett sorszámot kapott. Képernyőképen vettem észre, nem méréssel — a szám nem mutatta volna.
N79A levéltár frissessége is mérvecomplete2026-08-11: a Mail.app szinkronja megállt, és a figyelő félóránként, zölden, huszonhat órás adaton dolgozott. Nem ő romlott el, hanem a forrása — és egy rendszer, ami csak a saját futását figyeli, ezt sosem veszi észre. Minden futás előtt megnézi a tár korát, és egy óránál régebbi adatnál maga szinkronizál; ha az sem sikerül, kimondja, hogy elavult adaton dolgozik.
N80Levélidők budapesti időbencompleteA levéltár UTC-ben tárol, és a levelező szabályzat ki is mondja, hogy megjelenítéskor át kell váltani — mégis nyersen írtuk ki. Egy 22:45-ös levél 20:45-ként, egy 00:14-es válasz pedig az előző nap 22:14-eként jelent meg: nem csak az óra csúszik, a dátum is. A hat már eltárolt jelzés dátuma is átállítva.
N81Kézilabda VB projekt a levelezésbőlon productionA „kézi VB szerződés – aug 15." szálból: szerződéskötési határidő 2026-08-15; az IHF 2020-ban az MKSZ-nek ítélte a rendezési jogot, és Alapszabálya szerint kizárólag a tagszövetséggel szerződik; az NRÜ társrendezői vagy egyenrangú szerződő féli megjelenítését elutasította, utoljára írásban 2026-03-26-án. Négy feladat felelősökkel, hat résztvevő a projekthez rendelve, és egy átadási tétel az IHF–MKSZ szerződéses helyzetről.
N82Projekt létrehozása a levelezésbőlcompleteTulajdonosi döntés 2026-08-11: a figyelő magától hozhat létre projektet. Szűk végpont (projects.create_from_mail): CSAK létrehozni tud, meglévő projekthez nem nyúl, a típus a három ismert közül való, azonos nevet nem duplikál, és a rekord megjelöli a forrását. A kockázat kimondva: egy félreértett levélből is lesz projekt.
N83Mobil menü és nyomtatáscompleteA menü jobb széle elhalványul, hogy 360 px-en látszódjon: van még elem. Nyomtatási stíluslap a felkészítőhöz és az átadási dokumentumhoz — a keret eltűnik, az összecsukott részek kinyílnak (papíron nincs mit kattintani), a levélcímek kiíródnak a hivatkozások mellé. 17 szabály.
N84Másolatban kapott levelek és a „megtörtént" kategóriaon productionA tulajdonos vette észre a rést: az NRÜ–NSÜ WAUC megállapodás aláírásáról szóló levél átcsúszott a rendszeren. Három ok együtt: a levéltár elavult volt, a levél másolatban jött (a digest csak azt válogatja, ahol VÁRNAK valamit), és egy megtörtént tény a négy kategória egyikébe sem fért bele. Most a másolatban kapott levelek is bekerülnek (24 → 39 szál két napon), és van ötödik kategória: megtortent. Ebből NEM feladat lesz, hanem átadási tétel — pont az ilyesmi vész el, mert „nincs vele teendő". Az első futás azonnal megtalálta az NSÜ-megállapodást és a pirotechnikai tervezet kiküldését.
N85A tükrözés hitelesítése — a hibás diagnózis javításaon productionAz előző átadás azt írta, hogy lejárt a wrangler bejelentkezés, és az első teendő az újra-bejelentkezés. Mérve 2026-08-12: a bejelentkezés ÉL (npx wrangler whoami rendben, marikpeter@gmail.com), a tükrözés mégis óránként elhasal. A napló (/tmp/nruceo-mirror.err) kimondja a valódi okot: „In a non-interactive environment, it's necessary to set a CLOUDFLARE_API_TOKEN". A wrangler felügyelet nélküli futásban egyáltalán nem fogadja el a böngészős bejelentkezést, akármilyen friss — így az újra-bejelentkezés ezen SOHA nem segített volna. Kézzel azért működik, mert ott van terminál. Javítva: a jegyet és az adatbázis-címet a scripts/mirror.env adja, amit a Node olvas (--env-file), nem a héj — ugyanaz a minta, ami az N74-es levélfigyelő-hibát megoldotta, és egyben megszünteti a plistbe ágyazott python-értelmezést is. Beállítás egyetlen paranccsal: npm run tukrozes-beallitas — a jegyet rejtve kéri, valódi KV-olvasással próbára teszi, lefuttat egy teljes tükrözést és a TARTALMÁT nézi (nem a kilépési kódot), majd bekapcsolja az órás futást. A szkript hibaüzenete is javítva: a „nincs jegy a környezetben" és a „lejárt a jegy" két külön eset, és csak az utóbbin segít új hitelesítés. in progress, mert a jegy még nincs meg: a Cloudflare-fiókban a tulajdonosnak kell kiállítania (Account · Workers KV Storage · Read). Lezárva 2026-08-12 03:52: a tulajdonos kiállította a jegyet, és a tükrözés fut. A bizonyíték nem a kilépési kód: a launchctl start-tal kikényszerített, VALÓDI ütemezett futás (terminál nélkül, ahogy óránként is) 703 sort írt át — 12 hét, 6 projekt, 624 névsor-tétel, 51 feladat, 6 megbeszélés, 4 átadási tétel —, a hibanapló pedig egyetlen bájttal sem nőtt. A launchctl list 0-ja önmagában nem lett volna elég: betöltés után az érték nullázódik, tehát a „be van kapcsolva" és a „le is fut" két külön állítás (lásd N74).
N86Levélellenőrzés kora a fejlécbenon productionA tulajdonos kérése: a nyitólapon látszódjon, mikor néztük utoljára a leveleket — relatív időben, mert az abszolút időpontból fejben kell kivonni. „10 perce", „fél órája", „3 órája", „egy napja", „egy hete". Közben kiderült egy csendes hiba: a figyelő if (!signals.length) return-nel kilépett, tehát egy csendes napon MEG SEM SZÓLALT — a kijelző emiatt huszonnégy órás hallgatást mutatott volna ott, ahol félóránként rendben lefutott az ellenőrzés. Most minden futás jelent, a termésétől függetlenül (/api/mail-status). Két időpont látszik, mert kettő tud elromlani: mikor ellenőriztünk, és meddig tart maga a levéltár — a 2026-08-11-i eset (zöld futás huszonhat órás adaton) pontosan a második volt. 90 perc után sárga, 4 óra után piros. A relatív idő két példányban él (felület + insights.js), és az önellenőrzés a két kimenetet hasonlítja össze 23 időtávon, hogy ne csúszhassanak szét.
N87Igazgatói nézet — az NRÜ vezetés portáljacompleteTulajdonosi döntés 2026-08-12. Új szerep (board), amely nem kicsinyített supervisor, hanem más hatókör: a láthatóságot nem a szerep, hanem a rekord visibility mezője dönti el. Látja: a projekteket, a vezetőinek jelölt megbeszéléseket (napirend, döntések, feladatok, AI-összefoglaló), a vezetésre nyitott feladatokat és a névsor neveit. Nem látja: a tulajdonos heti tervét és saját feladatait, a levelezésből jövő jelzéseket, az átadási anyagot, a telefonszámokat és e-mail-címeket, a postaláda állapotát, és a szó szerinti leiratot soha — akkor sem, ha ő maga ott ült az ülésen. Ez utóbbi külön gépezetet igényelt (neverSee), mert a Q11-es résztvevői mentesség különben kiadta volna; a mérés kapta el, hogy a tulajdonos saját ülésjegyzetét is így szivárogtatta. Dolgozhat is: feladatot hozhat létre és oszthat ki (tulajdonosi döntés). Pénzügyi mező az adatmodellben nincs, tehát nincs mit elrejteni — ha lesz, a mezőházirendbe kell kerülnie. Szabotázzsal ellenőrizve: a feladatszűrő és a leirat-tilalom kiiktatása mindkettő megbuktatja az önellenőrzést.
N88Teljesítési jegyzet, láthatóság és a folytatáson productionA feladat lezárásakor rögzíthető, milyen körülmények között teljesült, saját láthatósággal — a jegyzet szűkebb körű lehet, mint maga a feladat. A jegyzet HOZZÁFŰZŐDIK, nem felülír: egy későbbi újranyitás sem teszi meg nem történtté. Üres jegyzet nem keletkeztet bejegyzést. Lezárás után a rendszer felajánlja a következő feladat létrehozását és delegálását, a forrás megnevezésével a leírásban — ez az a pillanat, amikor még megvan a fejben. Az „NRÜ vezetés" köre egy pipálható táblán áll (Beállítások → NRÜ vezetés), és a pipa nem ad belépést: a tagság azt mondja meg, mit LÁTNA az illető, a belépéshez a mátrixban kell szerepet adni. A kettő szétválasztása ugyanaz az elv, ami a névsor-szerkesztést és a jogosztást elválasztja.
N89Két állandó heti megbeszéléson productionTulajdonosi döntés 2026-08-12: kedd 10:00–11:30 NRÜ–NKOH tulajdonosi státusz (NKOH, Sas utca, 107-es tárgyaló) és csütörtök 11:00–12:00 NRÜ belső vezetői értekezlet. A mandátum végéig felvéve: 11 keddi és 12 csütörtöki alkalom, napirendi kerettel. A csütörtöki a vezetésnek látható és a nyolcfős kör a résztvevője; a keddi a tulajdonosé marad (az NKOH-oldal résztvevőit a tulajdonos tölti fel). A generálás idempotens (sorozat + dátum kulcs), és naptári napokat léptet, nem ezredmásodpercet — az óraátállítás hete 25 órás. Élesben a KV-n át ment, mert a jelszó nem volt kéznél; a sorozat definíciója viszont egyetlen helyen áll, a két szállítási út ugyanazt olvassa. Visszaolvasva ellenőrizve: mind a 11 kedd kedd, mind a 12 csütörtök csütörtök.
N90Belső margók átvizsgálásacompleteA tulajdonos jelezte, hogy bizonyos ablakszélességnél a szöveg a mező keretének feszül. Nem szemre javítva: egy szkript minden mezőt végigmért négy szélességen (375, 726, 860, 1100), és a találatokat gyökérokra vezettem vissza. Három valódi hiba. (1) A .row nem tördelt: három mező egy sorban 87 px-re préselődött, és a leghosszabb érték nekiment a keretnek — a mobil nézet 720 px alatt oszlopba rendez, de a kettő közötti sávban semmi nem védte őket. Most tördel, 180 px-es alsó határral. (2) Minden növekvő szövegmező két pixellel rövidebb volt a kelleténél: a magasság a scrollHeight-ból jött, border-box méretezésnél viszont abba a keret is beleszámít — az utolsó sor mindenhol a keretnek feszült. (3) A választólista hosszú neve és e-mail-címe kilógott a dobozból; most hármasponttal zárul. Végállapot: 375, 726, 860 és 1100 px-en nulla találat, vízszintes görgés sehol.
N91Csevegőablak a rendszer tartalmárólcompleteKérdés-válasz a teljes tartalomból: projektek, feladatok, névsor, megbeszélések, döntések, leiratok, átadási anyag és a levélfigyelő jelzései. A korpusz a MASZKOLT adatból épül (projectDb), nem a nyersből — ez a chat legfontosabb tulajdonsága: második ajtó ugyanabba a szobába, és a szivárgás itt nem 403-ként jelentkezne, hanem egy udvarias magyar mondatban, amit senki nem néz jogosultsági hibának. Szabotázzsal igazolva: nyers adatra állítva az önellenőrzés megbukik. Diktálás a böngésző beszédfelismerésével (magyar); ahol nincs, a gomb meg sem jelenik. A leiratok költségkerettel mennek be (60 e karakter), és ami kimaradt, azt a korpusz kimondja, hogy a modell ne állítsa magabiztosan a nemlétezőt. Prompt-gyorsítótár: a második kérdéstől 11 066 token onnan jön. Élesben lefutott: a felelős nélküli feladatokra 9 tételt sorolt fel — az adatból függetlenül ellenőrizve pontosan 9 ilyen van. Ismeretlen kérdésre kimondja, hogy nincs rá adat.
N92Leirat 600 pixeles alapmagassággalcompleteEgy negyvenperces ülés leirata több képernyőnyi volt, és a mező alatti minden vezérlő elérhetetlen messzeségbe került. Alapból 600 px, belül görgetve; egy chevronnal kinyitható, és kinyitva a teljes szöveg látszik, belső görgetés nélkül — ez a kinyitás egyetlen értelme. Megbeszélésenként külön emlékszik a nyitott állapotra. Mérve: zárva 600 px belső görgetéssel, nyitva 16 812 px görgetés nélkül.
N93A megbeszéléslista az aktuális hétnél nyílikcompleteA lista a mandátum elejétől tart, tehát júliussal nyílt — azzal viszont ma már senki nem kezdi a napját. Most az aktuális hét áll a lista tetején, a korábbi hetek megmaradnak, egy görgetésnyire fölötte. Ehhez a listának saját görgetősáv kellett: desktopon a max-height csak mobilra volt beállítva, ezért a lap görgött, és nem volt mit feljebb görgetni. A hét hétfőtől számolódik, naptári napokkal. A fejléc 1024 px alatt két sorba tördel, mert hét menüponttal a Projektek és a Kérdezz menüpont kicsúszott — képernyőképen vettem észre, a szám nem mutatta. A ragadós oldalsávok magassága innentől egy változóból jön, nem beégetett 64 px-ből.
N94Az önellenőrzés foglalt porton mást mértcompleteAz önellenőrzés fix portokon (4748–4750) indít kiszolgálókat. Amikor a 4748-on egy kézzel indított példány futott, a gyerekfolyamat nem tudott kötni, a teszt viszont ugyanazon a címen kérdezett — és az én munkaadataimról állított dolgokat, zölden. Egyetlen állítás bukott el véletlenül, az árulta el. Most a futás elején ellenőrzi, hogy a portok szabadok-e, és ha nem, kimondja, miért nem szabad hinni az eredménynek. Igazolva: foglalt porton a teszt megáll a magyarázattal, felszabadítva zölden fut.
N95Megbeszélés-javaslat a levelekbőlon productionA tulajdonos kérése: az e-mailekből javasoljunk naptárbejegyzést, és kérdezzünk rá, mielőtt létrejön. A figyelő kapott egy hatodik jelzéstípust (megbeszeles): akkor javasol, ha a levélből kiderül a NAP — a „egyeztessünk valamikor" szándékosan nem elég. A javaslat viszi az időpontot, a hosszt és a helyszínt. Az Áttekintés lapon külön panelen jelenik meg, a jóváhagyó ablak pedig kiírja a javasolt időpontot, mielőtt bármi létrejönne — egy rossz nap csendben bekerülve rosszabb, mint a hiánya. Óra nélküli dátumnál 9:00-cal nyit, üres időpontnál nem talál ki napot. A jóváhagyás végigmérve: javaslatból megbeszélés lett helyes időponttal, helyszínnel és forrásmegjelöléssel, a jelzés accepted lett. in progress, mert valódi levélen még egyszer sem sült el: hét nap postaládáján a modell 8 javaslatot adott, ebből nulla megbeszeles-t. A meghívók jellemzően mellékletben hozzák az időpontot, a melléklet viszont nincs letöltve a tárba (Q14).
N96A levéltár szinkronja ütemezetten sosem futott lecompleteA tulajdonos Outlook-hibája nyomán mérve: a levéltár 21,9 órás volt, és a figyelő félóránként pontosan kimondta, hogy elavult adaton dolgozik — az N79-es őr tehát működik. Az ok viszont új: a mailwatch sync kézzel lefuttatva sikerül (86 új levél érkezett be azonnal), ütemezetten mindig elhasal. A ~/Library/Mail a macOS Teljes lemezhozzáférés (TCC) védelme alatt áll; az interaktív héj megkapta, a launchd-munka nem. Ebből következik, hogy a figyelő önjavító szinkronja soha nem futott le sikeresen, csak a hibát mondta ki hűségesen. Megoldva 2026-08-12: a tulajdonos megadta a /opt/homebrew/bin/node számára a Teljes lemezhozzáférést. Nem a kilépési kóddal igazolva: egy eldobható launchd-munka futtatta le ugyanazt a szinkront ütemezett környezetből, és sikerült — ugyanaz a parancs, ami előtte mindig bukott.
N97Duplikáció-védelem és összevonás importáláskorcompleteTulajdonosi kérés: a levélből érkező megbeszélés ne hozzon létre másodpéldányt. A jóváhagyás előtt ütközésvizsgálat fut — a kiszolgálón, egy példányban, mert a felületen megismételve néhány hét alatt szétcsúszna a kettő, és a védelem pont ott hiányozna, ahol kell. A párosítás szó szintű: ékezet le, a szervezési zajszavak (meghívó, egyeztetés, RE, FW, Teams) kiesnek, a maradékon Dice-együttható; ehhez jön az azonos NAP és a ±120 perc. Ezért a jövő heti azonos című ülés NEM duplikátum — az a sorozat következő alkalma —, az „Meghívó: NRÜ belső vezetői értekezlet" viszont 100%-os egyezés. Találat esetén összevonó ablak nyílik: mit tud a rendszer, mit hozott a levél, és a levélből érkező résztvevők egyesével, pipálva. A már bent lévők nem jelennek meg (zaj volna), a meglévő cím és időpont nem íródik felül, üres helyszín viszont kitölthető, és a napirendbe bekerül, melyik levélből egyesítettünk. Végigmérve: a bepipált ember bekerült, a kihagyott nem, duplikátum nem keletkezett, a jelzés accepted lett. Szabotázzsal ellenőrizve a napkorlát és a láthatósági szűrés is: az igazgatói nézetből a nem látható ülés címe ütközésként sem szivárog ki.
N98Mezők csak akkor, amikor van értelmükon productionTulajdonosi kérés: az ablakok alsóbb részén álló mezők akkor jelenjenek meg, amikor a korábbi válaszok ezt indokolják. A feladatablakban a láthatóság mező eltűnik, amíg az „NRÜ vezetés" köre üres — addig a választás semmit nem befolyásol, csak egy kérdéssel több minden mentésnél. A napirendre tűzés eltűnik, ha nincs mire feltűzni: egy üres legördülő azt sugallja, hogy valamit rosszul csinálunk. A ritkán használt címke és napirend egy összecsukott „További beállítások" alá került — de az ÉRTÉK kiül a felirat mellé („További beállítások — jogi, kockázat"), tehát semmit nem rejtünk el, csak a szerkesztéséhez kell egy kattintás. Nyitva hagyva a meglévő címkék miatt a rész gyakorlatilag sosem lett volna összecsukva. A megbeszélés-panelen ugyanez a szabály a láthatóságra. Mérve: új feladatnál 15 mezőből 11 látszik.
N99Mobil alsó menüsáv, keskenyebb felső menücompleteA felső menü 1280 px-en a fejléc 54%-át foglalta (691 px). A nagybetűs, ritkított szedés volt a fő ok — kisbetűsre váltva, a réseket szűkítve és az „Átadás-átvétel" rövidítésével 477 px (37%) lett, olvashatóbban. Mobilon a navigáció az ablak aljára költözött, a natív alkalmazások mintájára: öt hely (Áttekintés, Heti terv, Megbeszélés, Kérdezz, Több), 48 px-es koppintási felülettel, hüvelykujjal elérhető helyen; a többi lap és a kilépés a „Több" rétegben. A felső menücsík és a hozzá tartozó elhalványuló görgetőmaszk törölve. A fejléc ezzel 126 → 57 px lett: 69 px vissza a képernyő tetejéből. Négy hiba a mérésből: az általános nav szabály beszivárgott a sávba (14 px margó + 16 px rések, 64 px-et elvéve az öt gomb elől), a rugalmas térköz kiszorította a levélállapotot, a belső görgetődobozok nem tudtak a sávról (a törlés gomb 53 px-re a sáv alatt maradt), a csevegő Küldés gombja pedig alácsúszott — ez utóbbi most méréssel áll be, nem képlettel, mert a panel fölötti bevezető magassága a szélességtől függ.
N100Előnézet más szemévelon production„Mit látna X, ha most belépne?" — levélküldés és jogosztás nélkül. Beállítások → Előnézet más szemével: ki, és milyen szerepben. A szerepet külön lehet választani, mert a kollégának még nincs hozzáférése: így megnézhető, mit KAPNA, mielőtt megkapja. Egyetlen GET végpont (/api/preview), supervisor-kapuval; a válasz a kész munkamenettel vetített adat, tehát ugyanaz a réteg dönt, mint éles belépéskor. Előnézet alatt a rendszer semmit nem ír: a hívóréteg minden nem-GET kérést elutasít, hogy a tulajdonos véletlenül se módosítson más nevében. Feltűnő sáv jelzi az állapotot — egy csendes előnézet veszélyes volna, mert hiányzó adatra lehetne belőle következtetni. Miért kell egyáltalán: a hozzáférési mátrix ELMÉLET, a tényleges láthatóságot rekordmezők is befolyásolják (visibility), és a kettő eltérhet anélkül, hogy bárki észrevenné. Az első futás azonnal talált is egy hibát: az igazgatói nézetben megjelentek a felvételi gombok és a láthatóság-választó, pedig az a szerep nem szerkeszthet megbeszélést — kapuzva.
N101Nyitólap masonry, és két mobilhiba a mérésbőlcompleteA tulajdonos jelezte, hogy az irányítópulton rés tátong a második sorban álló doboz fölött: rácsnál a sor magasságát a legmagasabb doboz adja. Oszlopos elrendezésre váltva minden panel közvetlenül az előző alá kerül (ára: az olvasási sorrend oszloponként fentről le — a masonry szokásos cseréje). Mérve: két oszlop, 20 px-nél nagyobb rés nincs. Két hibát is a képernyőképek hoztak elő, mindkettőt én okoztam a margó-javításnál (N90): (1) a .row > * { flex: 1 1 180px } mobilon, oszlopirányban a MAGASSÁGRA vonatkozik — minden mező 180 px magas lett, a projektlap tele üres résekkel; (2) a megbeszéléslistán a ragadós hónapfejléc pont az aktuális hétre ugró sort takarta, tehát a címe eltűnt, és csak a dátuma látszott. Mindkettő javítva és visszamérve.
N102Új megbeszélés MOST kezd, és mobilon meg is nyílikon productionKét tulajdonosi jelzés. (1) Az új megbeszélés a hét első napjának 9:00-ját kapta: az 1. hétnél ez két nappal a múltban volt, tehát minden új megbeszélés visszamenőleges időponttal született. Most az aktuális idő, a következő negyed órára felfelé kerekítve — a felfelé kerekítés az, ami garantálja, hogy soha ne kerüljön a múltba. Helyi idő szerint képezve, mert a datetime-local mező is abban gondolkodik; UTC-ből nyáron két órát csúszna. Mérve: 14:38-kor 14:45 lett, szerkeszthetően. (2) Mobilon a megbeszélésre koppintva nem jött elő az adatlap. Oka a N93-as ragadós lista: két hasábnál hasznos, egy hasábnál viszont a képernyő tetejére tapadt 487 px magasan, és az alatta kezdődő adatlap (710 px-nél) soha nem tudott feljönni. Mobilon a ragadás feloldva, és a választás navigációként viselkedik: koppintás után a lap magától az adatlaphoz görget. Ugyanez az új megbeszélés létrehozásakor is.
N103Geometriai őr: a felület mérésecompleteA felületet eddig semmi nem védte: a kiszolgálón 200+ állítás fut, a felületen nulla — és a 2026-08-12-i három elrendezési hibából kettőt épp egy korábbi javítás okozott. npm run geometria valódi Chrome-mal mér, négy szélességen és nyolc lapon: elérhetetlen vezérlő, levágott szöveg, aránytalanul magas mező, takart adatlap, kilógó menüpont, vízszintes görgés. Függőség nélkül — a gépen lévő Chrome-ot vezérli a fejlesztői protokollon, a Node beépített WebSocketjével; Playwright behúzása egyetlen HTML-fájlhoz aránytalan volna. Nem képet hasonlít, hanem SZÁMOKAT mér: egy képösszevetés minden szövegváltozásra elbukna, és egy hónap alatt kikapcsolnánk. Az őrt szabotázzsal ellenőriztem, és az első változata mind a három motiváló hibát átengedte — díszlet lett volna. Három ok: a 180 px a .field dobozon volt, nem az inputon; a takarást csak találatvizsgálat (elementFromPoint) mutatja meg, koordináták nem; és a friss adatbázis hat megbeszélésével a ragadós elrendezés hibái meg sem jelennek. Mindhárom javítva, most mind a hármat elkapja. Van saját portőre és határideje is: foglalt porton a MÁSIK rendszert mérné, beragadva pedig se nem zöld, se nem piros.
N104Amit az őr azonnal találtcompleteKét valódi hiba, még mielőtt bárkihez eljutott volna. (1) A --headh változó 12 pixelt hazudott asztali nézetben (64 px a mért 52 helyett), tehát a ragadós oldalsávok ennyivel lejjebb kezdődtek a kelleténél. (2) Élethű mennyiségű megbeszélésnél a lista nekifeszül a görgetési határnak, és az aktuális heti sor mégis a ragadós hónapfejléc alá kerül — a kiszámolt eltolás nem az, ami megvalósul. A görgetés most ellenőrzi magát: ha takarva van, visszaenged annyit, amennyi kell. A saját adataimon ez nulla pixelen múlott, tehát szemmel sosem vettem volna észre.
N105Éjszakai átvizsgálás és négy javításon productionTeljes ellenőrzés 2026-08-12 este: önellenőrzés zöld, geometriai őr zöld mind a nyolc lapon és négy szélességen, éles példány 401-gyel zár, mind a hat titok megvan, mindkét ütemezett munka 0-val fut — és a kilépési kód helyett a TARTALMUKAT is megnéztem. Négy javítás. (1) A wrangler nem volt rögzítve, tehát az órás tükrözés minden futáskor a legfrissebb kiadást töltötte le: ma 14:28-kor egy hibás függőség (miniflare@…-alpha) miatt elhasalt. Rögzítve 4.121.0-ra, így egy idegen kiadás nem tudja eltörni. (2) A nyitólapon az „Átadás-átvétel" doboz ugyanazokat a tételeket ismételte, amiket a „Hol áll meg a munka" — az egyetlen emberen álló projektek mindkét listából jöttek. (3) A heti terv bevezetője asztali elrendezésre hivatkozott („bal oldalt… jobb oldalt"), mobilon értelmetlenül. (4) A négy szűrő egy telefonon teljes képernyőt foglalt a lista előtt: összecsukható lett, de a felirat kiírja, mi van beállítva — összecsukott szűrőnél különben a felhasználó hiányzó feladatokat lát és nem érti, miért.
N106A levélfigyelő megbeszélés-javaslata élesbenon productionÉlesben elsült, öt javaslattal valódi levelekből (TKM Operatív Törzs, atlétikai sajtótájékoztató, World Athletics sajtóesemény, Event Tech Live). Ez az N95 nyitott kérdése volt. Mérve viszont egy minőségi rés is: öt javaslatból háromnál a modell ÜRESEN hagyta az időpontot, pedig a levélben ott volt a nap. Nap nélkül a javaslat nem naptárbejegyzés: elfogadva időpont nélküli megbeszélés lenne belőle, ami rosszabb, mint egy tiszta feladat. A prompt most kimondja, hogy nap nélkül a feladat típust kell választani, és a szkript ki is kényszeríti — az ígéret önmagában nem elég. Hat mintán mérve az ellenőrzés (üres, hiányos, magyar szöveges dátum elutasítva; ISO nap és nap+óra elfogadva).
N107A megbeszélés-elemzés bizonyítvaon productionAz N26 hónapok óta nyitott kérdés volt: a Claude-elemzés élesben 0 döntést és 0 feladatot adott, és a feltételezés az volt, hogy a rossz minőségű Soniox-leirat az ok. Ma beillesztett, tiszta magyar leirattal lefuttatva: 4 döntés, 4 feladat helyes felelősökkel, projekttel, héttel és prioritással, valamint egy pontos összefoglaló. A feltételezés tehát igaznak bizonyult: a lánc működik, a hibát a leirat minősége okozta. A magam hibáját is rögzítem: kétszer „0 döntés"-ként olvastam a saját mérésemet, mert angol kulcsokat kerestem (summary, decisions) egy magyar kulcsú sémában (osszefoglalo, dontesek). A mérőeszköz hibája ugyanúgy hamis eredmény, mint a rendszeré. Nyitva marad: ez beillesztett leiraton igazolt, nem Soniox-felvételen — az N23 és N24 továbbra is egy valódi felvételt vár.
N108Résztvevő-felismerés bizonyítvaon productionAz N27 „egyetlen valódi hívás sem futott le rajta" állapotból kikerült. Mérve: egyetlen beállított résztvevővel indítva a leiratból három további embert ismert fel helyesen (dr. Varjas Attila, Horváth Viktória, dr. Fullajtár-Németh Kinga), a meglévőt nem vette ki, és nem talált ki senkit — a séma zárt névsorból választhat.
N109A feldolgozás alatti átirat örökre az maradtcompleteA tulajdonos jelezte: egy tegnap esti felvétel reggel is „feldolgozás alatt" állt. Az ok nem a Sonioxnál volt. A lekérdezés kizárólag közvetlenül a feltöltés után indult el, abban az egy böngészőfülben — ha a fül bezárult vagy a gép elaludt, soha többé senki nem kérdezte meg, elkészült-e. A felvétel ott állhat készen a szolgáltatónál, a tervezőben pedig örökre processing marad. Mérve: 14 óra után is. Javítva két úton: a megbeszélés MEGNYITÁSAKOR magától elindul a lekérdezés (őrrel, hogy az újrarajzolás ne indítson újat), és van kézi „Állapot lekérdezése most" gomb is, ha az automatika bármiért nem futna. Ez ugyanaz a hibaforma, ami ebben a projektben visszatér: nem hibázik semmi, csak senki nem kérdez rá.
N110Négy elemzés lefuttatva valódi felvételekenon productionA tulajdonos négy hangfelvételt töltött fel. Eredmény: Hajduvári 7 döntés / 11 feladat, Lalák 6 / 12, Vezetői 13 / 24, WAUC 9 / 27 — összesen 35 döntés és 74 feladatjavaslat, valódi felelősökhöz rendelve. A beszélők szétválasztása (N23) is igazolva: 285, 188 és 122 beszélőváltás, 2–3 külön beszélővel. Egy korábbi magyarázatom megdőlt: azt írtam, hogy a régi felvételek 0 döntése a hiányzó beszélőjelölésből fakadt — a WAUC és a Vezetői leirata VÁLTOZATLAN, beszélőjelölés nélküli, mégis 9 és 13 döntést adott újrafuttatva. A hibát tehát nem a leirat okozta, hanem valami az elemzési úton, ami azóta javult. Ezt nem tudom pontosabban megmondani, és nem is állítom, hogy tudom.
N111A „Vezetői" leirata visszaállítvacompleteAz augusztus 6-i megbeszélés leiratmezője üres volt, pedig a két feltöltés completed, és a szövegük (30 806 + 10 498 karakter) végig ott volt a rekordban. A tulajdonos nem törölte. Mindkét munka „hozzáfűzve" jelöléssel állt, tehát magától soha nem került volna vissza. Visszaállítva a rendszer SAJÁT összefűző függvényével (appendCompleted), nem kézzel újraírt logikával: 41 358 karakter, pontosan az a szám, amit a ledger a javítás előtti felvételnél rögzített. Hogy eredetileg mi ürítette ki a mezőt, nem derült ki — a appended: true jelölés miatt a törlés a hozzáfűzés UTÁN történt.
N112Élő frissítés: a lap magától követi a változástcompleteA tulajdonos kérése: a felület kövesse a háttérben történő változásokat, távolról is — telefonon, másik gépen, több felhasználónál. Minden írás növeli a db.rev számlálót (egyetlen helyen, a save() függvényben, amin mind a 19 írási hely átmegy), és a felület 25 másodpercenként lekérdezi a 44 bájtos /api/version végpontot. Az egész adatbázist letölteni ehhez pazarlás volna, mobilon adatforgalom is. Nem oldalt tölt újra, csak adatot: az újratöltés elvinné a görgetést, a nyitott lapot és a félig beírt szöveget. Nem frissít, ha a felhasználó dolgozik — mentetlen mező, nyitott ablak, beviteli fókusz vagy előnézet esetén kihagyja, és a jelzőt sem lépteti, tehát a következő körben újra próbálja. Háttérfülben nem hálózatozik (document.hidden), viszont visszaváltáskor és képernyő-visszakapcsoláskor azonnal kérdez. Mérve: két távoli írás megjelent oldalfrissítés nélkül (41 → 43 → 44), és mindhárom védelem tartott.
N113Az átirat lekérdezése böngésző nélkülcompleteAz N109-ben javított hiba maradék fele: a megnyitás már elindítja a lekérdezést, de ha senki nem nyitja meg a lapot, továbbra sem történik semmi. Új, szűk jogú végpont (POST /api/transcriptions/poll), amit a levélfigyelő félóránként meghív — a válasza darabszám, nem leirat, ezért a gépi szerep is megkaphatja. A jogot (meetings.poll_transcription) az önellenőrzés elkapta, mert a gépi szerep jogkörét szándékosan rögzíti egy állítás; frissítve, plusz egy új állítás arra, hogy ez a jog NEM nyitja meg a megbeszéléseket (403 marad). Élesben azonnal lezárta a függőben lévő felvételt.
N114A HNT-felvétel elkészült és elemezveon productionA tegnap este feltöltött felvétel a Sonioxnál rég kész volt — csak senki nem kérdezte meg. Az új lekérdezés első futása lehozta: 45 032 karakter, 405 beszélőváltás, 5 külön beszélő. Az elemzés ebből 10 döntést és 11 feladatot adott, valódi felelősökkel (Bolvári Boglárka, dr. Arató Petra Zita, dr. Molnár Péter), és 3 résztvevőt ismert fel a leiratból. Ezzel a tegnapi öt felvétel mindegyike feldolgozva: összesen 45 döntés és 85 feladatjavaslat.
N115Döntésnapló: a döntés saját rekordcompleteMérve 2026-08-13: 50 kinyert döntés élt kizárólag a meeting.analysis.dontesek tömbben, szövegként, és 0 rögzített döntés volt a megbeszélés-rekordokban. Nem volt kereshető, nem volt szűrhető, és nem került át az átadási anyagba — pedig egy megbízott vezérigazgatónál a döntésnapló maga a leltár. Új decisions gyűjtemény, az alakot a migrate() adja: a napló vetület az elemzés döntéseiből és a kézzel rögzítettekből. A forráskulcs a szöveg ujjlenyomata, ezért az azonosító olvasásonként stabil (háromszori migráció után is ugyanaz az 50 azonosító), és az újraelemzés nem duplázza a naplót. Az elemzésből jövő döntés javasolt állapotban születik: a gépi kivonat nem jegyzőkönyv. Az elvetés státusz, nem törlés — különben a következő olvasás ugyanazt hozná fel újra, örökre. Külön nézet szűrésekkel és élő kereséssel, egy kattintással átadási tétellé (mérve: a tétel és a döntés kölcsönösen hivatkoznak egymásra, tehát kétszer nem tehető meg), és /api/decisions-export. Az export a maszkolt listából épül, nem a nyersből: egy összesítő a legkönnyebb szivárgási út.
N116A döntés láthatósága a forrás-üléséécompleteA jogosultság nem szerep-, hanem rekordkérdés, ahogy a feladatnál és az ülésnél: a döntés a forrás-megbeszélés visibility mezőjét viszi, és ez minden olvasásnál frissül. Az igazgatói nézet csak a board ülések döntéseit látja. Négy szabotázs, mind elbukott a kapun: (1) a döntés visibility mezőjét kézzel board-ra írva a forrás-ülés felülírja; (2) az ülés résztvevőjeként sem jár hozzáférés — a leirathoz adott résztvevői mentesség (Q11) a naplóra szándékosan nem terjed ki; (3) jogosulatlan szerep 403-at kap, az egyedi lekérés 404-et, hogy a létezés se derüljön ki; (4) a láthatóság-öröklés kivétele bukik a teszten. Az ülés megnyitása és visszazárása mindkét irányba átviszi a döntéseit — ez is mérve.
N117Tömeges jóváhagyás, felelőssel menet közbencompleteMérve: 88 függő feladatjavaslat 6 megbeszélésben és 72 eldöntetlen levéljelzés állt sorban. Egyesével kattintva ez több óra — ezért álltak ott. Új Jóváhagyás lap: minden függő javaslat egy képernyőn, megbeszélésenként, a jelzések naponta, csoportonként „Kijelöltek elfogadása" és „A többi elvetése". Felelős rendelhető menet közben, a soron belül — ez volt a gazdátlan feladatok oka: a modell szándékosan üresen hagyja a felelőst, ha a leiratból nem derül ki, és a jóváhagyáskor eddig nem volt hol megadni. Élesszerű adaton mérve: 12 javaslatból 11 elfogadva egy kattintással, és amelyik sorban felelőst adtam, az felelőssel jött létre; a kipipálatlan a helyén maradt, majd elvetettként. A megbeszeles fajtájú jelzést a tömeges elfogadás kihagyja és ezt ki is mondja — ütközést kell vizsgálni, és egy csendben kétszer felvett ülés rosszabb, mint ha egy sem lenne.
N118Az újraelemzés eddig eldobta az emberi ítéletetcompleteLatens hiba, amit a jóváhagyás építése hozott elő. A meeting.analysis cseréje az újraelemzéskor az applied jelölést is elvitte: a már elfogadott javaslatot a rendszer újra felajánlotta volna, minden jelzés nélkül — huszonnégy elfogadás után huszonnégy duplikátum. Pontosan az a néma hibaforma, amit ez a projekt már hatszor megfizetett. Az ítéletet most a javaslat címének ujjlenyomata viszi át (carryProposalVerdicts), tiszta függvényként, sorrendtől függetlenül. Szabotázzsal mérve: az átvitel kivétele elbuktatja a tesztet.
N119Heti státuszjelentéscompleteA tulajdonos a keddi NKOH-egyeztetésre féloldalas állapotjelentést kér mindenkitől; a rendszer minden összetevőt ismert hozzá, csak négy lapon szétszórva. Projektenként: mi készült el a héten, mi csúszik, mi akadt el, mely döntések születtek, mi a következő heti kötelezettség, milyen ülés volt. Nézet + nyomtatás + markdown letöltés, egyetlen kiszolgálóoldali számolásból — két megvalósítás néhány hét alatt elcsúszna, és a papíron lévő szám mondana mást. „Ezen a héten készült el" a feladat naplójából derül ki, nem az állapotából: az állapot csak azt mondja, hogy MOST kész, egy három hete lezárt feladat különben minden héten újra bekerülne, és a jelentés hetente ugyanazt ünnepelné (szabotázzsal mérve). Csak megerősített döntés kerül bele; a függők darabszáma viszont ki van mondva, hogy a hiányuk ne látsszon teljességnek. A jelentés a maszkolt adatból épül.
N120Az őr talált egy lapot, amit sosem mértcompleteA geometriai őr mostantól laponként megköveteli a valódi tartalmat, és ez azonnal talált egyet: az átadás lap mind a négy szélességen ÜRESEN mérődött, mert a kezdeti tartalomban egyetlen átadási tétel sincs. Az őr hónapok óta zölden jelentett egy lapról, amit meg sem nézett. A puszta panel-számlálás erre kevés lett volna — a „összeállítás…" felirat maga is panel —, ezért laponként az a kiválasztó a küszöb, ami a valódi sorokat jelenti. Most 14 tétellel mér; elrendezési hibát nem talált rajta, de ezt eddig nem tudtuk, csak hittük. Az őr adata a három új lapot is megkapja (24 megbeszélés javaslatokkal és elemzéssel, 18 jelzés), és mindhárom új lap szabotázzsal ellenőrizve bukik, ha a sorelrendezés elromlik. 8 lapról 11 lapra.
N121Csak olvasható mezők a szűk jogú nézetekbencompleteAz előnézet hozta felszínre: az igazgatói nézetben szerkeszthetőnek látszó szövegmezők voltak, amiket a kiszolgáló elutasít — a gombok és a láthatóság-választó már kapuzva voltak, a mezők nem. A javítás egy helyen van, nem lapon-nézetenként: a data-coll+data-field páros az egyetlen jel arra, hogy egy vezérlő rekordot ír, és ez ugyanaz a páros, amiből a mentés dolgozik — ezért ami itt kimarad, az ott sem menne el. Mérve az igazgatói előnézetben: 5 megbeszélés-mezőből 5 letiltva, a tulajdonosnál 6-ból 0; a döntésnapló gombjai 100 a tulajdonosnál, 0 az igazgatói körben. A felület és a kiszolgáló szerkesztési térképének elcsúszása mindkét irányban néma hiba lenne, ezért teszt hasonlítja őket (szabotázzsal ellenőrizve).
N122Az elakadt átirat kimondásacompleteA processing állapot két perc és két nap után ugyanúgy néz ki, a lekérdezés pedig félóránként zölden lefut: egy örökre függve maradt munka pontosan így tud némán elveszni (ez az N109 harmadik felvonása). A munka mostantól viszi a kezdés időpontját, és egy óra után a felület kimondja, hogy ez elakadt — a teendővel együtt. Régi, időbélyeg nélküli munkára nem állít semmit: nem tudja, tehát nem találgat.
N123Az ülés törlése után árván maradt döntésekcompleteA saját munkámon talált hiba, mérve egy éles másolaton: egy 13 döntéses megbeszélés törlése után mind a 13 döntés ott maradt a naplóban, miközben a törlés párbeszéde azt ígéri, hogy a döntések is törlődnek. Az ok általános érvényű, és minden jövőbeli vetületre igaz: a migrate() csak HOZZÁAD, elvenni nem tud — nem lát olyat, ami már nincs. A takarítás ezért a DELETE ágába került. A szabály nem „mindent törlünk": a meg nem erősített döntés a gép állítása egy megszűnt forrásról, az megy; a megerősített emberi állítás, és a napló épp azért van, hogy a megbeszélésnél tovább éljen — az marad, de felveszi a forrás CÍMÉT, hogy a származása szövegként is meglegyen, és visszazár supervisor-ra: a láthatóságát eddig az ülés mezője őrizte, egy kaput pedig, amit már semmi nem tart karban, nem hagyunk nyitva. A két törlésdialógus szövege is javítva, mert eddig olyat ígért, ami nem történt meg. Szabotázzsal mérve.
N124Modellhasználat: mérve, nem hangolvacompleteA tulajdonos kérésére átnéztem a három modellhívást (elemzés, csevegés, levélfigyelő). A kód eddig egyszer sem mondta ki a ráfordítás szintjét, tehát mindhárom a high alapértéken futott. A kézenfekvő takarékosság MÉRVE megbukott. Ugyanazon a 41 358 karakteres leiraton, ugyanazzal a kóddal: high 16 döntést és 20 feladatot talált 3 perc 54 alatt, medium 10-et és 16-ot 1 perc 15 alatt. Az alacsonyabb szint nem rosszabb választ ad, hanem kevesebb tételt lát — és a levélfigyelő ismert hibája pontosan a kimaradás. Ezért az elemzés és a levélfigyelő is high maradt, most már kimondva; a döntés mérésen áll, nem feltevésen. (Egy-egy futás, nem sokmintás mérés: az irány egyértelmű, a pontos számok nem etalonok.) Ahol a takarékosság ingyen van, ott meg is történt: a csevegés low szinten ugyanazt a választ adja 35%-kal gyorsabban (15 s vs 23 s, 1283 vs 1343 karakter) — ott a válasz kész anyagból születik, nem felderítésből. Két valódi hiba is előjött. (1) Az elemzés 16 000 kimeneti tokennel, nem streamelve futott — miközben ezen a modellen a gondolkodás alapból BE van kapcsolva és UGYANABBÓL a keretből eszik. Egy 3 perc 54 másodperces hívás ráadásul a HTTP-időtúllépés határának feszült. Most streamelve fut, 32 000 kerettel. A csevegés 2000-es kerete ugyanettől szenvedett: 4000 lett. (2) A csevegés költségkijelzője 44 beolvasott tokent mutatott egy hatvanezer karakteres korpusznál — mintha a modell szinte semmit nem dolgozott volna fel. A gyorsítótárba ÍRT tétel hiányzott a háromból. Pótolva; mérve: kérdésenként 40 443 token jön a gyorsítótárból, a teljes ár tizedéért. A szint mindhárom helyen környezeti változóval végigpróbálható (ANALYSIS_EFFORT, CHAT_EFFORT, SCAN_EFFORT), mert beégetve senki nem próbálná ki. A levélfigyelő mostantól kiírja a tokenszámot — eddig egyetlen futás sem rögzítette, tehát a napi ráfordítást senki nem tudta megmondani, és semmilyen optimalizálást nem lehetett igazolni.
N125A két javaslat-út nem tudott egymásrólcompleteTulajdonosi kérdés: visszakapja-e ugyanazt a feladatot. A két útra más a válasz, mérve. A levél-út zárt volt, két egymástól független zárral. (1) A figyelő a hívás ELŐTT kiszűri azokat a szálakat, amelyek már szültek jelzést — a kulcs a conversationId, ÁLLAPOTTÓL FÜGGETLENÜL, tehát a feladat törlése ezen nem változtat. Mérve: 100 szál van így lezárva. (2) A beírásnál a dedupeKey (mail:<szálId>:<típus>), és az a szabály, hogy amit egyszer elfogadtak vagy elvetettek, azt egy újabb futás nem támasztja fel. Az ülés-út viszont NYITVA volt. A levélfigyelő promptja megkapja a MÁR NYILVÁNTARTOTT NYITOTT FELADATOK listát a tiltással együtt; az ülés-elemzés promptja NEM kapta meg — csak névsort, projekteket, heteket, napirendet és a leiratot látott. Egy levélből felvett feladat, ha szóba került egy ülésen, MÁSODSZOR is javaslatként jött vissza, mert a két út nem tudott egymásról. A lista most az elemzés promptjában is ott van, ugyanazzal a tiltással — a lezárt feladatokkal együtt, mert egy elkészült munkát újra felajánlani rosszabb, mint egy nyitottat. Determinisztikus háló is került mellé, mert a prompt valószínűség, nem bizonyosság: a jóváhagyó lap kiírja, ha egy javaslathoz már van hasonló feladat, és a pipát alapból leveszi — a visszafordíthatatlanul nem ártó alapértelmezés. A felismerést a projekt MEGLÉVŐ titleSimilarity függvénye végzi (az ülés-párosításé), nem új kód. A küszöb (0.40) mérve, nem tippelve: a 88 függő javaslatot mind a 64 meglévő feladathoz hasonlítva 355 nem-nulla pár jött ki, a legmagasabb 0.375 — és egyik sem valódi ismétlés, csak közös témaszó. Az átfogalmazott UGYANAZ ezzel szemben 0.44 és 0.50 között. Az első tippem (0.62) a saját tesztjén bukott meg: a magyar toldalékok miatt (vitatolevelet vs vitatolevel) az azonos feladat sem ér el magas pontszámot. Amit nem fog megfogni: a lényegesen rövidebb átfogalmazást (0.25) — lejjebb víve valódi külön munkákat jelölne meg, és a figyelmeztetés, amit meg kell tanulni figyelmen kívül hagyni, az összes többit is elrontja. Élesszerű adaton mérve: 162 javaslatból pontosan 1 lett megjelölve, pipa levéve, a szöveg megnevezi a meglévő feladatot — nincs téves találat özöne. A felület másolata és a kiszolgáló képlete, valamint a küszöbszám is tesztben van összehasonlítva; mindkét szabotázs (elcsúsztatott küszöb, megváltoztatott képlet) elbukott.
N126A figyelő félóránként ugyanazt küldte elcompleteA tokenszámlálás (N124) első haszna: láthatóvá tett egy szivárgást, ami addig néma volt. A korábbi szűrő csak azokat a levélszálakat jegyezte meg, amelyek SZÜLTEK jelzést — amiben a modell nem talált semmit, arról nem maradt nyom. Mérve 2026-08-14: ötven szálból HARMINCNYOLC ment át a modellen minden egyes körben, naponta 48-szor ugyanaz a tartalom. Semmi nem hibázott: a futás zölden, eredménytelenül égette a keretet. Ugyanennek a szűrőnek volt egy NÉMA hibája is, ellentétes irányban: a jelzést szült szálat VÉGLEG kizárta, tehát ha egy ilyen szálra később az érkezett, hogy „aláírtuk", azt a figyelő soha többé meg nem nézte — pontosan a projekt visszatérő hibaformája. Egy javítás mindkettőre: a „megnézettük már" kulcs mostantól nem a szálazonosító önmagában, hanem a szál + az akkori legfrissebb üzenet ideje. Változatlan szál kimarad; új üzenet új kulcsot ad, tehát újra sorra kerül. A napló helyben él (scripts/mail-scan.seen.json, git-ből kizárva), és CSAK sikeres tervező-írás után frissül — előbb feljegyezve egy elhasalt írás után a szál „megnézettnek" számítana, és a benne talált jelzés soha nem érkezne meg. Végponttól végpontig mérve, három futásban: (1) üres naplóval 38 szál feldolgozva, 84 169 bemeneti és 9 208 kimeneti token; (2) közvetlenül utána, változatlan postaláda: „38 szál változatlan… a modellt meg sem hívom" — NULLA hívás; (3) egy szál állapotát visszaállítva (mintha új levél jött volna): pontosan az az egy szál került újra a modellhez. Közben egy második hiba is előjött, és épp az éjjel hozzáadott őr fogta meg: 38 szál egyszerre NEM fér a 8000 tokenes kimeneti keretbe. Eddig ez csonka JSON-ként, értelmezhetetlen hibaként jelentkezett volna, és az EGÉSZ futás elveszett volna — azokkal a szálakkal együtt, amelyekkel semmi baj nem volt. A hívás mostantól 12-es kötegekben megy, kötegenkénti hibatűréssel: egy elhasalt köteg nem viszi magával a többit, és csak a sikeres kötegek szálai kerülnek a naplóba. Mérve: 4 köteg, 24 javaslat, egyik sem hasalt el. Amit szándékosan NEM tettem: a rögzített előtag gyorsítótárazását. Az előtag (névsor, projektek, nyitott feladatok) hívásonként ~13 000 token, tehát csábító — de a takarékosság csak a többkötegű futásokon térülne meg, azok viszont a javítás után épp a ritka esetek. Két futás közt harminc perc telik el, ami hosszabb az ötperces élettartamnál; az egyórásnál pedig a kétszeres írási ár nem térül meg egyetlen olvasásból. Számolva, nem feltételezve.
N127A sikertelen futás is jelentéscompleteMa reggel 9:40-kor elfogyott az API-keret. A levélfigyelő ettől kezdve félóránként elhasalt, és ezt KIZÁRÓLAG a /tmp/nruceo-mailscan.err fájl tudta — amit senki nem néz. A felületen mindez annyi volt, hogy „régen hallottunk felőle", ami pontosan ugyanúgy néz ki alvó gépnél, álló levéltárnál, lejárt kulcsnál és elfogyott keretnél. A kulcs időközben újra működik; a rés viszont maradt volna. Mostantól a figyelő a hiba OKÁT is elküldi a tervezőnek (/api/mail-status, error mező), a fejléc pirosra vált, és a súgóbuborék kiírja a pontos üzenetet. Két szabály tartja helyben: (1) a hiba NEM írja felül az utolsó SIKERES ellenőrzés idejét — az az elavulás jelzése, és nem gyengülhet; a hiba ideje külön mezőben van (failedAt). (2) Egy sikeres futás TÖRLI a hibát, különben a felület örökké egy már megoldott bajt panaszolna. Mindkettő tesztben van, és a szabotázs (a hiba felülírja a sikeres ellenőrzést) elbukott rajta. A hibaszöveg 300 karakterre vágva tárolódik. Ha épp a tervező sem érhető el, marad a napló és az elavuló időbélyeg — azon a ponton nincs hova jelenteni, és ezt a szkript ki is mondja. Mérve a felületen: hibás állapotban „Levelek: nem fut — épp most" pirosan, a buborékban a teljes ok és az utolsó sikeres ellenőrzés; egy sikeres futás után azonnal visszaáll.
N128Modellköltség: napi bontásban, munkánkéntcompleteMa reggel elfogyott az API-keret, és ezt semmi nem jelezte előre. Az N127 a hibát tette láthatóvá, ez a TRENDET: új Beállítások-lap mutatja naponta és munkánként (elemzés, csevegés, levélfigyelő), hogy hány hívás, hány token és mennyi becsült forint. A gyűjtés EGY helyen történik (recordUsage), és mind a három hívási hely átmegy rajta; a levélfigyelő a saját jelentésére ülteti rá a számait, külön végpont nélkül. A becslés a gyorsítótár kedvezményét is számolja: az onnan olvasott token a teljes ár tizede, a beírás 1,25-szerese. Egy áron számolva a csevegés becslése többszörösen túllőne — épp ott, ahol a gyorsítótár a legtöbbet dolgozik, tehát a szám pont fordítva vezetne félre. Mérve: egy csevegés-kérdés 0,018 dollár a gyorsítótárral, e nélkül ~0,13 lenne. Az egységárak feljegyzett dátummal állnak a kódban, és a felület KIMONDJA, hogy a forintérték becslés, nem a szolgáltató számlája — egy pontosnak látszó, valójában közelítő szám rosszabb, mint egy bevallottan becsült. Ismeretlen modellnél a legdrágább tarifával számol: az alábecsült költség meglepetést okoz, a túlbecsült nem. Harminc napnál régebbi nap kiesik (az első változatom itt hibás volt: egyetlen lépésben az egész előzményt törölte volna — tesztben rögzítve).
N129A geometriai őr eddig a Beállítások allapjait SOHA nem nézte megcompleteAz őr a settings lapot az alapértelmezett allapjával rajzolta, a másik hatot pedig soha nem látta — köztük az újonnan épült költséglapot, amin TÁBLÁZAT van, a legtörékenyebb elem keskeny sávban. Az őr mostantól lap:allap alakot is ért, és négy allapot külön mér (költség, hozzáférési mátrix, NRÜ vezetés, szótár); a jelentés a TELJES lapnevet írja ki, különben nem derülne ki, melyik allapon van a hiba. A hozzáférési mátrix a kiszolgálóról jön, ezért meg is várja — enélkül üres táblázatot mérne, ugyanaz a hiba, mint a heti jelentésnél. A költséglap adatát ugyanazon az úton kapja, ahogy élesben előáll (a levélfigyelő jelentésén keresztül), nem kézzel írt adatszerkezettel. A bővítés azonnal talált egy valódi, korábban soha nem mért hibát: az „NRÜ vezetés" lap 760 pixelen vízszintesen görgette az egész oldalt (813 > 760), mert a négyoszlopos táblázatról hiányzott a .scrollx burkoló, amit a heti terv és a mátrix már használ. Javítva — és az új költségtábla is megkapta, mert négy munkánál ugyanez a hiba jött volna elő. 11 lapról 15 lapra.
N130A saját naplóm a végtelenségig nőtt volnacompleteVisszanézve az N126-ra: a megjegyzésem azt állította, hogy a régi bejegyzések kiesnek a „megnézett szálak" naplójából — a kód viszont a teljes régi naplót vitte tovább minden mentésnél, tehát a fájl soha nem szűkült. A magyarázat nem bizonyíték, és itt a saját magyarázatom volt hamis. Javítva: a bejegyzés ÉRTÉKE maga az időbélyeg, tehát külön nyilvántartás nélkül eldobható, ami kilencven napnál régebbi (a lekérdezési ablak egy nap, alkalmi újraszinkronnál is legfeljebb kettő hét). Mérve: egy 2025-ös és egy 2026 márciusi bejegyzés kiesett, a friss maradt, a futás 39 valódi szála bekerült.
N131A nyitólap nem tudott a legnagyobb halomrólcompleteA nyitólap arra való, hogy a nap ott kezdődjön — de a rendszerben ma 212 eldöntetlen javaslat áll (88 feladatjavaslat a megbeszélések elemzéséből, 74 levéljelzés, 50 megerősítésre váró döntés), és erről a nyitólap egyetlen szót sem mondott. Új panel: „Jóváhagyásra vár", a három sor számokkal és két gombbal a Jóváhagyás és a Döntések lapra. Nem ismétli meg a listákat — a nyitólap attól hasznos, hogy KEVÉS van rajta; a szám és az út odáig elég. A szöveg kimondja, mi ez a halom: nem feladat, hanem az a hely, ahol a rendszer munkája megáll és emberre vár.
N132Egy napnál hosszabb leállás után a levél véglegesen kiesettcompleteA figyelő fix EGY NAPOS ablakban nézett vissza. Ez addig helyes, amíg félóránként fut — de ha áll (ma reggel például elfogyott az API-keret, és órákig egyetlen futás sem ment végig), akkor egy napnál hosszabb kiesés után a közben érkezett levél VÉGLEG kiesik: nem hibázik semmi, a levél egyszerűen nem létezik a rendszer számára. Mérve az éles adatból: 19 órás szünet már előfordult a jelzések keletkezésében, tehát a 24 órás határ nincs messze. Az ablak mostantól a legutóbbi SIKERES futáshoz igazodik (mailStatus.checkedAt), egész napra felfelé kerekítve, 14 napos plafonnal. A megnézett szálak naplója (N126) teszi ezt olcsóvá: a szélesebb ablakból is csak az megy a modellhez, amit még nem láttunk — a szélesítés biztonságot ad, nem költséget. Mérve: 72 órás szimulált kimaradásnál 5 napra nyílt, 60 szálat hozott, ebből 27-et a napló kiszűrt, és csak 33 ment a modellhez; közvetlenül utána visszaállt 1 napra (39 szálból 38 kimaradt). A képletem első változata hibás volt: a Math.ceil mellé írt „+1 nap ráhagyás" dupla kerekítés volt, és minden NORMÁL futás is két napra nyitott — mérve 38 helyett 50 szál, minden körben, ok nélkül. Javítva. A 14 napos plafon fölött a kiesés egy része akkor sem fér bele; ezt a szkript KIMONDJA, a futást elavultnak jelöli, és megmondja a kézi szinkron parancsát — egy két hétnél hosszabb leállás után nem állíthatjuk, hogy minden levelet láttunk.
N133A képernyő és a papír mégsem ugyanazt mondtacompleteAz N119-ben azt állítottam, hogy a heti jelentés nézete és a letölthető dokumentum egy forrásból dolgozik, tehát nem tudnak elcsúszni. Valódi, mai éles adaton kiderült, hogy már el is csúsztak: a képernyő felsorolta a hét megbeszéléseit, a dokumentum viszont nem — a „projekthez nem rendelt" blokk azt írta, hogy „csak megbeszélés volt", de azt nem, hogy melyik. A közös FORRÁS nem elég, ha a két megjelenítés külön dönti el, mit rajzol ki belőle. Javítva; és a teszt mostantól minden blokk-mezőt megkövetel a papíron is, nem csak az elkészült munkát (szabotázzsal ellenőrizve). A dokumentum ezenfelül a megbízás állásával nyit — „A megbízásból 78 nap van hátra (2026-08-10 – 2026-10-31). Feladat: 2/64 kész, 0 elakadt, 0 csúszik." Egy időkorlátos munkánál ez a legfontosabb egy mondat, és egy külső egyeztetésen ez adja a keretet minden más számnak. A keddi NKOH-egyeztetésre készülő jelentés így ma éles adaton: 4 blokk, 37 sor, féloldalnyi — pontosan az, amit a tulajdonos kért.
N134A csendes futás nem jelentett — és a napló ezt tipikussá tettecompleteAz N126 napló bevezetése után a futások TÖBBSÉGE már nem talál új szálat (ez a lényege). A szkript viszont ilyenkor jelentés NÉLKÜL lépett ki — ez az ág korábban ritka volt, most a normális eset lett. Következmény: a tervező órákig nem hallott a figyelőről, a fejléc sárgára majd pirosra váltott volna, és a jelzés épp arról hazudott volna, amiért van: hogy a figyelő áll. Élesben mérve, a hiba MŰKÖDÉS KÖZBEN: az utolsó jelentés 20:53-kor kelt, miközben az ütemezett munka azóta is félóránként, hibátlanul lefutott. Javítva: a csendes futás is jelenti a tényt (időpont, átnézett szálszám, a levéltár kora). A termés és a MŰKÖDÉS két külön állítás — ez a szkript másik pontján már ki volt mondva, csak ez az ág maradt ki belőle. Ellenőrizve éles futással: a jelentés azonnal frissült, a jelző visszaállt semlegesre.
N136Az árfolyam és a modellárak a Beállítások közé kerültekcompleteAz N128 óta a becslés a kódba írt egységárakból és a 380 Ft/USD árfolyamból számolt, feljegyzett dátummal. Tulajdonosi döntés: legyen szerkeszthető. Új egyrekordos végpont (/api/arak, GET és PUT, settings.manage joggal), a Modellköltség lapon szerkeszthető mezőkkel; a feljegyzés dátuma is mező, mert a becslés hitelét az adja, hogy MIKORI árlistából származik. A hiányzó modellár továbbra is az alapértelmezettre esik vissza — egy új modell így nem nullával számolna. A bevitel ellenőrzött: nem szám, negatív és nagyságrendi elgépelés 400-at kap, és olyankor semmit nem ír. Az önellenőrzés nemcsak a mentést méri, hanem azt is, hogy a MÁR RÖGZÍTETT tokenek forintértéke tényleg az új árral jelenik meg (kétszeres egységár = kétszeres becslés) — enélkül a szerkesztés csak látszatra hatna. Szabotázzsal ellenőrizve.
N137A handout arculata a tervező minden felületéncompleteA 2026-08-15-i éjszakai jelentés új vizuális arculatot kapott, és a tulajdonos jóváhagyta: mélyindigó cím (#1B1B6F), indigó akcentus (#3E2EE8), krémfehér alap (#F9F7F4), melegebb szürkék, 12/16 px lekerekítés, teljesen kerek pirulák, 15 px törzsszöveg, táblázatos számjegyek. A csere a jelentésrétegben történt, nem képernyőnként: a tokenek és a szórványos, kézzel beírt hexek egyszerre kaptak új értéket, a szerkezet és az elrendezés érintetlen — így a lapok a saját meglévő szabályaik szerint követték az arculatot. Böngészőben ellenőrizve: Áttekintés, Heti terv, Munkatársak, Döntések, Beállítások és 375 px-es mobilnézet. Sötét mód nincs: az alkalmazásnak eddig sem volt, és nem volt rá kérés.
N142Témacsoportok a projektek alatt, dobozok, és a projekt törlése végre igazat mondcompleteA csoport a PROJEKT rekordjában lakik (p.themes = [{id, text}]), nem külön gyűjteményben: egy önálló gyűjtemény hat helyet nyitott volna ki (COLLECTIONS, kapuk, maszkolás, importálás-ellenőrzés, törlési kaszkád, export), és amelyikről megfeledkezünk, az némán rossz. Így a migrate() egy sorral bővül, a meglévő rows() normalizálóval. A tagság SZÁRMAZTATOTT: a felület nem azt kérdezi, üres-e a mező, hanem hogy ISMERT-e a csoport — egy kifejezés kezeli a sosem besoroltat, a törölt csoportra mutatót és a másik projektbe átkerültet is. Nulla migráció, nulla kaszkád. A „Csoport nélkül” sáv akkor is ott van, ha üres: a nulla és a hiány nem ugyanaz. Saját hiba, amit a próba fogott meg: a csoport azonosító nélkül született (a migrate() OLVASÁSKOR pótol, a mentés válasza a nyers alakot hozza), és a besorolás némán undefined-ot írt — mérve 20 „besorolt” feladat nyom nélkül. Az azonosítót mostantól a felület adja. A PROJEKT TÖRLÉSE HAZUDOTT: a párbeszéd azt ígéri, hogy a feladatok projekt nélkül maradnak, valójában halott azonosítóra mutattak; a heti jelentés projektenként csoportosít, a gyűjtőblokkja a null-t viszi, tehát az ilyen feladat EGYIK BLOKKBA SEM esett — némán eltűnt a jelentésből. Javítva feladatra, jelzésre, ülésre, döntésre, átadási tételre; tesztben, szabotázzsal. Megbeszélés-lap: kiválasztás után a lista eltűnik, az adatlap viszi a teljes szélességet („← Lista” gombbal vissza), és tizenegy egyenrangú szakasz helyett öt doboz. Az őr mostantól a KIVÁLASZTOTT állapotot is méri: 17 lap.
N143A 23 témacsoport élesben, és a hat duplikátum eltakarítvacompleteKét új szkript, mindkettő próbamenettel indul, mentést készít írás előtt, és VISSZAOLVASSA az eredményt. npm run temacsoportok: a 23 csoport felvitele négy projektre (6/6/6/5), a valódi feladat-, döntés- és jelzéscímekből levezetve; két projekt szándékosan csoport nélkül marad. Ismételhető: ami már fent van, azt nem viszi fel újra. npm run duplikatum: az N141 hat kárának takarítása, szűk szabállyal — csak szó szerint azonos cím, csak a későbbi példány, és ha a két rekord TARTALMA eltér, nem dönt helyette. Mérési tanulság a jegyekről: a mirror.env Cloudflare-jegye a tükrözéshez készült, egyetlen joggal (KV · READ) — írásra 10000-es hitelesítési hibával hasal el, és mivel a --env-file FELÜLÍRJA a bejelentkezést, a jegy jelenléte elvette az írás jogát ott, ahol amúgy megvolt. Mindkét szkript ezért a wrangler saját bejelentkezését használja. Éles állapot: 81 feladat, 23 csoport, 0 azonosító nélküli csoport, 0 ismétlődő cím.
N145Az audit hátralévő tételei: a néma számláló, a résztvevőválasztó és a BeállításokcompleteEgy élő hiba: a megbeszéléslista döntésszámlálója a KÉZZEL beírt sorokat számolta, ami 33 ülésből 32-n üres — miközben a naplóban 72 döntés áll; a 22 döntést termelő ülés NULLAKÉNT nézett ki. A valódi naplóból számol. A résztvevőválasztó a 624 fős címtárat kínálta: ez az egyetlen függvény adta az adatlap 1394 eleméből 1114-et, 268 olyan szervezetfejléccel, amelyhez tartozó címek egyetlen ülésen sem ültek ott. Most a napi névsort kínálja, de aki MÁR résztvevő, bent marad — különben a kipipálása némán eltűnne. Adatlap: 1394 → 358 elem, 357 → 71 vezérlő. A felkészítő natív <details>-ben ült, ami minden újrarajzoláskor becsukódik — a ház foldjára állítva. Beállítások: a 93 soros vezetői kör táblázata hajtogatva (5566 → 1103 px), a szótár 630 chipje hajtogatva (6882 → 949 px), és az „Előnézet” meg a „Súgó” eddig .body burkoló NÉLKÜL rajzolt, nulla belső margóval — pótolva. Az őr zöld: 4 szélesség, 17 lap.
N147Témacsoport-javaslat, mérve — és a projektnév, ami mindent magához húzottcompleteA besorolás a legnagyobb hátralévő kézi munka (81 feladat, 23 csoport), ezért a rendszer javasol — a MEGLÉVŐ szóhasonlósággal, nem új gépezettel. Egy igazítás tette használhatóvá: a projekt nevének szavait ki kell venni a téma nevéből, mielőtt hasonlítunk. Enélkül a projektnevet tartalmazó téma mindenre illeszkedett — a „World Athletics kapcsolattartás” a projekt három olyan feladatát is magához húzta, aminek semmi köze a kapcsolattartáshoz. Mérve mind a 70 csoportos feladaton: szűrés nélkül 14 javaslat, ebből 3 hibás; szűréssel 14 javaslat, mind helyes. A küszöb 0,15, mért szám: a 70-ből tizennégyre ad javaslatot, az ötödére — ezt a felület ki is mondja, és ezért javaslatként áll ott, nem automatikus besorolásként. Szabotázzsal ellenőrizve: a szűrés kivételével a teszt azonnal elbukik.
N149A három adatlap egy nyelvet beszél a varázslókártyávalcompleteA munkatárs, a projekt és az átadási tétel adatlapja megkapja a .wizcard mértanát (23 px cím, 20/26 px fejléc-margó, halk árnyék) — a hercules-nyelv, amit a varázsló már beszél. A kiválasztó a .panel.sticky-detail, ami pontosan az adatlapokra illik: a Tervező és a Beállítások táblázatos hasábját nem érinti, mert ott a sűrűség szándékos — egy nyolcoszlopos táblázatnak nem a levegő hiányzik. 720 px alatt a margó visszaszűkül. Mellé a hozzáférési mátrix családfejléce a hideg #eef1f5 helyett a fájl saját csoportsáv-színét kapja.
N152Árva hivatkozások: kitakarítva, és a jövőben nem keletkezhetnekcompleteTíz árva hivatkozás állt az éles adatban: egy megbeszélés résztvevője egy már nem létező emberre mutatott; egy accepted jelzés egy törölt feladatra; és NYOLC halott feladat-azonosító egy ülés followUpTaskIds listájában — ezt a saját duplikátum-takarításom hagyta ott. Javítva, mentéssel és visszaolvasással; rekord nem törlődött, csak a sehová nem vezető hivatkozások oldódtak. Három réteg, hogy ne ismétlődjön: (1) a kiszolgáló takarít — a feladat és az EMBER törlésének kaszkádja eddig hiányzott, a projekté pedig a saját csoportjaira mutató themeId-ket nem oldotta; (2) egy teszt, ami OSZTÁLYT őriz, nem egy hibát: a hivatkozási térkép alapján mindent mindenre mutatva hoz létre, majd a legrosszabb sorrendben töröl, és minden lépés után nulla árvát követel — írás közben azonnal talált egy nyolcadik esetet, és szabotázzsal ellenőrizve; (3) npm run adatellenorzes, ami 21 hivatkozást néz végig az ÉLES adaton, alapból csak jelent, --javit-tal old — ez a háló arra, ha egy KV-szintű szkript kerüli meg a kiszolgálót. Két jogszabályi felirat is javítva, elsődleges forrásból: az előzetes vitarendezés a felhívás ellen a határidő lejárta előtti TIZEDIK napig (Kbt. 80. § (1) b) ba)), és a 148. § (9) objektív határideje (30 nap, legfeljebb 1 év a szerződéskötéstől) — az „objektív határidő nincs” csak a (3)-ra igaz.
N158a személyjavaslat felületecomplete- A javaslat a Munkatársak lap TETEJÉN áll, a névsor fölött, nem a Címtár fülön: aki a névsort nézi, annak kell megtudnia, hogy hiányzik onnan valaki. - Két gomb: „Felveszem a névsorba" (a meglévő promote-person) és „Nem kolléga" (nemNevsor: true).
N159projektfelismerés a gazdátlan jelzésekbőlcompleteMiért modellhívás. A nagybetűs szavak kiemelése mérve megbukott — a találatok élén emberek nevei álltak. A klaszterek csak a mondat jelentéséből állnak elő. Az élő adaton nyolc jelölt lett, 24 jelzést lefedve:
N160a felismerés és a felület ugyanazt a jelzéskört nézion productionA felület függő jelzésnek az új állapotút tekinti (pendingSignals), a felismerés viszont mindent, ami nem elutasított — vagyis az ELFOGADOTTAKAT is.
N161a feladatcímek nyelvi alakjacompleteÉlesben NÉGY alak keveredett a 70 feladatcímen:
N162a nyelvi felülvizsgálat csomagokban folyikon productionA tulajdonos jelentette: „nem jelenik meg semmi, ami valós szöveg lenne", a képernyőn a „Fut a felülvizsgálat…" áll. Megmérve: 88 másodperc — a 70 cím egyetlen modellhívásban ment. A válasz megérkezett volna, de másfél percnyi mozdulatlan felirat elakadásnak látszik, és a tulajdonos annak is olvasta.
N163névrendezés: ábécé, titulus nélkül, a Maxint leghátulcomplete1. Ábécérend a legördülőkben. Eddig a valaszthatoak() a TÁROLÁSI sorrendet adta — vagyis a felvétel sorrendjét, ami 93 főnél gyakorlatilag véletlen. Három ilyen legördülő volt: a felelősválasztó, a döntésszűrő és a feladatszűrő. 2.
N164a munkaviszony megszüntetése a lap aljára, három lépcsőbencompleteMostantól a lap alján, a törlés mintájára: csukott sáv gomb megerősítés. A megerősítés kiírja a nyitott feladatok számát, és kimondja, hogy a belépési jogosultság ugyanebben a lépésben szűnik meg.
N166a levélfigyelő küszöbe a tulajdonos saját döntéseibőlon productionAz első 27 eldöntött jelzésen mérve: 18 eldobva, 9 megtartva — 67% szemét. Fajtánként megtortent 75%, feladat 60%, hatarido 100% (2/2). A sor eközben 234 tételre nőtt, tíz napos legrégebbi tétellel, EGY döntéshozóval.
N167a nyitólap kimondja a közbeszerzési hiánytcompleteNem azért, mert rosszak: azért, mert semmi nem mondta, hogy hiányoznak. Egy adat, amit csak akkor tölt ki valaki, ha magától eszébe jut, üresen marad. A nyitólap pont arra való, hogy a nap ott kezdődjön.
N168határidő: a forrásnál, a meglévőkön, és a nyitólap vak ablakacompleteA jelzésnek nem volt határidő mezője, az acceptSignalSimple pedig fix dueDate: null-lal hozta létre a feladatot. Ha a levélben ott állt a vállalás, az a feladatra sosem jutott el.
N169a javasolt napirend meglévő megbeszéléshez, és a napirend összevonásacompleteA meglévő „Új megbeszélés ezekkel a pontokkal" gomb így másolt:
N170a felismerési szótár: a hat projektnévből egy sem ért el a SonioxhozcompleteA szójegyzék létezett, és minden átirat előtt el is ment. A hiba máshol volt.
N171a felismert döntések szerkeszthetőkcompleteMostantól soronként szerkeszthető és törölhető, a napirendi pontok mintájára. Üresre törölve kiesik. Az analysis beágyazott objektum, ezért egészben íródik vissza — a dontesek tömb önmagában nem mező.
N172újraleiratozás a mostani szótárral, és a szótár felületeon productionA 2026-08-18-i, 125 194 karakteres felvételen, szóhatárra illesztve:
N173a javasolt feladatok címe is szerkeszthetőon productionUgyanaz az ok, mint a felismert döntéseknél: a javaslat a leiratból származik, tehát elírást és félreértelmezést is tartalmaz, a „Létrehozás" viszont ezt a szöveget teszi feladattá — onnan pedig a heti jelentésbe és az átadási anyagba is továbbmegy.
N174összefüggésmátrix: mi tartozik ugyanahhoz az alprojekthezcompleteA témacsoport (alprojekt) mezője MINDEN rekordfajtán ott volt már. Élesben mégis:
N175a szótár szerkesztése a lap TETEJÉREon productionA tulajdonos jelezte, hogy nem tudja szerkeszteni a szótárat. A kód kint volt és működött — a szerkesztősorok a lap ALJÁN álltak, két olvasnivaló blokk (a mérleg és a 630 automatikus név) mögé temetve, és nulla saját szónál csak egyetlen üres sor látszott. A képernyőkép pontosan ott ért véget.
N176a felismert rövidítés is javítható, és kidobhatócompleteMostantól a bal oldali mező is szerkeszthető, és a kidobja a szót.
N177munkajelző: látszik, hogy a rendszer dolgozikcompleteA visszajelzés CSAK a kattintott gombon élt (aria-busy, a műveletkezelőben). A legördülők, a jelölőnégyzetek, a rádiógombok és a szerkesztőmezők viszont a change eseményen mennek, nem a műveletkezelőn — azok semmit nem jeleztek. A teljes újratöltés (refresh) sem.
N178a párbeszéd gombfelirata a kérdéshez igazodikcompleteA „Mégse" MEGSZAKÍTÁST jelent: ott a helye, ahol a felhasználó elindított valamit, és visszaléphet. A feladat lezárása utáni párbeszéd viszont eldöntendő KÉRDÉST tesz fel — „Következik ebből új feladat?" —, és ott a nemleges válasz nem visszalépés, hanem válasz.
N179mentés után MINDIG frissül a képernyőcompleteA mezők mentése a change eseményen fut, és így hívta a mentést:
N180166 alvállalkozói kontakt felvétele XLSX táblábólon productionA tulajdonos átadta a Hard Rock alvállalkozói bejelentések tábláját (884 sor, 209 érdemi adatsor), és kérte a kontaktok felvételét.
N181Részletes / Egyszerű nézet, és barátságosabb tipográfiacompleteA lapok magasságából mennyi a MÁSODLAGOS szöveg — indoklás, forrásmegjelölés, magyarázat?
N182menüikonok, üres állapotok, és a cím, ami eddig levágódottcompleteÜres állapot. Huszonhárom helyen áll csupasz mondat a lap közepén — az pedig hibának olvasódik: „nem töltődött be". Egy halk jel megnyugtat: nincs itt semmi, és ez rendben van. Egy CSS-szabály, mind a 23 helyen.
N183az elvégzett feladat alapból nem látszikcompleteA szabály a visibleTasks-ben, az EGYETLEN fojtóponton van: minden feladatlista azon megy át, tehát nem lehet olyan képernyő, ahol kimarad.
N184a döntés három művelete, és a kapcsoló, ami „semmit sem csinált"completeA tulajdonos jelezte: a Részletes kapcsoló látszólag semmit nem tesz. Mérve: a döntések lapját 11 134-ről 8 542 pixelre rövidítette (23%), a sorokat 94-ről 73-ra. Tehát dolgozott.
N185a kapcsoló, ami tényleg nem csinált semmitcompletejs for (const sel of ['#view', '#tabbar', '#more-sheet', '#preview-bar']) $(sel)?.addEventListener('click', actionHandler);
N186minden szerep végigmérve VALÓDI munkamenettelcompleteA próba mostantól valódi belépéssel dolgozik: szerepet ad, belépési tokent vált be, és a kapott sütivel próbálkozik. Mind az öt kiosztható szerepre:
N187minden szerep minden lapja, és a szerepcímkék igazságacompleteA szerepcímkék pontosítva. A címke az EGYETLEN dolog, amit a tulajdonos a szerep kiosztásakor elolvas, tehát nem ígérhet mást, mint amit ad:
N189a néma hiba végecompleteA change eseményen futó mentéseknél nem volt catch sehol; az elutasított ígéret senkihez nem jutott el.
N190az új felhasználó első percecompleteA nyitólap tetején megjelenik egy köszöntő, amelyik kimondja, hogy most nincs Önhöz rendelve feladat, és ez nem hiba — a feladatokat a vezérigazgatói kör osztja ki, és amint kap egyet, ott fog megjelenni.
N191sebesség, terhelés és a csevegés határa, mérvecompleteÚjrarajzolás valódi adaton (789 ember, 219 feladat, 217 jelzés):
N192Folyamatőr: a kattintás mentés újrarajzolás hurok mérésecompleteMiért kellett. Két ellenőrzés volt a házban, és mindkettő ugyanazt a réteget hagyta ki. Az npm test a kiszolgálót méri HTTP-kérésekkel; a felületről semmit nem mond. A geometriai őr a megjelenítést méri; nulla click() hívása van.
N193A kiszolgált felület ujjlenyomata: a telepítés bizonyításacompleteMiért kellett. Az N192 javítását kitelepítettem, és nem tudtam bizonyítani, hogy kiment. A gyökér belépés nélkül a belépőlapot adja, az /api/... 401-et. A wrangler „Deployed" üzenetén és egy verzióazonosítón kívül nem volt semmi.
N194A jóváhagyó sor két folyamatacompleteA holnap legterheltebb képernyője a jóváhagyó sor: 234 elbírálatlan tétel várja a tulajdonost. Két dolgot kell bizonyítani, és mind a kettőt a kiszolgálón, nem a képernyőn:
N195Az egyszerű nézet mérése: minden lapon, őszinte nevezővelcompleteA mérés átkerült a fő ciklusba, ahol minden lap már a tartalmas állapotában áll, és a KELL kiválasztó igazolta is, hogy áll.
N196A felület mérése VALÓDI adaton: 104 hiba, amit a vetőmag elrejtettcompleteA geometriai őr eddig a vetőmagon mért: 40 feladat, 6 megbeszélés, 95 munkatárs. Élesben 213 feladat, 795 ember, 35 megbeszélés és egy 250 250 karakteres leirat van. Az őr egy mentés másolatát is be tudja tölteni egy eldobható könyvtárba — az éles adathoz nem nyúl.
N197Papíron minden látszikcompleteA heti jelentés kinyomtatva a vezetés elé kerül. Ha a tulajdonos egyszerű nézetben nyomtat, csonka dokumentumot ad ki a kezéből — bevezető nélkül, a döntések és az indoklások két sorra vágva —, és semmi nem szól róla. A képernyőn minden rendben néz ki; a hiba csak a papíron látszik, ott viszont mások előtt.
N198A státuszoldal 142 szeletet mutatott 180 helyettcompleteKövetkezmény: az oldal 142 szeletet mutatott, miközben a ledger 197-ig tartott. Harmincnyolc szelet csendben kimaradt, és az oldal helyesnek látszott.
N199Rajzolási idő, és a leghosszabb leiratú alkalomcompleteMérve, éles adaton (795 ember, 219 feladat, 35 alkalom):
N200Ránéztem a képernyőkre, éles adatoncomplete1280 pixelen mindkét szövegből a lényeg tűnt el, és a mellékes maradt. A levélállapotban a .mailtext kapott min-width: 0-t és levágást, a .mailextra nem — a rugalmas elrendezés így a fontosat zsugorította nullára.
N201A bevezető, ami a saját lapjáról mondott valótlantcompleteEgy bevezető, ami a saját lapjáról mond valótlant, minden más állítását is gyanússá teszi. Mostantól számol: a LEAD bejegyzés lehet függvény is.
N202A keretmondat elhagyása, és a hiba, amit közben találtamcomplete- A prompt (authz.js, DONTES_NYELV) átírva. A korábbi MINTA maga tartalmazta a keretet, és a modell a keretet másolta le, nem a tanulságot — 122 megerősített döntésből 45 ezzel kezdődött. Az új minta keret nélküli, és a prompt ki is mondja a tiltást. - A meglévő szövegek: npm run donteskezdet.
N203Az átvezetés gombja kétszeresre vitte a döntésnaplótcompleteA megbeszélés lapján van egy gomb: „Összefoglaló és döntések átvezetése" (apply-notes). Ez az elemzés döntéseit átmásolja a kézi sorok közé, a felismert szöveget viszont ottHAGYJA. A napló mindkét forrásból származtat, tehát ugyanabból a döntésből két sor lett.
N204A 15 kétszeres döntés összevonvaon productionA tulajdonos döntése után: npm run dontesparok -- --osszevon --eles.
N205A hangfájl feltöltése telefonon: egy hiba, három tünetcompletehtml <input type="file" id="rec-files" …> <!-- a megbeszélés lapjának jelölésében -->
N206Ugyanaz a hiba a többi hosszú műveletben iscompletejs const bubi = $('#chat-stream'); // egyszer, az elején await ndjson('/api/chat', …, (sor) => { bubi.textContent = valasz; });
N207A folyamatőr mobilon iscompleteA tulajdonos mindkét eddigi hibát telefonon találta meg. A folyamatőr eddig 1280 pixelen futott: a kattintás mentés újrarajzolás hurkot senki nem járta végig telefonos elrendezésben, ahol alsó lapsáv van, egyhasábos a felület, és más gombok látszanak.
N208A hangfelvételnek nem volt méretkorlátjacompleteA hangfájl a Workeren megy át, és ott egészben a memóriában él: előbb nyers bájtsorként (request.arrayBuffer()), aztán a Soniox felé menő többrészes törzsben is.
N209A felvétel ne veszhessen elcompletejs const mr = new MediaRecorder(stream); // nincs megadva bitsebesség
N210A lap bezárása felvétel közbencompleteMostantól a böngésző kérdez, ha a lap bezárásakor bármelyik fennáll.
N211A futó felvétel minden lapon látszikcompleteAz N210 figyelmeztetése lapváltáskor egyszer szól. Ez a sáv folyamatosan: a fejléc alatt, minden lapon, futó órával, „Megnyitom" és „Leállítom" gombbal. Egy órán át futó, elfelejtett felvétel a legdrágább félreértés ebben a termékben.
N212Koppintási méret: az ellenőrzés, ami nem is létezettcompleteÉs a #view-n KÍVÜLI vezérlőket — fejléc, hibasáv, felvételsáv, lapsáv — egyáltalán semmi.
N213Összeragadt szavak, és a backtick-csapda megszüntetésecompleteAz első változatom csak elem gyerekeket nézett. A valódi esetben viszont az egyik oldal szövegcsomó volt (<strong>154</strong> csúszik) — a rugalmas elrendezés azt névtelen tétellé teszi, és a széli szóközét levágja.
N214Olvashatóság: kontraszt-ellenőrzéscompleteA mérce a WCAG AA: normál szövegre 4,5:1, nagy szövegre 3:1. Ez nem ízlés, hanem szabvány. A háttér a legközelebbi átlátszatlan ősé — az átlátszó háttér nem szín, hanem hiány.
N215Hatásőr: mi változik egy művelettől, és mi NEMcompleteHárom ellenőrzés volt a házban, és mind egy-egy réteget mért: az npm test a kiszolgálót, a folyamatőr a kattintás mentés újrarajzolás hurkot, a geometriai őr az elrendezést. Egyik sem mérte az ÖSSZEFÜGGÉSEKET.
N216A hatásőr kiterjesztése és a saját méréseim hibáicompleteAz első változat hat mezőt nézett. Két szabotázs simán átment rajta: a napirendi pont és a jelzés feladat-hivatkozása nem szerepelt benne. Egy hivatkozás-ellenőrzés annyit ér, amennyit felsorol — a fel nem sorolt mező nem „rendben van", hanem nincs megnézve.
N217Az elutasított írás ottmaradt a képernyőncompletejs if (rec) Object.assign(rec, changes); // optimista írás try { await api('PATCH', …); } catch (err) { markDirty(coll, id); throw err; } // …és semmi nem gördít vissza
N218A heti jelentés képernyője és papírja elváltcompleteA jelentés a kiszolgálón számolódik, és a felület hetenként EGYSZER kérdezi le:
N219Éjjel két órán át a rendszer tegnapot írtcompletejs const iso = (d) => ${d.getFullYear()}-${d.getMonth() + 1}-${d.getDate()};
N220A külső szöveg nem lehet kódcompleteEddig ezt semmi nem mérte.
N221A híd a laptop ébrenlététől függöttcompleteMit csinált a híd addig. Egy órás launchd feladat a laptopon átmásolta a tervező adatait az event.clinic nru sémájába. Ez működött — amíg a gép ébren volt. Lecsukott laptop mellett a tükör csendben elavult: a hídon semmi nem hibázott, csak nem történt semmi.
N222Két kulcs, ami nem azt nevezte meg, amiről szóltcompletekey: unowned:${orphan.length} — a „felelős nélküli feladatok" javaslat kulcsa a feladatok SZÁMA volt. Két irányban hibás:
N223A napi mentés ma nem futott le, és semmi nem szólton productionA launchd munkák állapotát nézve a com.nruceo.mentes utolsó kilépési kódja 1 volt. A napló mai bejegyzése egy fejlécből állt, utána semmi. A hibafájl megmondta, miért:
N224A híd megáll a laptop nélkül ison productionAz éles cron lefutott. 2026-08-28 18:00:49 UTC, magától, a Cloudflare ütemezéséből — semmit nem indítottam el.
N225Két egyidejű mentésből az egyik elveszettcompleteMinden írás a TELJES dokumentumot olvassa be, módosítja és visszaírja. Élesben minden kérés SAJÁT másolatot kap a KV-ből, tehát a második írás egy olyan állapotot ír vissza, amiben az első változása nincs benne.
N226A megszűnt munkaviszony négy úton mégis köthető voltcompleteA kapu egy MEZŐLISTÁT őrzött. Az élesben tárolt személyazonosítókat végigmérve kiderült, hogy a lista elmaradt a valóságtól — és mind a négy hiányzó út át is ment:
N227Két őr ugyanazt a portot kértecompleteAz őr fejlécében ott állt: „a teszt 4748–4750-et használja". Igaz volt, amikor leírták. A test.js azóta 4752-t és 4753-at is felvett, és a széljegyzet nem tudott róla — ahogy egy széljegyzet soha nem is fog.
N228npm run epseg: az adat épségecompleteEgy árva hivatkozás nem hibázik: a felület nem talál semmit, és üresen hagyja a helyet. A feladatnak „nincs" felelőse, a döntés „nem tartozik" megbeszéléshez.
N229Három biztonsági állítás, amelyik soha nem futott lecompleteA ház visszatérő hibaformája, hogy egy nem futó eset pontosan úgy néz ki, mint egy zöld. Egy for üres listán csendben átugorja az állításait; egy if ág soha nem teljesül. Eddig ezt semmi nem mérte.
N230A kérdezz-AI korpuszának három szakaszát senki nem mértecompleteA korpusznak nyolc szakasza van; próba kettőre volt. Az Átadás-átvétel szakasz maszkolását ki lehetett kapcsolni úgy, hogy egyetlen próba sem lett piros — pedig egy viewer nulla átadási tételt láthat, tehát élesben mind a huszonöt kikerült volna a modellhez.
N231156 nap a falig, és semmi nem szólt volnacompleteA megbízás tíz hete ezen belül van, a rendszer élettartama viszont nem feltétlenül. És a fal némán jönne: egy korlát, amiről csak az ütközéskor tudunk meg, nem korlát, hanem meglepetés.
N232Egy kockázat, amit én vittem be, és lezártamcompleteAdat nem veszne el — a saveSeen csak SIKERES beküldés után fut, tehát a levelek a következő körben újra sorra kerülnének. De:
N233Két széles vizsgálat, ami nem talált semmitcompleteMinden API-útvonal kapuja. 26 útvonal végigmérve. Négy tűnt kapu nélkülinek; kettő a belépés maga (/api/login, /api/auth), egy csak a revíziószámot adja (/api/version), a negyedik pedig — a /api/preview — kapuzott, csak session.isSupervisor-ral, nem mayDo-val: a szondám nem ismerte fel.
N234npm run szabotazs: gépesített szabotázscompleteA szkript apró, mechanikus rontásokat visz be egyesével (>=>, ===!==, &&||, ||&&), lefuttatja a próbákat, és megnevezi azokat, amiket SENKI nem vett észre. Minden TÚLÉLŐ rontás egy szabály, amit semmi nem őriz.
N235Huszonöt tételnyi tudás, és az export egyet sem tartalmaznaon productionAz éles adat átnézésekor: 0 / 25 átadási tétel van késznek jelölve.
N236Becommitoltam egy élő szabotázstcompleteA gépi szabotázs a helyben lévő forrást rontotta el és állította vissza. Amíg futott, kiadtam egy git add -A && git commit-ot — és a parancs besöpörte az ÉPP ÉLŐ rontást. Így került az a59cf2b commitba:
N237Tizenegy helyen UTC-ben számoltuk a mai napotcompleteMegmérve, ugyanabban a pillanatban:
N238Egy üres fájl egy lépésben elvihette volna az egészetcompleteAz éles Workeren ráadásul pillanatkép sem készült: a helyi kiszolgáló írás előtt félretette a régi állapotot, a Worker nem. Élesben a visszatöltés visszavonhatatlan volt. Megint egy adapter-különbség, ami elrejtette a hibát.
N239A gépi szabotázs négy fájlon: 66 rontásból 9 maradtcompleteA belépés két tartóoszlopát semmi nem mérte. Az auth.js 65. és 85. sora: a token EGYSZER használhatósága és a LEJÁRATA, illetve a munkamenet lejárata.
N240A beragadt feltöltés csendben megállította volna a képernyőtcompleteA következmény nem hibaüzenet, hanem némaság:
N241A fal utolsó előtti méterecompleteEddig: a Cloudflare adott volna egy angol nyelvű, technikai hibát, a felhasználó pedig annyit lát, hogy „nem sikerült menteni". Semmi arról, hogy MIÉRT, és semmi arról, hogy mit lehet tenni.
N242A backtick kilencedszer, és most már egy másodperc alatt kiderülcompleteA npm test zöld maradt közben: az API-próbák nem elemzik a lap JavaScriptjét. Csak a böngészős őrök vették észre, két perc múlva, „a felület nem töltődött be" üzenettel — ami tíz másik okra is illik.
N243A gépi szabotázs második köre: a belépés és az összevonáscomplete- a lejárat PONTOS határa, tokenre és munkamenetre is. A <= és a < közti különbség egy ezredmásodperc, de a szabály attól még szabály; - a felhasznált és lejárt tokenek takarítása. Ez nem szépészeti kérdés: a lista a db-dokumentumban él, aminek 25 MB a felső határa (N231).
N244A jegyzőkönyv-melléklet: egy leirat, ami Word-fájlban érkezikcompleteA tervezés lényege egy mondat: egy jegyzőkönyv ugyanaz, mint egy leirat. Ami benne van — kik voltak ott, mi dőlt el, mi a következő lépés — pontosan az, amit a rendszer a hangfelvétel leiratából is kiszed.
N245Két ülés egy napon, és én összekevertem őket — élesbencompleteÉlesben lefuttatva a Steering Group jegyzőkönyve az „NRÜ belső vezetői értekezlet" leiratához került. Két teljesen különböző ülés — az egyik a World Athletics irányítócsoportja külső résztvevőkkel, a másik egy belső értekezlet —, egyetlen közös napon: 2026-08-27.
N246A gomb mellett ott áll, mennyibe kerülcompleteA szám mérésből jön, nem tippből. A usage napló megmondja, hány elemzés futott és mennyibe került: 8 futás, 4,29 dollár átlag 204 Ft. A leirat hosszával arányosítjuk, de csak FÉL súllyal: a kimenetet a séma korlátozza, a döntések száma nem a leirat hosszától függ.
N247Modellcsere: megmérve, ugyanazon a leiratonon productionA tulajdonos kérdése: van-e értelme Claude helyett a Cloudflare beépített Llamáját használni ezekhez az elemzésekhez. A válasz elé egy mérés került — ugyanaz a leirat, ugyanaz a kérdés és séma, két modell.
N248A levélfigyelő megmérve, és egy nagyobb kar, mint a modellcsereon productionUgyanaz a 25 levélszálas köteg, három modell, ugyanaz a kérdés és séma.
N249A gyorsítótár nem épült meg, mert a mérés megállítottaon productionA tulajdonos kérte a gyorsítótár beépítését — az én ajánlásom alapján (N248), ahol ~5 500 Ft/hó megtakarítást írtam „minőségváltozás nélkül".
N250A szűkített lista és a Llama, megmérveon productionUgyanaz a 25 szálas köteg, ugyanaz a modell (opus), csak a kérdésbe tett feladatlista más: mind a 242 nyitott feladat, vagy a legutóbb módosított 60.
N251A séma RÁKÉNYSZERÍTHETŐ, de a Scout egy fajtát nem lát megcompleteAz N250 nyitva hagyott kérdése: a Workers AI json_schema módja rá tudja-e kényszeríteni a saját sémánkat a Llama 4 Scoutra. A json_object mód nem tudta — a modell a saját kulcsneveivel válaszolt, tehát gépileg használhatatlan volt.
N252Valódi kötegen: az alak tartható, a FAJTA nemcompleteAz N251 nyitva hagyott kérdése: valódi 25 szálas kötegen mennyit talál meg a Scout az opushoz képest, fajtánként bontva. Lemérve.
N253Éles felhasználók előtt: a bevitel semmit nem utasított elcompleteA héten éles felhasználók jönnek. Eddig egy ember gépelt, és aki elgépelte, ki is javította. Több kollégánál ez nem áll.
N254Árva hivatkozás bevihető volt, és egy szám is elment azonosítónakcompleteAz N253 folytatása ugyanazon az úton: ha a cím ellenőrizetlen volt, mi van a HIVATKOZÁSOKKAL?
N255Az értékkészletek ellenőrizetlenek voltak, és a saját próbám bizonyítottacompleteAz N253 (cím) és az N254 (hivatkozás) után a harmadik ugyanezen az úton: a MEZŐK ÉRTÉKE.
N256A dátum bármi lehetett, és háromféleképpen volt némacompleteA negyedik ugyanezen az úton, és a legsúlyosabb: egy tíz hetes mandátumnál a határidő nem mellékes mező.
N257Amit MEGMÉRTEM és nem hiba, plusz egy rés a próbaadatbanon productionAz N253–N256 után végigmértem azt is, ami nem bizonyult hibának. Ezt ugyanolyan fontos leírni: enélkül a következő ülés újra megméri.
N258A felület éles méretű adaton is gyors, és az első mérésem hazudotton productionAz N257 résére (a próbaadat 40 feladatos, az éles 257) az volt a kérdés: van-e olyan hiba, ami CSAK nagy adaton jön elő. A gyanút megerősíteni látszott, hogy a npm run geometria éles méretű adattal betöltve időtúllépett („a böngésző 45 másodpercen belül nem válaszolt").
N259Két gomb a tapintási küszöb alatt, és egy elavult kompromisszumon productionAz N258 után éles méretű adaton végigmértem az elrendezést mobilon (375 px): vízszintes görgés 0, levágott szöveg 0 — és két koppintási cél a ház saját 40 pt-os mértéke (N12) alatt: a nézetváltó „Részletes" és „Egyszerű" gombja, 30 pixel.
N260Az összesítő elárulta azt, amit a lista elrejtettcompleteA tulajdonos döntése után (a kollégák member és director szerepben jönnek, nem supervisorként) végigjártam a felületet az ő szemükkel. Eddig minden mérés supervisorként futott.
N261A belépés 500-at adott rossz alakú kérésre, és a helyi próba erre vakon productionAz éles őr-ellenőrzés közben JSON törzset küldtem a /api/login-ra, és a válasz 500 lett. A request.formData() nem volt elkapva.
N262Az ismeretlen mezők őre, de CSAK ott, ahol a kockázat valóscompleteA tulajdonos kérte az ismeretlen mezők őrét (az N257-ben halasztottam). A kérdésben a kockázatot leírtam, és ennek ismeretében döntött — de a munka közben ÚJ bizonyíték került elő, ami a hatókört megváltoztatta.
N263A futtatókörnyezet-eltérés végigmérve: két feltöltési út 500-at adott volnaon productionAz N261 vakfoltja (a Node és a Workers web-API-jai eltérnek, és a helyi próba erre vak) nem egy hiba volt, hanem egy osztály. A tulajdonos kérésére végigmértem az egész hatókört.
N264A levéljelzés műveletei: az elrendezés bizonyítva volt, a MŰVELET nemcompleteA tulajdonos döntése: a jelzésrést zárjuk be. A rés viszont pontosabb volt, mint ahogy az N257-ben leírtam — ezt korrigálom.
N265A feliratok nyelve: 228 szöveg tiszta, 12 hibaüzenet nem volt azcompleteA tulajdonos mondta: a kollégák nem technikai emberek. Egy pontos, de fejlesztői szóval megfogalmazott üzenet náluk zsákutca — nem tudják, mit jelent, és nem tudják, mit tegyenek.
N266A teljes mobil út, és két gomb, amit telefonon nem lehet eltalálnicompleteA tulajdonos kérte a teljes mobil út bejárását. Nem írtam újat: az eszköz megvolt, csak nem futott.
N267A küldés gomb néma volt, és a kiszolgáló sem mondott igazatcompleteA tulajdonos jelentése 2026-08-30-án: kiküldött egy belépési linket, és „nem történt semmi, nem jelent meg animáció, a felület nem jelzett vissza". A levél nem érkezett meg.
N268A levélküldés működik: a teljes belépési út igazolvaon productionAz N267 lezárása után egyetlen dolog maradt, amit méréssel nem tudtam ellenőrizni: él-e a Brevo levélküldő kulcs. A titok a Workerben van, és egy próbaküldés valódi levelet küldött volna — ezért ezt a tulajdonosra hagytam.
N269Egyidejű írás: az ütközés VALÓDI, és a felhasználó munkája elveszettcompleteA tulajdonos kimondta: többen fognak egyszerre dolgozni. Ez volt a handout F1 feladata, és a legkockázatosabb nyitott tétel.
N270Optimalizálás: egy valódi nyereség, és két mérés, ami mást mondott, mint vártamcompleteAz N269-ben beépített automatikus újrapróbálkozás első változata minden kísérlet előtt refresh()-t hívott. Ez az én hibám volt, és drága: a /api/db az éles adaton 379 kB a huzalon, tehát két újrapróbálkozás ~758 kB fölösleges forgalom EGYETLEN mentéshez — mobilneten.
N271A súgó azt állította, hogy az adat nem hagyja el a laptopotcompleteA felhasználói kézikönyv munkájának első lépése a meglévő súgó felmérése volt. Az első mondata ez állt benne:
N272A telepítés elakadt: a wrangler bejelentkezése lejártcompleteA súgó-javítás (N271) telepítése elhasalt:
N273A súgó mindenkinek mindent mutatott, akkor is, amit nem látcompleteA munkarend 2. szálának első darabja. A kollégák member és director szerepben jönnek — a súgó viszont egyetlen, mindenkinek azonos szöveg volt.
N274Néma adatvesztés: 200-as válasz, mögötte nincs mentéscompleteA ház legrégebbi ellensége jött vissza, egy réssel odébb. Az N269 egyidejűség-munkája közben a próbám „instabilnak" látszott: hatból egyszer bukott ugyanazon a kódon. Majdnem flake-nek minősítettem.
N275Kézikönyv a kollégáknak, és egy állítás, ami nem volt igazcompleteA munkarend 2. szálának fő darabja: /Users/petermarik/Documents/nru-transition-planner/docs/KEZIKONYV.md
N276Helyben-súgó a fogalmakhoz, és a ház őre elkapta a saját hibámatcompleteA munkarend 2. szálának utolsó darabja. A rendszernek van néhány saját szava — jelzés, javaslat, „megtörtént", átadási tétel —, ami máshol mást jelent vagy sehol nem jelent semmit. Ezeket ott kell megmagyarázni, ahol előfordulnak, nem a kézikönyv 7. szakaszában.
N277Üzemeltetési eljárások, és három plist, ami nem volt érvényes XMLcompleteA munkarend 4. szála: /Users/petermarik/Documents/nru-transition-planner/docs/ELJARASOK.md
N278Keményítés: négy gyanú megmérve, három rendben, két rés a PRÓBÁKBANcompleteA munkarend 3. szála. A jegyzék szerint a fájltípus-ellenőrzés hiányzott — megmérve a gyanú nem állta meg a helyét, viszont a mérés közben két valódi rés került elő, mindkettő a PRÓBÁKBAN, nem a rendszerben.
N279A tétel kora UTC-ből számolt, és éjfél után egy napot tévedettcompleteA munkarend 1. szála, az „időzóna-váltás hete" tétel. A vizsgálat az óraátállítás miatt indult, és mást talált, mint amit kerestem.
N280A mandátum után a rendszer még mindig visszaszámláltcompleteA munkarend 1. szála, a „mi történik 2026-11-01 után" tétel. A rendszer tizenkét hétre készült, és a naptár nem áll meg.
N281A kereső ékezetvak lett, és megmondja, ha a másik fülön van az embercompleteA munkarend 1. szála, a keresőmezők tétel (a HANDOUT-2026-09-05 F1 pontja). Az öt beviteli őr a KÖZÖS ÍRÁSI úton ül; a keresőmező más út, oda be sem néz. Amit itt mértem, azt eddig semmi nem mérte.
N282A szűrősor a keze alatt csukódott be, és egy törölt szűrő láthatatlan voltcompleteA munkarend 1. szála, a szűrők kombinációi tétel (a HANDOUT-2026-09-05 F2 pontja). Három kérdést mértem: túléli-e a szűrősor állapota az újrarajzolást; mit mutat a felület, ha a szűrő olyan értékre mutat, ami már nincs; és mi történik, ha a szűrő és a fókuszcsempe egyszerre van bekapcsolva.
N283A nyomtatás éles adaton rendben; a geometria két leletet adott, egyet nyitva hagyokcompleteA munkarend 1. szála, a nyomtatási nézet valódi adaton tétel (a HANDOUT-2026-09-05 F3 pontja).
N284A mentés „16 kimaradt napot" jelentett, és a rendszer hibátlan voltcompletenpm run mentes a fejlesztői mappából:
N285A melléklet feltöltése négy védelemből hármat nem kapott megcompleteA munkarend jegyzékének utolsó át nem nézett területe volt: „fájlfeltöltés határesetei — 0 bájt, hibás típus, megszakadt kapcsolat". A tulajdonos mindkét eddigi feltöltési hibát TELEFONON találta meg, és mindkettő ugyanabba az osztályba tartozott: a feltöltés nem hibázott, hanem elnémult.
N286A ragadós hónapfejléc: nem a számolás volt rossz, hanem a böngésző mozdította el utánacompleteAz N283-ból nyitva hagyott lelet: a megbeszéléslista az aktuális hétnél nyílik ki, és a ragadós hónapfejléc 10-11 pixelt takar a sor CÍMÉBŐL — 375, 760 és 900 px-en; 1280-on nem.
N287A folyamatőr két „rendszerhibája" a SAJÁT vaksága volt, éles adatoncompleteAz átadó feljegyzés G3 tétele: NRU_MENTES=backups/eles-db-2026-09-06.json npm run folyamat két állítást buktatott, és a feljegyzés már kizárta, hogy regresszió volna (a változatlan ae793bd HEAD fán ugyanígy bukott).
N288A tavozott kapu a generikus íráson ült, az összevonás pedig mellette ment elcompleteA keményítési jegyzék utolsó nyitott tétele (G4). Az N-korábbi mérés a kaput hat generikus úton mérte végig, és mind a hat zár. Amit eddig senki nem kérdezett meg: minden írás generikus-e? Nem az — a házban tizennégy saját végpont ír, és ezek egyike sem megy át a guardTavozott-on.
N28995 szelet állt „élesben"-ben, pedig futtatható igazolás állt mögöttecompleteA tulajdonos kérése: „legyen kész minden, ami lehet, ahelyett hogy élesben állna." A státuszoldal 108 kész / 158 élesben / 3 folyamatban arányt mutatott. A kérés nem átcímkézés — az oldal saját szótára szerint:
N290A telepítés utáni próba a KISZOLGÁLÓRÓL semmit nem mond, és az olcsó javítás zsákutcaon productionA ház szabálya: „egy wrangler deploy, ami nullával lép ki, nem bizonyíték — npm run ujjlenyomat az, ami bizonyít." Ma kiderült, hogy ez csak a felületre igaz.
N291A négy hiányzó őr megírása, és amit közben a mérőeszközben találtam (G7)completeAz N289 hat szeletet hagyott on production-ben azzal, hogy nincs mögöttük megnevezhető őr. A munkarend G7 tétele ebből négyet nevezett meg. Mind a négy megíródott — és a megírás közben öt olyan hibát találtam, amit egyik szelet sem kért: egyet a felületen, négyet a MÉRŐESZKÖZÖKBEN.
N292A hatásőr ÉLES adaton: három következmény, amit a vetőmag elő sem tud állítani (G8)completeA hatásőr eddig kizárólag a vetőmagon futott: 40 feladat, 95 ember. Éles adaton (300 feladat, 789 ember) három eset mozdított olyan számot, amit a várakozáslistája nem ismert. Egyik sem rendszerhiba — mind a három valódi, helyes következmény, amit a vetőmag nem tud előállítani.
N293Mit lát a MÁSODIK ember? A folyamatőr 20. folyamata, két lappal (G9)completeA megbízás kimondja: „többen fognak egyszerre dolgozni." A kiszolgáló oldalán ez mérve volt (npm test: 9 elfogadott, 31 ütközés), a felület is tudott róla — de az ütközés utáni KÉPERNYŐT semmi nem nézte meg. A folyamatőr egyetlen lapot nyitott.
N294A varázsló befejező képernyője a geometriai őrben (G10)completeA tipográfiai halmazban a 24px volt az egyetlen tétel, amit a mérés nem ért el — a kivétellista ezt ki is mondta:
N295A 14. folyamat ingadozott, és az oka a MÉRÉSBEN voltcompleteA A tároló figyelmeztetése folyamat egy 375 pixeles futáson elhasalt:
N296Nyers JSON a belépőlap után, és a „biztonsági rés", ami a lap hazugsága voltcompleteA tulajdonos két dolgot jelentett be, egy órán belül. Ugyanannak a hibának két fele volt, és a második súlyosabbnak látszott, mint amilyen.
N297A belépési link körbe-körbe járt: a süti SameSite=Strict voltcompleteA tulajdonos bejelentése: „Beírom az e-mail-címet, megérkezik az e-mail, rákattintok, majd újra a linkkérő felület jelenik meg. Újra beírom, rákattintok, és csak ez történik körbe-körbe."
N298Egy ember, három címhalmaz: a rendszer kiküldte a linket annak, akit nem engedett becompleteMiután az N297 (SameSite) kiment, végigmértem a teljes belépési utat, hogy mi tud még elhasalni ugyanezzel a tünettel. Három dolgot találtam, mind ugyanabból a gyökérből.
N299A 409-es hibasáv a KÉPERNYŐN: az átadó útja nem létezett, a valódi úton a sáv hazudott, és a visszatöltés némán veszett el (G11)completeA G11 azt kérte, hogy a 409-es hibasávot végre valaki a KÉPERNYŐN is lássa, a feljegyzés szerinti egyetlen determinisztikus úton: a TELJES_IRAS (/api/db) ki van zárva az újrapróbálkozásból, tehát ott egyetlen ütközés eléri a sávot.
N300A patch() visszaállító sora a 409-es úton szándékosan nem hat — most kimondva, és mindkét oldala mérve (G12)completeA 409-es ágon az api() a feladás előtt refresh()-t hív, ami kicseréli a db-t. A patch() kezében lévő rec hivatkozás ettől leszakad, tehát az Object.assign(rec, elozo) egy árva objektumra ír. A képernyő csak azért helyes, mert a frissítés már behozta a kiszolgáló igazságát.
N301A 300-as porteltolás tiltott portra tette a folyamatőrt, és az őr azt mondta: „a kiszolgáló nem indult el"completeAz N299 előtt kiinduló battériát futtattam egy romlatlan másolaton (d4107e2), NRU_PORT_ELTOLAS=300-zal, hogy közben a munkafán dolgozhassak. A folyamatőr kétszer állt meg ugyanazzal:
N302A levélfigyelő szünetel: a tulajdonos döntése, az AI-költség miattcompleteA tulajdonos kérése, szó szerint: „függesszük fel az email fiók rendszeres ellenőrzését és feldolgozását, mert túl magas az AI API költség".
N303A gomb: egyszeri levélfigyelés a szünet alatt, Sonnet 5-telcompleteA tulajdonos kérése: „A tervező fejlécében »Levelek: szünetel« áll, szürke ponttal. Mellette legyen egy PLAY ikon, amely egyszeri futtatást alkalmaz a levélfigyelőre és elindítja az elemzést, azonban csak sonnet 5 modellel."

What “done” means here

Done means a verification script exited zero on the committed tree. Not that somebody opened the screen and it looked right, and not that an agent reported success. Every slice marked complete above has a script in scripts/ that exits 0 against the code as committed; a slice whose script has not exited 0 in a single run is not complete here, whatever else was built. Nem tud semmit igazolni, ami élő Soniox- vagy Anthropic-hívást igényel.

Run every gate at once:
npm test

Run it locally

# 0 · függőségek, egyszer
cd ~/Documents/nru-transition-planner && npm install
# 1 · a tervező helyben
cd ~/Documents/nru-transition-planner && npm start   # :4747
# prove the tree before believing any status above
cd ~/Documents/nru-transition-planner && npm test
# telepítés élesbe
cd ~/Documents/nru-transition-planner && npx wrangler deploy

Helyben nincs jelszó; élesben a fogaskerék alatt van a mentés, a szótár és a súgó.

Screens with data

Screen
Open at
What is on it
Heti terv
landing
http://localhost:4747/#planner
Az aktuális héttel nyílik, előre-hátra léptethető
Projektek
list + detail
http://localhost:4747/#projects
Feladatok, megbeszélések és a projekthez rendelt kontaktok
Munkatársak
list + detail
http://localhost:4747/#people
95 kontakt, szervezet → egység bontásban, keresővel
Megbeszélés
signature
http://localhost:4747/#meetings
★ Leirat, elemzés, résztvevők — a termék lényege
Beállítások
diagnostic
http://localhost:4747/#settings
Mentés/visszatöltés, felismerési szótár, súgó
Éles változat
production
https://nruceo.event.clinic/
Jelszó mögött, Cloudflare KV-vel