Inspiration
Every maintainer who's inherited an abandoned repository knows this problem: the README is stale, the dependency situation is unclear, there are dozens of open issues and no way to tell which ones matter, and somewhere in the backlog there's probably a pull request with a real fix in it that just never got merged. You don't know if the project even still runs. You don't know what reviving it would actually take. So you close the tab.
I wanted to build something that answers that question honestly, not by fixing the repo, but by diagnosing it the way a careful, skeptical engineer would on their first day, and handing back evidence instead of a guess.
What it does
Lazarus is a five-stage, evidence-backed diagnostic pipeline for stale open-source repositories. Point it at a repo and it will:
- Clone a read-only local checkout, no writes, no side effects.
- Diagnose the actual declared runtime and dependencies from real manifest files and CI config, flagging what's obsolete or unverified, distinct from what the README claims.
- Regenerate documentation from the real code structure via static AST analysis, not by copying the existing stale README.
- Triage the entire issue and PR backlog into duplicate/resolved, obsolete, still valid, and valuable-but-stalled-by-inactivity, a category that exists specifically so a real, working, but old and conflicted pull request doesn't get treated as noise.
- Draft a documentation-only pull request, draft mode only, on a fork the operator owns, never touching application source code, never auto-merged.
- Synthesize everything into one Revival Report with a phased human decision checklist, where every claim traces back to a real file, API response, or prior-stage artifact.
It never modifies application source code, never installs dependencies, never merges anything, and never operates on a repository the user doesn't own or control a fork of.
How i built it
I built this stage by stage, directive first: each pipeline stage started as a written SOP, then a deterministic execution script, then real logic verified against a real GitHub repository (WuJie1010/Facial-Expression-Recognition.Pytorch, Python 2.7, no dependency manifest, 40 open issues, one real unmerged fix in PR #95) before moving to the next stage.
Once all five stages worked, I ran the full pipeline end-to-end against two structurally different real repositories, then deliberately audited the entire codebase against a strict standard: every claim must trace to real evidence, every unknown must be stated explicitly, and confidence levels must reflect real evidence strength, not just data presence. That audit found real, fixable gaps, see below.
After correctness was verified, I packaged the project as a real installable Python package with console-script entry points, built a FastAPI layer that wraps the pipeline by shelling out to the real CLI (preserving the same process isolation the pipeline already had internally), and built a React/TypeScript frontend with a live-polling dashboard, a custom WebGL ambient background, and an ASCII-rendered wordmark, with WebGL feature detection and prefers-reduced-motion support built in from the start, not bolted on after.
Challenges i ran into
The hardest problems weren't in the happy path, they were in the places where "evidence-backed" could quietly stop being true.
The most serious: a cross-repository identity check that was too permissive. Under the right conditions, a locally cloned repository could get paired with a different project's GitHub issue/PR data, meaning a report could silently blend evidence from two unrelated projects. I found this through a deliberate adversarial test, fixed it by requiring canonical repository identity binding wherever the calling context actually knows it, and verified the fix by reproducing the exact original attack scenario and confirming it now fails safely with a clear error.
A second, independent audit pass caught a duplicate-issue false positive: a "duplicate of" pattern match was firing on a real issue that was actually about duplicate game data, not a duplicate bug report, which would have silently hidden a genuinely valid issue from a maintainer. I fixed it to require an explicit issue-number reference instead of matching on the phrase alone.
I also had to be honest about a subtler failure mode: a safety-halted PR receipt (missing approval, or a legitimate no-op halt) was being treated as a hard block on the whole synthesis stage, instead of producing the partial report our own spec promised. Fixing that meant making every core input to the final report independently optional, so a partial evidence set still produces an honest, clearly-labeled partial report instead of failing outright.
Accomplishments that I am proud of
The core diagnostic engine has zero third-party runtime dependencies, every finding is deterministic, auditable Python standard library code, not a black box. I verified this literally, by grepping every import across the entire pipeline.
I proved the whole system end-to-end more than once: real draft pull requests created on real forks of both test repositories, a real installed wheel run from a completely different machine directory to prove packaging correctness, and a real API-driven pipeline run watched live through the actual frontend, not just the CLI.
Most of all, I am proud that the audits actually found things. A system that claims to be evidence-backed has to survive someone trying to break it, and ours did, twice.
What i learned
The gap between "this looks right" and "this is provably right" is where the real engineering lives. Several of the bugs i found were things a first pass would never catch, they only showed up because i specifically tested for the failure mode of confident-but-wrong evidence, not just for whether the happy path worked.
What's next for Lazarus
- Wiring
--detail-prmergeability data into the orchestrator's triage stage for richer pull-request evidence. - A lightweight MCP wrapper around the HTTP API, so a conversational AI assistant could trigger a Lazarus run as a tool call on a user's behalf.
- Authentication and multi-tenant run isolation for the API, moving it from demo-safe to production-safe.
- Expanding diagnosis coverage to more manifest formats and CI providers.
Log in or sign up for Devpost to join the conversation.