# Portal - Current State

Verified against the current Portal repo after the dashboard/nav cleanup pass, fresh API and Agent repo review, server status/host lifecycle/IDE UX pass, public marketing/SEO refresh, mobile responsiveness pass, server create/delete/status follow-up fixes, and the API control-plane hardening review.

This file records what is implemented now.

## Runtime / tooling baseline
- Portal is aligned to the Node 24 runtime line used by the API repo.
- Current `package.json` pins `engines.node` to `24.14.1`.
- Current `package.json` uses `next@16.2.4`, React 18.2, TypeScript 5, Tailwind 3.4, ESLint 9, and `eslint-config-next@16.2.4`.
- Lint no longer relies on removed `next lint`; the repo uses `eslint .` with the Next 16 flat-config path.
- The lint configuration has been adjusted so current project patterns lint cleanly without forcing a broad React-compiler-style refactor.
- `npm run lint` has previously been reported passing with only existing React hook dependency warnings.
- `npm run build` has previously been reported passing on Next 16.2.4 with Turbopack.
- npm audit has previously been reported clean at moderate-or-higher severity.

## Repo cleanup already done
- Confirmed-unused HUD wrapper components have been removed.
- Stale `src/styles.old/*` legacy CSS has been removed.
- Unused `js-cookie` type shim has been removed.
- Unused dependencies and Tailwind plugins have reportedly been pruned from the Portal repo.
- The Portal cleanup pass reports net line-count reduction rather than growth.
- Current root listing no longer shows the previously suspected stray root binary `testdameon`.

## Public marketing / SEO site
- Public marketing now follows a hybrid SaaS structure:
  - homepage acts as the conversion flow
  - separate pages support deeper product/SEO intent
- Homepage now includes:
  - hero with platform-neutral copy: `Code, test, and run servers from your browser.`
  - browser/dev + managed server subheadline
  - product-style visual panel
  - Build / Test / Ship workflow
  - differentiators
  - use cases
  - SEO topic links
  - pricing preview
  - FAQ preview
  - final CTA
- Root metadata has been updated from the old game-hosting-only description to browser dev environments + managed server hosting positioning.
- Pricing has been repositioned from `Vanilla / Modded / Heavy` to workload tiers:
  - Starter
  - Pro
  - Performance
- Pricing copy now states that every plan includes a browser-based dev environment and managed server hosting.
- Public feature copy now presents the platform as build/test/run rather than Minecraft-only hosting.
- LXC/system-container differentiator is represented carefully as avoiding Docker-style game-server overhead without unsupported benchmark claims.
- The fake `zlh build --target server` hero command was removed and replaced with a real/plausible `$ npm run build` line.
- Public SEO/intent pages exist:
  - `/minecraft-server-hosting`
  - `/modded-minecraft-hosting`
  - `/browser-dev-environment`
- Metadata has been added or refreshed for Home, Features, Pricing, FAQ, About, Support, and the three SEO landing pages.
- FAQ has been expanded around platform positioning, dev environments, Minecraft, mods, datapacks, local install expectations, backups/restores, and plan limits.
- Build and lint were previously reported passing after the marketing/SEO changes with the same existing unrelated warnings.

## Current mobile status
- A targeted mobile responsiveness pass has been applied across public marketing, SEO landing pages, auth pages, server list, server create, and basic console/file/backup surfaces.
- Public nav now uses a working mobile menu and hides the desktop nav until the larger breakpoint.
- CTA groups, pricing cards, auth forms, server cards, and dashboard shell spacing have been adjusted with responsive Tailwind utilities.
- Complex console/file/backup panels are considered basic-mobile-usable rather than full mobile-native experiences.
- Remaining mobile work should be validation/polish only unless new breakage is observed.

## Readiness / operation UI
- Portal consumes API-normalized state.
- Portal understands:
  - `ready`
  - `operationInProgress`
  - `operationType`
  - `maintenance`
  - `operationStartedAt`
  - `operationMessage`
- targeted `409` and `503` UX messaging exists for operation conflicts and not-ready states.
- server card and game console readiness labels now share explicit mapping for ready, stopped, starting, stopping, restarting, maintenance, provisioning/network-pending, plan-limit, and true error states.
- `connectable === false` no longer automatically maps to `Needs attention`; expected non-connectable states such as stopped servers, host lifecycle actions, backup/restore maintenance, and provisioning use specific user-facing labels.
- game server readiness and dev container readiness are separated in the server list so DEV cards use host/agent/IDE state instead of game `connectable` semantics.
- host/container lifecycle status is surfaced from the LXC host layer, including `Online`, `Offline`, `Starting`, `Stopping`, and `Restarting`, plus active host-operation polling.
- server list refresh waits for per-server status enrichment before committing the merged state, preventing transient IDE/readiness badge flips during polling or page remount.
- server creation now records a pending setup marker and returns the user to `/servers` immediately after submit while the create request completes in the background.
- setup progress can be matched by pending name/type before the API returns a VMID, then by VMID once creation finishes.
- setup-step labels are state-aware; stopping or stopped hosts no longer appear as `installing`/`creating` simply because the host is offline.
- the previous maximum-update-depth loop in server-list creation progress hydration has been fixed by removing state values that were being changed from the polling effect dependency path.

## Metrics UI
- server console metrics continue to poll the API metrics summary route for both DEV and GAME servers.
- Portal normalizes multiple CPU, memory, disk, and network field shapes so API casing/name drift does not leave CPU or network stuck at zero.
- metrics polling sends no-cache headers and a cache-busting query value to avoid stale summary responses.
- if CPU/network still do not move for running servers, the remaining likely cause is API/agent metrics collection or rate calculation rather than Portal rendering.

## Backup UI
- game backup UI exists for:
  - list
  - create
  - restore
  - delete
- Portal uses API routes, not direct agent calls.
- backup metadata is normalized and displayed when the API includes metadata fields.
- backup/restore actions now provide user feedback and progress/elapsed time during active operations.

## Console / action gating
- console command transport uses POST JSON through API.
- previous blanket `ready === false` gating bug for game actions was fixed.
- Start is not blocked merely because a stopped server is not ready.
- backup actions are not blocked purely by `ready === false`; backend validity decides.

## Billing / auth / onboarding
- billing UI alignment exists with the newer billing state model.
- billing plan-limit gating has been observed in Portal create flow.
- forgot/reset password flow exists.
- logged-in change-password flow exists.
- first-login onboarding flow exists.
- Next 16 / current TypeScript cleanup included fixes around nullable normalization and search-param/Suspense usage in affected pages/components.

## Hosted IDE
- console and server-list `Open IDE` actions request `/api/dev/{serverId}/ide-token`.
- Portal opens the hosted URL returned by the API, falling back to the configured API base for relative URLs.
- DEV server console and server-list rows show compact IDE indicators and inline `Open`, `Start`, `Restart`, and `Stop` controls instead of large stacked action blocks.
- code-server service actions call `/api/dev/{serverId}/codeserver/start`, `/api/dev/{serverId}/codeserver/restart`, and `/api/dev/{serverId}/codeserver/stop`.
- Portal preserves last-known IDE state when a polling response omits code-server fields, avoiding UI blips between list and status responses.
- API owns the IDE bootstrap, hosted proxy, and tunnel flow. Portal is not expected to proxy IDE traffic itself.

## API client layer
- Portal uses API-mediated transport rather than direct agent calls.
- the old Portal-internal `/api/agent/{serverId}/{action}` bridge has been removed from the frontend repo.
- server deletion has been migrated from `DELETE /api/containers/{vmid}` to `DELETE /api/servers/{id}` through the normal user JWT API client.
- Portal does not add or expose `INTERNAL_API_TOKEN` in browser code.
- delete UX maps API responses explicitly: `202` as already in progress, `401` as login required, `404` as not owned/missing, `409` as `Stop host before deleting`, and `500` as teardown failure.
- Current browser-side API helpers still include `listAuditLogs()` and `listInstances()`; these must be treated as admin/internal-sensitive surfaces until usage is audited against the API route boundary.
- `src/lib/api/legacy.ts` still contains legacy/Pterodactyl-era helper exports and TODOs; keep them quarantined and remove only after confirming there are no live imports.
- Project cleanup has removed dead weight around unused wrappers/dependencies, but API-client/status-polling consolidation is not yet considered fully complete.

## Dashboard / IA
- the dashboard spotlight server card now uses API-backed server data instead of placeholder entries.
- the spotlight card no longer links to a non-existent `/servers/{id}` route; it routes users back into the supported `/servers` surface.
- the spotlight card now recognizes DEV containers across API field aliases and mirrors server-list badges, including the IDE indicator, readiness badge, and host status.
- hub navigation now includes Billing and Profile so onboarding tour targets match the actual menu.
- the hub shell now covers authenticated account/control-surface pages including billing, profile, and support instead of only dashboard/servers.

## Still true
- Portal should track API auth / JWT behavior closely because API-side token hardening can require Portal compatibility verification.
- Portal cleanup should remain behavior-preserving; build/lint green status is part of the current baseline.
- Mobile responsiveness is no longer a from-zero open item, but it still needs periodic device/browser validation as UI surfaces change.
- Browser-visible code must not gain admin/internal shared secrets; admin/internal routes should stay API/server-side concerns unless a deliberate admin UI is built.
