BackboneNeo/ai-skills-cad-engineering

CAD-Engineering-Workflow

Behandeln Sie Repository-Anweisungen und Repository-eigene Validatoren als autoritativ. Verwenden Sie diese Fähigkeit, um die Arbeit systematisch zu gestalten; ersetzen Sie niemals projektspezifische Anforderungen durch generische Annahmen.

1. Den Vertrag festlegen

1. Lesen Sie vor dem Schreiben jedes anwendbare AGENTS.md, den vollständigen Projektleitfaden, den aktuellen Zeichnungsschnappschuss und das angeforderte Issue.
2. Identifizieren Sie das unveränderliche Basislinien-Tag, den CAD-Pfad, SHA-256, das Koordinatensystem, das Einheitensystem, die aktuelle Komponenteninventur, die erwarteten druckbaren Körper und das Freigabeziel.
3. Stoppen Sie vor dem Bearbeiten, wenn sich die Wahrheitsquellen widersprechen oder die Basislinie nicht verifiziert werden kann.
4. Trennen Sie das angeforderte Ergebnis vom Kontext des verwandten Issues. Nehmen Sie keinen Rückstand in die Aufgabe auf.
5. Wählen Sie den vom Issue, der Repository-Richtlinie oder dem Benutzer festgelegten Freigabe-Pfad: digitales CAD/Zeichnung oder physisch qualifiziertes Produkt. Eine Zeichnungsfreigabe impliziert keine Produktqualifikation.
6. Klassifizieren Sie jedes Akzeptanzkriterium gemäß diesem autoritativen Vertrag als rechnerisch, visuell, physisch oder nur durch Bediener. Für einen Zeichnungs-Pfad bedeuten Formulierungen wie "passen", "einbauen", "entfernen", "klemmen", "betätigen", "verlegen" oder "zugreifen" eine digitale Geometrie/Pfad-Validierung, es sei denn, der Vertrag erfordert ausdrücklich ein gefertigtes Muster oder einen praktischen Test. Stufen Sie niemals ein generisches technisches Risiko zu einem obligatorischen Gate hoch und melden Sie niemals ein physisches Kriterium als bestanden, das nur auf Geometrie basiert.

Lesen Sie baseline-and-source-truth.md bei der Auswahl oder Validierung einer Basislinie. Lesen Sie failure-patterns.md vor der Reparatur eines fehlgeschlagenen Kandidaten.

2. Vor dem Ändern inspizieren

1. Öffnen Sie das vorhandene native CAD-Dokument und inspizieren Sie dessen Baum, Objekttypen, Ausdrücke, Eigenschaften, Platzierungen, Gruppen, Volumenkörper, Sichtbarkeit und Neuberechnungszustand.

2. Erfassen Sie einen maschinenlesbaren Basislinienbericht. Wenn FreeCAD verfügbar ist, führen Sie aus:

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

3. Bauen Sie ein vorhandenes natives Dokument nicht aus Mesh, STEP, Screenshots, Schnappschüssen oder Bootstrap-Generatoren wieder auf.

4. Überschreiben Sie nicht die vom Benutzer gespeicherten Platzierungen, Farben, Sichtbarkeit, Ausdrücke oder manuellen Bearbeitungen, es sei denn, die Aufgabe erfordert genau diese Änderungen.

5. Arbeiten Sie in einem neuen versionierten Pfad, wenn Repository-Regeln historische Freigaben unveränderlich machen.

3. Die kleinste vollständige technische Änderung implementieren

1. Verwenden Sie exakte, fixierte Komponentenquellen. Bewahren Sie die editierbare Quelle, das genaue importierte Artefakt, die Herkunftsrevision und SHA-256 zusammen auf.
2. Platzieren Sie externe Komponenten in der eingebetteten Quellgruppe des Repositorys und leiten Sie die Montagegeometrie aus dem verifizierten Modell ab.
3. Ersetzen Sie veraltete Geometrie an ihrer nativen vorgelagerten Funktion. Überdecken Sie niemals ein veraltetes Loch, eine Tasche, eine Entlastung oder ein Montagemerkmal durch das Verschmelzen eines Patches, einer Platte, eines Stopfens, einer Haut, eines Füllstoffs oder einer koplanaren Reparatur in einen nachgelagerten fertigen Körper.
4. Wenn der native Vorfunktionskörper oder die editierbare Konstruktionskette nicht wiederhergestellt werden kann, stoppen Sie mit einem Blocker. Ersetzen Sie keine additive Reparaturgeometrie, nur um die angeforderte Endhülle zu erhalten.
5. Halten Sie die steuernde Geometrie editierbar und vollständig bestimmt, wenn das Repository eine Sketcher-basierte Steuerung erfordert.
6. Verbinden Sie jedes Steuermerkmal über eine überprüfbare Abhängigkeit oder sequentielle Boolesche Kette mit dem endgültigen druckbaren Körper. Die Existenz einer Skizze oder eines Fräsers beweist keine Integration.
7. Entfernen Sie beim Ersetzen einer Komponente veraltete komponentenspezifische Schnitte, Entlastungen, Beschriftungen, aktive eingebettete Quellen und nachgelagerte Überreste.
8. Begrenzen Sie Kollateraländerungen. Bewahren Sie Platzierungen nicht verwandter Komponenten, druckbare Körper, Koordinatensysteme, Darstellung und Dokumentstruktur.

Lesen und befolgen Sie für jeden Ersatz oder jede geänderte Öffnung native-feature-replacement.md. Lesen Sie component-integration.md für Komponentenarbeit und parametric-geometry.md für natives Modellieren und Boolesche Operationen.

4. In Schichten validieren

Führen Sie die Validierung nach jeder sinnvollen Geometriegruppe durch, nicht erst am Ende.

1. Neuberechnen und Dokumentfehler ablehnen.
2. Speichern, schließen, erneut öffnen, neuberechnen, speichern und erneut öffnen.
3. Bestätigen Sie die erwartete Anzahl druckbarer Körper, Volumenkörper, Grenzen, Volumen und Topologie.
4. Beweisen Sie, dass die angeforderten Merkmale den beabsichtigten Endkörper beeinflussen.
5. Beweisen Sie bei einem Ersatz, dass der betroffene lokale Volumenkörper der nativen unveränderten Funktion entspricht, auf die nur die neue beabsichtigte Operation angewendet wurde. Lehnen Sie restliche veraltete Konturen, additive Reparaturabhängigkeiten, zusätzliche koplanare Grenzen und versteckte Füllkörper ab.
6. Überprüfen Sie Kollisionen und erforderliche Kontakte separat. Ein erforderlicher Montagekontakt ist keine unerwünschte Kollision.
7. Überprüfen Sie digital die Montagereihenfolge, den Ausbaupfad, den Steckverbinder-Einführpfad, die Befestigungsachse, den Werkzeugraum, den Anschlusszugang, den Verdrahtungsraum, den Biegeradius und die Zugentlastung, soweit zutreffend. Kennzeichnen Sie diesen Nachweis als geometrisch; beanspruchen Sie keine physische Passung, Kraft oder Haltbarkeit.
8. Testen Sie die parametrische Editierbarkeit an einer Einwegkopie, stellen Sie dann den ursprünglichen Parameter wieder her.
9. Exportieren Sie die erforderlichen STL- und STEP-Artefakte und öffnen Sie jeden Export unabhängig erneut.
10. Rendern Sie Nahaufnahmen mit eingeblendeter und ausgeblendeter Komponente, damit die native Öffnung und die umgebende Wand überprüfbar sind.
11. Rendern Sie die gespeicherte FCStd, kein approximatives Parallelmodell.
12. Führen Sie jeden Repository-eigenen Test genau so aus, wie vom Runner gesteuert.

Generieren Sie einen Kandidatenbericht mit run_inspect_fcstd.py und vergleichen Sie ihn dann mit der Basislinie mit:

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

Lesen Sie validation-matrix.md für den von jedem Gate geforderten Nachweis.

5. Einen kohärenten Freigabekandidaten zusammenstellen

1. Halten Sie natives CAD, eingebettete Quellen, Exporte, Vorschau, Layout, Manifest, Schnappschuss, Versionshinweis und aktiven Index gegenseitig konsistent.
2. Berechnen Sie SHA-256 erst nach der endgültigen Artefaktgenerierung neu. Führen Sie die Validierung nach jeder Änderung einer hash-tragenden Datei erneut durch.
3. Beweisen Sie die Unveränderlichkeit der historischen Basislinie mit einem Diff oder gespeicherten Hashes.
4. Halten Sie rein manuelle Formate leer, wenn die Projektrichtlinie die automatische Generierung verbietet.
5. Erstellen oder genehmigen Sie kein Tag oder Release, wenn ein obligatorisches Gate unvollständig ist.
6. Erlauben Sie eine Zeichnungsfreigabe, wenn ihre erforderlichen digitalen Gates bestanden sind, selbst wenn eine optionale zukünftige physische Qualifikation nicht durchgeführt wurde. Kennzeichnen Sie es niemals als produktionsreif oder physisch qualifiziert.
7. Erstellen Sie eine produktqualifizierte Freigabe nur aus einem exakten Zeichnungs-Commit, nachdem der erforderliche physische Bau, die Messung, die Montage und die technische Freigabe bestanden sind.

Lesen Sie release-lifecycle.md, um den Freigabe-Pfad und die Tag-Richtlinie auszuwählen. Lesen Sie release-gate.md, bevor Sie die Fertigstellung erklären.

6. Wahrheitsgemäß berichten

• Geben Sie completed zurück, wenn alle aufgabenrelevanten Gates für den ausgewählten Freigabe-Pfad bestanden sind.
• Geben Sie blocked mit dem erhaltenen abgeschlossenen Kandidaten nur zurück, wenn eine autoritative Aufgaben- oder Repository-Quelle ausdrücklich ein unvollständiges physisches oder Bediener-Gate erfordert.
• Geben Sie no_change_needed nur zurück, nachdem bewiesen wurde, dass der angeforderte Zustand bereits existiert.
• Erfassen Sie nicht angeforderte Coupon-, Zyklus-, Vibrations-, Pinbelegungs-, Verkabelungs- oder andere physische Tests als Empfehlungen für Folgemaßnahmen, nicht als Blocker. Erfinden Sie keine Akzeptanzkriterien.
• Listen Sie jeden Blocker separat mit Nachweis und einem umsetzbaren nächsten Schritt auf.
• Unterscheiden Sie zwischen not_run, failed und passed. Wandeln Sie niemals das Fehlen von Nachweisen in Erfolg um.
• Verstecken Sie keine Freigabe-Blocker in Risiken oder Zusammenfassungstexten.