homelab-codex-ws/kb/decisions/backlog-rozjazdy-repo-rzeczywistosc.md
oskar 4658089e21 fix(kb): przepiecie wszystkich odwolan wewnetrznych po migracji
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>
2026-08-04 16:58:46 +02:00

4.8 KiB

okf type visibility status updated links
0.1 decision private active 2026-08-03
../phases/backlog.md

Rozjazdy repo<->rzeczywistosc (z inwentaryzacji 2026-06-30)

Zrodlo: kb/subsystems/fleet-inventory.md (23 rozjazdy, pelna tabela tam). Weryfikacja 2026-07-02: kb/subsystems/fleet-inventory-verify.md — bilans: 20 wciaz aktualnych, 2 zmienione, 1 wyjasniony (storage SOLARIA = partycja Windows dual-boot, NIE rozjazd — zdjety z listy). Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka.

Grupa A — czyste docs, zero ryzyka

  • ZROBIONE (2026-07-02, commit 886bc85) — forgejo service.yaml owner_node: saturn -> piha (biega na PIHA always-on)
  • ZROBIONE (2026-07-02, commit 886bc85) — mosquitto service.yaml owner_node: piha -> vps (biega na VPS, nie na PIHA)
  • capabilities SATURN: RAM 8 -> 14GiB; dysk sd-card 64GB -> /dev/sda 159GB
  • capabilities SOLARIA: CPU 24 -> 32 nproc
  • hosts/saturn/services.yaml nie istnieje — 5 kontenerow bez deklaracji
  • hosts/vps/services.yaml niekompletne (4 z 9 z topology); solaria tez (brak planner-agent)

Grupa B — wymaga decyzji

  • npm x2: PIHA (LAN ingress :80/:443) + VPS (public). Repo zna jedna (owner=vps). Decyzja: zostawic oba (intentional, wildcard cert via NPM@PIHA) czy usunac PIHA? Jesli oba zamierzone -> dodac piha do service.yaml + hosts/piha.
  • ZROBIONE (2026-07-02) — control-plane na SATURN: docker compose down (wolumeny zachowane). Supervisor byl SLEPY (brak mountu repo, WARNING loop "Hosts directory /repo/hosts does not exist" co 30s) — zero ryzyka zdublowanych remediacji przez te 3 dni. Jedyny control-plane = produkcyjny na VPS.
  • ollama: service.yaml owner=solaria ale NIE biega. Wdrozyc czy wyrzucic z repo?

Grupa C — sprzatanie

  • control-plane-ui healthcheck: uzywa curl ktorego NIE MA w obrazie -> failuje w kolko -> UNHEALTHY + log spam (4.2G syslog na SATURN). Fix: wget/nc w healthcheck albo curl w Dockerfile. (Przyczyna rozjazdu #6 znaleziona przy gaszeniu dysku.)
  • homeassistant5 na PIHA (HA "ken" :8123) niedeklarowany -> dodac do hosts/piha + topology
  • VPS: outline-postgres-1 anonimowy image (4e6e670bb069) -> named tag; humanai-landing/mailer/umami do repo. joplin-db postgres:18 -> 17/16 (ocena zdezaktualizowana 2026-07-02: PG18 GA od 09/2025, nie pre-release — bez akcji)
  • PIHA: 33 shadow kontenery poza GitOps (immich, vaultwarden, wikijs, actual, audiobookshelf, elasticsearch, grafana, prom, portainer, code-server, diskover...) -> audyt + stopniowo do hosts/piha/services.yaml
  • zigbee2mqtt topology mowi chelsty-infra, biega na PIHA -> poprawic topology
  • stability-agent / node_exporter owner_node single, biegaja wielomiejscowo -> per-host

Followupy z weryfikacji + rozbrajania min (2026-07-02)

Zrodlo: kb/subsystems/fleet-inventory-verify.md + sesja 2026-07-02. Zgloszone przy fixie owner_node (886bc85), swiadomie NIE ruszone — osobne decyzje.

  • forgejo brak wpisu w hosts/piha/services.yaml; mosquitto brak w hosts/vps/services.yaml — schemat hostowy wymaga role/exposure/depends_on (miny #2/#3/#16 z audytu).
  • mosquitto na VPS bez mem_limit override w hosts/vps/runtime/ — narusza konwencje CLAUDE.md (kazdy serwis VPS deklaruje mem_limit).
  • drugi mosquitto na chelsty-infra (offline'owa instancja) — pojedyncze owner_node jej nie opisuje; wzorzec per-host jak stability-agent / node_exporter (miny #17/#18).
  • topology.yaml:75: mosquitto zadeklarowany tez jako komponent ai-cluster — rozstrzygnac, czyj jest broker :1883.
  • pi-watchtower-1 na LUSTRO w restart-loopie (nowe z reconu; node-agent healthy).
  • alias lustro nie rezolwuje z SOLARII (nowe z reconu).
  • fleet-prometheus bez formalnego override mem_limit w hosts/vps/runtime/ — limit siedzi w bazowym compose (kosmetyka).

Po odchudzaniu PIHA (2026-07-02, faza 2 modulu 0)

  • llm-gateway: zlokalizowac/zarchiwizowac zrodlo — kod (wlasny FastAPI router -> Ollama@SOLARIA) moze zyc TYLKO w /opt/llm-gateway na PIHA, bez gita; przeszukanie PIHA i repo nie znalazlo innej kopii. Zarchiwizowac do repo/Forgejo zanim padnie nosnik.
  • Prometheus@PIHA: target llm-gateway blednie nazwany watchtower — celuje w :8080 i odpytuje /v1/metrics, dostaje wieczne 404 (llm-gateway nie serwuje metryk). Naprawic nazwe/endpoint albo usunac target.

Tech debt SATURN (z gaszenia dysku 2026-06-30)

  • /opt/anaconda3 16G — najwiekszy pojedynczy zjadacz dysku (env-y Pythona). Decyzja Oskara kiedy/czy czyscic.
  • Dysk 91% -> 83% ugaszone (docker prune + journal + syslog), ale /home zaszyfrowany i ciasny strukturalnie. SATURN dzwiga dev + drugi control-plane + agent-webui — napiecie.