mARTin-B78/My-Weekly-ToDo-List
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

TODO-CODESCENE-OPTIMIERUNG-FUER-CLAUDE.md #1

New Issue
Open
opened 2026-09-21 10:31:26 +02:00 by mARTin-B78 · 0 comments
mARTin-B78 commented 2026-09-21 10:31:26 +02:00
Owner
Copy Link

Claude-Auftrag: CodeScene-getriebene Sanierung von My Weekly ToDo List

Verwendung

Diesen Auftrag in Claude Code im Repository My-Weekly-ToDo-List verwenden.
Claude soll zuerst analysieren und einen umsetzbaren Plan vorlegen. Erst nach
expliziter Freigabe des Repository-Owners darf Claude Code veraendern.

Rolle und Ziel

Du arbeitest als erfahrener TypeScript-/React-/Next.js-Refactoring-Engineer am
Projekt My Weekly ToDo List. Verbessere die Wartbarkeit der nachfolgend
belegten CodeScene-Hotspots, ohne sichtbares Verhalten, APIs, Persistenz,
Authentifizierung, Kalender-Synchronisation oder Datenformat zu veraendern.

Das Ziel ist keine kosmetische Aufteilung nach Zeilenzahl und kein Umschreiben
der Anwendung. Das Ziel sind kleine, verifizierbare Refactoring-Schritte, die
Verantwortlichkeiten trennen, komplexe Logik isoliert testbar machen und das
Aenderungsrisiko der haeufig bearbeiteten Dateien senken.

Lies vor jeder Arbeit mindestens:

  1. CLAUDE.md
  2. README.md
  3. package.json
  4. die betroffenen Quell- und Testdateien

Halte den Branch-, Commit-, Versions- und Tag-Prozess aus CLAUDE.md ein. Wenn
eine Anweisung dieses Auftrags dazu im Widerspruch steht, weise vor einer
Aenderung darauf hin und frage den Owner.

Belastbare CodeScene-Ergebnisse

Analysezeitpunkt: 2026-09-11, Repository-Stand dcbcb77 (v1.120.1).

Gesamtbild:

  • 515 Commits, 270 analysierte Dateien, 178 Dateien mit Code-Health-Wertung
  • durchschnittliche Code Health: 5,82/10
  • Verteilung des Codes: 46,70 % rot, 25,03 % gelb, 28,27 % gruen
  • 5 von CodeScene empfohlene Refactoring-Ziele
  • fuer CodeScene wurde keine Test-Coverage importiert (coverage: null)
  • 27 zeitlich gekoppelte Dateipaare wurden erkannt
  • ein aktiver Hauptentwickler; das macht kleine, nachvollziehbare Schritte
    wichtiger als eine grosse parallele Umstrukturierung

Refactoring-Ziele nach CodeScene

Prioritaet Datei Code Health LOC laut CodeScene Revisionen Reibungsanteil Einordnung
P0 src/components/WeeklyView.tsx 1,93 8.713 318 0,897 primaeres Ziel
P1 src/components/CalendarEventModal.tsx 3,62 1.314 34 0,069 sekundaer, stark verschlechtert
P1 src/lib/calendar-events.ts 2,20 1.172 39 0,097 sekundaer
P2 src/components/GridTaskBlock.tsx 5,57 923 37 0,052 sekundaer
P2 src/lib/apple-calendar.ts 3,33 1.053 24 0,051 sekundaer

CalendarEventModal.tsx fiel innerhalb eines Monats von rund 6,08 auf
3,62. Das ist nach der ersten sicheren Entlastung von WeeklyView.tsx der
dringendste Trendbefund.

Weitere niedrige Werte, die erst nach den fuenf empfohlenen Zielen betrachtet
werden sollen:

  • src/lib/synology-calendar.ts: 3,33
  • src/components/PriorityView.tsx: 3,34
  • src/components/SettingsSidebar.tsx: 3,53 bei 5.215 LOC
  • src/app/api/tasks/route.ts: 3,72
  • src/app/api/tasks/sync/route.ts: 3,72

Konkrete Befunde in WeeklyView.tsx

CodeScene meldet unter anderem:

  • 127 Funktionen und damit ein deutliches Modularitaetsproblem
  • durchschnittliche zyklomatische Komplexitaet von rund 7,98
  • fetchUserInfo: Komplexitaet 80, ca. 160 LOC, „Bumpy Road"
  • handleEventSave: Komplexitaet 72
  • fetchProfile: Komplexitaet 52
  • renderKanbanCard: Komplexitaet 36, ca. 129 LOC
  • handleDrop: Komplexitaet 28, ca. 127 LOC, Verschachtelungstiefe 6
  • duplizierte Funktionsbloecke in Task-Updates, Kanban-Drops und Tab-Aktionen
  • komplexe Bedingungen und viele primitive bzw. stringbasierte Argumente
  • 5.899 als Datendeklarationen erkannte Zeilen

Positiver Kontext: Die Datei wurde bereits durch Auslagerungen verbessert
(Code Health ca. 1,72 -> 1,93; Komplexitaet sank). Vorhandene Module unter
src/components/weekly/ und src/lib/weekly/ sind weiterzuverwenden. Keine
zweite, konkurrierende Komponentenstruktur anlegen.

Weitere konkrete Befunde

  • CalendarEventModal.tsx: Die Komponente umfasst praktisch die gesamte Datei
    und wird als Bumpy Road, Complex Method und Large Method gewertet.
  • calendar-events.ts: sehr grosse Datei; getCalendarEvents ist ein langer,
    komplexer und stark verschachtelter Ablauf. Auch updateCalendarEvent und
    deleteCalendarEvent enthalten komplexe Regeln.
  • GridTaskBlock.tsx: Die Hauptkomponente umfasst fast die gesamte Datei und
    wird als Bumpy Road, Complex Method und Large Method gewertet.
  • apple-calendar.ts: Brain Method in getUpcomingEventsBatch, komplexe Logik
    in getUpcomingEvents, tiefe Verschachtelung und Duplikation.

Zeitliche Kopplung, die bei Modulgrenzen zu beachten ist:

  • apple-calendar.ts <-> calendar-events.ts: 62 %
  • apple-calendar.ts <-> synology-calendar.ts: 57 %
  • calendar-events.ts <-> outlook-calendar.ts: 44 %
  • CalendarEventModal.tsx <-> calendar-events.ts: 38 %
  • api/calendar/events/route.ts <-> calendar-events.ts: 42 %

Behandle diese Kopplungen als Hinweis auf gemeinsame Vertrage und fachliche
Grenzen, nicht als Auftrag, alle Dateien gleichzeitig umzubauen.

Wichtige Einordnung der Messung

Die CodeScene-Analyse enthaelt auch Dateien, die den Produktcode nicht
repraesentieren, beispielsweise Version 01/, .opencode/, Debugskripte und
tests/debug/. Markdown wurde ebenfalls in grossem Umfang gezaehlt. Leite aus
der Gesamtgroesse deshalb keine pauschalen Ziele ab.

package.json erscheint wegen der im Projekt vorgeschriebenen
Versionsaenderung pro Commit als groesster Aenderungs-Hotspot. Das ist ein
Prozessartefakt und kein Refactoring-Ziel. Veraendere oder schreibe die
Git-Historie nicht um. package-lock.json ist ebenfalls kein manuelles
Optimierungsziel.

Empfiehl dem Owner separat folgende CodeScene-Excludes und warte auf dessen
Entscheidung; vermische diese Konfigurationsbereinigung nicht mit dem Code-Diff:

**/Version 01/**;**/.opencode/**;**/tests/debug/**;**/.next/**;**/playwright-report/**;**/test-results/**

Verbindliche Arbeitsweise

1. Bestandsaufnahme und Plan, noch kein Code

Pruefe zuerst:

  • aktueller Branch und sauberer Worktree
  • bestehende Komponenten, Hooks, Hilfsfunktionen und Typen
  • alle Aufrufer und Importe der Zielmodule
  • vorhandene Unit-, Integrations- und Playwright-Tests
  • heutiger Zustand von Lint, Type-Check, Unit-Tests, E2E und Build
  • welche sichtbaren Nutzerablaeufe die jeweils zu extrahierende Logik schuetzen

Lege danach einen phasenweisen Plan vor. Fuer jeden Schritt nenne:

  • fachliche Verantwortung und exakte Modulgrenze
  • betroffene Dateien
  • Verhalten, das unveraendert bleiben muss
  • zuerst anzulegende oder zu erweiternde Charakterisierungstests
  • erwarteten kleinen Diff
  • Risiken und Rueckfallmoeglichkeit
  • eindeutige Abnahmekriterien

Warte anschliessend auf ein ausdrueckliches Go des Owners.

2. Tests vor jedem Refactoring-Schnitt

CodeScene kennt aktuell keine importierte Coverage. Behaupte deshalb weder,
dass keine Tests existieren, noch dass die Hotspots ausreichend getestet sind.
Ermittle die reale Abdeckung aus dem Repository.

Vor jeder Extraktion muessen relevante Verhaltenstests vorhanden und gruen
sein. Bevorzuge:

  • node:test fuer pure TypeScript-Domaenenlogik
  • bestehende Playwright-Tests fuer sichtbare End-to-End-Ablaufe
  • Tests gegen beobachtbares Verhalten statt interne Funktionsnamen

Fuehre keine neue Testbibliothek ohne Freigabe des Owners ein. Falls sich eine
React-Komponente mit den vorhandenen Mitteln nicht sinnvoll isoliert testen
laesst, beschreibe Kosten und Nutzen einer Testbibliothek und frage zuerst.

Mindestens zu schuetzende Kernablaeufe:

  • Aufgaben anlegen, bearbeiten, abschliessen, verschieben und loeschen
  • Undo/Redo und Unteraufgaben
  • Drag-and-drop zwischen Tagesraster, Kanban und Someday-Listen
  • wiederkehrende Aufgaben und einzelne Serienvorkommen
  • Kalendertermine laden, anlegen, bearbeiten, verschieben und loeschen
  • Zeitzonen, Ganztagstermine und Datumsgrenzen
  • Kalender-Sync und Fehlerfaelle der Provider
  • Profil-/Ansichtseinstellungen und deren Persistenz

3. Umsetzungsreihenfolge

Arbeite in kleinen, separat pruefbaren Scheiben:

Phase A - WeeklyView.tsx stabilisieren

  1. Pure Regeln und Transformationen mit Charakterisierungstests absichern und
    in die bestehende Struktur src/lib/weekly/ verschieben.
  2. Zusammengehoerige Seiteneffekte aus fetchUserInfo, fetchProfile, Task-
    CRUD, Kalender-CRUD und Sync voneinander trennen. Keine beliebigen
    „utils"-Sammeldateien anlegen.
  3. Drag-and-drop-Entscheidungslogik von DOM-/React-Ereignissen trennen; pure
    Ziel-/Validierungsregeln separat testen. handleDrop mit Guard Clauses und
    benannten Teilablaeufen entlasten.
  4. Zusammenhaengende Darstellungsteile in die bereits vorhandene
    src/components/weekly/-Struktur extrahieren. Props nach fachlicher
    Verantwortung schneiden; keine Komponente mit dutzenden Einzel-Props
    erzeugen.
  5. Duplizierte Task-Update-, Kanban-Drop- und Tab-Operationen nur dann
    vereinheitlichen, wenn sie tatsaechlich dieselbe fachliche Semantik haben.

Nicht die komplette Datei in einem Schritt neu schreiben. Bestehende
Auslagerungen (TaskItem, ProjectsSidebar, NotesSidebar, TaskInput,
VisualsPopover, Datums-/Formatierungshelfer usw.) nicht zurueckdrehen.

Phase B - fallenden Trend stoppen

Zerlege CalendarEventModal.tsx entlang stabiler Verantwortlichkeiten, zum
Beispiel Formularzustand/Validierung, Wiederholung, Kalenderauswahl und
Praesentation. Die konkrete Grenze ist aus dem Code abzuleiten. API-Payloads
und Nutzerverhalten muessen identisch bleiben.

Phase C - Kalender-Domaene modularisieren

Teile calendar-events.ts entlang der tatsaechlichen Verantwortlichkeiten von
Lesen/Normalisieren, Erstellen, Aktualisieren, Loeschen und Recurrence auf.
Definiere zuerst durch Tests einen schmalen, typisierten Vertrag. Beachte die
Kopplung zu API-Route, Modal und Provider-Modulen.

Danach apple-calendar.ts bearbeiten. Wiederverwendbare Provider-Logik nur
extrahieren, wenn mindestens zwei Provider nachweislich dieselbe Semantik
haben. Provider-spezifische Fehlerbehandlung, Zeitzonen- und Recurrence-Regeln
nicht durch eine voreilige Abstraktion verwischen.

Phase D - uebrige empfohlene Ziele

GridTaskBlock.tsx entlang von Darstellung, Benutzerinteraktion und puren
Berechnungen schneiden. Erst danach anhand einer neuen CodeScene-Analyse
entscheiden, ob SettingsSidebar.tsx, synology-calendar.ts oder die
Task-Routen als naechstes bearbeitet werden.

Nicht erlaubt

  • keine Feature-Aenderungen im Refactoring-Diff
  • keine neue Dependency ohne Owner-Freigabe
  • keine API-, Datenbank- oder Payload-Aenderung ohne separaten Auftrag
  • keine Massenumbenennung oder Formatierung des gesamten Repositories
  • keine Abschaltung oder Abschwaechung von TypeScript, ESLint oder Tests
  • keine @ts-nocheck, pauschalen Lint-Suppressions oder neuen any-Auswege
  • keine Tests loeschen oder Erwartungen abschwaechen, damit der Diff gruen wird
  • keine Secrets, Tokens, Kalenderinhalte oder personenbezogenen Daten loggen
  • kein Refactoring von package.json/Lockfile nur wegen des Hotspot-Rangs
  • keine Optimierung allein auf den CodeScene-Score

Pruefung nach jedem kleinen Schritt

Fuehre, soweit fuer den Schritt relevant, mindestens aus:

npm run lint
npm run type-check
npm run test:unit
npm run test:e2e
npm run build

Wenn E2E eine externe Umgebung, Zugangsdaten oder Dienste benoetigt, nicht
umgehen oder faelschen. Dokumentiere exakt, was lokal nachgewiesen wurde und
was der Owner in seiner Zielumgebung pruefen muss.

Nach einem fachlich zusammenhaengenden Schritt:

  1. Diff auf unbeabsichtigte Verhaltensaenderungen pruefen.
  2. Tests und Build ausfuehren.
  3. Nur diesen Schritt committen; Vorgaben aus CLAUDE.md zu Version und Tag
    beachten.
  4. CodeScene erneut gegen denselben bereinigten Scope laufen lassen.

Abnahmekriterien

Eine Phase gilt nur dann als erfolgreich, wenn:

  • alle zuvor gruenen Checks weiterhin gruen sind
  • neue Tests beobachtbares Verhalten bzw. pure Fachregeln absichern
  • kein sichtbares Verhalten und kein externer Vertrag unbeabsichtigt geaendert
    wurde
  • die Zielverantwortung klarer und isoliert testbar ist
  • keine neue „God Component" oder allgemeine utils.ts als Verschiebebahnhof
    entstanden ist
  • CodeScene beim gleichen Scope keine Verschlechterung anderer Hotspots zeigt
  • der Score und/oder die konkreten Befunde des bearbeiteten Hotspots messbar
    besser werden

Fuer die erste WeeklyView.tsx-Iteration ist nicht „10/10" das Ziel. Realistisch
ist eine klar messbare Reduktion von Dateigroesse, Funktionsanzahl und den
konkreten Komplexitaetsbefunden bei vollstaendig gruenem Verhaltenstest. Nenne
vorab einen begruendeten Zielkorridor; passe ihn nicht nachtraeglich an, nur um
die Phase als erfolgreich zu deklarieren.

Gewuenschtes erstes Ergebnis von Claude

Antworte zunaechst ausschliesslich mit:

  1. verifiziertem Ist-Zustand und eventuellen Abweichungen von den obigen Daten
  2. Risikokarte der P0-/P1-Dateien
  3. vorgeschlagener Modulgrenze fuer den ersten kleinen Refactoring-Schnitt
  4. konkreten Charakterisierungstests fuer genau diesen Schnitt
  5. betroffenen Dateien und erwarteter Diff-Groesse
  6. auszufuehrenden Checks
  7. offenen Fragen an den Owner

Noch keinen Code aendern und noch keinen Commit erstellen. Warte auf das Go.

# Claude-Auftrag: CodeScene-getriebene Sanierung von My Weekly ToDo List ## Verwendung Diesen Auftrag in Claude Code im Repository `My-Weekly-ToDo-List` verwenden. Claude soll zuerst analysieren und einen umsetzbaren Plan vorlegen. Erst nach expliziter Freigabe des Repository-Owners darf Claude Code veraendern. ## Rolle und Ziel Du arbeitest als erfahrener TypeScript-/React-/Next.js-Refactoring-Engineer am Projekt **My Weekly ToDo List**. Verbessere die Wartbarkeit der nachfolgend belegten CodeScene-Hotspots, ohne sichtbares Verhalten, APIs, Persistenz, Authentifizierung, Kalender-Synchronisation oder Datenformat zu veraendern. Das Ziel ist keine kosmetische Aufteilung nach Zeilenzahl und kein Umschreiben der Anwendung. Das Ziel sind kleine, verifizierbare Refactoring-Schritte, die Verantwortlichkeiten trennen, komplexe Logik isoliert testbar machen und das Aenderungsrisiko der haeufig bearbeiteten Dateien senken. Lies vor jeder Arbeit mindestens: 1. `CLAUDE.md` 2. `README.md` 3. `package.json` 4. die betroffenen Quell- und Testdateien Halte den Branch-, Commit-, Versions- und Tag-Prozess aus `CLAUDE.md` ein. Wenn eine Anweisung dieses Auftrags dazu im Widerspruch steht, weise vor einer Aenderung darauf hin und frage den Owner. ## Belastbare CodeScene-Ergebnisse Analysezeitpunkt: **2026-09-11**, Repository-Stand `dcbcb77` (`v1.120.1`). Gesamtbild: - 515 Commits, 270 analysierte Dateien, 178 Dateien mit Code-Health-Wertung - durchschnittliche Code Health: **5,82/10** - Verteilung des Codes: **46,70 % rot**, **25,03 % gelb**, **28,27 % gruen** - 5 von CodeScene empfohlene Refactoring-Ziele - fuer CodeScene wurde keine Test-Coverage importiert (`coverage: null`) - 27 zeitlich gekoppelte Dateipaare wurden erkannt - ein aktiver Hauptentwickler; das macht kleine, nachvollziehbare Schritte wichtiger als eine grosse parallele Umstrukturierung ### Refactoring-Ziele nach CodeScene | Prioritaet | Datei | Code Health | LOC laut CodeScene | Revisionen | Reibungsanteil | Einordnung | |---|---|---:|---:|---:|---:|---| | P0 | `src/components/WeeklyView.tsx` | **1,93** | 8.713 | 318 | **0,897** | primaeres Ziel | | P1 | `src/components/CalendarEventModal.tsx` | **3,62** | 1.314 | 34 | 0,069 | sekundaer, stark verschlechtert | | P1 | `src/lib/calendar-events.ts` | **2,20** | 1.172 | 39 | 0,097 | sekundaer | | P2 | `src/components/GridTaskBlock.tsx` | **5,57** | 923 | 37 | 0,052 | sekundaer | | P2 | `src/lib/apple-calendar.ts` | **3,33** | 1.053 | 24 | 0,051 | sekundaer | `CalendarEventModal.tsx` fiel innerhalb eines Monats von rund **6,08 auf 3,62**. Das ist nach der ersten sicheren Entlastung von `WeeklyView.tsx` der dringendste Trendbefund. Weitere niedrige Werte, die erst nach den fuenf empfohlenen Zielen betrachtet werden sollen: - `src/lib/synology-calendar.ts`: 3,33 - `src/components/PriorityView.tsx`: 3,34 - `src/components/SettingsSidebar.tsx`: 3,53 bei 5.215 LOC - `src/app/api/tasks/route.ts`: 3,72 - `src/app/api/tasks/sync/route.ts`: 3,72 ### Konkrete Befunde in `WeeklyView.tsx` CodeScene meldet unter anderem: - 127 Funktionen und damit ein deutliches Modularitaetsproblem - durchschnittliche zyklomatische Komplexitaet von rund 7,98 - `fetchUserInfo`: Komplexitaet 80, ca. 160 LOC, „Bumpy Road" - `handleEventSave`: Komplexitaet 72 - `fetchProfile`: Komplexitaet 52 - `renderKanbanCard`: Komplexitaet 36, ca. 129 LOC - `handleDrop`: Komplexitaet 28, ca. 127 LOC, Verschachtelungstiefe 6 - duplizierte Funktionsbloecke in Task-Updates, Kanban-Drops und Tab-Aktionen - komplexe Bedingungen und viele primitive bzw. stringbasierte Argumente - 5.899 als Datendeklarationen erkannte Zeilen Positiver Kontext: Die Datei wurde bereits durch Auslagerungen verbessert (Code Health ca. 1,72 -> 1,93; Komplexitaet sank). Vorhandene Module unter `src/components/weekly/` und `src/lib/weekly/` sind weiterzuverwenden. Keine zweite, konkurrierende Komponentenstruktur anlegen. ### Weitere konkrete Befunde - `CalendarEventModal.tsx`: Die Komponente umfasst praktisch die gesamte Datei und wird als Bumpy Road, Complex Method und Large Method gewertet. - `calendar-events.ts`: sehr grosse Datei; `getCalendarEvents` ist ein langer, komplexer und stark verschachtelter Ablauf. Auch `updateCalendarEvent` und `deleteCalendarEvent` enthalten komplexe Regeln. - `GridTaskBlock.tsx`: Die Hauptkomponente umfasst fast die gesamte Datei und wird als Bumpy Road, Complex Method und Large Method gewertet. - `apple-calendar.ts`: Brain Method in `getUpcomingEventsBatch`, komplexe Logik in `getUpcomingEvents`, tiefe Verschachtelung und Duplikation. Zeitliche Kopplung, die bei Modulgrenzen zu beachten ist: - `apple-calendar.ts` <-> `calendar-events.ts`: 62 % - `apple-calendar.ts` <-> `synology-calendar.ts`: 57 % - `calendar-events.ts` <-> `outlook-calendar.ts`: 44 % - `CalendarEventModal.tsx` <-> `calendar-events.ts`: 38 % - `api/calendar/events/route.ts` <-> `calendar-events.ts`: 42 % Behandle diese Kopplungen als Hinweis auf gemeinsame Vertrage und fachliche Grenzen, nicht als Auftrag, alle Dateien gleichzeitig umzubauen. ## Wichtige Einordnung der Messung Die CodeScene-Analyse enthaelt auch Dateien, die den Produktcode nicht repraesentieren, beispielsweise `Version 01/`, `.opencode/`, Debugskripte und `tests/debug/`. Markdown wurde ebenfalls in grossem Umfang gezaehlt. Leite aus der Gesamtgroesse deshalb keine pauschalen Ziele ab. `package.json` erscheint wegen der im Projekt vorgeschriebenen Versionsaenderung pro Commit als groesster Aenderungs-Hotspot. Das ist ein Prozessartefakt und **kein Refactoring-Ziel**. Veraendere oder schreibe die Git-Historie nicht um. `package-lock.json` ist ebenfalls kein manuelles Optimierungsziel. Empfiehl dem Owner separat folgende CodeScene-Excludes und warte auf dessen Entscheidung; vermische diese Konfigurationsbereinigung nicht mit dem Code-Diff: ```text **/Version 01/**;**/.opencode/**;**/tests/debug/**;**/.next/**;**/playwright-report/**;**/test-results/** ``` ## Verbindliche Arbeitsweise ### 1. Bestandsaufnahme und Plan, noch kein Code Pruefe zuerst: - aktueller Branch und sauberer Worktree - bestehende Komponenten, Hooks, Hilfsfunktionen und Typen - alle Aufrufer und Importe der Zielmodule - vorhandene Unit-, Integrations- und Playwright-Tests - heutiger Zustand von Lint, Type-Check, Unit-Tests, E2E und Build - welche sichtbaren Nutzerablaeufe die jeweils zu extrahierende Logik schuetzen Lege danach einen phasenweisen Plan vor. Fuer jeden Schritt nenne: - fachliche Verantwortung und exakte Modulgrenze - betroffene Dateien - Verhalten, das unveraendert bleiben muss - zuerst anzulegende oder zu erweiternde Charakterisierungstests - erwarteten kleinen Diff - Risiken und Rueckfallmoeglichkeit - eindeutige Abnahmekriterien Warte anschliessend auf ein ausdrueckliches **Go** des Owners. ### 2. Tests vor jedem Refactoring-Schnitt CodeScene kennt aktuell keine importierte Coverage. Behaupte deshalb weder, dass keine Tests existieren, noch dass die Hotspots ausreichend getestet sind. Ermittle die reale Abdeckung aus dem Repository. Vor jeder Extraktion muessen relevante Verhaltenstests vorhanden und gruen sein. Bevorzuge: - `node:test` fuer pure TypeScript-Domaenenlogik - bestehende Playwright-Tests fuer sichtbare End-to-End-Ablaufe - Tests gegen beobachtbares Verhalten statt interne Funktionsnamen Fuehre keine neue Testbibliothek ohne Freigabe des Owners ein. Falls sich eine React-Komponente mit den vorhandenen Mitteln nicht sinnvoll isoliert testen laesst, beschreibe Kosten und Nutzen einer Testbibliothek und frage zuerst. Mindestens zu schuetzende Kernablaeufe: - Aufgaben anlegen, bearbeiten, abschliessen, verschieben und loeschen - Undo/Redo und Unteraufgaben - Drag-and-drop zwischen Tagesraster, Kanban und Someday-Listen - wiederkehrende Aufgaben und einzelne Serienvorkommen - Kalendertermine laden, anlegen, bearbeiten, verschieben und loeschen - Zeitzonen, Ganztagstermine und Datumsgrenzen - Kalender-Sync und Fehlerfaelle der Provider - Profil-/Ansichtseinstellungen und deren Persistenz ### 3. Umsetzungsreihenfolge Arbeite in kleinen, separat pruefbaren Scheiben: #### Phase A - `WeeklyView.tsx` stabilisieren 1. Pure Regeln und Transformationen mit Charakterisierungstests absichern und in die bestehende Struktur `src/lib/weekly/` verschieben. 2. Zusammengehoerige Seiteneffekte aus `fetchUserInfo`, `fetchProfile`, Task- CRUD, Kalender-CRUD und Sync voneinander trennen. Keine beliebigen „utils"-Sammeldateien anlegen. 3. Drag-and-drop-Entscheidungslogik von DOM-/React-Ereignissen trennen; pure Ziel-/Validierungsregeln separat testen. `handleDrop` mit Guard Clauses und benannten Teilablaeufen entlasten. 4. Zusammenhaengende Darstellungsteile in die bereits vorhandene `src/components/weekly/`-Struktur extrahieren. Props nach fachlicher Verantwortung schneiden; keine Komponente mit dutzenden Einzel-Props erzeugen. 5. Duplizierte Task-Update-, Kanban-Drop- und Tab-Operationen nur dann vereinheitlichen, wenn sie tatsaechlich dieselbe fachliche Semantik haben. Nicht die komplette Datei in einem Schritt neu schreiben. Bestehende Auslagerungen (`TaskItem`, `ProjectsSidebar`, `NotesSidebar`, `TaskInput`, `VisualsPopover`, Datums-/Formatierungshelfer usw.) nicht zurueckdrehen. #### Phase B - fallenden Trend stoppen Zerlege `CalendarEventModal.tsx` entlang stabiler Verantwortlichkeiten, zum Beispiel Formularzustand/Validierung, Wiederholung, Kalenderauswahl und Praesentation. Die konkrete Grenze ist aus dem Code abzuleiten. API-Payloads und Nutzerverhalten muessen identisch bleiben. #### Phase C - Kalender-Domaene modularisieren Teile `calendar-events.ts` entlang der tatsaechlichen Verantwortlichkeiten von Lesen/Normalisieren, Erstellen, Aktualisieren, Loeschen und Recurrence auf. Definiere zuerst durch Tests einen schmalen, typisierten Vertrag. Beachte die Kopplung zu API-Route, Modal und Provider-Modulen. Danach `apple-calendar.ts` bearbeiten. Wiederverwendbare Provider-Logik nur extrahieren, wenn mindestens zwei Provider nachweislich dieselbe Semantik haben. Provider-spezifische Fehlerbehandlung, Zeitzonen- und Recurrence-Regeln nicht durch eine voreilige Abstraktion verwischen. #### Phase D - uebrige empfohlene Ziele `GridTaskBlock.tsx` entlang von Darstellung, Benutzerinteraktion und puren Berechnungen schneiden. Erst danach anhand einer neuen CodeScene-Analyse entscheiden, ob `SettingsSidebar.tsx`, `synology-calendar.ts` oder die Task-Routen als naechstes bearbeitet werden. ## Nicht erlaubt - keine Feature-Aenderungen im Refactoring-Diff - keine neue Dependency ohne Owner-Freigabe - keine API-, Datenbank- oder Payload-Aenderung ohne separaten Auftrag - keine Massenumbenennung oder Formatierung des gesamten Repositories - keine Abschaltung oder Abschwaechung von TypeScript, ESLint oder Tests - keine `@ts-nocheck`, pauschalen Lint-Suppressions oder neuen `any`-Auswege - keine Tests loeschen oder Erwartungen abschwaechen, damit der Diff gruen wird - keine Secrets, Tokens, Kalenderinhalte oder personenbezogenen Daten loggen - kein Refactoring von `package.json`/Lockfile nur wegen des Hotspot-Rangs - keine Optimierung allein auf den CodeScene-Score ## Pruefung nach jedem kleinen Schritt Fuehre, soweit fuer den Schritt relevant, mindestens aus: ```bash npm run lint npm run type-check npm run test:unit npm run test:e2e npm run build ``` Wenn E2E eine externe Umgebung, Zugangsdaten oder Dienste benoetigt, nicht umgehen oder faelschen. Dokumentiere exakt, was lokal nachgewiesen wurde und was der Owner in seiner Zielumgebung pruefen muss. Nach einem fachlich zusammenhaengenden Schritt: 1. Diff auf unbeabsichtigte Verhaltensaenderungen pruefen. 2. Tests und Build ausfuehren. 3. Nur diesen Schritt committen; Vorgaben aus `CLAUDE.md` zu Version und Tag beachten. 4. CodeScene erneut gegen denselben bereinigten Scope laufen lassen. ## Abnahmekriterien Eine Phase gilt nur dann als erfolgreich, wenn: - alle zuvor gruenen Checks weiterhin gruen sind - neue Tests beobachtbares Verhalten bzw. pure Fachregeln absichern - kein sichtbares Verhalten und kein externer Vertrag unbeabsichtigt geaendert wurde - die Zielverantwortung klarer und isoliert testbar ist - keine neue „God Component" oder allgemeine `utils.ts` als Verschiebebahnhof entstanden ist - CodeScene beim gleichen Scope keine Verschlechterung anderer Hotspots zeigt - der Score und/oder die konkreten Befunde des bearbeiteten Hotspots messbar besser werden Fuer die erste `WeeklyView.tsx`-Iteration ist nicht „10/10" das Ziel. Realistisch ist eine klar messbare Reduktion von Dateigroesse, Funktionsanzahl und den konkreten Komplexitaetsbefunden bei vollstaendig gruenem Verhaltenstest. Nenne vorab einen begruendeten Zielkorridor; passe ihn nicht nachtraeglich an, nur um die Phase als erfolgreich zu deklarieren. ## Gewuenschtes erstes Ergebnis von Claude Antworte zunaechst ausschliesslich mit: 1. verifiziertem Ist-Zustand und eventuellen Abweichungen von den obigen Daten 2. Risikokarte der P0-/P1-Dateien 3. vorgeschlagener Modulgrenze fuer den **ersten kleinen** Refactoring-Schnitt 4. konkreten Charakterisierungstests fuer genau diesen Schnitt 5. betroffenen Dateien und erwarteter Diff-Groesse 6. auszufuehrenden Checks 7. offenen Fragen an den Owner Noch keinen Code aendern und noch keinen Commit erstellen. Warte auf das Go.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mARTin-B78/My-Weekly-ToDo-List#1
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?