commit cbaf3319ce18eb40e40ee657a5e5385e57708ad5 Author: Sven Date: Thu Apr 23 10:11:58 2026 +0200 README.md hinzugefügt diff --git a/README.md b/README.md new file mode 100644 index 0000000..a9f75e1 --- /dev/null +++ b/README.md @@ -0,0 +1,123 @@ +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. \ No newline at end of file