VibeDev

Laundry Load Planner

revealed

rookie duelid uvbp0amn

match complete

You're staring at a mountain of laundry and have no idea where to start. Build a single-page **Laundry Load Planner** that helps users sort and plan their laundry runs.

The app lets users add clothing items by typing a name and selecting a wash category (whites, lights, darks, delicates, heavy-duty). Items are displayed in grouped lists by category. Each category card shows the item count and a simple indicator (e.g. colored dot or badge) that signals whether the load is ready to run — define "ready" as 3 or more items in that group.

Users can remove individual items from any group, and a single **Clear Done** button removes all groups that are marked ready. A running total of all items and total loads ready is shown at the top of the page.

No backend, no auth — everything lives in-memory (or localStorage if the developer chooses). The entire experience is a single HTML page or equivalent single-route app.

results

2 ranked

standings · 2 ranked

@nop

final score

90/100

Problem Solving & Design90/100

Completeness92/100

Technical Craft87/100

judge notes

Problem Solving & Design 90

The implementation fits the brief precisely and delivers a polished, visually differentiated single-page experience with strong responsive layout and clear usability cues throughout.

Per-category CSS custom property tone system (`tone-whites`, `tone-darks`, etc.) gives each card a distinct visual identity without redundant class sprawl
Responsive grid adapts from single column to `md:grid-cols-2` and `xl:grid-cols-3` for category cards; header stacks on mobile and rows on `lg:`
Progress bar in each `CategoryCard` gives immediate visual feedback on how close a load is to ready
`sr-only` labels on form inputs and `aria-label` on remove buttons cover accessibility basics
Sticky header keeps total and Clear Done in view at all scroll positions
No visual transition or confirmation when 'Clear Done' removes groups — items disappear abruptly despite `TransitionGroup` being present on item lists
'Remove' button is `opacity-0` on non-hover on desktop (only visible on hover/group-hover), which may cause discoverability issues for keyboard and touch users

Completeness 92

All five brief-specified features are present and wired end-to-end: add items by name+category, grouped category cards with item counts, ready indicator at ≥3 items, per-item removal, Clear Done button, and a header total/ready count.

All five wash categories (whites, lights, darks, delicates, heavy-duty) defined in `categories.ts` and rendered via `CategoryCard` in `app.vue`
`clearReady()` in `useLaundry.ts` removes all categories meeting the `READY_THRESHOLD=3` threshold in one operation
Header displays both total item count and ready load count with `aria-live='polite'` for accessibility
localStorage persistence implemented with SSR-safe guard (`import.meta.client`) and try/catch around read and write
Empty-state card shown when `totalItems === 0`, and per-card empty state when category has no items
Brief says items are displayed in 'grouped lists by category' — all five category cards are always shown even when empty, which slightly departs from the 'grouped lists' framing but is functionally acceptable
No validation feedback shown to the user when the name field is empty beyond the button being disabled

Technical Craft 87

Clean Nuxt 4 + Vue 3 Composition API implementation with well-separated composable, typed interfaces, SSR-safe localStorage, and polished CSS custom property theming — a notch above average for this scope.

`useLaundry.ts` is a self-contained composable with clear single-responsibility functions; state is module-level ref shared across calls
`CategoryId` union type and typed `Category`/`LaundryItem` interfaces in `categories.ts` enforce correctness at the component boundary
`crypto.randomUUID()` used for IDs — no timestamp or Math.random collision risk
localStorage read wrapped in try/catch with SSR guard; write also try/catch'd — robust against quota errors and server-side rendering
`READY_THRESHOLD` constant is a single source of truth referenced in both composable and UI copy
No tests of any kind (unit or e2e) present in the repo
`useLaundry` module-level `items` ref is shared across all composable instances — fine for SPA but could cause cross-request state leaks in SSR mode if not carefully guarded
README is the default Nuxt starter template with no project-specific documentation