DEV Community: Xiaojia Yu

Dresser: my wife's private wardrobe, now picking today's outfit in one tap

Xiaojia Yu — Sat, 03 Oct 2026 17:08:15 +0000

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

Dresser, a private wardrobe that picks today's outfit so you don't have to think.

My wife is an everyday user of the wardrobe app I built earlier and run on our NAS (it is called yichu). We designed it together: she asks for what she needs, I build it. Choosing what to wear takes thinking every morning, and you don't want to wear the same thing several days in a row. Dresser is the version that takes that thinking away: open it, get one outfit from clothes you own, tap Wear this. It is a new repository, written from scratch for this challenge; the original is its inspiration and the source of the requirements.

The same morning on the command line. It is raining in Shanghai (2026-10-04), and the example wardrobe is 21 drawings with a scripted two-week wear log:

$ dresser --demo today --occasion casual
Today in Shanghai: 19-22 °C, rain 100%  ->  occasion: casual, room: autumn

  Top pick: white t-shirt + blue jeans + yellow rain boots
    Yellow rain boots keep your feet dry in the rain, while the white tee and blue jeans offer a relaxed, casual vibe perfect for the mild 20.5°C weather.
    Rotation: Nothing in it was worn in the last 3 days.

  Alternative 1: white t-shirt + blue jeans + brown ankle boots
    Right weight for 20.5 °C and within the casual dress code; no rain-sensitive shoes; tagged for this occasion (rule-based pick).
    Rotation: Nothing in it was worn in the last 3 days.

The weather is live, the reason is written by an open-weight model, and the Rotation line is built by plain code from the wear log.

A day with it

Morning. You open the page. One quiet line says Shanghai 19-22 °C, rain 100% · Autumn. Under it, four words: commute, casual, date, formal. Under those, one card: three pieces from your wardrobe and a sentence on why.

Not feeling it? Show another gives the next outfit, and the app remembers that you passed on that exact combination, so it is ranked lower from then on. There is no "do you like it?" question.

Wearing it. Wear this writes the day into a history on your own disk. Undo is one tap.

Tomorrow. The history does the remembering. Pieces you wore yesterday are steered away from, and a piece that has been sitting there for a while gets brought back, with a line that says so: Brings back white t-shirt (not worn for 14 days).

When it rains. Suede, canvas and other rain-sensitive shoes are taken out of the running before the model sees anything. That is why a rainy day gives yellow rain boots instead of the brown pair.

Between seasons. The wardrobe is split into four rooms, Spring, Summer, Autumn and Winter, as in the original app. You only see, and only get outfits from, the current room. The room follows the date and your city's hemisphere, and you can switch it by hand.

Putting clothes in

Take or choose photos, and a vision model fills in category, colour, material and warmth. You look it over and fix anything before it is saved.

Or paste a link to a product page. On a shop page that exposes its picture, the item turns into a pre-filled form, here from a real Allbirds page:

Tags (work, casual, rain-ready, layering) are added automatically, and a button can ask the model for more ideas; you keep or remove each one. The app never suggests buying anything.

How it works

Rules decide what is allowed, the history decides what is fresh, and the model only chooses among what is left and explains it. If the model is slow or down, you get the rule-based pick instead of an error.

photo -> describe (vision model) -> filter by weather, occasion, season (rules)
      -> rotate by wear history (rules) -> choose + explain (text model)

Rotation, in one number

I simulated two weeks of dressing on the example wardrobe, 50 runs. Without rotation, the same piece was worn two days in a row 17 times over the fortnight; with rotation, 0.2 (averages over the 50 runs). Details are in docs/rotation_simulation.md.

Why open-weight models

The photos are her wardrobe. With an open-weight model, where those photos go is a choice. Everything goes through one OpenAI-compatible client, so the same code can point at the cloud or at a server on your own machine, such as Ollama:

[llm]
preset = "siliconflow"   # cloud, open-weight Qwen models
# preset = "local"       # Ollama or llama.cpp on your own machine, no key, nothing leaves it
privacy = "off"          # or "images-local", or "local-only"

With images-local, photos only go to localhost. With local-only, nothing leaves the machine, including the forecast and link fetching, and the app refuses before sending. In the default cloud mode a 512 px copy of each photo is sent once and cached; after that only text goes out, and the wear history stays on disk.

For photos I use Qwen3-VL-30B-A3B, and for the pick Qwen3.6-35B-A3B, both open-weight and served by SiliconFlow. Swapping either is a one-line change.

Try it

To try it with no account and no key (the rules choose; with a key, the model writes the reason too):

git clone https://github.com/wubian87/dresser && cd dresser
./demo.sh                        # prints suggestions from the example wardrobe
python -m dresser --demo serve   # the web page, on the example wardrobe

Code (MIT): https://github.com/wubian87/dresser

Limits

The demo uses an example wardrobe of 21 drawings and a scripted wear log; the rotation figure comes from a simulation, not from a person.
Paste-a-link works on shop pages that expose their product picture, and says so plainly when it can't; then you upload a photo.
The model's pick and wording differ from run to run. There is no login, so keep it on a network you trust.

I built this with an AI coding agent, directing the design.

Fermion Fleet: When the Door Is Code, Not a Prompt

Xiaojia Yu — Thu, 27 Aug 2026 11:55:44 +0000

This post was created for the Google All Things Agentic Hackathon.

Autonomous agents can sound certain while still being wrong. That is not a prompt-quality problem; it is a boundary problem.

Fermion Fleet is a small multi-agent system built around one constraint: an order must not lock because a model says it is ready. It may lock only after code can read a structured boolean approval.

Demo: https://youtu.be/6nPqy1AI2Kw
Code: https://github.com/wubian87/fermion-fleet
Devpost: https://devpost.com/software/fermion-fleet

The problem: confident language is not a permission

In the demo, a handler drafts an order confirmation. It misses required fields. An auditor sends it back. The handler rewrites. Only a valid review can release the order to the ledger.

The important part is not that the auditor is asked to be careful. The important part is that the ledger accepts only a real boolean approval from a parseable result.

The gate has a deliberately boring policy:

The handler prepares a draft.
The auditor checks the required fields.
The gate parses the auditor output.
If the output is missing, malformed, false, or cannot be parsed, the order is held.
Only a structured boolean approval can lock the order.

This is fail-closed by construction. Looks good, a persuasive explanation, an unexpected format, and a parser failure all resolve to stop.

We tested that boundary by breaking the auditor’s output format. The auditor could still identify a real hallucination in natural language. It sounded professional. But code could not read a structured approval, so the door stayed shut.

That is the project’s central idea: the door is code, not a prompt.

Context pressure, not a timer

The other problem is context management. In a long-running system, context cannot expand forever. But forgetting should not mean permanently deleting facts that a later step may need.

Fermion Fleet uses a small context window and a recoverable pool:

customer
-> triage: writes the case file
-> gardener: select / evict / recall
-> gate: handler -> auditor -> parse, fail closed
-> ledger: locks only on boolean true

When the window is full, the gardener evicts low-priority items into a recoverable pool. That eviction is driven by pressure, not by a timer. Later, when a new step needs an earlier detail, the system scores and recalls that item.

In the recorded run, an after-sales commitment leaves the active window. A later customer question makes it relevant again; the system recalls it, and the handler can answer with details that were not present in the current conversation. Without recall, that answer would be impossible.

The Google stack and the policy layer

The runtime stack is Google’s:

Gemini 3.5 Flash through Vertex AI (global)
Google ADK for the agent structure
Cloud Run for deployment

The policy layer is ours:

which context is eligible at each step;
when a full window must evict an item;
how an evicted item can return;
which role may act;
and which handoff is allowed to become a durable ledger entry.

That separation matters. A model can generate the next action; the system still needs explicit, inspectable rules for what that action is allowed to do.

An honest limit

This hackathon build keeps context and the ledger in process memory. A Cloud Run restart loses them. We deliberately do not claim Firestore, a managed memory service, Model Armor, or a background side-track as deployed components.

Those are sensible next steps, but they are not part of this submission. The architecture and README draw only what runs now.

Run it yourself

The repository contains reproducible instructions. The Cloud Run service is an API, rather than a browser UI. To run a complete shift against the public deployment:

git clone https://github.com/wubian87/fermion-fleet
cd fermion-fleet
URL=https://fleet-843303850287.us-central1.run.app ./跑班.sh

A cold start can take roughly 15 seconds.

What I learned

A reliable agent system should make its important no decisions boring and mechanical. The model can be creative inside the workflow; the boundary that grants permission should remain readable by code.

That is the experiment behind Fermion Fleet: make a rejection visible, make a retry auditable, and make the final lock depend on a value that cannot be talked into existence.``