docs: reorganize and archive documentation for improved structure

Moved outdated files to the `_archive` folder and reorganized infrastructure-related documentation into the `07_Infrastructure` directory. Improved clarity and ensured logical grouping of files.

docs/Bin/Temp.md

@@ -0,0 +1,87 @@
+# **„Hello-World“-Testprojekt**
+
+Bevor das **"Meldestelle"-Projekt** auf **Zora** losgelassen wird, erstellen wir ein **"Hallo Welt"-Projekt**. Das spart Zeit beim Debugging, wenn der Test-Build fehlschlägt, wissen wir sofort, es liegt an der Infrastruktur (Runner/Registry) und nicht an komplexen Gradle-Abhängigkeiten.
+
+## Plan für "Sandbox-Projekt“, um die CI/CD-Leitung auf **Zora** zu testen.
+
+---
+
+### 1. Runner-Stabilisierung: Der „Herz-Check“
+
+Bevor das Testprojekt gepusht wird, müssen wir sicherstellen, dass der Runner nicht nur „jetzt“ online war, sondern als stabiler Dienst im Hintergrund läuft.
+
+**Checke das im Container `infra-runner`:**
+
+```bash
+incus exec infra-runner -- systemctl status act_runner
+
+```
+
+* **Wenn „active (running)“:** Alles bestens.
+* **Falls nicht:** Starte ihn mit `systemctl enable --now act_runner`.
+* **Gitea-Check:** Im Browser sollte der Status jetzt von **Inaktiv** (Grau/Gelb) auf **Aktiv** (Grün) springen, sobald der Dienst läuft.
+
+---
+
+### 2. Das Test-Projekt: „Zora-Proof-of-Concept“
+
+Erstelle in deiner IDEA (oder direkt in Gitea) ein neues, leeres Repository namens `zora-test`.
+
+#### A. Die minimale Dockerfile
+
+Wir nehmen ein extrem kleines Image, um die ARM64-Fähigkeit zu testen:
+
+```dockerfile
+FROM alpine:latest
+RUN echo "Zora hat dieses Image gebaut!" > /hello.txt
+CMD ["cat", "/hello.txt"]
+
+```
+
+#### B. Der Workflow (`.gitea/workflows/test.yaml`)
+
+Hier nutzen wir deine neuen Secrets `REGISTRY_TOKEN` und `REGISTRY_USER`.
+
+```yaml
+name: Zora Test Build
+on: [push]
+jobs:
+  build-and-push:
+    runs-on: ubuntu-latest # Dein Runner erkennt das Label
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      
+      - name: Login to Registry
+        uses: docker/login-action@v3
+        with:
+          registry: git.mo-code.at
+          username: ${{ secrets.REGISTRY_USER }}
+          password: ${{ secrets.REGISTRY_TOKEN }}
+
+      - name: Build and Push
+        uses: docker/build-push-action@v5
+        with:
+          context: .
+          push: true
+          tags: git.mo-code.at/${{ secrets.REGISTRY_USER }}/zora-test:latest
+
+```
+
+---
+
+### 3. Warum dieser Test so wertvoll ist
+
+1. **Registry-Rechte:** Wir prüfen, ob dein neuer Token wirklich Pakete schreiben darf.
+2. **LXC-Docker-Check:** Wir sehen, ob Docker im Container `infra-runner` mit dem `fuse-overlayfs` Treiber wirklich Images bauen kann.
+3. **ARM64-Verifizierung:** Wir bestätigen, dass der Runner das Image nativ für dein Biest baut.
+
+---
+
+### Was wir kontrollieren müssen (Erfolgskriterien):
+
+* [ ] Erscheint in Gitea unter dem Reiter **„Actions“** ein neuer Eintrag nach dem Push?
+* [ ] Läuft der Build ohne Fehler durch?
+* [ ] Taucht unter deinem Profil in Gitea ein neues **„Paket“** namens `zora-test` auf?
+
+**Soll ich dir, sobald du das Testprojekt in Gitea angelegt hast, helfen das Log-Streaming des Runners zu analysieren, falls er beim `docker login` hängen bleibt?** (Das ist oft die Stelle, an der falsche Secret-Namen auffallen).