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>
1.4 KiB
| okf | type | visibility | status | updated | links | ||
|---|---|---|---|---|---|---|---|
| 0.1 | decision | private | active | 2026-08-04 |
|
M1 aktywna na SOLARII — cleanup node-agenta wyłączony do czasu R1 (2026-08-04)
Data: 2026-08-04
Źródło: kb/incidents/2026-07-30-ollama-solaria-vanish.md (§7, M1).
Stan: w hosts/solaria/runtime/node-agent/docker-compose.override.yml ustawiono
NODE_TYPE=lte_node (było ai_node) na czas backfillu embed (faza mailowa KB).
lte_node powoduje wczesny return w run_safe_cleanup(), więc na SOLARII nie działa
niefiltrowany docker container prune kasujący zatrzymane kontenery w ≤60 s —
łącznie z tymi, które mają restart: unless-stopped i zostały zatrzymane świadomie.
self.node_type jest czytane wyłącznie w run_safe_cleanup() i dwóch liniach logu,
więc monitoring, eventy i dispatch akcji działają bez zmian.
Skutek uboczny: lte_node pomija CAŁY cleanup — na czas mitygacji nie są sprzątane
dangling images ani build cache. Pilnować miejsca na dysku SOLARII.
Nie zdeployowane — zmiana jest tylko w repo (branch task/m1-prune-mitigation);
wchodzi przy najbliższym redeployu node-agenta na SOLARII.
Zdjąć po: wdrożeniu R1 (filtrowanie prune po restart policy / labelu compose) na tym
nodzie — wtedy przywrócić NODE_TYPE=ai_node. R1–R3 w toku po stronie subsystemu A.