This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.
What I Built
FileNap is a local file-planning app for a small pile of receipts, notes and saved reading. Gemma reads short previews and proposes destinations. Each proposed move comes with a reason and an exact quote from the file. You review the plan, select the moves to approve, and keep a record that supports undo.
The chore it aims to reduce is opening files one by one to decide where they belong. The intended user is someone with a small inbox to sort who still wants to check the decisions. This prototype handles up to 16 files in one plan; it does not reorganize an entire drive.
Demo
Watch the recorded local demo.
The recording uses 12 fictional documents. Gemma proposed nine moves, kept a checklist in place and left two files for review: an ambiguous document and a deliberate prompt-injection example. After approval, the nine files moved into Receipts, Notes and Reading. Undo returned them to the inbox. A separate filesystem check confirmed that all 12 original SHA-256 hashes were restored.
Planning took 89.6 seconds on an Apple M4 Mac with 32 GiB of memory. The 42.6-second edit removes most of the model wait and slows the review steps. The same page includes the 111.3-second full recording at its original timing, with English captions for both versions.
These are fictional test documents, not evidence of accuracy on personal files or time saved in everyday use.
Code
Source code, tests and run instructions.
The application is a new Python project started during this week's build window. It uses the standard library, a local Ollama runtime and a browser interface. The application code is MIT licensed; model weights are not redistributed.
How I Built It
Gemma supplies the content-based decisions. File names such as paper_001.txt do not tell the app whether a document is a receipt, a note or something to read. The model receives the selected names, text excerpts, folder goal and permitted destinations, then returns a structured plan.
The recorded run used a cached Gemma4 11.9B Q4_K_M model with thinking disabled. Its manifest and weight hashes are documented in the README. The public Ollama tag had changed by the time of verification, so the shared tag name alone does not reproduce these exact cached bytes.
The file-operation code checks model IDs, destinations, source quotes and the saved file state. Applying a plan requires approval. Moves preserve existing destination files, and undo leaves a conflict visible if a moved file has changed or its original name has been recreated.
An undo-collision test caught a bug where the journal could report an incomplete undo as finished. That case now preserves both files, reports the conflict and supports retry. The final 19 tests passed on macOS and Linux/WSL2, including interrupted moves, edited files, collisions and local HTTP boundaries.
A correct quote can still accompany a wrong classification. FileNap keeps review in the flow. It is a working prototype, and its recovery tests do not cover every possible filesystem race.
Why Does Open Innovation Matter?
The open-weight model lets this project run its inference locally with a documented model artifact. FileNap's client accepts only a loopback model endpoint, does not follow redirects or use environment proxies, and has no hosted fallback. Development used Ollama with cloud features disabled and an already-cached model, without an inference API key.
Open source also makes the decision boundary inspectable: the prompt, validation checks and code that moves files are in the repository. The model makes suggestions; the application records approved actions. Someone adapting the project can examine both parts before trusting it with a folder.
Prize Categories
Best Use of Gemma.
AI assistance: Codex assisted with implementation, tests, demo preparation and this submission draft. The results above come from local test and recording evidence. No personal documents or private agent-session transcript are included.
Top comments (0)