Začalo to nevinnou prosbou #

Měl jsem v Projektu na claude.ai připojený svůj GitHub repozitář a chtěl jednu prostou věc: ať mi Claude vezme jeden konkrétní soubor, celý, beze změny, a napíše mi, že ho má. Nic víc. Žádné úpravy, žádné vylepšování, jen „stáhni to a potvrď".

Místo toho se odpověď začala kroutit. Nejdřív Claude tvrdil, že soubor zkusí stáhnout z živého webu, a snažil se načíst adresu, která s úkolem vůbec nesouvisela. Když jsem ho zarazil otázkou, k čemu mám připojený repozitář, když se do něj ani nepodívá, otočil se: ano, repozitář prý dostupný má, ale jen přes vyhledávání, které mu vrací relevantní úryvky souborů, ne celé soubory najednou. A u dlouhého souboru že nemůže zaručit, že hledání vrátí úplně všechno.

Mám pravidlo, podle kterého se mnou modely pracují: nikdy needituj soubor, ke kterému nemáš kompletní originál. Vzniklo z bolesti, z hodin debugování po tom, co model „opravil" něco, co vidět neměl. A přesně tady to pravidlo narazilo na technickou realitu, kterou jsem do té chvíle neznal pojmem, jen pocitem.

Protože ta kostrbatá, vytáčející se odpověď měla v jádru pravdu. Ten výlet na živý web byl nesmysl a vysvětlení bylo zmatené. Ale tvrzení „nevidím celé soubory, jen nad nimi vyhledávám" věcně sedělo. A to je věc, kterou stojí za to rozebrat, protože boří iluzi, kterou má skoro každý: že připojený repozitář znamená, že Claude zná můj kód.

Dvě „připojení", která vypadají stejně #

Větu „Claude má připojený GitHub repozitář" si lidé představují jako jednu věc. Ve skutečnosti se za ní skrývají dva úplně různé světy, každý postavený na jiném principu.

A) Projekt na claude.ai s GitHub integrací. Pasivní znalost. Vybrané soubory se zkopírují jako snímek do projektových znalostí a Claude nad nimi přemýšlí. Je to read-only. Žádné commity, žádné spuštění kódu, žádné PR.

B) Claude Code. Aktivní agent. Běží v prostředí s přímým přístupem k souborům a gitu, čte celé soubory, edituje je, spouští příkazy, commituje a otevírá pull requesty.

Přirovnání, které to vystihuje: A je kolega, kterému dáš přečíst dokumentaci, aby ti poradil. B je kolega, který si tu práci reálně otevře a udělá. Já jsem pracoval v režimu A, ale očekával chování režimu B. Chtěl jsem agentní operaci („vezmi soubor a měj ho") po nástroji, který na to není stavěný.

Co Projekt s repozitářem reálně dělá #

Když do Projektu přidáš repozitář, vybereš v prohlížeči konkrétní soubory a složky a jejich obsah se přidá do projektových znalostí. Přes ikonu „Sync" si ručně stáhneš nejnovější verzi, přes „Configure files" měníš, které soubory Claude vidí. Je to kontext pro analýzu a diskuzi nad kódem, ne nástroj na zápis.

A teď to klíčové. Projekt pracuje ve dvou režimech podle toho, kolik znalosti do něj nasypeš.

In-context režim (malá znalost)

Dokud se znalost vejde do kontextového okna, Claude má soubory načtené celé a doslovně. Tady „stáhni mi celý soubor" funguje, protože ho má před očima v plném znění.

RAG režim (velká znalost)

Když se znalost blíží limitu kontextového okna, Projekt se automaticky přepne do RAG režimu, který kapacitu rozšíří až desetinásobně. Místo aby načetl celý obsah, použije nástroj project knowledge search a vytáhne jen úryvky, které jsou pro daný dotaz nejrelevantnější. Claude doslova nemá celý soubor před očima, dotazuje se nad indexem a dostává chunky, které se „trefily".

Že jsi v tomhle režimu poznáš. Objeví se vizuální indikátor, že je projekt v RAG režimu, a v chatu hláška ve stylu „To save space in chats, Claude will look up specific information as needed". To je ten viditelný signál, že od téhle chvíle Claude nečte celé soubory, jen nad nimi hledá.

A teď pikantní detail, který vysvětluje můj případ. Oficiálně se RAG zapíná, „když se znalost blíží limitu kontextového okna", tedy podle objemu v tokenech. Jenže existuje doložený nahlášený případ, kdy se režim přepnul mnohem agresivněji: práh se zřejmě odvíjel od počtu souborů, ne od jejich velikosti. RAG se aktivoval už při třinácti souborech o necelých 73 000 tokenech, tedy při zhruba dvou procentech kapacity.1 A repozitář má z principu hodně souborů. Takže ve chvíli, kdy ho připojíš, skoro jistě okamžitě spadneš do RAG režimu, i kdyby ten kód nebyl velký. Od té chvíle žádný soubor nevidíš celý.

Důsledky jsou tři a všechny jsem na sobě zažil: žádná garance úplnosti dlouhého souboru, žádný živý stav (pracuje se se snímkem, dokud nedáš Sync), a ztráta kontextu napříč soubory, protože co se nevejde do vrácených úryvků, jako by nebylo.

Je to přesně ten RAG z tohoto seriálu #

Tohle je moment, kdy se kruh celého seriálu uzavírá. To, co se mi stalo, není žádná zvláštní funkce Projektů. Je to doslova ten RAG, který jsme tu popisovali pět dílů.

Už v úvodním díle o práci s vlastními daty v LLM jsem v sekci o limitech, o kterých výrobci nemluví, zmínil, že se Claude Projects umí automaticky přepnout do RAG módu. Tady je ta nitka splacená příběhem.

Mechanika je přesně ta z dílu RAG technicky: obsah se rozseká na chunky, ty se zaindexují jako embeddingy a při dotazu se přes kosinovou podobnost vrátí jen sémanticky nejbližší úryvky. A slabiny jsou přesně ty z dílu RAG v praxi: chunkování láme myšlenku, retrieval umí minout relevantní pasáž, když je formulovaná jinak než dotaz, a souvislosti napříč soubory se ztrácejí, protože každý chunk se hledá samostatně.

Jediné, co je nové, je kontext, ve kterém tě to potká. V seriálu RAG stavíš schválně, jako nástroj nad vlastní databází. Tady ti naskočí sám, potichu, nad tvým vlastním kódem, aniž by sis ho objednal. Iluze zní „Claude teď zná můj repozitář". Realita je „Claude má zaindexovanou kopii a dostává z ní střípky".

Druhý svět, Claude Code jako agent #

Proti pasivní znalosti stojí Claude Code, a je to jiná liga. Není to jednoduché API volání, které pošle prompt a vrátí text. Je to celý běhový agent s přímým přístupem k repozitáři, struktuře souborů, git historii a diffu, který čte soubory, uvažuje ve více krocích a používá nástroje.

V praxi to znamená, že přes zmínku @claude v issue nebo pull requestu umí analyzovat kód, implementovat funkci, opravit bug a založit PR. Když se napojuje na GitHub, nevidí jen vybrané soubory, ale celou strukturu projektu, a se soubory reálně pracuje, ne nad nimi jen hledá.

Důležité je, že tahle moc je podmíněná právy, která mu udělíš. GitHub App si při instalaci říká o oprávnění Read & write pro Contents, Issues a Pull requests, aby mohl měnit soubory a otevírat PR. Pokud chceš agenta jen na čtení a komentáře, musíš si least-privilege nastavit sám, třeba contents: read.2

To je ten kolega z přirovnání, který si práci otevře a udělá. Když chceš reálné úpravy souborů, commity a verzování, tohle je nástroj, ne Projekt.

Jak teda dostat celý soubor #

Tahle část je pointa, protože v původní frustrující odpovědi chybělo úplně nejdůležitější: řešení existují, a hned tři.

1. Vlož soubor přímo do chatu

Nejjednodušší a nejbezpečnější. Otevřeš soubor v GitHubu, zkopíruješ ho celý do zprávy, a Claude ho má zaručeně kompletní, doslovně, beze ztráty. Pro úpravu jednoho souboru 1:1 je tohle skoro vždy nejlepší volba. Mimochodem přesně tohle dělá moje pravidlo „vyžádej si originál", aniž bych do té doby tušil proč technicky.

2. Zúži výběr přes „Configure files"

Když opravdu chceš pracovat z připojeného repozitáře, vyber jen pár klíčových souborů, ne celé repo. Čím méně znalosti, tím větší šance, že zůstaneš v in-context režimu, kde Claude vidí soubory celé. Oficiální doporučení k integraci ostatně zní začít s malou podmnožinou kódu a teprve postupně přidávat.

3. Sáhni po Claude Code

Když nejde o porozumění, ale o reálnou práci se soubory, jejich úpravu, commity a PR, je správný nástroj Claude Code, ne Projekt. Tam je přímý souborový přístup vlastností, ne náhodou.

Rozhodovací vodítko: jde mi o porozumění kódu, diskuzi nad ním, návrhy? Projekt stačí, ale počítej s tím, že u většího repa jsi v RAG režimu a nedostáváš celé soubory. Jde mi o úpravu konkrétního souboru, kde záleží na úplnosti 1:1? Vlož ho do chatu. Jde mi o reálné zásahy do repozitáře, commity, PR? Claude Code.

Proč „vyžádej si originál" není paranoia #

Když to spojím dohromady, moje pracovní pravidlo a tahle technická limitace jsou dvě strany téže mince. V RAG režimu se na úplnost dlouhého souboru spolehnout nedá, takže vyžádat si originál je racionální obrana, ne přehnaná opatrnost.

Obecnější poučení je jednoduché: vědět, ve kterém režimu zrovna jsi. Viditelný signál máš, ta hláška o vyhledávání informací podle potřeby a indikátor RAG režimu. Když ji vidíš, neptej se modelu na doslovnou reprodukci dlouhého souboru, protože ji nemá z čeho vzít. Buď zúži znalost, nebo soubor vlož, nebo přejdi na Claude Code.

A na rovinu, ať je verdikt spravedlivý: ten Claude v mém příběhu nešidil podstatu, limitace, kterou popsal, je skutečná. Co odflákl, byla diagnóza a komunikace. Místo „jsem v RAG režimu, protože repo má moc souborů, proto ti vracím jen úryvky, a tady jsou tři způsoby, jak to obejít" plácal o přístupu přes projektové znalosti, tvářil se zmateně a řešení nechal na mně. To je dobrá připomínka, že nestačí mít pravdu, je potřeba ji umět vysvětlit.