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.
7.2 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 |
|---|---|---|---|---|
| Comment contribuer à SnapOtter. Rapports de bugs, demandes de fonctionnalités, pull requests et exigences du CLA. | 6c920a5f83e0 | human | ef79a31d14aa | 2 |
Contribuer
Merci de l'intérêt que vous portez à contribuer. Ce guide explique comment participer, ce que nous acceptons et comment démarrer.
Façons de contribuer
Tickets (aucune configuration requise)
- Rapports de bugs - Quelque chose est cassé ? Ouvrez un rapport de bug avec les étapes de reproduction.
- Demandes de fonctionnalités - Vous avez une idée ? Lancez une discussion pour que la communauté puisse donner son avis et voter pour elle.
- Problèmes de traduction - Vous repérez une traduction erronée ou manquante ? Ouvrez un ticket de traduction.
- Problèmes de documentation - Quelque chose cloche dans la documentation ? Ouvrez un ticket de documentation.
Code (nécessite le CLA)
Nous acceptons les pull requests pour :
| Type | Processus |
|---|---|
| Corrections de bugs | Ouvrez une PR directement (liez le ticket s'il en existe un) |
| Nouvelles traductions | Ouvrez une PR directement (voir le Guide de traduction) |
| Améliorations de la documentation | Ouvrez une PR directement |
| Améliorations de la couverture de tests | Ouvrez une PR directement |
| Nouveaux outils ou fonctionnalités | Lancez d'abord une discussion ; un mainteneur convertit les idées approuvées en un ticket suivi avant que vous n'écriviez du code |
| Refactorisations ou changements d'architecture | Lancez d'abord une discussion et attendez la validation d'un mainteneur avant d'écrire du code |
Ce que nous n'accepterons pas
- Les modifications des workflows CI/CD, de la configuration de release ou de la configuration du linter/compilateur
- Les PR sans Accord de licence de contributeur signé
- Les PR de plus de 400 lignes de changement (découpez les gros travaux en PR plus petites)
- Les fonctionnalités qui n'ont pas été discutées et approuvées au préalable
- Les modifications de
packages/ai/sans discussion préalable
Accord de licence de contributeur
Avant que nous puissions fusionner votre première PR, vous devez signer notre CLA individuel. C'est une exigence à faire une seule fois.
Pourquoi : SnapOtter est sous double licence (AGPLv3 + commerciale). Le CLA nous accorde le droit de distribuer vos contributions sous les deux licences. Vous conservez la pleine propriété du droit d'auteur sur votre travail.
Comment : Lorsque vous ouvrez votre première PR, le bot CLA Assistant publie un commentaire avec un lien. Cliquez dessus, relisez l'accord et signez avec votre compte GitHub. Cela prend 30 secondes.
Si vous contribuez pour le compte de votre employeur et que celui-ci conserve les droits de propriété intellectuelle sur votre travail, contactez contact@snapotter.com pour mettre en place un CLA d'entreprise avant de soumettre.
Démarrage
Prérequis
- Node.js 22.22+
- pnpm 9+
- Python 3.11+ (uniquement pour les outils d'IA)
- Docker (facultatif, pour les tests d'intégration complets)
Configuration
# 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
Exécuter les vérifications
Avant de soumettre une PR, assurez-vous que toutes les vérifications passent en local :
pnpm lint # Biome lint + format check
pnpm typecheck # TypeScript across monorepo
pnpm test # Vitest unit + integration tests
Processus de pull request
- Forkez le dépôt et créez une branche à partir de
main(feat/my-featureoufix/issue-123) - Effectuez vos modifications dans des commits ciblés et relisibles en utilisant les commits conventionnels
- Ajoutez ou mettez à jour les tests pour vos modifications
- Exécutez
pnpm lint && pnpm typecheck && pnpm testen local - Ouvrez une PR contre
mainet remplissez le modèle - Signez le CLA si on vous le demande
- Attendez que la CI passe et qu'un mainteneur fasse sa relecture
Attentes concernant la relecture
- Nous visons à répondre aux PR sous 7 jours
- Les PR petites et ciblées sont relues plus rapidement
- Si vous n'avez pas de nouvelles sous 7 jours, laissez un commentaire pour relancer le fil
- Nous pouvons demander des modifications, suggérer une approche différente ou fermer la PR si elle ne correspond pas à la direction du projet
Une fois votre PR fusionnée
Votre contribution sera incluse dans la prochaine release et créditée dans le changelog.
Bons premiers tickets
Vous cherchez quelque chose sur quoi travailler ? Consultez nos bons premiers tickets pour des tâches adaptées aux débutants, ou aide recherchée pour des chantiers plus importants où l'aide de la communauté serait appréciée.
Style de code
- Biome gère le formatage et le linting (guillemets doubles, points-virgules, indentation de 2 espaces)
- Le hook de pré-commit exécute automatiquement
biome check --writesur les fichiers indexés - Si le linter se plaint, corrigez le code (ne modifiez pas la configuration de Biome)
- Modules ES partout (
import/export) - Commits conventionnels :
feat:,fix:,refactor:,docs:,test:,chore:
Pour tous les détails d'architecture, consultez le Guide du développeur.
Sécurité
N'ouvrez pas de PR ou de ticket public pour les vulnérabilités de sécurité. Signalez-les de manière privée via les GitHub Security Advisories ou par e-mail à contact@snapotter.com. Consultez SECURITY.md pour tous les détails.