Model real responsibilities
The application manages officials, invitation acceptance, assignments, and a private handbook. The director uses Google Workspace identity through the shared controller, while invited officials use single-use email links. An invitation cannot grant director access.
Staffing, event access, reference material, rules, and team views share navigation filtered by role and active event grants. Direct routes and APIs enforce the same policy, so hiding a menu item is not treated as authorization.
Keep identity outside the application
The separate controller supplies verified identity and a narrow local storage and email interface. The rodeo application owns its roster, sessions, permissions, and retry behavior without receiving cloud credentials or the Google client secret.
Revocation takes effect on subsequent requests. The documented test surface includes invitation, access, navigation, and integration logic, with explicit coverage thresholds for the security-sensitive modules.
The application bundle is generated and committed alongside source. A freshness check guards against releasing edited modules with an older embedded application artifact.
Exercise access without changing real assignments
Deployment checks can use a synthetic accepted assignment in an isolated copy of state. They report when a fixture was used and do not create real invitations or change production permissions. That keeps an access rehearsal repeatable while preserving the distinction between a test principal and a person's live responsibilities.