Dashboard

Late June, Sherman/Sheridan double 14er, two-day shakedown with Kid — his first 14er. Kyle wanted Roamze's gear list to tell Kid he needs real traction above 13k, not nag the experienced hiker about beginner items, and factor in car-camping at the TH.

• maxTokens: 2048 in generateGearListHandler truncated real responses mid-array — real Haiku output is ~8k chars. Bumped to 4096.
• trailhead_elevation_ft silently dropped from inline request bodies — field existed on TripContext but not on GearListRequest. Added to the request type and wired into buildTripContext.

N/A — this was a swarm-infrastructure change, not a product feature.

Wednesday night, planning Memorial Day weekend. Kyle opens /explore, wants to filter to 'Colorado, May 23-25, day hike' without typing a natural-language query. Taps the pill, taps the Memorial Day quick-date chip (visible 28 days out), picks Colorado, sees filtered results in-page.

• Initial build added the search bar as a separate sticky row below the nav instead of integrating inline into the existing Navigation component — caught by side-by-side screenshot comparison with the home page, which already has the correct pattern. Required a second iteration to refactor into the existing Navigation.tsx instead of scaffolding a parallel component tree.
• Memorial Day chip hidden on Apr 21 because the 28-day window put the holiday 32 days out. Kept the 28-day window as-is; chip will render starting Apr 25. Manual trail test used explicit date picker instead.

Imagine a user who saved a Smith Rock overnight back in February, logged one completed experience, and hasn't opened Roamze in 35+ days. On the daily 9am local run, the candidate query finds them, the generator writes a short note that references Smith Rock and Leadville by name, the reviewer scores it 23/25 and greenlights, Resend delivers it to Gmail. If the reviewer fails on safety (invented closure) or specificity, we don't send. Second follow-up ~3 weeks later explicitly signals it's the final check-in.

• contextPacket.ts selected non-existent scalar columns (location_name, activity_type) when the experiences schema stores location as JSONB and uses experience_type enum (migration 005). The 400s were silently absorbed because the code destructured `{ data }` without `{ error }`, so every user hit the NO_SEND sentinel. Fixed with correct column names + explicit error logging on every Supabase call.
• signUnsubscribeToken test was flaky (~6.5% rate) because it flipped the LAST base64 char of the sig — the last char encodes only 4 real bits, so some flips decoded to the identical buffer. Fixed by flipping the first char instead.
• Logo invisible in Gmail — used a colored SVG + CSS `filter: brightness(0) invert(1)` to whiten it at render time, but Gmail strips CSS filters on <img>, producing indigo-on-indigo. Fixed with a pre-whitened PNG hosted on Supabase Storage behind LIFECYCLE_LOGO_URL env var.
• Seasonal hallucinations — 2 of 3 early drafts failed reviewer on Safety axis with phrases like 'Leadville's high country is waking up' and 'snowmelt's running.' The season field in the context packet was derived from month (not observed) and the generator treated it as ground truth. Option 3 fix: dropped the season field entirely so the generator can only reference actual input data.
• Migration 129 (campaign_sends + email_events tables) was not applied to staging at first. Silent-error-absorption in the job's Supabase writes masked this — sent:1 was reported even though no row was being written. Kyle applied the SQL manually to staging; prod still pending. Root-cause of the silent absorption is tracked in GH #227.

New user signs up via the Roamze frontend at 8pm on a Sunday. Frontend calls /signup → public.users row created. Supabase sends a confirm-your-email link. User clicks the link from their phone at 8:02pm. Behind the scenes: auth.users.email_confirmed_at gets set, Supabase DB webhook hits the backend, handler enqueues a pending_welcome_emails row with fire_at=8:07pm. Cloud Scheduler fires the drain at 8:08:00pm, picks up the row, renders the 'YOU'RE IN.' email, sends via Resend. User gets the email at 8:08:30pm — 6 minutes 30 seconds after clicking confirm. They open it, see the founder note from Kyle, click 'Find your first trail', and land on /discover with utm_source=welcome attribution intact.

• v1 hero showed a generic orange-circle SVG placeholder — fallback URL was `${APP_URL}/og-image.png` (the brand OG illustration), wrong tone for welcome. Fixed by uploading a real outdoor photograph (Patagonia hikers) to Supabase Storage at experience-photos/brand/welcome-hero.jpg and hardcoding that as the WELCOME_HERO_IMAGE_URL fallback so preview renders correctly without env config.
• Three design iterations before composition lock: v2 was full-indigo immersive with 'You're in.' at 42px (too small, looked like lifecycle), v3 dropped the outer-darker bg per Kyle's feedback but still felt undifferentiated, v4 swung too far to a cream 'letter' variant that abandoned the brand palette, v5 landed on indigo + onX-style editorial composition — tight header, full-bleed hero, 96px overlay, 440px column, pill CTA, 3-line minimal footer. Lesson lives in the `lessons` block.
• Schema-verification pass during LLD assumed an auth.users → public.users sync trigger on signup. Wrong — public.users is created by the backend's /signup route, not a DB trigger. Production reality is fine (frontend always calls /signup before user clicks confirm) but the trail-test admin-API path bypassed /signup, so I had to manually INSERT public.users to simulate it. LLD failure-modes table updated to reflect that the 'no_public_user' edge case is more theoretical than first thought.
• On the first end-to-end run, Kyle created a test signup before flipping WELCOME_EMAIL_ENABLED=true → webhook fired but handler short-circuited with 'kill_switch' (correct behavior). Not a bug, just a sequencing reminder: configure webhook + verify acceptance with flag off, then flip flag, then test.