ReviewOS

stacks/ts-cloud

Introduce project → environment → service information architecture and responsive navigation

#140
Closed chrisbbreuer opened this 24 days ago · 0 comments
24 days ago

Roadmap relationship

Outcome

Give every dashboard page a stable place in a single hierarchy—project, environment, service/resource, and operation—so users always know which scope they are viewing and cannot accidentally act on the wrong environment.

Current gap

The current horizontal navigation switches mainly between server/serverless and a few box-level pages. As resources grow, routes and context become hard to discover, member/admin affordances diverge, and environment switching is process-wide rather than page-scoped.

User experience

  • Adopt a responsive sidebar or equivalent compact shell with collapsible groups for projects, services, operations, and settings.
  • Show project and environment selectors persistently, service breadcrumbs on detail pages, and a visible provider/region/server context badge.
  • Preserve deep links and selected scope across reloads; mobile navigation traps no focus and keeps primary actions reachable.
  • Render only permitted destinations, while the server independently enforces access.

Scope

  • Define canonical route and navigation metadata for server, serverless, static, container, data, and infrastructure resources.
  • Introduce project registration/discovery for one or more local configs without copying secret material into UI state.
  • Replace the global active-environment mutation with request/user-scoped selection and explicit URLs.
  • Add not-found, no-access, unsupported-capability, and deleted-resource states with recovery links.
  • Create service overview pages that lead to deployments, logs, metrics, domains, configuration, and operations.

Technical direction

  • Use the persisted resource IDs from the control-plane store and retain human-readable slugs in URLs where useful.
  • Generate permission-aware navigation from one route manifest shared with policy tests.
  • Keep mode/provider capability detection server-side and expose a typed capability descriptor to templates.
  • Add redirects for existing dashboard URLs and a compatibility window.

Safety and operability

  • Changing visible context never changes desired state or deploy target until an explicit action is confirmed.
  • Production is visually distinct without relying on color alone.
  • Cross-scope authorization tests cover guessed IDs and stale/deleted links.

Acceptance criteria

  • A user can move from project list to an environment, service, deployment, and log stream without losing scope.
  • Opening two browser tabs in different environments does not change the other tab.
  • All existing admin/member pages remain reachable through permission-correct navigation or documented redirects.
  • Layouts work at 320px, common tablet widths, and desktop without horizontal page scrolling.

Verification

  • Route-manifest/policy parity tests, deep-link tests, and legacy redirect tests.
  • Keyboard and screen-reader navigation checks plus responsive visual regression snapshots.
  • End-to-end multi-tab environment isolation and member-scope tests.

Non-goals

  • Changing the underlying server vs serverless deployment-mode rules.
  • Adding global search; that is a dependent issue.
  • Redesigning individual feature pages beyond what the shell migration requires.

Sign in to comment on this issue.