9 Commits

Include renames

Author	SHA1	Message	Date
florian.wilde	afe57c4428	Suche ueber Aufgaben ... Zwei Luecken, die im Issue zusammen stehen. **Im Aufgabendashboard fehlte ein Suchfeld.** Es gab Filter nach Status und Projekt, aber keine Moeglichkeit, nach einem Wort zu suchen. Das Suchfeld deckt Titel, Beschreibung, Labels und Projektname ab. Gefiltert wird im Browser - die Aufgaben liegen dort ohnehin alle vor, es braucht also keine zusaetzliche Abfrage und es gibt keine Verzoegerung beim Tippen. Wer sucht, sucht dabei auch in Erledigtem: sonst faende man die Aufgabe von letzter Woche nicht wieder, obwohl man genau sie meint. Der Schalter "Erledigte einblenden" gilt nur ohne Suchbegriff. **Die Volltextsuche kannte nur Notizen.** Task ist jetzt ebenfalls dabei, nach demselben Muster: deutsche Textsuche, ts_headline fuer den Ausschnitt, Hervorhebung als [[…]] statt als HTML. Deutsche Stammformen greifen damit auch hier - "Rechnung" findet "Rechnungen". Dazu ein Ausdrucksindex Task_fulltext_idx wie Note_fulltext_idx. Der Ausdruck muss Zeichen fuer Zeichen dem in der Abfrage entsprechen, sonst greift er nicht; nachgeprueft mit EXPLAIN, der Plan zeigt einen Bitmap Index Scan darauf. "prisma migrate diff" laesst ihn in Ruhe - Gegenprobe kommt leer heraus. Das Antwortfeld heisst weiterhin "hits" und meint die Notizen. Umbenennen haette nur Aufrufer gebrochen, ohne etwas zu verbessern; Aufgaben kommen als eigenes Feld dazu. Beide Stellen, die Treffer anzeigen - Projektbrett und Schnellsuche -, zeigen sie jetzt. Geprueft: 261 Unit-Tests, 36 E2E-Tests. Die Volltextsuche zusaetzlich gegen die laufende Anwendung: Treffer in Titel und Beschreibung, Erledigtes inbegriffen, Stammformen greifen, fremde Konten finden nichts. Refs #4	2026-08-18 03:39:02 +02:00
florian.wilde	9cdd51fba8	Globale Zeitleiste ueber alle Projekte ... Eine Seite /verlauf, die den Aktivitaetsverlauf fortlaufend ueber alle Projekte zeigt - ohne Wochengrenze, nach Kalendertagen gegliedert, mit Nachladen aelterer Eintraege. Erste Seite serverseitig, alles Weitere ueber /api/activity. Geblaettert wird per Cursor ueber (createdAt, id), nicht per skip. Der Verlauf schreibt mehrere Eintraege im selben Augenblick - beim Uebernehmen von Issues entstehen zehn Zeilen mit identischem Zeitstempel. Ein Offset ueber eine solche Grenze hinweg ueberspringt Zeilen oder zeigt sie zweimal, und zwar lautlos. Der zweite Zweig der Bedingung (gleicher Zeitpunkt, kleinere ID) faengt genau das ab. Geprueft gegen 144 Eintraege mit absichtlichen Bloecken gleicher Zeitstempel: 15 Seiten, 144 Zeilen, keine Dublette, streng absteigend. Die Bedingung selbst steht als pruefbare Funktion in lib/timeline, samt Deckelung der Seitengroesse und Abweisen unbrauchbarer Cursor - eine ID aus der Abfragezeichenkette geht nicht ungeprueft in die Abfrage. Damit Rueckblick und Zeitleiste wirklich gleich aussehen, sind Zeile und Tagesgruppen nach components/ActivityRow gewandert. Bewusst ohne "use client" und ohne Hooks, damit beides sowohl aus der Server-Komponente (Rueckblick) als auch aus der Client-Komponente (Zeitleiste) heraus benutzbar ist. Die Buendelung im Browser ist unbedenklich, weil tagesschluessel eine feste Zeitzone benutzt - Server und Browser kommen auf denselben Kalendertag. Erreichbar ueber die Schnellsuche und vom Wochenrueckblick aus. Geprueft: 9 neue Unit-Tests zur Cursor-Logik, ein E2E-Test, der die ganze Liste in Dreierseiten durchblaettert und gegen einen einzelnen grossen Aufruf haelt, ein E2E-Test fuer die Seite, axe-core auf 375px und 1280px je vor und nach dem Nachladen ohne Beanstandung. Refs #3	2026-08-18 01:54:50 +02:00
florian.wilde	52f2d0ce8e	Wochenrueckblick ueber alle Projekte ... Eine Seite, die aus dem vorhandenen Aktivitaetsverlauf zusammenfasst, was in einer Woche ueber alle Projekte hinweg passiert ist: Kennzahlen oben, darunter die Vorgaenge nach Kalendertagen gebuendelt, neuester Tag zuerst. Blaettern in frueher Wochen ueber ?woche=-n. Der Verlauf kennt keinen Besitzer - die Trennung laeuft ueber das Projekt, "project: { ownerId }" steht als erste Bedingung. Zwei Dinge, die sonst still falsch werden: - **Wochengrenzen** stehen als pruefbare Funktion in lib/review, nicht in der Seite. Gerechnet wird ueber Berliner Kalendertage, nicht ueber "sieben mal 24 Stunden": liegt eine Zeitumstellung in der Woche, hat sie 167 oder 169 Stunden. Und im Container laeuft die Anwendung nach UTC, ein Eintrag von Sonntagabend fiele sonst in die falsche Woche. - **"Aufgaben erledigt"** wird am meta-Feld abgelesen (to: "DONE") und nicht am Anzeigetext. Der Text ist zum Lesen da und aendert sich mit der Formulierung; eine Zaehlung daran wuerde beim naechsten umformulierten Einzeiler unbemerkt kippen. Eintraege ohne meta zaehlen nicht mit - lieber untertreiben als raten. Damit completeTaskFromIssue dieselbe Grundlage liefert, schreibt es jetzt ebenfalls from/to ins meta, wie es das Verschieben von Hand schon tut. Die Zuordnung Symbol/Farbe je Eintragsart lag bisher in ActivityFeed und wird jetzt von zwei Stellen gebraucht - herausgezogen nach components/activityKinds, sonst laufen die Kopien beim naechsten neuen Eintragstyp auseinander. Erreichbar ueber die Schnellsuche und einen Verweis vom Dashboard. Bewusst kein vierter Punkt in der Kopfleiste - die ist auf dem Telefon schon eng. Geprueft: 20 neue Unit-Tests (Wochengrenzen inklusive beider Zeitumstellungen, Jahreswechsel, Zaehlung), ein E2E-Test ueber Aufruf und Blaettern, axe-core auf 375px und 1280px ueber drei Zustaende - auch die leere Woche - ohne Beanstandung, kein seitlicher Ueberlauf. Refs #2	2026-08-18 00:55:02 +02:00
florian.wildeandClaude Opus 5	6a7365946b	fix(ui): Dialoge weichen der Bildschirmtastatur aus ... Auf dem Telefon verdeckte die Tastatur den halben Dialog – bei der Schnellerfassung genau das Eingabefeld, um das es geht. Ursache ist der Unterschied zwischen Layout- und Sichtfenster: die Tastatur schiebt sich darueber, ohne dass sich fuer die Seite etwas aendert. "position: fixed" und "100vh" beziehen sich weiter auf das volle Fenster, ein mittig stehender Dialog liegt damit zur Haelfte darunter. Der Dialog richtet sich jetzt nach window.visualViewport – Hoehe und oberer Rand kommen von dort und werden bei jeder Aenderung nachgefuehrt. Weil der Behaelter scrollbar ist, holt der Browser das fokussierte Feld dann von selbst ins Bild. Das gilt fuer alle Dialoge, nicht nur die Schnellerfassung. Dazu, weil es beim Nachsehen auffiel: Aufgaben lassen sich in der Uebersicht direkt bearbeiten. Bisher fuehrte von dort nur der Weg ins Projekt, und wer eine Faelligkeit aendern wollte, musste die Aufgabe im Brett wiederfinden. Der Dialog nimmt dafuer eine schlankere Form entgegen als den vollstaendigen Prisma-Datensatz. Geprueft mit einem nachgestellten Sichtfenster: Eingabefeld und Absende- knopf liegen bei 375x667 und aufgeklappter Tastatur vollstaendig im freien Bereich. Vorher lagen beide darunter. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-15 00:34:56 +02:00
florian.wildeandClaude Opus 5	5ae1b6ed06	feat(tasks): Schnellerfassung und Aufgaben ueber alle Projekte ... Zwei Wege, die zusammengehoeren: etwas festhalten, ohne den Rechner aufzuklappen, und danach einen Ort haben, an dem alles zusammenlaeuft. **Schnellerfassung.** Ein Blitzsymbol in der Kopfleiste, auf jeder Seite erreichbar. Ein Feld, Enter, fertig - als Idee entsteht ein Projekt im Status IDEA, als Aufgabe eine Aufgabe im gewaehlten Projekt. Beide Schemas kommen mit einem einzigen Feld aus, an der API war deshalb nichts zu aendern. Der Dialog bleibt nach dem Anlegen offen und leert nur das Feld. Wer eine Idee notiert, hat meistens gleich die naechste; ihn jedes Mal neu zu oeffnen waere genau die Huerde, die hier wegsoll. Das zuletzt gewaehlte Projekt wird gemerkt. Der Einstieg sitzt in der Kopfleiste und nicht als schwebender Knopf unten rechts - dort waere er auf schmalen Anzeigen mit der Auswahlleiste kollidiert, die beim Markieren von Projekten einfaehrt. **Aufgabenuebersicht.** /tasks sammelt jede Aufgabe aus jedem Projekt. Geordnet wird nach Faelligkeit, nicht nach Spalte: projektuebergreifend lautet die Frage "was ist ueberfaellig", nicht "was steht wo im Brett". Abhaken geht direkt aus der Liste; den Rest - Zeitpunkt, abgeleiteter Fortschritt, naechste Fassung wiederkehrender Aufgaben - erledigt der bestehende Endpunkt. Zwei Entscheidungen, die im Code begruendet sind: - Gerechnet wird auf Kalendertage in fester Zeitzone, nicht auf Stunden und nicht nach Serverzeit. Eine um 9 Uhr faellige Aufgabe ist um 17 Uhr nicht ueberfaellig, sondern immer noch "heute". Und im Container laeuft die Anwendung nach UTC - ohne feste Zeitzone kippte die Einteilung abends um einen Tag. Das Fach bestimmt der Server, sonst liefen Server-Render und Hydration auseinander. - Bewusst nicht per Ziehen sortierbar. Die Position gilt innerhalb ihrer Spalte in ihrem Projekt und waere hier ohne Bedeutung; eine Reihenfolge anzubieten, die nirgends ankommt, waere ein leeres Versprechen. Die Aufgabe kennt keinen Besitzer - die Trennung laeuft ueber das Projekt, "project: { ownerId }" steht als einzige und erste Bedingung. Nebenbei: der Untertitel in der Kopfleiste brach mit dem dritten Navigationspunkt auf 375px mitten im Wort ab und bleibt unterhalb von sm jetzt weg. Geprueft: 200 Unit-Tests (davon 7 neue zu dueBucket, inklusive des UTC-Falls), 27 E2E-Tests mit zwei neuen Wegen, axe-core auf 375px ueber Uebersicht und beide Zustaende der Schnellerfassung ohne Beanstandung. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-14 23:33:16 +02:00
florian.wildeandClaude Opus 5	f3c3383231	feat(board): Listenansicht, und die mobile Ansicht laeuft nicht mehr aus dem Bild ... Auf 375px war das Dashboard 40px breiter als der Bildschirm. Ursache war die Steuerleiste: Suchfeld, Sortierung, Ansichtsumschalter und "Neues Projekt" lagen in einer Flex-Zeile ohne Umbruch, und weil das Sortierfeld ein min-width mitbringt, wurde der Knopf am Ende schlicht hinausgeschoben. Das overflow-x: hidden am body hat ihn dann abgeschnitten statt erreichbar zu lassen. Dasselbe Muster im Projektkopf, wo "Loeschen" ausserhalb lag. Die Zeilen brechen jetzt um, der Ansichtsumschalter steht auf schmalen Anzeigen ueber die volle Breite. Gemessen ueber alle Seiten und beide Testbreiten: scrollWidth == clientWidth. Weil der Umschalter ohnehin umgebaut wurde, kommt die vierte Ansicht gleich mit: eine Zeile je Projekt statt einer Karte. Auf dem Telefon ist das der eigentliche Gewinn — eine Karte braucht rund 260px Hoehe und steht dort zwangslaeufig allein in der Zeile, fuenf Projekte fuellen also zwei Bildschirme. Als Liste passen sie auf einen, und weil alle Zeilen gleich gebaut sind, liegen Name, Fortschritt und Status untereinander. Was nicht mehr in die Breite passt, faellt der Reihe nach weg, statt sie zu sprengen. Dazu die Kleinigkeiten, die auf dem Telefon dranhaengen: - .field bekommt auf Beruehrungsgeraeten 16px. Darunter zoomt iOS Safari beim Hineintippen die Seite heran und kehrt nicht von selbst zurueck. - .btn mindestens 44px hoch, der Schieberegler einen 24px-Griff. - Der Popover klemmt seine Breite ans Fenster. Unter 280px lieferte die Rechnung eine negative linke Kante, das Menue stand halb ausserhalb. - Das Tag-Formular der Auswahlleiste war 16px breiter als sein Popover und wurde von dessen overflow-hidden beschnitten – auf jeder Breite. - Die Heatmap scrollt wieder seitlich, statt sich zu stauchen. - Die Kennzahlen stehen zweispaltig; einspaltig fuellten die fuenf Kacheln den ganzen ersten Bildschirm, bevor das erste Projekt kam. - viewportFit und die safe-area-Abstaende, damit im installierten Betrieb nichts unter Statusleiste und Home-Anzeige verschwindet. - Die beiden Verweise in der Kopfleiste und "Neues Projekt" tragen ein aria-label. Unterhalb von sm sind sie reine Symbole und hiessen fuer einen Screenreader gar nichts; axe-core meldete das als link-name. axe-core laeuft auf 375px ueber alle vier Ansichten, den Dialog und die Projektseite jetzt ohne Beanstandung. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-14 01:58:27 +02:00
florian.wildeandClaude Opus 5	fce0a90cc3	chore: prisma.config.ts, Tests und Doku, Version 1.1.0 ... Prisma liest seine Einstellungen aus prisma.config.ts statt aus der package.json; die Warnung vor Prisma 7 ist damit weg. Der dotenv-Aufruf darin ist nicht optional: sobald die Datei existiert, laedt Prisma die .env nicht mehr von selbst, und migrate deploy staende ohne DATABASE_URL da. Vier neue Ende-zu-Ende-Tests: Reihenfolge und Mehrfachauswahl ueber die API, Mehrfachauswahl in der Oberflaeche, der Aenderungsverlauf und das Manifest samt Symbolen ohne Anmeldung. Damit sind es 21. Der Test zum Ziehen von Aufgaben war gelegentlich rot, ohne dass etwas kaputt war: das Neuladen brach den noch laufenden Speicheraufruf ab. Er wartet jetzt auf die Antwort, statt auf eine feste Pause zu hoffen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 14:30:44 +02:00
florian.wildeandClaude Opus 5	fa5fd78318	test: Schnellsuche und Issue-Uebernahme abdecken, Version 0.9.0 ... Zwei neue Ende-zu-Ende-Tests: die Palette findet Projekt und Notiz und oeffnet den Treffer mit Enter; die Uebernahme meldet ohne Repo-Stand einen Hinweis statt still zu scheitern. Damit sind es 15. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:36:44 +02:00
florian.wildeandClaude Opus 5	6e63fec49b	test: Ende-zu-Ende-Tests mit Playwright ... 13 Tests gegen die gebaute Anwendung mit eigener Datenbank auf Port 3111 - also durch Middleware, Authentifizierung, Validierung und Datenbank hindurch. Genau die Schicht, die Unit-Tests nicht erreichen. Laufzeit rund 20 Sekunden. api.spec.ts prueft, was bisher nur von Hand geprueft war: - Einrichtung sperrt sich nach dem ersten Konto - ohne Anmeldung liefert jeder Endpunkt 401 - fremdes Origin und falscher Content-Type werden abgewiesen - SSRF-Sperren greifen - Datentrennung: ein zweites Konto bekommt auf fremde Projekte, Aufgaben und Adminwege durchgaengig 404 beziehungsweise 403, das Original bleibt unveraendert - Aufgaben: Reihenfolge, abgeleiteter Fortschritt, untergeschobene IDs - Export ohne Geheimnisse, Import je Strategie ui.spec.ts geht den Weg eines Menschen: anmelden, Projekt anlegen, Aufgaben anlegen und ziehen, suchen, abmelden. Das Ziehen wird nach einem Neuladen erneut geprueft - sonst waere nur die Anzeige getestet, nicht das Speichern. Zwei Vorkehrungen: - global-setup.ts bricht ab, wenn der Datenbankname nicht "test" enthaelt, und zwar vor dem TRUNCATE. Der teuerste denkbare Fehler waere eine Testreihe, die die Produktivdaten leert. - Playwright startet den Server selbst mit eigener DATABASE_URL und eigenem Port; eine laufende Instanz auf 3000 stoert nicht. Beim Schreiben zeigte sich, dass synthetische Zieh-Gesten eine Pause vor dem Loslassen brauchen - dnd-kit wertet die Bewegung in einem eigenen Frame aus und faende sonst kein Ziel. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 09:50:36 +02:00