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

TODO-CODESCENE-FORTSETZUNG-2026-09-12.md #2

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

Arbeitsauftrag: CodeScene-Optimierung fortsetzen

Verwendung

Diese Anweisung im Repository My-Weekly-ToDo-List verwenden. Sie basiert
auf dem CodeScene-Weekly-Lauf vom 2026-09-12, 16:03 UTC. Der analysierte
Stand enthielt 527 Commits; der letzte enthaltene Commit war nach den
CodeScene-Evolutionsdaten 3ac3d13 (v1.125.2).

Wenn HEAD inzwischen neuer ist, arbeite mit dem aktuellen Stand, nenne aber
vor jeder Empfehlung die Abweichung zur CodeScene-Baseline. CodeScene-Werte
sind Priorisierungshilfen, keine alleinigen Erfolgsmetriken.

Rolle und Ziel

Du arbeitest als erfahrener TypeScript-/React-/Next.js-Refactoring-Engineer.
Verbessere Wartbarkeit und Testbarkeit in kleinen, rücksetzbaren Schritten.
Sichtbares Verhalten, APIs, Authentifizierung, Persistenz, Kalender-Payloads,
Zeitzonen- und Wiederholungslogik dürfen sich dabei nicht unbeabsichtigt
ändern.

Beginne mit Analyse und Plan. Ändere noch keinen Code, bis der Owner den
ersten Refactoring-Schnitt ausdrücklich freigegeben hat.

Aktuelle CodeScene-Baseline

  • durchschnittliche Code Health: 5,88/10
  • Hotspot Code Health: 1,93/10
  • Technical-Debt-Friction: 48,60; zuvor 50,72
  • Technical-Debt-Accumulation: 41,2; zuvor 44,9
  • 309 Entities, 276 Dateien, 185 Dateien mit Code-Health-Wertung
  • keine importierte Test-Coverage (coverage: null)
  • 27 zeitlich gekoppelte Dateipaare
  • ein aktiver Hauptentwickler

Priorisierte Ziele

Priorität Datei Code Health LOC Revisionen Aktueller Hauptbefund
P0 src/components/WeeklyView.tsx 1,93 8.658 320 127 Funktionen; fetchUserInfo ist Bumpy Road/Complex/Large Method; handleDrop ist tief verschachtelt
P1 src/lib/calendar-events.ts 2,20 1.172 39 getCalendarEvents ist Bumpy Road; komplexe Update-/Delete- und Recurrence-Logik
P1 src/components/CalendarEventModal.tsx 3,62 1.314 34 Monatsabfall von 6,08; eine sehr große Komponente mit wachsender Komplexität
P2 src/lib/apple-calendar.ts 3,33 1.053 24 Brain Method in getUpcomingEventsBatch; komplexe Recurrence-Löschung und Duplikation
P2 src/components/GridTaskBlock.tsx 5,57 923 37 Darstellung, Berechnung und Interaktion in einer großen Komponente

WeeklyView.tsx wurde bereits verbessert: gegenüber dem Monatsstand sank die
CodeScene-LOC von 10.735 auf 8.658 und der Score stieg von 1,72 auf 1,93. Der
Score blieb zwischen den letzten beiden Weekly-Läufen jedoch unverändert.
Vorhandene Module unter src/lib/weekly/ und src/components/weekly/ müssen
weiterverwendet werden.

Auftrag 1: Ist-Zustand verifizieren

Lies zuerst vollständig:

  1. CLAUDE.md
  2. README.md
  3. package.json
  4. src/components/WeeklyView.tsx
  5. die vorhandenen Dateien unter src/lib/weekly/ und
    src/components/weekly/
  6. alle Tests, die Drag-and-drop, Aufgabenoperationen, Kalenderdarstellung und
    Profilinitialisierung abdecken

Prüfe anschließend read-only:

  • Branch, HEAD und Worktree-Status
  • verfügbare npm-Skripte und tatsächlich verwendetes Testframework
  • alle Aufrufer und verwendeten Typen der als erster Schnitt vorgeschlagenen
    Logik
  • aktuellen Zustand von Typecheck, Lint, Unit-Tests, E2E und Build
  • reale Coverage, soweit die vorhandenen Werkzeuge sie ohne neue Dependency
    liefern können

Berichte fehlende oder nicht ausführbare Checks ausdrücklich. Behaupte aus
coverage: null nicht, dass keine Tests existieren.

Auftrag 2: Erster kleiner Schnitt in WeeklyView.tsx

Untersuche zuerst handleDrop. Ziel ist, die fachliche Drop-Entscheidung von
React-, DOM-, Netzwerk- und State-Update-Code zu trennen.

Der Plan soll genau einen zusammenhängenden Schnitt enthalten:

  1. Ermittle alle Drop-Quellen und -Ziele sowie die Guard Conditions.
  2. Beschreibe diese als Entscheidungstabelle: Quelle, Ziel, erlaubte Aktion,
    resultierende fachliche Operation und Ablehnungsgrund.
  3. Schlage eine reine, typisierte Funktion in der bestehenden Struktur
    src/lib/weekly/ vor. Leite Name und Signatur aus den vorhandenen Typen ab;
    erfinde keine parallelen Task- oder Kalender-Typen.
  4. Lasse handleDrop anschließend nur noch Eingaben aus dem UI lesen, die
    reine Entscheidung aufrufen und genau die bestehende Operation ausführen.
  5. Verändere keine Persistenzreihenfolge, keine API-Payloads und kein
    optimistisches UI-/Rollback-Verhalten.

Charakterisierungstests vor der Extraktion

Formuliere mit den tatsächlich vorhandenen Quell- und Zieltypen mindestens
folgende Given-When-Then-Fälle:

  • gültiger Task-Drop zwischen zwei Tageszielen
  • gültiger Drop zwischen Tagesraster und Kanban/Someday, sofern unterstützt
  • Drop auf dasselbe Ziel ohne unnötige Persistenzänderung
  • ungültige oder unvollständige Drag-Daten
  • durch eine bestehende Guard Condition gesperrter Drop
  • wiederkehrende Aufgabe beziehungsweise einzelnes Serienvorkommen
  • Kalendereintrag darf nicht versehentlich als Task behandelt werden
  • Fehler der bestehenden Persistenzoperation erhält das bisherige
    Rollback-/Fehlerverhalten

Nutze beobachtbares Verhalten. Teste die neue reine Funktion direkt und halte
mindestens einen vorhandenen Integrations- oder E2E-Test für den vollständigen
Nutzerfluss grün. Keine neue Testbibliothek ohne Owner-Freigabe.

Abnahme für den ersten Schnitt

  • alle vorher grünen Checks bleiben grün
  • handleDrop besitzt keine tiefe fachliche Verzweigungslogik mehr
  • mindestens der CodeScene-Befund Deep, Nested Complexity für handleDrop
    ist entfernt oder messbar reduziert
  • WeeklyView.tsx wird netto kleiner; neue Logik ist isoliert testbar
  • keine allgemeine utils.ts und keine neue Komponente mit einer großen
    Anzahl unstrukturierter Props
  • keine Änderung an API, Datenbank, Authentifizierung oder sichtbarem Verhalten
  • ein kleiner, eigenständig rücksetzbarer Commit

Der nächste CodeScene-Zielwert für den Hotspot ist zunächst über 2,02.
Ein einzelner kleiner Schnitt gilt aber auch dann als erfolgreich, wenn der
Gesamtscore noch nicht springt, sofern der adressierte Befund verschwindet,
Komplexität sinkt und alle Verhaltenstests grün bleiben.

Auftrag 3: Nächste Schnitte nach neuer Freigabe

Diese Schritte nicht im selben Commit und nicht ohne erneute Owner-Freigabe
umsetzen.

A. fetchUserInfo entflechten

  • Netzwerkaufruf, Antwortvalidierung, fachliche Ableitung und React-State-
    Aktualisierung getrennt erfassen.
  • Pure Transformationen zuerst mit Charakterisierungstests absichern.
  • Bestehende Lade-, Fehler- und Fallback-Zustände exakt erhalten.
  • Keine zweite Quelle für Profil- oder Berechtigungsregeln schaffen.

B. Fallenden Trend von CalendarEventModal.tsx stoppen

  • tatsächliche Verantwortlichkeiten für Formularzustand, Validierung,
    Wiederholung, Kalenderauswahl und Payload-Erzeugung identifizieren.
  • Zuerst die stabilste pure Regel extrahieren, nicht sofort die ganze
    Komponente zerlegen.
  • Create- und Edit-Modus, Ganztagstermine, Zeitzonen, Wiederholungen und
    Provider-Auswahl durch Tests schützen.

C. calendar-events.ts modularisieren

  • Lesen/Normalisieren, Erstellen, Aktualisieren, Löschen und Recurrence als
    getrennte Verantwortlichkeiten planen.
  • getCalendarEvents zuerst als Pipeline mit benannten Schritten
    charakterisieren; keine Provider-Semantik vereinheitlichen, die sich real
    unterscheidet.
  • Bestehende Kopplungen als Vertragsgrenzen beachten:
    apple-calendar.ts ↔ calendar-events.ts 62 %, calendar-events.ts ↔
    outlook-calendar.ts 44 %, API-Route ↔ calendar-events.ts 42 %.

D. Restliche Ziele

  • apple-calendar.ts: zuerst getUpcomingEventsBatch, danach
    deleteRecurringInstance.
  • GridTaskBlock.tsx: pure Berechnungen, Interaktionen und Darstellung
    schrittweise trennen.
  • SettingsSidebar.tsx erst nach den fünf CodeScene-Zielen neu bewerten; der
    Score ist niedrig, aber die Änderungsreibung geringer.

Sicherheits- und Regressionstor

Die beiden risikoreichsten Commits des letzten Laufs hatten CodeScene-Risiko
7 beziehungsweise 6 und betrafen breit gestreute Security-/Deployment-
Änderungen sowie das Next.js-Upgrade. Vor größeren Refactorings muss geklärt
sein, dass folgende Pfade geschützt sind:

  • Login und Rate-Limit
  • Kalender-Connect und -Sync
  • Verschlüsselung neuer und Lesen bestehender Zugangsdaten
  • Next.js-15-Routen mit asynchronen params
  • fehlgeschlagenes Deployment, Smoke-Test und Rollback
  • Produktions-Build mit der vorgesehenen Umgebungskonfiguration

Keine echten Zugangsdaten, Tokens, Kalenderinhalte oder personenbezogenen
Daten in Tests oder Logs verwenden.

CodeScene-Scope vor der nächsten Baseline

Empfiehl dem Owner separat, diese nicht repräsentativen Pfade auszuschließen:

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

Die Scope-Bereinigung nicht mit einem Refactoring-Commit vermischen.
package.json und package-lock.json sind wegen der vorgeschriebenen
Versionspflege Änderungshotspots, aber keine manuellen Optimierungsziele.

Verbotene Abkürzungen

  • kein Big-Bang-Rewrite
  • keine Feature-, API-, Payload- oder Schemaänderung im Refactoring
  • keine neue Dependency ohne ausdrückliche Freigabe
  • keine neue allgemeine utils-, helpers- oder God-Komponente
  • keine Tests löschen, Erwartungen abschwächen oder Typprüfung unterdrücken
  • kein any, @ts-nocheck oder pauschales ESLint-Disable als Ausweg
  • keine Optimierung ausschließlich auf einen CodeScene-Score
  • keine Änderung der Git-Historie

Gewünschte erste Antwort

Antworte vor jeder Codeänderung ausschließlich mit:

  1. verifiziertem HEAD, Branch und Worktree-Status
  2. Abweichungen von der CodeScene-Baseline
  3. Entscheidungstabelle für handleDrop
  4. vorgeschlagener exakter Funktionssignatur und Modulgrenze
  5. konkreten Charakterisierungstests
  6. betroffenen Dateien und erwarteter Diff-Größe
  7. auszuführenden Checks
  8. Risiken und Rückfallmöglichkeit
  9. offenen Fragen an den Owner

Warte danach auf ein ausdrückliches Go. Setze nur den freigegebenen ersten
Schnitt um und liefere anschließend Testergebnisse, Diff-Zusammenfassung und
den Vergleich mit einer neuen CodeScene-Analyse.

# Arbeitsauftrag: CodeScene-Optimierung fortsetzen ## Verwendung Diese Anweisung im Repository **`My-Weekly-ToDo-List`** verwenden. Sie basiert auf dem CodeScene-Weekly-Lauf vom **2026-09-12, 16:03 UTC**. Der analysierte Stand enthielt 527 Commits; der letzte enthaltene Commit war nach den CodeScene-Evolutionsdaten `3ac3d13` (`v1.125.2`). Wenn `HEAD` inzwischen neuer ist, arbeite mit dem aktuellen Stand, nenne aber vor jeder Empfehlung die Abweichung zur CodeScene-Baseline. CodeScene-Werte sind Priorisierungshilfen, keine alleinigen Erfolgsmetriken. ## Rolle und Ziel Du arbeitest als erfahrener TypeScript-/React-/Next.js-Refactoring-Engineer. Verbessere Wartbarkeit und Testbarkeit in kleinen, rücksetzbaren Schritten. Sichtbares Verhalten, APIs, Authentifizierung, Persistenz, Kalender-Payloads, Zeitzonen- und Wiederholungslogik dürfen sich dabei nicht unbeabsichtigt ändern. Beginne mit Analyse und Plan. **Ändere noch keinen Code**, bis der Owner den ersten Refactoring-Schnitt ausdrücklich freigegeben hat. ## Aktuelle CodeScene-Baseline - durchschnittliche Code Health: **5,88/10** - Hotspot Code Health: **1,93/10** - Technical-Debt-Friction: **48,60**; zuvor 50,72 - Technical-Debt-Accumulation: **41,2**; zuvor 44,9 - 309 Entities, 276 Dateien, 185 Dateien mit Code-Health-Wertung - keine importierte Test-Coverage (`coverage: null`) - 27 zeitlich gekoppelte Dateipaare - ein aktiver Hauptentwickler ### Priorisierte Ziele | Priorität | Datei | Code Health | LOC | Revisionen | Aktueller Hauptbefund | |---|---|---:|---:|---:|---| | P0 | `src/components/WeeklyView.tsx` | 1,93 | 8.658 | 320 | 127 Funktionen; `fetchUserInfo` ist Bumpy Road/Complex/Large Method; `handleDrop` ist tief verschachtelt | | P1 | `src/lib/calendar-events.ts` | 2,20 | 1.172 | 39 | `getCalendarEvents` ist Bumpy Road; komplexe Update-/Delete- und Recurrence-Logik | | P1 | `src/components/CalendarEventModal.tsx` | 3,62 | 1.314 | 34 | Monatsabfall von 6,08; eine sehr große Komponente mit wachsender Komplexität | | P2 | `src/lib/apple-calendar.ts` | 3,33 | 1.053 | 24 | Brain Method in `getUpcomingEventsBatch`; komplexe Recurrence-Löschung und Duplikation | | P2 | `src/components/GridTaskBlock.tsx` | 5,57 | 923 | 37 | Darstellung, Berechnung und Interaktion in einer großen Komponente | `WeeklyView.tsx` wurde bereits verbessert: gegenüber dem Monatsstand sank die CodeScene-LOC von 10.735 auf 8.658 und der Score stieg von 1,72 auf 1,93. Der Score blieb zwischen den letzten beiden Weekly-Läufen jedoch unverändert. Vorhandene Module unter `src/lib/weekly/` und `src/components/weekly/` müssen weiterverwendet werden. ## Auftrag 1: Ist-Zustand verifizieren Lies zuerst vollständig: 1. `CLAUDE.md` 2. `README.md` 3. `package.json` 4. `src/components/WeeklyView.tsx` 5. die vorhandenen Dateien unter `src/lib/weekly/` und `src/components/weekly/` 6. alle Tests, die Drag-and-drop, Aufgabenoperationen, Kalenderdarstellung und Profilinitialisierung abdecken Prüfe anschließend read-only: - Branch, `HEAD` und Worktree-Status - verfügbare npm-Skripte und tatsächlich verwendetes Testframework - alle Aufrufer und verwendeten Typen der als erster Schnitt vorgeschlagenen Logik - aktuellen Zustand von Typecheck, Lint, Unit-Tests, E2E und Build - reale Coverage, soweit die vorhandenen Werkzeuge sie ohne neue Dependency liefern können Berichte fehlende oder nicht ausführbare Checks ausdrücklich. Behaupte aus `coverage: null` nicht, dass keine Tests existieren. ## Auftrag 2: Erster kleiner Schnitt in `WeeklyView.tsx` Untersuche zuerst `handleDrop`. Ziel ist, die fachliche Drop-Entscheidung von React-, DOM-, Netzwerk- und State-Update-Code zu trennen. Der Plan soll genau **einen** zusammenhängenden Schnitt enthalten: 1. Ermittle alle Drop-Quellen und -Ziele sowie die Guard Conditions. 2. Beschreibe diese als Entscheidungstabelle: Quelle, Ziel, erlaubte Aktion, resultierende fachliche Operation und Ablehnungsgrund. 3. Schlage eine reine, typisierte Funktion in der bestehenden Struktur `src/lib/weekly/` vor. Leite Name und Signatur aus den vorhandenen Typen ab; erfinde keine parallelen Task- oder Kalender-Typen. 4. Lasse `handleDrop` anschließend nur noch Eingaben aus dem UI lesen, die reine Entscheidung aufrufen und genau die bestehende Operation ausführen. 5. Verändere keine Persistenzreihenfolge, keine API-Payloads und kein optimistisches UI-/Rollback-Verhalten. ### Charakterisierungstests vor der Extraktion Formuliere mit den tatsächlich vorhandenen Quell- und Zieltypen mindestens folgende Given-When-Then-Fälle: - gültiger Task-Drop zwischen zwei Tageszielen - gültiger Drop zwischen Tagesraster und Kanban/Someday, sofern unterstützt - Drop auf dasselbe Ziel ohne unnötige Persistenzänderung - ungültige oder unvollständige Drag-Daten - durch eine bestehende Guard Condition gesperrter Drop - wiederkehrende Aufgabe beziehungsweise einzelnes Serienvorkommen - Kalendereintrag darf nicht versehentlich als Task behandelt werden - Fehler der bestehenden Persistenzoperation erhält das bisherige Rollback-/Fehlerverhalten Nutze beobachtbares Verhalten. Teste die neue reine Funktion direkt und halte mindestens einen vorhandenen Integrations- oder E2E-Test für den vollständigen Nutzerfluss grün. Keine neue Testbibliothek ohne Owner-Freigabe. ### Abnahme für den ersten Schnitt - alle vorher grünen Checks bleiben grün - `handleDrop` besitzt keine tiefe fachliche Verzweigungslogik mehr - mindestens der CodeScene-Befund `Deep, Nested Complexity` für `handleDrop` ist entfernt oder messbar reduziert - `WeeklyView.tsx` wird netto kleiner; neue Logik ist isoliert testbar - keine allgemeine `utils.ts` und keine neue Komponente mit einer großen Anzahl unstrukturierter Props - keine Änderung an API, Datenbank, Authentifizierung oder sichtbarem Verhalten - ein kleiner, eigenständig rücksetzbarer Commit Der nächste CodeScene-Zielwert für den Hotspot ist zunächst **über 2,02**. Ein einzelner kleiner Schnitt gilt aber auch dann als erfolgreich, wenn der Gesamtscore noch nicht springt, sofern der adressierte Befund verschwindet, Komplexität sinkt und alle Verhaltenstests grün bleiben. ## Auftrag 3: Nächste Schnitte nach neuer Freigabe Diese Schritte nicht im selben Commit und nicht ohne erneute Owner-Freigabe umsetzen. ### A. `fetchUserInfo` entflechten - Netzwerkaufruf, Antwortvalidierung, fachliche Ableitung und React-State- Aktualisierung getrennt erfassen. - Pure Transformationen zuerst mit Charakterisierungstests absichern. - Bestehende Lade-, Fehler- und Fallback-Zustände exakt erhalten. - Keine zweite Quelle für Profil- oder Berechtigungsregeln schaffen. ### B. Fallenden Trend von `CalendarEventModal.tsx` stoppen - tatsächliche Verantwortlichkeiten für Formularzustand, Validierung, Wiederholung, Kalenderauswahl und Payload-Erzeugung identifizieren. - Zuerst die stabilste pure Regel extrahieren, nicht sofort die ganze Komponente zerlegen. - Create- und Edit-Modus, Ganztagstermine, Zeitzonen, Wiederholungen und Provider-Auswahl durch Tests schützen. ### C. `calendar-events.ts` modularisieren - Lesen/Normalisieren, Erstellen, Aktualisieren, Löschen und Recurrence als getrennte Verantwortlichkeiten planen. - `getCalendarEvents` zuerst als Pipeline mit benannten Schritten charakterisieren; keine Provider-Semantik vereinheitlichen, die sich real unterscheidet. - Bestehende Kopplungen als Vertragsgrenzen beachten: `apple-calendar.ts` ↔ `calendar-events.ts` 62 %, `calendar-events.ts` ↔ `outlook-calendar.ts` 44 %, API-Route ↔ `calendar-events.ts` 42 %. ### D. Restliche Ziele - `apple-calendar.ts`: zuerst `getUpcomingEventsBatch`, danach `deleteRecurringInstance`. - `GridTaskBlock.tsx`: pure Berechnungen, Interaktionen und Darstellung schrittweise trennen. - `SettingsSidebar.tsx` erst nach den fünf CodeScene-Zielen neu bewerten; der Score ist niedrig, aber die Änderungsreibung geringer. ## Sicherheits- und Regressionstor Die beiden risikoreichsten Commits des letzten Laufs hatten CodeScene-Risiko 7 beziehungsweise 6 und betrafen breit gestreute Security-/Deployment- Änderungen sowie das Next.js-Upgrade. Vor größeren Refactorings muss geklärt sein, dass folgende Pfade geschützt sind: - Login und Rate-Limit - Kalender-Connect und -Sync - Verschlüsselung neuer und Lesen bestehender Zugangsdaten - Next.js-15-Routen mit asynchronen `params` - fehlgeschlagenes Deployment, Smoke-Test und Rollback - Produktions-Build mit der vorgesehenen Umgebungskonfiguration Keine echten Zugangsdaten, Tokens, Kalenderinhalte oder personenbezogenen Daten in Tests oder Logs verwenden. ## CodeScene-Scope vor der nächsten Baseline Empfiehl dem Owner separat, diese nicht repräsentativen Pfade auszuschließen: ```text **/Version 01/**;**/.opencode/**;**/tests/debug/**;**/.next/**;**/playwright-report/**;**/test-results/** ``` Die Scope-Bereinigung nicht mit einem Refactoring-Commit vermischen. `package.json` und `package-lock.json` sind wegen der vorgeschriebenen Versionspflege Änderungshotspots, aber keine manuellen Optimierungsziele. ## Verbotene Abkürzungen - kein Big-Bang-Rewrite - keine Feature-, API-, Payload- oder Schemaänderung im Refactoring - keine neue Dependency ohne ausdrückliche Freigabe - keine neue allgemeine `utils`-, `helpers`- oder God-Komponente - keine Tests löschen, Erwartungen abschwächen oder Typprüfung unterdrücken - kein `any`, `@ts-nocheck` oder pauschales ESLint-Disable als Ausweg - keine Optimierung ausschließlich auf einen CodeScene-Score - keine Änderung der Git-Historie ## Gewünschte erste Antwort Antworte vor jeder Codeänderung ausschließlich mit: 1. verifiziertem `HEAD`, Branch und Worktree-Status 2. Abweichungen von der CodeScene-Baseline 3. Entscheidungstabelle für `handleDrop` 4. vorgeschlagener exakter Funktionssignatur und Modulgrenze 5. konkreten Charakterisierungstests 6. betroffenen Dateien und erwarteter Diff-Größe 7. auszuführenden Checks 8. Risiken und Rückfallmöglichkeit 9. offenen Fragen an den Owner Warte danach auf ein ausdrückliches **Go**. Setze nur den freigegebenen ersten Schnitt um und liefere anschließend Testergebnisse, Diff-Zusammenfassung und den Vergleich mit einer neuen CodeScene-Analyse.
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#2
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?