CommunityProgramación y desarrollogithub.com

papuagigi/disassembly-planner-research

Un procedimiento portátil y con evidencia limitada para manejar colisiones de extracción específicas de dirección, probando direcciones alternativas disponibles para el mismo objetivo.

¿Qué es disassembly-planner-research?

Este skill proporciona un procedimiento estructurado para que los planificadores de desensamblaje robótico manejen colisiones de extracción dependientes de la dirección. Cuando un validador físico rechaza una ruta de extracción para un objetivo en una dirección específica, el procedimiento evita prohibir permanentemente ese objetivo. En su lugar, instruye al planificador para que retenga el objetivo y pruebe sistemáticamente otras direcciones disponibles, incluida la opuesta, utilizando el mismo validador de confianza. El skill se basa en un análisis de 89 trazas de evidencia física (D01 a D89), que muestran que una colisión en una dirección a menudo coexiste con una dirección alternativa aceptada para el mismo objetivo. El procedimiento está diseñado para dos modos de aplicación: CODE, donde el planificador integra estas reglas directamente en su generación de candidatos e historial, y GRAPH_DFS, donde las reglas se utilizan para priorizar direcciones candidatas dentro de un algoritmo de búsqueda existente. Es importante destacar que el procedimiento no garantiza el éxito, sino que describe un protocolo de prueba basado en observaciones empíricas. Se enfatiza que cada extracción aún requiere validación física y que el procedimiento no es aplicable a otros tipos de fallos, como inestabilidad o bloqueadores genéricos.

Compatible con~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 Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Procedimiento de Espacio Direccional

Propósito

Utilizar la retroalimentación física medida para decidir qué probar después de que una ruta de extracción sea rechazada por colisión. El procedimiento se centra en una opción específica de dirección: retener el objetivo e intentar otras direcciones actualmente disponibles, incluida la dirección opuesta cuando esté disponible. Propone un orden de prueba; no puede predecir la aceptación. Los IDs de evidencia a continuación se refieren a las trazas físicas proporcionadas.

Disparadores

Aplicar cuando el validador físico de confianza informa path_collision para un objetivo y una dirección. Esto es especialmente útil cuando el mismo objetivo tiene otras direcciones disponibles. Las trazas muestran repetidamente una dirección rechazada junto con una dirección diferente para ese objetivo que el validador aceptó (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).

Diagnóstico

Una colisión de ruta se refiere al par objetivo-dirección probado en su estado de ensamblaje actual. No muestra que el objetivo sea inextractable en todas las direcciones: muchas trazas emparejan una colisión en una dirección con una alternativa aceptada para el mismo objetivo (por ejemplo D01, D04, D10, D22). Algunas trazas tienen solo direcciones rechazadas y ninguna consulta aceptada (D08, D17, D19, D24, D26–D27); no infiera una reparación donde no se midió ninguna alternativa aceptada.

Las cadenas de dirección como +x son etiquetas de acción. No definen la orientación mundial. Las trazas proporcionadas asignan las mismas etiquetas a diferentes vectores mundiales en diferentes ensamblajes (D01, D02, D03, D04, D05). Si los vectores mundiales están disponibles, inspecciónelos y la geometría; aun así, utilice la validación física para decidir.

Pasos numerados ejecutables por el planificador

  1. Ante una colisión, registre el estado exacto del ensamblaje, el objetivo, la dirección intentada, los bloqueadores informados y si la acción fue confirmada. Trate una consulta rechazada y no confirmada como ninguna extracción.
  2. Mantenga el objetivo elegible para pruebas posteriores. No convierta la colisión de una sola dirección en una prohibición para todo el objetivo. Las direcciones repetidamente bloqueadas para el mismo objetivo pueden coexistir con una alternativa clara (D01, D04, D10, D22).
  3. Enumere las otras direcciones actualmente disponibles del objetivo. Utilice la geometría disponible y los vectores mundiales para ordenarlas por holgura plausible. Si la dirección opuesta está disponible, inclúyala como candidata; las trazas muestran tanto alternativas de dirección opuesta como alternativas de otros ejes que tienen éxito (D06, D16, D21; D04, D10, D22). Esta es una regla de generación de candidatos, no una afirmación de que la opuesta funcionará.
  4. Consulte una dirección candidata con el validador físico de confianza. No asuma que la inspección geométrica o una aceptación previa sea suficiente. Cada extracción aún necesita validación.
  5. Si es rechazada, registre el resultado con el estado exacto, el objetivo y la dirección, luego pruebe las direcciones disponibles restantes. Mantenga disponibles las opciones desconocidas y no probadas. Si todas las opciones probadas fallan, informe que este estado no tiene ninguna dirección aceptada medida entre las probadas; no afirme que ninguna dirección puede funcionar.
  6. Si es aceptada como una verificación hipotética pero no confirmada, regístrela solo como una dirección prometedora. Si la extracción es confirmada, use el nuevo estado del ensamblaje y reevalúe los candidatos; no transfiera resultados de direcciones anteriores como garantías. D54 incluye una verificación aceptada y estable y una extracción confirmada posterior para la misma acción.
  7. Preserve las alternativas y la memoria de fallos del estado exacto. Un fallo debe reducir la prioridad solo para su estado y dirección registrados. Después de cualquier cambio de estado, reconsidere las direcciones bajo nueva geometría y validación.

Aplicación CODE versus GRAPH_DFS

  • CODE: Incorpore estas reglas en la generación de candidatos e historial del propio planificador. Después de una colisión, retenga el objetivo y enumere sus otras direcciones disponibles. Almacene cada resultado con el estado exacto, objetivo, dirección, bloqueadores y estado de confirmación. Envíe cada extracción elegida al validador de confianza.
  • GRAPH_DFS: Clasifique solo las acciones actualmente disponibles. Después de una colisión, reduzca la prioridad de ese par objetivo-dirección para el estado registrado y eleve otras direcciones disponibles para el mismo objetivo como candidatas. Preserve todas las acciones no probadas y el historial de estado exacto. El anfitrión sigue siendo responsable del recorrido, seguimiento de estado, recuperación y llamadas al validador; la clasificación por sí sola no ejecuta ni valida una extracción.

Retroalimentación de confianza esperada

Una dirección candidata solo se admite cuando el validador físico devuelve un resultado aceptado e informa un remanente estable. Una extracción completada requiere un resultado confirmado y un cambio de estado confirmado. Una respuesta de colisión con bloqueadores explica la ruta probada; no certifica otras rutas. Las trazas incluyen comprobaciones aceptadas y estables para direcciones alternativas (D01, D04, D10, D22) y una extracción aceptada confirmada (D54). Cada extracción aún requiere validación.

No aplicabilidad

No aplique este procedimiento de búsqueda de dirección a fallos que no sean colisiones de ruta. No repara inestabilidad, determina qué bloqueador eliminar ni prescribe una dirección de extracción universal. No infiera orientación física a partir de etiquetas de dirección, convierta una dirección rechazada en una prohibición global, ni trate una comprobación hipotética aceptada como una extracción confirmada.

Limitaciones de la evidencia

La evidencia proporcionada consiste en trazas medidas con muchos fallos de colisión de ruta y algunas comprobaciones de dirección alternativa aceptadas. Varias trazas no tienen consulta aceptada, por lo que las alternativas no están garantizadas. Los datos no proporcionan nuevos casos de evaluación, validación independiente ni evidencia de éxito universal. Estas reglas describen una respuesta comprobable a colisiones específicas de dirección observadas; no establecen por qué una ruta está despejada ni si este procedimiento mejora el éxito general de la tarea. No se prescribe ninguna secuencia de respuesta o reparación de API.

Individual skills in this repo

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

Skills relacionados