04 / System
System
Architektura, elementy i przepracowany przykład wzorca w skali zespołowej.
Zasady opisują, co robi KMS. Strona systemu opisuje, jak jest zbudowany. To architektura referencyjna, do której ciągle wracam — z nazwanymi elementami i wprost wyłożonym przepływem.
Architektura
Sześć etapów, od lewej do prawej:
- Źródła — wszędzie, gdzie wchodzi surowy materiał: czat, notatki głosowe, transkrypty, integracje, przesłane pliki, zaplanowane scrapery, uruchomienia agentów.
- Przyjęcie — odbiera surowe wejście, normalizuje kształt, dopina proweniencję (kiedy, gdzie, kto, które uruchomienie agenta).
- Bramkarz — stosuje bramkę jakości z Bramkarz–Promotor. Odrzucaj wcześnie, zanim cokolwiek dotknie magazynu.
- Magazyn wiedzy — typowane encje, atomowe fakty, decyzje, źródła, koncepcje. Markdown na dysku dla warstwy osobistej; markdown + baza dla zespołowej; izolowana per-tenant baza dla aplikacyjnej.
- Przejścia kompilacyjne — odpalane przy każdej mutacji magazynu: wyciąganie faktów, łączenie encji, propagacja fali, wykrywanie sprzeczności. Zobacz Automatyczna kompilacja.
- Warstwa zapytań — zamienia prośby w języku naturalnym w pobrania z magazynu. Łączy encje, podąża za linkami, składa zsyntetyzowane odpowiedzi.
- Interfejs — powierzchnia, przy której pojawia się użytkownik. Rozmowa (Claude w terminalu), przeglądanie (Obsidian / web), UI wewnątrz produktu, kontekst pobierany przez agenta.
Przepływ nie jest ściśle liniowy. Przejścia kompilacyjne odpalają się w sposób ciągły. Warstwa zapytań może zapisywać z powrotem do magazynu (np. zapisując wyciągnięty wniosek). Interfejs może wywołać przyjęcie (notatka z rozmowy staje się surowym materiałem).
Elementy
Magazyn trzyma mały, stały zbiór typów elementów:
| Typ | Cel | Mutowalność |
|---|---|---|
| Encja | Rzeczywista rzecz (osoba, firma, projekt, źródło) | Głównie append; pola strukturalne aktualizowane |
| Koncepcja | Wielokrotnego użytku pomysł lub framework | Głównie append; autorstwa człowieka lub skompilowana |
| Decyzja | Podjęty wybór, z uzasadnieniem i alternatywami | Niemutowalna; zastąpienie jest jawne |
| Wniosek | Nieoczywiste odkrycie, często międzydziedzinowe | Głównie append; zwykle skompilowany |
| Źródło | Zewnętrzna referencja (artykuł, książka, prelekcja) | Niemutowalne; notatki dopinane osobno |
| Pochodne | Skompilowane streszczenie, skrót, widok | Regenerowalne ze źródeł |
Sześć typów to celowy wybór. Pięć byłoby za mało; osiem zaczyna się rozjeżdżać. To dyscyplina małych kategorii zastosowana na poziomie schematu.
Przepracowany przykład w skali zespołowej
Mały system koordynacji zespołowej, przy budowie którego pomagałem, siedzi w ciaśniejszym zakresie niż pełny zespołowy KMS, ale korzysta z tego samego wzorca od początku do końca. To najczystszy przepracowany przykład powyższej architektury, bo wszystko jest w markdownie, każdy typ elementu jest w użyciu, a przejścia kompilacyjne są widoczne.
Źródła — wątki Slacka, transkrypty spotkań, podsumowania sesji agentowych, ręczne aktualizacje.
Magazyn wiedzy — typowane foldery dla encji (osoby, projekty, klienci), wiedzy (wnioski, koncepcje) i decyzji. Wszystko markdown, wszystko wikilinkowane.
Kompilacja — każdy import sesji wywołuje ekstrakcję encji, tworzenie linków oraz zamiatanie pod kątem sprzeczności w stosunku do istniejącej wiedzy.
Warstwa zapytań — sesje Claude Code otwierane w katalogu projektu, z plikiem CLAUDE.md deklarującym schemat i reguły.
Interfejs — rozmowa z Claude do zbierania i syntezy; Obsidian do przeglądania; okresowe skróty zespołowe do dystrybucji.
System nie jest „narzędziem do produktywności zespołu”. Jest to KMS używający markdownu jako warstwy danych, z workflowami zespołowego OS-u jako interfejsem na górze tych danych. Właściwy sposób myślenia o tym: zespołowy OS to tylko jeden interfejs do zespołowego KMS-u.
Czym ta architektura wyraźnie nie jest
- Bazą grafową. Wikilinki dają ci graf za darmo; nie ma potrzeby osobnego magazynu.
- Bazą wektorową. Osadzenia pomagają w pobieraniu, ale nie są głównym indeksem. Wikilinki + system plików są głównym indeksem; osadzenia są fallbackiem dla zapytań rozmytych.
- Systemem kolejek / workflow. Przejścia kompilacyjne są funkcjami, nie zadaniami. Odpalają się na wyzwalaczach (zapis pliku, hook, cron), ale system nie jest silnikiem workflow.
- UI. Warstwa interfejsu jest wymienialna; magazyn jest trwałym artefaktem.
Co niesie ciężar
Jeśli zetniesz architekturę do najmniejszej działającej formy:
- Pliki markdown w folderach, z frontmatterem i wikilinkami.
- Plik CLAUDE.md deklarujący tablicę routingu i schematy elementów.
- Niewielki zbiór umiejętności do przyjmowania, kompilowania i pytania.
- Jakiś sposób odpalania przejść kompilacyjnych (hooki, cron, ręcznie).
Tyle. Cała reszta to wygoda.
Rev. 2026-04-18