[UI/UX Design] Design a refund tracking UI with multi-stage progress and ETA

[thlpkee20-wq]

Summary

[UI/UX Design] Design a refund tracking UI with multi-stage progress and ETA

Why this matters

Refunds flow through stages (requested, approved, broadcast, settled) and buyers need transparency. Build a RefundTracker with stage chips, ETA, and a copyable transaction hash.

Scope

Implement the requested behavior across src/components/dashboard/booking-progress.tsx. The solution must preserve existing compatibility, authorization, and production safeguards.

Priority

High

Acceptance criteria

• The requested behavior is implemented across src/components/dashboard/booking-progress.tsx with a clear, reviewable contract.
• Security, authorization, validation, and data-integrity requirements in the repository context are enforced and covered by tests.
• Failure, retry, timeout, concurrency, and boundary behavior is explicit and produces safe, diagnosable outcomes where applicable.
• Regression coverage includes empty, invalid, duplicate, and boundary inputs relevant to this flow.
• Existing API, storage, and deployment compatibility is preserved unless a migration is explicitly documented.

Validation

Include focused tests for:

• happy paths;
• invalid input and authorization boundaries;
• concurrency, retries, or failure recovery;
• backward compatibility;
• relevant integration or contract behavior.

The implementation must pass the repository’s existing build, lint, test, and formatting checks (use npm run lint where applicable).

Non-goals

• Typo-only, formatting-only, or documentation-only changes.
• Unrelated refactors or dependency upgrades.
• Weakening security, authorization, CI, or production safeguards.
• Changing public behavior outside this issue’s scope.

Contributor application

Before implementation, comment with:

1. relevant experience;
2. a concise implementation approach;
3. expected files or modules affected;
4. an estimate for opening the first PR.

Wait for maintainer assignment before coding.

PR requirements

Use a feature branch and include Closes #.

The PR must:

• address every acceptance criterion;
• link each criterion to code and tests;
• explain security and failure-mode handling;
• include meaningful regression coverage;
• document compatibility or migration considerations;
• pass the repository checks.

Reward-readiness

This is a substantive quality issue. Merge status does not guarantee reward eligibility; final evaluation is determined separately.

Implementation context

Description

Refunds flow through stages (requested, approved, broadcast, settled) and buyers need transparency. Build a RefundTracker with stage chips, ETA, and a copyable transaction hash.

Requirements and context

• Must be accessible (WCAG 2.1 AA), responsive, and documented in the design system
• Should be consistent with existing patterns and easy to review
• Relevant code: src/components/dashboard/booking-progress.tsx
• The transaction hash row must include a copy button with success toast

Suggested execution

• Fork the repo and create a branch
• git checkout -b uiux/refund-tracker
• Implement changes
  • Add a RefundTracker component with four stage chips
  • Add ETA microcopy and "View on explorer" link
  • Add a copy-to-clipboard control for the tx hash
• Validate accessibility and responsive assumptions

Test and commit

• Run checks
  • npm run lint and component/visual tests
• Cover edge cases
  • Responsive breakpoints, empty/loading/error states, keyboard/screen-reader, contrast, dark mode
• Include screenshots/before-after and accessibility (axe) notes

Example commit message

design: add refund tracker with stage chips and ETA

Guidelines

• Minimum 95 percent test coverage
• Clear documentation
• Timeframe: 96 hours

[ByteForce-Labs]

@ByteForce-Labs has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintain,I will love to work on this issue,I have an experience and I have already reviewed the issue please assigned me to it and I will give a good result.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ByteForce-Labs to this issue.

[drips-wave]

Congratulations, @ByteForce-Labs! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @ByteForce-Labs: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[ByteForce-Labs]

Contributor application — refund tracking UI

I'd like to implement #629.

1. Relevant experience

• [UI/UX Design] Design the marketplace browse grid with sort, density, and saved views #621 — built the on-chain receipt flow (Receipt table, tx-hash copy row, explorer link, truncateHash), establishing the copy/explorer patterns I reused here.
• [UI/UX Design] Design a rebooking flow for cancelled or rescheduled time-tokens #627 — rewrote the slot-list and rebooking dialog with 100 % line coverage on my files, WCAG 2.1 AA focus management, and axe-clean renders. Already shipped via PR feat: rebooking flow for cancelled/rescheduled time-tokens #690.

2. Approach

• Add a RefundTracker component to src/components/dashboard/booking-progress.tsx:
  • Four ordered stage chips (requested → approved → broadcast → settled) that never rely on colour alone: each chip carries an explicit label plus an sr-only "completed / current / upcoming" suffix, and the current stage gets aria-current="step".
  • ETA microcopy per stage with a default estimate and an optional estimatedCompletion override; a settled stage swaps the ETA for a completion summary.
  • Copyable transaction hash with a success toast (CopyButton + useToast, matching the wallet-card pattern) and a "View on explorer" link (rel="noopener noreferrer", default stellar.expert).
  • Polite live region announcing the current stage; graceful states for unrecognised stages and for the pre-broadcast window (no hash yet).
• Add a refundTracking GlossaryTerm and wire the header HelpPopover up to it (glossary is already in the coverage include set).
• Keep BookingProgress / BookingFlowShell and the dashboard barrel backward compatible.

3. Files

• src/components/dashboard/booking-progress.tsx (add RefundTracker)
• src/components/dashboard/booking-progress.test.tsx (RefundTracker + shell state-coverage tests)
• src/lib/glossary.ts (new refundTracking term)
• vitest.config.ts (add booking-progress.tsx to coverage include)

4. Estimate

~2–3 hours including accessibility review, coverage to the 95/90 gates, and the PR.

---

Implementation done — see PR #691 (feat: refund tracking UI with multi-stage progress and ETA (#629)):

• 25 tests passing, per-file coverage for booking-progress.tsx at lines 100 / functions 100 / statements 97.05 / branches 97.34.
• 0 lint errors in touched files, 0 new tsc errors, axe scan clean, and the failing-suite set is identical to upstream main (no new regressions).