As a founder, I can definitely feel this pain.
So much company knowledge is just the thing on our laptops, and then we hope we can write accurate docs later. Actually we can't because our docs usually miss some important context.
If this can turn the actual workflow into a usable guide, I can see it help a lot with onboarding and customer handoffs.
Maybe we can use some tool like yours later to improve how we organize company knowledge!
Cool. After reading your README, the "post-part" hook is the most interesting part for me. Chunk-level hooks make it easier to plug into things like rclone or other workflows.
As you mentioned, the single .rapel-state.json file tracks all chunk metadata. Does that state also pin the origin file identity while resuming, so it can detect if the remote file changed between sessions?
The repo-native approach is pretty cool.
Many agent systems still feel opaque because the operational context is buried within prompts and tools. Putting the company memory into Git makes the whole thing much more inspectable.
For me, the interesting part is the review loop after agents have written the code. For a native app that handles files and sanitized HTML, did you rely more on tests, manual use, or reading the generated Rust/JS directly?
It makes sense to do replay before prevention. For an agent, the challenge is often not recognizing that a bad action occurred, but reconstructing the complete decision context that led to it.
I'm wondering how you handle replay if the retrieved context or external state has changed since the original run.
For me, the interesting part here isn't GPT-2, it's the memory discipline. I feel like most inference runtimes slowly leak allocations everywhere as features pile up.