DevHibernate: My Side Projects Needed a Nap, Not Another SSD

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I have a perfectly reasonable number of side projects.

Unfortunately, each one seems to have invited an entire dependency ecosystem to live on my laptop indefinitely.

The project I haven't opened in a month still has its node_modules. The experiment I was “just trying quickly” has apparently signed a long-term storage agreement. Meanwhile, my laptop is being asked to fund everybody's accommodation.

That is the idea behind DevHibernate: put a shelved development project to sleep without throwing away the work you might return to.

The intended workflow is deliberately small:

1. Select a development folder.
2. Inspect a local inventory of supported projects.
3. Mark a project as shelved and review an AI-assisted hibernation assessment.
4. Approve removal of selected, supported dependency artifacts.
5. Keep the source and configuration in place, with a guide for returning later.

For the hackathon, the scope is standalone npm projects on macOS. Python environments, background processes, Xcode resources and encrypted archives belong to later phases. “One more feature” is how this application would acquire its own abandoned dependency neighbourhood.

The important preservation rule is that hibernation is not project deletion. Source, Git history, lockfiles and configuration outside the explicitly approved artifact stay in place. A supported target with protected entries or an incomplete inventory is blocked for review.

And the AI does not get to read my .env.

The Phase 1 design keeps the scanner metadata-only: filenames are mapped to recognized categories, sizes are measured, and project IDs replace paths in the model request. The model does not receive source code, configuration contents or credentials. This boundary is a testable implementation requirement, not a request politely tucked into a prompt.

Demo

The demonstration should follow a disposable but runnable project through the whole journey: inspect the plan, remove approved dependencies, verify the source and a fake .env fixture remain unchanged, then reinstall dependencies and run it again.

Code

https://github.com/CynthiaWahome/dev-hibernate

How I Built It

The planned stack is React and TypeScript for the interface, a local Express service for filesystem operations, SQLite for the operation record, and Gemma 3 1B through Ollama for the assessment.

I separated the responsibilities because the sentence “the model thought it looked disposable” is not an acceptable deletion policy.

Collect evidence without opening project files

The collector recognizes supported project markers and artifact directories using filesystem metadata. It records completeness and blockers rather than treating an unreadable directory as an empty one.

An old timestamp does not prove a project is abandoned. For the first version, the user explicitly marks a project as shelved. Active projects can be pinned.

Give the local model a restricted inventory

The model's job is to organize the available evidence into a hibernation assessment and a restart checklist. Inputs use generated IDs and fixed categories rather than arbitrary project text or absolute paths.

Structured output and Zod validation constrain the response. Code rejects unknown candidate IDs and recommendations that conflict with preservation rules. The model has no shell or filesystem tools.

Review before mutation

The review screen needs to show the exact local target, estimated size, preservation boundary and reinstall caveats. Only an approved plan can reach the executor, which rechecks its conditions and records the outcome.

Filesystem changes are not database transactions. A partially failed deletion must be reported as partial, not covered up by an optimistic green tick.

Leave a route back

The resume guide records what was removed and the package-manager evidence available. Required runtime versions stay unverified unless the user supplies them. Reinstallation may require internet, registry access and package scripts; it is not a guaranteed undo button.

One real implementation lesson: The first full end-to-end run exposed two bugs that silently broke the AI step. The model call aborted at a 30-second timeout, but structured-output generation on gemma3:1b actually takes 35–100 seconds, so every plan came back as model_unavailable — the fix was raising the timeout to 120s after measuring the real latency. Worse, the policy overlay read project.userShelved while the column is user_shelved, so it quietly blocked every project even when it was shelved. Both were invisible until the chain ran for real. Now a preservation test — delete node_modules, assert .env and source survive — runs on every CI push so they can't regress.

Why Does Open Innovation Matter?

A tool inspecting local development projects has a good reason to keep its analysis local. Project inventories can reveal client names, internal work and the shape of someone's development environment, even without file contents.

Running an open-weight model locally gives this design control over where that assessment happens. It also lets me evaluate another model using the same fixture cases instead of tying the product to a single hosted response format.

There are no per-token hosted API charges in this local setup. That does not make hardware, electricity or model downloads free, and reinstalling dependencies may still need a connection.

The open pieces matter because they support a tool I can inspect, adapt and run on my own machine. The model's weights have their own terms; they are not automatically covered by the application's source-code licence.

The Lazy Payoff

I ran the full flow on a disposable fixture — one standalone npm project with a multi-package node_modules. I have not benchmarked against a manual baseline yet, so these are what the tool actually did, not a time-savings claim.

Measure	Observed result
Logical dependency bytes removed	5,500,729 bytes (~5.3 MB) on the fixture
Model recommendation	hibernate — 1 candidate selected, 9-step restart checklist
Local model latency (plan)	~35–100s on gemma3:1b (structured output)
Observed free-space change	Not separately measured — logical_bytes is an estimate, not physical disk freed
Reinstall and successful start	Not yet benchmarked
Protected fixture preservation	Passed — node_modules removed; .env, source and package.json intact (checksum-verified, automated test green)

The useful outcome was a reviewed, reversible cleanup: the model proposes, a deterministic policy validates, and the executor only ever touches the one approved node_modules — the project's source and .env are provably left alone.

My goal was not to become more disciplined about cleaning every project. It was to make putting a project away require less effort than continuing to pretend I was about to finish it.

Prize Categories

• Best Use of Gemma: gemma3:1b runs locally through Ollama and produces the hibernation assessment — a structured recommendation (hibernate / skip / blocked), the selected removable candidates, evidence, and a restart checklist. Its output is constrained by a JSON schema and then re-checked by a deterministic policy overlay, so the model advises but never has the final say on what gets deleted.