---
title: web-app-skeleton — Repo-Vorlage fuer neue Web-Apps
type: project
tags: [skeleton, boilerplate, kar-522, nextjs]
date: 2026-05-23
status: aktiv
related: ["[[02-Wissen/architecture-audit/00-synthese]]", "[[02-Wissen/architecture-audit/00-plan]]"]
source: https://github.com/KADiCon/web-app-skeleton
description: Production-ready Next.js 16 Starter mit den KAR-522-Audit-Baselines ab Tag 1. Adoption Option 1 aus KAR-522 Phase 4 Follow-up.
---

# web-app-skeleton — Repo-Vorlage fuer neue Web-Apps

> **Repo:** https://github.com/KADiCon/web-app-skeleton (private)
> **Commit-0:** `c6a1424` — "feat: initial skeleton (KAR-522 follow-up)" am 2026-05-23.

## Zweck

Greenfield Next.js-Apps starten mit den 6 Konvergenz-Patterns aus dem KAR-522-Audit ab Commit-0:

1. 12-Factor Env-Validation via `@t3-oss/env-nextjs`
2. OpenTelemetry Tracing via `@vercel/otel`
3. Web Vitals via `@vercel/speed-insights`
4. OWASP ASVS L2 Blank-Checklist
5. Architecture Boundaries via `eslint-plugin-boundaries`
6. GDPR Art-15 + Art-17 Endpoints

Statt diese in jedem neuen Projekt nachzubauen: `git clone` + Rename = los.

## Verwendung

```bash
git clone --depth 1 https://github.com/KADiCon/web-app-skeleton.git my-new-app
cd my-new-app
rm -rf .git && git init
# Rename in package.json, app/layout.tsx, .env.example
npm install
cp .env.example .env.local      # Supabase + Sentry values einfuellen
npm run dev
```

## Was ist drin (Stand 2026-05-23)

| Bereich | File / Mechanismus |
|---|---|
| Env-Schema | `lib/env-schema.ts` + `instrumentation.ts` |
| OTel-Helpers | `lib/observability/spans.ts` |
| GDPR-Endpoints | `app/api/users/me/export/route.ts` + `app/api/users/me/route.ts` |
| GDPR-Helpers | `lib/gdpr/export.ts` + `lib/gdpr/deletion.ts` |
| Security-Headers | `next.config.mjs` |
| ESLint-Boundaries | `eslint.config.mjs` |
| Speed Insights | `app/layout.tsx` |
| ASVS L2 Blank | `docs/security/asvs-l2.md` |
| ADRs | `docs/adr/001-skeleton-baseline.md`, `021-state-management-strategy.md`, `022-caching-strategy.md` |
| CI: Typecheck/Lint/Test | `.github/workflows/ci.yml` |
| CI: Lighthouse | `.github/workflows/lighthouse-ci.yml` + `.lighthouserc.json` |
| Tests | `__tests__/smoke.test.ts` + Tests pro Helper |

## Verification beim Initial-Commit

- `npm run typecheck` clean
- `npm run lint` 0 issues
- `npm test` 15/15 passing
- `npm run build` success

## Was beim Adoption pro Projekt noch zu tun ist

Skeleton ist Floor, nicht Ceiling. Jedes neue Projekt fuellt aus:

- `USER_OWNED_TABLES` in `lib/gdpr/export.ts` mit Domain-Tabellen
- ASVS L2 Checklist vor erstem Prod-Deploy
- Supabase-Schema + RLS-Policies
- Business-Metrics in `lib/observability/spans.ts` ersetzen
- Domain-Server-Actions mit `getClaims()` + Zod ab Tag 1

## Future-Roadmap (offen)

- Tailwind + shadcn/ui Default-Setup (aktuell plain CSS)
- Storybook (optional, fuer Component-Heavy Projekte)
- Vercel-Sandbox lokal fuer Edge-Function-Testing
- Drizzle vs Supabase-Client-Direct Decision-ADR

## Quellen

- KAR-522 Audit Cross-Synthesis: `[[02-Wissen/architecture-audit/00-synthese]]`
- 20 Audit-Notes: `02-Wissen/architecture-audit/01-12-factor.md` bis `20-fielding-rest-dissertation.md`
- Audit-Plan: `[[02-Wissen/architecture-audit/00-plan]]`
- Adoption-Entscheidung: Kais 2026-05-23 02:39 CEST "Option 1"

## Verbindung zu Kadi-v2

Kadi-v2 ist *kein* Skeleton-Konsument — es ist die *Quelle* aus der die Patterns destilliert wurden. Quick-Wins (`KAR-522 commit 0138d3b`) haben einige der Skeleton-Patterns nachtraeglich in Kadi-v2 eingebaut. Die naechsten neuen Projekte starten direkt aus dem Skeleton.

## Verwandte Memory-Files

- `feedback_web_service_baseline_stack` — Standing Order, was im Skeleton ab Tag 1 sein muss
- `feedback_react_project_baseline` — bulletproof-react Folder-Struktur als Default
- `feedback_api_design_discipline` — REST-Constraints als Baseline
- `feedback_loading_state_hierarchy` — Skeleton/Spinner/Progress Hierarchy
- `feedback_micro_frontend_default_no` — bewusste Architektur-Entscheidung dokumentiert