This is an X:Y problem. You don't have new tasks, you've got problems in scope planning and estimation/WBS development.
1) The work isn't scoped correctly - the WBS & WBSD should explicitly address the number of legs for the cat (assuming that the cat's number of legs is important). This is a planning problem. When you analyze variance, you should consider the impact of this on future planning. If this happened to me, I'd revise my planning process for future project/sprints/planning efforts.
2) The work isn't estimated correctly. Estimation of work packages has an innate high variance. The reason we pay these people so much is because their work is complicated and includes a lot of surprises. Bugs get discovered. Technical debt undermines progress. Good project managers recognize this and ask for estimation in ranges/confidence intervals, and continuously track the variance. Some developers will consistently underestimate work packages; others will overestimate. A good project manager will track the estimation variance and adjust estimation variance for future projects.
How do you handle changes in planned value? (which is the way I'd phrase your original question) First, you use a configuration management process to assess the impact of the changes on the project and ensure that relevant stakeholders are aware of the change and have the option to assist in managing the change and second you re-assess the rest of the project plan in the light of the change. Scrutinize that plan to see where else the estimation and/or scoping are questionable, and adjust the confidence interval of those sections of the plan.
Key summary points
1) Subsequent plans & estimation should benefit from earlier plans and estimation (that is one of the points of lessons learned and variance measurement). Bad project managers "pad" the schedule; good project managers apply lessons learned from prior projects to improve the probability that the outcome will be within the estimate.
2) As the team progresses through the project, the confidence intervals will narrow. Good project managers are constantly revising estimates, and the confidence interval can be a huge leading indicator of risk. If a finished project requires 12 work packages, and each work package is estimated within 80%, then the confidence interval for the entire project is huge (which is why monte carlo is so powerful). But when the first work package is delivered, the confidence interval should collapse inward - both because the confidence interval of a delivered work package is zero, and because what you learned from the variance can be applied to the confidence interval of all subsequent work packages.
3) I forget who said that the key skill of a project manager is setting up the conversations with the technical experts so that they automatically give you the information you need to manage the project - establishing your information needs so that sharing that information seems friction free. A good PM is always alert to any event that might alter the quality, schedule, cost, or completion probability of the project and is constantly listening to the project team for evidence.