papuagigi/disassembly-planner-research

Procedimento de Liberação de Longo Horizonte Físico

Propósito

Orientar a ordenação de candidatos durante múltiplas remoções usando feedback físico confiável. As medidas observadas suportam dois padrões práticos: tentar outra direção disponível após uma colisão de caminho, e quando um bloqueador relatado tem ele mesmo uma extração aceita, reavaliar o alvo bloqueado no estado alterado. Esses padrões orientam consultas; eles não garantem a conclusão da tarefa. Toda remoção aceita requer validação física.

Gatilhos observados

Aplicar quando um candidato removível atual recebe um resultado confiável de path_collision. Registrar seus bloqueadores relatados e estado exato. As evidências mostram tanto direções alternativas no mesmo estado aceitas (L01, L02, L04, L05) quanto remoção aceita de um bloqueador relatado seguida por uma remoção aceita posterior do alvo previamente bloqueado (L01: 10 bloqueado por 11, 11 removido, então 10 removido; L04: 5 bloqueado por 9, 9 removido, então 5 removido). L04 também mostra um alvo com várias direções rejeitadas sendo aceito em outra direção disponível.

Esta é uma evidência de ordenação de longo horizonte, não uma estratégia universal. L05 esgotou seu orçamento de verificação sem atingir o objetivo, apesar de remoções aceitas e tentativas repetidas de direção.

Ações numeradas do planejador

1. Estabelecer o estado atual. Listar apenas candidatos atualmente removíveis e suas ações disponíveis. Manter um registro de estado exato de resultados de consultas anteriores.
2. Ao colidir, registrar a observação. Armazenar identidade do estado, alvo, direção, bloqueadores, resultado e status de confirmação. Uma consulta de remoção com falha não confirma nem altera o estado físico; ela sozinha não requer restauração de ponto de verificação.
3. Tentar direções disponíveis para o mesmo alvo. Ordená-las usando geometria disponível e vetores mundiais, se fornecidos. Rótulos de direção isoladamente não estabelecem orientação mundial. Consultar cada candidato escolhido com o validador confiável. Uma colisão para uma direção não proíbe o alvo em outras direções.
4. Usar bloqueadores nomeados como pistas de ordenação. Se o alvo permanecer bloqueado, considerar bloqueadores atualmente removíveis nomeados pelo validador. Isso apenas prioriza um teste; não prova uma relação de suporte nem que remover o bloqueador limpará o caminho.
5. Validar toda remoção. Confirmar apenas quando o validador confiável aceitar a remoção proposta. Após a confirmação, usar o estado físico resultante e atualizar a disponibilidade de candidatos, bloqueadores e direções.
6. Reconsiderar alvos adiados após mudanças relevantes. Quando um bloqueador tiver sido removido ou o estado mudar de outra forma, consultar o alvo adiado novamente se estiver disponível. Rejeições permanecem vinculadas ao seu estado e ação exatos registrados. Registros de estado exato sobrevivem à restauração; não repetir uma falha conhecida inalterada. Um estado diferente requer nova avaliação, não uma suposição de sucesso.
7. Continuar com candidatos restantes e relatar limites. Se as ações testadas falharem, preservar ações não testadas e declarar apenas que nenhuma ação testada foi aceita naquele estado. Não inferir que a montagem é impossível de desmontar.

Feedback físico confiável esperado

Uma consulta de colisão rejeitada identifica um caminho testado e pode nomear bloqueadores; não é uma remoção. Um resultado aceito e confirmado deve confirmar o componente removido e o estado físico alterado. Reavaliar após a remoção do bloqueador pode então produzir uma remoção recém-aceita, como observado em L01 e L04. Essas observações não estabelecem causalidade além da sequência medida nem preveem aceitação futura.

Aplicabilidade em CÓDIGO e Grafos/DFS fixos

• Código gerado B: Usar o procedimento para ordenar suas próprias consultas de candidatos disponíveis e reter feedback de estado exato. Preservar ações não testadas. Não substituir a execução, validação ou rastreamento de estado do hospedeiro.
• Grafo/DFS fixo C: Usar este documento apenas para classificar ações atualmente disponíveis. O DFS fixo controla a travessia e o momento da restauração. O documento não altera esse fluxo de controle nem prescreve restauração. Consultas com falha sozinhas não exigem restauração. Preservar registros de falha de estado exato após a restauração e evitar repetir uma falha conhecida inalterada.

Limitações e status da evidência

L01, L02 e L04 atingiram seus objetivos medidos; L05 não, apesar de muitas remoções aceitas e 40 restaurações. L03 é excluído porque avisos do motor nativo tornaram sua evidência de procedimento físico inutilizável. Estas são observações de desenvolvimento, não validação independente. CADs de avaliação e validação independente foram retidos.

Alternar direções e priorizar bloqueadores nomeados são padrões de ordenação de consulta observados. A explicação de que a remoção de um bloqueador permite o alvo é uma hipótese além da sequência medida. Não inferir suportes ocultos, rotações, mudanças de aperto ou isenções de colisão. Não afirmar retrocesso bem-sucedido como um reparo: embora L05 registre restaurações, a evidência não estabelece retrocesso bem-sucedido. Este procedimento não substitui orientações anteriores de liberação específica de direção ou reparo de falha e não estabelece sucesso universal de desmontagem.