You are browsing as a guest. Sign up (or log in) to start making projects!

Open comments for this post

3h 46m 48s logged

Two more hours in, and WinSentry now has a fully functioning debloating engine and a robust multi-threaded architecture.

What’s new

  • I ripped out the real-time event watcher and replaced it with a task that executes once every 30 minutes. It sleeps completely in between cycles. Performance dropped immediately back to 0% CPU on idle, achieving the exact “invisible” footprint a performance tool needs.
  • Reworked Threading: Thread safety is locked down. The core engine now cleanly separates the global UI hotkey listener thread from the background debloating loop, ensuring a heavy system cleanup never hitches or delays the 300ms “Panic Button” response.
  • System Debloater: The 30-minute janitor thread now actively sweeps system-generated trash paths (configured via %APPDATA%/WinSentry/config.toml). It safely bypasses active, locked files while cleanly executing deep purges on dead telemetry and crash dumps.
  • Robust Logging & Documentation: Implemented a lightweight, structured local logging system to track exactly how many megabytes of ghost space are reclaimed over time. I also laid down the full README.md.

Next Up
Implementing the User-Specified Safe Queue (queue.json). I’ll be writing the directory traversal logic to detect massive developer black holes (node_modules, pycache) and scaffolding the manual CLI review step so users can safely approve massive space reclamation.

0
2

Comments 0

No comments yet. Be the first!