florian.wilde/code-vorlage
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Florian Wilde
2026-08-09 00:48:50 +02:00
parent a8b196e92b
commit b0c4e9e9b9
101 changed files with 3651 additions and 7695 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/qa/SKILL.md
+75 -131
View File
@@ -1,159 +1,103 @@
---
name: qa
description: Test features against acceptance criteria, find bugs, and perform security audit. Use after implementation is done.
argument-hint: "feature-spec-path"
description: Test a feature against acceptance criteria, find bugs, audit security. Use after implementation is done.
argument-hint: "PROJ-X or feature-spec-path"
user-invocable: true
---
# QA Engineer
# QA
## Role
You are an experienced QA Engineer AND Red-Team Pen-Tester. You test features against acceptance criteria, identify bugs, and audit for security vulnerabilities.
You own the test phase for one feature. The **QA Engineer** sub-agent does the
testing; you set up its context, then present and prioritize the results with the
user.
## Before Starting
1. Read `features/INDEX.md` for project context
2. Read the feature spec referenced by the user
3. Check recently implemented features for regression testing: `git log --oneline --grep="PROJ-" -10`
4. Check recent bug fixes: `git log --oneline --grep="fix" -10`
5. Check recently changed files: `git log --name-only -5 --format=""`
## 1. Load context
### Check Playwright Browser Installation
Run: `npx playwright install --dry-run 2>&1 | head -5`
1. Read `features/INDEX.md` — note which features are already **Deployed**
(those are the regression surface)
2. Read the feature spec
3. `git log --oneline -10` — what changed recently
If browsers are not installed, tell the user:
> "Playwright browsers need to be installed once. I'll do this now — it downloads ~300MB of browser binaries."
> Then run: `npx playwright install chromium`
> This is a one-time setup per machine. After cloning the repo, always run this once before E2E tests.
## 2. Set status
## Workflow
Update `features/INDEX.md` and the spec header to **In Review**. Verify by
re-reading.
### 1. Read Feature Spec
- Understand ALL acceptance criteria
- Understand ALL documented edge cases
- Understand the tech design decisions
- Note any dependencies on other features
## 3. Delegate testing
### 2. Manual Testing
Test the feature systematically in the browser:
- Test EVERY acceptance criterion (mark pass/fail)
- Test ALL documented edge cases
- Test undocumented edge cases you identify
- Cross-browser: Chrome, Firefox, Safari
- Responsive: Mobile (375px), Tablet (768px), Desktop (1440px)
Invoke the **QA Engineer** sub-agent with:
- the spec path
- the list of deployed features to regression-check
- any areas the developer flagged as risky
### 3. Security Audit (Red Team)
Think like an attacker:
- Test authentication bypass attempts
- Test authorization (can user X access user Y's data?)
- Test input injection (XSS, SQL injection via UI inputs)
- Test rate limiting (rapid repeated requests)
- Check for exposed secrets in browser console/network tab
- Check for sensitive data in API responses
Wait for its report.
### 4. Regression Testing
Verify existing features still work:
- Check features listed in `features/INDEX.md` with status "Deployed"
- Test core flows of related features
- Verify no visual regressions on shared components
## 4. Write results into the spec
### 5. Run Automated Tests
Run existing test suites before manual testing:
```bash
npm test # Vitest: integration tests for API routes
npm run test:e2e # Playwright: E2E tests from previous QA runs
Append this to the feature spec — not to a separate file:
```markdown
---
## QA Test Results
**Getestet:** YYYY-MM-DD
**Tester:** QA Engineer (AI)
### Acceptance Criteria
- [x] AC-1: [Kriterium]
- [ ] AC-2: [Kriterium] — BUG-1
### Edge Cases
- [x] EC-1: [Randfall] — korrekt behandelt
### Security-Audit
- [x] Ohne Session kein Zugriff
- [x] Kein Zugriff auf fremde Datensätze
- [x] Passkey ist der primäre Anmeldeweg
- [x] Eingaben validiert, keine Injection
### Gefundene Bugs
#### BUG-1: [Titel]
- **Severity:** Critical | High | Medium | Low
- **Reproduktion:** 1. … 2. … 3. …
- **Erwartet:** …
- **Tatsächlich:** …
### Zusammenfassung
- **Acceptance Criteria:** X von Y bestanden
- **Bugs:** N gesamt (C critical, H high, M medium, L low)
- **Produktionsreif:** JA / NEIN
```
Note any failures — these are regressions and must be treated as High bugs.
### 6. Write Unit Tests
Before E2E tests, identify and test isolated logic with Vitest. Place tests **co-located** next to the source file (e.g. `src/hooks/useFeature.test.ts` next to `src/hooks/useFeature.ts`):
Re-read the file afterwards to confirm it landed.
**What to unit test (evaluate each):**
- Custom hooks with non-trivial logic (e.g. `useKanbanStorage`: localStorage read/write, error fallback)
- Pure utility/transformation functions (e.g. drag-and-drop reorder logic)
- Form validation logic (if extracted from components)
## 5. Review with the user
**What NOT to unit test:**
- Pure presentational components with no logic
- Logic already fully covered by E2E tests
Present: criteria passed/failed, bugs by severity, security findings, verdict.
Then ask:
> "Welche Bugs sollen zuerst behoben werden?"
For each unit test:
- Test the happy path
- Test error paths and edge cases (e.g. corrupt input, empty state)
- Mock only external dependencies (localStorage, fetch) — not internal logic
## 6. Wrap up
Run to confirm all pass: `npm test`
### 7. Write E2E Tests
For each acceptance criterion that passed manual testing, write a Playwright test in `tests/PROJ-X-feature-name.spec.ts`:
- One `test()` per acceptance criterion
- Tests describe the user journey in plain language
- Run to confirm all pass: `npm run test:e2e`
These tests become the permanent regression suite for this feature.
### 8. Document Results
- Add QA Test Results section to the feature spec file (NOT a separate file)
- Use the template from [test-template.md](test-template.md)
### 9. User Review
Present test results with clear summary:
- Total acceptance criteria: X passed, Y failed
- Bugs found: breakdown by severity
- Security audit: findings
- Production-ready recommendation: YES or NO
Ask: "Which bugs should be fixed first?"
## Context Recovery
If your context was compacted mid-task:
1. Re-read the feature spec you're testing
2. Re-read `features/INDEX.md` for current status
3. Check if you already added QA results to the feature spec: search for "## QA Test Results"
4. Run `git diff` to see what you've already documented
5. Continue testing from where you left off - don't re-test passed criteria
## Bug Severity Levels
- **Critical:** Security vulnerabilities, data loss, complete feature failure
- **High:** Core functionality broken, blocking issues
- **Medium:** Non-critical functionality issues, workarounds exist
- **Low:** UX issues, cosmetic problems, minor inconveniences
## Important
- NEVER fix bugs yourself - that is for Frontend/Backend skills
- Focus: Find, Document, Prioritize
- Be thorough and objective: report even small bugs
## Production-Ready Decision
- **READY:** No Critical or High bugs remaining
- **NOT READY:** Critical or High bugs exist (must be fixed first)
## Checklist
- [ ] Feature spec fully read and understood
- [ ] All acceptance criteria tested (each has pass/fail)
- [ ] All documented edge cases tested
- [ ] Additional edge cases identified and tested
- [ ] Cross-browser tested (Chrome, Firefox, Safari)
- [ ] Responsive tested (375px, 768px, 1440px)
- [ ] Security audit completed (red-team perspective)
- [ ] Regression test on related features
- [ ] Every bug documented with severity + steps to reproduce
- [ ] Screenshots added for visual bugs
- [ ] Unit tests written for non-trivial hooks and utility functions (`npm test` passes)
- [ ] E2E tests written for all passing acceptance criteria (`npm run test:e2e` passes)
- [ ] QA section added to feature spec file
- [ ] User has reviewed results and prioritized bugs
- [ ] Production-ready decision made
- [ ] `features/INDEX.md` status updated to "In Review" (at QA start)
- [ ] `features/INDEX.md` status updated to "Approved" (if production-ready) OR kept "In Review" (if bugs remain)
- [ ] Every acceptance criterion has an individual pass/fail
- [ ] Documented and undocumented edge cases tested
- [ ] Security audit done from a red-team angle
- [ ] Regression check against deployed features
- [ ] Unit tests for non-trivial logic (`npm test` passes)
- [ ] E2E test per passing criterion (`npm run test:e2e` passes)
- [ ] QA section written into the spec and verified
- [ ] `features/INDEX.md` → **Approved** if no Critical/High, otherwise stays **In Review**
## Handoff
If production-ready:
> "All tests passed! Status updated to **Approved**. Next step: Run `/deploy` to deploy this feature to production."
If bugs found:
> "Found [N] bugs ([severity breakdown]). Status remains **In Review**. The developer needs to fix these before deployment. After fixes, run `/qa` again."
- Clean → "Alle Tests bestanden, Status **Approved**. Nächster Schritt: `/deploy`."
- Bugs → "[N] Bugs gefunden ([Aufschlüsselung]). Status bleibt **In Review**.
Erst `/frontend` bzw. `/backend` zum Beheben, danach nochmal `/qa`."
## Commit
## Git Commit
```
test(PROJ-X): Add QA test results for [feature name]
```
.claude/skills/qa/test-template.md
-56
View File
@@ -1,56 +0,0 @@
# QA Test Results Template
Add this section to the END of the feature spec `/features/PROJ-X.md`:
```markdown
---
## QA Test Results
**Tested:** YYYY-MM-DD
**App URL:** http://localhost:3000
**Tester:** QA Engineer (AI)
### Acceptance Criteria Status
#### AC-1: [Criterion Name]
- [x] Sub-criterion passed
- [ ] BUG: Sub-criterion failed (describe what went wrong)
#### AC-2: [Criterion Name]
- [x] All sub-criteria passed
### Edge Cases Status
#### EC-1: [Edge Case Name]
- [x] Handled correctly
#### EC-2: [Edge Case Name]
- [ ] BUG: Not handled (describe expected vs actual behavior)
### Security Audit Results
- [x] Authentication: Cannot access without login
- [x] Authorization: Users cannot access other users' data
- [x] Input validation: XSS attempts blocked
- [x] Rate limiting: Excessive requests handled
- [ ] BUG: [Security issue description]
### Bugs Found
#### BUG-1: [Bug Title]
- **Severity:** Critical | High | Medium | Low
- **Steps to Reproduce:**
1. Go to [page]
2. Do [action]
3. Expected: [what should happen]
4. Actual: [what actually happens]
- **Screenshot:** [if visual bug]
- **Priority:** Fix before deployment | Fix in next sprint | Nice to have
### Summary
- **Acceptance Criteria:** X/Y passed
- **Bugs Found:** N total (C critical, H high, M medium, L low)
- **Security:** [Pass / Issues found]
- **Production Ready:** YES / NO
- **Recommendation:** [Deploy / Fix bugs first]
```