Jun 9, 2026, 4:06 PM
This commit is contained in:
Paweł Domański
@@ -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: []
|
||||
Reference in New Issue
Block a user