Missing operational features and suggested product improvements

Verification responses now expose manual-review labels, next actions, retry/resubmit guidance, evidence requirements, and retention notices, user-facing copy no longer claims automated AI/biometric approval, operations can assign review ownership, and reviewers have a configured cleanup job for expired terminal evidence files. Future work can add provider-backed identity checks if product direction requires them.

The admin dashboard now supports multi-queue review operations, queue filters, status controls, reviewer notes, assignments, notifications, audit history filters, operational status, runbooks, shift handoff exports, local history, reviewer-only team archives, retention labels, combined exports, expired-archive pruning, configurable retention windows, team-owned playbook destinations, runbook owners, handoff cadence metadata, and queue-scoped playbook destination controls. Future work can add deeper owner assignment workflows and destination permission administration.

Users can submit moderation reports, reviewers can triage open/reviewing/escalated queues, lifecycle actions require notes, write audit logs, notify reporters, preserve escalated reports as a distinct senior-review status, block reported accounts from contacting reporters when resolving safety cases, and flag, hide, or restore reported messages with user-facing redaction metadata. Future work can add richer safety evidence bundles and senior-review assignment queues.

Users can request account exports and deletion workflows, operators can advance pending and processing requests from the admin queue, users see lifecycle status, next actions, operator notes, retained-record explanations for safety/legal exceptions, completed account export requests provide generated JSON downloads with profile data, request history, and retention notices, Settings shows a formal retention-policy report with active request counts, completed deletions, retained-record exceptions, and policy-specific deletion workflow guidance, and deletion requests now include operator-guided automation metadata for eligible record targets, hold checks, completion notes, and operator-confirmed completion details.

Email notifications are queued or suppressed in the database with centralized template subjects, status labels, next actions, provider-readiness metadata, user-facing delivery history, admin recovery controls for failed or suppressed emails, provider send calls for newly queued messages and admin retries, provider message IDs, safe provider failure capture, provider attempt metadata, authenticated provider webhooks, bounce/failure/suppression classification, webhook audit history, provider-driven unsubscribe preference updates, user-facing resubscribe guidance, and a secret-protected service-role worker for scheduled queued delivery. Future work can add richer provider template rendering and delivery analytics.

The dashboard notification popover now honors in-app preferences, separates persisted alerts from derived dashboard tasks, supports per-notification read/dismiss controls, and includes a bulk mark-all-read catch-up action. Future work can add richer notification history, snoozing, and category-specific inbox views.

Billing now presents Kindred Path as an included service with no checkout, invoices, renewal, customer portal, or subscription-management action required. Future work should only add payment operations if the product direction changes.

Document signing now records provider request IDs, recipient metadata, signed-copy storage paths, declined/voided/completed notifications, formatted signing timelines, and provider-readiness next actions. Future work can add unauthenticated provider webhook verification, direct provider send calls, and automated signed file ingestion.

Users can create, revoke, and share expiring provider invitation links, invited providers can sign in with the invited email to accept or decline scoped access, and operations can review, expire, revoke, audit, and notify members about pending provider invites. Future work should add provider onboarding, scoped collaborator dashboards, permission enforcement across workflows, and collaborator activity audit logs.

External app connections now return structured sync metadata including sync_status_label, next_action, connection_method, provider_ready, and beta_notice. Manual tracking remains the primary workflow with CSV import as a fallback. Future work can add OAuth flows, token refresh, scheduled sync, and per-source data mapping once API access is available from each provider.

CSV import now returns validation summaries, mapped column lists, partial row errors, duplicate/conflict counts, duplicate handling choices, safer replacement confirmation, and rollback guidance. Future work can add interactive column mapping and downloadable import manifests.

Discovery now applies saved match preferences when request filters are omitted, including role, screening, verification, same-region location radius, timeline, contact preference, and goals. Match preference responses include saved-filter summaries and next actions, and discovery profiles include compatibility summaries. Future work can add richer UI management controls and declined-match reconsideration flows.

Messages, read receipts, and blocking checks now include centralized conversation safety metadata, sensitive-sharing and attachment guidance, user-facing report/block controls, and blocked-conversation send pausing. Future work can add conversation archiving, richer workflow system messages, provider conversations, and deeper case-management assignment.

Profile onboarding and updates now include centralized completion scoring, profile completion checklist tasks, next recommended account action metadata, and a settings overview for profile, avatar, visibility, verification, privacy, and account-control guidance. Future work can add direct email/password change flows and account deactivation.

The document hub supports templates, uploads, previews, lifecycle states, review actions, centralized workspace tags, retention guidance, activity timelines, user-facing search/status filtering, sharing permission summaries, expiration guidance, required role checklists, version history, and redaction guidance. Future work can add direct collaborator permission editing and automated version snapshots when files are replaced.

The help page now includes a support/contact form, categorized support requests, safety escalation routing, professional-resource links by topic, status tracking, staff responses, and lifecycle next actions. Operations can assign, request follow-up, resolve, or close tickets from the admin queue with audit logs and user notifications. Future work can add multi-message response threads and SLA reporting.

The health endpoint now returns structured ok/degraded status with required Supabase configuration checks and optional AI chat configuration, and the admin dashboard shows an operational status panel. Future work can add live dependency pings, uptime monitoring, structured error logging, and alerts for failed jobs or webhooks.

The app now has consent record persistence, user-facing compliance overview metadata, retention policy summaries, audit-log visibility, sensitive upload warnings, and role-specific workflow disclaimers. Future work can add dedicated settings UI controls, policy-version migration prompts, and richer retention reporting.

Journey steps now include centralized next-action guidance, due/reminder labels, provider-required flags, dashboard task explanations, and journey UI milestone context. Future work can add deeper automatic completion from workflow events, provider assignment, and scheduled reminder delivery.

The README now includes a full API overview, environment variable table, operator runbooks for verification, moderation, privacy, document signing, provider invitations, email recovery, and compliance review, and notes on the external app integration model. Test coverage now includes external-apps helpers, admin role checks, and contact-preference constants. Future work can add integration tests, RLS policy tests, and seed data scripts.

Support requests now support multi-turn message threads between users and staff. Users can view the thread for any request, add follow-up messages when a request is not closed, and see color-coded staff replies inline. A closed ticket blocks new messages, and a resolved ticket reopens automatically when the user adds a follow-up. Thread metadata includes message count, staff reply indicator, last message timestamp, and a contextual status note. Future work can add staff-side thread management, SLA timestamps, and notification triggers on staff replies.

The operations support queue now loads recent thread messages, staff reply state, message counts, last message timestamps, and SLA labels for active support requests. Staff responses recorded through operations actions are also written into the support request message thread, keeping user-facing support history and operator actions aligned. SLA metadata distinguishes on-track, due-soon, overdue, paused, and closed tickets based on priority and latest response timing. Future work can add dedicated staff reply composition, SLA analytics, and assignment dashboards.

Support operations now separate internal audit notes from user-facing staff replies, persist dedicated staff replies into the support thread, and use the reply text for requester notifications when provided. The admin support queue also shows active ticket assignment ownership plus SLA summary cards for total, assigned, unassigned, overdue, due-soon, and waiting-on-user tickets. Future work can add SLA trend analytics.

Support operations now group assigned tickets by reviewer and summarize each reviewer workload by active ticket count, overdue tickets, due-soon tickets, and tickets waiting on the requester. Reviewer workload cards appear above the support queue so operators can spot uneven assignment and SLA pressure before acting on individual tickets. Future work can add historical SLA trend analytics.

Support operations now let reviewers filter the active support queue by all reviewers, unassigned tickets, or an individual reviewer from the workload dashboard. The filtered ticket list helps operators rebalance ownership, focus on one reviewer's SLA pressure, and find unassigned support requests without losing the overall workload summary.

Support operations now summarize recent support volume and SLA pressure across a seven-day trend view. The admin queue shows daily counts for total active tickets, overdue tickets, due-soon tickets, paused requests, and on-track requests so operators can spot workload spikes and response-risk patterns before reviewing individual tickets.

Support operations now summarize saved response template coverage for the active support queue. The admin queue shows how many requests have matching templates, how many have no template match, how often SLA-sensitive templates apply, and which saved replies match the most active requests.

Support operations can now switch between general support, billing support, trust and safety, and provider operations template sets. Team-specific saved replies appear alongside shared support templates, analytics update for the selected team, and quick-reply buttons populate the staff reply composer with the chosen team's language.

Support operations now include reusable reply templates for investigation updates, follow-up requests, SLA-sensitive responses, resolutions, and ticket closures. Templates are filtered by ticket status and SLA state, can populate the staff reply composer from the admin queue, and keep user-facing reply text separate from internal audit notes.

Users can now initiate account deactivation from the settings page with a confirmation phrase, checklist of blocking conditions (active matches, pending documents, open provider invitations), and warnings about retention and data export. Deactivation performs a soft deactivation that hides the profile from discovery without permanent deletion. A dedicated GET endpoint returns deactivation metadata built from live account state, and the POST endpoint writes the deactivation flag. Reactivation requires signing in again; permanent deletion remains a separate privacy data-request workflow.

Deactivated users are now reactivated when they sign in again. The sign-in page restores profile visibility, shows a reactivation banner with the original deactivation date when available, and lets users continue to their intended destination. Deactivation also queues an account deactivation confirmation email notification so the existing email delivery queue can send or hold the message based on provider readiness.

Journey steps can now be automatically advanced based on live account signals: profile completeness, identity verification, active match relationships, signed documents, and screening completion. A new POST /api/journey endpoint with action 'autocomplete' checks each incomplete step against these signals and bulk-advances eligible steps with an automation reason note. The getAutocompletedSteps helper is pure and testable, and the route collects signals from profile, matches, and document tables before computing completions. Future work can add scheduled reminder delivery and webhook-triggered autocomplete from external events.

Provider-required journey milestones now include assignment metadata derived from accepted provider invitations. The journey API attaches assigned, needed, or not-required provider states to formatted milestones, and the journey UI shows accepted provider context or invite guidance for active legal, screening, cycle, and medical steps. Future work can add dedicated assignment editing and webhook-triggered autocomplete from external events.

Active journey milestones now include reminder delivery readiness metadata based on notification preferences. Users can schedule an active-step reminder from the journey view, and the journey API reuses existing in-app notifications plus the transactional email queue to create or reuse journey reminder records while respecting paused journey/email preferences. Future work can add recurring schedules and webhook-triggered autocomplete from external events.

Journey reminders now support one-time, weekly, and monthly cadence choices. The journey UI lets users choose cadence before scheduling, the journey API normalizes cadence into reminder metadata, and queued reminder records are deduplicated per milestone cadence so recurring-intent reminders remain auditable without adding new scheduling infrastructure. Future work can add webhook-triggered autocomplete from external events.

Journey reminder email records now include due-time scheduling, the service-role email worker only claims queued records whose scheduled_for time is due, and successful weekly or monthly journey reminder sends enqueue the next reminder with recurrence metadata. One-time reminders remain unchanged, current notification preferences are still honored before provider delivery, and existing queue-only/provider-ready behavior remains intact.

Journey automation can now react to trusted external workflow events through a secret-protected service-role webhook. The webhook normalizes provider event types or explicit trusted signals into journey completion signals, reuses existing autocompletion rules, advances eligible incomplete milestones, and writes audit metadata with source, provider event id, signals, and completed step ids.

Journey autocomplete webhooks now support provider-style HMAC SHA-256 verification with timing-safe signature comparison. Operators can keep the existing shared secret authorization or configure a signing secret and send x-journey-webhook-signature values in bare, sha256-prefixed, or comma-delimited provider formats while the route still preserves raw payload bytes for verification before parsing.

Journey autocomplete webhooks now normalize common provider envelope shapes and map source-specific event aliases from document signing, identity verification, screening, profile, and matching systems into journey completion signals. Nested data, event, resource, and object payload fields can provide user identifiers, provider event IDs, source labels, timestamps, and statuses while explicit trusted signals remain supported.

Journey autocomplete webhooks now derive a normalized replay key from the provider source and provider event ID, check prior journey webhook audit metadata before mutating milestones, and return a duplicate replay response without reapplying autocomplete work when the same source event is delivered again. New audit records store the replay key for future duplicate checks while source-specific keys allow different providers to reuse event IDs safely. Future work can add provider dashboard diagnostics.