init

docs/cross-platform.md

@@ -0,0 +1,282 @@
+# fxg — strategia cross-platform
+
+> Cel: jedna binarka, trzy systemy, instalacja w 30 sekund, zero wiedzy technicznej wymaganej.
+
+---
+
+## Stan obecny
+
+Rust kompiluje się do natywnych binarek bez zewnętrznych zależności runtime. To dobra podstawa — nie trzeba instalować Pythona, Node.js ani JVM. Ale dziś jedynym sposobem instalacji jest `cargo install --path .`, co wymaga zainstalowanego Rusta i środowiska build. Dla grafika — nierealne.
+
+Obecny problem z `keyring`: na Linuksie wymaga `libdbus` lub `libsecret`. Do rozwiązania przy pakowaniu.
+
+---
+
+## Cel UX instalacji
+
+**Windows:** Pobierasz plik `.exe`. Klikasz go dwukrotnie. Otwiera się terminal z konfiguratorem. Po 2 minutach piszesz `fxg status` i to działa.
+
+**Linux:** Wklejasz jedną linię w terminal. Po 10 sekundach piszesz `fxg status` i to działa.
+
+**macOS:** `brew install`. Jedna komenda.
+
+---
+
+## Strategia dystrybucji — GitHub Releases + CI
+
+### GitHub Actions — automatyczne buildowanie binarek
+
+Przy każdym tagu (`v*.*.*`) CI buduje binarkę na 4 targety:
+
+```yaml
+# .github/workflows/release.yml
+strategy:
+  matrix:
+    include:
+      - os: ubuntu-latest
+        target: x86_64-unknown-linux-musl   # statyczna binarka — działa na każdym Linuksie
+        artifact: fxg-linux-x64
+      - os: ubuntu-latest
+        target: aarch64-unknown-linux-musl  # ARM (np. Raspberry Pi, nowe serwery)
+        artifact: fxg-linux-arm64
+      - os: windows-latest
+        target: x86_64-pc-windows-msvc
+        artifact: fxg-windows-x64.exe
+      - os: macos-latest
+        target: x86_64-apple-darwin
+        artifact: fxg-macos-x64
+      - os: macos-latest
+        target: aarch64-apple-darwin         # Apple Silicon (M1/M2/M3)
+        artifact: fxg-macos-arm64
+```
+
+> Używamy `x86_64-unknown-linux-musl` zamiast `gnu` — binarka statyczna, nie wymaga żadnych systemowych `.so`. Keyring na Linuksie fallback do pliku szyfrowanego (jeśli brak dbus).
+
+Pliki lądują w GitHub Releases jako Assets. Użytkownik pobiera odpowiedni plik dla swojego systemu.
+
+---
+
+## Linux — instalacja
+
+### Skrypt jednolinijkowy (docelowy UX)
+
+```bash
+curl -fsSL https://github.com/twoj-user/fxg/releases/latest/download/install.sh | bash
+```
+
+Skrypt robi:
+1. Wykrywa architekturę (`uname -m`)
+2. Pobiera odpowiednią binarkę z GitHub Releases
+3. Umieszcza ją w `~/.local/bin/fxg`
+4. Dodaje `~/.local/bin` do `$PATH` w `.bashrc`/`.zshrc` jeśli jeszcze nie ma
+5. Jeśli brak konfiguracji → uruchamia `fxg setup` (first-run wizard)
+
+```bash
+#!/bin/bash
+set -e
+ARCH=$(uname -m)
+OS=linux
+case $ARCH in
+  x86_64)  FILE="fxg-linux-x64" ;;
+  aarch64) FILE="fxg-linux-arm64" ;;
+  *) echo "Nieobsługiwana architektura: $ARCH"; exit 1 ;;
+esac
+
+LATEST=$(curl -s https://api.github.com/repos/twoj-user/fxg/releases/latest | grep tag_name | cut -d '"' -f 4)
+URL="https://github.com/twoj-user/fxg/releases/download/${LATEST}/${FILE}"
+
+mkdir -p ~/.local/bin
+curl -fsSL "$URL" -o ~/.local/bin/fxg
+chmod +x ~/.local/bin/fxg
+
+# Dodaj do PATH jeśli brak
+if ! echo "$PATH" | grep -q "$HOME/.local/bin"; then
+  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
+  export PATH="$HOME/.local/bin:$PATH"
+fi
+
+echo "fxg zainstalowany. Uruchamianie konfiguracji..."
+fxg setup
+```
+
+### Opcjonalnie: pakiety .deb i .rpm
+
+Generowane przez `cargo-deb` i `cargo-rpm` w CI — przydatne dla systemów zarządzanych przez IT.
+
+```bash
+# Ubuntu/Debian
+sudo dpkg -i fxg_0.1.0_amd64.deb
+
+# Fedora/RHEL/CentOS
+sudo rpm -i fxg-0.1.0.x86_64.rpm
+```
+
+---
+
+## Windows — instalacja
+
+### Opcja A: Kliknięcie `.exe` (docelowy UX dla grafika)
+
+Gdy użytkownik dwukrotnie kliknie `fxg-windows-x64.exe` bez żadnych argumentów i brak konfiguracji, zamiast wyświetlić help i zamknąć okno — **otwiera PowerShell z konfiguratorem**.
+
+Implementacja w `src/main.rs`:
+```rust
+#[cfg(windows)]
+fn ensure_console() {
+    // Jeśli uruchomiono przez dwuklik (nie z terminala), otwórz nowe okno konsoli
+    // i uruchom fxg setup w nim
+    use std::os::windows::process::CommandExt;
+    if !is_launched_from_terminal() {
+        std::process::Command::new("cmd")
+            .args(["/k", "fxg.exe", "setup"])
+            .creation_flags(0x00000010) // CREATE_NEW_CONSOLE
+            .spawn().ok();
+        std::process::exit(0);
+    }
+}
+```
+
+### Opcja B: Skrypt PowerShell (instalacja systemowa)
+
+```powershell
+# Wklej w PowerShell jako Administrator:
+iwr https://github.com/twoj-user/fxg/releases/latest/download/install.ps1 | iex
+```
+
+Skrypt:
+1. Pobiera `fxg-windows-x64.exe`
+2. Umieszcza w `%USERPROFILE%\AppData\Local\fxg\`
+3. Dodaje ten folder do `$PATH` (przez `[Environment]::SetEnvironmentVariable`)
+4. Uruchamia `fxg setup` w nowym oknie terminalu
+
+### Opcja C: WinGet (Microsoft Store CLI) — przyszłość
+
+```
+winget install fxg
+```
+
+Wymaga zgłoszenia pakietu do repozytorium `winget-pkgs`.
+
+---
+
+## macOS — instalacja
+
+### Homebrew (docelowy UX)
+
+```bash
+brew install twoj-user/tap/fxg
+```
+
+Wymaga stworzenia własnego "tap" (repozytorium z formularzem Homebrew):
+
+```ruby
+# Formula/fxg.rb
+class Fxg < Formula
+  desc "Multi-repository git workflow manager"
+  homepage "https://github.com/twoj-user/fxg"
+  version "0.1.0"
+
+  on_macos do
+    if Hardware::CPU.arm?
+      url "https://github.com/twoj-user/fxg/releases/download/v0.1.0/fxg-macos-arm64"
+      sha256 "..."
+    else
+      url "https://github.com/twoj-user/fxg/releases/download/v0.1.0/fxg-macos-x64"
+      sha256 "..."
+    end
+  end
+
+  def install
+    bin.install "fxg-macos-arm64" => "fxg"
+  end
+end
+```
+
+---
+
+## First-run wizard
+
+Kluczowy element UX. Gdy użytkownik uruchamia **dowolną komendę** po raz pierwszy (brak `~/.fxg/config.toml`), zamiast error'a dostaje automatyczny setup.
+
+Implementacja w `src/app.rs`, przed każdym `match cli.command`:
+
+```rust
+// src/app.rs
+pub async fn run(cli: Cli) -> Result<()> {
+    // Jeśli brak konfiguracji → uruchom first-run setup
+    if !config::config_path().exists() {
+        println!("Wygląda na to, że uruchamiasz fxg po raz pierwszy.");
+        println!("Przeprowadźmy krótką konfigurację (zajmie ~2 minuty).\n");
+        first_run_setup().await?;
+    }
+
+    let cfg = config::load_config()?;
+    // ... reszta
+}
+
+async fn first_run_setup() -> Result<()> {
+    // 1. Uruchom config TUI
+    let cfg = config::run_first_time().await?;
+    // 2. Zapytaj o dodanie konta
+    if inquire::Confirm::new("Czy chcesz teraz podłączyć konto GitHub/GitLab?")
+        .with_default(true).prompt()? {
+        // Uruchom auth add wizard
+        auth::run_add_wizard(&cfg).await?;
+    }
+    println!("\nGotowe! Wpisz 'fxg status' żeby zobaczyć swoje projekty.");
+    Ok(())
+}
+```
+
+---
+
+## Systemowe zależności — problemy i rozwiązania
+
+| Zależność | Problem | Rozwiązanie |
+|---|---|---|
+| `libgit2` | Wymagana na Linuksie przy dynamicznym linkowaniu | Używamy `git2` z feature `vendored` — kompiluje libgit2 statycznie |
+| `keyring` / `libsecret` | Wymaga `dbus` na Linuksie headless | Fallback do zaszyfrowanego pliku `~/.fxg/credentials.enc` gdy brak dbus |
+| `openssl` | Różne wersje na różnych systemach | Feature `native-tls` → `rustls` — TLS w całości wbudowany w Rust |
+
+```toml
+# Cargo.toml — docelowa konfiguracja dla statycznych binarek
+[dependencies]
+git2     = { version = "0.19", features = ["vendored"] }
+reqwest  = { version = "0.12", features = ["json", "rustls-tls"], default-features = false }
+keyring  = { version = "3", features = ["sync-secret-service"] }
+```
+
+---
+
+## O nazwie
+
+Aktualna nazwa `fxg` ("finally executable git") to placeholder — dobra jako codename, ale przed publicznym wydaniem warto rozważyć zmianę.
+
+Kryteria dobrej nazwy narzędzia CLI:
+- Krótka (2–4 znaki idealne, max 6)
+- Łatwa do wymówienia i zapamiętania
+- Nie koliduje z istniejącymi komendami systemowymi
+- Nawiązuje do funkcji (opcjonalnie)
+
+Kilka luźnych kierunków (bez rekomendacji — ostateczna decyzja należy do Ciebie):
+- Coś od "workspace" / "repos" / "git"
+- Coś sugerującego "wielość" lub "hub"
+- Akronim który znaczy coś po polsku, a po angielsku brzmi jak komenda
+
+Niezależnie od wyboru nazwy — warto go podjąć przed stworzeniem Homebrew tap i pierwszym publicznym Release, bo zmiana nazwy binarki po publikacji jest uciążliwa.
+
+---
+
+## Roadmap dystrybucji
+
+```
+v0.1 (teraz)    cargo install — tylko dla developerów
+v0.2            GitHub Releases z binaries (Linux + Windows + macOS)
+                Skrypt instalacyjny curl | bash
+v0.3            First-run wizard (bez potrzeby wpisywania komend setup)
+                PowerShell install script dla Windows
+v0.4            Homebrew tap dla macOS
+v1.0            Stabilny API, binarka klikalna na Windows
+                WinGet (opcjonalnie)
+                Pakiety .deb/.rpm (opcjonalnie)
+```

docs/guide-designer.md

@@ -0,0 +1,198 @@
+# Poradnik dla grafika — jak używać fxg
+
+> Ten poradnik zakłada, że nigdy wcześniej nie używałeś terminalu do pracy z kodem. Spokojnie — to jest prostsze niż myślisz.
+
+---
+
+## Co to jest i po co to komuś?
+
+Wyobraź sobie, że każdy projekt (strona, aplikacja, assets) mieszka w osobnym folderze na GitHubie. `fxg` to program, który pozwala ci zarządzać tymi wszystkimi folderami jednocześnie — zobaczyć co się zmieniło, wysłać zmiany na serwer, pobrać najnowszą wersję — wszystko bez klikania po interfejsie GitHuba.
+
+**Dla Ciebie oznacza to:** zamiast wchodzić na stronę GitHuba i klikać w każde repozytorium osobno, wpisujesz jedną komendę i widzisz status wszystkiego.
+
+---
+
+## Krok 1 — Instalacja
+
+### Windows
+
+1. Pobierz plik `fxg.exe` z sekcji [Releases](https://github.com/twoj-team/fxg/releases) (zakładka "Assets")
+2. Przenieś plik do folderu `C:\Users\TwojeImie\` (czyli do swojego folderu domowego)
+3. Otwórz **Terminal** (wyszukaj "Terminal" w menu Start, lub `Windows + R` → wpisz `cmd` → Enter)
+4. Wpisz `fxg --version` i naciśnij Enter — jeśli widzisz numer wersji, instalacja się udała
+
+> Jeśli system pyta "Czy chcesz uruchomić ten plik?" — kliknij "Tak" / "Uruchom mimo to".
+
+### Linux (np. Linux Mint)
+
+Otwórz terminal i wklej:
+```
+curl -fsSL https://github.com/twoj-team/fxg/install.sh | bash
+```
+Gotowe.
+
+### macOS
+
+```
+brew install twoj-team/tap/fxg
+```
+(wymaga Homebrew — jeśli nie masz, zapytaj kolegę programistę)
+
+---
+
+## Krok 2 — Pierwsze uruchomienie (robisz to RAZ)
+
+Otwórz terminal i wpisz:
+
+```
+fxg config
+```
+
+Pojawi się ekran konfiguracji. Ustaw:
+
+| Pole | Co wpisać |
+|---|---|
+| `workspace_root` | Folder gdzie trzymasz projekty, np. `C:\Users\TwojeImie\projekty` lub `/home/twoje/projekty` |
+| `username` | Twoje imię i nazwisko lub nick (to będzie widoczne w commitach) |
+| `email` | Twój email z GitHuba |
+
+Poruszasz się strzałkami, edytujesz pole po naciśnięciu Enter, zapisujesz przez `q` lub `Ctrl+S`.
+
+---
+
+## Krok 3 — Podłącz konto GitHub (robisz to RAZ)
+
+Potrzebujesz **tokenu dostępu** z GitHuba. Oto jak go zdobyć:
+
+1. Wejdź na [github.com/settings/tokens](https://github.com/settings/tokens)
+2. Kliknij **"Generate new token (classic)"**
+3. Wpisz nazwę (np. "fxg na moim laptopie")
+4. Zaznacz: `repo` (cały zakres)
+5. Kliknij **"Generate token"** na dole
+6. **Skopiuj token** — zobaczysz go tylko raz!
+
+Teraz wróć do terminalu i wpisz (zamień `TWOJ_TOKEN` na skopiowany token):
+
+```
+fxg auth add --provider github --token TWOJ_TOKEN
+```
+
+Gotowe. Token jest bezpiecznie zapisany na Twoim komputerze.
+
+---
+
+## Codzienne użycie
+
+### Sprawdź co się dzieje we wszystkich projektach
+
+```
+fxg status
+```
+
+Zobaczysz tabelę z projektami. Co oznaczają kolumny:
+
+```
+  #   NAZWA           BRANCH     AHEAD  BEHIND  DIRTY  OSTATNI COMMIT
+  1   projekt-strona  main           0       2      ✗   2h temu
+  2   projekt-logo    develop        1       0      ✓   wczoraj
+```
+
+| Kolumna | Co znaczy |
+|---|---|
+| `AHEAD` | Masz zmiany gotowe do wysłania na serwer |
+| `BEHIND` | Na serwerze są nowsze zmiany — ktoś coś dodał |
+| `DIRTY ✓` | Masz niezapisane zmiany (jak "niezapisany dokument") |
+
+**Poruszanie się:** strzałki góra/dół, `Enter` żeby wejść w szczegóły projektu, `q` żeby wyjść.
+
+---
+
+### Pobierz najnowszą wersję projektu
+
+Jeśli `BEHIND` pokazuje liczbę większą od 0, ktoś dodał zmiany na serwerze. Pobierz je:
+
+```
+fxg sync pull --all
+```
+
+To pobierze najnowszą wersję **wszystkich** projektów naraz.
+
+---
+
+### Wyślij swoje zmiany na serwer
+
+Masz nowe pliki (np. nowe grafiki, zaktualizowane assets)? Użyj interaktywnego trybu:
+
+```
+fxg sync
+```
+
+Pojawi się ekran z listą projektów. Obsługa:
+
+1. **Zaznacz projekt** — naciśnij `Spacja` przy projekcie który chcesz wysłać. Możesz zaznaczyć kilka.
+   - `a` — zaznacz wszystkie naraz
+2. **Naciśnij Enter** — przejdziesz do wyboru akcji
+3. **Wybierz "Commit"** — strzałkami, potem Enter. Wpisz opis zmian (np. "nowe bannery dla kampanii Q2"), Enter.
+4. **Wybierz "Push"** — to faktycznie wysyła na serwer.
+
+> **Commit vs Push:** Commit to jak "zapisanie wersji" lokalnie. Push to wysłanie tej wersji na serwer. Zawsze robisz najpierw Commit, potem Push.
+
+---
+
+### Szybki push z linii komend (jeśli wiesz co robisz)
+
+```
+fxg sync push --all -m "aktualizacja grafik landing page"
+```
+
+To jednocześnie commita (z wiadomością po `-m`) i pushuje wszystkie zmienione projekty.
+
+---
+
+## Słowniczek
+
+| Słowo | Po ludzku |
+|---|---|
+| **Repozytorium** (repo) | Folder projektu na GitHubie. Jak teczka z plikami projektu. |
+| **Commit** | Zapisanie wersji plików z opisem "co zmieniłem". Jak ctrl+S z etykietką. |
+| **Push** | Wysłanie swoich zmian na serwer GitHuba. |
+| **Pull** | Pobranie zmian z serwera na swój komputer. |
+| **Branch** | Wersja projektu. `main` to główna, `develop` to robocza. |
+| **Dirty** | Pliki zmienione ale jeszcze nie scommitowane. |
+| **Merge** | Połączenie dwóch wersji projektu w jedną. Robi to zwykle programista. |
+
+---
+
+## Coś nie działa?
+
+**Terminal nie zna komendy `fxg`**
+- Windows: sprawdź czy plik `fxg.exe` jest w folderze który jest w PATH. Najprostsze rozwiązanie: przenieś plik do `C:\Windows\System32\`
+- Linux/Mac: sprawdź czy `~/.cargo/bin` jest w PATH, lub uruchom ręcznie: `./fxg`
+
+**"Permission denied" lub "access denied"**
+- Linux/Mac: wpisz `chmod +x fxg` przed pierwszym uruchomieniem
+
+**"Authentication failed" przy push/pull**
+- Token prawdopodobnie wygasł lub nie ma uprawnień do `repo`
+- Wygeneruj nowy token i dodaj: `fxg auth add --provider github --token NOWY_TOKEN`
+
+**Nie widzę swoich projektów w `fxg status`**
+- Sprawdź czy `workspace_root` w `fxg config` wskazuje na właściwy folder
+- Folder musi zawierać podfoldery z projektami (każdy projekt to osobny podfolder z `.git` w środku)
+
+**Zmiany się nie wysyłają, `fxg sync push` nic nie robi**
+- Najpierw sprawdź `fxg status` — kolumna `DIRTY` musi być `✓` żeby był co wysyłać
+- Jeśli `DIRTY` jest `✗`, ale `AHEAD` > 0 — wystarczy sam push bez commita
+
+---
+
+## Szybka ściąga
+
+```
+fxg status              # sprawdź co się dzieje
+fxg sync pull --all     # pobierz najnowsze wersje
+fxg sync                # interaktywny ekran: commit + push
+fxg sync push --all -m "opis zmian"   # szybki commit + push
+fxg auth add --provider github --token TOKEN   # dodaj konto
+fxg config              # zmień ustawienia
+```

docs/qol-ideas.md

@@ -0,0 +1,314 @@
+# fxg — pomysły na QoL (Quality of Life)
+
+> Dokument roboczy. Każdy pomysł ma tytuł, opis, przykład użycia i szacunkową trudność implementacji.
+
+---
+
+## Wysoki priorytet
+
+### 1. `fxg clone` — pobierz wszystkie repozytoria jedną komendą
+
+**Problem:** Na nowym laptopie masz 50 repo na GitHubie. Musisz je klonować jedno po drugim. Żmudne.
+
+**Rozwiązanie:** Komenda pobierająca listę repo z API i klonująca je do `workspace_root`.
+
+```bash
+fxg clone --mine            # repo których jesteś właścicielem
+fxg clone --contributed     # repo w których robiłeś commity (contributor)
+fxg clone --org mojaFirma   # wszystkie repo organizacji
+fxg clone --starred         # repo które oznaczyłeś gwiazdką
+
+# z filtrowaniem
+fxg clone --mine --filter "frontend"    # tylko repo z "frontend" w nazwie
+fxg clone --mine --limit 20            # max 20 repo
+```
+
+**Implementacja:** Wywołać `provider.list_repos()` (nowa metoda w trait `Provider`), przefiltrować, wywołać `git clone` dla każdego. Wyświetlić progress w TUI podobny do `sync`.
+
+**Trudność:** średnia — wymaga nowej metody w każdym providerze (GitHub/GitLab/Gitea API wszystkie to obsługują).
+
+---
+
+### 2. Tagi jako organizacja folderów lokalnych
+
+**Problem:** Masz 50 repo i wszystkie są w jednym `workspace_root/`. Chaos.
+
+**Rozwiązanie:** Tag przypisany do repo = podfolder w `workspace_root`. repo z tagiem `dev` ląduje w `workspace_root/dev/`, repo z tagiem `client-acme` ląduje w `workspace_root/client-acme/`.
+
+```bash
+# przy tworzeniu repo
+fxg init moj-projekt --tags dev,frontend
+
+# retroaktywnie
+fxg tag moj-projekt add client-acme
+fxg tag moj-projekt remove dev
+
+# reorganizacja lokalna — przenieś foldery według tagów
+fxg workspace organize        # pyta o potwierdzenie przed każdym przeniesieniem
+fxg workspace organize --dry-run   # pokaż co by się przeniosło, bez wykonania
+```
+
+**Wynikowa struktura:**
+```
+~/projekty/
+├── dev/
+│   ├── api-backend/
+│   └── shared-utils/
+├── client-acme/
+│   ├── acme-website/
+│   └── acme-mobile/
+└── archived/
+    └── stary-projekt/
+```
+
+**Implementacja:** Przechowywać tagi per-repo w `workspaces.toml` lub osobnym `tags.toml`. Komenda `organize` tworzy podfoldery i przenosi repo (lub tworzy symlinki — symlinki są bezpieczniejsze, bo oryginał zostaje w miejscu).
+
+**Trudność:** średnia — logika przenoszenia + aktualizacja `workspace_root` per-repo.
+
+---
+
+### 3. Domyślna paczka plików przy `fxg init`
+
+**Problem:** Przy tworzeniu repo trzeba pamiętać o zaznaczeniu README, CHANGELOG, .env.example w wizardzie. Zawsze się o czymś zapomni.
+
+**Rozwiązanie:** Konfigurowalna lista plików tworzonych domyślnie (bez pytania), z możliwością wyłączenia.
+
+```toml
+# ~/.fxg/config.toml
+default_init_files = ["README.md", "CHANGELOG.md", ".env.example", ".gitignore"]
+```
+
+```bash
+fxg init moj-projekt                    # tworzy domyślny zestaw
+fxg init moj-projekt --no-defaults     # tworzy puste repo
+fxg init moj-projekt --files readme,license  # tylko te dwa
+```
+
+Dodatkowo: **szablony zawartości pliku README** konfigurowalne w `config.toml` (`readme_template = "heartbyte-default"` już istnieje w konfigu, ale nie jest zaimplementowane).
+
+**Trudność:** niska — już mamy `InitConfig` z polami `readme`, `changelog` itd., wystarczy ustawić domyślne wartości z configa zamiast false.
+
+---
+
+### 4. `fxg sync branch cleanup` — sprzątanie zmergowanych gałęzi
+
+**Problem:** Po miesiącach pracy masz 30 lokalnych gałęzi, z których 25 jest już zmergowanych do main. Zajmują miejsce, mylą.
+
+**Rozwiązanie:**
+```bash
+fxg sync branch cleanup           # interaktywny wybór (TUI lista)
+fxg sync branch cleanup --all     # usuń wszystkie zmergowane bez pytania
+fxg sync branch cleanup --dry-run # pokaż co by się usunęło
+```
+
+Usuwa gałęzie które są już zmergowane do `main`/`master` — lokalnie i opcjonalnie zdalnie.
+
+**Implementacja:** `git2` — `repo.branches()`, sprawdzenie czy jest zmergowana przez `repo.merge_analysis()`. Już mamy `delete_branch()` w `sync/mod.rs`.
+
+**Trudność:** niska — wszystkie potrzebne funkcje `git2` już są w kodzie.
+
+---
+
+## Średni priorytet
+
+### 5. Shell completions (bash / zsh / fish / PowerShell)
+
+Wpisanie `fxg <Tab>` podpowiada:
+- subkomendy (`status`, `sync`, `init`...)
+- nazwy repo dla `fxg status <Tab>` → lista repo z workspace_root
+- nazwy workspace dla `--workspace <Tab>`
+- aliasy kont dla `fxg auth switch <Tab>`
+
+```bash
+fxg completions bash   >> ~/.bashrc
+fxg completions zsh    >> ~/.zshrc
+fxg completions fish   > ~/.config/fish/completions/fxg.fish
+fxg completions powershell >> $PROFILE
+```
+
+**Implementacja:** `clap` ma wbudowany generator completion przez crate `clap_complete`. Dynamiczne uzupełnianie nazw repo wymaga osobnego skryptu który wywołuje `fxg --list-repos` (nowa ukryta flaga).
+
+**Trudność:** niska (statyczne) / średnia (dynamiczne nazwy repo).
+
+---
+
+### 6. `fxg status --watch` — live monitoring workspace
+
+```bash
+fxg status --watch          # odświeża TUI co 30 sekund
+fxg status --watch --interval 10   # co 10 sekund
+```
+
+TUI pokazuje kiedy ostatnio odświeżono. Przy zmianie statusu (np. nowy commit na serwerze) wiersz miga przez chwilę na żółto.
+
+**Implementacja:** Tokio timer w pętli TUI, wywołuje `scan_workspace()` co N sekund. Detekcja zmian przez porównanie `ahead/behind` z poprzednim stanem.
+
+**Trudność:** niska — już mamy `scan_workspace()` i pętlę TUI.
+
+---
+
+### 7. Szablony projektów (`fxg init --template`)
+
+```bash
+fxg init moj-projekt --template react-app
+fxg init moj-projekt --template rust-cli
+fxg init moj-projekt --template python-fastapi
+fxg init moj-projekt --template node-express
+```
+
+Każdy szablon tworzy kompletną strukturę katalogów i pliki startowe:
+- `react-app` → `src/`, `public/`, `package.json` z React, `.eslintrc`, Dockerfile
+- `rust-cli` → `src/main.rs`, `Cargo.toml` z clap+anyhow, `README.md`
+- `python-fastapi` → `main.py`, `requirements.txt`, `.env.example`, `Dockerfile`
+
+Szablony przechowywane w `~/.fxg/templates/` jako foldery — użytkownik może dodać własne.
+
+**Trudność:** średnia — logika tworzenia plików jest już w `init/mod.rs`, potrzebny nowy system szablonów.
+
+---
+
+### 8. `fxg pr list` — przegląd otwartych PR
+
+```bash
+fxg pr list                     # wszystkie PR we wszystkich repo workspace
+fxg pr list --repo moj-projekt  # tylko jedno repo
+fxg pr list --mine              # tylko PR gdzie jesteś autorem lub reviewerem
+```
+
+Wyświetla TUI tabelę: repo | numer | tytuł | autor | data | etykiety.
+
+Enter na PR otwiera URL w przeglądarce.
+
+**Implementacja:** Nowa metoda `list_pull_requests()` w trait `Provider`, wywołanie API. GitHub/GitLab/Gitea wszystkie to mają.
+
+**Trudność:** średnia — nowa metoda w każdym providerze.
+
+---
+
+### 9. Globalny `.fxgignore` — repo do pominięcia
+
+```
+# ~/.fxg/ignore
+archived-*        # wszystkie repo zaczynające się od "archived-"
+old-monorepo      # konkretne repo po nazwie
+```
+
+`scan_workspace()` pomija pasujące foldery. Przydatne gdy `workspace_root` zawiera też foldery inne niż repo git.
+
+**Implementacja:** Dodać `ignore_patterns: Vec<String>` do `AppConfig`, sprawdzać przy `scan_workspace()`.
+
+**Trudność:** niska.
+
+---
+
+### 10. `fxg stats --trend` — wykres aktywności w czasie
+
+```bash
+fxg stats --trend             # ostatnie 30 dni
+fxg stats --trend --days 90
+fxg stats --trend --repo api-backend
+```
+
+ASCII wykres słupkowy commitów per dzień:
+
+```
+Aktywność (ostatnie 30 dni) — api-backend
+
+May 01  ████████░░░░░░░░░░░░░  8
+May 08  ████████████░░░░░░░░░  12
+May 15  ██████░░░░░░░░░░░░░░░  6
+May 22  ██████████████████░░░  18
+```
+
+**Implementacja:** `revwalk` po historii commitów + grupowanie po dniach. Już mamy `git2` w projekcie.
+
+**Trudność:** niska.
+
+---
+
+## Przyszłość / ambitne
+
+### 11. VSCode Extension — automatyczne time tracking
+
+Aktualnie `fxg stats time` czyta pliki JSON z `~/.fxg/vsc-data/`. Trzeba je tworzyć ręcznie lub osobnym narzędziem.
+
+**Rozwiązanie:** Towarzyszące rozszerzenie VS Code które automatycznie zapisuje czas spędzony na plikach w formacie rozumianym przez `fxg`.
+
+```
+fxg stats time            # pokazuje automatycznie zbierane dane
+```
+
+---
+
+### 12. Webhook przy każdym sync
+
+Opcjonalny URL w `config.toml`:
+```toml
+sync_webhook = "https://discord.com/api/webhooks/..."
+```
+
+Po każdym udanym `push` wysyła embed z: repo, branch, commit message, autor.
+Identyczny mechanizm jak audit log w innych projektach z tego zespołu.
+
+**Trudność:** niska — prosty `reqwest::post` po każdym `push_repo()`.
+
+---
+
+### 13. AI-assisted commit messages
+
+```bash
+fxg sync commit --ai        # generuje wiadomość z diff za pomocą AI API
+fxg sync commit --ai --edit # generuje, ale otwiera edytor do poprawki przed commitem
+```
+
+Wysyła `git diff --staged` do API (np. Claude lub OpenAI), dostaje propozycję wiadomości w stylu conventional commits.
+
+Wymaga klucza API w konfiguracji.
+
+---
+
+### 14. `fxg release` multi-platform publish
+
+Po stworzeniu release tagu — automatyczne wyzwolenie publishu na:
+- `crates.io` (dla Rust)
+- `npm` (dla Node.js)
+- `PyPI` (dla Python)
+
+Wykrywa typ projektu przez `detect_project_type()` (już istnieje w `summary/mod.rs`).
+
+---
+
+### 15. Interaktywny diff viewer
+
+W widoku szczegółowym repo (`fxg status <repo>`) — klawisz `d` otwiera inlinowy diff zmienionych plików z kolorowym podświetleniem:
+
+```
+  M  src/components/Nav.tsx    [d] diff  [s] stage  [r] revert
+─────────────────────────────────────────
+  - const navItems = ["Home", "About"];
+  + const navItems = ["Home", "About", "Contact"];
+```
+
+**Trudność:** wysoka — wymaga parsowania diff output i renderowania w ratatui.
+
+---
+
+## Szybkie podsumowanie priorytetów
+
+| # | Pomysł | Priorytet | Trudność |
+|---|---|---|---|
+| 1 | `fxg clone --mine/--contributed` | Wysoki | Średnia |
+| 2 | Tagi → organizacja folderów | Wysoki | Średnia |
+| 3 | Domyślna paczka plików przy init | Wysoki | Niska |
+| 4 | `branch cleanup` | Wysoki | Niska |
+| 5 | Shell completions | Średni | Niska–Średnia |
+| 6 | `status --watch` | Średni | Niska |
+| 7 | Szablony projektów | Średni | Średnia |
+| 8 | `pr list` | Średni | Średnia |
+| 9 | `.fxgignore` | Średni | Niska |
+| 10 | `stats --trend` | Średni | Niska |
+| 11 | VSCode extension | Przyszłość | Wysoka |
+| 12 | Webhook przy sync | Przyszłość | Niska |
+| 13 | AI commit messages | Przyszłość | Średnia |
+| 14 | Multi-platform publish | Przyszłość | Wysoka |
+| 15 | Diff viewer w TUI | Przyszłość | Wysoka |