From 2a72e08c1358dec399d2deb17d20ef93fb92d802 Mon Sep 17 00:00:00 2001 From: Conrad Schulz Date: Sat, 30 May 2026 10:55:16 +0000 Subject: [PATCH] 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 --- .DS_Store | Bin 8196 -> 0 bytes .github/copilot-instructions.md | 70 ++++++++++++++++++++ .github/prompts/architecture.prompt.md | 66 +++++++++++++++++++ .github/prompts/code-review.prompt.md | 46 +++++++++++++ .github/prompts/debug.prompt.md | 32 +++++++++ .github/prompts/docker.prompt.md | 30 +++++++++ .github/prompts/done-check.prompt.md | 66 +++++++++++++++++++ .github/prompts/new-feature.prompt.md | 88 +++++++++++++++++++++++++ .github/prompts/refactor.prompt.md | 33 ++++++++++ .github/prompts/requirements.prompt.md | 73 ++++++++++++++++++++ .github/prompts/write-tests.prompt.md | 34 ++++++++++ .vscode/extensions.json | 6 ++ .vscode/settings.json | 10 ++- 13 files changed, 553 insertions(+), 1 deletion(-) delete mode 100644 .DS_Store create mode 100644 .github/copilot-instructions.md create mode 100644 .github/prompts/architecture.prompt.md create mode 100644 .github/prompts/code-review.prompt.md create mode 100644 .github/prompts/debug.prompt.md create mode 100644 .github/prompts/docker.prompt.md create mode 100644 .github/prompts/done-check.prompt.md create mode 100644 .github/prompts/new-feature.prompt.md create mode 100644 .github/prompts/refactor.prompt.md create mode 100644 .github/prompts/requirements.prompt.md create mode 100644 .github/prompts/write-tests.prompt.md create mode 100644 .vscode/extensions.json diff --git a/.DS_Store b/.DS_Store deleted file mode 100644 index f98d79b3139633e3e4c4b07ad893a597936fd0e1..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8196 zcmeHMO=uHA6n@*Lb`!A%72DqSB2=iQsg+ixkj4}#D2Nd~sIOrL9-4;A}^58*1PhJEsUiF|LA|5=bC;eu2+s^JLr6*B3Q)b@myzjkv^UY%?vn3)W zQOm@L28c*SWiq-GO`F2>tOiP#JEB17}s1}+?6dyI_9Lfmk-6AS#fVD3ZEVRH4Y~w?nv261|$PP1~d$XXoPZ9 zpsMHo9y<0@)D^8{(l9LpW9qYq{rB!Zc{T0TXExQ_dEwhY-+P!+@7lbSry3ca*{OGb z5Fy6!<-?~(t6yKT7<_(;)ZH-e~DK5cdVe%E3)VA~~Y_m7T8}*9qCi-i`HVc*N=;%A8t2@-QqgPcUYGhaBaw>1tQ&qiMt0eUD zMfP+?ujUQ6e-8Ao_jTiZAzPn|?mJkDO2HoQjS7Z z!)kagI@oATj7<(}9e(?P=S+8XLSDk}`vawIoF q!>{9z{5lS~{trX+H9(n7+?6dyVg%*ye+UR1%kuo^J0Y9x#K0dEx3M?? diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000..f2cbff5 --- /dev/null +++ b/.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/-description`, `fix/-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 diff --git a/.github/prompts/architecture.prompt.md b/.github/prompts/architecture.prompt.md new file mode 100644 index 0000000..c55945e --- /dev/null +++ b/.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. diff --git a/.github/prompts/code-review.prompt.md b/.github/prompts/code-review.prompt.md new file mode 100644 index 0000000..7b160f5 --- /dev/null +++ b/.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. diff --git a/.github/prompts/debug.prompt.md b/.github/prompts/debug.prompt.md new file mode 100644 index 0000000..a669abf --- /dev/null +++ b/.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 diff --git a/.github/prompts/docker.prompt.md b/.github/prompts/docker.prompt.md new file mode 100644 index 0000000..6351cab --- /dev/null +++ b/.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) diff --git a/.github/prompts/done-check.prompt.md b/.github/prompts/done-check.prompt.md new file mode 100644 index 0000000..8373ba8 --- /dev/null +++ b/.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. diff --git a/.github/prompts/new-feature.prompt.md b/.github/prompts/new-feature.prompt.md new file mode 100644 index 0000000..2f1337d --- /dev/null +++ b/.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 diff --git a/.github/prompts/refactor.prompt.md b/.github/prompts/refactor.prompt.md new file mode 100644 index 0000000..4c25d2f --- /dev/null +++ b/.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. diff --git a/.github/prompts/requirements.prompt.md b/.github/prompts/requirements.prompt.md new file mode 100644 index 0000000..df81559 --- /dev/null +++ b/.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 diff --git a/.github/prompts/write-tests.prompt.md b/.github/prompts/write-tests.prompt.md new file mode 100644 index 0000000..b8b2c3d --- /dev/null +++ b/.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 diff --git a/.vscode/extensions.json b/.vscode/extensions.json new file mode 100644 index 0000000..dad5415 --- /dev/null +++ b/.vscode/extensions.json @@ -0,0 +1,6 @@ +{ + "recommendations": [ + "github.copilot", + "github.copilot-chat" + ] +} \ No newline at end of file diff --git a/.vscode/settings.json b/.vscode/settings.json index f345fde..683ee83 100644 --- a/.vscode/settings.json +++ b/.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" + } } \ No newline at end of file