Expertiză · Software la comandă

Un sistem construit pentru felul în care lucrează organizația ta, nu pentru cazul general.

Construim sisteme de la zero, când niciun produs de pe piață nu se potrivește: platforme cu mai multe aplicații și o bază de date comună, conectori către sisteme care nu au API, conducte care citesc documente și mișcări de bani, și programe al căror rezultat nu e un ecran, ci un dosar de fabricație. La final predăm depozitul, documentul de punere în funcțiune și accesele.

Discută un proiect

Construit dejaAm ales patru sisteme proprii din discipline diferite, tocmai ca să nu arate ca patru variante ale aceluiași site, și am rulat testele fiecăruia azi. Un monorepo cu 3 aplicații și 12 pachete, 486 de fișiere TypeScript și 68 de fișiere de test, 151 de comituri, arbore de lucru curat. Un sistem de interogare a două portaluri B2B fără API public: 38 de teste trecute în 0,52 s, pe răspunsuri reale salvate ca fixturi. O conductă care citește notificări bancare din e-mail și PDF și le scrie în Postgres cu deduplicare prin amprentă. Și un generator de documentație de inginerie, în Python, cu 44 de teste trecute în 0,50 s. Cifrele sunt din rulările mele de pe 6 septembrie 2026, nu din README-uri.

„La comandă” înseamnă că sistemul se scrie după felul în care lucrează deja oamenii tăi, nu invers. Are un cost pe care e cinstit să-l spunem înainte: cineva trebuie să-l întrețină, iar acel cineva suntem noi sau echipa ta. De aceea prima întrebare pe care ți-o punem nu e ce vrei să construim, ci dacă există un produs care face deja 80% din treabă. Dacă există, îl spunem, chiar dacă asta înseamnă că nu ne dai nouă lucrarea. Ce rămâne după întrebarea aia — bucata care nu se cumpără — e exact ce construim bine.

Amplitudinea se vede mai clar din patru sisteme diferite decât dintr-o listă de tehnologii. Primul e o platformă pentru o instituție de spectacole: un monorepo cu trei aplicații (site public, cabinet administrativ, API) și douăsprezece pachete comune — bilete, comerț, conținut, notificări, restituiri, securitate. Al doilea interoghează, la cerere, portalurile B2B ale unor tur-operatori care nu publică niciun API: autentificare programatică, reîntoarcere la login când sesiunea expiră, și un analizor testat pe răspunsuri reale capturate în fișiere. Al treilea citește notificări bancare din e-mail și extrase în PDF și le așază în Postgres. Al patrulea nu are ecran deloc: e programul care generează modelul, lista de materiale și planșele unei mașini industriale.

Ce ține un astfel de sistem în picioare nu e stiva, ci regulile scrise înainte de primul ecran. În platforma pentru instituția de spectacole, contractul de implementare fixează în text lucruri care altfel se negociază la fiecare ședință: banii se țin în unități minore întregi, cu moneda alături; disponibilitatea unui loc e dată numai de o rezervare durabilă din baza de date, niciodată din memoria intermediară; comenzile critice au chei de idempotență; căile P0 și P1 cad închis, nu deschis; datele de card nu se stochează niciodată. Regulile astea se scriu la început pentru că, scrise la sfârșit, ar însemna rescrierea sistemului.

La final se predau trei lucruri, nu unul: depozitul cu tot istoricul lui, documentul care spune cum se pune în funcțiune pe un server gol, și accesele. Sub directorul nostru de proiecte sunt 150 de depozite git, 103 fișiere README și 19 documente de punere în funcțiune sau de predare — numărate azi, nu estimate. Regula de proprietate o scriem în contract înainte de start și e simplă: codul scris special pentru tine e al tău, bibliotecile terțe rămân sub licența lor, iar componentele noastre refolosibile și produsele noastre se licențiază, nu se cedează. Dacă o parte din lucrare se rezolvă mai bine cu un produs de-al nostru, ți-o spunem exact așa, ca să știi de la început ce cumperi și ce primești.

Ce cuprinde

Lucrarea, pe componente

Scriem regulile domeniului înainte de primul ecran

Un contract de implementare, în text, care fixează vocabularul și invariantele: ce înseamnă un loc rezervat, ce înseamnă o plată încasată, ce cade închis când un serviciu nu răspunde. În platforma pentru instituția de spectacole regulile sunt explicite — banii în unități minore întregi plus moneda, disponibilitatea numai din rezervări durabile în baza de date, chei de idempotență pe comenzile critice, memoria intermediară niciodată sursă de adevăr pentru stoc, datele de card niciodată stocate. Sunt reguli care se verifică în cod, nu principii.

Construim nucleul pe teste care rulează fără sistemul viu

Răspunsurile reale ale sistemelor externe se salvează ca fixturi și analizorul se testează pe ele, nu pe portalul care poate să fie jos exact în ziua în care lucrezi. La sistemul de interogare a portalurilor de zboruri, suita rulează în 0,52 secunde și trece integral; testele care chiar ating portalurile sunt marcate separat și se cer explicit. Aceeași separare există în toate cele patru sisteme: ce se poate verifica pe masă se verifică pe masă.

Predăm depozitul, punerea în funcțiune și accesele

Nu un fișier zip. Depozitul cu istoricul comiturilor, un document care descrie cum se ridică sistemul pe o mașină goală — bază de date, variabile de mediu, serviciu de sistem, server web în față — și accesele care îl fac al tău. Sub directorul nostru de proiecte există azi 150 de depozite git, 103 README-uri și 19 documente de tip DEPLOY sau HANDOVER; forma asta de predare e obiceiul, nu excepția.

Când sistemul celuilalt nu are API, spunem ce risc iei

Portalurile B2B pe care le interogăm nu publică interfață programatică, deci autentificarea se face ca a unui utilizator, cu cookie de sesiune și cheie de conectare, și se reface automat la expirare. Riscul e scris în README-ul proiectului, nu descoperit ulterior: autentificarea programatică e o zonă gri față de condițiile de utilizare ale portalului, iar pentru un volum de producție intens soluția corectă e să ceri operatorului API-ul lui oficial. Un client are dreptul să afle asta înainte să semneze, nu după.

Documentele intră o singură dată, chiar dacă le citim de zece ori

Fiecare tranzacție extrasă dintr-o notificare bancară sau dintr-un extras PDF primește un identificator extern calculat ca amprentă SHA-256 peste câmpurile ei, iar inserarea în Postgres se face cu `ON CONFLICT (external_id) DO NOTHING`. Consecința practică: cutia poștală poate fi recitită de câte ori vrei, iar soldul nu se dublează. Fără regula asta, orice conductă de ingestie ajunge să producă dubluri, adică o problemă de contabilitate.

Clasificarea cu model se face prin unelte, nu prin text liber

Modelul nu scrie o propoziție pe care apoi o ghicim noi: primește șapte unelte — plată de la client, salariu, impozit, plată către creditor, cheltuială de exploatare, necunoscut — și trebuie să aleagă una, cu un scor de încredere între 0 și 1. Pentru potrivirea aproximativă a numelor de contrapartidă există o rezervă separată, pe asemănare de vectori. „Necunoscut” e o ieșire legitimă, cu motiv, nu un eșec ascuns.

Uneori rezultatul nu e un ecran, ci un dosar

Un sistem propriu în Python generează modelul tridimensional al unei mașini industriale, lista de materiale cu status de eliberare pe fiecare poziție, planul de verificare, schema de cabluri și planșele PDF — dintr-o singură comandă, ca nimic din pachet să nu poată rămâne în urma modelului. Are 44 de teste care trec în jumătate de secundă și care verifică reguli de inginerie, nu doar cod: că domeniul activ e exact un metru cub, că nicio poziție din lista de materiale nu rămâne fără rând de verificare, că mașina nu extrudează niciodată în repaus.

Măsurarea continuă e altă disciplină decât interogarea la cerere

Un sistem propriu captează simultan mai multe posturi de radio cu `ffmpeg`, transcrie local cu un model open-source, apoi caută reclame cu un scor transparent pe grupe de semnale în română și rusă, cu prag configurabil, și grupează aceeași reclamă difuzată pe posturi diferite printr-o amprentă audio de tip chromaprint — pentru că transcrierile diverg, dar sunetul e identic. Are 81 de teste care trec în 1,14 secunde. Un sistem care rulează nesupravegheat are nevoie de contoare de acoperire, reîncercări cu închiriere de sarcină și un autotest, altfel tace când se strică.

Spunem și ce nu construim

Nu construim de la zero ce se rezolvă cu un produs existent, al nostru sau al altcuiva, doar pentru că lucrarea ar fi mai mare. Nu preluăm sisteme pe care nu le putem rula local, cu date de test, până la sfârșitul primei etape. Și nu pornim un sistem care depinde de un furnizor extern înainte să verificăm ce poartă publică are acel furnizor — verificarea aia e prima, nu ultima.

Cum arată

Traseul, pas cu pas.

Delimităm domeniul și scriem regulile

O etapă de citit sisteme și de vorbit cu oamenii care fac munca azi, încheiată cu un document scurt cu vocabularul, invariantele și ce cade închis. Livrăm documentul acesta chiar dacă nu se ajunge la construcție — e util și fără noi. În el intră și lista de sisteme externe de care depinde lucrarea și verificarea a ce poartă publică are fiecare, pentru că de acolo vin surprizele.

Construim nucleul, cu testele lui, înainte de ecrane

Regulile domeniului, modelele de date, analizoarele, calculele — plus testele care rulează fără sistemele vii, pe fixturi capturate din răspunsuri reale. Livrăm suita și rezultatul ei, cu comanda de rulare, ca să o poți rula tu. Un nucleu care nu poate fi testat fără mediul de producție e un nucleu pe care nu-l putem repara repede mai târziu.

Punem interfața și integrările peste nucleu

Cabinetul administrativ, ecranele publice, punctele de intrare pentru alte sisteme. Aici se leagă furnizorii externi, fiecare cu un adaptor propriu și cu o variantă de simulare, ca sistemul să poată fi rulat integral fără conturi reale. Livrăm și modul de rulare local, cu bază de date și servicii ridicate din containere.

Punem în funcțiune și predăm

Instalare pe infrastructura convenită, serviciu de sistem, server web în față, jurnale și rotația lor, autotest. Apoi predarea: depozit, document de punere în funcțiune scris pentru o mașină goală, accese, și o trecere în revistă a ce rămâne de făcut. Ce nu s-a apucat să intre în lucrare se scrie ca listă, nu se lasă nespus.

Trei pași și ordinea lor, care e jumătate din lucrare. Întâi regulile domeniului scrise în text — ce înseamnă un loc rezervat, cum se țin banii, ce cade închis când un serviciu tace. Apoi nucleul cu testele lui, care rulează pe răspunsuri reale salvate ca fixturi, fără sistemele vii. La final punerea în funcțiune și predarea: depozit, documentul pentru o mașină goală, accese. Săgeata înapoi de la pasul trei la pasul unu e reală: ce se descoperă la punerea în funcțiune schimbă regulile, nu se ascunde sub ele.

Datele

Ce atingem, unde stau și cât rămân

Întrebările pe care le pune oricine are un responsabil cu protecția datelor — puse aici înainte să le pună el.

Unde rulează și cine ține cheia: Sistemul rulează pe infrastructura convenită în scris la început: serverul tău, un server administrat de noi, sau un furnizor de găzduire ales împreună. Cele patru sisteme de mai sus rulează diferit între ele — unul ca serviciu de sistem în spatele unui server web, unul din containere, unul ca proces programat pe o mașină locală, unul doar la comandă, pe stația de lucru. Alegerea se ia din constrângerile datelor, nu din obișnuință.
Credențialele nu stau în cod și, unde se poate, nici pe disc: Parolele și cheile se citesc din variabile de mediu, iar fișierul care le conține se restrânge la utilizatorul curent. Într-un conector către un sistem extern, jetonul de sesiune se ține doar în memorie și se reface la expirare sau la primul refuz — parola și jetonul nu se scriu în niciun fișier. Regula se verifică la revizie: o cheie ajunsă în depozit e un incident, nu o scăpare.
Datele care intră din documente: Când sistemul citește e-mailuri sau PDF-uri, atinge date reale de business: sume, date calendaristice, denumiri de contrapartidă, numere de cont. Se stochează în baza de date a beneficiarului, cu identificator propriu, care nu se poate repeta, per înregistrare, și se poate reconstitui de la sursă. Ce pleacă spre un model extern, dacă se folosește unul, e descrierea tranzacției — nu documentul întreg și nu atașamentul.
Ce se păstrează și cât: Termenul de păstrare se stabilește pe tip de dată, nu global, și se scrie înainte de punerea în funcțiune: înregistrările de business după obligațiile legale ale beneficiarului, jurnalele tehnice pe o fereastră scurtă, fișierele intermediare — capturi audio, atașamente descărcate — cu curățenie automată. Un sistem care nu are politică de ștergere ajunge, în șase luni, un risc mai mare decât problema pe care o rezolva.
Ce rămâne la noi după predare: După predare, accesul nostru la sistemele tale există numai dacă există un contract de mentenanță care îl cere, și se retrage când acela se încheie. Copiile de lucru de pe stațiile noastre se șterg la cerere. Ce păstrăm în orice caz sunt componentele generice pe care le-am scris și care nu conțin datele tale — și pe acelea le declarăm de la început, ca să nu fie o surpriză la final.

Un caz

Un sistem de interogare pentru două portaluri care nu au niciun API

Situația

O agenție de turism avea nevoie, la cerere, de disponibilitatea locurilor și de tarifele pe cursele charter din portalurile B2B a doi tur-operatori. Portalurile sunt gândite pentru ochi omenesc: te loghezi, cauți, citești un tabel. Nu există interfață programatică publicată, iar informația era recitită manual, de mai multe ori pe zi, de un om.

Ce am construit

Am scris un client care se autentifică programatic și își reface singur sesiunea când expiră, un analizor care transformă răspunsurile în obiecte și un strat de identificatori pentru aeroporturi, unde codul e format din oraș și port, iar unele apeluri cer cele două părți separat. Peste ele: o comandă de linie care întoarce o rută completă cu disponibilitate și preț, un mod de cereri în lot cu pauze între ele ca să nu se blocheze contul, și două puncte de intrare JSON pentru cazul în care altă platformă vrea să consume rezultatul. Analizorul se testează pe răspunsuri reale, salvate ca fixturi în depozit, iar testele care chiar ating portalurile sunt marcate separat și nu rulează implicit.

Ce a ieșit

Suita trece integral: 38 de verificări în 0,52 secunde, fără să atingă portalurile. O cerere întoarce, într-un singur răspuns, disponibilitatea în cele patru stări pe care le folosește portalul și tariful cu clasă și bagaj, în moneda cerută. Rezultatul se poate consuma din linia de comandă, ca JSON, sau prin cele două puncte de intrare HTTP.

Ce nu spune cazul

Autentificarea programatică rămâne o zonă gri față de condițiile de utilizare ale portalurilor, iar asta e scris în README-ul proiectului, nu descoperit după livrare. Pentru un volum de producție intens, recomandarea noastră e explicită: se cere API-ul oficial de la operatori. Sistemul face cereri punctuale și pune pauze între ele tocmai ca să nu ajungă un instrument de extragere în masă.

Întrebări

Ce ne întreabă oamenii înainte să sune

De ce nu scrie niciun preț pe pagina asta?

Pentru că nu l-am putea scrie cinstit. Efortul unui sistem la comandă e dat de trei lucruri pe care nu le știm înainte să ne uităm: câte sisteme externe trebuie atinse și dacă vreunul are API, câte reguli de business există deja scrise undeva și câte trebuie descoperite de la oameni, și cine ține sistemul în viață după livrare. Un număr dat înainte de a vedea sistemul e o ghicitoare cu factură. Ce putem face repede e prima etapă — citit, delimitat, scris regulile — care se estimează corect și rămâne utilă chiar dacă te oprești acolo.

Cine deține codul la final?

Codul scris special pentru tine e al tău, cu tot cu depozit și istoric. Bibliotecile terțe rămân sub licențele lor — nu putem să ți le cedăm, pentru că nu sunt ale noastre. Componentele noastre refolosibile și produsele noastre existente se licențiază pentru utilizare, nu se transferă; dacă lucrarea ta se sprijină pe una dintre ele, îți spunem asta în oferta scrisă, înainte de start, nu în ultima ședință.

Ce se întâmplă dacă vrem să continuăm cu altcineva?

Predarea trebuie să facă asta posibilă fără noi, altfel n-a fost predare. De aceea documentul de punere în funcțiune se scrie pentru o mașină goală și nu presupune nimic din capul nostru, iar testele rămân în depozit ca următoarea echipă să știe ce se strică atunci când modifică. Ce nu putem promite e că un sistem complex se preia fără efort — putem promite doar că nu-i lipsește nimic din ce trebuie ca să fie preluat.

Pot să văd un sistem construit de voi, ca să judec calitatea?

Parțial, și e corect să spunem unde se oprește. Sistemele construite pentru clienți nu sunt ale noastre ca să le arătăm, iar cele interne conțin date reale de business. Ce putem face în fața ta, pe ecran, e altceva: deschidem depozitul, îți arătăm regulile domeniului scrise în text, rulăm suitele de teste — 38 într-o jumătate de secundă pe unul, 81 în puțin peste o secundă pe altul, 44 pe al treilea — și citim împreună codul care face afirmația pe care o pui la îndoială. Site-ul acesta e, la rândul lui, un sistem propriu care poate fi inspectat din exterior.

Sistemul nostru vechi nu are API. Se poate face ceva?

De obicei da, dar cu risc declarat. Ordinea e: întâi întrebăm dacă furnizorul are un API oficial pe care pur și simplu nu l-a documentat public — se întâmplă des. Dacă nu are, se poate lucra prin autentificare programatică, exact ca un utilizator, cu sesiune reînnoită automat; am construit așa un sistem care interoghează două portaluri B2B. Atunci îți scriem în clar că e o zonă gri față de condițiile de utilizare ale furnizorului și că, pentru volum mare, soluția durabilă e să ceri API-ul oficial. Decizia rămâne a ta, dar informată.

Folosiți inteligență artificială ca să scrieți codul?

Da, și nu ascundem asta. Contează regulile sub care se face: fiecare bucată de lucrare se închide cu teste care rulează, cu verificare de tipuri și cu o revizie a diferențelor înainte de comitere, iar limitele sunt scrise în depozit — fără publicări în producție din interiorul lucrării, fără modificări în conturi externe, adaptoare pentru furnizori doar cu variantă de simulare. Un cod scris repede și nedovedit e mai scump decât unul scris încet. Ce vinde asta e viteza pe partea plictisitoare, nu absența verificării.

Ce faceți când, la mijloc, se dovedește că ideea inițială era greșită?

Spunem. Într-un proiect propriu de inginerie am ajuns, după evaluare, la o a doua arhitectură complet diferită pentru aceeași problemă și am scris-o ca alternativă documentată, cu porțile care trebuie trecute înainte de orice comandă, în loc să continuăm pe prima pentru că era deja începută. Costul unei schimbări de direcție la jumătate e mai mic decât al unui sistem livrat în forma greșită, iar diferența o plătește beneficiarul în ambele cazuri.

Cât de mare poate fi lucrarea?

La un capăt, un sistem cu trei aplicații și douăsprezece pachete comune într-un singur depozit, 486 de fișiere TypeScript, 68 de fișiere de test și 151 de comituri, cu bază de date relațională, coordonare efemeră separată de sursa de adevăr și contracte comune între aplicații. La celălalt capăt, un sistem cu un singur proces și douăzeci de puncte de intrare, care e exact cât trebuie. Amplitudinea nu e o promisiune despre orice dimensiune — e observația că am lucrat la ambele capete.

Faceți și întreținere după livrare?

Da, dar ca înțelegere separată, nu ca subînțeles. Un sistem la comandă are nevoie de actualizări de securitate, de urmărirea schimbărilor la furnizorii externi și de cineva care se uită la jurnale. Dacă preferi să faci asta cu echipa ta, predarea e construită ca să se poată. Dacă preferi să o facem noi, se scrie ce acoperă și ce nu — inclusiv ce înseamnă „urgent”, pentru că fără definiție cuvântul ăsta nu înseamnă nimic.

Pe ce se sprijină fiecare afirmație de mai sus (15 surse)

150 de depozite git, 103 fișiere README și 19 documente de tip DEPLOY / HANDOVER / HANDOFF sub directorul de proiecteProjects:find /Users/macbook_nou/Projects -maxdepth 3 -name .git → 150; find -maxdepth 2 -iname README.md → 103; find -maxdepth 2 -iname 'HANDOVER*.md' -o -iname 'HANDOFF*.md' -o -iname 'DEPLOY*.md' -o -iname 'DEPLOYMENT*.md' → 19
Monorepo cu 3 aplicații (web, admin, api) și 12 pachete comune: cms, commerce, config, data, database, domain, notifications, refunds, security, seo, ticketingpackages:ls apps packages
486 de fișiere TypeScript/TSX, 68 de fișiere de test, 151 de comituri, arbore de lucru curatLuceafarul-E2E:find apps packages -type f \( -name '*.ts' -o -name '*.tsx' \) -not -path '*/node_modules/*' → 486; același filtru pentru *.test.ts / *.spec.ts / *.test.tsx → 68; git log --oneline | wc -l → 151; git status --porcelain → gol
Reguli canonice scrise în contractul de implementare: bani în unități minore întregi plus monedă ISO, disponibilitate numai din rezervări durabile în baza de date, chei de idempotență pe comenzile critice, Redis niciodată sursă de adevăr pentru stoc, căile P0/P1 cad închis, datele de card nu se stocheazăIMPLEMENTATION.md:12, 23, 27, 29, 30, 32
Regula de închidere pe fiecare bucată de lucrare: implementare, teste adăugate, rulare de teste și verificare de tipuri, inspecția diferențelor, comitere, raport cu SHA-ul comitului și riscurile; fără publicări în producție și fără modificări în conturi externeIMPLEMENTATION.md:20-22, 34-35 (secțiunile „Safety and truth” și „Worker closure”)
38 de teste trecute în 0,52 s, fără atingerea portalurilor; testele „live” sunt marcate separatsamo-flights:./.venv/bin/python -m pytest -q -m 'not live' → „38 passed in 0.52s”; README.md:72-74
Autentificare programatică cu cookie de sesiune și cheie de conectare, re-login automat la expirare; identificatorii de aeroport sunt de forma oraș.port, iar unele apeluri cer cele două părți separatREADME.md:62, 64, 65
Riscul e declarat de proiect: autentificarea programatică e zonă gri față de condițiile de utilizare, iar pentru producție intensă se cere API-ul oficial de la operatoriREADME.md:77-78
Deduplicare la ingestie: identificator extern din amprentă SHA-256 și inserare cu ON CONFLICT (external_id) DO NOTHINGinsert_to_postgres.py:6, 90 (tabela `transactions`, coloana `external_id TEXT NOT NULL UNIQUE`, liniile 32-40)
Clasificare prin unelte: șapte unelte disponibile modelului, fiecare cu scor de încredere 0-1, plus o rezervă pe asemănare de vectori pentru potrivirea numelor de contrapartidăclassify_transaction.py:1-14 (antetul modulului), 36-60 (definiția primelor unelte)
44 de teste trecute în 0,50 s într-un sistem care generează CAD, listă de materiale, plan de verificare și planșe dintr-o singură comandăconcrete-3d-printer:./.venv/bin/python -m unittest discover -s tests → „Ran 44 tests in 0.501s OK”; tests/ (10 fișiere); cad/mega_cp_cube_1.py (441 linii), cad/generate_fabrication_parts.py (386 linii)
A doua arhitectură pentru aceeași problemă, documentată ca alternativă cu porți de achiziție, în loc să fie continuată primaarhitectura-cp-cube-1r-brat-robotic.md:secțiunile „Porți de achiziție” și „Testele sintetice obligatorii înainte de comandă”
81 de teste trecute în 1,14 s într-un sistem de captură și măsurare continuă: ffmpeg pe mai multe posturi, transcriere locală, scor pe grupe de semnale RO+RU cu prag configurabil, amprentă audio chromaprint pentru gruparea aceleiași reclame între posturiradio-ad-monitor:./.venv/bin/python -m pytest -q → „81 passed in 1.14s”; src/radio_ad_monitor/audio_fingerprint.py:1-13; src/radio_ad_monitor/detector.py:19-50 (grupele de semnale); config/example.toml:12-14 (prag 0,58)
Douăzeci de puncte de intrare într-un singur proces, rulat ca serviciu de sistem, ca exemplu de capătul mic al amplitudiniiserver.js:grep -c '^app\.\(get\|post\|put\|delete\)' → 20; transport-dashboard.service (unitate systemd, Restart=on-failure)
Credențialele se citesc din variabile de mediu, cu fișierul restrâns; într-un conector, jetonul se ține doar în memorie și se reface la expirare sau la primul refuz, fără a fi scris pe discREADME.md:samo README:16 („chmod 600 .env”); connector README, secțiunea „Ce face” — reface login-ul la expirare sau la 401, nu salvează parola sau token-ul în fișiere

Citările interne arată numele fișierului și linia. Calea completă rămâne în depozitul nostru; o putem parcurge împreună, la cerere.

Cum lucrăm Toate serviciile

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm