INFO

This page is BACKLOG.md from the repository, as it stands.

Backlog

Ideas captured for later. Nothing here is committed work or a design decision — each entry records the intent, whatever prior art already exists in the codebase, and the open questions that would need answers before building it.

For what the app does today, see ARCHITECTURE.md; for why it is that way, DECISIONS.md.

---

Mid-trip support

Everything Planet4.Us does today stops at the moment the plan locks. This is the first entry in a category that picks up after that: helping a crew that's already out.

Live participant location on the map

The idea. While a hangout is happening, show where people are on the map so separated parties can find each other. Two granularities, either as a progressive disclosure or as a per-person choice:

• Stop level — "3 people at The Burger Place." Coarse, social, and cheap: you're located at a place in the plan, not at a coordinate.
• GPS coordinate — an actual live position on the map, for the case where someone isn't at a stop yet (walking over, stuck in a cab, lost).

Why it fits. The map pane is already the app's workspace on wide screens and a first-class surface on phones, and it already knows how to draw member pins alongside venue pins. This is the same map answering a different question: instead of where could we go, where is everyone right now.

What already exists to build on.

• An opt-in coarse location pipeline, end to end: the Profile's shareLocation toggle → syncMemberOrigin() → originLat / originLng / originLabel on the member doc → originsFromMembers() → "Coming from" pins with their own legend/filter chip on the map. The consent model, the member fields, the security rule, and the map rendering are all in place.
• That pipeline deliberately publishes a rounded ~1km area, never an exact address, which is the right default for planning but is exactly the precision this feature would need to exceed — a deliberate, separate, and more temporary opt-in.
• Venue-poll options carry lat/lng/placeId, so "at The Burger Place" can be resolved against places the crew already voted on.

Open questions.

• There is no machine-readable event time. The plan stores free-text dates (dateText); plan.date is legacy and never written, and the cleanup sweep keys off inactivity precisely because a real date isn't available. Nothing in the app currently knows when a hangout is "in progress," so mid-trip features need either a real datetime on the plan (see An itinerary builder under Scheduling below) or an explicit "we're out — start sharing" action. The explicit action is probably better anyway: consent to live tracking should be a deliberate act, not something a clock turns on.
• There is no notion of an ordered stop. The plan has one venue plus a flat activities[] — no itinerary of stops to be "at." Stop-level presence needs some structure to attach to.
• Privacy and expiry. Live location is a different consent class from a coarse home area: it should be per-hangout (not a profile setting), time-boxed with an automatic expiry, visibly indicated while active, and killable in one tap. Worth deciding whether a member can share with the group but not with a specific person.
• Cost and battery. Continuous GPS written to Firestore is both a battery and a write-volume concern. Throttling, distance-gated updates, and dropping to stop-level when precision isn't needed are all worth weighing.
• Stop-level detection. Deriving "3 people at The Burger Place" could be geofencing against the venue's coordinates, or simply a manual "I'm here" check-in. Manual is cheaper, more predictable, and avoids the GPS question entirely — possibly the right first version. See Automatic location-based check-ins below, which is the automated end of the same idea.

Automatic location-based check-ins

The idea. Rather than making people tap "I'm here," have arrival at a place in the plan check them in on its own: cross the threshold of The Burger Place and the crew sees you've arrived. Applies to both the plan's venue(s) and the individual stops/activities on it.

Why it fits. It's the payoff for the location plumbing above: a check-in is a single, low-frequency, socially meaningful event rather than a continuous position feed — cheaper to store, far less invasive to share, and useful even to people who'd never turn on live tracking. It also gives the assistant real signal it has never had: the plan is happening, and who has actually shown up.

Shape of it.

• Geofence the coordinates the plan already knows (venue-poll options carry lat/lng/placeId), fire once on entry, post a low-key system message or update a presence row — not a chat spam per person per stop.
• Debounce and de-dupe: one arrival per person per stop, with a dwell threshold so passing by doesn't count, and a manual override for when it misfires.
• Degrade honestly: no permission, no coordinates, or a free-text venue → fall back to the manual "I'm here" tap.

Open questions.

• Background geofencing is the hard constraint. This is a PWA. iOS Safari has no background geolocation and no Geofencing API, so true arrive-while-the-app-is-closed detection is not available on the platform the app most needs it on. Realistic first version is foreground-only (detect on open / while the app is in view), with the manual tap as the everywhere fallback. Worth confirming current platform support before scoping — this may be what decides whether the feature is worth building at all.
• Shares the dependencies above — no machine-readable event time to bound "when should we even be watching," and no ordered stop structure to check in to.
• Who sees it. Arrival is more socially loaded than it looks ("she got there 20 minutes late"). Probably wants to be per-hangout, opt-in, and expiring with the event, like live location.
• Assistant interaction. Check-ins are a natural trigger for the plan status ("everyone's here") — but they must not burn a summary run per arrival. The sponsored-card precedent (client-side only, never written to Firestore) and the existing throttling policy are the models to follow.

---

Scheduling

Planet4.Us's planning tools all assume everything is still up for a vote, and the plan they produce is prose. Both entries here push toward the plan knowing when things actually happen — which is also the dependency every mid-trip entry above runs into.

An itinerary builder — real dates and times on the plan

The idea. A way to make a schedule: give the plan a real start datetime and an ordered list of timed stops ("7:00 dinner at Hermanos → 9:30 show"), or at minimum a way to attach a date/time to the events and activities already on it.

Why it fits. The structured data mostly exists — it just gets flattened into prose at the last step. The calendar widget votes on real ISO dates (d-YYYY-MM-DD option keys in CalendarVote.tsx), the time poll and the hangout's suggestedTimes[] hold real clock times, and venue cards carry lat/lng/placeId. But when a decision lands in the plan it becomes dateText free text; plan.date is legacy and never written. Keeping the winner structured instead of prose-ifying it is the first, cheapest step.

What already exists to build on.

• plan.todos[] is already a list of {key, text, done} — an ordered stops[] with {time?, place?} riding along is the same pattern.
• The Profile collects remind: {week, day, dayOf} toggles that nothing consumes — there is no event datetime to schedule reminders against. A real datetime switches that dormant surface on, along with calendar export (the also-dormant calendar pref) and .ics generation.
• The TTL cleanup sweep keys off inactivity precisely because no real date exists; with one it could archive hangouts after the event actually passes.
• This is the named dependency of both mid-trip entries above ("no machine-readable event time", "no notion of an ordered stop").

Open questions.

• The assistant writes the plan. Plan fields are LLM-drafted free text by design — forgiving of "Friday-ish, 7:30?". A structured datetime needs a schema the model fills reliably, validation on the write path, and a decision about what happens when the chat contradicts the structure.
• Timezones — stored UTC with a hangout-local zone? Everyone's local? Crews are usually same-city, but not always.
• How much structure before it stops feeling chat-first. A full itinerary editor is a different app; a time chip on an activity row is not. Where's the line?
• Write access. Security rules let only the organizer write plan — do stops follow the same posture, or can any member add one (like widget options today)?

Bringing outside events in (concerts, games, shows)

The idea. Some hangouts form around something already scheduled outside the app — a concert, a game, a show. Two ways in, either or both: manually enter a fixed event (date/time/venue are known facts, not poll material), and search a concert/event API the way the venue widgets search restaurants.

Why it fits. Today's widgets assume every dimension is up for a vote. A fixed event inverts that: the when and where are given, and the only real question is who's in — which is exactly what the existing readyCheck widget asks. A fixed-event card is roughly a venueSuggestion card (name/address/coords) plus a start datetime and a ticket link.

What already exists to build on.

• The whole venue-search mold (functions/src/places.ts): server-held API key, rate-limited callables, caching, honest no-key fallbacks. An events provider would be a sibling module, not an extension — Google Places doesn't do events.
• src/sponsored.ts already builds Eventbrite search deep-links (activityTicketsUrl) — the zero-API version of this feature ships today's posture: honest outbound links, AFFILIATE_TAG ready if a partner program is ever joined.

Is there an event API? Yes, several — worth re-verifying terms and quotas at build time, but the landscape as last checked:

• Ticketmaster Discovery API — the obvious first candidate: free API key, broad concert/sports/theater coverage, returns dates, venues (with coords), images, and ticket links. Search by keyword + location + date range.
• SeatGeek — public developer API, similar shape, resale-inclusive.
• Eventbrite — public event search API was retired years ago; only org-owned events are retrievable. It stays a deep-link target, not a search backend.
• Bandsintown — artist-centric and partner-gated; good if the flow is "we all like this artist," bad for "what's on Saturday."
• PredictHQ and similar aggregators — paid/enterprise; overkill here.

Open questions.

• Depends on the itinerary entry above — a fixed event has a real start time, which the plan can't store today. Building this first would just create a second free-text date.
• What does dropping an event into the chat do? Set the plan outright (organizer-only?), or post a card that opens a ready-check and lets the crew confirm? The latter matches "the app suggests; humans decide."
• Ticketing links. Same honesty posture as sponsored CTAs — clearly labeled outbound links, no dark patterns; affiliate revenue only if a real program is joined.
• Coverage honesty. No API covers the long tail (house shows, local markets, a friend's gig) — manual entry is the floor, API search the accelerator, never the other way around.