papuagigi/planificador-desensamblaje-investigacion

Procedimiento de Despeje Físico de Horizonte Largo

Propósito

Guiar el orden de los candidatos durante muchas eliminaciones utilizando retroalimentación física confiable. Las trazas medidas respaldan dos patrones prácticos: probar otra dirección disponible después de una colisión de trayectoria, y cuando un bloqueador reportado tiene una extracción aceptada, reevaluar el objetivo bloqueado en el estado modificado. Estos patrones guían las consultas; no garantizan la finalización de la tarea. Cada eliminación aceptada requiere validación física.

Disparadores observados

Aplicar cuando un candidato removible actual recibe un resultado confiable de path_collision. Registrar sus bloqueadores reportados y el estado exacto. La evidencia muestra tanto direcciones alternativas en el mismo estado aceptadas (L01, L02, L04, L05) como la eliminación aceptada de un bloqueador seguida de una eliminación aceptada posterior del objetivo previamente bloqueado (L01: 10 bloqueado por 11, 11 eliminado, luego 10 eliminado; L04: 5 bloqueado por 9, 9 eliminado, luego 5 eliminado). L04 también muestra un objetivo con varias direcciones rechazadas aceptado en otra dirección disponible.

Esta es evidencia de ordenamiento de horizonte largo, no una estrategia universal. L05 agotó su presupuesto de verificación sin alcanzar la meta a pesar de eliminaciones aceptadas y repetidos intentos de dirección.

Acciones numeradas del planificador

1. Establecer el estado actual. Listar solo los candidatos actualmente removibles y sus acciones disponibles. Mantener un registro de estado exacto de los resultados de consultas anteriores.
2. En caso de colisión, registrar la observación. Almacenar identidad del estado, objetivo, dirección, bloqueadores, resultado y estado de confirmación. Una consulta de eliminación fallida no confirma ni cambia el estado físico; por sí sola no requiere restauración de punto de control.
3. Probar direcciones disponibles para el mismo objetivo. Ordenarlas usando geometría disponible y vectores del mundo, si se proporcionan. Las etiquetas de dirección por sí solas no establecen la orientación mundial. Consultar cada candidato seleccionado con el validador confiable. Una colisión para una dirección no prohíbe el objetivo en otras direcciones.
4. Usar bloqueadores nombrados como pistas de ordenamiento. Si el objetivo permanece bloqueado, considerar los bloqueadores removibles actuales nombrados por el validador. Esto solo prioriza una prueba; no prueba una relación de soporte ni que eliminar el bloqueador despejará el camino.
5. Validar cada eliminación. Confirmar solo cuando el validador confiable acepte la eliminación propuesta. Después de la confirmación, usar el estado físico resultante y actualizar la disponibilidad de candidatos, bloqueadores y direcciones.
6. Reconsiderar objetivos diferidos después de cambios relevantes. Cuando un bloqueador ha sido eliminado o el estado cambia de otra manera, consultar nuevamente el objetivo diferido si está disponible. Los rechazos permanecen vinculados a su estado y acción exactos registrados. Los registros de estado exacto sobreviven a la restauración; no reintentar un fallo conocido sin cambios. Un estado diferente requiere una evaluación nueva, no una suposición de éxito.
7. Continuar con los candidatos restantes e informar límites. Si las acciones probadas fallan, preservar las acciones no probadas y afirmar solo que ninguna acción probada fue aceptada en ese estado. No inferir que el ensamblaje es imposible de desensamblar.

Retroalimentación física confiable esperada

Una consulta de colisión rechazada identifica una trayectoria probada y puede nombrar bloqueadores; no es una eliminación. Un resultado aceptado y confirmado debe confirmar el componente eliminado y el estado físico cambiado. Reevaluar después de la eliminación de un bloqueador puede entonces producir una eliminación recién aceptada, como se observó en L01 y L04. Estas observaciones no establecen causalidad más allá de la secuencia medida ni predicen aceptación futura.

Aplicabilidad de CODE y Graph/DFS fijo

• Código generado B: Usar el procedimiento para ordenar sus propias consultas de candidatos disponibles y retener retroalimentación de estado exacto. Preservar acciones no probadas. No reemplazar la ejecución, validación o seguimiento de estado del anfitrión.
• Graph/DFS fijo C: Usar este documento solo para clasificar las acciones actualmente disponibles. El DFS fijo controla el recorrido y el momento de la restauración. El documento no cambia ese flujo de control ni prescribe la restauración. Las consultas fallidas por sí solas no requieren restauración. Preservar los registros de fallos de estado exacto a través de la restauración y evitar reintentar un fallo conocido sin cambios.

Limitaciones y estado de la evidencia

L01, L02 y L04 alcanzaron sus metas medidas; L05 no, a pesar de muchas eliminaciones aceptadas y 40 restauraciones. L03 está excluido porque las advertencias del motor nativo hicieron que su evidencia de procedimiento físico no fuera utilizable. Estas son observaciones de desarrollo, no validación independiente. Los CAD de evaluación y validación independiente se omiten.

Alternar direcciones y priorizar bloqueadores nombrados son patrones de orden de consulta observados. La explicación de que la eliminación de un bloqueador permite el objetivo es una hipótesis más allá de la secuencia medida. No inferir soportes ocultos, rotaciones, cambios de agarre o exenciones de colisión. No afirmar la retrocesión exitosa como una reparación: aunque L05 registra restauraciones, la evidencia no establece una retrocesión exitosa. Este procedimiento no reemplaza la orientación previa de despeje específico de dirección o reparación de fallos y no establece el éxito universal del desensamblaje.