chore: add GitHub Copilot AI config (instructions, prompts, vscode settings)

- Add .github/copilot-instructions.md with project-specific context
- Add .github/prompts/ with 9 reusable agent prompt files
- Add .vscode/extensions.json recommending copilot extensions
- Update .vscode/settings.json with rulers and YAML schema
- Remove tracked .DS_Store

.github/copilot-instructions.md

@@ -0,0 +1,70 @@
+# GitHub Copilot – Project Instructions
+
+## Project
+MediaWiki deployment for rd13 – a self-hosted wiki running in Docker, served via a reverse proxy, with a MariaDB backend.
+
+## Stack
+- Language: PHP (MediaWiki core + extensions), YAML, Dockerfile
+- Framework: MediaWiki
+- Database: MariaDB
+- Infrastructure: Docker Compose, GitHub Container Registry (ghcr.io), Linux Server (remote via VS Code Server)
+
+## Architecture
+- Pattern: Containerised deployment (App + DB as separate services)
+- Key constraints: No application code changes – configuration and infrastructure only
+- Image published to: `ghcr.io/c-schulz-rd13/rd13_media_wiki:latest`
+- Extensions live in: `wikidata/extensions/`
+- Wiki config: `wikidata/LocalSettings.php`
+- Upload config: `wikidata/uploads.ini`
+
+## Conventions
+- Branch naming: `feat/<ticket>-description`, `fix/<ticket>-description`
+- Commit format: Conventional Commits (`feat|fix|chore|docs|refactor|ci`)
+- Secrets: never in `docker-compose.yml` or `LocalSettings.php` – use `.env` files or Docker secrets
+- Images: always pin with a specific tag, avoid `:latest` in production compose files
+
+## Engineering Process
+
+### Before starting any task
+1. Clarify requirements – user story + acceptance criteria vorhanden?
+2. Impact analysis – welche bestehenden Komponenten sind betroffen?
+3. Architecture check – passt die geplante Lösung zur bestehenden Architektur?
+4. Test strategy – wie wird das Feature getestet?
+
+### Definition of Ready (DoR)
+A task can only be started when:
+- [ ] Acceptance criteria are clear and unambiguous
+- [ ] Non-functional requirements defined (performance, security, scalability)
+- [ ] Architectural approach agreed upon
+- [ ] No unresolved external blockers
+
+### Definition of Done (DoD)
+A task is only done when ALL of the following are true:
+- [ ] Change implements the acceptance criteria
+- [ ] No secrets or credentials in code or config
+- [ ] OWASP Top 10 reviewed
+- [ ] Relevant documentation updated (README, if applicable)
+- [ ] Commit message follows Conventional Commits
+- [ ] Docker image builds successfully (`docker buildx build --platform linux/amd64 .`)
+- [ ] No dead config, no TODOs left behind (or tracked as issues)
+
+## Testing Strategy
+- No unit/integration tests (deployment-only repo)
+- Validation: `docker compose config` for compose syntax
+- Build test: CI pipeline runs `docker buildx build` on PRs
+
+## Security
+- No secrets in code or config files – use environment variables / `.env`
+- MediaWiki `$wgSecretKey` and DB passwords must come from env or secrets
+- Validate all extension configurations before enabling
+- Principle of least privilege for all container permissions
+- Dependency vulnerabilities: check before adding new extensions or base image versions
+
+## Documentation Standards
+- Code comments: explain WHY, not WHAT
+- Architecture decisions: write ADR in `docs/adr/` (template: `docs/adr/000-template.md`)
+
+## Non-Functional Requirements
+- Availability: 99% (self-hosted, single node)
+- Data retention: persistent volumes for `wikidata/` and `mdbdata/`
+- Response time: < 2s for wiki page loads

.github/prompts/architecture.prompt.md

@@ -0,0 +1,66 @@
+---
+mode: agent
+description: Architektur-Review und Architecture Decision Record (ADR) erstellen
+tools:
+  - codebase
+  - editFiles
+---
+
+# Architecture Review & ADR
+
+**Entscheidung:** ${input:decision:Welche architektonische Entscheidung steht an?}
+**Kontext:** ${input:context:Warum wird diese Entscheidung gerade getroffen?}
+
+---
+
+## 1. Kontext & Problem
+
+Beschreibe:
+- Den aktuellen Zustand des Systems (relevante Teile lesen mit `codebase`)
+- Was sich ändern soll und warum
+- Welche Constraints existieren (Performance, Security, Teamgröße, Time-to-Market)
+
+## 2. Optionen
+
+Evaluiere **mindestens 3 Ansätze** (inkl. Status-Quo als Option):
+
+### Option A: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option B: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option C: [Name / Status Quo beibehalten]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+## 3. Entscheidung
+
+**Gewählte Option:** [A / B / C]
+
+**Begründung:** (Warum ist das die beste Option gegeben den Constraints?)
+
+**Trade-offs die wir bewusst eingehen:**
+
+## 4. Konsequenzen
+
+**Positiv:**
+**Negativ / Akzeptierte Risiken:**
+**Folgeentscheidungen die nötig werden:**
+
+---
+
+## ADR-Datei erstellen
+
+Erstelle die ADR unter `docs/adr/NNN-[kurzer-titel].md` mit obigem Inhalt im
+[MADR-Format](https://adr.github.io/madr/).
+
+Nummerierung: nächste freie Nummer in `docs/adr/` verwenden.

.github/prompts/code-review.prompt.md

@@ -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 (1–10) + die 3 wichtigsten Maßnahmen.

.github/prompts/debug.prompt.md

@@ -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

.github/prompts/docker.prompt.md

@@ -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)

.github/prompts/done-check.prompt.md

@@ -0,0 +1,66 @@
+---
+mode: agent
+description: Definition of Done – vollständige Abnahme-Checkliste vor dem Merge
+tools:
+  - codebase
+  - runCommands
+  - problems
+---
+
+# Definition of Done – Abnahme-Check
+
+**Task / Feature:** ${input:task:Was wurde implementiert?}
+
+Führe alle Checks durch. Behebe gefundene Probleme bevor du abschließt.
+
+---
+
+## 1. Funktionalität
+- [ ] Alle Acceptance Criteria erfüllt (gegen ursprüngliche ACs prüfen)
+- [ ] Happy Path funktioniert
+- [ ] Edge Cases behandelt
+- [ ] Error Cases mit sinnvollen Fehlermeldungen
+
+## 2. Code-Qualität
+- [ ] Kein roter Code (`problems`-Tool)
+- [ ] Kein Dead Code, keine auskommentierten Blöcke
+- [ ] Keine TODOs ohne zugehöriges Issue
+- [ ] Funktionen ≤ 50 Zeilen, Klassen ≤ 200 Zeilen
+- [ ] Naming: klar, konsistent, keine Abkürzungen
+
+## 3. Tests
+- [ ] Unit-Tests für alle neuen/geänderten Funktionen
+- [ ] Integration-Tests wo Services zusammenspielen
+- [ ] Alle Tests grün
+- [ ] Keine Tests deaktiviert/übersprungen ohne Begründung
+- [ ] Coverage nicht gesunken
+
+## 4. Security (OWASP Top 10)
+- [ ] Keine Secrets, API-Keys, Passwörter im Code
+- [ ] Alle Inputs an System-Grenzen validiert
+- [ ] SQL/Command-Injection nicht möglich
+- [ ] Auth/Authz korrekt
+- [ ] Keine neuen Abhängigkeiten mit bekannten CVEs
+
+## 5. Dokumentation
+- [ ] Code-Kommentare erklären das WHY (nicht das WHAT)
+- [ ] Public APIs dokumentiert
+- [ ] README aktualisiert (wenn Verhalten sich ändert)
+- [ ] ADR erstellt (wenn architektonische Entscheidung getroffen wurde)
+- [ ] CHANGELOG.md aktualisiert (wenn Release-relevant)
+
+## 6. Git
+- [ ] Commits atomar (ein Commit = eine logische Änderung)
+- [ ] Commit-Messages: Conventional Commits Format
+- [ ] Keine unrelated changes im Branch
+- [ ] Branch up-to-date mit main/master
+
+## 7. Nicht-funktionale Anforderungen
+- [ ] Performance: keine Regression (bekannte Benchmarks)
+- [ ] Keine neuen Warnungen in Logs
+- [ ] Ressourcenverbrauch vertretbar (CPU, Memory, DB-Queries)
+
+---
+
+**Ergebnis:** Wenn alle Punkte ✓ → Task ist Done. Jeden offenen Punkt mit konkretem
+Problem und Fix-Vorschlag benennen.

.github/prompts/new-feature.prompt.md

@@ -0,0 +1,88 @@
+---
+mode: agent
+description: Neues Feature – vollständiger Engineering-Prozess von Requirements bis Commit
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# New Feature – Full Engineering Workflow
+
+**Feature Request:** ${input:feature_description:Beschreibe das gewünschte Feature}
+
+---
+
+## Phase 1 – Requirements Engineering
+
+Bevor eine Zeile Code geschrieben wird:
+
+**User Story:**
+> Als [Rolle] möchte ich [Aktion], damit [Nutzen].
+
+**Acceptance Criteria** (konkret, testbar, kein Interpretationsspielraum):
+- [ ] AC1:
+- [ ] AC2:
+- [ ] AC3:
+
+**Non-Functional Requirements:**
+- Performance: (z.B. Response <200ms unter Last X)
+- Security: (z.B. Auth erforderlich, Input-Validierung)
+- Scalability: (z.B. muss bei Y gleichzeitigen Usern funktionieren)
+
+**Out of Scope** (explizit ausschließen):
+-
+
+→ Prüfe: Sind alle ACs klar und unambiguös? Wenn nicht, stelle Rückfragen.
+
+---
+
+## Phase 2 – Architecture Review
+
+**Bestandsanalyse:** Lies relevante bestehende Dateien mit dem `codebase`-Tool.
+
+**Ansätze** (mindestens 2 evaluieren):
+| Ansatz | Vorteile | Nachteile | Empfehlung |
+|---|---|---|---|
+| A | | | |
+| B | | | |
+
+**Entscheidung:** [Begründung warum Ansatz X gewählt wird]
+
+**Impact Analysis:**
+- Welche bestehenden Komponenten werden berührt?
+- Gibt es Breaking Changes?
+- Datenbankmigrationen erforderlich?
+
+---
+
+## Phase 3 – Implementation
+
+Implementiere gemäß dem gewählten Ansatz. Halte dich strikt an:
+- Bestehende Code-Patterns und Naming-Konventionen
+- Kein Code außerhalb des definierten Scopes
+- Jeden Schritt kompilierbar lassen
+
+---
+
+## Phase 4 – Tests (nicht überspringen)
+
+Test-Strategie für dieses Feature:
+- **Unit Tests:** Alle neuen Funktionen mit Arrange/Act/Assert
+- **Integration Tests:** Zusammenspiel der Komponenten
+- **Edge Cases:** Leer-Input, Grenzwerte, Fehlerszenarien
+
+Tests müssen grün sein bevor weitergemacht wird.
+
+---
+
+## Phase 5 – Definition of Done
+
+Bevor der Task als abgeschlossen gilt:
+- [ ] Alle Acceptance Criteria erfüllt
+- [ ] Alle Tests grün, keine `problems`-Fehler
+- [ ] Keine Secrets im Code
+- [ ] OWASP Top 10 geprüft
+- [ ] Dokumentation aktualisiert (README / API-Docs / ADR falls nötig)
+- [ ] Commit mit Conventional Commits Format erstellt

.github/prompts/refactor.prompt.md

@@ -0,0 +1,33 @@
+---
+mode: agent
+description: Refactoring – Code verbessern ohne Verhalten zu ändern
+tools:
+  - codebase
+  - editFiles
+  - problems
+---
+
+# Refactoring
+
+**Ziel:** ${input:target:Was soll refactored werden und warum?}
+
+## Grundregeln (nicht verhandelbar)
+- **Kein Behavior-Change** – Tests müssen vorher und nachher grün sein
+- Scope klar definieren – nichts außerhalb des Ziels anfassen
+- Inkrementell vorgehen – nach jedem Schritt kompilierbar/lauffähig
+
+## Was ist erwünscht?
+Wähle was zutrifft (oder beschreibe selbst):
+- Lesbarkeit verbessern (Naming, Struktur)
+- Duplizierung eliminieren (DRY)
+- Komplexität reduzieren (Cyclomatic Complexity)
+- Performance-kritischen Pfad optimieren
+- Testbarkeit erhöhen (Dependency Injection, Pure Functions)
+
+## Prozess
+1. Analyse: Aktuelle Probleme konkret benennen
+2. Plan: Welche Änderungen in welcher Reihenfolge
+3. Durchführung: Schrittweise, jeder Schritt single-purpose
+4. Verifikation: `problems`-Tool, kein roter Code
+
+Nach dem Refactoring: diff-Zusammenfassung mit Begründung für jede wesentliche Änderung.

.github/prompts/requirements.prompt.md

@@ -0,0 +1,73 @@
+---
+mode: agent
+description: Requirements Engineering Workshop – User Stories, ACs und NFRs erarbeiten
+tools:
+  - codebase
+---
+
+# Requirements Engineering Workshop
+
+**Ausgangspunkt:** ${input:raw_request:Was wurde grob angefragt oder gewünscht?}
+
+Führe einen strukturierten Requirements-Workshop durch. Stelle Rückfragen wo nötig,
+aber arbeite so weit wie möglich mit dem vorhandenen Kontext.
+
+---
+
+## 1. Problem Statement
+
+**Problem:** Was ist das eigentliche Problem, das gelöst werden soll?
+**Betroffene Nutzer:** Wer hat dieses Problem?
+**Aktueller Workaround:** Wie lösen Nutzer das Problem heute?
+**Impact:** Was passiert wenn wir es nicht lösen?
+
+## 2. User Stories
+
+Erstelle User Stories im Format:
+> Als **[Rolle]** möchte ich **[Aktion/Feature]**, damit **[geschäftlicher Nutzen]**.
+
+Identifiziere: Wer sind die Nutzer-Rollen in diesem System?
+
+## 3. Acceptance Criteria
+
+Für jede User Story: konkrete, testbare, unambiguöse ACs.
+
+**Format:** `Given [Vorbedingung], When [Aktion], Then [Erwartetes Ergebnis]`
+
+Checkliste für gute ACs:
+- [ ] Eindeutig – nur eine mögliche Interpretation
+- [ ] Testbar – kann automatisch oder manuell verifiziert werden
+- [ ] Vollständig – Happy Path + wichtigste Error-Cases abgedeckt
+- [ ] Kein "wie" – ACs beschreiben WAS, nicht WIE
+
+## 4. Non-Functional Requirements
+
+| Kategorie | Anforderung | Messbar? |
+|---|---|---|
+| Performance | z.B. Response <200ms bei 100 concurrent users | |
+| Security | z.B. Auth erforderlich, keine PII in Logs | |
+| Availability | z.B. 99.9% uptime, <1h RTO | |
+| Scalability | z.B. skaliert bis 10.000 Einträge ohne Perf-Degradation | |
+| Maintainability | z.B. neue Entwickler können in <1h onboarden | |
+
+## 5. Out of Scope (explizit)
+
+Was wird explizit **nicht** gebaut (jetzt):
+-
+
+## 6. Open Questions & Risiken
+
+Offene Fragen die vor dem Start beantwortet werden müssen:
+-
+
+Bekannte Risiken:
+-
+
+## 7. Definition of Ready
+
+Dieser Task ist ready to start wenn:
+- [ ] Alle ACs klar und unambiguös
+- [ ] NFRs definiert
+- [ ] Scope abgegrenzt
+- [ ] Open Questions geklärt
+- [ ] Architektureller Ansatz skizziert

.github/prompts/write-tests.prompt.md

@@ -0,0 +1,34 @@
+---
+mode: agent
+description: Tests schreiben – Unit, Integration oder E2E für bestehenden Code
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# Tests schreiben
+
+**Ziel:** ${input:target:Welcher Code soll getestet werden?}
+**Test-Typ:** ${input:test_type:unit / integration / e2e}
+
+## Strategie
+
+1. **Analyse** – Bestehende Tests lesen, Test-Framework und Patterns verstehen
+2. **Coverage-Lücken** – Welche Fälle sind ungetestet?
+3. **Test-Cases** – Happy Path + Edge Cases + Error Cases definieren
+4. **Implementierung** – Tests schreiben, bestehende Patterns und Helpers nutzen
+5. **Ausführen** – Tests laufen grün
+
+## Gute Tests
+- **Arrange / Act / Assert** – klare Struktur
+- Ein Test = eine Assertion (oder eng verwandte Gruppe)
+- Test-Namen beschreiben das erwartete Verhalten: `should return empty array when input is null`
+- Keine Implementation Details testen – nur Verhalten
+- Keine Mocks wo Echte Objekte möglich sind
+
+## Nicht erwünscht
+- Tests die nur Code paraphrasieren ohne Mehrwert
+- Fragile Tests die bei jedem Refactor brechen
+- Tests mit versteckten Abhängigkeiten zwischen sich

.vscode/extensions.json

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

.vscode/settings.json

@@ -1,3 +1,11 @@
 {
-    "search.useIgnoreFiles": false
+    // Repo-specific overrides only. Global Copilot settings are in User/settings.json (Settings Sync).
+    "search.useIgnoreFiles": false,
+    "editor.rulers": [
+        100
+    ],
+    // YAML schema validation
+    "yaml.schemas": {
+        "https://json.schemastore.org/github-workflow.json": ".github/workflows/*.yml"
+    }
 }