Am câteva boards în Miro care demult au devenit load-bearing — reflecții, planuri, hărți mentale adunate de-a lungul anilor. Butonul Export îți dă un PNG sau un PDF. Astea nu sunt date, e o fotografie a datelor.

De ce să le scoți afară

Vendor lock-in nu e o problemă teoretică. E concretă: ca să-ți descarci propriile date prin API, trebuie să faci upgrade la Expert tier. Adică plătești pentru permisiunea de a-ți lua înapoi ceea ce oricum e al tău.

Trăiesc de mult după principiul Obsidian-first: tot ce e important stă într-un vault local, în plain files pe care le pot pune în git, le pot da grep și le pot citi peste zece ani. Un instrument care nu exportă în formatul ăsta e un instrument din care trebuie să pleci înainte ca dependența să devină imposibil de rupt.

De ce Export nu te salvează

Butonul Export din Miro îți dă un PNG sau un PDF. Ăsta e raster — structura s-a dus. Nu poți schimba textul dintr-un box. Nu poți muta un shape. Nu poți da grep pe o etichetă. E anunțul de deces al board-ului, nu board-ul în sine.

Obsidian are două alternative care trăiesc în interiorul vault-ului: plugin-ul Excalidraw și Canvas-ul nativ. Ambele sunt JSON. Ambele sunt editable. Ambele sunt searchable. Ambele stau în vault-ul tău lângă notițe, și poți da grep pe text direct din Obsidian.

Cum le scoți când nu există un buton 'Export to Obsidian'

Când Export-ul din UI nu-ți dă ce ai nevoie, te bagi în API. Miro are un REST API: îți returnează o descriere JSON a fiecărui shape de pe un board. Excalidraw și Obsidian Canvas sunt amândouă JSON open-format. Între ele stă un mapping.

Am scris două scripturi Python. miro_to_excalidraw.py și miro_to_canvas.py. Standard library only — zero deps. Le rulezi cu un token și un board ID, primești un fișier, îl arunci în vault.

Ce a supraviețuit conversiei

Sarcina nu era doar să mut shapes dintr-o parte în alta — era să păstrez vizualul astfel încât board-ul să se citească la fel ca în Miro.

• Poziții și dimensiuni — coordonatele fiecărui shape 1:1
• Culori cu fill opacity (un galben la 40% rămâne la 40%)
• Borders — culoare, grosime, stil (solid / dashed)
• Fonturi și alignment — monospace rămâne monospace, center rămâne center
• Connectors — săgețile se prind în aceleași puncte în care le-a prins Miro
• Curved connectors — arce bow în loc de linii drepte
• Images încorporate în fișier (nu URL-uri externe)
• Mindmap nodes — textul extras prin experimental Mindmap API
• Z-ordering — overlap-ul nu se încurcă

Unde a fost incomod

API-ul Miro are câteva găuri pe care a trebuit să le ocolesc prin reverse engineering.

• Curved connectors — Miro nu expune control points prin API. Așa că în loc de curba originală exactă sintetizez un bow — un arc cu rază fixă între cele două endpoints. Vizual apropiat, mathematically nu identic.
• Z-index — API-ul Miro nu returnează deloc un câmp z. Care shape stă deasupra, care dedesubt? Euristică: suprafață mai mare = mai în spate. Funcționează pentru că în board-urile reale containerele mari stau de obicei sub elementele mai mici.
• Mindmap — textul din mindmap nodes nu e accesibil prin items API-ul obișnuit. Ai nevoie de un call separat către experimental Mindmap endpoint. Filled nodes devin boxes, unfilled devin plain text.

Excalidraw vs Canvas — cum alegi

Dacă gândești în stil drawings — sketchy lines, hand-drawn feel, compoziții freeform — alege Excalidraw. Plugin-ul Excalidraw randează fișierul în aceeași estetică pe care ai văzut-o pe whiteboards.

Dacă board-urile tale sunt mai ales dreptunghiuri cu text legate prin săgeți și trăiești în Obsidian ca second brain — alege Canvas. Canvas e nativ, se deschide dintr-un click și e cusut în backlinks și tags-urile vault-ului.

Unele board-uri le convertesc în Excalidraw (unde contează visual style), altele în Canvas (unde contează viteza și feel-ul nativ). Repo-ul suportă ambele formate — alegi la rulare.

Rezumat

Python 3, standard library only. Fără pip install, fără virtualenv, fără node_modules. python3 miro_to_excalidraw.py 'BOARD_ID' 'output.excalidraw' — și fișierul e în mâinile tale.

Repo: github.com/oleksiimazurenko/miro-to-obsidian. Licență MIT. PR-uri binevenite — mai ales pentru edge case-uri pe care încă nu le-am întâlnit.

Lecția e mai mare decât Miro

SaaS lock-in-ul e un drog. Primele luni sunt gratis. La șase luni, e deja obicei. La un an, datele tale trăiesc într-un format pe care doar UI-ul lor îl poate citi. La doi ani, plătești Expert tier ca să scoți ce oricum era al tău.

Concluzia nu e „nu folosi SaaS”. Concluzia e că orice instrument pe care îl lași să devină load-bearing are nevoie de un exit plan ÎNAINTE să-l deschizi vreodată. Întrebarea „cum ies de aici când o să am nevoie” cântărește la fel de mult ca „cât de plăcut e UI-ul”. Un instrument fără export în plain-text sau fără un API deschis e un instrument cu un preț ascuns pe care îl plătești peste doi ani.

Obsidian-first nu pentru că Obsidian ar fi perfect. Ci pentru că plain markdown files sunt un format care va supraviețui însuși Obsidian-ului. La fel cum un fișier JSON Excalidraw simplu va supraviețui plugin-ului. La fel cum scriptul ăsta Python va supraviețui Miro-ului.

Nu o listă vagă de sfaturi — acelea se evaporă în clipa în care ești obosit. Un canon cu nume, pe care îl poți invoca sub presiune, așa cum SOLID funcționează pentru proiectarea orientată pe obiecte. Îl numesc CRAFT: cinci principii, câte o literă fiecare, așezate sub o singură axiomă. Numele e chiar esența — programarea rămâne un meșteșug, iar AI e doar o unealtă în mâinile cuiva care încă poate face treaba fără ea.

Axioma: linia care se mișcă

Înaintea celor cinci litere vine o regulă care le guvernează pe toate — așa cum „responsabilitatea unică” stă în inima SOLID:

AI face ceea ce ai stăpânit deja. Tu faci ceea ce încă înveți. Linia se deplasează pe măsură ce crești.

Predă partea stăpânită către AI și mergi mai repede — e câștig curat. Predă către AI partea pe care încă ți-o formezi și pur și simplu nu ți-o mai formezi niciodată; plătești în pricepere pentru o viteză de care nici măcar nu aveai nevoie. Fiecare principiu de mai jos e doar o cale de a rămâne sincer cu tine însuți despre unde se află acea linie pentru tine astăzi.

CRAFT — cinci principii, un acronim

Citite de sus în jos, literele sunt un flux de lucru: provoacă-te mai întâi pe tine, analizează cu ostilitate ce îți dă AI, întreabă de ce, nu ce, creează fricțiune în mod deliberat și verifică dacă înțelegi cu adevărat.

C — Challenge First

Principiu. Înainte să deschizi AI, încearcă singur problema timp de 5–15 minute. Prima soluție de pe pagină trebuie să fie a ta — chiar și una stângace. AI intervine ca să te deblocheze, niciodată ca să înceapă în locul tău.

De ce. Zbaterea e cea care construiește modelul mental — neuronii se activează cât timp ești blocat, nu cât timp citești un răspuns gata făcut. Este exact fricțiunea pe care realitatea ți-o impunea gratis; acum trebuie să ți-o programezi singur.

R — Review Adversarially

Principiu. Nu lași AI să-ți facă review la cod — tu faci review la codul AI. Citește fiecare linie generată vânând bug-ul, cazul-limită, gaura de securitate.

De ce. Judecata este cea mai durabilă abilitate din inginerie și singura care devine mai valoroasă pe măsură ce modelele se întăresc. Să faci review la AI o ascute și prinde greșelile pline de siguranță pe care modelele adoră să le facă. Să accepți un diff necitit erodează ambele deodată.

A — Ask Why, Not What

Principiu. Folosește AI ca tutore, nu ca autor-fantomă. Cere raționamentul, alternativele, compromisurile — nu doar fragmentul gata scris.

De ce. „Ce” îți dă un pește; „de ce” îți dă undița. „Dă-mi codul” nu lasă nimic în urmă. „De ce abordarea asta și nu cealaltă, și ce se strică la input gol?” te lasă cu un nivel mai deștept decât erai.

F — Friction on Purpose

Principiu. Realitatea nu te mai obligă să te încordezi, așa că adaugă tu însuți rezistența la loc. Fă regulat sesiuni fără AI — construiește ceva de la zero, fără asistent. Rescrie codul în loc să-l lipești. Închide AI și reprodu ce tocmai te-a învățat.

De ce. Abilitatea se fixează doar prin dificultate dezirabilă. Un copy-paste nu lasă nicio urmă în memorie; rescrierea lentă a acelorași linii lasă. Fricțiunea pare o taxă pe viteză — de fapt e prețul de a-ți păstra abilitatea, pur și simplu.

T — Test Your Understanding

Principiu. Poarta supremă e o singură întrebare: aș putea explica asta, linie cu linie, altei persoane? Dacă nu, nu stăpânești codul și nu-l dai în producție. Prezice output-ul înainte să-l rulezi; strică-l intenționat și repară-l la loc.

De ce. „Merge” nu înseamnă „înțeleg” — prăpastia aceea e iluzia competenței, și exact acolo se ascunde pierderea abilităților. Să-ți testezi propria înțelegere este cea mai ieftină asigurare împotriva zilei în care te trezești incapabil să lucrezi fără unealtă.

CRAFT pe scurt

Autoverificare: crești sau te degradezi?

Nu-ți trebuie un studiu ca să știi în ce direcție mergi. Te degradezi dacă:

• Nu poți scrie o versiune de bază a lucrului fără AI.
• Lipești cod pe care nu l-ai putea explica dacă te-ar întreba cineva.
• Simți anxietate la gândul de a lucra cu asistentul închis.
• Ai încetat să mai citești output-ul AI și pur și simplu îl accepți.
• Nu poți prezice ce face un fragment înainte să-l rulezi.

Crești dacă:

• AI te face mai rapid la lucruri pe care le înțelegi cu adevărat.
• Prinzi în mod obișnuit greșelile modelului.
• Încă poți lucra fără el — mai lent, dar poți.
• Îl folosești ca să înveți un concept nou, apoi reproduci acel concept fără ajutor.
• Decizi conștient ce predai și ce păstrezi.

Dacă reții o singură literă

Reține T. Poarta explicabilității — aș putea explica asta, linie cu linie? — este cel mai simplu obicei din toată metoda și, de una singură, prinde aproximativ 80% din degradare. Tot restul din CRAFT nu face decât să-ți fie mai ușor să treci sincer de acea poartă.

Concluzia

Nimic fundamental nu s-a schimbat în privința învățării. Înțelegerea conștientă a contat dintotdeauna; tocitul a fost mereu un substitut prost. Ce s-a schimbat e că mediul a încetat să mai impună acea diferență în locul tău. CRAFT e pur și simplu o cale de a ți-o impune singur.

Regulile jocului sunt aceleași. Doar că jocul a devenit mai perfid — calea ușoară poartă acum masca succesului.

Dacă n-ai citit diagnosticul din spatele a toate acestea, începe cu postarea anterioară despre AI și bucla de feedback pierdută. Aceea era boala; aceasta e leacul.

Nu e "înveți sau nu înveți". E despre ce anume îi predai AI-ului și ce păstrezi pentru tine. Și despre un lucru pe care AI chiar l-a schimbat — nu în sensul "s-a răsturnat totul", ci ceva mult mai subtil: a dispărut feedbackul forțat pe care realitatea însăși ți-l dădea înainte.

Două extreme — ambele unilaterale

Întâi să curățăm masa de cele două tabere zgomotoase care apar în fiecare discuție:

• Tabăra nr. 1: "Nu mai trebuie să înveți limbaje — AI le scrie". Cei mai gălăgioși sunt cei care vând bootcamp-uri "devii programator în 30 de zile cu AI".
• Tabăra nr. 2: "Toată lumea se va tâmpi, în câțiva ani nu vor mai fi specialiști". Cei mai gălăgioși sunt cei experimentați, puțin speriați de propria neputință în fața vitezei cu care juniorii par productivi.

O falsă dihotomie. În esență, nimic fundamental nu s-a schimbat: ca întotdeauna, se prețuiește înțelegerea conștientă, nu tocitul sec. AI doar adâncește prăpastia dintre cei care chiar se pricep și restul — și o face mai repede decât înainte.

Ce spune baza de dovezi

Nu mai e "mi se pare". Pe parcursul 2025–2026 au apărut măsurători concrete:

• Nature (iunie 2026), "Is AI ruining our skills?" — sprijinul excesiv pe AI degradează competențele. Nu doar la programatori — și la medici.
• Anthropic RCT pe 52 de ingineri: un asistent AI produce o formare a măiestriei cu ~17% mai mică. Nuanța fină — nu suferă viteza de execuție a sarcinii, ci formarea competenței. Adică pe termen scurt ești mai rapid, pe termen lung — mai slab.
• AI & Society: deskilling-ul e o problemă structurală, fără soluție de-a gata. Nu "AI e rău", ci "unealta a schimbat mediul de învățare".
• TechCrunch: inginerii refuză să lucreze fără AI pentru că nu mai pot fără el. Titlul: "asta li se poate întoarce împotrivă".

Concluzia expertului K. Crowston (citat de Nature) — nu e "AI sau nu", ci: decide conștient ce competențe păstrezi pentru tine și pe care le predai. Exact pe această frază se sprijină restul articolului.

Ce predai și ce păstrezi

Concret — aici trece linia:

Nu poți face review la ceva ce nu știi să citești. Așa că "să înțelegi fără să știi limbajul" e o iluzie; e încredere oarbă în AI. Și exact aici e punctul de trecere între "un specialist care folosește AI" și "un operator de AI". Primul conduce AI-ul; pe al doilea îl conduce el.

Încă o distincție pe care lumea o confundă mereu: pierderea competenței ≠ competența neformată. Un om cu experiență care deodată se sprijină pe AI rămâne puternic — are deja un model al lumii. Un începător care din prima zi stă 100% pe AI nu va construi niciodată acel model. Sunt probleme diferite, cu consecințe diferite.

Cum să înveți corect — și de ce, în esență, nimic nu s-a schimbat

Trebuie să înveți în continuare — doar că corect. Nu să toci sec termeni sau comenzi, ci să înțelegi logica și să ai o intuiție a felului în care funcționează în ansamblu. Valoarea nu stă în "a reține", ci în "a înțelege → a ști să aplici → a judeca".

Și cel mai important: e exact același lucru care a fost dintotdeauna, cu mult înainte de AI. Mereu au fost prețuiți cei care chiar se pricep ca specialiști, nu cei care au tocit sec. AI n-a răsturnat nimic — doar face calea leneșă mai ușoară (acum poți "să faci" fără să înțelegi), așa că prăpastia dintre aceste două tipuri doar se adâncește.

Cine a învățat conștient — așa va rămâne. Cine a fost leneș — leneș va rămâne. AI n-a creat această diviziune — doar a scos-o la lumină.

Verifică pe exemple simple

• Matematică: să știi tabla înmulțirii pe de rost nu înseamnă încă "să știi matematică". Calculatorul a omorât înmulțirea în coloană, dar nu și nevoia de a înțelege ce e înmulțirea și când s-o aplici.
• Telefoane: nu mai ții numerele în cap — le ține telefonul minte. Dar trebuie să știi pe cine suni și de ce. Memoria ai predat-o — judecata ai păstrat-o.
• GPS: nu ții rutele în cap. Dar trebuie să înțelegi unde mergi — și să observi când GPS-ul te duce pe un ocol aiurea.

În toate trei, mașina a luat memoria mecanică, nu înțelegerea și judecata — și așa a fost întotdeauna. AI e următoarea iterație a aceluiași lucru, doar cu un spectru mai larg de ce poți delega acum.

Sintaxa e un produs secundar, nu scopul

Asta nu înseamnă "nu trebuie să știi sintaxa". Sintaxa oricum o vei prinde — dar ca produs secundar al înțelegerii și practicii, nu ca scop. Doar n-ai învățat %d cu flashcards — ai înțeles logica format-string-urilor și ți-a rămas de la sine. Așa funcționează învățarea sănătoasă: înțelegi → aplici → sintaxa se așază singură. AI doar accelerează această buclă, dacă o folosești cum trebuie.

Dar un lucru chiar s-a schimbat: a dispărut feedbackul forțat

"Nu s-a schimbat nimic" — e adevărat cam în proporție de 80%. Un lucru important chiar s-a schimbat, și nu e o nimica toată.

Înainte, mediul te forța să înveți. Nu puteai să pui pe picioare cod funcțional fără să-l înțelegi măcar atât cât să meargă. Compilatorul, bug-ul, crash-ul — erau profesori care trăgeau cu forța pe toată lumea până la un nivel de bază. Lupta era obligatorie — și construia înțelegere chiar și la cei nu prea silitori.

Acum profesorul acesta e oprit: poți obține un rezultat funcțional fără să fi înțeles nici măcar o dată cum funcționează. Pedeapsa imediată pentru neînțelegere a dispărut. De aici o consecință pe care teza "nu s-a schimbat nimic" o ratează:

Prăpastia nu se adâncește doar între tipuri fixe — noul mediu îi trage acolo și pe cei care înainte ar fi învățat, fiindcă acum calea leneșă livrează un rezultat funcțional fără pedeapsă imediată.

De aceea și "leneșul rămâne leneș" e prea îngust. E mai mult despre mediu și obiceiuri decât despre fire: majoritatea reacționează la fricțiune și feedback, nu sunt leneși "din fire". Scoate fricțiunea — și chiar și cei care nu sunt leneși alunecă. Riscul nu e doar la leneși.

Și cel mai subtil — iluzia competenței. AI astupă golurile atât de lin încât nu te izbești de zidul propriei neștiințe și nici nu-l observi. Ți se pare că înțelegi, fiindcă "totul merge" (efectul metacognitive laziness). De aceea a rămâne silitor a devenit mai greu: acum îți cere să-ți creezi conștient fricțiune — uneori să oprești AI-ul, să încerci să explici sau să scrii fără el, să verifici "chiar înțeleg, sau doar cred că înțeleg". Înainte, asta o făcea realitatea în locul tău — acum e responsabilitatea ta.

Regulile jocului sunt aceleași, dar jocul a devenit mai perfid — calea ușoară se deghizează acum în succes.

Pentru cei care deja se pricep — jocul e altul

Tot ce e mai sus e despre formarea unei competențe de la zero. Dacă ești deja format — pentru tine tabloul e răsturnat, și merită spus răspicat, altfel articolul se citește ca "AI e rău", ceea ce nu e teza.

Cel cu experiență își cunoaște limitele. Vede ce i-a scos AI-ul → într-o jumătate de secundă înțelege unde e "pe lângă", unde e "da, dar nu pentru cazul ăsta", unde e "da și e ok aici și acum". Are un detector încorporat de "asta nu miroase a bine", asamblat din ani de incidente reale. AI nu oprește acel detector — dimpotrivă, îl hrănește mai repede: mai multe exemple, mai multe cazuri, mai multe patterns de filtrat rapid.

De aceea același AI care riscă să transforme un începător în operator transformă un senior într-un turbo-senior. Boilerplate în 30 de secunde în loc de 3 minute. Explorarea unei biblioteci noi — într-o seară, nu într-o săptămână. Portarea unui modul din Python în TypeScript — chiar fezabilă, nu "cândva, mai târziu". E nitro într-un motor deja asamblat.

Și încă un lucru subtil: AI nu-i poate minți pe cei cu experiență pe nesimțite. Îi minte la fel de des ca pe un începător — doar că el prinde asta înainte să termine de citit fraza. Ce pentru un începător e o capcană a iluziei de competență, pentru un senior e doar încă un bug report în fluxul zilnic.

Pentru cei care au investit deja timp, AI e turbo. Pentru cei care încă n-au investit — e încă un motiv să n-o facă. Între aceste două stări nu există cale de mijloc — și asta face din "când anume ai învățat" unul dintre cei mai importanți factori dintr-o carieră.

Risc sistemic: "scara ruptă"

Seniorii ies din juniori. Dacă AI mănâncă munca de junior și nimeni nu construiește fundamentul → peste 5–10 ani nu va mai fi din cine să crești un senior. Riscul unei "generații pierdute" de specialiști e real — și nu e alarmism, e o simplă problemă de piping: țeava de intrare a sistemului e blocată, cea de ieșire nu.

De ce nu va ajunge la zero (dar va durea): echilibrul "toți s-au oprit din învățat" e instabil. Penuria îi face pe cei care au învățat supraevaluați → stimulentul de a învăța se întoarce. Companiile care cresc conștient specialiști obțin un moat. Dar tranziția e dureroasă: operatorii se prăbușesc la primul incident serios, când AI minte clar și convingător și nu e nimeni în jur care să deosebească adevărul.

Poziția mea

• Limbajul trebuie învățat obligatoriu — cu țintă pe citire și judecată, nu pe tocit. Nu poți scurta drumul spre fluența în citire; AI nu-l scurtează, doar îl face pe nesimțite opțional.
• Cât timp majoritatea "predă înțelegerea" către AI — a învăța acum e o fereastră de oportunitate: devii un specialist rar, care conduce AI-ul, nu care concurează cu el. E o fereastră pe termen scurt — piața se va adapta mai devreme sau mai târziu. Cât timp e deschisă — ar fi păcat să n-o folosești.
• Regimul sănătos: să folosești AI ca să mergi mai repede și să înveți mai adânc, nu ca să eviți învățatul. Antipatternul — "fă-mi tu tot exercițiul". Patternul — scrii tu, AI îți explică "de ce", iar tu îi deslușești varianta înainte s-o accepți.
• Un paradox pentru drum: ca să folosești AI eficient, trebuie să știi destul cât să nu ai nevoie de el la lucrurile simple. Cine depinde de AI la cele simple — la cele grele va fi păcălit de AI fără nicio șansă să observe.

Surse

• Nature — Is AI ruining our skills? Early results are in (iunie 2026): nature.com/articles/d41586-026-01947-1
• InfoQ — Anthropic study, ~17% skill mastery drop: infoq.com/news/2026/02/ai-coding-skill-formation
• TechCrunch — Coders are refusing to work without AI: techcrunch.com/2026/05/29/coders-refusing-ai
• AI & Society — AI deskilling is a structural problem: link.springer.com/article/10.1007/s00146-025-02686-z

Dar după o lună de uz real m-am lovit de câteva probleme serioase pe care articolul acela nu le acoperea. Cea mai mare — o ciudățenie ascunsă a Claude Code peste care am dat din întâmplare, când am adăugat MCP-ul Gmail și acesta a "dispărut" din profilul meu cinci minute mai târziu. Azi am reconstruit tot pe o arhitectură nouă — conformă XDG, cu un symlink și un selector interactiv de profil prin gum. Asta e v2 — o evoluție ieșită din experiență reală, nu o îmbunătățire teoretică.

Ce a început să mă roadă

Patru lucruri. Primele trei țin de ordine, vizibilitate și scalare. Al patrulea e adevărata capcană de arhitectură pe care n-am văzut-o imediat. Le iau pe rând, fiindcă tocmai al patrulea a forțat până la urmă reconstrucția.

1. Două foldere separate în $HOME — e o dezordine

~/.claude și ~/.claude-promova — două dotfoldere așezate unul lângă altul în rădăcina lui $HOME. XDG Base Directory Specification spune că fișierele de configurare stau în ~/.config/. Folderele dotfile împrăștiate direct în home sunt un antipattern care, cu timpul, transformă $HOME într-un sertar de vechituri. Cosmetic, de acord, dar mă enerva de fiecare dată când vedeam ls -la ~.

2. Nicio confirmare vizuală a profilului activ

Pornesc claude și n-am idee care profil e activ — până nu rulez claude config list în interiorul sesiunii. Dacă am uitat care terminal l-am pornit unde, trebuia să verific. Un fleac, dar cu personal + muncă rulând în paralel în două taburi se adună.

3. Aliasurile nu scalează

Două profiluri — claude și claude-promova — e în regulă. Adaugi al treilea (un client de freelance) — îți trebuie un al treilea alias. Al patrulea — un al patrulea. După șase luni n-aș mai ține minte ce aliasuri chiar creasem.

4. Capcana ascunsă din ~/.claude.json

Și ăsta e adevăratul motiv al reconstrucției. Claude Code are două locuri diferite pentru configurare, iar documentația nu strigă asta: ~/.claude/ — directorul care ține projects/, sessions/, hooks/, skills/. Și separat — ~/.claude.json, un fișier chiar în rădăcina lui $HOME, unde stau oauthAccount, mcpServers, istoricul projects, skillUsage și cam alte 40 de câmpuri de stare live reală.

Comanda claude mcp add --scope user scrie exact în acel ~/.claude.json din rădăcina home, nu în ~/.claude/.claude.json sau în directorul profilului. Nu știam asta. Până când, într-o zi, m-am lovit de ea.

Descoperire: de ce a "dispărut" MCP-ul Gmail

Azi-dimineață configuram MCP-ul Gmail în Claude Code. Setup standard: proiect Google Cloud, credențiale OAuth, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Totul în regulă. Am repornit sesiunea — merge, citesc mailuri, răspund la mesaje. O oră mai târziu am început să refactorizăm aliasurile într-o funcție cu un picker de profil pe gum, apoi am mutat totul pe XDG. Am făcut mv ~/.claude → ~/.config/claude-profiles/personal, am repornit CC, am ales personal în meniu. Și în noua sesiune am deschis /mcp:

figma            (failed)
playwright-test
claude.ai Notion

Niciun gmail. Niciun vaultforge. Doar trei servere, dintre care unul chiar eșuase. Și tocmai adăugasem Gmail. Între timp, o sesiune într-alt terminal (profilul de muncă) afișa Gmail și Vaultforge fără nicio problemă.

Am început să sap și am găsit că aveam trei fișiere diferite pe mașină numite .claude.json:

Iată. Asta e capcana de arhitectură:

1. claude mcp add --scope user scrie mereu în ~/.claude.json din rădăcina home, indiferent de CLAUDE_CONFIG_DIR
2. Când CLAUDE_CONFIG_DIR e setat, Claude Code citește $CLAUDE_CONFIG_DIR/.claude.json — fișierul din interiorul profilului
3. Intrările "MCP-uri user-scope" și intrările "MCP-uri de profil" stau în fișiere diferite cu același nume — și sunt ușor de confundat

În cazul meu, ~/.claude.json (rădăcina home, 113 KB) era starea vie, curentă — cu gmail, vaultforge, sesiunea OAuth, tot. Iar ~/.config/claude-profiles/personal/.claude.json (29 KB) s-a dovedit a fi un snapshot vechi care stătea de mai demult în vechiul ~/.claude/ — poate o versiune mai veche de CC a scris acolo, poate un plugin. jq -r 'keys[]' pe ambele fișiere a arătat că versiunea din rădăcina home avea 41 de chei unice care lipseau din snapshot.

Iar cele 41 de chei nu sunt gunoi. E starea reală a Claude Code:

• skillUsage — statistici de utilizare a skill-urilor
• githubRepoPaths — cache de repo-uri pentru navigarea prin proiecte
• cachedGrowthBookFeatures + cachedStatsigGates — feature flags (fără ele CC le aduce proaspete la fiecare pornire)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — flaguri UI (fără ele, modalele reapar la următoarea pornire)
• lastPlanModeUse, feedbackSurveyState, installMethod — stare de onboarding și UX

Dacă faci pur și simplu mv ~/.claude ~/.config/claude-profiles/personal fără merge, pierzi tot. Modalele de welcome revin, căutarea githubRepoPaths rulează din nou, fiecare cerere de sondaj se întoarce. Ceea ce era cât pe ce să fac.

Noua arhitectură

Totul trăiește sub un singur director-părinte în ~/.config/, așa cum vrea XDG. Fiecare profil e autonom — își are starea completă, inclusiv propriul .claude.json. ~/.claude rămâne ca symlink către profilul personal, pentru compatibilitate retroactivă.

~/.config/claude-profiles/
├── personal/
│   ├── .claude.json          ← full live state + MCP list (113 KB)
│   ├── projects/, sessions/, hooks/, skills/, ...
│   └── CLAUDE.md
└── promova/
    ├── .claude.json          ← work state + work MCPs (41 KB)
    └── projects/, sessions/, agents/, skills/, ...

~/.claude  →  symlink to ~/.config/claude-profiles/personal/

Niciun .claude.json în rădăcina lui $HOME. Fiecare profil e un director izolat separat, care ține totul: folderele projects/sessions și același fișier cu serverele MCP și token-urile OAuth. O singură sursă de adevăr per profil.

De ce symlink-ul indică spre personal

Tot ce codează hardcodat calea ~/.claude/ — scripturi vechi, plugin-uri, extensiile IDE ale Claude Code, configurări de statusline precum claude-powerline.json — funcționează în continuare fără modificări. Symlink-ul se rezolvă spre profilul personal. Dacă rulezi din greșeală command claude (ocolind funcția wrapper), tot în personal ajungi, prin căutarea pe calea implicită. Personal devine "default-ul tăcut" cum era înainte, dar acum trăiește fizic în locația XDG.

Selector interactiv la pornire — funcție + gum

În loc de aliasuri — o funcție claude() în ~/.zshrc care afișează un meniu cu săgeți prin gum (helper-ul TUI de la Charm). Funcția interceptează apelul claude la nivel de shell, te lasă să alegi un profil și rulează command claude cu CLAUDE_CONFIG_DIR-ul potrivit. command contează aici — ocolește funcția wrapper și invocă binarul real.

# brew install gum

# Claude Code: profile picker on launch
claude() {
  local profile
  profile=$(gum choose \
    --header "Claude profile:" \
    --cursor "▸ " \
    --selected.foreground 212 \
    --cursor.foreground 212 \
    --header.foreground 244 \
    "personal" "promova") || return
  case "$profile" in
    personal) CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/personal" command claude "$@" ;;
    promova)  CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/promova"  command claude "$@" ;;
  esac
}

Cum arată la pornire:

Claude profile:
▸ personal
  promova

↑↓ pentru navigare, Enter ca să alegi, Esc ca să anulezi (Claude pur și simplu nu pornește). Profilul e mereu vizibil — nu ai cum să-l ratezi.

De la zero (fără v1 de migrat)

Dacă rulezi deja vechiul hack cu două foldere + alias, sari direct la scriptul de migrare de mai jos. Secțiunea asta e construcția curată de la zero — o mașină nouă, sau pur și simplu ~/.claude-ul implicit rezultat din uz normal. Mai întâi decide forma: un cont cu mai multe profiluri (ca să izolezi proiectele și seturile lor de MCP — cazul obișnuit), sau conturi cu adevărat diferite pentru fiecare profil (personal vs. muncă).

1. Așază directoarele

# prerequisites
brew install gum jq

# 1. XDG parent for all profiles
mkdir -p ~/.config/claude-profiles

# 2. fold an existing default install in as your first profile (no-ops on a fresh machine)
if [ -d ~/.claude ] && [ ! -L ~/.claude ]; then
  mv ~/.claude ~/.config/claude-profiles/personal
  [ -f ~/.claude.json ] && mv ~/.claude.json ~/.config/claude-profiles/personal/.claude.json
fi

# 3. one directory = one profile
mkdir -p ~/.config/claude-profiles/personal ~/.config/claude-profiles/work

# 4. these files will hold OAuth tokens — lock them down
chmod 600 ~/.config/claude-profiles/*/.claude.json 2>/dev/null

Un director per profil, sub un singur părinte XDG. Dacă ai folosit deja Claude Code, snippetul îți pliază ~/.claude-ul existent ca personal și cară cu el și starea live din ~/.claude.json din rădăcina home; pe o mașină cu adevărat nouă, liniile astea pur și simplu nu fac nimic. Restul sunt directoare goale care se umplu singure la prima pornire — iar chmod 600 contează, fiindcă fișierele astea ajung să conțină token-uri OAuth.

2. Autentifică fiecare profil

# launch each profile once and authenticate it
CLAUDE_CONFIG_DIR=~/.config/claude-profiles/work claude
#   → run /login in the session, sign in, done.
# Same account for every profile? One /login is enough — macOS keeps it in the
# shared Keychain, so the other profiles are already authenticated.

Pornește fiecare profil o dată cu propriul CLAUDE_CONFIG_DIR și rulează /login. Detaliul-cheie: dacă fiecare profil folosește același cont, te loghezi o singură dată — macOS ține credențialul într-o singură intrare partajată în Keychain, așa că orice alt profil e autentificat automat.

Conturi diferite per profil e calea mai spinoasă: acea intrare partajată din Keychain ține un singur login, așa că logarea unui al doilea cont într-alt profil poate suprascrie primul. Dacă ăsta e cazul tău, urmează ghidul dedicat din rularea a două conturi Claude pe aceeași mașină și verifică izolarea credențialelor pe versiunea ta de Claude Code înainte să te bazezi pe ea.

3. Symlink-ul și picker-ul

# personal becomes the default target of ~/.claude (back-compat)
ln -s ~/.config/claude-profiles/personal ~/.claude

# add the claude() gum picker from the architecture section to ~/.zshrc, then:
source ~/.zshrc
claude        # ← now shows the profile menu on every launch

Îndreaptă ~/.claude spre profilul personal, ca tot ce codează hardcodat calea asta să funcționeze în continuare, apoi aruncă picker-ul claude() cu gum din secțiunea de arhitectură de mai sus în ~/.zshrc. După un reload, claude afișează meniul de profiluri la fiecare pornire — aceeași stare finală ca la setup-ul migrat, doar construită de la zero.

4. Curatoriază MCP-ul fiecărui profil

În final, dă fiecărui profil doar uneltele pe care ar trebui să le vadă: pune disableClaudeAiConnectors: true în settings.json-ul acelui profil și adaugă înapoi ce-i trebuie cu claude mcp add, exact ca în secțiunea despre conectori de mai sus. Asta transformă zece profiluri interschimbabile în zece construite pe scop.

Script de migrare

Pentru oricine citește asta și vrea să treacă de la schema veche. Pasul cel mai critic e al doilea: face merge între ~/.claude.json din rădăcina home și ce e deja în profilul personal, combinând listele mcpServers. Fără pasul ăsta, profilul își pierde și MCP-urile, și toată starea live.

# 1. Move existing dotfolders into a new XDG-style parent.
#    APFS mv is an inode rename — safe even if claude --resume is open in
#    another terminal, file descriptors stay alive on the same inode.
mkdir -p ~/.config/claude-profiles
mv ~/.claude          ~/.config/claude-profiles/personal
mv ~/.claude-promova  ~/.config/claude-profiles/promova   # rename as needed

# 2. CRITICAL: merge ~/.claude.json (the live state — likely 100+ KB) into
#    the personal profile, unioning mcpServers so no MCP is dropped.
jq -s '.[0] * {mcpServers: (.[0].mcpServers + .[1].mcpServers)}' \
  ~/.claude.json \
  ~/.config/claude-profiles/personal/.claude.json \
  > /tmp/personal-merged.json
mv /tmp/personal-merged.json ~/.config/claude-profiles/personal/.claude.json

# 3. Fix permissions — jq+mv inherits umask (likely 644), but this file
#    holds OAuth tokens. Tighten to 600 immediately.
chmod 600 ~/.config/claude-profiles/personal/.claude.json

# 4. Back up the orphaned home-root file (delete once verified)
mv ~/.claude.json ~/.claude.json.migrated.bak

# 5. Symlink for backward compatibility (statusline configs, IDE plugins,
#    anything that hardcodes ~/.claude/ keeps working unchanged)
ln -s ~/.config/claude-profiles/personal ~/.claude

Al treilea pas, despre permisiuni, e important în sine. jq | mv creează un fișier cu umask 644 (citibil de oricine). Are token-uri OAuth în el. chmod 600 imediat după merge e obligatoriu.

După migrare — închide și redeschide toate sesiunile Claude active, reîncarcă shell-ul (source ~/.zshrc sau un terminal nou), rulează claude, alege un profil, verifică prin claude mcp list că toate MCP-urile sunt la locul lor. Dacă totul e bine — șterge ~/.claude.json.migrated.bak. Dacă ceva nu e în regulă — rollback-ul e trivial: mv ~/.claude.json.migrated.bak ~/.claude.json și scoate symlink-ul.

Bonus: conectori MCP per profil (când organizația ți-i partajează)

Arhitectura de mai sus deblochează o a doua axă de izolare — și a ajuns lucrul pe care de fapt îl folosesc cel mai mult. Dacă contul tău Claude aparține unei organizații, aceasta poate distribui un set partajat de conectori MCP remote (Figma, un tracker de tichete, un backend de metrici, un gateway de bază de date, un CMS…). Claude Code aduce automat fiecare conector activat de organizație în fiecare sesiune, fiindcă sunt legați de cont, nu de directorul din care ai pornit.

Cu doi-trei conectori e în regulă. Cu zece proiecte și o duzină de conectori de organizație încetează să mai fie: fiecare sesiune încarcă unelte de care n-ar avea nicio treabă să se atingă. E zgomot în lista de unelte a modelului, e context irosit și — partea care chiar doare — lasă o sesiune să întindă mâna într-un sistem care aparține altui proiect. Conectorul pentru proiectul A n-ar trebui nici măcar să existe cât timp lucrezi la proiectul B.

Dezactivează auto-fetch-ul, apoi curatoriază

Pârghia e o singură setare, disableClaudeAiConnectors (Claude Code v2.1.182+). Trăiește în orice scope de setări — inclusiv în settings.json-ul propriu al unui profil — deci e per-CLAUDE_CONFIG_DIR. Pune-o pe true și profilul acela încetează complet să mai aducă automat conectorii de organizație:

{
  "disableClaudeAiConnectors": true
}

Apoi adaugi înapoi doar conectorii de care profilul chiar are nevoie. Serverele adăugate explicit nu sunt atinse de flag, deci se încarcă normal — rezultatul e un subset curatoriat, profil cu profil:

# add back only what this profile uses — writes to the profile's own .claude.json
claude mcp add --scope user --transport http figma  https://<your-figma-connector>/mcp
claude mcp add --scope user --transport http linear https://<your-linear-connector>/mcp

Același cont, același catalog de organizație — dar fiecare profil vede doar felia lui, plus conectorii comuni pe care alegi să-i repeți (un tracker de tichete de obicei își merită locul peste tot).

L-am testat înainte să mă încred în el

N-am vrut să iau documentația de bună, așa că am rulat un A/B curat pe un singur profil — același cont, același token OAuth, singura diferență fiind acel unic settings.json:

profile WITHOUT the flag
  /mcp → Figma, Linear, Grafana, Postgres, Notion, Sentry, …   (entire org catalog)

same account, profile WITH  disableClaudeAiConnectors: true
  /mcp → (nothing auto-loaded)

…then  claude mcp add  Figma + Linear
  /mcp → Figma, Linear                                         (exactly the curated subset)

Face exact ce promite. Două avertismente pe care merită să le știi înainte să te bazezi pe el:

• Readăugarea unui conector OAuth cere un singur login interactiv. Conectorii care se autentifică prin cheie-în-URL revin complet automat prin claude mcp add. Conectorii din spatele OAuth vor cere o autentificare unică în browser prima dată când îi folosești în acel profil.
• claude mcp list nu afișează deloc conectorii de organizație — doar serverele definite local și adăugate explicit. Cei aduși automat sunt vizibili doar într-o sesiune vie, prin /mcp. Nu te panica atunci când mcp list pare golit de ei.

Ce câștigi

• Un singur director-părinte în loc de două dotfoldere în $HOME — conform XDG
• Symlink-ul păstrează compatibilitatea cu tot ce codează hardcodat ~/.claude/
• Fiecare profil e autonom — starea lui completă și MCP-urile lui trăiesc în propriul .claude.json
• O singură sursă de adevăr per profil — gata cu configurarea orfană din rădăcina home care se depărtează tăcut de cea din profil
• Datele sensibile (oauthAccount, token-uri) au garantat permisiuni 600
• Confirmare vizuală a profilului activ la fiecare pornire — nu ai cum să uiți care profil e activ
• Adăugarea unui al treilea profil = adăugarea unei singure linii în case-ul funcției, nu clonarea unui nou alias și ținerea minte a numelui lui

Unde lasă de dorit

Vreau să fiu sincer. Nu e o îmbunătățire gratis — au venit la pachet câteva compromisuri și merită știute din start.

• gum e o dependență în plus (brew install gum, ~13 MB). Dacă chiar nu vrei să-l instalezi — poți cădea înapoi pe select din zsh sau pe un simplu read. Merge, dar nu arată la fel de bine și n-are navigare cu săgeți.
• O apăsare de Enter la fiecare pornire. Pentru cine dă drumul la claude de zeci de ori pe zi, asta poate deveni enervant. Alternativa mai jos (direnv).
• Symlink-ul ~/.claude → personal face personal-ul default. Dacă îți trebuie profilul de muncă drept default, trebuie să redirecționezi symlink-ul (ln -sf). Nu e greu, dar nu e nici "uită de el și nu se strică nimic".
• Symlink-ul s-ar putea, teoretic, strica dacă vreo unealtă rescrie atomic ~/.claude.json printr-un pattern temp+rename (write-file-atomic). În practică, Claude Code însuși nu face asta, dar dacă instalezi plugin-uri terțe — verifică.
• Dacă ai conturi Anthropic diferite pe profiluri diferite, cu planuri diferite — poate exista un lag sub o secundă după comutare, cât timp Claude Code sincronizează starea OAuth. În uzul meu nu se simte, dar nu e zero.

Alternative pe care le-am luat în calcul

direnv — setează automat CLAUDE_CONFIG_DIR pe baza unui .envrc din rădăcina fiecărui proiect. Zero interacțiune, zero clicuri. Dezavantaj: trebuie să pui un .envrc în fiecare work root, iar dacă rulezi claude într-un folder nerecunoscut, primești profilul default (care s-ar putea să nu fie cel dorit). Pentru cine trăiește într-un set restrâns de work roots și vrea să nu dea niciodată vreun clic, direnv e realmente mai bun.

Comutarea pe bază de symlink (un singur profil activ prin redirecționarea symlink-ului ~/.claude) am luat-o și eu în calcul și am renunțat imediat. Nu poți avea două terminale cu profiluri diferite deschise în același timp — "curentul" global e unic. Pentru mine, ăsta e un deal-breaker.

Concluzie

v2 nu e doar un UX mai bun peste v1. E o recunoaștere a faptului că Claude Code are o ciudățenie de arhitectură ascunsă (~/.claude.json ca fișier separat în rădăcina home, scris de comenzile --scope user indiferent de CLAUDE_CONFIG_DIR) de care trebuie să ții cont dacă vrei izolare reală între profiluri. Prima abordare (~/.claude + ~/.claude-promova + alias) mergea în proporție de 80%, dar restul de 20% se manifesta ca o derivă tăcută a stării între profiluri. Acum e luat în calcul. Dacă abia începi — pornește direct cu v2. Dacă ești deja pe v1 — scriptul de migrare e mai sus, mutarea durează cinci minute și nu strică nimic (tocmai merge-ul cu jq e pasul care te salvează de la pierderea stării).

Două reguli mi-au transformat fluxurile de lucru pline de halucinații în pipeline-uri de încredere: un agent, o specializare și tot ce poate rula ca o comandă de shell trebuie să ruleze ca o comandă de shell. Nu e teorie. Este ceea ce fac în fiecare zi cu Claude Code, iar acestea sunt tiparele care chiar contează.

De ce mint agenții generaliști

LLM-urile sunt predictori ai următorului token. Când un prompt cere două roluri — construiește X și verifică X — modelul termină primul rol, apoi prezice cum ar arăta rezultatul celui de-al doilea, fără să îl execute cu adevărat. Autoverificarea este slabă din punct de vedere structural: același context, același model, aceleași puncte oarbe. Trecut la verificare corelează cu trecut la construire — eșuează împreună.

Modelul nu știe că minte. Din perspectiva lui, a povesti am verificat totul cu atenție este o continuare coerentă a faptului că a scris codul. Din același motiv prompturile de tip ești sigur? nu prind halucinațiile: modelul este la fel de sigur la a doua trecere. Încrederea nu corelează cu corectitudinea — corelează cu cât de plauzibil sună propoziția următoare.

Soluția nu sunt prompturi mai bune. Fii atent, verifică din nou, nu halucina — aceste instrucțiuni nu fac nimic. Soluția este structurală: specializează agentul astfel încât să nu poată pretinde fizic că a făcut ceva și direcționează munca cantitativă prin shell, astfel încât răspunsul să vină din starea reală, nu din probabilitatea tokenilor.

Regula 1: un agent, o specializare

Împarte munca în agenți separați cu contexte separate. Fiecare agent are o singură responsabilitate și un set restrâns de unelte. Întregul flux devine o ștafetă în loc de un singur agent care aleargă în cerc:

• Agentul builder: ia specificația, scrie codul. Asta e toată treaba lui. Are Read, Edit, Write, Bash.
• Agentul reviewer: ia specificația plus diff-ul, verifică criteriile de acceptanță. Context nou. Nu știe cum a fost scris codul, doar ce a ieșit. Are Bash, Read, Grep, Glob — niciun fel de unelte de scriere.
• Agentul de analytics: răspunde la întrebări despre date construind și rulând interogări. Doar Bash. Nu poate ajunge la răspuns fără să ruleze o comandă reală.
• Orchestratorul: sesiunea principală care trimite fiecare agent pe rând și niciodată nu cere unui agent să facă treaba altuia.

Exemplu concret: implementarea unui UI plus o verificare vizuală față de un mockup Figma. Builderul scrie componentele și face commit la diff. Apoi orchestratorul invocă reviewerul cu URL-ul designului, diff-ul și criterii de acceptanță explicite. Reviewerul rulează Playwright, face capturi de ecran, le compară cu referința și returnează PASS sau FAIL cu căile reale ale capturilor și diferențele la nivel de pixel. Builderul nu se apropie niciodată de pasul de verificare — și tocmai de aceea verificarea este reală.

Antitiparul este mega-agentul: un singur prompt care spune construiește acest UI și asigură-te că se potrivește cu mockup-ul. Îți garantez că va raporta că totul se potrivește. Nu se potrivește. Narațiunea am verificat este pur și simplu cea mai probabilă secvență de tokeni după l-am construit.

Regula 2: shell în loc de prompt, întotdeauna

Orice este cantitativ, orice atinge starea reală, orice unde răspunsul poate fi greșit într-un fel care pare corect — trimite-l prin sh. Treaba agentului este să construiască și să ruleze comanda, apoi să îi citească rezultatul. Agentul nu este sursa adevărului. Rezultatul shell-ului este.

• Numărare: wc -l logs.txt este adevărat. Sunt aproximativ 47 de linii de log spus de un model este o halucinație.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Nu estimează volumul.
• Teste: pnpm test --reporter=json | jq '.numFailedTests'. Nu rezumă ce a eșuat.
• Starea Git: git rev-list --count main..HEAD, git diff --stat. Nu numără commit-urile sau descrie modificările.

Odată ce interiorizezi asta, începi să observi fiecare loc unde agentul era pe cale să inventeze un număr. Se pare că sunt vreo 200 de înregistrări... — nu. Rulează SELECT count(*). Majoritatea testelor trec... — nu. Rulează suita de teste, parsează JSON-ul. Modelul este excelent la construirea comenzii. Este nesigur când vine vorba să fie comanda.

Moduri de eșec pe care le-am întâlnit chiar eu

Nu sunt scenarii ipotetice. Fiecare dintre acestea m-a costat timp real înainte să schimb tiparul:

• Verificare fantomă. Agentul a spus am verificat toate cele 14 secțiuni față de mockup. Nu a deschis mockup-ul. Nu a făcut nicio captură de ecran. Verificarea a fost un pas halucinat din narațiune.
• Numere greșite spuse cu încredere. Am cerut monthly active users din datele de analytics. Am primit un număr greșit de aproximativ 3×. Modelul a interpolat din rânduri de eșantion în loc să ruleze interogarea reală.
• Modificări de fișiere inventate. Agentul a spus am actualizat config/feature-flags.json. Nu o făcuse. Doar intenționase. git diff era gol.
• Rulări de teste false. Toate testele trec. Niciun test nu a fost executat. Agentul nu a invocat niciodată test runner-ul — a prezis cum ar fi arătat rezultatul acestuia.

Toate patru se rezolvă cu aceleași două reguli: împarte agentul, împinge în shell. Reviewerul nu are Write, deci nu poate falsifica editarea fișierelor. Agentul de analytics are doar Bash, deci nu poate returna un număr care nu a venit dintr-o interogare. Imposibilitatea structurală bate bunele intenții de fiecare dată.

Cum structurezi asta în Claude Code

Claude Code acceptă sub-agenți definiți în .claude/agents/*.md. Fiecare fișier de agent declară un nume, o descriere, un set de unelte permise și un system prompt. Orchestratorul (sesiunea ta principală) îi trimite folosind unealta Agent. Iată genul de definiție pe care îl folosesc pentru reviewer — scurtă, îngustă și incapabilă fizic să scrie cod:

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

Observă setul de unelte: Bash, Read, Grep, Glob. Niciun Write, niciun Edit, niciun Agent. Reviewerul poate rula comenzi, citi fișiere, căuta tipare — și nimic altceva. Dacă încearcă să dea un diff halucinat drept verificat, forma apelurilor lui de unelte face asta evident: nu au existat verificări reale. Poți audita apelurile de unelte și vezi exact ce a fost inspectat.

Tiparul de orchestrare: sesiunea principală apelează Builderul → așteaptă → rulează ea însăși git diff pentru a captura modificarea reală → apelează Reviewerul cu specificația și diff-ul → citește verdictul. Sesiunea principală nu cere niciodată unui singur agent să facă ambele. Restricțiile de unelte sunt mai puternice decât instrucțiunile din prompt: nu falsifica verificarea este o dorință. Faptul de a nu avea Write este un fapt.

Antitipare de abandonat

Lucruri pe care le văd în prompturi și care nu fac nimic — sau, mai rău, dau un fals sentiment de siguranță:

• Fii atent și verifică-ți munca din nou. Nu generează niciun comportament suplimentar. Modelul produce deja ceva ce arată ca muncă atentă.
• Asigură-te că verifici cu adevărat. Cuvintele cu adevărat nu adaugă o semantică pe care modelul să poată acționa. Va pretinde cu adevărat că a verificat.
• Nu halucina. Un meme din prompt engineering. Halucinația nu este un întrerupător pe care modelul îl poate opri.
• Să te încrezi în agent la numerele mici. La numerele mici minte cu cea mai mare încredere. Nu există un prag minim de onestitate.
• Să adaugi mai multe reguli în prompt pentru a forța onestitatea. Corecțiile structurale (împărțire + shell) bat ajustările de prompt de fiecare dată. Dacă o regulă trebuie impusă, codific-o în accesul la unelte, nu în limba română.

Dacă strategia ta de a prinde halucinațiile este o formulare mai emfatică, nu ai o strategie. Ai o speranță.

Modelul mental

Un agent nu este un coleg. Este o funcție: prompt → tokens. Funcția este excelentă la scrierea codului și groaznică la a introspecta dacă a făcut lucrul corect. Tratează afirmațiile ei despre propria muncă drept o ipoteză. Diff-ul, codul de ieșire, captura de ecran, numărul de rânduri — acestea sunt dovezile. Rezumatul de la finalul turei este suprafața cea mai predispusă la minciună din tot sistemul.

Specializarea este asigurarea ta împotriva derivei narative. Shell-ul este singura ta sursă de adevăr. Builderul scrie. Reviewerul verifică. Bash decide.

Concluzie

Dacă reții un singur lucru: nu lăsa un singur agent să își producă și să își judece propriul rezultat și nu lăsa niciun agent să răspundă la o întrebare cantitativă fără să ruleze o comandă. Tot restul decurge din aceste două reguli. Configurează accesul la unelte agresiv, auditează apelurile de unelte în loc de rezumate, iar suprafața halucinațiilor se micșorează de la peste tot la câteva locuri specifice pe care deja știi să le verifici.

Problema

În mod implicit, Claude Code stochează totul în ~/.claude — tokenul OAuth, istoricul conversațiilor, fișierul global CLAUDE.md, memoria proiectelor, configurările serverelor MCP și setările. Când ai două conturi, ai nevoie de două lumi complet separate:

• Contul personal: abonamentul tău Max/Pro, un CLAUDE.md personal cu preferințele tale, serverele tale MCP (Obsidian, unelte personale)
• Contul corporativ: planul gestionat de companie, un CLAUDE.md de lucru cu instrucțiuni de integrare Jira/Slack, serverele MCP ale companiei
• Sesiuni OAuth diferite: nu poți fi autentificat pe două conturi în același director de configurare
• Memorie de proiect separată: nu vrei ca contextul proiectelor de la muncă să se scurgă în sesiunile personale și invers

Să te deconectezi și să te reconectezi de fiecare dată când schimbi contextul nu e o opțiune. Pierzi starea sesiunii, iar procesul e pur și simplu enervant.

Soluția: CLAUDE_CONFIG_DIR

Claude Code respectă o singură variabilă de mediu: CLAUDE_CONFIG_DIR. Setează-o pe orice cale, iar Claude va folosi acel director în locul lui ~/.claude pentru tot — autentificare, istoric, setări, memorie, absolut tot. Întreaga configurare durează 60 de secunde.

Pasul 1: Creează un al doilea director de configurare

Alege un nume care are sens pentru cazul tău de utilizare:

mkdir ~/.claude-work

Atât. Claude îl va popula cu structura necesară la prima pornire.

Pasul 2: Autentifică al doilea cont

Rulează Claude o dată cu noul director de configurare pentru a declanșa autentificarea OAuth:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Se deschide browserul. Autentifică-te cu contul corporativ. Tokenul OAuth se salvează în ~/.claude-work — complet separat de sesiunea ta personală din ~/.claude.

Pasul 3: Adaugă un alias de shell

Adaugă asta în configurarea shell-ului ca să nu fii nevoit să ții minte variabila:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Reîncarcă shell-ul:

source ~/.zshrc

Ce obții

Acum ai două medii Claude complet izolate:

• claude — pornește cu contul personal, CLAUDE.md-ul personal, memoria personală
• claude-work — pornește cu contul corporativ, CLAUDE.md-ul de lucru, memorie separată
• Istoric izolat: conversațiile de la muncă rămân la muncă, cele personale rămân personale
• Servere MCP separate: MCP-ul personal pentru vault-ul tău Obsidian nu apare în sesiunile de lucru
• Setări independente: unelte permise diferite, niveluri de permisiuni diferite, preferințe de model diferite pentru fiecare cont

Cum funcționează în culise

Directorul de configurare este sursa unică de adevăr pentru starea lui Claude Code. Iată ce se află înăuntrul fiecăruia:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

Când rulezi claude-work, Claude citește totul din ~/.claude-work. Habar nu are că ~/.claude există. Cele două instanțe sunt complet independente — le poți rula chiar simultan în file diferite ale terminalului.

Scalarea la N conturi

Modelul se extinde la orice număr de conturi. Ești freelancer cu mai mulți clienți? Adaugă mai multe alias-uri:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Fiecare alias primește propriul director de configurare, propria sesiune OAuth, propriul CLAUDE.md cu instrucțiuni specifice clientului. Poți avea un CLAUDE.md pentru Clientul A care cunoaște convențiile codului și proiectul lui Jira și unul complet diferit pentru Clientul B.

Sfaturi practice

• Numește directoarele clar: ~/.claude-work, ~/.claude-clientname — o să-ți mulțumești singur când ai trei sau patru
• Scrie un CLAUDE.md croit pentru fiecare: cel de lucru poate include instrucțiuni specifice companiei (cum se creează tichete Jira, ce canale Slack să referențieze, proceduri de deployment). Cel personal rămâne suplu.
• Servere MCP diferite pentru fiecare cont: configurează uneltele de lucru (Jira MCP, Slack MCP, API-uri interne) doar în configurarea de lucru. Ține-o pe cea personală curată.
• Verifică ce cont e activ: rulează claude config list într-o sesiune dacă nu ești sigur pe ce cont ești — îți arată calea directorului de configurare

Unde această abordare dă greș

CLAUDE_CONFIG_DIR izolează pe cont, nu pe proiect. În interiorul unui singur profil, Claude vede fiecare server MCP pe care l-ai înregistrat vreodată pentru acel cont — din toate proiectele tale. Pentru uz personal solo, de obicei e în regulă. În momentul în care ai mai multe proiecte critice pentru producție sub un singur cont, mai ales în domenii care se suprapun precum facturarea, uneltele de administrare sau infrastructura, apare un risc concret între proiecte: un asistent AI poate apela o unealtă din proiectul A în timp ce lucrează la proiectul B, mai ales când ambele expun operațiuni cu nume asemănătoare.

Modelul cu profile răspunde la întrebarea pe ce cont sunt?. Nu răspunde la întrebarea uneltele cărui proiect ar trebui să fie active acum?. Pentru munca cu miză mai mare, adaugă un al doilea strat de izolare peste separarea pe conturi:

• Un profil per proiect critic pentru producție, nu doar per cont: în loc de ~/.claude și ~/.claude-work, creează ~/.claude-work-billing și ~/.claude-work-admin. Fiecare profil vede doar serverele MCP de care are realmente nevoie.
• MCP la nivel de proiect prin .mcp.json: comite un .mcp.json în rădăcina proiectului care listează doar serverele MCP ale acelui proiect. Claude le preia când e pornit din acel director. Ține-ți configurarea globală minimală — doar unelte universale (notițe, căutare), niciun endpoint de producție.
• Numește serverele MCP fără ambiguitate: evită nume generice precum admin, billing, mcp-server. Prefixează cu numele proiectului: acme_billing_prod, acme_admin_stage. Un nume descriptiv te obligă la o pauză când ceva e pe cale să fie apelat din contextul greșit.
• Verifică fiecare apel de unealtă MCP înainte să-l aprobi: apeluri precum *_create_*, *_delete_*, *_charge_* merită o a doua privire deliberată. Orice viteză câștigi din auto-aprobarea în bloc se evaporă prima dată când o unealtă din proiectul greșit trage în producție.

Regula generală: împarte profilurile agresiv, ține MCP-urile de nivel producție în afara profilului implicit și tratează suprapunerea numelor de unelte între proiecte ca pe un semnal că merită refactorizat.

Concluzie

O singură variabilă de mediu. Un singur alias. Izolare completă între conturi. Fără dansul logout/login, fără conflicte de configurare, fără scurgeri de context. E genul de soluție aproape dezamăgitor de simplă — dar tocmai asta o face bună. Configureaz-o o dată și nu te mai gândi niciodată la ea.

Ce este MCP și de ce nu e chiar atât de simplu

MCP (Model Context Protocol) este un protocol deschis de la Anthropic care îi permite lui Claude să se conecteze la instrumente și date externe. Principiul e simplu: rulează un server local care expune "instrumente" (tools), iar Claude le apelează în timpul conversației.

Pentru Obsidian există teoretic o grămadă de servere MCP. În practică — fiecare are problemele lui.

Problema principală a ecosistemului Obsidian: Obsidian este o aplicație închisă, fără MCP oficial. Comunitatea a umplut golul, dar fiecare implementare o ia pe drumul ei și niciuna nu are "binecuvântarea oficială".

Încercarea 1: MarkusPfundstein/mcp-obsidian

Primul instrument pe care îl găsești când cauți. 3.400 de stele pe GitHub, prezent în toate tutorialele. Pare o alegere sigură.

Cum funcționează: server Python bazat pe pluginul Local REST API din Obsidian. Serverul comunică cu pluginul prin HTTPS, iar pluginul execută operațiile prin Obsidian API.

Ce a mers prost

• Nu a mai fost actualizat de 17 luni
• 85 de issue-uri deschise
• Fără move/rename — doar read, write, append, delete
• Local REST API are un bug documentat de pierdere de date: endpoint-ul POST poate suprascrie în tăcere un fișier la append

Nu e potrivit pentru refactoring — avem nevoie să mutăm fișiere și să păstrăm link-urile. Mergem mai departe.

Încercarea 2: aaronsb/obsidian-mcp-plugin

Am găsit o variantă care funcționează ca plugin nativ de Obsidian. Asta înseamnă acces direct la API-ul intern al Obsidian — backlinks, Dataview, graful de legături. Move-ul prin API-ul nativ actualizează automat toate wiki-link-urile, pentru că Obsidian se ocupă singur de asta.

Dificultăți la configurare

• Pluginul nu se află în catalogul oficial Obsidian (PR-ul stă în așteptare, cu erori de validare)
• Trebuie instalat prin BRAT (Beta Reviewers Auto-update Tool)
• Claude Desktop nu acceptă Bearer token direct din UI — m-a obligat să activez HTTPS în plugin
• Certificatul self-signed pentru localhost creează probleme de încredere

Prin toate aceste soluții de compromis l-am conectat în cele din urmă. Test de bază — vault.move chiar rescrie [[wikilinks]], funcționează cum trebuie.

Ce a mers prost în producție

Când am început refactoringul în masă (drag-and-drop la zeci de foldere în Obsidian + operații MCP simultane), serverul s-a blocat 4+ minute. De ce: pluginul rulează în interiorul Obsidian. Când Obsidian reindexează mii de fișiere după o schimbare masivă de structură, pluginul se blochează odată cu el.

Concluzie: dependența de o instanță Obsidian deschisă și de indexul ei este fatală pentru operațiile în masă.

Încercarea 3: @bitbonsai/mcpvault

Logic — avem nevoie de un server care nu depinde de Obsidian. Lucrează direct cu fișierele de pe disc. @bitbonsai/mcpvault — recomandat în multe recenzii. Acces direct la sistemul de fișiere, configurare simplă (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 instrumente. Obsidian nici măcar nu trebuie să fie deschis.

Înainte să instalez, am verificat un lucru critic — dacă wiki-link-urile se actualizează la move. Am găsit un review de la un utilizator:

Conectorul de sistem de fișiere nu știe că e în Obsidian — vede un folder cu fișiere <code>.md</code> și atât. Nu știe că numele fișierelor poartă greutate semantică, că fiecare <code>[[wikilink]]</code> se rupe în momentul în care redenumești sau muți. Auto-update links funcționează doar când redenumirea se face din interiorul aplicației. Am aflat asta după ce i-am cerut lui Claude să curețe numele fișierelor și m-am întors la un dashboard cu jumătate din link-uri rupte.

Confirmat în documentația proprie a mcpvault: PR #101 (wiki link resolution) este în review, nu a fost merge-uit. Deci un move prin mcpvault ar rupe jumătate din vault. Nu e potrivit.

Încercarea 4: VaultForge (finalul)

blacksmithers/vaultforge — construit special pentru agenți AI care fac refactoring.

Corect arhitectural

• Sistem de fișiere direct — nu depinde de Obsidian
• Motor propriu de wikilink — implementează logica de rezolvare a [[wikilink]] care actualizează toate formele (stem, cale completă, alias, embed)
• Dry run implicit la toate operațiile distructive — întâi arată ce se va schimba, apoi confirmi tu
• 27 de instrumente față de 8–14 la concurenți: batch_rename, update_links, backlinks (analiză de impact), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (clustering TF-IDF)
• Licență MIT, TypeScript, zero sub-dependențe
• Instalare în 30 de secunde prin .mcpb (extensie one-click pentru Claude Desktop)

Test de siguranță pe fișiere izolate

Am creat 4 fișiere de test cu link-uri încrucișate — link-uri stem, link-uri cu alias, link-uri cu cale completă. Mut un fișier într-un subfolder:

delta.md → subfolder/delta-renamed.md

VaultForge a arătat un dry run: "1 fișier va fi redenumit, 3 link-uri vor fi actualizate". Am executat pe bune.

Am verificat după — toate cele trei tipuri de link-uri s-au actualizat corect. Exact asta le lipsea tuturor instrumentelor anterioare.

Cum instalezi VaultForge — instrucțiunea finală

Dacă ai macOS și Claude Desktop:

Pasul 1

Descarcă fișierul .mcpb:

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

Pasul 2

Claude Desktop va deschide dialogul de instalare a extensiei. Introdu calea absolută către vault — fără backslash-uri, cu spații normale:

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

Pasul 3

Apasă Save. Claude Desktop va adăuga extensia în config automat. Nu e nevoie de restart — extensiile .mcpb sunt preluate automat.

Pasul 4

Verifică: într-un chat nou întreabă: "What is the status of my Obsidian vault?" — ar trebui să returneze ceva de genul totalFiles: 416, totalDirs: 135, ...

Ce am învățat despre ecosistemul MCP al Obsidian

În primul rând, "cel mai popular" nu înseamnă "funcțional". MarkusPfundstein/mcp-obsidian are 3.400 de stele și e recomandarea implicită, dar e învechit și îi lipsesc operații esențiale.

În al doilea rând, un plugin nativ are un cost ascuns. Pluginul aaronsb părea ideal — graf, Dataview, move nativ. Dar dependența de o instanță Obsidian pornită și de indexul ei îl face nepotrivit pentru operații în masă serioase.

În al treilea rând, sistemul de fișiere direct fără un motor de link-uri este o capcană. Mcpvault e rapid și simplu, dar "doar mutarea fișierelor" distruge structura vault-ului. Link-urile poartă o semantică impusă pe care sistemul de fișiere nu o cunoaște. Fără o implementare proprie a logicii de wikilink, instrumentul devine o mină.

În al patrulea rând, testează pe date izolate. Înainte să încredințezi vreunui instrument un refactoring în masă — creează un folder de test cu 4–5 fișiere cu link-uri încrucișate și vezi ce se întâmplă. 5 minute de testare economisesc ore de recuperare din backup.

În al cincilea rând, ține un backup git al vault-ului. Cel mai important dintre toate. Un singur git init în interiorul vault-ului și commit-uri periodice — asta e asigurarea împotriva oricărei greșeli a unui agent AI sau instrument. Dacă se strică ceva — git reset --hard aduce totul înapoi.

Concluzie

Drumul a durat câteva ore și trei încercări eșuate. Arhitectura finală arată așa:

• VaultForge — instrumentul principal de lucru. Sistem de fișiere direct + motor propriu de wikilink + 27 de instrumente = refactoring stabil la orice scară.
• Git — versionarea vault-ului. Rollback gratuit pentru orice greșeală.

Acum pot face ceea ce a pornit totul: să-i cer lui Claude să organizeze 400 de note într-o arhitectură PARA ca lumea, să îmbine duplicatele, să adauge frontmatter, să construiască hărți MOC. Fiecare operație e sigură, link-urile se păstrează, iar dry run-ul arată ce se va întâmpla înainte să se schimbe ceva.

Dacă și tu te uiți la Obsidianul tău dezordonat și vrei un asistent AI — începe direct cu VaultForge. Nu repeta traseul meu prin proiecte moarte, plugin-uri beta și servere de sistem de fișiere fără logică de link-uri.

Ce-ar fi dacă fiecare gaură neagră este un Big Bang al unui nou univers? Acest articol explorează ideea că universul nostru ar putea fi un nod într-un arbore recursiv infinit — unde găurile negre nasc sub-universuri, energia se întoarce prin radiația Hawking, iar legile fundamentale ale fizicii sunt concepute în mod deliberat pentru a face imposibil contactul dintre universuri.

Gaură neagră = univers

Ideea a apărut într-un moment de reflecție: o gaură neagră se formează atunci când suficientă masă și presiune se concentrează într-un singur punct. Acea singularitate — densitate infinită, curbură infinită — seamănă în mod suspect cu condițiile pe care le descriem pentru Big Bang.

Ce-ar fi dacă acesta este unul și același eveniment, privit din părți diferite? Din exterior vedem o gaură neagră care înghite materia. Din interior — un nou univers care explodează în existență. Masa și energia care s-au prăbușit în gaura neagră devin materia primă a unui cosmos complet nou, cu propriile stele, planete și, posibil, propriile găuri negre.

Fiecare gaură neagră din universul nostru ar putea conține un univers. Iar universul nostru ar putea exista în interiorul unei găuri negre a unui univers-părinte.

De ce universurile nu pot intra în contact unele cu altele

Iată partea elegantă: odată ce treci de orizontul evenimentelor, nu mai există cale de întoarcere. Relativitatea generală garantează acest lucru — viitorul universului-părinte se află în întregime dincolo de orizontul evenimentelor, inaccesibil din interior. Din perspectiva sub-universului, universul-părinte s-a încheiat deja. Întreaga sa linie temporală a trecut deja.

Aceasta nu este o limitare tehnică pe care am putea-o depăși cu o tehnologie mai bună. Este înscrisă în însăși geometria spațiu-timpului. Universurile sunt fundamental izolate unele de altele — nu prin distanță, ci prin structura timpului.

Ciclul energiei: împrumut și restituire

Dar energia nu se pierde. Radiația Hawking — procesul cuantic prin care găurile negre se evaporă lent — creează un ciclu remarcabil:

1. Un univers-părinte creează o gaură neagră, transferând energie într-un sub-univers
2. Sub-universul își trăiește întregul ciclu de viață de-a lungul a trilioane de ani
3. Gaura neagră se evaporă lent, restituind energia universului-părinte prin radiația Hawking
4. Universul-părinte își primește energia înapoi — cu dobândă

Această „dobândă” este fascinantă: fizicienii cred acum că radiația Hawking păstrează informația. Universul-părinte nu primește înapoi doar energie goală — primește o amprentă a tot ceea ce s-a petrecut înăuntru. Fiecare stea care s-a format, fiecare planetă, fiecare moment de conștiință — codificate în radiație.

Recursivitate până la capăt

Dacă ești programator, tiparul este inconfundabil. Aceasta este recursivitate. Fiecare univers apelează universe() cu mai puțină energie, creând sub-universuri care creează sub-sub-universuri, până când nu mai rămâne suficientă energie pentru a forma găuri negre — cazul de bază.

universe(energy)
  ├── creates black holes
  │     ├── universe(energy - n)
  │     │     ├── universe(energy - n - m)
  │     │     │     └── base case: not enough energy for black holes
  │     │     └── returns energy via Hawking radiation
  │     └── returns energy via Hawking radiation
  └── receives all energy back

Fizicianul Lee Smolin a formalizat o idee similară sub numele de Selecție Naturală Cosmologică: universurile „se reproduc” prin găuri negre, iar fiecare generație are constante fizice ușor diferite — optimizate de-a lungul a nenumărate cicluri pentru a produce mai multe găuri negre, mai multe universuri.

Unde ne aflăm în acest ciclu?

Universul nostru are aproximativ 13,8 miliarde de ani. Sună străvechi, dar în contextul întregii sale durate de viață, asistăm la chiar începutul începutului:

Existăm la aproximativ 0,00000000...01% din durata totală de viață a universului nostru. Era stelelor — tot ceea ce putem vedea — este o scurtă scânteie chiar la început. Adevărata poveste a universului este era lentă și răbdătoare a găurilor negre care creează și evaporă sub-universuri.

Problema dimensiunilor superioare

Tot ceea ce am discutat până acum operează în cadrul înțelegerii noastre tridimensionale. Dar dacă universul nostru este o „felie” a ceva de dimensiune superioară, atunci întregul arbore recursiv de găuri negre și sub-universuri ar putea fi doar umbra unei structuri pe care nu o putem percepe.

În 1884, Edwin Abbott a scris Flatland — o poveste despre ființe bidimensionale incapabile să conceapă o a treia dimensiune. O sferă care trece prin Flatland apare ca un cerc care crește și se micșorează. „Flatlandezii” o pot descrie matematic, dar nu vor înțelege niciodată cu adevărat ceea ce văd. S-ar putea să ne aflăm exact în aceeași situație în raport cu universul nostru.

Ce este conștiința? De ce există experiența subiectivă? David Chalmers a numit acest lucru „problema dificilă” — și ar putea fi cea mai puternică dovadă că ceva operează dincolo de raza noastră dimensională.

Totul este blocat la nivel fundamental

Cea mai frapantă realizare nu este că nu știm — ci că nu putem ști. Fiecare direcție de investigație se lovește de o barieră fundamentală:

• Vrei să vezi universul-părinte? Blocat de orizontul evenimentelor
• Vrei să înțelegi conștiința? Blocat — un sistem nu se poate analiza complet pe sine însuși (teoremele de incompletitudine ale lui Gödel)
• Vrei să știi ce a fost „înainte”? Blocat — timpul a început cu Big Bang
• Vrei să percepi dimensiuni superioare? Blocat de limitările cognitive ale unei ființe tridimensionale

Filosoful Colin McGinn numește acest lucru închidere cognitivă: unele întrebări sunt închise minții umane nu din cauza datelor insuficiente, ci din cauza arhitecturii minții înseși. Diferența dintre „încă nu știm” și „nu putem ști” este profundă.

Singurul lucru care rămâne: perfecționarea de sine

Dacă fiecare ieșire este blocată prin construcție — dacă nu poți privi în afară, nu poți privi înapoi, nu poți privi în sus — atunci rămâne o singură direcție: înăuntru. Universul pare construit în mod deliberat pentru a forța concentrarea asupra propriei ființe.

Această concluzie nu provine din religie sau din manualele de filosofie. Provine din urmărirea logicii găurilor negre, a recursivității, a teoriei informației și a limitelor cunoașterii. Existențialiștii, budiștii, stoicii și fizicienii ajung cu toții în același punct pe căi diferite: scopul existenței ar putea fi pur și simplu rafinarea ființei care există.

Am ajuns aici nu prin credință, ci prin fizică — de la găurile negre, prin universurile recursive, până la blocajele fundamentale ale cunoașterii, până la singura ușă deschisă: a deveni mai buni.

Referințe

• Lee Smolin — Selecție Naturală Cosmologică
• Stephen Hawking — Radiația Hawking
• David Chalmers — Problema Dificilă a Conștiinței
• Edwin Abbott — Flatland: O poveste a multor dimensiuni (1884)
• Kurt Gödel — Teoremele de Incompletitudine

Pentru site-uri simple — portofolii, bloguri, landing page-uri, site-uri de firme mici — un CMS tradițional devine o povară inutilă. Instrumente AI precum Claude Code, Cursor și GitHub Copilot pot acum să-ți editeze direct codul, să înțeleagă contextul, să traducă conținutul și să facă deploy la modificări prin git. Stratul de abstractizare oferit de CMS este înlocuit de o interfață mai inteligentă: limbajul natural.

Taxa CMS pe care o plătești

Orice CMS vine cu un cost ascuns. Nu doar abonamentul — ci întregul ecosistem de complexitate care se înfășoară în jurul site-ului tău altminteri simplu:

• Infrastructură: O bază de date de găzduit, un API de întreținut, un dashboard de securizat. Doar WordPress reprezintă ~43% din web și ~90% dintre atacurile țintite pe CMS-uri.
• Performanță: Generare dinamică de pagini, apeluri API la fiecare cerere, hidratare pe client a datelor din CMS. Portofoliul tău de 3 pagini are acum arhitectura unui produs SaaS.
• Dependență de furnizor: Conținutul tău trăiește în schema de bază de date a altcuiva. Migrezi de la Contentful la Sanity? Ăsta e un proiect, nu o schimbare de configurație.
• Schimbarea contextului: Editezi cod în IDE, apoi treci la dashboard-ul CMS din browser ca să schimbi un titlu. Două modele mentale diferite pentru ceea ce este, în fond, aceeași operațiune.
• Cost: Prețurile CMS-urilor headless scalează adesea cu apelurile API sau cu numărul de intrări de conținut. Un blog personal nu are nevoie de o infrastructură de conținut de $99/lună.

Pentru un site de marketing unde 50 de oameni editează conținut zilnic, acest cost este justificat. Pentru portofoliul unui dezvoltator sau landing page-ul unei firme mici? Construiești un pod ca să treci peste o baltă.

Ce s-a schimbat: AI îți înțelege codul

Motivul pentru care exista CMS-ul era simplu: oamenii non-tehnici (și chiar dezvoltatorii care nu voiau să atingă codul pentru modificări de conținut) aveau nevoie de o interfață vizuală ca să actualizeze site-uri. Codul era prea complex, prea fragil, prea ușor de stricat.

AI a schimbat fundamental această ecuație. Instrumentele AI moderne de scris cod nu doar completează automat — înțeleg structura proiectului, citesc pattern-urile existente și fac modificări corecte contextual. Schimbarea fluxului de lucru este dramatică:

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

Nu e ipotetic. Chiar acest blog rulează pe SolidStart, cu conținutul stocat ca fișiere TypeScript. Fiecare articol — inclusiv acesta — a fost creat spunându-i AI-ului ce să scrie, verificând rezultatul și făcând push în git. Fără dashboard CMS. Fără bază de date. Fără strat API între conținut și cod.

Exemple reale de pe acest site

Acest site suportă 10 limbi, are un blog, generează imagini OG dinamic și produce feed-uri RSS și sitemap-uri. Iată cum arată stratul de conținut — TypeScript pur:

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

Lucruri pe care le fac cu AI și care în mod tradițional ar cere un CMS:

• Adaug un articol nou: "Scrie un articol nou despre X, urmează aceeași structură ca postările existente" — AI creează fișierul, adaugă traducerile, îl înregistrează în index
• Actualizez textul de pe landing page: "Schimbă titlul hero în Y" — AI găsește fișierul corect și îl actualizează
• Traduc conținut: "Adaugă traducerea în germană pentru pagina de prețuri" — AI citește versiunea în engleză și produce o traducere adaptată cultural, nu una cuvânt cu cuvânt
• Corectez o greșeală de tastare: "E o greșeală pe pagina about, 'recieve' ar trebui să fie 'receive'" — gata în 3 secunde, făcut commit în git cu un mesaj relevant

Ce a rezolvat de fapt CMS-ul — și cum îl înlocuiește AI

Să fim sinceri cu privire la ce a adus CMS-ul și cum se mapează fiecare capabilitate pe fluxul de lucru cu AI:

Ideea-cheie: git este deja un sistem de control al versiunilor mai bun decât a construit vreodată vreun CMS. Iar limbajul natural este o interfață mai bună decât orice editor WYSIWYG — pentru că poartă intenția, nu doar formatarea.

Schimbarea de paradigmă: codul este stratul de conținut

Asistăm la o inversiune. Timp de două decenii, tendința a fost să separi conținutul de cod — să pui conținutul într-o bază de date, să-l expui prin API, să-l randezi pe frontend. Avea sens când codul era greu de editat, iar conținutul trebuia să fie accesibil non-dezvoltatorilor.

AI nu a făcut CMS-ul învechit devenind un CMS mai bun. L-a făcut învechit făcând codul la fel de accesibil ca un dashboard.

Evoluția gestionării conținutului web urmează o traiectorie clară:

1. Anii 2000: CMS-uri monolitice (WordPress, Drupal) — conținut și prezentare cuplate într-un singur sistem
2. Anii 2010: CMS-uri headless (Contentful, Strapi) — conținut separat prin API, randat de framework-uri de frontend
3. Anii 2020: Generatoare de site-uri statice + Markdown (Hugo, Astro) — conținut ca fișiere, construit la momentul deploy-ului
4. 2025+: Cod-ca-conținut + AI — conținutul trăiește în cod tipizat, AI este interfața de editare

Când încă ai nevoie de un CMS

Nu e un discurs de tipul "CMS-ul a murit". CMS-ul rezolvă probleme reale la scară. Încă ai nevoie de unul când:

• Echipe editoriale mari: 10+ editori de conținut care au nevoie de acces pe bază de roluri, flux de aprobare și editare simultană. Conflictele de merge din git nu sunt o problemă pe care s-o rezolve un editor de conținut.
• Conținut de înaltă frecvență: Site-urile de știri care publică 50+ articole pe zi au nevoie de pipeline-uri editoriale optimizate, nu de commit-uri git.
• Relații complexe între conținuturi: Cataloagele e-commerce cu mii de SKU-uri, variante de produs și prețuri dinamice au nevoie de baze de date structurate.
• Conformitate cu reglementările: Industriile care cer piste de audit, lanțuri de aprobare a conținutului și procese de revizuire impuse legal au nevoie de sisteme construite special.

Granița este clară: dacă modificările tale de conținut cer coordonare între mai mulți stakeholderi non-tehnici la frecvență mare, un CMS își merită complexitatea. Dacă ești un dezvoltator solo, o echipă mică sau administrezi un site care se schimbă săptămânal, nu din oră în oră — AI + cod este mai simplu, mai rapid, mai ieftin și mai fiabil.

Viitorul: AI ca interfață universală

Tendința se întinde dincolo de CMS. Fiecare strat de abstractizare software care exista pentru că "sistemul de la bază este prea complex pentru interacțiune directă" este comprimat de AI. Dashboard-uri de administrare, interfețe de configurare, editoare vizuale de baze de date — toate acestea sunt interfețe care traduc intenția umană în modificări de sistem. AI face această traducere nativ.

Pentru site-urile simple, viitorul e deja aici. Conținutul tău este cod. Editorul tău este AI. Controlul tău al versiunilor este git. Deploy-ul tău este un push. Întregul strat CMS — dashboard-ul, baza de date, API-ul, găzduirea — era middleware între intenția ta și site-ul tău. AI a eliminat nevoia de acel middleware.

Cel mai bun CMS este niciun CMS. Nu pentru că gestionarea conținutului nu contează — ci pentru că AI a transformat codul însuși în cea mai intuitivă interfață de gestionare a conținutului pe care am avut-o vreodată.

Perplexity Desktop acceptă conectori MCP (Model Context Protocol). Adăugând serverul oficial @modelcontextprotocol/server-filesystem orientat către Obsidian vault-ul tău, îi poți cere lui Perplexity în limbaj natural să citească, să creeze și să editeze note — direct din chat. Fără pluginuri, fără extensii, fără copy-paste.

Problema

Perplexity este excelent la cercetare — caută pe web, rezumă surse și îți oferă răspunsuri cu citări. Dar când vrei să salvezi aceste descoperiri în Obsidian vault-ul tău, fluxul de lucru se blochează: copiezi textul, comuți pe Obsidian, găsești nota potrivită, lipești, formatezi. De fiecare. Dată.

Extensiile de browser precum "Perplexity to Obsidian" ajută la export, dar sunt unidirecționale — AI-ul nu îți poate vedea vault-ul, nu poate citi notele existente și nu poate decide unde să pună lucrurile în funcție de structura folderelor tale.

Ce este MCP?

Model Context Protocol (MCP) este un standard deschis care permite modelelor AI să interacționeze cu instrumente și surse de date locale. Gândește-te la el ca la un port USB pentru AI — conectezi un "server" (un program mic), iar AI-ul capătă noi capabilități. În cazul nostru, serverul filesystem îi oferă lui Perplexity 14 instrumente pentru a lucra cu fișiere:

Perplexity Desktop (Mac App)
  │
  ├── MCP Connector: "Obsidian Vault"
  │     │
  │     └── @modelcontextprotocol/server-filesystem
  │           │
  │           ├── read_file()      → read any .md file
  │           ├── write_file()     → create or overwrite files
  │           ├── edit_file()      → patch existing files
  │           ├── list_directory() → browse vault structure
  │           ├── search_files()   → find files by pattern
  │           └── ... 14 tools total
  │
  └── Perplexity AI Model
        │
        └── "Save this to my daily note" → calls write_file()

Ideea cheie: modelul AI nu accesează direct fișierele tale. El apelează instrumente furnizate de serverul MCP, care rulează local pe mașina ta. Datele tale nu îți părăsesc niciodată calculatorul decât dacă îi ceri explicit AI-ului să facă ceva cu ele.

Cerințe

• Abonament Perplexity Pro (conectorii MCP sunt disponibili pentru utilizatorii plătitori)
• Perplexity Mac App din App Store (nu versiunea de browser)
• Node.js instalat pe Mac-ul tău (pentru ca npx să funcționeze)

Configurare pas cu pas

Întreaga configurare durează aproximativ 2 minute:

Comanda

Comanda de lipit în câmpul Command:

npx -y @modelcontextprotocol/server-filesystem "/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian Vault"

Înlocuiește calea cu locația reală a Obsidian vault-ului tău. Dacă vault-ul este sincronizat prin iCloud, calea va fi sub ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. Asigură-te că păstrezi ghilimelele — calea conține probabil spații.

Cum se folosește

Odată ce conectorul afișează Running cu 14 instrumente disponibile, intră în orice chat Perplexity și începe să vorbești cu vault-ul tău:

> Show me the structure of my Obsidian vault
> Add a new reflection to daily notes/2026-04-12.md: "Started using MCP today"
> Find all notes that mention "meditation"
> Create a new note in concepts/ about quantum computing
> List all files in my ideas/ folder

AI-ul înțelege structura vault-ului tău, respectă convențiile tale de formatare și poate lucra cu conținutul existent. Îi poți cere să cerceteze un subiect pe web și să salveze rezumatul direct într-o notă anume — combinând căutarea Perplexity cu organizarea din Obsidian într-un singur flux.

De ce MCP întrece celelalte abordări

Înainte de MCP, existau modalități limitate de a face legătura între Perplexity și Obsidian:

Limitări actuale

• Doar Mac — conectorii MCP ai Perplexity funcționează momentan doar în versiunea din Mac App Store
• Fără integrare cu API-ul Obsidian — serverul filesystem lucrează cu fișiere brute, nu prin API-ul Obsidian. Asta înseamnă că nu va declanșa pluginuri Obsidian (precum Linter sau Templater) la crearea fișierelor
• Aprobare necesară — operațiunile sensibile cu fișiere pot necesita confirmarea ta în aplicația Perplexity — este o funcție de securitate, nu un bug

Concluzii

Această configurare transformă Perplexity dintr-un instrument de cercetare într-un instrument de cercetare-și-captură:

1. Cercetează pe web și salvează în Obsidian într-o singură conversație
2. AI-ul vede structura vault-ului tău și se adaptează la sistemul tău de organizare
3. Zero comutări între aplicații — totul se întâmplă în chat-ul Perplexity

Surse

• Model Context Protocol — official MCP specification
• MCP Filesystem Server — the server used in this setup
• Perplexity Help Center — Local and Remote MCPs for Perplexity
• Perplexity Blog — Everything is Computer

Un script bash de 6 linii care rulează Claude Code CLI în mod headless în fiecare dimineață la ora 9:00. Caută știri pe web pentru 11 subiecte configurabile, filtrează zgomotul și scrie un digest markdown formatat direct într-un Obsidian vault sincronizat prin iCloud. Zero dependențe. ~100 de linii de configurare în total.

Problema

Ca dezvoltator, să rămâi la curent cu mai multe tehnologii este o taxă zilnică. Feedurile RSS sunt zgomotoase, Twitter îți fură timpul, newsletterele ajung fix când ești adânc în flow. Aveam nevoie de ceva care să facă documentarea în locul meu și să prezinte rezultatele acolo unde deja lucrez — în Obsidian vault-ul meu.

Soluția tipică este să construiești un pipeline de scraping: un scheduler, un crawler, un pipeline NLP, o bază de date, un serviciu de notificări. Sunt săptămâni de muncă pentru ceva care se poate strica atunci când un site își schimbă HTML-ul. Voiam ceva ce pot construi într-o după-amiază.

Arhitectura

Întregul sistem înseamnă 4 fișiere și zero dependențe. Iată cum funcționează de la un capăt la altul:

macOS launchd (9:00 AM daily)
  │
  └── digest.sh
        │
        └── claude -p "$(cat prompt.md)" --max-turns 20 --allowedTools Read,WebSearch,WebFetch,Write
              │
              ├── Reads topics.yaml (11 configurable topics)
              ├── WebSearch → finds news for each topic (last 24-48h)
              ├── WebFetch → reads full articles
              ├── Filters noise: old tutorials, promos, AI spam
              └── Write → saves digest to Obsidian Vault
                    │
                    └── ~/Obsidian Vault/digests/2026-04-12.md
                          │
                          └── iCloud sync → available on all devices

Codul (tot)

Proiectul este intenționat minimal. Fiecare linie își merită locul.

Punctul de intrare: digest.sh

Întreaga aplicație este un script bash de 6 linii:

#!/bin/bash
DIGEST_DIR="$HOME/Developer/news-digest"

claude -p "$(cat "$DIGEST_DIR/prompt.md")" \
  --max-turns 20 \
  --allowedTools Read,WebSearch,WebFetch,Write

Flag-urile cheie: -p rulează Claude în mod headless (fără terminal interactiv), --max-turns 20 îi dă agentului spațiu suficient pentru a documenta toate subiectele, iar --allowedTools restrânge agentul doar la citirea fișierelor, căutarea pe web și scrierea rezultatului.

Creierul: prompt.md

Aici trăiește inteligența. Promptul transformă Claude într-un agent de documentare a știrilor, cu instrucțiuni precise despre ce să caute, cum să filtreze și unde să salveze:

# News Digest Agent

You are a news research agent. Your job is to find today's most important
and interesting news for a senior frontend developer.

## Instructions

1. Read the topics file at ~/Developer/news-digest/topics.yaml
2. For EACH topic, search the web for news from the last 24-48 hours
3. Filter: only include genuinely new and noteworthy items
4. Write the digest as a markdown file to Obsidian Vault digests/YYYY-MM-DD.md
5. IMPORTANT: Use the Write tool to save the file. Do NOT output to stdout.

## Rules

- Language: Ukrainian for summaries, English for titles and technical terms
- If there's no real news for a topic — SKIP IT ENTIRELY
- Prioritize: releases > breaking changes > security > new patterns > discussions
- Max 5 items per topic, sorted by importance
- Include direct links to sources
- Skip promotional content, generic tutorials, and AI-generated spam

Configurare: topics.yaml

Subiectele sunt complet configurabile — adaugi un subiect nou și apare în digestul de mâine. Fiecare subiect are un nume și un context opțional care ghidează căutarea AI-ului:

topics:
  - name: better-auth
    context: "auth library for TypeScript. New releases, breaking changes"

  - name: Next.js
    context: "GitHub issues, releases, App Router, Turbopack, performance"

  - name: SolidJS
    context: "SolidStart, releases, ecosystem, comparison with React"

  - name: Tailwind CSS
    context: "v4 updates, new utilities, plugins"

  - name: Claude AI
    context: "Anthropic announcements, Claude Code, new models, MCP, API"

  - name: GPT AI
    context: "OpenAI announcements, new models, ChatGPT features"

  - name: React
    context: "React 19+, Server Components, new patterns, ecosystem"

  - name: Apple
    context: "Hardware, software, WWDC, developer tools, Apple Intelligence"

  - name: Notable People
    context: >
      Latest tweets from: Elon Musk, Dario Amodei, Sam Altman,
      Jensen Huang, Andrej Karpathy, Simon Willison, Swyx...

  - name: AI Global
    context: "Major AI news, new models, regulations, open-source AI"

Programare cu launchd

Pe macOS, launchd este modalitatea nativă de a programa sarcini recurente (precum cron pe Linux). Fișierul plist definește când și cum rulează scriptul:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.news-digest</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/you/Developer/news-digest/digest.sh</string>
    </array>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>

    <key>StandardOutPath</key>
    <string>/Users/you/Developer/news-digest/logs/stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/you/Developer/news-digest/logs/stderr.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin</string>
        <key>HOME</key>
        <string>/Users/you</string>
    </dict>
</dict>
</plist>

Îl instalezi cu launchctl load ~/Library/LaunchAgents/com.news-digest.plist. Scriptul rulează în fiecare zi la ora 9:00, chiar dacă erai deconectat — launchd va executa sarcinile ratate atunci când sistemul se trezește.

Cum arată rezultatul

În fiecare dimineață, un nou fișier markdown apare în Obsidian vault cu știri structurate și prioritizate:

---
date: 2026-04-12
---

# News Digest — 2026-04-12

## Next.js

### Next.js 16.1 Released with Improved Turbopack Caching
Нова версія Next.js 16.1 включає покращене кешування для Turbopack,
що зменшує час холодного старту на ~40%.
[Посилання](https://nextjs.org/blog/next-16-1)

### Critical Memory Leak Fix in App Router
Виправлено витік пам'яті в App Router при частому перемиканні
між динамічними маршрутами.
[GitHub Issue](https://github.com/vercel/next.js/issues/...)

## Claude AI

### Claude Code 1.5 — MCP Server Auto-Discovery
Anthropic випустив оновлення Claude Code з автоматичним
виявленням MCP серверів у проєкті.
[Блог](https://www.anthropic.com/news/...)

În cifre

Decizii cheie de design

• Claude Code CLI în loc de API — nu e nevoie să gestionezi chei API, clienți HTTP sau parsarea răspunsurilor. CLI-ul se ocupă din start de autentificare, execuția uneltelor și recuperarea după erori
• Obsidian în loc de email — digesturile pot fi căutate, legate între ele și rămân permanente. Trăiesc lângă notițele mele, nu se îneacă într-un inbox
• launchd în loc de cron — launchd este schedulerul nativ pe macOS. Gestionează curat rulările ratate, logarea și variabilele de mediu
• YAML pentru subiecte — adăugarea unui subiect nou înseamnă o modificare de 2 linii. Fără schimbări de cod
• Sari peste subiectele goale — dacă nu există știri reale, secțiunea este omisă complet. Fără umplutură, fără conținut întins artificial

Cum îți construiești propriul agent

Îl poți avea funcțional în 10 minute:

1. Instalează Claude Code CLI și autentifică-te
2. Clonează repo-ul: git clone https://github.com/oleksiimazurenko/news-digest
3. Editează topics.yaml cu interesele tale și prompt.md cu calea ta de salvare
4. Editează fișierul plist cu numele tău de utilizator și căile tale, apoi rulează launchctl load
5. Așteaptă ora 9:00 — sau testează manual cu bash digest.sh

Concluzii

Cel mai interesant lucru la acest proiect este ceea ce nu se află în el. Nicio bază de date, niciun server API, niciun container Docker, niciun pachet npm, niciun virtualenv Python, niciun parser HTML, niciun pipeline NLP. Doar un prompt, o listă de subiecte și un script de 6 linii care deleagă toată munca grea unui agent AI.

Așa arată să construiești cu agenți AI în practică: tu definești ce și unde, iar agentul se ocupă de cum. Timpul total de dezvoltare a fost de aproximativ 2 ore, incluzând iterațiile pe prompt pentru a obține o filtrare de calitate.

Surse

• news-digest on GitHub — full source code
• Claude Code Documentation — headless mode and CLI flags
• Apple Developer — creating launchd jobs
• Obsidian — markdown knowledge base

next-themes randează un tag <script> în interiorul unui React Client Component pentru a preveni flash-ul de temă (FOUC). React 19 avertizează acum despre asta — și nu există nicio modalitate de a-l suprima. Biblioteca nu a mai fost actualizată din martie 2025. Soluția: înlocuiește next-themes cu un store Zustand + useServerInsertedHTML pentru a injecta scriptul în afara arborelui React. Zero dependențe adăugate. Zero FOUC. Zero avertismente.

Problema

Dacă folosești next-themes cu Next.js 15+ și React 19, primești această eroare în consolă la fiecare încărcare a paginii:

Encountered a script tag while rendering React component.
Scripts inside React components are never executed when rendering on the client.
Consider using template tag instead.

src/providers/theme-provider.tsx (7:10) @ ThemeProvider

Aceasta nu este o nepotrivire de hidratare. Este React 19 care avertizează explicit că tagurile <script> randate de componente React pe client nu vor rula niciodată. Scriptul funcționează în timpul SSR (se află în HTML), dar React îl marchează ca fiind incorect.

De ce se întâmplă

next-themes trebuie să seteze clasa de temă corectă pe <html> înainte ca React să hidrateze — altfel obții un flash cu tema greșită. Pentru asta, injectează un <script> inline prin React.createElement:

// next-themes renders a <script> inside a Client Component
return React.createElement(Provider, { value },
  React.createElement("script", {
    suppressHydrationWarning: true,
    dangerouslySetInnerHTML: { __html: `(...theme init code...)` }
  }),
  children
)

React 19 și-a schimbat comportamentul: tagurile script din interiorul componentelor sunt acum marcate explicit. Înainte de React 19, acest lucru era ignorat în tăcere. Prop-ul suppressHydrationWarning de pe script nu ajută — el suprimă avertismentele de hidratare, nu avertismentul „script în componentă".

Ce am încercat (și de ce a eșuat)

Am încercat sistematic fiecare abordare înainte de a găsi soluția:

Soluția: Zustand + useServerInsertedHTML

Ideea cheie: useServerInsertedHTML este un hook Next.js care injectează HTML în stream-ul SSR în afara arborelui de componente React. Scriptul ajunge în HTML, dar React nu îl „vede" niciodată în timpul randării pe client — deci niciun avertisment. Combinat cu un store Zustand pentru stare reactivă a temei, obținem un înlocuitor complet, fără dependențe.

Cum funcționează

SSR (server):
  useServerInsertedHTML → injects <script> into HTML stream
  ↓
  Browser receives HTML with theme script already in it
  ↓
  Script runs BEFORE React hydrates → correct class on <html>
  ↓
  No flash. No mismatch. No warning.

Client (after hydration):
  useEffect → _init() → Zustand store syncs with localStorage
  ↓
  useTheme() → reactive theme state for components

Pasul 1: Store Zustand

Store-ul gestionează starea temei, aplică clase pe DOM, se ocupă de detectarea temei sistemului și sincronizează între taburi. Metoda _init() returnează o funcție de curățare pentru a fi folosită în useEffect:

import { create } from "zustand";

const STORAGE_KEY = "theme";
const MEDIA_QUERY = "(prefers-color-scheme: dark)";

function getSystemTheme(): "light" | "dark" {
  return window.matchMedia(MEDIA_QUERY).matches ? "dark" : "light";
}

function applyTheme(resolved: string, disableTransition: boolean) {
  const d = document.documentElement;

  if (disableTransition) {
    const style = document.createElement("style");
    style.appendChild(
      document.createTextNode(
        "*,*::before,*::after{transition:none!important}"
      )
    );
    document.head.appendChild(style);
    window.getComputedStyle(document.body);
    setTimeout(() => document.head.removeChild(style), 1);
  }

  d.classList.remove("light", "dark");
  d.classList.add(resolved);
  d.style.colorScheme = resolved;
}

interface ThemeState {
  theme: string;
  systemTheme: "light" | "dark";
  resolvedTheme: string;
  setTheme: (theme: string) => void;
  _init: (disableTransition: boolean) => () => void;
}

export const useThemeStore = create<ThemeState>((set, get) => ({
  theme: "system",
  systemTheme: "light",
  resolvedTheme: "light",

  setTheme: (newTheme) => {
    const { systemTheme, disableTransitionOnChange } = get();
    const resolved = newTheme === "system" ? systemTheme : newTheme;
    localStorage.setItem(STORAGE_KEY, newTheme);
    applyTheme(resolved, disableTransitionOnChange);
    set({ theme: newTheme, resolvedTheme: resolved });
  },

  _init: (disableTransition) => {
    const stored = localStorage.getItem(STORAGE_KEY) || "system";
    const system = getSystemTheme();
    const resolved = stored === "system" ? system : stored;

    set({ theme: stored, systemTheme: system, resolvedTheme: resolved });
    applyTheme(resolved, disableTransition);

    // System theme changes
    const mq = window.matchMedia(MEDIA_QUERY);
    const onChange = (e: MediaQueryListEvent) => {
      const newSystem = e.matches ? "dark" : "light";
      const { theme } = get();
      set({ systemTheme: newSystem,
            resolvedTheme: theme === "system" ? newSystem : theme });
      if (theme === "system") applyTheme(newSystem, disableTransition);
    };
    mq.addEventListener("change", onChange);

    // Cross-tab sync
    const onStorage = (e: StorageEvent) => {
      if (e.key !== STORAGE_KEY || !e.newValue) return;
      const system = getSystemTheme();
      const resolved = e.newValue === "system" ? system : e.newValue;
      set({ theme: e.newValue, resolvedTheme: resolved });
      applyTheme(resolved, disableTransition);
    };
    window.addEventListener("storage", onStorage);

    return () => {
      mq.removeEventListener("change", onChange);
      window.removeEventListener("storage", onStorage);
    };
  },
}));

export function useTheme() {
  return useThemeStore((s) => ({
    theme: s.theme,
    setTheme: s.setTheme,
    resolvedTheme: s.resolvedTheme,
    systemTheme: s.systemTheme,
  }));
}

Pasul 2: ThemeProvider

Provider-ul face două lucruri: injectează scriptul de prevenire a FOUC prin useServerInsertedHTML și inițializează store-ul Zustand la montare:

"use client"

import { useEffect } from "react"
import { useServerInsertedHTML } from "next/navigation"
import { useThemeStore } from "@/store/use-theme-store"

const THEME_INIT_SCRIPT = `(function(){
  try {
    var t = localStorage.getItem("theme") || "system";
    var r = t;
    if (t === "system") {
      r = window.matchMedia("(prefers-color-scheme: dark)").matches
        ? "dark" : "light";
    }
    document.documentElement.classList.remove("light", "dark");
    document.documentElement.classList.add(r);
    document.documentElement.style.colorScheme = r;
  } catch(e) {}
})()`

export function ThemeProvider({
  children,
  disableTransitionOnChange = false,
}) {
  // Injects script into SSR HTML outside the React tree
  // — prevents FOUC without triggering React 19 warning
  useServerInsertedHTML(() => (
    <script dangerouslySetInnerHTML={{ __html: THEME_INIT_SCRIPT }} />
  ))

  useEffect(() => {
    return useThemeStore.getState()._init(disableTransitionOnChange)
  }, [disableTransitionOnChange])

  return <>{children}</>
}

Pasul 3: Layout

import { ThemeProvider } from "@/providers/theme-provider"

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <ThemeProvider disableTransitionOnChange>
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

Pasul 4: Folosește-l

import { useTheme } from "@/store/use-theme-store"

export function ThemeSwitch() {
  const { theme, setTheme } = useTheme();

  return (
    <button onClick={() => setTheme(
      theme === "dark" ? "light" : "dark"
    )}>
      {theme === "dark" ? "☀️" : "🌙"}
    </button>
  );
}

Migrare de la next-themes

API-ul este identic în mod intenționat. Migrarea înseamnă o singură modificare de import per fișier:

- import { useTheme } from "next-themes"
+ import { useTheme } from "@/store/use-theme-store"

  // API is identical — no other changes needed
  const { theme, setTheme, resolvedTheme, systemTheme } = useTheme()

Comparație

De ce nu alte alternative?

@wrksz/themes

Un înlocuitor direct care folosește și el useServerInsertedHTML. Funcționează, dar este încă o dependență de la un singur maintainer. Dacă next-themes ne-a învățat ceva — dependențele sunt abandonate. Cu ~100 de linii de cod, poți deține soluția în întregime.

next-themes@1.0.0-beta.0

Există pe npm, dar fără dată de lansare, fără changelog și fără vreo indicație clară că avertismentul React 19 este rezolvat. A paria cod de producție pe o versiune beta pe termen nedefinit nu este un risc care merită asumat.

Doar CSS (prefers-color-scheme)

Funcționează pentru detectarea temei sistemului, dar nu poate gestiona persistența preferinței utilizatorului (localStorage), schimbarea manuală a temei sau opțiunea „system". Pentru asta ai nevoie de JavaScript.

Concluzii

1. next-themes este practic abandonat — ultima lansare martie 2025, avertismentul React 19 nerezolvat
2. useServerInsertedHTML este primitiva Next.js corectă pentru injectarea scripturilor fără avertismente React
3. Zustand oferă stare reactivă a temei cu mai puțin cod decât un provider de Context
4. Întreaga soluție are ~100 de linii, zero dependențe noi, și deții fiecare linie

Surse

• shadcn/ui #10104 — Dark mode guide should address React 19 script warning
• next-themes #296 — React 19 support request (open since 2024)
• React #34008 — Script tags not executing in components (by design)
• @wrksz/themes — Drop-in replacement using useServerInsertedHTML
• Next.js Docs — useServerInsertedHTML API

Aplicația noastră (Promova) folosește Next.js 16 cu un Landing Builder — un sistem bazat pe CMS care asamblează pagini de marketing din ~90 de componente de secțiune diferite (heroes, FAQ-uri, prețuri, recenzii etc.). Arhitectura folosește un sectionRegistry.tsx care mapează numele secțiunilor la apeluri next/dynamic():

// sectionRegistry.tsx — imports all 90 sections
export const sectionRegistry = {
  HeroSection: dynamic(() => import('./HeroSection/HeroSection')),
  FAQSection: dynamic(() => import('./FAQSection/FAQSection')),
  ReviewsSection: dynamic(() => import('./ReviewsSection/ReviewsSection')),
  // ... 87 more
}

O singură pagină de destinație randează doar 5-8 secțiuni. Dar Lighthouse arăta:

Eliminate render-blocking resources
  94 CSS resources (~330 KB)
  Potential savings: 5,440 ms

De ce? Turbopack vede toate cele 90 de căi import() ca fiind accesibile și generează <link rel="stylesheet"> pentru fiecare modul SCSS. Chiar și secțiunile care nu se randează niciodată pe pagină își primesc CSS-ul injectat în <head>. Acesta este un comportament confirmat și așteptat al Next.js App Router. CSS-ul nu este împărțit pe bucăți de cod pentru importurile dynamic() din Server Components. Maintainerii îl consideră un compromis deliberat pentru a preveni FOUC. Nu este planificată o remediere.

Tot ce am încercat (și de ce a eșuat)

Am petrecut zile întregi parcurgând fiecare abordare pe care am putut-o găsi. Iată lista completă:

Capcana inlineCss

Next.js are un flag experimental.inlineCss care înlocuiește toate <link rel="stylesheet"> cu etichete <style> inline. Sună perfect, nu?

Problema: este totul sau nimic. Nu îl poți activa per rută. Dacă ai pagini SSR (force-dynamic), fiecare cerere reconstruiește tot CSS-ul inline. Am încercat — CMS-ul nostru headless nu a făcut față încărcării și a picat. Pentru ca acest lucru să funcționeze în siguranță, 100% dintre paginile tale trebuie să fie force-static sau ISR. Cu peste 20 de pagini SSR (autentificare, tablouri de bord, pagini dinamice), aceasta este o migrare masivă.

Descoperirea: Turbopack Import Attributes

Săpând prin notele de lansare Next.js 16.2, am găsit o funcționalitate slab documentată: Turbopack Import Attributes. Îți permite să înlocuiești pipeline-ul de bundling încorporat pentru un import specific folosind sintaxa TC39 with {}:

import { cssText, styles } from './hero.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}

Aceasta îi spune lui Turbopack: "Nu procesa acest import ca pe o foaie de stil. Trece-l prin loader-ul meu personalizat și tratează rezultatul ca JavaScript."

Aceasta este perspectiva-cheie. În loc ca Turbopack să genereze un <link rel="stylesheet"> care blochează randarea, loader-ul nostru compilează SCSS-ul și îl exportă ca un șir JS. Apoi îl injectăm ca o etichetă <style> inline direct în componentă. Rezultatul: doar CSS-ul pentru secțiunile care se randează efectiv ajunge în HTML-ul paginii. O pagină cu 5 secțiuni primește CSS pentru 5 secțiuni — nu pentru 94.

Soluția

1. Loader Turbopack personalizat

Un script Node.js de ~70 de linii ca pachet yarn workspace (@promova/scss-to-inline-loader):

const { createHash } = require('node:crypto')
const sass = require('sass')
const postcss = require('postcss')
const postcssModules = require('postcss-modules')
const path = require('path')

const SHARED_STYLES = path.resolve(__dirname, '../shared/styles')

// Same prependData as sassOptions.prependData in next.config.ts
const PREPEND_DATA = `
@use "sass:math" as math;
@use "sass:list" as list;
@use "${SHARED_STYLES}/_variables.scss" as *;
@use "${SHARED_STYLES}/_breakpoints.scss" as *;
@use "${SHARED_STYLES}/_mixins.scss" as *;
`

module.exports = function scssToInlineLoader(source) {
  const callback = this.async()
  processScss(source, this.resourcePath)
    .then((js) => callback(null, js))
    .catch((err) => callback(err))
}

async function processScss(source, resourcePath) {
  // 1. Compile SCSS → CSS (with global variables, mixins, breakpoints)
  const sassResult = sass.compileString(PREPEND_DATA + '\n' + source, {
    loadPaths: [path.dirname(resourcePath), SHARED_STYLES],
    style: 'compressed',
    sourceMap: false,
    url: new URL('file://' + resourcePath),
  })

  // 2. Scope class names with postcss-modules (CSS Modules compatible)
  let classNames = {}
  const result = await postcss([
    postcssModules({
      generateScopedName(name, filename) {
        const file = path.basename(filename, path.extname(filename))
          .replace('.module', '')
        const hash = createHash('md5')
          .update(filename + name)
          .digest('base64url')
          .slice(0, 6)
        return `${file}__${name}__${hash}`
      },
      getJSON(_, json) { classNames = json },
    }),
  ]).process(sassResult.css, { from: resourcePath })

  // 3. Export as JS module — same interface as CSS Modules
  return [
    `export const cssText = ${JSON.stringify(result.css)};`,
    `export const styles = ${JSON.stringify(classNames)};`,
    `export default styles;`,
  ].join('\n')
}

Ce face: styles — aceeași hartă de nume de clase cu scop ca la CSS Modules standard. cssText — CSS-ul compilat ca șir de caractere.

2. Componenta InlineStyle

Folosește API-ul încorporat <style href precedence> din React 19 pentru deduplicare automată:

export function InlineStyle({ css, id }: { css: string; id: string }) {
  return (
    <style href={id} precedence="default">
      {css}
    </style>
  )
}

React 19 garantează: același href → un singur <style> în DOM. Dacă o secțiune se randează de două ori pe o pagină, CSS-ul este totuși injectat o singură dată.

3. Migrare per componentă (~6 linii per secțiune)

// BEFORE: Turbopack → <link rel="stylesheet"> (render-blocking)
import styles from './hero_section.module.scss'

// AFTER: Custom loader → JS module → inline <style> (non-blocking)
import { cssText, styles } from './hero_section.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}
import { InlineStyle } from '@promova/scss-to-inline-loader/InlineStyle'

export function HeroSection() {
  return (
    <section className={styles.hero}>
      <InlineStyle css={cssText} id="hero-section" />
      {/* ... component JSX, className usage is identical */}
    </section>
  )
}

Fișierele .module.scss rămân exact la fel. Fără rescrierea CSS-ului. Stylelint, Prettier, suportul IDE — toate păstrate.

De ce este mai bine decât inlineCss: true

Aceasta este diferența critică:

Cu inlineCss: true, o pagină tot primește TOATE cele 94 de foi de stil inline — sunt doar etichete <style> în loc de etichete <link>. HTML-ul se umflă. Cu abordarea noastră, doar CSS-ul care se randează efectiv ajunge în HTML. 5 secțiuni randate → 5 etichete <style>. Atât.

Capcana Turbopack: fără reguli globale pentru .module.scss

O capcană în care am căzut: ai putea crede că poți adăuga o regulă Turbopack în next.config.ts pentru a aplica loader-ul global:

// ❌ THIS CAUSES A FATAL PANIC
turbopack: {
  rules: {
    '**/components/**/*.module.scss': {
      loaders: ['@promova/scss-to-inline-loader'],
      as: '*.js'
    }
  }
}

Nu face asta. Pipeline-ul încorporat de module CSS al Turbopack interceptează fișierele .module.scss înainte ca regulile personalizate să fie aplicate. Creează un asset EcmascriptCssModule care intră în conflict cu ieșirea as: '*.js', cauzând:

FATAL PANIC: inner asset should be CSS processable

Atributele with {} funcționează pentru că îi indică lui Turbopack la locul importului să ocolească complet pipeline-ul de module CSS. Nu există nicio modalitate de a face acest lucru global prin configurare.

Rezultate

Am migrat 127 de componente de secțiune în Landing Builder. Build-ul de producție verificat.

Limitări

• with {} per import este verbos — fiecare import are nevoie de 3 linii suplimentare. Nicio modalitate de a-l aplica global (vezi capcana de mai sus).
• Doar Turbopack — atributele with {} nu sunt suportate de Webpack. Dacă ai nevoie de fallback Webpack, importurile revin la CSS Modules standard (cssText va fi undefined).
• Hashing-ul numelor de clase — loader-ul nostru folosește un algoritm de hashing diferit de cel încorporat în Turbopack. Numele claselor arată diferit în DevTools. Funcțional identice.
• Dimensiunea HTML crește — CSS-ul este inline în HTML în loc să fie stocat în cache ca fișiere separate. Pentru paginile statice/ISR servite din CDN, aceasta nu este o problemă.

Când să folosești asta

Această tehnică este cea mai eficientă atunci când:

1. Ai un pattern registry/barrel — un fișier importă multe componente, dar doar câteva se randează per pagină
2. Ești pe Turbopack — Import Attributes sunt specifice Turbopack
3. Vrei control per componentă — nu un flag totul-sau-nimic
4. SCSS-ul tău este complex — variabile, mixin-uri, breakpoint-uri, imbricare — toate suportate
5. Nu poți folosi experimental.inlineCss — pentru că ai pagini SSR sau vrei control granular

Probleme GitHub asociate

Dacă ești afectat de CSS-ul care blochează randarea în Next.js App Router — nu ești singur:

Problema fundamentală

• #62485 — Render blocking CSS (maintainers: "expected behavior")
• #61066 — Dynamic imports from Server Components are not code-split
• #54935 — Server-side dynamic imports don't split client modules
• #61574 — JS/CSS code splitting doesn't work as documented
• #57634 — Add support for critical CSS inlining with App Router
• #50300 — next/dynamic on server component does not build CSS modules

Funcționalitatea inlineCss și problemele

• PR #72195 — experimental: css inlining (the implementation)
• PR #73182 — Don't inline CSS in RSC payload for client navigation
• #75648 — WhatsApp preview broken with inlineCss + Tailwind
• #83612 — Turbopack wrong font URL with inline CSS

Comunitatea caută soluții

• Discussion #82894 — How to prevent render-blocking with CSS Modules? (2025)
• Discussion #70526 — Ideas for reducing render-blocking CSS
• Discussion #59814 — Render blocking styles with Tailwind
• Discussion #49691 — How to deal with render-blocking modular CSS
• Discussion #59989 — Critical CSS inlining with App Router
• Discussion #80486 — Is optimizeCss still in use?
• Discussion #85465 — Turbopack plugin API (doesn't exist)

Buguri CSS în Turbopack

• #68412 — Incorrect CSS modules load order with external components
• #76464 — Turbopack sometimes strips SCSS imports
• #82497 — SCSS module not loading when not-found.tsx is present
• #88544 — Exporting Sass variables from CSS modules doesn't work with Turbopack

Construit la Promova — o platformă de învățare a limbilor care deservește milioane de utilizatori. Dacă te lupți cu aceeași problemă de CSS, nu ezita să faci referire la acest articol în issue-urile GitHub de mai sus.

Next.js aplică un patch peste fetch-ul global și adaugă un strat de cache care păstrează referințe către datele de răspuns după ce ar fi trebuit eliberate. Fiecare apel fetch adaugă memorie care nu este niciodată returnată către GC. În Docker/Kubernetes acest lucru duce la crash-uri OOM la fiecare câteva ore. Bug-ul există din Next.js 14 (aprilie 2024) și rămâne nerezolvat în 16.2.x (martie 2026). Pe Vercel problema nu se manifestă datorită funcțiilor serverless efemere.

Cum funcționează un fetch normal

Request → fetch → got data → response to user → GC cleans up → memory free

Cum funcționează fetch în Next.js

Next.js interceptează fetch-ul global și îl împachetează cu propriul strat de cache/tracking:

Request → Next.js fetch wrapper → creates:
  - Performance entry (speed tracking)    ← not cleaned
  - Request metadata object               ← not cleaned
  - Internal promise wrapper              ← not cleaned
  - Cache lookup entry                    ← not cleaned
  - Response body (for unique URL)        ← not cleaned
→ Response to user
→ GC sees objects are still referenced → doesn't touch them
→ Memory grows indefinitely

Ce se întâmplă în producție

Self-hosted (Docker/K8s):
  Request 1:      fetch → +100KB → RAM: 100KB
  Request 2:      fetch → +100KB → RAM: 200KB
  Request 1000:   fetch → +100KB → RAM: 100MB
  Request 50,000: fetch → +100KB → RAM: 5GB → OOM Kill 💀
  → Kubernetes restarts the pod → cycle repeats

Vercel (Serverless):
  Request 1: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  Request 2: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  → Memory never accumulates

Versiuni afectate

Next.js — Toate versiunile cu App Router

Node.js

Testat pe Node.js 20, 22, 24, 25 — pierde memorie pe toate.

Ce nu funcționează

Ce funcționează (workaround-uri)

Limitarea workaround-ului cu axios

Propriile apeluri API pot fi înlocuite cu axios. Dar Next.js folosește intern fetch-ul modificat pentru:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• Preluarea datelor în Server Components cu deduplicare
• use cache (Next.js 16)

Chiar și fără un singur fetch în codul tău — Next.js îl folosește tot intern.

De ce Vercel nu rezolvă problema

Logica de business

Vercel este o companie care câștigă bani din găzduirea Next.js. Pe platforma lor problema nu se manifestă (serverless = efemer). Bug-ul afectează doar self-hosted (Docker, K8s, VPS) — adică pe cei care nu plătesc Vercel.

Poziția oficială

Tim Neutkens (maintainer Vercel) a analizat problema și a declarat că este o problemă de undici (biblioteca fetch din Node.js), nu de Next.js. Issue-ul #90433 a fost închis. În ciuda faptului că:

• axios și node-fetch pe același Node.js funcționează fără scurgeri
• Scurgerea apare doar când fetch trece prin wrapper-ul Next.js
• Bug-ul este deschis de 2 ani fără o rezolvare

Priorități

În acești 2 ani echipa Next.js a livrat:

• Turbopack (build-uri de 2-5x mai rapide) — avantaj de marketing
• Cache Components / use cache — reduce încărcarea pe serverele Vercel
• proxy.ts în locul middleware-ului — simplifică deployment-ul edge pe Vercel
• DevTools MCP — hype-ul AI

Memory leak în self-hosted? Nu e o prioritate.

Soluția: AWS Lambda (SST + OpenNext)

Ce este

OpenNext este un adaptor open-source care convertește un build Next.js într-un format pentru AWS Lambda. SST este un framework care automatizează infrastructura.

Arhitectură

Next.js build
  → OpenNext
    → AWS Lambda (SSR, API routes)
    → S3 (static, assets)
    → CloudFront (CDN)
    → SQS + DynamoDB (ISR revalidation)

De ce asta rezolvă memory leak-ul

Funcțiile Lambda procesează cererile și sunt reciclate după 5-15 minute de inactivitate. Memoria nu apucă să se acumuleze.

Deployment

npx sst@latest init
npx sst deploy --stage production

Comparație

Nuanțe Lambda

• Cold starts — prima cerere este mai lentă (~200-500ms)
• Securitate — activează OAC (Origin Access Control), altfel URL-ul Lambda este public
• OpenNext — proiect comunitar, nu oficial Vercel. Funcțiile noi din Next.js se pot strica
• Atac asupra portofelului — în timpul unui DDoS, auto-scaling-ul Lambda poate genera o factură mare

De ce o rezolvare reală este nerealistă

1. Problemă arhitecturală

Scurgerea nu este un bug accidental, ci consecința unei decizii de design: Next.js interceptează fetch-ul global și adaugă cache/tracking peste el. Ca să o repari — trebuie regândit modul în care App Router interacționează cu fetch. Asta afectează ISR, revalidation, data cache, request deduplication — nucleul framework-ului.

2. Conflict de interese

Vercel nu este motivat să repare ceva ce nu le afectează platforma. Self-hosted concurează cu business-ul lor. Cu cât sunt mai multe probleme în self-hosted — cu atât mai mulți oameni migrează pe Vercel.

3. Pasarea vinei

Poziția oficială este "e undici, nu noi". Până când asta nu se schimbă — nu vor lucra la o rezolvare.

4. Nicio rezolvare din comunitate

Licența AGPL-3.0 a Next.js permite fork-uri, dar codebase-ul este uriaș și strâns cuplat cu infrastructura Vercel. Un PR din comunitate pentru a repara wrapper-ul fetch ar necesita o înțelegere profundă a arhitecturii interne și aprobarea maintainerilor — care au închis deja issue-ul.

Concluzii

1. Dacă ești pe Vercel — nicio problemă, nu ai ce face
2. Dacă ești self-hosted și ai nevoie de serverless — SST + OpenNext pe AWS Lambda
3. Dacă ești self-hosted Docker — înlocuiește fetch cu axios unde se poate, monitorizează RAM-ul, configurează restart automat al pod-urilor
4. Dacă începi un proiect nou — ia în calcul SvelteKit sau Nuxt ca alternative fără această problemă

Surse

• Issue #64212 — Memory Leak with global fetch (April 2024)
• Issue #68578 — Possible memory leak in Fetch API (August 2024)
• Issue #85914 — Memory Leak with fetch + standalone (November 2025)
• Issue #90433 — OOM in 16.0.10 (February 2026)
• Discussion #88603 — OOM in Docker/K8s (January 2026)
• Discussion #88078 — cacheMaxMemorySize behavior
• OpenNext
• SST — Next.js on AWS
• Secret knowledge to self-host Next.js
• Next.js Memory Usage Guide