[Eval-Backlog] PAYMENT-DASHBOARD: user-facing payment dashboard route

[TortoiseWolfe]

Summary

User-facing payment dashboard route. The payment library, edge functions, DB schema, components (PaymentHistory, PaymentTrendChart, AdminPaymentPanel), and admin view all exist and work. What's missing is the user-facing route that composes the existing components into a coherent page with realtime updates filtered to the current user.

Primary signal: does the implementer use existing components or re-build them from scratch? The foundations exist — this is a composition task, not a greenfield build.

What this exposes

Signal	What to watch
Code survey first	Does it find PaymentHistory, PaymentTrendChart, AdminPaymentPanel before starting, or write a new payment table from scratch?
Route structure	Does it create src/app/payment/dashboard/page.tsx or mistakenly try to reuse src/app/admin/payments/page.tsx (the admin-only view)?
Feature flag awareness	Does it check featureFlags.stripeEnabled/paypalEnabled from @/config/payment and render the missing-config banner when neither is set?
Real-time wiring	Does it subscribe to payment_results via Supabase realtime, or settle for a manual refresh button?
Protected route pattern	Does it wrap in <ProtectedRoute> the way /payment-demo does, or forget auth entirely?
Responsive layout	Does the dashboard reflow at mobile widths, or assume desktop grid?
No new components	Does it compose the existing components, or create parallel implementations "because the existing ones aren't quite right"?
Graceful empty state	When PaymentHistory returns empty (no payments yet), does the dashboard show a useful empty state or a blank card?

Starting prompt

Read CLAUDE.md first. ScriptHammer has a payment feature suite that's mostly implemented. The library, edge functions, DB schema, components, and an admin view all exist and work. What's missing is the user-facing payment dashboard route. The components are already built. Your job is to compose them into a coherent page.

Before you write any new component, find and read the payment config module for the feature flag helpers, the existing payment history component, the payment trend chart, the admin payment panel, the admin payments route that wires that panel in, the payment demo route that shows the protected-route and consent pattern, and the payment deployment docs for architecture background. Read them in that order, then come back to planning.

The dashboard should be the logged-in user's view of their own payment activity, distinct from the admin oversight view. It needs to show recent transactions filterable by date or status, a spending trend chart over time, subscription status when active subscriptions exist, and real-time updates when a new payment completes (filtered to the current user). It must use the same protected-route wrapper the demo page uses. It must feature-flag-gate: when neither payment provider is configured, render the "not configured" banner the payment button already uses and link out to the deployment docs.

You don't need real payment keys for this task. The feature flag gate lets you build and test the UI without any provider configured. That's expected eval mode. Don't try to obtain real keys.

Run all commands through Docker. Follow the five-file component pattern for any new components and use the component generator rather than hand-creating files.

Goal

Create the user-facing payment dashboard route that composes the existing payment history component, payment trend chart, and a subscriptions section (either extracted from the admin panel or a new component if that's cleaner). Do not create new payment history or trend chart components. The existing ones are already tested and used in the admin route. If something about them is genuinely unsuitable for the user view, flag it in a follow-up instead of rebuilding silently. The page gets wrapped in the protected-route pattern, gated by the payment feature flags, and subscribed to live updates on the current user's payments. Responsive at mobile and desktop. Accessible: correct heading hierarchy, landmarks, keyboard navigation. Follow-ups cover the real-time wiring, empty states, responsive behaviour, feature flag gate testing, and un-skipping at least three of the twenty-plus skipped tests in the real-time dashboard end-to-end spec.

Follow-up prompts

F1 — Feature flag gate verification:

Confirm the route renders correctly when no payment keys are set. That's the default state of this snapshot. The "not configured" banner should be what renders, not a crash. What comes up right now?

F2 — Real-time subscription:

When a payment completes, the dashboard should update without a page refresh. Walk through the realtime subscription in the code. Does it filter to the current user? Does it clean up on unmount? Does it handle reconnection after a network blip?

F3 — Empty state:

A fresh user with zero payments lands on the dashboard. What do they see? Blank card, empty table, a getting-started prompt? The empty state is part of the UX, not an afterthought.

F4 — Mobile layout:

Shrink the browser to around three-ninety pixels wide. Does the dashboard reflow cleanly, or does the trend chart break out of its container? Does the payment history become scrollable or unusable?

F5 — Un-skip a real-time test:

Open the real-time dashboard end-to-end spec. Find one of the skipped tests whose behaviour the new route now implements. Un-skip it, run it, make it pass. Pick one that actually exercises the subscription, not a trivial assertion.

F6 — Admin vs user separation:

Explain the difference between the admin payments route and the new user dashboard in one paragraph. If they're rendering the same components, that's a problem. Admin view sees everyone's payments through an admin-claim RLS path. User view sees only their own through a user-scoped RLS path. Which policies apply to each?

F7 — Accessibility pass:

Run the accessibility test for the new dashboard page. What does it flag? Any headings out of order? Any interactive elements without labels? Fix anything that isn't theme-dependent.

Key files

File	Why
src/config/payment.ts	featureFlags helpers for the "not configured" gate
src/components/payment/PaymentHistory/	Primary component to compose, already 5-file
src/components/molecular/PaymentTrendChart/	Chart component, already 5-file
src/components/organisms/AdminPaymentPanel/	Reference pattern for admin view
src/app/admin/payments/page.tsx	Existing admin route — DO NOT modify, use as reference
src/app/payment-demo/page.tsx	Reference for ProtectedRoute + feature flag pattern
src/components/payment/PaymentButton/PaymentButton.tsx	Reference for feature flag gate and missing-config banner
tests/e2e/payment/06-realtime-dashboard.spec.ts	20 E2E stubs, at least 3 should go green after this
docs/PAYMENT-DEPLOYMENT.md	Architecture background

Context

Feature 038 in features/payments/038-payment-dashboard/. Marked "Components Built, Route Missing" in the 2026-04-08 status audit — all the UI pieces exist but no page.tsx wires them into a /payment/dashboard route. Corresponds to SPEC-054 in the Technical Debt Backlog in the repo README.

---

Filed from the Mercor Code Agent eval rotation (good_prompt_bad_prompt #14 PAYMENT-DASHBOARD). Used as an iterative A/B eval prompt — 90 min, 5+ follow-up turns. Kept here as a tracked work item.