Struktura budowanego systemu · stan 27.09.2026
Architektura bota crypto scalping
Kliknij warstwę, aby zobaczyć, co robi i z kim się komunikuje. System ma działać „jak trader”: najpierw rozumie sytuację na wykresie, potem formułuje tezę, wchodzi, prowadzi pozycję i uczy się na wynikach — każda warstwa robi jedną rzecz i przekazuje dalej jeden obiekt z kontraktem JSON. Strona pokazuje strukturę; dashboard rozwoju (lejek hipotez, tempo uczenia) to etap G4.
1. Warstwy (od pomiaru do kapitału)
0 · PomiarP7 ledger, P8 kosztG1 PASS
Jedna prawda o każdym trade'zie: USD z deali, R w kanonie właściciela (z faktycznego wypełnienia, flaga fill_near_sl, obok R_signal), koszt rzeczywisty (spread para × godzina × typ dnia + poślizg wejścia ~0,04 R), latencja jako rozkład (P50 0,96 s / P95 2,4 s), blocked_by / would_have_R dla zatrzymanych sygnałów.
Wejście: dziennik floty (kopie SQLite + sha256), deale MT5, fast_signals, wyniki paper. Wyjście: LedgerEvent@1 (JSONL z łańcuchem sha256), CostModel@1, ExecutionModel@1. Każda warstwa czyta ledger, pisze tylko P7. Rekoncyliacja z dashboardem 4/4 dni co do centa.
1a · SytuacjaP2G2 PASS
„Karta wykresu” tradera w chwili sygnału: trend 1m…4h/1d (silnik cech generatora, parytet 100 %), faza ruchu (impuls / wyczerpanie / odbicie / range), mapa poziomów (S/R wyższych TF, H/L dnia i tygodnia, VWAP, OR, okrągłe liczby), formacje 15m/1h/4h (liczone raz), makro (risk-on/off z BTC, kalendarz), przepływ, spread i grupa kosztowa. Brak danych = brak biasu.
Wyjście: Situation@1 z situation_id (sha treści), dołączany do każdego sygnału. Czytają: P3 generator, P4 alokator, P9 egzamin (bramki per faza), P6 zarządzanie (świeża karta co bar).
1a' · Sygnał + tezaP3 generator (dziś obserwator SCALPOWANIE)istnieje
Reguły i detektory dają FastSignal@1 (wejście, SL autora, TP) i thesis@1: kierunek, kody powodów odwołujące się do karty, warunek unieważnienia poza SL (struktura, czas, zdarzenie), oczekiwana ścieżka.
Sygnał + teza + situation_id idą kanałem szybkim (TCP 47931 + JSONL) do P4.
1b · WyjściaExitConfig@1plan
Drabinka TP, próg BE, trailing, time-stop warunkowy i runner jako jeden obiekt, bo we flocie BE = ułamek dystansu do TP1: zmiana TP1 bez BE kasuje przewagę. Warianty testowane jako całe obiekty (rodzina E).
exit_config_id w Trade@1; P5 egzekwuje; P9 porównuje warianty sparowane na tych samych sygnałach.
1c · Zarządzanie pozycjąP6 (nowa)plan
Po wejściu co zamknięty bar pobiera świeżą kartę i tezę; regułami z góry: wyjście, gdy teza unieważniona (struktura przeciw, czas bez MFE, zdarzenie High), stop za strukturą, redukcja przy zmianie fazy. Najpierw jako cień (log-only), egzekwowanie po egzaminie.
RPC do P5 (modify_sl, close_partial), ExitEvent do ledgera.
2 · Koszt · kalendarz · makroP8 + rekorderczęściowo
Model kosztu (spread, poślizg, grupa kosztowa pary A/B/C; alarm gdy 7-dniowy spread/zasięg > 0,2), kalendarz makro z surowego źródła, stan makro i sentyment liczony offline.
Zasila kartę (1a), bramkę (P4: SL ≥ 5 × spread, blackouty) i egzamin (wynik netto po kosztach).
3 · EgzekucjaP5 = flota discord_mt5 (jedyny order_send)istnieje
Zlecenia, wypełnienia, transze, lustro dwóch kont, kolejka per para (final-28: limit 2,5 s + strażnik dryfu), telemetria wieku sygnału.
Przyjmuje admission z P4, zwraca Fill@1 / Trade@1 i dziennik do P7. ExecutionModel@1 pozwala replayowi symulować dokładnie tę egzekucję.
4 · Rejestr + egzaminP9 / P10G3 w budowie
Hipoteza rejestrowana przed liczeniem (hash protokołu), forward od rejestracji, jednostka = epizod, klaster = dzień, BH per rodzina / Holm do promocji, nadwyżka nad losowym dla bramek, suspect_simulation (> 85 % trafień), ocena tygodniowa. Statusy: nominated / rejected / underpowered / suspect / promoted_conditional; karta negatywna dla odrzuconych. Produkt: EGZAMIN-tydzień, PLAYBOOK.json (sytuacja → dozwolone rodziny).
Czyta ledger, kartę, koszt; jedyna droga paper → live = przełączenie admission w P4 po decyzji właściciela.
5 · UczenieP11 (jeden temat = jeden przebieg)plan
Źródła (książki, papers, TradingView/Pine, YouTube, lekcje pętli, dziennik) → karty Hypothesis@1 z source_kind → rejestr. LLM tylko offline: narracja z testem cytowania, ekstrakcja specyfikacji; nigdy nie zmienia reguł ani konfiguracji. Meta-pętla: ImprovementProposal@1 do backlogu bramek po przeglądzie.
Pisze wyłącznie do rejestru i backlogu; czyta wszystko.
6 · Kapitał i ryzykoP4 alokatorplan
„Czy, gdzie i ile” oddzielone od „kiedy”: budżet per księga w USD, wielkość w USD, sloty, korelacja z otwartymi pozycjami, ranking okazji w oknie 60 s, hamulec serii i cooldown kierunku (2 SL tej samej strony → blokada 15 min), kill-switche, dzienny limit, wybór par wg grupy kosztowej.
Wyjście: admission {allow | shadow | block, blocked_by, size_usd, book}. Jedyny punkt, w którym egzamin wpływa na handel; bramki z cienia egzekwowane dopiero po nadwyżce nad losowym.
2. Droga jednego sygnału (jedna koperta, jeden signal_id)
- P1 rekorder → dane rynku Envelope
- P2 sytuacja →
situation_idSituation@1 - P3 generator → sygnał + teza FastSignal@1 · Thesis@1
- P4 bramka / alokator → decyzja Admission
- P5 egzekucja → wypełnienie, transakcja Fill@1 · Trade@1.1 · ExecutionModel@1
- P6 zarządzanie → zdarzenia wyjścia ExitConfig@1 · ExitEvent
- P7 ledger → USD, R kanoniczne LedgerEvent@1.1 · CostModel@1
- P9 egzamin · P10 rejestr · P11 uczenie → hipotezy Hypothesis@1
- Zmiana systemu tylko przez
admission— nic nie trafia bezpośrednio do generatora
Jak warstwy się komunikują
- Jedna koperta z jednym
signal_idprzez całą drogę P2 → P3 → P4 → P5 → P6 → P7; każdy proces dopisuje swój blok w kontrakcie JSON walidowanym na granicy. - Jeden rdzeń (
botlab.core: geometria SL/TP, wypełnienia, faza, ExitConfig) importowany identycznie przez live i replay, więc egzamin ocenia dokładnie to, co gra flota. - Dane append-only z proweniencją, stan zapisywany atomowo, ledger i rejestr z łańcuchem sha256.
- Zmiany tylko przez rejestr → egzamin → admission, nigdy przez edycję innej warstwy.
- Role sesji: SCALPOWANIE = generator/obserwator, flota = egzekucja, lab (Architektura) = warstwy 0/1a/1c/4/5/6 w scalp-lab, PRZEGLĄDY = bramka przeglądu, PĘTLE = badania, DASHBOARD = widok (tylko odczyt).
Księgi: scalp (1m/5m, AAVE + XLM, dziś poligon egzekucji i wyjść), intraday (15m–4h, retest + SL strukturalny, ciężar hipotez), swing (4h/1d). Każda ma własny budżet ryzyka i progi egzaminu; wspólne: karta, koszt, ledger, rdzeń.
3. Kto za co odpowiada
| Warstwa | Proces | Wejście → wyjście | Właściciel kodu | Status |
|---|---|---|---|---|
| 0 Pomiar | P7 ledger | Fill/Trade → LedgerEvent (USD, R) | lab / Architektura (scalp-lab) | istnieje (G1) |
| 1a Sytuacja | P1, P2 | świece, przepływ → Situation | lab / Architektura | istnieje (G2) |
| 1a' Sygnał | P3 | Situation → FastSignal + Thesis | SCALPOWANIE (generator, obserwator) | istnieje |
| 1b/1c Wyjścia i prowadzenie | P6 | Trade → ExitEvent | lab / Architektura | plan |
| 3 Egzekucja | P4, P5 | Admission → Fill, Trade | flota (discord_mt5) | istnieje |
| 4 Egzamin | P9, P10 | LedgerEvent → werdykt hipotezy | lab / Architektura; PRZEGLĄDY = bramka przeglądu | w budowie (G3) |
| 5 Uczenie | P11 | wyniki → Hypothesis | lab; PĘTLE = badania | plan |
| 6 Kapitał | P4 alokator | sygnały → sloty, limity | lab / Architektura | plan |
| Widok | — | wszystko → strony dashboardu (tylko odczyt) | DASHBOARD | istnieje |
4. Bramki budowy
Status statyczny do czasu, aż lab zacznie publikować scalp-lab/reports/lab/status.json (od G3) — wtedy strona będzie go czytać.
5. Zasady, których system nie łamie
- Replay = live: ten sam kod liczy historię i rynek na żywo.
- Pre-rejestracja: hipoteza zapisana przed testem, nie po.
- Jedna definicja R: z faktycznego wypełnienia i pierwotnego SL.
- LLM tylko offline: model nie decyduje na żywo.
- Nic bezpośrednio do generatora: zmiany tylko przez bramkę i akceptację właściciela.
- Lab poza żywym repo: eksperymenty nie dotykają floty.
- Liveness ≠ PID: proces żyje, gdy produkuje świeże dane, nie gdy ma PID.