BackboneNeo/ai-skills-cad-engineering

Flux de travail d'ingénierie CAO

Traitez les instructions du dépôt et les validateurs appartenant au dépôt comme faisant autorité. Utilisez cette compétence pour rendre le travail systématique ; ne remplacez jamais les exigences spécifiques au projet par des hypothèses génériques.

1. Établir le contrat

1. Lisez chaque AGENTS.md applicable, le guide complet du projet, l'instantané du dessin actif et le problème (Issue) demandé avant d'écrire.
2. Identifiez la ligne de base immuable, le chemin CAO, le SHA-256, le système de coordonnées, le système d'unités, l'inventaire actuel des composants, les corps imprimables attendus et la cible de publication.
3. Arrêtez-vous avant de modifier si les sources de vérité sont en conflit ou si la ligne de base ne peut pas être vérifiée.
4. Séparez le résultat demandé du contexte des problèmes connexes. N'absorbez pas un backlog dans la tâche.
5. Sélectionnez la voie de publication déclarée par le problème, la politique du dépôt ou l'utilisateur : CAO/dessin numérique ou produit physiquement qualifié. Une publication de dessin n'implique pas une qualification du produit.
6. Classez chaque critère d'acceptation comme étant numérique, visuel, physique ou réservé à l'opérateur conformément à ce contrat faisant autorité. Pour une voie de dessin, des termes tels que ajustement, installation, retrait, clip, actionnement, routage ou accès signifient une validation numérique de la géométrie/du chemin, sauf si le contrat exige explicitement un échantillon fabriqué ou un test pratique. Ne promouvez jamais un risque d'ingénierie générique en une porte obligatoire, et ne signalez jamais un critère physique comme réussi sur la seule base de la géométrie.

Lisez baseline-and-source-truth.md lors de la sélection ou de la validation d'une ligne de base. Lisez failure-patterns.md avant de réparer un candidat défaillant existant.

2. Inspecter avant de modifier

1. Ouvrez le document CAO natif existant et inspectez son arbre, ses types d'objets, ses expressions, ses propriétés, ses placements, ses groupes, ses solides, sa visibilité et son état de recalcul.

2. Enregistrez un rapport de ligne de base lisible par machine. Lorsque FreeCAD est disponible, exécutez :

   python scripts/run_inspect_fcstd.py --freecad FreeCADCmd.exe --file <baseline.FCStd> --output <baseline-report.json>

3. Ne reconstruisez pas un document natif existant à partir d'un maillage, STEP, captures d'écran, instantanés ou générateurs bootstrap.

4. N'écrasez pas les placements, couleurs, visibilité, expressions ou modifications manuelles enregistrés par l'utilisateur, sauf si la tâche exige explicitement ces modifications exactes.

5. Travaillez dans un nouveau chemin versionné lorsque les règles du dépôt rendent les versions historiques immuables.

3. Implémenter le plus petit changement d'ingénierie complet

1. Utilisez des sources de composants exactes et épinglées. Conservez ensemble la source modifiable, l'artefact importé exact, la révision de provenance et le SHA-256.
2. Placez les composants externes dans le groupe de sources intégrées du dépôt et dérivez la géométrie de montage du modèle vérifié.
3. Remplacez la géométrie héritée à son amont natif. Ne masquez jamais un trou, une poche, un dégagement ou une fonction de montage obsolète en fusionnant un patch, une plaque, un bouchon, une peau, un remplissage ou une réparation coplanaire dans un corps fini en aval.
4. Si le corps pré-caractéristique natif ou la chaîne de construction modifiable ne peut pas être récupéré, arrêtez-vous avec un blocage. Ne substituez pas une géométrie de réparation additive simplement pour obtenir l'enveloppe finale demandée.
5. Gardez la géométrie de contrôle modifiable et entièrement contrainte lorsque le dépôt exige un contrôle basé sur Sketcher.
6. Connectez chaque caractéristique de contrôle au corps imprimable final via une chaîne de dépendances inspectable ou des opérations booléennes séquentielles. L'existence d'un sketch ou d'un cutter ne prouve pas l'intégration.
7. Supprimez les découpes, dégagements, étiquettes, sources intégrées actives et vestiges en aval obsolètes lors du remplacement d'un composant.
8. Limitez les changements collatéraux. Préservez les placements des composants non concernés, les corps imprimables, les systèmes de coordonnées, l'apparence et la structure du document.

Pour chaque remplacement ou ouverture redimensionnée, lisez et suivez native-feature-replacement.md. Lisez component-integration.md pour le travail sur les composants et parametric-geometry.md pour la modélisation native et les opérations booléennes.

4. Valider en couches

Exécutez la validation après chaque groupe de géométrie significatif, pas seulement à la fin.

1. Recalculez et rejetez les erreurs de document.
2. Enregistrez, fermez, rouvrez, recalculez, enregistrez et rouvrez à nouveau.
3. Confirmez le nombre attendu de corps imprimables, le nombre de solides, les limites, le volume et la topologie.
4. Prouvez que les caractéristiques demandées affectent le corps final prévu.
5. Pour un remplacement, prouvez que le solide local affecté est égal à la caractéristique native non modifiée avec seulement la nouvelle opération prévue appliquée. Rejetez les contours hérités résiduels, les dépendances de réparation additives, les limites coplanaires supplémentaires et les corps de remplissage cachés.
6. Vérifiez les collisions et les contacts requis séparément. Un contact de montage requis n'est pas une collision indésirable.
7. Vérifiez numériquement, le cas échéant, l'ordre d'assemblage, le chemin de retrait, le chemin d'insertion du connecteur, l'axe de la fixation, l'enveloppe de l'outil, l'accès terminal, l'espace de câblage, le rayon de courbure et le dégagement du serre-câble. Étiquetez cette preuve comme géométrique ; ne prétendez pas à un ajustement, une force ou une durabilité physique.
8. Testez la modifiabilité paramétrique sur une copie jetable, puis restaurez le paramètre d'origine.
9. Exportez les artefacts STL et STEP requis et rouvrez chaque exportation indépendamment.
10. Rendez les gros plans avec le composant affiché puis masqué afin que l'ouverture native et la paroi environnante soient examinables.
11. Rendez le FCStd enregistré, pas un modèle parallèle approximatif.
12. Exécutez chaque test appartenant au dépôt exactement comme contrôlé par l'exécuteur.

Générez un rapport candidat avec run_inspect_fcstd.py, puis comparez-le avec la ligne de base en utilisant :

python scripts/compare_fcstd_reports.py --baseline <baseline-report.json> --candidate <candidate-report.json>

Lisez validation-matrix.md pour les preuves requises par chaque porte.

5. Assembler un candidat de publication cohérent

1. Assurez la cohérence mutuelle entre la CAO native, les sources intégrées, les exportations, l'aperçu, la mise en page, le manifeste, l'instantané, la note de version et l'index actif.
2. Recalculez le SHA-256 uniquement après la génération finale de l'artefact. Réexécutez la validation après toute modification de fichier comportant un hachage.
3. Prouvez l'immuabilité de la ligne de base historique avec un diff ou des hachages stockés.
4. Gardez les formats manuels vides lorsque la politique du projet interdit la génération automatique.
5. Ne créez ni n'approuvez un tag ou une publication lorsqu'une porte obligatoire est incomplète.
6. Autorisez une publication de dessin lorsque ses portes numériques requises sont réussies, même si la qualification physique future facultative n'a pas été effectuée. Ne l'étiquetez jamais comme prête pour la production ou physiquement qualifiée.
7. Créez une publication qualifiée produit uniquement à partir d'un commit de dessin exact après que la construction physique requise, la mesure, l'assemblage et la validation par l'ingénieur sont réussis.

Lisez release-lifecycle.md pour sélectionner la voie de publication et la politique de tag. Lisez release-gate.md avant de déclarer l'achèvement.

6. Rapporter honnêtement

• Retournez completed lorsque toutes les portes requises par la tâche pour la voie de publication sélectionnée sont réussies.
• Retournez blocked avec le candidat terminé préservé uniquement lorsqu'une tâche ou une source de dépôt faisant autorité exige explicitement une porte physique ou opérateur incomplète.
• Retournez no_change_needed uniquement après avoir prouvé que l'état demandé existe déjà.
• Enregistrez les tests physiques non demandés (coupon, cycle, vibration, brochage, câblage, etc.) comme des recommandations de suivi, pas comme des blocages. N'inventez pas de critères d'acceptation.
• Listez chaque blocage séparément avec une preuve et une prochaine étape exploitable.
• Distinguez not_run, failed et passed. Ne convertissez jamais l'absence de preuve en succès.
• Ne cachez pas les blocages de publication dans les risques ou le texte de résumé.