Undo tweaks

[ahmetcemkaraca]

hi everyone,

i’d like to contribute an “undo” feature so users can revert tweaks in a controlled way (not a single blanket “undo all”). i’m still fairly new to coding/github, but i’m happy to start small and iterate with feedback.

current repo pieces (as i understand them)

• the script already saves the last used settings in lastusedsettings.json (script root; quick method puts it in %temp%/win11debloat)
• features.json already links each tweak’s undo .reg file (where available)

goal

• let users select what to undo (safe + predictable)
• keep gui and cli feature parity wherever possible

ux options (open to feedback)
option a: “undo mode” screen

• add an “undo mode” entry point in gui
• read lastusedsettings.json and highlight tweaks that were last applied/changed
• user checks the tweaks they want to revert and clicks “undo selected”
• cli equivalent: --undo (interactive) or --undo-tweaks <id1,id2,...>

option b: 3-state toggles everywhere

• per tweak: default / enable / disable
• “default” means “don’t touch”
• enable/disable explicitly applies the tweak or its undo
• cli equivalent: flags that map to the same states

option c: combine both

• keep normal ui as-is, but introduce undo mode for “select what to revert”
• use 3-state toggles only where it improves clarity (or later as a follow-up)

mvp scope (suggested)
phase 1 (mvp): registry-based tweaks

• wire undo using the existing undo reg links in features.json
• focus on a clear selection workflow + cli parity
  phase 2: services + scheduled tasks
  phase 3: best-effort for things that are hard to fully revert (e.g. some appx removals / optional features), with clear documentation of limits

questions

1. do you prefer starting with option a (undo mode), option b (3-state everywhere), or option c (mix)?
2. for “highlight last changes”: should that be “last applied settings” from lastusedsettings.json, or do we need a separate “last changed” tracking later?
3. any preference on cli naming? (e.g. --undo, --undo-tweaks, --undo-mode)

if this direction looks good, i can start with a small pr for the mvp (undo mode + registry tweaks using features.json undo regs) and then iterate from there.

thanks!
p.s. wording here got a tiny assist from ai, implementation will be hands-on :)

[Raphire]

I think starting with just the registry tweaks is definitely the way to go. App reinstalls are a lot lower on my list of priorities.

1. A mix like your option c might be the way to go, there are some settings that people might want to change either way (outside of undoing).

2. I'm not sure on that yet, what do you think?

3. An -Undo parameter in combination with any command parameters feels like it would be the simplest to use and it would be the easiest to implement. But I'm open to other ideas, with much of this I try to get a feel before I make up my mind.

[ahmetcemkaraca]

thanks, that makes sense.

i agree,starting with registry-only is the safest mvp, and app reinstalls can stay out of scope for now.

on option c: i’m leaning the same way. keeping the current ui flow, but adding an “undo mode” for selective revert, and only using 3-state toggles for a small subset of settings that users commonly want to flip either way (even outside of undo). that avoids turning the whole ui into 3-state everywhere immediately.
i think we can start simple and use lastusedsettings.json as “what was applied last”. in the mvp, undo mode can just pre-select / highlight the tweaks that were enabled/disabled in that last run. it won’t be perfect “changed vs already-matched”, but it will be predictable and easy to understand. later, if needed, we can add a lightweight “last changed” tracking (e.g. store a small per-tweak apply timestamp or a diff list), but i’d avoid that complexity in the first pr.