Lars/shinkan-jinkendo
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 3 Wiki Activity
main
shinkan-jinkendo/docs/architecture/README.md
Lars 3be7606d90
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Details
Test Suite / pytest-backend (push) Successful in 43s
Details
Test Suite / lint-backend (push) Successful in 0s
Details
Test Suite / build-frontend (push) Successful in 13s
Details
Test Suite / k6 /health Baseline (push) Successful in 34s
Details
Test Suite / playwright-tests (push) Successful in 1m25s
Details
Update documentation and enhance planning features in Progression Graph 
- Updated the `CLAUDE.md` to reflect changes in the Progression Graph, including the new Ist-Stand and roadmap specifications.
- Enhanced `PLANNING_EXERCISE_SUGGEST_CONTEXT.md` with detailed descriptions of the current state and features of the planning exercise.
- Revised `PLANNING_PROGRESSION_ROADMAP_SPEC.md` to document the implementation status of various phases and their corresponding migrations.
- Incremented application version to 0.8.217 to incorporate recent updates and improvements in the planning context and roadmap functionalities.
2026-06-10 07:50:29 +02:00

3.1 KiB
Raw Permalink Blame History

Architektur: Zielbild, Refaktor, Regeln (Shinkan Jinkendo)

Dieses Bündel ist die Leitlinie für die große Refaktorierung nach dem MVP. Es ergänzt die bestehenden Pflichtdokumente (.claude/rules/ARCHITECTURE.md, CODING_RULES.md, Zugriffsschicht, Media-Spec) und ist für Wartbarkeit, Performance und sichere Erweiterung verbindlich, soweit hier ausdrücklich festgelegt.

Inhalt

Datei Zweck
ZIELBILD_ARCHITEKTUR.md Zielarchitektur (Frontend, API, Daten), Qualitätsziele, Einbindung neuer Features
SCHULDEN_UND_REMEDIATION.md Erfasste Architekturschuld, Reihenfolge und Massnahmen zur Behebung
UMSETZUNGSPLAN_ROADMAP.md Phasen, Meilensteine, Abnahmekriterien, Aufwandsschwerpunkte
frontend/src/api/client.js Phase 4: zentraler HTTP-Client (request, ACTIVE_CLUB_STORAGE_KEY, API_URL, mergeActiveClubHeader)
frontend/src/api/exercises.js Phase 4: Übungen, Medien/Archiv, Progressionsgraphen, KI-Hilfen
frontend/src/api/planning.js Phase 4: Trainingsplanung (Einheiten, Vorlagen, Module, Rahmen, KPIs)
BASELINE_SNAPSHOT.md Phase 0: Bundle-, API- und Last-Baseline (Messvorlagen, Vergleich nach Phase 2)
KI-Prompt-Zielarchitektur Roadmap: Kontext-Arten, Composition, Planung/Rahmen, Phasenplan (verbindliche Zielrichtung)
PLANNING_PROGRESSION_GRAPH_KI.md Progressionsgraph-KI Ist-Stand (Module, API, Graph-Verhalten, Persistenz — zentrale Referenz)
PLANNING_KI_ROADMAP.md Planungs-KI Produkt-Roadmap (Phase F–G, Abgrenzung Trainingsplanung)
Progressions-Roadmap Spec Phase F: Artefakte A→B→C, API, Workflow-lite

Tests (E2E / Refaktor-Budget)

  • tests/dev-smoke-test.spec.js – Playwright-Suite (Smoke + Compliance). Enthält u. a. Test 8: nach Login und Reload des Dashboards werden GET-Aufrufe zu /api/profiles/me und /api/training-units gezählt (Absicherung Dashboard-Refaktor Phase 1). Ausführung: npm run test:e2e; CI: .gitea/workflows/test.yml Job playwright-tests. k6-Baseline: Job k6-health-baseline (siehe scripts/load/README.md).

Pflege

  • Bei abgeschlossenen Phasen: Roadmap und Remediation-Dokument aktualisieren; bei Regeländerungen: nur mit expliziter Projektfreigabe (gleiches Verfahren wie bei .claude/rules/ARCHITECTURE.md).
  • Querschnitt: docs/HANDOVER.md soll auf die aktive Roadmap-Phase verweisen.

Bezug MVP

Die aktuelle Codebasis ist funktional MVP-tauglich; strukturell bestehen bekannte Schwerpunkte (grosse Seiten-Monolithen, API-Monolith im Client, redundante Lesepfade, schwere Listenqueries). Dieses Bündel definiert, wie nach dem MVP weitergebaut wird, ohne jedes neue Feature erneut mit architektonischer Schuld zu überfrachten.