Add wishlist/saved state for scraped items before wardrobe
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 16m
- Merged PRs (30d)
- 1
Description
## Problem
Scraped items appear to go straight into the wardrobe, so there is no intermediate “I like this but haven’t bought it yet” state.
Users currently cannot separate aspirational items from owned inventory, which makes planning and backloging purchases difficult.
## Impact
- Scraped products are mixed with owned wardrobe items, reducing clarity and trust.
- Users cannot easily track shopping intent or style gaps before purchase.
- The wardrobe view becomes cluttered with items that are not actually acquired.
- Increases risk of duplicate purchases, missing planned items, and poor shopping workflow.
## Proposed Fix
- Add a dedicated **Wishlist / Saved items** state for scraped products.
- On scrape (or during later item actions), allow users to save as:
- `Wardrobe` (owned)
- `Wishlist` (saved for later purchase)
- Add a new wishlist listing/filter in the UI separate from wardrobe.
- Add transitions between states:
- `Wishlist -> Wardrobe` when purchased
- `Wishlist -> Archived/Removed` when no longer needed
- Optional: `Wardrobe -> Wishlist` for rollback
- Optional setting: **Auto-save scraped items to wishlist** for planning-focused users.
- Make state visible in item cards and search/sort results.
## Functionality Impact
| Area | Current State | Requested Change |
|---|---|---|
| Scrape flow | Scraped item always lands in wardrobe | Scraped item can be saved to wishlist or wardrobe |
| Product lifecycle | No explicit “interested” state | Distinct states: wishlist, wardrobe, archived |
| UI | Single collection (wardrobe-centric) | Separate wishlist + wardrobe views/filters |
| Purchase conversion | No explicit transition action | Explicit “moved to wardrobe / marked as bought” |
| Planning | Weak intent tracking | Strong planning flow for gaps and future buys |
Contributor guide
Assessment
This issue has not been assessed yet.