---
okf: "0.1"
type: phase
visibility: private
status: active
updated: 2026-08-27
links:
  - ../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 `�`/`\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ć).