Jun 9, 2026, 4:06 PM
This commit is contained in:
@@ -0,0 +1,2 @@
|
|||||||
|
/cache
|
||||||
|
/project.local.yml
|
||||||
@@ -0,0 +1,26 @@
|
|||||||
|
# Conventions
|
||||||
|
|
||||||
|
Coding style, naming, and structural conventions for the Knowledge Base.
|
||||||
|
|
||||||
|
## Language Convention
|
||||||
|
|
||||||
|
- **Synthesis Layer Content**: Polish (Polski) is used for summaries, index listings, concepts, and log descriptions (matching the current Polish structure of `knowledge/`).
|
||||||
|
- **Configuration & Schemas**: English is used for `GEMINI.md`, core repository schemas, and code/script names.
|
||||||
|
|
||||||
|
## Formatting & Link Style
|
||||||
|
|
||||||
|
- **WikiLinks**: Prefer double brackets `[[knowledge/path/to/page]]` or standard relative link `[[page]]` for connections in the synthesis layer (`knowledge/`).
|
||||||
|
- **YAML Frontmatter**: When requested or appropriate, include metadata (tags, dates, source counts) at the top of markdown files.
|
||||||
|
- **Kebab Case**: File names in `knowledge/concepts/` and `knowledge/entities/` must be kebab-case (e.g., `human-in-the-loop.md`, `sql-server.md`).
|
||||||
|
|
||||||
|
## Log Bookkeeping
|
||||||
|
|
||||||
|
- **Log Appends**: Always append new entries to the top of `knowledge/log.md` with format:
|
||||||
|
```markdown
|
||||||
|
## [YYYY-MM-DD] Ingest | Source Title
|
||||||
|
- Bulleted details of created or updated pages.
|
||||||
|
```
|
||||||
|
|
||||||
|
## Feynman Problems Alignment
|
||||||
|
|
||||||
|
- **Central Alignment**: Every newly ingested raw file must be tested against the 12 Feynman Problems documented in `knowledge/feynman_problems.md`. If the content addresses or helps answer any of those questions, update the respective section in `knowledge/feynman_problems.md` with a direct link and concise insight.
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
# Core Memory
|
||||||
|
|
||||||
|
Top-level map and invariant rules for the LLM Knowledge Base repository.
|
||||||
|
|
||||||
|
## Knowledge Base Architecture
|
||||||
|
|
||||||
|
The project implements a personal knowledge base based on Andrej Karpathy's LLM Knowledge Base pattern and the 12 Feynman Problems.
|
||||||
|
|
||||||
|
### Directory Layout
|
||||||
|
|
||||||
|
- `raw/`: **Source of Truth**. Immutable. Contains original PDFs, clipped articles, transcripts, and personal notes.
|
||||||
|
- `raw/articles/`: Web articles and blog posts.
|
||||||
|
- `raw/inbox/`: New files to be processed/ingested.
|
||||||
|
- `raw/notes/`: Raw personal notes and ideas.
|
||||||
|
- `raw/transcripts/`: Audio/video transcripts.
|
||||||
|
- `knowledge/`: **Synthesis Layer**. Generated and updated solely by LLM agent.
|
||||||
|
- `knowledge/sources/` or `knowledge/summaries/`: Individual summaries of ingested sources.
|
||||||
|
- `knowledge/entities/`: Specific pages for tools, organizations, and people (e.g., `[[knowledge/entities/n8n]]`).
|
||||||
|
- `knowledge/concepts/`: Analytical pages for core ideas and theories (e.g., `[[knowledge/concepts/human-in-the-loop]]`).
|
||||||
|
- `knowledge/indices/`: Lists grouping files by category.
|
||||||
|
- `knowledge/index.md`: Master catalog mapping knowledge domains.
|
||||||
|
- `knowledge/log.md`: Chronological journal of ingest/analysis operations.
|
||||||
|
- `knowledge/feynman_problems.md`: Master list of the 12 Feynman problems.
|
||||||
|
- `GEMINI.md`: Configuration and instructions for Gemini CLI.
|
||||||
|
|
||||||
|
## Deep Dive Memories
|
||||||
|
|
||||||
|
- For technical tools, platform details, and runtimes, see `mem:tech_stack`.
|
||||||
|
- For useful workspace utility scripts and commands, see `mem:suggested_commands`.
|
||||||
|
- For naming standards, language conventions, and Markdown link styles, see `mem:conventions`.
|
||||||
|
- For validation and verification procedures before completing tasks, see `mem:task_completion`.
|
||||||
@@ -0,0 +1,33 @@
|
|||||||
|
# Memory Maintenance
|
||||||
|
|
||||||
|
## Discovery Model
|
||||||
|
|
||||||
|
- Core principle: progressive discovery through references, building a graph of memories.
|
||||||
|
- Initially, agents are provided with the list of all memories (names only).
|
||||||
|
- Agents should read `mem:core` as the top-level entry point (graph root).
|
||||||
|
This memory should contain references to other memories covering major project domains.
|
||||||
|
The referenced memories shall, in turn, shall contain references to even more specific memories, and so on.
|
||||||
|
The depth of the graph shall depend on the project complexity.
|
||||||
|
- Use topics/folders to group related memories in order to make the content structure explicit.
|
||||||
|
Folders can mirror project structure (e.g. modules like frontend/backend) or topics like debugging, architecture, etc.
|
||||||
|
- Memory references must use a mem: prefix inside backticks, e.g. `mem:frontend/core`.
|
||||||
|
The surrounding text should clearly indicate when to read the memory/which content to expect.
|
||||||
|
The text should provide more precise guidance than the memory name alone,
|
||||||
|
i.e. avoid a reference like "frontend debugging: `mem:frontend/debugging` and instead make clear which aspects of frontend debugging are covered.
|
||||||
|
- Memories themselves should not contain information about when to read them; this is the responsibility of the referring memory.
|
||||||
|
|
||||||
|
## Style
|
||||||
|
|
||||||
|
Dense agent notes, not prose docs. Prefer invariants, terse bullets.
|
||||||
|
Avoid obvious context, rationale, and examples unless they prevent likely mistakes.
|
||||||
|
Keep guidance durable and generalizable, not task-local.
|
||||||
|
|
||||||
|
## Add/update threshold
|
||||||
|
|
||||||
|
Add or update memories only with stable, non-obvious project conventions that avoid complex rediscovery in the future.
|
||||||
|
Do not add: quick-read facts; generic language/framework knowledge; one-off task notes; volatile line-level details; behavior likely to change soon.
|
||||||
|
|
||||||
|
## Maintenance Actions
|
||||||
|
|
||||||
|
- Renaming memories: References are updated automatically if handled via Serena's memory rename tool.
|
||||||
|
- Checking for stale memories (e.g. after deletion): Call `serena memories check` for a report.
|
||||||
@@ -0,0 +1,36 @@
|
|||||||
|
# Suggested Commands
|
||||||
|
|
||||||
|
Project and shell commands for development, utility, and maintenance tasks.
|
||||||
|
|
||||||
|
## Maintenance Scripts (Windows PowerShell)
|
||||||
|
|
||||||
|
- **Knowledge-base Terms Replacer**: Refactors old "wiki" references to "knowledge" across files and renames files containing "wiki":
|
||||||
|
```powershell
|
||||||
|
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\replace_knowledge.ps1
|
||||||
|
```
|
||||||
|
|
||||||
|
## File Search & Search Commands
|
||||||
|
|
||||||
|
- **Find specific pattern in knowledge directory**:
|
||||||
|
```powershell
|
||||||
|
Select-String -Path .\knowledge\**\*.md -Pattern "concept-pattern"
|
||||||
|
```
|
||||||
|
- **List files matching a glob recursively (using PowerShell)**:
|
||||||
|
```powershell
|
||||||
|
Get-ChildItem -Path .\knowledge -Recurse -Filter *.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Git Commands
|
||||||
|
|
||||||
|
- **Check current repository status**:
|
||||||
|
```powershell
|
||||||
|
git status
|
||||||
|
```
|
||||||
|
- **Inspect changes in working tree**:
|
||||||
|
```powershell
|
||||||
|
git diff HEAD
|
||||||
|
```
|
||||||
|
- **Check the 3 most recent commits to match style**:
|
||||||
|
```powershell
|
||||||
|
git log -n 3
|
||||||
|
```
|
||||||
@@ -0,0 +1,18 @@
|
|||||||
|
# Task Completion
|
||||||
|
|
||||||
|
Steps and commands to execute when validating code changes or knowledge-base updates.
|
||||||
|
|
||||||
|
## Verification Checklist
|
||||||
|
|
||||||
|
1. **Broken Link Check**: Ensure all newly added `[[WikiLinks]]` are accurate and point to existing files.
|
||||||
|
2. **Kebab-Case Naming**: Verify all created concept or entity files are named in kebab-case.
|
||||||
|
3. **UTF-8 Encoding**: Ensure modified and created markdown files are written in UTF-8 format.
|
||||||
|
4. **Consistency Script**: Run the text replacement script if naming or file paths were updated:
|
||||||
|
```powershell
|
||||||
|
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\replace_knowledge.ps1
|
||||||
|
```
|
||||||
|
5. **Memory Reference Checks**: Validate Serena onboarding memories using:
|
||||||
|
```powershell
|
||||||
|
serena memories check
|
||||||
|
```
|
||||||
|
6. **Git Cleanliness**: Run `git status` to ensure only intended changes are modified and no unintended files are staged.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
# Tech Stack
|
||||||
|
|
||||||
|
Technical details and tools used in the LLM Knowledge Base repository.
|
||||||
|
|
||||||
|
## Environment & Platform
|
||||||
|
|
||||||
|
- **Operating System**: Windows (win32)
|
||||||
|
- **Primary Shell**: PowerShell
|
||||||
|
|
||||||
|
## Core Technologies
|
||||||
|
|
||||||
|
- **Content Format**: GitHub Flavored Markdown (GFM).
|
||||||
|
- **Encoding**: UTF-8.
|
||||||
|
- **PKM UI**: Obsidian (recommended local viewer and graph visualizer).
|
||||||
|
- **Agent Orchestrator**: Gemini CLI (used for parsing raw files, maintaining links, updating synthesis pages).
|
||||||
|
|
||||||
|
## Versioning & Configuration
|
||||||
|
|
||||||
|
- No compilers, compilers pins, or heavy framework dependencies.
|
||||||
|
- Git is used for version control of the markdown files, allowing revision history and branching.
|
||||||
|
- Local custom script: `replace_knowledge.ps1` handles codebase-wide text replacements (specifically migrating old "wiki" terminology to "knowledge").
|
||||||
@@ -0,0 +1,133 @@
|
|||||||
|
# the name by which the project can be referenced within Serena
|
||||||
|
project_name: "brain"
|
||||||
|
|
||||||
|
|
||||||
|
# list of languages for which language servers are started; choose from:
|
||||||
|
# al angular ansible bash clojure
|
||||||
|
# cpp cpp_ccls crystal csharp csharp_omnisharp
|
||||||
|
# dart elixir elm erlang fortran
|
||||||
|
# fsharp go groovy haskell haxe
|
||||||
|
# hlsl html java json julia
|
||||||
|
# kotlin lean4 lua luau markdown
|
||||||
|
# matlab msl nix ocaml pascal
|
||||||
|
# perl php php_phpactor powershell python
|
||||||
|
# python_jedi python_ty r rego ruby
|
||||||
|
# ruby_solargraph rust scala scss solidity
|
||||||
|
# svelte swift systemverilog terraform toml
|
||||||
|
# typescript typescript_vts vue yaml zig
|
||||||
|
# (This list may be outdated. For the current list, see values of Language enum here:
|
||||||
|
# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py
|
||||||
|
# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
|
||||||
|
# Note:
|
||||||
|
# - For C, use cpp
|
||||||
|
# - For JavaScript, use typescript
|
||||||
|
# - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
|
||||||
|
# - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
|
||||||
|
# - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
|
||||||
|
# - For Free Pascal/Lazarus, use pascal
|
||||||
|
# Special requirements:
|
||||||
|
# Some languages require additional setup/installations.
|
||||||
|
# See here for details: https://oraios.github.io/serena/01-about/020_programming-languages.html#language-servers
|
||||||
|
# When using multiple languages, the first language server that supports a given file will be used for that file.
|
||||||
|
# The first language is the default language and the respective language server will be used as a fallback.
|
||||||
|
# Note that when using the JetBrains backend, language servers are not used and this list is correspondingly ignored.
|
||||||
|
languages:
|
||||||
|
- powershell
|
||||||
|
|
||||||
|
# the encoding used by text files in the project
|
||||||
|
# For a list of possible encodings, see https://docs.python.org/3.11/library/codecs.html#standard-encodings
|
||||||
|
encoding: "utf-8"
|
||||||
|
|
||||||
|
# line ending convention to use when writing source files.
|
||||||
|
# Possible values: unset (use global setting), "lf", "crlf", or "native" (platform default)
|
||||||
|
# This does not affect Serena's own files (e.g. memories and configuration files), which always use native line endings.
|
||||||
|
line_ending:
|
||||||
|
|
||||||
|
# The language backend to use for this project.
|
||||||
|
# If not set, the global setting from serena_config.yml is used.
|
||||||
|
# Valid values: LSP, JetBrains
|
||||||
|
# Note: the backend is fixed at startup. If a project with a different backend
|
||||||
|
# is activated post-init, an error will be returned.
|
||||||
|
language_backend:
|
||||||
|
|
||||||
|
# whether to use project's .gitignore files to ignore files
|
||||||
|
ignore_all_files_in_gitignore: true
|
||||||
|
|
||||||
|
# advanced configuration option allowing to configure language server-specific options.
|
||||||
|
# Maps the language key to the options.
|
||||||
|
# Have a look at the docstring of the constructors of the LS implementations within solidlsp (e.g., for C# or PHP) to see which options are available.
|
||||||
|
# No documentation on options means no options are available.
|
||||||
|
ls_specific_settings: {}
|
||||||
|
|
||||||
|
# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos).
|
||||||
|
# Paths can be absolute or relative to the project root.
|
||||||
|
# Each folder is registered as an LSP workspace folder, enabling language servers to discover
|
||||||
|
# symbols and references across package boundaries.
|
||||||
|
# Currently supported for: TypeScript.
|
||||||
|
# Example:
|
||||||
|
# additional_workspace_folders:
|
||||||
|
# - ../sibling-package
|
||||||
|
# - ../shared-lib
|
||||||
|
additional_workspace_folders: []
|
||||||
|
|
||||||
|
# list of additional paths to ignore in this project.
|
||||||
|
# Same syntax as gitignore, so you can use * and **.
|
||||||
|
# Note: global ignored_paths from serena_config.yml are also applied additively.
|
||||||
|
ignored_paths: []
|
||||||
|
|
||||||
|
# whether the project is in read-only mode
|
||||||
|
# If set to true, all editing tools will be disabled and attempts to use them will result in an error
|
||||||
|
# Added on 2025-04-18
|
||||||
|
read_only: false
|
||||||
|
|
||||||
|
# list of tool names to exclude.
|
||||||
|
# This extends the existing exclusions (e.g. from the global configuration)
|
||||||
|
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||||||
|
excluded_tools: []
|
||||||
|
|
||||||
|
# list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
|
||||||
|
# This extends the existing inclusions (e.g. from the global configuration).
|
||||||
|
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||||||
|
included_optional_tools: []
|
||||||
|
|
||||||
|
# fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
|
||||||
|
# This cannot be combined with non-empty excluded_tools or included_optional_tools.
|
||||||
|
# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
|
||||||
|
fixed_tools: []
|
||||||
|
|
||||||
|
# list of mode names that are to be activated by default, overriding the setting in the global configuration.
|
||||||
|
# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
|
||||||
|
# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
|
||||||
|
# Otherwise, this overrides the setting from the global configuration (serena_config.yml).
|
||||||
|
# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
|
||||||
|
# for this project.
|
||||||
|
# This setting can, in turn, be overridden by CLI parameters (--mode).
|
||||||
|
# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
|
||||||
|
default_modes:
|
||||||
|
|
||||||
|
# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
|
||||||
|
# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
|
||||||
|
# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
|
||||||
|
added_modes:
|
||||||
|
|
||||||
|
# initial prompt for the project. It will always be given to the LLM upon activating the project
|
||||||
|
# (contrary to the memories, which are loaded on demand).
|
||||||
|
initial_prompt: ""
|
||||||
|
|
||||||
|
# time budget (seconds) per tool call for the retrieval of additional symbol information
|
||||||
|
# such as docstrings or parameter information.
|
||||||
|
# This overrides the corresponding setting in the global configuration; see the documentation there.
|
||||||
|
# If null or missing, use the setting from the global configuration.
|
||||||
|
symbol_info_budget:
|
||||||
|
|
||||||
|
# list of regex patterns which, when matched, mark a memory entry as read‑only.
|
||||||
|
# Extends the list from the global configuration, merging the two lists.
|
||||||
|
read_only_memory_patterns: []
|
||||||
|
|
||||||
|
# list of regex patterns for memories to completely ignore.
|
||||||
|
# Matching memories will not appear in list_memories or activate_project output
|
||||||
|
# and cannot be accessed via read_memory or write_memory.
|
||||||
|
# To access ignored memory files, use the read_file tool on the raw file path.
|
||||||
|
# Extends the list from the global configuration, merging the two lists.
|
||||||
|
# Example: ["_archive/.*", "_episodes/.*"]
|
||||||
|
ignored_memory_patterns: []
|
||||||
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Budowanie knowledge badawczej LLM: Jak przekształciłem 3000 stron filozofii w żywy system wiedzy"
|
||||||
|
type: "summary"
|
||||||
|
tags: [karpathy, llm-knowledge, continental-philosophy, claude-code, multi-agent, epistemic-markers, scaling]
|
||||||
|
created: 2026-06-09
|
||||||
|
updated: 2026-06-09
|
||||||
|
sources: ["raw/inbox/Budowanie knowledge badawczej LLM_ Jak przekształciłem 3000 stron filozofii w żywy system wiedzy.md"]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Budowanie knowledge badawczej LLM: Jak przekształciłem 3000 stron filozofii w żywy system wiedzy
|
||||||
|
|
||||||
|
Artykuł Paula de Assis opisuje praktyczną adaptację modelu LLM Knowledge Base Andreja Karpathy'ego do specyfiki badań naukowych i akademickich w dziedzinie filozofii kontynentalnej i teorii muzyki. Autor wdrożył system oparty na narzędziu Claude Code, tworząc zautomatyzowane ramy do głębokiej syntezy gęstych tekstów źródłowych.
|
||||||
|
|
||||||
|
## Key Points
|
||||||
|
- **Adaptacja dla humanistyki**: Klasyczne bazy techniczne skupiają się na dokumentacji. Praca naukowa w humanistyce wymaga śledzenia pojęć (np. u Deleuze'a, Simondona, Stieglaera) o skomplikowanych i ewoluujących definicjach.
|
||||||
|
- **Wykorzystanie Claude Code**: Terminalowy agent Anthropic działa bezpośrednio na plikach Markdown, stając się "operatorem" bazy wiedzy na podstawie instrukcji z kontraktu `CLAUDE.md`.
|
||||||
|
- **Wieloagentowa orkiestracja**: Konfiguracja systemu została zrealizowana przy użyciu 3 wyspecjalizowanych agentów Claude Code (Koordynator, Strateg migracji biblioteki, Inicjalizator struktury).
|
||||||
|
- **Epistemiczne Markery (Epistemic Markers)**: Przełomowa metoda oznaczania statusu twierdzeń:
|
||||||
|
- *(brak)* — Bezpośrednie twierdzenie z konkretnego źródła pierwotnego.
|
||||||
|
- **[W]** — Synteza wygenerowana przez bazę wiedzy (LLM) z wielu źródeł.
|
||||||
|
- **[P]** — Własna, suwerenna teza badawcza człowieka (Personal stance).
|
||||||
|
- **[?]** — Twierdzenie niepewne lub trudne do jednoznacznego zweryfikowania.
|
||||||
|
- **Kaskada nawigacyjna przeciwko kosztom**: Aby uniknąć liniowego wzrostu kosztów i spowolnienia zapytań przy ponad 180 stronach, autor zastosował kaskadę: Skupiska tematyczne w `index.md` -> Dedykowane strony syntez -> Powiązania YAML sąsiednich pojęć.
|
||||||
|
- **Mnożnik Ingestu**: Średnio jedno źródło aktualizuje lub tworzy 2.6 strony w bazie wiedzy. Gęste monografie potrafią wywołać modyfikacje na nawet 17 stronach (np. dodanie cytatów do stron koncepcyjnych i autorskich).
|
||||||
|
|
||||||
|
## Relevant Concepts
|
||||||
|
- [[concepts/epistemic-markers]] — System precyzyjnego oznaczania rejestru twierdzeń (autor vs LLM vs źródło).
|
||||||
|
- [[concepts/multi-agent-orchestration]] — Orkiestracja pracy wielu agentów przy konfiguracji i utrzymaniu bazy.
|
||||||
|
- [[concepts/knowledge-scaling]] — Metody hierarchizacji nawigacji zapobiegające eksplozji kosztów tokenów.
|
||||||
|
|
||||||
|
## Relevant Entities
|
||||||
|
- [[entities/claude-code]] — Agent CLI będący programistą i operatorem bazy wiedzy.
|
||||||
|
- [[entities/constella]] — Platforma komercjalizująca ten model workflow.
|
||||||
|
|
||||||
|
## Source Metadata
|
||||||
|
- **Type**: Artykuł / Case study akademickie
|
||||||
|
- **Author**: Paulo de Assis
|
||||||
|
- **Date**: 2026-04-17
|
||||||
|
- **URL**: https://medium.com/@paulo.deassis/building-an-llm-research-knowledge-how-i-turned-3-000-pages-of-philosophy-into-a-living-knowledge-609de9935cd9
|
||||||
@@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: "Budowanie osobistego asystenta AI z użyciem SQLite, Claude Code i GTD"
|
||||||
|
type: "summary"
|
||||||
|
tags: [gtd, sqlite, claude-code, local-first, agent-contract, markdown, productivity]
|
||||||
|
created: 2026-06-09
|
||||||
|
updated: 2026-06-09
|
||||||
|
sources: ["raw/inbox/Budowanie osobistego asystenta AI z użyciem SQLite, Claude Code i GTD.md"]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Budowanie osobistego asystenta AI z użyciem SQLite, Claude Code i GTD
|
||||||
|
|
||||||
|
Marc Bara w swoim artykule przedstawia autorski system **MarcOS** — lokalnego asystenta produktywności opartego na metodyce GTD (Getting Things Done). System łączy bazę danych SQLite, lokalny frontend HTML oraz automatyzację napędzaną przez Claude Code, tworząc alternatywę dla scentralizowanych narzędzi SaaS typu Notion.
|
||||||
|
|
||||||
|
## Key Points
|
||||||
|
- **Architektura Local-First**: Dane użytkownika są w 100% lokalne i zapisane w pojedynczym pliku SQLite (`gtd.db`) zlokalizowanym w folderze Dropbox.
|
||||||
|
- **Ścisła Hierarchia Danych**: Baza opiera się na twardej strukturze: Klient -> Projekt -> Zadanie -> Faktura. Zapobiega to gubieniu kontekstu i rozpraszaniu zadań.
|
||||||
|
- **Podział na Dashboard i Agenta (Zero-Token Daily View)**:
|
||||||
|
- Codzienne interakcje (oś czasu, kalendarz, zadania) odbywają się na lokalnym pulpicie HTML za pomocą `sql.js` (SQLite w WebAssembly) bez użycia tokenów LLM.
|
||||||
|
- Claude Code wkracza wyłącznie do zadań wymagających analizy języka naturalnego: cotygodniowe przeglądy, parsowanie maili ze skrzynki, automatyczne generowanie faktur PDF i harmonogramowanie zadań.
|
||||||
|
- **Git dla Danych Tekstowych**: Zamiast wersjonować binarny plik `.db`, skrypt co godzinę wykonuje tekstowy zrzut SQL (`gtd.sql`), który jest śledzony przez Gita, umożliwiając łatwy podgląd historii zmian (diffs).
|
||||||
|
- **Kontrakt i Pamięć Długoterminowa**:
|
||||||
|
- `CLAUDE.md` definiuje schemat bazy, zasady bezpieczeństwa oraz reguły zachowania agenta.
|
||||||
|
- `memory.md` służy do zapisywania trwałych preferencji i wiedzy operacyjnej o użytkowniku (np. nawyki kalendarzowe, charakterystyka klientów), co eliminuje bezstanowość sesji LLM.
|
||||||
|
|
||||||
|
## Relevant Concepts
|
||||||
|
- [[concepts/local-first-ai]] — Projektowanie asystentów działających na lokalnych zasobach użytkownika.
|
||||||
|
- [[concepts/agent-contracts]] — CLAUDE.md jako zbiór nienaruszalnych zasad i ograniczeń dla agenta CLI.
|
||||||
|
- [[concepts/gtd-ai]] — Integracja klasycznych metodyk organizacji pracy (GTD) z możliwościami generatywnego AI.
|
||||||
|
|
||||||
|
## Relevant Entities
|
||||||
|
- [[entities/sqlite]] — Lekka, bezserwerowa baza danych.
|
||||||
|
- [[entities/sql-js]] — Port SQLite do WebAssembly na frontendzie.
|
||||||
|
- [[entities/claude-code]] — Narzędzie CLI obsługujące automatyzację GTD.
|
||||||
|
|
||||||
|
## Source Metadata
|
||||||
|
- **Type**: Artykuł / Poradnik techniczny
|
||||||
|
- **Author**: Marc Bara
|
||||||
|
- **Date**: 2026-03-14
|
||||||
|
- **URL**: https://medium.com/@marc.bara.iniesta/building-a-personal-ai-assistant-with-sqlite-claude-code-and-gtd-0ae12dc18d3e
|
||||||
@@ -0,0 +1,35 @@
|
|||||||
|
---
|
||||||
|
title: "Karpathy LLM Knowledge Base to supermoc dla badaczy. Oto jak go używam."
|
||||||
|
type: "summary"
|
||||||
|
tags: [karpathy, llm-knowledge, research, pkm, obsidian, RAG]
|
||||||
|
created: 2026-06-09
|
||||||
|
updated: 2026-06-09
|
||||||
|
sources: ["raw/inbox/Karpathy LLM knowledge to supermoc dla badaczy. Oto jak go używam..md"]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Karpathy LLM Knowledge Base to supermoc dla badaczy. Oto jak go używam.
|
||||||
|
|
||||||
|
Artykuł autorstwa R.F. Bryana analizuje rewolucyjny wpływ koncepcji "LLM Knowledge Base" Andreja Karpathy'ego na pracę naukową i badawczą. Autor przeciwstawia tradycyjne, jednorazowe sesje czatu z modelami językowymi oraz standardowe systemy RAG długoterminowemu budowaniu spójnej, trwałej, "skompilowanej" bazy wiedzy.
|
||||||
|
|
||||||
|
## Key Points
|
||||||
|
- **Kompilator wiedzy**: Baza wiedzy nie jest tylko zbiorem notatek, lecz "skompilowaną" strukturą danych. LLM działa jak kompilator, przekształcając surowe materiały (artykuly, PDF-y, transkrypcje) w uporządkowane, powiązane pliki Markdown.
|
||||||
|
- **Problem standardowego RAG / czatu**: Klasyczne interfejsy czatu zapominają o poprzednich interakcjach i nie potrafią łączyć nowo czytanego artykułu z materiałami sprzed tygodnia. RAG świetnie wyszukuje izolowane fakty, lecz zawodzi przy wieloźródłowej syntezie.
|
||||||
|
- **Obsidian jako "IDE"**: Obsidian pełni funkcję interfejsu (frontendu) do czytania i nawigacji, podczas gdy LLM działa w tle jako "programista" i administrator dbający o relacje między dokumentami.
|
||||||
|
- **Moc "lintingu"**: Cykliczne sprawdzanie spójności bazy przez LLM (znajdowanie "sierot", niespójności metodologicznych oraz luk merytorycznych) to krytyczny i niedoceniany krok w utrzymaniu jakości wiedzy.
|
||||||
|
- **Zasada GIGO (Garbage In, Organized Garbage Out)**: Jakość wyjściowej syntezy zależy całkowicie od selekcji wprowadzanych źródeł oraz dyscypliny w regularnym uzupełnianiu bazy.
|
||||||
|
|
||||||
|
## Relevant Concepts
|
||||||
|
- [[concepts/knowledge-compilation]] — Model kompilacji surowej wiedzy do bazy danych.
|
||||||
|
- [[concepts/compounding-knowledge]] — Efekt procentu składanego w wiedzy: im większa baza, tym cenniejsze staje się każde nowe źródło.
|
||||||
|
- [[concepts/rag-vs-knowledge]] — Zderzenie klasycznego RAG z trwałym repozytorium wiedzy.
|
||||||
|
- [[concepts/knowledge-graph-analysis]] — Badanie bazy jako grafu wiedzy w celu wyszukiwania niespójności i luk.
|
||||||
|
|
||||||
|
## Relevant Entities
|
||||||
|
- [[entities/obsidian]] — Wizualny frontend bazy wiedzy.
|
||||||
|
|
||||||
|
## Source Metadata
|
||||||
|
- **Type**: Artykuł / Analiza badawcza
|
||||||
|
- **Author**: R.F. Bryan
|
||||||
|
- **Date**: 2026-05-11
|
||||||
|
- **URL**: https://medium.com/below-the-abstract/karpathy-llm-knowledge-is-a-superpower-for-researchers-heres-how-i-use-it-cf3db8d24ce1
|
||||||
@@ -0,0 +1,39 @@
|
|||||||
|
---
|
||||||
|
title: "Your Obsidian Vault Is a Knowledge Graph. Here’s How to Make It Think (quickly)."
|
||||||
|
type: "summary"
|
||||||
|
tags: [obsidian, knowledge-graph, claude-code, mcp, graph-metrics, pkm]
|
||||||
|
created: 2026-06-09
|
||||||
|
updated: 2026-06-09
|
||||||
|
sources: ["raw/inbox/Your Obsidian Vault Is a Knowledge Graph. Here’s How to Make It Think (quickly)..md"]
|
||||||
|
confidence: high
|
||||||
|
---
|
||||||
|
|
||||||
|
# Your Obsidian Vault Is a Knowledge Graph. Here’s How to Make It Think (quickly).
|
||||||
|
|
||||||
|
Artykuł Aleksandra Szereszewskiego opisuje koncepcję traktowania bazy notatek Obsidian jako aktywnego grafu wiedzy (Knowledge Graph) i uwalniania jej potencjału za pomocą Claude Code oraz protokołu MCP (Model Context Protocol). Autor dzieli się doświadczeniami z pięciu lat prowadzenia skarbca zawierającego ponad 5 000 notatek.
|
||||||
|
|
||||||
|
## Key Points
|
||||||
|
- **Skarbiec jako Graf**: Notatki w Obsidianie to węzły (nodes), WikiLinki `[[link]]` to krawędzie skierowane (edges), a tagi i właściwości frontmatter to atrybuty węzłów.
|
||||||
|
- **Obsidian to Codebase**: Claude Code doskonale radzi sobie ze skarbem Obsidianu, ponieważ traktuje notatki Markdown jak pliki kodu źródłowego, a linki jak instrukcje importu.
|
||||||
|
- **Rola CLAUDE.md**: Pełni rolę stałego dokumentu wdrożeniowego (kontraktu) dla agenta, definiując strukturę (Projects, Areas, Resources, Archive), konwencje linkowania i tagowania oraz bezwzględne reguły bezpieczeństwa (np. zakaz modyfikacji szablonów i załączników).
|
||||||
|
- **Optymalizacja za pomocą MCP**: Aby uniknąć powolnego wyszukiwania i marnowania tokenów w dużych skarbcach, wykorzystuje się serwery MCP (np. MCPVault lub TurboVault), które udostępniają skarbiec jako ustrukturyzowaną bazę danych grafowych.
|
||||||
|
- **Analiza Metryk Grafowych**:
|
||||||
|
- **Centrality ranking (Ranking centralności)**: Identyfikuje prawdziwe pojęcia-huby w bazie (które często różnią się od sztucznych folderów czy Map Zawartości).
|
||||||
|
- **Detekcja sierot (Orphan detection)**: Wyszukiwanie notatek bez linków wchodzących i wychodzących, ułatwiające archiwizację lub integrację zapomnianych idei.
|
||||||
|
- **Analiza klastrów (Cluster analysis)**: Ujawnianie odizolowanych wysp wiedzy i znajdowanie brakujących połączeń między bliskimi domenami.
|
||||||
|
- **Bridge notes (Notatki mostkowe)**: Identyfikowanie pojęć łączących odległe dziedziny, co często stanowi źródło najbardziej unikalnych i kreatywnych spostrzeżeń.
|
||||||
|
|
||||||
|
## Relevant Concepts
|
||||||
|
- [[concepts/knowledge-graph-analysis]] — Zastosowanie algorytmów grafowych do optymalizacji bazy notatek.
|
||||||
|
- [[concepts/mcp-servers]] — Standardy komunikacji i dostarczania ustrukturyzowanych narzędzi dla LLM.
|
||||||
|
|
||||||
|
## Relevant Entities
|
||||||
|
- [[entities/obsidian]] — Osobiste narzędzie PKM i wizualizator grafu.
|
||||||
|
- [[entities/claude-code]] — Agent CLI operujący bezpośrednio na notatkach.
|
||||||
|
- [[entities/mcpvault]] — Specjalizowany serwer MCP dedykowany do obsługi skarbców Obsidian.
|
||||||
|
|
||||||
|
## Source Metadata
|
||||||
|
- **Type**: Artykuł / Analiza PKM
|
||||||
|
- **Author**: Aleksander Szereszewski
|
||||||
|
- **Date**: 2026-04-11
|
||||||
|
- **URL**: https://medium.com/graph-praxis/your-obsidian-vault-is-a-knowledge-graph-heres-how-to-make-it-think-quickly-1487614a7682
|
||||||
Reference in New Issue
Block a user