Lars/shinkan-jinkendo
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 3 Wiki Activity
ea7de64061
shinkan-jinkendo/.claude/docs/working/PARALLEL_TRAINING_STREAMS_PREREQ_PROMPT.md
Lars 220a16429c
All checks were successful
Deploy Development / deploy (push) Successful in 39s
Details
Test Suite / pytest-backend (push) Successful in 36s
Details
Test Suite / lint-backend (push) Successful in 0s
Details
Test Suite / build-frontend (push) Successful in 12s
Details
Test Suite / k6 /health Baseline (push) Successful in 33s
Details
Test Suite / playwright-tests (push) Successful in 1m9s
Details
Enhance training unit sections handling and documentation for parallel training streams 
- Updated the backend to improve the fetching and insertion of training unit sections, including a new function for handling section items.
- Added documentation notes regarding the unique constraint on `training_unit_sections` and the implications for parallel training streams.
- Updated frontend components and utility functions to reflect changes in the training planning API and to prepare for future enhancements related to parallel streams.
2026-05-14 22:24:55 +02:00

3.6 KiB
Raw Blame History

Prompt: Vorbereitungs- / Vorarbeit-Session (Performance & Wartung) für „Parallele Trainingsstreams“

Kontext: Du arbeitest in Shinkan Jinkendo (c:\Dev\shinkan-jinkendo). Das Feature Parallele Trainingsstreams / Breakout ist inhaltlich spezifiziert; eine Ist-Analyse und ein risikoarmer Umsetzungsplan liegen persistiert in:

  • .claude/docs/working/PARALLEL_TRAINING_STREAMS_ANALYSIS_AND_IMPLEMENTATION_PLAN.md
  • Fachlich: .claude/docs/functional/PARALLEL_TRAINING_STREAMS_CONCEPT.md
  • Technik-Entwurf: .claude/docs/technical/PARALLEL_TRAINING_STREAMS_SPEC.md

Deine Rolle: Du hast bereits Refaktorierungs- und Wartungsaufgaben mit Fokus Performance, Lesbarkeit und Testbarkeit durchgeführt. In dieser Session geht es nicht darum, das komplette Parallel-Feature zu bauen, sondern um Vorarbeiten („Prerequisites“), die die geplante Komplexitätsauflösung sicherer und billiger machen.

Ziele

  1. Lesepfad Planung vereinheitlichen: backend/routers/training_planning.py ist zentral für _fetch_sections, _replace_unit_sections, _hydrate_training_unit_payload, Klonen, Blueprint-Kopie, apply-training-module. Prüfe, ob klar abgegrenzte Hilfsfunktionen (ohne Verhaltensänderung) die nächste große Änderung erleichtern — keine Feature-Logik für Phasen/Streams hinzufügen, nur Struktur/Tests/Docs wenn nötig.

  2. Test-Lücken schließen (minimal, hoher Nutzen): Heute fehlen DB/API-Tests für kritische Pfade (_replace_unit_sections Roundtrip, from-framework-slot Struktur-Kopie, optional apply-training-module). Ergänze kleine, deterministische Tests (pytest mit DB, falls im Projekt üblich), ohne riesige Fixtures.

  3. Frontend-Schneidstellen markieren: kurze Kommentare oder ein Working-Doc-Update, wo TrainingPlanningPageRoot, buildSectionsPayload, TrainingUnitRunPage, TrainingCoachPage + trainingPlanUtils.flattenPlanTimeline später angebunden werden — kein großes UI-Rewrite.

  4. Migrations-Sicherheit: Dokumentiere in einem Absatz im ANALYSIS-Dokument oder hier, welche Unique-Constraints (training_unit_sections: UNIQUE (training_unit_id, order_index)) die Parallelität blockieren — ohne sie schon zu ändern, außer es ist Teil einer explizit freigegebenen ersten Migration.

  5. Performance nur berührensensible Stellen: Einzelabruf GET /api/training-units/{id} wird mit mehr JOINs kommen. Falls du jetzt N+1 oder redundante Arbeit in _fetch_sections siehst und das risikoarm verbesserbar ist, nur mit Messpunkt/Messvorstellung (kein unnötiger Micro-Optimismus).

Leitplanken

  • Stabilität vor Geschwindigkeit: Keine Änderung, die bestehende Einheiten, Rahmen-Blueprints oder Run-Modus bricht.
  • Keine pauschalen Refactors: Nur Änderungen mit klarem Träger für das Parallel-Feature oder mit Test-Regression-Schutz.
  • Regeln: .claude/rules/ARCHITECTURE.md, CODING_RULES.md, Zugriffsschicht wo relevant.

Erwartete Ausgabe

  1. Kurze Liste erledigter Vorarbeiten (Dateien, was warum).
  2. Empfohlene Reihenfolge für die nächste Session, die Phasen/Streams implementiert (verweis auf PARALLEL_TRAINING_STREAMS_ANALYSIS_AND_IMPLEMENTATION_PLAN.md Pakete 0–2).
  3. Falls nichts Sinnvolles ohne Feature-Branch riskiert werden kann: explizit „keine Code-Änderung“, nur Risiko-Notiz.

Optionaler Startbefehl

Lies zuerst:
.claude/docs/working/PARALLEL_TRAINING_STREAMS_ANALYSIS_AND_IMPLEMENTATION_PLAN.md
dann backend/routers/training_planning.py (Abschnitte um _fetch_sections, _replace_unit_sections).