feat(superadmin): migrate internal docs from docusaurus to guava kb

docs/ops/deployment/docker.md

@@ -117,11 +117,10 @@ Because the app image keeps the authoritative copy of the code, each container r
 - Configure backups for the `storage` directories and database dumps.
 - Hook into your observability stack (e.g., ship container logs to Loki or ELK).
 
-## 9. Internal docs publishing
+## 9. Internal docs access
 
-- Build the static docs site locally or in CI via `./scripts/build-docs-site.sh` (runs `npm ci && npm run build` in `docs/site/` and outputs to `docs/site/build`).
-- The Nginx container mounts that build directory and serves it at `/internal-docs/`. History fallback is already configured in `docker/nginx/default.conf`.
-- Access is protected with HTTP Basic Auth. Update `docker/nginx/.htpasswd-docs` with real credentials (`htpasswd -c docker/nginx/.htpasswd-docs <user>`). The repo ships with a weak default for local use—never reuse it in production.
-- Optionally run the build script inside your CI pipeline before deploying so the static output is always up to date. A typical GitHub Actions job would simply call the script after checkout and upload `docs/site/build` as an artifact or rsync it to the server.
+- Internal operations/admin documentation is now delivered in Filament through the Guava Knowledge Base plugin.
+- Access path: `/super-admin/docs` (same auth guard as SuperAdmin).
+- No separate static docs build/container is required.
 
 With the provided configuration you can bootstrap a consistent Docker-based deployment across environments while keeping queue workers, migrations, and asset builds manageable. Adjust service definitions as needed for staging vs. production.

docs/ops/deployment/dokploy.md

@@ -121,9 +121,8 @@ Only SuperAdmins should have access to these widgets. If you rotate the API key,
 
 With this setup the Fotospiel team can manage deployments, restarts, and metrics centrally through Dokploy while Laravel’s scheduler and workers continue to run within the same infrastructure.
 
-## 8. Internal docs publishing in Dokploy
+## 8. Internal docs in Dokploy
 
-- Build the static docs site during CI/CD by running `./scripts/build-docs-site.sh`. Upload the resulting `docs/site/build` directory as part of the deployment artifact or copy it into the Dokploy server before redeploying the stack.
-- `docker-compose.dokploy.yml` mounts that directory into the Nginx container and exposes it at `/internal-docs/`, protected by HTTP Basic Auth.
-- Update `docker/nginx/.htpasswd-docs` with production credentials (use `htpasswd -c docker/nginx/.htpasswd-docs <user>` locally, then redeploy). The repository ships with a weak default only for development—always override it in Dokploy.
-- If Dokploy builds the image itself, add a post-build hook or automation step that runs the docs build and copies it into the shared storage volume before restarting the `web` service.
+- Internal operations/admin documentation is served from the SuperAdmin panel itself via the Guava Knowledge Base.
+- Access path: `/super-admin/docs` with normal SuperAdmin authentication (`super_admin` guard).
+- No dedicated documentation build container or static docs artifact is required in Dokploy.

docs/ops/monitoring-glitchtip.md

@@ -78,7 +78,7 @@ If you skip source map upload, events still work; stack traces will be minified.
 
 ## 4) Docker/Dokploy wiring
 
-- `docker-compose.dokploy.yml` now forwards `SENTRY_*` and `VITE_SENTRY_*` to `app`, workers, scheduler, and docs-build.
+- `docker-compose.dokploy.yml` now forwards `SENTRY_*` and `VITE_SENTRY_*` to `app`, workers, scheduler, and build-time asset steps.
 - Ensure the build container that runs `npm run build` sees `VITE_SENTRY_*` (set in Dokploy env UI or `.env` loaded by Dokploy).
 - Redeploy stack after setting envs; no other container changes needed.
 

docs/ops/oncall-roles.md

@@ -115,7 +115,7 @@ Für On‑Call/Platform‑Ops sollten mindestens folgende Zugänge eingerichtet
 
 Bei einem Incident sollte die On‑Call‑Person immer vom **Betriebshandbuch** aus denken:
 
-- Einstieg über `docs/ops/operations-manual.md` (Docusaurus‑Startseite).
+- Einstieg über `docs/ops/operations-manual.md` (Knowledge-Base-Startseite im SuperAdmin-Panel).
 - Je nach Symptome:
   - **API-/Frontend-Probleme** → Public‑API‑Playbook (`ops/deployment/public-api-incident-playbook.md`), ggf. Marketing/Guest‑PWA‑Spezifikationen in `docs/prp/` (in PRP, nicht im Ops‑Bereich).
   - **Upload/Storage-Probleme** → `ops/media-storage-spec.md`, `ops/guest-notification-ops.md`.

docs/ops/operations-manual.md

@@ -16,7 +16,7 @@ Ziel ist, dass du von hier aus schnell zu den relevanten Runbooks und Referenzen
 - **Systemlandschaft (High‑Level)**
   - Laravel App + Nginx + Redis + MySQL.
   - Async‑Pipeline: Queues (`default`, `media-storage`, `media-security`, `notifications`) und Horizon.
-  - Satelliten: Photobooth‑FTP + Control‑Service, Docs‑Site (`/internal-docs`), Monitoring/Dokploy.
+  - Satelliten: Photobooth‑FTP + Control‑Service, SuperAdmin Knowledge Base (`/super-admin/docs`), Monitoring/Dokploy.
   - Externe Dienste: Lemon Squeezy (Billing), RevenueCat (Mobile‑Abos), E‑Mail Provider, Logging/Monitoring (Loki/Grafana o.ä.).
 
 > TODO: Ergänze ein Architekturdiagramm aus Sicht des Betriebs (z.B. als PNG oder PlantUML) und verlinke es hier.