Read-only recon pod fazę 5. Ustala że architektura jest już w dużej mierze
zatwierdzona (kb-m5-faza3.md §8, 2026-07-15/17) i że blokada "pełna wiki po
fazie mailowej" jest dziś zdjęta (korpus sięga 2026-08-26 po naprawie
incydentu 20-dni-ciszy). Dociąga trzy luki nieadresowane w tamtym szkicu:
fallback chunk-id→envelope_id przy re-chunkingu, inwariant 7 (rozdział
retrievalu kompilacji od retrievalu zapytań, mitygacja self-citation) i
sekcję "niepewne/sprzeczne". Lista 17 encji zalążkowych z SELECT-ów na
żywym korpusie (top nadawcy/domeny wśród zaembedowanych kopert, streszczenia
paperless). Plan iteracji: Etap 1 = 3 strony proof (1 sesja), Etap 2 = lint
+ skala do 17. Decyzje operatora (a)-(h).
Co: kb/audits/wiki-kompilat-recon-2026-08-26.md
Co nie: implementacja — nic zdeployowane ani skommitowane poza tym dokumentem.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AWrHr2z1tGhFrGUvPSx2vU
Read-only recon (kb/audits/mail-sync-2026-08-06.md, OKF type: audit).
Stan wyjsciowy zmierzony na zywo: korpus gmail urywa sie 2026-06-19, dziura
48 dni ~ 1800 maili przy tempie ~37/dobe; zero kodu IMAP/JMAP w repo (tylko
dokumenty), brak modelu stanu synca — w bazie 3 tabele, zadnej z UID.
Ustalenia blokujace, ktore latwo przeoczyc (kazde zawodzi cicho, bez bledu):
- koperty bez entities[type=headers] daja prefiks chunka "(brak tematu) | ?"
(build_prefix), wiec poller musi pisac headers przy INSERCIE, nie backfillem
- DEFAULT_SUMMARYLESS_SOURCES = ("gmail",) — fastmail zembeduje sie i zniknie
z /search, bo galaz summaryless filtruje po source
- etap mailowy dopiety do kb-ingest.timer (03:30) zapali KbEmbedBacklogGrowing
na stale: SOLARIA wtedy spi (potwierdzone: kb_ingest_embed_skipped 1)
- envelope.id = goly Message-ID globalnie, wiec mail obecny na obu kontach
trafia do bazy raz, z source konta ktore wygralo wyscig
Architektura: fetch na PIHA co godzine (24/7, archiwum kanoniczne, bez GPU),
indeksowanie osobno bramkowane probe'em Ollamy (embed z PIHA zmierzony:
HTTP 200 w 8 ms, ~60 chunkow/dobe — rsync na SOLARIE zbedny). Spoiwem jest
kolejka "koperty bez chunkow", nie --since (ts to naglowek nadawcy).
Decyzje operatora (a)-(g) z rekomendacjami. Dwie korekty zalozen:
- POSTGRES_PASSWORD NIE lezy plaintextem w repo — service.yaml wymienia tylko
nazwy zmiennych, env.example ma placeholdery, skan sledzonych YAML: 0 trafien.
Rekomendacja uzywa istniejacego /opt/homelab/kb/.env (root:root 600,
czytany przez systemd przed zrzuceniem uprawnien)
- Fastmail przez IMAP, nie JMAP — domyka otwarta od czerwca decyzje
"unifikacja adaptera" (kb-mail-pillar.md §9); wymaga korekty §2/§7 tamtego
dokumentu po zatwierdzeniu
Zaleznosci z reconem multiagentowym: zadnych blokujacych. Dyspozytor to
subsystem B (osobny projekt); jawna zaleznosc to wiki-kompilat
(kb-m5-faza3.md:620 — "pelna wiki po przyrostowce").
Aktualizacja kb-m5-faza-mailowa.md: Krok 7 = WYKONANE + wskaznik do reconu.
Nic nie zaimplementowano, nie zdeployowano ani nie pobrano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Recon read-only zlecony pod teze "executor odpala deploy-node.sh z argumentami,
ktore skrypt ignoruje, na sciezce nieistniejacej w kontenerze". Teza byla
prawdziwa dla mastera do 2026-08-03; dzis nie jest. 79bfe8c + da151fc zastapily
to dispatchem do jobs/deploy-runner/ (systemd na hoscie wezla).
Realny stan: luka deployowa w trzech miejscach naraz — kontener executora
zbudowany 2026-07-22 (wciaz stary kod), /opt/homelab/actions/deploy/ nie istnieje
na VPS, deploy-runner nie jest zainstalowany na zadnym wezle. Zero akcji
kiedykolwiek osiagnelo stan terminalny (completed 0 / failed 0); jedyne dwa
action_result to reczne testy z 2026-07-23, nie remediacje z incydentu.
Zweryfikowane wzgledem fbf165f: healthcheck_failed idzie do container_restart,
nie do redeploy. Zywe incydenty w world state maja wylacznie trigger_type
containers_not_running / healthcheck_failed — czyli zaden nie generuje redeployu;
dzialaja tylko dryfy missing_service (2 pending).
Najostrzejszy problem projektowy: jedyny zywy emiter service_unhealthy
(node_agent.py:1104-1115) ma zahardkodowane service="control-plane", a
control-plane ma wlasne deploy-local.sh — deploy-service.sh:93-96 konczy sie
exit 3, wiec runner odmowi. Po wdrozeniu fixu redeploy sterowany incydentem
nadal nie wykona sie ani razu.
Ubocznie: w obrazie executora nie ma binarki ssh, wiec disk_cleanup
(executor.py:392-400) jest martwy tym samym defektem. Osobny task.
Dokument konczy sie sekcja FIX SHAPE — pieciopunktowa lista decyzji do podjecia,
bez rekomendacji.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
czujniki-2026-07-30 (node-agent vs stability-agent)
lustro-shipping-2026-07-16 (event=dead prom=up, 1507 mismatchy)
prometheus-cutover-2026-07-06 (recon starego toru livenesci)
piha-slim-2026-07-02 (audyt odchudzania PIHA)
vps-stacki-2026-07-27 (audyt niezarzadzanych stackow na VPS)
ODSTEPSTWO OD RECONU — swiadome. Recon typowal te 5 plikow jako SPLIT
(audit+decision / audit+incident / audit+phase). Rozstrzygniecie 2 wprowadza
typ `audit` z polem as_of i mapuje kazdy z nich na JEDNA sciezke
kb/audits/<obszar>-<data>.md. Audyt jest spojna migawka stanu z konkretna
data — rozbicie go na "ustalenia" i "rekomendacje" rozerwaloby ten kontekst
i wymagaloby redakcji tresci, czego etap 2 zabrania. Zostaja w calosci.
Efekt: 29 SPLIT-ow z reconu realizowane jako 24 (10 service+runbook,
14 wielotypowych), 5 zamienionych na caloscowe dokumenty type: audit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nowy typ `audit` (rozstrzygniecie 2) — migawka stanu z pola `as_of`,
nie opis stanu biezacego.
monitoring-coverage-2026-07-14, ha-automatyzacje-2026-07-23.
Pozostale 5 audytow/reconow jest wielotypowych — wychodza w grupie SPLIT-ow.
git mv + frontmatter, tresc nietknieta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
