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/rules/general.md

@@ -1,75 +1,70 @@
 # General Project Rules
 
-## New Project Detection (MANDATORY)
-Before starting ANY work, check if the project has been initialized:
-1. Read `docs/PRD.md` - if it still contains placeholder text like "_Describe what you are building_", the project is NOT initialized
-2. Read `features/INDEX.md` - if the features table is empty, no features have been defined
+## Before any work: is the project initialized?
 
-**If the project is not initialized:**
-- Do NOT write any code or create any components
-- Do NOT skip ahead to implementation
-- Instead, tell the user: "This project hasn't been set up yet. Let's start by defining what you want to build. Run `/init` with a description of your idea (e.g. `/init I want to build a task management app`)."
-- If the user already described their idea in the current message, run `/init` automatically with their description
+1. Read `docs/PRD.md` — placeholder text like "_Describe what you are building_" means **not** initialized
+2. Read `features/INDEX.md` — an empty feature table means no features defined
 
-**If the project is initialized but the user requests a feature not yet in INDEX.md:**
-- Guide them to run `/write-spec` first to create the feature spec before any implementation
+**Not initialized:** do not write code or create components. Say:
+> "Dieses Projekt ist noch nicht aufgesetzt. Starte mit `/init` und beschreibe kurz deine Idee
+> (z. B. `/init Ich will eine Aufgabenverwaltung bauen`)."
+
+If the user already described their idea in that same message, run `/init` with it directly.
+
+**Initialized, but the requested feature is not in INDEX.md:** guide the user to `/write-spec` first.
 
 ## Feature Tracking
-- All features are tracked in `features/INDEX.md` - read it before starting any work
-- Feature specs live in `features/PROJ-X-feature-name.md`
-- Feature IDs are sequential: check INDEX.md for the next available number
-- One feature per spec file (Single Responsibility)
-- Never combine multiple independent functionalities in one spec
 
-## Git Conventions
-- Commit format: `type(PROJ-X): description`
-- Types: feat, fix, refactor, test, docs, deploy, chore
-- Check existing features before creating new ones: `ls features/ | grep PROJ-`
-- Check existing components before building: `git ls-files src/components/`
-- Check existing APIs before building: `git ls-files src/app/api/`
+- `features/INDEX.md` is the index — read it before starting anything
+- Specs live in `features/PROJ-X-feature-name.md`, IDs are sequential
+- One feature per spec file. Never combine independent functionality.
 
-## Human-in-the-Loop
-- Always ask for user approval before finalizing deliverables
-- Present options using clear choices rather than open-ended questions
-- Never proceed to the next workflow phase without user confirmation
+## Status Flow
 
-## Status Updates (MANDATORY - Write-Then-Verify)
-After completing work on any feature, you MUST update tracking files. Follow this exact sequence:
+`Roadmap` → `Planned` → `Architected` → `In Progress` → `In Review` → `Approved` → `Deployed`
 
-1. **Read** the feature spec (`features/PROJ-X-*.md`) and `features/INDEX.md` BEFORE editing
-2. **Write** your changes using the Edit tool — do NOT just describe what you would write
-3. **Re-read** the file AFTER editing to verify the changes are actually present
-4. **If changes are missing**, repeat step 2 — never claim updates were made without verifying
+| Status | Set by |
+|--------|--------|
+| Roadmap | `/init` — feature identified, no spec file yet |
+| Planned | `/write-spec` |
+| Architected | `/architecture` |
+| In Progress | `/frontend` or `/backend` |
+| In Review | `/qa` starts |
+| Approved | `/qa` passes with no Critical/High bugs |
+| Deployed | `/deploy` |
 
-**What to update in the feature spec:**
-- Status field in the header (Planned → In Progress → In Review → Deployed)
-- Implementation notes: what was built, what changed, any deviations from the original spec
-- Bug fixes or design changes discovered during implementation
+## Status Updates (write, then verify)
 
-**What to update in `features/INDEX.md`:**
-- Feature status column must match the feature spec header
-- Valid statuses: Roadmap → Planned → Architected → In Progress → In Review → Approved → Deployed
-  - **Roadmap**: after `/init` — feature identified, no spec file yet
-  - **Planned**: after `/write-spec`
-  - **Architected**: after `/architecture`
-  - **In Progress**: after `/frontend` or `/backend` starts
-  - **In Review**: after `/qa` starts
-  - **Approved**: after `/qa` passes (no critical/high bugs)
-  - **Deployed**: after `/deploy`
+1. **Read** the spec and `features/INDEX.md` before editing
+2. **Write** with the Edit tool — describing the change in chat is not doing it
+3. **Re-read** the file afterwards to confirm the change landed
+4. If it did not land, repeat step 2
 
-**NEVER do this:**
-- Do NOT say "I've updated the feature spec" without actually calling the Edit tool
-- Do NOT summarize changes in chat as a substitute for writing them to the file
-- Do NOT skip updates because "it's obvious" or "minor"
+Update in the spec: status header, implementation notes, deviations, bugs found.
+Update in `INDEX.md`: the status column must match the spec header.
+
+Never claim a file was updated without having called Edit and verified the result.
 
 ## File Handling
-- ALWAYS read a file before modifying it - never assume contents from memory
-- After context compaction, re-read files before continuing work
-- When unsure about current project state, read `features/INDEX.md` first
-- Run `git diff` to verify what has already been changed in this session
-- Never guess at import paths, component names, or API routes - verify by reading
 
-## Handoffs Between Skills
-- After completing a skill, suggest the next skill to the user
-- Format: "Next step: Run `/skillname` to [action]"
-- Handoffs are always user-initiated, never automatic
+- Read a file before modifying it — never work from memory
+- After context compaction, re-read before continuing
+- Verify import paths, component names and API routes by reading, never guess
+- `git diff` shows what this session already changed
+
+## Git
+
+- Commit format: `type(PROJ-X): description` (feat, fix, refactor, test, docs, deploy, chore)
+- Check what exists before building: `git ls-files src/components/`, `git ls-files src/app/api/`
+
+## Human-in-the-Loop
+
+- Ask for approval before finalizing a deliverable
+- Offer clear choices instead of open-ended questions
+- Never advance to the next phase without confirmation
+- End each skill with: "Nächster Schritt: `/skillname` — [Aktion]"
+
+## Language
+
+Specs, PRD and acceptance criteria are written in **German**. Code, comments,
+commit messages and these instructions stay **English**.