OpenSpec: Odrzucone propozycje — konwencja pamięci decyzji

Brak stanu odrzucenia. Oto obejście.

Page content

Agent, który sześć miesięcy temu zaproponował i wdrożył „przeniesienie trwałego przechowywania do wspólnej biblioteki”, z przyjemnością zaproponuje to samo następnego kwartału, chyba że coś trwałego powie mu, iż ten pomysł został już przeanalizowany i odrzucony – a OpenSpec obecnie nie ma wbudowanego mechanizmu do śledzenia takiego stanu.

Polecenie /opsx:archive jest zaprojektowane z myślą o jednym wynikiem: zmianie, która została wdrożona. Synchronizuje ono specyfikacje różnicowe do katalogu openspec/specs/ i przenosi folder do openspec/changes/archive/YYYY-MM-DD-<nazwa>/ jako rejestr tego, co się zmieniło i dlaczego. Nie istnieje odpowiednik w postaci /opsx:reject ani /opsx:abandon, a nic w formacie archiwum nie informuje przyszłych propozycji, że „dokładnie ten pomysł został przeanalizowany i odrzucony”. Ta luka ma największe znaczenie właśnie w kodzie, w którym OpenSpec jest inaczej dobrym rozwiązaniem: w systemach brązowych (brownfield) z niewielką liczbą współtwórców i agentami, które okresowo ponownie badają te same pytania architektoniczne – połączenie tych dwóch usług, współdzielenie tej warstwy trwałego przechowywania, zastąpienie tego interfejsu HTTP bezpośrednim importem.

Warstwowe archiwum decyzji dostarczające kontekst z powrotem do nowej propozycji

To nie jest hipotetyczna luka. Została ona bezpośrednio zgłoszona samym opiekunom OpenSpec jako próśba o funkcjonalność, a przebieg tej dyskusji jest warty poznania, zanim zaczniesz improwizować własne rozwiązanie: to, do czego doszedł projekt kształtuje konwencję, która jest warta wdrożenia. Ten przewodnik omawia, co się stanie, jeśli polegamy wyłącznie na /opsx:archive, rzeczywistą dyskusję, która już odbyła się w trackeru problemów OpenSpec, oraz lekki wzorzec pliku decision.md, który możesz przyjąć dzisiaj, czekając – albo nie potrzebując – wsparcia w kodzie źródłowym.

Dlaczego samo archiwizowanie nie rejestruje odrzuconej decyzji

Archiwizowanie zmiany, z której zdecydowałeś się zrezygnować, technicznie działa – folder w każdej sytuacji trafia poza listę aktywnych. Problemem jest to, co ten zarchiwizowany folder nie jest w stanie zakomunikować, gdy leży obok dziesiątek wdrożonych zmian:

  • Brak pola statusu. Zarchiwizowana zmiana wygląda identycznie niezależnie od tego, czy została wdrożona, czy porzucona po trzeciej wiadomości w trakcie /opsx:propose. Kolega z zespołu lub agent skanujący katalog openspec/changes/archive/ nie może odróżnić tych stanów, o ile nie otworzy każdego folderu propozycji i nie przeczyta artefaktów w nim zawartych.
  • Brak sygnału, aby najpierw sprawdzić archiwum. Nic w domyślnym workflow nie instrukcjonuje agenta, aby przeszukał archiwum przed sporządzeniem nowej propozycji. /opsx:propose tworzy szkic na podstawie bieżącego żądania i stanu bazy kodu, kropka – nie porównuje go z wcześniejszymi odrzuconymi zmianami, chyba że mu to nakazujesz.
  • Specyfikacje różnicowe, których nie chcesz synchronizować. Jeśli odrzucona zmiana ma już szkicowe specyfikacje różnicowe i zarchiwizujesz ją w zwykły sposób, /opsx:archive zaproponuje najpierw zsynchronizowanie tych różnic do openspec/specs/. Akceptacja tej oferty spowoduje, że kanoniczne specyfikacje zaczną opisywać zachowanie, którego zdecydowałeś się nie budować, co cichutko zniekształca zapis tego, „co system aktualnie robi”, z którego korzysta każda inna propozycja przed planowaniem czegokolwiek.

Żadne z tych problemów to błąd. /opsx:archive robi dokładnie to, co wynika z jego dokumentacji: kończy zmianę, która została wdrożona. Przypadek odrzucenia leży poza tym udokumentowanym zakresem celowo, a sam przewodnik workflow zespołu OpenSpec jest jednoznaczny w tym, że większość rekomendacji – konwencje gałęzi, kolejność przeglądu PR, kiedy archiwizować – to konwencja nakładona na narzędzie, a nie coś, czego OpenSpec wymusza. Obsługa odrzucenia to kolejna konwencja, którą sam definiujesz, a CLI już daje ci flagę potrzebną do zrobienia tego czysto: przekazując --skip-specs przy archiwizowaniu zmiany, której nie wdrażasz, polecenie openspec archive investigate-shared-persistence --skip-specs spakuje folder w archiwum, nie dotykając katalogu openspec/specs/.

Do czego rzeczywiście doszli opiekunowie OpenSpecu w kwestii wsparcia dla ADR

Zanim wymyślisz domową konwencję, warto przeczytać, jak to konkretne pytanie rozstrzygnęło się publicznie, ponieważ rozwiązanie jest bardziej specyficzne – i bardziej interesujące – niż samo „nie”. Problem GitHuba #557 otwarto w styczniu 2026 roku z prośbą o pierwszorzędną obsługę Architekturalnych Rekordów Decyzji (ADR): trwałych zapisów, które przetrwają niezależnie od cyklu życia pojedynczej zmiany, tak aby odrzucona lub zastąpiona decyzja pozostała widoczna dla wszystkich przyszłych propozycji. Jeden z współtwórców nawet otworzył pull request z wdrożeniem tej funkcjonalności.

W ciągu kolejnych siedmiu miesięcy toczyła się naprawdę merytoryczna wymiana zdań z udziałem głównego opiekuna Tabisha Bidiwale (@TabishB) i kilku bardzo zaangażowanych członków społeczności, obejmująca kwestie nienaruszalnych versus modyfikowalnych rekordów, czy ADR należy do fazy badania czy projektowania, właściciela zmian w przypadkach, gdy jedna decyzja kaskadowo wpływa na dziesiątki późniejszych zmian, oraz jak ADR-y relacjonują się do specyfikacji jako „autorytatywny” opis systemu. Wczesne ujęcie tematu przez Tabisha Bidiwale nadało kierunek, na którym ostatecznie oparto wątek: OpenSpec powinien pozostać lekki w domyślnych ustawieniach i umożliwiać konfigurację wyspecjalizowanych workflow, takich jak ADR, poprzez system schematów, zamiast wbudowywania ich w rdzeń. Później członek społeczności podsumował, na czym wykrystalizowała się dyskusja:

Workflow oparte na ADR-ach są wartościowe, ale OpenSpec nie posiada obecnie pierwszorzędnego/native wsparcia dla ADR… kierunek omawiany tutaj polega na utrzymaniu domyślnego workflow lekkiego i umożliwieniu konfigurowania wyspecjalizowanych workflow.

Opiekun Clay Good (@clay-good) zamknął problem na tej podstawie w sierpniu 2026 roku i przeniósł go do Dyskusji GitHub #1553, aby rozmowa mogła dalej ewoluować, nie pozostając otwartym, nierozwiązanym bugiem. To rozsądna decyzja dla narzędzia, którego całą filozofią jest unikanie ceremonii w stylu Spec Kit w domyślnych ustawieniach. Oznacza to również, że rozwiązanie leży jedną warstwę wyżej, w jednym z dwóch miejsc:

  1. Schemat społecznościowy. Schemat spec-driven-with-adr, stworzony przez technicznego doradcę OpenSpec, Hari Krishnana (@harikrishnan83) i opisany na intent-driven.dev, dodaje piąty artefakt do domyślnego cztero-artefaktowego pipeline’u OpenSpec. Istnieje on, ponieważ domyślny schemat traci rozumowanie z design.md w chwili archiwizacji zmiany – tylko specyfikacje różnicowe są synchronizowane do przodu, więc „dlaczego” stojące za decyzją znika wraz ze zmianą, o ile coś innego tego nie zachowa.
  2. Konwencja na poziomie repozytorium. Mały, ręcznie tworzony plik decision.md oraz reguła nazewnictwa, którego wdrożenie nic nie kosztuje i które nie wymaga instalowania niestandardowego schematu.

Reszta tego przewodnika szczegółowo omawia opcję drugą, ponieważ jest to punkt startowy o niższym progu wejścia dla większości zespołów – a, jak pokazuje sekcja o schemacie społecznościowym poniżej, jest ona kompatybilna z późniejszym przejściem na te cięższe narzędzia, jeśli log odrzuceń wystarczająco urośnie, by to uzasadnić.

Konwencja decision.md do rejestrowania odrzuconej zmiany

Zbuduj odrzucone badanie w ten sam sposób, co wdrożone, ale zatrzymaj się przed synchronizowaniem jakichkolwiek różnic i dodaj jeden plik, który jasno stwierdza wynik:

openspec/
  changes/
    archive/
      2026-09-16-rejected-shared-persistence-layer/
        proposal.md
        decision.md

Plik decision.md odpowiada na te same cztery pytania, co prawidłowy Rekord Decyzji Architektonicznej – co zostało zdecydowane, dlaczego, jakie istniały alternatywy i co zmieniłoby odpowiedź:

# Decyzja

Status: Odrzucona

## Decyzja

Nie zastępować granicy HTTP między usługami bezpośrednim
importem pakietu między dwiema usługami Go.

## Powody

- Zwiększa sprzężenie na poziomie kompilacji między niezależnie wdrażanymi usługami.
- Sprawia, że warstwa trwałego przechowywania staje się implicitową, nieudokumentowaną umową.
- Pomiarowe korzyści (latencja, duplikacja kodu) były mniejsze niż
  koszt sprzężenia w tej bazie kodu.

## Rozważane alternatywy

- Współdzielony wewnętrzny moduł Go – odrzucony z powodu tego samego sprzężenia.
- gRPC zamiast HTTP – odłożone, nie odrzucone; do rozważenia ponownie, jeśli narzut
  HTTP stanie się zmierzoną wąskim gardłem.

## Rozważ ponownie tylko jeśli

- Dwie usługi zostaną celowo połączone w jeden wdrażalny, lub
- Pomiary latencji pokażą, że skok HTTP jest udowodnionym wąskim gardłem.

## Powiązane

- Zasada architektoniczna: usługi komunikują się przez HTTP, a nie współdzielone pakiety.

Jedna twarda zasada, która sprawia, że ta cała konwencja działa: nie wykonuj kroku synchronizacji dla odrzuconej zmiany. Jeśli /opsx:propose już naszkicował specyfikacje różnicowe, zanim zdecydowałeś się przeciwko zmianie, użyj flagi, którą CLI już daje ci do tej sytuacji:

openspec archive investigate-shared-persistence --skip-specs

Flaga --skip-specs mówi openspec archive, aby spakowało zmianę w archiwum bez dotykania katalogu openspec/specs/, co jest najbezpieczniejszą domyślną opcją dla wszystkiego, co archiwizujesz bez wdrażania. Przyjęcie zwykłego promptu synchronizacji zamiast tego spowodowałoby scalenie specyfikacji różnicowych odrzuconego pomysłu z twoimi kanonicznymi specyfikacjami, a kanoniczne openspec/specs/ powinny opisywać to, co system aktualnie robi, a nie każdy pomysł, który został naszkicowany i odrzucony. Jeśli zmiana trwale nie generuje żadnych zmian specyfikacji z powodów strukturalnych – powiedzmy, czysty folder badawczy – OpenSpec obsługuje również deklarację skip_specs: true w pliku .openspec.yaml tej zmiany, dzięki czemu archiwizuje się czysto bez flagi za każdym razem.

Nazwanie odrzuconych zmian tak, aby ludzie i agenci mogli skanować archiwum

Plik decision.md pomaga tylko jeśli ktoś otworzy folder. Przedłuż nazwę folderu o wynik, aby zarówno człowiek przeglądarki ls openspec/changes/archive/, jak i agent listujący zmiany mogli poznać status bez otwierania żadnego pliku:

2026-09-16-rejected-shared-persistence-layer/
2026-09-20-abandoned-react-router-migration/
2026-10-01-superseded-old-auth-design/
2026-10-10-add-project-filtering/          # wdrożone, brak prefiksu

Odzwierciedla to słownictwo statusów już rekomendowane dla samodzielných rekordów decyzji – zaproponowana, zaakceptowana, zastąpiona, opuszczona – stosowane do archiwum OpenSpec, zamiast osobnego folderu docs/decisions/. Utrzymuj słownictwo małe. Trzy lub cztery konsekwentne prefiksy biją wolny tekst statusu, który każda propozycja zapisuje nieco inaczej.

Jak skłonić agenta do sprawdzenia archiwum przed ponownym proponowaniem

Nazewnictwo i plik decision.md rozwiązują problem wykrywalności dla człowieka przeglądającego foldery. Same w sobie nie robią nic, aby agent przeszukał archiwum przed tworzeniem nowej propozycji – to musi być jawna instrukcja, ponieważ /opsx:propose domyślnie tego nie robi, i żadna ilość uporządkowanego nazewnictwa plików tego nie zmieni sama w sobie.

Dwa miejsca, w których umieścić tę instrukcję, zgodnie z tym, jak OpenSpec już oczekuje, że wskazówki specyficzne dla projektu zostaną wstrzyknięte:

W pliku openspec/config.yaml, pod polem context:, które jest wstrzykiwane do każdego żądania planowania (uwaga na limit 50KB opisany w Szybkim starcie OpenSpec):

context: |
  Przed zaproponowaniem zmiany przeszukaj katalog openspec/changes/archive pod kątem folderów
  z prefiksem "rejected-" lub "abandoned-", opisujących istotnie podobny
  pomysł. Jeśli taki istnieje, podsumuj jego plik decision.md i wskaż, co się
  zmieniło, zanim zaproponujesz pomysł ponownie. Nie przebudowuj odrzuconej
  decyzji bez nowych dowodów.

W pliku AGENTS.md lub własnych instrukcjach agenta projektu, jako trwała zasada, a nie jako blok kontekstu na każde żądanie:

## Odrzucone zmiany OpenSpec

Gdy propozycja zostanie przeanalizowana i odrzucona:

1. Nie synchronizuj i nie aplikuj jej specyfikacji różnicowych.
2. Dodaj plik `decision.md` ze Statusem, Decyzją, Powodami, Rozważanymi
   alternatywami oraz warunkiem „Rozważ ponownie tylko jeśli”.
3. Przedłuż nazwę zarchiwizowanego folderu: `rejected-<nazwa>` lub `abandoned-<nazwa>`.
4. Przed zaproponowaniem istotnie podobnej zmiany przeszukaj
   katalog `openspec/changes/archive/` i odwołaj się do wcześniejszej decyzji.
5. Nie otwieraj odrzuconej decyzji na nowo, chyba że jej udokumentowane
   warunki ponownego rozważenia faktycznie się zmieniły.
flowchart TD A[Nowy pomysł wart zmiany] --> B{Przeszukaj katalog openspec/changes/archive} B -->|Znaleziono podobną odrzuconą decyzję| C[Podsumuj wcześniejszy plik decision.md] C --> D{Warunki ponownego rozważenia się zmieniły?} D -->|Nie| E[Nie proponuj ponownie. Odwołaj się do decyzji.] D -->|Tak| F["/opsx:propose z podanym zmienionym kontekstem"] B -->|Nic podobnego nie znaleziono| F

Żadna z tych instrukcji nie gwarantuje przestrzegania – agent nadal może pominąć krok wyszukiwania, tak samo jak może pominąć czytanie innego kontekstu, który wstrzykujesz. Ale to jest różnica między „informacja istnieje gdzieś w repozytorium” a „agentowi za każdym razem mówi się, aby szukał jej”, i tylko druga opcja faktycznie redukuje powtarzające się badania w praktyce.

Przykład z życia: Odrzucenie propozycji, a następnie poprawne ponowne rozważenie

Połączmy elementy na konkretnym przypadku. Załóżmy, że kolega z zespołu prosi agenta o przejrzenie zastąpienia wywołania HTTP między usługami bezpośrednim importem pakietu Go, aby skrócić opóźnienia sieciowe.

  1. Eksploracja, a potem propozycja. /opsx:explore czyta obie usługi, a /opsx:propose replace-http-with-direct-import szkicuje propozycję, dokument projektu wagami zysków z latencji względem kosztu sprzężenia oraz szkic specyfikacji różnicowej.
  2. Analiza i odrzucenie. Po przeglądnięciu dokumentu projektu zespół decyduje, że koszt sprzężenia – dwie niezależnie wdrażane usługi dzielące teraz zależność na poziomie kompilacji – przewyższa zysk z latencji, którego nikt nie zmierzył jako problemu. Nic nie zostaje zbudowane.
  3. Archiwizacja bez synchronizacji. Zamiast kasować folder, uruchom openspec archive replace-http-with-direct-import --skip-specs, a następnie dodaj plik decision.md do zarchiwizowanego folderu z Status: Rejected, powyższymi powodami oraz klauzulą Reconsider only if nazywającą warunki, które zmieniłyby odpowiedź – na przykład, „pomiary latencji pokażą, że skok HTTP jest udowodnionym wąskim gardłem”. Zmień nazwę folderu z prefiksem rejected-, tak aby czytał się jako openspec/changes/archive/2026-09-16-rejected-replace-http-with-direct-import/.
  4. Kilka miesięcy później ktoś podnosi to ponownie. Inny współtwórca lub ten sam agent w nowej sesji zostaje poproszony o „przyspieszenie wywołania z koszyka na inwentaryzację” i zaczyna szkicować propozycję, która wygląda dużo na ten sam pomysł. Ponieważ openspec/config.yaml instruuję agenta, aby najpierw przeszukał archiwum, znajduje on odrzucony folder, czyta decision.md i raportuje: „Istotnie podobna zmiana została zaproponowana i odrzucona 2026-09-16 z powodów sprzężenia. Warunkiem ponownego rozważenia było ‘pomiary latencji pokażą, że skok HTTP jest udowodnionym wąskim gardłem.’ Czy masz nowe pomiary, czy to inny problem?”
  5. Zespół dostarcza nowe dowody. Jeśli profilowanie teraz pokaże, że skok HTTP faktycznie dominuje nad latencją koszyka, to jest dokładnie zmieniona okoliczność, o którą prosił oryginalny decision.md. Agent postępuje z /opsx:propose, a plik decision.md nowej propozycji – gdy ta również zostanie zarchiwizowana, zaakceptowana lub odrzucona – odwoła się do wcześniejszego w sekcji Related, dzięki czemu archiwum będzie czytać się jako ciągła historia decyzji, a nie jako dwa niespowiązane foldery, które przypadkiem opisują ten sam pomysł.

Piąty krok jest całym sensem tej konwencji. Bez niego krok 4 albo w ogóle się nie wydarzy – agent po prostu przeanalizuje od zera – albo wydarzy się z przypadku, ponieważ ktoś zapamiętał wcześniejszą rozmowę. Plik decision.md i instrukcja przeszukania archiwum zamieniają „ktoś może pamiętać” w coś, co workflow faktycznie sprawdza.

Archiwum OpenSpec vs. Dedykowany Dziennik ADR: Kto za co odpowiada

Gdy już utrzymujesz pliki decision.md w archiwum, warto być jednoznacznym, który artefakt odpowiada na które pytanie, aby konwencja nie cichutko nie zamieniła się w duplikowaną dokumentację:

Artefakt Odpowiada na
openspec/specs/ Co system aktualnie robi?
openspec/changes/<nazwa>/ (aktywne) Co proponujemy zmienić teraz?
openspec/changes/archive/<nazwa>/ Co zmieniło się (lub zostało odrzucone) w przeszłości i dlaczego?
docs/adr/ (samodzielne, niezależne od narzędzia) Jaką trwałą zasadę architektoniczną się wyuczono, niezależnie od pojedynczej zmiany?

Dla decyzji dostatecznie wąskiej, aby należeć do jednego badania – „przeanalizowaliśmy współdzielenie tej warstwy trwałego przechowywania i powiedzieliśmy nie” – konwencja decision.md w archiwium powyżej wystarcza. Dla decyzji, która powinna przetrwać i ograniczać wiele przyszłych zmian – „usługi komunikują się przez HTTP, nigdy przez współdzielone pakiety” – promocja do samodzielnego Rekordu Decyzji Architektonicznej w docs/adr/, a odrzucona zmiana odwołuje się do niego w Related w swoim decision.md. Podział ten utrzymuje archiwum OpenSpec skoncentrowane na indywidualnych badaniach, podczas gdy dziennik ADR trzyma małą liczbę zasad, które powinny przetrwać cykl życia dowolnego pojedynczego narzędzia – w tym przyszłą migrację całkowicie poza OpenSpec.

Kiedy przyjąć schemat spec-driven-with-adr zamiast tego

Ręcznie tworzona konwencja powyżej nic nie kosztuje i mieści się w piętnastu minutach setupu, co czyni ją właściwą wartością domyślną. Warto jednak zrozumieć, co faktycznie robi bardziej zstrukturyzowana alternatywa, zanim uznasz, że wyrosłeś z prefiksu nazewnictwa.

Schemat spec-driven-with-adr wstawia piąty artefakt, adr, między design a tasks w pipeline’u OpenSpec. Zamiast pisać treści ADR bezpośrednio do folderu zmiany, krok adr produkuje krótką, lokalną dla zmiany listę kontrolną adr.md i, gdy zmiana wprowadza naprawdę trwałe zobowiązanie architektoniczne, numerowany rekord w korzeniu repozytorium – /adr/0042-use-postgres-for-catalog.md, sąsiadujący z openspec/, a nie w nim zagnieżdżony. Każdy ADR tworzony przez schemat jest nienaruszalny po zaakceptowaniu: własne instrukcje schematu nazywają to „żelazną zasadą” – nigdy nie edytujesz statusu, treści ani daty zaakceptowanego rekordu. Aby zmienić wcześniejszą decyzję, piszesz nowy ADR, którego pole Supersedes: nazywa ten stary, a przyszłe projekty przechodzą łańcuch zastępowania, aby wiedzieć, które decyzje są nadal w mocy. To jest bardziej rygorystyczna wersja dokładnie tego pomysłu „rozważ ponownie tylko jeśli” z konwencji decision.md powyżej, egzekwowana przez schemat, a nie pozostawiona pamięci człowieka.

Warto być precyzyjnym co do tego, co ten schemat rozwiązuje, a co nie. Został zbudowany dla decyzji, które są zaakceptowane i muszą przetrwać archiwizację – Postgres zamiast DynamoDB, JWT zamiast ciasteczek sesyjnych – a nie dla propozycji, które zostały przeanalizowane i odrzucone bez wdrożenia czegokolwiek. Odrzucone badanie nadal nie ma oczywistego miejsca pod tym schematem; nałożylibyś tę samą konwencję decision.md i nazewnictwa z tego przewodnika, odnosząc się tylko do rekordów /adr/ zamiast samodzielnego folderu docs/adr/.

Sięgnij po niego, gdy zauważysz któreś z tych:

  • Liczba odrzuconych decyzji jest wystarczająco duża, że przeszukiwanie openspec/changes/archive/ pod kątem prefiksów przestaje być szybkie.
  • Chcesz, aby trwałe decyzje architektoniczne były weryfikowane i odwoływane do każdego nowego projektu automatycznie, a nie przez konwencję i grep.
  • Wielu współtwórców wciąż wymyśla nieco różne formy decision.md, a chcesz, aby schemat wymuszał jeden nienaruszalny, numerowany format.

Instalowanie niestandardowego schematu to większe zobowiązanie niż konwencja nazewnictwa – zmienia to, co /opsx:propose generuje dla każdej przyszłej zmiany, nie tylko odrzuconych – więc traktuj to jako krok wyżej, gdy lekka wersja wyraźnie się nadwyręża, a nie jako domyślny pierwszy ruch.

Wniosek

Archiwum OpenSpec zostało zaprojektowane wokół jednego wyniku – zmiany, która została wdrożona – a jego opiekunowie byli jednoznacznymi, po siedmiomiesięcznej publicznej dyskusji, że pierwszorzędna obsługa odrzuceń lub ADR nie pojawi się w workflow rdzeniowym wkrótce. To pozostawia naprawę tam, gdzie OpenSpec już umieścił większość swoich konwencji zespołowych: w Twoim repozytorium, a nie w narzędziu. Plik decision.md, flaga --skip-specs przy archiwizacji, prefiks nazwy rejected-/abandoned- i jawna instrukcja mówiąca agentowi, aby przeszukał archiwum przed proponowaniem, wystarczą, aby zatrzymać większość powtarzających się badań. Sięgnij po schemat spec-driven-with-adr dopiero wtedy, gdy ta lekka konwencja faktycznie nadwyręży się pod liczbą śledzonych decyzji – i nawet wtedy, utrzymuj jasną różnicę: zarządza on decyzjami, które zaakceptowałeś i chcesz, by przetrwały archiwizację, a nie tymi, które odrzuciłeś.

Przydatne linki

Subskrybuj

Otrzymuj nowe wpisy o systemach, infrastrukturze i inżynierii AI.