diff --git a/docs/depanare-server-update-roa.md b/docs/depanare-server-update-roa.md
index 32b03d4..71a6cf3 100644
--- a/docs/depanare-server-update-roa.md
+++ b/docs/depanare-server-update-roa.md
@@ -177,3 +177,94 @@ Dupa kill, totul revine imediat - nu e nevoie de restart de sit sau de recycle d
 
 De urmarit daca se repeta: de ce se agata linkul `DBL_ROMFAST2` spre 10.0.20.36 (timeout de retea
 fara detectie - merita un `SQLNET.EXPIRE_TIME` / `outbound_connect_timeout` pe link-ul respectiv).
+
+## Anatomia fallback-ului PACK_UTILS: de ce ORA-29024 nu inseamna certificat
+
+Referinta: `SCRIPTURI_CLAR/2026/09/co_2026_09_16_02_COMUN_PACK_UTILS.sql`.
+
+`URL2Clob` (linia 333) si `URL2Blob` (linia 284) lucreaza pe **acelasi** `tcURL` si au **doua**
+ramuri de transport una dupa alta; nu exista un URL separat "fara SSL". URL-ul vine din
+`optiuni.UPD_URL_APP` (vezi mai sus).
+
+**Ramura 1 - curl extern.** Se intra doar daca `SERVER_INFO.POWERSHELLDOWNLOAD = '1'`
+(`URL2Clob`:347, `URL2Blob`:298). `DownloadFileOS` (`URL2Clob`:353, `URL2Blob`:304) scrie un script
+PowerShell cu `curl.exe -k -o "<dest>.part"` (linia 756), il ruleaza prin `sys.ExecuteScriptOS`
+(linia 766) si asteapta prin polling pana la `SERVER_INFO.POWERSHELLTIMEOUT` secunde (implicit 60:
+linia 696, bucla liniile 771-775) sa apara fisierul final; redenumirea din `.part` o face
+`$LASTEXITCODE` (linia 758). Criteriul de succes e **doar existenta fisierului**
+(liniile 772-773 si 777-778).
+
+**Ramura 2 - HTTPURITYPE.** Se atinge cand `llDownloaded = FALSE` **sau** cand
+`POWERSHELLDOWNLOAD <> '1'`: nu exista `ELSE`, se cade direct la
+`HTTPURITYPE.createuri(tcURL).getclob()` (`URL2Clob`:367) / `getblob()` (`URL2Blob`:318). Pe URL
+`https` fara wallet, asta da **mereu** `ORA-29273 / ORA-29024`.
+
+**Consecinta - miezul sectiunii.** Codul de iesire al `curl.exe` (conexiune refuzata, timeout, 502)
+e folosit doar ca sa se decida daca `.part` se redenumeste (linia 758); valoarea nu se logheaza si nu
+se pastreaza nicaieri. Singurul semnal care ajunge inapoi la Oracle ramane `llDownloaded = FALSE`.
+De aceea `ORA-29024` e zgomotul caderii, nu cauza, si cauza reala trebuie reconstruita din alta
+parte (`v$session`, log-ul serverului de update).
+
+**Ce sa verifici cand vezi ORA-29024**, in ordinea asta:
+
+1. raspunde serverul de update pentru clientul ala? (`curl` de pe client, vezi mai sus);
+2. `POWERSHELLDOWNLOAD` e `'1'` pe instanta clientului?
+3. `ExecuteScriptOS` functioneaza pe instanta (POWERSHELLPATH completat, drepturi, directorul de
+   descarcare scriibil)? Un job `EXEC_PS_*` cu `SUCCEEDED` **nu** dovedeste ca si `curl` a reusit:
+   scriptul iese cu 0 si cand descarcarea a esuat. Un `<fisier>.part` ramas in DMPDIR arata ca
+   procesul nativ nu a fost asteptat.
+4. abia la urma wallet-ul / certificatele - si numai daca cineva chiar vrea ramura 2.
+
+## Incident 16.09.2026 (2): ROMFAST 10.0.20.36, acelasi simptom
+
+Stare, nu concluzie.
+
+**Fapt.** Pe serverul Oracle de productie ROMFAST (`10.0.20.36`) actualizarea esueaza cu stiva
+`ORA-29273 / ORA-29024`, cu `PACK_UTILS` linia 313 si 305, `PACK_UPDATE` linia 323 si 180.
+
+**Fapt (masurat de pe statia de lucru, 16.09.2026).** `curl https://roa.romfast.ro/contafinupdate/roaupdate/`
+-> HTTP 200 in 0.127s; `curl http://10.0.20.122/` -> HTTP 404 in 0.0016s de la
+`Microsoft-HTTPAPI/2.0`. Al doilea e normal - situl real e pe portul 81, cu ruta `/contafinupdate/...`,
+iar 404-ul de la `http.sys` **nu** inseamna server picat. Deci serverul de update raspundea la ora
+verificarii.
+
+### Cauza: `&` nu asteapta procesul sub jobul extern
+
+Configuratia era corecta: `POWERSHELLDOWNLOAD = 1`, `POWERSHELLTIMEOUT = 30`, `POWERSHELLPATH`
+completat, NTFS pe `C:\DMPDIR` cu `Authenticated Users:(M)`. `sys.ExecuteScriptOS` functiona -
+joburile `EXEC_PS_*` apar in `dba_scheduler_job_run_details` cu `SUCCEEDED`.
+
+**Sub jobul DBMS_SCHEDULER `job_type => 'executable'` (proces fara consola), operatorul `&` din
+PowerShell nu asteapta procesul nativ.** Masurat prin acelasi mecanism:
+
+```
+t0=23:07:08.671
+t1=23:07:08.707   ec=[]   exists=False     <- la 36 ms dupa lansarea curl
+t2=23:07:13.735           exists=True      <- dupa Start-Sleep 5
+```
+
+Deci `$LASTEXITCODE` nu e niciodata setat, `if ($LASTEXITCODE -eq 0)` e FALSE (`$null -eq 0`), se
+executa ramura `else` pe un fisier inca inexistent, iar `curl` termina descarcarea dupa ce scriptul
+s-a incheiat si lasa `<destinatie>.part` pe disc definitiv. Fisierul destinatie nu apare niciodata ->
+polling-ul expira dupa `POWERSHELLTIMEOUT` -> `HTTPURITYPE` -> `ORA-29273 / ORA-29024`.
+
+Codul anterior scria cu `curl -o` direct in fisierul destinatie: neavand pas de redenumire, nu
+depindea de terminarea lui `curl`, iar bucla de polling astepta oricum aparitia fisierului. Pasul
+`Move-Item` introdus pe 16.09.2026 a facut ca asincronia sa conteze - de aceea simptomul apare la
+prima rulare de dupa recompilare.
+
+**Reparat** in `co_2026_09_16_06_COMUN_PACK_UTILS.sql`: lansarea asteapta explicit procesul si ii
+citeste codul de iesire.
+
+```powershell
+$p = Start-Process -FilePath '<curl>' -ArgumentList '-k','-o','<dest>.part','<url>' -Wait -PassThru -NoNewWindow
+if ($p.ExitCode -eq 0) { Move-Item ... } else { Remove-Item ... }
+```
+
+Dupa aplicare pe ROMFAST: `URL2Clob` intoarce documentul complet in ~2s, iar `PACK_UPDATE.UpdateROA`
+s-a incheiat cu `UPDATEROA_JOB` SUCCEEDED.
+
+**Ramas de verificat.** Capatul departat al db link-ului `DBL_ROMFAST2` este chiar `10.0.20.36`; la
+incidentul conpress s-a omorat sesiunea de pe partea apropiata (ROA_CENTRAL), fara sa se fi privit
+vreodata partea departata. Cele doua incidente pot avea radacini diferite - acesta nu il explica pe
+celalalt.