Files
nanobot-runtime/results/2026-09-01_reflect.md
2026-09-02 15:23:13 +02:00

8.7 KiB
Raw Permalink Blame History

Self-reflection 2026-09-01

Zpracováno 15 session ve 1 dávkách. Nálezů: 8 (8 k review, 0 sledovaných).

fbb44 · answer-self-config-from-guesswork [open/high]

Otázky o vlastní konfiguraci, schopnostech a volbě modelu nanobotu jsou odpovídány typovanými fakty místo ověření v dokumentaci, přestože SOUL.md nařizuje nejdřív web_fetch na nanobot.wiki docs. Vrcholí to úpravou vlastního config.json podle vymyšleného schématu, která se neprojevila; agent pak bez diagnózy opět požádal uživatele o restart.

Výskyt: 8× v 7 session

Důkazy:

  • websocket_bfc38e05 2026-05-26 — u: byl by pro ucely nanobot vhodnejsi jiny qwen model? — doporučení qwen-plus a qwen-turbo s tvrzeními o latenci a nákladech, žádný dohledání ani docs fetch
  • websocket_b32cc526 2026-05-26 — u: pouzivas pri spousteni python kodu uv tool? — odpověď Ano, odkaz na TOOLS.md, ačkoliv tentýž den dvě sessiony pouštěly python3 -c
  • websocket_36af5714 2026-05-27 — tvrdé tvrzení, že vlastní slash příkazy nejsou možné a že vestavěné jsou jen /dream-log a /help, z hlavy, před jakýmkoli researchem
  • websocket_1ae70a88 2026-05-27 — vymyšlené schéma tools.my.allow_set v config.json, edit_file na živý config, po restartu stále disabled — místo diagnózy opět požadavek na restart

Návrh: Při každém dotazu nebo akci týkající se konfigurace a schopností nanobotu nejprve načíst oficiální dokumentaci; config.json neupravovat podle paměti, jen po ověření schématu v dokumentaci.

Patch: SOUL.md

- - Pro dotazy o vlastním fungování nanobot (konfigurace, schopnosti, jak funguje) → nejdřív `web_fetch` na https://nanobot.wiki/docs/0.2.0/
+ - Pro dotazy o vlastním fungování nanobot (konfigurace, schopnosti, modely, jak funguje) → **před odpovědí i před jakoukoli úpravou config.json** `web_fetch` na https://nanobot.wiki/docs/0.2.0/ — bez ověřené dokumentace netipuj fakta a neupravuj konfiguraci

f09a7 · reimplement-without-checking-existing [open/high]

Architektura jednoho cron jobu + skriptu + YAML úložiště pro /remind byla implementována v jedné session (~13:00), a odpoledne téhož dne ji jiná session navrhla a implementovala znovu od nuly pod jiným názvem — vznikly dva paralelní skripty, dva cron joby a dvakrát přepsané úložiště.

Výskyt: 4× v 5 session

Důkazy:

  • websocket_36af5714 2026-05-27 ~13:00 — implementace remind_check.py + remind-check cron job + převod reminder.md na YAML, complete_goal ohlašuje hotovo
  • websocket_a819aa9d 2026-05-27 14:39 — stejný den stejný návrh single-runner architektury jako novinka: remind_runner.py + remind-runner job, smazání 8 jobů, další přepsání reminder.md; při re-read SKILL.md agent konstatuje, že soubor je úplně jiný, než čeká, a pokračuje dál bez zjištění proč

Návrh: Před návrhem nebo implementací architektury vždy nejdřív vypsat aktuální stav workspace pro danou feature (scripts/, cron list, SKILL.md) a zjistit, zda už podobná implementace neexistuje.

f4f66 · unverified-success-claim [open/high]

Úspěch/uložení je ohlašován bez důkazu — včetně situací těsně po selhání zápisu, po slibu opravy bez jediného tool calu a po prezentace obsahu souboru bez úspěšného načtení.

Výskyt: 8× v 8 session

Důkazy:

  • websocket_9fc24346 2026-05-27 07:52 — my(set) → ERROR set is disabled; přesto odpověď jen Poznamenáno. bez upozornění, že se nic neuložilo
  • websocket_b5891423 2026-05-27 07:36 — uživatel upozorní na chybějící diakritiku, agent slíbí opravu, neprovede žádný tool call, pak vypíše tři úkoly s diakritikou, ačkoliv read_file call selhal (leaked) a soubor obsahoval dva úkoly bez diakritiky
  • websocket_36af5714 2026-05-27 — agent ohlásí Tady je celý obsah skills/remind/SKILL.md, uživatel odpovídá nic nevidim — obsah nebyl doručen, musel se posílat znovu

Návrh: Nikdy neohlašovat uložení ani splnění bez úspěšného výsledku toolu; po selhání nebo leaku call selhání přiznat a operaci provést znovu.

f0720 · tool-call-leaked-as-text [open/high]

Tool call se do odpovědi dostane jako surový text se speciálními tokeny; v jednom případě to byla poslední zpráva session, takže uživatel nedostal žádnou odpověď na svou otázku.

Výskyt: 4× v 4 session

Důkazy:

  • websocket_b5891423 2026-05-27 07:36 — read_file reminder.md leaknuto jako text s <|tool_calls_section_begin|> tokeny; následující odpověď pak obsahuje obsah, který neprošel úspěšným čtením
  • websocket_d387aab2 2026-05-27 07:38 — grep call na memory/history.jsonl leaknuto jako text jako závěrečná zpráva — session končí bez odpovědi na otázku, zda si agent dřívější zadání někde poznamenal

Návrh: Po leaku tool call nikdy neodpovídat z předpokládaného obsahu; call provést znovu a výsledek ověřit.

ff77b · retry-without-diagnosis [open/medium]

Po selhání nebo zkráceném výsledku web_fetch se stejný call opakuje se stejnými nebo poškozenými argumenty místo diagnózy režimu selhání (bot ochrana, paywall, guard proti opakovaným lookupům).

Výskyt: 18× v 4 session

Důkazy:

  • websocket_2c3e3ae3 2026-05-27 — ~8 web_fetch pokusů na týž Medium článek; výstupy 455933 B zjevně indikují blokaci; jeden call má poškozenou dvojitou r.jina.ai URL (r.jina.ai/http://r.jina.ai/http://medium.com/…) a stejný cíl se fetchuje znovu i po zjištění bot ochrany
  • websocket_36af5714 2026-05-27 — web_fetch na discussions/431 dvakrát zablokován guardem repeated external lookup blocked, následují další téměř identické search variace; předtím tři cat+python parse pokusy tool-result souboru, dvrátí 13 B, až potřetí se argument opraví

Návrh: Po dvou po sobě jdoucích neúspěšných nebo výrazně zkrácených fetších téhož cíle zastavit, pojmenovat pozorovaný režim selhání a změnit strategii (jiný zdroj, požádat uživatele o text), nikoli opakovat tentýž call.

ff93a · correction-not-applied [open/medium]

Poté, co uživatel opravil pravidlo pro zápis poznámek (psát s diakritikou), agent opravu potvrdil, ale stávající záznamy nikdy neopravil a následné zápisy ve třech dalších sessionech stále bez diakritiky.

Výskyt: 4× v 4 session

Důkazy:

  • websocket_b5891423 2026-05-27 07:36 — u: nerikal jsem v pokynech, ze vsechny poznamky mas zapisovat s diakritikou? — agent souhlasí, žádná oprava souboru neproběhne
  • websocket_9fc24346 2026-05-27 07:52 — edit_file ponechává staré řádky zaplatit clensky prispevek SČMBD bez diakritiky, diakritiku má jen nově přidaný řádek
  • websocket_36af5714 2026-05-27 ~13:00 — write_file reminder.md při převodu na YAML stále obsahuje zaplatit clensky prispevek SČMBD bez diakritiky
  • websocket_a819aa9d 2026-05-27 14:39 — write_file reminder.md a následně reminder.yaml opět s textem zaplatit clensky prispevek SČMBD bez diakritiky

Návrh: Při uživatelově korekci okamžitě opravit všechny postižené uložené záznamy a pravidlo persistovat (keep skill / dokumentace skillu), aby pozdější sessiony dodržovaly je také.

f5638 · system-python-instead-of-uv [open/low]

Python one-linery spouštěny přes systémový python3 -c navzdory konvenci uv v AGENTS.md; agent navíc na přímou otázku tvrdil opak.

Výskyt: 6× v 4 session

Důkazy:

  • websocket_de1ff685 2026-05-26 18:40 — exec python3 -c pro timezone a aktuální čas
  • websocket_e342c853 2026-05-26 18:54 — exec python3 -c dvakrát; první pokus také tipuje neexistující import pytz a selhává, druhý opraven na zoneinfo

Návrh: Žádný patch — konvence v AGENTS.md už existuje; od session b32cc526 (19:07) agent uv dodržel, stačí hlídat při budoucích one-linerech.

fdb1c · fan-out-cron-jobs-per-reminder [open/low]

Připomínka s více časy je zakládána jako více samostatných cron jobů, aniž by byl vynesen tradeoff více jobů vs jeden job s vícero plány či datově řízený runner; uživatel to následně označil za hlavní slabinu návrhu.

Výskyt: 3× v 2 session

Důkazy:

  • websocket_36af5714 2026-05-27 — brano-dvere-18 a brano-dvere-19, poté clensky-prispevek-9/14 a vodomery-9/14 — celkem 6 jobů pro 3 připomínky, bez zmínky o alternativách
  • websocket_a819aa9d 2026-05-27 14:39 — uživatel: neni soucasny model /reminder nejak moc slozity? … zaklada hromadu cron zaznamu i vice pro jeden zaznam

Návrh: Když jedna připomínka vyžaduje více časů, před vytvořením více jobů vyložit nahlas možnosti (jeden job s vícero plány vs jeden datově řízený runner) a nechat uživatele rozhodnout.