BIGboss248/nextjs-wordpress

Universelle Repository-Einrichtungs- & Umgebungs-Fertigkeit (setup-repository)

Diese Fertigkeit richtet die Standard-Entwicklungsumgebung für jedes Software-Repository ein, konfiguriert und validiert sie. Sie umfasst die Erkennung von Projektmetadaten, Git-Hygiene, Code-Intelligenz mit codebase-memory-mcp (konfiguriert im Workspace und global nur für Google Antigravity / AGY), Commit-Standardisierung mit Husky & Commitlint, produktionsreife Docker-Containerisierung und automatisierte Release-Please- & Multi-Arch-GHCR-CI/CD-Bereitstellung.

---

Workflow-Übersicht

flowchart TD
    A["1. Automatisierte Erkennung & unterbrechungsfreier Scan"] --> B["2. Projektmetadaten-Ground-Truth (docs/project.json)"]
    B --> C["3. Codebase-Memory-MCP-Einrichtung (Workspace & AGY Global)"]
    C --> D["4. Git-Hooks- & Commitlint-Konfiguration"]
    D --> E["5. Produktions-Docker- & Compose-Stacks"]
    E --> F["6. Release-Please- & Multi-Arch-GHCR-CI/CD"]
    F --> G["7. Überprüfung der Umgebungssanität"]
    G --> H["8. Standardisierter Ausführungsbericht & Git-Anleitung"]

---

Schritt 1: Automatisierte Erkennung & Repository-Scan (Keine-Unterbrechungs-Regel)

[!IMPORTANT] FRAGEN SIE DEN BENUTZER NICHT, WENN INFORMATIONEN IN REPOSITORY-DATEIEN VERFÜGBAR SIND. Scannen Sie zuerst Repository-Dateien, Konfigurationen und Dokumentationen in docs/. Leiten Sie Laufzeitumgebung, Tooling und Konventionen automatisch ab. Fragen Sie den Menschen nur nach fehlenden oder mehrdeutigen Konfigurationen.

1.1. Automatisierte Inspektion (Keine-Unterbrechungs-Regel)

1. Framework & Laufzeit erkennen:
   • Untersuchen Sie Paketmanifeste: package.json (Node/Bun), pyproject.toml / requirements.txt (Python), Cargo.toml (Rust), go.mod (Go), etc.
   • Erkennen Sie den Paketmanager anhand von Lockfiles:
     • pnpm-lock.yaml → pnpm
     • bun.lockb / bun.lock → bun
     • yarn.lock → yarn
     • package-lock.json → npm
2. Vorhandene Dokumentation scannen:
   • Lesen Sie CONTEXT.md, docs/plan.md, docs/adr/*.md und README.md, um Architekturstandards, Testsuiten und Sprachkonventionen zu extrahieren.
3. Git-Working-Tree überprüfen:
   • Überprüfen Sie den Git-Status und -Branch. Alle Inspektions- und Befehlsschritte müssen als einzelne, diskrete Operationen ohne Verkettung ausgeführt werden.

1.2. Interaktive Klärung (KI-gestütztes Scaffolding)

Wenn kritische Parameter fehlen, mehrdeutig sind oder aus vorhandenen Dateien nicht ermittelt werden können, stellen Sie dem Benutzer fokussierte Fragen mit klaren Optionen:

### 📋 Repository-Setup & CI/CD-Konfiguration

Um den standardmäßigen CI/CD-Workflow für dieses Repository zu konfigurieren, bestätigen oder spezifizieren Sie bitte:

1. **Primäre Sprache & Laufzeit**: (z.B. Node.js / TypeScript, Python, Go, Rust, Java, C++)
2. **Testbefehl**: (z.B. `pnpm test`, `pytest`, `cargo test`, `go test ./...`)
3. **Build-Befehl**: (z.B. `pnpm run build`, `cargo build --release`, `go build`, `none`)
4. **Release / Publish-Ziel**:
   - [ ] Docker-Container-Image (GHCR / Docker Hub)
   - [ ] Paketregister (npm, PyPI, Crates.io, Maven)
   - [ ] Binäre Release-Assets (GitHub Releases)
   - [ ] Statische Seite / Dokumentation (GitHub Pages)
   - [ ] Keines (nur CI-Tests & SemVer-Git-Tags)

---

Schritt 2: Projektmetadaten-Ground-Truth (docs/project.json)

Pflegen Sie eine zentrale, maschinenlesbare Konfigurationsdatei unter docs/project.json, damit alle KI-Agenten und spezialisierten Fertigkeiten denselben Kontext teilen.

Standard-docs/project.json-Vorlage:

{
  "project_context_and_metadata": {
    "project_name": "my-project",
    "runtime": "node",
    "package_manager": "pnpm",
    "source_dir": "src",
    "test_command": "pnpm test",
    "build_command": "pnpm run build",
    "testing_library": ["jest", "playwright"],
    "containerization": "docker-standalone",
    "ci_cd_provider": "github-actions",
    "release_automation": "release-please",
    "publish_target": "container"
  }
}

1. Stellen Sie sicher, dass das Verzeichnis docs/ existiert.
2. Schreiben oder aktualisieren Sie docs/project.json mit den ermittelten oder bestätigten Konfigurationswerten.

---

Schritt 3: codebase-memory-mcp Code-Intelligenz-Server einrichten

Statten Sie das Repository mit dem persistenten Wissensgraphen-Server codebase-memory-mcp aus (162 Sprachen, Tree-Sitter AST, hybride LSP-Semantik-Typauflösung und 100% lokale Vektorsuche).

3.1. Binärdatei installieren

Wählen Sie die plattformspezifische Methode:

• Windows (PowerShell):

  Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
  Unblock-File .\install.ps1
  .\install.ps1
  Remove-Item .\install.ps1
  

• macOS / Linux (Bash):

  curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
  

• Globales npm-Paket als Alternative:

  npm install -g codebase-memory-mcp@latest
  

3.2. MCP-Server registrieren (Workspace & nur AGY Global)

[!IMPORTANT] Die globale MCP-Registrierung ist NUR für Antigravity (AGY) vorgesehen. Antigravity entdeckt und lädt MCP-Server, die global auf dem Hostsystem konfiguriert sind. Konfigurieren oder registrieren Sie MCP-Server NIEMALS global für andere Coding-Agenten (z. B. Claude Desktop, Cursor, VS Code, Cline). Registrieren Sie den MCP-Server an den folgenden Orten:

1. Workspace-Root mcp.json:

   {
     "mcpServers": {
       "codebase-memory": {
         "command": "codebase-memory-mcp",
         "args": []
       }
     }
   }
   

2. Workspace-Agenten-Konfiguration (.agents/mcp_config.json) (falls das Repository .agents/ verwendet):

   {
     "mcpServers": {
       "codebase-memory": {
         "command": "codebase-memory-mcp",
         "args": []
       }
     }
   }
   

3. Globale Host-Konfiguration (nur Google Antigravity / AGY): Fügen Sie codebase-memory ausschließlich zu den AGY-Host-Konfigurationen hinzu:
   • ~/.gemini/antigravity/mcp_config.json
   • ~/.gemini/config/mcp_config.json (Nicht in Claude Desktop, Cursor oder anderen Coding-Agenten registrieren):

   {
     "mcpServers": {
       "codebase-memory": {
         "command": "codebase-memory-mcp",
         "args": []
       }
     }
   }
   

3.3. Git-Hygiene & Persistenz

3.3. .cbmignore-Ausschlüsse konfigurieren (Editor-Stottern & Erkennungschaos verhindern)

• Nur lokal (Standard): Fügen Sie .codebase-memory/ zur .gitignore hinzu.

[!IMPORTANT] Stotter-Prävention & Ausschlüsse bei hoher Änderungsrate (.cbmignore): codebase-memory-mcp liest eine .cbmignore-Datei, die sich strikt im Repository-Root befindet (<repo>/.cbmignore), und verwendet die .gitignore-Syntax. Ohne .cbmignore lösen Nicht-Code-Dateien (wie Planungsdokumente, Agenten-Speicher, Test-Artefakte und Build-Caches) bei jeder Bearbeitung kontinuierlich AST-Erkennung, Typauflösung und Festplattenschreibvorgänge aus. Generieren Sie immer <repo>/.cbmignore im Repository-Root:

# codebase-memory-mcp Ignorierregeln (.cbmignore)
# Verhindert, dass Nicht-Code- und Dateien mit hoher Änderungsrate die Graph-Indizierung auslösen oder den AST-Graphen aufblähen.

# Agenten-Logs, Metadaten und Planungsdokumente (hohe Änderungsrate während aktiver Sitzungen)
.agents/
docs/
*.md

# Build-Artefakte & Kompilierungs-Caches
dist/
build/
out/
.next/
.swc/

# Tests, Berichte und Abdeckung
coverage/
test-results/
playwright-report/
blob-report/
.playwright-mcp/
storybook-static/
*storybook.log

# Codebase-Memory lokale Artefakte (Selbstauslösende Schleifen verhindern)
.codebase-memory/

# System und Logs
*.log
*.tsbuildinfo
.DS_Store

# Statische Assets und Medien (keine Code-Symbole)
public/
assets/
*.png
*.jpg
*.jpeg
*.gif
*.svg
*.ico
*.webp
*.mp4
*.mp3
*.pdf

# Umgebung & Lockfiles
.env*
*.pem
*.lock
pnpm-lock.yaml
package-lock.json
yarn.lock
bun.lockb

3.4. Automatische Dateiüberwachung in Sitzungen deaktivieren (auto_watch = false)

[!CAUTION] System-Stottern verhindern: Standardmäßig registriert codebase-memory-mcp verbundene Projekte automatisch bei seinem Hintergrund-Git-Watcher (auto_watch = true). Auf Windows- und Multitasking-Systemen erkennt der Watcher Dateispeicherungen, erzeugt einen index.supervisor-Worker-Prozess und komprimiert .codebase-memory/graph.db.zst mittels zstd bei jedem einzelnen Tastendruck/Speichervorgang, was zu schwerwiegenden Mikro-Stottern in der Editor-UI und im Fenstermanager führt. Deaktivieren Sie die automatische Sitzungsüberwachung immer global:

codebase-memory-mcp config set auto_watch false

Wenn deaktiviert, registrieren sich Sitzungen nicht beim Hintergrund-Watcher, wodurch Editor-Einfrieren vollständig eliminiert werden. Der Graph wird über MCP-Tools abgefragt und explizit bei Bedarf aktualisiert.

3.5. Git-Hygiene & Persistenz

• Nur lokal (Standard): Fügen Sie .codebase-memory/ zur .gitignore hinzu. Committen Sie das binäre Artefakt nicht bei jedem Speichern.
• Team-Snapshot-Sharing: Wenn Sie den vorindizierten Graph-Snapshot für das Team committen möchten, verfolgen Sie .codebase-memory/graph.db.zst mit Git LFS in der Root-.gitattributes:

  .codebase-memory/graph.db.zst filter=lfs diff=lfs merge=lfs -text
  

3.4. Erste Indizierung & Kadenz-Skript

3.6. Erste bedarfsgesteuerte Indizierung & Kadenz-Skript

1. Führen Sie die erste Indizierung bei Bedarf durch (verwenden Sie den moderate- oder fast-Modus, um umfangreiche semantische Embedding-Berechnungen zu überspringen):

   codebase-memory-mcp cli index_repository --repo-path "<canonical-repo-path>"
   codebase-memory-mcp cli index_repository --repo-path "<canonical-repo-path>" --mode moderate
   

2. Fügen Sie ein Kadenz-Skript zu package.json hinzu, um den Index bei wichtigen Meilensteinen/Commits zu aktualisieren:

   {
     "scripts": {
       "cbm:update": "codebase-memory-mcp cli index_repository --repo-path . --mode moderate --persistence true"
     }
   }
   

---

Schritt 4: Git-Hooks mit Husky & Commitlint einrichten

Erzwingen Sie Conventional Commits und stellen Sie sicher, dass Testsuiten ausgeführt werden, bevor Code in entfernte Branches gepusht werden kann.

1. Dev-Abhängigkeiten installieren:

   pnpm add -D husky @commitlint/cli @commitlint/config-conventional
   

2. commitlint.config.mjs konfigurieren:

   export default {
     extends: ["@commitlint/config-conventional"],
   };
   

3. Husky initialisieren:

   pnpm exec husky init
   

4. commit-msg-Hook konfigurieren:

   echo "pnpm exec commitlint --edit \$1" > .husky/commit-msg
   

5. pre-push-Hook konfigurieren: Erzwingen Sie die Ausführung der Testsuite vor jedem git push:

   echo "pnpm run test:all" > .husky/pre-push
   

   [!NOTE] Stellen Sie sicher, dass Testskripte in package.json sichere Flags enthalten (z. B. --passWithNoTests), damit Repositories ohne Testdateien mit Exit-Code 0 beendet werden, anstatt Pushs zu unterbrechen. Erstellen Sie niemals Beispiel-/Dummy-Testdateien im Workspace.

---

Schritt 5: Mehrstufige Produktions-Docker-Containerisierung einrichten

Konfigurieren Sie die Containerisierung ausschließlich für eigenständige Produktions-Builds und -Bereitstellungen. Die lokale Entwicklung erfolgt auf dem Host-Rechner mit dem nativen Paketmanager des Projekts.

5.1. .dockerignore konfigurieren

Schließen Sie lokale Artefakte, Git-Verlauf und Geheimnisse aus:

node_modules/
.pnp/
.pnpm-store/
dist/
build/
coverage/
test-results/
.env*
*.log
.git/
.dockerignore
Dockerfile*
docker-compose*.yml
.codebase-memory/

5.2. Mehrstufiges Dockerfile

Erstellen Sie einen 3-stufigen mehrstufigen Build (dependencies → builder → runner), der unter einem sicheren Nicht-Root-Benutzer läuft:

ARG NODE_VERSION=22-slim

FROM node:${NODE_VERSION} AS dependencies
WORKDIR /app
ENV CI=true
COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN --mount=type=cache,target=/root/.local/share/pnpm/store \
  if [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm install --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  else yarn install --frozen-lockfile; fi

FROM node:${NODE_VERSION} AS builder
WORKDIR /app
COPY --from=dependencies /app/node_modules ./node_modules
COPY . .
ENV NODE_ENV=production
RUN if [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm run build; else npm run build; fi

FROM node:${NODE_VERSION} AS runner
WORKDIR /app
ENV NODE_ENV=production
ARG PORT=3000
ENV PORT=${PORT}
ENV HOSTNAME="0.0.0.0"
COPY --from=builder --chown=node:node /app/dist ./dist
USER node
EXPOSE ${PORT}
CMD ["node", "dist/index.js"]

5.3. Docker-Compose-Stacks

1. Lokaler Build & Test (docker-compose.yml):

   services:
     app:
       build:
         context: .
         dockerfile: Dockerfile
       container_name: app-production
       restart: unless-stopped
       ports:
         - "${PORT:-3000}:${PORT:-3000}"
       environment:
         - NODE_ENV=production
   

2. Produktions-Pre-Build-Stack (docker-compose.prod.yml): Zieht vorgebaute Multi-Arch-Images direkt von GHCR ohne Quellcode:

   services:
     app:
       image: ghcr.io/<lowercase-owner>/<lowercase-repo>:${IMAGE_TAG:-latest}
       container_name: app-production
       restart: always
       ports:
         - "${PORT:-3000}:${PORT:-3000}"
       environment:
         - NODE_ENV=production
   

---

Schritt 6: Credit-Optimiertes CI/CD & Release-Please-Automatisierung einrichten

Automatisieren Sie semantische Releases, Changelogs und die Multi-Arch-Veröffentlichung (AMD64 & ARM64) im GitHub Container Registry über .github/workflows/release-please.yml:

Kern-DevOps-Designregeln:

1. Automatisiertes Test-Gate: Führt Projekt-Tests bei Pull-Requests und Commits auf main aus.
2. Release-Please-Automatisierung: Automatisiert Versionssprünge, Changelogs und Release-PRs.
3. concurrency.cancel-in-progress: false: Brechen Sie niemals Release-Workflows oder Main-Branch-Bereitstellungen ab, die gerade ausgeführt werden.
4. Zweistufiger Multi-Arch-Matrix-Builder: Bauen Sie AMD64 und ARM64 auf nativen Runner-Maschinen (ubuntu-latest und ubuntu-24.04-arm) ohne QEMU-Emulation. Pushen Sie Images per Digest.
5. Digest-Manifest-Zusammenführung: Ein nachgelagerter merge-manifest-Job fügt AMD64- und ARM64-Digests zu einem einheitlichen Multi-Arch-Tag zusammen.
6. Repository-Name in Kleinbuchstaben: Transformieren Sie github.repository immer über t

…

[abgeschnitten für die Übersetzung]