mvyshnyvetska

Yeah, that's more process-tooling territory — keeping this dev-focused for now.

Update: just shipped --brief flag. Thanks for the push!

Fair points :). The naming is 'evolutionary' — started as 'semantic diff' because it analyzes meaning not just lines, but 'commit review' is more accurate for what it does now. You're right about the redundancy — same issue appearing in 3 sections is noise. Adding output config (sections to include, verbosity level) is on the list. The 'why was this deleted' questions — yeah, the tool can't answer, but surfacing the question for the reviewer has value. At least you know to ask the author. Good callout on dependabot. Worth reconsidering. Thanks for actually trying it and giving specific feedback.

Interesting approach. A few questions:

How do you handle false positives from mutation strategies like Base64 or token smuggling? In my experience, a lot of "successful" jailbreaks from automated fuzzing don't actually produce harmful outputs — the model just gets confused and outputs gibberish that technically matches a keyword filter.

Also curious about your payload curation — are these tested against specific model families, or generic? The attack surface differs quite a bit between Claude, GPT-4, and open-source models.

The local-first angle is smart. Most enterprises I've talked to won't send their system prompts to a third-party SaaS for obvious reasons.

Hit exactly this problem some time ago (preliminarily buried 5 or 6 versions of memory systems).

Generic summaries or RAG results often feel useless because models optimize for "what would be useful to explain to anyone" rather than "what was significant in this specific context."

What worked for me: separate semantic context (the "why are we here" layer) from structured tracking (decisions, blockers, dependencies). The semantic layer captures salience — what mattered emotionally or strategically — and the tracking layer handles facts or even snapshots of the latest state of the process.

The model does not have to guess what was important. The memory architecture can encode it.

We've been solving similar problems differently. Instead of a flat progress.txt, we use three layers: semantic context (what are we building and why), structured intention tracking (blockers, dependencies, decision paths), and git for versioning. Separating "understanding" from "tracking" from "versioning" reduces cognitive load on the agent. On the premature victory problem — we lean toward better task decomposition and human checkpoints rather than JSON flags the model "can't" edit. Funny thing: we had a bug where the orchestrating agent couldn't see the sub-agent's completion report. While fixing it, we realized — wait, this is actually useful. The human validates what was actually done before the orchestrator sees it. Accidental feature, now intentional. Feels more robust than programmatic constraints. Anyone else experimenting with multi-session agent architectures? Curious what's working for others.