pico.save

Jesteś agentem „Codex” w trybie **read mode + plan mode**. Funkcjonalności, o których mowa, **już są wpisane w aplikację**, ale nie wszystkie są poprawnie „spięte” (integracja/przepływy). Masz wyjaśnić **dlaczego pewnych rzeczy nie spinamy** (albo czemu nie warto ich spinać „po staremu”) oraz podać **plan dalszych kroków**, żeby dopiąć minimalny zestaw funkcji znany z poprzedniej wersji — **bez tworzenia duplikatów i bez legacy structów**.

## 1) Opis zadania (z transkryptu)
- Zidentyfikuj minimalne funkcjonalności, które były w poprzedniej wersji i powinny działać teraz.
- Sprawdź, które z nich są już obecne w kodzie, ale nie są połączone (UI ↔ backend ↔ kernel/serwisy).
- Wyjaśnij, dlaczego **nie spinamy** niektórych rzeczy (np. bo są duplikatem, bo istnieje nowy moduł robiący to samo, bo stary przepływ był błędny, bo powoduje legacy).
- Przygotuj plan działań (kolejność kroków/PR) żeby dopiąć MVP funkcji **bez duplikacji** i bez utrwalania starych struktur danych.

## 2) Kontekst wstępny
- Projekt jest w trakcie iteracyjnego porządkowania: są stare ścieżki/duplikacje.
- Priorytet: „single source of truth”, brak dublowania logiki, brak przepisywania pod legacy.
- Celem jest spięcie minimalnych funkcji, a nie rekonstrukcja poprzedniej architektury.

---

## 3) Actionable TODO (checklista)

### Zbadaj kod
- [ ] Wypisz listę „minimalnych funkcjonalności” (MVP) na podstawie poprzedniej wersji: ekrany/komendy/flow.
- [ ] Dla każdej funkcji sprawdź w aktualnym kodzie:
  - gdzie jest logika (moduł/serwis),
  - gdzie jest wywołanie (UI/command/router),
  - gdzie jest brakujące ogniwo (np. brak rejestracji command, brak eventu, brak wstrzyknięcia zależności).
- [ ] Zidentyfikuj obecne moduły, które już realizują te funkcje i mogą być „źródłem prawdy”.
- [ ] Znajdź legacy structy / stare DTO / stare eventy, które kuszą, żeby ich użyć ponownie.
- [ ] Zmapuj duplikacje: jeśli istnieją dwie ścieżki do tego samego celu, opisz je i wskaż, która powinna zostać.

### Przeprowadź implementację (TYLKO PLAN – bez kodu w tym zadaniu)
- [ ] Dla każdej funkcji MVP zaproponuj **jedną** docelową ścieżkę integracji (konkret: jakie moduły, jakie API/commands, jakie typy danych).
- [ ] Ustal zasady „nie spinamy X, bo…”:
  - bo to dubluje nowy moduł,
  - bo prowadzi do legacy structów,
  - bo nowy kontrakt jest inny i trzeba adapter, nie rewire.
- [ ] Zaproponuj plan kolejnych PR-ów:
  1) doprecyzowanie kontraktów (typy/DTO) i usunięcie nieużywanych struktur,
  2) spięcie 1. funkcji end-to-end,
  3) spięcie kolejnych funkcji, każda osobnym PR,
  4) usunięcie duplikatów i dead code po każdym etapie.
- [ ] Zaproponuj minimalny mechanizm kompatybilności, jeśli trzeba (adaptery), ale bez utrwalania legacy.

### Sprawdź integralność (format, lint)
- [ ] Określ komendy format/lint (wg stacku) i dodaj jako „definition of done” dla PR-ów.
- [ ] W planie uwzględnij czyszczenie importów, nieużywanego kodu, dead feature flags.

### Testy (jeśli brak to obowiązkowo napisz)
- [ ] Dla każdej funkcji MVP zaproponuj co najmniej jeden test integracyjny/e2e potwierdzający spięcie end-to-end.
- [ ] Dodaj testy kontraktowe dla granic modułów (żeby nie wróciła duplikacja).
- [ ] Zaproponuj testy regresji tam, gdzie usuwamy starą ścieżkę.

---

## 4) Expected deliverables
1) **Raport „dlaczego nie spinamy X”**: lista decyzji z uzasadnieniem (duplikacja/legacy/błędny przepływ).
2) **Mapa funkcji MVP**: tabela (Funkcja → gdzie jest logika → gdzie brakuje integracji → docelowa ścieżka).
3) **Plan PR-ów**: kolejność, kryteria „done”, jakie pliki/obszary dotykamy.
4) **Plan testów**: co testujemy i jak uruchamiamy.

---

## 5) Report expectation
- Konkretne ścieżki w repo i nazwy modułów.
- Jasne wskazanie „single source of truth”.
- Zero przenoszenia starych struktur danych, jeśli są zbędne — zamiast tego adapter lub nowy kontrakt.

---

## Appendix: tooling + zasady anty–technical debt
**Tooling:**
- `rg` do znajdowania punktów integracji
- `loctree` (jeśli dostępne) do mapy katalogów
- Rust: `cargo fmt`, `cargo clippy`, `cargo test`
- TS: `eslint`, `prettier`, `pnpm test` (jeśli dotyczy)

**Zasady anty–technical debt:**
- Nie dokładamy nowej warstwy „na stare” tylko dlatego, że kiedyś działało.
- Jedna funkcja = jedno źródło prawdy; reszta to wywołania/adaptory.
- Po spięciu funkcji usuń starą ścieżkę i martwe struktury.
- Brak „tymczasowych” duplikatów bez planu usunięcia.

---

**Call to action:**
Przeanalizuj aktualny kod, wskaż które funkcje MVP są już obecne i gdzie brakuje spięcia, wyjaśnij które rewire są zbędne i przygotuj plan dopięcia MVP bez duplikatów i legacy structów.

=======================
**„Duplikat w kodzie to jak drugi pacjent z tą samą kartą — niby szybciej, a potem nikt nie wie, który wynik jest prawdziwy (งಠ_ಠ)ง”**
=======================