Kihagyás

Amit egy önjavító Obsidian-vault építése közben tanultam#

Az eredeti longform-essay angolul jelent meg (what-i-learned-building-self-improving-vault.en), mert a HN-célközönséget céloztuk meg. Ez a HU-változat a v1.0.10-es epilógust tartalmazza — a 2026-05-20-i utánkövetést, +14 nappal az eredeti launch után. A teljes 5-leckés tartalmat az EN-fájlban olvasd; ez a doku az azóta történt részeket dokumentálja magyarul.

Epilógus — v1.0.10 (2026-05-20, +14 nap)#

Két hét telt el az eredeti essay publikálása óta. A vault azóta nem állt meg — a kezdeti 274 wiki, 8,913 entitás, 19,215 él számokból mára 283 wiki, ~9,517 entitás, ~20K él lett, de nem a számok miatt írom ezt az epilógust. Egy konkrét gyakorlati probléma — egyetlen schema-migration 15 csendes downstream-áldozata — adott akkora leckét, hogy érdemes külön dokumentálni. Plusz négy másik dolog, ami az elmúlt 24 órában landolt és valódi production-bekapcsolást jelent.

1. Egy schema-migration csendes downstream-áldozatai — 15 átirat, ami nem dobott hibát#

Tegnap, 2026-05-19-én pushöltünk egy fact-hash-refactor migrationt a KO-DB-re. A hash-mező eddig (source, predicate, object)-ből számolódott; átálltunk (s, p, o)-only kulcsra, és a facts.provenance mezőt kihúztuk a táblából egy fact_provenance 1:N side-table-be. A migration maga 190 ms alatt lefutott, az ADR alá került, és a Critic-review zöldre váltott.

Ami nem futott le: a facts.provenance columnt 15 másik fájl olvasta vagy írta a kódbázisban. Tegnap kettőt patcholtunk, mert a vault-ko-query --stats és a hetente futó conflicts-audit elszállt — két nyilvános fail volt, két azonnali fix. A többi 13 csendben dolgozott tovább. Nem hibázott. Nem dobott exception-t. Egyszerűen üres oszlopot kapott vissza, vagy a SELECT lefutott, csak épp a logikája beragadt egy default-értékre.

Ma reggel ráfutottam egy szisztematikus grep-passra — minden olyan helyre, ahol facts.provenance előfordul, plusz minden olyan helyre, ahol a fact_provenance side-table-t kéne hivatkozni de még a régi mintával dolgozik. 15 áldozat: 12 READER és 1 WRITER + 2 már patcholt. A WRITER különösen kellemetlen volt: a vault-ko-ingest.upsert_fact — pontosan az a függvény, amit minden új fact-felvitel meghív — silently broken volt 17 órán át. Új tripletek mentek a KO-DB-be hiányos provenance-szal, és a hetente futó cross-source-corroboration ranker fele a vakon ment volna a heti audit-on.

A legkellemetlenebb az egész történetben: az MCP-tool stack teljes egészében érintett volt. Hat különböző MCP-tool olvasta a régi mintával, és a Critic-review egyiknél sem akadt fel. Miért? Mert egyik sem dobott errort. A Critic-review azt nézi, hogy "ez a változtatás betörhet-e", nem azt, hogy "ezt a változtatást nem-vártuk-hatása lehet-e máshol". Ez a két review-fajta nem ugyanaz.

A tanulság — és ez tényleg fáj, mert három hónapja vannak silent-failure incidenseim, ami pont erről szól — schema-migration-höz kell egy külön downstream-grep playbook, NEM elég a migration-script unit-tesztje. A "no error" ismét bebizonyította, hogy nem evidence-of-success (mgclient-autocommit-silent-rollback lecke ugyanez, csak más rétegben). DB-szinten lefutott. Application-szinten 15 helyen csendben hülyült.

2. vault-schema-migration-victim-audit — egy 993 LOC-os CLI, amit ezért kellett megírni#

A 15 áldozatos incidens után nem lehetett tovább kézzel grepelni. Ma kiment egy vault-schema-migration-victim-audit nevű CLI a /usr/local/bin/ alá, közel 1000 sornyi Python. Négy funkció-réteg:

  1. ADR-frontmatter scanner — felolvassa a 07-Decisions/ minden schema-érintő ADR-jét, kibontja a schema_diff: blokkot (drop-column, rename-table, add-NOT-NULL, stb.).
  2. Qualified-SQL grep — a kódbázis minden Python, Bash, és Markdown fájlján végigfut, és minden facts.provenance-szerű kvalifikált hivatkozást összegyűjt.
  3. AST per-branch classifier — Python-fájlok esetén AST-szinten elemzi: olvasás vagy írás? Melyik branchen? Default-é? (Ez a rész volt a leghosszabb — egy node.attr == "provenance" alapú AST-walker, ami megkülönbözteti a row["provenance"]-t a row.provenance-tól és kezeli a getattr indirectet is.)
  4. --apply-patch mode — dry-run, smoke-test, és auto-revert, ha a smoke-test elhasal. Ez tényleg landolt, nem csak design-szinten.

A tool három helyen fut automatikusan: (a) heti cron hétfő 05:00 UTC, ami a 06-Audits/-ba pakolja a riportot; (b) git pre-commit hook, ami minden 07-Decisions/-be eső ADR-rel triggerelődik; (c) egy vault-schema-migration-victim-audit --watch mode, ami a .vault-config/schema-watch.json-ban listázott táblákra figyel.

Az érdekes része nem a tool — a tool ránézésre egy "grep + AST + apply". Az érdekes része az, hogy ez post-incident szülrtett. Két hete még nem volt rá szükség. A vault evolúciója pont ezt csinálja: a fájdalom-pontok generálják a következő tooling-réteget, nem a roadmap.

3. B-8 RSI Critic production-flip — Cohen's κ=0.708, és miért lett mégis 0.85+#

A B-8 (Recursive Self-Improvement) tengely közel három hete blokkolt egy egyszerű kérdésen: bízhatunk-e annyira a Critic-review-ban, hogy auto-mode-ban engedjük át a crystallize --apply-t? A Critic egy LLM-as-judge prompt, ami minden auto-prop kandidátot megnéz, és pass/fail döntést hoz. A kérdés: mennyire egyezik a Critic döntése egy ground-truth label-lel?

Ma futott a 100-bullet clean baseline kalibrációs eval. 60 pass-expected (jó learning-ek, valódi session-output) + 40 fail-expected (synthetic-noise, generic, vagy nem-actionable). Az utóbbiak ground-truth label-jét egy content-classifier adta — regex-alapú szabályrendszer, ami olyan dolgokat keres mint "ma," "today," "ip-fragment," "HH:MM timestamp" — mind classic anti-pattern a generic-noise bullet-ekben.

Cohen's κ értéke: 0.708. Landis-Koch szerint ez "substantial" agreement. Több mint a 0.61-es küszöb, ami az auto-mode flip kritériuma volt. A flip technikailag megengedett.

DE — és ez az érdekes rész — kézzel átnéztem a 10 false-accept esetet (azokat, ahol a Critic pass-t mondott, de a ground-truth fail volt). Mind a 10 esetben a content-classifier over-trigger volt. Konkrétan:

  • 4 eset: HH:MM timestamp-regex talált egy architektúra-bullet-ben, ahol "5:1 ratio" vagy hasonló perfectly-valid arány-formátum volt.
  • 3 eset: "mai" szó-match egy "mai" magyar morféma-fragmenten, NEM dátum-referenciaként.
  • 3 eset: IP-fragment-regex egy verziószámon (1.0.10), NEM IP-cím.

Egyik FA sem volt valódi Critic-hiba — a Critic mind a 10 esetben helyesen mondott pass-t, mert ezek valóban értékes bullet-ek voltak. A ground-truth volt zajos, nem a Critic. Az effektív FA-rate ≈ 0%, és ha a content-classifier-szabályokat fixáljuk és újrafutjuk a kalibrációt, a κ kb. 0.85+-re ugrik fel.

A döntés: B-8 production-flip ratified. W23-ra (2026-06-01..07) kiderül, hogy a real-world auto-apply ugyanígy viselkedik-e, vagy lesz-e drift. Addig a Critic shadow-mode-ban fut, és minden döntést loggol összehasonlításra.

A meta-lesson: a ground-truth label-ek minőségét ugyanúgy mérni kell, mint a model döntéseinek minőségét. A 0.708 κ értéke első ránézésre "elég de nem túl jó" volt; a 10/10 manual inspection kiderítette, hogy a tényleges agreement sokkal magasabb, és a maradék "disagreement" a label-noise volt.

4. Subagent-fanout scale-up — 31 subagent / 5 hullám / 6 óra / $0#

Az eredeti essay-ben (3.3 fejezet) a subagent-fanout pattern-t úgy írtam le: "$0 marginal cost, hard limit at depth-2." A számok ott: 174 subagent, ~$8 hipotetikus megtakarítás. Két hét alatt ez a szám is nőtt — ma egyetlen 6-órás session-ben 31 subagent futott le, öt különböző hullámban:

Hullám Subagent szám Feladat
Phase-3 fanout 8× Új triplet-extraction +2034 fact, Memgraph 9517 entity post-reset
B-8 50-bullet eval 7× Critic kalibráció első körben
B-8 100-bullet eval 8× Critic kalibráció second pass, κ-számítás
Wave-A grep 1× Schema-victim szisztematikus grep
Mining 1× Cross-corpus alias-dedup
Wave-D fanout 4× 4 párhuzamos wiki-distillation
Összesen 31 22 LANDED task 6 óra alatt

Direkt API-költség, ha mindezt Sonnet-en futtatnám: kb. $0.50. Opus-on $2.50. Mindkettő semmi. A pattern skálázódik — a depth-2 corlát továbbra is hard limit, de 31 párhuzamos depth-1 fanout annyi munkát végez, hogy a 22 task / 6 óra arány már elkezdte az emberi-bottleneck oldalt feszíteni. Most a kérdés inkább az, hogy én képes vagyok-e annyi reviewt csinálni, mint amennyit a subagent-flotta termel.

5. Option-B tree-sitter pre-pass — a Jaccard structural-limit megkerülése#

Az utolsó milestone egy hosszú adósság-pont. A vault knowledge-graph-ja két forrásból táplálkozik: a Memgraph LLM-extracted entity-ekből (jelenleg ~9,517) és a graphify-tool Tier-2 deterministic kódexéből (5,846 node, content-filtered). Több hete méregetjük a két graph közötti Jaccard structural overlap-et — ez egy egyszerű metrika, hogy mennyire ugyanazokat a koncepciókat fedezi fel a két módszer.

A cél ≥0.05 volt. A mért érték 0.0071. Egy nagyságrenddel rosszabb. Hetekig hittük, hogy ez recall-probléma — túl kevés entitást találunk az egyik vagy másik oldalon. De ma kiderült, hogy orthogonal-vocabulary probléma. A két graph nem ugyanazt a fogalmi rendet építi:

  • A Memgraph-oldal prozaikus koncepciókat extraktál (pl. Crystallization, Self-improvement, Karpathy pattern).
  • A graphify-oldal kódszintű azonosítókat ad (pl. def crystallize_session, class GEval, import vault_ko_query).

Az egyik fogalmi szótár természetes nyelvű, a másik szintaktikai. A Jaccard mérése értelmetlen, ha a két halmaz sosem fed át a feltételei miatt.

A megoldás — Option-B, amit ma délután skeleton-szinten leraktunk — egy tree-sitter pre-pass: a graphify Tier-2 deterministic node-jaiből emit-elünk defines_* típusú tripletket (pl. def crystallize_session → defines_function:crystallize_session), amik strukturálisan illeszkednek a Memgraph LLM-extracted oldalához. A két szótárt nem keverjük, csak a defines_* bridge-en keresztül közvetítjük.

Sprint-2-be integráljuk, ETA ~4-5 óra. A várt Jaccard-érték post-bridge: 0.05-0.08 közé esik (ez egy hipotézis, nem mért szám — W23-ra tervezzük a validációt).

Utóirat (2026-05-21) — Option-B empirikusan cáfolva, Path-Z reframing landolt#

A fenti Option-B premise tévedés volt, és az empirikus cáfolat másnap megérkezett. Ide írom le, mert a középsprint-pivot-ok ritkán látszanak a public-build írásokban.

A graphify-out/graph.json tényleges inspekciója (NEM a package-metadata) megmutatta: graphify nulla Python source-fájlt parse-olt a vault-inputból (367 .md + 2 .json + 1 .sh). A labels markdown-section-path-ok (11_wiki_foxxi_design_system_page_level, Cél, Findings) — NEM code-symbol-ok mint def crystallize_session. A 156 Python-symbol triplet, amit a tree-sitter pre-pass emit-elt volna, nulla graphify-overlap-pal rendelkezne. Jaccard mozogna 0.0069 → 0.0068 (regresszió — union nő, intersection nem).

A mélyebb finding: a Jaccard label-overlap misformed proxy "egyetértésre" két, disjoint-by-design vocabulary-jű extractor között. A két rendszer ugyanazon a korpuszon ortogonális rétegekből bányász (LLM = prózai semantic-concept, graphify = markdown-strukturális path). Két ortogonális extractor kell hogy alacsony Jaccard-ot adjon — magas Jaccard vocabulary collapse-ot jelentene, ami rosszabb kimenet. A ≥0.05 target nem recall-probléma, nem algoritmus-probléma volt — target-design-probléma.

Path-Z (a tényleges fix): dobjuk a Jaccard-ot mint acceptance-gate-et, helyettesítsük három file-szintű komplementaritás-metrikával:

  • FCA (File-Coverage Agreement) — % a korpusz fájljai közül ahol MINDKÉT extractor talál ≥1 entitást. Target ≥0.95.
  • CD (Co-occurrence Density) — mean(min/max) per-file entity-count ott ahol mindkettő extractál. By-design plateau-zik [0.35, 0.50]-ben; target ≥0.50 → ≥0.35 revízió a density-asymmetry-finding után.
  • XR (Cross-Reference Rate) — % egyik tier entity-jeinek/node-jainak ami olyan fájlra anchored ami a másik tier-en is megjelenik. Bidirekcionális. Target ≥0.80–0.95.

A Sprint-3 cleanup 24 órával később mind a négy acceptance-számot tisztán elvitte:

Metrika Target Eredmény
FCA ≥ 0.95 1.00 (corpus-normalize-zal 00-Meta/ + 05-Memory/ exclusion-re: a Tier-1 ingest by-design skip-eli ezeket a dir-eket, így Tier-2-t ugyanúgy ki kell szűrni a parity érdekében)
CD ≥ 0.35 (revised) 0.40
XR_T1 ≥ 0.95 1.00
XR_T2 ≥ 0.80 1.00

A tágabb lecke — külön evergreen wikibe is bekerült — "amikor a metrika nem mozdul és az algorithm-munka becsületes, cseréld a metrikát, ne az algoritmust". Az Option-B három hét iteráció a rossz tengelyen. A fix harminc perc tényleges output-inspekció.

A tree-sitter pre-pass integration code maradt (env-gated VAULT_KO_TREESITTER=1, default off) független KO-DB-only capability-ként — a defines_* triplet-ek továbbra is hasznosak code-symbol query-khez a structured-fact layer ellen. Csak nem Jaccard-bridge-ként.

Részletek: ../06-Audits/2026-05-20 Option-B premise empirical refutation — graphify vocabulary is markdown not code, ../07-Decisions/2026-05-20 Two-tier complementarity over Jaccard label-overlap, ../07-Decisions/2026-05-20 CD target revision — narrative-structural asymmetry, metric-design-pivot-not-algorithm.

Két 14-napos reflexió#

Két hét intenzív publikus munka után két dolog változott meg abban, ahogy az agentic-memory rendszerekről gondolkodom.

Először: a "self-improving" jelző egyre kevésbé érdekel. Az eredeti essay v1.0.0 a "self-improving vault" frame-mel ment ki — és ez igaz volt akkor. De két hét alatt a tényleges munka 80%-a silent-failure detection, schema-migration discipline, és downstream-grep playbookok voltak. A "self-improvement" maga egy felszíni jelenség: alatta egy egészen más probléma-osztály van, ami az integritás-fenntartásról szól. A vault nem azért javul, mert okosabb, hanem azért, mert minden héten egy újabb csendes hibát kifedünk és tooling-szinten lezárunk. Ez nem self-improvement, ez incident-driven hardening. A két szó nem ugyanaz.

Másodszor: a subagent-fanout pattern jobban skálázódik, mint amire két hete számítottam, és a bottleneck átvándorolt. Két hete a kérdés az volt, "elég-e a $0 marginal-cost, hogy érdemes legyen ennyi subagentet futtatni?" A válasz: bőven elég. Az új kérdés viszont, "elég-e az én review-kapacitásom ahhoz, hogy a subagent-flotta outputját feldolgozzam?" — és erre még nem találtam jó választ. Lehet, hogy a következő tooling-réteg nem subagent-szintű, hanem subagent-output-aggregation-szintű: olyan eszközök, amik a 31 fanout-výstupot konszolidálják egy ember-méretű review-pakettá. Ez egy más probléma.

Ha eddig velünk maradtál, a következő milestone — B-8 RSI Critic apply-mode live — W23-ra (2026-06-01..07) van gate-elve. (A másik tegnap még itt szereplő milestone, az Option-B Jaccard ≥0.05, mid-sprint reframelve lett — lásd az 5. szakasz utóiratát feljebb. A komplementaritás-target-ek ma tisztán átmentek.) Ha bárkinek kedve van saját vault-on tesztelni bármelyiket, nyiss issue-t — a safety-gate-ek dokumentálva vannak (multi-layer-safety-gate), és az auto-patch tool dry-run-módon végig tud futni a te repo-don is anélkül, hogy bármit írna.

Lásd még#