Když jeden PROJECT_MEMORY.md nestačí: jak si vytvořit společný pohled napříč AI projekty

Jak jsem z jednotlivých projektových pamětí vytvořila společný rozhodovací pohled a proč odděluji kontrolu zdrojů od AI interpretace.

Když jsem začala držet kontext přímo u jednotlivých projektů, návraty k práci byly jednodušší. Codex nebo Claude Code si dokázaly přečíst aktuální stav, rozhodnutí a otevřené otázky. Při každé nové session jsem už nemusela vysvětlovat celý průběh od začátku.

U více projektů ale zůstávala další vrstva práce.

Ráno jsem stále potřebovala otevřít jeden projekt za druhým a zjišťovat, co se od poslední kontroly posunulo, co zůstalo otevřené, kde chybí rozhodnutí a kterému projektu mám věnovat pozornost.

Projektová paměť vyřešila pokračování uvnitř jednotlivých projektů. Pro orientaci napříč nimi jsem potřebovala společný rozhodovací pohled.

Tak začala vznikat portfoliová vrstva mého AI Project Memory.

Dvě různé úlohy projektové paměti

Při práci s více projekty mi pomáhá rozlišovat dvě vrstvy.

Projektová paměť drží detail konkrétního projektu. Zachycuje jeho cíl, aktuální stav, rozhodnutí, otevřené otázky a další krok.

Portfoliová paměť tento detail neopakuje. Vybírá z něj pouze informace potřebné pro rozhodování.

Pokud mám pět projektů, ráno nepotřebuji pět dlouhých souhrnů. Potřebuji vědět, který projekt se změnil, kde čeká moje rozhodnutí, kde chybí důkaz a které dvě nebo tři věci si zaslouží pozornost.

Kdy má společná vrstva smysl

Portfoliovou paměť bych přidávala až tehdy, když funguje paměť jednotlivých projektů.

Pokud jsou vstupy neaktuální nebo nejasné, společný přehled tuto nejistotu jen přenese výš. Výsledek může vypadat přesvědčivě, ale bude stát na slabých podkladech.

Před vytvořením společné vrstvy by proto mělo být u každého aktivního projektu jasné:

• jaký je jeho aktuální stav,
• který další krok je platný,
• jaká rozhodnutí už byla udělána,
• co zůstává otevřené,
• ze kterých souborů nebo důkazů tyto informace vycházejí.

Nové návrhy by zároveň měly zůstat odlišené od potvrzeného stavu. Portfoliový přehled má vycházet z toho, co dnes platí, a otevřeně ukázat místa, kde to potvrdit neumíme.

Jak vytvořit první PORTFOLIO_MEMORY.md

Na první pokus nepotřebujete ranní automatizaci ani kontrolní skripty. Stačí, aby každý projekt obsahoval aktuální PROJECT_MEMORY.md.

Nad nimi si můžete vytvořit jeden společný výstup:

PORTFOLIO_MEMORY.md

Jeho struktura může vypadat například takto:

# Portfolio Memory

Review date:
[DATE]

Review window:
[FROM] – [TO]

## Project A

Status:
Updated / Confirmed no change / Needs confirmation

What changed:
...

Current next step:
...

Needs my decision:
...

Missing context or evidence:
...

Source:
[path to PROJECT_MEMORY.md]

## Project B

Status:
...

## Moje pozornost teď

1. ...
2. ...
3. ...

## Projekty bez potřebné akce

...

Výstup má zůstat krátký. Pokud potřebuji technický detail, otevřu si konkrétní projekt. Úkolem portfoliového pohledu je pomoci mi rozhodnout se, kam jít dál.

První přehled může vzniknout manuálně pomocí jednoho promptu:

Pracuji na více projektech.

Každý projekt obsahuje soubor PROJECT_MEMORY.md s aktuálním stavem,
rozhodnutími, otevřenými otázkami a dalším krokem.

Přečti PROJECT_MEMORY.md v těchto projektech:

1. [PATH TO PROJECT A]
2. [PATH TO PROJECT B]
3. [PATH TO PROJECT C]

Připrav návrh PORTFOLIO_MEMORY.md.

U každého projektu uveď:

1. aktuální stav,
2. co se od poslední aktualizace změnilo,
3. nejbližší konkrétní krok,
4. co potřebuje moje rozhodnutí,
5. zda chybí kontext nebo důkaz,
6. zdroj, ze kterého informace vychází.

Použij jeden ze tří stavů:

- Updated,
- Confirmed no change,
- Needs confirmation.

Potom vytvoř sekci:

## Moje pozornost teď

Vyber maximálně tři položky napříč projekty, které si podle
dostupných podkladů vyžadují moji pozornost.
Při pořadí zohledni:

- zablokovanou další práci,
- chybějící rozhodnutí,
- riziko,
- termín,
- dopad na ostatní projekty.

Rozlišuj mezi:

- potvrzeným stavem,
- doporučením,
- chybějící informací.

Pokud něco nedokážeš potvrdit, označ:
JE TŘEBA POTVRDIT.

Nevymýšlej chybějící kontext.
Neupravuj jednotlivé PROJECT_MEMORY.md.
Nejprve mi ukaž návrh.

Při prvních bězích bych tento proces spouštěla manuálně. Uvidíte, zda je společný pohled přesný, zda některý projekt nedostává nepřiměřeně mnoho pozornosti a zda vstupní Project Memories obsahují dost aktuálního kontextu.

Jak vyhodnotit stav každého projektu

Mně se osvědčily tři jednoduché stavy.

Updated

V projektu vznikla relevantní změna. Může jít o upravený zdrojový soubor, nový výstup, změnu tasku nebo potvrzené rozhodnutí.

Tento stav by neměl znamenat jen to, že se v projektové složce změnil libovolný soubor. Potřebujeme vědět, že změna ovlivňuje samotný projekt nebo jeho další krok.

Confirmed no change

Projekt byl zahrnut do kontroly a od posledního checkpointu se v něm nic relevantního nezměnilo.

Toto označení je důležité. Ukazuje rozdíl mezi projektem, který byl zkontrolován bez změny, a projektem, na který se při kontrole zapomnělo.

Needs confirmation

Stav projektu nedokážeme spolehlivě vyhodnotit.

Může chybět aktuální projektová paměť, zdroj, přístup nebo důkaz o tom, co se stalo. Takový stav má zůstat viditelný. Portfoliová vrstva by ho neměla potichu nahradit odhadem.

Jak ověřit, které projekty se skutečně změnily

U první verze můžete vycházet z data aktualizace PROJECT_MEMORY.md. Později se ale ukáže, že samotný čas změny nemusí stačit.

Projekt může vypadat jako aktualizovaný, protože proběhl build, vznikl testovací výstup, změnil se pomocný soubor nebo předchozí automatizace vytvořila vlastní souhrn. Samotná práce se přitom nemusela posunout.

Proto jsem postupně začala používat Git jako vrstvu důkazů.

Git mi pomáhá zjistit, které soubory se změnily, od jakého checkpointu a co bylo před změnou a po ní. Dokážu také odlišit zdrojové soubory od odvozených výstupů, které nemají ovlivnit stav projektu.

Model pak nemusí hledat změnu v celém projektu. Dostane konkrétní soubory nebo diff, jejichž význam má interpretovat.

Tím vzniká důležité rozdělení:

1. jednodušší kontrola zjistí, kde nastala změna,
2. AI vyhodnotí, co tato změna znamená.

Jak oddělit kontrolu zdrojů od AI interpretace

Před zapojením modelu lze ověřit několik věcí bez potřeby jazykového porozumění:

• které projekty jsou registrované,
• zda jsou jejich zdroje dostupné,
• zda se od posledního checkpointu změnily,
• zda mají aktuální projektovou paměť,
• zda už neprobíhá jiný kontrolní běh.

Až potom AI interpretuje význam změněných podkladů.

Zjednodušený flow vypadá takto:

PROJECT A → PROJECT_MEMORY.md ┐
PROJECT B → PROJECT_MEMORY.md ├→ kontrola zdrojů
PROJECT C → PROJECT_MEMORY.md ┘
                                  ↓
                    Updated / No change / Confirm
                                  ↓
                     relevantní soubory a rozhodnutí
                                  ↓
                         AI interpretace
                                  ↓
                       PORTFOLIO_MEMORY.md

Toto rozdělení snižuje riziko, že některý projekt vypadne z kontroly nebo že model opakovaně čte projekty, ve kterých se nic relevantního nestalo.

Kde používám AI a kde pevná pravidla

U každého kroku mi pomáhá otázka:

Potřebuje tento krok pochopit význam, nebo jen ověřit jasnou podmínku?

AI používám hlavně pro interpretaci změněných souborů, spojení kontextu z více zdrojů, rozlišení výsledku a překážky, přípravu krátkého souhrnu a návrh priorit.

Pevná pravidla nebo skripty používám pro kontrolu toho, zda byly zahrnuty všechny projekty, zda projekt existuje, zda se změnil, zda má výstup povinné sekce a zda už neprobíhá jiný běh.

Model tak dostává prostor tam, kde potřebuji úsudek. Kód drží konzistentnost tam, kde je pravidlo jednoznačné.

Proč první verze spotřebovala příliš mnoho kontextu

První automatizovaná verze ranního a večerního review vytvářela použitelný přehled, ale četla příliš mnoho.

Model opakovaně dostával pracovní instrukce, celý registr tasků, staré souhrny, širokou historii i projekty, ve kterých se nic relevantního nezměnilo. Některé projekty navíc vypadaly jako aktualizované jen proto, že předchozí běh vytvořil vlastní výstup.

Postupně jsem proto upravila flow tak, aby se všechny projekty nejprve zkontrolovaly bez detailní interpretace. AI dnes čte pouze změněné nebo nejasné projekty a dostává konkrétní balík relevantních podkladů. Buildy, pomocné soubory a manažerské výstupy se z kontroly vyloučí.

Systém zároveň kontroluje, zda už neprobíhá jiný běh. Duplicitní proces tak může skončit dřív, než znovu pošle modelu stejný kontext.

Nejúspornější AI běh je ten, který se nemusí spustit.

Tato věta pro mě neznamená, že je potřeba AI používat co nejméně. Znamená, že má smysl ji zapojit tam, kde potřebujeme porozumět významu. Kontrolu existence souboru nebo času poslední změny zvládne spolehlivěji a levněji jednodušší mechanismus.

Přesnou procentuální úsporu zatím neuvádím. Změnu architektury mám ověřenou, finanční výsledek ještě měřím.

Které změny stále potvrzuje člověk

Portfoliová paměť může připravit kvalitní podklad pro rozhodování. Stále ale nechci, aby model bez kontroly měnil prioritu, ownera, termín, hlavní stav úkolu nebo potvrzené rozhodnutí.

Stejně tak má pod lidskou kontrolou zůstat sloučení dvou tasků, změna jejich významu nebo označení práce jako dokončené bez dostatečného důkazu.

Důvod je praktický. Pokud se pracovní návrh smíchá s potvrzeným stavem, další AI nástroj může velmi efektivně pokračovat špatným směrem.

Systém proto rozděluji do tří kroků:

1. AI čte a interpretuje podklady.
2. AI navrhuje změnu nebo prioritu.
3. Člověk potvrzuje, co bude dál platit.

Nové vstupy ze schůzek, chatů nebo jiných AI nástrojů v mém setupu nejprve směřují do odděleného prostoru ke kontrole. Do hlavního stavu se dostanou až po porovnání s existujícími tasky a potvrzení.

Tento intake proces je samostatná větev systému. Portfoliový pohled má pracovat především s potvrzeným stavem projektů.

Jak používám ranní a večerní pohled

Společná paměť má pro mě dvě praktická použití.

Ráno potřebuji vidět, co se od poslední kontroly posunulo, co zůstalo otevřené, kde chybí rozhodnutí a které maximálně tři priority dávají smysl.

Večer chci zachytit potvrzené výstupy, nedokončenou práci, nové otevřené otázky a další krok.

Detail zůstává v konkrétním projektu. Společný pohled mi má pomoci rozhodnout se, kam jít dál.

Právě tady se ukazuje rozdíl mezi souhrnem a rozhodovacím pohledem. Souhrn může obsahovat všechno, co se stalo. Rozhodovací pohled vybírá pouze informace, které mění moji další akci.

Doporučené pořadí implementace

1. Ověřte projektovou paměť na jednom projektu

Portfoliová vrstva bude jen tak spolehlivá jako její vstupy. Nejprve si proto ověřte, že podle PROJECT_MEMORY.md dokáže jiný AI nástroj správně pochopit projekt a pokračovat.

2. Rozšiřte stejný princip na další aktivní projekty

Jednotlivé projekty nemusí mít identickou technickou strukturu. Potřebují ale obsahovat stejné základní typy informací: aktuální stav, rozhodnutí, otevřené otázky, další krok a zdroje.

3. Vytvořte první manuální portfoliový pohled

Spusťte prompt nad dvěma nebo třemi projekty a zkontrolujte, zda vám výsledek reálně pomáhá rozhodovat. Sledujte, zda vybrané priority nevycházejí jen z poslední změny, ale zohledňují i blokery, termíny a potřebná rozhodnutí.

4. Sledujte opakující se kontroly

Během jednoho nebo dvou týdnů si všímejte, co stále ověřujete stejným způsobem. Může jít o existenci souboru, čas poslední změny, pokrytí projektů nebo povinné části výstupu.

5. Až potom přidávejte skripty a automatizace

Automatizace má smysl tam, kde už rozumíte manuálnímu flow a víte, jaký výstup potřebujete. Jinak může jen zrychlit tvorbu nepřesného nebo málo užitečného přehledu.

Limity společné projektové paměti

Portfoliová paměť mi pomáhá s orientací, stále ale není autonomní project manager.

Kontrolní skript může potvrdit, že byl projekt zahrnut. Nedokáže zaručit, že model správně pochopil význam každé změny.

I výběr tří priorit zůstává doporučením. Model nemusí znát širší obchodní, osobní nebo týmový kontext, který ovlivňuje moje rozhodnutí.

Lidské schválení chrání hlavní stav, zároveň přidává další krok a může se stát úzkým místem. Při týmovém nebo produkčním použití bych proto řešila i technická oprávnění: kdo může kontext číst, kdo může navrhovat změnu a kdo ji může potvrdit.

Hodnota AI Project Memory pro mě nevzniká množstvím uchovaných informací. Vzniká ve chvíli, kdy ráno nemusím otevřít pět projektů, abych zjistila, kde jsem na řadě já.

Pokud s tím začínáte, držela bych jednoduché pořadí: nejprve spolehlivá paměť jednoho projektu, potom manuální společný pohled a až nakonec automatizace.