boehmitools-training/android/docs/SOURCE_ANALYSIS.md

Vollständige Quellenanalyse

Stand: 24. Juli 2026

Untersuchte Lieferobjekte

Archiv	Originaldateien	SHA-256
01-boehmitools-current(1).zip	93	167d0d1b4670cbe6bb7cab10d2b84c315fde6dadc824cf3f7b9d6ccce3d61d1e
02-training-tools-v2.0-bundle.zip	29	b2859ccb86a3915a86e3c64e157c9021f3b713b63b600360419e686f41c8dbee
03-training-app-samples.zip	8	1634f3b83e98d5e5df7d1c56719dede13ed4cf1ce1517a3745cfee0384f93991

Alle enthaltenen Dateien wurden inventarisiert. Die technische Analyse umfasste insbesondere Host-Mounts und Basic Auth, beide Plugin-Backends, Storage- und Vertragsmodule, Plugin-Metadaten, Tests, HTML-Oberflächen, Migrationsdokumentation, beide Planwrapper, beide Legacy-Tracker, Wochen- und Gesamtanalyse sowie die Vorschlagsdatei. Die vollständige Dateiliste liegt unter build-logs/source-files.txt; die maschinenlesbare Datenauswertung unter build-logs/source-audit.json.

Abgleich aktueller Serverstand gegen v2.0-Bundle

Die Quelltexte von plugins/trainingsplan und plugins/trainingstracker sind in beiden Lieferungen inhaltlich identisch. Im entpackten aktuellen Stand kamen durch lokale Python-Testläufe lediglich __pycache__-Dateien hinzu. Die beiden Trainingsplan-Dateien phase-1.json und calihoss-newbie-8-wochen.json sind ebenfalls identisch. Der vollständige Serverstand enthält zusätzlich vier Rezeptplan-Dateien, die nicht zum Umfang dieser Android-App gehören.

Die Host-App mountet die Plugins unter:

• /plugins/trainingsplan
• /plugins/trainingstracker

Die App nutzt ausschließlich diese HTTP-Mounts. Es gibt keinen direkten Dateizugriff.

Pläne und Vertragsversionen

Beide Planwrapper haben revision = 1 und published_revision = 1. Die veröffentlichte Fassung liegt in config, der Entwurf in draft.

Plan	Modus	Wochen	Tage	Blöcke	Platzierungen	Progressionen	Stufen	Katalog
phase-1	tabata	8	6	12	48	31	248	40
calihoss-newbie-8-wochen	sets_reps	8	6	12	48	31	248	27

Jede der 96 Übungsplatzierungen besitzt ein explizites result_schema; alle 496 Progressionsstufen ebenfalls. Tages-, Rotations-, Platzierungs-, Progressions- und Stufen-IDs sind innerhalb ihres jeweiligen Entitätstyps vollständig und eindeutig. Bewegungs-IDs werden absichtlich über mehrere Platzierungen hinweg wiederverwendet und dürfen daher nicht global eindeutig behandelt werden.

Die Beschreibung verwendet die Begriffe plan_schema und training_contract. In den Plan-JSONs heißen die tatsächlichen Felder schema_version = 3 und contract_version = 2. Der Tracker-Health-Endpunkt meldet dieselben Verträge als versions.plan_schema = 3 und versions.training_contract = 2. Die Android-Domäne bildet diese Namensdifferenz explizit ab, statt ein zusätzliches JSON-Feld zu erfinden.

Legacy-Sessions und Migration

Sessiondatei	gelieferte Version	Sessions	Items	positionsbasierte Übungskeys	Freitextergebnisse	result_data v2
phase-1.json	5	10	197	80	40	0
calihoss-newbie-8-wochen.json	1	6	88	48	0	0

Die Testdaten erzwingen damit beide Migrationspfade:

1. dN-rN-eN wird ausschließlich anhand des im Plan mitgelieferten legacy_id in die stabile Platzierungs-ID überführt.
2. Vorhandene Freitextergebnisse werden lokal in result_data Version 2 geparst, ohne den Originaltext vor einer Benutzeränderung zu verwerfen.

Warm-up-, Cooldown- und Stretch-Items besitzen eigene Sequenzschlüssel und werden nicht als Übungsplatzierungen migriert.

Analyse und Vorschläge

Geliefert sind genau eine Wochenanalyse für Woche 1 und genau eine Gesamtanalyse. Beide besitzen status = success und die Antwortbereiche headline, summary, data_quality, metrics, exercise_updates, plan_adjustments, warnings und conclusion.

Die Vorschlagsdatei hat Version 2, gehört zu phase-1, basiert auf published_revision = 1 und enthält zwei offene Vorschläge. Zielreferenzen verwenden stabile Bewegungs-, Progressions- und Stufen-IDs. Der Editor aktualisiert nur den Vorschlagsstatus und navigiert zum Ziel. Er überträgt keinen Vorschlag automatisch in den Entwurf.

API- und Konfliktbefunde

• Hostweite Basic Auth wird vor den Plugin-Routen ausgewertet; nur der exakte Hostpfad /api/health ist ausgenommen.
• Der Session-Patch ersetzt eine komplette Session und prüft die globale Tracker-revision über expected_revision.
• Ein 409 revision_conflict liefert current_revision; es existiert kein serverseitiger Merge-Endpunkt.
• Analyse-POST liefert 200 für einen aktuellen Cachetreffer und 202 für einen neu gestarteten Hintergrundjob.
• Der laufende Analysezustand ist serverseitig persistent und wird über den Statusendpunkt gelesen.
• Planentwurf und Veröffentlichung haben getrennte Revisionen und getrennte Endpunkte.
• Der Server erstellt beim Planlöschen ein Backup. Die Android-App verlässt sich dennoch ausschließlich auf die API und kennt keinen Backup-Dateipfad.

Visuelle Referenz

Keines der drei Archive enthält PNG-, JPEG-, WebP- oder andere Screenshotdateien. Das ist ein Widerspruch zur Aufgabenbeschreibung, die UI-Screenshots als mitgelieferte Referenz nennt. Für die Umsetzung wurden deshalb die beiden mobilen HTML/CSS-Oberflächen vollständig als visuelle und funktionale Referenz ausgewertet. Die native App übernimmt Informationshierarchie, Begriffe und Arbeitsabläufe, nicht DOM-Struktur oder Web-Komponenten.

Bewusst nicht übernommene Web-Funktionen

Der phase-1-Plan deklariert ein Tabata-Format. Entsprechend der App-Vorgabe wird dieser Vertrag angezeigt und für Ergebnisschemata berücksichtigt, aber es wird kein Tabata- oder Trainingstimer implementiert. Ebenso fehlen bewusst RIR, RPE, Technikrating, unterschiedliche Gewichte pro Satz, WebView und direkte OpenAI-Kommunikation.

Verifikation des gelieferten Backends

Die vorhandenen Plugin-Testsets wurden lokal ausgeführt:

11 passed, 8 skipped

Das vollständige Protokoll liegt unter build-logs/backend-plugin-tests.log.