[HanielUlises]

A mission that stops at the first failed action throws away everything it learned getting there. survey_mission now asks for a policy again, up to three times (--attempts), and the planner reads the epistemic state as the mission left it: a scan that already happened is not planned for twice.

The executor is not the place for this. It executes the plan it was given and reports which action failed; asking for another plan belongs to whoever owns the mission, which is where it went.

The domain change that goes with it

goto_site stopped consuming at_depot. An action whose at-start effect asserts it has left the depot cannot be dispatched a second time, and a mission that replans after a failure dispatches it a second time. The requirement stays; only its consumption goes.

Worth recording why the requirement stays rather than the whole condition: an empty :condition (and) made the executor's feedback watchdog fire and re-request an action that was already running, so a drive was dispatched twice. With the requirement in place the two-site mission runs each action once, in 16.3 s parallel against 23.8 s serial.

Measured on the fleet

The link-drop experiment cuts the fleet adapter mid-drive, with the bridge's wait set to 30 s:

planning (attempt 1 of 3)
goto_site: 0 of 1 RMF task(s) done after 30s, last underway
(goto_site scout):0 failed: RMF task timed out
the policy failed; replanning from the state the mission reached
planning (attempt 2 of 3)
...
mission failed after 3 attempt(s)

The loop does what it says. What it does not buy is recovery, and the reason is on the fleet's side: a restarted fleet_adapter re-initialises its robots at their chargers, so the tasks it accepts afterwards never complete. Measuring recovery needs the link interrupted without killing the adapter.