Ce este un execution bundle și ce trebuie să conțină

Un execution bundle este contractul complet dintre o schimbare aprobată și sistemul care o execută. El nu conține doar textul nou sau un fișier de import. Leagă motivul intervenției, ținta exactă, starea inițială, diferența aprobată, precondițiile, testele, autorizația, regulile de execuție, revenirea și dovada rezultatului.

Folosesc termenul ca model editorial și operațional, nu ca nume al unui standard universal. Organizațiile îl pot implementa în JSON, YAML, tabele de bază de date, artefacte de CI/CD sau structuri proprii ale CMS-ului. Forma poate varia. Contractul nu: executorul trebuie să știe fără interpretare creativă ce modifică, unde, pe ce versiune, cu ce drept și cum demonstrează rezultatul.

În lipsa acestui pachet, aprobarea rămâne într-un comentariu, patch-ul într-un document, sursele într-un tab de browser și instrucțiunile de rollback într-o conversație. Fiecare element poate fi corect separat, dar combinația executată poate fi alta decât cea revizuită.

De la recomandare la artefact executabil

O analiză poate spune că unei pagini îi lipsește răspunsul la o întrebare importantă. O propunere poate recomanda un paragraf nou. Un editor poate aproba ideea. Niciuna dintre acestea nu este încă suficientă pentru execuție.

Artefactul executabil trebuie să elimine ambiguitatea dintre patru stări:

1. insight — problema observată și dovezile care o susțin;
2. propunere — intervenția sugerată și rezultatul așteptat;
3. decizie — autoritatea aprobă o versiune și niște limite;
4. execution bundle — pachetul verificat pe care un executor îl poate aplica exact.

Articolul despre aprobarea modificărilor automate explică cine acordă autoritatea și când aceasta expiră. Aici ne concentrăm pe obiectul concret căruia îi este acordată acea autoritate.

1. Manifestul fixează identitatea pachetului

Primul strat este un manifest scurt, citibil atât de oameni, cât și de sistem. El include cel puțin:

• un identificator unic al bundle-ului;
• versiunea schemei după care este interpretat;
• versiunea conținutului pachetului;
• data creării și mediul pentru care a fost produs;
• un hash calculat peste componentele care trebuie să rămână neschimbate;
• starea curentă: draft, validat, aprobat, executabil, executat sau verificat.

Versiunea schemei spune cum citim câmpurile. Versiunea bundle-ului spune ce ediție a schimbării avem în față. Hash-ul dovedește dacă octeții protejați s-au schimbat. Aceste trei valori nu sunt sinonime.

O identificare stabilă reduce riscul ca aprobatorul să vadă versiunea 3, iar executorul să primească versiunea 4. Detaliile de implementare pentru hash și audit trail merită tratate separat; aici este suficientă regula: orice modificare materială produce o versiune nouă și invalidează semnătura veche.

2. Intenția și dovezile explică de ce schimbăm

Executorul nu are nevoie să refacă întreaga analiză, dar pachetul trebuie să păstreze legătura cu problema inițială. Secțiunea de intenție notează:

• obiectivul intervenției în limbaj concret;
• insightul sau incidentul care a declanșat-o;
• întrebarea utilizatorului ori afirmația care trebuie clarificată;
• sursele și capturile datate folosite pentru decizie;
• rezultatul așteptat și limitele afirmației.

De exemplu, „optimizăm pagina pentru AI” nu este un obiectiv executabil. „Adăugăm un răspuns verificat la întrebarea X, fără să schimbăm promisiunea comercială sau intenția canonică a paginii” este mult mai precis.

W3C PROV oferă un vocabular general pentru relațiile dintre entități, activități și agenți. Nu este necesar să implementăm întreaga ontologie, dar principiul provenienței este util: putem urmări ce dovadă a generat propunerea, cine a validat-o și ce activitate a produs rezultatul live.

3. Țintele și baseline-ul spun exact ce atingem

O țintă nu este „site-ul” sau „articolele despre vizibilitate AI”. Pentru fiecare operație declarăm:

• domeniul, mediul și limba;
• URL-ul canonic și identificatorul intern al conținutului;
• tipul obiectului: articol, pagină, produs, taxonomie, template sau asset;
• câmpurile permise și cele interzise;
• versiunea, ETag-ul ori hash-ul stării curente;
• dependențele: imagini, legături, schema, redirecturi, cache sau feeduri.

Bundle-ul face referire la baseline-ul înghețat înaintea intervenției. Nu trebuie să copieze toate datele brute, dar trebuie să indice fără echivoc snapshotul, momentul capturii și contractul de măsurare.

Precondiția protejează munca apărută între aprobare și execuție. În HTTP, RFC 9110 descrie If-Match ca metodă de a permite o cerere de modificare numai dacă reprezentarea curentă corespunde etichetei furnizate. Nu toate CMS-urile folosesc ETag pentru editare, dar regula este transferabilă: dacă versiunea live nu mai este cea analizată, executorul se oprește.

4. Change set-ul trebuie să fie exact și ordonat

Schimbarea nu poate rămâne la nivelul „rescrie introducerea”. Bundle-ul conține operații determinate: înlocuiește valoarea câmpului, inserează blocul după un reper stabil, elimină legătura identificată sau încarcă assetul cu checksumul declarat.

RFC 6902 definește JSON Patch ca o listă ordonată de operații precum add, remove, replace, move, copy și test. Nu este obligatoriu ca un website să folosească acest format, însă oferă un exemplu bun: operațiile au ținte precise, se aplică în ordine, iar o eroare oprește evaluarea.

Pentru fiecare schimbare păstrăm valoarea de dinainte, valoarea propusă și motivul. Pentru fișiere declarăm numele, tipul MIME, dimensiunile, hash-ul, alt textul și locul de inserare. Pentru legături declarăm sursa, destinația și ancora. Pentru date structurate declarăm proprietățile afectate și relația lor cu textul vizibil.

Astfel putem afișa un diff inteligibil aprobatorului și putem compara ulterior rezultatul live cu exact aceeași intenție.

5. Riscul, raza de propagare și precondițiile sunt controale de execuție

Riscul nu trebuie ascuns într-un scor fără explicație. Bundle-ul notează ce tip de impact poate apărea și cât de departe se poate propaga:

• numărul maxim de obiecte și URL-uri afectate;
• câmpurile sensibile: preț, promisiune, legal, canonical, robots sau template;
• sistemele secundare care pot primi schimbarea prin cache, feed, email ori webhook;
• permisiunile minime necesare executorului;
• fereastra de publicare și condițiile de oprire;
• limita de timp după care aprobarea nu mai poate fi folosită.

Controlul CM-3 din NIST SP 800-53 oferă o analogie solidă: schimbările controlate sunt analizate, aprobate ori respinse cu evaluarea impactului, documentate, implementate și păstrate în evidență. Nu afirmăm că un blog trebuie să adopte un catalog federal; folosim disciplina de change control proporțional cu riscul.

6. Validarea nu este o singură bifă

Înainte de aprobare și din nou înainte de execuție, bundle-ul trece prin teste deterministe. Suita poate include:

• validarea structurii manifestului și a tipurilor de date;
• confirmarea existenței țintelor și a hash-urilor curente;
• verificarea linkurilor, imaginilor și placeholderelor;
• parsing HTML, schema și reguli de accesibilitate;
• limite de lungime și structură editorială;
• detecția operațiilor în afara scope-ului;
• simulare sau dry-run fără scriere;
• controlul duplicatelor și al idempotency key-ului.

JSON Schema poate descrie și valida structura unui document JSON. Trecerea schemei dovedește că pachetul are forma așteptată; nu dovedește că o afirmație este adevărată, că textul este bun sau că schimbarea are permisiune.

La fel, un validator de date structurate poate confirma sintaxa, dar nu relația dintre markup și conținut. Ghidul Google pentru structured data cere ca marcajul să reprezinte conținutul vizibil și să respecte politicile de calitate. Bundle-ul trebuie să includă ambele verificări când schema este modificată.

7. Aprobarea este atașată bundle-ului, nu intenției generale

Secțiunea de aprobare nu trebuie să conțină doar numele unei persoane și cuvântul „da”. Ea leagă decizia de:

• ID-ul și versiunea exactă a bundle-ului;
• hash-ul conținutului protejat;
• ținte, risc și rază de propagare;
• rezultatele testelor văzute la aprobare;
• fereastra de execuție și data expirării;
• identitatea aprobatorului sau referința politicii preaprobate;
• condițiile speciale și motivul deciziei.

Dacă se schimbă un paragraf, un asset, o sursă care alterează concluzia, lista de ținte sau o precondiție, autorizația nu se transferă automat. Se produce o nouă versiune, se repetă validarea relevantă și se cere o decizie nouă.

8. Executorul are nevoie de ordine, idempotency și limite de retry

Două execuții ale aceluiași pachet nu trebuie să creeze două articole, să insereze paragraful de două ori sau să încarce copii inutile ale imaginii. Bundle-ul include un idempotency key, identificatori stabili pentru operații și regula prin care executorul recunoaște o aplicare deja reușită.

Ordinea este la fel de importantă. Poate fi necesar să încărcăm assetul, să confirmăm URL-ul lui, să actualizăm conținutul, să setăm imaginea principală și abia apoi să invalidăm cache-ul. Fiecare pas are o condiție de succes, o limită de retry și o stare necunoscută care cere oprire și investigație.

Retry-ul este potrivit pentru o eroare tranzitorie cunoscută, nu pentru un rezultat ambiguu. Dacă API-ul a pierdut răspunsul după scriere, executorul verifică starea înainte să repete operația. Altfel, mecanismul de „reziliență” devine generator de duplicate.

9. Rollback-ul trebuie pregătit înaintea publicării

Planul de revenire identifică versiunea bună, operațiile de restaurare, sistemele secundare și testele de recuperare. Pentru o pagină WordPress poate indica revizia anterioară, dar trebuie să păstreze și valorile câmpurilor care nu intră în revizie, asseturile, metadata și efectele externe.

WordPress permite compararea și restaurarea reviziilor. Este o bază utilă pentru recuperare, nu o garanție completă. O notificare trimisă, un feed consumat sau o pagină deja indexată nu dispar fiindcă am restaurat conținutul.

NIST SSDF pune accent pe integritatea release-urilor, proveniență și răspuns la probleme. Pentru conținut aplicăm aceeași idee proporțional: știm ce versiune am livrat, o putem verifica și avem o cale controlată de recuperare.

10. Un răspuns 200 nu este dovada rezultatului

CMS-ul poate confirma că a acceptat cererea, iar pagina publică să fie încă greșită. Cache-ul poate servi versiunea veche. Un placeholder poate rămâne vizibil. Canonicalul poate indica alt URL. Imaginea poate răspunde 404. Schema poate conține valoarea nouă, iar textul vizibil pe cea veche.

Verificarea post-deploy trebuie să citească suprafața publică și să confirme cel puțin:

• statusul, URL-ul final și canonicalul;
• titlul, secțiunile și valorile modificate;
• absența placeholderelor și a duplicatelor;
• răspunsul imaginilor și destinațiile linkurilor;
• HTML-ul, datele structurate și elementele de indexare;
• randarea vizuală pe dimensiunile relevante;
• faptul că nicio țintă neautorizată nu a fost schimbată.

Dovezile rezultate — hash live, captură datată, rezultate de test și loguri — se atașează bundle-ului fără a include secrete sau date personale inutile.

11. Măsurarea începe după verificarea execuției

Un deployment corect și un impact pozitiv sunt două întrebări diferite. Bundle-ul se închide operațional când starea live corespunde versiunii aprobate. Apoi transmite către măsurare ID-ul intervenției, baseline-ul, momentul publicării, țintele și rezultatele verificării.

Protocolul pentru măsurarea impactului unei intervenții GEO compară observațiile înainte și după fără să confunde succesiunea temporală cu o cauză demonstrată. Bundle-ul oferă trasabilitatea necesară, nu produce singur concluzia.

Exemplu complet: o editare care se oprește la timp

O analiză arată că un articol în limba română nu răspunde unei întrebări importante și formulează ambiguu o afirmație factuală. Echipa pregătește bundle-ul versiunea 3 pentru un singur URL: înlocuirea unui paragraf, inserarea unei secțiuni cu surse și adăugarea a două legături interne.

Manifestul fixează hash-ul articolului live, asseturile, diff-ul și testele. Riscul este mediu deoarece se schimbă o afirmație publică. Editorul aprobă versiunea 3 pentru 24 de ore.

Înainte de execuție, un coleg corectează independent un exemplu din același articol. Hash-ul live nu mai corespunde baseline-ului. Executorul nu combină automat editările și nu suprascrie versiunea nouă. Marchează precondiția ca eșuată și oprește pachetul.

Propunerea este refăcută peste conținutul actual, devine versiunea 4, trece din nou testele și primește o aprobare nouă. După publicare, verificatorul confirmă textul, canonicalul, linkurile, imaginile și absența duplicatelor. Numai atunci intervenția este predată măsurării.

Schema minimă a unui execution bundle

Secțiune	Întrebarea la care răspunde	Conținut minim
identity	Ce versiune executăm?	ID, schema version, bundle version, hash, stare
intent	De ce intervenim?	obiectiv, insight, dovezi, rezultat așteptat
targets	Ce putem atinge?	mediu, limbă, URL/ID, câmpuri, dependențe
baseline	Care este starea inițială?	snapshot, versiune/hash, moment, contract de măsurare
changes	Ce se modifică exact?	operații ordonate, before/after, asseturi
controls	Când trebuie să ne oprim?	risc, blast radius, precondiții, validări
approval	Cine a autorizat această versiune?	decizie, versiune, hash, scope, expirare
execution	Cum aplicăm în siguranță?	ordine, idempotency, retry, stop conditions
rollback	Cum revenim?	known-good state, operații, teste de recuperare
verification	Ce a ajuns live?	asertări publice, dovezi și rezultat
provenance	Cine a făcut fiecare pas?	producător, validatori, aprobator, executor, timpi

În bundle nu punem parole, chei API, cookie-uri sau tokenuri permanente. Păstrăm numai referința la identitatea de execuție și la mecanismul aprobat prin care runtime-ul obține credențiale temporare cu permisiuni minime.

Checklist înainte ca pachetul să devină executabil

• bundle-ul are ID, versiune de schemă, versiune de conținut și hash;
• obiectivul și dovezile sunt suficiente pentru a înțelege schimbarea;
• ținta, mediul, limba și câmpurile permise sunt exacte;
• baseline-ul și precondițiile pot detecta o editare concurentă;
• change set-ul este ordonat, complet și inteligibil în diff;
• asseturile, linkurile și dependențele au identificatori stabili;
• riscul și raza maximă de propagare sunt declarate;
• validările au trecut și rezultatele sunt atașate;
• aprobarea corespunde exact versiunii și nu a expirat;
• execuția este idempotentă și are retry-uri limitate;
• rollback-ul indică o stare bună și verificări de recuperare;
• testele live sunt separate de răspunsul API;
• măsurarea primește identitatea intervenției și baseline-ul;
• proveniența este păstrată, iar secretele sunt excluse.

Un execution bundle bun nu îi cere executorului să ghicească. Îi oferă o singură versiune autorizată, limite tehnice clare și criterii observabile de succes. Când realitatea nu mai corespunde pachetului, comportamentul corect este oprirea, nu improvizația.

Sursele au fost verificate la 2 august 2026. „Execution bundle” este folosit aici ca model editorial și operațional; articolul nu afirmă existența unui standard universal sau a unei funcții AYSA deja lansate.