Loren_SL

Have agents write scratch output outside the repo, while anything that matters lives in version control. That way you can purge the scratch files whenever you like.

Think of a project that helps you understand the machine and make it. Like visualizing virtual address space of a process. Input and output don't need to be fancy - just make a console application which read/writes using stdio.

It is not every day you see a VMS reference! Interesting read.

Thanks - I'll try to make it easier to read and tell what is going on.

Good points - maybe "arcane" would have been a better word to describe WinDbg - you can do just about anything, provided you know the right incantation. I hope you enjoy ForensicDbg!

Nice writeup. WinDbg has the same stale-cache trap on live Windows targets.

Does this work with stdio MCP servers? Or just http/https ones?

I always thought that traffic signals should be trying to minimize squared anger, where anger increases linearly with time spent waiting at intersection.

Having a clock you can play with also opens up ability to do things like bullet-time.

1: Don't keep it in memory. If you have to, keep it in memory for as short as time as possible and scrub it afterwards. For example, password fields.

2: If you generate crash dumps, scrub the dumps when you generate them. Some crash reporting services offer to do this automatically.

3: If you are writing anything client/server, where you control the server and the client runs on a users machine, never trust the client. Expect that it has been hacked, is being debugged, and is actively hostile.

I remember getting a 80387 chip for my Compaq 386/20. It has the same size package as the CPU! Now that makes a bit more sense.

This is a great writeup — bookmarking it. ForensicDbg is Windows-only right now, but I could easily see a day where I'm in your exact shoes trying to get a native postmortem debugger running on macOS.

This sounds like you would be entrusting Muse with an uncomfortable amount of personal information.