# The Ghost in the Tauri Repos

There is a desktop app in my portfolio that I would have sworn was alive. It has a signed macOS build that launches in under a second. It has a README with a hero screenshot, a feature list, and install instructions that still work. Double-click the icon and a native window opens, the interface renders, the buttons do what the labels promise. Every surface you can inspect says: finished software, maintained software, software someone stands behind.

The commit log says something else. The last meaningful change landed months ago. The test suite has not run since then, because nothing has triggered it. No issue has been opened, no branch has moved, and if I am honest, I have not launched the app myself for anything but the screenshot. The project is not broken. It is not abandoned in any way you could point to. It is a ghost: present, plausible, and empty.

I build a cluster of these. Tauri apps, meaning a Rust backend and a web frontend compiled together into a native shell. I like the stack, and I keep reaching for it. Which is exactly why I have had to learn, the hard way, that desktop apps are the portfolio's best liars.

## The most convincing corpse

Every kind of repository decays, but they decay at different rates of visibility. A deployed web app dies loudly. The certificate expires, the hosting bill lapses, a dependency of the platform shifts underneath it, and one day the URL serves an error page to anyone who looks. A library dies almost as loudly: its dependents pin away from it, its CI badge goes red, its issue tracker fills with unanswered questions. A script barely pretends to be alive in the first place; nobody mistakes a dusty script for a product.

A compiled desktop app dies silently, because it does not depend on anything that can visibly fail. The binary I built last winter is the same bytes today. The Rust backend compiled once, and it stays compiled. The web frontend was frozen into the bundle at build time; no CDN can break it, no framework update can bitrot it in place, no server can go down under it. The app is a preserved moment, embalmed at the instant of its last successful build, and embalming is precisely the technology of making the dead look well.

This is not an accident of Tauri; it is the entire point of shipping native. We choose desktop apps because they keep working without us. The property that makes them good software is the property that makes them terrible witnesses.

## Four instruments of the lie

Look at what a desktop repo presents to an observer, including the observer who wrote it.

The binary is the strongest signal of effort that exists in a portfolio. Anyone can push a half-finished web demo. A notarized, installable, double-clickable app implies a gauntlet was run: build toolchains, code signing, packaging, the platform's whole bureaucracy of legitimacy. The artifact radiates completion. Nothing about it radiates recency, but completion and recency blur together when you are skimming.

The README was written at the moment of peak momentum, usually the week of the first release, when I knew the project intimately and believed in it completely. It has not been wrong since, exactly. It has just stayed frozen at maximum confidence while the truth drifted out from under it.

The screenshot is the README's accomplice. A screenshot of a web app can go stale against the live site; someone might notice the mismatch. A screenshot of a desktop app cannot be caught out, because the app it depicts still launches and still looks like that. The screenshot is perfectly, uselessly accurate forever.

And the demo, the live walkthrough, is the closer. I can open one of my Tauri apps today and give a convincing two-minute tour, and nothing in that tour reveals that the tour is the only use the app has seen this quarter. The demo proves the software works. It proves nothing about whether the software lives.

A library cannot assemble this act. Its liveness signals are structural and external: downloads, dependents, issues, the red or green of CI. A desktop app's signals are all internal and all self-authored, and every one of them was minted on the project's best day.

## Liveness is a claim

The reframe that finally helped me: liveness is not a property you can read off a repository. It is a claim the repository makes, and different repos make it with different degrees of persuasiveness. A script mumbles the claim. A library states it and submits to cross-examination. A desktop app makes the claim under oath, in a good suit, with exhibits.

Once you see liveness as a claim, the question becomes what would count as evidence, and the evidence turns out to be boring and unglamorous, which is how you know it is the real thing. Commit momentum: not the date of the last commit, but the shape of activity over time, whether the project is being pushed or merely poked. Tests that run because changes happen, not tests that pass because nothing does. Real use, which for a local-first desktop app is the hardest evidence of all to gather, and the most honest: did I open this app this month for a reason other than checking on it?

None of that appears in a screenshot. All of it is what the screenshot is standing in for.

## The instrument

This is the problem GithubRepoAuditor exists to work on. It is a public tool (github.com/saagpatel/GithubRepoAuditor) built on a premise I have written about elsewhere: a portfolio of well over a hundred repositories is not something you can hold accurate beliefs about by memory, because repositories drift and misreport their own state. So you audit them against evidence instead of against their surfaces, and you [sort them into lifecycle tiers](/verdict-machine), from actively developed down through dormant to the tier that motivated this essay: zombie, a repo that looks alive and is not.

The mechanics matter less than the posture. The auditor does not read READMEs and believe them. It looks at what cannot be minted on the project's best day: when commits actually landed and in what rhythm, whether the machinery of maintenance shows recent motion, whether the signals that require ongoing effort are present or merely the signals that require one past effort. A polished artifact scores nothing on its own. That single design decision is aimed straight at the desktop apps, because they are the population for which surface and substance diverge the most. When the auditor runs across the portfolio, the Tauri cluster is reliably where the zombie tier finds its residents. Not because those projects were worse. Because they were finished enough to fake it.

I will be honest about the instrument's limits. Commit momentum is a proxy, and proxies can be gamed by the person holding them; I could churn cosmetic commits and manufacture a pulse. Local use is nearly invisible to any tool that reads git metadata. And the auditor cannot distinguish a zombie from a genuinely completed project that needs nothing, which is a real category. Some software is done the way a chair is done. The tiers force the question; they do not answer it for me.

## The discipline

So the discipline, stated plainly: treat every liveness signal you could have created in a single sitting as inadmissible. The binary, the README, the screenshot, the demo were all minted once. Evidence of life has to be evidence of ongoing expenditure: commits with momentum, tests exercised by change, use that leaves traces. When the polished surface and the evidence disagree, the evidence wins, every time, especially when the repo in question is one you are fond of. Fondness is how ghosts get fed.

And then the second half, which is harder: once a ghost is identified, say so. Mark the repo dormant. Amend the README's tense from present to past if the past is where the project lives. A portfolio full of accurately labeled dormant projects is more trustworthy than one where everything claims to breathe, because a reader who catches one zombie stops believing the living.

The app I opened this essay with is now labeled what it is. The binary still launches in under a second, the screenshot is still accurate, and the tier next to its name says dormant, because the evidence said so and I have stopped arguing with the evidence. It was a good project. It may be a good project again; dormant is a state, not a verdict. But until the commits move, it does not get to claim it is alive just because it still knows how to open a window. That trick is the whole problem. Ghosts are excellent at doors.