Debugging
Applying a proposed fix
Review the diff, apply it in one step, or turn it down; nothing lands until you say so.
A debug or optimize run ends with a proposal: the exact files it would write, the diff between them and yours, and two buttons. Applying is free, takes no model call at all, and is the only thing in either mode that writes to your project.
The card
Proposed fix
re-simulated1 file modified · compare the full pointer before asserting full.
The heading tells you which kind of proposal it is, because the two ask you for different decisions. A proposed fix is something you probably need. A proposed rewrite from Optimize mode is something you are choosing, with a trade-off attached.
Reading the badge
| Badge | What it means |
|---|---|
| re-simulated | A simulation passed after the last edit in this change set. The strongest routine claim a fix can carry. |
| not re-simulated | No simulation passed after the last edit. The reasoning may be right and the change has not been demonstrated; read the diff before applying. |
| equivalence proved | Optimize only. The rewrite was formally proved to behave identically after the last edit. Check the panel for whether that proof was bounded. |
| behaviour unproved | Optimize only. No proof survived the last edit; treat the rewrite as unverified. |
Note
The "after the last edit" part is the whole point of the badge. Evidence gathered before the final change says nothing about that change, so it is tracked mechanically rather than taken from what the run said it did.
The weakened-checks warning
Before a proposal is shown, its diff is scanned for checks that were removed or commented out, and for edits to the testbench. Anything found is listed on the card next to the Apply button and repeated in the transcript. This scan runs on the diff itself, independently of what the run reported, so it holds even when the run believed it did nothing of the sort.
- A check or assertion was deleted. Read that hunk before anything else; a failure that disappears because the check disappeared is not a fix.
- A check was commented out. Same, with a thinner disguise.
- The testbench was modified. Sometimes legitimate, when the testbench timing was genuinely wrong. The summary should say so; if it does not, be suspicious.
Heads up
Removing a print statement is not flagged; that is housekeeping. Removing something that decides pass or fail is, every time.
Applying
Apply writes every file in the proposal, or none of them. If any of the files have moved on since the diagnosis was made, nothing is written and you are told which ones changed; applying the clean half would leave your project in a state nobody has ever compiled.
- 1
Expand the diffs and read them
Each file lists its added and removed lines. A good fix is small. A large diff on a small bug is worth a second look before it lands.
- 2
Click Apply
The files are written into your project workspace. There is no model call and no charge; you can take as long as you like deciding.
- 3
Re-run what matters to you
Ask for a simulation, or download the project and run it in your own flow. The badge says what was checked here; your own toolchain is the one that has to be happy.
Clicking Apply twice is harmless; the second click reports that it was already applied rather than writing again.
When a proposal goes stale
If you edit the project, or apply another proposal that touches the same files, an earlier proposal no longer describes the code it was built against. It is marked stale and the panel warns you before you click rather than after.
The fix for a stale proposal is to ask again, not to merge it by hand. A fresh turn re-reads the current files, and because the workspace persists it still has everything the earlier turn learned.
Turning one down
Not now marks the proposal rejected and leaves your files alone. The diagnosis stays on the turn, so you keep the analysis and lose only the suggested edit. Rejecting is also the right move when the diagnosis is right but you would rather write the fix yourself.