GraphSloth: auditing 29 abandoned project folders so I don't have to

GraphSloth: auditing 29 abandoned project folders so I don't have to Live demo · Source What I Built My ~/Desktop/Project folder has 29 project folders in it, about 95GB total. I had no idea which ones were safe to archive and which ones I'd regret deleting. Auditing that by hand is exactly the kind of task International Sloth Day exists for, so I built something to do it instead. GraphSloth scans a folder of projects and, for each one, pulls real facts: disk size, git commit age, and (for git repos) a real Graphify structural extraction — real tree-sitter AST parsing, zero LLM cost — giving node/edge counts and the most-referenced symbol. A local Gemma model then reads those facts and returns a verdict: ACTIVE, DORMANT, or ARCHIVE-CANDIDATE, with a one-sentence reason that has to cite the actual numbers, not invent anything. Nothing gets deleted automatically. The output is a static report, and an optional --apply flag only moves archive candidates into a sibling _Archive/ folder, one at a time, asking before every move. Demo Real run against my actual Desktop: 29 folders audited, 10 flagged ARCHIVE-CANDIDATE (29.4G reclaimable if I trust them), 16 ACTIVE, 3 DORMANT. 9 of those were flagged with real deploy signals and automatically kept out of the archive pile, including my own live e-commerce store and a production exam-scoring backend. Caught Lying to Itself All three of these were found by running GraphSloth on my own live, production folders, not a test suite, and each one got fixed the same day I found it. A live store flagged safe to archive. Srijan Saree, a real store with real orders, came back as ARCHIVE-CANDIDATE. The deploy-signal check only looked at a folder's top level; the store's actual code and its .vercel config sat one folder down. Fixed by checking one level into subfolders when the top level isn't a git repo itself. One busy repo almost spoke for 34. OSS, 26.8G holding 34 separate git clones, was one busy clone away from being called ACTIVE as a whole. My first nested-repo fix picked whichever single clone was touched most recently and judged the entire 26.8G folder by it — only 10 of the 34 clones had actually moved in the last 30 days. Fixed by detecting a multi-repo container and reporting the real distribution instead of one point sample, with a hard cap: a container with stale repos among its recent ones is never called ACTIVE. A raw exception almost shipped as a verdict. A single Ollama timeout, right after a restart, nearly produced a report with the literal text [Gemma call failed after 3 attempts: timed out] sitting in a folder's "reason" field. Turned out the model emits a chain-of-thought before its answer, and a complex fact block pushed that past a 300-second timeout on CPU-only inference. Fixed by passing think: false and capping num_predict — the same call that used to hang indefinitely now returns in single-digit seconds — plus a check that catches and retries that shape of error before anything publishes. When It Actually Died Partway through the real run, the OS killed the process. Not a bug in my code — Gemma sits at about 8GB resident in RAM, and my laptop ran low on memory in the background while the audit was running. 27 of 29 folders were already done, but they only existed as text in a log file. I had to write a second script just to parse completed verdicts back out of stderr output. That's exactly the problem Temporal workflows exist to solve, so I rebuilt the audit loop as one. temporal_audit.py runs the same per-folder audit, but each folder's result is a durable activity instead of a line in a Python list. I proved it, not just claimed it: started a 5-folder run, let 2 finish, kill -9'd the worker process mid-activity, confirmed with temporal workflow describe that the workflow was still alive on the server with its 2 results intact, restarted the worker, and watched it pick up from folder 3 instead of starting over. (Temporal's workflow code has to be deterministic, so it forbids filesystem and subprocess access in the workflow definition itself. That meant splitting the workflow logic from the activity implementation into two files: ta_workflow.py stays sandboxed and clean, ta_activities.py does the real I/O and is only imported by the worker process.) The Bug I Almost Shipped My first version scored folders mostly on git commit age. That's wrong for anything that's deployed and stable: a live backend I rarely need to touch would look just as "stale" as something I actually abandoned a year ago. Several of my own folders are live production services, and under the first version they were one unlucky LLM response away from getting flagged for archiving. So GraphSloth checks for cheap, local, no-network deploy signals — vercel.json, .vercel, docker-compose.yml, render.yaml, fly.toml, a live URL in the README — before Gemma ever sees the folder, and the result is a hard rule in code, not something I'm hoping the model remembers: a folder with any deploy signal can never come back as ARCHIVE-CANDIDATE. It's capped at DORMANT and shown with a visible warning instead. This isn't proof a service is actually live, so the flag means "check this yourself," never "it's definitely fine." Why Open Innovation Matters Zero cost. Graphify's extraction is local tree-sitter parsing with no API key. Gemma runs locally through Ollama. Auditing dozens of gigabytes of my own code costs nothing. Privacy. Several of these folders are private client work. None of their contents leave my laptop. Real evidence beats guessing. Most "clean up your projects" advice is pure vibes based on file dates. Grounding the verdict in an actual structural graph of the code is the same idea that worked for OneGraph, an MLH Hack Day project I built the week before this challenge: an LLM reasoning over real graph facts is more trustworthy than an LLM reasoning over nothing. Code CodersAcademy006 / graphsloth Graphify + local Gemma 4 (+ Temporal) audit of abandoned project folders, Hacktoberfest Week 3 GraphSloth Live demo → A lazy-friendly audit of your abandoned project folders. Built for the Hacktoberfest Open-Source AI Challenge: Week 3 ("Slow and Steady"). Most developers have a ~/Desktop/Project folder full of things they built, half-finished, and never looked at again. Deciding what's safe to archive is tedious enough that nobody does it. GraphSloth does it for you, overnight, and cites real evidence instead of guessing. Real run against the author's own Desktop: 29 folders audited, 10 flagged ARCHIVE-CANDIDATE (29.4G reclaimable), 16 ACTIVE, 3 DORMANT. 9 of those were flagged with real deploy signals and kept out of the archive pile automatically, including a live e-commerce store and a production exam-scoring backend. How it works For each top-level folder: Disk size — du -sk. Git facts — last commit age, branch, dirty state. Checked one level into subfolders too, for folders that hold a git repo rather than being… View on GitHub Prize Categories Best Use of Gemma, Best Use of Temporal.