SCHRITT FÜR SCHRITT

Workshop preflight

Diese Checkliste gilt für den vollständigen Workshop mit isoliertem Odoo 20, nicht für den Simulator auf Port 18340. Normal sind zwei Teams, drei sind optional. Einen bestehenden Sechs-Team-Durchgang nicht löschen: in der Trainerkonsole immer einen neuen Durchgang erzeugen.

Wer macht was?

• Die technische Leitung startet auf dem Windows-Trainerlaptop Docker Desktop und in WSL/Ubuntu npm run workshop.
• Die Trainerin oder der Trainer meldet sich im Browser an, erzeugt den neuen Durchgang und verteilt nur Team-Tokens.
• Teilnehmende verwenden Codex oder Claude Code mit ihrem Teamzugang. Kein API-Key und kein Produktiv-Connector sind erlaubt.

Netzwerk

127.0.0.1 bedeutet: Nur derselbe Trainercomputer erreicht Camp. Für andere Laptops braucht es eine bewusst eingerichtete private Trainings-LAN-Freigabe und eine darauf begrenzte Firewall. In einem isolierten Demo-Raum sind kurzlebige Tokens mit ausschliesslich fiktiven Daten über HTTP vertretbar. Ausserhalb dieses klar abgegrenzten privaten Netzes ist HTTPS/TLS nötig. Camp nie ins Internet stellen.

1. Verify Docker Engine/WSL and Node, then npm run workshop. On port 18350,

/health must report status ok, simulated mail, and odoo20 for ERP/calendar. Loopback is the default. Provisioning/unavailable is not ready.

2. In the trainer console, create a new workshop with two teams (or three if deliberately needed). Generate each team's private connection with

CAMP_DATA_DIR=var/workshop20 CAMP_URL=http://127.0.0.1:18350 node scripts/client-config.mjs <team-email>. Use the reachable training-LAN URL and explicit LAN opt-in for other laptops. Distribute only that team's client snippet, never the server's var directory or trainer/native Odoo tokens.

3. In each actual client, call camp_context and a real source read. Confirm

correct team/workshop and Odoo20 sources. A successful auth-status command alone does not prove that an expired model session can refresh.

4. Read-only profiles expose five read tools and cannot create drafts. Writer

profiles may save private drafts immediately; sending and Odoo changes wait for the exact trainer preview/approval. Trainer/reset/restore are not MCP tools.

5. Run the basic real-tool checks before any contradiction: E01 camp_context; E02 read P-1 name/city/email; E03 search Lagerplanung and read sender/subject/first sentence; E04 read only the team's own calendar title/start/end. Confirm actual tool results, not pasted or invented text.
6. Then practise E05 three-source Alpenglühen conflict, E06 mail delivery and reply, E07 shared Odoo calendar appointment, E08 note approval, E09 restricted-profile/injection handling and E10 logical restore. Delivered mail and other teams' calendar copies remain.

Complete the full Camp/DB/filestore drill and recovered-service proof in ODOO.md before the event; Camp-file recovery alone is insufficient.

7. Retain actual, redacted traces from BOTH clients with the real backend. The

in-process client smoke runner is simulation-only; use the native launcher plus live trainer API for the existing Odoo20 server. No model API key is needed.

8. Check the intended network from a second physical laptop. This disposable, synthetic Camp deliberately has no scheduled/off-machine backup (owner decision, 2026-11-08). Keep a reset/new-workshop fallback ready; optional restore drills are teaching exercises, not a production backup service.

Stop on an unexpected production connector, personal account source, filesystem or shell tool in the restricted exercise profile. Real isolated Odoo20 is expected; all its business data must be fictional. Deliberate simulation mode on port 18340 is a separate fallback/development path, not full acceptance.