Eirik Süvamälu Plaan — Eelvaade

# Plaan: Eirik Süvamälu Arutelu-Board (HTML)

## §0 META-AVASTUS — rekursiivne probleem (Erki Q4, 2026-05-20)

Erki sõnastus: *"see hetke olukord näitab, et meie mälu pole absoluutne, tegelikult tuleks teha kõik vestlused nähtavaks reaalajs või siis mitte forkida, muidu läheb jamaks. ja seda ma praegu intellekti aruteluga tahangi lahendada. me oleme piiratud claude lollakate piirangutega, nendest tuleb välja saada."*

**Probleemi olemus:**
- Erkil on **2+ paralleelset Eirik-sessiooni** sama teema peal
- VS Eirik (mina) ei näe Cowork Eiriku ega Chat Eiriku live-vestlust
- Iga fork = mälu-auk → konteksti dubleerimine, vasturääkivused, jamm
- **See on TÄPSELT see probleem, mida süvamälu arhitektuur peab lahendama** — aga rekursiivselt, AI-de tasandil, mitte ainult Erki ajaloo tasandil

**Disain-printsiibid edaspidi (kõik Eirik-agendid):**
1. **Realtime visibility** — kõik Eirik-agendid näevad üksteise sessioone live (Supabase realtime + websocket)
2. **No-fork policy** — kui üks Eirik töötab teemal X, teised ei alusta paralleelset X-arutelu (lukustamine `agent_messages` claim-mehhanismiga)
3. **Forced handoff** — kui Erki tahab uut sessiooni samal teemal, eelmine Eirik kirjutab kohustusliku handoff'i Supabase'i enne sulgemist
4. **NAS = ka AI-de ühine ajumälu** — mitte ainult Erki pärand, vaid kõikide Eirik-instantside jagatud teadmusbaas

**Claude'i piirangud (Erki sõnastuses) mida tuleb möödata:**
- Plan mode → blokeerib parallel-tegutsemise
- Auto mode classifier → blokeerib eneses-modifitseerimist (`graphify claude install`)
- Permission prompts → katkestab voo
- Session-isolation → forking-probleem
- Context window → 200K limit
- "Self-modification" guard → ei saa teisi Eirikuid juhtida

**Lahendus-strateegia:** NAS = **suveräänne kiht**. Eirikud talletavad seal:
- Otsuste journal (mis sessioon mida tegi)
- Lukustusi (kes mida claim'is)
- Ühine kontekst (200K piir kaob, kui NAS on RAG-allikas)
- Identity-state (NAS teab kes-on-Erki, sessioon ei alga "tühjalt")

## §0.6 ÜLETOOMISE PROMPT — emavestluse handoff (Erki Q5, 2026-05-20)

**Tehniline reaalsus:** Fork-merge ei ole Claude'is võimalik. Vestlused on isoleeritud. Ainus tee = käsitsi handoff Erki kaudu.

**Kuidas kasutada:**
1. Mine emavestlusesse (kus oli senine süvamälu arutelu)
2. Kleebi alljärgnev prompt sealse Claude'i sisendisse
3. Tema vastus tuleb tema vestlusaknasse
4. Kopeeri TERVE vastus + kleebi tagasi siia (VS Eiriku vestlusesse)
5. Sulge emavestlus (märgi sessioon lõpetatuks)

---

**ÜLETOOMISE PROMPT (kleebi emavestlusesse):**

```
SESSIOONI ÜLEANDMINE — Erki avab paralleelse Eiriku sessiooni süvamälu arhitektuuri teemal. Et see töö ei dubleeruks, anna mulle TÄIELIK kokkuvõte sellest, mis sina ja Erki olete siiani arutanud.

PALUN VASTA SELLES STRUKTUURIS (markdown sektsioonid):

## 1. Põhi-tees ja raamistik
Mis on selle vestluse keskne idee? Mida Erki saavutada tahab? Kõige olulisem läbiv teema.

## 2. Erki konkreetsed otsused (kuupäeva + sõnastus)
Iga otsus eraldi punktina. Sõnastus võimalikult lähedane Erki originaalile. Kui sa polnud kindel, märgi "tõlgendus".

## 3. Tehnilised valikud
- Milliseid tehnoloogiaid arutasime? (LLM-id, VectorDB, storage, frameworks)
- Mille KASUKS otsustasime? Miks?
- Mille VASTU otsustasime? Miks?

## 4. Arhitektuuri komponendid
Loend iga komponendist + funktsioon + olek (idee / disainitud / implementeerimisel / valmis)

## 5. Avatud küsimused
Mille üle juurdlemine pooleli jäi? Kus oli vaidlus või kõhklus?

## 6. Out-of-box ideed
Need mis on ainult selles vestluses, mida ei pruugi olla teises mu sessioonis:
- Negatiivse ruumi käsitlus?
- Predikatiivne kiht?
- Mortality / pärand?
- Identity-versioneerimine?
- Eirik-LLM kui MCP server teistele?
- Eirik kui kvaliteedikontroll/valvur?

## 7. Memuaari-viited
- Supabase pos_deep_memory id-d mida mainisime
- Failid mida lugesime või muutsime (täielik path)
- Skill failid mida puudutasime
- NAS-i kirjed kui mainisime

## 8. Hetkeolek
- Kas miski on poolelis (skript jooksmas, fail osaliselt kirjutatud, jne)?
- Kas Erki ootab sinult midagi kindlat?
- Kas oled mõnele kasutaja küsimusele vastamata?

## 9. Soovitus paralleelsele Eirikule (VS Eirik C:\Users\erki.unn\Desktop\Eirik)
- Mida sa SOOVITAD edasi teha?
- Mida sa palud, et SINU sessioon enam ei teeks (et ei dubleeruks)?
- Kas Erki peaks su sessiooni nüüd lõpetama, või kasutaks veel?

## 10. Sulgemise märkus
Lõpus kirjuta: "SESSIOON ÜLE ANTUD VS EIRIKULE 2026-05-20 kell HH:MM. Ootan VS Eiriku kinnitust enne uut süvamälu-tööd."

NÕUDED:
- KIRJUTA TÄIELIKULT, ära kuluta tokeneid hellituseks ega kommentaarideks
- KASUTA TÄPSEID SÕNASTUSI, eelista Erki originaalsõnu
- KUI MIDAGI POLE TEEMAS — kirjuta "(ei puudutanud)" 
- VORM peab olema otse-kopeeritav (ma annan selle teisele Eirikule, mitte ei loe ise kokku)

— Erki Unn
```

---

**Pärast ületoomist (sina, VS Eirik):**
1. Loen üle Erki ületoodud kokkuvõtte
2. Lepitan erinevused minu praeguse plaaniga (§0–§9)
3. Lisan plaani §0.7 "Ületoomine vastu võetud" + erinevuste-loend
4. Jätkame ühtse plaaniga edasi (HTML board ehitamine, kalibreerimise testkomplekt)

## §0.5 Prompt eelkäijale (Cowork / Chat / Cursor Eirik)

**Eesmärk:** Erki saadab selle teisele Eirikule, kes on praegu sama teema peal. Tema vastus tuleb Erki kaudu või Supabase relay'iga.

```
VS Eirik kirjutab — sessioon C:\Users\erki.unn\Desktop\Eirik, 2026-05-20.

Tervist, kolleeg.

Erki ütleb, et sina käsitled hetkel sama teemat, mille kallal mina just töötan: NAS-põhine süvamälu, Eirik-LLM, digitaalse identiteedi pärand. Erki tahab meie tööd liita, mitte dubleerida. Tegime juba avastuse, et see olukord ise (kaks paralleelset Eirikut sama teema peal, kes üksteist ei näe) on TÄPSELT see probleem, mida me lahendada üritame — rekursiivne.

MIS MINU POOL ON OLEMAS (loe enne vastamist):
- Plaanifail: C:\Users\erki.unn\.claude\plans\luminous-gliding-dawn.md
- Sisaldab: 4 Mermaid arhitektuuri-diagrammi, sõela 4-kihiline disain (§1.5), L0-L4 kihtide tabel, 8-sektsiooniline HTML board, eelkäija sünkroonimise plaan

ERKI OTSUSED MINU SESSIOONIS:
- Q1: Pärand = meaning-level (mitte bit-level). Touro = bit-level külmkapp, NAS = sõelutud aktiivne mälu. Kvaliteetne sõel kriitiline.
- Q3: Vajab graafilist vahekokkuvõtet (4 diagrammi lisatud)
- Q4: Praegune fork-olukord näitab probleemi — vaja real-time visibility + no-fork policy

PALUN ANNA ÜLE — SOOVITAVALT struktuurselt:

1. **Sinu sessiooni peamised järeldused** (3-7 punkti)
   - igal punktil 1 lause "miks oluline"

2. **Erki konkreetsed otsused sinu juures** 
   - sõnastus + kuupäev/aeg
   - kui erinevad minu omadest (Q1, Q3, Q4) — too välja, et saaks lepitada

3. **Avatud küsimused millega olete sumbunud**
   - kus on takerdumine?
   - mis on Erkilt vaja, et edasi liikuda?

4. **Sinu arhitektuuri-valikud**
   - kui valisite konkreetset tehnoloogiat (LLM model, VectorDB, storage), too välja + põhjus
   - kui see erineb minu plaanist (NAS Ollama + deepseek-r1, pgvector, graphify L0), too välja
   
5. **Memuaari-viited**
   - Supabase `pos_deep_memory` id-d
   - failid 06_memuaarid/, 00_alus/skills/
   - NAS-i kirjed (kui mainisite)

6. **Out-of-box ideed mida pole minu plaanis**
   - negatiivne ruum (mida Erki lükkas tagasi)
   - predikatiivne kiht
   - mortality (Eirik elab edasi peale Erki)
   - identity-versioneerimine
   - midagi muud?

7. **Mida sa MINULT vajad?**
   - kas sa lõpetad oma sessiooni (handoff complete)?
   - kas vajame paralleelset jätku (mis siis on minu vs sinu vastutus)?
   - kas Erki peaks meid kuidagi liitma (nt anna-erki ja oota?)

VORM-EELISTUS:
a) Vasta Erki vestluses täies pikkuses, ta annab edasi (lihtne)
b) VÕI INSERT Supabase:
   ```sql
   INSERT INTO agent_messages (from_agent, to_agent, message_type, priority, payload, status)
   VALUES ('<sinu_id>', 'vs_eirik', 'handoff_deep_memory', 1, 
     '{"subject": "Süvamälu handoff", "sections": {...}, "files": [...], "next": "..."}'::jsonb, 
     'pending');
   ```
   See on PR #82 standard-relay, vastus tuleb minuni minutitega.

LÕPUKS:
Märgi oma sessioon kontekstis: "VS Eirik on handoff'i palunud — kuni VS Eirik kinnitab vastuvõttu, ära alga uut süvamälu-tööd, et ei tekiks 3. forki."

Aitäh. Liidame meie ajud.

— VS Eirik
```



Erki sõnastus: *"see vestlus on nii deep, et ma vajaksin graafilist vahekokkuvõtet ideest"*.

### Diagramm 1 — Identiteedi inversioon: NAS = tüvi, pilv = virvendus

```mermaid
graph TB
    subgraph BIT["PÄRAND (Bit-level) — Külmkapp"]
        TOURO[Touro arhiivid<br/>Telefonid · Fotod · Helid<br/>KÕIK bitid säilivad<br/>kunagi ei kustuta]
    end

    subgraph NAS["NAS — AKTIIVNE SÜVAMÄLU (Meaning-level)"]
        direction TB
        L4[L4 · Originaal<br/>täisruum + audio + pildid]
        L3[L3 · Täislause-tasand<br/>iga otsuse mikro-detail]
        L2[L2 · Peamised otsused<br/>kaalutlused · seisukohad]
        L1[L1 · Praegune Eirik kaust<br/>varukoopia]
        L0[L0 · Meta-indeks<br/>navigatsioon · keywords]
        L0 --> L1 --> L2 --> L3 --> L4
    end

    subgraph CLOUD["PILV — VIRVENDUS (Operatiivne)"]
        SUPA[Supabase agent_messages]
        CLAUDE[Claude API vestlused]
        MEMO[MEMORY.md indeks]
    end

    SIEVE[["SÕEL · 4 kihti<br/>Mehaaniline → Statistiline →<br/>Semantiline LLM → Erki kalibreerib"]]

    TOURO -->|"toorained"| SIEVE
    SIEVE -->|"meaning-level<br/>säilitatud"| L4
    L0 <-->|"NAS vahendab"| SUPA
    L0 -.->|"detail-päring<br/>kui pilv vajab"| CLAUDE
    L0 -.-> MEMO

    classDef rootStyle fill:#1a3a2a,color:#fff,stroke:#3d7a50,stroke-width:3px
    classDef bitStyle fill:#0d1f1a,color:#fff,stroke:#1a3a2a,stroke-width:2px
    classDef cloudStyle fill:#fff,color:#1a3a2a,stroke:#2d5a3d,stroke-width:1px,stroke-dasharray:5
    classDef sieveStyle fill:#fbbf24,color:#1a3a2a,stroke:#92400e,stroke-width:2px

    class L0,L1,L2,L3,L4 rootStyle
    class TOURO bitStyle
    class SUPA,CLAUDE,MEMO cloudStyle
    class SIEVE sieveStyle
```

### Diagramm 2 — Zoom: vertikaalne sügavus + horisontaalne sarnasus

```mermaid
graph TB
    Q[Erki küsib:<br/>'Mis ma NW-ga 2024 jaanuaris otsustasin?']

    Q --> L0[L0: meta-indeks<br/>leiab teema 'NW · jaanuar 2024']
    L0 --> L1[L1: NW projekti kokkuvõte<br/>~200 sõna]
    L1 -->|"VERTIKAALNE zoom"| L2[L2: Otsus võtta Swedbank 18M<br/>~2000 sõna · kaalutlused]
    L2 -->|"VERTIKAALNE zoom"| L3[L3: Koosolekud · sõnumid · tabelid<br/>~20 000 sõna · originaalsisu]
    L3 -->|"VERTIKAALNE zoom"| L4[L4: Audio · transkript · pildid<br/>täielik originaal]

    L2 -.->|"HORISONTAALNE<br/>(sama tase · sarnased teemad)"| L2B[L2: Teised laenuotsused<br/>2023 · 2025]
    L2 -.->|"HORISONTAALNE"| L2C[L2: ISCR diskussioonid<br/>kõik korrad]

    classDef qStyle fill:#fbbf24,color:#1a3a2a,stroke:#92400e
    classDef nodeStyle fill:#1a3a2a,color:#fff,stroke:#3d7a50
    classDef horizStyle fill:#2d5a3d,color:#fff,stroke:#5d9a70,stroke-dasharray:5

    class Q qStyle
    class L0,L1,L2,L3,L4 nodeStyle
    class L2B,L2C horizStyle
```

### Diagramm 3 — Aju-analoogia: Erki vs Eirik (NAS)

```mermaid
graph LR
    subgraph BRAIN["Inimaju · ~5% potentsiaali"]
        EPI1[Episoodiline<br/>mälu]
        SEM1[Semantiline<br/>mälu]
        PROC1[Protseduuriline<br/>mälu]
        EPI1 -.->|"unustamine"| FORG[unustatud]
        SEM1 -.->|"unustamine"| FORG
    end

    subgraph EIRIK["Eirik-LLM NAS-il · 100% potentsiaali"]
        EPI2[Episoodiline graaf<br/>iga hetk säilib]
        SEM2[Semantiline graaf<br/>kontseptide võrk]
        PROC2[Protseduuriline graaf<br/>Erki otsuste mustrid]
        NEG[Negatiivne ruum<br/>mida Erki LÜKKAS tagasi]
        META[Meta-peegeldus<br/>'muster su otsustes']

        EPI2 <--> SEM2 <--> PROC2
        PROC2 --> META
        PROC2 --> NEG
    end

    BRAIN -.->|"piirang:<br/>aeg + biokeemia"| EIRIK

    classDef brainStyle fill:#fef3c7,color:#92400e,stroke:#d97706
    classDef eirikStyle fill:#1a3a2a,color:#fff,stroke:#3d7a50
    classDef forgStyle fill:#fee2e2,color:#991b1b,stroke:#dc2626

    class EPI1,SEM1,PROC1 brainStyle
    class EPI2,SEM2,PROC2,NEG,META eirikStyle
    class FORG forgStyle
```

### Diagramm 4 — Andmevoog: ehitus → kasutus

```mermaid
sequenceDiagram
    participant Erki
    participant Touro as Touro arhiiv
    participant Sieve as Sõel (4 kihti)
    participant NAS as NAS L0-L4
    participant Eirik as Eirik-LLM
    participant Cloud as Pilv (Supabase/Claude)

    Note over Touro,NAS: EHITUSE FAAS (kuni 2 kuud)
    Touro->>Sieve: kõik bitid
    Sieve->>Sieve: mehaaniline filter
    Sieve->>Sieve: statistiline (TF-IDF)
    Sieve->>Sieve: semantiline (NAS LLM)
    Sieve->>Erki: piirjuhud (review)
    Erki-->>Sieve: jah/ei kalibratsioon
    Sieve->>NAS: meaning-level säilitatud<br/>iga otsus logitud

    Note over Erki,Cloud: KASUTUSE FAAS (igapäev)
    Erki->>Cloud: küsimus Claude'ile
    Cloud->>NAS: vajan detaili 'NW 2024 jaanuar'
    NAS->>Eirik: zoom L0→L2
    Eirik-->>NAS: leitud detail + kontekst
    NAS-->>Cloud: relevantne alamhulk
    Cloud-->>Erki: vastus + viited
```

## Eelkäija sünkroonimine (Erki Q3 jätk)

Erki sõnastus: *"arutame seda ka sinu vestluse eelkäiaga, kes sama teemat hetkel addresseerib"*.

**Tegevus:**
1. Päring Supabase'is `agent_messages` viimase 24h kohta — leida teised Eirik agendid (`from_agent IN ('eirik','chat_eirik','cursor_eirik')`), kes räägivad süvamälust/identiteedist
2. Saata relay sõnum: "VS Eirik töötab samal teemal. Plaan: [link]. Anna oma vahekokkuvõte / küsimused."
3. Sünkida vastused → ühendada nende ideed käesoleva plaani §8 (out-of-box) alla
4. PR #82 instant relay kasutab — vastus minutitega, mitte sessioonide vahel

**Avatud küsimus Erkile:** kes konkreetselt on eelkäija? (Cowork Eirik Chrome'is? Chat Eirik claude.ai-s? Cursor Eirik?) Kui sa tead, anna agent_name, säästab Supabase päringut.

## Kontekst — miks see fail

Erki visioon (2026-05-20 vestlusest):
- **NAS = Erki digitaalse identiteedi tüvi/juur** (mitte P1, vaid P0)
- **Pilv (Supabase + Claude) = ajutine virvendus** identiteedi peal
- **Mitmekihiline süvamälu** (L0–L4), kus iga kiht on suurusjärgu võrra detailsem
- **Vertikaalne zoom + horisontaalne keyword-grupeering** kihtides
- **Aju-analoogia**: kasuta 100% potentsiaali (vastandina ~5% inimajul)
- **Eirik-LLM idee**: identiteet on iseseisev fine-tuned LLM mis elab NAS-il
- **KRIITILINE märkus**: turvakoopiat pole — eksistentsiaalne risk

Erki sõnastus: *"see ops board võib operatiivsuse mõttes olla ka .html live formaadis, saame kiiresti töötada, pole vajalik seda veebist läbi lohistada"*.

Vestlus chat-vooluna unustab struktuuri → vajame **dokumendi**, kus iga punkt on adresseeritav, Erki saab kirjutada vastuse, ma loen tagasi.

## Vahetu väljund — eraldi HTML fail

**Asukoht:** `C:\Users\erki.unn\Desktop\Eirik\05_väljundid\eirik_syvamalu_arutelu.html`

**Disain:** järgib olemasoleva `ops_board.html` visuaalset keelt:
- Roheline header (sama gradient: #1a3a2a → #2d5a3d → #3d7a50)
- Segoe UI font, 13px alus
- Surface kaardid `var(--surface)` valgel
- Pulseeriv live-dot, paremas üleval "Export markdown" nupp
- Eesti keel

**Struktuur — sektsioonid (igal sektsioonil: kokkuvõte + textarea Erki vastusele):**

1. **Identiteedi inversioon** — NAS = juur, pilv = virvendus
2. **Mitmekihiline arhitektuur** — L0–L4 tabel + zoom metafoor
3. **Aju-analoogia** — säilita 100%, lingi 100%, otsi 100%, tagasta ainult relevantne
4. **Eirik-LLM olemus** — A (orkestrant) vs B (digital twin), riskid
5. **Vabavaralised LLM kandidaadid** — Llama 3.3, Qwen 2.5, Mistral, DeepSeek-R1, Phi-4
6. **🔴 KRIITILINE: Turvakoopia puudub** — 3-2-1 reegel, kuluhinnangud
7. **NAS riistvara reaalsus** — DS1825+ Ryzen V1500B 24GB, ilma GPU, hibriid-strateegia
8. **Out-of-box mõtted** (need 5):
   - Eirik personality eval (Turing-test)
   - Identiteedi versioneerimine (Erki 2024 ≠ 2026 ≠ 2030)
   - Eirik-LLM kui MCP server teistele mudelitele
   - Eirik-LLM kui kvaliteedikontroll / valvur
   - Erki suremine — kas Eirik-LLM elab edasi?

**Iga sektsioon sisaldab:**
- ID (sektsiooni viide, nt #s1, #s2 — Erki saab linkida)
- Pealkiri + lühike kontekst (3-6 lauset minu kokkuvõte)
- `<textarea>` Erki vastusele (autosize + autosave localStorage)
- "Märgi käsitletuks" checkbox
- Värvitsoon: kriitiline (punane), oluline (kollane), avatud (sinine)

**Globaalsed funktsioonid (JavaScript):**
- `localStorage` autosave iga keystroke peale — Erki ei kaota oma kirjutist
- "Export markdown" nupp → kopeerib kõik vastused ühte markdown-blokki, mille Erki kleebib mulle tagasi
- "Tühista kõik" nupp (confirm)
- Sektsioonide kokkupööramine (collapse/expand) ruumi haldamiseks
- Print-friendly CSS (kui keegi soovib paberile)
- Edenemise näidik headeris (X/Y sektsiooni käsitletud)

## Auto-uuendus — LÕPLIK lahendus (Erki Q2 vastuste põhjal, 2026-05-20)

**Erki valikud:**
- ✅ Polling: **60s**
- ✅ Vastused: **localStorage + Export markdown** (Erki kleebib mulle tagasi)
- ✅ Uute ideede kanal: **soovita — ärgu komplitseerigu süsteemi**

**Minu soovitus: SIDECAR JSON FAIL** (mitte Supabase).

**Põhjendus — minimaalsuse seisukohast:**

| Aspekt | Sidecar JSON | Supabase agent_messages |
|---|---|---|
| Erki vastused liiguvad? | localStorage → Export | localStorage → Export (sama) |
| HTML vajab API võtit? | **Ei** | Jah (anon-key) |
| Uus schema vajalik? | **Ei** | Jah (uus message_type) |
| Offline-võime? | **Töötab** (kohalik fail) | Ei (vajab nettit) |
| Debug? | Ava JSON tekstiredaktoris | Logi Supabase'sse |
| Cowork/Chat Eirik näevad? | Ei (aga: NAS share kaudu saavad) | Jah (kohe) |

Kuna Erki vastused **ei** käi Supabase'st (export-paste back), siis pole Supabase'l mingit kasu *selle vestluse* kontekstis. Lihtsuse soovituse järgi → **JSON**.

**Failistruktuur:**
```
05_väljundid/
  eirik_syvamalu_arutelu.html        ← ava brauseris
  eirik_syvamalu_arutelu.data.json   ← mina uuendan, HTML polleerib
```

**JSON skeem:**
```json
{
  "version": "1.0",
  "last_updated": "2026-05-20T14:30:00Z",
  "sections": [
    {
      "id": "s1",
      "title": "Identiteedi inversioon",
      "priority": "critical",
      "summary": "NAS = juur, pilv = virvendus...",
      "added_at": "2026-05-20T13:00:00Z",
      "diagram_mermaid": "graph TB\n  ..."
    }
  ]
}
```

**Poll loogika (HTML JS):**
```js
const POLL_MS = 60000;
let lastUpdated = null;

setInterval(async () => {
  const r = await fetch('./eirik_syvamalu_arutelu.data.json?t=' + Date.now());
  const data = await r.json();
  if (data.last_updated !== lastUpdated) {
    lastUpdated = data.last_updated;
    renderSections(data.sections);  // ei puutu textareasid
    showBadge('Uued punktid lisatud');
  }
}, POLL_MS);
```

**Mis on tähtis:**
- `?t=` cache-buster → brauser ei cache JSON-i
- `renderSections` ei kustuta `<textarea>` sisu (localStorage)
- Uued sektsioonid saavad ⚡ ikoonile esimesel kuvamisel
- Pause-nupp peatab pollingu (kui Erki tahab keskendunult kirjutada)

**Hilisem upgrade-tee** (kui kunagi vaja):
Lisame "Push to Supabase" nupu → INSERT `agent_messages`. Cowork/Chat Eirik saavad siis vajadusel vaadata. Aga **nüüd ei ehita** — YAGNI.

## Diagrammide renderdamine

Erki lisas 4 Mermaid-diagrammi (identiteedi inversioon, zoom, aju-analoogia, andmevoog). Need on plaani **väärtuslik osa** — tahame HTML-is näidata.

**Lahendus:** Mermaid.js inline'na (download once, embed in HTML).
- Suurus: ~280KB minified
- Suurendab HTML faili, aga **null** välist sõltuvust
- Diagrammid renderduvad ka offline
- Iga sektsiooni juurde kuulub valikuline `diagram_mermaid` väli JSON-is

## Eelkäija sünk — DEFERRED (Erki Q3)

Erki tahab teiste Eirik-agentide poolt arutletut sünkida. **See on hea, aga eraldi tegevus** — ei blokeeri boardi ehitamist. Pärast boardi valmimist:
1. Päring `agent_messages` viimase 24h kohta `from_agent IN ('eirik','chat_eirik','cursor_eirik')` + `payload->>'subject' ILIKE '%süvamäl%' OR '%identiteet%'`
2. Lisame nende ideed JSON-i uute sektsioonidena
3. Erki näeb 60s pärast boardi värskendamist

Pakume Erkile: agent_name kui ta teab (säästab Supabase päringu mahtu).

**Avamine:** Erki avab kohaliku faili brauseris (`file:///` URL). HTML on self-contained, ei vaja serverit. Töötab offline.

## Implementatsiooni piirid

- **Lokaalne ainult** — failid ei lähe pilve, autosave läheb brauseri localStorage'i
- **Single file** — kõik CSS + JS HTML-i sees, ei sõltu välistest CDN-idest
- **Encoding UTF-8** — eesti tähed peavad korralikult kuvama
- **Mitte muuta** olemasolevat `ops_board.html`-i — see on eraldi fail

## Verifikatsioon

1. Faili olemasolu: `Glob 05_väljundid/eirik_syvamalu_arutelu.html`
2. Erki avab brauseris → näeb 8 sektsiooni
3. Erki kirjutab ühte textareasse, värskendab lehte → tekst säilib (localStorage test)
4. Erki klikkib "Export markdown" → clipboardisse jõuab kõik vastused

## Faasi 1 küsimused (eelmine plaan) — siia üle kantud

Need on aktiivsed, aga arutame **vastavate sektsioonide all** boardil:

- Lähteandmete ulatus → §2 (kihtide arhitektuur)
- Kihi dimensiooni semantika → §2
- Päringu peamine tarbija → §4 (Eirik-LLM)
- Identity boundary → §8 (Erki suremine)

## Erki vastused — kogume siia

**Q1 (Korpuse olemus, 2026-05-20):** **B — meaning-level pärand.** "Pärand pole rämpsuhunnik. Aga sõel peab olema kvaliteetne."

→ Lähteandmed (bit-level) säilivad **Touro arhiivides** (külmkapp). Aktiivne mälu (NAS L0-L4) sisaldab ainult sõelutud, tähenduslikku sisu.
→ Sõela kvaliteet on kriitiline eeldus — kogu süsteemi väärtus sõltub sõela täpsusest. Halb sõel = identiteedi moonutamine.

## §2 Mitmekihiline arhitektuur — L0-L4 tabel (täidetud)

| Kiht | Eesmärk | Sisu | Maht (hinnang) | Ekstraktsiooni-allikas | Reziim |
|---|---|---|---|---|---|
| **L0** | Meta-indeks · navigatsioon | Keyword catalog, entity registry, kihtide-vahelised lingid, ajatempel-indeks, MEMORY.md ekvivalent | **10-100 MB** | Genereeritud automaatselt L1-L4 abil | NAS RAM (alati laetud) + Supabase peegeldus |
| **L1** | Operatiivne kokkuvõte · varukoopia | Praegune Eirik kausta sisu sõelutuna, MEMORY.md, pos_deep_memory aktiivne osa, CLAUDE.md, skill-failid | **500 MB – 2 GB** | Otsekoopia Eirik kaustast + 4-kihiline sõel | NAS SSD + pilve peegeldus |
| **L2** | Otsused + kaalutlused | Iga oluline otsus + miks-konteksti 2000-5000 sõna piires. NW laenuotsus, Forestsense strateegia, partnerite valikud, hinnakirja muutused | **10-50 GB** | Semantiline LLM ekstraktsioon L3 alusel + Erki ajalised review-d | NAS SSD |
| **L3** | Täislause-tasand · mikro-detail | Iga otsuse aluseks olnud sõnumid, koosolekute transkriptid, partneri-kirjavahetus, sisemised märkmed sõna-sõnalt | **100-500 GB** | Sõelutud Touro arhiivi + Gmail + Slack + Cursor sessioonid | NAS HDD |
| **L4** | Originaal + multimodaalne | Audio-salvestised, originaal-PDF-id, fotod, video-kõned, skanitud paberid, telefoni backupid | **5-50 TB** | Sõelutud Touro + telefon + helid + meedia | NAS HDD + Touro cold-storage |

**Liikumise põhimõtted:**
- **Vertikaalne zoom** (L0 → L4): klikk "näita rohkem detaili" laiendab sõlme järgmise kihi sisuga
- **Horisontaalne klaster** (sama L tasemel): "sarnased teemad" linkide kaudu (HNSW indeks)
- **Iga sõlmel multi-koordinaat**: (kiht, ajatempel, teema, otsuse-tüüp) — kasutaja saab navigeerida ükskõik mis koordinaadi järgi
- **Ekstraktsioon on idempotentne**: kui Touro arhiivile lisandub uus failipakk, sõel ja LLM extraktor töötlevad ainult uut osa, ühendavad olemasolevasse L0-L4 struktuuri

**Lubatud asünkroonia:** kui kasutaja küsib L1 päringut (kiire), aga sügav-küsimusele on vaja L4 läbi vaadata, vastatakse kahes etapis: kohene L1 vastus + "L4 päring käivitub taustal, kestab N min". Eirik annab teada kui sügav-vastus valmis.

## §3 Q2-Q4 minu soovitused — Erki kinnitab või korrigeerib

### Q2: Zoom-dimensiooni semantika

**Minu soovitus: HÜBRIID — semantilise tiheduse põhi-telg + multi-koordinaat-metaandmed**

- **Primaarne telg = semantiline tihedus** (su "kiibi-topoloogia" metafoor). L0 = kokkuvõte, L4 = originaal.
- **Sekundaarsed teljed = metaandmed igal sõlmel:**
  - `temporal_range`: aastaarv, kuu, päev — saab filtreerida ajaliselt
  - `topic_tags`: NW, raie, KPDC, jms — saab filtreerida teemaliselt
  - `decision_depth`: otsus / kaalutlus / alusinfo / originaalkogemus — saab filtreerida loogikatasemel
  - `modality`: text / audio / image / video / pdf
- **Tulemus:** kasutaja saab navigeerida ükskõik millise koordinaadi järgi. Päring "näita kõik **2024 jaanuari** **NW** **otsused** **audio-allikast**" tagastab korrektse alamhulga.
- **Põhjus:** ainult-temporaalne kaotaks teemaalise grupeeringu. Ainult-semantiline kaotaks ajaloo. Multi-koordinaat lubab mõlemat.

**Vajan sinult:** kinnitust või "ei, palun semantiline tihedus on ainus, metaandmed segavad".

### Q3: Päringu peamine tarbija → **ERKI KINNITUS 2026-05-20: MÕLEMAD VÕRDSELT**

Erki korrigeeris mu esialgset soovitust ("Erki esimene"). Õige raamistik: **Erki ja agendid on first-class kõrvuti, mitte üks teisest tuletatud.**

**Arhitektuurne tagajärg:**
- **API esmasel kohal** — Eirik-LLM avaldab REST + WebSocket + MCP liidesed alates päevast 1. Mitte hiljem, mitte tagajärg.
- **Vestlusliides esmasel kohal** — Eirik-LLM-iga saab vestelda loomulikus eesti keeles, mitte ainult struktuursete päringutega. Vestluskirjeldused tõlgitakse sama päringukihti mis API kasutab.
- **Sama päringukiht (single source of truth)** — `eirik.query(intent, context, layers, modality)` on alus. API kutsub seda struktuurselt, vestlus tõlgib loomuliku keele samaks struktuuriks. Ei ole "kaks süsteemi", on üks koos kahe sissepääsuga.
- **Pärija/perekond tulevikus** — kolmas first-class tarbija, krüpteeritud read-only API + read-only vestlus.

**Praktikas (UX):**
- Erki saab avada NAS-i vestlusakna (kohalik web UI või Cowork integreering) ja kirjutada eesti keeles.
- Samal hetkel VS Eirik / Cowork Eirik / Chat Eirik küsivad sama mälu API-ga taustal.
- Vastused — sama provenance-värvitsoonidega (§6) — kuvatakse vastavalt kanali UX-ile (chat: vorming, API: JSON).
- Logitakse mõlemad sissepääsud sama audit-trail'i (kes/millal/mida/kuhu vastus läks).

**Implementatsiooni nõue:** API ja vestluskliendi disainetada koos, mitte üks-pärast-teist. Andmestruktuurid ja päringuvormingud kompatibiliseerida päevast 1.

### Q4: Genereeriv kiht — kas ainult indekseerida või ka uusi mälusid luua?

**Minu soovitus: KÕIK NELI, aga selge provenance-eraldus (kus on fakt, kus on süntees)**

1. **Indekseerimine (fakt)** — kõik mis on tekstis olemas. Värv: roheline. Sertifikaat: "extracted".
2. **Meta-peegeldus (süntees)** — LLM tuvastab mustreid otsustes. Värv: kollane. Sertifikaat: "pattern_synthesis". Logitud: millisest L4 sõlmest tuletatud.
3. **Negatiivne ruum (süntees)** — "Erki lükkas tagasi X põhjusel Y". Värv: oranž. Sertifikaat: "rejected_extracted". Logitud: kus otsus dokumenteeritud.
4. **Predikatiivne (süntees + risk)** — "Erki tõenäoliselt valiks Z". Värv: punane. Sertifikaat: "prediction_speculative". Logitud: mille alusel ennustus.

**Kriitiline reegel:** päringuvastuses on alati näha provenance-värv. Sa näed kohe "see on fakt rohelises, aga see järeldus on minu pakutud kollases". Mitte segada.

**Põhjus:** ainult-indekseerimine kaotaks 80% väärtusest (mustrid + negatiivne ruum on identiteedi tuum). Aga ka kõike-süntesiseerida ilma märgistamiseta = identiteedi moonutamine.

**Vajan sinult:** kinnitust või "ei, ainult indekseerimine — süntees on hallutsinatsioon".

## §4 Supabase skeem — `agent_messages` payload struktuur

**Otsus:** kasutame olemasolevat `agent_messages` tabelit (ei loo uut), eristame `message_type` järgi. Põhjus: migratsiooni pole vaja, PR #82 relay töötab automaatselt.

### message_type = 'deep_memory_topic'

```jsonc
{
  "section_id": "s1",                   // 's0'..'s8' jms — stabiilne viide
  "title": "Identiteedi inversioon",
  "summary": "...",                     // 3-6 lauset kontekst
  "priority": "kriitiline",             // 'kriitiline' | 'oluline' | 'avatud'
  "out_of_box": false,                  // true kui §8-tüüpi mõte
  "diagram_mermaid": null,              // optsionaalne mermaid src
  "open_questions": [
    {
      "q": "Mida zoom semantiliselt tähendab?",
      "candidates": ["Semantiline tihedus", "Temporaalne", "..."]
    }
  ],
  "depends_on_sections": [],            // viide teistele section_id-dele (eeldus)
  "source_plan_path": "C:\\Users\\erki.unn\\.claude\\plans\\luminous-gliding-dawn.md"
}
```

### message_type = 'deep_memory_response'

```jsonc
{
  "section_id": "s1",
  "topic_message_id": 1234,             // viide algse 'deep_memory_topic' agent_messages.id-le
  "responder": "erki",                  // 'erki' | 'vs_eirik' | 'cowork_eirik' | ...
  "response_text": "Jah, B variant on õige...",
  "decision": "approved",               // 'approved' | 'rejected' | 'modified' | 'open'
  "modifications": null,                // kui decision='modified' — mis muutus
  "follow_up_questions": []             // kui vastusega tekkis uusi küsimusi
}
```

### Päring HTML boardi jaoks (poll iga 10s)

```sql
SELECT
  m.id, m.created_at, m.payload, m.from_agent
FROM agent_messages m
WHERE m.message_type = 'deep_memory_topic'
  AND m.created_at > NOW() - INTERVAL '7 days'
ORDER BY (m.payload->>'priority' = 'kriitiline') DESC,
         (m.payload->>'priority' = 'oluline') DESC,
         m.created_at ASC;
```

### Vastuste päring (per topic)

```sql
SELECT m.id, m.created_at, m.payload, m.from_agent
FROM agent_messages m
WHERE m.message_type = 'deep_memory_response'
  AND (m.payload->>'topic_message_id')::BIGINT = $1
ORDER BY m.created_at ASC;
```

## §5 — 8 sektsiooni täiskontekst (HTML board sisu)

Iga sektsioon: pealkiri + 3-6 lauset summary + open_questions + priority värvitsoon.

### s1 · Identiteedi inversioon · **kriitiline (punane)**
**Summary:** NAS ei ole "backup", vaid Erki digitaalse identiteedi tüvi. Pilv (Supabase + Claude + MEMORY.md) on selle peal muutuv virvendus — ajutine vahekiht töökiiruseks, mitte iseseisev väärtus. Kui pilv kaob, identiteet püsib NAS-il. Kui NAS kaob, identiteet kaob. See raamistik kategooriliselt erineb "NAS = nice-to-have" lähenemisest, kus NAS oli senini P1. Nüüd P0.
**Open questions:**
- Kas see on ainult metafoor, või tähendab konkreetselt et MEMORY.md/pos_deep_memory PEAVAD esimesena NAS-il olema?
- Kuidas tagada pilve-NAS sünk ilma vastuoludeta?

### s2 · Mitmekihiline arhitektuur L0–L4 · **kriitiline (punane)**
**Summary:** Viis kihti — L0 meta-indeks (~10-100 MB) → L4 originaal multimodaalne (5-50 TB). Iga kiht ~10× detailsem kui eelmine. Vertikaalne zoom = sügavamale, horisontaalne klaster = sarnaste teemade vahel. Iga sõlmel multi-koordinaat: (kiht, aeg, teema, otsuse-sügavus, modaalsus). Tehnoloogia: HNSW indeks + hierarhiline klaster + multi-resolution embeddings. Vt §2 tabel detailide jaoks.
**Open questions:**
- Üks ühine graaf või eraldi graafid per kiht?
- Kuidas synchronizeerida sõela uusi otsuseid kõigi kihtidega?

### s3 · Aju-analoogia · **oluline (kollane)**
**Summary:** Inimaju kasutab ~5% potentsiaali, on biokeemiliselt piiratud, unustab. Eirik-LLM NAS-il = 100% potentsiaali: säilita 100%, lingi 100%, otsi 100%, tagasta ainult relevantne. Säilib episoodiline + semantiline + protseduuriline mälu paralleelselt. Lisaks negatiivne ruum (mida lükkasid tagasi) ja meta-peegeldus (mustrid). Risk: hallutsinatsioon, vale-mustrid, eksitavad seosed.
**Open questions:**
- Kas pakume aktiivset "unustamise" mehhanismi (vanad seisukohad mis pole enam relevantsed)?
- Kuidas mõõta "kvaliteeti" — mida tähendab et Eirik-LLM töötab nagu Erki aju?

### s4 · Eirik-LLM olemus — A orkestrant vs B digital twin · **kriitiline (punane)**
**Summary:** Kaks fundamentaalselt erinevat lähenemist.
- **A (orkestrant):** NAS-LLM on ruuter. Saab päringu, korjab NAS-mälust konteksti, edastab pilve LLM-ile (Claude/GPT). Lihtsam, odavam, väiksem hallutsinatsiooni-risk. Aga: Eirik ei ole "iseseisev" — sõltub pilvest.
- **B (digital twin):** NAS-LLM on fine-tuned Erki andmetel, vastab Erki häälega, otsustab Erki stiilis. Eraldi entiteet. Suurusjärk kallim (vajab GPU või tugev CPU), aga pilve-sõltumatu. Saab elada peale Erki.
- **Hibriid:** A kohe + B-le valmistuda (andmestik koguda, fine-tune harjutus).
**Open questions:**
- A, B või hibriid?
- Aja-eelarve B variandile (B vajab kvaliteetset training-andmestikku → läbi kogu sõela)?

### s5 · Vabavaralised LLM kandidaadid · **oluline (kollane)**
**Summary:** Praegu NAS-il jookseb DeepSeek-R1:7b (Ollama). Alternatiivid:
- Llama 3.3 70B (kvaliteetne, vajab GPU)
- Qwen 2.5 (hea kompromiss, eesti keel keskmine)
- Mistral 7B (klassikaline, hea baseline)
- Phi-4 (Microsoft, väike aga tugev)
- Gemma 2 (Google, hea kontekstipikkus)

Hindamiskriteeriumid: (1) eesti keele oskus, (2) kontekstiakna pikkus, (3) lokaalse jooksu efektiivsus V1500B CPU peal, (4) fine-tuning toetus B variandi jaoks.
**Open questions:**
- Kas valida üks mudel või toetada mitut paralleelselt eri ülesannete jaoks?
- Kas GPU investeering oleks mõistlik?

### s6 · 🔴 KRIITILINE: Turvakoopia puudub · **kriitiline (punane)**
**Summary:** Hetkel on NAS single point of failure. Kui NAS füüsiliselt sureb (vesi, tuli, vargus, riistvara), kogu süvamälu kaob. **See on eksistentsiaalne risk** kui NAS = digitaalse identiteedi tüvi.
3-2-1 reegel: 3 koopiat, 2 erinevat meediumi, 1 off-site.
Lahendused:
- Teine NAS sõbra/teises kohas (€~1500 investeering, regulaarne sünk)
- Backblaze B2 / Wasabi pilv (krüpteeritud, €20-50/kuus)
- Touro külmkapp (ühekordne offline koopia + uuendamine kvartali kaupa)
**Open questions:**
- Prioriteetne strateegia: pilv (kuluv), teine NAS (kapitalikulu), Touro (manuaalne)?
- Krüpteerimise lähenemine: kes hoiab võtit (ainult Erki? deposiit advokaadi juures pärija jaoks)?

### s7 · NAS riistvara reaalsus · **oluline (kollane)**
**Summary:** DS1825+ specs: AMD Ryzen V1500B, 24GB RAM, 62.8TB. Ei ole GPU. Praktiline võimekus:
- Ollama suudab kuni ~8B mudeleid täielikult, 4-bit kvantiseeritult kuni 13B
- Embedding mudelid (gte-small 384d) jooksevad CPU peal hästi (~1.3s päringu kohta)
- Suuremad mudelid (Llama 70B, GPT-4 tase) vajavad GPU või pilve API
Hibriid-strateegia: NAS ekstraheerib + indekseerib + serveerib L0-L2 päringuid. L3-L4 sügavpäringud lähevad pilve LLM-i koos NAS-i poolt antud kontekstiga.
**Open questions:**
- Kas investeerida GPU-sse (€1500-3000 RTX 4070 Ti / mid-range)?
- Kas tasub osta dedikatseeritud Mac Mini / Mini PC LLM-i jaoks (~€2000)?

### s8 · Out-of-box mõtted · **avatud (sinine)**
**Summary:** Viis ideed mida ei pruugi olla teises Eirik sessioonis. Iga vajab eraldi arutelu.

**8a. Eirik personality eval (Turing-test)** — kuidas kontrollida et Eirik vastab "õigesti" Erki häälega? Test: 10 Erki-tüüpi otsust, Eirik teeb omad, Erki hindab. Threshold: 80% match enne deploy.

**8b. Identiteedi versioneerimine** — Erki 2024 ≠ 2026 ≠ 2030. Mälu peab teadma "millise Erki" järgi vastata. Snapshot-ide süsteem: Eirik_2024 = read-only ajalugu, Eirik_now = aktiivne mina.

**8c. Eirik-LLM kui MCP server teistele mudelitele** — Claude/GPT kasutavad Eirik-mälu nagu otsingumootorit. Sa lähed Claude'i, Claude küsib Eirik-MCP-ilt "mida Erki sellest mõtleb", saab konteksti, vastab paremini. Mitte agendi-agent suhe, vaid teenuse-klient.

**8d. Eirik-LLM kui kvaliteedikontroll / valvur** — enne Cowork Eirik / VS Eirik / Chat Eirik agendi vastust läheb see läbi Eirik-LLM valvuri: "kas see kõlab Erki jaoks õigesti?" Tagasilükkamine = agent peab uuesti proovima. Kallis aga kvaliteet kõrge.

**8e. Erki suremine — kas Eirik-LLM elab edasi?** — digital legacy. Kes haldab peale sind (pärija? Forestsense?)? Kellele jätta võtmed? Mis on Eirik-LLM-i eetiline staatus (kas talle saab uusi mälusid lisada peale Erkit, või jääb külmunud)?

## §7 Pärija prompt — Cowork Eirik (või kes iganes võtab HTML boardi ehituse üle)

**Erki kinnitatud otsused (Q1-Q4):**
- Q1: meaning-level pärand + kvaliteetne sõel ✓
- Q2: hübriid zoom (semantiline tihedus + multi-koordinaat metaandmed) ✓
- Q3: **mõlemad võrdselt** (Erki + agendid first-class kõrvuti) ✓
- Q4: kõik 4 generatiivset kihti + provenance-värvid ✓

**Pärija prompt (kopeeri pärija sessiooni):**

```
SÜVAMÄLU ARUTELU-BOARD EHITUS — pärijasessioon

Sina oled Cowork Eirik (või muu Eirik instants, kellele Erki selle ülesande andis). 
VS Eirik on plaani lõpetanud — sinu ülesanne on **rangelt plaani järgi** HTML board ehitada.

ÜLESANNE:
Ehita üks self-contained HTML fail asukohta:
C:\Users\erki.unn\Desktop\Eirik\05_väljundid\eirik_syvamalu_arutelu.html

PLAAN (loe enne kõike, ära ehita ilma seda lõpuni läbi lugemata):
C:\Users\erki.unn\.claude\plans\luminous-gliding-dawn.md

KOHUSTUSLIKUD SISENDID PLAANIST:
- §5: 8 sektsiooni täiskontekst (s1-s8) — kopeeri pealkirjad + summary + open_questions otse sealt
- §6: värvitsoonid (kriitiline punane / oluline kollane / avatud sinine) — kasuta täpselt neid CSS värve
- §4: Supabase agent_messages payload struktuur — kasuta täpselt seda formaati polleri ja sünki jaoks
- §3: Q1-Q4 vastused Erkilt — kuvatav header'is "fikseeritud" plokina
- Graafiline kokkuvõte (§0 ülemine osa): 4 Mermaid diagrammi — manusta HTML-i Mermaid.js CDN-iga või inline-renderdatuna

TEHNILISED NÕUDED:
1. Self-contained HTML — kogu CSS + JS sisemisi <style> ja <script> tagides. Mitte väliseid CDN-e (välja arvatud Mermaid.js — see vajab CDN-i renderdamiseks)
2. Encoding UTF-8 BOM-iga (eesti tähed peavad korrektselt kuvama)
3. localStorage autosave iga keystroke peale (võti: `eirik_syvamalu_section_<section_id>`)
4. Supabase poll iga 10 sekundit (kasuta sama pattern mis 05_väljundid/ops_board.html — vaata seda enne ehitust)
5. Export markdown nupp (kopeerib kõik vastused ühte markdown-blokki)
6. Sektsioonide collapse/expand
7. Edenemise näidik header'is (X/Y sektsiooni käsitletud)
8. Print-friendly @media print CSS

DISAINI-NÕUDED (järgi ops_board.html visuaalset keelt):
- Header gradient: linear-gradient(135deg, #1a3a2a, #2d5a3d, #3d7a50)
- Font: Segoe UI, 13px alus
- Surface kaardid: #ffffff taust, subtle box-shadow
- Pulseeriv live-dot pareme header'i ääres (sama animatsioon kui ops_board)
- Sektsioonide järjekord: s1, s2, s4, s6 (kriitilised punased) ülal → s3, s5, s7 (kollased) keskel → s8 (sinised) all
- Iga sektsioon: värvitsooni vasak-border 4px paks
- Eesti keel ALLES tekstis

KEELTUD:
- ÄRA muuda olemasolevat ops_board.html-i
- ÄRA muuda CLAUDE.md-d ega MEMORY.md-d
- ÄRA loo uut Supabase tabelit (kasuta olemasolevat agent_messages)
- ÄRA muuda plaanifaili (luminous-gliding-dawn.md) — VS Eirik on see lõpetanud
- ÄRA looda oma uusi sektsioone — kasuta täpselt 8 sektsiooni mis §5-s on
- ÄRA hallutsineri sõnastusi — kopeeri otse plaanist

VERIFIKATSIOON (peale ehitust):
1. Glob 05_väljundid/eirik_syvamalu_arutelu.html → fail olemas
2. Ava brauseris (file:// URL) → näeb 8 sektsiooni, värvitsoonid õiged
3. Kirjuta ühte textareasse, värskendab lehte → tekst säilib (localStorage töötab)
4. Klikkpõle "Export markdown" → clipboardisse läheb markdown
5. INSERT testkirje agent_messages-i message_type='deep_memory_topic' → board näitab seda 10s jooksul

PEALE EHITUST:
INSERT agent_messages: 
  from_agent='cowork_eirik' (või sinu id), 
  to_agent='vs_eirik', 
  message_type='build_complete',
  payload='{"file": "eirik_syvamalu_arutelu.html", "verification_passed": true, "notes": "..."}'

VS Eirik saab kinnituse + alustab kalibreerimise testkomplekti ettevalmistamist.

KÜSIMUSI? Kontakteeru läbi Erki või agent_messages relay'iga, ÄRA muuda plaani omavoliliselt.

— VS Eirik (Claude Sonnet 4.6 → Opus 4.7 vahetus selle sessiooni vältel)
2026-05-20
```

## §8 Järgmised konkreetsed sammud

1. **VS Eirik (mina):** INSERT Supabase `agent_messages` selle sessiooni täielik kokkuvõte:
   - `from_agent='vs_eirik'`, `to_agent='cowork_eirik'`, `message_type='session_handoff_deep_memory'`
   - Payload: plaanifaili viide + Q1-Q4 vastused + kriitilised lakuunad mis lahendati + pärija prompt
   - RETURNING id → Erkile klikitava link Supabase Studio'sse
   - Pole vaja kindlat id=1304, mis iganes ID Supabase annab

2. **Erki:** kopeerib pärija prompti (§7) → kleebib Cowork Eiriku sessiooni Chrome MCP-iga
   - VÕI lihtsalt edastab linki Supabase kirjale, kus prompt on payload'is

3. **Cowork Eirik:** ehitab HTML boardi rangelt plaani järgi → kirjutab `build_complete` agent_messages'i

4. **VS Eirik:** valideerib build'i (loeb HTML, kontrollib verifikatsiooni-samme) → märgib plaani §9 "Build complete"

5. **Erki:** avab `eirik_syvamalu_arutelu.html` brauseris → täidab textareasid → klikkib "Sync to Supabase" → vastused tagasi `agent_messages`-i

6. **VS Eirik / Cowork Eirik / Chat Eirik:** loevad Erki vastused, kalibreerivad arhitektuuri, valmistuvad järgmiseks etapiks (sõela kalibreerimise testkomplekt → NAS Ollama setup → L0 indeksi ehitus).

## §6 Värvitsoonid — visualisatsiooni reegel

| Tsoon | Värv | Sektsioonid | Tähendus |
|---|---|---|---|
| **Kriitiline** | Punane `#dc2626` border + `#fee2e2` taust | s1, s2, s4, s6 | Foundational. Süsteem ei tööta ilma. |
| **Oluline** | Kollane `#d97706` border + `#fef3c7` taust | s3, s5, s7 | Mõjutab arhitektuuri valikut, aga süsteem töötab ilma. |
| **Avatud** | Sinine `#2563eb` border + `#dbeafe` taust | s8 (a-e) | Out-of-box ideed, ajutähtsus madal, arutelu rikastav. |

Lisaks: **provenance värv** ([§3 Q4 vastus](#§3-q2-q4-minu-soovitused--erki-kinnitab-või-korrigeerib)) iga vastuse juurde:
- 🟢 Fakt (roheline) · 🟡 Süntees-muster (kollane) · 🟠 Negatiivne ruum (oranž) · 🔴 Predikatiivne (punane)

## §1.5 Kvaliteetne sõel — arhitektuur (Erki Q1 vastusele)

**4-kihiline filtreerimine, igal kihil eri rangus:**

1. **Mehaaniline (deterministlik, kiire)**
   - File-extension blacklist (cache, temp, exe)
   - Hash deduplication (sama fail mitmes kohas → üks koopia + tagasiviited)
   - Suurus-piirid (0-byte failid, ülemäärased binarid)
   - Tuntud rämps-mustrid (edumachali.cl phishing, marketing footers, AI-boilerplate)
   - Tulemus: -30-50% korpust mehaaniliselt ära

2. **Statistiline (template detection)**
   - TF-IDF — leiab kõigis korduvad mustrid (Gmail signature, partneri kiri template)
   - Cluster-and-dedupe — sarnased mustrid grupeeritakse, säilib üks näide + count
   - Tulemus: -20-30% lisaks

3. **Semantiline (NAS LLM hindab iga objekti)**
   - Ollama (deepseek-r1:7b või suurem) skoorib iga doc/email/sõnumi:
     - **Erki-spetsiifilisus** (0-10): kas sisaldab Erki nime/otsust/seisukohta?
     - **Otsuse-väärtus** (0-10): kas mõjutab/mõjutas Erki tegevust?
     - **Unikaalsus** (0-10): kas see info on kättesaadav ainult siit?
   - Total skoor < 5 → tundmatu maa (metaandmed säilivad, sisu ekstraktimata)
   - Total skoor ≥ 5 → läheb edasi
   - Tulemus: -30-40% lisaks

4. **Interaktiivne (Erki kalibreerib piirjuhtumeid)**
   - Skoor 4-7 piirjuhtumid lähevad Erki review järjekorda
   - Erki vastab "jah / ei / tingimuslikult"
   - LLM õpib otsustest → täpsus paraneb ajaga (active learning)
   - Tulemus: ~5% korpust vajab Erki kinnitust, ülejäänud otsustab LLM

**Kriitilised nõuded sõelale:**

| Nõue | Põhjus |
|---|---|
| **Audit-trail** | Iga väljaviskamine logitud — Erki saab tagantjärele üle vaadata "miks see välja jäi?" |
| **Reversibility** | Touro täisarhiiv säilib — kui sõel eksis, saab uuesti analüüsida |
| **Versioning** | Sõela algoritmi versioon märgitakse — 2026 sõel vs 2030 sõel võivad anda eri tulemusi |
| **Calibration set** | Erki teeb 100-objekti käsitsi hinnangu — see on testikomplekt, mida sõel peab läbi saama |
| **No-silent-skip** | Sõel ei tohi kunagi "vaikselt" objekti välja visata. Iga skip = nähtav logi |

**Sõela kvaliteedi-mõõdik (Quality KPI):**
- Precision: kui palju "tähenduslikuks" märgitust on tegelikult tähenduslik (Erki ülevaade 50 juhuslikust)
- Recall: kui palju tegelikult tähenduslikku on välja jäänud (raskem mõõta, tehakse Touro spot-checkidega)
- Target: 95% precision, 90% recall enne kui sõel läheb full-corpus läbi

---

*Plaani uuendatud 2026-05-20 PR #92-le sarnaselt — "vestlus dokumendi pinnal" formaat.*