diff --git a/soneta-addon-planning/Planowanie.md b/soneta-addon-planning/Planowanie.md
new file mode 100644
index 0000000..02783d5
--- /dev/null
+++ b/soneta-addon-planning/Planowanie.md
@@ -0,0 +1,283 @@
+
+# Proces planowania projektu modułu/dodatku Soneta
+
+## Część I: Zasady procesu planowania
+
+### Przeznaczenie dokumentu planu projektu
+Planowanie projektów modułów funkcjonalności dla platformy Soneta. Firma Soneta tworzy dwa programy: enova365 oraz Triva — oba oparte na tej samej platformie technologicznej.
+Przygotowuje opis funkcjonalności nowego modułu z punktu widzenia używania go do stworzenia kolejnych planów implementacji poszczególnych elementów programu Soneta.
+Plan będzie wykorzystywany w kolejnych etapach do budowania:
+* struktury bazy danych,
+* listy dostępnych list i widoków,
+* innych ważnych/kluczowych elementów interfejsu,
+* formularzy,
+* tworzenia raportów i wydruków,
+* praw dostępu,
+* ról operatorów,
+* zaplanowania testów,
+* budowy dokumentacji
+* i innych tego typu elementów projektu.
+
+### Poziom szczegółowości
+Plan projektu zawiera ogólne opisy elementów projektu. Nie zawiera szczegółowych informacji, które będą uzupełniane w kolejnych etapach. Na tym etapie chodzi o określenie ogólnych założeń, zakresu funkcjonalności i kluczowych elementów modułu.
+
+### Etapowość procesu
+Proces planowania składa się z trzech etapów o rosnącym poziomie szczegółowości:
+- **ETAP 1** — Wizja i kontekst biznesowy (dla decydentów, marketingu, sprzedaży)
+- **ETAP 2** — Architektura modułu (dla zespołu projektowego)
+- **ETAP 3** — Specyfikacja szczegółowa (dla zespołu implementacyjnego i AI)
+
+Każdy etap powinien być zatwierdzony przed przejściem do kolejnego.
+
+---
+
+## Część II: Struktura dokumentu planu projektu
+
+## ETAP 1: Wizja i kontekst biznesowy
+
+### 1.1. Cel biznesowy projektu
+Krótka informacja — cztery, pięć zdań o tym co jest celem projektu. Jaki jest jego kluczowy element. Najważniejsza rzecz, którą chcemy osiągnąć.
+Plan powinien rozpoczynać się podstawową ideą, którą chcemy osiągnąć w danym module — np. przygotowanie danych, które dopiero później będą wykorzystywane do analizy za pomocą innych narzędzi.
+
+### 1.2. Profil klienta docelowego
+Ogólne określenie użytkownika końcowego, który będzie używał tego rozwiązania. Firma mała, średnia, duża? Branża? Działalność?
+
+### 1.3. Korzyści dla klienta
+Zdefiniowanie najważniejszych korzyści dla klienta, określenie problemów rozwiązywanych przez moduł. Informacja ma być wykorzystywana w działach marketingu i sprzedaży, a także jako wprowadzenie do spotkań w temacie modułu.
+
+### 1.4. Najważniejsze funkcjonalności (priorytetyzacja)
+Krótka lista najważniejszych funkcjonalności modułu z podziałem na priorytety:
+- **Krytyczne (must-have)** — funkcjonalności bez których moduł nie ma sensu, sedno modułu. Wskazać które elementy interfejsu i funkcjonalności są kluczowe dla sukcesu produktu.
+- **Ważne (should-have)** — istotne funkcjonalności, ale moduł może działać bez nich w pierwszej wersji.
+- **Opcjonalne (nice-to-have)** — funkcjonalności dodatkowe, które mogą być zrealizowane w kolejnych wersjach.
+
+Te funkcjonalności będą szczegółowo opisywane w kolejnych etapach — w Etapie 2 na poziomie architektury, a w Etapie 3 jako specyfikacja szczegółowa (sekcje 3.1–3.12).
+
+### 1.5. Scenariusze użytkownika
+Opis kilku kluczowych scenariuszy użytkownika, które pokazują jak użytkownik będzie korzystał z modułu. Scenariusze powinny być opisane w formie krok po kroku, pokazując jakie działania użytkownik będzie podejmował, ogólnie jakie dane będzie wprowadzał, jakie wyniki będzie otrzymywał. Scenariusze powinny ograniczyć się tylko do najważniejszych, kluczowych danych. Szczegóły będą uzupełniane w kolejnych etapach.
+
+### 1.6. Procesy biznesowe
+Procesy biznesowe, które będą realizowane w całości przez moduł, ale także inne procesy biznesowe, w których części realizacji będzie wykorzystana funkcjonalność modułu, włącznie z pozostałymi elementami programu.
+Zdefiniowane procesy będą wykorzystane później do stworzenia procesów workflow, a także do przypisania ich do poszczególnych operatorów i ról.
+
+### 1.7. Ograniczenia modułu i wymagania licencyjne
+Określenie ograniczeń modułu, które mogą dotyczyć:
+- zakresu funkcjonalności,
+- wymagań technicznych,
+- integracji z innymi systemami,
+- ograniczeń wynikających z przepisów prawa.
+
+Określenie wymagań licencyjnych — jakie licencje są wymagane do działania modułu, zarówno licencje Soneta, jak i ewentualne licencje zewnętrzne.
+
+### 1.8. Założenia i zależności
+Określenie warunków, które muszą być spełnione, aby projekt mógł być zrealizowany:
+- **Założenia** — co zakładamy jako pewne (np. dostępność określonych modułów programu Soneta, wersja platformy, dostęp do API zewnętrznych systemów).
+- **Zależności** — od czego projekt jest uzależniony (np. zakończenie innego projektu, dostarczenie danych przez klienta, dostępność zespołu).
+
+### 1.9. Ryzyka projektu
+Identyfikacja kluczowych ryzyk z określeniem prawdopodobieństwa i wpływu:
+- **Ryzyka techniczne** — np. ograniczenia platformy, wydajność przy dużych wolumenach danych.
+- **Ryzyka biznesowe** — np. zmiana wymagań prawnych, brak zainteresowania rynku.
+- **Ryzyka integracyjne** — np. niekompatybilność z innymi modułami, zmiany w API zewnętrznych systemów.
+
+Dla każdego ryzyka wskazać plan mitygacji lub działania zapobiegawcze.
+
+### 1.10. Kryteria akceptacji
+Określenie mierzalnych kryteriów, po spełnieniu których moduł zostanie uznany za gotowy do wdrożenia:
+- Kryteria funkcjonalne — jakie scenariusze muszą działać poprawnie.
+- Kryteria wydajnościowe — orientacyjne wolumeny danych (ile rekordów, jak często przetwarzane), akceptowalne czasy odpowiedzi.
+- Kryteria jakościowe — pokrycie testami, brak błędów krytycznych.
+
+### 1.11. Harmonogram i kamienie milowe
+Określenie ramowego harmonogramu realizacji projektu z uwzględnieniem kluczowych kamieni milowych:
+- **Fazy projektu** — podział realizacji na fazy (np. planowanie, implementacja MVP, testy, wdrożenie pilotażowe, produkcja) z orientacyjnymi ramami czasowymi.
+- **Kamienie milowe** — kluczowe punkty kontrolne projektu, np.:
+  - Zatwierdzenie specyfikacji (koniec Etapu 3).
+  - Gotowość MVP (funkcjonalności krytyczne).
+  - Zakończenie testów integracyjnych.
+  - Wdrożenie pilotażowe u pierwszego klienta.
+  - Wydanie wersji produkcyjnej.
+- **Zależności czasowe** — powiązanie kamieni milowych z zależnościami zdefiniowanymi w sekcji 1.8, uwzględniając czynniki mogące wpłynąć na harmonogram.
+
+Harmonogram na tym etapie ma charakter orientacyjny i służy do ogólnego planowania zasobów oraz koordynacji z innymi projektami. Szczegółowy plan realizacji powstaje w fazie implementacji.
+
+
+## ETAP 2: Architektura modułu
+
+### 2.1. Role użytkowników
+Lista operatorów, którzy będą korzystać z modułu. Jakie zadania będą realizować. W jakich procesach będą uczestniczyć.
+
+### 2.2. Zakres konfiguracji modułu
+Opisy elementów systemu, które będą konfigurowane. Ogólny opis zakresu konfiguracji, pozwalający na dostosowanie modułu do różnych potrzeb różnych klientów. Określenie ewentualnych definicji dokumentów, słowników, konfigurowanych ustawień, opcji programu dostępnych tylko dla pewnych grup klientów.
+Uwzględnić ustawienia definiowane w procesie konfigurowania programu, a także różnego rodzaju definicje wykorzystywane jako podpowiedzi przy przetwarzaniu danych operacyjnych.
+
+### 2.3. Kluczowe struktury danych
+Określenie najważniejszych struktur danych, które będą podstawą modułu. Podstawowe listy dokumentów, kartoteki. Bez opisu szczegółowej zawartości, która będzie określona w kolejnym etapie.
+Wskazanie ogólnego diagramu relacji między głównymi obiektami modułu.
+
+Przy projektowaniu struktur danych należy odwoływać się do aktualnego modelu danych programu Soneta opisanego w pliku `tables.md`. Plik zawiera pełną listę modułów, tabel, obiektów i relacji platformy. Pozwala to na:
+- sprawdzenie, czy potrzebne struktury danych już istnieją w programie (unikanie duplikacji),
+- identyfikację tabel nadrzędnych, do których nowe obiekty mogą się odwoływać,
+- rozpoznanie wzorców projektowych stosowanych w istniejących modułach (np. podział na tabele konfiguracyjne i operacyjne, stosowanie definicji dokumentów, definiowanie obiektów głównych - Guided oraz szczegółownych będących w realcji do nich, budowania datapack-ów).
+
+### 2.4. Struktura menu i elementy interfejsu
+Określenie folderów i elementów interfejsu dostępnych z punktu widzenia modułu. Wskazanie hierarchii list w menu głównym i grupowania funkcjonalnego.
+Wyróżnienie elementów interfejsu, które są szczególnie ważne dla sukcesu produktu — np. w module kontrolingu kluczowym elementem może być miejsce do budowania zapytań i warunków (na podobieństwo arkusza Excel, na zasadzie AND/OR).
+
+### 2.5. Relacje z modułami programu Soneta
+Określenie zmian w aktualnych strukturach programu Soneta, które są potrzebne do realizacji tego modułu.
+Określenie tabel i danych z programu Soneta, które będą wykorzystywane przez moduł — z krótkim opisem celu użycia tych danych.
+
+Plik `tables.md` zawiera kompletny opis aktualnych modułów i tabel programu Soneta. Na jego podstawie należy:
+- wskazać konkretne moduły programu Soneta, z którymi projektowany moduł będzie współpracować (np. Handel, Kadry, Ksiega, CRM),
+- wymienić konkretne tabele i obiekty z tych modułów, do których nowy moduł będzie się odwoływać (relacje lookup/inner),
+- określić, czy realizacja modułu wymaga rozszerzenia istniejących tabel programu Soneta (np. dodania nowych kolumn lub relacji do już istniejących obiektów).
+
+### 2.6. Relacje z innymi systemami
+Określenie relacji z innymi systemami, które będą wykorzystywane przez moduł, ale także innych systemów, które będą integrowane z modułem. Określenie jakie dane będą wymieniane między modułem a innymi systemami, jakie procesy będą realizowane w ramach tej integracji.
+Określenie jakiego typu dane będą potrzebne do zasilania systemu BI, a także jakie dane będą dostarczane z systemu BI do modułu.
+
+### 2.7. Migracja danych
+Określenie czy klient posiada dane do zaimportowania z istniejących systemów. Wskazanie:
+- Jakie dane wymagają migracji (kartoteki, dokumenty historyczne, salda).
+- Źródła danych (inne systemy ERP, arkusze Excel, bazy danych).
+- Wymagania dotyczące zachowania historii danych.
+
+### 2.8. Wydajność i skalowalność
+Określenie założeń wydajnościowych wpływających na decyzje architektoniczne modułu:
+- **Wolumeny danych** — przewidywana liczba rekordów w kluczowych tabelach (bieżąca i docelowa po kilku latach użytkowania), częstotliwość operacji zapisu i odczytu.
+- **Optymalizacja dostępu do danych** — wskazanie tabel i operacji wymagających szczególnej uwagi pod kątem wydajności (np. dedykowane indeksy, widoki, denormalizacja, mechanizmy cache).
+- **Przetwarzanie wsadowe vs. online** — określenie, które operacje muszą działać w czasie rzeczywistym (interakcja użytkownika), a które mogą być realizowane w tle lub w trybie wsadowym (np. przeliczenia, generowanie raportów, synchronizacja danych).
+- **Skalowalność** — jak moduł powinien zachowywać się przy rosnącej liczbie użytkowników, rekordów i równoczesnych operacji. Wskazanie potencjalnych wąskich gardeł i sposobów ich unikania.
+
+### 2.9. Kierunki rozwoju modułu w przyszłości
+Określenie kierunków rozwoju modułu w przyszłości, jakie funkcjonalności mogą być dodane w kolejnych etapach, które nie powinny być rozwijane w tej wersji rozwiązania. O ile taki rozwój jest planowany.
+
+
+## ETAP 3: Specyfikacja szczegółowa
+
+### 3.1. Dane operacyjne
+Rozwinięcie struktur danych operacyjnych. Wskazanie ich dodatkowych cech, jak historyczność danych, wykorzystanie numeracji dokumentów. Wyszczególnienie pól danych. Określenie list szczegółowych w ramach obiektu. Określenie relacji do innych danych modułu, a także innych danych programu Soneta (poza projektowanym modułem).
+Określenie części konfiguracyjnej, jak typy, definicje, słowniki, itp. powiązanych z omawianym obiektem.
+Przykład: Dokument jest numerowany, określa datę wprowadzenia, zatwierdzenia, stany (bufor, zatwierdzony, odrzucony), jest powiązany z pracownikiem.
+Przypisany do definicji dokumentu określającej zasady numeracji, tytuł dokumentu, warunki akceptacji, itp.
+
+Przy specyfikowaniu danych operacyjnych należy korzystać z pliku `tables.md` w celu:
+- odwoływania się do istniejących tabel programu Soneta po ich nazwach (kolumna „Tabela") i obiektach biznesowych (kolumna „Obiekt"),
+- wykorzystania informacji o hierarchii nadrzędności tabel (kolumna „Nadrzędny") jako wzorca dla projektowania relacji inner w nowym module,
+- rozróżnienia tabel konfiguracyjnych i operacyjnych (kolumna „Konfiguracyjna") — ten sam podział powinien być stosowany w nowym module,
+- identyfikacji istniejących słowników, definicji i kartotek, do których nowe obiekty powinny się odwoływać zamiast tworzyć własne duplikaty.
+
+### 3.2. Diagram relacji
+Graficzne przedstawienie relacji między tabelami modułu oraz relacji do tabel innych modułów programu Soneta. Diagram powinien pokazywać:
+- Relacje 1:N (inner) — tabele szczegółów
+- Relacje N:1 (lookup) — odwołania do słowników i kartotek
+- Relacje do tabel spoza modułu
+
+Tabele spoza modułu powinny być identyfikowane na podstawie pliku `tables.md` — używając nazw tabel i obiektów tam zdefiniowanych. Diagram powinien wskazywać moduł źródłowy dla każdej tabeli zewnętrznej (np. `Kontrahenci` z modułu CRM, `Pracownicy` z modułu Kadry).
+
+### 3.3. Relacje do danych programu
+Określenie relacji do danych programu Soneta spoza modułu, które będą integrowane z modułem. Określenie jakie dane będą wymieniane między modułem, a innymi danymi programu Soneta.
+
+Dla każdej relacji do danych programu należy na podstawie pliku `tables.md` wskazać:
+- nazwę modułu programu Soneta (np. Handel, Kadry, Ksiega, CRM, Towary, Kasa),
+- konkretną tabelę i obiekt biznesowy (np. tabela `Kontrahenci`, obiekt `Kontrahent` z modułu CRM),
+- typ relacji (lookup — odwołanie do istniejącego obiektu, inner — tabela szczegółów, powiązanie logiczne),
+- cel użycia danych z tej tabeli w kontekście projektowanego modułu.
+
+### 3.4. Podstawowe listy modułu
+Wyszczególnienie głównych list obiektów modułu.
+Wyspecyfikowanie podstawowych kolumn listy, oraz kolumn opcjonalnych dostępnych dopiero w opcjach konfiguracyjnych.
+Określenie podstawowych pól filtrujących dane, podstawowych filtrów oraz dodatkowych (po rozwinięciu).
+
+### 3.5. Formularze
+Wyszczególnienie podstawowych formularzy obiektów dostępnych z list. Opisanie ich zawartości, pól znajdujących się w obiekcie oraz list szczegółowych. Pogrupowanie danych w zakładki oraz grupy na zakładkach.
+
+### 3.6. Workery i czynności
+Określenie akcji i operacji dostępnych dla użytkownika na listach i formularzach modułu:
+- **Czynności na formularzach** — akcje dostępne w menu „Czynności" na poszczególnych obiektach (np. zatwierdzanie, anulowanie, kopiowanie, generowanie powiązanych dokumentów). Dla każdej czynności wskazać: warunki dostępności (np. stan dokumentu), efekt działania, wymagane uprawnienia.
+- **Czynności na listach** — operacje grupowe dostępne na listach (np. zatwierdzanie wielu dokumentów, eksport, zbiorowe przypisanie).
+- **Workery** — procesy działające w tle, realizujące operacje wymagające dłuższego przetwarzania (np. przeliczenia, synchronizacja z systemami zewnętrznymi, generowanie raportów wsadowych). Wskazać wyzwalacze (ręczne, harmonogramowe, zdarzeniowe) oraz oczekiwane czasy wykonania.
+
+### 3.7. Raporty i wydruki
+Określenie raportów i wydruków dostępnych w module:
+- **Wydruki dokumentów** — wydruki powiązane z konkretnymi obiektami (np. wydruk dokumentu, karty obiektu). Wskazać format (PDF, Excel), szablon, dane zawarte na wydruku.
+- **Raporty zbiorcze** — raporty generowane na podstawie list lub danych zagregowanych (np. zestawienia, podsumowania okresowe). Wskazać parametry wejściowe (zakres dat, filtry), układ danych, grupowania.
+- **Eksport danych** — możliwości eksportu danych z list do formatów zewnętrznych (Excel, CSV).
+
+### 3.8. Procesy Workflow
+Uszczegółowienie procesów biznesowych zdefiniowanych w sekcji 1.6 do poziomu implementacyjnego:
+- **Stany obiektów** — lista stanów, przez które przechodzi obiekt w ramach procesu (np. Bufor → Zatwierdzony → W realizacji → Zakończony → Anulowany).
+- **Przejścia między stanami** — warunki i reguły przejść (kto może zatwierdzić, jakie warunki muszą być spełnione, czy przejście jest odwracalne).
+- **Automatyzacje** — akcje wykonywane automatycznie przy zmianie stanu (np. wysłanie powiadomienia, zmiana pól, wygenerowanie powiązanego dokumentu).
+- **Ścieżki akceptacji** — jeśli proces wymaga akceptacji przez przełożonego lub inną rolę, określić ścieżkę i reguły eskalacji.
+
+### 3.9. Uprawnienia i role
+Szczegółowa specyfikacja modelu uprawnień modułu:
+- **Matryca uprawnień** — tabela określająca dostęp poszczególnych ról (zdefiniowanych w sekcji 2.1) do funkcjonalności modułu:
+
+| Funkcjonalność | Rola A | Rola B | Rola C |
+|----------------|--------|--------|--------|
+| Lista X — odczyt | Tak | Tak | Nie |
+| Lista X — edycja | Tak | Nie | Nie |
+| Czynność Y | Tak | Nie | Nie |
+
+- **Uprawnienia do danych** — ograniczenia widoczności danych w zależności od roli (np. operator widzi tylko swoje dokumenty, kierownik widzi dokumenty podwładnych).
+- **Uprawnienia konfiguracyjne** — kto może modyfikować ustawienia, definicje i słowniki modułu.
+
+### 3.10. Integracje szczegółowe
+Uszczegółowienie integracji zdefiniowanych w sekcjach 2.5 i 2.6 do poziomu implementacyjnego:
+- **API i protokoły** — specyfikacja interfejsów wymiany danych (REST, SOAP, pliki CSV/XML, bezpośredni dostęp do bazy).
+- **Formaty danych** — struktura wymienianych komunikatów i plików, mapowanie pól.
+- **Częstotliwość i tryb synchronizacji** — import/eksport jednorazowy, cykliczny (harmonogram), w czasie rzeczywistym (zdarzeniowy).
+- **Obsługa błędów** — postępowanie w przypadku niedostępności systemu zewnętrznego, walidacja danych wejściowych, logowanie błędów.
+
+### 3.11. Scenariusze testowe
+Określenie zakresu testów wymaganych do weryfikacji modułu:
+- **Testy funkcjonalne** — scenariusze testowe pokrywające kluczowe ścieżki użytkownika zdefiniowane w sekcji 1.5. Dla każdego scenariusza: kroki, dane wejściowe, oczekiwany rezultat.
+- **Testy integracyjne** — weryfikacja poprawności współpracy z innymi modułami programu Soneta i systemami zewnętrznymi.
+- **Testy wydajnościowe** — weryfikacja założeń z sekcji 2.8 (wolumeny danych, czasy odpowiedzi).
+- **Przypadki brzegowe** — scenariusze nietypowe i graniczne (puste dane, maksymalne wolumeny, równoczesna edycja, brak uprawnień).
+
+### 3.12. Dane demonstracyjne
+Określenie jakie dane przykładowe powinny być przygotowane:
+- Dane do bazy Demo — reprezentatywne scenariusze pokazujące możliwości modułu.
+- Dane do testów — zestawy danych pokrywające przypadki brzegowe i typowe scenariusze.
+
+### 3.13. Słownik terminów
+Definicje kluczowych terminów biznesowych i technicznych używanych w kontekście modułu. Szczególnie ważne przy modułach domenowych (np. kontroling, logistyka), gdzie terminologia może być niejednoznaczna lub specyficzna dla branży.
+
+
+## Otwarte kwestie
+Miejsce na nierozstrzygnięte pytania i decyzje do podjęcia w trakcie planowania. Kwestie mogą pojawiać się na każdym etapie — od wizji po specyfikację szczegółową:
+
+| Nr | Etap | Kwestia | Status | Decyzja |
+|----|------|---------|--------|---------|
+| 1 | | [Opis problemu do rozstrzygnięcia] | Otwarta/Zamknięta | [Podjęta decyzja] |
+
+
+## Przygotowanie dokumentu TODO
+
+Dokument powinien określać kolejne kroki w projekcie i procesie implementacji. Powinien to być osobny dokument, wykorzystywany przez zespół implementacyjny oraz AI do realizacji kolejnych kroków tworzenia modułu, ale także przez inne działy firmy Soneta, jak marketing, sprzedaż czy dział wsparcia. Dokument powinien być aktualizowany w trakcie realizacji projektu, a także po jego zakończeniu, w celu określenia kolejnych kroków rozwoju modułu.
+
+### Uzupełnienie planu (do realizacji przed implementacją)
+- [ ] Weryfikacja i zatwierdzenie Etapu 1 przez interesariuszy
+- [ ] Weryfikacja i zatwierdzenie Etapu 2 przez zespół projektowy
+- [ ] Uzupełnienie specyfikacji szczegółowej (Etap 3) dla wszystkich obiektów modułu
+- [ ] Zamknięcie otwartych kwestii
+
+### Implementacja
+- [ ] Określenie modelu danych projektu, takich jak tabele, pola, relacje, itp.
+- [ ] Zbudowanie na podstawie modelu pliku business.xml
+- [ ] Struktura menu modułu, listy, widoki
+- [ ] Wyglądy formularzy, ich zakładek
+- [ ] Zakładki konfiguracji, takich jak słowniki, definicje, ustawienia
+- [ ] Workery, menu "Czynności" dostępne na listach i formularzach
+- [ ] Raporty i wydruki dostępne na listach i formularzach
+- [ ] Procesy Workflow w których uczestniczy moduł i realizowane w module
+- [ ] Wskaźniki, listy, agregaty, wykresy BI
+- [ ] Uprawnienia i role użytkowników
+- [ ] Punkty styku/integracji z innymi systemami
+- [ ] Uzupełnienie bazy Demo i inne bazy demonstracyjne
+- [ ] Testy integracyjne, interfejsowe
+- [ ] Określenie struktury dokumentacji użytkownika i technicznej
diff --git a/soneta-addon-planning/SKILL.md b/soneta-addon-planning/SKILL.md
deleted file mode 100644
index 66d1f99..0000000
--- a/soneta-addon-planning/SKILL.md
+++ /dev/null
@@ -1,118 +0,0 @@
-
-# Uwagi ogólne do tworzenia dokuemntu planowania projektu modułu/dodatku
-
-## Przeznaczenie dokumentu planu projektu
-Planowanie projektów modułów fukcjonalności dla platformy enova365/Soneta Enterprise.
-Przygotowuje opis funkcjonalności nowego modułu z punktu widzenia używania go do stworzenia kolejnych planów implementacji poszczególnych elementów programu Soneta.
-Plan będzie wykorzystywany w kolejnych etapach do budowania:
-* struktury bazy danych,
-* listy dostępnych list i widoków,
-* innych ważnych/kluczowych elementów interfejsu,
-* formularzy,
-* tworzenia raportów i wydruków,
-* praw dostępu,
-* ról operatorów,
-* zaplanowania testów,
-* budowy dokumentacji
-* i innych tego typu elementów prohjektu.
-
-
-## Różne tematy do ujęcia w planie
-- ogarnąć temat licencji w szczególności jakie licencję wymagane są do działania kontrolingu
-- opracować punkty ograniczające modułu. Ograniczenia mogą dotyczyć np. zakresu funkcjonalności, wymagań technicznych, integracji z innymi systemami, czy też ograniczeń wynikających z przepisów prawa.
-- opracować zmiany w aktualnych strukturach programu enova które są potrzebne do realizacji tego modułu
-- opracować tabele i dane które będą wykorzystywane przez moduł kontrolingu, opisać krótko jaki jest cel u tych danych, a które znajdują się w programie enowa
-- Przygotować plan todo czyli kolejne elementy do realizacji po planowaniu
-- plan powinien rozpoczynać się podstawową ideą którą chcemy osiągnąć w danym systemie danym module. w tym przypadku chodzi o to że podstawową rzeczą jest przygotowanie danych które dopiero później będą wykorzystywane do analizy za pomocą innych narzędzi
-- określić jakiego typu dane będą potrzebne do wczytywania systemu BI ale również jakie dane będą dostarczane do systemu BI
-- zdefiniować jakie procesy będą realizowane w ramach danego modułu. Te procesy będą wykorzystane później do stworzenia procesów workflow a także do przypisania ich do poszczególnych operatorów ról
-- określić jakie rolę będą realizowane przez system czyli opisać rolę operatorów i zadania które w ramach tej roli będą realizowane
-- określić foldery i elementy interfejs-owę które będą dostępne z punktu widzenia modułu do opisania są funkcjonalności, które są szczególnie ważne interfejs sowo żeby produkt odniósł sukces. W kontrolingu ważnym elementem będzie miejsce w którym będzie można budować gotowe zapytania i warunki na podobieństwo Arkusz Excel owy m na zasadzie and/or. Wskazać które elementy interfejsu są krytyczne albo są sednem danego modułu
-- określić zakres konfiguracji czyli wskazać ustawienia które będą definiowane w procesie konfigurowania programu a także różnego rodzaju definicję które będą wykorzystywane jako podpowiedzi przetwarzaniu już danych operacyjnych
-
-
-
-## Poziom szczegółowości
-Plan projektu zawiera ogólne opisy elementów projektu. Nie zawiera szczególowych inforamcji, które będą uzupełniane w kolejnych etapach. Na tym etapie chodzi o określenie ogólnych założeń, zakresu funkcjonalności...
-
-## ETAP 1: Określenie ogólnych założeń mmodułu oraz ogólny opis funkcjonalności
-
-## Elementy planu projektu
-
-### Cel biznesowy projektu
-Krótka informacja cztery, pięć zdań o tym co jest celem projektu. Jaki jest jego kluczowy element. Najważniejsza rzecz, którą chcemy osiągnąć.
-
-### Firmy docelowe
-Ogólne określenie użytkownika końcowego, który będzie używał tego rowiązania. Firma mała, średnia, duża? Branża? Działalność?
-
-### Korzyści dla klienta
-Zdefiniowanie najważniejszych korzyści dla klienta, określenie problemów rozwiązywanych przez moduł. Informacja ma być wykorzystywana w działach marketingu i sprzedaży, a także jako wprowadzenie do spotkań w temacie modułu.
-
-### Najważniejsze funkcjonalności
-Krótka lista najważniejszych funkcjonalności modułu. Te funkcjonalności będą szczegółowo opisywane w kolejnych etapach, ale już na tym etapie warto wskazać te kluczowe, które są sednem modułu i które będą najbardziej istotne z punktu widzenia klienta. Wyszczególnione w krótkich punktach.
-
-### Scenariusze użytkownika
-Opis kilku kluczowych scenariuszy użytkownika, które pokazują jak użytkownik będzie korzystał z modułu. Scenariusze powinny być opisane w formie krok po kroku, pokazując jakie działania użytkownik będzie podejmował, ogólnie jakie dane będzie wprowadzał, jakie wyniki będzie otrzymywał. Scenariusze powinny ograniczyć się tylko do najważniejszych,kluczowych danych. Szczegóły będą uzupełniane w kolejnych etapach.
-
-### Proesy biznesowe
-Procesy biznesowe, które będą realizowane w całoci przez moduł, ale także inne procesy biznesowe, w których części realizacji będzie wykorzystana funkcjonalność modułu, włącznie z pozostałymi elementami programu.
-
-
-## ETAP 2: Ogólne określenie szczegółowych elementów projektu
-
-### Role użytkowników. 
-Lista operatorów, którzy będą korzystać z modułu? Jakie zadanie będzie realizować. W jakich procesach będą uczestniczyć? 
-
-### Zakres konfiguracji modułu
-Opisy elementów systemu, które będą konfigurowane. Ogólny opis zakresu konfiguracji, pozwalające na dostosowanie modułu do różnych potrzeb różnych klientów. Określenie ewentualnych definicji dokumentów, słowników, konfigurowanych ustawień, opcji programu dostępnych tylko dla pewnych grup klientów.
-
-### Kluczowe struktury danych
-Określenie najważniejszych struktur danych, które będą podstawą modułu. Podstawowe listy dokumentów, kartoteki. Bez opis szczegółowej zawartości, która będzie okreslona w kolejnym etapie.
-
-## Kierunki rozwoju modułu w przyszłości o ile taki rozwój jest planowany.
-Okreslenie kierunków rozwoju modułu w przyszłości, jakie funkcjonalności mogą być dodane w kolejnych etapach, które nie powinny być rozwijane w tej wersji rozwiązania.
-
-## Relacje z innymi systemami
-Określenie relacji z innymi systemami, które będą wykorzystywane przez moduł, ale także innych systemów, które będą integrowane z modułem. Określenie jakie dane będą wymieniane między modułem a innymi systemami, jakie procesy będą realizowane w ramach tej integracji.
-
-
-## ETAP 2: Uszczegółowienie elementów projektu
-
-### Dane operacyjne
-Rozwiniecie struktu danych operacyjnych. Wskazanie ich dodatkowych cech, jak hostoryczność danych, wykorzystanie numeracji dokumentów. Wyszczególnienie pól danych. Określenie list szczegółowych w ramach obiektu. Określenie relacji do innych danych modułu, a także innych danych programu Soneta (poza projektowanych modułem).
-Określenie części konfiguracyjnej, jak typy definicje, słowniki, itp. powiązanych z omawianym obiektem.
-Przykład: Dokument jest numerowany, określa datę wprowadzenia, zatwierdzenia, stany (bufor, zatwierdzony, odrzucony), jest powiązany z pracownikiem.
-Przypisany do definicji dokumentu. okreslającej zasady numeracji, tytuł dokuemntu, warunki akceptacji, itp.
-
-### Relacje do danych programu
-Określenie relacji do danych programu Soneta z poza modułu, które będą integrowane z modułem. Określenie jakie dane będą wymieniane między modułem, a innymi danymi programu Soneta.
-
-### Podstawowe listy modułu
-Wyszczególnienie głównych list obiektów modułu.
-Wyspecifikowanie podstawowych kolumn listy, oraz kolumn opcjonalnych dostępnych dopiera w opcjach konfiguracyjnych.
-Określenie podstawowych pól filtrtujących dane, podstawowych filtrów oraz dodatkowych (po rozwinięciu).
-
-### Formularze
-Wyszczególnienie podstawowych formularzy obiektów dostępnych z list. Opisanie ich zawartości, pól znajdujących się w obiekcie oraz list szczegółowych. Pogrupowanie danych w zakłądki oraz grupy na zakładkach.
-
-## Przygotowanie dokumentu TODO
-Dokument powinien określać kolejne kroki w projekcie i procesie implementacji. Powinien to być osobny dokument, wykorzystywany przez zespół implementacyjny, oraz AI do realizacji kolejnych kroków tworzenia modułu, ale także przez inne działy firmy Soneta, jak marketing, sprzedaż, czy dział wsparcia. Dokument powinien być aktualizowany w trakcie realizacji projektu, a także po jego zakończeniu, w celu określenia kolejnych kroków rozwoju modułu.
-
-### Punkty do dokumentu TODO:
-- [ ] Określenie modelu danych projektu, takich jak tabele, pola, relacje, itp.
-- [ ] Zbudownie na podstawie modelu pliku business.xml
-- [ ] Struktura menu modułu, listy, widoki
-- [ ] Wyglądy formularzy, ich zakładek
-- [ ] Zakładki konfiguracji, takich jak słowniki, definicje, ustawienia
-- [ ] Workery, menu "Czynności" dostępne na listach i formularzach
-- [ ] Raporty i wydruki dostępne na listach i formularzach
-- [ ] Procesy Workflow w których uczestniczy moduł i realizowane w module
-- [ ] Wskaźniki, listy, agregaty, wykresy BI
-- [ ] Uprawnienia i role użytkowników
-- [ ] Punkty styku/integracji z innymi systemami
-- [ ] Uzupełnienie bazy Demo, i inne bazy demostracyjne
-- [ ] Testy integracyjne, interface-owych
-- [ ] Określenie struktury dokumentacji użytkownika i technicznej
-
-
-
diff --git a/soneta-addon-planning/references/checklist.md b/soneta-addon-planning/references/checklist.md
deleted file mode 100644
index 369cdf3..0000000
--- a/soneta-addon-planning/references/checklist.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# Lista kontrolna planu projektu dodatku enova365
-
-Lista kontrolna do weryfikacji kompletności planu projektu przed rozpoczęciem implementacji.
-
-## 1. Założenia projektu
-
-- [ ] Zdefiniowany cel biznesowy (problem do rozwiązania)
-- [ ] Określony zakres funkcjonalny (lista funkcji)
-- [ ] Wymienione elementy konfigurowalne z opisem sposobu konfiguracji
-- [ ] Zidentyfikowane integracje z istniejącymi modułami enova365
-- [ ] Opisane ograniczenia i wymagania niefunkcjonalne
-
-## 2. Model danych
-
-### Tabele
-
-- [ ] Każda tabela ma określone:
-  - [ ] Nazwę (PascalCase, l.poj.)
-  - [ ] Typ (operacyjna / konfiguracyjna)
-  - [ ] Atrybut guided (Root / Exported / inner / brak)
-  - [ ] Krótki opis przeznaczenia
-
-### Pola
-
-- [ ] Każde pole ma określone:
-  - [ ] Nazwę (PascalCase)
-  - [ ] Typ danych (string, int, date, relacja, enum itp.)
-  - [ ] Wymagalność (Tak/Nie)
-  - [ ] Krótki opis
-
-### Relacje
-
-- [ ] Wszystkie relacje między tabelami są opisane
-- [ ] Tabele szczegółów mają wskazaną tabelę główną (relguided="inner")
-- [ ] Relacje do modułów zewnętrznych są zidentyfikowane
-- [ ] Istnieje diagram relacji lub lista powiązań
-
-### Klucze
-
-- [ ] Zdefiniowane klucze unikalne (keyprimary, keyunique)
-- [ ] Określone klucze wyszukiwania (indeksy)
-
-## 3. Struktura menu
-
-- [ ] Zdefiniowana hierarchia menu modułu
-- [ ] Listy pogrupowane logicznie
-- [ ] Konfiguracja wydzielona do osobnej grupy
-
-## 4. Listy
-
-Dla każdej listy:
-
-- [ ] Określona tabela źródłowa
-- [ ] Opisane przeznaczenie listy
-- [ ] Zdefiniowane filtry:
-  - [ ] Filtry polowe (wyszukiwanie po polach)
-  - [ ] Filtry predefiniowane (najczęstsze scenariusze)
-  - [ ] Filtry zakresowe (daty, wartości)
-- [ ] Określone kolumny z kolejnością
-- [ ] Lista czynności (workerów) z krótkim opisem działania
-- [ ] Lista raportów/wydruków z krótkim opisem zawartości
-
-## 5. Formularze
-
-Dla każdego formularza:
-
-- [ ] Określona tabela źródłowa
-- [ ] Zdefiniowane zakładki:
-  - [ ] Nazwa zakładki
-  - [ ] Przeznaczenie (co grupuje)
-- [ ] Pola przypisane do zakładek i grup
-- [ ] Zdefiniowane listy szczegółów (sublists):
-  - [ ] Tabela szczegółów
-  - [ ] Kolumny na liście
-  - [ ] Ewentualne filtry
-- [ ] Lista czynności z kontekstem (pojedynczy/zaznaczone/bez kontekstu)
-- [ ] Lista raportów z kontekstem
-
-## 6. Słowniki i konfiguracja
-
-- [ ] Wszystkie tabele konfiguracyjne zidentyfikowane
-- [ ] Określone wartości początkowe słowników
-- [ ] Zdefiniowane parametry konfiguracyjne modułu
-- [ ] Opisane definicje obiektów (jeśli występują)
-
-## 7. Uprawnienia
-
-- [ ] Zdefiniowane role użytkowników
-- [ ] Przypisane prawa dostępu do:
-  - [ ] List
-  - [ ] Formularzy
-  - [ ] Workerów
-  - [ ] Raportów
-
-## 8. Kompletność ogólna
-
-- [ ] Wszystkie nazwy zgodne z konwencjami enova365
-- [ ] Brak duplikatów nazw tabel/pól
-- [ ] Relacje nie tworzą cykli (poza świadomymi wyjątkami)
-- [ ] Każdy worker i raport ma krótki opis
-- [ ] Otwarte kwestie są udokumentowane
-
-## 9. Gotowość do implementacji
-
-Po pozytywnej weryfikacji listy kontrolnej można przystąpić do:
-
-1. **Generowania business.xml** (skill: enova365-business-xml)
-   - Definicje tabel i relacji
-   - Klucze i indeksy
-   - Enumy i interfejsy
-
-2. **Implementacji logiki** (skill: soneta-programming-basics)
-   - Workery i ich algorytmy
-   - Walidacje biznesowe
-   - Raporty i wydruki
-
----
-
-## Typowe braki do uzupełnienia
-
-| Sekcja | Typowy brak | Jak uzupełnić |
-|--------|-------------|---------------|
-| Model danych | Brak tabeli historii | Dodać tabelę z okresami (FromTo) |
-| Model danych | Brak tabeli notatek/załączników | Rozważyć użycie standardowego mechanizmu Attachments |
-| Listy | Brak filtra po dacie | Dodać filtr zakresowy dla dat |
-| Formularze | Brak zakładki "Historia" | Dodać zakładkę z ChangeInfos |
-| Konfiguracja | Brak statusów | Dodać tabelę słownikową statusów |
-| Uprawnienia | Brak roli administratora | Dodać rolę z pełnymi uprawnieniami |
-
-## Pytania kontrolne
-
-1. Czy użytkownik może wykonać wszystkie operacje biznesowe opisane w zakresie?
-2. Czy dane wprowadzone przez użytkownika mogą być później wyszukane i zmodyfikowane?
-3. Czy administrator może skonfigurować wszystkie elementy konfigurowalne?
-4. Czy można wygenerować wszystkie potrzebne raporty?
-5. Czy uprawnienia pozwalają na bezpieczne rozdzielenie obowiązków?
diff --git a/soneta-addon-planning/references/project-template.md b/soneta-addon-planning/references/project-template.md
deleted file mode 100644
index 4f6ba0c..0000000
--- a/soneta-addon-planning/references/project-template.md
+++ /dev/null
@@ -1,297 +0,0 @@
-# Szablon planu projektu dodatku enova365
-
-Poniżej znajduje się kompletny szablon dokumentu planu projektu. Sekcje oznaczone `[...]` należy wypełnić zgodnie z wymaganiami projektu.
-
----
-
-# Plan projektu: [Nazwa dodatku]
-
-**Wersja:** 1.0  
-**Data:** [Data utworzenia]  
-**Autor:** [Imię i nazwisko]
-
----
-
-## 1. Założenia projektu
-
-### 1.1. Cel biznesowy
-
-[Krótki opis problemu biznesowego, który dodatek ma rozwiązać. 2-3 zdania.]
-
-### 1.2. Zakres funkcjonalny
-
-[Lista głównych funkcjonalności dodatku:]
-- [Funkcjonalność 1]
-- [Funkcjonalność 2]
-- [Funkcjonalność 3]
-
-### 1.3. Elementy konfigurowalne
-
-Elementy, które będą dostosowywane podczas wdrożenia u klienta:
-
-| Element | Opis | Sposób konfiguracji |
-|---------|------|---------------------|
-| [Nazwa elementu] | [Co konfigurujemy] | [Słownik / Parametr / Definicja] |
-
-**Przykłady elementów konfigurowalnych:**
-- Słowniki (statusy, typy, kategorie)
-- Definicje dokumentów (numeracja, pola wymagane)
-- Parametry algorytmów (stawki, progi, limity)
-- Szablony wydruków
-- Uprawnienia i role
-
-### 1.4. Integracje z modułami enova365
-
-| Moduł | Typ integracji | Opis |
-|-------|----------------|------|
-| [Nazwa modułu] | [Odczyt / Zapis / Relacja] | [Krótki opis] |
-
-**Typowe integracje:**
-- **Handel** - dokumenty handlowe, towary, kontrahenci
-- **CRM** - kontrahenci, osoby kontaktowe
-- **Kadry** - pracownicy, struktury organizacyjne
-- **Księgowość** - ewidencje, rozrachunki
-
-### 1.5. Ograniczenia i wymagania niefunkcjonalne
-
-- [Ograniczenie 1]
-- [Wymaganie wydajnościowe]
-- [Wymaganie bezpieczeństwa]
-
----
-
-## 2. Model danych
-
-### 2.1. Tabele operacyjne
-
-Tabele przechowujące dane wprowadzane podczas codziennej pracy.
-
-#### [Nazwa tabeli 1] (guided="Root")
-
-**Opis:** [Krótki opis przeznaczenia tabeli]
-
-| Pole | Typ | Wymagane | Opis |
-|------|-----|----------|------|
-| [Nazwa pola] | [Typ danych] | [Tak/Nie] | [Krótki opis] |
-
-**Klucze:**
-- `Wg[NazwaPola]` - [opis przeznaczenia klucza]
-
-**Relacje:**
-- → [Tabela docelowa] (przez pole [Nazwa pola])
-
-#### [Nazwa tabeli szczegółów] (relguided="inner")
-
-**Opis:** [Pozycje/szczegóły dla tabeli głównej]
-
-| Pole | Typ | Wymagane | Opis |
-|------|-----|----------|------|
-| [Tabela główna] | [Relacja] | Tak | Relacja do obiektu głównego |
-| [Pole szczegółu] | [Typ] | [Tak/Nie] | [Opis] |
-
-### 2.2. Tabele konfiguracyjne
-
-Tabele zawierające dane konfiguracyjne tworzone podczas wdrożenia (config="true").
-
-#### [Nazwa słownika] (config="true")
-
-**Opis:** [Słownik/definicja dla...]
-
-| Pole | Typ | Wymagane | Opis |
-|------|-----|----------|------|
-| Kod | string | Tak | Unikalny kod elementu |
-| Nazwa | string | Tak | Wyświetlana nazwa |
-| Blokada | boolean | Nie | Blokuje wyświetlanie na listach wyboru |
-
-**Wartości początkowe:**
-- [Wartość 1]
-- [Wartość 2]
-
-### 2.3. Diagram relacji
-
-```
-┌─────────────────┐     ┌─────────────────┐
-│  [Tabela główna]│────<│ [Tabela szczeg.]│
-│                 │     │                 │
-│ - Pole1         │     │ - TabelaGłówna  │
-│ - Pole2         │     │ - PoleSzczegółu │
-└────────┬────────┘     └─────────────────┘
-         │
-         │ relacja
-         ▼
-┌─────────────────┐
-│ [Tabela słown.] │
-│   (config)      │
-└─────────────────┘
-
-Legenda:
-────< relacja 1:N (inner)
-────  relacja N:1 (lookup)
-```
-
----
-
-## 3. Struktura menu modułu
-
-### 3.1. Menu główne modułu
-
-```
-[Nazwa modułu]
-├── [Grupa 1]
-│   ├── [Lista 1.1] - [krótki opis]
-│   └── [Lista 1.2] - [krótki opis]
-├── [Grupa 2]
-│   ├── [Lista 2.1] - [krótki opis]
-│   └── [Lista 2.2] - [krótki opis]
-└── Konfiguracja
-    ├── [Słownik 1]
-    └── [Słownik 2]
-```
-
----
-
-## 4. Listy
-
-### 4.1. [Nazwa listy]
-
-**Tabela źródłowa:** [Nazwa tabeli]  
-**Przeznaczenie:** [Krótki opis co lista pokazuje i dla kogo]
-
-#### Filtry
-
-| Filtr | Typ | Opis |
-|-------|-----|------|
-| [Nazwa filtra] | [Pole / Predefiniowany / Zakres dat] | [Opis działania] |
-
-**Filtry predefiniowane:**
-- [Nazwa filtra] - [Warunek filtrowania]
-
-#### Kolumny
-
-| Kolumna | Źródło | Opis |
-|---------|--------|------|
-| [Nagłówek kolumny] | [Nazwa pola lub wyrażenie] | [Opis zawartości] |
-
-#### Czynności (Workery)
-
-| Czynność | Opis |
-|----------|------|
-| [Nazwa czynności] | [Krótki opis działania - 1-2 zdania] |
-
-#### Raporty i wydruki
-
-| Raport | Opis |
-|--------|------|
-| [Nazwa raportu] | [Krótki opis zawartości - 1-2 zdania] |
-
----
-
-## 5. Formularze
-
-### 5.1. Formularz: [Nazwa obiektu]
-
-**Tabela:** [Nazwa tabeli]  
-**Przeznaczenie:** [Edycja/Podgląd obiektu typu...]
-
-#### Zakładki i pola
-
-##### Zakładka: [Nazwa zakładki 1]
-
-**Przeznaczenie:** [Co zawiera ta zakładka]
-
-| Grupa | Pola |
-|-------|------|
-| [Nazwa grupy] | [Pole1], [Pole2], [Pole3] |
-| [Nazwa grupy 2] | [Pole4], [Pole5] |
-
-##### Zakładka: [Nazwa zakładki 2]
-
-**Przeznaczenie:** [Co zawiera ta zakładka]
-
-| Grupa | Pola |
-|-------|------|
-| [Nazwa grupy] | [Pole1], [Pole2] |
-
-#### Listy szczegółów (Sublists)
-
-##### Lista: [Nazwa listy szczegółów]
-
-**Tabela:** [Tabela szczegółów]  
-**Relacja:** [Pole relacji do obiektu głównego]
-
-| Kolumna | Opis |
-|---------|------|
-| [Nazwa kolumny] | [Opis] |
-
-**Filtry listy szczegółów:**
-- [Nazwa filtra] - [Opis]
-
-#### Czynności (Workery)
-
-| Czynność | Kontekst | Opis |
-|----------|----------|------|
-| [Nazwa] | [Pojedynczy obiekt / Zaznaczone / Bez kontekstu] | [Opis] |
-
-#### Raporty i wydruki
-
-| Raport | Kontekst | Opis |
-|--------|----------|------|
-| [Nazwa] | [Pojedynczy / Lista] | [Opis] |
-
----
-
-## 6. Słowniki i konfiguracja
-
-### 6.1. Słowniki
-
-| Słownik | Przeznaczenie | Pola konfiguracyjne |
-|---------|---------------|---------------------|
-| [Nazwa] | [Do czego służy] | [Jakie dodatkowe pola poza Kod/Nazwa] |
-
-### 6.2. Parametry konfiguracyjne modułu
-
-| Parametr | Typ | Domyślnie | Opis |
-|----------|-----|-----------|------|
-| [Nazwa parametru] | [Typ] | [Wartość] | [Co parametr kontroluje] |
-
-### 6.3. Definicje obiektów
-
-| Definicja | Przeznaczenie | Elementy definiowalene |
-|-----------|---------------|------------------------|
-| [Nazwa] | [Typ obiektów, które definiuje] | [Co można skonfigurować w definicji] |
-
----
-
-## 7. Uprawnienia
-
-### 7.1. Role użytkowników
-
-| Rola | Opis | Typowe uprawnienia |
-|------|------|-------------------|
-| [Nazwa roli] | [Kto to jest] | [Ogólny zakres uprawnień] |
-
-### 7.2. Prawa dostępu
-
-| Obiekt/Funkcja | [Rola 1] | [Rola 2] | [Rola 3] |
-|----------------|----------|----------|----------|
-| [Lista/Formularz/Worker] | [Pełny/Odczyt/Brak] | [...] | [...] |
-
----
-
-## 8. Załączniki
-
-### 8.1. Słownik terminów
-
-| Termin | Definicja |
-|--------|-----------|
-| [Termin biznesowy] | [Wyjaśnienie w kontekście dodatku] |
-
-### 8.2. Otwarte kwestie
-
-| Nr | Kwestia | Status | Decyzja |
-|----|---------|--------|---------|
-| 1 | [Opis problemu do rozstrzygnięcia] | [Otwarta/Zamknięta] | [Podjęta decyzja] |
-
----
-
-**Koniec dokumentu**
diff --git a/soneta-addon-planning/references/tables.md b/soneta-addon-planning/tables.md
similarity index 100%
rename from soneta-addon-planning/references/tables.md
rename to soneta-addon-planning/tables.md