Currently it’s just capturing stdin only and re-running the entire app, but I have plans for more. In order to be able to replay a program deterministically you need to be able to capture all possible inputs. This includes little background things like random number generator seeds, the current time whenever it is read, etc. Currently it doesn’t do a good job of replaying if you use a random number or try to measure how long it takes for a user to provide input.
For a Discord bot you need to capture request-response pairs (or a recording of whatever is streaming over a websocket) so it’s as easy as storing them and replaying them. If you decide to change the code to make a new request in a different order or with different parameters then well... it can’t replay that safely so it’d have to prompt the user to do another manual run. For a network heavy app like that most of the running time is waiting for the network so replays would be pretty fast.
For a 2D game… that’s a lot harder to deterministically reproduce, especially at speed. You’d need to replay each mouse/keyboard event at the appropriate times in the main event loop, and you’d need to replay all the event/render loops with the same timestamp they originally occurred at - so if you take a 5min long capture of gameplay then well… replaying that could be pretty slow, even if you cut out all the sleeps, max out your CPU and skip the actual rendering. That is unless you can find a way to make it faster by snapshotting state and skipping steps.
Inspiration for this (and considering that it might even be possible to deterministically record and replay programs) came from the RR project:
https://rr-project.org/. They work at a very different level of abstraction though.