Un mesaj intră pe o ușă, iese cu un verdict

NexusFabric primește un mesaj pe una din patru uși — HTTP, coadă, orar sau gRPC — îl trece prin aceeași poartă de acces și prin fluxul declarat într-un fișier, apoi lasă exact un verdict în jurnal.

Jurnalul L1: livrări filtrabile pe tenant, flux, nivel și verdict, fiecare rând extensibil la câmpurile complete. — Jurnalul unei instalații care rulează. Datele sunt ale tenantului de vitrină Meridian Logistics (showcase).

Patru uși, o singură poartă

Cerere sincronă
HTTP, pe ruta de rulare. Mesajul rulează imediat, iar apelantul primește ieșirea fluxului neîmpachetată, cu statusul pe care fluxul îl declară.
Predare în coadă
HTTP, pe ruta de predare. Mesajul se scrie într-un jurnal pe disc, apelantul primește 202, iar un lucrător îl ia de acolo, cu reîncercări și coadă de mesaje moarte.
Orar
Un flux poate purta un orar cu șase câmpuri. Un tic lasă în jurnal aceeași pereche primire plus verdict ca o cerere, pe canalul cron.
Ușa gRPC
Un port separat rutează apelul către flux prin aceeași poartă de acces și aceeași paranteză de livrare ca ușa HTTP.

Poarta e închisă implicit și rulează înaintea corpului: un apelant nelegitimat nu provoacă nicio citire de corp și nicio parsare. Pe ce ușă a intrat livrarea se citește dintr-o coloană a jurnalului, nu din felul evenimentului.

Cum călătorește un mesaj

Poarta decide înaintea corpului
Cererea trece prin poartă înainte ca vreun octet de corp să fie citit. Un apelant fără cheie primește 401 și nu află nici dacă fluxul există, nici cât corp ar fi avut voie să trimită.
Plafonul se rezolvă, apoi corpul se citește până la el
Plafonul unui mesaj se rezolvă per punct de acces, din trei straturi: instalația, fluxul, pasul de egress. Un corp care îl depășește primește 413 și lasă un eveniment fault în jurnal.
Executor::deliver e singura paranteză
Toate cele patru uși intră prin aceeași paranteză de livrare. Dedupul pe cheie, corelarea cerere-răspuns și memoizarea răspunsului nu au cod propriu pe nicio ușă.
Pașii rulează în ordine
Un gard validate refuză la prima regulă falsă, un route alege o ramură și converge după ultima ramură a gardului, o fență ntd produce documentul următor. O eroare netratată intră în secțiunea ## Fault:, dacă fluxul are una.
Exact un verdict
O livrare lasă în jurnal o primire și exact un verdict: completed, fault sau delivery_refused. Nuanța stă pe rubrica outcome de lângă el — succeeded, fault_handled sau failed.
Jurnalul spune pe ce ușă a intrat
Canalul e o coloană, nu un fel de eveniment: http, grpc, queue sau cron. Un tic de orar lasă aceeași pereche primire plus verdict ca o cerere sincronă.

Poarta e prima, plafonul al doilea. De aceea un apelant fără cheie care anunță un corp peste plafon primește 401, nu 413: plafonul e stare internă a instalației și nu se divulgă înainte de autentificare.

Citește diagrama ca text

Apelantul trimite cererea către o rută de flux.
Poarta de acces decide prima, și e închisă implicit. Fără credențială valabilă cererea se oprește aici, cu 401 sau 403, și lasă un eveniment access_denied.
Plafonul mesajului se rezolvă, apoi corpul se citește până la el. Un corp peste plafon se oprește cu 413 și nu ajunge la niciun pas.
Executor::deliver e paranteza prin care intră toate cele patru uși. Dedupul și corelarea se decid aici.
Pașii fluxului rulează în ordine.
Livrarea se încheie cu un verdict, unul singur: completed, fault sau delivery_refused.
Un refuz al porții sau al plafonului merge direct în jurnal, fără să atingă pașii.
Jurnalul L1 înregistrează primirea, verdictul, canalul pe care a intrat livrarea și rubrica outcome.

Fișierul pe care îl scrii

Un flux e un fișier Markdown: un antet care spune cui aparține și ce efecte are voie să folosească, apoi pași. Gardurile, transformările și răspunsul se scriu în fențe, fiecare cu limbajul ei. Mai jos, două fențe dintr-un flux real din corpusul de conformitate: un gard care refuză explicit, la prima regulă falsă, și un pas care își declară statusul răspunsului.

tests/battery/corpus/meridian/01-shipment-intake.flow.md — pasul de ieșire dintre cele două fențe, liniile 34-40, e lăsat afară: poartă un endpoint pe care bateria îl substituie la rulare.

## Step: check-booking
```validate
$.shipmentId != null    | "shipmentId is required"                    | syntactic
$.hubCode != null       | "hubCode is required"                       | syntactic
$.parcelCount > 0       | "parcelCount must be greater than zero"
$.weightKg > 0          | "weightKg must be greater than zero"
```

…

## Step: acknowledge
response_status: 202
```ntd
{
  "status": "ACCEPTED",
  "shipmentId": "{{ $.echo.shipmentId }}",
  "waybill": "{{ $.echo.waybill }}",
  "hubCode": "{{ $.echo.hubCode }}",
  "parcelCount": {{ $.echo.parcelCount }}
}
```

Limbajul de fluxuri

Ce se numără

Cifrele de mai jos descriu forma produsului și se citesc din cod.

4uși pe care intră o livrareHTTP, coadă, orar și gRPC, toate prin aceeași poartă
10limbaje de fence într-un fișier de fluxtransformare, garduri, rutare, buclă, paralelism
23feluri de eveniment în jurnalfiecare cu un sit de emitere cerut mecanic
25câmpuri mascate întotdeaunanu se pot opri; un flux poate adăuga la listă
16variante de eroare într-o singură mapareun match exhaustiv, fără braț implicit

Ce refuză să facă

Limitele stau aici, lângă capacități, ca un caz nepotrivit să se poată exclude din prima pagină.

Coada livrează cel puțin o dată. Platforma nu promite exactly-once la ușă; ce oferă e deduplicare declarativă pe o cheie scrisă în flux.
Nu exportă metrici. Ce s-a întâmplat se citește din jurnalul de livrări și din interfața de administrare, nu dintr-un sistem de monitorizare.
Nu cifrează la repaus. Bazele de date și fișierele de coadă se cifrează la nivelul discului sau al volumului, nu de către platformă.
Ușa gRPC servește metode unare. O metodă de flux primește un refuz explicit, nu o degradare tăcută.
Tabela de rutare gRPC se construiește la pornire. Un flux publicat după aceea se rutează la următoarea repornire.
Configurarea de mediu se capturează la pornire. O schimbare de configurare cere repornire, ca verificarea de la pornire să fi acoperit exact valorile pe care rulează platforma.

Acoperire

Ce protocoale și ce efecte există azi în platformă, pe intrare și pe ieșire.
Protocol sau efect	Intrare	Ieșire
HTTP, JSON	sincron pe ruta de rulare, asincron pe cea de predare	apel HTTP dintr-un pas
XML	aceleași uși, cu Content-Type XML	apel HTTP, cu Content-Type XML
SOAP 1.1 și 1.2	detectat din corp; WSDL 1.1 generat pe rută proprie	plic compus pe pasul de ieșire
gRPC	ușă separată, metode unare	unar și streaming de server, cu TLS și mTLS
Orar (cron)	orar cu șase câmpuri în antetul fluxului	nu se aplică
Coadă	rută de predare, jurnal pe disc, livrare cel puțin o dată	publicare în coadă dintr-un pas
JMS, prin STOMP	conector separat, care predă pe ruta de coadă	neconstruit
Fișiere într-un director	conector separat, care predă pe ruta de coadă	neconstruit
Secrete din mediu	nu se aplică	citire de secret dintr-un pas
OAuth2 client_credentials	nu se aplică	obținere de token dintr-un pas

Platforma, pe capitole

Licențiere și versiune

Versiunea descrisă aici: 1.2.0
Licență: Comercială, proprietară. Fără descărcare publică și fără cod sursă.
Disponibilitate: Prin contract, la cerere.

Patru uși, o singură poartă

Cerere sincronă

Predare în coadă

Orar

Ușa gRPC

Cum călătorește un mesaj

Poarta decide înaintea corpului

Plafonul se rezolvă, apoi corpul se citește până la el

Executor::deliver e singura paranteză

Pașii rulează în ordine

Exact un verdict

Jurnalul spune pe ce ușă a intrat