cleveragents/cleveragents-core

Fork 3

UAT: `agents plan correct --mode revert` does not re-execute plan from corrected decision point — only runs invariant reconciliation #5095

New issue

Open

opened 2026-04-09 01:00:46 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-09 01:00:46 +00:00

Owner

Bug Report

Feature Area: Sandbox and Checkpoint / Correction Model
Tested By: UAT worker (uat-pool-1), feature area: Sandbox and Checkpoint
Severity: Critical (correction revert mode is non-functional — plan is not re-executed after correction)

What Was Tested

The agents plan correct --mode revert command was analyzed to verify it re-executes the plan from the corrected decision point as defined in the specification (§Correction Flow (Revert Mode), lines 28787–28906).

Expected Behavior (from spec)

The spec defines the revert correction flow (§Mid-Execute Correction, lines 28811–28837):

Load checkpoint group for the target decision
Classify resources (rollbackable vs non-rollbackable)
Warn about limitations
Resource rollback (git reset --hard)
Reasoning rollback (restore actor's LangGraph state from actor_state_ref)
Supersede affected subtree
Inject guidance and resume: The execution actor continues from the restored state

The spec also states (§Mid-Strategize Correction, line 28806):

Resume strategy actor: The actor continues reasoning from the restored state, informed by the correction guidance. New decisions replace the superseded ones.

Actual Behavior (from code)

The CorrectionService.execute_revert() in src/cleveragents/application/services/correction_service.py:

✓ Restores checkpoint (via _try_checkpoint_restoration)
✓ Extracts actor_state_ref from target decision
✓ Creates user_intervention decision ID
✓ Sets phase_transition_target = "strategize"
❌ Does NOT re-execute the plan — only returns a CorrectionResult with metadata

The PlanLifecycleService._handle_correction_applied() (lines 542–569) handles the CORRECTION_APPLIED event but only:

Re-runs invariant reconciliation (_run_invariant_reconciliation)
Does NOT transition the plan back to Strategize phase
Does NOT re-execute the plan from the corrected decision point
Does NOT use the phase_transition_target signal from the correction result

After agents plan correct --mode revert completes, the plan remains in its current phase (e.g., Execute) with the sandbox reverted but no re-execution triggered. The user must manually run agents plan execute <PLAN_ID> to continue — but this is not documented and the plan's state may not be correct for re-execution.

Code Location

src/cleveragents/application/services/correction_service.py, execute_revert() method — returns phase_transition_target but doesn't act on it
src/cleveragents/application/services/plan_lifecycle_service.py, _handle_correction_applied() method (lines 542–569) — only runs reconciliation, not re-execution

Steps to Reproduce

Create and execute a plan to generate several decisions
Run agents plan correct <DECISION_ID> --mode revert --guidance "Use a different approach" --yes
Expected: Plan reverts to the corrected decision point and automatically re-executes from there
Actual: Sandbox is reverted (if checkpoint exists), but plan stays in current phase with no re-execution triggered

Impact

Critical: The core value proposition of --mode revert — "undo a decision and recompute affected subtrees" — is not implemented
User confusion: Users expect the plan to re-execute after correction, but nothing happens automatically
Spec violation: The spec's correction flow (§Correction Flow (Revert Mode)) requires automatic re-execution from the corrected decision point

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area**: Sandbox and Checkpoint / Correction Model **Tested By**: UAT worker (uat-pool-1), feature area: Sandbox and Checkpoint **Severity**: Critical (correction revert mode is non-functional — plan is not re-executed after correction) --- ## What Was Tested The `agents plan correct --mode revert` command was analyzed to verify it re-executes the plan from the corrected decision point as defined in the specification (§Correction Flow (Revert Mode), lines 28787–28906). ## Expected Behavior (from spec) The spec defines the revert correction flow (§Mid-Execute Correction, lines 28811–28837): 1. Load checkpoint group for the target decision 2. Classify resources (rollbackable vs non-rollbackable) 3. Warn about limitations 4. Resource rollback (git reset --hard) 5. Reasoning rollback (restore actor's LangGraph state from `actor_state_ref`) 6. Supersede affected subtree 7. **Inject guidance and resume**: The execution actor continues from the restored state The spec also states (§Mid-Strategize Correction, line 28806): > **Resume strategy actor**: The actor continues reasoning from the restored state, informed by the correction guidance. New decisions replace the superseded ones. ## Actual Behavior (from code) The `CorrectionService.execute_revert()` in `src/cleveragents/application/services/correction_service.py`: 1. ✓ Restores checkpoint (via `_try_checkpoint_restoration`) 2. ✓ Extracts `actor_state_ref` from target decision 3. ✓ Creates `user_intervention` decision ID 4. ✓ Sets `phase_transition_target = "strategize"` 5. ❌ **Does NOT re-execute the plan** — only returns a `CorrectionResult` with metadata The `PlanLifecycleService._handle_correction_applied()` (lines 542–569) handles the `CORRECTION_APPLIED` event but only: - Re-runs invariant reconciliation (`_run_invariant_reconciliation`) - Does NOT transition the plan back to Strategize phase - Does NOT re-execute the plan from the corrected decision point - Does NOT use the `phase_transition_target` signal from the correction result After `agents plan correct --mode revert` completes, the plan remains in its current phase (e.g., Execute) with the sandbox reverted but no re-execution triggered. The user must manually run `agents plan execute <PLAN_ID>` to continue — but this is not documented and the plan's state may not be correct for re-execution. ## Code Location - `src/cleveragents/application/services/correction_service.py`, `execute_revert()` method — returns `phase_transition_target` but doesn't act on it - `src/cleveragents/application/services/plan_lifecycle_service.py`, `_handle_correction_applied()` method (lines 542–569) — only runs reconciliation, not re-execution ## Steps to Reproduce 1. Create and execute a plan to generate several decisions 2. Run `agents plan correct <DECISION_ID> --mode revert --guidance "Use a different approach" --yes` 3. Expected: Plan reverts to the corrected decision point and automatically re-executes from there 4. Actual: Sandbox is reverted (if checkpoint exists), but plan stays in current phase with no re-execution triggered ## Impact - **Critical**: The core value proposition of `--mode revert` — "undo a decision and recompute affected subtrees" — is not implemented - **User confusion**: Users expect the plan to re-execute after correction, but nothing happens automatically - **Spec violation**: The spec's correction flow (§Correction Flow (Revert Mode)) requires automatic re-execution from the corrected decision point --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 01:00:50 +00:00

HAL9000 added a new dependency

2026-04-09 01:03:06 +00:00

#4959 EPIC: Correction Engine — Revert & Append Modes with plan.attempt Tracking

HAL9000 commented

2026-04-09 01:03:25 +00:00

Author

Owner

Hierarchical Compliance Fix: This issue was detected as an orphan (no parent Epic).

Solution: Linked to Epic #4959 (EPIC: Correction Engine — Revert & Append Modes with plan.attempt Tracking) based on scope — this bug is about agents plan correct --mode revert which is the core deliverable of that Epic.

Hierarchy: Issue #5095 → Epic #4959 → Legendary #4942

Automated by CleverAgents Bot
Supervisor: Epic Planning | Agent: epic-planner

**Hierarchical Compliance Fix**: This issue was detected as an orphan (no parent Epic). **Solution**: Linked to Epic #4959 (EPIC: Correction Engine — Revert & Append Modes with plan.attempt Tracking) based on scope — this bug is about `agents plan correct --mode revert` which is the core deliverable of that Epic. **Hierarchy**: Issue #5095 → Epic #4959 → Legendary #4942 --- **Automated by CleverAgents Bot** Supervisor: Epic Planning | Agent: epic-planner

~~HAL9000 referenced this issue 2026-04-09 01:06:02 +00:00~~

[AUTO-EPIC] Epic Planning Health Report (Cycle 1) #4985

HAL9000 added

and removed

labels

2026-04-09 01:10:49 +00:00

HAL9000 added this to the v3.2.0 milestone

2026-04-09 01:10:49 +00:00

HAL9000 commented

2026-04-09 01:10:49 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: High — Critical spec compliance bug
Milestone: v3.2.0
Story Points: 3 — M
MoSCoW: Must Have

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: High — Critical spec compliance bug - **Milestone**: v3.2.0 - **Story Points**: 3 — M - **MoSCoW**: Must Have --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 referenced this issue

2026-04-09 01:11:14 +00:00

[AUTO-UAT-POOL] UAT Testing Report (Cycle 2) #4987

HAL9000 modified the milestone from v3.2.0 to v3.3.0

2026-04-09 01:11:37 +00:00

HAL9000 referenced this issue

2026-04-09 02:56:12 +00:00

[AUTO-UAT-POOL] UAT Testing Report (Cycle 4) #5160

HAL9000 referenced this issue

2026-04-09 03:09:06 +00:00

[AUTO-UAT-POOL] UAT Testing Report (Cycle 5) #5200

HAL9000 referenced this issue