Procédure de dégagement directionnel
Objectif
Utiliser un retour physique mesuré pour décider quoi tester après qu'un chemin d'extraction ait été rejeté pour collision. La procédure se concentre sur une option spécifique à la direction : conserver la cible et essayer d'autres directions actuellement disponibles, y compris la direction opposée lorsqu'elle est disponible. Elle propose un ordre de test ; elle ne peut pas prédire l'acceptation. Les identifiants de preuve ci-dessous se réfèrent aux traces physiques fournies.
Déclencheurs
Appliquer lorsque le validateur physique de confiance rapporte path_collision pour une cible et une direction. Ceci est particulièrement utile lorsque la même cible a d'autres directions disponibles. Les traces montrent à plusieurs reprises une direction rejetée associée à une direction différente pour cette cible que le validateur a acceptée (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).
Diagnostic
Une collision de chemin concerne la paire cible-direction testée dans son état d'assemblage actuel. Cela ne montre pas que la cible est inextractible dans toutes les directions : de nombreuses traces associent une collision dans une direction à une alternative acceptée pour la même cible (par exemple D01, D04, D10, D22). Certaines traces n'ont que des directions rejetées et aucune requête acceptée (D08, D17, D19, D24, D26–D27) ; n'inférez pas une réparation là où aucune alternative acceptée n'a été mesurée.
Les chaînes de direction telles que +x sont des étiquettes d'action. Elles ne définissent pas l'orientation dans le monde. Les traces fournies mappent les mêmes étiquettes à différents vecteurs mondiaux à travers les assemblages (D01, D02, D03, D04, D05). Si les vecteurs mondiaux sont disponibles, inspectez-les ainsi que la géométrie ; utilisez toujours la validation physique pour décider.
Étapes numérotées exécutables par le planificateur
- En cas de collision, enregistrez l'état exact de l'assemblage, la cible, la direction tentée, les bloqueurs rapportés, et si l'action a été validée. Traitez une requête rejetée et non validée comme aucune suppression.
- Gardez la cible éligible pour des tests ultérieurs. Ne convertissez pas une collision de direction unique en une interdiction à l'échelle de la cible. Des directions bloquées à plusieurs reprises pour la même cible peuvent coexister avec une alternative claire (D01, D04, D10, D22).
- Listez les autres directions actuellement disponibles pour la cible. Utilisez la géométrie disponible et les vecteurs mondiaux pour les ordonner par dégagement plausible. Si la direction opposée est disponible, incluez-la comme candidat ; les traces montrent que les deux alternatives de direction opposée et les alternatives d'autres axes réussissent (D06, D16, D21 ; D04, D10, D22). C'est une règle de génération de candidats, pas une affirmation que l'opposé fonctionnera.
- Interrogez une direction candidate avec le validateur physique de confiance. Ne supposez pas qu'une inspection géométrique ou une acceptation précédente est suffisante. Chaque suppression a toujours besoin d'une validation.
- Si rejeté, enregistrez le résultat par rapport à l'état exact, la cible et la direction, puis testez les directions disponibles restantes. Gardez les options inconnues et non testées disponibles. Si toutes les options testées échouent, signalez que cet état n'a pas de direction acceptée mesurée parmi celles testées ; ne prétendez pas qu'aucune direction ne peut fonctionner.
- Si accepté comme un contrôle hypothétique mais non validé, enregistrez-le uniquement comme une direction prometteuse. Si la suppression est validée, utilisez le nouvel état d'assemblage et réévaluez les candidats ; ne transférez pas les résultats de direction précédents comme garanties. D54 inclut un contrôle accepté stable et une suppression validée ultérieure pour la même action.
- Préservez les alternatives et la mémoire des échecs d'état exact. Un échec ne devrait réduire la priorité que pour son état et sa direction enregistrés. Après tout changement d'état, reconsidérez les directions sous une nouvelle géométrie et validation.
Application CODE ou GRAPH_DFS
- CODE : Incorporez ces règles dans la génération de candidats et l'historique propres au planificateur. Après une collision, conservez la cible et énumérez ses autres directions disponibles. Stockez chaque résultat avec l'état exact, la cible, la direction, les bloqueurs et le statut de validation. Soumettez chaque suppression choisie au validateur de confiance.
- GRAPH_DFS : Classez uniquement les actions actuellement disponibles. Après une collision, abaissez cette paire cible-direction pour l'état enregistré et augmentez les autres directions disponibles pour la même cible comme candidats. Préservez toutes les actions non testées et l'historique d'état exact. L'hôte reste responsable du parcours, du suivi d'état, de la récupération et des appels au validateur ; le classement seul n'exécute ni ne valide une suppression.
Retour de confiance attendu
Une direction candidate est soutenue uniquement lorsque le validateur physique renvoie un résultat accepté et rapporte un reste stable. Une suppression complète nécessite un résultat validé et un changement d'état confirmé. Une réponse de collision avec bloqueurs explique le chemin testé ; elle ne certifie pas d'autres chemins. Les traces incluent des contrôles acceptés stables pour des directions alternatives (D01, D04, D10, D22) et une suppression acceptée validée (D54). Chaque suppression a toujours besoin d'une validation.
Non-applicabilité
N'appliquez pas cette procédure de recherche directionnelle à des échecs autres que la collision de chemin. Elle ne répare pas l'instabilité, ne détermine pas quel bloqueur supprimer, ni ne prescrit une direction d'extraction universelle. N'inférez pas l'orientation physique à partir des étiquettes de direction, ne transformez pas une direction rejetée en une interdiction globale, et ne traitez pas un contrôle hypothétique accepté comme une suppression validée.
Limitations des preuves
Les preuves fournies consistent en des traces mesurées avec de nombreux échecs de collision de chemin et quelques vérifications de direction alternative acceptée. Plusieurs traces n'ont aucune requête acceptée, donc les alternatives ne sont pas garanties. Les données ne fournissent pas de nouveaux cas d'évaluation, de validation indépendante ou de preuve de succès universel. Ces règles décrivent une réponse testable aux collisions observées spécifiques à une direction ; elles n'établissent pas pourquoi un chemin est dégagé ni si cette procédure améliore le succès global de la tâche. Aucune séquence de réponse ou réparation d'API n'est prescrite.