Zalohovani vsech podstatnych souboru

This commit is contained in:
lachtan
2026-06-10 06:39:52 +02:00
parent 1e10891945
commit 67e29c8b88
69 changed files with 9115 additions and 0 deletions

50
plans/brain-short.md Normal file
View File

@@ -0,0 +1,50 @@
# Brain — Short Plan
## Repo
- Gitea: `git@git.fnet.cz:lachtan/brain.git`
- Private, branch `main`
- Local path: `/home/nanobot/brain/`
- Inside: standard `wiki/` structure from plugin
## Git
- SSH key: `/home/nanobot/.ssh/id_ed25519` (ed25519)
- Auto commit + push after every nanobot write
- Git history = safety net for bad ingests
## Wiki structure
- `wiki/index.md` — main index (shards at >300 lines)
- `wiki/pages/` — compiled pages (LLM output)
- `wiki/sources/` — raw inputs
- Every page has YAML frontmatter: title, type, tags, created, updated, sources
## Nanobot commands
- `/brain-write` — write raw source or page with auto frontmatter, auto commit+push
- `/brain-search` — fulltext search across markdown files
- `/brain-ingest` — full LLM ingest (raw source → compiled page), auto commit+push
- Keyword "brain/wiki" = write to brain; no keyword = MEMORY.md
## Models
- Ingest: `qwen-3.6-plus-openrouter` (fallback `kimi-k2.6-openrouter`)
- All models cloud via OpenRouter/Ollama gateway
- No local inference for ingest
## Scripts
- From `praneybehl/llm-wiki-plugin`: init, search, lint, stats, graph
- Prepared in Claude Code, integrated into nanobot skill wrapper
- Pure Python 3.10+, stdlib + optional PyYAML
## Scaling
- Page soft cap: 400 lines, hard cap: 800 lines
- Index shards at >300 lines or >150 pages
- BM25 fallback at >300 pages
## Machines
- home pc, office pc — Claude Code GUI
- wood.hell — Claude Code CLI
- this LXC — nanobot host
## Implementation phases
1. SSH key → Gitea, clone repo, init wiki, test git push
2. Nanobot skill: write, search
3. Test ingest with qwen-3.6-plus, implement /brain-ingest
4. Add lint/stats/graph scripts, sync across machines

213
plans/brain.md Normal file
View File

@@ -0,0 +1,213 @@
# Brain — LLM Wiki Deployment Plan
> Vytvoreno: 2026-05-28
> Cil: Nasadit a pouzivat plugin `praneybehl/llm-wiki-plugin` (Karpathy LLM Wiki pattern) jako osobni knowledge base "brain" napric pocitaci, s uchovavanim vseho contentu v gitu a integraci do nanobota.
---
## 1. Architektura
### 1.1 Repo
- **Nazev:** `brain`
- **Host:** Gitea self-hosted (`https://git.fnet.cz`)
- **URL:** `git@git.fnet.cz:lachtan/brain.git`
- **Viditelnost:** private
- **Branch:** `main` (primarni, ingest jde rovnou sem)
### 1.2 Lokalni cesta na tomto stroji
- `/home/nanobot/brain/`
- Uvnitr standardni `wiki/` struktura z pluginu (plugin hardcoduje `wiki/`, pozdeji lze patchnout)
### 1.3 Stroje
| Stroj | Role | Claude Code | Nanobot |
|-------|------|-------------|---------|
| home pc | primary dev | ano (GUI) | ne |
| office pc | secondary dev | ano (GUI) | ne |
| wood.hell | server/CLI | ano (CLI only) | ne |
| tento LXC | nanobot host | ne | ano |
### 1.4 Sync mechanismus
- Git push/pull mezi vsemi instancemi
- Okamzity `git commit && git push` po kazdem zapisu nanobotem
- Ostatni stroje si pulluji pri startu nebo periodicke
---
## 2. Git & SSH
### 2.1 SSH klic pro nanobot
- Vygenerovan: `/home/nanobot/.ssh/id_ed25519` (ed25519, bez passphrase)
- Public key: pridat do Gitea repo `brain` jako deploy key nebo k uzivatelskemu uctu
- Fingerprint: `SHA256:iMrDLkVKxNAGPo+xOup0Abi7c/49/D/rZx/MPUIPt4U`
### 2.2 Git config
- `user.name`: `nanobot`
- `user.email`: `nanobot@git.fnet.cz`
- Remote: `origin``git@git.fnet.cz:lachtan/brain.git`
---
## 3. Struktura wiki
Plugin vytvari adresar `wiki/` s nasledujici strukturou:
```
wiki/
index.md # hlavni index, sharded pri >300 radku
indexes/ # per-type indexy pri >150 strankach
pages/ # strukturovane stranky (vysledky ingestu)
sources/ # raw sources (vstupy pro ingest)
references/ # scaling playbook, schema docs
```
Kazda stranka ma YAML frontmatter:
```yaml
---
title: "Nazev"
type: concept | source | summary | index
tags: [tag1, tag2]
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: [slug-zdroje]
---
```
---
## 4. Nanobot integrace
### 4.1 Rozliseni zapisu
- "zapis do brain" / "do wiki" / "brain-write" → zapis do `brain/wiki/`
- Bez klicoveho slova → zapis do `MEMORY.md` (soucasne chovani)
### 4.2 Slash commands / skill tools
| Operace | Popis | Auto commit |
|---------|-------|-------------|
| `/brain-write` | Zapis raw source nebo stranky s YAML frontmatter | ano, okamzite |
| `/brain-search` | Fulltext search pres markdown soubory (grep/BM25) | neni potreba |
| `/brain-ingest` | Full LLM ingest — zkompiluje raw source do stranek | ano, okamzite |
### 4.3 Frontmatter
- `/brain-write` automaticky pridava YAML frontmatter:
- `created`, `updated` (datum)
- `source` (napr. `telegram`, `web`, `user-input`)
- `tags` (volitelne, zadane uzivatelem)
- `type` (`source` pro raw, `concept` pro zpracovane)
### 4.4 Ingest workflow
- Nanobot cte raw source z `wiki/sources/`
- Vola LLM (qwen-3.6-plus) pro strukturalni analyzu
- Vytvari/aktualizuje stranky v `wiki/pages/`
- Aktualizuje `wiki/index.md` a cross-references
- Commit + push do `main`
---
## 5. Modely
### 5.1 Dostupne modely (cloud pres OpenRouter/Ollama gateway)
- `deepseek-v3.2`
- `glm-5.1`
- `kimi-k2.6`
- `minimax-m2.7`
- `qwen-3.6-plus`
- `qwen3.5`
### 5.2 Model pro ingest
- **Primarni:** `qwen-3.6-plus-openrouter` — dobry reasoning/coding, cena
- **Fallback:** `kimi-k2.6-openrouter` — pro velke sources (>32K tokenu)
### 5.3 Ollama role
- Ollama na `nvidia.hell` slouzi jako gateway/proxy pro cloud modely
- Zadny lokalni inference pro ingest (vsechny modely jsou cloud)
---
## 6. Skripty a tooling
### 6.1 Pluginove skripty (z `praneybehl/llm-wiki-plugin`)
- `init_wiki.py` — inicializace wiki struktury
- `wiki_search.py` — BM25 search s frontmatter filtry
- `wiki_lint.py` — strukturalni lint (velikost stranek, odkazy)
- `wiki_stats.py` — statistiky a scaling thresholds
- `wiki_graph_*.py` — optional graph layer (vyzaduje PyYAML)
### 6.2 Nasazeni skriptu
- Skripty budou pripraveny v Claude Code a zkopirovany do `brain/skills/llm-wiki/scripts/`
- Nanobot skill wrapper je bude volat pres `exec` nebo jako tool
### 6.3 Skill wrapper pro nanobot
- Pripraven v Claude Code jako nanobot-compatible skill
- Minimalni sada na startu: `write`, `search`, `ingest`
- Rozsireni pozdeji podle potreby (lint, stats, graph)
---
## 7. Scaling & udrzba
### 7.1 Automaticke sharding
- `wiki/index.md` se sharduje pri >300 radcich
- Per-type indexy v `wiki/indexes/` pri >150 strankach
- BM25 search fallback pri >300 strankach
### 7.2 Velikostni limity
- Stranka: soft cap 400 radku, hard cap 800 radku
- Ingest velkych sources: chunked (po castech)
### 7.3 Safety
- Ingest jde rovnou do `main`
- Git history jako pojistka pro revert
- Chybne ingesty se opravuji v Claude Code
---
## 8. Implementacni kroky
### Faze 1: Zaklad
1. [ ] Pridat SSH public key do Gitea repo `brain`
2. [ ] Naklonovat `brain` do `/home/nanobot/brain/`
3. [ ] Nastavit git config (user.name, user.email)
4. [ ] Inicializovat wiki strukturu (`init_wiki.py` nebo rucne)
5. [ ] Otestovat git push/pull
### Faze 2: Nanobot skill
1. [ ] Pripravit skill wrapper v Claude Code
2. [ ] Implementovat `/brain-write` s frontmatter
3. [ ] Implementovat `/brain-search`
4. [ ] Testovat zapis a search
### Faze 3: Ingest
1. [ ] Otestovat modely na ingest (qwen-3.6-plus)
2. [ ] Implementovat `/brain-ingest`
3. [ ] Otestovat full workflow: raw source → ingest → stranka
### Faze 4: Rozsireni
1. [ ] Pridat pluginove skripty (lint, stats, graph)
2. [ ] Nastavit cron pro periodicke lint/stats
3. [ ] Integrovat s ostatnimi stroji (home pc, office pc, wood.hell)
---
## 9. Rozhodnuti z grill-me session
| Tema | Rozhodnuti |
|------|-----------|
| Nazev projektu | `brain` (repo), uvnitr `wiki/` (plugin default) |
| Lokalni cesta | `/home/nanobot/brain/` |
| Git workflow | Okamzity commit+push do `main` |
| SSH auth | Novy klic pro `nanobot` uzivatele |
| Zapis bez keywordu | MEMORY.md |
| Zapis s "brain/wiki" | `brain/wiki/` |
| Frontmatter | Automaticky pridavat |
| Ingest scope | Full LLM ingest (ne jen light) |
| Ingest model | qwen-3.6-plus (fallback kimi-k2.6) |
| Safety | Rovnou do `main`, git history jako pojistka |
| Skripty | Pripravit v Claude Code, integrovat pozdeji |
---
## 10. Odkazy
- Plugin: https://github.com/praneybehl/llm-wiki-plugin
- Karpathy gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Gitea: https://git.fnet.cz/lachtan/brain

202
plans/projects.md Normal file
View File

@@ -0,0 +1,202 @@
# Project Skill — plán a diskuze
Založeno: 2026-06-08 (session `websocket_12f851b1`)
Poslední aktualizace: 2026-06-09
---
## Původní požadavek
Oddělit část z notes do `projects/` — projekty, na kterých chci pracovat, ale na které neustále zapomínám. Každý projekt vlastní soubor s poznámkami, náhodné připomínky v rozumném intervalu.
---
## Rozhodnutí: Nový skill `/project`, čistě soubory, frontmatter
### Proč nový skill (ne rozšířit `/note` nebo `/remind`)
- `/note` je pro rychlé poznámky — přidat status, prioritu, next-step by ho překutilo
- `/remind` je pro konkrétní opakující se úkoly — projekty mají jinou životnost
- Samostatný skill = čistší interface, nezávislá evoluce
### Proč soubory místo SQLite
- Volné poznámky, editace částí textu, mazání odstavců — **soubor je přirozenější** než DB řádky
- DB je dobrá pro rychlé filtrování, ale špatná pro: "smaž druhý odstavec", "přidej poznámku mezi dvě existující"
- Frontmatter na začátku souboru = metadata se načtou bez procházení celého souboru
- Git-friendly, jeden commit = jedna změna, jeden diff
- Jedno místo pravdy — žádná desynchronizace mezi DB a souborem
### Proč frontmatter místo indexu + souborů
| Kritérium | Index + soubory | Frontmatter |
|-----------|----------------|-------------|
| Jedno místo pravdy | ❌ Dvě místa, riziko desynchronizace | ✅ Vše v jednom souboru |
| Rychlost listu | ✅ Index okamžitě | ⚡ Parse 1020 souborů = zanedbatelné |
| Editace metadat | Edit index + edit soubor | Edit jednoho souboru |
| Git/historie | Dva commity, dva diffy | Jeden commit, jeden diff |
| "Přepni se do projektu" | Najdi v indexu, otevři soubor | Otevři soubor, máš vše |
Index přináší jen rychlost listu, ale projektů bude max desítky — parse zanedbatelný. Frontmatter vyhrává na všem ostatním.
---
## Struktura
```
projects/
├── nuget-cache.md
├── grill-me-plugin.md
└── ...
```
### Šablona projektového souboru
```markdown
---
status: active
priority: high
created: 2026-06-09
slug: nuget-cache
---
# NuGet cache
Hostovat vlastní NuGet cache na Linuxu.
## Poznámky
- 2026-06-09: BaGetter podporuje S3
- 2026-06-09: Originální BaGet je mrtvý, BaGetter je fork
## Další krok
zkusit BaGetter v LXC
```
**Frontmatter obsahuje pouze metadata:** `status`, `priority`, `created`, `slug`. Žádný `next_step` — ten je v těle jako sekce `## Další krok`.
---
## Rozdělení odpovědnosti: skript vs. agent
### Skript `project.py` — metadata + základní operace
| Subcommand | Co dělá | Proč ve skriptu |
|------------|---------|-----------------|
| `add <název>` | Vytvoří `.md` s frontmatter a základní strukturou | Deterministické, žádná volba struktury |
| `list` | Parse frontmatter ze všech `.md`, vypíše active | Rychlé, žádný kontext potřeba |
| `show <slug>` | Vypíše celý soubor | Triviální |
| `status <slug> <active|paused|done>` | Změní `status:` v frontmatteru | Jednoduchý regex, deterministické |
### Agent — textové úpravy souboru
| Operace | Jak | Proč na agentovi |
|---------|-----|------------------|
| `project next <slug> "text"` | Agent `edit_file` na sekci `## Další krok` | Struktura může být libovolná, skript by to nezvládl robustně |
| `project note <slug> "text"` | Agent `edit_file` přidá řádek pod `## Poznámky` | Stejný důvod |
| Editace existující poznámky | Agent `edit_file` | Skript by musel parsovat přirozený jazyk |
| Mazání poznámky | Agent `edit_file` | Skript by musel identifikovat "tu poznámku o S3" |
| Změna struktury souboru | Agent `apply_patch` | Skript nemůže předvídat všechny struktury |
**Pravidlo:** Kdykoliv jde o volný text v těle souboru, použije agent `edit_file`/`apply_patch`. Skript řeší jen frontmatter a celkovou strukturu.
---
## Příkazy skillu `/project`
| Příkaz | Kdo provádí | Co dělá |
|--------|-------------|---------|
| `project add <název>` | Skript | Založí projekt, vygeneruje slug, vytvoří soubor |
| `project list` | Skript | Vypíše aktivní projekty (parse frontmatter) |
| `project show <slug>` | Skript | Zobrazí celý soubor |
| `project status <slug> <status>` | Skript | Změní `status` v frontmatteru |
| `project next <slug> <text>` | Agent | Nahradí obsah pod `## Další krok` |
| `project note <slug> <text>` | Agent | Přidá poznámku pod `## Poznámky` |
| `project switch <slug>` | Agent | Uloží slug do `my` scratchpadu pro aktuální session |
---
## Klíčová feature: "Přepni se do projektu"
- **Explicitní slug** — default, `project note nuget-cache "..."`
- **Session context** — `project switch nuget-cache``my set project_context=nuget-cache` → další příkazy bez slugu použijí kontext
- **Scope:** Jen aktuální session. Po restartu se kontext ztratí — musí se znovu `project switch`.
---
## Připomínky — odloženo na další kolo
Posílání upomínek je feature pro další iteraci. Nejsou součástí POC.
Navržený mechanismus (pro budoucí implementaci):
- Jeden cron job denně (náhodný čas 821h)
- Skript načte `active` projekty, váženě vybere podle priority
- Vypíše `"{name}: {next_step}"`
- Agent přepošle do Telegram
---
## Definitivní rozhodnutí (zodpovězeno 2026-06-09)
### 1. Slug generování
→ Jednoduchý kebab-case lowercase z prvních pár slov názvu. Např. "NuGet package caching" → `nuget-package-caching`. Max pár slov, zbytek se ořízne.
### 2. `next_step` — frontmatter vs. tělo
`next_step` je **pouze v těle** jako sekce `## Další krok`. Frontmatter obsahuje jen `status`, `priority`, `created`, `slug`. Důvod: jedno místo pravdy, frontmatter je jen metadata.
### 3. Editace poznámek — skript vs. agent
**Na agentovi.** Skript nedokáže robustně pracovat s libovolnou strukturou markdown souboru. Agent použije `edit_file`/`apply_patch`.
### 4. `project switch` — přežití mezi sessiony
**Nepřežije.** Kontext je jen v `my` scratchpadu aktuální session. Po restartu se ztratí — explicitní `project switch` znovu.
### 5. Formát priority
→ Slovní: `high`, `medium`, `low`. Čísla jsou nejednoznačná (1 může být nejvyšší i nejnižší).
### 6. Rozdělení skript/agent
→ Skript: `add`, `list`, `show`, `status`. Agent: `next`, `note`, `switch`, veškerá editace/smazání textu.
### 7. Formát data v poznámkách
**Nedefinováno.** Struktura souboru je volná. Agent přidává poznámky pod `## Poznámky` jako bullety, ale uživatel může mít libovolnou strukturu.
---
## Otevřené otázky — VŠECHNY ZODPOVĚZENY
### Identifikace projektů — název vs. slug
→ Slug je souborové jméno (`nuget-cache.md`). Uživatel používá slug v příkazech. Jednoznačné, lidsky přívětivé (kebab-case).
### Vztah k `/note` skillu
→ Oddělené. Explicitní `project note <slug>` jde do projektového souboru, obecný `/note` zůstává v SQLite.
### Vztah k `/remind` skillu
→ Oddělené. Projekty mají vlastní připomínkový mechanismus (až v další iteraci).
### Databáze vs. soubory
→ Čistě soubory s YAML frontmatter. Žádná DB.
### Co je "projekt" vs. "úkol"
→ Projekt = dlouhodobá věc s next-step a poznámkami. Úkol = jednorázová připomínka v `/remind`. Hranice je na uživateli.
### Je to nový systém, nebo rozšířit existující?
**Nový skill.** Méně systémů = méně údržby je obecně pravda, ale `/note` a `/remind` mají jiný charakter. Projektový skill potřebuje frontmatter, editaci souborů, session context — to by existující skilly překutilo.
---
## Implementační plán POC
| Krok | Co |
|------|-----|
| 1 | `project.py``add`, `list`, `show`, `status` |
| 2 | `SKILL.md` — protokol pro agenta (co dělá skript, co agent) |
| 3 | Test — vytvoř 2-3 projekty, ověř editaci přes agenta |
---
## Další kroky
- [ ] Implementovat `project.py` (krok 1)
- [ ] Napsat `SKILL.md`
- [ ] Otestovat základní CRUD
- [ ] Připomínky — další kolo