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.
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)
- Zgłoszenia błędów - Coś nie działa? Otwórz zgłoszenie błędu wraz z krokami do odtworzenia problemu.
- Propozycje funkcji - Masz pomysł? Rozpocznij dyskusję, aby społeczność mogła się wypowiedzieć i oddać na nią głos.
- Problemy z tłumaczeniami - Zauważyłeś błędne lub brakujące tłumaczenie? Otwórz zgłoszenie dotyczące tłumaczenia.
- Problemy z dokumentacją - Coś jest nie tak w dokumentacji? Otwórz zgłoszenie dotyczące dokumentacji.
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
- Sforkuj repozytorium i utwórz gałąź z
main(feat/my-featurelubfix/issue-123) - Wprowadź zmiany w skupionych, łatwych do przejrzenia commitach, używając konwencjonalnych commitów
- Dodaj lub zaktualizuj testy dla swoich zmian
- Uruchom
pnpm lint && pnpm typecheck && pnpm testlokalnie - Otwórz PR względem
maini wypełnij szablon - Podpisz CLA, jeśli zostaniesz o to poproszony
- 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 --writena 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.