Studios in MotionProjektkartei

Website-Aufträge und Website-Agent

Aktiv

Änderungs-Pipeline vom Ticket zur Website: Ticket-Schleuse, Planungslauf mit Freigabe per Mail, Website-Agent, Repo-Registry, Onboarding aus der Zentrale, Dispatcher

Bereich
Zentrale
Start
19.07.2026
Zuletzt
03.10.2026
Am Zug
niemand
Nächster Schritt, niemand

Ersten echten Auftrag mit Kundenanhang und das erste neue Kursplan-Ticket beobachten; Stufe B (Vollautomatik) erst nach Alltagserfahrung

Zentrale (Betrieb › Website-Freigabe, Website-Änderungen)Ticketsystem (KI-Analyse › Website-Automatik)

Worum es geht

Änderungswünsche von Kunden sollen vom Ticket bis zur Vorschau auf der Website laufen, mit möglichst wenig Handarbeit und genau einer Entscheidung je Stufe. Der Ablauf: Mail oder Ticket, Triage erkennt den Wunsch, die Ticket-Schleuse legt einen Auftrag (website.aenderung) an, ein Planungslauf des Website-Agenten (nur lesen) schreibt den Plan, René gibt ihn frei, der Agent setzt um (Zweig devel, dann preprod), eine Vorschau-Mail mit „Live schalten“ geht raus. Dazu gehören die Repo-Registry (welches Repo gehört zu welchem Kunden), der Dispatcher (Job zu Agenten-Sitzung) und das Onboarding neuer Kunden aus der Zentrale (setup:sim).

Stand

  • Dispatcher (seit 19.07., Hub): Ein Job gleich eine Hermes-Sitzung gleich ein geprüftes Artefakt. Global an, Tool-Allowlist, Tageslimit, Retries. Das Pro-Kunde-Opt-in-Gate ist seit 27.07. entfernt.
  • Website-Agent (Hermes-Container, nur intern): website.aenderung mit Pre-Flight (devel und preprod müssen existieren, devel darf nicht hinter preprod liegen), Artefaktkette devel → preprod → CI → Preview-Probe. Nach einem Commit nie ein Retry.
  • Planungslauf mit Freigabe per Mail seit 02.09. (Hub v0.248.0): Plan-JSON, Mail an service@ mit Freigabe-Seite, Umsetzung mit Plan als Vorgabe, zweite Mail „Umgesetzt, Vorschau bereit“ mit „Live schalten“ (preprod nach main) oder „Nachbesserung“. Seit 22.09. Übersicht der Website-Änderungen in der Zentrale.
  • Ticket-Schleuse: Stufe A seit 20.08. (Schalter website_repos.automatik aus, freigabe, voll; „voll“ verhält sich bewusst wie „freigabe“). Seit 03.10. (Hub v0.357.0) geht die Schleuse direkt in den Planungslauf ohne „Plan erstellen“. Auftragsgrundlage ist der ganze Ticketverlauf (v0.281.x), weitergeleitete Kundenmails bleiben im Verlauf (v0.358.0, 03.10.). Zuordnung zur Website ist immer nur ein Vorschlag mit Kandidatenliste (v0.313.0), interne Tickets folgen der genannten Kundenwebsite (v0.339.x).
  • Kundenmaterial: Anhänge und Links aus dem Ticket gehen an den Agenten (v0.315.0, 17.09.), Chat-Dateien aus dem Assistenten ebenfalls (v0.337.0, 22.09.). Kursplan-Tickets laufen als eigener Auftragstyp kursplan.aenderung (v0.338.0, 22.09.).
  • Repo-Registry: Tabelle website_repos ist die einzige Pflegestelle (Betrieb › Website-Freigabe); mappings.repo in der Akte ist ein Spiegel. Stand 24.08. 15 Einträge, später ergänzt um uniqbag (id 18) und rae-geisler-franke (id 19).
  • Automatik-Stand 20.08.: freigabe bei balance, energy, fuchspack, impuls, mytime, osteoathletik, proaktiv, tschann; voll bei simgym und sim2026; aus bei browns, ploen und secdata (Stand heute prüfen).
  • Onboarding: „setup:sim“ im Template v1 zieht den Freeda-Ersatz aus der Zentrale (Website-Setup- und Design-Karte, Export website-setup); Pilot FitMax, Template v1 komplett frei von Freeda. Neue Kunden aus bestehenden Repos: Standard-Prozess seit 31.07. (Plön, OsteoAthletik, Balance Kassel).
  • Knopf „Vorschau aktualisieren“ in der Kundenakte (v0.222.0) bringt den Stand der Zentrale nach preprod, main nie.

Offen

  • ich Ersten echten Auftrag mit Kundenanhang beobachten (Positivfall der Abruf-Route aus v0.315.0 im Echtbetrieb noch nicht gesehen). Wiedervorlage bei „PROBLEM im Plan“ ist nicht gebaut.
  • ich Erstes echtes neues Kursplan-Ticket beobachten (Bildqualität, Dauer, ob die KI die Wünsche richtig trennt). Antwortentwurf an den Kunden nach der Übernahme ist nicht gebaut.
  • René Go für Verbesserungen der Agenten-Qualität (Befund 12.09., Impuls Team-Karten): V1 Gestaltungsregeln im Playbook, V2 Pflicht-Sichtcheck mit Screenshots bei 390 und 1440 px, V3 Planformat mit „So sieht es danach aus“ in Laiensprache, V4 Artefaktcheck für Layout-Aufträge.
  • René Go für Hinweise bei fehlenden Anhängen („anbei“ ohne Anhang) und bei „AW:“ mit erkannter Weiterleitung (Vorschläge b und c vom 24.09.). Regel an alle: Kundenmails immer weiterleiten.
  • René Fuchspack-Automatik von „aus“ auf „freigabe“ umlegen, sobald der Kundenfreigabe-Merge durch ist (war für 23.08. geplant, Stand prüfen).
  • René rae-geisler-franke (Repo geisler-website-2024): Das Bot-Konto hatte am 05.09. keinen Zugriff (Branch-Anlage 403). Dem Konto „SIM Agent“ oder dem Team „SimTools Agents“ das Repo freigeben (Stand prüfen).
  • ich Stufe B (Vollautomatik für eine Allowlist) erst nach Alltagserfahrung; Automatik-Badge in der Kundenakte ist ein Nice-to-have.
  • ich Onboarding Stufe 2: Design-Showroom hinter dem Zentrale-Login (nie auf einer Kundendomain), setup:sim in den Repo-Erstellungs-Flow einhängen, Template v2 und Bestandsrepos nachziehen. Nachlese der Kandidaten aus dem Repo-Onboarding vom 02.08. (kanzlei-gudjons, frank-best-coaching, norbert-kox, bellyformer, optik-wiethold, grobe-fitness-hagen, faceforce2026, Golfclub-Gruppe): Stand je Kunde prüfen.
  • ich Prüfregel nach jeder Repo-Anlage: git ls-files src/data/studio-config.json muss 1 liefern (die GitHub-Vorlage entfernt den MASTER-ONLY-Block der .gitignore nicht, setup:sim entfernt ihn seit 09.09. selbst).
  • ich Fremder roter Test rechercheCore.test.ts („berichtParsen: Ampel folgt den Befunden“) auf main, nicht Teil der Pipeline.
  • Alle Freigabe-PINs stehen auf 1234 (René: „anfangs überall, später je Kunde“). Für uniqbag.de fehlt ein Deploy-Workflow und eine bekannte Preview-Domain, Aufträge laufen dort nur bis devel und preprod.

Entscheidungen und Regeln

  • 2026-10-03: Neue Auftragsquellen gehen direkt in den Planungslauf. René will bei jedem Weg genau EINE Entscheidung je Stufe, nie einen Klick, der nur „mach weiter“ bedeutet.
  • 2026-09-16: Die Website-Zuordnung im Ticket ist ein Vorschlag, nie eine Festlegung. Eine Firma kann mehrere Websites haben. Eigene Domains zählen nicht als Textbeleg.
  • 2026-09-11: Grundlage eines Auftrags ist der ganze Ticketverlauf, die jüngste Kundennachricht ist der aktuelle Stand. Bereits als erledigt gemeldete Wünsche werden nicht neu gebaut.
  • 2026-09-02: Vor jeder Umsetzung gibt es einen Plan, den René per Mail freigibt. Nur Kursplan-Wünsche laufen nicht über den Agenten (Kursplan liegt in der Zentrale).
  • 2026-08-19: Das Repo wird nur in der Registry gepflegt. Die Zuordnung Kunde zu Repo steht dort.
  • 2026-08-09: Der Design-Switcher darf nie auf einer Kundendomain erscheinen, auch nicht auf preprod. Der Showroom gehört hinter den Zentrale-Login.
  • 2026-07-28: Version 1 des Templates ist Single-Master, Version 2 Multi-Standort-Master, keine Fusion. Der Chat bleibt das einzige Gate: eine Bestätigung je Auftrag, danach läuft alles bis zur Vorschau durch.
  • 2026-07-27: Das Pro-Kunde-Opt-in für den Dispatcher entfällt, alle aktiven Kunden laufen mit.
  • Betrieb: Vor jedem Hub-Rollout prüfen, ob Aufträge running oder queued sind, ein Rollout bricht laufende Agentenläufe ab. Coolify-Umgebungsvariablen nie per SQL setzen. Im Agent-Container immer docker exec -u 10000. Rollout nur mit cd /root/sim-ops/deploy && ./rollout.sh.

Verlauf

  1. Hub v0.357.0 (3ac31c8): Schleuse plant direkt, Renés Rückmeldung zu den Aufträgen #542 bis #544 (Impuls). Hub v0.358.0 (90d2c41): Weiterleitungen bleiben im Verlauf (Anlass Ticket #808, Auftrag #544); Lehre daraus: vor jedem Rollout die Warteschlange prüfen.
  2. Hub v0.343.1 (03352ef) Auftrags-Dialog im Ticketsystem (ac846d5), v0.345.0 (e2c50be) GitHub-Token je Repo-Owner für Repos außerhalb der Org (uniqbag.com).
  3. Hub v0.339.0 und v0.339.1 interne Tickets (Anlass Ticket #760, Auftrag #423 auf #425 ersetzt).
  4. Hub v0.338.0 (657aa40) Kursplan-Auftrag aus Tickets (Anlass Job #413 New Circles); v0.337.0 (8b2056b) Chat-Dateien gehen an den Agenten; Website-Änderungen-Übersicht in der Zentrale (67cc5e1).
  5. Hub v0.315.0 (0337c70) Kundenanhänge und Bildquellen für den Agenten (Anlass Balance #707).
  6. Hub v0.313.0 Kandidatenliste statt stiller Vorauswahl (Anlass Ticket #736, SecData mit zwei Websites); Assistent-Werkzeuge im Ticketsystem (404dcb8).
  7. Befund Impuls Team-Karten (#392 und #393): Agent liefert schlechter als die direkte Sitzung; Verbesserungen V1 bis V4 vorgeschlagen.
  8. Hub v0.281.0 und v0.281.1 (20ff364) ganzer Verlauf als Auftragsgrundlage (Anlass Ticket #702, Auftrag #389 auf #390 ersetzt).
  9. Registry-Einträge uniqbag (id 18) und rae-geisler-franke (id 19).
  10. Hub v0.248.0 (80a5ff3) Planungslauf mit Freigabe per Mail, v0.249.0 Ticket-Knopf mit Website-Automatik.
  11. Hub v0.217.0 (ace741a) Stufe A, erster echter E2E-Lauf (Ticket #620, Auftrag #293, SimGym, in 7,5 Minuten bis preprod); v0.218.0 (caeeb6b) Denylist-Politik, Vorabgleich, Originalmail im Auftrag nach dem Balance-Fall #619 und #292.
  12. Hub v0.213.4 Registry spiegelt in mappings.repo.
  13. Hub v0.135.0 Onboarding-Ablösung Stufe 1 (setup:sim), Template v1 Freeda-frei.
  14. Build-Blocker bei harten Prebuild-Abbrüchen behoben (Prüfbau-Schalter SIM_BUILD_PRUEFLAUF, Hub v0.117.0).
  15. Hub v0.52.0 (15970f7) W2-Schattenmodus (Ticketsystem 93ca66d); Repo-Onboarding Pilot OsteoAthletik.
  16. W0 (Hub v0.48.0, Aufräumen, PIN-Hashes, Kill-Switch), W1 (Hub v0.49.0, Website-Agent als Job-Typ), erster Echtkundenlauf MyTime (Job #215, Commit 4a4550a), Chat-Screenshots Stufe 1 (v0.50.0), Job-Fortschritt im Chat (v0.51.0).
  17. Hub v0.42.2 Opt-in-Gate des Dispatchers entfernt.
  18. Dispatcher gebaut (Hub v0.9.0), erste Job-Typen content.ausspielung, ads.konzept und seo.bericht.

Wo liegt was

  • Hub-Code (sim-ops): hub/src/dispatcher.ts, dispatcherToolPolicyCore.ts (Denylist im Wegwerf-Klon), websitePlan.ts und websitePlanCore.ts, websiteDeploy.ts und websiteDeployCore.ts (Webhook preprod-approval, Merge, Redeploy), ticketschatten.ts, ticketschleuseCore.ts, tickets.ts, ticketsCore.ts (Verlauf, Kandidaten, weiterleitungZerlegen), ticketAnhaengeCore.ts, kursplanAuftrag.ts und kursplanAuftragCore.ts, vorschau.ts und vorschauCore.ts. Doku im Repo: docs/website-plan-freigabe-2026-09.md. Vault: 50-Strategien/Gesamtsystem/Website-Aenderungs-Pipeline.md.
  • Zentrale: Betrieb › Website-Freigabe (Tabelle website_repos, Spalte Automatik, Repo-Registry), Startseiten-Karte für Ticket-Aufträge, Website-Änderungen-Übersicht, Kundenakte › Design › „Vorschau aktualisieren“.
  • Schalter und Env-Namen (Hub): HUB_DISPATCH_ENABLED, HUB_DISPATCH_TYPES, HUB_DISPATCH_DAILY_LIMIT, HUB_DISPATCH_MAX_RETRIES, HUB_DISPATCH_TOOL_ALLOWLIST, HUB_DISPATCH_WEBSITE_AUTOAPPROVE, HUB_WEBSITE_DEPLOY_ENABLED, HUB_WEBSITE_PLANUNG, HUB_WEBSITE_PLAN_MAIL_AN, HUB_WEBSITE_GITHUB_TOKENS_JE_OWNER, HUB_AGENT_WEBSITE_BASE, HUB_AGENT_WEBSITE_WS, HUB_AGENT_WEBSITE_USER, HUB_AGENT_WEBSITE_PASSWORD, HUB_TICKETS_*.
  • Website-Agent: Container hermes-etuq372r7sv1wirc6ixk47h2, Volume etuq372r7sv1wirc6ixk47h2_sim-webste, Klone unter customer-sites/<repo-ohne-praefix>; Logs logs/agent.log im Volume. Git auf den Klonen vom Host nur mit temporärem safe.directory.
  • Ticketsystem-Seite: backend/src/routes/websiteAuftrag.js, backend/src/services/hubBridge.js, Frontend TicketDetailView (Block „Website-Automatik“, Auftrags-Dialog).
  • Onboarding: Template studiowebsite-template-v1 mit scripts/import_sim_api.mjs (npm run setup:sim), Export GET /api/content/customers/:key/website-setup, Kundenakte-Karten „Website-Setup“ und „Design & Darstellung“. Wiki: 40-Projekte/Website-Onboarding setup-sim. PINs: /root/transfer/keys/website-pins-2026-09-05.txt (nur Pfad).