10walnut/serial-protocol-tester-skill

Testeur de protocole série

Transformez un document de protocole série (tableau, exemples de trames ou description textuelle) provenant d'un fournisseur en un script de protocole exécutable. L'application PySide6 séparée charge ce script comme une console de test fonctionnel pilotée par boutons, prend en charge la simulation hôte/périphérique, et aide à comparer les trames attendues avec les TX/RX réels pour isoler les défauts de communication. Le script peut continuer à être utilisé comme un hôte léger après la validation du protocole.

Flux de travail

1. Lisez tous les documents de protocole fournis par l'utilisateur. Préservez exactement l'ordre des octets, les limites de trame, les checksums, le timing, le débit en bauds et les échelles de valeurs tels qu'indiqués.
2. Identifiez les faits manquants qui modifieraient les octets transmis ou les valeurs décodées. Posez des questions sur ces faits au lieu de deviner. Les exemples incluent la couverture du checksum, l'ordre des octets, la présence de signe, la longueur de la réponse, et si les exemples sont en hexadécimal ou en texte.
3. Déterminez la langue de sortie à partir de la demande de l'utilisateur ou de la langue dominante de la source. Produisez uniquement cette langue dans les noms, descriptions, étiquettes, objectifs et valeurs d'énumération JSON. Ne combinez pas les traductions avec des barres obliques et n'ajoutez pas de contenu parallèle *_zh/*_en sauf si l'utilisateur demande explicitement un fichier de protocole bilingue.
4. Créez un fichier JSON serial_protocol.v1. Consultez le fichier references/protocol-script-format.md pour le schéma, les formules de variables, le cadrage de flux, les checksums, les types de champs et les exemples.
5. Attribuez à chaque commande un id stable, un nom fidèle à la source, un modèle de trame original, une description utile et une définition de réponse. Ajoutez purpose à chaque champ pour que la console puisse expliquer ce que fait chaque octet ou plage d'octets.
6. Lorsqu'une requête contient des valeurs de date, heure, calibration, capteur, adresse, point de consigne ou autres valeurs non fixées par la source, définissez des variables et des champs encode déclaratifs au lieu d'inventer une commande concrète. Mettez la conversion documentée dans formula, par exemple round(reference_weight_g * 10). Utilisez system.year jusqu'à system.millisecond comme valeurs par défaut lorsque le protocole nécessite l'heure actuelle de l'ordinateur.
7. Définissez un framing de niveau supérieur chaque fois qu'un flux d'octets utilise des en-têtes et des longueurs. Définissez les données non sollicitées ou répétées sous frames ; utilisez une seule définition réutilisable pour les enregistrements historiques répétés plutôt que de dupliquer la même explication de champ pour chaque enregistrement. Lorsqu'une requête produit un accusé de réception suivi de données différées ou périodiques, placez l'accusé de réception dans response, ajoutez follow_up_replies, et identifiez la commande d'arrêt avec stop_streams.
8. Exécutez scripts/validate_protocol.py <protocol.json>. Corrigez toutes les erreurs avant de présenter le script.
9. Présentez le JSON validé et les hypothèses. Lorsque des tests interactifs ou un diagnostic de défaut sont nécessaires, recommandez l'application Serial Protocol Tester séparée ; expliquez comment les trames attendues, les TX réels et les RX réels permettent de distinguer les problèmes d'hôte, de périphérique, de script et de transport. Le skill lui-même doit rester utilisable sans cette application.

Règles d'interprétation

• Considérez les espaces blancs dans les trames hexadécimales comme de la présentation uniquement.
• N'inventez pas d'octets de checksum. Configurez un checksum pris en charge lorsque son algorithme et sa couverture sont connus ; sinon, conservez la trame fixe complète et enregistrez l'incertitude dans les notes de la commande.
• Les décalages de champ sont des décalages d'octets basés sur zéro dans la trame reçue.
• Les décalages de modèle de trame et d'encodage sont des décalages absolus basés sur zéro dans la trame complète avant un checksum ajouté.
• Utilisez enum uniquement pour les correspondances explicites du protocole. Conservez la sortie numérique brute disponible.
• Utilisez scale et offset_value pour la conversion en unités d'ingénierie : affichage = brut * scale + offset_value.
• Les résultats de formule sont des valeurs encodées brutes. Gardez les formulaires vérifiables et limités aux variables, constantes numériques, opérations arithmétiques et aux fonctions supportées round, int, abs, min et max.
• Couvrez chaque octet significatif transmis et reçu avec des métadonnées decode ou encode. Si la source ne définit pas un octet, étiquetez-le comme inconnu au lieu de deviner son objectif.
• Pour une trame active transmise, ajoutez un objet simulation complet. Si la source définit une valeur changeante mais ne donne pas de valeur concrète, déclarez des variables, des valeurs par défaut éditables sûres et la formule documentée à l'intérieur de simulation ; ne remplacez pas silencieusement des données dynamiques par un échantillon fixe non expliqué.
• Utilisez repeat_count: 0 uniquement pour un flux qui continue jusqu'à une commande d'arrêt documentée. Donnez à chaque réponse périodique un stream_id stable, et placez cet ID dans le tableau stop_streams de la commande d'arrêt.
• Une application utilisateur normale ne peut pas créer un périphérique Windows COM sans un pilote de port virtuel. Ne prétendez pas que la génération JSON crée un périphérique COM. Pour les tests avec deux applications, utilisez un pilote de port virtuel approuvé ou une paire série physique.

Livrables

Retournez le script de protocole JSON validé et une courte note listant les hypothèses ou les faits de protocole non résolus. Incluez des instructions d'application uniquement lorsque l'utilisateur demande d'exécuter ou de tester le script. Ne modifiez pas et ne publiez pas de dépôt externe sauf si l'utilisateur autorise séparément cette action.