Najpierw wynik, użytkownik i luka dowodowa
Zapisz wynik biznesowy, użytkowników, obecny proces i mierzalne kryterium odbioru. Następnie znajdź dokładny dowód możliwości produktu. Dopiero potwierdzona luka uzasadnia wybór mechanizmu; brak dowodu oznacza dalsze discovery, nie zgodę na budowę.
Prawidłowym wynikiem może być brak zmiany: użycie istniejącej funkcji, konfiguracja albo świadoma adaptacja procesu. Mechanizmy można łączyć, lecz każda dodatkowa warstwa powiększa własność kodu, testów, bezpieczeństwa, aktualizacji i wycofania.
Pola i encje zmieniają dane, nie dostarczają całego zachowania domeny
Pola niestandardowe i encje runtime pomagają opisać dodatkowe dane. Gdy potrzebne są zachowania, walidacje wielorekordowe, akcje, integracje, przetwarzanie w tle lub własny cykl życia, potrzebny może być typowany moduł albo inny punkt rozszerzenia.
W sprawdzonym query layer pola niestandardowe i ich wartości są filtrowane po tenant_id, ale discovery pól i joiny wartości nie dodają automatycznie filtra organization_id. Encje wirtualne mogą stosować zakres organizacji. Projekt musi zatem udowodnić oczekiwany zakres danych zamiast zakładać go na podstawie etykiety „custom”.
Kod aplikacji i moduł lokalny mają różny zasięg, ale wspólną odpowiedzialność
Gdy zmiana dotyczy własnej strony lub sekcji aplikacji, składaj ją w warstwie aplikacji. Gdy potrzebuje danych, ACL, setupu, usług, zadań, API i własnego cyklu życia, moduł lokalny @app jest pełnym utrzymywanym kodem projektu, a nie konfiguracją.
Zmiana między modułami powinna używać dokładnego mechanizmu rozszerzeń: publiczny inwentarz obejmuje między innymi zdarzenia, widgety, enrichery, interceptory, extension entities, kontrakty API i sloty portalu. Sama nazwa rodziny nie dowodzi dopasowania do konkretnej powierzchni.
Override zastępuje stabilny identyfikator, nie dowolny fragment Core
Nadpisanie na poziomie aplikacji działa dla jawnie obsługiwanych typów i stabilnych identyfikatorów. Może zastąpić definicję albo wyłączyć obsługiwany kontrakt wartością null. Udokumentowana kolejność rozwiązywania prowadzi od override programowego przez modules.ts i obsługiwane pliki do rejestracji bazowej; nieaktualny klucz wywołuje ostrzeżenie. Zamiennik musi zachować kontrakt i mieć test wyboru oraz kolizji. To precyzyjny mechanizm, a nie ogólny patch.
Eject i fork to ostatnie poziomy własności
Eject działa tylko dla kwalifikujących się modułów oznaczonych jako ejectable. Kopiuje taki moduł do aplikacji i przełącza jego źródło na @app. Upstream nie aktualizuje tej kopii automatycznie; właściciel musi śledzić poprawki, porównywać zmiany, scalać, testować i utrzymywać bezpieczeństwo. Rozważaj eject dopiero, gdy udokumentowane mechanizmy nie wystarczają i istnieje plan wyłączenia lub powrotu.
Utrzymywany fork lub patch Core to czerwona strefa trwałej rozbieżności. Wymaga jawnego sponsora produktu i technicznego, budżetu, upstream-watch, przeglądu każdego wydania, testów bezpieczeństwa i regresji oraz kryterium zakończenia. Bez tego decyzja powinna być odrzucona.
Decyzja obejmuje pełny cykl życia
Dla każdego kodowego wyboru zapisz źródło, właścicieli produktu i technicznych, zakres danych i tenantów, model uprawnień, testy kontraktu i akceptacji, obserwowalność, trigger przeglądu aktualizacyjnego, sposób wyłączenia, migrację danych oraz rollback. Rejestr poniżej nie zatwierdza architektury; blokuje status gotowy, dopóki wymagane pola nie są kompletne.
Mapa mechanizmów dostosowania
| Mechanizm | Odpowiedni problem | Warunki wstępne | Dokładny dowód | Własność kodu i danych | Bezpieczeństwo i zakres | Wymagane testy | Przegląd aktualizacji | Wyłączenie lub rollback | Warunek odrzucenia | Źródło |
|---|---|---|---|---|---|---|---|---|---|---|
| Istniejąca możliwość lub adaptacja procesuno code change | Zweryfikowane zachowanie produktu albo świadoma zmiana procesu już spełnia cel. | Dokładny dowód możliwości i zaakceptowane dopasowanie procesu. | Matryca możliwości oraz wskazany moduł lub dokumentacja. | Brak nowego właściciela kodu; właściciel procesu odpowiada za adopcję. | Sprawdź role, granice danych i kontrole procesu. | Test odbiorczy rzeczywistego wyniku użytkownika. | Ponów ocenę po zmianie możliwości, procesu lub polityki. | Cofnij konfigurację albo instrukcję procesu. | Cel nadal ma zweryfikowaną lukę funkcjonalną. | Sprawdź źródło |
| Konfiguracjashipped configuration surface | Dostarczona opcja, workflow, rola, definicja lub polityka wyraża wymagane zachowanie. | Nazwany mechanizm konfiguracji, właściciel i ścieżka promocji środowisk. | Dokładna dokumentacja albo kod konfiguracji. | Właściciel aplikacji lub procesu odpowiada za wartości; platforma za kod bazowy. | Minimalne uprawnienia, bezpieczne wartości, zakres tenant/organizacja i sekrety. | Walidacja konfiguracji oraz testy regresji i promocji. | Sprawdź zmiany wartości domyślnych oraz usunięte lub przemianowane opcje. | Przywróć wersjonowaną wcześniejszą konfigurację. | Zmiana wymaga zachowania, którego konfiguracja nie potrafi wyrazić. | Sprawdź źródło |
| Pole niestandardowe lub encja runtimeruntime data customization | Potrzebne są dodatkowe dane bez nowego kodowanego cyklu domenowego. | Definicja pola lub encji, semantyka, dostęp, walidacja i migracja. | Dokumentacja rozszerzalności danych i pól niestandardowych. | Projekt odpowiada za definicje i governance danych; platforma za silnik ogólny. | Udowodnij zakres tenant i organizacji; joiny pól custom nie dodają automatycznie organization_id. | Testy definicji, walidacji, uprawnień, zapytań, eksportu i migracji. | Sprawdź rodzaje pól, zapytania, identyfikatory i rozwój schematu. | Wyłącz użycie tylko z jawną decyzją o retencji, eksporcie lub usunięciu danych. | Potrzeba obejmuje akcje, reguły między rekordami, pracę w tle albo kodowany cykl. | Sprawdź źródło |
| Bezpośrednia kompozycja aplikacjiapp-owned composition | Własna strona, sekcja, nawigacja lub prezentacja składa publiczne komponenty i usługi. | Powierzchnia należy do aplikacji i nie wymaga mutacji między modułami. | Dokumentacja struktury aplikacji i tworzenia modułu. | Zespół aplikacji odpowiada za kod kompozycji i UX. | Zastosuj dostęp tras, scoped reads, bezpieczny rendering i dostępność. | Testy strony, uprawnień, empty state, interakcji i dostępności. | Sprawdź importowane publiczne kontrakty i zachowanie komponentów. | Usuń trasę lub komponent za udokumentowaną flagą. | Zmiana modyfikuje inny moduł albo wymaga jego hooków cyklu życia. | Sprawdź źródło |
| Moduł lokalny aplikacjiproject-maintained module code | Spójna własna możliwość potrzebuje danych, ACL, setupu, usług, API, zadań, stron lub cyklu życia. | Granica modułu, stabilne ID, właściciele, setup i projekt zależności. | Dokumentacja tworzenia pierwszego modułu. | Zespół aplikacji odpowiada za cały moduł @app i artefakty generowane. | Zadeklaruj funkcje, politykę ról, zakres tenant/org, walidację i granice sekretów. | Odpowiednie testy unit, integration, ACL, migracji, API, tła i odbioru. | Przy każdej aktualizacji sprawdź użyte kontrakty i zależności. | Wyłącz moduł tylko z obsługą danych, zadań, tras i zależności. | Zmiana jest jedynie małym wkładem między modułami do istniejącej powierzchni. | Sprawdź źródło |
| Udokumentowane rozszerzenie między modułamipublic extension contract | Pasuje dokładny widget, event, enricher, interceptor, extension entity, kontrakt API, slot portalu lub inny mechanizm. | Zweryfikowano dokładną powierzchnię, stabilne ID lub zdarzenie, zachowanie bez modułu i kontrakt. | Aktualny inwentarz rozszerzeń i wskazana implementacja. | Właściciel rozszerzenia odpowiada za kod wkładu; moduł hosta za publiczny punkt. | Egzekwuj dostęp i zakres przy każdym odczycie/zapisie; zależności opcjonalne muszą bezpiecznie zawodzić. | Testy kontraktu, kolizji/kolejności, uprawnień, braku modułu, awarii i odbioru. | Sprawdź dokładną powierzchnię, ID, payload, kolejność i deprecjacje. | Wyrejestruj lub wyłącz wkład flagą bez uszkodzenia hosta. | Żaden udokumentowany mechanizm nie pasuje do wymaganego cyklu lub miejsca. | Sprawdź źródło |
| Nadpisanie aplikacji po stabilnym IDsupported replacement contract | Obsługiwany rodzaj override zastępuje jedną rejestrowaną implementację, zachowując kontrakt. | Obsługiwany rodzaj, dokładne stabilne ID, kontrakt zamiennika i polityka kolizji. | Dokumentacja nadpisań aplikacji. | Aplikacja odpowiada za zamiennik; platforma za discovery i kontrakt bazowy. | Zamiennik zachowuje auth, zakres, walidację, redakcję i zachowanie awaryjne. | Testy discovery, wyboru, kolizji, kontraktu, uprawnień i regresji. | Przy każdej aktualizacji sprawdź rodzaj override, stabilne ID i bazowe zachowanie. | Usuń override, aby przywrócić implementację pakietu po sprawdzeniu zgodności danych. | Cel nie ma udokumentowanego rodzaju override lub stabilnego ID. | Sprawdź źródło |
| Integracja zewnętrznasystem boundary | Cel zależy od innego systemu referencyjnego, dostawcy, protokołu lub zdalnego skutku. | Nazwane systemy, kierunek, ID, opóźnienie, uzgadnianie, awaria i wyjście. | Przewodnik integracji oraz dokładny dowód dostawcy/API. | Właściciel integracji odpowiada za adapter i operacje; każdy system za własną domenę. | Udowodnij ochronę danych dostępowych, auth, routing tenantów, minimalizację, replay i dostęp dostawcy. | Testy kontraktu, idempotencji, retry, uzgadniania, awarii, bezpieczeństwa i odbioru. | Sprawdź zdalne API, dostawcę, schemat, dane dostępowe i mechanizmy platformy. | Bezpiecznie wstrzymaj, opróżnij pracę, uzgodnij, cofnij dostęp i zachowaj dane wyjścia. | Zachowanie mieści się całkowicie w granicy jednej aplikacji. | Sprawdź źródło |
| Moduł po ejectlast-resort copied ownership | Moduł pakietu musi zostać szeroko przejęty i zmieniony po odrzuceniu mniejszych mechanizmów. | Zapisane alternatywy, właściciel, upstream watch, budżet merge, plan danych i powrotu/wyłączenia. | Dokumentacja eject modułu. | Organizacja odpowiada za skopiowany moduł @app; poprawki upstream nie wpływają automatycznie. | Ponownie audytuj cały moduł, nie tylko zmienione linie. | Pełne testy regresji, bezpieczeństwa, migracji, integracji, wydajności i odbioru. | Porównuj każde istotne wydanie upstream i świadomie scalaj poprawki. | Przywróć źródło pakietu tylko przez przetestowany plan zgodności i migracji danych. | Konfiguracja, rozszerzenie, override, integracja lub własny moduł może spełnić cel. | Sprawdź źródło |
| Utrzymywany fork lub patch Corered-zone permanent divergence | Świadoma trwała rozbieżność pozostaje po odrzuceniu wszystkich wspieranych ścieżek przez przegląd architektury. | Sponsorzy biznesowi i techniczni, budżet, przegląd licencji, upstream watch, proces wydań i kryterium wyjścia. | Przypięty kod, dowód kompatybilności i licencji; żadna komenda nie czyni tego bezpiecznym. | Organizacja odpowiada za rozbieżny kod platformy i pełny ciężar utrzymania. | Pełny model zagrożeń i cykliczny przegląd bezpieczeństwa zmienionej granicy platformy. | Kompletne testy platformy, zgodności, bezpieczeństwa, migracji, wydajności i aplikacji. | Sprawdź każde wydanie upstream i advisory bezpieczeństwa przed wydaniem downstream. | Finansowany plan konwergencji, wymiany lub wycofania z zachowaniem danych. | Brak sponsora, budżetu cyklu życia, właściciela bezpieczeństwa lub kryterium wyjścia oznacza odrzucenie. | Dowód i zgoda projektu |
Drzewo decyzji fail-closed
- 1
Czy cel biznesowy, użytkownik i kryterium odbioru są jasne?
Jeśli tak: Przejdź do dowodów możliwości.
Jeśli nie: Stop: niewystarczające dowody; ukończ discovery przed wyborem mechanizmu.
- 2
Czy zweryfikowana obecna możliwość już spełnia cel?
Jeśli tak: Użyj obecnej możliwości albo dostosuj proces; zapisz, dlaczego kod nie jest potrzebny.
Jeśli nie: Przejdź do konfiguracji i danych.
- 3
Czy konfiguracja albo pole/encja runtime może zamknąć lukę?
Jeśli tak: Skonfiguruj lub użyj danych custom; udowodnij zakres danych i granice cyklu.
Jeśli nie: Przejdź do własności kodu.
- 4
Czy zmiana mieści się we własnej stronie, sekcji lub spójnej możliwości aplikacji?
Jeśli tak: Złóż w aplikacji albo utwórz moduł lokalny.
Jeśli nie: Przejdź do dokładnej powierzchni między modułami.
- 5
Czy jeden dokładny udokumentowany punkt rozszerzeń pasuje do miejsca i cyklu?
Jeśli tak: Użyj tej powierzchni i przetestuj kontrakt, uprawnienia, kolejność, brak i awarie.
Jeśli nie: Pauza na przegląd architektury; nazwa rodziny nie wystarcza.
- 6
Czy trzeba zastąpić jedną wspieraną implementację o stabilnym ID?
Jeśli tak: Użyj override aplikacji zachowującego udokumentowany kontrakt.
Jeśli nie: Przejdź do analizy granicy systemów.
- 7
Czy wynik zależy od systemu zewnętrznego lub dostawcy?
Jeśli tak: Zaprojektuj integrację z odpowiedzialnością, uzgadnianiem, awarią i wyjściem.
Jeśli nie: Kontynuuj tylko, jeśli potrzeba pozostaje wewnątrz modułu pakietu.
- 8
Czy dowiedziono niewystarczalności konfiguracji, kodu aplikacji, modułów, rozszerzeń, override i integracji?
Jeśli tak: Przegląd architektury może rozważyć eject jako ostatnią opcję.
Jeśli nie: Odrzuć eject i wróć do najmniejszego wspieranego mechanizmu.
- 9
Czy trwała rozbieżność platformy jest jawnie wymagana i finansowana?
Jeśli tak: Eskaluj do czerwonego przeglądu forka/patcha ze sponsorami, bezpieczeństwem, upstream watch i wyjściem.
Jeśli nie: Nie forkuj ani nie patchuj Core.
- 10
Czy źródło, właściciele, zakres, bezpieczeństwo, testy, trigger aktualizacji, wyłączenie, rollback, uzasadnienie, akceptujący i data przeglądu są kompletne?
Jeśli tak: Zapisz decyzję jako gotową do oceny; uprawniony człowiek nadal ją zatwierdza.
Jeśli nie: Pozostaw decyzję niegotową albo odrzuconą.
Pytania cyklu życia dla każdego wyboru kodowego
- Jakie dokładne publiczne źródło i stabilny kontrakt uzasadniają mechanizm?
- Kto odpowiada za wynik produktu, projekt techniczny, implementację, utrzymanie, zależność od dostawcy i ciągłość zespołu?
- Które tenanty, organizacje, osoby, rekordy i środowiska są w zakresie?
- Jak dowiedziono autoryzacji, walidacji, prywatności, szyfrowania, sekretów i audytu?
- Kto odpowiada za definicje danych, migracje, retencję, eksport, usuwanie i uzgodnienie?
- Co dzieje się przy braku zależności, częściowej awarii, retry, duplikacji, timeout i degradacji?
- Jakie testy kontraktu, uprawnień, migracji, integracji, dostępności, wydajności i odbioru są wymagane?
- Jakie logi, metryki, alerty, audyt, dokumentacja techniczna i runbooki wsparcia ujawniają awarię?
- Który kontrakt, zależność, ID, artefakt generowany lub moduł upstream wywołuje przegląd aktualizacji?
- Czy zmianę można wyłączyć bez uszkodzenia danych, zadań, tras, integracji lub użytkowników?
- Jaki rollback kodu, schematu, danych, konfiguracji, skutków zewnętrznych i dostawcy jest możliwy?
- Jaka data przeglądu, wygaśnięcie, konwergencja, wymiana lub kryterium wycofania kończy ten wybór?
Narzędzie lokalne
Rejestr decyzji o dostosowaniu
Wszystkie 13 obszarów startują jako niewystarczające dowody. Uzupełnij pola odpowiedzialności i cyklu życia przed zatwierdzeniem; odrzucona ścieżka wymaga pełnego uzasadnienia i akceptującego.
Prywatność: Wpisy pozostają w tej przeglądarce i lokalnych eksportach. Nie wpisuj sekretów, danych dostępowych, danych osobowych ani rekordów produkcyjnych.
Stan rejestru
NIEGOTOWEOtwarte bramki: 286
| Obszar | Wynik biznesowy | Użytkownicy i proces | Dowód obecnej możliwości | Zweryfikowana luka | Stan decyzji | Kandydat mechanizmu | Dokładne źródło lub kontrakt | Rozważone alternatywy | Zakres danych, tenantów i organizacji | Kontrole bezpieczeństwa i prywatności | Właściciel produktu | Właściciel techniczny | Właściciel implementacji | Właściciel utrzymania | Testy odbiorcze i techniczne | Trigger przeglądu aktualizacji | Wyłączenie i rollback | Zależności | Status | Uzasadnienie decyzji | Rola lub osoba zatwierdzająca | Data przeglądu |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Dodatkowy atrybut danych | ||||||||||||||||||||||
| Dodatkowa encja lub relacja danych | ||||||||||||||||||||||
| Własna strona, sekcja lub nawigacja aplikacji | ||||||||||||||||||||||
| Wkład UI między modułami | ||||||||||||||||||||||
| Walidacja, uprawnienie lub guard mutacji | ||||||||||||||||||||||
| Trasa lub kontrakt API | ||||||||||||||||||||||
| Zdarzenie, subskrybent, kolejka lub zadanie w tle | ||||||||||||||||||||||
| Workflow lub reguła biznesowa | ||||||||||||||||||||||
| Integracja zewnętrzna lub synchronizacja | ||||||||||||||||||||||
| Kontrola bezpieczeństwa, prywatności, tożsamości lub audytu | ||||||||||||||||||||||
| Raportowanie, wyszukiwanie lub indeksowanie | ||||||||||||||||||||||
| Rozbieżność zachowania całego modułu | ||||||||||||||||||||||
| Trwała rozbieżność Core lub platformy |
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.