homelab-codex-ws/kb/phases/kb-m5-faza5-wiki.md

okf	type	visibility	status	updated	links
0.1	phase	private	active	2026-08-27	../audits/wiki-kompilat-recon-2026-08-26.md kb-m5-faza3.md kb-m5-faza-mailowa.md

Moduł 5, faza 5 — wiki-kompilat (Etap 1: bootstrap + proof, i odkrycie rozjazdu)

**Status: Etap 1 wykonany 2026-08-27 — ale w cieniu ważniejszego znaleziska: proof-of-concept wiki-kompilatu (repo kb-wiki, 5 stron) już istniał od 2026-07-21, na Forgejo (https://forgejo.kapala.org/oskar/kb-wiki), i kb/audits/wiki-kompilat-recon-2026-08-26.md tego nie wykrył. Ta sesja (2026-08-27) zbudowała niezależny, równoległy lokalny bootstrap (~/kb-wiki-etap1-sesja-2026-08-27/, 3 strony) nie wiedząc o repo z lipca — dowiedziała się dopiero przy Części C tego zadania, kiedy próba udokumentowania "remote nie istnieje" (cytat z polecenia sesji, zgodny z audytem) skłoniła do sprawdzenia Forgejo wprost. Nic nie zostało wypchnięte do prawdziwego zdalnego repo — ta sesja tylko czytała je (git clone, pull-only). Rekoncyliacja dwóch niezależnych kompilacji tej samej encji (fll-2025-26) i decyzja co dalej z lokalnym repo tej sesji — do operatora, patrz §4.

---

0. Jak doszło do odkrycia (żeby przyszła sesja nie powtórzyła tej samej luki)

kb/audits/wiki-kompilat-recon-2026-08-26.md (2026-08-26, decyzje a-h zatwierdzone 2026-08-27) stwierdza wprost w nagłówku: „Nic nie zostało zaimplementowane, zdeployowane ani skommitowane poza tym dokumentem." Dowody audytu: worktree homelab-codex-ws cięty z mastera, pilot ~/narty-2027/saalbach-kb (lokalny odczyt), żywa baza kb na PIHA (ssh piha 'docker exec kb-postgres psql...'), systemctl status na PIHA. Forgejo nie było w tym zestawie dowodów — audyt nie odpytał API/repo Forgejo, mimo że CLAUDE.md i inventory/topology.yaml jasno wskazują git_provider: forgejo jako miejsce, gdzie kb-wiki miało w ogóle powstać (decyzja D7 faza3 §8.2: „osobne repo kb-wiki", bez wskazania konkretnego hosta w chwili pisania szkicu — Forgejo to naturalna, ale niejawna implikacja).

Zlecenie tej sesji (2026-08-27, Etap 1) powtórzyło za audytem: „REMOTE NIE ISTNIEJE — nie konfiguruj, nie pushuj; operator założy repo na Forgejo później." To zdanie okazało się faktycznie nieprawdziwe — sprawdzone dopiero przy pisaniu tego dokumentu (Część C zlecenia), zapytaniem GET do http://100.108.208.3:3000/ api/v1/repos/search?q=kb-wiki (read-only, bez uwierzytelnienia, private: false więc odpowiedź jawna) i następnie git clone (pull-only, potwierdzone uprawnieniami API: "push": false, "pull": true) do katalogu tymczasowego poza tym repo.

Wniosek na przyszłość: „repo nie istnieje" w planie/audycie nie jest wystarczające bez sprawdzenia bezpośrednio w systemie, który je hostuje (inventory/topology.yaml → git_provider: forgejo → Forgejo API/git ls-remote), nie tylko w obrębie homelab-codex-ws i lokalnych klonów znanych z wcześniejszych sesji. Ten sam błąd metodologiczny mógłby się powtórzyć przy dowolnym innym „osobnym repo" planowanym w dokumentacji, ale nigdy nie zweryfikowanym wprost u hosta.

---

1. Co faktycznie istnieje w oskar/kb-wiki (Forgejo, od 2026-07-21)

Stan wg git clone https://forgejo.kapala.org/oskar/kb-wiki.git (read-only, 2026-08-27), 3 commity na master:

156925c struktura: katalogi, konwencje, README
42c7731 compile: pzu, warta, ubezpieczenie-auto-ga431ja-2026, fll-2025-26, wspolnota-mieszkaniowa-targowa-2a ← kaskada retrievalu kb-postgres@PIHA
c52f867 lint: pierwszy raport ręczny 2026-07-21

Struktura: README.md, INDEX.md (wielka litera — inaczej niż plik zarezerwowany OKF index.md, patrz §3 niżej), _meta/conventions.md, _meta/lint-reports/ lint-report-2026-07-21.md, 5 stron-encji:

Strona	Typ	Skrót
podmioty/pzu.md	podmiot	PZU — OWU Auto/OC, karty produktu, oferta T1531938417
podmioty/warta.md	podmiot	WARTA — OWU AC Standard/Komfort/Moje Auto
sprawy/ubezpieczenie-auto-ga431ja-2026.md	sprawa	Porównanie ofert PZU/WARTA/InterRisk, Mazda 6 (GA431JA), 06.2026
sprawy/fll-2025-26.md	sprawa	FLL Challenge UNEARTHED, drużyna #1100, Warszawa II
sprawy/wspolnota-mieszkaniowa-targowa-2a.md	sprawa	Wspólnota Mieszkaniowa Targowa 2A (Pruszków) — zebranie roczne 2026

osoby/, umowy/, tematy/ istnieją jako katalogi puste (.gitkeep) — zero stron typu osoba w lipcowym proof-of-concept. To jest jedyna luka pokrycia typów, którą Etap 1 tej sesji (§2) faktycznie domyka, nie duplikuje.

Jakość: wysoka, metodologicznie zgodna z tym, co audyt 08-26 dopiero rekomendował (sekcja „Niepewne/sprzeczne" jako wzorzec — tam nazwana wprost inaczej, ale ta sama funkcja; degradacja przy uszkodzonym OCR zamiast ślepego zaufania streszczeniu; 84/86 wpisów sources[].chunks i 73/73 przypisów inline zweryfikowanych wprost w bazie, udokumentowane w _meta/lint-reports/lint-report-2026-07-21.md). Pełna treść: _meta/conventions.md tamtego repo (różni się od konwencji tej sesji w kilku miejscach nieistotnych merytorycznie — casing INDEX.md/index.md, typ meta vs temat dla conventions.md — patrz §3).

kb-m5-faza4.md (linia 17, docs/sessions/2026-07-21.md) już to dokumentowały poprawnie — ten fakt był w repo homelab-codex-ws cały czas, czytelny git log/ grep -r kb-wiki. Audyt 08-26 po prostu tego nie sprawdził (§0 wyżej).

---

2. Co ta sesja (2026-08-27) faktycznie zrobiła — Etap 1 wg zlecenia, lokalnie, bez wiedzy o §1

Zbudowany od zera, niezależnie: ~/kb-wiki-etap1-sesja-2026-08-27/ (przemianowany z ~/kb-wiki/ po odkryciu §1 — żeby nie kolidować ścieżką z przyszłym git clone prawdziwego repo). Git lokalny, 6 commitów, nigdy nie pushowany do żadnego remote (żaden remote nie był skonfigurowany — zgodnie z literą pierwotnego zlecenia, które okazało się oparte na błędnym założeniu z §0).

3 strony proof, celowo zróżnicowane typy (jak żądał audyt §9 Etap 1):

Strona	Typ	Pokrycie względem §1
sprawy/fll-2025-26.md	sprawa	Duplikat tej samej encji co lipcowe repo — skompilowany niezależnie, z częściowo innym zestawem chunków (uzupełniające, nie identyczne sources). Wysoka zgodność wniosków — patrz §4.
podmioty/mbank.md	podmiot	Nowe pokrycie — nie istnieje w lipcowym repo (tam tylko PZU/WARTA, ubezpieczyciele)
osoby/pawel-cesar-sanjuan-szklarz.md	osoba	Domyka lukę — lipcowe repo ma katalog osoby/ pusty; to pierwsza strona typu osoba w całym projekcie, jedyny dotąd test entity-resolution na aliasach

Pełna treść stron, _meta/conventions.md tej sesji (napisane niezależnie od lipcowego — patrz różnice §3), check_okf.py (walidator, którego lipcowe repo nie ma jako skomitowanego pliku — tamta sesja weryfikowała sources/przypisy ad hoc, bez zostawienia narzędzia), i _meta/lint-reports/2026-08-27.md — wszystko w ~/kb-wiki-etap1-sesja-2026-08-27/, 6 commitów (git log --oneline): struktura+konwencje, walidator, 3× compile:, 1× lint:.

DoD audytu §9 Etap 1 (tabela, 4 punkty) — spełnione lokalnie, w tym repo równoległym: repo istnieje z konwencjami, walidator działa (zielono, 40 par sources + 47 inline przypisów zweryfikowanych wprost w KB_DSN), 3 strony proof spełniają inwarianty 1-2, raport lintu ręcznego zapisany.

Weryfikacja lint:

$ python3 check_okf.py     # w ~/kb-wiki-etap1-sesja-2026-08-27/
ZGODNE z OKF v0.1 (kb-wiki): [...] wszystkie 40 przypisów zweryfikowane w bazie.

scripts/kb/check_okf.py z homelab-codex-ws uruchomiony na tym samym repo — zgodnie z rozjazdem przewidzianym w zleceniu:

$ python3 scripts/kb/check_okf.py ~/kb-wiki-etap1-sesja-2026-08-27
Zakres: kb, docs/sessions
Sprawdzono plików .md: 0
BRAK plików w zakresie — nie ma czego walidować.

SCOPE = ("kb", "docs/sessions") w tamtym skrypcie jest wpisany na sztywno względem root — kb-wiki (żadna z dwóch kopii, lipcowa ani ta) nie ma podkatalogu kb/ ani docs/sessions/, więc walidator zawsze zwróci "brak plików" dla tego layoutu. Nie hackowany — to jest realny, ustrukturalny rozjazd (nie błąd w kb-wiki), odnotowany tu jako follow-up: albo scripts/kb/ check_okf.py dostaje parametr --scope, albo kb-wiki (dowolna wersja) trzyma własny walidator na stałe (rekomendacja tej sesji — już częściowo zrobione, patrz check_okf.py w repo tej sesji).

---

3. Różnice konwencji: lipiec vs ta sesja (nieistotne merytorycznie, warto ujednolicić)

Aspekt	Lipiec (oskar/kb-wiki, prawdziwe repo)	Ta sesja (lokalne)	Rekomendacja
Plik nawigacyjny root	INDEX.md (duża litera), osobny od OKF-owego index.md (nie istnieje w ogóle w lipcowym repo — brak pliku index.md)	index.md (mała litera, OKF §11 reserved-file, pełni tę samą rolę)	Do rozstrzygnięcia przez operatora — lipcowe repo nie ma pliku index.md w ogóle, więc formalnie nie przechodzi check_okf.py tej sesji (brak bloku frontmattera nie wystąpi, bo pliku nie ma, ale reguła "root index.md wymagany" by to złapała, gdyby uruchomić walidator tej sesji na lipcowym repo — nie testowane, bo nie nasze repo do modyfikacji)
type dla _meta/conventions.md	meta (dodatkowa wartość w słowniku typów)	temat (nadużycie istniejącego typu, bo TYPES tej sesji nie miało meta)	Lipcowe podejście czystsze — warto przyjąć meta jako 6. typ przy rekoncyliacji
Frontmatter sources obowiązkowe niepuste	Nie wymuszone narzędziem (ręczna dyscyplina)	Wymuszone w check_okf.py (poza _meta/)	Zachować regułę tej sesji przy rekoncyliacji — tańsze niż poleganie na dyscyplinie
Walidator jako plik w repo	Brak (weryfikacja ad hoc, nieskomitowana)	check_okf.py, skomitowany, wielokrotnego użytku	Przenieść check_okf.py tej sesji do prawdziwego repo przy rekoncyliacji
Remote skonfigurowany	Tak (Forgejo, master)	Nie (lokalny, celowo)	—

Żadna z różnic nie jest błędem — obie konwencje są spójne z faza3 §8.2 i audytem 08-26 w rzeczach, które się nakładają (format [^envelope_id#chunk_id], fallback, sekcja niepewności, CC/API-only, izolacja retrievalu kompilacji od source='wiki').

---

4. Rekoncyliacja — do operatora, nie rozstrzygane przez tę sesję

To jest decyzja o realnych, już opublikowanych danych osobowych (finanse, ubezpieczenia, dziecko na turnieju) w prawdziwym repo — powyżej progu, przy którym ta sesja podejmuje decyzje sama. Opcje, bez rekomendacji wiążącej:

1. Scalić nowe strony tej sesji do prawdziwego repo. podmioty/mbank.md i osoby/pawel-cesar-sanjuan-szklarz.md nie kolidują z niczym w lipcowym repo — czysty dodatek. sprawy/fll-2025-26.md koliduje (dwie różne kompilacje tej samej encji) — wymaga porównania treść-po-treści przez operatora albo kolejną sesję CC, nie automatycznego scalenia.
2. Porównanie dwóch niezależnych kompilacji fll-2025-26 jako test jakości kompilatora. Obie wersje (lipcowa i ta) zgadzają się merytorycznie w kluczowych punktach: wynik 195 pkt jako jedyny czytelny wprost z chunka (paperless:119#277/#278 — obie sesje trafiły w ten sam chunk niezależnie), pozostałe dwa wyniki (165/230) tylko ze streszczenia, nominacja do Nagrody Sędziów niepotwierdzona wprost w chunku, imiona z formularzy zgód celowo pominięte, nazwisko trenera nieczytelne OCR. Rozbieżność: ta sesja znalazła i zacytowała sprzeczność liczebności drużyny (10 vs 8 osób, z korespondencji gmail — lipcowa wersja jej nie ma, bo nie sięgnęła po te same koperty gmail). Lipcowa wersja znalazła niejednoznaczność sezonu SUBMERGED vs UNEARTHED (paperless:6) i konkretne imiona dzieci z nazw plików (metadane, nie treść dokumentu) — ta sesja pominęła paperless:6 całkowicie i nie sięgnęła po entities[type=filename]. Dwie niezależne kompilacje tej samej encji nie są sprzeczne, są komplementarne — dobry sygnał, że metoda jest powtarzalna, zły sygnał, że jedna kompilacja pomija realne dowody, które druga znalazła.
3. Zostawić oba repo osobno, jawnie zarchiwizować to jako dwa niezależne przebiegi tej samej fazy. Najbezpieczniejsze, ale traci szansę na scalenie uzupełniających się dowodów z punktu 2.

Krok operatora, niezależnie od wyboru z (1)-(3): ~/kb-wiki-etap1-sesja-2026-08-27/ istnieje lokalnie, nigdy nie pushowany — do usunięcia/scalenia/zachowania wg decyzji, nie automatycznie.

---

5. Poza zakresem tej notatki (Etap 2, jeśli operator potwierdzi kontynuację)

Zależnie od wyniku rekoncyliacji z §4:

• Skala do pełnej listy 17 encji z audytu §3 (już częściowo pokryta lipcowym repo inną listą — PZU/WARTA/wspólnota/FLL nie pokrywają się z 17-pozycyjną listą audytu poza fll-2025-26; wymaga ponownego review, które z 17 są już zrobione pod innymi nazwami).
• Lint automatyczny w kodzie (kb-wiki/lint.py, inwariant 3 pełny) — żadna z dwóch kopii tego nie ma, obie robiły lint ręcznie.
• Jednorazowy skan <EFBFBD>/\x00 na źródłach, które faktycznie zasiliły PoC (decyzja h) — nie wykonany w żadnej z dwóch kompilacji; oba proof-of-concept napotkały uszkodzony OCR organicznie (paperless:119/120 w obu wersjach fll-2025-26, mbank.md ta sesja) bez systematycznego skanu.
• Integracja source='wiki' w packages/kb-retrieval (inwariant 5+7) — poza zakresem obu przebiegów.
• Rozjazd scripts/kb/check_okf.py (SCOPE sztywny) — patrz §2, nie naprawiony celowo (instrukcja zlecenia: nie hackować).