CDN-Proxy — Core v1 (Phasen-0–6-Quellkandidat)

cdn-proxy ist ein reines Codex-Plugin mit genau einem lokalen Stdio-MCP-Server, cdn-node, zum Auditieren oder Konfigurieren eines registrierten Linux-Origins als einen über Cloudflare ausgelieferten 3x-ui/Xray-WebSocket-Knoten.

Status — ehrlicher Umfang dieses Builds

Dieses Repository enthält den Quellkandidaten für Phase 0–6: Grundgerüst und lokalen Lebenszyklus, das ausführbare Vertragswerk und das Ledger, den Audit-Ablauf, den Clean-Host-Installer und den Ablauf der Broker-Anmeldedaten, den vollständigen Node-Ablauf mit authentifizierter Ende-zu-Ende-Verifizierung sowie den optionalen BBR-Zweig mit beiden Rollback-Graphen, den sechs Core-Hook-Ereignissen und einem auditieren Quellpaket-Layout.

• INSTALLABLE: NOT_CLAIMED

• RUNNABLE: NOT_CLAIMED

• ACCEPTED: NOT_CLAIMED

Jeder externe Adapter (SSH, Cloudflare, 3x-ui, Nginx, Keychain-Broker) ist weiterhin eine injizierte Nahtstelle. Der Produktions-Adapter-Satz ist phasengesteuert und bleibt vor dem Dispatch ausfallsicher geschlossen (fail closed), sodass dieser Build keinen echten Server, keine Cloudflare-Zone, keinen DNS-Record, kein Zertifikat, keinen Kernel und keinen Keychain-Eintrag lesen oder verändern kann. Die Suite und die Lifecycle-Prüfungen verwenden Fake-Adapter und explizite temporäre Runtime-Wurzeln. Ihr Bestehen ist kein Beleg für eine Clean-Host-Installation, echten authentifizierten Staging-Traffic oder Betrieb auf realer Infrastruktur.

Related MCP server: Infrastructure MCP Server

Zuerst lesen — GitHub-Release-Grenze

Dieses Repository wird als überprüfbarer, reproduzierbarer Quell-Release-Kandidat veröffentlicht, nicht als sofort anschließbarer Produktions-Operator. Es ist dafür gedacht, den geschlossenen MCP-Vertrag zu prüfen, die hermetische Test-Suite auszuführen, die Paketoberfläche zu inspizieren und freigegebene Adapter- oder Staging-Arbeiten fortzusetzen.

Das Veröffentlichen oder Klonen dieses Repository ändert diese Grenzen nicht. Eine künftige Phase mit echter Umgebung muss ausdrücklich autorisiert werden und muss authentifizierten Traffic, zum ordnungsgemäß erwarteten, nachvollziehbaren ausgehenden Verkehr, korrelierte Logs, geschütztes Beeinträchtigung der bestehenden Leitung und jedes erforderliche Rollback-Verhalten nachweisen.

Plugin-Identität

Das Codex-Plugin und das npm-Paket heißen cdn-proxy. Sein MCP-Server bleibt cdn-node: Dieser Servername und sein 31-Tool-Katalog sind durch den eingefrorenen Core-v1-Vertrag festgelegt, sodass eine Markenänderung sie weder umbenennen noch umreihen darf.

Vertragsautorität

Das eingefrorene Übergabedokument 02-mcp-tool-plan.md (SHA-256 a4bf469b9f5dd61a03b73b7b61cfb818a962de280e107aefe56442a43a0c542ea0) ist die alleinige Autorität für den 31-Tool-Katalog, alle 93 geschlossenen Schemas, das Fehlervokabular, die Zustände und die Richtlinien. scripts/extract-contract.cjs extrahiert die beiden eingebetteten ausführbaren Module byte-identisch nach contract/; der Server bedient diese eingefrorenen Objekte direkt, und die Tests extrahieren sie bei jedem Lauf erneut und vergleichen sie byteweise. Es existiert keiner von Hand geschriebener zweiter Katalog.

Erneuter Extrahierung (schreibgeschützt gegenüber dem eingefrorenen Paket):

CDN_OPERATOR_SPEC_PATH=/path/to/handoff/02-mcp-tool-plan.md node scripts/extract-contract.cjs

Was dieser Build erzwingt

• Nur-Clean-Host-Installation durch einen gepinnten Adapter. Genau ein zur Build-Zeit auf die Zulassungsliste gesetzter, digest-gepinnt Früchte und serverseitig aus Inventarfakten aufgelöste Adapter. Es existiert weder ein Aufruferbefehl, nicht einmal argv, kein Skript, keine URL, kein Pfad, kein Benutzername, kein Passwort, keine Port und keine Nutzlast, die auf der gesamten Installer-Oberfläche auffindbar sind. Bestehende, Teilanlagen, gedriftete, mehrdeutige und nicht unterstützte Installationen verweigern jeweils vor jeder Wirkung.

• Vom Broker gehaltene Anmeldedaten. Der Server hält nur opake SecretRefs und maskierte Metadaten. Erzeugung, Verwahrung und Nutzung der Panel Administrator-Anmeldedaten, Client-Anmeldedaten, Laufzeitgeheimnisse der profile, des WebSocket-Pfads und des privaten Origin-CA-Schlüssels liegen vollständig hinter der Keychain-Naht; Ein Broker, der Schlüsselbytes anbietet, wird abgelehnt, nicht redigiert.- Ein eingerichtet dedizierter, überall gebundener Hostname. Der Cloudflare-Record, der Zertifikats-SAN, das Nginx server_name sowie Adresse, SNI und WebSocket-Host des Client-Profils müssen alle denselben registrierten Hostnamen benennen, und der WebSocket-Pfad muss eingehend, über Route und Profil byte-identisch sein. Apex, Verwaltungshostname und sämtliche mehrdeutige Namen werden abgewiesen.

• Create-only, no-clobber. Jede Ressource, die dieser Lauf erzeugt, wird ausschließlich exklusiv an einer nachweislich freien Stelle erzeugt. Nichts wird übernommen, gesichert, überschrieben oder wiederhergestellt. Ein Erkennungskonzer Ergebnis ein konkurrenter, Dritter-Digest stoppt den Schreibzugang und führt zu manuellem Bearbeiten.

• Cloudflare ist auf Zonenebene nur lesend. Strict-kompatibler Modus und WebSockets sind Voraussetzungen, die zu beobachten, nicht zu verstellen sind; Core v1 führt keinerlei Zonenweite Schreiboperation vor.

• Erst Nachweis, dann Proxy. Der Node-Datensatz wird ungeproxt erstellt; Der Proxy wird erst aktiviert, nachdem ein direkter TLS+WebSocket-Nachweis an den gegenwärtigen Route gebunden wurde.

• Authentifizierte Ende-zu-Ende-Verifizierung oder nichts. Für die Akzeptanz ist eine echte, authentifizierte Proxy-Anfrage erforderlich, deren beobachteter öffentlicher Ausgang dem erwarteten Verhalten des Origins am gleichen zugelassenen Ziel entspricht, verglichen als opaque HMAC-Digests unter einem pro-Installation-Schlüssel. Latenz, ein offener Port, ein Zertifikat, ein TLS-Handshake, ein HTTP 101-Verbind und ein statisches Profil sind jeweils ausdrücklich nicht ausreichend.

• BBR nur auf unterstützten Kerneln. Genau ein exklusiv erzeugtes, eigener Drop-in mit dem exakten bbr/fq Schlüsseln. Core v1 installiert oder aktualisiert niemals einen Kernel, greift nie in einen Bootloader oder eine gemeinsame sysctl-Datei ein und startet nie neu.

• Rollback macht nur rückgängig, was dieser Lauf besitzt. Acht logische Diagrammknoten erweitern sich auf die eingefrorenen elf geordneten atomischen Stufen (zusätzlich der vier eigenen BBR-Stufen); jeder Schritt sichert eine dauerhafte Empfangsbestätigung (Receipt) nach seinem eigenen Readback und vor dem nächsten. Die Empfangsbestätigung der letzten Stufe und die Gesamtempfangsbestätigung werden nur beide oder keine geführt. Ein belegter zusammenhängender Prefix setzt exakt an seinem restlichen Suffix fort, und eine abgeschlossene Stufe wird nie wiederholt. Importierte Anmeldedaten werden nie beseitigt.

• Kein Fortsetzen in Vorwärtsrichtung. Eine abgelaufene wirksame Genehmigung entzieht alle weitere Autorität und mündet in den dreiteiligen Zustand: zero Commits führen zurück zu INVENTORIED, eigene Commits erzeugen eine Wiederherstellungsverpflichtung und ROLLBACK_REQUIRED, und unbekannte oder dritte Beobachtungen führen in den manuellen Modus.

Aufbau

• .codex-plugin/plugin.json, .mcp.json (ein einziger cdn-node-Stdio-Server), skills/cdn-proxy/SKILL.md, hooks/hooks.json (sechs Command-Ereignnisse)

• contract/ — eingefrorene Vertrag-Module sowie Abkunfts-Digests

• datac/ — Server-Einst, strikte Ajv-2020-12-Validierung vor jedem Handler, Dispatch, geschlossene Adapter-/Manifest-/Broker-/Keychain-Registry, Vorwärts-Dispatch-Gate, Domäine-Identität-Bindung, HMAC-Binder mit niedrriger Entropie, Rollback-Stufe-Engine, SQLite-WAL-Ledger, 31 Händler

• runtime/, lifecycle/ — kontrollierter Runtime-Root pro Benutzer, ActiveSet-Re ceipts, atomares Installieren/Update/explicit-Rollback/Uninstall, Doctor, Verift

• DEPENDENCIES.json — aus der Lockdatei abgeleitete Abhängigkeiten/ Versionn/Lizenzen-/Integrität-Auditliste

• tests/ — Vertragparität, 93-Schema-Instanzzen, Vor-Handler-Ablehnung, Audit-Journey, Ledger/WAL/Idempotenz/Wiederherstellung, Install-Journey, Broker-Credentials-Grenze, Node-, authentifizierte E2E, BBR, Rollback, Ablauf/Drift/Reconciliation-Wiederherstellung und statische Sicherheitsscans

Ausführung

npm ci               # installs the lockfile-pinned dependency closure
npm test             # full suite (fake adapters, temp data dirs only)
npm run acceptance   # full suite plus frozen-package re-verification
npm pack --dry-run   # inspect the audited source-package surface
node lifecycle/doctor.cjs

Benötigt Node.js >= 24 (nutzt die in gebauten node:sqlite und node:test).

Für einen Re-Check des Release-Kandidaten lassen Sie npm run acceptance aus. Es lässt die gesamsuite erneut aus, überluft dagegen das eingefrorene Übergabepaket vor und nach dem Lauf, kontrolliert die eingequellten Vertragsbytes und führt doctor gegen einen temporären Runtime-Wurzelpunkt aus. Diese Prüfungen bleiben damit sämtlich lokal und hermetisch.

Lizenz

Dieser Quellkandidat wird mit der Paketlizenz UNLICENSED veröffentlicht. Die öffentliche Verfügbarkeit dient der Prüfung und freigegebenen Weiterentwicklung; sie gewährt keine Opensource-Redistributions- oder Produktionsnutzung.