Files
SnapOtter/apps/docs/pl/guide/contributing.md
T
SnapOtterandGitHub d10d0f544f fix: release QA hardening across processing, media, security, and CI gates (#649)
A release-readiness QA pass over the whole product. The commits split into
defects a user would hit and gates that were reporting green while measuring
nothing.

## Fixes that change behaviour

Rate limiting was bypassable on every install: TRUST_PROXY defaulted to true, so
request.ip came from a client-set header and a forged X-Forwarded-For got past
the login limiter. The default is now a private-network trust list.

A transient Postgres outage stranded in-flight jobs, leaving finished output on
disk with no row pointing at it. A reconciler now resolves those rows and adopts
the bytes rather than dropping the work.

A Redis connection that moved to a new address wedged every read-blocked
consumer, so completions stopped signalling while health still answered 200.
Socket timeouts plus subscriber pings recover it.

Installing more than one AI bundle left the shared venv multi-versioned and
silently broke three tools. The installer now reconciles distributions to one
version each.

Converting an image to JXL at quality 1 through 4 returned a 500, because
libjxl 0.7 rejects the distance those values compute. The quality is floored at
what the encoder honours. A missing ffmpeg was also reported to the user as a
corrupt upload; it now says the engine is unavailable.

RAW uploads reached an unpatched LibRaw on arm64, so it is built from source at
0.22.2, and the release scan was split so it can fail on an unfixed critical
instead of hiding it behind ignore-unfixed.

## Gates that could not fail

Two mutation lanes ran zero mutants because Stryker crawled the gitignored docs
build; coverage discarded its whole report on any failing test; the lint gate
skipped root tests, scripts, and two workspaces; and several generated matrices
counted a host missing ffmpeg as a passing tool. Each now measures what it
claims.

Full evidence and the outstanding release items are tracked locally and are not
part of this branch.
2026-07-27 15:37:30 +08:00

6.9 KiB

description, i18n_source_hash, i18n_provenance, i18n_output_hash, i18n_hash_version
description i18n_source_hash i18n_provenance i18n_output_hash i18n_hash_version
Jak wnieść wkład w SnapOtter. Zgłoszenia błędów, propozycje funkcji, pull requesty i wymagania CLA. 6c920a5f83e0 human b6b9b3b7dca6 2

Wnoszenie wkładu

Dziękujemy za zainteresowanie wnoszeniem wkładu. Ten przewodnik opisuje, jak uczestniczyć, co akceptujemy i jak zacząć.

Sposoby wnoszenia wkładu

Zgłoszenia (nie wymagają konfiguracji)

Kod (wymaga CLA)

Akceptujemy pull requesty dotyczące:

Typ Proces
Poprawki błędów Otwórz PR bezpośrednio (podlinkuj zgłoszenie, jeśli istnieje)
Nowe tłumaczenia Otwórz PR bezpośrednio (zobacz Przewodnik po tłumaczeniach)
Ulepszenia dokumentacji Otwórz PR bezpośrednio
Ulepszenia pokrycia testami Otwórz PR bezpośrednio
Nowe narzędzia lub funkcje Najpierw rozpocznij dyskusję; opiekun projektu zamienia zatwierdzone pomysły w śledzone zgłoszenie, zanim zaczniesz pisać kod
Refaktoryzacje lub zmiany architektury Najpierw rozpocznij dyskusję i poczekaj na akceptację opiekuna projektu, zanim zaczniesz pisać kod

Czego nie zaakceptujemy

  • Zmian w przepływach CI/CD, konfiguracji wydań lub konfiguracji lintera/kompilatora
  • PR-ów bez podpisanej Umowy licencyjnej współtwórcy
  • PR-ów zmieniających ponad 400 wierszy (podziel dużą pracę na mniejsze PR-y)
  • Funkcji, które nie zostały wcześniej przedyskutowane i zatwierdzone
  • Zmian w packages/ai/ bez wcześniejszej dyskusji

Umowa licencyjna współtwórcy

Zanim będziemy mogli scalić Twój pierwszy PR, musisz podpisać naszą Indywidualną umowę CLA. Jest to wymóg jednorazowy.

Dlaczego: SnapOtter ma podwójną licencję (AGPLv3 + komercyjna). CLA daje nam prawo do dystrybucji Twojego wkładu na obu licencjach. Zachowujesz pełne prawa autorskie do swojej pracy.

Jak: Gdy otworzysz swój pierwszy PR, bot CLA Assistant doda komentarz z odnośnikiem. Kliknij go, zapoznaj się z umową i podpisz ją za pomocą swojego konta GitHub. Zajmuje to 30 sekund.

Jeśli wnosisz wkład w imieniu swojego pracodawcy, a pracodawca zachowuje prawa własności intelektualnej do Twojej pracy, skontaktuj się z contact@snapotter.com, aby przygotować firmową umowę CLA przed przesłaniem wkładu.

Pierwsze kroki

Wymagania wstępne

  • Node.js 22.22+
  • pnpm 9+
  • Python 3.11+ (tylko dla narzędzi AI)
  • Docker (opcjonalnie, do pełnego testowania integracyjnego)

Konfiguracja

# Fork and clone
git clone https://github.com/<your-username>/snapotter.git
cd snapotter

# Start Postgres + Redis for local dev
docker compose -f docker-compose.dev.yml up -d

# Install dependencies
pnpm install

# Start dev servers (web on :1351, API on :13490)
pnpm dev

Uruchamianie sprawdzeń

Przed przesłaniem PR-a upewnij się, że wszystkie sprawdzenia przechodzą lokalnie:

pnpm lint          # Biome lint + format check
pnpm typecheck     # TypeScript across monorepo
pnpm test          # Vitest unit + integration tests

Proces pull requesta

  1. Sforkuj repozytorium i utwórz gałąź z main (feat/my-feature lub fix/issue-123)
  2. Wprowadź zmiany w skupionych, łatwych do przejrzenia commitach, używając konwencjonalnych commitów
  3. Dodaj lub zaktualizuj testy dla swoich zmian
  4. Uruchom pnpm lint && pnpm typecheck && pnpm test lokalnie
  5. Otwórz PR względem main i wypełnij szablon
  6. Podpisz CLA, jeśli zostaniesz o to poproszony
  7. Poczekaj, aż CI przejdzie, a opiekun projektu przejrzy zmiany

Czego oczekiwać podczas przeglądu

  • Staramy się odpowiadać na PR-y w ciągu 7 dni
  • Małe, skupione PR-y są przeglądane szybciej
  • Jeśli nie otrzymasz odpowiedzi w ciągu 7 dni, zostaw komentarz przywołujący wątek
  • Możemy poprosić o zmiany, zasugerować inne podejście lub zamknąć PR, jeśli nie jest zgodny z kierunkiem projektu

Po scaleniu Twojego PR-a

Twój wkład zostanie uwzględniony w kolejnym wydaniu i wymieniony w dzienniku zmian.

Dobre pierwsze zgłoszenia

Szukasz czegoś do zrobienia? Sprawdź nasze dobre pierwsze zgłoszenia w poszukiwaniu zadań przyjaznych dla początkujących lub potrzebna pomoc w przypadku większych zadań, przy których docenimy pomoc społeczności.

Styl kodu

  • Biome zajmuje się formatowaniem i lintowaniem (cudzysłowy podwójne, średniki, wcięcie 2 spacje)
  • Hook pre-commit automatycznie uruchamia biome check --write na plikach ze staging
  • Jeśli linter zgłasza uwagi, popraw kod (nie modyfikuj konfiguracji Biome)
  • Moduły ES wszędzie (import/export)
  • Konwencjonalne commity: feat:, fix:, refactor:, docs:, test:, chore:

Pełne informacje o architekturze znajdziesz w Przewodniku dla programistów.

Bezpieczeństwo

Nie otwieraj publicznego PR-a ani zgłoszenia dla luk bezpieczeństwa. Zgłaszaj je prywatnie poprzez GitHub Security Advisories lub e-mailem na contact@snapotter.com. Pełne szczegóły znajdziesz w SECURITY.md.

Pytania?