Platform Updates

Repositories: Rego, Partners and Partners API.

What changed: Attendees can select several volunteer roles and answer each role’s questions in a separate step. Review groups answers by role before submitting the applications together. The primary Show more about this role button sits inside each selectable card and opens details without changing selection. Roles already applied for remain unavailable for another application.

Who may notice: Volunteer applicants and partners previewing volunteer forms. Each role keeps its own application, review status and confirmation. The API validates every selected role before saving the batch in one database statement.

Validation: Desktop and mobile browser fixtures verified full-card selection, independent detail buttons, separate answer drafts, shared conditions, review and one batch request. Actual API handler tests covered validation, ownership, eligibility, conflicts and legacy single-role submissions. Client/API type checks, production builds and 85-module EMS preview parity passed. Fixtures sent no real applications or messages.

Repository: Rego.

What changed: Event pages now have a compact sticky navigation bar below the site header. Visitors can jump to the event description, registration tiers, dealer packages, add-ons, inclusions, activities, volunteering, shop options and conditions when those sections are available. The current section is highlighted; narrow screens scroll the navigation horizontally.

Who may notice: Visitors browsing longer event pages. Section jumps keep headings clear of the navigation, support keyboard focus and direct links, and respect reduced-motion preferences. Navigation follows sections that become available after event details load.

Validation: Client type checking and production build; desktop and mobile browser checks for sticky placement, section visibility, jumps, direct links and keyboard navigation.

Repositories: Rego, Partners API and Partners schema.

What changed: Shop item questions appear in the add-to-cart modal instead of being asked again during checkout. Buyers can reopen Edit item options in the cart to correct answers or finish an older cart. Courier checkout now offers an account-owned address book with add, edit, delete and primary-address controls. Address editing uses the same fields and validation as profile setup.

Who may notice: Event shop buyers choosing courier delivery. The profile address is preselected until a saved primary delivery address is set; primary delivery addresses take precedence for future orders without changing the profile. Pickup does not ask for an address. Orders keep the full delivery address snapshot even if the saved address is later edited or deleted. Checkout verifies saved-address ownership and takes the canonical address from the API.

Validation: Desktop/mobile browser fixtures cover modal-only questions, editing cart answers, profile defaults, primary precedence, address CRUD, and checkout payloads. API ownership and snapshot tests, client/API type checks, production builds and EMS source parity pass. The address-book migration is installed with its schema ledger; database tests for primary uniqueness, ownership, deletion, address limits and private access passed with synthetic records rolled back. No real cart, order or personal address is created by validation.

Repositories: Rego, with existing Partners and API variant pricing.

What changed: Configured shop variants now appear under Select a variant as selectable cards showing artwork, name, price and availability. An eye button opens that variant’s description, pickup or delivery, availability and stock details. Unavailable variants remain greyed out and cannot be selected. Adding an item closes its detail modal once the cart accepts the local change; cart synchronization status remains visible.

Who may notice: Shop buyers choosing sizes or designs. Each variant remains a separate cart line with its own name, unit price and line total. Partners can already configure prices independently for inclusion variants in Shop Config. Buyer question choices such as a standalone listing’s design dropdown remain form answers; use configured variants when choices need distinct prices, SKUs or stock.

Validation: Desktop/mobile production-build browser fixtures exercise artwork, variant details, selection, required questions, automatic dismissal, distinct prices and cart removal. Rego typecheck and production build pass. Existing API price/availability contract checks and Partners Shop source-boundary checks pass. No live cart or order is written by these checks.

Repositories: Rego and Partners.

What changed: The Dealers Den application representative contact card now offers Update profile. The button opens the same shared profile editor used by Settings. Successful saves update the representative details in place while retaining the application answers, table details, selected package and current step. Settings now opens its profile editor in this shared modal too.

Who may notice: Attendees correcting contact information before applying. The editor retains canonical profile validation, phone checks, photo handling and username recovery. Failed or uncertain saves stay open for correction; active saves prevent accidental dismissal. Closing without saving leaves the application draft intact. EMS uses the same contact presentation without enabling real attendee account edits in previews.

Validation: Actual desktop/mobile route fixtures cover shared Settings/application editing, cancel, failed-save retry, pending-save dismissal, refreshed contact and retained draft values. Client type checks, production builds and canonical preview parity pass. No live profiles or applications are modified by the checks.

Repositories: Rego, Partners schema and Partners API.

What changed: Friends Settings now includes Only people with mutual friends, off by default. When enabled, new account discovery and incoming friend requests require at least one accepted shared friend. Existing friendships remain available. Pending requests and blocked relationships do not count. Discovery being disabled still takes precedence, and turning other controls off does not erase the saved restriction.

Who may notice: Attendees who prefer introductions through trusted connections. Rego and Social request paths enforce the preference on the server and in the canonical database command. Discovery checks do not expose the names of mutual friends.

Validation: Actual route and component fixtures cover saving, privacy enforcement, direct request attempts, rejected responses, keyboard use and mobile layout. A rollback-only database fixture verifies accepted, pending and blocked graph cases and command replay without retaining test identities or friendships. Client/API checks and production builds pass. No friend-request notifications are sent by the verification fixtures.

Repositories: Rego and Partners.

What changed: The complete bordered checkbox or radio choice card, including its padding and empty space, now selects the option. Form questions, registration choices, dealer packages and add-ons share this behavior. EMS form previews use the same canonical component. Disabled options remain unavailable, and separate details buttons and links do not change the selection.

Validation: Actual component browser checks cover pointer clicks, exactly-once changes, radio behavior, disabled controls and native keyboard selection at desktop and mobile sizes. Client type checks, production builds and shared-preview parity verify source consistency. No registrations or purchases are submitted by these checks.

Repositories: Rego, Partners and Partners API.

What changed: Event Shop is now the single public event commerce destination. Old event Merch links redirect to Shop, the duplicate event merchandise section is removed, and Rego Config no longer offers the obsolete merchandise visibility switch. Registration individual sales remain available. Public item listings, variant prices, eligibility, stock and fulfilment belong to Shop Config.

Who may notice: Event teams managing merchandise and visitors using saved Merch links. Existing inclusions, registrations and orders remain intact. Former merch visibility does not automatically publish items to Shop; teams choose their listings in Shop Config. The retired API projection returns an explicit removal response with the Shop destination.

Validation: Focused redirect and catalog browser checks, client/API type checks and production builds verify source behavior. Local screenshots show the actual components. Release is through Git-linked deployment; no purchases or communications were sent.

Repositories: Partners and Partners API.

What changed: Email Blasts and SMS Blasts now group audiences by registration tier, dealer package, activity, volunteer position, waitlist tier, saved prefill tier, purchased event shop item and registration add-on. Search or filter the category, then select a group for its own message. Selecting several groups combines their recipients and removes duplicates. Selected groups stay visible while filtering, and no audience is chosen automatically.

Who may notice: Event teams sending updates to specific participants. Dealer package groups include representatives and assistants; volunteer groups include applicants and assigned roster members; add-on groups cover attendee and dealer registrations. Prefills must still be active and saved; shop groups contain confirmed, non-cancelled purchases. Email preferences and SMS consent, phone and sending-device requirements continue to apply. Stale or cross-event audience selections are rejected before a campaign is created.

Validation: Actual API handler fixtures exercise all eight categories, consent, pagination, status exclusions, overlapping recipients and forged or stale selections. The segment query loader also passed read-only checks against the live test event. Responsive composer fixtures check search, category filters, retained selection, exact audience IDs, refresh pruning and SMS eligibility counts. Existing email (15 groups) and SMS (14 groups) campaign ownership/recovery checks, channel contracts, API and Partners type checks, Worker dry build and Partners production build passed, including all 85 shared-preview source checks. No live email or SMS campaign was sent by this work.

Repositories: Partners, Rego and Partners API.

What changed: Dealer packages based on registration tiers inherit tier inclusions by default. Partners can enable Override tier inclusions to choose a replacement bundle and fixed item variants for each included attendee. An empty replacement grants no tier items. Package cards, selection screens and details dialogs show inclusions through the shared attendee inclusion components. Table and chair counts plus table dimensions are explicit package fields; package availability remains a separate setting.

Who may notice: Partners configuring booth packages, applicants comparing them, and logistics teams packing registrations. Existing packages keep their default tier behavior. Purchased custom bundles and table details remain frozen through later configuration changes, registration upgrades and transfers.

Validation: Type checks, responsive package editor/card/dialog browser fixtures, source parity checks, API and packing fixtures, and a hosted transaction rollback certificate exercised default inheritance, custom and empty bundles, fixed variants, stock accounting, upgrades, transfers and furniture validation. No test purchases or allocations were retained in production. Source releases use Git-linked deployment.