Najpierw rozdziel stan wdrożony, opublikowany i rozwijany
Stan sprawdzono 14 lipca 2026 r. Repozytorium robocze było na rewizji 01911d00e28f44cf484d0b1d04860dcfef5370bf. Najnowszy publiczny tag Git i wydanie GitHub to v0.6.5, a kanał npm latest dla @open-mercato/core wskazywał 0.6.5. W kodzie develop znajdowały się już wpisy 0.6.6 i kanały prerelease; nie są one automatycznie docelową wersją wdrożenia.
Decyzja musi zapisać obecny lockfile i manifesty, dokładny tag i commit celu oraz dowód, że Core, Enterprise, moduły oficjalne i dostawców są ze sobą zgodne. Etykieta latest, gałąź develop i działająca kopia aplikacji to trzy różne fakty.
Pięć warstw dowodu odpowiada na różne pytania
Manifesty i lockfile mówią, co rzeczywiście wdrożono. Tag, commit i pakiety opisują cel. Changelog lub opis wydania mówi, co dostarczono użytkownikom. UPGRADE_NOTES opisuje znane działania dla każdego przekraczanego okna. BACKWARD_COMPATIBILITY określa zasady zmian publicznych kontraktów. Dopiero testy, runbooki i odbiór konkretnej aplikacji dowodzą wyniku wdrożenia.
Kontrakt kompatybilności nie oznacza zerowej pracy
Konwencje auto-discovery i identyfikatory są zamrożone, publiczne typy, funkcje, ścieżki importu i trasy są stabilne, a schemat bazy ma rozwijać się addytywnie. Zmiana łamiąca wymaga deprecjacji, mostu zgodności przez co najmniej jedną wersję minor, instrukcji migracji i specyfikacji. Są to reguły dla wkładu do platformy, a nie gwarancja dla bibliotek zewnętrznych, własnego kodu, konfiguracji, danych, integracji lub operacji.
Przykłady pokazują, dlaczego liczy się dokładne okno
Okno 0.5.0 → 0.6.0 obejmowało MikroORM v6 → v7: przeniesienie dekoratorów, zmianę persist/flush, przejście z Knex do Kysely, zmiany migratora, bootstrapu, typów i konfiguracji testów dla używającego ich kodu. Natomiast dla 0.6.0 → 0.6.1 i 0.6.1 → 0.6.2 notatki podają brak wymaganych działań zależnościowych w kodzie downstream. To nie zwalnia z regresji aplikacji i nie prognozuje kolejnego okna.
Automatyzacja edytuje wzorce; nie zatwierdza działania
Pomocnik 0.4.10 → 0.5.0 wykrywa i modyfikuje wybrane wzorce, wykonuje typecheck i raportuje elementy do ręcznego przeglądu. Osobny workflow prowadzi migrację MikroORM v6 → v7. Ich zakres jest wersyjny i mechaniczny. Żaden nie dowodzi migracji danych, zachowania integracji, uprawnień, wydajności, odtwarzania ani odbioru biznesowego.
Kod przejęty i rollback rozszerzają odpowiedzialność
Override i udokumentowane punkty rozszerzeń zmniejszają potrzebę modyfikowania Core, ale nadal wymagają testów kontraktów. Moduł własny lub dostawcy ma własny cykl zgodności. Eject kopiuje moduł do aplikacji i przełącza jego źródło na @app: od tej chwili jest to kod organizacji wymagający porównywania, scalania, testów i przeglądu bezpieczeństwa; poprawki upstream nie wpływają automatycznie.
Plan wycofania musi osobno objąć pakiety i aplikację, schemat i migracje, odwracalność transformacji danych, konfigurację i sekrety, cache i artefakty generowane, skutki w systemach zewnętrznych oraz zmiany dostawców. Down migration albo snapshot jednego komponentu nie odtwarza całej usługi.
Utrzymanie zaczyna się po wdrożeniu
Po zmianie zweryfikuj migracje i health check, obserwuj błędy, kolejki i integracje, uzgodnij krytyczne rekordy, zachowaj dowody, zamknij wyjątki czasowe, zaktualizuj baseline aplikacji i zaplanuj następny przegląd. Głębsza ocena infrastruktury i gotowości należy do dedykowanych przewodników.
Hierarchia dowodów aktualizacji
| Warstwa | Co może udowodnić | Czego nie dowodzi | Dokładne źródło |
|---|---|---|---|
| Manifesty i lockfile wdrożenia | Jakie wersje pakietów i drzewo zależności są rzeczywiście wdrożone. | Działania runtime, jakości danych ani zgodności z celem. | Dowód projektu |
| Publiczny tag, commit i pakiety docelowe | Niezmienną tożsamość celu i dostępność zgodnych pakietów. | Przetestowania aplikacji na tej wersji. | Dowód projektu |
| Changelog i opis wydania | Zmiany dla użytkownika przypisane do opublikowanego wydania. | Każdej wymaganej zmiany downstream ani regresji aplikacji. | Sprawdź źródło |
| UPGRADE_NOTES dla każdego okna | Znane działania dla aplikacji, modułów i rozszerzeń downstream. | Nieznanego zachowania własnego kodu ani sukcesu migracji. | Sprawdź źródło |
| Kontrakt kompatybilności | Jak autorzy platformy mają zachować lub zdeprecjonować publiczne kontrakty. | Gwarancji dla zależności, kodu własnego, danych, konfiguracji, integracji lub operacji. | Sprawdź źródło |
| Testy, runbooki i odbiór aplikacji | Co wydarzyło się w konkretnej aplikacji na środowisku staging i produkcyjnopodobnym. | Przyszłych wydań ani nieprzetestowanych procesów. | Dowód projektu |
Kategorie kompatybilności i ich granice
| Kategoria | Reguła repozytorium | Granica aplikacji |
|---|---|---|
| Zamrożone | Konwencje auto-discovery, identyfikatory zdarzeń i rozszerzeń, ACL oraz inne opublikowane adresy nie mogą być bezpośrednio zmienione ani usunięte. | Reguła dla zmian platformy, nie gwarancja zerowej pracy aplikacji. |
| Stabilne | Publiczne typy, funkcje, trasy, ścieżki importu, CLI, DI i kontrakty generowane muszą zachować dotychczasowych odbiorców. | Reguła dla zmian platformy, nie gwarancja zerowej pracy aplikacji. |
| Tylko addytywne | Schemat bazy może otrzymywać bezpieczne kolumny, tabele i indeksy, ale nie może zawężać, zmieniać nazw ani usuwać istniejących kontraktów. | Reguła dla zmian platformy, nie gwarancja zerowej pracy aplikacji. |
| Deprecjacja i most zgodności | Zmiana łamiąca wymaga deprecjacji, instrukcji migracji, mostu przez co najmniej jedną wersję minor i specyfikacji uwzględniającej migrację. | Reguła dla zmian platformy, nie gwarancja zerowej pracy aplikacji. |
Matryca ekspozycji modyfikacji
| Rodzaj ekspozycji | Właściciel oceny | Oczekiwany dowód | Dlaczego wpływ jest inny |
|---|---|---|---|
| Udokumentowany override aplikacji | Właściciel aplikacji | Inwentarz stabilnych ID, ostrzeżenia stale key, testy kontraktowe i regresja zachowania zamiennika. | Wspierany mechanizm nadal może zależeć od semantyki lub kontekstu. |
| Udokumentowany punkt UMES lub rozszerzeń | Właściciel rozszerzenia | Inwentarz kontraktów zdarzeń, widgetów, enricherów, guardów, komend, encji lub AI oraz test przypadku braku. | Stabilne adresy ograniczają sprzężenie z Core, ale payload i założenia biznesowe nadal wymagają oceny. |
| Własny moduł aplikacji | Zespół aplikacji | Importy pakietów, encje, migracje, ACL, artefakty generowane oraz testy jednostkowe i integracyjne. | Organizacja odpowiada za zgodność własnego kodu i danych. |
| Pakiet dostawcy lub moduł oficjalny | Dostawca modułu i właściciel aplikacji | Dokładne wyrównanie pakietów, release notes, źródło lub umowa, testy staging i granica wsparcia. | Oddzielny pakiet może mieć własny cykl wydań i kompatybilności. |
| Moduł przejęty do @app | Właściciel aplikacji | Diff do upstream, plan scalenia, przegląd bezpieczeństwa, migracje i pełna regresja modułu. | To niezależny kod aplikacji; poprawki upstream nie wpływają automatycznie. |
| Bezpośrednia poprawka Core lub utrzymywany fork | Opiekun forka | Inwentarz patchy, diff upstream, konflikty scalenia, kontrakty, bezpieczeństwo i pełna regresja. | Tworzy największy koszt scalenia i utrzymania. |
| Integracja zewnętrzna lub kontrakt danych | Właściciele integracji i systemu biznesowego | Wersja dostawcy, schematy, auth, retry, idempotencja, uzgodnienie, awarie i rollback. | Stabilne API Open Mercato nie zamraża systemu zewnętrznego ani skutków ubocznych. |
| Konfiguracja środowiska, sekretów, workerów, wyszukiwania i cache | Właściciel operacyjny | Wersjonowana konfiguracja, kolejność migracji, plan opróżnienia kolejek, health i odtwarzanie. | Zgodność kodu nie dowodzi zgodności operacyjnej. |
Przykłady ograniczone do konkretnych okien
| Okno | Udokumentowana informacja downstream | Granica |
|---|---|---|
| 0.5.0 → 0.6.0 | MikroORM v6 → v7 wymagał oceny i zmian downstream tam, gdzie używano dekoratorów, persist/flush, Knex lub raw SQL, API migratora, własnego bootstrapu, ścisłych typów albo konfiguracji Jest. | Znacząca udokumentowana praca w tym oknie; rzeczywisty wpływ zależy od użycia w aplikacji. |
| 0.6.0 → 0.6.1 | Nie udokumentowano wymaganych działań aktualizacji zależności w kodzie downstream. | Nadal wymaga regresji bazowej, przypięcia celu, oceny aplikacji i odbioru. |
| 0.6.1 → 0.6.2 | Nie udokumentowano wymaganych działań aktualizacji zależności w kodzie downstream. | To stwierdzenie nie dotyczy kolejnych okien ani nie dowodzi zachowania biznesowego. |
Dziesięć bramek od baseline do zamknięcia
| Bramka | Właściciel oceny | Wymagany rezultat lub dowód | Warunek stop |
|---|---|---|---|
| 1. Baseline i zamrożenie | Właściciel aplikacji | Inwentarz wdrożenia i zamrożenie zmian | Nieodtwarzalny lub zmienny baseline |
| 2. Wybór i przypięcie celu | Właściciel techniczny | Dokładny publiczny tag, commit, pakiety i decyzja o kanale | Nieopublikowany, zmienny lub niewyrównany cel |
| 3. Zebranie dowodów | Lider aktualizacji | Przeczytane wszystkie okna i rejestr źródeł | Nieprzeczytane albo niejednoznaczne okno |
| 4. Klasyfikacja wpływu | Właściciele kodu, danych, integracji i operacji | Kompletny rejestr ekspozycji i wpływu | Dotknięty artefakt bez właściciela lub działania |
| 5. Kopie i przygotowanie wycofania | Właściciele danych i operacji | Próba odtworzenia i drzewo decyzji rollback | Brak lub nieprzetestowana ścieżka odtwarzania |
| 6. Migracja i build na staging | Właściciele inżynierii i danych | Powtarzalny build, migracje i artefakty generowane | Błąd buildu, migracji albo uzgodnienia danych |
| 7. Regresja techniczna i biznesowa | QA, bezpieczeństwo i właściciele procesów | Dowody procesów krytycznych, integracji, bezpieczeństwa, wydajności i odbioru | Niezaliczony test krytyczny lub nierozstrzygnięty odbiór |
| 8. Zgoda na zmianę produkcyjną | Uprawniony właściciel zmiany | Datowany zapis go, pauza lub odrzucenie i okno serwisowe | Dowolny bloker albo niepełna akceptacja ryzyka |
| 9. Wdrożenie i obserwacja | Właściciele wydania i operacji | Uporządkowana zmiana, health, monitoring i obserwacja rollback | Osiągnięty próg stop albo nieznany stan usługi |
| 10. Zamknięcie po zmianie | Właściciel usługi | Uzgodnienie, pakiet dowodów, nowy baseline, wyjątki i kolejny przegląd | Krytyczna rozbieżność albo wyjątek bez terminu |
Rollback to zestaw decyzji dla różnych stanów
| Warstwa stanu | Wymagane pytanie o wycofanie |
|---|---|
| Pakiety i kod aplikacji | Przypnij poprzedni znany artefakt i sprawdź kolejność wdrożenia; rollback kodu nie cofa późniejszych skutków w danych. |
| Schemat bazy i migracje | Sklasyfikuj kroki forward-only i odwracalne; down migration wymaga testu z realnymi zależnościami. |
| Przekształcone dane | Zachowaj dowód sprzed zmiany i określ odwrócenie lub kompensację; kopia nie czyni każdej transformacji logicznie odwracalną. |
| Konfiguracja, środowisko i sekrety | Wersjonuj wartości i stan rotacji bez eksportowania sekretów; skoordynuj zgodność kodu i konfiguracji. |
| Artefakty generowane, wyszukiwanie i cache | Określ regenerację, invalidację, obsługę kolejek i zachowanie zdegradowane. |
| Integracje i skutki zewnętrzne | Uwzględnij webhooki, płatności, wiadomości, eksporty i zdalne zapisy, których lokalny rollback nie usuwa. |
| Zmiany dostawcy i platformy | Zapisz zmiany dostawcy, umów, flag i zależności wyjścia poza repozytorium. |
Narzędzie lokalne
Rejestr wpływu aktualizacji
Wszystkie 21 obszarów zaczyna jako nierozstrzygnięte. „Brak udokumentowanego działania” jest tylko klasyfikacją; nie weryfikuje wiersza i nie usuwa regresji bazowej.
Prywatność: Wpisy pozostają w tej przeglądarce i lokalnych eksportach. Nie wpisuj sekretów, danych osobowych, rekordów produkcyjnych ani danych dostępowych.
Stan decyzji
NIEGOTOWEOtwarte bramki zgody: 262
Inwentarz wersji — nieznane fakty o aplikacji pozostaw puste
Zapisz dokładny stan wdrożony i cel. Żadna fikcyjna wersja obecna ani docelowa nie jest wypełniona.
| Obszar | Dotknięty artefakt | Stan obecny | Zmiana docelowa | Źródło / okno wersji | Klasyfikacja | Właściciel odpowiedzialny | Wymagane działanie | Dowód walidacji | Działanie rollback | Warunek stop | Status | Data przeglądu | Uprawniona rola ryzyka | Uzasadnienie ryzyka | Data akceptacji | Wygaśnięcie / trigger przeglądu |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Wyrównanie pakietów Core, Enterprise, oficjalnych i dostawców | ||||||||||||||||
| Zmiany zależności bezpośrednich i runtime | ||||||||||||||||
| Publiczne kontrakty i mosty deprecjacji | ||||||||||||||||
| Własne moduły i nadpisania aplikacji | ||||||||||||||||
| Moduły przejęte, poprawki i forki | ||||||||||||||||
| Migracje bazy i kolejność schematu | ||||||||||||||||
| Transformacje i uzgodnienie danych | ||||||||||||||||
| Generowane rejestry, klienty, artefakty i snapshoty | ||||||||||||||||
| Środowisko, konfiguracja, flagi i sekrety | ||||||||||||||||
| Workery, kolejki, scheduler i zdarzenia | ||||||||||||||||
| Indeksy wyszukiwania, wektory i cache | ||||||||||||||||
| Integracje, webhooki, pliki i zdalne skutki | ||||||||||||||||
| Uwierzytelnianie, autoryzacja, ACL, szyfrowanie i prywatność | ||||||||||||||||
| Krytyczne ścieżki użytkownika i dostępność | ||||||||||||||||
| Wydajność, pojemność i timeouty | ||||||||||||||||
| Kopie, odtwarzanie i odzyskanie danych po transformacji | ||||||||||||||||
| Logi, metryki, alerty i budżety błędów | ||||||||||||||||
| Kolejność wdrożenia i okno serwisowe | ||||||||||||||||
| Wykonalność rollbacku w każdej warstwie stanu | ||||||||||||||||
| Odbiór biznesowy i uzgodnienie krytycznych rekordów | ||||||||||||||||
| Runbooki, przekazanie wsparcia, baseline i kolejny przegląd |
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.