docs: v0.3.0 und v0.4.0 dokumentieren, Roadmap fortschreiben
FEATURES beschreibt Markdown, Volltextsuche, PR- und Issue-Listen, den CI-Status samt Herkunft je Git-System, die Aktivitaetskurve inklusive ihrer Grenze, das Kanban-Board und das Testfundament. ROADMAP: sieben Punkte wandern zu den erledigten. Ganz oben steht jetzt der Ausbau der Tests auf Datenbank und Browser - das Fundament steht, die Schicht darueber fehlt und ich pruefe weiterhin von Hand. Danach Benachrichtigungen, die von CI-Status und Abgleich nun profitieren wuerden. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
+34
-58
@@ -11,101 +11,74 @@ Was bereits steht, listet [FEATURES.md](FEATURES.md).
|
||||
|
||||
## 1 · Als Nächstes empfohlen
|
||||
|
||||
### 1.1 Markdown in Beschreibung und Notizen `S`
|
||||
### 1.1 Tests ausbauen: Datenbank und Browser `L`
|
||||
|
||||
Heute wird alles als reiner Text dargestellt. Mit Markdown werden aus
|
||||
`- [ ] Aufgabe` echte Checklisten, Codeblöcke bekommen Hervorhebung, Links
|
||||
werden klickbar.
|
||||
Das Fundament steht — 51 Unit-Tests der reinen Logik laufen in unter einer
|
||||
Sekunde. Was fehlt, ist die Schicht darüber:
|
||||
|
||||
Zu beachten: HTML muss beim Rendern entfernt werden, sonst reißt es ein
|
||||
XSS-Loch. Mit `react-markdown` plus `rehype-sanitize` ist das sauber lösbar.
|
||||
- **Integrationstests** gegen eine Wegwerf-Datenbank: Datentrennung zwischen
|
||||
Konten, Import-Strategien, Backoff des Abgleichs
|
||||
- **Playwright** für die Wege durch die App: Einrichtung, Anmeldung, Kanban
|
||||
- **CI-Pipeline** bei GitHub oder Gitea Actions
|
||||
|
||||
### 1.2 Volltextsuche über Notizen `S`
|
||||
Ich prüfe bislang alles von Hand, inklusive Screenshots. Das trägt nicht
|
||||
dauerhaft und macht jede weitere Änderung teurer als nötig.
|
||||
|
||||
Die Suche im Board deckt Namen, Kurzbeschreibung und Tags ab — Notizen nicht.
|
||||
Postgres kann das nativ (`tsvector` mit deutscher Konfiguration), also ohne
|
||||
zusätzlichen Dienst.
|
||||
### 1.2 Benachrichtigungen `M`
|
||||
|
||||
### 1.3 Kanban-Board mit Drag & Drop `M`
|
||||
Bei Sync-Fehlern, roter CI, neuen Releases oder Projekten, die lange
|
||||
stillstehen. Kanäle: E-Mail (SMTP), ntfy, generischer Webhook. Zusammen mit
|
||||
dem automatischen Abgleich und dem CI-Status ergibt das ein brauchbares
|
||||
Frühwarnsystem — die Daten liegen bereits vor.
|
||||
|
||||
Die gruppierte Ansicht gibt es schon, aber Statuswechsel geht nur über das
|
||||
Menü. Spalten mit Ziehen und Ablegen wären der natürlichere Weg.
|
||||
### 1.3 Aufgaben und Checklisten `M`
|
||||
|
||||
Bibliothek: `@dnd-kit` — leichtgewichtig, tastaturbedienbar. Auf Mobilgeräten
|
||||
bleibt die Listenansicht.
|
||||
Eigene Entität statt Freitext, mit Häkchen und automatisch berechnetem
|
||||
Fortschritt. Ersetzt das manuelle Schieben des Reglers. Die Markdown-
|
||||
Checklisten in Notizen sind ein Vorgeschmack, aber nicht auswertbar.
|
||||
|
||||
---
|
||||
|
||||
## 2 · Danach
|
||||
|
||||
### 2.1 Offene Pull Requests und Issues als Liste `S`
|
||||
|
||||
Aktuell werden sie nur gezählt. Titel, Autor, Alter und Link wären deutlich
|
||||
nützlicher — die Daten holen wir ohnehin schon ab.
|
||||
|
||||
### 2.2 CI-Status je Branch `M`
|
||||
|
||||
Grün oder rot direkt an der Projektkarte, gespeist aus GitHub Actions,
|
||||
GitLab Pipelines und Gitea Actions. Erfordert je Provider einen weiteren
|
||||
Endpunkt und einen zusätzlichen Token-Scope.
|
||||
|
||||
### 2.3 Webhooks statt Polling `M`
|
||||
### 2.1 Webhooks statt Polling `M`
|
||||
|
||||
Ein Push aktualisiert den Snapshot sofort, statt bis zum nächsten Durchlauf
|
||||
zu warten. Braucht einen öffentlich erreichbaren Endpunkt mit
|
||||
Signaturprüfung je Provider — sinnvoll erst, wenn die Instanz von außen
|
||||
erreichbar ist. Der Zeitplan bleibt als Rückfalllösung.
|
||||
|
||||
### 2.4 Commit-Aktivität als Verlauf `S`
|
||||
### 2.2 Commit-Aktivität als Heatmap `S`
|
||||
|
||||
Kleine Sparkline auf der Karte, Heatmap auf der Projektseite. Datenbasis ist
|
||||
da, es fehlt nur die Darstellung.
|
||||
Die Sparkline gibt es auf Karte und Projektseite. Eine Heatmap über ein Jahr
|
||||
wäre die nächste Ausbaustufe — dafür braucht es allerdings mehr als eine
|
||||
Seite Commits, also Paginierung oder die Statistik-Endpunkte.
|
||||
|
||||
### 2.5 Aufgaben und Checklisten `M`
|
||||
### 2.3 Kanban mit freier Reihenfolge `M`
|
||||
|
||||
Eigene Entität statt Freitext-Notiz, mit Häkchen und automatisch
|
||||
berechnetem Fortschritt. Ersetzt das manuelle Schieben des Reglers.
|
||||
|
||||
### 2.6 Benachrichtigungen `M`
|
||||
|
||||
Bei Sync-Fehlern, neuen Releases oder Projekten, die lange stillstehen.
|
||||
Kanäle: E-Mail (SMTP), ntfy, generischer Webhook. Zusammen mit dem
|
||||
automatischen Abgleich ergibt das ein brauchbares Frühwarnsystem.
|
||||
Heute folgt die Reihenfolge innerhalb einer Spalte der gewählten Sortierung.
|
||||
Frei sortieren hieße, eine Position je Projekt zu speichern.
|
||||
|
||||
---
|
||||
|
||||
## 3 · Größere Brocken
|
||||
|
||||
### 3.1 Automatisierte Tests und CI `L`
|
||||
|
||||
Aktuell prüfe ich jede Änderung von Hand — Typecheck, Build, API-Durchläufe,
|
||||
Browser-Screenshots. Das gehört in eine Pipeline:
|
||||
|
||||
- **Vitest** für die Logik: URL-Parsing, SSRF-Regeln, Passwort-Hashing,
|
||||
Backoff-Berechnung
|
||||
- **Playwright** für die Wege durch die App: Einrichtung, Anmeldung,
|
||||
Datentrennung
|
||||
- **GitHub Actions** oder Gitea Actions, je nachdem wohin du das Repo legst
|
||||
|
||||
Aus meiner Sicht der wertvollste Punkt der ganzen Liste, sobald das Projekt
|
||||
länger lebt: er macht alles Weitere billiger und sicherer.
|
||||
|
||||
### 3.2 Mehrere Repositories je Projekt `M`
|
||||
### 3.1 Mehrere Repositories je Projekt `M`
|
||||
|
||||
Frontend und Backend getrennt, aber ein Projekt. Erfordert eine Zwischentabelle
|
||||
und Anpassungen in der Anzeige.
|
||||
|
||||
### 3.3 Zwei-Faktor per TOTP `M`
|
||||
### 3.2 Zwei-Faktor per TOTP `M`
|
||||
|
||||
Als Alternative zum Passkey — nützlich, wenn die Instanz aus dem Internet
|
||||
erreichbar ist und nicht jedes Gerät Passkeys kann.
|
||||
|
||||
### 3.4 Passwort-Zurücksetzen per E-Mail `M`
|
||||
### 3.3 Passwort-Zurücksetzen per E-Mail `M`
|
||||
|
||||
Heute setzt ein Administrator das Passwort neu. Selbstbedienung braucht SMTP
|
||||
und damit eine weitere Konfiguration — lohnt erst im Mehrbenutzerbetrieb.
|
||||
|
||||
### 3.5 Mehrsprachigkeit `L`
|
||||
### 3.4 Mehrsprachigkeit `L`
|
||||
|
||||
Die Oberfläche ist durchgängig deutsch verdrahtet. Englisch dazu wäre eine
|
||||
Voraussetzung, falls du das Projekt veröffentlichen willst.
|
||||
@@ -117,6 +90,7 @@ Voraussetzung, falls du das Projekt veröffentlichen willst.
|
||||
| Idee | Aufwand | Nutzen |
|
||||
| --- | --- | --- |
|
||||
| Schnellsuche per `Strg+K` | `S` | Springt direkt zu Projekt oder Aktion |
|
||||
| Suchtreffer in Notizen hervorheben | `S` | In der Notiz selbst, nicht nur in der Trefferliste |
|
||||
| Mehrfachauswahl im Board | `S` | Status oder Tags für mehrere auf einmal |
|
||||
| Aktivitätsverlauf je Projekt | `S` | Wer hat wann was geändert |
|
||||
| Projektvorlagen | `S` | Neues Projekt mit vorgefüllten Tags und Notizen |
|
||||
@@ -124,7 +98,7 @@ Voraussetzung, falls du das Projekt veröffentlichen willst.
|
||||
| Eigenes Logo und Farbe | `S` | Ergänzt `APP_NAME` |
|
||||
| PWA-Manifest | `S` | Auf dem Handy als App installierbar |
|
||||
| Barrierefreiheits-Durchsicht | `M` | Fokusreihenfolge, Screenreader, Kontraste |
|
||||
| `prisma.config.ts` | `S` | Beseitigt die Deprecation-Warnung vor Prisma 7 |
|
||||
| `prisma.config.ts` | `S` | Beseitigt die Deprecation-Warnung vor Prisma 7. Achtung: danach lädt Prisma die `.env` nicht mehr von selbst |
|
||||
| Audit-Log für Adminaktionen | `M` | Nachvollziehbar, wer Konten geändert hat |
|
||||
|
||||
---
|
||||
@@ -156,6 +130,8 @@ Damit klar ist, was **nicht** kommt und warum:
|
||||
| Docker- und Standalone-Betrieb | ✓ |
|
||||
| Automatischer Abgleich mit Zeitplan | ✓ |
|
||||
| Export, Import und Sicherung | ✓ |
|
||||
| **v0.3.0** Markdown, Volltextsuche über Notizen, PR- und Issue-Listen, Testfundament | ✓ |
|
||||
| **v0.4.0** Kanban mit Drag & Drop, CI-Status je Branch, Commit-Aktivität | ✓ |
|
||||
|
||||
Zur Entscheidung beim Export: Git-Tokens gehen **nicht** mit. Die Verbindung wird nur
|
||||
beschrieben, das Token ist nach dem Import neu zu hinterlegen. Snapshots bleiben
|
||||
|
||||
Reference in New Issue
Block a user