BACKLOG — Bike-Tinder

Glenn's "later versions" idea queue. He drops ideas in conversation; they land here (near-verbatim + a scope sketch + open questions), and get built in a future version — never mid-phase. Newest first.

v1.1 — QOL wishlist (drafted 2026-11-12; feasibility triaged same day; build awaits Glenn's go-ahead)

Glenn's words: "Going to go through a laundry list of fixes before we do lets say 1.1?" — nothing here is started.

Shortcuts

Arrow keys: Left = Nope, Right = Like, Up = Maybe, Down = back one (read as: undo the last swipe — confirm at spec time). Esc = exit fullscreen views.
Feasibility: trivial — keyboard invokes the exact actions gestures/buttons already call (undo exists). Care: ignore keys while a text input has focus; prevent arrow-key page scroll. Desktop/Bluetooth-keyboard benefit only; the app is reachable from any tailnet device (MacBook included).

UI changes

Tap flow — info first, then photos. Center tap opens the fullscreen bike data view (today it opens the photo); tapping the photo there opens the fullscreen image viewer. Side taps keep flipping photos on the card. Esc/back pops viewer → data → deck. Resolves "can't get info unless I hit the ⓘ button." Revisit UI-SPEC.md §11 tap map before build (v1.1 spec bump).
Photo fit: fill → contain. Show photos uncropped — no "zoomed" crops. One CSS property; visual tradeoff = dark letterbox bars. Open question: viewer only, or the card stack too? Explained to Glenn 2026-11-12 with a 3-panel demo (fill vs contain vs contain+blurred backdrop — ~/dev/bike-tinder-demos/fit-vs-fill.html); awaiting his choice.
Rubric display goes minimal. Show ONLY the gas-tank gauge + percent full (e.g. "76%"); drop the rest of the rubric-fit display in bike views — plus a setting that re-enables the full "why" breakdown for debugging (Glenn, 2026-11-12; wire via the existing prefs key/value API — same pattern as forge_mode).

Analytics phase (post-1.1; notes per Glenn 2026-11-12)

Glenn's words: "take in just about all interactions… how long I have looked at each picture, how many pictures I flipped through, how quickly I swiped… kept on an individual bike perspective and fed to the model for further accuracy" + "start the database from scratch, giving myself a new start."

Capture (local-only, per bike): dwell time per photo, flips (count/order), decision latency (card visible → swipe), maybe/undo/list-edit events, session id; card-dwell vs fullscreen-dwell as separate signals.
Store: new append-only interaction_events table (same pattern as swipe_events); batched client flush (sendBeacon/pagehide); iOS PWA: pause dwell clocks on visibilitychange so background time can't pollute.
Feed the model: nightly agent pass consumes per-bike aggregates as extra taste features. HARD LAW unchanged: no LLM in the swipe path — capture is write-only until the nightly read.
Reset: its own phase (separate from v1.1), paired with a from-scratch DB reset so telemetry starts clean on the new ledger. Scope to confirm: wipe swipes + events + profile only (listings/catalog stay — re-import is idempotent); legacy data stays in data/backup/ archives.
Open questions: reset scope; raw events forever vs aggregate-and-prune; include list-browsing events; surface any of it in the UI (probably not).

Gallery mirror gap (found 2026-11-12, filing for a later phase)

Verified while preparing the fit/fill demo: the local image mirror (data/img/{id}.webp) holds primaries only. Gallery photos beyond the first (/img/{id}?i≥1) serve a 302 redirect to the Kijiji CDN — not hedged locally. If an ad is deleted we keep photo 1, but the gallery (often where the good shots are) is gone. Fix options for a later phase: mirror galleries on import/first-touch (estimates in the B1 notes: roughly +350–600 MB for the full catalog — fine for the mirror volume), keep the redirect as fallback. Not urgent; filed so it is not forgotten.

Dry-pool UX + agent feedback (noted 2026-11-12)

Glenn hit a fully-reviewed catalog: 563/563 actives decided → fresh pool = 0 → forges returned 2-card returns-only sections ("stuck on a couple bikes"), and "Run agent now" looked inert (a pass ran, but the deck can't change without fresh listings). Possible polish: (a) report/forge state says "catalog fully reviewed — fresh listings arrive with the next import" instead of silently dripping 2 cards; (b) agent button shows a richer confirmation (profile version + lean delta); (c) re-open "second look" eligibility or widen the wildcard pool when the catalog is dry; (d) a "review your Maybes" shortcut at exhaustion. Related: the nightly import + nightly agent read make the pool self-refreshing (Phase 4).

B1 · Photo experience v2 — multi-image galleries, photo swipe, fullscreen viewer

Queued 2026-11-10 (during the P3 build; for the version after it). PULLED FORWARD 2026-11-10; SHIPPED 2026-11-11 — built, verified (walk 390/390, selfcheck 31/31), LIVE on :9453; see PLAN.md. Spec frozen in UI-SPEC.md §11 + DATA-MODEL.md B1 additions.

Glenn's words: "more pictures! As many pictures as we can get honestly. I'd like to swipe through them left and right like tinder does. One repeats, the image should change as to not tip me off." · "I'd like to tap the image to 'full screen' it so I can see it better."

Scope sketch:

Capture every gallery photo. Today the pipeline keeps ONE image per listing. Verified 2026-11-10: Kijiji detail pages expose the full gallery (probe — 2026 Sport Scout page: 8 unique images; Scout Sixty Bobber: 3). The image tool already opens each listing's page when filling photos — it just keeps the first image. Extension = grab all unique gallery images (dedupe by image uuid, keep page order). State gains imgs: [...] beside img; DB carries the photo list; the mirror downloads all (sizing rule unchanged: ?rule=kijijica-640-webp). Storage estimate: ~640 listings × ~5–10 photos × ~70–120 KB ≈ 350–600 MB — fine for the mirror.
Photo swipe on the card — Tinder-style: tap-left / tap-right zones advance photos (segment indicators on the photo's top edge); horizontal drag stays LIKE/NOPE — the no-lock law outranks everything.
Fullscreen viewer — tap the image → fullscreen photo (pinch-zoom, swipe through the gallery, pull/✕ to close); works from the deck card and the dossier hero.
Repeat handling — "the image should change so it doesn't tip me off." Two readings to settle at spec time with Glenn:
- (a) when a card repeats (second look / re-listed ad), lead with a different photo than the one previously shown, so the repeat doesn't read as déjà vu;
- (b) dedupe/rotate so the same photo never repeats twice in a row within or across a swipe session. Both are cheap once galleries exist; ask which was meant at spec time.
Gesture-map tension to resolve at spec: today a tap on the card opens the dossier, and Glenn now wants tap = fullscreen; Tinder's model taps to advance photos. The exact zone map (tap-left/right = photo, center/ⓘ = dossier vs fullscreen) is a spec-time design session with Glenn. Dossier remains reachable from ⓘ and list rows either way.

Settled 2026-11-10 (Glenn, in chat): gesture map = tap sides flip photos · tap center fullscreen · ⓘ details. Repeat handling = lead with a different photo each time (rotation). Frozen in UI-SPEC.md §11.

Not for P3 — nothing here blocks or alters the current phase. Forward-compatible: gallery segment indicators and the P3 card bands (§10.3) must share the card's top area; the stack/drag engine is untouched.

Other v2+ seeds already live where they were planted: distance feature (RANKING.md open decisions) · AUTH_TOKEN hardening (DESIGN.md security) · Facebook paste-the-link box (SOURCES.md) · weekly digest, "hide this seller" (RANKING.md / DESIGN.md risk notes).

7.9 KiB Raw Blame History Unescape Escape