diff --git a/README.md b/README.md
index 94ba311..fbe6f5a 100644
--- a/README.md
+++ b/README.md
@@ -1,163 +1,742 @@
-# meva
-
-A distributed version control system written in Rust, developed as part of an engineering thesis.
-
-## Workspace structure
-
-The workspace contains five crates, organized as follows:
+
+ 
+
+
+# 🪶 MEVA
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+**MEVA** (ang. _Modular & Extensible Versioning Assistant_) to rozproszony system kontroli wersji wyposażony w interfejsy CLI oraz GUI, zaimplementowany w języku Rust. Projekt został zrealizowany w ramach pracy inżynierskiej na Wydziale Matematyki i Nauk Informacyjnych Politechniki Warszawskiej przez zespół w składzie:
+
+- **[Adam Grącikowski](https://github.com/adamgracikowski)**
+- **[Mikołaj Karbowski](https://github.com/mikolajkarbowski)**
+
+Promotorem pracy był **[mgr inż. Tomasz Herman](https://github.com/tomasz-herman)**.
+
+## Spis treści
+
+- [Obsługiwane polecenia](#obslugiwane-polecenia)
+- [Graficzny interfejs użytkownika](#graficzny-interfejs-uzytkownika)
+- [Architektura](#architektura)
+ - [Struktura projektu](#struktura-projektu)
+ - [Model rozproszony i architektura repozytoriów](#model-rozproszony-i-architektura-repozytoriów)
+ - [Warstwa sieciowa i protokoły synchronizacji](#warstwa-sieciowa-i-protokoły-synchronizacji)
+- [Instalacja](#instalacja)
+ - [Wymagania wstępne i środowisko budowania](#wymagania-wstępne-i-środowisko-budowania)
+ - [Instalacja klienta CLI](#instalacja-klienta-cli)
+ - [Instalacja klienta GUI](#instalacja-klienta-gui)
+ - [Instalacja i konfiguracja serwera SSH](#instalacja-i-konfiguracja-serwera-ssh)
+ - [Weryfikacja instalacji](#weryfikacja-instalacji)
+- [Instrukcja użytkownika](#instrukcja-użytkownika)
+ - [Praca z interfejsem CLI](#praca-z-interfejsem-cli)
+ - [Praca z interfejsem GUI](#praca-z-interfejsem-gui)
+ - [Praca z serwerem SSH](#praca-z-serwerem-ssh)
+- [Generowanie dokumentacji projektu](#generowanie-dokumentacji-projektu)
+
+## Obsługiwane polecenia
+
+| Polecenie | Opis |
+| :--------- | :----------------------------------------------------------------------------------------- |
+| `init` | Inicjalizuje nowe, puste repozytorium. |
+| `add` | Dodaje zawartość plików do indeksu. |
+| `commit` | Tworzy nowe zatwierdzenie w repozytorium. |
+| `status` | Wyświetla stan plików w drzewie roboczym (zmodyfikowane, nieśledzone). |
+| `log` | Pokazuje historię commitów. |
+| `ls-files` | Wyświetla informacje o plikach w indeksie i drzewie roboczym. |
+| `ls-tree` | Wyświetla zawartość obiektu drzewa. |
+| `show` | Wyświetla szczegóły zatwierdzenia. |
+| `diff` | Pokazuje zmiany między zatwierdzeniami, zatwierdzeniem a drzewem roboczym itp. |
+| `restore` | Przywraca pliki w drzewie roboczym. |
+| `config` | Pobiera i ustawia opcje konfiguracyjne (`create`, `get`, `set`, `unset`, `list`, `edit`). |
+| `ignore` | Zarządza ignorowaniem plików (`add`, `remove`, `check`, `edit`). |
+| `branch` | Listuje, tworzy lub usuwa gałęzie. |
+| `checkout` | Przełącza gałęzie lub przywraca pliki drzewa roboczego. |
+| `merge` | Scala historię z innej gałęzi do bieżącej. |
+| `remote` | Zarządza zdalnymi repozytoriami (`add`, `remove`, `show`, `rename`, `get-url`, `set-url`). |
+| `clone` | Klonuje repozytorium do nowego katalogu. |
+| `fetch` | Pobiera obiekty i referencje ze zdalnego repozytorium. |
+| `pull` | Pobiera (`fetch`) i scala (`merge`) zmiany ze zdalnego repozytorium lub z lokalnej gałęzi. |
+| `push` | Aktualizuje zdalne referencje wraz z powiązanymi obiektami. |
+| `plugins` | Zarządza systemem skryptów użytkownika (`register`, `unregister`, `list`, `info`, `edit`). |
+
+## Graficzny interfejs użytkownika
+
+
+
+Ekran startowy aplikacji (Dashboard).
+
+
+
+ 
+
+
+
+
+
+
+Widok ustawień z formularzem edycji oraz listą globalnych zmiennych konfiguracyjnych.
+
+
+
+ 
+
+
+
+
+
+
+Błąd ładowania konfiguracji lokalnej przy braku otwartego repozytorium.
+
+
+
+ 
+
+
+
+
+
+
+Menu główne aplikacji z opcjami tworzenia i klonowania repozytorium.
+
+
+
+ 
+
+
+
+
+
+
+Okno dialogowe inicjalizacji nowego repozytorium.
+
+
+
+ 
+
+
+
+
+
+
+Okno dialogowe klonowania zdalnego repozytorium.
+
+
+
+ 
+
+
+
+
+
+
+Komunikat błędu wyświetlany przy próbie otwarcia katalogu z niezainicjowanym repozytorium.
+
+
+
+ 
+
+
+
+
+
+
+Podział plików na sekcje Staged i Unstaged z widocznymi ikonami statusu.
+
+
+
+ 
+
+
+
+
+
+
+Interaktywna lista historii commitów z rozwiniętymi szczegółami zmian.
+
+
+
+ 
+
+
+
+
+
+
+Okno dialogowe zatwierdzania zmian.
+
+
+
+ 
+
+
+
+
+
+
+Widok różnicowy z podświetlaniem składni.
+
+
+
+ 
+
+
+
+
+
+
+Menu kontekstowe pliku z opcją podglądu różnic i odrzucenia zmian.
+
+
+
+ 
+
+
+
+
+
+
+Okno dialogowe do zarządzania gałęziami.
+
+
+
+ 
+
+
+
+
+
+
+Stan aplikacji po wykryciu konfliktu w trakcie operacji scalania.
+
+
+
+ 
+
+
+
+
+
+
+Menu kontekstowe pliku z opcją rozpoczęcia rozwiązywania konfliktu.
+
+
+
+ 
+
+
+
+
+
+
+Edycja pliku ze znacznikami konfliktów w zewnętrznym edytorze.
+
+
+
+ 
+
+
+
+
+
+
+Oznaczenie konfliktu jako rozwiązanego.
+
+
+
+ 
+
+
+
+
+
+
+Pasek stanu z informacją o śledzonej gałęzi (2 zmiany do pobrania, 4 do wysłania).
+
+
+
+ 
+
+
+
+
+
+
+Widok paska statusu z widocznymi przyciskami akcji sieciowych.
+
+
+
+ 
+
+
+
+
+
+
+Lista aktywnych pluginów z filtrem ustawionym na zdarzenia pre-execute.
+
+
+
+ 
+
+
+
+
+
+
+Widok nieaktywnego pluginu z widocznym przyciskiem Enable.
+
+
+
+ 
+
+
+
+
+
+
+Edycja źródła skryptu wywołana przyciskiem Edit.
+
+
+
+ 
+
+
+
+
+
+
+Formularz rejestracji nowego pluginu.
+
+
+
+ 
+
+
+
+
+## Architektura
+
+### Struktura projektu
+
+Projekt `meva` zorganizowany jest jako _Rust Workspace_ i został podzielony jest na 6 modułów (ang. _crates_).
```
meva/
-├── Cargo.toml
-├── Cargo.lock
-├── engine/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
-├── cli/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
├── gui/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
-├── plugins/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
+│ └── ...
+├── cli/
+│ └── ...
├── server/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
+│ └── ...
+├── engine/
+│ └── ...
+├── plugins/
+│ └── ...
├── shared/
-│ ├── Cargo.toml
-│ └── src/
-│ └── ...
-├── tests/
│ └── ...
-└── target/
- └── ...
+├── Cargo.toml
+├── LICENSE
+└── README.md
```
-## Getting Started
+| Moduł | Opis |
+| :-------- | :--------------------------------------------------------------------------------------------------------------------------------------------- |
+| `cli` | Interfejs wiersza poleceń, który pozwala na skryptowe zarządzanie repozytorium. |
+| `gui` | Interfejs graficzny dla użytkownika końcowego w formie aplikacji desktopowej, wspierający podzbiór funkcjonalności interfejsu wiersza poleceń. |
+| `server` | Moduł sieciowy. Obsługuje protokoły synchronizacji z repozytorium zdalnym, a także uwierzytelnianie i autoryzację użytkowników. |
+| `engine` | Główny moduł implementujący logikę poszczególnych operacji na repozytorium. |
+| `plugins` | System rozszerzeń w postaci skryptów użytkownika, uruchamianych jako procesy potomne. |
+| `shared` | Biblioteka pomocnicza, przechowująca logikę wspólną dla wszystkich modułów. |
-> The installation guide assumes you have already installed [Rust](https://www.rust-lang.org/learn/get-started).
+Projekt generuje trzy niezależne pliki wykonywalne: `meva`, `meva-gui` oraz `meva-server` odpowiednio dla modułów `cli`, `gui` oraz `server`.
-### Building the project
+### Model rozproszony i architektura repozytoriów
-To build all crates in the workspace:
+System kontroli wersji MEVA należy do klasy systemów rozproszonych (DVCS ang. _Distributed Version Control System_). W przeciwieństwie do systemów scentralizowanych (ang. _centralized_), takich jak SVN, gdzie pełna historia zmian znajduje się wyłącznie na głównym serwerze, w modelu przyjętym przez system MEVA każdy użytkownik posiada własną, kompletną kopię zdalnego repozytorium.
-```bash
-cargo build
+Diagram ilustruje współpracę dwóch niezależnych użytkowników za pośrednictwem węzła centralnego:
+
+
+ 
+
+
+Węzeł oznaczony jako `Repozytorium zdalne` pełni funkcję źródła danych (ang. _single source of truth_). Przechowuje ono wspólną historię projektu, do której dostęp mają wyłącznie uprawnieni użytkownicy. `Użytkownik 2`, za pośrednictwem aplikacji desktopowej (`Klient GUI`), rozpoczyna pracę poprzez wykonania operacji `clone`. Jej wynikiem jest lokalna kopii zdalnego repozytorium, oznaczona na schemacie jako `Repozytorium lokalne 2`.
+
+Zarówno `Użytkownik 1`, korzystający z interfejsu konsolowego (`Klient CLI`), jak i `Użytkownik 2` przesyłają swoje zatwierdzone zmiany za pomocą polecenia `push`. Operacja ta aktualizuje stan zdalnego repozytorium.
+
+W celu zsynchronizowania stanu swojego lokalnego repozytorium z postępami innych członków zespołu, użytkownicy wykorzystują polecenia `fetch` (pobranie brakujących obiektów bez integracji zmian) oraz `pull` (pobranie zmian połączone ze ich scalaniem).
+
+### Warstwa sieciowa i protokoły synchronizacji
+
+System MEVA nie implementuje własnego, niskopoziomowego protokołu transportowego opartego bezpośrednio na gniazdach TCP. Zamiast tego, przyjęto architekturę opartą na tunelowaniu ruchu przez protokół SSH (ang. _Secure Shell_). Całość wymiany danych, w tym negocjacja historii oraz transfer obiektów, odbywa się wewnątrz bezpiecznego kanału.
+
+#### Protokół pobierania danych
+
+Protokół pobierania danych (`meva-upload-pack`) stanowi fundament operacji `fetch` oraz `clone`. Jego zadaniem jest synchronizacja stanu repozytorium lokalnego z repozytorium zdalnym poprzez pobranie jedynie brakujących obiektów historii. Protokół ten jest uruchamiany bezpośrednio po zakończeniu wstępnej fazy rozgłaszania referencji i składa się z dwóch etapów: negocjacji historii oraz transferu danych (generowania i wysyłania paczki).
+
+Diagram sekwencji dla protokołu `meva-upload-pack`:
+
+
+ 
+
+
+#### Protokół wysyłania danych
+
+Protokół wysyłania danych (`meva-receive-pack`) stanowi fundament operacji `push`. Jego zadaniem jest synchronizacja stanu repozytorium zdalnego z repozytorium lokalnym klienta, a także zarządzanie stanem zdalnych referencji. Protokół ten jest uruchamiany bezpośrednio po zakończeniu wstępnej fazy rozgłaszania referencji i składa się z 3 etapów: przesyłania poleceń aktualizacji referencji, transferu danych (generowania i wysyłania paczki) oraz raportowania aktualizacji referencji.
+
+Diagram sekwencji dla protokołu `meva-receive-pack`:
+
+
+ 
+
+
+## Instalacja
+
+Zarówno narzędzie wiersza poleceń (CLI), jak i interfejs graficzny (GUI) są dystrybuowane jako
+samodzielne pliki wykonywalne, co eliminuje konieczność instalowania skomplikowanych zależności
+w systemie użytkownika końcowego.
+
+### Wymagania wstępne i środowisko budowania
+
+System MEVA został napisany w języku [Rust](https://www.rust-lang.org/learn/get-started), dlatego do skompilowania kodu źródłowego wymagana jest obecność dedykowanych dla tego języka narzędzi (ang. _Rust toolchain_). Zalecana wersja kompilatora to 1.88.0 lub nowsza.
+
+Aby zweryfikować poprawność instalacji środowiska, należy wywołać w wierszu poleceń polecenia sprawdzające wersje kompilatora [rustc](https://cargo-book.irust.net/en-us/getting-started/installation.html) oraz menedżera pakietów [cargo](https://cargo-book.irust.net/en-us/getting-started/installation.html):
+
+```sh
+rustc --version
+# rustc 1.88.0 (6b00bc388 2025-06-23)
+
+cargo --version
+# cargo 1.88.0 (873a06493 2025-05-10)
```
-To build a specific crate only:
+### Instalacja klienta CLI
-```bash
-cargo build -p
+Klient wiersza poleceń jest podstawowym narzędziem do interakcji z systemem MEVA. Jego instalacja polega na skompilowaniu kodu źródłowego oraz skonfigurowaniu ścieżek systemowych.
+
+Kompilację należy wykonać z poziomu katalogu głównego projektu, wykorzystując menedżer pa
+kietów cargo:
+
+```sh
+cargo build --release --bin meva
```
-Replace `` with one of: `engine`, `cli`, `gui`, `plugins`, `server`, or `shared`.
+Wygenerowany plik wykonywalny zostanie domyślnie umieszczony w katalogu `target/release/`.
-### Running the project
+Uruchomienie systemu MEVA za pomocą wiersza poleceń z dowolnego miejsca systemu operacyjnego wymaga dodania ścieżki z plikiem wykonywalnym do zmiennej środowiskowej `PATH`.
-To run the CLI binary:
+#### Konfiguracja globalna użytkownika
-```bash
-cargo run -p cli
+Po zainstalowaniu oprogramowania, należy zdefiniować tożsamość użytkownika. Konfiguracja tożsamości polega na określeniu wartości dla kluczy `user.name` oraz `user.email` w globalnym pliku konfiguracyjnym w katalogu domowym użytkownika.
+
+W celu stworzenia pliku konfiguracyjnego oraz ustawienia wartości `user.name` oraz `user.email` należy wykonać następujące polecenia:
+
+```
+meva config create
+meva config set --global user.name "John Doe"
+meva config set --global user.email "john.doe@example.com"
```
-To run the GUI binary:
+### Instalacja klienta GUI
-```bash
-cargo run -p gui
+Aplikacja kliencka z graficznym interfejsem użytkownika MEVA GUI stanowi alternatywę dla narzędzi wiersza poleceń, oferując wizualną reprezentację historii zmian i statusu repozytorium. W celu skompilowanie interfejsu graficznego, należy użyć polecenia:
+
+```sh
+cargo build --release --bin meva-gui
```
-To run the Server binary:
+Podobnie jak w przypadku klienta konsolowego, wynikowy plik wykonywalny (`meva-gui` lub `meva-gui.exe`) zostanie domyślnie umieszczony w katalogu `target/release/`.
-> On Windows
+Uruchomienie aplikacji desktopowej MEVA GUI za pomocą wiersza poleceń z dowolnego miejsca systemu operacyjnego wymaga dodania ścieżki z plikiem wykonywalnym do zmiennej środowi
+skowej `PATH`.
-```bash
-$env:RUST_LOG = "info"; cargo run --bin server -- ".\path\to\mevaserverconfig.toml"
+### Instalacja i konfiguracja serwera SSH
+
+Proces budowania wersji produkcyjnej serwera przebiega analogicznie do procedur opisanych dla narzędzi klienckich. W przypadku serwera SSH cel binarny nazywa się `meva-server`. Właściwe polecenie kompilacji przyjmuje postać:
+
+```sh
+cargo build --release --bin meva-server
```
-> On Linux
+#### Generowanie kluczy kryptograficznych
-```bash
-RUST_LOG=info cargo run --bin server -- ./path/to/mevaserverconfig.toml
+Fundamentem bezpieczeństwa serwera MEVA jest asymetryczna kryptografia oparta na protokole SSH. Aby serwer mógł bezpiecznie zestawiać połączenia i potwierdzać swoją tożsamość przed klientami, konieczne jest wygenerowanie pary kluczy hosta.
+
+Polecenie generujące parę kluczy wygląda następująco:
+
+```sh
+ssh-keygen -t ed25519 -f ./server_host_key -C "meva-server-host"
```
-### Running tests
+#### Struktura katalogów serwera
-To run all tests in the workspace:
+```
+opt/meva-server/
+├── bin/
+│ └── meva-server
+├── config/
+│ ├── mevaserverconfig.toml
+│ ├── access.toml
+│ └── authorized_keys
+├── secrets/
+│ ├── server_host_key
+│ └── server_host_key.pub
+├── logs/
+│ └── ...
+└── repositories/
+ └── ...
+```
-```bash
-cargo test
+| Katalog | Przeznaczenie |
+| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `bin/` | Katalog, w którym przechowywany jest plik wykonywalny zdalnego serwera SSH. |
+| `config/` | Katalog, w którym przechowywane są wszystkie pliki sterujące zachowaniem serwera. |
+| `secrets/` | Katalog dla danych krytycznych z punktu widzenia bezpieczeństwa, w szczególności dla klucza prywatnego serwera. |
+| `logs/` | Katalog na pliki z logami serwera, umożliwiające monitorowanie jego pracy oraz diagnostykę błędów. |
+| `repositories/` | Katalog, w którym serwer przechowuje pliki i historię wszystkich obsługiwanych repozytoriów. Każde repozytorium otrzymuje własny podkatalog, wewnątrz którego znajduje się właściwa baza danych systemu MEVA. |
+
+W systemie MS Windows odpowiednikiem katalogu `opt/` jest folder `Program Files`.
+
+#### Plik z konfiguracją podstawową
+
+```toml
+[server]
+port = 2223
+address = "0.0.0.0"
+host_key = "./secrets/server_host_key"
+repositories_root = "./repositories"
+
+[access]
+authorized_keys = "./config/authorized_keys"
+policy_file = "./config/access.toml"
+
+[logging]
+level = "info"
+detailed = true
+log_file = "./logs/server.log"
+rotate_size = 10485760 # Rotacja przy 10MiB
+keep_logs = 7 # Przechowywanie 7 ostatnich plików
```
-To run tests for a specific crate:
+**Sekcja `[server]`:**
-```bash
-cargo test -p
+Sekcja ta definiuje podstawowe parametry pracy usługi sieciowej oraz lo
+kalizację danych.
+
+- `port`: Numer portu TCP, na którym serwer nasłuchuje połączeń przychodzących (domyślnie 2223, aby uniknąć konfliktu z systemowym SSH na porcie 22).
+- `address`: Adres IP interfejsu sieciowego. Wartość `0.0.0.0` oznacza nasłuchiwanie na wszystkich dostępnych interfejsach sieciowych.
+- `host_key`: Względna lub bezwzględna ścieżka do pliku zawierającego klucz prywatny serwera.
+- `repositories_root`: Ścieżka do katalogu głównego, w którym przechowywane będą wszystkie repozytoria systemu MEVA.
+
+**Sekcja [access]:**
+
+Wskazuje lokalizację plików odpowiedzialnych za uwierzytelnianie i autory
+zację.
+
+- `authorized_keys`: Ścieżka do pliku zawierającego listę kluczy publicznych użytkowników uprawnionych do nawiązania połączenia.
+- `policy_file`: Ścieżka do pliku access.toml, definiującego szczegółowe uprawnienia dla poszczególnych użytkowników i repozytoriów.
+
+**Sekcja [logging]:**
+
+Konfiguruje sposób zbierania logów w trakcie działania serwera.
+
+- `level`: Określa minimalny poziom ważności komunikatów zapisywanych w logach. Możliwe wartości (od najmniej do najbardziej szczegółowych) to:
+ - `error`: Tylko błędy krytyczne uniemożliwiające dalsze działanie.
+ - `warn`: Ostrzeżenia o potencjalnych problemach.
+ - `info`: Standardowe informacje o przebiegu działania operacji.
+ - `debug`: Szczegółowe informacje diagnostyczne przydatne w trakcie diagnozowania błędów.
+- `detailed`: Wartość logiczna (`true`/`false`). Określa sposób formatowania wpisów. Jeśli ustawiona na `true`, logi zawierają dodatkowe metadane, takie jak sygnatura czasowa, nazwa pliku źródłowego i numer linii kodu, w której wystąpiło zdarzenie.
+- `log_file`: Ścieżka do pliku wyjściowego, w którym zapisywane są logi.
+- `rotate_size`: Maksymalny rozmiar pliku logów w bajtach, po przekroczeniu którego następuje jego rotacja (zamknięcie i zmiana nazwy). Wartość 10485760 odpowiada 10 MiB (mebibajtów).
+- `keep_logs`: Liczba plików archiwalnych przechowywanych po rotacji. Starsze pliki są automatycznie usuwane, co pozwala na kontrolowanie zużycia przestrzeni dyskowej.
+
+#### Plik z definicją kontroli dostępu
+
+Wsystemie MEVA zaimplementowano model uprwanień oparty na rolach, definiowanych w pliku `access.toml`. Model ten umożliwia przypisywanie uprawnień odczytu (`read`) oraz zapisu (`write`) zdefiniowanym użytkownikom do poszczególnych repozytoriów. Wpisy w pliku `access.toml` mają postać:
+
+```toml
+[company_project.john-doe]
+read = true
+write = true
```
-### Adding dependencies
+#### Plik z kluczami publicznymi klientów
-You can manage dependencies in your workspace efficiently with Cargo's CLI.
+Plik ten przechowuje listę kluczy publicznych (w formacie SSH Ed25519) użytkowników uprawnionych do łączenia się z serwerem.
+Przykładowy wpis w pliku `authorized_keys` wygląda następująco:
-To add a regular dependency to a chosen crate:
+```txt
+ssh-ed25519 john-doe
+```
+
+gdzie `john-doe` to nazwa użytkownika, która posłuży do jego identyfikacji w systemie uprawnień.
+
+#### Struktura katalogu repozytoriów
+
+Katalog zdefiniowany w pliku konfiguracyjnym `mevaserverconfig.toml` jako `repositories_root` jest miejscem, w którym serwer przechowuje pliki i historię wszystkich obsługiwanych repozytoriów. Każde repozytoium otrzymuje własny podkatalog, wewnątrz którego znajduje się właściwa baza danych systemu MEVA. Gdy użytkownik końcowy wykonuje operację push, przy pomocy interfejsu CLI lub GUI, serwer autoryzuje żądanie, a następnie zapisuje nowe obiekty w odpowiednim podkatalogu.
+
+#### Uruchomienie serwera SSH
+
+Aplikacja `meva-server` przyjmuje ścieżkę do głównego pliku konfiguracyjnego (plik `mevaserverconfig.toml`) jako argument pozycyjny. Dodatkowo, poziom szczegółowości komunikatów diagnostycznych wyświetlanych na standardowym wyjściu (`stdout`) sterowany jest poprzez zmienną środowiskową `RUST_LOG`.
+
+Polecenie uruchomienia serwera w systemie operacyjnym MS Windows:
-```bash
-cargo add -p
+```
+$env:RUST_LOG = "info"; .\bin\meva-server.exe ‘
+"C:\meva\server\config\mevaserverconfig.toml"
```
-To add a development-only dependency:
+Polecenie uruchomienia serwera w systemie operacyjnym Linux:
-```bash
-cargo add --dev -p
+```
+RUST_LOG=info ./bin/meva-server \
+"/opt/meva-server/config/mevaserverconfig.toml"
```
-To remove a dependency from a crate:
+### Weryfikacja instalacji
-```bash
-cargo remove -p
+Aby uruchomić zestaw testów jednostkowych zdefiniowanych w kodzie źródłowym, należy w głównym katalogu projektu wywołać polecenie:
+
+```
+cargo test
```
-Examples:
+Polecenie to automatycznie skompiluje kod w trybie testowym (który może zawierać dodatkowe asercje niewidoczne w wersji produkcyjnej), a następnie uruchomi wszystkie funkcje oznaczone atrybutem `#[test]`.
+
+**Pomyślny przebieg testów:**
-```bash
-cargo add regex -p engine # Regular dependency for 'engine'
-cargo add insta --dev -p plugins # Dev dependency for 'plugins'
-cargo remove regex -p engine # Removes regular regex dependency
```
+...
+test repositories::meva_repository::tests::init_creates_expected_structure ... ok
+test repositories::meva_repository::tests::init_fails_if_repo_already_exists ... ok
+test result: ok. 47 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
+finished in 0.04s
+```
+
+Jeśli środowisko nie spełnia wymagań, testy zakończą się niepowodzeniem, oznaczonym komunikatem `FAILED`:
+
+```
+...
+test repositories::meva_repository::tests::init_creates_expected_structure ... ok
+test repositories::meva_repository::tests::init_fails_if_repo_already_exists ... FAILED
+test result: FAILED. 46 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out;
+finished in 0.01s
+```
+
+## Instrukcja użytkownika
+
+### Praca z interfejsem CLI
+
+#### Wyświetlanie pomocy
+
+Interfejs linii poleceń został wyposażony w mechanizm pomocy o ustandaryzowanym formacie komunikatów oraz walidację wprowadzanych argumentów.
+System pomocy dostępny jest na dwóch poziomach:
+
+- Pomoc globalna: Wywołanie `meva –-help` (lub w wersji skróconej `-h`) wyświetla listę wszystkich dostępnych poleceń podrzędnych wraz z ich krótkim opisem oraz dostępne flagi globalne.
+- Pomoc kontekstowa: Każde polecenie (np. `commit`, `clone`) posiada własny ekran pomocy, dostępny poprzez wywołanie: `meva –-help`. Prezentuje on składnię danej operacji, wymagane i opcjonalne argumenty pozycyjne oraz flagi.
-To share a dependency (or dev-dependency) version across multiple crates, declare it in your workspace root `Cargo.toml` using `[workspace.dependencies]`:
+#### Edycja plików konfiguracyjnych
+
+System MEVA opiera swoje działanie na plikach konfiguracyjnych w formacie [TOML](https://toml.io/pl/v1.0.0). Umożliwiają one dostosowanie zachowania narzędzia, od podstawowych danych użytkownika po ustawienia sieciowe i parametry skryptów użytkownika.
+Zarządzanie konfiguracją odbywa się za pomocą polecenia zbiorczego `meva config`.
+
+**Domyślna zawartość globalnego pliku konfiguracyjnego:**
```toml
-[workspace.dependencies]
-regex = "1.11.1"
+# Meva Configuration File
+# Edit this file to customize your global settings
+[user]
+name = "Your Name"
+email = "your.email@example.com"
+signing_key = "path/to/client/signing/key"
+
+[editor]
+default = "vim"
+
+[plugins]
+enabled = false
+collect_logs = false
```
-In any crate that should use a workspace-provided dependency, reference it like so in its own `Cargo.toml`:
+### Praca z interfejsem GUI
+
+Oprócz interfejsu wiersza poleceń, system MEVA oferuje dedykowaną aplikację desktopową, która ułatwia zarządzanie repozytoriami użytkownikom preferującym środowiska graficzne. GUI stanowi nakładkę na silnik CLI, zapewniając dostęp do ograniczonego zbioru funkcjonalności systemu.
+
+### Praca z serwerem SSH
+
+Bieżące utrzymanie serwera MEVA sprowadza się do zarządzania plikami konfiguracyjnymi znajdującymi się w katalogu `config/`. Poniżej opisano kluczowe procedury administracyjne na przykładzie wdrożenia projektu o nazwie `company_project` dla użytkownika `john-doe`.
+
+#### Tworzenie repozytorium
+
+Fizyczne utworzenie struktury danych repozytorium odbywa się poprzez polecenie `meva init` wywołane w stworzonym dla projektu katalogu umieszczonym wewnątrz katalogu `repositories/`. Wprzypadku projektu o nazwie `company_project` polecenie powinno zostać wywołane z poziomu `repositories/company_project/`.
+
+#### Dodawanie użytkowników
+
+Proces rejestracji nowego użytkownika w systemie składa się z dwóch etapów: wygenerowania pary kluczy po stronie klienta oraz zarejestrowania klucza publicznego na serwerze.
+
+**Generowanie klucza po stronie klienta:**
+
+```sh
+ssh-keygen -t ed25519 -f ./id_ed25519 -C "john-doe"
+```
+
+Wwyniku tej operacji użytkownik uzyskuje plik klucza publicznego `id_ed25519.pub`, którego zawartość musi bezpiecznym kanałem przekazać administratorowi serwera.
+
+Administrator, po otrzymaniu klucza publicznego, musi dodać go do pliku `authorized_keys`, znajdującego się w katalogu konfiguracyjnym serwera
+(np. `/opt/meva-server/config/authorized_keys`). Każdy klucz powinien znajdować się w osobnej linii i kończyć się identyfikatorem użytkownika, który będzie później wykorzystywany w polityce dostępu.
+
+Ostatnim etapem jest zdefiniowanie uprawnień w pliku access.toml. W celu umożliwienia użytkownikowi `john-doe` pracy z repozytorium `company_project`, należy dodać nową sekcję o schematycznej nazwie `[nazwa_projektu.nazwa_użytkownika]`.
+
+**Konfiguracja uprawnień w pliku `access.toml`:**
```toml
-[dependencies]
-regex = { workspace = true }
+[company_project.john-doe]
+read = true
+write = true
+```
-[dev-dependencies]
-rstest.workspace = true # alternative syntax
+
-### Generating docs
+## Generowanie dokumentacji projektu
-To generate documentation for all crates and open it:
+Aby wygenerować dokumentację publicznego API poszczególnych modułów projektu i otworzyć ją w domyślnej przeglądarce należy użyć polecenia:
```bash
cargo doc --open
```
-To include documentation for private items:
+Aby wygenerować kompletną dokumentację, uwzględniającą również elementy prywatne (przydatne dla deweloperów rozwijających projekt) i otworzyć ją w przeglądarce należy użyć polecenia:
```bash
cargo doc --document-private-items --open
diff --git a/docs/images/distributed-architecture.png b/docs/images/distributed-architecture.png
new file mode 100644
index 0000000..742b6a8
Binary files /dev/null and b/docs/images/distributed-architecture.png differ
diff --git a/docs/images/feather.png b/docs/images/feather.png
new file mode 100644
index 0000000..80e1152
Binary files /dev/null and b/docs/images/feather.png differ
diff --git a/docs/images/gui/gui-branch.png b/docs/images/gui/gui-branch.png
new file mode 100644
index 0000000..d8bbadd
Binary files /dev/null and b/docs/images/gui/gui-branch.png differ
diff --git a/docs/images/gui/gui-clone-repo.png b/docs/images/gui/gui-clone-repo.png
new file mode 100644
index 0000000..75bd33f
Binary files /dev/null and b/docs/images/gui/gui-clone-repo.png differ
diff --git a/docs/images/gui/gui-commit-modal.png b/docs/images/gui/gui-commit-modal.png
new file mode 100644
index 0000000..11d066f
Binary files /dev/null and b/docs/images/gui/gui-commit-modal.png differ
diff --git a/docs/images/gui/gui-config-error.png b/docs/images/gui/gui-config-error.png
new file mode 100644
index 0000000..4b4dbd6
Binary files /dev/null and b/docs/images/gui/gui-config-error.png differ
diff --git a/docs/images/gui/gui-conflict-editor.png b/docs/images/gui/gui-conflict-editor.png
new file mode 100644
index 0000000..e69048e
Binary files /dev/null and b/docs/images/gui/gui-conflict-editor.png differ
diff --git a/docs/images/gui/gui-conflict-mark.png b/docs/images/gui/gui-conflict-mark.png
new file mode 100644
index 0000000..8f1c64b
Binary files /dev/null and b/docs/images/gui/gui-conflict-mark.png differ
diff --git a/docs/images/gui/gui-conflict-menu.png b/docs/images/gui/gui-conflict-menu.png
new file mode 100644
index 0000000..8517582
Binary files /dev/null and b/docs/images/gui/gui-conflict-menu.png differ
diff --git a/docs/images/gui/gui-conflict-unmerged.png b/docs/images/gui/gui-conflict-unmerged.png
new file mode 100644
index 0000000..54d7375
Binary files /dev/null and b/docs/images/gui/gui-conflict-unmerged.png differ
diff --git a/docs/images/gui/gui-context-menu.png b/docs/images/gui/gui-context-menu.png
new file mode 100644
index 0000000..92bd258
Binary files /dev/null and b/docs/images/gui/gui-context-menu.png differ
diff --git a/docs/images/gui/gui-create-repo.png b/docs/images/gui/gui-create-repo.png
new file mode 100644
index 0000000..00efe31
Binary files /dev/null and b/docs/images/gui/gui-create-repo.png differ
diff --git a/docs/images/gui/gui-dashboard.png b/docs/images/gui/gui-dashboard.png
new file mode 100644
index 0000000..a5c87ca
Binary files /dev/null and b/docs/images/gui/gui-dashboard.png differ
diff --git a/docs/images/gui/gui-diff.png b/docs/images/gui/gui-diff.png
new file mode 100644
index 0000000..09e1cf2
Binary files /dev/null and b/docs/images/gui/gui-diff.png differ
diff --git a/docs/images/gui/gui-history.png b/docs/images/gui/gui-history.png
new file mode 100644
index 0000000..173a090
Binary files /dev/null and b/docs/images/gui/gui-history.png differ
diff --git a/docs/images/gui/gui-menu-file.png b/docs/images/gui/gui-menu-file.png
new file mode 100644
index 0000000..011d0ea
Binary files /dev/null and b/docs/images/gui/gui-menu-file.png differ
diff --git a/docs/images/gui/gui-open-error.png b/docs/images/gui/gui-open-error.png
new file mode 100644
index 0000000..03c411c
Binary files /dev/null and b/docs/images/gui/gui-open-error.png differ
diff --git a/docs/images/gui/gui-plugin-edit.png b/docs/images/gui/gui-plugin-edit.png
new file mode 100644
index 0000000..6847beb
Binary files /dev/null and b/docs/images/gui/gui-plugin-edit.png differ
diff --git a/docs/images/gui/gui-plugin-register.png b/docs/images/gui/gui-plugin-register.png
new file mode 100644
index 0000000..6442ae5
Binary files /dev/null and b/docs/images/gui/gui-plugin-register.png differ
diff --git a/docs/images/gui/gui-plugins-list-disabled.png b/docs/images/gui/gui-plugins-list-disabled.png
new file mode 100644
index 0000000..6484898
Binary files /dev/null and b/docs/images/gui/gui-plugins-list-disabled.png differ
diff --git a/docs/images/gui/gui-plugins-list-enabled.png b/docs/images/gui/gui-plugins-list-enabled.png
new file mode 100644
index 0000000..64f4ee6
Binary files /dev/null and b/docs/images/gui/gui-plugins-list-enabled.png differ
diff --git a/docs/images/gui/gui-settings-view.png b/docs/images/gui/gui-settings-view.png
new file mode 100644
index 0000000..da63684
Binary files /dev/null and b/docs/images/gui/gui-settings-view.png differ
diff --git a/docs/images/gui/gui-staging.png b/docs/images/gui/gui-staging.png
new file mode 100644
index 0000000..bf4a967
Binary files /dev/null and b/docs/images/gui/gui-staging.png differ
diff --git a/docs/images/gui/gui-status-bar.png b/docs/images/gui/gui-status-bar.png
new file mode 100644
index 0000000..4d23efe
Binary files /dev/null and b/docs/images/gui/gui-status-bar.png differ
diff --git a/docs/images/gui/gui-sync-actions.png b/docs/images/gui/gui-sync-actions.png
new file mode 100644
index 0000000..97f6cdd
Binary files /dev/null and b/docs/images/gui/gui-sync-actions.png differ
diff --git a/docs/images/receive-pack.png b/docs/images/receive-pack.png
new file mode 100644
index 0000000..7285452
Binary files /dev/null and b/docs/images/receive-pack.png differ
diff --git a/docs/images/upload-pack.png b/docs/images/upload-pack.png
new file mode 100644
index 0000000..b6c973b
Binary files /dev/null and b/docs/images/upload-pack.png differ