Guide de la version préliminaire · 0.1.0
Étendre les sources avec des contrats clairs
Identifiez les frontières des analyseurs, éléments, clients et workflows qu’une contribution ciblée doit préserver.
La référence de l’API est en anglais.
Les sources offrent plusieurs points de contribution : adaptateurs et règles d’analyse, éléments normalisés, workflows durables, interface React et client VS Code. Ce sont des frontières d’implémentation examinées. Il n’existe ni SDK de plugins à l’exécution, ni registre arbitraire d’exécutables, ni intégration générique par clé API.
Choisir une contribution bornée
- Trouver le contrat
Commencez par registre public, dispatch des adaptateurs et schéma normalisé des constats.
- Examiner les entrées d’outils et de données
Actualisez les entrées de build figées, notices et exigences de données concernées.
- Implémenter l’adaptateur borné
Définissez arguments, environnement et parsing exacts. Préservez périmètre, limites de sortie et expurgation des motifs connus.
- Relier disponibilité et couverture
Rendez données absentes, outils indisponibles et analyse limitée visibles dans les prérequis et le résultat.
- Exercer le comportement modifié
Utilisez de petites fixtures synthétiques et des contrôles ciblés de parsing, échec, disponibilité et collecte.
- Examiner tout le changement
Reliez les modifications aux contrats UI et API affectés avant de proposer une contribution.
| Domaine | Point de départ | Contrat à préserver |
|---|---|---|
| Exécution des analyseurs | Registre et adaptateurs natifs | Identité figée, configuration maîtrisée, exécution bornée et résultats honnêtes de parsing/couverture. |
| Règles et données | Verrou des outils, verrou des règles et validation des générations | Entrées examinées, identité du contenu, compatibilité, fraîcheur et activation atomique. |
| Constats et artefacts | Normalisation et frontière d’artefacts | Emplacement et empreinte canoniques, métadonnées bornées, expurgation et publication attestée. |
| Workflows durables | Dépôt de jobs et exécution worker | Idempotence, isolation des baux/tentatives, échéances, annulation et checkpoints récupérables. |
| Parcours navigateur | Application React | Actualisation des ressources faisant autorité, révisions attendues, états d’attente/erreur utiles et accessibilité. |
| Parcours éditeur | Sources VS Code | Génération active, Workspace Trust, identité source et actions hôtes explicites. |
Une petite fixture de règle ou une correction précise de workflow peut être un bon début. Décrivez le comportement corrigé et les éléments qui le démontrent. N’utilisez pas une catégorie générale comme « prise en charge SAST » pour promettre toutes les langues ou faiblesses.
Ajouter ou modifier un analyseur de façon coordonnée
Le registre fixe valide versions, commandes de version, arguments, passes complémentaires, environnements et formats contre le verrou. Ajouter un binaire à une image ne suffit donc pas. Les identifiants inconnus sont refusés à l’exécution.
- Examinez sources amont, licence, modifications et entrées exactes de compilation/téléchargement. Préservez les notices et liez l’identité de l’image.
- Actualisez catalogue et verrous avec commande, format et règles/données nécessaires. Gardez la préparation réseau séparée de l’exécution sur les sources.
- Implémentez adaptateur et parseur avec contrôles maîtrisés, durée et sortie bornées, emplacements canoniques et erreurs honnêtes. Une sortie mal formée ne doit pas devenir zéro constat.
- Intégrez disponibilité et couverture. Un prérequis absent reste visible avant admission ou dans les éléments incomplets.
- Ajoutez selon le cas tests positifs, sans constat, mal formés, surdimensionnés, timeout et contrôle des sources. Vérifiez l’outil natif autant que les fixtures du parseur.
- Examinez constats normalisés, expurgation, empreintes déterministes et tout le parcours de publication du worker. Un rapport brut n’est pas automatiquement un artefact pris en charge.
La matrice d’exécution explique les différences : Trivy a deux passes ; Grype dépend de Syft ; Checkov maîtrise la découverte de configuration ; Bearer utilise un build modifié. Chaque mise à niveau exige des éléments renouvelés sur ces contrats particuliers.
Préserver le sens des éléments dans les nouveaux workflows
Un statut ou une action UI peut changer plus qu’un libellé. Les constats ont révisions et décisions ; les analyses ont couverture et contrôle ; les jobs ont baux et issues terminales. Gardez ces significations séparées.
Accepter le risque exclut par exemple un constat des comptes du contrôle sans compléter la couverture. Marquer fixed enregistre une revue sans vérifier les sources modifiées. Une analyse terminée de l’arbre de travail ne peut autoriser un push dont d’anciens commits sortants contiennent d’autres arbres.
Les changements client doivent réconcilier REST après événements, resets et mutations, pas traiter les indications comme ressources complètes. Une réponse périmée ne doit pas écraser une décision récente. Examinez contrat de révision API et comportement visible lors de navigation, reconnexion, annulation et échec.
Garder les intégrations dans les droits existants
Les clients utilisent session/CSRF du navigateur ou scopes IDE exacts permis, avec les contrôles de propriété de chaque route. Les protocoles internes d’analyseur, de mise à jour et Advisor ne sont pas des API d’intégration prises en charge. Une nouvelle route ne doit pas donner accidentellement à chaque éditeur associé des actions réservées au propriétaire ou un montage plus large.
Une extension Advisor doit préserver la frontière de divulgation. La confirmation distante d’un constat lie destination, modèle, configuration, consentement et prompt ; la résolution automatique à l’échelle d’une analyse reste locale. Le connecteur parle les routes Ollama examinées. Ajouter un fournisseur est un changement de sources et de contrat de sécurité, pas une astuce de configuration non documentée.
Utilisez droits des sources et services internes pour identifier appelant et frontière de confiance avant proposition.
Rapporter les éléments à leur juste niveau
Les tests unitaires ciblés établissent les cas exécutés. Les fixtures natives établissent le comportement des outils et données exacts utilisés. Les parcours navigateur établissent le workflow observé. Sorties réseau des images, hooks hôtes et acceptation des plateformes exigent leurs propres observations. Aucun ne doit être rebaptisé qualification complète de version.
Le dépôt contient des tests ciblés pour propriété des jobs, événements, admission des artefacts et contrôles d’analyseurs gérés par les sources. Leur existence oriente les contributeurs ; elle ne prétend pas qu’ils ont été exécutés pour un nouveau changement.
Suivez contribution, vérifications de développement et limites de version. Notez sources et entrées testées exactes, résultat observé et écarts restants.