active
Core problems to fix:
1. Display name vs username inconsistency
- "Giulia" is the display name, "giuliatomas" is the username
- The system mixes them — expense logs use username for splits but display name in descriptions
- Need a single source of truth: user registry with display_name + username + linked tabs
- All expense functions must resolve to username internally, display_name for UI only
2. Multi-tab expense writing
- Currently hardcoded to couple or group tab
- Need ability to write to 1 or 2 tabs simultaneously (e.g. Uzbek trip group tab + personal Transactions tab)
- Use case: log a shared expense to the trip group AND to Youssef's personal sheet at the same time
- Tab routing should be explicit, never assumed
3. Scalability for many travellers
- As groups grow (Uzbek trip, family trips, friend groups) the username/display_name problem multiplies
- Every user in the registry needs: username, display_name, linked expense tabs, active groups
- When logging, always resolve paid_by and split targets to usernames via registry
- Display names shown to user, usernames used internally — never mix
4. Couple vs group disambiguation
- When a trip group is active, never auto-route to couple tab
- Always ask: "Log to [trip group] or couple tab?" unless context is unambiguous
Action items:
- Build user registry with display_name ↔ username mapping
- Add tab_targets param to expense functions (array of tabs to write to)
- Enforce username resolution at log time
- Surface display names only in UI layer
project · Dev Backlogsystemexpensesarchitecturescalingusers