Tagro AI · 6 Min.

Vom Dev-Update zur ruhigen Client-Lage

Wie der tägliche 16:00-Loop funktioniert, was Tagro aus Dev-Updates baut und warum Reporting bei Festag operative Steuerung ist, nicht Doku.

Festag trennt interne Arbeitsrealität von client-fähiger Lage. Tagro sitzt dazwischen: sie liest Arbeitssignale, prüft Relevanz und formuliert daraus verständliche Statusberichte.

16:00 Berlin
   |
   v
Vercel Cron -> /api/cron/tagro-daily-dev-prompt
   |
   v
dev_daily_prompts (eine Karte pro Developer + Projekt + Tag)
   |
   v
"Wie weit bist du heute mit X gekommen?"
   |
   v
Dev antwortet in einem Satz auf /dev
   |
   v
/api/dev/daily-update
   |
   v
developer_updates -> status_reports
intern             client-safe

Warum diese Logik wichtig ist

Der Kunde will nicht jeden Commit, jede interne Rückfrage und jede technische Nuance lesen. Er will wissen, ob das Projekt ruhig läuft, ob etwas blockiert ist, ob eine Entscheidung gebraucht wird und was als Nächstes passiert.

Genau dafür sitzt Tagro zwischen Ausführung und Client-Sicht. Die Arbeitsrealität bleibt vollständig dokumentiert, aber die Client-Kommunikation wird bewusst klar, kurz und professionell.

Der tägliche Status ist kein Chat

Das Developer-Update ist bewusst klein: ein Satz, ein Fortschritt, ein Blocker oder ein Hinweis. Tagro sammelt diese Signale über 24 Stunden und macht daraus eine Lage, die im Dashboard, in Statusberichten und optional als Audio verfügbar ist.

Was wurde seit dem letzten Bericht tatsächlich bewegt?
Welche Risiken oder Blocker brauchen Aufmerksamkeit?
Welche Entscheidung muss vom Client oder Projektverantwortlichen kommen?
Welche neue Aufgabe sollte aus dem Bericht entstehen?
Welche Formulierung ist client-safe und nicht unnötig technisch?

Datenmodell als Trust-Layer

Statusberichte dürfen nicht aus dünner Luft entstehen. Der Bericht muss auf echten Developer-Updates, Aufgaben, Entscheidungen und optionalen Nachweisen basieren. Deshalb trennt Festag interne Signale von sichtbaren Client-Berichten.

developer_updates
  project_id
  developer_id
  update_text
  created_at
       |
       v
tagro_events
  event_type = status_translation
  confidence_score
  source_window = 24h
       |
       v
status_reports
  audience = client
  visible = true
  text_transcript
  audio_url optional
       |
       v
tasks / risks / decisions
nur wenn wirklich Handlung entsteht

Client-Sicht bleibt ruhig

Tagro ist kein Überwachungswerkzeug. Es ist eine Übersetzungsschicht. Der Developer arbeitet intern, Tagro prüft und verdichtet, und der Client bekommt nur die klare Lage: Fortschritt, Risiko, Entscheidung, nächster Schritt.

Dev Panel                 Tagro Layer                  Client Panel
---------                 -----------                  ------------
Rohes Update       ->     prüfen + übersetzen   ->     klare Lage
Evidence           ->     Plausibilität         ->     Statusbericht
Blocker            ->     Risiko einordnen      ->     Entscheidung
interne Details    ->     filtern               ->     ruhige Sprache
Task-Fortschritt   ->     zusammenfassen        ->     nächster Schritt

Wenn aus Bericht Arbeit wird

Ein Statusbericht ist nicht das Ende der Arbeit. Wenn Tagro einen offenen Punkt erkennt, kann daraus eine Aufgabe, ein Risiko, eine Entscheidung oder ein Projektbriefing entstehen. So wird Reporting nicht nur Dokumentation, sondern operative Steuerung.

Dev gibt tägliches Update ab.
Tagro baut daraus eine verständliche Lage.
Client liest oder hört den Bericht.
Risiken und Entscheidungen werden zu Aktionspunkten.
Aus offenen Punkten können neue Tasks entstehen.

Zielbild: Der Client öffnet Festag, hört ein 30- bis 60-sekündiges Tagro-Briefing und versteht sofort, was passiert ist, was blockiert ist und worauf er achten muss.