Patch
Half built.
Wrong provider.
The forecast works. The settings screen is done. Then you notice the provider needs a paid key.
“Use a free provider instead. Keep the settings screen.”
What Needs Rebuilding? What Can Stay?
You do not want a fresh project. You want this one corrected. The hard part is knowing what that correction touches.
Try The Situation
Interactive simulation. Fixed sample data. No real actions.
Back In Your Own Work
What Changes
When You Use This?
- A new plan revision with the earlier history retained.
- A visible distinction between revised, redone, preserved and rechecked work.
- File identity checks that can reveal conflicts instead of quietly overwriting newer work.
Before you try it for real.
The example explains the behavior. Your actual tools, account and evidence determine what is possible.
What You Need
A saved conversation with a qualifying plan or recorded tool activity. Code and tool access must be enabled for the intended workspace.
What Is Enforced, Recorded Or Advised
The platform checks file preconditions and retains plan revisions. External effects that need repeating can require fresh approval. Inferred impact analysis remains a judgment, not a complete dependency proof.
Where It Stops
Patch cannot unsend an email, reverse a payment or guarantee that generated code is correct. Review the diff and run checks appropriate to the project.
The Workflow, Step By Step
Name The Correction
Send a Patch against the earlier decision. If the target is ambiguous, choose it before anything changes.
Review The Impact
Inspect the revised plan. Recorded dependencies and inferred dependencies stay distinct; later work with no proven independence needs a recheck.
Repair And Inspect
Let Iris revise the affected work. Check the resulting file versions and verification results. A conflicting file version holds the repair for review.
Bring Your Own Version Of This Problem.