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?

Thanks for pointing it out, README is outdated, .rapel-state.json is not being used anymore, as the current state is now calculated from the chunk files downloaded. It doesn't detect remote file changes.

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.

Yes exactly how I felt - I wanted to keep control on the tooling + on what's inside the context so Git felt like the most open tool to do this

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.

I think the git worktree per task idea makes more sense. The hard part with parallel agents seems to be reviewing and merging the mess

yeah, the worktree is a must for running multiple agents working on the same repo/folder. I want to add the branch creation in a future release too

Humans are kind part of the process but in a `review mode`

Do you think the DMG installation method will continue to be a long-term part of the macOS ecosystem, or is it more of a continuation of indie Mac culture?

macOS AppStore is largely unpopular. Unless Apple changes something (very unlikely), DMG will continue being the main way of intalling apps. The app supports signing the DMG itself, so your users won’t get the Gatekeeper warning.

So innovative! I've talked to your goose and I found this is really a great way to test whether I truly understand concept. I don't know how the goose thinks, maybe it would be even better if it allowed me to upload my own data and ask questions based on that context.

Yeah, that's not the first time I've been suggested that feature. It's still being activley devloped so be on the look out for it :).

I think your concept of this APP is meaningful for most people. I'm curious to know how you handle data calibration, especially when it comes to different regions, remote offers, and issues with uneven sample distribution.

"App" is still hard-wired into my brain after my last job. It's web-only right now but I do want to get iOS and Android version when I have the time (or money).

Right now we're processing a lot of data from various government sources and other free datasets to get salary information across all of the major US metros. Plus ingesting a bunch of data from some unnamed paid job posting APIs (respecting ToS) and pulling out reported salary information, if it exists. It's why the landing page is marked as "US-only" right now, I wanted a tight scope for an MVP launch. I have a number of tech friends in Canada so that'll probably be the next country I support.

Right now I'm basing the user's salary data on the metro where they currently live. Not perfect and not the long term solution but cracking it fell to the cutting room floor to get an MVP shipped. That was a difficult cut but I gave myself a mid-May deadline to get something shipped.

Re: Uneven sample distribution. Sample size is a first-class concept in scoring. For each user's metro+role+level slice, n is computed over a trailing 60-day window. Below a threshold (currently 30), I aggregate to a broader peer group and explicitly flag lower confidence on the score. Bayesian priors derived from the nationwide distribution for that role help fill in thin slices, so a senior Rust dev in Boise still gets a number but they also see "this is computed from a small local sample plus regional inference" rather than a false-precision point estimate. It's a lot and is still being fine-tuned.

Pay transparency laws in CA/NYC/CO/WA are helping but coverage is patchy.

Right now I'm not using any user-provided data in calculations as my user-base is too small and there's too much risk for identification. Eventually I want to add opt-in data submission so we can run real-time metro-aware compensation surveys based on consented and anonymized peer data.