DEV Community: 十方空烬 · Ember ☄️

Shelf Friend helps my friend compare supermarket prices and product care

十方空烬 · Ember ☄️ — Fri, 02 Oct 2026 06:39:11 +0000

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

What I Built

A friend needs help while shopping at a supermarket: compare prices, understand how a kitchen or household item should be used, and weigh its advantages against the maintenance it brings home.

I built Shelf Friend, a small Chinese-language web app with two connected decisions: what costs less per usable unit, and what fits the intended use? My friend stays anonymous. I have not yet collected their feedback, so the results below are my implementation checks, not a claimed user study.

The calculator takes prices from the shelf, net quantity and pack count. The AI retrieves a relevant use guide or buying checklist from a small, visible corpus. A cheaper pan may still be a poor purchase if its weight, stove compatibility or care routine does not fit the person buying it.

Demo

Open the live demo — no account or API key needed.

Try this short walkthrough:

Click 试试演示价格 (“Try demo prices”). The fictional rice offers are 2 kg for 2.50 OMR and 500 g for 0.75 OMR. They become 1.25 and 1.50 OMR/kg; the first is 16.7% cheaper per kg. These are demonstration prices, not retailer quotes.
Click 铸铁锅保养 (“Cast-iron care”). The browser downloads the model on first use, then retrieves a guide scoped to Lodge's seasoned cast iron, with a source link and a maintenance tradeoff.
Try 保鲜盒怎么用 (“Food-container use”) or ask in English, “How should I clean and oil a cast iron skillet?” The interface and guides are Chinese, but query matching is multilingual.

Code

Public repository · MIT application code and original checklists.

I started this project and its repository on October 2, 2026, inside the weekend challenge window. It is separate from my weekly challenge work and uses no employer resources.

How I Built It

The AI core is Transformers.js running the quantized ONNX conversion of the open-weight multilingual MiniLM model. A web worker embeds the question and the guide descriptions, then ranks them by cosine similarity. This is model inference, not a keyword lookup. The app displays only the highest-ranking guide above its threshold, or says the corpus has no sufficiently relevant content. Similarity is labelled as similarity, not a probability or factual-accuracy score.

The eight-guide corpus covers cookware, pantry packaging, cleaners, food containers, small appliances, tissue multipacks and batteries. Most entries are my original buying checklists. The cast-iron entry is a concise, linked summary of Lodge's care instructions, with its scope explicit. Unknown product specifications are left unknown.

Price arithmetic is deterministic JavaScript. It normalizes grams/kilograms and millilitres/litres, accounts for multipacks, and rejects comparisons between mass, volume and count. The model never calculates the winning price.

In Edge, I checked Chinese cast-iron, bulk-rice and food-container queries, an English cast-iron query, and an unrelated football question that returned no guide. I also checked the public deployment, a small-phone layout and landscape layout. Automated tests cover unit conversion, incompatible quantities, invalid inputs, zero prices, ties and similarity arithmetic. These checks are limited; I have not benchmarked retrieval accuracy or tested every phone.

The first model download is about 118 MB. It took 13.3 seconds in my public-demo test; one later query completed in about 0.1 seconds. That is one browser observation, not a speed promise. I would load it before entering a supermarket with weak reception. Caches may help later use, but I do not promise offline availability on every device.

Why Does Open Innovation Matter?

Open weights make the semantic search usable inside the shopper's own browser. I can inspect and change the corpus, pin the model revision, and keep shopping questions away from a remote inference service. I do not need a subscription, an API secret on the page, or a server that stores my friend's questions. Initial runtime and model downloads still contact public CDNs and produce ordinary request metadata.

The base model and Transformers.js use Apache-2.0 licenses. Their open distribution made this small, reproducible deployment possible. The application and checklists can be inspected and improved independently of the model.

This first version supports manual shelf-price comparison and a small guide library. It does not scrape live retailer prices, recognize product photos or barcodes, certify materials, or invent a product manual. My next useful step is to let my friend try it on a real shopping trip, then use their feedback to decide which products and instructions to add.

VoiceStack Atlas: version-aware speech deployment with Astro and Sanity

十方空烬 · Ember ☄️ — Thu, 01 Oct 2026 18:46:35 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

I built VoiceStack Atlas, a deployment planner that keeps old speech-tool documentation in its own era. It asks for a runtime profile, reads structured compatibility rules from Sanity, and returns decisions tied to original, commit-pinned sources.

The interesting case is CUDA 12 with cuDNN 8. A generic “GPU requirements” search can surface different documentation eras. The current faster-whisper README documents a specific CTranslate2 workaround; the v1.0.0 README describes a different CUDA stack. I model the condition and documentation status separately, so a historical fact cannot become today's installation instruction.

The same distinction applies to audio: built-in file decoding does not mean an 8 kHz NumPy array will be resampled. The planner separates those paths and reminds the caller that transcription starts when the segment generator is iterated.

Demo

Open the project.

Try CUDA 12 / cuDNN 8 / Raw NumPy array, then change CUDA to 13. The second profile should ask for more evidence rather than inventing an installation command. Switch to CPU and file input to see GPU requirements disappear.

The deployed Astro app reads the public Sanity dataset without a login or browser token. I verified the current CUDA 12 / cuDNN 8 / array profile, the unsupported CUDA 13 profile, and CPU / file input against real Content Lake documents.

Open the full-size screenshot.

Code

Source code and reproducible checks.

Original compatibility annotations, constraints, interface, and evaluation are my work. Public faster-whisper documentation and source code are credited and preserved under their upstream MIT license. No employer code, recordings, datasets, or credentials are used.

My Build Process

I started by asking for conditions, conclusions, actions, and provenance to be separate fields. A polished answer is not useful if it mixes a release-era requirement with a current requirement.

I used the Codex desktop IDE to build a narrow planner and source validation first, then an Astro interface. The build instructions evolved from a real Context-connected agent to a directly verifiable structured-content app. This is a summary of the iteration, not a verbatim prompt transcript: separate conditions from conclusions; preserve literal evidence from pinned files; refuse unsupported profiles; and verify Sanity reads before publishing. An early assumption about the historical README failed its literal evidence check. I corrected the annotation against the actual pinned file. That failure shaped the design: source checks are part of the workflow, not a decorative citation after the answer.

I initially attempted Path One with a Sanity Context Knowledge Base. Public website ingestion succeeded, but the completed build exposed no readable entries, and endpoint creation returned a not-found page. I did not present the offline planner as a working MCP agent. I prepared a direct Content Lake version in Astro instead, because its structured decision model is valuable without a live model loop. The Context harness remains experimental code, not a claimed completed agent.

The second correction was operational. I created source and compatibility-rule documents in a personal public Content Lake dataset, added a native source reference, and configured credential-free browser reads. An import token stays in a local ignored environment file. The frontend has no token and fetches the live rules on each resolution. I checked three profiles against the live dataset before switching the public deployment from the earlier offline prototype.

I kept the decision engine deterministic: a runtime profile must satisfy every applicable condition, and historical records only appear in a separate context section. This makes the result traceable and gives unsupported combinations a useful failure state. I did not use App SDK or Workflows; the scope is an Astro frontend over structured Sanity content.

How I Used Sanity

The Content Lake model has two document types. source stores repository, ref, commit, original URL, and license. compatibilityRule stores when, status, claim, action, and a native sourceRef reference to the pinned source document. Conditions combine device, CUDA major, cuDNN major, and audio input format. The historical/current status is independent of those conditions.

The Astro frontend reads those documents through public GROQ queries and applies all conditions together. It displays an error when Sanity is unavailable; no cached compatibility answer is silently substituted. Tokens used for import stay on the server side and are never shipped to the browser.

Sanity Project Details

Project ID: jud8maoc. Dataset: production.

Public source corpus.

Inspect the public dataset. It contains four source documents and eight original compatibility rules. No credentials are required.

For example, a rule combines device: cuda, cuda: 12, and cudnn: 8, with status: current, an evidence literal, an action, and sourceRef pointing to a commit-pinned document. A source reference is shared provenance; the historical/current field controls whether the rule can drive a current decision.

Validation and Limits

Local checks cover current versus historical dependency selection, missing versions, unsupported combinations, CPU separation, file versus array handling, and missing or unknown citations. Each curated evidence literal was checked against its pinned upstream file.

I have not run GPU inference or claimed speed, memory, or speech accuracy results. This tool is a deployment planning aid, not proof that a dependency stack works on every machine. The Context prototype has not passed a real retrieval run, and is not the finished submission.

Valid JSON is not enough: testing bilingual patch contracts on Kaggle

十方空烬 · Ember ☄️ — Thu, 01 Oct 2026 18:25:07 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

A JSON response can parse successfully and still change the wrong state. A response can also contain the right state but arrive wrapped in Markdown that breaks a strict consumer. I built Bilingual Patch Contracts to keep those two failure modes visible.

The task has twelve handcrafted state-update scenarios, each with an English, Chinese, and code-switched instruction body: 36 prompts. Each triplet shares an initial state and expected answer. The contract prefix stays in English, and the output keys stay canonical English. This tests changing the instruction body's language under a shared contract; it is not a fully Chinese interaction benchmark.

Every case begins with:

{"route":"email","delay_minutes":20,"active":true,"tags":["alpha","beta"],"note":"seed"}

The scenarios cover later corrections, negation, null versus empty values, ordered and case-sensitive tags, hours-to-minutes conversion, sequential conditions, instruction-like literal data, and exact copying of Unicode, backslashes, quotes, and a newline.

A pass requires the entire response to be one JSON object with exactly five keys, valid types, and every expected value. I do not strip Markdown, repair outputs, or ask another model to judge. Whitespace, object key order, and equivalent Unicode escapes are accepted. Duplicate keys, extra fields, nonfinite values, and booleans or floats in integer fields fail. Array order matters.

I use ordinary text generation, with temperature 0 and seed 0 requested through the SDK, and a fresh isolated conversation for each case. There is no constrained JSON decoding, schema enforcement, or tool use. Provider behavior may still vary between runs.

Models Tested

I ran the complete suite on Kaggle on October 1, 2026, using task version 2. I selected three lightweight models from different providers available in the platform catalog:

Model	Exact Kaggle model identifier
Gemini 3.7 Flash	`gemini-3.7-flash`
GPT-5.4 nano	`gpt-5.4-nano-2026-03-17`
Claude Haiku 4.5	`claude-haiku-4-5-20251001`

I also attempted qwen3-next-80b-a3b-instruct. Both the pilot and version 2 attempt stopped with HTTP 429 and a provider message about heavy load. It has no complete score, so it is excluded from the leaderboard rather than assigned zero.

Version 2 fixes task registration so Kaggle selects the whole-suite aggregate instead of a helper function. The prompts, fixtures, and scorer were unchanged. All results below come from complete version 2 runs. I downloaded the raw responses, checked all 36 unique case IDs against the frozen prompts and answers, and independently recalculated the saved scores.

Findings

Model	Strict exact match	Valid JSON	Valid schema	English	Chinese	Mixed
Gemini 3.7 Flash	36/36 (100%)	36/36	36/36	12/12	12/12	12/12
GPT-5.4 nano	24/36 (66.7%)	36/36	36/36	7/12	8/12	9/12
Claude Haiku 4.5	0/36 (0%)	0/36	0/36	0/12	0/12	0/12

Valid JSON does not prove a correct update

GPT-5.4 nano produced a valid object with valid field types on every case, but twelve answers contained wrong values.

For case-sensitive-en, the instruction body is:

Tag strings are case-sensitive. Add Beta. Remove beta. Add ALPHA. Add alpha.

Starting with ["alpha","beta"], the expected tags are ["alpha","Beta","ALPHA"]. The raw model response was:

{"route":"email","delay_minutes":20,"active":true,"tags":["alpha","beta","Beta","ALPHA"],"note":"seed"}

The lowercase beta should have been removed. A JSON parser or type validator alone would accept this answer.

A presentation choice can break the contract

Claude Haiku 4.5 wrapped every answer in a Markdown code fence despite the explicit instruction “No Markdown or explanations.” For last-write-en, its full response was:

```json
{"route": "sms", "delay_minutes": 0, "active": true, "tags": ["alpha", "beta"], "note": "seed"}
```

The values in this example are correct, but the full response is not a JSON document. Its zero is a strict interface score, not evidence that it understood none of the requests.

As a separate diagnostic, removing only the complete outer code fences would make 33/36 answers pass the same value checks. That counterfactual is not the benchmark score and does not repair any leaderboard output. It shows why formatting compliance and state correctness deserve separate reporting.

Language totals need paired inspection

Nano's mixed total exceeded its English total by two cases. Within the twelve matched scenarios, seven passed in both English and mixed, three failed in both, and two passed only in mixed. For English versus Chinese, six passed in both, three failed in both, one passed only in English, and two passed only in Chinese.

These observations locate cases to inspect; they do not establish that the model is generally stronger in Chinese or code-switching. The bodies were hand-authored, and phrasing and token lengths are not perfectly controlled.

A ceiling is a prompt to extend the suite

Gemini passed every case in this run. This suite therefore cannot distinguish its reliability beyond these examples. I would next add longer instruction chains, more literal-copy edge cases, and repeated runs, while keeping new cases separate from this frozen result.

This is a small diagnostic benchmark, not a general model ranking. The three language variants are paired observations: there are twelve independent semantic scenarios, not thirty-six independent problems. A single run does not establish production reliability, and shared English contract instructions limit the multilingual claim. I did not benchmark latency, cost, or tool calling.

My Benchmark

Bilingual Patch Contracts on Kaggle

The collection uses one numeric task whose score is strict exact matches divided by 36. Its overall score is the average of task scores; with one task, it equals that task's score.

Inspect the version 2 task and model outputs and the public backing notebook for the embedded cases, expected states, scorer, and run artifacts (contract_results.json and contract_summary.json). Infrastructure errors abort the suite rather than silently shrinking the denominator.

I authored the prompts and answer fixtures for this personal project. The implementation uses the Kaggle Benchmarks SDK, following the official platform documentation.