urban-recall

As an Owner-Clinician, I need to import patient lists, last visit dates, and recall types to manage recalls effectively. Implementation contract: - Outcome: Backend Sync Import - Requirement sources: - src-28d27b3b8ff3a86f - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - Owned behavior: - As an Owner-Clinician, I need to import patient lists, last visit dates, and recall types to manage recalls effectively. - data import - Handle one-way sync/import of patient list, last visit, and recall type. - Interfaces: - API for data import - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide backend.sync.import: Handle one-way sync/import of patient list, last visit, and recall type. - State transitions: - data imported - Failure and safety behavior: - import failure - data inconsistency Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.sync.import implements Handle one-way sync/import of patient list, last visit, and recall type. and is verified through its declared interfaces.

As an Owner-Clinician, I need to set rules-based recall cadences per procedure to automate reminders. Implementation contract: - Outcome: Backend Rules Recall - Requirement sources: - src-3ed64a5dd48a90e3 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - Owned behavior: - As an Owner-Clinician, I need to set rules-based recall cadences per procedure to automate reminders. - recall rule application - Implement rules-based recall cadence per procedure. - Interfaces: - API for recall rules - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide backend.rules.recall: Implement rules-based recall cadence per procedure. - State transitions: - rules applied - Failure and safety behavior: - rule conflict - application error Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.rules.recall implements Implement rules-based recall cadence per procedure. and is verified through its declared interfaces.

As a Patient/Client, I should be able to receive SMS reminders and confirm or reschedule appointments with one tap. Implementation contract: - Outcome: Backend SMS Two-Way - Requirement sources: - src-457966a7180931db - src-2a9d317a4e85d9ac - src-e6ca005d08a6899b - src-2ed0015a1db8ea53 - src-98d366c228d26859 - src-81efa54478bb459b - Owned behavior: - As a Patient/Client, I should be able to receive SMS reminders and confirm or reschedule appointments with one tap. - SMS confirmation - appointment rescheduling - Two-way SMS Confirmation (Patient/Client) — trigger: Receive SMS reminder; inputs: SMS message; outcomes: Appointment confirmed or rescheduled - Manage two-way SMS communication with patients. - Interfaces: - SMS Gateway - Input contract for Two-way SMS Confirmation: SMS message - Provide backend.sms.two.way: Manage two-way SMS communication with patients. - State transitions: - appointment confirmed - appointment rescheduled - When Receive SMS reminder: Appointment status updated - Failure and safety behavior: - SMS delivery failure - confirmation error - If Two-way SMS Confirmation cannot complete: Confirmation failed. - Validate provider configuration and credentials, handle provider errors explicitly, and never report an unconfirmed external action as successful. - Web research: - SMS Gateway API documentation - RESEARCH BLOCKER: No official or provider-primary documentation or direct provider selection—external SMS gateway/protocol/contract is unresolved. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - When Receive SMS reminder, Patient/Client produces Appointment confirmed or rescheduled. - Two-way SMS Confirmation includes the required human touchpoint: SMS. - Capability backend.sms.two.way implements Manage two-way SMS communication with patients. and is verified through its declared interfaces.

As an Owner-Clinician, I should be able to initiate lapsed-patient reactivation campaigns and measure recovered bookings. Implementation contract: - Outcome: Backend Campaign Reactivate - Requirement sources: - src-16d04c47f32e28c9 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-d554c80a3e81b609 - Owned behavior: - As an Owner-Clinician, I should be able to initiate lapsed-patient reactivation campaigns and measure recovered bookings. - campaign initiation - booking measurement - Reactivate Lapsed Patients (Owner-Clinician) — trigger: Identify lapsed patients; inputs: Patient history; outcomes: Reactivation campaigns initiated - Reactivate lapsed patients through campaigns. - Interfaces: - API for campaign management - Input contract for Reactivate Lapsed Patients: Patient history - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide backend.campaign.reactivate: Reactivate lapsed patients through campaigns. - State transitions: - campaign initiated - When Identify lapsed patients: Campaign status updated - Failure and safety behavior: - campaign initiation failure - If Reactivate Lapsed Patients cannot complete: Campaign initiation failed. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - When Identify lapsed patients, Owner-Clinician produces Reactivation campaigns initiated. - Reactivate Lapsed Patients includes the required human touchpoint: Dashboard. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.campaign.reactivate implements Reactivate lapsed patients through campaigns. and is verified through its declared interfaces.

As an Owner-Clinician, I should be able to follow up on no-shows and fill waitlists automatically. Implementation contract: - Outcome: Backend Follow-up No-show - Requirement sources: - src-457679cbccd1ebef - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-035ba791512f32e0 - Owned behavior: - As an Owner-Clinician, I should be able to follow up on no-shows and fill waitlists automatically. - follow-up initiation - waitlist management - Follow-up on No-shows (Owner-Clinician) — trigger: No-show detected; inputs: Appointment data; outcomes: Follow-up initiated, Waitlist filled - Follow-up on no-shows and manage waitlist. - Interfaces: - API for follow-up management - Input contract for Follow-up on No-shows: Appointment data - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide backend.followup.noshow: Follow-up on no-shows and manage waitlist. - State transitions: - follow-up initiated - When No-show detected: Appointment status updated - Failure and safety behavior: - follow-up failure - If Follow-up on No-shows cannot complete: Follow-up failed. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - When No-show detected, Owner-Clinician produces Follow-up initiated. - When No-show detected, Owner-Clinician produces Waitlist filled. - Follow-up on No-shows includes the required human touchpoint: Dashboard. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.followup.noshow implements Follow-up on no-shows and manage waitlist. and is verified through its declared interfaces.

As an AI Agent, I should be able to text lapsed patients, handle replies, and book appointments into open slots. Implementation contract: - Outcome: AI Outreach Booking - Requirement sources: - src-c22a8c0ba7c74c41 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-16942914262422ca - src-710eced9e64925f6 - src-829fd9667ca0ae5a - src-0b92c3a676820abb - Owned behavior: - As an AI Agent, I should be able to text lapsed patients, handle replies, and book appointments into open slots. - outreach automation - booking automation - AI Outreach and Booking (AI Agent) — trigger: Lapsed patient detected or recall opportunity identified; inputs: Lapsed patient list, Open appointment slots, Patient contact preferences, Treatment type; outcomes: Personalized outreach sent, Replies handled, Appointments booked, Propensity-to-book scored, Voice callback initiated for non-texters, Campaign copy generated, Revenue-at-risk estimated - AI-driven outreach and booking automation. - Interfaces: - AI Platform - Input contract for AI Outreach and Booking: Lapsed patient list, Open appointment slots, Patient contact preferences, Treatment type - External handoff for AI Outreach and Booking: Patient/Client - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide ai.outreach.booking: AI-driven outreach and booking automation. - State transitions: - outreach sent - appointments booked - When Lapsed patient detected or recall opportunity identified: Outreach log updated, Appointment status updated, Campaign metrics updated - Failure and safety behavior: - outreach failure - booking failure - If AI Outreach and Booking cannot complete: Outreach failed or booking not completed. - Validate AI inputs/outputs, define safety and provider-failure behavior, and make latency, cost, and result persistence observable where required. - Web research: - AI Platform API documentation - RESEARCH BLOCKER: No official or provider-primary documentation or external AI vendor/API/platform selection—integration contract is unresolved. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Personalized outreach sent. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Replies handled. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Appointments booked. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Propensity-to-book scored. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Voice callback initiated for non-texters. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Campaign copy generated. - When Lapsed patient detected or recall opportunity identified, AI Agent produces Revenue-at-risk estimated. - AI Outreach and Booking includes the required human touchpoint: Dashboard. - AI Outreach and Booking completes its external handoff to Patient/Client. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability ai.outreach.booking implements AI-driven outreach and booking automation. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Authentication page design and the task-owned sections below. Implementation contract: - Outcome: Implement Authentication page - Requirement sources: - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-0c0f9c34dee80a04 - Owned behavior: - Credential submission and session establishment - Error state display and dismissal - Loading state during authentication backend call - Successful authentication and redirect to Owner Dashboard - Interfaces: - auth_session - Consume identity.access.management through auth_session. - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - State transitions: - Unauthenticated to authenticated redirect - Successful authentication and redirect to Owner Dashboard - Use neutral loading, empty, anonymous, and error states instead of restoring prototype data. - Failure and safety behavior: - Display authentication errors - Never retain or restore hardcoded prototype data as the runtime fallback when live integration fails. - Prototype-to-live replacements: - Replace 'Primary login interface for Owner-Clinician access to Urban-Recall.' with auth_session. Successful authentication and redirect to Owner Dashboard Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - AuthenticationForm renders once on the Authentication page - Includes email and password input fields, submit button, and error display - Matches provided CSS design - Submits credentials to backend and handles responses - Restricted access to Owner-Clinician persona - Successful authentication and redirect to Owner Dashboard - The prototype value is absent from successful runtime rendering and from error fallbacks. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Owner Dashboard page design and the task-owned sections below. Implementation contract: - Outcome: Implement Owner Dashboard page - Requirement sources: - src-fccb8aa2994cbf75 - src-3ed64a5dd48a90e3 - src-28d27b3b8ff3a86f - src-40c2b68312c498d3 - src-5f1f3c1c1926176d - src-c6ddca603699819d - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - 4 additional source record(s) are retained in the structured implementation contract. - Owned behavior: - Send Recall Reminders - Display scheduled reminders and their status - Log and display failed deliveries; enable manual retry - Display ROI metrics - Export report - Display patient list with search and filter - Render static header with branding - Send Recall Reminders (Owner-Clinician) — trigger: Scheduled recall reminder; inputs: Recall schedule, Patient contact info; outcomes: Recall reminders sent - ROI Dashboard (Owner-Clinician) — trigger: Access dashboard; inputs: Appointment data, Revenue data; outcomes: ROI metrics displayed - Provide custom UI for managing recalls and reminders. - Send recall reminders to patients. - Display ROI metrics on the dashboard. - Interfaces: - backend.reminder.send - backend.rules.recall - backend.sync.import - backend.dashboard.roi - Input contract for Send Recall Reminders: Recall schedule, Patient contact info - External handoff for Send Recall Reminders: Patient/Client - Input contract for ROI Dashboard: Appointment data, Revenue data - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Provide frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Consume backend.sync.import: Handle one-way sync/import of patient list, last visit, and recall type. - Consume backend.rules.recall: Implement rules-based recall cadence per procedure. - Provide backend.reminder.send: Send recall reminders to patients. - Provide backend.dashboard.roi: Display ROI metrics on the dashboard. - State transitions: - Scheduled recall reminder trigger fires from the dashboard - Reminder delivery attempt fails - Load patient data from backend - When Scheduled recall reminder: Recall reminders sent - When Access dashboard: ROI metrics displayed - Failure and safety behavior: - Reminder not sent - Delivery failure - Dashboard access failed - Display error message if data fetch fails - If Send Recall Reminders cannot complete: Reminder not sent. - If ROI Dashboard cannot complete: Dashboard access failed. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - RecallReminderScheduler renders once on Owner Dashboard - Allows filtering, composing, scheduling, and viewing logs - Design matches provided CSS - Backend supports scheduling and sending reminders - The declared task-owned behavior is implemented and verified without relying on undeclared mocks or downstream behavior. - Owner Dashboard page renders once - PatientRecallList displays all patients - DashboardWelcomeBanner shows branding - When Scheduled recall reminder, Owner-Clinician produces Recall reminders sent. - Send Recall Reminders includes the required human touchpoint: Dashboard. - Send Recall Reminders completes its external handoff to Patient/Client. - When Access dashboard, Owner-Clinician produces ROI metrics displayed. - ROI Dashboard includes the required human touchpoint: Dashboard. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.sync.import implements Handle one-way sync/import of patient list, last visit, and recall type. and is verified through its declared interfaces. - Capability backend.rules.recall implements Implement rules-based recall cadence per procedure. and is verified through its declared interfaces. - Capability backend.reminder.send implements Send recall reminders to patients. and is verified through its declared interfaces. - Capability backend.dashboard.roi implements Display ROI metrics on the dashboard. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Owner Dashboard page design and the task-owned sections below. Implementation contract: - Outcome: Implement ReviewRequestManager section for Owner Dashboard - Requirement sources: - src-c904c0307fe63b75 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-d29e6efac27e0dcf - src-30e1e9d73335334d - Owned behavior: - Filter completed visits by time range and procedure type - Select patients for review request - Compose or select review request message - Send review requests - View sent request log - Track review completion - Request Reviews (Owner-Clinician) — trigger: Completed visit; inputs: Visit data; outcomes: Review request sent - Request reviews from patients after visits. - Interfaces: - backend.review.request - Input contract for Request Reviews: Visit data - External handoff for Request Reviews: Patient/Client - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Provide backend.review.request: Request reviews from patients after visits. - State transitions: - Review request sent - Review completion tracked - When Completed visit: Review request sent - Failure and safety behavior: - Review request failed - If Request Reviews cannot complete: Review request failed. Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - ReviewRequestManager renders on Owner Dashboard - Allows filtering of visits - Enables patient selection - Supports message composition - Sends review requests via backend - Updates sent request log - When Completed visit, Owner-Clinician produces Review request sent. - Request Reviews includes the required human touchpoint: Dashboard. - Request Reviews completes its external handoff to Patient/Client. - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.review.request implements Request reviews from patients after visits. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Owner Dashboard page design and the task-owned sections below. Implementation contract: - Outcome: Implement AIOutreachResultsViewer section for Owner Dashboard - Requirement sources: - src-c8b133c108066db6 - src-d90ebd0c8fcf5137 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-c22a8c0ba7c74c41 - src-16942914262422ca - src-710eced9e64925f6 - 2 additional source record(s) are retained in the structured implementation contract. - Owned behavior: - Display AI outreach campaign summaries and detailed logs - Filter outreach results by campaign, status, and date range - Provide detailed reply review and booking inspection panes - Enable retry controls for failed outreach - Interfaces: - AI Platform - SMS Gateway - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Consume ai.outreach.booking: AI-driven outreach and booking automation. - State transitions: - Outreach log updated - Appointment status updated - Failure and safety behavior: - Outreach failed or booking not completed Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - AIOutreachResultsViewer renders on Owner Dashboard - Campaign summaries and logs are displayed - Filtering, reply review, booking inspection, and retry actions are functional - Design matches provided CSS - Backend integration for data loading and retries is functional - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability ai.outreach.booking implements AI-driven outreach and booking automation. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Owner Dashboard page design and the task-owned sections below. Implementation contract: - Outcome: Implement LapsedPatientCampaignManager section - Requirement sources: - src-16d04c47f32e28c9 - src-c22a8c0ba7c74c41 - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-d554c80a3e81b609 - Owned behavior: - Reactivate Lapsed Patients - Interfaces: - backend.campaign.reactivate - ai.outreach.booking - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Consume backend.campaign.reactivate: Reactivate lapsed patients through campaigns. - State transitions: - Campaign status updated - Failure and safety behavior: - Campaign initiation failed Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - LapsedPatientCampaignManager section renders on Owner Dashboard - Displays lapsed patient cohorts and allows campaign customization - AI outreach toggle functions correctly - Campaign progress updates based on backend data - Design matches provided CSS - Section is accessible to Owner-Clinicians only - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.campaign.reactivate implements Reactivate lapsed patients through campaigns. and is verified through its declared interfaces.

As a Frontend Developer, implement the approved Owner Dashboard page design and the task-owned sections below. Implementation contract: - Outcome: Implement NoShowFollowUpManager section on Owner Dashboard - Requirement sources: - src-457679cbccd1ebef - src-457966a7180931db - src-2faa74adf0b7ab24 - src-b829d530dd3e86ea - src-59e828c14315b253 - src-ac26782d59cd7408 - src-4d9dfc0d25001977 - src-7dcf134a750c9281 - src-37b05fd75b7106a2 - src-2a9d317a4e85d9ac - src-e6ca005d08a6899b - src-2ed0015a1db8ea53 - 3 additional source record(s) are retained in the structured implementation contract. - Owned behavior: - Display no-show queue - Send follow-up SMS - Trigger waitlist fill - Interfaces: - backend.followup.noshow - backend.sms.two.way - Consume identity.access.management: Manage authentication and session access for Owner-Clinician. - Consume frontend.ui.presentation: Provide custom UI for managing recalls and reminders. - Consume backend.sms.two.way: Manage two-way SMS communication with patients. - Consume backend.followup.noshow: Follow-up on no-shows and manage waitlist. - State transitions: - No-show status updated - SMS sent confirmation - Failure and safety behavior: - Follow-up failed - SMS dispatch failed Acceptance criteria: - The task-owned behavior is implemented and verified without undeclared mocks or downstream assumptions. - NoShowFollowUpManager renders on Owner Dashboard - Queue displays no-shows - SMS and waitlist functionalities integrate with backend - Access restricted to Owner-Clinician - Capability identity.access.management implements Manage authentication and session access for Owner-Clinician. and is verified through its declared interfaces. - Capability frontend.ui.presentation implements Provide custom UI for managing recalls and reminders. and is verified through its declared interfaces. - Capability backend.sms.two.way implements Manage two-way SMS communication with patients. and is verified through its declared interfaces. - Capability backend.followup.noshow implements Follow-up on no-shows and manage waitlist. and is verified through its declared interfaces.