Jun 9, 2026, 3:31 PM

brain/knowledge/concepts/_index_karpathy.md

@@ -0,0 +1,75 @@
+# LLM Wiki
+
+A pattern for building personal knowledge bases using LLMs.
+
+This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
+
+## The core idea
+
+Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
+
+The idea here is different. Instead of just retrieving from raw documents at query time, the LLM **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then *kept current*, not re-derived on every query.
+
+This is the key difference: **the wiki is a persistent, compounding artifact.** The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.
+
+You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.
+
+This can apply to a lot of different contexts. A few examples:
+
+- **Personal**: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
+- **Research**: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
+- **Reading a book**: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
+- **Business/team**: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
+- **Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives** — anything where you're accumulating knowledge over time and want it organized rather than scattered.
+
+## Architecture
+
+There are three layers:
+
+**Raw sources** — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.
+
+**The wiki** — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.
+
+**The schema** — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.
+
+## Operations
+
+**Ingest.** You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.
+
+**Query.** You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: **good answers can be filed back into the wiki as new pages.** A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.
+
+**Lint.** Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.
+
+## Indexing and logging
+
+Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:
+
+**index.md** is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.
+
+**log.md** is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. `## [2026-04-02] ingest | Article Title`), the log becomes parseable with simple unix tools — `grep "^## \[" log.md | tail -5` gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.
+
+## Optional: CLI tools
+
+At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. [qmd](https://github.com/tobi/qmd) is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.
+
+## Tips and tricks
+
+- **Obsidian Web Clipper** is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
+- **Download images locally.** In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. `raw/assets/`). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
+- **Obsidian's graph view** is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
+- **Marp** is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
+- **Dataview** is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
+- The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.
+
+## Why this works
+
+The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.
+
+The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.
+
+The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.
+
+
+## Note
+
+This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.@_in

brain/knowledge/concepts/accidental-dba.md

@@ -0,0 +1,36 @@
+---
+title: "Accidental DBA (Przypadkowy Administrator)"
+type: "concept"
+tags: [dba, kariera, zarządzanie-bazami-danych]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/accidental-dba-intro]]"]
+confidence: high
+---
+
+# Accidental DBA (Przypadkowy Administrator)
+
+## Definition
+Osoba, która nie planowała kariery jako administrator baz danych (DBA), ale z racji potrzeb organizacji lub specyfiki projektów (np. jako deweloper lub administrator systemów), przejęła pełną odpowiedzialność za stabilność, bezpieczeństwo i wydajność serwerów bazodanowych.
+
+## How It Works
+Zjawisko często zaczyna się od pojedynczego incydentu (awaria produkcji, powolne zapytanie), który wymaga interwencji osoby "najbardziej technicznej" w zespole. Z czasem te interwencje stają się stałym elementem obowiązków, tworząc nieformalną rolę administratora.
+
+## Key Parameters
+- **Brak formalnego wykształcenia DBA**: Uczenie się na "żywym organizmie".
+- **Reaktywny tryb pracy**: Dominacja gaszenia pożarów nad planowaniem.
+- **Dualizm roli**: Łączenie zadań deweloperskich/systemowych z administracją bazą danych.
+
+## When To Use
+Termin używany w HR i zarządzaniu IT do identyfikacji luk kompetencyjnych i potrzeb szkoleniowych w zespołach operacyjnych.
+
+## Risks & Pitfalls
+- **Wysoki stres**: Odpowiedzialność za dane bez pełnego zrozumienia mechanizmów silnika (np. SQL Server).
+- **Zaniedbanie podstaw**: Brak testów backupów lub monitoringu, co prowadzi do katastrofalnych awarii.
+- **Dług technologiczny**: Rozwiązania "na szybko" (quick fixes), które utrudniają skalowanie systemu w przyszłości.
+
+## Related Concepts
+- [[concepts/proactive-administration]] - Pożądany kierunek ewolucji Accidental DBA.
+
+## Sources
+- [[summaries/accidental-dba-intro]]

brain/knowledge/concepts/ai-hallucinations.md

@@ -0,0 +1,35 @@
+---
+title: "Halucynacje AI (AI Hallucinations)"
+type: "concept"
+tags: [AI, bezpieczeństwo, ryzyko]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/ai-impact-on-dba]]"]
+confidence: high
+---
+
+# Halucynacje AI (AI Hallucinations)
+
+## Definition
+Zjawisko, w którym model językowy (LLM) lub system AI generuje informacje, które brzmią przekonująco i logicznie, ale są całkowicie nieprawdziwe, nielogiczne lub niezgodne z faktami.
+
+## How It Works
+Wynika z probabilistycznej natury modeli AI, które przewidują kolejny najbardziej prawdopodobny token (słowo), zamiast operować na twardej bazie faktów. W administracji bazami danych może to objawiać się np. sugerowaniem nieistniejących parametrów konfiguracyjnych lub błędnych skryptów SQL.
+
+## Key Parameters
+- **Temperatura modelu**: Wyższa temperatura sprzyja kreatywności, ale zwiększa ryzyko halucynacji.
+- **Kontekst (Grounding)**: Brak dostępu do aktualnych danych technicznych zwiększa prawdopodobieństwo błędu.
+
+## When To Use
+Pojęcie kluczowe przy projektowaniu systemów [[concepts/human-in-the-loop]], gdzie człowiek musi weryfikować wyniki pracy AI.
+
+## Risks & Pitfalls
+- **Destabilizacja systemów**: Uruchomienie "halucynowanego" skryptu na produkcji może doprowadzić do utraty danych lub przestoju.
+- **Fałszywe poczucie bezpieczeństwa**: Przekonujący ton AI może uśpić czujność administratora.
+
+## Related Concepts
+- [[concepts/human-in-the-loop]] - Niezbędny mechanizm obronny przed halucynacjami.
+- [[concepts/proactive-administration]] - Ryzyko przy automatycznym dostrajaniu bazy przez AI.
+
+## Sources
+- [[summaries/ai-impact-on-dba]]

brain/knowledge/concepts/ai-pipelines.md

@@ -0,0 +1,43 @@
+---
+title: "Rurociągi AI (AI Pipelines)"
+type: "concept"
+tags: [AI, automatyzacja, workflow, inżynieria-promptów]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/google-nanobanana-workflow]]", "[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
+confidence: high
+---
+
+# Rurociągi AI (AI Pipelines)
+
+## Definition
+Zaawansowany model pracy z AI, w którym zamiast ręcznego wpisywania pojedynczych promptów, buduje się zautomatyzowane ciągi zdarzeń (workflow). Dane wejściowe przechodzą przez serię węzłów (nodes), gdzie są transformowane, wzbogacane i dystrybuowane przez różne modele AI i API.
+
+## How It Works
+Typowy rurociąg składa się z:
+1. **Triggera**: (np. wiadomość na Telegramie, wrzucenie pliku do `raw/`).
+2. **Warstwy wzbogacania**: Jeden model AI (np. GPT-4) poprawia prompt dla innego modelu (np. Gemini Image).
+3. **Generacji równoległej**: Tworzenie wielu wariantów jednocześnie.
+4. **Dystrybucji**: Automatyczny zapis wyniku w chmurze lub publikacja.
+
+## Key Parameters
+- **Szybkość (Throughput)**: Ile zasobów system generuje w jednostce czasu.
+- **Koszt (Cost per Asset)**: Wykorzystanie modeli typu "Flash" do obniżenia kosztów masowej produkcji.
+- **Powtarzalność**: Zdolność do uzyskania spójnych wyników przy minimalnym udziale człowieka.
+
+## When To Use
+- Masowa produkcja treści (social media, newslettery).
+- Przetwarzanie dużych zbiorów danych (summarization, data extraction).
+- Systemy typu [[concepts/human-in-the-loop]], gdzie człowiek tylko inicjuje proces.
+
+## Risks & Pitfalls
+- **Zależność od API**: Zmiany w cennikach lub limitach dostawców mogą zablokować rurociąg.
+- **Utrata jakości**: Bez odpowiednich "checkpointów" kontroli jakości, rurociąg może generować treści o niskiej wartości (AI slop).
+
+## Related Concepts
+- [[concepts/human-in-the-loop]] - Rurociąg zazwyczaj wymaga człowieka na początku lub końcu.
+- [[entities/n8n]] - Główne narzędzie do budowy takich rurociągów.
+
+## Sources
+- [[summaries/google-nanobanana-workflow]]
+- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]

brain/knowledge/concepts/autoresearch.md

@@ -0,0 +1,45 @@
+---
+title: "Autoresearch"
+type: "concept"
+tags: [AI, automatyzacja, machine-learning, karpathy]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/how-to-deploy-autoresearch]]", "[[summaries/karpathy-llm-wiki-breakdown]]"]
+confidence: high
+---
+
+# Autoresearch
+
+## Definition
+Wzorzec projektowy (i konkretne narzędzie autorstwa Andreja Karpathy'ego), w którym agent AI (LLM) autonomicznie prowadzi badania nad poprawą innego modelu AI. Agent modyfikuje kod źródłowy, przeprowadza eksperymenty i uczy się na ich wynikach bez bezpośredniego udziału człowieka.
+
+## How It Works
+System działa w pętli zamkniętej:
+1. **Instrukcje (Meta-prompt)**: Człowiek definiuje cel i strategię w pliku (np. `program.md`).
+2. **Akcja**: Agent AI modyfikuje plik `train.py`.
+3. **Eksperyment**: Uruchamiany jest krótki (np. 5-minutowy) proces treningowy.
+4. **Ocena**: System porównuje wynik (`val_bpb`) z poprzednim najlepszym rezultatem.
+5. **Wersjonowanie**: Udane zmiany są zatwierdzane przez `git`, budując trwały postęp.
+
+## Key Parameters
+- **Budżet czasowy**: Stały czas na eksperyment (np. 5 min) wymusza szukanie najbardziej efektywnych rozwiązań.
+- **val_bpb**: Obiektywna metryka sukcesu (niższa = lepsza).
+- **Autonomia**: Zdolność agenta do podejmowania setek decyzji bez zatwierdzenia przez człowieka.
+
+## When To Use
+- Przy optymalizacji hiperparametrów modeli.
+- Przy poszukiwaniu nowych architektur sieci neuronowych.
+- W badaniach, gdzie przestrzeń poszukiwań jest zbyt duża dla człowieka.
+
+## Risks & Pitfalls
+- **Halucynacje w kodzie**: Agent może zaproponować kod, który się nie kompiluje lub daje błędne wyniki (rozwiązywane przez pętlę błędu).
+- **Zasoby GPU**: System wymaga ciągłego dostępu do mocy obliczeniowej.
+- **Lokalne minima**: Agent może utknąć w jednej strategii poprawy (wymaga dopracowania meta-instrukcji).
+
+## Related Concepts
+- [[concepts/ai-pipelines]] - Autoresearch to najbardziej zaawansowana forma rurociągu AI.
+- [[concepts/knowledge-compilation]] - Kod modelu jest "kompilowany" przez agenta do coraz lepszej formy.
+
+## Sources
+- [[summaries/how-to-deploy-autoresearch]]
+- [[summaries/karpathy-llm-wiki-breakdown]]

brain/knowledge/concepts/compounding-knowledge.md

@@ -0,0 +1,36 @@
+---
+title: "Kumulowanie Wiedzy (Compounding Knowledge)"
+type: "concept"
+tags: [produktywność, AI, wiedza, karpathy]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
+confidence: high
+---
+
+# Kumulowanie Wiedzy (Compounding Knowledge)
+
+## Definition
+Właściwość bazy wiedzy (Wiki), dzięki której z każdym nowym dodanym źródłem staje się ona nie tylko większa (więcej plików), ale przede wszystkim gęstsza i bogatsza w powiązania.
+
+## How It Works
+Podczas dodawania nowego źródła, LLM nie tworzy izolowanej notatki, ale aktywnie aktualizuje istniejące strony encji i koncepcji. Nowe informacje wzmacniają lub podważają stare twierdzenia, a automatyczne linkowanie krzyżowe buduje gęstą sieć skojarzeń.
+
+## Key Parameters
+- **Gęstość sieci (Graph Density)**: Liczba powiązań między stronami.
+- **Synteza międzydokumentowa**: Zdolność bazy do odpowiadania na pytania o relacje między autorami/źródłami.
+
+## When To Use
+- W długoterminowych projektach badawczych.
+- Przy śledzeniu ewoluujących trendów lub tematów (np. rozwój AI).
+
+## Risks & Pitfalls
+- **Maintenance Burden**: Bez pomocy AI, koszt utrzymania spójności w gęstej sieci rośnie wykładniczo.
+- **Stale Claims**: Ryzyko posiadania nieaktualnych syntez, jeśli LLM nie przeprowadzi poprawnej aktualizacji podczas ingestji.
+
+## Related Concepts
+- [[concepts/knowledge-compilation]] - Proces prowadzący do kumulacji.
+- [[feynman_problems]] - Narzędzie do ukierunkowania kumulacji wiedzy na konkretne problemy.
+
+## Sources
+- [[summaries/karpathy-llm-wiki-breakdown]]

brain/knowledge/concepts/human-in-the-loop.md

@@ -0,0 +1,36 @@
+---
+title: "Human-in-the-loop (HITL)"
+type: "concept"
+tags: [AI, workflow, design-pattern]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
+confidence: high
+---
+
+# Human-in-the-loop (HITL)
+
+## Definition
+Model projektowania systemów AI, w którym człowiek pozostaje integralną częścią procesu, sprawując nadzór nad działaniami sztucznej inteligencji, podejmując ostateczne decyzje lub korygując wyniki.
+
+## How It Works
+AI wykonuje "ciężką pracę" (np. zbieranie danych, generowanie szkiców, formatowanie), a człowiek działa jako filtr końcowy (redaktor, zatwierdzający). Proces zazwyczaj kończy się na etapie "Draft", który wymaga manualnej akcji do pełnej realizacji.
+
+## Key Parameters
+- **Poziom automatyzacji**: Ile procent pracy wykonuje AI (np. 90% w przypadku newslettera).
+- **Punkt kontrolny (Checkpoint)**: Moment, w którym maszyna przekazuje pałeczkę człowiekowi.
+
+## When To Use
+- Gdy błędy AI (halucynacje) mają wysoki koszt reputacyjny lub biznesowy.
+- Gdy wymagany jest unikalny "głos" lub ton marki.
+- W skomplikowanych procesach decyzyjnych, gdzie kontekst pozatechniczny jest kluczowy.
+
+## Risks & Pitfalls
+- **Wąskie gardło**: Człowiek może stać się najwolniejszym elementem systemu.
+- **Nadmierne zaufanie**: Ryzyko "gumowego stemplowania" wyników AI bez ich faktycznego sprawdzenia.
+
+## Related Concepts
+- **Automatyzacja workflow** - Techniczna podstawa realizacji HITL (np. [[entities/n8n]]).
+
+## Sources
+- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]

brain/knowledge/concepts/idea-collision.md

@@ -0,0 +1,41 @@
+---
+title: "Kolizja Pomysłów (Idea Collision)"
+type: "concept"
+tags: [kreatywność, AI, innowacja, loom]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/loom-thinking-tool]]", "[[summaries/google-nanobanana-workflow]]"]
+confidence: high
+---
+
+# Kolizja Pomysłów (Idea Collision)
+
+## Definition
+Proces twórczy polegający na celowym zderzaniu dwóch lub więcej idei, często pochodzących z zupełnie odległych dziedzin, w celu odkrycia ukrytych podobieństw strukturalnych i wygenerowania nowej, unikalnej wartości.
+
+## How It Works
+W systemach wspieranych przez AI (jak [[summaries/loom-thinking-tool]]), proces ten jest zautomatyzowany:
+1. System wybiera losowe lub semantycznie odległe notatki z bazy wiedzy.
+2. Model językowy analizuje ich treść w poszukiwaniu analogii, wspólnych zasad lub potencjalnych synergii.
+3. Wynik prezentowany jest użytkownikowi jako "iskra" do dalszego myślenia lub gotowa synteza.
+
+## Key Parameters
+- **Dystans semantyczny**: Im bardziej odległe dziedziny, tym trudniejsza, ale potencjalnie bardziej wartościowa kolizja.
+- **Struktura vs Treść**: Najsilniejsze kolizje opierają się na podobieństwie mechanizmów (np. biologia mrówek vs zarządzanie projektami), a nie tylko na słowach kluczowych.
+
+## When To Use
+- W fazie generowania pomysłów (ideacji).
+- Gdy czujemy, że nasz proces myślowy utknął w rutynie.
+- Do budowy unikalnych strategii biznesowych i artystycznych.
+
+## Risks & Pitfalls
+- **Puste skojarzenia**: Nie każda kolizja prowadzi do wartościowego wniosku (ryzyko szumu).
+- **Zależność od AI**: Ryzyko, że użytkownik przestanie samodzielnie szukać połączeń, polegając wyłącznie na algorytmie.
+
+## Related Concepts
+- [[concepts/compounding-knowledge]] - Kolizje przyspieszają gęstnienie sieci wiedzy.
+- [[concepts/metacognition-as-a-service]] - Analiza efektów kolizji pomaga zrozumieć własny umysł.
+
+## Sources
+- [[summaries/loom-thinking-tool]]
+- [[summaries/google-nanobanana-workflow]]

brain/knowledge/concepts/knowledge-compilation.md

@@ -0,0 +1,36 @@
+---
+title: "Kompilacja Wiedzy (Knowledge Compilation)"
+type: "concept"
+tags: [AI, wiedza, architektura, karpathy]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
+confidence: high
+---
+
+# Kompilacja Wiedzy (Knowledge Compilation)
+
+## Definition
+Analogia zapożyczona z inżynierii oprogramowania, gdzie surowe dokumenty źródłowe (PDFy, notatki, artykuły) są traktowane jako "kod źródłowy", który LLM "kompiluje" do postaci trwałej Wiki ("pliku binarnego").
+
+## How It Works
+Zamiast przeszukiwać surowe fragmenty tekstów przy każdym pytaniu, LLM przetwarza je raz w momencie ingestji, ekstrahując esencję i integrując ją z istniejącą strukturą. Wynikowa Wiki jest sformatowana tak, aby była optymalna dla przyszłych zapytań i syntez.
+
+## Key Parameters
+- **Niezmienność źródeł (Immutability)**: Oryginalne pliki pozostają nienaruszone jako "ground truth".
+- **Gęstość informacji**: Skompilowana strona zawiera syntezę wielu źródeł zamiast powielać te same fakty.
+
+## When To Use
+- Gdy zależy nam na wysokiej jakości odpowiedzi wymagających łączenia faktów z wielu dokumentów.
+- Przy budowie osobistych baz wiedzy na konkretne tematy badawcze.
+
+## Risks & Pitfalls
+- **Koszt Ingestji**: Proces kompilacji jest droższy (wymaga więcej tokenów) niż proste indeksowanie RAG.
+- **Ryzyko "utrwalenia" błędów**: Halucynacja podczas kompilacji może zostać zapisana w Wiki jako fakt.
+
+## Related Concepts
+- [[concepts/compounding-knowledge]] - Rezultat skutecznej kompilacji.
+- [[concepts/rag-vs-wiki]] - Alternatywne podejście "interpretowane".
+
+## Sources
+- [[summaries/karpathy-llm-wiki-breakdown]]

brain/knowledge/concepts/metacognition-as-a-service.md

@@ -0,0 +1,37 @@
+---
+title: "Metapoznanie jako Usługa (Metacognition as a Service)"
+type: "concept"
+tags: [AI, psychologia, produktywność, loom]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/loom-thinking-tool]]"]
+confidence: medium
+---
+
+# Metapoznanie jako Usługa (Metacognition as a Service)
+
+## Definition
+Wykorzystanie sztucznej inteligencji do monitorowania, analizowania i dostarczania informacji zwrotnej na temat procesów myślowych użytkownika, jego uprzedzeń, preferencji i ewolucji intelektualnej.
+
+## How It Works
+AI skanuje całą bazę wiedzy użytkownika (notatki, dzienniki, artykuły) i identyfikuje:
+- **Motywy przewodnie**: Tematy, które powracają w różnych kontekstach.
+- **Ślepe plamy (Blind Spots)**: Obszary, o których użytkownik nigdy nie pisze lub pytania, których unika.
+- **Zmiany w czasie**: Ewolucję definicji i poglądów (np. co myślałem o pracy 2 lata temu vs dziś).
+
+## Benefits
+- **Obiektywne lustro**: Pozwala spojrzeć na własne myślenie z dystansem (percepcja głębi).
+- **Wykrywanie uprzedzeń**: AI może wskazać, że nasze wnioski opierają się na niezweryfikowanych założeniach.
+- **Wsparcie rozwoju**: Sugeruje nowe ścieżki eksploracji w oparciu o luki w wiedzy.
+
+## When To Use
+- W głębokiej pracy intelektualnej (badania, pisanie).
+- W procesach samorozwoju i coachingu.
+- Przy podejmowaniu strategicznych decyzji (jako "adwokat diabła").
+
+## Related Concepts
+- [[concepts/idea-collision]] - Wynik aktywnego metapoznania.
+- [[concepts/knowledge-compilation]] - Metapoznanie pomaga w lepszej organizacji kompilowanej wiedzy.
+
+## Sources
+- [[summaries/loom-thinking-tool]]

brain/knowledge/concepts/plain-text-productivity.md

@@ -0,0 +1,37 @@
+---
+title: "Plain-text Productivity"
+type: "concept"
+tags: [produktywność, metodyka, plain-text]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/one-file-diary]]"]
+confidence: high
+---
+
+# Plain-text Productivity
+
+## Definition
+Metodyka zarządzania czasem, zadaniami i wiedzą oparta wyłącznie na prostych plikach tekstowych (`.txt`, `.md`). Wyklucza skomplikowane systemy bazodanowe na rzecz plików czytelnych dla człowieka i maszyn.
+
+## How It Works
+Użytkownik tworzy proste struktury (listy, nagłówki z datami) w edytorze tekstu. Kluczowe jest używanie standardowych formatów, które nie wymagają specjalistycznego oprogramowania i są łatwe do wersjonowania (np. przez Git).
+
+## Key Parameters
+- **Przenośność**: Pliki działają na każdym systemie operacyjnym.
+- **Długowieczność**: Tekst będzie czytelny za 50 lat.
+- **Szybkość**: Brak czasu ładowania aplikacji, natychmiastowe wyszukiwanie.
+
+## When To Use
+- W środowiskach technicznych (CLI, serwery).
+- Gdy użytkownik chce uniknąć "prokrastynacji narzędziowej" (ciągłego zmieniania apek do notatek).
+- Gdy wymagana jest pełna kontrola nad danymi i ich prywatność.
+
+## Risks & Pitfalls
+- **Brak automatycznych przypomnień**: System nie wyśle powiadomienia o deadline.
+- **Złożoność przy dużych projektach**: Zarządzanie tysiącami linii w jednym pliku może wymagać dyscypliny w tagowaniu/szukaniu.
+
+## Related Concepts
+- [[concepts/work-journaling]] - Prowadzenie dziennika jako podzbiór produktywności tekstowej.
+
+## Sources
+- [[summaries/one-file-diary]]

brain/knowledge/concepts/proactive-administration.md

@@ -0,0 +1,39 @@
+---
+title: "Administracja Proaktywna (Proactive Administration)"
+type: "concept"
+tags: [dba, metodyka, AI, monitoring]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/ai-impact-on-dba]]", "[[summaries/accidental-dba-intro]]"]
+confidence: high
+---
+
+# Administracja Proaktywna (Proactive Administration)
+
+## Definition
+Podejście do zarządzania systemami (szczególnie bazami danych), w którym główny nacisk kładzie się na przewidywanie i zapobieganie problemom, zamiast jedynie reagowania na już zaistniałe awarie.
+
+## How It Works
+Wykorzystuje zaawansowany monitoring, progi ostrzegawcze oraz – coraz częściej – analitykę predykcyjną opartą na AI. Systemy proaktywne analizują trendy (np. wzrost zajętości dysku, fragmentacja indeksów, wzorce obciążenia CPU) i sugerują działania naprawcze (np. dodanie indeksu, rozszerzenie pamięci) przed wystąpieniem kryzysu.
+
+## Key Parameters
+- **Czas do awarii (TTF)**: Identyfikacja ryzyk z wyprzedzeniem.
+- **Automatyzacja adaptacyjna**: Zdolność systemu do samonaprawy w bezpiecznych granicach.
+- **Analityka trendów**: Porównywanie bieżących metryk z profilami historycznymi.
+
+## When To Use
+- W systemach o krytycznym znaczeniu biznesowym (High Availability).
+- Przy zarządzaniu dużymi flotami serwerów, gdzie manualny monitoring jest niemożliwy.
+- W nowoczesnych strukturach DevOps/SRE.
+
+## Risks & Pitfalls
+- **Over-monitoring**: Generowanie zbyt dużej liczby alertów (alarm fatigue).
+- **Zaufanie do AI**: Ślepe podążanie za predykcjami AI może prowadzić do niepotrzebnych kosztów lub błędnych zmian konfiguracyjnych (patrz: [[concepts/ai-hallucinations]]).
+
+## Related Concepts
+- [[concepts/accidental-dba]] - DBA z przypadku często utykają w trybie reaktywnym; administracja proaktywna to ich cel rozwojowy.
+- [[entities/tavily]] - Może być wykorzystywany do proaktywnego wyszukiwania rozwiązań dla znanych błędów.
+
+## Sources
+- [[summaries/ai-impact-on-dba]]
+- [[summaries/accidental-dba-intro]]

brain/knowledge/concepts/rag-vs-wiki.md

@@ -0,0 +1,39 @@
+---
+title: "RAG vs LLM Wiki"
+type: "concept"
+tags: [AI, architektura, RAG, wiki]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
+confidence: high
+---
+
+# RAG vs LLM Wiki
+
+## Definition
+Porównanie dwóch paradygmatów wykorzystania LLM do pracy z dokumentami: Retrieval-Augmented Generation (RAG) oraz persistent LLM Wiki.
+
+## How It Works
+- **RAG**: Działa w trybie "bezstanowym". Na każde pytanie wyszukuje fragmenty w surowych plikach i składa z nich odpowiedź "ad hoc".
+- **Wiki**: Działa w trybie "stanowym". Wiedza jest wstępnie przetworzona (skompilowana) do struktury Wiki, a odpowiedzi są generowane na podstawie tej syntezy.
+
+## Comparison Table
+
+| Cecha | RAG | LLM Wiki |
+| :--- | :--- | :--- |
+| **Dane** | Surowe dokumenty | Skompilowane strony wiki |
+| **Stanowość** | Bezstanowy (każde zapytanie od zera) | Stanowy (wiedza kumuluje się) |
+| **Skala** | Miliony dokumentów | 100-500 wybranych źródeł |
+| **Koszt** | Tani ingest, drogie zapytania (tokeny) | Drogi ingest, tanie zapytania |
+| **Cel** | Wyszukiwanie faktów (Lookup) | Synteza i zrozumienie (Synthesis) |
+
+## When To Use
+- **Wybierz RAG**: Gdy masz ogromne, dynamicznie zmieniające się zbiory danych (np. dokumentacja techniczna firmy, akta prawne).
+- **Wybierz Wiki**: Gdy pracujesz nad konkretnym tematem badawczym, piszesz książkę lub budujesz osobistą bazę wiedzy (Second Brain).
+
+## Related Concepts
+- [[concepts/knowledge-compilation]]
+- [[concepts/compounding-knowledge]]
+
+## Sources
+- [[summaries/karpathy-llm-wiki-breakdown]]

brain/knowledge/concepts/software-1-0.md

@@ -0,0 +1,34 @@
+---
+title: "Software 1.0"
+type: "concept"
+tags: [programowanie, architektura, historia-it]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/software-2-0]]"]
+confidence: high
+---
+
+# Software 1.0
+
+## Definition
+Tradycyjny stos oprogramowania, w którym programista tworzy kod poprzez pisanie jawnych instrukcji w językach wysokiego poziomu (C++, Python, Java). Każda linijka kodu definiuje konkretne zachowanie systemu w przestrzeni programu.
+
+## How It Works
+Programista identyfikuje algorytmy i reguły logiczne potrzebne do rozwiązania problemu, a następnie implementuje je manualnie. Wynikowy kod jest czytelny dla człowieka (przed kompilacją) i oparty na deterministycznych strukturach sterujących (if/else, pętle).
+
+## Key Parameters
+- **Jawność**: Każda funkcja i moduł mają zdefiniowaną logikę.
+- **Determinism**: System zachowuje się dokładnie tak, jak został zaprogramowany.
+- **Struktura**: Hierarchiczna budowa modułów połączonych przez API.
+
+## When To Use
+- W problemach o jasnej, matematycznej lub logicznej strukturze.
+- W systemach krytycznych wymagających pełnej weryfikowalności kodu.
+- W zadaniach, gdzie dane są rzadkie lub nie istnieją.
+
+## Related Concepts
+- [[concepts/software-2.0]] - Następca i uzupełnienie Software 1.0.
+- [[concepts/knowledge-compilation]] - Proces zamiany kodu 1.0 na binarny vs trening modelu 2.0.
+
+## Sources
+- [[summaries/software-2-0]]

brain/knowledge/concepts/software-2-0.md

@@ -0,0 +1,44 @@
+---
+title: "Software 2.0"
+type: "concept"
+tags: [AI, programowanie, machine-learning, karpathy]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/software-2-0]]", "[[summaries/karpathy-llm-wiki-breakdown]]", "[[summaries/how-to-deploy-autoresearch]]"]
+confidence: high
+---
+
+# Software 2.0
+
+## Definition
+Paradygmat programowania, w którym systemy są tworzone nie przez pisanie instrukcji, ale przez optymalizację parametrów (wag) modelu na podstawie zbioru danych i zdefiniowanego celu.
+
+## How It Works
+Zamiast budować algorytm, programista 2.0:
+1. Zbiera i przygotowuje dane (Dataset).
+2. Definiuje architekturę sieci neuronowej (Szkielet).
+3. Uruchamia proces optymalizacji (Trening), który automatycznie dobiera wagi tak, aby zminimalizować błąd.
+
+## Key Parameters
+- **Wagi (Weights)**: Miliony parametrów tworzących "kod" 2.0.
+- **Funkcja celu (Loss Function)**: Definiuje, co model ma osiągnąć.
+- **Dane (Dataset)**: Prawdziwe "źródło prawdy" systemu.
+
+## Benefits
+- **Wydajność**: Często przewyższa możliwości człowieka w rozpoznawaniu wzorców (obraz, mowa).
+- **Adaptacyjność**: Łatwa zmiana zachowania poprzez dodanie nowych danych.
+- **Hardware-friendly**: Optymalne dla procesorów graficznych i dedykowanych układów AI.
+
+## Risks & Pitfalls
+- **Brak interpretowalności**: Trudno zrozumieć, dlaczego model podjął konkretną decyzję.
+- **Ataki adwersarialne**: Podatność na celowo przygotowane, błędne dane wejściowe.
+- **Uprzedzenia**: Model kopiuje błędy i uprzedzenia zawarte w danych treningowych.
+
+## Related Concepts
+- [[concepts/software-1.0]] - Tradycyjne podejście.
+- [[concepts/knowledge-compilation]] - Trening jako forma kompilacji wiedzy.
+- [[concepts/autoresearch]] - Automatyzacja tworzenia oprogramowania 2.0.
+
+## Sources
+- [[summaries/software-2-0]]
+- [[summaries/karpathy-llm-wiki-breakdown]]

brain/knowledge/concepts/val-bpb.md

@@ -0,0 +1,23 @@
+---
+title: "val_bpb (Bits Per Byte)"
+type: "concept"
+tags: [machine-learning, metryka, AI]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/how-to-deploy-autoresearch]]"]
+confidence: high
+---
+
+# val_bpb (Bits Per Byte)
+
+## Definition
+Metryka stosowana w uczeniu maszynowym (szczególnie w modelach językowych), mierząca jak efektywnie model przewiduje dane. Określa średnią liczbę bitów potrzebną do zakodowania jednego bajtu informacji.
+
+## How It Works
+Niższa wartość `val_bpb` oznacza, że model lepiej "rozumie" strukturę danych i potrafi je przewidzieć z mniejszą niepewnością. W projekcie [[concepts/autoresearch]] służy jako główny kompas dla agenta AI – każda zmiana w kodzie musi prowadzić do obniżenia tej liczby.
+
+## Why It Matters
+W przeciwieństwie do innych metryk, `val_bpb` jest niezależna od rozmiaru słownika (vocabulary size) czy tokenizera, co czyni ją idealną do porównywania bardzo różnych architektur modeli i metod treningowych.
+
+## Sources
+- [[summaries/how-to-deploy-autoresearch]]

brain/knowledge/concepts/work-journaling.md

@@ -0,0 +1,39 @@
+---
+title: "Work Journaling (Dziennik Pracy)"
+type: "concept"
+tags: [produktywność, inżynieria, metodyka]
+created: 2026-05-14
+updated: 2026-05-14
+sources: ["[[summaries/one-file-diary]]", "[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
+confidence: high
+---
+
+# Work Journaling (Dziennik Pracy)
+
+## Definition
+Praktyka rejestrowania działań, decyzji i incydentów w czasie rzeczywistym podczas dnia pracy. Służy jako "zewnętrzna pamięć" inżyniera.
+
+## How It Works
+Pracownik zapisuje kluczowe zdarzenia (np. "09:00 - restart serwera X", "10:30 - spotkanie z zespołem Y") w liniowej strukturze. Wpisuje się nie tylko fakty, ale i uzasadnienia decyzji technicznych.
+
+## Key Parameters
+- **Zapis chronologiczny**: Liniowy potok zdarzeń.
+- **Audytowalność**: Możliwość odtworzenia przebiegu incydentu po fakcie.
+- **Kontekst**: Przechowywanie informacji o "dlaczego" coś zostało zrobione.
+
+## When To Use
+- Przy pracy z systemami krytycznymi (DBA, SRE).
+- Podczas debugowania długotrwałych problemów.
+- Jako podstawa do pisania raportów post-mortem lub tygodniowych podsumowań.
+
+## Risks & Pitfalls
+- **Przerwy w logowaniu**: Zapominanie o wpisach podczas stresujących awarii (kluczowe, by pisać "w trakcie").
+- **Szum informacyjny**: Zapisywanie zbyt wielu nieistotnych szczegółów.
+
+## Related Concepts
+- [[concepts/plain-text-productivity]] - Najczęstszy sposób realizacji dziennika.
+- [[concepts/human-in-the-loop]] - Dziennik może być miejscem zapisu interakcji z agentami AI.
+
+## Sources
+- [[summaries/one-file-diary]]
+- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]