# 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.