# 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`. ## ȘABLONUL: `17_STRATEGII/01_buy_doji.md` (aprobat de user, 20.09.2026) **Capitolul ăla e contractul. Citește-l înainte să scrii altul** — regulile de mai jos sunt extrase din el, dar textul lui e arbitrul când ceva nu e acoperit aici. Ce urmează bate orice regulă de mai jos care o contrazice. ### Ce s-a adăugat pe 20.09.2026, după a doua citire a userului **1. Diagramele cu două timeframe-uri trebuie să aibă corespondență de prețuri.** Cererea lui, cuvânt cu cuvânt: „să îmi dau seama care bucată din graficul weekly este reprezentată de graficul daily — adică care candelă weekly e reprezentată de candelele din graficul daily, cu aceleași linii de preț". Concret, cum e rezolvat în `buy_doji_perechi_tf` și `buy_doji_directie`: - Graficul TF-ului mic e **descompunerea reală** a candelelor mari, nu o serie care vine după ele: o candelă mare = `k` candele mici, cu open, close, `max(high)` și `min(low)` care coincid — verificat bară cu bară prin assert. `k` = 5 zile pe săptămână, 4 săptămâni pe lună, 7 bare de 60 de minute pe zi (ședința e de 6,5 ore, ultima bară e de jumătate de oră — spune asta pe desen). - Sursa de adevăr e **seria fină**; candelele mari se calculează din ea prin agregare. Invers, corespondența rămâne în urmă la prima modificare. - Pe desen: **casetă punctată** peste exact candelele mărite, **ghidaje** de la colțurile ei la colțurile cadrului mic, și nivelul-cheie desenat pe **ambele panouri, cu același număr de ambele părți**. - Nivelul comun **nu se poate alinia** la aceeași înălțime — ghidajele fixează deja două prețuri, iar scările au pante diferite. E o lupă, nu o eroare. Leagă-l cu un **conector** subțire între cele două capete, cu numărul scris o singură dată, în cot. - Dacă o etichetă numește un nivel de referință, **nivelul trebuie să se vadă undeva**. Dacă nu încape pe panoul mic fără să strici scara, marcheaz-l pe panoul mare și trimite acolo din etichetă („bifa din stânga"). Nivelul trăiește pe TF-ul mare, declanșatorul pe cel mic. **2. Fiecare termen tehnic, explicat ȘI exemplificat.** Userul a reclamat „ai folosit «bull reversal» fără să îl explici sau să îl exemplifici". Definiție în mini-glosar + explicație inline la prima folosire + un exemplu concret, de preferință unul care se vede pe o diagramă din capitol. **3. Definițiile se ancorează de un nivel, nu se lasă absolute.** „Pullback = nu mai face minim nou" e fals: orice pullback care coboară face minime tot mai joase. Corect: „nu rupe minimul din care a pornit mișcarea". O definiție neancorată e neverificabilă pentru un începător, deci greșită. **4. Blocul „Surse" NU stă în capitol.** Userul l-a respins. Trimiterile merg în `fise/__surse.md`, cu un link de o linie în paragraful „Cum citești capitolul", de sub etichete. În corpul capitolului rămân doar linkuri markdown către alte capitole din `summaries/`. ### Regulile de la v2, care rămân în picioare ### 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. Merg toate în `fise/_surse.md`, grupate pe pas (vezi punctul 4 de mai sus — blocul „Surse" din capitol a fost respins). Î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/_/_.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.) **Assert-uri care chiar prind ceva** (lecții din verificarea lui `01_buy_doji`, 20.09.2026): 1. **Un assert care compară un calcul cu el însuși nu poate pica și dă falsă siguranță.** `zoom = aggregate(fine, k, n)`, apoi `assert zoom == aggregate(fine, k, n)` — inutil. Assert-ul util afirmă o **proprietate pe care textul o pretinde**: peste câte candele mari se întinde pullback-ul, în a câta cade doji-ul. Exact acolo se rupsese textul capitolului. 2. **Nicio etichetă nu poate numi un `\d+\.\d\d` care nu e un nivel desenat.** Cel mai general tipar; jumătate din problemele găsite la verificare erau un preț scris de mână care rămăsese în urmă când s-a schimbat seria. 3. **O etichetă de pe un panou nu poate conține prețul celuilalt panou** — cu o excepție **explicită** pentru nivelurile comune, care trebuie să aibă assert propriu că apar identic pe ambele. O scutire fără assert lasă nivelul să dispară sau să apară cu alt număr. 4. **Numărul din textul unei zone == numărul de bare pe care le acoperă.** 5. **Liniile nu cad pe marginea cadrului.** Dacă stopul e `min(low)`, linia lui se citește ca bordură, iar fitilul pare tăiat. Lasă aer (6 %) și pune assert pe distanța în px. 6. **Aceeași regulă numerică în tot capitolul.** `directie` punea stopul cu marja de 5 cenți, `perechi_tf` fix pe low — două reguli de stop în același capitol, amândouă etichetate corect local. Compară între diagrame, nu doar în interiorul uneia. **Etichetele se leagă de liniile lor.** Când două niveluri sunt la câțiva px, stivuirea etichetelor le rupe de linii și nu se mai vede care e care: desenează leader lines. ## 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 `...`** — 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 `` (`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/-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).