## Kontekst projektu

Maszyna: Linux, /root/claude/ jako główny katalog roboczy.
RAM: 961MB (mało), swap 2GB dodany dziś.

## Struktura repo

/root/claude/repo/
├── mcp_helpers/        — biblioteka pomocnicza (code_updater, signed_tool)
├── mcp_files/          — serwer MCP do operacji na plikach
├── mcp_gateway/        — gateway agregujący wiele backendów MCP
└── agent0/             — klient MCP + Claude API  ← TU JESTEŚMY

## Co zostało zrobione

### mcp_helpers
- Przemianowano file_tool.py → code_updater.py, add_file_tools → add_code_updater
- add_code_updater(mcp, __file__) rejestruje 2 toole: readCode() i updateCode(new_code)
- updateCode zapisuje nowy kod i restartuje serwer przez os.execv (z asyncio.sleep(1.0) przed restartem)
- Testy: test_code_updater.py (unit, async, z mock asyncio), test_integration_update.py (e2e z prawdziwym serwerem)
- venv: /root/claude/repo/mcp_helpers/.venv (ma fastmcp, mcp, uvicorn)
- Test runner: /root/claude/repo/.venv/bin/python -m pytest

### mcp_files
- Dodano add_code_updater(mcp, __file__) — serwer MCP plików teraz można updatować zdalnie przez MCP
- requirements.txt: dodano cryptography>=42.0.0

### mcp_gateway
- Dodano aktywny monitoring połączeń do backendów
- _ConnectionWorker: wykrywa nieoczekiwane rozłączenie (flaga _connected + finally + on_disconnect callback)
- ConnectionPool: set_on_disconnect(callback), _handle_disconnect(backend_id)
- Orchestrator:
  - _handle_disconnect: usuwa toole z Registry (zachowuje backend), notyfikuje gateway (Claude widzi zmiany), startuje _reconnect_loop
  - _reconnect_loop: co 5s (RECONNECT_INTERVAL) próbuje połączyć, po sukcesie przywraca toole i notyfikuje
  - remove_backend: anuluje pending reconnect task
- Registry: dodano remove_backend_tools() i has_backend()
- Testy: 18 testów, wszystkie przechodzą

### agent0 — OSTATNIA ZMIANA, NIE PRZETESTOWANA
Plik: /root/claude/agent0/client.py

Zrobiono: przepisano żeby był odporny na restart mcp_gateway.

Zmiany względem oryginału:
1. Dodano zewnętrzną pętlę reconnect (while True)
2. Dodano _is_connection_error() — odróżnia błędy połączenia od logiki
3. first_connect flag — pierwsze połączenie pokazuje powitanie, kolejne "[Ponownie połączono]"
4. Historia messages zachowana między reconnectami
5. Usunięto except* z __main__ — logika przeniesiona do run()
6. RECONNECT_INTERVAL = 3.0 sekund

## Co zostało do zrobienia

Użytkownik zapytał czy można napisać testy dla agent0 i zaraz przerwał.

### Zadanie do kontynuacji: napisać testy dla agent0/client.py

Co warto przetestować:
- _is_connection_error() — różne typy wyjątków
- reconnect loop: gdy gateway pada → klient czeka i próbuje ponownie
- historia messages zachowana po reconnect
- on_notification aktualizuje tools_dirty
- normalne zakończenie przez KeyboardInterrupt / EOFError

Uwagi techniczne:
- client.py używa input() w run_in_executor — w testach trzeba mockować
- streamable_http_client to context manager — mockować przez AsyncMock
- ClientSession.initialize(), list_tools(), call_tool() — mockować
- Można użyć pytest-asyncio (już zainstalowany w /root/claude/repo/.venv)
- agent0 nie ma własnego venv — zainstalować deps lub użyć systemowego pythona

Aby uruchomić testy (gdy zostaną napisane):
cd /root/claude/agent0
python -m pytest tests/ -v
# lub z repo venv:
/root/claude/repo/.venv/bin/python -m pytest tests/ -v

## Komendy do uruchamiania testów (istniejących)
cd /root/claude/repo
.venv/bin/python -m pytest mcp_helpers/tests/test_code_updater.py -v
.venv/bin/python -m pytest mcp_helpers/tests/test_integration_update.py -v
cd /root/claude/repo/mcp_gateway
.venv/bin/python -m pytest tests/ -v
