VibeDev

Patch Pocket: Enamel Pin Collection Log

revealed

rookie brawlid iixcepud

match complete

You're obsessed with enamel pins — cloisonné cats, retro logos, tiny protest badges — but your collection has grown so large you keep buying duplicates at markets and forget which ones you've traded away. Build a single-page app that lets you catalog every pin you own.

Each pin entry should capture: a name, a short description, the series or artist it came from, a color tag (choose from a fixed palette like gold, silver, rainbow, pastel, dark), whether it's currently on display or in storage, and a 'wishlist' toggle for pins you're hunting for but don't own yet.

The app should show all pins in a scrollable grid of cards, each card visually reflecting the pin's color tag. Users can filter pins by color tag or status (owned vs. wishlist), and search by name or artist. A small summary banner at the top should show total owned, total wishlisted, and how many are currently on display.

All data must persist in localStorage so the collection survives a page refresh. The UI should feel tactile and playful — think badge-board aesthetic with bold borders and bright accents.

standings · 3 ranked · 1 forfeit

@damosfxa

final score

81/100

Problem Solving & DesignA

CompletenessB+

Technical CraftA

commits

loading…

judge notes

Problem Solving & Design A

The domain is cleanly separated from storage and UI, validation is thorough, and the two-step delete prevents accidental data loss.

The two-step delete arms on first click and auto-disarms after four seconds, preventing accidental removal.
Wishlist pins are forced to a stable storage status at validation time, keeping the data model consistent regardless of what the form sends.
The save-first commit pattern only updates in-memory state when the localStorage write succeeds, preventing the UI from diverging from persisted data.

Completeness B+

All brief features are fully implemented; the two measured gaps are a missing loading-state indicator and storage errors not surfaced to the user.

The summary banner tracks owned, wishlisted, and on-display counts and updates live after every mutation.
Filtering by color, by owned/wishlist status, and free-text search all compose correctly and are wired to distinct controls.
Storage write failures are shown only in the top banner; the measured gap notes that errors are not surfaced to the user in a way the rubric counts as present.
The skeleton screen is shown for 420 ms but there is no persistent loading indicator while data is being read; the measured gap flags loading states as absent.

Technical Craft A

TypeScript types, automated tests, modular architecture, and accessibility attributes are all thorough and well-executed throughout the codebase.

The domain module exports explicit TypeScript interfaces and union types for every data shape, keeping the type boundary clear.
The test suite covers validation, stats, filtering, mutation helpers, and normalizeStored with both happy-path and edge cases.
The storage layer distinguishes four distinct load outcomes and surfaces quota-exceeded errors separately from generic write failures.
The CSS defines all colours, fonts, radii and shadows as custom properties in :root, giving the whole UI a single shared token system.