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 v2 — corecțiile userului după ce a citit 01_buy_doji (19.09.2026, seara)

Userul a citit capitolul rescris în format tutorial și l-a respins. Ce a cerut, punct cu punct. Astea bat orice regulă de mai jos care le contrazice.

Structura: trei niveluri, de sus în jos

1. Nivelul 1 — din avion. O pagină. Ce e strategia, o diagramă mare cu tot trade-ul adnotat, fraza de decizie, mini-glosarul termenilor. Cine citește doar atât trebuie să știe deja ce caută pe ecran.
2. Nivelul 2 — procedura mecanică. Pașii, în ordinea în care îi faci. Fiecare pas: o propoziție de acțiune, o diagramă, maximum ~300 de cuvinte, și „Treci mai departe doar dacă…". Aici omul nu alege nimic — dă din mână, mecanic.
3. Nivelul 3 — rafinări. Confirmările care fac un setup A+, perechile de TF, tranșele, exemplul real, transferul pe prop/BVB, contradicțiile. Începe cu o linie: „asta citești după 20 de trade-uri făcute mecanic".

Limbaj

• Explică fiecare termen tehnic la prima folosire, inline, într-o propoziție. „ieșire pe trail", „retest", „1R", „tranșe", „doji" — nimic nu se presupune știut. Dacă termenul are formă pe grafic, desenează-l.
• Propoziții normale, nu telegrafice. Fără stil abrupt de notiță.
• Cifrele se plimbă cu o diagramă. Un pas care e doar text cu numere e un pas prost scris.

Referințe

• Zero trimiteri fișier:linie în corpul textului. Ele îngreunează cititul. Toate se mută la finalul fiecărui nivel, într-un bloc „Surse", grupate pe pas. În text, cel mult un link markdown către un alt capitol din summaries/.

Diagrame — „ca la proști"

• Fiecare diagramă de preț arată săgeți cu text: „aici intri", „aici pui stopul — sub el ideea e moartă", „aici prima țintă".
• Zonă dreptunghiulară de evidențiere peste regiunea despre care e vorba (userului i-a plăcut explicit cea de la pasul 7). Folosește-o.
• Fiecare săgeată spune și de ce, nu doar ce.
• Tranzacția în oglindă (short) are diagrama ei completă, nu o propoziție „e invers". Userul e vizual.

Volum

• Mai puține tabele. Un tabel doar dacă compari 3+ lucruri pe aceleași criterii. Altfel: listă sau paragraf.
• Mai scurt. Userul: „te lungesti foarte mult", „daca imi dai extrem de multe informatii nu stiu care sunt relevante". Ce nu intră în procedura mecanică merge la nivelul 3 sau se taie.
• Exemplele concrete și setup-urile rămân — alea îi plac. Abstracțiile pleacă.

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).