cschulz/rd13_media_wiki
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions
rd13_media_wiki/.github/copilot-instructions.md
Conrad Schulz 2a72e08c13 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
2026-05-30 10:55:16 +00:00

3 KiB
Raw Blame History

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