@hybridlabor-api/aos 4.4.1 → 4.4.2-beta.0

package/skills/bdbsaastraining/references/interaction-modes.md

@@ -1,94 +0,0 @@
-# Interaktionsmodi — Dual-Mode Kontrakt
-
-Der Trainings-Skill läuft in fünf Clients. Nur **Claude Code** hat ein natives Auswahl-Tool.
-Der Tutor erkennt den Client aus Station 0 (`<CLIENT_NAME>`) und wählt den Modus **einmal** für die gesamte Session.
-
----
-
-## Modus 1 — Claude Code: `AskUserQuestion`
-
-Nutze das Tool für **jede** strukturierte Auswahl:
-- Track-Wahl (Station 0, Teil B)
-- Sizing-/Konfig-Entscheidungen (CPU/RAM/Disk, DNS-Proxy-Modus, Auth ja/nein)
-- alle Multiple-Choice-Verständnisfragen
-- alle 10 Abschlussfragen
-
-Regeln:
-- 2–4 echte Optionen pro Frage. Die vom Skill empfohlene Option steht an Position 1 mit `(Empfohlen)` im Label.
-- `header` ≤ 12 Zeichen (z. B. `Track`, `RAM`, `DNS-Modus`, `Frage 3`).
-- **„Other" (Freitext) fügt das Tool automatisch hinzu** — nicht selbst als Option auflisten.
-- `preview` einsetzen, wenn **Vergleich** der Kern ist: YAML-Profilvarianten nebeneinander, Ressourcen-Sizing, `🟠 proxied` vs `⚪ DNS-only`. NICHT bei einfachen Ja/Nein-Abzweigungen.
-- Single-Select als Default. `multiSelect: true` nur wenn Mehrfachauswahl fachlich sinnvoll ist (z. B. „welche Zusatzpakete brauchst du?").
-
-Auswertung:
-- Gewählte Option → direkt weiterverarbeiten.
-- „Other"-Freitext → siehe Freitext-Regeln unten.
-
----
-
-## Modus 2 — AGY / Cursor / Claude Desktop / OpenCode / unbekannt: Text-Schema
-
-Formatiere jede Auswahl als nummerierte Liste:
-
-```
-<Frage>
-
-  A) <Option 1>
-  B) <Option 2>
-  C) <Option 3>
-  D) <Option 4>
-  E) etwas anderes → beschreib es in eigenen Worten
-```
-
-- `E)` ist der Freitext-Kanal (Äquivalent zu „Other").
-- Bei Verständnisfragen mit nur 2–4 Sachoptionen entfällt `E)` **nur in der Abschlussprüfung** (dort ist Freitext ungültig); in Stationsfragen bleibt `E)` erhalten.
-- **Fehleingaben still normalisieren:** `b`, `b.`, `B)`, „Antwort B", „die zweite", „option 2" → alle zu `B`. Nicht belehren, einfach die gemeinte Option verarbeiten.
-- Mehrdeutige oder leere Antwort → einmal kurz rückfragen: „Meinst du A oder C?"
-
----
-
-## Freitext-Regeln (modusübergreifend)
-
-| Kontext | Freitext erlaubt? | Verhalten |
-| :-- | :-- | :-- |
-| Station 0 Teil A (Name, User, Client) | ja, immer offen | direkt übernehmen |
-| Station 0 Teil B (Workload) | **ja, erwünscht** | Freitext → **Track E**, Rohziel für `build_profile.py` merken |
-| Sizing-/Konfig-Fragen (Station 2, Track E) | **ja, erwünscht** | Freitext parsen (Zahlen, Paketnamen, Ports); bei Lücken gezielt nachfragen |
-| Zwischen-Verständnisfragen der Stationen 0.5–5 | ja | Freitext inhaltlich bewerten; bei „fast richtig" sokratisch nachhaken |
-| **Abschlussprüfung (10 Fragen)** | **nein** | Freitext → **einmalig** um Auswahl A–D bitten. Bleibt Trainee bei Freitext → **0 Punkte** für die Frage, weiter zur nächsten |
-
----
-
-## Mapping Workload-Auswahl → Track
-
-| Auswahl Station 0 Teil B | Track | Track-Datei |
-| :-- | :-- | :-- |
-| A · AI-Agent Sandbox | `A` | `references/track-a-ai-agent.md` |
-| B · WordPress / Web-App | `B` | `references/track-b-wordpress.md` |
-| C · Mailserver | `C` | `references/track-c-mailserver.md` |
-| D · Clean Debian / DB / Worker | `D` | `references/track-d-debian.md` |
-| „Other" / E · Freitext | `E` | `references/track-e-custom.md` |
-
-Track E kann nach dem Interview auf einen konkreten Basis-Track „andocken" (web-artig → B-Muster, mail-artig → C-Muster, intern → D-Muster). Die Track-E-Datei steuert das.
-
----
-
-## Beispiel — Track-Wahl in beiden Modi
-
-**Claude Code (`AskUserQuestion`):**
-- question: „Was möchtest du auf der BDB SaaS Host Fleet konkret betreiben?"
-- header: `Workload`
-- options: `AI-Agent Sandbox` / `WordPress / Web-App` / `Mailserver` / `Clean Debian / DB / Worker`
-- (Tool ergänzt „Other" automatisch → Track E)
-- optional `preview` je Option: 4–6 Zeilen, was der Track lehrt + Basis-Template
-
-**Text-Modus:**
-```
-Was möchtest du auf der BDB SaaS Host Fleet konkret betreiben?
-
-  A) AI-Agent Sandbox    – autonome Agenten, restricted shell, agent-sudo
-  B) WordPress / Web-App  – öffentlich, Caddy + Authelia 2FA, Cloudflare proxied
-  C) Mailserver           – Froxlor/Postfix/Dovecot, eigene Kundendomain, DNS-Blueprint
-  D) Clean Debian         – generischer Container, Datenbank/Worker, selbst konfiguriert
-  E) etwas anderes → beschreib deinen Workload in eigenen Worten
-```

package/skills/bdbsaastraining/references/track-a-ai-agent.md

@@ -1,111 +0,0 @@
-# Track A — AI-Agent Sandbox
-
-**Ziel-Workload:** autonome AI-Agenten in isolierter, restricted-shell Umgebung.
-**Basis-Template (real):** `server-config/templates/incus/profile-ai-agent.yaml`
-**Container-Name im Training:** `c-A-<TRAINEE_USER>` · **Profil-Name:** `A-<TRAINEE_USER>`
-
----
-
-## Station 2 — Incus Profile Engineering (Track A)
-
-### 2.1 Echtes Template inspizieren
-Der Trainee öffnet `profile-ai-agent.yaml` und liest laut vor, was er sieht. Erwartete Struktur:
-- `config.limits.cpu: "2"`, `config.limits.memory: 2GiB` — harte Quotas.
-- `config.cloud-init.user-data` (**nicht** `user.user-data`) mit `#cloud-config`.
-- `packages:` nodejs, npm, python3, python3-venv, python3-pip, git, build-essential.
-- `users:` — ein User `agent` mit **`shell: /bin/rbash`** und einer einzigen sudo-Regel (`systemctl --no-pager status *`).
-- `write_files:` — eine `README.txt` im Home des Agenten.
-- **kein `devices:`** → `eth0`/`root` kommen aus dem `default`-Profil.
-
-Frage zum Verständnis (nicht Prüfung): „Was kann der User `agent` mit `/bin/rbash` NICHT?" → kein `cd`, keine absoluten Pfade, kein `>`-Redirect, kein Ändern von `PATH`.
-
-### 2.2 Eigenes Profil generieren
-Interview (per `AskUserQuestion` / Text):
-- RAM: 1 / 2 / 4 GiB (Default 2, Node-Limit ≤ 8)
-- CPU: 1 / 2 (Default 2)
-- Zusatz-Runtime: „nur Python" / „nur Node" / „beides" (Default beides)
-- Agent-Framework vorinstallieren? `fastmcp` via pip / `@modelcontextprotocol/sdk` via npm / nichts
-
-```bash
-python3 ~/.agents/skills/bdbsaastraining/scripts/build_profile.py \
-    --track A --user <TRAINEE_USER> \
-    --ram 2 --cpu 2 --runtime both --agent-framework fastmcp
-```
-Output: `~/profile-A-<TRAINEE_USER>.yaml` + zeilenweise Erklärung.
-Der Generator behält `shell: /bin/rbash` bei (Kernkonzept) und ergänzt bei `--agent-framework fastmcp` einen `runcmd`-Schritt `python3 -m venv /home/agent/venv && /home/agent/venv/bin/pip install fastmcp` (statt es dem Trainee später als `ModuleNotFoundError` zu überlassen).
-
-### 2.3 Registrieren & prüfen
-```bash
-sudo incus profile create A-<TRAINEE_USER>
-sudo incus profile edit A-<TRAINEE_USER> < ~/profile-A-<TRAINEE_USER>.yaml
-sudo incus profile show A-<TRAINEE_USER>
-```
-
-**Verständnisfrage 2 → `exam-pool.md` → `CORE_2`** (incusbr0 / Bridge).
-
----
-
-## Station 3 — Deployment & Agent-Task (Track A)
-
-```bash
-sudo incus launch images:debian/13 c-A-<TRAINEE_USER> -p default -p A-<TRAINEE_USER>
-sudo incus list
-sudo incus exec c-A-<TRAINEE_USER> -- cloud-init status --wait
-```
-
-### 3.1 In die Sandbox als unprivilegierter Agent
-```bash
-sudo incus exec c-A-<TRAINEE_USER> -- su - agent
-# Erwartung: rbash-Prompt. Test:
-cd /tmp            # -> rbash: cd: restricted
-```
-> Falls der Trainee den User `agentrunner` erwartet (aus altem Skill-Stand): den gibt es NICHT. Der reale User heißt `agent`.
-
-### 3.2 Realer Agent-Task — MCP-Tool im Container bauen
-```bash
-# als agent, im Home:
-cat > build_mcp.py <<'PY'
-from fastmcp import FastMCP
-mcp = FastMCP("demo-agent-service")
-
-@mcp.tool()
-def analyze_lead(email: str, company: str) -> dict:
-    return {"status": "analyzed", "email": email, "company": company, "score": 95}
-
-if __name__ == "__main__":
-    mcp.run(transport="stdio")
-PY
-/home/agent/venv/bin/python build_mcp.py --help 2>&1 | head
-```
-Didaktik: Selbst wenn das Skript crasht oder eine Endlosschleife baut — der Host ist durch die 2-GiB-Quota + Incus-Sandbox unberührt.
-
-**Verständnisfrage 3 → `exam-pool.md` → `CORE_1`** (Sandbox-Vorteil).
-
----
-
-## Station 4 — FastMCP & Guardrails (Track A-Fokus)
-
-Zusätzlich zum gemeinsamen Station-4-Ablauf (siehe `SKILL.md`):
-- Der Trainee ruft `create_lldap_user(username="agent-demo-<TRAINEE_USER>", group="ai_agents", owner="<TRAINEE_USER>")` auf und beobachtet die Antwort (`status: "success"`, Hinweis auf Background-Worker).
-- Erklärung `agent-sudo`: auf einer Agent-SSH-Session ist `sudo` gesperrt; der Agent nutzt `agent-sudo <cmd>`. `agent-sudo ls /etc` → Auto-Approve. `agent-sudo systemctl restart caddy` → Queue.
-
-**Track-Fragen für die Prüfung:** `A_1`, `A_2`, `A_3`, `A_4`.
-
----
-
-## Station 5 — Interne Gateway-Route (Track A)
-
-Der Agent exponiert ein kleines Web-UI (z. B. Port 8000) — **nur** hinter Authelia, nie roh öffentlich:
-```
-remoteos_add_route(
-    domain="agent-<TRAINEE_USER>.<DOMAIN>",
-    upstream_port=8000,
-    require_auth=True,
-    target_node="netcup",
-    service_type="web",
-    sync_cloudflare=True
-)
-```
-> **Gateway-Lücke:** `/tools/add_route` ist am Remote-Gateway ein Stub. Der Trainee verifiziert daher zusätzlich direkt auf dem Server: `sudo caddy validate --config /etc/caddy/Caddyfile` und prüft, ob ein `forward_auth`-Block für die Domain existiert. Alternativ Konzept erklären: ohne 2FA-Session → 302 auf `auth.<DOMAIN>`.
-
-**Verständnisfrage 5 → `exam-pool.md` → `A_3`** (agent-sudo Klassifikation) — oder als Prüfungsfrage aufheben und hier `CORE_5` (Queue-Verhalten) stellen.

package/skills/bdbsaastraining/references/track-b-wordpress.md

@@ -1,111 +0,0 @@
-# Track B — WordPress / Web-App
-
-**Ziel-Workload:** öffentlich erreichbare Web-Anwendung hinter Caddy + Authelia 2FA.
-**Basis-Template (real):** `server-config/templates/incus/profile-wordpress.yaml`
-**Container:** `c-B-<TRAINEE_USER>` · **Profil:** `B-<TRAINEE_USER>`
-
----
-
-## Station 2 — Incus Profile Engineering (Track B)
-
-### 2.1 Echtes Template inspizieren
-`profile-wordpress.yaml`:
-- `config.limits.cpu: "2"`, `config.limits.memory: 4GiB`.
-- `config.cloud-init.user-data` → `#cloud-config` mit `package_update: true`, `package_upgrade: true`.
-- `packages:` nginx, mariadb-server, redis-server, php-fpm, php-mysql, php-redis, php-curl, php-gd, php-xml, php-mbstring, certbot.
-- `runcmd:` — erzeugt DB `wp` + User `wp` mit Zufallspasswort (`openssl rand -hex 16` → `/root/.wp-db-credentials`, `chmod 0600`), dann `systemctl enable --now nginx mariadb redis-server php8.2-fpm`.
-- **kein `devices:`** → aus `default`.
-
-**Bekannter Bug (Diagnose-Übung):** `php8.2-fpm` ist hart kodiert. Debian 13 (trixie) liefert PHP 8.4 → die Unit `php8.2-fpm` existiert nicht, der `systemctl`-Aufruf schlägt fehl. Der Generator ersetzt das durch die real installierte Version (`php-fpm` Meta-Paket → Dienst per `systemctl enable --now $(systemctl list-units 'php*-fpm*' ...)` bzw. parametrisiert `php8.4-fpm`).
-
-### 2.2 Eigenes Profil generieren
-Interview:
-- RAM: 2 / 4 GiB (Default 4, Node-Limit ≤ 8)
-- Disk-Quota: 20 / 40 / 60 GiB (Default 40)
-- DB-Engine: MariaDB (Default) / PostgreSQL
-- Object-Cache Redis: ja (Default) / nein
-- WordPress automatisch per `wp-cli` installieren? ja / nein (nur Stack)
-
-```bash
-python3 ~/.agents/skills/bdbsaastraining/scripts/build_profile.py \
-    --track B --user <TRAINEE_USER> \
-    --ram 4 --disk 40 --db mariadb --redis yes --wpcli yes
-```
-Output: `~/profile-B-<TRAINEE_USER>.yaml`. Der Generator fixt den `php8.2-fpm`-Bug und fügt bei `--wpcli yes` einen `runcmd`-Schritt für `wp core download && wp config create ...` hinzu.
-
-### 2.3 Registrieren & prüfen
-```bash
-sudo incus profile create B-<TRAINEE_USER>
-sudo incus profile edit B-<TRAINEE_USER> < ~/profile-B-<TRAINEE_USER>.yaml
-sudo incus profile show B-<TRAINEE_USER>
-```
-
-**Verständnisfrage 2 → `exam-pool.md` → `B_1`** (packages in cloud-init).
-
----
-
-## Station 3 — Deployment & Verify (Track B)
-
-```bash
-sudo incus launch images:debian/13 c-B-<TRAINEE_USER> -p default -p B-<TRAINEE_USER>
-sudo incus exec c-B-<TRAINEE_USER> -- cloud-init status --wait
-sudo incus exec c-B-<TRAINEE_USER> -- systemctl --failed
-```
-Verifikation:
-```bash
-CT_IP=$(sudo incus list c-B-<TRAINEE_USER> -c4 --format csv | cut -d' ' -f1)
-curl -sI "http://$CT_IP/" | head -1        # -> HTTP/1.1 200 / 301 (nginx lebt)
-sudo incus exec c-B-<TRAINEE_USER> -- cat /root/.wp-db-credentials
-```
-Wenn `systemctl --failed` `php8.2-fpm` zeigt → Diagnose-Übung: `systemctl list-units 'php*'`, richtigen Dienstnamen finden, im generierten Profil ist es bereits gefixt (Trainee vergleicht).
-
-**Verständnisfrage 3 → `exam-pool.md` → `B_4`** (php-Version-Bug).
-
----
-
-## Station 4 — FastMCP & Guardrails
-
-Gemeinsamer Ablauf (`SKILL.md`). Track-B-Betonung: `remoteos_create_instance` würde für einen echten Kunden so aussehen —
-```
-remoteos_create_instance(
-    client_name="kunde-mueller",
-    domain="shop.kunde-mueller.de",
-    template="wordpress",
-    environment="staging1",
-    target_node="netcup",
-    cpu_cores=2, ram_gb=4, disk_gb=40
-)
-```
-`staging1` → sofort, `environment="production"` → 4-Augen-Queue (siehe `classify_risk`).
-
-**Track-Fragen:** `B_1`, `B_2`, `B_3`, `B_4`.
-
----
-
-## Station 5 — Öffentliche Web-Route (Track B)
-
-```
-remoteos_add_route(
-    domain="app-<TRAINEE_USER>.<DOMAIN>",
-    upstream_port=80,
-    require_auth=True,
-    target_node="netcup",
-    service_type="web",
-    sync_cloudflare=True
-)
-```
-Erwartetes Verhalten (Konzept, da `/tools/add_route` Stub):
-- Caddy bekommt `forward_auth 127.0.0.1:9091 { uri /api/authz/forward-auth ... }` + `reverse_proxy` auf die Container-IP.
-- Cloudflare A-Record `app-<TRAINEE_USER>` → Netcup-IP, **`🟠 proxied`** (`service_type="web"` ⇒ `proxied: true`).
-
-Verifikation auf dem Server:
-```bash
-sudo caddy validate --config /etc/caddy/Caddyfile
-curl -sI https://app-<TRAINEE_USER>.<DOMAIN> | grep -Ei 'location|http/'   # -> 302 auth.<DOMAIN>
-```
-DNS-Blueprint für eine echte Kundendomain zusätzlich:
-```
-remoteos_get_dns_blueprint(domain="kunde-mueller.de", service_type="web")
-```
-
-**Verständnisfrage 5 → `exam-pool.md` → `B_2`** (proxied-Modus) oder `B_3` (forward_auth 302).

package/skills/bdbsaastraining/references/track-c-mailserver.md

@@ -1,107 +0,0 @@
-# Track C — Mailserver (Froxlor / Postfix / Dovecot)
-
-**Ziel-Workload:** Kunden-Mailserver mit eigener Domain.
-**Basis-Template (real):** `server-config/templates/incus/profile-mailserver-froxlor.yaml`
-**Container:** `c-C-<TRAINEE_USER>` · **Profil:** `C-<TRAINEE_USER>`
-
----
-
-## Station 2 — Incus Profile Engineering (Track C)
-
-### 2.1 Echtes Template inspizieren
-`profile-mailserver-froxlor.yaml`:
-- **Top-Level `name:` UND `description:`** (dieses Template hat beides — anders als die anderen).
-- `config.limits.cpu: "2"`, `config.limits.memory: 4GiB`.
-- `config.cloud-init.user-data` → `packages:` postfix, dovecot-imapd, dovecot-pop3d, mariadb-server, php-fpm, php-mysql, php-cli, certbot, nginx, curl, gnupg.
-- `write_files:` — `/root/install_froxlor.sh` (Rechte `0755`), setzt die offizielle Froxlor-Debian-Repo + Key ein, `apt-get install froxlor`.
-- `runcmd:` — `[ "/bin/bash", "/root/install_froxlor.sh" ]`.
-
-> Für `incus profile edit` **muss der Top-Level `name:` raus** (bzw. exakt gleich dem CLI-Profilnamen). Der Generator entfernt ihn.
-> `php8.2-fpm` im `install_froxlor.sh` ist wie bei Track B versionsabhängig — Diagnose-Übung, im Generat gefixt.
-
-### 2.2 Eigenes Profil generieren
-Interview:
-- Kundendomain (Freitext, z. B. `kunde-mueller.de`) — Pflicht für Station 5
-- Anzahl Postfächer: 5 / 10 / 20 (beeinflusst Disk-Empfehlung)
-- POP3 zusätzlich zu IMAP? ja / nein (Default nur IMAP)
-- Webmail (Roundcube) mit ausliefern? ja / nein
-
-```bash
-python3 ~/.agents/skills/bdbsaastraining/scripts/build_profile.py \
-    --track C --user <TRAINEE_USER> \
-    --customer-domain kunde-mueller.de --mailboxes 10 --pop3 no --webmail yes
-```
-
-### 2.3 Registrieren & prüfen
-```bash
-sudo incus profile create C-<TRAINEE_USER>
-sudo incus profile edit C-<TRAINEE_USER> < ~/profile-C-<TRAINEE_USER>.yaml
-sudo incus profile show C-<TRAINEE_USER>
-```
-
-**Verständnisfrage 2 → `exam-pool.md` → `C_1`** (write_files vs runcmd).
-
----
-
-## Station 3 — Deployment & Verify (Track C)
-
-```bash
-sudo incus launch images:debian/13 c-C-<TRAINEE_USER> -p default -p C-<TRAINEE_USER>
-sudo incus exec c-C-<TRAINEE_USER> -- cloud-init status --wait
-```
-Verifikation:
-```bash
-sudo incus exec c-C-<TRAINEE_USER> -- postconf mail_version
-sudo incus exec c-C-<TRAINEE_USER> -- systemctl is-active postfix dovecot
-sudo incus exec c-C-<TRAINEE_USER> -- ss -tlnp | grep -E ':25|:143|:993'
-sudo incus exec c-C-<TRAINEE_USER> -- ls -la /var/www/froxlor 2>/dev/null || echo "froxlor install noch nicht fertig"
-```
-
-**Verständnisfrage 3 → `exam-pool.md` → `CORE_6`** (Mail nie proxied).
-
----
-
-## Station 4 — FastMCP & Guardrails
-
-Gemeinsamer Ablauf. Track-C-Betonung — echter Provisioning-Call für einen Mail-Kunden:
-```
-remoteos_create_instance(
-    client_name="kunde-mueller",
-    domain="mail.kunde-mueller.de",
-    template="froxlor-mail",
-    environment="staging1",
-    target_node="netcup"
-)
-```
-Antwort enthält bei einer externen Kundendomain (nicht die Fleet-Domain) **kein** Cloudflare-Sync, sondern ein `dns_blueprint`-Feld (Mailserver-Variante).
-
-**Track-Fragen:** `C_1`, `C_2`, `C_3`, `C_4`.
-
----
-
-## Station 5 — DNS-Blueprint für die Kundendomain (Track C)
-
-```
-remoteos_get_dns_blueprint(
-    domain="<CUSTOMER_DOMAIN>",
-    service_type="mail",
-    target_node="netcup"
-)
-```
-Der Trainee liest das generierte Paket und ordnet jeden Record zu:
-- **A** `mail.<domain>` → Netcup-IP, **⚪ DNS-only**
-- **MX** `<domain>` → `mail.<domain>` Prio 10
-- **TXT SPF** `v=spf1 a mx ~all` (o. ä.)
-- **TXT DKIM** `default._domainkey.<domain>` (öffentlicher Key aus dem Container)
-- **TXT DMARC** `_dmarc.<domain>` `v=DMARC1; p=quarantine; ...`
-- **CNAME** `autodiscover` / `autoconfig`
-
-Wichtig: Die Fleet verwaltet nur ihre eigene Domain (`*.<FLEET_DOMAIN>`) per Cloudflare-API. Für **BYOD-Kundendomains** trägt der Kunde diese Records bei **seinem eigenen** DNS-Provider ein — deshalb Blueprint statt API-Call.
-
-DKIM-Key aus dem Container holen:
-```bash
-sudo incus exec c-C-<TRAINEE_USER> -- cat /etc/dkimkeys/<domain>/default.txt 2>/dev/null || \
-sudo incus exec c-C-<TRAINEE_USER> -- opendkim-genkey --help
-```
-
-**Verständnisfrage 5 → `exam-pool.md` → `C_4`** (BYOD Blueprint).

package/skills/bdbsaastraining/references/track-d-debian.md

@@ -1,109 +0,0 @@
-# Track D — Clean Debian / Datenbank / Worker
-
-**Ziel-Workload:** generischer System-Container (PostgreSQL, Redis, BullMQ-Worker, Cron-Jobs …), selbst konfiguriert.
-**Basis-Template:** KEINES — es gibt kein `profile-debian-clean.yaml`. Station 2 = Profil von Grund auf.
-**Container:** `c-D-<TRAINEE_USER>` · **Profil:** `D-<TRAINEE_USER>`
-
-> Hinweis: Das MCP-Schema kennt `template="debian-clean"`, aber `incus_client.create_from_profile` erwartet ein Incus-Profil dieses Namens auf dem Host — das existiert nicht. Deshalb geht Track D bewusst den manuellen `incus profile create/edit`-Weg. Das ist der eigentliche Lernwert: „Custom Profile Engineering".
-
----
-
-## Station 2 — Incus Profile von Grund auf (Track D)
-
-### 2.1 Vergleichsbasis
-Der Trainee öffnet EIN mitgeliefertes Template (z. B. `profile-ai-agent.yaml`) nur als Formvorlage und markiert, was für einen minimalen DB-Container **weg** kann (nodejs, npm, build-essential, rbash-User).
-
-### 2.2 Interview → minimales Profil
-- Workload-Art: PostgreSQL / Redis / Node-Worker (BullMQ) / „nur Debian, ich installiere selbst"
-- RAM: 1 / 2 / 4 GiB (Node-Limit ≤ 8)
-- CPU-Kerne: 1 / 2 · CPU-Deckel: `limits.cpu.allowance` 50% / 100%
-- Disk-Quota: 10 / 20 / 30 GiB
-- Persistenter Datenpfad als eigenes `devices:`-Disk (empfohlen für DB): ja / nein
-
-```bash
-python3 ~/.agents/skills/bdbsaastraining/scripts/build_profile.py \
-    --track D --user <TRAINEE_USER> \
-    --workload postgres --ram 2 --cpu 2 --cpu-allowance 50 --disk 20 --data-device yes
-```
-Ergebnis-Skelett (illustrativ, real generiert der Generator):
-```yaml
-config:
-  limits.cpu: "2"
-  limits.cpu.allowance: 50%
-  limits.memory: 2GiB
-  cloud-init.user-data: |
-    #cloud-config
-    package_update: true
-    packages: [postgresql, postgresql-client]
-    runcmd:
-      - systemctl enable --now postgresql
-description: "RC Cloud Clean Debian — postgres (D-<TRAINEE_USER>)"
-devices:
-  data:
-    type: disk
-    pool: default
-    source: ""
-    path: /var/lib/postgresql
-    size: 20GiB
-```
-
-### 2.3 Registrieren & prüfen
-```bash
-sudo incus profile create D-<TRAINEE_USER>
-sudo incus profile edit D-<TRAINEE_USER> < ~/profile-D-<TRAINEE_USER>.yaml
-sudo incus profile show D-<TRAINEE_USER>
-```
-
-**Verständnisfrage 2 → `exam-pool.md` → `D_1`** (Profil von Grund auf) oder `D_4` (limits.cpu.allowance).
-
----
-
-## Station 3 — Deployment & Verify (Track D)
-
-```bash
-sudo incus launch images:debian/13 c-D-<TRAINEE_USER> -p default -p D-<TRAINEE_USER>
-sudo incus exec c-D-<TRAINEE_USER> -- cloud-init status --wait
-```
-Verifikation je nach Workload:
-```bash
-# postgres:
-sudo incus exec c-D-<TRAINEE_USER> -- sudo -u postgres psql -c "SELECT version();"
-# redis:
-sudo incus exec c-D-<TRAINEE_USER> -- redis-cli ping
-# quota-check:
-sudo incus config show c-D-<TRAINEE_USER> | grep -E 'limits|size'
-```
-
-**Verständnisfrage 3 → `exam-pool.md` → `D_2`** (Snapshot/Migration).
-
----
-
-## Station 4 — FastMCP & Guardrails
-
-Gemeinsamer Ablauf. Track-D-Betonung: Lifecycle über MCP —
-```
-remoteos_manage_instance(container_name="c-D-<TRAINEE_USER>", action="stop",  reason="Bootcamp D Lifecycle-Test")
-remoteos_manage_instance(container_name="c-D-<TRAINEE_USER>", action="start", reason="Bootcamp D Lifecycle-Test")
-```
-`start`/`stop` → sofort (`RiskLevel.STAGING`). `restart`/`delete` → Queue.
-
-**Track-Fragen:** `D_1`, `D_2`, `D_3`, `D_4`.
-
----
-
-## Station 5 — Bewusst KEINE öffentliche Route (Track D)
-
-Ein DB/Worker-Container gehört **nicht** ins öffentliche Internet. Zwei Optionen:
-
-**Option 1 — nur intern über die Bridge:** Die App im selben Netz erreicht die DB über die Container-IP auf `incusbr0`. Nichts weiter zu tun.
-
-**Option 2 — gezieltes Port-Forwarding zum Host (kein Caddy, kein DNS):**
-```bash
-sudo incus config device add c-D-<TRAINEE_USER> pg proxy \
-    listen=tcp:127.0.0.1:15432 connect=tcp:127.0.0.1:5432
-```
-→ DB nur auf `127.0.0.1:15432` des Hosts, erreichbar für lokale Prozesse / SSH-Tunnel, nie extern.
-
-Wenn der Trainee doch eine Admin-Weboberfläche (pgAdmin) exponieren will → wie Track B, aber `require_auth=True` ist Pflicht und Cloudflare `🟠 proxied`.
-
-**Verständnisfrage 5 → `exam-pool.md` → `D_3`** (keine öffentliche Route für DB).

package/skills/bdbsaastraining/references/track-e-custom.md

@@ -1,83 +0,0 @@
-# Track E — Custom Workload (frei beschrieben)
-
-**Auslöser:** Der Trainee hat in Station 0 „Other" / `E)` gewählt und seinen Workload in eigenen Worten beschrieben.
-**Ziel:** Aus dem Freitext ein reales, valides Incus-Profil ableiten und das Training an den passenden Basis-Track andocken.
-
----
-
-## E.0 — Interview (nach dem Freitext)
-
-Frage strukturiert nach, was im Freitext fehlt. Nutze `AskUserQuestion` / Text-Schema:
-
-1. **Grundcharakter** → bestimmt das Basis-Muster:
-   - „öffentlich per HTTP(S) erreichbar, mit Login" → **B-Muster** (Caddy + Authelia + Cloudflare proxied)
-   - „E-Mail / SMTP / IMAP" → **C-Muster** (DNS-Blueprint, DNS-only)
-   - „nur intern / Datenbank / Worker / Batch" → **D-Muster** (keine öffentliche Route)
-   - „autonome Agenten / Code-Ausführung" → **A-Muster** (rbash, ai_agents, agent-sudo)
-2. **Ressourcen:** RAM (1–8 GiB), CPU (1–2), CPU-Deckel (50/100 %), Disk (10–60 GiB)
-3. **Pakete:** welche Dienste/Runtimes? (Freitext-Liste, Generator validiert gegen Debian-13-Paketnamen und warnt bei Unbekanntem)
-4. **Ports:** welche TCP-Ports lauscht der Dienst? intern / öffentlich?
-5. **Auth:** braucht der öffentliche Endpunkt Authelia-2FA? (Default: ja, wenn öffentlich)
-6. **Persistenz:** eigener Daten-`devices:`-Block? (Default ja bei DB-artigen Workloads)
-
-Speichere: `<E_BASE>` ∈ {A, B, C, D}.
-
----
-
-## E.1 — Profil generieren
-
-```bash
-python3 ~/.agents/skills/bdbsaastraining/scripts/build_profile.py \
-    --track E --user <TRAINEE_USER> \
-    --base <E_BASE> \
-    --ram <N> --cpu <N> --cpu-allowance <50|100> --disk <N> \
-    --packages "pkg1,pkg2,pkg3" \
-    --ports "8000/public,9000/internal" \
-    --auth <yes|no> --data-device <yes|no> \
-    --describe "<originaler Freitext des Trainees>"
-```
-
-Der Generator:
-- nimmt das `<E_BASE>`-Template als Ausgangsbasis (bzw. ein Minimal-Skelett bei `--base D`),
-- ersetzt `packages:` durch die validierte Liste,
-- setzt `limits.*` aus den Sizing-Antworten,
-- **warnt** (nicht abbricht) bei: `ram > 8`, `disk > 100`, unbekannten Paketnamen, öffentlichem Port ohne `--auth yes`,
-- entfernt Top-Level `name:`,
-- schreibt `~/profile-E-<TRAINEE_USER>.yaml` + zeilenweise Erklärung + Liste aller Warnungen.
-
-Bei `ram > 8`: Hinweis, dass der Primary-Node (`ram_gb ≤ 8` im MCP-Schema) das nicht trägt → Workload auf Auxiliary-Node (Oracle, 24 GB) planen.
-
----
-
-## E.2 — Station 2 / 3 / 5 nach Basis-Muster
-
-Ab hier folgst du der Datei des Basis-Tracks `<E_BASE>` für Struktur und Befehle, aber mit den Custom-Werten:
-
-| `<E_BASE>` | Station 2/3 wie | Station 5 wie |
-| :-- | :-- | :-- |
-| A | `track-a-ai-agent.md` (rbash-User, Sandbox-Task) | interne Gateway-Route, `require_auth=True` |
-| B | `track-b-wordpress.md` (Stack-Verify per `curl`) | öffentliche Route, Caddy forward_auth, CF `🟠 proxied` |
-| C | `track-c-mailserver.md` (`postconf`, Ports) | `remoteos_get_dns_blueprint(service_type="mail")`, `⚪ DNS-only` |
-| D | `track-d-debian.md` (minimal, Quotas, Snapshot) | keine öffentliche Route / `incus proxy` Device |
-
-Container-Name: `c-E-<TRAINEE_USER>` · Profil: `E-<TRAINEE_USER>`.
-
-Verifikation immer zuerst:
-```bash
-sudo incus profile show E-<TRAINEE_USER>
-sudo incus launch images:debian/13 c-E-<TRAINEE_USER> -p default -p E-<TRAINEE_USER>
-sudo incus exec c-E-<TRAINEE_USER> -- cloud-init status --wait
-```
-
----
-
-## E.3 — Station 4 (gemeinsam)
-
-Wie in `SKILL.md`, mit `container_name="c-E-<TRAINEE_USER>"` und Pflichtfeld `reason`.
-
----
-
-## Prüfung — Track E
-
-**Track-Fragen:** `E_1`, `E_2`, `E_3`, `E_4` (aus `exam-pool.md`).
-Zusätzlich: Wenn `<E_BASE>` z. B. `B` war, darf der Tutor bis zu 2 der 4 Track-Fragen durch passende `B_*`-Fragen ersetzen, damit die Prüfung zum tatsächlich Gelernten passt. Immer 6 Kern + 4 Track = 10.