Un besoin nouveau.
Une extension traçable du catalogue.
Votre projet ne correspond pas encore à une recette publiée, ou une opération manque à un module. Le processus conserve le diagnostic et distingue correction de configuration et développement de capacité.
Nx désigne le niveau concerné
Nx n’est pas un cinquième niveau ni un module universel. Il désigne la capacité N0, N1, N2 ou N3 dont la responsabilité doit couvrir le besoin.
- N0 : une architecture ou une opération de volume absente.
- N1 : un runtime, une option ou un mode d’exécution non pris en charge.
- N2 : un service, un binding ou une opération de données manquante.
- N3 : une application, une version ou une fonction métier sans recette compatible.
Le premier choix consiste à réutiliser les modules existants, puis à paramétrer ou adapter leur contrat. Une nouvelle capacité est créée lorsqu’une responsabilité réellement absente le justifie.
Du diagnostic à une capacité utilisable
- Identifier le commit et le refus. Une source inconnue ou une configuration refusée crée un suivi durable. Le client voit la cause ; l’absence de runtime n’est pas présentée comme une livraison réussie.
- Analyser le besoin. Le modèle privé peut aider au diagnostic à partir de métadonnées filtrées. Une demande
capability_requiredreste bloquée et visible tant que la capacité manque. - Choisir le bon niveau. L’intervenant autorisé cherche ce qui est réutilisable, paramétrable ou adaptable avant de définir une nouvelle responsabilité.
- Développer et tester. Contrat, dépendances, opérations, recette et exécution réelle sont mis en cohérence. Les tests couvrent la nouvelle fonction et les consommateurs existants concernés.
- Publier la capacité. Le produit doit reconnaître la source et exécuter la recette. Ajouter une fiche JSON, un nom au catalogue ou un skill ne suffit pas.
- Reprendre le même incident. Si le commit client est toujours courant, la configuration repasse par sa branche, la CI, la PR et la livraison. Une preuve métier confirme le résultat.
Le modèle privé ne développe ni ne publie seul le code manquant. Il n’a pas d’outil d’exécution ni de droit d’écriture direct sur votre dépôt. La réparation automatisée peut proposer uniquement une modification de paas.toml.
Une reprise conserve l’historique et les limites
Les tentatives, refus et compteurs appartiennent au même incident. Le budget automatique de découverte et de réparation est fixé à trois appels privés ; la publication de la capacité conserve ce compteur et permet la reprise de la demande originale sans imposer un nouveau push client.
Si le budget ou les générations automatiques sont épuisés, un intervenant autorisé peut soumettre une configuration revue. La plateforme vérifie les droits, le projet, l’état bloqué et le commit courant. La correction garde la racine de l’incident et les refus, puis repasse par la branche, la CI, la PR et la livraison. Une correction de plateforme conserve également sa preuve avant la reprise.
Un push de maintenance pendant une installation inachevée conserve désormais son incident et le budget consommé. La reprise vérifie le HEAD client : un push concurrent qui rend l’ancien commit obsolète empêche d’intégrer une correction devenue incompatible. Une construction ou une période d’observation encore active reste une attente.
Ces limites de processus ne remplacent pas les totaux observés. Immich garde un écart historique de quatre appels au total de trois annoncé. Les campagnes avec plusieurs lignées, comme Drupal et PrestaShop (six appels chacune), et les sources successives de Discourse (sept appels), restent documentées. Un upgrade compatible à zéro appel ne remet aucun de ces totaux à zéro.
Un contrôle métier refusé après l’état technique « ready » peut aussi rouvrir le traitement sur le commit servi, avec sa preuve privée. Un premier écran visible ne suffit pas à livrer un éditeur, une session durable ou un envoi de message.
Si un préalable ne peut pas être résolu, le statut conserve la cause du blocage. Le catalogue ne présente alors aucune opération non prouvée comme réussie.
FreshRSS : du cas inconnu au prochain push compatible
FreshRSS 1.30.0 a rencontré une découverte imprécise puis deux configurations incomplètes refusées. Les trois appels privés et leurs échecs sont restés dans le suivi.
Le travail autorisé a ajouté les paramètres nécessaires aux capacités PHP, worker et composition : SQLite embarqué, bibliothèques du dépôt, répertoire public et actualisation périodique. Une configuration revue est passée par les contrôles, la CI et la PR, puis la création et l’usage métier ont été vérifiés.
Un push suivant de code client compatible a conservé les comptes, abonnements, catégories et états de lecture, sans appel de modèle. Il portait toujours sur la version amont 1.30.0 : cette preuve ne qualifie pas un changement de version amont.
Plausible : créer seulement les responsabilités manquantes
La recette Plausible réutilise Node, PostgreSQL, la composition, la persistance et les ressources N0. Le runtime Elixir et le service analytique ClickHouse ont chacun une responsabilité réutilisable distincte : ils deviennent N1-ELIXIR et N2-CLICKHOUSE, avec leurs contrats, opérations et tests.
La création assistée et l’upgrade compatible vérifient le compte, le site, les mesures conservées, puis une nouvelle visite et conversion. Les exports PostgreSQL et ClickHouse restent séparés ; leur restauration et une migration amont ne sont pas qualifiées par ce scénario.
Lire la composition et ses limites →Préparer votre cas particulier
Indiquez l’application et sa version, le résultat attendu, les modules déjà utilisés, l’opération en échec et les données à préserver. Conservez le diagnostic et le commit concerné dans le suivi de votre projet. Ne transmettez aucun secret dans une demande publique.
Une extension commence par définir son périmètre et sa preuve attendue. Sa présence dans une demande ou une feuille de route n’établit ni délai, ni livraison, ni compatibilité universelle.