BoundedRelay

BoundedRelay ermöglicht es Claude Code, eine klar abgegrenzte Aufgabe an die lokal installierte Codex-CLI über MCP zu übergeben. Der Aufruf kehrt sofort mit einem Job-Handle zurück. Claude kann dann anzeigen, was der Worker tut, effizient auf das nächste echte Update warten, das Ergebnis abrufen oder den Job abbrechen.

Claude Code  ── local MCP/stdio ──>  BoundedRelay  ── codex exec --json ──>  Codex
                                             │
                                             ├─ policy and resource limits
                                             ├─ deterministic SDD routing
                                             ├─ content-addressed dual review
                                             ├─ sanitized live activity
                                             └─ isolated proposal clone

Die unterstützte v0.1-Topologie ist bewusst einseitig: Claude Code → BoundedRelay → Codex. BoundedRelay bietet keine Codex-zu-Claude-Rückroute, und der Worker wendet generierte Änderungen niemals auf das Quell-Repository an.

[!WICHTIG] BoundedRelay ist ein unabhängiges Community-Projekt. Es ist nicht mit Anthropic oder OpenAI verbunden, wird von diesen nicht unterstützt oder gepflegt. Claude, Claude Code, Codex und OpenAI sind Marken ihrer jeweiligen Inhaber.

Version 0.1.0 ist eine lokale Entwicklungsversion. Das npm-Paket ist noch nicht veröffentlicht, und v0.1 hat keinen Remote-Dienst, keinen Daemon, keine Datenbank, keinen persistenten Job-Speicher und kein Audit-Ledger.

Warum BoundedRelay

• Sichtbar statt eingefroren: sichere Aktivitätsbezeichnungen, Ereigniszähler, verstrichene Zeit, Zeit seit dem letzten Update, Warteschlangenposition und revisionsbewusstes Polling.

• Standardmäßig schreibgeschützt: Analysen fordern immer die read-only-Sandbox von Codex an.

• Begrenzte Autorität: Der Server besitzt Workspace-Roots, Modell-Overrides, Umgebungsweiterleitung, Timeouts, Nebenläufigkeit, Ausgabe- und Patch-Limits.

• Überprüfung vor Mutation: Der Vorschlagsmodus arbeitet in einem Wegwerf-Klon, validiert den resultierenden Patch und wendet ihn niemals auf den Quell-Worktree an.

• Adaptive Arbeitsaufteilung: Der optionale SDD-Router wählt zuerst die beste versionierte Aufgabenart/Spur-Passung, verwendet Präferenz und einen neutralen Anteil nur bei Passungsgleichheit und gibt abhängigkeitssichere Wellen mit jeweils höchstens einem Schreiber aus.

• Checkpointierte Ausführung: Das optionale Spec-Kit-Paket verwandelt eine verifizierte Route in execution.json, führt jeweils eine exakte Abhängigkeitswelle aus und verlangt, dass jeder Schreiber-Checkpoint ein einzelner Non-Merge-Commit ist, der direkt vom aktiven Basisstand abstammt.

• Unabhängige strenge Überprüfung: Claude-Host-Evidenz wird eingefroren, bevor eine frische schema-constraintierte Codex-Überprüfung in einem abgetrennten schreibgeschützten Klon stattfindet, und beide Genehmigungen müssen mit einem aktuellen inhaltsadressierten Siegel übereinstimmen.

• Kein Fake-Fortschritt: BoundedRelay meldet beobachtete Lebenszyklusaktivität. Es erfindet keinen Prozentsatz der Fertigstellung oder eine ETA.

• Explizite öffentliche Oberfläche: fokussierte MCP-Tools für Fähigkeitserkennung, Workspace-Inspektion, Routing, Überprüfung, Einreichung, Status, Ergebnis, Abbruch und Verlauf.

Was Claude anzeigen kann, während Codex arbeitet

codex_worker_status gibt eine bereinigte Momentaufnahme wie diese zurück:

{
  "status": "running",
  "revision": 14,
  "progress": {
    "phase": "working",
    "activity": "running_command",
    "activityLabel": "Codex is running a sandboxed command",
    "eventCount": 8,
    "commandCount": 2,
    "messageCount": 0,
    "lastEventType": "item.started",
    "updatedAt": "2026-08-27T18:30:00.000Z",
    "elapsedMs": 12420,
    "sinceLastUpdateMs": 180
  }
}

Die Statusoberfläche legt ein festes, server-eigenes Aktivitätsvokabular offen. Sie legt keine Chain-of-Thought, keinen Befehlstext, keine Tool-Argumente, keine Repository-Dateipfade aus Ereignissen und keine beliebigen Codex-Ereignis-Payloads offen.

Related MCP server: cc-in-codex

Wo das hineinpasst

Für allgemeine Claude-Code-zu-Codex-Delegation bewerten Sie zuerst die offizielle openai/codex-plugin-cc von OpenAI. Verwenden Sie BoundedRelay, wenn Sie speziell eine lokale MCP-Policy-Grenze um den Codex-Subprozess benötigen.

Siehe den detaillierten Vergleich mit dem offiziellen Plugin und den breiteren, nicht bewertenden Ökosystem-Vergleich.

Voraussetzungen

• Node.js >=22.13.0 und npm;

• Git verfügbar auf PATH;

• Codex-CLI installiert und für den aktuellen Betriebssystem-Benutzer authentifiziert;

• Claude Code mit lokaler stdio-MCP-Unterstützung;

• ein Git-Repository für jede delegierte Aufgabe.

BoundedRelay verwendet die unterstützte nicht-interaktive Schnittstelle codex exec --json. Es hat keine Anmeldeinformationen und keinen Anmeldeinformationsspeicher. Gespeicherte Codex-Authentifizierung wird über die normale Benutzerumgebung verwendet; direkte API-Token-Weiterleitung ist ein separates Opt-in.

Schnellstart aus dem Quellcode

Das Paket ist noch nicht auf npm. Klonen oder laden Sie dieses Repository herunter und führen Sie es lokal aus.

1. Installieren, verifizieren und lokale Umgebung prüfen

git clone https://github.com/mohammad19974/bounded-relay.git
cd bounded-relay
npm ci
npm run check
node dist/cli.js doctor

doctor prüft Node-abhängige Abhängigkeiten, Codex-Befehls-Kompatibilität, Git und den Codex-Anmeldestatus, ohne einen Modellaufruf zu machen.

Um das verpackte Spec-Kit und die Claude-Code-Integration zu prüfen, ohne ein Verbraucher-Repository zu installieren oder zu ändern:

node dist/cli.js sdd validate
node dist/cli.js sdd path

Der Validator prüft verpackte Dateien und JSON-Manifeste. Er ruft Claude Code nicht auf und zertifiziert es nicht; siehe den Integrationsleitfaden für den separaten hostseitigen Validierungsschritt.

2. Den gebauten Worker bei Claude Code registrieren

Führen Sie dies aus dem BoundedRelay-Verzeichnis aus, damit die Shell einen absoluten Pfad aufzeichnet. Der Benutzerbereich ist die empfohlene persönliche Standardeinstellung, da dieselbe Installation verfügbar ist, wenn Claude Code andere Projekte öffnet:

WORKER_ENTRY="$(pwd)/dist/cli.js"

claude mcp add \
  --transport stdio \
  --scope user \
  bounded-relay \
  -- node "$WORKER_ENTRY" serve

--scope user ist persönlich für Ihr Betriebssystem-Konto und wird nicht in ein Repository übernommen. Um die Registrierung auf ein einzelnes Projekt zu beschränken, wechseln Sie stattdessen in das Ziel-Git-Repository, bevor Sie den Befehl ausführen, und verwenden Sie --scope local; der lokale Bereich gehört zu dem Projekt, in dem der Befehl ausgeführt wird.

Dann verifizieren:

claude mcp list

Führen Sie in Claude Code /mcp aus. bounded-relay sollte als verbunden angezeigt werden.

3. Die erste schreibgeschützte Delegation ausführen

Öffnen Sie Claude Code in einem Git-Repository und fragen Sie:

Use bounded-relay to inspect this workspace and start a read-only architecture review.
Poll codex_worker_status with afterRevision so you show each new activity without spam.
When the job completes, retrieve the result and summarize only high-confidence findings.

Claude sollte codex_worker_workspace, codex_worker_analyze, codex_worker_status und codex_worker_result verwenden.

Für macOS, Linux, Windows PowerShell, projektspezifische Konfiguration, Entfernung, Upgrades und häufige Einrichtungsfehler lesen Sie den vollständigen Installations- und Ersteinrichtungsleitfaden.

MCP-Tools

Die stabilen v0.1-Protokoll-/Konfigurations-Namespaces bleiben codex_worker_* und CCW_*. Die öffentliche Marke ist BoundedRelay; die Beibehaltung dieser expliziten Namespaces vermeidet eine unnötige Breaking-Migration, bevor der Vertrag stabilisiert wird.

Lesen Sie die vollständige Tool-Referenz, einschließlich jedes Aktivitätszustands, jeder Eingabe, jeder Ausgabe und jedes Fehlercodes.

Sicherheitsvertrag

Analysemodus — Standard

• Fordert die read-only-Sandbox von Codex in einem kanonischen erlaubten Git-Repository an.

• Lehnt nur für Vorschläge vorgesehene Felder wie writePaths und expectedRevision ab.

• Gibt die endgültige Analyse von Codex plus beobachtete Nutzungsmetadaten zurück.

Adaptives SDD-Routing — modellfrei

• Validiert und kanonisiert eine begrenzte Aufgaben-DAG, ohne Dateien zu lesen oder ein Modell aufzurufen.

• Verwendet zuerst harte Spur-Berechtigung, dann versionierte Aufgabenart-Passung.

• Wendet eine berechtigte Präferenz nur auf eine exakte Basis-Passungsgleichheit an, dann konsultiert neutrale Aufwands-/Aufgabenzähl-Anteile. Es erzwingt niemals 50/50.

• Gibt Policy-Versionen, Spur-Passungs-Evidenz, Entscheidungsstufen, Gründe, Abweichungen, sichere Wellen und einen Inhalts-Fingerabdruck zurück.

• Gewährt niemals direkte Schreibberechtigung; jede Welle hat höchstens einen Schreiber.

Strukturierte SDD-Überprüfung — schreibgeschützt

• Friert normalisierte Claude-Host-Evidenz ein, bevor Codex startet, während seine Schlussfolgerungen aus dem Codex-Prompt herausgehalten werden.

• Der strenge Modus verlangt eine saubere vollständige Revision, versiegelt exakte Artefakt-Bytes und führt Codex schreibgeschützt in einem abgetrennten origin-freien Klon aus, der nachweislich mit dem Siegel übereinstimmt.

• Überprüft die Quelle nach Codex erneut und besteht nur, wenn beide unabhängigen Überprüfungen dasselbe aktuelle strenge Siegel genehmigen.

• Entwurfsmodus und generische Analyse sind beratend und können ein strenges Gate nicht erfüllen.

Vorschlagsmodus — standardmäßig deaktiviert

• Wird nur registriert, wenn der Server mit CCW_ENABLE_PROPOSALS=true startet.

• Erfordert einen sauberen Quellbaum, eine exakte vollständige Git-Objekt-ID und explizite repository-relative Schreibpfade.

• Erstellt einen sauberen Wegwerf-Klon an der fixierten Revision.

• Führt workspace-write nur innerhalb dieses Klons aus.

• Lehnt geänderte Refs, geändertes HEAD, Dateien außerhalb des Geltungsbereichs, geschützte Pfade, Symlink-Änderungen, übermäßig große Patches und übermäßige geänderte Dateianzahlen ab.

• Gibt einen validierten Vollindex-Binärpatch und SHA-256-Digest zurück und löscht dann den Klon.

• Wendet den Patch niemals auf die Quelle an, committet, pusht, veröffentlicht oder stellt ihn bereit.

Aktivieren Sie ihn erst, nachdem der schreibgeschützte Modus funktioniert:

claude mcp remove bounded-relay --scope user

claude mcp add \
  --env CCW_ENABLE_PROPOSALS=true \
  --transport stdio \
  --scope user \
  bounded-relay \
  -- node /absolute/path/to/bounded-relay/dist/cli.js serve

codex_worker_result lässt Patch-Text standardmäßig aus. Ein Aufrufer muss includePatch=true anfordern, den zurückgegebenen Digest verifizieren, den Inhalt überprüfen und separat entscheiden, ob er angewendet werden soll. Lesen Sie das vollständige Sicherheitsmodell, bevor Sie Vorschläge aktivieren.

Architektur

flowchart TB
    Human[Human developer] <--> Host["Claude Code<br/>host orchestrator<br/>user-selected Claude model"]
    Host --> Plan["Spec Kit plan, committed tasks manifest,<br/>reviews, and human gates"]
    Plan --> Route["Verified adaptive route<br/>exact pending-ID coverage"]
    Route --> Ledger["execution.json<br/>dependency-ordered waves"]

    subgraph Relay["BoundedRelay MCP policy boundary"]
        Router["Deterministic router"]
        Review["Codex read-only lane<br/>analysis or detached strict review"]
        Proposal["Codex proposal<br/>revision-pinned disposable clone"]
    end

    Route <--> Router
    Ledger -->|Codex read-only task| Review
    Ledger -->|Codex write task| Proposal
    Ledger -->|claude-host task| Host
    Proposal -->|patch bytes + digest;<br/>never integrated by BoundedRelay| Host
    Host -->|inspect and integrate one writer| Checkpoint["Tested Git tree + exactly one<br/>non-merge checkpoint commit"]
    Checkpoint -->|next exact wave| Ledger
    Checkpoint -->|freeze host findings| Host
    Host -->|fresh strict review request| Review
    Host -->|frozen host evidence| Dual["Same-seal dual-review<br/>verification"]
    Review -->|strict sealed Codex evidence| Dual
    Dual --> Converge["Fail-closed convergence audit<br/>no direct implementation"]
    Converge -->|no new work| Proof["Revalidated proof pack<br/>isolated recheck + atomic handoff"]
    Converge -->|new pending tasks| Restart["Abort stale chain<br/>fresh routed run"]
    Restart --> Plan
    Proof --> Human

Claude Code ist der einzige Host-Orchestrator. Opus, Sonnet und andere Claude-Modelle sind mögliche benutzergewählte Host-Modelle, keine separaten Agenten in diesem Diagramm. BoundedRelay startet niemals Claude und macht diese Modellwahl nicht zu einem Drei-Modell-Orchestrierungssystem.

Orchestrator bedeutet, dass der Claude-Code-Host Befehle, Artefakte, Gates, Provider-Aufrufe und die autorisierte Integration koordiniert. Es ist kein drittes Modell, kein Modellselektor und kein automatischer Merger. BoundedRelay ist die lokale Orchestrierungsgrenze und Codex-Worker-Steuerungsebene; es als symmetrischen Claude/Codex-Orchestrator zu bezeichnen, würde seine Autorität überzeichnen.

Siehe Architektur und die Architekturentscheidungsprotokolle.

Planung, Ausführung und Überprüfung: vor vs. mit BoundedRelay

Dies ist ein qualitativer Vergleich der Workflow-Architektur, kein Benchmark. Tatsächliche Korrektheit, Geschwindigkeit, Token-Nutzung und Kosten hängen von der Aufgabe, den Modellen, den Prompts, dem Repository und dem Konto ab; es werden keine Verbesserungen oder Einsparungen garantiert. Beispielhafte Aufwandspunkte oder Provider-Anteile sind illustrative Planungsmetadaten, keine gemessene Nutzung, Qualitätsbewertungen oder Benchmark-Ergebnisse.

Der gesteuerte Pfad ist an seinen Vertrauensgrenzen bewusst sequenziell:

flowchart LR
    S[Specify] --> P[Plan]
    P --> PR[Independent<br/>dual plan review]
    PR --> R[Quality-first<br/>task routing]
    R --> X[Verified execution.json]
    X --> W[Do-while waves<br/>one writer + checkpoint]
    W --> IR[Routing-base-to-HEAD<br/>dual implementation review]
    IR --> V[Fail-closed convergence audit<br/>no direct implementation]
    V -->|no new work| CR[Fresh no-delta<br/>dual review]
    V -->|new pending tasks| NR[Fresh routed run]
    CR --> E[Revalidated proof pack<br/>isolated recheck + atomic handoff]

Optionaler Spec-Kit-Workflow

Dieses Quellrepository verwendet .specify/ für seine eigenen wesentlichen Änderungen, aber Spec Kit ist bewusst keine BoundedRelay-Laufzeitabhängigkeit. Das npm-Paket enthält eine eigene optionale Spec-Kit-Workflow/Erweiterung und ein Claude-Code-Plugin unter integrations/; es installiert keines von beiden automatisch.

Der Workflow friert Claudes Host-Review vor einem neuen Codex-Review ein, routet genehmigte Tasks über codex_worker_sdd_route, verifiziert routing.json und erstellt dann execution.json. Eine Spec-Kit-do-while-Schleife führt die kanonischen Abhängigkeitswellen der Reihe nach aus. Jede Welle startet vom vorherigen verifizierten sauberen Commit, verarbeitet bereite Read-only-Tasks vor ihrem einzigen möglichen Writer und muss akzeptierte Ergebnisse plus Check-Belege aufzeichnen, bevor ein menschlicher Checkpoint sie weiterbewegen kann. Der standardmäßige Codex-Anteil von 5.000 Basispunkten ist ein neutraler Metadatenwert, kein Kontingent. Berechtigung und Eignung können legitimerweise jeden tatsächlichen Anteil ergeben, einschließlich aller Implementierungs-Tasks auf einer Spur.

Das Routing wird aus dem exakten committeten tasks.md in seiner Revision erstellt. Seine standardmäßigen Checkbox-Task-IDs (T### oder länger) bilden ein inhaltsadressiertes Manifest, und Zuweisungen müssen jede unvollständige ID genau einmal abdecken, ohne eine abgeschlossene oder erfundene ID zu routen. Die genehmigte Plan-Review-Revision muss ein Vorfahre dieses Task-Checkpoints sein; spec.md und plan.md müssen unverändert sein, und die vollständigen strengen Plan-Nachweise werden erneut validiert, bevor das Routing fortgesetzt werden kann.

Check-Belege sind geschwärzte, vom Koordinator beglaubigte Digest-Datensätze für Befehle, Ausgaben, Arbeitsverzeichnis, Exit-Status null, Zeitstempel und den exakt getesteten Git-Baum. Writer-Belege müssen dem Checkpoint-Baum dieser Welle entsprechen; Konvergenz-Belege müssen ihrem versiegelten Review-Baum entsprechen. Sie sind keine signierten CI-Attestierungen, enthalten keine Rohausgaben und können nicht unabhängig beweisen, dass der Koordinator den behaupteten Befehl ausgeführt hat.

Codex-Schreib-Slices bleiben isolierte Vorschläge. Ihre exakten Patch-Bytes werden nur unter der ignorierten, laufzeitlokalen Datei patches/<task-id>.patch aufbewahrt; der Ausführungsvalidator berechnet den Digest neu, wendet diese Bytes auf einen Wegwerf-Git-Index an der aktiven Baseline an und verlangt, dass der resultierende Baum dem Checkpoint-Baum entspricht. Jeder Writer-Checkpoint muss genau ein Nicht-Merge-Commit sein, dessen einziger Elternteil die aktive Baseline ist. Claude Code oder der menschliche Koordinator prüft und integriert einen Patch – BoundedRelay tut das nie. Ein abgelehntes Gate bricht diese Nachweiskette ab. Korrigieren Sie die Artefakte oder den Code und starten Sie einen neuen Lauf; verwenden Sie die abgelehnte Route, das Ausführungsledger, das Review oder das Beweispaket nicht erneut.

Jedes Codex-Ausführungsergebnis zeichnet model und reasoningEffort auf (einschließlich null, wenn die Route Server-Standardwerte verwendet), und beide müssen exakt der gerouteten Richtlinie entsprechen. Eine kritische Claude-Host-Task erzwingt für die anschließende Codex-Cross-Review-Richtlinie das explizit auf der Allowlist stehende Profil gpt-5.6-sol / ultra; Nichtverfügbarkeit führt zu Fail-closed. Das Host-Modell bleibt das, was der Benutzer in Claude Code ausgewählt hat.

Das Implementierungs-Review vergleicht die genehmigte Routing-Basisrevision mit dem finalen HEAD und lehnt einen Umfang von mehr als 256 geänderten Pfaden ab. Konvergenz ist fail-closed: Sie prüft nur, implementiert nie direkt. Wenn sie neue ausstehende Tasks anhängt, stoppt die aktuelle Nachweiskette und diese Tasks erfordern eine neue Route und einen Wellenlauf; nur ein Ergebnis ohne Änderungen darf zu einem No-Delta-Review auf der Grundlage der genehmigten Implementierungsrevision übergehen. Für Implementierung und Konvergenz bindet die eingefrorene Host-Review-ID den Lauf, die Phase, die Nonce, die versiegelte Revision, den Quellnachweis-Digest, den Check-Digest und die vorbereitete Codex-Review-Richtlinie. Das finale, nur aus Digests bestehende proof-pack.json validiert statisch die vollständigen Routing-Projektionen, die exakten Quellketten von Ausführung über Implementierung bis Konvergenz, historische Wellen-Checkpoints, strenge Nachweise und die aktuelle Konvergenz-Aktualität. Es indexiert Digests und akzeptierte Identifikatoren, ohne Prompts oder rohe Provider-Ausgaben zu kopieren.

Nach der Genehmigung des Beweises schreibt Claude nur eine laufzeitlokale handoff-draft.md. Der Verifizierer kopiert die finale Revision und die Laufnachweise in ein isoliertes Git-Klon, validiert dort den Beweis erneut, prüft den exakten Bindungsmarker des Entwurfs und veröffentlicht atomar .specify/agents/HANDOFF.md. Die Wiederholung der Verifizierung mit demselben gültigen Entwurf ist idempotent; sie führt keine Provider-Arbeit erneut aus.

claude-host bedeutet immer das in Claude Code ausgewählte Modell. BoundedRelay startet Claude nicht, wählt kein Opus/Sonnet aus und verifiziert kein host-deklariertes Modell-Label. Jede kritische Route erfordert eine explizit auf der Allowlist stehende gpt-5.6-sol / ultra-Codex-Spur: Ausführung, wenn Codex die Task besitzt, oder Cross-Review, wenn claude-host sie besitzt. Ein nicht verfügbares Profil schlägt fehl, anstatt stillschweigend zurückzufallen.

Verwenden Sie den vollständigen Spec-Kit-Integrationsleitfaden für lokales Laden, Workflow-Nachweise, Strict-Gate-Regeln, Wiederherstellung und Entfernung.

Konfiguration

Sichere Standardwerte erfordern keine Projektkonfiguration.

Lesen Sie Konfiguration, bevor Sie Geheimnisse weiterleiten oder Proposals aktivieren.

Was BoundedRelay nicht beansprucht

• Es wählt kein objektiv „bestes“ Modell aus. Optionale Modell- und Reasoning-Werte bleiben explizite, server-allowlistete Auswahlmöglichkeiten.

• Es garantiert keinen besseren Code, keinen geringeren Token-Verbrauch und keine geringeren Kosten.

• Es macht aus lokalen Check-Belegen, Modell-Metadaten oder Patch-zu-Baum-Gleichheit keine signierten CI-/Provider-Attestierungen oder Korrektheitsbeweise.

• Die exakte Manifest-Abdeckung beweist, dass aufgezeichnete ausstehende IDs geroutet wurden, nicht dass tasks.md vollständig ist oder dass seine Tasks gut entworfen sind.

• High/Critical-Blockierung gilt für aufgezeichnete strukturierte Befunde; sie kann ein Versäumnis eines Reviewers nicht erkennen.

• Isolierte Handoff-Revalidierung und atomares Umbenennen signieren den Handoff nicht und verhindern nicht, dass ein unabhängiger Prozess ihn später ändert.

• Es legt private Chain-of-Thought nicht als Fortschritt offen.

• Es hält Jobs nach dem Beenden des Stdio-Serverprozesses nicht am Leben.

• Es verhindert nicht Schreibvorgänge, die manuell oder durch unabhängige Tools vorgenommen werden.

• Es macht Codex nicht offline und ändert keine Provider-Aufbewahrungsrichtlinien.

• Es wendet nichts automatisch an, committet, pusht, veröffentlicht, deployed oder mutiert entfernten Zustand.

Dokumentation

• Erste Schritte

• Dokumentationsindex

• Architektur

• Sicherheitsmodell

• Live-Status und MCP-Tools

• Konfiguration

• Kompatibilität

• Spec-Kit-Integration

• Ökosystem-Vergleich

• Fehlerbehebung

• Entwicklung

• Roadmap

• Rezepte

• Marken-Assets und Generierungshinweise

Projektstatus

0.1.0 ist bewusst vor-stabil. Verträge können sich vor 1.0.0 ändern. Prüfen Sie CHANGELOG.md und die Kompatibilitätshinweise, bevor Sie ein Upgrade durchführen.

Mitwirken, Sicherheit und Support

• Lesen Sie CONTRIBUTING.md, bevor Sie einen Pull-Request eröffnen.

• Melden Sie Sicherheitslücken privat über SECURITY.md.

• Nutzen Sie SUPPORT.md für Support-Grenzen und Diagnosedetails.

Lizenz

MIT