refactor: rebuild template — Tailwind v4, Docker self-hosting, passkey auth

Toolchain fixes (all previously broken): - npm run lint: next lint was removed in Next 16 -> eslint with flat config - .eslintrc.json was ignored by ESLint 9 -> eslint.config.mjs - npm test / test:e2e exited 1 with no tests -> passWithNoTests - Vitest scanned tests/ and would have run Playwright specs -> scoped to src/ - Playwright targeted Mobile Safari while docs installed only chromium - reuseExistingServer silently tested a foreign server on :3000 -> E2E_PORT - 11 high-severity vulns -> npm audit fix - deny rule Read(**/.env*) also blocked .env.example -> precise patterns Stack changes: - Tailwind v3 -> v4 (CSS-first, no tailwind.config.ts, tw-animate-css) - shadcn regenerated for v4; 33 components -> 6 core, bundled radix-ui - Supabase removed entirely; data layer is now chosen per project - Vercel removed; Docker Compose self-hosting with scripts/update.sh - Better Auth + passkey plugin as the binding auth standard - ThemeProvider and Sonner mounted; dark mode and toasts now actually work Workflow system: - Sub-agents wired: /frontend, /backend, /qa delegate to .claude/agents - Checklists folded into their SKILL.md; one file per skill - Rules rewritten: DB-agnostic backend, passkey security, v4 frontend - Spec language settled as German, skill instructions English
2026-08-09 00:48:50 +02:00
parent a8b196e92b
commit b0c4e9e9b9
101 changed files with 3651 additions and 7695 deletions
@@ -1,21 +1,24 @@
 # Feature Index

-> Central tracking for all features. Updated by skills automatically.
+> Zentrales Tracking aller Features. Wird von den Skills automatisch gepflegt.

-## Status Legend
- **Roadmap** - `/init` done, feature identified in feature map, no spec file yet
- **Planned** - `/write-spec` done, full spec written, architecture not yet designed
- **Architected** - `/architecture` done, tech design approved, ready to build
- **In Progress** - `/frontend` or `/backend` active or completed, not yet in QA
- **In Review** - `/qa` active, testing in progress
- **Approved** - `/qa` passed, no critical/high bugs, ready to deploy
- **Deployed** - `/deploy` done, live in production
+## Status
+
+`Roadmap` → `Planned` → `Architected` → `In Progress` → `In Review` → `Approved` → `Deployed`
+
+| Status | Bedeutung |
+|--------|-----------|
+| Roadmap | In `/init` identifiziert, noch keine Spec-Datei |
+| Planned | `/write-spec` fertig — Spec geschrieben |
+| Architected | `/architecture` fertig — technisches Design steht |
+| In Progress | `/frontend` oder `/backend` läuft oder ist fertig |
+| In Review | `/qa` läuft |
+| Approved | `/qa` bestanden, keine Critical/High-Bugs |
+| Deployed | `/deploy` fertig, live |

 ## Features

-| ID | Feature | Status | Spec | Created |
-|----|---------|--------|------|---------|
+| ID | Feature | Priorität | Abhängigkeiten | Status | Spec |
+|----|---------|-----------|----------------|--------|------|

-<!-- Add features above this line -->
-
-## Next Available ID: PROJ-1
+## Nächste freie ID: PROJ-1
@@ -1,112 +0,0 @@
-# Feature Specifications
-
-Dieser Ordner enthält detaillierte Feature Specs vom Requirements Engineer.
-
-## Naming Convention
-`PROJ-X-feature-name.md`
-
-Beispiele:
- `PROJ-1-user-authentication.md`
- `PROJ-2-kanban-board.md`
- `PROJ-3-file-attachments.md`
-
-## Was gehört in eine Feature Spec?
-
-### 1. User Stories
-Beschreibe, was der User tun möchte:
-```markdown
-Als [User-Typ] möchte ich [Aktion] um [Ziel zu erreichen]
-```
-
-### 2. Acceptance Criteria
-Konkrete, testbare Kriterien:
-```markdown
- [ ] User kann Email + Passwort eingeben
- [ ] Passwort muss mindestens 8 Zeichen lang sein
- [ ] Nach Registration wird User automatisch eingeloggt
-```
-
-### 3. Edge Cases
-Was passiert bei unerwarteten Situationen:
-```markdown
- Was passiert bei doppelter Email?
- Was passiert bei Netzwerkfehler?
- Was passiert bei gleichzeitigen Edits?
-```
-
-### 4. Tech Design (vom Solution Architect)
-```markdown
-## Database Schema
-CREATE TABLE tasks (...);
-
-## Component Architecture
-ProjectDashboard
-├── ProjectList
-│   └── ProjectCard
-```
-
-### 5. QA Test Results (vom QA Engineer)
-Am Ende des Feature-Dokuments fügt QA die Test-Ergebnisse hinzu:
-```markdown
---
-
-## QA Test Results
-
-**Tested:** 2026-01-12
-**App URL:** http://localhost:3000
-
-### Acceptance Criteria Status
- [x] AC-1: User kann Email + Passwort eingeben
- [x] AC-2: Passwort mindestens 8 Zeichen
- [ ] ❌ BUG: Doppelte Email wird nicht abgelehnt
-
-### Bugs Found
-**BUG-1: Doppelte Email-Registrierung**
- **Severity:** High
- **Steps to Reproduce:** 1. Register with email, 2. Try again with same email
- **Expected:** Error message
- **Actual:** Silent failure
-```
-
-### 6. Deployment Status (vom DevOps Engineer)
-```markdown
---
-
-## Deployment
-
-**Status:** ✅ Deployed
-**Deployed:** 2026-01-13
-**Production URL:** https://your-app.vercel.app
-**Git Tag:** v1.0.0-PROJ-1
-```
-
-## Workflow
-
-1. **Requirements Engineer** erstellt Feature Spec
-2. **User** reviewed Spec und gibt Feedback
-3. **Solution Architect** fügt Tech-Design hinzu
-4. **User** approved finales Design
-5. **Frontend/Backend Devs** implementieren (dokumentiert via Git Commits)
-6. **QA Engineer** testet und fügt Test-Ergebnisse zum Feature-Dokument hinzu
-7. **DevOps** deployed und fügt Deployment-Status zum Feature-Dokument hinzu
-
-## Status-Tracking
-
-Feature-Status wird direkt im Feature-Dokument getrackt:
-```markdown
-# PROJ-1: Feature Name
-
-**Status:** 🔵 Planned | 🟡 In Progress | ✅ Deployed
-**Created:** 2026-01-12
-**Last Updated:** 2026-01-12
-```
-
-**Status-Bedeutung:**
- 🔵 Planned – Requirements sind geschrieben, ready for development
- 🟡 In Progress – Wird gerade gebaut
- ✅ Deployed – Live in Production
-
-**Git als Single Source of Truth:**
- Alle Implementierungs-Details sind in Git Commits
- `git log --grep="PROJ-1"` zeigt alle Änderungen für dieses Feature
- Keine separate FEATURE_CHANGELOG.md nötig!