Fldicoahkiin/lab-report-autopilot

Lab Report Autopilot

Pilote le rapport de l'affectation à la livraison : inspecter les fichiers, choisir l'environnement, exécuter l'expérience, capturer les résultats utiles, remplir le modèle de l'utilisateur et inspecter le DOCX finalisé. Une fois les fichiers requis et les champs personnels disponibles, continuez sans demander à l'utilisateur d'effectuer les étapes de routine.

N'inventez jamais de sortie logicielle, de captures d'écran, de détails utilisateur, de citations ou de valeurs d'environnement. Interrompez uniquement lorsqu'un environnement indisponible, une autorisation manquante ou un champ obligatoire manquant rendrait le rapport inexact.

Configuration

Résoudre le répertoire contenant ce SKILL.md comme SKILL_DIR. Exécutez les scripts fournis par chemin absolu ; le répertoire courant peut être le dossier du rapport de l'utilisateur plutôt que le dossier du skill.

Si aucun espace de travail de rapport n'existe :

python3 "$SKILL_DIR/scripts/init_report.py" work/report-name \
  --kind lab \
  --discipline packet-analysis \
  --title "ARP 协议抓包与字段分析"

Utilisez --kind practice pour une pratique professionnelle. Un DOCX fourni reste le modèle du rapport ; ne le remplacez pas par le brouillon Markdown générique.

Le vérificateur d'images nécessite Pillow :

python3 -m pip install -r "$SKILL_DIR/requirements.txt"

Lire le matériel

Classez chaque entrée avant d'écrire :

• Modèle: contrôle les sections, les champs, la mise en page et le style visuel.
• Bonne référence: montre une longueur d'étape, un libellé ou un placement de capture d'écran utile.
• Contre-exemple: montre les problèmes à éviter.
• Matériel de tâche: fournit les données, le code, la topologie et le résultat attendu requis.
• Matériel privé: suit les instructions de traitement de l'utilisateur et ne fournit que des faits autorisés. Lisez user-data-and-privacy.md.

Apprenez le modèle, pas l'identité ou les résultats d'une autre personne. Ne copiez pas les noms, captures d'écran, adresses, dossiers privés ou déclarations à la première personne.

Lisez disciplines.md, puis chargez le fichier de discipline correspondant. Chargez un second fichier uniquement lorsque l'affectation traverse réellement des sujets.

Décider ce qui doit être livré

Enregistrez :

• sections requises et consignes de notation ;
• champs fournis par l'utilisateur ;
• logiciel, système d'exploitation, données, topologie et sortie attendue ;
• le résultat visible nécessaire pour chaque affirmation soumise ;
• règles de longueur, date, nom de fichier et format de fichier.

Remplissez les noms, numéros d'étudiant, classes, enseignants, organisation, rôles, dates et autres champs uniquement à partir des valeurs que l'utilisateur fournit ou confirme. Utilisez la même valeur partout où elle apparaît. Demandez une fois les champs manquants que le modèle exige. Laissez les champs de signature, de note et d'approbation vides sauf si l'utilisateur les fournit explicitement. Ne réutilisez pas un modèle de nom de fichier provenant d'un rapport non lié.

Avant d'éditer Word, lisez docx-qa.md et mesurez le modèle fourni : format de papier, marges, tableaux, polices, tailles, interlignes, retraits, largeurs d'image, légendes, en-têtes, pieds de page et numérotation des pages. Ces valeurs mesurées contrôlent la sortie.

Choisir l'environnement

Lisez environment-playbook.md, puis inspectez la machine actuelle :

python3 "$SKILL_DIR/scripts/probe_environment.py" --json

Ne présumez pas de l'ordinateur de l'auteur ou du produit de virtualisation. Suivez le système d'exploitation et le logiciel nommés par l'affectation. Pour les travaux pratiques universitaires chinois courants, traitez Windows comme la route principale pour Office, PowerShell, SQL Server, eNSP, les simulateurs de fournisseurs et les logiciels pédagogiques Windows uniquement. Utilisez Linux ou Kali pour les outils de réseau et de sécurité Linux. Utilisez macOS nativement uniquement lorsque le logiciel nommé et les captures d'écran requises restent équivalents ; sinon, utilisez toute VM Windows ou Linux disponible, conteneur, WSL ou laboratoire distant autorisé.

Conservez les corrections d'autorisations et les tentatives échouées dans les notes de travail, sauf si elles modifient le résultat soumis. Le travail de sécurité doit rester dans des laboratoires locaux, des systèmes de cours, des cibles délibérément vulnérables ou d'autres systèmes autorisés.

Exécuter et capturer

Lisez evidence-and-screenshots.md et le fichier de discipline sélectionné.

1. Construisez la plus petite configuration qui satisfait la tâche.
2. Exécutez chaque commande et chemin de code qui apparaîtra dans le rapport.
3. Après une action GUI significative, inspectez l'état frais de l'application.
4. Enregistrez les entrées exactes, les noms de fichiers, les versions, les adresses, les numéros de trame et les valeurs observées.
5. Capturez l'écran qui montre le résultat ; ne capturez pas chaque clic.
6. Conservez les captures d'écran originales, les fichiers de paquets, les données et le code source inchangés.

Les diagrammes générés peuvent expliquer un concept mais ne peuvent pas remplacer un résultat logiciel réel. Les captures d'écran utilisées dans un même rapport doivent concorder sur les noms de fichiers, adresses, ports, valeurs et environnement.

Vérifiez le dossier d'images avant de rédiger :

python3 "$SKILL_DIR/scripts/evidence_manifest.py" path/to/evidence \
  --output evidence-manifest.json

Corrigez les fichiers corrompus, les doublons accidentels, les captures illisibles, les données privées exposées et les écrans de résultats manquants.

Écrire à partir du résultat observé

Lisez writing-and-code.md.

Pour chaque étape pratique, énoncez l'opération, la valeur ou le comportement observé, la capture d'écran à proximité, et une brève explication uniquement si elle est utile. Gardez la théorie et les résumés proportionnels aux exemples et à l'affectation.

Pour une pratique professionnelle, rédigez-le comme un travail assigné : ce qui a été reçu, ce qui a été vérifié ou opéré, comment le jugement a été rendu, et quel résultat a été enregistré. N'ajoutez pas de notes de présentation sur le nombre de captures d'écran, la structure du rapport, les artefacts conservés, ou ce que le rapport choisit de ne pas introduire. N'ajoutez pas de page d'accueil d'entreprise simplement pour remplir une ligne de source.

Pour le code, implémentez uniquement le comportement demandé. N'ajoutez pas d'abstractions inutilisées, d'options spéculatives, de vérifications de cas impossibles, ou de commentaires qui reformulent un code simple.

Construire et vérifier le DOCX

Utilisez les outils de document de l'agent hôte lorsqu'ils sont disponibles ; sinon, utilisez un outillage DOCX compatible et un moteur de rendu réel. Remplissez le modèle fourni en place. Supprimez le texte d'exemple uniquement là où le contenu du rapport le remplace.

Rendez le dernier DOCX et inspectez chaque page à 100% :

• les captures d'écran et les légendes sont lisibles et alignées ;
• le texte, les tableaux et les images ne se coupent pas ou ne se chevauchent pas ;
• les glyphes chinois et latins s'affichent correctement ;
• les titres, la numérotation, l'espacement, les retraits, les marges, les en-têtes et les pieds de page correspondent au modèle ;
• les noms, dates, commandes, adresses, numéros de trame, figures et conclusions concordent ;
• aucune page blanche supplémentaire ou page de report presque vide ne subsiste ;
• le nom de fichier suit la règle de cette affectation ;
• aucun identifiant, donnée de lieu de travail privée ou information personnelle non liée ne reste.

Répétez le rendu après chaque changement de mise en page. Livrez uniquement les fichiers demandés, sauf si l'utilisateur demande le matériel de travail.