- import_nota / import_adauga_factura: flux unificat note contabile + articole, sincronizare automata, total factura automat, TVA impartit pe conturile creditoare ale notelor (rundele 1-31) - runda 32: totalurile import_nota pe _label/_textbox din _baza.vcx (Arial 10), fara containerele clb_tx_simplu si fara bifa "Recalculeaza TVA" (recalcul mereu automat); "Sincronizeaza facturile secundare" mutata sub butoane - utile/Teste: harness UI VFP headless (vfp_ui_harness.ps1, ui_harness.prg, precompilare, mock-uri) in radacina; suitele e2e pentru achizitia din import grupate in utile/Teste/achizitie_import/ - docs: flux editare text vcx/scx, testare-ui-vfp si testare-vfp-mcp (mutate din ROAGEST, general valabile), inventar comun, orchestrare subagenti, conventie GO recno, depanare testare VFP Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019DGibQKa5uK4P2TNSFFQNh
41 lines
2.5 KiB
Markdown
41 lines
2.5 KiB
Markdown
# Orchestrare cu subagenti: context mic, misiuni descompuse
|
|
|
|
Regula (valabila in toate proiectele ROA/VFP): un singur subagent care duce o misiune lunga
|
|
(iteratii de teste, investigatii, mai multe sarcini inlantuite) acumuleaza context urias
|
|
(s-a ajuns la ~800k tokens) — calitate degradata, cost mare. Nu se lucreaza asa.
|
|
|
|
## Cum se lucreaza
|
|
|
|
- Sesiunea principala (sau un agent primar) e ORCHESTRATOR: imparte planul pe sarcini
|
|
independente (un test, un audit, un scenariu = o sarcina), monitorizeaza, transmite
|
|
constatarile intre agenti, verifica rezultatele.
|
|
- Fiecare sarcina merge la un SUBAGENT PROASPAT cu prompt autosuficient: context complet
|
|
in prompt + trimitere la un fisier de handoff, nu context acumulat in conversatie.
|
|
- HANDOFF compact pe disc (docs\handoff_*.md, stil telegrafic): inventar livrabile,
|
|
stare, ce ramane, detaliile ne-evidente pe care un agent proaspat nu le-ar putea
|
|
reconstitui usor. Se actualizeaza la fiecare predare de stafeta.
|
|
- PRAG: maxim ~200-250k tokens per subagent. Orchestratorul urmareste dimensiunea
|
|
contextului; la atingerea pragului: cere handoff, inchide agentul, respawneaza unul
|
|
proaspat pe sarcina urmatoare.
|
|
- Sarcinile independente ruleaza in PARALEL (lane-uri), ex. audit read-only + editare teste.
|
|
- Orchestratorul da utilizatorului UPDATE-URI SCURTE de progres, regulat (monitor pe
|
|
artefacte: loguri/fisiere/screenshots; o propozitie-doua la fiecare schimbare relevanta,
|
|
fara naratiune la evenimente fara continut).
|
|
- Orchestratorul MONITORIZEAZA ACTIV subagentii sa nu se blocheze: monitor persistent pe
|
|
artefactele lor + verificare la lipsa de progres (~10 min fara schimbare = suspect):
|
|
procese agatate (vfp9 zombi, dialoguri modale), semafoare orfane, timeout-uri de tool
|
|
(120s implicit) care omoara procese. La blocaj: diagnostic direct (procese, fisiere,
|
|
loguri), mesaj de deblocare cu constatarea concreta, si abia apoi restart daca e cazul.
|
|
- Modele: subagentii care DOAR ruleaza/editeaza teste si alte sarcini de volum/rutina ->
|
|
Sonnet; ORCHESTRATORUL subagentilor (cel care imparte, monitorizeaza, deblocheaza,
|
|
decide) -> Opus (sau sesiunea principala). Commit doar dupa review-ul diff-ului de
|
|
catre om (vezi reguli_lucru.md).
|
|
|
|
## Semne ca ai gresit impartirea
|
|
|
|
- Acelasi agent primeste "inca o sarcina" a treia oara -> trebuia agent nou + handoff.
|
|
- Agentul re-descopera capcane deja documentate -> handoff-ul/docs-ul e incomplet;
|
|
completeaza-l, nu repeta investigatia.
|
|
- Orchestratorul face el insusi munca de volum -> deleaga si pastreaza-si contextul
|
|
pentru decizii, verificari si deblocari.
|