# Operator i zmienione rozliczenie: lokalna próba

Syntalith, 11 października 2026. To osobny demonstrator z fikcyjnymi rozliczeniami. Rozszerza wcześniejszy moduł kontroli należności o widok operatora i uprawnienia przypisane do konta w konfiguracji serwera. Nie wywołuje modelu, banku, księgowości ani dostawcy wiadomości.

Operator widzi fakturę 12/10 na 100 zł i przypisaną wpłatę 70 zł. Przygotowuje rekord 30 zł i zatwierdza go lokalnie. Następna fikcyjna wersja zawiera dodatkową wpłatę 10 zł: poprzedni rekord zostaje unieważniony, a nowy wynosi 20 zł. Po kolejnej wersji z oznaczonym sporem oba rekordy pozostają historyczne i przygotowanie nowego zostaje zatrzymane. Decyzje zachowują nazwę konta ustaloną przez serwer.

Dwa fikcyjne podmioty mają tę samą nazwę kontrahenta i numer faktury. Konto jednego nie otrzymuje drugiego rozliczenia i nie może zatwierdzić jego rekordu. To ograniczona próba lokalnej konfiguracji, bez produkcyjnego logowania i zarządzania uprawnieniami.

## Co można odtworzyć

Pobierz experiment.zip. Potrzebny jest Python 3, wyłącznie biblioteka standardowa. Z katalogu rozpakowanego pakietu:

```sh
PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s receivables-control-2026-10-11 -p 'test_*.py' -v
PYTHONDONTWRITEBYTECODE=1 python3 receivables-operator-2026-10-11/test_http.py
```

Pierwszy moduł ma 15 testów rozliczeń i trwałości. Cztery testy HTTP sprawdzają token, Host/Origin, odrzucenie tożsamości z żądania, rozdzielenie podmiotów, zmianę źródła, oznaczony spór oraz ponowienie po restarcie. Nie sumujemy tego jako miary jakości AI. Logi, zapis przeglądu ekranu i osobny odczyt API/SQLite są w pakiecie. Testy i implementację przygotował ten sam agent.

## Otworzenie interfejsu

Poza katalogiem publicznym utwórz plik JSON z tablicą kont. Każde konto ma token (losowy ciąg co najmniej 20 znaków), actor (fikcyjne oznaczenie operatora) i customer (creditor-a/customer-x albo creditor-b/customer-x). Nie używaj prawdziwych danych klientów.

```sh
PYTHONDONTWRITEBYTECODE=1 python3 receivables-operator-2026-10-11/server.py --database /tmp/receivables-demo.sqlite --accounts /tmp/receivables-accounts.json --port 3197
```

Otwórz http://127.0.0.1:3197 i wpisz token. Konto pozostaje w pamięci interfejsu do zamknięcia sesji. Po próbie zatrzymaj serwer. Nie wystawiaj go w sieci publicznej.

## Co wynik potwierdza i czego nie mierzy

W przeglądzie na 1440 i 390 pikselach wykonano opisany przebieg. Pierwsza próba ujawniła zbyt szeroki identyfikator w historii; poprawka zawijania tekstu przeszła powtórny przegląd. Osobny odczyt API, SQLite i nowego procesu potwierdził dwa unieważnione rekordy oraz dwie zachowane akceptacje operatora. To nie jest próba zaniku zasilania.

Wczytywane źródła to stałe pliki przygotowane przez autora, sprawdzane sumą SHA-256. Hash potwierdza tożsamość pliku, nie prawdziwość salda ani kompletność danych z ksiąg. Wpłaty, przypisania i oznaczenie sporu zostały wpisane ręcznie. Wcześniejszy test negatywny pokazuje, że błędne oznaczenie spornej wiadomości przez człowieka może przepuścić sprawę. Nie mierzymy rozpoznawania reklamacji przez model.

Brakuje konektorów, produkcyjnego uwierzytelniania, cyklu cofania uprawnień, retencji i pełnej historii importów. Zegar oraz próg aktualności należą do założeń przykładu. Dane mają jedną walutę, dodatnie kwoty i jawne przypisania. Nie obsługujemy korekt, naliczeń wspólnot, harmonogramów leasingowych ani dokumentów wykonania usługi. Historia rekordów nie jest historią kontaktu: nowa wersja może utworzyć kolejny rekord tej samej faktury. Nie ma tekstu przypomnienia, wysyłki, oceny roszczenia ani pomiaru odzyskanych należności. Pobranych wcześniej danych nie da się unieważnić w niepodłączonym zewnętrznym systemie.