91 lines
8.7 KiB
Markdown
91 lines
8.7 KiB
Markdown
# Memory
|
|
|
|
## feedback: při deploymentu skillu synchronizovat celý adresář, ne jen scripts/
|
|
|
|
Při kopírování skillu na server vždy rsyncovat **celý adresář skillu** (např. `skills/remind/`), nikoli jen podadresář `scripts/`.
|
|
|
|
**Why:** 2026-05-29 — fix `remind_edit.py` byl rsyncem nasazen, ale `SKILL.md` s novou instrukcí ne. Agent proto stále četl starý `SKILL.md` a chybné chování přetrvávalo. Druhé kolo čištění dat bylo nutné zbytečně.
|
|
|
|
**How to apply:** `rsync -av skills/remind/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/remind/` — cílový rsync pokrývá vše (SKILL.md i scripts/). Nikdy nekopírovat jen podadresář, pokud si nejsi jistý, že ostatní soubory jsou beze změny.
|
|
|
|
## feedback: Python skripty na serveru spouštět přes uv (PEP 723 + `uv run --script`)
|
|
|
|
Nové Python skripty v `~/.nanobot/workspace/` psát s shebang `#!/usr/bin/env -S uv run --script` a PEP 723 inline metadata (`# /// script` blok). Žádné přímé cesty do `~/.local/share/uv/tools/<tool>/bin/python` jako shebang, žádné `python3` s předpokladem správného venv.
|
|
|
|
**Why:** Uživatel explicitně řekl „python veci se maji spoustet pres uv" (2026-05-28, iterace #3 detach skillu). Důvod: uv-managed venv má izolaci, cache, a skript je portable — přežije reinstalaci tooly, upgrade Pythonu i přesun stroje.
|
|
|
|
**How to apply:** Pro každý nový stand-alone Python skript na serveru → PEP 723 hlavička. Pokud skript poběží přes user systemd unit, doplnit `Environment=PATH=%h/.local/bin:/usr/bin:/bin` do `.service`, jinak `uv` nebude v PATH. Detail pattern viz [[knowledge.md]] sekce „Python skripty na serveru".
|
|
|
|
## feedback: zálohy serverových configů ukládat do `~/.nanobot/backup/`
|
|
|
|
Před editací jakéhokoli configu na serveru (zejména `~/.nanobot/config.json`) ukládej zálohu do adresáře **`~/.nanobot/backup/`**, ne vedle původního souboru. Pojmenování s timestampem (např. `config.json.bak-YYYYMMDD-HHMMSS`).
|
|
|
|
**Why:** Uživatel to vyžádal 2026-06-02 po editaci context window presetů — záloha vedle configu (`config.json.bak-*`) zaneřáďuje `.nanobot/` root. Centrální `backup/` drží root čistý a zálohy pohromadě.
|
|
|
|
**How to apply:** `mkdir -p ~/.nanobot/backup` a `cp config.json ~/.nanobot/backup/config.json.bak-$(date +%Y%m%d-%H%M%S)` před in-place editem. Platí pro všechny serverové configy, které trackujeme/měníme.
|
|
|
|
## feedback: po změně knowledge/history/memory synchronizovat do serverového develop/
|
|
|
|
Po každém commitu, který mění `knowledge.md`, `history.md` nebo `memory.md`, rsyncni daný soubor i do `nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/develop/`, aby měl serverový nanobot agent aktuální verzi (čte je on-demand jako referenci „jak byla instance rozšiřována a laděna").
|
|
|
|
**Why:** Uživatel 2026-06-02 chtěl agentovi zpřístupnit develop kontext a zvolil průběžnou synchronizaci (ne jednorázovou kopii) — jinak agent časem uvidí zastaralý stav.
|
|
|
|
**How to apply:** `rsync -av <soubor> nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/develop/`. `README.md` v `develop/` je statický popis, ten se nesynchronizuje. Owner zůstává `nanobot:nanobot` (jdeme jako `nanobot`).
|
|
|
|
## feedback: než navrhneš řešení, nejdřív se podívej na reálný stav souborů na serveru
|
|
|
|
Když uživatel navrhuje změnu/přidání do serverové konfigurace (skill, `SOUL.md`/`AGENTS.md`/ostatní workspace soubory, config), **nejdřív si stáhni a přečti aktuální serverovou verzi** a ověř, zda navrhovaná věc už neexistuje nebo není vyřešená jinak — teprve pak navrhuj postup.
|
|
|
|
**Why:** Uživatel 2026-06-07 — na otázku „má smysl zapsat nanobotovi reasoning anglicky?" jsem rovnou navrhl formulaci a celý deployment, ale pravidlo už v `SOUL.md` dávno bylo (napsal si ho Dream procesor sám 2026-05-27). Celý návrh byl zbytečný. Uživatel to označil za podstatnější poznatek než samotnou odpověď. Server se navíc mění autonomně (Dream), takže předpoklady z paměti/repa můžou být zastaralé.
|
|
|
|
**How to apply:** U čehokoli, co se týká serverového stavu, je první krok `rsync`/`ssh cat` reálného souboru + kontrola, jestli problém už není vyřešený. Návrh řešení až po ověření. Platí i pro „malé" změny, které vypadají triviálně.
|
|
|
|
## feedback: u bugu nejdřív najdi a dolož PŘÍČINU, neiteruj workaroundy
|
|
|
|
Než navrhnu jakýkoli fix chování (zvlášť rendering/UI bug), musím **nejdřív najít a doložit kořenovou příčinu** — přečíst reálný **nasazený** kód, který chování produkuje (ne upstream/podobnou verzi), a získat **přímý důkaz** (např. session log s tím, co model skutečně vrátil). Teprve s prokázanou příčinou navrhovat řešení.
|
|
|
|
**Why:** 2026-06-14 (`/note` + URL ve WebUI, viz [[plans/note-wrong-urls.md]]) jsem několik kol nasazoval kosmetické obezličky (linkify → backtick → odrážky → tučné číslo), všechny selhaly, a teprve pak našel příčinu: custom fork WebUI má `li` handler, co přebalí každou položku seznamu s odkazem na kartu. Kdybych nejdřív přečetl nasazený renderer a session log (důkaz, že model echovuje verbatim → chyba je v rendereru, ne v modelu/formátu), ušetřil bych celá kola deploy-test a autorovo zklamání. Nabízená „řešení" pak byly workaroundy, ne systémová oprava — autor je všechny zamítl jako „nesystémové".
|
|
|
|
**How to apply:** U bug reportu: (1) lokalizuj a přečti reálný nasazený kód zodpovědný za chování; (2) seženi přímý důkaz, kde přesně se to láme (logy, session transcript, raw výstup) a vyluč nesprávné hypotézy (model vs renderer apod.); (3) až pak navrhuj fix — a měř ho proti příčině: pokud neopravuje příčinu, řekni to nahlas a označ za workaround. Doplňuje [[memory.md]] „než navrhneš řešení, nejdřív se podívej na reálný stav souborů na serveru".
|
|
|
|
## feedback: skill nemá opakovat ani vysvětlovat to, co už je v system promptu
|
|
|
|
Do `SKILL.md` (nanobotího skillu) nepatří konvence a fakta o prostředí, která už žijí
|
|
v system promptu — `AGENTS.md` (nástroje, `uv`, temp soubory, exec guard, git) a `SOUL.md`
|
|
(osobnost, styl výstupu, jazyk reasoningu). Skill popisuje **svůj vlastní postup**, ne to,
|
|
jak se v tomhle prostředí obecně pracuje. Než něco takového do skillu napíšu, ověřit
|
|
`grep` v `AGENTS.md`/`SOUL.md`, jestli to tam už není.
|
|
|
|
**Why:** 2026-09-02 jsem při zkracování skillu `reflect` do STOP gate 1 *přidal* půlvětu
|
|
vysvětlující, proč se `uv` volá plnou cestou („`uv` není v `PATH` v neinteraktivním SSH;
|
|
uvnitř tahu stačí `uv run`"). Uživatel se zeptal, proč to tam vůbec je — `AGENTS.md` má
|
|
celou sekci `## python — use uv`. Byla to dvojí chyba: environmentální meta-znalost ve
|
|
skillu, a druhá polovina věty navíc doslova opakovala, co `AGENTS.md` agentovi říká.
|
|
Zvlášť trapné v commitu, jehož cílem bylo skill **zkrátit**. Viz `history.md` 2026-09-02
|
|
14:15.
|
|
|
|
**How to apply:** Fakt o prostředí → `AGENTS.md`/`SOUL.md`. Vysvětlení „proč je ten příkaz
|
|
takhle" pro člověka → `README.md` skillu (nenačítá se do kontextu, takže nestojí tokeny).
|
|
Do `SKILL.md` jen to, co agent potřebuje k provedení **tohoto** postupu. A pozor na
|
|
asymetrii: přidat do system promptu se vyplatí jen tehdy, když to agent reálně potřebuje —
|
|
`PATH` gotcha se do `AGENTS.md` nakonec taky nepřidala, protože agentovi bare `uv run`
|
|
funguje a týkala se jen člověka v SSH. Souvisí s [[memory.md]] „než navrhneš řešení,
|
|
nejdřív se podívej na reálný stav souborů na serveru".
|
|
|
|
## feedback: YAML seznamy — víc položek nebo dlouhé stringy jdou do block stylu
|
|
|
|
Seznam s jedinou krátkou položkou zůstává flow (`include: ["*.md"]`, `paths: ["**"]`,
|
|
`exclude: []`). Jakmile má **víc položek** nebo jsou položky **dlouhé stringy** (typicky
|
|
cesty a globy), píše se **block stylem, každá položka na vlastním řádku**.
|
|
|
|
**Why:** 2026-09-09 jsem v plánu `final-wiki-hybrid-rag` napsal `exclude` jako flow seznam
|
|
zalomený přes dva řádky (`["**/node_modules/**", "**/vendor/**",` / `"**/.venv/**", …]`).
|
|
Uživatel to vrátil: zalomený flow seznam je nejhorší z obou světů — nevejde se na řádek,
|
|
nejde u položky mít komentář a diff jedné změněné položky přepíše celý blok.
|
|
|
|
**How to apply:** Platí pro jakýkoli YAML, který píšu nebo který generuje kód (configy
|
|
skillů, frontmatter, CI). Rozhoduj podle obsahu, ne podle délky výsledku: dva dlouhé globy
|
|
jdou do block stylu, i kdyby se na jeden řádek vešly. Block styl navíc umožní komentář
|
|
u konkrétní položky, což u whitelistů a excludů nese hodnotu. Souvisí s pravidlem
|
|
v `CLAUDE.md`, že config je YAML právě kvůli komentářům.
|