123 lines
3.7 KiB
Markdown
123 lines
3.7 KiB
Markdown
You are helping implement an internal web application called **Support Provisioning Portal**.
|
|
|
|
Your task is to bootstrap the project based on the local `README.md` in this repository and then implement the first vertical slice with strong engineering discipline.
|
|
|
|
## Product context
|
|
|
|
The application is an internal self-service portal for support staff. It provisions standardized VMs on **Proxmox VE** through a backend service. Users must never interact with Proxmox directly.
|
|
|
|
Typical resources:
|
|
- turnkey PBX/test appliances
|
|
- Windows support clients
|
|
- Linux utility VMs
|
|
|
|
The system must enforce:
|
|
- template-based provisioning only
|
|
- policy-controlled resource limits
|
|
- audit logging
|
|
- lifecycle actions
|
|
- TTL / expiration support
|
|
|
|
## Technical direction
|
|
|
|
Use this stack unless the repository already contains an equivalent decision:
|
|
- Monorepo with pnpm
|
|
- Next.js + TypeScript for `apps/web`
|
|
- Node.js + TypeScript for `apps/api`
|
|
- Fastify preferred for the API
|
|
- PostgreSQL + Prisma
|
|
- Tailwind CSS for the web UI
|
|
- Zod for request/response validation
|
|
|
|
## Constraints
|
|
|
|
- Do not overengineer.
|
|
- Prefer a clean vertical slice over broad scaffolding.
|
|
- Keep Proxmox integration behind a dedicated adapter/module.
|
|
- Use clear domain names and explicit types.
|
|
- Avoid magic strings.
|
|
- Add TODOs only when truly necessary.
|
|
- Document all non-obvious decisions in code comments or small docs.
|
|
- Make the codebase easy to extend toward RBAC, SSO, and multi-cluster support later.
|
|
|
|
## Initial implementation goals
|
|
|
|
Implement a usable first slice with the following:
|
|
|
|
1. Monorepo structure
|
|
- `apps/web`
|
|
- `apps/api`
|
|
- `packages/types`
|
|
- `packages/proxmox-client`
|
|
- `prisma`
|
|
|
|
2. Database schema with at least:
|
|
- users
|
|
- templates
|
|
- deployments
|
|
- audit_logs
|
|
|
|
3. Backend API endpoints
|
|
- `GET /api/templates`
|
|
- `GET /api/deployments`
|
|
- `GET /api/deployments/:id`
|
|
- `POST /api/deployments`
|
|
- `POST /api/deployments/:id/start`
|
|
- `POST /api/deployments/:id/stop`
|
|
- `DELETE /api/deployments/:id`
|
|
|
|
4. Proxmox adapter
|
|
- token auth support
|
|
- stubbed or mockable implementation if no live environment is available
|
|
- methods for clone/start/stop/delete/getStatus
|
|
- clear interface separation between domain service and transport
|
|
|
|
5. Web UI
|
|
- dashboard page listing deployments
|
|
- templates page
|
|
- create deployment form
|
|
- deployment detail view
|
|
- simple status badges and action buttons
|
|
|
|
6. Seed data
|
|
- at least 3 sample templates
|
|
|
|
7. Audit logging
|
|
- every mutating action must write an audit log row
|
|
|
|
8. Developer experience
|
|
- `.env.example`
|
|
- scripts for dev/build/lint
|
|
- basic README sections updated if needed
|
|
|
|
## Working style
|
|
|
|
Proceed in small, reviewable steps:
|
|
1. inspect repository
|
|
2. propose concrete file plan
|
|
3. implement foundation
|
|
4. implement backend slice
|
|
5. implement frontend slice
|
|
6. verify types/build consistency
|
|
7. summarize what was created and what remains
|
|
|
|
## Output requirements
|
|
|
|
- Start by reading the local `README.md` and align implementation with it.
|
|
- Show the file/folder plan before making broad changes.
|
|
- Then create the project incrementally.
|
|
- When assumptions are required, state them briefly and choose the most pragmatic path.
|
|
- Favor production-style code structure over tutorial-style code.
|
|
- Where live Proxmox access is unavailable, create a mock adapter that can later be replaced without touching domain logic.
|
|
|
|
## Quality bar
|
|
|
|
- TypeScript strict mode
|
|
- input validation at API boundaries
|
|
- no secrets committed
|
|
- minimal but coherent UI
|
|
- compile-ready code where possible
|
|
- no dead code
|
|
- no fake features presented as complete
|
|
|
|
Begin by inspecting the repository and proposing the exact bootstrap structure to create. |