Vaheaudit — Forestsense süsteemiarhitektuur (6+2 kihtide vahekord)

§1 Lühikokkuvõte

§2 Forestsense süsteemiarhitektuur — 6+2 mudel

Mudel — 6 kihti + 2 cross-cutting

Kihtide rollid Karpathy-stiilis

Eelmise raami võrdlus (v1, hüljatud): Vaatasin TerraNervus ↔ TimberTrace kui kahte rakendust mis omavahel liidestuvad. Erki Karpathy-peegeldus näitas et see oli vale raam — nad mõlemad telisid LAOST ja ei lähe omavahel ühendusse. Kogu integratsioon toimub lepete kaudu, mitte rakenduste-vaheliselt.

§3 Olemasolev seis — täielik artefaktide kataloog

§3.1 Supabase tabelid (56 public schema)

Tähelepanek: LADU 2D (data products) on hetkel ainult 50 rida 5 tabelis. See on alarm — kasvab kiirelt kui 3 paketti × 11 etappi × N kliendid. Vt §4 R12 + §6 soovitused.

§3.2 Edge Functions (12 ACTIVE)

§3.3 Skill failid (31 faili)

§3.4 Dokumendid (00_alus/ — valikud)

Kataloogi-tähelepanek: Kolm faili puuduvad mis on uue 6+2 mudeli aluseks: 00_alus/ladu_v1.md (LADU SSOT), identiteet_v1.md (RLS coverage matrix), compute_jetson_v1.md (Kiht 3 hardware SSOT). Need on P0/P1 action item'id (§7).

§4 Diagnoos — 13 cohesion/coupling rikkumist

§4.1 Algsed rikkumised (Generator) — 8

§4.2 Arhitekt-agendi täiendused — R9-R13

§4.3 Skeptik-agendi leid — pos_deep_memory paradoks (super-rikkumine)

§5 Sünergia-võimalused — 5 tugevamat

§6 Soovitused — tsentraalse koordineerimise raamistik

§6.A — LADU autonoomia (data products eraldi rakendustest)

Iga "enrichment" (materialized view, embedding, join, RPC mis töötab ≥2 rakendusele) peab elama LADU 2D kataloogis 00_alus/ladu_v1.md. Iga data product'ile määratud: omanik-meeskond (data-team / app-team / shared), refresh-tsükkel (real-time / hourly / nightly / weekly), tarbijad (rakenduste loend), schema-stabiilsus SLA (v1.0 / breaking changes 30 päeva ette). See on PR #99 kandidaat (vt §8).

§6.B — Leppe-katalog (API + compliance + reeglid masinaloetav)

Praegu Kiht 5 (LEPPED) on 6 alamkihti aga ühtset kataloogi pole. Soovitus: 00_alus/lepped_v1.md — kataloog kus iga lepe on tabelis kirje: {leppe_nimi, kiht (5A-5F), version (semver), kohaldumine, machine_readable_schema}. Migration 0050: contract_catalog Supabase tabel (LADU 2E master) — masinaloetav.

§6.C — Skill ümberkujundamine (per-kiht skill failid)

Praegu 31 skilli on hajutatud rakenduste järgi. Soovitus: 5 uut per-kiht skilli:

• 00_alus/skills/ladu-data-products-skill.md — LADU 2D haldus, omanikud, refresh-rütm
• 00_alus/skills/leppe-katalog-skill.md — Kiht 5 6 alamkihti + machine-readable schema
• 00_alus/skills/compute-jetson-skill.md — Kiht 3 hardware + AI-mudelite haldus
• 00_alus/skills/semantika-kiht-skill.md — Kiht 4 embedding + Graphify + sõnastik-mapping
• 00_alus/skills/identiteet-rls-skill.md — Cross +A multi-tenant + policy coverage

§6.D — Cross-project audit cron (CLAUDE.md PR #99 kandidaat)

Automaatne audit iga 4 nädala järel — kontrollib: layer_tag completeness, cohesion violations, RLS coverage, schema drift, data products owner-list. Tulemus saadetud agent_messages kui task Erkile (priority 3).

§6.E — 6+2 mudeli laiendus (kandidaat v1.1 — vt §9 Skeptik)

Skeptik avastas et 6+2 ei piisa 10x skaalal. Soovitan järgmise iteratsiooni kandidaadid (ei lukku praegu, aga jätame raporti lisana):

• Kiht 2.LAKE alamkiht — S3/MinIO + Parquet/Iceberg suurte ruumiandmete jaoks (Sentinel-2, LiDAR pointcloud)
• Cross +C VERSIOONIMINE — iga API + view + embedding-mudel + äri-reegel kannab semver-tag'i. Migratsioonid versioonide vahele. pos_deep_memory.embedding_model = 'bge-m3@v1.5'
• Cross +D PERFORMANCE / CACHING — Redis/Memcached kihi 2 ja 5 vahel reaalajas (sub-100ms) päringute jaoks (TimberTrace Janis UI sortiment-otsing)
• Multi-layer artifact mõiste — pos_deep_memory paradoksi lahendus. Iga tabeli rida saab tagged multi-layer atribuutidega kui ta tõesti elab 2+ kihis (LADU 2 + SEMANTIKA 4 + APPS 6).
• Deployment topology peatükk — Jetson tsentraliseeritud / edge / hybrid? Multi-tenant: cloud-host / self-host / dedicated?

Need EI ole lukus 2026-05-23. Need on v1.1 kandidaadid mille Erki saab kaaluda järgmistes sessioonides. Praegu lukus on 6+2 mudel (lihtsus müügile ja töökorraldusele).

§7 Tegevuskava — prioritiseeritud action items

P0 — sel nädalal (3 punkti)

# Forestsense LADU v1.0 — SSOT

## Kiht 2A — Ruumi+tabel ühendatud (20 tabelit)

### lvm_cirsmas (1133 rida) — LVM Geo Basic Auth layer 2
- **Owner skill:** lvm-geo-kaart-skill.md
- **Refresh:** nightly cron `lvm_geo_sync` (P1)
- **Consumers:** TerraNervus (Kiht #4 NFA, #5 Sortiment), TimberTrace (audit § 3 cirsma)
- **RLS status:** ⚠️ DISABLED (P1 fix)
- **Schema version:** v1.0 (stabiilne)
- **FK:** geom_4326 PostGIS geometry; jobcode VARCHAR (49% NULL)

### tma_tracking (100653 rida) — Machine Tracking TMA-st
... (jätku iga tabelile)

## Kiht 2D — Data products (5 view'd kasvavad)

### synth_sortiment_heatmap (TBD — Migration 0048)
- **Owner:** data-team
- **Refresh:** pg_cron 06:00 igapäev
- **Consumers:** terranervus_kiht_5, timbertrace_audit, 3rd_party_api
- **SLA:** schema v1.0 — breaking changes 30 päeva ette teatatud agent_messages-iga
...

-- Migration 0049: Data product ownership + layer_tag
-- VS Eirik 2026-05-23 · PR #99 kandidaat

-- 1) layer_tag enum
CREATE TYPE layer_tag AS ENUM (
  '1','2A','2B','2C','2D','2E','2F','3','4',
  '5A','5B','5C','5D','5E','5F','6','+A','+B'
);

-- 2) Tabelite klassifikatsiooni meta-tabel
CREATE TABLE IF NOT EXISTS forestsense_layer_registry (
  object_name TEXT PRIMARY KEY,
  object_type TEXT NOT NULL CHECK (object_type IN ('table','view','mview','function','edge_function','skill')),
  layer layer_tag NOT NULL,
  owner_skill TEXT,
  refresh_cycle TEXT,
  consumers TEXT[],
  schema_version TEXT DEFAULT 'v1.0',
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- 3) Materialized view'd → LADU 2D
ALTER MATERIALIZED VIEW IF EXISTS synth_lepingu_risk
  RENAME TO ladu_synth_lepingu_risk;
COMMENT ON MATERIALIZED VIEW ladu_synth_lepingu_risk IS
  'LADU 2D data product · owner: data-team · refresh: pg_cron 06:00 · consumers: terranervus, timbertrace, 3rd_party';

ALTER MATERIALIZED VIEW IF EXISTS synth_sortiment_heatmap
  RENAME TO ladu_synth_sortiment_heatmap;
COMMENT ON MATERIALIZED VIEW ladu_synth_sortiment_heatmap IS
  'LADU 2D data product · owner: data-team · refresh: pg_cron 06:00 · consumers: terranervus_kiht_5';

ALTER MATERIALIZED VIEW IF EXISTS synth_nfa_overlap
  RENAME TO ladu_synth_nfa_overlap;
COMMENT ON MATERIALIZED VIEW ladu_synth_nfa_overlap IS
  'LADU 2D data product · owner: data-team · refresh: pg_cron 06:00 · consumers: terranervus_kiht_4, timbertrace_nfa_audit';

-- 4) Seed forestsense_layer_registry kõikidele teadaolevatele objektidele
INSERT INTO forestsense_layer_registry (object_name, object_type, layer, owner_skill, refresh_cycle, consumers) VALUES
  ('lvm_cirsmas', 'table', '2A', 'lvm-geo-kaart-skill', 'nightly', ARRAY['terranervus','timbertrace','janis_ui']),
  ('lvm_nogabali', 'table', '2A', 'lvm-geo-kaart-skill', 'nightly', ARRAY['terranervus','timbertrace','janis_ui']),
  ('tma_tracking', 'table', '2A', 'harvester-skill', 'nightly', ARRAY['timbertrace','janis_ui']),
  ('kpdc_documents', 'table', '2A', 'kpdc-saatelehed-skill', 'nightly', ARRAY['timbertrace','terranervus']),
  ('pos_deep_memory', 'table', '4', 'l1-malu-loomise-skill', 'realtime', ARRAY['vs_eirik','cowork_eirik','chat_eirik','janis_ui']),
  ('agent_messages', 'table', '5E', 'agent-messaging-bus-skill', 'realtime', ARRAY['*']),
  ('session_manifests', 'table', '+B', 'sessiooni-lopetamise-skill', 'realtime', ARRAY['vs_eirik']),
  ('unit_mapping', 'table', '2E', 'directo-skill', 'manual', ARRAY['directo_sync','raie_arve']),
  ('price_lists', 'table', '2C', 'hinnakirja-koefitsent-skill', 'manual', ARRAY['raie_arve_verifitseerimine']),
  ('ladu_synth_lepingu_risk', 'mview', '2D', NULL, 'pg_cron_06:00', ARRAY['terranervus','timbertrace','3rd_party']),
  ('ladu_synth_sortiment_heatmap', 'mview', '2D', NULL, 'pg_cron_06:00', ARRAY['terranervus_kiht_5']),
  ('ladu_synth_nfa_overlap', 'mview', '2D', NULL, 'pg_cron_06:00', ARRAY['terranervus_kiht_4','timbertrace_nfa']);
  -- ... (jätku kõigi 56 tabelitele + 12 Edge Functions + 31 skillile)

P1 — kahe nädala jooksul (5 punkti, abstraktselt)

P2 — kuu (3 punkti, abstraktsed)

§8 PR #99 kandidaat — lõplik lukk-tekst

| **#99** | **Data product ownership + layer_tag metadata** — kõik enrichment'id
(materialized view'd, embedding'ud, joinid, RPC funktsioonid mis töötavad
≥2 rakendusele) PEAVAD olema (a) LAOS dokumenteeritud kui "data products"
(`00_alus/ladu_v1.md` Kiht 2D), (b) tagged `layer` metadata-veeruga
forestsense_layer_registry tabelis (`{1, 2A-2F, 3, 4, 5A-5F, 6, +A, +B}`),
(c) varustatud owner-skilli viite + refresh-tsükli + tarbijate (rakenduste)
loendiga + schema-stabiilsus SLA-ga. **Põhjus 1:** rakenduskihi
materialiseeritud omandused → coupling murrub kui kolmas rakendus tahab samu
agregeeringuid; lock-in tehniliselt + müügistrateegias. **Põhjus 2:** ilma
metadata-tagging'uta on cohesion-test võimatu, drift-detection cron-il
pole signaali. **Erki nõue 2026-05-23:** *"applikatsioonid ei tohi olla
hardcoded omavahel kokku, vaid neid seob andmete kasutamine samas laost ja
üksteise täpselt sõnastatud tellimuste täitmine"* — Karpathy data-as-a-
product. **Kohaldumine:** iga `ladu_synth_*`, `tma_workorder_match`,
`pos_deep_memory.embedding_*`, `v_*` view, kõik agregaadid + cross-table
joinid + reusable RPC funktsioonid. **Erand:** Edge Function/skill mis
on ainult ühe rakenduse loogika (ei jagatav) tohib elada rakenduse omandus,
AGA peab olema `layer_tag = 6` (APPS) ja teiste rakenduste poolt ei
kasutata. **Migration-pool:** sel sessioonil diagnoositud 4 rikkumist
(R1 synth_*, R2 pos_deep_memory.embedding_bge_m3, R3 tma_workorder_match,
R4 eudr-dds reeglid) → P0 #2 (Migration 0049). |

§9 Red Team kontra-argumendid — 3 agendi süntees

Arhitekt — peamised hoiatused

• LADU 2D over-bloat risk: kasvab 100+ view'ks kiiresti (6 etappi × 11 ahel-punkti × 3 ettevõtet). Owner-kaos kui ei eraldata.
• Kiht 5 fragmenteeritus: 6 alamkihti (5A-5F) on "kõik mis pole andmed" — risk muutuda misc/ kataloogiks.
• Cross-cutting +A/+B = teine taksonoomia: agent_messages on samaaegselt 5E ja +B. Topelt-owner = lõputu vaidlus.
• Skill ↔ Kiht mapping mitte 1:1: harvesting-project-audit-skill puudutab kihte 1+2A+2D+5B+6. Vajab metadata: layers: [1, 2A, 2D, 5B, 6].

Müügimees — peamised hoiatused

• Lock-in eetika: LADU + LEPPED peavad olema portable (GDPR + EU andmesuveräänsus). Lepingusse "data portability" klausel.
• Jetson EI tule iga kliendiga: see on TerraNervus Pakk B premium-feature ainult. Vaikimisi shared Jetson cluster meie pilves.
• Müügiloogika kaskaadina: EUDR (Pakk A) → upsell TerraNervus (Pakk B) → upsell Full Platform (Pakk C). Iga klient siseneb läbi A.
• Pakk D = partneri-võrgustik: data.forestsense.ai REST API + OAuth2. Teeb meist platvormi, mitte ainult toote.

Skeptik (Red Team) — peamised hoiatused (kõige tugevamad)

• "Üks tõe-allikas = üks tehnoloogia" eeldus on vale: 50TB+ Sentinel-2 ei mahu Postgres'i. Vajab Kiht 1.5 Data Lake.
• Embedding migratsiooni-strateegia puudub: kui BGE-M3 → BGE-M4 2027, kuidas migreerime ilma kihi 2 murdmata?
• pos_deep_memory multi-layer paradoks: elab 4 kihis korraga — see on fundamentaalne kategooriaviga mudelis.
• Karpathy adversariaalne küsimus: "Kustuta Kiht 5. Kas Kiht 6 töötab?" — Ei. APPS pole 2-st sõltuv vaid 5-st. Lepe ei lahuta, see liimib.
• Schema-reality-check on käitumusreegel: kui arendaja unustab, ei kontrolli keegi. Vajab CI hook + automatiseerimine.
• "6+2 on hea kommunikatsiooniraam, aga kehv täideviimise spec": mudel ütleb kus asi elab, mitte kuidas asi liigub kihtide vahel.

Süntees: 6+2 mudel kestab praegu (lihtsus müügile + meeskonna-koordinatsioonile). Aga v1.1 kandidaadid §6.E on hädavajalik enne 10x skaalat. Erki saab kaaluda järgmise vaheauditi (2026-06-23 kuu).

§10 Mälu-struktuuri ettepanekud (PR #95)

Sel sessioonil tehtavad INSERT-id (prognoos — täituvad pärast HTML salvestamist)

• pos_deep_memory 1 INSERT (category='otsus', subject='Vaheaudit Forestsense arhitektuur 6+2 mudel 2026-05-23' + PR #99 kandidaat)
• agent_messages 1 INSERT (from_agent='vs_eirik' → to_agent='erki', task_done)
• session_manifests 1 INSERT (compliance audit 14/14 tõenäoliselt)

Uued failid sel sessioonil

• memory/ssot_forestsense_arhitektuur.md (uus SSOT)
• 05_väljundid/vaheaudit_forestsense_arhitektuur_2026-05-23.html (käesolev raport)

P0/P1 action item'iga loodavad failid (järgmised sessioonid)

• P0 #1 → 00_alus/ladu_v1.md
• P1 #3 → 00_alus/identiteet_v1.md
• P1 #1 → 5 per-kiht skilli (ladu-data-products, leppe-katalog, compute-jetson, semantika-kiht, identiteet-rls)

L1 olek

• Kirjeid kokku: 524 → 525 (+1 sel sessioonil)
• Vanimad >30 päeva: kontrollimata sel sessioonil (P2 punkt kompaktimisele)
• Schema snapshot vanus: < 7 päeva ✅ (cron Eirik_Schema_Snapshot)

Ettepanekud

1. CLAUDE.md PR #99: data product ownership + layer_tag reegel (lõplik tekst §8). Sisestatakse pärast Erki kinnitust.
2. MEMORY.md §A SSOT: lisa ssot_forestsense_arhitektuur.md rida (uus SSOT, kõige tähtsam projekti-vaade).
3. MEMORY.md §D Tehnilised viited: lisa 00_alus/ladu_v1.md viide pärast P0 #1 loomist.
4. Skill registry: 5 per-kiht skilli (vt §6.C) — P1 sessioonid.
5. L1: käesolev raport INSERT category='otsus' (1024-dim BGE-M3 embedding ootel nightly Jetson cron'iga).
6. G-kiht: pärast SSOT loomist graphify update . et globaalne graaf näeks uut sõlme.

§11 Kaardistuse õppetunnid (PR #98)

Sel sessioonil kaartidega ei tegeleta otseselt — see on cross-system süsteemiarhitektuuri vaheaudit, mitte kaardistus.

Sektsioon eksisteerib vastavalt PR #98 kohustusele. Sisuline märkus: viitame TerraNervus kihtide #1, #4, #5 (lepingu-risk, NFA audit, sortiment-heatmap) sõltuvustele TimberTrace andmetest. Uue 6+2 mudeli järgi need andmeprodukti (synth_*) kuuluvad LADU 2D-sse, mitte rakendusse. Järgmise kaardi-sessiooni puhul tuleb sellele uuele lepingule (PR #99) viidata — kihti #1/#4/#5 visuaal-toode loeb LADU 2D view'd, mitte rakenduse-sisest cache'i.

Tehniliste õppetundide-vaade: kaks tooret ülemandimispromptit antud paralleelselt (TerraNervus + TimberTrace) andsid piisavalt konteksti et üldagent saaks teha 3-kihilise süsteemi-vaate ilma kontaktivaba. Karpathy-stiilis peegeldus (data-as-a-product mantra) muutis terve raami radikaalselt — lugemine "kahe rakenduse integratsioon" → "süsteemi-arhitektuur 6+2". See peaks olema standardne praktika — iga "integratsiooni" vaheauditi puhul küsida kõigepealt: "kas need kaks asja on tegelikult rakendused mis teineteisega liidestuvad, või on nad kaks tarbijat mille vahel asub jagatud LADU?"