Beim Vermessen der Struktur zeigte sich: In WeeklyView.tsx stecken acht
eigenstaendige Komponenten mit zusammen rund 1.870 Zeilen, die gar nichts
mit der Wochenansicht zu tun haben. Sie haben bereits eigene Props -- der
Schnitt braucht also kein Props-Design, nur die richtigen Importe.
Drei davon sind jetzt heraus, unter src/components/weekly/. Die Symbolliste
projectIconsGlobal ist zu ProjectIcon gewandert, wo sie als einzige
gebraucht wird.
11.556 -> 11.148 Zeilen.
Der scharfe Typecheck aus v1.118.1 hat sich hier zum ersten Mal richtig
ausgezahlt: Er nannte in 19 Sekunden praezise jeden fehlenden Import, in
mehreren schnellen Runden. Vor C1 haette der Build all das stumm
durchgewunken -- und die Fehler waeren erst im Browser aufgeschlagen.
Verifiziert: Typecheck 0 Fehler, npm run build Exit 0, 63 Unit-Tests gruen.
v1.119.1
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei UI-Wuensche aus der Wochenansicht (TODO.md Block I).
Der Spaltenkopf ist position: sticky und deckte mit --weekly-bg ab -- die
Hervorhebung des heutigen Tages begann daher erst unterhalb von Wochentag
und Datum. Jetzt faerbt sich der Kopf mit.
Die Symbole sitzen statt unten rechts oben rechts. Damit Titel und Uhrzeit
nicht darunter laufen, bekommen sie rechts Freiraum -- ueber
:has(.event-icons-row) nur dort, wo ueberhaupt Symbole erscheinen. Fuer
beide Darstellungen umgesetzt: Zeitraster und Liste.
Verifiziert: npm run build Exit 0. Das Ergebnis ist rein visuell und daher
nur im Browser wirklich pruefbar.
v1.119.0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Dateien schalteten die Typpruefung komplett ab und blieben deshalb auch
von ignoreBuildErrors: false unberuehrt -- eine Luecke im gerade erst
geschlossenen Netz.
- calendar-cache.ts brauchte die Ausnahme gar nicht: ohne sie null Fehler.
- microsoft-todo.ts hatte vier Faelle zirkulaerer Typinferenz
(url -> data -> response -> url), aufgeloest durch explizite Annotationen.
- outlook-calendar.ts verbarg einen moeglichen Laufzeitfehler: Der Code
streute response!-Assertions, eine Stelle war vergessen. Statt noch einer
Assertion prueft er jetzt echt, ob nach drei Wiederholversuchen ueberhaupt
eine Antwort vorliegt.
Ausserdem Block I in TODO.md: Hervorhebung des aktuellen Tages im
Spaltenkopf und die Symbole in Kalenderterminen nach oben rechts, beide mit
Fundstelle in globals.css.
Verifiziert: Typecheck 0 Fehler, npm run build Exit 0.
v1.118.2
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
typescript.ignoreBuildErrors steht jetzt auf false. Ein erfolgreicher Build
ist damit wieder ein Beleg dafuer, dass der Code uebersetzbar ist.
Die Ursache der 30-Minuten-Laufzeit war nicht die Groesse von WeeklyView.tsx,
wie ich vermutet hatte, sondern das include-Muster **/* in tsconfig.json. Auf
src/**/* eingegrenzt laeuft der volle Typecheck in 19 Sekunden.
Die sieben gefundenen Fehler:
- notion-calendar.ts rief notion.databases.query() auf. Die Methode gibt es
in @notionhq/client v5 nicht mehr -- die Notion-Anbindung war zur Laufzeit
schlicht kaputt und niemandem aufgefallen. Migriert auf dataSources.query(),
aber mangels Notion-Zugang ungetestet. Gespeicherte Verbindungen enthalten
alte database_ids und muessen neu eingerichtet werden.
- WeeklyView.tsx importierte isAllDayEvent noch aus format statt date-utils
-- mein eigener Fehler aus v1.118.0, der ohne scharfen Typecheck
durchgerutscht war.
- Export-Helfer lagen in einer route.ts, wo Next.js nur Route-Handler
erlaubt; SettingsSidebar importierte sie von dort und zog einen
Server-Handler in den Client-Graphen. Jetzt in src/lib/export-fields.ts.
- push-notifications.ts: BufferSource-Cast fuer applicationServerKey.
- web-push hat keine Typen; lokale Deklaration statt neuer Abhaengigkeit.
Verifiziert: npm run build Exit 0 mit scharfem Typecheck, 63 Unit-Tests gruen.
v1.118.1
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nodes eingebauter Test-Runner mit --experimental-strip-types: keine neue
Abhaengigkeit, keine Browser, keine Datenbank, Laufzeit rund 170 ms.
npm test fuehrt sie aus, npm run test:e2e startet weiterhin Playwright.
Die Tests haben sofort zwei echte Fehler gefunden, die ich beim Auslagern
in v1.117.7 selbst eingebaut hatte:
- isAllDayEvent rief parseCalendarDate ohne Import auf
- resolveViewDays nutzte clampViewDays ohne Import
Beides haette zur Laufzeit einen ReferenceError gegeben. Der Build meldete
nichts, weil typescript.ignoreBuildErrors noch aktiv ist -- genau der Fall,
gegen den C1 laeuft. isAllDayEvent liegt jetzt in date-utils.ts, wo es
thematisch hingehoert; clampViewDays und MAX_VIEW_DAYS in
device-settings.ts, DaysSelector re-exportiert sie.
Geprueft werden ISO-Kalenderwochen gegen bekannte Kalenderdaten, die
Wochenstart-Berechnung inklusive Sonntag-Sonderfall, das Zeitraster, die
12/24-Stunden-Anzeige und der Round-Trip formatDateToISO <-> parseCalendarDate
-- die Bruecke zwischen Datenbank und Anzeige, aus der Ein-Tag-Verschiebungen
entstehen.
Mit npm run build verifiziert (Exit 0).
v1.118.0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dritter Schnitt an WeeklyView.tsx (D1):
- src/lib/weekly/device-settings.ts: Cookie-Helfer plus die vier
Schluessellisten, die bewusst nur im Cookie und nicht in der Datenbank
gehalten werden
- src/lib/weekly/format.ts: stripHtml, invertColor, isAllDayEvent,
getSomedaySlotCount
11.655 -> 11.556 Zeilen. Mit npm run build verifiziert (Exit 0).
Damit sind die reinen Funktionen ohne Komponenten-State heraus, insgesamt
11.906 -> 11.556 (rund 3 %). Der Rest ist die Komponente selbst: JSX und
Handler auf gemeinsamem State. Jeder weitere Schnitt braucht echtes
Props-Design statt Verschieben.
v1.117.7
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zweiter Schnitt an WeeklyView.tsx (D1). 13 reine Funktionen ohne
Komponenten-State: getStartOfWeek, getDayName, getTimeSlots, formatHour,
getWeekNumber, formatCustomHeader und weitere.
11.830 -> 11.655 Zeilen. Mit npm run build verifiziert (Exit 0).
Nebenbefund: getWeekNumber existiert im Projekt dreimal -- hier, in
WeekPrintModal.tsx und in api/user/export-week-view/route.ts. Das Ersetzen
der Duplikate steht in TODO.md; vorher gehoeren die drei Implementierungen
auf Gleichheit geprueft.
v1.117.6
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erster Schritt der Aufteilung von WeeklyView.tsx (D1). Die sieben gemeinsamen
Typen lagen in der Komponentendatei; SettingsSidebar und GridTaskBlock
importierten sie von dort und zogen sich damit die gesamte
11.900-Zeilen-Komponente in ihren Abhaengigkeitsgraphen.
WeeklyView.tsx re-exportiert die Typen weiterhin, bestehende Importe bleiben
also unveraendert -- kein Anfassen der beiden Importeure noetig.
11.906 -> 11.830 Zeilen. Mit npm run build verifiziert: Exit 0, 36 Seiten
generiert, /tasks unveraendert bei 265 kB.
v1.117.5
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
eslint.ignoreDuringBuilds stand auf true, der Build verschluckte also jede
Lint-Meldung. Im gesamten Projekt gab es genau zwei echte Errors -- beide
"let json" statt "const json" in SettingsSidebar.tsx. Behoben, Schalter aus,
next lint endet mit Exit 0.
Die 695 Warnungen (470 no-explicit-any, 209 ungenutzte Variablen, 11
unvollstaendige Hook-Abhaengigkeiten) blockieren den Build nicht. Die
Hook-Warnungen sind davon die interessantesten, weil daraus echte Bugs
entstehen -- stehen als eigener Punkt in TODO.md.
Naechster Schritt ist typescript.ignoreBuildErrors; der volle tsc-Lauf
dauert wegen WeeklyView.tsx ueber 15 Minuten und laeuft noch.
v1.117.4
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
.env.production.save und .env.local geloescht (per shred ueberschrieben) --
beide waren identische Kopien derselben Zugangsdaten. In deployment-notes.md
und INFRASTRUCTURE_REQUIREMENTS.md sind die Klartext-Werte durch Platzhalter
ersetzt, die Dateien bleiben als Dokumentation lesbar.
Ausserhalb der Git-Historie liegt damit kein Zugangsdatum mehr im Projekt.
Das alte NEXTAUTH_SECRET und SMTP_PASSWORD sind laut Nutzer rotiert und
ausser Betrieb; offen bleibt allein der Status des Datenbank-Passworts
(Pruefbefehl in TODO.md Block F).
v1.117.3
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Audit hatte nur src/ nach Passwoertern durchsucht -- zu eng. Betroffen
sind vier getrackte Dateien, nicht eine:
- INFRASTRUCTURE_REQUIREMENTS.md fuehrt das DB-Passwort unverschleiert als
"**Password**: ..." auf, dazu SMTP und NEXTAUTH_SECRET
- deployment-notes.md enthaelt DATABASE_URL und NEXTAUTH_SECRET
- tests/debug/db-connection-test.spec.ts eine Connection-URL samt echter IP
- .env.production.save, der urspruengliche Fund
Die ersten beiden und .env.production.save sind aus dem Index genommen
(lokal bleiben sie), im Testskript ist das Passwort ersetzt. .gitignore
greift jetzt auf .env* statt auf feste Namen -- genau daran war
.env.production.save vorbeigerutscht.
Im Git liegen zwei verschiedene DB-Passwoerter: eines aus dem alten
Docker-Compose-Setup (@db:5432, vermutlich tot), eines aus dem
Supabase-Zugang. Ob letzteres noch aktiv ist, klaert der Pruefbefehl
in TODO.md Block F.
v1.117.2
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erste Abarbeitung des Repository-Audits (siehe TODO.md).
Sicherheit:
- Rate-Limiting für alle vier Auth-Endpunkte. Sie waren unbegrenzt aufrufbar,
also beliebig viele Mails über den eigenen SMTP-Zugang und beliebig viele
Rateversuche auf Verifizierungscodes.
- Passwort-Reset-Token nur noch als SHA-256-Hash in der Datenbank. Bisher
Klartext: Lesezugriff auf die DB genuegte zur Kontouebernahme.
- Tote Mock-Login-Route entfernt. Sie verglich gegen ein hartcodiertes
Fake-Passwort und war ueber die Middleware-Ausnahme fuer /api/auth/*
ohne Anmeldung erreichbar.
- Passwort-Reset auf bcrypt-Kosten 12, wie beim Signup.
Reparaturen:
- npm test rief jest auf, obwohl es weder Jest-Config noch Jest-Tests gibt.
Zeigt jetzt auf Playwright; jest/ts-jest/@types/jest entfernt.
- Falscher sonar.projectKey im Workflow.
Verifiziert per tsc gegen die geaenderten Bereiche: keine neuen Typfehler.
v1.117.0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
