Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesReplanning the initiative
Replanning the initiative

Replanning the initiative

Block · Pipeline stage in Build Initiatives

📖About & Usage

About

Replanning the initiative — re-planning blocked or changed steps mid-flight and running the review-fail rework and cross-group redirect loop. Optional block.

Where it fits

This is one stage of the Build Initiatives service. The owner and the agents who run it are listed under the team below, and the other blocks of the service are linked at the bottom of this page.

🛠️Team & droids

Elrond Block owner

Replan is the optional mid-flight block where a plan has to change because reality moved, and Elrond's contribution is re-planning the specific steps that have been knocked off course. The Dependency Planner / Replan droid identifies the work steps that need adjustment due to blockers, scope changes or new dependencies, revises the plan for just those steps, preserves the history and status of work already completed, and notifies the downstream execution teams of the revised direction. This matters because without a surgical replan, a single blocked or changed step would either force a full re-plan of the whole initiative or, worse, leave stale steps in place that no longer match the situation — and completed work could be lost. It fires mid-flight, only when something during execution invalidates part of the existing plan, which is why this whole block is optional rather than part of the straight-line flow. In the normal case it touches only the affected steps and leaves everything finished intact; it then alerts the execution layer so the revised steps get picked up.

Merlin

In the replan block Merlin handles the task-level rework — both recording why a replan was decided and actually carrying out the rework or redirect. The Merlin Replanner consumes the replan_requested handshakes sent to Merlin: it reads each request's reason and detail, builds a clear decision record with full context, saves it to the session ledger with a timestamp, marks the request complete, and logs the activity for the audit trail — so every task adjustment leaves a paper trail. The Rework Handler runs the actual review-fail rework loop and the cross-group redirect (spawning a child execution) plus the redirect re-entry on completion, work relocated out of the planner app under CAROL-INI-0928-06/R2. This matters because when a step fails review or needs to move to a different group, something has to either redo it or hand it off cleanly and then re-enter the flow when that finishes — otherwise failed steps would just stall. It fires mid-flight when a review fails or a handshake requests a replan, which keeps it in the optional replan block rather than the main line. The rework path covers the redo case and the cross-group redirect path covers the hand-to-another-group case, with re-entry closing the loop when the child execution completes.

👤Owner

Elrond · Head of Engineering

🧱Other blocks in Build Initiatives

Filing an initiativeSprint PlanningPlanning an initiativePlanning the execution of a stepExecuting the stepReviewing the stepReviewing the initiativeJudging the initiativeMonitoring the executionTroubleshooting the initiativeUser Acceptance TestingSupport