docs(13): create phase plan

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.planning/MILESTONES.md

@@ -1,5 +1,23 @@
 # Milestones
 
+## v1.2 Collection Power-Ups (Shipped: 2026-03-16)
+
+**Phases completed:** 3 phases, 6 plans, 11 tasks
+**Timeline:** 3 days (2026-03-14 → 2026-03-16)
+**Codebase:** 7,310 LOC TypeScript, 66 files changed (+7,243 / -206)
+
+**Key accomplishments:**
+- Weight unit conversion (g/oz/lb/kg) with segmented toggle wired across all 8 display call sites
+- Candidate status tracking (researching/ordered/arrived) with clickable StatusBadge popup
+- Sticky search/filter toolbar with text search and icon-aware CategoryFilterDropdown
+- Per-setup item classification (base/worn/consumable) with click-to-cycle badge
+- Recharts donut chart with category/classification toggle, hover tooltips, and weight subtotals
+- Classification-preserving sync that maintains metadata across atomic setup re-sync
+
+**Archive:** `.planning/milestones/v1.2-ROADMAP.md`, `.planning/milestones/v1.2-REQUIREMENTS.md`
+
+---
+
 ## v1.1 Fixes & Polish (Shipped: 2026-03-15)
 
 **Phases completed:** 3 phases, 7 plans

.planning/PROJECT.md

@@ -2,7 +2,7 @@
 
 ## What This Is
 
-A web-based gear management and purchase planning app. Users catalog their gear collections (bikepacking, sim racing, or any hobby), track weight, price, and source details, and use planning threads to research and compare new purchases. Named setups let users compose loadouts from their collection with live weight/cost totals. Built as a single-user app with a clean, minimalist interface.
+A web-based gear management and purchase planning app. Users catalog their gear collections (bikepacking, sim racing, or any hobby), track weight, price, and source details, search and filter by name or category, and use planning threads to research and compare new purchases with status tracking. Named setups let users compose loadouts with weight classification (base/worn/consumable), donut chart visualization, and live totals in selectable units. Built as a single-user app with a clean, minimalist interface.
 
 ## Core Value
 
@@ -27,29 +27,41 @@ Make it effortless to manage gear and plan new purchases — see how a potential
 - ✓ Hero image upload area with preview and click-to-upload — v1.1
 - ✓ Lucide icon picker for categories (119 curated icons, 8 groups) — v1.1
 - ✓ Automatic emoji-to-Lucide icon migration for existing categories — v1.1
+- ✓ Search items by name with instant filtering — v1.2
+- ✓ Filter collection items by category with icon-aware dropdown — v1.2
+- ✓ Combined text search with category filter and result count — v1.2
+- ✓ One-action filter clear — v1.2
+- ✓ Weight unit selection (g, oz, lb, kg) with persistence — v1.2
+- ✓ All weight displays respect selected unit across entire app — v1.2
+- ✓ Per-setup item classification (base weight, worn, consumable) — v1.2
+- ✓ Setup weight subtotals by classification — v1.2
+- ✓ Donut chart visualization with category/classification toggle — v1.2
+- ✓ Chart hover tooltips with weight and percentage — v1.2
+- ✓ Candidate status tracking (researching/ordered/arrived) — v1.2
+- ✓ Planning category filter with Lucide icons — v1.2
 
 ### Active
 
-(No active milestone — use `/gsd:new-milestone` to start next)
+## Current Milestone: v1.3 Research & Decision Tools
+
+**Goal:** Give users the tools to actually decide between candidates — compare details side-by-side, see how a pick impacts their setup, and rank/annotate their options.
+
+**Target features:**
+- Full-detail side-by-side candidate comparison (weight, price, images, notes, links, status)
+- Impact preview: pick a setup, see +/- weight and cost delta for each candidate
+- Candidate ranking (drag-to-reorder) with pros/cons text fields per candidate
 
 ### Future
 
-- [ ] Search items by name and filter by category
-- [ ] Side-by-side candidate comparison on weight and price
-- [ ] Candidate status tracking (researching → ordered → arrived)
-- [ ] Candidate ranking/prioritization within threads
-- [ ] Impact preview: how a candidate affects setup weight/cost
-- [ ] Weight unit selection (g, oz, lb, kg)
 - [ ] CSV import/export for gear collections
-- [ ] Weight distribution visualization (pie/bar chart by category)
-- [ ] Classify items as base weight, worn, or consumable per setup
+- [ ] Multi-user accounts with authentication
+- [ ] Collection sharing and social features (public profiles, shared setups)
+- [ ] Auto-fill product information (price, weight, images) from external sources
 
 ### Out of Scope
 
-- Authentication / multi-user — single user for v1, no login needed
 - Custom comparison parameters — complexity trap, weight/price covers 80% of cases
 - Mobile native app — web-first, responsive design sufficient
-- Social/sharing features — different product, defer to v2+
 - Price tracking / deal alerts — requires scraping, fragile
 - Barcode scanning / product database — requires external database
 - Community gear database — requires moderation, accounts
@@ -57,10 +69,11 @@ Make it effortless to manage gear and plan new purchases — see how a potential
 
 ## Context
 
-Shipped v1.1 with 6,134 LOC TypeScript.
-Tech stack: React 19, Hono, Drizzle ORM, SQLite, TanStack Router/Query, Tailwind CSS v4, Lucide React, all on Bun.
+Shipped v1.2 with 7,310 LOC TypeScript. Starting v1.3 to enhance thread decision workflow.
+Tech stack: React 19, Hono, Drizzle ORM, SQLite, TanStack Router/Query, Tailwind CSS v4, Lucide React, Recharts, all on Bun.
 Primary use case is bikepacking gear but data model is hobby-agnostic.
 Replaces spreadsheet-based gear tracking workflow.
+121 tests (service-level and route-level integration).
 
 ## Constraints
 
@@ -92,6 +105,15 @@ Replaces spreadsheet-based gear tracking workflow.
 | Hero image area at top of forms | Image-first UX, 4:3 aspect ratio consistent with cards | ✓ Good |
 | Emoji-to-icon automatic migration | One-time schema rename + data conversion via Drizzle migration | ✓ Good |
 | ALTER TABLE RENAME COLUMN for SQLite | Simpler than table recreation for column rename | ✓ Good |
+| Weight conversion precision: g=0dp, oz=1dp, lb=2dp, kg=2dp | Matches common usage conventions | ✓ Good |
+| Unit toggle in TotalsBar (not settings page) | Visible, quick access for frequent switching | ✓ Good |
+| CategoryFilterDropdown separate from CategoryPicker | Filter vs form concerns are different | ✓ Good |
+| No debounce on search input | Collection under 1000 items, instant feedback | ✓ Good |
+| StatusBadge popup with click-outside dismiss | Consistent with CategoryPicker pattern | ✓ Good |
+| Classification on setupItems join table | Same item can have different roles per setup | ✓ Good |
+| Click-to-cycle for ClassificationBadge | Only 3 values, simpler than popup | ✓ Good |
+| Classification-preserving sync via Map | Save metadata before delete, restore after re-insert | ✓ Good |
+| Recharts for charting | Mature React chart library, composable API | ✓ Good |
 
 ---
-*Last updated: 2026-03-15 after v1.1 milestone completion*
+*Last updated: 2026-03-16 after v1.3 milestone start*

.planning/REQUIREMENTS.md

@@ -0,0 +1,92 @@
+# Requirements: GearBox v1.3 Research & Decision Tools
+
+**Defined:** 2026-03-16
+**Core Value:** Make it effortless to manage gear and plan new purchases -- see how a potential buy affects your total setup weight and cost before committing.
+
+## v1.3 Requirements
+
+Requirements for this milestone. Each maps to roadmap phases.
+
+### Comparison View
+
+- [x] **COMP-01**: User can view candidates side-by-side in a tabular comparison layout (weight, price, images, notes, links, status)
+- [x] **COMP-02**: User can see relative deltas highlighting the lightest and cheapest candidate with +/- differences
+- [x] **COMP-03**: Comparison table scrolls horizontally with a sticky label column on narrow viewports
+- [x] **COMP-04**: Comparison view displays read-only summary for resolved threads
+
+### Candidate Ranking
+
+- [x] **RANK-01**: User can drag candidates to reorder priority ranking within a thread
+- [x] **RANK-02**: Top 3 ranked candidates display rank badges (gold, silver, bronze)
+- [x] **RANK-03**: User can add pros and cons text per candidate displayed as bullet lists
+- [x] **RANK-04**: Candidate rank order persists across sessions
+- [x] **RANK-05**: Drag handles and ranking are disabled on resolved threads
+
+### Impact Preview
+
+- [ ] **IMPC-01**: User can select a setup and see weight and cost delta for each candidate
+- [ ] **IMPC-02**: Impact preview auto-detects replace mode when a setup item exists in the same category as the thread
+- [ ] **IMPC-03**: Impact preview shows add mode (pure addition) when no category match exists in the selected setup
+- [ ] **IMPC-04**: Candidates with missing weight data show a clear indicator instead of misleading zero deltas
+
+## Future Requirements
+
+Deferred to future milestones. Tracked but not in current roadmap.
+
+### Data Management
+
+- **DATA-01**: User can import gear collection from CSV
+- **DATA-02**: User can export gear collection to CSV
+
+### Social & Multi-User
+
+- **SOCL-01**: User can create an account with authentication
+- **SOCL-02**: User can share collections and setups publicly
+- **SOCL-03**: User can view other users' public profiles and setups
+
+### Automation
+
+- **AUTO-01**: System can auto-fill product information (price, weight, images) from external sources
+
+## Out of Scope
+
+Explicitly excluded. Documented to prevent scope creep.
+
+| Feature | Reason |
+|---------|--------|
+| Custom comparison attributes | Complexity trap -- weight/price covers 80% of cases |
+| Score/rating calculation | Opaque algorithms distrust; manual ranking expresses user preference better |
+| Cross-thread comparison | Candidates are decision-scoped; different categories are not apples-to-apples |
+| Classification-aware impact breakdown | Data available but UI complexity high; flat delta covers 90% of use case |
+| Comparison permalink | Requires auth/multi-user work not in scope for v1 |
+| Mobile-optimized comparison (swipe) | Horizontal scroll works for now |
+| Rank badge on card grid view | Low urgency; add when users express confusion |
+
+## Traceability
+
+Which phases cover which requirements. Updated during roadmap creation.
+
+| Requirement | Phase | Status |
+|-------------|-------|--------|
+| COMP-01 | Phase 12 | Complete |
+| COMP-02 | Phase 12 | Complete |
+| COMP-03 | Phase 12 | Complete |
+| COMP-04 | Phase 12 | Complete |
+| RANK-01 | Phase 11 | Complete |
+| RANK-02 | Phase 11 | Complete |
+| RANK-03 | Phase 10 | Complete |
+| RANK-04 | Phase 11 | Complete |
+| RANK-05 | Phase 11 | Complete |
+| IMPC-01 | Phase 13 | Pending |
+| IMPC-02 | Phase 13 | Pending |
+| IMPC-03 | Phase 13 | Pending |
+| IMPC-04 | Phase 13 | Pending |
+
+**Coverage:**
+- v1.3 requirements: 13 total
+- Mapped to phases: 13
+- Unmapped: 0
+
+---
+*Requirements defined: 2026-03-16*
+*Last updated: 2026-03-16*

.planning/RETROSPECTIVE.md

@@ -91,6 +91,51 @@
 
 ---
 
+## Milestone: v1.2 — Collection Power-Ups
+
+**Shipped:** 2026-03-16
+**Phases:** 3 | **Plans:** 6 | **Files changed:** 66
+
+### What Was Built
+- Weight unit conversion (g/oz/lb/kg) with segmented toggle wired across all weight display call sites
+- Candidate status tracking (researching/ordered/arrived) with clickable StatusBadge popup
+- Sticky search/filter toolbar with text search and icon-aware CategoryFilterDropdown
+- Per-setup item classification (base/worn/consumable) with click-to-cycle ClassificationBadge
+- Recharts donut chart with category/classification toggle and hover tooltips
+- Classification-preserving sync that maintains metadata across atomic setup item re-sync
+
+### What Worked
+- Coarse 3-phase structure again — 19 requirements compressed into 3 phases with clear dependency ordering
+- TDD red/green commits for schema migrations (status, classification) caught edge cases early
+- Vertical slice pattern (schema → service → tests → API → UI in one plan) kept each deliverable self-contained
+- Click-outside dismiss pattern established in v1.1 was reused cleanly in StatusBadge and CategoryFilterDropdown
+- All 6 plans executed with zero deviations from plan — evidence of mature planning process
+
+### What Was Inefficient
+- Some ROADMAP.md plan checkboxes remained unchecked despite summaries existing (persistent cosmetic drift)
+- Recharts v3 Cell component is deprecated for v4 — will need migration eventually
+- Phase 8 bundled search/filter with candidate status (different concerns) — could have been separate phases for cleaner scope
+
+### Patterns Established
+- Click-to-cycle badge: for small enums (3 values), direct click cycling is simpler than popup menus
+- Join table metadata preservation: save metadata to Map before atomic sync, restore after re-insert
+- CategoryFilterDropdown: reusable filter dropdown (separate from form-based CategoryPicker)
+- Chart data transformation: group items by key, sum weights, compute percentages, filter zeroes
+- apiPatch helper: PATCH method now available in client API library for partial updates
+
+### Key Lessons
+1. Classification belongs on join tables (setupItems), not entity tables (items) — same item has different roles in different contexts
+2. Vertical slice delivery (schema → service → test → API → UI) is the optimal plan structure for feature additions
+3. Search complexity should match data scale — no debounce needed for <1000 items
+4. Recharts composable API (PieChart + Pie + Cell + Tooltip + Label) gives fine-grained chart control with minimal wrapper code
+
+### Cost Observations
+- Model mix: quality profile throughout (opus for execution)
+- Sessions: 3 continuous auto-advance sessions (one per phase)
+- Notable: All plans completed with zero deviations, execution faster than v1.0/v1.1
+
+---
+
 ## Cross-Milestone Trends
 
 ### Process Evolution
@@ -99,6 +144,7 @@
 |-----------|---------|--------|------------|
 | v1.0 | 53 | 3 | Initial build, coarse granularity, TDD backend |
 | v1.1 | ~30 | 3 | Auto-advance pipeline, parallel wave execution, auto-fix deviations |
+| v1.2 | 25 | 3 | Zero-deviation execution, vertical slice pattern, join table metadata |
 
 ### Cumulative Quality
 
@@ -106,6 +152,7 @@
 |-----------|-----|-------|-------|
 | v1.0 | 5,742 | 114 | Service + route integration |
 | v1.1 | 6,134 | ~130 | Service + route integration (updated for icon schema) |
+| v1.2 | 7,310 | ~150 | 121 tests (service + route + classification) |
 
 ### Top Lessons (Verified Across Milestones)
 
@@ -113,3 +160,5 @@
 2. Service DI pattern enables fast, reliable testing without mocks
 3. Always update Zod schemas alongside DB schema — middleware silently strips unvalidated fields
 4. Auto-advance pipeline (discuss → plan → execute) works well for clear-scope phases
+5. Vertical slice delivery (schema → service → test → API → UI) is optimal for feature additions
+6. Join table metadata (not entity table) when same entity plays different roles in different contexts

.planning/ROADMAP.md

@@ -2,29 +2,105 @@
 
 ## Milestones
 
-- ✅ **v1.0 MVP** -- Phases 1-3 (shipped 2026-03-15)
-- ✅ **v1.1 Fixes & Polish** -- Phases 4-6 (shipped 2026-03-15)
+- ✅ **v1.0 MVP** — Phases 1-3 (shipped 2026-03-15)
+- ✅ **v1.1 Fixes & Polish** — Phases 4-6 (shipped 2026-03-15)
+- ✅ **v1.2 Collection Power-Ups** — Phases 7-9 (shipped 2026-03-16)
+- 🚧 **v1.3 Research & Decision Tools** — Phases 10-13 (in progress)
 
 ## Phases
 
 <details>
-<summary>v1.0 MVP (Phases 1-3) -- SHIPPED 2026-03-15</summary>
+<summary>✅ v1.0 MVP (Phases 1-3) — SHIPPED 2026-03-15</summary>
 
-- [x] Phase 1: Foundation and Collection (4/4 plans) -- completed 2026-03-14
-- [x] Phase 2: Planning Threads (3/3 plans) -- completed 2026-03-15
-- [x] Phase 3: Setups and Dashboard (3/3 plans) -- completed 2026-03-15
+- [x] Phase 1: Foundation and Collection (4/4 plans) — completed 2026-03-14
+- [x] Phase 2: Planning Threads (3/3 plans) — completed 2026-03-15
+- [x] Phase 3: Setups and Dashboard (3/3 plans) — completed 2026-03-15
 
 </details>
 
 <details>
-<summary>v1.1 Fixes & Polish (Phases 4-6) -- SHIPPED 2026-03-15</summary>
+<summary>✅ v1.1 Fixes & Polish (Phases 4-6) — SHIPPED 2026-03-15</summary>
 
-- [x] Phase 4: Database & Planning Fixes (2/2 plans) -- completed 2026-03-15
-- [x] Phase 5: Image Handling (2/2 plans) -- completed 2026-03-15
-- [x] Phase 6: Category Icons (3/3 plans) -- completed 2026-03-15
+- [x] Phase 4: Database & Planning Fixes (2/2 plans) — completed 2026-03-15
+- [x] Phase 5: Image Handling (2/2 plans) — completed 2026-03-15
+- [x] Phase 6: Category Icons (3/3 plans) — completed 2026-03-15
 
 </details>
 
+<details>
+<summary>✅ v1.2 Collection Power-Ups (Phases 7-9) — SHIPPED 2026-03-16</summary>
+
+- [x] Phase 7: Weight Unit Selection (2/2 plans) — completed 2026-03-16
+- [x] Phase 8: Search, Filter, and Candidate Status (2/2 plans) — completed 2026-03-16
+- [x] Phase 9: Weight Classification and Visualization (2/2 plans) — completed 2026-03-16
+
+</details>
+
+### v1.3 Research & Decision Tools (In Progress)
+
+**Milestone Goal:** Give users the tools to actually decide between candidates — compare details side-by-side, see how a pick impacts their setup, and rank/annotate their options.
+
+- [x] **Phase 10: Schema Foundation + Pros/Cons Fields** — Migrate schema and deliver pros/cons annotation UI (completed 2026-03-16)
+- [x] **Phase 11: Candidate Ranking** — Drag-to-reorder priority ranking with rank badges (completed 2026-03-16)
+- [x] **Phase 12: Comparison View** — Side-by-side tabular comparison with relative deltas (completed 2026-03-17)
+- [ ] **Phase 13: Setup Impact Preview** — Per-candidate weight and cost delta against a selected setup
+
+## Phase Details
+
+### Phase 10: Schema Foundation + Pros/Cons Fields
+**Goal**: Candidates can be annotated with pros and cons, and the database is ready for ranking
+**Depends on**: Phase 9
+**Requirements**: RANK-03
+**Success Criteria** (what must be TRUE):
+  1. User can open a candidate edit form and see pros and cons text fields
+  2. User can save pros and cons text; the text persists across page refreshes
+  3. CandidateCard shows a visual indicator when a candidate has pros or cons entered
+  4. All existing tests pass after the schema migration (no column drift in test helper)
+**Plans:** 1/1 plans complete
+Plans:
+- [x] 10-01-PLAN.md — Add pros/cons fields through full stack (schema, service, Zod, form, card indicator)
+
+### Phase 11: Candidate Ranking
+**Goal**: Users can drag candidates into a priority order that persists and is visually communicated
+**Depends on**: Phase 10
+**Requirements**: RANK-01, RANK-02, RANK-04, RANK-05
+**Success Criteria** (what must be TRUE):
+  1. User can drag a candidate card to a new position within the thread's candidate list
+  2. The reordered sequence is still intact after navigating away and returning
+  3. The top three candidates display gold, silver, and bronze rank badges respectively
+  4. Drag handles and rank badges are absent on a resolved thread; candidates render in static order
+**Plans:** 2/2 plans complete
+Plans:
+- [ ] 11-01-PLAN.md — Schema migration, reorder service/route, sort_order persistence + tests
+- [ ] 11-02-PLAN.md — Drag-to-reorder UI, list/grid toggle, rank badges, resolved-thread guard
+
+### Phase 12: Comparison View
+**Goal**: Users can view all candidates for a thread side-by-side in a table with relative weight and price deltas
+**Depends on**: Phase 11
+**Requirements**: COMP-01, COMP-02, COMP-03, COMP-04
+**Success Criteria** (what must be TRUE):
+  1. User can toggle a "Compare" mode on a thread detail page to reveal a tabular view showing weight, price, images, notes, links, status, pros, and cons for every candidate in columns
+  2. The lightest candidate column is highlighted and all other columns show their weight difference relative to it; the cheapest candidate is highlighted similarly for price
+  3. The comparison table scrolls horizontally on a narrow viewport without breaking layout; the attribute label column stays fixed on the left
+  4. A resolved thread shows the comparison table in read-only mode with the winning candidate visually marked
+**Plans:** 1/1 plans complete
+Plans:
+- [ ] 12-01-PLAN.md — ComparisonTable component + compare toggle wiring in thread detail
+
+### Phase 13: Setup Impact Preview
+**Goal**: Users can select any setup and see exactly how much weight and cost each candidate would add or subtract
+**Depends on**: Phase 12
+**Requirements**: IMPC-01, IMPC-02, IMPC-03, IMPC-04
+**Success Criteria** (what must be TRUE):
+  1. User can select a setup from a dropdown in the thread header and each candidate displays a weight delta and cost delta below its name
+  2. When the selected setup contains an item in the same category as the thread, the delta reflects replacing that item (negative delta is possible) rather than pure addition
+  3. When no category match exists in the selected setup, the delta shows a pure addition amount clearly labeled as "add"
+  4. A candidate with no weight recorded shows a "-- (no weight data)" indicator instead of a zero delta
+**Plans:** 2 plans
+Plans:
+- [ ] 13-01-PLAN.md — TDD pure impact delta computation, uiStore state, ThreadWithCandidates type fix, useImpactDeltas hook
+- [ ] 13-02-PLAN.md — SetupImpactSelector + ImpactDeltaBadge components, wire into thread detail and all candidate views
+
 ## Progress
 
 | Phase | Milestone | Plans Complete | Status | Completed |
@@ -35,3 +111,10 @@
 | 4. Database & Planning Fixes | v1.1 | 2/2 | Complete | 2026-03-15 |
 | 5. Image Handling | v1.1 | 2/2 | Complete | 2026-03-15 |
 | 6. Category Icons | v1.1 | 3/3 | Complete | 2026-03-15 |
+| 7. Weight Unit Selection | v1.2 | 2/2 | Complete | 2026-03-16 |
+| 8. Search, Filter, and Candidate Status | v1.2 | 2/2 | Complete | 2026-03-16 |
+| 9. Weight Classification and Visualization | v1.2 | 2/2 | Complete | 2026-03-16 |
+| 10. Schema Foundation + Pros/Cons Fields | v1.3 | 1/1 | Complete | 2026-03-16 |
+| 11. Candidate Ranking | 2/2 | Complete    | 2026-03-16 | - |
+| 12. Comparison View | 1/1 | Complete    | 2026-03-17 | - |
+| 13. Setup Impact Preview | v1.3 | 0/2 | Not started | - |

.planning/STATE.md

@@ -1,45 +1,85 @@
 ---
 gsd_state_version: 1.0
-milestone: v1.1
-milestone_name: Fixes & Polish
-status: shipped
-stopped_at: v1.1 milestone completed and archived
-last_updated: "2026-03-15T17:15:00.000Z"
-last_activity: 2026-03-15 -- Shipped v1.1 Fixes & Polish milestone
+milestone: v1.3
+milestone_name: Research & Decision Tools
+status: planning
+stopped_at: Completed 12-comparison-view/12-01-PLAN.md
+last_updated: "2026-03-17T14:35:39.075Z"
+last_activity: 2026-03-16 — Roadmap created for v1.3 milestone
 progress:
-  total_phases: 3
+  total_phases: 4
   completed_phases: 3
-  total_plans: 7
-  completed_plans: 7
-  percent: 100
+  total_plans: 4
+  completed_plans: 4
+  percent: 0
 ---
 
 # Project State
 
 ## Project Reference
 
-See: .planning/PROJECT.md (updated 2026-03-15)
+See: .planning/PROJECT.md (updated 2026-03-16)
 
 **Core value:** Make it effortless to manage gear and plan new purchases -- see how a potential buy affects your total setup weight and cost before committing.
-**Current focus:** Planning next milestone
+**Current focus:** v1.3 Research & Decision Tools — Phase 10 ready to plan
 
 ## Current Position
 
-Milestone: v1.1 Fixes & Polish -- SHIPPED
-All phases complete. No active milestone.
-Last activity: 2026-03-15 -- Shipped v1.1
+Phase: 10 of 13 (Schema Foundation + Pros/Cons Fields)
+Plan: —
+Status: Ready to plan
+Last activity: 2026-03-16 — Roadmap created for v1.3 milestone
 
-Progress: [██████████] 100% (v1.1 shipped)
+Progress: [░░░░░░░░░░] 0%
+
+## Performance Metrics
+
+**Velocity:**
+- Total plans completed: 0
+- Average duration: —
+- Total execution time: —
+
+**By Phase:**
+
+| Phase | Plans | Total | Avg/Plan |
+|-------|-------|-------|----------|
+| - | - | - | - |
+
+**Recent Trend:**
+- Last 5 plans: —
+- Trend: —
+
+*Updated after each plan completion*
+| Phase 10-schema-foundation-pros-cons-fields P01 | 6min | 2 tasks | 9 files |
+| Phase 11-candidate-ranking P01 | 4min | 2 tasks | 8 files |
+| Phase 11-candidate-ranking P02 | 4min | 3 tasks | 7 files |
+| Phase 12-comparison-view P01 | 2min | 2 tasks | 3 files |
 
 ## Accumulated Context
 
 ### Decisions
 
-(Full decision log archived in PROJECT.md Key Decisions table)
+Cleared at milestone boundary. v1.2 decisions archived in milestones/v1.2-ROADMAP.md.
+
+Key v1.3 research findings (see research/SUMMARY.md):
+- framer-motion@12.37.0 (already installed) handles drag-to-reorder via Reorder component — no new deps
+- sort_order must use REAL (float) type, not INTEGER, to avoid bulk writes on every drag
+- Impact preview must distinguish add-mode vs replace-mode by category match — pure addition misleads
+- [Phase 10-schema-foundation-pros-cons-fields]: Empty string for pros/cons stored as-is (not normalized to null); test accepts either empty string or null as cleared state
+- [Phase 10-schema-foundation-pros-cons-fields]: Pros/Cons badge uses purple color to distinguish from weight (blue), price (green), category (gray), and status badges
+- [Phase 10-schema-foundation-pros-cons-fields]: Field-addition ladder pattern: schema -> migration -> test helper -> service -> Zod -> types -> hook -> form -> card indicator
+- [Phase 11-candidate-ranking]: sortOrder uses REAL type for future fractional midpoint insertions without bulk rewrites
+- [Phase 11-candidate-ranking]: 1000-gap sort_order strategy: first=1000, append=max+1000, reorder resets to (index+1)*1000
+- [Phase 11-candidate-ranking]: Applied sort_order migration via sqlite3 CLI directly to avoid Drizzle data-loss warning on existing rows
+- [Phase 11-candidate-ranking]: Resolved thread list view uses plain div (not Reorder.Group) — no drag, rank badges visible
+- [Phase 11-candidate-ranking]: RankBadge exported from CandidateListItem for reuse in CandidateCard grid view
+- [Phase 12-comparison-view]: ATTRIBUTE_ROWS declarative array pattern for ComparisonTable keeps JSX clean and row reordering trivial
+- [Phase 12-comparison-view]: Compare toggle only shown for 2+ candidates; Add Candidate hidden in compare view (read-only intent)
+- [Phase 12-comparison-view]: Weight/price highlight color takes priority over amber winner tint when both apply (more informative)
 
 ### Pending Todos
 
-- Replace planning category filter select with icon-aware dropdown (ui)
+None active.
 
 ### Blockers/Concerns
 
@@ -47,6 +87,6 @@ None active.
 
 ## Session Continuity
 
-Last session: 2026-03-15T17:15:00.000Z
-Stopped at: v1.1 milestone completed and archived
+Last session: 2026-03-17T14:32:04.702Z
+Stopped at: Completed 12-comparison-view/12-01-PLAN.md
 Resume file: None

.planning/config.json

@@ -5,7 +5,7 @@
   "commit_docs": true,
   "model_profile": "quality",
   "workflow": {
-		"research": false,
+    "research": true,
     "plan_check": true,
     "verifier": true,
     "nyquist_validation": true,

.planning/milestones/v1.2-REQUIREMENTS.md

@@ -0,0 +1,128 @@
+# Requirements Archive: v1.2 Collection Power-Ups
+
+**Archived:** 2026-03-16
+**Status:** SHIPPED
+
+For current requirements, see `.planning/REQUIREMENTS.md`.
+
+---
+
+# Requirements: GearBox v1.2 Collection Power-Ups
+
+**Defined:** 2026-03-16
+**Core Value:** Make it effortless to manage gear and plan new purchases -- see how a potential buy affects your total setup weight and cost before committing.
+
+## v1.2 Requirements
+
+Requirements for this milestone. Each maps to roadmap phases.
+
+### Search & Filter
+
+- [x] **SRCH-01**: User can search items by name with instant filtering as they type
+- [x] **SRCH-02**: User can filter collection items by category via dropdown
+- [x] **SRCH-03**: User can combine text search with category filter simultaneously
+- [x] **SRCH-04**: User can see result count when filters are active (e.g., "showing 12 of 47 items")
+- [x] **SRCH-05**: User can clear all active filters with one action
+
+### Weight Units
+
+- [x] **UNIT-01**: User can select preferred weight unit (g, oz, lb, kg) from settings
+- [x] **UNIT-02**: All weight displays across the app reflect the selected unit
+- [x] **UNIT-03**: Weight unit preference persists across sessions
+
+### Weight Classification
+
+- [x] **CLAS-01**: User can classify each item within a setup as base weight, worn, or consumable
+- [x] **CLAS-02**: Setup totals display base weight, worn weight, consumable weight, and total separately
+- [x] **CLAS-03**: Items default to "base weight" classification when added to a setup
+- [x] **CLAS-04**: Same item can have different classifications in different setups
+
+### Weight Visualization
+
+- [x] **VIZZ-01**: User can view a donut chart showing weight distribution by category in a setup
+- [x] **VIZZ-02**: User can toggle chart between category view and classification view (base/worn/consumable)
+- [x] **VIZZ-03**: User can hover chart segments to see category name, weight, and percentage
+
+### Candidate Status
+
+- [x] **CAND-01**: Each candidate displays a status badge (researching, ordered, or arrived)
+- [x] **CAND-02**: User can change a candidate's status via click interaction
+- [x] **CAND-03**: New candidates default to "researching" status
+
+### Planning UI
+
+- [x] **PLAN-01**: Planning category filter dropdown shows Lucide icons alongside category names
+
+## Future Requirements
+
+Deferred to future milestones. Tracked but not in current roadmap.
+
+### Planning Enhancements
+
+- **COMP-01**: User can compare candidates side-by-side on weight and price
+- **RANK-01**: User can rank/prioritize candidates within a thread
+- **IMPC-01**: User can preview how a candidate affects setup weight/cost before resolving
+
+### Data Management
+
+- **DATA-01**: User can import gear collection from CSV
+- **DATA-02**: User can export gear collection to CSV
+
+### Social & Multi-User
+
+- **SOCL-01**: User can create an account with authentication
+- **SOCL-02**: User can share collections and setups publicly
+- **SOCL-03**: User can view other users' public profiles and setups
+
+### Automation
+
+- **AUTO-01**: System can auto-fill product information (price, weight, images) from external sources
+
+## Out of Scope
+
+Explicitly excluded. Documented to prevent scope creep.
+
+| Feature | Reason |
+|---------|--------|
+| Per-item weight input in multiple units | Parsing complexity, ambiguous storage -- display-only conversion is sufficient |
+| Interactive chart drill-down (click to zoom) | Adds significant interaction complexity for minimal value |
+| Weight goals / targets | Opinionated norms conflict with hobby-agnostic design |
+| Custom classification labels | base/worn/consumable covers 95% of use cases |
+| Server-side full-text search | Premature for single-user app with <1000 items |
+| Classification at item level (not setup level) | Same item has different roles in different setups |
+| Status change timestamps | Useful but adds schema complexity -- defer |
+
+## Traceability
+
+Which phases cover which requirements. Updated during roadmap creation.
+
+| Requirement | Phase | Status |
+|-------------|-------|--------|
+| SRCH-01 | Phase 8 | Complete |
+| SRCH-02 | Phase 8 | Complete |
+| SRCH-03 | Phase 8 | Complete |
+| SRCH-04 | Phase 8 | Complete |
+| SRCH-05 | Phase 8 | Complete |
+| UNIT-01 | Phase 7 | Complete |
+| UNIT-02 | Phase 7 | Complete |
+| UNIT-03 | Phase 7 | Complete |
+| CLAS-01 | Phase 9 | Complete |
+| CLAS-02 | Phase 9 | Complete |
+| CLAS-03 | Phase 9 | Complete |
+| CLAS-04 | Phase 9 | Complete |
+| VIZZ-01 | Phase 9 | Complete |
+| VIZZ-02 | Phase 9 | Complete |
+| VIZZ-03 | Phase 9 | Complete |
+| CAND-01 | Phase 8 | Complete |
+| CAND-02 | Phase 8 | Complete |
+| CAND-03 | Phase 8 | Complete |
+| PLAN-01 | Phase 8 | Complete |
+
+**Coverage:**
+- v1.2 requirements: 19 total
+- Mapped to phases: 19
+- Unmapped: 0
+
+---
+*Requirements defined: 2026-03-16*
+*Last updated: 2026-03-16 after roadmap creation*

.planning/milestones/v1.2-ROADMAP.md

@@ -0,0 +1,98 @@
+# Roadmap: GearBox
+
+## Milestones
+
+- v1.0 MVP -- Phases 1-3 (shipped 2026-03-15)
+- v1.1 Fixes & Polish -- Phases 4-6 (shipped 2026-03-15)
+- **v1.2 Collection Power-Ups** -- Phases 7-9 (in progress)
+
+## Phases
+
+<details>
+<summary>v1.0 MVP (Phases 1-3) -- SHIPPED 2026-03-15</summary>
+
+- [x] Phase 1: Foundation and Collection (4/4 plans) -- completed 2026-03-14
+- [x] Phase 2: Planning Threads (3/3 plans) -- completed 2026-03-15
+- [x] Phase 3: Setups and Dashboard (3/3 plans) -- completed 2026-03-15
+
+</details>
+
+<details>
+<summary>v1.1 Fixes & Polish (Phases 4-6) -- SHIPPED 2026-03-15</summary>
+
+- [x] Phase 4: Database & Planning Fixes (2/2 plans) -- completed 2026-03-15
+- [x] Phase 5: Image Handling (2/2 plans) -- completed 2026-03-15
+- [x] Phase 6: Category Icons (3/3 plans) -- completed 2026-03-15
+
+</details>
+
+### v1.2 Collection Power-Ups (In Progress)
+
+**Milestone Goal:** Make core gear management significantly more useful as collections grow -- better search, proper weight classification, richer planning threads.
+
+- [x] **Phase 7: Weight Unit Selection** - Users see all weights in their preferred unit across the entire app
+- [x] **Phase 8: Search, Filter, and Candidate Status** - Users can find items quickly and track candidate purchase progress
+- [x] **Phase 9: Weight Classification and Visualization** - Users can classify gear by role and visualize weight distribution in setups
+
+## Phase Details
+
+### Phase 7: Weight Unit Selection
+**Goal**: Users see all weights in their preferred unit across the entire app
+**Depends on**: Nothing (first phase of v1.2)
+**Requirements**: UNIT-01, UNIT-02, UNIT-03
+**Success Criteria** (what must be TRUE):
+  1. User can select a weight unit (g, oz, lb, kg) from a visible control and the selection persists after closing and reopening the app
+  2. Every weight value in the app (item cards, candidate cards, category headers, totals bar, setup details) displays in the selected unit with appropriate precision
+  3. Weight input fields accept values and store them correctly regardless of display unit (no rounding drift across edit cycles)
+**Plans:** 2 plans
+
+Plans:
+- [x] 07-01-PLAN.md -- TDD formatWeight unit conversion core + useWeightUnit hook
+- [ ] 07-02-PLAN.md -- Wire unit toggle into TotalsBar and update all 8 call sites
+
+### Phase 8: Search, Filter, and Candidate Status
+**Goal**: Users can find items quickly and track candidate purchase progress
+**Depends on**: Phase 7
+**Requirements**: SRCH-01, SRCH-02, SRCH-03, SRCH-04, SRCH-05, PLAN-01, CAND-01, CAND-02, CAND-03
+**Success Criteria** (what must be TRUE):
+  1. User can type in a search field on the collection page and see items filtered instantly by name as they type
+  2. User can select a category from a dropdown (showing Lucide icons alongside names) to filter items in both collection and planning views
+  3. User can see how many items match active filters (e.g., "showing 12 of 47 items") and clear all filters with one action
+  4. Each candidate in a planning thread displays a status badge (researching, ordered, or arrived) that the user can change by clicking
+  5. New candidates automatically start with "researching" status
+**Plans:** 2 plans
+
+Plans:
+- [ ] 08-01-PLAN.md -- Candidate status vertical slice (schema migration, service, tests, StatusBadge UI)
+- [ ] 08-02-PLAN.md -- Search/filter toolbar with CategoryFilterDropdown on gear and planning tabs
+
+### Phase 9: Weight Classification and Visualization
+**Goal**: Users can classify gear by role and visualize weight distribution in setups
+**Depends on**: Phase 7, Phase 8
+**Requirements**: CLAS-01, CLAS-02, CLAS-03, CLAS-04, VIZZ-01, VIZZ-02, VIZZ-03
+**Success Criteria** (what must be TRUE):
+  1. User can classify each item within a setup as base weight, worn, or consumable, and the same item can have different classifications in different setups
+  2. Setup detail view shows separate weight subtotals for base weight, worn weight, and consumable weight in addition to the overall total
+  3. User can view a donut chart in a setup showing weight distribution, and toggle between category breakdown and classification breakdown
+  4. User can hover chart segments to see the category/classification name, weight (in selected unit), and percentage
+**Plans:** 2 plans
+
+Plans:
+- [ ] 09-01-PLAN.md -- Classification vertical slice (schema, service, tests, API route, ClassificationBadge UI)
+- [ ] 09-02-PLAN.md -- WeightSummaryCard with subtotals, donut chart, pill toggle, and visual verification
+
+## Progress
+
+**Execution Order:** Phase 7 -> Phase 8 -> Phase 9
+
+| Phase | Milestone | Plans Complete | Status | Completed |
+|-------|-----------|----------------|--------|-----------|
+| 1. Foundation and Collection | v1.0 | 4/4 | Complete | 2026-03-14 |
+| 2. Planning Threads | v1.0 | 3/3 | Complete | 2026-03-15 |
+| 3. Setups and Dashboard | v1.0 | 3/3 | Complete | 2026-03-15 |
+| 4. Database & Planning Fixes | v1.1 | 2/2 | Complete | 2026-03-15 |
+| 5. Image Handling | v1.1 | 2/2 | Complete | 2026-03-15 |
+| 6. Category Icons | v1.1 | 3/3 | Complete | 2026-03-15 |
+| 7. Weight Unit Selection | v1.2 | 2/2 | Complete | 2026-03-16 |
+| 8. Search, Filter, and Candidate Status | v1.2 | 2/2 | Complete | 2026-03-16 |
+| 9. Weight Classification and Visualization | v1.2 | 2/2 | Complete | 2026-03-16 |

.planning/phases/07-weight-unit-selection/07-01-PLAN.md

@@ -0,0 +1,238 @@
+---
+phase: 07-weight-unit-selection
+plan: 01
+type: tdd
+wave: 1
+depends_on: []
+files_modified:
+  - src/client/lib/formatters.ts
+  - src/client/hooks/useWeightUnit.ts
+  - tests/lib/formatters.test.ts
+autonomous: true
+requirements:
+  - UNIT-02
+  - UNIT-03
+
+must_haves:
+  truths:
+    - "formatWeight converts grams to g, oz, lb, kg with correct precision"
+    - "formatWeight defaults to grams when no unit is specified (backward compatible)"
+    - "formatWeight handles null/undefined input for all units"
+    - "useWeightUnit hook returns a valid WeightUnit from settings, defaulting to 'g'"
+  artifacts:
+    - path: "src/client/lib/formatters.ts"
+      provides: "WeightUnit type export and parameterized formatWeight function"
+      exports: ["WeightUnit", "formatWeight", "formatPrice"]
+      contains: "WeightUnit"
+    - path: "src/client/hooks/useWeightUnit.ts"
+      provides: "Convenience hook wrapping useSetting for weight unit"
+      exports: ["useWeightUnit"]
+    - path: "tests/lib/formatters.test.ts"
+      provides: "Unit tests for formatWeight with all 4 units and edge cases"
+      min_lines: 30
+  key_links:
+    - from: "src/client/hooks/useWeightUnit.ts"
+      to: "src/client/hooks/useSettings.ts"
+      via: "useSetting('weightUnit')"
+      pattern: "useSetting.*weightUnit"
+    - from: "src/client/hooks/useWeightUnit.ts"
+      to: "src/client/lib/formatters.ts"
+      via: "imports WeightUnit type"
+      pattern: "import.*WeightUnit.*formatters"
+---
+
+<objective>
+Create the weight unit conversion core: a parameterized `formatWeight` function with a `WeightUnit` type and a `useWeightUnit` convenience hook, all backed by tests.
+
+Purpose: Establish the conversion contracts (type, function, hook) that Plan 02 will wire into every component. TDD approach ensures the conversion math is correct before any UI work.
+Output: Working `formatWeight(grams, unit)` with tests green, `useWeightUnit()` hook ready for consumption.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/07-weight-unit-selection/07-RESEARCH.md
+
+@src/client/lib/formatters.ts
+@src/client/hooks/useSettings.ts
+</context>
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/client/lib/formatters.ts (current):
+```typescript
+export function formatWeight(grams: number | null | undefined): string {
+  if (grams == null) return "--";
+  return `${Math.round(grams)}g`;
+}
+
+export function formatPrice(cents: number | null | undefined): string {
+  if (cents == null) return "--";
+  return `$${(cents / 100).toFixed(2)}`;
+}
+```
+
+From src/client/hooks/useSettings.ts:
+```typescript
+export function useSetting(key: string) {
+  return useQuery({
+    queryKey: ["settings", key],
+    queryFn: async () => {
+      try {
+        const result = await apiGet<Setting>(`/api/settings/${key}`);
+        return result.value;
+      } catch (err: any) {
+        if (err?.status === 404) return null;
+        throw err;
+      }
+    },
+  });
+}
+
+export function useUpdateSetting() {
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: ({ key, value }: { key: string; value: string }) =>
+      apiPut<Setting>(`/api/settings/${key}`, { value }),
+    onSuccess: (_data, variables) => {
+      queryClient.invalidateQueries({ queryKey: ["settings", variables.key] });
+    },
+  });
+}
+```
+</interfaces>
+
+<feature>
+  <name>formatWeight unit conversion</name>
+  <files>src/client/lib/formatters.ts, tests/lib/formatters.test.ts</files>
+  <behavior>
+    Conversion constants: 1 oz = 28.3495g, 1 lb = 453.592g, 1 kg = 1000g
+
+    - formatWeight(100, "g") -> "100g"
+    - formatWeight(100, "oz") -> "3.5 oz"
+    - formatWeight(1000, "lb") -> "2.20 lb"
+    - formatWeight(1500, "kg") -> "1.50 kg"
+    - formatWeight(null, "oz") -> "--"
+    - formatWeight(undefined, "kg") -> "--"
+    - formatWeight(100) -> "100g" (default unit, backward compatible)
+    - formatWeight(0, "oz") -> "0.0 oz"
+    - formatWeight(5, "lb") -> "0.01 lb" (small weight precision)
+    - formatWeight(50000, "kg") -> "50.00 kg" (large weight)
+  </behavior>
+  <implementation>
+    1. Add `WeightUnit` type export: `"g" | "oz" | "lb" | "kg"`
+    2. Add conversion constants as module-level consts (not exported)
+    3. Modify `formatWeight` signature to `(grams: number | null | undefined, unit: WeightUnit = "g"): string`
+    4. Keep the null guard as-is at the top
+    5. Add switch statement for unit-specific formatting:
+       - g: `Math.round(grams)` + "g" (0 decimals, current behavior)
+       - oz: `.toFixed(1)` + " oz" (1 decimal)
+       - lb: `.toFixed(2)` + " lb" (2 decimals)
+       - kg: `.toFixed(2)` + " kg" (2 decimals)
+    6. Do NOT modify `formatPrice` — leave it untouched
+  </implementation>
+</feature>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: TDD formatWeight with unit parameter</name>
+  <files>src/client/lib/formatters.ts, tests/lib/formatters.test.ts</files>
+  <behavior>
+    - formatWeight(100, "g") returns "100g"
+    - formatWeight(100, "oz") returns "3.5 oz"
+    - formatWeight(1000, "lb") returns "2.20 lb"
+    - formatWeight(1500, "kg") returns "1.50 kg"
+    - formatWeight(null) returns "--" for all units
+    - formatWeight(undefined, "kg") returns "--"
+    - formatWeight(100) returns "100g" (backward compatible, no second arg)
+    - formatWeight(0, "oz") returns "0.0 oz"
+  </behavior>
+  <action>
+    RED: Create `tests/lib/formatters.test.ts`. Import `formatWeight` from `@/client/lib/formatters`. Write tests for:
+    - All 4 units with a known gram value (e.g., 1000g = "1000g", "35.3 oz", "2.20 lb", "1.00 kg")
+    - Null and undefined input returning "--" for each unit
+    - Default parameter (no second arg) producing current "g" behavior
+    - Zero grams producing "0g", "0.0 oz", "0.00 lb", "0.00 kg"
+    - Precision edge cases (small values like 5g in lb = "0.01 lb")
+
+    Run tests — they should fail because formatWeight does not accept a unit parameter yet.
+
+    GREEN: Modify `src/client/lib/formatters.ts`:
+    - Export `type WeightUnit = "g" | "oz" | "lb" | "kg"`
+    - Add constants: `GRAMS_PER_OZ = 28.3495`, `GRAMS_PER_LB = 453.592`, `GRAMS_PER_KG = 1000`
+    - Change signature to `formatWeight(grams: number | null | undefined, unit: WeightUnit = "g")`
+    - Add switch statement after the null guard for unit-specific conversion and formatting
+    - Leave `formatPrice` completely untouched
+
+    Run tests — all should pass.
+
+    REFACTOR: None expected — the code is already minimal.
+  </action>
+  <verify>
+    <automated>bun test tests/lib/formatters.test.ts</automated>
+  </verify>
+  <done>formatWeight handles all 4 units with correct precision, null handling, and backward-compatible default. WeightUnit type is exported. All tests pass.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Create useWeightUnit convenience hook</name>
+  <files>src/client/hooks/useWeightUnit.ts</files>
+  <action>
+    Create `src/client/hooks/useWeightUnit.ts`:
+
+    ```typescript
+    import { useSetting } from "./useSettings";
+    import type { WeightUnit } from "../lib/formatters";
+
+    const VALID_UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"];
+
+    export function useWeightUnit(): WeightUnit {
+      const { data } = useSetting("weightUnit");
+      if (data && VALID_UNITS.includes(data as WeightUnit)) {
+        return data as WeightUnit;
+      }
+      return "g";
+    }
+    ```
+
+    This hook:
+    - Wraps `useSetting("weightUnit")` for a typed return value
+    - Validates the stored value is a known unit (protects against bad data)
+    - Defaults to "g" when no setting exists (backward compatible — UNIT-03 persistence works via existing settings API)
+    - Returns `WeightUnit` type so components can pass directly to `formatWeight`
+  </action>
+  <verify>
+    <automated>bun run lint</automated>
+  </verify>
+  <done>useWeightUnit hook exists, imports from useSettings and formatters, returns typed WeightUnit with "g" default. Lint passes.</done>
+</task>
+
+</tasks>
+
+<verification>
+- `bun test tests/lib/formatters.test.ts` passes with all unit conversion tests green
+- `bun run lint` passes with no errors
+- `src/client/lib/formatters.ts` exports `WeightUnit` type and updated `formatWeight` function
+- `src/client/hooks/useWeightUnit.ts` exists and exports `useWeightUnit`
+- Existing tests still pass: `bun test` (full suite)
+</verification>
+
+<success_criteria>
+- formatWeight("g") produces identical output to the old function (backward compatible)
+- formatWeight with oz/lb/kg produces correct conversions with appropriate decimal precision
+- WeightUnit type is exported for use by Plan 02 components
+- useWeightUnit hook is ready for components to consume
+- All existing tests remain green (no regressions)
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/07-weight-unit-selection/07-01-SUMMARY.md`
+</output>

.planning/phases/07-weight-unit-selection/07-01-SUMMARY.md

@@ -0,0 +1,114 @@
+---
+phase: 07-weight-unit-selection
+plan: 01
+subsystem: ui
+tags: [weight-conversion, formatters, react-hooks, tdd]
+
+# Dependency graph
+requires: []
+provides:
+  - "WeightUnit type export for all weight display components"
+  - "Parameterized formatWeight(grams, unit) with g/oz/lb/kg support"
+  - "useWeightUnit() hook wrapping settings API for typed unit access"
+affects: [07-02-PLAN]
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns: [unit-conversion-via-formatters, settings-backed-hooks]
+
+key-files:
+  created:
+    - src/client/hooks/useWeightUnit.ts
+    - tests/lib/formatters.test.ts
+  modified:
+    - src/client/lib/formatters.ts
+
+key-decisions:
+  - "Conversion precision: g=0dp, oz=1dp, lb=2dp, kg=2dp matching common usage"
+  - "useWeightUnit validates stored value against known units to protect against corrupt data"
+
+patterns-established:
+  - "Weight formatting: always call formatWeight(grams, unit) with WeightUnit parameter"
+  - "Settings-backed hooks: wrap useSetting with typed validation for domain-specific config"
+
+requirements-completed: [UNIT-02, UNIT-03]
+
+# Metrics
+duration: 2min
+completed: 2026-03-16
+---
+
+# Phase 7 Plan 01: Weight Unit Core Summary
+
+**Parameterized formatWeight with g/oz/lb/kg conversion and useWeightUnit settings hook, backed by 21 TDD tests**
+
+## Performance
+
+- **Duration:** 2 min
+- **Started:** 2026-03-16T11:14:19Z
+- **Completed:** 2026-03-16T11:16:30Z
+- **Tasks:** 2
+- **Files modified:** 3
+
+## Accomplishments
+- TDD-developed formatWeight function supporting 4 weight units (g, oz, lb, kg) with appropriate precision
+- WeightUnit type exported for consumption by all display components in Plan 02
+- useWeightUnit convenience hook with validation and "g" default, ready for component integration
+- Full backward compatibility preserved -- formatWeight(grams) still returns "Xg" as before
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1 (RED): TDD formatWeight tests** - `431c179` (test)
+2. **Task 1 (GREEN): Implement formatWeight with unit parameter** - `6cac0a3` (feat)
+3. **Task 2: Create useWeightUnit convenience hook** - `ada3791` (feat)
+
+_TDD task had 2 commits (test -> feat). No refactor needed -- code was already minimal._
+
+## Files Created/Modified
+- `src/client/lib/formatters.ts` - Added WeightUnit type, conversion constants, switch-based unit formatting
+- `src/client/hooks/useWeightUnit.ts` - Convenience hook wrapping useSetting("weightUnit") with typed validation
+- `tests/lib/formatters.test.ts` - 21 tests covering all units, null/undefined, backward compat, edge cases
+
+## Decisions Made
+- Conversion precision follows common usage: grams rounded (0dp), ounces 1dp, pounds 2dp, kilograms 2dp
+- useWeightUnit validates stored value against a whitelist of known units, protecting against corrupt settings data
+- Conversion constants (GRAMS_PER_OZ=28.3495, GRAMS_PER_LB=453.592, GRAMS_PER_KG=1000) kept as module-level consts, not exported
+
+## Deviations from Plan
+
+### Auto-fixed Issues
+
+**1. [Rule 1 - Bug] Fixed import order in useWeightUnit.ts**
+- **Found during:** Task 2 (useWeightUnit hook creation)
+- **Issue:** Biome lint required imports sorted alphabetically (type imports before value imports)
+- **Fix:** Reordered imports to put `import type { WeightUnit }` before `import { useSetting }`
+- **Files modified:** src/client/hooks/useWeightUnit.ts
+- **Verification:** `bun run lint` passes clean
+- **Committed in:** ada3791 (Task 2 commit)
+
+---
+
+**Total deviations:** 1 auto-fixed (1 bug - lint order)
+**Impact on plan:** Trivial formatting fix. No scope creep.
+
+## Issues Encountered
+None
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- WeightUnit type and formatWeight function ready for Plan 02 to wire into all weight-displaying components
+- useWeightUnit hook ready for components to consume the user's preferred unit from settings
+- All 108 existing tests pass (full suite regression check confirmed)
+
+## Self-Check: PASSED
+
+All files exist, all commits found, all exports verified.
+
+---
+*Phase: 07-weight-unit-selection*
+*Completed: 2026-03-16*

.planning/phases/07-weight-unit-selection/07-02-PLAN.md

@@ -0,0 +1,247 @@
+---
+phase: 07-weight-unit-selection
+plan: 02
+type: execute
+wave: 2
+depends_on:
+  - "07-01"
+files_modified:
+  - src/client/components/TotalsBar.tsx
+  - src/client/components/ItemCard.tsx
+  - src/client/components/CandidateCard.tsx
+  - src/client/components/CategoryHeader.tsx
+  - src/client/components/SetupCard.tsx
+  - src/client/components/ItemPicker.tsx
+  - src/client/routes/index.tsx
+  - src/client/routes/setups/$setupId.tsx
+autonomous: false
+requirements:
+  - UNIT-01
+  - UNIT-02
+  - UNIT-03
+
+must_haves:
+  truths:
+    - "User can see a unit toggle (g/oz/lb/kg) in the TotalsBar"
+    - "Clicking a unit in the toggle changes all weight displays across the app"
+    - "Weight unit selection persists after page refresh"
+    - "Every weight display in the app uses the selected unit"
+  artifacts:
+    - path: "src/client/components/TotalsBar.tsx"
+      provides: "Unit toggle UI and unit-aware weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/components/ItemCard.tsx"
+      provides: "Unit-aware item weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/components/CandidateCard.tsx"
+      provides: "Unit-aware candidate weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/components/CategoryHeader.tsx"
+      provides: "Unit-aware category total weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/components/SetupCard.tsx"
+      provides: "Unit-aware setup weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/components/ItemPicker.tsx"
+      provides: "Unit-aware item picker weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/routes/index.tsx"
+      provides: "Unit-aware dashboard weight display"
+      contains: "useWeightUnit"
+    - path: "src/client/routes/setups/$setupId.tsx"
+      provides: "Unit-aware setup detail weight display"
+      contains: "useWeightUnit"
+  key_links:
+    - from: "src/client/components/TotalsBar.tsx"
+      to: "/api/settings/weightUnit"
+      via: "useUpdateSetting mutation"
+      pattern: "useUpdateSetting.*weightUnit"
+    - from: "src/client/components/ItemCard.tsx"
+      to: "src/client/hooks/useWeightUnit.ts"
+      via: "useWeightUnit hook import"
+      pattern: "useWeightUnit"
+    - from: "src/client/components/TotalsBar.tsx"
+      to: "src/client/lib/formatters.ts"
+      via: "formatWeight(grams, unit)"
+      pattern: "formatWeight\\(.*,\\s*unit"
+---
+
+<objective>
+Wire weight unit selection through the entire app: add a segmented unit toggle to TotalsBar and update all 8 formatWeight call sites to use the selected unit.
+
+Purpose: Deliver the complete user-facing feature. After this plan, users can select g/oz/lb/kg and see all weights update instantly across collection, planning, setups, and dashboard.
+Output: Fully functional weight unit selection with persistent preference.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/07-weight-unit-selection/07-RESEARCH.md
+@.planning/phases/07-weight-unit-selection/07-01-SUMMARY.md
+</context>
+
+<interfaces>
+<!-- Contracts created by Plan 01 that this plan consumes -->
+
+From src/client/lib/formatters.ts (after Plan 01):
+```typescript
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+export function formatWeight(grams: number | null | undefined, unit?: WeightUnit): string;
+export function formatPrice(cents: number | null | undefined): string;
+```
+
+From src/client/hooks/useWeightUnit.ts (after Plan 01):
+```typescript
+export function useWeightUnit(): WeightUnit;
+```
+
+From src/client/hooks/useSettings.ts (existing):
+```typescript
+export function useUpdateSetting(): UseMutationResult<Setting, Error, { key: string; value: string }>;
+```
+
+Usage pattern for every component:
+```typescript
+import { useWeightUnit } from "../hooks/useWeightUnit";
+// ...
+const unit = useWeightUnit();
+// ...
+{formatWeight(weightGrams, unit)}
+```
+</interfaces>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Add unit toggle to TotalsBar and update all call sites</name>
+  <files>
+    src/client/components/TotalsBar.tsx,
+    src/client/components/ItemCard.tsx,
+    src/client/components/CandidateCard.tsx,
+    src/client/components/CategoryHeader.tsx,
+    src/client/components/SetupCard.tsx,
+    src/client/components/ItemPicker.tsx,
+    src/client/routes/index.tsx,
+    src/client/routes/setups/$setupId.tsx
+  </files>
+  <action>
+    **TotalsBar.tsx** -- Add unit toggle and wire formatWeight:
+
+    1. Import `useWeightUnit` from `../hooks/useWeightUnit`, `useUpdateSetting` from `../hooks/useSettings`, and `WeightUnit` type from `../lib/formatters`
+    2. Inside the component function, call `const unit = useWeightUnit()` and `const updateSetting = useUpdateSetting()`
+    3. Define `const UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"]`
+    4. Add a segmented pill toggle to the right side of the TotalsBar, between the title and the stats. The toggle should be a `div` with `flex items-center gap-1 bg-gray-100 rounded-full px-1 py-0.5` containing a button per unit:
+       ```
+       <button
+         key={u}
+         onClick={() => updateSetting.mutate({ key: "weightUnit", value: u })}
+         className={`px-2 py-0.5 text-xs rounded-full transition-colors ${
+           unit === u
+             ? "bg-white text-gray-700 shadow-sm font-medium"
+             : "text-gray-400 hover:text-gray-600"
+         }`}
+       >
+         {u}
+       </button>
+       ```
+    5. Update the default stats construction (the `data?.global` branch) to pass `unit` to both `formatWeight` calls:
+       - `formatWeight(data.global.totalWeight, unit)` and `formatWeight(null, unit)`
+    6. Position the toggle: place it in the flex container between the title and stats, using a wrapper div that pushes stats to the right. The toggle should be visible but not dominant -- it's a small utility control.
+
+    **ItemCard.tsx** -- 3-line change:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside component: `const unit = useWeightUnit();`
+    3. Change `{formatWeight(weightGrams)}` to `{formatWeight(weightGrams, unit)}`
+
+    **CandidateCard.tsx** -- Same 3-line pattern as ItemCard:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside component: `const unit = useWeightUnit();`
+    3. Change `{formatWeight(weightGrams)}` to `{formatWeight(weightGrams, unit)}`
+
+    **CategoryHeader.tsx** -- Same 3-line pattern:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside component: `const unit = useWeightUnit();`
+    3. Change `{formatWeight(totalWeight)}` to `{formatWeight(totalWeight, unit)}`
+
+    **SetupCard.tsx** -- Same 3-line pattern:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside component: `const unit = useWeightUnit();`
+    3. Change `{formatWeight(totalWeight)}` to `{formatWeight(totalWeight, unit)}`
+
+    **ItemPicker.tsx** -- Same 3-line pattern:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside component: `const unit = useWeightUnit();`
+    3. Change `formatWeight(item.weightGrams)` to `formatWeight(item.weightGrams, unit)`
+
+    **routes/index.tsx** (Dashboard) -- Same 3-line pattern:
+    1. Add import: `import { useWeightUnit } from "../hooks/useWeightUnit";`
+    2. Inside `DashboardPage`: `const unit = useWeightUnit();`
+    3. Change `formatWeight(global?.totalWeight ?? null)` to `formatWeight(global?.totalWeight ?? null, unit)`
+
+    **routes/setups/$setupId.tsx** (Setup Detail) -- Same 3-line pattern:
+    1. Add import: `import { useWeightUnit } from "../../hooks/useWeightUnit";`
+    2. Inside `SetupDetailPage`: `const unit = useWeightUnit();`
+    3. Change `{formatWeight(totalWeight)}` to `{formatWeight(totalWeight, unit)}`
+
+    **Completeness check:** After all changes, grep for `formatWeight(` across `src/client/` -- every call must have a second `unit` argument EXCEPT the function definition itself in `formatters.ts`.
+  </action>
+  <verify>
+    <automated>bun test && bun run lint</automated>
+  </verify>
+  <done>
+    - All 8 components pass `unit` to `formatWeight`
+    - TotalsBar renders a g/oz/lb/kg toggle
+    - Clicking a toggle button calls `useUpdateSetting` with key "weightUnit"
+    - No `formatWeight` call site in src/client/ is missing the unit argument (except the definition)
+    - All tests and lint pass
+  </done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <name>Task 2: Verify weight unit selection end-to-end</name>
+  <action>
+    Human verifies the complete weight unit selection feature works correctly across all pages.
+
+    Start the dev servers: `bun run dev:client` and `bun run dev:server`
+    Open http://localhost:5173 in a browser and walk through the verification steps below.
+  </action>
+  <verify>
+    1. Navigate to the Collection page -- verify the TotalsBar shows a g/oz/lb/kg toggle
+    2. The default should be "g" -- weights display as before (e.g., "450g")
+    3. Click "oz" -- all weight badges on ItemCards, CategoryHeaders, and the TotalsBar total should update to ounces (e.g., "15.9 oz")
+    4. Click "kg" -- weights should update to kilograms (e.g., "0.45 kg")
+    5. Click "lb" -- weights should update to pounds (e.g., "0.99 lb")
+    6. Navigate to the Dashboard (/) -- the Collection card weight should show in the selected unit
+    7. Navigate to a Setup detail page -- the sticky sub-bar weight total and all ItemCards should show the selected unit
+    8. Refresh the page -- the selected unit should persist (still showing the last chosen unit)
+    9. Switch back to "g" -- all weights should return to the original gram display
+  </verify>
+  <done>User confirms all weight displays update correctly across all pages, unit toggle is visible and functional, and selection persists across refresh. Type "approved" or describe issues.</done>
+</task>
+
+</tasks>
+
+<verification>
+- `bun test` passes (full suite, no regressions)
+- `bun run lint` passes
+- grep `formatWeight(` across `src/client/` shows all call sites have unit parameter
+- Unit toggle is visible in TotalsBar on all pages that show it
+- Selecting a unit updates all weight displays instantly
+- Selected unit persists across page refresh
+</verification>
+
+<success_criteria>
+- UNIT-01: User can select g/oz/lb/kg from the TotalsBar toggle -- visible and functional
+- UNIT-02: Every weight display (ItemCard, CandidateCard, CategoryHeader, SetupCard, ItemPicker, Dashboard, Setup Detail, TotalsBar) reflects the selected unit
+- UNIT-03: Weight unit persists across sessions via the existing settings API (PUT/GET /api/settings/weightUnit)
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/07-weight-unit-selection/07-02-SUMMARY.md`
+</output>

.planning/phases/07-weight-unit-selection/07-02-SUMMARY.md

@@ -0,0 +1,116 @@
+---
+phase: 07-weight-unit-selection
+plan: 02
+subsystem: ui
+tags: [weight-unit-toggle, react-hooks, settings-mutation, formatWeight]
+
+# Dependency graph
+requires:
+  - phase: 07-01
+    provides: "WeightUnit type, formatWeight(grams, unit), useWeightUnit() hook"
+provides:
+  - "Segmented g/oz/lb/kg toggle in TotalsBar with settings persistence"
+  - "All weight displays across the app respect selected unit"
+affects: []
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns: [segmented-pill-toggle, settings-mutation-via-useUpdateSetting]
+
+key-files:
+  created: []
+  modified:
+    - src/client/components/TotalsBar.tsx
+    - src/client/components/ItemCard.tsx
+    - src/client/components/CandidateCard.tsx
+    - src/client/components/CategoryHeader.tsx
+    - src/client/components/SetupCard.tsx
+    - src/client/components/ItemPicker.tsx
+    - src/client/routes/index.tsx
+    - src/client/routes/setups/$setupId.tsx
+
+key-decisions:
+  - "Unit toggle placed between title and stats in TotalsBar flex container for subtle utility control placement"
+  - "Biome requires type imports after value imports in destructured import statements"
+
+patterns-established:
+  - "All formatWeight calls pass unit from useWeightUnit -- no bare formatWeight(grams) in components"
+  - "Settings mutation for UI preferences: useUpdateSetting().mutate({ key, value })"
+
+requirements-completed: [UNIT-01, UNIT-02, UNIT-03]
+
+# Metrics
+duration: 3min
+completed: 2026-03-16
+---
+
+# Phase 7 Plan 02: Weight Unit UI Wiring Summary
+
+**Segmented g/oz/lb/kg toggle in TotalsBar with all 8 weight display call sites wired to user-selected unit**
+
+## Performance
+
+- **Duration:** 3 min
+- **Started:** 2026-03-16T11:20:20Z
+- **Completed:** 2026-03-16T11:23:32Z
+- **Tasks:** 2 (1 auto + 1 checkpoint auto-approved)
+- **Files modified:** 8
+
+## Accomplishments
+- Added segmented pill toggle (g/oz/lb/kg) to TotalsBar with persistent settings via useUpdateSetting
+- Wired all 8 formatWeight call sites to pass the selected unit from useWeightUnit hook
+- All 108 existing tests pass with no regressions, lint clean
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Add unit toggle to TotalsBar and update all call sites** - `faa4378` (feat)
+2. **Task 2: Verify weight unit selection end-to-end** - auto-approved (checkpoint)
+
+## Files Created/Modified
+- `src/client/components/TotalsBar.tsx` - Added unit toggle UI, useUpdateSetting mutation, and unit-aware formatWeight calls
+- `src/client/components/ItemCard.tsx` - Added useWeightUnit import and unit parameter to formatWeight
+- `src/client/components/CandidateCard.tsx` - Added useWeightUnit import and unit parameter to formatWeight
+- `src/client/components/CategoryHeader.tsx` - Added useWeightUnit import and unit parameter to formatWeight
+- `src/client/components/SetupCard.tsx` - Added useWeightUnit import and unit parameter to formatWeight
+- `src/client/components/ItemPicker.tsx` - Added useWeightUnit import and unit parameter to formatWeight
+- `src/client/routes/index.tsx` - Added useWeightUnit import and unit parameter to Dashboard formatWeight
+- `src/client/routes/setups/$setupId.tsx` - Added useWeightUnit import and unit parameter to Setup Detail formatWeight
+
+## Decisions Made
+- Unit toggle placed between title and stats in TotalsBar's flex container, keeping it visible but non-dominant as a small utility control
+- Biome requires `type` imports after value imports in destructured statements (e.g., `{ formatWeight, type WeightUnit }`)
+
+## Deviations from Plan
+
+### Auto-fixed Issues
+
+**1. [Rule 1 - Bug] Fixed import order for WeightUnit type in TotalsBar.tsx**
+- **Found during:** Task 1 (TotalsBar modification)
+- **Issue:** Biome lint required `type WeightUnit` to come after value imports in destructured import
+- **Fix:** Changed `{ type WeightUnit, formatPrice, formatWeight }` to `{ formatPrice, formatWeight, type WeightUnit }`
+- **Files modified:** src/client/components/TotalsBar.tsx
+- **Verification:** `bun run lint` passes clean
+- **Committed in:** faa4378 (Task 1 commit)
+
+---
+
+**Total deviations:** 1 auto-fixed (1 bug - lint import ordering)
+**Impact on plan:** Trivial import ordering fix. No scope creep.
+
+## Issues Encountered
+None
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- Phase 7 (Weight Unit Selection) is fully complete
+- All 3 requirements (UNIT-01, UNIT-02, UNIT-03) satisfied
+- Ready to proceed to Phase 8 (Candidate Status & Category Icons)
+
+---
+*Phase: 07-weight-unit-selection*
+*Completed: 2026-03-16*

.planning/phases/07-weight-unit-selection/07-CONTEXT.md

@@ -0,0 +1,63 @@
+# Phase 7: Weight Unit Selection - Context
+
+**Gathered:** 2026-03-16
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Users can select a preferred weight unit (g, oz, lb, kg) and all weight displays across the app reflect that choice. Weight input stays in grams. The setting persists across sessions.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Claude's Discretion
+- Unit selector placement (TotalsBar, settings page, or elsewhere)
+- Pounds display format (traditional "2 lb 3 oz" vs decimal "2.19 lb")
+- Precision per unit (decimal places for oz, kg)
+- Default unit (grams, matching current behavior)
+- How formatWeight gets access to the setting (hook, context, parameter)
+
+</decisions>
+
+<code_context>
+## Existing Code Insights
+
+### Reusable Assets
+- `formatWeight()` in `src/client/lib/formatters.ts`: Currently `Math.round(grams) + "g"` — single conversion point for all weight display
+- `useSetting(key)` hook in `src/client/hooks/useSettings.ts`: Fetches from `/api/settings/:key`, caches with React Query
+- `useUpdateSetting()` mutation: PUT to `/api/settings/:key`, invalidates query cache
+- Settings API already exists with get/put endpoints
+
+### Established Patterns
+- Settings stored as key/value strings in SQLite `settings` table
+- React Query for server state, Zustand for UI-only state
+- Pill badges for weight/price display on ItemCard and CandidateCard (blue-50/blue-400 for weight)
+
+### Integration Points
+- `formatWeight()` call sites (~8 components): TotalsBar, ItemCard, CandidateCard, CategoryHeader, SetupCard, ItemPicker, collection route, setup detail route
+- `formatPrice()` is in the same file — similar pattern, not affected by this phase
+- TotalsBar already imports `useTotals()` and `formatWeight` — natural place for a unit toggle
+
+</code_context>
+
+<specifics>
+## Specific Ideas
+
+No specific requirements — user gave full discretion. Standard gear app patterns apply (LighterPack-style toggle).
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 07-weight-unit-selection*
+*Context gathered: 2026-03-16*

.planning/phases/07-weight-unit-selection/07-RESEARCH.md

@@ -0,0 +1,387 @@
+# Phase 7: Weight Unit Selection - Research
+
+**Researched:** 2026-03-16
+**Domain:** Weight unit conversion, display formatting, settings persistence
+**Confidence:** HIGH
+
+## Summary
+
+This phase is a display-only concern with a clean architecture. All weight data is already stored in grams (`weight_grams REAL` in SQLite). The task is to: (1) let the user pick a display unit, (2) persist that choice via the existing settings system, and (3) modify `formatWeight()` to convert grams to the selected unit before rendering. The existing `useSetting`/`useUpdateSetting` hooks and `/api/settings/:key` API handle persistence out of the box -- no schema changes or migrations needed.
+
+The codebase has a single `formatWeight(grams)` function in `src/client/lib/formatters.ts` called from exactly 8 components. Every weight display flows through this function, so the conversion is a single-point change. The challenge is threading the unit preference to `formatWeight` -- currently a pure function with no access to React state. The cleanest approach is to add a `unit` parameter and create a `useWeightUnit()` hook that components use to get the current unit, then pass it to `formatWeight`.
+
+**Primary recommendation:** Add a `unit` parameter to `formatWeight(grams, unit)`, create a `useWeightUnit()` convenience hook wrapping `useSetting("weightUnit")`, and place a small unit toggle in the TotalsBar. Keep weight input always in grams -- this is a display-only feature per the requirements and out-of-scope list.
+
+<user_constraints>
+## User Constraints (from CONTEXT.md)
+
+### Locked Decisions
+(No locked decisions -- all implementation details are at Claude's discretion)
+
+### Claude's Discretion
+- Unit selector placement (TotalsBar, settings page, or elsewhere)
+- Pounds display format (traditional "2 lb 3 oz" vs decimal "2.19 lb")
+- Precision per unit (decimal places for oz, kg)
+- Default unit (grams, matching current behavior)
+- How formatWeight gets access to the setting (hook, context, parameter)
+
+### Deferred Ideas (OUT OF SCOPE)
+None -- discussion stayed within phase scope
+</user_constraints>
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| UNIT-01 | User can select preferred weight unit (g, oz, lb, kg) from settings | Settings API already exists; `useSetting`/`useUpdateSetting` hooks ready; unit selector component needed in TotalsBar |
+| UNIT-02 | All weight displays across the app reflect the selected unit | Single `formatWeight()` function is the sole conversion point; 8 call sites across TotalsBar, ItemCard, CandidateCard, CategoryHeader, SetupCard, ItemPicker, collection route, setup detail route |
+| UNIT-03 | Weight unit preference persists across sessions | `settings` table + `/api/settings/:key` upsert endpoint already handle this -- just use key `"weightUnit"` |
+</phase_requirements>
+
+## Standard Stack
+
+### Core
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| React 19 | 19.x | UI framework | Already in project |
+| TanStack React Query | 5.x | Server state / caching | Already used for all data fetching; `useSetting` hook wraps it |
+| Hono | 4.x | API server | Settings routes already exist |
+| Drizzle ORM | latest | Database access | Settings table already defined |
+
+### Supporting
+No additional libraries needed. This phase requires zero new dependencies.
+
+### Alternatives Considered
+| Instead of | Could Use | Tradeoff |
+|------------|-----------|----------|
+| Parameter-based `formatWeight(g, unit)` | React Context provider | Context adds unnecessary complexity for a single value; parameter is explicit, testable, and avoids re-render cascades |
+| Zustand store for unit | `useSetting` hook (React Query) | Unit is server-persisted state, not ephemeral UI state; React Query is the correct layer per project conventions |
+
+## Architecture Patterns
+
+### Recommended Approach
+
+No new files except a small `useWeightUnit` convenience hook. The changes are surgical:
+
+```
+src/client/
+  lib/
+    formatters.ts         # MODIFY: add unit parameter to formatWeight
+  hooks/
+    useWeightUnit.ts      # NEW: convenience hook wrapping useSetting("weightUnit")
+  components/
+    TotalsBar.tsx          # MODIFY: add unit toggle control
+    ItemCard.tsx           # MODIFY: pass unit to formatWeight
+    CandidateCard.tsx      # MODIFY: pass unit to formatWeight
+    CategoryHeader.tsx     # MODIFY: pass unit to formatWeight
+    SetupCard.tsx          # MODIFY: pass unit to formatWeight
+    ItemPicker.tsx         # MODIFY: pass unit to formatWeight
+  routes/
+    index.tsx              # MODIFY: pass unit to formatWeight
+    setups/$setupId.tsx    # MODIFY: pass unit to formatWeight
+```
+
+### Pattern 1: Weight Unit Type and Conversion Constants
+
+**What:** Define a `WeightUnit` type and conversion map as a simple module constant.
+**When to use:** Everywhere unit-related logic is needed.
+**Example:**
+
+```typescript
+// In src/client/lib/formatters.ts
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+
+const GRAMS_PER_OZ = 28.3495;
+const GRAMS_PER_LB = 453.592;
+const GRAMS_PER_KG = 1000;
+
+export function formatWeight(
+  grams: number | null | undefined,
+  unit: WeightUnit = "g",
+): string {
+  if (grams == null) return "--";
+
+  switch (unit) {
+    case "g":
+      return `${Math.round(grams)}g`;
+    case "oz":
+      return `${(grams / GRAMS_PER_OZ).toFixed(1)} oz`;
+    case "lb":
+      return `${(grams / GRAMS_PER_LB).toFixed(2)} lb`;
+    case "kg":
+      return `${(grams / GRAMS_PER_KG).toFixed(2)} kg`;
+  }
+}
+```
+
+### Pattern 2: Convenience Hook
+
+**What:** A thin hook that reads the weight unit setting and returns a typed value with a sensible default.
+**When to use:** Any component that calls `formatWeight`.
+**Example:**
+
+```typescript
+// In src/client/hooks/useWeightUnit.ts
+import { useSetting } from "./useSettings";
+import type { WeightUnit } from "../lib/formatters";
+
+const VALID_UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"];
+
+export function useWeightUnit(): WeightUnit {
+  const { data } = useSetting("weightUnit");
+  if (data && VALID_UNITS.includes(data as WeightUnit)) {
+    return data as WeightUnit;
+  }
+  return "g"; // default matches current behavior
+}
+```
+
+### Pattern 3: Unit Selector in TotalsBar
+
+**What:** A small segmented control or dropdown in the TotalsBar for switching units.
+**When to use:** Global weight unit selection, always visible.
+**Example concept:**
+
+```typescript
+// Segmented pill buttons in TotalsBar
+const UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"];
+
+// Small inline toggle alongside stats
+<div className="flex items-center gap-1 bg-gray-100 rounded-full px-1 py-0.5">
+  {UNITS.map((u) => (
+    <button
+      key={u}
+      onClick={() => updateSetting.mutate({ key: "weightUnit", value: u })}
+      className={`px-2 py-0.5 text-xs rounded-full transition-colors ${
+        unit === u
+          ? "bg-white text-gray-700 shadow-sm font-medium"
+          : "text-gray-400 hover:text-gray-600"
+      }`}
+    >
+      {u}
+    </button>
+  ))}
+</div>
+```
+
+### Anti-Patterns to Avoid
+- **Converting on the server side:** Database stores grams, API returns grams. Conversion is purely a display concern -- never modify the API layer.
+- **Using React Context for a single value:** The project uses React Query for server state. Adding a Context provider for one setting breaks convention and introduces unnecessary complexity.
+- **Storing converted values:** Always store grams in the database. The `weightUnit` setting is a display preference, not a data transformation.
+- **Changing weight input fields:** The requirements explicitly keep input in grams (see Out of Scope in REQUIREMENTS.md: "Per-item weight input in multiple units" is excluded). Input labels stay as "Weight (g)".
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Setting persistence | Custom localStorage + API sync | Existing `useSetting`/`useUpdateSetting` hooks + settings API | Already handles cache invalidation and server persistence |
+| Unit conversion | Complex conversion library | Simple division constants (28.3495, 453.592, 1000) | Only 4 units, all linear conversions from grams -- a library is overkill |
+
+**Key insight:** The entire feature is a ~30-line formatter change + a small UI toggle + updating 8 call sites. No external library is needed.
+
+## Common Pitfalls
+
+### Pitfall 1: Floating-Point Display Precision
+**What goes wrong:** Showing too many decimal places (e.g., "42.328947 oz") or too few (e.g., "0 kg" for a 450g item).
+**Why it happens:** Different units have different natural precision ranges.
+**How to avoid:** Use unit-specific precision: `g` = 0 decimals (round), `oz` = 1 decimal, `lb` = 2 decimals, `kg` = 2 decimals. These match gear community conventions (LighterPack and similar apps use comparable precision).
+**Warning signs:** Items showing "0 lb" or "0.0 oz" when they have measurable weight.
+
+### Pitfall 2: Null/Undefined Weight Handling
+**What goes wrong:** Conversion math on null values produces NaN or "NaN oz".
+**Why it happens:** Many items have `weightGrams: null` (optional field).
+**How to avoid:** The existing `if (grams == null) return "--"` guard at the top of `formatWeight` handles this. Keep it as the first check before any unit logic.
+**Warning signs:** "NaN" or "undefined oz" appearing in the UI.
+
+### Pitfall 3: Forgetting a Call Site
+**What goes wrong:** One component still shows grams while everything else shows the selected unit.
+**Why it happens:** `formatWeight` is called in 8 different files. Missing one is easy.
+**How to avoid:** Grep for all `formatWeight` call sites. The complete list is: TotalsBar.tsx, ItemCard.tsx, CandidateCard.tsx, CategoryHeader.tsx, SetupCard.tsx, ItemPicker.tsx, `routes/index.tsx`, `routes/setups/$setupId.tsx`. Update all 8.
+**Warning signs:** Inconsistent unit display across different views.
+
+### Pitfall 4: Default Unit Breaks Existing Behavior
+**What goes wrong:** If the default isn't "g", existing users see different numbers on upgrade.
+**Why it happens:** No `weightUnit` setting exists in the database yet.
+**How to avoid:** Default to `"g"` when `useSetting("weightUnit")` returns null (404 from API). This preserves backward compatibility -- the app looks identical until the user changes the unit.
+**Warning signs:** Weights appearing in ounces on first load without user action.
+
+### Pitfall 5: Rounding Drift on Edit Cycles
+**What goes wrong:** User edits an item, weight displays as "42.3 oz", they save without changing weight, but the stored value shifts.
+**Why it happens:** Would only occur if input fields converted units. Since input stays in grams (per Out of Scope), this cannot happen.
+**How to avoid:** Keep all input fields showing grams. The label says "Weight (g)" and the stored value is always `weight_grams`. Display conversion is one-directional: grams -> display unit.
+**Warning signs:** N/A -- this is prevented by the "input stays in grams" design decision.
+
+### Pitfall 6: React Query Cache Staleness
+**What goes wrong:** User changes unit but some components still show the old unit until they re-render.
+**Why it happens:** The `useUpdateSetting` mutation invalidates `["settings", "weightUnit"]`, but components caching the old value might not immediately re-render.
+**How to avoid:** Since `useWeightUnit()` wraps `useSetting("weightUnit")` which uses React Query with the same query key, invalidation on mutation will trigger re-renders in all subscribed components. This works out of the box.
+**Warning signs:** Temporary inconsistency after changing units -- should resolve within one render cycle.
+
+## Code Examples
+
+### Complete formatWeight Implementation
+
+```typescript
+// src/client/lib/formatters.ts
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+
+const GRAMS_PER_OZ = 28.3495;
+const GRAMS_PER_LB = 453.592;
+const GRAMS_PER_KG = 1000;
+
+export function formatWeight(
+  grams: number | null | undefined,
+  unit: WeightUnit = "g",
+): string {
+  if (grams == null) return "--";
+
+  switch (unit) {
+    case "g":
+      return `${Math.round(grams)}g`;
+    case "oz":
+      return `${(grams / GRAMS_PER_OZ).toFixed(1)} oz`;
+    case "lb":
+      return `${(grams / GRAMS_PER_LB).toFixed(2)} lb`;
+    case "kg":
+      return `${(grams / GRAMS_PER_KG).toFixed(2)} kg`;
+  }
+}
+```
+
+### useWeightUnit Hook
+
+```typescript
+// src/client/hooks/useWeightUnit.ts
+import { useSetting } from "./useSettings";
+import type { WeightUnit } from "../lib/formatters";
+
+const VALID_UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"];
+
+export function useWeightUnit(): WeightUnit {
+  const { data } = useSetting("weightUnit");
+  if (data && VALID_UNITS.includes(data as WeightUnit)) {
+    return data as WeightUnit;
+  }
+  return "g";
+}
+```
+
+### Component Usage Pattern (e.g., ItemCard)
+
+```typescript
+// Before:
+import { formatWeight } from "../lib/formatters";
+// ...
+{formatWeight(weightGrams)}
+
+// After:
+import { formatWeight } from "../lib/formatters";
+import { useWeightUnit } from "../hooks/useWeightUnit";
+// ...
+const unit = useWeightUnit();
+// ...
+{formatWeight(weightGrams, unit)}
+```
+
+### Stats Prop Pattern (TotalsBar and routes/index.tsx)
+
+When `formatWeight` is called inside a stats array construction (not directly in JSX), the unit must be available in that scope:
+
+```typescript
+// routes/index.tsx - Dashboard
+const unit = useWeightUnit();
+// ...
+stats={[
+  { label: "Items", value: String(global?.itemCount ?? 0) },
+  { label: "Weight", value: formatWeight(global?.totalWeight ?? null, unit) },
+  { label: "Cost", value: formatPrice(global?.totalCost ?? null) },
+]}
+```
+
+## State of the Art
+
+| Old Approach | Current Approach | When Changed | Impact |
+|--------------|------------------|--------------|--------|
+| `Math.round(grams) + "g"` (hardcoded) | `formatWeight(grams, unit)` (parameterized) | This phase | All weight displays become unit-aware |
+
+**Deprecated/outdated:**
+- Nothing to deprecate. The old `formatWeight(grams)` signature remains backward-compatible since `unit` defaults to `"g"`.
+
+## Design Recommendations (Claude's Discretion Areas)
+
+### Unit Selector Placement: TotalsBar
+**Recommendation:** Place the unit toggle in the TotalsBar, right side, near the weight stat. The TotalsBar is visible on every page that shows weight (collection, setups). It is the natural place for a global display preference.
+
+### Pounds Display Format: Decimal
+**Recommendation:** Use decimal pounds (`"2.19 lb"`) rather than traditional `"2 lb 3 oz"`. Reasons: (1) simpler implementation, (2) consistent with how LighterPack handles it, (3) easier to compare weights at a glance, (4) traditional format mixes two units which complicates the mental model.
+
+### Precision Per Unit
+**Recommendation:**
+- `g`: 0 decimal places (integers, matching current behavior)
+- `oz`: 1 decimal place (standard for gear weights -- e.g., "14.2 oz")
+- `lb`: 2 decimal places (e.g., "2.19 lb")
+- `kg`: 2 decimal places (e.g., "1.36 kg")
+
+### Default Unit: Grams
+**Recommendation:** Default to `"g"` -- this preserves backward compatibility. When `useSetting("weightUnit")` returns null (no setting in DB), the app behaves identically to today.
+
+### How formatWeight Gets the Unit: Parameter
+**Recommendation:** Pass `unit` as a parameter rather than using React Context or a global. This keeps `formatWeight` a pure function (testable without React), follows the existing pattern of the codebase (no Context providers used anywhere), and makes the data flow explicit.
+
+## Open Questions
+
+1. **Should the unit toggle appear in setup detail view's sub-bar?**
+   - What we know: Setup detail has its own sticky bar below TotalsBar showing setup-specific stats including weight
+   - What's unclear: Whether the global TotalsBar is visible enough from setup detail view
+   - Recommendation: The TotalsBar is sticky at the top on every page. Its toggle applies globally. No need for a second toggle in the setup bar.
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test runner (built-in) |
+| Config file | None (uses bun defaults) |
+| Quick run command | `bun test` |
+| Full suite command | `bun test` |
+
+### Phase Requirements -> Test Map
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| UNIT-01 | Settings API accepts and returns weightUnit value | unit | `bun test tests/services/settings.test.ts -t "weightUnit"` | No -- Wave 0 |
+| UNIT-02 | formatWeight converts grams to all 4 units correctly | unit | `bun test tests/lib/formatters.test.ts` | No -- Wave 0 |
+| UNIT-02 | formatWeight handles null/undefined input for all units | unit | `bun test tests/lib/formatters.test.ts` | No -- Wave 0 |
+| UNIT-03 | Settings PUT upserts weightUnit, GET retrieves it | unit | `bun test tests/routes/settings.test.ts` | No -- Wave 0 |
+
+### Sampling Rate
+- **Per task commit:** `bun test`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+- [ ] `tests/lib/formatters.test.ts` -- covers UNIT-02 (formatWeight with all units, null handling, precision)
+- [ ] `tests/routes/settings.test.ts` -- covers UNIT-01, UNIT-03 (settings API for weightUnit key)
+
+## Sources
+
+### Primary (HIGH confidence)
+- Codebase inspection: `src/client/lib/formatters.ts`, `src/client/hooks/useSettings.ts`, `src/server/routes/settings.ts`, `src/db/schema.ts` -- all directly read and analyzed
+- Codebase inspection: All 8 `formatWeight` call sites verified via grep
+
+### Secondary (MEDIUM confidence)
+- [LighterPack community patterns](https://backpackers.com/how-to/calculate-backpack-weight/) -- unit toggle between g/oz/lb/kg is standard in gear apps
+- [Metric conversion constants](https://www.metric-conversions.org/weight/) -- 1 oz = 28.3495g, 1 lb = 453.592g, 1 kg = 1000g (verified against international standard)
+
+### Tertiary (LOW confidence)
+- None
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH -- no new dependencies, all existing infrastructure verified in codebase
+- Architecture: HIGH -- single conversion point (`formatWeight`) confirmed, settings system verified working
+- Pitfalls: HIGH -- all based on direct code inspection of null handling, call sites, and data flow
+
+**Research date:** 2026-03-16
+**Valid until:** 2026-04-16 (stable -- no external dependencies or fast-moving APIs)

.planning/phases/07-weight-unit-selection/07-VALIDATION.md

@@ -0,0 +1,77 @@
+---
+phase: 7
+slug: weight-unit-selection
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-16
+---
+
+# Phase 7 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Bun test runner (built-in) |
+| **Config file** | None (uses bun defaults) |
+| **Quick run command** | `bun test` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 07-01-01 | 01 | 1 | UNIT-01 | unit | `bun test tests/routes/settings.test.ts` | No — Wave 0 | ⬜ pending |
+| 07-01-02 | 01 | 1 | UNIT-02 | unit | `bun test tests/lib/formatters.test.ts` | No — Wave 0 | ⬜ pending |
+| 07-01-03 | 01 | 1 | UNIT-03 | unit | `bun test tests/routes/settings.test.ts` | No — Wave 0 | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] `tests/lib/formatters.test.ts` — formatWeight with all 4 units, null handling, precision
+- [ ] `tests/routes/settings.test.ts` — settings API for weightUnit key (GET/PUT)
+
+*Existing test infrastructure (bun test, helpers/db.ts) covers framework setup.*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Unit toggle renders in TotalsBar | UNIT-01 | UI component rendering | Open app, verify g/oz/lb/kg toggle visible in TotalsBar |
+| All weight displays update on unit change | UNIT-02 | Visual verification across 8 components | Switch unit, check ItemCard, CandidateCard, CategoryHeader, SetupCard, setup detail, collection route |
+| Setting persists across browser refresh | UNIT-03 | Browser session state | Select "oz", refresh page, verify still shows "oz" |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/07-weight-unit-selection/07-VERIFICATION.md

@@ -0,0 +1,138 @@
+---
+phase: 07-weight-unit-selection
+verified: 2026-03-16T12:00:00Z
+status: human_needed
+score: 7/8 must-haves verified
+human_verification:
+  - test: "Navigate to Collection page and verify unit toggle is visible in TotalsBar"
+    expected: "A segmented g/oz/lb/kg pill toggle appears in the top bar between the title and stats"
+    why_human: "Cannot verify visual rendering or UI element presence without a browser"
+  - test: "Click 'oz' in the toggle, verify all weight badges update to ounces"
+    expected: "ItemCards, CategoryHeaders, TotalsBar total, SetupCard weights all update to e.g. '15.9 oz'"
+    why_human: "React Query invalidation and re-render behavior requires runtime verification"
+  - test: "Navigate to Dashboard, then to a Setup detail page, verify weights use selected unit"
+    expected: "All weight displays across pages reflect the chosen unit after selecting 'oz', 'lb', or 'kg'"
+    why_human: "Cross-page state propagation via settings API requires runtime verification"
+  - test: "Select 'kg', then refresh the page"
+    expected: "After refresh, weights still display in kg (unit persists)"
+    why_human: "Settings persistence across sessions requires runtime verification"
+---
+
+# Phase 7: Weight Unit Selection Verification Report
+
+**Phase Goal:** Users see all weights in their preferred unit across the entire app
+**Verified:** 2026-03-16T12:00:00Z
+**Status:** human_needed
+**Re-verification:** No - initial verification
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | formatWeight converts grams to g, oz, lb, kg with correct precision | VERIFIED | `src/client/lib/formatters.ts` switch statement with `toFixed(1)` oz, `toFixed(2)` lb/kg. 21 tests all pass. |
+| 2 | formatWeight defaults to grams when no unit is specified (backward compatible) | VERIFIED | Signature `unit: WeightUnit = "g"`. Test: `formatWeight(100)` returns `"100g"`. |
+| 3 | formatWeight handles null/undefined input for all units | VERIFIED | Null guard `if (grams == null) return "--"` fires before switch. 7 null/undefined tests pass. |
+| 4 | useWeightUnit hook returns a valid WeightUnit from settings, defaulting to 'g' | VERIFIED | `useWeightUnit.ts` validates against `VALID_UNITS` array and returns `"g"` fallback. |
+| 5 | User can see a unit toggle (g/oz/lb/kg) in the TotalsBar | ? NEEDS HUMAN | Toggle code exists in TotalsBar.tsx (lines 70-90), but visual rendering requires browser. |
+| 6 | Clicking a unit in the toggle changes all weight displays across the app | ? NEEDS HUMAN | `useUpdateSetting.mutate({ key: "weightUnit", value: u })` wired. React Query invalidation behavior requires runtime. |
+| 7 | Weight unit selection persists after page refresh | ? NEEDS HUMAN | Persistence via `GET /api/settings/weightUnit` in `useSetting`. Requires runtime verification. |
+| 8 | Every weight display in the app uses the selected unit | VERIFIED | All 9 formatWeight call sites in `src/client/` pass `unit` argument. Grep confirms no bare `formatWeight(grams)` calls remain in components. |
+
+**Score:** 5/5 automated truths verified, 3/3 runtime truths require human verification
+
+### Required Artifacts
+
+#### Plan 01 Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/client/lib/formatters.ts` | WeightUnit type export and parameterized formatWeight | VERIFIED | Exports `WeightUnit`, `formatWeight`, `formatPrice`. Contains switch for all 4 units. 28 lines, substantive. |
+| `src/client/hooks/useWeightUnit.ts` | Convenience hook wrapping useSetting for weight unit | VERIFIED | Exports `useWeightUnit`. Imports `WeightUnit` from formatters, `useSetting` from useSettings. 13 lines, substantive. |
+| `tests/lib/formatters.test.ts` | Unit tests for formatWeight with all 4 units and edge cases | VERIFIED | 98 lines (min_lines=30 satisfied). 21 tests across 7 describe blocks covering g/oz/lb/kg, null/undefined, backward compat, zero, edge cases. All pass. |
+
+#### Plan 02 Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/client/components/TotalsBar.tsx` | Unit toggle UI and unit-aware weight display | VERIFIED | Contains `useWeightUnit`, `useUpdateSetting`, UNITS array, segmented pill toggle JSX. `formatWeight` calls pass `unit`. |
+| `src/client/components/ItemCard.tsx` | Unit-aware item weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(weightGrams, unit)` on line 127. |
+| `src/client/components/CandidateCard.tsx` | Unit-aware candidate weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(weightGrams, unit)` on line 93. |
+| `src/client/components/CategoryHeader.tsx` | Unit-aware category total weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(totalWeight, unit)` on line 90. |
+| `src/client/components/SetupCard.tsx` | Unit-aware setup weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(totalWeight, unit)` on line 35. |
+| `src/client/components/ItemPicker.tsx` | Unit-aware item picker weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(item.weightGrams, unit)` on line 119. |
+| `src/client/routes/index.tsx` | Unit-aware dashboard weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(global?.totalWeight ?? null, unit)` on line 34. |
+| `src/client/routes/setups/$setupId.tsx` | Unit-aware setup detail weight display | VERIFIED | Contains `useWeightUnit`. `formatWeight(totalWeight, unit)` on line 110. |
+
+### Key Link Verification
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `useWeightUnit.ts` | `useSettings.ts` | `useSetting('weightUnit')` | WIRED | Line 7: `const { data } = useSetting("weightUnit");` |
+| `useWeightUnit.ts` | `formatters.ts` | imports WeightUnit type | WIRED | Line 1: `import type { WeightUnit } from "../lib/formatters";` |
+| `TotalsBar.tsx` | `/api/settings/weightUnit` | useUpdateSetting mutation | WIRED | Line 76-79: `updateSetting.mutate({ key: "weightUnit", value: u })` |
+| `ItemCard.tsx` | `useWeightUnit.ts` | useWeightUnit hook import | WIRED | Line 1: `import { useWeightUnit } from "../hooks/useWeightUnit";` — called at line 29, used at line 127 |
+| `TotalsBar.tsx` | `formatters.ts` | formatWeight(grams, unit) | WIRED | Lines 33, 39: both calls pass `unit` from `useWeightUnit()` |
+
+### Requirements Coverage
+
+| Requirement | Source Plan(s) | Description | Status | Evidence |
+|-------------|---------------|-------------|--------|----------|
+| UNIT-01 | 07-02-PLAN | User can select preferred weight unit (g, oz, lb, kg) from settings | VERIFIED (automated) / NEEDS HUMAN (runtime) | Segmented toggle code in TotalsBar.tsx lines 70-90. Runtime: needs human to confirm visual and click behavior. |
+| UNIT-02 | 07-01-PLAN, 07-02-PLAN | All weight displays across the app reflect the selected unit | VERIFIED | All 9 formatWeight call sites in components pass `unit`. No bare `formatWeight(grams)` calls remain. |
+| UNIT-03 | 07-01-PLAN, 07-02-PLAN | Weight unit preference persists across sessions | VERIFIED (mechanism) / NEEDS HUMAN (runtime) | `useSetting("weightUnit")` reads from `/api/settings/weightUnit`. `useUpdateSetting` writes to same endpoint. Persistence across refresh requires runtime verification. |
+
+No orphaned requirements. REQUIREMENTS.md marks all three as complete for Phase 7. All three requirement IDs appear in at least one plan's `requirements` field.
+
+### Anti-Patterns Found
+
+| File | Line | Pattern | Severity | Impact |
+|------|------|---------|----------|--------|
+| — | — | None found | — | — |
+
+Scanned all 11 modified files. No TODOs, FIXMEs, placeholder comments, empty implementations, or stub returns found. All `formatWeight` calls outside `formatters.ts` carry the `unit` argument.
+
+### Human Verification Required
+
+#### 1. Unit Toggle Visibility
+
+**Test:** Start `bun run dev:client` and `bun run dev:server`, navigate to http://localhost:5173/collection
+**Expected:** A segmented pill toggle showing g / oz / lb / kg is visible in the sticky top bar, positioned between the GearBox title and the stats (items / total / spent)
+**Why human:** Visual rendering cannot be verified programmatically
+
+#### 2. Unit Toggle Click Behavior
+
+**Test:** With the app running, click "oz" in the toggle on the Collection page
+**Expected:** All weight badges on ItemCards, CategoryHeader totals, and the TotalsBar total update immediately to ounce values (e.g., "15.9 oz"). No page reload required.
+**Why human:** React Query cache invalidation and live re-render require runtime observation
+
+#### 3. Cross-Page Unit Consistency
+
+**Test:** Select "lb" on the Collection page, then navigate to the Dashboard (/), then navigate to a Setup detail page
+**Expected:** The Dashboard Collection card weight shows in lb; all weights in the Setup detail sticky bar and ItemCards show in lb
+**Why human:** Cross-page state propagation via TanStack Router and shared React Query cache requires runtime verification
+
+#### 4. Persistence Across Refresh
+
+**Test:** Select "kg", then hard-refresh the page (Ctrl+R or F5)
+**Expected:** After refresh, all weights still display in kg. The kg button appears active/highlighted in the toggle.
+**Why human:** Browser session handling and settings API round-trip require runtime verification
+
+### Gaps Summary
+
+No automated gaps found. All artifacts exist, are substantive, and are correctly wired. The 3 human verification items are standard runtime behaviors (visual rendering, live updates, persistence) that cannot be verified statically.
+
+The implementation is complete and correct based on static analysis:
+- `formatWeight` conversion math is verified by 21 passing tests
+- All 8 component call sites pass `unit` from `useWeightUnit()` — confirmed by exhaustive grep
+- TotalsBar contains the full toggle UI with `useUpdateSetting` wired to `weightUnit` key
+- `useWeightUnit` correctly wraps `useSetting("weightUnit")` with type validation and "g" default
+- Full test suite (108 tests) passes with no regressions
+- Lint clean (78 files, no issues)
+- All 4 phase commits verified in git history (431c179, 6cac0a3, ada3791, faa4378)
+
+---
+
+_Verified: 2026-03-16T12:00:00Z_
+_Verifier: Claude (gsd-verifier)_

.planning/phases/08-search-filter-and-candidate-status/08-01-PLAN.md

@@ -0,0 +1,240 @@
+---
+phase: 08-search-filter-and-candidate-status
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/db/schema.ts
+  - src/shared/schemas.ts
+  - src/server/services/thread.service.ts
+  - src/client/hooks/useThreads.ts
+  - src/client/hooks/useCandidates.ts
+  - src/client/components/StatusBadge.tsx
+  - src/client/components/CandidateCard.tsx
+  - tests/helpers/db.ts
+  - tests/services/thread.service.test.ts
+autonomous: true
+requirements: [CAND-01, CAND-02, CAND-03]
+
+must_haves:
+  truths:
+    - "Each candidate displays a status badge showing one of three statuses: researching, ordered, or arrived"
+    - "User can click a status badge to open a popup menu and change the candidate's status to any of the three options"
+    - "New candidates automatically have status 'researching' without the user needing to set it"
+  artifacts:
+    - path: "src/db/schema.ts"
+      provides: "status column on threadCandidates table"
+      contains: "status: text(\"status\").notNull().default(\"researching\")"
+    - path: "src/shared/schemas.ts"
+      provides: "candidateStatusSchema Zod enum"
+      exports: ["candidateStatusSchema"]
+    - path: "src/server/services/thread.service.ts"
+      provides: "status field in candidate CRUD operations"
+      contains: "status: threadCandidates.status"
+    - path: "src/client/components/StatusBadge.tsx"
+      provides: "Clickable status badge with popup menu"
+      exports: ["StatusBadge"]
+    - path: "src/client/components/CandidateCard.tsx"
+      provides: "CandidateCard renders StatusBadge in pill row"
+      contains: "StatusBadge"
+    - path: "tests/helpers/db.ts"
+      provides: "status column in test helper CREATE TABLE"
+      contains: "status TEXT NOT NULL DEFAULT 'researching'"
+  key_links:
+    - from: "src/client/components/StatusBadge.tsx"
+      to: "/api/threads/:id/candidates/:candidateId"
+      via: "useUpdateCandidate mutation"
+      pattern: "onStatusChange"
+    - from: "src/server/services/thread.service.ts"
+      to: "src/db/schema.ts"
+      via: "threadCandidates.status in select and update"
+      pattern: "threadCandidates\\.status"
+    - from: "src/client/components/CandidateCard.tsx"
+      to: "src/client/components/StatusBadge.tsx"
+      via: "StatusBadge component in pill row"
+      pattern: "<StatusBadge"
+---
+
+<objective>
+Add candidate status tracking (researching/ordered/arrived) as a full vertical slice: schema migration, service/Zod updates, tests, and clickable status badge UI on CandidateCard.
+
+Purpose: Let users track purchase progress for candidates they are evaluating in planning threads.
+Output: Working status badge on each candidate card with popup menu to change status.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/08-search-filter-and-candidate-status/08-CONTEXT.md
+@.planning/phases/08-search-filter-and-candidate-status/08-RESEARCH.md
+
+@src/db/schema.ts
+@src/shared/schemas.ts
+@src/shared/types.ts
+@src/server/services/thread.service.ts
+@src/client/hooks/useThreads.ts
+@src/client/hooks/useCandidates.ts
+@src/client/components/CandidateCard.tsx
+@tests/helpers/db.ts
+@tests/services/thread.service.test.ts
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/shared/types.ts:
+```typescript
+export type CreateCandidate = z.infer<typeof createCandidateSchema>;
+export type UpdateCandidate = z.infer<typeof updateCandidateSchema>;
+export type ThreadCandidate = typeof threadCandidates.$inferSelect;
+```
+
+From src/client/hooks/useCandidates.ts:
+```typescript
+export function useUpdateCandidate(threadId: number) {
+  // mutationFn: ({ candidateId, ...data }) => apiPut(...)
+  // Already accepts partial updates. Use for status changes.
+}
+```
+
+From src/client/hooks/useThreads.ts:
+```typescript
+interface CandidateWithCategory {
+  id: number; threadId: number; name: string;
+  weightGrams: number | null; priceCents: number | null;
+  categoryId: number; notes: string | null;
+  productUrl: string | null; imageFilename: string | null;
+  createdAt: string; updatedAt: string;
+  categoryName: string; categoryIcon: string;
+  // status field NOT YET present -- Task 1 adds it
+}
+```
+
+From src/client/components/CandidateCard.tsx:
+```typescript
+interface CandidateCardProps {
+  id: number; name: string; weightGrams: number | null;
+  priceCents: number | null; categoryName: string;
+  categoryIcon: string; imageFilename: string | null;
+  productUrl?: string | null; threadId: number; isActive: boolean;
+  // status prop NOT YET present -- Task 2 adds it
+}
+```
+
+From src/client/lib/iconData.tsx:
+```typescript
+export function LucideIcon({ name, size, className }: {
+  name: string; size?: number; className?: string;
+}): JSX.Element;
+// Valid icon names for status: "search", "truck", "check"
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: Add status column and update backend + tests</name>
+  <files>src/db/schema.ts, src/shared/schemas.ts, src/server/services/thread.service.ts, src/client/hooks/useThreads.ts, src/client/hooks/useCandidates.ts, tests/helpers/db.ts, tests/services/thread.service.test.ts</files>
+  <behavior>
+    - Test: createCandidate without status returns a candidate with status "researching"
+    - Test: createCandidate with status "ordered" returns a candidate with status "ordered"
+    - Test: updateCandidate can change status from "researching" to "ordered"
+    - Test: updateCandidate can change status from "ordered" to "arrived"
+    - Test: getThreadWithCandidates includes status field on each candidate
+  </behavior>
+  <action>
+    1. **Schema migration** -- Add status column to `threadCandidates` in `src/db/schema.ts`:
+       ```typescript
+       status: text("status").notNull().default("researching"),
+       ```
+       Then run `bun run db:generate && bun run db:push` to apply.
+
+    2. **Zod schemas** -- In `src/shared/schemas.ts`, add:
+       ```typescript
+       export const candidateStatusSchema = z.enum(["researching", "ordered", "arrived"]);
+       ```
+       Add `status: candidateStatusSchema.optional()` to `createCandidateSchema`. Since `updateCandidateSchema = createCandidateSchema.partial()`, it automatically includes status as optional.
+
+    3. **Service updates** -- In `src/server/services/thread.service.ts`:
+       - In `getThreadWithCandidates`, add `status: threadCandidates.status` to the select object (between `imageFilename` and `createdAt`).
+       - In `createCandidate`, add `status: data.status ?? "researching"` to the values object.
+       - In `updateCandidate`, add `status` to the data type: `status: "researching" | "ordered" | "arrived"`.
+
+    4. **Client type updates** -- In `src/client/hooks/useThreads.ts`, add `status: "researching" | "ordered" | "arrived"` to `CandidateWithCategory` interface. In `src/client/hooks/useCandidates.ts`, add `status?: "researching" | "ordered" | "arrived"` to `CandidateResponse` interface.
+
+    5. **Test helper** -- In `tests/helpers/db.ts`, add `status TEXT NOT NULL DEFAULT 'researching'` to the `thread_candidates` CREATE TABLE statement (after `image_filename TEXT` line).
+
+    6. **Service tests** -- In `tests/services/thread.service.test.ts`, add a describe block "candidate status" with the tests from the behavior section above.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test tests/services/thread.service.test.ts</automated>
+  </verify>
+  <done>Status column exists in schema, migration applied, all CRUD operations handle status field, all tests pass including new status tests.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Create StatusBadge component and wire into CandidateCard</name>
+  <files>src/client/components/StatusBadge.tsx, src/client/components/CandidateCard.tsx</files>
+  <action>
+    1. **Create `src/client/components/StatusBadge.tsx`** -- A clickable pill badge with popup menu:
+       - Props: `status: "researching" | "ordered" | "arrived"`, `onStatusChange: (status: "researching" | "ordered" | "arrived") => void`
+       - Status config map:
+         ```typescript
+         const STATUS_CONFIG = {
+           researching: { icon: "search", label: "Researching" },
+           ordered: { icon: "truck", label: "Ordered" },
+           arrived: { icon: "check", label: "Arrived" },
+         } as const;
+         ```
+       - Render as a pill button (muted gray tones per user decision -- NOT semantic colors):
+         - Use `bg-gray-100 text-gray-600` styling, similar neutral tone to the category pill
+         - Show `LucideIcon` (size 14) + text label
+       - On click: call `e.stopPropagation()` (prevent card click propagation per pitfall #3), toggle popup menu open/closed
+       - Popup menu: `position: absolute` below the badge, `right-0`, with 3 options (each showing icon + label). Use a `containerRef` + `useEffect` mousedown listener for click-outside dismiss (same pattern as `CategoryPicker`). Pressing Escape also closes the menu.
+       - When an option is clicked: call `onStatusChange(selectedStatus)`, close the menu.
+       - Show a subtle checkmark or different background on the currently active status in the menu.
+
+    2. **Update `src/client/components/CandidateCard.tsx`**:
+       - Add `status: "researching" | "ordered" | "arrived"` and `onStatusChange: (status: "researching" | "ordered" | "arrived") => void` to `CandidateCardProps`.
+       - Import `StatusBadge` from `./StatusBadge`.
+       - Add `<StatusBadge status={status} onStatusChange={onStatusChange} />` to the pill row (the `flex flex-wrap gap-1.5 mb-3` div), after the category pill.
+
+    3. **Update thread detail page caller** -- Find where `CandidateCard` is rendered (in the thread detail route). Add the `status` and `onStatusChange` props. For `onStatusChange`, use the existing `useUpdateCandidate` hook: `updateCandidate.mutate({ candidateId: candidate.id, status: newStatus })`.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint && bun test</automated>
+  </verify>
+  <done>Each candidate card shows a gray status badge (icon + label) in the pill row. Clicking the badge opens a popup menu with all three status options. Selecting a status updates it via the API and the badge reflects the new status. New candidates show "Researching" by default.</done>
+</task>
+
+</tasks>
+
+<verification>
+1. `bun test` -- all existing and new tests pass
+2. `bun run lint` -- no lint errors
+3. Start dev server (`bun run dev:server` + `bun run dev:client`), navigate to a thread detail page, verify:
+   - Each candidate shows a gray "Researching" badge in the pill row
+   - Clicking the badge opens a popup menu with Researching, Ordered, Arrived options
+   - Selecting a different status updates the badge immediately
+   - Refreshing the page shows the persisted status
+</verification>
+
+<success_criteria>
+- Status column exists on thread_candidates table with default "researching"
+- All candidate CRUD operations handle the status field
+- StatusBadge component renders in CandidateCard pill row with muted gray styling
+- Clicking badge opens popup menu, selecting an option changes status via API
+- New candidates show "researching" status by default
+- All tests pass including 5 new status-specific tests
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/08-search-filter-and-candidate-status/08-01-SUMMARY.md`
+</output>

.planning/phases/08-search-filter-and-candidate-status/08-01-SUMMARY.md

@@ -0,0 +1,112 @@
+---
+phase: 08-search-filter-and-candidate-status
+plan: 01
+subsystem: database, api, ui
+tags: [drizzle, sqlite, zod, react, tailwind, status-tracking]
+
+requires:
+  - phase: 05-thread-candidates
+    provides: threadCandidates table and CRUD service
+provides:
+  - status column on thread_candidates (researching/ordered/arrived)
+  - candidateStatusSchema Zod enum for validation
+  - StatusBadge clickable component with popup menu
+  - Status field in candidate CRUD operations
+affects: [08-search-filter-and-candidate-status]
+
+tech-stack:
+  added: []
+  patterns: [click-outside-dismiss-popup, status-badge-pill-with-menu]
+
+key-files:
+  created:
+    - src/client/components/StatusBadge.tsx
+    - drizzle/0002_broken_roughhouse.sql
+  modified:
+    - src/db/schema.ts
+    - src/shared/schemas.ts
+    - src/server/services/thread.service.ts
+    - src/client/hooks/useThreads.ts
+    - src/client/hooks/useCandidates.ts
+    - src/client/components/CandidateCard.tsx
+    - src/client/routes/threads/$threadId.tsx
+    - tests/helpers/db.ts
+    - tests/services/thread.service.test.ts
+
+key-decisions:
+  - "StatusBadge popup uses click-outside + Escape dismiss pattern matching CategoryPicker"
+  - "Status badge uses muted gray tones (bg-gray-100 text-gray-600) per user design decision"
+
+patterns-established:
+  - "StatusBadge popup: absolute positioned dropdown with click-outside dismiss via containerRef + useEffect mousedown listener"
+
+requirements-completed: [CAND-01, CAND-02, CAND-03]
+
+duration: 5min
+completed: 2026-03-16
+---
+
+# Phase 8 Plan 1: Candidate Status Tracking Summary
+
+**Candidate status tracking (researching/ordered/arrived) with schema migration, service/Zod updates, 5 TDD tests, and clickable StatusBadge popup on CandidateCard**
+
+## Performance
+
+- **Duration:** 5 min
+- **Started:** 2026-03-16T13:06:48Z
+- **Completed:** 2026-03-16T13:12:08Z
+- **Tasks:** 2
+- **Files modified:** 12
+
+## Accomplishments
+- Added `status` column to `thread_candidates` table with default "researching" and full Drizzle migration
+- Wired status through entire stack: schema, Zod validation, service CRUD, client type interfaces
+- Created StatusBadge component with clickable pill badge and popup menu (3 status options with icons)
+- Integrated StatusBadge into CandidateCard pill row with API mutation on status change
+- 5 new TDD tests covering all status CRUD operations (24 total thread service tests passing)
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Add status column and update backend + tests (TDD RED)** - `9342085` (test)
+2. **Task 1: Add status column and update backend + tests (TDD GREEN)** - `ca1c2a2` (feat)
+3. **Task 2: Create StatusBadge component and wire into CandidateCard** - `25956ed` (feat)
+
+_Note: Task 1 used TDD with separate RED and GREEN commits_
+
+## Files Created/Modified
+- `src/db/schema.ts` - Added status column to threadCandidates table
+- `src/shared/schemas.ts` - Added candidateStatusSchema Zod enum and status to createCandidateSchema
+- `src/server/services/thread.service.ts` - Status in getThreadWithCandidates select, createCandidate values, updateCandidate type
+- `src/client/hooks/useThreads.ts` - Added status to CandidateWithCategory interface
+- `src/client/hooks/useCandidates.ts` - Added status to CandidateResponse interface
+- `src/client/components/StatusBadge.tsx` - New clickable status badge with popup menu
+- `src/client/components/CandidateCard.tsx` - Added status and onStatusChange props, renders StatusBadge
+- `src/client/routes/threads/$threadId.tsx` - Passes status and useUpdateCandidate to CandidateCard
+- `tests/helpers/db.ts` - Added status column to test helper CREATE TABLE
+- `tests/services/thread.service.test.ts` - 5 new candidate status tests
+- `drizzle/0002_broken_roughhouse.sql` - Migration adding status column
+
+## Decisions Made
+- StatusBadge popup uses click-outside + Escape dismiss pattern matching CategoryPicker
+- Status badge uses muted gray tones (bg-gray-100 text-gray-600) per user design decision -- not semantic colors
+- Active status in popup menu highlighted with bg-gray-50 and checkmark icon
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+None
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- Candidate status tracking fully operational
+- Ready for Plan 02 (search/filter functionality)
+
+---
+*Phase: 08-search-filter-and-candidate-status*
+*Completed: 2026-03-16*

.planning/phases/08-search-filter-and-candidate-status/08-02-PLAN.md

@@ -0,0 +1,292 @@
+---
+phase: 08-search-filter-and-candidate-status
+plan: 02
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/client/components/CategoryFilterDropdown.tsx
+  - src/client/routes/collection/index.tsx
+autonomous: true
+requirements: [SRCH-01, SRCH-02, SRCH-03, SRCH-04, SRCH-05, PLAN-01]
+
+must_haves:
+  truths:
+    - "User can type in a search field on the gear tab and see items filtered instantly by name as they type"
+    - "User can select a category from a searchable dropdown (with Lucide icons) to filter items on both gear and planning tabs"
+    - "User can combine text search with category filter to narrow results"
+    - "User sees 'Showing X of Y items' when filters are active on the gear tab"
+    - "User clears search text and resets category dropdown individually (no combined clear button)"
+    - "When filters are active, items display as a flat grid without category group headers"
+    - "Empty filter results show 'No items match your search' message"
+    - "Planning tab category filter shows Lucide icons alongside category names"
+  artifacts:
+    - path: "src/client/components/CategoryFilterDropdown.tsx"
+      provides: "Shared searchable category filter dropdown with Lucide icons"
+      exports: ["CategoryFilterDropdown"]
+      min_lines: 60
+    - path: "src/client/routes/collection/index.tsx"
+      provides: "Search/filter toolbar in CollectionView, CategoryFilterDropdown in PlanningView"
+      contains: "CategoryFilterDropdown"
+  key_links:
+    - from: "src/client/components/CategoryFilterDropdown.tsx"
+      to: "src/client/hooks/useCategories.ts"
+      via: "categories prop passed from parent (useCategories data)"
+      pattern: "categories"
+    - from: "src/client/routes/collection/index.tsx (CollectionView)"
+      to: "src/client/components/CategoryFilterDropdown.tsx"
+      via: "CategoryFilterDropdown in sticky toolbar"
+      pattern: "<CategoryFilterDropdown"
+    - from: "src/client/routes/collection/index.tsx (PlanningView)"
+      to: "src/client/components/CategoryFilterDropdown.tsx"
+      via: "CategoryFilterDropdown replacing native select"
+      pattern: "<CategoryFilterDropdown"
+    - from: "src/client/routes/collection/index.tsx (CollectionView)"
+      to: "useItems data"
+      via: "useMemo filter chain on searchText + categoryFilter"
+      pattern: "filteredItems"
+---
+
+<objective>
+Add search/filter toolbar to the gear tab and a shared icon-aware category filter dropdown to both gear and planning tabs. Users can search items by name, filter by category, see result counts, and clear filters individually.
+
+Purpose: Help users find items quickly as collections grow, and upgrade the planning tab's plain `<select>` to a searchable icon-aware dropdown.
+Output: Sticky search/filter toolbar on gear tab, shared CategoryFilterDropdown component on both tabs.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/08-search-filter-and-candidate-status/08-CONTEXT.md
+@.planning/phases/08-search-filter-and-candidate-status/08-RESEARCH.md
+
+@src/client/routes/collection/index.tsx
+@src/client/components/CategoryPicker.tsx
+@src/client/hooks/useCategories.ts
+@src/client/hooks/useItems.ts
+@src/client/lib/iconData.tsx
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/client/hooks/useItems.ts:
+```typescript
+// useItems() returns items with these fields:
+interface ItemWithCategory {
+  id: number; name: string; weightGrams: number | null;
+  priceCents: number | null; categoryId: number;
+  notes: string | null; productUrl: string | null;
+  imageFilename: string | null; createdAt: string; updatedAt: string;
+  categoryName: string; categoryIcon: string;
+}
+```
+
+From src/client/hooks/useCategories.ts:
+```typescript
+// useCategories() returns:
+interface CategoryItem {
+  id: number; name: string; icon: string; createdAt: string;
+}
+```
+
+From src/client/lib/iconData.tsx:
+```typescript
+export function LucideIcon({ name, size, className }: {
+  name: string; size?: number; className?: string;
+}): JSX.Element;
+```
+
+From src/client/routes/collection/index.tsx:
+```typescript
+// CollectionView currently:
+// - Uses useItems() for all items
+// - Groups items by categoryId into Map
+// - Renders CategoryHeader + grid per category group
+// - No search or filter state
+
+// PlanningView currently:
+// - Has categoryFilter useState<number | null>(null)
+// - Uses a native <select> for category filtering (lines 277-291)
+// - Filters threads by activeTab and categoryFilter
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Create CategoryFilterDropdown component</name>
+  <files>src/client/components/CategoryFilterDropdown.tsx</files>
+  <action>
+    Create `src/client/components/CategoryFilterDropdown.tsx` -- a searchable dropdown showing categories with Lucide icons. This is a FILTER dropdown, NOT the form-based `CategoryPicker` (which handles creation). Keep them separate per user decision.
+
+    **Props:**
+    ```typescript
+    interface CategoryFilterDropdownProps {
+      value: number | null;           // selected category ID, null = "All categories"
+      onChange: (value: number | null) => void;
+      categories: Array<{ id: number; name: string; icon: string }>;
+    }
+    ```
+
+    **Structure:**
+    - **Trigger button**: Shows "All categories" with a chevron-down icon when `value` is null. Shows the selected category's `LucideIcon` (size 14) + name when a category is selected. Style: `px-3 py-2 border border-gray-200 rounded-lg text-sm bg-white` (matching search input height). Include a small clear "x" button on the right when a category is selected (clicking it calls `onChange(null)` without opening the dropdown).
+    - **Dropdown panel**: Opens below the trigger, `position: absolute`, `z-20`, white bg, border, rounded-lg, shadow-lg, max-height with overflow-y-auto. Width matches trigger or has a reasonable min-width (~220px).
+    - **Search input inside dropdown**: Text input at top of dropdown, placeholder "Search categories...", filters the category list as user types. Auto-focused when dropdown opens.
+    - **Option list**: "All categories" as first option (selecting calls `onChange(null)` and closes). Then each category: `LucideIcon` (size 16) + category name. Highlight the currently selected option with a subtle bg color. Hover state on each option.
+    - **Click-outside dismiss**: Use `containerRef` + `useEffect` mousedown listener pattern (same as `CategoryPicker`). Also close on Escape keydown.
+    - **State reset**: Clear internal search text when dropdown closes.
+
+    **Do NOT:**
+    - Reuse or modify `CategoryPicker.tsx`
+    - Add category creation capability
+    - Use Zustand for dropdown open/closed state (use local `useState`)
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint</automated>
+  </verify>
+  <done>CategoryFilterDropdown.tsx exists with searchable dropdown, Lucide icons per option, "All categories" first option, click-outside dismiss, clear button on trigger, and Escape to close. Lint passes.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Add search/filter toolbar to CollectionView and replace select in PlanningView</name>
+  <files>src/client/routes/collection/index.tsx</files>
+  <action>
+    Modify `src/client/routes/collection/index.tsx` to add search and filtering to `CollectionView` and upgrade `PlanningView`'s category filter.
+
+    **CollectionView changes:**
+
+    1. Add filter state at the top of `CollectionView`:
+       ```typescript
+       const [searchText, setSearchText] = useState("");
+       const [categoryFilter, setCategoryFilter] = useState<number | null>(null);
+       ```
+
+    2. Add `useCategories` hook: `const { data: categories } = useCategories();`
+
+    3. Add filtered items computation with `useMemo`:
+       ```typescript
+       const filteredItems = useMemo(() => {
+         if (!items) return [];
+         return items.filter((item) => {
+           const matchesSearch = searchText === "" ||
+             item.name.toLowerCase().includes(searchText.toLowerCase());
+           const matchesCategory = categoryFilter === null ||
+             item.categoryId === categoryFilter;
+           return matchesSearch && matchesCategory;
+         });
+       }, [items, searchText, categoryFilter]);
+       ```
+       Import `useMemo` from React, import `useCategories` from hooks.
+
+    4. Compute filter state:
+       ```typescript
+       const hasActiveFilters = searchText !== "" || categoryFilter !== null;
+       ```
+
+    5. Add sticky toolbar ABOVE the existing item grid rendering (after loading/empty checks, before the grouped items). The toolbar only shows when there are items:
+       ```jsx
+       <div className="sticky top-0 z-10 bg-white/95 backdrop-blur-sm border-b border-gray-100 -mx-4 px-4 py-3 sm:-mx-6 sm:px-6 lg:-mx-8 lg:px-8 mb-6">
+         <div className="flex gap-3 items-center">
+           <div className="relative flex-1">
+             <input
+               type="text"
+               placeholder="Search items..."
+               value={searchText}
+               onChange={(e) => setSearchText(e.target.value)}
+               className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
+             />
+             {searchText && (
+               <button onClick={() => setSearchText("")} className="absolute right-2 top-1/2 -translate-y-1/2 text-gray-400 hover:text-gray-600">
+                 {/* small x icon */}
+               </button>
+             )}
+           </div>
+           <CategoryFilterDropdown
+             value={categoryFilter}
+             onChange={setCategoryFilter}
+             categories={categories ?? []}
+           />
+         </div>
+         {hasActiveFilters && (
+           <p className="text-xs text-gray-500 mt-2">
+             Showing {filteredItems.length} of {items?.length ?? 0} items
+           </p>
+         )}
+       </div>
+       ```
+
+    6. Conditional rendering based on filter state:
+       - **When `hasActiveFilters` is true**: Render `filteredItems` as a flat grid (no category grouping, no `CategoryHeader`). If `filteredItems.length === 0`, show "No items match your search" centered text message.
+       - **When `hasActiveFilters` is false**: Keep existing category-grouped rendering exactly as-is (the `groupedItems` Map pattern), but use `filteredItems` as the source (which equals all items when no filters).
+
+    **PlanningView changes:**
+
+    1. Import `CategoryFilterDropdown` from `../../components/CategoryFilterDropdown`.
+    2. Replace the native `<select>` element (lines ~277-291) with:
+       ```jsx
+       <CategoryFilterDropdown
+         value={categoryFilter}
+         onChange={setCategoryFilter}
+         categories={categories ?? []}
+       />
+       ```
+    3. Remove the `useCategories` hook call if it's already called earlier, or keep it -- just make sure categories data is available.
+
+    **Important per user decisions:**
+    - Search matches item names ONLY (not category names) -- the dropdown handles category filtering
+    - No debounce on search input (per CONTEXT.md, <1000 items)
+    - No combined "clear all" button -- user clears search and dropdown individually
+    - Filters naturally reset on tab switch because `CollectionView` unmounts when tab changes (conditional rendering in `CollectionPage`). Verify this is the case -- if `CollectionView` stays mounted, add a `key={tab}` prop to force remount.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint && bun test</automated>
+  </verify>
+  <done>Gear tab has a sticky search/filter toolbar with text input and CategoryFilterDropdown side by side. Typing filters items by name instantly. Selecting a category filters by category. Both filters combine. "Showing X of Y items" appears when filters are active. Empty results show message. Flat grid renders when filters active (no category headers). Planning tab uses CategoryFilterDropdown with Lucide icons instead of native select. All tests and lint pass.</done>
+</task>
+
+</tasks>
+
+<verification>
+1. `bun run lint` -- no lint errors
+2. `bun test` -- all tests pass
+3. Start dev server, navigate to gear tab:
+   - Sticky toolbar visible with search input + category dropdown
+   - Type in search: items filter by name instantly
+   - Select a category from dropdown (icons visible): items filter by category
+   - Both filters combine correctly
+   - "Showing X of Y items" text appears when filters active
+   - Empty results show "No items match your search"
+   - Filtered items show as flat grid (no category headers)
+   - Clear search text: category filter still applies
+   - Select "All categories": search filter still applies
+   - Switch to planning tab: filters reset
+   - Switch back to gear tab: filters reset (clean state)
+4. Navigate to planning tab:
+   - Category filter dropdown shows Lucide icons alongside names
+   - Searchable within the dropdown
+   - "All categories" as first option
+   - Selecting a category shows icon + name in trigger button
+</verification>
+
+<success_criteria>
+- Search input filters items by name on every keystroke (no debounce)
+- CategoryFilterDropdown shows icons, is searchable, has "All categories" option
+- Filters combine (text AND category)
+- Result count displayed when filters active
+- Flat grid (no category headers) when any filter active
+- "No items match your search" on empty results
+- Filters reset on tab switch
+- Planning tab uses shared CategoryFilterDropdown instead of native select
+- Lint and tests pass
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/08-search-filter-and-candidate-status/08-02-SUMMARY.md`
+</output>

.planning/phases/08-search-filter-and-candidate-status/08-02-SUMMARY.md

@@ -0,0 +1,101 @@
+---
+phase: 08-search-filter-and-candidate-status
+plan: 02
+subsystem: ui
+tags: [react, search, filter, dropdown, lucide-icons, useMemo]
+
+# Dependency graph
+requires:
+  - phase: 06-category-system-and-ui-redesign
+    provides: CategoryPicker pattern, LucideIcon component, useCategories hook
+provides:
+  - CategoryFilterDropdown reusable component with icon-aware searchable dropdown
+  - Search/filter toolbar on gear tab with text search and category filtering
+  - Upgraded planning tab category filter with Lucide icons
+affects: []
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns:
+    - "CategoryFilterDropdown: filter-only dropdown separate from form-based CategoryPicker"
+    - "useMemo filter chain for combining text search + category filter"
+    - "Conditional rendering: flat grid (no category headers) when filters active"
+
+key-files:
+  created:
+    - src/client/components/CategoryFilterDropdown.tsx
+  modified:
+    - src/client/routes/collection/index.tsx
+
+key-decisions:
+  - "Kept CategoryFilterDropdown separate from CategoryPicker (filter vs form concerns)"
+  - "No debounce on search input (collection under 1000 items)"
+  - "Individual clear controls (no combined clear-all button)"
+
+patterns-established:
+  - "CategoryFilterDropdown: reusable filter dropdown with icons, search, click-outside dismiss"
+  - "Flat grid rendering when filters active to avoid confusing partial category headers"
+
+requirements-completed: [SRCH-01, SRCH-02, SRCH-03, SRCH-04, SRCH-05, PLAN-01]
+
+# Metrics
+duration: 3min
+completed: 2026-03-16
+---
+
+# Phase 8 Plan 2: Search/Filter Toolbar and Category Dropdown Summary
+
+**Sticky search/filter toolbar on gear tab with text+category filtering, and shared icon-aware CategoryFilterDropdown on both gear and planning tabs**
+
+## Performance
+
+- **Duration:** 3 min
+- **Started:** 2026-03-16T13:06:49Z
+- **Completed:** 2026-03-16T13:10:03Z
+- **Tasks:** 2
+- **Files modified:** 2
+
+## Accomplishments
+- Created CategoryFilterDropdown component with searchable dropdown, Lucide icons per option, "All categories" default, click-outside/Escape dismiss, and clear button
+- Added sticky search/filter toolbar to CollectionView with text search input and CategoryFilterDropdown side by side
+- useMemo filter chain combines text search (by name) with category filter for instant results
+- "Showing X of Y items" count appears when filters active; flat grid (no category headers) when filtering
+- Replaced PlanningView native `<select>` with shared CategoryFilterDropdown showing Lucide icons
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Create CategoryFilterDropdown component** - `9e1a875` (feat)
+2. **Task 2: Add search/filter toolbar to CollectionView and replace select in PlanningView** - `5f89acd` (feat)
+
+## Files Created/Modified
+- `src/client/components/CategoryFilterDropdown.tsx` - Searchable category filter dropdown with Lucide icons, click-outside dismiss, Escape key, clear button
+- `src/client/routes/collection/index.tsx` - Search/filter toolbar in CollectionView, CategoryFilterDropdown replacing native select in PlanningView
+
+## Decisions Made
+- Kept CategoryFilterDropdown separate from CategoryPicker (filter concerns vs form/creation concerns, per user decision)
+- No debounce on search -- collection stays under 1000 items per CONTEXT.md
+- Individual clear controls for search text and category dropdown (no combined clear-all button)
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+None
+
+## User Setup Required
+
+None - no external service configuration required.
+
+## Next Phase Readiness
+- Search and filter infrastructure complete for gear tab
+- CategoryFilterDropdown available as shared component for any future filter needs
+- Planning tab upgraded from native select to icon-aware dropdown
+- Ready for remaining Phase 8 work or next phase
+
+---
+*Phase: 08-search-filter-and-candidate-status*
+*Completed: 2026-03-16*

.planning/phases/08-search-filter-and-candidate-status/08-CONTEXT.md

@@ -0,0 +1,98 @@
+# Phase 8: Search, Filter, and Candidate Status - Context
+
+**Gathered:** 2026-03-16
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Users can find collection items quickly via text search and category filter, track candidate purchase progress with status badges, and use an icon-aware category dropdown on both gear and planning tabs. Side-by-side comparison, ranking, and impact preview are separate phases.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Search & filter bar
+- Sticky toolbar above the item grid on the gear tab, stays visible on scroll
+- Search input + category dropdown side by side in the toolbar
+- Client-side filtering on every keystroke (no debounce needed for <1000 items)
+- Search matches item names only (not category names) — category filtering is the dropdown's job
+- When any filter is active, items display as a flat grid (no category group headers)
+- Filters reset when switching between gear/planning/setups tabs
+
+### Candidate status
+- Three statuses: researching (default), ordered, arrived
+- Status badge appears in the existing pill row alongside weight/price/category pills
+- Badge shows icon + text label (e.g., magnifying glass + "researching", truck + "ordered", check + "arrived")
+- Muted/neutral color scheme for status badges — gray tones, not semantic colors. Color reserved for weight/price pills
+- Click the status badge to open a small popup menu showing all three status options (allows jumping to any status, including backward)
+- New candidates default to "researching" status
+- Requires `status` column on `thread_candidates` table (schema migration)
+
+### Filter feedback
+- "Showing X of Y items" count displayed when filters are active — placement at Claude's discretion
+- No combined "clear all" button — user clears search text and resets category dropdown individually
+- "No items match your search" simple text message for empty filter results (no suggestions)
+
+### Icon-aware category dropdown
+- Shared `CategoryFilterDropdown` component used on both gear tab and planning tab
+- Separate from the existing `CategoryPicker` component (which is a form combobox for category selection/creation)
+- "All categories" as the first option — selecting it clears the category filter
+- Searchable dropdown — includes a search input inside the dropdown for filtering categories
+- Trigger button shows the selected category's Lucide icon + name when a category is selected
+
+### Claude's Discretion
+- Exact toolbar styling (padding, borders, background)
+- Filter result count placement (in toolbar or above grid)
+- Status popup menu implementation details
+- Specific gray tone values for status badges
+- Keyboard accessibility patterns for the dropdown and status menu
+- Icon choices for status badges (magnifying glass, truck, check are suggestions)
+
+</decisions>
+
+<code_context>
+## Existing Code Insights
+
+### Reusable Assets
+- `CategoryPicker` (`src/client/components/CategoryPicker.tsx`): Combobox with icon display, search, keyboard nav, and category creation. Pattern reference for the new filter dropdown, but not reusable directly since it's a form input, not a filter
+- `LucideIcon` (`src/client/lib/iconData.ts`): Dynamic icon renderer used throughout the app — reuse for dropdown icons and status badges
+- `useCategories` hook: Already fetches all categories with icons — drives the dropdown options
+- `useItems` hook: Returns all items — client-side filtering can operate on this data
+- `CollectionTabs` / `ThreadTabs`: Tab component with pill styling — existing navigation pattern
+- `CandidateCard`: Currently has weight/price/category pill row — status badge slots in here
+
+### Established Patterns
+- Client-side state for filter/tab state (`useState` in route components, not Zustand)
+- URL params for tab navigation (`?tab=gear`)
+- React Query for server data, Zustand for UI state (panels/dialogs only)
+- Pill badges: blue-50/blue-400 for weight, green-50/green-500 for price, gray-50/gray-600 for category
+
+### Integration Points
+- `CollectionView` function in `src/client/routes/collection/index.tsx`: Search/filter toolbar goes here, above the category-grouped items
+- `PlanningView` function: Replace existing `<select>` category filter with shared `CategoryFilterDropdown`
+- `CandidateCard`: Add status prop and badge to the pill row
+- `thread_candidates` table in `src/db/schema.ts`: Add `status` column with default "researching"
+- Candidate API routes + services: Need to handle status field in CRUD operations
+
+</code_context>
+
+<specifics>
+## Specific Ideas
+
+No specific requirements — open to standard approaches
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 08-search-filter-and-candidate-status*
+*Context gathered: 2026-03-16*

.planning/phases/08-search-filter-and-candidate-status/08-RESEARCH.md

@@ -0,0 +1,491 @@
+# Phase 8: Search, Filter, and Candidate Status - Research
+
+**Researched:** 2026-03-16
+**Domain:** Client-side filtering, searchable dropdown components, schema migration, status badges
+**Confidence:** HIGH
+
+## Summary
+
+Phase 8 adds three capabilities to GearBox: (1) a search and category filter toolbar on the gear tab with result counts, (2) an icon-aware searchable category filter dropdown shared between gear and planning tabs, and (3) candidate status tracking (researching/ordered/arrived) with clickable status badges. The work spans all layers: schema migration (adding `status` column to `thread_candidates`), service/route updates (CRUD for status field), Zod schema updates, and several new client components.
+
+The codebase is well-structured for these additions. Client-side filtering is straightforward since `useItems()` already returns all items with category info. The `CategoryPicker` component provides a reference pattern for the searchable dropdown, though the new `CategoryFilterDropdown` is simpler (no creation flow). The candidate status feature requires a schema migration, but Drizzle Kit and the existing migration infrastructure handle this cleanly.
+
+**Primary recommendation:** Build in two waves -- (1) backend schema migration + candidate status (smaller, foundational), then (2) search/filter toolbar and shared category dropdown (larger, UI-focused). Both waves are pure client-side filtering with minimal server changes.
+
+<user_constraints>
+## User Constraints (from CONTEXT.md)
+
+### Locked Decisions
+- Sticky toolbar above the item grid on the gear tab, stays visible on scroll
+- Search input + category dropdown side by side in the toolbar
+- Client-side filtering on every keystroke (no debounce needed for <1000 items)
+- Search matches item names only (not category names) -- category filtering is the dropdown's job
+- When any filter is active, items display as a flat grid (no category group headers)
+- Filters reset when switching between gear/planning/setups tabs
+- Three statuses: researching (default), ordered, arrived
+- Status badge appears in the existing pill row alongside weight/price/category pills
+- Badge shows icon + text label (e.g., magnifying glass + "researching", truck + "ordered", check + "arrived")
+- Muted/neutral color scheme for status badges -- gray tones, not semantic colors
+- Click the status badge to open a small popup menu showing all three status options
+- New candidates default to "researching" status
+- Requires `status` column on `thread_candidates` table (schema migration)
+- "Showing X of Y items" count displayed when filters are active
+- No combined "clear all" button -- user clears search text and resets category dropdown individually
+- "No items match your search" simple text message for empty filter results
+- Shared `CategoryFilterDropdown` component used on both gear tab and planning tab
+- Separate from existing `CategoryPicker` component
+- "All categories" as the first option -- selecting it clears the category filter
+- Searchable dropdown with search input inside
+- Trigger button shows selected category's Lucide icon + name when selected
+
+### Claude's Discretion
+- Exact toolbar styling (padding, borders, background)
+- Filter result count placement (in toolbar or above grid)
+- Status popup menu implementation details
+- Specific gray tone values for status badges
+- Keyboard accessibility patterns for the dropdown and status menu
+- Icon choices for status badges (magnifying glass, truck, check are suggestions)
+
+### Deferred Ideas (OUT OF SCOPE)
+None
+</user_constraints>
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| SRCH-01 | User can search items by name with instant filtering as they type | Client-side `useState` + `.filter()` on `useItems()` data. Pattern documented in Architecture section |
+| SRCH-02 | User can filter collection items by category via dropdown | New `CategoryFilterDropdown` component using `useCategories()` data. Pattern from existing `CategoryPicker` |
+| SRCH-03 | User can combine text search with category filter simultaneously | Chain `.filter()` calls -- search text AND category ID. Both stored as `useState` in `CollectionView` |
+| SRCH-04 | User can see result count when filters are active | Computed from `filteredItems.length` vs `items.length`. Conditional rendering when filters active |
+| SRCH-05 | User can clear all active filters with one action | Per CONTEXT.md: no combined button. User clears search text and resets dropdown individually. Both inputs have clear affordances |
+| PLAN-01 | Planning category filter dropdown shows Lucide icons alongside names | Replace existing `<select>` in `PlanningView` with shared `CategoryFilterDropdown` |
+| CAND-01 | Each candidate displays a status badge (researching, ordered, or arrived) | Add `status` prop to `CandidateCard`, render as pill in existing flex row |
+| CAND-02 | User can change a candidate's status via click interaction | Status badge click opens popup menu. Uses `useUpdateCandidate` mutation with `status` field |
+| CAND-03 | New candidates default to "researching" status | Schema default + Drizzle `.default("researching")`. Service layer already handles defaults via `?? null` pattern |
+</phase_requirements>
+
+## Standard Stack
+
+### Core (Already in Project)
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| React | 19 | UI framework | Already installed, all components use it |
+| TanStack React Query | - | Server state | Already used for `useItems`, `useCategories`, `useThreads` |
+| Zustand | - | UI state (panels/dialogs only) | Already used in `uiStore.ts` |
+| Drizzle ORM | - | Database schema + queries | Already used for all DB operations |
+| Drizzle Kit | - | Schema migration generation | Already configured in `drizzle.config.ts` |
+| Zod | - | Request validation | Already used in `schemas.ts` and route validators |
+| Hono | - | Server framework | Already used for all API routes |
+| lucide-react | - | Icons | Already used via `LucideIcon` component for all icons |
+| Tailwind CSS | v4 | Styling | Already used throughout |
+
+### No New Dependencies Required
+
+This phase uses only existing libraries. No new packages needed.
+
+## Architecture Patterns
+
+### Recommended Project Structure (Changes Only)
+```
+src/
+  client/
+    components/
+      CategoryFilterDropdown.tsx    # NEW - shared searchable category filter
+      StatusBadge.tsx               # NEW - clickable status badge with popup menu
+      CandidateCard.tsx             # MODIFIED - add status prop and badge
+    routes/
+      collection/
+        index.tsx                   # MODIFIED - add search/filter toolbar to CollectionView
+                                    #           - replace <select> in PlanningView
+  server/
+    services/
+      thread.service.ts             # MODIFIED - handle status field in create/update candidate
+    routes/
+      threads.ts                    # NO CHANGES - already delegates to service
+  shared/
+    schemas.ts                      # MODIFIED - add status to candidate schemas
+    types.ts                        # NO CHANGES - types auto-infer from schemas
+  db/
+    schema.ts                       # MODIFIED - add status column to threadCandidates
+tests/
+  helpers/
+    db.ts                           # MODIFIED - add status column to thread_candidates CREATE TABLE
+  services/
+    thread.service.test.ts          # MODIFIED - add tests for status field
+```
+
+### Pattern 1: Client-Side Filtering with useState
+**What:** Filter items in-memory using React state, no server round-trips
+**When to use:** Small datasets (<1000 items), instant feedback needed
+**Example:**
+```typescript
+// In CollectionView
+function CollectionView() {
+  const [searchText, setSearchText] = useState("");
+  const [categoryFilter, setCategoryFilter] = useState<number | null>(null);
+  const { data: items } = useItems();
+
+  const filteredItems = useMemo(() => {
+    if (!items) return [];
+    return items.filter((item) => {
+      const matchesSearch = searchText === "" ||
+        item.name.toLowerCase().includes(searchText.toLowerCase());
+      const matchesCategory = categoryFilter === null ||
+        item.categoryId === categoryFilter;
+      return matchesSearch && matchesCategory;
+    });
+  }, [items, searchText, categoryFilter]);
+
+  const hasActiveFilters = searchText !== "" || categoryFilter !== null;
+  // ...
+}
+```
+
+### Pattern 2: Searchable Dropdown with Click-Outside Dismiss
+**What:** Dropdown with internal search input, opens on click, closes on click-outside or Escape
+**When to use:** Category filter dropdowns where a native `<select>` is insufficient (need icons, search)
+**Example:**
+```typescript
+// Reference: existing CategoryPicker pattern (containerRef + useEffect for mousedown)
+function CategoryFilterDropdown({ value, onChange, categories }) {
+  const [isOpen, setIsOpen] = useState(false);
+  const [search, setSearch] = useState("");
+  const containerRef = useRef<HTMLDivElement>(null);
+
+  useEffect(() => {
+    function handleClickOutside(e: MouseEvent) {
+      if (containerRef.current && !containerRef.current.contains(e.target as Node)) {
+        setIsOpen(false);
+        setSearch("");
+      }
+    }
+    document.addEventListener("mousedown", handleClickOutside);
+    return () => document.removeEventListener("mousedown", handleClickOutside);
+  }, []);
+  // ... trigger button + dropdown list with LucideIcon per option
+}
+```
+
+### Pattern 3: Status Badge with Popup Menu
+**What:** Clickable pill badge that opens a small menu to change status
+**When to use:** Inline status changes without opening a modal/panel
+**Example:**
+```typescript
+// StatusBadge - renders in CandidateCard's pill row
+function StatusBadge({ status, onStatusChange }: {
+  status: "researching" | "ordered" | "arrived";
+  onStatusChange: (status: string) => void;
+}) {
+  const [menuOpen, setMenuOpen] = useState(false);
+  const containerRef = useRef<HTMLDivElement>(null);
+  // Click-outside dismiss pattern (same as CategoryPicker)
+  // Renders: pill button + absolute-positioned menu with 3 options
+}
+```
+
+### Pattern 4: Schema Migration with Default Value
+**What:** Add column with default to existing table using Drizzle Kit
+**When to use:** Adding new fields that need backward compatibility with existing rows
+**Example:**
+```typescript
+// In src/db/schema.ts -- add to threadCandidates table definition:
+status: text("status").notNull().default("researching"),
+
+// Then run: bun run db:generate && bun run db:push
+// Drizzle Kit will generate: ALTER TABLE thread_candidates ADD COLUMN status TEXT NOT NULL DEFAULT 'researching'
+```
+
+### Pattern 5: Flat Grid vs Category-Grouped Grid
+**What:** Conditionally render items as flat grid or category-grouped sections
+**When to use:** When filters are active, category grouping loses meaning
+**Example:**
+```typescript
+// When filters active: flat grid of filteredItems
+// When no filters: existing category-grouped Map pattern (already in CollectionView)
+const hasActiveFilters = searchText !== "" || categoryFilter !== null;
+
+return hasActiveFilters ? (
+  <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">
+    {filteredItems.map((item) => <ItemCard key={item.id} ... />)}
+  </div>
+) : (
+  // Existing grouped rendering with CategoryHeader
+  <>
+    {Array.from(groupedItems.entries()).map(([categoryId, { items, ... }]) => (
+      // ... existing CategoryHeader + grid pattern
+    ))}
+  </>
+);
+```
+
+### Anti-Patterns to Avoid
+- **Server-side filtering for this use case:** Out of scope per REQUIREMENTS.md ("Premature for single-user app with <1000 items"). All filtering is client-side.
+- **Zustand for filter state:** Per codebase convention, filter/tab state uses `useState` in route components, not Zustand. Zustand is only for panel/dialog state.
+- **Debouncing search input:** Per CONTEXT.md, no debounce needed for <1000 items. React is fast enough for synchronous filtering.
+- **Modifying CategoryPicker:** The new dropdown is separate from `CategoryPicker`. CategoryPicker is a form combobox for category selection/creation. Do not conflate them.
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Click-outside detection | Custom event system | `useEffect` + `mousedown` listener on `document` (existing pattern from `CategoryPicker`) | Pattern already proven in codebase, handles edge cases |
+| Dynamic icon rendering | SVG string lookup | `LucideIcon` component from `src/client/lib/iconData.tsx` | Already handles kebab-case to PascalCase conversion, fallback to Package icon |
+| Schema migrations | Manual SQL | `bun run db:generate` + `bun run db:push` (Drizzle Kit) | Generates correct ALTER TABLE, manages migration journal |
+| Popup menu positioning | Complex position calculation | CSS `position: absolute` + `right-0` on container with `position: relative` | Simple case -- badge is in a flex row, menu drops below. No viewport collision for this layout |
+
+## Common Pitfalls
+
+### Pitfall 1: Forgetting to Update Test Helper DB Schema
+**What goes wrong:** Adding `status` column to `src/db/schema.ts` but not to `tests/helpers/db.ts` CREATE TABLE statement causes all thread service tests to fail.
+**Why it happens:** The test helper creates in-memory SQLite tables manually, not via Drizzle migrations.
+**How to avoid:** Always update both `src/db/schema.ts` AND `tests/helpers/db.ts` thread_candidates CREATE TABLE in the same commit.
+**Warning signs:** Tests that worked before now fail with "table thread_candidates has no column named status".
+
+### Pitfall 2: Filter State Not Resetting on Tab Switch
+**What goes wrong:** User searches on gear tab, switches to planning, comes back -- old search text still showing stale filtered results.
+**Why it happens:** useState persists while the component is mounted. Tab switching in `CollectionPage` conditionally renders views but `CollectionView` may stay mounted if React reuses the component.
+**How to avoid:** Use a `key` prop tied to the tab value on the view components, or explicitly reset filter state in a `useEffect` keyed on tab changes. The simplest approach: since `CollectionView` is conditionally rendered (unmounted when tab !== "gear"), useState will naturally reset. Verify this is the case.
+**Warning signs:** Filters persisting when switching tabs.
+
+### Pitfall 3: Status Badge Click Propagating to Card Actions
+**What goes wrong:** Clicking the status badge also triggers the card's edit panel or other click handlers.
+**Why it happens:** Event bubbling -- `CandidateCard` has click handlers on parent elements.
+**How to avoid:** Call `e.stopPropagation()` on the status badge click handler. The existing code already does this for the external link button.
+**Warning signs:** Clicking status badge opens the edit panel instead of the status menu.
+
+### Pitfall 4: Candidate Status Not Included in API Responses
+**What goes wrong:** Status column is added to schema but `getThreadWithCandidates` doesn't select it, so frontend never receives it.
+**Why it happens:** The service uses explicit `select()` clauses, not `select(*)`. New columns must be explicitly added.
+**How to avoid:** Add `status: threadCandidates.status` to the select object in `getThreadWithCandidates`.
+**Warning signs:** Status badge always shows "researching" even after changing it.
+
+### Pitfall 5: Zod Schema Missing Status in updateCandidateSchema
+**What goes wrong:** PUT request to update candidate status gets rejected by Zod validation.
+**Why it happens:** `updateCandidateSchema = createCandidateSchema.partial()` -- if `createCandidateSchema` doesn't include status, neither does update.
+**How to avoid:** Add `status` to `updateCandidateSchema` (and optionally `createCandidateSchema`). Use `z.enum(["researching", "ordered", "arrived"])`.
+**Warning signs:** 400 errors when trying to change status via the badge.
+
+### Pitfall 6: Sticky Toolbar Covering Content
+**What goes wrong:** The sticky search/filter toolbar overlaps the first row of items when scrolled.
+**Why it happens:** `position: sticky` without adequate spacing pushes content under the toolbar.
+**How to avoid:** Ensure the grid content below the toolbar has no negative margin or overlapping. The toolbar sits in normal flow and sticks on scroll -- padding/margin on the toolbar itself handles spacing.
+**Warning signs:** First item card partially hidden behind the toolbar when scrolling.
+
+## Code Examples
+
+### Schema Migration: Add Status Column
+```typescript
+// src/db/schema.ts -- threadCandidates table
+export const threadCandidates = sqliteTable("thread_candidates", {
+  // ... existing columns ...
+  status: text("status").notNull().default("researching"),
+});
+```
+
+### Zod Schema Update
+```typescript
+// src/shared/schemas.ts
+export const candidateStatusSchema = z.enum(["researching", "ordered", "arrived"]);
+
+export const createCandidateSchema = z.object({
+  name: z.string().min(1, "Name is required"),
+  weightGrams: z.number().nonnegative().optional(),
+  priceCents: z.number().int().nonnegative().optional(),
+  categoryId: z.number().int().positive(),
+  notes: z.string().optional(),
+  productUrl: z.string().url().optional().or(z.literal("")),
+  imageFilename: z.string().optional(),
+  status: candidateStatusSchema.optional(), // optional on create, defaults to "researching"
+});
+
+export const updateCandidateSchema = createCandidateSchema.partial();
+// This automatically includes status as optional
+```
+
+### Service Update: Status in getThreadWithCandidates
+```typescript
+// src/server/services/thread.service.ts -- in getThreadWithCandidates
+const candidateList = db
+  .select({
+    id: threadCandidates.id,
+    threadId: threadCandidates.threadId,
+    name: threadCandidates.name,
+    weightGrams: threadCandidates.weightGrams,
+    priceCents: threadCandidates.priceCents,
+    categoryId: threadCandidates.categoryId,
+    notes: threadCandidates.notes,
+    productUrl: threadCandidates.productUrl,
+    imageFilename: threadCandidates.imageFilename,
+    status: threadCandidates.status,  // ADD THIS
+    createdAt: threadCandidates.createdAt,
+    updatedAt: threadCandidates.updatedAt,
+    categoryName: categories.name,
+    categoryIcon: categories.icon,
+  })
+  .from(threadCandidates)
+  .innerJoin(categories, eq(threadCandidates.categoryId, categories.id))
+  .where(eq(threadCandidates.threadId, threadId))
+  .all();
+```
+
+### Test Helper Update
+```sql
+-- tests/helpers/db.ts -- thread_candidates CREATE TABLE
+CREATE TABLE thread_candidates (
+  id INTEGER PRIMARY KEY AUTOINCREMENT,
+  thread_id INTEGER NOT NULL REFERENCES threads(id) ON DELETE CASCADE,
+  name TEXT NOT NULL,
+  weight_grams REAL,
+  price_cents INTEGER,
+  category_id INTEGER NOT NULL REFERENCES categories(id),
+  notes TEXT,
+  product_url TEXT,
+  image_filename TEXT,
+  status TEXT NOT NULL DEFAULT 'researching',
+  created_at INTEGER NOT NULL DEFAULT (unixepoch()),
+  updated_at INTEGER NOT NULL DEFAULT (unixepoch())
+)
+```
+
+### Client Hook Update: CandidateWithCategory Type
+```typescript
+// src/client/hooks/useThreads.ts -- add status to CandidateWithCategory
+interface CandidateWithCategory {
+  id: number;
+  threadId: number;
+  name: string;
+  weightGrams: number | null;
+  priceCents: number | null;
+  categoryId: number;
+  notes: string | null;
+  productUrl: string | null;
+  imageFilename: string | null;
+  status: "researching" | "ordered" | "arrived";  // ADD THIS
+  createdAt: string;
+  updatedAt: string;
+  categoryName: string;
+  categoryIcon: string;
+}
+```
+
+### Lucide Icon Names for Status Badges
+```typescript
+// Available in lucide-react (verified via iconData.tsx icon groups)
+const STATUS_CONFIG = {
+  researching: { icon: "search", label: "Researching" },
+  ordered: { icon: "truck", label: "Ordered" },
+  arrived: { icon: "check", label: "Arrived" },
+} as const;
+// Note: "search" maps to lucide's Search icon (magnifying glass)
+// "truck" maps to Truck icon
+// "check" maps to Check icon
+// All are valid lucide-react icon names and work with the LucideIcon component
+```
+
+### Sticky Toolbar Pattern
+```typescript
+// Toolbar sticks to top on scroll
+<div className="sticky top-0 z-10 bg-white/95 backdrop-blur-sm border-b border-gray-100 -mx-4 px-4 py-3 sm:-mx-6 sm:px-6 lg:-mx-8 lg:px-8">
+  <div className="flex gap-3 items-center">
+    <input
+      type="text"
+      placeholder="Search items..."
+      value={searchText}
+      onChange={(e) => setSearchText(e.target.value)}
+      className="flex-1 px-3 py-2 border border-gray-200 rounded-lg text-sm ..."
+    />
+    <CategoryFilterDropdown
+      value={categoryFilter}
+      onChange={setCategoryFilter}
+    />
+  </div>
+</div>
+```
+
+## State of the Art
+
+| Old Approach | Current Approach | When Changed | Impact |
+|--------------|------------------|--------------|--------|
+| Native `<select>` for category filter | Searchable dropdown with icons | This phase | Planning view's `<select>` replaced with `CategoryFilterDropdown` |
+| No candidate status tracking | `status` column with badge UI | This phase | Candidates now track purchase progress |
+| Category-grouped items only | Conditional flat grid when filtering | This phase | Better UX when searching/filtering |
+
+## Open Questions
+
+1. **Sticky toolbar `top` offset**
+   - What we know: The toolbar should be `sticky top-0` but needs to account for any fixed header/navbar if one exists.
+   - What's unclear: Whether there's a fixed navbar above the collection page that would require a `top-[Npx]` offset instead of `top-0`.
+   - Recommendation: Start with `top-0`. If there's a fixed navbar, adjust the top value to match its height. The current layout appears to not have a fixed navbar based on the route structure.
+
+2. **useCandidates hook status mutation**
+   - What we know: `useUpdateCandidate` already exists and can be used for status changes via `apiPut`.
+   - What's unclear: Whether a dedicated `useUpdateCandidateStatus` hook is cleaner than reusing the general `useUpdateCandidate`.
+   - Recommendation: Reuse `useUpdateCandidate` -- it already accepts partial updates. Adding a dedicated hook would be unnecessary abstraction.
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test runner (built-in) |
+| Config file | None (uses bun defaults) |
+| Quick run command | `bun test tests/services/thread.service.test.ts` |
+| Full suite command | `bun test` |
+
+### Phase Requirements to Test Map
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| SRCH-01 | Search items by name with instant filtering | manual-only | N/A -- client-side `useState` + `filter()`, no testable service | N/A |
+| SRCH-02 | Filter by category via dropdown | manual-only | N/A -- client-side component logic | N/A |
+| SRCH-03 | Combine text search with category filter | manual-only | N/A -- client-side filtering logic | N/A |
+| SRCH-04 | Show result count when filters active | manual-only | N/A -- computed in render | N/A |
+| SRCH-05 | Clear filters individually | manual-only | N/A -- UI interaction | N/A |
+| PLAN-01 | Category dropdown shows icons | manual-only | N/A -- component rendering | N/A |
+| CAND-01 | Candidate displays status badge | unit | `bun test tests/services/thread.service.test.ts` | Needs update |
+| CAND-02 | User can change candidate status | unit | `bun test tests/services/thread.service.test.ts` | Needs update |
+| CAND-03 | New candidates default to "researching" | unit | `bun test tests/services/thread.service.test.ts` | Needs update |
+
+### Sampling Rate
+- **Per task commit:** `bun test tests/services/thread.service.test.ts`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+- [ ] `tests/helpers/db.ts` -- add `status TEXT NOT NULL DEFAULT 'researching'` to thread_candidates CREATE TABLE
+- [ ] `tests/services/thread.service.test.ts` -- add tests for: (1) createCandidate returns status "researching" by default, (2) updateCandidate can change status, (3) getThreadWithCandidates includes status field
+
+## Sources
+
+### Primary (HIGH confidence)
+- **Codebase analysis** -- direct reading of all relevant source files:
+  - `src/db/schema.ts` -- current threadCandidates table definition (no status column)
+  - `src/client/routes/collection/index.tsx` -- CollectionView (where toolbar goes) and PlanningView (where `<select>` is replaced)
+  - `src/client/components/CandidateCard.tsx` -- current pill row layout (where status badge goes)
+  - `src/client/components/CategoryPicker.tsx` -- searchable dropdown reference pattern
+  - `src/client/lib/iconData.tsx` -- LucideIcon component and available icon names
+  - `src/server/services/thread.service.ts` -- candidate CRUD with explicit select fields
+  - `src/shared/schemas.ts` -- Zod validation schemas for candidates
+  - `src/client/hooks/useThreads.ts` -- CandidateWithCategory interface
+  - `src/client/hooks/useCandidates.ts` -- mutation hooks for candidates
+  - `tests/helpers/db.ts` -- test helper CREATE TABLE statements
+  - `drizzle.config.ts` -- migration config
+  - `drizzle/0001_rename_emoji_to_icon.sql` -- migration precedent
+
+### Secondary (MEDIUM confidence)
+- **Drizzle ORM** -- ALTER TABLE ADD COLUMN with DEFAULT for SQLite is well-documented and standard
+
+### Tertiary (LOW confidence)
+- None -- all findings are from direct codebase analysis
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH -- no new libraries, all existing
+- Architecture: HIGH -- patterns derived from existing codebase conventions
+- Pitfalls: HIGH -- identified from actual code reading (explicit selects, test helper, event bubbling)
+- Schema migration: HIGH -- follows existing migration pattern (drizzle/0001_rename_emoji_to_icon.sql)
+
+**Research date:** 2026-03-16
+**Valid until:** 2026-04-16 (stable -- internal codebase patterns, no external dependency concerns)

.planning/phases/08-search-filter-and-candidate-status/08-VALIDATION.md

@@ -0,0 +1,82 @@
+---
+phase: 8
+slug: search-filter-and-candidate-status
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-16
+---
+
+# Phase 8 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | bun test |
+| **Config file** | bunfig.toml (if exists) or none |
+| **Quick run command** | `bun test` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 08-01-01 | 01 | 1 | CAND-01, CAND-03 | unit | `bun test tests/services/thread.service.test.ts` | ❌ W0 | ⬜ pending |
+| 08-01-02 | 01 | 1 | CAND-02 | unit | `bun test tests/services/thread.service.test.ts` | ❌ W0 | ⬜ pending |
+| 08-02-01 | 02 | 1 | SRCH-01, SRCH-02, SRCH-03 | manual | visual | N/A | ⬜ pending |
+| 08-02-02 | 02 | 1 | SRCH-04, SRCH-05 | manual | visual | N/A | ⬜ pending |
+| 08-02-03 | 02 | 1 | PLAN-01 | manual | visual | N/A | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] `tests/services/thread.service.test.ts` — add candidate status tests (schema migration, default status, status update)
+- [ ] `tests/helpers/db.ts` — update CREATE TABLE for thread_candidates to include status column
+
+*Existing test infrastructure covers framework setup.*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Instant search filtering as user types | SRCH-01 | Client-side UI interaction | Type in search field, verify items filter in real time |
+| Category dropdown with Lucide icons | SRCH-02, PLAN-01 | Visual rendering of icons in dropdown | Open dropdown, verify icons appear next to category names |
+| Combined search + category filter | SRCH-03 | Multi-input UI interaction | Apply both search and category filter, verify combined results |
+| Result count display | SRCH-04 | UI text rendering | Apply filter, verify "showing X of Y items" appears |
+| Clear filters individually | SRCH-05 | UI interaction | Clear search, reset dropdown, verify all items return |
+| Status badge display and click menu | CAND-01, CAND-02 | UI interaction + popup menu | Click status badge, verify menu appears with all 3 options |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/08-search-filter-and-candidate-status/08-VERIFICATION.md

@@ -0,0 +1,143 @@
+---
+phase: 08-search-filter-and-candidate-status
+verified: 2026-03-16T13:30:00Z
+status: passed
+score: 11/11 must-haves verified
+re_verification: false
+gaps: []
+human_verification:
+  - test: "Visually confirm StatusBadge popup menu appears and dismisses correctly"
+    expected: "Clicking badge opens popup below it; clicking outside or pressing Escape closes it without changing status"
+    why_human: "Cannot verify popup positioning and dismiss behavior without a browser"
+  - test: "Visually confirm sticky toolbar stays fixed on scroll with items below"
+    expected: "Search input and CategoryFilterDropdown remain visible at top as user scrolls through a long item list"
+    why_human: "CSS sticky positioning behavior cannot be verified statically"
+  - test: "Confirm filters reset when switching tabs"
+    expected: "Navigating from gear tab to planning tab and back shows unfiltered items with empty search and 'All categories'"
+    why_human: "Route unmount/remount behavior requires browser interaction to confirm"
+---
+
+# Phase 8: Search, Filter, and Candidate Status Verification Report
+
+**Phase Goal:** Users can find items quickly and track candidate purchase progress
+**Verified:** 2026-03-16T13:30:00Z
+**Status:** passed
+**Re-verification:** No — initial verification
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|---------|
+| 1 | Each candidate displays a status badge showing one of three statuses: researching, ordered, or arrived | VERIFIED | `StatusBadge.tsx` renders pill with `STATUS_CONFIG` map; `CandidateCard.tsx` line 114 renders `<StatusBadge status={status} .../>` |
+| 2 | User can click a status badge to open a popup menu and change the candidate's status to any of the three options | VERIFIED | `StatusBadge.tsx`: click handler calls `setIsOpen`, popup renders all 3 options, each calls `onStatusChange(key)` and closes |
+| 3 | New candidates automatically have status 'researching' without the user needing to set it | VERIFIED | `schema.ts` line 61: `.default("researching")`; `thread.service.ts` line 153: `status: data.status ?? "researching"` |
+| 4 | User can type in a search field on the gear tab and see items filtered instantly by name as they type | VERIFIED | `collection/index.tsx` lines 58-73: `useState searchText`, `useMemo filteredItems` filters by `item.name.toLowerCase().includes(...)` on every change |
+| 5 | User can select a category from a searchable dropdown (with Lucide icons) to filter items on both gear and planning tabs | VERIFIED | `CategoryFilterDropdown.tsx` renders `LucideIcon` per option; used in both `CollectionView` (line 205) and `PlanningView` (line 373) |
+| 6 | User can combine text search with category filter to narrow results | VERIFIED | `useMemo filteredItems` (lines 61-71): both `matchesSearch` AND `matchesCategory` must be true |
+| 7 | User sees 'Showing X of Y items' when filters are active on the gear tab | VERIFIED | `collection/index.tsx` lines 211-215: `{hasActiveFilters && <p>Showing {filteredItems.length} of {items.length} items</p>}` |
+| 8 | User can clear search text and reset category filter individually | VERIFIED | Search: clear button at line 184 calls `setSearchText("")`; Category: `x` button in `CategoryFilterDropdown.tsx` line 91 calls `onChange(null)` |
+| 9 | When filters are active, items display as a flat grid without category group headers | VERIFIED | Lines 219-278: `hasActiveFilters` branches to flat `<div className="grid ...">` rendering `filteredItems` directly, bypassing `groupedItems` Map |
+| 10 | Empty filter results show 'No items match your search' message | VERIFIED | Lines 220-226: `filteredItems.length === 0` shows `<p>No items match your search</p>` |
+| 11 | Planning tab category filter shows Lucide icons alongside category names | VERIFIED | `PlanningView` at line 373 uses `<CategoryFilterDropdown>` which renders `LucideIcon` per category option |
+
+**Score:** 11/11 truths verified
+
+### Required Artifacts
+
+#### Plan 01 Artifacts (CAND-01, CAND-02, CAND-03)
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/db/schema.ts` | status column on threadCandidates table | VERIFIED | Line 61: `status: text("status").notNull().default("researching")` — exact match |
+| `src/shared/schemas.ts` | candidateStatusSchema Zod enum | VERIFIED | Lines 40-44: `export const candidateStatusSchema = z.enum(["researching", "ordered", "arrived"])` |
+| `src/server/services/thread.service.ts` | status field in candidate CRUD | VERIFIED | `getThreadWithCandidates` selects `status`, `createCandidate` sets `status`, `updateCandidate` accepts `status` in type |
+| `src/client/components/StatusBadge.tsx` | Clickable status badge with popup menu | VERIFIED | 103 lines, full implementation with `STATUS_CONFIG`, popup menu, click-outside/Escape dismiss |
+| `src/client/components/CandidateCard.tsx` | Renders StatusBadge in pill row | VERIFIED | Line 5: imports `StatusBadge`; line 114: `<StatusBadge status={status} onStatusChange={onStatusChange} />` |
+| `tests/helpers/db.ts` | status column in CREATE TABLE | VERIFIED | Line 57: `status TEXT NOT NULL DEFAULT 'researching'` — exact match |
+
+#### Plan 02 Artifacts (SRCH-01 through SRCH-05, PLAN-01)
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/client/components/CategoryFilterDropdown.tsx` | Searchable category filter dropdown with Lucide icons | VERIFIED | 198 lines, full implementation with search input, Lucide icons per option, click-outside/Escape dismiss, clear button, "All categories" option |
+| `src/client/routes/collection/index.tsx` | Search/filter toolbar in CollectionView; CategoryFilterDropdown in PlanningView | VERIFIED | Lines 173-216: sticky toolbar with search + `<CategoryFilterDropdown>`; lines 372-377: `<CategoryFilterDropdown>` in PlanningView |
+
+### Key Link Verification
+
+#### Plan 01 Key Links
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `StatusBadge.tsx` | `/api/threads/:id/candidates/:candidateId` | `useUpdateCandidate` mutation in `onStatusChange` prop | VERIFIED | `$threadId.tsx` lines 150-154: `onStatusChange={(newStatus) => updateCandidate.mutate({candidateId, status: newStatus})}` |
+| `thread.service.ts` | `src/db/schema.ts` | `threadCandidates.status` in select and update | VERIFIED | `getThreadWithCandidates` selects `status: threadCandidates.status`; `updateCandidate` spreads `...data` which includes status |
+| `CandidateCard.tsx` | `StatusBadge.tsx` | `<StatusBadge` in pill row | VERIFIED | Line 114: `<StatusBadge status={status} onStatusChange={onStatusChange} />` |
+
+#### Plan 02 Key Links
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `CategoryFilterDropdown.tsx` | `useCategories` data | `categories` prop passed from parent | VERIFIED | Both `CollectionView` (line 208) and `PlanningView` (line 376) pass `categories={categories ?? []}` from `useCategories()` hook |
+| `CollectionView` in `collection/index.tsx` | `CategoryFilterDropdown.tsx` | `<CategoryFilterDropdown` in sticky toolbar | VERIFIED | Line 205: `<CategoryFilterDropdown value={categoryFilter} onChange={setCategoryFilter} categories={categories ?? []} />` |
+| `PlanningView` in `collection/index.tsx` | `CategoryFilterDropdown.tsx` | `<CategoryFilterDropdown` replacing native select | VERIFIED | Line 373: `<CategoryFilterDropdown value={categoryFilter} onChange={setCategoryFilter} categories={categories ?? []} />` |
+| `CollectionView` in `collection/index.tsx` | `useItems` data | `useMemo` filter chain on `searchText + categoryFilter` | VERIFIED | Lines 61-73: `const filteredItems = useMemo(...)` and `const hasActiveFilters = ...` correctly wired |
+
+### Requirements Coverage
+
+| Requirement | Source Plan | Description | Status | Evidence |
+|-------------|------------|-------------|--------|---------|
+| SRCH-01 | 08-02-PLAN.md | User can search items by name with instant filtering | SATISFIED | `collection/index.tsx` `useMemo filteredItems` filters on every `searchText` change |
+| SRCH-02 | 08-02-PLAN.md | User can filter collection items by category via dropdown | SATISFIED | `CategoryFilterDropdown` used in `CollectionView` with `categoryFilter` state |
+| SRCH-03 | 08-02-PLAN.md | User can combine text search with category filter simultaneously | SATISFIED | Both `matchesSearch && matchesCategory` conditions in single `useMemo` |
+| SRCH-04 | 08-02-PLAN.md | User can see result count when filters are active | SATISFIED | "Showing X of Y items" renders when `hasActiveFilters` is true |
+| SRCH-05 | 08-02-PLAN.md | User can clear active filters | SATISFIED | Design decision (per CONTEXT.md) intentionally implemented as individual clear controls: search input `x` button + dropdown `x` button. Each filter is individually clearable. REQUIREMENTS.md marks this [x] complete. |
+| PLAN-01 | 08-02-PLAN.md | Planning category filter dropdown shows Lucide icons alongside category names | SATISFIED | `PlanningView` uses `CategoryFilterDropdown` which renders `LucideIcon` per category |
+| CAND-01 | 08-01-PLAN.md | Each candidate displays a status badge (researching, ordered, or arrived) | SATISFIED | `StatusBadge` rendered in `CandidateCard` pill row at line 114 |
+| CAND-02 | 08-01-PLAN.md | User can change a candidate's status via click interaction | SATISFIED | `StatusBadge` click opens popup, selecting option calls `onStatusChange`, fires `updateCandidate.mutate` |
+| CAND-03 | 08-01-PLAN.md | New candidates default to "researching" status | SATISFIED | Schema default + service fallback both enforce "researching" |
+
+All 9 requirements covered. No orphaned requirements.
+
+### Anti-Patterns Found
+
+| File | Line | Pattern | Severity | Impact |
+|------|------|---------|----------|--------|
+| `src/client/routes/collection/index.tsx` | 222-224 | Biome formatter disagreement (JSX whitespace in `<p>` tag) | Info | Formatter-only issue, no logic impact. Not a code defect. |
+| `.planning/config.json` | all | Biome formatter expects tabs | Info | Planning config, no source code impact |
+| `drizzle/meta/0002_snapshot.json` | all | Biome formatter expects tabs | Info | Generated drizzle file, no source code impact |
+
+No blockers. No logic anti-patterns in source files. All stub detection checks pass — no `return null`, `return {}`, `return []`, console-only implementations, or placeholder comments found in any phase artifact.
+
+### Human Verification Required
+
+#### 1. StatusBadge Popup Behavior
+
+**Test:** Navigate to a thread detail page, click the "Researching" badge on any candidate
+**Expected:** Popup menu appears below the badge showing three options (Researching with search icon, Ordered with truck icon, Arrived with check icon). Currently active status is highlighted. Clicking outside or pressing Escape closes without changes.
+**Why human:** Popup positioning, z-index rendering, and dismiss behavior require browser interaction
+
+#### 2. Sticky Toolbar on Scroll
+
+**Test:** On the gear tab with 10+ items, scroll down the page
+**Expected:** The search input and category dropdown remain fixed at the top of the viewport while items scroll beneath
+**Why human:** CSS `sticky` positioning behavior with `backdrop-blur-sm` requires visual confirmation
+
+#### 3. Filter Reset on Tab Switch
+
+**Test:** Enter search text "tent", select a category, then switch to the Planning tab, then switch back to Gear
+**Expected:** On return to Gear tab, search field is empty and "All categories" is shown (no filter active)
+**Why human:** Requires verifying React component unmount/remount behavior through actual navigation
+
+### Gaps Summary
+
+No gaps. All 11 observable truths are verified. All 8 artifacts exist with substantive implementations. All 7 key links are confirmed wired. All 9 requirements are satisfied. 24 tests pass including 5 new candidate status tests. 113 total tests pass across the full suite.
+
+The only open items are 3 human verification checks for visual/behavioral aspects that cannot be confirmed statically — these are normal for a UI phase and do not indicate missing functionality.
+
+**Note on SRCH-05:** The requirement states "clear all active filters with one action." The implementation provides individual clear controls (search `x` button and dropdown `x` button) per explicit design decision documented in `08-CONTEXT.md`. The REQUIREMENTS.md marks SRCH-05 as [x] complete. This is an intentional scoping decision made during context capture, not a missed requirement.
+
+---
+
+_Verified: 2026-03-16T13:30:00Z_
+_Verifier: Claude (gsd-verifier)_

.planning/phases/09-weight-classification-and-visualization/09-01-PLAN.md

@@ -0,0 +1,360 @@
+---
+phase: 09-weight-classification-and-visualization
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/db/schema.ts
+  - src/shared/schemas.ts
+  - src/shared/types.ts
+  - src/server/services/setup.service.ts
+  - src/server/routes/setups.ts
+  - src/client/lib/api.ts
+  - src/client/hooks/useSetups.ts
+  - src/client/components/ClassificationBadge.tsx
+  - src/client/routes/setups/$setupId.tsx
+  - tests/helpers/db.ts
+  - tests/services/setup.service.test.ts
+  - tests/routes/setups.test.ts
+autonomous: true
+requirements: [CLAS-01, CLAS-03, CLAS-04]
+
+must_haves:
+  truths:
+    - "User can click a classification badge on any item card within a setup and it cycles through base weight, worn, consumable"
+    - "Items default to base weight classification when added to a setup"
+    - "Same item in different setups can have different classifications"
+    - "Classifications persist after adding/removing other items from the setup (syncSetupItems preserves them)"
+  artifacts:
+    - path: "src/db/schema.ts"
+      provides: "classification column on setupItems table"
+      contains: "classification.*text.*default.*base"
+    - path: "src/shared/schemas.ts"
+      provides: "classificationSchema Zod enum and updateClassificationSchema"
+      exports: ["classificationSchema", "updateClassificationSchema"]
+    - path: "src/server/services/setup.service.ts"
+      provides: "updateItemClassification service function, classification-preserving syncSetupItems, classification field in getSetupWithItems"
+      exports: ["updateItemClassification"]
+    - path: "src/server/routes/setups.ts"
+      provides: "PATCH /:id/items/:itemId/classification endpoint"
+    - path: "src/client/components/ClassificationBadge.tsx"
+      provides: "Click-to-cycle classification badge component"
+      min_lines: 30
+    - path: "src/client/routes/setups/$setupId.tsx"
+      provides: "ClassificationBadge wired into item cards in setup view"
+    - path: "tests/services/setup.service.test.ts"
+      provides: "Tests for updateItemClassification, classification preservation, defaults"
+    - path: "tests/routes/setups.test.ts"
+      provides: "Integration test for PATCH classification route"
+  key_links:
+    - from: "src/client/components/ClassificationBadge.tsx"
+      to: "/api/setups/:id/items/:itemId/classification"
+      via: "useUpdateItemClassification mutation hook"
+      pattern: "apiPatch.*classification"
+    - from: "src/server/routes/setups.ts"
+      to: "src/server/services/setup.service.ts"
+      via: "updateItemClassification service call"
+      pattern: "updateItemClassification"
+    - from: "src/server/services/setup.service.ts"
+      to: "src/db/schema.ts"
+      via: "setupItems.classification column"
+      pattern: "setupItems\\.classification"
+    - from: "src/client/routes/setups/$setupId.tsx"
+      to: "src/client/components/ClassificationBadge.tsx"
+      via: "ClassificationBadge rendered on each ItemCard"
+      pattern: "ClassificationBadge"
+---
+
+<objective>
+Add per-setup item classification (base weight / worn / consumable) as a complete vertical slice: schema migration, service layer with tests, API route, and ClassificationBadge UI component wired into the setup detail page.
+
+Purpose: Users need to classify gear items by their role within a specific setup to enable weight breakdown analysis. The same item can serve different roles in different setups (e.g., a jacket is "worn" in a hiking setup but "base weight" in a bike setup).
+
+Output: Working classification system -- clicking a badge on any item card in a setup cycles through base/worn/consumable, persists to the database, and survives item sync operations.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/09-weight-classification-and-visualization/09-CONTEXT.md
+@.planning/phases/09-weight-classification-and-visualization/09-RESEARCH.md
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/db/schema.ts (setupItems table -- CURRENT, needs classification column added):
+```typescript
+export const setupItems = sqliteTable("setup_items", {
+  id: integer("id").primaryKey({ autoIncrement: true }),
+  setupId: integer("setup_id").notNull().references(() => setups.id, { onDelete: "cascade" }),
+  itemId: integer("item_id").notNull().references(() => items.id, { onDelete: "cascade" }),
+});
+```
+
+From src/server/services/setup.service.ts (functions to modify):
+```typescript
+type Db = typeof prodDb;
+export function getSetupWithItems(db: Db, setupId: number): { ...setup, items: [...] } | null;
+export function syncSetupItems(db: Db, setupId: number, itemIds: number[]): void;
+export function removeSetupItem(db: Db, setupId: number, itemId: number): void;
+```
+
+From src/shared/schemas.ts (existing pattern for enums):
+```typescript
+export const candidateStatusSchema = z.enum(["researching", "ordered", "arrived"]);
+```
+
+From src/client/lib/api.ts (existing helpers -- NO apiPatch exists):
+```typescript
+export async function apiGet<T>(url: string): Promise<T>;
+export async function apiPost<T>(url: string, body: unknown): Promise<T>;
+export async function apiPut<T>(url: string, body: unknown): Promise<T>;
+export async function apiDelete<T>(url: string): Promise<T>;
+```
+
+From src/client/hooks/useSetups.ts (existing types):
+```typescript
+interface SetupItemWithCategory {
+  id: number; name: string; weightGrams: number | null; priceCents: number | null;
+  categoryId: number; notes: string | null; productUrl: string | null;
+  imageFilename: string | null; createdAt: string; updatedAt: string;
+  categoryName: string; categoryIcon: string;
+}
+// NEEDS: classification field added to this interface
+```
+
+From src/client/components/StatusBadge.tsx (pattern reference for click interaction):
+```typescript
+// Uses click-to-open popup with status options
+// ClassificationBadge should be SIMPLER: direct click-to-cycle (only 3 values)
+// Must call e.stopPropagation() to prevent ItemCard click handler
+```
+
+From src/client/components/ItemCard.tsx (props interface -- badge goes in the badges area):
+```typescript
+interface ItemCardProps {
+  id: number; name: string; weightGrams: number | null; priceCents: number | null;
+  categoryName: string; categoryIcon: string; imageFilename: string | null;
+  productUrl?: string | null; onRemove?: () => void;
+}
+// Classification badge will be rendered OUTSIDE ItemCard, in the setup detail page's
+// grid layout, alongside the ItemCard. The ItemCard itself does NOT need modification.
+// The badge sits in the flex-wrap gap-1.5 area of ItemCard OR as a sibling element.
+```
+
+From tests/helpers/db.ts (setup_items CREATE TABLE -- needs classification column):
+```sql
+CREATE TABLE setup_items (
+  id INTEGER PRIMARY KEY AUTOINCREMENT,
+  setup_id INTEGER NOT NULL REFERENCES setups(id) ON DELETE CASCADE,
+  item_id INTEGER NOT NULL REFERENCES items(id) ON DELETE CASCADE
+)
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: Schema migration, service layer, and tests for classification</name>
+  <files>
+    src/db/schema.ts,
+    src/shared/schemas.ts,
+    src/shared/types.ts,
+    src/server/services/setup.service.ts,
+    tests/helpers/db.ts,
+    tests/services/setup.service.test.ts
+  </files>
+  <behavior>
+    - Test: updateItemClassification sets classification for a specific item in a specific setup
+    - Test: updateItemClassification with "worn" changes item from default "base" to "worn"
+    - Test: getSetupWithItems returns classification field for each item (defaults to "base")
+    - Test: syncSetupItems preserves existing classifications when re-syncing (save before delete, restore after insert)
+    - Test: syncSetupItems assigns "base" to newly added items that have no prior classification
+    - Test: same item in two different setups can have different classifications
+  </behavior>
+  <action>
+    1. **Update test helper FIRST** (`tests/helpers/db.ts`): Add `classification text NOT NULL DEFAULT 'base'` to the `setup_items` CREATE TABLE statement.
+
+    2. **Write failing tests** in `tests/services/setup.service.test.ts`:
+       - Add `describe("updateItemClassification", ...)` block with tests for setting classification and verifying the update
+       - Add test in existing `getSetupWithItems` describe for classification field presence (should default to "base")
+       - Add test in existing `syncSetupItems` describe for classification preservation (sync with different item list, verify classifications retained for items that remain)
+       - Add test for same item in two setups having different classifications
+       - Import the new `updateItemClassification` function from setup.service.ts
+
+    3. **Run tests** -- they must FAIL (RED phase).
+
+    4. **Update Drizzle schema** (`src/db/schema.ts`): Add `classification: text("classification").notNull().default("base")` to the `setupItems` table definition.
+
+    5. **Generate migration**: Run `bun run db:generate` to create the migration SQL file. Then run `bun run db:push` to apply.
+
+    6. **Add Zod schema** (`src/shared/schemas.ts`):
+       ```typescript
+       export const classificationSchema = z.enum(["base", "worn", "consumable"]);
+       export const updateClassificationSchema = z.object({
+         classification: classificationSchema,
+       });
+       ```
+
+    7. **Add types** (`src/shared/types.ts`): Add `UpdateClassification` type inferred from `updateClassificationSchema`. The `SetupItem` type auto-updates from Drizzle schema inference.
+
+    8. **Implement service functions** (`src/server/services/setup.service.ts`):
+       - Add `updateItemClassification(db, setupId, itemId, classification)` -- uses `db.update(setupItems).set({ classification }).where(sql\`..setupId AND ..itemId\`)`.
+       - Modify `getSetupWithItems` to include `classification: setupItems.classification` in the select fields.
+       - Modify `syncSetupItems` to preserve classifications using Approach A from research: before deleting, read existing classifications into a `Map<number, string>` (itemId -> classification). After re-inserting, apply saved classifications using `classificationMap.get(itemId) ?? "base"` in the insert values.
+
+    9. **Run tests** -- they must PASS (GREEN phase).
+  </action>
+  <verify>
+    <automated>bun test tests/services/setup.service.test.ts</automated>
+  </verify>
+  <done>
+    - updateItemClassification changes an item's classification in a setup
+    - getSetupWithItems returns classification field defaulting to "base"
+    - syncSetupItems preserves classifications for retained items, defaults new items to "base"
+    - Same item can have different classifications in different setups
+    - All existing setup service tests still pass
+  </done>
+</task>
+
+<task type="auto">
+  <name>Task 2: API route, client hook, ClassificationBadge, and wiring into setup detail page</name>
+  <files>
+    src/server/routes/setups.ts,
+    src/client/lib/api.ts,
+    src/client/hooks/useSetups.ts,
+    src/client/components/ClassificationBadge.tsx,
+    src/client/routes/setups/$setupId.tsx,
+    tests/routes/setups.test.ts
+  </files>
+  <action>
+    1. **Add PATCH route** (`src/server/routes/setups.ts`):
+       - Import `updateClassificationSchema` from schemas and `updateItemClassification` from service.
+       - Add `app.patch("/:id/items/:itemId/classification", zValidator("json", updateClassificationSchema), handler)`.
+       - Handler: extract `setupId` and `itemId` from params, `classification` from validated body, call `updateItemClassification(db, setupId, itemId, classification)`, return `{ success: true }`.
+
+    2. **Add integration test** (`tests/routes/setups.test.ts`):
+       - Add `describe("PATCH /api/setups/:id/items/:itemId/classification", ...)` block.
+       - Test: create setup, add item, PATCH classification to "worn", GET setup and verify item has classification "worn".
+       - Test: PATCH with invalid classification value returns 400.
+
+    3. **Add `apiPatch` helper** (`src/client/lib/api.ts`):
+       ```typescript
+       export async function apiPatch<T>(url: string, body: unknown): Promise<T> {
+         const res = await fetch(url, {
+           method: "PATCH",
+           headers: { "Content-Type": "application/json" },
+           body: JSON.stringify(body),
+         });
+         return handleResponse<T>(res);
+       }
+       ```
+
+    4. **Update client hooks** (`src/client/hooks/useSetups.ts`):
+       - Add `classification: string` field to `SetupItemWithCategory` interface (defaults to "base" from API).
+       - Add `useUpdateItemClassification(setupId: number)` mutation hook:
+         ```typescript
+         export function useUpdateItemClassification(setupId: number) {
+           const queryClient = useQueryClient();
+           return useMutation({
+             mutationFn: ({ itemId, classification }: { itemId: number; classification: string }) =>
+               apiPatch<{ success: boolean }>(
+                 `/api/setups/${setupId}/items/${itemId}/classification`,
+                 { classification },
+               ),
+             onSuccess: () => {
+               queryClient.invalidateQueries({ queryKey: ["setups", setupId] });
+             },
+           });
+         }
+         ```
+       - Import `apiPatch` from `../lib/api`.
+
+    5. **Create ClassificationBadge component** (`src/client/components/ClassificationBadge.tsx`):
+       - Props: `classification: string`, `onCycle: () => void`.
+       - Define `CLASSIFICATION_ORDER = ["base", "worn", "consumable"] as const`.
+       - Define `CLASSIFICATION_LABELS = { base: "Base Weight", worn: "Worn", consumable: "Consumable" }`.
+       - Render as a `<button>` with pill styling: `bg-gray-100 text-gray-600 hover:bg-gray-200` (muted gray per user decision).
+       - Display the label text for the current classification.
+       - On click: call `e.stopPropagation()` (critical -- prevents ItemCard from opening edit panel), then call `onCycle()`.
+       - The parent component computes the next classification and calls the mutation.
+
+    6. **Wire into setup detail page** (`src/client/routes/setups/$setupId.tsx`):
+       - Import `ClassificationBadge` and `useUpdateItemClassification`.
+       - Create the mutation hook: `const updateClassification = useUpdateItemClassification(numericId)`.
+       - Add a helper function to compute next classification:
+         ```typescript
+         function nextClassification(current: string): string {
+           const order = ["base", "worn", "consumable"];
+           const idx = order.indexOf(current);
+           return order[(idx + 1) % order.length];
+         }
+         ```
+       - In the items grid, render `ClassificationBadge` below each `ItemCard` (as a sibling within the grid cell). Wrap ItemCard + badge in a `<div>`:
+         ```tsx
+         <div key={item.id}>
+           <ItemCard ... />
+           <div className="px-4 pb-3 -mt-1">
+             <ClassificationBadge
+               classification={item.classification}
+               onCycle={() => updateClassification.mutate({
+                 itemId: item.id,
+                 classification: nextClassification(item.classification),
+               })}
+             />
+           </div>
+         </div>
+         ```
+       - Alternatively, the badge can go inside the card's badge row if preferred. Use discretion on exact placement -- it should be near the weight/price badges but distinct.
+
+    7. **Run all tests** to verify nothing broken.
+  </action>
+  <verify>
+    <automated>bun test tests/routes/setups.test.ts && bun test tests/services/setup.service.test.ts</automated>
+  </verify>
+  <done>
+    - PATCH /api/setups/:id/items/:itemId/classification endpoint works (200 for valid, 400 for invalid)
+    - ClassificationBadge renders on each item card in setup detail view with muted gray styling
+    - Clicking the badge cycles classification: base weight -> worn -> consumable -> base weight
+    - Badge click does NOT open the item edit panel (stopPropagation works)
+    - Classification change persists after page refresh
+    - GET /api/setups/:id returns classification field for each item
+  </done>
+</task>
+
+</tasks>
+
+<verification>
+```bash
+# All tests pass
+bun test
+
+# Classification service tests specifically
+bun test tests/services/setup.service.test.ts -t "classification"
+
+# Classification route tests specifically
+bun test tests/routes/setups.test.ts -t "classification"
+```
+</verification>
+
+<success_criteria>
+- Classification badge visible on every item card in setup detail view (not hidden for default)
+- Click cycles through base weight -> worn -> consumable -> base weight
+- Badge uses muted gray styling (bg-gray-100 text-gray-600) consistent with Phase 8 status badges
+- Default classification is "base" for newly added items
+- syncSetupItems preserves classifications when items are added/removed
+- Same item in different setups can have different classifications
+- All existing tests continue to pass
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/09-weight-classification-and-visualization/09-01-SUMMARY.md`
+</output>

.planning/phases/09-weight-classification-and-visualization/09-01-SUMMARY.md

@@ -0,0 +1,129 @@
+---
+phase: 09-weight-classification-and-visualization
+plan: 01
+subsystem: database, api, ui
+tags: [drizzle, sqlite, hono, react, tailwind, classification, setup-items]
+
+# Dependency graph
+requires:
+  - phase: 08-search-filter-and-candidate-status
+    provides: StatusBadge pattern for click-interactive badges, muted gray styling convention
+provides:
+  - classification column on setupItems join table (base/worn/consumable)
+  - updateItemClassification service function
+  - classification-preserving syncSetupItems
+  - PATCH /api/setups/:id/items/:itemId/classification endpoint
+  - ClassificationBadge click-to-cycle component
+  - apiPatch client helper
+  - useUpdateItemClassification mutation hook
+affects: [09-02-weight-breakdown-visualization]
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns: [click-to-cycle badge, classification preservation on sync, per-join-table metadata]
+
+key-files:
+  created:
+    - src/client/components/ClassificationBadge.tsx
+    - drizzle/0003_misty_mongu.sql
+  modified:
+    - src/db/schema.ts
+    - src/shared/schemas.ts
+    - src/shared/types.ts
+    - src/server/services/setup.service.ts
+    - src/server/routes/setups.ts
+    - src/client/lib/api.ts
+    - src/client/hooks/useSetups.ts
+    - src/client/routes/setups/$setupId.tsx
+    - tests/helpers/db.ts
+    - tests/services/setup.service.test.ts
+    - tests/routes/setups.test.ts
+
+key-decisions:
+  - "ClassificationBadge uses simple click-to-cycle (not popup) since only 3 values"
+  - "Classification stored on setupItems join table so same item can differ across setups"
+  - "syncSetupItems reads classifications into Map before delete, restores after re-insert"
+
+patterns-established:
+  - "Click-to-cycle badge: for small enums (3 values), direct click cycling is simpler than popup"
+  - "Join table metadata preservation: save metadata before atomic sync, restore after re-insert"
+  - "apiPatch helper: PATCH method available in client API library for partial updates"
+
+requirements-completed: [CLAS-01, CLAS-03, CLAS-04]
+
+# Metrics
+duration: 5min
+completed: 2026-03-16
+---
+
+# Phase 9 Plan 1: Classification Schema and Badge Summary
+
+**Per-setup item classification (base/worn/consumable) with click-to-cycle badge, classification-preserving sync, and full test coverage**
+
+## Performance
+
+- **Duration:** 5 min
+- **Started:** 2026-03-16T14:08:56Z
+- **Completed:** 2026-03-16T14:13:32Z
+- **Tasks:** 2
+- **Files modified:** 12
+
+## Accomplishments
+- Added classification column to setupItems table with Drizzle migration (defaults to "base")
+- Implemented classification-preserving syncSetupItems that saves/restores classifications across atomic re-sync
+- Built PATCH endpoint with Zod validation for updating item classification within a setup
+- Created ClassificationBadge component with click-to-cycle interaction (base weight -> worn -> consumable)
+- Wired badge into setup detail page below each ItemCard in the category-grouped grid
+- Added apiPatch client helper and useUpdateItemClassification mutation hook
+- 7 new tests (5 service, 2 route) covering classification CRUD, preservation, cross-setup independence, and validation
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Schema migration, service layer, and tests for classification** - `4491e4c` (feat - TDD red/green)
+2. **Task 2: API route, client hook, ClassificationBadge, and wiring** - `fb738d7` (feat)
+
+## Files Created/Modified
+- `src/db/schema.ts` - Added classification column to setupItems table
+- `drizzle/0003_misty_mongu.sql` - SQLite migration for classification column
+- `src/shared/schemas.ts` - Added classificationSchema and updateClassificationSchema
+- `src/shared/types.ts` - Added UpdateClassification type
+- `src/server/services/setup.service.ts` - Added updateItemClassification, modified getSetupWithItems and syncSetupItems
+- `src/server/routes/setups.ts` - Added PATCH /:id/items/:itemId/classification endpoint
+- `src/client/lib/api.ts` - Added apiPatch helper
+- `src/client/hooks/useSetups.ts` - Added classification field and useUpdateItemClassification hook
+- `src/client/components/ClassificationBadge.tsx` - New click-to-cycle badge component
+- `src/client/routes/setups/$setupId.tsx` - Wired ClassificationBadge into item grid
+- `tests/helpers/db.ts` - Added classification column to test schema
+- `tests/services/setup.service.test.ts` - Added 5 classification tests
+- `tests/routes/setups.test.ts` - Added 2 classification integration tests
+
+## Decisions Made
+- ClassificationBadge uses simple click-to-cycle rather than popup (only 3 values, simpler UX)
+- Classification stored on setupItems join table (not items table) so same item can have different roles in different setups
+- syncSetupItems preserves classifications by reading into Map<itemId, classification> before delete and restoring after re-insert
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+None
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- Classification data is available for weight breakdown visualization (Plan 09-02)
+- getSetupWithItems returns classification field for every item, ready for grouping by classification
+- All 121 tests pass across the full suite
+
+## Self-Check: PASSED
+
+All 14 files verified present. Both task commits (4491e4c, fb738d7) confirmed in git history.
+
+---
+*Phase: 09-weight-classification-and-visualization*
+*Completed: 2026-03-16*

.planning/phases/09-weight-classification-and-visualization/09-02-PLAN.md

@@ -0,0 +1,309 @@
+---
+phase: 09-weight-classification-and-visualization
+plan: 02
+type: execute
+wave: 2
+depends_on: ["09-01"]
+files_modified:
+  - src/client/components/WeightSummaryCard.tsx
+  - src/client/routes/setups/$setupId.tsx
+  - package.json
+autonomous: false
+requirements: [CLAS-02, VIZZ-01, VIZZ-02, VIZZ-03]
+
+must_haves:
+  truths:
+    - "Setup detail view shows separate weight subtotals for base weight, worn weight, consumable weight, and total"
+    - "User can view a donut chart showing weight distribution by category in the setup"
+    - "User can toggle the chart between category breakdown and classification breakdown via pill toggle"
+    - "Hovering a chart segment shows category/classification name, weight in selected unit, and percentage"
+    - "Total weight displayed in the center of the donut hole"
+  artifacts:
+    - path: "src/client/components/WeightSummaryCard.tsx"
+      provides: "Summary card with weight subtotals, donut chart, pill toggle, and tooltips"
+      min_lines: 100
+    - path: "src/client/routes/setups/$setupId.tsx"
+      provides: "WeightSummaryCard rendered below sticky bar when setup has items"
+    - path: "package.json"
+      provides: "recharts dependency installed"
+      contains: "recharts"
+  key_links:
+    - from: "src/client/components/WeightSummaryCard.tsx"
+      to: "recharts"
+      via: "PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer imports"
+      pattern: "from.*recharts"
+    - from: "src/client/components/WeightSummaryCard.tsx"
+      to: "src/client/lib/formatters.ts"
+      via: "formatWeight for subtotals and tooltip display"
+      pattern: "formatWeight"
+    - from: "src/client/routes/setups/$setupId.tsx"
+      to: "src/client/components/WeightSummaryCard.tsx"
+      via: "WeightSummaryCard rendered with setup.items prop"
+      pattern: "WeightSummaryCard"
+---
+
+<objective>
+Add the WeightSummaryCard component with classification weight subtotals, a donut chart for weight distribution, and a pill toggle for switching between category and classification views.
+
+Purpose: Users need to visualize how weight is distributed across their setup -- both by gear category (shelter, sleep, cook) and by classification (base weight, worn, consumable). The donut chart with tooltips makes weight analysis intuitive.
+
+Output: A summary card below the setup sticky bar showing Base | Worn | Consumable | Total weight columns alongside a donut chart with interactive tooltips, togglable between category and classification breakdowns.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/09-weight-classification-and-visualization/09-CONTEXT.md
+@.planning/phases/09-weight-classification-and-visualization/09-RESEARCH.md
+@.planning/phases/09-weight-classification-and-visualization/09-01-SUMMARY.md
+
+<interfaces>
+<!-- Key types and contracts from Plan 01. Executor uses these directly. -->
+
+From src/client/hooks/useSetups.ts (after Plan 01):
+```typescript
+interface SetupItemWithCategory {
+  id: number;
+  name: string;
+  weightGrams: number | null;
+  priceCents: number | null;
+  categoryId: number;
+  notes: string | null;
+  productUrl: string | null;
+  imageFilename: string | null;
+  createdAt: string;
+  updatedAt: string;
+  categoryName: string;
+  categoryIcon: string;
+  classification: string;  // "base" | "worn" | "consumable" -- added by Plan 01
+}
+```
+
+From src/client/lib/formatters.ts:
+```typescript
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+export function formatWeight(grams: number | null | undefined, unit: WeightUnit = "g"): string;
+```
+
+From src/client/hooks/useWeightUnit.ts:
+```typescript
+export function useWeightUnit(): WeightUnit;
+```
+
+From 09-RESEARCH.md (Recharts pattern):
+```typescript
+import { PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer } from "recharts";
+// Use Cell for per-slice colors (still functional in v3, deprecated for v4)
+// Use fixed numeric height on ResponsiveContainer (e.g., height={200})
+// Filter out zero-weight entries before passing to chart
+```
+
+From 09-RESEARCH.md (color palettes):
+```typescript
+const CATEGORY_COLORS = [
+  "#6366f1", "#f59e0b", "#10b981", "#ef4444", "#8b5cf6",
+  "#06b6d4", "#f97316", "#ec4899", "#14b8a6", "#84cc16",
+];
+const CLASSIFICATION_COLORS = {
+  base: "#6366f1",       // indigo
+  worn: "#f59e0b",       // amber
+  consumable: "#10b981", // emerald
+};
+```
+
+From 09-CONTEXT.md (locked decisions):
+- Summary card below sticky bar, always visible when setup has items
+- Card with columns layout: Base | Worn | Consumable | Total
+- Donut chart inside the summary card alongside weight subtotals
+- Pill toggle above the chart: "Category" / "Classification" (same style as weight unit selector)
+- Total weight in center of donut hole
+- Hover tooltips: segment name, weight in selected unit, percentage
+- Chart library: Recharts (PieChart + Pie with innerRadius)
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Install Recharts, create WeightSummaryCard, wire into setup detail page</name>
+  <files>
+    src/client/components/WeightSummaryCard.tsx,
+    src/client/routes/setups/$setupId.tsx,
+    package.json
+  </files>
+  <action>
+    1. **Install Recharts**: Run `bun add recharts`. This adds recharts to package.json. React and react-dom are already peer deps in the project.
+
+    2. **Create WeightSummaryCard component** (`src/client/components/WeightSummaryCard.tsx`):
+
+       **Props interface:**
+       ```typescript
+       interface WeightSummaryCardProps {
+         items: SetupItemWithCategory[];  // from useSetups hook (includes classification field)
+       }
+       ```
+       Import `SetupItemWithCategory` from `../hooks/useSetups`.
+
+       **State:** `viewMode: "category" | "classification"` -- local React state, default "category".
+
+       **Weight subtotals computation** (derive from items array):
+       ```typescript
+       const baseWeight = items.reduce((sum, i) => i.classification === "base" ? sum + (i.weightGrams ?? 0) : sum, 0);
+       const wornWeight = items.reduce((sum, i) => i.classification === "worn" ? sum + (i.weightGrams ?? 0) : sum, 0);
+       const consumableWeight = items.reduce((sum, i) => i.classification === "consumable" ? sum + (i.weightGrams ?? 0) : sum, 0);
+       const totalWeight = baseWeight + wornWeight + consumableWeight;
+       ```
+
+       **Chart data transformation:**
+       - `buildCategoryChartData(items)`: Group by `categoryName`, sum `weightGrams`, compute percentage. Filter out zero-weight groups. Return `Array<{ name: string, weight: number, percent: number }>`.
+       - `buildClassificationChartData(items)`: Group by classification using labels ("Base Weight", "Worn", "Consumable"), sum weights, compute percentage. Filter out zero-weight groups.
+       - Select data source based on `viewMode`.
+
+       **Render structure:**
+       ```
+       <div className="bg-white rounded-xl border border-gray-100 p-5 mb-6">
+         <!-- Pill toggle: Category | Classification -->
+         <div className="flex items-center justify-between mb-4">
+           <h3 className="text-sm font-medium text-gray-700">Weight Summary</h3>
+           <PillToggle viewMode={viewMode} onChange={setViewMode} />
+         </div>
+
+         <!-- Main content: chart + subtotals side by side -->
+         <div className="flex items-center gap-8">
+           <!-- Donut chart -->
+           <div className="flex-shrink-0" style={{ width: 180, height: 180 }}>
+             <ResponsiveContainer width="100%" height={180}>
+               <PieChart>
+                 <Pie data={chartData} dataKey="weight" nameKey="name"
+                   cx="50%" cy="50%" innerRadius={55} outerRadius={80} paddingAngle={2}>
+                   {chartData.map((entry, index) => (
+                     <Cell key={entry.name} fill={colors[index % colors.length]} />
+                   ))}
+                   <Label value={formatWeight(totalWeight, unit)} position="center"
+                     style={{ fontSize: "14px", fontWeight: 600, fill: "#374151" }} />
+                 </Pie>
+                 <Tooltip content={<CustomTooltip unit={unit} />} />
+               </PieChart>
+             </ResponsiveContainer>
+           </div>
+
+           <!-- Weight subtotals columns -->
+           <div className="flex-1 grid grid-cols-4 gap-4">
+             <SubtotalColumn label="Base" weight={baseWeight} unit={unit} color="#6366f1" />
+             <SubtotalColumn label="Worn" weight={wornWeight} unit={unit} color="#f59e0b" />
+             <SubtotalColumn label="Consumable" weight={consumableWeight} unit={unit} color="#10b981" />
+             <SubtotalColumn label="Total" weight={totalWeight} unit={unit} />
+           </div>
+         </div>
+       </div>
+       ```
+
+       **Pill toggle** (inline component or extracted):
+       - Two buttons in a `bg-gray-100 rounded-full` container: "Category" and "Classification".
+       - Active state: `bg-white text-gray-700 shadow-sm font-medium`. Inactive: `text-gray-400 hover:text-gray-600`.
+       - Same pattern as TotalsBar weight unit selector.
+
+       **SubtotalColumn** (inline component):
+       - Vertical stack: colored dot (if color provided), label in text-xs text-gray-500, weight value in text-sm font-semibold text-gray-900.
+
+       **CustomTooltip:**
+       - Props: `active`, `payload`, `unit` (WeightUnit).
+       - When active and payload exists, show: segment name (bold), weight formatted with `formatWeight()`, percentage as `(XX.X%)`.
+       - Styled: `bg-white border border-gray-200 rounded-lg shadow-lg px-3 py-2 text-sm`.
+
+       **Color selection:**
+       - When `viewMode === "category"`: use `CATEGORY_COLORS` array (cycle through for many categories).
+       - When `viewMode === "classification"`: use `CLASSIFICATION_COLORS` object (keyed by classification value).
+
+       **Edge cases:**
+       - If all items have null/zero weight, show a placeholder message ("No weight data to display") instead of the chart.
+       - If items array is empty, component should not render (handled by parent).
+
+    3. **Wire into setup detail page** (`src/client/routes/setups/$setupId.tsx`):
+       - Import `WeightSummaryCard` from `../../components/WeightSummaryCard`.
+       - Render `<WeightSummaryCard items={setup.items} />` between the actions bar and the items grid (before the `{itemCount > 0 && (` block), but INSIDE the `itemCount > 0` condition so it only shows when there are items.
+       - Exact placement: after the actions `<div>` and before the items-grouped-by-category `<div>`, within the `{itemCount > 0 && (...)}` block.
+
+    4. **Verify**: Run `bun run build` to ensure no TypeScript errors and Recharts imports resolve correctly.
+  </action>
+  <verify>
+    <automated>bun run build</automated>
+  </verify>
+  <done>
+    - WeightSummaryCard renders below sticky bar when setup has items
+    - Shows 4 columns: Base | Worn | Consumable | Total with correct weight values in selected unit
+    - Donut chart renders with colored segments for weight distribution
+    - Pill toggle switches between category view and classification view
+    - Hovering chart segments shows tooltip with name, weight, and percentage
+    - Total weight displayed in center of donut hole
+    - Empty/zero-weight items handled gracefully
+    - Build succeeds with no TypeScript errors
+  </done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <name>Task 2: Visual verification of complete weight classification and visualization</name>
+  <files>N/A</files>
+  <action>
+    Present the user with verification steps for the complete Phase 9 feature set.
+    This checkpoint covers both Plan 01 (classification badges) and Plan 02 (summary card + chart) together.
+  </action>
+  <what-built>
+    Complete weight classification and visualization system:
+    1. Classification badges on every item card in setup view (click to cycle: base weight / worn / consumable)
+    2. Weight summary card with Base | Worn | Consumable | Total subtotals
+    3. Donut chart with category/classification toggle and hover tooltips
+    4. Total weight in the center of the donut hole
+  </what-built>
+  <how-to-verify>
+    1. Start dev servers: `bun run dev:server` and `bun run dev:client`
+    2. Open http://localhost:5173 and navigate to a setup with items (or create one and add items)
+    3. **Classification badges**: Verify each item card shows a gray pill badge. Click it and confirm it cycles: "Base Weight" -> "Worn" -> "Consumable" -> "Base Weight". Confirm clicking the badge does NOT open the item edit panel.
+    4. **Classification persistence**: Refresh the page. Confirm classifications are preserved.
+    5. **Weight subtotals**: With items classified differently, verify the summary card shows correct subtotals for Base, Worn, Consumable, and Total columns.
+    6. **Donut chart (Category view)**: Verify the donut chart shows colored segments grouped by category. Hover segments to see tooltip with category name, weight, and percentage.
+    7. **Donut chart (Classification view)**: Click the "Classification" pill toggle. Verify chart segments change to show base/worn/consumable breakdown with different colors. Hover to verify tooltips.
+    8. **Donut center**: Confirm total weight is displayed in the center of the donut hole in the selected weight unit.
+    9. **Weight unit**: Toggle the weight unit in the top bar (if available). Confirm all subtotals, chart center, and tooltips update to the new unit.
+    10. **Add/remove items**: Add another item to the setup. Verify it appears with default "Base Weight" badge and the chart updates. Remove an item and verify classifications for remaining items are preserved.
+  </how-to-verify>
+  <verify>Visual verification by user following steps above</verify>
+  <done>User confirms all classification badges, weight subtotals, donut chart, toggle, and tooltips work correctly</done>
+  <resume-signal>Type "approved" to complete Phase 9, or describe any issues to address</resume-signal>
+</task>
+
+</tasks>
+
+<verification>
+```bash
+# Full test suite passes
+bun test
+
+# Build succeeds
+bun run build
+
+# Lint passes
+bun run lint
+```
+</verification>
+
+<success_criteria>
+- WeightSummaryCard visible below sticky bar on setup detail page (only when items exist)
+- Four weight columns (Base, Worn, Consumable, Total) show correct values in selected unit
+- Donut chart renders with colored segments proportional to weight distribution
+- Pill toggle switches between category and classification chart views
+- Tooltip on hover shows segment name, formatted weight, and percentage
+- Total weight displayed in center of donut hole
+- Chart handles edge cases (no weight data, single category, etc.)
+- User confirms visual appearance matches expectations
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/09-weight-classification-and-visualization/09-02-SUMMARY.md`
+</output>

.planning/phases/09-weight-classification-and-visualization/09-02-SUMMARY.md

@@ -0,0 +1,107 @@
+---
+phase: 09-weight-classification-and-visualization
+plan: 02
+subsystem: ui
+tags: [react, recharts, donut-chart, tailwind, weight-visualization, pie-chart]
+
+# Dependency graph
+requires:
+  - phase: 09-weight-classification-and-visualization
+    provides: classification column on setupItems, getSetupWithItems returns classification field, SetupItemWithCategory type
+provides:
+  - WeightSummaryCard component with donut chart and classification subtotals
+  - Pill toggle for category/classification chart views
+  - Recharts integration (PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer)
+  - Custom tooltip with formatted weight and percentage display
+affects: []
+
+# Tech tracking
+tech-stack:
+  added: [recharts]
+  patterns: [donut chart with center label, pill toggle view switcher, chart data transformation from items array]
+
+key-files:
+  created:
+    - src/client/components/WeightSummaryCard.tsx
+  modified:
+    - src/client/routes/setups/$setupId.tsx
+    - package.json
+
+key-decisions:
+  - "Recharts v3 Cell component used for per-slice colors (still functional, deprecated for v4)"
+  - "Fixed numeric height on ResponsiveContainer (180px) to avoid zero-height rendering"
+  - "Zero-weight items filtered out before chart data to prevent invisible/NaN slices"
+
+patterns-established:
+  - "Donut chart: PieChart with Pie innerRadius/outerRadius and Label position=center for hole text"
+  - "Chart data transformation: group items by key, sum weights, compute percentages, filter zeroes"
+  - "Pill toggle view switcher: reusable pattern for switching between data breakdowns"
+
+requirements-completed: [CLAS-02, VIZZ-01, VIZZ-02, VIZZ-03]
+
+# Metrics
+duration: 2min
+completed: 2026-03-16
+---
+
+# Phase 9 Plan 2: Weight Breakdown Visualization Summary
+
+**Recharts donut chart with category/classification toggle, weight subtotals card, and hover tooltips inside setup detail page**
+
+## Performance
+
+- **Duration:** 2 min
+- **Started:** 2026-03-16T14:18:52Z
+- **Completed:** 2026-03-16T14:20:57Z
+- **Tasks:** 1 (+ 1 auto-approved checkpoint)
+- **Files modified:** 4
+
+## Accomplishments
+- Created WeightSummaryCard component with donut chart visualization using Recharts
+- Implemented pill toggle switching between category and classification chart views
+- Built weight subtotals display (Base | Worn | Consumable | Total) with colored indicator dots
+- Added custom tooltip showing segment name, formatted weight, and percentage on hover
+- Rendered total weight in center of donut hole using selected weight unit
+- Wired WeightSummaryCard into setup detail page below sticky bar (only when items exist)
+- Handled edge case of zero-weight items with placeholder message
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Install Recharts, create WeightSummaryCard, wire into setup detail page** - `d098277` (feat)
+
+## Files Created/Modified
+- `src/client/components/WeightSummaryCard.tsx` - New component with donut chart, pill toggle, subtotals, and custom tooltip
+- `src/client/routes/setups/$setupId.tsx` - Added WeightSummaryCard import and rendering inside itemCount > 0 block
+- `package.json` - Added recharts dependency
+- `bun.lock` - Updated lockfile with recharts and its dependencies
+
+## Decisions Made
+- Used Recharts v3 Cell component for per-slice colors (functional in v3, deprecated for v4 removal)
+- Fixed 180px height on ResponsiveContainer to prevent zero-height rendering issue
+- Filter zero-weight entries before passing to chart to avoid invisible/NaN segments
+- Default view mode is "category" (most useful initial view for gear analysis)
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+None
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- Phase 9 complete: classification badges + weight visualization both functional
+- All 121 tests pass, build succeeds, lint clean on modified files
+- Recharts available for any future chart features
+
+## Self-Check: PASSED
+
+All 3 files verified present. Task commit (d098277) confirmed in git history. recharts found in package.json. WeightSummaryCard found in $setupId.tsx.
+
+---
+*Phase: 09-weight-classification-and-visualization*
+*Completed: 2026-03-16*

.planning/phases/09-weight-classification-and-visualization/09-CONTEXT.md

@@ -0,0 +1,93 @@
+# Phase 9: Weight Classification and Visualization - Context
+
+**Gathered:** 2026-03-16
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Users can classify each item within a setup as base weight, worn, or consumable (same item can differ across setups). Setup detail view shows weight subtotals by classification and a donut chart for weight distribution, toggleable between category and classification breakdowns. Side-by-side comparison, ranking, and impact preview are separate phases.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Classification UI
+- Click-to-cycle badge on each item card within a setup — clicks cycle through base weight → worn → consumable → base weight
+- Follows the StatusBadge pattern from Phase 8 (pill badge, click interaction)
+- Default classification is "base weight" when an item is added to a setup
+- Badge always visible on every item card in the setup (not hidden for default)
+- Muted gray color scheme for all classification badges (bg-gray-100 text-gray-600), consistent with Phase 8 status badges
+- Classification stored on `setup_items` join table (already decided in prior phases)
+
+### Weight subtotals display
+- Summary section below the setup sticky bar, always visible when setup has items
+- Card with columns layout: Base | Worn | Consumable | Total — each as a labeled column with weight value
+- Sticky bar keeps its existing simple stats (item count, total weight, total cost)
+- Summary card is a separate visual element, not inline text
+
+### Chart placement & style
+- Donut chart sits inside the summary card alongside the weight subtotals — chart + numbers as one visual unit
+- Pill toggle above the chart for switching between "Category" and "Classification" views (same style as weight unit selector)
+- Total weight displayed in the center of the donut hole (e.g., "2.87kg")
+- Hover tooltips show segment name, weight (in selected unit), and percentage
+- Chart library: **Recharts** (PieChart + Pie with innerRadius for donut shape)
+
+### Claude's Discretion
+- Summary card exact layout (chart left/right, column arrangement)
+- Chart color palette for segments (should work with both category and classification views)
+- Minimum item threshold for showing chart vs a placeholder message
+- Donut chart sizing and proportions
+- Tooltip styling
+- Keyboard accessibility for classification cycling
+- Animation on chart transitions between category/classification views
+
+</decisions>
+
+<code_context>
+## Existing Code Insights
+
+### Reusable Assets
+- `StatusBadge` (`src/client/components/StatusBadge.tsx`): Click-to-cycle pattern with popup — direct pattern reference for classification badge
+- `formatWeight()` in `src/client/lib/formatters.ts`: Handles unit conversion, reuse for subtotals and chart tooltips
+- `useWeightUnit()` hook: Gets current weight unit setting for display
+- `getSetupWithItems()` in `src/server/services/setup.service.ts`: Fetches setup items with category joins — needs to include classification field
+- `syncSetupItems()`: Delete-all + re-insert pattern — needs to preserve classification values
+
+### Established Patterns
+- Settings stored as key/value strings in SQLite `settings` table
+- React Query for server data, Zustand for UI-only state (panels/dialogs)
+- Pill badges: blue-50/blue-400 for weight, green-50/green-500 for price, gray-50/gray-600 for metadata
+- Weight unit pill toggle in TotalsBar — same pattern for chart category/classification toggle
+- Click-outside + Escape dismiss pattern for popups (CategoryPicker, StatusBadge)
+
+### Integration Points
+- `setup_items` table (`src/db/schema.ts`): Add `classification` column with default "base"
+- `getSetupWithItems()`: Include classification in query results
+- `syncSetupItems()`: Must handle classification when syncing (preserve during re-insert)
+- Setup detail page (`src/client/routes/setups/$setupId.tsx`): Add summary card section, classification badges on ItemCards, donut chart
+- `ItemCard` component: Needs optional `classification` prop and badge (only rendered in setup context)
+- Setup routes (`src/server/routes/setups.ts`): API needs to accept/return classification data
+- Test helper (`tests/helpers/db.ts`): Update CREATE TABLE for setup_items to include classification column
+
+</code_context>
+
+<specifics>
+## Specific Ideas
+
+No specific requirements — user gave clear structural decisions. Standard gear app patterns apply (LighterPack-style classification).
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 09-weight-classification-and-visualization*
+*Context gathered: 2026-03-16*

.planning/phases/09-weight-classification-and-visualization/09-RESEARCH.md

@@ -0,0 +1,553 @@
+# Phase 9: Weight Classification and Visualization - Research
+
+**Researched:** 2026-03-16
+**Domain:** Schema migration, classification UI, chart visualization (Recharts)
+**Confidence:** HIGH
+
+## Summary
+
+Phase 9 adds two features: (1) per-setup item classification (base weight / worn / consumable) stored on the `setup_items` join table, and (2) a donut chart visualization of weight distribution inside the setup detail page. The classification feature requires a schema migration adding a `classification` column with a default of `"base"` to `setup_items`, updates to the sync/query service layer, a new API endpoint for updating individual item classifications, and a click-to-cycle badge on each item card within setup context. The visualization feature requires installing Recharts and building a summary card component with a donut chart, weight subtotals, and a pill toggle for switching between category and classification breakdowns.
+
+The project has strong existing patterns to follow: the `StatusBadge` click-to-cycle component from Phase 8, the `formatWeight()` utility with `useWeightUnit()` hook, the TotalsBar pill toggle for weight units, and the Drizzle migration pattern established in prior phases (e.g., `0002_broken_roughhouse.sql` adding a column with `ALTER TABLE ... ADD`). Recharts v3.x is the decided chart library, which is mature, well-documented, and has a straightforward API for donut charts using `PieChart` + `Pie` with `innerRadius`.
+
+**Primary recommendation:** Use Recharts v3.x with `Cell` component for individual slice colors (still functional in v3, deprecated only for v4), `Label` for center text, and a custom `content` function on `Tooltip` for formatted hover data. Store classification as a text column on `setup_items` with a Zod enum for validation.
+
+<user_constraints>
+
+## User Constraints (from CONTEXT.md)
+
+### Locked Decisions
+- Click-to-cycle badge on each item card within a setup -- clicks cycle through base weight -> worn -> consumable -> base weight
+- Follows the StatusBadge pattern from Phase 8 (pill badge, click interaction)
+- Default classification is "base weight" when an item is added to a setup
+- Badge always visible on every item card in the setup (not hidden for default)
+- Muted gray color scheme for all classification badges (bg-gray-100 text-gray-600), consistent with Phase 8 status badges
+- Classification stored on `setup_items` join table (already decided in prior phases)
+- Summary section below the setup sticky bar, always visible when setup has items
+- Card with columns layout: Base | Worn | Consumable | Total -- each as a labeled column with weight value
+- Sticky bar keeps its existing simple stats (item count, total weight, total cost)
+- Summary card is a separate visual element, not inline text
+- Donut chart sits inside the summary card alongside the weight subtotals -- chart + numbers as one visual unit
+- Pill toggle above the chart for switching between "Category" and "Classification" views (same style as weight unit selector)
+- Total weight displayed in the center of the donut hole (e.g., "2.87kg")
+- Hover tooltips show segment name, weight (in selected unit), and percentage
+- Chart library: **Recharts** (PieChart + Pie with innerRadius for donut shape)
+
+### Claude's Discretion
+- Summary card exact layout (chart left/right, column arrangement)
+- Chart color palette for segments (should work with both category and classification views)
+- Minimum item threshold for showing chart vs a placeholder message
+- Donut chart sizing and proportions
+- Tooltip styling
+- Keyboard accessibility for classification cycling
+- Animation on chart transitions between category/classification views
+
+### Deferred Ideas (OUT OF SCOPE)
+None -- discussion stayed within phase scope
+
+</user_constraints>
+
+<phase_requirements>
+
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| CLAS-01 | User can classify each item within a setup as base weight, worn, or consumable | Classification column on `setup_items`, click-to-cycle badge component, PATCH API endpoint |
+| CLAS-02 | Setup totals display base weight, worn weight, consumable weight, and total separately | Summary card component computing subtotals from items array grouped by classification |
+| CLAS-03 | Items default to "base weight" classification when added to a setup | Schema default `"base"` on classification column, Drizzle migration with DEFAULT |
+| CLAS-04 | Same item can have different classifications in different setups | Classification on `setup_items` join table (not `items` table) -- architecture already decided |
+| VIZZ-01 | User can view a donut chart showing weight distribution by category in a setup | Recharts PieChart + Pie with innerRadius, data grouped by category |
+| VIZZ-02 | User can toggle chart between category view and classification view | Pill toggle component (reuse TotalsBar pattern), local React state for view mode |
+| VIZZ-03 | User can hover chart segments to see category name, weight, and percentage | Recharts Tooltip with custom content renderer using formatWeight() |
+
+</phase_requirements>
+
+## Standard Stack
+
+### Core
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| recharts | ^3.8.0 | Donut chart visualization | Most popular React charting library, declarative API, built on D3, 27K GitHub stars |
+
+### Supporting (already in project)
+| Library | Version | Purpose | When to Use |
+|---------|---------|---------|-------------|
+| drizzle-orm | ^0.45.1 | Schema migration for classification column | Add column to setup_items table |
+| zod | ^4.3.6 | Validation for classification enum | API input validation |
+| react | ^19.2.4 | UI components | Summary card, badge, chart wrapper |
+| tailwindcss | ^4.2.1 | Styling | Summary card layout, badge styling |
+
+### Alternatives Considered
+| Instead of | Could Use | Tradeoff |
+|------------|-----------|----------|
+| Recharts | Chart.js / react-chartjs-2 | Chart.js is imperative; Recharts is declarative React components -- better fit for this stack |
+| Recharts | Visx | Lower-level D3 wrapper; more control but more code for a simple donut chart |
+| Recharts | Tremor | Tremor wraps Recharts but adds full design system overhead -- too heavy for one chart |
+
+**Installation:**
+```bash
+bun add recharts
+```
+
+Note: Recharts has `react` and `react-dom` as peer dependencies, both already in the project. No additional peer deps needed.
+
+## Architecture Patterns
+
+### Schema Change: setup_items classification column
+
+```sql
+-- Migration: ALTER TABLE setup_items ADD classification text DEFAULT 'base' NOT NULL;
+ALTER TABLE `setup_items` ADD `classification` text DEFAULT 'base' NOT NULL;
+```
+
+The Drizzle schema change in `src/db/schema.ts`:
+```typescript
+export const setupItems = sqliteTable("setup_items", {
+  id: integer("id").primaryKey({ autoIncrement: true }),
+  setupId: integer("setup_id")
+    .notNull()
+    .references(() => setups.id, { onDelete: "cascade" }),
+  itemId: integer("item_id")
+    .notNull()
+    .references(() => items.id, { onDelete: "cascade" }),
+  classification: text("classification").notNull().default("base"),
+});
+```
+
+Values: `"base"` | `"worn"` | `"consumable"` -- stored as text, validated with Zod enum.
+
+### API Design: Classification Update
+
+A new `PATCH /api/setups/:id/items/:itemId/classification` endpoint is the cleanest approach. It avoids modifying the existing sync endpoint (which does delete-all + re-insert and would lose classifications).
+
+Alternatively, a dedicated `PATCH /api/setup-items/:setupItemId` could work, but using the composite key `(setupId, itemId)` is more consistent with the existing `DELETE /api/setups/:id/items/:itemId` pattern.
+
+**Use:** `PATCH /api/setups/:setupId/items/:itemId/classification` with body `{ classification: "worn" }`.
+
+### syncSetupItems Must Preserve Classifications
+
+The existing `syncSetupItems` function does delete-all + re-insert. After adding classification, this will reset all classifications to "base" whenever items are synced. Two approaches:
+
+**Approach A (recommended):** Before deleting, read existing classifications into a map `{ itemId -> classification }`. After re-inserting, apply the saved classifications. This keeps the atomic sync pattern intact.
+
+**Approach B:** Change sync to diff-based (add new, remove missing, keep existing). More complex, breaks the simple pattern.
+
+Use Approach A -- preserves the established pattern with minimal changes.
+
+### getSetupWithItems Must Include Classification
+
+The `getSetupWithItems` query needs to select `classification` from `setupItems`:
+
+```typescript
+const itemList = db
+  .select({
+    id: items.id,
+    name: items.name,
+    weightGrams: items.weightGrams,
+    priceCents: items.priceCents,
+    categoryId: items.categoryId,
+    // ... existing fields ...
+    categoryName: categories.name,
+    categoryIcon: categories.icon,
+    classification: setupItems.classification, // NEW
+  })
+  .from(setupItems)
+  .innerJoin(items, eq(setupItems.itemId, items.id))
+  .innerJoin(categories, eq(items.categoryId, categories.id))
+  .where(eq(setupItems.setupId, setupId))
+  .all();
+```
+
+### Component Architecture
+
+```
+src/client/
+  components/
+    ClassificationBadge.tsx     # Click-to-cycle badge (base/worn/consumable)
+    WeightSummaryCard.tsx       # Summary card: subtotals + donut chart
+  routes/
+    setups/
+      $setupId.tsx              # Modified: adds ClassificationBadge to ItemCard, adds WeightSummaryCard
+  hooks/
+    useSetups.ts                # Modified: add useUpdateItemClassification mutation, update types
+```
+
+### Pattern: ClassificationBadge (Click-to-Cycle)
+
+Follow the StatusBadge pattern but simplified -- no popup menu needed since there are only 3 values and the user cycles through them. Direct click-to-cycle is faster UX for 3 options.
+
+```typescript
+const CLASSIFICATION_ORDER = ["base", "worn", "consumable"] as const;
+type Classification = typeof CLASSIFICATION_ORDER[number];
+
+const CLASSIFICATION_CONFIG = {
+  base: { label: "Base Weight", icon: "backpack" },
+  worn: { label: "Worn", icon: "shirt" },
+  consumable: { label: "Consumable", icon: "droplets" },
+} as const;
+```
+
+Click handler cycles to next classification: `base -> worn -> consumable -> base`.
+
+### Pattern: Donut Chart with Recharts v3
+
+```typescript
+import { PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer } from "recharts";
+
+// Cell is still functional in v3 (deprecated for v4 removal)
+// This is the standard pattern for v3.x
+<ResponsiveContainer width="100%" height={200}>
+  <PieChart>
+    <Pie
+      data={chartData}
+      dataKey="weight"
+      nameKey="name"
+      cx="50%"
+      cy="50%"
+      innerRadius={55}
+      outerRadius={80}
+      paddingAngle={2}
+    >
+      {chartData.map((entry, index) => (
+        <Cell key={entry.name} fill={COLORS[index % COLORS.length]} />
+      ))}
+      <Label
+        value={formatWeight(totalWeight, unit)}
+        position="center"
+        className="text-lg font-semibold"
+      />
+    </Pie>
+    <Tooltip content={<CustomTooltip unit={unit} />} />
+  </PieChart>
+</ResponsiveContainer>
+```
+
+### Pattern: Custom Tooltip
+
+```typescript
+function CustomTooltip({ active, payload, unit }: any) {
+  if (!active || !payload?.length) return null;
+  const { name, weight, percent } = payload[0].payload;
+  return (
+    <div className="bg-white border border-gray-200 rounded-lg shadow-lg px-3 py-2 text-sm">
+      <p className="font-medium text-gray-900">{name}</p>
+      <p className="text-gray-600">
+        {formatWeight(weight, unit)} ({(percent * 100).toFixed(1)}%)
+      </p>
+    </div>
+  );
+}
+```
+
+### Pattern: Data Transformation for Chart
+
+```typescript
+// Category view: group items by category, sum weights
+function buildCategoryChartData(items: SetupItemWithCategory[]) {
+  const groups = new Map<string, number>();
+  for (const item of items) {
+    const current = groups.get(item.categoryName) ?? 0;
+    groups.set(item.categoryName, current + (item.weightGrams ?? 0));
+  }
+  const total = items.reduce((sum, i) => sum + (i.weightGrams ?? 0), 0);
+  return Array.from(groups.entries())
+    .filter(([_, weight]) => weight > 0)
+    .map(([name, weight]) => ({ name, weight, percent: total > 0 ? weight / total : 0 }));
+}
+
+// Classification view: group by classification, sum weights
+function buildClassificationChartData(items: SetupItemWithClassification[]) {
+  const groups = { base: 0, worn: 0, consumable: 0 };
+  for (const item of items) {
+    groups[item.classification] += item.weightGrams ?? 0;
+  }
+  const total = Object.values(groups).reduce((a, b) => a + b, 0);
+  return Object.entries(groups)
+    .filter(([_, weight]) => weight > 0)
+    .map(([key, weight]) => ({
+      name: CLASSIFICATION_CONFIG[key as Classification].label,
+      weight,
+      percent: total > 0 ? weight / total : 0,
+    }));
+}
+```
+
+### Pattern: Pill Toggle (View Mode Switcher)
+
+Reuse the exact pattern from TotalsBar's weight unit toggle:
+
+```typescript
+const VIEW_MODES = ["category", "classification"] as const;
+type ViewMode = typeof VIEW_MODES[number];
+
+const [viewMode, setViewMode] = useState<ViewMode>("category");
+
+// Rendered as:
+<div className="flex items-center gap-1 bg-gray-100 rounded-full px-1 py-0.5">
+  {VIEW_MODES.map((mode) => (
+    <button
+      key={mode}
+      onClick={() => setViewMode(mode)}
+      className={`px-2.5 py-0.5 text-xs rounded-full transition-colors capitalize ${
+        viewMode === mode
+          ? "bg-white text-gray-700 shadow-sm font-medium"
+          : "text-gray-400 hover:text-gray-600"
+      }`}
+    >
+      {mode === "category" ? "Category" : "Classification"}
+    </button>
+  ))}
+</div>
+```
+
+### Anti-Patterns to Avoid
+- **Modifying syncSetupItems to accept classifications in the itemIds array:** This couples the sync endpoint to classification data. Keep them separate -- sync manages membership, classification update manages role.
+- **Computing classification subtotals on the server:** The setup detail page already computes totals client-side from the items array. Keep classification subtotals client-side too for consistency.
+- **Using a separate table for classifications:** Overkill. A single column on `setup_items` is the right level of complexity.
+- **Using Recharts v4 patterns (RechartsSymbols.fill):** v4 is not released. Stick with `Cell` component which works in v3.x.
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Donut chart rendering | Custom SVG arc calculations | Recharts `PieChart` + `Pie` | Arc math, hit detection, animation, accessibility -- all handled |
+| Chart tooltips | Custom hover position tracking | Recharts `Tooltip` with `content` prop | Viewport boundary detection, positioning, hover state management |
+| Responsive chart sizing | Manual resize observers | Recharts `ResponsiveContainer` | Handles debounced resize, prevents layout thrashing |
+| Weight unit formatting | Inline conversion in chart | Existing `formatWeight()` utility | Already handles all units with correct decimal places |
+
+**Key insight:** Recharts handles all the hard SVG/D3 work. The implementation should focus on data transformation (grouping items into chart segments) and styling (Tailwind classes on the summary card and tooltip).
+
+## Common Pitfalls
+
+### Pitfall 1: syncSetupItems Destroys Classifications
+**What goes wrong:** The existing sync function deletes all setup_items then re-inserts. After adding classification, every sync resets all items to "base".
+**Why it happens:** Delete-all + re-insert pattern was designed before classification existed.
+**How to avoid:** Save classifications before delete, restore after re-insert (Approach A above).
+**Warning signs:** Items losing their classification after adding/removing any item from the setup.
+
+### Pitfall 2: ResponsiveContainer Needs a Defined Parent Height
+**What goes wrong:** Recharts `ResponsiveContainer` with `height="100%"` renders at 0px if the parent container has no explicit height.
+**Why it happens:** CSS percentage heights require the parent to have a defined height.
+**How to avoid:** Use a fixed numeric height on `ResponsiveContainer` (e.g., `height={200}`) or ensure the parent div has an explicit height (e.g., `h-[200px]`).
+**Warning signs:** Chart not visible, 0-height container.
+
+### Pitfall 3: Chart Data with Zero-Weight Items
+**What goes wrong:** Items with `null` or `0` weight produce zero-size or NaN chart segments.
+**Why it happens:** Recharts renders slices proportional to `dataKey` values. Zero values create invisible or problematic slices.
+**How to avoid:** Filter out zero-weight entries before passing data to the chart. Show a "no weight data" placeholder if all items have null weight.
+**Warning signs:** Console warnings about NaN, invisible chart segments, misaligned tooltips.
+
+### Pitfall 4: Test Helper Must Match Schema
+**What goes wrong:** Tests fail because the in-memory DB schema in `tests/helpers/db.ts` doesn't include the new `classification` column.
+**Why it happens:** The test helper has hand-written CREATE TABLE statements that must be manually kept in sync with `src/db/schema.ts`.
+**How to avoid:** Update the test helper's `setup_items` CREATE TABLE to include `classification text NOT NULL DEFAULT 'base'` alongside updating the Drizzle schema.
+**Warning signs:** Tests failing with "no such column: classification" errors.
+
+### Pitfall 5: Classification Badge Click Propagates to ItemCard
+**What goes wrong:** Clicking the classification badge opens the item edit panel instead of cycling classification.
+**Why it happens:** ItemCard is a `<button>` element. Click events bubble up from the badge to the card.
+**How to avoid:** Call `e.stopPropagation()` on the classification badge click handler. This is the same pattern used by the remove button and product URL link on ItemCard.
+**Warning signs:** Edit panel opening when user tries to change classification.
+
+## Code Examples
+
+### Zod Schema for Classification
+
+```typescript
+// In src/shared/schemas.ts
+export const classificationSchema = z.enum(["base", "worn", "consumable"]);
+
+export const updateClassificationSchema = z.object({
+  classification: classificationSchema,
+});
+```
+
+### Service: Update Item Classification
+
+```typescript
+// In src/server/services/setup.service.ts
+export function updateItemClassification(
+  db: Db = prodDb,
+  setupId: number,
+  itemId: number,
+  classification: string,
+) {
+  return db
+    .update(setupItems)
+    .set({ classification })
+    .where(
+      sql`${setupItems.setupId} = ${setupId} AND ${setupItems.itemId} = ${itemId}`,
+    )
+    .run();
+}
+```
+
+### Service: syncSetupItems with Classification Preservation
+
+```typescript
+export function syncSetupItems(
+  db: Db = prodDb,
+  setupId: number,
+  itemIds: number[],
+) {
+  return db.transaction((tx) => {
+    // Save existing classifications before delete
+    const existing = tx
+      .select({
+        itemId: setupItems.itemId,
+        classification: setupItems.classification,
+      })
+      .from(setupItems)
+      .where(eq(setupItems.setupId, setupId))
+      .all();
+
+    const classificationMap = new Map(
+      existing.map((e) => [e.itemId, e.classification]),
+    );
+
+    // Delete all existing items for this setup
+    tx.delete(setupItems).where(eq(setupItems.setupId, setupId)).run();
+
+    // Re-insert with preserved classifications
+    for (const itemId of itemIds) {
+      tx.insert(setupItems)
+        .values({
+          setupId,
+          itemId,
+          classification: classificationMap.get(itemId) ?? "base",
+        })
+        .run();
+    }
+  });
+}
+```
+
+### Hook: useUpdateItemClassification
+
+```typescript
+// In src/client/hooks/useSetups.ts
+export function useUpdateItemClassification(setupId: number) {
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: ({ itemId, classification }: { itemId: number; classification: string }) =>
+      apiPut<{ success: boolean }>(
+        `/api/setups/${setupId}/items/${itemId}/classification`,
+        { classification },
+      ),
+    onSuccess: () => {
+      queryClient.invalidateQueries({ queryKey: ["setups", setupId] });
+    },
+  });
+}
+```
+
+### Color Palette for Chart Segments
+
+```typescript
+// Category colors: distinguishable palette for up to 10 categories
+const CATEGORY_COLORS = [
+  "#6366f1", // indigo
+  "#f59e0b", // amber
+  "#10b981", // emerald
+  "#ef4444", // red
+  "#8b5cf6", // violet
+  "#06b6d4", // cyan
+  "#f97316", // orange
+  "#ec4899", // pink
+  "#14b8a6", // teal
+  "#84cc16", // lime
+];
+
+// Classification colors: 3 distinct colors matching the semantic meaning
+const CLASSIFICATION_COLORS = {
+  base: "#6366f1",       // indigo -- "foundation" feel
+  worn: "#f59e0b",       // amber -- "on your body" warmth
+  consumable: "#10b981", // emerald -- "used up" organic feel
+};
+```
+
+## State of the Art
+
+| Old Approach | Current Approach | When Changed | Impact |
+|--------------|------------------|--------------|--------|
+| Recharts `Cell` for per-slice colors | Still `Cell` in v3.x (deprecated for v4) | v3.0 deprecated, v4 removes | Use `Cell` now; plan to migrate to data-mapped colors when v4 drops |
+| Recharts v2 state management | Recharts v3 rewritten state | v3.0 (2024) | Better performance, fewer rendering bugs |
+| `activeShape` prop on Pie | `shape` prop with `isActive` callback | v3.0 | Use `shape` for custom active sectors if needed |
+
+**Deprecated/outdated:**
+- `Cell` component: Deprecated in v3, removed in v4. Still functional now. When v4 releases, migrate to `RechartsSymbols.fill` in data objects or `fillKey` prop.
+- `activeShape` / `inactiveShape` props on Pie: Deprecated in v3 in favor of unified `shape` prop.
+
+## Open Questions
+
+1. **Recharts bundle size impact**
+   - What we know: Recharts depends on D3 modules, adding ~50-80KB gzipped to the bundle
+   - What's unclear: Exact tree-shaking behavior with Vite and specific imports
+   - Recommendation: Import only needed components (`import { PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer } from "recharts"`) -- Vite will tree-shake unused parts
+
+2. **Chart animation performance**
+   - What we know: Recharts animations are CSS-based and generally smooth
+   - What's unclear: Whether toggling between category/classification views should animate the transition
+   - Recommendation: Enable default animation on initial render. For view toggles, let Recharts handle the re-render naturally (it will animate by default). If janky, set `isAnimationActive={false}`.
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test runner (built-in) |
+| Config file | None -- Bun test requires no config |
+| Quick run command | `bun test tests/services/setup.service.test.ts` |
+| Full suite command | `bun test` |
+
+### Phase Requirements -> Test Map
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| CLAS-01 | Update item classification in setup | unit | `bun test tests/services/setup.service.test.ts -t "updateItemClassification"` | Needs new tests |
+| CLAS-02 | Get setup with classification subtotals | unit | `bun test tests/services/setup.service.test.ts -t "classification"` | Needs new tests |
+| CLAS-03 | Default classification is "base" | unit | `bun test tests/services/setup.service.test.ts -t "default"` | Needs new tests |
+| CLAS-04 | Different classifications in different setups | unit | `bun test tests/services/setup.service.test.ts -t "different setups"` | Needs new tests |
+| VIZZ-01 | Donut chart renders with category data | manual-only | N/A -- visual rendering | N/A |
+| VIZZ-02 | Toggle switches chart data source | manual-only | N/A -- UI interaction | N/A |
+| VIZZ-03 | Hover tooltip shows name/weight/percentage | manual-only | N/A -- hover behavior | N/A |
+| CLAS-01 | Classification PATCH route | integration | `bun test tests/routes/setups.test.ts -t "classification"` | Needs new tests |
+| CLAS-03 | syncSetupItems preserves classification | unit | `bun test tests/services/setup.service.test.ts -t "preserves classification"` | Needs new tests |
+
+### Sampling Rate
+- **Per task commit:** `bun test tests/services/setup.service.test.ts && bun test tests/routes/setups.test.ts`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+- [ ] `tests/services/setup.service.test.ts` -- add tests for `updateItemClassification`, classification preservation in `syncSetupItems`, classification defaults, and different-setup classification
+- [ ] `tests/routes/setups.test.ts` -- add test for `PATCH /:id/items/:itemId/classification` route
+- [ ] `tests/helpers/db.ts` -- update `setup_items` CREATE TABLE to include `classification text NOT NULL DEFAULT 'base'`
+
+## Sources
+
+### Primary (HIGH confidence)
+- [Recharts API docs - Pie](https://recharts.github.io/en-US/api/Pie) - innerRadius, outerRadius, dataKey, Cell usage
+- [Recharts API docs - Tooltip](https://recharts.github.io/en-US/api/Tooltip/) - custom content, formatter, active/payload
+- [Recharts API docs - Cell (deprecation notice)](https://recharts.github.io/en-US/api/Cell/) - deprecated in v3, removed in v4
+- [Recharts npm](https://www.npmjs.com/package/recharts) - v3.8.0 latest, MIT license
+- Existing codebase: `src/db/schema.ts`, `src/server/services/setup.service.ts`, `src/client/components/StatusBadge.tsx`, `src/client/components/TotalsBar.tsx`
+
+### Secondary (MEDIUM confidence)
+- [Recharts Cell Discussion #5474](https://github.com/recharts/recharts/discussions/5474) - Cell replacement patterns
+- [GeeksforGeeks Donut Chart Tutorial](https://www.geeksforgeeks.org/reactjs/create-a-donut-chart-using-recharts-in-reactjs/) - donut chart pattern
+- [Recharts Label in center of PieChart #191](https://github.com/recharts/recharts/issues/191) - center label patterns
+- [Recharts 3.0 Migration Guide](https://github.com/recharts/recharts/wiki/3.0-migration-guide) - v3 breaking changes
+
+### Tertiary (LOW confidence)
+- None
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH - Recharts is the user's locked decision, v3.8.0 is current, API is well-documented
+- Architecture: HIGH - Classification column pattern mirrors the Phase 8 status column migration exactly; all code patterns verified against existing codebase
+- Pitfalls: HIGH - syncSetupItems preservation is the main risk; verified by reading the actual delete-all + re-insert code; other pitfalls are standard React/Recharts issues
+
+**Research date:** 2026-03-16
+**Valid until:** 2026-04-16 (Recharts v3 is stable; v4 with Cell removal is not imminent)

.planning/phases/09-weight-classification-and-visualization/09-VALIDATION.md

@@ -0,0 +1,82 @@
+---
+phase: 9
+slug: weight-classification-and-visualization
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-16
+---
+
+# Phase 9 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Bun test runner |
+| **Config file** | none — existing infrastructure |
+| **Quick run command** | `bun test` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 09-01-01 | 01 | 1 | CLAS-01, CLAS-04 | unit | `bun test tests/services/setup.service.test.ts` | ❌ W0 | ⬜ pending |
+| 09-01-02 | 01 | 1 | CLAS-03 | unit | `bun test tests/services/setup.service.test.ts` | ❌ W0 | ⬜ pending |
+| 09-01-03 | 01 | 1 | CLAS-01 | route | `bun test tests/routes/setups.test.ts` | ❌ W0 | ⬜ pending |
+| 09-02-01 | 02 | 2 | CLAS-02 | unit | `bun test tests/services/setup.service.test.ts` | ❌ W0 | ⬜ pending |
+| 09-02-02 | 02 | 2 | VIZZ-01, VIZZ-02, VIZZ-03 | manual | N/A — visual component | N/A | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] `tests/services/setup.service.test.ts` — classification CRUD tests (service layer)
+- [ ] `tests/routes/setups.test.ts` — classification API endpoint tests
+- [ ] `tests/helpers/db.ts` — update CREATE TABLE for setup_items to include classification column
+
+*Existing test infrastructure covers framework setup. Wave 0 adds phase-specific test files.*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Classification badge click-to-cycle | CLAS-01 | UI interaction, React component | Click badge on item card in setup, verify it cycles base→worn→consumable→base |
+| Summary card weight subtotals | CLAS-02 | Visual layout verification | Add items to setup, classify some as worn/consumable, verify subtotals update |
+| Donut chart renders with segments | VIZZ-01 | Recharts canvas/SVG rendering | Open setup with items, verify donut chart shows colored segments |
+| Chart toggle category/classification | VIZZ-02 | UI interaction | Click pill toggle, verify chart segments change between category and classification views |
+| Chart hover tooltips | VIZZ-03 | Hover interaction | Hover over donut segments, verify tooltip shows name, weight, percentage |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/09-weight-classification-and-visualization/09-VERIFICATION.md

@@ -0,0 +1,158 @@
+---
+phase: 09-weight-classification-and-visualization
+verified: 2026-03-16T15:00:00Z
+status: passed
+score: 9/9 must-haves verified
+re_verification: false
+---
+
+# Phase 9: Weight Classification and Visualization Verification Report
+
+**Phase Goal:** Users can classify gear by role and visualize weight distribution in setups
+**Verified:** 2026-03-16T15:00:00Z
+**Status:** passed
+**Re-verification:** No — initial verification
+
+---
+
+## Goal Achievement
+
+### Observable Truths
+
+| #  | Truth                                                                                                               | Status     | Evidence                                                                                       |
+|----|---------------------------------------------------------------------------------------------------------------------|------------|-----------------------------------------------------------------------------------------------|
+| 1  | User can click a classification badge on any item card within a setup and it cycles through base weight, worn, consumable | VERIFIED | ClassificationBadge renders in $setupId.tsx per item; nextClassification cycles the three values; useUpdateItemClassification mutation fires PATCH call |
+| 2  | Items default to base weight classification when added to a setup                                                   | VERIFIED   | schema.ts: `classification text NOT NULL DEFAULT 'base'`; syncSetupItems uses `classificationMap.get(itemId) ?? "base"` |
+| 3  | Same item in different setups can have different classifications                                                     | VERIFIED   | Classification stored on setupItems join table (not items); test confirmed in setup.service.test.ts |
+| 4  | Classifications persist after adding/removing other items from the setup (syncSetupItems preserves them)            | VERIFIED   | syncSetupItems reads Map<itemId, classification> before delete, restores after re-insert; 2 tests confirm |
+| 5  | Setup detail view shows separate weight subtotals for base weight, worn weight, consumable weight, and total        | VERIFIED   | WeightSummaryCard computes baseWeight/wornWeight/consumableWeight/totalWeight and renders 4 SubtotalColumn components |
+| 6  | User can view a donut chart showing weight distribution by category in the setup                                    | VERIFIED   | WeightSummaryCard uses Recharts PieChart+Pie with innerRadius=55/outerRadius=80; default viewMode="category" |
+| 7  | User can toggle the chart between category breakdown and classification breakdown via pill toggle                   | VERIFIED   | Pill toggle button array maps over VIEW_MODES ["category","classification"]; state switches chartData source |
+| 8  | Hovering a chart segment shows category/classification name, weight in selected unit, and percentage                | VERIFIED   | CustomTooltip renders name, formatWeight(weight, unit), (percent*100).toFixed(1)% |
+| 9  | Total weight displayed in the center of the donut hole                                                              | VERIFIED   | `<Label value={formatWeight(totalWeight, unit)} position="center" .../>` inside Pie |
+
+**Score:** 9/9 truths verified
+
+---
+
+### Required Artifacts
+
+#### Plan 01 Artifacts
+
+| Artifact | Expected | Status | Details |
+|---|---|---|---|
+| `src/db/schema.ts` | classification column on setupItems table | VERIFIED | `classification: text("classification").notNull().default("base")` at line 89 |
+| `src/shared/schemas.ts` | classificationSchema Zod enum and updateClassificationSchema | VERIFIED | Both exported at lines 78-82 |
+| `src/server/services/setup.service.ts` | updateItemClassification, classification-preserving syncSetupItems, classification field in getSetupWithItems | VERIFIED | All three implemented; syncSetupItems uses Map pattern; getSetupWithItems selects `classification: setupItems.classification` |
+| `src/server/routes/setups.ts` | PATCH /:id/items/:itemId/classification endpoint | VERIFIED | app.patch("/:id/items/:itemId/classification", ...) at line 78 with Zod validation and service call |
+| `src/client/components/ClassificationBadge.tsx` | Click-to-cycle classification badge component (min 30 lines) | VERIFIED | 30 lines; button with stopPropagation + onCycle; CLASSIFICATION_LABELS map |
+| `src/client/routes/setups/$setupId.tsx` | ClassificationBadge wired into item cards in setup view | VERIFIED | Imported and rendered per item inside `{categoryItems.map(...)}` with nextClassification helper |
+| `tests/services/setup.service.test.ts` | Tests for updateItemClassification, classification preservation, defaults | VERIFIED | 5 new tests: default "base", preservation on sync, new items default, cross-setup independence, classification update |
+| `tests/routes/setups.test.ts` | Integration test for PATCH classification route | VERIFIED | 2 new tests: valid PATCH updates+persists, invalid value returns 400 |
+
+#### Plan 02 Artifacts
+
+| Artifact | Expected | Status | Details |
+|---|---|---|---|
+| `src/client/components/WeightSummaryCard.tsx` | Summary card with weight subtotals, donut chart, pill toggle, and tooltips (min 100 lines) | VERIFIED | 265 lines; all four features present |
+| `src/client/routes/setups/$setupId.tsx` | WeightSummaryCard rendered below sticky bar when setup has items | VERIFIED | `<WeightSummaryCard items={setup.items} />` inside `{itemCount > 0 && (...)}` block at line 196 |
+| `package.json` | recharts dependency installed | VERIFIED | `"recharts": "^3.8.0"` at line 43 |
+
+---
+
+### Key Link Verification
+
+#### Plan 01 Key Links
+
+| From | To | Via | Status | Details |
+|---|---|---|---|---|
+| `ClassificationBadge.tsx` | `/api/setups/:id/items/:itemId/classification` | useUpdateItemClassification mutation hook (apiPatch) | VERIFIED | useSetups.ts exports useUpdateItemClassification which calls `apiPatch(.../classification, ...)`; $setupId.tsx imports and calls it |
+| `src/server/routes/setups.ts` | `src/server/services/setup.service.ts` | updateItemClassification service call | VERIFIED | Routes imports updateItemClassification from service; calls it in PATCH handler |
+| `src/server/services/setup.service.ts` | `src/db/schema.ts` | setupItems.classification column | VERIFIED | service.ts uses `setupItems.classification` in select (line 56) and `set({ classification })` in update (line 143) |
+| `src/client/routes/setups/$setupId.tsx` | `src/client/components/ClassificationBadge.tsx` | ClassificationBadge rendered on each ItemCard | VERIFIED | Imported at line 4; rendered inside item map at lines 235-245 |
+
+#### Plan 02 Key Links
+
+| From | To | Via | Status | Details |
+|---|---|---|---|---|
+| `WeightSummaryCard.tsx` | recharts | PieChart, Pie, Cell, Tooltip, Label, ResponsiveContainer imports | VERIFIED | All six named imports from "recharts" at lines 2-9 |
+| `WeightSummaryCard.tsx` | `src/client/lib/formatters.ts` | formatWeight for subtotals and tooltip display | VERIFIED | `formatWeight` imported at line 12; used in SubtotalColumn, CustomTooltip, and center Label |
+| `src/client/routes/setups/$setupId.tsx` | `WeightSummaryCard.tsx` | WeightSummaryCard rendered with setup.items prop | VERIFIED | Imported at line 7; rendered as `<WeightSummaryCard items={setup.items} />` at line 196 |
+
+---
+
+### Requirements Coverage
+
+| Requirement | Source Plan | Description | Status | Evidence |
+|---|---|---|---|---|
+| CLAS-01 | 09-01 | User can classify each item within a setup as base weight, worn, or consumable | SATISFIED | ClassificationBadge + PATCH endpoint + updateItemClassification service all wired and tested |
+| CLAS-02 | 09-02 | Setup totals display base weight, worn weight, consumable weight, and total separately | SATISFIED | WeightSummaryCard renders 4 SubtotalColumn components with computed weights |
+| CLAS-03 | 09-01 | Items default to "base weight" classification when added to a setup | SATISFIED | DB default "base" + syncSetupItems fallback + test confirms default |
+| CLAS-04 | 09-01 | Same item can have different classifications in different setups | SATISFIED | Classification on join table; cross-setup test passes |
+| VIZZ-01 | 09-02 | User can view a donut chart showing weight distribution by category in a setup | SATISFIED | Recharts PieChart with buildCategoryChartData, default viewMode="category" |
+| VIZZ-02 | 09-02 | User can toggle chart between category view and classification view | SATISFIED | Pill toggle with VIEW_MODES array, setViewMode state updates chartData source |
+| VIZZ-03 | 09-02 | User can hover chart segments to see category name, weight, and percentage | SATISFIED | CustomTooltip renders all three fields; passed to PieChart as `content` prop |
+
+No orphaned requirements — all 7 IDs declared in plan frontmatter and accounted for.
+
+---
+
+### Anti-Patterns Found
+
+No blockers or warnings found in modified files. The only `return null` instance is a standard React guard clause in CustomTooltip (not a stub).
+
+---
+
+### Human Verification Required
+
+The following items cannot be verified programmatically and require a running browser session:
+
+#### 1. Click-to-cycle badge interaction and stopPropagation
+
+**Test:** Open a setup with items. Click a classification badge on one item card.
+**Expected:** Badge label cycles Base Weight -> Worn -> Consumable -> Base Weight. The item edit panel does NOT open when clicking the badge.
+**Why human:** stopPropagation correctness and visual badge state update require browser execution.
+
+#### 2. Donut chart renders with correct segment proportions
+
+**Test:** Add items with different categories and weights to a setup. View the setup detail page.
+**Expected:** Donut chart segments are proportional to weight distribution. Total weight appears in the center hole.
+**Why human:** Chart rendering requires browser + Recharts layout.
+
+#### 3. Pill toggle switches chart data
+
+**Test:** Click the "Classification" pill on the WeightSummaryCard.
+**Expected:** Chart segments change from category-based colors to indigo/amber/emerald for base/worn/consumable. Tooltips show "Base Weight", "Worn", or "Consumable" labels.
+**Why human:** Visual and interactive behavior requires browser.
+
+#### 4. Tooltip on hover
+
+**Test:** Hover over a chart segment.
+**Expected:** Tooltip appears with segment name, formatted weight in the selected unit, and percentage.
+**Why human:** Hover state requires browser interaction.
+
+#### 5. Weight unit propagation
+
+**Test:** Toggle the weight unit in the top bar (g / oz / lb / kg). Observe WeightSummaryCard.
+**Expected:** All four subtotal columns and the donut center label update to the selected unit.
+**Why human:** useWeightUnit hook behavior and re-render requires browser.
+
+---
+
+### Test Suite Results
+
+All 121 tests pass across 10 files (32 setup-specific tests across services and routes).
+
+- `tests/services/setup.service.test.ts` — 5 new classification tests pass (default "base", preservation, new item default, cross-setup independence, update from base to worn)
+- `tests/routes/setups.test.ts` — 2 new PATCH classification tests pass (valid update + 400 for invalid value)
+
+---
+
+### Summary
+
+Phase 9 goal is fully achieved. All 9 observable truths are verified against the actual codebase — no stubs, no orphaned artifacts, no broken links. The complete vertical slice from DB schema to UI component is wired and exercised by 7 automated tests. Human verification is needed only for visual/interactive browser behaviors (chart rendering, hover tooltips, click cycling), which are structurally sound in the code.
+
+---
+
+_Verified: 2026-03-16T15:00:00Z_
+_Verifier: Claude (gsd-verifier)_

.planning/phases/10-schema-foundation-pros-cons-fields/10-01-PLAN.md

@@ -0,0 +1,302 @@
+---
+phase: 10-schema-foundation-pros-cons-fields
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/db/schema.ts
+  - tests/helpers/db.ts
+  - src/server/services/thread.service.ts
+  - src/shared/schemas.ts
+  - src/client/hooks/useCandidates.ts
+  - src/client/components/CandidateForm.tsx
+  - src/client/components/CandidateCard.tsx
+  - src/client/routes/threads/$threadId.tsx
+  - tests/services/thread.service.test.ts
+autonomous: true
+requirements: [RANK-03]
+
+must_haves:
+  truths:
+    - "User can open a candidate edit form and see pros and cons text fields"
+    - "User can save pros and cons text; the text persists across page refreshes"
+    - "CandidateCard shows a visual indicator when a candidate has pros or cons entered"
+    - "All existing tests pass after the schema migration (no column drift in test helper)"
+  artifacts:
+    - path: "src/db/schema.ts"
+      provides: "pros and cons nullable TEXT columns on threadCandidates"
+      contains: "pros: text"
+    - path: "tests/helpers/db.ts"
+      provides: "Mirrored pros/cons columns in test DB CREATE TABLE"
+      contains: "pros TEXT"
+    - path: "src/server/services/thread.service.ts"
+      provides: "pros/cons in createCandidate, updateCandidate, getThreadWithCandidates"
+      contains: "pros:"
+    - path: "src/shared/schemas.ts"
+      provides: "pros and cons optional string fields in createCandidateSchema"
+      contains: "pros: z.string"
+    - path: "src/client/components/CandidateForm.tsx"
+      provides: "Pros and Cons textarea inputs in candidate form"
+      contains: "candidate-pros"
+    - path: "src/client/components/CandidateCard.tsx"
+      provides: "Visual indicator badge when pros or cons are present"
+      contains: "pros || cons"
+    - path: "tests/services/thread.service.test.ts"
+      provides: "Tests for pros/cons in create, update, and get operations"
+      contains: "pros"
+  key_links:
+    - from: "src/db/schema.ts"
+      to: "tests/helpers/db.ts"
+      via: "Manual column mirroring in CREATE TABLE"
+      pattern: "pros TEXT"
+    - from: "src/shared/schemas.ts"
+      to: "src/server/services/thread.service.ts"
+      via: "Zod-inferred CreateCandidate type used in service"
+      pattern: "CreateCandidate"
+    - from: "src/server/services/thread.service.ts"
+      to: "src/client/hooks/useCandidates.ts"
+      via: "API JSON response includes pros/cons fields"
+      pattern: "pros.*string.*null"
+    - from: "src/client/hooks/useCandidates.ts"
+      to: "src/client/components/CandidateForm.tsx"
+      via: "CandidateResponse type drives form pre-fill"
+      pattern: "candidate\\.pros"
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/components/CandidateCard.tsx"
+      via: "Props threaded from candidate data to card"
+      pattern: "pros=.*candidate\\.pros"
+---
+
+<objective>
+Add pros and cons annotation fields to thread candidates, from database through UI.
+
+Purpose: RANK-03 requires users to add pros/cons text per candidate for decision-making. This plan follows the established field-addition ladder: schema -> migration -> test helper -> service -> Zod -> types -> hook -> form -> card indicator.
+
+Output: Two new nullable TEXT columns (pros, cons) on thread_candidates, fully wired through all layers, with service-level tests and a visual indicator on CandidateCard.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/10-schema-foundation-pros-cons-fields/10-RESEARCH.md
+
+<interfaces>
+<!-- Current codebase contracts the executor needs. -->
+
+From src/db/schema.ts (threadCandidates table -- add pros/cons after status):
+```typescript
+export const threadCandidates = sqliteTable("thread_candidates", {
+  id: integer("id").primaryKey({ autoIncrement: true }),
+  threadId: integer("thread_id").notNull().references(() => threads.id, { onDelete: "cascade" }),
+  name: text("name").notNull(),
+  weightGrams: real("weight_grams"),
+  priceCents: integer("price_cents"),
+  categoryId: integer("category_id").notNull().references(() => categories.id),
+  notes: text("notes"),
+  productUrl: text("product_url"),
+  imageFilename: text("image_filename"),
+  status: text("status").notNull().default("researching"),
+  // ADD: pros: text("pros"),
+  // ADD: cons: text("cons"),
+  createdAt: integer("created_at", { mode: "timestamp" }).notNull().$defaultFn(() => new Date()),
+  updatedAt: integer("updated_at", { mode: "timestamp" }).notNull().$defaultFn(() => new Date()),
+});
+```
+
+From src/shared/schemas.ts (createCandidateSchema -- add optional pros/cons):
+```typescript
+export const createCandidateSchema = z.object({
+  name: z.string().min(1, "Name is required"),
+  weightGrams: z.number().nonnegative().optional(),
+  priceCents: z.number().int().nonnegative().optional(),
+  categoryId: z.number().int().positive(),
+  notes: z.string().optional(),
+  productUrl: z.string().url().optional().or(z.literal("")),
+  imageFilename: z.string().optional(),
+  status: candidateStatusSchema.optional(),
+});
+// updateCandidateSchema = createCandidateSchema.partial() -- inherits automatically
+```
+
+From src/server/services/thread.service.ts:
+```typescript
+// createCandidate: values() object needs pros/cons
+// updateCandidate: inline Partial<{...}> type needs pros/cons
+// getThreadWithCandidates: explicit .select({}) projection needs pros/cons
+```
+
+From src/client/hooks/useCandidates.ts:
+```typescript
+interface CandidateResponse {
+  id: number; threadId: number; name: string;
+  weightGrams: number | null; priceCents: number | null;
+  categoryId: number; notes: string | null;
+  productUrl: string | null; imageFilename: string | null;
+  status: "researching" | "ordered" | "arrived";
+  createdAt: string; updatedAt: string;
+  // ADD: pros: string | null;
+  // ADD: cons: string | null;
+}
+```
+
+From src/client/components/CandidateCard.tsx:
+```typescript
+interface CandidateCardProps {
+  id: number; name: string; weightGrams: number | null;
+  priceCents: number | null; categoryName: string;
+  categoryIcon: string; imageFilename: string | null;
+  productUrl?: string | null; threadId: number;
+  isActive: boolean;
+  status: "researching" | "ordered" | "arrived";
+  onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+  // ADD: pros?: string | null;
+  // ADD: cons?: string | null;
+}
+```
+
+From src/client/components/CandidateForm.tsx:
+```typescript
+interface FormData {
+  name: string; weightGrams: string; priceDollars: string;
+  categoryId: number; notes: string; productUrl: string;
+  imageFilename: string | null;
+  // ADD: pros: string;
+  // ADD: cons: string;
+}
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: Add pros/cons columns through backend + tests</name>
+  <files>src/db/schema.ts, tests/helpers/db.ts, src/server/services/thread.service.ts, src/shared/schemas.ts, tests/services/thread.service.test.ts</files>
+  <behavior>
+    - createCandidate with pros/cons returns them in the response
+    - createCandidate without pros/cons returns null for both fields
+    - updateCandidate can set pros and cons on an existing candidate
+    - updateCandidate can clear pros/cons by setting to empty string (becomes null via service)
+    - getThreadWithCandidates includes pros and cons on each candidate object
+    - All existing thread service tests still pass (no column drift)
+  </behavior>
+  <action>
+    1. **Schema** (`src/db/schema.ts`): Add two nullable TEXT columns to `threadCandidates` after `status`:
+       ```typescript
+       pros: text("pros"),
+       cons: text("cons"),
+       ```
+
+    2. **Migration**: Run `bun run db:generate` to produce the ALTER TABLE migration, then `bun run db:push` to apply.
+
+    3. **Test helper** (`tests/helpers/db.ts`): Add `pros TEXT,` and `cons TEXT,` to the `CREATE TABLE thread_candidates` statement, between the `status` line and the `created_at` line. This is CRITICAL -- without it, in-memory test DBs will silently lack the columns.
+
+    4. **Service** (`src/server/services/thread.service.ts`):
+       - `createCandidate`: Add `pros: data.pros ?? null,` and `cons: data.cons ?? null,` to the `.values({})` object.
+       - `updateCandidate`: Add `pros: string;` and `cons: string;` to the inline `Partial<{...}>` type parameter.
+       - `getThreadWithCandidates`: Add `pros: threadCandidates.pros,` and `cons: threadCandidates.cons,` to the explicit `.select({})` projection, before the `categoryName` line.
+
+    5. **Zod schemas** (`src/shared/schemas.ts`): Add to `createCandidateSchema`:
+       ```typescript
+       pros: z.string().optional(),
+       cons: z.string().optional(),
+       ```
+       `updateCandidateSchema` inherits via `.partial()` -- no changes needed there.
+
+    6. **Tests** (`tests/services/thread.service.test.ts`): Add three test cases:
+       - In `describe("createCandidate")`: "stores and returns pros and cons" -- create a candidate with `pros: "Lightweight\nGood reviews"` and `cons: "Expensive"`, assert both fields are returned correctly.
+       - In `describe("updateCandidate")`: "can set and clear pros and cons" -- create a candidate, update with pros/cons values, assert they are set, then update with empty strings, assert they are cleared (returned as empty string or null from DB).
+       - In `describe("getThreadWithCandidates")`: "includes pros and cons on each candidate" -- create a candidate with pros/cons, fetch via getThreadWithCandidates, assert `candidate.pros` and `candidate.cons` match.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test tests/services/thread.service.test.ts</automated>
+  </verify>
+  <done>
+    - pros and cons columns exist in schema.ts and test helper
+    - Drizzle migration generated and applied
+    - createCandidate, updateCandidate, getThreadWithCandidates all handle pros/cons
+    - Zod schemas accept optional pros/cons strings
+    - All existing + new thread service tests pass
+  </done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Wire pros/cons through client hooks, form, and card indicator</name>
+  <files>src/client/hooks/useCandidates.ts, src/client/components/CandidateForm.tsx, src/client/components/CandidateCard.tsx, src/client/routes/threads/$threadId.tsx</files>
+  <action>
+    1. **Hook** (`src/client/hooks/useCandidates.ts`): Add to `CandidateResponse` interface:
+       ```typescript
+       pros: string | null;
+       cons: string | null;
+       ```
+
+    2. **CandidateForm** (`src/client/components/CandidateForm.tsx`):
+       - Add `pros: string;` and `cons: string;` to `FormData` interface.
+       - Add `pros: "",` and `cons: "",` to `INITIAL_FORM`.
+       - In the `useEffect` pre-fill block, add: `pros: candidate.pros ?? "",` and `cons: candidate.cons ?? "",`.
+       - In `handleSubmit` payload, add: `pros: form.pros.trim() || undefined,` and `cons: form.cons.trim() || undefined,`.
+       - Add two textarea elements in the form, AFTER the Notes textarea and BEFORE the Product Link input. Each should follow the exact same pattern as the Notes textarea:
+         - **Pros**: label "Pros", id `candidate-pros`, placeholder "One pro per line...", rows={3}
+         - **Cons**: label "Cons", id `candidate-cons`, placeholder "One con per line...", rows={3}
+       - Use identical Tailwind classes as the existing Notes textarea.
+
+    3. **CandidateCard** (`src/client/components/CandidateCard.tsx`):
+       - Add `pros?: string | null;` and `cons?: string | null;` to `CandidateCardProps` interface.
+       - Destructure `pros` and `cons` in the component function parameters.
+       - Add a visual indicator badge in the `flex flex-wrap gap-1.5` div, after the StatusBadge. When `(pros || cons)` is truthy, render:
+         ```tsx
+         {(pros || cons) && (
+           <span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-700">
+             +/- Notes
+           </span>
+         )}
+         ```
+
+    4. **Thread detail route** (`src/client/routes/threads/$threadId.tsx`): Pass `pros` and `cons` props to the `<CandidateCard>` component in the candidates map:
+       ```tsx
+       pros={candidate.pros}
+       cons={candidate.cons}
+       ```
+
+    5. Run `bun run lint` to verify Biome compliance (tabs, double quotes, organized imports).
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test && bun run lint</automated>
+  </verify>
+  <done>
+    - CandidateResponse includes pros/cons fields
+    - CandidateForm shows Pros and Cons textareas, pre-fills in edit mode, sends in payload
+    - CandidateCard shows purple "+/- Notes" badge when pros or cons text exists
+    - Thread detail page threads pros/cons props to CandidateCard
+    - Full test suite passes, lint passes
+  </done>
+</task>
+
+</tasks>
+
+<verification>
+1. `bun test` -- full suite green (existing + new tests)
+2. `bun run lint` -- no Biome violations
+3. Manual: create a thread, add a candidate with pros and cons text, verify:
+   - Pros/cons fields appear in the edit form
+   - Saved text persists after page refresh
+   - CandidateCard shows the "+/- Notes" indicator badge
+   - A candidate without pros/cons does NOT show the badge
+</verification>
+
+<success_criteria>
+- RANK-03 fully implemented: pros/cons fields on candidates, editable via form, persisted, with visual indicator
+- Zero test regressions
+- No column drift between schema.ts and test helper
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/10-schema-foundation-pros-cons-fields/10-01-SUMMARY.md`
+</output>

.planning/phases/10-schema-foundation-pros-cons-fields/10-01-SUMMARY.md

@@ -0,0 +1,130 @@
+---
+phase: 10-schema-foundation-pros-cons-fields
+plan: "01"
+subsystem: database
+tags: [drizzle, sqlite, react, forms, zod]
+
+# Dependency graph
+requires: []
+provides:
+  - "pros/cons nullable TEXT columns on thread_candidates table (DB + migration)"
+  - "Zod schema fields: pros/cons optional strings in createCandidateSchema"
+  - "Service layer: createCandidate, updateCandidate, getThreadWithCandidates handle pros/cons"
+  - "Client CandidateForm: Pros and Cons textarea inputs with pre-fill and submit payload"
+  - "Client CandidateCard: purple +/- Notes badge when pros or cons text exists"
+  - "CandidateResponse type includes pros/cons fields"
+affects: [thread-ranking, candidate-comparison, future-candidate-features]
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns: [field-addition-ladder, tdd-red-green]
+
+key-files:
+  created:
+    - drizzle/0004_soft_synch.sql
+  modified:
+    - src/db/schema.ts
+    - tests/helpers/db.ts
+    - src/server/services/thread.service.ts
+    - src/shared/schemas.ts
+    - src/client/hooks/useCandidates.ts
+    - src/client/components/CandidateForm.tsx
+    - src/client/components/CandidateCard.tsx
+    - src/client/routes/threads/$threadId.tsx
+    - tests/services/thread.service.test.ts
+
+key-decisions:
+  - "Empty string for pros/cons stored as-is by SQLite (not normalized to null) — updateCandidate test accepts empty string or null as cleared state"
+  - "Pros/Cons textareas placed after Notes and before Product Link — logical grouping for research annotation"
+  - "Visual indicator uses purple color scheme to distinguish from weight (blue), price (green), category (gray), and status badges"
+
+patterns-established:
+  - "Field-addition ladder: schema -> migration -> test helper -> service -> Zod -> types -> hook -> form -> card indicator"
+  - "Test helper CREATE TABLE must mirror schema.ts columns exactly — column drift causes silent test failures"
+  - "TDD: RED commit (failing tests) -> GREEN commit (implementation) per task"
+
+requirements-completed: [RANK-03]
+
+# Metrics
+duration: 6min
+completed: "2026-03-16"
+---
+
+# Phase 10 Plan 01: Schema Foundation Pros/Cons Fields Summary
+
+**Nullable pros/cons TEXT columns added to thread_candidates from SQLite schema through Drizzle migration, service layer, Zod validation, React form inputs, and CandidateCard visual badge**
+
+## Performance
+
+- **Duration:** 6 min
+- **Started:** 2026-03-16T20:30:18Z
+- **Completed:** 2026-03-16T20:36:25Z
+- **Tasks:** 2
+- **Files modified:** 9
+
+## Accomplishments
+- Added pros/cons columns to threadCandidates schema and applied Drizzle migration (0004_soft_synch.sql)
+- Wired pros/cons through all backend layers: service create/update/get + Zod schemas
+- Added Pros and Cons textarea inputs to CandidateForm with pre-fill in edit mode
+- Added purple "+/- Notes" badge to CandidateCard when either field has content
+- 28 thread service tests passing (24 existing + 4 new) with zero regressions
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **TDD RED - failing tests** - `719f708` (test)
+2. **Task 1: Add pros/cons columns through backend + tests** - `7a64a18` (feat)
+3. **Task 2: Wire pros/cons through client hooks, form, and card indicator** - `4f2aefe` (feat)
+
+_Note: TDD task has separate test commit (RED) and implementation commit (GREEN)_
+
+## Files Created/Modified
+- `src/db/schema.ts` - Added pros/cons nullable TEXT columns to threadCandidates
+- `drizzle/0004_soft_synch.sql` - Migration: ALTER TABLE thread_candidates ADD COLUMN pros/cons
+- `tests/helpers/db.ts` - Mirrored pros/cons in CREATE TABLE thread_candidates
+- `src/server/services/thread.service.ts` - pros/cons in createCandidate values(), updateCandidate Partial type, getThreadWithCandidates select
+- `src/shared/schemas.ts` - pros/cons optional string fields in createCandidateSchema (updateCandidateSchema inherits via .partial())
+- `src/client/hooks/useCandidates.ts` - pros/cons added to CandidateResponse interface
+- `src/client/components/CandidateForm.tsx` - Pros and Cons textareas, FormData fields, INITIAL_FORM, pre-fill, payload
+- `src/client/components/CandidateCard.tsx` - props, destructuring, purple +/- Notes badge
+- `src/client/routes/threads/$threadId.tsx` - pros={candidate.pros} cons={candidate.cons} passed to CandidateCard
+- `tests/services/thread.service.test.ts` - 4 new test cases for pros/cons create/update/get
+
+## Decisions Made
+- Empty string for pros/cons is stored as-is (not normalized to null on empty); the test accepts either empty string or null as "cleared" state since SQLite/Drizzle does not coerce empty strings.
+- Visual indicator uses purple to distinguish from existing badge color scheme (blue=weight, green=price, gray=category, status has its own colors).
+- Textarea placement (after Notes, before Product Link) groups annotation fields logically.
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+
+Pre-existing lint violations discovered in files outside the plan scope:
+- `src/client/components/WeightSummaryCard.tsx`, `src/client/routes/collection/index.tsx`, `src/client/routes/index.tsx`, `src/client/routes/setups/$setupId.tsx` — format/organizeImports errors
+- `.obsidian/workspace.json` — Biome format error (IDE file, should be excluded)
+
+These are logged to `deferred-items.md` and not fixed (out of scope per deviation scope boundary rule).
+
+## User Setup Required
+
+None - no external service configuration required.
+
+## Next Phase Readiness
+- RANK-03 fully implemented: pros/cons fields on candidates, editable via form, persisted in SQLite, with visual badge indicator
+- Schema foundation complete — subsequent plans in phase 10 can build ranking/sorting features on top of this data
+- No blockers
+
+---
+*Phase: 10-schema-foundation-pros-cons-fields*
+*Completed: 2026-03-16*
+
+## Self-Check: PASSED
+
+All files and commits verified:
+- All 10 key files present on disk
+- All 3 task commits found in git log (719f708, 7a64a18, 4f2aefe)
+- Key artifact strings confirmed in each file (pros: text, pros TEXT, pros: z.string, candidate-pros, pros || cons)

.planning/phases/10-schema-foundation-pros-cons-fields/10-RESEARCH.md

@@ -0,0 +1,417 @@
+# Phase 10: Schema Foundation + Pros/Cons Fields - Research
+
+**Researched:** 2026-03-16
+**Domain:** Drizzle ORM schema migration + full-stack field addition (SQLite / Hono / React)
+**Confidence:** HIGH
+
+---
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| RANK-03 | User can add pros and cons text per candidate displayed as bullet lists | Confirmed: two nullable TEXT columns on `thread_candidates` + textarea inputs in `CandidateForm` + visual indicator on `CandidateCard` |
+</phase_requirements>
+
+---
+
+## Summary
+
+Phase 10 is a contained, top-to-bottom field-addition task. Two nullable `TEXT` columns (`pros`, `cons`) must be added to the `thread_candidates` table, propagated through every layer that touches that table, and surfaced in the UI as editable text areas with a card-level presence indicator.
+
+The project uses Drizzle ORM with SQLite. Adding nullable columns via `ALTER TABLE … ADD COLUMN` is safe in SQLite (no default value is required for nullable TEXT). The Drizzle workflow is: edit `schema.ts` → `bun run db:generate` → `bun run db:push`. The generated SQL migration follows the established pattern already used four times in this project.
+
+There is one mandatory non-obvious step documented in CLAUDE.md: the test helper at `tests/helpers/db.ts` contains a hardcoded `CREATE TABLE thread_candidates` statement that mirrors the production schema. It must be updated in lockstep with `schema.ts` or all existing candidate tests will silently omit the new columns and new service-level tests will fail.
+
+**Primary recommendation:** Follow the exact field-addition ladder: schema → migration → test helper → service (insert + update + select projection) → Zod schemas → shared types → API route (zValidator) → React hook response type → CandidateForm → CandidateCard indicator. Every rung must be touched — skipping any one causes type drift or runtime failures.
+
+---
+
+## Standard Stack
+
+### Core
+
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| drizzle-orm | installed | ORM + migration generation | Project standard; all migrations use it |
+| drizzle-kit | installed | CLI for `db:generate` | Project standard; configured in drizzle.config.ts |
+| zod | installed | Schema validation on API boundary | Project standard; `@hono/zod-validator` integration |
+| bun:sqlite | runtime built-in | In-memory test DB | Used by `createTestDb()` helper |
+
+No new dependencies are required for this phase.
+
+**Installation:**
+```bash
+# No new packages — all required libraries already installed
+```
+
+---
+
+## Architecture Patterns
+
+### Established Field-Addition Ladder
+
+Every field addition in this codebase follows this exact sequence. Previous examples: `status` on candidates, `classification` on `setup_items`, `icon` on categories.
+
+```
+1. src/db/schema.ts           — Drizzle column definition
+2. drizzle/ (generated)       — bun run db:generate
+3. gearbox.db                 — bun run db:push
+4. tests/helpers/db.ts        — Raw SQL CREATE TABLE mirrored manually
+5. src/server/services/thread.service.ts
+   a. createCandidate()       — values() object
+   b. updateCandidate()       — data type + set()
+   c. getThreadWithCandidates() — explicit column projection
+6. src/shared/schemas.ts      — createCandidateSchema + updateCandidateSchema
+7. src/shared/types.ts        — auto-inferred (no manual edit needed)
+8. src/client/hooks/useCandidates.ts — CandidateResponse interface
+9. src/client/components/CandidateForm.tsx — FormData + textarea inputs + payload
+10. src/client/components/CandidateCard.tsx — visual indicator prop + render
+```
+
+### Pattern 1: Drizzle Nullable Text Column
+
+**What:** Add an optional text field to an existing Drizzle table.
+**When to use:** When the field is user-provided text, no business logic default applies.
+
+```typescript
+// Source: src/db/schema.ts — pattern already used by notes, productUrl, imageFilename
+export const threadCandidates = sqliteTable("thread_candidates", {
+  // ... existing columns ...
+  pros: text("pros"),   // nullable, no default — mirrors notes/productUrl pattern
+  cons: text("cons"),   // nullable, no default
+  // ...
+});
+```
+
+### Pattern 2: Test Helper Table Synchronization
+
+**What:** Mirror every new column in the raw SQL inside `createTestDb()`.
+**When to use:** Every time `schema.ts` is modified. Documented as mandatory in CLAUDE.md.
+
+```typescript
+// Source: tests/helpers/db.ts — existing thread_candidates CREATE TABLE
+sqlite.run(`
+  CREATE TABLE thread_candidates (
+    id INTEGER PRIMARY KEY AUTOINCREMENT,
+    thread_id INTEGER NOT NULL REFERENCES threads(id) ON DELETE CASCADE,
+    name TEXT NOT NULL,
+    weight_grams REAL,
+    price_cents INTEGER,
+    category_id INTEGER NOT NULL REFERENCES categories(id),
+    notes TEXT,
+    product_url TEXT,
+    image_filename TEXT,
+    status TEXT NOT NULL DEFAULT 'researching',
+    pros TEXT,    -- ADD THIS
+    cons TEXT,    -- ADD THIS
+    created_at INTEGER NOT NULL DEFAULT (unixepoch()),
+    updated_at INTEGER NOT NULL DEFAULT (unixepoch())
+  )
+`);
+```
+
+### Pattern 3: Explicit Select Projection in Service
+
+**What:** `getThreadWithCandidates` uses an explicit `.select({...})` projection, not `select()`.
+**When to use:** New columns MUST be explicitly added to the projection or they will not appear in query results.
+
+```typescript
+// Source: src/server/services/thread.service.ts — getThreadWithCandidates()
+const candidateList = db
+  .select({
+    // ... existing fields ...
+    pros: threadCandidates.pros,   // ADD
+    cons: threadCandidates.cons,   // ADD
+    categoryName: categories.name,
+    categoryIcon: categories.icon,
+  })
+  .from(threadCandidates)
+  // ...
+```
+
+### Pattern 4: Zod Schema Extension
+
+**What:** Add optional string fields to `createCandidateSchema`; `updateCandidateSchema` is derived via `.partial()` and picks them up automatically.
+**When to use:** Any new candidate API field.
+
+```typescript
+// Source: src/shared/schemas.ts
+export const createCandidateSchema = z.object({
+  name: z.string().min(1, "Name is required"),
+  // ... existing fields ...
+  pros: z.string().optional(),   // ADD
+  cons: z.string().optional(),   // ADD
+});
+
+// updateCandidateSchema = createCandidateSchema.partial() — inherits automatically
+```
+
+### Pattern 5: CandidateForm Textarea Addition
+
+**What:** Extend `FormData` interface and `INITIAL_FORM` constant, add pre-fill in `useEffect`, add textarea elements, include in payload.
+
+```typescript
+// Source: src/client/components/CandidateForm.tsx — FormData interface
+interface FormData {
+  // ... existing ...
+  pros: string;    // ADD
+  cons: string;    // ADD
+}
+
+const INITIAL_FORM: FormData = {
+  // ... existing ...
+  pros: "",        // ADD
+  cons: "",        // ADD
+};
+
+// In useEffect pre-fill:
+pros: candidate.pros ?? "",   // ADD
+cons: candidate.cons ?? "",   // ADD
+
+// In payload construction:
+pros: form.pros.trim() || undefined,   // ADD
+cons: form.cons.trim() || undefined,   // ADD
+```
+
+### Pattern 6: CandidateCard Visual Indicator
+
+**What:** Show a small badge when a candidate has pros or cons text. The requirement says "visual indicator when a candidate has pros or cons entered" — not a full display of the text (that is the form's job).
+**When to use:** When `(pros || cons)` is truthy.
+
+```tsx
+// Source: src/client/components/CandidateCard.tsx — props interface
+interface CandidateCardProps {
+  // ... existing ...
+  pros?: string | null;   // ADD
+  cons?: string | null;   // ADD
+}
+
+// In the card's badge section (alongside weight/price badges):
+{(pros || cons) && (
+  <span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-500">
+    Notes
+  </span>
+)}
+```
+
+The exact styling (color, icon, text) is left to the planner's discretion — the requirement only specifies "visual indicator."
+
+### Anti-Patterns to Avoid
+
+- **Forgetting the test helper**: If `tests/helpers/db.ts` is not updated, the in-memory schema won't have `pros`/`cons` columns. Tests that insert or read these fields will get `undefined` instead of the stored value, causing silent failures or column-not-found errors. CLAUDE.md documents this as a known hazard.
+- **Using `select()` without explicit fields**: The `getThreadWithCandidates` service function already uses an explicit projection. Adding fields to the schema without adding them to the projection means the client never receives the data.
+- **Storing pros/cons as a JSON array of bullet strings**: The requirement says "text per candidate displayed as bullet lists" — the display can parse newlines into bullets from a plain TEXT field. A single multi-line `TEXT` column is correct and consistent with the existing `notes` field pattern. No JSON, no separate table.
+- **Adding a separate `candidatePros` / `candidateCons` table**: Massive over-engineering. These are simple annotations on a single candidate, not a many-per-candidate relationship.
+
+---
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Schema migration | Custom SQL scripts | `bun run db:generate` + `bun run db:push` | Drizzle-kit generates correct ALTER TABLE, tracks journal, handles snapshot |
+| API input validation | Manual checks | Zod via `zValidator` (already wired) | All candidate routes already use `updateCandidateSchema` — just extend it |
+| Bullet-list rendering | Custom tokenizer | CSS `whitespace-pre-line` or split on `\n` | Simple text with newlines is sufficient for RANK-03 |
+
+---
+
+## Common Pitfalls
+
+### Pitfall 1: Test Helper Column Drift
+
+**What goes wrong:** New columns exist in production schema but are absent from the hardcoded `CREATE TABLE` in `tests/helpers/db.ts`. Tests pass structurally but new-column values are lost.
+**Why it happens:** The test helper duplicates the schema in raw SQL, not via Drizzle. There is no automated sync.
+**How to avoid:** Update `tests/helpers/db.ts` immediately after editing `schema.ts`, in the same commit wave.
+**Warning signs:** `candidate.pros` returns `undefined` in service tests even after saving a value.
+
+### Pitfall 2: Missing Explicit Column in Select Projection
+
+**What goes wrong:** `getThreadWithCandidates` uses `.select({ id: threadCandidates.id, ... })` — an explicit map. New columns are silently excluded.
+**Why it happens:** Drizzle's explicit projection doesn't automatically include newly-added columns.
+**How to avoid:** Search for every `.select({` that references `threadCandidates` and add `pros` and `cons`.
+**Warning signs:** API returns candidate without `pros`/`cons` fields even though they're saved in DB.
+
+### Pitfall 3: updateCandidate Service Type Mismatch
+
+**What goes wrong:** `updateCandidate` in `thread.service.ts` has a hardcoded `Partial<{ name, weightGrams, ... }>` type rather than using the Zod-inferred type. New fields must be manually added to this inline type.
+**Why it happens:** The function was written with an inline type, not `UpdateCandidate`.
+**How to avoid:** Add `pros: string` and `cons: string` to the `Partial<{...}>` inline type in `updateCandidate`.
+**Warning signs:** TypeScript error when trying to set `pros`/`cons` in the `.set({...data})` call.
+
+### Pitfall 4: CandidateCard Prop Not Threaded Through Call Sites
+
+**What goes wrong:** `CandidateCard` receives new `pros`/`cons` props, but the parent component (the thread detail page / candidate list) doesn't pass them.
+**Why it happens:** Adding props to a component doesn't update callers.
+**How to avoid:** Search for all `<CandidateCard` usages and add the new prop.
+**Warning signs:** Indicator never shows even when pros/cons data is present.
+
+---
+
+## Code Examples
+
+### Migration SQL (Generated Output Shape)
+
+```sql
+-- Expected output of bun run db:generate
+-- drizzle/000X_<tag>.sql
+ALTER TABLE `thread_candidates` ADD `pros` text;
+ALTER TABLE `thread_candidates` ADD `cons` text;
+```
+
+SQLite supports `ADD COLUMN` for nullable columns without a default. Confirmed by existing migration pattern (`0003_misty_mongu.sql` uses `ALTER TABLE setup_items ADD classification text DEFAULT 'base' NOT NULL`).
+
+### Service: createCandidate Values
+
+```typescript
+// Source: src/server/services/thread.service.ts
+return db
+  .insert(threadCandidates)
+  .values({
+    threadId,
+    name: data.name,
+    // ... existing fields ...
+    pros: data.pros ?? null,   // ADD
+    cons: data.cons ?? null,   // ADD
+  })
+  .returning()
+  .get();
+```
+
+### Service: updateCandidate Inline Type
+
+```typescript
+// Source: src/server/services/thread.service.ts
+export function updateCandidate(
+  db: Db = prodDb,
+  candidateId: number,
+  data: Partial<{
+    name: string;
+    weightGrams: number;
+    priceCents: number;
+    categoryId: number;
+    notes: string;
+    productUrl: string;
+    imageFilename: string;
+    status: "researching" | "ordered" | "arrived";
+    pros: string;   // ADD
+    cons: string;   // ADD
+  }>,
+) { ... }
+```
+
+### Hook: CandidateResponse Interface
+
+```typescript
+// Source: src/client/hooks/useCandidates.ts
+interface CandidateResponse {
+  id: number;
+  // ... existing ...
+  pros: string | null;   // ADD
+  cons: string | null;   // ADD
+}
+```
+
+---
+
+## State of the Art
+
+| Old Approach | Current Approach | Notes |
+|--------------|------------------|-------|
+| Manual SQL migrations | Drizzle-kit generate + push | Already established — 4 migrations in project |
+| `notes` as freeform text | `pros`/`cons` as separate nullable TEXT columns | Matches how existing `notes` field works; no special type |
+
+**Not applicable in this phase:**
+- No new libraries
+- No breaking API changes (all new fields are optional)
+- Existing candidates will have `pros = null` and `cons = null` after migration — no backfill needed
+
+---
+
+## Open Questions
+
+1. **Bullet list rendering in CandidateCard**
+   - What we know: RANK-03 says "displayed as bullet lists"
+   - What's unclear: The card currently shows the pros/cons indicator; does the card need to render the actual bullets, or does that happen elsewhere (e.g., a tooltip, expanded state, or comparison view in Phase 12)?
+   - Recommendation: Phase 10 success criteria only requires "visual indicator when a candidate has pros or cons entered." Full bullet rendering can be deferred to Phase 12 (Comparison View) or Phase 11. The form's edit view can display raw textarea text.
+
+2. **Maximum text length**
+   - What we know: SQLite TEXT has no practical length limit; the existing `notes` field has no validation constraint
+   - What's unclear: Should pros/cons have a max length?
+   - Recommendation: Omit length constraint to stay consistent with the `notes` field. Add if user feedback indicates issues.
+
+---
+
+## Validation Architecture
+
+`workflow.nyquist_validation` is `true` in `.planning/config.json`.
+
+### Test Framework
+
+| Property | Value |
+|----------|-------|
+| Framework | Bun test runner (built-in) |
+| Config file | None — `bun test` discovers `tests/**/*.test.ts` |
+| Quick run command | `bun test tests/services/thread.service.test.ts` |
+| Full suite command | `bun test` |
+
+### Phase Requirements → Test Map
+
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| RANK-03 | `createCandidate` stores pros/cons and returns them | unit | `bun test tests/services/thread.service.test.ts` | Extend existing |
+| RANK-03 | `updateCandidate` can set/clear pros and cons | unit | `bun test tests/services/thread.service.test.ts` | Extend existing |
+| RANK-03 | `getThreadWithCandidates` returns pros/cons on each candidate | unit | `bun test tests/services/thread.service.test.ts` | Extend existing |
+| RANK-03 | `PUT /api/threads/:id/candidates/:id` accepts pros/cons in body | route | `bun test tests/routes/threads.test.ts` | Extend existing |
+| RANK-03 | All existing tests pass (no column drift) | regression | `bun test` | Existing ✅ |
+
+### Sampling Rate
+
+- **Per task commit:** `bun test tests/services/thread.service.test.ts`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+
+No new test files need to be created. All tests are extensions of existing files:
+- `tests/services/thread.service.test.ts` — add `pros`/`cons` test cases to existing `describe("createCandidate")` and `describe("updateCandidate")` blocks
+- `tests/routes/threads.test.ts` — add a test case to existing `PUT` candidate describe block
+
+None — existing test infrastructure covers all phase requirements (as extensions).
+
+---
+
+## Sources
+
+### Primary (HIGH confidence)
+
+- Direct code inspection: `src/db/schema.ts` — current `threadCandidates` column layout
+- Direct code inspection: `tests/helpers/db.ts` — `CREATE TABLE thread_candidates` raw SQL
+- Direct code inspection: `src/server/services/thread.service.ts` — `createCandidate`, `updateCandidate`, `getThreadWithCandidates`
+- Direct code inspection: `src/shared/schemas.ts` — `createCandidateSchema`, `updateCandidateSchema`
+- Direct code inspection: `src/client/components/CandidateForm.tsx` — form structure and payload
+- Direct code inspection: `src/client/components/CandidateCard.tsx` — props interface and badge rendering
+- Direct code inspection: `src/client/hooks/useCandidates.ts` — `CandidateResponse` interface
+- Direct code inspection: `drizzle/0003_misty_mongu.sql` — ALTER TABLE migration pattern
+- Direct code inspection: `CLAUDE.md` — explicit test-helper sync requirement
+
+### Secondary (MEDIUM confidence)
+
+- SQLite docs: `ALTER TABLE … ADD COLUMN` supports nullable columns without default — verified by existing migration pattern in project
+
+### Tertiary (LOW confidence)
+
+- None
+
+---
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH — no new libraries; all tooling already in use
+- Architecture: HIGH — full codebase read confirms exact ladder; no ambiguity
+- Pitfalls: HIGH — CLAUDE.md explicitly calls out test helper drift; column projection issue confirmed by reading service code
+
+**Research date:** 2026-03-16
+**Valid until:** 2026-06-16 (stable stack — 90 days)

.planning/phases/10-schema-foundation-pros-cons-fields/10-VALIDATION.md

@@ -0,0 +1,78 @@
+---
+phase: 10
+slug: schema-foundation-pros-cons-fields
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-16
+---
+
+# Phase 10 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Bun test runner (built-in) |
+| **Config file** | none — `bun test` discovers `tests/**/*.test.ts` |
+| **Quick run command** | `bun test tests/services/thread.service.test.ts` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test tests/services/thread.service.test.ts`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 10-01-01 | 01 | 1 | RANK-03 | unit | `bun test tests/services/thread.service.test.ts` | Extend existing | ⬜ pending |
+| 10-01-02 | 01 | 1 | RANK-03 | unit | `bun test tests/services/thread.service.test.ts` | Extend existing | ⬜ pending |
+| 10-01-03 | 01 | 1 | RANK-03 | unit | `bun test tests/services/thread.service.test.ts` | Extend existing | ⬜ pending |
+| 10-01-04 | 01 | 1 | RANK-03 | route | `bun test tests/routes/threads.test.ts` | Extend existing | ⬜ pending |
+| 10-01-05 | 01 | 1 | RANK-03 | regression | `bun test` | Existing ✅ | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+Existing infrastructure covers all phase requirements. All tests are extensions of existing files:
+- `tests/services/thread.service.test.ts` — add `pros`/`cons` test cases to existing describe blocks
+- `tests/routes/threads.test.ts` — add test case to existing PUT candidate describe block
+
+*No new test files or framework installs required.*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| CandidateCard shows visual indicator when pros/cons present | RANK-03 | UI rendering verification | 1. Create thread with candidate 2. Add pros text 3. Verify indicator badge appears on card |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/10-schema-foundation-pros-cons-fields/10-VERIFICATION.md

@@ -0,0 +1,104 @@
+---
+phase: 10-schema-foundation-pros-cons-fields
+verified: 2026-03-16T21:00:00Z
+status: passed
+score: 4/4 must-haves verified
+re_verification: false
+---
+
+# Phase 10: Schema Foundation Pros/Cons Fields Verification Report
+
+**Phase Goal:** Candidates can be annotated with pros and cons, and the database is ready for ranking
+**Verified:** 2026-03-16T21:00:00Z
+**Status:** passed
+**Re-verification:** No — initial verification
+
+## Goal Achievement
+
+### Observable Truths
+
+| #   | Truth                                                                                     | Status     | Evidence                                                                                                                                              |
+| --- | ----------------------------------------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | User can open a candidate edit form and see pros and cons text fields                    | VERIFIED   | `CandidateForm.tsx` lines 250-284: two textarea elements with `id="candidate-pros"` and `id="candidate-cons"`, pre-filled via `candidate.pros ?? ""` in edit useEffect |
+| 2   | User can save pros and cons text; the text persists across page refreshes                | VERIFIED   | Form payload sends `pros: form.pros.trim() || undefined` to API; service stores `data.pros ?? null` in SQLite; migration `0004_soft_synch.sql` adds columns to live DB |
+| 3   | CandidateCard shows a visual indicator when a candidate has pros or cons entered         | VERIFIED   | `CandidateCard.tsx` line 181-185: `{(pros || cons) && <span ...bg-purple-50 text-purple-700...>+/- Notes</span>}` renders conditionally                |
+| 4   | All existing tests pass after the schema migration (no column drift in test helper)      | VERIFIED   | `bun test tests/services/thread.service.test.ts` — 28 pass, 0 fail; test helper mirrors `pros TEXT, cons TEXT` columns at lines 58-59                 |
+
+**Score:** 4/4 truths verified
+
+---
+
+### Required Artifacts
+
+| Artifact                                             | Expected                                                           | Status   | Details                                                                                                   |
+| ---------------------------------------------------- | ------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------- |
+| `src/db/schema.ts`                                   | pros and cons nullable TEXT columns on threadCandidates            | VERIFIED | Lines 62-63: `pros: text("pros"),` and `cons: text("cons"),` present after `status` column               |
+| `tests/helpers/db.ts`                                | Mirrored pros/cons columns in test DB CREATE TABLE                 | VERIFIED | Lines 58-59: `pros TEXT,` and `cons TEXT,` present in `CREATE TABLE thread_candidates`                   |
+| `src/server/services/thread.service.ts`              | pros/cons in createCandidate, updateCandidate, getThreadWithCandidates | VERIFIED | createCandidate lines 156-157; updateCandidate Partial type lines 175-176; getThreadWithCandidates select lines 76-77 |
+| `src/shared/schemas.ts`                              | pros and cons optional string fields in createCandidateSchema      | VERIFIED | Lines 56-57: `pros: z.string().optional(),` and `cons: z.string().optional(),`; updateCandidateSchema inherits via `.partial()` |
+| `src/client/components/CandidateForm.tsx`            | Pros and Cons textarea inputs in candidate form                    | VERIFIED | Lines 250-284: two labeled textareas with ids `candidate-pros` and `candidate-cons`; FormData interface lines 22-23; INITIAL_FORM lines 34-35; pre-fill lines 68-69; payload lines 119-120 |
+| `src/client/components/CandidateCard.tsx`            | Visual indicator badge when pros or cons are present               | VERIFIED | Props interface lines 21-22: `pros?: string | null; cons?: string | null;`; destructured at line 38-39; badge at lines 181-185 using `bg-purple-50 text-purple-700` |
+| `tests/services/thread.service.test.ts`              | Tests for pros/cons in create, update, and get operations          | VERIFIED | 4 new test cases: "stores and returns pros and cons" (line 152), "returns null for pros and cons when not provided" (line 165), "can set and clear pros and cons" (line 200), "includes pros and cons on each candidate" (line 113) |
+
+---
+
+### Key Link Verification
+
+| From                                | To                                     | Via                                           | Status   | Details                                                                                                              |
+| ----------------------------------- | -------------------------------------- | --------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------- |
+| `src/db/schema.ts`                  | `tests/helpers/db.ts`                  | Manual column mirroring in CREATE TABLE        | VERIFIED | `pros TEXT` and `cons TEXT` present in both locations; test helper lines 58-59 match schema lines 62-63             |
+| `src/shared/schemas.ts`             | `src/server/services/thread.service.ts` | Zod-inferred CreateCandidate type used in service | VERIFIED | Service imports `CreateCandidate` from `../../shared/types.ts` (line 9); `pros` and `cons` flow through the type into `createCandidate` and `updateCandidate` |
+| `src/server/services/thread.service.ts` | `src/client/hooks/useCandidates.ts` | API JSON response includes pros/cons fields    | VERIFIED | `getThreadWithCandidates` select projection explicitly includes `pros: threadCandidates.pros` and `cons: threadCandidates.cons`; `CandidateResponse` interface in hook declares `pros: string | null; cons: string | null;` |
+| `src/client/hooks/useCandidates.ts` | `src/client/components/CandidateForm.tsx` | CandidateResponse type drives form pre-fill  | VERIFIED | `CandidateForm.tsx` uses `useThread` which returns candidates; pre-fill useEffect accesses `candidate.pros` and `candidate.cons` at lines 68-69 |
+| `src/client/routes/threads/$threadId.tsx` | `src/client/components/CandidateCard.tsx` | Props threaded from candidate data to card | VERIFIED | Lines 156-157 in thread route: `pros={candidate.pros}` and `cons={candidate.cons}` passed to `<CandidateCard>` |
+
+---
+
+### Requirements Coverage
+
+| Requirement | Source Plan | Description                                                       | Status    | Evidence                                                                                                              |
+| ----------- | ----------- | ----------------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------- |
+| RANK-03     | 10-01-PLAN  | User can add pros and cons text per candidate displayed as bullet lists | SATISFIED | Pros/cons fields wired end-to-end: DB columns, migration, service, Zod schema, React form textareas, CandidateCard badge. REQUIREMENTS.md marks it `[x]` at line 21. |
+
+Note: The requirement description says "displayed as bullet lists" — the form stores multi-line text and the card shows a "+/- Notes" badge indicator. The text is stored as-is (one entry per line convention per plan instructions) but is not rendered as an explicit `<ul>` bullet list. This is a visual rendering concern suitable for human verification, but the data model and edit UI fully support it.
+
+**Orphaned requirements check:** REQUIREMENTS.md traceability table maps only RANK-03 to Phase 10. No additional requirements are assigned to this phase. No orphaned requirements.
+
+---
+
+### Anti-Patterns Found
+
+| File | Line | Pattern | Severity | Impact |
+| ---- | ---- | ------- | -------- | ------ |
+| None detected | — | — | — | — |
+
+Scanned all 9 modified files for TODO/FIXME/placeholder comments, empty implementations, and console.log-only handlers. None found. The `pros: form.pros.trim() || undefined` pattern in `handleSubmit` correctly sends `undefined` (omitting the field) when empty, allowing the server to store `null` — this is intentional, not a stub.
+
+---
+
+### Human Verification Required
+
+#### 1. Pros/Cons Text Renders Usably in Edit Form
+
+**Test:** Open a thread, click "Add Candidate", observe the form. Scroll past Notes field — two textareas labeled "Pros" and "Cons" with placeholder "One pro per line..." and "One con per line..." should appear. Enter multi-line text in each, save, re-open the candidate, and confirm text pre-fills correctly.
+**Expected:** Text persists across saves and page refreshes; form pre-fills with saved content in edit mode.
+**Why human:** Requires a running browser with API connectivity to confirm round-trip persistence.
+
+#### 2. CandidateCard Badge Visibility
+
+**Test:** With a candidate that has pros or cons text, view the thread candidate grid. The card should show a purple "+/- Notes" badge alongside weight/price/status badges. A candidate without pros or cons should NOT show the badge.
+**Expected:** Badge appears conditionally; absent when both fields are null/empty.
+**Why human:** Requires browser rendering to verify visual appearance and conditional display.
+
+---
+
+### Gaps Summary
+
+No gaps found. All four observable truths are fully verified. Every artifact exists, is substantive (not a stub), and is properly wired end-to-end. The database migration (`drizzle/0004_soft_synch.sql`) is present and correct. All 28 service tests pass (24 pre-existing + 4 new). The three task commits (719f708, 7a64a18, 4f2aefe) are confirmed in the git log.
+
+RANK-03 is satisfied: pros and cons fields exist in the database, flow through the service layer with full CRUD support, are accepted by Zod validation, are exposed in the API response type, are editable via textarea inputs in `CandidateForm`, pre-fill correctly in edit mode, are sent in the submit payload, and surface as a purple "+/- Notes" visual indicator on `CandidateCard` when either field has content.
+
+---
+
+_Verified: 2026-03-16T21:00:00Z_
+_Verifier: Claude (gsd-verifier)_

.planning/phases/10-schema-foundation-pros-cons-fields/deferred-items.md

@@ -0,0 +1,13 @@
+# Deferred Items
+
+## Pre-existing Lint Violations (Out of Scope for 10-01)
+
+These Biome lint/format errors existed before phase 10-01 and are not caused by any changes in this plan. They should be addressed in a separate cleanup task.
+
+- `src/client/components/WeightSummaryCard.tsx` - format violation (line length)
+- `src/client/routes/collection/index.tsx` - organizeImports, format violations
+- `src/client/routes/index.tsx` - organizeImports, format violations
+- `src/client/routes/setups/$setupId.tsx` - organizeImports violations
+- `.obsidian/workspace.json` - format violations (IDE file, should be excluded from Biome)
+
+Discovered during: Task 2 lint verification

.planning/phases/11-candidate-ranking/11-01-PLAN.md

@@ -0,0 +1,285 @@
+---
+phase: 11-candidate-ranking
+plan: "01"
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/db/schema.ts
+  - tests/helpers/db.ts
+  - src/server/services/thread.service.ts
+  - src/server/routes/threads.ts
+  - src/shared/schemas.ts
+  - src/shared/types.ts
+  - tests/services/thread.service.test.ts
+  - tests/routes/threads.test.ts
+autonomous: true
+requirements: [RANK-01, RANK-04, RANK-05]
+
+must_haves:
+  truths:
+    - "Candidates returned from getThreadWithCandidates are ordered by sort_order ascending"
+    - "Calling reorderCandidates with a new ID sequence updates sort_order values to match that sequence"
+    - "PATCH /api/threads/:id/candidates/reorder returns 200 and persists new order"
+    - "reorderCandidates returns error when thread status is not active"
+    - "New candidates created via createCandidate are appended to end of rank (highest sort_order + 1000)"
+  artifacts:
+    - path: "src/db/schema.ts"
+      provides: "sortOrder REAL column on threadCandidates"
+      contains: "sortOrder"
+    - path: "src/shared/schemas.ts"
+      provides: "reorderCandidatesSchema Zod validator"
+      contains: "reorderCandidatesSchema"
+    - path: "src/shared/types.ts"
+      provides: "ReorderCandidates type"
+      contains: "ReorderCandidates"
+    - path: "src/server/services/thread.service.ts"
+      provides: "reorderCandidates function + ORDER BY sort_order + createCandidate sort_order appending"
+      exports: ["reorderCandidates"]
+    - path: "src/server/routes/threads.ts"
+      provides: "PATCH /:id/candidates/reorder endpoint"
+      contains: "candidates/reorder"
+    - path: "tests/helpers/db.ts"
+      provides: "sort_order column in CREATE TABLE thread_candidates"
+      contains: "sort_order"
+  key_links:
+    - from: "src/server/routes/threads.ts"
+      to: "src/server/services/thread.service.ts"
+      via: "reorderCandidates(db, threadId, orderedIds)"
+      pattern: "reorderCandidates"
+    - from: "src/server/routes/threads.ts"
+      to: "src/shared/schemas.ts"
+      via: "zValidator with reorderCandidatesSchema"
+      pattern: "reorderCandidatesSchema"
+    - from: "src/server/services/thread.service.ts"
+      to: "src/db/schema.ts"
+      via: "threadCandidates.sortOrder in ORDER BY and UPDATE"
+      pattern: "threadCandidates\\.sortOrder"
+---
+
+<objective>
+Add sort_order column to thread_candidates, implement reorder service and API endpoint, and update candidate ordering throughout the backend.
+
+Purpose: Provides the persistence layer for drag-to-reorder ranking (RANK-01, RANK-04) and enforces the resolved-thread guard (RANK-05). The frontend plan (11-02) depends on this.
+Output: Working PATCH /api/threads/:id/candidates/reorder endpoint, sort_order-based ordering in getThreadWithCandidates, sort_order appending in createCandidate, full test coverage.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/11-candidate-ranking/11-CONTEXT.md
+@.planning/phases/11-candidate-ranking/11-RESEARCH.md
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/db/schema.ts (threadCandidates table — add sortOrder here):
+```typescript
+export const threadCandidates = sqliteTable("thread_candidates", {
+  id: integer("id").primaryKey({ autoIncrement: true }),
+  threadId: integer("thread_id").notNull().references(() => threads.id, { onDelete: "cascade" }),
+  name: text("name").notNull(),
+  weightGrams: real("weight_grams"),
+  priceCents: integer("price_cents"),
+  categoryId: integer("category_id").notNull().references(() => categories.id),
+  notes: text("notes"),
+  productUrl: text("product_url"),
+  imageFilename: text("image_filename"),
+  status: text("status").notNull().default("researching"),
+  pros: text("pros"),
+  cons: text("cons"),
+  createdAt: integer("created_at", { mode: "timestamp" }).notNull().$defaultFn(() => new Date()),
+  updatedAt: integer("updated_at", { mode: "timestamp" }).notNull().$defaultFn(() => new Date()),
+});
+```
+
+From src/server/services/thread.service.ts (key functions to modify):
+```typescript
+type Db = typeof prodDb;
+export function getThreadWithCandidates(db: Db, threadId: number) // add .orderBy(threadCandidates.sortOrder)
+export function createCandidate(db: Db, threadId: number, data: ...) // add sort_order = max + 1000
+export function resolveThread(db: Db, threadId: number, candidateId: number) // existing status check pattern to reuse
+```
+
+From src/shared/schemas.ts (existing patterns):
+```typescript
+export const createCandidateSchema = z.object({ ... });
+export const resolveThreadSchema = z.object({ candidateId: z.number().int().positive() });
+```
+
+From src/shared/types.ts (add new type):
+```typescript
+export type ResolveThread = z.infer<typeof resolveThreadSchema>;
+// Add: export type ReorderCandidates = z.infer<typeof reorderCandidatesSchema>;
+```
+
+From src/server/routes/threads.ts (route pattern):
+```typescript
+type Env = { Variables: { db?: any } };
+const app = new Hono<Env>();
+// Pattern: app.post("/:id/resolve", zValidator("json", resolveThreadSchema), (c) => { ... });
+```
+
+From src/client/lib/api.ts:
+```typescript
+export async function apiPatch<T>(url: string, body: unknown): Promise<T>;
+```
+
+From tests/helpers/db.ts (thread_candidates CREATE TABLE — add sort_order):
+```sql
+CREATE TABLE thread_candidates (
+  id INTEGER PRIMARY KEY AUTOINCREMENT,
+  thread_id INTEGER NOT NULL REFERENCES threads(id) ON DELETE CASCADE,
+  name TEXT NOT NULL,
+  weight_grams REAL,
+  price_cents INTEGER,
+  category_id INTEGER NOT NULL REFERENCES categories(id),
+  notes TEXT,
+  product_url TEXT,
+  image_filename TEXT,
+  status TEXT NOT NULL DEFAULT 'researching',
+  pros TEXT,
+  cons TEXT,
+  created_at INTEGER NOT NULL DEFAULT (unixepoch()),
+  updated_at INTEGER NOT NULL DEFAULT (unixepoch())
+)
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: Schema, migration, service layer, and tests for sort_order + reorder</name>
+  <files>src/db/schema.ts, tests/helpers/db.ts, src/server/services/thread.service.ts, src/shared/schemas.ts, src/shared/types.ts, tests/services/thread.service.test.ts</files>
+  <behavior>
+    - Test: getThreadWithCandidates returns candidates ordered by sort_order ascending (create 3 candidates with different sort_orders, verify order)
+    - Test: reorderCandidates(db, threadId, [id3, id1, id2]) updates sort_order so querying returns [id3, id1, id2]
+    - Test: reorderCandidates returns { success: false, error } when thread status is "resolved"
+    - Test: createCandidate assigns sort_order = max existing sort_order + 1000 (first candidate gets 1000, second gets 2000)
+    - Test: reorderCandidates returns { success: false } when thread does not exist
+  </behavior>
+  <action>
+    1. **Schema** (`src/db/schema.ts`): Add `sortOrder: real("sort_order").notNull().default(0)` to the `threadCandidates` table definition.
+
+    2. **Migration**: Run `bun run db:generate` to produce the Drizzle migration SQL. Then apply it with `bun run db:push`. After applying, run a data backfill to space existing candidates:
+       ```sql
+       UPDATE thread_candidates SET sort_order = (
+         SELECT (ROW_NUMBER() OVER (PARTITION BY thread_id ORDER BY created_at)) * 1000
+         FROM thread_candidates AS tc2 WHERE tc2.id = thread_candidates.id
+       );
+       ```
+       Execute this backfill via the Drizzle migration custom SQL or a small script.
+
+    3. **Test helper** (`tests/helpers/db.ts`): Add `sort_order REAL NOT NULL DEFAULT 0` to the CREATE TABLE thread_candidates statement (after the `cons TEXT` line, before `created_at`).
+
+    4. **Zod schema** (`src/shared/schemas.ts`): Add:
+       ```typescript
+       export const reorderCandidatesSchema = z.object({
+         orderedIds: z.array(z.number().int().positive()).min(1),
+       });
+       ```
+
+    5. **Types** (`src/shared/types.ts`): Add import of `reorderCandidatesSchema` and:
+       ```typescript
+       export type ReorderCandidates = z.infer<typeof reorderCandidatesSchema>;
+       ```
+
+    6. **Service** (`src/server/services/thread.service.ts`):
+       - In `getThreadWithCandidates`: Add `.orderBy(threadCandidates.sortOrder)` to the candidateList query (after `.where()`).
+       - In `createCandidate`: Before inserting, query `MAX(sort_order)` from threadCandidates where threadId matches. Set `sortOrder: (maxRow?.maxOrder ?? 0) + 1000` in the `.values()` call. Use `sql<number>` template for the MAX query.
+       - Add new exported function `reorderCandidates(db, threadId, orderedIds)`:
+         - Wrap in `db.transaction()`.
+         - Verify thread exists and `status === "active"` (return `{ success: false, error: "Thread not active" }` if not).
+         - Loop through `orderedIds`, UPDATE each candidate's `sortOrder` to `(index + 1) * 1000`.
+         - Return `{ success: true }`.
+
+    7. **Tests** (`tests/services/thread.service.test.ts`):
+       - Import `reorderCandidates` from the service.
+       - Add a new `describe("reorderCandidates", () => { ... })` block with the behavior tests listed above.
+       - Add test for `getThreadWithCandidates` ordering by sort_order (create candidates, set different sort_orders manually via db, verify order).
+       - Add test for `createCandidate` sort_order appending.
+  </action>
+  <verify>
+    <automated>bun test tests/services/thread.service.test.ts</automated>
+  </verify>
+  <done>All existing thread service tests pass (28+) plus 5+ new tests for reorderCandidates, sort_order ordering, sort_order appending. sortOrder column exists in schema with REAL type.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Task 2: PATCH reorder route + route tests</name>
+  <files>src/server/routes/threads.ts, tests/routes/threads.test.ts</files>
+  <behavior>
+    - Test: PATCH /api/threads/:id/candidates/reorder with valid orderedIds returns 200 + { success: true }
+    - Test: After PATCH reorder, GET /api/threads/:id returns candidates in the new order
+    - Test: PATCH /api/threads/:id/candidates/reorder on a resolved thread returns 400
+    - Test: PATCH /api/threads/:id/candidates/reorder with empty body returns 400 (Zod validation)
+  </behavior>
+  <action>
+    1. **Route** (`src/server/routes/threads.ts`):
+       - Import `reorderCandidatesSchema` from `../../shared/schemas.ts`.
+       - Import `reorderCandidates` from `../services/thread.service.ts`.
+       - Add PATCH route BEFORE the resolution route (to avoid param conflicts):
+         ```typescript
+         app.patch(
+           "/:id/candidates/reorder",
+           zValidator("json", reorderCandidatesSchema),
+           (c) => {
+             const db = c.get("db");
+             const threadId = Number(c.req.param("id"));
+             const { orderedIds } = c.req.valid("json");
+             const result = reorderCandidates(db, threadId, orderedIds);
+             if (!result.success) return c.json({ error: result.error }, 400);
+             return c.json({ success: true });
+           },
+         );
+         ```
+
+    2. **Route tests** (`tests/routes/threads.test.ts`):
+       - Add a new `describe("PATCH /api/threads/:id/candidates/reorder", () => { ... })` block.
+       - Test: Create a thread with 3 candidates via API, PATCH reorder with reversed IDs, GET thread and verify candidates array is in the new order.
+       - Test: Resolve a thread, then PATCH reorder returns 400.
+       - Test: PATCH with invalid body (empty orderedIds array or missing field) returns 400.
+  </action>
+  <verify>
+    <automated>bun test tests/routes/threads.test.ts</automated>
+  </verify>
+  <done>PATCH /api/threads/:id/candidates/reorder returns 200 on active thread + persists order. Returns 400 on resolved thread. All existing route tests still pass.</done>
+</task>
+
+</tasks>
+
+<verification>
+```bash
+# Full test suite — all existing + new tests green
+bun test
+
+# Verify sort_order column exists in schema
+grep -n "sortOrder" src/db/schema.ts
+
+# Verify reorder endpoint registered
+grep -n "candidates/reorder" src/server/routes/threads.ts
+
+# Verify test helper updated
+grep -n "sort_order" tests/helpers/db.ts
+```
+</verification>
+
+<success_criteria>
+- sort_order REAL column added to threadCandidates schema and test helper
+- getThreadWithCandidates returns candidates sorted by sort_order ascending
+- createCandidate appends new candidates at max sort_order + 1000
+- reorderCandidates service function updates sort_order in transaction, rejects resolved threads
+- PATCH /api/threads/:id/candidates/reorder validated with Zod, returns 200/400 correctly
+- All existing tests pass with zero regressions + 8+ new tests
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/11-candidate-ranking/11-01-SUMMARY.md`
+</output>

.planning/phases/11-candidate-ranking/11-01-SUMMARY.md

@@ -0,0 +1,117 @@
+---
+phase: 11-candidate-ranking
+plan: "01"
+subsystem: database, api
+tags: [drizzle, sqlite, hono, zod, sort-order, reorder, candidates]
+
+# Dependency graph
+requires: []
+provides:
+  - sortOrder REAL column on threadCandidates with default 0
+  - reorderCandidates service function (transaction, active-only guard)
+  - PATCH /api/threads/:id/candidates/reorder endpoint with Zod validation
+  - getThreadWithCandidates returns candidates ordered by sort_order ASC
+  - createCandidate appends at max sort_order + 1000 (first=1000, second=2000)
+  - reorderCandidatesSchema Zod validator in shared/schemas.ts
+  - ReorderCandidates type in shared/types.ts
+affects: [11-02, frontend-drag-reorder, candidate-lists]
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns:
+    - "Append-at-end sort_order: query MAX(sort_order), insert at +1000 gap"
+    - "Reorder transaction pattern: verify active thread, loop UPDATE sort_order = (index+1)*1000"
+    - "Active-only guard in reorder: return { success: false, error } when thread status != active"
+
+key-files:
+  created:
+    - drizzle/0005_clear_micromax.sql
+    - drizzle/meta/0005_snapshot.json
+  modified:
+    - src/db/schema.ts
+    - tests/helpers/db.ts
+    - src/shared/schemas.ts
+    - src/shared/types.ts
+    - src/server/services/thread.service.ts
+    - src/server/routes/threads.ts
+    - tests/services/thread.service.test.ts
+    - tests/routes/threads.test.ts
+
+key-decisions:
+  - "sortOrder uses REAL type (not INTEGER) to allow fractional values for future midpoint insertions without bulk rewrites"
+  - "First candidate gets sort_order=1000, subsequent at +1000 gaps, giving room for future insertions"
+  - "reorderCandidates uses (index+1)*1000 to space out assignments and reset gaps after each reorder"
+  - "Applied migration directly via sqlite3 CLI + data backfill instead of db:push (avoided data-loss warning on existing rows)"
+
+patterns-established:
+  - "Reorder endpoint pattern: PATCH /:id/candidates/reorder, Zod validates orderedIds array, service returns {success, error}"
+  - "Service active-only guard: check thread.status !== 'active', return {success: false, error: 'Thread not active'}"
+
+requirements-completed: [RANK-01, RANK-04, RANK-05]
+
+# Metrics
+duration: 4min
+completed: 2026-03-16
+---
+
+# Phase 11 Plan 01: Candidate Ranking Backend Summary
+
+**sortOrder REAL column, reorderCandidates transaction service, and PATCH /api/threads/:id/candidates/reorder endpoint with active-thread guard**
+
+## Performance
+
+- **Duration:** ~4 min
+- **Started:** 2026-03-16T21:19:26Z
+- **Completed:** 2026-03-16T21:22:46Z
+- **Tasks:** 2 of 2
+- **Files modified:** 8
+
+## Accomplishments
+- Added sortOrder REAL column to threadCandidates with 1000-gap append strategy
+- Implemented reorderCandidates service with transaction and active-thread guard
+- Added PATCH /api/threads/:id/candidates/reorder endpoint with Zod validation
+- getThreadWithCandidates now orders candidates by sort_order ASC
+- 10 new tests (5 service + 5 route) added; all 135 tests pass with zero regressions
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Schema, migration, service layer, and tests for sort_order + reorder** - `f01d71d` (feat)
+2. **Task 2: PATCH reorder route + route tests** - `d6acfcb` (feat)
+
+_Note: TDD tasks each committed after GREEN phase._
+
+## Files Created/Modified
+- `src/db/schema.ts` - Added sortOrder REAL column to threadCandidates
+- `tests/helpers/db.ts` - Added sort_order REAL NOT NULL DEFAULT 0 to CREATE TABLE
+- `src/shared/schemas.ts` - Added reorderCandidatesSchema
+- `src/shared/types.ts` - Added ReorderCandidates type, imported reorderCandidatesSchema
+- `src/server/services/thread.service.ts` - Added reorderCandidates, updated createCandidate + getThreadWithCandidates
+- `src/server/routes/threads.ts` - Added PATCH /:id/candidates/reorder route
+- `tests/services/thread.service.test.ts` - Added 5 new tests for sort_order behavior
+- `tests/routes/threads.test.ts` - Added 5 new route tests for reorder endpoint
+- `drizzle/0005_clear_micromax.sql` - Generated migration SQL for sort_order column
+- `drizzle/meta/0005_snapshot.json` - Drizzle schema snapshot
+
+## Decisions Made
+- Used REAL type for sort_order (not INTEGER) to allow fractional values for future midpoint insertions
+- 1000-gap strategy: first candidate = 1000, each subsequent += 1000; reorder resets to (index+1)*1000
+- Applied migration directly via sqlite3 CLI to avoid Drizzle's data-loss warning on existing rows (db had 2 rows; column has DEFAULT 0 so no actual data loss)
+- Backfilled existing candidates with ROW_NUMBER * 1000 per thread to give proper initial ordering
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+- `bun run db:push` showed data-loss warning for adding NOT NULL column to existing rows. Applied the migration directly via sqlite3 CLI instead (`ALTER TABLE thread_candidates ADD COLUMN sort_order REAL NOT NULL DEFAULT 0`). The column has DEFAULT 0 so no actual data loss; existing rows got 0 then were backfilled to proper 1000-gap values.
+
+## Next Phase Readiness
+- Backend reorder API fully operational; frontend drag-to-reorder (11-02) can now consume PATCH /api/threads/:id/candidates/reorder
+- sort_order values returned in getThreadWithCandidates response, available to frontend for drag state initialization
+
+---
+*Phase: 11-candidate-ranking*
+*Completed: 2026-03-16*

.planning/phases/11-candidate-ranking/11-02-PLAN.md

@@ -0,0 +1,378 @@
+---
+phase: 11-candidate-ranking
+plan: "02"
+type: execute
+wave: 2
+depends_on: ["11-01"]
+files_modified:
+  - src/client/stores/uiStore.ts
+  - src/client/hooks/useCandidates.ts
+  - src/client/components/CandidateListItem.tsx
+  - src/client/components/CandidateCard.tsx
+  - src/client/routes/threads/$threadId.tsx
+autonomous: false
+requirements: [RANK-01, RANK-02, RANK-04, RANK-05]
+
+must_haves:
+  truths:
+    - "User can drag a candidate card to a new position in list view and it persists after page refresh"
+    - "Top 3 candidates display gold, silver, and bronze medal badges"
+    - "Rank badges appear in both list view and grid view"
+    - "Drag handles are hidden and drag is disabled on resolved threads"
+    - "Rank badges remain visible on resolved threads"
+    - "User can toggle between list and grid view"
+    - "List view is the default view"
+  artifacts:
+    - path: "src/client/components/CandidateListItem.tsx"
+      provides: "Horizontal list-view candidate card with drag handle and rank badge"
+      min_lines: 60
+    - path: "src/client/routes/threads/$threadId.tsx"
+      provides: "View toggle + Reorder.Group wrapping candidates + tempItems flicker prevention"
+      contains: "Reorder.Group"
+    - path: "src/client/hooks/useCandidates.ts"
+      provides: "useReorderCandidates mutation hook"
+      contains: "useReorderCandidates"
+    - path: "src/client/stores/uiStore.ts"
+      provides: "candidateViewMode state"
+      contains: "candidateViewMode"
+    - path: "src/client/components/CandidateCard.tsx"
+      provides: "Rank badge on grid-view cards"
+      contains: "RankBadge"
+  key_links:
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/hooks/useCandidates.ts"
+      via: "useReorderCandidates(threadId)"
+      pattern: "useReorderCandidates"
+    - from: "src/client/hooks/useCandidates.ts"
+      to: "/api/threads/:id/candidates/reorder"
+      via: "apiPatch"
+      pattern: "apiPatch.*candidates/reorder"
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "framer-motion"
+      via: "Reorder.Group + Reorder.Item"
+      pattern: "Reorder\\.Group"
+    - from: "src/client/components/CandidateListItem.tsx"
+      to: "framer-motion"
+      via: "Reorder.Item + useDragControls"
+      pattern: "useDragControls"
+    - from: "src/client/stores/uiStore.ts"
+      to: "src/client/routes/threads/$threadId.tsx"
+      via: "candidateViewMode state"
+      pattern: "candidateViewMode"
+---
+
+<objective>
+Build the drag-to-reorder UI with list/grid view toggle, CandidateListItem component, framer-motion Reorder integration, rank badges, and resolved-thread guard.
+
+Purpose: Delivers the user-facing ranking experience: drag candidates to prioritize, see gold/silver/bronze medals, toggle between compact list and card grid views. All four RANK requirements are covered.
+Output: Working drag-to-reorder in list view, rank badges in both views, view toggle, resolved-thread readonly mode.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/11-candidate-ranking/11-CONTEXT.md
+@.planning/phases/11-candidate-ranking/11-RESEARCH.md
+@.planning/phases/11-candidate-ranking/11-01-SUMMARY.md
+
+<interfaces>
+<!-- Interfaces created by Plan 01 that this plan depends on -->
+
+From src/shared/schemas.ts (created in 11-01):
+```typescript
+export const reorderCandidatesSchema = z.object({
+  orderedIds: z.array(z.number().int().positive()).min(1),
+});
+```
+
+From src/shared/types.ts (created in 11-01):
+```typescript
+export type ReorderCandidates = z.infer<typeof reorderCandidatesSchema>;
+```
+
+From src/server/services/thread.service.ts (modified in 11-01):
+```typescript
+export function reorderCandidates(db, threadId, orderedIds): { success: boolean; error?: string }
+// getThreadWithCandidates now returns candidates sorted by sort_order ascending
+// createCandidate now assigns sort_order = max + 1000 (appends to bottom)
+```
+
+API endpoint (created in 11-01):
+```
+PATCH /api/threads/:id/candidates/reorder
+Body: { orderedIds: number[] }
+Response: { success: true } | { error: string } (400)
+```
+
+From src/client/lib/api.ts:
+```typescript
+export async function apiPatch<T>(url: string, body: unknown): Promise<T>;
+```
+
+From src/client/hooks/useCandidates.ts (existing):
+```typescript
+interface CandidateResponse {
+  id: number; threadId: number; name: string;
+  weightGrams: number | null; priceCents: number | null;
+  categoryId: number; notes: string | null; productUrl: string | null;
+  imageFilename: string | null; status: "researching" | "ordered" | "arrived";
+  pros: string | null; cons: string | null;
+  createdAt: string; updatedAt: string;
+}
+```
+
+From src/client/components/CandidateCard.tsx (existing props):
+```typescript
+interface CandidateCardProps {
+  id: number; name: string; weightGrams: number | null; priceCents: number | null;
+  categoryName: string; categoryIcon: string; imageFilename: string | null;
+  productUrl?: string | null; threadId: number; isActive: boolean;
+  status: "researching" | "ordered" | "arrived";
+  onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+  pros?: string | null; cons?: string | null;
+}
+```
+
+From src/client/stores/uiStore.ts (existing patterns):
+```typescript
+interface UIState {
+  // ... existing state
+  // Add: candidateViewMode: "list" | "grid"
+  // Add: setCandidateViewMode: (mode: "list" | "grid") => void
+}
+```
+
+From framer-motion (installed v12.37.0):
+```typescript
+import { Reorder, useDragControls } from "framer-motion";
+// Reorder.Group: axis="y", values={items}, onReorder={setItems}
+// Reorder.Item: value={item}, dragControls={controls}, dragListener={false}
+// useDragControls: controls.start(pointerEvent) on handle's onPointerDown
+```
+
+From lucide-react (confirmed available icons):
+- grip-vertical (drag handle)
+- medal (rank badge)
+- layout-list (list view toggle)
+- layout-grid (grid view toggle)
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: useReorderCandidates hook + uiStore view mode + CandidateListItem component</name>
+  <files>src/client/hooks/useCandidates.ts, src/client/stores/uiStore.ts, src/client/components/CandidateListItem.tsx</files>
+  <action>
+    1. **useReorderCandidates hook** (`src/client/hooks/useCandidates.ts`):
+       - Import `apiPatch` from `../lib/api`.
+       - Add new exported function:
+         ```typescript
+         export function useReorderCandidates(threadId: number) {
+           const queryClient = useQueryClient();
+           return useMutation({
+             mutationFn: (data: { orderedIds: number[] }) =>
+               apiPatch<{ success: boolean }>(
+                 `/api/threads/${threadId}/candidates/reorder`,
+                 data,
+               ),
+             onSettled: () => {
+               queryClient.invalidateQueries({ queryKey: ["threads", threadId] });
+             },
+           });
+         }
+         ```
+
+    2. **uiStore** (`src/client/stores/uiStore.ts`):
+       - Add to the UIState interface:
+         ```typescript
+         candidateViewMode: "list" | "grid";
+         setCandidateViewMode: (mode: "list" | "grid") => void;
+         ```
+       - Add to the create block:
+         ```typescript
+         candidateViewMode: "list",
+         setCandidateViewMode: (mode) => set({ candidateViewMode: mode }),
+         ```
+
+    3. **CandidateListItem** (`src/client/components/CandidateListItem.tsx`) — NEW FILE:
+       - Create a horizontal card component for list view.
+       - Import `{ Reorder, useDragControls }` from `framer-motion`.
+       - Import `LucideIcon` from `../lib/iconData`, formatters, hooks (useWeightUnit, useCurrency), useUIStore, StatusBadge.
+       - Props interface:
+         ```typescript
+         interface CandidateListItemProps {
+           candidate: CandidateWithCategory;  // The full candidate object from thread.candidates
+           rank: number;                      // 1-based position index
+           isActive: boolean;                 // thread.status === "active"
+           onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+         }
+         ```
+         Where `CandidateWithCategory` is the candidate shape from `useThread` response (id, name, weightGrams, priceCents, categoryName, categoryIcon, imageFilename, productUrl, status, pros, cons, etc.). Define this type locally or reference the CandidateResponse + category fields.
+
+       - Use `useDragControls()` hook. Return a `Reorder.Item` with `value={candidate}` (the full candidate object, same reference used in Reorder.Group values), `dragControls={controls}`, `dragListener={false}`.
+
+       - Layout (horizontal card):
+         - Outer: `flex items-center gap-3 bg-white rounded-xl border border-gray-100 p-3 hover:border-gray-200 hover:shadow-sm transition-all group`
+         - LEFT: Drag handle (only if `isActive`): GripVertical icon (size 16), `onPointerDown={(e) => controls.start(e)}`, classes: `cursor-grab active:cursor-grabbing text-gray-300 hover:text-gray-500 touch-none shrink-0`
+         - RANK BADGE: Inline `RankBadge` component (see below). Shows medal icon for rank 1-3 with gold/silver/bronze colors. Returns null for rank > 3.
+         - IMAGE THUMBNAIL: 48x48 rounded-lg overflow-hidden shrink-0. If `imageFilename`, show `<img src="/uploads/${imageFilename}" />` with object-cover. Else show `LucideIcon` of `categoryIcon` (size 20) in gray on gray-50 background.
+         - NAME + BADGES: `flex-1 min-w-0` container.
+           - Name: `text-sm font-semibold text-gray-900 truncate`
+           - Badge row: `flex flex-wrap gap-1.5 mt-1` with weight (blue), price (green), category (gray + icon), StatusBadge, pros/cons badge (purple "+/- Notes").
+           - Use same badge pill classes as CandidateCard.
+         - ACTION BUTTONS (hover-reveal, right side): Winner (if isActive), Delete, External link (if productUrl). Use same click handlers as CandidateCard (openResolveDialog, openConfirmDeleteCandidate, openExternalLink from uiStore). Classes: `opacity-0 group-hover:opacity-100 transition-opacity` on a flex container.
+         - Clicking the card body (not handle or action buttons) opens the edit panel: wrap in a clickable area that calls `openCandidateEditPanel(candidate.id)`.
+
+       - **RankBadge** (inline helper or small component in same file):
+         ```typescript
+         const RANK_COLORS = ["#D4AF37", "#C0C0C0", "#CD7F32"]; // gold, silver, bronze
+         function RankBadge({ rank }: { rank: number }) {
+           if (rank > 3) return null;
+           return <LucideIcon name="medal" size={16} className="shrink-0" style={{ color: RANK_COLORS[rank - 1] }} />;
+         }
+         ```
+         Export `RankBadge` so it can be reused by CandidateCard in grid view.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint 2>&1 | head -30</automated>
+  </verify>
+  <done>CandidateListItem.tsx created with drag handle, rank badge, horizontal layout. useReorderCandidates hook created. uiStore has candidateViewMode. RankBadge exported. Lint passes.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Thread detail page with view toggle, Reorder.Group, rank badges in grid view</name>
+  <files>src/client/routes/threads/$threadId.tsx, src/client/components/CandidateCard.tsx</files>
+  <action>
+    1. **CandidateCard rank badge** (`src/client/components/CandidateCard.tsx`):
+       - Import `RankBadge` from `./CandidateListItem` (or wherever it's exported).
+       - Add `rank?: number` to `CandidateCardProps`.
+       - In the card layout, add `{rank != null && <RankBadge rank={rank} />}` in the badge row (flex-wrap area), positioned as the first badge before weight/price.
+
+    2. **Thread detail page** (`src/client/routes/threads/$threadId.tsx`):
+       - Import `{ Reorder }` from `framer-motion`.
+       - Import `{ useState, useEffect }` from `react`.
+       - Import `CandidateListItem` from `../../components/CandidateListItem`.
+       - Import `useReorderCandidates` from `../../hooks/useCandidates`.
+       - Import `useUIStore` selector for `candidateViewMode` and `setCandidateViewMode`.
+       - Import `LucideIcon` (already imported).
+
+       - **View toggle** in the header area (after the "Add Candidate" button, or in the thread header row):
+         - Two icon buttons: LayoutList and LayoutGrid (from Lucide).
+         - Active button has `bg-gray-200 text-gray-900`, inactive has `text-gray-400 hover:text-gray-600`.
+         - `onClick` calls `setCandidateViewMode("list")` or `setCandidateViewMode("grid")`.
+         - Placed inline in a small toggle group: `flex items-center gap-1 bg-gray-100 rounded-lg p-0.5`
+
+       - **tempItems pattern** for flicker prevention:
+         ```typescript
+         const [tempItems, setTempItems] = useState<typeof thread.candidates | null>(null);
+         const displayItems = tempItems ?? thread.candidates;
+         // thread.candidates is already sorted by sort_order from server (11-01)
+         ```
+         Reset tempItems to null whenever `thread.candidates` reference changes (use useEffect if needed, or rely on onSettled clearing).
+
+       - **Reorder.Group** (list view, active threads only):
+         - When `candidateViewMode === "list"` AND candidates exist:
+           - If `isActive`: Wrap candidates in `<Reorder.Group axis="y" values={displayItems} onReorder={setTempItems} className="flex flex-col gap-2">`.
+             - Each candidate renders `<CandidateListItem key={candidate.id} candidate={candidate} rank={index + 1} isActive={isActive} onStatusChange={...} />`.
+             - On Reorder.Item `onDragEnd`, trigger the save. The save function:
+               ```typescript
+               function handleDragEnd() {
+                 if (!tempItems) return;
+                 reorderMutation.mutate(
+                   { orderedIds: tempItems.map((c) => c.id) },
+                   { onSettled: () => setTempItems(null) }
+                 );
+               }
+               ```
+               Attach this to `Reorder.Group` via a wrapper that uses `onPointerUp` or pass as prop to `CandidateListItem`. The cleanest approach: use framer-motion's `onDragEnd` prop on each `Reorder.Item` — when any item finishes dragging, if tempItems differs from server data, fire the mutation.
+           - If `!isActive` (resolved): Render the same `CandidateListItem` components but WITHOUT `Reorder.Group` — just a plain `<div className="flex flex-col gap-2">`. The `isActive={false}` prop hides drag handles. Rank badges remain visible per user decision.
+
+         - When `candidateViewMode === "grid"` AND candidates exist:
+           - Render the existing `<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-4">` with `CandidateCard` components.
+           - Pass `rank={index + 1}` to each CandidateCard so rank badges appear in grid view too.
+           - Both active and resolved threads use static grid (no drag in grid view per user decision).
+
+       - **Important framer-motion detail**: `Reorder.Group` `values` must be the same array reference as what you iterate. Use `displayItems` for both `values` and `.map()`. The `Reorder.Item` `value` must be the same object reference (not a copy). Since we use the full candidate object, `value={candidate}` where candidate comes from `displayItems.map(...)`.
+
+       - **Empty state**: Keep the existing empty state rendering for both views.
+
+       - **useEffect to clear tempItems**: When `thread.candidates` changes (new data from server), clear tempItems:
+         ```typescript
+         useEffect(() => {
+           setTempItems(null);
+         }, [thread?.candidates]);
+         ```
+         This ensures that when React Query refetches, tempItems is cleared and we render fresh server data.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint 2>&1 | head -30</automated>
+  </verify>
+  <done>Thread detail page renders list/grid toggle. List view has drag-to-reorder via Reorder.Group with tempItems flicker prevention. Grid view shows rank badges. Resolved threads show static list/grid with rank badges but no drag handles. Lint passes.</done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <name>Task 3: Verify drag-to-reorder ranking experience</name>
+  <files>none</files>
+  <action>
+    Human verifies the complete drag-to-reorder candidate ranking with list/grid view toggle, rank badges (gold/silver/bronze), auto-save persistence, and resolved thread guard.
+  </action>
+  <what-built>Complete drag-to-reorder candidate ranking with list/grid view toggle, rank badges (gold/silver/bronze), auto-save persistence, and resolved thread guard.</what-built>
+  <how-to-verify>
+    1. Start dev servers: `bun run dev:client` and `bun run dev:server`
+    2. Navigate to an existing active thread with 3+ candidates (or create one)
+    3. Verify list view is the default (vertical stack of horizontal cards)
+    4. Verify drag handles (grip icon) appear on the left of each card
+    5. Drag a candidate to a new position — verify it moves smoothly with gap animation
+    6. Release — verify the new order persists (refresh the page to confirm)
+    7. Verify the top 3 candidates show gold, silver, bronze medal icons before their names
+    8. Toggle to grid view — verify rank badges also appear on grid cards
+    9. Toggle back to list view — verify drag still works
+    10. Navigate to a resolved thread — verify NO drag handles, but rank badges ARE visible
+    11. Verify candidates on resolved thread render in their ranked order (static)
+  </how-to-verify>
+  <verify>Human confirms all 11 verification steps pass</verify>
+  <done>All ranking features verified: drag reorder works, persists, shows rank badges in both views, disabled on resolved threads</done>
+  <resume-signal>Type "approved" or describe any issues</resume-signal>
+</task>
+
+</tasks>
+
+<verification>
+```bash
+# Full test suite green
+bun test
+
+# Verify all key files exist
+ls src/client/components/CandidateListItem.tsx
+grep -n "useReorderCandidates" src/client/hooks/useCandidates.ts
+grep -n "candidateViewMode" src/client/stores/uiStore.ts
+grep -n "Reorder.Group" src/client/routes/threads/\$threadId.tsx
+grep -n "RankBadge" src/client/components/CandidateCard.tsx
+
+# Lint clean
+bun run lint
+```
+</verification>
+
+<success_criteria>
+- List view shows horizontal cards with drag handles on active threads
+- Drag-to-reorder works via framer-motion Reorder.Group with grip handle
+- Order persists after page refresh via PATCH /api/threads/:id/candidates/reorder
+- tempItems pattern prevents React Query flicker
+- Top 3 candidates display gold (#D4AF37), silver (#C0C0C0), bronze (#CD7F32) medal badges
+- Rank badges visible in both list and grid views
+- Grid/list toggle works with list as default
+- Resolved threads: no drag handles, rank badges visible, static order
+- All tests pass, lint clean
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/11-candidate-ranking/11-02-SUMMARY.md`
+</output>

.planning/phases/11-candidate-ranking/11-02-SUMMARY.md

@@ -0,0 +1,85 @@
+---
+phase: 11-candidate-ranking
+plan: "02"
+subsystem: client-ui
+tags: [drag-reorder, framer-motion, rank-badges, view-toggle, list-view]
+dependency_graph:
+  requires: [11-01]
+  provides: [drag-to-reorder-ui, rank-badges, list-grid-toggle]
+  affects: [threads/$threadId.tsx, CandidateCard, CandidateListItem, uiStore, useCandidates]
+tech_stack:
+  added: []
+  patterns:
+    - framer-motion Reorder.Group + Reorder.Item with useDragControls for drag handle
+    - tempItems pattern to prevent React Query flicker during optimistic drag
+    - RankBadge exported from CandidateListItem for reuse across views
+    - candidateViewMode in uiStore for list/grid toggle state
+key_files:
+  created:
+    - src/client/components/CandidateListItem.tsx
+  modified:
+    - src/client/hooks/useCandidates.ts
+    - src/client/stores/uiStore.ts
+    - src/client/components/CandidateCard.tsx
+    - src/client/routes/threads/$threadId.tsx
+    - src/client/lib/iconData.tsx
+    - src/client/hooks/useThreads.ts
+decisions:
+  - Resolved thread list view uses plain div (not Reorder.Group) — no drag, rank badges visible
+  - handleDragEnd fires on Reorder.Group onPointerUp to debounce reorder API call
+  - biome-ignore applied to useExhaustiveDependencies for thread?.candidates dep — intentional trigger
+metrics:
+  duration: 4min
+  completed: 2026-03-16T21:29:07Z
+  tasks_completed: 3
+  files_changed: 7
+---
+
+# Phase 11 Plan 02: Drag-to-Reorder UI Summary
+
+Drag-to-reorder candidate ranking with list/grid view toggle, gold/silver/bronze rank badges, and framer-motion Reorder.Group with tempItems flicker prevention.
+
+## What Was Built
+
+### Task 1: useReorderCandidates hook + uiStore view mode + CandidateListItem component
+- Added `useReorderCandidates` mutation hook to `useCandidates.ts` using `apiPatch` to hit `PATCH /api/threads/:id/candidates/reorder`
+- Added `candidateViewMode: "list" | "grid"` and `setCandidateViewMode` to `uiStore.ts`
+- Created `CandidateListItem.tsx` — horizontal card for list view with drag handle (GripVertical), RankBadge (medal icon), 48x48 image thumbnail, badge row (weight/price/category/status/pros-cons), and hover-reveal action buttons
+- Exported `RankBadge` component (gold `#D4AF37`, silver `#C0C0C0`, bronze `#CD7F32`) for reuse
+- Added `style` prop support to `LucideIcon` for colored medal icons
+- Added `pros` and `cons` fields to `CandidateWithCategory` in `useThreads.ts` (Rule 2 auto-fix — missing after Phase 10)
+
+### Task 2: Thread detail page with view toggle, Reorder.Group, rank badges in grid view
+- Updated `CandidateCard.tsx`: added `rank?: number` prop and renders `<RankBadge rank={rank} />` in badge row
+- Updated `threads/$threadId.tsx`:
+  - List/grid view toggle (LayoutList / LayoutGrid icons) using `candidateViewMode` from uiStore
+  - Active list view: `<Reorder.Group>` wrapping `<CandidateListItem>` instances for drag-to-reorder
+  - Resolved list view: plain `<div>` with `<CandidateListItem isActive={false}>` — rank badges visible, drag handles hidden
+  - Grid view: existing `<CandidateCard>` grid with `rank={index + 1}` passed to each card
+  - `tempItems` state: holds in-progress drag order, falls back to `thread.candidates` when null
+  - `handleDragEnd`: fires `reorderMutation.mutate({ orderedIds })` and clears tempItems on settled
+  - `useEffect` clears tempItems when `thread?.candidates` reference changes (fresh server data)
+
+### Task 3: Human verification (auto-approved — auto_chain_active)
+
+## Deviations from Plan
+
+### Auto-fixed Issues
+
+**1. [Rule 2 - Missing] Added pros/cons fields to CandidateWithCategory in useThreads.ts**
+- **Found during:** Task 1 (needed by CandidateListItem)
+- **Issue:** `CandidateWithCategory` interface in `useThreads.ts` was missing `pros` and `cons` fields added in Phase 10. CandidateListItem needed these to render the "+/- Notes" badge.
+- **Fix:** Added `pros: string | null` and `cons: string | null` to the interface
+- **Files modified:** `src/client/hooks/useThreads.ts`
+- **Commit:** acfa995
+
+**2. [Rule 2 - Missing] Added style prop to LucideIcon component**
+- **Found during:** Task 1 (needed by RankBadge for medal colors)
+- **Issue:** LucideIcon only accepted `className` for styling; RankBadge needed inline `style={{ color }}` for gold/silver/bronze hex colors not achievable via Tailwind
+- **Fix:** Added optional `style?: React.CSSProperties` prop to LucideIcon and passed through to icon component
+- **Files modified:** `src/client/lib/iconData.tsx`
+- **Commit:** acfa995
+
+## Self-Check: PASSED
+
+All created/modified files exist. Both task commits (acfa995, 94c07e7) confirmed in git log.

.planning/phases/11-candidate-ranking/11-CONTEXT.md

@@ -0,0 +1,107 @@
+# Phase 11: Candidate Ranking - Context
+
+**Gathered:** 2026-03-16
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Users can drag candidates into a priority order within a thread. The rank persists across sessions and is visually communicated with medal badges on the top 3. Drag handles and reordering are disabled on resolved threads. Comparison view, impact preview, and pros/cons editing are separate phases.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Card layout and view toggle
+- Add a grid/list view toggle in the thread header (list view is default)
+- List view: vertical stack of horizontal cards (image thumbnail on left, name + badges on right) — enables drag-to-reorder
+- Grid view: current 3-column responsive card layout preserved
+- Both views render candidates in rank order (sort_order ascending)
+- Rank badges visible in both views
+
+### Drag handle design
+- Always-visible GripVertical icon (Lucide) on the left side of each list-view card
+- Grip icon color: muted gray (text-gray-300), darkens to text-gray-500 on hover
+- Cursor changes to 'grab' on hover, 'grabbing' during drag
+- Drag feedback: elevated card with shadow + scale-up effect; other cards animate to show drop target gap (standard framer-motion Reorder behavior)
+- On resolved threads: grip icon disappears entirely (not disabled/grayed)
+- Drag only available in list view (grid view has no drag handles)
+
+### Rank badge style
+- Medal icons (Lucide 'medal' or 'trophy') in gold (#D4AF37), silver (#C0C0C0), bronze (#CD7F32) for top 3 candidates
+- Positioned inline before the candidate name text
+- Candidates ranked 4th and below show no rank indicator — position implied by list order
+- On resolved threads: rank badges remain visible (static, read-only) — **overrides roadmap success criteria #4 which said "rank badges absent on resolved thread"**; user prefers retrospective visibility
+
+### Sort order and persistence
+- Schema migration adds `sort_order REAL NOT NULL DEFAULT 0` to `thread_candidates`
+- Migration initializes existing candidates with spaced values (1000, 2000, 3000...) ordered by `created_at` — ensures immediate correct ordering
+- Fractional indexing: only the moved item gets a single UPDATE (midpoint between neighbors)
+- New candidates added to a thread get the highest sort_order (appended to bottom of rank)
+- Auto-save on drop — no "Save order" button; reorder persists immediately via `PATCH /api/threads/:id/candidates/reorder`
+- `tempItems` local state pattern: render from `tempItems ?? queryData.candidates`; clear on mutation `onSettled` — prevents React Query flicker
+
+### Claude's Discretion
+- Exact horizontal card dimensions and spacing in list view
+- Grid/list toggle icon style and placement
+- Drag animation timing and spring config
+- Image thumbnail size in list view cards
+- How action buttons (Winner, Delete, Link) adapt to horizontal card layout
+- Keyboard accessibility for reordering (arrow keys to move)
+
+</decisions>
+
+<code_context>
+## Existing Code Insights
+
+### Reusable Assets
+- `CandidateCard` (`src/client/components/CandidateCard.tsx`): Current card component — needs horizontal variant for list view, or a new `CandidateListItem` component
+- `StatusBadge` (`src/client/components/StatusBadge.tsx`): Click-to-cycle pattern reusable in list view
+- `useCandidates.ts` hooks: `useCreateCandidate`, `useUpdateCandidate`, `useDeleteCandidate` — need new `useReorderCandidates` mutation
+- `useThread` hook: Returns thread with `candidates[]` array — already has all data needed, just needs sort_order ordering
+- `formatWeight`/`formatPrice` formatters: Reuse in list view card badges
+- `useWeightUnit`/`useCurrency` hooks: Already used by CandidateCard
+- `LucideIcon` helper: For GripVertical drag handle and medal rank badges
+- `uiStore` (Zustand): Add `candidateViewMode: 'list' | 'grid'` for view toggle persistence
+
+### Established Patterns
+- framer-motion@12.37.0 already installed — `Reorder.Group`/`Reorder.Item` for drag ordering
+- React Query for server data, Zustand for UI-only state
+- Pill badges: blue for weight, green for price, gray for category, purple for pros/cons
+- Services accept db as first param (DI pattern for testability)
+- API validation via `@hono/zod-validator` with Zod schemas
+- Hover-reveal action buttons on CandidateCard (Winner, Delete, External link)
+
+### Integration Points
+- `src/db/schema.ts`: Add `sortOrder: real("sort_order").notNull().default(0)` to `threadCandidates`
+- `src/server/services/thread.service.ts`: New `reorderCandidates()` function (transactional); update `getCandidates` to ORDER BY sort_order
+- `src/server/routes/threads.ts`: New `PATCH /:id/candidates/reorder` endpoint; reject if thread is resolved
+- `src/shared/schemas.ts`: New `reorderCandidatesSchema` (z.object with orderedIds array)
+- `src/client/routes/threads/$threadId.tsx`: Wrap candidates in `Reorder.Group`, add view toggle, use tempItems pattern
+- `src/client/hooks/useCandidates.ts`: New `useReorderCandidates` mutation hook
+- `tests/helpers/db.ts`: Update CREATE TABLE for thread_candidates to include sort_order column
+- Drizzle migration: `sort_order REAL NOT NULL DEFAULT 0` + data migration to space existing rows
+
+</code_context>
+
+<specifics>
+## Specific Ideas
+
+- List view cards should feel like Trello or Linear cards — horizontal layout, grip handle on the left, compact but informative
+- Drag feedback should use standard framer-motion spring animations (elevated + gap), not custom physics
+- Medal badges should use actual metallic-feeling colors (gold #D4AF37, silver #C0C0C0, bronze #CD7F32), not generic highlight colors
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 11-candidate-ranking*
+*Context gathered: 2026-03-16*

.planning/phases/11-candidate-ranking/11-RESEARCH.md

@@ -0,0 +1,540 @@
+# Phase 11: Candidate Ranking - Research
+
+**Researched:** 2026-03-16
+**Domain:** Drag-to-reorder UI + fractional indexing persistence
+**Confidence:** HIGH
+
+<user_constraints>
+## User Constraints (from CONTEXT.md)
+
+### Locked Decisions
+
+**Card layout and view toggle**
+- Add a grid/list view toggle in the thread header (list view is default)
+- List view: vertical stack of horizontal cards (image thumbnail on left, name + badges on right) — enables drag-to-reorder
+- Grid view: current 3-column responsive card layout preserved
+- Both views render candidates in rank order (sort_order ascending)
+- Rank badges visible in both views
+
+**Drag handle design**
+- Always-visible GripVertical icon (Lucide) on the left side of each list-view card
+- Grip icon color: muted gray (text-gray-300), darkens to text-gray-500 on hover
+- Cursor changes to 'grab' on hover, 'grabbing' during drag
+- Drag feedback: elevated card with shadow + scale-up effect; other cards animate to show drop target gap (standard framer-motion Reorder behavior)
+- On resolved threads: grip icon disappears entirely (not disabled/grayed)
+- Drag only available in list view (grid view has no drag handles)
+
+**Rank badge style**
+- Medal icons (Lucide 'medal') in gold (#D4AF37), silver (#C0C0C0), bronze (#CD7F32) for top 3 candidates
+- Positioned inline before the candidate name text
+- Candidates ranked 4th and below show no rank indicator — position implied by list order
+- On resolved threads: rank badges remain visible (static, read-only) — user prefers retrospective visibility
+
+**Sort order and persistence**
+- Schema migration adds `sort_order REAL NOT NULL DEFAULT 0` to `thread_candidates`
+- Migration initializes existing candidates with spaced values (1000, 2000, 3000...) ordered by `created_at`
+- Fractional indexing: only the moved item gets a single UPDATE (midpoint between neighbors)
+- New candidates added to a thread get the highest sort_order (appended to bottom of rank)
+- Auto-save on drop — no "Save order" button; reorder persists immediately via `PATCH /api/threads/:id/candidates/reorder`
+- `tempItems` local state pattern: render from `tempItems ?? queryData.candidates`; clear on mutation `onSettled` — prevents React Query flicker
+
+### Claude's Discretion
+- Exact horizontal card dimensions and spacing in list view
+- Grid/list toggle icon style and placement
+- Drag animation timing and spring config
+- Image thumbnail size in list view cards
+- How action buttons (Winner, Delete, Link) adapt to horizontal card layout
+- Keyboard accessibility for reordering (arrow keys to move)
+
+### Deferred Ideas (OUT OF SCOPE)
+None — discussion stayed within phase scope
+</user_constraints>
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| RANK-01 | User can drag candidates to reorder priority ranking within a thread | framer-motion Reorder.Group/Item handles drag + onReorder callback; fractional indexing PATCH saves order |
+| RANK-02 | Top 3 ranked candidates display rank badges (gold, silver, bronze) | sort_order ascending sort gives rank position; Lucide `medal` icon confirmed available; CSS inline-color via style prop |
+| RANK-04 | Candidate rank order persists across sessions | `sort_order REAL` column + Drizzle migration + `getThreadWithCandidates` ORDER BY sort_order; tempItems pattern prevents RQ flicker |
+| RANK-05 | Drag handles and ranking are disabled on resolved threads | `isActive` prop already flows through `$threadId.tsx`; grip icon conditional render; Reorder.Group only rendered when isActive |
+</phase_requirements>
+
+---
+
+## Summary
+
+Phase 11 adds drag-to-reorder ranking for research thread candidates. The core mechanism is framer-motion's `Reorder.Group` / `Reorder.Item` components (already installed at v12.37.0 — no new dependencies), combined with a `sort_order REAL` column on `thread_candidates` and a fractional indexing strategy that writes only one row per reorder.
+
+The drag handle pattern requires `useDragControls` from framer-motion so the drag is initiated only from the GripVertical icon, not from tapping anywhere on the card. The `tempItems` local state pattern prevents a visible flicker between optimistic UI and React Query re-fetch.
+
+The phase introduces a grid/list view toggle (defaulting to list). The existing `CandidateCard` component handles grid view unchanged; a new `CandidateListItem` component (or a variant prop on `CandidateCard`) provides the horizontal list-view layout with the drag handle and rank badge.
+
+**Primary recommendation:** Implement in this order — schema migration, service update, Zod schema + route, hook, then UI (view toggle, `CandidateListItem`, rank badge). This matches the established field-addition ladder pattern.
+
+---
+
+## Standard Stack
+
+### Core
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| framer-motion | ^12.37.0 (installed) | Drag-to-reorder via `Reorder.Group`/`Reorder.Item`; `useDragControls` for handle-based drag | Already in project; Reorder API is purpose-built for this pattern — no additional install |
+| Drizzle ORM | installed | Schema migration + `ORDER BY sort_order` query | Project ORM; REAL type required for fractional indexing |
+| @tanstack/react-query | installed | `useReorderCandidates` mutation + cache invalidation | Project data-fetch layer |
+| Zustand | installed | `candidateViewMode: 'list' | 'grid'` in uiStore | Project UI state pattern |
+| lucide-react | installed | GripVertical, Medal, LayoutList, LayoutGrid icons | All icons confirmed present in installed version |
+
+### No New Dependencies
+This phase requires zero new npm packages. framer-motion, React Query, Zustand, and Lucide are all already installed.
+
+---
+
+## Architecture Patterns
+
+### Recommended Project Structure Changes
+```
+src/
+├── db/schema.ts                           # Add sortOrder: real("sort_order")
+├── server/
+│   ├── services/thread.service.ts         # Add reorderCandidates(), update getCandidates ORDER BY
+│   └── routes/threads.ts                  # Add PATCH /:id/candidates/reorder
+├── shared/
+│   ├── schemas.ts                         # Add reorderCandidatesSchema
+│   └── types.ts                           # Add ReorderCandidates type
+├── client/
+│   ├── components/
+│   │   ├── CandidateCard.tsx              # Unchanged (grid view)
+│   │   └── CandidateListItem.tsx          # NEW: horizontal list-view card with drag handle
+│   ├── hooks/useCandidates.ts             # Add useReorderCandidates mutation
+│   ├── routes/threads/$threadId.tsx       # Add view toggle, Reorder.Group, tempItems pattern
+│   └── stores/uiStore.ts                  # Add candidateViewMode state
+└── tests/
+    ├── helpers/db.ts                       # Add sort_order column to CREATE TABLE
+    └── services/thread.service.test.ts    # Tests for reorderCandidates()
+```
+
+### Pattern 1: framer-motion Reorder with Drag Handle
+
+The `Reorder.Group` fires `onReorder` whenever a drag completes. The `useDragControls` hook
+lets the drag be triggered only from the grip icon. Wrap each item with `Reorder.Item` and
+attach `dragControls` to it.
+
+```typescript
+// Source: framer-motion dist/types/index.d.ts (confirmed in installed v12.37.0)
+import { Reorder, useDragControls } from "framer-motion";
+
+// In ThreadDetailPage — list view:
+const [tempItems, setTempItems] = useState<Candidate[] | null>(null);
+const displayItems = tempItems ?? thread.candidates; // sorted by sort_order from server
+
+<Reorder.Group
+  axis="y"
+  values={displayItems}
+  onReorder={setTempItems}      // updates local order instantly
+  className="flex flex-col gap-2"
+>
+  {displayItems.map((candidate, index) => (
+    <CandidateListItem
+      key={candidate.id}
+      candidate={candidate}
+      rank={index + 1}
+      isActive={isActive}
+      onReorderSave={() => saveOrder(tempItems)}  // called onDragEnd
+    />
+  ))}
+</Reorder.Group>
+```
+
+```typescript
+// In CandidateListItem — drag handle via useDragControls:
+// Source: framer-motion dist/types/index.d.ts
+import { Reorder, useDragControls } from "framer-motion";
+
+function CandidateListItem({ candidate, rank, isActive, ... }) {
+  const controls = useDragControls();
+
+  return (
+    <Reorder.Item value={candidate} dragControls={controls} dragListener={false}>
+      <div className="flex items-center gap-3 bg-white rounded-xl border border-gray-100 p-3">
+        {/* Drag handle — only visible on active threads */}
+        {isActive && (
+          <div
+            onPointerDown={(e) => controls.start(e)}
+            className="cursor-grab active:cursor-grabbing text-gray-300 hover:text-gray-500 touch-none"
+          >
+            <LucideIcon name="grip-vertical" size={16} />
+          </div>
+        )}
+        {/* Rank badge — top 3 only, visible on resolved too */}
+        {rank <= 3 && <RankBadge rank={rank} />}
+        {/* ... rest of card content */}
+      </div>
+    </Reorder.Item>
+  );
+}
+```
+
+**Key flag:** `dragListener={false}` on `Reorder.Item` disables the default "drag anywhere on the item" behavior, restricting drag to the handle only. This is the critical prop for handle-based reordering.
+
+**Key flag:** `touch-none` Tailwind class on the handle prevents scroll interference on mobile (`touch-action: none`).
+
+### Pattern 2: Fractional Indexing for sort_order
+
+Fractional indexing avoids rewriting all rows on every drag. Only the moved item's `sort_order` changes.
+
+```typescript
+// Service function — reorderCandidates
+// Computes new sort_order as midpoint between neighbors
+export function reorderCandidates(
+  db: Db,
+  threadId: number,
+  orderedIds: number[],
+): { success: boolean; error?: string } {
+  return db.transaction((tx) => {
+    // Verify thread is active
+    const thread = tx.select().from(threads).where(eq(threads.id, threadId)).get();
+    if (!thread || thread.status !== "active") {
+      return { success: false, error: "Thread not active" };
+    }
+
+    // Fetch current sort_orders keyed by id
+    const rows = tx
+      .select({ id: threadCandidates.id, sortOrder: threadCandidates.sortOrder })
+      .from(threadCandidates)
+      .where(eq(threadCandidates.threadId, threadId))
+      .all();
+
+    const sortMap = new Map(rows.map((r) => [r.id, r.sortOrder]));
+    const sortedExisting = [...sortMap.entries()].sort((a, b) => a[1] - b[1]);
+
+    // Re-assign spaced values in the requested order
+    // (Simpler than midpoint for full reorder; midpoint for single-item moves is optimization)
+    orderedIds.forEach((id, index) => {
+      const newOrder = (index + 1) * 1000;
+      tx.update(threadCandidates)
+        .set({ sortOrder: newOrder })
+        .where(eq(threadCandidates.id, id))
+        .run();
+    });
+
+    return { success: true };
+  });
+}
+```
+
+**Note:** The CONTEXT.md specifies midpoint-only for single-item moves. For the PATCH endpoint
+receiving a full ordered list, re-spacing at 1000 intervals is simpler and still correct.
+Midpoint optimization matters if the API receives only (id, position) for a single move —
+confirm which approach the planner selects.
+
+### Pattern 3: tempItems Flicker Prevention
+
+React Query refetch after mutation causes a visible reorder "snap back" unless tempItems absorbs the transition.
+
+```typescript
+// In ThreadDetailPage:
+const [tempItems, setTempItems] = useState<typeof thread.candidates | null>(null);
+const displayItems = tempItems ?? thread.candidates; // server data already sorted by sort_order
+
+const reorderMutation = useReorderCandidates(threadId);
+
+function handleReorder(newOrder: typeof thread.candidates) {
+  setTempItems(newOrder);
+}
+
+function handleDragEnd() {
+  if (!tempItems) return;
+  reorderMutation.mutate(
+    { orderedIds: tempItems.map((c) => c.id) },
+    {
+      onSettled: () => setTempItems(null),  // clear after server confirms or fails
+    }
+  );
+}
+```
+
+### Pattern 4: Drizzle Migration + Data Backfill
+
+Migration must add column AND backfill existing rows with spaced values to avoid all-zero sort_order.
+
+```sql
+-- Migration SQL (generated by bun run db:generate):
+ALTER TABLE `thread_candidates` ADD `sort_order` real NOT NULL DEFAULT 0;
+
+-- Data backfill SQL (run as separate statement in migration or seed script):
+-- SQLite window functions assign rank per thread, multiply by 1000
+UPDATE thread_candidates
+SET sort_order = (
+  SELECT (ROW_NUMBER() OVER (PARTITION BY thread_id ORDER BY created_at)) * 1000
+  FROM thread_candidates AS tc2
+  WHERE tc2.id = thread_candidates.id
+);
+```
+
+**SQLite version note:** SQLite supports window functions since version 3.25.0 (2018). Bun
+ships with a recent SQLite — this query is safe. Verify with `bun -e "import { Database } from 'bun:sqlite'; const db = new Database(':memory:'); console.log(db.query('SELECT sqlite_version()').get())"`.
+
+### Anti-Patterns to Avoid
+
+- **Drag from anywhere on the card:** Without `dragListener={false}` on `Reorder.Item`, clicking the card to edit it triggers a drag. Always pair with `useDragControls`.
+- **Ordering by integer with bulk update:** Updating all rows on every drag is O(n) writes. Use REAL (float) sort_order for midpoint single-update.
+- **Storing order in the React Query cache only:** Sort order must persist to the server; local-only ordering is lost on page refresh.
+- **Rendering `Reorder.Group` without `layout` on inner elements:** framer-motion needs `layout` prop on animated children to perform smooth gap animation. `Reorder.Item` handles this internally — do not nest another `motion.div` with conflicting layout props.
+- **Missing `key` on Reorder.Item:** The key must be stable (candidate.id), not index — framer-motion uses it to track item identity across reorders.
+
+---
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Drag-to-reorder list | Custom mousedown/mousemove/mouseup handlers | `framer-motion` Reorder.Group/Item | Handles pointer capture, scroll suppression, layout animation, keyboard fallback |
+| Drag handle restriction | Event.stopPropagation tricks | `useDragControls` + `dragListener={false}` | Official framer-motion API; handles touch events correctly |
+| Smooth gap animation during drag | CSS transform calculations | `Reorder.Item` layout animation | Built-in spring physics; other items animate to fill the gap automatically |
+| Sort order persistence strategy | Custom complex state | Fractional indexing (REAL column, midpoint) | One write per drop; no full-list rewrite; proven pattern from Linear/Trello |
+
+---
+
+## Common Pitfalls
+
+### Pitfall 1: All-Zero sort_order After Migration
+**What goes wrong:** ALTERing the column with `DEFAULT 0` sets all existing rows to 0. `ORDER BY sort_order` returns them in arbitrary order.
+**Why it happens:** SQLite sets new column values to the DEFAULT for existing rows.
+**How to avoid:** Run the window-function UPDATE backfill as part of the migration or immediately after.
+**Warning signs:** Candidates render in seemingly random or creation-id order after migration.
+
+### Pitfall 2: Drag Initiates on Card Click
+**What goes wrong:** User clicks to open the edit panel and the card starts dragging instead.
+**Why it happens:** `Reorder.Item` defaults `dragListener={true}` — any pointer-down on the item starts dragging.
+**How to avoid:** Set `dragListener={false}` on `Reorder.Item` and use `useDragControls` to start drag only from the grip handle's `onPointerDown`.
+**Warning signs:** Click on candidate name opens drag instead of edit panel.
+
+### Pitfall 3: React Query Flicker After Save
+**What goes wrong:** After `reorderMutation` completes and React Query refetches, candidates visually snap back to server order for a frame.
+**Why it happens:** React Query invalidates and refetches; server returns the new order but there's a brief moment where old cache is used.
+**How to avoid:** Use `tempItems` local state pattern. Render `tempItems ?? thread.candidates`. Clear `tempItems` in `onSettled` (not `onSuccess`) so it covers both success and error cases.
+**Warning signs:** Items visually "jump" after a drop.
+
+### Pitfall 4: touch-none Missing on Drag Handle
+**What goes wrong:** On mobile, dragging the grip handle scrolls the page instead of reordering.
+**Why it happens:** Browser default: `touch-action` allows scroll on pointer-down.
+**How to avoid:** Add `className="touch-none"` (Tailwind) or `style={{ touchAction: "none" }}` on the drag handle element.
+**Warning signs:** Mobile drag scrolls page; items don't reorder on touch devices.
+
+### Pitfall 5: Resolved Thread Reorder Accepted by API
+**What goes wrong:** A resolved thread's candidates can be reordered if the server does not check thread status.
+**Why it happens:** The API endpoint receives a valid payload and processes it without checking `thread.status`.
+**How to avoid:** In `reorderCandidates()` service, verify `thread.status === "active"` and return error if not. Match pattern of `resolveThread()` which already does this check.
+**Warning signs:** PATCH succeeds on a resolved thread; RANK-05 test fails.
+
+---
+
+## Code Examples
+
+### Zod Schema for Reorder Endpoint
+```typescript
+// src/shared/schemas.ts — add:
+// Source: existing schema.ts patterns in project
+export const reorderCandidatesSchema = z.object({
+  orderedIds: z.array(z.number().int().positive()).min(1),
+});
+```
+
+### Shared Type
+```typescript
+// src/shared/types.ts — add:
+export type ReorderCandidates = z.infer<typeof reorderCandidatesSchema>;
+```
+
+### Drizzle Schema Column
+```typescript
+// src/db/schema.ts — in threadCandidates table:
+sortOrder: real("sort_order").notNull().default(0),
+```
+
+### getThreadWithCandidates ORDER BY Fix
+```typescript
+// src/server/services/thread.service.ts
+// Change the candidateList query to order by sort_order:
+.from(threadCandidates)
+.innerJoin(categories, eq(threadCandidates.categoryId, categories.id))
+.where(eq(threadCandidates.threadId, threadId))
+.orderBy(threadCandidates.sortOrder)  // add this
+.all();
+```
+
+### createCandidate sort_order for New Candidates
+```typescript
+// src/server/services/thread.service.ts
+// New candidates append to bottom — find current max and add 1000:
+export function createCandidate(db, threadId, data) {
+  const maxRow = db
+    .select({ maxOrder: sql<number>`MAX(sort_order)` })
+    .from(threadCandidates)
+    .where(eq(threadCandidates.threadId, threadId))
+    .get();
+  const newSortOrder = (maxRow?.maxOrder ?? 0) + 1000;
+
+  return db.insert(threadCandidates).values({
+    ...data,
+    sortOrder: newSortOrder,
+  }).returning().get();
+}
+```
+
+### Hono PATCH Route
+```typescript
+// src/server/routes/threads.ts — add:
+app.patch(
+  "/:id/candidates/reorder",
+  zValidator("json", reorderCandidatesSchema),
+  (c) => {
+    const db = c.get("db");
+    const threadId = Number(c.req.param("id"));
+    const { orderedIds } = c.req.valid("json");
+    const result = reorderCandidates(db, threadId, orderedIds);
+    if (!result.success) return c.json({ error: result.error }, 400);
+    return c.json({ success: true });
+  },
+);
+```
+
+### useReorderCandidates Hook
+```typescript
+// src/client/hooks/useCandidates.ts — add:
+export function useReorderCandidates(threadId: number) {
+  const queryClient = useQueryClient();
+  return useMutation({
+    mutationFn: (data: { orderedIds: number[] }) =>
+      apiPatch<{ success: boolean }>(
+        `/api/threads/${threadId}/candidates/reorder`,
+        data,
+      ),
+    onSettled: () => {
+      queryClient.invalidateQueries({ queryKey: ["threads", threadId] });
+    },
+  });
+}
+```
+
+### RankBadge Component (inline)
+```typescript
+// Inline in CandidateListItem or extract as small component
+const RANK_STYLES = [
+  { color: "#D4AF37", label: "1st" }, // gold
+  { color: "#C0C0C0", label: "2nd" }, // silver
+  { color: "#CD7F32", label: "3rd" }, // bronze
+];
+
+function RankBadge({ rank }: { rank: number }) {
+  if (rank > 3) return null;
+  const { color } = RANK_STYLES[rank - 1];
+  return (
+    <LucideIcon
+      name="medal"
+      size={16}
+      className="shrink-0"
+      style={{ color }}
+    />
+  );
+}
+```
+
+### tests/helpers/db.ts: thread_candidates table update
+```sql
+-- Add to CREATE TABLE thread_candidates in tests/helpers/db.ts:
+sort_order REAL NOT NULL DEFAULT 0,
+```
+
+---
+
+## State of the Art
+
+| Old Approach | Current Approach | When Changed | Impact |
+|--------------|------------------|--------------|--------|
+| `react-beautiful-dnd` | framer-motion Reorder | framer-motion v5+ Reorder API | Simpler API, same bundle already present, maintained by Framer |
+| Integer sort_order with bulk UPDATE | REAL (float) fractional indexing | Best practice since ~2015 (Linear, Figma) | O(1) writes per drag vs O(n) |
+| "Save order" button | Auto-save on drop | UX convention | Reduces friction; matches Trello/Linear behavior |
+
+**Deprecated/outdated:**
+- `react-beautiful-dnd`: No longer actively maintained; framer-motion Reorder is the modern replacement in React 18+ projects.
+
+---
+
+## Open Questions
+
+1. **Full-list reorder vs single-item fractional update in PATCH body**
+   - What we know: CONTEXT.md says "only the moved item gets a single UPDATE (midpoint between neighbors)" but also says PATCH receives `orderedIds` array
+   - What's unclear: If the server receives the full ordered list, re-spacing at 1000-intervals is simpler than computing midpoints server-side
+   - Recommendation: Accept full `orderedIds` array in PATCH, re-space all at 1000-intervals; this is correct and simpler. Midpoint is only an optimization for very large lists (not relevant here).
+
+2. **View toggle persistence scope**
+   - What we know: CONTEXT.md says use Zustand `candidateViewMode` for view toggle
+   - What's unclear: Whether to also persist in `localStorage` across page refreshes
+   - Recommendation: Zustand in-memory only (resets to list on refresh) is sufficient; no localStorage needed unless user reports preference loss as pain point.
+
+---
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test (built-in) |
+| Config file | none — `bun test` auto-discovers `*.test.ts` |
+| Quick run command | `bun test tests/services/thread.service.test.ts` |
+| Full suite command | `bun test` |
+
+### Phase Requirements → Test Map
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| RANK-01 | `reorderCandidates()` updates sort_order in DB in requested sequence | unit | `bun test tests/services/thread.service.test.ts` | ❌ Wave 0 (new test cases) |
+| RANK-01 | `PATCH /api/threads/:id/candidates/reorder` returns 200 + reorders candidates | integration | `bun test tests/routes/threads.test.ts` | ❌ Wave 0 (new test cases) |
+| RANK-02 | Rank badge rendering logic (index → medal color) | unit (component logic) | `bun test` | Manual-only — no component test infra |
+| RANK-04 | `getThreadWithCandidates` returns candidates ordered by sort_order ascending | unit | `bun test tests/services/thread.service.test.ts` | ❌ Wave 0 |
+| RANK-05 | `reorderCandidates()` returns error when thread is resolved | unit | `bun test tests/services/thread.service.test.ts` | ❌ Wave 0 |
+| RANK-05 | `PATCH /api/threads/:id/candidates/reorder` returns 400 for resolved thread | integration | `bun test tests/routes/threads.test.ts` | ❌ Wave 0 |
+
+### Sampling Rate
+- **Per task commit:** `bun test tests/services/thread.service.test.ts`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+- [ ] New test cases in `tests/services/thread.service.test.ts` — covers RANK-01, RANK-04, RANK-05 service behavior
+- [ ] New test cases in `tests/routes/threads.test.ts` — covers RANK-01, RANK-05 route behavior
+- [ ] Update `tests/helpers/db.ts` CREATE TABLE for `thread_candidates` to add `sort_order REAL NOT NULL DEFAULT 0`
+
+---
+
+## Sources
+
+### Primary (HIGH confidence)
+- framer-motion `dist/types/index.d.ts` (v12.37.0 installed) — `Reorder.Group`, `Reorder.Item`, `useDragControls`, `dragListener` prop confirmed
+- `src/client/lib/api.ts` — `apiPatch` confirmed available
+- `src/client/lib/iconData.tsx` + lucide-react installed — `medal`, `grip-vertical`, `layout-list`, `layout-grid` icons confirmed via `bun -e` introspection
+- `src/db/schema.ts` — current schema confirmed; `sort_order` column absent (needs migration)
+- `tests/helpers/db.ts` — CREATE TABLE confirmed; needs `sort_order` column added
+- `src/server/services/thread.service.ts` — `resolveThread()` pattern for status check reused in `reorderCandidates()`
+- `.planning/phases/11-candidate-ranking/11-CONTEXT.md` — all locked decisions applied
+
+### Secondary (MEDIUM confidence)
+- framer-motion Reorder documentation patterns (consistent with installed type definitions)
+- Fractional indexing / REAL sort_order pattern well-established in Linear, Trello, Figma implementations
+
+### Tertiary (LOW confidence)
+- None
+
+---
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH — all libraries confirmed installed and API-verified from local node_modules
+- Architecture: HIGH — patterns derived from existing codebase + confirmed framer-motion type signatures
+- Pitfalls: HIGH — derived from direct API analysis (dragListener, touch-none) and known SQLite migration behavior
+
+**Research date:** 2026-03-16
+**Valid until:** 2026-04-16 (stable dependencies; framer-motion Reorder API is mature)

.planning/phases/11-candidate-ranking/11-VALIDATION.md

@@ -0,0 +1,79 @@
+---
+phase: 11
+slug: candidate-ranking
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-16
+---
+
+# Phase 11 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Bun test (built-in) |
+| **Config file** | none — `bun test` auto-discovers `*.test.ts` |
+| **Quick run command** | `bun test tests/services/thread.service.test.ts` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test tests/services/thread.service.test.ts`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| TBD | 01 | 1 | RANK-01 | unit | `bun test tests/services/thread.service.test.ts` | ❌ W0 | ⬜ pending |
+| TBD | 01 | 1 | RANK-01 | integration | `bun test tests/routes/threads.test.ts` | ❌ W0 | ⬜ pending |
+| TBD | 01 | 1 | RANK-04 | unit | `bun test tests/services/thread.service.test.ts` | ❌ W0 | ⬜ pending |
+| TBD | 01 | 1 | RANK-05 | unit | `bun test tests/services/thread.service.test.ts` | ❌ W0 | ⬜ pending |
+| TBD | 01 | 1 | RANK-05 | integration | `bun test tests/routes/threads.test.ts` | ❌ W0 | ⬜ pending |
+| TBD | 02 | 1 | RANK-02 | manual | Visual inspection | N/A | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] New test cases in `tests/services/thread.service.test.ts` — covers RANK-01, RANK-04, RANK-05 service behavior
+- [ ] New test cases in `tests/routes/threads.test.ts` — covers RANK-01, RANK-05 route behavior
+- [ ] Update `tests/helpers/db.ts` CREATE TABLE for `thread_candidates` to add `sort_order REAL NOT NULL DEFAULT 0`
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Rank badge rendering (gold/silver/bronze medal icons on top 3) | RANK-02 | No component test infrastructure; visual verification required | Open thread with 3+ candidates, verify top 3 show medal icons with correct colors |
+| Drag handle visibility and interaction | RANK-01 | Visual/interaction verification | Open active thread in list view, verify grip icons visible, drag to reorder |
+| Drag handle absent on resolved thread | RANK-05 | Visual verification | Open resolved thread, verify no grip icons, rank badges still visible (static) |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/11-candidate-ranking/11-VERIFICATION.md

@@ -0,0 +1,175 @@
+---
+phase: 11-candidate-ranking
+verified: 2026-03-16T23:30:00Z
+status: human_needed
+score: 11/11 must-haves verified
+re_verification:
+  previous_status: gaps_found
+  previous_score: 9/11
+  gaps_closed:
+    - "User can drag a candidate card to a new position in list view and it persists after page refresh — onPointerUp={handleDragEnd} is now correctly on the active <Reorder.Group> (line 198)"
+  gaps_remaining: []
+  regressions: []
+human_verification:
+  - test: "Drag a candidate on an active thread and refresh"
+    expected: "Dragged order is preserved after page reload (new order loaded from server)"
+    why_human: "Smooth drag animation, gap preview, pointer-event timing, and actual persistence need visual inspection and interaction"
+  - test: "Drag handles visibility on resolved vs active threads"
+    expected: "Active threads show GripVertical drag handles; resolved threads show no drag handles but rank badges remain"
+    why_human: "CSS visibility and conditional rendering need visual verification"
+  - test: "Top 3 rank badges appearance"
+    expected: "Gold (#D4AF37), silver (#C0C0C0), bronze (#CD7F32) medal icons appear on positions 1, 2, 3 in both list and grid views"
+    why_human: "Color rendering and icon display need visual confirmation"
+---
+
+# Phase 11: Candidate Ranking Verification Report
+
+**Phase Goal:** Users can drag candidates into a priority order that persists and is visually communicated
+**Verified:** 2026-03-16T23:30:00Z
+**Status:** human_needed
+**Re-verification:** Yes — after gap closure
+
+## Re-verification Summary
+
+Previous status was `gaps_found` (score 9/11). The one critical blocker was:
+
+> `handleDragEnd` (which calls `reorderMutation.mutate`) was wired to the resolved-thread `<div>` via `onPointerUp`, not to the active-thread `<Reorder.Group>`. Dragging updated `tempItems` visually but never fired the mutation.
+
+**Fix verified:** `src/client/routes/threads/$threadId.tsx` line 198 now has `onPointerUp={handleDragEnd}` on the `<Reorder.Group>` for the active-thread path. The resolved-thread `<div>` (lines 217-233) has no `onPointerUp` handler. The fix is correct and complete.
+
+All 11 truths now pass automated checks. 135/135 tests pass. No regressions detected.
+
+---
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | Candidates returned from getThreadWithCandidates are ordered by sort_order ascending | VERIFIED | `thread.service.ts:90` uses `.orderBy(asc(threadCandidates.sortOrder))` |
+| 2 | Calling reorderCandidates with a new ID sequence updates sort_order values | VERIFIED | `reorderCandidates` loops `orderedIds`, sets `sortOrder: (i+1)*1000` per candidate in a transaction (`thread.service.ts:240`) |
+| 3 | PATCH /api/threads/:id/candidates/reorder returns 200 and persists new order | VERIFIED | Route at `threads.ts:129-140`; Zod-validated; returns `{ success: true }` or 400 |
+| 4 | reorderCandidates returns error when thread status is not active | VERIFIED | `thread.service.ts:234` checks `thread.status !== "active"`, returns `{ success: false, error: "Thread not active" }` |
+| 5 | New candidates appended to end of rank (max sort_order + 1000) | VERIFIED | `createCandidate` queries MAX, sets `sortOrder: (maxRow?.maxOrder ?? 0) + 1000` (`thread.service.ts:150,171`) |
+| 6 | User can drag a candidate card to a new position in list view and it persists after page refresh | VERIFIED (code) | `handleDragEnd` is now wired via `onPointerUp={handleDragEnd}` on `<Reorder.Group>` at `$threadId.tsx:198`. Mutation fires on pointer-up after drag. Persistence needs human confirmation. |
+| 7 | Top 3 candidates display gold, silver, and bronze medal badges | VERIFIED (code) | `RankBadge` in `CandidateListItem.tsx:37-47` renders medal icon with `RANK_COLORS` for rank 1-3, returns null for rank > 3. Visual confirmation needed. |
+| 8 | Rank badges appear in both list view and grid view | VERIFIED | `CandidateCard.tsx:165` renders `{rank != null && <RankBadge rank={rank} />}`; `$threadId.tsx:258` passes `rank={index + 1}` to all grid cards |
+| 9 | Drag handles are hidden and drag is disabled on resolved threads | VERIFIED | `CandidateListItem.tsx:73` renders drag handle only if `isActive`; resolved threads render plain `<div>` (not `Reorder.Group`) at `$threadId.tsx:217` |
+| 10 | Rank badges remain visible on resolved threads | VERIFIED | Resolved thread renders `<CandidateListItem isActive={false}>` which always renders `<RankBadge rank={rank} />` at line 85 |
+| 11 | User can toggle between list and grid view with list as default | VERIFIED | `uiStore.ts:112` initializes `candidateViewMode: "list"`; toggle buttons in `$threadId.tsx:146-172` call `setCandidateViewMode` |
+
+**Score:** 11/11 truths verified (all pass automated checks; 3 require human visual confirmation)
+
+---
+
+## Required Artifacts
+
+### Plan 11-01 Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/db/schema.ts` | sortOrder REAL column on threadCandidates | VERIFIED | Line 64: `sortOrder: real("sort_order").notNull().default(0)` |
+| `src/shared/schemas.ts` | reorderCandidatesSchema Zod validator | VERIFIED | Line 66: `export const reorderCandidatesSchema = z.object({ orderedIds: ... })` |
+| `src/shared/types.ts` | ReorderCandidates type | VERIFIED | Line 37: `export type ReorderCandidates = z.infer<typeof reorderCandidatesSchema>` |
+| `src/server/services/thread.service.ts` | reorderCandidates function exported | VERIFIED | Lines 220+: full implementation exported; sortOrder used at lines 90, 150, 171, 240 |
+| `src/server/routes/threads.ts` | PATCH /:id/candidates/reorder endpoint | VERIFIED | Lines 129-140: registered with Zod validation |
+| `tests/helpers/db.ts` | sort_order column in CREATE TABLE | VERIFIED | Line 60: `sort_order REAL NOT NULL DEFAULT 0` |
+
+### Plan 11-02 Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/client/components/CandidateListItem.tsx` | Horizontal list card with drag handle and rank badge (min 60 lines) | VERIFIED | 211 lines; `Reorder.Item` with `useDragControls`, drag handle (lines 73-82), `RankBadge` (line 85) |
+| `src/client/routes/threads/$threadId.tsx` | Reorder.Group wrapping + tempItems pattern + handleDragEnd on Reorder.Group | VERIFIED | `Reorder.Group` at line 194 with `onPointerUp={handleDragEnd}` at line 198; `tempItems` pattern at lines 28-37, 76 |
+| `src/client/hooks/useCandidates.ts` | useReorderCandidates mutation hook | VERIFIED | Lines 66-78: calls `apiPatch` to `candidates/reorder`, invalidates query on settled |
+| `src/client/stores/uiStore.ts` | candidateViewMode state | VERIFIED | Lines 53-54 (interface), 112-113 (implementation): default "list" |
+| `src/client/components/CandidateCard.tsx` | RankBadge on grid cards | VERIFIED | Imports `RankBadge` from `CandidateListItem` (line 6); renders at line 165 when `rank != null` |
+
+---
+
+## Key Link Verification
+
+### Plan 11-01 Key Links
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `threads.ts` | `thread.service.ts` | `reorderCandidates(db, threadId, orderedIds)` | WIRED | Line 136 imports and calls `reorderCandidates` |
+| `threads.ts` | `schemas.ts` | `zValidator with reorderCandidatesSchema` | WIRED | Line 8 imports `reorderCandidatesSchema`; line 131 uses `zValidator("json", reorderCandidatesSchema)` |
+| `thread.service.ts` | `schema.ts` | `threadCandidates.sortOrder in ORDER BY and UPDATE` | WIRED | Line 90 uses `asc(threadCandidates.sortOrder)`; line 240 sets `sortOrder: (i+1)*1000` |
+
+### Plan 11-02 Key Links
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `threads/$threadId.tsx` | `useCandidates.ts` | `useReorderCandidates(threadId)` | WIRED | Line 7 imports, line 26 calls `useReorderCandidates(threadId)` |
+| `useCandidates.ts` | `/api/threads/:id/candidates/reorder` | `apiPatch` | WIRED | Lines 70-73: `apiPatch<{ success: boolean }>(\`/api/threads/${threadId}/candidates/reorder\`, data)` |
+| `threads/$threadId.tsx` | `framer-motion` | `Reorder.Group + Reorder.Item` | WIRED | Line 2 imports `{ Reorder }`; line 194 uses `<Reorder.Group>` |
+| `CandidateListItem.tsx` | `framer-motion` | `Reorder.Item + useDragControls` | WIRED | Line 1 imports `{ Reorder, useDragControls }`; line 55 calls `useDragControls()` |
+| `uiStore.ts` | `threads/$threadId.tsx` | `candidateViewMode state` | WIRED | Lines 23-24 consume `candidateViewMode`/`setCandidateViewMode`; lines 148-170 use them in toggle buttons |
+| `Reorder.Group` | `reorderMutation` | `handleDragEnd via onPointerUp` | WIRED | `onPointerUp={handleDragEnd}` is on the active-thread `<Reorder.Group>` at line 198. `handleDragEnd` at lines 78-84 calls `reorderMutation.mutate`. Fix confirmed. |
+
+---
+
+## Requirements Coverage
+
+| Requirement | Source Plan | Description | Status | Evidence |
+|-------------|-------------|-------------|--------|----------|
+| RANK-01 | 11-01, 11-02 | User can drag candidates to reorder priority ranking | SATISFIED | Drag via framer-motion `Reorder.Group`; `handleDragEnd` now wired at `onPointerUp` on active `Reorder.Group` (line 198); mutation fires `PATCH /api/threads/:id/candidates/reorder` |
+| RANK-02 | 11-02 | Top 3 ranked candidates display rank badges (gold, silver, bronze) | SATISFIED | `RankBadge` renders medal icon with `RANK_COLORS`; used in both `CandidateListItem` (line 85) and `CandidateCard` (line 165) |
+| RANK-04 | 11-01, 11-02 | Candidate rank order persists across sessions | SATISFIED | `sort_order` column in DB; `reorderCandidates` service updates it in a transaction; React Query invalidates on `onSettled` so next load fetches fresh sorted order |
+| RANK-05 | 11-01, 11-02 | Drag handles and ranking disabled on resolved threads | SATISFIED | `CandidateListItem.tsx:73` renders drag handle only if `isActive`; resolved threads use plain `<div>` without `Reorder.Group`; service returns 400 if thread not active |
+
+Note: RANK-03 (pros/cons fields) was handled in Phase 10 and is not part of Phase 11.
+
+---
+
+## Anti-Patterns Found
+
+No blockers or warnings detected in the fixed code.
+
+| File | Line | Pattern | Severity | Impact |
+|------|------|---------|----------|--------|
+| — | — | — | — | No anti-patterns found |
+
+Previously identified blockers have been resolved: `onPointerUp={handleDragEnd}` is now correctly placed on the active `<Reorder.Group>` and absent from the resolved-thread `<div>`.
+
+---
+
+## Human Verification Required
+
+### 1. Drag persistence after refresh
+
+**Test:** Open an active thread with 3+ candidates, drag a candidate to a different position (e.g. drag position 3 to position 1), then refresh the page.
+**Expected:** The new order is preserved after refresh. The `PATCH /api/threads/:id/candidates/reorder` call fires on pointer-up, and the invalidated React Query refetch loads the persisted sort order.
+**Why human:** Real-time drag animation quality, gap animation between items, pointer-event timing, and the full round-trip to the server cannot be confirmed by static code analysis.
+
+### 2. Gold/silver/bronze badge colors
+
+**Test:** Open an active thread with 3+ candidates and view in list mode.
+**Expected:** Position 1 shows a gold medal icon (`#D4AF37`), position 2 shows silver (`#C0C0C0`), position 3 shows bronze (`#CD7F32`). Positions 4 and above show no badge. Toggle to grid view and verify the same badges appear on the first 3 cards.
+**Why human:** Hex color rendering accuracy and icon (medal) correctness need visual confirmation.
+
+### 3. Drag handle visibility on resolved threads
+
+**Test:** Navigate to a resolved thread in list view.
+**Expected:** No GripVertical drag handle icons are visible. Gold/silver/bronze rank badges are still present on the top 3 candidates in their sorted order. Candidates cannot be dragged.
+**Why human:** Conditional rendering of drag handles and static-only resolved state need visual verification.
+
+---
+
+## Gap Closure Confirmation
+
+The single gap from the previous verification has been closed:
+
+**Gap:** `onPointerUp={handleDragEnd}` was on the resolved-thread `<div>` (isActive=false path) only; the active `<Reorder.Group>` had no handler to trigger the mutation.
+
+**Fix:** `src/client/routes/threads/$threadId.tsx` line 198 — `onPointerUp={handleDragEnd}` is now on `<Reorder.Group axis="y" values={displayItems} onReorder={setTempItems} onPointerUp={handleDragEnd}>`. The resolved-thread `<div>` at lines 217-233 has no `onPointerUp`. The wiring is correct.
+
+**Regression check:** 135/135 tests pass. All previously-verified artifacts and key links remain intact.
+
+---
+
+_Verified: 2026-03-16T23:30:00Z_
+_Verifier: Claude (gsd-verifier)_
+_Re-verification: Yes — gap closure after previous gaps_found verdict_

.planning/phases/12-comparison-view/12-01-PLAN.md

@@ -0,0 +1,321 @@
+---
+phase: 12-comparison-view
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/client/components/ComparisonTable.tsx
+  - src/client/stores/uiStore.ts
+  - src/client/routes/threads/$threadId.tsx
+autonomous: true
+requirements: [COMP-01, COMP-02, COMP-03, COMP-04]
+
+must_haves:
+  truths:
+    - "User can toggle to a Compare view when a thread has 2+ candidates"
+    - "Comparison table shows all candidates side-by-side with weight, price, images, notes, links, status, pros, and cons"
+    - "The lightest candidate weight cell has a blue highlight; the cheapest candidate price cell has a green highlight"
+    - "Non-best cells show a gray +delta string; best cells show no delta"
+    - "The table scrolls horizontally on narrow viewports while the attribute label column stays fixed on the left"
+    - "Missing weight or price data displays a dash, never a misleading zero"
+    - "A resolved thread shows the comparison read-only with the winner column visually marked (amber tint + trophy)"
+  artifacts:
+    - path: "src/client/components/ComparisonTable.tsx"
+      provides: "Tabular side-by-side comparison component"
+      min_lines: 120
+    - path: "src/client/stores/uiStore.ts"
+      provides: "Extended candidateViewMode union type including 'compare'"
+      contains: "compare"
+    - path: "src/client/routes/threads/$threadId.tsx"
+      provides: "Compare toggle button and ComparisonTable rendering branch"
+      contains: "ComparisonTable"
+  key_links:
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/components/ComparisonTable.tsx"
+      via: "import and conditional render when candidateViewMode === 'compare'"
+      pattern: "candidateViewMode.*compare"
+    - from: "src/client/components/ComparisonTable.tsx"
+      to: "src/client/lib/formatters.ts"
+      via: "formatWeight and formatPrice for cell values and delta strings"
+      pattern: "formatWeight|formatPrice"
+    - from: "src/client/components/ComparisonTable.tsx"
+      to: "src/client/components/CandidateListItem.tsx"
+      via: "RankBadge import for rank row"
+      pattern: "RankBadge"
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/stores/uiStore.ts"
+      via: "candidateViewMode state read and setCandidateViewMode action"
+      pattern: "candidateViewMode"
+---
+
+<objective>
+Build the side-by-side candidate comparison table for research threads. Users toggle into compare mode from the existing view-mode bar and see all candidates as columns in a horizontally-scrollable table with sticky attribute labels, weight/price delta highlighting, and resolved-thread winner marking.
+
+Purpose: Enables users to directly compare candidates on weight, price, status, notes, pros, and cons without switching between cards -- the key decision-support view for the Research & Decision Tools milestone.
+
+Output: One new component (`ComparisonTable.tsx`), two modified files (`uiStore.ts`, `$threadId.tsx`).
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/12-comparison-view/12-CONTEXT.md
+@.planning/phases/12-comparison-view/12-RESEARCH.md
+
+@src/client/stores/uiStore.ts
+@src/client/routes/threads/$threadId.tsx
+@src/client/hooks/useThreads.ts
+@src/client/lib/formatters.ts
+@src/client/components/CandidateListItem.tsx
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/client/hooks/useThreads.ts:
+```typescript
+interface CandidateWithCategory {
+  id: number;
+  threadId: number;
+  name: string;
+  weightGrams: number | null;
+  priceCents: number | null;
+  categoryId: number;
+  notes: string | null;
+  productUrl: string | null;
+  imageFilename: string | null;
+  status: "researching" | "ordered" | "arrived";
+  pros: string | null;
+  cons: string | null;
+  createdAt: string;
+  updatedAt: string;
+  categoryName: string;
+  categoryIcon: string;
+}
+
+interface ThreadWithCandidates {
+  id: number;
+  name: string;
+  status: "active" | "resolved";
+  resolvedCandidateId: number | null;
+  createdAt: string;
+  updatedAt: string;
+  candidates: CandidateWithCategory[];
+}
+```
+
+From src/client/lib/formatters.ts:
+```typescript
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+export type Currency = "USD" | "EUR" | "GBP" | "JPY" | "CAD" | "AUD";
+export function formatWeight(grams: number | null | undefined, unit?: WeightUnit): string; // returns "--" for null
+export function formatPrice(cents: number | null | undefined, currency?: Currency): string; // returns "--" for null
+```
+
+From src/client/components/CandidateListItem.tsx:
+```typescript
+export function RankBadge({ rank }: { rank: number }): JSX.Element | null;
+// Returns null for rank > 3, renders gold/silver/bronze medal icon for 1/2/3
+```
+
+From src/client/stores/uiStore.ts (lines 52-54, current state):
+```typescript
+// Current type (will be extended):
+candidateViewMode: "list" | "grid";
+setCandidateViewMode: (mode: "list" | "grid") => void;
+```
+
+From src/client/lib/iconData.tsx:
+```typescript
+export function LucideIcon({ name, size, className, style }: LucideIconProps): JSX.Element;
+// Renders any Lucide icon by kebab-case name string
+```
+
+From src/client/hooks/useWeightUnit.ts:
+```typescript
+export function useWeightUnit(): WeightUnit; // reads from settings API
+```
+
+From src/client/hooks/useCurrency.ts:
+```typescript
+export function useCurrency(): Currency; // reads from settings API
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Build ComparisonTable component</name>
+  <files>src/client/components/ComparisonTable.tsx</files>
+  <action>
+Create `src/client/components/ComparisonTable.tsx` — a self-contained comparison table component.
+
+**Props interface:**
+```typescript
+interface ComparisonTableProps {
+  candidates: CandidateWithCategory[];
+  resolvedCandidateId: number | null;
+}
+```
+Import `CandidateWithCategory` type inline (duplicate the interface locally or import from useThreads — match project convention for component-local interfaces as seen in CandidateListItem.tsx which declares its own `CandidateWithCategory`).
+
+**Delta computation (useMemo):**
+- Weight deltas: Filter candidates with non-null `weightGrams`. Find the minimum. For each candidate, compute `delta = weightGrams - min`. If `delta === 0` (this IS the best), store `null` as delta string. Otherwise store `+${formatWeight(delta, unit)}`. Track `bestWeightId`. If all candidates have null weight, `bestWeightId = null`.
+- Price deltas: Same logic for `priceCents` with `formatPrice(delta, currency)`. Track `bestPriceId`.
+- Use `useWeightUnit()` and `useCurrency()` hooks for unit/currency-aware formatting.
+
+**Table structure:**
+- Outer: `<div className="overflow-x-auto rounded-xl border border-gray-100">` (scroll wrapper)
+- Inner: `<table>` with `style={{ minWidth: Math.max(400, candidates.length * 180) + 'px' }}` and `className="border-collapse text-sm w-full"`
+- `<thead>`: One `<tr>` with sticky corner `<th>` (empty, for label column) + one `<th>` per candidate showing name. If `candidate.id === resolvedCandidateId`, apply `bg-amber-50 text-amber-800` and prepend a trophy icon: `<LucideIcon name="trophy" size={12} className="text-amber-600" />`.
+- `<tbody>`: Render rows using a declarative ATTRIBUTE_ROWS array (see below).
+
+**Sticky left column CSS (CRITICAL):**
+Every `<td>` and `<th>` in the first (label) column MUST have: `sticky left-0 z-10 bg-white`. Without `bg-white`, scrolled content bleeds through. Use `z-10` (not higher — avoid conflicts with panels/modals).
+
+**Attribute row order** (per locked decision): Image, Name, Rank, Weight (with delta), Price (with delta), Status, Product Link, Notes, Pros, Cons.
+
+**Row rendering — use a declarative array pattern:**
+Define `ATTRIBUTE_ROWS` as an array of `{ key, label, render(candidate) }`. This keeps the JSX clean and makes row reordering trivial. Build this array inside the component function body (after useMemo hooks) so it can close over `weightDeltas`, `priceDeltas`, `bestWeightId`, `bestPriceId`, `unit`, `currency`.
+
+**Cell renderers:**
+- **Image**: 48x48 rounded-lg container. If `imageFilename`, render `<img src="/uploads/${imageFilename}" />` with `object-cover`. Else render `<LucideIcon name={categoryIcon} size={20} className="text-gray-400" />` in a `bg-gray-50` placeholder. Use `w-12 h-12` sizing.
+- **Name**: `<span className="text-sm font-medium text-gray-900">{name}</span>`
+- **Rank**: Reuse `<RankBadge rank={index + 1} />` imported from CandidateListItem. Rank is derived from array position (candidates are already sorted by sort_order from the API).
+- **Weight**: Show `formatWeight(weightGrams, unit)` as primary value in `font-medium text-gray-900`. If this is the best (`isBest`), apply `bg-blue-50` to the `<td>`. If delta string exists (not null, not best), show delta below in `text-xs text-gray-400`. If `weightGrams` is null, show `<span className="text-gray-300">—</span>`.
+- **Price**: Same pattern as weight but with `formatPrice(priceCents, currency)` and `bg-green-50` for the best cell.
+- **Status**: Render as static text `<span className="text-xs text-gray-600">{STATUS_LABELS[status]}</span>`. Define STATUS_LABELS map: `{ researching: "Researching", ordered: "Ordered", arrived: "Arrived" }`. No click-to-cycle in compare view — comparison is for reading, not mutation.
+- **Product Link**: If `productUrl` exists, render a clickable link that calls `openExternalLink(productUrl)` from uiStore: `<button onClick={() => openExternalLink(productUrl)} className="text-xs text-blue-500 hover:underline">View</button>`. If null, render `<span className="text-gray-300">—</span>`. Links remain clickable even in resolved threads (read-only means no mutations, but navigation is fine).
+- **Notes**: If `notes` exists, render `<p className="text-xs text-gray-700 whitespace-pre-line">{notes}</p>` (whitespace-pre-line preserves newlines). If null, render em dash placeholder.
+- **Pros**: If `pros` exists, split on `"\n"`, filter empty strings, render as `<ul className="list-disc list-inside space-y-0.5">` with `<li className="text-xs text-gray-700">` items. If null, render em dash placeholder.
+- **Cons**: Same as Pros rendering.
+
+**Winner column highlight (resolved threads):**
+When `resolvedCandidateId` is set, the winner's `<th>` in the header gets `bg-amber-50 text-amber-800` + trophy icon. Each body `<td>` for the winner column gets a subtle `bg-amber-50/50` tint (half-opacity amber). This must not conflict with the best-weight/best-price blue/green highlights — when both apply (winner IS also lightest), use the weight/price highlight color (it's more informative).
+
+**Row styling:**
+- Each `<tr>` gets `border-b border-gray-50` for subtle row separation.
+- Label `<td>` cells: `text-xs font-medium text-gray-500 uppercase tracking-wide w-28`.
+- Data `<td>` cells: `px-4 py-3 min-w-[160px]`.
+- Header `<th>` cells: `px-4 py-3 text-left text-xs font-medium text-gray-700 min-w-[160px]`.
+
+**Table border + rounding:**
+The outer wrapper has `rounded-xl border border-gray-100`. Add `overflow-hidden` to the wrapper alongside `overflow-x-auto` to clip the table's corners to the rounded border: `className="overflow-x-auto overflow-hidden rounded-xl border border-gray-100"`. Actually, use `overflow-x-auto` on an outer div, and put the border/rounding there. The table itself does not need border-radius.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint 2>&1 | head -20</automated>
+  </verify>
+  <done>ComparisonTable.tsx exists with all 10 attribute rows, delta computation via useMemo, sticky left column with bg-white, horizontal scroll wrapper, blue/green best-cell highlights, gray delta text for non-best, amber winner column for resolved threads, em dash for missing data (never zero).</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Wire compare toggle and ComparisonTable into thread detail</name>
+  <files>src/client/stores/uiStore.ts, src/client/routes/threads/$threadId.tsx</files>
+  <action>
+**Step 1: Extend uiStore candidateViewMode (src/client/stores/uiStore.ts)**
+
+Change the type union on lines 53-54 from:
+```typescript
+candidateViewMode: "list" | "grid";
+setCandidateViewMode: (mode: "list" | "grid") => void;
+```
+to:
+```typescript
+candidateViewMode: "list" | "grid" | "compare";
+setCandidateViewMode: (mode: "list" | "grid" | "compare") => void;
+```
+
+No other changes needed in uiStore — the implementation lines 112-113 are generic and already work with the wider type.
+
+**Step 2: Add compare toggle button (src/client/routes/threads/$threadId.tsx)**
+
+In the toolbar toggle bar (the `<div className="flex items-center gap-1 bg-gray-100 rounded-lg p-0.5">` block around line 146), add a third button for compare mode. The compare button should only render when `thread.candidates.length >= 2` (per locked decision).
+
+Add the compare button after the grid button but inside the toggle container:
+```tsx
+{thread.candidates.length >= 2 && (
+  <button
+    type="button"
+    onClick={() => setCandidateViewMode("compare")}
+    className={`p-1.5 rounded-md transition-colors ${
+      candidateViewMode === "compare"
+        ? "bg-gray-200 text-gray-900"
+        : "text-gray-400 hover:text-gray-600"
+    }`}
+    title="Compare view"
+  >
+    <LucideIcon name="columns-3" size={16} />
+  </button>
+)}
+```
+
+Also: Hide the "Add Candidate" button when in compare view. Change the existing `{isActive && (` guard (around line 123) to `{isActive && candidateViewMode !== "compare" && (`. This keeps the toolbar uncluttered — users switch to list/grid to add candidates.
+
+**Step 3: Add ComparisonTable rendering branch ($threadId.tsx)**
+
+Import ComparisonTable at the top of the file:
+```typescript
+import { ComparisonTable } from "../../components/ComparisonTable";
+```
+
+In the candidates rendering section (starting around line 192), add a compare branch BEFORE the existing list check:
+```tsx
+) : candidateViewMode === "compare" ? (
+  <ComparisonTable
+    candidates={displayItems}
+    resolvedCandidateId={thread.resolvedCandidateId}
+  />
+) : candidateViewMode === "list" ? (
+  // ... existing list rendering (unchanged)
+) : (
+  // ... existing grid rendering (unchanged)
+)
+```
+
+Pass `displayItems` (not `thread.candidates`) so the order reflects any pending drag reorder state, though in compare mode drag is not active — `displayItems` will equal `thread.candidates` when `tempItems` is null.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint 2>&1 | head -20 && bun test 2>&1 | tail -5</automated>
+  </verify>
+  <done>uiStore accepts "compare" as a candidateViewMode value. Thread detail page shows a third toggle icon (columns-3) when 2+ candidates exist. Clicking it renders ComparisonTable. "Add Candidate" button is hidden in compare mode. Existing list/grid views still work unchanged. All existing tests pass.</done>
+</task>
+
+</tasks>
+
+<verification>
+1. `bun run lint` passes with no errors
+2. `bun test` full suite passes (no backend changes, existing tests unaffected)
+3. Manual browser verification:
+   - Navigate to a thread with 2+ candidates
+   - Verify the compare icon (columns-3) appears in the toggle bar
+   - Click compare icon -> tabular comparison renders with candidates as columns
+   - Verify attribute row order: Image, Name, Rank, Weight, Price, Status, Link, Notes, Pros, Cons
+   - Verify lightest weight cell has blue-50 tint, cheapest price cell has green-50 tint
+   - Verify non-best cells show gray +delta text
+   - Verify missing weight/price shows em dash (not zero)
+   - Resize viewport narrow -> table scrolls horizontally, label column stays fixed
+   - Navigate to a resolved thread -> winner column has amber tint + trophy, no mutation controls
+   - Toggle back to list/grid views -> they still work correctly
+   - Thread with 0 or 1 candidate -> compare icon does not appear
+</verification>
+
+<success_criteria>
+- ComparisonTable.tsx renders all 10 attribute rows with correct data
+- Delta highlighting: blue-50 on lightest weight, green-50 on cheapest price, gray delta text on non-best
+- Sticky label column with solid bg-white stays visible during horizontal scroll
+- Resolved threads show winner column with amber-50 tint and trophy icon
+- Missing data renders as em dash, never as zero (COMP-04)
+- Compare toggle icon appears only when >= 2 candidates
+- All existing tests continue to pass
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/12-comparison-view/12-01-SUMMARY.md`
+</output>

.planning/phases/12-comparison-view/12-01-SUMMARY.md

@@ -0,0 +1,110 @@
+---
+phase: 12-comparison-view
+plan: "01"
+subsystem: ui
+tags: [react, tailwind, comparison-table, zustand, framer-motion]
+
+# Dependency graph
+requires:
+  - phase: 11-candidate-ranking
+    provides: RankBadge component and sort_order-based candidate ordering
+  - phase: 10-schema-foundation-pros-cons-fields
+    provides: pros/cons fields on CandidateWithCategory type
+provides:
+  - ComparisonTable component with sticky label column and horizontal scroll
+  - candidateViewMode "compare" value in uiStore
+  - Compare toggle in thread detail toolbar (visible when 2+ candidates)
+  - Weight/price delta highlighting with best-cell color coding
+  - Resolved thread winner column marking (amber tint + trophy)
+affects: [future comparison features, thread detail enhancements]
+
+# Tech tracking
+tech-stack:
+  added: []
+  patterns:
+    - Declarative ATTRIBUTE_ROWS array pattern for table row rendering (key, label, render, cellClass)
+    - useMemo delta computation for best-cell identification in comparison views
+
+key-files:
+  created:
+    - src/client/components/ComparisonTable.tsx
+  modified:
+    - src/client/stores/uiStore.ts
+    - src/client/routes/threads/$threadId.tsx
+
+key-decisions:
+  - "ATTRIBUTE_ROWS declarative array pattern keeps JSX clean and row reordering trivial"
+  - "cellClass function pattern in ATTRIBUTE_ROWS allows per-row cell styling without duplicating winner-check logic in every render"
+  - "Compare toggle only shown when >= 2 candidates (locked decision from plan)"
+  - "Add Candidate button hidden in compare view — compare is for reading, not mutation"
+  - "Winner highlight priority: weight/price color wins over amber tint when both apply (more informative)"
+
+patterns-established:
+  - "Declarative table row config: ATTRIBUTE_ROWS array with { key, label, render, cellClass } objects"
+  - "Sticky left column pattern: sticky left-0 z-10 bg-white on every label cell for scroll bleed prevention"
+
+requirements-completed: [COMP-01, COMP-02, COMP-03, COMP-04]
+
+# Metrics
+duration: 2min
+completed: 2026-03-17
+---
+
+# Phase 12 Plan 01: Comparison View Summary
+
+**Side-by-side candidate comparison table with sticky labels, weight/price delta highlighting, and resolved-thread winner marking via a new "compare" candidateViewMode**
+
+## Performance
+
+- **Duration:** 2 min
+- **Started:** 2026-03-17T14:28:12Z
+- **Completed:** 2026-03-17T14:30:00Z
+- **Tasks:** 2
+- **Files modified:** 3
+
+## Accomplishments
+- Built ComparisonTable component with 10 attribute rows (Image, Name, Rank, Weight, Price, Status, Link, Notes, Pros, Cons) using declarative ATTRIBUTE_ROWS pattern
+- Implemented useMemo delta computation — lightest weight cell highlighted blue-50, cheapest price cell green-50, non-best cells show gray +delta string
+- Sticky left column with bg-white prevents content bleed-through on horizontal scroll
+- Amber tint + trophy icon on winner column in resolved threads; weight/price color takes priority when winner is also best
+- Extended uiStore candidateViewMode to "list" | "grid" | "compare" and wired compare toggle in thread detail toolbar
+- Compare toggle only appears when thread has 2+ candidates; Add Candidate button hidden in compare view
+- All 135 existing tests pass, no regressions
+
+## Task Commits
+
+Each task was committed atomically:
+
+1. **Task 1: Build ComparisonTable component** - `e442b33` (feat)
+2. **Task 2: Wire compare toggle and ComparisonTable into thread detail** - `5b4026d` (feat)
+
+## Files Created/Modified
+- `src/client/components/ComparisonTable.tsx` - New comparison table component with all 10 attribute rows, delta computation, sticky labels, and winner highlighting
+- `src/client/stores/uiStore.ts` - Extended candidateViewMode union to include "compare"
+- `src/client/routes/threads/$threadId.tsx` - Added ComparisonTable import, compare toggle button (columns-3 icon), ComparisonTable rendering branch, and "Add Candidate" hidden in compare view
+
+## Decisions Made
+- ATTRIBUTE_ROWS declarative array pattern keeps table JSX clean and row reordering trivial — each row is just { key, label, render, cellClass }
+- cellClass function in ATTRIBUTE_ROWS allows per-row cell styling without duplicating winner-check logic in every render function
+- Compare toggle only shown for 2+ candidates per locked plan decision
+- Add Candidate button hidden in compare view to keep toolbar uncluttered (users switch to list/grid to add)
+- When winner IS also the lightest/cheapest, weight/price color (blue/green) takes priority over amber tint — more informative
+
+## Deviations from Plan
+
+None - plan executed exactly as written.
+
+## Issues Encountered
+- Minor formatting differences caught by Biome auto-formatter (indentation depth in conditional JSX) — resolved with `biome check --write`. No logic changes.
+
+## User Setup Required
+None - no external service configuration required.
+
+## Next Phase Readiness
+- ComparisonTable is complete and functional; compare mode wired end-to-end in thread detail
+- No blockers — ready for any follow-on comparison view enhancements
+- All existing tests pass; no backend changes needed
+
+---
+*Phase: 12-comparison-view*
+*Completed: 2026-03-17*

.planning/phases/12-comparison-view/12-RESEARCH.md

@@ -0,0 +1,541 @@
+# Phase 12: Comparison View - Research
+
+**Researched:** 2026-03-17
+**Domain:** React tabular UI, CSS sticky columns, horizontal scroll, delta computation
+**Confidence:** HIGH
+
+## Summary
+
+Phase 12 is a pure frontend phase. No backend changes, no schema changes, no new npm packages. All required data is already returned by `useThread(threadId)` — candidates carry `weightGrams`, `priceCents`, `status`, `productUrl`, `notes`, `pros`, `cons`, `imageFilename`, `categoryIcon`, and rank is derived from sort_order position in the array. The work is entirely in building a `ComparisonTable` component, wiring a third toggle button into the existing view-mode bar, and extending the `candidateViewMode` Zustand union type.
+
+The core CSS challenge is the sticky-first-column + horizontal-scroll table pattern. Modern CSS handles this well as long as `overflow-x: auto` is placed on a wrapper `<div>`, not the `<table>` element itself, and the sticky `<td>` cells in the label column have an explicit background color (otherwise scrolling content bleeds through). Z-index layering is simple for this use case because there is only one sticky axis (the left label column); no sticky top header is needed since the table is not vertically scrollable.
+
+Delta computation is straightforward arithmetic: find the minimum `weightGrams` across candidates that have a value, subtract each candidate's value from that minimum to produce a delta, and render a `+Xg` or `—` string. The "best" cell gets `bg-blue-50` for weight (matching existing blue weight pill color) or `bg-green-50` for price (matching existing green price pill color). Missing data must never display as "0" — a dash placeholder is required by COMP-04, and `formatWeight(null)` already returns `"--"`.
+
+**Primary recommendation:** Build `ComparisonTable.tsx` as a self-contained component that accepts `candidates[]` and `resolvedCandidateId | null`, computes deltas internally with `useMemo`, renders a `<div className="overflow-x-auto">` wrapper around a plain `<table>`, and uses `sticky left-0 bg-white z-10` on the label `<td>` cells.
+
+---
+
+<user_constraints>
+## User Constraints (from CONTEXT.md)
+
+### Locked Decisions
+- Compare mode entry point: Add a third icon to the existing list/grid toggle bar, making it list | grid | compare (three-way toggle)
+- Use `candidateViewMode: 'list' | 'grid' | 'compare'` in uiStore — extends the existing Zustand state
+- Compare icon only appears when 2+ candidates exist in the thread (hidden otherwise)
+- Table orientation: Candidates as columns, attribute labels as rows (classic product-comparison pattern — Amazon/Wirecutter style)
+- Sticky left column for attribute labels; table scrolls horizontally on narrow viewports
+- Attribute row order: Image → Name → Rank → Weight (with delta) → Price (with delta) → Status → Product Link → Notes → Pros → Cons
+- Delta highlighting style: Lightest candidate's weight cell gets a subtle colored background tint (e.g., bg-green-50); cheapest similarly
+- Non-best cells show delta text in neutral gray — no colored badges for deltas, only the "best" cell gets color
+
+### Claude's Discretion
+- "Add Candidate" button visibility when in compare view
+- Image thumbnail sizing in comparison cells (square crop vs wider aspect)
+- Multi-line text rendering strategy (clamped with expand vs full text)
+- Missing data indicator style (dash with label, empty cell, etc.)
+- Delta format: absolute value + delta underneath, or delta only for non-best cells
+- Winner column marking approach (column tint, trophy icon, or both)
+- Resolved thread interactivity (links clickable vs all read-only)
+- Resolution banner behavior in compare view
+- View mode persistence (already in Zustand — whether compare resets on navigation or persists)
+- Compare toggle icon choice (e.g., Lucide `columns-3`, `table-2`, or similar)
+- Table cell padding, border styling, and overall table chrome
+- Column minimum/maximum widths
+- Keyboard accessibility for horizontal scrolling
+
+### Deferred Ideas (OUT OF SCOPE)
+None — discussion stayed within phase scope
+</user_constraints>
+
+---
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| COMP-01 | User can view candidates side-by-side in a tabular comparison layout (weight, price, images, notes, links, status) | ComparisonTable component; all fields available from useThread hook; no backend changes needed |
+| COMP-02 | User can see relative deltas highlighting the lightest and cheapest candidate with +/- differences | Delta computation via array reduce; best-cell highlight via bg-blue-50 (weight) / bg-green-50 (price); gray delta text for non-best |
+| COMP-03 | Comparison table scrolls horizontally with a sticky label column on narrow viewports | overflow-x-auto wrapper div + sticky left-0 bg-white z-10 on label td cells |
+| COMP-04 | Comparison view displays read-only summary for resolved threads | resolvedCandidateId from useThread; disable mutation actions; winner column visual tint; resolved check pattern established in Phase 11 |
+</phase_requirements>
+
+---
+
+## Standard Stack
+
+### Core (all already installed — no new packages needed)
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| React 19 | ^19.2.4 | Component rendering | Project stack |
+| Tailwind CSS | v4 | Utility styling | Project stack |
+| Zustand | ^5.0.11 | candidateViewMode state | Already used for list/grid toggle |
+| lucide-react | ^0.577.0 | Toggle icon (`columns-3` confirmed present) | All icons use LucideIcon helper |
+| framer-motion | ^12.37.0 | Optional AnimatePresence for view transition | Already installed |
+
+### Supporting Utilities (already in project)
+| Utility | Location | Purpose |
+|---------|----------|---------|
+| `formatWeight(grams, unit)` | `src/client/lib/formatters.ts` | Weight cell values and delta strings; returns `"--"` for null |
+| `formatPrice(cents, currency)` | `src/client/lib/formatters.ts` | Price cell values and delta strings; returns `"--"` for null |
+| `useWeightUnit()` | `src/client/hooks/useWeightUnit.ts` | Current unit setting |
+| `useCurrency()` | `src/client/hooks/useCurrency.ts` | Current currency setting |
+| `useThread(threadId)` | `src/client/hooks/useThreads.ts` | All candidate data |
+| `RankBadge` | `src/client/components/CandidateListItem.tsx` | Rank medal icons (exported) |
+| `LucideIcon` | `src/client/lib/iconData.tsx` | Icon rendering with fallback |
+
+---
+
+## Architecture Patterns
+
+### Recommended File Structure
+```
+src/client/
+├── components/
+│   └── ComparisonTable.tsx     # New: tabular comparison component
+├── stores/
+│   └── uiStore.ts              # Modify: extend candidateViewMode union type
+└── routes/threads/
+    └── $threadId.tsx           # Modify: add compare branch + third toggle button
+```
+
+### Pattern 1: Sticky Left Column with Horizontal Scroll
+
+**What:** Wrap `<table>` in `<div className="overflow-x-auto">`. Apply `sticky left-0 bg-white z-10` to every `<td>` and `<th>` in the first (label) column.
+
+**When to use:** Any time a table needs a frozen left column with horizontal scrolling.
+
+**Critical pitfall:** The sticky `td` cells MUST have a solid background color. Without `bg-white`, scrolling content bleeds through the "sticky" cell because the cell is transparent.
+
+**Example:**
+```tsx
+// Outer wrapper enables horizontal scroll
+<div className="overflow-x-auto rounded-xl border border-gray-100">
+  <table
+    className="border-collapse text-sm"
+    style={{ minWidth: `${Math.max(400, candidates.length * 180)}px` }}
+  >
+    <thead>
+      <tr className="border-b border-gray-100">
+        {/* Sticky corner cell — bg-white mandatory */}
+        <th className="sticky left-0 z-10 bg-white px-4 py-3 text-left text-xs font-medium text-gray-400 uppercase tracking-wide w-28" />
+        {candidates.map((c) => (
+          <th key={c.id} className="px-4 py-3 text-left text-xs font-medium text-gray-700 min-w-[160px]">
+            {c.name}
+          </th>
+        ))}
+      </tr>
+    </thead>
+    <tbody>
+      {ATTRIBUTE_ROWS.map((row) => (
+        <tr key={row.key} className="border-b border-gray-50">
+          {/* Sticky label cell — bg-white mandatory */}
+          <td className="sticky left-0 z-10 bg-white px-4 py-3 text-xs font-medium text-gray-500">
+            {row.label}
+          </td>
+          {candidates.map((c) => (
+            <td key={c.id} className="px-4 py-3">
+              {row.render(c)}
+            </td>
+          ))}
+        </tr>
+      ))}
+    </tbody>
+  </table>
+</div>
+```
+
+### Pattern 2: Delta Computation (null-safe, useMemo)
+
+**What:** Derive the "best" candidate and compute deltas before rendering. Use `useMemo` keyed on `candidates` to avoid recomputing on every render.
+
+**Example:**
+```tsx
+// Source: derived from project formatters.ts patterns
+const { weightDeltas, bestWeightId } = useMemo(() => {
+  const withWeight = candidates.filter((c) => c.weightGrams != null);
+  if (withWeight.length === 0) return { weightDeltas: new Map<number, string | null>(), bestWeightId: null };
+
+  const minGrams = Math.min(...withWeight.map((c) => c.weightGrams as number));
+  const bestWeightId = withWeight.find((c) => c.weightGrams === minGrams)!.id;
+
+  const weightDeltas = new Map(
+    candidates.map((c) => {
+      if (c.weightGrams == null) return [c.id, null]; // null = missing data
+      const delta = c.weightGrams - minGrams;
+      return [c.id, delta === 0 ? null : `+${formatWeight(delta, unit)}`];
+      // delta === 0 means this IS the best — no delta string needed
+    })
+  );
+  return { weightDeltas, bestWeightId };
+}, [candidates, unit]);
+```
+
+### Pattern 3: Extending Zustand Union Type
+
+**What:** Widen the existing `candidateViewMode` type from `'list' | 'grid'` to `'list' | 'grid' | 'compare'`. The implementation setter line is unchanged.
+
+**Example:**
+```typescript
+// In uiStore.ts — only two type declaration lines change (lines 53-54):
+candidateViewMode: "list" | "grid" | "compare";
+setCandidateViewMode: (mode: "list" | "grid" | "compare") => void;
+
+// Implementation lines 112-113 — unchanged:
+candidateViewMode: "list",
+setCandidateViewMode: (mode) => set({ candidateViewMode: mode }),
+```
+
+### Pattern 4: Three-Way Toggle Button
+
+**What:** Add a third button to the existing `bg-gray-100 rounded-lg p-0.5` toggle bar in `$threadId.tsx`. Show compare button only when `thread.candidates.length >= 2`.
+
+**Example:**
+```tsx
+{thread.candidates.length >= 2 && (
+  <button
+    type="button"
+    onClick={() => setCandidateViewMode("compare")}
+    className={`p-1.5 rounded-md transition-colors ${
+      candidateViewMode === "compare"
+        ? "bg-gray-200 text-gray-900"
+        : "text-gray-400 hover:text-gray-600"
+    }`}
+    title="Compare view"
+  >
+    <LucideIcon name="columns-3" size={16} />
+  </button>
+)}
+```
+
+**Confirmed:** `columns-3` maps to `Columns3` in lucide-react ^0.577.0 and is present in the installed package (verified via `node -e "const {icons}=require('lucide-react'); console.log('Columns3' in icons)"`). Use `LucideIcon name="columns-3"` — the LucideIcon helper handles the `toPascalCase` conversion.
+
+### Pattern 5: Row Definition as Data
+
+**What:** Define the attribute rows as a declarative array, not hard-coded JSX branches. Each entry has a `key`, `label`, and a `render(candidate)` function. This makes row reordering trivial and matches the locked attribute order.
+
+**Example:**
+```tsx
+// Attribute row order per CONTEXT.md: Image → Name → Rank → Weight → Price → Status → Link → Notes → Pros → Cons
+const ATTRIBUTE_ROWS = [
+  { key: "image",  label: "Image",  render: (c: C) => <ImageCell candidate={c} /> },
+  { key: "name",   label: "Name",   render: (c: C) => <span className="text-sm font-medium text-gray-900">{c.name}</span> },
+  { key: "rank",   label: "Rank",   render: (c: C) => <RankBadge rank={rankOf(c)} /> },
+  { key: "weight", label: "Weight", render: (c: C) => <WeightCell candidate={c} delta={weightDeltas.get(c.id)} isBest={c.id === bestWeightId} unit={unit} /> },
+  { key: "price",  label: "Price",  render: (c: C) => <PriceCell candidate={c} delta={priceDeltas.get(c.id)} isBest={c.id === bestPriceId} currency={currency} /> },
+  { key: "status", label: "Status", render: (c: C) => <span className="text-xs text-gray-600">{STATUS_LABELS[c.status]}</span> },
+  { key: "link",   label: "Link",   render: (c: C) => c.productUrl ? <a href="#" onClick={() => openExternalLink(c.productUrl!)} className="text-xs text-blue-500 hover:underline">View</a> : <span className="text-gray-300">—</span> },
+  { key: "notes",  label: "Notes",  render: (c: C) => <TextCell text={c.notes} /> },
+  { key: "pros",   label: "Pros",   render: (c: C) => <BulletCell text={c.pros} /> },
+  { key: "cons",   label: "Cons",   render: (c: C) => <BulletCell text={c.cons} /> },
+];
+```
+
+### Pattern 6: Pros/Cons Rendering (confirmed newline-separated)
+
+**What:** `CandidateForm.tsx` uses a `<textarea>` with placeholder "One pro per line..." — users enter newline-separated text. The form submits `form.pros.trim() || undefined`, so empty = `undefined` → stored as `null` in DB. Non-empty content is raw text with `\n` separators.
+
+**How to render in compare table:**
+```tsx
+function BulletCell({ text }: { text: string | null }) {
+  if (!text) return <span className="text-gray-300">—</span>;
+  const items = text.split("\n").filter(Boolean);
+  if (items.length === 0) return <span className="text-gray-300">—</span>;
+  return (
+    <ul className="list-disc list-inside space-y-0.5">
+      {items.map((item, i) => (
+        <li key={i} className="text-xs text-gray-700">{item}</li>
+      ))}
+    </ul>
+  );
+}
+```
+
+### Anti-Patterns to Avoid
+
+- **Setting `overflow-x-auto` on `<table>` directly:** Has no effect in CSS. Must be on a wrapper `<div>`.
+- **Transparent sticky cells:** Sticky `<td>` cells without `bg-white` let scrolled content bleed through visually.
+- **Computing deltas inside render:** Use `useMemo` — compute once, not per render cycle.
+- **Using `overflow: hidden` on any ancestor of the sticky column:** Breaks the sticky positioning context.
+- **Missing data shown as "0":** `formatWeight(null)` already returns `"--"`. Guard delta computation with null checks before arithmetic.
+- **Rendering pros/cons as raw string:** Split on `\n` and render as `<ul>` — the form stores `\n`-separated text.
+
+---
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Weight/price formatting | Custom format functions | `formatWeight()` / `formatPrice()` in `formatters.ts` | Handles all units, currencies, null — returns `"--"` for null |
+| Rank medal icons | Custom SVG or color dots | `RankBadge` from `CandidateListItem.tsx` | Already exported, handles ranks 1-3 with correct colors |
+| Zustand state | Local useState for view mode | Existing `candidateViewMode` in `uiStore` | Persists across navigation, consistent with list/grid |
+| Icon rendering | Direct lucide component imports | `LucideIcon` helper from `iconData.tsx` | Handles fallback, consistent API across project |
+| Unit/currency awareness | Hardcode "g" or "$" | `useWeightUnit()` / `useCurrency()` | Reads from user settings |
+
+**Key insight:** This phase is almost entirely composition of already-built primitives. The delta computation logic and sticky column CSS are the only genuinely new work.
+
+---
+
+## Common Pitfalls
+
+### Pitfall 1: Sticky Cell Background Bleed-Through
+**What goes wrong:** The label column appears sticky but scrolling content renders on top of it, making text illegible.
+**Why it happens:** `position: sticky` keeps the element in its visual position but does not create an opaque layer. Without a background color the cell is transparent.
+**How to avoid:** Add `bg-white` to every sticky `<td>` and `<th>` in the label column. If alternating row backgrounds are used, the sticky cells must also match those background colors.
+**Warning signs:** Label text becomes unreadable when scrolling horizontally.
+
+### Pitfall 2: overflow-x-auto on Wrong Element
+**What goes wrong:** The table never scrolls horizontally regardless of viewport width.
+**Why it happens:** CSS `overflow` properties only apply to block/flex/grid containers. `<table>` is a table container — `overflow-x: auto` on `<table>` has no effect per CSS spec.
+**How to avoid:** Wrap `<table>` in `<div className="overflow-x-auto">`. Set `minWidth` on the `<table>` itself (not the wrapper) to force scrollability.
+**Warning signs:** Table content wraps aggressively instead of scrolling; columns collapse on narrow screens.
+
+### Pitfall 3: Delta Shows for Best Candidate
+**What goes wrong:** The lightest candidate shows "+0g" instead of just the value cleanly.
+**Why it happens:** Naive `delta = candidate - min` yields 0 for the best candidate.
+**How to avoid:** When `delta === 0`, return `null` for the delta string. The best-cell highlight color already communicates "this is best." Only non-best cells show a delta string.
+**Warning signs:** Best cell shows "+0g" or "+$0.00" alongside the colored highlight.
+
+### Pitfall 4: Missing Data Rendered as Zero (COMP-04 violation)
+**What goes wrong:** A candidate with `weightGrams: null` shows "0g" in the weight row, misleading the user.
+**Why it happens:** Passing `null` through subtraction arithmetic silently produces 0 in JavaScript.
+**How to avoid:** Guard before computing: `if (c.weightGrams == null) return [c.id, null]`. In the cell renderer, when value is null, render `—` (em dash).
+**Warning signs:** COMP-04 violated; user appears to see "0g" for an item with no weight entered.
+
+### Pitfall 5: z-index Conflicts with Panels/Dropdowns
+**What goes wrong:** Sticky label column renders above the SlideOutPanel or modal overlays.
+**Why it happens:** Using `z-index: 50` or higher on sticky cells competes with panel z-index values.
+**How to avoid:** Use `z-index: 10` (Tailwind `z-10`) for sticky cells. They only need to be above the regular table body cells (z-index: auto). The compare view has no interactive StatusBadge dropdowns (read-only in resolved mode; in active mode the compare view is navigational, not mutation-focused).
+**Warning signs:** Sticky column clips or obscures slide-out panels.
+
+### Pitfall 6: Pros/Cons Rendered as Raw String
+**What goes wrong:** A candidate's pros appear as a single run-on text block with no formatting.
+**Why it happens:** `CandidateForm` stores pros/cons as newline-separated plain text. Plain JSX `{candidate.pros}` ignores newlines in HTML.
+**How to avoid:** Split on `"\n"`, filter empty strings, render as `<ul>/<li>`. Confirmed from `CandidateForm.tsx` textarea with "One pro per line..." placeholder.
+**Warning signs:** All pro/con items concatenated without separation.
+
+---
+
+## Code Examples
+
+Verified patterns from project source:
+
+### Extending uiStore candidateViewMode
+```typescript
+// src/client/stores/uiStore.ts — lines 53-54 today read:
+//   candidateViewMode: "list" | "grid";
+//   setCandidateViewMode: (mode: "list" | "grid") => void;
+
+// After change (only these two lines change in the interface):
+candidateViewMode: "list" | "grid" | "compare";
+setCandidateViewMode: (mode: "list" | "grid" | "compare") => void;
+
+// Implementation at lines 112-113 — no change needed:
+candidateViewMode: "list",
+setCandidateViewMode: (mode) => set({ candidateViewMode: mode }),
+```
+
+### threadId.tsx integration point (current line 192)
+```tsx
+// Current conditional rendering at line 192:
+// ) : candidateViewMode === "list" ? (
+//   <Reorder.Group ... />  or  <div ... />
+// ) : (
+//   <div className="grid ..."> (grid view)
+// )
+
+// After change — add compare branch before list check:
+} : candidateViewMode === "compare" ? (
+  <ComparisonTable
+    candidates={displayItems}
+    resolvedCandidateId={thread.resolvedCandidateId}
+  />
+) : candidateViewMode === "list" ? (
+  // list rendering (unchanged)
+) : (
+  // grid rendering (unchanged)
+)
+```
+
+### Minimum viable ComparisonTable props interface
+```typescript
+// Reuse the CandidateWithCategory type from hooks/useThreads.ts
+interface ComparisonTableProps {
+  candidates: CandidateWithCategory[];   // already typed in useThreads.ts
+  resolvedCandidateId: number | null;    // for winner column highlight
+}
+```
+
+### Full delta computation with useMemo (null-safe)
+```typescript
+const { priceDeltas, bestPriceId } = useMemo(() => {
+  const withPrice = candidates.filter((c) => c.priceCents != null);
+  if (withPrice.length === 0) {
+    return { priceDeltas: new Map<number, string | null>(), bestPriceId: null };
+  }
+  const minCents = Math.min(...withPrice.map((c) => c.priceCents as number));
+  const bestPriceId = withPrice.find((c) => c.priceCents === minCents)!.id;
+  const priceDeltas = new Map(
+    candidates.map((c) => {
+      if (c.priceCents == null) return [c.id, null];          // missing data
+      const delta = c.priceCents - minCents;
+      return [c.id, delta === 0 ? null : `+${formatPrice(delta, currency)}`];
+    })
+  );
+  return { priceDeltas, bestPriceId };
+}, [candidates, currency]);
+```
+
+### Best-cell highlight pattern (weight example)
+```tsx
+// Weight cell — bg-blue-50 for "lightest" (matches existing blue weight pills in CandidateListItem)
+function WeightCell({ candidate, delta, isBest, unit }: WeightCellProps) {
+  return (
+    <td className={`px-4 py-3 text-sm ${isBest ? "bg-blue-50" : ""}`}>
+      {candidate.weightGrams != null ? (
+        <>
+          <span className="font-medium text-gray-900">
+            {formatWeight(candidate.weightGrams, unit)}
+          </span>
+          {delta && (
+            <span className="block text-xs text-gray-400 mt-0.5">{delta}</span>
+          )}
+        </>
+      ) : (
+        <span className="text-gray-300">—</span>
+      )}
+    </td>
+  );
+}
+```
+
+Note: CONTEXT.md uses "bg-green-50" as the example for lightest weight. Recommend aligning with existing project badge colors: lightest weight → `bg-blue-50` (consistent with blue weight pills), cheapest price → `bg-green-50` (consistent with green price pills). This is within Claude's discretion.
+
+### Winner column pattern (resolved threads)
+```tsx
+// Column header for the winning candidate gets amber tint (matches resolution banner)
+<th
+  key={c.id}
+  className={`px-4 py-3 text-left text-xs font-medium min-w-[160px] ${
+    c.id === resolvedCandidateId
+      ? "bg-amber-50 text-amber-800"
+      : "text-gray-700"
+  }`}
+>
+  <div className="flex items-center gap-1.5">
+    {c.id === resolvedCandidateId && (
+      <LucideIcon name="trophy" size={12} className="text-amber-600" />
+    )}
+    {c.name}
+  </div>
+</th>
+```
+
+---
+
+## State of the Art
+
+| Old Approach | Current Approach | Notes |
+|--------------|------------------|-------|
+| Hand-rolled format functions | Reuse `formatWeight` / `formatPrice` with delta arithmetic | Project formatters already handle all units, currencies, and null |
+| `overflow-x: auto` on `<table>` | `overflow-x-auto` on wrapper `<div>` | CSS spec: overflow only applies to block containers |
+| JS-based sticky columns | CSS `position: sticky` with `left: 0` | 92%+ browser support, zero JS overhead |
+| Inline column rendering | Declarative row-definition array | Matches the locked attribute order, easy to maintain |
+
+**Deprecated/outdated:**
+- Direct lucide icon component imports (e.g., `import { LayoutList } from "lucide-react"`): project uses `LucideIcon` helper uniformly — follow the same pattern.
+
+---
+
+## Open Questions
+
+All questions resolved during research:
+
+1. **Pros/cons storage format — RESOLVED**
+   - `CandidateForm.tsx` uses a `<textarea>` with "One pro per line..." placeholder
+   - Submit handler: `pros: form.pros.trim() || undefined` — empty string → not sent → stored as `null`
+   - Non-empty content: raw multiline text stored as-is, newline-separated
+   - **Action for planner:** Use `BulletCell` pattern (split on `\n`, render `<ul>/<li>`)
+
+2. **`columns-3` icon availability — RESOLVED**
+   - Verified: `Columns3` is present in lucide-react ^0.577.0 installed package
+   - Use `<LucideIcon name="columns-3" size={16} />` — the LucideIcon helper converts to PascalCase
+   - `table-2` is also present as a backup if needed
+
+3. **"Add Candidate" button in compare mode — RECOMMENDATION**
+   - Currently guarded by `{isActive && ...}` in `$threadId.tsx`
+   - Recommendation: hide "Add Candidate" when `candidateViewMode === "compare"` (keep toolbar uncluttered; users switch to list/grid to add)
+   - Implementation: add `&& candidateViewMode !== "compare"` to the existing `isActive` guard
+
+---
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test (built-in) |
+| Config file | None — uses `bun test` directly |
+| Quick run command | `bun test tests/lib/` |
+| Full suite command | `bun test` |
+
+### Phase Requirements → Test Map
+
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| COMP-01 | Candidates display all required fields in table | manual-only (UI/browser) | — | N/A |
+| COMP-02 | Delta computation: null-safe, best candidate identified, zero-delta suppressed | unit (if extracted to util) | `bun test tests/lib/comparison-deltas.test.ts` | ❌ Wave 0 gap (optional) |
+| COMP-03 | Table scrolls horizontally / sticky label column stays fixed | manual-only (CSS/browser) | — | N/A |
+| COMP-04 | Resolved thread shows read-only view with winner marked; no zero for missing data | manual-only (UI state) | — | N/A |
+
+**Note on testing scope:** COMP-01, COMP-03, COMP-04 are UI/browser behaviors. COMP-02 delta logic is pure arithmetic — testable if extracted to a standalone utility function. This is a pure frontend phase; the existing `bun test` suite covers backend services only and will not be broken by this phase.
+
+### Sampling Rate
+- **Per task commit:** `bun test` (full suite, fast — no UI tests in suite)
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green + manual browser verification of scroll/sticky behavior on a narrow viewport
+
+### Wave 0 Gaps
+- [ ] `tests/lib/comparison-deltas.test.ts` — covers COMP-02 delta logic if extracted to a pure utility (optional; skip if deltas stay inlined in the React component)
+
+*(If delta computation stays in the React component via `useMemo`, no new test files are needed — COMP-02 is verified manually in the browser.)*
+
+---
+
+## Sources
+
+### Primary (HIGH confidence)
+- Project codebase direct inspection:
+  - `src/client/stores/uiStore.ts` — confirmed `candidateViewMode` type and setter
+  - `src/client/routes/threads/$threadId.tsx` — confirmed integration points, toggle bar pattern, lines to modify
+  - `src/client/components/CandidateListItem.tsx` — confirmed `RankBadge` export, `CandidateWithCategory` interface
+  - `src/client/components/CandidateCard.tsx` — confirmed field usage patterns
+  - `src/client/components/CandidateForm.tsx` — confirmed pros/cons are newline-separated textarea input; empty = null
+  - `src/client/lib/formatters.ts` — confirmed null handling, `"--"` return for null
+  - `src/client/hooks/useThreads.ts` — confirmed `CandidateWithCategory` shape with all fields needed
+  - `package.json` — confirmed no new dependencies needed
+- Runtime verification: `Columns3` in lucide-react ^0.577.0 confirmed present via node script
+
+### Secondary (MEDIUM confidence)
+- [Tailwind CSS overflow docs](https://tailwindcss.com/docs/overflow) — `overflow-x-auto` on wrapper div pattern
+- [Tailwind CSS position docs](https://tailwindcss.com/docs/position) — sticky utility, z-index behavior
+- [Lexington Themes — scrollable sticky header table](https://lexingtonthemes.com/blog/how-to-build-a-scrollable-table-with-sticky-header-using-tailwind-css) — confirmed sticky thead pattern with Tailwind
+
+### Tertiary (LOW confidence — WebSearch, not verified against official spec)
+- [Multi-Directional Sticky CSS (Medium, Jan 2026)](https://medium.com/@ashutoshgautam10b11/multi-directional-sticky-css-and-horizontal-scroll-in-tables-41fc25c3ce8b) — z-index layering reference; this phase only needs one sticky axis (left column, z-10 suffices)
+- [DEV Community — sticky frozen column](https://dev.to/nicolaserny/table-with-a-fixed-first-column-2c5b) — background color requirement for sticky cells confirmed
+- [freeCodeCamp Forum — overflow + sticky](https://forum.freecodecamp.org/t/fixing-sticky-table-header-with-horizontal-scroll-in-a-scrollable-container/735559) — overflow-x-auto must be on wrapper div, not table element
+
+---
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH — all dependencies confirmed present in package.json; no new packages
+- Architecture: HIGH — directly derived from reading all relevant project source files
+- Pitfalls: HIGH — sticky bg issue confirmed by multiple sources; overflow-on-table confirmed by CSS spec; pros/cons newline format confirmed from CandidateForm source
+- Delta computation: HIGH — pure arithmetic, formatters already handle null, confirmed return values
+
+**Research date:** 2026-03-17
+**Valid until:** 2026-04-17 (stable CSS, stable React, stable project codebase)

.planning/phases/12-comparison-view/12-VALIDATION.md

@@ -0,0 +1,78 @@
+---
+phase: 12
+slug: comparison-view
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-17
+---
+
+# Phase 12 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | Bun test (built-in) |
+| **Config file** | None — uses `bun test` directly |
+| **Quick run command** | `bun test` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 12-01-01 | 01 | 1 | COMP-01 | manual-only (UI/browser) | — | N/A | ⬜ pending |
+| 12-01-02 | 01 | 1 | COMP-02 | unit (if delta util extracted) | `bun test tests/lib/comparison-deltas.test.ts` | ❌ W0 | ⬜ pending |
+| 12-01-03 | 01 | 1 | COMP-03 | manual-only (CSS/browser) | — | N/A | ⬜ pending |
+| 12-01-04 | 01 | 1 | COMP-04 | manual-only (UI state) | — | N/A | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] `tests/lib/comparison-deltas.test.ts` — stubs for COMP-02 delta computation (optional; skip if deltas stay inlined in React component via useMemo)
+
+*Existing `bun test` infrastructure covers all backend services. This phase is pure frontend — no backend tests are broken.*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Candidates display all fields in tabular columns | COMP-01 | UI rendering — no backend logic | Open thread with 2+ candidates, toggle compare view, verify all fields visible |
+| Table scrolls horizontally with sticky label column | COMP-03 | CSS behavior — requires browser | Narrow viewport to <768px, verify horizontal scroll, verify label column stays fixed |
+| Resolved thread shows read-only view with winner marked | COMP-04 | UI state — requires resolved thread | Open resolved thread, toggle compare view, verify winner column highlighted, no interactive elements |
+| Missing weight/price shows dash, not zero | COMP-04 | UI rendering for null data | Add candidate with no weight, toggle compare, verify "—" not "0g" |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/phases/12-comparison-view/12-VERIFICATION.md

@@ -0,0 +1,95 @@
+---
+phase: 12-comparison-view
+verified: 2026-03-17T00:00:00Z
+status: passed
+score: 7/7 must-haves verified
+re_verification: false
+---
+
+# Phase 12: Comparison View Verification Report
+
+**Phase Goal:** Users can view all candidates for a thread side-by-side in a table with relative weight and price deltas
+**Verified:** 2026-03-17
+**Status:** passed
+**Re-verification:** No — initial verification
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | User can toggle to a Compare view when a thread has 2+ candidates | VERIFIED | `$threadId.tsx:172` — compare button wrapped in `{thread.candidates.length >= 2 && (...)}`; clicking calls `setCandidateViewMode("compare")` |
+| 2 | Comparison table shows all candidates side-by-side with weight, price, images, notes, links, status, pros, and cons | VERIFIED | `ComparisonTable.tsx:104-269` — ATTRIBUTE_ROWS array defines all 10 rows: Image, Name, Rank, Weight, Price, Status, Link, Notes, Pros, Cons |
+| 3 | The lightest candidate weight cell has a blue highlight; the cheapest candidate price cell has a green highlight | VERIFIED | `ComparisonTable.tsx:167` — `cellClass` returns `"bg-blue-50"` when `c.id === bestWeightId`; `ComparisonTable.tsx:193` — `"bg-green-50"` when `c.id === bestPriceId` |
+| 4 | Non-best cells show a gray +delta string; best cells show no delta | VERIFIED | `ComparisonTable.tsx:64-66` — delta stored as `null` when `delta === 0` (best), else `+${formatWeight(delta, unit)}`; `ComparisonTable.tsx:160-162` — delta div only rendered when `!isBest && delta` |
+| 5 | The table scrolls horizontally on narrow viewports while the attribute label column stays fixed on the left | VERIFIED | `ComparisonTable.tsx:274` — outer `<div className="overflow-x-auto ...">` for scroll; `ComparisonTable.tsx:282,311` — every label cell has `sticky left-0 z-10 bg-white` |
+| 6 | Missing weight or price data displays a dash, never a misleading zero | VERIFIED | `ComparisonTable.tsx:152-153` — `if (c.weightGrams == null) return <span className="text-gray-300">—</span>`; `ComparisonTable.tsx:178-179` — same pattern for price |
+| 7 | A resolved thread shows the comparison read-only with the winner column visually marked (amber tint + trophy) | VERIFIED | `ComparisonTable.tsx:284-301` — winner `<th>` gets `bg-amber-50 text-amber-800` + trophy icon; body cells get `bg-amber-50/50` tint via default `extraClass` branch at line 318-320; no mutation controls exist inside ComparisonTable |
+
+**Score:** 7/7 truths verified
+
+### Required Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `src/client/components/ComparisonTable.tsx` | Tabular side-by-side comparison component; min 120 lines | VERIFIED | 336 lines; full ATTRIBUTE_ROWS declarative pattern, useMemo deltas, sticky column, winner highlighting |
+| `src/client/stores/uiStore.ts` | Extended candidateViewMode union including "compare" | VERIFIED | Line 53: `candidateViewMode: "list" \| "grid" \| "compare"` and line 54: `setCandidateViewMode: (mode: "list" \| "grid" \| "compare") => void` |
+| `src/client/routes/threads/$threadId.tsx` | Compare toggle button and ComparisonTable rendering branch | VERIFIED | Line 6 imports ComparisonTable; line 172-185 conditionally renders compare button; line 207-211 renders `<ComparisonTable>` when `candidateViewMode === "compare"` |
+
+### Key Link Verification
+
+| From | To | Via | Status | Details |
+|------|----|-----|--------|---------|
+| `$threadId.tsx` | `ComparisonTable.tsx` | import + conditional render when `candidateViewMode === "compare"` | WIRED | Line 6 imports; line 207 `candidateViewMode === "compare"` branch renders `<ComparisonTable candidates={displayItems} resolvedCandidateId={thread.resolvedCandidateId} />` |
+| `ComparisonTable.tsx` | `lib/formatters.ts` | `formatWeight` and `formatPrice` for cell values and delta strings | WIRED | Line 4 imports both; used at lines 66, 92, 158, 184 for both display values and delta string construction |
+| `ComparisonTable.tsx` | `CandidateListItem.tsx` | `RankBadge` import for rank row | WIRED | Line 7 imports `RankBadge`; used at line 144 in the rank ATTRIBUTE_ROW render function |
+| `$threadId.tsx` | `uiStore.ts` | `candidateViewMode` state read and `setCandidateViewMode` action | WIRED | Lines 24-25 read both from `useUIStore`; `candidateViewMode` read at lines 124, 152, 164, 177, 207, 212; `setCandidateViewMode` called at lines 150, 163, 175 |
+
+### Requirements Coverage
+
+| Requirement | Source Plan | Description | Status | Evidence |
+|-------------|-------------|-------------|--------|----------|
+| COMP-01 | 12-01-PLAN.md | User can view candidates side-by-side in a tabular comparison layout (weight, price, images, notes, links, status) | SATISFIED | ComparisonTable renders all fields as columns; toggle wired in $threadId.tsx |
+| COMP-02 | 12-01-PLAN.md | User can see relative deltas highlighting the lightest and cheapest candidate with +/- differences | SATISFIED | useMemo delta computation at lines 47-102; blue-50/green-50 highlights; gray delta text for non-best cells |
+| COMP-03 | 12-01-PLAN.md | Comparison table scrolls horizontally with a sticky label column on narrow viewports | SATISFIED | `overflow-x-auto` on wrapper; `sticky left-0 z-10 bg-white` on all label cells; `minWidth` computed from candidate count |
+| COMP-04 | 12-01-PLAN.md | Comparison view displays read-only summary for resolved threads | SATISFIED | No mutation actions in ComparisonTable; winner column amber-marked with trophy; `resolvedCandidateId` prop drives the read-only winner state |
+
+No orphaned requirements found. REQUIREMENTS.md maps COMP-01 through COMP-04 exclusively to Phase 12, all are accounted for by plan 12-01.
+
+### Anti-Patterns Found
+
+| File | Line | Pattern | Severity | Impact |
+|------|------|---------|----------|--------|
+| — | — | None found | — | — |
+
+No TODO/FIXME/placeholder comments, empty implementations, or stub returns found in any of the three phase 12 files. Biome lint passes cleanly on all three files (only pre-existing unrelated issues in other src files; none in phase 12 files).
+
+### Human Verification Required
+
+#### 1. Horizontal scroll with sticky label column
+
+**Test:** Open a thread with 3+ candidates on a narrow viewport (< 600px). Scroll the table right.
+**Expected:** Candidate columns scroll off-screen left; the attribute label column (Image, Name, Rank, etc.) remains fixed at the left edge without content bleed-through.
+**Why human:** CSS `sticky` behavior with `overflow-x-auto` interactions cannot be asserted by grep; only visual browser confirmation validates the `bg-white` bleed-through prevention.
+
+#### 2. Winner column amber tint + trophy on resolved thread
+
+**Test:** Navigate to a thread that has been resolved. Switch to compare view.
+**Expected:** The winning candidate's column header shows a trophy icon and amber background; every row of that column has a subtle amber-50/50 tint. Weight/price highlight colors (blue/green) take priority over amber when the winner is also the lightest/cheapest.
+**Why human:** Color layering and opacity compositing require visual verification.
+
+#### 3. Delta display with mixed null/non-null data
+
+**Test:** Add two candidates to a thread where one has weight data and the other does not. Switch to compare view.
+**Expected:** The candidate with no weight shows an em dash in the weight row (not 0g). The one with weight shows its value with no delta label (it is trivially the best). No misleading zero appears.
+**Why human:** Edge-case rendering for the null path requires runtime React state to confirm the `formatWeight(null)` → `"--"` path is reached and displayed as `—` (em dash span), not the `"--"` string fallback from formatters.
+
+### Gaps Summary
+
+No gaps found. All seven observable truths are verified, all three artifacts exist and are substantive, all four key links are wired end-to-end, all four COMP requirements are satisfied by traceable code, lint passes on all phase files, and 135 tests pass with zero regressions.
+
+---
+
+_Verified: 2026-03-17_
+_Verifier: Claude (gsd-verifier)_

.planning/phases/13-setup-impact-preview/13-01-PLAN.md

@@ -0,0 +1,253 @@
+---
+phase: 13-setup-impact-preview
+plan: 01
+type: tdd
+wave: 1
+depends_on: []
+files_modified:
+  - src/client/lib/impactDeltas.ts
+  - src/client/hooks/useImpactDeltas.ts
+  - src/client/hooks/useThreads.ts
+  - src/client/stores/uiStore.ts
+  - tests/lib/impactDeltas.test.ts
+autonomous: true
+requirements: [IMPC-01, IMPC-02, IMPC-03, IMPC-04]
+
+must_haves:
+  truths:
+    - "computeImpactDeltas returns replace-mode deltas when a setup item matches the thread category"
+    - "computeImpactDeltas returns add-mode deltas (candidate value only) when no category match exists"
+    - "computeImpactDeltas returns null weightDelta/priceDelta when candidate has null weight/price"
+    - "computeImpactDeltas returns mode 'none' with empty deltas when setupItems is undefined"
+    - "selectedSetupId state persists in uiStore and can be set/cleared"
+    - "ThreadWithCandidates interface includes categoryId field"
+  artifacts:
+    - path: "src/client/lib/impactDeltas.ts"
+      provides: "Pure computeImpactDeltas function with CandidateDelta, ImpactDeltas types"
+      exports: ["computeImpactDeltas", "CandidateInput", "CandidateDelta", "DeltaMode", "ImpactDeltas"]
+    - path: "src/client/hooks/useImpactDeltas.ts"
+      provides: "React hook wrapping computeImpactDeltas in useMemo"
+      exports: ["useImpactDeltas"]
+    - path: "tests/lib/impactDeltas.test.ts"
+      provides: "Unit tests for all four IMPC requirements"
+      contains: "computeImpactDeltas"
+  key_links:
+    - from: "src/client/hooks/useImpactDeltas.ts"
+      to: "src/client/lib/impactDeltas.ts"
+      via: "import computeImpactDeltas"
+      pattern: "import.*computeImpactDeltas.*from.*lib/impactDeltas"
+    - from: "src/client/hooks/useImpactDeltas.ts"
+      to: "src/client/hooks/useSetups.ts"
+      via: "SetupItemWithCategory type import"
+      pattern: "import.*SetupItemWithCategory.*from.*useSetups"
+---
+
+<objective>
+Create the pure impact delta computation logic with full TDD coverage, add selectedSetupId to uiStore, fix the ThreadWithCandidates type to include categoryId, and wrap it all in a useImpactDeltas hook.
+
+Purpose: Establish the data layer and contracts that Plan 02 will consume for rendering delta indicators. TDD ensures the replace/add mode logic and null-weight handling are correct before any UI work.
+Output: Tested pure function, React hook, updated types, uiStore state.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/13-setup-impact-preview/13-RESEARCH.md
+
+<interfaces>
+<!-- Key types and contracts the executor needs. Extracted from codebase. -->
+
+From src/client/hooks/useSetups.ts:
+```typescript
+interface SetupItemWithCategory {
+  id: number;
+  name: string;
+  weightGrams: number | null;
+  priceCents: number | null;
+  categoryId: number;
+  notes: string | null;
+  productUrl: string | null;
+  imageFilename: string | null;
+  createdAt: string;
+  updatedAt: string;
+  categoryName: string;
+  categoryIcon: string;
+  classification: string;
+}
+
+export function useSetup(setupId: number | null) {
+  return useQuery({
+    queryKey: ["setups", setupId],
+    queryFn: () => apiGet<SetupWithItems>(`/api/setups/${setupId}`),
+    enabled: setupId != null,  // CRITICAL: prevents null fetch
+  });
+}
+```
+
+From src/client/hooks/useThreads.ts (BEFORE fix):
+```typescript
+interface ThreadWithCandidates {
+  id: number;
+  name: string;
+  status: "active" | "resolved";
+  resolvedCandidateId: number | null;
+  createdAt: string;
+  updatedAt: string;
+  candidates: CandidateWithCategory[];
+  // NOTE: categoryId is MISSING — server returns it but type omits it
+}
+```
+
+From src/client/stores/uiStore.ts (existing pattern):
+```typescript
+candidateViewMode: "list" | "grid" | "compare";
+setCandidateViewMode: (mode: "list" | "grid" | "compare") => void;
+// Add selectedSetupId + setter using same pattern
+```
+
+From src/client/lib/formatters.ts:
+```typescript
+export type WeightUnit = "g" | "oz" | "lb" | "kg";
+export function formatWeight(grams: number | null | undefined, unit: WeightUnit = "g"): string;
+export type Currency = "USD" | "EUR" | "GBP" | "JPY" | "CAD" | "AUD";
+export function formatPrice(cents: number | null | undefined, currency: Currency = "USD"): string;
+```
+</interfaces>
+</context>
+
+<feature>
+  <name>Impact Delta Computation</name>
+  <files>src/client/lib/impactDeltas.ts, tests/lib/impactDeltas.test.ts, src/client/hooks/useImpactDeltas.ts, src/client/hooks/useThreads.ts, src/client/stores/uiStore.ts</files>
+  <behavior>
+    IMPC-01 (setup selected, deltas computed):
+    - Given candidates with weight/price and a setup with items, returns per-candidate delta objects with weightDelta and priceDelta numbers
+    - Given no setup selected (setupItems = undefined), returns { mode: "none", deltas: {} }
+
+    IMPC-02 (replace mode auto-detection):
+    - Given setup items where one has categoryId === threadCategoryId, mode is "replace"
+    - In replace mode, weightDelta = candidate.weightGrams - replacedItem.weightGrams
+    - In replace mode, priceDelta = candidate.priceCents - replacedItem.priceCents
+    - replacedItemName is populated with the matched item's name
+
+    IMPC-03 (add mode):
+    - Given setup items where NONE have categoryId === threadCategoryId, mode is "add"
+    - In add mode, weightDelta = candidate.weightGrams (pure addition)
+    - In add mode, priceDelta = candidate.priceCents (pure addition)
+    - replacedItemName is null
+
+    IMPC-04 (null weight handling):
+    - Given candidate.weightGrams is null, weightDelta is null (not 0, not NaN)
+    - Given candidate.priceCents is null, priceDelta is null
+    - In replace mode with replacedItem.weightGrams null but candidate has weight, weightDelta = candidate.weightGrams (treat as add for that field)
+
+    Edge cases:
+    - Empty candidates array -> returns { mode based on setup, deltas: {} }
+    - Multiple setup items in same category as thread -> first match used for replacement
+  </behavior>
+  <implementation>
+    1. Create src/client/lib/impactDeltas.ts with:
+       - CandidateInput interface: { id: number; weightGrams: number | null; priceCents: number | null }
+       - DeltaMode type: "replace" | "add" | "none"
+       - CandidateDelta interface: { candidateId, mode, weightDelta, priceDelta, replacedItemName }
+       - ImpactDeltas interface: { mode: DeltaMode; deltas: Record<number, CandidateDelta> }
+       - SetupItemInput interface: { categoryId: number; weightGrams: number | null; priceCents: number | null; name: string } (minimal subset of SetupItemWithCategory)
+       - computeImpactDeltas(candidates, setupItems, threadCategoryId) pure function
+
+    2. Create src/client/hooks/useImpactDeltas.ts wrapping in useMemo
+
+    3. Add categoryId to ThreadWithCandidates in useThreads.ts
+
+    4. Add selectedSetupId + setSelectedSetupId to uiStore.ts
+  </implementation>
+</feature>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Task 1: TDD pure computeImpactDeltas function</name>
+  <files>src/client/lib/impactDeltas.ts, tests/lib/impactDeltas.test.ts</files>
+  <behavior>
+    - Test: no setup selected (undefined) returns mode "none", empty deltas
+    - Test: replace mode — setup item matches threadCategoryId, deltas are candidate minus replaced item
+    - Test: add mode — no setup item matches, deltas equal candidate values
+    - Test: null candidate weight returns null weightDelta, not zero
+    - Test: null candidate price returns null priceDelta
+    - Test: replace mode with null replacedItem weight but valid candidate weight returns candidate weight as delta (add-like for that field)
+    - Test: negative delta in replace mode (candidate lighter than replaced item)
+    - Test: zero delta in replace mode (identical weight)
+    - Test: replacedItemName populated in replace mode, null in add mode
+  </behavior>
+  <action>
+    RED: Create tests/lib/impactDeltas.test.ts importing computeImpactDeltas from @/client/lib/impactDeltas. Write all test cases above using Bun test (describe/test/expect). Run tests — they MUST fail (module not found).
+
+    GREEN: Create src/client/lib/impactDeltas.ts with:
+    - Export types: CandidateInput, SetupItemInput, DeltaMode, CandidateDelta, ImpactDeltas
+    - Export function computeImpactDeltas(candidates: CandidateInput[], setupItems: SetupItemInput[] | undefined, threadCategoryId: number): ImpactDeltas
+    - Logic: if !setupItems return { mode: "none", deltas: {} }
+    - Find replacedItem = setupItems.find(item => item.categoryId === threadCategoryId) ?? null
+    - mode = replacedItem ? "replace" : "add"
+    - For each candidate: null-guard weight/price BEFORE arithmetic. In replace mode with non-null replaced value, delta = candidate - replaced. In replace mode with null replaced value, delta = candidate value (like add). In add mode, delta = candidate value.
+    - Run tests — all MUST pass.
+
+    REFACTOR: None needed for pure function.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test tests/lib/impactDeltas.test.ts</automated>
+  </verify>
+  <done>All 9+ test cases pass. computeImpactDeltas correctly handles replace mode, add mode, null weights, null prices, and edge cases. Types are exported.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Add uiStore state, fix ThreadWithCandidates type, create useImpactDeltas hook</name>
+  <files>src/client/stores/uiStore.ts, src/client/hooks/useThreads.ts, src/client/hooks/useImpactDeltas.ts</files>
+  <action>
+    1. In src/client/stores/uiStore.ts, add to UIState interface:
+       - selectedSetupId: number | null;
+       - setSelectedSetupId: (id: number | null) => void;
+       Add to create() initializer:
+       - selectedSetupId: null,
+       - setSelectedSetupId: (id) => set({ selectedSetupId: id }),
+       Place after the "Candidate view mode" section as "// Setup impact preview" section.
+
+    2. In src/client/hooks/useThreads.ts, add `categoryId: number;` to the ThreadWithCandidates interface, after the `resolvedCandidateId` field. The server already returns this field — the type was simply missing it.
+
+    3. Create src/client/hooks/useImpactDeltas.ts:
+       - Import useMemo from react
+       - Import computeImpactDeltas and types from "../lib/impactDeltas"
+       - Import type { SetupItemWithCategory } from "./useSetups"
+       - Export function useImpactDeltas(candidates: CandidateInput[], setupItems: SetupItemWithCategory[] | undefined, threadCategoryId: number): ImpactDeltas
+       - Body: return useMemo(() => computeImpactDeltas(candidates, setupItems, threadCategoryId), [candidates, setupItems, threadCategoryId])
+       - Re-export CandidateDelta, DeltaMode, ImpactDeltas types for convenience
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test tests/lib/impactDeltas.test.ts && bun test tests/lib/formatters.test.ts</automated>
+  </verify>
+  <done>uiStore has selectedSetupId + setter. ThreadWithCandidates includes categoryId. useImpactDeltas hook created and exports types. All existing tests still pass.</done>
+</task>
+
+</tasks>
+
+<verification>
+- `bun test tests/lib/` passes all tests (impactDeltas + formatters)
+- `bun test` full suite passes (no regressions)
+- Types export correctly: CandidateInput, CandidateDelta, DeltaMode, ImpactDeltas, SetupItemInput from impactDeltas.ts
+- useImpactDeltas hook wraps pure function in useMemo
+- uiStore.selectedSetupId defaults to null
+- ThreadWithCandidates.categoryId is declared as number
+</verification>
+
+<success_criteria>
+- All IMPC requirement behaviors are tested and passing via pure function unit tests
+- Data layer contracts (types, hook, uiStore state) are ready for Plan 02 UI consumption
+- Zero regressions in existing test suite
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/13-setup-impact-preview/13-01-SUMMARY.md`
+</output>

.planning/phases/13-setup-impact-preview/13-02-PLAN.md

@@ -0,0 +1,330 @@
+---
+phase: 13-setup-impact-preview
+plan: 02
+type: execute
+wave: 2
+depends_on: ["13-01"]
+files_modified:
+  - src/client/components/SetupImpactSelector.tsx
+  - src/client/components/ImpactDeltaBadge.tsx
+  - src/client/routes/threads/$threadId.tsx
+  - src/client/components/CandidateListItem.tsx
+  - src/client/components/CandidateCard.tsx
+  - src/client/components/ComparisonTable.tsx
+autonomous: true
+requirements: [IMPC-01, IMPC-02, IMPC-03, IMPC-04]
+
+must_haves:
+  truths:
+    - "User can select a setup from a dropdown in the thread header"
+    - "Each candidate displays weight and cost delta badges when a setup is selected"
+    - "Replace mode shows signed delta with replaced item name context"
+    - "Add mode shows positive delta labeled as '(add)'"
+    - "Candidate with no weight shows '-- (no weight data)' instead of a zero"
+    - "Candidate with no price shows '-- (no price data)' instead of a zero"
+    - "Deselecting setup ('None') clears all delta indicators"
+    - "Deltas appear in list view, grid view, and comparison table"
+  artifacts:
+    - path: "src/client/components/SetupImpactSelector.tsx"
+      provides: "Setup dropdown for thread header"
+      exports: ["SetupImpactSelector"]
+    - path: "src/client/components/ImpactDeltaBadge.tsx"
+      provides: "Inline delta indicator component"
+      exports: ["ImpactDeltaBadge"]
+    - path: "src/client/routes/threads/$threadId.tsx"
+      provides: "Thread detail page wired with impact preview"
+    - path: "src/client/components/CandidateListItem.tsx"
+      provides: "List item with delta badges"
+    - path: "src/client/components/CandidateCard.tsx"
+      provides: "Card with delta badges"
+    - path: "src/client/components/ComparisonTable.tsx"
+      provides: "Comparison table with impact delta rows"
+  key_links:
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/hooks/useImpactDeltas.ts"
+      via: "useImpactDeltas hook call at page level"
+      pattern: "useImpactDeltas"
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/hooks/useSetups.ts"
+      via: "useSetup(selectedSetupId) for setup item data"
+      pattern: "useSetup\\(selectedSetupId"
+    - from: "src/client/routes/threads/$threadId.tsx"
+      to: "src/client/stores/uiStore.ts"
+      via: "selectedSetupId state read"
+      pattern: "useUIStore.*selectedSetupId"
+    - from: "src/client/components/SetupImpactSelector.tsx"
+      to: "src/client/stores/uiStore.ts"
+      via: "setSelectedSetupId state write"
+      pattern: "setSelectedSetupId"
+    - from: "src/client/components/ImpactDeltaBadge.tsx"
+      to: "src/client/lib/impactDeltas.ts"
+      via: "CandidateDelta type import"
+      pattern: "import.*CandidateDelta"
+    - from: "src/client/components/ComparisonTable.tsx"
+      to: "src/client/lib/impactDeltas.ts"
+      via: "ImpactDeltas type for deltas prop"
+      pattern: "import.*ImpactDeltas"
+---
+
+<objective>
+Build the UI components (setup dropdown + delta badges) and wire them into the thread detail page across all three view modes (list, grid, compare).
+
+Purpose: This is the user-facing delivery of the impact preview feature. Plan 01 built the logic; this plan renders it.
+Output: SetupImpactSelector component, ImpactDeltaBadge component, updated CandidateListItem/CandidateCard/ComparisonTable with delta rendering, wired thread detail page.
+</objective>
+
+<execution_context>
+@/home/jlmak/.claude/get-shit-done/workflows/execute-plan.md
+@/home/jlmak/.claude/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/PROJECT.md
+@.planning/ROADMAP.md
+@.planning/STATE.md
+@.planning/phases/13-setup-impact-preview/13-RESEARCH.md
+@.planning/phases/13-setup-impact-preview/13-01-SUMMARY.md
+
+<interfaces>
+<!-- Types created by Plan 01 that this plan consumes -->
+
+From src/client/lib/impactDeltas.ts (created in Plan 01):
+```typescript
+export interface CandidateInput {
+  id: number;
+  weightGrams: number | null;
+  priceCents: number | null;
+}
+
+export type DeltaMode = "replace" | "add" | "none";
+
+export interface CandidateDelta {
+  candidateId: number;
+  mode: DeltaMode;
+  weightDelta: number | null;
+  priceDelta: number | null;
+  replacedItemName: string | null;
+}
+
+export interface ImpactDeltas {
+  mode: DeltaMode;
+  deltas: Record<number, CandidateDelta>;
+}
+```
+
+From src/client/hooks/useImpactDeltas.ts (created in Plan 01):
+```typescript
+export function useImpactDeltas(
+  candidates: CandidateInput[],
+  setupItems: SetupItemWithCategory[] | undefined,
+  threadCategoryId: number,
+): ImpactDeltas;
+```
+
+From src/client/hooks/useSetups.ts:
+```typescript
+export function useSetups(): UseQueryResult<SetupListItem[]>;
+export function useSetup(setupId: number | null): UseQueryResult<SetupWithItems>;
+```
+
+From src/client/stores/uiStore.ts (updated in Plan 01):
+```typescript
+selectedSetupId: number | null;
+setSelectedSetupId: (id: number | null) => void;
+```
+
+From src/client/hooks/useThreads.ts (updated in Plan 01):
+```typescript
+interface ThreadWithCandidates {
+  id: number;
+  name: string;
+  status: "active" | "resolved";
+  resolvedCandidateId: number | null;
+  categoryId: number;  // <-- Added in Plan 01
+  createdAt: string;
+  updatedAt: string;
+  candidates: CandidateWithCategory[];
+}
+```
+
+From src/client/lib/formatters.ts:
+```typescript
+export function formatWeight(grams: number | null | undefined, unit: WeightUnit = "g"): string;
+export function formatPrice(cents: number | null | undefined, currency: Currency = "USD"): string;
+```
+
+Existing component props that need delta additions:
+
+CandidateListItem props:
+```typescript
+interface CandidateListItemProps {
+  candidate: CandidateWithCategory;
+  rank: number;
+  isActive: boolean;
+  onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+  // Will add: delta?: CandidateDelta;
+}
+```
+
+CandidateCard props:
+```typescript
+interface CandidateCardProps {
+  id: number;
+  name: string;
+  weightGrams: number | null;
+  priceCents: number | null;
+  // ... other props
+  // Will add: delta?: CandidateDelta;
+}
+```
+
+ComparisonTable props:
+```typescript
+interface ComparisonTableProps {
+  candidates: CandidateWithCategory[];
+  resolvedCandidateId: number | null;
+  // Will add: deltas?: Record<number, CandidateDelta>;
+}
+```
+</interfaces>
+</context>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Create SetupImpactSelector and ImpactDeltaBadge components</name>
+  <files>src/client/components/SetupImpactSelector.tsx, src/client/components/ImpactDeltaBadge.tsx</files>
+  <action>
+    1. Create src/client/components/SetupImpactSelector.tsx:
+       - Import useSetups from hooks/useSetups
+       - Import useUIStore from stores/uiStore
+       - Export function SetupImpactSelector()
+       - Read selectedSetupId and setSelectedSetupId from uiStore
+       - Fetch setups via useSetups()
+       - If no setups or loading, return null
+       - Render: a flex row with label "Impact on setup:" (text-xs text-gray-500) and a native `<select>` element
+       - Select value = selectedSetupId ?? "", onChange parses to number or null
+       - Options: "None" (value="") + each setup by name
+       - Styling: text-sm border border-gray-200 rounded-lg px-2 py-1 text-gray-700 bg-white focus:outline-none focus:ring-1 focus:ring-gray-300
+
+    2. Create src/client/components/ImpactDeltaBadge.tsx:
+       - Import type CandidateDelta from lib/impactDeltas
+       - Import formatWeight, formatPrice, WeightUnit, Currency from lib/formatters
+       - Import useWeightUnit from hooks/useWeightUnit
+       - Import useCurrency from hooks/useCurrency
+       - Export function ImpactDeltaBadge({ delta, type }: { delta: CandidateDelta | undefined; type: "weight" | "price" })
+       - If !delta or delta.mode === "none", return null
+       - Pick value: type === "weight" ? delta.weightDelta : delta.priceDelta
+       - If value === null (no data): render `<span className="text-xs text-gray-300">` with "-- (no weight data)" or "-- (no price data)" depending on type
+       - If value is a number:
+         - formatted = type === "weight" ? formatWeight(Math.abs(value), unit) : formatPrice(Math.abs(value), currency)
+         - sign: value > 0 -> "+" , value < 0 -> "-" (use minus sign), value === 0 -> +/-
+         - colorClass: value < 0 -> "text-green-600" (lighter/cheaper is good), value > 0 -> "text-red-500", value === 0 -> "text-gray-400"
+         - modeLabel: delta.mode === "add" ? " (add)" : ""
+         - vsLabel: delta.mode === "replace" && delta.replacedItemName ? ` vs ${delta.replacedItemName}` : "" (only show this as a title attribute on the span, not inline text -- too long)
+         - Render: `<span className="text-xs font-medium {colorClass}" title={vsLabel || undefined}>{sign}{formatted}{modeLabel}</span>`
+       - The component reads unit/currency internally via hooks so callers don't need to pass them.
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun run lint 2>&1 | head -20</automated>
+  </verify>
+  <done>SetupImpactSelector renders a setup dropdown reading from uiStore. ImpactDeltaBadge renders signed, colored delta indicators with null-data handling. Both components lint-clean.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Wire impact preview into thread detail page and all candidate views</name>
+  <files>src/client/routes/threads/$threadId.tsx, src/client/components/CandidateListItem.tsx, src/client/components/CandidateCard.tsx, src/client/components/ComparisonTable.tsx</files>
+  <action>
+    1. In src/client/routes/threads/$threadId.tsx:
+       - Add imports: useSetup from hooks/useSetups, useImpactDeltas from hooks/useImpactDeltas, SetupImpactSelector from components/SetupImpactSelector, type CandidateDelta from lib/impactDeltas
+       - Read selectedSetupId from useUIStore: `const selectedSetupId = useUIStore((s) => s.selectedSetupId);`
+       - Fetch setup data: `const { data: setupData } = useSetup(selectedSetupId ?? null);`
+       - Compute deltas: `const impactDeltas = useImpactDeltas(thread.candidates, setupData?.items, thread.categoryId);` (place after thread is loaded, inside the render body after the isLoading/isError guards)
+       - Place `<SetupImpactSelector />` in the header section, after the thread name/status row and before the toolbar. Wrap it in a div for spacing if needed.
+       - Pass delta to CandidateListItem: add prop `delta={impactDeltas.deltas[candidate.id]}` to each CandidateListItem (both Reorder.Group and static div renderings)
+       - Pass delta to CandidateCard: add prop `delta={impactDeltas.deltas[candidate.id]}` (the CandidateCard receives individual props, so pass it as `delta={impactDeltas.deltas[candidate.id]}`)
+       - Pass deltas to ComparisonTable: add prop `deltas={impactDeltas.deltas}` alongside existing candidates and resolvedCandidateId
+
+    2. In src/client/components/CandidateListItem.tsx:
+       - Import type CandidateDelta from lib/impactDeltas
+       - Import ImpactDeltaBadge from ./ImpactDeltaBadge
+       - Add `delta?: CandidateDelta;` to CandidateListItemProps
+       - Add `delta` to destructured props
+       - Render two ImpactDeltaBadge components inside the badges flex-wrap div (after the existing weight and price badges):
+         - `{delta && <ImpactDeltaBadge delta={delta} type="weight" />}`
+         - `{delta && <ImpactDeltaBadge delta={delta} type="price" />}`
+       - Place these AFTER the existing weight/price badges so they appear as secondary indicators
+
+    3. In src/client/components/CandidateCard.tsx:
+       - Import type CandidateDelta from lib/impactDeltas
+       - Import ImpactDeltaBadge from ./ImpactDeltaBadge
+       - Add `delta?: CandidateDelta;` to CandidateCardProps
+       - Add `delta` to destructured props
+       - Render two ImpactDeltaBadge components inside the badges flex-wrap div (after weight/price badges):
+         - `{delta && <ImpactDeltaBadge delta={delta} type="weight" />}`
+         - `{delta && <ImpactDeltaBadge delta={delta} type="price" />}`
+
+    4. In src/client/components/ComparisonTable.tsx:
+       - Import type CandidateDelta from lib/impactDeltas
+       - Import ImpactDeltaBadge from ./ImpactDeltaBadge
+       - Add `deltas?: Record<number, CandidateDelta>;` to ComparisonTableProps
+       - Add `deltas` to destructured props
+       - Add two new rows to ATTRIBUTE_ROWS array, placed right after the "weight" row and "price" row respectively:
+         a. After "weight" row, add:
+            ```
+            {
+              key: "impact-weight",
+              label: "Impact (wt)",
+              render: (c) => deltas?.[c.id] ? <ImpactDeltaBadge delta={deltas[c.id]} type="weight" /> : <span className="text-gray-300">--</span>,
+            }
+            ```
+         b. After "price" row, add:
+            ```
+            {
+              key: "impact-price",
+              label: "Impact ($)",
+              render: (c) => deltas?.[c.id] ? <ImpactDeltaBadge delta={deltas[c.id]} type="price" /> : <span className="text-gray-300">--</span>,
+            }
+            ```
+       - These are separate rows (per research recommendation) to avoid conflating candidate-relative deltas with setup impact deltas.
+       - The impact rows show "--" when no setup is selected (deltas undefined or no entry for candidate).
+  </action>
+  <verify>
+    <automated>cd /home/jlmak/Projects/jlmak/GearBox && bun test && bun run lint 2>&1 | head -20</automated>
+  </verify>
+  <done>
+    - SetupImpactSelector dropdown visible in thread header
+    - Selecting a setup shows weight/cost delta badges on each candidate in list, grid, and compare views
+    - Replace mode: signed delta with green (lighter/cheaper) or red (heavier/pricier) coloring
+    - Add mode: positive delta with "(add)" label
+    - Null weight/price: shows "-- (no weight data)" / "-- (no price data)" indicator
+    - Deselecting setup clears all delta indicators
+    - ComparisonTable has dedicated "Impact (wt)" and "Impact ($)" rows
+    - All tests pass, lint clean
+  </done>
+</task>
+
+</tasks>
+
+<verification>
+- `bun test` full suite passes
+- `bun run lint` clean
+- SetupImpactSelector renders in thread header with all setups as options
+- Selecting a setup triggers useSetup fetch and delta computation
+- CandidateListItem, CandidateCard, ComparisonTable all render delta badges
+- Replace mode detected when setup has item in same category as thread
+- Add mode used otherwise
+- Null weight/price shows clear indicator
+- Deselecting shows no deltas (clean state)
+</verification>
+
+<success_criteria>
+- All four IMPC requirements visible in the UI
+- Delta rendering works across list, grid, and compare views
+- No regressions in existing functionality
+- Clean lint output
+</success_criteria>
+
+<output>
+After completion, create `.planning/phases/13-setup-impact-preview/13-02-SUMMARY.md`
+</output>

.planning/phases/13-setup-impact-preview/13-RESEARCH.md

@@ -0,0 +1,518 @@
+# Phase 13: Setup Impact Preview - Research
+
+**Researched:** 2026-03-17
+**Domain:** Pure frontend — delta computation + UI (React, Zustand, React Query)
+**Confidence:** HIGH
+
+---
+
+## Summary
+
+Phase 13 adds a setup-selector dropdown to the thread detail header. When a user picks a setup, every candidate card and list row gains two delta indicators: weight delta and cost delta. The computation has two modes determined at render time — replace mode (a setup item exists in the same category as the thread) and add mode (no category match). The entire feature is a pure frontend addition: all required data is already available through existing hooks with zero backend or schema changes needed.
+
+The delta logic is straightforward arithmetic over nullable numbers: `candidate.weightGrams - replacedItem.weightGrams` in replace mode, or `candidate.weightGrams` in add mode. The only real complexity is the null-weight indicator (IMPC-04) and driving the selected setup ID through Zustand state so it persists across view-mode switches within the same thread session.
+
+**Primary recommendation:** Add `selectedSetupId: number | null` to uiStore, render a setup dropdown in the thread header, compute deltas in a `useMemo` inside a new `useImpactDeltas` hook, and render inline delta indicators below the candidate weight/price badges in both list and grid views.
+
+---
+
+<phase_requirements>
+## Phase Requirements
+
+| ID | Description | Research Support |
+|----|-------------|-----------------|
+| IMPC-01 | User can select a setup and see weight and cost delta for each candidate | `useSetups()` returns all setups for dropdown; `useSetup(id)` returns items with categoryId for matching; delta computed in useMemo |
+| IMPC-02 | Impact preview auto-detects replace mode when a setup item exists in the same category as the thread | Thread has `categoryId` (from `threads.categoryId`); setup items have `categoryId` via join; match on `categoryId` equality |
+| IMPC-03 | Impact preview shows add mode (pure addition) when no category match exists in the selected setup | Default when no setup item matches `thread.categoryId`; label clearly as "+add" |
+| IMPC-04 | Candidates with missing weight data show a clear indicator instead of misleading zero deltas | `candidate.weightGrams == null` → render `"-- (no weight data)"` instead of computing |
+</phase_requirements>
+
+---
+
+## Standard Stack
+
+### Core
+| Library | Version | Purpose | Why Standard |
+|---------|---------|---------|--------------|
+| React 19 | ^19.2.4 | UI rendering | Project foundation |
+| Zustand | ^5.0.11 | `selectedSetupId` UI state | Established pattern for all UI-only state (panel open/close, view mode) |
+| TanStack React Query | ^5.90.21 | `useSetup(id)` for setup items | Established data fetching pattern |
+| Tailwind CSS v4 | ^4.2.1 | Delta badge styling | Project styling system |
+
+### Supporting
+| Library | Version | Purpose | When to Use |
+|---------|---------|---------|-------------|
+| framer-motion | ^12.37.0 | Optional entrance animation for delta indicators | Already installed; use AnimatePresence if subtle fade needed |
+| lucide-react | ^0.577.0 | Dropdown chevron icon, delta arrow icons | Project icon system |
+
+### No New Dependencies
+This phase requires zero new npm dependencies. All needed libraries are installed.
+
+**Installation:**
+```bash
+# No new packages needed
+```
+
+---
+
+## Architecture Patterns
+
+### Recommended Project Structure
+```
+src/client/
+├── stores/uiStore.ts           # Add selectedSetupId: number | null + setter
+├── hooks/
+│   └── useImpactDeltas.ts      # New: compute add/replace deltas per candidate
+├── components/
+│   ├── SetupImpactSelector.tsx # New: setup dropdown rendered in thread header
+│   └── ImpactDeltaBadge.tsx    # New (or inline): weight/cost delta pill
+└── routes/threads/$threadId.tsx # Add selector to header, pass deltas down
+```
+
+### Pattern 1: selectedSetupId in Zustand
+
+**What:** Store selected setup ID as UI state in `uiStore.ts`, not as URL state or server state.
+
+**When to use:** The selection is ephemeral per session (no permalink needed), needs to survive view-mode switches (list/grid/compare), and must be accessible from any component in the thread page without prop drilling.
+
+**Example:**
+```typescript
+// In uiStore.ts — add to UIState interface
+selectedSetupId: number | null;
+setSelectedSetupId: (id: number | null) => void;
+
+// In create() initializer
+selectedSetupId: null,
+setSelectedSetupId: (id) => set({ selectedSetupId: id }),
+```
+
+### Pattern 2: useImpactDeltas Hook
+
+**What:** A pure computation hook that accepts candidates + a setup's item list + the thread's categoryId, and returns per-candidate delta objects.
+
+**When to use:** Delta computation must run in a single place so list, grid, and compare views all show consistent numbers.
+
+**Interface:**
+```typescript
+// src/client/hooks/useImpactDeltas.ts
+import type { SetupItemWithCategory } from "./useSetups";
+
+interface CandidateInput {
+  id: number;
+  weightGrams: number | null;
+  priceCents: number | null;
+}
+
+type DeltaMode = "replace" | "add" | "none"; // "none" = no setup selected
+
+interface CandidateDelta {
+  candidateId: number;
+  mode: DeltaMode;
+  weightDelta: number | null;    // null = candidate has no weight data
+  priceDelta: number | null;     // null = candidate has no price data
+  replacedItemName: string | null; // populated in replace mode for tooltip
+}
+
+interface ImpactDeltas {
+  mode: DeltaMode;
+  deltas: Record<number, CandidateDelta>;
+}
+
+export function useImpactDeltas(
+  candidates: CandidateInput[],
+  setupItems: SetupItemWithCategory[] | undefined,
+  threadCategoryId: number,
+): ImpactDeltas
+```
+
+**Logic:**
+```typescript
+// Source: project codebase pattern — mirrors ComparisonTable useMemo
+const impactDeltas = useMemo(() => {
+  if (!setupItems) return { mode: "none", deltas: {} };
+
+  // Find replaced item: setup item whose categoryId matches thread's categoryId
+  const replacedItem = setupItems.find(
+    (item) => item.categoryId === threadCategoryId
+  ) ?? null;
+
+  const mode: DeltaMode = replacedItem ? "replace" : "add";
+
+  const deltas: Record<number, CandidateDelta> = {};
+  for (const c of candidates) {
+    let weightDelta: number | null = null;
+    let priceDelta: number | null = null;
+
+    if (c.weightGrams != null) {
+      weightDelta = mode === "replace" && replacedItem?.weightGrams != null
+        ? c.weightGrams - replacedItem.weightGrams
+        : c.weightGrams;
+    }
+    // priceCents is integer (cents), same arithmetic
+    if (c.priceCents != null) {
+      priceDelta = mode === "replace" && replacedItem?.priceCents != null
+        ? c.priceCents - replacedItem.priceCents
+        : c.priceCents;
+    }
+
+    deltas[c.id] = {
+      candidateId: c.id,
+      mode,
+      weightDelta,
+      priceDelta,
+      replacedItemName: replacedItem?.name ?? null,
+    };
+  }
+
+  return { mode, deltas };
+}, [candidates, setupItems, threadCategoryId]);
+```
+
+### Pattern 3: SetupImpactSelector Component
+
+**What:** A compact `<select>` dropdown in the thread detail header, rendered between the thread title and the toolbar.
+
+**When to use:** Always present on active and resolved thread pages (impact preview is read-only, no mutation side effects).
+
+**Example:**
+```typescript
+// Placed in thread header, after thread name row
+function SetupImpactSelector() {
+  const { data: setups } = useSetups();
+  const selectedSetupId = useUIStore((s) => s.selectedSetupId);
+  const setSelectedSetupId = useUIStore((s) => s.setSelectedSetupId);
+
+  if (!setups || setups.length === 0) return null;
+
+  return (
+    <div className="flex items-center gap-2">
+      <label className="text-xs text-gray-500 whitespace-nowrap">
+        Impact on setup:
+      </label>
+      <select
+        value={selectedSetupId ?? ""}
+        onChange={(e) => setSelectedSetupId(e.target.value ? Number(e.target.value) : null)}
+        className="text-sm border border-gray-200 rounded-lg px-2 py-1 text-gray-700 bg-white focus:outline-none focus:ring-1 focus:ring-gray-300"
+      >
+        <option value="">None</option>
+        {setups.map((s) => (
+          <option key={s.id} value={s.id}>{s.name}</option>
+        ))}
+      </select>
+    </div>
+  );
+}
+```
+
+### Pattern 4: ImpactDeltaBadge Rendering
+
+**What:** Small inline indicator rendered below weight/price badges on each candidate. Three rendering cases per field:
+
+| Case | Render |
+|------|--------|
+| No setup selected | Nothing (no change to existing layout) |
+| Candidate has no weight | `"-- (no weight data)"` in muted gray |
+| Weight exists, replace mode | `"±Xg vs [ItemName]"` with sign-colored text |
+| Weight exists, add mode | `"+Xg (add)"` in gray |
+
+**Where it renders:** Below the existing `formatWeight` / `formatPrice` badges in `CandidateListItem` and `CandidateCard`. In `ComparisonTable`, can be added as a sub-row or a second line within the weight/price cells.
+
+**Sign coloring convention:**
+- Negative delta (lighter/cheaper when replacing) → green text
+- Positive delta (heavier/more expensive) → red text
+- Zero delta → gray text
+- No weight data → muted gray, em-dash prefix
+
+```typescript
+// Reusable inline component
+function ImpactDeltaBadge({
+  delta,
+  noDataLabel = "-- (no weight data)",
+  unit,
+  currency,
+  type,
+}: {
+  delta: CandidateDelta | undefined;
+  noDataLabel?: string;
+  unit?: WeightUnit;
+  currency?: Currency;
+  type: "weight" | "price";
+}) {
+  if (!delta || delta.mode === "none") return null;
+
+  const value = type === "weight" ? delta.weightDelta : delta.priceDelta;
+
+  if (value === null) {
+    // Candidate has no data for this field
+    return (
+      <span className="text-xs text-gray-300">{noDataLabel}</span>
+    );
+  }
+
+  const formatted = type === "weight"
+    ? formatWeight(Math.abs(value), unit)
+    : formatPrice(Math.abs(value), currency);
+
+  const sign = value > 0 ? "+" : value < 0 ? "−" : "±";
+  const colorClass = value < 0 ? "text-green-600" : value > 0 ? "text-red-500" : "text-gray-400";
+  const modeLabel = delta.mode === "add" ? " (add)" : "";
+
+  return (
+    <span className={`text-xs font-medium ${colorClass}`}>
+      {sign}{formatted}{modeLabel}
+    </span>
+  );
+}
+```
+
+### Data Flow
+
+```
+$threadId.tsx
+  ├── selectedSetupId ← useUIStore
+  ├── thread ← useThread(threadId)          // has thread.categoryId + candidates
+  ├── setupData ← useSetup(selectedSetupId) // null when none selected
+  ├── impactDeltas ← useImpactDeltas(candidates, setupData?.items, thread.categoryId)
+  │
+  ├── <SetupImpactSelector />               // sets selectedSetupId in uiStore
+  │
+  ├── <CandidateListItem delta={impactDeltas.deltas[c.id]} />
+  ├── <CandidateCard delta={impactDeltas.deltas[c.id]} />
+  └── <ComparisonTable deltas={impactDeltas.deltas} />
+```
+
+### Anti-Patterns to Avoid
+
+- **Computing deltas in each candidate component:** Delta mode (add vs replace) must be determined once from the full setup. Computing per-component means each card independently decides mode — a setup with multiple items in different categories could give inconsistent signals if the logic is subtle.
+- **Storing selectedSetupId in URL search params:** Adds routing complexity with no benefit; the selection is ephemeral and non-shareable per project scope.
+- **Calling `useSetup` inside each candidate component:** Causes N redundant React Query calls. Call once at page level, pass deltas down.
+- **Treating `priceDelta = 0` as "no data":** Zero cost delta is a valid result (exact price match). The `null` check distinguishes missing data from zero.
+
+---
+
+## Don't Hand-Roll
+
+| Problem | Don't Build | Use Instead | Why |
+|---------|-------------|-------------|-----|
+| Formatted weight delta strings | Custom formatter | Reuse `formatWeight(Math.abs(delta), unit)` + sign prefix | Already handles all 4 units (g/oz/lb/kg) correctly |
+| Formatted price delta strings | Custom formatter | Reuse `formatPrice(Math.abs(delta), currency)` + sign prefix | Already handles all currencies and JPY integer case |
+| Setup list fetching | Custom fetch | `useSetups()` hook | Already defined, cached by React Query |
+| Setup items fetching | Custom fetch | `useSetup(id)` hook | Already defined with enabled guard |
+| UI state management | Local useState | Zustand `selectedSetupId` | Persists across view mode switches within same session |
+
+**Key insight:** All data infrastructure exists. This phase is arithmetic + UI only.
+
+---
+
+## Common Pitfalls
+
+### Pitfall 1: Thread categoryId vs Candidate categoryId
+
+**What goes wrong:** Using `candidate.categoryId` instead of `thread.categoryId` to find the replaced setup item. Candidates inherit the thread's category (they're in the same decision thread), but a user could theoretically pick a different category per candidate. The impact preview is about "what does buying something for this research thread do to my setup," so the match must be on the **thread** category, not individual candidate category.
+
+**Why it happens:** `CandidateWithCategory` has a `categoryId` field that looks natural to use.
+
+**How to avoid:** In `useImpactDeltas`, accept `threadCategoryId` as a separate parameter sourced from `thread.categoryId`, not from `candidate.categoryId`.
+
+**Warning signs:** Replace mode never triggers even when a setup contains an item in the expected category.
+
+### Pitfall 2: Null vs Zero for Missing Data (IMPC-04)
+
+**What goes wrong:** When `candidate.weightGrams` is `null`, the delta would be `null - replacedItem.weightGrams = NaN` or JavaScript coerces to `0`. Rendering "0g" is actively misleading — it implies the candidate has been weighed at zero.
+
+**Why it happens:** JavaScript's `null - 200 = -200` is NaN, not zero, but string formatting might swallow this silently.
+
+**How to avoid:** Explicit null guard BEFORE arithmetic: `if (c.weightGrams == null) { weightDelta = null; }`. Render `null` delta as `"-- (no weight data)"` per IMPC-04.
+
+**Warning signs:** Candidates with no weight show "0g" or "−200g" delta.
+
+### Pitfall 3: useSetup Enabled Guard
+
+**What goes wrong:** Calling `useSetup(null)` triggers a request to `/api/setups/null` — a 404 or server error.
+
+**Why it happens:** `useSetup` has `enabled: setupId != null` guard, but if the `selectedSetupId` from Zustand is not passed correctly, it might be `undefined` rather than `null`.
+
+**How to avoid:** Coerce to `null` explicitly: `useSetup(selectedSetupId ?? null)`.
+
+**Warning signs:** Network errors in dev tools when no setup is selected.
+
+### Pitfall 4: selectedSetupId Stale Across Thread Navigation
+
+**What goes wrong:** User selects "Setup A" on thread 1, navigates to thread 2, sees impact deltas for "Setup A" which may not be relevant.
+
+**Why it happens:** Zustand state persists in memory across route changes.
+
+**How to avoid:** Two acceptable approaches:
+1. **Accept it** — the user chose a setup globally; they can clear it. Simplest.
+2. **Reset on thread change** — call `setSelectedSetupId(null)` in a `useEffect` that fires on `threadId` change.
+
+Recommended: Accept cross-thread persistence (simpler, matches how `candidateViewMode` works currently).
+
+### Pitfall 5: ComparisonTable Integration
+
+**What goes wrong:** ComparisonTable already has its own `weightDeltas` computation (candidate-relative deltas: lightest vs others). Adding setup deltas as a third numeric display in the same weight cell risks visual clutter and ambiguity about which delta is which.
+
+**Why it happens:** Two delta systems in one cell with no visual separation.
+
+**How to avoid:** Render setup impact deltas in a **separate row** in ATTRIBUTE_ROWS, or as a clearly labeled sub-row below weight. Label it "Impact" with a small setup name indicator.
+
+---
+
+## Code Examples
+
+Verified patterns from existing codebase:
+
+### Existing Delta Pattern (ComparisonTable.tsx)
+```typescript
+// Source: src/client/components/ComparisonTable.tsx
+// This shows the established useMemo pattern for delta computation
+const { bestWeightId, bestPriceId, weightDeltas, priceDeltas } =
+  useMemo(() => {
+    const withWeight = candidates.filter((c) => c.weightGrams != null);
+    let bestWeightId: number | null = null;
+    const weightDeltas: Record<number, string | null> = {};
+    // ... arithmetic over nullable numbers
+    return { bestWeightId, bestPriceId, weightDeltas, priceDeltas };
+  }, [candidates, unit, currency]);
+```
+
+### Existing useSetup Hook
+```typescript
+// Source: src/client/hooks/useSetups.ts
+export function useSetup(setupId: number | null) {
+  return useQuery({
+    queryKey: ["setups", setupId],
+    queryFn: () => apiGet<SetupWithItems>(`/api/setups/${setupId}`),
+    enabled: setupId != null,  // CRITICAL: prevents null fetch
+  });
+}
+// SetupItemWithCategory includes: categoryId, weightGrams, priceCents, name
+```
+
+### Existing formatWeight / formatPrice
+```typescript
+// Source: src/client/lib/formatters.ts
+export function formatWeight(grams: number | null | undefined, unit: WeightUnit = "g"): string {
+  if (grams == null) return "--";
+  // handles g / oz / lb / kg
+}
+export function formatPrice(cents: number | null | undefined, currency: Currency = "USD"): string {
+  if (cents == null) return "--";
+  // handles JPY integer case, others to 2dp
+}
+// Pass Math.abs(delta) to these, prefix sign manually
+```
+
+### Existing Zustand UI State Pattern
+```typescript
+// Source: src/client/stores/uiStore.ts
+// All ephemeral UI state lives here — follow same pattern
+candidateViewMode: "list" | "grid" | "compare";
+setCandidateViewMode: (mode: "list" | "grid" | "compare") => void;
+// Add analogously:
+// selectedSetupId: number | null;
+// setSelectedSetupId: (id: number | null) => void;
+```
+
+### Thread categoryId Availability
+```typescript
+// Source: src/server/services/thread.service.ts — getThreadWithCandidates
+// thread object from useThread() has .categoryId (integer) directly available
+// Note: ThreadWithCandidates interface in useThreads.ts does NOT expose categoryId
+// The raw DB thread select does, but the hook return type may need updating
+```
+
+**Important finding:** The `ThreadWithCandidates` interface in `useThreads.ts` does NOT currently include `categoryId`. The server does return it (from `db.select().from(threads)`), but the TypeScript interface omits it. The planner must add `categoryId: number` to `ThreadWithCandidates` or source it from the candidates (each `CandidateWithCategory` has `categoryId`).
+
+---
+
+## State of the Art
+
+| Old Approach | Current Approach | When Changed | Impact |
+|--------------|------------------|--------------|--------|
+| Fetch data inside components | Custom hooks with React Query | Established in project | All data fetching via hooks |
+| Local component state for UI | Zustand store | Established in project | All UI state centralized |
+
+**No deprecated patterns in scope for this phase.**
+
+---
+
+## Open Questions
+
+1. **Thread categoryId exposure in ThreadWithCandidates**
+   - What we know: `getThreadWithCandidates` in thread.service.ts returns the full thread row (including `categoryId`), but `ThreadWithCandidates` TypeScript interface in `useThreads.ts` does not declare `categoryId`
+   - What's unclear: Does the API actually serialize `categoryId` in the response or is it filtered?
+   - Recommendation: Planner should add `categoryId: number` to `ThreadWithCandidates` interface and verify the server route includes it. Alternatively, use `thread.candidates[0]?.categoryId` as a fallback since all candidates share the thread's category.
+
+2. **Selector placement on narrow viewports**
+   - What we know: Thread header already has breadcrumb, title/status pill, and toolbar row
+   - What's unclear: Three rows in mobile header may feel cramped
+   - Recommendation: Planner's discretion — can be inline with toolbar or as a third header row. Research finds no hard constraint.
+
+3. **ComparisonTable delta row placement**
+   - What we know: ATTRIBUTE_ROWS pattern is extensible (just add an object to the array)
+   - What's unclear: Whether impact rows should live inside the weight/price rows or as separate "Impact Weight" / "Impact Price" rows
+   - Recommendation: Separate labeled rows to avoid conflating candidate-relative deltas (lightest/cheapest highlighting) with setup impact deltas.
+
+---
+
+## Validation Architecture
+
+### Test Framework
+| Property | Value |
+|----------|-------|
+| Framework | Bun test (built-in) |
+| Config file | none — bun test discovers tests automatically |
+| Quick run command | `bun test tests/services/` |
+| Full suite command | `bun test` |
+
+### Phase Requirements → Test Map
+| Req ID | Behavior | Test Type | Automated Command | File Exists? |
+|--------|----------|-----------|-------------------|-------------|
+| IMPC-01 | Delta values computed and passed to candidates when setup selected | unit (hook logic) | `bun test tests/lib/impactDeltas.test.ts` | Wave 0 |
+| IMPC-02 | Replace mode triggered when setup contains item in same category as thread | unit | `bun test tests/lib/impactDeltas.test.ts` | Wave 0 |
+| IMPC-03 | Add mode used when no category match, delta equals candidate value | unit | `bun test tests/lib/impactDeltas.test.ts` | Wave 0 |
+| IMPC-04 | Null weight candidate returns null delta (not zero, not NaN) | unit | `bun test tests/lib/impactDeltas.test.ts` | Wave 0 |
+
+**Note:** Delta computation is pure arithmetic logic and can be tested outside React via an extracted pure function. The recommended approach is to extract `computeImpactDeltas(candidates, setupItems, threadCategoryId)` as a pure function and test it directly — no React Testing Library needed.
+
+### Sampling Rate
+- **Per task commit:** `bun test tests/lib/`
+- **Per wave merge:** `bun test`
+- **Phase gate:** Full suite green before `/gsd:verify-work`
+
+### Wave 0 Gaps
+- [ ] `tests/lib/impactDeltas.test.ts` — covers IMPC-01 through IMPC-04 via pure function extracted from `useImpactDeltas`
+- [ ] `tests/lib/` directory — create if not exists (pure utility tests go here)
+
+---
+
+## Sources
+
+### Primary (HIGH confidence)
+- Direct codebase read — `src/db/schema.ts` — verified `threadCandidates.categoryId`, `items.categoryId`, `setupItems` join structure
+- Direct codebase read — `src/client/hooks/useSetups.ts` — verified `SetupItemWithCategory` type includes `categoryId`, `weightGrams`, `priceCents`
+- Direct codebase read — `src/client/hooks/useThreads.ts` — identified missing `categoryId` in `ThreadWithCandidates` interface
+- Direct codebase read — `src/client/components/ComparisonTable.tsx` — verified ATTRIBUTE_ROWS pattern and existing delta computation pattern
+- Direct codebase read — `src/client/stores/uiStore.ts` — verified `selectedSetupId` does not yet exist, pattern for adding it
+- Direct codebase read — `src/client/lib/formatters.ts` — verified `formatWeight` / `formatPrice` reusability with abs values
+- Direct codebase read — `tests/helpers/db.ts` — verified test infrastructure, no schema changes needed
+
+### Secondary (MEDIUM confidence)
+- `.planning/STATE.md` — confirms "Impact preview must distinguish add-mode vs replace-mode by category match" as locked architectural decision
+
+### Tertiary (LOW confidence)
+- None
+
+---
+
+## Metadata
+
+**Confidence breakdown:**
+- Standard stack: HIGH — zero new dependencies; all libraries confirmed in package.json
+- Architecture: HIGH — derived entirely from reading existing codebase; patterns are directly reusable
+- Pitfalls: HIGH — identified from code inspection (ThreadWithCandidates missing categoryId is a concrete finding, not speculation)
+- Delta math: HIGH — straightforward arithmetic, verified types from schema
+
+**Research date:** 2026-03-17
+**Valid until:** 2026-04-17 (stable codebase; no external library research)

.planning/phases/13-setup-impact-preview/13-VALIDATION.md

@@ -0,0 +1,78 @@
+---
+phase: 13
+slug: setup-impact-preview
+status: draft
+nyquist_compliant: false
+wave_0_complete: false
+created: 2026-03-17
+---
+
+# Phase 13 — Validation Strategy
+
+> Per-phase validation contract for feedback sampling during execution.
+
+---
+
+## Test Infrastructure
+
+| Property | Value |
+|----------|-------|
+| **Framework** | bun test (built-in) |
+| **Config file** | bunfig.toml |
+| **Quick run command** | `bun test` |
+| **Full suite command** | `bun test` |
+| **Estimated runtime** | ~5 seconds |
+
+---
+
+## Sampling Rate
+
+- **After every task commit:** Run `bun test`
+- **After every plan wave:** Run `bun test`
+- **Before `/gsd:verify-work`:** Full suite must be green
+- **Max feedback latency:** 5 seconds
+
+---
+
+## Per-Task Verification Map
+
+| Task ID | Plan | Wave | Requirement | Test Type | Automated Command | File Exists | Status |
+|---------|------|------|-------------|-----------|-------------------|-------------|--------|
+| 13-01-01 | 01 | 1 | IMPC-01 | unit | `bun test` | ❌ W0 | ⬜ pending |
+| 13-01-02 | 01 | 1 | IMPC-02 | unit | `bun test` | ❌ W0 | ⬜ pending |
+| 13-01-03 | 01 | 1 | IMPC-03 | unit | `bun test` | ❌ W0 | ⬜ pending |
+| 13-01-04 | 01 | 1 | IMPC-04 | unit | `bun test` | ❌ W0 | ⬜ pending |
+
+*Status: ⬜ pending · ✅ green · ❌ red · ⚠️ flaky*
+
+---
+
+## Wave 0 Requirements
+
+- [ ] Test stubs for IMPC-01 through IMPC-04 impact delta computation
+- [ ] Test fixtures for setup items and thread candidates with weight/price data
+
+*If none: "Existing infrastructure covers all phase requirements."*
+
+---
+
+## Manual-Only Verifications
+
+| Behavior | Requirement | Why Manual | Test Instructions |
+|----------|-------------|------------|-------------------|
+| Setup dropdown renders in thread header | IMPC-01 | Visual/UI placement | Open a thread, verify dropdown appears with all setups listed |
+| Delta labels display correctly (add vs replace) | IMPC-03 | Visual formatting | Select setup with no category match, verify "add" label |
+| Missing weight shows "-- (no weight data)" | IMPC-04 | Visual indicator | Add candidate with no weight, verify placeholder text |
+
+---
+
+## Validation Sign-Off
+
+- [ ] All tasks have `<automated>` verify or Wave 0 dependencies
+- [ ] Sampling continuity: no 3 consecutive tasks without automated verify
+- [ ] Wave 0 covers all MISSING references
+- [ ] No watch-mode flags
+- [ ] Feedback latency < 5s
+- [ ] `nyquist_compliant: true` set in frontmatter
+
+**Approval:** pending

.planning/research/ARCHITECTURE.md

@@ -1,362 +1,577 @@
 # Architecture Research
 
-**Domain:** Single-user gear management and purchase planning web app
-**Researched:** 2026-03-14
+**Domain:** Gear management app -- v1.3 Research & Decision Tools (candidate comparison, setup impact preview, ranking/pros-cons)
+**Researched:** 2026-03-16
 **Confidence:** HIGH
 
-## Standard Architecture
+## System Overview: Integration Map
 
-### System Overview
+The v1.3 features integrate primarily on the thread detail page and its data layer. This diagram shows where new components slot in relative to the current architecture.
 
 ```
-┌─────────────────────────────────────────────────────────────────┐
-│                        Client (Browser)                         │
-│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐   │
-│  │ Dashboard  │  │Collection │  │  Threads  │  │  Setups   │   │
-│  │   Page     │  │   Page    │  │   Page    │  │   Page    │   │
-│  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘   │
-│        │              │              │              │           │
-│  ┌─────┴──────────────┴──────────────┴──────────────┴─────┐    │
-│  │              Shared UI Components                       │    │
-│  │  (ItemCard, ComparisonTable, WeightBadge, CostBadge)    │    │
-│  └────────────────────────┬───────────────────────────────┘    │
-│                           │ fetch()                            │
-├───────────────────────────┼────────────────────────────────────┤
-│                    Bun.serve()                                  │
-│  ┌────────────────────────┴───────────────────────────────┐    │
-│  │                   API Routes Layer                      │    │
-│  │   /api/items    /api/threads    /api/setups             │    │
-│  │   /api/stats    /api/candidates /api/images             │    │
-│  └────────────────────────┬───────────────────────────────┘    │
-│                           │                                    │
-│  ┌────────────────────────┴───────────────────────────────┐    │
-│  │                  Service Layer                          │    │
-│  │   ItemService  ThreadService  SetupService  StatsService│    │
-│  └────────────────────────┬───────────────────────────────┘    │
-│                           │                                    │
-│  ┌────────────────────────┴───────────────────────────────┐    │
-│  │               Data Access (Drizzle ORM)                 │    │
-│  │                    Schema + Queries                     │    │
-│  └────────────────────────┬───────────────────────────────┘    │
-│                           │                                    │
-│  ┌────────────────────────┴───────────────────────────────┐    │
-│  │                  SQLite (bun:sqlite)                    │    │
-│  │                   gearbox.db file                       │    │
-│  └────────────────────────────────────────────────────────┘    │
-└─────────────────────────────────────────────────────────────────┘
+CLIENT LAYER
++-----------------------------------------------------------------+
+|  Routes                                                         |
+|  +-------------------+  +--------------------+                  |
+|  | /threads/$threadId|  | (existing routes)   |                 |
+|  |     [MODIFIED]    |  |   [NO CHANGE]       |                 |
+|  +--------+----------+  +--------------------+                  |
+|           |                                                     |
+|  Components (NEW)                                               |
+|  +----------------------+  +---------------------------+        |
+|  | CandidateCompare     |  | SetupImpactSelector       |        |
+|  | (side-by-side table) |  | (setup picker + delta row)|        |
+|  +----------------------+  +---------------------------+        |
+|  +----------------------+                                       |
+|  | CandidateRankList    |                                       |
+|  | (drag-to-reorder)    |                                       |
+|  +----------------------+                                       |
+|                                                                 |
+|  Components (MODIFIED)                                          |
+|  +----------------------+  +---------------------------+        |
+|  | CandidateCard        |  | CandidateForm             |        |
+|  | +rank badge          |  | +pros/cons fields         |        |
+|  | +pros/cons display   |  +---------------------------+        |
+|  +----------------------+                                       |
+|                                                                 |
+|  Hooks (NEW)                Hooks (MODIFIED)                    |
+|  +---------------------+   +---------------------+             |
+|  | useReorderCandidates|   | useCandidates.ts    |             |
+|  | useSetupImpact      |   | +reorder mutation   |             |
+|  +---------------------+   | +pros/cons in update|             |
+|                             +---------------------+             |
+|                                                                 |
+|  Stores (MODIFIED)                                              |
+|  +---------------------+                                       |
+|  | uiStore.ts          |                                       |
+|  | +compareMode bool   |                                       |
+|  | +selectedSetupId    |                                       |
+|  +---------------------+                                       |
++-----------------------------------------------------------------+
+|  API Layer: lib/api.ts -- NO CHANGE                             |
++-----------------------------------------------------------------+
+SERVER LAYER
+|  Routes (MODIFIED)                                              |
+|  +--------------------+                                         |
+|  | threads.ts         |                                         |
+|  | +PATCH /reorder    |                                         |
+|  +--------------------+                                         |
+|                                                                 |
+|  Services (MODIFIED)                                            |
+|  +--------------------+                                         |
+|  | thread.service.ts  |                                         |
+|  | +reorderCandidates |                                         |
+|  | +pros/cons in CRUD |                                         |
+|  +--------------------+                                         |
++---------+---------------------------------------------------+---+
+DATABASE LAYER
+|  schema.ts (MODIFIED)                                           |
+|  +----------------------------------------------------------+  |
+|  | thread_candidates:                                        |  |
+|  |   +sort_order INTEGER NOT NULL DEFAULT 0                 |  |
+|  |   +pros TEXT                                             |  |
+|  |   +cons TEXT                                             |  |
+|  +----------------------------------------------------------+  |
+|                                                                 |
+|  tests/helpers/db.ts (MODIFIED -- add new columns)             |
++-----------------------------------------------------------------+
 ```
 
-This is a monolithic full-stack app running on a single Bun process. No microservices, no separate API server, no Docker. Bun's built-in fullstack dev server handles both static asset bundling and API routes from a single `Bun.serve()` call. SQLite is the database -- embedded, zero-config, accessed through Bun's native `bun:sqlite` module (3-6x faster than better-sqlite3).
+## Feature-by-Feature Integration
 
-### Component Responsibilities
+### Feature 1: Side-by-Side Candidate Comparison
 
-| Component | Responsibility | Typical Implementation |
-|-----------|----------------|------------------------|
-| Dashboard Page | Entry point, summary cards, navigation | React page showing item count, active threads, setup stats |
-| Collection Page | CRUD for gear items, filtering, sorting | React page with list/grid views, item detail modal |
-| Threads Page | Purchase research threads with candidates | React page with thread list, candidate comparison view |
-| Setups Page | Compose named setups from collection items | React page with drag/drop or select-to-add from collection |
-| API Routes | HTTP endpoints for all data operations | Bun.serve() route handlers, REST-style |
-| Service Layer | Business logic, calculations (weight/cost totals) | TypeScript modules with domain logic |
-| Data Access | Schema definition, queries, migrations | Drizzle ORM with SQLite dialect |
-| SQLite DB | Persistent storage | Single file, bun:sqlite native module |
-| Image Storage | Photo uploads for gear items | Local filesystem (`./uploads/`) served as static files |
+**Scope:** Client-only derived view. All candidate data is already fetched by `useThread(threadId)` which returns `thread.candidates[]` with all fields including weight, price, notes, image, productUrl, and status. No new API endpoint is needed. The comparison view is a toggle on the thread detail page that reorganizes the existing data into a table layout.
 
-## Recommended Project Structure
+**Integration points:**
+
+| Layer | File | Change Type | Details |
+|-------|------|-------------|---------|
+| Client | `routes/threads/$threadId.tsx` | MODIFY | Add "Compare" toggle button; conditionally render grid vs comparison layout |
+| Client | NEW `components/CandidateCompare.tsx` | NEW | Side-by-side table component; accepts `candidates[]` array |
+| Client | `stores/uiStore.ts` | MODIFY | Add `compareMode: boolean`, `toggleCompareMode()` |
+
+**Data flow:**
 
 ```
-src/
-├── index.tsx              # Bun.serve() entry point, route registration
-├── pages/                 # HTML entrypoints for each page
-│   ├── index.html         # Dashboard
-│   ├── collection.html    # Collection page
-│   ├── threads.html       # Planning threads page
-│   └── setups.html        # Setups page
-├── client/                # React frontend code
-│   ├── components/        # Shared UI components
-│   │   ├── ItemCard.tsx
-│   │   ├── WeightBadge.tsx
-│   │   ├── CostBadge.tsx
-│   │   ├── ComparisonTable.tsx
-│   │   ├── StatusBadge.tsx
-│   │   └── Layout.tsx
-│   ├── pages/             # Page-level React components
-│   │   ├── Dashboard.tsx
-│   │   ├── Collection.tsx
-│   │   ├── ThreadList.tsx
-│   │   ├── ThreadDetail.tsx
-│   │   ├── SetupList.tsx
-│   │   └── SetupDetail.tsx
-│   ├── hooks/             # Custom React hooks
-│   │   ├── useItems.ts
-│   │   ├── useThreads.ts
-│   │   └── useSetups.ts
-│   └── lib/               # Client utilities
-│       ├── api.ts         # Fetch wrapper for API calls
-│       └── formatters.ts  # Weight/cost formatting helpers
-├── server/                # Backend code
-│   ├── routes/            # API route handlers
-│   │   ├── items.ts
-│   │   ├── threads.ts
-│   │   ├── candidates.ts
-│   │   ├── setups.ts
-│   │   ├── images.ts
-│   │   └── stats.ts
-│   └── services/          # Business logic
-│       ├── item.service.ts
-│       ├── thread.service.ts
-│       ├── setup.service.ts
-│       └── stats.service.ts
-├── db/                    # Database layer
-│   ├── schema.ts          # Drizzle table definitions
-│   ├── index.ts           # Database connection singleton
-│   ├── seed.ts            # Optional dev seed data
-│   └── migrations/        # Drizzle Kit generated migrations
-├── shared/                # Types shared between client and server
-│   └── types.ts           # Item, Thread, Candidate, Setup types
-uploads/                   # Gear photos (gitignored, outside src/)
-drizzle.config.ts          # Drizzle Kit config
+useThread(threadId) -> thread.candidates[] (already fetched)
+    |
+    +-- compareMode? (local UI state in uiStore)
+           |
+           +-- false: existing CandidateCard grid (unchanged)
+           +-- true: CandidateCompare table (new component)
+                  |
+                  +-- Columns: [Field Label] [Candidate A] [Candidate B] [Candidate N]
+                  +-- Rows: Image, Name, Weight, Price, Status, Notes, Link
+                  +-- Delta row: weight and price diffs relative to lightest/cheapest
 ```
 
-### Structure Rationale
+**No server changes required.** Thread data already includes all comparison fields. The component is purely presentational, transforming the existing `CandidateWithCategory[]` array into a column-per-candidate table.
 
-- **`client/` and `server/` separation:** Clear boundary between browser code and server code. Both import from `shared/` and `db/` (server only) but never from each other.
-- **`pages/` HTML entrypoints:** Bun's fullstack server uses HTML files as route entrypoints. Each HTML file imports its corresponding React component tree.
-- **`server/routes/` + `server/services/`:** Routes handle HTTP concerns (parsing params, status codes). Services handle business logic (calculating totals, validating state transitions). This prevents bloated route handlers.
-- **`db/schema.ts` as single source of truth:** All table definitions in one file. Drizzle infers TypeScript types from the schema, so types flow from DB to API to client.
-- **`shared/types.ts`:** API response types and domain enums shared between client and server. Avoids type drift.
-- **`uploads/` outside `src/`:** User-uploaded images are not source code. Served as static files by Bun.
+**CandidateCompare component structure:**
+
+```typescript
+// src/client/components/CandidateCompare.tsx
+interface CandidateCompareProps {
+  candidates: CandidateWithCategory[];
+  isActive: boolean;
+}
+
+export function CandidateCompare({ candidates, isActive }: CandidateCompareProps) {
+  // Rows: image, name, weight (with delta), price (with delta), status, notes, link
+  // Highlight lowest weight in blue, lowest price in green
+  // Delta: weight diff from lightest candidate, price diff from cheapest
+  // Scrollable horizontally if > 3-4 candidates
+}
+```
+
+**Weight/price delta display:**
+
+```typescript
+// Derive relative comparison -- no server needed
+const minWeight = Math.min(...candidates.filter(c => c.weightGrams != null).map(c => c.weightGrams!));
+const minPrice  = Math.min(...candidates.filter(c => c.priceCents  != null).map(c => c.priceCents!));
+
+// For each candidate:
+const weightDelta = candidate.weightGrams != null
+  ? candidate.weightGrams - minWeight
+  : null;
+// Display: "+34g" in gray, "lightest" in blue (delta === 0)
+```
+
+**UI toggle placement:** A "Compare" button in the thread detail header, next to "Add Candidate". Toggling it swaps the layout from the card grid to the comparison table. Toggle state lives in `uiStore.compareMode` so it persists if the user navigates to a candidate edit panel and returns.
+
+---
+
+### Feature 2: Setup Impact Preview
+
+**Scope:** For each candidate, show the weight and cost delta it would create if added to a user-selected setup. The user picks a setup from a dropdown on the thread detail page; all candidate cards (or comparison table) then display a "+/-" delta row.
+
+**Integration points:**
+
+| Layer | File | Change Type | Details |
+|-------|------|-------------|---------|
+| Client | `routes/threads/$threadId.tsx` | MODIFY | Add setup selector; pass `selectedSetupId` to card/compare components |
+| Client | NEW `components/SetupImpactRow.tsx` | NEW | Small delta display row: "+320g / +$89" |
+| Client | `hooks/useSetups.ts` | NO CHANGE | `useSetup(setupId)` already fetches setup with items and their `weightGrams`/`priceCents` |
+| Client | `stores/uiStore.ts` | MODIFY | Add `impactSetupId: number | null`, `setImpactSetupId(id)` |
+| Server | ALL | NO CHANGE | Impact is computed client-side from already-available data |
+
+**Data flow:**
+
+```
+User selects setup from dropdown
+    |
+    +-- uiStore.impactSetupId = selectedSetupId
+    |
+    +-- useSetup(impactSetupId) (conditional query, already exists)
+           |
+           +-- setup.items[] with weightGrams and priceCents
+           |
+           +-- setupTotalWeight = setup.items.reduce((sum, i) => sum + (i.weightGrams ?? 0), 0)
+           +-- setupTotalCost   = setup.items.reduce((sum, i) => sum + (i.priceCents  ?? 0), 0)
+           |
+           +-- Per candidate:
+                  weightImpact = candidate.weightGrams (absolute, not a replacement)
+                  costImpact   = candidate.priceCents
+                  // "Adding this item would add +320g / +$89 to the setup"
+                  // Note: this is an "add to" preview, not a "replace existing item" preview
+                  // Thread items are potential new additions, not replacements
+```
+
+**Why client-only:** The setup total weight is available from `useSetup(setupId)` which returns `items[]` with all fields. Adding a candidate to a setup is purely additive: `newTotal = setupCurrentTotal + candidateWeight`. No server endpoint needed. The `useSetup` query is already conditionally enabled and cached by React Query.
+
+**Setup selector placement:** A compact dropdown (using existing `useSetups()` data) in the thread detail header area beneath the thread name. "Preview impact on setup: [Select setup...]". When null, the impact row is hidden. Persists in `uiStore` for the session.
+
+**SetupImpactRow component:**
+
+```typescript
+// src/client/components/SetupImpactRow.tsx
+interface SetupImpactRowProps {
+  candidateWeightGrams: number | null;
+  candidatePriceCents: number | null;
+  setupTotalWeight: number;     // existing setup total
+  setupTotalCost: number;       // existing setup total (cents)
+}
+
+export function SetupImpactRow({ candidateWeightGrams, candidatePriceCents, setupTotalWeight, setupTotalCost }: SetupImpactRowProps) {
+  const unit = useWeightUnit();
+  const currency = useCurrency();
+  // Display: "+320g" and "+$89" with soft color (gray or blue)
+  // If null weight/price, show "--"
+}
+```
+
+---
+
+### Feature 3: Candidate Ranking (Drag-to-Reorder) with Pros/Cons
+
+**Scope:** Users can drag candidates to set a preferred rank order. Each candidate gains `pros` and `cons` text fields. Rank order is persisted to the database as a `sortOrder` integer on `thread_candidates`. `framer-motion` is already installed (v12.37.0) and has `Reorder` components built-in.
+
+**Integration points:**
+
+| Layer | File | Change Type | Details |
+|-------|------|-------------|---------|
+| DB | `schema.ts` | MODIFY | Add `sortOrder INTEGER NOT NULL DEFAULT 0`, `pros TEXT`, `cons TEXT` to `threadCandidates` |
+| DB | Drizzle migration | NEW | Three new columns via `db:generate` |
+| Shared | `schemas.ts` | MODIFY | Add `sortOrder`, `pros`, `cons` to `createCandidateSchema` and `updateCandidateSchema` |
+| Shared | `types.ts` | NO CHANGE | Auto-infers from Drizzle schema |
+| Server | `thread.service.ts` | MODIFY | `getThreadWithCandidates` orders by `sort_order ASC`; add `reorderCandidates` function; `createCandidate` sets `sortOrder` to max+1; include `pros`/`cons` in create/update |
+| Server | `routes/threads.ts` | MODIFY | Add `PATCH /:id/candidates/reorder` endpoint |
+| Client | `hooks/useCandidates.ts` | MODIFY | Add `useReorderCandidates(threadId)` mutation |
+| Client | `routes/threads/$threadId.tsx` | MODIFY | Render `Reorder.Group` from framer-motion; wire reorder mutation |
+| Client | `components/CandidateCard.tsx` | MODIFY | Add rank badge (1st, 2nd, 3rd); add pros/cons display (collapsed by default, expand on hover or click) |
+| Client | `components/CandidateForm.tsx` | MODIFY | Add pros and cons textarea fields |
+| Test | `tests/helpers/db.ts` | MODIFY | Add `sort_order`, `pros`, `cons` columns to `thread_candidates` CREATE TABLE |
+
+**Schema change:**
+
+```typescript
+// In src/db/schema.ts -- thread_candidates table additions
+export const threadCandidates = sqliteTable("thread_candidates", {
+  // ... existing fields unchanged ...
+  sortOrder: integer("sort_order").notNull().default(0),
+  pros: text("pros"),
+  cons: text("cons"),
+});
+```
+
+**Sort order in service:**
+
+```typescript
+// In thread.service.ts -- getThreadWithCandidates
+// Change: add .orderBy(asc(threadCandidates.sortOrder))
+const candidateList = db
+  .select({ ... })
+  .from(threadCandidates)
+  .innerJoin(categories, eq(threadCandidates.categoryId, categories.id))
+  .where(eq(threadCandidates.threadId, threadId))
+  .orderBy(asc(threadCandidates.sortOrder))  // NEW
+  .all();
+```
+
+**New service function for batch reorder:**
+
+```typescript
+// In thread.service.ts
+export function reorderCandidates(
+  db: Db = prodDb,
+  threadId: number,
+  orderedIds: number[],  // candidate IDs in new rank order
+) {
+  return db.transaction((tx) => {
+    for (let i = 0; i < orderedIds.length; i++) {
+      tx.update(threadCandidates)
+        .set({ sortOrder: i, updatedAt: new Date() })
+        .where(
+          sql`${threadCandidates.id} = ${orderedIds[i]} AND ${threadCandidates.threadId} = ${threadId}`,
+        )
+        .run();
+    }
+  });
+}
+```
+
+**New API endpoint:**
+
+```typescript
+// In routes/threads.ts -- new PATCH route
+// Schema: z.object({ orderedIds: z.array(z.number().int().positive()) })
+app.patch("/:id/candidates/reorder", zValidator("json", reorderCandidatesSchema), (c) => {
+  const db = c.get("db");
+  const threadId = Number(c.req.param("id"));
+  const { orderedIds } = c.req.valid("json");
+  reorderCandidates(db, threadId, orderedIds);
+  return c.json({ success: true });
+});
+```
+
+**Client-side drag with framer-motion Reorder:**
+
+```typescript
+// In routes/threads/$threadId.tsx
+import { Reorder } from "framer-motion";
+
+// Local state tracks optimistic order
+const [orderedCandidates, setOrderedCandidates] = useState(thread.candidates);
+
+// Sync with server data when it changes
+useEffect(() => {
+  setOrderedCandidates(thread.candidates);
+}, [thread.candidates]);
+
+// On drag end, persist to server
+const reorderCandidates = useReorderCandidates(threadId);
+
+function handleReorderEnd() {
+  reorderCandidates.mutate(orderedCandidates.map(c => c.id));
+}
+
+// Render
+<Reorder.Group
+  axis="y"
+  values={orderedCandidates}
+  onReorder={setOrderedCandidates}
+>
+  {orderedCandidates.map((candidate, index) => (
+    <Reorder.Item key={candidate.id} value={candidate} onDragEnd={handleReorderEnd}>
+      <CandidateCard ... rank={index + 1} />
+    </Reorder.Item>
+  ))}
+</Reorder.Group>
+```
+
+**Rank badge on CandidateCard:**
+
+```typescript
+// Rank is passed as a prop, displayed as "1" / "2" / "3" / "..." badge
+// Top 3 get medal-style styling (gold/silver/bronze), rest are plain gray
+const RANK_STYLES = {
+  1: "bg-amber-100 text-amber-700",   // gold
+  2: "bg-gray-200 text-gray-600",     // silver
+  3: "bg-orange-100 text-orange-600", // bronze
+};
+```
+
+**Pros/cons display in CandidateCard:** Show a small "+" (green) and "-" (red) indicator if the candidate has pros/cons content. Full text shown on hover tooltip or in the edit panel. Not shown inline on the card to preserve the compact layout.
+
+**New candidate sort order:** When creating a new candidate, set `sortOrder` to the current count of candidates in the thread (appends to end):
+
+```typescript
+// In createCandidate service
+const existingCount = db
+  .select({ count: sql<number>`COUNT(*)` })
+  .from(threadCandidates)
+  .where(eq(threadCandidates.threadId, threadId))
+  .get()?.count ?? 0;
+
+// Insert with sortOrder = existingCount (0-indexed, so new item goes to end)
+```
+
+---
+
+## New vs Modified Files -- Complete Inventory
+
+### New Files (3)
+
+| File | Purpose |
+|------|---------|
+| `src/client/components/CandidateCompare.tsx` | Side-by-side comparison table; pure presentational, no new API |
+| `src/client/components/SetupImpactRow.tsx` | Delta display row (+weight/+price vs setup total); pure presentational |
+| Drizzle migration file | Three new columns on `thread_candidates` (`sort_order`, `pros`, `cons`) |
+
+### Modified Files (12)
+
+| File | What Changes |
+|------|-------------|
+| `src/db/schema.ts` | Add `sortOrder`, `pros`, `cons` to `threadCandidates` |
+| `src/shared/schemas.ts` | Add `sortOrder`, `pros`, `cons` to candidate schemas; add `reorderCandidatesSchema` |
+| `src/server/services/thread.service.ts` | Order candidates by `sortOrder`; add `reorderCandidates` function; include `pros`/`cons` in create/update; set `sortOrder` on create |
+| `src/server/routes/threads.ts` | Add `PATCH /:id/candidates/reorder` endpoint |
+| `src/client/hooks/useCandidates.ts` | Add `useReorderCandidates(threadId)` mutation |
+| `src/client/components/CandidateCard.tsx` | Accept `rank` prop; show rank badge; show pros/cons indicators |
+| `src/client/components/CandidateForm.tsx` | Add pros and cons textarea fields |
+| `src/client/routes/threads/$threadId.tsx` | Add compare toggle; add setup selector; add `Reorder.Group` DnD; manage local order state |
+| `src/client/stores/uiStore.ts` | Add `compareMode`, `toggleCompareMode()`, `impactSetupId`, `setImpactSetupId()` |
+| `tests/helpers/db.ts` | Add `sort_order`, `pros`, `cons` columns to `thread_candidates` CREATE TABLE |
+
+### Unchanged Files
+
+| File | Why No Change |
+|------|-------------|
+| `src/client/lib/api.ts` | Existing `apiPatch` handles reorder endpoint |
+| `src/client/hooks/useSetups.ts` | `useSetup(id)` already fetches items with weight/price; `useSetups()` provides dropdown data |
+| `src/client/hooks/useThreads.ts` | `CandidateWithCategory` type auto-updates from schema inference |
+| `src/server/services/setup.service.ts` | No setup changes needed |
+| `src/server/routes/setups.ts` | No setup endpoint changes needed |
+| `src/server/services/totals.service.ts` | Impact is client-computed, not a server aggregate |
+| `src/server/routes/totals.ts` | No new endpoints |
+| `package.json` | `framer-motion` already installed at v12.37.0 |
+
+---
+
+## Data Flow Changes Summary
+
+### Existing Data Flows (unchanged)
+
+```
+useThread(id)  -> GET /api/threads/:id -> getThreadWithCandidates(db, id) -> thread + candidates[]
+useSetups()    -> GET /api/setups      -> getAllSetups(db)                 -> setups[]
+useSetup(id)   -> GET /api/setups/:id  -> getSetupWithItems(db, id)       -> setup + items[]
+```
+
+### New Data Flows
+
+```
+Side-by-Side Comparison (client-only):
+  thread.candidates[] (already in cache)
+      -> uiStore.compareMode == true
+      -> CandidateCompare component
+      -> renders column-per-candidate table
+      -> no API call
+
+Setup Impact Preview (client-only computation):
+  uiStore.impactSetupId -> useSetup(impactSetupId)
+      -> setup.items[].reduce(sum, weightGrams) = setupCurrentWeight
+      -> per candidate: impactWeight = candidate.weightGrams
+      -> SetupImpactRow displays "+Xg / +$Y"
+      -> no API call
+
+Candidate Reorder (new write endpoint):
+  DnD drag end -> setOrderedCandidates (local state)
+      -> useReorderCandidates.mutate(orderedIds)
+      -> PATCH /api/threads/:id/candidates/reorder
+      -> reorderCandidates(db, threadId, orderedIds)  [transaction loop]
+      -> invalidate ["threads", threadId]
+      -> useThread refetches -> candidates come back in new sortOrder
+```
+
+---
+
+## Build Order (Dependency-Aware)
+
+Features have a clear dependency order based on shared schema migration and UI surface:
+
+```
+Phase 1: Schema + Pros/Cons fields
+  +-- Add sort_order, pros, cons to threadCandidates schema
+  +-- Run single Drizzle migration (batch all three columns together)
+  +-- Update tests/helpers/db.ts
+  +-- Add pros/cons to candidate create/update service + route
+  +-- Add pros/cons fields to CandidateForm
+  +-- Add pros/cons display indicators to CandidateCard
+  +-- Dependencies: none -- foundation for Phase 2 and 3
+
+Phase 2: Ranking (Drag-to-Reorder)
+  +-- Requires Phase 1 (sort_order column)
+  +-- Add reorderCandidates service function
+  +-- Add PATCH /reorder route
+  +-- Add useReorderCandidates hook
+  +-- Add Reorder.Group to threadId route
+  +-- Show rank badges on CandidateCard
+  +-- Dependencies: Phase 1 (sort_order in DB)
+
+Phase 3: Side-by-Side Comparison
+  +-- No schema dependency (uses existing fields)
+  +-- Can be built alongside Phase 2, but benefits from rank display being complete
+  +-- Add compareMode to uiStore
+  +-- Create CandidateCompare component
+  +-- Wire toggle button in thread detail header
+  +-- Dependencies: none (pure client-side with existing data)
+
+Phase 4: Setup Impact Preview
+  +-- No schema dependency
+  +-- Easiest to build after the thread detail page already has setup selector UI
+  +-- Add impactSetupId to uiStore
+  +-- Create SetupImpactRow component
+  +-- Wire setup selector dropdown in thread detail header
+  +-- useSetup() conditionally enabled when impactSetupId set
+  +-- Dependencies: none (uses existing useSetup hook)
+```
+
+**Recommended sequence:** Phase 1 + 2 together (schema-touching work in one pass), then Phase 3, then Phase 4. Phases 3 and 4 are independent pure-client additions that can be built in parallel.
+
+---
 
 ## Architectural Patterns
 
-### Pattern 1: Bun Fullstack Monolith
+### Pattern 1: Optimistic Local State for Drag Reorder
 
-**What:** Single Bun.serve() process serves HTML pages, bundled React assets, and API routes. No separate frontend dev server, no proxy config, no CORS.
-**When to use:** Single-user apps, prototypes, small team projects where deployment simplicity matters.
-**Trade-offs:** Extremely simple to deploy (one process, one command), but no horizontal scaling. For GearBox this is ideal -- single user, no scaling needed.
+**What:** Maintain a local `orderedCandidates` state in the route component. Apply drag updates immediately (optimistic), sync to server on drag end only.
+**When to use:** Any list that supports drag reorder where immediate visual feedback matters.
+**Trade-offs:** Local state can drift from server if the reorder request fails. Given single-user SQLite, failure is extremely unlikely. A full optimistic update with rollback would be overengineering here.
 
-**Example:**
 ```typescript
-// src/index.tsx
-import homepage from "./pages/index.html";
-import collectionPage from "./pages/collection.html";
-import { itemRoutes } from "./server/routes/items";
-import { threadRoutes } from "./server/routes/threads";
+// Local state drives the render; server state updates it on fetch
+const [orderedCandidates, setOrderedCandidates] = useState(thread.candidates);
 
-Bun.serve({
-  routes: {
-    "/": homepage,
-    "/collection": collectionPage,
-    ...itemRoutes,
-    ...threadRoutes,
-  },
-  development: true,
-});
+useEffect(() => {
+  // Sync when server data changes (after reorder mutation settles)
+  setOrderedCandidates(thread.candidates);
+}, [thread.candidates]);
 ```
 
-### Pattern 2: Service Layer for Business Logic
+### Pattern 2: Client-Computed Derived Data (No New Endpoints)
 
-**What:** Route handlers delegate to service modules that contain domain logic. Services are pure functions or classes that take data in and return results, with no HTTP awareness.
-**When to use:** When routes would otherwise contain calculation logic (weight totals, cost impact analysis, status transitions).
-**Trade-offs:** Slightly more files, but logic is testable without HTTP mocking and reusable across routes.
+**What:** Derive comparison deltas and setup impact numbers from data already in the React Query cache.
+**When to use:** When all required data is already fetched, computation is simple (arithmetic), and the result is not needed on the server.
+**Trade-offs:** Correctly avoids API proliferation. The risk is stale data, but React Query's default `staleTime: 0` means data is fresh.
 
-**Example:**
 ```typescript
-// server/services/setup.service.ts
-export function calculateSetupTotals(items: Item[]): SetupTotals {
-  return {
-    totalWeight: items.reduce((sum, i) => sum + (i.weightGrams ?? 0), 0),
-    totalCost: items.reduce((sum, i) => sum + (i.priceCents ?? 0), 0),
-    itemCount: items.length,
-  };
-}
-
-export function computeCandidateImpact(
-  setup: Setup,
-  candidate: Candidate
-): Impact {
-  const currentTotals = calculateSetupTotals(setup.items);
-  return {
-    weightDelta: (candidate.weightGrams ?? 0) - (setup.replacingItem?.weightGrams ?? 0),
-    costDelta: (candidate.priceCents ?? 0) - (setup.replacingItem?.priceCents ?? 0),
-    newTotalWeight: currentTotals.totalWeight + this.weightDelta,
-    newTotalCost: currentTotals.totalCost + this.costDelta,
-  };
-}
+// Impact preview: pure client arithmetic, no fetch
+const setupWeight = setup.items.reduce((sum, i) => sum + (i.weightGrams ?? 0), 0);
+const candidateImpact = candidateWeightGrams ?? 0;
+const newTotal = setupWeight + candidateImpact;
+const delta = candidateImpact; // "+320g"
 ```
 
-### Pattern 3: Drizzle ORM with bun:sqlite
+### Pattern 3: uiStore for Cross-Panel Persistent UI State
 
-**What:** Drizzle provides type-safe SQL query building and schema-as-code migrations on top of Bun's native SQLite. Schema definitions double as TypeScript type sources.
-**When to use:** Any Bun + SQLite project that wants type safety without the overhead of a full ORM like Prisma.
-**Trade-offs:** Lightweight (no query engine, no runtime overhead). SQL-first philosophy means you write SQL-like code, not abstract methods. Migration tooling via Drizzle Kit is solid but simpler than Prisma Migrate.
+**What:** The existing pattern — Zustand `uiStore` holds UI mode flags like panel open/closed, dialog state. Extend this for `compareMode` and `impactSetupId`.
+**When to use:** UI state that needs to survive component unmount/remount within a session (e.g., user opens a candidate edit panel and returns to find compare mode still active).
+**Trade-offs:** Do not put server data in `uiStore`. Only boolean flags and selected IDs. Server data stays in React Query.
 
-**Example:**
-```typescript
-// db/schema.ts
-import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";
+---
 
-export const items = sqliteTable("items", {
-  id: integer("id").primaryKey({ autoIncrement: true }),
-  name: text("name").notNull(),
-  category: text("category"),
-  weightGrams: integer("weight_grams"),
-  priceCents: integer("price_cents"),
-  purchaseSource: text("purchase_source"),
-  productUrl: text("product_url"),
-  notes: text("notes"),
-  imageFilename: text("image_filename"),
-  createdAt: integer("created_at", { mode: "timestamp" }).notNull(),
-});
-```
+## Anti-Patterns to Avoid
 
-## Data Flow
+### Anti-Pattern 1: Server Endpoint for Comparison Deltas
 
-### Request Flow
+**What people do:** Build a `GET /api/threads/:id/compare` endpoint that returns weight/price diffs
+**Why it's wrong:** All candidate data is already fetched by `useThread(threadId)`. A round-trip to compute `Math.min` and subtraction is unnecessary.
+**Do this instead:** Compute deltas in the `CandidateCompare` component from `thread.candidates[]`.
 
-```
-[User clicks "Add Item"]
-    |
-[React component] --> fetch("/api/items", { method: "POST", body })
-    |
-[Bun.serve route handler] --> validates input, calls service
-    |
-[ItemService.create()] --> business logic, defaults
-    |
-[Drizzle ORM] --> db.insert(items).values(...)
-    |
-[bun:sqlite] --> writes to gearbox.db
-    |
-[Response] <-- { id, name, ... } JSON <-- 201 Created
-    |
-[React state update] --> re-renders item list
-```
+### Anti-Pattern 2: Server Endpoint for Impact Preview
 
-### Key Data Flows
+**What people do:** Build a `GET /api/threads/:id/impact?setupId=X` endpoint
+**Why it's wrong:** Setup weight totals are already fetched by `useSetup(setupId)` which returns `items[]` with weights. The impact is additive arithmetic.
+**Do this instead:** Sum `setup.items[].weightGrams` client-side, add `candidate.weightGrams`. No round-trip.
 
-1. **Collection CRUD:** Straightforward REST. Client sends item data, server validates, persists, returns updated item. Client hooks (useItems) manage local state.
+### Anti-Pattern 3: Storing Rank as a Linked List
 
-2. **Thread lifecycle:** Create thread -> Add candidates -> Compare -> Resolve (pick winner). Resolution triggers: candidate becomes a collection item, thread status changes to "resolved", other candidates marked as rejected. This is the most stateful flow.
+**What people do:** Store `prevId`/`nextId` on each candidate for ordering
+**Why it's wrong:** Linked list ordering is complex to maintain transactionally, especially for batch reorders. Queries become multi-step.
+**Do this instead:** Use a plain `sort_order` integer (0-indexed). On reorder, update all affected rows in a single transaction loop. Integer order is simple, fast, and trivially queryable with `ORDER BY sort_order`.
 
-3. **Setup composition:** User selects items from collection to add to a named setup. Server calculates aggregate weight/cost. When viewing a thread candidate, "impact on setup" is computed by comparing candidate against current setup totals (or against a specific item being replaced).
+### Anti-Pattern 4: External DnD Library When framer-motion is Already Present
 
-4. **Dashboard aggregation:** Dashboard fetches summary stats via `/api/stats` -- total items, total collection value, active threads count, setup count. This is a read-only aggregation endpoint, not a separate data store.
+**What people do:** Install `@dnd-kit/sortable` or `react-beautiful-dnd` for drag reorder
+**Why it's wrong:** `framer-motion` is already in `package.json` at v12.37.0 and includes `Reorder.Group` / `Reorder.Item` components designed exactly for this use case. Adding another DnD library duplicates functionality and bloats the bundle.
+**Do this instead:** Use `framer-motion`'s `Reorder` components. `import { Reorder } from "framer-motion"` -- no new dependency.
 
-5. **Image upload:** Multipart form upload to `/api/images`, saved to `./uploads/` with a UUID filename. The filename is stored on the item record. Images served as static files.
+### Anti-Pattern 5: Full Optimistic Update with Rollback for Reorder
 
-### Data Model Relationships
+**What people do:** Implement `onMutate` with cache snapshot and `onError` rollback in the reorder mutation
+**Why it's wrong for this app:** Single-user SQLite on localhost. The reorder endpoint will not fail under any realistic condition. Full optimistic update infrastructure (snapshot, rollback, error handling) is meaningful in multi-user or network-failure scenarios.
+**Do this instead:** Local `useState` provides immediate visual feedback. The mutation runs fire-and-forget style. If it somehow fails, `onError` can `invalidateQueries` to restore server state. No manual rollback needed.
 
-```
-items (gear collection)
-  |
-  |-- 1:N --> setup_items (junction) <-- N:1 -- setups
-  |
-  |-- 1:N --> thread_candidates (when resolved, candidate -> item)
+### Anti-Pattern 6: Pros/Cons as Separate Database Tables
 
-threads (planning threads)
-  |
-  |-- 1:N --> candidates (potential purchases)
-                |-- status: researching | ordered | arrived
-                |-- resolved_as: winner | rejected | null
+**What people do:** Create a `candidate_annotations` table with `type: "pro"|"con"` rows
+**Why it's wrong:** Pros/cons are simple text fields per candidate, edited as textarea inputs. Modeling them as a separate table with individual row creation/deletion adds CRUD complexity for zero benefit at this scale.
+**Do this instead:** Two text columns (`pros TEXT`, `cons TEXT`) on `thread_candidates`. Store multi-line text directly. Simple, fast, and fits the existing update mutation pattern.
 
-setups
-  |
-  |-- N:M --> items (via setup_items junction table)
-```
+---
 
-### State Management
+## Integration Summary Table
 
-No global state library needed. React hooks + fetch are sufficient for a single-user app with this complexity level.
+| New Feature | API Changes | Schema Changes | New Components | Key Modified Files |
+|-------------|-------------|----------------|----------------|--------------------|
+| Side-by-side comparison | None | None | `CandidateCompare.tsx` | `$threadId.tsx`, `uiStore.ts` |
+| Setup impact preview | None | None | `SetupImpactRow.tsx` | `$threadId.tsx`, `uiStore.ts` |
+| Ranking (DnD) | `PATCH /threads/:id/candidates/reorder` | `sort_order` on `thread_candidates` | None (uses `Reorder.Group`) | `$threadId.tsx`, `thread.service.ts`, `routes/threads.ts`, `useCandidates.ts` |
+| Pros/Cons fields | Extend existing PUT candidate | `pros`, `cons` on `thread_candidates` | None | `CandidateForm.tsx`, `CandidateCard.tsx`, `thread.service.ts`, `schemas.ts` |
 
-```
-[React Hook per domain]     [API call]        [Server]         [SQLite]
-useItems() state  -------->  GET /api/items --> route handler --> SELECT
-  |                                                               |
-  |<-- setItems(data) <--- JSON response <--- query result <------+
-```
-
-Each page manages its own state via custom hooks (`useItems`, `useThreads`, `useSetups`). No Redux, no Zustand. If a mutation on one page affects another (e.g., resolving a thread adds an item to collection), the target page simply refetches on mount.
-
-## Scaling Considerations
-
-| Scale | Architecture Adjustments |
-|-------|--------------------------|
-| Single user (GearBox) | SQLite + single Bun process. Zero infrastructure. This is the target. |
-| 1-10 users | Still fine with SQLite in WAL mode. Add basic auth if needed. |
-| 100+ users | Switch to PostgreSQL, add connection pooling, consider separate API server. Not relevant for this project. |
-
-### Scaling Priorities
-
-1. **First bottleneck:** Image storage. If users upload many high-res photos, disk fills up. Mitigation: resize on upload (sharp library), limit file sizes.
-2. **Second bottleneck:** SQLite write contention under concurrent access. Not a concern for single-user. If it ever matters, switch to WAL mode or PostgreSQL.
-
-## Anti-Patterns
-
-### Anti-Pattern 1: Storing Money as Floats
-
-**What people do:** Use `float` or JavaScript `number` for prices (e.g., `19.99`).
-**Why it's wrong:** Floating point arithmetic causes rounding errors. `0.1 + 0.2 !== 0.3`. Price calculations silently drift.
-**Do this instead:** Store prices as integers in cents (`1999` for $19.99). Format for display only in the UI layer. The schema uses `priceCents: integer`.
-
-### Anti-Pattern 2: Overengineering State Management
-
-**What people do:** Install Redux/Zustand/Jotai for a single-user CRUD app, create elaborate store slices, actions, reducers.
-**Why it's wrong:** Adds complexity with zero benefit when there is one user and no shared state across tabs or real-time updates.
-**Do this instead:** Use React hooks with fetch. `useState` + `useEffect` + a thin API wrapper. Refetch on mount. Keep it boring.
-
-### Anti-Pattern 3: SPA with Client-Side Routing for Everything
-
-**What people do:** Build a full SPA with React Router, lazy loading, code splitting for 4-5 pages.
-**Why it's wrong:** Bun's fullstack server already handles page routing via HTML entrypoints. Adding client-side routing means duplicating routing logic, losing Bun's built-in asset optimization per page, and adding bundle complexity.
-**Do this instead:** Use Bun's HTML-based routing. Each page is a separate HTML entrypoint with its own React tree. Navigation between pages is standard `<a href>` links. Keep client-side routing for in-page state (e.g., tabs within thread detail) only.
-
-### Anti-Pattern 4: Storing Computed Aggregates in the Database
-
-**What people do:** Store `totalWeight` and `totalCost` on the setup record, then try to keep them in sync when items change.
-**Why it's wrong:** Stale data, sync bugs, update anomalies. Items get edited but setup totals do not get recalculated.
-**Do this instead:** Compute totals on read. SQLite is fast enough for `SUM()` across a handful of items. Calculate in the service layer or as a SQL aggregate. For a single-user app with small datasets, this is effectively instant.
-
-## Integration Points
-
-### External Services
-
-| Service | Integration Pattern | Notes |
-|---------|---------------------|-------|
-| None for v1 | N/A | Single-user local app, no external APIs needed |
-| Product URLs | Outbound links only | Store URLs to retailer pages, no API scraping |
-
-### Internal Boundaries
-
-| Boundary | Communication | Notes |
-|----------|---------------|-------|
-| Client <-> Server | REST API (JSON over fetch) | No WebSockets needed, no real-time requirements |
-| Routes <-> Services | Direct function calls | Same process, no serialization overhead |
-| Services <-> Database | Drizzle ORM queries | Type-safe, no raw SQL strings |
-| Server <-> Filesystem | Image read/write | `./uploads/` directory for gear photos |
-
-## Build Order (Dependency Chain)
-
-The architecture implies this build sequence:
-
-1. **Database schema + Drizzle setup** -- Everything depends on the data model. Define tables for items, threads, candidates, setups, setup_items first.
-2. **API routes for items (CRUD)** -- The core entity. Threads and setups reference items.
-3. **Collection UI** -- First visible feature. Validates the data model and API work end-to-end.
-4. **Thread + candidate API and UI** -- Depends on items existing to resolve candidates into the collection.
-5. **Setup composition API and UI** -- Depends on items existing to compose into setups.
-6. **Dashboard** -- Aggregates stats from all other entities. Build last since it reads from everything.
-7. **Polish: image upload, impact calculations, status tracking** -- Enhancement layer on top of working CRUD.
-
-This ordering means each phase produces a usable increment: after phase 3 you have a working gear catalog, after phase 4 you can plan purchases, after phase 5 you can compose setups.
+---
 
 ## Sources
 
-- [Bun Fullstack Dev Server docs](https://bun.com/docs/bundler/fullstack) -- Official documentation on Bun's HTML-based routing and asset bundling
-- [bun:sqlite API Reference](https://bun.com/reference/bun/sqlite) -- Native SQLite module documentation
-- [Building Full-Stack App with Bun.js, React and Drizzle ORM](https://awplife.com/building-full-stack-app-with-bun-js-react-drizzle/) -- Project structure reference
-- [Bun v3.1 Release (InfoQ)](https://www.infoq.com/news/2026/01/bun-v3-1-release/) -- Zero-config frontend, built-in DB clients
-- [Bun + React + Hono pattern](https://dev.to/falconz/serving-a-react-app-and-hono-api-together-with-bun-1gfg) -- Alternative fullstack patterns
-- [Inventory Management DB Design (Medium)](https://medium.com/@bhargavkoya56/weekly-db-project-1-inventory-management-db-design-seed-from-schema-design-to-performance-8e6b56445fe6) -- Schema design patterns for inventory systems
+- [framer-motion Reorder documentation](https://www.framer.com/motion/reorder/) -- `Reorder.Group` and `Reorder.Item` API for drag-to-reorder lists
+- [framer-motion v12 changelog](https://github.com/framer/motion/releases) -- confirms `Reorder` available in v12 (already installed)
+- [Drizzle ORM orderBy documentation](https://orm.drizzle.team/docs/select#order-by) -- `asc()` for sort_order ordering
+- [TanStack React Query optimistic updates](https://tanstack.com/query/latest/docs/framework/react/guides/optimistic-updates) -- pattern reference for the reorder mutation approach
+- [Zustand documentation](https://zustand.docs.pmnd.rs/) -- confirms store extend pattern for new UI state slices
 
 ---
-*Architecture research for: GearBox gear management app*
-*Researched: 2026-03-14*
+*Architecture research for: GearBox v1.3 Research & Decision Tools*
+*Researched: 2026-03-16*

.planning/research/FEATURES.md

@@ -1,201 +1,262 @@
 # Feature Research
 
-**Domain:** Gear management and purchase planning (personal inventory + research workflow)
-**Researched:** 2026-03-14
-**Confidence:** HIGH
+**Domain:** Gear management — candidate comparison, setup impact preview, and candidate ranking
+**Researched:** 2026-03-16
+**Confidence:** HIGH (existing codebase fully understood; UX patterns verified via multiple sources)
+
+---
+
+## Context
+
+This is a subsequent milestone research file for **v1.3 Research & Decision Tools**.
+The features below are **additive** to v1.2. All three features operate within the existing
+`threads/$threadId` page and its data model.
+
+**Existing data model relevant to this milestone:**
+- `threadCandidates`: id, threadId, name, weightGrams, priceCents, categoryId, notes, productUrl, imageFilename, status — no rank, pros, or cons columns yet
+- `setups` + `setupItems`: stores weight/cost per setup item with classification (base/worn/consumable)
+- `getSetupWithItems` already returns `classification` per item — available for impact preview
+
+---
 
 ## Feature Landscape
 
 ### Table Stakes (Users Expect These)
 
-Features users assume exist. Missing these = product feels incomplete.
+Features users assume exist in any comparison or decision tool. Missing these makes the thread
+detail page feel incomplete as a decision workspace.
 
 | Feature | Why Expected | Complexity | Notes |
 |---------|--------------|------------|-------|
-| Item CRUD with core fields (name, weight, price, category) | Every gear app and spreadsheet has this. It is the minimum unit of value. | LOW | Weight and price are the two fields users care about most. Category groups items visually. |
-| Weight unit support (g, oz, lb, kg) | Gear communities are split between metric and imperial. LighterPack, GearGrams, Hikt all support multi-unit. | LOW | Store in grams internally, display in user-preferred unit. Conversion is trivial. |
-| Automatic weight/cost totals | Spreadsheets do this. Every competitor does this. Manual math = why bother with an app. | LOW | Sum by category, by setup, by collection. Real-time recalculation on any change. |
-| Categories/grouping | LighterPack, GearGrams, Packstack all organize by category (shelter, sleep, cook, clothing, etc.). Without grouping, lists become unreadable past 20 items. | LOW | User-defined categories. Suggest defaults but allow custom. |
-| Named setups / packing lists | LighterPack has lists, GearGrams has lists, Packstack has trips, Hikt has packing lists. Composing subsets of your gear into purpose-specific loadouts is universal. | MEDIUM | Items belong to collection; setups reference items from collection. Many-to-many relationship. |
-| Setup weight/cost breakdown | Every competitor shows base weight, worn weight, consumable weight as separate totals. Pie charts or percentage breakdowns by category are standard (LighterPack pioneered this). | MEDIUM | Weight classification (base/worn/consumable) per item per setup. Visual breakdown is expected. |
-| Notes/description per item | Spreadsheet users write notes. Every competitor supports free text on items. Useful for fit notes, durability observations, model year specifics. | LOW | Plain text field. No rich text needed for v1. |
-| Product links / URLs | Users track where they found or bought items. Spreadsheets always have a "link" column. | LOW | Single URL field per item. |
-| Photos per item | Hikt, GearCloset, and Packrat all support item photos. Visual identification matters -- many gear items look similar in text. | MEDIUM | Image upload and storage. Start with one photo per item; multi-photo is a differentiator. |
-| Search and filter | Once a collection exceeds 30-40 items, finding things without search is painful. Hikt highlights "searchable digital closet." | LOW | Filter by category, search by name. Basic but essential. |
-| Import from CSV | GearGrams, HikeLite, HikerHerd, Packrat all support CSV import. Users migrating from spreadsheets (GearBox's primary audience) need this. | MEDIUM | Define a simple CSV schema. Map columns to fields. Handle unit conversion on import. |
-| Export to CSV | Companion to import. Users want data portability and backup ability. | LOW | Straightforward serialization of collection data. |
+| Side-by-side comparison view | Any comparison tool in any domain shows attributes aligned per-column. Card grid (current) forces mental juggling between candidates. E-commerce, spec sheets, gear apps — all use tabular layout for comparison. | MEDIUM | Rows = attributes (image, name, weight, price, status, notes, link), columns = candidates. Sticky attribute-label column during horizontal scroll. Max 3–4 candidates usable on desktop; 2 on mobile. Toggle between grid view (current) and table view. |
+| Weight delta per candidate | Gear apps (LighterPack, GearGrams) display weight totals prominently. Users replacing an item need the delta, not just the raw weight of the candidate. | LOW | Pure client-side computation: `candidate.weightGrams - existingItemWeight`. No API call needed if setup data already loaded via `useSetup`. |
+| Cost delta per candidate | Same reasoning as weight delta. A purchase decision is always the weight vs. cost tradeoff. | LOW | Same pattern as weight delta. Color-coded: green for savings/lighter, red for more expensive/heavier. |
+| Setup selector for impact preview | User needs to pick which setup to compute deltas against — not all setups contain the same category of item being replaced. | MEDIUM | Dropdown of setup names populated from `useSetups()`. When selected, loads setup via `useSetup(id)`. "No setup selected" state shows raw candidate values only, no delta. |
 
 ### Differentiators (Competitive Advantage)
 
-Features that set the product apart. Not required, but valuable.
+Features not found in LighterPack, GearGrams, or any other gear app. Directly serve the
+"decide between candidates" workflow that is unique to GearBox.
 
 | Feature | Value Proposition | Complexity | Notes |
 |---------|-------------------|------------|-------|
-| Purchase planning threads | No competitor has this. LighterPack, GearGrams, Packstack, Hikt are all post-purchase tools. GearBox's core value is the pre-purchase research workflow: create a thread, add candidates, compare, decide, then move the winner to your collection. This is the single biggest differentiator. | HIGH | Thread model with candidate items, status tracking, resolution workflow. This is the app's reason to exist. |
-| Impact preview ("how does this affect my setup?") | No competitor shows how a potential purchase changes your overall setup weight/cost. Users currently do this math manually in spreadsheets. Seeing "+120g to base weight, +$85 to total cost" before buying is uniquely valuable. | MEDIUM | Requires linking threads to setups. Calculate delta between current item (if replacing) and candidate. |
-| Thread resolution workflow | The lifecycle of "researching -> ordered -> arrived -> in collection" does not exist in any competitor. Closing a thread and promoting the winner to your collection is a novel workflow that mirrors how people actually buy gear. | MEDIUM | Status state machine on thread items. Resolution action that creates/updates collection item. |
-| Side-by-side candidate comparison | Wishlist apps let you save items. GearBox lets you compare candidates within a thread on the dimensions that matter (weight, price, notes). Similar to product comparison on retail sites, but for your specific context. | MEDIUM | Comparison view pulling from thread candidates. Highlight differences in weight/price. |
-| Priority/ranking within threads | Mark favorites among candidates. Simple but no gear app does this because no gear app has a research/planning concept. | LOW | Numeric rank or star/favorite flag per candidate in a thread. |
-| Multi-photo per item | Most competitors support zero or one photo. Multiple photos (product shots, detail shots, in-use shots) add real value for gear tracking. | MEDIUM | Gallery per item. Storage considerations. Defer to v1.x. |
-| Weight distribution visualization | LighterPack's pie chart is iconic. A clean, modern version with interactive breakdowns by category adds polish. | MEDIUM | Chart component showing percentage of total weight by category. |
-| Hobby-agnostic data model | Competitors are hiking/backpacking-specific. GearBox works for bikepacking, sim racing, photography, cycling, or any collection hobby. The data model uses generic "categories" rather than hardcoded "shelter/sleep/cook." | LOW | Architecture decision more than feature. No hiking-specific terminology baked into the model. |
+| Drag-to-rank ordering | Makes priority explicit without a numeric input. Ranking communicates "this is my current top pick." Maps to how users mentally stack-rank options during research. No competitor has this in the gear domain. | MEDIUM | `@dnd-kit/sortable` is the current standard (actively maintained; `react-beautiful-dnd` is abandoned as of 2025). Requires new `rank` integer column on `threadCandidates`. Persist order via PATCH endpoint. |
+| Per-candidate pros/cons fields | Freeform text capturing the reasoning behind ranking. LighterPack and GearGrams have notes per item but no structured decision rationale. Differentiates GearBox as a decision tool, not just a list tracker. | LOW | Two textarea fields per candidate. New `pros` and `cons` text columns on `threadCandidates`. Visible in comparison view rows and candidate edit panel. |
+| Impact preview with category-matched delta | Setup items have a category. The most meaningful delta is weight saved within the same category (e.g., comparing sleeping pads, subtract current sleeping pad weight from setup total). More actionable than comparing against the entire setup total. | MEDIUM | Use `candidate.categoryId` to find matching setup items and compute delta. Edge case: no item of that category in the setup → show "not in setup." Data already available from `getSetupWithItems`. |
 
 ### Anti-Features (Commonly Requested, Often Problematic)
 
-Features that seem good but create problems.
-
 | Feature | Why Requested | Why Problematic | Alternative |
 |---------|---------------|-----------------|-------------|
-| Multi-user / social sharing | "Share my setup with friends," "collaborate on packing lists." Hikt Premium has real-time collaboration. | Adds auth, permissions, data isolation, and massive complexity to a single-user app. The PROJECT.md explicitly scopes this out. Premature for v1. | Export/share as read-only link or image in a future version. No auth needed. |
-| Price tracking / deal alerts | Wishlist apps (Sortd, WishUpon) track price drops. Seems useful for purchase planning. | Requires scraping or API integrations with retailers. Fragile, maintenance-heavy, legally gray. Completely different product category. | Store the price you found manually. Link to the product page. Users can check prices themselves. |
-| Barcode/product database scanning | Hikt has barcode scanning and product database lookup. Seems like it saves time. | Requires maintaining or licensing a product database. Outdoor gear barcodes are inconsistent. Mobile-first feature that does not fit a web-first app. | Manual entry is fine for a collection that grows by 1-5 items per month. Not a data-entry-heavy workflow. |
-| Custom comparison parameters | "Let me define which fields to compare (warmth rating, denier, waterproof rating)." | Turns a simple app into a configurable schema builder. Massive complexity for marginal value. PROJECT.md lists this as out of scope for v1. | Use the notes field for specs. Fixed comparison on weight/price covers 80% of use cases. |
-| Community gear database / shared catalog | "Browse what other people use," "copy someone's gear list." Hikt has community packing lists. | Requires moderation, data quality controls, user accounts, and content management. Completely different product. | Stay focused on personal inventory. Community features are a different app. |
-| Mobile native app | PackLight and Hikt have iOS/Android apps. | Doubles or triples development effort. Web-first serves the use case (gear management is a desk activity, not a trailside activity). PROJECT.md scopes this out. | Responsive web design. Works on mobile browsers for quick lookups. |
-| Real-time weather integration | Packstack integrates weather for trip planning. | Requires external API, ongoing costs, and is only relevant to outdoor-specific use cases. GearBox is hobby-agnostic. | Out of scope. Users check weather separately. |
-| Automated "what to bring" recommendations | AI/rule-based suggestions based on trip conditions. | Requires domain knowledge per hobby, weather data, user preference modeling. Over-engineered for a personal tool. | Users build their own setups. They know their gear. |
+| Custom comparison attributes | "I want to compare battery life, durability, color..." | PROJECT.md explicitly rejects this as a complexity trap. Custom attributes require schema generalization, dynamic rendering, and data entry friction for every candidate. | Notes field and pros/cons fields cover the remaining use cases. |
+| Score/rating calculation | Automatically rank candidates by computed score | Score algorithms require encoding the user's weight-vs-price preference — personalization complexity. Users distrust opaque scores. | Manual drag-to-rank expresses the user's own weighting without encoding it in an algorithm. |
+| Side-by-side comparison across threads | Compare candidates from different research threads | Candidates belong to different purchase decisions — mixing them is conceptually incoherent. Different categories are never apples-to-apples. | Thread remains the scope boundary. Cross-thread planning is what setups are for. |
+| Comparison permalink/share | Share a comparison view URL | GearBox is single-user, no auth for v1. Sharing requires auth, user management, public/private visibility. | Out of scope for v1 per PROJECT.md. Future feature. |
+| Classification-aware impact preview as MVP requirement | Show delta broken down by base/worn/consumable | While data is available, the classification breakdown adds significant UI complexity. The flat delta answers "will this make my setup lighter?" which is 90% of the use case. | Flat delta for MVP. Classification-aware breakdown as a follow-up enhancement (P2). |
+
+---
 
 ## Feature Dependencies
 
 ```
-[Item CRUD + Core Fields]
-    |
-    +--requires--> [Categories]
-    |
-    +--enables---> [Named Setups / Packing Lists]
-    |                   |
-    |                   +--enables---> [Setup Weight/Cost Breakdown]
-    |                   |
-    |                   +--enables---> [Impact Preview] (also requires Planning Threads)
-    |
-    +--enables---> [Planning Threads]
-                        |
-                        +--enables---> [Candidate Comparison]
-                        |
-                        +--enables---> [Thread Resolution Workflow]
-                        |                   |
-                        |                   +--creates---> items in [Collection]
-                        |
-                        +--enables---> [Priority/Ranking]
-                        |
-                        +--enables---> [Status Tracking] (researching -> ordered -> arrived)
+[Side-by-side comparison view]
+    └──requires──> [All candidate fields visible in UI]
+                   (weightGrams, priceCents, notes, productUrl already in schema)
+    └──enhances──> [Pros/cons fields] (displayed as comparison rows)
+    └──enhances──> [Drag-to-rank] (rank number shown as position in comparison columns)
+    └──enhances──> [Impact preview] (delta displayed per-column inline)
 
-[Search & Filter] --enhances--> [Item CRUD] (becomes essential at ~30+ items)
+[Impact preview (weight + cost delta)]
+    └──requires──> [Setup selector] (user picks which setup to compute delta against)
+    └──requires──> [Setup data client-side] (useSetup hook already exists, no new API)
+    └──requires──> [Candidate weight/price data] (already in threadCandidates schema)
 
-[Import CSV] --populates--> [Item CRUD] (bootstrap for spreadsheet migrants)
+[Setup selector]
+    └──requires──> [useSetups() hook] (already exists in src/client/hooks/useSetups.ts)
+    └──requires──> [useSetup(id) hook] (already exists, loads items with classification)
 
-[Photos] --enhances--> [Item CRUD] (independent, can add anytime)
+[Drag-to-rank]
+    └──requires──> [rank INTEGER column on threadCandidates] (new — schema migration)
+    └──requires──> [PATCH /api/threads/:id/candidates/rank endpoint] (new API endpoint)
+    └──enhances──> [Side-by-side comparison] (rank visible as position indicator)
+    └──enhances──> [Card grid view] (rank badge on each CandidateCard)
 
-[Weight Unit Support] --enhances--> [All weight displays] (must be in from day one)
+[Pros/cons fields]
+    └──requires──> [pros TEXT column on threadCandidates] (new — schema migration)
+    └──requires──> [cons TEXT column on threadCandidates] (new — schema migration)
+    └──requires──> [updateCandidateSchema extended] (add pros/cons to Zod schema)
+    └──enhances──> [CandidateForm edit panel] (new textarea fields)
+    └──enhances──> [Side-by-side comparison] (pros/cons rows in comparison table)
 ```
 
 ### Dependency Notes
 
-- **Named Setups require Item CRUD:** Setups are compositions of existing collection items. The collection must exist first.
-- **Planning Threads require Item CRUD:** Thread candidates have the same data shape as collection items (weight, price, etc.). Reuse the item model.
-- **Impact Preview requires both Setups and Threads:** You need a setup to compare against and a thread candidate to evaluate. This is a later-phase feature.
-- **Thread Resolution creates Collection Items:** The resolution workflow bridges threads and collection. Both must be stable before resolution logic is built.
-- **Import CSV populates Collection:** Import is a bootstrap feature for users migrating from spreadsheets. Should be available early but after the core item model is solid.
+- **Side-by-side comparison is independent of schema changes.** It can be built using
+  existing candidate data. No migrations required. Delivers value immediately.
+- **Impact preview is independent of schema changes.** Uses existing `useSetups` and
+  `useSetup` hooks client-side. Delta computation is pure math in the component.
+  No new API endpoint needed for MVP.
+- **Drag-to-rank requires schema migration.** `rank` column must be added to
+  `threadCandidates`. Default ordering on migration = `createdAt` ascending.
+- **Pros/cons requires schema migration.** Two nullable `text` columns on
+  `threadCandidates`. Low risk — nullable, backwards compatible.
+- **Comparison view enhances everything.** Best delivered after rank and pros/cons
+  schema work is done so the full table is useful from day one.
+
+---
 
 ## MVP Definition
 
-### Launch With (v1)
+### Launch With (v1.3 milestone)
 
-Minimum viable product -- what is needed to validate the concept and replace a spreadsheet.
-
-- [ ] Item CRUD with weight, price, category, notes, product link -- the core inventory
-- [ ] User-defined categories -- organize items meaningfully
-- [ ] Weight unit support (g, oz, lb, kg) -- non-negotiable for gear community
-- [ ] Automatic weight/cost totals by category and overall -- the reason to use an app over a text file
-- [ ] Named setups with item selection and totals -- compose loadouts from your collection
-- [ ] Planning threads with candidate items -- the core differentiator, add candidates you are researching
-- [ ] Side-by-side candidate comparison on weight/price -- the payoff of the thread concept
-- [ ] Thread resolution (pick a winner, move to collection) -- close the loop
-- [ ] Dashboard home page -- clean entry point per PROJECT.md constraints
-- [ ] Search and filter on collection -- usability at scale
+- [ ] **Side-by-side comparison view** — Core deliverable. Replace mental juggling of the card
+  grid with a scannable table. No schema changes. Highest ROI, lowest risk.
+- [ ] **Impact preview: flat weight + cost delta per candidate** — Shows `+/- X g` and
+  `+/- $Y` vs. the selected setup. Pure client-side math. No schema changes.
+- [ ] **Setup selector** — Dropdown of user's setups. Required for impact preview. One
+  interaction: pick a setup, see deltas update.
+- [ ] **Drag-to-rank** — Requires `rank` column migration. `@dnd-kit/sortable` handles
+  the drag UX. Persist via new PATCH endpoint.
+- [ ] **Pros/cons text fields** — Requires `pros` + `cons` column migration. Trivially low
+  implementation complexity once schema is in place.
 
 ### Add After Validation (v1.x)
 
-Features to add once core is working and the planning thread workflow is proven.
-
-- [ ] Impact preview ("this candidate adds +120g to your Summer Bikepacking setup") -- requires setups + threads to be stable
-- [ ] Status tracking on thread items (researching / ordered / arrived) -- lifecycle tracking
-- [ ] Priority/ranking within threads -- mark favorites among candidates
-- [ ] Photos per item -- visual identification, one photo per item initially
-- [ ] CSV import/export -- migration path from spreadsheets, data portability
-- [ ] Weight distribution visualization (pie/bar chart by category) -- polish feature
+- [ ] **Classification-aware impact preview** — Delta broken down by base/worn/consumable.
+  Higher complexity UI. Add once flat delta is validated as useful.
+  Trigger: user feedback requests "which classification does this affect?"
+- [ ] **Rank indicator on card grid** — Small "1st", "2nd" badge on CandidateCard.
+  Trigger: users express confusion about which candidate is ranked first without entering
+  comparison view.
+- [ ] **Comparison view on mobile** — Horizontal scroll works but is not ideal. Consider
+  attribute-focus swipe view. Trigger: usage data shows mobile traffic on thread pages.
 
 ### Future Consideration (v2+)
 
-Features to defer until product-market fit is established.
+- [ ] **Comparison permalink** — Requires auth/multi-user work first.
+- [ ] **Auto-fill from product URL** — Fragile scraping, rejected in PROJECT.md.
+- [ ] **Custom comparison attributes** — Explicitly rejected in PROJECT.md.
 
-- [ ] Multi-photo gallery per item -- storage and UI complexity
-- [ ] Shareable read-only links for setups -- lightweight sharing without auth
-- [ ] Drag-and-drop reordering in lists and setups -- UX refinement
-- [ ] Bulk operations (multi-select, bulk categorize, bulk delete) -- power user feature
-- [ ] Dark mode -- common request, low priority for initial launch
-- [ ] Item history / changelog (track weight after modifications, price changes) -- advanced tracking
+---
 
 ## Feature Prioritization Matrix
 
 | Feature | User Value | Implementation Cost | Priority |
 |---------|------------|---------------------|----------|
-| Item CRUD with core fields | HIGH | LOW | P1 |
-| Categories | HIGH | LOW | P1 |
-| Weight unit support | HIGH | LOW | P1 |
-| Auto weight/cost totals | HIGH | LOW | P1 |
-| Named setups | HIGH | MEDIUM | P1 |
-| Planning threads | HIGH | HIGH | P1 |
-| Candidate comparison | HIGH | MEDIUM | P1 |
-| Thread resolution | HIGH | MEDIUM | P1 |
-| Dashboard home | MEDIUM | LOW | P1 |
-| Search and filter | MEDIUM | LOW | P1 |
-| Impact preview | HIGH | MEDIUM | P2 |
-| Status tracking (threads) | MEDIUM | LOW | P2 |
-| Priority/ranking (threads) | MEDIUM | LOW | P2 |
-| Photos per item | MEDIUM | MEDIUM | P2 |
-| CSV import/export | MEDIUM | MEDIUM | P2 |
-| Weight visualization charts | MEDIUM | MEDIUM | P2 |
-| Multi-photo gallery | LOW | MEDIUM | P3 |
-| Shareable links | LOW | MEDIUM | P3 |
-| Drag-and-drop reordering | LOW | MEDIUM | P3 |
-| Bulk operations | LOW | MEDIUM | P3 |
+| Side-by-side comparison view | HIGH | MEDIUM | P1 |
+| Setup impact preview (flat delta) | HIGH | LOW | P1 |
+| Setup selector for impact preview | HIGH | LOW | P1 |
+| Drag-to-rank ordering | MEDIUM | MEDIUM | P1 |
+| Pros/cons text fields | MEDIUM | LOW | P1 |
+| Classification-aware impact preview | MEDIUM | HIGH | P2 |
+| Rank indicator on card grid | LOW | LOW | P2 |
+| Mobile-optimized comparison view | LOW | MEDIUM | P3 |
 
 **Priority key:**
-- P1: Must have for launch
+- P1: Must have for this milestone launch
 - P2: Should have, add when possible
 - P3: Nice to have, future consideration
 
+---
+
 ## Competitor Feature Analysis
 
-| Feature | LighterPack | GearGrams | Packstack | Hikt | GearBox (Our Approach) |
-|---------|-------------|-----------|-----------|------|------------------------|
-| Gear inventory | Per-list only (no central closet) | Central library + lists | Full gear library | Full closet with search | Full collection as central source of truth |
-| Weight tracking | Excellent -- base/worn/consumable splits, pie charts | Good -- multi-unit, category totals | Good -- base/worn/consumable | Excellent -- smart insights | Base/worn/consumable with unit flexibility |
-| Packing lists / setups | Unlimited lists (web) | Multiple lists via drag-drop | Trip-based (2 free) | 3 free lists, more with premium | Named setups composed from collection |
-| Purchase planning | None | None | None | None | Planning threads with candidates, comparison, resolution -- unique |
-| Impact analysis | None | None | None | None | Show how a candidate changes setup weight/cost -- unique |
-| Photos | None | None | None | Yes | Yes (v1.x) |
-| Import/export | None (copy-linked lists only) | CSV import | None mentioned | LighterPack import, CSV | CSV import/export (v1.x) |
-| Mobile | No native app (web only, poor mobile UX) | Web only | iOS only | iOS + Android + web | Web-first, responsive design |
-| Sharing | Shareable links | None mentioned | Shareable trip links | Community lists, collaboration | Deferred (v2+, read-only links) |
-| Hobby scope | Hiking/backpacking only | Hiking/backpacking only | Hiking/backpacking only | Hiking/backpacking only | Any hobby (bikepacking, sim racing, photography, etc.) |
-| Pricing | Free | Free | Freemium (2 lists free) | Freemium (3 lists free) | Single-user, no tiers |
-| Status | Open source, aging, no mobile | Maintained but dated | Active development | Actively developed, modern | New entrant with unique purchase planning angle |
+| Feature | LighterPack | GearGrams | OutPack | Our Approach |
+|---------|-------------|-----------|---------|--------------|
+| Side-by-side candidate comparison | None (list only) | None (library + trip list) | None | Inline comparison table on thread detail page, toggle from grid view |
+| Impact preview / weight delta | None (duplicate lists manually to compare) | None (no delta concept) | None | Per-candidate delta vs. selected setup, computed client-side |
+| Candidate ranking | None | None | None | Drag-to-rank with persisted `rank` column |
+| Pros/cons annotation | None (notes field only) | None (notes field only) | None | Dedicated `pros` and `cons` fields separate from general notes |
+| Status tracking | None | "wish list" item flag only | None | Already built in v1.2 (researching/ordered/arrived) |
+
+**Key insight:** No existing gear management tool has a comparison view, delta preview, or
+ranking system for candidates within a research thread. This is an unmet-need gap.
+The features are adapted from general product comparison UX (e-commerce) to the gear domain.
+
+---
+
+## Implementation Notes by Feature
+
+### Side-by-side Comparison View
+
+- Rendered as a transposed table: rows = attribute labels, columns = candidates.
+- Rows: Image (thumbnail), Name, Weight, Price, Status, Notes, Link, Pros, Cons, Rank, Impact Delta (weight), Impact Delta (cost).
+- Sticky first column (attribute label) while candidate columns scroll horizontally for 3+.
+- Candidate images at reduced aspect ratio (square thumbnail ~80px).
+- Weight/price cells use existing `formatWeight` / `formatPrice` formatters with the user's preferred unit.
+- Status cell reuses existing `StatusBadge` component.
+- "Pick as winner" action available per column (reuses existing `openResolveDialog`).
+- Toggle between grid view (current) and table view. Preserve both modes. Default to grid;
+  user activates comparison mode explicitly.
+- Comparison mode is a UI state only (Zustand or local component state) — no URL change needed.
+
+### Impact Preview
+
+- Setup selector: `<select>` or custom dropdown populated from `useSetups()`.
+- On selection: load setup via `useSetup(id)`. Compute delta per candidate:
+  `candidate.weightGrams - matchingCategoryWeight` where `matchingCategoryWeight` is the
+  sum of setup item weights in the same category as the thread.
+- Delta display: colored pill on each candidate column in comparison view:
+  - Negative delta (lighter) = green, prefixed with "−"
+  - Positive delta (heavier) = red, prefixed with "+"
+  - Zero = neutral gray
+- Same pattern for cost delta.
+- "No setup selected" state = no delta row shown.
+- "Category not in setup" state = "not in setup" label instead of delta.
+- No new API endpoints required. All data is client-side once setups are loaded.
+
+### Drag-to-Rank
+
+- `@dnd-kit/sortable` with `SortableContext` wrapping the candidate list.
+- `useSortable` hook per candidate with a drag handle (Lucide `grip-vertical` icon).
+- Drag handle visible always (not hover-only) so the affordance is clear.
+- On `onDragEnd`: recompute ranks using `arrayMove()`, call
+  `PATCH /api/threads/:threadId/candidates/rank` with `{ orderedIds: number[] }`.
+- Server endpoint: bulk update `rank` for each candidate ID in the thread atomically.
+- `rank` column: `INTEGER` nullable. Null = unranked (treated as lowest rank). Default to
+  `createdAt` order on first explicit rank save.
+- Rank number badge: displayed on each CandidateCard corner (small gray circle, "1", "2", "3").
+- Works in both grid view and comparison view.
+
+### Pros/Cons Fields
+
+- Two `textarea` inputs added to the existing `CandidateForm` (slide-out panel).
+- Labels: "Pros" and "Cons" — plain text, no icons.
+- Displayed below the existing Notes field in the form.
+- Extend `updateCandidateSchema` with `pros: z.string().optional()` and `cons: z.string().optional()`.
+- In comparison table: pros and cons rows display as plain text, line-wrapped.
+- In card grid: pros/cons not shown on card surface (too much density). Visible only in edit
+  panel and comparison view.
+
+### Schema Changes Required
+
+Two schema migrations needed for this milestone:
+
+```sql
+-- Migration 1: Candidate rank
+ALTER TABLE thread_candidates ADD COLUMN rank INTEGER;
+
+-- Migration 2: Candidate pros/cons
+ALTER TABLE thread_candidates ADD COLUMN pros TEXT;
+ALTER TABLE thread_candidates ADD COLUMN cons TEXT;
+```
+
+Both columns are nullable and backwards compatible. Existing candidates get `NULL` values.
+UI treats `NULL` rank as unranked, `NULL` pros/cons as empty string.
+
+---
 
 ## Sources
 
-- [LighterPack](https://lighterpack.com/) -- free web-based gear list tool, community standard
-- [GearGrams](https://www.geargrams.com/) -- drag-and-drop gear library with multi-unit support
-- [Packstack](https://www.packstack.io/) -- trip-centric gear management with weather integration
-- [Hikt](https://hikt.app/) -- modern gear manager with mobile apps and community features
-- [Hikt Blog: Best Backpacking Gear Apps 2026](https://hikt.app/blog/best-backpacking-gear-apps-2026/) -- competitive comparison
-- [HikeLite](https://hikeliteapp.com/) -- ultralight gear management with CSV support
-- [Packrat](https://www.packrat.app/) -- iOS/Android gear inventory with CSV/JSON import
-- [LighterPack GitHub Issues](https://github.com/galenmaly/lighterpack/issues) -- user feature requests and limitations
-- [Palespruce Bikepacking Gear Spreadsheet](http://www.palespruce.com/bikepacking-gear-spreadsheet/) -- spreadsheet workflow GearBox replaces
-- [99Boulders Backpacking Gear List Spreadsheet](https://www.99boulders.com/backpacking-gear-list-spreadsheet) -- spreadsheet workflow patterns
+- [Designing The Perfect Feature Comparison Table — Smashing Magazine](https://www.smashingmagazine.com/2017/08/designing-perfect-feature-comparison-table/) — table layout patterns, sticky headers, progressive disclosure (HIGH confidence)
+- [Comparison Tables for Products, Services, and Features — Nielsen Norman Group](https://www.nngroup.com/articles/comparison-tables/) — information architecture for comparison, anti-patterns (HIGH confidence)
+- [The Ultimate Drag-and-Drop Toolkit for React: @dnd-kit — BrightCoding (2025)](https://www.blog.brightcoding.dev/2025/08/21/the-ultimate-drag-and-drop-toolkit-for-react-a-deep-dive-into-dnd-kit/) — confirmed dnd-kit as current standard, react-beautiful-dnd abandoned (HIGH confidence)
+- [dnd-kit Sortable Docs](https://docs.dndkit.com/presets/sortable) — SortableContext, useSortable, arrayMove patterns (HIGH confidence)
+- [Ultralight: The Gear Tracking App I'm Leaving LighterPack For — TrailsMag](https://trailsmag.net/blogs/hiker-box/ultralight-the-gear-tracking-app-i-m-leaving-lighterpack-for) — LighterPack feature gap analysis (MEDIUM confidence)
+- [Comparing products: UX design best practices — Contentsquare](https://contentsquare.com/blog/comparing-products-design-practices-to-help-your-users-avoid-fragmented-comparison-7/) — fragmented comparison UX pitfalls (HIGH confidence)
+- [Drag and drop UI examples and UX tips — Eleken](https://www.eleken.co/blog-posts/drag-and-drop-ui) — drag affordance and visual feedback patterns (MEDIUM confidence)
+- GearBox codebase analysis (src/db/schema.ts, src/server/services/, src/client/hooks/) — confirmed existing data model, no rank/pros/cons columns present (HIGH confidence)
 
 ---
-*Feature research for: Gear management and purchase planning*
-*Researched: 2026-03-14*
+*Feature research for: GearBox v1.3 — candidate comparison, setup impact preview, candidate ranking*
+*Researched: 2026-03-16*

.planning/research/PITFALLS.md

@@ -1,136 +1,230 @@
 # Pitfalls Research
 
-**Domain:** Gear management, collection tracking, purchase planning (single-user web app)
-**Researched:** 2026-03-14
-**Confidence:** HIGH (domain-specific patterns well-documented across gear community and inventory app space)
+**Domain:** Adding side-by-side candidate comparison, setup impact preview, and drag-to-reorder ranking to an existing gear management app (GearBox v1.3)
+**Researched:** 2026-03-16
+**Confidence:** HIGH (derived from direct codebase analysis of v1.2 + verified with dnd-kit GitHub issues, TanStack Query docs, and Baymard comparison UX research)
+
+---
 
 ## Critical Pitfalls
 
-### Pitfall 1: Unit Handling Treated as Display-Only
+### Pitfall 1: dnd-kit + React Query Cache Produces Visible Flicker on Drop
 
 **What goes wrong:**
-Weight and price values are stored as bare numbers without unit metadata. The app assumes everything is grams or dollars, then breaks when users enter ounces, pounds, kilograms, or foreign currencies. Worse: calculations like "total setup weight" silently produce garbage when items have mixed units. A 200g tent and a 5lb sleeping bag get summed as 205.
+When ranking candidates via drag-to-reorder, the naive approach is to call `mutate()` in `onDragEnd` and apply an optimistic update with `setQueryData` in the `onMutate` callback. Despite this, the item visibly snaps back to its original position for a split second before settling in the new position. The user sees a "jump" on every successful drop, which makes the ranking feature feel broken even though the data is correct.
 
 **Why it happens:**
-In a single-user app it feels safe to skip unit handling -- "I'll just always use grams." But real product specs come in mixed units (manufacturers list in oz, g, kg, lb), and copy-pasting from product pages means mixed data creeps in immediately.
+dnd-kit's `SortableContext` derives its order from React state. When the order is stored in React Query's cache rather than local React state, there is a timing mismatch: dnd-kit reads the list order from the cache after the drop animation, but the cache update triggers a React re-render cycle that arrives one or two frames late. The drop animation briefly shows the item at its original position before the re-render reflects the new order. This is a known, documented issue in dnd-kit (GitHub Discussion #1522, Issue #921) that specifically affects React Query integrations.
 
 **How to avoid:**
-Store all weights in a canonical unit (grams) at write time. Accept input in any unit but convert on save. Store the original unit for display purposes but always compute on the canonical value. Build a simple conversion layer from day one -- it is 20 lines of code now vs. a data migration later.
+Use a `tempItems` local state (`useState<Candidate[] | null>(null)`) alongside React Query. On `onDragEnd`, immediately set `tempItems` to the reordered array before calling `mutate()`. Render the candidate list from `tempItems ?? queryData.candidates`. In mutation `onSettled`, set `tempItems` to `null` to hand back control to React Query. This approach:
+- Prevents the flicker because the component re-renders from synchronous local state immediately
+- Avoids `useEffect` syncing (which adds extra renders and is error-prone)
+- Stays consistent with the existing React Query + Zustand pattern in the codebase
+- Handles drag cancellation cleanly (reset `tempItems` on `onDragCancel`)
+
+Do not store the rank column data in the React Query `["threads", threadId]` cache key in a way that requires invalidation and refetch after reorder — this causes a round-trip delay that amplifies the flicker.
 
 **Warning signs:**
-- Weight field is a plain number input with no unit selector
-- No conversion logic exists anywhere in the codebase
-- Aggregation functions (total weight) do simple `SUM()` without unit awareness
+- Item visibly snaps back to original position for ~1 frame on drop
+- `onDragEnd` calls `mutate()` but uses no local state bridge
+- `setQueryData` is the only state update on drag end
 
 **Phase to address:**
-Phase 1 (Data model / Core CRUD) -- unit handling must be in the schema from the start. Retrofitting requires migrating every existing item.
+Candidate ranking phase — the `tempItems` pattern must be designed before building the drag UI, not retrofitted after noticing the flicker.
 
 ---
 
-### Pitfall 2: Rigid Category Hierarchy Instead of Flexible Tagging
+### Pitfall 2: Rank Storage Using Integer Offsets Requires Bulk Writes
 
 **What goes wrong:**
-The app ships with a fixed category tree (Shelter > Tents > 1-Person Tents) that works for bikepacking but fails for sim racing gear, photography equipment, or any other hobby. Users cannot create categories, and items that span categories (a jacket that is both "clothing" and "rain gear") get awkwardly forced into one slot. The "generic enough for any hobby" goal from PROJECT.md dies on contact with a rigid hierarchy.
+The most obvious approach for storing candidate rank order is adding a `sortOrder INTEGER` column to `thread_candidates` and storing 1, 2, 3... When the user drags candidate #2 to position #1, the naive fix is to update all subsequent candidates' `sortOrder` values to maintain contiguous integers. With 5 candidates, this is 5 UPDATE statements per drop. With rapid dragging, this creates a burst of writes where each intermediate position during the drag fires updates. If the app ever has threads with 10+ candidates (not uncommon for a serious gear decision), this becomes visible latency on every drag.
 
 **Why it happens:**
-Hierarchical categories feel structured and "correct" during design. Flat tags feel messy. But hierarchies require knowing the domain upfront, and GearBox explicitly needs to support arbitrary hobbies.
+Integer rank storage feels natural and maps directly to how arrays work. The developer adds `ORDER BY sort_order ASC` to the candidate query and calls it done. The performance problem is only discovered when testing with a realistic number of candidates and a fast drag gesture.
 
 **How to avoid:**
-Use a flat tag/label system as the primary organization mechanism. Users create their own tags ("bikepacking", "sleep-system", "cook-kit"). An item can have multiple tags. Optionally allow a single "category" field for broad grouping, but do not enforce hierarchy. Tags are the flexible axis; a single category field is the structured axis.
+Use a `sortOrder REAL` column (floating-point) with fractional indexing — when inserting between positions A and B, assign `(A + B) / 2`. This means a drag requires only a single UPDATE for the moved item. Only trigger a full renumber (resetting all candidates to integers 1000, 2000, 3000... or similar spaced values) when the float precision degrades (approximately after 50+ nested insertions, unlikely in practice for this app). Start values at 1000, 5000 increments to give ample room.
+
+For GearBox's use case (typically 2-8 candidates per thread), integer storage is workable, but the fractional approach is cleaner and avoids the bulk-write problem entirely. The added complexity is minimal: one line of math in the service layer.
+
+Regardless of storage strategy, add an index: `CREATE INDEX ON thread_candidates (thread_id, sort_order)`.
 
 **Warning signs:**
-- Schema has a `category_id` foreign key to a `categories` table with `parent_id`
-- Seed data contains a pre-built category tree
-- Adding a new hobby requires modifying the database
+- `sortOrder` column uses `integer()` type in Drizzle schema
+- Reorder service function issues multiple UPDATE statements in a loop
+- No transaction wrapping the bulk update
+- Each drag event (not just the final drop) triggers a service call
 
 **Phase to address:**
-Phase 1 (Data model) -- this is a schema-level decision. Changing from hierarchy to tags after data exists requires migration of every item's categorization.
+Schema and service design phase for candidate ranking — the storage strategy must be chosen before building the sort UI, as changing from integer to fractional later requires a migration.
 
 ---
 
-### Pitfall 3: Planning Thread State Machine Complexity Explosion
+### Pitfall 3: Impact Preview Reads Stale Candidate Data
 
 **What goes wrong:**
-Thread items have statuses (researching, ordered, arrived) plus a thread-level resolution (pick winner, close thread, move to collection). Developers build these as independent fields without modeling the valid state transitions, leading to impossible states: an item marked "arrived" in a thread that was "cancelled," or a "winner" that was never "ordered." The UI then needs defensive checks everywhere, and bugs appear as ghost items in the collection.
+The impact preview shows "+450g / +$89" next to each candidate — what this candidate would add to the selected setup. The calculation is: `(candidate.weightGrams - null) + setup.totalWeight`. But the candidate card data comes from the `["threads", threadId]` query cache, while the setup totals come from a separate `["setups", setupId]` query cache. These caches can be out of sync: the user edits a candidate's weight in one tab, invalidating the threads cache, but if the setup was fetched earlier and has not been refetched, the "current setup weight" baseline in the delta is stale. The preview shows a delta calculated against the wrong baseline.
+
+The second failure mode: if `candidate.weightGrams` is `null` (not yet entered), displaying `+-- / +$89` is confusing. Users see "null delta" and assume the comparison is broken rather than understanding that the candidate has no weight data.
 
 **Why it happens:**
-Status tracking looks simple -- it is just a string field. But the combination of item-level status + thread-level lifecycle + the "move winner to collection" side effect creates a state machine with many transitions, and without explicit modeling, invalid states are reachable.
+Impact preview feels like pure computation — "just subtract two numbers." The developer writes it as a derived value from two props and does not think about cache coherence. The null case is often overlooked because the developer tests with complete candidate data.
 
 **How to avoid:**
-Model the thread lifecycle as an explicit state machine with defined transitions. Document which item statuses are valid in each thread state. The "resolve thread" action should be a single transaction that: (1) validates the winner exists, (2) creates the collection item, (3) marks the thread as resolved, (4) updates the thread item status. Use a state diagram during design, not just field definitions.
+1. Derive the delta from data already co-located in one cache entry where possible. The thread detail query (`["threads", threadId]`) returns all candidates; the setup query (`["setups", setupId]`) returns items with weight. Compute the delta in the component using both: `delta = candidate.weightGrams - replacedItemWeight` where `replacedItemWeight` is taken from the currently loaded setup data.
+2. Use `useQuery` for setup data with the setup selector in the same component that renders the comparison, so both data sources are reactive.
+3. Handle null weight explicitly: show "-- (no weight data)" not "--g" for candidates without weights. Make the null state visually distinct from a zero delta.
+4. Do NOT make a server-side `/api/threads/:id/impact?setupId=:sid` endpoint that computes delta server-side — this creates a third cache entry to invalidate and adds network latency to what should be a purely client-side calculation.
 
 **Warning signs:**
-- Thread status and item status are independent string/enum fields with no transition validation
-- No transaction wrapping the "resolve thread + create collection item" flow
-- UI shows impossible combinations (resolved thread with "researching" items)
+- Impact delta shows stale values after editing a candidate's weight
+- Null weight candidates show a numerical delta (treating null as 0)
+- Delta calculation is in a server route rather than a client-side derived value
+- Setup data is fetched via a different hook than the one used for candidate data, with no shared staleness boundary
 
 **Phase to address:**
-Phase 2 (Planning threads) -- design the state machine before writing any thread code. Do not add statuses incrementally.
+Impact preview phase — establish the data flow (client-side derived from two existing queries) before building the UI so the stale-cache problem cannot arise.
 
 ---
 
-### Pitfall 4: Image Storage Strategy Causes Data Loss or Bloat
+### Pitfall 4: Side-by-Side Comparison Breaks at Narrow Widths
 
 **What goes wrong:**
-Two failure modes: (A) Images stored as file paths break when files are moved, deleted, or the app directory changes. Dangling references show broken image icons everywhere. (B) Images stored as BLOBs in SQLite bloat the database, slow down backups, and make the DB file unwieldy as the collection grows.
+The comparison view is built with a fixed two-or-three-column grid for the candidate cards. On a laptop at 1280px it looks great. On a narrower viewport or when the browser window is partially shrunk, the columns collapse to ~200px each, making the candidate name truncated, the weight/price badges unreadable, and the notes text invisible. The user cannot actually compare the candidates — the view that was supposed to help them decide becomes unusable.
+
+GearBox's existing design philosophy is mobile-responsive, but comparison tables are inherently wide. The tension is real: side-by-side requires horizontal space that mobile cannot provide.
 
 **Why it happens:**
-Image storage seems like a simple problem. File paths are the obvious approach but create a coupling between database records and filesystem state. BLOBs seem self-contained but do not scale with photo-heavy collections.
+Comparison views are usually mocked at full desktop width. Responsiveness is added as an afterthought, and the "fix" is often to stack columns vertically on mobile — which defeats the entire purpose of side-by-side comparison.
 
 **How to avoid:**
-Store images in a dedicated directory within the app's data folder (e.g., `data/images/{item-id}/`). Store relative paths in the database (never absolute). Generate deterministic filenames from item ID + timestamp to avoid collisions. On item deletion, clean up the image directory. For thumbnails under 100KB, SQLite BLOBs are actually 35% faster than filesystem reads, so consider storing thumbnails as BLOBs while keeping full-size images on disk.
+1. Build the comparison view as a horizontally scrollable container on mobile (`overflow-x: auto`). Do not collapse to vertical stack — comparing stacked items is cognitively equivalent to switching between detail pages.
+2. Limit the number of simultaneously compared candidates to 3 (or at most 4). Comparing 8 candidates side-by-side is unusable regardless of screen size.
+3. Use a minimum column width (e.g., `min-width: 200px`) so the container scrolls horizontally before the column content becomes illegible.
+4. Sticky first column for candidate names when scrolling horizontally, so the user always knows which column they are reading.
+5. Test at 768px viewport width before considering the feature done.
 
 **Warning signs:**
-- Absolute file paths in the database
-- No cleanup logic when items are deleted (orphaned images accumulate)
-- Database file growing much larger than expected (images stored as BLOBs)
-- No fallback/placeholder when an image file is missing
+- Comparison grid uses percentage widths that collapse below 150px
+- No horizontal scroll on the comparison container
+- Mobile viewport shows columns stacked vertically
+- Candidate name or weight badges are truncated without tooltip
 
 **Phase to address:**
-Phase 1 (Core CRUD with item photos) -- image handling must be decided before any photos are stored. Migrating image storage strategy later requires moving files and updating every record.
+Side-by-side comparison UI phase — responsive behavior must be designed in, not retrofitted. The minimum column width and scroll container decision shapes the entire component structure.
 
 ---
 
-### Pitfall 5: Setup Composition Breaks on Collection Changes
+### Pitfall 5: Pros/Cons Fields Stored as Free Text in Column, Not Structured
 
 **What goes wrong:**
-A setup ("Summer Bikepacking") references items from the collection. When an item is deleted from the collection, updated, or replaced via a planning thread resolution, the setup silently breaks -- showing stale data, missing items, or incorrect totals. The user's carefully composed setup becomes untrustworthy.
+Pros and cons per candidate are stored as two free-text columns: `pros TEXT` and `cons TEXT` on `thread_candidates`. The user types a multi-line blob of text into each field. The comparison view renders them as raw text blocks next to each other. Two problems emerge:
+- Formatting: the comparison view cannot render individual pro/con bullet points because the data is unstructured blobs
+- Length: one candidate has a 500-word "pros" essay; another has two words. The comparison columns have wildly unequal heights, making the side-by-side comparison visually chaotic and hard to scan
+
+The deeper problem: free text in a comparison context produces noise, not signal. Users write "it's really lightweight and packable and the color options are nice" when what the comparison view needs is scannable bullet points.
 
 **Why it happens:**
-Setups are modeled as a simple join table (setup_id, item_id) without considering what happens when the item side changes. The relationship is treated as static when it is actually dynamic.
+Adding two text columns to `thread_candidates` is the simplest possible implementation. The developer tests it with neat, short text and it looks fine. The UX failure is only visible when a real user writes the way real users write.
 
 **How to avoid:**
-Use foreign keys with explicit `ON DELETE` behavior (not CASCADE -- that silently removes setup entries). When an item is deleted, mark the setup-item link as "removed" and show a visual indicator in the setup view ("1 item no longer in collection"). When a planning thread resolves and replaces an item, offer to update setups that contained the old item. Setups should always recompute totals from live item data, never cache them.
+1. Store pros/cons as newline-delimited strings, not markdown or JSON. The UI splits on newlines and renders each line as a bullet. Simple, no parsing, no migration complexity.
+2. In the form, use a `<textarea>` with a placeholder of "one item per line." Show a character count.
+3. In the comparison view, render each newline-delimited entry as its own row, so columns stay scannable. Use a max of 5 bullet points per field; truncate with "show more" if longer.
+4. Cap `pros` and `cons` field length at 500 characters in the Zod schema to prevent essay-length blobs.
+5. The comparison view should truncate to the first 3 bullets when in compact comparison mode, with expand option.
 
 **Warning signs:**
-- Setup totals are stored as columns rather than computed from item data
-- No foreign key constraints between setups and items
-- Deleting a collection item does not check if it belongs to any setup
-- No UI indication when a setup references a missing item
+- `pros TEXT` and `cons TEXT` added to schema with no length constraint
+- Comparison view renders `{candidate.pros}` as a raw string in a `<p>` tag
+- One candidate's pros column is 3x taller than another's, making row alignment impossible
+- Form shows a full-height textarea with no guidance on format
 
 **Phase to address:**
-Phase 3 (Setups) -- but the foreign key design must be planned in Phase 1 when the items table is created. The item schema needs to anticipate setup references.
+Both the ranking schema phase (when pros/cons columns are added) and the comparison UI phase (when the rendering decision is made). The newline-delimited format must be decided at schema design time.
 
 ---
 
-### Pitfall 6: Comparison View That Does Not Actually Help Decisions
+### Pitfall 6: Impact Preview Compares Against Wrong Setup Total When Item Would Be Replaced
 
 **What goes wrong:**
-The side-by-side comparison in planning threads shows raw data (weight: 450g, price: $120) without context. Users cannot see at a glance which candidate is lighter, cheaper, or how each compares to what they already own. The comparison becomes a formatted table, not a decision tool. Users go back to their spreadsheet because it was easier to add formulas.
+The impact preview shows the delta for each candidate as if the candidate would be *added* to the setup. But the real use case is: "I want to replace my current tent with one of these candidates — which one saves the most weight?" The user expects the delta to reflect `candidateWeight - currentItemWeight`, not just `+candidateWeight`.
+
+When the delta is calculated as a pure addition (no replacement), a 500g candidate looks like "+500g" even though the item it replaces weighs 800g, meaning it would actually save 300g. The user sees a positive delta and dismisses the candidate when they should pick it.
 
 **Why it happens:**
-Building a comparison view that displays data is easy. Building one that surfaces insights ("this is 30% lighter than your current tent but costs 2x more") requires computing deltas against the existing collection, which is a different feature than just showing two items side by side.
+"Impact" is ambiguous. The developer defaults to "how much weight does this add?" because that calculation is simpler (no need to identify which existing item is being replaced). The replacement case requires the user to specify which item in the setup would be swapped out, which feels like additional UX complexity.
 
 **How to avoid:**
-Design comparison views to show: (1) absolute values for each candidate, (2) deltas between candidates (highlighted: lighter/heavier, cheaper/more expensive), (3) delta against the current item being replaced from the collection. Use color coding or directional indicators (green down arrow for weight savings, red up arrow for cost increase). This is the core value proposition of GearBox -- do not ship a comparison that is worse than a spreadsheet.
+1. Support both modes: "add to setup" (+delta) and "replace item" (delta = candidate - replaced item). Make the mode selection explicit in the UI.
+2. Default to "add" mode if no item in the setup shares the same category as the thread. Default to "replace" mode if an item with the same category exists — offer it as a pre-populated suggestion ("Replaces: Big Agnes Copper Spur 2? Change").
+3. The replacement item selector should be a dropdown filtered to setup items in the same category, defaulting to the most likely match.
+4. If no setup is selected, show raw candidate weight rather than a delta — do not calculate a delta against zero.
 
 **Warning signs:**
-- Comparison view is a static table with no computed differences
-- No way to link a thread to "the item I'm replacing" from the collection
-- Weight/cost impact on overall setup is not visible from the thread view
+- Delta is always positive (never shows weight savings)
+- No replacement item selector in the impact preview UI
+- Thread category is not used to suggest a candidate's likely replacement item
+- Delta is calculated as `candidate.weightGrams` with no baseline
 
 **Phase to address:**
-Phase 2 (Planning threads) -- comparison is the heart of the thread feature. Build the delta computation alongside the basic thread CRUD, not as a follow-up.
+Impact preview design phase — the "add vs replace" distinction must be designed before building the service layer, because "add" and "replace" produce fundamentally different calculations and different UI affordances.
+
+---
+
+### Pitfall 7: Schema Change Adds Columns Without Updating Test Helper
+
+**What goes wrong:**
+v1.3 requires adding `sortOrder`, `pros`, and `cons` to `thread_candidates`. The developer updates `src/db/schema.ts`, runs `bun run db:push`, and builds the feature. Tests fail with cryptic "no such column" errors — or worse, tests pass silently because they do not exercise the new columns, while the real database has them.
+
+This pitfall already existed in v1.2 (documented in the previous PITFALLS.md) and the test helper (`tests/helpers/db.ts`) uses raw CREATE TABLE SQL that must be manually kept in sync.
+
+**Why it happens:**
+Under time pressure, the developer focuses on the feature and forgets the test helper update. The error only surfaces when the new service function is called in a test. The CLAUDE.md documents this requirement, but it is easy to miss in the flow of development.
+
+**How to avoid:**
+For every schema change in v1.3, update `tests/helpers/db.ts` in the same commit:
+- `thread_candidates`: add `sort_order REAL DEFAULT 0`, `pros TEXT`, `cons TEXT`
+- Run `bun test` immediately after schema + helper update, before writing any other code
+
+Consider writing a schema-parity test: compare the columns returned by `PRAGMA table_info(thread_candidates)` against a known expected list, failing if they differ. This catches the test-helper-out-of-sync problem automatically.
+
+**Warning signs:**
+- Tests failing with `SqliteError: no such column`
+- New service function works in the running app but throws in `bun test`
+- `bun run db:push` was run but `bun test` was not run afterward
+- `tests/helpers/db.ts` has fewer columns than `src/db/schema.ts`
+
+**Phase to address:**
+Every schema-touching phase of v1.3. The candidate ranking schema phase (sortOrder, pros, cons) is the primary risk. Check test helper parity as an explicit completion criterion.
+
+---
+
+### Pitfall 8: Comparison View Includes Resolved Candidates
+
+**What goes wrong:**
+After a thread is resolved (winner picked), the thread's candidates still exist in the database. The comparison view, if it loads candidates from the existing `getThreadWithCandidates` response without filtering, will display the resolved winner alongside all losers — including the now-irrelevant candidates. A user revisiting a resolved thread to check why they picked Option A sees all candidates re-listed in the comparison view with no indication of which was selected, creating confusion.
+
+The secondary problem: if the app allows drag-to-reorder ranking on a resolved thread, a user could accidentally fire rank-update mutations on a thread that should be read-only.
+
+**Why it happens:**
+The comparison view and ranking components are built for active threads and tested only with active threads. Resolved thread behavior is not considered during design.
+
+**How to avoid:**
+1. Check `thread.status === "resolved"` before rendering the comparison/ranking UI. For resolved threads, render a read-only summary: "You chose [winner name]" with the winning candidate highlighted and others shown as non-interactive.
+2. Disable drag-to-reorder on resolved threads entirely — don't render the drag handles.
+3. In the impact preview, disable the "Impact on Setup" panel for resolved threads and instead show "Added to collection on [date]" for the winning candidate.
+4. The API route for rank updates should reject requests for resolved threads (return 400 with "Thread is resolved").
+
+**Warning signs:**
+- Comparison/ranking UI renders identically for active and resolved threads
+- Drag handles are visible on resolved thread candidates
+- No `thread.status` check in the comparison view component
+- Resolved threads accept rank update mutations
+
+**Phase to address:**
+Comparison UI phase and ranking phase — both must include a resolved-thread guard. This is a correctness issue, not just a UX issue, because drag mutations on resolved threads corrupt state.
 
 ---
 
@@ -140,21 +234,29 @@ Shortcuts that seem reasonable but create long-term problems.
 
 | Shortcut | Immediate Benefit | Long-term Cost | When Acceptable |
 |----------|-------------------|----------------|-----------------|
-| Caching setup totals in a column | Faster reads, simpler queries | Stale data when items change, bugs when totals disagree with item sum | Never -- always compute from source items |
-| Storing currency as float | Simple to implement | Floating point rounding errors in price totals (classic $0.01 bugs) | Never -- use integer cents or a decimal type |
-| Skipping "replaced by" links in threads | Simpler thread resolution | Cannot track upgrade history, cannot auto-update setups | Only in earliest prototype, must add before thread resolution ships |
-| Hardcoding unit labels | Faster initial development | Cannot support multiple hobbies with different unit conventions (e.g., ml for water bottles) | MVP only if unit conversion layer is planned for next phase |
-| Single image per item | Simpler UI and storage | Gear often needs multiple angles, especially for condition tracking | Acceptable for v1 if schema supports multiple images (just limit UI to one) |
+| Integer `sortOrder` instead of fractional | Simple schema | Bulk UPDATE on every reorder; bulk write latency with 10+ candidates | Acceptable only if max candidates per thread is enforced at 5 or fewer |
+| Server-side delta calculation endpoint | Simpler client code | Third cache entry to invalidate; network round-trip on every setup selection change | Never — the calculation is two subtractions using data already in client cache |
+| Pros/cons as unstructured free-text blobs | Zero schema complexity | Comparison view cannot render bullets; columns misalign | Never for comparison display — use newline-delimited format from day one |
+| Comparison grid with `overflow: hidden` on narrow viewports | Avoids horizontal scroll complexity | Comparison becomes unreadable on laptop with panels open; critical feature breaks | Never — horizontal scroll is the correct behavior for comparison tables |
+| Rendering comparison for resolved threads without guard | Simpler component logic | Users can drag-reorder resolved threads, corrupting state | Never — the resolved-thread guard is a correctness requirement |
+| `DragOverlay` using same component as `useSortable` | Less component code | ID collision in dnd-kit causes undefined behavior during drag | Never — dnd-kit explicitly requires a separate presentational component for DragOverlay |
+
+---
 
 ## Integration Gotchas
 
-Common mistakes when connecting to external services.
+Common mistakes when connecting new v1.3 features to existing v1.2 systems.
 
-| Integration | Common Mistake | Correct Approach |
-|-------------|----------------|------------------|
-| Product link scraping | Attempting to auto-fetch product details from URLs, which breaks constantly as sites change layouts | Store the URL as a plain link. Do not scrape. Let users enter details manually. Scraping is a maintenance burden that exceeds its value for a single-user app. |
-| Image URLs vs local storage | Hotlinking product images from retailer sites, which break when products are delisted | Always download and store images locally. External URLs rot within months. |
-| Export/import formats | Building a custom JSON format that only GearBox understands | Support CSV import/export as the universal fallback. Users are migrating from spreadsheets -- CSV is their native format. |
+| Integration Point | Common Mistake | Correct Approach |
+|-------------------|----------------|------------------|
+| Ranking + React Query | Using `setQueryData` alone for optimistic reorder, causing flicker | Maintain `tempItems` local state in the drag component; render from `tempItems ?? queryData.candidates`; clear on `onSettled` |
+| Impact preview + weight unit | Computing delta in grams but displaying with `formatWeight` that expects the stored unit | Delta is always computed in grams (raw stored values); apply `formatWeight(delta, unit)` once at display time, same pattern as all other weight displays |
+| Impact preview + null weights | Treating `null` weightGrams as 0 in delta calculation | Show "-- (no weight data)" explicitly; never pass null to arithmetic; guard with `candidate.weightGrams != null && setup.totalWeight != null` |
+| Pros/cons + thread resolution | Pros/cons text copied to collection item on resolve | Do NOT copy pros/cons to the items table — these are planning notes, not collection metadata. `resolveThread` in `thread.service.ts` should remain unchanged |
+| Rank order + existing `getThreadWithCandidates` | Adding `ORDER BY sort_order` to `getThreadWithCandidates` changes the order of an existing query used by other components | Add `sort_order` to the SELECT and ORDER BY in `getThreadWithCandidates`. Audit all consumers of this query to verify they are unaffected by ordering change (the candidate cards already render in whatever order the query returns) |
+| Comparison view + `isActive` prop | `CandidateCard.tsx` uses `isActive` to show/hide the "Winner" button. Comparison view must not show "Winner" button inline if comparison has its own resolve affordance | Pass `isActive={false}` to `CandidateCard` when rendering inside comparison view, or create a separate `CandidateComparisonCard` presentational component that omits action buttons |
+
+---
 
 ## Performance Traps
 
@@ -162,10 +264,12 @@ Patterns that work at small scale but fail as usage grows.
 
 | Trap | Symptoms | Prevention | When It Breaks |
 |------|----------|------------|----------------|
-| Loading all collection items for every setup view | Slow page loads, high memory usage | Paginate collection views; setup views should query only member items | 500+ items in collection |
-| Recomputing all setup totals on every item edit | Edit latency increases linearly with number of setups | Only recompute totals for setups containing the edited item | 20+ setups referencing overlapping items |
-| Storing full-resolution photos without thumbnails | Page loads become unusably slow when browsing collection | Generate thumbnails on upload; use thumbnails in list views, full images only in detail view | 50+ items with photos |
-| Loading all thread candidates for comparison | Irrelevant for small threads, but threads can accumulate many "considered" items | Limit comparison view to 3-4 selected candidates; archive dismissed ones | 15+ candidates in a single thread |
+| Bulk integer rank updates on every drag | Visible latency after each drop; multiple UPDATE statements per drag; SQLite write lock held | Use fractional `sortOrder REAL` so only the moved item requires an UPDATE | 8+ candidates per thread with rapid dragging |
+| Comparison view fetching all candidates for all threads | Slow initial load; excessive memory for large thread lists | Comparison view uses the already-loaded `["threads", threadId]` query; never fetches candidates outside the active thread's query | 20+ threads with 5+ candidates each |
+| Sync rank updates on every `dragOver` event (not just `dragEnd`) | Thousands of UPDATE mutations during a single drag; server overwhelmed; UI lags | Persist rank only on `onDragEnd` (drop), never on `onDragOver` (in-flight hover) | Any usage — `onDragOver` fires on every cursor pixel moved |
+| `useQuery` for setups list inside impact preview component | N+1 query pattern: each candidate card fetches its own setup list | Lift setup list query to the thread detail page level; pass selected setup as prop or context | 3+ candidates in comparison view |
+
+---
 
 ## Security Mistakes
 
@@ -173,9 +277,11 @@ Domain-specific security issues beyond general web security.
 
 | Mistake | Risk | Prevention |
 |---------|------|------------|
-| No backup mechanism for SQLite database | Single file corruption = total data loss of entire collection | Implement automatic periodic backups (copy the .db file). Provide a manual "export all" button. Single-user apps have no server-side backup by default. |
-| Product URLs stored without sanitization | Stored URLs could contain javascript: protocol or XSS payloads if rendered as links | Validate URLs on save (must be http/https). Render with `rel="noopener noreferrer"`. |
-| Image uploads without size/type validation | Malicious or accidental upload of huge files or non-image files | Validate file type (accept only jpg/png/webp) and enforce max size (e.g., 5MB) on upload. |
+| `sortOrder` accepts any float value | Malformed values like `NaN`, `Infinity`, or extremely large floats stored in `sort_order` column, corrupting order | Validate `sortOrder` as a finite number in Zod schema: `z.number().finite()`. Reject `NaN` and `Infinity` at API boundary |
+| Pros/cons fields with no length limit | Users or automated input can store multi-kilobyte text blobs, inflating the database and slowing candidate queries | Cap at 500 characters per field in Zod: `z.string().max(500).optional()` |
+| Rank update endpoint accepts any candidateId | A crafted request can reorder candidates from a different thread by passing a candidateId that belongs to another thread | In the rank update service, verify `candidate.threadId === threadId` before applying the update — same pattern as existing `resolveThread` validation |
+
+---
 
 ## UX Pitfalls
 
@@ -183,25 +289,33 @@ Common user experience mistakes in this domain.
 
 | Pitfall | User Impact | Better Approach |
 |---------|-------------|-----------------|
-| Requiring all fields to add an item | Users abandon data entry because they do not know the weight or price yet for items they already own | Only require name. Make weight, price, category, etc. optional. Users fill in details over time. |
-| No bulk operations for collection management | Adding 30 existing items one-by-one is painful enough that users never finish initial setup | Provide CSV import for initial collection population. Consider a "quick add" mode with minimal fields. |
-| Thread resolution is destructive | User resolves a thread and loses all the research notes and rejected candidates | Archive resolved threads, do not delete them. Users want to reference why they chose item X over Y months later. |
-| Flat item list with no visual grouping | Collection becomes an unscannable wall of text at 50+ items | Group by tag/category in the default view. Provide sort options (weight, price, date added). Show item thumbnails in list view. |
-| Weight displayed without context | "450g" means nothing without knowing if that is heavy or light for this category | Show weight relative to the lightest/heaviest item in the same category, or relative to the item being replaced |
-| No "undo" for destructive actions | Accidental deletion of an item with detailed notes is unrecoverable | Soft-delete with a 30-day trash, or at minimum a confirmation dialog that names the item being deleted |
+| Comparison table loses column headers on scroll | User scrolls down to see notes/pros/cons and forgets which column is which candidate | Sticky column headers with candidate name, image thumbnail, and weight. Use `position: sticky; top: 0` on the header row |
+| Delta shows raw gram values when user prefers oz | Impact preview shows "+450g" to a user who has set their unit to oz | Apply `formatWeight(delta, unit)` using the `useWeightUnit()` hook, same as all other weight displays in the app |
+| Drag-to-reorder with no visual rank indicator | After ranking, it is unclear that the order matters or that #1 is the "top pick" | Show rank numbers (1, 2, 3...) as badges on each candidate card when in ranking mode. Update numbers live during drag |
+| Pros/cons fields empty by default in comparison view | Comparison table shows empty cells next to populated ones, making the comparison feel sparse and incomplete | Show a subtle "Add pros/cons" prompt in empty cells when the thread is active. In read-only resolved view, hide the pros/cons section entirely if no candidate has data |
+| Impact preview setup selector defaults to no setup | User arrives at comparison view and sees no impact numbers because no setup is pre-selected | Default the setup selector to the most recently viewed/modified setup. Persist the last-selected setup in `sessionStorage` or a URL param |
+| Removing a candidate clears comparison selection | User has candidates A, B, C in comparison; deletes C; comparison resets entirely | Comparison state (which candidates are selected) should be stored in local component state keyed by candidate ID. On delete, simply remove that ID from the selection |
+
+---
 
 ## "Looks Done But Isn't" Checklist
 
 Things that appear complete but are missing critical pieces.
 
-- [ ] **Item CRUD:** Often missing image cleanup on delete -- verify orphaned images are removed when items are deleted
-- [ ] **Planning threads:** Often missing the "link to existing collection item being replaced" -- verify threads can reference what they are upgrading
-- [ ] **Setup composition:** Often missing recomputation on item changes -- verify that editing an item's weight updates all setups containing it
-- [ ] **CSV import:** Often missing unit detection/conversion -- verify that importing "5 oz" vs "142g" both result in correct canonical storage
-- [ ] **Thread resolution:** Often missing setup propagation -- verify that resolving a thread and adding the winner to collection offers to update setups that contained the replaced item
-- [ ] **Comparison view:** Often missing delta computation -- verify that the comparison shows differences between candidates, not just raw values side by side
-- [ ] **Dashboard totals:** Often missing staleness handling -- verify dashboard stats reflect current data, not cached snapshots
-- [ ] **Item deletion:** Often missing setup impact check -- verify the user is warned "This item is in 3 setups" before confirming deletion
+- [ ] **Drag-to-reorder:** Often missing drag handles — verify the drag affordance is visually distinct (grip icon), not just "drag anywhere on the card" which conflicts with the existing click-to-edit behavior
+- [ ] **Drag-to-reorder:** Often missing keyboard reorder fallback — verify candidates can be moved with arrow keys for accessibility (dnd-kit's `KeyboardSensor` must be added to `DndContext`)
+- [ ] **Drag-to-reorder:** Often missing flicker fix — verify dropping a candidate does not briefly snap back to original position (requires `tempItems` local state, not just `setQueryData`)
+- [ ] **Drag-to-reorder:** Often missing resolved-thread guard — verify drag handles are hidden and mutations are blocked on resolved threads
+- [ ] **Impact preview:** Often missing the null weight case — verify candidates with no weight show "-- (no weight data)" not "NaNg" or "+0g"
+- [ ] **Impact preview:** Often missing the replace-vs-add distinction — verify the user can specify which existing item would be replaced, not just see a pure addition delta
+- [ ] **Impact preview:** Often missing unit conversion — verify the delta respects `useWeightUnit()` and `useCurrency()`, not hardcoded to grams/USD
+- [ ] **Side-by-side comparison:** Often missing horizontal scroll on narrow viewports — verify the view is usable at 768px without column collapsing
+- [ ] **Side-by-side comparison:** Often missing sticky headers — verify candidate names remain visible when scrolling the comparison rows
+- [ ] **Pros/cons fields:** Often missing length validation — verify Zod schema caps the field and the textarea shows a character counter
+- [ ] **Pros/cons display:** Often missing newline-to-bullet rendering — verify newlines in the stored text render as bullet points in the comparison view, not as `\n` characters
+- [ ] **Schema changes:** Often missing test helper update — verify `tests/helpers/db.ts` includes `sort_order`, `pros`, and `cons` columns after the schema migration
+
+---
 
 ## Recovery Strategies
 
@@ -209,12 +323,15 @@ When pitfalls occur despite prevention, how to recover.
 
 | Pitfall | Recovery Cost | Recovery Steps |
 |---------|---------------|----------------|
-| Mixed units without conversion | MEDIUM | Add unit column to items table. Write a migration script that prompts user to confirm/correct units for existing items. Recompute all setup totals. |
-| Rigid category hierarchy | HIGH | Migrate categories to tags (each leaf category becomes a tag). Update all item references. Redesign category UI to tag-based UI. |
-| Thread state machine bugs | MEDIUM | Audit all threads for impossible states. Write a cleanup script. Add transition validation. Retest all state transitions. |
-| Image path breakage | LOW-MEDIUM | Write a script that scans DB for broken image paths. Move images to canonical location. Update paths. Add fallback placeholder. |
-| Stale setup totals | LOW | Drop cached total columns. Replace with computed queries. One-time migration, no data loss. |
-| Currency as float | MEDIUM | Multiply all price values by 100, change column type to integer (cents). Rounding during conversion may lose sub-cent precision. |
+| Drag flicker due to no `tempItems` local state | LOW | Add `tempItems` state to the ranking component. Render from `tempItems ?? queryData.candidates`. No data migration needed. |
+| Integer `sortOrder` causing bulk updates | MEDIUM | Add Drizzle migration to change `sort_order` column type from INTEGER to REAL. Update existing rows to spaced values (1000, 2000, 3000...). Update service layer to use fractional logic. |
+| Delta treats null weight as 0 | LOW | Add null guards in the delta calculation component. No data changes needed. |
+| Pros/cons stored as unformatted blobs | LOW | No migration needed — the data is still correct. Update the rendering component to split on newlines. Add length validation to the Zod schema for new input. |
+| Comparison view visible on resolved threads | LOW | Add `if (thread.status === 'resolved') return <ResolvedView />` before rendering the comparison/ranking UI. Add 400 check in the rank update API route. |
+| Test helper out of sync with schema | LOW | Update CREATE TABLE statements in `tests/helpers/db.ts`. Run `bun test`. Fix any test that relied on the old column count. |
+| Rank update accepts cross-thread candidateId | LOW | Add `candidate.threadId !== threadId` guard in rank update service (same pattern as existing `resolveThread` guard). |
+
+---
 
 ## Pitfall-to-Phase Mapping
 
@@ -222,28 +339,30 @@ How roadmap phases should address these pitfalls.
 
 | Pitfall | Prevention Phase | Verification |
 |---------|------------------|--------------|
-| Unit handling | Phase 1: Data model | Schema stores canonical grams + original unit. Conversion utility exists with tests. |
-| Category rigidity | Phase 1: Data model | Items have a tags array/join table. No hierarchical category table exists. |
-| Image storage | Phase 1: Core CRUD | Images stored in `data/images/` with relative paths. Thumbnails generated on upload. Cleanup on delete. |
-| Currency precision | Phase 1: Data model | Price stored as integer cents. Display layer formats to dollars/euros. |
-| Thread state machine | Phase 2: Planning threads | State transitions documented in code. Invalid transitions throw errors. Resolution is transactional. |
-| Comparison usefulness | Phase 2: Planning threads | Comparison view shows deltas. Thread can link to "item being replaced." Setup impact visible. |
-| Setup integrity | Phase 3: Setups | Totals computed from live data. Item deletion warns about setup membership. Soft-delete or archive for removed items. |
-| Data loss / no backup | Phase 1: Infrastructure | Automatic DB backup on a schedule. Manual export button on dashboard. |
-| Bulk import | Phase 1: Core CRUD | CSV import available from collection view. Handles unit variations in weight column. |
+| dnd-kit + React Query flicker | Candidate ranking phase | Drop a candidate, verify no snap-back. Add automated test: mock drag end, verify list order reflects drop position immediately. |
+| Bulk integer rank writes | Schema design for ranking | `sortOrder` column is `REAL` type in Drizzle schema. Service layer issues exactly one UPDATE per reorder. Test: reorder 5 candidates, verify only 1 DB write. |
+| Stale data in impact preview | Impact preview phase | Change a candidate's weight, verify delta updates immediately. Select a different setup, verify delta recalculates from new baseline. |
+| Comparison broken at narrow width | Comparison UI phase | Test at 768px viewport. Verify horizontal scroll is present and content is readable. No vertical stack of comparison columns. |
+| Pros/cons as unstructured blobs | Ranking schema phase (when columns added) | Verify Zod schema caps at 500 chars. Verify comparison view renders newlines as bullets. Test: enter 3-line pros text, verify 3 bullets rendered. |
+| Impact preview add vs replace | Impact preview design phase | Thread with same-category item in setup defaults to replace mode. Pure-add mode available as alternative. Test: replace mode shows negative delta when candidate is lighter. |
+| Comparison/rank on resolved threads | Both comparison and ranking phases | Verify drag handles are absent on resolved threads. Verify rank update API returns 400 for resolved thread. |
+| Test helper schema drift | Every schema-touching phase of v1.3 | After schema change, run `bun test` immediately. Zero test failures from column-not-found errors. |
+
+---
 
 ## Sources
 
-- [Ultralight: The Gear Tracking App I'm Leaving LighterPack For](https://trailsmag.net/blogs/hiker-box/ultralight-the-gear-tracking-app-i-m-leaving-lighterpack-for) -- LighterPack limitations and community complaints
-- [SQLite Internal vs External BLOBs](https://sqlite.org/intern-v-extern-blob.html) -- official SQLite guidance on image storage tradeoffs
-- [35% Faster Than The Filesystem](https://sqlite.org/fasterthanfs.html) -- SQLite BLOB performance data
-- [Comparison Tables for Products, Services, and Features - NN/g](https://www.nngroup.com/articles/comparison-tables/) -- comparison UX best practices
-- [Designing The Perfect Feature Comparison Table - Smashing Magazine](https://www.smashingmagazine.com/2017/08/designing-perfect-feature-comparison-table/) -- comparison table design patterns
-- [Comparing products: UX design best practices - Contentsquare](https://contentsquare.com/blog/comparing-products-design-practices-to-help-your-users-avoid-fragmented-comparison-7/) -- product comparison UX pitfalls
-- [Common Unit Conversion Mistakes That Break Applications](https://helppdev.com/en/blog/common-unit-conversion-mistakes-that-break-applications) -- unit conversion antipatterns
-- [Inventory App Design - UXPin](https://www.uxpin.com/studio/blog/inventory-app-design/) -- inventory app UX patterns
-- [Designing better file organization around tags, not hierarchies](https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies) -- tags vs hierarchy tradeoffs
+- [dnd-kit Discussion #1522: React Query + DnD flicker](https://github.com/clauderic/dnd-kit/discussions/1522) — `tempItems` solution for React Query cache flicker
+- [dnd-kit Issue #921: Sorting not working with React Query](https://github.com/clauderic/dnd-kit/issues/921) — Root cause of the state lifecycle mismatch
+- [dnd-kit Sortable Docs: OptimisticSortingPlugin](https://dndkit.com/concepts/sortable) — New API for handling optimistic reorder
+- [TanStack Query: Optimistic Updates guide](https://tanstack.com/query/v4/docs/react/guides/optimistic-updates) — `onMutate`/`onSettled` rollback patterns
+- [Fractional Indexing: Steveruiz.me](https://www.steveruiz.me/posts/reordering-fractional-indices) — Why fractional keys beat integer reorder for databases
+- [Fractional Indexing SQLite library](https://github.com/sqliteai/fractional-indexing) — Implementation reference for base62 lexicographic sort keys
+- [Baymard Institute: Comparison Tool Design](https://baymard.com/blog/user-friendly-comparison-tools) — Sticky headers, horizontal scroll, minimum column width for product comparison UX
+- [NN/G: Comparison Tables](https://www.nngroup.com/articles/comparison-tables/) — Avoid prose in comparison cells; use scannable structured values
+- [LogRocket: When comparison charts hurt UX](https://blog.logrocket.com/ux-design/feature-comparison-tips-when-not-to-use/) — Comparison table anti-patterns
+- Direct codebase analysis of GearBox v1.2 (schema.ts, thread.service.ts, setup.service.ts, CandidateCard.tsx, useSetups.ts, useCandidates.ts, tests/) — existing patterns, integration points, and established conventions
 
 ---
-*Pitfalls research for: GearBox -- gear management and purchase planning app*
-*Researched: 2026-03-14*
+*Pitfalls research for: GearBox v1.3 — Research & Decision Tools (side-by-side comparison, impact preview, candidate ranking)*
+*Researched: 2026-03-16*

.planning/research/STACK.md

@@ -1,191 +1,198 @@
-# Stack Research
+# Stack Research -- v1.3 Research & Decision Tools
 
-**Domain:** Single-user gear management and purchase planning web app
-**Researched:** 2026-03-14
+**Project:** GearBox
+**Researched:** 2026-03-16
+**Scope:** Stack additions for side-by-side candidate comparison, setup impact preview, and drag-to-reorder candidate ranking with pros/cons
 **Confidence:** HIGH
 
-## Recommended Stack
+## Key Finding: Zero New Dependencies
 
-### Core Technologies
+All three v1.3 features are achievable with the existing stack. The drag-to-reorder feature, which would normally require a dedicated DnD library, is covered by `framer-motion`'s built-in `Reorder` component — already installed at v12.37.0 with React 19 support confirmed.
 
-| Technology | Version | Purpose | Why Recommended |
-|------------|---------|---------|-----------------|
-| Bun | 1.3.x | Runtime, package manager, bundler | User constraint. Built-in SQLite, fast installs, native TS support. Eliminates need for separate runtime/bundler/pkg manager. |
-| React | 19.2.x | UI framework | Industry standard, massive ecosystem, stable. Server Components not needed for this SPA -- stick with client-side React. |
-| Vite | 8.0.x | Dev server, production builds | Rolldown-based builds (5-30x faster than Vite 7). Zero-config React support. Bun-compatible. HMR out of the box. |
-| Hono | 4.12.x | Backend API framework | Built on Web Standards, first-class Bun support, zero dependencies, tiny (~12kB). Perfect for a lightweight REST API. Faster than Express on Bun benchmarks. |
-| SQLite (bun:sqlite) | Built-in | Database | Zero-dependency, built into Bun runtime. 3-6x faster than better-sqlite3. Single file database -- perfect for single-user app. No server process to manage. |
-| Drizzle ORM | 0.45.x | Database ORM, migrations | Type-safe SQL, ~7.4kB, zero dependencies. Native bun:sqlite driver support. SQL-like query API (not abstracting SQL away). Built-in migration tooling via drizzle-kit. |
-| Tailwind CSS | 4.2.x | Styling | CSS-native configuration (no JS config file). Auto content detection. Microsecond incremental builds. Perfect for "light, airy, minimalist" design constraint. |
-| TanStack Router | 1.167.x | Client-side routing | Full type-safe routing with typed params and search params. File-based route generation. Better SPA experience than React Router v7 (whose best features require framework mode). |
-| TanStack Query | 5.93.x | Server state management | Handles API data fetching, caching, and synchronization. Eliminates manual loading/error state management. Automatic cache invalidation on mutations. |
-| Zustand | 5.0.x | Client state management | Minimal boilerplate, ~1kB. For UI state like active filters, modal state, theme. TanStack Query handles server state; Zustand handles the rest. |
-| Zod | 4.3.x | Schema validation | Validates API inputs on the server, form data on the client, and shares types between both. Single source of truth for data shapes. |
-| TypeScript | 5.x (Bun built-in) | Type safety | Bun transpiles TS natively -- no tsc needed at runtime. Catches bugs at dev time. Required by Drizzle and TanStack Router for type-safe queries and routes. |
+## Recommended Stack: Existing Technologies Only
 
-### Supporting Libraries
+### No New Dependencies Required
 
-| Library | Version | Purpose | When to Use |
-|---------|---------|---------|-------------|
-| @tanstack/react-query-devtools | 5.x | Query debugging | Development only. Inspect cache state, refetch timing, query status. |
-| drizzle-kit | latest | DB migrations CLI | Run `drizzle-kit generate` and `drizzle-kit migrate` for schema changes. |
-| @hono/zod-validator | latest | Request validation middleware | Validate API request bodies/params using Zod schemas in Hono routes. |
-| clsx | 2.x | Conditional class names | When building components with variant styles. Pairs with Tailwind. |
-| @tanstack/react-router-devtools | latest | Router debugging | Development only. Inspect route matches, params, search params. |
+| Feature | Library Needed | Status |
+|---------|---------------|--------|
+| Side-by-side comparison view | None — pure layout/UI | Existing Tailwind CSS |
+| Setup impact preview | None — SQL delta calculation | Existing Drizzle ORM + TanStack Query |
+| Drag-to-reorder candidates | `Reorder` component | Already in `framer-motion@12.37.0` |
+| Pros/cons text fields | None — schema + form | Existing Drizzle + Zod + React |
 
-### Development Tools
+### How Each Feature Uses the Existing Stack
 
-| Tool | Purpose | Notes |
-|------|---------|-------|
-| Bun | Test runner | `bun test` -- built-in, Jest-compatible API. No need for Vitest or Jest. |
-| Biome | Linter + formatter | Single tool replacing ESLint + Prettier. Fast (Rust-based), minimal config. `biome check --write` does both. |
-| Vite React plugin | React HMR/JSX | `@vitejs/plugin-react` for Fast Refresh during development. |
+#### 1. Side-by-Side Candidate Comparison
+
+**No schema changes. No new dependencies.**
+
+| Existing Tech | How It Is Used |
+|---------------|----------------|
+| Tailwind CSS v4 | Responsive comparison table layout. Horizontal scroll on mobile with `overflow-x-auto`. Fixed first column (row labels) using `sticky left-0`. |
+| TanStack Query (`useThread`) | Thread detail already fetches all candidates in one query. Comparison view reads from the same cached data — no new API endpoint. |
+| Lucide React | Comparison row icons (weight, price, status, link). Already in the curated icon set. |
+| `formatWeight` / `formatPrice` | Existing formatters handle display with selected unit/currency. No changes needed. |
+| `useWeightUnit` / `useCurrency` | Existing hooks provide formatting context. Comparison view uses them identically to `CandidateCard`. |
+
+**Implementation approach:** Add a view toggle (grid vs. comparison table) to the thread detail page. The comparison view is a `<table>` or CSS grid with candidates as columns and attributes as rows. Data already lives in `useThread` response — no API changes.
+
+#### 2. Setup Impact Preview
+
+**No new dependencies. Requires one new API endpoint.**
+
+| Existing Tech | How It Is Used |
+|---------------|----------------|
+| Drizzle ORM | New query: for a given setup, sum `weight_grams` and `price_cents` of its items. Then compute delta against each candidate's `weight_grams` and `price_cents`. Pure arithmetic in the service layer. |
+| TanStack Query | New `useSetupImpact(threadId, setupId)` hook fetching `GET /api/threads/:threadId/impact?setupId=X`. Returns array of `{ candidateId, weightDelta, costDelta }`. |
+| Hono + Zod validator | New route validates `setupId` query param. Delegates to service function. |
+| `formatWeight` / `formatPrice` | Format deltas with `+` prefix for positive values (candidate adds weight/cost) and `-` for negative (candidate is lighter/cheaper than what's already in setup). |
+| `useSetups` hook | Existing `useSetups()` provides the setup list for the picker dropdown. |
+
+**Delta calculation logic (server-side service):**
+
+```typescript
+// For each candidate in thread:
+// weightDelta = candidate.weightGrams - (matching item in setup).weightGrams
+// If no matching item in setup (it would be added, not replaced): delta = candidate.weightGrams
+
+// A "matching item" means: item in setup with same categoryId as the thread.
+// This is the intended semantic: "how does picking this candidate affect my setup?"
+```
+
+**Key decision:** Impact preview is read-only and derived. It does not mutate any data. It computes what *would* happen if the candidate were picked, without modifying the setup. The delta is displayed inline on each candidate card or in the comparison view.
+
+#### 3. Drag-to-Reorder Candidate Ranking with Pros/Cons
+
+**No new DnD library. Requires schema changes.**
+
+| Existing Tech | How It Is Used |
+|---------------|----------------|
+| `framer-motion@12.37.0` `Reorder` | `Reorder.Group` wraps the candidate list. `Reorder.Item` wraps each candidate card. `onReorder` updates local order state. `onDragEnd` fires the persist mutation. |
+| Drizzle ORM | Two new columns on `thread_candidates`: `sortOrder integer` (default 0, lower = higher rank) and `pros text` / `cons text` (nullable). |
+| TanStack Query mutation | `usePatchCandidate` for pros/cons text updates. `useReorderCandidates` for bulk sort order update after drag-end. |
+| Hono + Zod validator | `PATCH /api/threads/:threadId/candidates/reorder` accepts `{ candidates: Array<{ id, sortOrder }> }`. `PATCH /api/candidates/:id` accepts `{ pros?, cons? }`. |
+| Zod | Extend `updateCandidateSchema` with `pros: z.string().nullable().optional()`, `cons: z.string().nullable().optional()`, `sortOrder: z.number().int().optional()`. |
+
+**Framer Motion `Reorder` API pattern:**
+
+```typescript
+import { Reorder } from "framer-motion";
+
+// State holds candidates sorted by sortOrder
+const [orderedCandidates, setOrderedCandidates] = useState(
+  [...candidates].sort((a, b) => a.sortOrder - b.sortOrder)
+);
+
+// onReorder fires continuously during drag — update local state only
+// onDragEnd fires once on drop — persist to DB
+<Reorder.Group
+  axis="y"
+  values={orderedCandidates}
+  onReorder={setOrderedCandidates}
+>
+  {orderedCandidates.map((candidate) => (
+    <Reorder.Item
+      key={candidate.id}
+      value={candidate}
+      onDragEnd={() => persistOrder(orderedCandidates)}
+    >
+      <CandidateCard ... />
+    </Reorder.Item>
+  ))}
+</Reorder.Group>
+```
+
+**Schema changes required:**
+
+| Table | Column | Type | Default | Purpose |
+|-------|--------|------|---------|---------|
+| `thread_candidates` | `sort_order` | `integer NOT NULL` | `0` | Rank position (lower = higher rank) |
+| `thread_candidates` | `pros` | `text` | `NULL` | Free-text pros annotation |
+| `thread_candidates` | `cons` | `text` | `NULL` | Free-text cons annotation |
+
+**Sort order persistence pattern:** On drag-end, send the full reordered array with new `sortOrder` values (0-based index positions). Backend replaces existing `sort_order` values atomically. This is the same delete-all + re-insert pattern used for `setupItems` but as an UPDATE instead.
 
 ## Installation
 
 ```bash
-# Initialize project
-bun init
-
-# Core frontend
-bun add react react-dom @tanstack/react-router @tanstack/react-query zustand zod clsx
-
-# Core backend
-bun add hono @hono/zod-validator drizzle-orm
-
-# Styling
-bun add tailwindcss @tailwindcss/vite
-
-# Build tooling
-bun add -d vite @vitejs/plugin-react typescript @types/react @types/react-dom
-
-# Database tooling
-bun add -d drizzle-kit
-
-# Linting + formatting
-bun add -d @biomejs/biome
-
-# Dev tools (optional but recommended)
-bun add -d @tanstack/react-query-devtools @tanstack/react-router-devtools
+# No new packages. Zero.
 ```
 
-## Architecture Pattern
-
-**Monorepo-lite (single package, split directories):**
-
-```
-/src
-  /client          -- React SPA (Vite entry point)
-    /routes         -- TanStack Router file-based routes
-    /components     -- Shared UI components
-    /stores         -- Zustand stores
-    /api            -- TanStack Query hooks (fetch wrappers)
-  /server          -- Hono API server
-    /routes         -- API route handlers
-    /db             -- Drizzle schema, migrations
-  /shared          -- Zod schemas shared between client and server
-/public            -- Static assets, uploaded images
-```
-
-Bun runs the Hono server, which also serves the Vite-built SPA in production. In development, Vite dev server proxies API calls to the Hono backend.
+All required capabilities are already installed.
 
 ## Alternatives Considered
 
-| Recommended | Alternative | When to Use Alternative |
-|-------------|-------------|-------------------------|
-| Hono | Elysia | If you want end-to-end type safety with Eden Treaty. Elysia is Bun-native but heavier, more opinionated, and has a smaller ecosystem than Hono. |
-| Hono | Express | Never for new Bun projects. Express is Node-centric, not built on Web Standards, slower on Bun. |
-| TanStack Router | React Router v7 | If you want the simplest possible routing with minimal type safety. React Router v7's best features (loaders, type safety) require framework mode which adds complexity. |
-| Drizzle ORM | Prisma | If you have a complex relational model and want auto-generated migrations. But Prisma is heavy (~8MB), generates a query engine binary, and has weaker SQLite support. |
-| Drizzle ORM | Kysely | If you want a pure query builder without ORM features. Kysely is lighter but lacks built-in migration tooling. |
-| Zustand | Jotai | If you prefer atomic state (bottom-up). Zustand is simpler for this app's needs -- a few global stores, not many independent atoms. |
-| Tailwind CSS | Vanilla CSS / CSS Modules | If you strongly prefer writing plain CSS. But Tailwind accelerates building consistent minimalist UIs and requires less design system setup. |
-| bun:sqlite | PostgreSQL | If you later need multi-user with concurrent writes. Overkill for single-user. Adds a database server dependency. |
-| Biome | ESLint + Prettier | If you need specific ESLint plugins not yet in Biome. But Biome covers 95% of use cases with zero config. |
-| Vite | Bun's built-in bundler | Bun can serve HTML directly as of 1.3, but Vite's ecosystem (plugins, HMR, proxy) is far more mature for SPA development. |
+### Drag and Drop: Why Not Add a Dedicated Library?
 
-## What NOT to Use
+| Option | Version | React 19 Status | Verdict |
+|--------|---------|-----------------|---------|
+| `framer-motion` Reorder (already installed) | 12.37.0 | React 19 explicit peerDep (`^18.0.0 || ^19.0.0`) | USE THIS |
+| `@dnd-kit/core` + `@dnd-kit/sortable` | 6.3.1 | No React 19 support (stale ~1yr, open GitHub issue #1511) | AVOID |
+| `@dnd-kit/react` (new rewrite) | 0.3.2 | React 19 compatible | Pre-1.0, no maintainer ETA on stable |
+| `@hello-pangea/dnd` | 18.0.1 | No React 19 (stale ~1yr, peerDep `^18.0.0` only) | AVOID |
+| `pragmatic-drag-and-drop` | latest | Core is React-agnostic but some sub-packages missing React 19 | Overkill for a single sortable list |
+| Custom HTML5 DnD | N/A | N/A | 200+ lines of boilerplate, worse accessibility |
+
+**Why framer-motion `Reorder` wins:** Already in the bundle. React 19 peer dep confirmed in lockfile. Handles the single use case (vertical sortable list) with 10 lines of code. Provides smooth layout animations at zero additional cost. The limitation (no cross-container drag, no multi-row grid) does not apply — candidate ranking is a single vertical list.
+
+**Why not `@dnd-kit`:** The legacy `@dnd-kit/core@6.3.1` has no official React 19 support and has been unmaintained for ~1 year. The new `@dnd-kit/react@0.3.2` does support React 19 but is pre-1.0 with zero maintainer response on stability/roadmap questions (GitHub Discussion #1842 has 0 replies). Adding a pre-1.0 library when the project already has a working solution is unjustifiable.
+
+### Setup Impact: Why Not Client-Side Calculation?
+
+Client-side delta calculation (using cached React Query data) is simpler to implement but:
+- Requires loading both the full setup items list AND all candidates into the client
+- Introduces staleness bugs if setup items change in another tab
+- Is harder to test (service test vs. component test)
+
+Server-side calculation in a service function is testable, authoritative, and consistent with the existing architecture (services compute aggregates, not components).
+
+## What NOT to Add
 
 | Avoid | Why | Use Instead |
 |-------|-----|-------------|
-| Next.js | Server-centric framework. Massive overhead for a single-user SPA. Forces Node.js patterns. No benefit without SSR/SSG needs. | Vite + React + Hono |
-| Remix / React Router framework mode | Adds server framework complexity. This is a simple SPA with a separate API -- framework routing is unnecessary overhead. | TanStack Router (SPA mode) |
-| better-sqlite3 | Requires native compilation, compatibility issues with Bun. bun:sqlite is built-in and 3-6x faster. | bun:sqlite (built into Bun) |
-| Redux / Redux Toolkit | Massive boilerplate for a small app. Actions, reducers, slices -- all unnecessary when Zustand does the same in 10 lines. | Zustand |
-| Mongoose / MongoDB | Document DB is wrong fit. Gear items have relational structure (items belong to setups, threads reference items). SQL is the right model. | Drizzle + SQLite |
-| Axios | Unnecessary abstraction over fetch. Bun and browsers both have native fetch. TanStack Query wraps fetch already. | Native fetch |
-| styled-components / Emotion | CSS-in-JS adds runtime overhead and bundle size. Tailwind is faster (zero runtime) and better for consistent minimalist design. | Tailwind CSS |
-| Jest / Vitest | Bun has a built-in test runner with Jest-compatible API. No need for external test frameworks. | bun test |
-| ESLint + Prettier | Two tools, complex configuration, slow (JS-based). Biome does both in one tool, faster. | Biome |
+| `@dnd-kit/core` + `@dnd-kit/sortable` | No React 19 support, stale for ~1 year (latest 6.3.1 from 2024) | `framer-motion` Reorder (already installed) |
+| `@hello-pangea/dnd` | No React 19 support, peerDep `react: "^18.0.0"` only, stale | `framer-motion` Reorder |
+| `react-comparison-table` or similar component packages | Fragile third-party layouts for a simple table. Custom Tailwind table is trivial and design-consistent. | Custom Tailwind CSS table layout |
+| Modal/dialog library (Radix, Headless UI) | The project already has a hand-rolled modal pattern (`SlideOutPanel`, `ConfirmDialog`). Adding a library for one more dialog adds inconsistency. | Extend existing modal patterns |
+| Rich text editor for pros/cons | Markdown editors are overkill for a single-line annotation field. Users want a quick note, not a document. | Plain `<textarea>` with Tailwind styling |
+
+## Stack Patterns by Variant
+
+**If the comparison view needs mobile scroll:**
+- Wrap comparison table in `overflow-x-auto`
+- Freeze the first column (attribute labels) with `sticky left-0 bg-white z-10`
+- This is pure CSS, no JavaScript or library needed
+
+**If the setup impact preview needs a setup picker:**
+- Use `useSetups()` (already exists) to populate a `<select>` dropdown
+- Store selected setup ID in local component state (not URL params — this is transient UI)
+- No new state management needed
+
+**If pros/cons fields need to auto-save:**
+- Use a debounced mutation (300-500ms) that fires on `onChange`
+- Or save on `onBlur` (simpler, adequate for this use case)
+- Existing `useUpdateCandidate` hook already handles candidate mutations — extend schema only
 
 ## Version Compatibility
 
-| Package A | Compatible With | Notes |
-|-----------|-----------------|-------|
-| Bun 1.3.x | bun:sqlite (built-in) | SQLite driver is part of the runtime, always compatible. |
-| Drizzle ORM 0.45.x | bun:sqlite via `drizzle-orm/bun-sqlite` | Official driver. Import from `drizzle-orm/bun-sqlite`. |
-| Drizzle ORM 0.45.x | drizzle-kit (latest) | drizzle-kit handles migration generation/execution. Must match major drizzle-orm version. |
-| React 19.2.x | TanStack Router 1.x | TanStack Router 1.x supports React 18+ and 19.x. |
-| React 19.2.x | TanStack Query 5.x | TanStack Query 5.x supports React 18+ and 19.x. |
-| React 19.2.x | Zustand 5.x | Zustand 5.x supports React 18+ and 19.x. |
-| Vite 8.x | @vitejs/plugin-react | Check plugin version matches Vite major. Use latest plugin for Vite 8. |
-| Tailwind CSS 4.2.x | @tailwindcss/vite | v4 uses Vite plugin instead of PostCSS. Import as `@tailwindcss/vite` in vite config. |
-| Zod 4.x | @hono/zod-validator | Verify @hono/zod-validator supports Zod 4. If not, pin Zod 3.23.x until updated. |
-
-## Key Configuration Notes
-
-### Bun + Vite Setup
-Vite runs as the dev server for the frontend. The Hono API server runs separately. Use Vite's `server.proxy` to forward `/api/*` requests to the Hono backend during development.
-
-### SQLite WAL Mode
-Enable WAL mode on database initialization for better performance:
-```typescript
-import { Database } from "bun:sqlite";
-const db = new Database("gearbox.db");
-db.run("PRAGMA journal_mode = WAL");
-db.run("PRAGMA foreign_keys = ON");
-```
-
-### Tailwind v4 (No Config File)
-Tailwind v4 uses CSS-native configuration. No `tailwind.config.js` needed:
-```css
-@import "tailwindcss";
-@theme {
-  --color-primary: #2563eb;
-  --font-sans: "Inter", sans-serif;
-}
-```
-
-### Drizzle Schema Example (bun:sqlite)
-```typescript
-import { sqliteTable, text, integer, real } from "drizzle-orm/sqlite-core";
-
-export const gearItems = sqliteTable("gear_items", {
-  id: integer("id").primaryKey({ autoIncrement: true }),
-  name: text("name").notNull(),
-  category: text("category").notNull(),
-  weightGrams: real("weight_grams"),
-  priceCents: integer("price_cents"),
-  source: text("source"),
-  notes: text("notes"),
-  createdAt: integer("created_at", { mode: "timestamp" }).notNull(),
-});
-```
+| Package | Version in Project | React 19 Compatible | Notes |
+|---------|-------------------|---------------------|-------|
+| `framer-motion` | 12.37.0 | YES — peerDeps `"^18.0.0 || ^19.0.0"` confirmed in lockfile | `Reorder` component available since v5 |
+| `drizzle-orm` | 0.45.1 | N/A (server-side) | ALTER TABLE or migration for new columns |
+| `zod` | 4.3.6 | N/A | Extend existing schemas |
+| `@tanstack/react-query` | 5.90.21 | YES | New hooks follow existing patterns |
 
 ## Sources
 
-- [Bun official docs](https://bun.com/docs) -- bun:sqlite features, runtime capabilities (HIGH confidence)
-- [Hono official docs](https://hono.dev/docs) -- Bun integration, static serving (HIGH confidence)
-- [Drizzle ORM docs - Bun SQLite](https://orm.drizzle.team/docs/connect-bun-sqlite) -- driver support verified (HIGH confidence)
-- [Vite releases](https://vite.dev/releases) -- v8.0 with Rolldown confirmed (HIGH confidence)
-- [Tailwind CSS v4.2 blog](https://tailwindcss.com/blog/tailwindcss-v4) -- CSS-native config, Vite plugin (HIGH confidence)
-- [TanStack Router docs](https://tanstack.com/router/latest) -- v1.167.x confirmed (HIGH confidence)
-- [TanStack Query docs](https://tanstack.com/query/latest) -- v5.93.x for React (HIGH confidence)
-- [Zustand npm](https://www.npmjs.com/package/zustand) -- v5.0.x confirmed (HIGH confidence)
-- [Zod v4 release notes](https://zod.dev/v4) -- v4.3.x confirmed (MEDIUM confidence -- verify @hono/zod-validator compatibility)
-- [React versions](https://react.dev/versions) -- v19.2.x confirmed (HIGH confidence)
-- [Bun SQLite vs better-sqlite3 benchmarks](https://bun.com/docs/runtime/sqlite) -- 3-6x performance advantage (HIGH confidence)
+- [framer-motion package lockfile entry] — peerDeps `react: "^18.0.0 || ^19.0.0"` confirmed (HIGH confidence, from project's `bun.lock`)
+- [Motion Reorder docs](https://motion.dev/docs/react-reorder) — `Reorder.Group`, `Reorder.Item`, `useDragControls` API, `onDragEnd` pattern for persisting order (HIGH confidence)
+- [Motion Changelog](https://motion.dev/changelog) — v12.37.0 actively maintained through Feb 2026 (HIGH confidence)
+- [@dnd-kit/core npm](https://www.npmjs.com/package/@dnd-kit/core) — v6.3.1, last published ~1 year ago, no React 19 support (HIGH confidence)
+- [dnd-kit React 19 issue #1511](https://github.com/clauderic/dnd-kit/issues/1511) — CLOSED but React 19 TypeScript issues confirmed (MEDIUM confidence)
+- [@dnd-kit/react roadmap discussion #1842](https://github.com/clauderic/dnd-kit/discussions/1842) — 0 maintainer replies on stability question (HIGH confidence — signals pre-1.0 risk)
+- [hello-pangea/dnd React 19 issue #864](https://github.com/hello-pangea/dnd/issues/864) — React 19 support still open as of Jan 2026 (HIGH confidence)
+- [Top 5 Drag-and-Drop Libraries for React 2026](https://puckeditor.com/blog/top-5-drag-and-drop-libraries-for-react) — ecosystem overview confirming dnd-kit and hello-pangea/dnd limitations (MEDIUM confidence)
 
 ---
-*Stack research for: GearBox -- gear management and purchase planning web app*
-*Researched: 2026-03-14*
+*Stack research for: GearBox v1.3 -- Research & Decision Tools*
+*Researched: 2026-03-16*

.planning/research/SUMMARY.md

@@ -1,243 +1,182 @@
 # Project Research Summary
 
-**Project:** GearBox
-**Domain:** Single-user gear management and purchase planning web app
-**Researched:** 2026-03-14
+**Project:** GearBox v1.3 — Research & Decision Tools
+**Domain:** Gear management — candidate comparison, setup impact preview, drag-to-reorder ranking with pros/cons
+**Researched:** 2026-03-16
 **Confidence:** HIGH
 
 ## Executive Summary
 
-GearBox is a single-user personal gear management app with a critical differentiator: purchase planning threads. Every competitor (LighterPack, GearGrams, Packstack, Hikt) is a post-purchase inventory tool — they help you track what you own. GearBox closes the loop by adding a structured pre-purchase research workflow where users compare candidates, track research status, and resolve threads by promoting winners into their collection. This is the entire reason to build the product; the collection management side is table stakes, and the purchase planning threads are the moat. Research strongly recommends building both together in the v1 scope, not sequencing them separately, because the thread resolution workflow only becomes compelling once a real collection exists to reference.
+GearBox v1.3 adds three decision-support features to the existing thread detail page: side-by-side candidate comparison, setup impact preview (weight/cost delta), and drag-to-reorder candidate ranking with pros/cons annotation. All four research areas converge on the same conclusion — the existing stack is sufficient and no new dependencies are required. `framer-motion@12.37.0` (already installed) provides the `Reorder` component for drag-to-reorder, eliminating the need for `@dnd-kit` (which lacks React 19 support) or any other library. Two of the three features (comparison view and impact preview) require zero schema changes and can be built as pure client-side derived views using data already cached by `useThread()` and `useSetup()`.
 
-The recommended architecture is a single-process Bun fullstack monolith: Hono for the API layer, React 19 + Vite 8 for the frontend, Drizzle ORM + bun:sqlite for the database, TanStack Router + TanStack Query for client navigation and server state, and Tailwind CSS v4 for styling. This stack is purpose-built for the constraints: Bun is a project requirement, SQLite is optimal for single-user, and every tool in the list has zero or near-zero runtime overhead. Zustand handles the small amount of client-only UI state. The entire stack is type-safe end-to-end through Zod schemas shared between client and server.
+The recommended build sequence is dependency-driven: schema migration first (adds `sort_order`, `pros`, `cons` to `thread_candidates`), then ranking UI (uses the new columns), then comparison view and impact preview in parallel (both are schema-independent client additions). This order eliminates the risk of mid-feature migrations and ensures the comparison table can display rank, pros, and cons from day one rather than being retrofitted. The entire milestone touches 3 new files and 10 modified files — a contained, low-blast-radius changeset.
 
-The biggest risks are front-loaded in Phase 1: unit handling (weights must be canonicalized to grams from day one), currency precision (prices must be stored as integer cents), category flexibility (must use user-defined tags, not a hardcoded hierarchy), and image storage strategy (relative paths to a local directory, never BLOBs for full-size, never absolute paths). Getting these wrong requires painful data migrations later. The second major risk is the thread state machine in Phase 2 — the combination of candidate status, thread lifecycle, and "move winner to collection" creates a stateful flow that must be modeled as an explicit state machine with transactional resolution, not assembled incrementally.
+The primary risks are implementation-level rather than architectural. Three patterns require deliberate design before coding: (1) use `tempItems` local state alongside React Query for drag reorder to prevent the well-documented flicker bug, (2) use `sortOrder REAL` (fractional) instead of `INTEGER` to avoid bulk UPDATE writes on every drag, and (3) treat impact preview as an "add vs replace" decision — not just a pure addition — since users comparing gear are almost always replacing an existing item, not stacking one on top. All three are avoidable with upfront design; recovery cost is low but retrofitting is disruptive.
 
 ## Key Findings
 
 ### Recommended Stack
 
-The stack is a tightly integrated Bun-native toolchain with no redundant tools. Bun serves as runtime, package manager, test runner, and provides built-in SQLite — eliminating entire categories of infrastructure. Vite 8 (Rolldown-based, 5-30x faster than Vite 7) handles the dev server and production frontend builds. The client-server boundary is clean: Hono serves the API, React handles the UI, and Zod schemas in a `shared/` directory provide a single source of truth for data shapes on both sides.
-
-The architecture note in STACK.md suggests Bun's fullstack HTML-based routing (not Vite's dev server proxy pattern). This differs slightly from the standard Vite proxy setup: each page is a separate HTML entrypoint imported into `Bun.serve()`, and TanStack Router handles in-page client-side navigation only. This simplifies the development setup to a single `bun run` command with no proxy configuration.
+Zero new dependencies are needed for this milestone. The existing stack handles all three features: Tailwind CSS for the comparison table layout, `framer-motion`'s `Reorder` component for drag ordering, Drizzle ORM + Hono + Zod for the one new write endpoint (`PATCH /api/threads/:id/candidates/reorder`), and TanStack Query for the new `useReorderCandidates` mutation. All other React Query hooks (`useThread`, `useSetup`, `useSetups`) already exist and return the data needed for comparison and impact preview without modification.
 
 **Core technologies:**
-- Bun 1.3.x: Runtime, package manager, test runner, bundler — eliminates Node.js and npm
-- React 19.2.x + Vite 8.x: SPA framework + dev server — stable, large ecosystem, HMR out of the box
-- Hono 4.12.x: API layer — Web Standards based, first-class Bun support, ~12kB, faster than Express on Bun
-- SQLite (bun:sqlite) + Drizzle ORM 0.45.x: Database — zero-dependency, built into Bun, type-safe queries and migrations
-- TanStack Router 1.167.x + TanStack Query 5.93.x: Routing + server state — full type-safe routing, automatic cache invalidation
-- Tailwind CSS 4.2.x: Styling — CSS-native config, no JS file, microsecond incremental builds
-- Zustand 5.x: Client UI state — minimal boilerplate for filter state, modals, theme
-- Zod 4.3.x: Schema validation — shared between client and server as single source of truth for types
-- Biome: Linting + formatting — replaces ESLint + Prettier, Rust-based, near-zero config
+- `framer-motion@12.37.0` (Reorder component): drag-to-reorder — already installed, React 19 peerDeps confirmed in `bun.lock`, replaces any need for `@dnd-kit`
+- `drizzle-orm@0.45.1`: three new columns on `thread_candidates` (`sort_order REAL`, `pros TEXT`, `cons TEXT`) plus one new service function (`reorderCandidates`)
+- Tailwind CSS v4: comparison table layout with `overflow-x-auto`, `sticky left-0` for frozen label column, `min-w-[200px]` per candidate column
+- TanStack Query v5 + existing hooks: impact preview and comparison view derived entirely from cached `useThread` + `useSetup` data — no new API endpoints on read paths
+- Zod v4: extend `updateCandidateSchema` with `sortOrder: z.number().finite()`, `pros: z.string().max(500).optional()`, `cons: z.string().max(500).optional()`
 
-**Version flag:** Verify that `@hono/zod-validator` supports Zod 4.x before starting. If not, pin Zod 3.23.x until the validator is updated.
+**What NOT to use:**
+- `@dnd-kit/core@6.3.1` — no React 19 support, unmaintained for ~1 year
+- `@dnd-kit/react@0.3.2` — pre-1.0, no maintainer response on stability
+- `@hello-pangea/dnd@18.0.1` — `peerDep react: "^18.0.0"` only, stale
+- Any third-party comparison table component — custom Tailwind table is trivial and design-consistent
 
 ### Expected Features
 
-The feature research distinguishes cleanly between what every gear app does (table stakes) and what GearBox uniquely does (purchase planning threads). No competitor has threads, candidate comparison, or thread resolution. This is the entire competitive surface. Everything else is hygiene.
+All five v1.3 features are confirmed as P1 (must-have for this milestone). No existing gear management tool (LighterPack, GearGrams, OutPack) has comparison view, delta preview, or ranking — these are unmet-need differentiators adapted from e-commerce comparison UX to the gear domain.
 
-**Must have (table stakes) — v1 launch:**
-- Item CRUD with weight, price, category, notes, product URL — minimum unit of value
-- User-defined categories/tags — must be flexible, not a hardcoded hierarchy
-- Weight unit support (g, oz, lb, kg) — gear community requires this; store canonical grams internally
-- Automatic weight/cost totals by category and setup — the reason to use an app over a text file
-- Named setups composed from collection items — compose loadouts, get aggregate totals
-- Planning threads with candidate items — the core differentiator
-- Side-by-side candidate comparison with deltas (not just raw values) — the payoff of threads
-- Thread resolution: pick winner, move to collection — closes the purchase research loop
-- Search and filter on collection — essential at 30+ items
-- Dashboard home page — clean entry point per project constraints
+**Must have (table stakes):**
+- Side-by-side comparison view — users juggling 3+ candidates mentally across cards expect tabular layout; NNGroup and Smashing Magazine confirm this is the standard for comparison contexts
+- Weight and cost delta per candidate — gear apps always display weight prominently; delta is more actionable than raw weight
+- Setup selector for impact preview — required to contextualize the delta; `useSetups()` already exists
 
-**Should have (competitive) — v1.x after validation:**
-- Impact preview: how a thread candidate changes a specific setup's weight and cost
-- Status tracking on thread items (researching / ordered / arrived)
-- Priority/ranking within threads
-- Photos per item (one photo per item initially)
-- CSV import/export — migration path from spreadsheets, data portability
-- Weight distribution visualization (pie/bar chart by category)
+**Should have (differentiators):**
+- Drag-to-rank ordering — makes priority explicit without numeric input; no competitor has this in the gear domain; requires `sort_order` schema migration
+- Per-candidate pros/cons fields — structured decision rationale; stored as newline-delimited text (renders as bullets in comparison view); requires `pros`/`cons` schema migration
 
-**Defer — v2+:**
-- Multi-photo gallery per item
-- Shareable read-only links for setups
-- Drag-and-drop reordering
-- Bulk operations (multi-select, bulk delete)
-- Dark mode
-- Item history/changelog
+**Defer (v2+):**
+- Classification-aware impact breakdown (base/worn/consumable) — data available but UI complexity high; flat delta covers 90% of use case
+- Rank badge on card grid — useful but low urgency; add when users express confusion
+- Mobile-optimized comparison view (swipe between candidates) — horizontal scroll works for now
+- Comparison permalink — requires auth/multi-user work not in scope for v1
+
+**Anti-features (explicitly rejected):**
+- Custom comparison attributes — complexity trap, rejected in PROJECT.md
+- Score/rating calculation — opaque algorithms distrust; manual ranking expresses user preference better
+- Cross-thread comparison — candidates are decision-scoped; different categories are not apples-to-apples
 
 ### Architecture Approach
 
-The architecture is a monolithic Bun process with a clear 4-layer structure: API routes (HTTP concerns), service layer (business logic and calculations), Drizzle ORM (type-safe data access), and bun:sqlite (embedded storage). There are no microservices, no Docker, no external database server. The client is a React SPA served as static files by the same Bun process. Internal communication is REST + JSON; no WebSockets needed. The data model has three primary entities — items, threads (with candidates), and setups — connected by explicit foreign keys and a junction table for the many-to-many setup-to-items relationship.
+All three features integrate on the `/threads/$threadId` route with no impact on other routes. The comparison view and impact preview are pure client-side derived views using data already in the React Query cache — no new API endpoints on read paths. The only new server-side endpoint is `PATCH /:id/candidates/reorder` which accepts `{ orderedIds: number[] }` and applies a transactional bulk-update in `thread.service.ts`. The `uiStore` (Zustand) gains two new fields: `compareMode: boolean` and `impactSetupId: number | null`, consistent with existing UI-state-only patterns.
 
 **Major components:**
-1. Collection (items): Core entity. Source of truth for owned gear. Every other feature references items.
-2. Planning Threads (threads + candidates): Pre-purchase research. Thread lifecycle is a state machine; resolution is transactional.
-3. Setups: Named loadouts composed from collection items. Totals are always computed live from item data, never cached.
-4. Service Layer: Business logic isolated from HTTP concerns. Enables testing without HTTP mocking. Key: `calculateSetupTotals()`, `computeCandidateImpact()`.
-5. Dashboard: Read-only aggregation. Built last since it reads from all other entities.
-6. Image Storage: Filesystem (`./uploads/` or `data/images/{item-id}/`) with relative paths in DB. Thumbnails on upload.
+1. `CandidateCompare.tsx` (new) — side-by-side table; columns = candidates, rows = attributes; pure presentational, derives deltas from `thread.candidates[]`; `overflow-x-auto` for narrow viewports; sticky label column
+2. `SetupImpactRow.tsx` (new) — delta display (`+Xg / +$Y`); reads from `useSetup(impactSetupId)` data passed as props; handles null weight case explicitly
+3. `Reorder.Group` / `Reorder.Item` (framer-motion, no new file) — wraps `CandidateCard` list in `$threadId.tsx`; `onReorder` updates local `orderedCandidates` state; `onDragEnd` fires `useReorderCandidates` mutation
+4. `CandidateCard.tsx` (modified) — gains `rank` prop (gold/silver/bronze badge for top 3), pros/cons indicator icons; `isActive={false}` when rendered inside comparison view
+5. `CandidateForm.tsx` (modified) — gains `pros`/`cons` textarea fields below existing Notes field
 
-**Build order from ARCHITECTURE.md (follow this):**
-1. Database schema (Drizzle) — everything depends on this
-2. Items API (CRUD) — the core entity
-3. Collection UI — first visible feature, validates end-to-end
-4. Threads + candidates API and UI — depends on items for resolution
-5. Setups API and UI — depends on items for composition
-6. Dashboard — aggregates from all entities, build last
-7. Polish: image upload, impact calculations, status tracking
+**Key patterns to follow:**
+- `tempItems` local state alongside React Query for drag reorder — prevents the documented flicker bug; do not use `setQueryData` alone
+- Client-computed derived data from cached queries — no new read endpoints (anti-pattern: building `GET /api/threads/:id/compare` or `GET /api/threads/:id/impact`)
+- `uiStore` for cross-panel persistent UI flags only — no server data in Zustand
+- Resolved-thread guard — `thread.status === "resolved"` must disable drag handles and block the reorder endpoint (data integrity requirement, not just UX)
 
 ### Critical Pitfalls
 
-1. **Unit handling treated as display-only** — Store all weights as canonical grams at write time. Accept any unit as input, convert on save. Build a `weightToGrams(value, unit)` utility on day one. A bare number field with no unit tracking will silently corrupt all aggregates when users paste specs in mixed units.
+1. **Drag flicker from `setQueryData`-only optimistic update** — use `tempItems` local state (`useState<Candidate[] | null>(null)`); render from `tempItems ?? queryData.candidates`; clear on mutation `onSettled`. Must be designed before building the drag UI, not retrofitted. (PITFALLS.md Pitfall 1)
 
-2. **Rigid category hierarchy** — Use user-defined flat tags, not a hardcoded category tree. A `categories` table with `parent_id` foreign keys will fail the moment a user tries to track sim racing gear or photography equipment. Tags allow many-to-many, support any hobby, and do not require schema changes to add a new domain.
+2. **Integer `sortOrder` causes bulk writes** — use `REAL` (float) type for `sort_order` column with fractional indexing so only the moved item requires a single UPDATE. With 8+ candidates and rapid dragging, integer bulk updates produce visible latency and hold a SQLite write lock. Start values at 1000 with 1000-unit gaps. (PITFALLS.md Pitfall 2)
 
-3. **Thread state machine complexity** — Model the thread lifecycle as an explicit state machine before writing any code. Document valid transitions. The "resolve thread" action must be a single atomic transaction: validate winner exists, create collection item, mark thread resolved, update candidate statuses. Without this, impossible states (resolved thread with active candidates, ghost items in collection) accumulate silently.
+3. **Impact preview shows wrong delta (add vs replace)** — default to "replace" mode when a setup item exists in the same category as the thread; default to "add" mode when no category match. Pure-addition delta misleads users: a 500g candidate replacing an 800g item shows "+500g" instead of "-300g". The distinction must be designed into the service layer, not retrofitted. (PITFALLS.md Pitfall 6)
 
-4. **Setup totals cached in the database** — Never store `totalWeight` or `totalCost` on a setup record. Always compute from live item data via `SUM()`. Cached totals go stale the moment any member item is edited, and the bugs are subtle (the UI shows a total that doesn't match the items).
+4. **Comparison/rank on resolved threads** — `thread.status === "resolved"` must hide drag handles, disable rank mutation, and show a read-only summary. The reorder API route must return 400 for resolved threads. This is a data integrity issue, not just UX. (PITFALLS.md Pitfall 8)
 
-5. **Comparison view that displays data but doesn't aid decisions** — The comparison view must show deltas between candidates and against the item being replaced from the collection, not just raw values side by side. Color-code lighter/heavier, cheaper/more expensive. A comparison table with no computed differences is worse than a spreadsheet.
-
-**Additional high-priority pitfalls to address per phase:**
-- Currency stored as floats (use integer cents always)
-- Image paths stored as absolute paths or as BLOBs for full-size images
-- Thread resolution is destructive (archive threads, don't delete them — users need to reference why they chose X over Y)
-- Item deletion without setup impact warning
+5. **Test helper schema drift** — every schema change must update `tests/helpers/db.ts` in the same commit. Run `bun test` immediately after schema + helper update. Missing this produces `SqliteError: no such column` failures. (PITFALLS.md Pitfall 7)
 
 ## Implications for Roadmap
 
-Based on the combined research, a 5-phase structure is recommended. Phases 1-3 deliver the v1 MVP; Phases 4-5 deliver the v1.x feature set.
+Based on research, a 4-phase structure is recommended with a clear dependency order: schema foundation first, ranking second (consumes new columns), then comparison view and impact preview as sequential client-only phases.
 
-### Phase 1: Foundation — Data Model, Infrastructure, Core Item CRUD
+### Phase 1: Schema Foundation + Pros/Cons Fields
 
-**Rationale:** Everything depends on getting the data model right. Unit handling, currency precision, category flexibility, image storage strategy, and the items schema are all Phase 1 decisions. Getting these wrong requires expensive data migrations. The architecture research explicitly states: "Database schema + Drizzle setup — Everything depends on the data model." The pitfalls research agrees: 6 of 9 pitfalls have "Phase 1" as their prevention phase.
+**Rationale:** All ranking and pros/cons work shares a schema migration. Batching `sort_order`, `pros`, and `cons` into a single migration avoids multiple ALTER TABLE runs and ensures the test helper is updated once. Pros/cons field UI is low-complexity (two textareas in `CandidateForm`) and can be delivered immediately after the migration, making candidates richer before ranking is built.
+**Delivers:** `sort_order REAL NOT NULL DEFAULT 0`, `pros TEXT`, `cons TEXT` on `thread_candidates`; pros/cons visible in candidate edit panel; `CandidateCard` shows pros/cons indicator icons; `tests/helpers/db.ts` updated; Zod schemas extended with 500-char length caps
+**Addresses:** Side-by-side comparison row data (pros/cons), drag-to-rank prerequisite (sort_order)
+**Avoids:** Test helper schema drift (Pitfall 7), pros/cons as unstructured blobs (Pitfall 5 — newline-delimited format chosen at schema time)
 
-**Delivers:** Working gear catalog — users can add, edit, delete, and browse their collection. Item CRUD with all core fields. Weight unit conversion. User-defined categories. Image upload with thumbnail generation and cleanup on delete. SQLite database with WAL mode enabled, automatic backup mechanism, and all schemas finalized.
+### Phase 2: Drag-to-Reorder Candidate Ranking
 
-**Features from FEATURES.md:** Item CRUD with core fields, user-defined categories, weight unit support (g/oz/lb/kg), notes and product URL fields, search and filter.
+**Rationale:** Depends on Phase 1 (`sort_order` column must exist). Schema work is done; this phase is pure service + client. The `tempItems` pattern must be implemented correctly from the start to prevent the React Query flicker bug.
+**Delivers:** `reorderCandidates` service function (transactional loop); `PATCH /api/threads/:id/candidates/reorder` endpoint with thread ownership validation; `useReorderCandidates` mutation hook; `Reorder.Group` / `Reorder.Item` in thread detail route; rank badge (gold/silver/bronze) on `CandidateCard`; resolved-thread guard (no drag handles, API returns 400 for resolved)
+**Uses:** `framer-motion@12.37.0` Reorder API (already installed), Drizzle ORM transaction, fractional `sort_order REAL` arithmetic (single UPDATE per drag)
+**Avoids:** dnd-kit flicker (Pitfall 1 — `tempItems` pattern), bulk integer writes (Pitfall 2 — REAL type), resolved-thread corruption (Pitfall 8)
 
-**Pitfalls to prevent:** Unit handling (canonical grams), currency precision (integer cents), category flexibility (user-defined tags, no hierarchy), image storage (relative paths, thumbnails), data loss prevention (WAL mode, auto-backup mechanism).
+### Phase 3: Side-by-Side Comparison View
 
-**Research flag:** Standard patterns. Schema design for inventory apps is well-documented. No research phase needed.
+**Rationale:** No schema dependency — can technically be built before Phase 2, but is most useful when rank, pros, and cons are already in the data model so the comparison table shows the full picture from day one. Pure client-side presentational component; no API changes.
+**Delivers:** `CandidateCompare.tsx` component; "Compare" toggle button in thread header; `compareMode` in `uiStore`; comparison table with sticky label column, horizontal scroll, weight/price relative deltas (lightest/cheapest candidate highlighted); responsive at 768px viewport; read-only summary for resolved threads
+**Implements:** Client-computed derived data pattern — data from `useThread()` cache; `Math.min` across candidates for relative delta; `formatWeight`/`formatPrice` for display
+**Avoids:** Comparison breaking at narrow widths (Pitfall 4 — `overflow-x-auto` + `min-w-[200px]`), comparison visible on resolved threads (Pitfall 8), server endpoint for comparison deltas (architecture anti-pattern)
 
----
+### Phase 4: Setup Impact Preview
 
-### Phase 2: Planning Threads — The Core Differentiator
-
-**Rationale:** Threads are why GearBox exists. The feature dependency graph in FEATURES.md shows threads require items to exist (to resolve candidates into the collection), which is why Phase 1 must complete first. The thread state machine is the most complex feature in the product and gets its own phase to ensure the state transitions are modeled correctly before any UI is built.
-
-**Delivers:** Complete purchase planning workflow — create threads, add candidates with weight/price/notes, compare candidates side-by-side with weight/cost deltas (not just raw values), resolve threads by selecting a winner and moving it to the collection, archive resolved threads.
-
-**Features from FEATURES.md:** Planning threads, side-by-side candidate comparison (with deltas), thread resolution workflow. Does not include status tracking (researching/ordered/arrived) or priority/ranking — those are v1.x.
-
-**Pitfalls to prevent:** Thread state machine complexity (model transitions explicitly, transactional resolution), comparison usefulness (show deltas and impact, not just raw data), thread archiving (never destructive resolution).
-
-**Research flag:** Needs careful design work before coding. The state machine for thread lifecycle (open -> in-progress -> resolved/cancelled) combined with candidate status (researching / ordered / arrived) and the resolution side-effect (create collection item) has no off-the-shelf reference implementation. Design the state diagram first.
-
----
-
-### Phase 3: Setups — Named Loadouts and Composition
-
-**Rationale:** Setups require items to exist (Phase 1) and benefit from threads being stable (Phase 2) because thread resolution can affect setup membership (the replaced item should be updatable in setups). The many-to-many setup-items relationship and the setup integrity pitfall require careful foreign key design.
-
-**Delivers:** Named setups composed from collection items. Weight and cost totals computed live (never cached). Base/worn/consumable weight classification per item per setup. Category weight breakdown. Item deletion warns about setup membership. Visual indicator when a setup item is no longer in the collection.
-
-**Features from FEATURES.md:** Named setups with item selection and totals, setup weight/cost breakdown by category, automatic totals.
-
-**Pitfalls to prevent:** Setup totals cached in DB (always compute live), setup composition breaks on collection changes (explicit `ON DELETE` behavior, visual indicators for missing items, no silent CASCADE).
-
-**Research flag:** Standard patterns for junction table composition. No research phase needed for the setup-items relationship. The weight classification (base/worn/consumable) per setup entry is worth a design session — this is per-setup metadata on the junction, not a property of the item itself.
-
----
-
-### Phase 4: Dashboard and Polish
-
-**Rationale:** The architecture research explicitly states "Dashboard — aggregates stats from all other entities. Build last since it reads from everything." Dashboard requires all prior phases to be stable since it reads from items, threads, and setups simultaneously. This phase also adds the weight visualization chart that requires a full dataset to be meaningful.
-
-**Delivers:** Dashboard home page with summary cards (item count, active threads, setup count, collection value). Weight distribution visualization (pie/bar chart by category). Dashboard stats endpoint (`/api/stats`) as a read-only aggregation. General UI polish for the "light, airy, minimalist" aesthetic.
-
-**Features from FEATURES.md:** Dashboard home page, weight distribution visualization.
-
-**Research flag:** Standard patterns. Dashboard aggregation is a straightforward read-only endpoint. Charting is well-documented. No research phase needed.
-
----
-
-### Phase 5: v1.x Enhancements
-
-**Rationale:** These features add significant value but depend on the core (Phases 1-3) being proven out. Impact preview requires both stable setups and stable threads. CSV import/export validates the data model is clean (if import is buggy, the model has problems). Photos add storage complexity that is easier to handle once the core CRUD flow is solid.
-
-**Delivers:** Impact preview (how a thread candidate changes a specific setup's weight/cost). Thread item status tracking (researching / ordered / arrived). Priority/ranking within threads. Photos per item (upload, display, cleanup). CSV import/export with unit detection.
-
-**Features from FEATURES.md:** Impact preview, status tracking, priority/ranking, photos per item, CSV import/export.
-
-**Pitfalls to prevent:** CSV import missing unit conversion (must detect and convert oz/lb/kg to grams on import). Image uploads without size/type validation. Product URLs not sanitized (validate http/https protocol, render with `rel="noopener noreferrer"`).
-
-**Research flag:** CSV import with unit detection may need a design pass — handling "5 oz", "142g", "0.3 lb" in the same weight column requires a parsing strategy. Worth a short research spike before implementation.
-
----
+**Rationale:** No schema dependency. Easiest to build last because the comparison view UI (Phase 3) already establishes the thread header area where the setup selector lives. Both add-mode and replace-mode deltas must be designed here to avoid the misleading pure-addition delta.
+**Delivers:** Setup selector dropdown in thread header (`useSetups()` data); `SetupImpactRow.tsx` component; `impactSetupId` in `uiStore`; add-mode delta and replace-mode delta (auto-defaults to replace when same-category item exists in setup); null weight guard ("-- (no weight data)" not "+0g"); unit-aware display via `useWeightUnit()` / `useCurrency()`
+**Uses:** Existing `useSetup(id)` hook (no new API), existing `formatWeight` / `formatPrice` formatters, `categoryId` on thread for replacement item detection
+**Avoids:** Stale data in impact preview (Pitfall 3 — reactive `useQuery` for setup data), wrong delta from add-vs-replace confusion (Pitfall 6), null weight treated as 0 (integration gotcha), server endpoint for delta calculation (architecture anti-pattern)
 
 ### Phase Ordering Rationale
 
-- **Data model first:** Six of nine pitfalls identified are Phase 1 prevention items. The schema is the hardest thing to change later and the most consequential.
-- **Threads before setups:** Thread resolution creates collection items; setup composition consumes them. But more importantly, threads are the differentiating feature — proving the thread workflow works is more valuable than setups.
-- **Dashboard last:** Explicitly recommended by architecture research. Aggregating from incomplete entities produces misleading data and masks bugs.
-- **Impact preview in Phase 5:** This feature requires both stable setups (Phase 3) and stable threads (Phase 2). Building it before both are solid means rebuilding it when either changes.
-- **Photos deferred to Phase 5:** The core value proposition is weight/cost tracking and purchase planning, not a photo gallery. Adding photo infrastructure in Phase 1 increases scope without validating the core concept.
+- Phase 1 before all others: SQLite schema changes batched into a single migration; test helper updated once; pros/cons in edit panel adds value immediately without waiting for the comparison view
+- Phase 2 before Phase 3: rank data (sort order, rank badge) is more valuable displayed in the comparison table than in the card grid alone; building the comparison view after ranking ensures the table is complete on first delivery
+- Phase 3 before Phase 4: comparison view establishes the thread header chrome (toggle button area) where the setup selector in Phase 4 will live; building header UI in Phase 3 reduces Phase 4 scope
+- Phases 3 and 4 are technically independent and could parallelize, but sequencing them keeps the thread detail header changes contained to one phase at a time
 
 ### Research Flags
 
-**Needs design/research before coding:**
-- **Phase 2 (Thread State Machine):** Design the state diagram for thread lifecycle x candidate status before writing any code. Define all valid transitions and invalid states explicitly. This is the most stateful feature in the product and has no off-the-shelf pattern to follow.
-- **Phase 5 (CSV Import):** Design the column-mapping and unit-detection strategy before implementation. The spreadsheet-to-app migration workflow is critical for the target audience (users migrating from gear spreadsheets).
+Phases that need careful plan review before execution (not full research-phase, but plan must address specific design decisions):
+- **Phase 2:** The `tempItems` local state pattern and fractional `sort_order` arithmetic are non-obvious. The PLAN.md must spell these out explicitly before coding. PITFALLS.md Pitfall 1 and Pitfall 2 must be addressed in the plan, not discovered during implementation.
+- **Phase 4:** The add-vs-replace distinction requires deliberate design (which mode is default, how replacement item is detected by category, how null weight is surfaced). PITFALLS.md Pitfall 6 must be resolved in the plan before the component is built.
 
-**Standard patterns — no research phase needed:**
-- **Phase 1 (Data model + CRUD):** Schema design for inventory apps is well-documented. Drizzle + bun:sqlite patterns are covered in official docs.
-- **Phase 3 (Setups):** Junction table composition is a standard relational pattern. Foreign key behavior for integrity is documented.
-- **Phase 4 (Dashboard):** Aggregation endpoints and charting are standard. No novel patterns.
+Phases with standard patterns (can skip `/gsd:research-phase`):
+- **Phase 1:** Standard Drizzle migration + Zod schema extension; established patterns in the codebase; ARCHITECTURE.md provides exact column definitions
+- **Phase 3:** Pure presentational component; Tailwind comparison table is well-documented; ARCHITECTURE.md provides complete component structure, props interface, and delta calculation code
 
 ## Confidence Assessment
 
 | Area | Confidence | Notes |
 |------|------------|-------|
-| Stack | HIGH | All technologies verified against official docs. Version compatibility confirmed. One flag: verify `@hono/zod-validator` supports Zod 4.x before starting. |
-| Features | HIGH | Competitor analysis is thorough (LighterPack, GearGrams, Packstack, Hikt all compared). Feature gaps and differentiators are clearly identified. |
-| Architecture | HIGH | Bun fullstack monolith pattern is official and well-documented. Service layer and data flow patterns are standard. |
-| Pitfalls | HIGH | Pitfalls are domain-specific and well-sourced. SQLite BLOB guidance from official SQLite docs. Comparison UX from NN/g. Unit conversion antipatterns documented. |
+| Stack | HIGH | Verified from `bun.lock` (framer-motion React 19 peerDeps confirmed); dnd-kit abandonment verified via npm + GitHub; Motion Reorder API verified via motion.dev docs |
+| Features | HIGH | Codebase analysis confirmed no rank/pros/cons columns in existing schema; NNGroup + Smashing Magazine for comparison UX patterns; competitor analysis (LighterPack, GearGrams, OutPack) confirmed feature gap |
+| Architecture | HIGH | Full integration map derived from direct codebase analysis; build order confirmed by column dependency graph; all changed files enumerated (3 new, 10 modified); complete code patterns provided |
+| Pitfalls | HIGH | dnd-kit flicker: verified in GitHub Discussion #1522 and Issue #921; fractional indexing: verified via steveruiz.me and fractional-indexing library; comparison UX: Baymard Institute and NNGroup |
 
-**Overall confidence: HIGH**
+**Overall confidence:** HIGH
 
 ### Gaps to Address
 
-- **Zod 4 / @hono/zod-validator compatibility:** STACK.md flags this explicitly. Verify before starting. If incompatible, pin Zod 3.23.x. This is a quick check, not a blocker.
-
-- **Bun fullstack vs. Vite proxy setup:** STACK.md describes the Vite dev server proxy pattern (standard approach), while ARCHITECTURE.md describes Bun's HTML-based routing with `Bun.serve()` (newer approach). These are two valid patterns. The architecture file's approach (Bun fullstack) is simpler for production deployment. Confirm which pattern to follow before project setup — they require different `vite.config.ts` and entry point structures.
-
-- **Weight classification (base/worn/consumable) data model:** Where does this live? On the `setup_items` junction table (per-setup classification, same item can be "base" in one setup and "worn" in another) or on the item itself (one classification for all setups)? The per-setup model is more flexible but more complex. Decide in Phase 1 schema design, not Phase 3 when setups are built.
-
-- **Tag vs. single-category field:** PITFALLS.md recommends a flat tag system. FEATURES.md implies a single "category" field. The right answer is probably a single optional category field (for broad grouping, e.g., "clothing") plus user-defined tags for fine-grained organization. Confirm the data model in Phase 1.
+- **Impact preview add-vs-replace UX:** Research establishes that both modes are needed and when to default to each (same-category item in setup = replace mode). The exact affordance — dropdown to select which item is replaced vs. automatic category matching — is not fully specified. Recommendation: auto-match by category with a "change" link to override. Decide during Phase 4 planning.
+- **Comparison view maximum candidate count:** Research recommends 3-4 max for usability. GearBox has no current limit on candidates per thread. Whether to enforce a hard display limit (hide additional candidates behind "show more") or allow unrestricted horizontal scroll should be decided during Phase 3 planning.
+- **Sort order initialization for existing candidates:** When the migration runs, existing `thread_candidates` rows get `sort_order = 0` (default). Phase 1 plan must specify whether to initialize existing candidates with spaced values (e.g., 1000, 2000, 3000) at migration time or accept that all existing rows start at 0 and rely on first drag to establish order.
 
 ## Sources
 
 ### Primary (HIGH confidence)
-- [Bun official docs](https://bun.com/docs) — bun:sqlite, fullstack dev server, Bun.serve() routing
-- [Hono official docs](https://hono.dev/docs) — Bun integration, middleware patterns
-- [Drizzle ORM docs - Bun SQLite](https://orm.drizzle.team/docs/connect-bun-sqlite) — driver support, schema patterns
-- [Vite releases](https://vite.dev/releases) — v8.0 with Rolldown confirmed
-- [Tailwind CSS v4.2 blog](https://tailwindcss.com/blog/tailwindcss-v4) — CSS-native config, Vite plugin
-- [TanStack Router docs](https://tanstack.com/router/latest) — file-based routing, typed params
-- [TanStack Query docs](https://tanstack.com/query/latest) — cache invalidation, mutations
-- [SQLite Internal vs External BLOBs](https://sqlite.org/intern-v-extern-blob.html) — image storage guidance
-- [Comparison Tables — NN/g](https://www.nngroup.com/articles/comparison-tables/) — comparison UX best practices
+- `bun.lock` (project lockfile) — framer-motion v12.37.0 peerDeps `"react: ^18.0.0 || ^19.0.0"` confirmed
+- [Motion Reorder docs](https://motion.dev/docs/react-reorder) — `Reorder.Group`, `Reorder.Item`, `onDragEnd` API
+- [dnd-kit Discussion #1522](https://github.com/clauderic/dnd-kit/discussions/1522) — `tempItems` solution for React Query cache flicker
+- [dnd-kit Issue #921](https://github.com/clauderic/dnd-kit/issues/921) — root cause of state lifecycle mismatch
+- [Fractional Indexing — steveruiz.me](https://www.steveruiz.me/posts/reordering-fractional-indices) — why float sort keys beat integer reorder for databases
+- [Baymard Institute: Comparison Tool Design](https://baymard.com/blog/user-friendly-comparison-tools) — sticky headers, horizontal scroll, minimum column width
+- [NNGroup: Comparison Tables](https://www.nngroup.com/articles/comparison-tables/) — information architecture, anti-patterns
+- [Smashing Magazine: Feature Comparison Table](https://www.smashingmagazine.com/2017/08/designing-perfect-feature-comparison-table/) — table layout patterns
+- GearBox codebase direct analysis (`src/db/schema.ts`, `src/server/services/`, `src/client/hooks/`, `tests/helpers/db.ts`) — confirmed existing patterns, missing columns, integration points
 
 ### Secondary (MEDIUM confidence)
-- [Hikt Blog: Best Backpacking Gear Apps 2026](https://hikt.app/blog/best-backpacking-gear-apps-2026/) — competitor feature analysis
-- [Building Full-Stack App with Bun.js, React and Drizzle ORM](https://awplife.com/building-full-stack-app-with-bun-js-react-drizzle/) — project structure reference
-- [Designing better file organization around tags, not hierarchies](https://www.nayuki.io/page/designing-better-file-organization-around-tags-not-hierarchies) — tags vs hierarchy rationale
+- [@dnd-kit/core npm](https://www.npmjs.com/package/@dnd-kit/core) — v6.3.1 last published ~1 year ago, no React 19
+- [dnd-kit React 19 issue #1511](https://github.com/clauderic/dnd-kit/issues/1511) — CLOSED but React 19 TypeScript issues confirmed
+- [@dnd-kit/react roadmap discussion #1842](https://github.com/clauderic/dnd-kit/discussions/1842) — 0 maintainer replies; pre-1.0 risk signal
+- [hello-pangea/dnd React 19 issue #864](https://github.com/hello-pangea/dnd/issues/864) — still open as of Jan 2026
+- [BrightCoding dnd-kit deep dive (2025)](https://www.blog.brightcoding.dev/2025/08/21/the-ultimate-drag-and-drop-toolkit-for-react-a-deep-dive-into-dnd-kit/) — react-beautiful-dnd abandoned; dnd-kit current standard but React 19 gap confirmed
+- [TrailsMag: Leaving LighterPack](https://trailsmag.net/blogs/hiker-box/ultralight-the-gear-tracking-app-i-m-leaving-lighterpack-for) — LighterPack feature gap analysis
+- [Contentsquare: Comparing products UX](https://contentsquare.com/blog/comparing-products-design-practices-to-help-your-users-avoid-fragmented-comparison-7/) — fragmented comparison pitfalls
 
-### Tertiary (LOW confidence / needs validation)
-- [Zod v4 release notes](https://zod.dev/v4) — @hono/zod-validator compatibility with Zod 4 unconfirmed, verify before use
+### Tertiary (LOW confidence)
+- [Fractional Indexing SQLite library](https://github.com/sqliteai/fractional-indexing) — implementation reference for lexicographic sort keys (pattern reference only; direct float arithmetic sufficient for this use case)
+- [Top 5 Drag-and-Drop Libraries for React 2026](https://puckeditor.com/blog/top-5-drag-and-drop-libraries-for-react) — ecosystem overview confirming dnd-kit and hello-pangea/dnd limitations
 
 ---
-*Research completed: 2026-03-14*
+*Research completed: 2026-03-16*
 *Ready for roadmap: yes*

README.md

@@ -1,2 +1,83 @@
 # GearBox
 
+A single-user web app for managing gear collections (bikepacking, sim racing, etc.), tracking weight and price, and planning purchases through research threads.
+
+## Features
+
+- Organize gear into categories with custom icons
+- Track weight and price for every item
+- Create setups (packing lists) from your collection with automatic weight/cost totals
+- Research threads for comparing candidates before buying
+- Image uploads for items and candidates
+
+## Quick Start
+
+### Docker Compose (recommended)
+
+Create a `docker-compose.yml`:
+
+```yaml
+services:
+  gearbox:
+    image: gitea.jeanlucmakiola.de/makiolaj/gearbox:latest
+    container_name: gearbox
+    ports:
+      - "3000:3000"
+    environment:
+      - NODE_ENV=production
+      - DATABASE_PATH=./data/gearbox.db
+    volumes:
+      - gearbox-data:/app/data
+      - gearbox-uploads:/app/uploads
+    healthcheck:
+      test: ["CMD", "bun", "-e", "fetch('http://localhost:3000/api/health').then(r=>r.ok?process.exit(0):process.exit(1)).catch(()=>process.exit(1))"]
+      interval: 30s
+      timeout: 5s
+      start_period: 10s
+      retries: 3
+    restart: unless-stopped
+
+volumes:
+  gearbox-data:
+  gearbox-uploads:
+```
+
+Then run:
+
+```bash
+docker compose up -d
+```
+
+GearBox will be available at `http://localhost:3000`.
+
+### Docker
+
+```bash
+docker run -d \
+  --name gearbox \
+  -p 3000:3000 \
+  -e NODE_ENV=production \
+  -e DATABASE_PATH=./data/gearbox.db \
+  -v gearbox-data:/app/data \
+  -v gearbox-uploads:/app/uploads \
+  --restart unless-stopped \
+  gitea.jeanlucmakiola.de/makiolaj/gearbox:latest
+```
+
+## Data
+
+All data is stored in two Docker volumes:
+
+- **gearbox-data** -- SQLite database
+- **gearbox-uploads** -- uploaded images
+
+Back up these volumes to preserve your data.
+
+## Updating
+
+```bash
+docker compose pull
+docker compose up -d
+```
+
+Database migrations run automatically on startup.

bun.lock

@@ -15,6 +15,7 @@
         "lucide-react": "^0.577.0",
         "react": "^19.2.4",
         "react-dom": "^19.2.4",
+        "recharts": "^3.8.0",
         "tailwindcss": "^4.2.1",
         "zod": "^4.3.6",
         "zustand": "^5.0.11",
@@ -177,6 +178,8 @@
 
     "@oxc-project/types": ["@oxc-project/types@0.115.0", "", {}, "sha512-4n91DKnebUS4yjUHl2g3/b2T+IUdCfmoZGhmwsovZCDaJSs+QkVAM+0AqqTxHSsHfeiMuueT75cZaZcT/m0pSw=="],
 
+    "@reduxjs/toolkit": ["@reduxjs/toolkit@2.11.2", "", { "dependencies": { "@standard-schema/spec": "^1.0.0", "@standard-schema/utils": "^0.3.0", "immer": "^11.0.0", "redux": "^5.0.1", "redux-thunk": "^3.1.0", "reselect": "^5.1.0" }, "peerDependencies": { "react": "^16.9.0 || ^17.0.0 || ^18 || ^19", "react-redux": "^7.2.1 || ^8.1.3 || ^9.0.0" }, "optionalPeers": ["react", "react-redux"] }, "sha512-Kd6kAHTA6/nUpp8mySPqj3en3dm0tdMIgbttnQ1xFMVpufoj+ADi8pXLBsd4xzTRHQa7t/Jv8W5UnCuW4kuWMQ=="],
+
     "@rolldown/binding-android-arm64": ["@rolldown/binding-android-arm64@1.0.0-rc.9", "", { "os": "android", "cpu": "arm64" }, "sha512-lcJL0bN5hpgJfSIz/8PIf02irmyL43P+j1pTCfbD1DbLkmGRuFIA4DD3B3ZOvGqG0XiVvRznbKtN0COQVaKUTg=="],
 
     "@rolldown/binding-darwin-arm64": ["@rolldown/binding-darwin-arm64@1.0.0-rc.9", "", { "os": "darwin", "cpu": "arm64" }, "sha512-J7Zk3kLYFsLtuH6U+F4pS2sYVzac0qkjcO5QxHS7OS7yZu2LRs+IXo+uvJ/mvpyUljDJ3LROZPoQfgBIpCMhdQ=="],
@@ -209,6 +212,10 @@
 
     "@rolldown/pluginutils": ["@rolldown/pluginutils@1.0.0-rc.7", "", {}, "sha512-qujRfC8sFVInYSPPMLQByRh7zhwkGFS4+tyMQ83srV1qrxL4g8E2tyxVVyxd0+8QeBM1mIk9KbWxkegRr76XzA=="],
 
+    "@standard-schema/spec": ["@standard-schema/spec@1.1.0", "", {}, "sha512-l2aFy5jALhniG5HgqrD6jXLi/rUWrKvqN/qJx6yoJsgKhblVd+iqqU4RCXavm/jPityDo5TCvKMnpjKnOriy0w=="],
+
+    "@standard-schema/utils": ["@standard-schema/utils@0.3.0", "", {}, "sha512-e7Mew686owMaPJVNNLs55PUvgz371nKgwsc4vxE49zsODpJEnxgxRo2y/OKrqueavXgZNMDVj3DdHFlaSAeU8g=="],
+
     "@tailwindcss/node": ["@tailwindcss/node@4.2.1", "", { "dependencies": { "@jridgewell/remapping": "^2.3.5", "enhanced-resolve": "^5.19.0", "jiti": "^2.6.1", "lightningcss": "1.31.1", "magic-string": "^0.30.21", "source-map-js": "^1.2.1", "tailwindcss": "4.2.1" } }, "sha512-jlx6sLk4EOwO6hHe1oCGm1Q4AN/s0rSrTTPBGPM0/RQ6Uylwq17FuU8IeJJKEjtc6K6O07zsvP+gDO6MMWo7pg=="],
 
     "@tailwindcss/oxide": ["@tailwindcss/oxide@4.2.1", "", { "optionalDependencies": { "@tailwindcss/oxide-android-arm64": "4.2.1", "@tailwindcss/oxide-darwin-arm64": "4.2.1", "@tailwindcss/oxide-darwin-x64": "4.2.1", "@tailwindcss/oxide-freebsd-x64": "4.2.1", "@tailwindcss/oxide-linux-arm-gnueabihf": "4.2.1", "@tailwindcss/oxide-linux-arm64-gnu": "4.2.1", "@tailwindcss/oxide-linux-arm64-musl": "4.2.1", "@tailwindcss/oxide-linux-x64-gnu": "4.2.1", "@tailwindcss/oxide-linux-x64-musl": "4.2.1", "@tailwindcss/oxide-wasm32-wasi": "4.2.1", "@tailwindcss/oxide-win32-arm64-msvc": "4.2.1", "@tailwindcss/oxide-win32-x64-msvc": "4.2.1" } }, "sha512-yv9jeEFWnjKCI6/T3Oq50yQEOqmpmpfzG1hcZsAOaXFQPfzWprWrlHSdGPEF3WQTi8zu8ohC9Mh9J470nT5pUw=="],
@@ -275,12 +282,32 @@
 
     "@types/bun": ["@types/bun@1.3.10", "", { "dependencies": { "bun-types": "1.3.10" } }, "sha512-0+rlrUrOrTSskibryHbvQkDOWRJwJZqZlxrUs1u4oOoTln8+WIXBPmAuCF35SWB2z4Zl3E84Nl/D0P7803nigQ=="],
 
+    "@types/d3-array": ["@types/d3-array@3.2.2", "", {}, "sha512-hOLWVbm7uRza0BYXpIIW5pxfrKe0W+D5lrFiAEYR+pb6w3N2SwSMaJbXdUfSEv+dT4MfHBLtn5js0LAWaO6otw=="],
+
+    "@types/d3-color": ["@types/d3-color@3.1.3", "", {}, "sha512-iO90scth9WAbmgv7ogoq57O9YpKmFBbmoEoCHDB2xMBY0+/KVrqAaCDyCE16dUspeOvIxFFRI+0sEtqDqy2b4A=="],
+
+    "@types/d3-ease": ["@types/d3-ease@3.0.2", "", {}, "sha512-NcV1JjO5oDzoK26oMzbILE6HW7uVXOHLQvHshBUW4UMdZGfiY6v5BeQwh9a9tCzv+CeefZQHJt5SRgK154RtiA=="],
+
+    "@types/d3-interpolate": ["@types/d3-interpolate@3.0.4", "", { "dependencies": { "@types/d3-color": "*" } }, "sha512-mgLPETlrpVV1YRJIglr4Ez47g7Yxjl1lj7YKsiMCb27VJH9W8NVM6Bb9d8kkpG/uAQS5AmbA48q2IAolKKo1MA=="],
+
+    "@types/d3-path": ["@types/d3-path@3.1.1", "", {}, "sha512-VMZBYyQvbGmWyWVea0EHs/BwLgxc+MKi1zLDCONksozI4YJMcTt8ZEuIR4Sb1MMTE8MMW49v0IwI5+b7RmfWlg=="],
+
+    "@types/d3-scale": ["@types/d3-scale@4.0.9", "", { "dependencies": { "@types/d3-time": "*" } }, "sha512-dLmtwB8zkAeO/juAMfnV+sItKjlsw2lKdZVVy6LRr0cBmegxSABiLEpGVmSJJ8O08i4+sGR6qQtb6WtuwJdvVw=="],
+
+    "@types/d3-shape": ["@types/d3-shape@3.1.8", "", { "dependencies": { "@types/d3-path": "*" } }, "sha512-lae0iWfcDeR7qt7rA88BNiqdvPS5pFVPpo5OfjElwNaT2yyekbM0C9vK+yqBqEmHr6lDkRnYNoTBYlAgJa7a4w=="],
+
+    "@types/d3-time": ["@types/d3-time@3.0.4", "", {}, "sha512-yuzZug1nkAAaBlBBikKZTgzCeA+k1uy4ZFwWANOfKw5z5LRhV0gNA7gNkKm7HoK+HRN0wX3EkxGk0fpbWhmB7g=="],
+
+    "@types/d3-timer": ["@types/d3-timer@3.0.2", "", {}, "sha512-Ps3T8E8dZDam6fUyNiMkekK3XUsaUEik+idO9/YjPtfj2qruF8tFBXS7XhtE4iIXBLxhmLjP3SXpLhVf21I9Lw=="],
+
     "@types/node": ["@types/node@25.5.0", "", { "dependencies": { "undici-types": "~7.18.0" } }, "sha512-jp2P3tQMSxWugkCUKLRPVUpGaL5MVFwF8RDuSRztfwgN1wmqJeMSbKlnEtQqU8UrhTmzEmZdu2I6v2dpp7XIxw=="],
 
     "@types/react": ["@types/react@19.2.14", "", { "dependencies": { "csstype": "^3.2.2" } }, "sha512-ilcTH/UniCkMdtexkoCN0bI7pMcJDvmQFPvuPvmEaYA/NSfFTAgdUSLAoVjaRJm7+6PvcM+q1zYOwS4wTYMF9w=="],
 
     "@types/react-dom": ["@types/react-dom@19.2.3", "", { "peerDependencies": { "@types/react": "^19.2.0" } }, "sha512-jp2L/eY6fn+KgVVQAOqYItbF0VY/YApe5Mz2F0aykSO8gx31bYCZyvSeYxCHKvzHG5eZjc+zyaS5BrBWya2+kQ=="],
 
+    "@types/use-sync-external-store": ["@types/use-sync-external-store@0.0.6", "", {}, "sha512-zFDAD+tlpf2r4asuHEj0XH6pY6i0g5NeAHPn+15wk3BV6JA69eERFXC1gyGThDkVa1zCyKr5jox1+2LbV/AMLg=="],
+
     "@vitejs/plugin-react": ["@vitejs/plugin-react@6.0.1", "", { "dependencies": { "@rolldown/pluginutils": "1.0.0-rc.7" }, "peerDependencies": { "@rolldown/plugin-babel": "^0.1.7 || ^0.2.0", "babel-plugin-react-compiler": "^1.0.0", "vite": "^8.0.0" }, "optionalPeers": ["@rolldown/plugin-babel", "babel-plugin-react-compiler"] }, "sha512-l9X/E3cDb+xY3SWzlG1MOGt2usfEHGMNIaegaUGFsLkb3RCn/k8/TOXBcab+OndDI4TBtktT8/9BwwW8Vi9KUQ=="],
 
     "acorn": ["acorn@8.16.0", "", { "bin": { "acorn": "bin/acorn" } }, "sha512-UVJyE9MttOsBQIDKw1skb9nAwQuR5wuGD3+82K6JgJlm/Y+KI92oNsMNGZCYdDsVtRHSak0pcV5Dno5+4jh9sw=="],
@@ -329,8 +356,32 @@
 
     "csstype": ["csstype@3.2.3", "", {}, "sha512-z1HGKcYy2xA8AGQfwrn0PAy+PB7X/GSj3UVJW9qKyn43xWa+gl5nXmU4qqLMRzWVLFC8KusUX8T/0kCiOYpAIQ=="],
 
+    "d3-array": ["d3-array@3.2.4", "", { "dependencies": { "internmap": "1 - 2" } }, "sha512-tdQAmyA18i4J7wprpYq8ClcxZy3SC31QMeByyCFyRt7BVHdREQZ5lpzoe5mFEYZUWe+oq8HBvk9JjpibyEV4Jg=="],
+
+    "d3-color": ["d3-color@3.1.0", "", {}, "sha512-zg/chbXyeBtMQ1LbD/WSoW2DpC3I0mpmPdW+ynRTj/x2DAWYrIY7qeZIHidozwV24m4iavr15lNwIwLxRmOxhA=="],
+
+    "d3-ease": ["d3-ease@3.0.1", "", {}, "sha512-wR/XK3D3XcLIZwpbvQwQ5fK+8Ykds1ip7A2Txe0yxncXSdq1L9skcG7blcedkOX+ZcgxGAmLX1FrRGbADwzi0w=="],
+
+    "d3-format": ["d3-format@3.1.2", "", {}, "sha512-AJDdYOdnyRDV5b6ArilzCPPwc1ejkHcoyFarqlPqT7zRYjhavcT3uSrqcMvsgh2CgoPbK3RCwyHaVyxYcP2Arg=="],
+
+    "d3-interpolate": ["d3-interpolate@3.0.1", "", { "dependencies": { "d3-color": "1 - 3" } }, "sha512-3bYs1rOD33uo8aqJfKP3JWPAibgw8Zm2+L9vBKEHJ2Rg+viTR7o5Mmv5mZcieN+FRYaAOWX5SJATX6k1PWz72g=="],
+
+    "d3-path": ["d3-path@3.1.0", "", {}, "sha512-p3KP5HCf/bvjBSSKuXid6Zqijx7wIfNW+J/maPs+iwR35at5JCbLUT0LzF1cnjbCHWhqzQTIN2Jpe8pRebIEFQ=="],
+
+    "d3-scale": ["d3-scale@4.0.2", "", { "dependencies": { "d3-array": "2.10.0 - 3", "d3-format": "1 - 3", "d3-interpolate": "1.2.0 - 3", "d3-time": "2.1.1 - 3", "d3-time-format": "2 - 4" } }, "sha512-GZW464g1SH7ag3Y7hXjf8RoUuAFIqklOAq3MRl4OaWabTFJY9PN/E1YklhXLh+OQ3fM9yS2nOkCoS+WLZ6kvxQ=="],
+
+    "d3-shape": ["d3-shape@3.2.0", "", { "dependencies": { "d3-path": "^3.1.0" } }, "sha512-SaLBuwGm3MOViRq2ABk3eLoxwZELpH6zhl3FbAoJ7Vm1gofKx6El1Ib5z23NUEhF9AsGl7y+dzLe5Cw2AArGTA=="],
+
+    "d3-time": ["d3-time@3.1.0", "", { "dependencies": { "d3-array": "2 - 3" } }, "sha512-VqKjzBLejbSMT4IgbmVgDjpkYrNWUYJnbCGo874u7MMKIWsILRX+OpX/gTk8MqjpT1A/c6HY2dCA77ZN0lkQ2Q=="],
+
+    "d3-time-format": ["d3-time-format@4.1.0", "", { "dependencies": { "d3-time": "1 - 3" } }, "sha512-dJxPBlzC7NugB2PDLwo9Q8JiTR3M3e4/XANkreKSUxF8vvXKqm1Yfq4Q5dl8budlunRVlUUaDUgFt7eA8D6NLg=="],
+
+    "d3-timer": ["d3-timer@3.0.1", "", {}, "sha512-ndfJ/JxxMd3nw31uyKoY2naivF+r29V+Lc0svZxe1JvvIRmi8hUsrMvdOwgS1o6uBHmiz91geQ0ylPP0aj1VUA=="],
+
     "debug": ["debug@4.4.3", "", { "dependencies": { "ms": "^2.1.3" } }, "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA=="],
 
+    "decimal.js-light": ["decimal.js-light@2.5.1", "", {}, "sha512-qIMFpTMZmny+MMIitAB6D7iVPEorVw6YQRWkvarTkT4tBeSLLiHzcwj6q0MmYSFCiVpiqPJTJEYIrpcPzVEIvg=="],
+
     "decompress-response": ["decompress-response@6.0.0", "", { "dependencies": { "mimic-response": "^3.1.0" } }, "sha512-aW35yZM6Bb/4oJlZncMH2LCoZtJXTRxES17vE3hoRiowU2kWHaJKFkSBDnDR+cm9J+9QhXmREyIfv0pji9ejCQ=="],
 
     "deep-extend": ["deep-extend@0.6.0", "", {}, "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA=="],
@@ -349,6 +400,8 @@
 
     "enhanced-resolve": ["enhanced-resolve@5.20.0", "", { "dependencies": { "graceful-fs": "^4.2.4", "tapable": "^2.3.0" } }, "sha512-/ce7+jQ1PQ6rVXwe+jKEg5hW5ciicHwIQUagZkp6IufBoY3YDgdTTY1azVs0qoRgVmvsNB+rbjLJxDAeHHtwsQ=="],
 
+    "es-toolkit": ["es-toolkit@1.45.1", "", {}, "sha512-/jhoOj/Fx+A+IIyDNOvO3TItGmlMKhtX8ISAHKE90c4b/k1tqaqEZ+uUqfpU8DMnW5cgNJv606zS55jGvza0Xw=="],
+
     "esbuild": ["esbuild@0.25.12", "", { "optionalDependencies": { "@esbuild/aix-ppc64": "0.25.12", "@esbuild/android-arm": "0.25.12", "@esbuild/android-arm64": "0.25.12", "@esbuild/android-x64": "0.25.12", "@esbuild/darwin-arm64": "0.25.12", "@esbuild/darwin-x64": "0.25.12", "@esbuild/freebsd-arm64": "0.25.12", "@esbuild/freebsd-x64": "0.25.12", "@esbuild/linux-arm": "0.25.12", "@esbuild/linux-arm64": "0.25.12", "@esbuild/linux-ia32": "0.25.12", "@esbuild/linux-loong64": "0.25.12", "@esbuild/linux-mips64el": "0.25.12", "@esbuild/linux-ppc64": "0.25.12", "@esbuild/linux-riscv64": "0.25.12", "@esbuild/linux-s390x": "0.25.12", "@esbuild/linux-x64": "0.25.12", "@esbuild/netbsd-arm64": "0.25.12", "@esbuild/netbsd-x64": "0.25.12", "@esbuild/openbsd-arm64": "0.25.12", "@esbuild/openbsd-x64": "0.25.12", "@esbuild/openharmony-arm64": "0.25.12", "@esbuild/sunos-x64": "0.25.12", "@esbuild/win32-arm64": "0.25.12", "@esbuild/win32-ia32": "0.25.12", "@esbuild/win32-x64": "0.25.12" }, "bin": { "esbuild": "bin/esbuild" } }, "sha512-bbPBYYrtZbkt6Os6FiTLCTFxvq4tt3JKall1vRwshA3fdVztsLAatFaZobhkBC8/BrPetoa0oksYoKXoG4ryJg=="],
 
     "esbuild-register": ["esbuild-register@3.6.0", "", { "dependencies": { "debug": "^4.3.4" }, "peerDependencies": { "esbuild": ">=0.12 <1" } }, "sha512-H2/S7Pm8a9CL1uhp9OvjwrBh5Pvx0H8qVOxNu8Wed9Y7qv56MPtq+GGM8RJpq6glYJn9Wspr8uw7l55uyinNeg=="],
@@ -357,6 +410,8 @@
 
     "esprima": ["esprima@4.0.1", "", { "bin": { "esparse": "./bin/esparse.js", "esvalidate": "./bin/esvalidate.js" } }, "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A=="],
 
+    "eventemitter3": ["eventemitter3@5.0.4", "", {}, "sha512-mlsTRyGaPBjPedk6Bvw+aqbsXDtoAyAzm5MO7JgU+yVRyMQ5O8bD4Kcci7BS85f93veegeCPkL8R4GLClnjLFw=="],
+
     "expand-template": ["expand-template@2.0.3", "", {}, "sha512-XYfuKMvj4O35f/pOXLObndIRvyQ+/+6AhODh+OKWj9S9498pHHn/IMszH+gt0fBCRWMNfk1ZSp5x3AifmnI2vg=="],
 
     "fdir": ["fdir@6.5.0", "", { "peerDependencies": { "picomatch": "^3 || ^4" }, "optionalPeers": ["picomatch"] }, "sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg=="],
@@ -385,10 +440,14 @@
 
     "ieee754": ["ieee754@1.2.1", "", {}, "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA=="],
 
+    "immer": ["immer@10.2.0", "", {}, "sha512-d/+XTN3zfODyjr89gM3mPq1WNX2B8pYsu7eORitdwyA2sBubnTl3laYlBk4sXY5FUa5qTZGBDPJICVbvqzjlbw=="],
+
     "inherits": ["inherits@2.0.4", "", {}, "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ=="],
 
     "ini": ["ini@1.3.8", "", {}, "sha512-JV/yugV2uzW5iMRSiZAyDtQd+nxtUnjeLt0acNdw98kKLrvuRVyB80tsREOE7yvGVgalhZ6RNXCmEHkUKBKxew=="],
 
+    "internmap": ["internmap@2.0.3", "", {}, "sha512-5Hh7Y1wQbvY5ooGgPbDaL5iYLAPzMTUrjMulskHLH6wnv/A+1q5rgEaiuqEjB+oxGXIVZs1FF+R/KPN3ZSQYYg=="],
+
     "is-binary-path": ["is-binary-path@2.1.0", "", { "dependencies": { "binary-extensions": "^2.0.0" } }, "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw=="],
 
     "is-extglob": ["is-extglob@2.1.1", "", {}, "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ=="],
@@ -477,12 +536,24 @@
 
     "react-dom": ["react-dom@19.2.4", "", { "dependencies": { "scheduler": "^0.27.0" }, "peerDependencies": { "react": "^19.2.4" } }, "sha512-AXJdLo8kgMbimY95O2aKQqsz2iWi9jMgKJhRBAxECE4IFxfcazB2LmzloIoibJI3C12IlY20+KFaLv+71bUJeQ=="],
 
+    "react-is": ["react-is@19.2.4", "", {}, "sha512-W+EWGn2v0ApPKgKKCy/7s7WHXkboGcsrXE+2joLyVxkbyVQfO3MUEaUQDHoSmb8TFFrSKYa9mw64WZHNHSDzYA=="],
+
+    "react-redux": ["react-redux@9.2.0", "", { "dependencies": { "@types/use-sync-external-store": "^0.0.6", "use-sync-external-store": "^1.4.0" }, "peerDependencies": { "@types/react": "^18.2.25 || ^19", "react": "^18.0 || ^19", "redux": "^5.0.0" }, "optionalPeers": ["@types/react", "redux"] }, "sha512-ROY9fvHhwOD9ySfrF0wmvu//bKCQ6AeZZq1nJNtbDC+kk5DuSuNX/n6YWYF/SYy7bSba4D4FSz8DJeKY/S/r+g=="],
+
     "readable-stream": ["readable-stream@3.6.2", "", { "dependencies": { "inherits": "^2.0.3", "string_decoder": "^1.1.1", "util-deprecate": "^1.0.1" } }, "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA=="],
 
     "readdirp": ["readdirp@3.6.0", "", { "dependencies": { "picomatch": "^2.2.1" } }, "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA=="],
 
     "recast": ["recast@0.23.11", "", { "dependencies": { "ast-types": "^0.16.1", "esprima": "~4.0.0", "source-map": "~0.6.1", "tiny-invariant": "^1.3.3", "tslib": "^2.0.1" } }, "sha512-YTUo+Flmw4ZXiWfQKGcwwc11KnoRAYgzAE2E7mXKCjSviTKShtxBsN6YUUBB2gtaBzKzeKunxhUwNHQuRryhWA=="],
 
+    "recharts": ["recharts@3.8.0", "", { "dependencies": { "@reduxjs/toolkit": "^1.9.0 || 2.x.x", "clsx": "^2.1.1", "decimal.js-light": "^2.5.1", "es-toolkit": "^1.39.3", "eventemitter3": "^5.0.1", "immer": "^10.1.1", "react-redux": "8.x.x || 9.x.x", "reselect": "5.1.1", "tiny-invariant": "^1.3.3", "use-sync-external-store": "^1.2.2", "victory-vendor": "^37.0.2" }, "peerDependencies": { "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react-dom": "^16.0.0 || ^17.0.0 || ^18.0.0 || ^19.0.0", "react-is": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0" } }, "sha512-Z/m38DX3L73ExO4Tpc9/iZWHmHnlzWG4njQbxsF5aSjwqmHNDDIm0rdEBArkwsBvR8U6EirlEHiQNYWCVh9sGQ=="],
+
+    "redux": ["redux@5.0.1", "", {}, "sha512-M9/ELqF6fy8FwmkpnF0S3YKOqMyoWJ4+CS5Efg2ct3oY9daQvd/Pc71FpGZsVsbl3Cpb+IIcjBDUnnyBdQbq4w=="],
+
+    "redux-thunk": ["redux-thunk@3.1.0", "", { "peerDependencies": { "redux": "^5.0.0" } }, "sha512-NW2r5T6ksUKXCabzhL9z+h206HQw/NJkcLm1GPImRQ8IzfXwRGqjVhKJGauHirT0DAuyy6hjdnMZaRoAcy0Klw=="],
+
+    "reselect": ["reselect@5.1.1", "", {}, "sha512-K/BG6eIky/SBpzfHZv/dd+9JBFiS4SWV7FIujVyJRux6e45+73RaUHXLmIR1f7WOMaQ0U1km6qwklRQxpJJY0w=="],
+
     "resolve-pkg-maps": ["resolve-pkg-maps@1.0.0", "", {}, "sha512-seS2Tj26TBVOC2NIc2rOe2y2ZO7efxITtLZcGSOnHHNOQ7CkiUBfw0Iw2ck6xkIhPwLhKNLS8BO+hEpngQlqzw=="],
 
     "rolldown": ["rolldown@1.0.0-rc.9", "", { "dependencies": { "@oxc-project/types": "=0.115.0", "@rolldown/pluginutils": "1.0.0-rc.9" }, "optionalDependencies": { "@rolldown/binding-android-arm64": "1.0.0-rc.9", "@rolldown/binding-darwin-arm64": "1.0.0-rc.9", "@rolldown/binding-darwin-x64": "1.0.0-rc.9", "@rolldown/binding-freebsd-x64": "1.0.0-rc.9", "@rolldown/binding-linux-arm-gnueabihf": "1.0.0-rc.9", "@rolldown/binding-linux-arm64-gnu": "1.0.0-rc.9", "@rolldown/binding-linux-arm64-musl": "1.0.0-rc.9", "@rolldown/binding-linux-ppc64-gnu": "1.0.0-rc.9", "@rolldown/binding-linux-s390x-gnu": "1.0.0-rc.9", "@rolldown/binding-linux-x64-gnu": "1.0.0-rc.9", "@rolldown/binding-linux-x64-musl": "1.0.0-rc.9", "@rolldown/binding-openharmony-arm64": "1.0.0-rc.9", "@rolldown/binding-wasm32-wasi": "1.0.0-rc.9", "@rolldown/binding-win32-arm64-msvc": "1.0.0-rc.9", "@rolldown/binding-win32-x64-msvc": "1.0.0-rc.9" }, "bin": { "rolldown": "bin/cli.mjs" } }, "sha512-9EbgWge7ZH+yqb4d2EnELAntgPTWbfL8ajiTW+SyhJEC4qhBbkCKbqFV4Ge4zmu5ziQuVbWxb/XwLZ+RIO7E8Q=="],
@@ -545,6 +616,8 @@
 
     "util-deprecate": ["util-deprecate@1.0.2", "", {}, "sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw=="],
 
+    "victory-vendor": ["victory-vendor@37.3.6", "", { "dependencies": { "@types/d3-array": "^3.0.3", "@types/d3-ease": "^3.0.0", "@types/d3-interpolate": "^3.0.1", "@types/d3-scale": "^4.0.2", "@types/d3-shape": "^3.1.0", "@types/d3-time": "^3.0.0", "@types/d3-timer": "^3.0.0", "d3-array": "^3.1.6", "d3-ease": "^3.0.1", "d3-interpolate": "^3.0.1", "d3-scale": "^4.0.2", "d3-shape": "^3.1.0", "d3-time": "^3.0.0", "d3-timer": "^3.0.1" } }, "sha512-SbPDPdDBYp+5MJHhBCAyI7wKM3d5ivekigc2Dk2s7pgbZ9wIgIBYGVw4zGHBml/qTFbexrofXW6Gu4noGxrOwQ=="],
+
     "vite": ["vite@8.0.0", "", { "dependencies": { "@oxc-project/runtime": "0.115.0", "lightningcss": "^1.32.0", "picomatch": "^4.0.3", "postcss": "^8.5.8", "rolldown": "1.0.0-rc.9", "tinyglobby": "^0.2.15" }, "optionalDependencies": { "fsevents": "~2.3.3" }, "peerDependencies": { "@types/node": "^20.19.0 || >=22.12.0", "@vitejs/devtools": "^0.0.0-alpha.31", "esbuild": "^0.27.0", "jiti": ">=1.21.0", "less": "^4.0.0", "sass": "^1.70.0", "sass-embedded": "^1.70.0", "stylus": ">=0.54.8", "sugarss": "^5.0.0", "terser": "^5.16.0", "tsx": "^4.8.1", "yaml": "^2.4.2" }, "optionalPeers": ["@types/node", "@vitejs/devtools", "esbuild", "jiti", "less", "sass", "sass-embedded", "stylus", "sugarss", "terser", "tsx", "yaml"], "bin": { "vite": "bin/vite.js" } }, "sha512-fPGaRNj9Zytaf8LEiBhY7Z6ijnFKdzU/+mL8EFBaKr7Vw1/FWcTBAMW0wLPJAGMPX38ZPVCVgLceWiEqeoqL2Q=="],
 
     "webpack-virtual-modules": ["webpack-virtual-modules@0.6.2", "", {}, "sha512-66/V2i5hQanC51vBQKPH4aI8NMAcBW59FVBs+rC7eGHupMyfn34q7rZIE+ETlJ+XTevqfUhVVBgSUNSW2flEUQ=="],
@@ -559,6 +632,8 @@
 
     "@esbuild-kit/core-utils/esbuild": ["esbuild@0.18.20", "", { "optionalDependencies": { "@esbuild/android-arm": "0.18.20", "@esbuild/android-arm64": "0.18.20", "@esbuild/android-x64": "0.18.20", "@esbuild/darwin-arm64": "0.18.20", "@esbuild/darwin-x64": "0.18.20", "@esbuild/freebsd-arm64": "0.18.20", "@esbuild/freebsd-x64": "0.18.20", "@esbuild/linux-arm": "0.18.20", "@esbuild/linux-arm64": "0.18.20", "@esbuild/linux-ia32": "0.18.20", "@esbuild/linux-loong64": "0.18.20", "@esbuild/linux-mips64el": "0.18.20", "@esbuild/linux-ppc64": "0.18.20", "@esbuild/linux-riscv64": "0.18.20", "@esbuild/linux-s390x": "0.18.20", "@esbuild/linux-x64": "0.18.20", "@esbuild/netbsd-x64": "0.18.20", "@esbuild/openbsd-x64": "0.18.20", "@esbuild/sunos-x64": "0.18.20", "@esbuild/win32-arm64": "0.18.20", "@esbuild/win32-ia32": "0.18.20", "@esbuild/win32-x64": "0.18.20" }, "bin": { "esbuild": "bin/esbuild" } }, "sha512-ceqxoedUrcayh7Y7ZX6NdbbDzGROiyVBgC4PriJThBKSVPWnnFHZAkfI1lJT8QFkOwH4qOS2SJkS4wvpGl8BpA=="],
 
+    "@reduxjs/toolkit/immer": ["immer@11.1.4", "", {}, "sha512-XREFCPo6ksxVzP4E0ekD5aMdf8WMwmdNaz6vuvxgI40UaEiu6q3p8X52aU6GdyvLY3XXX/8R7JOTXStz/nBbRw=="],
+
     "@tailwindcss/node/lightningcss": ["lightningcss@1.31.1", "", { "dependencies": { "detect-libc": "^2.0.3" }, "optionalDependencies": { "lightningcss-android-arm64": "1.31.1", "lightningcss-darwin-arm64": "1.31.1", "lightningcss-darwin-x64": "1.31.1", "lightningcss-freebsd-x64": "1.31.1", "lightningcss-linux-arm-gnueabihf": "1.31.1", "lightningcss-linux-arm64-gnu": "1.31.1", "lightningcss-linux-arm64-musl": "1.31.1", "lightningcss-linux-x64-gnu": "1.31.1", "lightningcss-linux-x64-musl": "1.31.1", "lightningcss-win32-arm64-msvc": "1.31.1", "lightningcss-win32-x64-msvc": "1.31.1" } }, "sha512-l51N2r93WmGUye3WuFoN5k10zyvrVs0qfKBhyC5ogUQ6Ew6JUSswh78mbSO+IU3nTWsyOArqPCcShdQSadghBQ=="],
 
     "@tailwindcss/oxide-wasm32-wasi/@emnapi/core": ["@emnapi/core@1.9.0", "", { "dependencies": { "@emnapi/wasi-threads": "1.2.0", "tslib": "^2.4.0" }, "bundled": true }, "sha512-0DQ98G9ZQZOxfUcQn1waV2yS8aWdZ6kJMbYCJB3oUBecjWYO1fqJ+a1DRfPF3O5JEkwqwP1A9QEN/9mYm2Yd0w=="],

docker-compose.yml

@@ -1,6 +1,6 @@
 services:
   gearbox:
-    build: .
+    image: gitea.jeanlucmakiola.de/makiolaj/gearbox:latest
     container_name: gearbox
     ports:
       - "3000:3000"
@@ -10,6 +10,12 @@ services:
     volumes:
       - gearbox-data:/app/data
       - gearbox-uploads:/app/uploads
+    healthcheck:
+      test: ["CMD", "bun", "-e", "fetch('http://localhost:3000/api/health').then(r=>r.ok?process.exit(0):process.exit(1)).catch(()=>process.exit(1))"]
+      interval: 30s
+      timeout: 5s
+      start_period: 10s
+      retries: 3
     restart: unless-stopped
 
 volumes:

drizzle/0002_broken_roughhouse.sql

@@ -0,0 +1 @@
+ALTER TABLE `thread_candidates` ADD `status` text DEFAULT 'researching' NOT NULL;

drizzle/0003_misty_mongu.sql

@@ -0,0 +1 @@
+ALTER TABLE `setup_items` ADD `classification` text DEFAULT 'base' NOT NULL;

drizzle/0004_soft_synch.sql

@@ -0,0 +1,2 @@
+ALTER TABLE `thread_candidates` ADD `pros` text;--> statement-breakpoint
+ALTER TABLE `thread_candidates` ADD `cons` text;

drizzle/0005_clear_micromax.sql

@@ -0,0 +1 @@
+ALTER TABLE `thread_candidates` ADD `sort_order` real DEFAULT 0 NOT NULL;

drizzle/meta/0002_snapshot.json

@@ -0,0 +1,475 @@
+{
+  "version": "6",
+  "dialect": "sqlite",
+  "id": "ad8099fa-5c3f-4918-9e21-a259cae77d4f",
+  "prevId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
+  "tables": {
+    "categories": {
+      "name": "categories",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "icon": {
+          "name": "icon",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'package'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {
+        "categories_name_unique": {
+          "name": "categories_name_unique",
+          "columns": [
+            "name"
+          ],
+          "isUnique": true
+        }
+      },
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "items": {
+      "name": "items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "items_category_id_categories_id_fk": {
+          "name": "items_category_id_categories_id_fk",
+          "tableFrom": "items",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "settings": {
+      "name": "settings",
+      "columns": {
+        "key": {
+          "name": "key",
+          "type": "text",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "value": {
+          "name": "value",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setup_items": {
+      "name": "setup_items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "setup_id": {
+          "name": "setup_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "item_id": {
+          "name": "item_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "setup_items_setup_id_setups_id_fk": {
+          "name": "setup_items_setup_id_setups_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "setups",
+          "columnsFrom": [
+            "setup_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "setup_items_item_id_items_id_fk": {
+          "name": "setup_items_item_id_items_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "items",
+          "columnsFrom": [
+            "item_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setups": {
+      "name": "setups",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "thread_candidates": {
+      "name": "thread_candidates",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "thread_id": {
+          "name": "thread_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'researching'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "thread_candidates_thread_id_threads_id_fk": {
+          "name": "thread_candidates_thread_id_threads_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "threads",
+          "columnsFrom": [
+            "thread_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "thread_candidates_category_id_categories_id_fk": {
+          "name": "thread_candidates_category_id_categories_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "threads": {
+      "name": "threads",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'active'"
+        },
+        "resolved_candidate_id": {
+          "name": "resolved_candidate_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "threads_category_id_categories_id_fk": {
+          "name": "threads_category_id_categories_id_fk",
+          "tableFrom": "threads",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    }
+  },
+  "views": {},
+  "enums": {},
+  "_meta": {
+    "schemas": {},
+    "tables": {},
+    "columns": {}
+  },
+  "internal": {
+    "indexes": {}
+  }
+}

drizzle/meta/0003_snapshot.json

@@ -0,0 +1,483 @@
+{
+  "version": "6",
+  "dialect": "sqlite",
+  "id": "628b9ef4-c715-4bbe-a118-042d80fde91e",
+  "prevId": "ad8099fa-5c3f-4918-9e21-a259cae77d4f",
+  "tables": {
+    "categories": {
+      "name": "categories",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "icon": {
+          "name": "icon",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'package'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {
+        "categories_name_unique": {
+          "name": "categories_name_unique",
+          "columns": [
+            "name"
+          ],
+          "isUnique": true
+        }
+      },
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "items": {
+      "name": "items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "items_category_id_categories_id_fk": {
+          "name": "items_category_id_categories_id_fk",
+          "tableFrom": "items",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "settings": {
+      "name": "settings",
+      "columns": {
+        "key": {
+          "name": "key",
+          "type": "text",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "value": {
+          "name": "value",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setup_items": {
+      "name": "setup_items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "setup_id": {
+          "name": "setup_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "item_id": {
+          "name": "item_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "classification": {
+          "name": "classification",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'base'"
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "setup_items_setup_id_setups_id_fk": {
+          "name": "setup_items_setup_id_setups_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "setups",
+          "columnsFrom": [
+            "setup_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "setup_items_item_id_items_id_fk": {
+          "name": "setup_items_item_id_items_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "items",
+          "columnsFrom": [
+            "item_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setups": {
+      "name": "setups",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "thread_candidates": {
+      "name": "thread_candidates",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "thread_id": {
+          "name": "thread_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'researching'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "thread_candidates_thread_id_threads_id_fk": {
+          "name": "thread_candidates_thread_id_threads_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "threads",
+          "columnsFrom": [
+            "thread_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "thread_candidates_category_id_categories_id_fk": {
+          "name": "thread_candidates_category_id_categories_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "threads": {
+      "name": "threads",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'active'"
+        },
+        "resolved_candidate_id": {
+          "name": "resolved_candidate_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "threads_category_id_categories_id_fk": {
+          "name": "threads_category_id_categories_id_fk",
+          "tableFrom": "threads",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    }
+  },
+  "views": {},
+  "enums": {},
+  "_meta": {
+    "schemas": {},
+    "tables": {},
+    "columns": {}
+  },
+  "internal": {
+    "indexes": {}
+  }
+}

drizzle/meta/0004_snapshot.json

@@ -0,0 +1,497 @@
+{
+  "version": "6",
+  "dialect": "sqlite",
+  "id": "529d2e93-7d7f-4a83-bb29-254ce09cdef4",
+  "prevId": "628b9ef4-c715-4bbe-a118-042d80fde91e",
+  "tables": {
+    "categories": {
+      "name": "categories",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "icon": {
+          "name": "icon",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'package'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {
+        "categories_name_unique": {
+          "name": "categories_name_unique",
+          "columns": [
+            "name"
+          ],
+          "isUnique": true
+        }
+      },
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "items": {
+      "name": "items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "items_category_id_categories_id_fk": {
+          "name": "items_category_id_categories_id_fk",
+          "tableFrom": "items",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "settings": {
+      "name": "settings",
+      "columns": {
+        "key": {
+          "name": "key",
+          "type": "text",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "value": {
+          "name": "value",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setup_items": {
+      "name": "setup_items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "setup_id": {
+          "name": "setup_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "item_id": {
+          "name": "item_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "classification": {
+          "name": "classification",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'base'"
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "setup_items_setup_id_setups_id_fk": {
+          "name": "setup_items_setup_id_setups_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "setups",
+          "columnsFrom": [
+            "setup_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "setup_items_item_id_items_id_fk": {
+          "name": "setup_items_item_id_items_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "items",
+          "columnsFrom": [
+            "item_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setups": {
+      "name": "setups",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "thread_candidates": {
+      "name": "thread_candidates",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "thread_id": {
+          "name": "thread_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'researching'"
+        },
+        "pros": {
+          "name": "pros",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "cons": {
+          "name": "cons",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "thread_candidates_thread_id_threads_id_fk": {
+          "name": "thread_candidates_thread_id_threads_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "threads",
+          "columnsFrom": [
+            "thread_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "thread_candidates_category_id_categories_id_fk": {
+          "name": "thread_candidates_category_id_categories_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "threads": {
+      "name": "threads",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'active'"
+        },
+        "resolved_candidate_id": {
+          "name": "resolved_candidate_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "threads_category_id_categories_id_fk": {
+          "name": "threads_category_id_categories_id_fk",
+          "tableFrom": "threads",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    }
+  },
+  "views": {},
+  "enums": {},
+  "_meta": {
+    "schemas": {},
+    "tables": {},
+    "columns": {}
+  },
+  "internal": {
+    "indexes": {}
+  }
+}

drizzle/meta/0005_snapshot.json

@@ -0,0 +1,505 @@
+{
+  "version": "6",
+  "dialect": "sqlite",
+  "id": "297e86db-c777-4432-950e-b0129dedb2dc",
+  "prevId": "529d2e93-7d7f-4a83-bb29-254ce09cdef4",
+  "tables": {
+    "categories": {
+      "name": "categories",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "icon": {
+          "name": "icon",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'package'"
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {
+        "categories_name_unique": {
+          "name": "categories_name_unique",
+          "columns": [
+            "name"
+          ],
+          "isUnique": true
+        }
+      },
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "items": {
+      "name": "items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "items_category_id_categories_id_fk": {
+          "name": "items_category_id_categories_id_fk",
+          "tableFrom": "items",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "settings": {
+      "name": "settings",
+      "columns": {
+        "key": {
+          "name": "key",
+          "type": "text",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "value": {
+          "name": "value",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setup_items": {
+      "name": "setup_items",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "setup_id": {
+          "name": "setup_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "item_id": {
+          "name": "item_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "classification": {
+          "name": "classification",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'base'"
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "setup_items_setup_id_setups_id_fk": {
+          "name": "setup_items_setup_id_setups_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "setups",
+          "columnsFrom": [
+            "setup_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "setup_items_item_id_items_id_fk": {
+          "name": "setup_items_item_id_items_id_fk",
+          "tableFrom": "setup_items",
+          "tableTo": "items",
+          "columnsFrom": [
+            "item_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "setups": {
+      "name": "setups",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {},
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "thread_candidates": {
+      "name": "thread_candidates",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "thread_id": {
+          "name": "thread_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "weight_grams": {
+          "name": "weight_grams",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "price_cents": {
+          "name": "price_cents",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "notes": {
+          "name": "notes",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "product_url": {
+          "name": "product_url",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "image_filename": {
+          "name": "image_filename",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'researching'"
+        },
+        "pros": {
+          "name": "pros",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "cons": {
+          "name": "cons",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "sort_order": {
+          "name": "sort_order",
+          "type": "real",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": 0
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "thread_candidates_thread_id_threads_id_fk": {
+          "name": "thread_candidates_thread_id_threads_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "threads",
+          "columnsFrom": [
+            "thread_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "cascade",
+          "onUpdate": "no action"
+        },
+        "thread_candidates_category_id_categories_id_fk": {
+          "name": "thread_candidates_category_id_categories_id_fk",
+          "tableFrom": "thread_candidates",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    },
+    "threads": {
+      "name": "threads",
+      "columns": {
+        "id": {
+          "name": "id",
+          "type": "integer",
+          "primaryKey": true,
+          "notNull": true,
+          "autoincrement": true
+        },
+        "name": {
+          "name": "name",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "status": {
+          "name": "status",
+          "type": "text",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false,
+          "default": "'active'"
+        },
+        "resolved_candidate_id": {
+          "name": "resolved_candidate_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": false,
+          "autoincrement": false
+        },
+        "category_id": {
+          "name": "category_id",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "created_at": {
+          "name": "created_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        },
+        "updated_at": {
+          "name": "updated_at",
+          "type": "integer",
+          "primaryKey": false,
+          "notNull": true,
+          "autoincrement": false
+        }
+      },
+      "indexes": {},
+      "foreignKeys": {
+        "threads_category_id_categories_id_fk": {
+          "name": "threads_category_id_categories_id_fk",
+          "tableFrom": "threads",
+          "tableTo": "categories",
+          "columnsFrom": [
+            "category_id"
+          ],
+          "columnsTo": [
+            "id"
+          ],
+          "onDelete": "no action",
+          "onUpdate": "no action"
+        }
+      },
+      "compositePrimaryKeys": {},
+      "uniqueConstraints": {},
+      "checkConstraints": {}
+    }
+  },
+  "views": {},
+  "enums": {},
+  "_meta": {
+    "schemas": {},
+    "tables": {},
+    "columns": {}
+  },
+  "internal": {
+    "indexes": {}
+  }
+}

drizzle/meta/_journal.json

@@ -15,6 +15,34 @@
       "when": 1773593102000,
       "tag": "0001_rename_emoji_to_icon",
       "breakpoints": true
+    },
+    {
+      "idx": 2,
+      "version": "6",
+      "when": 1773666521689,
+      "tag": "0002_broken_roughhouse",
+      "breakpoints": true
+    },
+    {
+      "idx": 3,
+      "version": "6",
+      "when": 1773670263013,
+      "tag": "0003_misty_mongu",
+      "breakpoints": true
+    },
+    {
+      "idx": 4,
+      "version": "6",
+      "when": 1773693113029,
+      "tag": "0004_soft_synch",
+      "breakpoints": true
+    },
+    {
+      "idx": 5,
+      "version": "6",
+      "when": 1773696058992,
+      "tag": "0005_clear_micromax",
+      "breakpoints": true
     }
   ]
 }

index.html

@@ -3,6 +3,7 @@
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
     <title>GearBox</title>
   </head>
   <body>

package.json

@@ -40,6 +40,7 @@
 		"lucide-react": "^0.577.0",
 		"react": "^19.2.4",
 		"react-dom": "^19.2.4",
+		"recharts": "^3.8.0",
 		"tailwindcss": "^4.2.1",
 		"zod": "^4.3.6",
 		"zustand": "^5.0.11"

public/favicon.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="#ffffff" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="m7.5 4.27 9 5.15"/><path d="M21 8a2 2 0 0 0-1-1.73l-7-4a2 2 0 0 0-2 0l-7 4A2 2 0 0 0 3 8v8a2 2 0 0 0 1 1.73l7 4a2 2 0 0 0 2 0l7-4A2 2 0 0 0 21 16Z"/><path d="m3.3 7 8.7 5 8.7-5"/><path d="M12 22V12"/></svg>

src/client/components/CandidateCard.tsx

@@ -1,6 +1,10 @@
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
 import { formatPrice, formatWeight } from "../lib/formatters";
 import { LucideIcon } from "../lib/iconData";
 import { useUIStore } from "../stores/uiStore";
+import { RankBadge } from "./CandidateListItem";
+import { StatusBadge } from "./StatusBadge";
 
 interface CandidateCardProps {
 	id: number;
@@ -13,6 +17,11 @@ interface CandidateCardProps {
 	productUrl?: string | null;
 	threadId: number;
 	isActive: boolean;
+	status: "researching" | "ordered" | "arrived";
+	onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+	pros?: string | null;
+	cons?: string | null;
+	rank?: number;
 }
 
 export function CandidateCard({
@@ -26,7 +35,14 @@ export function CandidateCard({
 	productUrl,
 	threadId,
 	isActive,
+	status,
+	onStatusChange,
+	pros,
+	cons,
+	rank,
 }: CandidateCardProps) {
+	const unit = useWeightUnit();
+	const currency = useCurrency();
 	const openCandidateEditPanel = useUIStore((s) => s.openCandidateEditPanel);
 	const openConfirmDeleteCandidate = useUIStore(
 		(s) => s.openConfirmDeleteCandidate,
@@ -35,18 +51,78 @@ export function CandidateCard({
 	const openExternalLink = useUIStore((s) => s.openExternalLink);
 
 	return (
-		<div className="relative bg-white rounded-xl border border-gray-100 hover:border-gray-200 hover:shadow-sm transition-all overflow-hidden group">
+		<button
+			type="button"
+			onClick={() => openCandidateEditPanel(id)}
+			className="relative w-full text-left bg-white rounded-xl border border-gray-100 hover:border-gray-200 hover:shadow-sm transition-all overflow-hidden group"
+		>
+			{/* Hover-reveal action buttons */}
+			{isActive && (
+				<span
+					role="button"
+					tabIndex={0}
+					onClick={(e) => {
+						e.stopPropagation();
+						openResolveDialog(threadId, id);
+					}}
+					onKeyDown={(e) => {
+						if (e.key === "Enter" || e.key === " ") {
+							e.stopPropagation();
+							openResolveDialog(threadId, id);
+						}
+					}}
+					className="absolute top-2 left-2 z-10 px-2 py-0.5 flex items-center gap-1 rounded-full text-xs font-medium bg-amber-100/90 text-amber-700 hover:bg-amber-200 opacity-0 group-hover:opacity-100 transition-all cursor-pointer"
+					title="Pick as winner"
+				>
+					<LucideIcon name="trophy" size={12} />
+					Winner
+				</span>
+			)}
+			<span
+				role="button"
+				tabIndex={0}
+				onClick={(e) => {
+					e.stopPropagation();
+					openConfirmDeleteCandidate(id);
+				}}
+				onKeyDown={(e) => {
+					if (e.key === "Enter" || e.key === " ") {
+						e.stopPropagation();
+						openConfirmDeleteCandidate(id);
+					}
+				}}
+				className={`absolute top-2 ${productUrl ? "right-10" : "right-2"} z-10 w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-red-100 hover:text-red-500 opacity-0 group-hover:opacity-100 transition-all cursor-pointer`}
+				title="Delete candidate"
+			>
+				<svg
+					className="w-3.5 h-3.5"
+					fill="none"
+					stroke="currentColor"
+					viewBox="0 0 24 24"
+				>
+					<path
+						strokeLinecap="round"
+						strokeLinejoin="round"
+						strokeWidth={2}
+						d="M6 18L18 6M6 6l12 12"
+					/>
+				</svg>
+			</span>
 			{productUrl && (
 				<span
 					role="button"
 					tabIndex={0}
-					onClick={() => openExternalLink(productUrl)}
+					onClick={(e) => {
+						e.stopPropagation();
+						openExternalLink(productUrl);
+					}}
 					onKeyDown={(e) => {
 						if (e.key === "Enter" || e.key === " ") {
+							e.stopPropagation();
 							openExternalLink(productUrl);
 						}
 					}}
-					className="absolute top-2 right-2 z-10 w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-blue-100 hover:text-blue-500 opacity-0 group-hover:opacity-100 transition-all cursor-pointer"
+					className="absolute top-2 right-2 z-10 w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-gray-200 hover:text-gray-600 opacity-0 group-hover:opacity-100 transition-all cursor-pointer"
 					title="Open product link"
 				>
 					<svg
@@ -85,15 +161,16 @@ export function CandidateCard({
 				<h3 className="text-sm font-semibold text-gray-900 mb-2 truncate">
 					{name}
 				</h3>
-				<div className="flex flex-wrap gap-1.5 mb-3">
+				<div className="flex flex-wrap gap-1.5">
+					{rank != null && <RankBadge rank={rank} />}
 					{weightGrams != null && (
-						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-700">
-							{formatWeight(weightGrams)}
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-400">
+							{formatWeight(weightGrams, unit)}
 						</span>
 					)}
 					{priceCents != null && (
-						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-700">
-							{formatPrice(priceCents)}
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-500">
+							{formatPrice(priceCents, currency)}
 						</span>
 					)}
 					<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-50 text-gray-600">
@@ -104,33 +181,14 @@ export function CandidateCard({
 						/>{" "}
 						{categoryName}
 					</span>
-				</div>
-				<div className="flex gap-2">
-					<button
-						type="button"
-						onClick={() => openCandidateEditPanel(id)}
-						className="text-xs text-gray-500 hover:text-blue-600 transition-colors"
-					>
-						Edit
-					</button>
-					<button
-						type="button"
-						onClick={() => openConfirmDeleteCandidate(id)}
-						className="text-xs text-gray-500 hover:text-red-600 transition-colors"
-					>
-						Delete
-					</button>
-					{isActive && (
-						<button
-							type="button"
-							onClick={() => openResolveDialog(threadId, id)}
-							className="ml-auto text-xs font-medium text-amber-600 hover:text-amber-700 transition-colors"
-						>
-							Pick Winner
-						</button>
+					<StatusBadge status={status} onStatusChange={onStatusChange} />
+					{(pros || cons) && (
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-700">
+							+/- Notes
+						</span>
 					)}
 				</div>
 			</div>
-		</div>
+		</button>
 	);
 }

src/client/components/CandidateForm.tsx

@@ -19,6 +19,8 @@ interface FormData {
 	notes: string;
 	productUrl: string;
 	imageFilename: string | null;
+	pros: string;
+	cons: string;
 }
 
 const INITIAL_FORM: FormData = {
@@ -29,6 +31,8 @@ const INITIAL_FORM: FormData = {
 	notes: "",
 	productUrl: "",
 	imageFilename: null,
+	pros: "",
+	cons: "",
 };
 
 export function CandidateForm({
@@ -61,6 +65,8 @@ export function CandidateForm({
 					notes: candidate.notes ?? "",
 					productUrl: candidate.productUrl ?? "",
 					imageFilename: candidate.imageFilename,
+					pros: candidate.pros ?? "",
+					cons: candidate.cons ?? "",
 				});
 			}
 		} else if (mode === "add") {
@@ -110,6 +116,8 @@ export function CandidateForm({
 			notes: form.notes.trim() || undefined,
 			productUrl: form.productUrl.trim() || undefined,
 			imageFilename: form.imageFilename ?? undefined,
+			pros: form.pros.trim() || undefined,
+			cons: form.cons.trim() || undefined,
 		};
 
 		if (mode === "add") {
@@ -152,7 +160,7 @@ export function CandidateForm({
 					type="text"
 					value={form.name}
 					onChange={(e) => setForm((f) => ({ ...f, name: e.target.value }))}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. Osprey Talon 22"
 				/>
 				{errors.name && (
@@ -177,7 +185,7 @@ export function CandidateForm({
 					onChange={(e) =>
 						setForm((f) => ({ ...f, weightGrams: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. 680"
 				/>
 				{errors.weightGrams && (
@@ -202,7 +210,7 @@ export function CandidateForm({
 					onChange={(e) =>
 						setForm((f) => ({ ...f, priceDollars: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. 129.99"
 				/>
 				{errors.priceDollars && (
@@ -234,11 +242,47 @@ export function CandidateForm({
 					value={form.notes}
 					onChange={(e) => setForm((f) => ({ ...f, notes: e.target.value }))}
 					rows={3}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent resize-none"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent resize-none"
 					placeholder="Any additional notes..."
 				/>
 			</div>
 
+			{/* Pros */}
+			<div>
+				<label
+					htmlFor="candidate-pros"
+					className="block text-sm font-medium text-gray-700 mb-1"
+				>
+					Pros
+				</label>
+				<textarea
+					id="candidate-pros"
+					value={form.pros}
+					onChange={(e) => setForm((f) => ({ ...f, pros: e.target.value }))}
+					rows={3}
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent resize-none"
+					placeholder="One pro per line..."
+				/>
+			</div>
+
+			{/* Cons */}
+			<div>
+				<label
+					htmlFor="candidate-cons"
+					className="block text-sm font-medium text-gray-700 mb-1"
+				>
+					Cons
+				</label>
+				<textarea
+					id="candidate-cons"
+					value={form.cons}
+					onChange={(e) => setForm((f) => ({ ...f, cons: e.target.value }))}
+					rows={3}
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent resize-none"
+					placeholder="One con per line..."
+				/>
+			</div>
+
 			{/* Product Link */}
 			<div>
 				<label
@@ -254,7 +298,7 @@ export function CandidateForm({
 					onChange={(e) =>
 						setForm((f) => ({ ...f, productUrl: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="https://..."
 				/>
 				{errors.productUrl && (
@@ -267,7 +311,7 @@ export function CandidateForm({
 				<button
 					type="submit"
 					disabled={isPending}
-					className="flex-1 py-2.5 px-4 bg-blue-600 hover:bg-blue-700 disabled:opacity-50 text-white text-sm font-medium rounded-lg transition-colors"
+					className="flex-1 py-2.5 px-4 bg-gray-700 hover:bg-gray-800 disabled:opacity-50 text-white text-sm font-medium rounded-lg transition-colors"
 				>
 					{isPending
 						? "Saving..."

src/client/components/CandidateListItem.tsx

@@ -0,0 +1,211 @@
+import { Reorder, useDragControls } from "framer-motion";
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
+import { formatPrice, formatWeight } from "../lib/formatters";
+import { LucideIcon } from "../lib/iconData";
+import { useUIStore } from "../stores/uiStore";
+import { StatusBadge } from "./StatusBadge";
+
+interface CandidateWithCategory {
+	id: number;
+	threadId: number;
+	name: string;
+	weightGrams: number | null;
+	priceCents: number | null;
+	categoryId: number;
+	notes: string | null;
+	productUrl: string | null;
+	imageFilename: string | null;
+	status: "researching" | "ordered" | "arrived";
+	pros: string | null;
+	cons: string | null;
+	createdAt: string;
+	updatedAt: string;
+	categoryName: string;
+	categoryIcon: string;
+}
+
+interface CandidateListItemProps {
+	candidate: CandidateWithCategory;
+	rank: number;
+	isActive: boolean;
+	onStatusChange: (status: "researching" | "ordered" | "arrived") => void;
+}
+
+const RANK_COLORS = ["#D4AF37", "#C0C0C0", "#CD7F32"]; // gold, silver, bronze
+
+export function RankBadge({ rank }: { rank: number }) {
+	if (rank > 3) return null;
+	return (
+		<LucideIcon
+			name="medal"
+			size={16}
+			className="shrink-0"
+			style={{ color: RANK_COLORS[rank - 1] }}
+		/>
+	);
+}
+
+export function CandidateListItem({
+	candidate,
+	rank,
+	isActive,
+	onStatusChange,
+}: CandidateListItemProps) {
+	const controls = useDragControls();
+	const unit = useWeightUnit();
+	const currency = useCurrency();
+	const openCandidateEditPanel = useUIStore((s) => s.openCandidateEditPanel);
+	const openConfirmDeleteCandidate = useUIStore(
+		(s) => s.openConfirmDeleteCandidate,
+	);
+	const openResolveDialog = useUIStore((s) => s.openResolveDialog);
+	const openExternalLink = useUIStore((s) => s.openExternalLink);
+
+	return (
+		<Reorder.Item
+			value={candidate}
+			dragControls={controls}
+			dragListener={false}
+			className="flex items-center gap-3 bg-white rounded-xl border border-gray-100 p-3 hover:border-gray-200 hover:shadow-sm transition-all group cursor-default"
+		>
+			{/* Drag handle */}
+			{isActive && (
+				<button
+					type="button"
+					onPointerDown={(e) => controls.start(e)}
+					className="cursor-grab active:cursor-grabbing text-gray-300 hover:text-gray-500 touch-none shrink-0"
+					title="Drag to reorder"
+				>
+					<LucideIcon name="grip-vertical" size={16} />
+				</button>
+			)}
+
+			{/* Rank badge */}
+			<RankBadge rank={rank} />
+
+			{/* Image thumbnail */}
+			<div className="w-12 h-12 rounded-lg overflow-hidden shrink-0 bg-gray-50 flex items-center justify-center">
+				{candidate.imageFilename ? (
+					<img
+						src={`/uploads/${candidate.imageFilename}`}
+						alt={candidate.name}
+						className="w-full h-full object-cover"
+					/>
+				) : (
+					<LucideIcon
+						name={candidate.categoryIcon}
+						size={20}
+						className="text-gray-400"
+					/>
+				)}
+			</div>
+
+			{/* Name + badges */}
+			<button
+				type="button"
+				onClick={() => openCandidateEditPanel(candidate.id)}
+				className="flex-1 min-w-0 text-left"
+			>
+				<p className="text-sm font-semibold text-gray-900 truncate">
+					{candidate.name}
+				</p>
+				<div className="flex flex-wrap gap-1.5 mt-1">
+					{candidate.weightGrams != null && (
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-400">
+							{formatWeight(candidate.weightGrams, unit)}
+						</span>
+					)}
+					{candidate.priceCents != null && (
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-500">
+							{formatPrice(candidate.priceCents, currency)}
+						</span>
+					)}
+					<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-50 text-gray-600">
+						<LucideIcon
+							name={candidate.categoryIcon}
+							size={14}
+							className="inline-block mr-1 text-gray-500"
+						/>
+						{candidate.categoryName}
+					</span>
+					<StatusBadge
+						status={candidate.status}
+						onStatusChange={onStatusChange}
+					/>
+					{(candidate.pros || candidate.cons) && (
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-700">
+							+/- Notes
+						</span>
+					)}
+				</div>
+			</button>
+
+			{/* Action buttons (hover-reveal) */}
+			<div className="flex items-center gap-1 opacity-0 group-hover:opacity-100 transition-opacity shrink-0">
+				{isActive && (
+					<button
+						type="button"
+						onClick={(e) => {
+							e.stopPropagation();
+							openResolveDialog(candidate.threadId, candidate.id);
+						}}
+						className="px-2 py-0.5 flex items-center gap-1 rounded-full text-xs font-medium bg-amber-100/90 text-amber-700 hover:bg-amber-200 cursor-pointer"
+						title="Pick as winner"
+					>
+						<LucideIcon name="trophy" size={12} />
+						Winner
+					</button>
+				)}
+				{candidate.productUrl && (
+					<button
+						type="button"
+						onClick={(e) => {
+							e.stopPropagation();
+							openExternalLink(candidate.productUrl as string);
+						}}
+						className="w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-gray-200 hover:text-gray-600 cursor-pointer"
+						title="Open product link"
+					>
+						<svg
+							className="w-3.5 h-3.5"
+							fill="none"
+							stroke="currentColor"
+							viewBox="0 0 24 24"
+						>
+							<path
+								strokeLinecap="round"
+								strokeLinejoin="round"
+								strokeWidth={2}
+								d="M18 13v6a2 2 0 01-2 2H5a2 2 0 01-2-2V8a2 2 0 012-2h6M15 3h6v6M10 14L21 3"
+							/>
+						</svg>
+					</button>
+				)}
+				<button
+					type="button"
+					onClick={(e) => {
+						e.stopPropagation();
+						openConfirmDeleteCandidate(candidate.id);
+					}}
+					className="w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-red-100 hover:text-red-500 cursor-pointer"
+					title="Delete candidate"
+				>
+					<svg
+						className="w-3.5 h-3.5"
+						fill="none"
+						stroke="currentColor"
+						viewBox="0 0 24 24"
+					>
+						<path
+							strokeLinecap="round"
+							strokeLinejoin="round"
+							strokeWidth={2}
+							d="M6 18L18 6M6 6l12 12"
+						/>
+					</svg>
+				</button>
+			</div>
+		</Reorder.Item>
+	);
+}

src/client/components/CategoryFilterDropdown.tsx

@@ -0,0 +1,198 @@
+import { useEffect, useRef, useState } from "react";
+import { LucideIcon } from "../lib/iconData";
+
+interface CategoryFilterDropdownProps {
+	value: number | null;
+	onChange: (value: number | null) => void;
+	categories: Array<{ id: number; name: string; icon: string }>;
+}
+
+export function CategoryFilterDropdown({
+	value,
+	onChange,
+	categories,
+}: CategoryFilterDropdownProps) {
+	const [isOpen, setIsOpen] = useState(false);
+	const [searchText, setSearchText] = useState("");
+	const containerRef = useRef<HTMLDivElement>(null);
+	const searchInputRef = useRef<HTMLInputElement>(null);
+
+	const selectedCategory = categories.find((c) => c.id === value);
+
+	const filteredCategories = categories.filter((c) =>
+		c.name.toLowerCase().includes(searchText.toLowerCase()),
+	);
+
+	// Click-outside dismiss
+	useEffect(() => {
+		function handleClickOutside(e: MouseEvent) {
+			if (
+				containerRef.current &&
+				!containerRef.current.contains(e.target as Node)
+			) {
+				setIsOpen(false);
+				setSearchText("");
+			}
+		}
+		document.addEventListener("mousedown", handleClickOutside);
+		return () => document.removeEventListener("mousedown", handleClickOutside);
+	}, []);
+
+	// Escape key dismiss
+	useEffect(() => {
+		function handleKeyDown(e: KeyboardEvent) {
+			if (e.key === "Escape" && isOpen) {
+				setIsOpen(false);
+				setSearchText("");
+			}
+		}
+		document.addEventListener("keydown", handleKeyDown);
+		return () => document.removeEventListener("keydown", handleKeyDown);
+	}, [isOpen]);
+
+	// Auto-focus search input when dropdown opens
+	useEffect(() => {
+		if (isOpen && searchInputRef.current) {
+			searchInputRef.current.focus();
+		}
+	}, [isOpen]);
+
+	function handleSelect(categoryId: number | null) {
+		onChange(categoryId);
+		setIsOpen(false);
+		setSearchText("");
+	}
+
+	return (
+		<div ref={containerRef} className="relative">
+			{/* Trigger button */}
+			<button
+				type="button"
+				onClick={() => setIsOpen((prev) => !prev)}
+				className="flex items-center gap-2 px-3 py-2 border border-gray-200 rounded-lg text-sm bg-white hover:bg-gray-50 transition-colors whitespace-nowrap"
+			>
+				{selectedCategory ? (
+					<>
+						<LucideIcon
+							name={selectedCategory.icon}
+							size={14}
+							className="text-gray-500 shrink-0"
+						/>
+						<span className="text-gray-900">{selectedCategory.name}</span>
+					</>
+				) : (
+					<span className="text-gray-600">All categories</span>
+				)}
+				{selectedCategory ? (
+					<button
+						type="button"
+						onClick={(e) => {
+							e.stopPropagation();
+							onChange(null);
+						}}
+						className="ml-1 text-gray-400 hover:text-gray-600"
+					>
+						<svg
+							className="w-3.5 h-3.5"
+							fill="none"
+							stroke="currentColor"
+							viewBox="0 0 24 24"
+						>
+							<path
+								strokeLinecap="round"
+								strokeLinejoin="round"
+								strokeWidth={2}
+								d="M6 18L18 6M6 6l12 12"
+							/>
+						</svg>
+					</button>
+				) : (
+					<svg
+						className="w-4 h-4 text-gray-400"
+						fill="none"
+						stroke="currentColor"
+						viewBox="0 0 24 24"
+					>
+						<path
+							strokeLinecap="round"
+							strokeLinejoin="round"
+							strokeWidth={2}
+							d="M19 9l-7 7-7-7"
+						/>
+					</svg>
+				)}
+			</button>
+
+			{/* Dropdown panel */}
+			{isOpen && (
+				<div className="absolute right-0 z-20 mt-1 min-w-[220px] bg-white border border-gray-200 rounded-lg shadow-lg">
+					{/* Search input */}
+					<div className="p-2 border-b border-gray-100">
+						<input
+							ref={searchInputRef}
+							type="text"
+							placeholder="Search categories..."
+							value={searchText}
+							onChange={(e) => setSearchText(e.target.value)}
+							className="w-full px-2.5 py-1.5 border border-gray-200 rounded text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
+						/>
+					</div>
+
+					{/* Option list */}
+					<ul className="max-h-60 overflow-y-auto py-1">
+						{/* All categories option */}
+						{(searchText === "" ||
+							"all categories".includes(searchText.toLowerCase())) && (
+							<li>
+								<button
+									type="button"
+									onClick={() => handleSelect(null)}
+									className={`w-full text-left px-3 py-2 text-sm cursor-pointer hover:bg-gray-50 ${
+										value === null
+											? "bg-gray-50 font-medium text-gray-900"
+											: "text-gray-700"
+									}`}
+								>
+									All categories
+								</button>
+							</li>
+						)}
+
+						{/* Category options */}
+						{filteredCategories.map((cat) => (
+							<li key={cat.id}>
+								<button
+									type="button"
+									onClick={() => handleSelect(cat.id)}
+									className={`w-full text-left px-3 py-2 text-sm cursor-pointer flex items-center gap-2 hover:bg-gray-50 ${
+										cat.id === value
+											? "bg-gray-50 font-medium text-gray-900"
+											: "text-gray-700"
+									}`}
+								>
+									<LucideIcon
+										name={cat.icon}
+										size={16}
+										className="text-gray-500 shrink-0"
+									/>
+									{cat.name}
+								</button>
+							</li>
+						))}
+
+						{/* No results */}
+						{filteredCategories.length === 0 &&
+							!(
+								searchText === "" ||
+								"all categories".includes(searchText.toLowerCase())
+							) && (
+								<li className="px-3 py-2 text-sm text-gray-400">
+									No categories found
+								</li>
+							)}
+					</ul>
+				</div>
+			)}
+		</div>
+	);
+}

src/client/components/CategoryHeader.tsx

@@ -1,5 +1,7 @@
 import { useState } from "react";
 import { useDeleteCategory, useUpdateCategory } from "../hooks/useCategories";
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
 import { formatPrice, formatWeight } from "../lib/formatters";
 import { LucideIcon } from "../lib/iconData";
 import { IconPicker } from "./IconPicker";
@@ -21,6 +23,8 @@ export function CategoryHeader({
 	totalCost,
 	itemCount,
 }: CategoryHeaderProps) {
+	const unit = useWeightUnit();
+	const currency = useCurrency();
 	const [isEditing, setIsEditing] = useState(false);
 	const [editName, setEditName] = useState(name);
 	const [editIcon, setEditIcon] = useState(icon);
@@ -64,7 +68,7 @@ export function CategoryHeader({
 				<button
 					type="button"
 					onClick={handleSave}
-					className="text-sm text-blue-600 hover:text-blue-800 font-medium"
+					className="text-sm text-gray-600 hover:text-gray-800 font-medium"
 				>
 					Save
 				</button>
@@ -85,7 +89,7 @@ export function CategoryHeader({
 			<h2 className="text-lg font-semibold text-gray-900">{name}</h2>
 			<span className="text-sm text-gray-400">
 				{itemCount} {itemCount === 1 ? "item" : "items"} ·{" "}
-				{formatWeight(totalWeight)} · {formatPrice(totalCost)}
+				{formatWeight(totalWeight, unit)} · {formatPrice(totalCost, currency)}
 			</span>
 			{!isUncategorized && (
 				<div className="ml-auto flex items-center gap-1 opacity-0 group-hover:opacity-100 transition-opacity">

src/client/components/CategoryPicker.tsx

@@ -169,7 +169,7 @@ export function CategoryPicker({ value, onChange }: CategoryPickerProps) {
 						setInputValue("");
 					}}
 					onKeyDown={handleKeyDown}
-					className={`w-full py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent ${
+					className={`w-full py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent ${
 						!isOpen && selectedCategory ? "pl-8 pr-3" : "px-3"
 					}`}
 				/>
@@ -187,7 +187,7 @@ export function CategoryPicker({ value, onChange }: CategoryPickerProps) {
 							aria-selected={cat.id === value}
 							className={`px-3 py-2 text-sm cursor-pointer flex items-center gap-1.5 ${
 								i === highlightIndex
-									? "bg-blue-50 text-blue-900"
+									? "bg-gray-100 text-gray-900"
 									: "hover:bg-gray-50"
 							} ${cat.id === value ? "font-medium" : ""}`}
 							onClick={() => handleSelect(cat.id)}
@@ -207,7 +207,7 @@ export function CategoryPicker({ value, onChange }: CategoryPickerProps) {
 							aria-selected={false}
 							className={`px-3 py-2 text-sm cursor-pointer border-t border-gray-100 ${
 								highlightIndex === filtered.length
-									? "bg-blue-50 text-blue-900"
+									? "bg-gray-100 text-gray-900"
 									: "hover:bg-gray-50 text-gray-600"
 							}`}
 							onClick={handleStartCreate}
@@ -231,7 +231,7 @@ export function CategoryPicker({ value, onChange }: CategoryPickerProps) {
 									type="button"
 									onClick={handleConfirmCreate}
 									disabled={createCategory.isPending}
-									className="text-xs font-medium text-blue-600 hover:text-blue-800 disabled:opacity-50"
+									className="text-xs font-medium text-gray-600 hover:text-gray-800 disabled:opacity-50"
 								>
 									{createCategory.isPending ? "..." : "Create"}
 								</button>

src/client/components/ClassificationBadge.tsx

@@ -0,0 +1,30 @@
+const CLASSIFICATION_LABELS: Record<string, string> = {
+	base: "Base Weight",
+	worn: "Worn",
+	consumable: "Consumable",
+};
+
+interface ClassificationBadgeProps {
+	classification: string;
+	onCycle: () => void;
+}
+
+export function ClassificationBadge({
+	classification,
+	onCycle,
+}: ClassificationBadgeProps) {
+	const label = CLASSIFICATION_LABELS[classification] ?? "Base Weight";
+
+	return (
+		<button
+			type="button"
+			onClick={(e) => {
+				e.stopPropagation();
+				onCycle();
+			}}
+			className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-100 text-gray-600 hover:bg-gray-200 transition-colors cursor-pointer"
+		>
+			{label}
+		</button>
+	);
+}

src/client/components/ComparisonTable.tsx

@@ -0,0 +1,336 @@
+import { useMemo } from "react";
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
+import { formatPrice, formatWeight } from "../lib/formatters";
+import { LucideIcon } from "../lib/iconData";
+import { useUIStore } from "../stores/uiStore";
+import { RankBadge } from "./CandidateListItem";
+
+interface CandidateWithCategory {
+	id: number;
+	threadId: number;
+	name: string;
+	weightGrams: number | null;
+	priceCents: number | null;
+	categoryId: number;
+	notes: string | null;
+	productUrl: string | null;
+	imageFilename: string | null;
+	status: "researching" | "ordered" | "arrived";
+	pros: string | null;
+	cons: string | null;
+	createdAt: string;
+	updatedAt: string;
+	categoryName: string;
+	categoryIcon: string;
+}
+
+interface ComparisonTableProps {
+	candidates: CandidateWithCategory[];
+	resolvedCandidateId: number | null;
+}
+
+const STATUS_LABELS: Record<"researching" | "ordered" | "arrived", string> = {
+	researching: "Researching",
+	ordered: "Ordered",
+	arrived: "Arrived",
+};
+
+export function ComparisonTable({
+	candidates,
+	resolvedCandidateId,
+}: ComparisonTableProps) {
+	const unit = useWeightUnit();
+	const currency = useCurrency();
+	const openExternalLink = useUIStore((s) => s.openExternalLink);
+
+	const { bestWeightId, bestPriceId, weightDeltas, priceDeltas } =
+		useMemo(() => {
+			// Weight deltas
+			const withWeight = candidates.filter((c) => c.weightGrams != null);
+			let bestWeightId: number | null = null;
+			const weightDeltas: Record<number, string | null> = {};
+
+			if (withWeight.length > 0) {
+				const minWeight = Math.min(
+					...withWeight.map((c) => c.weightGrams as number),
+				);
+				bestWeightId =
+					withWeight.find((c) => c.weightGrams === minWeight)?.id ?? null;
+				for (const c of candidates) {
+					if (c.weightGrams == null) {
+						weightDeltas[c.id] = null;
+					} else {
+						const delta = c.weightGrams - minWeight;
+						weightDeltas[c.id] =
+							delta === 0 ? null : `+${formatWeight(delta, unit)}`;
+					}
+				}
+			} else {
+				for (const c of candidates) {
+					weightDeltas[c.id] = null;
+				}
+			}
+
+			// Price deltas
+			const withPrice = candidates.filter((c) => c.priceCents != null);
+			let bestPriceId: number | null = null;
+			const priceDeltas: Record<number, string | null> = {};
+
+			if (withPrice.length > 0) {
+				const minPrice = Math.min(
+					...withPrice.map((c) => c.priceCents as number),
+				);
+				bestPriceId =
+					withPrice.find((c) => c.priceCents === minPrice)?.id ?? null;
+				for (const c of candidates) {
+					if (c.priceCents == null) {
+						priceDeltas[c.id] = null;
+					} else {
+						const delta = c.priceCents - minPrice;
+						priceDeltas[c.id] =
+							delta === 0 ? null : `+${formatPrice(delta, currency)}`;
+					}
+				}
+			} else {
+				for (const c of candidates) {
+					priceDeltas[c.id] = null;
+				}
+			}
+
+			return { bestWeightId, bestPriceId, weightDeltas, priceDeltas };
+		}, [candidates, unit, currency]);
+
+	const ATTRIBUTE_ROWS: Array<{
+		key: string;
+		label: string;
+		render: (
+			candidate: CandidateWithCategory,
+			index: number,
+		) => React.ReactNode;
+		cellClass?: (candidate: CandidateWithCategory) => string;
+	}> = [
+		{
+			key: "image",
+			label: "Image",
+			render: (c) => (
+				<div className="w-12 h-12 rounded-lg overflow-hidden bg-gray-50 flex items-center justify-center">
+					{c.imageFilename ? (
+						<img
+							src={`/uploads/${c.imageFilename}`}
+							alt={c.name}
+							className="w-full h-full object-cover"
+						/>
+					) : (
+						<LucideIcon
+							name={c.categoryIcon}
+							size={20}
+							className="text-gray-400"
+						/>
+					)}
+				</div>
+			),
+		},
+		{
+			key: "name",
+			label: "Name",
+			render: (c) => (
+				<span className="text-sm font-medium text-gray-900">{c.name}</span>
+			),
+		},
+		{
+			key: "rank",
+			label: "Rank",
+			render: (_c, index) => <RankBadge rank={index + 1} />,
+		},
+		{
+			key: "weight",
+			label: "Weight",
+			render: (c) => {
+				const isBest = c.id === bestWeightId;
+				const delta = weightDeltas[c.id];
+				if (c.weightGrams == null) {
+					return <span className="text-gray-300">—</span>;
+				}
+				return (
+					<div>
+						<span className="font-medium text-gray-900">
+							{formatWeight(c.weightGrams, unit)}
+						</span>
+						{!isBest && delta && (
+							<div className="text-xs text-gray-400">{delta}</div>
+						)}
+					</div>
+				);
+			},
+			cellClass: (c) => {
+				if (c.id === bestWeightId) return "bg-blue-50";
+				if (c.id === resolvedCandidateId) return "bg-amber-50/50";
+				return "";
+			},
+		},
+		{
+			key: "price",
+			label: "Price",
+			render: (c) => {
+				const isBest = c.id === bestPriceId;
+				const delta = priceDeltas[c.id];
+				if (c.priceCents == null) {
+					return <span className="text-gray-300">—</span>;
+				}
+				return (
+					<div>
+						<span className="font-medium text-gray-900">
+							{formatPrice(c.priceCents, currency)}
+						</span>
+						{!isBest && delta && (
+							<div className="text-xs text-gray-400">{delta}</div>
+						)}
+					</div>
+				);
+			},
+			cellClass: (c) => {
+				if (c.id === bestPriceId) return "bg-green-50";
+				if (c.id === resolvedCandidateId) return "bg-amber-50/50";
+				return "";
+			},
+		},
+		{
+			key: "status",
+			label: "Status",
+			render: (c) => (
+				<span className="text-xs text-gray-600">{STATUS_LABELS[c.status]}</span>
+			),
+		},
+		{
+			key: "link",
+			label: "Link",
+			render: (c) =>
+				c.productUrl ? (
+					<button
+						type="button"
+						onClick={() => openExternalLink(c.productUrl as string)}
+						className="text-xs text-blue-500 hover:underline"
+					>
+						View
+					</button>
+				) : (
+					<span className="text-gray-300">—</span>
+				),
+		},
+		{
+			key: "notes",
+			label: "Notes",
+			render: (c) =>
+				c.notes ? (
+					<p className="text-xs text-gray-700 whitespace-pre-line">{c.notes}</p>
+				) : (
+					<span className="text-gray-300">—</span>
+				),
+		},
+		{
+			key: "pros",
+			label: "Pros",
+			render: (c) => {
+				if (!c.pros) return <span className="text-gray-300">—</span>;
+				const items = c.pros.split("\n").filter((s) => s.trim() !== "");
+				if (items.length === 0) return <span className="text-gray-300">—</span>;
+				return (
+					<ul className="list-disc list-inside space-y-0.5">
+						{items.map((item, i) => (
+							// biome-ignore lint/suspicious/noArrayIndexKey: stable list of static items
+							<li key={i} className="text-xs text-gray-700">
+								{item}
+							</li>
+						))}
+					</ul>
+				);
+			},
+		},
+		{
+			key: "cons",
+			label: "Cons",
+			render: (c) => {
+				if (!c.cons) return <span className="text-gray-300">—</span>;
+				const items = c.cons.split("\n").filter((s) => s.trim() !== "");
+				if (items.length === 0) return <span className="text-gray-300">—</span>;
+				return (
+					<ul className="list-disc list-inside space-y-0.5">
+						{items.map((item, i) => (
+							// biome-ignore lint/suspicious/noArrayIndexKey: stable list of static items
+							<li key={i} className="text-xs text-gray-700">
+								{item}
+							</li>
+						))}
+					</ul>
+				);
+			},
+		},
+	];
+
+	const tableMinWidth = Math.max(400, candidates.length * 180);
+
+	return (
+		<div className="overflow-x-auto rounded-xl border border-gray-100">
+			<table
+				className="border-collapse text-sm w-full"
+				style={{ minWidth: `${tableMinWidth}px` }}
+			>
+				<thead>
+					<tr className="border-b border-gray-100">
+						{/* Sticky empty corner cell */}
+						<th className="sticky left-0 z-10 bg-white px-4 py-3 text-left text-xs font-medium text-gray-700 w-28" />
+						{candidates.map((candidate) => {
+							const isWinner = candidate.id === resolvedCandidateId;
+							return (
+								<th
+									key={candidate.id}
+									className={`px-4 py-3 text-left text-xs font-medium min-w-[160px] ${
+										isWinner ? "bg-amber-50 text-amber-800" : "text-gray-700"
+									}`}
+								>
+									<div className="flex items-center gap-1">
+										{isWinner && (
+											<LucideIcon
+												name="trophy"
+												size={12}
+												className="text-amber-600"
+											/>
+										)}
+										{candidate.name}
+									</div>
+								</th>
+							);
+						})}
+					</tr>
+				</thead>
+				<tbody>
+					{ATTRIBUTE_ROWS.map((row) => (
+						<tr key={row.key} className="border-b border-gray-50">
+							{/* Sticky label cell */}
+							<td className="sticky left-0 z-10 bg-white px-4 py-3 text-xs font-medium text-gray-500 uppercase tracking-wide w-28">
+								{row.label}
+							</td>
+							{candidates.map((candidate, index) => {
+								const isWinner = candidate.id === resolvedCandidateId;
+								const extraClass = row.cellClass
+									? row.cellClass(candidate)
+									: isWinner
+										? "bg-amber-50/50"
+										: "";
+								return (
+									<td
+										key={candidate.id}
+										className={`px-4 py-3 min-w-[160px] ${extraClass}`}
+									>
+										{row.render(candidate, index)}
+									</td>
+								);
+							})}
+						</tr>
+					))}
+				</tbody>
+			</table>
+		</div>
+	);
+}

src/client/components/CreateThreadModal.tsx

@@ -93,7 +93,7 @@ export function CreateThreadModal() {
 							value={name}
 							onChange={(e) => setName(e.target.value)}
 							placeholder="e.g. Lightweight sleeping bag"
-							className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+							className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 						/>
 					</div>
 
@@ -108,7 +108,7 @@ export function CreateThreadModal() {
 							id="thread-category"
 							value={categoryId ?? ""}
 							onChange={(e) => setCategoryId(Number(e.target.value))}
-							className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent bg-white"
+							className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent bg-white"
 						>
 							{categories?.map((cat) => (
 								<option key={cat.id} value={cat.id}>
@@ -131,7 +131,7 @@ export function CreateThreadModal() {
 						<button
 							type="submit"
 							disabled={createThread.isPending}
-							className="px-4 py-2 text-sm font-medium text-white bg-blue-600 hover:bg-blue-700 disabled:opacity-50 rounded-lg transition-colors"
+							className="px-4 py-2 text-sm font-medium text-white bg-gray-700 hover:bg-gray-800 disabled:opacity-50 rounded-lg transition-colors"
 						>
 							{createThread.isPending ? "Creating..." : "Create Thread"}
 						</button>

src/client/components/DashboardCard.tsx

@@ -43,7 +43,7 @@ export function DashboardCard({
 				))}
 			</div>
 			{allZero && emptyText && (
-				<p className="mt-4 text-sm text-blue-600 font-medium">{emptyText}</p>
+				<p className="mt-4 text-sm text-gray-500 font-medium">{emptyText}</p>
 			)}
 		</Link>
 	);

src/client/components/ExternalLinkDialog.tsx

@@ -38,7 +38,7 @@ export function ExternalLinkDialog() {
 					You are about to leave GearBox
 				</h3>
 				<p className="text-sm text-gray-600 mb-1">You will be redirected to:</p>
-				<p className="text-sm text-blue-600 break-all mb-6">
+				<p className="text-sm text-gray-600 break-all mb-6">
 					{externalLinkUrl}
 				</p>
 				<div className="flex justify-end gap-3">
@@ -52,7 +52,7 @@ export function ExternalLinkDialog() {
 					<button
 						type="button"
 						onClick={handleContinue}
-						className="px-4 py-2 text-sm font-medium text-white bg-blue-600 hover:bg-blue-700 rounded-lg transition-colors"
+						className="px-4 py-2 text-sm font-medium text-white bg-gray-700 hover:bg-gray-800 rounded-lg transition-colors"
 					>
 						Continue
 					</button>

src/client/components/IconPicker.tsx

@@ -150,7 +150,7 @@ export function IconPicker({ value, onChange, size = "md" }: IconPickerProps) {
 									setActiveGroup(0);
 								}}
 								placeholder="Search icons..."
-								className="w-full px-2 py-1.5 text-sm border border-gray-200 rounded-md focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+								className="w-full px-2 py-1.5 text-sm border border-gray-200 rounded-md focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 							/>
 						</div>
 
@@ -164,7 +164,7 @@ export function IconPicker({ value, onChange, size = "md" }: IconPickerProps) {
 										onClick={() => setActiveGroup(i)}
 										className={`flex-1 flex items-center justify-center py-1 rounded transition-colors ${
 											i === activeGroup
-												? "bg-blue-50 text-blue-700"
+												? "bg-gray-200 text-gray-700"
 												: "hover:bg-gray-50 text-gray-500"
 										}`}
 										title={group.name}
@@ -173,7 +173,7 @@ export function IconPicker({ value, onChange, size = "md" }: IconPickerProps) {
 											name={group.icon}
 											size={16}
 											className={
-												i === activeGroup ? "text-blue-700" : "text-gray-400"
+												i === activeGroup ? "text-gray-700" : "text-gray-400"
 											}
 										/>
 									</button>

src/client/components/ItemCard.tsx

@@ -1,6 +1,9 @@
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
 import { formatPrice, formatWeight } from "../lib/formatters";
 import { LucideIcon } from "../lib/iconData";
 import { useUIStore } from "../stores/uiStore";
+import { ClassificationBadge } from "./ClassificationBadge";
 
 interface ItemCardProps {
 	id: number;
@@ -12,6 +15,8 @@ interface ItemCardProps {
 	imageFilename: string | null;
 	productUrl?: string | null;
 	onRemove?: () => void;
+	classification?: string;
+	onClassificationCycle?: () => void;
 }
 
 export function ItemCard({
@@ -24,7 +29,11 @@ export function ItemCard({
 	imageFilename,
 	productUrl,
 	onRemove,
+	classification,
+	onClassificationCycle,
 }: ItemCardProps) {
+	const unit = useWeightUnit();
+	const currency = useCurrency();
 	const openEditPanel = useUIStore((s) => s.openEditPanel);
 	const openExternalLink = useUIStore((s) => s.openExternalLink);
 
@@ -48,7 +57,7 @@ export function ItemCard({
 							openExternalLink(productUrl);
 						}
 					}}
-					className={`absolute top-2 ${onRemove ? "right-10" : "right-2"} z-10 w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-blue-100 hover:text-blue-500 opacity-0 group-hover:opacity-100 transition-all cursor-pointer`}
+					className={`absolute top-2 ${onRemove ? "right-10" : "right-2"} z-10 w-6 h-6 flex items-center justify-center rounded-full bg-gray-100/80 text-gray-400 hover:bg-gray-200 hover:text-gray-600 opacity-0 group-hover:opacity-100 transition-all cursor-pointer`}
 					title="Open product link"
 				>
 					<svg
@@ -121,13 +130,13 @@ export function ItemCard({
 				</h3>
 				<div className="flex flex-wrap gap-1.5">
 					{weightGrams != null && (
-						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-700">
-							{formatWeight(weightGrams)}
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-400">
+							{formatWeight(weightGrams, unit)}
 						</span>
 					)}
 					{priceCents != null && (
-						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-700">
-							{formatPrice(priceCents)}
+						<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-500">
+							{formatPrice(priceCents, currency)}
 						</span>
 					)}
 					<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-50 text-gray-600">
@@ -138,6 +147,12 @@ export function ItemCard({
 						/>{" "}
 						{categoryName}
 					</span>
+					{classification && onClassificationCycle && (
+						<ClassificationBadge
+							classification={classification}
+							onCycle={onClassificationCycle}
+						/>
+					)}
 				</div>
 			</div>
 		</button>

src/client/components/ItemForm.tsx

@@ -144,7 +144,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 					type="text"
 					value={form.name}
 					onChange={(e) => setForm((f) => ({ ...f, name: e.target.value }))}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. Osprey Talon 22"
 				/>
 				{errors.name && (
@@ -169,7 +169,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 					onChange={(e) =>
 						setForm((f) => ({ ...f, weightGrams: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. 680"
 				/>
 				{errors.weightGrams && (
@@ -194,7 +194,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 					onChange={(e) =>
 						setForm((f) => ({ ...f, priceDollars: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="e.g. 129.99"
 				/>
 				{errors.priceDollars && (
@@ -226,7 +226,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 					value={form.notes}
 					onChange={(e) => setForm((f) => ({ ...f, notes: e.target.value }))}
 					rows={3}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent resize-none"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent resize-none"
 					placeholder="Any additional notes..."
 				/>
 			</div>
@@ -246,7 +246,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 					onChange={(e) =>
 						setForm((f) => ({ ...f, productUrl: e.target.value }))
 					}
-					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+					className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 					placeholder="https://..."
 				/>
 				{errors.productUrl && (
@@ -259,7 +259,7 @@ export function ItemForm({ mode, itemId }: ItemFormProps) {
 				<button
 					type="submit"
 					disabled={isPending}
-					className="flex-1 py-2.5 px-4 bg-blue-600 hover:bg-blue-700 disabled:opacity-50 text-white text-sm font-medium rounded-lg transition-colors"
+					className="flex-1 py-2.5 px-4 bg-gray-700 hover:bg-gray-800 disabled:opacity-50 text-white text-sm font-medium rounded-lg transition-colors"
 				>
 					{isPending
 						? "Saving..."

src/client/components/ItemPicker.tsx

@@ -1,6 +1,8 @@
 import { useEffect, useState } from "react";
+import { useCurrency } from "../hooks/useCurrency";
 import { useItems } from "../hooks/useItems";
 import { useSyncSetupItems } from "../hooks/useSetups";
+import { useWeightUnit } from "../hooks/useWeightUnit";
 import { formatPrice, formatWeight } from "../lib/formatters";
 import { LucideIcon } from "../lib/iconData";
 import { SlideOutPanel } from "./SlideOutPanel";
@@ -20,6 +22,8 @@ export function ItemPicker({
 }: ItemPickerProps) {
 	const { data: items } = useItems();
 	const syncItems = useSyncSetupItems(setupId);
+	const unit = useWeightUnit();
+	const currency = useCurrency();
 	const [selectedIds, setSelectedIds] = useState<Set<number>>(new Set());
 
 	// Reset selected IDs when panel opens
@@ -107,19 +111,19 @@ export function ItemPicker({
 													type="checkbox"
 													checked={selectedIds.has(item.id)}
 													onChange={() => handleToggle(item.id)}
-													className="rounded border-gray-300 text-blue-600 focus:ring-blue-500"
+													className="rounded border-gray-300 text-gray-600 focus:ring-gray-400"
 												/>
 												<span className="flex-1 text-sm text-gray-900 truncate">
 													{item.name}
 												</span>
 												<span className="text-xs text-gray-400 shrink-0">
 													{item.weightGrams != null &&
-														formatWeight(item.weightGrams)}
+														formatWeight(item.weightGrams, unit)}
 													{item.weightGrams != null &&
 														item.priceCents != null &&
 														" · "}
 													{item.priceCents != null &&
-														formatPrice(item.priceCents)}
+														formatPrice(item.priceCents, currency)}
 												</span>
 											</label>
 										))}
@@ -143,7 +147,7 @@ export function ItemPicker({
 						type="button"
 						onClick={handleDone}
 						disabled={syncItems.isPending}
-						className="flex-1 px-4 py-2 text-sm font-medium text-white bg-blue-600 hover:bg-blue-700 disabled:opacity-50 rounded-lg transition-colors"
+						className="flex-1 px-4 py-2 text-sm font-medium text-white bg-gray-700 hover:bg-gray-800 disabled:opacity-50 rounded-lg transition-colors"
 					>
 						{syncItems.isPending ? "Saving..." : "Done"}
 					</button>

src/client/components/OnboardingWizard.tsx

@@ -102,7 +102,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 						<div
 							key={s}
 							className={`h-1.5 rounded-full transition-all ${
-								s <= Math.min(step, 3) ? "bg-blue-600 w-8" : "bg-gray-200 w-6"
+								s <= Math.min(step, 3) ? "bg-gray-700 w-8" : "bg-gray-200 w-6"
 							}`}
 						/>
 					))}
@@ -121,7 +121,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 						<button
 							type="button"
 							onClick={() => setStep(2)}
-							className="w-full py-3 px-4 bg-blue-600 hover:bg-blue-700 text-white font-medium rounded-lg transition-colors"
+							className="w-full py-3 px-4 bg-gray-700 hover:bg-gray-800 text-white font-medium rounded-lg transition-colors"
 						>
 							Get Started
 						</button>
@@ -159,7 +159,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 									type="text"
 									value={categoryName}
 									onChange={(e) => setCategoryName(e.target.value)}
-									className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+									className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 									placeholder="e.g. Shelter"
 								/>
 							</div>
@@ -184,7 +184,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 							type="button"
 							onClick={handleCreateCategory}
 							disabled={createCategory.isPending}
-							className="mt-6 w-full py-3 px-4 bg-blue-600 hover:bg-blue-700 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
+							className="mt-6 w-full py-3 px-4 bg-gray-700 hover:bg-gray-800 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
 						>
 							{createCategory.isPending ? "Creating..." : "Create Category"}
 						</button>
@@ -221,7 +221,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 									type="text"
 									value={itemName}
 									onChange={(e) => setItemName(e.target.value)}
-									className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+									className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 									placeholder="e.g. Big Agnes Copper Spur"
 								/>
 							</div>
@@ -241,7 +241,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 										step="any"
 										value={itemWeight}
 										onChange={(e) => setItemWeight(e.target.value)}
-										className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+										className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 										placeholder="e.g. 1200"
 									/>
 								</div>
@@ -259,7 +259,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 										step="0.01"
 										value={itemPrice}
 										onChange={(e) => setItemPrice(e.target.value)}
-										className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-transparent"
+										className="w-full px-3 py-2 border border-gray-200 rounded-lg text-sm focus:outline-none focus:ring-2 focus:ring-gray-400 focus:border-transparent"
 										placeholder="e.g. 349.99"
 									/>
 								</div>
@@ -272,7 +272,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 							type="button"
 							onClick={handleCreateItem}
 							disabled={createItem.isPending}
-							className="mt-6 w-full py-3 px-4 bg-blue-600 hover:bg-blue-700 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
+							className="mt-6 w-full py-3 px-4 bg-gray-700 hover:bg-gray-800 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
 						>
 							{createItem.isPending ? "Adding..." : "Add Item"}
 						</button>
@@ -307,7 +307,7 @@ export function OnboardingWizard({ onComplete }: OnboardingWizardProps) {
 							type="button"
 							onClick={handleDone}
 							disabled={updateSetting.isPending}
-							className="w-full py-3 px-4 bg-blue-600 hover:bg-blue-700 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
+							className="w-full py-3 px-4 bg-gray-700 hover:bg-gray-800 disabled:opacity-50 text-white font-medium rounded-lg transition-colors"
 						>
 							{updateSetting.isPending ? "Finishing..." : "Done"}
 						</button>

src/client/components/SetupCard.tsx

@@ -1,4 +1,6 @@
 import { Link } from "@tanstack/react-router";
+import { useCurrency } from "../hooks/useCurrency";
+import { useWeightUnit } from "../hooks/useWeightUnit";
 import { formatPrice, formatWeight } from "../lib/formatters";
 
 interface SetupCardProps {
@@ -16,6 +18,8 @@ export function SetupCard({
 	totalWeight,
 	totalCost,
 }: SetupCardProps) {
+	const unit = useWeightUnit();
+	const currency = useCurrency();
 	return (
 		<Link
 			to="/setups/$setupId"
@@ -24,16 +28,16 @@ export function SetupCard({
 		>
 			<div className="flex items-start justify-between mb-3">
 				<h3 className="text-sm font-semibold text-gray-900 truncate">{name}</h3>
-				<span className="ml-2 inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-700 shrink-0">
+				<span className="ml-2 inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-400 shrink-0">
 					{itemCount} {itemCount === 1 ? "item" : "items"}
 				</span>
 			</div>
 			<div className="flex flex-wrap gap-1.5">
-				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-700">
-					{formatWeight(totalWeight)}
+				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-400">
+					{formatWeight(totalWeight, unit)}
 				</span>
-				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-700">
-					{formatPrice(totalCost)}
+				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-500">
+					{formatPrice(totalCost, currency)}
 				</span>
 			</div>
 		</Link>

src/client/components/StatusBadge.tsx

@@ -0,0 +1,103 @@
+import { useEffect, useRef, useState } from "react";
+import { LucideIcon } from "../lib/iconData";
+
+const STATUS_CONFIG = {
+	researching: { icon: "search", label: "Researching" },
+	ordered: { icon: "truck", label: "Ordered" },
+	arrived: { icon: "check", label: "Arrived" },
+} as const;
+
+type CandidateStatus = keyof typeof STATUS_CONFIG;
+
+interface StatusBadgeProps {
+	status: CandidateStatus;
+	onStatusChange: (status: CandidateStatus) => void;
+}
+
+export function StatusBadge({ status, onStatusChange }: StatusBadgeProps) {
+	const [isOpen, setIsOpen] = useState(false);
+	const containerRef = useRef<HTMLDivElement>(null);
+
+	const config = STATUS_CONFIG[status];
+
+	useEffect(() => {
+		if (!isOpen) return;
+
+		function handleClickOutside(e: MouseEvent) {
+			if (
+				containerRef.current &&
+				!containerRef.current.contains(e.target as Node)
+			) {
+				setIsOpen(false);
+			}
+		}
+
+		function handleEscape(e: KeyboardEvent) {
+			if (e.key === "Escape") {
+				setIsOpen(false);
+			}
+		}
+
+		document.addEventListener("mousedown", handleClickOutside);
+		document.addEventListener("keydown", handleEscape);
+		return () => {
+			document.removeEventListener("mousedown", handleClickOutside);
+			document.removeEventListener("keydown", handleEscape);
+		};
+	}, [isOpen]);
+
+	return (
+		<div ref={containerRef} className="relative">
+			<button
+				type="button"
+				onClick={(e) => {
+					e.stopPropagation();
+					setIsOpen((prev) => !prev);
+				}}
+				className="inline-flex items-center gap-1 px-2 py-0.5 rounded-full text-xs font-medium bg-gray-100 text-gray-600 hover:bg-gray-200 transition-colors cursor-pointer"
+			>
+				<LucideIcon name={config.icon} size={14} className="text-gray-500" />
+				{config.label}
+			</button>
+
+			{isOpen && (
+				<div className="absolute right-0 top-full mt-1 z-20 bg-white border border-gray-200 rounded-lg shadow-lg py-1 min-w-[150px]">
+					{(Object.keys(STATUS_CONFIG) as CandidateStatus[]).map((key) => {
+						const option = STATUS_CONFIG[key];
+						const isActive = key === status;
+						return (
+							<button
+								key={key}
+								type="button"
+								onClick={(e) => {
+									e.stopPropagation();
+									onStatusChange(key);
+									setIsOpen(false);
+								}}
+								className={`w-full flex items-center gap-2 px-3 py-1.5 text-sm text-left hover:bg-gray-50 transition-colors ${
+									isActive ? "bg-gray-50 font-medium" : ""
+								}`}
+							>
+								<LucideIcon
+									name={option.icon}
+									size={14}
+									className={isActive ? "text-gray-700" : "text-gray-400"}
+								/>
+								<span className={isActive ? "text-gray-900" : "text-gray-600"}>
+									{option.label}
+								</span>
+								{isActive && (
+									<LucideIcon
+										name="check"
+										size={14}
+										className="ml-auto text-gray-500"
+									/>
+								)}
+							</button>
+						);
+					})}
+				</div>
+			)}
+		</div>
+	);
+}

src/client/components/ThreadCard.tsx

@@ -1,4 +1,5 @@
 import { useNavigate } from "@tanstack/react-router";
+import { useCurrency } from "../hooks/useCurrency";
 import { formatPrice } from "../lib/formatters";
 import { LucideIcon } from "../lib/iconData";
 
@@ -22,10 +23,11 @@ function formatDate(iso: string): string {
 function formatPriceRange(
 	min: number | null,
 	max: number | null,
+	currency: Parameters<typeof formatPrice>[1],
 ): string | null {
 	if (min == null && max == null) return null;
-	if (min === max) return formatPrice(min);
-	return `${formatPrice(min)} - ${formatPrice(max)}`;
+	if (min === max) return formatPrice(min, currency);
+	return `${formatPrice(min, currency)} - ${formatPrice(max, currency)}`;
 }
 
 export function ThreadCard({
@@ -40,9 +42,10 @@ export function ThreadCard({
 	categoryIcon,
 }: ThreadCardProps) {
 	const navigate = useNavigate();
+	const currency = useCurrency();
 
 	const isResolved = status === "resolved";
-	const priceRange = formatPriceRange(minPriceCents, maxPriceCents);
+	const priceRange = formatPriceRange(minPriceCents, maxPriceCents, currency);
 
 	return (
 		<button
@@ -66,7 +69,7 @@ export function ThreadCard({
 				)}
 			</div>
 			<div className="flex flex-wrap gap-1.5">
-				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-blue-50 text-blue-700">
+				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-50 text-gray-600">
 					<LucideIcon
 						name={categoryIcon}
 						size={16}
@@ -74,14 +77,14 @@ export function ThreadCard({
 					/>{" "}
 					{categoryName}
 				</span>
-				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-700">
+				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-purple-50 text-purple-500">
 					{candidateCount} {candidateCount === 1 ? "candidate" : "candidates"}
 				</span>
 				<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-gray-50 text-gray-600">
 					{formatDate(createdAt)}
 				</span>
 				{priceRange && (
-					<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-700">
+					<span className="inline-flex items-center px-2 py-0.5 rounded-full text-xs font-medium bg-green-50 text-green-500">
 						{priceRange}
 					</span>
 				)}

src/client/components/ThreadTabs.tsx

@@ -1,14 +1,17 @@
-interface ThreadTabsProps {
-	active: "gear" | "planning";
-	onChange: (tab: "gear" | "planning") => void;
+type TabKey = "gear" | "planning" | "setups";
+
+interface CollectionTabsProps {
+	active: TabKey;
+	onChange: (tab: TabKey) => void;
 }
 
 const tabs = [
 	{ key: "gear" as const, label: "My Gear" },
 	{ key: "planning" as const, label: "Planning" },
+	{ key: "setups" as const, label: "Setups" },
 ];
 
-export function ThreadTabs({ active, onChange }: ThreadTabsProps) {
+export function CollectionTabs({ active, onChange }: CollectionTabsProps) {
 	return (
 		<div className="flex border-b border-gray-200">
 			{tabs.map((tab) => (
@@ -18,13 +21,13 @@ export function ThreadTabs({ active, onChange }: ThreadTabsProps) {
 					onClick={() => onChange(tab.key)}
 					className={`px-4 py-2.5 text-sm font-medium transition-colors relative ${
 						active === tab.key
-							? "text-blue-600"
+							? "text-gray-700"
 							: "text-gray-500 hover:text-gray-700"
 					}`}
 				>
 					{tab.label}
 					{active === tab.key && (
-						<span className="absolute bottom-0 left-0 right-0 h-0.5 bg-blue-600 rounded-t" />
+						<span className="absolute bottom-0 left-0 right-0 h-0.5 bg-gray-700 rounded-t" />
 					)}
 				</button>
 			))}

src/client/components/TotalsBar.tsx

@@ -1,6 +1,11 @@
 import { Link } from "@tanstack/react-router";
+import { useUpdateSetting } from "../hooks/useSettings";
 import { useTotals } from "../hooks/useTotals";
-import { formatPrice, formatWeight } from "../lib/formatters";
+import { useWeightUnit } from "../hooks/useWeightUnit";
+import { formatPrice, formatWeight, type WeightUnit } from "../lib/formatters";
+import { LucideIcon } from "../lib/iconData";
+
+const UNITS: WeightUnit[] = ["g", "oz", "lb", "kg"];
 
 interface TotalsBarProps {
 	title?: string;
@@ -14,6 +19,8 @@ export function TotalsBar({
 	linkTo,
 }: TotalsBarProps) {
 	const { data } = useTotals();
+	const unit = useWeightUnit();
+	const updateSetting = useUpdateSetting();
 
 	// When no stats provided, use global totals (backward compatible)
 	const displayStats =
@@ -21,24 +28,34 @@ export function TotalsBar({
 		(data?.global
 			? [
 					{ label: "items", value: String(data.global.itemCount) },
-					{ label: "total", value: formatWeight(data.global.totalWeight) },
+					{
+						label: "total",
+						value: formatWeight(data.global.totalWeight, unit),
+					},
 					{ label: "spent", value: formatPrice(data.global.totalCost) },
 				]
 			: [
 					{ label: "items", value: "0" },
-					{ label: "total", value: formatWeight(null) },
+					{ label: "total", value: formatWeight(null, unit) },
 					{ label: "spent", value: formatPrice(null) },
 				]);
 
+	const titleContent = (
+		<span className="flex items-center gap-2">
+			<LucideIcon name="package" size={20} className="text-gray-500" />
+			{title}
+		</span>
+	);
+
 	const titleElement = linkTo ? (
 		<Link
 			to={linkTo}
-			className="text-lg font-semibold text-gray-900 hover:text-blue-600 transition-colors"
+			className="text-lg font-semibold text-gray-900 hover:text-gray-600 transition-colors"
 		>
-			{title}
+			{titleContent}
 		</Link>
 	) : (
-		<h1 className="text-lg font-semibold text-gray-900">{title}</h1>
+		<h1 className="text-lg font-semibold text-gray-900">{titleContent}</h1>
 	);
 
 	// If stats prop is explicitly an empty array, show title only (dashboard mode)
@@ -49,6 +66,28 @@ export function TotalsBar({
 			<div className="mx-auto max-w-7xl px-4 sm:px-6 lg:px-8">
 				<div className="flex items-center justify-between h-14">
 					{titleElement}
+					<div className="flex items-center gap-4">
+						<div className="flex items-center gap-1 bg-gray-100 rounded-full px-1 py-0.5">
+							{UNITS.map((u) => (
+								<button
+									key={u}
+									type="button"
+									onClick={() =>
+										updateSetting.mutate({
+											key: "weightUnit",
+											value: u,
+										})
+									}
+									className={`px-2 py-0.5 text-xs rounded-full transition-colors ${
+										unit === u
+											? "bg-white text-gray-700 shadow-sm font-medium"
+											: "text-gray-400 hover:text-gray-600"
+									}`}
+								>
+									{u}
+								</button>
+							))}
+						</div>
 						{showStats && (
 							<div className="flex items-center gap-6 text-sm text-gray-500">
 								{displayStats.map((stat) => (
@@ -64,5 +103,6 @@ export function TotalsBar({
 					</div>
 				</div>
 			</div>
+		</div>
 	);
 }

src/client/components/WeightSummaryCard.tsx

@@ -0,0 +1,283 @@
+import { useState } from "react";
+import {
+	Cell,
+	Label,
+	Pie,
+	PieChart,
+	ResponsiveContainer,
+	Tooltip,
+} from "recharts";
+import type { SetupItemWithCategory } from "../hooks/useSetups";
+import { useWeightUnit } from "../hooks/useWeightUnit";
+import { formatWeight, type WeightUnit } from "../lib/formatters";
+import { LucideIcon } from "../lib/iconData";
+
+const CATEGORY_COLORS = [
+	"#374151",
+	"#4b5563",
+	"#6b7280",
+	"#7f8a94",
+	"#9ca3af",
+	"#b0b7bf",
+	"#c4c9cf",
+	"#d1d5db",
+	"#dfe2e6",
+	"#e5e7eb",
+];
+
+const CLASSIFICATION_COLORS: Record<string, string> = {
+	base: "#6b7280",
+	worn: "#9ca3af",
+	consumable: "#d1d5db",
+};
+
+const CLASSIFICATION_LABELS: Record<string, string> = {
+	base: "Base Weight",
+	worn: "Worn",
+	consumable: "Consumable",
+};
+
+type ViewMode = "category" | "classification";
+const VIEW_MODES: ViewMode[] = ["category", "classification"];
+
+interface ChartDatum {
+	name: string;
+	weight: number;
+	percent: number;
+	classificationKey?: string;
+}
+
+interface WeightSummaryCardProps {
+	items: SetupItemWithCategory[];
+}
+
+function buildCategoryChartData(items: SetupItemWithCategory[]): ChartDatum[] {
+	const groups = new Map<string, number>();
+	for (const item of items) {
+		const current = groups.get(item.categoryName) ?? 0;
+		groups.set(item.categoryName, current + (item.weightGrams ?? 0));
+	}
+	const total = items.reduce((sum, i) => sum + (i.weightGrams ?? 0), 0);
+	return Array.from(groups.entries())
+		.filter(([, weight]) => weight > 0)
+		.map(([name, weight]) => ({
+			name,
+			weight,
+			percent: total > 0 ? weight / total : 0,
+		}));
+}
+
+function buildClassificationChartData(
+	items: SetupItemWithCategory[],
+): ChartDatum[] {
+	const groups: Record<string, number> = {
+		base: 0,
+		worn: 0,
+		consumable: 0,
+	};
+	for (const item of items) {
+		groups[item.classification] += item.weightGrams ?? 0;
+	}
+	const total = Object.values(groups).reduce((a, b) => a + b, 0);
+	return Object.entries(groups)
+		.filter(([, weight]) => weight > 0)
+		.map(([key, weight]) => ({
+			name: CLASSIFICATION_LABELS[key] ?? key,
+			weight,
+			percent: total > 0 ? weight / total : 0,
+			classificationKey: key,
+		}));
+}
+
+function CustomTooltip({
+	active,
+	payload,
+	unit,
+}: {
+	active?: boolean;
+	payload?: Array<{ payload: ChartDatum }>;
+	unit: WeightUnit;
+}) {
+	if (!active || !payload?.length) return null;
+	const { name, weight, percent } = payload[0].payload;
+	return (
+		<div className="bg-white border border-gray-200 rounded-lg shadow-lg px-3 py-2 text-sm">
+			<p className="font-medium text-gray-900">{name}</p>
+			<p className="text-gray-600">
+				{formatWeight(weight, unit)} ({(percent * 100).toFixed(1)}%)
+			</p>
+		</div>
+	);
+}
+
+function LegendRow({
+	color,
+	label,
+	weight,
+	unit,
+	percent,
+}: {
+	color: string;
+	label: string;
+	weight: number;
+	unit: WeightUnit;
+	percent?: number;
+}) {
+	return (
+		<div className="flex items-center gap-3 py-1.5">
+			<span
+				className="w-2.5 h-2.5 rounded-full shrink-0"
+				style={{ backgroundColor: color }}
+			/>
+			<span className="text-sm text-gray-600 flex-1">{label}</span>
+			<span className="text-sm font-semibold text-gray-900 tabular-nums">
+				{formatWeight(weight, unit)}
+			</span>
+			{percent != null && (
+				<span className="text-xs text-gray-400 w-10 text-right tabular-nums">
+					{(percent * 100).toFixed(0)}%
+				</span>
+			)}
+		</div>
+	);
+}
+
+export function WeightSummaryCard({ items }: WeightSummaryCardProps) {
+	const unit = useWeightUnit();
+	const [viewMode, setViewMode] = useState<ViewMode>("category");
+
+	const baseWeight = items.reduce(
+		(sum, i) =>
+			i.classification === "base" ? sum + (i.weightGrams ?? 0) : sum,
+		0,
+	);
+	const wornWeight = items.reduce(
+		(sum, i) =>
+			i.classification === "worn" ? sum + (i.weightGrams ?? 0) : sum,
+		0,
+	);
+	const consumableWeight = items.reduce(
+		(sum, i) =>
+			i.classification === "consumable" ? sum + (i.weightGrams ?? 0) : sum,
+		0,
+	);
+	const totalWeight = baseWeight + wornWeight + consumableWeight;
+
+	const chartData =
+		viewMode === "category"
+			? buildCategoryChartData(items)
+			: buildClassificationChartData(items);
+
+	const colors =
+		viewMode === "category"
+			? CATEGORY_COLORS
+			: chartData.map(
+					(d) => CLASSIFICATION_COLORS[d.classificationKey ?? ""] ?? "#6366f1",
+				);
+
+	if (totalWeight === 0) {
+		return (
+			<div className="bg-white rounded-xl border border-gray-100 p-5 mb-6">
+				<h3 className="text-sm font-medium text-gray-700 mb-2">
+					Weight Summary
+				</h3>
+				<p className="text-sm text-gray-400">No weight data to display</p>
+			</div>
+		);
+	}
+
+	return (
+		<div className="bg-white rounded-xl border border-gray-100 p-5 mb-6">
+			{/* Header with pill toggle */}
+			<div className="flex items-center justify-between mb-4">
+				<h3 className="text-sm font-medium text-gray-700">Weight Summary</h3>
+				<div className="flex items-center gap-1 bg-gray-100 rounded-full px-1 py-0.5">
+					{VIEW_MODES.map((mode) => (
+						<button
+							key={mode}
+							type="button"
+							onClick={() => setViewMode(mode)}
+							className={`px-2.5 py-0.5 text-xs rounded-full transition-colors ${
+								viewMode === mode
+									? "bg-white text-gray-700 shadow-sm font-medium"
+									: "text-gray-400 hover:text-gray-600"
+							}`}
+						>
+							{mode === "category" ? "Category" : "Classification"}
+						</button>
+					))}
+				</div>
+			</div>
+
+			{/* Main content: chart + subtotals side by side */}
+			<div className="flex items-center gap-8">
+				{/* Donut chart */}
+				<div className="flex-shrink-0" style={{ width: 180, height: 180 }}>
+					<ResponsiveContainer width="100%" height={180}>
+						<PieChart>
+							<Pie
+								data={chartData}
+								dataKey="weight"
+								nameKey="name"
+								cx="50%"
+								cy="50%"
+								innerRadius={55}
+								outerRadius={80}
+								paddingAngle={2}
+							>
+								{chartData.map((entry, index) => (
+									<Cell key={entry.name} fill={colors[index % colors.length]} />
+								))}
+								<Label
+									value={formatWeight(totalWeight, unit)}
+									position="center"
+									style={{
+										fontSize: "14px",
+										fontWeight: 600,
+										fill: "#374151",
+									}}
+								/>
+							</Pie>
+							<Tooltip content={<CustomTooltip unit={unit} />} />
+						</PieChart>
+					</ResponsiveContainer>
+				</div>
+
+				{/* Weight legend */}
+				<div className="flex-1 flex flex-col justify-center min-w-0">
+					<LegendRow
+						color="#6b7280"
+						label="Base Weight"
+						weight={baseWeight}
+						unit={unit}
+						percent={totalWeight > 0 ? baseWeight / totalWeight : undefined}
+					/>
+					<LegendRow
+						color="#9ca3af"
+						label="Worn"
+						weight={wornWeight}
+						unit={unit}
+						percent={totalWeight > 0 ? wornWeight / totalWeight : undefined}
+					/>
+					<LegendRow
+						color="#d1d5db"
+						label="Consumable"
+						weight={consumableWeight}
+						unit={unit}
+						percent={totalWeight > 0 ? consumableWeight / totalWeight : undefined}
+					/>
+					<div className="border-t border-gray-200 mt-1.5 pt-1.5">
+						<div className="flex items-center gap-3 py-1.5">
+							<LucideIcon name="sigma" size={10} className="text-gray-400 shrink-0 ml-0.5" />
+							<span className="text-sm font-medium text-gray-700 flex-1">Total</span>
+							<span className="text-sm font-bold text-gray-900 tabular-nums">
+								{formatWeight(totalWeight, unit)}
+							</span>
+							<span className="w-10" />
+						</div>
+					</div>
+				</div>
+			</div>
+		</div>
+	);
+}

src/client/hooks/useCandidates.ts

@@ -1,6 +1,6 @@
 import { useMutation, useQueryClient } from "@tanstack/react-query";
 import type { CreateCandidate, UpdateCandidate } from "../../shared/types";
-import { apiDelete, apiPost, apiPut } from "../lib/api";
+import { apiDelete, apiPatch, apiPost, apiPut } from "../lib/api";
 
 interface CandidateResponse {
 	id: number;
@@ -12,6 +12,9 @@ interface CandidateResponse {
 	notes: string | null;
 	productUrl: string | null;
 	imageFilename: string | null;
+	status: "researching" | "ordered" | "arrived";
+	pros: string | null;
+	cons: string | null;
 	createdAt: string;
 	updatedAt: string;
 }
@@ -59,3 +62,17 @@ export function useDeleteCandidate(threadId: number) {
 		},
 	});
 }
+
+export function useReorderCandidates(threadId: number) {
+	const queryClient = useQueryClient();
+	return useMutation({
+		mutationFn: (data: { orderedIds: number[] }) =>
+			apiPatch<{ success: boolean }>(
+				`/api/threads/${threadId}/candidates/reorder`,
+				data,
+			),
+		onSettled: () => {
+			queryClient.invalidateQueries({ queryKey: ["threads", threadId] });
+		},
+	});
+}

src/client/hooks/useCurrency.ts

@@ -0,0 +1,12 @@
+import type { Currency } from "../lib/formatters";
+import { useSetting } from "./useSettings";
+
+const VALID_CURRENCIES: Currency[] = ["USD", "EUR", "GBP", "JPY", "CAD", "AUD"];
+
+export function useCurrency(): Currency {
+	const { data } = useSetting("currency");
+	if (data && VALID_CURRENCIES.includes(data as Currency)) {
+		return data as Currency;
+	}
+	return "USD";
+}