CRITICAL story-contact-detail-edit-screen-peer-mentor-001 5 pts
5
Story Points
Critical
Priority
Contact Detail & Edit Screen
Feature

User Story

As a Peer Mentor (Likeperson)
I want to open a contact's detail screen and see their full profile including assignment status, chapter affiliations, and activity history
So that I can quickly assess a peer mentor's current engagement and workload before making decisions about new assignments

Audience Summaries

This critical story establishes the foundational contact intelligence layer that coordinators depend on to make accurate, timely assignment decisions. Without a comprehensive single-screen view, coordinators are forced to navigate multiple systems to piece together a contact's assignment status, chapter affiliations, and recent activity — a workflow that wastes time and introduces errors into peer mentor matching. By delivering a rich contact detail screen with real-time assignment status, multi-chapter affiliation display, and scrollable activity history, this story directly reduces the time coordinators spend per contact review and improves the quality of every assignment decision they make. The inclusion of read receipt logging also introduces accountability and audit capability, which supports compliance and program oversight requirements.

As the dependency anchor for downstream contact management stories, delivering this story on time is critical to overall program delivery velocity and coordinator adoption of the platform.

This is a critical-priority story and a foundational dependency for several downstream contact management features, making it a high-scheduling priority in the sprint plan. Delivery complexity is medium-high: the screen must aggregate data from multiple sources (contact profile, assignment status, chapter affiliations, activity history, encrypted sensitive fields), each with its own loading and error state. The sensitive field reveal flow requires a warning dialog implementation with explicit user acknowledgement before decryption — this needs coordination with the security or data privacy stakeholder to validate the UX pattern and confirm which fields are classified as sensitive. The read receipt service integration requires a backend endpoint or event log to be available or mocked for testing.

Acceptance criteria are well-defined and testable, but the 500ms load time criterion requires performance testing against realistic data payloads. UAT should include coordinators validating the activity history layout and the paused-status banner visibility. No external integrations beyond the read receipt service are required. Blocking risk is low if the read receipt service is available; medium if it requires new backend work.

The contact detail screen must aggregate data from at minimum four sources: contact profile repository, assignment status service (returning active/inactive/paused enum with optional return date), chapter affiliation service (returning a list of chapter memberships), and activity registration repository (last 20 records with date, type, duration). The screen must handle all loading, error, and empty states independently per section. Multi-chapter affiliation chips must be horizontally scrollable and should handle overflow gracefully for contacts with many affiliations. The paused-status banner is conditionally rendered based on assignment status and must display the expected return date when available — null-safe rendering required.

Sensitive field reveal requires a modal confirmation dialog before calling a decryption service; the field should render as a masked placeholder until confirmed. The read receipt service call must fire on successful screen load (not on error states) and should be non-blocking — use fire-and-forget with silent error logging. Performance constraint: full screen render within 500ms per acceptance criteria — consider parallel repository calls and skeleton loading states. Activity history list should be paginated or virtually rendered if the dataset grows.

No schema migrations required if existing tables are in place.

Acceptance Criteria

  • Given I am a coordinator on the contact list screen, When I tap any contact card, Then the contact detail screen opens within 500ms showing the contact's name, role badge, and assignment status indicator
  • Given I am on the contact detail screen, When the contact belongs to multiple chapters, Then multi-chapter affiliation chips are displayed horizontally scrollable below the profile header
  • Given I am on the contact detail screen, When I scroll to the activity history section, Then a list of the last 20 activity registrations is displayed with date, type, and duration
  • Given the contact has encrypted personal fields, When I tap a field marked as sensitive, Then a warning dialog appears before revealing the decrypted content
  • Given I have opened a contact detail record, When the screen loads successfully, Then the read receipt service records my user ID and timestamp against this contact's record
  • Given I am on the contact detail screen, When the assignment status is 'paused', Then a pause status banner is displayed prominently at the top of the screen with the expected return date if available

Business Value

Coordinators need a single, comprehensive view of each contact to manage assignments and workload effectively. Without a rich detail screen, coordinators must navigate multiple screens or external systems to gather basic contact information, leading to inefficiency and errors in assignment decisions. This story directly reduces coordinator time-per-contact-review and improves the quality of peer mentor matching by surfacing all relevant context in one place.