chore: add GitHub Copilot AI setup

- .github/copilot-instructions.md: projektspezifische Copilot-Instruktionen
- .vscode/: empfohlene Extensions & Editor-Settings
- prompts/: Docker, Debug, Code-Review Prompt-Templates
This commit is contained in:
Conrad Schulz 2026-05-30 16:00:15 +00:00
parent bfd8dfdf96
commit dcc47babf9
6 changed files with 193 additions and 0 deletions

72
.github/copilot-instructions.md vendored Normal file
View file

@ -0,0 +1,72 @@
# GitHub Copilot Project Instructions
## Project
Selbst gehosteter Tile-Server (rd13) stellt Karten-Tiles (OSM Vektor + Satelliten-Raster)
für interne Dienste bereit: MediaWiki (Kartographer), Nextcloud Maps und weitere Web-Apps.
## Stack
- Language: Shell (Bash/Fish), JSON, Nginx config
- Infrastructure: Docker Compose, TileServer-GL (Node.js), nginx
- Data: MBTiles / PMTiles (OpenMapTiles-Schema), Planetiler (Java)
- Map styles: MapLibre GL / Mapbox GL JSON
- Reverse Proxy: nginx mit CORS + Rate-Limiting
## Architecture
- Pattern: Single-purpose service (tile serving only)
- `tileserver` Container: TileServer-GL rendert Tiles aus MBTiles-Dateien
- `nginx` Container: CORS-Header, Rate-Limiting, Caching-Header, externer Endpunkt
- Kartendaten liegen in `data/` (nicht im Git, da mehrere GB)
- Styles in `data/styles/`, Fonts in `data/fonts/`
- Key constraints:
- MBTiles/PMTiles nie ins Git committen (.gitignore)
- Secrets immer via `.env` (`.env` selbst auch ignoriert)
- CORS muss für alle Dienste im LAN offen sein (internes Netz)
## Conventions
- Branch naming: `feat/<beschreibung>`, `fix/<beschreibung>`
- Commit format: Conventional Commits (`feat|fix|chore|docs|refactor|ci`)
- File structure:
```
config/ TileServer-GL config.json
data/ MBTiles, Fonts, Sprites, Styles (nicht im Git)
docs/ Integrations-Anleitungen (MediaWiki, Nextcloud, API)
nginx/ nginx.conf, cors.conf
prompts/ GitHub Copilot Prompt-Templates
scripts/ Daten-Download, Deploy-Hilfen
```
- Naming: snake_case für Dateien, kebab-case für Docker-Service-Namen
## Engineering Process
### Before starting any task
1. `docker compose config` Syntax validieren
2. `docker compose logs tileserver` laufende Fehler prüfen
3. Impact analysis betrifft die Änderung CORS, Caching oder Endpunkt-URLs?
4. Test strategy mit curl / Browser gegen lokalen Server testen
### Definition of Done (DoD)
- [ ] `docker compose config` fehlerfrei
- [ ] Server startet ohne Fehler in den Logs
- [ ] Tile-Endpunkt antwortet (`curl http://localhost:PORT/health`)
- [ ] CORS-Header korrekt gesetzt (prüfen mit `curl -I -H "Origin: ..."`)
- [ ] Keine Secrets in docker-compose.yml oder Configs
- [ ] .gitignore schützt MBTiles und .env
- [ ] Commit message folgt Conventional Commits
## Tile-Server spezifische Hinweise
- Styles müssen auf `http://localhost:8080` zeigen (intern) nginx setzt öffentliche URL
- Zoom-Level 014 reichen für die meisten Anwendungsfälle (Dateigröße vs. Detail)
- Planetiler benötigt min. 4 GB RAM für Deutschland, 8 GB für Europa
- Satellitenkacheln: kostenfrei nur bis Zoom 10 (NASA GIBS oder maptiler.com)
- TileJSON-Endpoints: `/styles/{name}.json` und `/data/{name}.json`
## Security
- Keine Secrets in config.json oder nginx.conf
- nginx Rate-Limiting aktiv halten (100r/s, Burst 200)
- Ports: nginx nach außen, tileserver nur intern (expose, nicht ports)
- CORS auf `*` ist für internes LAN akzeptabel für public deployment einschränken
## Non-Functional Requirements
- Tile-Response: < 200ms für gecachte Tiles
- Availability: best-effort (kein HA erforderlich)
- Daten-Update-Zyklus: OSM monatlich (Planetiler-Re-Run), Satellit nach Bedarf

6
.vscode/extensions.json vendored Normal file
View file

@ -0,0 +1,6 @@
{
"recommendations": [
"github.copilot",
"github.copilot-chat"
]
}

7
.vscode/settings.json vendored Normal file
View file

@ -0,0 +1,7 @@
{
// Repo-specific overrides only. Global Copilot settings are in User/settings.json (Settings Sync).
"editor.rulers": [100],
// YAML schema validation adjust to your stack
"yaml.schemas": {}
}

View file

@ -0,0 +1,46 @@
---
mode: agent
description: Gründliches Code-Review Qualität, Security (OWASP), Performance
tools:
- codebase
- problems
---
# Code Review
**Ziel:** ${input:target:Datei, Funktion oder Feature-Bereich}
## Checkliste
### Korrektheit
- Logikfehler oder unbehandelte Edge-Cases?
- Fehlerbehandlung vollständig und sinnvoll?
- Alle Inputs an Systemgrenzen validiert?
### Security (OWASP Top 10)
- Injection-Risiken (SQL, Command, XSS)?
- Secrets oder Credentials im Code?
- Broken Access Control?
- Vulnerable Dependencies?
### Performance
- N+1 Queries oder unnötige DB-Roundtrips?
- Blocking I/O in async Kontext?
- Unnötige Re-Renders oder recalculations?
### Code-Qualität
- Funktionen >50 Zeilen → aufteilen?
- Duplizierter Code (DRY)?
- Naming klar und konsistent?
- Dead Code?
## Output-Format
Für jedes gefundene Problem:
```
[CRITICAL|HIGH|MEDIUM|LOW] datei.ts:42
Problem: ...
Fix: ...
```
Abschluss: Gesamtbewertung (110) + die 3 wichtigsten Maßnahmen.

32
prompts/debug.prompt.md Normal file
View file

@ -0,0 +1,32 @@
---
mode: agent
description: Root-Cause-Analyse und gezielter Fix für Bugs und unerwartetes Verhalten
tools:
- codebase
- editFiles
- runCommands
- problems
- terminalLastCommand
---
# Debug & Fix
**Problem:** ${input:problem:Beschreibe den Fehler oder das unerwartete Verhalten}
**Fehlermeldung / Stack-Trace** (optional einfügen):
```
${input:stacktrace:Stack-Trace oder Fehlermeldung hier oder leer lassen}
```
## Debugging-Strategie
1. **Reproduce** Unter welchen Bedingungen tritt der Fehler auf?
2. **Isolate** Kleinsten betroffenen Code-Bereich identifizieren
3. **Root Cause** Eigentliche Ursache finden (nicht nur Symptom bekämpfen)
4. **Fix** Minimaler, gezielter Fix ohne Refactoring nebenbei
5. **Verify** Fix löst das Problem, keine Regression
## Regeln
- Nicht den ersten offensichtlichen Fix wählen erst Root Cause verstehen
- Nie mehr Code ändern als für den Fix notwendig
- Wenn der Fix >10 Zeilen braucht: hinterfrage ob das Symptom nicht woanders liegt

30
prompts/docker.prompt.md Normal file
View file

@ -0,0 +1,30 @@
---
mode: agent
description: Docker / Compose Service analysieren, debuggen oder erweitern
tools:
- codebase
- editFiles
- runCommands
- terminalLastCommand
---
# Docker / Infrastructure
**Aufgabe:** ${input:task:Was soll analysiert, gefixt oder gebaut werden?}
## Kontext
- Basis: Docker Compose
- Umgebung: Linux-Server (remote via VS Code Server)
- Typische Services: Datenbank, App-Container, Reverse Proxy
## Workflow
1. Bestehende `docker-compose.yml` und `.env`-Dateien lesen
2. Logs / Fehlermeldungen analysieren (terminalLastCommand)
3. Minimale Änderung umsetzen
4. Validierung: `docker compose config` für Syntax, Service-Status prüfen
## Sicherheitsregeln
- Keine Secrets in docker-compose.yml immer `.env` oder Docker Secrets
- Ports nur soweit nötig exponieren
- Container nie als root (außer explizit begründet)
- Images immer mit Tag pinnen (kein `:latest` in Produktion)