# Design: Service Auto Web — Learning + Talent-Risk Hedge (rethink v2)

Generated by /plan-ceo-review on 2026-04-11 (pivot from the scrapped 2026-04-10 doc)
Revised by /plan-ceo-review on 2026-04-11 (v2 after HOLD SCOPE review + outside voice)
Branch: feat/service-auto
Repo: romfast/roa2web
Status: ACTIVE
Owner: Marius (ERP patron + sole dev)
Supersedes: `claude-main-design-20260410-205024.md` — premise invalidated (old doc was a product delivery plan; real intent is learning + capability hedge)

## What this is (and what it is NOT)

**This is:** a side-exploration prototype. Part learning project (Vue 3 + FastAPI async +
oracledb + PrimeVue), part strategic hedge against the "VFP is dead and I can't find
programmers" problem. Target = 1 end-to-end screen with 1 SP write, on the existing test
schema MARIUSM_AUTO at the office server `10.0.20.121/ROA`. Budget ≈ 2-4 hrs/week, ≈48-96
hours total over 24 weeks (doubled from the original 12-week plan after sincere budget
recalibration — see Review Corrections).

**This is NOT:** a product, an MVP, a migration plan, or a commitment to ship anything to
any client. The 4 existing clients stay on VFP + Oracle XE local. Zero migration. Zero
customer-facing delivery. Zero timeline pressure.

**The deliverable is NOT a demo.** The deliverable is **a reusable template for future
Oracle-backed modules + a decision log**. See "Final deliverable" below.

## Strategic driver (the one that matters)

Visual FoxPro is a dead language. Marius cannot hire programmers willing to learn it.
Every year on VFP is another year of compounding talent risk on an ERP that powers 4
long-term clients and generates stable revenue. The only realistic path to "someone else
can maintain this eventually" is moving incrementally to web stacks (Python/Vue) where the
labor pool exists.

**Constraint that makes this hard:** Oracle coupling. The ERP has 25 years of PL/SQL,
cross-schema synonyms, tenant-per-schema architecture. Postgres migration is not 1:1 —
the PL/SQL and schema mechanics don't translate cleanly. Therefore the migration path is
**"stay on Oracle, switch UI + business logic layer to Python/Vue, keep PL/SQL as the
durable layer."** Service auto is the lowest-risk place to probe whether this path works.

**Honest caveat on the hedge thesis:** PL/SQL + Oracle domain knowledge is itself a
scarce skill on the Romanian market. This prototype does NOT solve the hiring pipeline
problem for PL/SQL maintainers. What it solves is the Python+Vue+integration layer — the
UI/API half of the stack — where the labor pool is genuinely larger. The hedge is
"replace the half of the stack where hiring is easier"; it is NOT "fix the hiring problem
in one shot." This distinction matters for phase 2 scoping.

**Success definition for this prototype:** after 24 weeks (or sooner), Marius has
direct evidence (working code, not hand-wavy) that the roa2web monolith can drive Oracle
business logic end-to-end via PL/SQL stored procedures, AND a reusable template
documenting exactly how. If that evidence is positive, the same pattern applies to the
next module. If it's negative, Marius knows this before sinking years into it.

## The prototype — minimum viable experiment

One screen, one SP, one test schema, one developer. Absolute scope wall.

### Target feature

**Screen:** `ComandaNoua.vue` — formular creare comandă nouă service auto. Minimal
fields: tip comandă (select 4 opțiuni), client (dropdown **hardcoded în Vue** — 2-3
clienți test cu 1-2 mașini fiecare), operații solicitate (textarea). Submit → backend →
PL/SQL → insert row → return ID → display "Comanda X creată" via **PrimeVue Toast**.

**SP:** `SP_CREEAZA_COMANDA(p_tip IN, p_client_id IN, p_masina_id IN, p_operatii IN,
p_comanda_id OUT, p_numar OUT)`. **Insert într-un tabel DEDICAT de comenzi** (nume real
în MARIUSM_AUTO — de verificat în VFP înainte de a scrie SP-ul, vezi pregătire săpt 3).
**NU inserează în ACT** (registrul jurnal) — ACT se hit-uiește doar la facturare, care e
NOT IN SCOPE pentru prototype. Validare minimă, return ID + număr.

**Schema:** **MARIUSM_AUTO** — schemă dedicată de test, deja existentă pe serverul de la
biroul Marius (`10.0.20.121/ROA`), care nu e folosită de altcineva. Zero conexiune la
schemele de producție ale celor 4 clienți. Zero copy / impdp necesar — schema există deja.

**User Oracle tehnic:** **`ROA_WEB`** — user nou dedicat app-ului FastAPI, cu grants
explicite per SP (`GRANT EXECUTE ON MARIUSM_AUTO.SP_CREEAZA_COMANDA TO ROA_WEB`), fără
acces direct la tabele. Pattern multi-tenant compatibil — același user va avea grants pe
alte scheme în phase 2 dacă probează.

### Things this prototype will probe (the real learning)

Fiecare din acestea e o ipoteză pe care prototype-ul trebuie să o confirme sau să o
infirme:

| # | Ipoteză | Cum o probez |
|---|--------|-------------|
| 1 | `python-oracledb` async cleanly calls PL/SQL proc cu IN+OUT params | Săpt 1 POC: `poc/hello_async_out.py` cu `oracledb.connect_async()` + `cursor.var(oracledb.NUMBER)` + `await cursor.callproc('test_out', [out])`. **GATE**: dacă merge curat, prototype-ul continuă pe true-async. Dacă NU merge, fallback la pattern-ul sync-facade din `treasury_service.py` (deja proof-ed în prod). Fallback e pre-aprobat, NU blochează săpt 2+. |
| 2 | `session_callback` pentru CURRENT_SCHEMA switching nu leak-uiește între requests concurente | Săpt 4: 2 conexiuni paralele pe **aceeași schemă MARIUSM_AUTO**, ambele setează CURRENT_SCHEMA, rulează CALL-uri distincte, verific cu log-uri că nu se încurcă cursor tag reuse. **Limitare acceptată conștient:** testul pe 1 schemă nu dovedește 100% izolarea la multi-schemă — pentru asta ar trebui o a doua schemă test (ex: copie CLEVER), care e în afara budget-ului. Probă de primitive, nu de multi-schemă. |
| 3 | GRANTS de tip "EXECUTE ON SP, zero INSERT/UPDATE/DELETE pe tabele" țin în practică | Săpt 3: user `ROA_WEB` încearcă `INSERT INTO MARIUSM_AUTO.ACT` → `ORA-00942` sau `ORA-01031`; `SELECT * FROM MARIUSM_AUTO.ACT` → `ORA-00942`; `EXEC MARIUSM_AUTO.SP_CREEAZA_COMANDA(...)` → success. Un test automat pytest-marcat `integration` care rulează local. |
| 4 | `RAISE_APPLICATION_ERROR(-20001, 'mesaj cu diacritice ă î ș ț â')` ajunge în Vue ca eroare user-friendly, encoding corect | Săpt 11-12: SP aruncă eroare (client inexistent, tip invalid, operatii gol), serviciul traduce `oracledb.DatabaseError.code` la HTTP status (20001-20999 → 422 business, 12541/12170 → 503 infra, rest → 500), Vue afișează PrimeVue Toast cu mesajul. Obligatoriu test pe un mesaj cu diacritice pentru a proba `NLS_LANG` / encoding chain end-to-end. |
| 5 | FastAPI hot-reload + Vite dev-server + SSH tunnel Oracle e un DX acceptabil pentru side-work de 2-4h/săpt | Săpt 1: măsor timpul de la "save file" la "văd rezultatul" — dacă e > 10s, fix ecosistem înainte de content. **Documentat** în `docs/service-auto/week1-notes.md` cu numere concrete. |

Dacă oricare din 1-4 eșuează cu un răspuns clar, **prototype-ul s-a încheiat cu succes** —
learning obținut, decision point clar, zero cod irosit care trebuie să supraviețuiască.

## Scope wall — what is explicitly NOT in this prototype

Toate aceste subiecte aparțin doc-ului scrapped sau sunt defer-uri la TODO-phase2. Niciunul nu intră aici:

- ❌ Cei 4 clienți existenți, vreodată. Ei rămân pe VFP + XE local. Zero atingere.
- ❌ Migrare scheme, SSH tunnel VFP→Oracle central, decomisionare XE local
- ❌ eFactura / ANAF / SPV upload — irelevant fără producție
- ❌ Feature flags per-tenant, `FEATURE_FLAGS` table
- ❌ `SP_BON_CONSUM` (cross-schema synonyms), `SP_VALIDEAZA_COMANDA`, `SP_EMITE_FACTURA` — toate deferred
- ❌ **Insert în ACT la creare comandă** — ACT e registrul jurnal, se hit-uiește la facturare, care e NOT IN SCOPE
- ❌ `reconcile.py`, invariant checking, parallel testing cu VFP
- ❌ Runbook rollback, monthly restore drill, uptime monitoring, Telegram alerts
- ❌ 5 ecrane MVP (doar 1 — absolute wall)
- ❌ Mobile, responsive, iPad, tablet — desktop-only, viewport-whatever-is-convenient
- ❌ Playwright e2e, smoke parity pentru SPs
- ❌ Endpoint `/clienti` sau `/masini` pentru populare dropdown — hardcoded în Vue
- ❌ Onboarding client nou, referral pipeline, assignment cu telefoane
- ❌ Phase 2, Phase 3, Phase 4 — menționate doar în decision-log.md la finalul prototype-ului
- ❌ SLA, RPO, RTO, warm standby, backup discipline
- ❌ `X-Idempotency-Key`, double-submit protection, retry policy
- ❌ A doua schemă de test (ex: copie CLEVER) pentru probă multi-schemă — costă prea mult budget

Dacă în timpul construcției una dintre aceste tentații începe să pară "doar 30 min în
plus", răspunsul e **scriu o notă, nu scriu cod**. Scope wall ține. Note de tipul
"probabil o să am nevoie de X pentru phase 2" merg în `docs/service-auto/TODO-phase2.md`,
nu în codul prototype-ului.

## Review corrections (from /plan-ceo-review session, 2026-04-11)

Această secțiune documentează ce s-a corectat față de prima versiune a planului, pentru a
fi transparent despre gândirea care a dus la planul final.

### Correction 1 — Nu se creează `MarciusLabPool` nou

**Prima versiune** spunea: "modifică `OracleMultiPool` sau adaugă wrapper" și "creează NEW
minimal helper `MarciusLabPool`". **Realitate:** `OracleMultiPool` la
`shared/database/oracle_pool.py` are deja suport multi-server prin `_pools: Dict[server_id, ConnectionPool]`.
MARIUSM_AUTO se adaugă ca **server nou** prin `register_server('mariusm_test', host='10.0.20.121', port=1521, user='ROA_WEB', password='...', service_name='ROA')` — zero pool nou, zero refactor.

### Correction 2 — Pattern sync-in-async-facade e deja proof-ed în prod

**Prima versiune** trata ipoteza #1 ("oracledb async + OUT params") ca unknown. **Realitate:**
`backend/modules/reports/services/treasury_service.py` deja apelează SPs cu OUT params de
tip `oracledb.CURSOR` și `oracledb.NUMBER` în producție, folosind pattern-ul
sync-in-async-facade (`async with oracle_pool.get_connection(...)`, cursor sync, fără
`await` pe execute/callproc). **Consecință:** ipoteza #1 e reîncadrată ca probă a
pattern-ului `oracledb.connect_async()` **true-async** — nou, neprobeat în codebase.
Săpt 1 e **gate** (vezi mai sus): dacă true-async merge → adoptă; dacă nu → fallback la
sync-facade care e deja dovedit.

### Correction 3 — SP nu inserează în ACT

**Prima versiune** spunea "Insert în ACT, validare minimă". **Realitate:** ACT e registrul
jurnal contabil (double-entry bookkeeping, clasa 6/7 — vezi
`.claude/rules/financial-indicators.md`). O comandă de service auto la CREARE aterizează
într-un **tabel dedicat** (ex: `COMENZI`, `COMD_SA`, nume real de verificat în VFP), NU
în ACT. ACT se hit-uiește la **facturare**, care e NOT IN SCOPE. SP-ul corect face INSERT
în tabela dedicată de comenzi.

**Task în săpt 3 (preparare):** înainte de a scrie SP_CREEAZA_COMANDA, deschide VFP-ul
producție (cu grijă, doar read), caută fluxul real de "creează comandă nouă service auto",
identifică tabelele atinse, documentează în `docs/service-auto/tabele-service-auto.md`.

### Correction 4 — `connection.commit()` e explicit în pattern

**Prima versiune** nu menționa commit. **Realitate:** `oracledb` driver are autocommit OFF
default. Fără `connection.commit()` după `cursor.callproc`, SP-ul rulează dar datele NU se
salvează — **silent failure clasică**. Pattern-ul corect e:

```python
async with oracle_pool.get_connection('mariusm_test') as conn:
    with conn.cursor() as cursor:
        out_id = cursor.var(oracledb.NUMBER)
        out_numar = cursor.var(oracledb.STRING, size=50)
        cursor.callproc('SP_CREEAZA_COMANDA', [..., out_id, out_numar])
    conn.commit()  # <-- CRITICAL
```

**Test obligatoriu** în săpt 5-6: după `callproc + commit`, închide conexiunea, deschide
alta, `SELECT ... WHERE id = :id` — confirmă că row-ul persistă. Dacă nu, commit-ul e
problemă.

### Correction 5 — Error code classification e explicită în plan

**Prima versiune** zicea doar "ORA-20001 → toast". **Realitate:** există multe categorii
de erori Oracle, iar trducerea la HTTP trebuie să fie range-based:

| Cod Oracle | HTTP | Ce vede user-ul |
|---|---|---|
| 20001 — 20999 (`RAISE_APPLICATION_ERROR`) | 422 | Mesajul din SP, curat de prefix |
| 12541, 12170, 12154 (connection / listener errors) | 503 | "Serviciul bazei de date e temporar indisponibil" |
| 01017 (invalid credentials) | 500 + critical log | "Eroare de configurare. Contactați administratorul." |
| 00942 (table or view not exist — grants leak) | 500 + critical log | "Eroare internă. Contactați administratorul." |
| Orice alt cod | 500 + full log | "Eroare internă neașteptată" |

Săpt 11-12: scrie service-layer-ul cu `try/except oracledb.DatabaseError` + clasificare
pe range. Test cu diacritice în mesaj.

### Correction 6 — Logging persistent per-modul

**Prima versiune** nu menționa logging. **Realitate:** `backend/main.py:57` folosește
`logging.basicConfig` cu output doar în stdout. Dacă în săpt 5 vrei să recitești
log-urile din săpt 2, nu ai unde. Fix local pentru `service_auto`:

```python
# backend/modules/service_auto/__init__.py
import logging, os
os.makedirs('backend/logs', exist_ok=True)
logger = logging.getLogger('service_auto')
fh = logging.FileHandler('backend/logs/service_auto.log')
fh.setFormatter(logging.Formatter('%(asctime)s %(levelname)s %(name)s: %(message)s'))
logger.addHandler(fh)
logger.setLevel(logging.INFO)
```

Log structurat la fiecare call:
```python
logger.info("service_auto.create_comanda START", extra={'user': user.username, 'tip': data.tip, 'client_id': data.client_id})
logger.info("service_auto.create_comanda OK", extra={'comanda_id': comanda_id, 'duration_ms': elapsed})
logger.warning("service_auto.create_comanda BUSINESS_ERROR", extra={'ora_code': code})
logger.error("service_auto.create_comanda INFRA_ERROR", extra={'ora_code': code}, exc_info=True)
```

La sfârșit de fiecare săptămână, `grep` în log pentru count-uri și duration p99.

### Correction 7 — Timeline dublat: 12 → 24 săptămâni

**Prima versiune** aloca 12 săptămâni × 2-4 h/săpt = 24-48h. **Realitate (outside voice):**
10 tehnologii noi (Vue 3, Pinia, PrimeVue, Axios, FastAPI async, oracledb true-async,
`session_callback`, PL/SQL OUT params, JWT reuse cu auth store, error mapping) ÷ 24h =
~2.4h per tehnologie, **zero slack**. Plus 2-3 săpt pierdute realist pe VFP urgențe din
12. **Buget onest: 24 săptămâni × 2-4 h/săpt = 48-96h total.** Scope-ul rămâne același,
tempo-ul e mai onest.

### Correction 8 — Week-12-style deliverable schimbă: template reutilizabil, nu demo

**Prima versiune** zicea săpt 12 = "cleanup + phase 2 notes". **Realitate:** un demo pe un
branch throwaway nu e un hedge — e o demonstrație. Hedge-ul real e un **template
reutilizabil**. Noul deliverable pentru săpt 24:

- `docs/service-auto/template-modul-oracle.md` — rețetă de 1 pagină pentru "cum adaugi un
  modul nou peste Oracle în roa2web": register_server pattern, SP signature convention,
  grants model, error map range, `session_callback` snippet, JWT reuse via
  AuthenticationMiddleware, logging setup, file layout.
- `docs/service-auto/decision-log.md` — go / no-go pentru phase 2: ce a funcționat, ce
  nu, sub ce condiții se justifică un al doilea modul, când să nu.
- `docs/service-auto/learnings.md` — notele săptămânale consolidate în lesson patterns.

## What to reuse from the scrapped doc

Nu tot efortul de pe doc-ul vechi e pierdut:

- **Manual ROAAUTO PDF** (`docs/service-auto/manual_ROAAUTO.pdf`) — ground truth pentru
  fluxul real de service auto. Folosit ca input pentru ce câmpuri trebuie să aibă
  `ComandaNoua.vue` și ca referință pentru verificarea tabelelor atinse la creare comandă.
- **Legacy `/workspace/roaauto/frontend/src/views/orders/OrderCreateView.vue`** —
  starting point pentru `ComandaNoua.vue` la ~125 linii, audit de 30 min în săptămâna 1.
- **Convenția de `@cached` + services** din `.claude/rules/backend-patterns.md` — dar NU
  aplicat la endpoint-ul de INSERT (cache-ul e pentru reads).
- **Pattern-ul `treasury_service.py`** ca **golden example** de apel PL/SQL cu OUT params.

## Risks + mitigations

### Risk 1: 2-4 hrs/week + learning curve = prototype drifts into 12+ months
Corecția de buget (24 săpt) ajută. **Mitigare principală:** stop-point discipline
(milestone self-contained per săptămână) + **kill criterion explicit** (vezi mai jos).
Săpt 1 goal e **Hello World Oracle connection** — nu SP, nu schema, nu UI.

### Risk 2: oracledb async + PL/SQL OUT params sunt poorly documented
Săpt 1 POC e exact asta, pe o procedură trivială. **Fallback pre-aprobat:** dacă
true-async nu merge, prototype-ul continuă cu sync-facade (pattern deja în prod). Zero
timp pierdut.

### Risk 3: ~~CURRENT_SCHEMA switching conflictează cu OracleMultiPool~~
**Corectat:** nu conflictează. `OracleMultiPool` izolează per `server_id`.
`session_callback` se aplică la `create_pool` call, nu la nivel de instance. Poți adăuga
un argument `session_callback=` la pool creation pentru `mariusm_test` fără să atingi
pool-urile altor servere.

### Risk 4: Marius abandonează side project-ul după săpt 3 pentru că VFP-ul real cere atenție
Realitate acceptată (outside voice): 2-3 săpt pierdute în 12 e probabil. **Mitigare:**
timeline dublat la 24, fiecare săptămână e stoppable milestone, plus **kill criterion**.

### Risk 5 (NEW): Integration issues concentrate la final
Outside voice observă: fiecare layer e mock-uit până la săpt 11, apoi totul se integrează.
Dacă Vue↔FastAPI↔oracledb are un CORS/proxy/JWT header issue, apare fără buffer.
**Mitigare:** două **integration checkpoints** intermediare:
- Săpt 6 checkpoint: un `curl` hit pe endpoint-ul fără UI, cu JWT real, care cheamă SP-ul și returnează JSON. Confirmă FastAPI↔oracledb chain.
- Săpt 9 checkpoint: `ComandaNoua.vue` hit endpoint-ul cu JWT real, confirmă doar un drum happy path fără error handling. Confirmă Vue↔FastAPI chain.

### Risk 6 (NEW): Grants inventory pe MARIUSM_AUTO nedocumentat
Outside voice observă: testul negativ săpt 3 presupune clean slate. **Mitigare:** săpt 3,
înainte de testul negativ, rulează un `SELECT * FROM DBA_TAB_PRIVS WHERE grantee = 'ROA_WEB'`
+ `SELECT * FROM DBA_SYS_PRIVS WHERE grantee = 'ROA_WEB'` și documentează starting state
în `docs/service-auto/week3-grants-audit.md`.

## Kill criterion (NEW — from outside voice)

**Prototype-ul se oprește definitiv** (nu "pauză de o săptămână", ci "end of project,
scrie decision-log și gata") dacă ORICARE din:

1. **Săpt 4 checkpoint:** `session_callback` nu funcționează după 2 săpt de încercări
   (adică nu ai ajuns la o conexiune care schimbă CURRENT_SCHEMA curat, fără race). Decizia:
   scrie `decision-log.md` cu "session_callback nefezabil în acest oracledb/Python combo,
   multi-tenant necesită alt approach", apoi stop.
2. **Săpt 8 checkpoint:** nu ai un SP `SP_CREEAZA_COMANDA` funcțional testat din SQL
   Developer + Python + grants OK. Decizia: `decision-log.md` cu "pattern SP-first prea
   greu pentru side-project budget", apoi stop.
3. **Săpt 14 checkpoint:** nu ai un curl care apelează endpoint-ul + JWT real + SP + returnează JSON.
4. **Oricând:** 3 săpt consecutive în care nu ai atins nici măcar 1 oră de work pe
   prototype. Side project-ul e mort, acceptă realitatea, `decision-log.md` cu
   "abandoned — VFP demands exceeded budget".

Stop NU înseamnă eșec. Stop înseamnă "am învățat ce trebuia, continuarea nu mai produce
valoare marginală". Fiecare stop produce un `decision-log.md` citibil în 6 luni.

## Timeline (ajustat pentru 2-4 hrs/week × 24 săptămâni)

**Fiecare săptămână e self-contained + oprire curată.** Ordering-ul original e păstrat,
doar spațiat pe 24 săpt în loc de 12, cu checkpoints de integration intermediare.

| Săpt | Target | Cum știu că e gata |
|---|---|---|
| 1 | Oracle central rulează + `poc/hello_oracle.py` (sync) + `poc/hello_oracle_async.py` (`connect_async`) conectează cu `SELECT 1 FROM DUAL`. **Gate**: decide sync-facade vs true-async. DX check (save → result < 10s?). File handler logging setup. | Log arată rezultat, `docs/service-auto/week1-notes.md` scris |
| 2 | `poc/async_out_param_probe.py` — test SP trivial (`CREATE PROCEDURE test_out(p OUT NUMBER) AS BEGIN p := 42; END;`) + Python apel cu `cursor.var(int)` | Script scris, primește `42` |
| 3 | **Preparare:** audit grants curenți pe MARIUSM_AUTO (`DBA_TAB_PRIVS`, `DBA_SYS_PRIVS`). **Verifică tabelele** atinse de crearea comenzii în VFP, scrie `tabele-service-auto.md`. Creează user `ROA_WEB` + grants. | `week3-grants-audit.md` + `tabele-service-auto.md` scrise |
| 4 | Test negativ ipoteza #3 (INSERT direct → ORA-00942; SELECT direct → ORA-00942; CALL SP → success). Pytest integration marker. | Test automat rulează local, toate cele 3 asserts trec |
| 5 | `session_callback` pentru CURRENT_SCHEMA switching, test concurent pe 2 conexiuni paralele pe aceeași schemă | Log-uri clare, niciun cursor tag leak |
| 6 | **Checkpoint integration 1**: endpoint FastAPI minimal (fără logic, hardcoded return) + JWT reuse din middleware + curl hit cu JWT real. Doar ca să confirm că chain-ul FastAPI + auth merge. | `curl` cu JWT real returnează 200 |
| 7-8 | **Verify tabele** în VFP (din săpt 3), scrie `SP_CREEAZA_COMANDA` în SQL Developer, test manual cu `EXEC` | Row apare în tabela dedicată cu ID returnat prin OUT |
| 9-10 | Service-layer Python (`comenzi_service.create_comanda`) care apelează SP-ul prin pattern-ul ales în săpt 1 + `connection.commit()` + test persist după reconnect | Test automat: callproc + commit + new connection + SELECT → row există |
| 11 | Endpoint FastAPI `/api/service-auto/comenzi` care primește Pydantic, apelează service, returnează JSON | `curl` hit cu JWT real + body JSON → row inserted |
| 12 | **Checkpoint integration 2**: `ComandaNoua.vue` minimal (hardcoded dropdowns) + Pinia store + axios call → endpoint. Doar happy path, zero error handling. | Submit în browser → row inserted → console log "OK" |
| 13-16 | Error handling end-to-end: ORA-20001 (diacritice!) → HTTP 422 → PrimeVue Toast în română. ORA-12541 → HTTP 503 → Toast generic. Spinner pe buton cât SP rulează. Reset form la success. | Aruncă intenționat erori în SP, verifică fiecare drum |
| 17-20 | Buffer pentru VFP urgențe + lessons refactor (dacă săpt 1-16 au produs cod care trebuie curățat). Dacă nu e nevoie de buffer, rula ipoteza #2 mai adânc (2 conexiuni, concurență mai agresivă). | N/A — buffer |
| 21-22 | Scrie `template-modul-oracle.md` — reteta reutilizabilă | Doc scris, citibil de către un alt dev |
| 23 | Scrie `decision-log.md` — go/no-go phase 2, learnings consolidate | Doc scris, decizie clară |
| 24 | Cleanup: ștergerea `poc/` dacă e cazul, final commit pe branch, `learnings.md` consolidat | Branch clean, commit final |

**Timeline-ul e intenționat conservativ.** La 2-4 hrs/week, 24 săpt = 48-96 ore totale.
Dacă merge mai repede, perfect — atingi mai devreme la sfârșit. Dacă merge mai încet,
fiecare săptămână e încă un milestone self-contained.

## What would make this prototype fail (and it would still be useful)

- Ipoteza #1 eșuează pentru **true-async**: fallback la sync-facade, prototype continue.
  Zero învățare pierdută — sync-facade e deja în producție, știi că merge.
- Ipoteza #1 eșuează pentru **ambele** (sync + true-async): dacă nici sync-facade-ul din
  `treasury_service.py` nu merge la MARIUSM_AUTO, e ceva radical prost cu oracledb
  instalat la tine. **Stop și investighează**.
- Ipoteza #2 eșuează: `session_callback` fragil în practică → Marius știe că pool-per-tenant
  e necesar, nu pool-single-with-tag. Design major changed, decision-log documentează.
- Ipoteza #3 eșuează: GRANTS model nu ține (SP cheamă alte SPs cu privilegii neașteptate)
  → Marius știe că "Regula de aur via GRANTS" e naivă și trebuie altceva (VPD?
  row-level security?). Design major changed.
- Ipoteza #4 eșuează: error propagation urâtă (encoding, truncation) → Marius știe că
  trebuie protocol de eroare dedicat, nu `RAISE_APPLICATION_ERROR`.
- Ipoteza #5 eșuează: DX pentru 2-4 hrs/week e unusable → Marius știe că side project pe
  acest stack nu e viabil și trebuie alt approach.

Orice din aceste failures e **valoare mai mare** decât "prototype care merge happy path
fără să fi întâmpinat nicio problemă reală". Succesul real = învățare, nu cod.

## Next actions (săpt 1, 2026-04-14 → 2026-04-18)

Cel mai concret lucru, o singură zi, 2-4 ore:

1. **Verifică SSH tunnel setup** de la containerul de dev (sau workstation-ul de acasă)
   la `10.0.20.121/ROA`. Există `ssh-tunnel-manager.py` în `backend/shared/` — vezi dacă
   se refolosește.
2. **`poc/hello_oracle.py`** (sync, la `MARIUSM_AUTO` user sau alt user Oracle existent) —
   `oracledb.connect(...)` + `SELECT 1 FROM DUAL`.
3. **`poc/hello_oracle_async.py`** (true-async) — `oracledb.connect_async(...)` + același
   `SELECT 1 FROM DUAL` cu `await cursor.execute(...)`.
4. **Setup logging file handler** pentru modulul `service_auto` (nu exista încă, dar
   directory-ul `backend/modules/service_auto/` se poate crea în săpt 1 just to house
   the logging setup).
5. **Raport săpt 1** — `docs/service-auto/week1-notes.md`, max 15 linii: ce a mers, ce a
   fost greu, DX latency măsurat (save → result în secunde), gate decision (sync vs
   true-async), buget rămas din săpt 1.

Zero SP-uri, zero Vue, zero auth, zero scheme noi. Doar "Python vorbește cu Oracle local"
în ambele pattern-uri.

## Non-negotiables

1. **Cei 4 clienți nu sunt atinși niciodată în acest prototype.** MARIUSM_AUTO e
   dedicat, zero copy, zero conexiune la producție.
2. **Scope wall la 1 ecran + 1 SP.** Tentațiile de scope creep merg la
   `docs/service-auto/TODO-phase2.md`, nu în cod.
3. **Stop points weekly.** Fiecare săptămână e oprire curată. Nu se acceptă "oh, nu pot
   să mă opresc aici pentru că e jumătate făcut".
4. **Succesul se măsoară în învățare + template reutilizabil**, nu în ecrane livrate. Un
   prototype care descoperă o problemă e mai valoros decât unul care evită toate
   problemele.
5. **Kill criterion trigger-ed → scrie decision-log → stop.** Nu "mai dau 2 săpt să văd".

## Final deliverable (săpt 24)

Nu e un ecran. Nu e un demo. E:

1. `docs/service-auto/template-modul-oracle.md` — rețetă de 1 pagină citibilă de către un alt dev în 10 minute:
   - Cum înregistrezi un server nou în `OracleMultiPool`
   - Signature convention pentru SPs cu OUT params
   - Grants model (user tehnic + `EXECUTE ON SP` + `ALTER SESSION SET CURRENT_SCHEMA`)
   - Error code range classification (20xxx → 422, 12xxx → 503, else → 500)
   - `session_callback` snippet pentru CURRENT_SCHEMA switching
   - JWT reuse prin `AuthenticationMiddleware`
   - Logging file handler per-modul
   - File layout (`routers/`, `services/`, `models/`)
2. `docs/service-auto/decision-log.md` — go / no-go pentru phase 2:
   - Ce ipoteze s-au confirmat, care nu
   - Evidența concretă (log-uri, teste, numere DX)
   - Condițiile sub care un al doilea modul e justificat
   - Condițiile sub care NU e justificat (kill criterion retroactiv)
3. `docs/service-auto/learnings.md` — notele săptămânale consolidate, pattern-uri noi,
   surprize, workarounds descoperite, Oracle edge cases.
4. Cod: tot sub branch `feat/service-auto`, NU merged în main. Branch = arhivă + referință.

**Acest deliverable e valoros chiar dacă prototype-ul n-a ajuns la 100% din ipoteze.**

---

**END OF RETHINK DESIGN v2. ~9 pages. Budget 2-4 hrs/week × 24 weeks = 48-96 hrs total.**

---

## GSTACK REVIEW REPORT

| Review | Trigger | Why | Runs | Status | Findings |
|--------|---------|-----|------|--------|----------|
| CEO Review | `/plan-ceo-review` | Scope & strategy | 1 | CLEAR (PLAN) | HOLD SCOPE mode, 0 critical gaps post-fix, 10 items deferred to TODO-phase2, plan file rewritten v2 with 8 review corrections |
| Codex Review | `/codex review` | Independent 2nd opinion | 0 | — | — |
| Eng Review | `/plan-eng-review` | Architecture & tests (required) | 0 | — | — |
| Design Review | `/plan-design-review` | UI/UX gaps | 0 | — | — |
| DX Review | `/plan-devex-review` | Developer experience gaps | 0 | — | — |

**OUTSIDE VOICE:** Claude subagent (Codex unavailable). 15 findings total. 3 load-bearing surfaced as cross-model tension (SP→ACT modeling error, budget ~2x under-scoped, demo vs template deliverable). All 3 accepted by user and integrated into plan v2.

**UNRESOLVED:** 0

**VERDICT:** CEO CLEARED — plan rewritten as v2 with 8 corrections, 0 critical gaps, 24-week timeline, template deliverable. Eng review recommended before writing any code (optional for learning prototype but helps catch architectural issues in service_auto module structure).