Co istnieje, a czego nie wolno dopowiadać
Moduł portal wymaga customer_accounts. Bieżące strony obejmują wejście, logowanie, rejestrację, weryfikację, reset hasła, dashboard i profil. Nawigacja oraz widgety mogą być rozszerzane przez moduły.
Nazwy uprawnień związane z katalogiem, ofertami, zamówieniami i fakturami oraz promocyjne karty na stronie wejściowej nie są dowodem kompletnego procesu. W pierwszej kolejności sprawdza się stronę, API, reguły dostępu, integrację i test ścieżki od początku do końca.
Konto klienta wymaga jawnego modelu
Uwierzytelnienie pracownika i klienta to osobne systemy. Tenant, organizacja, firma w CRM, osoba kontaktowa, konto użytkownika, rola i funkcja także oznaczają różne granice. Powiązanie trzeba zaprojektować, a odmowę dostępu sprawdzić dla złej organizacji i innej firmy.
Własna domena jest osobnym strumieniem operacyjnym
Bieżący kod obejmuje rejestrację domeny, kontrolę DNS i TLS, rozpoznawanie routingu oraz zadania ponawiające. Projekt nadal potrzebuje właściciela domeny i DNS, zasad certyfikatów, środowisk, tajemnic routingu, linków email, monitoringu, obsługi incydentów, wycofania i likwidacji.
Jedna ścieżka jest jednostką zakresu
Dla jednej persony i jednego rezultatu zapisz system źródłowy, identyfikatory, odczyt i zapis, aktualność, idempotencję, ponowienia, uzgadnianie, awarie, retencję, wyjątki, dowody oraz właścicieli. Dopiero taki kontrakt można estymować i odbierać.
Pozycjonowanie dostawcy nie jest dowodem wdrożenia
Publiczne materiały używają określeń self service, zamówienia, faktury i w pełni oznakowany portal. Na tej stronie są one wyłącznie kontekstem oczekiwań rynku. Stan możliwości wynika z bieżącego kodu, tras, API, testów oraz dowodów konkretnej aplikacji.
Granica dowodów
Wydanie, bieżący kod i data przeglądu
- Najnowszy zweryfikowany tag
- v0.6.5
- Rewizja bieżącego kodu
01911d00e28f44cf484d0b1d04860dcfef5370bf- Data przeglądu
Customer Accounts i Portal weszły do historii publicznych wydań w v0.4.8. Własne domeny portalu ogłoszono w v0.6.1. Poniższy inwentarz sprawdzono w późniejszym bieżącym kodzie o podanej rewizji, bez przypisywania go wstecz do tych wydań.
Inwentarz fundamentu portalu
Stan opisuje zakres dowodu, a nie obietnicę rezultatu. Każdy wiersz wymaga ponownego sprawdzenia dla konkretnej aplikacji i włączonych modułów.
Otwórz: Inwentarz fundamentu portalu18 poz.
| Mechanizm | Stan | Dokładny dowód | Wydanie lub bieżący kod | Bezpieczny wniosek | Granica | Warunek wstępny | Odpowiedzialny właściciel | Data przeglądu |
|---|---|---|---|---|---|---|---|---|
| Strona wejściowa | dostępny fundament | portal/frontend/[orgSlug]/portal/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Publiczne wejście do portalu z logowaniem i rejestracją | Karty promocyjne nie dowodzą obsługi zamówień ani faktur | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Logowanie klienta | dostępny fundament | portal/login/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Osobne wejście uwierzytelnienia klienta | Polityka produkcyjna, dostarczanie email, limity i odzyskiwanie nadal wymagają dowodów wdrożenia | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Rejestracja | konfigurowalne | portal/signup/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieje pierwszostronna ścieżka rejestracji | Rejestracja przez zaproszenie albo otwarta pozostaje polityką projektu | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Weryfikacja email | dostępny fundament | portal/verify/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją ścieżka weryfikacji i przepływ tokenu | Dostarczenie, wygaśnięcie, nadużycia i wsparcie trzeba odebrać lokalnie | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Reset hasła | dostępny fundament | portal/reset-password/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Ścieżka resetu istnieje w bieżącym kodzie | Skonfigurowana ścieżka email i odzyskiwania nadal wymaga testu od początku do końca | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Dashboard | dostępny fundament | portal/dashboard/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Szkielet dashboardu przyjmuje dołączane widgety | Może być pusty i nie dowodzi istnienia żadnego widgetu biznesowego | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Profil | dostępny fundament | portal/profile/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Widoczne są profil, role i wynikowe funkcje | Profil nie jest kompletną administracją konta firmy | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Nawigacja | konfigurowalne | customer_accounts/api/portal/nav.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Manifesty ścieżek i przyznane funkcje kształtują nawigację | Widoczna pozycja nie jest autoryzacją serwerową ani ukończoną ścieżką | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Powiadomienia | dostępny fundament | customer_accounts/api/portal/notifications.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją API powiadomień klientów | Zakres powiadomień biznesowych i niezawodność dostarczania są dowodami projektu | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Zaproszenia | dostępny fundament | customer_accounts/api/post/invitations/accept.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją mechanizmy zaproszenia i akceptacji | Kto zaprasza, jaka rola jest przypisana i jak działa odzyskiwanie pozostaje decyzją polityki | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Role i funkcje klienta | konfigurowalne | customer_accounts/setup.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją role startowe i sprawdzanie funkcji uwzględniające symbole wieloznaczne | Nazwy funkcji są słownikiem dostępu, a nie dowodem strony lub procesu | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Zarządzanie sesjami | dostępny fundament | customer_accounts/api/portal/sessions.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Użytkownicy mogą sprawdzać aktywne sesje, a bieżący kod wspiera ich unieważnianie | Polityka cookie, czas trwania, wsparcie i reakcja na incydenty pozostają odpowiedzialnością wdrożenia | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel tożsamości i bezpieczeństwa | 2026-07-14 |
| Administracja użytkownikami firmy | konfigurowalne | customer_accounts/api/portal/users.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją API listy użytkowników tej samej firmy i administracji rolami | Powiązanie z firmą musi być poprawne i niezależnie przetestowane | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Punkty rozszerzeń | praca własna | portal/frontend/[orgSlug]/portal/dashboard/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Moduły mogą dołączać widgety i treść strony | Każda dołączona ścieżka wymaga implementacji, autoryzacji i odbioru | Projekt, implementacja, autoryzacja i odbiór | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Powiązania z CRM | konfigurowalne | customer_accounts/AGENTS.md | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Konta klientów mogą łączyć się z osobami i firmami w CRM | Reguły dopasowania i własności wymagają przeglądu projektu i uzgadniania | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Ścieżki związane z organizacją | dostępny fundament | apps/mercato/src/app/(frontend)/[...slug]/page.tsx | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Chronione ścieżki porównują organizację sesji z organizacją w adresie URL | Zakres organizacji różni się od zakresu firmy w CRM | Włączone moduły, skonfigurowana aplikacja i odbiór projektu | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Kontrolowane udostępnianie | konfigurowalne | customer_accounts setup and feature checks | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Role, funkcje i aktywacja konta mogą ograniczać dostęp | Bezpieczny pilotaż nadal wymaga właścicieli środowiska, monitoringu, wsparcia i wycofania | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel produktu portalu i realizacji | 2026-07-14 |
| Własne domeny | konfigurowalne | customer_accounts/api/admin/domain-mappings.ts | Bieżący kod w sprawdzonej rewizji; historia wydań jest opisana osobno | Istnieją rejestracja, kontrole DNS i TLS, routing, zadania i harmonogramy | Własność domeny, DNS, certyfikaty, linki email, monitoring, wycofanie i likwidacja pozostają pracą operacyjną | Zatwierdzona polityka, konfiguracja, egzekwowanie serwerowe i testy | Właściciel domeny i operacji | 2026-07-14 |
Matryca ścieżek B2B
Otwórz: Matryca ścieżek B2B18 poz.
| Ścieżka biznesowa | Stan po przeglądzie | Co trzeba ustalić lub udowodnić |
|---|---|---|
| Dostęp do konta | dostępny fundament | Wybierz zaproszenie lub rejestrację, weryfikację, odzyskiwanie i politykę sesji |
| Profil | dostępny fundament | Zdefiniuj dozwolone zmiany, dowody i wsparcie |
| Zarządzanie użytkownikami firmy | konfigurowalne | Wymagaj powiązania z firmą, delegowanych ról i negatywnych testów zakresu |
| Widoczność katalogu | brak dowodu | Startowa nazwa uprawnienia nie dowodzi pierwszostronnej strony katalogu |
| Asortyment właściwy dla klienta | praca własna | Zdefiniuj źródło uprawnień, własność ceny i produktu oraz zachowanie przy odmowie |
| Cenniki | praca własna | Zdefiniuj źródło prawdy, daty obowiązywania, walutę i uzgadnianie |
| Zapytania ofertowe | praca własna | Słownik uprawnień nie jest odebraną ścieżką ofertową |
| Koszyk | brak dowodu | W sprawdzonym drzewie portalu nie znaleziono kompletnej pierwszostronnej ścieżki koszyka |
| Tworzenie zamówienia | praca własna | Wymaga kontraktów produktu, ceny, walidacji, akceptacji, idempotencji i realizacji |
| Historia i status zamówień | wymagana integracja | Wymaga systemu źródłowego, mapowania identyfikatorów, aktualności i obsługi awarii |
| Dostęp do faktur | wymagana integracja | Wymaga własności dokumentu, autoryzacji, retencji i obsługi błędów |
| Dokumenty | praca własna | Zdefiniuj przechowywanie, klasyfikację, widoczność, retencję i zachowanie przy braku dokumentu |
| Zwroty | praca własna | Zdefiniuj kwalifikację, akceptację, magazyn, płatność i ścieżki wyjątków |
| Śledzenie dostawy | wymagana integracja | Wymagane są potwierdzenie systemu przewoźnika lub zamówień oraz uzgadnianie |
| Zgłoszenia do wsparcia | praca własna | Zdefiniuj własność zgłoszenia, routing, politykę obsługi, eskalację i dowody |
| Powiadomienia | konfigurowalne | Fundament istnieje, lecz każdy wyzwalacz, kanał, preferencja i ścieżka błędu są zakresem projektu |
| Płatności | wymagana integracja | Wymaga dowodów bramki, checkoutu, idempotencji, webhooka, uzgadniania i zwrotu |
| Akceptacje i ścieżki partnerów | praca własna | Zdefiniuj role, rozdział obowiązków, zmiany stanów i odpowiedzialnych właścicieli |
Granice tożsamości i uprawnień
Otwórz: Granice tożsamości i uprawnień8 poz.
| Granica | Znaczenie | Kontrola menedżerska |
|---|---|---|
| Uwierzytelnienie pracownika | Tożsamość operatora wewnętrznego | Nie używaj jej jako dowodu tożsamości klienta |
| Uwierzytelnienie klienta | Osobne konto klienta, dane logowania, sesje, role i funkcje | Musi być związane z właściwym tenantem i organizacją |
| Tenant | Najwyższa partycja danych w sprawdzonym modelu aplikacji | Sama nie definiuje handlowego konta klienta |
| Organizacja | Zakres operacyjny używany przez ścieżki i kontekst autoryzacji | Nie jest automatycznie firmą ani kontem w CRM |
| Firma lub konto w CRM | Rekord biznesowej relacji z klientem | Musi być świadomie powiązany i uzgadniany z kontami klientów |
| Osoba w CRM | Rekord kontaktu biznesowego | Nie jest tym samym obiektem co konto logowania |
| Konto użytkownika klienta | Tożsamość logowania do portalu, którą można powiązać z osobą i firmą | Cykl życia i odzyskiwanie wymagają właściciela |
| Rola i funkcja | Słownik dostępu używany przez kontrole serwerowe i nawigację | Widoczność w interfejsie nigdy nie zastępuje egzekwowania po stronie serwera |
Ścieżka decyzji o koncie i obsłudze
Nazwij jeden mierzalny rezultat klienta i jedną personę. Zatrzymaj się, jeśli portal nadal jest jedną niepodzielną estymacją.
Wybierz zaproszenia albo otwartą rejestrację. Zapisz, kto zatwierdza aktywację i jaki dowód weryfikacji pozostaje.
Wybierz hasło, magic link albo oba sposoby. Ustal reset, unieważnienie sesji, konto nieaktywne i odzyskiwanie dostępu.
Zdefiniuj relacje tenant, organizacja, firma klienta, osoba i konto użytkownika. Przetestuj odmowę dla złej organizacji i innej firmy.
Przypisz rolę domyślną, delegowanego administratora portalu, dozwolone funkcje i punkt egzekwowania po stronie serwera.
Wybierz adres organizacji albo własną domenę. Przypisz właścicieli domeny, DNS, TLS, linków email, monitoringu, incydentów, wycofania i likwidacji.
Przed przyjęciem użytkowników zdefiniuj dezaktywację, odebranie roli, unieważnienie sesji, reset hasła, odzyskiwanie konta i zachowane dowody.
Dla wybranego obiektu i działania wskaż system źródłowy, identyfikatory, kierunek odczytu i zapisu, aktualność oraz retencję.
Sklasyfikuj ścieżkę jako fundament, konfigurację, pracę własną, integrację albo brak dowodu. Nie promuj jej na podstawie tekstu interfejsu.
Ustal ponowienia, idempotencję, uzgadnianie, awarię, nieaktualne dane, duplikat wysłania i brak dokumentu.
Przypisz właścicieli biznesu, realizacji, bezpieczeństwa, prywatności, integracji, wsparcia, domeny i wyjścia.
Odbierz jedną cienką ścieżkę od początku do końca w kontrolowanym środowisku przed rozszerzeniem portalu.
Etapy realizacji i odbioru
Otwórz: Etapy realizacji i odbioru7 poz.
| Etap | Dowód wejściowy | Właściciel | Warunek zaliczenia | Warunek zatrzymania | Ograniczenie skutków | Zachowany dowód |
|---|---|---|---|---|---|---|
| Weryfikacja fundamentu | Inwentarz tożsamości i ścieżek | Właściciel realizacji | Sprawdzono dokładne dowody ścieżek i API | Brak modelu konta lub środowiska | Ogranicz zakres i pozostaw dostęp zamknięty | Inwentarz i dziennik decyzji |
| Cienka ścieżka | Jedna persona i rezultat | Właściciel biznesowy | Ścieżka podstawowa i odmowa przechodzą testy | Nieznany system źródłowy lub uprawnienie | Wyłącz ścieżkę | Ślad testu i próbka uzgodnienia |
| Kontrolowany pilotaż | Nazwana grupa pilotażowa i wsparcie | Właściciel operacji | Wyjątki są obsługiwane zgodnie z polityką | Wyciek zakresu, nierozwiązany incydent lub brak wsparcia | Cofnij dostęp pilotażowy | Dziennik pilotażu i notatki o incydentach |
| Uzgodnienie biznesowe | Rekordy źródłowe i portalowe | Właściciel danych | Liczby, stany i wyjątki są uzgodnione | Niewyjaśniona różnica | Wstrzymaj zapis i zbadaj problem | Podpisany raport uzgodnienia |
| Próba operacyjna | Monitoring, domena, email, kopia i odtwarzanie | Właściciel usługi | Działają alerty, odtwarzanie i ścieżki wsparcia | Brak właściciela lub nieudane odtwarzanie | Wróć do środowiska testowego | Dowód próby |
| Decyzja o starcie | Wszystkie blokery i ryzyka rezydualne | Uprawniony sponsor | Każdy bloker zamknięto albo jawnie odrzucono | Otwarte kryterium krytyczne | Bez uruchomienia | Datowany zapis zgody |
| Stopniowe rozszerzanie | Jedna dodatkowa ścieżka naraz | Właściciel produktu | Nowa ścieżka przechodzi te same bramki | Poprzednia ścieżka jest niestabilna albo bez właściciela | Nie rozszerzaj | Zaktualizowany inwentarz i pakiet odbioru |
Otwórz: Arkusz zakresu portalu
Narzędzie lokalne
Arkusz zakresu portalu
Używaj wyłącznie abstrakcyjnych nazw ról i odwołań do dowodów. Nie wpisuj danych logowania, danych osobowych, nazw klientów lub firm, tajemnic handlowych, identyfikatorów rekordów, adresów URL z tokenem, adresów infrastruktury ani konfiguracji produkcyjnej. Dane pozostają w tej przeglądarce i nie są wysyłane przez tę stronę.
Prywatność: ta strona nie wysyła, nie zapisuje w adresie URL ani nie dodaje do plików cookie treści arkusza.
Przykłady hipotetyczne
Otwórz: Przykłady syntetyczne2 poz.
Przykład syntetyczny
Hipotetyczny status zamówienia dystrybutora
- Persona lub nazwa roli
- Rola kupującego A
- Granica konta klienta
- Jedno fikcyjne konto dystrybutora
- Mierzalny rezultat
- Sprawdzenie przyjętego stanu zamówienia bez telefonu do wsparcia
- Wejście i sposób uwierzytelnienia
- Tylko zaproszenie i zweryfikowany email
- Obiekt i działanie
- Odczyt statusu zamówienia
- Dane wyświetlane lub zmieniane
- Wyłącznie syntetyczny stan zamówienia
- System źródłowy
- System zamówień A
Przykład syntetyczny
Hipotetyczne zgłoszenie o dokument
- Persona lub nazwa roli
- Rola klienta usługi B
- Granica konta klienta
- Jedno fikcyjne konto usługowe
- Mierzalny rezultat
- Zgłoszenie braku dokumentu i śledzenie odpowiedzialności
- Wejście i sposób uwierzytelnienia
- Hasło oraz polityka odzyskiwania
- Obiekt i działanie
- Utworzenie zgłoszenia do wsparcia
- Dane wyświetlane lub zmieniane
- Abstrakcyjna kategoria dokumentu i wiadomość
- System źródłowy
- System zgłoszeń B
Dowody odbioru projektu
Otwórz: Dowody odbioru projektu15 poz.
- ścieżka podstawowa
- odmowa działania
- dostęp między firmami
- zła organizacja
- wygasła lub unieważniona sesja
- niezweryfikowane lub nieaktywne konto
- awaria integracji
- podwójne wysłanie
- nieaktualne dane
- brak dokumentu
- niedostępny widget
- widok mobilny 360 px
- obsługa wyłącznie klawiaturą
- ograniczenie ruchu
- wyłączony JavaScript
Niedopasowanie i warunki zatrzymania
- Wymagany jest gotowy sklep bez prac produktowych.
- Nie zdefiniowano modelu konta klienta, firmy, osoby, użytkownika, tenantu lub organizacji.
- Brakuje właściciela systemu źródłowego, danych osobowych, integracji, uzgadniania, wsparcia, domeny, testów lub wycofania.
- Uprawnienia istnieją tylko jako etykiety interfejsu albo ukrywanie nawigacji.
- Brakuje systemu zewnętrznego, obsługi wyjątków, środowiska testowego albo planu ograniczenia skutków.
Wybrane źródła do weryfikacji
Linki są dowodami kontekstowymi. Nie zastępują przeglądu konkretnej aplikacji.
Metoda, założenia i ograniczenia
Stan na 14 lipca 2026 r. Fakty produktowe sprawdzono zarówno w publicznym kodzie wskazanej wersji repozytorium, jak i w oficjalnej dokumentacji. Gdy dokumentacja i kod się różnią, opisujemy zachowanie potwierdzone w kodzie. Interpretacje i zalecenia dotyczą pracy wdrożeniowej, a nie gwarancji produktu.
Ten materiał nie jest ofertą, audytem, certyfikacją ani poradą prawną, podatkową lub księgową. Na wynik wpływają edycja, wybrane moduły, konfiguracja, własny kod, infrastruktura, dane, dostawcy zewnętrzni i sposób operowania systemem.
Główne zbiory źródeł: repozytorium kodu, dokumentacja, publiczne wydania.