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.

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.

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 (obligatorii, nu opționale — userul e vizual learner)

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

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