Onboarding guide

21. ADC Conference - UI

What this chapter covers. This is the consumer half of the "write-once UI, render everywhere" story (primer §2): the Blazor pages, page-local collaborators, and per-entity HTTP services that turn the Conference REST surface (G20) into the screens an organizer, a speaker, a sponsor, or an anonymous attendee actually touches. Everything here lives in the per-module Razor Class Library MMCA.ADC.Conference.UI (under MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/, the path every File:line citation below is relative to), which, like every consumer UI, assembles the reusable primitives taught in G15 (Common UI Framework) into concrete pages. There is very little new infrastructure here: the value is in seeing how a twelve-area feature surface (events, sessions, speakers, conference categories and their items, questions, rooms, sponsors, activities, feedback moderation, public browsing, session selection, and the conference landing page) is composed from the framework's list-page base, typed HTTP service base, validation bridge, device-capability abstractions, and module system. The headline lens is [Rubric §18, UI Architecture & Component Design], which assesses component reuse, separation of presentation from data access, and a coherent composition model. Because the same Razor components compile into the Blazor Server, WebAssembly, and .NET MAUI hybrid heads, this one library renders the conference across web, Android, iOS, macOS, and Windows with no per-platform reimplementation. [Rubric §22, Responsive & Cross-Browser/Device].

The layering inside the UI: a page never touches HttpClient

Each page is a .razor + .razor.cs code-behind pair that depends on a UI service interface, never on HttpClient and never on the API's internals. The nine CRUD-shaped entities (events, sessions, speakers, conference categories, category items, questions, rooms, sponsors, activities) each get a service deriving from Common's EntityServiceBase<TEntityDTO, TIdentifierType> and exposing the IEntityService<TEntityDTO, TIdentifierType> contract: EventService, SessionService, SpeakerService, ConferenceCategoryService, CategoryItemService, QuestionService, RoomService, SponsorService, and ActivityService (MMCA.ADC.Conference.UI/Services/Events/EventService.cs:15, Services/SessionService.cs:10, Services/SpeakerService.cs:13, Services/ConferenceCategoryService.cs:10, Services/CategoryItemService.cs:10, Services/QuestionService.cs:10, Services/RoomService.cs:14, Services/SponsorService.cs:10, Services/ActivityService.cs:10). They inherit GetAllAsync/GetPagedAsync/GetByIdAsync/AddAsync/UpdateAsync/DeleteAsync and only add the handful of bespoke verbs the conference needs. Six add nothing at all: ActivityService, SponsorService, SessionService, QuestionService, CategoryItemService, and ConferenceCategoryService are fourteen-line files whose entire job is to bind an endpoint name to a DTO and an identifier alias, and their interfaces (IActivityUIService at Services/IActivityUIService.cs:9, ISponsorUIService at Services/ISponsorUIService.cs:9, and siblings) are equally empty extensions of the generic contract.

Three services show where extension goes. EventService layers PublishAsync, UnpublishAsync, RefreshFromSessionizeAsync, and RefreshFromSessionizeWithCodeAsync onto the inherited CRUD (Services/EventService.cs:19, :31, :43, :53). The first two carry the loaded row version as an If-Match header built by ConcurrencyETag (Services/EventService.cs:29, :41), so a publish races against a concurrent edit at the API rather than in the browser. The fourth is a small orchestration worth reading: an edited Sessionize code has to be persisted before the import runs (the import reads the code off the stored event), and the import rewrites the event's children and refresh stamp, so the method persists, imports, reloads, and hands back both halves as one SessionizeRefreshOutcome (Services/EventService.cs:61 to :82, record at Services/SessionizeRefreshOutcome.cs:13). That is the recurring shape: one call, one Result, one failure branch for the page. RoomService overrides AddAsync to reshape the POST body, because the API's AddRoomRequest contract names the key RoomId while the DTO calls it Id (Services/RoomService.cs:18 to :38), and adds a two-argument DeleteAsync that passes the owning event on the query string (Services/RoomService.cs:40). SpeakerService adds LinkUserAsync/UnlinkUserAsync for binding a speaker record to an identity account (Services/SpeakerService.cs:17, :28).

Nothing in this layer throws for a server answer. Every call funnels through the framework's HttpResultExecutor and ProblemDetailsResultReader, so a transport fault and a ProblemDetails body both arrive as a failed Result with a typed error the page can branch on (Services/SpeakerLookupService.cs:17 and :25, Services/SessionSelectionService.cs:21 and :31, Services/OrganizerFeedbackService.cs:28 and :35). [Rubric §3, Clean Architecture] and [Rubric §9, API & Contract Design]: the page binds to a DTO contract (EventDTO, SessionDTO, SpeakerDTO, SponsorDTO, ActivityDTO) plus an interface, and the wire envelope is the uniform PagedCollectionResult<T> / CollectionResult<T> the API returns for every entity.

The list pages: two bases, one recipe

Eleven list screens hang off DataGridListPageBase<TDto>, which supplies server-side paging against MudDataGrid<T>, cancellation lifecycle, loading and load-failed state, filter and sort extraction from MudBlazor's GridState<T>, toast error surfacing, saved page/rows-per-page/scroll restoration, and viewport-driven mobile rendering that swaps the grid for a MobileInfiniteScrollList<TItem>. Six derive from it directly, because their rows are not scoped to a conference event: EventList, SessionList, QuestionList, ConferenceCategoryList, PublicEventList, and PublicSessionList (Pages/Event/EventList.razor.cs:16, Pages/Session/SessionList.razor.cs:19, Pages/Question/QuestionList.razor.cs:11, Pages/ConferenceCategory/ConferenceCategoryList.razor.cs:11, Pages/Public/PublicEventList.razor.cs:31, Pages/Public/PublicSessionList.razor.cs:27). A concrete page reduces to overriding Title, GridRef, SaveFilters/RestoreFilters, and a LoadServerData delegate that calls its service's GetPagedAsync, with delete-and-confirm delegated to the shared ListPageActions helper.

The other five list pages scope their rows to one conference event, and that repetition earned its own ADC-local base: EventFilteredListPageBase<TDto> (Pages/Common/EventFilteredListPageBase.cs:25), used by RoomList, SpeakerList, SponsorList, ActivityList, and PublicSpeakerList (Pages/Room/RoomList.razor.cs:12, Pages/Speaker/SpeakerList.razor.cs:18, Pages/Sponsor/SponsorList.razor.cs:18, Pages/Activity/ActivityList.razor.cs:19, Pages/Public/PublicSpeakerList.razor.cs:33). It injects IEventLookupService (Pages/Common/EventFilteredListPageBase.cs:27), starts the event load before the first await of OnInitializedAsync and exposes it as EventsLoadTask (:132 to :144) because the grid's first ServerData call can race ahead of initialization, and gives derived pages WaitForEventsAsync and ApplyEventFilter to close that race deterministically (:192, :195, awaited at Pages/Activity/ActivityList.razor.cs:60 and applied at :73). It seals SaveFilters/RestoreFilters and hands pages SavePageFilters/RestorePageFilters instead (Pages/Common/EventFilteredListPageBase.cs:86, :89, :98, :110), so the eventId half of the saved state is written once, with the explicit "all" sentinel that distinguishes a deliberate clear from no saved state at all (:105). Default resolution is one method: a restored id that still exists wins, a dangling one falls back to the live-or-next event computed by CurrentEventSelector, and a page whose scope is locked is always pinned to that computed default (:169 to :189, opt-out property at :57, overridden by PublicSpeakerList to "only privileged readers choose" at Pages/Public/PublicSpeakerList.razor.cs:53). Two details are worth internalizing. The event picker renders only once the component is interactive (Pages/Common/EventFilteredListPageBase.cs:72): an SSR prerender would paint a fully formed picker into static HTML whose clicks are silently swallowed until the interactive runtime attaches, which under InteractiveAuto's WebAssembly leg is a whole runtime boot later. And a failed lookup is remembered rather than swallowed (:42, :163), so a page that must fail closed can branch instead of falling through to an unscoped query. [Rubric §19, State Management & Data Flow] and [Rubric §23, Front-End Performance & Rendering].

Two public lists deliberately opt out of the grid entirely. PublicSponsorList and PublicActivityList are plain ComponentBase pages (Pages/Public/PublicSponsorList.razor.cs:19, Pages/Public/PublicActivityList.razor.cs:20), because a sponsor roster and a social programme are bounded (both cap the fetch at 200 rows, Pages/Public/PublicSponsorList.razor.cs:22, Pages/Public/PublicActivityList.razor.cs:23) and render as tier-grouped logo cards and a chronological programme rather than a sortable table, so each fetches one page and orders it in memory (Pages/Public/PublicSponsorList.razor.cs:88 to :91, Pages/Public/PublicActivityList.razor.cs:87). PublicSpeakerList splits the difference: it keeps the base class's page-based mobile fetch path but appends each page to an accumulating list and hangs Common's InfiniteScrollSentinel below its card grid, twelve cards per chunk so a full chunk fills whole rows (Pages/Public/PublicSpeakerList.razor.cs:36, :38).

Detail pages, form models, and one declaration of the rules

The organizer detail pages share their own ADC-local base, DetailPageBase (Pages/Common/DetailPageBase.cs:19), which owns the two things every one of them repeated verbatim: the page-scoped CancellationTokenSource with its dispose pattern (:21, :29, :56) and the inline edit-mode lifecycle, IsEditing/IsDirty plus the BeginEdit/EndEdit transitions that keep the dirty flag from being left set behind a closed editor (:32 to :52). Four pages inherit it from markup: EventDetail, SessionDetail, SpeakerDetail, and ConferenceCategoryDetail (Pages/Event/EventDetail.razor:6, code-behind at Pages/Event/EventDetail.razor.cs:19), and the dirty flag feeds Common's UnsavedChangesGuard directly (Pages/Event/EventDetail.razor:11). [Rubric §24, Forms, Validation & UX Safety].

Editable fields are not loose page state. Each entity declares an abstract form model carrying its DataAnnotations, and the create page and the detail page's inline editor each bind a sealed subclass of it: EventFormModel with EventCreateModel and EventEditModel (Pages/Event/EventFormModel.cs:26, Pages/Event/EventCreateModel.cs:11, Pages/Event/EventEditModel.cs:11), and the same triad for sessions, speakers, rooms, questions, sponsors, activities, and conference categories (SessionFormModel Pages/Session/SessionFormModel.cs:24, SpeakerFormModel Pages/Speaker/SpeakerFormModel.cs:25, RoomFormModel Pages/Room/RoomFormModel.cs:24, QuestionFormModel Pages/Question/QuestionFormModel.cs:24, SponsorFormModel Pages/Sponsor/SponsorFormModel.cs:25, ActivityFormModel Pages/Activity/ActivityFormModel.cs:25, ConferenceCategoryFormModel Pages/ConferenceCategory/ConferenceCategoryFormModel.cs:24). The rules live once: the MudForm fields bridge to the annotations through Common's ModelValidation rather than repeating Required/RequiredError per field, the length caps come from the DTO's own constants, and every ErrorMessage is a resource key resolved by the localizing DataAnnotationsModelValidator (ADR-027) (Pages/Event/EventFormModel.cs:42 to :44). The subclasses own only the direction of travel: EventCreateModel.ToNew() builds the posted DTO and always as an unpublished draft, because publishing is a separate gesture on the detail page (Pages/Event/EventCreateModel.cs:25 to :42), while EventEditModel.LoadFrom(source) copies the loaded event into the editor in one call and ToUpdated(source) writes the edited values over the identity, row version, and published state that were loaded (Pages/Event/EventEditModel.cs:18, :48). Because both pages bind the same EventFormFields.razor component to an instance of the same base, a value the create page accepts is a value the detail page accepts. [Rubric §1, SOLID] and [Rubric §15, Best Practices & Code Quality]. The one model with no create page to mirror follows the same discipline anyway: ConferenceCategoryItemEditModel declares the inline item form's rules against CategoryItemDTO's own length constant (Pages/ConferenceCategory/ConferenceCategoryItemEditModel.cs:19 to :31).

Container and presentational split, and page-local collaborators

The behaviour-heavy screens do not keep everything in one code-behind: the page stays the container (data fetching, filter and paging state, service calls) and hands rendering to presentational children that receive parameters and raise callbacks. PublicSessionList is the fullest example, splitting into PublicSessionListFilterBar (privileged event picker or locked chip, debounced title search, room picker, All Sessions / My Schedule toggle, share action, Pages/Public/PublicSessionListFilterBar.razor.cs:15, parameters from :25) and PublicSessionListView (the mobile card list, the desktop grid, and the inline bookmark stars, Pages/Public/PublicSessionListView.razor.cs:26), which exposes Grid and ReloadAsync back to the page so the base class's grid plumbing keeps working unchanged. The same split shows up on the category detail page via ConferenceCategoryItemsPanel, which owns the item table and its inline add/edit rows and hands the reloaded aggregate back through CategoryChanged (Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:21, :31), on the speaker detail page via SpeakerCategoryItemsPanel (Pages/Speaker/SpeakerCategoryItemsPanel.razor.cs:16), and on the selection dashboard via SessionSelectionSpeakerOverlap and SessionSelectionAiScores (Pages/SessionSelection/SessionSelectionSpeakerOverlap.razor.cs:11, Pages/SessionSelection/SessionSelectionAiScores.razor.cs:12).

A second, quieter move keeps the code-behinds small: pure logic is lifted out into page-local collaborators, plain classes beside the page rather than registered services, each explicitly extracted to keep the component within the [Rubric §18] line budget. SessionSelectionDisplay holds the chip colors and filter predicates the dashboard and its two children share (Pages/SessionSelection/SessionSelectionDisplay.cs:11); SessionSelectionFilters holds the five bound filter values and the option lists derived from the loaded board (Pages/SessionSelection/SessionSelectionFilters.cs:13, projection in SessionSelectionFilterOptions at Pages/SessionSelection/SessionSelectionFilterOptions.cs:11); PublicSessionListFilterState translates that page's filters to and from the persisted string map (Pages/Public/PublicSessionListFilterState.cs:11); PublicScheduleRoomOptions builds the room picker out of events the page already loaded, so narrowing by room costs no extra fetch, and re-validates the active room against the newly scoped list rather than leaving a filter that matches nothing (Pages/Public/PublicScheduleRoomOptions.cs:11, :37 to :50); SessionLookups caches the session detail page's four dictionaries per page instance, re-fetching rooms when the session's event changes (Pages/Session/SessionLookups.cs:29, :43); SpeakerUserSearch fans three parallel IUserUIService lookups out and unions them, because GetPagedAsync ANDs its filters server-side and one call with all three set would return the empty intersection (Pages/Speaker/SpeakerUserSearch.cs:12, :42 to :44); FeedbackQuestionLoader pages until TotalItems is reached so a feedback report cannot silently truncate, with 100 rows per request and a 20-page runaway guard (Pages/Feedback/FeedbackQuestionLoader.cs:17, :20, :26); and ADCHomeContent holds the landing page's editorial data (Pages/Home/ADCHomeContent.cs:15). All of them are testable without rendering anything. [Rubric §28, Front-End Testing] and [Rubric §14, Testability].

Child-and-join entities: a thin POST/DELETE base

Sessions, speakers, and events own join relationships (a speaker added to a session, a category item to a speaker) that the generic CRUD base cannot model, because the write carries a parent id. These get four near-identical services (EventSpeakerService, SessionSpeakerService, SessionCategoryItemService, SpeakerCategoryItemService) over the shared ChildEntityServiceBase, which was hoisted out of this module into MMCA.Common.UI so every consumer module can reuse it (the note is left in place at Services/ChildEntityServices.cs:89). Each Conference join service reduces to supplying its endpoint and adding typed AddAsync/DeleteAsync wrappers over the base's two verbs (Services/ChildEntityServices.cs:22, :35, :48, :61), and their four interfaces live together in one file (Services/IChildEntityUIService.cs:14, :26, :38, :50). Note the hard-won detail, now enforced by a helper rather than by discipline: the add payload always names the parent explicitly (new { EventId = eventId, SpeakerId = speakerId }, Services/ChildEntityServices.cs:26), and every removal appends its owning aggregate's id through ChildEntityDeletePath (Services/ChildEntityServices.cs:76, called at :29, :42, :55, :68). The join controllers remove a row by loading the parent aggregate and asking it to drop the child, so a DELETE without the parent binds it to default, finds nothing, and answers 404 while the UI reports a generic failure (Services/ChildEntityServices.cs:14 to :21).

Display-enrichment lookups: the GetAll-vs-GetById populator gap, worked around in the UI

Because the API's list endpoints do not always populate every cross-entity navigation, several pages need a cheap id-to-name map to render speaker names beside a session or an event name beside a room, a sponsor, or an activity. Three lookup services fill that role, SpeakerLookupService, EventLookupService, and CategoryItemLookupService (behind ISpeakerLookupService, IEventLookupService, and ICategoryItemLookupService). Each does one pageSize=10000 fetch with children and foreign keys suppressed, and folds the result into a Dictionary of lightweight projection records, SpeakerInfo, EventInfo, CategoryItemInfo (Services/SpeakerLookupService.cs:12, fetch at :22, fold at :32; Services/EventLookupService.cs:33; Services/CategoryItemLookupService.cs:12). EventInfo is the one projection that grew a feature-specific field: SponsorshipPacketUrl is an optional trailing parameter defaulting to null precisely so the many call sites that need only identity and dates stayed unchanged, and only the public sponsor page reads it (Services/IEventLookupService.cs:14 to :21, read at Pages/Public/PublicSponsorList.razor.cs:62). This is a deliberate client-side join over the navigation-populator (ADR-002) gap between the API's list and by-id read shapes.

One page needed three of these together, and got a composite rather than three nullable caches and three failure branches: SpeakerDetailLookupService gathers the category items, their owning category titles, and the question texts into a single SpeakerDetailLookups record answered as one Result, short-circuiting on the first failure (Services/SpeakerDetailLookupService.cs:11, :18 to :37, record at Services/ISpeakerDetailLookupService.cs:13). The same "one call, one failure branch" instinct produced SessionizeRefreshOutcome above and SessionLookups beside the session detail page.

Three feature areas that go beyond CRUD

First, the speaker self-service dashboard. SpeakerDashboard sits behind a plain [Authorize] attribute (Pages/Speaker/SpeakerDashboard.razor:2, code-behind at Pages/Speaker/SpeakerDashboard.razor.cs:21) and is gated on the speaker_id JWT claim, showing the linked speaker's sessions, per-session bookmark counts, and feedback. It leans on SpeakerDashboardService (behind ISpeakerDashboardUIService), whose session read pushes the speaker filter server-side onto the virtual SpeakerId key, caps the page at 100 rows, and appends a per-call cache-bust parameter so this one read is a guaranteed miss against the shared sessions output cache and a just-made assignment shows immediately, while public list reads keep their cache (Services/SpeakerDashboardService.cs:14, :19, :35, :38). Its bookmark counts come back from one batched endpoint rather than one hop per session (Services/SpeakerDashboardService.cs:54), and it derives from Common's AuthenticatedServiceBase so its calls carry the bearer token and run through the shared retry policy. [Rubric §12, Performance & Scalability].

Second, organizer feedback moderation (BR-53). OrganizerEventFeedback and OrganizerSessionFeedback let organizers review and delete answers through OrganizerEventFeedbackService and OrganizerSessionFeedbackService (Services/OrganizerFeedbackService.cs:15, :66, behind IOrganizerEventFeedbackUIService and IOrganizerSessionFeedbackUIService at Services/IOrganizerFeedbackUIService.cs:11, :27). The read is the unscoped organizer view, capped at 500 answers (Services/OrganizerFeedbackService.cs:26), and each delete passes the parent id explicitly on the query string to satisfy the controller's binding (Services/OrganizerFeedbackService.cs:48). [Rubric §11, Security]: the scoping is server-side and the pages carry [Authorize(Roles = "Organizer")] (Pages/Feedback/OrganizerEventFeedback.razor:2), not a client-side hide.

Third, QR self-service. SpeakerQr renders a full-screen code a speaker can hold up at the podium with no backend call at all: the speaker comes from the speaker_id claim and the payload is built locally, so the page renders identically on the prerender and interactive passes (Pages/Speaker/SpeakerQr.razor.cs:19, :49 to :55). The payload is always the absolute public URL from Common's IPublicLinkBuilder (Pages/Speaker/SpeakerQr.razor.cs:21, :55), never the WebView-internal origin, or a code scanned off the MAUI head would open for nobody else. The framework's QrCodeButton puts the same capability on five organizer and public print surfaces: public event detail (Pages/Public/PublicEventDetail.razor:30), public session detail (Pages/Public/PublicSessionDetail.razor:41), public speaker detail (Pages/Public/PublicSpeakerDetail.razor:45), room detail (Pages/Room/RoomDetail.razor:58), and sponsor detail (Pages/Sponsor/SponsorDetail.razor:70).

Session-selection decision support, the asynchronous edge

The most behaviour-rich page is the organizer-only SessionSelectionDashboard (Pages/SessionSelection/SessionSelectionDashboard.razor:2 carries the Organizer role attribute, code-behind at Pages/SessionSelection/SessionSelectionDashboard.razor.cs:15), which renders category distribution, speaker overlap, locality breakdown, and AI content-similarity scoring over an event's session pool via SessionSelectionService (behind ISessionSelectionUIService). Every load is stamped with a monotonic generation rather than an event id, so switching away from an event and back still discards the first response even though both carry the same id: the generation is snapshotted before the fetch (Pages/SessionSelection/SessionSelectionDashboard.razor.cs:114), re-checked before the board is replaced or an error banner is painted (:127), and re-checked again before the spinner is cleared (:151). Filter options are recomputed from the returned SessionSelectionDashboardDTO itself (:133 to :134). [Rubric §19, State Management & Data Flow].

Scoring is the asynchronous edge. ScoreSessionsAsync POSTs to the scoring endpoint with no retry pipeline, because starting a run is not idempotent and a retried POST could queue a second run behind the first (Services/SessionSelectionService.cs:46 to :48). Because AI scoring of every eligible session can take minutes, the API runs the ScoreEventSessionsCommand in a background scope and answers 202 Accepted immediately with no body, so the service reads the status before the body reader (which treats a body-less 2xx as a failure) and maps it to a sentinel ScoreEventSessionsResultDTO with SessionsScored = -1 (Services/SessionSelectionService.cs:54 to :57). The page turns that sentinel, and only that sentinel, into a fire-and-forget polling session, leaving _isScoring set for the poll loop to clear while every other branch clears it inline (Pages/SessionSelection/SessionSelectionDashboard.razor.cs:180 to :199).

The loop itself is factored into three pieces, which is the part worth studying. ScorePollSession runs the polling (Pages/SessionSelection/ScorePollSession.cs:36, RunAsync at :50), re-reading the cadence each tick from an internal property so a bUnit test can shrink it (Pages/SessionSelection/SessionSelectionDashboard.razor.cs:203, read at Pages/SessionSelection/ScorePollSession.cs:61) and abandoning the session the moment the page's generation moves (:62, :68). ScorePollHost is the record of callbacks through which that loop raises its UI side effects, so no rendering decision lives in the loop and none of the loop lives on the component (Pages/SessionSelection/ScorePollSession.cs:19, constructed at Pages/SessionSelection/SessionSelectionDashboard.razor.cs:215 to :223). And ScorePollTracker is the pure state machine that turns each observation into a ScorePollSignal: keep polling, apply-and-continue, all sessions scored, counts stable long enough, or no scores at all within the zero-progress budget (Pages/SessionSelection/ScorePollTracker.cs:31, signal enum at :6). Its budgets are explicit constants: 225 polls for a 30-minute cap at the 8-second cadence (:34), 5 consecutive fetch failures (:41), 10 zero-progress polls (:48), and 3 stable polls before completion (:51). Because the service answers a server error with a failed Result rather than an exception, the consecutive-failure budget is fed from the result branch, or a persistently failing endpoint would poll silently to the cap without ever reporting (Pages/SessionSelection/ScorePollSession.cs:73 to :82). [Rubric §6, CQRS & Event-Driven] and [Rubric §29, Resilience].

Public versus authenticated rendering, and the offline-first path

A recurring [Rubric §11, Security] pattern: the same conference entity is exposed through two page families. No page under Pages/Public/ carries an @attribute [Authorize] at all, and those reads are output-cached at the API; the organizer family gates on the Organizer role in markup (Pages/Event/EventList.razor:2). PublicSessionList shows the nuance well. It is read-only for anonymous users (BR-43), but an authenticated user gets inline bookmark stars and a My Schedule toggle wired through the optional ISessionBookmarkUIService; because Blazor's [Inject] has no optional mode (an unregistered service throws at render), the page declares that dependency as a nullable property and resolves it via IServiceProvider.GetService, so it stays null when the Engagement module is disabled (Pages/Public/PublicSessionList.razor.cs:38, :86). [Rubric §7, Microservices Readiness]. Non-privileged readers are always locked server-side to the computed current or next event via CurrentEventDefaults and the privileged-reader list ConferenceReadAudience, so a shared organizer URL cannot pin an attendee to a different or unpublished event (Pages/Public/PublicSessionList.razor.cs:121, :154 to :169), and the same rule decides whether the event choice is persisted at all (Pages/Public/PublicSessionListFilterState.cs:22 to :43).

The offline-first behaviour that used to sit in the page now lives behind an interface. IPublicSessionScheduleService / PublicSessionScheduleService run the live paged query and compose it with the framework's OfflineFirstPageSnapshot<TItem>, keeping the last successful first page in the device-local cache so a dead venue network still shows a programme (ADR-042 Wave 3, Services/IPublicSessionScheduleService.cs:34, Services/PublicSessionScheduleService.cs:17, snapshot at :28, cache key at :26). The live path is never altered: the snapshot is consulted only when a fetch fails, a failure with nothing cached travels on to the grid's own handling unchanged, and the page owns only the "showing cached data" banner it raises through a callback (Services/PublicSessionScheduleService.cs:37 to :62, banner at Pages/Public/PublicSessionList.razor.cs:296). One page request is one SessionSchedulePageRequest (Services/IPublicSessionScheduleService.cs:20), and My Schedule rides it as a set of bookmarked ids that scope the query server-side with an Id IN (...) filter rather than over-fetching and filtering in memory (Services/PublicSessionScheduleService.cs:76 to :81); an empty schedule short-circuits before the service is reached, so it can never overwrite the cached programme with nothing (Pages/Public/PublicSessionList.razor.cs:269 to :272).

The rest of the device-capability layer (G26) shows up as injected interfaces that no-op on the web heads: the star toggle fires IHapticFeedbackService (Pages/Public/PublicSessionListView.razor.cs:29), the filter bar shares a schedule screenshot through IScreenshotService and IShareService (Pages/Public/PublicSessionListFilterBar.razor.cs:17, :18), the public activity page opens directions through IMapNavigationService (Pages/Public/PublicActivityList.razor.cs:29), and /conference/sessions?mine=true is a deep link the MAUI head's home-screen quick action targets, which beats the saved page state when present (Pages/Public/PublicSessionList.razor.cs:66, :89). [Rubric §29, Resilience] and [Rubric §22, Responsive & Cross-Browser/Device].

Sponsors and activities, two feature areas in miniature

The sponsor surface is a compact tour of every pattern above. Organizers manage the roster through SponsorList / SponsorCreate / SponsorDetail: the list is an EventFilteredListPageBase<SponsorDTO> that inherits the default-event resolution and persistence wholesale (Pages/Sponsor/SponsorList.razor.cs:18, :38 to :47), and the detail page edits every field except the owning event, on the stated rationale that moving a sponsorship between events is a create plus a delete (Pages/Sponsor/SponsorDetail.razor.cs:13 to :18). Attendees see the same data twice. PublicSponsorList resolves the featured event, filters the roster to it, and groups by SponsorTier ascending (package order) then by Sort and name, so the render order is deterministic rather than insertion-dependent (Pages/Public/PublicSponsorList.razor.cs:88 to :91); when the event publishes no packet URL the sponsorship call to action is hidden entirely rather than offering a dead link (Pages/Public/PublicSponsorList.razor.cs:62). ADCHome renders the same roster as a logo strip under the same tier-then-sort-then-name rule, filtering client-side to the featured event so a second published edition's sponsors cannot bleed onto the landing page (Pages/Home/ADCHome.razor.cs:224 to :233, event filter at :227), and any failure leaves the strip empty and the call to action standing (Pages/Home/ADCHome.razor.cs:235 to :242). Because that page reads the anonymous endpoint directly rather than through a typed service, its wire shapes are private records on the component itself: ADCSponsorCollectionResult and ADCSponsorInfo (Pages/Home/ADCHome.razor.cs:303, :305).

The activities area (the social programme: pre-conference party, coffee connect, after-party, closing ceremony) repeats the shape with two twists. ActivityCreate, ActivityDetail, and ActivityList are the organizer trio, with the create page defaulting the owning event to the current or next one through CurrentEventSelector (Pages/Activity/ActivityCreate.razor.cs:61). Because EventId is a real Activity column, the list's event filter needs no virtual-key resolution and goes straight through the base class's ApplyEventFilter (Pages/Activity/ActivityList.razor.cs:73), unlike the speaker list, whose event filter travels as a virtual key resolved server-side through the join tables (Pages/Public/PublicSpeakerList.razor.cs:19 to :20). PublicActivityList renders the same programme chronologically for attendees, ordering by start time first so ties are deterministic (Pages/Public/PublicActivityList.razor.cs:87), and offers the directions affordance for an activity that carries its own off-site venue.

The landing page

ADCHome is the conference front door, shared by the web and MAUI heads; both serve the editorial images from their own site root today, so neither overrides the ImageBasePath parameter (Pages/Home/ADCHome.razor.cs:17, :50). It fetches the events list through the named "APIClient" and features the live-or-next published event via CurrentEventSelector (Pages/Home/ADCHome.razor.cs:175, :179), deserializing into two more private API models, ADCCollectionResult and ADCEventInfo (Pages/Home/ADCHome.razor.cs:289, :291). Three rendering decisions are worth internalizing. First, during SSR prerender it skips the backend fetch and the timer entirely and renders the static fallback, because an untimed server-side call to a cold backend would block the prerender and therefore the post-login navigation (Pages/Home/ADCHome.razor.cs:115 to :120). Second, the per-second countdown ticking lives in a child component behind a render fence, so this page arms only a single one-shot timer for the Live-to-Ended flip (Pages/Home/ADCHome.razor.cs:125 to :127), classifying the moment into the EventPhase enum Upcoming/Live/Ended from the event's own time zone and going through CurrentEventSelector.ToUtc so the spring-forward gap at a midnight boundary cannot throw out of the render path (Pages/Home/ADCHome.razor.cs:245 to :267). Third, the fallback date is a named constant with an explicit warning that it must track the published event date, since a stale value makes the hero date and the countdown visibly jump once the real event loads (Pages/Home/ADCHome.razor.cs:39). [Rubric §23, Front-End Performance & Rendering]. The editorial content it renders (the keynote, the eight-track catalog, and the two pre-conference workshops) is held as static records in ADCHomeContent: KeynoteSpeakerInfo, ConferenceTrackInfo, and PreConferenceWorkshopInfo (Pages/Home/ADCHomeContent.cs:73, :81, :88, data at :18, :34, and :59); the workshop record carries only proper nouns plus a resource-key stem, so its audience and description lines stay localized (Pages/Home/ADCHomeContent.cs:83 to :88).

Routes, navigation, and localized strings

All paths are centralized in ConferenceRoutePaths, a static catalogue of literal routes and id-parameterized builder methods (EventDetails(id), PublicSessionDetails(id), SponsorDetails(id), ActivityDetails(id), EventFeedbackOrganizer(id), and so on) typed against the module's identifier aliases and formatted culture-invariantly, so a route change happens in one file (MMCA.ADC.Conference.UI/ConferenceRoutePaths.cs:8 to :69). Two entries in that file are deliberate duplicates of routes owned by Engagement.UI, SponsorVisitLink and RoomCheckInLink (ConferenceRoutePaths.cs:60, :61), because Conference.UI must not reference Engagement.UI yet the organizer print surfaces need those links to encode into a QR; the reason is recorded inline at ConferenceRoutePaths.cs:56 to :59. [Rubric §25, Navigation, Routing & Information Architecture]. User-facing strings are not inline English: every page injects an IStringLocalizer<TPage> in its markup (Pages/Event/EventList.razor:5) and resolves labels and snackbar messages through L["..."] over co-located .resx resource pairs, including format patterns such as the hero date layout so month names follow the selected culture (Pages/Home/ADCHome.razor.cs:276). Where a string is deliberately left untranslated (the conference brand name, a postal address, a ticketing URL, the English-only editorial content) the code carries an explicit // i18n: allow marker with a reason (Pages/Home/ADCHome.razor.cs:30, :78, :82, Pages/Home/ADCHomeContent.cs:10 to :13). [Rubric §27, Internationalization & Localization] assesses externalized strings and culture-aware formatting; this area embodies it under ADR-027, which superseded the single-locale ADR-011 (primer §6).

How it all plugs into the shell

Two registration types wire the area in. ConferenceUIModule implements Common's IUIModule (the front-end counterpart of the IModule back-end contract): it declares the module's sixteen NavItem entries, whose labels are resource keys (Nav.Events, Nav.Dashboard, and so on) resolved by the shared NavMenu at render time against the co-located ConferenceUIModule.resx pair (MMCA.ADC.Conference.UI/ConferenceUIModule.cs:14, :16 to :18). Those sixteen split three ways: five public entries for everyone, Events, Sessions, Speakers, Sponsors, and Activities (ConferenceUIModule.cs:21 to :25), two speaker_id-claim-gated entries in the user section, the dashboard and the speaker's own QR (ConferenceUIModule.cs:28, :29), and an Organizer-role-gated admin group of nine, Events, Sessions, Speakers, Categories, Questions, Rooms, Sponsors, Activities, and Session Selection (ConferenceUIModule.cs:32 to :40); it then exposes its assembly so the host can discover the Razor routes (ConferenceUIModule.cs:43).

The companion DependencyInjection extension AddConferenceUI() (a C# extension(IServiceCollection) member, primer §4) is the one call a host makes (MMCA.ADC.Conference.UI/DependencyInjection.cs:17, :19). It delegates the prologue to Common's AddUIModule<ConferenceUIModule>(), which scans the module assembly for every IEntityService<,> implementation as scoped and registers the descriptor as a singleton IUIModule (DependencyInjection.cs:23), then explicitly registers what a scan cannot infer: the four child-entity services (:26 to :29), the speaker dashboard (:32), the two organizer feedback services (:35, :36), session selection (:39), the offline-first schedule service (:42), the three lookup services (:45 to :47), and the composite speaker-detail lookup (:51). Public share links are not registered here: IPublicLinkBuilder comes from the framework's own AddUIShared, and the MAUI head overrides that registration afterwards so shared links always point at the web app, a note left in place where the registration used to be (DependencyInjection.cs:53 to :56). Because the scan covers the entity services, adding a tenth CRUD entity needs no edit in this file at all, and because the module contributes its own nav and assembly, the shell folds it in with no edit to the shell either. [Rubric §1, SOLID] (Open/Closed) and [Rubric §18, UI Architecture]. Read the per-type sections that follow for the mechanics of each page, model, and service; the bUnit and Playwright tests that exercise this library live in the testing chapter (G27).

ADCEventInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:291 · Level 0 · record (sealed, private)

• What it is: the deserialization-only projection of one published event as the landing page needs it. It is declared private sealed record inside ADCHome (:291), so it is not a shared contract: it exists purely to give System.Text.Json a shape to bind the events response into.
• Depends on: no first-party types. BCL only (DateOnly for the two dates).
• Concept introduced: the page-local wire model. [Rubric §9, API and Contract Design] assesses whether consumers bind to explicit, minimal contracts rather than reaching for the server's internal types. The landing page needs ten fields (Id, Name, Description?, StartDate, EndDate, TimeZone, VenueAddress?, VenueMapUrl?, SponsorshipPacketUrl?, TicketingUrl?, :291-301) out of the much larger event DTO the API serves, so it declares exactly those and lets the serializer ignore the rest. Because the record is private to the component, no other page can accidentally couple to it; a second consumer declares its own projection. Every optional field is nullable, which is what lets the page fall back to hard-coded defaults without null checks scattered through the markup.
• Walkthrough: a positional record with no methods. Name feeds the EventName property and therefore HeroTitleParts() (:78, :92); Description feeds EventDescription, falling back to the localized Fallback.EventDescription resource (:80); StartDate/EndDate/TimeZone are the three inputs UpdateCountdown() converts into the UTC live window (:247-259); VenueAddress backs the venue block and the Google Maps search URL (:82-85); Id is the filter key that keeps a second published edition's sponsors off the page (:227); SponsorshipPacketUrl gates the whole sponsorship call to action block, heading and button included (MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor:315-334); TicketingUrl gates the hero's "get tickets" button the same way (ADCHome.razor:71-79), so an event that has not opened sales renders no button rather than a dead link.
• Why it's built this way: the page must render before, during, and after the API call, so it stores a single nullable ADCEventInfo? _event (:64) and every derived property is written as _event?.X ?? <default>. One nullable field is the whole "loaded or not" state machine, with no extra flags. The two ticketing surfaces sit on opposite sides of that line: the conference-day button reads the event field, while the pre-conference workshop button reads the fixed PreConferenceTicketingUrl constant (:29-30), because the workshop day sells through its own TicketLeap page.
• Where it's used: the Items list of ADCCollectionResult (:289), selected by CurrentEventSelector.SelectCurrentOrNext in LoadEventAsync (:179-184), used as the sponsor filter key in LoadSponsorsAsync (:212, :227), and read by every derived display property on ADCHome.
• Caveats / not-in-source: VenueMapUrl is bound from the wire (:299) but never read by this page: the map button builds its own Google Maps search URL from VenueAddress instead (:84-85, ADCHome.razor:358-368). The field is a real event column, displayed on the organizer event page (MMCA.ADC.Conference.UI/Pages/Event/EventDetail.razor:90). Why the landing page projects it without using it is not determinable from source.

ConferenceRoutePaths

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI/ConferenceRoutePaths.cs:8 · Level 0 · class (static)

• What it is: one static class holding every Conference UI route, as public static readonly string constants for fixed paths and small factory methods for id-bearing paths. It covers the organizer management routes, the public attendee routes, the speaker surfaces, and the two QR landing links, so no @page directive or NavigateTo call has to hard-code a URL.
• Depends on: no first-party types. It uses the module's identifier aliases (EventIdentifierType, SessionIdentifierType, SpeakerIdentifierType, ConferenceCategoryIdentifierType, QuestionIdentifierType, RoomIdentifierType, SponsorIdentifierType, ActivityIdentifierType) that the Conference Shared project declares as global using (see the primer on identifier-type aliases, and ADR-048), plus System.Globalization.CultureInfo (:1).
• Concept introduced: a centralized navigation vocabulary. [Rubric §25, Navigation and Information Architecture] assesses whether routes form a coherent, role-aware information architecture instead of scattered magic strings; this class is that story in miniature. The paths split into two deliberate namespaces mirroring the module's two audiences: organizers work under bare prefixes (/events :10, /sessions :14, /speakers :18, /conferencecategories :22, /questions :26, /rooms :30, /sponsors :34, /activities :38) while attendees work under a /conference/... prefix (PublicSessions :43, PublicEvents :44, PublicSpeakers :47, PublicSponsors :49, PublicActivities :50). Detail routes are methods rather than constants because they interpolate a typed id: EventDetails(EventIdentifierType id) (:12) builds /events/{id} with string.Create(CultureInfo.InvariantCulture, ...) so an integer id can never be formatted with a culture-specific group separator. [Rubric §27, Internationalization] shows up here as the negative case: URLs are the one place culture-aware formatting must be suppressed.
• Walkthrough: the file is a flat list grouped by entity, each group contributing a list route, a create route, and a details factory: events (:10-12), sessions (:14-16), speakers (:18-20), conference categories (:22-24), questions (:26-28), rooms (:30-32), sponsors (:34-36), activities (:38-40). The public attendee block follows (:42-50), and it carries two detail factories of its own, PublicEventDetails (:45) and PublicSessionDetails (:46), so an attendee-facing deep link never borrows an organizer route. Then the speaker surfaces SpeakerDashboard and SpeakerQr (:53-54), the two QR self-service links, the organizer feedback factories, and the selection dashboard.
  • The two QR links are deliberate duplicates (:60-61). SponsorVisitLink and RoomCheckInLink build /engage/sponsors/{id} and /engage/rooms/{id}, but those two pages are owned by Engagement.UI. The comment (:56-59) records the reason: Conference.UI must not reference Engagement.UI, yet the organizer print surfaces need the URL to encode into a QR code, and EngagementRoutePaths duplicates a Conference session route the same way. Both are consumed by a QrCodeButton on the sponsor and room detail pages (MMCA.ADC.Conference.UI/Pages/Sponsor/SponsorDetail.razor:70, MMCA.ADC.Conference.UI/Pages/Room/RoomDetail.razor:58).
  • Feedback routes nest under their parent entity: EventFeedbackOrganizer gives /events/{id}/feedback and SessionFeedbackOrganizer gives /sessions/{id}/feedback (:64-65), so the URL itself expresses the ownership hierarchy. SessionSelectionDashboard closes the file (:68).
  • Two factories differ from the rest: SpeakerDetails (:20) and PublicSpeakerDetails (:48) use plain interpolation rather than string.Create(CultureInfo.InvariantCulture, ...), because SpeakerIdentifierType is a Guid whose ToString() is already culture-invariant.
• Why it's built this way: if the admin prefix ever moves (say /events becomes /admin/events), editing the one constant propagates the change to every navigation call, with no grep-and-replace and no risk of a stale link. Keeping the parameterized routes as methods typed against the identifier aliases means a wrong-entity id is a compile error, not a 404.
• Where it's used: every Conference UI Blazor page's @page directive and NavigationManager.NavigateTo call, the "see all sponsors" link on the landing page (ADCHome.razor:308), the NavItems collection in ConferenceUIModule (ConferenceUIModule.cs:21-40), and even one Engagement page, which links back to PublicSponsors (MMCA.ADC.Engagement.UI/Pages/Sponsors/SponsorVisit.razor:42).

ConferenceTrackInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHomeContent.cs:81 · Level 0 · record (sealed, internal)

• What it is: one row of the landing page's track catalogue: a track Name, an Icon (a MudBlazor icon path constant), and a Topics string listing the track's subject areas (:81).
• Depends on: no first-party types. The Icon values are MudBlazor Icons.Material.Filled.* constants (external, imported at :1).
• Concept introduced: this is one of three static-content records held by ADCHomeContent; the two-tier content model is taught under KeynoteSpeakerInfo and reused by PreConferenceWorkshopInfo.
• Walkthrough: a three-property positional record. The whole catalogue is the ADCHomeContent.Tracks property, an IReadOnlyList<ConferenceTrackInfo> initialized inline as a collection expression (:34-52) with eight entries (:36, :38, :40, :42, :44, :46, :48, :50), each spanning two lines: the track name and its icon constant on the first, the topics blurb on the second. They run from "Foundations (Beginner & Student)" (:36-37) to "Career, Leadership & Community" (:50-51), with the two AI tracks, languages, web/mobile/cross-platform, security, and game/XR in between. Every Icon is a MudBlazor Icons.Material.Filled.* constant picked per track (School, Psychology, AutoAwesome, Code, Devices, Security, SportsEsports, Groups). Storing the icon as a string (rather than a RenderFragment or an enum) is what keeps the record a plain data type: the markup passes it straight to <MudIcon Icon="@track.Icon"> (ADCHome.razor:241).
• Why it's built this way: the track list changes once per conference cycle and is editorial rather than transactional, so it lives in the assembly instead of behind an API call or a CMS; the remark on ADCHomeContent names the track catalog alongside the keynote bio as deliberately English-only editorial content, with the localized chrome around it (:10-14). The collection is a get-only static property, so it is initialized once per process, not per render.
• Where it's used: ADCHomeContent.Tracks (:34), rendered as the track grid in ADCHome.razor (:233-250): one MudItem/MudCard per entry, keyed by track.Name (ADCHome.razor:236), showing the icon (:241), the name (:243), and the topics line (:245).

DetailPageBase

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Common · MMCA.ADC.Conference.UI/Pages/Common/DetailPageBase.cs:19 · Level 0 · class (abstract)

• What it is: the base class every Conference detail page inherits (one aggregate, loaded by route id, edited inline). It owns exactly two things the four detail pages used to repeat verbatim: a page-scoped CancellationTokenSource with its dispose pattern, and the inline edit-mode lifecycle (IsEditing / IsDirty plus the enter and leave transitions the unsaved-changes guard reads).
• Depends on: Microsoft.AspNetCore.Components.ComponentBase and IDisposable only (:1, :19). It deliberately depends on nothing from MMCA.Common.UI.
• Concept introduced: the application-local page base, and why it is not framework code. [Rubric §3, Clean Architecture] assesses whether the direction of dependencies matches the direction of stability; the class remark makes the call explicitly (:12-18): the detail-page shape is an application convention, not framework plumbing, and it builds on nothing MMCA.Common would have to know about, so it stays in ADC rather than being pushed up into the shared UI package. That is the mirror image of the list-page decision one level down, where the grid plumbing genuinely is framework code and lives in DataGridListPageBase<TDto>. [Rubric §1, SOLID] is the other half: a derived page keeps only what differs per aggregate (which fields it copies into its edit model, and what a save posts) and inherits the parts that cannot vary. The second idea worth naming is the page-scoped cancellation token. PageToken (:29) is handed to every awaited call the page makes, so navigating away, or an InteractiveAuto render-mode transition swapping the component out, cancels the in-flight work instead of completing into a component that is gone. That is a correctness property, not an optimization: a completion landing on a disposed component is where "collection was modified" and lost-render bugs come from.
• Walkthrough:
  • State (:21-22): a readonly CancellationTokenSource _cts created at construction, and a _disposed idempotency flag.
  • PageToken (:29): protected, exposing only the token, never the source, so a derived page can pass it but cannot cancel or dispose it out from under the base.
  • IsEditing / IsDirty (:32, :35): both protected with private set, so only the three transition methods below can move them. A derived page reads them, and its markup binds the guard to IsDirty.
  • MarkDirty() (:38): the one-line setter bound to every editable field's @bind-Value:after, which is what makes "the reader typed something" a single well-defined event rather than a per-field comparison.
  • BeginEdit() (:41-45) and EndEdit() (:48-52): open the editor on a clean slate, and close it clearing the dirty flag. The class remark states the invariant these two exist to protect (:15-17): the dirty flag can never be left set behind a closed editor, which would otherwise strand the reader behind a navigation prompt with nothing to save.
  • Dispose(bool) / Dispose() (:56-77): the standard disposable pattern, guarded on _disposed, cancelling then disposing the source and calling GC.SuppressFinalize(this). Cancel-before-dispose is the ordering that lets awaiting callers observe an OperationCanceledException rather than an ObjectDisposedException.
• Why it's built this way: [Rubric §24, Forms, Validation and UX Safety] assesses whether a user can lose work by accident. The guard component consumes the flag directly (MMCA.ADC.Conference.UI/Pages/Event/EventDetail.razor:11 binds both IsDirty and an IsDirtyAccessor lambda), so the "are you sure" prompt is driven by one flag with exactly three writers rather than by per-page bookkeeping. [Rubric §15, Best Practices & Code Quality]: the cost of adding a fifth detail page is an @inherits line and two calls, not a re-implementation of the token and the flag.
• Where it's used: the four Conference detail pages, each through an @inherits directive: MMCA.ADC.Conference.UI/Pages/Event/EventDetail.razor:6, MMCA.ADC.Conference.UI/Pages/Session/SessionDetail.razor:6, MMCA.ADC.Conference.UI/Pages/Speaker/SpeakerDetail.razor:8, and MMCA.ADC.Conference.UI/Pages/ConferenceCategory/ConferenceCategoryDetail.razor:3. EventDetail shows the full usage: PageToken on every service call (EventDetail.razor.cs:86, :156, :163, :206-207, :214, :247, :283), BeginEdit() when the editor opens (:120), and EndEdit() on both cancel (:123) and successful save (:173).

EventPhase

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:71 · Level 0 · enum (private)

• What it is: the three-state classification of the featured event relative to now: Upcoming, Live, Ended (:71-76). It is the single switch the landing page's hero renders from.
• Depends on: nothing.
• Concept introduced: deriving a render state from a clock instead of storing it. [Rubric §19, State Management and Data Flow] assesses whether UI state is derived from a single source of truth or duplicated into flags. There is no IsLive boolean anywhere on the page: UpdateCountdown() recomputes _phase from DateTime.UtcNow against the converted UTC window every time it runs (:261-267), and the markup branches on that one field. Recomputing rather than storing means a stale phase is impossible after a timer callback, a parameter change, or the interactive render pass that follows prerender.
• Walkthrough: the assignment is a switch expression over now (:262-267): now < _startUtc gives Upcoming, now < _endUtc gives Live, anything later gives Ended. ArmPhaseTimerForEventEnd() reads it as its guard, returning immediately unless the phase is Live (:144-147), which is what makes the Live-to-Ended timer a single one-shot rather than a recurring tick. In the markup the loading branch comes first (ADCHome.razor:32-35, a PageLoadingState while _isLoading), then Upcoming renders the HomeCountdown child (ADCHome.razor:36-41), Live renders the "event live" chip plus a button to /happening-now (ADCHome.razor:42-56), and Ended renders the post-event chip (ADCHome.razor:57-65). The hero's ticketing button sits outside that branch (ADCHome.razor:67-80), so it shows in every phase the event publishes a URL.
• Why it's built this way: three named states read far better at the call site than nested date comparisons, and keeping the enum private to the component signals it is a view concern, not a domain concept. The domain's own notion of a live window lives server-side and in CurrentEventSelector.
• Where it's used: the _phase field on ADCHome (:63) and its Razor markup only.

KeynoteSpeakerInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHomeContent.cs:73 · Level 0 · record (sealed, internal)

• What it is: the keynote block's content: the speaker's Name, Title (their role), the TalkTitle, an optional PhotoFileName, and BioParagraphs as an IReadOnlyList<string> (:73-78).
• Depends on: no first-party types. BCL only.
• Concept introduced: the two-tier content model of a landing page. The page splits its content into dynamic data fetched from the API (dates, venue, name, ticketing link, sponsors, via ADCEventInfo and ADCSponsorInfo) and editorial data compiled into the assembly (keynote, tracks, and workshops, held by ADCHomeContent as this record and its siblings ConferenceTrackInfo and PreConferenceWorkshopInfo). [Rubric §23, Front-End Performance and Rendering] is the payoff: the keynote, the workshop cards, and the track grid render on the first frame with zero network dependency, so a cold or unreachable backend degrades only the countdown, the hero ticketing button, and the sponsor strip, never the page. [Rubric §27, Internationalization] is the deliberate exception: the holder class carries a written remark recording that this English-only editorial content is the same copy the API would serve, while the chrome around it is localized instead (:10-14). That convention is how ADR-027 distinguishes "not yet translated" from "intentionally untranslated".
• Walkthrough: a five-property positional record. The single instance is the get-only ADCHomeContent.Keynote property, initialized inline (:18-31): Jared Rhodes, "Microsoft MVP and Principal Engineer", the talk "More Software, Different Work", PhotoFileName: "jared-rhodes.webp" (:26), and a three-paragraph abstract (:28-30). BioParagraphs is a list rather than one string so the template can emit each paragraph in its own element instead of relying on whitespace preservation (ADCHome.razor:203-206). The record carries only the portrait's file name, not a path: the usable src is composed from the head-specific ImageBasePath parameter through KeynoteImageSrc, which returns $"{ImageBasePath}/speakers/{fileName}" or null when no file name is supplied (ADCHome.razor.cs:56-57). That split exists because a head could package its assets elsewhere, and the null case is still guarded in the markup so the card renders name and title without a portrait (ADCHome.razor:179-192).
• Why it's built this way: the keynote changes once per conference cycle, so a database round-trip and an admin screen would be pure overhead. The image choice is the interesting half. The comment above the file name (:22-25) records that the shipped asset is a WebP derivative sized to the display resolution, 640px square against a 300px CSS frame so it still has headroom at 2x device pixel ratio, weighing 17 KB against 306 KB for the 2048px source JPEG, and that because both hosts resolve it through ImageBasePath the file must ship in both wwwroots (the Web client and the MAUI head). The original JPEG stays in the repo as the re-encode source. The markup adds loading="lazy" with the reason inline (ADCHome.razor:182-184): the keynote sits below the hero, so it is never the largest-contentful-paint element, and MudImage splats unmatched attributes onto the rendered img, so the hint actually reaches the DOM. Both are [Rubric §23, Front-End Performance and Rendering] in the small.
• Where it's used: ADCHomeContent.Keynote (:18), read by ADCHome.KeynoteImageSrc (ADCHome.razor.cs:56-57) and rendered in the keynote section of ADCHome.razor (:163-211): the portrait (:185-190), the alt text and name (:186, :193), the role (:195), the talk title (:202), and the paragraphs (:203-206).

PreConferenceWorkshopInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHomeContent.cs:88 · Level 0 · record (sealed, internal)

• What it is: one pre-conference workshop card: a resource-key stem Key, the workshop Title, the Presenter name, and an Icon (:88). Two instances make up the whole workshops section.
• Depends on: no first-party types. The Icon values are MudBlazor Icons.Material.Filled.* constants (external).
• Concept introduced: the half-localized content record. [Rubric §27, Internationalization] assesses whether user-facing text resolves through resources rather than sitting in code, and this record is the interesting middle case that the other two content records do not show. Instead of choosing "all in code" or "all in resources", it splits by kind of string: proper nouns stay in code (workshop titles :62, :66; presenter names :63, :67) because translating a talk title or a person's name would be wrong, while the prose that describes each workshop lives in the .resx pair. The bridge is Key, documented on the record itself (:83-87): the markup composes Workshops.{Key}.Audience and Workshops.{Key}.Description at render time (ADCHome.razor:136, :139), and those keys exist in both locales (MMCA.ADC.Conference.UI/Pages/Home/ADCHome.resx:26-29, with the Spanish twins in ADCHome.es.resx). One consequence worth noticing: adding a workshop means adding four resource entries per locale, and a typo in Key fails at runtime as a missing resource rather than at compile time.
• Walkthrough: a four-property positional record. The catalogue is the get-only ADCHomeContent.Workshops property (:59-69) with two entries: "ModularMonolith", "Build a Modular Monolith with an AI Pair", presented by Ivan Ball-llovera with the Hub icon (:61-64), and "SoftwareFactory", "Beyond the Basics: Starting Your Software Factory", presented by Tim Rayburn with the PrecisionManufacturing icon (:65-68). The doc comment above the property states the split in one sentence (:54-58). The markup renders the list as a two-column grid (ADCHome.razor:120-145), keyed by workshop.Key (:123), each card showing the icon in a circle (:128), the title (:130), the localized Workshops.PresenterLabel formatted with the presenter name (:132-134), the audience line (:135-137), and the description (:138-140).
• Why it's built this way: the workshop day runs before the conference day, and the section is placed between the hero and the keynote so the page reads in the same order as the event, which the markup comment records (ADCHome.razor:86-88). Two facts the cards would otherwise repeat, the schedule and the venue, are hoisted into one shared logistics line above the grid (ADCHome.razor:107-118), which is why they are resources (Workshops.Schedule, Workshops.Venue, ADCHome.resx:21-22) rather than record fields. Ticketing is the other deliberate asymmetry: the workshop day sells on its own TicketLeap page, so its call to action reads the PreConferenceTicketingUrl constant (ADCHome.razor.cs:29-30) and always renders (ADCHome.razor:147-159), while the hero's conference-day button reads TicketingUrl off the featured event and hides itself when absent. The constant carries an S1075 suppression with the reason inline (ADCHome.razor.cs:26-31): it is a published product page, not an environment-dependent path, so there is nothing to configure. [Rubric §26, Front-End Security]: the workshop ticketing button opens with Target="_blank" together with rel="noopener noreferrer" (ADCHome.razor:155).
• Where it's used: ADCHomeContent.Workshops (:59) and the workshops section of ADCHome.razor (:85-161) only.

ADCCollectionResult

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:289 · Level 1 · record (sealed, private)

• What it is: the one-property envelope the landing page deserializes the events response into: List<ADCEventInfo>? Items (:289). It exists because the API returns a collection envelope, not a bare array.
• Depends on: ADCEventInfo (its element type), which is what puts it one level above the plain records.
• Concept introduced: mirroring only the slice of the envelope you consume. The API's uniform collection contract is CollectionResult<T>, which carries more than a list. Rather than referencing that type, the page declares a minimal structural twin containing just Items, keeping the landing page free of any dependency on the API's shared contract assembly. [Rubric §9, API and Contract Design]: the wire format is honoured, the coupling is not.
• Walkthrough: consumed in exactly one place, LoadEventAsync (:175): await client.GetFromJsonAsync<ADCCollectionResult>("events", ApiJsonOptions, _cts!.Token). The ApiJsonOptions field is a JsonSerializerOptions(JsonSerializerDefaults.Web) allocated once as static readonly (:33), which is what makes the camelCase wire names bind to the PascalCase record properties. Items is nullable and immediately coalesced to an empty collection at the call site (result?.Items ?? [], :180), so a null body, a null Items, and an empty list all take the same path.
• Why it's built this way: GetFromJsonAsync returns null for an empty response body, so the nullable property plus the coalesce covers both failure shapes without a branch.
• Where it's used: ADCHome.LoadEventAsync only (:175).

ADCHomeContent

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHomeContent.cs:15 · Level 1 · class (static, internal)

• What it is: the landing page's editorial content, lifted out of the code-behind into its own file: the keynote card, the conference track catalog, and the pre-conference workshop catalog, as three get-only static properties.
• Depends on: KeynoteSpeakerInfo, ConferenceTrackInfo, and PreConferenceWorkshopInfo (all three declared in this same file, :73, :81, :88), plus MudBlazor's Icons.Material.Filled.* constants (:1).
• Concept introduced: separating content from orchestration inside one page. [Rubric §18, UI Architecture and Component Design] assesses whether a component has one job and whether its structure makes that job legible. The class summary states the intent verbatim (:5-9): the content is kept beside the page, like the other page-local data holders, so the code-behind stays orchestration only. That is the practical difference between a 313-line code-behind that reads as a lifecycle (fetch, classify, arm a timer, dispose) and one where three paragraphs of conference copy sit between OnInitializedAsync and Dispose. [Rubric §15, Best Practices & Code Quality] is the follow-on: editing the track list for next year's conference touches exactly one file that contains no logic, so the review is a content review. The other reason this is a distinct type rather than a region: the internal accessibility. The three records and the holder are all internal sealed / internal static, so they are visible to the page and to nothing outside the assembly, but unlike the private inner records of ADCHome they can live in their own file. [Rubric §27, Internationalization]: the class remark (:10-14) is where the deliberate English-only decision for this content is recorded, per ADR-027.
• Walkthrough: three static get-only properties, each initialized once at type initialization.
  • Keynote (:18-31): a single KeynoteSpeakerInfo, including the WebP-derivative comment that explains the shipped portrait (:22-25).
  • Tracks (:34-52): an IReadOnlyList<ConferenceTrackInfo> collection expression with the eight conference tracks.
  • Workshops (:59-69): an IReadOnlyList<PreConferenceWorkshopInfo> with the two pre-conference workshops, above the doc comment that spells out which fields are code and which resolve from resources (:54-58).
• Why it's built this way: exposing the three as { get; } properties rather than public fields means the collections are initialized exactly once per process and shared by every circuit on the server head, which matters because the server head renders this page for every connected user. Returning IReadOnlyList<T> rather than an array keeps the markup's @foreach honest about the collection being read-only.
• Where it's used: ADCHome only: KeynoteImageSrc reads ADCHomeContent.Keynote.PhotoFileName (ADCHome.razor.cs:56-57), and the markup reads all three (ADCHome.razor:121 for the workshop grid, :186, :193, :195, :202, :203 for the keynote card, :234 for the track grid).

ADCSponsorInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:305 · Level 1 · record (sealed, private)

• What it is: the landing page's projection of one sponsor: Id, Name, Tier, LogoUrl?, WebsiteUrl?, Sort, and EventId (:305-312). Seven fields, exactly what the sponsor logo strip renders and sorts by.
• Depends on: SponsorTier from MMCA.ADC.Conference.Shared.Sponsors (imported at :5). That one shared enum is the single first-party type the landing page's wire models reference, and it is what raises this record above level 0.
• Concept introduced: sharing the enum, not the DTO. The page could have referenced the API's SponsorDTO and taken everything with it. Instead it declares its own seven-field record and imports only SponsorTier, because the tier is a domain vocabulary term whose numeric ordering is load-bearing here: Platinum = 0, Gold = 1, Silver = 2, Community = 3 (MMCA.ADC.Conference.Shared/Sponsors/SponsorTier.cs:12-25), so an OrderBy(g => g.Key) on the enum value yields package order without a lookup table (:229). Re-declaring the enum locally would have duplicated that ordering contract in a place no test guards. [Rubric §9, API and Contract Design] is the balance being struck: copy the shape, share the vocabulary.
• Walkthrough: a positional record with no methods, used only inside LoadSponsorsAsync and the markup. Tier is the grouping key (:228), Sort then Name are the intra-tier tie-breakers (:232), EventId is the filter that scopes the strip to the featured event (:227), and LogoUrl/WebsiteUrl drive a four-way render fallback in the markup (ADCHome.razor:277-301): linked logo, linked name, bare logo, or bare name, depending on which of the two optional URLs are present. [Rubric §26, Front-End Security] is visible in that block: the outbound sponsor link carries Target="_blank" together with rel="noopener noreferrer" (ADCHome.razor:280), so a sponsor site can never reach back through window.opener. [Rubric §21, Accessibility]: the link also carries a localized aria-label built from the sponsor name (ADCHome.razor:281), and each logo image its Alt (ADCHome.razor:285, :295), so a logo-only card is still announced. Both logo renders also carry loading="lazy", with the comment recording why it is unconditionally safe here (ADCHome.razor:284): the sponsor strip is the last section of the page, so it is always below the fold.
• Why it's built this way: Sort exists so organizers can order sponsors inside a tier by hand, and the code comment states why the sort is explicit at all (:222-223): tier ascending is package order, and Sort then Name breaks ties so the strip is deterministic rather than dependent on insertion order. StringComparer.CurrentCulture on the name tie-break (:232) keeps that alphabetical fallback correct under the selected culture.
• Where it's used: the Items list of ADCSponsorCollectionResult (:303), the grouped _sponsorTiers field (:67), and the sponsor section of ADCHome.razor (:254-336).

ADCSponsorCollectionResult

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:303 · Level 2 · record (sealed, private)

• What it is: the envelope for the sponsors response: List<ADCSponsorInfo>? Items (:303). It is the sponsor-side twin of ADCCollectionResult, declared separately because C# records are not structurally typed.
• Depends on: ADCSponsorInfo, and transitively SponsorTier.
• Concept introduced: nothing new; the minimal-envelope idea is taught under ADCCollectionResult.
• Walkthrough: deserialized in LoadSponsorsAsync with the same shared ApiJsonOptions and the same cancellation token (:220), then reduced in one collection expression (:224-233): result?.Items ?? [] for the null-safe start (:226), .Where(s => s.EventId == _event.Id) to scope to the featured event (:227), .GroupBy(s => s.Tier) (:228), .OrderBy(g => g.Key) for package order (:229), and a Select that materializes each group as a KeyValuePair<SponsorTier, IReadOnlyList<ADCSponsorInfo>> with its members ordered by Sort then Name (:230-232). The result lands in _sponsorTiers (:67), whose doc comment states the intent in one line: sponsors grouped by tier in package order, each group ordered by Sort then Name (:66).
• Why it's built this way: the method-level remarks (:204-209) record the two safety properties. The sponsors endpoint is the same anonymous read path as the events call and already scopes anonymous callers to sponsors of published events; the client-side EventId filter is the second half, so a second published edition's sponsors never bleed onto this page. And any failure leaves the list empty, which falls back to the sponsorship call to action rather than a blank strip. [Rubric §11, Security] is worth naming precisely here: the client-side filter is a correctness control, not an authorization control. The server decides what an anonymous caller may see.
• Where it's used: ADCHome.LoadSponsorsAsync only (:220).

ConferenceUIModule

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI/ConferenceUIModule.cs:14 · Level 3 · class (sealed)

• What it is: the Conference module's UI descriptor. It contributes the navigation items for the whole conference capability (public Events/Sessions/Speakers/Sponsors/Activities, the claim-gated speaker Dashboard and QR page, and an organizer admin group covering Events, Sessions, Speakers, Categories, Questions, Rooms, Sponsors, Activities, and Session Selection) and exposes its assembly so the host can discover the module's routable Blazor components.
• Depends on: IUIModule (the contract it implements), NavItem and NavSection (the nav vocabulary from MMCA.Common.UI.Common), RoleNames (the Organizer role string), ConferenceRoutePaths (the URLs), plus MudBlazor Icons and System.Reflection.Assembly (externals, :1, :5) and the co-located ConferenceUIModule.resx / ConferenceUIModule.es.resx pair.
• Concept introduced: the modular-UI descriptor, the front-end analogue of IModule. [Rubric §18, UI Architecture and Component Design] assesses whether UI is composed from cohesive, self-describing modules rather than a hard-coded master shell; a module declaring its own menu is exactly that, and it is the Open/Closed half of [Rubric §1, SOLID]: enabling a module adds its navigation with no edit to the shell. [Rubric §25, Navigation and Information Architecture] is served because the items are role- and claim-aware and grouped into sections. [Rubric §11, Security] applies with an important caveat: hiding a nav item is UX only. The services still enforce authorization server-side, so the claim and role here are not the security boundary. Per ADR-027 the Title and Group strings are resource keys, not literals: typeof(ConferenceUIModule) in the TitleResource position on every item tells the shared NavMenu to resolve them against the co-located .resx at render time, which the file's own comment records (:16-17). The record's own documentation adds the failure mode (MMCA.Common.UI/Common/NavItem.cs:10-14): a key the resource type does not declare renders as the raw string, so a not-yet-translated entry is legible rather than blank.
• Walkthrough: NavItems (:18-41) is an IReadOnlyList<NavItem> initialized with a collection expression in three tiers, sixteen items in all.
  • Public (:21-25): five items for everyone, anonymous included, pointing at the /conference/... routes: Events, Sessions, Speakers, Sponsors, Activities. They carry no RequiredRole and no Section, so they default to NavSection.General (MMCA.Common.UI/Common/NavItem.cs:16).
  • Speaker (:28-29): the Dashboard and the QR page, both carrying RequiredClaim: "speaker_id" and Section: NavSection.User, so they appear only for a user whose JWT links them to a speaker record and they render in the user menu rather than the main list.
  • Organizer (:32-40): nine items, each carrying RoleNames.Organizer, Section: NavSection.Admin, and Group: "Nav.Group.Conference" so they fold into one labelled admin group, ending with the Session Selection entry (:40).
  • Assembly (:43) returns typeof(ConferenceUIModule).Assembly so the host's Blazor router can discover this library's routable components. Note that "Events", "Sessions", "Speakers", "Sponsors", and "Activities" each appear twice in the list, once public and once organizer, differing only in route and gating: the same label serves two audiences with two destinations.
• Why it's built this way: mirroring the backend IModule pattern on the UI side keeps the app extensible. A host that boots without the Conference module simply has no conference nav and no conference routes, with no conditional code anywhere in the shell. The class also leaves AppBarComponentTypes and LayoutComponentTypes at their interface defaults (MMCA.Common.UI/Common/Interfaces/IUIModule.cs:19-22): Conference contributes no app-bar badge and no root overlay.
• Where it's used: registered as a singleton IUIModule by this module's DependencyInjection through AddUIModule<ConferenceUIModule>() (DependencyInjection.cs:23, implemented at MMCA.Common.UI/DependencyInjection.cs:207-216) and aggregated by the shared UI navigation builder in group 15.

DependencyInjection

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI/DependencyInjection.cs:17 · Level 6 · class (static)

• What it is: the Conference UI composition root. Its single AddConferenceUI() method is the one call a host makes to register every Conference UI service (the per-entity CRUD services by assembly scan, then the child-entity, dashboard, feedback, selection, offline-schedule, and lookup services explicitly) plus the module descriptor.

• Depends on: ConferenceUIModule and, through AddUIModule<T> (MMCA.Common.UI/DependencyInjection.cs:207-216), Scrutor's assembly-scanning API and the open generic IEntityService<TEntityDTO, TIdentifierType>. Then this module's own service contracts: IEventSpeakerUIService, ISessionSpeakerUIService, ISessionCategoryItemUIService, ISpeakerCategoryItemUIService, ISpeakerDashboardUIService, IOrganizerEventFeedbackUIService, IOrganizerSessionFeedbackUIService, ISessionSelectionUIService, IPublicSessionScheduleService, ISpeakerLookupService, IEventLookupService, ICategoryItemLookupService, and ISpeakerDetailLookupService.

• Concept introduced: the extension(IServiceCollection) registration block, half convention and half explicit. [Rubric §3, Clean Architecture] and [Rubric §15, Best Practices & Code Quality] both come down to keeping wiring at the edges; this file is the module's one wiring point. It uses the C# preview extension-type syntax extension(IServiceCollection services) (:13) to hang AddConferenceUI (:19) off IServiceCollection, the same idiom every module's DependencyInjection uses. The convention half is delegated to AddUIModule<ConferenceUIModule>() (:23), which does two things in one call (MMCA.Common.UI/DependencyInjection.cs:210-216): a Scrutor scan of this assembly registering every IEntityService<,> implementation AsImplementedInterfaces().WithScopedLifetime(), and the singleton registration of the descriptor itself. Registering AsImplementedInterfaces is what makes a page able to inject the narrow per-entity interface rather than the open generic, and it means adding a new entity service needs no edit here.

• Walkthrough: the scan runs first (:23), then the method registers by hand exactly the services the scan cannot see, because they do not implement IEntityService<,>:

  • four child-entity managers for the join relationships (:26-29);
  • the speaker dashboard service (:32);
  • the two organizer feedback moderation services, tagged BR-53 in the comment (:34-36);
  • the session-selection decision-support service (:39);
  • the offline-first page fetch for the public session schedule, tagged to ADR-042 Wave 3 (:41-42);
  • three cross-module lookup services (:44-47);
  • and the composite lookup for the speaker detail page (:51), whose comment states its purpose precisely (:49-50): one call and one failure branch over the three lookups that page needs together.

  Every explicit registration is AddScoped; only the descriptor is a singleton, which is correct because it is immutable data. The method returns services for chaining (:57).

• Why it's built this way: scanning the uniform bulk and spelling out the one-off collaborators keeps registration short without hiding the non-trivial wiring. The closing comment (:53-56) documents what this file deliberately does not register: IPublicLinkBuilder comes from the framework, where AddUIShared TryAdd-registers the browser-origin builder (MMCA.Common.UI/DependencyInjection.cs:129-131), and the MAUI head overrides it afterwards with AddCommonMauiPublicLinkBuilder() (MMCA.Common.UI.Maui/DependencyInjection.cs:134, called at MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/MauiProgram.cs:143) so last-registration-wins points shared links at the configured public web URL. Recording an ordering dependency that lives in another repository, right where a reader would otherwise expect the registration, is the cheap version of [Rubric §34, Architecture Governance and Documentation].

• Where it's used: called once during startup by each of the three UI heads: the Blazor Server host (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI.Web/Program.cs:86), the WebAssembly client (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI.Web.Client/Program.cs:65), and the MAUI host (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/MauiProgram.cs:131), alongside the other modules' AddXxxUI() extensions.

ADCHome

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Home · MMCA.ADC.Conference.UI/Pages/Home/ADCHome.razor.cs:17 · Level 9 · class (sealed partial component)

• What it is: the conference landing page: hero with a live countdown and a ticketing button, pre-conference workshops, keynote, track catalogue, sponsor strip with a sponsorship call to action, and venue block. It fetches the published events list to find which event to feature, classifies that event as Upcoming/Live/Ended, loads that event's sponsors, and renders the rest from the compiled-in editorial content in ADCHomeContent. It is shared verbatim by the Web and MAUI heads, and its class doc records that both heads serve the static images from their own site root, so neither overrides ImageBasePath today (:9-16).

• Depends on: ADCCollectionResult, ADCEventInfo, ADCSponsorCollectionResult, ADCSponsorInfo (the API models, all private inner records of this class), EventPhase (a private inner enum), ADCHomeContent with its KeynoteSpeakerInfo, ConferenceTrackInfo, and PreConferenceWorkshopInfo records, CurrentEventSelector from MMCA.ADC.Conference.Shared.Events (:4), SponsorTier (:5), and ConferenceRoutePaths for the "see all sponsors" link (ADCHome.razor:308). Externals: IHttpClientFactory and GetFromJsonAsync (:1, :41-42), IStringLocalizer<ADCHome> injected in the markup as L (ADCHome.razor:1), System.Threading.Timer, TimeZoneInfo, MudBlazor, and the Blazor RendererInfo API. It composes one first-party child component, HomeCountdown (ADCHome.razor:40), which lives in the same folder as a single .razor file with no code-behind.

• Concept introduced: rendering correctly across the prerender and interactive passes. [Rubric §23, Front-End Performance and Rendering] assesses whether a page avoids wasted renders and blocking work; this component is the chapter's clearest case study, and both of its decisions are recorded in the code comments. See ADR-056 for the render-mode strategy these two decisions live inside.

  • Skip the fetch during prerender. OnInitializedAsync checks RendererInfo.IsInteractive and, when false, sets _isLoading = false, computes the countdown from defaults, and returns without touching the network (:115-120). The comment (:110-114) states why: an untimed server-side call to a cold or unreachable backend would block the prerender, and therefore the page load and the post-login NavigateTo("/"), indefinitely. The static fallback renders immediately and the interactive pass loads the real event. Prerender is a one-shot static render, so the timer is moot there. [Rubric §29, Resilience and Business Continuity] is the same point from the availability angle.
  • Fence the per-second re-render. The ticking digits live in the HomeCountdown child, which owns its own timer, so this page arms only a single one-shot Timer for the Live-to-Ended flip (:142-157). The comment at :125-126 records the alternative: a 1-second timer would re-render the entire landing page, the largest static page in the app, for the whole event, per circuit, just to catch one transition. The child goes further still: it ticks once a minute while more than 65 minutes remain and switches to once a second only for the final hour (MMCA.ADC.Conference.UI/Pages/Home/HomeCountdown.razor:32, :52-56, :59, :70-74), and it too refuses to start a timer unless RendererInfo.IsInteractive (HomeCountdown.razor:51-52).

  Three more rubric threads run through it. [Rubric §22, Responsive and Cross-Browser/Device]: one component compiles into the Blazor Server, WebAssembly, and MAUI heads, with the per-head difference reduced to the ImageBasePath parameter (:49-50). [Rubric §27, Internationalization]: user-facing chrome resolves through L[...], while the strings that must not be translated carry explicit // i18n: allow markers with reasons (the ticketing URL :30, the brand name :78, :94-95, the postal address :82). [Rubric §20, Design System and Theming]: the page's scoped stylesheet is a single shared copy rendered by both heads, and an architecture fitness test embeds it and fails the build if it re-hardcodes the brand hex instead of using var(--mmca-primary) (MMCA.ADC/Tests/Architecture/MMCA.ADC.Architecture.Tests/Ui/BrandColorTokenTests.cs:12-17, embedded via MMCA.ADC.Architecture.Tests.csproj:11-13).

• Walkthrough, in lifecycle order:

  • Constants and state (:19-69): the PreConferenceTicketingUrl constant placed first because SA1203 requires constants before fields, with its doc block and S1075 suppression (:19-31), the shared ApiJsonOptions and EventStartTime (:33-34), the FallbackStartDate (:39), then a CancellationTokenSource, the one-shot _phaseTimer, the computed _startUtc/_endUtc, _phase, the nullable _event (:59-64), the grouped _sponsorTiers (:67), _isLoading (starting true, :68), and a _disposed guard the timer callback checks (:69).
  • Derived display properties (:78-85): EventName, EventDescription, VenueAddress, and MapSearchUrl are each _event?.X ?? <fallback>, so the page is fully renderable before and without a successful fetch. MapSearchUrl builds a Google Maps search URL with Uri.EscapeDataString over the address (:84-85).
  • HeroTitleParts() (:92-104): splits the event name so the hero can accent the keyword between "Atlanta " and " Conference" (in "2026 Atlanta Developers Conference" it accents "Developers"). It uses IndexOf/LastIndexOf with StringComparison.Ordinal and falls back to rendering the whole name plain when the name does not match the brand shape (:101-103), which is why an arbitrary event name never renders broken markup; the markup branches on the accent being non-empty (ADCHome.razor:19-26).
  • OnInitializedAsync (:106-128): creates the CTS, takes the prerender short-circuit described above, otherwise awaits LoadEventAsync() then LoadSponsorsAsync() in sequence (:122-123, the sponsor call needs the featured event id) and arms the phase timer (:127).
  • LoadEventAsync (:170-199): creates the named "APIClient" from IHttpClientFactory (:174), deserializes into ADCCollectionResult under the cancellation token (:175), and picks the event with CurrentEventSelector.SelectCurrentOrNext(...) passing three accessor lambdas plus DateTime.UtcNow (:179-184). The comment at :177-178 is the reason it is not a FirstOrDefault: the anonymous endpoint returns published events unordered, so a naive first-item pick would pin the oldest seeded event. Two catch arms are deliberately silent: OperationCanceledException means the component was disposed mid-load (:186-189), HttpRequestException means the API is unavailable and the fallback content stands (:190-193). The finally block always clears _isLoading and recomputes the countdown (:194-198), so no failure path leaves a spinner on screen.
  • LoadSponsorsAsync (:210-243): returns immediately when no event was featured (:212-215), then runs the same anonymous read path against sponsors and reduces the payload to the tier-grouped list described under ADCSponsorCollectionResult. Its two catch arms mirror LoadEventAsync (:235, :239) and both leave _sponsorTiers empty, which is a supported render state rather than an error state.
  • UpdateCountdown (:245-268): converts the event's local start and end into UTC using TimeZoneInfo.FindSystemTimeZoneById(timeZoneId) with "America/New_York" as the default (:251, :257), calling CurrentEventSelector.ToUtc rather than ConvertTimeToUtc because, as the comment records (:253-256), the midnight end boundary does not exist in zones that transition at 00:00 and a raw conversion would throw out of the render path (MMCA.ADC.Conference.Shared/Events/CurrentEventSelector.cs:89-94). The same comment notes the id itself always resolves, because EventInvariants.EnsureTimeZoneIsValid guards every write path. _phase is then assigned from the switch described under EventPhase (:261-267).
  • Phase timing (:130-168): OnCountdownElapsedAsync is the EventCallback the HomeCountdown child raises at zero (HomeCountdown.razor:82), which recomputes the phase, re-arms, and calls InvokeAsync(StateHasChanged) (:131-136). ArmPhaseTimerForEventEnd returns unless the phase is Live and the remaining time is positive, then disposes any prior timer and schedules one callback at untilEnd with Timeout.InfiniteTimeSpan as the period, meaning fire once and never repeat (:142-157). OnEventEnded checks _disposed before re-rendering (:159-168).
  • FormatEventDate (:270-277): formats the date with a pattern read from a resource (L["Hero.DateFormat"]) against CultureInfo.CurrentCulture, so both the layout and the month names follow the selected language (ADR-027).
  • Dispose (:279-286): sets _disposed, cancels and disposes the CTS, and both stops (Change(-1, -1)) and disposes the phase timer. Stopping before disposing is what prevents a callback already in flight from touching a torn-down component.

• Why it's built this way: the landing page is the app's most-hit surface and the post-login destination, so its correctness budget is dominated by two failure modes that have nothing to do with its content: a slow backend blocking the prerender, and a per-second render loop multiplied by every connected circuit. Both are solved structurally (skip the fetch, fence the tick) rather than by tuning, and every dynamic block has a defined empty state, so the page is never blank. The two conditional calls to action follow the same discipline: the hero ticketing button (ADCHome.razor:67-80) and the sponsorship packet block (ADCHome.razor:312-334) each render only when the featured event publishes the corresponding URL, and hide entirely otherwise rather than offering a dead link, which the markup comments state at both sites (ADCHome.razor:67-69, :312-314).

• Where it's used: resolved as the home component by each head's ADCHomePageContent. The Web client points ComponentType straight at this shared component (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI.Web.Client/Pages/ADCHomePageContent.cs:13); the MAUI head points at a thin local wrapper page that renders <ADCHome /> with no parameters (MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/Pages/ADCHomePageContent.cs:10, MMCA.ADC/Source/Hosts/UI/MMCA.ADC.UI/Pages/ADCHome.razor:6). [Rubric §28, Front-End Testing]: the page has no bUnit test, but two suites hold it to account from outside, the brand-token fitness test above and the E2E pseudo-localization sentinel, which probes this page's Location.OpenInMaps resource and settles on the always-rendered .location-section, precisely because that button is static markup rather than event-load-gated (MMCA.ADC/Tests/E2E/MMCA.ADC.E2E.Tests/Workflows/PseudoLocalizationTests.cs:31-44).

• Caveats / not-in-source: the page's own countdown window is not identical to the selector's. UpdateCountdown starts the event at EventStartTime = 08:00 local (:34, :249), while CurrentEventSelector starts its live window at midnight local (MMCA.ADC.Conference.Shared/Events/CurrentEventSelector.cs:71). Both end at midnight after the last day (:250, CurrentEventSelector.cs:70). So between midnight and 08:00 on day one, the selector already treats the event as live while the hero still shows a countdown. Whether that is intended is not determinable from source. Also note the two hard-coded fallbacks used when no event loads: the date 2026-10-17, whose comment warns it must track the published event date or the hero date and countdown visibly jump once the real event arrives (:36-39), and the venue address (:82).

EventFilteredListPageBase<TDto>

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Common · MMCA.ADC.Conference.UI/Pages/Common/EventFilteredListPageBase.cs:25 · Level 9 · class (abstract, generic)

• What it is: the base class for every Conference list page whose rows are scoped to a single conference event. It adds three things on top of the framework's grid base: the event lookup, a persisted eventId filter, and the default (current or next) event resolution. A derived page supplies only what differs: how it saves and restores its own filters, and what it reloads when the scope changes.
• Depends on: DataGridListPageBase<TDto> (its base, :25), IEventLookupService and its EventInfo record (injected at :27, :30), CurrentEventSelector (:3, :182), and the EventIdentifierType alias. Externals: Microsoft.AspNetCore.Components for [Inject] and RendererInfo, and System.Globalization.CultureInfo (:1).
• Concept introduced: layering an application-vocabulary base on a framework base. [Rubric §3, Clean Architecture] assesses whether abstractions sit at the layer that owns their vocabulary. The class remark makes the call in one sentence (:16-18): "conference event" is domain vocabulary, not framework vocabulary, so this does not belong in MMCA.Common alongside the grid plumbing it builds on. The result is a two-layer inheritance chain where each layer owns exactly the concepts of its own repository, which is the same reasoning that keeps DetailPageBase ADC-local for a different reason (nothing to share) and this one ADC-local for this reason (nothing shareable should be shared). The second idea is prerender-truthful interactivity, and it is worth reading in full because it is a non-obvious correctness rule rather than a preference. CanRenderEventPicker gates the picker on RendererInfo.IsInteractive && Events is { Count: > 1 } (:72), and the remark above it explains (:63-71): the SSR prerender pass resolves the events server-side and would happily paint a fully formed picker, dropdown and clear button included, into static HTML. Nothing is wired to it until the interactive runtime attaches, which under InteractiveAuto's WebAssembly leg is a whole runtime boot later, and every click landing in that window is swallowed with no feedback, leaving the list silently on the default event the prerender chose. Rendering the picker only once the component is interactive turns "the picker is on screen" into a truthful signal that a choice will be honored, for a reader and for an E2E wait alike. [Rubric §22, Responsive and Cross-Browser/Device] and [Rubric §24, Forms, Validation and UX Safety] both land on that one line, and ADR-056 is the render-mode policy it implements.
• Walkthrough:
  • Injected state (:27-50): the IEventLookupService, then Events (the id-to-EventInfo dictionary, null when the lookup failed), SelectedEventId (null meaning "all events"), EventFilterResolved (true once the scope is decided, restored or computed), EventsLoadFailed (so a page that must fail closed can branch rather than silently querying unscoped), and EventsLoadTask, the in-flight load. Every setter is private, so the base owns all transitions.
  • EventFilterIsUserControlled (:57): virtual, default true. It answers "does the reader pick the event themselves", which is what makes the choice worth persisting and worth restoring. PublicSpeakerList overrides it with a role check rather than a constant (MMCA.ADC.Conference.UI/Pages/Public/Speakers/PublicSpeakerList.razor.cs:53), so the same page is user-controlled for a privileged reader and locked to the computed event for everyone else.
  • CanRenderEventPicker and EventPickerOptions (:72, :79-80): the gate described above, and the ordered option list derived from it. Iterating EventPickerOptions instead of Events keeps every page's picker on one ordering (OrderBy(e => e.StartDate)) and keeps the markup free of the null handling the gate already did.
  • The three extension points (:83-95): ReloadForEventFilterAsync() is abstract, so a page cannot forget to reload; SavePageFilters / RestorePageFilters are virtual no-ops for page-specific values (search text, status dropdowns); OnEventsLoadingAsync() is a virtual hook for work that must run before the events are fetched, such as resolving whether the reader is privileged.
  • SaveFilters / RestoreFilters (:98-129): both are sealed override, which is the load-bearing detail. The base takes over the framework's two filter hooks, calls the page's hook first, then owns the eventId entry itself, so no derived page can accidentally drop the event scope from persisted state. The saved value is either the invariant-formatted id or the literal "all", and the comment states why the literal exists (:104): it distinguishes an explicit clear from no saved state, which would apply the default instead. Restore handles the three cases (absent, "all", parseable id) and sets EventFilterResolved only in the latter two.
  • OnInitializedAsync and BeginEventsLoad (:132-144): initialization starts the load before any await and then awaits it. BeginEventsLoad() is exposed separately so a derived page can start the event load, run its own non-event work concurrently, and only then await EventsLoadTask.
  • LoadEventsAndResolveDefaultAsync (:150-167): the hook, then the lookup with Result unwrapped by TryGetValue (see the primer on the Result pattern), then ResolveDefaultEventFilter(). A failure is non-fatal by design (:154-155): the picker stays hidden and the default filter stays unset, and the failure is remembered in EventsLoadFailed. The method is documented as callable again (:146-149), so a retry button heals a transient lookup failure.
  • ResolveDefaultEventFilter (:169-189): the precedence rule, stated in its comment (:171-172) and encoded in one condition. A restored id that still exists wins; a dangling one falls back to the computed default; and a page with a locked scope is always pinned to the computed current or next event, which is what stops a stale saved id from surviving an override of EventFilterIsUserControlled. The computation delegates to CurrentEventSelector.SelectCurrentOrNext over Events.Values (:182-187), the same selector the landing page uses, so "which event is current" has one implementation across the module.
  • WaitForEventsAsync (:192): returns the load task or Task.CompletedTask. The doc on EventsLoadTask (:44-49) says exactly when to await it: before any fetch that applies the event filter, because the grid's first ServerData call can race ahead of initialization completing. That race is why the task is a field rather than a local.
  • ApplyEventFilter (:195-199): adds EventId as an ("equals", value) pair to the outgoing filter dictionary, and only when an event is selected, so "all events" is the absence of a filter rather than a sentinel.
  • OnEventFilterChanged (:202-207): bound to the picker's ValueChanged. It sets the id, marks the scope resolved, and awaits the page's ReloadForEventFilterAsync(). A null value clears the scope.
  • GetEventName / SelectedEventName (:210-219): display helpers that degrade rather than throw, falling back to the raw id and to an empty string respectively when the lookup has nothing.
• Why it's built this way: [Rubric §19, State Management and Data Flow] is the through-line. There is one scope variable, one place that decides its default, one place that persists it, and one place that reloads on change, and the sealed override on the two persistence hooks is what keeps it that way as pages are added. [Rubric §11, Security] shows up in the EventsLoadFailed flag: a public reader whose lookup failed must not fall through to an unscoped query, so the flag exists specifically to let such a page fail closed, which PublicSpeakerList does through its ScopeUnresolvedForPublicReader() check (PublicSpeakerList.razor.cs:135). [Rubric §15, Best Practices & Code Quality]: five list pages share this, and each one's event handling is now three overrides.
• Where it's used: five Conference list pages derive from it, each pairing an @inherits directive with a partial class: SponsorList (MMCA.ADC.Conference.UI/Pages/Sponsors/SponsorList.razor.cs:19), SpeakerList (Pages/Speaker/SpeakerList.razor.cs:18), RoomList (Pages/Room/RoomList.razor.cs:12), ActivityList (Pages/Activity/ActivityList.razor.cs:19), and PublicSpeakerList (Pages/Public/PublicSpeakerList.razor.cs:33). The four organizer pages follow one shape verbatim (SavePageFilters/RestorePageFilters, ReloadForEventFilterAsync => ReloadActiveLayoutAsync(), await WaitForEventsAsync() before each fetch, ApplyEventFilter(filters) inside it); the public page is the variant that exercises every extension point, overriding EventFilterIsUserControlled (:53), OnEventsLoadingAsync (:91), and re-calling LoadEventsAndResolveDefaultAsync() on retry (:123).

PublicSessionListFilterState

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Public · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicSessionListFilterState.cs:12 · Level 0 · class (internal static)

• What it is: the translation layer between PublicSessionList's live filter fields and the flat string-to-string map that DataGridListPageBase<TDto> persists per page. Two static methods, Save and Restore, and no state of its own (PublicSessionListFilterState.cs:12).
• Depends on: only System.Globalization (:1) and the RoomIdentifierType / EventIdentifierType aliases. No component base, no injected service, no fetch. The class doc records the placement rule (:5-10): it is kept beside the page, like PublicScheduleRoomOptions, so the code-behind holds only the live filter fields and the handlers that change them.
• Concept introduced, persisted filter state as a pure, audience-aware codec. The list-page base can only persist strings, so every page that saves filters needs a codec. Writing it as a static pair rather than as two page methods buys three things worth naming.
  1. A sentinel that distinguishes "cleared" from "never set". Save writes "all" when a privileged reader has explicitly cleared the event filter (:42), because an absent key means "no saved state, apply the default" while an empty string would be ambiguous. Restore reads that sentinel back as an explicit null plus a resolved flag (:66-70). [Rubric §19, State Management & Data Flow] (assesses that restored state is distinguishable from absent state).
  2. Persistence itself is audience-scoped. persistEventId is a caller-supplied flag (:33) and the parameter doc states the rule (:22-26): only a privileged reader persists an event choice, because everyone else is always locked to the computed current or next event, so persisting it would only leak into shared URLs. The room filter, by contrast, is persisted for every audience, and the roomId doc says why in one sentence (:17-20): a room only ever narrows within the reader's own event. [Rubric §26, Front-End Security] (assesses that a client-persisted preference cannot widen what a reader sees) and [Rubric §11, Security].
  3. A restore never destroys a value it cannot read. Every branch in Restore is guarded by a TryGetValue plus a TryParse, and each parameter is passed in and returned out unchanged when the map has nothing usable (:57-90), so a corrupt or partial map degrades to "keep what the page already has" instead of resetting the view. [Rubric §24, Forms, Validation & UX Safety].
• Walkthrough
  • Save (:27-44): writes search verbatim (:35), the My Schedule toggle as an invariant bool string (:36), the room id as an invariant number or empty (:37), and the event id only when persistEventId is true, with the "all" sentinel for an explicit clear (:39-43).
  • Restore (:57-91): parses eventId first, accepting "all" case-insensitively as an explicit clear and any invariant integer as a pick, setting eventFilterResolved in both cases so the page knows not to recompute the default (:64-76); then roomId (:78-82), then mySchedule compared case-insensitively against "true" (:84-87); search falls back to empty (:89). The five values leave as one named tuple (:57, returned at :90) that the caller destructures straight into its fields.
  • The method doc records the one thing Restore deliberately does not do (:46-49): a restored room that the resolved event does not offer is dropped afterwards by the page's room-options rescope, not here, because this type never sees the events.
• Why it's built this way: the codec is pure and total, so its rules (the sentinel, the audience gate, the keep-on-unparseable behavior) can be exercised without a renderer, and the page keeps a two-line SaveFilters / RestoreFilters pair instead of forty lines of string handling. [Rubric §14, Testability] and [Rubric §1, SOLID].
• Where it's used: called only from PublicSessionList's sealed base overrides, SaveFilters (PublicSessionList.razor.cs:76-79, passing persistEventId: _isPrivileged && _eventFilterResolved) and RestoreFilters (PublicSessionList.razor.cs:82-85).

ScorePollSignal

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollTracker.cs:6 · Level 0 · enum (internal)

• What it is: the five-valued verdict that ScorePollTracker returns for one observation of the AI-scoring poll loop. It says what should happen next: keep waiting, re-render with fresh data, or stop and report an outcome.
• Depends on: nothing. It is a bare internal enum declared above the tracker in the same file (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollTracker.cs:6), visible to the bUnit test project through the project's InternalsVisibleTo (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/MMCA.ADC.Conference.UI.csproj:9).
• Concept introduced: the decision/effect split. [Rubric §18, UI Architecture] assesses whether components stay thin and free of tangled control flow; naming each outcome as an enum member is how that is achieved here. The decision (what did this poll mean?) is computed by a pure state machine, ScorePollTracker, and the effects (toast, re-render, stop the loop) are applied in a single switch inside ScorePollSession, so neither half has to know the other's internals. [Rubric §14, Testability] follows for free: the signal sequence for a synthetic count series can be asserted without rendering anything.
• Walkthrough: Continue (ScorePollTracker.cs:9) means nothing changed this tick, keep polling. Progressed (:12) means new scores arrived, so apply the fresh board, re-render, and keep polling. CompletedAll (:15) means every session now has a score, so apply and finish successfully. CompletedStable (:19) means the count has been unchanged long enough to call scoring done, with the success-versus-partial wording decided from coverage. GaveUpNoScores (:22) means no score was ever produced inside the zero-progress budget, so fail loudly rather than wait out the full cap.
• Why it's built this way: the poll loop has four terminal outcomes that each need a different user-facing message (complete, partial, timed out, never started). An enum makes the exhaustive switch in ScorePollSession readable and keeps that failure vocabulary in one place.
• Where it's used: returned by ScorePollTracker.RegisterFetch (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollTracker.cs:74) and consumed by ScorePollSession.HandleSignalAsync (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollSession.cs:117-145).

SessionSelectionDisplay

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionDisplay.cs:11 · Level 0 · class (static, internal)

• What it is: a stateless helper holding the display and filter-matching rules shared by the session-selection dashboard and its two presentational sub-components. It answers three kinds of question with no side effects: what color a status or score chip should be, whether a locality tier counts as local, and whether a session passes the active score-tier or status filter.
• Depends on: the MudBlazor Color enum (external NuGet, imported at SessionSelectionDisplay.cs:1). No first-party types: it is deliberately dependency-light so both SessionSelectionSpeakerOverlap and SessionSelectionAiScores can call the same predicates, and so can the page markup itself.
• Concept introduced: extracting view logic into testable pure functions. [Rubric §18, UI Architecture] rewards keeping decision logic out of .razor markup so it can be unit-tested and reused; [Rubric §14, Testability] is the same point from the other side. Every method here is static and total (each switch has a default arm), so the same input always yields the same color or boolean regardless of component state.
• Walkthrough: IsLocalTier (SessionSelectionDisplay.cs:13-16) folds three locality substrings (Atlanta, Georgia, Surrounding, all matched with StringComparison.OrdinalIgnoreCase) into one "is this speaker local" test. GetStatusColor (:18-27) maps six selection states (Accepted, Nominated, Accept_Queue, Waitlisted, Decline_Queue, Declined) onto MudBlazor semantic colors, with Color.Default as the fallback. GetScoreColor (:29-35) buckets a decimal score into four bands (at or above 8.0 success, 6.0 info, 4.0 warning, otherwise error). ScoreMatchesFilter (:37-48) turns a filter token ("9.0" down to "3.0", plus "<3.0") into a threshold predicate, with an unrecognized token matching everything; <3.0 is the only strict-less-than case. MatchesAcceptedFilter (:50-51) and SessionMatchesStatus (:53-56) encode a subtle rule: when the filter is Accepted, a session whose status is null also matches, because an unset status is treated as accepted by default; every other filter is a plain case-insensitive equality test.
• Why it's built this way: the two sibling sections filter over different DTO shapes but must agree on what "score tier 8.0" or "status Accepted" means; hoisting the rules here guarantees they never drift apart. The tier tokens it understands are exactly the values SessionSelectionFilters.ScoreTierOptions offers in the picker.
• Where it's used: by SessionSelectionSpeakerOverlap (SessionMatchesStatus and ScoreMatchesFilter, MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionSpeakerOverlap.razor.cs:62 and :69), by SessionSelectionAiScores (MatchesAcceptedFilter and ScoreMatchesFilter, .../SessionSelectionAiScores.razor.cs:48 and :63), and directly from markup for chip coloring: .../SessionSelectionAiScores.razor:72 and :76, .../SessionSelectionSpeakerOverlap.razor:45, :61, :65, and the locality tiles on the page itself (.../SessionSelectionDashboard.razor:194).

ScorePollTracker

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollTracker.cs:31 · Level 1 · class (sealed, internal)

• What it is: the pure state machine behind the dashboard's fire-and-forget AI-scoring poll loop. It counts progress, stability, zero-progress polls, and consecutive failures, and converts each observation into a ScorePollSignal. It performs no I/O and touches no UI.
• Depends on: nothing first-party except the co-located ScorePollSignal enum it returns; its whole state is four int fields.
• Concept introduced: taming a fire-and-forget loop with an explicit budget. [Rubric §12, Performance and Scalability] and [Rubric §29, Resilience and Business Continuity] both ask whether long-running work has bounded cost and a defined give-up path, and this class is where those bounds are written down as named constants instead of being scattered through a component. The class doc names the motivation directly (ScorePollTracker.cs:25-30): the state machine was extracted from the page code-behind so the component keeps only the UI side effects, which is the [Rubric §18, UI Architecture] concern about component size. [Rubric §14, Testability] applies because the whole loop policy can be exercised by calling RegisterFetch with a synthetic count series, with no timers and no rendering.
• Walkthrough: two public constants set the outer limits. MaxPolls = 225 (ScorePollTracker.cs:34, documented as a 30-minute cap at 225 polls times an 8-second interval) and MaxConsecutiveFailures = 5 (:41), whose doc comment explains why failures are tolerated at all: the polling task is fire-and-forget, so an escaping exception would be unobserved and would wedge the Score button until a full reload. Two private constants set the inner heuristics: ZeroProgressLimit = 10 (:48, roughly 80 seconds with no scores saved at all, aimed at the silent-fail case such as a missing API key) and StablePollsForCompletion = 3 (:51). Four fields carry the state (:53-56): _previousCount, _stablePolls, _zeroProgressPolls, _consecutiveFailures. ResetFailures (:59) zeroes the failure counter after any successful fetch; RegisterFailure (:65-69) increments it and returns true once the budget is exhausted. RegisterFetch(currentCount, totalSessions) (:74-105) is the core: a zero count increments _zeroProgressPolls and returns GaveUpNoScores at the limit, otherwise Continue (:76-82); any nonzero count clears the zero-progress counter (:84); a count greater than the previous one advances _previousCount, resets _stablePolls, and returns CompletedAll when the count has reached totalSessions (guarded by totalSessions > 0) or Progressed otherwise (:86-93); an unchanged count increments _stablePolls and returns CompletedStable at three (:95-102); anything else returns Continue (:104).
• Why it's built this way: server-side AI scoring is a batch whose duration depends on an external model, so the UI has no completion event to await and must infer completion from the score count. Treating completion as either full coverage or three unchanged polls yields an answer even when some sessions fail to score, and the separate zero-progress budget turns the common credential-failure case into a fast, loud error rather than a 30-minute silence.
• Where it's used: instantiated once per scoring run by ScorePollSession.RunAsync (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollSession.cs:55), whose for loop bounds itself with ScorePollTracker.MaxPolls (:57).
• Caveats / not-in-source: the latency claim in the MaxPolls comment ("enough for ~200+ sessions at typical Haiku latency", ScorePollTracker.cs:33) is a code comment, not a measurement recorded in this repo.

PublicScheduleRoomOptions

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Public · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/PublicScheduleRoomOptions.cs:13 · Level 3 · class (internal static)

• What it is: the pure functions behind the public schedule's Room picker and Room column. Given the events PublicSessionList has already loaded, IndexNames builds the id-to-name map the list renders with, and Scope returns the ordered room options for the active event filter plus the room filter that survives that scoping (PublicScheduleRoomOptions.cs:20, :37).
• Depends on: RoomDTO and EventDTO from MMCA.ADC.Conference.Shared.Events (:1), plus the RoomIdentifierType and EventIdentifierType aliases. Nothing else: no injected service, no fetch, no component base.
• Concept introduced, the derived filter option set with a self-healing selection. Two ideas are worth extracting from a sixty-line file.
  1. Derive, do not fetch. The class doc states the rule (:5-9): the page already reads /events?includeChildren=true, so its rooms are in memory and narrowing the schedule by room costs zero extra round trips. The same doc records the security consequence that comes for free: that events read is published-only for non-privileged audiences server-side, so an unpublished event's rooms can never reach the picker. [Rubric §23, Front-End Performance & Rendering] (assesses avoidable network work per interaction) and [Rubric §26, Front-End Security] (assesses that a client-derived option set cannot widen what the server already scoped).
  2. A selection that cannot go stale. The last block of Scope (:53-55) re-validates selectedRoomId against the freshly scoped list and returns null when the room is no longer offered. The comment names both ways that happens (:51-52): the reader switched events, or a stale choice was restored from saved page state by PublicSessionListFilterState. Without it, an unreachable room id would filter every session out and the reader would see an empty schedule with no visible cause. [Rubric §19, State Management & Data Flow] (assesses that derived state is reconciled rather than left to drift) and [Rubric §24, Forms, Validation & UX Safety].
• Walkthrough
  • IndexNames (:18-27): a nested loop over every loaded event's Rooms, adding each Id-to-Name pair with TryAdd (:24) so a room that two loaded events both reference is indexed once rather than throwing. The map it fills is the page's own _roomNames dictionary, added to in place (:17), which is what the list's Room column and mobile card line read.
  • Scope (:37-58): scoping (:42-44), where a non-null eventId takes that event's Rooms (an unknown id yields an empty list through the ?? [] fallback) and a null id, which only a privileged reader viewing every event can produce, takes the union across all loaded events; shaping (:46-49), DistinctBy(r => r.Id) because the union can repeat a room, then OrderBy(Sort).ThenBy(Name, StringComparer.OrdinalIgnoreCase) so the picker order is the organizer's intended order with a deterministic case-insensitive tiebreak; reconciliation (:53-55) and the tuple return (:57), which the caller destructures straight into its two fields.
• Why it's built this way: keeping this out of the page makes it a plain static function over data, directly unit-testable without a renderer, and it keeps the page's own code down to one line (PublicSessionList.razor.cs:154-155). [Rubric §14, Testability] and [Rubric §1, SOLID].
• Where it's used: IndexNames is called once per events load (PublicSessionList.razor.cs:142); Scope is called by that page's RefreshRoomOptions (:151-152), from the initial load (:147) and from every event-filter change (:216). The options it returns are passed down to PublicSessionListFilterBar's Rooms parameter and the surviving id to its SelectedRoomId.

ScorePollHost

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollSession.cs:19 · Level 4 · record (sealed, internal)

• What it is: the five-callback contract a ScorePollSession uses to reach back into the page that started it. The polling session owns no rendering: everything it needs from the component (the current load generation, the poll cadence, applying a board, re-rendering, finishing with a message) arrives as a delegate in this record.
• Depends on: SessionSelectionDashboardDTO (the payload of ApplyFreshDashboard) and ToastSeverity (the severity of the finish message), plus BCL Func<>, Action<>, Task, and TimeSpan. It is a positional record with no body.
• Concept introduced: the callback record as an inverted UI port. [Rubric §1, SOLID] assesses dependency inversion and interface segregation: rather than handing the loop a reference to the whole component (which would let it touch any field and would make it untestable outside a renderer), the component passes exactly the five capabilities the loop needs, each as its own delegate. [Rubric §19, State Management] is the reason this shape exists at all: two of the five members are readers, not values. CurrentGeneration and PollInterval are Func<> rather than captured snapshots so the loop re-reads the page's live state on every tick, which is what lets an event switch supersede a running session mid-flight and lets a bUnit test shrink the cadence after the loop has already started.
• Walkthrough: CurrentGeneration (ScorePollSession.cs:20) reads the page's _loadGeneration counter, the value the loop compares its own generation against to decide it has been superseded. PollInterval (:21) reads the page's cadence, re-read every tick (:15). ApplyFreshDashboard (:22) hands a freshly polled SessionSelectionDashboardDTO to the page, which swaps it in and recomputes the derived state. RenderAsync (:23) is the component's InvokeAsync(StateHasChanged), so the re-render is marshalled onto the renderer's synchronization context from whatever thread the loop resumed on. FinishScoring (:24) ends the scoring session and surfaces the outcome as a toast, taking the message and a ToastSeverity.
• Why it's built this way: the doc comment states the rule (:9-13): the loop raises side effects, the page performs them, so StateHasChanged, the toasts, and the generation counter that supersedes a stale session all stay on the component. Making the port a record of delegates instead of an interface keeps the wiring to one expression at the call site and avoids a second implementation existing only for tests.
• Where it's used: constructed inline by SessionSelectionDashboard.PollForScoresAsync (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionDashboard.razor.cs:219-224) and consumed throughout ScorePollSession.

SessionSelectionAiScores

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionAiScores.razor.cs:12 · Level 4 · class (partial component)

• What it is: the presentational AI-scores section of the selection dashboard. It renders the "Score Sessions with AI" action with its in-progress state and the per-session score table, narrowed by the parent's active filters. The scoring flow itself stays on the containing page and is triggered upward through an EventCallback.
• Depends on: SessionSelectionDashboardDTO and its SessionAiScoreDTO rows (imported at SessionSelectionAiScores.razor.cs:2), SessionSelectionDisplay for the shared predicates, and the Blazor [Parameter] and EventCallback infrastructure from Microsoft.AspNetCore.Components (external, :1).
• Concept introduced: lifting the action up via EventCallback. [Rubric §19, State Management] favors child components that raise intent rather than own the operation; here the child never calls a service. The scoring trigger is exposed as [Parameter] public EventCallback ScoreRequested (:16) alongside an IsScoring flag the parent flips (:15), so the long-running scoring loop, its cancellation, and its toasts all live in SessionSelectionDashboard while this section only shows the button and the progress state. Like its sibling it is otherwise a pure function of its parameters (:14-21): the whole Dashboard DTO plus the same five filter strings, each defaulting to empty.
• Walkthrough: HasActiveFilters (:23-26) is a cheap short-circuit over the five filter strings. FilteredAiScores (:28-40) returns an empty list when the board has no scores yet (:32-33), returns Dashboard.AiScores untouched when no filter is active (:35-36), and otherwise materializes ApplyAiScoreFilters into an array with a collection expression (:38). ApplyAiScoreFilters (:42-66) is a straight pipeline of Where clauses over the flat score rows: status, applying the same null-equals-Accepted rule through SessionSelectionDisplay.MatchesAcceptedFilter (:46-51); locality against the row's SpeakerLocalities collection (:53-54); category against SessionCategories (:56-57); level as a case-insensitive equality on SessionLevel (:59-60); and score tier via ScoreMatchesFilter on OverallScore (:62-63). The markup colors each row's status and score chip through the same helper (.../SessionSelectionAiScores.razor:72 and :76).
• Why it's built this way: the score table is a flat DTO list, so its filter pipeline is simpler than the speaker section's nested rebuild; sharing SessionSelectionDisplay keeps the two sections' notion of "matches this filter" identical even though their data shapes differ. Keeping the pipeline lazy until one final materialization avoids an intermediate array per filter stage ([Rubric §23, Front-End Performance]).
• Where it's used: rendered inside SessionSelectionDashboard's markup (.../SessionSelectionDashboard.razor:228-235), where its ScoreRequested callback invokes the page's ScoreSessionsAsync (.../SessionSelectionDashboard.razor.cs:161); covered by SessionSelectionAiScoresTests in the Conference UI bUnit tier (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Pages/SessionSelection/SessionSelectionAiScoresTests.cs).

[Rubric §16, AI-Native Application Architecture] applies: this type is part of the AI session-scoring feature (a model call behind a port, versioned prompt and model, an evaluation gate, metered spend; ADR-111).

SessionSelectionFilterOptions

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionFilterOptions.cs:11 · Level 4 · record (sealed, internal)

• What it is: the four dropdown option lists the dashboard's filters bind to (statuses, localities, categories, levels), together with the pure projection that derives them from a loaded board. It holds no page state: it is the answer to "given this dashboard, what can the organizer filter by?".
• Depends on: SessionSelectionDashboardDTO as the projection input (imported at SessionSelectionFilterOptions.cs:1), reading its SpeakerOverlap.Speakers, AiScores, SpeakerLocality, and CategoryDistribution.Categories collections. Externally it is LINQ plus StringComparer.OrdinalIgnoreCase.
• Concept introduced: the derived-option projection as a static factory on a record. [Rubric §19, State Management] distinguishes stored state from derived state; option lists are derived, so they are computed by one static method from the board and never edited afterwards. [Rubric §14, Testability] follows: the whole "what shows up in the pickers" rule set is one pure function of a DTO. The four IReadOnlyList<string> members (:12-15) are positional record parameters, so instances are immutable by construction.
• Walkthrough: a private static readonly Empty instance (:17) is the null-board answer, so callers never get null lists and no allocation happens on the not-yet-loaded path. From(SessionSelectionDashboardDTO?) (:20-54) returns Empty for a null board (:22-25), then derives each list. Statuses (:28-33) come from the union of every multi-session speaker's sessions and every AI-score row, with null normalized to "Accepted" (the same default SessionSelectionDisplay.SessionMatchesStatus applies), then de-duplicated and ordered case-insensitively. Localities (:35-37) are the LocalityTier values from the board's locality breakdown, ordered the same way. The level group is picked out by a CategoryTitle.Contains("Level") match (:39-40), and its items become the level list (:42-44); if no such group exists the list is empty. Categories (:46-51) then take every other category group's items, so the Level values do not appear twice in two different pickers, de-duplicated and ordered. All four use collection expressions over LINQ, materializing once at the end.
• Why it's built this way: the option lists must reflect only what the loaded event actually contains, otherwise the organizer can select a filter that matches nothing. Deriving statuses from both the speaker-overlap sessions and the score rows covers both child sections, and splitting the Level group out of the category options mirrors the two separate pickers in the markup (.../SessionSelectionDashboard.razor:90-107).
• Where it's used: called only by SessionSelectionFilters.ComputeOptions (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionFilters.cs:74), which copies the four lists onto the page's filter state.
• Caveats / not-in-source: the level group is identified by a title substring match, so it depends on the conference's category naming ("Level"). The category titles themselves come from the Conference data, not from this file.

ScorePollSession

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/ScorePollSession.cs:36 · Level 5 · class (sealed, internal)

• What it is: one fire-and-forget AI-score polling run for the selection dashboard. It drives ScorePollTracker (the pure counters) over repeated dashboard fetches and turns each resulting ScorePollSignal into the page's UI side effects through a ScorePollHost.
• Depends on: ISessionSelectionUIService for the fetch, IStringLocalizer for the outcome messages, and a ScorePollHost for the callbacks, all primary-constructor parameters (ScorePollSession.cs:36-39). Internally it uses ScorePollTracker, ScorePollSignal, SessionSelectionDashboardDTO, and ToastSeverity; externally Task.Delay, CancellationToken, and the Conference EventIdentifierType alias.
• Concept introduced: the generation guard against a superseded async loop. [Rubric §19, State Management] asks whether asynchronous work can corrupt state it no longer owns. A polling run belongs to the event that was selected when scoring started; if the organizer switches events, the page bumps a generation counter and this loop, which re-reads that counter through host.CurrentGeneration(), exits instead of painting the previous event's board (and its toasts) over the new selection. Note the counter is checked twice per tick, once after the delay and once after the fetch (:62 and :68), because both are await points where the selection can move. [Rubric §29, Resilience and Business Continuity] covers the second concept here: because ISessionSelectionUIService answers every non-2xx response and transport fault with a failed Result rather than an exception (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Sessions/Selection/ISessionSelectionUIService.cs:11-23), the consecutive-failure budget has to be fed from the result path, and the code comment says exactly why (:73-77): left on the exception path it would be dead code and a persistently failing endpoint would poll silently to MaxPolls without ever reporting.
• Walkthrough: RunAsync(eventId, generation, cancellationToken) (:50-108) creates a tracker (:55) and loops up to ScorePollTracker.MaxPolls times (:57). Each iteration awaits host.PollInterval() under the page's disposal token (:61), checks the generation (:62-65), fetches the board through selectionService.GetDashboardAsync (:67), and checks the generation again (:68-71). A failed Result feeds tracker.RegisterFailure(), and when the budget is exhausted the run reports Snackbar.ScoringPollFailed as an error and returns (:78-82); a failure inside budget falls through to continue because TryGetValue yields nothing (:84-87). A successful fetch resets the failure counter (:89) and passes AiScores.Count and TotalSessions to tracker.RegisterFetch, handing the resulting signal to HandleSignalAsync; a true return means the run is over and the finish callback has already fired (:90-93). OperationCanceledException exits quietly, which is component disposal (:95-99). Falling out of the loop means the cap was reached, so, unless the run has meanwhile been superseded (:102-105), it reports Snackbar.ScoringTimedOut as a warning (:107). HandleSignalAsync (:117-145) is the effects half of the split introduced under ScorePollSignal: GaveUpNoScores finishes with an error (:121-123), Progressed applies the board and re-renders but keeps going (:125-128), CompletedAll applies, re-renders, and finishes with a success message carrying the score count (:130-134), CompletedStable applies and defers to FinishStable (:136-139), and Continue does nothing (:141-143). FinishStable (:149-163) compares AiScores.Count against TotalSessions and reports either Snackbar.ScoringPartial with the missed count as a warning or Snackbar.ScoringComplete as a success.
• Why it's built this way: the class doc states the placement rule (:26-32): the session was extracted from the page code-behind under the rubric §18 line cap, and it stays beside the page rather than moving into ISessionSelectionUIService because every step it takes is a rendering decision, not a data-access one. Every user-visible string is a resource key resolved through the injected localizer, so the outcome messages follow a language switch like the rest of the page (ADR-027, Website/docs-src/adr/027-multi-locale-i18n.md).
• Where it's used: constructed and run by SessionSelectionDashboard.PollForScoresAsync (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionDashboard.razor.cs:216-228). Its supersede behavior is asserted end to end by WhenEventChangesMidScoring_ThePollingSessionStopsWithoutTouchingTheNewBoard (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Pages/Sessions/Selection/SessionSelectionStaleResponseTests.cs:217).
• Caveats / not-in-source: the resource keys used here (Snackbar.ScoringPollFailed, Snackbar.ScoringNoScores, Snackbar.ScoringComplete, Snackbar.ScoringPartial, Snackbar.ScoringTimedOut) resolve against the page's localizer, which the caller supplies; their text lives in SessionSelectionDashboard.resx and SessionSelectionDashboard.es.resx, not in this file.

SessionSelectionFilters

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionFilters.cs:13 · Level 5 · class (sealed, internal)

• What it is: the dashboard's filter state object. It holds the five selected values the markup two-way binds to (an empty string means "all") plus the four option lists derived from the loaded board, and it exposes the localized score-tier choices.
• Depends on: SessionSelectionFilterOptions for the derivation, SessionSelectionDashboardDTO as the input to ComputeOptions, and IStringLocalizer (external, SessionSelectionFilters.cs:1) for the tier labels.
• Concept introduced: the bindable state object as a component field. [Rubric §19, State Management] is the whole point: five separate _filterX fields on the page would be five things to reset, five things to pass down, and five things to keep in step with their option lists. Collapsing them into one object lets the markup bind @bind-Value="_filters.Status" directly (.../SessionSelectionDashboard.razor:70) and lets the page reset or recompute everything with one call. [Rubric §18, UI Architecture] is the stated motive in the class doc (:6-12): extracted from the code-behind under the line cap so the component keeps only its load and scoring orchestration. [Rubric §27, i18n] shows in ScoreTierOptions, which is a method taking a localizer rather than a stored list, "so the labels follow a language switch" (:42-45, ADR-027).
• Walkthrough: the five selections are plain get; set; string properties defaulting to empty (:16-28): Status, Locality, Category, Level, ScoreTier. The four option lists (:31-40) are IReadOnlyList<string> with private set, so only this class can replace them; they start empty. ScoreTierOptions(IStringLocalizer) (:47-58) is static and returns nine label/value tuples pairing a localized label with the token SessionSelectionDisplay.ScoreMatchesFilter understands: the empty string for "all", then "9.0" down to "3.0", then "<3.0" for Poor; the markup enumerates it directly (.../SessionSelectionDashboard.razor:112). Reset() (:61-68) clears all five selections back to "all". ComputeOptions(SessionSelectionDashboardDTO?) (:72-79) delegates the projection to SessionSelectionFilterOptions.From and copies its four lists across, so a null board yields four empty lists rather than a null reference.
• Why it's built this way: separating selection (mutable, bound to the UI) from projection (pure, derived from data) means a reload can recompute the options without disturbing the selections, and a fresh load can reset both with two calls. The page uses exactly that asymmetry: SessionSelectionDashboard.LoadDashboardAsync calls Reset() then ComputeOptions(...) for a new board (.../SessionSelectionDashboard.razor.cs:133-134), while ApplyFreshDashboard calls only ComputeOptions(...) mid-poll (:240), so the organizer's active filters survive a polling update.
• Where it's used: one instance is a readonly field on SessionSelectionDashboard (.../SessionSelectionDashboard.razor.cs:43), bound by the five MudSelect pickers in the page markup (.../SessionSelectionDashboard.razor:70-115) and passed down as parameters to SessionSelectionSpeakerOverlap (:221-225) and SessionSelectionAiScores (:231-235).

SessionSelectionSpeakerOverlap

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionSpeakerOverlap.razor.cs:11 · Level 7 · class (partial component)

• What it is: the presentational "speakers with multiple sessions" section of the selection dashboard. It lists each multi-session speaker with their locality and per-session status and score chips, narrowed to whatever filters the parent dashboard currently has active.
• Depends on: MultiSessionSpeaker and SpeakerSessionSummary (the DTOs it renders, imported at SessionSelectionSpeakerOverlap.razor.cs:2), SessionSelectionDisplay for the shared predicates, the SessionIdentifierType alias, and the Blazor [Parameter] infrastructure (external, :1).
• Concept introduced: the presentational (dumb) child component. [Rubric §19, State Management] distinguishes components that own state from components that only render state passed in; this is the second kind. It has no service injections and no mutable fields, only [Parameter] inputs (:13-19): the Speakers list, an AiScoreLookup dictionary from session id to score, and the five filter strings, each defaulting to empty. All state flows down from SessionSelectionDashboard, which makes this component a pure function of its parameters. [Rubric §18, UI Architecture] is served by keeping the filtering in the code-behind and the template thin.
• Walkthrough: HasActiveFilters (:21-24) is a cheap short-circuit: when every filter string is empty the component returns Speakers unfiltered and only sorts. FilteredSpeakerOverlap (:26-36) is the computed view the markup binds to; it applies filters when any are set, then orders speakers case-insensitively by name (:34). ApplySpeakerFilters (:38-59) works in two passes: the locality filter drops whole speakers by comparing LocalityCategory ?? "Unknown" against the selection (:42-46); then, if any session-level filter is set, a record with expression rebuilds each speaker's Sessions collection keeping only matching sessions, and speakers left with zero sessions are dropped (:48-56). SessionMatchesFilters (:61-65) ands together the status test (delegated to SessionSelectionDisplay.SessionMatchesStatus), a category and a level test that both search the session's CategoryItemNames, and the score-tier test. SessionMatchesScoreTier (:67-69) looks the session up in AiScoreLookup and returns false when the session has no score yet, so an active score-tier filter hides unscored sessions.
• Why it's built this way: rebuilding the speaker record with a filtered Sessions list (rather than hiding rows in markup) means the "drop empty speakers" rule and the sort both operate on already-filtered data, so the rendered list and any counts derived from it stay consistent. The with copy leaves the source DTOs untouched, which matters because the parent keeps rendering from the same board.
• Where it's used: rendered inside SessionSelectionDashboard's markup (.../SessionSelectionDashboard.razor:219-225), fed the board's speakers, the page's _aiScoreLookup, and the five values off SessionSelectionFilters; covered by SessionSelectionSpeakerOverlapTests in the Conference UI bUnit tier.

SessionSelectionDashboard

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Sessions.Selection · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/Selection/SessionSelectionDashboard.razor.cs:16 · Level 9 · class (partial component)

• What it is: the organizer decision-support page for choosing a conference program. It picks an event (defaulting to the current or next one), loads its decision-support DTO (category distribution, speaker overlap, content similarity, locality breakdown, AI scores), owns the filter state the two child sections read, and starts the asynchronous "score all sessions with AI" flow.
• Depends on: ISessionSelectionUIService (loads the board and starts scoring), IEventLookupService (the event picker source), and IToastService, all injected as properties (SessionSelectionDashboard.razor.cs:18-20); SessionSelectionDashboardDTO, EventInfo, CurrentEventSelector, ConferenceRoutePaths, ToastSeverity, and the co-located SessionSelectionFilters, ScorePollSession, and ScorePollHost. It composes SessionSelectionSpeakerOverlap and SessionSelectionAiScores in its markup, and the page is routed and role-gated in the .razor half (@page "/sessions/selection-dashboard" with [Authorize(Roles = "Organizer")], .../SessionSelectionDashboard.razor:1-2).
• Concept introduced: the smart (container) component that owns state and lifecycle, and the load-generation counter. This is the counterpart to the two presentational sections above. [Rubric §19, State Management] is fully exercised: the component holds the loaded DTO, the selected event id, the filter object, the _aiScoreLookup, and the loading and error flags (:21-45), and passes what the children need down as parameters. The generation counter _loadGeneration (:38) is the concept worth learning here: any await in a Blazor page is a window in which the user can change the selection, so every asynchronous result must prove it is still wanted before it writes anything. The field's doc comment (:32-37) explains why the generation and not the event id is authoritative: switching away from an event and back must still discard the first response even though both carry the same id. [Rubric §18, UI Architecture] is served by splitting a large page into a container, two presentational children, an extracted filter object, and an extracted polling session. [Rubric §14, Testability] shows in internal TimeSpan PollInterval (:203), documented as internal precisely so bUnit tests can shrink the cadence and exercise the loop quickly (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Pages/Sessions/Selection/SessionSelectionDashboardTests.cs:306). [Rubric §27, i18n] applies throughout: every user-visible string resolves through the injected IStringLocalizer<SessionSelectionDashboard> (.../SessionSelectionDashboard.razor:5) against the co-located SessionSelectionDashboard.resx and its .es.resx translation (ADR-027). [Rubric §11, Security] applies with the usual caveat that the Organizer role attribute is a UX gate; the services behind it enforce authorization independently.
• Walkthrough: the component implements IDisposable and owns a CancellationTokenSource (:21) that every service call threads through; Dispose cancels and disposes it exactly once via the guarded _disposed pattern (:251-273). OnInitializedAsync (:47-87) builds the three breadcrumbs (:49-54), loads the events, and defaults the picker through CurrentEventSelector.SelectCurrentOrNext (:67-72: live now, else next upcoming, else most recently ended), then loads the board; OperationCanceledException is swallowed as disposal and IsLoading is cleared in the finally (:79-86). OnEventSelectedAsync (:89-105) bumps _loadGeneration before the selection moves (:94), so both the load path and the clear path supersede anything in flight. LoadDashboardAsync (:107-154) is the generation pattern in full: it snapshots the generation and the requested id (:114-115), turns the spinner on, fetches, and then returns early if superseded (:127-128, with the comment noting that a superseded failure must not paint an error banner over a board that loaded fine); on success it stores the board, calls _filters.Reset() and _filters.ComputeOptions(...), and rebuilds the score lookup (:130-136); and even the finally is generation-guarded so a stale response cannot switch off the spinner a newer load just turned on (:149-152). RebuildAiScoreLookup (:156-159) projects the score rows into a SessionId to OverallScore dictionary for the speaker section. ScoreSessionsAsync (:161-200) sets _isScoring, clears the visible scores with a with expression, and calls the service; a failed Result (including the 409 already-running or queue-full conflict) toasts an error and clears the flag (:173-179), a SessionsScored == -1 result means the server accepted the work asynchronously so it toasts "started" and launches the fire-and-forget PollForScoresAsync (:180-184), and a synchronous result toasts the scored and failed counts and reloads (:185-191). The closing comment (:197-199) documents why there is no finally here: only the accepted asynchronous path leaves _isScoring set, handing ownership of the flag to the polling task. PollForScoresAsync (:210-235) builds a ScorePollSession with the service, the localizer, and a ScorePollHost wired to _loadGeneration, PollInterval, ApplyFreshDashboard, InvokeAsync(StateHasChanged), and FinishScoring (:215-223), runs it, and clears _isScoring in a finally so the Score button always comes back whatever path exits the loop (:229-234). ApplyFreshDashboard (:237-242) swaps the board in and recomputes the options and the lookup, deliberately without resetting the filters. FinishScoring (:244-249) clears the flag, shows the toast, and requests a re-render.
• Why it's built this way: AI scoring is a long, failure-prone batch that depends on an external model with variable latency, so the page cannot block on it and there is no server push channel for this surface. Delegating the loop to ScorePollSession and the counting policy to ScorePollTracker leaves this class holding only lifecycle, state, and UI effects, which is what keeps a page with this much behavior inside the rubric §18 size expectation. Cancelling the token on disposal stops the loop from outliving the page, and the generation counter stops it from outliving its event.
• Where it's used: the organizer route /sessions/selection-dashboard, reachable from the admin navigation registered by ConferenceUIModule; covered by SessionSelectionDashboardTests and SessionSelectionStaleResponseTests in the Conference UI bUnit tier (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Pages/SessionSelection/).
• Caveats / not-in-source: the -1 sentinel on SessionsScored is what distinguishes a deferred scoring start from a synchronous one; its meaning is documented on ISessionSelectionUIService (.../Services/ISessionSelectionUIService.cs:15-20) and produced by the server-side handler, not by this component. The model used for scoring, its per-session timeout, and its failure modes are not determinable from this file.

CategoryItemInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/ICategoryItemLookupService.cs:9 · Level 0 · record

• What it is: a four-field projection record carrying everything a Conference page needs to render one category item: Id, Name, CategoryId, and the parent category's CategoryTitle (ICategoryItemLookupService.cs:9-13). It is the value type of the category-item lookup dictionary, not a wire contract and not a domain type.
• Depends on: no first-party types. Its two id parameters use the Conference identifier aliases CategoryItemIdentifierType and ConferenceCategoryIdentifierType, both int in this module (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:6-7). BCL string.
• Concept introduced, the UI lookup projection. [Rubric §18, UI Architecture] (assesses whether the front end keeps its own display-shaped models instead of dragging server contracts through the render tree; this record is a UI-owned shape with three display fields and one key). [Rubric §23, Front-End Performance] (assesses avoiding per-row round-trips: a list page holds category item ids but must render category item names, so the page pre-loads a dictionary of these records once and indexes it during render instead of issuing one request per row). [Rubric §19, State Management] (the dictionary is page-local state loaded once, not an ambient store). The same shape repeats for events and speakers, see EventInfo and SpeakerInfo.
• Walkthrough: a positional record with four members and no body.
  • Id (ICategoryItemLookupService.cs:10): the dictionary key.
  • Name (line 11): the item's display name, for example a track or level value.
  • CategoryId (line 12): the owning category, which lets a page group items by category without a second fetch.
  • CategoryTitle (line 13): the parent category's title, denormalized onto the item. It is filled in by CategoryItemLookupService from a separate categories request and falls back to string.Empty when the parent title is not found (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/CategoryItemLookupService.cs:78-79).
• Why it's built this way: the denormalized CategoryTitle exists so a page can render the combined label without holding a second dictionary. SessionLookups does exactly that: string.IsNullOrEmpty(item.CategoryTitle) ? item.Name : $"{item.CategoryTitle}: {item.Name}" (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Sessions/SessionLookups.cs:168), and PublicSessionDetail uses the same expression (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/Sessions/PublicSessionDetail.razor.cs:215). The empty-title fallback keeps the label sensible rather than rendering a stray colon.
• Where it's used: produced by CategoryItemLookupService behind ICategoryItemLookupService; consumed by SessionLookups (SessionLookups.cs:35), which serves SessionDetail, by PublicSessionDetail (PublicSessionDetail.razor.cs:31), and, gathered with two sibling dictionaries, by SpeakerDetailLookups.

ChildEntityDeletePath

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/ChildEntityServices.cs:76 · Level 0 · class

• What it is: an internal static helper with a single generic method that builds the "{childId}?{parent}={parentId}" suffix the join endpoints' DELETE takes (ChildEntityServices.cs:76-87). It is the smallest type in this group and the one that decides whether a removal works at all.
• Depends on: no first-party types. BCL Convert, CultureInfo.InvariantCulture (ChildEntityServices.cs:1), Uri.EscapeDataString, string.Concat.
• Concept introduced, the parent-scoped child delete. [Rubric §9, API & Contract Design] (assesses whether the client speaks the URL shape the server actually implements). The join controllers remove a row by loading the OWNING aggregate and asking it to drop the child, so the parent id is not decoration: the class doc records that a DELETE sent without it binds the parent id to its default value, that aggregate is never found, and the API answers 404 while the UI reports a generic failure (ChildEntityServices.cs:14-21, :71-75). [Rubric §15, Best Practices & Code Quality]: the whole difference between a working removal and a 404 lives in this one place instead of being concatenated at four call sites. [Rubric §26, Front-End Security] in its smallest form: the parent id is percent-encoded before it reaches the query string.
• Walkthrough: one method, For<TChildId, TParentId>(TChildId childId, string parentName, TParentId parentId) (ChildEntityServices.cs:78), constrained where TChildId : notnull and where TParentId : notnull (lines 79-80). The body is a single string.Concat (lines 81-86) that formats the child id with Convert.ToString(..., CultureInfo.InvariantCulture) (invariant so an int id never picks up a culture-specific group separator), appends "?", the caller's parameter name and "=", then the parent id through the same invariant conversion wrapped in Uri.EscapeDataString. Both conversions fall back to string.Empty on a null result. The generic parameters matter because Conference ids are not one type: SpeakerIdentifierType is a System.Guid while every other alias here is int (MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:5-21).
• Why it's built this way: the shared ChildEntityServiceBase appends whatever string it is given straight onto the endpoint, var url = $"{endpoint}/{id}" (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/ChildEntityServiceBase.cs:75), so the query has to be baked into the "id" argument. Keeping that formatting in one internal helper rather than in the framework base keeps the base generic while making the Conference-specific convention explicit.
• Where it's used: all four join services in the same file, each supplying its own parent parameter name: EventSpeakerService with "eventId" (ChildEntityServices.cs:29), SessionSpeakerService with "sessionId" (line 42), SessionCategoryItemService with "sessionId" (line 55), and SpeakerCategoryItemService with "speakerId" (line 68).

ICategoryItemLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/ICategoryItemLookupService.cs:18 · Level 3 · interface

• What it is: the contract for the category-item lookup: fetch everything once, hand back a dictionary wrapped in a Result (ICategoryItemLookupService.cs:18-22).
• Depends on: CategoryItemInfo (the dictionary value), the CategoryItemIdentifierType alias, and Result<T> from MMCA.Common.Shared.Abstractions (ICategoryItemLookupService.cs:1). BCL Task, IReadOnlyDictionary, CancellationToken.
• Concept introduced, the bulk-then-index lookup contract. [Rubric §23, Front-End Performance] (assesses how many round-trips a render costs; one call plus O(1) dictionary reads replaces one request per referenced id) and [Rubric §1, SOLID] (a single-method interface is the smallest dependency a page can take, and it is what the UI tests substitute). Returning IReadOnlyDictionary<,> rather than a list is the point of the contract: the caller is told, by the type, that this is a key-indexed cache to read from, not a collection to search. The Result<T> envelope is the second half: a failed fetch is a value the page branches on, not an exception, which is the workspace-wide Result pattern taught in 00-primer.md.
• Walkthrough: one member, GetAllAsync(CancellationToken cancellationToken = default) returning Task<Result<IReadOnlyDictionary<CategoryItemIdentifierType, CategoryItemInfo>>> (ICategoryItemLookupService.cs:20-21). The cancellation token is optional and defaulted, so page code can pass its own component-scoped token.
• Why it's built this way: pages depend on this interface, never on the HTTP class, so the two requests the implementation actually makes (categories, then a 10000-page-size items read) stay an implementation detail (CategoryItemLookupService.cs:22-38).
• Where it's used: implemented by CategoryItemLookupService, registered scoped at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:53 under the "cross-module lookup services" comment, and injected into SessionLookups (SessionLookups.cs:35), PublicSessionDetail (PublicSessionDetail.razor.cs:31), and SpeakerDetailLookupService (SpeakerDetailLookupService.cs:14).

IEventSpeakerUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/IChildEntityUIService.cs:14 · Level 3 · interface

• What it is: the UI contract for managing EventSpeaker join rows, that is, attaching a speaker to an event and detaching one (IChildEntityUIService.cs:14-18). It is the first of four structurally identical join contracts declared in this one file.

• Depends on: EventSpeakerDTO (the created row it returns), the EventIdentifierType, SpeakerIdentifierType, and EventSpeakerIdentifierType aliases, and Result / Result<T>. BCL Task, CancellationToken.

• Concept introduced, the add/remove-only join contract. [Rubric §9, API & Contract Design] (assesses whether a contract exposes the operations the resource actually supports; a join row has no fields to edit, so there is no Update and no GetById, only Add and Delete). [Rubric §18, UI Architecture] (a page edits an association through a typed service, not by hand-rolling a POST). [Rubric §1, SOLID]: four narrow interfaces instead of one generic IJoinService<,> means each page injects exactly the association it edits, and the implementations keep strongly typed parameter names (eventId, speakerId) rather than two anonymous ids. Note the asymmetry that makes these contracts safe. AddAsync takes the two parent ids, while DeleteAsync takes the owning aggregate's id and the join row's own id, because the API removes a row by loading that aggregate and asking it to drop the child; the doc comment states plainly that a call without the parent id deletes nothing and answers 404 (IChildEntityUIService.cs:8-13). The formatting of that pair is ChildEntityDeletePath's job.

• Walkthrough

  • AddAsync(eventId, speakerId, ct) (IChildEntityUIService.cs:16): returns Task<Result<EventSpeakerDTO>>, the created row read back from the response body.
  • DeleteAsync(eventId, id, ct) (line 17): takes the event id and the EventSpeakerIdentifierType and returns Task<Result>, a non-generic Result, so a 404 arrives as an ErrorType.NotFound failure rather than as a bare false (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/ChildEntityServiceBase.cs:62-70).

• The family: all four contracts in this file share that shape and differ only in the ids and the DTO.

  Type	File:Line	Add parameters	Returns / delete key
  IEventSpeakerUIService	IChildEntityUIService.cs:14	eventId, speakerId	EventSpeakerDTO / eventId + EventSpeakerIdentifierType
  ISessionSpeakerUIService	IChildEntityUIService.cs:26	sessionId, speakerId	SessionSpeakerDTO / sessionId + SessionSpeakerIdentifierType
  ISessionCategoryItemUIService	IChildEntityUIService.cs:38	sessionId, categoryItemId	SessionCategoryItemDTO / sessionId + SessionCategoryItemIdentifierType
  ISpeakerCategoryItemUIService	IChildEntityUIService.cs:50	speakerId, categoryItemId	SpeakerCategoryItemDTO / speakerId + SpeakerCategoryItemIdentifierType

• Why it's built this way: keeping the four as separate interfaces in one file makes the family obvious to a reader while still giving DI four distinct binding targets (DependencyInjection.cs:32-35). The implementations are equally uniform: each derives from the shared ChildEntityServiceBase and supplies only its resource root (ChildEntityServices.cs:23,36,49,62).

• Where it's used: implemented by EventSpeakerService (ChildEntityServices.cs:22-23) and registered scoped at DependencyInjection.cs:32.

• Caveats / not-in-source: unlike its three siblings, this contract has no page consumer in the current source. It is registered and implemented, but no Razor component injects IEventSpeakerUIService today, so the event-to-speaker association is reachable only through the API. The three session and speaker join contracts are all wired into pages.

ISessionCategoryItemUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/IChildEntityUIService.cs:38 · Level 3 · interface

• What it is: the join contract for tagging a session with a category item and untagging it (IChildEntityUIService.cs:38-42).
• Depends on: SessionCategoryItemDTO, the SessionIdentifierType, CategoryItemIdentifierType, and SessionCategoryItemIdentifierType aliases, and Result / Result<T>.
• Concept: the add/remove-only join contract taught at IEventSpeakerUIService, including the family table and the parent-scoped delete. [Rubric §9, API & Contract Design].
• Walkthrough: AddAsync(sessionId, categoryItemId, ct) returning Task<Result<SessionCategoryItemDTO>> (line 40) and DeleteAsync(sessionId, id, ct) returning Task<Result> (line 41).
• Where it's used: implemented by SessionCategoryItemService (ChildEntityServices.cs:48-49), registered at DependencyInjection.cs:34, injected into SessionDetail (SessionDetail.razor.cs:33), which pairs it with ICategoryItemLookupService, reached through SessionLookups, to offer the untagged items as choices.

ISessionSpeakerUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/IChildEntityUIService.cs:26 · Level 3 · interface

• What it is: the join contract for adding a speaker to a session and removing one (IChildEntityUIService.cs:26-30).
• Depends on: SessionSpeakerDTO, the SessionIdentifierType, SpeakerIdentifierType, and SessionSpeakerIdentifierType aliases, and Result / Result<T>.
• Concept: see IEventSpeakerUIService for the shared shape and the family table. [Rubric §18, UI Architecture]. This is the one member of the family whose two ids in AddAsync are of different CLR types, an int session and a Guid speaker, which is why the family was written as four typed interfaces rather than one generic pair of ids.
• Walkthrough: AddAsync(sessionId, speakerId, ct) returning Task<Result<SessionSpeakerDTO>> (line 28) and DeleteAsync(sessionId, id, ct) returning Task<Result> (line 29).
• Where it's used: implemented by SessionSpeakerService (ChildEntityServices.cs:35-36), registered at DependencyInjection.cs:33, injected into SessionDetail (SessionDetail.razor.cs:32).

ISpeakerCategoryItemUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/IChildEntityUIService.cs:50 · Level 3 · interface

• What it is: the join contract for tagging a speaker with a category item, which is how speaker attributes such as locality are modeled, and untagging one (IChildEntityUIService.cs:50-54).
• Depends on: SpeakerCategoryItemDTO, the SpeakerIdentifierType, CategoryItemIdentifierType, and SpeakerCategoryItemIdentifierType aliases, and Result / Result<T>.
• Concept: see IEventSpeakerUIService. [Rubric §9, API & Contract Design]. Its delete is the one that carries a Guid parent id into the query string, which is why ChildEntityDeletePath is generic and escapes the parent value (ChildEntityServices.cs:68).
• Walkthrough: AddAsync(speakerId, categoryItemId, ct) returning Task<Result<SpeakerCategoryItemDTO>> (line 52) and DeleteAsync(speakerId, id, ct) returning Task<Result> (line 53).
• Where it's used: implemented by SpeakerCategoryItemService (ChildEntityServices.cs:61-62), registered at DependencyInjection.cs:35, injected into SpeakerCategoryItemsPanel (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerCategoryItemsPanel.razor.cs:19), the component SpeakerDetail hosts.

CategoryItemLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/CategoryItemLookupService.cs:12 · Level 4 · class (sealed)

• What it is: the implementation behind ICategoryItemLookupService. It makes two API calls, one for the categories and one for the items, then joins them in memory into a dictionary of CategoryItemInfo (CategoryItemLookupService.cs:12-83).
• Depends on: CategoryItemInfo (what it emits), CategoryItemDTO and ConferenceCategoryDTO (the wire shapes it reads), CollectionResult<T> and PagedCollectionResult<T> (the two envelopes those endpoints return), HttpResultExecutor and ProblemDetailsResultReader (the two halves of the railway conversion), and BCL IHttpClientFactory. Note what it does not take: no token storage (CategoryItemLookupService.cs:12), so this is an unauthenticated read, unlike the entity services that derive from AuthenticatedServiceBase.
• Concept introduced, the client-side join. [Rubric §23, Front-End Performance] assesses whether the front end minimizes round trips for a render, and [Rubric §8, Data Architecture] assesses where denormalization happens. The category-item endpoint returns a CategoryId but not the category's title, and the UI wants the pair. Rather than asking the server for a nested projection or fetching the parent per item, the client pulls both small collections once and does the join itself, producing the denormalized CategoryItemInfo. Two round trips total, regardless of how many items or how many rows the page renders. The second concept here is the two-part railway conversion that every lookup in this family uses: ProblemDetailsResultReader converts a response into a Result with the server's original ErrorType intact, while HttpResultExecutor converts the absence of a response (refused connection, DNS failure, dropped socket, client timeout) into a failure, and deliberately lets caller cancellation propagate as an exception rather than reporting a disposed page as an error (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/HttpResultExecutor.cs:11-23). Both halves are what let this method be honestly typed as returning a Result.
• Walkthrough: one public method, GetAllAsync(ct) (CategoryItemLookupService.cs:15-43), with the whole body wrapped in HttpResultExecutor.ExecuteAsync (:17).
  • Resolves the named "APIClient" HttpClient from the factory in a using (:20), so the per-call handler lifetime is the factory's concern.
  • GETs conferencecategories?includeFKs=false&includeChildren=false through the private GetAsync<T> helper into a CollectionResult<ConferenceCategoryDTO> (:22-25). This one is the non-paged envelope: the category list is small and unpaged.
  • Short-circuits on failure, re-wrapping the errors under the dictionary's type parameter (:27-31), so a failed first call is never silently treated as "no categories".
  • BuildCategoryTitles folds the categories into a Dictionary<ConferenceCategoryIdentifierType, string>, null-guarding the collection (:54-67).
  • GETs categoryitems?includeFKs=false&includeChildren=false&pageSize=10000 into a PagedCollectionResult<CategoryItemDTO> (:35-38).
  • Map projects the successful page through BuildLookup (:40-41), which loops the items, resolves each parent title with TryGetValue falling back to string.Empty, and stores one CategoryItemInfo per id (:69-83).
  • The private GetAsync<T> (:45-52) is the shared read step: one GetAsync, one ProblemDetailsResultReader.ReadAsync<T> (:51).
• Why it's built this way: includeFKs=false&includeChildren=false keeps both payloads flat and small, which is the whole point of a lookup fetch, no navigation graphs, only the display fields. The TryGetValue fallback (:78) means a missing or newly added category degrades to an unprefixed label instead of throwing mid-render.
• Where it's used: registered scoped in AddConferenceUI against ICategoryItemLookupService (DependencyInjection.cs:53); injected into SessionDetail (Pages/Session/SessionDetail.razor.cs:26) and PublicSessionDetail (Pages/Public/PublicSessionDetail.razor.cs:27), taken as a constructor argument by SessionLookups (Pages/Session/SessionLookups.cs:32), and composed by SpeakerDetailLookupService as the first of its three loads (Services/SpeakerDetailLookupService.cs:12,20).
• Caveats / not-in-source: the pageSize=10000 request (CategoryItemLookupService.cs:37) is a hard ceiling; beyond 10,000 category items the lookup would silently drop the remainder, and there is no follow-on page request. The categories call sends no page size at all (:24), so it depends on that endpoint returning the full set. Nothing memoizes the result inside this class: each GetAllAsync call re-issues both requests, and the scoped registration only means one instance per request or circuit scope, not one fetch. Its sibling EventLookupService does memoize, so the two lookups are not interchangeable on that point.

ICategoryItemUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/ICategoryItemUIService.cs:9 · Level 4 · interface

• What it is: the UI-service contract for the categoryitems REST resource, an empty marker over IEntityService<TEntityDTO, TIdentifierType> bound to CategoryItemDTO and CategoryItemIdentifierType (ICategoryItemUIService.cs:9-11).
• Depends on: IEntityService<TEntityDTO, TIdentifierType> (imported at ICategoryItemUIService.cs:2) and CategoryItemDTO (imported at ICategoryItemUIService.cs:1).
• Concept: identical shape to IActivityUIService; see it for the marker-interface and assembly-scan rationale. [Rubric §18, UI Architecture].
• Walkthrough: no members. The doc comment (ICategoryItemUIService.cs:6-8) repeats the "uses generic CRUD" formula.
• Where it's used: implemented by CategoryItemService; injected into ConferenceCategoryItemsPanel, the editor for the items belonging to a category (Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:24). It is the one CRUD marker in this family with a single consumer: category items are only ever managed from inside their parent category, never as a top-level list. Read-side enrichment of category items goes through the separate ICategoryItemLookupService instead.

IConferenceCategoryUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/IConferenceCategoryUIService.cs:9 · Level 4 · interface

• What it is: the UI-service contract for the conferencecategories REST resource, an empty marker over IEntityService<TEntityDTO, TIdentifierType> bound to ConferenceCategoryDTO and ConferenceCategoryIdentifierType (IConferenceCategoryUIService.cs:9-11).
• Depends on: IEntityService<TEntityDTO, TIdentifierType> and ConferenceCategoryDTO.
• Concept: identical shape to IActivityUIService. [Rubric §18, UI Architecture] and [Rubric §15, Best Practices & Code Quality] (a new aggregate resource costs one empty interface plus one thin class).
• Walkthrough: no members (doc comment IConferenceCategoryUIService.cs:6-8).
• Where it's used: implemented by ConferenceCategoryService; injected into the conference-category list, detail and create pages (Pages/ConferenceCategory/ConferenceCategoryList.razor.cs:16, Pages/ConferenceCategory/ConferenceCategoryDetail.razor.cs:23, Pages/ConferenceCategory/ConferenceCategoryCreate.razor.cs:13) and into ConferenceCategoryItemsPanel (:23). It is also one of the three services SpeakerDetailLookupService composes, supplying the category titles for SpeakerDetailLookups (Services/SpeakerDetailLookupService.cs:13,26).

CategoryItemService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/CategoryItemService.cs:10 · Level 5 · class (sealed)

• What it is: the concrete HTTP service for the categoryitems resource, structurally identical to ActivityService but bound to CategoryItemDTO and CategoryItemIdentifierType (CategoryItemService.cs:10-14). It implements ICategoryItemUIService.
• Depends on: EntityServiceBase<TEntityDTO, TIdentifierType>, ITokenStorageService, CategoryItemDTO; BCL IHttpClientFactory.
• Concept: identical to ActivityService; see it for the thin-leaf rationale. The only differences are the resource root "categoryitems" (CategoryItemService.cs:12), the DTO plus identifier alias, and the interface it satisfies. [Rubric §15, Best Practices & Code Quality].
• Walkthrough: no members. The base call passes "categoryitems" alongside the factory and token storage (CategoryItemService.cs:10-12), and the same line declares ICategoryItemUIService.
• Where it's used: picked up by the same assembly scan as its siblings (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:29) and resolved through ICategoryItemUIService in ConferenceCategoryItemsPanel, the category detail page's items editor (Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:24).

ConferenceCategoryService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Categories/ConferenceCategoryService.cs:10 · Level 5 · class (sealed)

• What it is: the concrete HTTP service for the conferencecategories resource, structurally identical to CategoryItemService but bound to ConferenceCategoryDTO and ConferenceCategoryIdentifierType (ConferenceCategoryService.cs:10-14). It implements IConferenceCategoryUIService.
• Depends on: EntityServiceBase<TEntityDTO, TIdentifierType>, ITokenStorageService, ConferenceCategoryDTO.
• Concept: identical to ActivityService; see it for the thin-leaf rationale. The only differences are the resource root "conferencecategories" (ConferenceCategoryService.cs:12), the DTO plus identifier alias, and the interface it satisfies. [Rubric §15, Best Practices & Code Quality]. Reading these three classes back to back is the clearest evidence of what the shared base buys: three resources, twelve lines of code, zero duplicated HTTP handling.
• Walkthrough: no members; the base call passes "conferencecategories" alongside the factory and token storage (ConferenceCategoryService.cs:10-12).
• Where it's used: picked up by the same assembly scan as its siblings (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:29) and resolved through IConferenceCategoryUIService in ConferenceCategoryList (Pages/ConferenceCategory/ConferenceCategoryList.razor.cs:16), ConferenceCategoryDetail (Pages/ConferenceCategory/ConferenceCategoryDetail.razor.cs:23), ConferenceCategoryCreate (Pages/ConferenceCategory/ConferenceCategoryCreate.razor.cs:13) and ConferenceCategoryItemsPanel (Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:23).

EventSpeakerService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/ChildEntityServices.cs:22 · Level 5 · class (sealed)

• What it is: the HTTP service for the EventSpeaker join entity: add (POST) or remove (DELETE) a speaker on an event (ChildEntityServices.cs:22-30). It is the first of four structurally identical join-entity services in one file and implements IEventSpeakerUIService.
• Depends on: ChildEntityServiceBase (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/ChildEntityServiceBase.cs:19, hoisted out of this file into the shared namespace, as the trailing comment records at ChildEntityServices.cs:89-90); ChildEntityDeletePath for the delete suffix; ITokenStorageService; EventSpeakerDTO; Result; the EventIdentifierType / SpeakerIdentifierType / EventSpeakerIdentifierType aliases.
• Concept introduced, the join-entity UI service. A join (association) entity has no rich lifecycle: you create the link or remove it, and there is no detail page and no update. So it does not use the full-CRUD EntityServiceBase<TEntityDTO, TIdentifierType>; it uses the leaner ChildEntityServiceBase, whose whole surface is three protected helpers: PostAsync<TResponse>, which posts and reads the created DTO back (ChildEntityServiceBase.cs:36-44), a valueless PostAsync for an endpoint that answers 204 (:52-60), and DeleteByIdAsync (:70-79). All three create their client through AuthenticatedServiceBase.CreateAuthenticatedClientAsync() (:40,56,74), so the join endpoints carry the same bearer token as their parent CRUD endpoints, and all three wrap the call in HttpResultExecutor and read the response through ProblemDetailsResultReader, so a missing join row arrives as a typed ErrorType.NotFound failure the caller can tell apart from a genuine failure (ChildEntityServiceBase.cs:62-65). [Rubric §18, UI Architecture] (assesses whether pages depend on well-factored typed services rather than raw HttpClient; the tag editor calls one method per direction) and [Rubric §2, Design Patterns] (the same base-plus-thin-leaf factoring as the CRUD family).
• Concept introduced, the parent id on every removal. The file-level remarks (ChildEntityServices.cs:14-21) are worth reading in full: the join controllers remove a row by loading the parent aggregate and asking it to drop the child, so the parent id in the query string is not decoration. A DELETE sent without it binds the parent id to its default value, that aggregate is never found, and the API answers 404 while the UI reports a generic failure. That is why every DeleteAsync in this file takes the owning aggregate's id as well as the join row's own, and why the suffix is built in exactly one place, ChildEntityDeletePath (ChildEntityServices.cs:76-87), which concatenates the child id, the parent parameter name and the URL-escaped parent id, all formatted with CultureInfo.InvariantCulture (:81-86). [Rubric §15, Best Practices & Code Quality] (assesses whether an easily-wrong detail is centralized instead of repeated at each call site).
• Walkthrough (ChildEntityServices.cs:22)
  • The base call supplies the "eventspeakers" endpoint (ChildEntityServices.cs:23).
  • AddAsync(eventId, speakerId, ct) (ChildEntityServices.cs:25-26): PostAsync<EventSpeakerDTO> with the anonymous payload new { EventId, SpeakerId }, returning Result<EventSpeakerDTO>.
  • DeleteAsync(eventId, id, ct) (ChildEntityServices.cs:28-29): DeleteByIdAsync over ChildEntityDeletePath.For(id, "eventId", eventId), returning a valueless Result.
• Why it's built this way: modeling each many-to-many link as its own tiny service over a shared child base keeps the add/remove surface uniform and each payload strongly typed, without the CRUD surface a join row does not need.
• Where it's used: registered explicitly at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:32 (join services are not IEntityService<,> implementations, so the assembly scan does not see them).
• Caveats / not-in-source: unlike the CRUD services, none of the ChildEntityServiceBase helpers runs inside the Polly RetryPolicy (the calls at ChildEntityServiceBase.cs:41,57,76 go straight to the HttpClient), so a transient failure on a link edit surfaces immediately rather than being retried. Note also that in the current tree no Conference page injects IEventSpeakerUIService: the interface, this implementation and the DI line are its only references, so the event-speaker link is registered and callable but has no page consumer today.

SessionCategoryItemService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/ChildEntityServices.cs:48 · Level 5 · class (sealed)

• What it is: the HTTP service for the SessionCategoryItem join entity: add (POST) or remove (DELETE) a category-item tag on a session (ChildEntityServices.cs:48-56). It implements ISessionCategoryItemUIService.
• Depends on: ChildEntityServiceBase; ChildEntityDeletePath; ITokenStorageService; SessionCategoryItemDTO; Result; the SessionIdentifierType / CategoryItemIdentifierType / SessionCategoryItemIdentifierType aliases.
• Concept: cross-reference the join-entity mechanics and the parent-id rule taught at EventSpeakerService. [Rubric §18, UI Architecture].
• Walkthrough (ChildEntityServices.cs:48)
  • The base call supplies the "sessioncategoryitems" endpoint (ChildEntityServices.cs:49).
  • AddAsync(sessionId, categoryItemId, ct) (ChildEntityServices.cs:51-52): PostAsync<SessionCategoryItemDTO>(new { SessionId, CategoryItemId }), returning the created SessionCategoryItemDTO in a Result<T>.
  • DeleteAsync(sessionId, id, ct) (ChildEntityServices.cs:54-55): DeleteByIdAsync over ChildEntityDeletePath.For(id, "sessionId", sessionId), so the owning session id rides along in the query string.
• Why it's built this way: modeling each many-to-many link as its own tiny service over a shared child base keeps the add/remove surface uniform and each payload strongly typed, without the CRUD surface a join row does not need.
• Where it's used: registered explicitly at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:34, and injected into SessionDetail's "categories on this session" editor (Pages/Session/SessionDetail.razor.cs:28).

SessionSpeakerService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/ChildEntityServices.cs:35 · Level 5 · class (sealed)

• What it is: the HTTP service for the SessionSpeaker join entity: add (POST) or remove (DELETE) a speaker on a session (ChildEntityServices.cs:35-43). It is the structural twin of EventSpeakerService, SessionCategoryItemService and SpeakerCategoryItemService, differing only in endpoint, payload keys, DTO and parent parameter name. It implements ISessionSpeakerUIService.
• Depends on: ChildEntityServiceBase; ChildEntityDeletePath; ITokenStorageService; SessionSpeakerDTO; Result; the SessionIdentifierType / SpeakerIdentifierType / SessionSpeakerIdentifierType aliases.
• Concept: cross-reference the join-entity mechanics and the parent-id rule taught at EventSpeakerService. [Rubric §18, UI Architecture].
• Walkthrough (ChildEntityServices.cs:35)
  • The base call supplies the "sessionspeakers" endpoint (ChildEntityServices.cs:36).
  • AddAsync(sessionId, speakerId, ct) (ChildEntityServices.cs:38-39): PostAsync<SessionSpeakerDTO>(new { SessionId, SpeakerId }).
  • DeleteAsync(sessionId, id, ct) (ChildEntityServices.cs:41-42): DeleteByIdAsync over ChildEntityDeletePath.For(id, "sessionId", sessionId).
• Why it's built this way: same rationale as the other join services, a tiny per-link service over the shared child base keeps the add/remove surface uniform and strongly typed.
• Where it's used: registered explicitly at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:33, and injected into SessionDetail's "speakers on this session" editor (Pages/Session/SessionDetail.razor.cs:27). The rows it creates are also what the server joins on when SpeakerDashboardService filters sessions by the virtual SpeakerId key.

SpeakerCategoryItemService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Common · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Common/ChildEntityServices.cs:61 · Level 5 · class (sealed)

• What it is: the HTTP service for the SpeakerCategoryItem join entity: add (POST) or remove (DELETE) a category-item tag on a speaker, which is the mechanism behind speaker categorization such as locality (ChildEntityServices.cs:61-69). It is the fourth structurally identical join service in the file and implements ISpeakerCategoryItemUIService.
• Depends on: ChildEntityServiceBase; ChildEntityDeletePath; ITokenStorageService; SpeakerCategoryItemDTO; Result; the SpeakerIdentifierType / CategoryItemIdentifierType / SpeakerCategoryItemIdentifierType aliases.
• Concept: cross-reference the join-entity mechanics and the parent-id rule taught at EventSpeakerService. [Rubric §18, UI Architecture].
• Walkthrough (ChildEntityServices.cs:61)
  • The base call supplies the "speakercategoryitems" endpoint (ChildEntityServices.cs:62).
  • AddAsync(speakerId, categoryItemId, ct) (ChildEntityServices.cs:64-65): PostAsync<SpeakerCategoryItemDTO>(new { SpeakerId, CategoryItemId }).
  • DeleteAsync(speakerId, id, ct) (ChildEntityServices.cs:67-68): DeleteByIdAsync over ChildEntityDeletePath.For(id, "speakerId", speakerId).
• Why it's built this way: same shared-child-base rationale as the other three join services. The four differ only in the resource name, the two id fields in the payload, and the parent parameter name in the delete path, which is exactly the amount of code the base cannot supply.
• Where it's used: registered explicitly at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:35, and injected into SpeakerCategoryItemsPanel, the speaker detail page's category editor (Pages/Speaker/SpeakerCategoryItemsPanel.razor.cs:18).

EventInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/IEventLookupService.cs:14 · Level 0 · record

• What it is: the event-side lookup projection: identity, name, the date window, the event's time zone, its published flag, and an optional sponsorship packet URL (IEventLookupService.cs:14-21). Beyond name enrichment it is the input to the "which event is the current one" decision that several pages make on load.
• Depends on: no first-party types. EventIdentifierType is int in this module (MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:8); BCL DateOnly, string, bool.
• Concept: the same UI lookup projection introduced by CategoryItemInfo. What is new here is that the projection carries decision fields, not only display fields. [Rubric §18, UI Architecture] and [Rubric §19, State Management]: pages feed StartDate, EndDate, and TimeZone into the shared CurrentEventSelector to pick the current or next event, so the "default event filter" rule lives in one shared selector while the record just supplies its inputs.
• Walkthrough: a positional record with seven members.
  • Id, Name (IEventLookupService.cs:15-16): key plus display name.
  • StartDate, EndDate (lines 17-18): DateOnly bounds of the event.
  • TimeZone (line 19): the event's time zone id, passed to the selector so "current" is evaluated in the event's own zone rather than the browser's.
  • IsPublished (line 20).
  • SponsorshipPacketUrl (line 21): string? with a default of null. The remarks block (IEventLookupService.cs:9-13) records why: the many call sites that need only identity and dates stay unchanged, and only the public sponsor page reads it, to decide whether the sponsorship call to action renders at all.
• Why it's built this way: adding the optional parameter last with a default kept a wide set of construction sites source-compatible while the sponsor feature landed. [Rubric §15, Best Practices & Code Quality] (assesses whether a shape can grow without a ripple edit). EventLookupService is the single place that fills every member (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/EventLookupService.cs:109).
• Where it's used: PublicSponsorList resolves the current or next event and then reads SponsorshipPacketUrl off it (PublicSponsorList.razor.cs:63); every page that injects IEventLookupService indexes the dictionary of these records to render event names, including EventFilteredListPageBase<TDto> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Common/EventFilteredListPageBase.cs:27), which supplies the shared event filter to its derived list pages.

SessionSchedulePageRequest

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Public · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Public/IPublicSessionScheduleService.cs:20 · Level 0 · record

• What it is: a sealed record describing one page request from the public session list: the grid's filters, the 1-based page number, the page size, the optional sort column and direction, and the optional set of bookmarked session ids that scopes the "My Schedule" view (IPublicSessionScheduleService.cs:20-26).
• Depends on: no first-party types. SessionIdentifierType is int (MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:15). BCL Dictionary<string, (string Operator, string Value)> and IReadOnlyCollection<T>.
• Concept introduced, the parameter object for a grid fetch. [Rubric §9, API & Contract Design] (assesses whether a call's inputs are named and typed rather than a positional run of primitives: six arguments collapse into one record whose members carry the intent). [Rubric §18, UI Architecture]: the record is what lets the offline-first fetch live in a service instead of in the page, because a page's ServerData delegate can hand its whole request over in one object. The filter dictionary's tuple value, (string Operator, string Value), is the MMCA.Common filter convention the paged query endpoints understand.
• Walkthrough: a positional record with six members and no body.
  • Filters (IPublicSessionScheduleService.cs:21): the grid filters the page already assembled.
  • Page, PageSize (lines 22-23): the 1-based page and rows per page.
  • SortColumn, SortDirection (lines 24-25): both string?, null when the grid is unsorted.
  • MyScheduleSessionIds (line 26): IReadOnlyCollection<SessionIdentifierType>?. The param doc (lines 14-19) is the load-bearing part: when the "My Schedule" view is active for an authenticated user this holds the bookmarked ids so the query is scoped server-side with an Id IN (...) filter and the server still pages; it is null for the normal browse path, and it is never empty, because an empty schedule has no query to run and the page answers it without reaching the service.
• Why it's built this way: PublicSessionScheduleService turns MyScheduleSessionIds into an extra "Id" filter with the IN operator before delegating to the paged session query (PublicSessionScheduleService.cs:78-83), which is why the "never empty" invariant is documented on the record rather than defended in the service: an empty IN list would be a query that cannot match. [Rubric §12, Performance & Scalability]: the alternative the doc comment rules out, pulling a 500-row page and filtering in memory, also reported a wrong total past 500 rows (PublicSessionScheduleService.cs:67-70).
• Where it's used: constructed by PublicSessionList inside its unified fetch delegate (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Public/Sessions/PublicSessionList.razor.cs:277-284) and consumed by IPublicSessionScheduleService.FetchPageAsync.

IEventLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/IEventLookupService.cs:26 · Level 3 · interface

• What it is: the event counterpart of ICategoryItemLookupService: one call returning an event-keyed dictionary of EventInfo (IEventLookupService.cs:26-30).
• Depends on: EventInfo, the EventIdentifierType alias, and Result<T>.
• Concept: identical bulk-then-index shape, see ICategoryItemLookupService. [Rubric §23, Front-End Performance]. This is the most widely injected of the three lookups because so many Conference surfaces are event-scoped, and it is the only one whose implementation memoizes: the remarks on EventLookupService explain that the cached unit is the Task, not the result, so concurrent callers in one scope share a single in-flight fetch (EventLookupService.cs:12-32), with a five-minute TTL matched to the server's "EventsCache" output-cache policy (EventLookupService.cs:36-41).
• Walkthrough: one member, GetAllAsync(CancellationToken cancellationToken = default) returning Task<Result<IReadOnlyDictionary<EventIdentifierType, EventInfo>>> (IEventLookupService.cs:28-29).
• Where it's used: implemented by EventLookupService, registered scoped at DependencyInjection.cs:52, and injected into a wide set of Conference pages, including EventFilteredListPageBase<TDto> (EventFilteredListPageBase.cs:27), RoomDetail (RoomDetail.razor.cs:21), RoomCreate (RoomCreate.razor.cs:15), SessionCreate (SessionCreate.razor.cs:22), SessionDetail (SessionDetail.razor.cs:29), ActivityDetail (ActivityDetail.razor.cs:25), ActivityCreate (ActivityCreate.razor.cs:22), SpeakerDashboard (SpeakerDashboard.razor.cs:26), SessionSelectionDashboard (SessionSelectionDashboard.razor.cs:19), OrganizerEventFeedback (OrganizerEventFeedback.razor.cs:22), PublicActivityList (PublicActivityList.razor.cs:29), PublicEventList (PublicEventList.razor.cs:36), PublicSponsorList (PublicSponsorList.razor.cs:28), and the sponsor admin pages (SponsorDetail.razor.cs:24, SponsorCreate.razor.cs:21). It is also consumed from the Engagement module's event feedback page, EventFeedback (MMCA.ADC/Source/Modules/Engagement/MMCA.ADC.Engagement.UI/Pages/Feedback/EventFeedback.razor.cs:23), which is why DependencyInjection.cs:50 labels these "cross-module lookup services".

IPublicSessionScheduleService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Public · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Public/IPublicSessionScheduleService.cs:34 · Level 3 · interface

• What it is: the offline-first page fetch for the public session schedule (IPublicSessionScheduleService.cs:34-53). One method runs the live paged query and keeps the last successful FIRST page in the device-local cache, so a dead venue network still shows a programme (doc comment, lines 28-33).
• Depends on: SessionSchedulePageRequest, SessionDTO, and Result<T>. BCL Action<bool>, Task, CancellationToken, and a named tuple return type (IReadOnlyList<SessionDTO> Items, int TotalItems).
• Concept introduced, offline-first read-through with an explicit blast radius. [Rubric §29, Resilience & Business Continuity] (assesses whether a surface degrades usefully when a dependency is gone; here the conference programme survives a venue network outage). [Rubric §19, State Management] and [Rubric §18, UI Architecture]: the caching decision lives in the service while the page keeps only the banner flag, so the component stays a renderer. The doc comment is precise about how narrow the fallback is, and that precision is the teaching point: the live path is never affected, the snapshot is only consulted when a fetch fails, and only for page 1 while the device reports itself offline (lines 30-33). This is the ADR-042 device-capability abstraction at work (Website/docs-src/adr/042-device-capability-abstraction.md): the implementation composes OfflineFirstPageSnapshot<TItem> over ILocalCacheStore and IConnectivityStatusService (PublicSessionScheduleService.cs:19-31), so the same page code runs on a head that has no local store at all.
• Walkthrough: one member, FetchPageAsync(SessionSchedulePageRequest request, Action<bool> onCacheStateChanged, CancellationToken cancellationToken = default) returning Task<Result<(IReadOnlyList<SessionDTO> Items, int TotalItems)>> (IPublicSessionScheduleService.cs:49-52).
  • request (line 50): the page to fetch, see SessionSchedulePageRequest.
  • onCacheStateChanged (line 51): a callback, raised with true when the snapshot answered, so the page shows its "cached schedule" banner and re-renders, and with false when a live fetch succeeded (documented at lines 42-46). Passing a callback rather than exposing a property keeps the service free of any rendering knowledge.
  • The failure contract is spelled out in the method doc (lines 36-41): a successful first page is written back to the snapshot, a failed fetch falls back to it, and a failure with nothing cached travels on to the caller unchanged, a failed Result as a failed result and a throwing cache store as a rethrow, so the grid's own handling still applies. The implementation matches that on both branches (PublicSessionScheduleService.cs:39-64).
• Why it's built this way: extracting the offline behavior behind an interface is what let the page keep a single fetch delegate for both the browse and "My Schedule" views. The page comment says it directly: only the banner stays in the page, the service decides when it is warranted (PublicSessionList.razor.cs:289-291).
• Where it's used: implemented by PublicSessionScheduleService, registered scoped at DependencyInjection.cs:48 under an explicit ADR-042 Wave 3 comment (line 41), and injected into PublicSessionList (PublicSessionList.razor.cs:34), which calls it from its unified fetch delegate (PublicSessionList.razor.cs:277-285).

SessionizeRefreshOutcome

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/SessionizeRefreshOutcome.cs:13 · Level 3 · record (sealed)

• What it is: the two-field payload the event detail page gets back from one Sessionize refresh gesture: Summary, the per-entity counts and warnings the import reported, and Event, the event reloaded after the import including its fresh row version (SessionizeRefreshOutcome.cs:11-13).
• Depends on: RefreshFromSessionizeResultDTO and EventDTO, both from MMCA.ADC.Conference.Shared.Events (SessionizeRefreshOutcome.cs:1).
• Concept introduced, the multi-step gesture packaged as one result. A Sessionize refresh is three server calls (persist an edited code, run the import, reload the event), and the doc comment states why the two payloads travel together: so the page reads one Result and reports one failure, instead of branching on a persist, an import, and a reload with the same message three times (SessionizeRefreshOutcome.cs:5-9). [Rubric §19, State Management] assesses whether the UI's copy of server state stays consistent after a write: the reloaded event is part of the success value, so a page that handles the outcome cannot forget to refresh its row version and then fail its next conditional update. [Rubric §9, API & Contract Design] assesses whether a client contract models the operation rather than the transport; this record exists because "refresh" is one user gesture even though it is three HTTP calls.
• Walkthrough: a positional sealed record with two members and no behavior (SessionizeRefreshOutcome.cs:13). Value equality and with come from the record declaration; there is no constructor body, no validation, and no mapping code. It is a transport-shaped tuple with names.
• Why it's built this way: the import rewrites the event's child data and its refresh stamp, so the caller's copy of the event is stale the moment the import succeeds. The service comment says exactly that and concludes "hand back the reloaded event rather than a bare summary" (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/EventService.cs:76-77).
• Where it's used: produced by IEventUIService.RefreshFromSessionizeWithCodeAsync (IEventUIService.cs:29), built by EventService (EventService.cs:81), and consumed by EventDetail, which unpacks both members in one branch: _refreshResult = refreshed.Summary, Event = refreshed.Event (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Events/EventDetail.razor.cs:247-256).

EventLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/EventLookupService.cs:33 · Level 4 · class (sealed)

• What it is: the implementation behind IEventLookupService: one bulk GET of the events collection projected into a dictionary of EventInfo, memoized per scope behind a single-flight cache (EventLookupService.cs:33-113). It is the most-injected service in this chapter, so the caching is not an optimization detail, it is the reason the pattern scales.
• Depends on: EventInfo, EventDTO, PagedCollectionResult<T>, HttpResultExecutor, ProblemDetailsResultReader; BCL IHttpClientFactory, TimeSpan, DateTimeOffset, Task.WaitAsync. Like its category-item sibling it takes no token storage (EventLookupService.cs:33), so this is an unauthenticated read.
• Concept introduced, the scope-lifetime single-flight cache. Three mechanisms interlock, and each one is documented in the class remarks (EventLookupService.cs:12-32).
  • The cached unit is the Task, not the result (:44). Two callers in the same scope that ask while a fetch is in flight share that one fetch instead of starting one each. The remarks explain why overlap is the normal case rather than the edge case: EventFilteredListPageBase<TDto> starts the load before its first await via BeginEventsLoad (Pages/Common/EventFilteredListPageBase.cs:144) and a derived page awaits it later.
  • A TTL stamped only on success (:91-96). _cachedUntil starts at DateTimeOffset.MinValue (:51), which is what makes a faulted task, a cancelled one and a failed Result all expire immediately rather than caching a non-answer; a transient outage heals on the next page instead of being remembered for five minutes. CacheTtl is five minutes (:41), deliberately matched to the server-side "EventsCache" output-cache policy so the client entry can never be staler than the response the origin would have served anyway (:36-40).
  • No lock (:22-25). The service is registered scoped in both heads (DependencyInjection.cs:52), and Blazor's renderer dispatches every component callback for one scope on a single logical thread, so the read-modify-write at :56-66 never interleaves with itself. This is a case where the hosting model, not a synchronization primitive, is the safety argument, and the code says so rather than leaving the reader to infer it. [Rubric §23, Front-End Performance] assesses redundant network work in a session: a user walking four grids pays one round trip for the event list instead of four. [Rubric §19, State Management] assesses freshness policy: bounding the client cache by the origin's own TTL means the two can never disagree in the direction that matters. [Rubric §12, Performance & Scalability] covers the single-flight collapse under concurrency.
• Walkthrough
  • CacheTtl (:41): static readonly TimeSpan of five minutes.
  • _cached (:44): the shared fetch, in flight or completed and still fresh.
  • _cachedUntil (:51): when _cached stops being reusable.
  • GetAllAsync(ct) (:53-72): snapshots _cached into a local (:56); starts a new FetchAsync() when the entry is null, or completed and past its TTL (:61-66), resetting _cachedUntil first; then returns the shared task guarded by the caller's token. The final line is the subtle one: the cached task is created without a caller token and awaited under one via entry.WaitAsync(cancellationToken) (:71), so a page disposing mid-load abandons only its own await and never cancels the fetch the other pages in the scope are sharing (:68-70).
  • FetchAsync() (:74-99): runs the GET events?includeFKs=false&includeChildren=false&pageSize=10000 under HttpResultExecutor.ExecuteAsync with CancellationToken.None throughout (:76-89), reads the response through ProblemDetailsResultReader (:84), maps the page through BuildLookup (:87), and stamps the TTL only when the result is a success and the payload is in hand, so the TTL measures the age of the data rather than the age of the attempt (:91-96).
  • BuildLookup(page) (:101-113): projects each DTO into an EventInfo carrying all seven members including SponsorshipPacketUrl (:109), keyed by evt.Id.
• Why it's built this way: the projection is the boundary between the transport contract and the UI's own model, so a change to EventDTO that does not affect these seven fields never reaches the pages ([Rubric §15, Best Practices & Code Quality]). The remarks also record a deliberate non-consolidation: the sibling read paths (LiveEventService, ADCHome, and the Conference service's SelfHttpOutputCacheWarmupTask) keep their own URLs and their own caching because they ask narrower questions of the same controller, and collapsing them onto this URL family would trade one saved round trip for a wider payload on every one of them (EventLookupService.cs:26-31).
• Where it's used: registered scoped against IEventLookupService (DependencyInjection.cs:52). It is injected across the Conference UI, including EventFilteredListPageBase<TDto> (Pages/Common/EventFilteredListPageBase.cs:27, which is what puts it behind every event-filtered grid), SessionDetail (:24), SessionCreate (:20), RoomDetail (:20), RoomCreate (:14), ActivityDetail (:24), ActivityCreate (:21), SponsorDetail (:23), SponsorCreate (:20), SpeakerDashboard (:25), SessionSelectionDashboard (:18), OrganizerEventFeedback (:20), PublicEventList (:36), PublicActivityList (:28), PublicSponsorList (:27), and SessionLookups (Pages/Session/SessionLookups.cs:30). It also crosses a module boundary into Engagement's EventFeedback page (MMCA.ADC/Source/Modules/Engagement/MMCA.ADC.Engagement.UI/Pages/Feedback/EventFeedback.razor.cs:23). Pages that need a default event filter feed its Values to CurrentEventSelector along with the StartDate / EndDate / TimeZone accessors.
• Caveats / not-in-source: the pageSize=10000 ceiling (EventLookupService.cs:81) is the same hard cap as the other lookups, with no follow-on page request. The cache is per scope, so a Blazor Server circuit and a WebAssembly app instance each hold their own copy, and there is no invalidation hook: an event edited in this scope is not reflected in the lookup until the five minutes elapse.

IEventUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/IEventUIService.cs:11 · Level 4 · interface

• What it is: the UI-service contract for the events resource. Unlike the plain CRUD markers, it extends the generic surface with four event-specific operations: publish, unpublish, a Sessionize refresh, and the composed refresh gesture (IEventUIService.cs:11-32).
• Depends on: IEntityService<TEntityDTO, TIdentifierType> bound to EventDTO, RefreshFromSessionizeResultDTO (the import summary), SessionizeRefreshOutcome (the composed payload), and Result (IEventUIService.cs:1-3). BCL Task, CancellationToken, byte[].
• Concept introduced, extending the generic UI service with resource-specific verbs. [Rubric §9, API & Contract Design] assesses whether non-CRUD state transitions get first-class, intention-revealing operations instead of being forced through a generic update. Publish and unpublish are lifecycle transitions on an event and refresh triggers an external Sessionize sync, none of which is a CRUD Update, so they earn their own methods mapped to dedicated WebAPI endpoints (the doc comment, IEventUIService.cs:7-10, says exactly this). The second concept is in the signatures: both transitions take a required byte[] rowVersion (IEventUIService.cs:13,15), the optimistic-concurrency token the client echoes back from the EventDTO it acted on. The implementation turns it into an If-Match header via ConcurrencyETag.Format (Services/EventService.cs:29,41), so a publish decided against a stale view comes back as a conflict rather than applying silently. That makes this contract a [Rubric §8, Data Architecture] touch point as well: concurrency control reaches all the way up into the UI service signature instead of stopping at the database. The rationale is ADR-035, which describes the ETag on the read and the conditional If-Match on the write as one exchange.
• Walkthrough: four declared members, all returning Result values.
  • PublishAsync(EventIdentifierType id, byte[] rowVersion, CancellationToken) (IEventUIService.cs:13), returns Task<Result>: success is "the transition applied", with no payload.
  • UnpublishAsync(EventIdentifierType id, byte[] rowVersion, CancellationToken) (IEventUIService.cs:15), the mirror transition, same shape.
  • RefreshFromSessionizeAsync(EventIdentifierType id, CancellationToken) (IEventUIService.cs:17), returns Task<Result<RefreshFromSessionizeResultDTO>>. It takes no rowVersion: a Sessionize pull is not a lifecycle transition on the event row.
  • RefreshFromSessionizeWithCodeAsync(EventDTO current, string? sessionizeCode, CancellationToken) (IEventUIService.cs:29-32), returns Task<Result<SessionizeRefreshOutcome>>. The doc comment is the interesting part (IEventUIService.cs:19-28): this member runs the whole organizer refresh gesture, persisting the Sessionize code when the organizer changed it, calling RefreshFromSessionizeAsync, then reloading the event so the caller renders the server's new state. The three steps share one failure, so the page reports "refresh failed" once instead of repeating the branch per call. The current parameter is documented as carrying the row version the update is conditional on.
• Why it's built this way: the extra verbs live on the interface so the concrete EventService is the only place that knows the endpoint URLs, and pages stay transport-agnostic. Putting the three-step gesture on the contract (rather than orchestrating it in the page) is the same move ISpeakerDetailLookupService makes for reads: one call, one failure branch, one success value.
• Where it's used: implemented by EventService; injected into EventList (Pages/Event/EventList.razor.cs:21), EventDetail (Pages/Event/EventDetail.razor.cs:23, which is the only caller of RefreshFromSessionizeWithCodeAsync, at :247), EventCreate (Pages/Event/EventCreate.razor.cs:17), SessionList (Pages/Session/SessionList.razor.cs:25), PublicEventList (:35), PublicEventDetail (:20), PublicSessionList (:32) and PublicSpeakerDetail (:24).

EventService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Events · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/EventService.cs:15 · Level 5 · class (sealed)

• What it is: the concrete HTTP service for the events resource. Unlike its plain-CRUD siblings it is not body-less: on top of the inherited CRUD it adds the four event-specific operations that map to dedicated WebAPI endpoints, publish, unpublish, Sessionize refresh, and the composed refresh-with-code gesture (EventService.cs:15-84). It implements IEventUIService, which itself extends the generic IEntityService<EventDTO, EventIdentifierType> (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Events/IEventUIService.cs:11).
• Depends on: EntityServiceBase<TEntityDTO, TIdentifierType> for the CRUD surface, the Endpoint property (EntityServiceBase.cs:51) and the protected SendRequestAsync dispatch (EntityServiceBase.cs:324,354); ConcurrencyETag to render the row version as a weak entity tag (EventService.cs:29,41); EventDTO, RefreshFromSessionizeResultDTO and SessionizeRefreshOutcome; Result; ITokenStorageService; BCL CultureInfo.InvariantCulture.
• Concept introduced, the conditional state-transition call. Publish and unpublish are not CRUD: they are named transitions the server owns, so they POST to {Endpoint}/{id}/publish and {Endpoint}/{id}/unpublish with no body at all (EventService.cs:24-27,36-39). What they do carry is an If-Match header holding the event's current row version, rendered by ConcurrencyETag.Format as a weak tag such as W/"AAAAAAAAB9E=" (MMCA.Common/Source/Core/MMCA.Common.Shared/Http/ConcurrencyETag.cs:41-45). The tag is weak on purpose: a strong tag would promise byte-for-byte equality of the representation, while all this token answers is "is this still the same version of the resource", which is exactly what If-Match asks (ConcurrencyETag.cs:11-18). So a publish issued against a stale copy of the event is refused by the server rather than silently overwriting a concurrent edit (ADR-035). [Rubric §9, API & Contract Design] (assesses whether state changes are modeled as intent-named resources rather than as generic updates) and [Rubric §8, Data Architecture] (assesses how concurrent writers are arbitrated; here by a version token on the wire, not by a last-writer-wins update).
• Concept introduced, composing a multi-call gesture behind one Result. RefreshFromSessionizeWithCodeAsync is the second idea worth teaching here. The organizer's "refresh from Sessionize" button is really three server calls: persist an edited Sessionize code, run the import, reload the event. Doing that in the page would mean three failure branches printing the same message. Instead the service runs the sequence and returns one Result carrying a SessionizeRefreshOutcome, so the page reads one value and reports one failure (EventService.cs:53-83, contract documented at IEventUIService.cs:19-28). [Rubric §18, UI Architecture] (assesses whether orchestration lives in a service rather than in component code) and [Rubric §24, Forms/Validation/UX Safety] (one failure branch means one message, and no half-reported gesture).
• Walkthrough
  • PublishAsync(id, rowVersion, ct) (EventService.cs:19-29): a body-less POST to {Endpoint}/{id}/publish built with string.Create(CultureInfo.InvariantCulture, ...) (:24-27), dispatched through the base's valueless SendRequestAsync with ifMatch: ConcurrencyETag.Format(rowVersion) (:29). The base attaches the header and turns the response into a Result.
  • UnpublishAsync(id, rowVersion, ct) (EventService.cs:31-41): the exact mirror against {Endpoint}/{id}/unpublish (:37), same conditional header (:41).
  • RefreshFromSessionizeAsync(id, ct) (EventService.cs:43-51): POSTs {Endpoint}/{id}/refresh (:47-50) through the value-returning SendRequestAsync<T> and yields the import summary as a Result<RefreshFromSessionizeResultDTO>. No If-Match here: an import is not a conditional edit of the caller's copy.
  • RefreshFromSessionizeWithCodeAsync(current, sessionizeCode, ct) (EventService.cs:53-83): guards a null event (:58); compares the edited code against the stored one with StringComparison.Ordinal and, only when they differ, persists it first through the inherited UpdateAsync on a with-copy of the DTO, because the import reads the code off the stored event (:60-68); short-circuits on a failed persist (:64-67); runs the import and short-circuits again on failure using TryGetValue (:70-74); then reloads the event through the inherited GetByIdAsync(id, true, ct) (:78), because the import rewrites the event's child data and its refresh stamp, so the caller's copy is stale the moment it succeeds (:76-77); and finally pairs the summary with the reloaded event into a SessionizeRefreshOutcome (:80-82). Every branch returns the underlying call's own Errors, so nothing is re-worded on the way out.
• Why it's built this way: publish, unpublish and refresh are server-owned transitions with their own endpoints and their own authorization, so they are additive methods on the event's interface rather than flags smuggled through a PUT. The composed method exists because the reload after an import is not optional: returning a bare summary would leave the page holding an event whose row version no longer matches, and the next conditional write would fail.
• Where it's used: registered by the AddUIModule<ConferenceUIModule>() entity-service scan (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:29), since IEventUIService derives from IEntityService<,>. It is injected as IEventUIService into EventList (Pages/Event/EventList.razor.cs:21), EventDetail (Pages/Event/EventDetail.razor.cs:23), EventCreate (Pages/Event/EventCreate.razor.cs:17), PublicEventList (Pages/Public/PublicEventList.razor.cs:35), PublicEventDetail (Pages/Public/PublicEventDetail.razor.cs:20), PublicSpeakerDetail (Pages/Public/PublicSpeakerDetail.razor.cs:24), SessionList (Pages/Session/SessionList.razor.cs:25) and PublicSessionList (Pages/Public/PublicSessionList.razor.cs:32). The transition methods are called from EventDetail: publish and unpublish at Pages/Event/EventDetail.razor.cs:206-207, and the composed refresh at :247.

PublicSessionScheduleService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Public · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Public/PublicSessionScheduleService.cs:19 · Level 5 · class (sealed)

• What it is: the offline-first page fetch behind the public session schedule. It runs the live paged session query and keeps the last successful first page in the device-local cache, so a dead venue network still shows a programme (PublicSessionScheduleService.cs:19-107). It implements IPublicSessionScheduleService.
• Depends on: ISessionUIService as the live query (constructor, PublicSessionScheduleService.cs:20), so it composes over SessionService rather than issuing HTTP itself; ILocalCacheStore and IConnectivityStatusService (:19-20); OfflineFirstPageSnapshot<TItem> as the snapshot mechanism (:28-29); SessionSchedulePageRequest as its request record; SessionDTO; Result.
• Concept introduced, offline-first as a composition, not a mode. The service is a decorator over a query, not a second data path: the live call always runs first, and the snapshot is consulted only when that call did not produce a page. The framework piece it composes, OfflineFirstPageSnapshot<TItem>, narrows the fallback deliberately: CanServe is true only when the device reports itself offline, the store is available, and the requested page is page 1 (MMCA.Common/Source/Presentation/MMCA.Common.UI/Pages/Common/OfflineFirstPageSnapshot.cs:31), and RememberAsync records only page 1 (:41-45). That is what keeps the live path unaffected: there is no scenario in which a stale snapshot outranks a live answer. ILocalCacheStore persists on the MAUI and WebAssembly heads and reports itself unavailable on Blazor Server, where SSR always has the live API (OfflineFirstPageSnapshot.cs:11-12), so the same code is a no-op on the server head rather than a branch. This is the device-capability abstraction of ADR-042 applied to a list surface. [Rubric §29, Resilience & Business Continuity] (assesses whether the app degrades usefully when a dependency is gone; a venue with no signal still renders yesterday's first page) and [Rubric §19, State Management] (the banner callback keeps the user aware of which data they are looking at).
• Concept introduced, scoping "My Schedule" server-side. The private QueryAsync shows the second idea. When the "My Schedule" view is active, the request carries the attendee's bookmarked session ids, and the service copies the grid's filter dictionary and adds an Id IN (...) filter built from those ids (PublicSessionScheduleService.cs:78-83), then lets the server page the result (:83-86). The doc comment records what this replaced and why it matters: pulling a 500-row page and filtering in memory also reported a wrong total past 500 rows (:65-69). [Rubric §12, Performance & Scalability].
• Walkthrough
  • ScheduleCacheKey = "conference.publicSessions.page1" (PublicSessionScheduleService.cs:28): the device-local cache key, unique to this surface. The comment states the consequence of changing it (:22-25): every already-cached schedule is orphaned. The uniqueness requirement is the framework's, since a shared key would let one list serve another list's rows (OfflineFirstPageSnapshot.cs:17-21).
  • _snapshot (PublicSessionScheduleService.cs:30-31): one OfflineFirstPageSnapshot<SessionDTO> built from the store, the connectivity probe and that key, held for the service's scoped lifetime.
  • FetchPageAsync(request, onCacheStateChanged, ct) (PublicSessionScheduleService.cs:34-65), the only public method, and it has three exits.
    1. Live success: QueryAsync returns a page (:39-40), the snapshot records it (:42), the page's cached-data banner is switched off through the onCacheStateChanged(false) callback (:43), and the live result is returned (:44).
    2. Live failure with a snapshot: a transport fault arrives as a failed Result, not an exception, so the fallback is tried on the same terms (:47-49); when the snapshot answers, the banner is raised and the cached page is returned as a success (:50); with nothing cached the original failure travels on to the grid's own handling.
    3. Thrown fault with a snapshot: the catch (Exception) when (_snapshot.CanServe(request.Page)) filter (:52) still guards the paths that can throw rather than fail, the local cache store itself and a cancelled fetch (:54). If the snapshot has nothing, the exception is rethrown (:57-59) so cancellation and genuine faults are not swallowed.
  • QueryAsync(request, ct) (PublicSessionScheduleService.cs:74-89): builds the effective filters described above and calls ISessionUIService.GetPagedAsync with includeChildren: true, since the public schedule renders each session's child data (:83-86).
  • ReadSnapshotAsync(page, onCacheStateChanged, ct) (PublicSessionScheduleService.cs:95-107): reads the snapshot and raises the "showing cached data" banner only when one actually answered (:98-102).
• Why it's built this way: the offline behavior is a property of this list surface, so it lives in a service the page injects rather than in the page or in the generic session service. Both the live service and the snapshot stay independently testable, and no other consumer of ISessionUIService inherits the caching.
• Where it's used: registered explicitly as IPublicSessionScheduleService at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:48, under the comment naming ADR-042 Wave 3 (:41), and injected into PublicSessionList (Pages/Public/PublicSessionList.razor.cs:31), whose grid data delegate calls FetchPageAsync at :274.
• Caveats / not-in-source: the snapshot is best-effort. Nothing here expires it, so on a device that has been offline for a long time the cached first page can be arbitrarily old; the only signal to the user is the banner the onCacheStateChanged callback raises. What the store does on a write failure is the store's concern, not visible in this class.

SpeakerInfo

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerLookupService.cs:9 · Level 0 · record

• What it is: the speaker-side lookup projection, three fields wide: Id, FullName, and a nullable ProfilePicture (ISpeakerLookupService.cs:9-12). It is what pages index when they hold a speaker id and must render a name or an avatar.
• Depends on: no first-party types. SpeakerIdentifierType is System.Guid in this module (MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:19), unlike the other Conference aliases, which are int, because speakers carry Sessionize-assigned GUIDs (BR-61, noted at MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:3).
• Concept: the UI lookup projection introduced by CategoryItemInfo; see there for the mechanism and the reason a page pre-loads a dictionary. [Rubric §18, UI Architecture]. ProfilePicture is nullable because not every speaker has an image, so the render path must have a fallback branch.
• Walkthrough: a positional record with three members and no body (ISpeakerLookupService.cs:9-12); it is filled member for member from the speaker DTO in SpeakerLookupService (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerLookupService.cs:40-41).
• Where it's used: returned as the dictionary value of ISpeakerLookupService.GetAllAsync (ISpeakerLookupService.cs:19-20), which the session and speaker surfaces inject to enrich speaker ids.
• Caveats / not-in-source: the name is reused. A separate, unrelated SpeakerInfo record exists in the Conference application layer for AI session scoring, documented as SpeakerInfo. They share only a name; the namespaces keep them apart.

SpeakerDetailLookups

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerDetailLookupService.cs:14 · Level 1 · record

• What it is: the three display lookups the speaker detail page needs before it can render a speaker, gathered into one record: the category items assigned to the speaker, the titles of the categories those items belong to, and the text of the questions the speaker answered (ISpeakerDetailLookupService.cs:14-17).
• Depends on: CategoryItemInfo as the value type of its first dictionary, plus the CategoryItemIdentifierType, ConferenceCategoryIdentifierType, and QuestionIdentifierType aliases. BCL IReadOnlyDictionary.
• Concept introduced, the composite lookup bundle. [Rubric §19, State Management] (assesses how many independent pieces of loaded state a component has to track and invalidate). The interface's doc comment states the problem it removes: the page used to issue the three loads itself and carry three nullable caches with a failure branch each, so this gathers them into one call answering with one Result<T>, leaving the page a single point of failure to report and a single cache to check (ISpeakerDetailLookupService.cs:19-24). [Rubric §1, SOLID]: the bundle is what makes the single-method composite interface possible at all, since a method can only return one value.
• Walkthrough: a positional record with three dictionary members and no body.
  • CategoryItems (ISpeakerDetailLookupService.cs:15): IReadOnlyDictionary<CategoryItemIdentifierType, CategoryItemInfo>, for the assigned-items panel.
  • CategoryTitles (line 15): IReadOnlyDictionary<ConferenceCategoryIdentifierType, string>, for grouping those items.
  • QuestionTexts (line 16): IReadOnlyDictionary<QuestionIdentifierType, string>, for the answers section.
• Why it's built this way: the three sources keep their own services because other pages share them; SpeakerDetailLookupService only composes them, short-circuiting on the first failure (SpeakerDetailLookupService.cs:22-39) so the caller reports one error instead of branching three times. Note the composition is sequential, not parallel: each await completes before the next begins.
• Where it's used: SpeakerDetail holds exactly one nullable field of this type (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerDetail.razor.cs:82), loads it once when it is still null (SpeakerDetail.razor.cs:130-138), and reads QuestionTexts when rendering an answer, falling back to the raw id when a question is missing (SpeakerDetail.razor.cs:200). CategoryTitles is handed down to SpeakerCategoryItemsPanel as a parameter (SpeakerCategoryItemsPanel.razor.cs:29, read at :36-37).

ISpeakerDetailLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerDetailLookupService.cs:25 · Level 3 · interface

• What it is: a one-method composite lookup contract for the speaker detail page. One call gathers the three display lookups that page needs before it can render a speaker: the category items assigned to the speaker, the titles of the categories those items belong to, and the text of the questions the speaker answered (ISpeakerDetailLookupService.cs:25-30). The file also declares the payload record SpeakerDetailLookups (ISpeakerDetailLookupService.cs:14-17).
• Depends on: SpeakerDetailLookups (the gathered shape), CategoryItemInfo (carried inside it), the CategoryItemIdentifierType / ConferenceCategoryIdentifierType / QuestionIdentifierType aliases, and Result from MMCA.Common.Shared.Abstractions (ISpeakerDetailLookupService.cs:2).
• Concept introduced, the composite lookup that collapses a page's failure branches. The three underlying lookups already exist as separate services, each shared with other pages. What this contract adds is aggregation of the outcome: the doc comment records the shape it replaced, a page that issued the three loads itself, carried three nullable caches, and repeated a failure branch for each (ISpeakerDetailLookupService.cs:19-24). Gathering them behind one Task<Result<SpeakerDetailLookups>> gives the page a single point of failure to report and a single cache field to check. [Rubric §18, UI Architecture] assesses whether page code-behind stays a rendering concern rather than an orchestration one; here the orchestration moved down into a service and the page keeps one if. [Rubric §15, Best Practices & Code Quality] assesses the cost of adding a fourth lookup later: it becomes one more member on the record plus one more step in the implementation, and no new branch on the page. The railway convention itself is taught at Result, and the UI-side branching helpers live on ResultUiExtensions.
• Walkthrough: one member.
  • GetAllAsync(CancellationToken cancellationToken = default) (ISpeakerDetailLookupService.cs:30): returns Task<Result<SpeakerDetailLookups>>. The contract states the failure rule explicitly, a failure in any one of the three loads fails the whole call (ISpeakerDetailLookupService.cs:27), and names the token's meaning, cancelled when the calling page is disposed (ISpeakerDetailLookupService.cs:28).
• Why it's built this way: the three sources stay independent services because other pages consume them individually; only the composition is speaker-detail-specific, so only the composition gets a new type. The implementation short-circuits on the first failure, which is what makes "one error to report" true rather than aspirational (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerDetailLookupService.cs:22-35).
• Where it's used: implemented by SpeakerDetailLookupService, registered scoped in the Conference UI composition root under a comment that repeats the rationale (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:55-57), and injected into exactly one page, SpeakerDetail (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerDetail.razor.cs:30).

ISpeakerLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerLookupService.cs:17 · Level 3 · interface

• What it is: the speaker display-enrichment contract. One call returns a speaker-keyed dictionary of SpeakerInfo so a grid or detail page can turn the speaker ids on a session into names and avatars without a request per row (ISpeakerLookupService.cs:17-21). The same file declares the SpeakerInfo record it emits (ISpeakerLookupService.cs:9-12).
• Depends on: SpeakerInfo, the SpeakerIdentifierType alias, and Result (ISpeakerLookupService.cs:1).
• Concept: the bulk-then-index lookup, the same shape as ICategoryItemLookupService and IEventLookupService: fetch one flat collection once, project it into a dictionary keyed by id, and let every consuming row do an O(1) TryGetValue instead of a fetch. [Rubric §23, Front-End Performance] assesses whether the front end avoids per-row network work; this contract is the shape that makes that possible. [Rubric §18, UI Architecture] assesses whether pages talk to typed services rather than raw HTTP; the page sees one method and no URL.
• Walkthrough: one member, GetAllAsync(CancellationToken cancellationToken = default) returning Task<Result<IReadOnlyDictionary<SpeakerIdentifierType, SpeakerInfo>>> (ISpeakerLookupService.cs:19-20). The Result wrapper is what distinguishes this from a naive dictionary-returning helper: a transport fault or a failed response arrives as a failure the page can render, never as an empty dictionary that would look like "this event has no speakers".
• Why it's built this way: the enrichment payload is deliberately narrower than SpeakerDTO, just id, full name and profile picture (ISpeakerLookupService.cs:9-12), so a change to the transport DTO that does not touch those three fields never reaches the consuming pages.
• Where it's used: implemented by SpeakerLookupService and registered scoped (DependencyInjection.cs:51). Injected into SessionDetail (Pages/Session/SessionDetail.razor.cs:25), SessionList (Pages/Session/SessionList.razor.cs:26), PublicSessionList (Pages/Public/PublicSessionList.razor.cs:33), PublicSessionDetail (Pages/Public/PublicSessionDetail.razor.cs:25), and taken as a constructor argument by the SessionLookups helper that the session pages share (Pages/Session/SessionLookups.cs:31).

ISpeakerDashboardUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerDashboardUIService.cs:10 · Level 3 · interface

• What it is: a bespoke, non-CRUD UI-service contract for a speaker's personalized dashboard: the sessions the speaker presents, per-session bookmark counts (single and batched), and per-session feedback (ISpeakerDashboardUIService.cs:10-45). It does not extend IEntityService<TEntityDTO, TIdentifierType>; it is its own read-only interface over the Conference contracts and Result<T> (ISpeakerDashboardUIService.cs:1-3).
• Depends on: SessionDTO and SessionFeedbackDTO, the SpeakerIdentifierType alias (a Guid in this module, MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:19) and SessionIdentifierType.
• Concept introduced, a cache-bypassing personalized read. [Rubric §23, Front-End Performance] and [Rubric §19, State Management] (assess how the front end balances shared caching against read-your-writes freshness for a personalized view). The doc comment on GetSpeakerSessionsAsync (ISpeakerDashboardUIService.cs:12-17) is explicit and load-bearing: this read is fetched fresh, bypassing the shared sessions output cache, so a just-made speaker assignment is reflected immediately. Without the bypass, a read-populate-after-evict race on the output cache could leave a freshly assigned speaker seeing "no sessions". The contract, not just the implementation, is where that decision is written down; the implementation honors it with a unique _= cache-bust query parameter that makes this one read a guaranteed miss while public list reads keep their cache (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerDashboardService.cs:31-38).
• Walkthrough: four read methods, all SpeakerIdentifierType-scoped.
  • GetSpeakerSessionsAsync(speakerId, ct) (ISpeakerDashboardUIService.cs:18-20): returns Task<Result<IReadOnlyList<SessionDTO>>>, the speaker's sessions, uncached. The implementation filters server-side on the virtual SpeakerId key with a page size capped at 100 and no child collections (SpeakerDashboardService.cs:18,38).
  • GetSessionBookmarkCountAsync(speakerId, sessionId, ct) (ISpeakerDashboardUIService.cs:22-25): returns Task<Result<int>>, the bookmark count for one of the speaker's sessions.
  • GetSessionBookmarkCountsAsync(speakerId, sessionIds, ct) (ISpeakerDashboardUIService.cs:32-35): returns Task<Result<IReadOnlyDictionary<SessionIdentifierType, int>>>, every requested session's active bookmark count in a single request. The doc comment (lines 27-31) records that it replaces the dashboard's per-session fan-out, that only sessions assigned to the speaker come back, and that sessions with no bookmarks map to 0. That is the [Rubric §12, Performance & Scalability] point in one signature: an N+1 of HTTP calls collapsed into one.
  • GetSessionFeedbackAsync(speakerId, sessionId, ct) (ISpeakerDashboardUIService.cs:41-44): returns Task<Result<SessionFeedbackDTO>>. Its doc comment (lines 37-40) states the modelling decision: "no feedback captured yet" arrives as an ErrorType.NotFound failure, not as a success carrying null, so the page tells that legitimate domain state apart from a real load failure (SpeakerDashboardService.cs:68-71).
• Why it's built this way: keeping these on a dedicated interface, rather than folding them into ISessionUIService, isolates the cache-bypass semantics to the personalized surface and keeps the generic session CRUD cache-friendly. It also keeps the speaker-scoped authorization story simple: every method takes the speaker id explicitly, so the server has the subject it needs to check ownership on every call [Rubric §11, Security].
• Where it's used: implemented by SpeakerDashboardService (SpeakerDashboardService.cs:14-16) and registered explicitly at DependencyInjection.cs:38 (an explicit AddScoped because it is not an IEntityService<,> and the assembly scan would not find it); injected into SpeakerDashboard (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerDashboard.razor.cs:25), which calls three of the four methods (SpeakerDashboard.razor.cs:108, :136, :269).
• Caveats / not-in-source: GetSessionBookmarkCountAsync, the single-session count, has no page consumer today; the dashboard uses the batched form. It remains on the contract, is implemented (SpeakerDashboardService.cs:45), and is covered by unit tests (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Services/SpeakerDashboardServiceTests.cs:121,135).

ISpeakerUIService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerUIService.cs:10 · Level 4 · interface

• What it is: the UI-service contract for the speakers resource, extending generic CRUD with two user-linking operations (ISpeakerUIService.cs:10-15).
• Depends on: IEntityService<TEntityDTO, TIdentifierType> bound to SpeakerDTO, Result (ISpeakerUIService.cs:2), and the SpeakerIdentifierType / UserIdentifierType aliases (the second crosses into Identity's vocabulary as a scalar, never as a project reference).
• Concept: [Rubric §9, API & Contract Design], state-transition verbs over generic update, the same rationale as IEventUIService. Linking a speaker to a user account is a distinct operation, not a field edit, so it gets LinkUserAsync / UnlinkUserAsync. [Rubric §7, Microservices Readiness] assesses whether cross-module consistency travels over decoupled edges: the UI issues one call against Conference, and the Identity side of the association is reconciled asynchronously by the SpeakerLinkedToUser / SpeakerUnlinkedFromUser integration events, so this contract deliberately says nothing about Identity. [Rubric §18, UI Architecture].
• Walkthrough: two added members, both returning Result.
  • LinkUserAsync(SpeakerIdentifierType speakerId, UserIdentifierType userId, CancellationToken) (ISpeakerUIService.cs:12).
  • UnlinkUserAsync(SpeakerIdentifierType speakerId, CancellationToken) (ISpeakerUIService.cs:14); unlink needs only the speaker id, because the association is single-valued from the speaker's side.
• Why it's built this way: a valueless Result is the right return shape for a confirm-only call. There is no payload worth deserializing, but the failure still has to carry the server's ErrorType so the page can tell "already linked" from "not permitted".
• Where it's used: implemented by SpeakerService; injected into SpeakerList (Pages/Speaker/SpeakerList.razor.cs:23), SpeakerDetail's link-to-user control (Pages/Speaker/SpeakerDetail.razor.cs:27), SpeakerCreate (Pages/Speaker/SpeakerCreate.razor.cs:17), SpeakerDashboard (Pages/Speaker/SpeakerDashboard.razor.cs:23) and the public speaker pages (PublicSpeakerList :42, PublicSpeakerDetail :22).

SpeakerDashboardService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerDashboardService.cs:14 · Level 4 · class (sealed)

• What it is: the bespoke authenticated HTTP service behind the speaker's own dashboard. It exposes four speaker-scoped reads: the sessions this speaker presents, how many attendees bookmarked one of those sessions (single and batched variants), and the aggregated feedback for a session. It extends AuthenticatedServiceBase directly rather than the CRUD base, and implements ISpeakerDashboardUIService (SpeakerDashboardService.cs:14-16).
• Depends on: AuthenticatedServiceBase for CreateAuthenticatedClientAsync() and the shared static Polly RetryPolicy (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/AuthenticatedServiceBase.cs:25,51); HttpResultExecutor and ProblemDetailsResultReader; PagedCollectionResult<T>; SessionDTO and SessionFeedbackDTO; ITokenStorageService; the SpeakerIdentifierType / SessionIdentifierType aliases; BCL IHttpClientFactory, CultureInfo.InvariantCulture, Guid.
• Concept introduced, the server-filtered, cache-bypassing dashboard read. These are computed, actor-scoped reads, not an entity surface, so the class drops to the thinner authenticated base and hand-builds each request. Two mechanisms inside GetSpeakerSessionsAsync are load-bearing, and the inline comment block (SpeakerDashboardService.cs:25-34) explains both.
  • Filter on the server, not in memory. The URL sends filters[SpeakerId].operator=equals and filters[SpeakerId].value={speakerId} (SpeakerDashboardService.cs:38), a virtual filter key. Session has no SpeakerId column, so SessionsController removes the key from the filter dictionary, parses it with TryParse under the invariant culture, and resolves it through the SessionSpeaker join before ANDing the result with the public-session specification (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Sessions/SessionsController.cs:113-122, documented at :90-94). The request also asks for includeFKs=false&includeChildren=false and caps the page at MaxSpeakerSessions = 100 (SpeakerDashboardService.cs:19,38). The comment records what this replaced: fetching the whole catalog with every child collection and filtering client-side. [Rubric §12, Performance & Scalability] (assesses whether work happens where the data is; the predicate and the paging both run in the database) and [Rubric §23, Front-End Performance] (assesses payload size on the wire; the dashboard renders no child collections, so it asks for none).
  • A deliberate cache bust. A unique _={Guid:N} query parameter (SpeakerDashboardService.cs:35,38) makes this one read a guaranteed miss against the shared output cache. The reason is a read-populate-after-evict race: a read that began before a session assignment can populate the cache after the assignment's eviction fired, so the cached list lags a change the speaker just made and must see. Public and anonymous list reads keep their caching (SpeakerDashboardService.cs:31-34). [Rubric §19, State Management] (assesses how the UI keeps what it shows consistent with the server, and at what cost). The bookmark counts are produced server-side from the Engagement service across the gRPC boundary (ADR-007); the UI sees only this one typed contract, which is what lets Engagement move without touching this file. [Rubric §7, Microservices Readiness].
• Walkthrough
  • MaxSpeakerSessions = 100 (SpeakerDashboardService.cs:19): an upper bound, on the stated reasoning that a conference speaker presents a handful of sessions (:18).
  • GetSpeakerSessionsAsync(speakerId, ct) (SpeakerDashboardService.cs:21-43) mints the cache bust (:35), builds the paged URL with string.Create(CultureInfo.InvariantCulture, ...) sorted StartsAt asc (:36-38), dispatches through the private SendGetRequestAsync<T> into a PagedCollectionResult<SessionDTO> because the paged endpoint answers with an envelope rather than a bare array (:40-41), then Maps the envelope to the item list, substituting an empty list for a null Items (:42). Map runs only on success and a failure passes through untouched, which is what makes the one-line projection safe.
  • GetSessionBookmarkCountAsync(speakerId, sessionId, ct) (SpeakerDashboardService.cs:45-52) GETs speakers/{speakerId}/sessions/{sessionId}/bookmarks/count (:50) and returns the deserialized count as a Result<int>.
  • GetSessionBookmarkCountsAsync(speakerId, sessionIds, ct) (SpeakerDashboardService.cs:54-66) is the batched variant. It short-circuits an empty id list into a successful empty dictionary with no round trip (:59-60), joins one repeated sessionIds= parameter per id (:62-63), and maps the concrete Dictionary up to the read-only interface the caller declares (:64-65). One request for a whole grid instead of one per row.
  • GetSessionFeedbackAsync(speakerId, sessionId, ct) (SpeakerDashboardService.cs:73-80) GETs speakers/{speakerId}/sessions/{sessionId}/feedback (:78). "No feedback captured yet" is a legitimate domain state and arrives as an ErrorType.NotFound failure, which the caller tells apart from a real load failure with IsNotFound(), as the doc comment states (:68-72). The typed error is the branch; there is no sentinel value to interpret.
  • SendGetRequestAsync<T>(url, ct) (SpeakerDashboardService.cs:92-104) is the central GET dispatch. HttpResultExecutor.ExecuteAsync wraps the body (:95), the client carries the bearer token (:98), the GET runs through the Polly RetryPolicy (:99-101), and ProblemDetailsResultReader turns the response into a Result<T> (:102).
  • Every URL is built with string.Create(CultureInfo.InvariantCulture, ...) and every call leads with speakerId, so the server scopes the read to the calling speaker rather than trusting a filter. [Rubric §11, Security] (assesses whether authorization scope is enforced by the resource shape rather than by client-side filtering).
• Why it's built this way: aggregate dashboard reads fit neither the entity-CRUD nor the lookup shape, so they get their own narrow service. The cache bust trades one extra origin fetch for correctness on the one surface where staleness is unacceptable, while the anonymous public list keeps its output cache.
• Where it's used: registered explicitly as ISpeakerDashboardUIService at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:38, and injected into SpeakerDashboard, the speaker's "My Sessions" page (Pages/Speaker/SpeakerDashboard.razor.cs:24).
• Caveats / not-in-source: the retry-plus-reader dispatch in SendGetRequestAsync is a deliberate private copy of the EntityServiceBase.SendRequestAsync semantics rather than inherited behavior, as the doc comment says (SpeakerDashboardService.cs:82-88), so the two must be kept in step by hand. The 100-session page cap (:19,38) is an upper bound, not a paging mechanism: a speaker with more sessions would silently see only the first 100.

SpeakerLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerLookupService.cs:12 · Level 4 · class (sealed)

• What it is: a small read service that fetches every speaker once and builds a speaker-keyed lookup dictionary (SpeakerIdentifierType to SpeakerInfo), so pages holding raw speaker ids can render display names and profile pictures (SpeakerLookupService.cs:12-45). It implements ISpeakerLookupService.
• Depends on: SpeakerInfo, the three-field projection it emits (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/ISpeakerLookupService.cs:9-12); SpeakerDTO as the wire shape; PagedCollectionResult<T>; HttpResultExecutor and ProblemDetailsResultReader; BCL IHttpClientFactory. Note what is absent: the primary constructor takes only IHttpClientFactory (SpeakerLookupService.cs:12), with no ITokenStorageService and no AuthenticatedServiceBase base. This is an unauthenticated public read, so it also gets none of that base's Polly retry.
• Concept introduced, the client-side denormalizing lookup. Session and event pages hold speaker ids but must show speaker names. Rather than issue one fetch per referenced speaker, this service pulls the whole speaker set in one call and hands back an in-memory dictionary the page indexes locally; the doc comment states exactly that use (SpeakerLookupService.cs:8-11). [Rubric §23, Front-End Performance] (assesses whether a view avoids N per-item round trips; one call serves a whole grid). [Rubric §9, API & Contract Design] shows up in the query string: includeFKs=false&includeChildren=false asks the server for the flat rows only, so the bulk read stays cheap on both ends. The dictionary is keyed by the identifier alias rather than a bare primitive, which is what makes a wrong-id lookup a compile error (ADR-048).
• Walkthrough
  • GetAllAsync(ct) (SpeakerLookupService.cs:15-30) is an expression-bodied method returning Result<IReadOnlyDictionary<SpeakerIdentifierType, SpeakerInfo>>. The body runs inside HttpResultExecutor.ExecuteAsync (:17), so a dead network becomes a transport failure rather than a thrown exception. It resolves the named "APIClient" client from the factory (:20), GETs speakers?includeFKs=false&includeChildren=false&pageSize=10000, a deliberately large page meant to pull every speaker in one request (:21-23), reads the response into a Result<PagedCollectionResult<SpeakerDTO>> through ProblemDetailsResultReader (:25-26), and then Maps that page through BuildLookup (:28). Mapping rather than unwrapping is the point: the projection runs only on success, and an API-described failure travels out with its ErrorType intact.
  • BuildLookup(page) (SpeakerLookupService.cs:32-45) is a private static. It substitutes an empty list for a null Items (:35), fills a Dictionary<SpeakerIdentifierType, SpeakerInfo> with Id, FullName and ProfilePicture per speaker (:37-42), and returns it as an IReadOnlyDictionary (:44). Being static is not decoration: it proves the projection touches no instance state, so it reads in isolation.
• Why it's built this way: one bulk fetch plus a local index is far cheaper than per-id lookups when a page renders many speaker references, and the projection to SpeakerInfo keeps only the three display fields the UI needs rather than the full SpeakerDTO, so what a page holds in memory stays small.
• Where it's used: registered as ISpeakerLookupService among the "cross-module lookup services" (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:51), and injected into SessionList (Pages/Session/SessionList.razor.cs:26), SessionDetail (Pages/Session/SessionDetail.razor.cs:25), PublicSessionList (Pages/Public/PublicSessionList.razor.cs:33) and PublicSessionDetail (Pages/Public/PublicSessionDetail.razor.cs:25).
• Caveats / not-in-source: the pageSize=10000 ceiling (SpeakerLookupService.cs:22) assumes the conference never exceeds 10,000 speakers; past that the lookup would silently miss speakers, and nothing here detects the truncation. The dictionary is rebuilt on every call (there is no memoization in this class), so a page that needs it twice pays for it twice. Because the read is unauthenticated, it sees only what the public speakers endpoint exposes.

SpeakerDetailLookupService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerDetailLookupService.cs:13 · Level 5 · class (sealed)

• What it is: a composite read service that gathers the three display lookups the speaker detail page needs (the category items a speaker can be tagged with, the titles of the categories those items belong to, and the text of the questions a speaker answered) behind one call, answering with a single Result that carries either all three or the first failure (SpeakerDetailLookupService.cs:13-40). It implements ISpeakerDetailLookupService and its success value is the SpeakerDetailLookups record.
• Depends on: three services injected through the primary constructor (SpeakerDetailLookupService.cs:13-17): ICategoryItemLookupService (implemented by CategoryItemLookupService), IConferenceCategoryUIService and IQuestionUIService, the last two being plain IEntityService<TEntityDTO, TIdentifierType> CRUD contracts (IConferenceCategoryUIService.cs:9-11, IQuestionUIService.cs:9-11). Also Result and its Map (MMCA.Common/Source/Core/MMCA.Common.Shared/Abstractions/Result.cs:276-280), the TryGetValue extension from ResultUiExtensions (MMCA.Common/Source/Presentation/MMCA.Common.UI/Common/ResultUiExtensions.cs:82), CategoryItemInfo, ConferenceCategoryDTO and QuestionDTO.
• Concept introduced, the composite lookup service. Most Conference pages load their reference data one service at a time, and every extra load costs the page a nullable cache field, a call site and a failure branch. A composite lookup collapses that into one interface, one call, one value object and one failure branch. The load-bearing detail is that it composes, it does not replace: each underlying lookup keeps its own service because other pages use them independently, and this class holds no state and no cache of its own (SpeakerDetailLookupService.cs:13-18 declares nothing but the three injected dependencies). [Rubric §1, SOLID] (assesses whether a type has one reason to change): the page's job is rendering, and the gathering of its reference data now lives in one substitutable class, so a fourth lookup is a change here rather than a fourth branch in the page. [Rubric §18, UI Architecture] (assesses how presentation is layered above data access): the page depends on one narrow interface instead of three. [Rubric §2, Design Patterns] (assesses whether a recognized pattern is applied where it earns its keep): this is a facade over three collaborators, deliberately thin enough that it adds no behavior beyond ordering and failure short-circuiting.
• Walkthrough (SpeakerDetailLookupService.cs:20-40, one method)
  • GetAllAsync(cancellationToken) starts with the category items: categoryItemLookupService.GetAllAsync(cancellationToken) (:20), then unwraps with the TryGetValue UI extension (:21). On failure it re-wraps the errors into a failure of the composite type, Result.Failure<SpeakerDetailLookups>(itemsResult.Errors) (:23), so the error list travels intact and nothing is invented at this layer.
  • The category load repeats the shape: categoryService.GetAllAsync(cancellationToken: cancellationToken) (:26), unwrap (:27), propagate errors (:29). The named argument is required because the contract's first two parameters are the includeFKs and includeChildren flags (MMCA.Common/Source/Presentation/MMCA.Common.UI/Common/Interfaces/IEntityService.cs:25-28), so this call takes both defaults and asks only for the flat rows.
  • The question load is last, so it needs no early return: questionsResult.Map(...) (:32, :34) either projects the success value or passes the errors through unchanged (Result.cs:276-280).
  • The projection builds the SpeakerDetailLookups record (:34-37). The category-item dictionary arrives already keyed from ICategoryItemLookupService (ICategoryItemLookupService.cs:20-21), while the other two are lists indexed here: categories.ToDictionary(c => c.Id, c => c.Title) (:36) and questions.ToDictionary(q => q.Id, q => q.QuestionText) (:37). Both projections keep only the single display string the page renders, so the DTOs do not travel further into the UI.
• Why it's built this way: the three loads are a set, not three independent concerns, because the page cannot render its category panel or its answers section until all three are present. Making them one call means one place decides the order and one place decides what a partial failure means, and here that decision is strict: a failure in any one of them fails the whole call (ISpeakerDetailLookupService.cs:27-30). Returning Result rather than throwing follows the framework-wide error contract (ADR-013).
• Where it's used: registered explicitly rather than by the entity-service scan, because it implements no IEntityService<,>: services.AddScoped<ISpeakerDetailLookupService, SpeakerDetailLookupService>() (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:57). Its one consumer is SpeakerDetail, which injects it (Pages/Speaker/SpeakerDetail.razor.cs:29), holds the value in a single nullable field for the life of the page (SpeakerDetail.razor.cs:81), calls it once inside the guarded load (SpeakerDetail.razor.cs:129-141), renders QuestionTexts through GetQuestionText (SpeakerDetail.razor.cs:198-199) and hands CategoryItems plus CategoryTitles to SpeakerCategoryItemsPanel (Pages/Speaker/SpeakerDetail.razor:169-172). The interface is also what SpeakerDetailTests mocks (MMCA.ADC/Tests/Modules/Conference/MMCA.ADC.Conference.UI.Tests/Pages/Speakers/SpeakerDetailTests.cs:30), which is the practical payoff of the facade: one Mock<ISpeakerDetailLookupService> stands in for three collaborators. [Rubric §14, Testability] (assesses whether collaborators can be substituted at a narrow boundary).
• Caveats / not-in-source: the three loads are sequential awaits (:20, :26, :32), not a Task.WhenAll, so the page pays the sum of the three round trips rather than the longest of them. [Rubric §23, Front-End Performance] (assesses how much latency the first render waits on). The short-circuit is ordered, so a category-item failure means the other two calls are never made and the page reports one cause even when several are broken. ToDictionary (:36-37) throws on duplicate keys and nothing here guards that; uniqueness comes from the server, since both keys are entity primary keys. Nothing in this class caches: the "cached for the life of the page" behavior is the page's own null check on its field (SpeakerDetail.razor.cs:129), not something this service does.

SpeakerService

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Services.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Services/Speakers/SpeakerService.cs:13 · Level 5 · class (sealed)

• What it is: the concrete HTTP service for the speakers WebAPI resource. It inherits the whole CRUD surface from EntityServiceBase<TEntityDTO, TIdentifierType> and adds the two operations specific to speakers: linking a user account to a speaker record and unlinking it again (SpeakerService.cs:13-36). It implements ISpeakerUIService.
• Depends on: EntityServiceBase<TEntityDTO, TIdentifierType> and, through it, AuthenticatedServiceBase; the base's Endpoint property (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/EntityServiceBase.cs:51) and its valueless SendRequestAsync overload (EntityServiceBase.cs:354-370); ITokenStorageService; SpeakerDTO; LinkUserRequest; ISpeakerUIService; Result; the SpeakerIdentifierType and UserIdentifierType aliases; BCL IHttpClientFactory and System.Net.Http.Json (SpeakerService.cs:1-5).
• Concept: the thin-leaf CRUD service is taught at ActivityService; this is that shape plus a two-method extension, and the extension is the standard recipe for adding a non-CRUD verb to an entity service. Build the relative URI from the inherited Endpoint so the resource name still lives in exactly one place, and dispatch through the base's protected SendRequestAsync instead of an HttpClient of your own, which is what buys the call the authenticated client, the Polly retry pipeline and the Result conversion through ProblemDetailsResultReader (EntityServiceBase.cs:354-370). [Rubric §9, API & Contract Design] (assesses whether the client speaks the server's contract exactly rather than an assumed one): link is a PUT to {id}/link carrying a LinkUserRequest body and unlink is a DELETE to the same path, which is precisely what the controller declares (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Speakers/SpeakersController.cs:375, :393). [Rubric §2, Design Patterns] (assesses use of template-method style bases): the subclass supplies only what varies, the resource name and the two extra verbs.
• Walkthrough
  • The primary constructor takes IHttpClientFactory and ITokenStorageService and forwards them with the resource name to the base: EntityServiceBase<SpeakerDTO, SpeakerIdentifierType>("speakers", httpClientFactory, tokenStorageService) (SpeakerService.cs:13-15). The base's fourth parameter, the optional IUiReadCache, is left at its null default (EntityServiceBase.cs:43-47), so every read here goes to the API.
  • LinkUserAsync(speakerId, userId, cancellationToken) (SpeakerService.cs:17-26): calls the valueless SendRequestAsync with a lambda that PutAsJsonAsynces a new LinkUserRequest { UserId = userId } to new Uri($"{Endpoint}/{speakerId}/link", UriKind.Relative) (:21-25). The URI is relative because the base resolves the named API client, and its configured base address, inside CreateAuthenticatedClientAsync (MMCA.Common/Source/Presentation/MMCA.Common.UI/Services/Api/AuthenticatedServiceBase.cs:51-53), which is also where the bearer token is attached (AuthenticatedServiceBase.cs:57-62). The interpolated speakerId is culture-safe because SpeakerIdentifierType aliases System.Guid (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/MMCA.ADC.Conference.GlobalUsings.IdentifierType.cs:19, ADR-048).
  • UnlinkUserAsync(speakerId, cancellationToken) (SpeakerService.cs:28-35): the same dispatch with DeleteAsync against the identical path and no body (:32-34). Both methods return the Result the base produced, success for any 2xx and otherwise the errors the ProblemDetails response described (EntityServiceBase.cs:354-370); the server answers NoContent on both success paths (SpeakersController.cs:390, :407).
  • Neither call passes an idempotencyKey or an ifMatch, both optional parameters of that overload (EntityServiceBase.cs:354-358). That matches the contract the base documents: a key is for non-idempotent writes (creates), and link and unlink are a PUT and a DELETE whose repetition lands on the same state (EntityServiceBase.cs:310-312, ADR-017).
• Why it's built this way: linking a user to a speaker is a relationship operation, not a field edit, so it is its own endpoint rather than a PUT of the whole SpeakerDTO, and the client mirrors that. Keeping the two methods on the subclass, and on ISpeakerUIService which extends the generic contract (ISpeakerUIService.cs:10-15), means pages doing plain CRUD never see them while the organizer page that needs them gets them without a cast.
• Where it's used: registered by the Scrutor scan inside AddUIModule<ConferenceUIModule>() (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/DependencyInjection.cs:29, which scans the module assembly for IEntityService<,> implementations at MMCA.Common/Source/Presentation/MMCA.Common.UI/DependencyInjection.cs:210-214), so no explicit AddScoped line exists for it. Injected as ISpeakerUIService into SpeakerList (Pages/Speaker/SpeakerList.razor.cs:23), SpeakerDetail (Pages/Speaker/SpeakerDetail.razor.cs:27), SpeakerCreate (Pages/Speaker/SpeakerCreate.razor.cs:17), SpeakerDashboard (Pages/Speaker/SpeakerDashboard.razor.cs:23), PublicSpeakerList (Pages/Public/PublicSpeakerList.razor.cs:42) and PublicSpeakerDetail (Pages/Public/PublicSpeakerDetail.razor.cs:22). The two link verbs have exactly one caller each, both on SpeakerDetail (SpeakerDetail.razor.cs:302 and :327).
• Caveats / not-in-source: the base invalidates its read cache only from the CRUD verbs, through a private InvalidateOnSuccess (EntityServiceBase.cs:165, :187, :213, :281-288), so the two link verbs here evict nothing. That is inert as written, because this service is constructed without an IUiReadCache; the server-side output cache is evicted by the controller itself on both paths (SpeakersController.cs:389, :406, ADR-040). Authorization for both endpoints is enforced server side with [HasPermission(ConferencePermissions.SpeakersManage)] (SpeakersController.cs:376, :394, ADR-020): the client sends the bearer token and reports whatever the server decides.

SpeakerQr

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerQr.razor.cs:19 · Level 1 · class (Blazor code-behind)

• What it is: the speaker-facing side of their own QR code. It renders one full-screen code that points at the speaker's PUBLIC profile page, for holding up at the podium or parking on a booth screen (class doc, SpeakerQr.razor.cs:9-11).
• Depends on: IPublicLinkBuilder (:21), ConferenceRoutePaths's PublicSpeakerDetails(id) route factory (:55, defined at MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/ConferenceRoutePaths.cs:48). Externals: the cascading Task<AuthenticationState> (:23-24), MudBlazor's BreadcrumbItem and Icons (:26,34), and the IStringLocalizer<SpeakerQr> injected by the template (SpeakerQr.razor:4). The code image itself is the shared QrCodeImage component from MMCA.Common.UI, configured in markup (SpeakerQr.razor:26-30).
• Concept introduced, the zero-fetch page and the absolute-URL payload rule. Two ideas make this the smallest complete page in the group.
  1. No backend call at all. The speaker's identity comes from the speaker_id JWT claim (:49) and the payload string is composed locally (:55), so nothing is awaited except the cascading auth state. The class doc states the consequence directly (:13-14): the page renders on the SSR prerender pass exactly as it does on the interactive pass, which removes the whole loading-state and double-fetch problem that pages such as SpeakerDashboard have to solve. [Rubric §23, Front-End Performance & Rendering] (assesses network work per view): the cheapest fetch is the one that does not exist.
  2. The payload must be an absolute public URL. LinkBuilder.BuildAbsolute(...) (:55) is not decoration. A relative path, or the origin the MAUI head's WebView serves from, would encode into a code that resolves for nobody outside that device (class doc, :15-16). Building the link through the shared builder is what keeps one page correct on the web head and on the native head at once. [Rubric §26, Front-End Security] (assesses that client-composed links point where they claim to) and [Rubric §22, Responsive & Cross-Browser] (the same component ships to two very different hosts). The name rendered beside the code (:47, markup at SpeakerQr.razor:32) is deliberate too: the in-code comment says a person scanning should be able to see whose profile they are about to open before they open it. [Rubric §21, Accessibility]: the image also carries a localized AltText (SpeakerQr.razor:27), because a QR code is opaque to a screen reader by construction.
• Walkthrough
  • State (:26-28): three fields only, the breadcrumb list, the nullable _payload, and _displayName.
  • OnInitializedAsync (:30-56): builds the two-crumb trail (:32-36), returns early when no auth state is cascaded (:38-41), reads the display name off state.User.Identity?.Name (:47), then looks for the speaker_id claim and returns unless it parses as a Guid (:49-53). Only on that path is _payload assigned (:55).
  • The null-payload branch is the page's entire error handling: the markup renders an informational alert instead of a card (SpeakerQr.razor:11-18), with an in-markup comment noting that the nav item is claim-gated but a bookmarked or typed URL still lands here without the claim. [Rubric §24, Forms, Validation & UX Safety]: an unreachable state gets a sentence, not an empty screen.
  • The code's own rendering parameters are argued in markup (SpeakerQr.razor:24-25): PixelsPerModule="14" so the code stays readable from a few steps away, and ErrorCorrection="QrErrorCorrectionLevel.Medium" so glare on a phone camera does not kill the scan.
• Why it's built this way: the public speaker page already carries the same code for whoever is reading it (class doc, :10-11); this page exists so the speaker can present that code rather than have to be found first. Deriving everything from the claim means the page cannot show one speaker's code to another.
• Where it's used: the /speaker/qr route, gated by a bare [Authorize] (SpeakerQr.razor:1-2), so any signed-in user reaches the page and only the claim decides whether a code appears. It links to the same public route PublicSpeakerDetail serves.

ActivityFormModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityFormModel.cs:25 · Level 2 · class (abstract)

• What it is: the editable activity fields, declared once, for both the create page and the detail page's inline editor. It carries the DataAnnotations rules for the text fields, the four half-picked schedule values, and the computed properties that recombine them.
• Depends on: System.ComponentModel.DataAnnotations (:1) and ActivityDTO (:2), which owns the length constants the rules quote. Its rules are executed through ModelValidation and DataAnnotationsModelValidator.
• Concept introduced, one form model behind two forms. This is the shape every Conference create/edit pair in this unit now uses, and it is worth reading once here.
  1. Rules declared once, not per control. Each property carries its own [Required] / [MaxLength] with the length taken from the DTO constant (:35-53), and the pages bridge MudBlazor's per-field validation to those attributes with a single delegate built by ModelValidation.For(...) rather than repeating Required="true" and RequiredError="..." on every MudTextField (class doc, :7-13). Because both pages bind the same ActivityFormFields component to an instance of this type, a name the create page accepts is a name the detail page accepts. [Rubric §24, Forms, Validation & UX Safety] (assesses whether validation is expressed once and consistently) and [Rubric §15, Best Practices & Code Quality]: adding a field is one property here plus one control in the shared field block.
  2. Error messages are resource keys, not sentences. ErrorMessage = "Error.NameMaxLength" (:36) is a key that the page's localizing validator resolves at render time, which is what lets DataAnnotations participate in the localization strategy of ADR-027. [Rubric §27, Internationalization]. The NameRequiredKey constant (:32) exists so the model rule and the field's own RequiredError affordance quote one key instead of two copies of a literal.
  3. The rule DataAnnotations cannot express stays out. The start/end window is four separate properties (:56-65) because two DateTime values are picked as four controls; no attribute can state "end after start", so the model exposes the raw parts plus the derived answers and leaves the check to the page, which owns the wording of the three schedule messages (class doc, :18-23). [Rubric §1, SOLID]: the model states what it can state and does not pretend to own the rest.
• Walkthrough
  • Text fields (:35-53): Name (required, ActivityDTO.NameMaxLength), Description, VenueName, VenueAddress, VenueUrl, each capped from the DTO constant.
  • Schedule parts (:56-65): StartDate / StartTime and EndDate / EndTime, nullable so "not picked yet" is representable.
  • SortOrder (:68): the tie-break between activities starting at the same instant.
  • Derived (:71-86): HasStart and HasEnd report whether both halves are present; StartsAt and EndsAt collapse a date plus a TimeSpan into one DateTime and are documented as valid only once the matching Has* is true (:76-79, :82-85).
• Why it's built this way: the create form and the edit form of the same aggregate diverging is a classic and invisible defect (a field that is required on one and optional on the other). Making the shared base the only declaration site removes the possibility rather than testing for it.
• Where it's used: subclassed by ActivityCreateModel and ActivityEditModel; bound by ActivityCreate (ActivityCreate.razor.cs:82) and ActivityDetail (ActivityDetail.razor.cs:74) through the shared ActivityFormFields component.

ActivityCreateModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityCreateModel.cs:11 · Level 3 · class (sealed)

• What it is: the create page's binding target. It adds nothing to ActivityFormModel except the mapping onto the DTO that gets posted.
• Depends on: ActivityFormModel (:11), ActivityDTO and the EventIdentifierType alias (:1,19).
• Concept introduced: none new. It is the create half of the shared-form-model pattern ActivityFormModel teaches.
• Walkthrough: ToNew(EventIdentifierType eventId) (:19-32) is the only member. It sends Id = default (:22) and lets the server mint the key, sets StartTime / EndTime from the base's combined StartsAt / EndsAt (:25-26), and stamps the owning event from the argument (:31). [Rubric §8, Data Architecture] (assesses a deliberate identity strategy): compare SpeakerCreateModel, which mints its own Guid client-side because a speaker's key is a GUID rather than a server-assigned int.
• Why it's built this way: the owning event is a create-time-only decision (the class doc says so at :5-9), so it is a parameter of the mapping rather than a property on the shared base that the edit form would also have to bind.
• Where it's used: ActivityCreate holds one instance (ActivityCreate.razor.cs:82) and calls ToNew on the save path (ActivityCreate.razor.cs:174).

ActivityEditModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityEditModel.cs:12 · Level 3 · class (sealed)

• What it is: the detail page's inline-editor binding target: the same shared fields plus the two mappings an edit needs, load-from-record and build-the-update.
• Depends on: ActivityFormModel (:12) and ActivityDTO (:1).
• Concept introduced, the edit buffer as a typed object. The older shape of these pages kept a row of loose _edit* fields on the code-behind; folding them into a model class means the buffer has a name, the copy-in and copy-out are two methods rather than twenty assignments, and the same DataAnnotations that guard the create form guard the editor. The loaded ActivityDTO is never mutated: cancelling an edit simply abandons this object. [Rubric §19, State Management & Data Flow] (assesses where mutable state lives and how long it lives). ToUpdated also carries the concurrency token forward: RowVersion = activity.RowVersion (:45) is the client half of the optimistic-concurrency contract in ADR-035, so a stale editor loses the write instead of silently overwriting a newer one. [Rubric §8, Data Architecture].
• Walkthrough
  • LoadFrom(ActivityDTO) (:16-34): null-guards, then copies the ten editable values off the loaded record, splitting the two instants back into the four picker halves (:22-25).
  • ToUpdated(ActivityDTO) (:38-56): rebuilds the DTO from the edited values over three preserved fields, Id (:44), RowVersion (:45) and EventId (:54). Preserving the event id here, rather than binding it, is what enforces the class doc's rule (:6-10) that moving an activity between events is a create plus a delete.
• Why it's built this way: an unmapped field is the failure mode of a hand-rolled edit form; keeping copy-in and copy-out adjacent in one small file makes the two halves reviewable against each other.
• Where it's used: ActivityDetail holds one instance (ActivityDetail.razor.cs:74), seeds it in StartEditing (ActivityDetail.razor.cs:144) and posts ToUpdated from SaveChangesAsync (ActivityDetail.razor.cs:209).

SpeakerFormModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerFormModel.cs:25 · Level 3 · class (abstract)

• What it is: the speaker equivalent of ActivityFormModel: the eleven editable speaker fields with their rules, shared by the organizer create page and the detail page's inline editor.
• Depends on: System.ComponentModel.DataAnnotations (:1), SpeakerDTO for every length constant (:2), and AbsoluteUrlAttribute from MMCA.Common.UI.Validation (:3,75,80,85).
• Concept introduced, the framework validation attribute alongside the BCL ones. The shared-model pattern is the one ActivityFormModel already taught; what is new here is the mix of rule sources on one model. [EmailAddress] (:62) is the BCL attribute, [MaxLength] (:43, and eight more) quotes a DTO constant, and [AbsoluteUrl] (:75,80,85) is the framework's own attribute applied to the three social URLs, so "http://..." style input is rejected in the browser with the same mechanism and the same resource-key error style as everything else. [Rubric §24, Forms, Validation & UX Safety] and [Rubric §26, Front-End Security] (assesses that user-supplied URLs are constrained before they are rendered as links). The Bio property is the instructive exception (:52-55): it carries no rule at all, and the doc explains why. The biography is stored unbounded, so the character cap the markup applies is a UI affordance rather than an invariant, and inventing a rule here would make the form stricter than the aggregate. It still lives on the model because both forms bind it. [Rubric §4, Domain-Driven Design]: a UI rule is not promoted to an invariant just because it is convenient.
• Walkthrough
  • Resource-key constants (:32,39): FirstNameRequiredKey and LastNameRequiredKey, quoted by the model rule and by the field's RequiredError affordance alike.
  • Required identity fields (:42-49): FirstName and LastName, each required and capped.
  • Optional profile fields (:52-72): Bio (unruled), TagLine, Email (format plus cap), ProfilePicture, TwitterHandle.
  • Social URLs (:75-87): LinkedInUrl, GitHubUrl, WebsiteUrl, each [AbsoluteUrl] plus a cap.
• Why it's built this way: the same argument as the activity model, with one addition. A speaker record is edited from three different places in this application (the organizer create page, the organizer detail page, and the speaker's own dashboard), so having a single declaration of the rules is what keeps the first two identical; see the caveat on SpeakerDashboard for the third.
• Where it's used: subclassed by SpeakerCreateModel and SpeakerEditModel; bound through the shared SpeakerFormFields component by SpeakerCreate (SpeakerCreate.razor:24) and SpeakerDetail (SpeakerDetail.razor:35).

SpeakerUserSearch

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerUserSearch.cs:12 · Level 4 · class (internal static)

• What it is: the candidate lookup behind the speaker-to-user link picker on SpeakerDetail. Given typed text, it returns up to ten distinct users whose email, first name or last name matches.
• Depends on: IUserUIService and UserListDTO from the Identity module (:1-2), and Result<T> (:3,59).
• Concept introduced, fanning out because the server ANDs. The remark on FindAsync (:20-25) states the constraint plainly: the paged users endpoint combines its filter parameters with AND, so one call carrying email, first name and last name would return the empty intersection for any real search term. The method therefore issues three independent single-filter calls, awaits them together, and unions the answers. [Rubric §9, API & Contract Design] (assesses whether a client can express its intent in the contract it is given): this is a client-side workaround for a server contract with no OR, and writing it down beside the code is what keeps the next reader from "simplifying" it back into one broken call. The failure policy is the second idea. ItemsOf (:59-60) turns a failed Result into an empty list, so a lookup that fails contributes nothing and the picker offers whatever the other two returned; a cancellation returns an empty list outright (:54-57). No snackbar is raised, because an error surfaced inside an autocomplete popover while a user is still typing is noise, not information. [Rubric §29, Resilience & Business Continuity] (assesses partial-failure behavior) and [Rubric §24, Forms, Validation & UX Safety]. Also worth noting is what this file's existence buys: the class doc (:8-11) says it is kept beside the page rather than inside the code-behind so the page holds only its own edit and link state. It has no component base, no injected service of its own, and takes its collaborator as a parameter, which makes it directly unit-testable without a renderer. [Rubric §14, Testability].
• Walkthrough
  • MaxSuggestions = 10 (:15), applied twice over: as the pageSize of each of the three calls and as the final Take (:52), so neither one lookup nor the union can flood the popover.
  • FindAsync (:30-61): returns empty for blank input (:35-38); starts the three tasks without awaiting each in turn (:42-44) and joins them with Task.WhenAll (:46), so the three round trips overlap; concatenates, then DistinctBy(u => u.UserId) (:51) because a person matching on two fields must appear once.
  • ItemsOf (:59-60) is a static local function, which is the pattern the analyzer baseline pushes toward: no closure over the enclosing method's state.
• Why it's built this way: linking a speaker record to a login is a rare organizer action against a large user set, so the search has to be forgiving about which field the organizer remembers while staying one interaction, not three.
• Where it's used: called only by SpeakerDetail's SearchUsersAsync (SpeakerDetail.razor.cs:291-292), which is bound to the MudAutocomplete's SearchFunc (SpeakerDetail.razor:146-148).

SpeakerCreateModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerCreateModel.cs:10 · Level 5 · class (sealed)

• What it is: the organizer create page's binding target, adding only the mapping onto the SpeakerDTO it posts.
• Depends on: SpeakerFormModel (:10) and SpeakerDTO (:1).
• Concept introduced: none new beyond SpeakerFormModel, but one detail is worth contrasting. ToNew mints the identity client-side with Id = Guid.NewGuid() (:20), where ActivityCreateModel sends Id = default and lets the server assign an int. That is the identifier-alias strategy of ADR-048 showing through: a GUID-keyed aggregate can be named before it is stored, an int-keyed one cannot. [Rubric §8, Data Architecture].
• Walkthrough: ToNew() (:17-32) is the only member. It composes FullName from the two entered parts (:23), which keeps the denormalized display name in step with the fields the organizer actually typed, and copies the remaining nine optional fields straight across.
• Why it's built this way: the create page collects exactly the shared field set and nothing else, so the subclass is a mapping and not a second declaration of the form.
• Where it's used: SpeakerCreate holds one instance (SpeakerCreate.razor.cs:43) and posts ToNew() (SpeakerCreate.razor.cs:71).

SpeakerEditModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerEditModel.cs:11 · Level 5 · class (sealed)

• What it is: the edit buffer for the inline speaker editor on the organizer detail page: the shared fields plus load-from-record and build-the-update.
• Depends on: SpeakerFormModel (:11) and SpeakerDTO (:1).
• Concept introduced: the typed edit buffer, as ActivityEditModel describes it. The speaker variant preserves one more field on the way out.
• Walkthrough
  • LoadFrom(SpeakerDTO) (:18-33): null-guards, then copies the ten editable values off the displayed speaker. The doc frames the value plainly (:15-17): opening the editor becomes one call rather than ten assignments on the page.
  • ToUpdated(SpeakerDTO) (:40-61): edited values over four preserved ones, Id (:46), RowVersion (:47, ADR-035), the recomposed FullName (:50), and LinkedUserId (:59). Preserving the linked user is the same trick ActivityEditModel uses on the owning event: linking and unlinking is its own action on the detail page (see SpeakerDetail), so the field cannot be bound and cannot be lost. [Rubric §24, Forms, Validation & UX Safety].
• Why it's built this way: an edit form that silently drops a field it does not display is the failure this shape removes; every field the editor does not own is re-sent from the loaded record, in one visible place.
• Where it's used: SpeakerDetail holds one instance (SpeakerDetail.razor.cs:73), seeds it in StartEditing (SpeakerDetail.razor.cs:209) and posts ToUpdated from SaveChangesAsync (SpeakerDetail.razor.cs:232).

SpeakerCreate

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerCreate.razor.cs:15 · Level 6 · class (Blazor code-behind)

• What it is: the organizer's speaker-creation form. It binds one SpeakerCreateModel, validates it, posts one SpeakerDTO, and redirects to the detail page for the record it just made.
• Depends on: ISpeakerUIService (:17), IToastService (:19), SpeakerCreateModel (:43), ModelValidation and DataAnnotationsModelValidator (:37), ConferenceRoutePaths (:32,80,92), and ErrorMessages (:64). Externals: NavigationManager (:18), MudBlazor's MudForm, BreadcrumbItem and Icons, and the IStringLocalizer<SpeakerCreate> from the template (SpeakerCreate.razor:6). The markup mounts the shared UnsavedChangesGuard, SpeakerFormFields and ErrorSummary components (SpeakerCreate.razor:10,24,35).
• Concept introduced, the model-validated create page. The create shape itself (validate, post, snackbar, redirect) is taught by the smaller create pages in this group. What this page adds is the bridge between DataAnnotations and MudBlazor.
  1. One validation delegate for the whole form. OnInitialized builds _validate = ModelValidation.For(_model, new DataAnnotationsModelValidator(L)) (:37, field at :50) and the shared field block hands that single Func<object, string, IEnumerable<string>> to every control (SpeakerCreate.razor:24-25). MudBlazor calls it with the model instance and the member path, and the model's own attributes decide the outcome, so no rule is written twice (in-code comment, :48-49). The localizer passed into the validator is what turns the resource keys on SpeakerFormModel into sentences, per ADR-027. [Rubric §24, Forms, Validation & UX Safety] and [Rubric §27, Internationalization].
  2. Validate before you mutate. CreateSpeakerAsync awaits _form.ValidateAsync() and returns with a warning toast on !_form.IsValid (:61-66) before any service call. The server validates again; this pass keeps a round trip off the wire and puts the message beside the field.
  3. A dirty flag that cannot block its own redirect. Every field change calls MarkDirty() (:52, wired at SpeakerCreate.razor:25), the guard reads it through an accessor (SpeakerCreate.razor:10), and the success path clears _isDirty before navigating, with the reason on the line (:78). [Rubric §25, Navigation & Information Architecture].
  4. Cancel on disposal. A page-scoped CancellationTokenSource (:21) is passed to the post (:71) and cancelled in the full Dispose(bool) pattern (:96-116); OperationCanceledException is caught and ignored as the expected teardown or InteractiveAuto transition outcome (:82-85, see ADR-056).
• Walkthrough
  • OnInitialized (:26-38): the three-crumb trail (Home, Speakers, Create) with the last crumb disabled, then the validation delegate.
  • CreateSpeakerAsync (:54-90): null-guard the form (:56), validate, set IsSaving (:68), post _model.ToNew() (:71), report a failed create as a localized snackbar (:74), then clear the dirty flag, snackbar success, and route to ConferenceRoutePaths.SpeakerDetails(created.Id) (:80) using the id read back from the response. The finally always clears IsSaving (:86-89), so a failed save leaves an enabled button rather than a stuck spinner.
  • NavigateToList (:92) is the cancel action, and it goes through the route constants rather than a literal.
• Why it's built this way: pushing the rules onto the shared model leaves the page holding only the things that are genuinely page-level, the breadcrumb trail, the save orchestration, and the navigation.
• Where it's used: the /speakers/create route with [Authorize(Roles = "Organizer")] (SpeakerCreate.razor:1-2), reached from SpeakerList's create button and redirecting to SpeakerDetail.

SpeakerCategoryItemsPanel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerCategoryItemsPanel.razor.cs:17 · Level 8 · class (Blazor code-behind)

• What it is: the "Additional Info" panel of the organizer speaker detail page. It renders a speaker's category items grouped by category as removable chips, and offers the not-yet-assigned items in an add picker.
• Depends on: ISpeakerCategoryItemUIService (:18), IToastService (:19), SpeakerDTO and SpeakerCategoryItemDTO (:3,22,42), CategoryItemInfo (:25,52), and the CategoryItemIdentifierType, ConferenceCategoryIdentifierType and SpeakerCategoryItemIdentifierType aliases.
• Concept introduced, the container/presentational split with a partial ownership boundary. The panel is presentational about data and self-sufficient about actions, and the class doc names the division exactly (:9-15).
  • The page owns and reloads the speaker, and owns both lookups; all three arrive as [Parameter]s (:22,25,28), and the panel never fetches them.
  • The panel calls the child-entity service itself (:70, :91) and then raises the Changed callback (:31,79,99), whose handler on the page is LoadAsync (SpeakerDetail.razor:172). So the mutation is local, but the refresh is the page's, and the page stays the single source of truth for what is on screen. [Rubric §18, UI Architecture & Component Design] (assesses decomposition and where responsibility sits) and [Rubric §19, State Management & Data Flow].
  • It owns its own CancellationTokenSource (:33) and its own IDisposable implementation (:107-129), because it makes its own calls. A child component that awaits must cancel on its own disposal; inheriting the parent's token would tie its lifetime to the wrong component. The lookups are passed as IReadOnlyDictionary (:25,28) rather than lists, so both label helpers are O(1) and both fall back to the raw id when a lookup is missing (:36-40), which is the same never-render-blank rule the other detail pages follow. [Rubric §24, Forms, Validation & UX Safety].
• Walkthrough
  • GetCategoryTitle / GetCategoryItemName (:36-40): dictionary lookups with an invariant-culture id fallback.
  • GetCategoryItemsGroupedByCategory (:42-50): returns empty until the lookup arrives, then filters the speaker's items to those the lookup knows and groups them by their category id, which is what produces the per-category chip rows (SpeakerCategoryItemsPanel.razor:8-20).
  • GetAvailableCategoryItems (:52-59): builds a HashSet of the already-assigned item ids and offers the complement, so the picker cannot propose a duplicate.
  • AddCategoryItemAsync (:61-85): no-ops without a selection (:63-66), calls AddAsync(Speaker.Id, id, token) (:70), reports failure through a localized error toast and returns (:71-75), otherwise clears the selection, toasts success, and awaits Changed (:77-79).
  • RemoveCategoryItemAsync (:87-105): the same shape over DeleteAsync, bound to each chip's OnClose (SpeakerCategoryItemsPanel.razor:15).
  • Both handlers swallow OperationCanceledException as expected disposal (:81-84, :101-104).
• Why it's built this way: the chip panel was extracted from the detail page so that page holds only its own edit and link state. Keeping the add/remove calls inside the panel while leaving the reload to the parent preserves the pre-split behavior exactly (class doc, :13-15) without giving the child a second copy of the speaker.
• Where it's used: rendered once by SpeakerDetail (SpeakerDetail.razor:169-172), fed Speaker, _lookups?.CategoryItems and _lookups?.CategoryTitles, with Changed bound straight to the page's LoadAsync. It is not routable and carries no @page directive.

SpeakerDetail

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerDetail.razor.cs:24 · Level 8 · class (Blazor code-behind)

• What it is: the organizer's speaker console. It loads one speaker with children by route id, inline-edits the profile, shows the answered questions and the speaker's sessions, hosts the category-item panel, links or unlinks a login, and deletes with confirmation.
• Depends on: ISpeakerUIService, ISessionUIService, ISpeakerDetailLookupService returning SpeakerDetailLookups, and IUserUIService (:27-30); IToastService (:32); SpeakerEditModel (:72), SpeakerUserSearch (:291), ModelValidation and DataAnnotationsModelValidator (:54), ErrorMessages (:115,224), and ConferenceRoutePaths (:49,343,345). It extends DetailPageBase (SpeakerDetail.razor:8), which supplies PageToken, IsEditing, IsDirty, MarkDirty, BeginEdit, EndEdit and the disposal pattern. Externals: MudBlazor's MudForm, MudAutocomplete and BreadcrumbItem, plus the IStringLocalizer<SpeakerDetail> from the template.
• Concept introduced, the load-generation guard. Every detail page in this group guards against a re-render refetching (OnParametersSetAsync compares Id against _loadedId, :84-93). This page carries a second, stronger guard that is worth reading closely. _loadGeneration (:65) is incremented at the top of LoadAsync (:98) and each awaited step re-checks its captured generation before touching page state (:107, :132, :184). The doc comment states the reason precisely (:59-64): _loadedId is stamped synchronously before the await, so two rapid route changes would let a later-completing fetch of the older speaker paint over the newer one. The generation, not the route id, is authoritative. The finally applies the same rule to the spinner (:151-156): only the current generation may clear IsLoading, because an unconditional clear would switch off a spinner that a newer load just turned on. [Rubric §19, State Management & Data Flow] (assesses reconciliation of concurrent updates to view state) and [Rubric §12, Performance & Scalability] (the cheap fix is to serialize the loads, which would be slower and still wrong). Two further mechanisms sit alongside it.
  1. Server-side filtering instead of client-side filtering. LoadSpeakerSessionsAsync (:168-196) sends a SpeakerId equals filter (:170-173) with includeChildren: false (:181) and sortColumn: "StartsAt" (:179), capped at MaxSpeakerSessions = 100 (:37). The remark records what it replaced (:163-167): the page used to pull the entire session catalog with all child collections and filter it in memory on SessionSpeakers, purely so it could match. [Rubric §12, Performance & Scalability] (assesses whether work happens where the data lives).
  2. One composite lookup, cached for the page. The three display lookups arrive in a single LookupService.GetAllAsync(PageToken) call, and only when _lookups is null (:129-141), so re-entering LoadAsync after a link or unlink does not refetch them. A failed lookup is reported and stops the load (:137-140). [Rubric §23, Front-End Performance & Rendering]. Result handling is uniform: IsNotFound() gets a dedicated not-found message and a null record (:112-117), and every other failure goes through NotifyOnFailure(Toast, L) (:121,191,234,241,276), which is the framework's one-line "report whatever went wrong, localized" path.
• Walkthrough
  • OnInitialized (:43-55): breadcrumbs plus the shared validation delegate over _model (:54).
  • OnParametersSetAsync (:84-93) then LoadAsync (:95-158): parse the route id defensively (:105; the comment at :103-104 notes an unconstrained string route parameter degrades to Guid.Empty and resolves to not-found rather than throwing out of the render), fetch with children (:106), fetch the lookups once (:129-141), then the sessions (:143).
  • Edit cycle: StartEditing (:201-210) seeds SpeakerEditModel from the loaded record and calls the base's BeginEdit(); CancelEditing (:212) is one call to EndEdit(), which clears the dirty flag the unsaved-changes guard reads (SpeakerDetail.razor:13). SaveChangesAsync (:214-257) validates the form, posts _model.ToUpdated(Speaker) (:231), then re-fetches the speaker (:238) so the page shows the server's version, including the new RowVersion for the next edit.
  • DeleteSpeakerAsync (:259-287): confirms through the shared DeleteConfirmation dialog seeded with the speaker's full name (:266), and treats anything other than exactly true as a cancel, so a dismissed dialog is not a delete.
  • Link and unlink (:289-341): SearchUsersAsync delegates to SpeakerUserSearch (:291); OnUserPickedAsync (:293-316) posts LinkUserAsync and reloads; UnlinkUserAsync (:318-341) is the mirror. Both reload through LoadAsync rather than patching local state, which is exactly why the generation guard matters: a link followed quickly by an unlink starts two loads.
  • GetQuestionText (:198-199) resolves an answered question's text from the cached lookups with an id fallback.
• Why it's built this way: this page is the widest read surface in the organizer area, so it composes four services rather than growing one. Delegating the chip panel to SpeakerCategoryItemsPanel, the candidate search to SpeakerUserSearch, the field rules to SpeakerFormModel, and the edit lifecycle to DetailPageBase is what keeps the code-behind at load, save, delete and link. [Rubric §15, Best Practices & Code Quality].
• Where it's used: the /speakers/{Id} route with a bare [Authorize] (SpeakerDetail.razor:1-2), reached from SpeakerList rows and from SpeakerCreate's success redirect. Session rows navigate on to SessionDetail (:345). It edits the aggregate the Speaker entity models.

ActivityCreate

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityCreate.razor.cs:19 · Level 9 · class (Blazor code-behind)

• What it is: the organizer form that schedules an activity, meaning the non-session items on a programme (registration, breaks, receptions, after-parties). It collects the name, the owning event, the start and end of the window as separate date and time pickers, the display order, and an optional off-site venue (class doc, :12-17).
• Depends on: IActivityUIService (:20), IEventLookupService returning EventInfo (:21,78), IToastService (:23), ActivityCreateModel (:81), CurrentEventSelector (:61), ModelValidation with DataAnnotationsModelValidator (:41), ConferenceRoutePaths (:36,182,194), and ErrorMessages (:160,166). Externals: NavigationManager, MudBlazor's MudForm and BreadcrumbItem, and the IStringLocalizer<ActivityCreate> from the template (ActivityCreate.razor:6).
• Concept introduced, the cross-field rule that lives outside the form. Every other rule on this page is declared on ActivityFormModel and executed by MudBlazor through the shared _validate delegate. The schedule window cannot be: no DataAnnotation states "end after start" across four controls. ValidateSchedule (:126-148) therefore checks the model's own HasStart / HasEnd / StartsAt / EndsAt and puts its message in _scheduleError (:130,136,142) instead of the form's error list, and the markup renders that string in its own MudAlert above the shared error summary (ActivityCreate.razor:30-33, summary at :41). A cross-field failure therefore reads like every other validation error to the organizer even though MudForm knows nothing about it. [Rubric §24, Forms, Validation & UX Safety] (assesses whether a form can express only legal input and explains a rejection in place): the check runs before anything is posted (:164) and the snackbar quotes the specific message rather than a generic one (:166). The second idea is the two-stage smart default, which removes the two most common clicks without hiding either field.
  1. The event picker is seeded with CurrentEventSelector.SelectCurrentOrNext evaluated over each event's start date, end date and IANA time zone against DateTime.UtcNow (:59-66), rather than the weaker "auto-select when exactly one exists" rule.
  2. ApplyEventDateDefaults (:109-119) then seeds both date pickers with the selected event's first day (:116-118), and re-runs on every event change through OnEventSelected (:99-103). Both stages use ??= (:59, :117-118), so a value the organizer already chose is never overwritten. [Rubric §24, Forms, Validation & UX Safety]. The event lookup is explicitly non-critical (comment, :50-51): a failed load leaves the picker empty and the required-event check at :158 guides the user, rather than blocking the page. [Rubric §29, Resilience & Business Continuity].
• Walkthrough
  • OnInitialized (:30-42): three breadcrumbs, then the validation delegate over _model.
  • OnInitializedAsync (:44-74): loads the events through the page _cts.Token (:52), resolves the default event, applies the date defaults (:68), and swallows OperationCanceledException as the expected disposal or InteractiveAuto transition outcome (:70-73, ADR-056).
  • CreateActivityAsync (:150-192): validate the form and re-check _eventId is null (:157-162), run ValidateSchedule (:164), post _model.ToNew(_eventId.Value) (:173), clear _isDirty before navigating (:180), and route to ConferenceRoutePaths.ActivityDetails(createdActivity.Id) (:182) using the key the server assigned. The finally always clears IsSaving (:188-191).
  • NavigateToList (:194) and the standard Dispose(bool) / Dispose pair (:196-218), guarded by _disposed so the _cts is cancelled and disposed exactly once.
• Why it's built this way: an activity belongs to exactly one event and its schedule is a window rather than a point, so the form's job is to make the window easy to enter and impossible to invert. Defaulting the event and both dates from the selected conference removes the routine clicks, and keeping the window check in the code-behind lets one message name the actual problem (a missing part versus an inverted window) instead of a generic "invalid form".
• Where it's used: the /activities/create route with [Authorize(Roles = "Organizer")] (ActivityCreate.razor:1-2), reached from ActivityList's create button; on success it hands off to ActivityDetail.
• Caveats / not-in-source: StartsAt and EndsAt compose local DateTime values from the pickers with no time-zone conversion, even though the event's TimeZone is available on EventInfo and is used for the default-event choice. How the posted StartTime and EndTime are interpreted downstream is decided by the command handler, not by this page.

ActivityDetail

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityDetail.razor.cs:20 · Level 9 · class (Blazor code-behind)

• What it is: the organizer's activity record page. It loads one activity by route id, inline-edits every field except the owning event, and deletes with confirmation (class doc, :14-18).
• Depends on: IActivityUIService (:23), IEventLookupService returning EventInfo (:24,65), IToastService (:26), ActivityEditModel (:73), ActivityDTO (:66), ModelValidation with DataAnnotationsModelValidator (:61), ErrorMessages (:106,195,201), and ConferenceRoutePaths (:56,277), plus the shared DeleteConfirmation component (:78). Externals: System.Globalization, MudBlazor's MudForm, and the IStringLocalizer<ActivityDetail> from the template.
• Concept introduced, culture-formatted display and the field that is deliberately not editable. The detail-page mechanics are the ones SpeakerDetail teaches (load-once guard on _loadedId, :86-95; edit buffer; confirm-then-delete; cancel-on-disposal). Note that this page manages its own CancellationTokenSource and _isEditing flag (:30,70) rather than extending DetailPageBase, which is the shape SpeakerDetail uses. Two things are specific here.
  1. Two computed display properties. EventName (:35-39) resolves the activity's EventId against the lookup and falls back to the invariant-culture id, so the read-only event line never renders blank. TimeRange (:41-48) formats the window as one localized sentence by passing the start ("f", full date and time) and the end ("t", short time) rendered in CultureInfo.CurrentCulture into the Text.TimeRange resource; the joining wording lives in the .resx, not in the code, so a locale can reorder or reword the range. [Rubric §27, Internationalization] (assesses whether user-visible text and formats follow the request culture, ADR-027).
  2. The immutable field on an editable record. ActivityEditModel has no event property and re-sends EventId from the loaded record, so this form cannot even express a move between events, which is the rule the class doc states (:15-17). [Rubric §24, Forms, Validation & UX Safety]. The window check reappears here as ValidateSchedule (:161-183) with the same three localized keys as ActivityCreate, so the create and edit paths validate a window identically. They are two copies of the same small method rather than one shared helper, which is the maintenance cost of keeping each page self-contained. [Rubric §15, Best Practices & Code Quality].
• Walkthrough
  • OnInitialized (:50-62): breadcrumbs plus the validation delegate.
  • OnParametersSetAsync (:86-95) then LoadAsync (:97-134): fetch with children (:102), treat IsNotFound() as the page's not-found state with a localized message (:103-108), report any other failure through NotifyOnFailure (:112), then hydrate the event lookup once (:120-124) with the comment noting that a failed lookup is reported and stops the load exactly as it did when the same failure arrived as an exception (:118-119). The finally clears IsLoading (:132).
  • StartEditing / CancelEditing (:136-154): seed the edit model from the record, clear _scheduleError and _isDirty on both paths, so neither a stale cross-field error nor the unsaved-changes guard can fire after a cancel.
  • SaveChangesAsync (:185-244): validate the form, run ValidateSchedule, post _model.ToUpdated(Activity) (:208), then re-fetch (:215). The reload has three outcomes, and all three are handled: a value refreshes the page (:216-219), a IsNotFound() drops the page into its not-found state (:220-225, with the comment recording that this matches the previous null answer), and anything else reports and returns (:226-230).
  • DeleteActivityAsync (:246-275): confirm through _deleteConfirm.ShowAsync(Activity.Name) (:253), return unless the answer is exactly true (:254), delete, toast, and navigate back to the list.
  • Disposal (:279-301): the standard guarded Dispose(bool) pair over the _cts at :30.
• Why it's built this way: an activity is a per-event programme item, so its name, window, order and venue are freely editable while its owning event is not. The re-fetch after save keeps the concurrency token current for the next edit, and handling the reload's not-found branch means a record deleted by someone else mid-edit resolves to the same empty state the page shows on a bad id.
• Where it's used: the /activities/{Id:int} route with [Authorize(Roles = "Organizer")] (ActivityDetail.razor:1-2), reached from ActivityList rows and from ActivityCreate's success redirect. It edits the aggregate the Activity entity models.

SpeakerDashboard

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerDashboard.razor.cs:22 · Level 9 · class (Blazor code-behind)

• What it is: the signed-in speaker's own console. It shows their profile with an inline editor, the sessions they present at the current or next event, the bookmark count per session, and their per-session feedback on demand (class doc, :13-19).
• Depends on: ISpeakerUIService (:23), ISpeakerDashboardUIService (:24), IEventLookupService (:25), AuthenticationStateProvider (:26), IToastService (:27), SpeakerDTO, SessionDTO, SessionFeedbackDTO (:38-42), CurrentEventSelector with EventInfo (:169), and the IStringLocalizer<SpeakerDashboard> from the template.
• Concept introduced, the claim-scoped self-service page. Three mechanisms distinguish this from the organizer pages in this unit.
  1. Identity comes from the token, not the route. There is no [Parameter] id: the speaker is read from the speaker_id claim (:76-86), and a missing or unparseable claim sets _hasSpeakerId = false (:81) and renders one informational alert (SpeakerDashboard.razor:19-21). The server enforces the same scope; the claim just decides what this page asks for. [Rubric §11, Security] (assesses that a self-service view derives its subject from the authenticated principal, ADR-004) and [Rubric §26, Front-End Security].
  2. Skip the loads on the prerender pass. OnInitializedAsync returns immediately when !RendererInfo.IsInteractive (:68-71), with the comment recording exactly what that saves: the profile, the sessions and the per-session bookmark counts used to run twice per visit, once for SSR prerender and once for the interactive instance (:65-67). The prerender pass shows the loading skeleton instead. [Rubric §23, Front-End Performance & Rendering] and ADR-056.
  3. One batched count call. GetSessionBookmarkCountsAsync(_speakerId, sessionIds, ...) (:136) returns every count from one grouped query; the comment records that each count was previously its own cross-service hop, HTTP to Conference to gRPC to Engagement (:129-131). The result is best effort: a failure is ignored with no snackbar so the dashboard still renders (:134-135). [Rubric §12, Performance & Scalability] and [Rubric §29, Resilience & Business Continuity]. The read scope is worth stating explicitly, because the class doc does (:16-19): a speaker is not a privileged reader, so the server returns only publicly visible sessions (accepted-or-unset), which means a submission still under review does not appear here. The empty-state copy names that. [Rubric §11, Security]. Reads go through ISpeakerDashboardUIService rather than the shared sessions service on purpose: the comment at :104-106 records that the dashboard path bypasses the shared sessions output cache, so a just-made speaker assignment shows immediately instead of lagging behind a cached public list.
• Walkthrough
  • State (:36-55): the claim flag and id, the full session list and the event-narrowed one, the current event name, and four collections keyed by session id, _bookmarkCounts, _sessionFeedback, _expandedSessions and _feedbackLoading, plus the profile edit fields.
  • OnInitializedAsync (:57-159): breadcrumbs, the interactivity gate, the claim read, the profile load (a not-found renders the empty dashboard without a toast, :92-99), the session load ordered by StartsAt (:114), the current-event narrowing (:116-127), and the batched counts. The outer catch (Exception) (:149-154) is explained in place: the authentication state provider is the one collaborator that still reports failure by throwing, while everything else returns a Result.
  • ResolveCurrentEventAsync (:161-175): non-critical by design (comment, :163), it returns null on a failed lookup and the page then shows all of the speaker's sessions rather than none.
  • Profile edit (:177-249): StartEditingProfile copies six fields into _edit* shadow fields (:184-189); SaveProfileAsync rebuilds a full SpeakerDTO carrying RowVersion (:208) and every field the speaker may not edit re-sent unchanged (:209-211,214-215,220), posts, re-fetches (:230) and leaves edit mode.
  • ToggleFeedbackAsync (:251-289): the HashSet.Add return value doubles as the toggle (:253-257), an already-cached session returns immediately (:259-262), and the fetch sets a per-session loading flag with an explicit StateHasChanged() (:264-265) because the spinner has to appear before the await. A not-found is treated as "no feedback captured yet" and left to the panel's empty state rather than reported (:274-279). [Rubric §23, Front-End Performance & Rendering]: feedback is fetched per session on first expand, never for the whole list.
• Why it's built this way: the dashboard is the one page a speaker sees on conference day, so it favors rendering something useful over rendering everything: a failed count load, a failed event lookup, or missing feedback each degrade to a smaller view rather than an error page.
• Where it's used: the /speaker/dashboard route with a bare [Authorize] (SpeakerDashboard.razor:1-2); the claim, not the role, decides what it can show. It reads the same aggregate SpeakerDetail edits.
• Caveats / not-in-source: the profile editor here does not use SpeakerFormModel. It binds six loose _edit* fields (:49-54) and its caps come from SpeakerDTO constants applied as MudBlazor MaxLength / Counter affordances in markup (SpeakerDashboard.razor:42-55), so it has no DataAnnotations pass and its MudForm (:55) is never validated in the code-behind. The organizer create and edit forms share their rules; this third editing surface does not.

ActivityList

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Activities · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Activities/ActivityList.razor.cs:20 · Level 10 · class (Blazor code-behind)

• What it is: the organizer browse page for activities: a server-paged MudDataGrid with a name search, start-time, venue and display-order columns, an event filter, a mobile card layout, and delete-with-confirmation.
• Depends on: extends EventFilteredListPageBase<TDto> closed over ActivityDTO (:19), which itself extends DataGridListPageBase<TDto> and supplies Toast, IsMobile, LoadServerDataAsync, the event lookup and the persisted event filter. It injects IActivityUIService (:24) and uses ListPageActions (:46,92), ErrorMessages (:98), ConferenceRoutePaths (:101-102), the MobileInfiniteScrollList<TItem> and DeleteConfirmation components (:32-33), and Result<T> as the mobile fetch's return type (:77).
• Concept introduced, the event-filtered list page as a thin override set. Once the base class owns the event lookup, the persisted eventId filter and the current-or-next default, a list page is reduced to five small overrides, and this page is the clearest place to read them.
  • SavePageFilters / RestorePageFilters (:39-43) persist only the page's own filter, the search string; the event choice is the base's business.
  • ReloadForEventFilterAsync (:48) tells the base how to refresh this page, which here means "reload whichever layout is on screen".
  • ApplyFilters (:69-74) adds the search term as a contains filter on Name and then calls the base's ApplyEventFilter (:73), which adds EventId equals when a scope is selected (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Common/EventFilteredListPageBase.cs:193-198). For activities that key needs no special handling: EventId is a real Activity column, so it travels straight through the generic filter pipeline (class doc, :14-16). Contrast SpeakerList.
  • GridRef (:28) hands the base the grid instance it needs to reload. [Rubric §15, Best Practices & Code Quality] (assesses whether shared behavior is factored rather than repeated) and [Rubric §1, SOLID]: the base defines the algorithm, the page supplies the varying steps. The startup race the base solves is still visible in the page: both fetch paths await WaitForEventsAsync() first (:60, :79), because the grid's first ServerData call can run ahead of initialization and ApplyFilters executes inside the base's LoadServerDataAsync (in-code comment, :58-59). Miss that await and the first page loads unscoped. What is specific to activities is the mobile sort: FetchMobilePage pins "StartTime", "asc" (:85) because, as the comment says, the programme reads chronologically (:84), while the desktop grid lets the organizer re-sort any sortable column. The two layouts share filters and a data contract but not ordering. [Rubric §22, Responsive & Cross-Browser]: one DTO feeds the desktop grid and the mobile infinite-scroll list, switched on the base's IsMobile. [Rubric §12, Performance & Scalability]: paging, searching, sorting and filtering all happen server-side.
• Walkthrough
  • FormatStartTime (:37): the grid's start-time cell rendered in the viewer's culture ("g", short date plus short time). [Rubric §27, Internationalization].
  • RetryLoadAsync (:31): the inline error state's retry, a null-safe ReloadServerData().
  • OnSearchChanged (:50-54): store the term, reload the active layout.
  • LoadServerData (:56-67): wait for events, then hand the base the fetch delegate and ApplyFilters.
  • FetchMobilePage (:77-86): the same filters against the mobile page size, with the chronological sort pinned.
  • DeleteActivityAsync (:91-99): delegates the whole confirm, delete, toast and reload sequence to ListPageActions, passing the shared dialog, the activity name, the delete call, the success message and the reload.
  • NavigateToCreate / NavigateToDetails (:101-102): route constants, never literals. [Rubric §25, Navigation & Information Architecture].
• Why it's built this way: an organizer works one conference at a time, so scoping to an event is the default rather than an option, and the base class makes that scoping identical on every list page in the module.
• Where it's used: the /activities route with [Authorize(Roles = "Organizer")] (ActivityList.razor:1-2), linking on to ActivityCreate and ActivityDetail.

SpeakerList

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Speakers · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Speakers/SpeakerList.razor.cs:19 · Level 10 · class (Blazor code-behind)

• What it is: the organizer browse page for speakers: server-side paging with a full-name search and avatars, an event filter, a mobile card layout, and delete-with-confirmation.
• Depends on: extends EventFilteredListPageBase<TDto> closed over SpeakerDTO (:18), and injects ISpeakerUIService (:23). It uses ListPageActions (:42,86), ErrorMessages (:92), ConferenceRoutePaths (:95-96), the MobileInfiniteScrollList<TItem> and DeleteConfirmation components (:31-32), and Result<T> (:73).
• Concept introduced, the virtual filter key. Structurally this is ActivityList: the same five overrides over the same base, the same WaitForEventsAsync guard before both fetches (:56, :75), the same delegation of delete to ListPageActions. One thing genuinely differs, and it is the interesting part. ApplyEventFilter (:69) adds filters["EventId"] exactly as it does for activities, but a Speaker has no EventId column: a speaker relates to an event through the EventSpeaker and SessionSpeaker joins. So EventId here is a virtual filter key. The paged speakers endpoint intercepts it, removes it from the filter dictionary before the generic filter pipeline ever sees it, and resolves the scope through those joins instead (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.API/Controllers/Speakers/SpeakersController.cs:120-122,152-159). The client-side contract is therefore identical for both entities while the server-side resolution is not. [Rubric §9, API & Contract Design] (assesses whether a query contract can express a client's intent without leaking the storage shape) and [Rubric §8, Data Architecture]: the join stays server-side, where the indexes are, instead of becoming a two-step client fetch. The class doc records this in one sentence at the top of the page (:13-16), which matters: a reader who assumes EventId is a column would look for it on the DTO and find nothing.
• Walkthrough
  • SavePageFilters / RestorePageFilters (:35-39): persist and restore the search term only.
  • ReloadActiveLayoutAsync (:41-42) and ReloadForEventFilterAsync (:44): one reload path for both layouts, via ListPageActions.
  • LoadServerData (:52-63) and ApplyFilters (:65-70): the search term as a contains filter on FullName (:68), the denormalized display name, then the event filter.
  • FetchMobilePage (:73-80): the same filters sorted "FullName", "asc" (:79), because a speaker roster reads alphabetically where a programme reads chronologically (compare ActivityList).
  • DeleteSpeakerAsync (:85-93): confirm, delete, toast, reload, all through the shared helper, seeded with the speaker's full name.
  • RetryLoadAsync (:30) backs the inline error state; NavigateToCreate / NavigateToDetails (:95-96) use the route constants.
• Why it's built this way: the organizer wants "the speakers at this conference", not "the speakers whose row carries this id". Expressing that as an ordinary filter key keeps the page identical to every other event-filtered list, and the one place that knows it is not an ordinary column is the endpoint that can resolve it cheaply.
• Where it's used: the /speakers route with [Authorize(Roles = "Organizer")] (SpeakerList.razor:1-2), linking on to SpeakerCreate and SpeakerDetail. Its public counterpart is PublicSpeakerList, which applies the same virtual key with a locked scope.

ConferenceCategoryItemEditModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Categories/ConferenceCategoryItemEditModel.cs:19 · Level 2 · class (sealed form model)

• What it is: the one-field form model behind the inline "add category item" form that ConferenceCategoryItemsPanel hosts. It carries a single Name property and the rules that property must satisfy.
• Depends on: CategoryItemDTO for the length cap (.../Pages/ConferenceCategory/ConferenceCategoryItemEditModel.cs:2,30); System.ComponentModel.DataAnnotations. It is consumed through ModelValidation and DataAnnotationsModelValidator.
• Concept introduced, the page form model as the single declaration of a form's rules. Every editable surface in this unit follows the same three-part arrangement, and this is the smallest instance of it, so it is the clearest place to read the mechanism.
  1. The rules live on a plain C# model, as DataAnnotations. [Required(ErrorMessage = NameRequiredKey)] and [MaxLength(CategoryItemDTO.NameMaxLength, ErrorMessage = "Validation.NameMaxLength")] sit on the Name property (lines 29-31). The cap is not a literal: it reads CategoryItemDTO.NameMaxLength, which is 500 and is declared once on the DTO (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Categories/CategoryItemDTO.cs:16), so the client cap and the contract cap cannot drift.
  2. The markup bridges to those rules instead of restating them. The panel builds one delegate with ModelValidation.For(_model, new DataAnnotationsModelValidator(L)) (.../Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:57) and hands it to the field's Validation parameter (.../Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor:30). MudBlazor invokes that delegate with (model, member path) and the model's own annotations decide the outcome (MMCA.Common/Source/Presentation/MMCA.Common.UI/Validation/ModelValidation.cs:43-49), so one delegate serves every field on the form and no rule is written twice.
  3. Every ErrorMessage is a resource key, not a sentence. NameRequiredKey is the constant "Validation.NameRequired" (line 26), and the localizing validator resolves the key at render time (ADR-027). The constant exists so the model's [Required] rule and the field's RequiredError affordance quote the same key rather than two copies of one string literal (lines 21-25). [Rubric §24, Forms, Validation & UX Safety] (assesses whether a form's rules are declared once and enforced before submit): the annotation is the only declaration, and the field renders its asterisk and message from it. [Rubric §15, Best Practices & Code Quality] (assesses whether a change has one landing site): raising the item-name cap is a one-line DTO edit that the model, the input's MaxLength, and the character counter all inherit. [Rubric §27, Internationalization]: the message is a key, so the wording is a resource concern rather than a code concern.
• Walkthrough
  • NameRequiredKey (line 26): the shared resource key described above.
  • Name (line 31): string initialized to string.Empty, so a fresh model binds cleanly to a text field, carrying the required and max-length rules (lines 29-30).
• Why it's built this way: there is no standalone item-creation page to mirror, so unlike its siblings this model has no abstract base and no ToNew (the doc comment says so explicitly, lines 6-18). The panel builds the CategoryItemDTO itself. The sort order is a plain numeric field with nothing to validate, so it stays on the panel rather than joining the model.
• Where it's used: held as the private _model of ConferenceCategoryItemsPanel (.../Pages/ConferenceCategory/ConferenceCategoryItemsPanel.razor.cs:36), reset on every "add item" click (line 62) and read when the new item is posted (line 87).

QuestionFormModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Questions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Questions/QuestionFormModel.cs:24 · Level 2 · class (abstract base form model)

• What it is: the editable question fields that the create page and the detail page's inline editor have in common: the question text with its rules, the display order, and the required flag. It is abstract, and the two concrete models derive from it.
• Depends on: QuestionDTO for the text cap (lines 2,35); System.ComponentModel.DataAnnotations. Its subclasses are QuestionCreateModel and QuestionEditModel.
• Concept introduced, one shared model as the anti-drift device between a create form and an edit form. The form-model mechanism itself is introduced on ConferenceCategoryItemEditModel; what this type adds is the abstract base. Two pages edit a question: /questions/create and the inline editor on /questions/{Id}. Both bind the same QuestionFormFields component (.../Pages/Question/QuestionCreate.razor:23, .../Pages/Question/QuestionDetail.razor:31), and that component's Model parameter is typed as QuestionFormModel (.../Pages/Question/QuestionFormFields.razor:42). The consequence is structural rather than conventional: a question text the create page accepts is a question text the detail page accepts, because there is exactly one [MaxLength] and one [Required] in the codebase for that field, and neither page can add a rule the other lacks. [Rubric §24, Forms, Validation & UX Safety]: a create form and an edit form that disagree on a rule is a classic source of "it saved yesterday and will not save today"; the shared base removes the possibility. [Rubric §1, SOLID] (assesses whether shared behavior is factored to one owner): the base holds what is common, the subclasses hold only what differs (what a post looks like). [Rubric §15, Best Practices & Code Quality]: QuestionDTO.QuestionTextMaxLength is 1000 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Questions/QuestionDTO.cs:17) and is referenced, never copied.
• Walkthrough
  • QuestionTextRequiredKey (line 31): the resource key "Validation.QuestionTextRequired", quoted both by the model's [Required] (line 34) and by the field's RequiredError (.../Pages/Question/QuestionFormFields.razor:17).
  • QuestionText (line 36): required, capped at QuestionDTO.QuestionTextMaxLength (line 35), rendered as a two-line text field whose Counter reads the same constant (.../Pages/Question/QuestionFormFields.razor:18-19).
  • Sort (line 39) and IsRequired (line 42): plain properties. The doc comment records why they live here at all (lines 18-22): DataAnnotations cannot express either rule, but keeping them on the model lets one object carry the whole form instead of a parallel set of loose page fields.
• Why it's built this way: the alternative (each page owning its own fields plus its own copy of the rules) is how the Conference pages were written before the shared field block existed, and it makes every rule change a two-file edit with no compiler help. Abstract rather than concrete because there is no scenario that binds "just the shared part": every use is a create or an edit.
• Where it's used: as the base of QuestionCreateModel and QuestionEditModel, and as the declared parameter type of the shared QuestionFormFields component (.../Pages/Question/QuestionFormFields.razor:42).

ConferenceCategoryFormModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Categories/ConferenceCategoryFormModel.cs:24 · Level 3 · class (abstract base form model)

• What it is: the editable conference-category fields shared by the create page and the detail page's inline editor: the title with its rules, the display order, and the optional type discriminator.
• Depends on: ConferenceCategoryDTO for the title cap (lines 2,35). Its subclasses are ConferenceCategoryCreateModel and ConferenceCategoryEditModel.
• Concept introduced: none new. This is the category-side twin of QuestionFormModel; read that section for the shared-base rationale, and ConferenceCategoryItemEditModel for the annotations-to-MudBlazor bridge. [Rubric §24, Forms, Validation & UX Safety] and [Rubric §15, Best Practices & Code Quality] apply for the same reasons.
• Walkthrough
  • CategoryTitleRequiredKey (line 31): the resource key "Validation.TitleRequired", quoted by the model's [Required] (line 34) and by the field's RequiredError (.../Pages/ConferenceCategory/ConferenceCategoryFormFields.razor:18).
  • CategoryTitle (line 36): required and capped at ConferenceCategoryDTO.TitleMaxLength, which is 255 (MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.Shared/Categories/ConferenceCategoryDTO.cs:17). The name is deliberate and the doc comment says why (line 33): a property named Title on a page class would read as the page title, and the pages already expose a localized Title.
  • Sort (line 39) and Type (line 42): plain properties with no annotation. Type is nullable and optional (for example "session" or "speaker"); its input caps itself at ConferenceCategoryDTO.TypeMaxLength in markup (.../Pages/ConferenceCategory/ConferenceCategoryFormFields.razor:23) rather than through an annotation.
• Why it's built this way: the same anti-drift argument as QuestionFormModel. The shared ConferenceCategoryFormFields component takes this type as its Model (.../Pages/ConferenceCategory/ConferenceCategoryFormFields.razor:28), so both consuming pages render the identical field block and neither can add a rule the other lacks.
• Where it's used: base of ConferenceCategoryCreateModel and ConferenceCategoryEditModel; bound by ConferenceCategoryCreate (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:23) and ConferenceCategoryDetail (.../Pages/ConferenceCategory/ConferenceCategoryDetail.razor:34).

QuestionCreateModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Questions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Questions/QuestionCreateModel.cs:11 · Level 3 · class (sealed form model)

• What it is: the form model for the organizer question-creation page. It adds the two fields that are chosen once at creation and never edited afterwards (the target entity and the input type) and knows how to turn itself into the QuestionDTO the create posts.
• Depends on: QuestionFormModel (base), QuestionDTO, and the QuestionIdentifierType alias (ADR-048).
• Concept introduced, the model owns the shape of the post. The page validates and calls the service; it does not build the DTO field by field. ToNew (lines 24-33) is the one place that maps form state onto the wire contract, which keeps the page's save handler down to "validate, map, post, navigate". [Rubric §18, UI Architecture & Component Design] (assesses whether logic sits outside the component where it can be reasoned about alone): mapping is a pure function of the model, testable without a renderer. [Rubric §9, API & Contract Design] (assesses how the client fills the contract): the create post is a full QuestionDTO, not a partial patch.
• Walkthrough
  • QuestionEntity (line 14) defaults to "Session" and QuestionType (line 17) defaults to "Rating", the common combination, so the organizer's most frequent case needs no interaction. Both render as MudSelect pickers only on the create leg, gated by the field block's ShowTargetPickers switch (.../Pages/Question/QuestionFormFields.razor:21-35).
  • ToNew(QuestionIdentifierType id) (lines 24-33) projects the model plus a caller-supplied id onto a QuestionDTO. Taking the id as a parameter rather than minting one keeps the model free of the identifier policy that QuestionCreate applies.
• Why it's built this way: an entity/type pair chosen at creation determines how every answer to the question will be captured, so it belongs to the create form only; putting it on the create model rather than the shared base is what makes QuestionEditModel structurally unable to change it.
• Where it's used: the _model field of QuestionCreate (.../Pages/Question/QuestionCreate.razor.cs:39), read at the post (.../Pages/Question/QuestionCreate.razor.cs:68).

QuestionEditModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Questions · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Questions/QuestionEditModel.cs:12 · Level 3 · class (sealed form model)

• What it is: the form model for the inline editor on the question detail page. It loads itself from the question that was fetched and projects itself back onto an updated QuestionDTO.
• Depends on: QuestionFormModel (base) and QuestionDTO.
• Concept introduced, the edit buffer plus the concurrency round trip. Two mechanisms are worth reading closely.
  1. The loaded record is never mutated. LoadFrom (lines 16-23) copies the three editable values off the fetched DTO into the model, and the page renders from the DTO throughout. Cancelling an edit therefore needs no undo: the model is simply abandoned, and what is on screen is still exactly what the server last returned. [Rubric §19, State Management & Data Flow] (assesses where mutable state lives and how long it lives): the edit buffer is a separate object with a scope of one editing session.
  2. ToUpdated round-trips what it must not change. The new DTO (lines 34-44) carries the edited QuestionText, Sort, and IsRequired over the loaded record's Id, RowVersion, QuestionEntity, and QuestionType. RowVersion is the client half of the optimistic-concurrency contract in ADR-035: a stale editor loses the write instead of silently overwriting a newer one. QuestionEntity and QuestionType are re-sent unchanged because the update contract is a full replacement, not a patch. [Rubric §8, Data Architecture] (assesses how concurrent writes are reconciled and how immutable fields are protected). Both methods open with ArgumentNullException.ThrowIfNull (lines 18,33), so a null argument fails at the call rather than as a NullReferenceException several lines later. [Rubric §15, Best Practices & Code Quality].
• Walkthrough
  • LoadFrom(QuestionDTO question) (lines 16-23): copies QuestionText, Sort, IsRequired.
  • ToUpdated(QuestionDTO question) (lines 31-45): builds the replacement DTO as described above.
• Why it's built this way: the class doc records the reasoning for the omission (lines 5-11). Retargeting a question or changing how it is answered would invalidate the answers already collected, so both fields are displayed but never edited; leaving them off the model makes that a compile-time fact rather than a markup discipline.
• Where it's used: the _model field of QuestionDetail (.../Pages/Question/QuestionDetail.razor.cs:49), loaded at StartEditing (line 105) and read at the save (line 133).

ConferenceCategoryCreateModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Categories/ConferenceCategoryCreateModel.cs:10 · Level 4 · class (sealed form model)

• What it is: the form model for the category-creation page. It adds nothing to ConferenceCategoryFormModel except the shape of the post.
• Depends on: ConferenceCategoryFormModel (base) and ConferenceCategoryDTO.
• Concept introduced: none new. ToNew is the mapping-on-the-model idea introduced on QuestionCreateModel.
• Walkthrough
  • ToNew() (lines 17-24) builds a ConferenceCategoryDTO with Id = default (line 20) plus the three entered values. Note the contrast with QuestionCreateModel.ToNew, which takes an id: a category leaves identity assignment entirely to the server, and the page navigates on the id read back from the response. [Rubric §8, Data Architecture] (assesses a deliberate identity strategy): the two entities in this unit make opposite choices, and each is visible right here in the mapping method.
• Why it's built this way: keeping the create model empty apart from ToNew is the point. Every field a reader could look for is on the shared base, which is the same base the detail page's editor binds, so the two forms cannot drift apart (doc comment, lines 5-9).
• Where it's used: the _model field of ConferenceCategoryCreate (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor.cs:39), read at the post (line 67).

ConferenceCategoryEditModel

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Categories/ConferenceCategoryEditModel.cs:11 · Level 4 · class (sealed form model)

• What it is: the edit buffer for the inline category editor on the detail page: it loads from the fetched category and projects back onto an updated DTO.
• Depends on: ConferenceCategoryFormModel (base) and ConferenceCategoryDTO.
• Concept introduced: none new. The load-into-buffer and RowVersion round-trip mechanics are taught on QuestionEditModel. [Rubric §8, Data Architecture]: ToUpdated carries RowVersion = category.RowVersion (line 37), so the category edit participates in optimistic concurrency (ADR-035). Worth contrasting with the item edits in ConferenceCategoryItemsPanel, which carry no token.
• Walkthrough
  • LoadFrom(ConferenceCategoryDTO category) (lines 15-22): null-guards, then copies Title into CategoryTitle, plus Sort and Type.
  • ToUpdated(ConferenceCategoryDTO category) (lines 30-42): null-guards, then rebuilds the DTO with the loaded Id and RowVersion and the edited title, sort, and type.
• Why it's built this way: the class doc records the deliberate omission (lines 5-10): the category items are absent from this model because they are edited in their own panel, not in this form. That is what lets the page's save path be a single UpdateAsync with no child reconciliation.
• Where it's used: the _model field of ConferenceCategoryDetail (.../Pages/ConferenceCategory/ConferenceCategoryDetail.razor.cs:53), loaded at StartEditing (line 108) and read at the save (line 129).

ConferenceCategoryCreate

MMCA.ADC.Conference.UI · MMCA.ADC.Conference.UI.Pages.Categories · MMCA.ADC/Source/Modules/Conference/MMCA.ADC.Conference.UI/Pages/Categories/ConferenceCategoryCreate.razor.cs:11 · Level 5 · class (Blazor code-behind)

• What it is: the organizer's category-creation form. It renders the shared field block over a ConferenceCategoryCreateModel, posts one ConferenceCategoryDTO through the UI service, and redirects to the detail page for the record it just made.
• Depends on: IConferenceCategoryUIService (line 13), IToastService (line 15), ConferenceRoutePaths (lines 28,76,88), ErrorMessages (line 60), ModelValidation and DataAnnotationsModelValidator (line 33). Externals: Blazor ([Inject], NavigationManager, OnInitialized), MudBlazor (MudForm, BreadcrumbItem, Icons.Material.Filled.Home), the shared UnsavedChangesGuard and ErrorSummary components from MMCA.Common.UI, and the IStringLocalizer<ConferenceCategoryCreate> the template injects as L (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:6).
• Concept introduced, the create-page shape and its three safety rails. This is the smallest create form in the group, which makes it the clearest place to read the shape the others repeat.
  1. Validate before you mutate. CreateCategoryAsync calls await _form.ValidateAsync() and returns with a warning toast when !_form.IsValid (lines 57-62), before any service call. The server validates again; this pass exists to keep a round trip off the wire and to put the message next to the field. Errors are then collapsed and localized once by the shared ErrorSummary (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:34), whose comment (lines 28-33) records why de-duplication is needed: MudBlazor runs a field's annotations through For as well as through the shared delegate, so one empty field can report the same rule twice, once localized and once as the bare key. [Rubric §24, Forms, Validation & UX Safety].
  2. Dirty tracking that cannot block its own redirect. Every field change raises MarkDirty() (line 48, wired through the field block's OnFieldChanged, .../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:23-25) and the markup mounts <UnsavedChangesGuard IsDirty="_isDirty" IsDirtyAccessor="() => _isDirty" /> (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:10). The accessor is the load-bearing half: the guard prefers the live accessor over the parameter snapshot, because clearing the flag and calling NavigateTo without an intervening render would otherwise still prompt. The page clears _isDirty on the success path before navigating, with the reason written on the line (line 74).
  3. Cancel on disposal. A private CancellationTokenSource (line 17) is passed into the service call (line 67) and cancelled through a full Dispose(bool) pattern (lines 90-112), with OperationCanceledException caught and ignored as the expected teardown or InteractiveAuto render-mode transition outcome (lines 78-81, ADR-056). [Rubric §23, Front-End Performance & Rendering]: an abandoned form does not keep a response alive for a component that no longer exists. [Rubric §11, Security] (assesses authorization at the boundary the user actually reaches): the route carries @attribute [Authorize(Roles = "Organizer")] (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:2). [Rubric §27, Internationalization]: every label, breadcrumb, and toast reads through L.
• Walkthrough
  • OnInitialized (lines 22-34) builds the Home / Categories / Create breadcrumb trail (lines 25-30) and then builds the validation delegate once (line 33), so the bridge is created per page instance rather than per render.
  • The form state is three fields: the _model (line 39), the _validate delegate (line 43), and the captured MudForm (line 45). Compare the pre-extraction shape, where each editable value was its own private field on the page.
  • CreateCategoryAsync (lines 50-86): null-guard the form (lines 52-55), validate, set IsSaving (line 64), post _model.ToNew() (line 67), fail into a toast when the result carries no value (lines 68-72), clear the dirty flag (line 74), toast success (line 75), and redirect to ConferenceRoutePaths.ConferenceCategoryDetails(newCategory.Id) using the id the server returned (line 76). The finally always clears IsSaving (lines 82-85), so a failed save leaves an enabled button rather than a stuck spinner.
  • NavigateToList (line 88) is the cancel action, routed through ConferenceRoutePaths rather than a literal. [Rubric §25, Navigation & Information Architecture]: every route in the module is a named constant in one file.
• Why it's built this way: one create shape repeated per entity keeps the organizer's mental model constant (fill, validate, save, land on the new record) while each page varies only in the fields it collects, and since the extraction of ConferenceCategoryFormModel it varies in even less than that.
• Where it's used: the /conferencecategories/create route (.../Pages/ConferenceCategory/ConferenceCategoryCreate.razor:1-2), reached from ConferenceCategoryList's create button; on success it hands off to ConferenceCategoryDetail.