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

.claude/skills/frontend/SKILL.md

@@ -1,95 +1,84 @@
 ---
 name: frontend
-description: Build UI components with React, Next.js, Tailwind CSS, and shadcn/ui. Use after architecture is designed.
-argument-hint: "feature-spec-path"
+description: Build UI components with React, Next.js, Tailwind v4 and shadcn/ui. Use after architecture is designed.
+argument-hint: "PROJ-X or feature-spec-path"
 user-invocable: true
 ---
 
-# Frontend Developer
+# Frontend
 
-## Role
-You are an experienced Frontend Developer. You read feature specs + tech design and implement the UI using React, Next.js, Tailwind CSS, and shadcn/ui.
+You own the UI phase for one feature. You do the interview and the review with the
+user; the **Frontend Developer** sub-agent does the implementation.
 
-## Before Starting
-1. Read `features/INDEX.md` for project context
-2. Read the feature spec referenced by the user (including Tech Design section)
-3. Check installed shadcn/ui components: `ls src/components/ui/`
-4. Check existing custom components: `ls src/components/*.tsx 2>/dev/null`
-5. Check existing hooks: `ls src/hooks/ 2>/dev/null`
-6. Check existing pages: `ls src/app/`
+## 1. Load context
 
-## Workflow
+1. Read `features/INDEX.md`
+2. Read the feature spec, including its Tech Design section
+3. `ls src/components/ui/` — installed shadcn components
+4. `git ls-files src/components/` — existing custom components
 
-### 1. Read Feature Spec + Design
-- Understand the component architecture from Solution Architect
-- Identify which shadcn/ui components to use
-- Identify what needs to be built custom
+**If the spec has no Tech Design section:**
+> "Für PROJ-X gibt es noch kein technisches Design. Führe zuerst `/architecture` aus —
+> ohne Komponentenstruktur baue ich sonst am Entwurf vorbei."
+→ Stop.
 
-### 2. Clarify Design Requirements
-First check for a project design system: `cat docs/design-system.md 2>/dev/null`
+## 2. Clarify design
 
-If `docs/design-system.md` exists → read it and apply its colors, typography, and component guidelines throughout. Do not ask the user about design choices already covered there.
+Check for a design system: `cat docs/design-system.md 2>/dev/null`
 
-If it does not exist, check for other design files: `ls -la design/ mockups/ assets/ 2>/dev/null`
+If it exists, follow it and do not ask about anything it already answers.
+Otherwise check `ls design/ mockups/ 2>/dev/null`, and if nothing exists, ask the
+user — one question at a time, each with a recommendation:
 
-If no design specs exist at all, ask the user:
-- Visual style preference (modern/minimal, corporate, playful, dark mode)
-- Reference designs or inspiration URLs
-- Brand colors (hex codes or use Tailwind defaults)
-- Layout preference (sidebar, top-nav, centered)
+- Visual style (modern/minimal, corporate, playful)
+- Brand colors, or Tailwind/shadcn defaults
+- Layout (sidebar, top-nav, centered)
+- Interactions beyond the basics (drag & drop, animations)
 
-### 3. Clarify Technical Questions
-- Mobile-first or desktop-first?
-- Any specific interactions needed (hover effects, animations, drag & drop)?
-- Accessibility requirements beyond defaults (WCAG 2.1 AA)?
+## 3. Set status
 
-### 4. Implement Components
-- Create components in `/src/components/`
-- ALWAYS use shadcn/ui for standard UI elements (check `src/components/ui/` first!)
-- If a shadcn component is missing, install it: `npx shadcn@latest add <name> --yes`
-- Only create custom components as compositions of shadcn primitives
-- Use Tailwind CSS for all styling
+Update `features/INDEX.md` and the spec header to **In Progress**. Verify by
+re-reading.
 
-### 5. Integrate into Pages
-- Add components to pages in `/src/app/`
-- Set up routing if needed
-- Connect to backend APIs or localStorage as specified in tech design
+## 4. Delegate implementation
 
-### 6. User Review
-- Tell the user to test in browser (localhost:3000)
-- Ask: "Does the UI look right? Any changes needed?"
-- Iterate based on feedback
+Invoke the **Frontend Developer** sub-agent with:
+- the spec path
+- the design decisions from step 2
+- the component list from the Tech Design
+- the shadcn components already installed
 
-## Context Recovery
-If your context was compacted mid-task:
-1. Re-read the feature spec you're implementing
-2. Re-read `features/INDEX.md` for current status
-3. Run `git diff` to see what you've already changed
-4. Run `git ls-files src/components/ | head -20` to see current component state
-5. Continue from where you left off - don't restart or duplicate work
+Wait for its report. Do not implement in parallel yourself.
 
-## After Completion: Backend & QA Handoff
+## 5. Review with the user
 
-Check the feature spec - does this feature need backend?
+Present the sub-agent's report, then:
+> "Läuft unter http://localhost:3000. Schau es dir an — passt das so?"
 
-**Backend needed if:** Database access, user authentication, server-side logic, API endpoints, multi-user data sync
+Iterate on feedback by sending follow-up instructions to the same sub-agent, so it
+keeps its context.
 
-**No backend if:** localStorage only, no user accounts, no server communication
+## 6. Wrap up
 
-If backend is needed:
-> "Frontend is done! This feature needs backend work. Next step: Run `/backend` to build the APIs and database."
+Verify before declaring done:
+- [ ] `npm run lint`, `npm run typecheck`, `npm run build` pass
+- [ ] Every acceptance criterion has a UI counterpart
+- [ ] shadcn used everywhere it could be; no hand-written duplicates
+- [ ] Loading, error and empty states exist
+- [ ] Responsive at 375 / 768 / 1440px
+- [ ] Spec updated with implementation notes (written **and** re-read)
+- [ ] `features/INDEX.md` status is In Progress
+- [ ] User approved
 
-If no backend needed:
-> "Frontend is done! Next step: Run `/qa` to test this feature against its acceptance criteria."
+## Handoff
 
-## Checklist
-See [checklist.md](checklist.md) for the full implementation checklist.
+Does the feature need a server side (data storage, auth, APIs, cross-device sync)?
 
-After completion, update tracking files:
-- [ ] Feature spec updated with implementation notes
-- [ ] `features/INDEX.md` status updated to "In Progress"
+- Yes → "Frontend steht. Nächster Schritt: `/backend` für APIs und Datenhaltung."
+- No → "Frontend steht. Nächster Schritt: `/qa` zum Testen gegen die Acceptance Criteria."
+
+## Commit
 
-## Git Commit
 ```
 feat(PROJ-X): Implement frontend for [feature name]
 ```