atm-curs-dl/CLAUDE.md

Reguli de lucru în atm-curs-dl

Cerute explicit de user pe 13.09.2026, după o sesiune în care contextul principal s-a umplut cu muncă ce putea fi delegată.

OBLIGATORIU: sesiunea principală e doar orchestrator

Nu executa tu munca de volum. Lansează agenți. Contextul principal e resursa rară: odată umplut, sesiunea se pierde și predarea costă timp.

Faci TU, în sesiunea principală	Dai la AGENȚI
împarți munca și scrii prompturile	citit transcrieri (20-35 mii de cuvinte)
citești rapoartele agenților	scris sumarizări
verificare prin sondaj: 1-2 screenshot-uri per lot	generat și verificat diagrame
git add pe foldere, commit, push	verificat cifre față de transcriere
actualizezi PROGRESS.md și INDEX_TEMATIC.md	căutări largi prin repo
decizi ce e corect când doi agenți se contrazic	audit + render + screenshot

Concret: nu citi o transcriere întreagă ca să scrii tu un sumar. Nu converti tu 60 de diagrame. Nu căuta tu prin toate fișierele. Pentru fiecare din astea, scrie un prompt și lansează un agent.

Ce rămâne al tău, indiferent de cât delegi: commit-urile și mesajele lor, deciziile de conținut, și verificarea prin sondaj a ce raportează agenții. Un raport de agent nu e dovadă — verifică în repo.

Pragul de context: 250k

Un hook (.claude/hooks/context_guard.py, configurat în .claude/settings.json) anunță când contextul trece de 250.000 de tokeni. Când apare anunțul:

1. Salvează starea în PROGRESS.md: ce s-a făcut, ce a rămas, ce rulează.
2. Comite și fă push.
3. Închide agenții care au terminat (SendMessage cu shutdown_request).
4. Spune userului că sesiunea e gata de predat și oprește-te.

Nu începe o sarcină nouă mare după prag. Dacă un agent încă lucrează, cere-i raportul parțial și notează în PROGRESS.md de unde se reia.

Reguli pentru agenți (pune-le în fiecare prompt)

• Același prag de context. „Dacă ajungi la ~250k tokeni, oprește-te, raportează ce ai făcut și ce a rămas, și nu începe altceva."
• Raport scurt. Cere lista de probleme cu dovezi, nu povestea muncii. „ok" pe o linie pentru categoriile curate.
• Fără commit. Agenții lasă fișierele modificate; comiți tu, pe foldere, după ce raportează. Altfel prinzi munca în zbor a altui agent.
• Fără sub-agenți, dacă nu ai cerut explicit — altfel doi agenți scriu în aceleași fișiere și nu mai știi a cui e versiunea din repo.
• Domeniu clar: dă-i fișierele lui, scrie „nu atinge nimic din afara lor", și nu suprapune două domenii.
• Verificare în sarcina lui: audit + render + screenshot pe care să le citească efectiv, nu doar să le genereze.

Verificarea se face tot cu agenți

După orice lot de muncă, lansează un agent de verificare separat de cel care a produs-o. Pe 13.09.2026 au găsit 14 probleme reale pe care auditul mecanic nu le prinde (etichete de R greșite, cifre inventate, un stop etichetat −9% care era −12.6%, contradicții între secțiuni).

Promptul care a funcționat e în PROGRESS.md, secțiunea „VERIFICARE CU AGENȚI".

Monitor pentru cozile de transcriere

Cozile de transcriere (local + moltbot) merg ore întregi. Nu le verifica prin polling — există un monitor care raportează în sesiune când se termină un fișier. Când vine anunțul, lansează agentul de sumarizare pentru transcrierea nouă.

Capcane de orchestrare, pățite

• git add -A cât timp agenții lucrează prinde fișiere pe jumătate scrise. Comite pe foldere, doar după raport.
• Panourile tmux se termină (~10 agenți concurenți). Închide-i pe cei terminați înainte să lansezi alții.
• Un agent care raportează „am terminat" poate avea un sub-agent care încă scrie. Verifică git status înainte să comiți.

Restul regulilor

• Format și conținut pentru sumarizări: STYLE.md.
• Starea proiectului și ce e de făcut: PROGRESS.md.
• Diagramele de preț: STYLE.md, secțiunea „Cum trebuie să arate un grafic de preț"; referința de copiat e gen/exemplu_grafic_real.py.