# Gitea repo cleanup plan

Stan na `2026-03-13`.

Cel:
- uporzadkowac repo `trade/*` na `gitea.mpabi.pl`
- wskazac jednoznaczne source of truth
- odseparowac repo aktywne od historycznych lub porzuconych
- uniknac kasowania aktywnych danych w ciemno

## Zasady

1. Najpierw archiwizacja, nie usuwanie.
2. Najpierw ustalic source of truth, potem porzadkowac branche.
3. Nie zostawiac repo, ktore duplikuja aktywny kod w innym miejscu.
4. `trade-deploy` i `trade-iac` traktowac jako repo operacyjne o wysokim priorytecie.
5. Po cleanupie kazde aktywne repo ma miec:
   - poprawny remote
   - aktywnego ownera
   - jasna role
   - aktualne README

## Repo po repo

### `trade-frontend`

Status:
- aktywne
- lokalne source of truth dla UI i `apps/visualizer`
- na Gitei sa juz aktualne branche robocze

Decyzja:
- zostawic

Dzialania:
- utrzymac jako repo dla:
  - frontend SPA
  - visualizer
  - dokumentacji frontend/runtime, jesli ma zostac blisko kodu
- zamknac stare branche po merge
- nie wydzielac ponownie `trade-visualizer`

### `trade-api`

Status:
- aktywne logicznie
- lokalny checkout nadal wskazuje na stare `rv32i.pl`
- lokalny `main` rozjechany z `gitea.mpabi.pl/trade/trade-api`

Decyzja:
- zostawic
- uporzadkowac natychmiast

Dzialania:
- przepiac local remote na `gitea.mpabi.pl`
- porownac lokalny `main` z Gitea `main`
- zdecydowac:
  - czy lokalny checkout jest historyczny i do porzucenia
  - czy trzeba go zrebase'owac/cherry-pickowac na nowe repo
- dopiero potem wznowic aktywne prace

### `trade-ingestor`

Status:
- aktywne
- lokalny checkout jest zgodny z Gitea
- rola w runtime wymaga przedefiniowania

Decyzja:
- zostawic

Dzialania:
- zachowac repo
- zmienic role z glownego ingestu na:
  - pomocniczy ingest
  - backfill
  - normalizacja danych pomocniczych
- dopisac README z aktualna rola po redesignie DLOB

### `trade-drift-dlob`

Status:
- repo istnieje na Gitei
- lokalnie aktywnie pracujesz na `dlob-server`
- source of truth nie jest jeszcze czyste

Decyzja:
- zostawic
- uporzadkowac zaraz po `trade-api`

Dzialania:
- zdecydowac, czy `dlob-server` ma zostac przeniesiony do `trade-drift-dlob`
- jesli tak:
  - uznac `trade-drift-dlob` za docelowe repo
  - przeniesc aktualny kod i workflow tam
- jesli nie:
  - zarchiwizowac `trade-drift-dlob`
  - ale tylko po migracji kodu do repo docelowego

### `trade-deploy`

Status:
- aktywne
- repo GitOps
- na Gitei jest aktualny branch z overlay `mevnode-bot`

Decyzja:
- zostawic

Dzialania:
- utrzymac jako jedyne source of truth dla runtime `k3s`
- nie trzymac runtime patchy poza tym repo
- porzadkowac branche po merge

### `trade-iac`

Status:
- aktywne
- zawiera bootstrap/infra
- branch roboczy `step2-solana-rpc` jest na Gitei

Decyzja:
- zostawic

Dzialania:
- utrzymac jako source of truth dla:
  - bootstrap hostow
  - k3s
  - wireguard
  - provisioning
- po merge wyczyscic stare branche robocze

### `trade-infra`

Status:
- repo istnieje
- lokalny checkout jest zsynchronizowany
- jego rola nie jest dzis jednoznaczna

Decyzja:
- tymczasowo zostawic
- wymagac decyzji architektonicznej

Dzialania:
- wybrac jedna z dwoch rol:
  - umbrella/superproject
  - repo narzedziowe ops
- jesli nie dostanie konkretnej roli, zarchiwizowac

### `trade-doc`

Status:
- repo istnieje
- lokalny checkout zsynchronizowany
- czesc aktywnej dokumentacji zyje jednak w `trade-frontend`

Decyzja:
- tymczasowo zostawic
- wymagac decyzji o modelu dokumentacji

Dzialania:
- wybrac jedna z dwoch strategii:
  - docs centralne w `trade-doc`
  - docs przy repo kodowym
- jesli wybierzesz docs przy kodzie:
  - `trade-doc` zarchiwizowac po migracji najwazniejszych materialow

### `trade-visualizer`

Status:
- repo istnieje na Gitei
- lokalnie `visualizer` zyje w `trade-frontend`
- brak sensu utrzymywac dwoch rownoleglych repo dla tego samego obszaru

Decyzja:
- archiwizowac

Dzialania:
- sprawdzic, czy nie ma tam unikalnego kodu do uratowania
- jesli nie ma:
  - oznaczyc repo jako archived
  - dopisac w opisie, ze `visualizer` jest teraz w `trade-frontend`

### `trade-inc`

Status:
- repo istnieje na Gitei
- brak lokalnego checkoutu
- brak widocznego uzycia w deployu i codziennej pracy

Decyzja:
- archiwizowac

Dzialania:
- sprawdzic, czy nie ma tam czegos krytycznego historycznie
- jesli nie ma:
  - oznaczyc repo jako archived

## Priorytety wykonania

### Faza 1. Uporzadkowanie aktywnych repo

1. `trade-api`
2. `trade-drift-dlob`
3. `trade-deploy`
4. `trade-iac`

Cel:
- miec wszystkie aktywne repo na poprawnych remote
- miec jasny source of truth dla kodu i deployu

### Faza 2. Decyzje architektoniczne

1. `trade-doc`
2. `trade-infra`

Cel:
- zdecydowac, czy te repo maja nadal odrebna wartosc

### Faza 3. Archiwizacja repo zbednych

1. `trade-visualizer`
2. `trade-inc`

Cel:
- odchudzic Gitee bez utraty historii

## Plan zmian operacyjnych

### Krok 1. `trade-api`

- przepiac local remote na `gitea.mpabi.pl`
- pobrac `origin/main`
- porownac commit lokalny z Gitea
- zdecydowac, czy:
  - zachowac lokalny checkout
  - czy porzucic go i klonowac od nowa

### Krok 2. `trade-drift-dlob`

- porownac repo `trade-drift-dlob` z lokalnym `dlob-server`
- wybrac repo docelowe
- dopiero potem przenosic redesign DLOB

### Krok 3. `trade-doc` vs docs przy kodzie

- jesli dokumentacja ma byc centralna:
  - przenosic nowe materialy do `trade-doc`
- jesli dokumentacja ma byc przy repo:
  - stopniowo wygaszac `trade-doc`

### Krok 4. Archiwizacja

- ustawic `Archived` na:
  - `trade-visualizer`
  - `trade-inc`
- bez usuwania repo

## Rekomendacja koncowa

Docelowy zestaw aktywnych repo:
- `trade-frontend`
- `trade-api`
- `trade-ingestor`
- `trade-drift-dlob`
- `trade-deploy`
- `trade-iac`

Repo warunkowe:
- `trade-infra`
- `trade-doc`

Repo do archiwizacji:
- `trade-visualizer`
- `trade-inc`