Desktop app: your credential, building itself while you code (Mac first)

[jpbelmo]

Freezing the product vision here so the design discussion has a north star.

A menu bar app you keep on while you code. Always running, like Dropbox, and just as boring. You add the repos you want it to watch, opt-in, one by one. It reads nothing but the git history of those repos, the same data redential scan already reads. No screen capture, no keystrokes, no other apps, ever.

One rule explains the whole product: if you committed it, it's in your credential. Everything you shipped, nothing you did around it.

What it does with that: your CV builds itself, live. Commit, and you can watch your profile grow: skills, streaks, the shape of your work. Every so often, right after a meaningful commit, it asks one question, in text or by voice (local models only): "what problem were you solving here?". Your answer lands timestamped and hash-chained in the local vault (the session receipts from #13). Answering is always optional, silence never penalized.

Everything stays on your machine until you hit upload. Then you see exactly what leaves, you choose what updates your Redential profile, and code never leaves, same as today.

Build order is fixed by dependencies: the session receipts (#13) land in the CLI first, since this app is a viewer of that vault; without receipts there is nothing to show live. Design and mockups happen in this thread meanwhile. Two standing decisions, both revisable here: the app lives in its own repo in this org (the CLI stays the small, auditable engine underneath), and this is design first: mockups in this thread before any code, same rule as #46.

Would the post-commit question feel useful or annoying? Genuinely curious.

[jpbelmo]

Pinging everyone who's built this project so far: @BharadwajKanneveti @rudi193-cmd @waterlemonnn @haleyher @SulimanAbdulrazzaq @eeshsaxena @tomatotomata @Arunendra21

Before any design work starts I want your honest read on this. The idea in one line: an open source menu bar app anyone can download, and it builds your credential automatically while you code. Nothing to run by hand, the CLI's guarantees underneath.

How do you see it? And I'll share the doubts we're chewing on, because they're real:

• Would people actually trust an always-on app from a small project, even open source? Would YOU run it?
• The post-commit question needs a local LLM to be worth anything. The moment an LLM is in the loop, how do we prove code never leaves the machine? Local-only models, but what's the verifiable guarantee, not just the promise?
• Is "open source + reproducible builds" enough of an answer, or does this need something stronger?
• Anything about this that makes you uncomfortable? That's the most useful answer of all.

No wrong takes here. If your reaction is "I'd never run that", say it and say why.

The problem I'm trying to solve: today you have to remember to run redential scan and submit. Most people run it once and never again. The app would make it automatic, opt-in per repo, same guarantees underneath.

Is that a real problem for you, or is running the CLI when you need it fine? And would you keep an app like this running?

[BharadwajKanneveti]

I’m still not completely sure about it, to be honest. I can definitely see the benefit of automating, since the current flow has some friction and I can see why people might stop using it after trying it once.

For me, the part I’m still trying to understand is what would make me personally want to keep the app running. Since GitHub and the existing Redential portfolio already give some visibility into the work, I’m wondering what additional value the continuously built credential would provide for me.

I think the idea becomes much more interesting if it captures something beyond the Git activity itself — especially the context behind the work, like what problem I was solving and why I made certain decisions. That feels like something GitHub doesn’t capture particularly well.

I’d probably be a little cautious about an always-on app initially, especially with a local LLM involved, so I’d want the privacy guarantees to be very clear and verifiable. Personally, I’d probably need to see that additional value in the credential before I’d be comfortable keeping it running all the time.

But I’m definitely interested in seeing how the credential itself would differ from what we already have.

[rudi193-cmd]

Most of what I have set up for Willow is based on crons so the user won't have to think about it.

[jpbelmo]

Two things from a design conversation that belong in this thread.

The credential should say anchored since, and age well. The honest framing for this app: a single scan proves little about the past, but every submitted bundle gets anchored in a public transparency log, and you cannot retro-fabricate what was anchored yesterday. The proof lives in the series, not in any snapshot. So the credential should carry an explicit anchored since [date] and visibly gain weight as the series grows, instead of pretending month one and month twelve weigh the same. Sustaining the series is itself something the candidate demonstrates. This also reframes the cold-start question: what you have on day one is a defended credential plus an anchor; what you have in month twelve is history nobody can fake.

If sessions ever measure response latency, it's soft context, never a hard signal. Latency looks attractive for detecting a coach in the loop, but it measures non-native speakers, slow deliberate thinkers, and bad connections with the same ruler, and it's trivially gameable with uniform padding. Cross-session coherence discriminates better and has none of those problems. Latency can inform, it must not score.

[jpbelmo]

@rudi193-cmd that's a real data point, thanks. Cron plus notification is a lighter trust ask than a resident app: nothing living in the menu bar, just a scheduled scan the user set up themselves and can read in crontab. Maybe that's exactly the v0 shape: the CLI stays the engine, a cron recipe ships in the docs, and the app comes later only if the cron version proves people actually want the automation. How does Willow handle the "it ran and found something worth telling you" moment? That's the part where a bare cron gets awkward and an app starts earning its place.

@BharadwajKanneveti your comment did what I hoped this thread would do: the context behind the work is exactly the part I think GitHub can't show, and it's why the receipts RFC (#13) comes before any app code. On "clear and verifiable guarantees" for the local LLM: agreed that promises aren't enough. What would count as verifiable for you, concretely? OS-level network sandboxing on the model process, reproducible builds, an auditable egress log, something else? Asking because that answer decides real architecture.

[rudi193-cmd]

@jpbelmo Right now it surfaces through the main agent working with the user. A prompt injection for the model at run time, or if is an overnight task, then it surfaces on boot.