DEV Community: EazyHood

SweepSheet: turn cleanup voice notes into reviewed counts

EazyHood — Wed, 07 Oct 2026 14:26:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

A cleanup has two different jobs: picking things up and keeping track of what was collected. SweepSheet puts the bookkeeping after the outdoor part.

Use your usual voice recorder to leave a short note: “Three plastic bottles and two cans.” Put the phone away. When you’re back, import the recording into SweepSheet. An open speech model transcribes it on your device, and a small parser proposes quantities in six categories. Listen, correct anything necessary, and confirm. Only then do the numbers enter your notebook and CSV.

The person I designed for is someone keeping the tally for a small cleanup, with several voice memos to turn into a table. This is a working prototype for that task, not a report of a cleanup I have already conducted. The examples are synthetic speech and are labeled that way throughout.

The most revealing test was a mistake. The sentence “Twenty three wrappers and twelve cans” came back as “23 rappers and 12 kids.” SweepSheet did not try to rescue it with another model. It left the counts for a person to enter after listening.

That decision shapes the whole application: speech recognition can help with transcription, but it does not get to approve the record.

Demo

Open SweepSheet — no account or API key needed.

A real browser run with a clearly marked synthetic recording. The total is five because one note has been confirmed; the other two are still pending.

Choose Try the example notebook, then open Along the canal. The initial example transcript comes from the saved model test. Transcribe again runs Whisper on your own device; the first use downloads the model.

Play the note and check 3 plastic bottles + 2 cans. Confirm: the total becomes 5.
Review By the footbridge: 4 wrappers + 6 cigarette butts + 1 glass bottle. Confirm: 16 in total.
Open An uncertain count. Its transcript says “Maybe 4 or 5 rappers.” The app holds the proposal; it adds nothing.
Correct a confirmed quantity and explain why. The total changes by replacement, while the previous quantities remain in the review history.
Download the confirmed CSV and the JSON review history. The latter includes the audio file’s SHA-256 identifier, original model output and corrections, but not the audio bytes.

Uncertainty stays visible. Opening this note does not change the confirmed total.

Your own short audio files work too. Keep them below 60 seconds and 10 MB. A printable field card lists the six categories and a short recording example. There is no requirement to keep this app open outdoors or rely on a web recorder with a locked phone.

Code

Source, setup and evidence on GitHub · All ten test inputs and observed outputs

The app and repository were started on October 7 for this challenge. The application code is MIT licensed. Model and library licenses are credited separately in the README.

How I Built It

The pipeline is small enough to inspect:

Audio file → browser decoding → Whisper tiny.en in a worker
           → editable transcript → conservative count proposal
           → explicit human confirmation → totals and CSV

I used Transformers.js 3.8.1 and the quantized Xenova/whisper-tiny.en ONNX conversion, pinned to revision 79fb389fc764e7c395bd330e9531d9d32ada7049. The browser runs inference through ONNX Runtime WASM. A worker keeps that computation away from the interface. The app stores recordings, transcripts and review history in IndexedDB; there is no transcription server or application backend.

The parser supports exact quantities in six categories. It holds corrections, vague amounts, negation and unsupported numbered categories. “Bottles” alone needs a material. The parser does not silently repair “rappers” to “wrappers.” These are inspectable, intentionally limited rules, not a claim to understand every sentence.

Every imported note starts pending. Exact-byte reimports are detected with SHA-256, so importing the same file twice does not double the tally. Corrections replace a note’s quantities instead of adding them again. Excluded notes remain available for reference. The CSV contains confirmed records only; the JSON also retains pending and excluded notes. Spreadsheet-sensitive text is escaped.

What the tests actually showed

I generated eight short spoken fixtures locally with Microsoft Zira Desktop, plus digital silence and deterministic white noise. The full method distinguishes synthetic speech, CPU inference and browser execution.

Test group	Observed result
Four unambiguous count sentences	Three produced the intended quantities; one was held after a recognition failure
Four correction, uncertain, vague or not-collected sentences	All held for manual review
Silence and white noise	Neither proposed counts; noise was transcribed as “(water splashing)”

The noise result matters too: even a speech model can invent a plausible description. Nothing about that output establishes that there was water, much less collected litter.

The tests also check that pending and excluded notes never affect totals, corrections retain the earlier values, invalid quantities are rejected, and CSV text cannot become a spreadsheet formula. These checks protect the recording workflow; they do not establish outdoor ASR accuracy.

The current limits are practical. It is English-only. Browser audio-format support varies. Model preparation needs internet, and offline page reload is not supported in this version. Browser storage can be cleared, so keep original recordings and export your work. Wind, real voices, accents and mobile performance still need field testing. I have not measured a reduction in screen time or claimed environmental impact from these example counts.

AI assistance: Codex substantially assisted with implementation, tests, documentation and this write-up. The synthetic demo voice is disclosed separately. No field experience, interviews or user metrics have been invented to fill in the story.

Why Does Open Innovation Matter?

The useful open component here is the transcription model, not a logo beside a text field. Without it, the user must type the recording into the notebook. With it, audio can be transcribed on the same device, without uploading cleanup recordings or obtaining an inference API key.

The pinned weights and readable pipeline also make the failure above reproducible. Someone can try another open speech model against the same WAV files, or adapt the parser to another cleanup vocabulary, while keeping the confirmation rules intact. The application does not depend on a remote provider continuing to offer a particular model or pricing tier.

A closed API could also transcribe these notes. The reason to use open weights is control over where inference happens and the ability to inspect and replace the component. It does not make recognition magically reliable.

Cleanup logging itself already exists—Clean Swell is one example—and a voice memo plus a spreadsheet is a reasonable manual alternative. SweepSheet’s contribution is narrower: keep the recording beside a proposed tally, make uncertainty visible, and preserve what changed after review. The next useful test is taking that complete workflow to a real cleanup and finding out whether the bookkeeping is actually easier.

A mano: remember the place, find the thing

EazyHood — Fri, 02 Oct 2026 13:48:00 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built A mano around a practical problem affecting Lucía, a designer who works from home. Lucía is a pseudonym for a real person who prefers to keep her identity private.

She sometimes remembers what an object does more easily than its name or where she stored it. Connecting a laptop to a television becomes a search for the thing that puts the computer screen on the TV, rather than for “USB-C to HDMI.”

A mano connects that remembered purpose to a saved record. Each object has a name, room, precise location and optional description. Ordinary keyword search works immediately. An optional open-weight model runs in the browser and finds additional matches from descriptions of what someone needs to do. It suggests existing records; it cannot invent locations.

The useful result is deliberately simple: an editable card saying where to look. Users can update a location after moving an object, mark favorites, filter rooms and export a backup.

The public demo contains ten synthetic records, separate from personal collections. Its adapter example reproduces a technically tested search; it is not evidence of Lucía's possessions, feedback or measured time savings.

Personal records stay in the browser, without synchronization or encryption. The model needs an initial download and can return incorrect suggestions. Objects must first be recorded, and their locations kept current. Those limits remain visible alongside the working demo.

The Spanish interface uses a compact catalogue layout, self-hosted Archivo and original SVG objects. Card transitions preserve context when filtering, while keyboard navigation and reduced-motion preferences remain supported.

Demo

Open A mano.

Try this route:

Keep Explorar demo selected. Search estuche gris; the adapter appears because that exact place is recorded.
Clear the field and choose Activar. The first activation downloads approximately 160 MB of public model and runtime assets. No account or paid inference key is needed.
Search quiero mostrar la pantalla del computador en el televisor. The model suggests the USB-C to HDMI adapter even though that sentence is not its title. Open its card to inspect the recorded location.
Switch to Mis cosas, add a harmless test object, edit its place and export a backup. The fictional and personal collections stay separate.

Code

Repository, reproducible checks and evidence.

This is new source written during the event window, with OpenAI Codex assistance. Earlier projects informed design decisions; their code was not repackaged as this entry. The repository records authorship, third-party licenses, synthetic test data and current limitations.

How I Built It

React and TypeScript handle the interface. Transformers.js 3.8.1 loads a pinned, quantized ONNX conversion of paraphrase-multilingual-MiniLM-L12-v2 in a Web Worker. Mean-pooled, normalized embeddings let cosine similarity rank existing names, descriptions and tags. Literal matches are retained and placed first, so activating AI does not make exact locations disappear.

The asynchronous details matter: stale queries and collection versions are ignored, clearing a query restores the ready state, and room filters operate on all qualifying candidates rather than a prematurely shortened result list. The model cannot write or delete records.

The app passed 55 unit tests, production compilation and browser checks for add/edit/favorite/reload, export/delete/restore, narrow layouts and actual ONNX inference. A loaded session could also search with the network disabled. This does not establish offline page reload support.

In eleven synthetic target queries against the ten-object demo, literal search found two target records and the hybrid approach found nine. Two absent-object examples produced no result. The model still missed an Allen-key paraphrase and a sofa-measuring paraphrase. A second open model and a fragmented index did not improve the tradeoff, so neither was shipped. These are small reproducible examples, not a user study or an accuracy guarantee. Read the evaluation and its failures.

Why Does Open Innovation Matter?

Open weights and a browser runtime let the semantic search happen on the device without sending household descriptions to a hosted inference API. They also make it possible to pin the model, compare alternatives and publish the actual evaluation, including failures.

That choice has costs: a noticeable first download, device computation and imperfect suggestions. Browser storage is not encrypted or synchronized, and the hosting services still receive ordinary asset requests. The design makes those boundaries visible instead of implying that local inference solves every privacy or reliability problem.

The cache key that only looked at one of its four inputs

EazyHood — Sun, 02 Aug 2026 15:47:59 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Paritok is a context compressor. You
hand it a blob of text, a query describing what you care about, and a compression level,
and it hands back a shorter version that is supposed to keep what matters for that query
and drop the rest. Results are cached, because compression is the expensive part.

I was not looking for bugs in it. I was building an audit harness to measure how much
meaning compression costs — feeding the same corpus through with different queries and
checking which critical substrings survive: file paths, error types, line numbers,
identifiers.

Bug Fix or Performance Improvement

Two rows in my results table were byte-for-byte identical. Different query, different
compression level, same 544 characters:

query="Fix the IntegrityError on commit"              level=L0  ->  159 tok  cache_hit=False
query="Explain the tax rounding TODO in compute_tax"  level=L3  ->  159 tok  cache_hit=True

compress() takes four things that shape its output — content, query, level and
kind. The cache was keyed on one of them:

sid = content_hash(content)
cached = self.storage.get_cached_compressed(sid)

So the first caller's answer was served to every later caller with the same input text, no
matter what they actually asked. The second caller got a compression tuned to somebody
else's question, marked cache_hit=True, with nothing in the response to say so.

This is worse than a stale cache. A stale cache gives you an old answer to your question.
This gives you a fresh answer to someone else's.

Code

The fix is open as a PR: Paritok-official/paritok-4b-v1#17 — 2 files, +118/−12.

The audit harness that surfaced it is at
EazyHood/paritok-audit (Apache-2.0).

# The compressed result depends on query, level and kind as well as on the
# content -- query is documented as driving keep/drop -- so all four belong
# in the key. Keying on content alone returned the first caller's answer to
# every later caller. `sid` deliberately stays content-only, because
# expand_context resolves originals by content and that behaviour is correct.
cache_key = content_hash(
    "\x00".join([sid, level or "", kind or "", query or ""])
)

# 4. Cache check (same content AND same intent gets the same answer)
cached = self.storage.get_cached_compressed(cache_key)

My Improvements

Three decisions in this patch are worth explaining, because the obvious fix is wrong.

1. Don't change sid — add a key beside it.

The tempting one-liner is to fold the query into sid and move on. That breaks something
else: expand_context resolves a compressed reference back to its original by content
hash. sid has to stay content-only for that to keep working. So the patch introduces a
separate cache_key and leaves sid exactly as it was. Two identifiers, two jobs.

2. Classify kind before building the key, not after.

kind was being resolved after the cache check. That meant a caller passing kind=None
and a caller passing the same kind explicitly would key differently, even though the
compressor would treat them identically — a cache miss on every first call, forever.

Moving classification above the cache check fixed that, and it fixed a second bug on the
way: only LocalModelStrategy sniffed kind internally, so GpuServerStrategy was
forwarding kind=None to the server. Central classification means every backend now
receives a real value.

3. Join the parts with a null byte.

"\x00".join(...) rather than "-".join(...) or plain concatenation. Without a separator
that cannot occur in the inputs, level="L0" + kind="1code" and level="L01" +
kind="code" collide into the same key. It costs nothing and removes a class of bug that
would be genuinely miserable to track down later.

The test. tests/test_cache_key_intent.py (+92) asserts the property directly: same
content with different queries must not return the same object, and the same content with
the same intent must hit the cache. It fails on the original code and passes on the patch,
which is the only claim about a fix I actually trust.

What I took away from it

I found this because my harness printed cache_hit next to every row. If it had only
printed token counts, two identical numbers would have looked like a compressor being
consistent, which is exactly what you want it to be.

The bug was invisible in the metric everyone watches and obvious in the one nobody logs.
Since then I print the cache flag next to every cached result I benchmark — the cost is one
column, and it is the column that told me the answer I was measuring wasn't mine.