SnapOtterandGitHub
d10d0f544f
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 |
|---|---|---|---|---|
| Wie man zu SnapOtter beiträgt. Fehlerberichte, Feature-Anfragen, Pull Requests und CLA-Anforderungen. | 6c920a5f83e0 | human | ed043841f564 | 2 |
Mitwirken
Vielen Dank für dein Interesse am Mitwirken. Dieser Leitfaden erklärt, wie du dich beteiligen kannst, was wir annehmen und wie du loslegst.
Möglichkeiten zum Mitwirken
Issues (kein Setup erforderlich)
- Fehlerberichte - Etwas kaputt? Öffne einen Fehlerbericht mit Schritten zur Reproduktion.
- Feature-Anfragen - Hast du eine Idee? Starte eine Diskussion, damit die Community sich einbringen und dafür stimmen kann.
- Übersetzungsprobleme - Eine falsche oder fehlende Übersetzung entdeckt? Öffne ein Übersetzungs-Issue.
- Dokumentationsprobleme - Etwas stimmt in der Dokumentation nicht? Öffne ein Dokumentations-Issue.
Code (erfordert CLA)
Wir nehmen Pull Requests an für:
| Typ | Ablauf |
|---|---|
| Fehlerbehebungen | Öffne direkt einen PR (verlinke das Issue, falls eines existiert) |
| Neue Übersetzungen | Öffne direkt einen PR (siehe Übersetzungsleitfaden) |
| Verbesserungen an der Dokumentation | Öffne direkt einen PR |
| Verbesserungen der Testabdeckung | Öffne direkt einen PR |
| Neue Tools oder Features | Starte zuerst eine Diskussion; ein Maintainer überführt genehmigte Ideen in ein nachverfolgtes Issue, bevor du Code schreibst |
| Refactorings oder Architekturänderungen | Starte zuerst eine Diskussion und warte auf die Freigabe eines Maintainers, bevor du Code schreibst |
Was wir nicht annehmen
- Änderungen an CI/CD-Workflows, Release-Konfiguration oder Linter-/Compiler-Konfiguration
- PRs ohne unterzeichnete Contributor License Agreement
- PRs mit mehr als 400 geänderten Zeilen (teile große Arbeiten in kleinere PRs auf)
- Features, die nicht zuvor besprochen und genehmigt wurden
- Änderungen an
packages/ai/ohne vorherige Absprache
Contributor License Agreement
Bevor wir deinen ersten PR mergen können, musst du unsere Individual CLA unterzeichnen. Das ist eine einmalige Voraussetzung.
Warum: SnapOtter ist dual lizenziert (AGPLv3 + kommerziell). Die CLA gewährt uns das Recht, deine Beiträge unter beiden Lizenzen zu verbreiten. Du behältst das volle Urheberrecht an deiner Arbeit.
Wie: Wenn du deinen ersten PR öffnest, kommentiert der CLA-Assistant-Bot mit einem Link. Klicke darauf, prüfe die Vereinbarung und unterzeichne mit deinem GitHub-Konto. Das dauert 30 Sekunden.
Wenn du im Auftrag deines Arbeitgebers beiträgst und dein Arbeitgeber die IP-Rechte an deiner Arbeit behält, wende dich an contact@snapotter.com, um vor der Einreichung eine Corporate CLA zu vereinbaren.
Erste Schritte
Voraussetzungen
- Node.js 22.22+
- pnpm 9+
- Python 3.11+ (nur für AI-Tools)
- Docker (optional, für vollständige Integrationstests)
Setup
# 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
Prüfungen ausführen
Stelle vor dem Einreichen eines PR sicher, dass alle Prüfungen lokal bestehen:
pnpm lint # Biome lint + format check
pnpm typecheck # TypeScript across monorepo
pnpm test # Vitest unit + integration tests
Ablauf eines Pull Requests
- Forke das Repository und erstelle einen Branch von
main(feat/my-featureoderfix/issue-123) - Nimm deine Änderungen in fokussierten, überprüfbaren Commits mit Conventional Commits vor
- Füge Tests für deine Änderungen hinzu oder aktualisiere sie
- Führe
pnpm lint && pnpm typecheck && pnpm testlokal aus - Öffne einen PR gegen
mainund fülle die Vorlage aus - Unterzeichne die CLA, falls du dazu aufgefordert wirst
- Warte, bis die CI besteht und ein Maintainer den PR prüft
Was du bei der Prüfung erwarten kannst
- Wir bemühen uns, innerhalb von 7 Tagen auf PRs zu reagieren
- Kleine, fokussierte PRs werden schneller geprüft
- Wenn du nach 7 Tagen nichts gehört hast, hinterlasse einen Kommentar und pinge den Thread an
- Wir können Änderungen anfordern, einen anderen Ansatz vorschlagen oder den PR schließen, wenn er nicht zur Projektausrichtung passt
Nachdem dein PR gemergt wurde
Dein Beitrag wird im nächsten Release enthalten sein und im Changelog vermerkt.
Gute erste Issues
Suchst du etwas, woran du arbeiten kannst? Sieh dir unsere guten ersten Issues für einsteigerfreundliche Aufgaben an oder help wanted für größere Aufgaben, bei denen wir uns über Unterstützung aus der Community freuen.
Codestil
- Biome übernimmt Formatierung und Linting (doppelte Anführungszeichen, Semikolons, Einrückung mit 2 Leerzeichen)
- Der Pre-Commit-Hook führt
biome check --writeautomatisch auf gestagten Dateien aus - Wenn der Linter meckert, behebe den Code (ändere nicht die Biome-Konfiguration)
- ES-Module überall (
import/export) - Conventional Commits:
feat:,fix:,refactor:,docs:,test:,chore:
Vollständige Architekturdetails findest du im Entwicklerleitfaden.
Sicherheit
Öffne keinen öffentlichen PR oder kein öffentliches Issue für Sicherheitslücken. Melde sie privat über GitHub Security Advisories oder per E-Mail an contact@snapotter.com. Alle Details findest du in SECURITY.md.