papuagigi/planejamento-de-extração-por-direção

Procedimento de Folga Direcional

Propósito

Usar feedback físico medido para decidir o que testar após um caminho de extração ser rejeitado por colisão. O procedimento foca em uma opção específica de direção: manter o alvo e tentar outras direções atualmente disponíveis, incluindo a direção oposta quando disponível. Ele propõe uma ordem de teste; não pode prever aceitação. Os IDs de evidência abaixo referem-se aos rastreamentos físicos fornecidos.

Gatilhos

Aplicar quando o validador físico confiável relatar path_collision para um alvo e uma direção. Isso é especialmente útil quando o mesmo alvo tem outras direções disponíveis. Os rastreamentos mostram repetidamente uma direção rejeitada junto com uma direção diferente para aquele alvo que o validador aceitou (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

Uma colisão de caminho diz respeito ao par alvo-direção testado em seu estado de montagem atual. Isso não mostra que o alvo é inextrível em todas as direções: muitos rastreamentos emparelham uma colisão em uma direção com uma alternativa aceita para o mesmo alvo (por exemplo, D01, D04, D10, D22). Alguns rastreamentos têm apenas direções rejeitadas e nenhuma consulta aceita (D08, D17, D19, D24, D26–D27); não inferir um reparo onde nenhuma alternativa aceita foi medida.

Strings de direção como +x são rótulos de ação. Eles não definem orientação mundial. Os rastreamentos fornecidos mapeiam os mesmos rótulos para vetores mundiais diferentes entre montagens (D01, D02, D03, D04, D05). Se vetores mundiais estiverem disponíveis, inspecione-os e a geometria; ainda assim, use validação física para decidir.

Etapas numeradas executáveis pelo planejador

1. Após uma colisão, registre o estado exato da montagem, alvo, direção tentada, bloqueadores relatados e se a ação foi confirmada. Trate uma consulta rejeitada e não confirmada como nenhuma remoção.
2. Mantenha o alvo elegível para teste posterior. Não converta a colisão de uma única direção em uma proibição em todo o alvo. Direções repetidamente bloqueadas para o mesmo alvo podem coexistir com uma alternativa clara (D01, D04, D10, D22).
3. Liste as outras direções atualmente disponíveis do alvo. Use a geometria disponível e vetores mundiais para ordená-las por folga plausível. Se a direção oposta estiver disponível, inclua-a como candidata; os rastreamentos mostram tanto alternativas de direção oposta quanto alternativas de outros eixos sendo bem-sucedidas (D06, D16, D21; D04, D10, D22). Esta é uma regra de geração de candidatos, não uma afirmação de que a oposta funcionará.
4. Consulte uma direção candidata com o validador físico confiável. Não presuma que uma inspeção geométrica ou uma aceitação anterior seja suficiente. Toda remoção ainda precisa de validação.
5. Se rejeitada, registre o resultado contra o estado, alvo e direção exatos, então teste as direções disponíveis restantes. Mantenha opções desconhecidas e não testadas disponíveis. Se todas as opções testadas falharem, relate que este estado não tem direção aceita medida entre as testadas; não afirme que nenhuma direção pode funcionar.
6. Se aceita como uma verificação hipotética, mas não confirmada, registre-a apenas como uma direção promissora. Se a remoção for confirmada, use o novo estado de montagem e reavalie os candidatos; não transfira resultados de direção anteriores como garantias. D54 inclui uma verificação estável aceita e uma remoção confirmada posterior para a mesma ação.
7. Preserve alternativas e a memória de falha de estado exato. Uma falha deve reduzir a prioridade apenas para seu estado e direção registrados. Após qualquer mudança de estado, reconsidere direções sob nova geometria e validação.

Aplicação CODE versus GRAPH_DFS

• CODE: Incorpore estas regras na geração de candidatos e no histórico do próprio planejador. Após uma colisão, retenha o alvo e enumere suas outras direções disponíveis. Armazene cada resultado com estado exato, alvo, direção, bloqueadores e status de confirmação. Submeta cada remoção escolhida ao validador confiável.
• GRAPH_DFS: Classifique apenas as ações atualmente disponíveis. Após uma colisão, diminua a classificação daquele par alvo-direção para o estado registrado e aumente outras direções disponíveis para o mesmo alvo como candidatas. Preserve todas as ações não testadas e o histórico de estado exato. O anfitrião permanece responsável pela travessia, rastreamento de estado, recuperação e chamadas do validador; a classificação sozinha não executa ou valida uma remoção.

Feedback confiável esperado

Uma direção candidata é suportada apenas quando o validador físico retorna um resultado aceito e relata um restante estável. Uma remoção concluída requer um resultado confirmado e uma mudança de estado confirmada. Uma resposta de colisão com bloqueadores explica o caminho testado; não certifica outros caminhos. Os rastreamentos incluem verificações estáveis aceitas para direções alternativas (D01, D04, D10, D22) e uma remoção aceita confirmada (D54). Toda remoção ainda requer validação.

Não aplicabilidade

Não aplique este procedimento de busca de direção a falhas que não sejam colisão de caminho. Ele não repara instabilidade, determina qual bloqueador remover ou prescreve uma direção de extração universal. Não infira orientação física a partir de rótulos de direção, transforme uma direção rejeitada em uma proibição global ou trate uma verificação hipotética aceita como uma remoção confirmada.

Limitações das evidências

As evidências fornecidas consistem em rastreamentos medidos com muitas falhas de colisão de caminho e algumas verificações de direção alternativa aceitas. Vários rastreamentos não têm consulta aceita, portanto, alternativas não são garantidas. Os dados não fornecem novos casos de avaliação, validação independente ou evidência de sucesso universal. Essas regras descrevem uma resposta testável a colisões específicas de direção observadas; elas não estabelecem por que um caminho está livre ou se este procedimento melhora o sucesso geral da tarefa. Nenhuma sequência de resposta ou reparo de API é prescrita.