-
Notifications
You must be signed in to change notification settings - Fork 2
fix(gotjunk): Add safety verification for classification modal #93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Changed all navigation and map control buttons from white backgrounds to dark gray (bg-gray-800) to fix white-on-white visibility issue reported by user. Changes: - LeftSidebarNav: bg-white/90 → bg-gray-800/90 for all 4 nav buttons - PigeonMapView: bg-white → bg-gray-800 for zoom/center/legend controls - White icons now clearly visible on dark backgrounds - Provides contrast against light map tile backgrounds Fixes user feedback: "icons no longer display on the map view... need a lite color background and not white on white" 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Fixed typo bug in handleReclassify where `classification` was used instead of `newClassification` parameter, causing incorrect discount/bid values. Added console logging to diagnose duplicate image creation: - Log when handleClassify is called (new items) - Log when handleReclassify is called (re-classification) - Log state updates to track if items are added/updated multiple times - Log IndexedDB saves to track storage operations This will help troubleshoot the issue where changing discount/bid creates duplicate images. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Added missing body scroll lock to PigeonMapView to complete the fullscreen overlay contract. This prevents Safari from clipping floating controls when the map is open. Changes: - Import useEffect from React - Lock document.body.style.overflow = 'hidden' on mount - Restore original overflow on unmount Completes the z-index fix implementation where all fullscreen overlays (ItemReviewer, FullscreenGallery, FullscreenViewer, PigeonMapView) now lock body scroll. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Fixed low-contrast sidebar icons on varied map tile backgrounds by implementing context-aware adaptive styling. Problem: - bg-gray-800/90 icons invisible on dark map tiles (parks, water, buildings) - Inconsistent visibility across mixed urban areas (light streets, dark foliage) - PR #40 fixed white-on-white but created dark-on-dark issue Solution: Added getButtonStyle() helper with conditional map-aware styling: - Map view: Inactive icons use bright bg-indigo-600/85 with strong borders - Other views: Inactive icons retain subtle bg-gray-800/90 - Active state: Always bright blue (unchanged) Changes: - LeftSidebarNav.tsx: Added getButtonStyle() helper function - All 4 buttons now use helper instead of inline ternary logic - Preserved Z_LAYERS.sidebar (2200) from PR #40 contract - No hardcoded z-index values Result: ✅ Icons visible on light streets, dark parks, blue water, gray buildings ✅ No regression on Browse/MyItems/Cart tabs ✅ Active (blue) distinguishable from inactive (indigo) on map ✅ Build: 413.49 kB │ gzip: 130.10 kB (2.68s) Pattern learned: UI over dynamic backgrounds needs context-aware styling. WSP References: WSP 50 (HoloIndex), WSP 22 (ModLog), WSP 64 (z-contract), WSP 87 (no vibecoding) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Added explicit pointer events to PigeonMapView to ensure proper event handling and confirmed z-index layering is correct. Z-index contract (already in place): - Sidebar: Z_LAYERS.sidebar (2200) - highest, always visible - Map: Z_LAYERS.mapOverlay (1600) - below sidebar Changes: - PigeonMapView.tsx: Added pointerEvents: "auto" to map container - Added missing z-index contract files (constants/zLayers.ts, styles/zindex-map.md) The sidebar SHOULD float above the map. If not visible in deployed version, redeploy with latest code from main branch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Added comprehensive entry documenting 7 PRs merged in today's session: - PR #62: Icon size adjustment (12px → 16px) - PR #63: Instructions modal on every load + sidebar positioning - PR #64: Instructions modal with actual swipe button components - PR #65: Fixed modal overlap with camera orb - PR #66: Z-index hierarchy fix (modals above all controls) - PR #67: Instructions modal only on Browse tab - PR #68: Proper modal centering Documented: - Problem/solution for each PR - Code changes with before/after examples - WSP compliance references (WSP 22, 50, 64, 87) - User feedback integration process - Build metrics and zero regression validation WSP 22 Compliance: ModLog kept current with all session changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Root Cause: - handleClassify cleared pendingClassificationItem at END of async function - If user double-tapped or tap fell through ActionSheet, second call would pass guard check before first call completed, creating duplicate items Fix: - Added isProcessingClassification flag to prevent concurrent calls - Clear pendingClassificationItem IMMEDIATELY after guard check - Wrap processing in try/finally to ensure flag is always reset - Log processing state for debugging Impact: - Eliminates duplicate item creation when: * User double-taps classification button * Tap falls through ActionSheet backdrop to button beneath * User rapidly taps after modifying discount/bid settings Tested: Build passes (vite build ✓) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…select ISSUE: PR #84 removed power-user quick-select feature - Changed onTap to ALWAYS open action sheet - Broke documented behavior: "Tap to select • Long-press to edit" - JSDoc explicitly states: "Single tap: Select classification with defaults" ROOT CAUSE: Misinterpreted user complaint about "choice bypass" - Thought quick-tap was the problem - Actually removed useful power-user shortcut - Helper text contradicted implementation FIX: Restore original intent - Tap DISCOUNT → Instant select with current default (75%) - Long-press DISCOUNT → Open action sheet to customize - Tap BID → Instant select with current default (48h) - Long-press BID → Open action sheet to customize - FREE → Always instant select (unchanged) BEHAVIOR: Before PR #84: Tap=instant, Long-press=edit ✓ (correct) After PR #84: Tap=menu, Long-press=menu ✗ (vibecoding) After this fix: Tap=instant, Long-press=edit ✓ (restored) WSP: Anti-vibecoding (CLAUDE.md), First principles analysis Files: - modules/foundups/gotjunk/frontend/components/ClassificationModal.tsx 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…ement ISSUE: Camera orb visible on Browse tab caused confusion - Browse tab shows OTHER people's items - Camera creates YOUR items - Contextually misleading - why take photo while browsing? USER INSIGHT (Occam's Razor): "Camera should NOT be on landing screen (Browse tab)" "ONLY show on My Items tab - eliminate confusion" FIX: One line change - camera orb only visible on My Items tab - Browse tab → No camera orb (browse mode) - My Items tab → Camera orb visible (create mode) - Map view → No camera orb (location mode) - All other navigation stays visible BEHAVIOR: Before: Camera orb on Browse + My Items tabs After: Camera orb ONLY on My Items tab FILE: modules/foundups/gotjunk/frontend/App.tsx:495 CHANGE: const showCameraOrb = !isMapOpen && activeTab === 'myItems'; WSP: Occam's Razor (simplest solution), First principles UX 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
… markers ISSUE: Photos went to myDrafts (user ownership model) USER INSIGHT (First Principles): "This is a found items app, not a marketplace" - When taking photos, you're DOCUMENTING found items (like Pokémon GO) - Photos should populate Browse feed immediately (not "My Items") - Map should show ALL items with thumbnails - Clicking map marker should filter Browse to that location CHANGES: 1. **Camera → Browse Feed** (not myDrafts) - Changed handleClassify: ownership='world', status='browsing' - Photos now appear in Browse feed immediately - Location: App.tsx:303-320 2. **Map Shows Browse Feed** (not myListed) - Changed junkItems data source: browseFeed instead of myListed - All captured items appear as map markers - Location: App.tsx:764-774 3. **Map Marker Click → Filter Browse** - Added locationFilter state (App.tsx:86) - Added onMarkerClick handler: filters Browse by GPS (~100m radius) - Clicking marker → switches to Browse tab + filters by location - Location: App.tsx:491-503, 791-797 4. **PigeonMapView Enhanced** - Added onMarkerClick prop (optional) - Marker onClick: calls onMarkerClick(location) instead of onClose() - Location: PigeonMapView.tsx:27, 169-175 FLOW (Before): Camera → Classify → myDrafts → Review → Publish → Browse Map shows: myListed items only FLOW (After): Camera → Classify → Browse feed (instant!) Map shows: ALL Browse items Map click → Browse filtered by location TEST PLAN: 1. Take photo → Classify → Should appear in Browse feed 2. Open Map → Should see thumbnail marker at photo location 3. Click marker → Should filter Browse to items at that GPS location 4. Take photos at different locations → Map should show multiple markers WSP: Occam's Razor (simplest flow), First principles (found items, not marketplace) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Problem: Sometimes after taking a photo, the classification modal (Free/Discount/Bid) doesn't appear or gets accidentally dismissed, leaving the user unable to post the image. Solution: Implemented automatic safety verification system: 1. **Backup Storage**: Store captured item in ref when photo taken - pendingClassificationBackupRef stores blob/url/location - classificationCompletedRef tracks if user made selection 2. **Safety Monitor**: useEffect watches pendingClassificationItem - Detects if modal closes without classification - Automatically restores modal after 100ms delay - Console warnings for debugging 3. **Completion Tracking**: Mark when classification succeeds - handleClassify sets classificationCompletedRef = true - Clears backup to prevent false positives Files Changed: - App.tsx:103-104 - Added backup refs - App.tsx:106-122 - Added safety monitor useEffect - App.tsx:285-293 - Store backup in handleCapture - App.tsx:309-310 - Mark completion in handleClassify Console Output: - "[GotJunk] Photo captured - opening classification modal" - "[GotJunk] SAFETY CHECK: Classification modal closed without selection! Restoring..." - "[GotJunk] SAFETY RESTORE: Re-opening classification modal" This ensures users MUST classify before image is posted. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Adds automatic safety verification to ensure the classification modal (Free/Discount/Bid) always appears and waits for user selection before posting images.
Problem
User reported: "when I take a pic sometimes the selection option doesn't happen"
The classification modal would sometimes:
Result: Photo captured but user unable to classify and post it.
Solution
Implemented 3-layer safety verification system:
1. Backup Storage
Added refs (App.tsx:103-104):
Stores captured photo data as backup when photo is taken.
2. Safety Monitor
useEffect watcher (App.tsx:106-122):
Monitors when
pendingClassificationItemchanges. If it disappears without classification completing, automatically restores the modal after 100ms.3. Completion Tracking
Mark success (App.tsx:309-310):
When user successfully selects Free/Discount/Bid, marks classification as completed and clears backup.
Debugging
Console output added for troubleshooting:
"[GotJunk] Photo captured - opening classification modal"- Photo captured"[GotJunk] SAFETY CHECK: Classification modal closed without selection! Restoring..."- Modal disappeared unexpectedly"[GotJunk] SAFETY RESTORE: Re-opening classification modal"- Modal restoredTesting
Before:
After:
User Experience
This ensures users can NEVER lose a captured photo. The modal will keep re-appearing until they make a classification choice (Free/Discount/Bid).
🤖 Generated with Claude Code