This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.
What I Built
I built Doze Sort for a small pile of notes with filenames like note-03.md. Opening each file to decide where it belongs is the part I wanted to hand off.
The app uses an open-weight model to compare the contents with topic descriptions. It makes a plan first. After I inspect that plan, one batch action creates copies in the proposed folders. A low score or close result goes to _review. Exact byte duplicates point to one canonical copy.
I chose to keep the original pile. That means this is an organized working copy, not a tool that empties a messy folder. It also means a bad category does not lose the source note. Undo moves the completed run into recovery and retains its files.
The intended user is someone with a small English Markdown or text inbox who wants help filing it. The browser demo is restricted to the fictional files included in the repository; the CLI accepts an inbox and topics chosen by the person running it. It never scans other folders in the background.
I started this new project and repository on October 20, inside this week's entry period. The sorter, copy/recovery logic, UI and example notes are new. I reused an installed personal Python environment and cached model weights.
Demo
Watch the 35-second walkthrough using GitHub's Download raw file button. I assembled it from real captured browser states; it is not a continuous recording.
The demo has three actions: make a plan, create organized copies, and undo the run. The actual test produced 12 unique copies from 14 files. Two duplicate originals referenced canonical copies, and two uncertain copies went into _review. Undo retained the run in recovery with zero files deleted.
The local app runs on the laptop at a loopback address. The README includes setup and offline startup instructions. I checked the 375px layout with no horizontal overflow. The browser demo does not let a visitor upload files or supply arbitrary paths.
Code
MIT source, original notes, tests and recorded results
The examples cover cooking, gardening and travel. They are fictional original material. No client or employer files, credentials, dependencies or model weights are committed.
How I Built It
all-MiniLM-L6-v2 is the content classifier. It has Apache-2.0 open weights, and I pinned its revision. Sentence Transformers runs it on CPU, producing normalized 384-dimensional embeddings for each note and topic description.
Cosine similarity chooses a topic only when the top score is at least 0.30 and the top-two gap is at least 0.06. Those thresholds are heuristics, not probabilities. The model can still miss a mixed-topic note. Deduplication is separate: only identical SHA-256 bytes count as duplicates. Similar meanings never cause notes to be merged.
The copy engine checks the source filenames and hashes again before applying a plan. A changed inbox needs a fresh plan. It writes into a staging directory before exposing the completed run. Reapplying the same plan stops without making another copy. Undo checks for edited or unexpected output files and leaves the run in place if it finds them.
Seven behavior and integration tests passed, including stale input, original byte preservation, duplicate references, replay prevention, edited or extra output, symlinks, path checks, token rejection and recoverable undo. These checks assume a stable local filesystem; I have not built a service for hostile concurrent writers. A failed filesystem operation may leave a staging directory for manual inspection.
I ran cached inference with offline flags. Unsupported files are skipped, while empty text, non-UTF-8 content and notes above the model token limit are rejected. Only visible top-level .md and .txt files are processed, with no recursion. Plans contain local paths and excerpts, so a person using private notes should keep the plan private too.
Why Does Open Innovation Matter?
After caching the weights, I can classify notes without an internet connection or a per-file API charge. The text stays on the computer running the model. The app's page loads local assets and has no analytics, remote fonts or background folder watcher.
The policy is inspectable as well. I can change the topic descriptions or the score threshold and run the same example inbox again. A different embedding model could replace MiniLM. The exact-duplicate and recovery logic would remain available to inspect independently of that choice.
Open weights make this useful on a small local workflow, although installation, model storage and running the laptop still have costs.
The Lazy Payoff
I used the included 14-file fictional inbox to run the full plan, copy and undo sequence this week. All 14 original files remained byte-identical, the recovered run was preserved, and no files were deleted. One action produced the categorized snapshot instead of filing each note separately.
The complete diagnostic report records 13 of 14 intended outcomes. The failure is a note about baking, herb pots and a train: the model chose cooking when I wanted it held for review. I kept that result. Inspecting the plan still matters, and the CLI lets me change a wrong proposal to _review before applying it.
Warm planning had a median of 14.92 ms across five runs, excluding model loading. First planning took 25.40 ms and copying took 1.87 ms. These are local machine timings on a tiny author-written set. I did not measure a human filing session, test a real personal inbox or conduct an external user study, so I cannot claim a number of minutes saved.
The tested convenience is a batch plan with recoverable output. Choosing useful topics, handling bad suggestions and managing stored snapshots remain my responsibility.
Top comments (0)