sync SVN r18175

This commit is contained in:
2026-09-17 22:44:24 +03:00
parent 04a78f99db
commit 30fee191f3
9 changed files with 1541 additions and 0 deletions

View File

@@ -0,0 +1,98 @@
# Progres QA factura/aviz
Plan: `docs/plan_qa_factura_aviz.md` (aprobat 17.09.2026, mandat de executie continua).
Acest fisier spune **unde s-a ajuns**, nu ce e de facut. Se actualizeaza dupa FIECARE story.
Harti de pornire (read-only, nu se refac):
`docs/qa_factura_harta.md` - harta de cod a formularului
`docs/qa_factura_unelte.md` - harness UI, headless, Oracle, hook-uri existente
## Stare pe story
| Story | Stare | Unde |
|---|---|---|
| S0 prototip context/handoff | **TERMINAT** 17.09.2026 | `docs/handoff_activ.md` |
| S1 baseline QA cu capturi | de facut, **pe VM 304** | - |
| S2 cautare articole | de facut | - |
| S3 selector lista de preturi | blocat pana se citeste `pack_facturare.cursor_preturi` | - |
| S4 zona totaluri+discount | de facut, mockup inainte | - |
| S5 regresie | de facut | - |
## S0 - terminat (doua runde)
**Runda 2 (dupa ce prima s-a dovedit nedovedita).** Prima varianta a lui S0 a fost probata doar
cu stdin sintetic; in ciclul real bucla a continuat. Am instalat logare temporara pe hook si am
capturat inputul real al lui `SubagentStop`. Ce a iesit:
- `stop_hook_active` EXISTA in input si trece pe `true` la a doua declansare - garda e corecta.
Bucla observata venea de la agenti porniti inainte de fix.
- Mecanismul buclei: mesajul injectat trezeste agentul idle, el raspunde, redevine idle, hook-ul
se declanseaza iar.
- **Inputul contine `agent_transcript_path`** - transcriptul separat al subagentului oprit.
Deci un hook POATE masura contextul fiecarui subagent, nu doar al sesiunii.
Consecinta: `context_watch.ps1` are acum `-Subagent` (citeste `agent_transcript_path`, praguri
150k/200k, mai joase decat la sesiunea principala) si `-Json` (ambaleaza in
`hookSpecificOutput`). Garda `stop_hook_active` a intrat in script, deci comanda hook-ului e o
singura linie. Logarea temporara e scoasa.
Probe pe input real capturat: subagent peste prag -> mesaj cu numele agentului si 40k; sub prag
-> tacere; `stop_hook_active=true` -> tacere. Comis: `9823f1e` pe `qa-factura-s0`.
Compromis acceptat: mesajul vechi "verifica daca subagentul si-a scris starea pe disc" nu mai
apare la fiecare oprire, ci doar in avertismentul de context.
**Corectie de fond**, dupa ce Marius a contestat afirmatia: e fals ca "niciun hook nu poate afla
contextul". Niciun hook nu primeste tokenii de-a gata (nici `command`, nici function hook din
SDK), dar orice hook primeste `transcript_path` si poate citi singur `usage` din JSONL. Doar
`statusLine` primeste `context_window.used_percentage` gata calculat, si nu e hook.
Detalii condensate in `docs/handoff_activ.md`.
## S0 - runda 1
Trei modificari, toate probate (rezultatele probelor sunt in `docs/handoff_activ.md`):
1. `C:\Users\mmari\.claude\settings.json`, hook `SubagentStop`: garda `stop_hook_active`. Era un
`echo` static care reinjecta acelasi `additionalContext` la fiecare oprire de subagent - de
aici bucla observata azi (patru agenti invartindu-se in gol). Backup:
`settings.json.bak_20260917`.
2. `D:\ROA\ROAGEST\COMUN\utile\context_watch.ps1`: parametru nou `-StareFile`. La atingerea
pragului scrie/inlocuieste un singur antet pe primul rand al fisierului de stare
(`<!-- context_watch: data ora | tokeni: N | nivel: ... -->`), fara sa atinga restul
continutului. Fara `-StareFile` comportamentul e neschimbat.
3. `settings.json`, `env`: `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`. Pus initial pe 70 - **gresit**:
fereastra e 1M, deci 70% = 700k, la trei ori distanta de pragul de handoff de 250k. Marius a
prins eroarea. Valoarea corecta, aplicata: **30** (=300k), imediat peste pragul max de 275k.
Ce s-a stabilit si nu se mai rediscuta:
- Compactarea **nu** poate fi declansata programatic dintr-un hook. Mecanismul ramas: hook
avertizeaza -> modelul scrie handoff-ul -> compactarea vine singura la pragul coborat.
- Niciun hook nu primeste numarul de tokeni. Singura sursa e transcriptul JSONL
(`transcript_path`), pe care `context_watch.ps1` il citea deja.
- `D:\ROA\ROAGEST\COMUN` si `D:\ROA\ROAFACTURARE\COMUN` sunt checkout-uri separate ale aceluiasi
repo `comun.git`. Scriptul e deci deja in biblioteca partajata; nu trebuie mutat.
Ramas deschis din S0:
- Proba pe un ciclu real cu subagent viu (garda a fost probata in izolare, cu stdin sintetic).
Se confirma implicit la prima rulare de subagent din sesiunea urmatoare.
- `settings.json` trimite la `context_watch.ps1` prin calea din checkout-ul ROAGEST. Pe VM 304
trebuie verificat ca `D:\ROA\ROAGEST\COMUN\utile\context_watch.ps1` exista acolo, altfel
hook-ul tace fara sa dea eroare.
## VM 304 - ce s-a aflat
Proxmox VM ID 304 "Win11-Marius", nod `pvemini`, clona lui VM 303.
Acces probat si functional: `ssh root@10.0.20.201 'qm agent 304 ping'` -> raspunde;
comenzi in VM prin `qm guest exec 304 -- <cmd>`. **Nu exista share UNC** catre discul ei.
Documentatia NU mentioneaza VFP sau client Oracle instalat - de verificat pe teren, planul le
presupune. Credentialele sunt documentate in `E:\proiecte\ROMFASTSQL\docs\` (nu se copiaza).
Marius a cerut explicit copierea directa si `roa_sync` rulat pe VM. Pachetul de pornire e
pregatit in scratchpad (`pachet_vm304\` cu `PORNIRE.md` + cele 8 documente + `context_watch.ps1`);
roa_sync pe VM a fost anulat (svn fara credentiale in sesiunea 0); il ruleaza Marius.
## Urmatorul pas
S1, **pe VM 304**: sesiune noua care porneste din `docs/plan_qa_factura_aviz.md` + acest fisier.
Baseline vizual pentru FACTURA si AVIZ, capturi la 1366x768 si maximizat, dovada pentru
constatarile C2, C4, C6 si C8 din plan. Nicio modificare de cod in S1.