DEV Community: Hornet-Wing

Memory Lantern: finding old stories when you’ve forgotten the words

Hornet-Wing — Fri, 30 Oct 2026 23:27:13 +0000

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

What I Built

Sometimes you remember what a story was about, but not the words someone used to tell it. A dented cake tin. A train ticket. The way somebody fixed a broken radio rather than throwing it away.

Memory Lantern is a small collection for those memories. Add notes about people, places, and ordinary moments, then search for what you remember. The AI’s job is to find related passages in the notes you actually saved. Every result opens the original text.

For “Ghost in the Machine,” I wanted to help the past remain accessible. The app holds onto people’s words and makes them easier to find. An example collection contains eight clearly labeled fictional memories so visitors can try the idea before adding their own.

Demo

Try Memory Lantern

To try the difference between the two search modes:

Search food she made for celebrations with Match words selected.
Enable meaning search and compare the results for the same query.
Open a result to read the complete source note.

The example collection includes a birthday baking memory called “The lemon cake tin.” Its vocabulary differs from the query, which makes it a useful case for checking semantic retrieval. The model ranks the results; the app has no hardcoded answer for this query.

No account or API key is needed. Initial model loading requires internet, and the interface shows download progress. Visitors can also add a memory, reload to check that it was saved, and export the collection.

Code

Source code and setup instructions

The app and original fictional example collection are MIT licensed. Runtime code and model weights are downloaded separately under their respective licenses.

How I Built It

The app is plain HTML, CSS, and JavaScript, served as static files. Memories are stored in the browser and can be exported as a restorable JSON backup or a self-contained HTML reading copy. The reading copy contains no scripts or external assets.

Meaning search runs all-MiniLM-L6-v2, using Xenova’s ONNX port, in a module Web Worker. Transformers.js 3.8.1 runs q8 weights with ONNX Runtime’s WASM CPU backend. Both queries and notes use mean pooling and L2 normalization.

Long notes are split into overlapping source passages to reduce truncation. The worker caches their embeddings in memory and re-encodes changed notes on the next search. Cosine similarity selects the best passage for each memory, then ranks the memories. The model encodes and compares text; it does not write any memories or answers.

flowchart LR
    Notes[Original memories] --> Passages[Source passages]
    Passages --> Model[Local MiniLM worker]
    Query[Search thought] --> Model
    Model --> Similarity[Cosine ranking]
    Similarity --> Original[Passage and complete original note]
    Notes --> Backup[JSON backup and HTML reading copy]

Two details matter for trust. A nearest neighbor can still be irrelevant, so results show similarity scores and original passages. Word matching stays available for exact details. Download or inference failures produce an error, with no silent change of search method.

Ten logic tests cover backup round trips, malformed imports, merge behavior, long-note passage coverage, retrieval ranking, safe exports, and worker cancellation/recovery. The repository also includes an optional browser check that downloads the real model and exercises the example query.

Why Does Open Innovation Matter?

The search model is downloadable and can run on the reader’s device. There is no inference account or API key to obtain, and no per-query inference service to pay for. The app can be hosted as static files, and its search code and weights can be inspected or replaced.

That is especially useful for personal memories. The app does not upload notes or search queries to an inference server. Loading meaning search still fetches code from jsDelivr and files from Hugging Face, which receive normal download metadata. Browser storage is not encrypted, synced, or backed up automatically, so the export feature is part of the core experience.

There are tradeoffs: the model weights take about 23 MB plus runtime files, the model works best with English, and semantic similarity can miss a useful memory. Code/runtime loading can still need internet after a reload. The standalone reading copy provides a simple way to preserve the collection independently of the application.

What Informed the Build

Gabriel Anhaia’s explanation of pooling and normalization reinforced the need to encode notes and queries consistently. Divyakush Punjabi’s “Similarity isn't relevance” informed the way results are presented: source passages and a similarity ranking rather than an assertion that the app knows the answer. No article code was copied.

This app and post were created with AI coding and writing assistance. The model and Transformers.js are Apache-2.0 licensed; ONNX Runtime is MIT licensed. I’m entering the overall category.

Daylight: A Local AI PA That Makes Room for Work and Life

Hornet-Wing — Sun, 25 Oct 2026 18:00:58 +0000

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

What I Built

I wanted a personal assistant for a small daily problem: I have work tasks and personal tasks, but deciding what to do when is another task in itself.

Daylight turns a task list into a proposed day. Work and personal tasks can share the schedule, with priorities, estimates, fixed appointments and breaks taken into account.

The workflow is:

Set the hours available and add appointments that cannot move.
Write one task per line, or add tasks using a form.
Let a local open-weight model suggest category, priority and duration.
Review those suggestions, then add them to the schedule.
Complete tasks or replan the remaining day when something changes.

Tasks that cannot fit appear under For another time, with an explanation. The planner keeps the original estimate and respects the end of the day.

That is the “Slow and Steady” idea I wanted to explore: spend less effort juggling the list, while still being honest about how much day is left.

Demo

Demo video: Watch the Daylight demo on Google Drive

During development I tried a mixed list: preparing a challenge entry, packing for a trip, and cleaning a pet’s bowl. The early results exposed useful problems, described below. This was hands-on browser testing, not a formal accuracy evaluation.

Code

Source repository: Hornet-Wing/daylight

The original application code is MIT licensed. The project uses plain HTML, CSS and JavaScript, plus a small Node.js static server for local use. No dependency installation or build step is required for the manual planner.

From the project directory:

npm start

Open http://127.0.0.1:4174. The AI reader separately downloads its runtime and model when enabled.

How I Built It

I built Daylight with Codex, starting from the behaviour I wanted: list what needs doing, give it rough priorities, and see a realistic day containing both work and personal tasks.

The AI integration uses WebLLM and the open-weight Qwen2.5 0.5B Instruct model, through its MLC WebGPU build. Inference runs in a browser worker.

Give the model a smaller job

The first version asked the model for a complete task list, including optional start and finish times. Browser testing revealed that it could invent full date-and-time strings even when my notes supplied no times. It also omitted one task.

An earlier error handler hid the useful diagnostic because a worker failure arrived as plain text instead of an Error object. Preserving that text exposed a grammar-initialisation failure, which led to a simpler generation schema.

Those failures changed the design.

Each original task line is now kept by application code. The model handles one line at a time and returns only:

{
  "category": "personal",
  "priority": "should",
  "duration": 30
}

This is an example of the response format, not a benchmark result.

The model does not supply task titles or time constraints. Explicit phrases such as “before 5pm” or “after 09:30” are handled separately. Without a supported time phrase, both optional time fields stay blank. Ambiguous source phrases remain visible for correction.

Explicit user metadata takes precedence too. For example:

Personal: pack for a trip, medium priority, 37 minutes

That preserves the stated 37 minutes even if the model suggests something else.

A later trial exposed another limitation: “week 3” became a three-minute estimate, and packing was classified as Work/High. The current request constrains inferred durations to a menu of valid time blocks and includes clearer classification examples. Those changes do not establish that the model’s judgments are accurate. Category, priority and duration still need review.

Let scheduling code handle the clock

After review, ordinary code builds the schedule:

Original task lines
  → local model suggests category, priority and duration
  → explicit source metadata overrides guesses
  → person reviews and accepts
  → scheduling code fits tasks around appointments and breaks
  → timeline and explicit overflow

Tasks are considered by priority, then deadline, then input order. Each receives the earliest uninterrupted slot that fits its full duration and constraints. Fixed appointments stay fixed. Breaks reserve time between tasks.

This is a greedy scheduling heuristic, not a claim of an optimal schedule. It does not split tasks automatically, and a missed deadline can leave a task unscheduled. The interface explains those cases so I can make the tradeoff myself.

Check the rules separately from model quality

The current automated suite has 50 passing tests, including 120 generated scheduling scenarios.

The checks cover overlapping appointments, task durations, deadlines, work/personal hours, overflow, backups, server responses, visible error messages, preservation of source lines, and rejection of invented model time fields.

The AI contract tests use test doubles. They check what the application requests and accepts; they do not measure real-model accuracy. The development environment also restricted automated browser testing. My browser trials supplied the screenshots and failure reports that drove the changes above.

Two community references helped frame the approach:

Building a CLI Task Manager That Solves the "When to Do It" Problem Taskwarrior Lacked, by @kohei_wada, describes transparent scheduling from priorities, estimates and daily capacity.
Stop AI From Inventing Facts in Document Extraction, by @claupttools, discusses keeping missing facts unknown and checking proposed values against their source.

Why Does Open Innovation Matter?

A daily task list can mix work information with personal routines. Local inference is useful because the notes can be processed on my device, without sending them to a hosted inference API.

The browser still fetches runtime and model files when needed. This is not a claim that the app makes no network requests. The first model load needs a substantial download and compatible WebGPU hardware; cached files may reduce later downloads.

Open weights and an open runtime also let me inspect the integration, change the prompt or experiment with a different model. The scheduling rules are separate, so changing the model does not mean trusting it to rewrite the clock.

Daylight stores its plan in one browser, with JSON backup and restore. There is no account or cloud database. Browser storage is not encrypted, and backups include notes. Calendar sync and multi-device sync are outside this prototype.

The Lazy Payoff

The intended benefit is less repeated planning: place the tasks once, see what fits, and rebuild the remaining day when plans change.

I have not measured minutes saved or run a sustained daily-use trial. What I have is a working prototype, hands-on feedback, and a clearer understanding of where a small local model needs boundaries and human correction.

The next useful measurement is how much I edit its suggestions and how much manual rearranging remains after it proposes a day.

The code and this article were prepared with Codex assistance.

Town Centre: An AoE2 Tournament Desk with Local AI

Hornet-Wing — Sun, 18 Oct 2026 23:20:52 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Town Centre is an organiser desk for small Age of Empires II: Definitive Edition 1v1 tournaments.

Picture an eight-player community cup. The first round has four series. One pair has agreed a time, another is waiting for a reply, one player has shared no availability, and two opponents cannot find an overlapping window.

That is the situation in Town Centre's fictional sample tournament. The organiser can see which matches need attention and take the next action from one dashboard.

The prototype supports:

An eight-player single-elimination bracket, with organiser-approved seeds.
Editable availability in each player's time zone.
Proposed match times checked against both players' full availability.
Confirmations recorded by the organiser.
Manual series results that advance the winner.
Copyable Discord announcements and JSON backups.
An AI reader designed to turn informal availability messages into structured windows for review.

The intended customer is a streamer or community organiser who runs tournaments repeatedly. My pricing hypothesis is $5–$10 per tournament for less scheduling administration. That price has not been validated, and I have not measured time saved or collected payments. An open-source app could still have a paid hosted service or event-support offering around it; the prototype does not implement either.

The next useful test is to put it in front of an organiser: can they arrange the first round more easily, and is the improvement worth paying for?

Demo

Demo video: Watch the Town Centre demo on Google Drive

The recorded walkthrough uses the fictional Castle vs Monk match to demonstrate the organiser workflow:

Paste a sample availability message for the selected player, extract its availability, and save it.
Propose a match time once both players have availability.
Record the fictional players’ confirmations and copy a Discord announcement.
Enter the series result and show Castle advancing in the bracket.

Testing: I recorded the sample workflow described above. Automated checks cover core rules, DOM-adapter interactions, and AI request/response contracts. This is a functional demonstration with fictional players; I have not measured general extraction accuracy, run a real customer tournament, or validated willingness to pay.

Code

Source repository: Hornet-Wing/tourney-organiser

The original application code is MIT licensed. It is plain HTML, CSS, and JavaScript, with a small Node.js static server for local use. No npm dependency installation or build step is required for the manual tournament workflow.

From the repository's project directory:

npm start

Then open http://127.0.0.1:4173. The AI reader separately downloads its browser runtime and model when requested.

How I Built It

I developed the prototype with Codex, starting from the game and event format I wanted to support: AoE2 and competitive 1v1 tournaments. I kept the first version to eight players so the whole competition could be represented and tested.

Give the language model a specific job

The AI integration uses WebLLM with the open-weight Qwen2.5 0.5B Instruct model, through its MLC WebGPU build.

An organiser chooses a player, supplies their declared time zone and the message's reference date, and pastes that player's availability message. The model is asked for JSON containing complete availability windows and clarification questions.

Messages are pasted manually in this prototype. There is no automatic Discord import or channel monitoring. After arranging a match, the organiser can copy an announcement and post it to Discord themselves.

The implementation supplies an explicit JSON Schema string with the JSON-output request, validates the returned fields, converts valid local times to UTC, and presents the interpretation for review. Saving the reviewed output adds availability; it does not confirm or schedule a match automatically.

The first model load requires a substantial download and a compatible WebGPU device. Manual entry remains available throughout.

Keep tournament decisions explicit

The rest of the workflow uses ordinary application rules:

Player message
  → local model extracts proposed windows
  → validation and organiser review
  → saved availability
  → code checks possible match slots
  → organiser proposes a time
  → organiser records player confirmations
  → manual result advances the winner

For example, the application checks whether a complete reserved series slot fits within both players' availability. A proposed time change clears both confirmations. Later rounds must follow the reserved slots of their prerequisite matches.

The organiser supplies the estimated series duration, including drafts and breaks. That duration is a scheduling allowance, not an AI prediction of how long an AoE2 series will last.

The app rejects impossible local times during daylight-saving changes. For a local time that occurs twice when the clocks go back, it asks the organiser to enter the time in UTC instead.

Test the competition rules

The current suite has 26 passing tests: 14 core-rule tests, eight DOM-adapter interaction tests, and four AI request/response contract tests.

They cover daylight-saving cases, availability intersections, invalid scores, winner progression, imported backup validation, UI navigation, confirmations, event creation, and escaping player text.

The recorded walkthrough supplements these automated checks with a sample browser workflow. It does not establish compatibility across browsers or accuracy across different scheduling messages.

The World's Edge AoE2 tournament handbook informed the scheduling workflow. Individual events provide their own rules, maps, settings, and draft links.

Why Does Open Innovation Matter?

Local inference is a useful fit for this particular customer.

Availability messages may contain players' personal schedules. The integration is designed to process those messages on the organiser's device, avoiding the need to send them to a hosted inference API. The browser still fetches runtime and model files, and the page requests external fonts; this is not a claim that the app makes no network requests.

There is also no per-message inference API charge in this architecture. That could make a small per-event service easier to operate, although device resources, download size, hosting, support, and maintenance still have costs.

Open weights and an open runtime make it possible to experiment with a larger model or change the extraction prompt without rebuilding the tournament rules. The small default model keeps the initial scope manageable, but its extraction quality still needs to be evaluated on real scheduling messages.

The tradeoff is hardware compatibility. Organisers without a suitable GPU can use manual availability, while the model-backed workflow needs a compatible device.

What informed the approach

The project builds on lessons other developers have shared:

I Watched a Streamer Suffer Through Tournament Admin and Spent A Month Fixing It, by @scythe2, describes the work of coordinating tournament tools.
Building an AI lineup optimizer for a Discord esports bot (the algorithm, not the hype), by @ravendev, helped frame the division between interpreting messages and enforcing constraints.
I built React components that run Qwen2.5 in the browser via WebGPU – no server, no API key, works offline, by @dhruvil_chauhan_eccb4a1eb, describes a related local extraction approach. Town Centre does not use that library.

What comes next

The next milestone is an organiser trial using scheduling messages shared with permission. A future Discord integration could reduce copying and pasting, but it is not part of the current prototype. I would measure incorrect interpretations and the organiser's remaining manual work before expanding the scope.

Town Centre currently stores data in one browser, has no player login or multi-organiser synchronisation, and requires results to be entered manually. No first-user feedback, sales, or partner-category eligibility is claimed in this draft.

The code and this draft were prepared with assistance from Codex. The author should review and verify the content before publishing.