atm-curs-dl/STYLE.md

# Stil pentru sumarizări (summaries/) — cerințe confirmate cu userul

Referință obligatorie înainte de a scrie/genera orice fișier nou în
`summaries/`. Exemplul de referință: `summaries/05_MODUL_4/01_patternuri_complexe_partea_a_doua.md`.

## FORMAT TUTORIAL pentru capitolele de strategie (cerut de user, 19.09.2026)

Userul a citit `17_STRATEGII/A3_intrarea.md` și a spus: conținutul îi place,
dar e **greoi și greu de urmărit**. Cererea, cuvânt cu cuvânt: „trebuie să
aibă o abordare 1-2-3 de sus în jos explicat ca și cum ar fi un tutorial".
Se aplică tuturor capitolelor din `17_STRATEGII/`.

**Ce se schimbă față de formatul Nivel 0/1/2:**

1. **Pașii numerotați sunt coloana vertebrală, nu nivelurile.** Documentul
   curge „Pasul 1 → Pasul 2 → Pasul 3", în ordinea în care le faci tu la
   ecran: ce cauți, cum confirmi, unde intri, unde e stopul, unde ieși.
   Nivelurile 0/1/2 rămân ca adâncime **în interiorul** unui pas („dacă vrei
   nuanța"), nu ca structură a documentului.
2. **Fiecare pas începe cu o propoziție de acțiune**, la persoana a doua:
   „Deschizi graficul weekly și cauți…". Nu „Se identifică…".
3. **Fiecare pas are diagrama lui.** Nu o diagramă la trei pași. Dacă un pas
   n-are ce să arate vizual, probabil nu e un pas separat.
4. **Diagrama stă lângă textul ei**, nu într-o galerie la final.
5. **La finalul fiecărui pas: o linie „Treci mai departe doar dacă…"** —
   condiția care te lasă la pasul următor. Asta e ce face din listă o
   procedură.
6. **Tabelele: maximum 4 coloane, și niciodată un tabel de 2 coloane care ar
   fi putut fi o listă.** Userul a semnalat explicit tabelele de 2 coloane ca
   fiind greu de citit. Un tabel e pentru comparat 3+ lucruri pe aceleași
   criterii; altfel scrie listă sau paragraf.
7. **Blocul de deschidere e scurt:** ce face strategia, pe ce TF, cât de des
   dă semnal, și un link către pasul 1. Lista de surse se mută la **finalul**
   documentului — acum e un zid de linkuri chiar sub titlu, înainte de orice
   conținut.

**Ce NU se schimbă:** citatele exacte cu `[sic]`, trimiterile la
`fișier:linie`, marcarea deducțiilor, contradicțiile lăsate nerezolvate cu
ambele variante scrise.

**Completările proprii** (decizie a userului, 19.09.2026): unde materialul
nu spune, **completezi** prin corelație cu restul cursului, dar într-un bloc
marcat vizibil — începe cu „**Completare proprie:**" și spune pe ce te
sprijini. Userul preferă un document utilizabil cap-coadă cu completări
marcate, în locul unuia cu găuri în mijlocul procedurii. Ce e al lui rămâne
al lui; ce e al tău se vede de la distanță.

## Structură și ton
- Grupat pe module (`summaries/<NN>_<MODUL>/<NN>_<titlu>.md`), în română,
  dar termenii de trading rămân în engleză (relative strength, trend line,
  doji, neckline, short covering etc.) — nu se traduc.
- Fără emoji, oriunde.
- Concis, nu verbos. Fără liste lungi de "concepte cheie" (nu e un rezumat
  de citit cursul, e un material de referință rapidă).
- Focus pe utilitate practică: exemple concrete, psihologia din spatele
  mișcărilor de preț, când/de ce intri într-un trade, la ce folosește
  fiecare indicator/pattern — nu doar cum arată sau cum se numește.

## Aplicabilitate practică obligatorie — nu te opri la mecanism
Găsit ca gaură reală: `06_divergente.md` explica mecanismul (de ce apare
divergența) foarte bine, dar userul tot nu înțelegea de ce îl interesează,
ce trebuie să facă, când să intre, la ce TP/SL — fișierul spunea "ai nevoie
de trigger și de un plan, subiecte separate" și se oprea acolo. Nu e
suficient.

Pentru orice concept care poate deveni parte dintr-un trade (pattern,
indicator, set-up, divergență, catalizator economic) — pe lângă mecanism —
răspunde explicit, cu diagramă și cifre, la:
1. **De ce urmărești asta** — ce decizie te ajută să iei, concret (nu
   "e important să știi", ci "te ajută să X, ca să nu Y").
2. **Ce faci când îl vezi** — pasul practic imediat următor (aștepți
   confirmare? cauți context? verifici altceva?).
3. **Ce înseamnă confirmare/trigger valid, cu DA/NU** — dacă conceptul e
   un set-up (nu un semnal direct de intrare), arată explicit un trigger
   valid și unul invalid/prea devreme, cu cifre.
4. **Un exemplu complet, de la identificare la ieșire din trade** — nu doar
   "am văzut X", ci intrare (preț exact), stop-loss (preț exact, motivat —
   ce nivel invalidează ideea), take-profit (preț exact, motivat — de unde
   vine ținta), cu diagramă care arată tot trade-ul, nu doar set-up-ul
   izolat. Dacă transcrierea nu dă exact aceste cifre, construiește un
   exemplu plauzibil pe scara reală deja stabilită în fișier (ex: continuă
   graficul unui exemplu real deja folosit), marcat explicit ca fiind
   completarea ta.

Nu amâna asta la "altă lecție" dacă tu (Claude) poți completa cu propria
cunoaștere de trading — exact genul de completare pe care userul l-a cerut
de la început ("nu mă interesează doar mecanic, vreau și de ce și cum").

## Direcție: long și short
- Acolo unde patternul/conceptul are ambele variante (ex: Head & Shoulders
  normal = reversal bearish/short, Inverted = reversal bullish/long; orice
  indicator sau strategie simetrică), include diagramă + exemplu pentru
  **amândouă direcțiile**, nu doar varianta discutată explicit în lecție.
  Nu presupune că mecanismul opus e "evident prin simetrie" — arată-l.

## Gotchas practice / sfaturi de mentor
- O secțiune scurtă, doar cele **2-4 cele mai importante** capcane sau
  sfaturi practice legate direct de exemplul/lecția respectivă — nu o listă
  exhaustivă de "best practices" generice. Genul de lucru pe care un mentor
  îl spune o dată, pe scurt, pentru că a văzut pe cineva pierdut bani exact
  așa ("nu intra pe pattern neconfirmat", "volumul mic la breakout = fals
  breakout", "nu muta stop-loss-ul mai aproape după ce ai intrat").
  Marchează-le tot ca și completare a mea, dacă nu vin explicit din curs.

## Termeni noi — definește-i, nu doar folosește-i
- Orice termen tehnic folosit într-o afirmație (ex: "retest-ul neckline-ului",
  "breakout confirmat cu volum", "fals breakout") trebuie definit prima dată
  când apare — pe scurt, nu verbos — **și** ilustrat cu propria lui
  mini-diagramă cu cifre (nivel de preț concret), nu doar explicat în cuvinte.
  Nu presupune că un termen anterior introdus într-un context (ex: "breakout"
  în diagrama principală) acoperă automat un termen nou înrudit (ex: "retest"
  al aceluiași nivel) — dacă e un concept diferit, are nevoie de diagrama lui.
- Regulă practică: dacă o propoziție folosește un cuvânt de jargon fără să-l
  fi explicat deja în acel fișier, oprește-te și adaugă (a) o definiție de-o
  linie, (b) o diagramă mică cu niveluri de preț reale care arată exact ce
  înseamnă.

## Explicațiile suplimentare (dincolo de ce spune transcrierea)
- Trebuie să fie **mecanisme concrete**, nu afirmații reformulate/metaforice.
  Testul: dacă cineva întreabă "de ce?" despre propria propoziție, răspunsul
  nu trebuie să fie o repetare a aceleiași afirmații cu alte cuvinte
  ("vânzătorii domină → preț mai jos" NU e o explicație dacă nu spui de ce
  mecanic mai multă vânzare mută prețul).
  Exemplul bun din fișierul de referință: mecanismul de bid/ask (cine
  trebuie să accepte ce preț ca să se execute o tranzacție ACUM) explicat
  ÎNAINTE de a-l aplica pe fiecare fază a patternului, cu o diagramă proprie.
- Notă explicită la finalul fiecărui fișier ce anume e completare a mea
  (dincolo de transcriere) vs. ce vine strict din curs.
- **Nu titra o secțiune "de ce X înseamnă Y"** ca și cum X=Y ar fi fost deja
  afirmat mai devreme, dacă nu a fost. Dacă mecanismul e prima dată când
  apare ideea, spune asta explicit ("mai jos folosesc ideea X de mai multe
  ori — o explic o singură dată, aici, înainte de a o aplica"), nu sări
  direct la "de ce X" ca și cum ar fi un follow-up la ceva spus anterior.

## Diagrame de candele: generează-le, nu le desena
`svg_candles.py` construiește diagramele de candele din prețuri (OHLC +
niveluri), cu o singură scară px/unitate pe tot desenul. **Folosește-l pentru
orice diagramă cu candele sau cu entry/SL/TP** — nu scrie SVG de mână.

Motivul, găsit ca bug real în `01_MODUL_1/05_patternuri_candele.md`
(semnalat de user, 2026-09-12): o țintă de 2R desenată la 41 px/unitate în
sus și un stop la 75 px/unitate în jos — adică 2R arăta ca 1R. Trei
diagrame de trade aveau aceeași problemă, una de 8 ori. Plus o etichetă de
`open` pusă deasupra celei de `close` la un marubozu bull, deci axa de preț
inversată. Ochiul nu prinde asta; calculul da.

Generatoarele stau în `gen/` (ex. `gen/patternuri_candele.py`) și rescriu
fișierul `.md` întreg. Ca să corectezi un preț, schimbi cifra în generator
și rulezi din nou — nu edita SVG-ul rezultat.

Verificare automată de pus în orice pagină cu trade-uri: pentru fiecare
diagramă cu trei niveluri (SL / intrare / TP), raportul dintre distanțele în
preț trebuie să fie identic cu raportul dintre distanțele în pixeli.

## Cum trebuie să arate un grafic de preț (cerut de user, 2026-09-13)

Userul citește diagramele ca să vadă **trendul** și să facă analogie cu un
grafic real din TradingView. Candelele izolate, cu spații mari între ele, nu
arată ca un grafic și nu-i spun nimic despre trend. Deci:

**Orice diagramă care arată preț sau volum se desenează ca serie continuă:**
- **25-45 de candele**, lipite (`gap=15-18`, `body_w=9-10`), nu 3-6 candele
  izolate. Pattern-ul trebuie să aibă context în stânga și în dreapta lui.
- **Open-ul fiecărei bare = close-ul barei anterioare.** Folosește
  `from_closes(...)` (definești close-urile, deci controlezi exact structura)
  sau `walk(...)`. Fără goluri artificiale între bare.
- **Panou de volum dedesubt** (`vol_h=70`), cu bare colorate pe direcția
  candelei, de fiecare dată când textul vorbește despre volum.
- **Medie mobilă** (`mas=[MA(20, ...)]`) când textul vorbește despre trend
  sau despre SMA — se calculează singură din close-uri.
- **Etichetele se ancorează pe candele** cu `marks=[Mark(i, ...)]`, nu cu
  `tag` per candelă: la 30 de bare, etichetele per candelă se suprapun.
- `title="SIMBOL — timeframe"` sus, ca pe un chart real.

Stilul vechi (3-6 candele, `gap=92`) rămâne valabil **doar** pentru
definiții de pattern-uri de o candelă (ce e un marubozu, ce e un doji),
unde contează forma barei, nu trendul.

**Verificare obligatorie în generator:** după ce construiești seria, extrage
din ea nivelurile pe care le afirmi în text (`min(c.l for c in cds[a:b])`) și
pune `assert` că se potrivesc — ex. că al doilea picior chiar e mai jos decât
primul, că intrarea e egală cu close-ul ultimei bare, că R-ul din etichetă e
cel calculat. Ochiul nu prinde o structură care contrazice eticheta; calculul
da. (Găsit ca bug real de agenții de verificare, 13.09.2026: o intrare short
descrisă „sub low-ul barei de retest", desenată deasupra lui.)

## Diagrame (obligatorii, nu opționale — userul e vizual learner)
- **Orice paragraf "Exemplu real" cu cifre concrete are nevoie de propria
  diagramă chiar acolo, lipită de text** — nu doar undeva mai jos în fișier,
  sub alt heading, chiar dacă diagrama aia conține exact aceleași cifre.
  Găsit ca bug real: `06_divergente.md` cita cifre reale (Tesla, -435.330 /
  +4.620.702) într-un paragraf "Exemplu real", dar diagrama cu acele cifre
  era plasată câteva secțiuni mai jos, sub un heading separat ("Histograma")
  — cititorul nu avea ce să se uite exact unde citea cifrele. Regulă: mută
  diagrama lângă text, nu invers (nu muta textul lângă diagramă dacă rupe
  fluxul logic al secțiunii).
- Fiecare secțiune de explicație și fiecare exemplu concret are nevoie de
  o diagramă vizuală, nu doar text.
- **Corelare 1-la-1, nu o diagramă la început + mult text după.** Dacă
  textul descrie cum se schimbă ceva prin mai multe etape/momente (ex: "la
  umărul stâng bara roșie e mare, la head e maximă, la umărul drept e mică"),
  fiecare etapă are nevoie de **propria ei mini-diagramă**, lipită direct de
  paragraful ei — nu o singură diagramă generică la început, urmată de
  paragrafe lungi care doar descriu verbal schimbări pe care cititorul nu
  le mai vede. Regula practică: dacă un paragraf zice "acum bara X e mai
  mare/mică decât înainte", trebuie să existe o imagine chiar acolo care
  arată exact asta, nu doar la începutul secțiunii.
- **Text: numește entitatea, nu culoarea.** Nu scrie "bara roșie"/"bara
  verde" în text — scrie "vânzătorii"/"cumpărătorii" (entitatea reală).
  Culoarea e un ajutor vizual în diagramă, nu vocabularul din proză; cere
  cititorului să țină minte o mapare culoare→sens de fiecare dată, care e
  frecare inutilă.
- **Diagrame cu orientare diferită de graficul de preț au nevoie de
  locator.** Graficul principal de preț e vertical (prețul pe axa Y). O
  diagramă order-flow (bare orizontale cumpărători/vânzători) e alt tip de
  grafic, altă orientare — fără nimic care să le lege, cititorul nu poate
  ști la ce punct de pe graficul de preț se referă bara. Soluție: lângă
  fiecare mini-diagramă de tip bară, pune un mini-locator (o siluetă mică a
  formei principale, cu un punct evidențiat unde ne aflăm), nu doar un titlu
  text ("Umărul stâng").
- Diagramele de preț (pattern-uri, niveluri, entry/stop/target) trebuie să
  aibă **niveluri de preț reale** pe ele (numere, nu doar etichete generice
  ca "neckline"/"head" fără cifre) și să fie **desenate la scară corectă**:
  dacă textul zice "aceeași distanță", distanța pe desen trebuie să fie
  vizual egală, nu aproximată. Verifică geometric (calculează y-coordonatele
  din prețuri reale) înainte de a considera o diagramă gata.
- **Include contextul de trend anterior**, nu doar pattern-ul izolat. Dacă
  textul zice "prețul trece dintr-un trend descendent într-unul ascendent",
  diagrama trebuie să arate acel trend descendent înainte de pattern — nu
  să înceapă direct cu umărul stâng, ca și cum ar apărea din senin. Prepend
  un segment clar de trend (2-3 puncte, pantă vizibilă) înainte de primul
  punct al pattern-ului, etichetat ("trend descendent anterior" / "trend
  ascendent anterior").
- Nu duplica aproape-identic o diagramă structurală și una cu exemplu numeric
  — dacă exemplul concret poate fi desenat direct pe diagrama principală
  (cu prețuri reale în loc de etichete generice), unește-le într-una singură.
- SVG inline în markdown, **fără linii goale în interiorul blocului
  `<svg>...</svg>`** — python-markdown rupe blocul HTML în paragrafe la
  fiecare linie goală, iar browserul aruncă restul elementelor. Un rând gol
  ⇒ diagramă stricată.
- Dacă mai multe elemente text/bare riscă să se suprapună la coordonate
  fixe (ex. bare de volum alăturate), preferă un tabel HTML normal sub SVG
  pentru text/legendă (se aliniază singur) față de text poziționat absolut
  în SVG lângă elemente înghesuite.
- Verifică vizual, nu doar cita codul SVG: pornește un `python3 -m
  http.server` local pe `summaries/`, navighează cu Playwright, și dă
  screenshot pe fiecare `<svg>` (`page.locator('svg').nth(i).screenshot()`)
  înainte de a considera o diagramă gata. Erorile de layout (text tăiat de
  viewBox, elemente suprapuse) nu se văd doar citind codul.
- **Nu sări verificarea vizuală pentru că diagrama "pare simplă".** Găsit ca
  bug real: un agent a considerat un SVG cu linii/cercuri/text "suficient de
  simplu" și a sărit peste Playwright — două etichete se suprapuneau exact
  acolo, ilizibil. Complexitatea codului SVG nu prezice dacă textul se
  suprapune la randare; verifică mereu, fără excepție.

## Confirmare vs. capcană — arată DA și NU, nu doar DA
- Pentru orice concept unde există o versiune validă și una înșelătoare care
  arată aproape identic la prima vedere (breakout real vs. fals breakout,
  retest valid vs. eșec, divergență reală vs. zgomot) — arată **ambele**,
  explicit etichetate "DA" / "NU", fiecare cu cifre proprii și diagramă
  proprie, una lângă alta sau imediat succesive. Nu descrie doar cazul bun.
- Nu duplica aceeași diagramă în două locuri ale fișierului dacă un concept
  revine mai târziu (ex: gotchas) — referă înapoi la perechea DA/NU deja
  arătată, cu cifrele relevante repetate în text, fără să redesenezi SVG-ul.

## Exemple practice — minim 2-3, nu unul singur
- Un singur exemplu numeric (ex: doar EURUSD long) nu e suficient. Fiecare
  concept cu aplicație practică are nevoie de **2-3 exemple concrete cu
  cifre**, fiecare cu propria diagramă. Variază: alt instrument/pereche,
  altă direcție (dacă nu e deja acoperită de secțiunea long/short), sau un
  caz de eșec/invalidare (arată și cum arată numeric când NU funcționează,
  nu doar cazul de manual perfect).
- "Cu capturi de screenshot sau construite" — pipeline-ul păstrează doar
  audio→text, deci din curs **nu avem capturi**; toate exemplele de acolo
  sunt **diagrame construite** (SVG, la scară, cu cifre reale). Nu inventa
  și nu promite screenshot-uri care nu există.

  **Excepție, de la 18.09.2026:** userul poate primi direct de la autor
  capturi din platforma lui (WhatsApp etc.). Alea se pun în
  `docs/strategie/`, se recoltează într-un `harvest/<data>-autor.md` scris
  de sesiunea principală (un agent nu vede pozele), și de acolo intră în
  documente. Reguli pentru ele:
  - **Nivelurile citite din captură sunt reale, deci diagrama poate purta
    ticker real** — vezi regula de ticker de mai sus. Legenda spune la
    fiecare diagramă ce e al lui (nivelurile, citirea) și ce e construit de
    tine (structura barelor dintre niveluri, când captura nu e lizibilă
    bară cu bară).
  - **Ce nu se poate citi din captură nu se scrie ca regulă.** Dacă autorul
    afirmă ceva ce imaginea nu arată (ce indicator calculează o bandă, unde
    a intrat exact), se trece la „rămâne neconfirmat", cu motivul. Vezi
    `05_volum`, secțiunea 10, ca model.
  - **Verifică aritmetica în generator**, cu assert, ca la orice diagramă:
    dacă scrii „194 de puncte = 6R", cifrele alea ies din serie, nu din cap.

## Referințe
- Secțiune finală cu 2-4 link-uri externe către cele mai bune explicații
  găsite (WebSearch — link-uri reale, verificate, niciodată ghicite).
  Preferă surse educaționale de brokeri/platforme cunoscute (IG, OANDA,
  Investopedia etc.) în locul unor bloguri necunoscute. Acoperă ambele
  direcții (long/short) dacă e cazul, ca și diagramele.

## Pagina (rendering)
- `render_html.py` convertește fiecare `.md` în `.html` mobil-friendly
  (viewport meta, font 18px, lățime max 720px) — rulează-l după orice
  modificare de conținut, altfel pagina servită e veche.
- Servit prin `tailscale serve` pe `/atm` (dosarul `summaries/` întreg,
  inclusiv `index.html` cu linkuri către toate paginile).