[ThatCodeBabe]

Summary

Implements three Stellar Wave Program issues in one branch (#685 depends on loading states introduced by #684, so these were done in order: #682 → #684 → #685).

#682 — Settings page

/settings, five tabs (Network, Trading, Display, Security, Advanced). No backend settings service exists yet, so this is a client-only first cut backed by localStorage (web/lib/settings.ts + web/lib/settingsStore.ts, following the same createStore/createUseStore pattern context/WalletContext.tsx already uses). Reuses existing state instead of duplicating it where it already exists:

• Network tab reads the build-time active network from lib/contracts.config.ts's getStage() (same source NetworkStatusBanner uses) rather than re-deriving it, and persists a UI-only "preferred network" + custom RPC endpoint + chain ID for a future runtime switcher.
• Display tab embeds the existing <ThemeToggle /> as-is.
• Security tab reuses useWallet() for the connected-wallets list.
• Advanced tab reuses the existing featureFlagService singleton directly (the React <FeatureFlagProvider> is only mounted in the Pages Router tree, not available to this App Router page).

#684 — Vault detail modal

Expandable modal/drawer with strategy config, performance metrics, risk parameters, a historical APY sparkline, token info, and deposit/withdraw/manage actions (wired to a toast placeholder — no transaction-building). Data loads on demand (useVaultDetail, only fetches once the modal actually opens).

There's no backend endpoint yet returning strategy/risk/performance data, so lib/vault-detail.ts generates deterministic, seeded mock data from the vault id (same id → same numbers, covered by lib/vault-detail.test.cjs) rather than inventing a fake "looks real" contract. The historical chart is a small inline SVG sparkline — no charting library added (none exists in package.json, and next.config.js already splits vendor chunks deliberately for bundle size, #686).

VaultDetailContent is shared between the modal and the /vault/[id] and /vaults/[id] page routes (previously placeholder stubs), so the list-triggered and deep-linked views never drift apart. Both page routes now also export generateMetadata via the existing buildVaultMetadata/buildVaultJsonLd helpers, and correctly type Next.js 15+'s async params.

components/VaultRow.tsx gained an optional onClick (keyboard-accessible, doesn't conflict with the existing href/PrefetchLink case), and components/vault/VaultList.tsx had a broken import (./VaultRow instead of ../VaultRow) fixed so it actually compiles. A new /vaults list page wires VaultList → VaultDetailModal end-to-end, since neither component had a caller anywhere in the app before this change.

#685 — Skeleton loading states

New skeletons: VaultCardSkeleton/VaultListSkeleton, VaultDetailSkeleton (ships with #684 from the start, per the issue's own sequencing note), TransactionRowSkeleton (sized to the existing TRANSACTION_ROW_HEIGHT constant — no TransactionRow component exists yet to retrofit), DataTableSkeleton (mirrors components/ui/DataTable.tsx), and FormSkeleton (used by the Settings page's hydration guard). All follow the accessibility/visual convention already established by NutritionLabelSkeleton/ResultViewerSkeleton (animate-pulse, role="table"/"row"/"cell", aria-busy="true"), colored to match the content each stands in for.

Also wired the two existing-but-previously-unused skeletons into real call sites: ResultViewerSkeleton now replaces both the dynamic-import "Loading result viewer…" text fallback and the in-flight-simulation state in pages/index.tsx.

Left alone intentionally: the small Loader2 icons inside DynamicForm's and WasmUpload's active submit buttons — those are transient busy-state indicators on an already-labeled control ("Simulating…", "Invoking…"), not full-content loading screens; swapping a 16px icon for a skeleton there would be the wrong pattern.

Pre-existing issues found and fixed (unrelated to these 3 issues, but blocking verification)

• app/layout.tsx and pages/_app.tsx each had duplicated/unreconciled JSX from two previously-merged features, failing to parse at all. Reconciled into single trees keeping every provider from both branches.
• pages/index.tsx had a duplicated second results column; merged into one.
• web/package.json was missing the @tanstack/react-virtual dependency that yarn.lock and existing vault-list code already required (present in the lockfile, never added to package.json) — added it; package-lock.json updated. (yarn.lock intentionally left alone — yarn 4.9.1 crashed with an unrelated internal error in the sandbox used for this change; a maintainer with a working yarn should run yarn install once to sync it.)
• web/package.json's test script glob was silently dropping every direct-child test file under lib/ and __tests__/ when run through sh (** degrades to a single * under POSIX glob, requiring exactly one directory level). Quoted the globs so Node's own recursive glob engine handles them — this surfaced ~190 previously-dead tests, including the new ones added here, and 6 pre-existing, unrelated failures (component-docs registry drift, an App Router migration placeholder check, a mobile-responsiveness class-string check, and a CSP connect-src check) that were never actually being run before. None of those 6 are touched by this PR.
• hooks/useFocusTrap.ts's FocusTrap interface hardcoded a non-generic ref type, breaking any typed caller (already affected NavDrawer.tsx; now needed for the new vault detail modal). Made it generic.
• lib/vault-metadata.ts's normalizeVaultData read fields off a union type that didn't typecheck. Read through an explicit Record<string, unknown> view instead.

Verification

• npm test (web/): 545/551 passing. The 6 failures are 100% pre-existing on a clean upstream/main (confirmed by running the suite on a pristine checkout with only the test-glob fix applied) and unrelated to these 3 issues — see above.
• npm run typecheck (web/): fails, but only with the same pre-existing errors present on a clean upstream/main before this branch (missing optional devDependencies for storybook/playwright/testing-library/axe-core, a sentry SDK version mismatch, next-intl config types, lib/api.ts DTO narrowing, an unrelated dead-variable bug in ErrorBoundary.tsx, etc.) — confirmed by diffing the error list before/after this branch's changes. No new errors introduced; several pre-existing ones fixed (see above).
• npm run lint (web/): fails project-wide, including on files this PR never touches — every file reports Definition for rule '@typescript-eslint/...' was not found, an eslint/eslint-config-next version-compatibility break pre-existing on upstream/main. Filtering that specific noise out, npx eslint on every file this PR adds/touches reports zero other issues.
• npm run build (web/): fails on a clean upstream/main before this branch too — Next 16 treats the App Router/Pages Router path collisions on /, /admin/managers and /vault/[id] as hard build errors (web/Vault.md documents this App Router migration as still in progress, Phase 2 of 4). This branch adds no new colliding routes (/settings, /vaults, /vaults/[id] have no Pages Router equivalent) and doesn't change this pre-existing failure mode.

Judgment calls

• Settings persistence: localStorage-backed client store, no backend — documented above and in lib/settings.ts's file header.
• Network tab's network toggle is a UI-only preference; the real network is build-time-resolved (NEXT_PUBLIC_STELLAR_NETWORK) and shown read-only.
• Language tab persists a preference rather than wiring the existing LanguageSwitcher (which depends on next/router, unavailable under the App Router page this Settings page renders on).
• Vault detail data is deterministic mock data (seeded by vault id), since no backend endpoint returns strategy/risk/performance fields yet.
• Historical performance chart is a hand-rolled SVG sparkline, not a new charting dependency.
• Fixed several pre-existing, build/test-blocking bugs encountered along the way (see above) rather than leaving verification impossible; left the larger, unrelated pre-existing issues (App Router/Pages Router route collisions, the eslint plugin resolution break, the ~6 newly-surfaced-but-unrelated test failures) untouched as out of scope.

Closes #682
Closes #684
Closes #685

[drips-wave]

@ThatCodeBabe Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits