Zasady Fabryki

• Spis treści
• Teza
• Dlaczego to się zmieniło teraz
• Podział warstw
• Reguły redakcyjne dla dokumentów przekazywanych klientowi
• Kanon tworzenia dokumentów (rozszerzenie 2026-08-24)
  • Odpowiedź na pytanie „dlaczego tak"
  • Ta sama zasada działa w audycie
  • Dlaczego ta zasada jest wykonalna dopiero teraz
• Zastosowanie
• Napięcie, o którym warto pamiętać

Strona nadrzędna: Zasady Fabryki

Źródło: ZasadyRealizacji\slad-rozwoju-metody-jako-know-how.md w drzewie FB. Wiki jest kopią do czytania – zmiany nanosimy w pliku źródłowym, nie tutaj.

Ustalone 2026-08-23 przy przeglądzie modelu wyceny VCN. Zasada dotyczy wszystkich projektów: co zostaje w warstwie FB, a co trafia do klienta.

Teza¶

Rejestr decyzji projektowych jest elementem metodyki, nie dokumentacji klienta. Klient kupuje działający system i wymagania, które ma spełnić – nie zapis tego, jak dochodziliśmy do sposobu ich formułowania.

Daty i numery wersji niosą osobną informację: pokazują, jak rozwijały się poszczególne elementy metody. Ciąg „v01 → v02 → v03" wraz z uzasadnieniami zmian to opis drogi, a nie stanu. Droga jest tym, co odróżnia FB od konkurencji, która ma dostęp do tych samych norm.

Dlaczego to się zmieniło teraz¶

Do niedawna odtworzenie metody z rozproszonych artefaktów wymagało pracy analityka przez wiele dni i i tak dawało wynik przybliżony. Inżynieria wsteczna z udziałem AI zmienia ten rachunek: model dostaje komplet dokumentów z datami i wersjami, odtwarza kolejność decyzji, rekonstruuje uzasadnienia i wyprowadza regułę ogólną. To, co było kosztowne, stało się tanie i szybkie.

W języku modelu interpreterów: daty i wersje są interpreterem. Same dokumenty to dane; dopiero uporządkowane w czasie i opatrzone uzasadnieniem zmian stają się wiedzą o metodzie. Rozdzielenie interpretera od danych jest tu tym samym zabezpieczeniem, co przy pseudonimizacji.

Podział warstw¶

Trzecia warstwa bywa mylona z pierwszą, a to różne rzeczy: audyt wymaga śladu decyzji klienta, nie śladu ewolucji naszej metody. Klient ma udowodnić, że jego zarząd coś zatwierdził – nie że my zmienialiśmy zdanie o modelu wyceny trzy razy w ciągu miesiąca.

Reguły redakcyjne dla dokumentów przekazywanych klientowi¶

Z dokumentu klienckiego usuwa się:

• sekcje typu „zmiany względem wersji poprzedniej" i uzasadnienia zmian,
• identyfikatory decyzji projektowych (D-xx) oraz odesłania do rejestru decyzji,
• ścieżki do plików źródłowych w drzewie FB,
• statystyki i stany pośrednie prac („78 aktywów, 23 propozycje podniesienia"),
• nazwy wariantów odrzuconych i ślady sporów metodycznych.

Zostaje: numer wydania, data zatwierdzenia, właściciel dokumentu – tyle, ile potrzeba do nadzoru nad dokumentacją, i ani zdania więcej o historii.

To nie jest ukrywanie czegokolwiek przed klientem. Klient dostaje wszystko, co dotyczy jego systemu; nie dostaje warsztatu, którym ten system zbudowano.

Kanon tworzenia dokumentów (rozszerzenie 2026-08-24)¶

Redakcja nie jest czynnością przed wysyłką – jest sposobem pisania. Dokument powstaje od razu jako suchy dokument dla odbiorcy; wersja z warsztatem nie istnieje w obiegu klienckim w ogóle. Powód praktyczny: redakcja robiona na końcu zawsze coś przepuszcza, a przy pośpiechu wypada pierwsza.

Nagłówek dokumentu klienckiego zawiera wyłącznie: tytuł, strony (klient, FB), datę opracowania. Nic więcej – żadnego opisu, co dokument realizuje, z czego wynika, jaką decyzję wykonuje ani co się w nim zmieniło.

Do dokumentu klienckiego nie wchodzą:

Zostaje wszystko, co dotyczy systemu klienta: wymagania, statusy, podstawy prawne, artefakty, pozycje do potwierdzenia po stronie klienta, terminy.

Test przed oddaniem dokumentu, jedno pytanie: czy z tego dokumentu da się odtworzyć, jak pracujemy – a nie tylko co ustaliliśmy? Jeżeli tak, wraca do redakcji.

Precedens: dokumenty VCN z sierpnia 2026 niosły nagłówki z odesłaniami do plików roboczych i not o zmianach; poprawiane są przy najbliższej edycji, nie hurtowo.

Odpowiedź na pytanie „dlaczego tak"¶

Usunięcie genealogii z dokumentu nie oznacza, że nie umiemy jej pokazać – oznacza, że nie wysyłamy jej z góry, każdemu i w komplecie. Na pytanie o powód rozstrzygnięcia sięga się do rejestru decyzji autora i wskazuje przyjętą podstawę: przepis, normę albo rozstrzygnięcie metodyczne.

Dwa rejestry, których nie wolno mylić:

Odpowiedź brzmi więc: „podstawą było X", a nie „oto historia naszych przemyśleń". Klient dostaje uzasadnienie decyzji, która go dotyczy – nie zapis drogi, którą metoda do niej doszła. To także chroni przed wciąganiem w spór o warsztat zamiast o rozstrzygnięcie.

Ta sama zasada działa w audycie¶

W raporcie audytowym nie umieszcza się druków roboczych – wypełnionych formularzy wywiadu, kart oceny dokumentu, arkuszy próby. Do raportu wchodzi treść dowodu: co stwierdzono, na czym się to opiera, jakie wymaganie zostało naruszone albo spełnione. Druk zostaje w aktach audytu u audytora.

Powód jest dokładnie ten sam co przy dokumentacji wdrożeniowej: druk pokazuje jak badamy, treść dowodu pokazuje co ustaliliśmy. Pierwsze jest warsztatem, drugie jest produktem.

Gdy na spotkaniu zamykającym albo w korespondencji pada pytanie, skąd wniosek – audytor sięga do akt i pokazuje konkretną podstawę: zapis z wywiadu, oznaczony dokument, wynik badania. Nie dlatego, że musiał to załączyć – dlatego, że to ma. Zdolność wykazania na żądanie jest mocniejsza niż wysłanie wszystkiego z góry: dowodzi kontroli nad materiałem, a nie tylko jego posiadania.

Wspólna reguła dla obu ról FB:

Konsekwencja, którą warto znać: skoro warsztat ma być pokazywalny na żądanie, musi być prowadzony porządnie – akta audytu i rejestr decyzji nie są notatnikiem, tylko materiałem dowodowym drugiej linii.

Dlaczego ta zasada jest wykonalna dopiero teraz¶

Symetria warta odnotowania: ta sama technologia obniżyła koszt po obu stronach. Odtworzenie cudzej metody z rozproszonych artefaktów stało się tanie – i dlatego pilnujemy warstw. Ale prowadzenie własnego rejestru decyzji też stało się tanie – i dlatego reguła „warsztat u nas, do pokazania na żądanie" przestała być obietnicą.

Wcześniej rejestr przegrywał z terminami: spisanie rozstrzygnięcia wraz z podstawą i kontekstem zajmowało porównywalnie tyle, co samo rozstrzygnięcie, więc powstawał po fakcie albo wcale. Zapis prowadzony na bieżąco w trakcie pracy zmienia rachunek – i dopiero to czyni zasadę operacyjną, a nie deklaratywną. Zasada, która wymaga heroizmu, żeby ją utrzymać, jest niespójnością czekającą na ujawnienie.

Zastosowanie¶

• Wiki kliencka (projekt <klient>) powstaje z osobnego renderu, a nie przez kopię wersji roboczej – w roboczej zostają nagłówki, zmiany i źródła. Format do opracowania; do tego czasu wiki kliencka nie powstaje.
• Dokumenty docx wysyłane klientowi – redakcja według listy powyżej przed wysyłką, nie po.
• Prezentacje i szkolenia – przykłady z wdrożeń bez nazw i dat własnych wersji metodyki.
• Materiały publiczne (artykuły, LinkedIn) – teza tak, genealogia nie.

Napięcie, o którym warto pamiętać¶

Ta zasada stoi w napięciu z zasadą dowodowej rzetelności: im mniej śladu, tym trudniej wykazać, że coś powstało w określony sposób. Rozstrzygnięcie: ślad istnieje i jest kompletny – tylko w warstwie FB. Nie kasujemy historii, przenosimy ją tam, gdzie jej miejsce.