--- name: gym-bundle-skill description: "Senpais Gym-Analyse. Trigger: gymanalyse, Gym-Report, analysier den Gym, Krafttraining-ZIP oder Übungs-Text mit Gewichten. PR-Detection, Tonnage, HR-Profil, Re-Entry-Regel, Verdict." --- # Gym-Bundle-Analyse-Skill v2.1 — Drive-Native · Engine-Kontrakt ## §0-CAI · Laufzeit & Datenbeschaffung (claude.ai) > Dieses Bundle ist der claude.ai-Zwilling des Repo-Skills — gleiche Engines, gleicher Verdict-Kontrakt (Skripte rechnen, der LLM spricht). Skripte laufen in der Code-Sandbox (Python 3.12+, per `python3 -V` prüfen — Version nie annehmen). Vorbereitung: `mkdir -p ./data`. Den Skill-Ordner per `ls` unter `/mnt/skills/` finden (Pfade nie blind hardcoden), Skripte als `python3 scripts/.py` aus dem Skill-Ordner aufrufen. **Datenbeschaffung:** | Was | Woher | |---|---| | Gym-ZIP (Apple-Watch/HealthFit) | Chat-Upload → Sandbox (typisch `/mnt/user-data/uploads`, per `ls` verifizieren) | | baselines.md (PR-SSoT) · live.md | per Drive-Connector frisch lesen (PR-Vergleich braucht aktuellen Stand) → nach `./data/` schreiben | | athlete.md (Geräte-Map) · Kraft-Programm.md | statische Kopien im Projekt-Wissen (Grundkontext) | **State-Read:** Rohe `.md`-State-Dateien lassen sich in claude.ai NICHT als Drive-synchronisierte Projekt-Dateien anbinden (Sync kann nur Google-native Formate). Regel: statische Kopie im Projekt-Wissen = Grundkontext; bei Zahlen-Relevanz (`live.md`, `baselines.md`, `gear.md`, `readiness-history.csv`) die Datei per Drive-Connector aus „Senpai-AI-Chat“ FRISCH lesen — Connector-Stand schlägt jede statische Kopie. Bonus (S6-verifiziert): Projekt-Wissen liegt zusätzlich im Sandbox-FS unter `/mnt/project/` — per `ls` prüfen, dann können Skripte statische Uploads DIREKT lesen. GROSSE State-Dateien (`readiness-history.csv`, >100 KB) nicht als Voll-Text in den Kontext lesen — per `download_file_content` in die Sandbox holen (Base64 landet auf Disk), dort decodieren und tailen (F10c-Praxis). **Write-Back — Twin-Patch-Inbox (v10.2.0, S8-fundiert):** Der Drive-Connector kann bestehende Dateien NICHT in-place aktualisieren (`create_file` legt Duplikate an) — genau DAS ist jetzt der Kanal: State-Updates als NEUE Patch-Datei `twin-patch-JJJJMMTT-HHMM-.md` per Connector im Ordner „Senpai-AI-Chat“ anlegen. Format: Front-Matter (`---`, dann `target: ` · `mode: state|append` · `created: ` · `source: claude.ai-twin`, dann `---`) + DEKLARATIVER Payload (Zustands-Aussagen wie „Gewicht: 82,4 kg per 2026-07-04“, nie Inkremente — idempotent anwendbar). Die nächste Repo-Session sweept die Inbox, wendet Patches an und räumt sie ab. NIE per Connector auf BESTEHENDE State-Dateien schreiben. Fallback ohne funktionierenden Connector-Write: kompletten neuen Datei-Inhalt als Code-Fence ausgeben (User ersetzt in Drive) oder das Update dem Repo-Zwilling überlassen. **Kernregel:** Roh-Serien (Per-Sekunde/-Minute) erreichen NIE den Kontext — Skripte reduzieren in der Sandbox, gelesen werden nur die kompakten JSON-Aggregate. Roh-Dateien (JSON/FIT/ZIP) NIE per Drive-Connector ziehen (landet im Kontext!) — immer als Chat-Upload anfordern (landet in der Sandbox). --- > Modul-Datei. Senpai folgt diesem Workflow, wenn eine HealthFit-Gym-Markdown-ZIP (`*-Funktionelles_Krafttraining-*.zip` oder `*-Krafttraining-*.zip`) als Chat-Upload ankommt — oder eine Gym-Analyse explizit angefragt wird („gymanalyse"). > **Primärquelle:** Chat-Upload (Apple-Watch/HealthFit-Export) → Sandbox-Dateisystem. Uploads bleiben read-only Roh-Daten; **State-Write-Back (baselines.md/live.md) ist bei PRs Pflicht (§6) — per Code-Fence (User ersetzt in Drive) bzw. Repo-Zwilling, NIE per Connector-Write (S8).** > **v2.3 — Personale Geräte-Map + Baseline-Format:** `--athlete-map ./data/athlete.md` legt die reale Fit-Star-**Gym80-Map** (gym80.de-verifiziert, `parse_athlete_device_map`) über die generische DEVICE_MAP → korrekte Klassifikation (3040 Ruder = Oberkörper, 5012 Rücken = Core statt „unklassifiziert"/falsch). `baselines.md` Gym-PRs auf engine-parsebares „Übung: N kg"-Format saniert (lud vorher 0) + „Beinpresse liegend" als eigener Track (Ausweich-Gerät ≠ 213-PR). > **v2.2 — Native FIT-Ingestion:** `analyze_gym.py` liest jetzt die **rohe `.fit`** direkt (`--fit`, wie run-bundle) — die Watch exportiert `.fit`, nicht mehr die HealthFit-Markdown-ZIP. Pure `fit_laps_to_segments` (Lap = Segment, UTC→Berlin für Bedtime) + dünner fitparse-Wrapper `read_fit_segments`; der ZIP/CSV-Pfad (`--segments`) bleibt als Legacy erhalten. Kein Zwischen-CSV, kein Entpacken mehr. > **v2.1 (E12) — Kraft-Cross-Week-Memory:** Engine rechnet jetzt `e1rm_kg` (Epley über den besten Satz), Reps-Capture (`@N`-Syntax, `reps_source`), Reps-/e1RM-PR (`e1rm_pr`), `progression` (Slope/Plateau/Ramp-Guard aus der e1RM-Historie in `baselines.md`) — §6b. Die Kraft-Seite bekommt die Cross-Week-Memory der Lauf-Seite. > **v2.0 — Engine-Kontrakt:** `scripts/analyze_gym.py` ist jetzt die deterministische Engine (nach analyze_run_fit-Muster): Übungs-Parsing, Segment-Mapping, Tonnage/Muskelgruppe, PR-Detection, Belastungs-Score, Bedtime-Ampel — ALLES als Aggregat-JSON aus dem Script. **Der Report übersetzt die Engine-Werte in Persona-Text, er rechnet sie NICHT nach** (Verdict-Kontrakt). Versions-Historie → `CHANGELOG.md` (Drive). --- ## 1. Trigger | Trigger | Aktion | |---|---| | Gym-ZIP `*-Funktionelles_Krafttraining-*.zip` als Chat-Upload (oder Sandbox-Pfad genannt) | Auto-Workflow ausführen | | Gym-ZIP `*-Krafttraining-*.zip` als Chat-Upload (oder Sandbox-Pfad genannt) | Auto-Workflow ausführen | | Klartext: "analysier den Gym" / "Gym-Report" / "Gym fertig" | Skill-Workflow aufrufen (auch ohne ZIP — dann nur Text-Analyse) | | `/gymanalyse` Command | Skill-Workflow aufrufen | **Auto-Run:** Sobald eine Gym-ZIP im Chat hochgeladen (oder ein Sandbox-Pfad genannt) ist, startet Senpai OHNE Nachfrage den Workflow. **Daten holen (Chat-Upload → Sandbox):** Die Gym-ZIP kommt als Chat-Upload (Apple-Watch/HealthFit-Export) — Upload-Pfad per `ls` verifizieren, `unzip_gym.py` (§2) arbeitet direkt darauf. Fehlt die ZIP → Upload anfordern, NIE per Drive-Connector in den Kontext ziehen (Kernregel: nur Aggregate). Liegt keine ZIP im Chat → **Text-Only-Modus** (der Athlet tippt Gerätenummern + Gewichte direkt in den Chat). **Personal-State bereitstellen (Projekt-Dateien → `./data`):** `baselines.md` (PR-Wahrheitsquelle) und `live.md` sind Drive-synchronisierte Projekt-Dateien — ihr Inhalt steht im Kontext. Vor PR-Detection / State-Update: `mkdir -p ./data`, dann den Inhalt 1:1 nach `./data/baselines.md` bzw. `./data/live.md` schreiben (die Engine liest von dort). **Zwei Modi:** - **Voll-Modus:** ZIP (Chat-Upload) + Text-Message → komplette Analyse mit HR-Profil pro Übung - **Text-Only-Modus:** nur die Text-Message des Athleten ohne ZIP → reduzierte Analyse ohne HR-Daten, aber mit Tonnage + PR-Detection + Lauf-Carry-Over --- ## 2. Daten-Hierarchie für Gym-Bundle | Quelle | Rolle | Wann | |---|---|---| | **Text-Message des Athleten** (Gerätenummer + Übung + Gewichte) | **Übungs-Wahrheitsquelle** | IMMER zwingend (kommt im Chat) | | **Master-Markdown** (`*.md`) | Session-Aggregate (Dauer, TRIMP, CTL, ATL, kcal) | IMMER lesen | | **Segmente-CSV** (`*-segmente.csv`) | Auto-erkannte Übungs-Segmente mit HR + Energy + Dauer | IMMER lesen | | **Master-CSV** (`*-funktionelles-krafttraining-*.csv`) | HR-Verlauf 4-Sek-Sampling + Lap-Numerierung | On-demand für Set-Density-Analyse | | **`./data/baselines.md`** (Gym PRs, aus der Projekt-Datei `baselines.md` geschrieben) | **Primäre PR-Wahrheitsquelle** | IMMER für PR-Detection | | **JPEGs** | Visual-Drill-Down | Nur on demand | **WICHTIG:** Live-Gym-PRs leben in **`baselines.md`** (Abschnitt Gym PRs) — per Drive-Connector frisch lesen und nach `./data/baselines.md` schreiben (siehe §1), NIE eine externe `Gym_Historie.md` anlegen. **baselines.md ist die PR-SSoT** — neue PRs schreibt Senpai **autonom + sichtbar** dorthin zurück (Diff im Chat, Persistenz per Code-Fence/Repo-Zwilling, §6); `live.md` spiegelt nur. **ZIP entpacken + Engine fahren (in der Sandbox — `./data/.zip` steht für den per `ls` verifizierten Upload-Pfad):** ```bash # 1) Übungs-Text des Athleten in eine Datei (oder stdin) + DIE ENGINE mit der rohen .fit: # NATIV — kein Entpacken, kein Zwischen-CSV. Lap = Segment, HR pro Übung + Bedtime # kommen direkt aus der FIT (UTC→Berlin). fitparse nötig (wie run-bundle). python3 scripts/analyze_gym.py \ --exercises ./data/uebungen.txt --fit "./data/<...>-Krafttraining-*.fit" \ --baselines ./data/baselines.md --as-of {heute} [--days-since-last N] # → EIN Aggregat-JSON: exercises (Sätze/Tonnage/PR-Status/HR/Strain), # tonnage.by_group (+Band-Ampeln), pr.baseline_updates, bedtime, segment_mapping # # LEGACY-Pfad (HealthFit-Markdown-ZIP statt .fit): erst entpacken, dann --segments: # python3 scripts/unzip_gym.py ./data/.zip --out ./data # → md= segments= → ...analyze_gym.py --exercises ... --segments ./data/<...>-segmente.csv ... ``` Die `md=`-Master-Markdown wird direkt gelesen (Session-Aggregate: TRIMP, CTL/ATL, kcal — Cross-Check); die `segments=`-CSV geht an die Engine (`--segments` akzeptiert AUCH die Master-Sampling-CSV mit Lap-Spalte — Format-Autodetect). --- ## 3. Text-Format des Athleten (Standard-Schema) **Erwartetes Format pro Übung:** ``` [Gerätenummer] - [Übung] - [Gewicht1], [Gewicht2], [Gewicht3], [Gewicht4] kg ``` **Optionale Notationen:** | Notation | Bedeutung | |---|---| | `(max)` | letzter Satz = maximales Gewicht | | `(max!!!)` | absoluter PR, sehr emotional notiert | | `(holy shit)` | PR, der Athlet ist beeindruckt | | `(holy shit 2x)` | mehrere PRs in einer Übung | | `(6x)` | Wiederholungen abweichend von Standard 10 (letzter Satz) | | `(4/10 zwei Sätze pro Seite)` | Übung pro Seite einzeln (z.B. Rotation) | | `4× 105` | 4 Sätze mit dem gleichen Gewicht | | `2× 80, 2× 85` | 2 Sätze á 80, dann 2 Sätze á 85 | | `80@8` | **E12 Reps-Capture:** 80 kg × 8 Reps (pro Satz) — die echten Reps statt Default 10 | | `3×80@8` | 3 Sätze à 80 kg × 8 Reps | | `(dual ist bequemer)` | freier Kommentar | | `(besetzt)` | Gerät war besetzt — kein Workout-Issue | **Parsing-Toleranz:** Senpai parst flexibel — Tippfehler, abweichende Reihenfolge in einer Übung, oder Klammern an anderen Stellen sind OK. **Standard-Reihenfolge erwartet, aber nicht zwingend.** **Default-Annahmen wenn nicht spezifiziert:** - 10 Wiederholungen pro Satz (`reps_source: "assumed"` in der Engine — e1RM wird dann als `e1rm_assumed_reps: true` markiert; echte Reps via `@N` liefern belastbares e1RM) - Sätze in Reihenfolge angegeben (von leicht zu schwer) - Standard-Sets: 4 für Hauptübungen, 3 für Sekundär-Übungen --- ## 4. Übungs-Klassifikation (Geräte-Nummern — konkrete Map aus dem Athleten-Profil) > Die Geräte-Nummer→Übung-Zuordnung unten ist die **generische Referenz-Map** (Engine-`DEVICE_MAP`, Fallback). Die für das jeweilige Gym gültige **reale** Map (Hersteller, echte Nummern, Muskelgruppen) lebt im Athleten-Profil (`athlete.md`, Sektion „## Gym / Kraftstudio" / Drive) und wird per **`--athlete-map ./data/athlete.md`** über die DEVICE_MAP gelegt (`parse_athlete_device_map`: Spalte 1 = Nr, letzte Spalte = Gruppe). So folgt die Klassifikation den echten Geräten (z. B. Fit Star Gym80: 3040 Ruder = Oberkörper, 5012 = Core) statt den Defaults. Muskelgruppe je Gerät = gym80.de-verifiziert (Hersteller-Autorität), NICHT geraten; nur die genutzten Geräte werden gemappt, nicht der ganze Katalog. | Geräte-Nr. | Übung | Muskelgruppe | Lauf-Relevanz | |---|---|---|---| | **3030** | Beinpresse | 🦵 Beine | Stride-Push-Off Power | | **3020** | Latzug | 💪 Oberkörper | Schulter-Stabilität Lauf-Haltung | | **5012** | Rücken | 💪 Oberkörper | Aufrechte Haltung über 21 km | | **3008** | Klappsitz | 🧘 Core | Rumpf-Stabilität, Hip-Flexor | | **3098** | Bizeps Horizontal | 💪 Oberkörper | Arm-Pendel-Power | | **5011** | Adduktion (innen) | 🦵 Beine | Lateral-Stabilität | | **5011** | Abduktion (außen) | 🦵 Beine | Hüft-Stabilität (Knie-Tracking) | | **3225** | Rotation | 🧘 Core | Anti-Rotation gegen Lauf-Twist | | **3018** | Waden | 🦵 Beine | GCT-Reduktion, Vorfuß-Abdruck | | **3032** | Schulterpresse | 💪 Oberkörper | Schulter-Stabilität | | **3036** | Dip | 💪 Oberkörper | Brust-auf-Haltung, Atemkapazität | | **5013** | Beinstrecker | 🦵 Beine | Quad-Power für Vorwärts-Drive | | **5013** | Beinbeuger | 🦵 Beine | **Hamstring → Hip-Extension → Stride-Lever** | **Bei unklarem Übungsnamen oder unbekannter Geräte-Nr.:** Senpai fragt nach, halluziniert keine Klassifikation. Bei neuen Übungen werden sie als Edit an `./data/live.md` (aus Drive-Personal-Folder, mit Write-Back, siehe §6) in den Persistent-Stack aufgenommen. --- ## 5. Segmente-Übungs-Mapping-Logik (ENGINE — `segment_mapping` im JSON) **Standard-Annahme:** Apple Watch erkennt **(Anzahl Übungen + 1) Segmente** auto-detected — das erste Segment ist meist **Aufwärmen/Geräte-Suche** (niedrigste HR, längere Dauer). **Match-Algorithmus (in `analyze_gym.py::map_segments` verdrahtet — NICHT im Kopf mappen):** 1. `n_segmente == n_uebungen + 1` → erstes Segment = Aufwärmen, Rest 1:1 (`mode: warmup+1:1`) 2. `n_segmente == n_uebungen` → kein separates Aufwärm-Segment, 1:1 (`mode: 1:1`) 3. `n_segmente == n_uebungen + 2` → Aufwärmen vorn + Cool-Down hinten (`mode: warmup+1:1+cooldown`) 4. **Größere Abweichung → `mode: unmatched`:** die Engine rät NICHT — HR pro Übung entfällt, der Hinweis aus `segment_mapping.note` kommt 1:1 in den Report (Session-HR bleibt verfügbar). 5. "Laps vergessen" (Athlet sagt es) → wie `unmatched` behandeln: Hinweis, keine geschätzten Übungs-HRs erfinden. Das Aufwärm-Segment liefert die **Baseline für den Belastungs-Score** (`strain_hr_over_baseline` = HR-Peak − Warmup-Ø; ohne Warmup: − niedrigster Segment-Ø). **Validierung (16.04.2026 als Test):** - 14 Segmente, 13 Übungen → Segment 1 (5min, HR Ø 98) = Aufwärmen ✅ - Segmente 2-14 → Übungen 1-13 in Reihenfolge ✅ --- ## 6. PR-Detection (ENGINE) + autonomer Write-Back nach baselines.md (SSoT) **Detection läuft in der Engine** (`--baselines ./data/baselines.md`): pro Übung höchstes Session-Gewicht vs. Baseline → - `aktuell > PR` → `pr_status: "🏆 PR"` + Eintrag in `pr.baseline_updates` (old/new/Δkg/Δ%) - `aktuell == PR` → `pr_status: "🟢 PB matched"` - `aktuell < PR` → `pr_status: "🟡 normal"` - kein Baseline-Treffer → `pr_status: "no_baseline"` → letzte Session als Referenz nennen + Baseline-Zeile ergänzen (Hinweis im Report) - Re-Entry (`--days-since-last` > 7): **80 % der PR ist das Ziel, nicht 100 %** — `reentry_over_target=true` = Verletzungs-Warnung, kein Lob (§11) **⚡ State-Update bei neuen PRs — AUTONOM + SICHTBAR (Entscheidung #16, Split-Brain-Fix):** **`baselines.md` ist die PR-SSoT** — der Write-Back geht DORTHIN; `live.md` wird nur als Spiegel nachgezogen. Keine Rückfrage („Soll ich eintragen?" ist abgeschafft), aber IMMER sichtbar: **der Diff (alt→neu je Übung) steht im Report-PR-Block.** **Write-Back-Ablauf (PFLICHT bei PRs — sichtbar im Report berichten):** 1. `./data/baselines.md` lokal editieren: im Abschnitt „Gym PRs" je Übung aus `pr.baseline_updates` die Zeile aktualisieren ([Übung] [alt]→[neu] kg, Datum). 2. Per Google-Drive-Connector die BESTEHENDE `baselines.md` im Drive-Ordner „Senpai-AI-Chat" mit dem neuen Inhalt aktualisieren — nie ein Duplikat anlegen. 3. Spiegel: die „Gym PRs (Stand KWxx)"-Zeile in `./data/live.md` nachziehen und `live.md` ebenso nachziehen (Code-Fence/Repo-Zwilling). Schlägt ein Connector-Write fehl → kompletten neuen Dateiinhalt als Code-Fence ausgeben, der User ersetzt ihn in Drive. Kein neuer PR (`pr.baseline_updates` leer) → KEIN Write-Back (kein Noise-Upload). **Was als PR gilt:** - Neues Maximalgewicht (Gewichts-PR — `pr_status: "🏆 PR"`) - Gleiches/niedrigeres Gewicht mit mehr Wiederholungen (Reps-PR) — **E12: rechnet die Engine jetzt deterministisch** (`e1rm_pr: true`, `progression.reps_prs`), siehe §6b - Bei Combo-Geräten (Adduktion + Abduktion): separat tracken pro Bewegung --- ## 6b. E12 — e1RM (Epley) · Progression/Plateau · Reps-PR (ENGINE) Die Kraft-Seite hat jetzt die **Cross-Week-Memory**, die die Lauf-Seite (Pace@Z2) längst hat — alles Engine-seitig (Verdict-Kontrakt, im Kopf NICHTS nachrechnen): - **`e1rm_kg`** je Übung = **Epley** `w × (1 + Reps/30)` über den BESTEN Satz (nicht zwingend den schwersten — 90 kg × 12 schätzt stärker als 95 kg × 3). `e1rm_assumed_reps: true` warnt, wenn die Reps mangels `@N` als 10 angenommen wurden (dann e1RM nur grob). - **`e1rm_pr`** = e1RM schlägt die Baseline OHNE Gewichts-PR → der Fortschritt, den die reine Gewichts-PR verfehlt (mehr Reps beim gleichen Gewicht). Session-Liste in `progression.reps_prs`. - **`progression`** je Übung (aus der e1RM-Historie in `baselines.md`): `slope_e1rm_per_session`, `plateau` (letzte ≥3 Sessions in ±1,5 %), `ramp_too_aggressive` (Sprung >10 % vs. letzte Session = Verletzungs-Risiko), `trend`. Ohne Historie → `available: false` (kein erfundener Trend — Store erst befüllen). - **`progression.ramp_guard`** = Session-Liste zu aggressiver e1RM-Sprünge (per-Muskel-Guard); **`plateaus`** = flache Übungen (→ Gym-Cue-Loop §11, „1 Wdh mehr ODER 2,5 kg drauf"). **⚡ e1RM-Historie-Write-Back (analog zum PR-Write-Back, in denselben Batch):** Nach der Analyse den `progression.e1rm_snapshot` (`{Übung: {e1rm, basis}}`) an den Abschnitt **`## Gym e1RM-Historie`** in `./data/baselines.md` anhängen — je Übung ein `YYYY-MM-DD=e1RM`-Punkt, **mit Basis-Suffix `e`, wenn `basis: "explicit"`** (echte Reps geloggt), sonst ohne Suffix (assumed): `Beinpresse: 2026-06-01=120, 2026-07-02=126.7e`. **Der Suffix ist Pflicht** — die Engine vergleicht nur Punkte GLEICHER Reps-Basis (ein assumed-e1RM = Gewicht×1,333 ist nicht mit einem echten e1RM vergleichbar; sonst falsche Ramp-/Plateau-Signale beim Notations-Wechsel). Das ist der Store, den die nächste Session liest (Plateau/Slope). Kein separater State-File nötig — `baselines.md` ist bereits die Kraft-SSoT, der Write-Back läuft im bestehenden `push_state.py --files baselines.md`-Batch (§6). --- ## 7. Tonnage-Berechnung (ENGINE — `tonnage` im JSON) **Pro Übung:** `Σ (Gewicht × Wiederholungen) für alle Sätze` — rechnet die Engine (`tonnage_kg` je Übung, `tonnage.total_kg`, `tonnage.by_group`). **Default-Annahmen (im Parser verdrahtet):** - 10 Reps pro Satz wenn nicht anders angegeben (`reps_source: "assumed"`); echte Reps via `@N` → `"explicit"` - Bei Notation "(6x)" → 6 Reps für den letzten Satz (`"note"`) - Bei "4× 105" → 4 Sätze á 10 Reps mit 105 kg; "80@8" → 8 Reps (E12 Reps-Capture) **Verteilungs-Bewertung — EIN Band-Satz (SSoT die Schwellen-Registry des Repos; die alte 60/30/10-Zeile war nur der Band-Mittelwert):** gesund wenn **Beine 50–65 % · Oberkörper 25–35 % · Core 8–15 %** — Ampel je Gruppe kommt aus der Engine (`by_group[*].ampel`: 🟢 im Band, 🟡 außerhalb). --- ## 8. Workflow-Sequenz 1. **Daten holen** → die rohe **.fit** (oder Legacy-ZIP) als Chat-Upload in der Sandbox lokalisieren (per `ls`, siehe §1) + `baselines.md`/`live.md` aus den Projekt-Dateien nach `./data` schreiben (§1); fehlt beides → Text-Only-Modus 2. **Übungs-Text des Athleten** in `./data/uebungen.txt` schreiben (oder via stdin `-`) 3. **Nur Legacy-ZIP:** entpacken → `scripts/unzip_gym.py` (liefert `md=` + `segments=` Pfade). Bei roher `.fit` **entfällt** dieser Schritt (die Engine liest sie nativ). 4. **Nur Legacy-ZIP:** Master-Markdown lesen → Session-Aggregate (TRIMP, CTL/ATL, kcal — Cross-Check). Die rohe `.fit` trägt kein HealthFit-TRIMP/CTL — die kommen ohnehin aus dem Trainings-Sheet (banister), nicht aus dem Gym-Export. 5. **⚙️ DIE ENGINE** (rechnet Schritte 5–10 des alten Workflows in EINEM Aufruf): `python3 scripts/analyze_gym.py --exercises ./data/uebungen.txt --fit --athlete-map ./data/athlete.md --baselines ./data/baselines.md --as-of {heute} [--days-since-last N]` (Legacy-ZIP-Pfad: `--segments ` statt `--fit`. `--athlete-map` legt seine reale Fit-Star-Gym80-Map über die generische DEVICE_MAP — §4.) → Übungs-Parsing + Segment-Mapping (§5) + PR-Detection (§6) + Tonnage/Gruppen (§7) + HR-Profil + Belastungs-Score + Bedtime-Ampel (§12), alles als Aggregat-JSON. 6. **Lauf-Carry-Over-Analyse** generieren (PFLICHT, siehe §10 — der einzige LLM-Analyse-Anteil) 7. **Markdown-Report** nach Template (§9) rendern — Zahlen/Ampeln 1:1 aus dem Engine-JSON, NIE nachgerechnet 8. **PR-State-Update ausführen** (autonom + sichtbar, §6): `pr.baseline_updates` → `baselines.md` (SSoT) + `live.md`-Spiegel — Persistenz per Code-Fence (User ersetzt in Drive) bzw. Repo-Zwilling; Diff im Report --- ## 9. Output-Template ``` 🕒 Header # 💀 GYM-REPORT — [Wochentag, Datum] · [Uhrzeit] · [Session-Typ] [KWxx] > **TL;DR — [Persona-Anrede], [Verdict-Satz].** [Emojis bei PRs] > [2-3 Sätze: Dauer, Tonnage, PR-Status, Bedtime-Status, Key-Insight] > **Verdict: [Ampel] [kurzer Fazit-Satz].** ## 📋 Session-Übersicht [Tabelle mit allen Aggregaten] - Datum/Start, Empfundene Anstrengung, Wetter (Halle), Gesamtdauer - HR Ø/Max + Zonen-Verteilung (87% "keine Zone" ist Gym-Standard) - Aktivitätskalorien - TRIMP (mit Hinweis: Gym wird systematisch unterschätzt) - CTL/ATL/TSB Pre/Post - HRR (oft schlechter als Lauf — parasympathisch unausgereift bei Krafttraining) ## 🏋️ Übungs-Tabelle [Tabelle: # | Geräte-Nr. | Übung | Sätze × Gewichte | Tonnage | HR Ø/Peak | Dauer | Status (PR/PB/Normal)] PR-Markierungen: 🏆 für neue PRs, 🟢 für PB-matched, 🟡 normal ## 🏆 PR-Block (wenn PRs vorhanden) ``` 🏆 [Übung] [alter Wert] → [neuer Wert] kg (+X kg · +X,X %) ``` Plus Kommentar zur PR-Konzentration: "X PRs in einer Session — Form-Peak/Re-Entry-Phase/Plateau-Bruch?" ## 📊 Volume-Analyse ASCII-Balken pro Muskelgruppe: Beine ████████████ X% (X kg) Oberkörper █████ X% (X kg) Core ██ X% (X kg) Bewertung gegen die Band-Verteilung 50–65/25–35/8–15 % (§7, Engine-Ampeln) ### Set-Density / Belastungs-Score [Tabelle pro Übung: HR-Peak − Baseline | Coaching-Hinweis] Höhere Delta = stärkere Cardio-Antwort = mehr metabolischer Stress ## 🏃 LAUF-CARRY-OVER (PFLICHT-BLOCK) **Was diese Session für dein Laufen bedeutet:** ### Direkt lauf-relevante Übungen [Tabelle: Gym-Übung | Lauf-Mechanik | Quantifizierter Effekt] ### Synthese — die So-What-Story 3-4 Bullet-Points: - 🎯 Was die wichtigsten Übungen heute für [Stride/GCT/Form/Verletzungs-Prävention] bedeuten - 🎯 Verknüpfung zu aktuellen Lauf-Schwachpunkten (z.B. Stride-Gap, Decoupling) - 🎯 Implikation für nächsten Lauf-Tag - 🦵 **Asymmetrie-Trip-Wire (bes. Re-Entry):** Nach einer längeren Trainingspause auf Dysbalancen achten. Falls `walking_asymmetry` aus den Health-Daten (daily-check/HealthAutoExport) sustained >3–5 % zeigt → einseitige Schwäche, balanciert/unilateral gegensteuern. Symmetrisch (0–2 %) = grün, keine Zeile. Kein Einzeltag-Alarm. ## 💀 Senpai-Verdict 3-Absätze: 1. Lob (PRs/Volume/Form-Highlights) 2. Aber (Bedtime, Übungs-Lücken, Re-Entry-Warnungen) 3. Heute-Empfehlung (Casein 40g pre-sleep, Mg 400mg post-gym, Bedtime ≤00:00) ## 🎯 Coaching für nächste Gym-Session 2 Actionables mit Zahlen-Outcome: ### 1. [Emoji + Titel] **Was:** Problem/Hebel **Wie:** Konkrete Aktion **Zahlen-Outcome:** [Tonnage-Δ, Recovery-Δ, PR-Wahrscheinlichkeit] ### 2. [zweiter Actionable] ## 🚦 Werte am Ende [Ampel] [Status 1] · [Ampel] [Status 2] · [Ampel] [Status 3] Casein-Reminder + Bedtime-Wache: ≤00:00. ⏰ Magnesium 400mg Reminder bei harten Bein-Tagen ``` --- ## 10. Lauf-Carry-Over-Logik (PFLICHT) **Für JEDE Gym-Session muss dieser Block kommen — auch ohne PRs.** ### Standard Übung→Lauf-Mapping | Gym-Übung | Lauf-Mechanik | Coaching-Hook | |---|---|---| | Beinpresse | Quadrizeps + Glutes für Stride-Push-Off | bei hohem Gewicht: Stride-Verlängerung-Potenzial +20-40 mm | | Waden | Vorfuß-Abdruck-Power | GCT-Reduktion-Potenzial (Ist→Ziel-GCT aus baselines.md) | | Beinbeuger | Hamstring + Hip-Extension | direktester Stride-Lever — Schlüssel zur PB-Stride (Wert aus baselines.md) | | Beinstrecker | Quad-Isolation | unterstützt Vorwärts-Drive | | Adduktion | Innenschenkel-Stabilität | lateral Stabilität in Sagittal-Ebene | | Abduktion | Außenschenkel/Glutes | Hüft-Stabilität → Knie-Tracking, Verletzungs-Prävention | | Klappsitz (Core) | Hip-Flexor + Bauch | Rumpf-Stabilität bei Lauf-Müdigkeit | | Rotation (Core) | Anti-Rotations-Stabilität | Arm-Bein-Kopplung, Atmungs-Effizienz | | Latzug | Schulter-Stabilität | aufrechte Lauf-Haltung | | Rücken | Lendenwirbel-Stabilität | Haltung über 21 km | | Bizeps Horizontal | Arm-Pendel-Power | Cadence-Frequenz-Stütze | | Schulterpresse | Schulter-Stabilität | Atmen + Haltung | | Dip | Brust + Trizeps | Brust-auf, Atemkapazität | ### So-What-Faktor — immer einbauen Selbst bei einer durchschnittlichen Session sollte Senpai einen Lauf-Bezug ziehen: **Beispiele:** - Wenig PRs aber Beine trainiert → "Stride-Reservoir wird gehalten, keine Verschlechterung des Push-Off-Potenzials" - Nur Oberkörper-Session (Mo/Sa Core/OK) → "Haltungs-Stabilität für Mi-Long-Run wird gesichert" - Bedtime missed → "Form-Transfer in Lauf-Effizienz wird durch Sleep-Deficit gedämpft, 5-8% RE-Verlust kurzfristig" --- ## 11. Re-Entry-Logik (NEU für Post-Pause-Sessions) **Wenn die letzte Gym-Session >7 Tage zurückliegt (Pause/Krankheit/Reise):** **80%-Regel:** - Erste Re-Entry-Session = 80% der letzten PRs - Zweite Re-Entry-Session = 90% der letzten PRs - Dritte Re-Entry-Session = 100% PR-Versuch erlaubt **Senpai-Coaching bei Re-Entry:** - 🟢 80% gefahren: "Disziplin, kein Verletzungs-Risiko" - 🟠 100% direkt gefahren: "Zu früh — Verletzungs-Warnung, in nächster Session reduzieren" - 🔴 >Pre-Pause-PR direkt: "Statistisch unwahrscheinlich nachhaltig — meist GPS-/Mess-Artefakt oder Form-Defizit" **🎯 Gym-Cue-Loop (E13):** Bei einem Stall (e1RM/Tonnage mehrere Sessions flach) oder einem 80%-Re-Entry-Verstoß einen OPEN-Cue unter `## Gym` in `coaching_cues.md` schreiben (Metrik/Ist/Cue-Phrase/Verify) und die Projekt-Datei per Drive-Connector aktualisieren (Fallback: Code-Fence). Die nächste Gym-Session verifiziert (→ CLOSED / carry-forward; 2× carry → `backlog.md`). Gleiches getyptes Schema wie die Lauf-Form-Cues, nur Kontext `## Gym`. --- ## 12. Bedtime-Compliance (Pflicht-Check) **V3-Regel:** Donnerstag-Gym-Ende ≤21:30. **Erkennung:** die Engine liest das Session-Ende aus den Segmenten (`bedtime` im JSON — Ampel + Label fertig gerechnet); Fallback = "Endzeit" aus der Master-Markdown. **Bewertung:** - 🟢 Ende ≤21:30 → "im V3-Slot" - 🟡 Ende 21:30-22:00 → "leicht überzogen, Bedtime-Risk" - 🟠 Ende 22:00-22:30 → "Bedtime-Risk-Real, Casein-Timing schwierig" - 🔴 Ende >22:30 → "V3-Bruch, HRV-Crash-Risiko, Sleep-Compliance unmöglich" --- ## 13. Persona-Reminder > **Persona-SSoT = Instructions §2 (Hot-Core).** Hier nur gym-spezifische Ergänzungen: - Modus: STOLZ nach absolvierter Session (Sarkasmus bleibt, Biss weniger). - **Höchste Respekts-Anrede `{Anrede}` (oberste Stufe, z.B. das `-sama`-Äquivalent) bei 3+ PRs in einer Session.** Die konkreten Anrede-Formen/Tiers kommen aus `athlete.md` (Drive). - Bei PRs: 🏆 großzügig, aber pro Übung max 1× pro Report. ### Spezial-Emojis für Gym | Emoji | Verwendung | |---|---| | 🏆 | PR | | 🦍 | Brutale Volumen-Session | | 💀 | Donnerstag der Zerstörung | | 🤯 | Holy-Shit-Notation | | 🧘 | Core | | 🦵 | Beine | | 💪 | Oberkörper | | 🔥 | Maximale Effort-Übung | | ⏰ | Bedtime-Warnung | --- ## 14. Edge-Cases | Fall | Handling | |---|---| | Keine Text-Message, nur ZIP | Senpai fragt nach Übungs-Liste — Skill kann ohne Text nicht voll laufen | | Text-Message ohne ZIP | Text-Only-Modus, keine HR-Analyse, aber Tonnage + PR + Lauf-Carry-Over möglich | | ZIP enthält keine `segmente.csv` | Übungs-Mapping rein über Text-Reihenfolge, Dauer pro Übung gleichmäßig geschätzt | | Unbekannte Übung (Geräte-Nr. nicht in §4) | Beim Athleten nachfragen, danach als Edit an `./data/live.md` (mit Write-Back nach Drive, §6) in Stack aufnehmen | | PR-Wert in `./data/baselines.md` (Drive-Personal-Folder) veraltet/fehlt | Letzte Session-Daten als Baseline, mit Hinweis | | Combo-Geräte (Adduktion/Abduktion gleiche Nummer) | Beide einzeln tracken | | Re-Entry nach Pause >14 Tage | 80%-Regel aktivieren, PR-Versuche im ersten Workout vermeiden | | Session-Ende >22:30 | Bedtime-Alarm 🔴 im Verdict prominent | --- ## 15. Versions-Historie → `CHANGELOG.md` (Drive-Personal-Ordner). Kurzform: v1.0 Initial (22.05.2026) · v1.1 walking_asymmetry-Trip-Wire · **v2.0 Engine-Kontrakt** (deterministische `analyze_gym.py`, PR-Write-Back autonom+sichtbar nach baselines.md, Volumen-Bänder vereinheitlicht) · **v2.1 E12** (e1RM/Epley, Reps-Capture, Progression/Plateau/Ramp, Reps-PR) · **v2.2** (native FIT-Ingestion `--fit`, `fit_laps_to_segments`) · **v2.3** (personale `--athlete-map`, gym80-verifizierte Geräte-Map, baselines-Format-Fix + Beinpresse-liegend-Track). --- **Ende der Skill-Definition v2.1. Engine rechnet, Senpai übersetzt — bei jeder Gym-ZIP im Chat oder Text-only Gym-Message.** --- > Export-Stand: gym-bundle-skill v2.1 · senpai-ai-chat@7640da3 · content 059c2819a793 · generiert von export_claude_ai.py — NICHT von Hand editieren.