execuție guvernată pentru instrumente externe
Prototip
Instalezi o capabilitate, nu o integrare.
Syntagma permite unui produs să ofere instrumentele altcuiva fără să construiască un proiect separat pentru fiecare. Un dezvoltator declară instrumentul într-un manifest versionat — ce expune, ce widget îl afișează, ce porți de politică îl condiționează, cum se plătește — iar o organizație instalează acea versiune. Instrumentul apare apoi ca widget integrat sau ca simplu apel de API, în timp ce identitatea, politicile, plata și auditul rămân la platformă, în loc să fie rescrise în fiecare integrare. Platforma se numește Syntagma, iar codul, pachetele publicate și protocoalele ei păstrează numele de lucru xapps. Patru luni și jumătate separă primul commit de ultimul: 1.618 commituri, o poartă cu 519 rute de API documentate, trei console de operare, protocoale proprii pentru compunere, orchestrarea plăților și monetizare și paisprezece pachete publicate pe npm. Apoi s-a oprit. Nimic nu este lansat și nimeni nu o folosește — Syntagma este construită și pusă pe pauză.
Am proiectat-o și am construit-o: contractele pentru manifest și pentru porțile de politică, poarta de execuție și procesele ei de fundal, cele trei straturi de protocol, SDK-urile pentru Node și PHP, cele trei console de operare, documentația și identitatea. Tot eu am fixat pragul pentru „gata” — bateria completă rulată și justificată la fiecare schimbare, fiecare eșec dus până la o cauză reală sau la un flake cunoscut înainte ca lucrarea să conteze ca terminată — și am ales să pun platforma pe pauză în loc să o lansez.
Imagini din proiect
Ce construim
O capabilitate, declarată și instalată
Un dezvoltator împachetează instrumente, widget-uri, porți de politică și puncte de acces într-un singur manifest versionat; o versiune este un instantaneu care nu se mai schimbă, iar o instalare este acea versiune activată pentru o singură organizație. Manifestul este contractul: ce nu este declarat și validat la importul pachetului nu se întâmplă la rulare. Zece rânduri de manifest ajung pentru un instrument care funcționează.
Porțile de politică decid înainte de orice execuție
O poartă de politică este evaluată în șapte momente care pot bloca — înainte de crearea unei instalări, înainte de încărcarea unui widget, înainte de deschiderea unei sesiuni, înainte de deschiderea unui fir de discuție, înainte de rularea unui instrument, înainte de revocarea unei legături și înainte de dezinstalare — într-o ordine declarată și cu blocare implicită la eroare. Un apel blocat primește un singur răspuns canonic, care spune ce l-ar debloca, astfel încât o plată, un acord sau o verificare suplimentară pot fi făcute, iar apelul reluat. Porțile sunt ele însele pachete instalabile: platforma verifică dacă o poartă respectă contractul cerut, nu cine a scris-o.
Patru căi de integrare, alese după cine deține ce
Catalog integrat, widget găzduit, numai API sau execuție pe infrastructura dezvoltatorului. Pot coexista, iar alegerea ține de cine vrea să dețină ce, nu de preferința de tehnologie. Prima cale recomandată este intenționat cea mai mică: integratorul își păstrează propria aplicație, identitatea vizuală și autentificarea și construiește o pagină de lansare plus un singur punct de inițializare, în timp ce apelurile către poartă, rutele de plată și de politică și gestionarea credențialelor rămân de partea platformei.
Urma execuției
O cerere este verificată față de schema de intrare declarată de instrument, păstrată cu conținutul criptat cu o cheie care se rotește, trimisă executorului printr-un apel semnat și ținută ca o cronologie la care se poate doar adăuga, cu artefacte și un rezultat care poate fi recuperat. Pentru acțiunile cu miză mare, persoana semnează ea însăși acțiunea, cu o passkey sau cu o cheie de dispozitiv, iar dezvoltatorul trebuie să verifice el însuși acea semnătură, nu să se bazeze pe confirmarea porții.
Cum funcționează
Organizația este granița de autoritate
Utilizatorii, politicile și ce poate intra în catalog sunt limitate la o singură organizație. O organizație poate adăuga oricând constrângeri; un dezvoltator nu poate scoate niciodată constrângerile puse de ea. API-ul privat al organizației nu este predat niciodată unui furnizor extern — un instrument ajunge la el doar printr-un proxy cu drepturi verificate, așa că furnizorul nu ține niciodată acele chei. Identitățile nu sunt unite între organizații după adresa de e-mail, iar cheia dintre servere este, intenționat, inutilizabilă din browser.
Ce refuză să facă
Browserul nu este niciodată o autoritate: o pagină de plată se poate baza doar pe identificatorul sesiunii, nu pe o sumă, nu pe o monedă, nu pe o adresă de retur luată din parametrii din URL, iar dovada nu se semnează niciodată în codul din pagină. Furnizorii adaptează transportul, nu înțelesul: un adaptor trebuie să traducă rezultatul în vocabularul platformei, iar o eroare necunoscută de la furnizor blochează. Un widget care doar citește nu face pe tăcute o acțiune în numele cuiva; arată o stare goală și așteaptă să i se ceară.
Un registru onest al ceea ce este real
Proiectul își ține propriul tabel cu ce funcționează azi, ce este parțial și ce este doar specificat, iar brief-ul acesta îl respectă. Stratul de compunere rulează, dar nucleul de orchestrare pe care îl descriu specificațiile nu este încă realizat: manifestele rămân sursa de autoritate, nu nucleul. Stratul de guvernanță este o schiță, nu o implementare. Calea de facturare electronică pentru România construiește, validează și trimite facturi prin propriul client către autoritatea fiscală, cu tot ciclul de stare și mesaje, dar nu a fost niciodată validată pe un cont fiscal real, de producție. Există adaptoare pentru trei furnizori de plăți și niciunul nu a încasat banii nimănui. Sistemul este verificat de propria baterie de teste, nu încă printr-o rulare reală, cap la cap.