BreadRelay

Recover a changed bread collection round, inspect the trade-offs, and hand off checked routes.

Comment

Inspiration and problem

A bakery collection round has a short deadline and a limited volunteer crew. If someone becomes unavailable before departure, keeping the remaining routes can leave collectable bread behind. The coordinator needs a feasible replacement plan and a clear explanation of its compromises.

BreadRelay focuses on that decision for a coordinator preparing a small evening collection round in Hong Kong. Feeding Hong Kong's Bread Run informed the local setting; BreadRelay is an independent prototype with no affiliation or operator endorsement. Its bakery names, travel times and quantities are fictional.

What it does

Change a volunteer's availability, carrying limit or shift, or edit a pickup's quantity and collection window. BreadRelay recalculates complete routes and compares them with the feasible parts of the unchanged plan. Each route shows arrivals, waiting, collection time, carried weight and the return deadline.

The demonstration starts with 38 kg scheduled. Mark Volunteer A unavailable: the unchanged routes retain 18 kg; the revised plan schedules 26 kg. Ask why Bakery C is excluded: a real alternative schedules 23 kg, adding C's 4 kg while leaving Bakery B's 7 kg out. Inspecting it preserves the selected 26 kg plan. These are modeled scheduled quantities, not verified deliveries.

Download, copy or print the checked plan. Reopening its JSON report restores the reference and changed inputs and recomputes both plans. Imported result totals are never trusted. Complete replacement rounds can be supplied as validated JSON; structural round creation has no visual editor.

How it was built

TypeScript, native HTML/CSS and Vite produce a static application hosted on GitHub Pages. A module Web Worker enumerates feasible directed routes, then uses disjoint-subset dynamic programming to choose assignments. It first maximizes scheduled grams, then retains prior assignments, then minimizes travel. A separate validator reconstructs route timing, load and totals before accepting a result.

The scope is deliberately bounded: ten whole pickups, three volunteers, three stops per volunteer, one hub and same-day Hong Kong times. Supplied fixed travel minutes are inputs, not live navigation. Revision isolation prevents old calculations from appearing as current results. Inputs are validated and canonicalized; worker startup failure falls back to local computation, while calculation timeout offers a visible Retry. No backend, credentials, external runtime API or inference model is required.

What makes it distinctive

The memorable interaction is an inspectable recovery decision: see the cost of including an excluded pickup without losing the selected plan, then preserve the whole comparison for handoff. Established products already optimize multi-stop food rescues, including Food Rescue Hero. BreadRelay claims neither a novel routing algorithm nor superiority over those products. It explores a small, transparent, browser-local recovery workflow.

Verification and accomplishments

The independently enumerated test oracle checked 350 small instances. Sixteen native tests, 52 compiled Chrome assertions and 11 desktop WebKit assertions passed. The public release passed 24 HTTPS workflow assertions at desktop and phone widths, plus seven refinement assertions. Downloads, report restoration, invalid imports, keyboard focus, repeated changes, direct links, reloads and offline operation after loading were exercised.

In 100 seeded synthetic cancellation rounds, exact recovery scheduled 1,956 kg in total, compared with 1,830 kg for a defined weight-first greedy insertion baseline and 1,688 kg for unchanged routes. The mean modeled gain over greedy was 1.26 kg per case. Inputs and outcomes are reproducible in the release evidence. This is a synthetic benchmark, not representative field evidence, a vendor comparison or food actually delivered.

Challenges and lessons

Rapid changes can produce convincing but stale results. Revision checks and checked input snapshots keep the displayed routes and exported report consistent. Oversized or unexpected JSON also threatened report restoration; bounded validation and canonical inputs solved the reproduced cases. Clear pickup substitutions and mobile save-panel ordering made the central workflow easier to demonstrate. No external user study is claimed.

Reused work and limitations

BreadRelay was created during the hackathon; no pre-existing BreadRelay application was submitted unchanged. Third-party development dependencies and Vite's bundled helper are documented in the repository and release notices. Fixture, interface and icons were created for this project; problem and interface references informed decisions without copying operator data or branding. Original source is public for inspection and currently has no open-source license grant (UNLICENSED).

The prototype does not provide live maps, in-progress dispatch, overnight routes, accounts, messages or food-safety decisions. Actual collection outcomes and coordinator usefulness remain unmeasured. Automated phone-width browser checks do not establish physical-device or comprehensive assistive-technology coverage. Next steps should validate the workflow with real coordinators and trustworthy travel inputs before enlarging the problem.

Built With

Share this project:

Updates

Submission history