CommunityCodierung & Entwicklunggithub.com

papugagigi/Richtungsbezogene-Kollisionsplanung

Ein portables, evidenzbasiertes Verfahren zur Behandlung richtungsspezifischer CAD-Extraktionskollisionen durch Testen alternativer verfügbarer Richtungen für dasselbe Ziel.

Was ist Richtungsbezogene-Kollisionsplanung?

Diese Skill definiert ein systematisches Verfahren zur Behandlung von Pfadkollisionen bei der Extraktion in CAD-Baugruppen, wenn der physikalische Validator eine Kollision für ein bestimmtes Ziel und eine bestimmte Richtung meldet. Es ermöglicht dem Planer, nach einer Kollision nicht das gesamte Ziel aufzugeben, sondern andere verfügbare Richtungen (einschließlich der entgegengesetzten) zu testen, basierend auf gemessenen physischen Rückmeldungen. Die Skill ist plattformunabhängig und für Planer wie CODE (eigene Kandidatengenerierung) und GRAPH_DFS (Rangfolge verfügbarer Aktionen) anpassbar. Der Schlüssel liegt darin, eine Kollision als richtungsspezifisch und nicht als Zielweit zu betrachten und jeden Entfernungsversuch weiterhin durch den vertrauenswürdigen physikalischen Validator zu überprüfen.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/papuagigi/disassembly-planner-research/tree/HEAD/disassembly_final_v4/memory/prior/physical-directional-clearance

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Richtungsbezogenes Kollisionsverfahren

Zweck

Verwenden Sie gemessene physikalische Rückmeldungen, um zu entscheiden, was nach einer abgelehnten Extraktionsroute aufgrund einer Kollision getestet werden soll. Das Verfahren konzentriert sich auf eine richtungsspezifische Option: Behalten Sie das Ziel bei und testen Sie andere derzeit verfügbare Richtungen, einschließlich der entgegengesetzten Richtung, falls verfügbar. Es schlägt eine Testreihenfolge vor; es kann die Akzeptanz nicht vorhersagen. Die Evidenz-IDs unten beziehen sich auf die bereitgestellten physikalischen Spuren.

Auslöser

Wenden Sie es an, wenn der vertrauenswürdige physikalische Validator path_collision für ein Ziel und eine Richtung meldet. Dies ist besonders nützlich, wenn dasselbe Ziel andere verfügbare Richtungen hat. Die Spuren zeigen wiederholt eine abgelehnte Richtung zusammen mit einer anderen Richtung für dasselbe Ziel, die der Validator akzeptiert hat (D01–D07, D09–D16, D18, D20–D23, D25, D28–D36, D39, D42–D46, D48, D51–D57, D59–D60, D62, D64–D66, D69–D70, D72, D74–D77, D79–D80, D82–D83, D86–D87, D89).

Diagnose

Eine Pfadkollision betrifft das getestete Ziel-Richtung-Paar in seinem aktuellen Baugruppenzustand. Es zeigt nicht, dass das Ziel in jeder Richtung nicht extrahierbar ist: Viele Spuren paaren eine Kollision in einer Richtung mit einer akzeptierten Alternative für dasselbe Ziel (z. B. D01, D04, D10, D22). Einige Spuren haben nur abgelehnte Richtungen und keine akzeptierte Abfrage (D08, D17, D19, D24, D26–D27); leiten Sie keine Reparatur ab, wo keine akzeptierte Alternative gemessen wurde.

Richtungszeichenfolgen wie +x sind Aktionsbezeichnungen. Sie definieren keine Weltausrichtung. Die bereitgestellten Spuren ordnen dieselben Bezeichnungen verschiedenen Weltvektoren über Baugruppen hinweg zu (D01, D02, D03, D04, D05). Wenn Weltvektoren verfügbar sind, überprüfen Sie diese und die Geometrie; verwenden Sie dennoch die physikalische Validierung zur Entscheidung.

Nummerierte, vom Planer ausführbare Schritte

  1. Bei einer Kollision den genauen Baugruppenzustand, das Ziel, die versuchte Richtung, die gemeldeten Blocker und ob die Aktion ausgeführt wurde, aufzeichnen. Behandeln Sie eine abgelehnte, nicht ausgeführte Abfrage als keine Entfernung.
  2. Das Ziel für spätere Tests behalten. Wandeln Sie eine einzelne Richtungskollision nicht in ein Zielweites Verbot um. Wiederholt blockierte Richtungen für dasselbe Ziel können mit einer klaren Alternative koexistieren (D01, D04, D10, D22).
  3. Listen Sie die anderen derzeit verfügbaren Richtungen des Ziels auf. Verwenden Sie verfügbare Geometrie und Weltvektoren, um sie nach plausibler Durchfahrbarkeit zu ordnen. Wenn die entgegengesetzte Richtung verfügbar ist, schließen Sie sie als Kandidaten ein; Spuren zeigen, dass sowohl entgegengesetzte Richtungsalternativen als auch Alternativen auf anderen Achsen erfolgreich sind (D06, D16, D21; D04, D10, D22). Dies ist eine Kandidatengenerierungsregel, keine Behauptung, dass die entgegengesetzte Richtung funktioniert.
  4. Fragen Sie eine Kandidatenrichtung mit dem vertrauenswürdigen physikalischen Validator ab. Gehen Sie nicht davon aus, dass eine geometrische Inspektion oder eine vorherige Akzeptanz ausreicht. Jede Entfernung benötigt noch eine Validierung.
  5. Bei Ablehnung das Ergebnis für den genauen Zustand, das Ziel und die Richtung aufzeichnen, dann die verbleibenden verfügbaren Richtungen testen. Unbekannte und ungetestete Optionen verfügbar halten. Wenn alle getesteten Optionen fehlschlagen, melden Sie, dass dieser Zustand keine gemessene akzeptierte Richtung unter den getesteten hat; behaupten Sie nicht, dass keine Richtung funktionieren kann.
  6. Wenn als hypothetische Prüfung akzeptiert, aber nicht ausgeführt, nur als vielversprechende Richtung aufzeichnen. Wenn die Entfernung ausgeführt wird, den neuen Baugruppenzustand verwenden und Kandidaten neu bewerten; übertragen Sie keine vorherigen Richtungsergebnisse als Garantien. D54 enthält eine akzeptierte, stabile Prüfung und eine spätere ausgeführte Entfernung für dieselbe Aktion.
  7. Alternativen und Fehlerspeicher für genaue Zustände bewahren. Ein Fehler sollte die Priorität nur für seinen aufgezeichneten Zustand und seine Richtung senken. Nach jeder Zustandsänderung die Richtungen unter neuer Geometrie und Validierung neu bewerten.

CODE- versus GRAPH_DFS-Anwendung

  • CODE: Diese Regeln in die eigene Kandidatengenerierung und den Verlauf des Planers integrieren. Nach einer Kollision das Ziel behalten und seine anderen verfügbaren Richtungen aufzählen. Jedes Ergebnis mit genauen Zustand, Ziel, Richtung, Blockern und Ausführungsstatus speichern. Jede ausgewählte Entfernung dem vertrauenswürdigen Validator vorlegen.
  • GRAPH_DFS: Nur derzeit verfügbare Aktionen einstufen. Nach einer Kollision dieses Ziel-Richtung-Paar für den aufgezeichneten Zustand herabstufen und andere verfügbare Richtungen für dasselbe Ziel als Kandidaten anheben. Alle ungetesteten Aktionen und den Verlauf des genauen Zustands bewahren. Der Host bleibt verantwortlich für Traversierung, Zustandsverfolgung, Wiederherstellung und Validatoraufrufe; die Einstufung allein führt keine Entfernung aus oder validiert sie.

Erwartetes vertrauenswürdiges Feedback

Eine Kandidatenrichtung wird nur unterstützt, wenn der physikalische Validator ein akzeptiertes Ergebnis zurückgibt und einen stabilen Rest meldet. Eine abgeschlossene Entfernung erfordert ein ausgeführtes Ergebnis und eine bestätigte Zustandsänderung. Eine Kollisionsantwort mit Blockern erklärt den getesteten Pfad; sie zertifiziert keine anderen Pfade. Die Spuren enthalten stabile akzeptierte Prüfungen für alternative Richtungen (D01, D04, D10, D22) und eine ausgeführte akzeptierte Entfernung (D54). Jede Entfernung erfordert noch eine Validierung.

Nichtanwendbarkeit

Wenden Sie dieses Richtungssuchverfahren nicht auf andere Fehler als Pfadkollisionen an. Es repariert keine Instabilität, bestimmt nicht, welcher Blocker entfernt werden soll, oder schreibt eine universelle Extraktionsrichtung vor. Leiten Sie keine physikalische Ausrichtung aus Richtungsbezeichnungen ab, machen Sie eine abgelehnte Richtung nicht zu einem globalen Verbot oder behandeln Sie eine akzeptierte hypothetische Prüfung als ausgeführte Entfernung.

Grenzen der Evidenz

Die bereitgestellte Evidenz besteht aus gemessenen Spuren mit vielen Pfadkollisionsfehlern und einigen akzeptierten Prüfungen alternativer Richtungen. Mehrere Spuren haben keine akzeptierte Abfrage, daher sind Alternativen nicht garantiert. Die Daten liefern keine neuen Bewertungsfälle, unabhängige Validierung oder Evidenz für universellen Erfolg. Diese Regeln beschreiben eine testbare Reaktion auf beobachtete richtungsspezifische Kollisionen; sie begründen nicht, warum ein Pfad frei ist oder ob dieses Verfahren den Gesamterfolg der Aufgabe verbessert. Es wird keine Antwortsequenz oder API-Reparatur vorgeschrieben.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Verwandte Skills