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.
Comments 0
No comments yet. Be the first!
Sign in to join the conversation.