126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.2 KiB
2.2 KiB
| okf | type | visibility | status | updated | links |
|---|---|---|---|---|---|
| 0.1 | decision | public | active | 2026-07-30 |
ai-cluster — LEGACY, wygaszany (decyzja 2026-07-28)
Decyzja
Stack ai-cluster działający na vps (ai-cluster-openclaw-1, codex-worker,
planner-worker, service-ops-worker, redis, mosquitto) jest wygaszany,
nie migrowany. Podstawa (recon
RECON-multiagent-2026-07-27.md, C9):
bus codex/* jest martwy od 2026-06-09 — zero nowych połączeń przez ~7 tygodni,
workery trzymają tylko puste długożyjące połączenia.
Konsekwencje:
- Migracja na solarię NIE wchodzi. Branch
task/ai-cluster-solaria(@b124e54) zostaje niezmergowany — pełni rolę dokumentacji stanu prac i reconu; nie kasować. - ai-cluster nie ma katalogu w
services/na masterze i nie dostanie go — nie wciągamy legacy do GitOps. planner-agentna solarii (ta sama rodzina) ma whosts/solaria/services.yamlmonitor: false— decyzja o jego losie osobno.- Kontenery na vps zostaną zatrzymane w osobnej, nadzorowanej sesji
(stop stacka, obserwacja
free -m, rollback = start) — poza tym taskiem; do tego czasu działają dalej pod hard mem_limitami.
Co przeżywa w subsystemie B (wzorce, nie kod)
Subsystem B (dyspozytor + KB + HA + homelab-ops; osobny projekt) dziedziczy z ai-clustra wzorce projektowe:
- bus zadań z routingiem po polu
target(role:*/AGENT_ID) i wąskim ACL, - podział na wyspecjalizowane workery-role (dev / planner / service-ops),
- allowlisty kształtu komend przed wykonaniem czegokolwiek na hoście — z lekcją
z reconu (A2): allowlist musi być egzekwowana i celowana (martwa stała
SERVICE_NAMES+ substring-match podocker psto antywzorzec), - tryb preview/diagnose przed wykonaniem,
- frontend telegramowy jako kanał operatorski (wzorzec żyje dalej w agent-system/telegram-bot na piha — ten zostaje).
Kod ai-clustra nie jest przenoszony.
Czego NIE robić
- Nie deployować, nie restartować i nie "naprawiać" stacka ai-cluster na vps.
- Nie mergować
task/ai-cluster-solaria. - Nie podpinać nowych klientów pod
codex/*na brokerze ai-clustra.