soneta-erp-skills/soneta-addon-planning/SKILL.md

name, description

name

description

soneta-addon-planning

Planowanie projektów dodatków dla platformy enova365/Soneta Enterprise. Tworzy kompletną dokumentację projektową obejmującą: strukturę danych (tabele, relacje), elementy konfigurowalne, definicje list i menu, formularze, workery i raporty. Używaj gdy użytkownik prosi o zaplanowanie nowego modułu/dodatku enova365, przygotowanie założeń projektu, stworzenie specyfikacji funkcjonalnej dodatku, lub zdefiniowanie struktury danych i interfejsu użytkownika dla nowego modułu.

Planowanie projektu modułu/dodatku Soneta

Skill prowadzi interaktywny proces planowania nowego modułu dla platformy Soneta (programy enova365 i Triva). Proces przebiega etapowo — każdy etap wymaga zatwierdzenia przez użytkownika przed przejściem do kolejnego.

Przebieg procesu

Proces planowania składa się z trzech etapów o rosnącym poziomie szczegółowości:

1. ETAP 1 — Wizja i kontekst biznesowy (dla decydentów, marketingu, sprzedaży)
2. ETAP 2 — Architektura modułu (dla zespołu projektowego)
3. ETAP 3 — Specyfikacja szczegółowa (dla zespołu implementacyjnego i AI)

Na końcu generowany jest dokument TODO z kolejnymi krokami implementacji.

Jak prowadzić rozmowę

Proces jest interaktywny. Nie generuj całego dokumentu naraz — pracuj etap po etapie:

1. Zbierz informacje — Na początku zapytaj użytkownika o ogólną ideę modułu. Co chce osiągnąć? Dla kogo jest ten moduł? Jaki problem rozwiązuje?
2. Opracuj etap — Na podstawie zebranych informacji wygeneruj dokument danego etapu. Jeśli brakuje Ci informacji, zadaj konkretne pytania zamiast zgadywać.
3. Poczekaj na zatwierdzenie — Przedstaw dokument etapu użytkownikowi i poczekaj na jego akceptację, uwagi lub poprawki. Nie przechodź do kolejnego etapu bez wyraźnej zgody.
4. Iteruj — Jeśli użytkownik ma uwagi, popraw dokument i ponownie przedstaw do zatwierdzenia.
5. Przejdź dalej — Po zatwierdzeniu przejdź do kolejnego etapu, zadając dodatkowe pytania potrzebne do jego opracowania.

Prowadź rozmowę w języku polskim. Zadawaj pytania jedno po drugim — nie zasypuj użytkownika listą 15 pytań naraz. Grupuj pytania tematycznie (2–4 pytania na raz) i dostosowuj kolejne pytania do udzielonych odpowiedzi.

Dane referencyjne — tabele programu Soneta

Plik tables.md zawiera kompletny opis aktualnych modułów i tabel programu Soneta. Jest duży, więc czytaj go selektywnie — tylko moduły istotne dla projektowanego dodatku.

Struktura pliku: nagłówki # Moduł: NazwaModułu z opisem, a pod nimi tabele w formacie:

| Tabela | Obiekt | Tytuł tabeli | Nadrzędny | Konfiguracyjna | Opis |

Kolumny:

• Tabela — nazwa tabeli w bazie danych
• Obiekt — nazwa klasy C# (obiekt biznesowy)
• Nadrzędny — tabela nadrzędna (root = tabela główna, inna nazwa = tabela szczegółów w relacji inner)
• Konfiguracyjna — X = tabela konfiguracyjna (definicje, słowniki, ustawienia), pusta = tabela operacyjna
• Opis — opis przeznaczenia tabeli

Korzystaj z tego pliku aby:

• sprawdzić, czy potrzebne struktury danych już istnieją (unikanie duplikacji),
• wskazać konkretne tabele, do których nowy moduł będzie się odwoływać,
• rozpoznać wzorce projektowe (podział na tabele konfiguracyjne/operacyjne, hierarchia nadrzędny-szczegółowy, stosowanie definicji dokumentów),
• zidentyfikować moduły, z którymi projektowany moduł będzie współpracować.

Gdy użytkownik wspomina o integracji z istniejącymi danymi (np. pracownicy, kontrahenci, towary), przeczytaj odpowiedni moduł z tables.md i wskaż konkretne tabele i obiekty.

---

ETAP 1: Wizja i kontekst biznesowy

Cel: ustalić co budujemy, dla kogo i dlaczego. Dokument tego etapu jest przeznaczony dla decydentów, marketingu i sprzedaży.

Pytania do zadania użytkownikowi

Zacznij od ogólnej idei, potem doprecyzowuj. Nie zadawaj wszystkich pytań naraz.

Pierwsza tura — zrozumienie idei:

• Co jest głównym celem modułu? Jaki problem rozwiązuje?
• Kto jest docelowym użytkownikiem? (mała/średnia/duża firma, branża)

Druga tura — funkcjonalności i korzyści:

• Jakie są najważniejsze funkcjonalności? (kluczowe vs opcjonalne)
• Jakie korzyści uzyska klient?

Trzecia tura — kontekst i ograniczenia:

• Jakie procesy biznesowe realizuje moduł?
• Czy są ograniczenia techniczne, prawne, licencyjne?
• Jakie moduły programu Soneta będą wykorzystywane?

Sekcje dokumentu Etapu 1

Wygeneruj dokument Markdown zawierający te sekcje:

1.1. Cel biznesowy projektu

4–5 zdań o celu projektu, kluczowym elemencie, najważniejszej rzeczy do osiągnięcia. Zacznij od podstawowej idei modułu.

1.2. Profil klienta docelowego

Typ firmy (mała/średnia/duża), branża, działalność.

1.3. Korzyści dla klienta

Najważniejsze korzyści, problemy rozwiązywane przez moduł. Informacja dla marketingu i sprzedaży.

1.4. Najważniejsze funkcjonalności (priorytetyzacja)

Podział na:

• Krytyczne (must-have) — bez nich moduł nie ma sensu
• Ważne (should-have) — istotne, ale moduł może działać bez nich w v1
• Opcjonalne (nice-to-have) — kolejne wersje

1.5. Scenariusze użytkownika

Kilka kluczowych scenariuszy krok po kroku — jakie działania, jakie dane, jakie wyniki. Tylko najważniejsze dane, bez szczegółów.

1.6. Procesy biznesowe

Procesy realizowane w całości przez moduł oraz procesy, w których moduł uczestniczy częściowo (z innymi elementami programu).

1.7. Ograniczenia modułu i wymagania licencyjne

Ograniczenia funkcjonalne, techniczne, integracyjne, prawne. Wymagane licencje programu Soneta i ewentualne licencje zewnętrzne.

1.8. Założenia i zależności

• Założenia — co zakładamy jako pewne (np. dostępność modułów, wersja platformy)
• Zależności — od czego projekt zależy (inne projekty, dane od klienta, zespół)

1.9. Ryzyka projektu

Ryzyka techniczne, biznesowe, integracyjne — z prawdopodobieństwem, wpływem i planem mitygacji.

1.10. Kryteria akceptacji

Mierzalne kryteria gotowości: funkcjonalne (scenariusze), wydajnościowe (wolumeny, czasy), jakościowe (testy, błędy).

1.11. Harmonogram i kamienie milowe

Ramowy harmonogram: fazy projektu, kamienie milowe (zatwierdzenie specyfikacji, MVP, testy, pilotaż, produkcja), zależności czasowe. Charakter orientacyjny.

---

ETAP 2: Architektura modułu

Cel: określić jak moduł będzie zbudowany — role, dane, interfejs, integracje. Dokument dla zespołu projektowego.

Pytania do zadania użytkownikowi

Pierwsza tura — role i konfiguracja:

• Jakie role użytkowników będą korzystać z modułu? Jakie zadania realizują?
• Jakie elementy powinny być konfigurowalne przez klienta?

Druga tura — dane i interfejs:

• Jakie są główne obiekty danych? (dokumenty, kartoteki, słowniki)
• Jak powinna wyglądać struktura menu?

Trzecia tura — integracje i przyszłość:

• Jakie dane z istniejących modułów Soneta będą wykorzystywane? (w tym momencie przeczytaj odpowiednie moduły z tables.md)
• Czy moduł integruje się z systemami zewnętrznymi?
• Czy klient ma dane do migracji?

Sekcje dokumentu Etapu 2

2.1. Role użytkowników

Lista operatorów, ich zadania, procesy w których uczestniczą.

2.2. Zakres konfiguracji modułu

Elementy konfigurowalne: definicje dokumentów, słowniki, ustawienia. Zarówno konfiguracja wstępna jak i definicje używane przy przetwarzaniu danych operacyjnych.

2.3. Kluczowe struktury danych

Najważniejsze struktury danych — dokumenty, kartoteki. Bez szczegółowej zawartości (to Etap 3). Ogólny diagram relacji między głównymi obiektami.

Na podstawie tables.md sprawdź:

• czy potrzebne struktury już istnieją w programie,
• jakie tabele nadrzędne mogą być wykorzystane,
• jakie wzorce projektowe stosują istniejące moduły (podział konfiguracyjne/operacyjne, definicje dokumentów, obiekty Guided i szczegółowe, datapacki).

2.4. Struktura menu i elementy interfejsu

Foldery, hierarchia list w menu głównym, grupowanie funkcjonalne. Wyróżnienie elementów kluczowych dla sukcesu produktu.

2.5. Relacje z modułami programu Soneta

Na podstawie tables.md:

• wskaż konkretne moduły, z którymi nowy moduł współpracuje,
• wymień tabele i obiekty, do których się odwołuje (relacje lookup/inner),
• określ, czy wymagane są rozszerzenia istniejących tabel.

2.6. Relacje z innymi systemami

Integracje z systemami zewnętrznymi, wymiana danych, procesy integracyjne. Zasilanie systemu BI.

2.7. Migracja danych

Dane do importu, źródła (inne ERP, Excel, bazy), zachowanie historii.

2.8. Wydajność i skalowalność

• Wolumeny danych — przewidywana liczba rekordów, częstotliwość operacji
• Optymalizacja — indeksy, widoki, cache
• Przetwarzanie wsadowe vs online — co w czasie rzeczywistym, co w tle
• Skalowalność — wzrost użytkowników i danych, wąskie gardła

2.9. Kierunki rozwoju

Przyszłe funkcjonalności, które nie wchodzą w zakres bieżącej wersji.

---

ETAP 3: Specyfikacja szczegółowa

Cel: dostarczyć szczegółowy opis każdego elementu modułu na poziomie implementacyjnym. Dokument dla zespołu implementacyjnego i AI.

Pytania do zadania użytkownikowi

Na tym etapie pytania dotyczą szczegółów poszczególnych obiektów. Pracuj obiekt po obiekcie:

• Jakie pola powinien mieć ten dokument/kartoteka?
• Jakie stany przechodzi? (bufor, zatwierdzony, anulowany...)
• Jakie czynności są dostępne? (zatwierdzanie, kopiowanie, generowanie...)
• Jakie wydruki i raporty?
• Kto ma dostęp do czego?

Sekcje dokumentu Etapu 3

3.1. Dane operacyjne

Dla każdego obiektu danych:

• pola danych z typami,
• cechy szczególne (historyczność, numeracja dokumentów, stany),
• listy szczegółowe (relacje inner),
• relacje do innych danych modułu i do danych spoza modułu,
• część konfiguracyjna (typy, definicje, słowniki).

Na podstawie tables.md:

• odwołuj się do istniejących tabel po nazwach (kolumna „Tabela") i obiektach (kolumna „Obiekt"),
• wykorzystuj hierarchię nadrzędności jako wzorzec relacji inner,
• rozróżniaj tabele konfiguracyjne i operacyjne — ten sam podział stosuj w nowym module,
• identyfikuj istniejące słowniki i kartoteki zamiast tworzyć duplikaty.

3.2. Diagram relacji

Graficzne przedstawienie relacji (w formie tekstowej Mermaid lub tabeli):

• 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 (z nazwą modułu źródłowego)

3.3. Relacje do danych programu

Dla każdej relacji do danych spoza modułu wskaż na podstawie tables.md:

• nazwę modułu programu Soneta,
• konkretną tabelę i obiekt biznesowy,
• typ relacji (lookup, inner, powiązanie logiczne),
• cel użycia danych w kontekście projektowanego modułu.

3.4. Podstawowe listy modułu

Dla każdej listy:

• kolumny podstawowe i opcjonalne,
• pola filtrujące (podstawowe i dodatkowe po rozwinięciu),
• filtry predefiniowane.

3.5. Formularze

Dla każdego formularza:

• zakładki i grupy na zakładkach,
• pola w każdej grupie,
• listy szczegółów (sublists).

3.6. Workery i czynności

• Czynności na formularzach — warunki dostępności, efekt, wymagane uprawnienia
• Czynności na listach — operacje grupowe
• Workery — procesy w tle, wyzwalacze (ręczne/harmonogramowe/zdarzeniowe)

3.7. Raporty i wydruki

• Wydruki dokumentów — format, szablon, dane
• Raporty zbiorcze — parametry, układ, grupowania
• Eksport danych — formaty (Excel, CSV)

3.8. Procesy Workflow

• Stany obiektów — lista stanów i przejść
• Przejścia — warunki, reguły, odwracalność
• Automatyzacje — akcje przy zmianie stanu
• Ścieżki akceptacji — reguły eskalacji

3.9. Uprawnienia i role

• Matryca uprawnień — tabela ról vs funkcjonalności
• Uprawnienia do danych — ograniczenia widoczności
• Uprawnienia konfiguracyjne — kto modyfikuje ustawienia

3.10. Integracje szczegółowe

• API i protokoły (REST, SOAP, CSV/XML)
• Formaty danych i mapowanie pól
• Częstotliwość synchronizacji
• Obsługa błędów

3.11. Scenariusze testowe

• Testy funkcjonalne (kroki, dane, oczekiwany rezultat)
• Testy integracyjne
• Testy wydajnościowe
• Przypadki brzegowe

3.12. Dane demonstracyjne

• Dane do bazy Demo
• Dane do testów

3.13. Słownik terminów

Definicje kluczowych terminów biznesowych i technicznych, szczególnie przy modułach domenowych.

---

Otwarte kwestie

Na każdym etapie mogą pojawić się nierozstrzygnięte pytania. Prowadź tabelę otwartych kwestii:

Nr	Etap	Kwestia	Status	Decyzja
1		[Opis problemu]	Otwarta/Zamknięta	[Decyzja]

Prezentuj ją użytkownikowi na końcu każdego etapu i przed przejściem do kolejnego.

---

Dokument TODO

Po zakończeniu wszystkich etapów wygeneruj dokument TODO z kolejnymi krokami:

Uzupełnienie planu

• 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
• Zamknięcie otwartych kwestii

Implementacja

• Model danych — tabele, pola, relacje
• Plik business.xml (→ skill soneta-business-xml)
• Struktura menu, listy, widoki
• Formularze i zakładki (→ skill soneta-form-xml)
• Konfiguracja — słowniki, definicje, ustawienia
• Workery i czynności
• Raporty i wydruki
• Procesy Workflow
• Wskaźniki i wykresy BI
• Uprawnienia i role
• Integracje z innymi systemami
• Baza Demo i dane demonstracyjne
• Testy integracyjne i interfejsowe
• Dokumentacja użytkownika i techniczna

Powiązanie z innymi skillami

Po zatwierdzeniu planu projektu:

1. soneta-business-xml — generowanie pliku business.xml na podstawie modelu danych z Etapu 3
2. soneta-form-xml — generowanie formularzy i widoków UI na podstawie sekcji 3.4 i 3.5
3. soneta-programming — implementacja logiki biznesowej, workerów