LOGIV: Graph-Verified Execution with Causal Local Repair for Long-Horizon Robot Tasks

*Equal contribution, †Corresponding author

Email: [email protected], [email protected]

GitHub: https://github.com/Enqiao-Lu/LOGIV

Project Page: https://enqiao-lu.github.io/logiv-project/

Introduction

Agentic robots combine goal-directed planning, perception, and physical action in a feedback loop [34]. Vision-Language-Action (VLA) models [27, 21, 32] and World Action Models (WAMs) [43, 2] provide increasingly capable execution policies, while an agent-level controller must decide how their actions contribute to a longer task. A distinctive difficulty in physical execution is that an intermediate result can cease to hold after the action that produced it has succeeded. A support placed during bridge assembly may be displaced before the beam is installed (Figure 1). The placement remains a completed action, yet the support condition needed by the remaining plan is no longer valid. Reliable long-horizon behavior therefore requires tracking both action completion and the continuing validity of its consequences.

Related progress spans structured agent capabilities [41], multi-agent interaction topology [3], and feedback-based visual refinement [44]. LLM- and VLM-based systems select skills, interpret feedback, and organize multistep behavior [28, 18, 12, 6, 30, 46, 16] (Ji et al. 2026). Symbolic and program-based methods make action constraints explicit [42, 22, 5, 7], building on established work in plan monitoring and repair [33, 38]. Graph-based agent frameworks expose subtask dependencies for reuse and repair [45]; in robotics, AgentChord augments task graphs with anticipatory recovery branches before execution (Xu et al., 2026). These advances raise a question: when observations invalidate an earlier condition, which support should the robot restore while preserving a usable unfinished plan?

We approach this question through graph engineering: constructing, checking, and revising an explicit dependency graph as the interface between planning and robot execution.

We present LOGIV (Long-Horizon Online Graph-based Inference and Verification for Plan Repair). Its task graph records which conditions each action supplies to later actions, together with resource-ordering constraints. The key design is to separate a node’s completion status from the current validity of the support it provides. When that support fails, unfinished consumers can remain in the plan while repair reestablishes their prerequisites. The retained continuation then constrains the repair goal. This gives graph structure an operational role in deciding what to check, what to preserve, and what to change.

LOGIV implements this interface as a closed-loop execution and repair layer above an existing VLA or WAM policy. Before execution, it validates a high-level plan and compiles its dependencies into a task graph. During execution, visual observations and robot feedback check the selected action and the support required by pending actions. After a confirmed failure, dependency tracing identifies affected actions; repair synthesizes a continuation constrained by retained operators and expands the replacement scope when validation fails. The combined plan is checked under the symbolic model before the graph is rebuilt and execution resumes. In the bridge example, the robot restores the displaced support while retaining the remaining beam operations. This design adds no trainable components and focuses on online repair from the observed state, with the validity of the repaired continuation checked explicitly. We evaluate LOGIV on 20 simulated dual-arm tasks from RoboTwin V2 and BiCoord using $\pi_{0.5}$, AHA-WAM, and Light-WAM. Without injected perturbations, mean success across the three backbones increases from 71.67% to 82.33% on RoboTwin V2 and from 42.33% to 57.67% on BiCoord. Under predefined perturbations, LOGIV achieves higher task completion and condition restoration than three adapted recovery baselines for every backbone on both benchmarks. On three real-robot tasks, successful trials increase from 12/30 to 17/30. Ablations support the role of graph structure: removing dependency checks reduces perturbed-task success from 60% to 48%, and replacing local repair with replanning all remaining actions increases repeated valid actions from 0.2 to 1.6. These results support graph engineering for the evaluated tasks. Our contributions are:

• A graph engineering formulation of agentic robot execution that separates completed actions from the continuing validity of their condition support during physical task execution.

• A closed-loop implementation combining observation-based graph checks, dependency-guided repair constrained by retained actions, and symbolic validation of the full continuation.

• Evaluation across two simulation benchmarks, three execution backbones, and real robots, with ablations examining how graph verification and repair design affect task success and redundant execution.

Related Work

Long-Horizon Manipulation with VLA and WAM

Recent approaches improve long-horizon manipulation through high-level execution organization or changes to the policy backbone. In the first group, a high-level module selects and sequences subtasks while a low-level policy executes them. HiMe uses hierarchical memory to preserve task context, Cortex aligns planning and execution interfaces, and Harness VLA and RoboHarness use execution memory to organize robot policies [30, 46, 16] (Ji et al. 2026). EMERGE-Policy coordinates specialized agents for perception, monitoring, verification, and memory through a graph-structured framework with a common skill interface [11]. These methods motivate the use of an explicit execution layer around an existing policy. Other approaches improve the representation or use of temporal information within the model. RoboHorizon combines multiview world modeling with mechanisms for long-horizon task organization [6]. Fast-WAM studies whether future generation is needed at test time [43], while AHA-WAM uses asynchronous world and action branches with observation-guided context routing [2]. LOGIV addresses a complementary system-level problem: how to update a high-level plan when an execution error or external disturbance invalidates a condition needed later in the task.

Plan Verification and Recovery

Structured representations can support both plan checking and online recovery. VeriGraph uses scene graphs to verify and refine candidate action sequences [10]. Other graph-based systems maintain scene information or task structure for planning and execution [36, 40, 45]. LERa uses visual feedback to identify failures and revise a plan [29], Reflective Planning reassesses actions using predicted observations [12], and behavior-tree approaches provide reactive execution and recovery mechanisms [1, 8, 19]. Recent language-based systems use visual or multimodal feedback to detect execution failures, explain plan–execution mismatches, or trigger corrective replanning [13, 47, 25, 9, 37, 17]. Symbolic planning provides explicit preconditions and effects that can be checked before execution [42, 22, 5, 7, 24]. Causal-link monitoring and plan repair provide a basis for reasoning about support relations from executed actions to pending actions. LOGIV builds on these ideas rather than treating dependency tracking itself as a new planning principle. It specifically addresses support conditions established by completed subtasks that later become invalid, using visual state assessment to update explicit producer–consumer dependencies before selecting a local repair scope. Retained actions constrain the continuation, and the combined plan is validated before execution resumes. The experiments compare this framework with adapted verification and recovery baselines under a shared evaluation protocol.

Method

LOGIV separates high-level task management from low-level control: it constructs, checks, and repairs plans, while the execution policy carries out individual subtasks. We use bridge assembly as a running example: the robot places supports, grasps a beam, and lays it across them.

Problem Formulation

At round $t$, $O_t$ is the visual observation and $S_t$ is the symbolic state estimated from visual interpretation, robot status, and actuator feedback. Given $S_0$ and goal $g$, the Operator Planner generates a reference plan $P = (o_1, \ldots, o_n)$ of grounded PDDL operators with specified preconditions and effects [26]. VAL checks the plan [15], which is then compiled into a directed acyclic graph $G = (V, E)$.

The nodes in $V$ are subtasks, START, and GOAL. Causal edges record which action supplies another’s required condition; resource edges encode ordering constraints from resource use or modeled interference. Here, causal means PDDL condition support, not a learned model. The reference plan orders the graph and breaks scheduling ties.

The selected operator is passed to the low-level policy as a natural-language instruction with the current visual observation. After execution, LOGIV updates the state and checks the outcome and dependencies. A confirmed execution failure produces an error record $e_t$ and triggers plan repair:

The updated plan combines a repair fragment with retained unfinished operators. Validation from $S_{t+1}$ establishes consistency with the symbolic model and supplied state, without guaranteeing perception accuracy or physical success. Completed actions’ valid effects remain in the current state; the completed prefix is not replayed.

Pre-Execution Planning

Plan generation and validation. The Operator Planner receives a PDDL Domain and Problem (Figure 2). The Domain specifies reusable operators, parameters, preconditions, and effects; the Problem specifies objects, initial state $S_0$, and goal $g$ [26]. LAMA-first [35] in Fast Downward [14] searches for a grounded sequence reaching $g$ from $S_0$. VAL independently checks action bindings, preconditions, modeled effects, and the final goal [15]. On failure, it returns the location and reason. The Domain, objects, $S_0$, and $g$ remain unchanged; the failed sequence is excluded before searching for an alternative grounding or ordering. Graph construction begins only after validation passes.

Task graph construction. Each operator becomes a subtask node. For each precondition of $o_i$, the compiler searches preceding operators in reverse order for the nearest producer without an intervening invalidation in $P$. A causal edge links that producer to $o_i$ and is labeled with the supported condition. Conditions supplied by $S_0$ originate at START; goal conditions link to GOAL by the same rule. Placing a bridge support establishes the support-position condition needed by beam placement.

Resource edges retain ordering for exclusive resources, such as an arm or gripper, and modeled interference. Our PDDL uses typed object parameters with deterministic logical preconditions and effects. Operators interfere when one invalidates a condition required or established by the other. Both edge types follow $P$, making the graph acyclic and $P$ a topological order. Other topological orders need not be valid; execution order is checked online.

Online Verification and Recovery

Task-graph scheduling and online checking. As shown in Figure 3, the system schedules actions using causal dependencies and resource order in $G$. Among unfinished actions whose predecessors are complete, it selects the earliest action in $P$ whose execution conditions hold. If none is ready, it selects the earliest action with completed predecessors, refreshes the state, and checks whether repair is needed. Once all actions are complete, it checks $g$.

Before execution, the VLM extracts facts from $O_t$ about the current action and its dependencies. The State Gate combines them with robot state and actuator feedback to form $S_t$. If evidence is insufficient, the system acquires new images, adjusts the viewpoint, or repeats checks. Facts still unconfirmed within the observation budget yield UNRESOLVED and stop execution. The Node Gate checks preconditions; the Graph Gate checks resource predecessors and condition support. Confirmed unmet preconditions yield FAIL with PRECONDITION_FAILURE. Otherwise, the operator is converted into an instruction for the low-level policy.

After execution, the system updates $S_{t+1}$ from $O_{t+1}$ and robot feedback. The Node Gate checks the expected effects and marks the node complete if they pass. The Graph Gate then checks whether support from START and completed actions still holds for remaining actions and GOAL. Missing effects or invalidated support yield FAIL with EFFECT_FAILURE. Thus, a support displaced while grasping the beam triggers repair even if the grasp succeeds; the completed support-placement node is not reopened. If both checks pass, the system returns PASS. At GOAL, a verified $g$ yields success; a confirmed unmet goal yields FAIL with GOAL_FAILURE. Algorithm 1 in Appendix A gives the execution loop, with these checks summarized as

The checked node is $v$. Record $e_t$ gives the failure type, node, unmet condition, and failed edge; it is empty otherwise. Completion status distinguishes missing action effects from a completed action’s invalidated support.

Repair scope selection. Algorithm 2 in Appendix A distinguishes affected actions from those that must be replaced. After a failure, we identify the unfinished action at which the failure was detected, or the unfinished actions that directly depend on invalidated support, together with their unfinished causal successors. Initially, only a just-executed action whose own effects failed is replaced. An action with a missing precondition is retained, and repair restores that condition before execution. If support from a completed action is later invalidated, the action remains complete and its unfinished consumers are retained. A final-goal failure starts with an empty replacement set. In the beam example, beam placement remains in the plan while repair restores its required support.

Repair planning and validation. Once the replacement scope is fixed, the remaining unfinished actions form the retained plan $P_{\mathrm{keep}}$. The system works backward from the final goal $g$ through these actions to determine what must hold before their execution resumes; this result is denoted by $g_{\mathrm{rep}}$. For actions with conjunctive preconditions and goals and unconditional add/delete effects, conditions are represented as signed literals. The system processes the retained actions in reverse order, starting from $g$. If an action deletes a condition that is still required, the requirement is infeasible; otherwise, the system removes the conditions established by that action and adds its preconditions. Complementary literals also make the requirement infeasible and cause planning to fail immediately. If no actions are retained, the repair fragment must directly achieve $g$. For example, a retained beam-grasp action requires gripper_empty and establishes holding(beam) for placement. The repair therefore needs an empty gripper before the grasp, but need not establish holding(beam) in advance. Starting from $S_{t+1}$, the Operator Planner generates a repair fragment $\Delta P_t$ that achieves $g_{\mathrm{rep}}$, giving $P' = \Delta P_t \oplus P_{\mathrm{keep}}$. The system uses VAL to check whether the complete plan $P'$ reaches $g$. A failure inside the repair fragment triggers replanning within the same scope, while a repeated candidate terminates repair. A failure at a retained action expands the replacement scope to that action and its unfinished causal successors. A planning failure, timeout, or unlocated failure invokes the deterministic fallback in the Notes. After validation succeeds, LOGIV rebuilds the graph from $P'$: repair actions become new nodes, completed actions remain complete, and their still-valid effects are represented by the current state and the new START node. Execution resumes from the earliest ready node in reference order. Repair terminates when no further expansion is possible or the budget is exhausted, without guarantees of minimality or completeness.

Experiments

Experiment Setup

Tasks and perturbations. We evaluate LOGIV on ten tasks from RoboTwin V2 [4] and ten from BiCoord [31]. Both benchmarks support dual-arm manipulation with multistage actions and cross-arm dependencies. Appendix B lists the selected tasks in Table A1. Each task has ten predefined initial states. The clean setting evaluates each state once without an injected disturbance. The perturbed setting reuses the same initial states and introduces one recoverable disturbance at a predefined event. The disturbance type and trigger are fixed within each task and vary across tasks. For example, in move_can_pot, the pot is shifted laterally by 10–15 cm after the can is grasped and lifted.

RoboTwin V2 ([4])
beat_block_hammer	blocks_ranking_size
handover_block	move_can_pot
open_microwave	place_dual_shoes
stack_blocks_three	stack_bowls_three
stamp_seal	turn_switch
BiCoord ([31])
cook	put_objects_cabinet
divide_block_tower	place_plate_and_cup
build_bridge	clean_table
collect_pens	match_blocks_with_signs
jigsaw	exchange_mics

We design three real-world tasks (Figure 4). In pick_tomato, the robot moves a tomato from the table into a bowl, a short task with few conditions. In build_blocks, both arms build a small block structure, where earlier placements establish support conditions for later ones. In insert_cable, the robot plugs an RJ45 connector into a switch port, requiring millimeter-level alignment beyond pick-and-place. No disturbances are injected in these trials.

Backbones and baselines. We use $\pi_{0.5}$ [32], AHA-WAM [2], and Light-WAM (Li et al., 2026) as execution policies. For RoboTwin V2 and BiCoord, each backbone undergoes task-specific fine-tuning on the ten selected tasks in that benchmark. The backbone training or adaptation uses expert demonstrations without the evaluation-time perturbations. LOGIV itself introduces no additional trainable components. For each backbone, we compare LOGIV with the backbone alone and three adapted recovery methods. VeriGraph-PDDL follows the scene-graph verification approach of VeriGraph [10] and replans the remaining task from the current symbolic state when a constraint is violated. LERa-PDDL uses visual feedback to analyze a failure, updates the planning conditions, and replans the remaining task [29]. VLM-RP-BT organizes the initial plan as a behavior tree [8, 19] and inserts recovery actions when a required condition is not satisfied. These names refer to the adaptations evaluated here, rather than to unmodified implementations of the original systems.

Implementation details. The experimental PDDL specification is predefined and held fixed. The VLM configuration uses GPT-4o with a maximum of 512 output tokens per call. Each node receives one pre-execution and one post-execution check. Human assistance is disabled in all reported experiments; potential failures first trigger active perception by the robot. An unresolved assessment allows at most three additional observations. We use LAMA-first in Fast Downward with a 30 s limit per planning call and a 5 s limit per VAL call. Each failure allows at most three local repair rounds and four VLM calls. Exceeding either limit terminates the episode.

For these tasks, we compare the base $\pi_{0.5}$ policy with $\pi_{0.5}$ + LOGIV on two physical dual-arm platforms: an Astribot S1 whole-body dual-arm robot and a workcell built from two AgileX Piper 6-DoF arms with parallel-jaw grippers. Each platform provides a third-person RGB-D camera and a wrist camera per arm. The baseline and LOGIV configurations use the same $\pi_{0.5}$ checkpoint and the same demonstrations. LOGIV adds no trainable components. Each configuration is evaluated over 10 trials per task under a shared protocol with matched initial layouts. A trial counts as successful only when the full instruction is completed.

Evaluation metrics. We report full-task success without injected perturbations (C), full-task success with injected perturbations (P), and condition restoration (R). An event is eligible if execution reaches the injection point, the disturbance invalidates the designated condition, and recovery remains possible with the available action set. Restoration succeeds if the condition is restored within budget and passes the next relevant check. For each method, $R$ is the fraction of eligible events with successful restoration, counting failures in the denominator. Event sets may differ across methods, so $R$ is read alongside $P$. The ablation study additionally reports the fraction of unexecuted nodes deleted, replaced, or replanned during repair, and the number of still-valid completed actions executed again. These measures describe plan changes and redundant execution, respectively.

Detailed Results

We report results from simulation benchmarks and real-world robot experiments.

C: Task success rate without artificial perturbations; P: Task success rate after applying predefined perturbations; R: Recovery success rate for invalidated conditions among valid, recoverable perturbation events. All results are expressed as percentages (%).

Simulation experiments. Table I summarizes the results of LOGIV on both benchmarks. Without artificial perturbations, integrating LOGIV raises mean task success across the three backbones from 71.67% to 82.33% on RoboTwin V2 and from 42.33% to 57.67% on BiCoord. Robots can still encounter state deviations and action failures in these runs. The gains therefore show that LOGIV improves normal task execution as well as recovery from injected disturbances. Under predefined execution-time perturbations, LOGIV also improves task completion. On RoboTwin V2, task success with $\pi_{0.5}$, AHA-WAM, and Light-WAM reaches 60%, 83%, and 72%, respectively, exceeding the corresponding backbone results by 28, 23, and 14 percentage points. On BiCoord, the respective success rates are 48%, 53%, and 49%, with gains of 17, 10, and 10 percentage points. LOGIV achieves higher task success than all three correction baselines in both settings, indicating that its benefits extend across backbones and benchmarks. The perturbed results further show that the framework can help execution continue after an external disturbance. We also evaluate condition restoration separately from full-task completion. LOGIV achieves higher recovery success than the three correction baselines for every combination of benchmark and backbone, showing consistent gains in restoring invalidated conditions within the evaluation budget. These results support the use of dependency checks and plan repair to help execution continue after a failure. To guide repair, LOGIV traces the conditions needed by subsequent actions, extending its assessment beyond the failed action itself. Retained actions constrain the updated plan, limiting changes to still-usable parts of the unfinished task.

Backbone	Method	RoboTwin V2			BiCoord
		C ↑	P ↑	R ↑	C ↑	P ↑	R ↑
$\pi_{0.5}$	Backbone	56	32	18	39	31	21
	VeriGraph-PDDL	68	56	66	46	39	56
	LERa-PDDL	67	57	64	47	43	63
	VLM-RP-BT	63	58	68	45	45	59
	LOGIV	72	60	72	50	48	68
AHA-WAM	Backbone	85	60	35	45	43	37
	VeriGraph-PDDL	90	78	81	56	46	77
	LERa-PDDL	88	79	82	52	48	73
	VLM-RP-BT	91	80	80	57	48	80
	LOGIV	93	83	85	62	53	84
Light-WAM	Backbone	74	58	28	43	39	31
	VeriGraph-PDDL	76	68	65	56	46	67
	LERa-PDDL	76	67	70	51	45	65
	VLM-RP-BT	78	70	62	58	43	68
	LOGIV	82	72	79	61	49	74

Task	Platform	$\pi_{0.5}$	$\pi_{0.5}$ + LOGIV
pick_tomato	Astribot S1	7 / 10	9 / 10
build_blocks	Astribot S1	3 / 10	5 / 10
insert_cable	AgileX Piper	2 / 10	3 / 10
Overall	—	12 / 30 (40.0%)	17 / 30 (56.7%)

Real-world experiments. Table II reports the real-robot results. LOGIV succeeds in 17 of the 30 trials compared with 12 for the base policy, raising the overall success rate from 40.0% to 56.7%. It improves performance on all three tasks. On pick_tomato, successes increase from 7 to 9, with recovery from empty grasps or early releases of the tomato. On build_blocks, successes increase from 3 to 5. This gain comes from restoring condition support: when a later reach displaces a previously placed block, the Graph Gate detects that a condition required by the remaining placements no longer holds. Repair restores that block while retaining placements that remain valid. On insert_cable, successes increase only from 2 to 3. Most residual failures occur when the plug is aligned but fails to seat, so a successful retry depends on the contact-rich precision of the low-level policy rather than on the plan. With ten trials per task, wide confidence intervals indicate a trend rather than a precise effect size.

Ablation Study

We evaluate each ablation variant over 100 episodes per setting on the ten RoboTwin V2 tasks in Appendix B (Table A1), using $\pi_{0.5}$ with shared visual inputs, VLMs, and planning budgets.

Execution verification. Removing the State Gate, Node Gate, or Graph Gate lowers all three success measures. Removing the Graph Gate gives the lowest perturbed-task success, 48% compared with 60% for the full framework.

This result is consistent with a benefit from checking dependencies beyond the selected action. Removing uncertainty handling lowers condition restoration from 72% to 59%.

Dependency tracing and local repair. The variant without causal tracing selects repair nodes by their positions in the linear plan. Its mean modified-node fraction remains 24.6%, but clean-task success drops from 72% to 61% and perturbed-task success from 60% to 52%. Thus, the size of the selected region alone does not explain the result; the choice of nodes also matters. Replanning all remaining actions increases the modified-node fraction to 100% and repeated valid actions from 0.2 to 1.6, while perturbed-task success decreases to 54%. The modified-node fraction partly reflects this variant’s definition and should be read alongside task success and repeated execution.

Plan validation. Without validation of the repaired plan, condition restoration decreases from 72% to 62%, while perturbed-task success decreases from 60% to 57%. VAL checks whether the repair fragment is compatible with retained operators and whether the complete continuation reaches the goal under the symbolic model. These results are consistent with a benefit from checking the combined plan rather than accepting a local fragment in isolation.

Conclusion

We presented LOGIV, a framework that connects symbolic task dependencies with observation-based execution checks and local plan repair. After detecting an invalidated condition, LOGIV constructs a repaired continuation while retaining usable unfinished actions and validates the result before execution resumes. Experiments on RoboTwin V2 and BiCoord show higher observed task success across three execution backbones, while the number of successful real-robot trials increases from 12/30 to 17/30. Ablations are consistent with benefits from dependency tracing, local repair, and validation. The findings are limited to the evaluated tasks, perturbations, and trial counts. Future work will examine broader disturbances, incomplete state information, and the runtime and resource costs of online recovery. We will also evaluate human assistance in failure recovery.

Appendix A: Execution and Repair Algorithms

This appendix provides the pseudocode for the graph execution interface described in Section III. The two procedures separate execution monitoring from plan repair: the first determines when the current graph can advance, and the second constructs a validated continuation after a confirmed failure.

Task-Graph Execution

Algorithm 1 connects initial planning, graph-based scheduling, observation-based verification, and repair. It advances only when the selected action and its required support pass the checks; unresolved state estimates terminate the episode. Goal satisfaction is checked explicitly after all actions are complete.

Algorithm 1  LOGIV Task-Graph Execution and Repair

Require  initial task state S₀, task goal g
Output   SUCCESS or FAILURE

 1  P ← PreparePlan(S₀, g)
 2  if P = FAIL then return FAILURE
 3  G ← BuildGraph(S₀, P, g); t ← 0
 4  while execution budget remains do
 5      if all actions are complete then v ← GOAL
 6      else v ← SelectNode(G, P, Sₜ)
 7      if v = ∅ then return FAILURE
 8      (status, Sₜ₊₁, eₜ) ← VerifyAndExecute(v, G, Sₜ)
 9      if status = UNRESOLVED then return FAILURE
10      if v = GOAL and status = PASS then return SUCCESS
11      if status = FAIL then
12          (P′, G′) ← TopologyGuidedRepair(Sₜ₊₁, eₜ, P, G)
13          if P′ = FAIL then return FAILURE
14          (P, G) ← (P′, G′)
15      end if
16      t ← t + 1
17  end while
18  return FAILURE    // budget exhausted

Notes. SelectNode uses Section III-C’s scheduling rule and returns $\varnothing$ if no unfinished action has completed predecessors; START counts as complete. VerifyAndExecute updates the state and $G$, marking the action complete once its effects pass, then checking remaining support.

Topology-Guided Repair

Algorithm 2 distinguishes actions affected by a failure from actions that must be replaced. The retained unfinished actions determine the repair requirements through a backward pass. A candidate is accepted only after validation of the repair fragment together with the retained continuation; failures can expand the replacement scope within the stated budget. The procedure does not guarantee a minimal repair or completeness.

Algorithm 2 TopologyGuidedRepair

Require symbolic state $S_{t+1}$, error $e_t$, plan $P$, graph $G$ Output repaired plan and graph $(P', G')$, or FAIL

1. $g \leftarrow\operatorname{Goal}(G)$; $(D, A) \leftarrow\operatorname{Locate}(e_t, G)$; $H \leftarrow\varnothing$

2. while repair budget remains do

3. $P_{\mathrm{keep}} \leftarrow P_{\mathrm{unfinished}} \setminus A$ // retained plan

4. $g_{\mathrm{rep}} \leftarrow g$ // repair goal

5. for each $a \in P_{\mathrm{keep}}^{\mathrm{rev}}$ do

6. $g_{\mathrm{rep}} \leftarrow\operatorname{Backstep}(g_{\mathrm{rep}}, a)$

7. if $g_{\mathrm{rep}} = \mathrm{FAIL}$ then return FAIL

8. end for

9. $\Delta P_t \leftarrow\operatorname{OperatorPlanner}(S_{t+1}, g_{\mathrm{rep}})$; $u \leftarrow\varnothing$

10. if $\Delta P_t \notin\{\mathrm{FAIL}, \mathrm{TIMEOUT}\}$ then

11. if $\Delta P_t \in H$ then return FAIL

12. $H \leftarrow H \cup\{\Delta P_t\}$; $P' \leftarrow\Delta P_t \oplus P_{\mathrm{keep}}$

13. $(\mathrm{valid}, f) \leftarrow\operatorname{VAL}(S_{t+1}, P', g)$

14. if valid then return $(P', \operatorname{BuildGraph}(S_{t+1}, P', g))$

15. if $f \in\Delta P_t$ then continue // retry same scope

16. $u \leftarrow\operatorname{EarliestFail}(f, P_{\mathrm{keep}})$

17. end if; if $u = \varnothing$ then $u \leftarrow\operatorname{Fallback}(P_{\mathrm{keep}}, D)$

18. if $u = \varnothing$ then return FAIL

19. $A \leftarrow A \cup\operatorname{Succ}^{*}_{G}(u)$; $H \leftarrow\varnothing$

20. end while; return FAIL

Notes. $D$ and $A$ denote affected and currently replaced actions. Backstep performs the backward update in Section III-C and returns FAIL on conflict. $P_{\mathrm{unfinished}}$ follows the order in $P$; $P_{\mathrm{keep}}^{\mathrm{rev}}$ is $P_{\mathrm{keep}}$ in reverse. EarliestFail selects the earliest failing retained action. Fallback selects the first retained action in $D$, otherwise the first in $P_{\mathrm{keep}}$, or $\varnothing$. $\operatorname{Succ}^{*}_{G}$ includes $u$ and its unfinished causal successors. Locate follows the scope-selection rules in Section III-C; BuildGraph follows Section III-B; $H$ stores current-scope candidates.

Appendix B: Simulation Task Suite

Table A1 lists the ten selected tasks from each simulation benchmark. These are the same tasks used for the clean and perturbed settings in § 4-A; the ablations use the RoboTwin V2 subset. Each task has ten predefined initial states, giving 100 episodes per benchmark and setting. Task names are retained as benchmark identifiers to make the evaluation scope explicit. The table lists the selected subset, not the complete benchmark collections.