CryptGit Studio：在程式碼造成問題前找出可能已棄用的部分

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 4, "Ghost in the Machine".

What I Built

The Problem: The Hidden Risk of Deleting "Unused" Code

Every software repository has a past.

Functions get replaced, features become obsolete, developers move on, and forgotten implementations remain buried inside Git history.

Eventually, someone discovers a function that appears to have no references and asks a seemingly simple question:

Can I safely delete this?

But Python makes that question complicated. Dynamic imports, reflection, runtime registration, plugins, and external callers can make apparently unused functions important.

A basic reference search cannot establish that code is safe to remove. And an AI model confidently saying something is unused is not proof either.

I wanted to build something that could investigate those forgotten pieces of code instead of blindly deleting them.

That became CryptGit Studio — a local-first software archaeology tool that combines deterministic Python analysis, Git history reconstruction, evidence verification, and open-weight AI reasoning to help developers understand potentially unused code.

The central idea is simple:

Evidence before deletion.

CryptGit does not automatically remove code. It gives developers the information they need to investigate and make informed decisions.

The Core Pipeline

CryptGit Studio uses a combination of deterministic engineering and open-source AI:

1. AST-Based Analysis: Inspects Python repositories and identifies potentially unreferenced module-level functions.
2. Git History Archaeology: Examines historical commits to understand when functions appeared and when they were last modified.
3. Deterministic Evidence Verification: Validates historical observations using commit information, source files, symbols, line ranges, and AST digests.
4. Local AI Reasoning: Uses Qwen2.5-Coder 3B to interpret findings, explain uncertainty, and suggest what deserves human investigation.
5. Human Review: Allows developers to record review decisions and notes without automatically deleting code.
6. Persistent Investigation History: Uses Appwrite TablesDB to store scan records, findings, and review decisions.

Demo

🎥 Watch the CryptGit Studio walkthrough:

https://youtu.be/1wWnhyCewFE

🌐 Live Application:

https://cryptgit-studio.onrender.com

The hosted application uses a synthetic Git repository so visitors can explore the workflow without providing their own source code.

The full local workflow supports repository analysis and Ollama inference on the developer's machine.

Code

Technology Stack:

• Python 3.11+
• Streamlit
• Python AST
• Git
• Ollama
• Qwen2.5-Coder 3B
• Appwrite TablesDB
• Sentry
• Render

The project is organized into modular components for repository analysis, Git history, evidence verification, AI reasoning, telemetry, persistence, and reporting.

Run It Locally

Clone the repository:

git clone https://github.com/Droid-Faizan/cryptgit-studio.git
cd cryptgit-studio

Install the project:

python -m pip install -e .

For local AI inference, install Ollama separately and pull the model:

ollama pull qwen2.5-coder:3b

Launch the interface:

streamlit run streamlit_app.py

How I Built It

The project was developed as a modular Python application, keeping deterministic analysis separate from AI interpretation.

1. Deterministic Analysis Before AI

I deliberately avoided making the LLM responsible for detecting unused code.

The Python AST analyzer identifies candidate functions, while the Git history component reconstructs their available historical context.

This separation matters because AI should interpret evidence, not manufacture it.

2. Evidence Verification

One of the most important components is the evidence verification engine.

It validates historical function observations against the actual Git repository, checking information such as:

• Commit identity
• Source file
• Function symbol
• Historical line range
• Normalized AST digest

The verification layer returns explicit statuses rather than pretending every historical observation is valid.

3. Open-Weight AI With Ollama

For the AI reasoning component, I used Qwen2.5-Coder 3B through Ollama.

The model runs locally and receives structured findings rather than unrestricted access to the repository.

Its job is to explain uncertainty, identify alternative explanations, and recommend human investigation.

I also added response validation and grounding safeguards because a convincing AI explanation can still be wrong.

4. Appwrite TablesDB Integration

I integrated Appwrite as the persistence layer for investigation metadata.

It stores:

• Scan records
• Finding metadata
• Evidence verification statuses
• Human review decisions and notes

I tested the integration through a dedicated smoke-test workflow.

The results were:

Source code, full prompts, diffs, and credentials are not uploaded to Appwrite.

5. Sentry Agent Tracing

I also integrated Sentry as an optional, opt-in tracing layer to make the investigation pipeline easier to observe and debug.

The instrumentation includes spans for:

• Repository scanning
• Python AST analysis
• Git history operations
• Evidence verification
• Ollama inference
• AI response validation
• Report generation

The idea is to understand where time is spent, identify failures, and investigate how the different stages of the AI-assisted workflow behave.

Privacy was important here too. Sentry is disabled by default and requires explicit opt-in and a configured DSN. The telemetry configuration disables default PII collection and avoids attaching source code, full prompts, model responses, diffs, absolute paths, or credentials.

6. Testing and Validation

I built a regression test suite around the analysis, history, evidence verification, AI reasoning, integrations, and application behavior.

The latest reported test run completed with:

• 52 tests passed
• 1 test skipped

I also tested local Qwen inference successfully. One accepted inference run completed with zero grounding errors.

Why Does Open Innovation Matter?

For CryptGit Studio, open innovation is directly connected to developer privacy and control.

A software repository can contain proprietary algorithms, internal business logic, credentials, and sensitive implementation details.

Sending an entire repository to a closed AI API just to identify potentially unused functions would introduce unnecessary privacy concerns.

Using an open-weight model through Ollama gives developers more control over their AI infrastructure.

It makes several things possible:

• Local inference: Run Qwen2.5-Coder 3B on your own machine.
• Privacy: Keep source code and diffs local during analysis.
• Model control: Change the model through local Ollama configuration.
• Transparency: Inspect the analysis, verification, and reasoning workflow.
• Less vendor dependency: The core analysis does not rely on a proprietary AI API.

The deterministic analysis and verification components also remain useful when Ollama is unavailable.

Appwrite and Sentry are optional integrations rather than requirements for local analysis.

The goal is not to replace closed AI with another dependency. It is to give developers more control over how their code is inspected and interpreted.

My Agent Session

I used GitHub Copilot Agent during development to help implement the modular architecture, work through debugging issues, refine the AI reasoning pipeline, and improve test coverage.

I followed an iterative development process: implement a component, run the tests, inspect the results, and then move to the next part.

The Spirit of It

I interpreted Ghost in the Machine through the forgotten history of software.

Every repository contains traces of decisions made by developers who may no longer be working on that project.

Some functions are genuinely obsolete. Others may still be important in ways that are difficult to see.

They are the ghosts of previous implementations, still living inside the codebase.

CryptGit Studio is my attempt to bring those traces back into view.

Instead of treating forgotten code as something to erase, I wanted to create a tool that could investigate its history, verify its evidence, and help developers understand why it might still matter.

Not every ghost needs to be removed. Some need to be understood first.

Prize Categories Targeted

• Best Use of Render (Featured Category): Deployed the public Streamlit application and synthetic repository demonstration on Render.
• Best Use of GitHub Copilot (Partner Category): Used GitHub Copilot Agent throughout the modular implementation, debugging, and testing workflow.
• Best Use of Sentry Agent Tracing (Partner Category): Implemented opt-in Sentry tracing across the analysis and AI-assisted workflow, with privacy-conscious instrumentation.

For the Sentry category, I am working with the tracing instrumentation in the codebase; I will include an actual Sentry trace screenshot in the submission once I verify trace delivery in the dashboard.

CryptGit Studio — Understand your code before you remove it.

Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.

Feedback, suggestions, and contributions are welcome!