Clean up memories and move system prompt info to critical_info memory

.serena/memories/conventions.md

@@ -1,32 +0,0 @@
-# Conventions
-
-## Style (project-instructed)
-- Idiomatic, object-oriented design. Non-trivial interfaces use **explicitly typed abstractions** (strategy pattern etc.) rather than bare functions/callbacks.
-- Avoid low-level data structures where an OO abstraction fits. For simple data containers use **dataclasses**, not dicts/tuples.
-- Structure function bodies into **functional blocks separated by blank lines**, each prefixed with a short elliptical phrase (lowercase, no leading capital) describing the block's purpose.
-- **Docstrings: reStructuredText.** Param/return/raises use `:param x:`, `:return:`, `:raises X:`.
-- Parameter / method / class descriptions begin with a precise elliptical phrase defining *what* the thing is; details in subsequent sentences.
-
-## Formatting / lint (ruff)
-- Line length 140, double quotes, target `py311`.
-- Many "annoying" rules are disabled — see `[tool.ruff.lint] ignore` in `pyproject.toml` before adding workarounds (e.g. `Optional[T]` is preferred over `T | None`, `Union` is allowed, relative imports forbidden, `% string formatting` allowed).
-- `ruff format` runs on `src scripts test`; same set for `ruff check`.
-- mccabe complexity cap: 20.
-
-## Typing (ty)
-- Type checker is **ty** (Astral), configured under `[tool.ty]` in `pyproject.toml`.
-  
-## Tests
-- Language-server tests are pytest-marker-gated (one marker per language; see `pyproject.toml` `[tool.pytest.ini_options].markers`). Default `poe test` runs unmarked tests + whatever `PYTEST_MARKERS` selects.
-- Snapshot tests use **syrupy** with custom `--snapshot-patch-pycharm-diff` plugin (auto-added via `addopts`).
-
-## Tool descriptions (LLM-facing)
-- To change how a tool is described to the model, edit the Tool class's `apply()` **docstring** (in
-  `src/serena/tools/*.py`) — `make_mcp_tool` parses the docstring body + `:param:` lines into the MCP tool
-  description/schema. Do NOT use `tool_description_overrides` in context ymls (e.g. `claude-code.yml`); the
-  docstring is the single source of truth and overrides drift. Keep `:param:` lines accurate.
-
-## Memories
-- Follow `mem:memory_maintenance` for any new/updated memory in `.serena/memories/`.
-- Durable knowledge goes in memories/docs (not the assistant's auto-memory); see the monorepo top-level
-  `CLAUDE.md` for the cross-repo conventions (no benchmark-tuning of agent-facing strings, etc.).

.serena/memories/critical_info.md

@@ -0,0 +1,48 @@
+# Software Design
+
+IMPORTANT: You use an idiomatic, object-oriented style (Java-esque principles, Pythonic syntax and constructs).
+
+* You keep each concern in exactly one home.
+  A mechanism whose parts are only correct in combination is implemented as a single component/class, and its parts are private to it;
+  expose a minimal public surface. Java-like encapsulation: If helper functions and constants are only used by one abstraction,
+  make them internal to the respective class.
+* You enforce invariants through structure and visibility; interfaces should not permit states the design forbids.
+* For any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions
+  rather than mere functions (i.e. use the strategy pattern, for example).
+  You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate.
+  For simple data storage, you use dataclasses instead of dictionaries or tuples.
+
+# Testing
+
+The key principle is to test *only* externally observable behavior and guarantees, never implementation structure.
+* Litmus test: a behaviour-preserving refactoring must not break any test. A test that could break is wrong and must not be written.
+* When functionality is removed, you delete its tests. You never add tests asserting the *absence* of something;
+  absence of an implementation detail is not a behaviour, and such tests only freeze the current implementation and burden maintenance.
+* Fewer, behaviour-anchored tests are preferred; a missing test is better than an implementation-coupled one.
+
+Language-server tests are pytest-marker-gated (one marker per language; see `pyproject.toml` `[tool.pytest.ini_options].markers`). Default `poe test` runs unmarked tests + whatever `PYTEST_MARKERS` selects.
+Snapshot tests use syrupy.
+
+# Docstrings & Comments
+
+* You consistently use reStructuredText.
+* You structure function implementations into functional blocks that are separated by blank lines.
+  Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the
+  block in a concise manner.
+* When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase
+  clearly defines *what* it is. Any details then follow in subsequent sentences.
+* Each piece of information appears exactly once, at the element that owns it: callers do not
+  explain callees' internals, and callees do not describe their callers.
+
+# Pull requests
+
+Read `mem:creating_pull_requests` when asked to participate in the creation of a pull request.
+
+# Memories
+
+- Follow `mem:memory_maintenance` for any new/updated memory in `.serena/memories/`.
+- Durable project knowledge goes into memories or docs/
+
+# Dev Tools
+
+Read `mem:task_completion` for tools to call upon task completion.

.serena/memories/memory_maintenance.md

@@ -4,7 +4,7 @@
 
 - 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).
+- Agents should read `mem:critical_info` 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.

.serena/memories/project_structure.md

@@ -18,12 +18,10 @@ Serena is an MCP-based "IDE for coding agents": semantic code retrieval/editing/
 - `test/serena/`, `test/solidlsp/<lang>/` — pytest suites; per-language tests gated by pytest markers
 - `test/resources/repos/<lang>/` — fixture projects used by language-server tests
 - `scripts/` — utilities (prompt regen, tool overview, profiling, agno agent)
-- `docs/` — Jupyter Book sources; build via poe `doc-build`
+- `docs/` — Jupyter Book sources; build via `poe doc-build`
 
 ## Project-wide invariants
 
-- Package name (PyPI): `serena-agent`; import root: `serena`. Wheel includes `serena`, `interprompt`, `solidlsp`.
+- Package name (PyPI): `serena-agent`; Wheel includes `serena`, `interprompt`, `solidlsp`.
 - Python: `>=3.11, <3.15`. Dependencies are exact-pinned in `pyproject.toml` (uvx installs from git, lockfile ignored — pin exactly).
 - Entry points: `serena` → `serena.cli:top_level`; `serena-hooks` → `serena.hooks:hook_commands`.
-- Per-project state lives under `<project>/.serena/` (config + `memories/` as `.md` files).
-- See `mem:tech_stack`, `mem:suggested_commands`, `mem:conventions`, `mem:task_completion`.

.serena/memories/serena_repository_structure.md

@@ -1,113 +0,0 @@
-# Serena Repository Structure
-
-## Overview
-Serena is a multi-language code assistant that combines two main components:
-1. **Serena Core** - The main agent framework with tools and MCP server
-2. **SolidLSP** - A unified Language Server Protocol wrapper for multiple programming languages
-
-## Top-Level Structure
-
-```
-serena/
-├── src/                          # Main source code
-│   ├── serena/                   # Serena agent framework
-│   ├── solidlsp/                 # LSP wrapper library  
-│   └── interprompt/              # Multi-language prompt templates
-├── test/                         # Test suites
-│   ├── serena/                   # Serena agent tests
-│   ├── solidlsp/                 # Language server tests
-│   └── resources/repos/          # Test repositories for each language
-├── scripts/                      # Build and utility scripts
-├── resources/                    # Static resources and configurations
-├── pyproject.toml               # Python project configuration
-├── README.md                    # Project documentation
-└── CHANGELOG.md                 # Version history
-```
-
-## Source Code Organization
-
-### Serena Core (`src/serena/`)
-- **`agent.py`** - Main SerenaAgent class that orchestrates everything
-- **`tools/`** - MCP tools for file operations, symbols, memory, etc.
-  - `file_tools.py` - File system operations (read, write, search)
-  - `symbol_tools.py` - Symbol-based code operations (find, edit)
-  - `memory_tools.py` - Knowledge persistence and retrieval
-  - `config_tools.py` - Project and mode management
-  - `workflow_tools.py` - Onboarding and meta-operations
-- **`config/`** - Configuration management
-  - `serena_config.py` - Main configuration classes
-  - `context_mode.py` - Context and mode definitions
-- **`util/`** - Utility modules
-- **`mcp.py`** - MCP server implementation
-- **`cli.py`** - Command-line interface
-
-### SolidLSP (`src/solidlsp/`)
-- **`ls.py`** - Main SolidLanguageServer class
-- **`language_servers/`** - Language-specific implementations
-  - `csharp_language_server.py` - C# (Microsoft.CodeAnalysis.LanguageServer)
-  - `python_server.py` - Python (Pyright)
-  - `typescript_language_server.py` - TypeScript
-  - `rust_analyzer.py` - Rust
-  - `gopls.py` - Go
-  - And many more...
-- **`ls_config.py`** - Language server configuration
-- **`ls_types.py`** - LSP type definitions
-- **`ls_utils.py`** - Utilities for working with LSP data
-
-### Interprompt (`src/interprompt/`)
-- Multi-language prompt template system
-- Jinja2-based templating with language fallbacks
-
-## Test Structure
-
-### Language Server Tests (`test/solidlsp/`)
-Each language has its own test directory:
-```
-test/solidlsp/
-├── csharp/
-│   └── test_csharp_basic.py
-├── python/
-│   └── test_python_basic.py
-├── typescript/
-│   └── test_typescript_basic.py
-└── ...
-```
-
-### Test Resources (`test/resources/repos/`)
-Contains minimal test projects for each language:
-```
-test/resources/repos/
-├── csharp/test_repo/
-│   ├── serena.sln
-│   ├── TestProject.csproj
-│   ├── Program.cs
-│   └── Models/Person.cs
-├── python/test_repo/
-├── typescript/test_repo/
-└── ...
-```
-
-### Test Infrastructure
-- **`test/conftest.py`** - Shared test fixtures and utilities
-- **`create_ls()`** function - Creates language server instances for testing
-- **`language_server` fixture** - Parametrized fixture for multi-language tests
-
-## Key Configuration Files
-
-- **`pyproject.toml`** - Python dependencies, build config, and tool settings
-- **`.serena/`** directories - Project-specific Serena configuration and memories
-- **`CLAUDE.md`** - Instructions for AI assistants working on the project
-
-## Dependencies Management
-
-The project uses modern Python tooling:
-- **uv** for fast dependency resolution and virtual environments
-- **pytest** for testing with language-specific markers (`@pytest.mark.csharp`)
-- **ruff** for linting and formatting
-- **ty** (Astral) for type checking
-
-## Build and Development
-
-- **Docker support** - Full containerized development environment
-- **GitHub Actions** - CI/CD with language server testing
-- **Development scripts** in `scripts/` directory

.serena/memories/suggested_commands.md

@@ -1,24 +0,0 @@
-# Suggested Commands
-
-Run via `uv run poe <task>` (or `poe <task>` inside the activated venv). Poe executor is `simple`, so plain `poe` works without uv re-resolving.
-
-## Dev loop
-- `poe test` — pytest on `test/` (per-language tests are marker-gated; pass `-m <marker>` to enable).
-- `poe lint` — ruff format-check + ruff check (no fixes).
-- `poe format` — ruff `--fix` then `ruff format` (mutates files).
-- `poe type-check` — ty on `src/serena`, `src/solidlsp`, and `test/` (test pass relaxes pytest/mock-noisy rules via `[[tool.ty.overrides]]`).
-- Single test file: `uv run pytest test/path/to/test_x.py -vv`. Language-gated: add `-m python` etc.
-
-## Docs
-- `poe doc-build` — clean + autogen + sphinx (uses `rm -rf`; needs a unix-like shell, e.g. Git Bash on Windows).
-
-## Entrypoints
-- `uv run serena ...` — main CLI (`serena.cli:top_level`).
-- `uv run serena-hooks ...` — hook helpers.
-- `python scripts/gen_prompt_factory.py` — regenerate `src/serena/generated/generated_prompt_factory.py` after editing prompt templates.
-
-## Windows shell notes (PowerShell 7+ is the project shell)
-- Use `Remove-Item -Recurse -Force <path>` instead of `rm -rf` (the `doc-clean` poe task uses unix `rm -rf` and requires bash).
-- Env vars: `$env:NAME = 'value'` (not `export`).
-- Path separator in `pyproject.toml` poe tasks uses forward slashes; PowerShell accepts them in arguments.
-- `git`, `uv`, `poe`, `pytest` behave identically to unix.

.serena/memories/task_completion.md

@@ -8,4 +8,4 @@ After any code change in `src/` or `test/`, run:
 
 If prompt templates changed: `uv run python scripts/gen_prompt_factory.py` (regenerates `src/serena/generated/generated_prompt_factory.py`; use `uv run poe format` and commit the result).
 
-If memories were edited/renamed/split: run `uv run serena memories check` from the project root to find broken `mem:` references.
+If memories were edited/renamed/split: run `uv run --no-sync serena memories check` from the project root to find broken `mem:` references.

.serena/memories/tech_stack.md

@@ -1,10 +0,0 @@
-# Tech Stack
-
-- Language: Python 3.11–3.14 (`requires-python = ">=3.11, <3.15"`).
-- Package/dep manager: **uv** (uv.lock present). Exact version pins in `pyproject.toml` because `uvx` installs from git and ignores the lockfile.
-- Build backend: `hatchling`. Packages: `src/serena`, `src/interprompt`, `src/solidlsp`.
-- Task runner: **poethepoet** (`poe <task>`). Poe executor is `simple` (does NOT shell out via uv) — avoids env recreation while MCP server is running.
-- Key runtime deps: `mcp`, `flask` (dashboard), `pydantic`, `pygls` + `lsprotocol` (LSP), `anthropic`, `jinja2`, `ruamel.yaml`, `pywebview`/`pystray` (GUI), `pythonnet` (Windows only).
-- Dev deps: `ruff` (lint+format), `ty` (Astral type checker; replaced mypy), `pytest` (+ `pytest-xdist`, `pytest-timeout`, `syrupy` snapshots), `sphinx`/`jupyter-book` for docs.
-- Optional extras: `agno` (Agno agent integration), `google` (gemini).
-- LSP client core lives under `src/solidlsp/`; one subdir per supported language server under `language_servers/`.

.serena/project.yml

@@ -71,38 +71,7 @@ included_optional_tools: []
 # 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: |
-  IMPORTANT: You use an idiomatic, object-oriented style (Java-esque principles, Pythonic syntax and constructs). 
-
-  Design:
-  * You keep each concern in exactly one home. 
-    A mechanism whose parts are only correct in combination is implemented as a single component/class, and its parts are private to it;
-    expose a minimal public surface. Java-like encapsulation: If helper functions and constants are only used by one abstraction, 
-    make them internal to the respective class.
-  * You enforce invariants through structure and visibility; interfaces should not permit states the design forbids.
-  * For any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions
-    rather than mere functions (i.e. use the strategy pattern, for example).
-    You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate.
-    For simple data storage, you use dataclasses instead of dictionaries or tuples.
-
-  Testing:
-  The key principle is to test *only* externally observable behavior and guarantees, never implementation structure.
-  * Litmus test: a behaviour-preserving refactoring must not break any test. A test that could break is wrong and must not be written.
-  * When functionality is removed, you delete its tests. You never add tests asserting the *absence* of something; 
-    absence of an implementation detail is not a behaviour, and such tests only freeze the current implementation and burden maintenance.
-  * Fewer, behaviour-anchored tests are preferred; a missing test is better than an implementation-coupled one.
-
-  Docstrings & Comments:
-  * You consistently use reStructuredText.
-  * You structure function implementations into functional blocks that are separated by blank lines.
-    Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the 
-    block in a concise manner.
-  * When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase
-    clearly defines *what* it is. Any details then follow in subsequent sentences.
-  * Each piece of information appears exactly once, at the element that owns it: callers do not
-    explain callees' internals, and callees do not describe their callers.
-
-  Pull requests:
-  Read `mem:creating_pull_requests` when asked to participate in the creation of a pull request.
+  ALWAYS read the `critical_info` memory before doing anything else. It contains absolutely critical information about the project.
 
 # 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