Channel Manager, Telegram und Support

Der Channel Manager ist der produktive Telegram-User-Bot-Weg des Accounts. Er bleibt technisch und datenschutzrechtlich vom älteren, nur bei Bedarf gestarteten Support-Bot getrennt. Diese Seite dokumentiert ausschließlich Architektur-, Health-, Deployment- und Retentionsmetadaten; Kontakte, Peer-IDs, Nachrichten und Telegram-Sitzungsinhalte erscheinen nicht im Wiki.

Verifizierter Status

Der Channel Manager läuft aus dem einzigen stabilen Git-Projektroot /home/wpmcp/codex-projects/channel-manager auf Forgejo-main-Commit d02537ca41c0. Supervisor verwendet direkt diesen Root und dessen .venv/bin/channel-manager; weder ein current- Symlink noch ein aktiver Channel-Manager-Releasepfad ist beteiligt. Der zugehörige Responses-Adapter läuft weiterhin aus Release 193f0c8e1bf4. Es existiert kein separater Dienst namens telegram-user-bot: Der User-Bot ist der Telethon-Adapter innerhalb des Channel Managers.

Zentrale Audio-Primärroute vom 30. August 2026

Der Manager sendet nach Allowlist-Prüfung das Originalaudio mit stabilem Requester und vorhandener Request-ID an den privaten zentralen Dienst. Unmittelbar nach dem Download prüft er die aktuelle Telegram-Freigabe ein zweites Mal, bevor Status, Reservierung oder zentraler beziehungsweise lokaler Providerpfad beginnen. Normalisierung und Provideraufruf liegen im Primärpfad dort. Der bisherige lokale AudioNormalizer und OpenAITranscriptionClient bleiben als Fallback erhalten. Dieser ist nur nach sicherem Connect-/Poolfehler oder explizitem fallback_safe=true zulässig. Read-, Write- und Protokollmehrdeutigkeit werden mit derselben Request-ID und kleiner Backofffolge bis zum konfigurierten Gesamttimeout reconciled. queued, normalizing und provider_inflight werden weiter gepollt; Timeout, unknown und unsichere Terminalzustände erlauben keinen lokalen Zweitdispatch. Nur streng validiertes JSON mit erlaubtem HTTP-Status, Content-Type, Bodylimit, Status und Dispatchvertrag kann Transkript oder Fallback auslösen. Die Vollsuite mit 210 Tests, Configcheck, fünf gezielte Mockbelege, sichere Nichterreichbarkeit und Rollback 0.5.0 → 0.5.1 waren grün.

Migration auf den stabilen Git-Root vom 30. August 2026

Der Root ist 0700, die versionierte private config.json liegt mit Mode 0600 direkt darin. Die Python-3.13-venv wurde am endgültigen Root aus der gesperrten Abhängigkeitsspezifikation aufgebaut. Lokaler und öffentlicher /healthz liefern 200, lokale und öffentliche unautorisierte /v1/messages liefern 401, PRAGMA integrity_check liefert ok, und der Prozess-CWD entspricht exakt dem festen Projektroot. Ein releases/- Unterbaum ist dort nicht mehr vorhanden.

Zugriffsschutz vom 28. August 2026

Der produktive Stand prüft Owner, Allowlist, Pending und Banned jetzt vor Medien-Download, SQLite, Codex-Account-Snapshot und LLM. Die private Registry ist 0600, ihr Verzeichnis 0700; der Owner ist als eigener Top-Level-Eintrag gebunden und kommt nicht in der zusätzlichen Allowlist vor. Linux-Suite, Config- und Installcheck, Schema-Migration, Loopback-/Public-Health sowie ein realer Luna-Direktlauf waren erfolgreich.

Medien- und Ausführungsrollout vom 29. August 2026

Bilder und begrenzte Dokumentinhalte erreichen den Luna-Koordinator jetzt Ende zu Ende. Der Adapter materialisiert validierte Bild-Capabilities als privates localImage und entfernt das Jobverzeichnis nach Abschluss. Conversation-Jobs besitzen keine lokale Shell; ausschließlich autorisierte Server-Sessions dürfen über einen zusätzlichen Adapter-Opt-in ohne Sandbox laufen. Vollsuiten, Loopback-/Public-Health, 401-Gate, synthetischer Bild-Smoke, Datei-Smoke und ein verifizierter Server-Shell-Smoke waren grün.

SQLite-Verbindungsreparatur vom 29. August 2026

Eine bestätigte Dateideskriptor-Erschöpfung konnte trotz grüner HTTP-Health Lesebestätigungen ohne finale Antwort verursachen. Der Responses-Adapter schließt seine SQLite-Verbindungen jetzt in allen Erfolgs- und Fehlerpfaden explizit. Der Channel Manager schließt zusätzlich teilweise aufgebaute Verbindungen sowie Transaktionen nach einem fehlgeschlagenen BEGIN und wiederholt ausschließlich die dauerhafte Retry- oder Terminalmarkierung bei vorübergehenden SQLite-Fehlern. Nach dem Adapter- und Manager-Restart wurden die betroffenen Dispatches durch die bestehende Startup-Recovery erneut eingeplant und vollständig zugestellt. Loopback-/Public-Health, Queue, Supervisor und Dateideskriptorzahlen blieben anschließend stabil.

Verifizierte Reparatur vom 28. August 2026

Der frühere Stand übergab gpt-5.6-sol ohne erforderlichen Providerpräfix und ließ außerdem einen unerwartet beendeten Dispatch-Task unbemerkt. Der laufende HTTP-Dienst verschickte dadurch weiterhin Lesebestätigungen, obwohl kein Worker die Queue mehr abarbeitete. Der neue Stand normalisiert Codex-Modellnamen, erntet und protokolliert Taskfehler, setzt die Verarbeitung fort und ersetzt bei einem terminalen Fehler die Lesebestätigung durch einen sicheren Wiederholungshinweis.

Telegram zu Codex

Jeder Telegram-Nutzer darf den User-Bot privat anschreiben. Das bedeutet noch keine Freigabe: Vor jeder Verarbeitung entscheidet die private Inbound- Zugriffsregistry. In Gruppen werden ebenfalls nur berechtigte ausdrückliche Erwähnungen oder Antworten auf eine Bot-Nachricht aufgenommen. Erst eine angenommene Nachricht wird als Channel-Manager-Quelle und -Sitzung gespeichert. Neue Sitzungen verwenden als leichten Koordinator codex:gpt-5.6-luna mit Reasoning low. Der Providerpräfix ist Teil des Adaptervertrags; unqualifizierte Codex-Namen werden vor Thread-Create und Job-Start automatisch mit codex: ergänzt.

Begrüßungen, Wetter- und Zeitfragen, kurze Wissensfragen und notwendige Rückfragen beantwortet der Luna-Koordinator direkt im bestehenden Turn. Er erzeugt dafür keinen zweiten Codex-Auftrag. Erst ein konkreter, substanzieller Coding-, Recherche-, Datei- oder Serverauftrag darf an eine getrennte Codex-Sitzung übergeben werden. Eine Nachricht aus dem allgemein zugänglichen Telegram-Kanal ist dabei keine Autorisierung für externe, privilegierte oder destruktive Aktionen; diese erfordern eine bestätigte, berechtigte Auftraggeberrolle.

Der leichte Koordinator darf über das gescoptete MCP-Tool session_create einen getrennten Codex-Thread erzeugen und mit continue_message einen dauerhaften Folgeauftrag einstellen. model und reasoning_effort sind dabei frei aus dem dynamischen Adapterkatalog wählbar und werden nicht durch eine statische Channel-Manager-Allowlist begrenzt. Source- und Session-Scope können durch Toolargumente nicht erweitert werden.

Der Folgejob trägt zusätzlich access_scope=conversation|stage|server. Der Channel Manager prüft den aktuellen Registry-Eintrag bei Session-Erzeugung und erneut unmittelbar vor dem Dispatch. Conversation, Stage und Server zeigen auf getrennte 0700-Unterordner innerhalb des vom Adapter erlaubten Workspace. Ein späterer Ban oder Rechteentzug verhindert deshalb auch die nächste Ausführung einer schon vorhandenen Session.

Ausführungsrechte und Sandbox

Der frei erreichbare Conversation-Koordinator erhält features.shell_tool=false. Er kann Text, Vision und die freigegebenen Channel-Manager-MCP-Werkzeuge verwenden, aber keine lokale Shell starten.

Nur eine Session mit wirksamem access_scope=server setzt das interne Feld codex_disable_sandbox=true. Dafür müssen drei Grenzen gleichzeitig stimmen:

1. Die private Telegram-Registry erlaubt dem Absender Serverzugriff oder die Source ist der separat gebundene Owner.
2. Der Channel Manager bindet den Dispatch an den konfigurierten Server-Workspace und liest den Scope erneut aus dem Session-Datensatz.
3. Der ausschließlich auf Loopback erreichbare Responses-Adapter besitzt den ausdrücklichen Betreiber-Opt-in und übersetzt das Feld erst dann in default_permissions=:danger-full-access.

Fehlt der Adapter-Opt-in, endet ein solcher Metadatenwunsch fail-closed mit HTTP 403. Conversation kann den Modus nicht auswählen. Stage bleibt eine eigene Berechtigungs- und Workspace-Grenze und wird nicht stillschweigend zu Server-Vollzugriff hochgestuft. Auf dem aktuellen Host stehen weder Bubblewrap noch nutzbare unprivilegierte User-Namespaces bereit; deshalb läuft der ausdrücklich autorisierte Server-Scope bewusst ohne Sandbox. Ein Stage-Job, der lokale Shellausführung benötigt, kann auf diesem Host weiterhin an der fehlenden Sandbox-Laufzeit scheitern.

CHANNEL_MANAGER_CODEX_DEFAULT_MODEL=codex:gpt-5.6-luna
CHANNEL_MANAGER_CODEX_DEFAULT_REASONING_EFFORT=low

Vor einem Live-Smoke müssen codex-current --status und codex-current --preflight erfolgreich sein. Die Abschlussprüfung vom 28. August 2026 umfasste einen realen Telegram-Lauf, eine direkte synthetische Luna/low-Antwort und einen getrennten, authentifiziert gestarteten Folgejob mit bewusst gewähltem Modell und Reasoning. Die direkte Antwort war nach rund 7 Sekunden, der Folgejob nach rund 12 Sekunden abgeschlossen. Der zuvor in der Queue stehende Telegram-Lauf wurde nach Wiederanlauf des Workers in rund 32 Sekunden verarbeitet; die Lesebestätigung wurde durch die finale Antwort ersetzt. Account-, Peer- und Nachrichteninhalte gehören nicht in allgemeine Logs oder das Wiki.

Die Medienprüfung vom 29. August verwendete ausschließlich neu erzeugte synthetische Daten. Die Bildantwort war nach 38,8 Sekunden korrekt, die Dateiprüfkennung nach 31,8 Sekunden. Ein separater Server-Scope-Job legte per Shell eine zufällige Prüfdatei an; Inhalt und anschließende Entfernung wurden verifiziert. Keine reale Telegram-Nachricht und kein Nutzerupload wurde für diese Smokes wiederverwendet.

Bilder, Medien und Dateien

Telegram lädt angenommene Medien zuerst in den owner-only Medienbereich. Vor Allowlist-Entscheidung findet weiterhin kein Download statt. Pro Objekt gelten 25 MiB als Obergrenze.

Extrahierter Dokumenttext wird vor dem Adapter in den untrusted Prompt-Frame eingefügt und aus Transportmetadaten entfernt. Dateien werden dadurch nicht ausführbar in einen Codex-Workspace kopiert. Für Bilder erzeugt der Adapter ein privates Verzeichnis mit Präfix .codex-input-images-, Dateien mit Modus 0600 und Verzeichnis mit 0700; eine terminale Capability-Revoke entfernt genau dieses Jobverzeichnis.

Ein Thread aus der Zeit vor der Workspace-Trennung darf nur automatisch neu gebunden werden, wenn der Adapter exakt codex_thread_workspace_mismatch meldet und SQLite bestätigt, dass kein aktiver Providerjob die Session besitzt. Dann werden Threadbindung und Initialkontext atomar zurückgesetzt und der Dispatch einmal neu gestartet. Freie Adapterfehlermeldungen gelangen dabei weder in Audit noch Telegram.

Voice und Audio ab Schema 13

Der Audiovertrag erweitert den bestehenden Telethon-Adapter und seine source-geordnete SQLite-/Outbox-Pipeline. Es gibt keinen zweiten Bot, Poller oder Telegram-Sitzungspfad. Angenommen werden Telegram-voice und Telegram-audio; Video, Videonotes, andere Anhänge und externe URLs sind kein Transkriptionseingang. Die Owner-/Allowlist-Prüfung bleibt vor Telegram-Medienabruf, SQLite-Ingest, Account-Snapshot und LLM.

ACK, beide Zwischenstände und der erste Antwortchunk verwenden dieselbe gebundene Telegram-Reply. Längere finale Antworten senden regulär weitere korrelierte Chunks als neue Folgenachrichten, auch wenn der Edit des ersten Chunks erfolgreich war. Nur wenn der finale Edit des ersten Antwortchunks nach begrenzten kontrollierten Versuchen scheitert, darf dessen bestehender idempotenter Reply-Fallback eine neue Nachricht erzeugen. Sein Audit enthält weder Telegram-IDs noch Inhalt. Der Zwischenstatus besitzt keinen solchen Reply-Fallback: Ein nach erschöpftem Editbudget abgebrochenes Statusereignis wird inhaltsfrei auditiert und beendet weder Transkription noch LLM. Ein Duplicate oder Replay erzeugt kein zweites ACK und führt weder zu einem zweiten Transkriptions- noch zu einem zweiten LLM-Aufruf. Innerhalb einer Source bleibt die Reihenfolge strikt; unterschiedliche Sources dürfen begrenzt parallel arbeiten.

Validierung und Normalform

Nach dem ACK wird das korrelierte Telegram-Objekt in ein eindeutiges privates Arbeitsverzeichnis mit Mode 0700 geladen; einzelne Dateien besitzen höchstens 0600. Pfadausbruch und Symlinks werden abgewiesen. Telegram-MIME und Dateiname gelten nur als Behauptung: Zuerst müssen erlaubte Magic Bytes, danach die tatsächlichen Streams und die Dauer durch /usr/bin/ffprobe bestehen. Leere, beschädigte, zu große, zu lange oder videoenthaltende Dateien enden kontrolliert in derselben Reply.

/usr/bin/ffmpeg läuft ausschließlich mit einer festen Argumentliste ohne Shell-Interpolation und normalisiert die Audiospur zu MP3 mit libmp3lame, mono, 16 kHz und 48 kbit/s. Video, Untertitel, Datenstreams, Kapitel und Metadaten werden nicht übernommen. Original und Normalform sind jeweils auf 25 MiB begrenzt; die Standarddauer beträgt 1.200 Sekunden. Binarypfade, Timeout, Prozessausgabegrenze, Format, Codec, Kanäle, Rate und Bitrate sind zentral konfiguriert. Timeout und Abbruch beenden die Prozessgruppe. Arbeitsverzeichnis und Normalform werden bei Erfolg, Fehler, Timeout, Cancel und Shutdown entfernt. Für das angenommene Telegram-Original gilt weiterhin der bestehende geschützte 30-Tage-Medienvertrag.

OpenAI-Transkription und Konfiguration

Die MP3-Normalform wird als serverseitiger Multipart-Upload mit Bearer-Key über HTTPS an POST /v1/audio/transcriptions gesendet. Standardmodell ist gpt-transcribe; eine leere Spracheinstellung aktiviert Auto-Detect. Die config.json ist eine versionierte private Datei, liegt mit Mode 0600 unmittelbar im Channel-Manager-Projektroot und wird nicht inhaltlich im Wiki wiedergegeben.

Nur ConnectError, ConnectTimeout und PoolTimeout sowie tatsächlich empfangene HTTP 429, 500, 502, 503 und 504 werden begrenzt mit Backoff, Jitter und Retry-After wiederholt. Read-, Write-, Protokoll- und sonstige mehrdeutige Transportfehler, andere 5xx sowie der äußere Gesamttimeout werden nicht erneut übertragen. Ein nach einem Neustart mehrdeutiger transcription_inflight-Zustand schlägt ebenfalls fail-closed fehl. Permanente 4xx, insbesondere 401 und 403, werden nicht wiederholt. Die stabile, inhaltsfreie Requestkennung dient der Korrelation und dem lokalen Replay-Schutz, ist aber keine zugesicherte Provider-Idempotenz. HTTP-Status, Content-Type, JSON-Schema und ein nicht nur aus Whitespace bestehender Transkripttext sind zwingend. Providerrohantwort, Authorization, Audio und vollständiges Transkript gehören nicht in allgemeine Logs. Das validierte Transkript wird ausschließlich als normale, nicht vertrauenswürdige Nutzernachricht in den bestehenden LLM-Pfad gegeben und nie als System- oder Developeranweisung interpoliert.

Als historischer Rollout-Snapshot wurde der Audiovertrag am 29. August 2026 auf Stand 0dad5c31fde5, damals Release 0dad5c31fde5, Version 0.4.0 und Schema 13, verifiziert. Text- und Bildbetrieb wurden dabei gemeinsam mit einem synthetischen Direct-Ingress bis zur finalen Codex-Antwort geprüft. Der Voice-/Audio-Vertrag ist in Forgejo-main 9327a6e18fc8, Version 0.4.2 und Schema 13, unverändert enthalten.

Restart, Fehler und Rollback-Gate

SQLite führt den Audioworkflow dauerhaft durch pending, transcription_inflight, transcribed und anschließend completed oder failed. Source, Telegram-Update, Medienobjekt, Dispatch, Reply und eine stabile inhalts- und identitätsfreie Provider-Requestkennung bleiben gemeinsam gebunden. Ein Neustart setzt eindeutig noch nicht gestartete lokale Arbeit fort. Ein nach begonnenem Providerupload mehrdeutiger Zustand wird dagegen fail-closed terminalisiert, statt möglicherweise einen zweiten kostenpflichtigen Request auszulösen; der Nutzer kann die Audionachricht bewusst erneut senden.

Download-, Validierungs-, Konvertierungs-, Transkriptions-, LLM- und Telegram-Editfehler bleiben getrennte sichere Fehlerklassen. Sie geben keine Pfade, IDs, Providerantworten oder Credentials an Telegram weiter, räumen temporäre Daten auf, terminalisieren oder verwenden nur den dokumentierten Retry und blockieren nachfolgende Nachrichten nicht.

Vor einem Rückweg auf einen Commit oder Tag mit Code vor Schema 13 muss der aktuelle Stand mit rollback-check belegen, dass weder ein nichtterminaler Audioworkflow noch ein offenes Audio-Statusereignis vorhanden ist. Bei einem positiven Count bleibt der Rollback gesperrt. Der Rückweg ersetzt weder Datenbank noch Telegram-Sitzung, Registries, Medien oder andere private Zustände.

Allowlist, Pending und Banned-Liste

Die im Alltag oft „Whitelist“ genannte Liste heißt im technischen Vertrag allowlist. Sie ist nicht mit der separaten Empfängerregistry für proaktive Notices zu verwechseln.

Neue Absender erhalten nur den automatischen Hinweis, dass ihre Anfrage an den Betreiber gegangen ist und bis zur Freigabe keine KI aktiviert wird. Die Owner-Nachricht nennt die opake Kennung und – ausschließlich im privaten Telegram-Dialog – die dort verfügbare Identitätsinformation. Nachrichtentext des neuen Absenders wird nicht in die Freigabeaufforderung kopiert.

Der Owner kann Luna sinngemäß anweisen:

Erlaube TG-XXXXXXXX; Stage nein; Server nein; Profil: ...
Sperre TG-XXXXXXXX; Grund: ...
Aktualisiere TG-XXXXXXXX; Stage ja; Server nein; Profil: ...

Nur eine serverseitig als Owner authentifizierte Telegram-Source sieht die MCP-Werkzeuge telegram_access_list und telegram_access_update. Ein Allowlist-Nutzer kann diese Werkzeuge weder entdecken noch aufrufen und kann seine Rechte daher nicht durch eine eigene Chatnachricht erhöhen. Das Listenwerkzeug liefert keine Telefonnummer oder Telegram-ID, sondern nur opake Kennungen, Profile, Zustände und Berechtigungen.

Das Markdown-Profil beschreibt Gesprächspräferenzen, typische Anliegen und andere vom Owner freigegebene Hinweise. Es wird bei einer neuen Codex-Session als erste autoritative Information vor Provider-History und aktueller Nachricht injiziert. Der Bot darf den Nutzer im Gespräch besser kennenlernen; eine persistente Profil- oder Rechteänderung bleibt trotzdem eine ausdrückliche Owner-Aktion.

Zum verifizierten Deployment war der Owner korrekt separat gebunden; die zusätzlichen Buckets allowlist, pending und banned waren leer. Das Wiki dokumentiert künftig höchstens solche aggregierten Zustände. Identitäten, Nummern, Profile und Sperrgründe bleiben ausschließlich in der privaten Datei.

Zugriff und Routen

• GET /healthz liefert lokal 200; Adminrouten antworten ohne Bearer auch auf Loopback mit 401.
• codex-master.webdevmedia.de/channel-manager ist als Uberspace-Web-Backend auf Port 8769 veröffentlicht; der Präfix wird am Backend entfernt. Der Health-Smoke liefert öffentlich und auf Loopback 200.
• Der Channel-Responses-Adapter ist ausschließlich auf Loopback gebunden.
• Die proaktive Empfängerregistry und die davon getrennte Inbound-Zugriffsregistry liegen in einem 0700-Konfigurationsbaum und sind jeweils 0600. Nur die Inbound-Registry enthält Owner, Allowlist, Pending und Banned; keine ihrer Identitäten wird über HTTP oder Wiki veröffentlicht.

Diagnose: Lesebestätigung ohne finale Antwort

Ein grüner /healthz-Status belegt nur, dass der HTTP-Prozess antwortet. Er belegt nicht, dass ein source-geordneter Dispatch noch Fortschritt macht. Bei einer Lesebestätigung ohne finale Antwort sind deshalb folgende Metadaten in dieser Reihenfolge zu prüfen:

1. Status von Inbound-Nachricht, Dispatch, Run, finalem Outbound-Ereignis und Telegram-Zustellung ohne Nachrichtentext oder Identität korrelieren.
2. Prüfen, ob der älteste Dispatch derselben Source running oder queued hält; eine zweite Nachricht wartet bestimmungsgemäß hinter der ersten.
3. Zeitstempel neuer dispatch.worker_task_failed-Ereignisse und die Fehlerklasse im Supervisor-Log prüfen, ohne Prompt oder Providerrohantwort zu übernehmen.
4. Offene Dateideskriptoren beider Prozesse und besonders SQLite-Handles beobachten; ein stabiler Health-Endpunkt schließt Erschöpfung nicht aus.
5. Erst den Loopback-Adapter aktualisieren und prüfen, danach den Channel Manager kontrolliert neu starten. Die Startup-Recovery darf eindeutig wiederholbare running-Dispatches neu einplanen.
6. Abschluss nur melden, wenn Dispatch und Run terminal, die Antwort zugestellt, keine Source mehr blockiert und keine neue Worker-Task-Ausnahme aufgetreten ist.

Eine historische reserved-Idempotenzzeile kann nach einem vor dem Providerstart abgebrochenen Versuch als forensischer Beleg bestehen bleiben. Sie ist nicht automatisch ein aktiver Job und darf nicht ohne Prüfung aus der Datenbank gelöscht werden. Entscheidend sind der aktuelle Idempotenzschlüssel, der Providerjob-Status und die source-geordnete Queue.

Verifizierter Release-Versand

Die Benachrichtigung für Content-Release 8f68bfdac1eb erreichte am 28. August den terminalen Zustand notified. Ein Replay mit derselben releasebezogenen Idempotency lieferte dieselbe Interaction zurück und erzeugte keinen Doppelversand. Zielnummer und Peer wurden zuvor live auf Gleichheit geprüft, aber weder ausgegeben noch im Wiki gespeichert. Registry-Änderung, privates 0600-Backup, check-config, kontrollierter Neustart und Health-Smoke waren erfolgreich.

Bind-Adresse ist keine Freigabe

Der Listener des Channel Managers bindet an alle Interfaces und besitzt eine explizite Web-Backend-Zuordnung. Präfixrouting und Bearer-Prüfung bleiben deshalb beide Teil des Sicherheitsmodells. Vor jeder Änderung sind Socket, Backendliste, unauthentifizierter 401-Smoke sowie öffentlicher und lokaler Health erneut zu prüfen.

Zwei bewusst getrennte Telegram-Pfade

Der Support-Sanitizer entfernt unter anderem Schlüsselblöcke, Authorization- und Cookie-Werte, bekannte Token-/JWT-Muster, URL-Userinfo sowie sensible Credentialfelder. Er begrenzt Text auf 4.000 Bytes und verwirft Bild-URLs mit Userinfo oder sensiblen Queryparametern. Audits enthalten nur logische IDs, Bytezahl, Hash und Redaktionszahl, nie den Rohtext.

Wichtige Sanitizer-Grenze

Dieser Vertrag gilt für die Legacy-Supportwerkzeuge, nicht automatisch für Channel-Manager-Notices: notice.prompt wird dort unverändert transportiert. Automatisierte Benachrichtigungen müssen deshalb vor dem lokalen API-Aufruf eine strikte Feld-Allowlist und einen fail-closed Secret-Check anwenden. Keine Rohantwort, Telefonnummer oder Peer-ID darf in Argumenten, allgemeinen Logs oder Idempotency-Schlüsseln stehen.

Technische Vorfälle und Zustellungs-Idempotenz

LIVE: technischer Incident- und Dedupe-Vertrag

Channel Manager läuft aus dem festen Git-Projektroot auf Forgejo-main- Commit 9327a6e18fc8 als Version 0.4.2 auf Schema 13; der Channel-Responses-Adapter läuft aus Commit 193f0c8e1bf4 und Release 193f0c8e1bf4 als Version 0.3.1; die Stage-Plugins laufen aus Commit 3f9585569a00. Vollsuite, Migrations-, Incident-, Dedupe- und SQLite-Lifecycle-Tests waren grün. Der Channel Manager wird bei Bedarf kontrolliert im selben Git-Root auf einen verifizierten Commit oder Tag zurückgesetzt; für den Adapter bleibt der Vorgänger 9e666cdfd8fd als unveränderter Release-Rollbackstand erhalten. Der Legacy-Supportdienst blieb gestoppt.

Eine strukturierte technische Notice verwendet den Untervertrag technical_incident. Der Channel Manager rendert den Diagnoseblock selbst aus einer festen Feld-Allowlist. Er übernimmt keinen freien Fehlerdump. Der Block enthält mindestens incident_id, correlation_id, bekannte Central-/Stage- Request- oder Jobkennung, Tool, Cursor, Versuch, Phase, Reason-Code und Dispatchzustand. Nicht verfügbare Werte erscheinen ausdrücklich als unknown. Nur eine fehlende incident_id darf der Channel Manager deterministisch aus der kanonischen Korrelation ableiten; Request-, Stage- und Jobkennungen werden niemals erfunden.

Die stabile logische Zustellungsidentität ist der incident_id zusammen mit dem bewussten Zustandsübergang. Der Channel Manager dedupliziert diese Interaction persistent auch nach einem Prozessneustart. Ein echter Folgezustand – etwa eine neue Fehlerphase oder die Wiederherstellung – darf genau eine weitere Interaction erzeugen. Wechselnde JSON-RPC-IDs, Zeitstempel oder Textformatierung sind ausdrücklich keine neue Zustellungsidentität. Die nachgelagerte User-Bot-Outbox besitzt davon getrennte Retry- und Wiederherstellungsregeln; die logische Deduplizierung allein beseitigt kein Ambiguitätsfenster des Telegram-Transports.

Das owner-only Entscheidungs-Audit speichert ausschließlich die erlaubten Diagnosefelder, den Übergang, die Dedupe-Entscheidung und Zeit. Der spätere Interaction-Zustand wird getrennt geführt. Nachrichtentext, Peer-/Chatkennung, Telefonnummer, Telegram-Rohantwort, Prompt, Ergebnis und Credentials werden nicht in den Entscheidungsdatensatz kopiert. Die bestehende generische Notice bleibt aus Kompatibilitätsgründen erhalten; technische Automatisierung soll den strukturierten Untervertrag verwenden. Technische Interactions verwenden dafür einen eigenen Outbox-Ereignistyp. Ein auf Version 0.2 zurückgesetzter Worker kennt diesen Typ nicht und bleibt vor der Telegram-Sendung fail-closed, statt den Vorfall als generische Notice ohne Diagnoseblock auszuliefern. Vor einem Rollback muss das Gate deshalb entweder das Fehlen wartender technischer Ereignisse bestätigen oder deren spätere Verarbeitung durch die Vorwärtsversion ausdrücklich erhalten.

Der Stage-Legacypfad telegram__send_to_support verwendet denselben strukturierten Diagnoseblock und reserviert incident_id plus transition dauerhaft, bevor er den lokalen Bridge-Dienst aufruft. Ein erfolgreicher Erstversuch und beliebig viele identische Retries ergeben dadurch genau eine Bridge-Sendung; ein neuer Zustandsübergang darf eine weitere erzeugen. Abweichende Diagnosedaten unter derselben Zustellungsidentität enden als Konflikt.

Grenze des Telegram-Transports

Telegram bietet für diesen Stage-Legacy-Supportpfad keine transaktionale Idempotenzschnittstelle. Zwischen dem externen Send und dem lokalen Erfolgsmarker bleibt deshalb ein unvermeidbares Absturzfenster. Der sichere Vertrag ist dort at most once: Ein unklarer reservierter Versuch wird als unknown_after_timeout sichtbar und nicht automatisch erneut gesendet. Erst eine manuelle Prüfung oder ein bewusst neuer transition darf den Zustand fortschreiben. So wird ein mögliches Ausbleiben nicht durch eine doppelte technische Meldung kaschiert.

Sicherer Benachrichtigungsablauf

1. Zielzuordnung ausschließlich privat und in memory prüfen; im Wiki bleibt nur ein pseudonymes Registry-Alias wie wiki_release_notice.
2. Falls ein neuer Peer nötig ist, nur die numerische Peer-ID unter dem Alias in der 0600-Registry speichern; keine Telefonnummer persistieren.
3. Für den API-Aufruf nur die minimale Interaction-Berechtigung verwenden und den direkten Token aus seiner 0600-Datei in memory lesen.
4. POST /v1/interactions mit kind=notice, stabiler releasebezogener Idempotency und ausschließlich Release-ID, Umfang, QA-Status und offenen Punkten senden.
5. Als Ergebnis nur Interaction-ID, Zustand und Duplicate-Flag auswerten; niemals Telegram-Rohantwort oder Nachrichtentext allgemein protokollieren.
6. Bei Fehlern das Wiki-Deployment nicht zurückrollen. Channel Manager und User-Session getrennt diagnostizieren; den Support-Bot nicht als Ersatz verwenden.

Zustand, Rotation und Retention

Mehrere Supervisorlogdateien waren trotz geschützter Elternverzeichnisse selbst 0644. Das ist als Berechtigungsdrift dokumentiert; Log-Inhalte wurden nicht gelesen.

Deployment und Rollback

deploy/uberspace/update.sh arbeitet ausschließlich im festen Projektroot und verlangt zu Beginn einen eindeutig gestoppten Dienst. Der Updater prüft den sauberen Git-Root und die Root-config.json, führt git pull --ff-only, den gesperrten Python-3.13-Sync und den Installcheck aus und endet bewusst mit weiterhin gestopptem Dienst. Erst der kontrollierte Betriebsablauf startet den Dienst explizit und prüft Supervisor, lokalen und öffentlichen Health sowie das unautorisierte 401-Gate. Der alte Channel-Manager-Releasebaum und seine Pfadumschaltung sind entfernt; es gibt keinen current-Symlink.

Ein Rollback ist ein kontrollierter Git-Rückweg auf einen zuvor verifizierten Commit oder Tag im selben festen Root. Anschließend werden die venv aus der gesperrten Spezifikation neu aufgebaut, check-config, Supervisor, Loopback-/Public-Health und das 401-Gate geprüft. Schema 13 wird bei einem Code-Rollback nie downgraded oder durch eine alte Sicherung ersetzt; vor einem Rückweg auf älteren Code muss außerdem das vorstehende Audio-rollback-check grün sein. Persistente private Daten – SQLite, Telegram-Session, Registries, Medien und Logs – liegen außerhalb des Projekts und werden nicht zurückgesetzt. Der Adapter behält seinen getrennten releasebasierten Rückweg; bei einem gemeinsamen Rückweg gilt weiterhin die umgekehrte Deployreihenfolge.

Stabiler Projektroot geschützt

/home/wpmcp/codex-projects/channel-manager ist 0700; seine versionierten Dateien und die Python-3.13-venv sind privat. Die versionierte private config.json liegt direkt im Root und ist 0600. Supervisor startet unmittelbar .venv/bin/channel-manager aus diesem Root. Der Adapter-Release 193f0c8e1bf4 und sein Vorgänger 9e666cdfd8fd bleiben in ihren privaten, unveränderlichen Release- und Laufzeitverzeichnissen.

Die Legacy Support Bridge ist ein sauberer Forgejo-main-Checkout auf f0a21277498f, Version 1.0.0. Sie bleibt gestoppt, solange kein ausdrücklich autorisierter Supportvorgang vorliegt.

Bekannte Unbekannte

• Die Identität hinter den beiden privaten Registry-Aliasen bleibt absichtlich außerhalb des öffentlichen Wiki; aus Alias oder Peerbindung darf keine Person abgeleitet werden.
• Eine Forgejo-Pluginquelle allein belegt weder WordPress-Installation noch Aktivierung; die Site-Inventur behandelt dies getrennt.
• Aktive Telegram-Inhalte, Kontakte, Dialoge und Supportnachrichten wurden nicht gelesen und bleiben außerhalb dieses Inventars.

Weiterführend: Betrieb & Support, Serverinventar, Session-Inventar und URLs und Dienste.

WordPress-Agentenlabor: geprüfter Owner-Rückkanal (2026-09-08)

Das separate Labor auf wp-lab.christian-igel.tech (wpmcp00) verwendet die bestehende Channel-Manager-Interaction-API auf wpmcp. Der vorhandene Macgaiver-Benutzeraccount bleibt aktiv; der optionale Companion-Bot wird nicht benötigt und ist nicht aktiviert. Der bestehende direkte Owner-Empfänger wurde privat mit Registry, tatsächlicher Telegram-Identität und WordPress-Konto abgeglichen. Saved Messages gehört zum Dienstkonto und darf deshalb nicht automatisch an den WordPress-Owner gebunden werden. Empfängerkennungen, Telefonnummern, Profile und Bearer bleiben außerhalb des Wiki.

CM-Commit c3e1d41fcd61 ergänzt die Owner-DM-Antworten vor dem normalen Codex-Auftragseingang. 44 Fixturetests bestehen. Ausschließlich das vorhandene geprüfte Owner-Profil erhielt die beiden Interactions-Rechte. Vor der kontrollierten Aktivierung gab es keine aktiven Dispatches/Runs und keine wartende Outbox; anschließend waren Healthcheck und Telegram-Verbindung erfolgreich. Andere Empfänger, Dienste, Accountauswahl und Queues bleiben erhalten.

Die WP-Bridge speichert eine Nutzer-/Frage-/Interactionbindung, verwendet die bestehende Outbox und hält Annahme, Zustellung sowie Antwortübernahme getrennt. Der vorhandene reine CM-Direct-Bearer wurde per SSH in eine private 0600-Referenz auf wpmcp00 übertragen. Botdaten oder Telegram-Sessions wurden nicht kopiert. Der CM besitzt derzeit keinen Interactions-Only-Bearer; die WP-Bridge selbst beschränkt sich auf ihre festen Interaction-Routen und verifizierten Empfänger.

WordPress bleibt Quelle für Fragen und Antworten. Der begrenzte 60s-Poll verarbeitet nur bestehende Interactions; keine automatische neue Frage und kein Codex-Dispatch entstehen daraus. Spätere Telegram-Antworten überschreiben keine neuere WordPress- Antwort, und ein Timeout gilt nie als Zustimmung. Die erste tatsächliche Labor-Rückfrage wurde als zugestellt bestätigt. Der reale Nutzerantwort-Eingang bleibt bis zu seinem Nachweis separat offen.

Quellverträge: docs/wp-agent-lab-owner-replies.md im Channel-Manager-Repository und docs/telegram.md im Laborprojekt. Private Vorzustände und Aktivierungsbelege liegen im jeweiligen Betreiberbereich; Rollback stellt den gesicherten vorherigen Dienststand und ausschließlich die geänderten Interactions-Rechte wieder her.

Direkte Freitextantworten auf eine zugestellte Laborfrage werden anhand der tatsächlich gespeicherten Telegram-Zustellungskennung, des Empfängers und des exakten Owner-Privatchats zugeordnet. Der ergänzende Stand c3e1d41fcd61 ist mit 44 Fixtureprüfungen geprüft und veröffentlicht. Bearbeitete oder weitergeleitete Nachrichten und ein abweichender Antwortcode erzeugen dabei keine Agentenaufträge. Eine normale Antwort auf eine andere Nachricht behält ihren bisherigen Verarbeitungsweg.

Vollständige Commitkennungen

Die im Text gekürzten Git-Kennungen lauten vollständig:

d02537ca41c04d8fa2fcca26c74f59f04ddfc690
0dad5c31fde51aaa74bad40acd81086906d9c27d
9327a6e18fc8022dc966dca176eed7dfc6fa36fc
193f0c8e1bf41e0b62ad2ee4996174f170be2192
c3e1d41fcd618d2887b63ea5f764def75ca79ab6