trade-doc/gitea-repo-cleanup-plan.md

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