Eirik OS · Post-Mortem Analüüs

2026-05-26 — Katastroofiline tööpäev

spawn_postmortem_koord11_01 agent_runs id=79 Koostatud: 2026-05-27 Tier 2 (Supabase MCP) — PASS_TIER2 Red Team RT1+RT2+RT3
Erki küsimus: "Kas see süsteem on üldse vajalik? Kas sellise funktsionaalsusega töökeskkonda kus ja OS kusagil juba olemas pole, et võta ja hakka lihtsalt kasutama?" — Selle rapordi eesmärk on anda erapooletu Red Team vastus.
1

Faktid ja kronoloogia — 2026-05-26

40
agent_runs kokku
28
Lõpetatud ✓
11
Ebaõnnestunud ✗
27.5%
Rikke määr
9
Distinct agendid
19
PR-id ühes päevas
10
Koordinaatori sess.
v3.8→3.11
CLAUDE.md vers. ühes päevas
07:45–08:21 UTC
H23 OS Reports portaal + Hypervision FAAS-2 D4
agent_runs id=47,50 — COMPLETED. Produktiivne algus.
07:45–12:57 UTC (5h 12min)
Zombie: id=46,48,51 jooksevad failed seisundis
h23-os-reports-portal (312 min), telegram_listener (300 min), cursor-eirik-onboarding (243 min) — kõik failed aga liinid ei lõpe.
08:54–14:25 UTC
Cursor Eirik onboarding (id=52) — 328 min failed
cursor_eirik stage: uus pere-liige ei suuda onboardingut lõpetada.
10:28–11:08 UTC
🚨 H3 BUILD_FAILED intsident (id=53)
_h3_probe_build.py kutsus undocumented DSM API → forestsense BUILD_FAILED. Koordinaator pime 39 min.
11:20–14:25 UTC (3h 4min)
Forestsense Driver PWA plaan (id=55) — 184 min failed
Plan session ei lõpetanud korrektselt.
13:00–16:02 UTC
Red Team 1+2 koordinaatori audit (id=59)
8 PR-i pakk #112-#119 planeeritud. COMPLETED.
18:42–22:22 UTC
Koord 5→6→7→8→9 (MCP fix + PR #127-#131)
Tier 2.5 läbimurre, PR #128 LIVE, koord chain 5 sessiooni.
21:48–22:05 UTC
Ghost-session id=70 (spawn_graphify_skill_audit)
process_state_id=NULL → Vahimees M1 ei näinud. Tegelikult lõpetas 17.4 min. PR #129 tuvastab selle seisundi.
24h+ (krooniline)
Tier 1 DEGRADED muster
195–199 DEGRADED teadet/päev Mai 24-25, 172/päev Mai 26. Ei ole 1-päeva probleem.
2

Kolm intsidenti — sügavanalüüs

SEV-1

H3 BUILD_FAILED — agent_runs id=53 (10:28–11:08 UTC)

Kestus
40.6 minutit
Põhjus
Probe-skript _h3_probe_build.py kutsus DSM API compose-create endpointi — undocumented → forestsense container BUILD_FAILED
Impact
Forestsense tootmis-konteiner build-failed seisundis, koordinaator pime 39 min (heartbeat 15-min kill ei rakendunud)
Root cause
"Probe" sildiga skript sisaldas tegelikult mutatsiooni (build/start/stop). PR #112 Kiht 1 read-only lipp polnud rakendatud.
Fix
PR #112 3-kihiline kaitse LIVE: _READ_ONLY_MODE + _audit_mutation + _ask_or_recommend. 7 _h3_*.py backfill.
Õppetund
Nimekonventsioon "probe" ei taga read-only käitumist. Kood peab tagama, nimi on dekoratiivne.
SEV-1

Ghost-session — agent_runs id=70 (spawn_graphify_skill_audit)

Kestus näiline
8+ tundi "running" — tegelik kestus 17.4 minutit
Põhjus
process_state_id=NULL → Vahimees M1 HeartbeatWatcher ei suutnud PID-i jälgida → ghost-seisund
Root cause
Tier 2.5 helper start_run puudus spawn-sessioonist (pre-PR #129 muster). agent_runs INSERT tehti otse, ilma process_state_log sidumiseta.
Fix
PR #129: kõik Tier 2.5 sessioonid peavad kasutama tier_2_5_helper.start_run() (annab process_state_id). Smoke-test PASS (id=72).
Õppetund
Monitoring toimib ainult kui jälgitav on registreerunud õigel viisil. "Kood töötab" ≠ "monitoring näeb".
SEV-2

Tier 1 DEGRADED krooniline — eirik-memory MCP port 8092

Kestus
Mai 23–27 (5 päeva), 195–199 DEGRADED teadet/päev peak
Mõõdik
agent_messages DEGRADED count: 35 (Mai 23) → 195 (Mai 24) → 199 (Mai 25) → 172 (Mai 26) → 43 (Mai 27 hommik)
Root cause
PR #130 implementeerimata — olemasolev mcp_doctor.py 3-strike consecutive-down loogika ei avasta intermittent degradation mustrit. Docker konteiner restardib manual.
Fix
PR #130 kandidaat: DEGRADED count >10/tund threshold + auto-restart DSM API kaudu (mitte SSH paramiko)
Õppetund
3-consecutive-down ≠ intermittent-degraded. Threshold-põhine monitor on vajalik lisaks strike-loendajale.

Zombie sessioonid (5 tk, 184–328 min failed)

idTargetKestus (min)Põhjus
46h23-os-reports-portal312.4Session ei lõpetanud — finish() kutsumata
48telegram_listener long-poll300.9Daemon ei lõpe kui session hangub
51cursor-eirik-onboarding243.2Onboarding nurjub midway, summary puudub
52cursor_eirik session328.5Pikim zombie — 5h28min
55forestsense-driver-pwa-plan184.6Plan session ei lõpetanud

⚠️ Kõik 5 zombie-sessiooni lõpetati korraga 12:57 UTC — tõenäoliselt CLI restart. Selle kinnitab id=53 lõpp 11:08 UTC, aga id=46/48/51/55 kõik lõpetasid 12:57/14:25 — batch-kill.

3

Alternatiivide analüüs — "kas mujal on midagi olemas?"

Hinnang 5 dimensioonil: K1 semantiline mälu · K2 graaf · K3 messaging bus · K5 watchdog · LLM-agnostic + äriprotsessid (Forestsense/TimberTrace)

Alternatiiv K1 Semantiline mälu K2 Graaf K3 Messaging K5 Watchdog LLM-agnostic Äriprotsessid Self-hosted Hind/kuu
mem0
mem0.ai		 ✓ vector+graph ~ Pro tier ✗ ei ole ✗ ei ole ✓ OpenAI/Claude/jne ✗ generic ✗ hosted only $249 (graph)
Cursor Projects
cursor.com		 ~ .cursorrules ✗ ei ole ✗ ei ole ✗ ei ole ✗ Cursor-only ✗ code-only N/A Pro $20
Letta (MemGPT)
letta.com		 ✓ core/archival/recall ✗ ei ole ✗ ei ole ✗ ei ole ✓ open source ✗ generic agents ✓ PostgreSQL+pgvector $5-10 self-host
Devin / OpenHands
devin.ai		 ~ session only ✗ ei ole ✗ ei ole ✗ ei ole ✗ hosted ✗ code-only ✗ $500+/kuu
Notion AI + Zapier ~ document search ✗ ei ole ~ Zapier webhooks ✗ ei ole ✗ Notion-only ~ manuaalne ✗ $30-100
Eirik OS
praegune süsteem		 ✓ 8656 äri-kirjet ✓ 132K sõlme ✓ agent_messages + relay ✓ 5 moodulit ✓ K0-K5 LLM-agnostic ✓ TimberTrace/TMA/KPDC ✓ NAS + Supabase ~$0 infra

Järeldus: Ükski alternatiiv ei kata kõiki 5 dimensiooni korraga. Lähim on Letta (K1 mälu + self-hosted) + mem0 (semantiline), aga mõlemad jätavad K3 messaging, K5 watchdog ja äriprotsessid (TimberTrace/TMA/KPDC) täielikult katmata. Üleminek alternatiivile = 8656 äri-spetsiifilise mälu-kirje kadumine + kõigi skill-failide (51+) ja PR-reeglite (130+) ümberkirjutamine.

4

Red Team analüüs — RT1 + RT2 + RT3

🔴 RT1 — Operatiivsed rikked: mis läks valesti 2026-05-26?

  1. Probe = mutation: _h3_probe_build.py kutsus build/start/stop — nime järgi "probe", tegelikult destruktiivne. Read-only lipp puudus (PR #112 polnud rakendatud).
  2. Zombie sessioonid: 5 sessiooni jooksis 184–328 min failed seisundis ilma auto-kill'ita. PR #107 heartbeat 15-min kill polnud kõikidel sessioonidel aktiivne.
  3. Tier 1 krooniline DEGRADED: 195–199 alert/päev Mai 24–25 — 5 päeva enne intsidenti oli TEADA probleem. PR #130 polnud implementeeritud.
  4. Ghost-session: process_state_id=NULL → M1 pime. Pre-PR #129 muster.
  5. 11/40 failures = 27.5% rikke-määr: Aktsepteeritud operatsioonikvaliteet on <5%. 27.5% tähendab, et iga 4. agent_run ebaõnnestub.

🟡 RT2 — Struktuursed probleemid: miks need rikked on võimalikud?

  1. Keerukuse keerukuse spiral: 19 PR ühes päevas → iga PR lisab uue reegli → reeglid tekitavad uusi compliance-alerteid → alertid tekitavad uusi PR-e. Süsteem kasvab kiiremini kui saab testida.
  2. CLAUDE.md v3.8→v3.11 ühes päevas: Identiteedi-reeglid muutuvad kiiremini kui agendid jõuavad nendega kohaneda. "Mis oli reegel eile" vs "mis on reegel täna" lahknevus.
  3. Monitoring bootstrapping paradoks: Vahimees K5 ehitatakse samal ajal kui seda vajatakse. M1/M3/M5/M6 on osaliselt toimivad — kogu süsteem eeldab täielikku Vahimeest aga see pole valmis.
  4. Pärandvõlg kasvab: 12+ priority=1 pending sõnumit (mõned Mai 8-st!), ENERGY-001/002/003 processing kuu aega. Süsteem ei tõmba "lahtisi lõime" kinni piisavalt kiiresti.
  5. pos_deep_memory 8656 kirjet, 2000+ lisandus <24h: re_distiller promote_l2 jookseb pidevalt. Mälu kasvab kontrollitamatult — kas kõik 8656 kirjet on kvaliteetsed? Kust teab?

🟢 RT3 — Fundamentaalne küsimus: kas Eirik OS keerukus on proportsionaalne?

Erapooletu vastus: JAH ja EI korraga.

JAH — keerukus on proportsionaalne, kuna:

  • 8656 Erki-spetsiifilised ärimälud (Vestman/Forestsense/NW/TimberTrace) ei eksisteeri kusagil mujal. Need on aastate ärikontekst — ei saa "lihtsalt importida" mem0-sse.
  • Multi-tool koordinatsioon (Claude Code + Cursor + Cowork + Vahimees + mälu-agent) ei ole ühegi olemasoleva alternatiiviga võimalik ilma olulise arhitektuuri ümberkirjutamiseta.
  • Forestsense äriprotsessid (TimberTrace/TMA/KPDC/Directo ETL, EUDR DDS, harvester OCR) vajavad domäänispetsiifilisi tööriistu — genericud alternatiivid ei kata.

EI — keerukus on ebaproportsionaalne, kuna:

  • 19 PR ühes päevas on mitte süsteemi probleem — see on kasutusintensiivsuse probleem. Süsteem ei saa testa nii kiiresti muutuvat konfiguratsiooni.
  • Vahimees K5 teeb tööd mida süsteem ise tekitab: Vahimees jälgib reegleid mida süsteem ise loob. Circular dependency.
  • Koordinaatori sessioonide arv (10/päev) on inimesele liiga palju jälgida. Erki ei suuda 10 sessiooni samaaegselt koordineerida.

Peamine järeldus: Eirik OS ei ole vale süsteem — see kasvab liiga kiiresti. Probleem ei ole arhitektuur, vaid muutuste tempo.

5

Strateegilised valikud Erkile

Valik A · Stabiliseerida ja jätkata

3 kriitilise kaitsemehhanismi implementeerimine + tempo distsipliin:

  • A1: Spawn fail-fast — >20 min ilma heartbeatita → auto-kill (M1 watcher laiend)
  • A2: PR keerukuse piirmäär — max 5 PR/nädal, max 3 koordinaatori sess/päev
  • A3: Tier 1 auto-restart PR #130 ASAP
  • A4: Zombie-sessioonide kill — M1 watcher >60 min failed → force-finish

Süsteem ON hea. Probleem on tempo, mitte arhitektuur. Neli kaitsmehhanismi võtavad 1 sessiooni ja fikseerivad 80% probleemidest.

⏱ Kulu: 1 sessioon (3-5h) · Riski: madal · Soovituslik ✓
Valik B · Lihtsustamine

Süsteemi arhitektuuri vähendamine:

  • Eemalda K3 messaging bus → Telegram-only
  • Asenda Tier 1 → mem0 ($249/kuu Pro)
  • Minimeeri K5 Watchdog → simple cron
  • Eemalda K2 GraphMemory → mitte kriitiline

Hoiatus: 8656 ärimälu kirjet kaob. mem0 Pro migration = ärimälu kadumise risk. K5 minimeerimine tähendab samade probleemide kordumist tulevikus.

⏱ Kulu: 2-3 nädalat · Riski: kõrge (mälukadumine)
Valik C · Tempo vähendamine

Ainult distsipliin — kood ei muutu:

  • Max 3 koordinaatori sessiooni/päev
  • Max 5 PR-i/nädal
  • Iga PR vajab 24h küpsetamisaega enne rakendamist
  • CLAUDE.md muudatused max 1×/nädal

Tegeleb RT2 juurpõhjusega (keerukuse spiral). AGA ilma A1-A4 kaitsemehhanismideta korduvad samad intsidendid.

⏱ Kulu: 0 (ainult distsipliin) · Riski: keskmine (ei eemalda tehnilisi haavatavusi)

Soovitus: Valik A + C kombinatsioon

Süsteemi arhitektuur on fundamentaalselt õige. 8656 äri-spetsiifiliste mälu-kirje, 51 skill-faili, K0-K5 LLM-agnostic 6-kihi arhitektuur — ühtegi alternatiivi ei eksisteeri mis kataks kõiki dimensioone.

Kuid 19 PR ühes päevas pole süsteem mis kukkus — see on operaator kes kihutas. H3 intsidenti, zombie sessioone ja ghost-sessioone ei tekitanud arhitektuur — neid tekitas PR #112 puudumine (juba rakendatav) + heartbeat kill puudumine (A1) + kasutustempo (C).

Konkreetsed 4 sammu: (1) A1: spawn fail-fast >20 min → auto-kill. (2) A3: PR #130 Tier 1 DEGRADED auto-restart ASAP. (3) A4: zombie-sessioonid >60 min failed → force-finish. (4) C: max 5 PR/nädal, max 3 sessiooni/päev.

"Probleem ei ole see et Eirik OS on liiga keeruline — probleem on et me muutsime seda liiga kiiresti. Süsteem vajab stabiliseerimisaega, mitte lammutamist."

Erki — sinu otsus

Red Team analüüs on selge: A+C kombinatsioon. Aga strategiline otsus on sinu.

A+C · Stabiliseerida + tempo vähendada (Soovituslik)
A only · Tehniline fix, tempo samaks
B · Lihtsustamine (mälukadumine risk)
Muu · Kirjuta oma valik