Tell us about your process and discipline; I see `engineering-quality` in the repo, which seems to be some sort of QA harness. Makes this a bit more interesting than just-another-yt-dlp-ui. Do you follow some similar design process, like speckit?

I'm not using Spec Kit specifically, my approach is pretty simple. Everything should have separation of concerns and clear ownership to help prevent nasty subtle bugs and can help point to a single entity when things go wrong.

Also, it is specifically designed to avoid only following happy paths, it exercises the actual download pipeline with yt-dlp, ffmpeg, and real output files. It will introduce things like interrupted connections, failed requests, cancellation of downloads, and unwritable destinations. It also checks for processes that were left running when a download completes as to not waste resources.

I also wanted to distinguish between headless pipeline tests and testing the actual packaged app. Passing the headless pipeline doesnt prove the UI, queue, or restart UX works. This same idea influences the design. The library should reflect the actual saved state for example. Completed should mean a valid file was produced and so the engineering quality harness is there to test assumptions and pressure test the application in ways unit tests can easily miss. It is still evolving but that is where im putting effort right now so that we dont conclude "it just works" and walk away because it needs to work well and shouldnt rob your computers memory cause it feels like holding on to it and it has helped find many issues that unit tests have missed, which is great.

One example of something the harness helped find before was regarding the processes being left over and it was found a subtle memory leak in vodforge where yt-dlp’s terminal-capability/progress machinery was retaining the per-download logger, which in turn kept the entire YoutubeDL + DownloadJob graph alive after the job finished. I believe this was in part to the fact that python methods are bounded when you access them through object instances and so yt-dlp simply needed to have its native progress path disabled since vodforge already owned progress presentation. Engineer-quality harness was able to make this subtle memory leak a massive red flag when simulating 100 downloads and then showing 100 dead job graphs still sitting in memory.