feat(ansible): build agave-validator from source

doc/etap-001-doc-rpc-sol-ansible.md

@@ -4,7 +4,7 @@ Cel etapu: uruchomić pierwszy, bezpieczny playbook Ansible dla hosta RPC (`mevn
 
 ## Zakres
 
-1. Sprawdzić i zainstalować Ansible na VPS (control node), jeśli brak.
+1. Uruchamiać Ansible na VPS jako runner w Dockerze (bez instalacji Ansible na hoście), jeśli to jest preferowany model operacyjny.
 2. Dodać minimalną strukturę Ansible w `trade-iac`:
    - inventory dla `mevnode`,
    - minimalny playbook testowy (bez zmian destrukcyjnych).
@@ -18,6 +18,20 @@ Cel etapu: uruchomić pierwszy, bezpieczny playbook Ansible dla hosta RPC (`mevn
 
 ## Kryteria akceptacji
 
-- `ansible-playbook --version` działa na VPS.
+- `ansible-playbook --version` działa w kontenerze na VPS.
 - Playbook kończy się statusem success dla grupy `sol_rpc`.
 - Wynik zawiera podstawowe fakty hosta i potwierdzenie łączności Ansible.
+
+## Jak uruchomić na VPS (Docker)
+
+Przykład (image: `quay.io/ansible/ansible-runner:latest`):
+
+```bash
+cd /opt/trade-iac
+docker run --rm -t \
+  -v "$PWD/ansible:/ansible" \
+  -v "$HOME/.ssh:/home/runner/.ssh:ro" \
+  -w /ansible \
+  quay.io/ansible/ansible-runner:latest \
+  ansible-playbook -i inventory/hosts.ini playbooks/doc-rpc-sol-min.yml
+```

doc/etap-006-agave-install-identity-start.md

@@ -17,6 +17,7 @@ Cel etapu: domknąć bootstrap uruchomienia `solana-rpc` jako `solana` przez:
 
 - Bootstrap używa domyślnego bind `127.0.0.1` (bez publicznej ekspozycji RPC).
 - Produkcyjny bind na WG IP i hardening sieciowy będzie osobnym etapem.
+- Release tar z `agave-install` nie zawiera `agave-validator`, więc `agave-validator` budujemy ze źródeł (tag `v2.x`) i instalujemy do `/opt/solana/bin`.
 
 ## Kryteria akceptacji
 

doc/workflow.md

@@ -0,0 +1,67 @@
+# Workflow `trade-iac`
+
+Cel: utrzymywać konfigurację IaC w Git i wdrażać ją kontrolowanie na `mevnode`.
+
+## 1. Dodanie klucza SSH na hoście (operator)
+
+Host operatora musi mieć klucz do dostępu do repo `trade/trade-iac`.
+
+Przykład:
+
+```bash
+ssh-keygen -t ed25519 -C "trade-iac-host" -f ~/.ssh/trade_iac
+cat ~/.ssh/trade_iac.pub
+```
+
+Publiczny klucz dodajemy w Gitei (`Settings -> SSH Keys`), a potem test:
+
+```bash
+ssh -T git@gitea.mpabi.pl
+```
+
+## 2. Dodanie klucza SSH na VPS
+
+VPS (runner/deployer) musi mieć osobny klucz do klonowania/pull z `trade/trade-iac`.
+
+Przykład:
+
+```bash
+ssh-keygen -t ed25519 -C "trade-iac-vps" -f ~/.ssh/trade_iac
+cat ~/.ssh/trade_iac.pub
+ssh -T git@gitea.mpabi.pl
+```
+
+Ten publiczny klucz też dodajemy do Gitei.
+
+## 3. Wdrożenie na `mevnode` (runner na VPS)
+
+Po zmianach w repo:
+
+1. `doc/` (opis etapu),
+2. implementacja (playbook/vars),
+3. test/syntax-check,
+4. commit + push,
+5. wdrożenie z VPS na `mevnode`,
+6. testy powdrożeniowe.
+
+Minimalny przepływ:
+
+```bash
+# VPS
+git -C /opt/trade-iac pull --ff-only origin main
+cd /opt/trade-iac
+
+# uruchom Ansible w kontenerze (bez instalacji Ansible na hoście)
+docker run --rm -t \
+  -v "$PWD/ansible:/ansible" \
+  -v "$HOME/.ssh:/home/runner/.ssh:ro" \
+  -w /ansible \
+  quay.io/ansible/ansible-runner:latest \
+  ansible-playbook -i inventory/hosts.ini playbooks/doc-rpc-sol-min.yml
+```
+
+## Zasada pracy
+
+- Zmiany zawsze przez PR/commit (bez ręcznych zmian na `mevnode` poza awarią).
+- `mevnode` traktujemy jako target deploymentu, nie źródło prawdy.
+- Źródłem prawdy jest repo `trade/trade-iac`.