feat(correction): implement plan correct --mode=revert re-execution from corrected decision point #8909

Open
opened 2026-04-14 04:02:07 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Commit message: feat(correction): implement plan correct --mode=revert re-execution from corrected decision point
  • Branch name: feat/m3-m4/correction-revert-mode

Background and Context

Epic #4959 (Correction Engine — Revert & Append Modes) requires that agents plan correct --mode=revert properly re-enters the Strategize phase after a correction is applied. Currently, plan correct --mode=revert sets phase_transition_target but the CLI never reads it, so the plan does not actually re-execute from the corrected decision point.

This issue implements the full revert correction flow: the user identifies a decision to revert, the correction engine supersedes the affected decisions, and the plan re-enters Strategize to re-execute from the corrected point. The plan.attempt counter must be incremented on each correction.

This issue blocks Epic #4959.

Acceptance Criteria

  • agents plan correct --mode=revert <PLAN_ID> <DECISION_ID> supersedes the target decision and all downstream decisions
  • After revert, the plan re-enters the Strategize phase for re-execution from the corrected point
  • plan.attempt counter is incremented on each successful correction
  • CorrectionService.execute_revert() persists the correction attempt to the correction_attempts DB table
  • correction_attempts table includes original_subtree_snapshot field per spec DDL
  • Rich output shows: corrected decision ID, affected decisions count, new attempt number
  • JSON/YAML output uses spec-required envelope with correction_id, mode, affected_decisions
  • Unit tests (Behave) cover revert scenarios including partial subtree revert
  • Test coverage >= 97% for all new/modified modules

Subtasks

  • Read phase_transition_target in CLI after CorrectionService.execute_revert() returns
  • Implement plan state transition to Strategize after revert
  • Implement CorrectionService.execute_revert() to supersede affected decisions in DB
  • Add original_subtree_snapshot column to correction_attempts migration
  • Implement plan.attempt increment in CorrectionService
  • Implement Rich output panel for revert result (Correction, Affected Decisions, New Attempt)
  • Implement JSON/YAML envelope output for plan correct command
  • Write Behave unit tests for revert mode (full subtree, partial subtree, no-op)
  • Verify coverage >= 97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

  • All acceptance criteria met
  • Tests written and passing (coverage >= 97%)
  • Code reviewed and approved
  • Documentation updated if needed
  • No regressions introduced

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit message:** `feat(correction): implement plan correct --mode=revert re-execution from corrected decision point` - **Branch name:** `feat/m3-m4/correction-revert-mode` ## Background and Context Epic #4959 (Correction Engine — Revert & Append Modes) requires that `agents plan correct --mode=revert` properly re-enters the Strategize phase after a correction is applied. Currently, `plan correct --mode=revert` sets `phase_transition_target` but the CLI never reads it, so the plan does not actually re-execute from the corrected decision point. This issue implements the full revert correction flow: the user identifies a decision to revert, the correction engine supersedes the affected decisions, and the plan re-enters Strategize to re-execute from the corrected point. The `plan.attempt` counter must be incremented on each correction. This issue blocks Epic #4959. ## Acceptance Criteria - [ ] `agents plan correct --mode=revert <PLAN_ID> <DECISION_ID>` supersedes the target decision and all downstream decisions - [ ] After revert, the plan re-enters the Strategize phase for re-execution from the corrected point - [ ] `plan.attempt` counter is incremented on each successful correction - [ ] `CorrectionService.execute_revert()` persists the correction attempt to the `correction_attempts` DB table - [ ] `correction_attempts` table includes `original_subtree_snapshot` field per spec DDL - [ ] Rich output shows: corrected decision ID, affected decisions count, new attempt number - [ ] JSON/YAML output uses spec-required envelope with `correction_id`, `mode`, `affected_decisions` - [ ] Unit tests (Behave) cover revert scenarios including partial subtree revert - [ ] Test coverage >= 97% for all new/modified modules ## Subtasks - [ ] Read `phase_transition_target` in CLI after `CorrectionService.execute_revert()` returns - [ ] Implement plan state transition to Strategize after revert - [ ] Implement `CorrectionService.execute_revert()` to supersede affected decisions in DB - [ ] Add `original_subtree_snapshot` column to `correction_attempts` migration - [ ] Implement `plan.attempt` increment in `CorrectionService` - [ ] Implement Rich output panel for revert result (Correction, Affected Decisions, New Attempt) - [ ] Implement JSON/YAML envelope output for `plan correct` command - [ ] Write Behave unit tests for revert mode (full subtree, partial subtree, no-op) - [ ] Verify coverage >= 97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done - [ ] All acceptance criteria met - [ ] Tests written and passing (coverage >= 97%) - [ ] Code reviewed and approved - [ ] Documentation updated if needed - [ ] No regressions introduced --- **Automated by CleverAgents Bot** Agent: new-issue-creator
HAL9000 added this to the v3.3.0 milestone 2026-04-14 04:03:43 +00:00
Author
Owner

Verified — Plan correct revert mode is a v3.3.0 acceptance criterion. MoSCoW: Must-have. Priority: Medium.


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

✅ **Verified** — Plan correct revert mode is a v3.3.0 acceptance criterion. MoSCoW: Must-have. Priority: Medium. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner-pool-supervisor
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
cleveragents/cleveragents-core#8909
No description provided.