Kit de démarrage reproductible pour l’orientation des demandes

Un petit ensemble de règles à exécuter hors ligne.

Utilisez des demandes fictives pour reproduire l’attribution, les contrôles de détails manquants, la détection des doublons et une réponse relue. Ce kit de démarrage téléchargeable fournit à l’opérateur chargé de la mise en place les règles, les données de test et les contrôles derrière un exemple au périmètre limité.

Licence MIT · données fictives uniquement · testé avec Node.js 22.23.2 le 8 octobre 2026. Lire l’installation complète sans télécharger.

Commencez par les cinq contrôles reproductibles.

Extrayez l’archive dans un nouveau dossier et ouvrez un terminal à l’intérieur. Utilisez une installation de Node.js existante ; la version de test enregistrée est indiquée ci-dessus. Exécutez ces commandes :

node --version
node verify.mjs

Le rapport JSON doit indiquer cinq cas, cinq réussis et zéro échec : demande complète, détails manquants, doublon normalisé, validation répétée et échec/rattrapage. Il contient les entrées synthétiques, les attentes et les états observés. Conservez votre résultat ; ne considérez pas notre exécution conservée comme la preuve du vôtre.

Les contrôles valident volontairement des brouillons fictifs pour mettre les règles à l’épreuve. Pour une répétition manuelle, suivez le README : initialisez un état local, soumettez une donnée de test, examinez la demande et le fichier de réponse, puis validez-le explicitement. Aucune commande ne peut envoyer de message.

Examinez les règles avant de les modifier.

• Les demandes normales vont au coordinateur de service ; les demandes de devis vont à l’équipe Devis ; un mot de priorité envoie la demande au responsable de permanence.
• Une zone vide ou un message de moins de 20 caractères prépare une demande de précisions qui doit tout de même être validée.
• La clé anti-doublon compare l’e-mail, la zone et le message normalisés dans la file locale. Elle ne fusionne pas toutes les demandes d’une même personne.
• Un échec simulé conserve le brouillon. Le rétablissement efface la validation précédente et renvoie la même fiche pour une nouvelle relecture.

Le contrat des champs et le code source lisible sont inclus. Ces règles de mots et de longueur sont des exemples, pas une évaluation complète d’une intervention de plomberie. Vérifiez les fonctions natives de vos vrais outils avant d’ajouter une connexion.

Sachez ce qui est conservé et comment l’arrêter.

La démo publique dans le navigateur garde son état en mémoire. L’utilitaire de ce paquet écrit un fichier local sample-state.json dans votre dossier courant. Sa commande de pause bloque les nouvelles soumissions, validations et rétablissements. La reprise ne rejoue rien. Ces fonctions de fichier et de pause appartiennent au paquet, pas à la démo du navigateur.

Exécutez un seul processus à la fois et utilisez uniquement des données synthétiques. Il n’y a ni verrouillage multi-utilisateur, ni authentification, ni chiffrement, ni planificateur, ni connecteur réel. La file contient au maximum 20 fiches. La réinitialisation supprime l’état local et la mémoire des doublons ; elle ne peut pas annuler une action externe. Supprimez le dossier extrait pour désinstaller.

Les mainteneurs du dépôt Fireflax sont responsables de cet artefact versionné. Aucune affectation individuelle de support continu n’est établie. Avant de l’adapter, désignez votre propre responsable de la maintenance, notez la version et fixez une date de relecture.

Utilisez l’exemple pour clarifier votre passage de relais.

Une connexion réelle a toujours besoin des vrais identifiants de champs, des autorisations de compte, d’identifiants fiables, de contrôles des effets externes et d’une responsabilité de rattrapage acceptée. Le paquet n’établit pas la compatibilité avec votre CRM.