Entscheidungen in Festag

Warum Entscheidungen ein eigener Bereich sind

Die meisten Projekte scheitern nicht an der Arbeit, sondern an der Kommunikation rund um die Arbeit. Eine Frage des Devs landet in WhatsApp, die Antwort drei Tage später per E-Mail, der Kontext ist verschollen, niemand weiß mehr, was eigentlich entschieden wurde.

Festag löst das, indem Entscheidungen nicht in Chats oder Mails stattfinden, sondern in einem eigenen, strukturierten Objekt. Eine Entscheidung hat einen Titel, eine Frage, mögliche Antworten, eine zuständige Rolle, eine Wirkung und einen Audit-Trail. Sie ist kein Nachrichten-Stream, sondern ein Vertrag im Kleinen.

Tagro übersetzt zwischen den beiden Seiten. Was der Dev technisch fragt, wird für den Auftraggeber ruhig und verständlich. Was der Auftraggeber entscheidet, kommt beim Dev als klare Anweisung mit allen relevanten technischen Implikationen an. Niemand muss die Sprache der anderen Seite lernen.

Drei Sichten, eine Wahrheit

Eine Entscheidung existiert als ein einziges Objekt im System. Die drei Beteiligten sehen sie in jeweils ihrer eigenen Projektion — ohne dass die Information dabei wandert, kopiert oder verfälscht wird.

Client Board

Ruhig und entscheidungsorientiert. Titel und Zusammenfassung in normaler Sprache, zwei bis vier Optionen, eine primäre Aktion. Keine technischen Details, keine Confidence-Prozente, keine Dev-Begriffe.

Tagro Backend

Notar und Übersetzer. Rahmt die Entscheidung, formuliert beide Sichten, routet an die richtige Rolle, propagiert das Ergebnis. Selbst nie Entscheidungsträger, außer es ist explizit erlaubt.

Dev Panel

Technisch und vollständig. Verlinkte Tasks, Begründung, Tagro-Vorschlag mit Reasoning, mögliche Verfeinerung vor dem Versand an den Client.

Wer eine Entscheidung erzeugt

Am Projektstart kommen Entscheidungen fast ausschließlich vom Dev. Er weiß, welche technischen oder organisatorischen Fragen beantwortet werden müssen, bevor er weiterarbeiten kann. Tagro hat in dieser Phase noch keinen ausreichenden Kontext, um eigenständig zu erkennen, was offen ist — sie ist hier reine Übersetzerin und Routerin.

Sobald das Projekt läuft, kommen weitere Quellen dazu. Statusberichte, Blocker, Risikoindikatoren und Scope-Vergleiche füttern Tagro mit genug Signal, um Entscheidungsbedarf eigenständig zu erkennen. Auch dann bleibt der Dev der dominante Ursprung — Tagro ergänzt, sie ersetzt nicht.

• Vage Tasks ohne klare Akzeptanzkriterien — Tagro fragt nach, statt zu raten.
• Blocker, deren Auflösung eine externe Wahl voraussetzt.
• Explizite Dev-Anfrage über die Aktion „Entscheidung anfragen" an einem Task.
• Scope-Drift, erkannt aus dem Vergleich aktueller Tasks mit dem ursprünglichen Auftrag.
• Überschrittene Risikoschwellen, etwa drohende Deadlines oder Budgetabweichungen.
• Statusbericht-Signale wie offene Fragen oder neue Anforderungen.

Was Tagro für jede Entscheidung liefert

Bevor eine Entscheidung dem Auftraggeber gezeigt wird, prüft Tagro, ob sie vollständig gerahmt ist. Ohne die folgenden Elemente bleibt sie im Entwurf und erreicht das Client Board nicht.

1. Ein ruhiger Titel in normaler Sprache, höchstens ein Satz.
2. Eine Zusammenfassung in zwei bis vier Sätzen: was zu entscheiden ist und warum jetzt.
3. Zwischen zwei und vier Optionen, formuliert in der Sprache des Auftraggebers.
4. Pro Option die strukturierte Auswirkung: zeitlicher Effekt, Kosten, Risiko, Scope.
5. Eine Tagro-Empfehlung in einer einzigen Zeile — oder die ehrliche Aussage, dass keine Empfehlung möglich ist.

Wie der Auftraggeber antwortet

Nicht jede Entscheidung sieht gleich aus. Manche brauchen ein einfaches Ja oder Nein, andere eine Auswahl, andere einen kurzen Text. Tagro erkennt den passenden Antworttyp aus dem Kontext und schlägt ihn dem Dev vor, der die Frage stellt.

Ja / Nein

Binäre Entscheidung mit zwei klaren Konsequenzen. Beispiel: Soll diese Website ein Impressum erhalten?

Auswahl

Zwei bis vier vorbereitete Optionen mit Auswirkung. Beispiel: Welche Hero-Variante soll umgesetzt werden?

Mehrfachauswahl

Mehrere Optionen können gemeinsam gelten. Beispiel: Welche Sprachen soll die Plattform unterstützen?

Freier Text

Eine eigene Eingabe ist sinnvoller als jede vorbereitete Option. Beispiel: Wie soll der Footer-Claim lauten?

Tagro entscheiden lassen

Neben den vier Antworttypen gibt es eine fünfte Möglichkeit, die jede Entscheidung still im Hintergrund mitführt: Der Auftraggeber kann Tagro bitten, für ihn zu entscheiden.

Das ist kein Verzicht auf Kontrolle, sondern das Gegenteil. Der Auftraggeber entscheidet pro Entscheidung neu, wem er die Wahl überlässt. Tagro lernt mit jeder Delegation die Präferenzen des Projekts kennen — Tonalität, Risikoneigung, Designgeschmack — und kann zukünftige Vorschläge präziser rahmen.

Jede delegierte Entscheidung wird mit einer kurzen Begründung dokumentiert. Der Auftraggeber sieht das Ergebnis sofort und kann es innerhalb von 48 Stunden überschreiben. Audit-Trail bleibt vollständig.

Wenn die Entscheidung gefallen ist

Eine Entscheidung im Status „decided" ist erst der zweite Schritt von dreien. Anschließend übersetzt Tagro die Wahl in konkrete Wirkung im Projekt — atomar, idempotent, mit vollständigem Audit-Trail.

decision.state = decided
   |
   v
[apply, transaktional]
   |
   +-- blockierte Tasks: wechseln zurück in ihren vorherigen Status
   +-- betroffene Tasks: Tagro hängt eine Notiz an, ggf. neue Akzeptanzkriterien
   +-- Statusbericht: enthält die Entscheidung in der naechsten Generation
   +-- Progress: gewichtete Neuberechnung, Decision-Drag faellt weg
   +-- Sync-Bus: Events fan-out an Client Board und Dev Panel
   |
   v
decision.state = applied

Erst der Übergang zu „applied" bedeutet, dass die Entscheidung wirklich im Projekt angekommen ist. Schlägt eine Teiloperation fehl, rollt das System zurück und ein erneuter Versuch ist möglich. Der Auftraggeber bekommt davon nichts mit — er sieht nur, dass seine Entscheidung Wirkung gezeigt hat.

Was Tagro niemals tut

• Tagro erfindet keine Fragen, die der Dev nicht gestellt hat. Halluzination im Trust Layer wäre fatal.
• Tagro entscheidet nicht eigenständig, außer der Auftraggeber hat die Entscheidung explizit an sie delegiert oder es handelt sich um einen ausdrücklich erlaubten Trivial-Default.
• Tagro schätzt keine Auswirkungen, die sie nicht belegen kann. Unbekanntes wird als unbekannt markiert, nicht geraten.
• Tagro umgeht niemals die Autoritätsregeln. Wer entscheiden darf, ist im Datenmodell fixiert — Rolle, nicht Person.
• Tagro entscheidet nie rechtliche, finanzielle oder vertragliche Fragen. Diese sind explizit ausgeschlossen.

Kontrolle ohne Überwachung. Klarheit ohne Bürokratie. Geschwindigkeit ohne Chaos.

Wo das im Produkt sichtbar wird

Auf dem Client Board liegt eine Entscheidung als ruhige Karte im Bereich „Entscheidungen". Maximal drei Karten sind primär sichtbar, weiteres rutscht in einen sekundären Bereich. Eine Karte zeigt Titel, Zusammenfassung, Optionen und eine einzelne Empfehlung. Daneben gibt es die Möglichkeit, die Entscheidung zu diskutieren — eine Rückfrage, die wieder bei Tagro landet und in eine geschärfte Version mündet.

Im Dev Panel taucht jede aktive Entscheidung am Kopf des Projekt-Workspaces auf. Blockierte Tasks zeigen direkt, welche Entscheidung sie aufhält. Mit der Aktion „Entscheidung anfragen" an einem Task lässt sich eine neue Frage anstoßen — Tagro übernimmt das Rahmen und Übersetzen.

Hinter beidem läuft Tagro als stille Schicht. Sie hat kein eigenes UI, sie ist die Schreibweise des Systems. Sichtbar wird sie nur im Audit-Log und in der ruhigen Tatsache, dass beide Seiten verstanden haben, was die andere meint.