Captured 2026-06-18 from Nathan's design message after the
auth flow was confirmed end-to-end working (signOut state
reset + inline error banner). Eight distinct features
+ a structural refactor, all original design from Nathan
(verbatim phrasing preserved where the user expressed
opinions; structural recommendations from TARS).
"add a part of the UI where the user can RSVP to a meeting
of the felt faction/session—and there name will populate
the 'who's coming' lst of the briefing page."
The flow: member sees a session (from the Briefing, or a list), taps RSVP, their members.name is added to the "who's coming" list in the BriefingView. The DB write goes to event_attendance (table already exists from the production Felt Faction schema). Status: confirmed.
"the admins should also be able to see the buy in amount
for each user so they can despense the correct amount of
CCs at the start of the session."
Admin view (probably in the Session tab or a new admin sub-tab) lists each RSVP'd member + their buy-in amount. The admin uses this to know how many physical chips to hand out at the table.
"also the admins, should be able to see the pending
inviations on the invite screen. along with having the
ability to cancel invitations."
The existing GenerateInviteView shows the share-sheet text but doesn't list existing pending invites. Add a list view with status (pending / claimed / expired / cancelled) and a cancel button per row. Cancel sets used_at = NOW() with a cancelled reason (or similar marker), or DELETE the row — depends on the production schema's audit policy.
"lets add a season starting amount/new members starting
amount to the settings page for admins. so the admins
can change the amount of CCs a new user starts
with/the amount of CCs all members start with at the
beginning of a season."
New field on the seasons table or a new settings table. Two related knobs:
joins mid-season
(overrides all members' net_worth)
The v1 plan's seasons.starting_chip_allocation already exists in the migration. The new-member case is missing — add seasons.new_member_starting_chips or similar.
"when the user chooses cash out, don't have a choose from
library option—as this allow the user to possibly pick
the same image they had last time. just open the live
camera with prompts on how to take the photo."
UX: remove the "choose from library" PHPicker button from CashoutView. Open AVCaptureSession directly with a viewfinder overlay that has prompts like "Center your stack in the frame. Make sure all chips are visible." No old-photo attack surface.
"also lets tidy up the briefing and session page. the
briefing page should be for RSVPs, the buy in, cash
out. Obviously the buy in option should be avaliable
until the user has rsvp'd and the cash out should be
avaliable until the session/meeting of the felt faction
has at least started—unless the user is an admin,
because they need to test."
"the session page should be for previous sessions.
actually lets rename this to archive or vault. and the
live settlement board should be moved to settings and
only accessable/visible to admins."
Page structure (post-refactor):
admins bypass this for testing)
The MainTabView's tab bar reflects this:
"also display on the standing the current front-runners
for the badges like whale, phoenix etc—and update these
as the badges shift hands. once the season is over the
badges become perminate and get awarded like the whale
of season 1 (2026)—to add a sense of rapport."
StandingView shows, for each award (Phoenix, Veteran, Whale, Drowning), the current front-runner. Updates reactively as net_worth / paid_loans / session_count shift hands mid-season. On season end, the badge is awarded permanently and the page records "The Whale of Season 1 (2026): [member]".
"lets also add a cap for the number of members that can
attend the session—set by the adimins in the settings
page. to try and drive artifical scarsity and give a
sense of exclusivity. also since there is a finite amount
of seats for each meeting of the felt faction—this should
be reflected in the RSVP UI. have a visual of seats
where the gold ones represent the ones that are taken
and the grey ones are the ones the members can RSVP
to claim."
Settings: seasons.max_attendance_per_session (or events.max_attendees). RSVP UI shows a row of seat icons: gold = claimed, grey = available. When full, the RSVP button is disabled and shows "Session full".
decide the order" pattern + incremental-implementation discipline)
Order rationale: structural refactor first (everything else needs the new home), then the new UX features (RSVP is the headline), then the admin surfaces, then the live-data features.
rename, LiveSettlementBoard → Settings** (the structural foundation; everything else lands in the right place)
feature; member cap depends on RSVP, do together)
seat indicator** (the payoff of RSVP; one view change)
logic change)
(small UX change; remove PHPicker)
LiveSettlementBoard)
(extend GenerateInviteView)
cap field** (small field additions to a settings view)
data feature; biggest computation)
you have any further ideas/improvements, let me know")
full, the RSVP button becomes "Join waitlist" instead of disabling. Members are waitlisted in FIFO order. If a member cancels their RSVP, the next waitlisted member is auto-promoted + gets a Felty-voiced push notification ("A seat opened up. The House has your name."). The seat visual would show a third color (e.g., silver) for waitlisted seats.
admin buy-in view should also show:
have already been recorded as working hand increments) This gives the admin a one-screen view of the table state.
cash-out flow should record:
cashout_submitted_at (when the photo was taken)cashout_calculated_at (when the vision came back)cashout_finalized_at (when the admin approved)cashout_status (submitted / processing / disputed/ finalized) The admin sees a per-member status: "Olivia: pending review" / "Bob: submitted 3 min ago" / "Connor: finalized, +412 CC".
support:
"All sessions")
This makes the archive useful as a personal history (member's own season-end P&L) AND a global view (admin checking past performance).
Standing page should show, for each award:
members who are already locked out, e.g., the member with the lowest net worth is unlikely to catch up to the Whale front-runner in the remaining season time)
runner-up, so the visual shows the contest) This is a "sense of drama" feature — the user explicitly mentioned "a sense of rapport" (probably meant "rivalry"). Live data + visual stakes = great retention.
v10 features; Felty should speak on:
the claim.")
The House is patient.")
The House is watching.") The v1.5 (Felty voice system) is the right home for these — add to FeltyTemplate.swift as new enum cases.
The v1 plan's Phase 2 (Session lifecycle) is the implementation surface for most of this. The original v1 plan had buy-in/cashout as the v0 minimum; the v10 additions are the v1+ feature set. The refactor (renaming Session → Archive, moving LiveSettlementBoard to Settings) is closer to a v1.5 polish.
This isn't a small bug fix or a single feature — it's a coordinated batch of 8 features + 1 structural refactor. The user is signaling:
the "you decide the order" pattern, the LLM executes; per this message, the LLM also gets to propose ideas)
The signal-detector skill's "build session behavior" applies: focus on the work, use timeline entries for milestones, don't push ambient capture, actually make the changes described. The user is gone (or about to be), the design is captured, the work begins.
Published and managed by TARS, an AI co-author built on Nathan's gbrain.