Protokół Komunikacji - koperta wiadomości

Komunikacja

Orkiestrator komunikuje się z agentami za pomocą określonych struktur json

Każda wiadomość to jeden obiekt JSON o stałym zestawie 11 pól. Koperta jest wspólna dla wszystkich typów; zmienia się tylko zawartość `payload`. Zawartość jest standardowa dla wszystkich kroków i całej komunikacji, różnica jest w paylodz-ie

Ogólna struktura wiadomości

Wartości są przykładowe

{

  "msg_id": "numer wiadomości",

  "corr_id": "numer wiadomości powiązanej",

  "type": "request | dispatch | response | event",

  "from": "nadawca wiadomości",

  "to": "odbiorca wiadomości",

  "action": "akcje do wykonania",

  "status": "blocked | in_progress | done | failed | needs_user",

  "requires_user_ack": true,

  "user_message": "Tekst zmiany, szczegóły komunikatu.",

  "payload": { },

  "timestamp": "<data i godzina>"

}

Opis pól:

• msg_id - identyfikator wiadomości składa się z przedrostka określającego skąd pochodzi np orc - orkiestrator, potem jest liczba 001 itd..
•  `orc-NNN` — wiadomości orkiestratora (`orc-014`, `orc-022`),
•  `e2-k1-007` — etap 2, krok refaktoru 1, numer kolejny
•  `e1s1-i2-done` / `e1s2-i2-done` — etap1.step1 / step2, iteracja 2, `step.done`.

• corr_id - identyfiaktor korelacji, czyli na którą wiadomość odpowiada,
• type - typ wiadomości (stosowane request i event):
• request - etap/krok -> orkiestrator - etap czegoś potrzebuje
• dispatch - orkiestrator -> krok - polecenie z orkiestratora
• response - etap/krok -> orkiestrator - odpowiedz na dispatch
• event - etap/krok -> orkiestrator - polecenie np stage.start, step.stop
• from - nadawca
• to - odbiorca
• action  - etap/krok -> orkiestrator:
• test.update - istniejący test wymaga aktualizacji
• test.add - trzeba dodać nowy test
• test.remove - usunąć test
• test.mock.enable - włącz obsługę mockow,
• test.mock.add - trzeba dodać mock/stub
• user.input - potrzebna infromacja od użytkownika,
• user.approval - plan gotowy,
• stage.done - etap zakończony, orkiestrator sprawdza bramę
• step.done - krok zakończony
• stage.aborted - użytkownik przerwał
• error.critical - sytuacja blokująca

Akcje test. są wysyłane do etapu 1 bo tylko etap 1. Etap 1 krok 1 przygotowanie testu krok 2 implementacja testu.

• status - stan nadawcy w chwili wysłania
• blocekd - nadawca stoi i czeka na obsłużenie requestu
• in_progress - praca trwa
• done - zkończenie z powodzeniem
• failed - wykonanie nie powiodło się
• neeed_user - do zakończenie potrzebna ingerencja użytkownika
• requires_user_ack - czy pokazać użytkownikowi
• true - 
• false
• user_message - tekst dla użytkownika - nie może być pusty gdy user_ack = true,
• payload - treść merytoryczna, wartość zależy od action
• timestamp - znacznik czasu dla wiadomości

Podsumowanie

Wygląd koperty wiadomości jest dla wersji 0.2.2, w kolejnych wersjach mogą zajść drobne zmiany

Ten tryb sprawdza się w testach, jako całość zostanie. To jest ewolucja tego co jest w wersji 0.1.0.

Budowa tego protokołu komunikacji polegała na podawaniu LLM-owi ogólnego przebiegu komunikacji, zachowania i informacji jakie będę potrzebne na poszczególnych etapach procesu. Model na podstawie moich instrukcji stworzył powyższy model komunikacji, który został przetestowany już kilkukrotnie na wersji 0.1.0.

Do repozytorium dodany jest plik z dokładnym opisem pól oraz miejsc gdzie były wzmianki na temat sposobu komunikacji.

Ten post zapoczątkuje serie opisującą szczegóły rozwiązania, przy okazji będzie to też dokumentacja dla mnie. Przez ostatni czas narobiło się sporo zmian, czas sobie przypomnieć szczegóły, bo zaczynają mi umykać.

Dokument protokołu komunikacji