ApplicationCard.tsx is a fully-built, tested applicant-review component that is never imported or rendered anywhere

[Jagadeeshftw]

Description

src/features/maintainers/components/issues/ApplicationCard.tsx is a complete, well-documented component for maintainers to review, assign, reject, or unassign an applicant on an issue — confirmation steps for destructive actions, pending/spinner states, unmount-safety via a mountedRef, and accessible labels are all implemented, and it has its own test file (ApplicationCard.test.tsx). Despite this investment, it is never imported anywhere in production code:

$ grep -rln "ApplicationCard" src --include="*.ts*"
src/features/maintainers/components/issues/ApplicationCard.tsx
src/features/maintainers/components/issues/ApplicationCard.test.tsx

The only two matches are the component's own definition and its own test — no page or parent component (including IssuesTab.tsx, which lives in the same directory and does its own inline applicant assignment via assignApplicant/unassignApplicant from shared/api/client) ever renders <ApplicationCard />. Maintainers reviewing applicants therefore never see this card's UI at all; whatever IssuesTab.tsx renders inline for applicants is the real, live experience.

Separately, unlike every other card-style component in this feature area, ApplicationCard.tsx never imports useTheme and hardcodes light-mode-only colors throughout (e.g. text-[#2d2820] on a bg-white/[0.15] translucent background) — so if it were wired up as-is, it would likely be unreadable in dark mode, the app's other default. This strongly suggests the component was built and then abandoned before it was ever plugged in or dark-mode-audited.

Requirements

• Either (a) wire ApplicationCard into IssuesTab.tsx's applicant-review flow in place of (or alongside) its current inline implementation, adding dark-mode support first, or (b) delete ApplicationCard.tsx and its test if the inline IssuesTab.tsx implementation is intended to be the permanent one.
• If kept and wired up, add useTheme-driven styling consistent with the rest of the maintainers feature area.

Suggested execution

1. Fork the repo and create a branch: git checkout -b fix/applicationcard-dead-code
2. Compare ApplicationCard.tsx's assign/reject/unassign flow against IssuesTab.tsx's current inline applicant rendering to decide which should be canonical.
3. If wiring it up: add useTheme and dark-mode class variants (mirroring MaintainerIssueCard.tsx's pattern), then render it from IssuesTab.tsx's applicant list.
4. If removing it: delete ApplicationCard.tsx and ApplicationCard.test.tsx.
5. Confirm the maintainers Issues tab's applicant-review flow still functions end-to-end either way.

Example commit message

fix: wire up (or remove) the unused ApplicationCard component

Acceptance criteria

• ApplicationCard is either actually rendered somewhere in the app, or removed entirely along with its test.
• If kept, it is dark-mode aware like its sibling components.
• No dead, unreachable component remains in the maintainers issues feature area.

Security notes

None; this is a dead-code/maintainability issue with no runtime security surface.

Guidelines

• Minimum 95% test coverage
• Timeframe: 96 hours

[1nonlypiece]

Hi Maintainers 👋,

I’d like to apply for this issue.

I have hands-on experience with Next.js frontend development as well as Stellar smart contracts using Rust (Soroban). I’m comfortable working with Figma designs, integrating APIs/wallets on the frontend, and implementing, testing, and optimizing smart contracts on Stellar.

I can follow the project guidelines, communicate progress clearly, and deliver clean, well-tested code within the expected timeline.

Looking forward to contributing to the project 🚀
Thanks!

[Jagadeeshftw]

Assigned @1nonlypiece! Go ahead and open a PR referencing this issue (Closes #891) when ready. t.me/+vTbe0hOUKrFhNTJl