# Simpler Sport Full LLM Guide This file combines the public LLM-facing Simpler Sport documentation into one Markdown document. The source documents remain available individually under /docs/llms/. # Comprehensive Guide Source: /docs/llms/simpler-sport-guide.md ## Product Overview Simpler Sport is for organizing adult amateur sports teams. It centers on a team roster, scheduled fixtures, RSVP availability, guest invitations, and simple team polls. Use these product terms: - Team. - Roster. - Person. - User. - Membership. - Fixture. - RSVP. - Poll. - Organizer. - Guest. Do not describe Simpler Sport as a league management system unless the user specifically provides that context. The product behavior shown here is team-level organization. ## Core Model A Team contains: - A roster. - A schedule of fixtures. - Polls. - Organizer settings. - Minimum-player requirements. A Roster contains Memberships. A Membership connects one Person to one Team and defines: - Role: Player, Guest, or Non-Player. - Organizer rights. - Owner status. - Archived status. A Person is the participant identity. A User is a sign-in account. A Person can exist without a User account and still receive RSVP or poll messages. ## Roles Player: - Regular active participant. - Included in fixture availability. - Always included in polls. Guest: - Backup or extra player. - Can be invited when more players are needed. - Optional poll recipient. Non-Player: - Not active for fixture availability. - Optional poll recipient. Organizer: - A registered team member with organizer rights on their Membership. - Can manage team settings, roster, fixtures, polls, invitations, and team finances. Owner: - The Membership that owns the team. - Must be an organizer. - Can delete the team. ## Teams And Settings Important team settings: - Co-ed team flag. - Minimum players per game. - Co-ed male/female minimums. - Team time zone. - Default RSVP behavior. - Default RSVP display order. - Event preview setting. Default RSVP behavior has two modes: - Players reply for every event: Players start as No Response. - Assume everyone is playing unless they opt out: Players start as Yes. Default RSVP display order has two modes: - Alphabetically by name. - By status and response time. When sorted by time, RSVP lists use this status order: Yes, Maybe, No, No Response. Within each status, earlier response updates appear first. ## Fixtures A fixture is a scheduled team item. It is either: - Game: has an optional opponent and home-team flag. - Event: has an optional description instead of an opponent. Fixture fields: - Date. - Optional time. - Optional duration. - Optional location. - Optional notes. - Days before fixture to request RSVPs. - Canceled state and cancellation details. Time behavior: - If no time is set, the fixture displays as Time TBD. - If time is set and duration is blank, duration defaults to 60 minutes. Creating a fixture creates RSVP entries for roster memberships. Adding a roster member later creates RSVP entries for that member on future fixtures. ## RSVP Values Allowed RSVP values: - Yes. - Maybe. - No. - No Response. Meaning for games: - Yes: Playing. - Maybe: Maybe Playing. - No: Not Playing. - No Response: Unknown. Meaning for non-game events: - Yes: Going. - Maybe: Maybe Going. - No: Not Going. - No Response: Unknown. Some teams allow Maybe. Some teams only use Yes and No. A response button cycles according to the team's configured RSVP flow. RSVP notes: - Optional. - Up to 140 characters. - Can be edited independently from status. ## Attendance And Backups Attendance counts are grouped by Yes, Maybe, No, and No Response. Counting rules: - Players are in scope for attendance. - Guests are separate from Players. - A Guest is counted after responding. - Once Guests are invited, Guest No Response entries are also counted. - Non-Players are not active for fixture attendance. Minimum-player checks: - Yes responses count toward the minimum. - Maybe responses do not satisfy minimum-player requirements. - Co-ed teams can require minimum male and female Yes counts. Guest workflow: - Use Guests when more players are needed. - Organizers can invite all Guests or invite one Guest. - Invited Guests are marked as invited. ## Over-Subscription Simpler Sport does not enforce maximum roster or fixture capacity. It does not automatically move late Yes responses to a waitlist. When too many Players respond Yes: - Use the fixture's Player RSVP list. - If the team uses time-priority sorting, read Yes responses in order from earliest to latest. - The organizer decides who plays and communicates any backup decision. Example: - The organizer needs 10 Players. - 13 Players answered Yes. - In time-priority sorting, the first 10 Yes entries are the earliest Yes responses. - The other 3 remain Yes unless an organizer or player changes them. ## Polls A poll is a team yes/no/maybe question. Poll fields: - Question, up to 100 characters. - Optional supporting details, up to 400 characters. - Recipient scope. - Expiration. Recipient rules: - Players are always included. - Guests can be included. - Non-Players can be included. Poll behavior: - Polls create one poll response for each included Membership. - Polls are open for seven days by default. - Open polls accept response and note changes. - Closed polls do not accept voter changes. - Organizers can end a poll early, reopen an expired poll for seven days, nudge non-voters, and delete a poll. Poll response values: - Yes. - Maybe. - No. - No Response. ## Notifications Messages can be sent by Email or Text depending on each Person's communication channel. Main notification types: - Fixture RSVP invitation. - Final fixture reminder. - Changed-fixture reminder. - Event preview. - Minimum-player alert to organizers. - Guest invitation. - Player nudge. - Poll invitation. - Poll nudge. - Cancellation notice. - Late RSVP change alert to organizers. - Post-event summary request and summary. Communication rules: - Email requires an email address. - Text requires a mobile number. - Don't Send Any suppresses event invites. - Email and text unsubscribe states are respected. - Unreachable people are not sent ordinary reminders. ## Late Changes A late RSVP change is a status change after the event preview has been sent while the fixture is still active. Behavior: - RSVP counts update immediately. - Organizers can receive a late-change alert. - Note-only changes do not trigger late-change alerts. - The alert is delayed briefly and checks the current status before notifying. ## Cancellations Organizers can cancel fixtures. Game cancellation reasons: - Weather. - Opposition Forfeited. - We Forfeited. - Other. Non-game event cancellation reasons: - Weather. - Not Enough People. - Other. Cancellation behavior: - The fixture remains visible as canceled. - The cancellation can include a note up to 400 characters. - Cancellation notices are sent to relevant people based on prior invitations, responses, and Guest invitation state. ## Access Summary Anonymous visitors: - Have no general team access. - May use specific response links. Known people: - Can view dashboard, team schedule, event pages, and poll pages for teams they belong to. - Can respond to their own RSVPs and poll responses. - Cannot view private roster contact details unless registered and signed in. Registered users: - Can access registered-only areas for teams they belong to. - Can view roster contact details. Organizers: - Must be registered users. - Can manage roster, fixtures, polls, invitations, settings, and finance areas. Owner: - Can delete the team. --- # Concept Glossary Source: /docs/llms/concepts.md ## Team Definition: A team is the main organizing space for an adult amateur sports group. Key attributes: - Name. - Optional website URL and description. - Time zone. - Co-ed setting. - Minimum confirmed players per game. - Optional minimum male and female player counts for co-ed teams. - Default RSVP behavior: - Players reply for every event. - Or assume players are playing unless they opt out (this option is rarely used) - Default RSVP display order: - Alphabetically by name. - Or by status and response time (this is most sometimes used for pickup sessions). - Event preview setting. Relationships: - Has one roster. - Has many fixtures. - Has many polls. - Has organizers through roster memberships. - Has one owner through a roster membership. ## Roster Definition: The roster is the team membership list. Key attributes: - Grouped by role: Player, Guest, Non-Player. - Can show archived members. - Can be searched by name. - Can be exported to CSV. - Can expose email actions for everyone or for a specific role. Relationships: - Contains Membership entries. - Each Membership connects one Person to one Team. - Organizers manage the roster. ## Person Definition: A Person is the product identity for someone on one or more rosters. Key attributes: - First name and surname. - Optional nickname. - Optional email. - Optional mobile number. - Optional gender. - Optional birthday. - Optional notes. - Communication channel: Email, Text, or Don't Send Any. - Email and text unsubscribe state. Relationships: - Can have memberships in multiple teams. - Can have RSVP responses for fixtures through memberships. - Can have poll responses through memberships. - May correspond to a registered User account when emails match. ## User Definition: A User is a registered sign-in account. Key attributes: - Email. - Password. - Email confirmation state. - Site-admin flag for application administration. Relationships: - A User is associated with a Person by matching email. - A User becomes a team organizer only when the matching Person has organizer rights on that team. ## Identity States Definition: Simpler Sport recognizes three levels of identity. States: - Anonymous visitor: no known Person and no signed-in User. - Known person: a browser has been associated with a Person, usually through lookup or a response link, but is not signed in. - Registered user: a signed-in User whose email matches a Person. Relationships: - Known people can view their own dashboard and team/event/poll pages when they belong to the team. - Registered users can access additional private areas such as roster contact details. - Organizer powers require a registered user whose Person has organizer rights on the team. ## Membership Definition: A Membership connects a Person to a Team. Key attributes: - Role: Player, Guest, or Non-Player. - Organizer rights. - Owner flag. - Archived status. Relationships: - Belongs to one Team. - Belongs to one Person. - Has RSVP entries for team fixtures. - Has poll response entries for team polls. Behavior: - New memberships receive RSVP entries for future fixtures. - Archived memberships are removed from the active roster but can be shown and unarchived. - The team owner must also have organizer rights. - The owner cannot be archived through normal roster management. ## Roles Definition: Roles describe how a roster member participates in scheduling and communication. Allowed roles: - Player: A regular player. Players are included in fixture RSVP requests and required in every poll. - Guest: A backup or extra player. Guests can be invited when more players are needed and can optionally be included in polls. - Non-Player: A roster contact who is not active for fixture availability. Non-Players can optionally be included in polls. Relationships: - A Membership has exactly one role. - RSVP and attendance counts distinguish Players from Guests. ## Organizer And Owner Definition: An organizer is a registered team member with organizer rights. The owner is the special organizer who owns the team. Organizer capabilities: - Edit team settings. - Add, copy, edit, archive, and unarchive roster members. - Create, edit, import, and cancel fixtures. - Invite players and guests. - Send nudges. - Create, close, reopen, delete, and nudge polls. - View private roster contact details. Owner capabilities: - All organizer capabilities. - Delete the team. Relationships: - Organizer rights live on a Membership. - A User account alone does not grant organizer powers. ## Fixture Definition: A fixture is a scheduled team item. It can be a game or a non-game event. Key attributes: - Date. - Optional time. If no time is set, the fixture displays as Time TBD. - Optional duration. Timed fixtures default to 60 minutes. - Type: Game or Event. - Game fields: opponent and home-team flag. - Event fields: description. - Optional notes. - Optional location. - RSVP request timing in days before the fixture. - Canceled state, cancel reason, cancel note, and canceling person. Relationships: - Belongs to one Team. - Has RSVP entries for team memberships. - May belong to a repeating event series. - May have a post-event summary/report. Behavior: - Creating a fixture creates RSVP entries for current roster memberships. - Adding a roster member later creates RSVP entries for that member for future fixtures. - Editing date, time, or a previously set location marks the fixture as changed. - Editing a fixture that belongs to a repeating series separates that fixture from the series. - Canceling a fixture keeps the fixture visible as canceled and sends cancellation notices to relevant people. ## Repeating Event Definition: A repeating event creates a series of non-game events. Key attributes: - Start date. - End date. - Repeat frequency. - Repeat period: days, weeks, or months. - Optional time, duration, description, notes, and location. - RSVP request timing. Relationships: - Belongs to one Team. - Owns the generated future fixtures. Behavior: - Creating a repeating event creates child fixtures. - Updating the repeating event updates future child fixtures. - Moving the start or end date later removes child fixtures outside the new range. - Deleting the repeating event deletes its child fixtures. ## RSVP Definition: An RSVP is a person's availability response for one fixture. Allowed values: - Yes: available. Displayed as Playing for games and Going for non-game events. - Maybe: uncertain. Displayed as Maybe Playing for games and Maybe Going for non-game events. - No: unavailable. Displayed as Not Playing for games and Not Going for non-game events. - No Response: no answer yet. Displayed as Unknown. Key attributes: - Status. - Optional note, up to 140 characters. - Invitation timestamp for Guests. - Communication phone number used for text replies, when applicable. Relationships: - Belongs to one Fixture. - Belongs to one Membership. - Inherits Person, Team, and Role through its Membership and Fixture. Behavior: - RSVP counts update when statuses change. - A person's RSVP button cycles to the next allowed status based on the team's RSVP flow. - Some teams allow Maybe; some teams only allow Yes and No. - A late status change after the event preview has been sent can notify organizers. ## RSVP Counts And Attendance Definition: Attendance is the fixture-level summary of RSVP responses. Key attributes: - Counts for Yes, Maybe, No, and No Response. - For co-ed teams, counts can include male/female breakdowns. Rules: - Players are always in the attendance scope. - Guests are counted once they respond. - If all Guests have been invited, Guest No Response entries are included in counts. - Non-Players are not active for attendance. - A team has enough players when confirmed Yes responses meet the total minimum and, for co-ed teams, the configured gender minimums. ## Poll Definition: A poll is a team question answered with the same response set as RSVP. Key attributes: - Question, up to 100 characters. - Optional supporting details, up to 400 characters. - Open or closed state based on expiration. - Sent timestamp. - Optional nudge timestamp. - Recipient scope flags for Guests and Non-Players. Relationships: - Belongs to one Team. - Has one poll response per included membership. Behavior: - Players are always included. - Organizers may include Guests and Non-Players. - Polls expire after seven days by default. - Closed polls cannot be modified by voters. - Organizers can end a poll early, reopen an expired poll for seven days, nudge non-voters, and delete a poll. ## Poll Response Definition: A Poll Response is one person's answer to one poll. Allowed values: - Yes. - Maybe. - No. - No Response. Key attributes: - Status. - Optional note, up to 140 characters. Relationships: - Belongs to one Poll. - Belongs to one Membership. Behavior: - A voter can change their response while the poll is open. - Organizers can update visible poll responses while the poll is open. - Archived member responses remain visible in poll results. ## Reminders And Notifications Definition: Notifications are outbound email or text messages sent for team activity. Types: - Fixture RSVP invitations. - Final fixture reminders. - Changed-fixture reminders. - Event previews. - Minimum-player alerts to organizers. - Guest invitations. - Individual Guest invite-now messages. - Player nudges. - Poll invitations. - Poll nudges. - Cancellation notices. - Late RSVP change alerts to organizers. - Post-event summary requests and summaries. Rules: - Messages follow each Person's communication channel. - A Person set to Don't Send Any does not receive event invites. - Unsubscribed email or text channels are not used. - If text delivery cannot be prepared because no sending number is available, the product can fall back to email when the Person has email. --- # Workflows Source: /docs/llms/workflows.md ## Create A Team 1. A registered user starts a new team. 2. Enter the team name. 3. Choose whether the team is co-ed. 4. Set the team time zone. 5. Optionally open advanced settings: - Description. - Team website URL. - Minimum players per game. - Co-ed male/female minimums. - Default RSVP display order. - Default RSVP behavior. 6. Submit the team. 7. System behavior: - The team is created. - The creator is added to the roster as a Player. - The creator is marked as owner and organizer. Decision points: - If the team assumes everyone is playing unless they opt out, Players default to Yes for fixtures. - If Players reply for every event, Players default to No Response for fixtures. - If RSVP display order is Time, RSVP lists show Yes, Maybe, No, then No Response, with response-time order inside each status. ## Add A Roster Member 1. A registered organizer opens the team roster. 2. Choose Add to Roster. 3. Enter the Person fields: - First name. - Surname. - Optional nickname. - Optional gender. - Optional email. - Optional mobile. - Communication channel. 4. Choose the Membership role: - Player. - Guest. - Non-Player. 5. Optionally open advanced settings: - Notes. - Birthday. - Organizer rights. 6. Submit the member. 7. System behavior: - If the email or mobile matches an existing Person, the Membership uses that Person. - If the Person is already active on the team, the product reports that they are already a member. - If the Person was archived on the team, the product unarchives them and applies the selected role and organizer setting. - The new Membership receives RSVP entries for future fixtures. - If invitations were already sent for a future fixture, the new active member can receive relevant pending invites. Decision points: - Choose Player for regular availability tracking. - Choose Guest for backups or extra players who are invited when needed. - Choose Non-Player for a roster contact who should not be active for fixture availability. - Choose Don't Send Any when the Person should not receive event invites. ## Copy Members To A Roster 1. A registered organizer who manages more than one team opens the target team roster. 2. Choose Copy to Roster. 3. Select people from other teams the organizer manages. 4. Choose the role to copy them as. 5. Submit the copy action. 6. System behavior: - People already active on the target team are reported as duplicates. - Archived target-team memberships are unarchived. - New target-team memberships are created for eligible people. - People outside the organizer's managed teams are rejected. ## Import Roster Members From CSV 1. Prepare a CSV with columns in this order: - First name. - Surname. - Email. - Mobile. - Notes. - Role. 2. Use role values: - Player. - Guest. - Any other value maps to Non-Player. 3. Import the CSV for a team. 4. System behavior: - Each row is treated like an Add to Roster action. - Email or mobile can match an existing Person. - Communication channel defaults to Email if email is present, Text if only mobile is present, and Don't Send Any if neither is present. ## Create A Fixture 1. A registered organizer opens the team schedule. 2. Choose Add, then select: - a Game. - an Event. - a Repeating Event. 3. For a single Game or Event, enter: - Date. - Optional time or Time TBD. - Optional duration when time is known. - Opponent for a Game, or description for an Event. - Optional notes. - Optional location. - Days before the fixture to request RSVPs. 4. Submit the fixture. 5. System behavior: - The fixture is added to the schedule. - RSVP entries are created for current roster memberships. - Timed fixtures default to 60 minutes if no duration is selected. - RSVP reminder and preview timings are scheduled from the fixture date, team time zone, and days-before setting. Decision points: - Use Game when the scheduled item is a match against an opponent. - Use Event for practices, scrimmages, socials, or other non-game activities. - Use Time TBD when the time is not known. ## Create A Repeating Event 1. A registered organizer opens the team schedule. 2. Choose Add, then a Repeating Event. 3. Enter: - Start date. - End date. - Repeat frequency. - Repeat period: days, weeks, or months. - Optional time, duration, description, notes, and location. - Days before the event to request RSVPs. 4. Submit the repeating event. 5. System behavior: - The product creates non-game fixtures across the date range. - Updating the repeating event updates future child fixtures. - Editing one child fixture directly separates that fixture from the repeating series. ## Request RSVPs 1. Create a future fixture. 2. Confirm the team has active Players with reachable communication settings. 3. Wait for the scheduled invitation time or, as an organizer, choose Invite Players Now when available. 4. System behavior: - RSVP invitations are sent to reachable Players. - Organizers receive a summary of sent and unsubscribed invite recipients when invites are sent. - A fixture can show when Players were first invited. - If fixture details change after invites, the fixture is marked as changed. - Changed fixtures can send updated reminder language. Decision points: - Invite Players Now is available before scheduled invites, or after invites when important details changed. - For opt-in teams, invites are only needed when Players still have No Response. - For opt-out teams, Players can already default to Yes, but invites are still used to confirm or update availability. ## Interpret RSVP Responses 1. Open a fixture. 2. Review the RSVP summary: - Yes. - Maybe. - No. - No Response. 3. For games, read Yes as Playing, Maybe as Maybe Playing, No as Not Playing, and No Response as Unknown. 4. For non-game events, read Yes as Going, Maybe as Maybe Going, No as Not Going, and No Response as Unknown. 5. Review Player and Guest sections separately. 6. System behavior: - Player responses drive ordinary attendance planning. - Guest responses are shown separately. - Guest No Response entries are counted only after Guests have been invited, unless that Guest already responded. - Co-ed teams show male/female counts where gender is known. Decision points: - If confirmed Yes count is below the team's minimum, the team does not yet have enough players. - If a co-ed team has enough total Yes responses but not enough male or female Yes responses, it still does not meet the configured minimum. - Maybe is not the same as Yes for minimum-player checks. ## Handle Over-Subscription Simpler Sport does not enforce a maximum player cap. It helps organizers interpret priority. 1. Open the fixture. 2. Confirm the team setting for default RSVP display order. 3. If the display order is Time: - Review the Player list. - Read statuses in this order: Yes, Maybe, No, No Response. - Within each status, earlier updates appear before later updates. 4. Use the ordered Yes list as the response-time priority list. 5. Decide manually who plays if too many Players said Yes. 6. Use Guest responses separately; do not mix Guests into Player priority unless the organizer chooses to. Example: - A team needs 10 players and 13 Players answered Yes. - With time-priority sorting, the first 10 Yes responses are the earliest Yes responses. - The remaining 3 Yes responses are not automatically changed to Guest or No; the organizer must communicate the decision. ## Invite Guests When More Players Are Needed 1. Open the fixture. 2. Review Player RSVP counts. 3. If more players are needed, expand the Guests section. 4. Choose Invite Guests to invite all uninvited Guests, or Invite Now for an individual Guest when available. 5. System behavior: - Guest invitations ask whether the Guest can help out. - Invited Guests are marked as invited. - Once all Guests are invited, Guest No Response entries are included in fixture counts. Decision points: - Use Guests for backup availability, not as regular Players. - A Guest who answers Yes or Maybe is visible even before all Guests are invited. ## Send A Player Nudge 1. Open the fixture as an organizer. 2. Confirm Player invitations were sent at least 24 hours ago. 3. Confirm no nudge was sent in the last 24 hours. 4. Confirm there are active Maybes or Player No Responses. 5. Choose Nudge. 6. Optionally enter the nudge message. 7. Submit. 8. System behavior: - Nudges are sent to active Maybes and Players with No Response. - Guests with No Response are not nudged by the player nudge flow. - The fixture keeps the last nudge time. ## Manage Late Availability Changes 1. A fixture preview is sent shortly before the fixture. 2. A Person changes their RSVP status after the preview while the fixture is still active. 3. System behavior: - RSVP counts update immediately. - A late-change alert is queued for organizers. - Note-only changes do not trigger late-change alerts. - If the Person changes status again before the alert is sent, the alert uses the current status before notifying. Decision points: - Treat late Yes-to-No and No-to-Yes changes as organizer-relevant. - Do not treat note edits alone as availability changes. ## Send A Poll 1. A registered organizer opens the team polls area. 2. Choose New Poll. 3. Enter a short yes/no/maybe question. 4. Optionally add supporting details. 5. Choose recipients: - Players are required. - Guests are optional. - Non-Players are optional. 6. Send the poll. 7. System behavior: - Poll responses are created for included memberships. - The poll is sent to reachable people who have No Response. - The poll is open for seven days by default. Decision points: - Phrase the question so Yes, Maybe, and No are meaningful. - Include Guests only when their answer is relevant. - Include Non-Players only when the question applies to them. ## Interpret Poll Results 1. Open the poll. 2. Check whether it is Open or Closed. 3. Review summary counts for Yes, Maybe, No, and No Response. 4. Review the Votes list for individual responses and notes. 5. Filter by status if needed. 6. System behavior: - Voters can change answers while the poll is open. - Closed polls show results but cannot be modified by voters. - Archived member responses remain visible in results. ## Nudge, Close, Reopen, Or Delete A Poll 1. Open a poll as an organizer. 2. To nudge: - Wait until the poll is at least two days old. - Confirm it is still open. - Confirm non-voters remain. - Confirm no previous poll nudge was sent. - Choose Nudge. 3. To close: - Choose End Poll. - The poll expires immediately and ignores further votes. 4. To reopen: - Use Re-Open on an expired poll. - The poll is extended for seven days. - The prior nudge marker is cleared. 5. To delete: - Choose Delete. - The poll and its responses are removed. --- # Permissions And Identity Model Source: /docs/llms/permissions.md ## Identity Levels Simpler Sport distinguishes identity from registration. Anonymous visitor: - Has no recognized Person. - Is sent to the start/lookup flow for dashboard access. - Can use some response links that identify a specific RSVP or poll response. Known person: - Has a recognized Person in the current browser. - May be recognized by entering a known email or mobile number. - May be recognized after using an email response link. - Is not the same as a registered user. Registered user: - Is signed in with a confirmed account. - Is associated with a Person when the account email matches a Person email. - Can access private areas that require registration. ## Person vs User Person: - Represents the real participant on a roster. - Holds contact details, communication preferences, notes, gender, and memberships. - Receives RSVP entries and poll responses through memberships. User: - Represents sign-in credentials. - Does not by itself grant access to a team. - Must match a Person who belongs to the team. Example: - A Person can be on a roster and receive RSVP emails without having a User account. - A User can sign in but cannot manage a team unless the matching Person has organizer rights for that team. ## Team Access Team pages: - Require the current identity to be a Person on that team. - Anonymous visitors are redirected away. - Known people who belong to the team can view team schedule, event, and poll contexts. Roster: - Requires a registered user who is a member of the team. - Known people who are not signed in see a prompt to sign in or create an account. - Roster contact details are private to signed-in team members. Event pages: - Require the current identity to be a Person on the event's team. - Known people can view event pages. - Event reports are gated to registered users. Poll pages: - Require at least a known Person. - Known people can view and answer their own poll responses. - Anonymous visitors are redirected to the start flow unless they are using a response link. ## Response-Link Access RSVP response links: - Can identify one RSVP. - Can set that RSVP to Yes, Maybe, or No. - Can establish the browser as the RSVP owner's known-person session. - Should not be treated as general team access. Poll email response links: - Can identify one poll response. - Can set that poll response to Yes, Maybe, or No. - Can establish the browser as the poll response owner's known-person session. - Cannot modify a closed poll. SMS replies: - Are matched by sender phone number and the phone number used for the conversation. - Valid RSVP and poll commands include yes/y, no/n, and maybe/m. - Other SMS commands include next, schedule, roster, where, map, help, hello, and thanks. - Unknown senders are ignored. ## Actions Requiring A Registered User The following require sign-in: - Create a team. - View roster contact details. - Export a roster. - View member detail pages. - Create fixtures. - Edit fixtures. - Cancel fixtures. - Create repeating events. - Import schedules. - Create polls. - Manage polls. - Manage roster members. - Manage finances and payment instructions. - Edit a Person account page. ## Actions Requiring Organizer Rights The following require a registered user whose Person has organizer rights on the team: - Edit team settings. - Add roster members. - Copy roster members from another managed team. - Edit roster members. - Archive and unarchive roster memberships. - Create, edit, import, and cancel fixtures. - Create and manage repeating events. - Invite players. - Invite Guests. - Send fixture nudges. - Create, nudge, close, reopen, and delete polls. - Manage team finances and payment settings. Organizer rights belong to a Membership, not to the User account alone. ## Owner Rights The team owner: - Is a Membership marked as owner. - Must also have organizer rights. - Can delete the team. - Cannot be archived through normal roster management. If a non-owner organizer attempts to delete the team, the product blocks the action. ## Regular Member Rights A regular member can: - View their dashboard when known or signed in. - View teams they belong to. - View fixtures for their teams. - Respond to their own RSVPs. - Add, edit, or delete their own RSVP notes. - View polls for their teams. - Respond to their own poll responses while the poll is open. - Add, edit, or delete their own poll response notes while the poll is open. A regular member cannot: - Manage the roster. - Create or cancel fixtures. - Manage polls. - View private roster contact details unless signed in. - Act as another person unless they are an organizer using organizer controls. ## Organizer Response Controls Organizers can update fixture RSVP statuses and poll response statuses from admin views. Behavior: - RSVP updates refresh attendance counts and visible response lists. - Poll response updates refresh poll counts and visible vote lists. - Poll response changes are blocked once the poll is closed. ## Private Data Controls Private data includes: - Roster contact details. - Member notes. - Birthday. - Communication preferences and unsubscribe state. - Financial balances and transactions. Access rules: - Roster contact details require a registered team member. - Roster editing requires organizer rights. - Finance sections require organizer rights. - A member's own account page can be managed only by the registered user matching that Person. - Team access always requires the current Person to belong to the team. ## Communication Preferences Each Person has one outbound communication channel: - Email. - Text. - Don't Send Any. Rules: - Email requires an email address. - Text requires a mobile number. - Don't Send Any suppresses event invites. - Email and text unsubscribe states are respected. - A Person can be reachable by the selected channel only when the required contact detail exists and the channel is not unsubscribed.