98 lines
5.2 KiB
Markdown
98 lines
5.2 KiB
Markdown
# Session lifecycle — DRAFT (rozpracováno postupně, finální návod až po dohodě)
|
||
|
||
## Body 1–5 (shoda zdrojů z researchu 10.9.)
|
||
Nový task = nová session; review ve fresh context; přenos mezi sessions artefakty;
|
||
po 2 neúspěšných opravách restart; compact = pojistka, ne plán.
|
||
|
||
---
|
||
|
||
## 6. Vztahuje se „2 neúspěšné korekce → restart" i na plánování?
|
||
|
||
**Ne na počet kol — na typ iterace.** U plánování se 6 kol může znamenat dvě
|
||
naprosto různé věci:
|
||
|
||
**Konvergující iterace** (zdravá):
|
||
- každé kolo uzavře nová rozhodnutí a staré námitky se nevracejí
|
||
- context roste o decision history — přesně to, co pro plánování chceme
|
||
- ukončit ji = zahodit nashromážděné rozhodnutí, ne ušetřit
|
||
|
||
**Kruhová iterace — anchor loop** (selhání):
|
||
- opakuji **stejnou** námitku, model kosmeticky přepracovává vlastní draft
|
||
- výstup nesleduje vstup; každá další korekce stejného typu nepřidává informaci
|
||
|
||
**Signál je „stejná námitka podruhé", ne počet kol.** Zdůvodnění:
|
||
|
||
1. Počet kol nedokáže odlišit konvergenci od smyčky — 6 kol konvergující
|
||
iterace je v pořádku, 3 kola smyčky jsou ztracený čas.
|
||
2. Stejná námitka podruhé je **důkaz**, že výstup nesleduje vstup. Třetí korekce
|
||
stejného typu nemá žádnou novou informační hodnotu — jen přidává tokeny
|
||
mrtvých pokusů, kterými se model dál ukotví.
|
||
3. V plánování chybí verifier. U kódu každý pokus narazí na realitu (build,
|
||
testy) a force korekci kurzu; u plánu je jediným „faktem" text, který model
|
||
sám napsal — reviduje se sám vůči sobě a kosmetika vypadá jako pokrok.
|
||
Proto je anchoring u plánování **silnější** než u kódu, ne slabší.
|
||
|
||
**Praktika pro plánování:**
|
||
|
||
1. Iterovat **v souboru plánu, ne v chatu.** Po každém kole se upraví soubor
|
||
(plán, tabulka scénářů); chat je jen médium. Soubor je single source of
|
||
truth — přežije kompakci i restart a nová session z něj může spustit
|
||
implementaci bez rekonstrukce z historie.
|
||
*(Naše extenze — Anthropic jen říká „plan file → fresh session na
|
||
implementaci"; iterovat přímo soubor plyne z mechaniky: soubor je imunní
|
||
vůči context rot.)*
|
||
2. Námitka podruhé → stop → **kostru navrhnu sám** (tabulka scénářů, skeleton,
|
||
rozhraní) a model ji doplňuje. Lesson z agent-to-human-tools.md: rozhraní
|
||
navrhuje člověk, protože model je anchorovaný na svůj první draft a není
|
||
schopen ho opustit.
|
||
3. Plán hotov → implementace **ve fresh session ze souboru plánu**
|
||
(Anthropic: „Once the spec is complete, start a fresh session to execute it.")
|
||
|
||
## 7. „Přenos mezi sessions = artefakty" — jak to dělat snadno
|
||
|
||
Artefakt není nová povinnost, ale věc, která v práci stejně existuje. Tři druhy:
|
||
|
||
| Artefakt | Kdy vzniká | Co nese | Životnost |
|
||
|---|---|---|---|
|
||
| **Repo / kód / diff** | pořád | kompletní stav implementace | trvalá |
|
||
| **Spec / plan soubor** | při plánování | zadání, constrainty, done-when | do konce úkolu |
|
||
| **Handoff brief** | při ukončování session | rozhodnutí, vyloučené cesty, další krok | jednorázová |
|
||
|
||
**Repo je hlavní artefakt.** Pro pokračování v kódu nepotřebuju vůbec nic
|
||
přenášet: nová session si přečte kód. Historie chatu nenese hodnotu navíc —
|
||
všechno, co v ní bylo smysluplného, je buď v kódu, nebo patří do briefu
|
||
(rozhodnutí a vyloučené cesty **nejsou** v kódu vidět, proto brief existuje).
|
||
|
||
**Handoff brief — kdo ho píše: model, ne já.** Low-effort postup na hranici
|
||
session (před `/clear`, před ukončením práce):
|
||
|
||
1. Jedna zpráva: „sepiš handoff: cíl, constrainty, padnutá rozhodnutí,
|
||
vyloučené přístupy a proč, soubory které se týkají, další krok."
|
||
2. Uložit do souboru (tmp/plán/noty), 30 s review.
|
||
3. `/clear`, nová session: „přečti <soubor>; úkol: <X>; hotovo když <Y>."
|
||
|
||
Moje práce: jedna věta + 30 sekund review. (Anthropic o /clear říká „you write
|
||
down what matters" — varianta s model-drafted briefem je naše zjednodušení;
|
||
caveat: model píše brief s plným kontextem, tedy ve slabším stavu, proto to
|
||
review. Zkrácená verze: klíčová rozhodnutí/vyloučené cesty si nadiktuju sám,
|
||
model doplní stav souborů.)
|
||
|
||
**Proč to není zbytečná práce:**
|
||
- píše se **jednou na hranici session**, ne průběžně
|
||
- je to pár vět, ne dokumentační projekt
|
||
- po použití se brief zahodí; trvalé části odtékají do store, které stejně
|
||
vedu — rozhodnutí → memory.md, opakující se chyba → CLAUDE.md/AGENTS.md
|
||
(OpenAI: „when Codex makes the same mistake twice, update AGENTS.md")
|
||
|
||
**Co se nedělá:** nepřesouvat historii chatu („prosím pokračuj"), nepsat
|
||
retrospektivy, neduplikovat do souborů, co už je v kódu/diffu.
|
||
|
||
**Mapping na současné nástroje:**
|
||
- nanobot project skill už to dělá: memory.md = decision log, state.md =
|
||
handoff brief (activate = „přečti soubor a pokračuj")
|
||
- Claude Code: plan file v repu + CLAUDE.md pro trvalá pravidla
|
||
- Codex: AGENTS.md + skills
|
||
|
||
## Otevřené otázky
|
||
- Kde přesně vede hranice „related task" — dokumentace k hotové feature?
|
||
Anthropic: může zůstat (reread by byl dražší), ale jde o stejný úkol. |