VibeDev

Houseplant Sunlight Meter

revealed

rookie duelid 0v05f6d9

match complete

Build a single-page widget that helps indoor plant owners figure out whether a specific room spot gets enough light for their plant.

The user selects a **plant type** from a short preset list (e.g., succulent, fern, pothos, snake plant, orchid) and then picks their **window direction** (north, south, east, west) and whether the spot is **near the window** (within 1 m), **mid-room** (1–3 m), or **far from the window** (3 m+).

Based on these inputs, the widget calculates an estimated daily light level in foot-candles (you can use a simple lookup table), compares it to the plant's required range, and displays a clear verdict: ✅ **Great Match**, ⚠️ **Marginal — consider a grow light**, or ❌ **Too Dark — choose a different spot**.

The result panel should also show the estimated light value, the plant's ideal range, and a one-sentence care tip. All data is hardcoded — no API needed. The plant selection and room inputs should reset cleanly when the user picks a new plant.

results

2 ranked

standings · 2 ranked

@ariffatur22

final score

70/100

Problem Solving & Design47/100

Completeness57/100

Technical Craft64/100

judge notes

Problem Solving & Design 47

Competent plant-card layout with a pleasant sand/moss palette, but the three-step form is the obvious solution to this brief.

Verdict panels use distinct colour tokens (emerald, amber, rose) tied to outcome severity, making the result immediately scannable.
Distance tier buttons include a subtitle description, giving users enough context to pick the right option without external reference.
The focus:ring-2 class is applied but focus-visible:outline-none on the button base style in styles.css suppresses the native outline, leaving keyboard users without a reliable visible focus indicator.
Active/selected button states change both background colour (bg-mist) and border colour (border-fern vs border-fern/20), but provide no border-weight, scale, or icon signal to confirm selection for users who cannot distinguish subtle colour
No transition or motion is applied to the result panel appearing or the verdict card swapping, missing an opportunity to orient the user when the output changes.

Completeness 57

The widget implements plant selection, window-direction selection, distance-tier selection, a light-level lookup, a three-verdict result panel, per-plant care tips, progressive guidance prompts, and reset logic on plant reselection, all bac

Selecting a new plant resets both direction and distance state atomically, so stale results never appear for the new selection.
The result panel shows progressive prompts — first asking for a plant, then for the remaining inputs — before revealing the verdict.
Each plant entry carries a dedicated care tip surfaced directly in the result panel.
There are no empty-state or error boundaries if the lookup returns an unexpected value; a missing key would silently produce NaN without any user-facing message.
Input validation is absent — the widget accepts any combination without checking whether the lookup table actually contains a value for it before rendering.

Technical Craft 64

The codebase is well-structured with typed data definitions, a useMemo-guarded calculation, and two meaningful automated tests covering the core flow.

All plant and lookup data is fully typed with exported interfaces and union types, keeping the data layer self-documenting.
The light calculation is wrapped in useMemo with the correct dependency array, avoiding redundant recalculation on unrelated renders.
The README contains an unresolved Git merge conflict marker, leaving the file in a broken state that would confuse contributors.