Tag 7 - Von der Anfrage zum Ticket, automatisiert

End-to-End-Automatisierung: Ideenformular und Admin Help machen aus Eingaben klare Tickets, mit menschlicher Prüfung vor der Umsetzung.

Einleitung

Tag 7 ist ein Sondereintrag: Er dokumentiert Automatisierung, die eine Lücke schließt, die die früheren Tage offen ließen. Jemand reichte eine Idee oder Störung ein; ein Entwickler las Rohtext, formulierte daraus ein GitHub-Issue und erst dann begann die Implementierung. Diese Übergabe war der Engpass.

Am 4. Juni 2026 haben wir die vollständige Schleife in zwei Kanälen verdrahtet: öffentliches Feedback auf km0digital.com (Produktion) und internes Admin Help auf einem Laravel-E-Commerce-Staging-Stack. Gleiches Modell: Queue, Autoissue-Entwurf, menschliches Label, Autoagents-Pickup.

Zusammenfassung

Vorher und nachher

Anfrage: lose Nachricht oder E-Mail → strukturiertes JSON in der Queue.
Verständnis: Dev interpretiert Rohtext → cursor-agent schreibt strukturierten .md-Entwurf.
Ticket: manuelles gh issue create → automatisiertes Issue mit sauberem Markdown-Body.
Menschliche Kontrolle: implizit → Label waiting for human validation.
Implementierung: Dev weist zu → Mensch entfernt Label → Autoagents (001 / FEAT) übernehmen das Issue.

Der Entwickler muss die Roheinreichung nicht mehr öffnen und das Ticket von Grund auf schreiben. Das System stellt in die Queue, entwirft und veröffentlicht in Sekunden auf GitHub. Ein Mensch validiert oder korrigiert durch Entfernen des Labels; danach kann die Agent-Pipeline implementieren.

Architektur

Zwei Eingänge, ein Muster

EINGANG
  km0-web:     POST /hooks/ideas        (öffentlich /ideas/)
  ecommerce:   POST /api/v1/admin/help  (auth /admin/help)
        ↓
  JSON-Queue (Spool / Storage)
        ↓
  Sofortiger Trigger (systemd path / Queue-Job)
        ↓
  cursor-agent (--yolo) + Autoissue-Prompt → Entwurf .md
        ↓
  gh issue create --body-file + Label waiting for human validation
        ↓
  Mensch prüft → entfernt Label → Autoagents 001 → FEAT → Code

Warum es passt

Ein praktisches Muster für kleine Teams

Es ging uns nicht um Automatisierung um ihrer selbst willen. Wir wollten, dass sinnvolle Anfragen nicht in Chats, E-Mails oder im Kopf von jemandem verschwinden. Das System macht aus jeder Eingabe in Sekunden ein lesbares Ticket mit Kontext und Umfang.

Schnelligkeit: wer schreibt, wartet nicht, bis jemand Zeit findet, die Störung sauber zu formulieren.
Qualität: jeder Entwurf folgt derselben Struktur (was passiert, für wen, was erwartet wird).
Kontrolle: nichts geht in die Entwicklung, bevor eine Person im Team zustimmt.
Wiederverwendbar: dasselbe Muster gilt für öffentliches Feedback und interne Anfragen.

Für KM0 passt das besonders: Wir hören von nicht-technischen Menschen und wollen deren Input mit derselben Sorgfalt behandeln wie den Bericht eines Shop-Administrators.

Wo es gilt

Zwei Eingänge, ein Weg

KM0-Nutzer: das Formular Ideen auf km0digital.com. Produktvorschläge, Website-Verbesserungen oder Lücken, die jemand beim Cloud-Nutzung bemerkt.
Wer ein internes Projekt betreibt: der Admin-Help-Bildschirm eines Online-Shops in Staging. Wenn jemand im Team einen Fehler sieht oder eine Änderung braucht und sie nachvollziehbar festhalten will.

In beiden Fällen ist der Weg derselbe: Formular → Warteschlange → formuliertes Ticket → menschliche Prüfung → Umsetzung. Nur wer schreibt und wo, ändert sich, nicht die Logik.

Beispiele

So sieht es in der Praxis aus

Stell dir vor, jemand sendet über Ideen: „Ich hätte gern einen Button zum Teilen von Blog-Beiträgen.“ In etwa fünfzehn Sekunden entsteht ein überschriebenes, geordnetes Ticket: was die Person will, in welcher Sprache sie schrieb, welchen Teil der Site es betrifft. Es ist als wartet auf menschliche Prüfung markiert.

Jemand im Team liest es. Steht der Text, entfernt er die Markierung und das Ticket geht in die automatische Umsetzungs-Warteschlange. Braucht es Feinschliff („nur mobil“, „WhatsApp-Icon“), wird das Ticket vor der Freigabe bearbeitet. Ohne die Originalnachricht von Hand neu zu tippen.

Ein anderer Fall: Ein Shop-Admin in Staging meldet über Admin Help, dass ein Produktfilter nicht richtig speichert. Gleiche Mechanik: klares Ticket, Prüfschritt, dann Entwicklung. Ziel ist, dass niemand raten muss, was der Absender meinte.

Menschen

Was Automatisierung tut (und was nicht)

Die Maschine formuliert und ordnet ein. Eine Person entscheidet. Entwicklungs-Agenten greifen keine Tickets auf, solange sie noch als ungeprüft markiert sind. So bauen wir nicht blind auf vagen Nachrichten oder Spam auf.

Für jemanden, der eine Idee sendet, ist der Nutzen einfach: einmal in normaler Sprache schreiben, und das Team bekommt etwas Umsetzbares. Für den Betrieb heißt es: nicht mehr dauernd Übersetzer zwischen „WhatsApp-Nachricht“ und „gut geschriebenem Ticket“ sein.

Ergebnis

Was Tag 7 erreicht hat

Der manuelle Schritt zwischen „jemand bittet um etwas“ und „es gibt ein Ticket, das umgesetzt werden kann“ entfällt in Produktion (öffentliche KM0-Ideen) und in der E-Commerce-Staging-Umgebung (Admin Help).

Heute funktioniert der ganze Kreislauf: Anfrage, formuliertes Ticket, menschliche Freigabe und agentenunterstützte Umsetzung. Das war das fehlende Stück, um Zuhören in der Community und durchdachte Lieferung zu verbinden.

Serie

Tage 1–6

Frühere Einträge decken den Stack ab (OpenCloud, Dex, LDAP, native Clients, Tutorials, Vision). Tag 7 ergänzt die Feedback-Schleife: probiere das Ideenformular oder lies Tag 6 für Geräte-Onboarding. Fragen: Kontakt.