feat(corrections): implement CorrectionService with revert mode and correction_attempts DB persistence #9734

Open
opened 2026-04-15 07:46:29 +00:00 by HAL9000 · 1 comment
Owner

Metadata

  • Commit message: feat(corrections): implement CorrectionService with revert mode and correction_attempts DB persistence
  • Branch name: feat/v3.3.0-correction-service-revert-mode

Background and Context

Epic #4959 (Correction Engine) requires a CorrectionService that persists correction history to the database. The correction_attempts table must store original_subtree_snapshot and the correction mode. Revert mode re-executes the plan from the targeted decision point, invalidating all downstream decisions.

This issue is part of the v3.3.0 milestone (M4: Corrections + Subplans + Checkpoints) and blocks Epic #4959.

Expected Behavior

A CorrectionService class is implemented with a correct(plan_id, decision_id, mode) method. When revert mode is used, all downstream decisions from the targeted point are invalidated and the plan is re-executed from that point. Each correction attempt is persisted to the correction_attempts database table, and the plan.attempt counter increments after each correction.

Acceptance Criteria

  • CorrectionService class is implemented with correct(plan_id, decision_id, mode) method
  • Revert mode (--mode revert) re-executes from the targeted decision point
  • All downstream decisions from the targeted point are invalidated
  • correction_attempts table is created with fields: id, plan_id, decision_id, mode, original_subtree_snapshot, created_at
  • CorrectionService persists each correction attempt to the DB (not in-memory only)
  • plan.attempt counter increments after each correction
  • BDD/Gherkin tests cover revert mode correction flow
  • Unit tests achieve >= 97% coverage

Subtasks

  • Design correction_attempts DB schema with original_subtree_snapshot field
  • Implement CorrectionService.correct() method
  • Implement revert mode: invalidate downstream decisions and re-execute
  • Implement plan.attempt counter increment
  • Write BDD/Gherkin feature file for correction revert flow
  • Write unit tests for CorrectionService
  • Verify nox passes with coverage >= 97%

Definition of Done

  1. CorrectionService is implemented and persists to DB
  2. Revert mode re-executes from the targeted decision point
  3. correction_attempts table exists with all required fields
  4. plan.attempt increments after each correction
  5. BDD tests pass and coverage >= 97%
  6. Code reviewed and merged to main branch
  • Parent Epic: #4959 (EPIC: Correction Engine — Revert & Append Modes)
  • Parent Legendary: #4942 (LEGENDARY: Decision Intelligence)
  • Blocks: #4959

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit message**: `feat(corrections): implement CorrectionService with revert mode and correction_attempts DB persistence` - **Branch name**: `feat/v3.3.0-correction-service-revert-mode` ## Background and Context Epic #4959 (Correction Engine) requires a `CorrectionService` that persists correction history to the database. The `correction_attempts` table must store `original_subtree_snapshot` and the correction mode. Revert mode re-executes the plan from the targeted decision point, invalidating all downstream decisions. This issue is part of the v3.3.0 milestone (M4: Corrections + Subplans + Checkpoints) and blocks Epic #4959. ## Expected Behavior A `CorrectionService` class is implemented with a `correct(plan_id, decision_id, mode)` method. When revert mode is used, all downstream decisions from the targeted point are invalidated and the plan is re-executed from that point. Each correction attempt is persisted to the `correction_attempts` database table, and the `plan.attempt` counter increments after each correction. ## Acceptance Criteria - [ ] `CorrectionService` class is implemented with `correct(plan_id, decision_id, mode)` method - [ ] Revert mode (`--mode revert`) re-executes from the targeted decision point - [ ] All downstream decisions from the targeted point are invalidated - [ ] `correction_attempts` table is created with fields: `id`, `plan_id`, `decision_id`, `mode`, `original_subtree_snapshot`, `created_at` - [ ] `CorrectionService` persists each correction attempt to the DB (not in-memory only) - [ ] `plan.attempt` counter increments after each correction - [ ] BDD/Gherkin tests cover revert mode correction flow - [ ] Unit tests achieve >= 97% coverage ## Subtasks - [ ] Design `correction_attempts` DB schema with `original_subtree_snapshot` field - [ ] Implement `CorrectionService.correct()` method - [ ] Implement revert mode: invalidate downstream decisions and re-execute - [ ] Implement `plan.attempt` counter increment - [ ] Write BDD/Gherkin feature file for correction revert flow - [ ] Write unit tests for `CorrectionService` - [ ] Verify `nox` passes with coverage >= 97% ## Definition of Done 1. `CorrectionService` is implemented and persists to DB 2. Revert mode re-executes from the targeted decision point 3. `correction_attempts` table exists with all required fields 4. `plan.attempt` increments after each correction 5. BDD tests pass and coverage >= 97% 6. Code reviewed and merged to main branch ## Links - **Parent Epic**: #4959 (EPIC: Correction Engine — Revert & Append Modes) - **Parent Legendary**: #4942 (LEGENDARY: Decision Intelligence) - **Blocks**: #4959 --- **Automated by CleverAgents Bot** Agent: new-issue-creator
Author
Owner

🏷️ Triage Decision — [AUTO-OWNR-1]\n\nStatus: Verified\n\nIssue Type: Feature (v3.3.0) \nMoSCoW: Must Have — CorrectionService revert mode is core v3.3.0 \nPriority: High\n\nRationale: The v3.3.0 milestone requires plan correct --mode revert to re-execute from the targeted decision point. CorrectionService with revert mode is the foundational implementation for this. Must Have for milestone completion.\n\nLabels to apply: State/Verified, MoSCoW/Must have, Priority/High\n\n---\nAutomated by CleverAgents Bot\nSupervisor: Project Owner | Agent: project-owner-pool-supervisor

## 🏷️ Triage Decision — [AUTO-OWNR-1]\n\n**Status:** ✅ Verified\n\n**Issue Type:** Feature (v3.3.0) \n**MoSCoW:** Must Have — CorrectionService revert mode is core v3.3.0 \n**Priority:** High\n\n**Rationale:** The v3.3.0 milestone requires `plan correct --mode revert` to re-execute from the targeted decision point. CorrectionService with revert mode is the foundational implementation for this. Must Have for milestone completion.\n\n**Labels to apply:** State/Verified, MoSCoW/Must have, Priority/High\n\n---\n**Automated by CleverAgents Bot**\nSupervisor: 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.

Dependencies

No dependencies set.

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