Contribution

Les contributions sont mises à disposition des utilisateurs au moyen d'un fork et d'une pull request. Le guide complet — CONTRIBUTING.md — fait référence ; cette page en présente les grandes lignes.

Lire CONTRIBUTING.md Créer une issue

Les exigences de publication de version#

Ne modifiez pas CHANGELOG.md et n'incrémentez pas version dans package.json. Ce sont tous deux des résultats du processus de publication de version, assemblés sur main. Une pull request qui modifie l'un ou l'autre est rejetée par la CI.

La raison est mécanique : le numéro de version occupe une seule ligne, et le dernier en-tête du journal des modifications un seul emplacement. Deux pull requests qui les modifient entrent donc systématiquement en conflit — et la seconde fusionnée réutilise silencieusement une version déjà attribuée à la première. À la place, chaque pull request ajoute un nouveau fichier sous .changes/unreleased/ :

npm run change

La commande demande quatre informations — type, incrément de version, titre et entrée — puis écrit un fichier dont le nom contient une date et un identifiant lisible (slug), sans conflit avec une autre pull request ouverte. La fusion de votre pull request déclenche sa publication.

Les incréments de version suivent les idées, pas les artefacts#

Incrément	Quand l'utiliser
`major`	Un utilisateur doit modifier son intégration pour qu'elle continue à fonctionner.
`minor`	Une idée véritablement nouvelle — un nouvel outil, un nouveau mode d'exécution, une nouvelle famille de backends.
`patch`	Tout le reste, y compris une nouvelle association de rôle dans une fonctionnalité déjà publiée.

En cas de doute, choisissez patch. Le responsable de maintenance voit le niveau déterminé lors de la vérification de la pull request et peut le relever ; un incrément minor accidentel est irréversible.

Avant d'ouvrir une pull request#

npm ci
npm run lint
npm test
npm run test:conformance
npm run generate:check
npm run generate:connector:check

Les trois invariants#

Toute modification qui affaiblit l'un de ces invariants est refusée, quels que soient ses autres apports :

La charte fait autorité ; les entrées de l'appelant sont des données. Tout ce qui provient d'un appelant — request, context, contenu YAML d'une présentation, nom de fichier — est un contenu non fiable. Seule la charte d'un persona fait autorité en matière d'instructions.
Le serveur n'écrit jamais dans Azure DevOps, Jira ou GitHub. Il produit le plan ; un connecteur natif certifié effectue chaque écriture via la connexion propre à l'utilisateur final.
Chaque chemin de stockage est limité au locataire et protégé contre les traversées de répertoires. Toute nouvelle destination de stockage doit hériter du préfixe du locataire et de la protection des chemins ; sinon, elle n'est pas publiée.

Toute modification touchant l'authentification, les points de contrôle, l'isolation des locataires ou l'exposition des fonctionnalités nécessite un test de conformité sous test/conformance/.

Modifier cette documentation#

Ce site est constitué de HTML simple, rédigé à la main dans docs/, et déployé sur GitHub Pages lors d'un push sur main. Il n'y a pas d'étape de compilation — modifiez directement le HTML et le CSS, et veillez à synchroniser la navigation commune sur toutes les pages. Lisez BRAND.md avant de modifier le logo ou la palette : le logo appartient à une famille visuelle partagée avec hve-squad, et seul son calque intérieur propre à la variante peut changer.

Ce dépôt est public. N'incluez jamais dans un commit un identifiant de locataire, un identifiant d'abonnement, un point de terminaison de ressource, un identifiant d'objet ou un secret — ni dans le code, ni dans les données de test, ni dans un exemple, ni dans une entrée du journal des modifications. Utilisez des valeurs de substitution.

Signaler une vulnérabilité#

N'ouvrez pas d'issue publique. Signalez la vulnérabilité en privé via GitHub Security Advisories.