Skip to content

[1/4] feat(web): scaffold control-plane console and deploy wiring - #76

Open
immanuel-peter wants to merge 1 commit into
kvcache-ai:mainfrom
immanuel-peter:feat/web-1-scaffold
Open

[1/4] feat(web): scaffold control-plane console and deploy wiring#76
immanuel-peter wants to merge 1 commit into
kvcache-ai:mainfrom
immanuel-peter:feat/web-1-scaffold

Conversation

@immanuel-peter

@immanuel-peter immanuel-peter commented Jul 29, 2026

Copy link
Copy Markdown

What

Add the Next.js control-plane Web UI scaffold (web/), Compose/Kubernetes deploy wiring for agentenv-web, and getting-started docs. Feature routes are intentional stubs until later PRs in this stack.

Why

Maintainers asked for smaller reviewable PRs rather than one large Web UI change. This first slice lands deployable shell + docs without connection or resource logic.

Related issue

Part of #6 (full stack closes it via #79).

Scope and non-goals

In scope

  • Next.js app shell, shadcn UI kit, console sidebar/layout
  • Stub pages for dashboard/settings/sandboxes/snapshots/templates/nodes
  • Dockerfile.web, Compose web service, k8s Deployment/Service
  • Docs + Makefile/gitignore updates

Non-goals

Design and behavior changes

  • New web/ package (Next.js App Router + pnpm)
  • UI published on port 3000 in Compose; k8s Service agentenv-web
  • Nav links exist; stub pages state which follow-up PR owns each surface

Compatibility and operations

  • Public API or generated protocol: N/A
  • Configuration or defaults: Compose/K8s gain optional web service; AENV_DEFAULT_GATEWAY_URL env is present for later PRs
  • Snapshot manifest, artifact layout, or storage format: N/A
  • Upgrade and rollback: additive; remove/disable the web service to roll back
  • Host requirements, permissions, ports, or dependencies: Node/pnpm for local web/; container via deploy/docker/Dockerfile.web

Validation

  • Documentation updated
  • Web lint/build

Commands and results:

cd web && pnpm install --frozen-lockfile && pnpm lint && pnpm build  # pass

Skipped checks and reasons:

  • make fmt / make clippy / make test-unit: no Rust changes in this slice
  • make -C services test: no Go service code changes (deploy YAML only)
  • Benchmarks: UI scaffold only

Risks and reviewer notes

  • Review deploy path: deploy/docker-compose.yml, deploy/docker/Dockerfile.web, deploy/k8s/base/web-*.yaml
  • Stub pages are temporary; do not expect working resource UIs yet
  • Full reference branch: feat/agentenv-webui on the fork

Stack

  1. [1/4] feat(web): scaffold control-plane console and deploy wiring #76 — scaffold + deploy
  2. [2/4] feat(web): Gateway connection settings and session cookies #77 — connection + session
  3. [3/4] feat(web): sandbox and snapshot management views #78 — sandboxes + snapshots
  4. [4/4] feat(web): templates, dashboard, and node views #79 — templates + dashboard + nodes

Please merge strictly 1 → 4. Until preceding PRs merge, later PR diffs include earlier layers; review scope for PR k after the first is its latest commit (compare link in each body). After each merge, remaining PRs will be rebased onto main.

Checklist

  • The PR contains one coherent change and no unrelated formatting or refactoring.
  • New behavior is covered by tests, or I explained why testing is impractical.
  • Logs and examples contain no credentials, tokens, or private registry information.
  • I did not manually edit generated code without updating its source and regenerating it.

Add the Next.js app shell, shadcn UI kit, Compose/Kubernetes web service,
and getting-started docs. Feature routes are stubs until later PRs in the
stack land connection and resource views.

Co-authored-by: Cursor <cursoragent@cursor.com>
@github-actions

Copy link
Copy Markdown
Contributor

OpenCodeReview: Some files could not be reviewed due to errors.

@yingdi-shan

Copy link
Copy Markdown
Collaborator

Thanks for your contribution! This is a huge body of work that clearly took substantial effort. Adding a WebUI could benefit AgentENV a lot. However, this series of changes adds over 50K LoC to our repo, which would significantly increase the maintenance burden. I'd suggest keeping the UI in your own repo instead, and adding a reference to it in our README or docs. What do you think?

@immanuel-peter

Copy link
Copy Markdown
Author

That makes sense. Then, should I migrate this work to a separate immanuel-peter/aenv-webui repo? If so, I can replace these PRs with a docs PR, mentioning the maintained web UI in the new repo.

@yingdi-shan

Copy link
Copy Markdown
Collaborator

Yes, please go ahead. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants