feat(agent): show task kinds in log and dashboard #44

Merged

frank merged 3 commits from agent/issue-43-agent-aufgabenart-in-log-und-dashboard-a into main 2026-07-12 17:20:31 +02:00

Conversation 31 Commits 3 Files changed 12 +243 -27

frank commented 2026-07-12 17:16:26 +02:00

Owner

Copy link

Summary

• Stabile Task-Kind-IDs (coding, fix_build, resolve_conflicts, mention) mit menschenlesbaren Labels
• Mapping aus Dispatch-Pfaden: RunIssue, RunCIFix, RunConflictFix, RunMentionReply
• Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (--no-tui)
• Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals)

Test plan

• go test ./internal/agent/...
• forge agent watch --tui — Running/Queue zeigen Kind-Labels
• PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log
• --no-tui — Logzeilen mit [Fixing Build] o. ä.

---

Änderungen (3 Commits)

1. taskkind.go — Task-Kind-Modell, Labels, Mapping von prFixKind
2. Status & Pipeline — TaskKind auf IssueEntry und OrchestrationEvent; TrackRunningWithKind / SetRunTaskKind; Pipeline setzt Kind pro Job-Typ
3. UI — TUI zeigt [Agent Coding] etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via logJob()
4. Activity-Drawer — standardmäßig expanded, ~height/3 (min. 10 Zeilen ab 30 Zeilen Terminalhöhe)
5. Wiki — Abschnitt „Task Kinds“ in docs/wiki/Agent-Watch.md

Closes #43

## Summary - Stabile Task-Kind-IDs (`coding`, `fix_build`, `resolve_conflicts`, `mention`) mit menschenlesbaren Labels - Mapping aus Dispatch-Pfaden: `RunIssue`, `RunCIFix`, `RunConflictFix`, `RunMentionReply` - Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (`--no-tui`) - Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals) ## Test plan - [x] `go test ./internal/agent/...` - [ ] `forge agent watch --tui` — Running/Queue zeigen Kind-Labels - [ ] PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log - [ ] `--no-tui` — Logzeilen mit `[Fixing Build]` o. ä. --- ### Änderungen (3 Commits) 1. **`taskkind.go`** — Task-Kind-Modell, Labels, Mapping von `prFixKind` 2. **Status & Pipeline** — `TaskKind` auf `IssueEntry` und `OrchestrationEvent`; `TrackRunningWithKind` / `SetRunTaskKind`; Pipeline setzt Kind pro Job-Typ 3. **UI** — TUI zeigt `[Agent Coding]` etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via `logJob()` 4. **Activity-Drawer** — standardmäßig expanded, ~`height/3` (min. 10 Zeilen ab 30 Zeilen Terminalhöhe) 5. **Wiki** — Abschnitt „Task Kinds“ in `docs/wiki/Agent-Watch.md` Closes #43

frank commented 2026-07-12 17:16:26 +02:00

Author

Owner

Copy link

🚧 WIP pull request opened — linked to issue #43. Agent is working…

🚧 **WIP pull request opened** — linked to issue #43. Agent is working…

frank commented 2026-07-12 17:16:32 +02:00

Author

Owner

Copy link

💭 Agent progress

Ich implementiere Issue #43. Die Agent-Aufgabenart soll im Activity-Log und Dashboard angezeigt werden.

Ich durchsuche die Codebasis nach relevanten Dateien für Orchestrierung, Dashboard und Activity-Log. Zusätzlich plane ich die Wiki-Dokumentation zu aktualisieren, die Log-Höhe auf ein Drittel des Terminals zu begrenzen und die Änderungen schrittweise zu committen.
Ich verschaffe mir zuerst einen Überblick über die relevanten Stellen für Task-Kinds, Activity-Log und Dashboard.

💭 **Agent progress** Ich implementiere Issue #43. Die Agent-Aufgabenart soll im Activity-Log und Dashboard angezeigt werden. Ich durchsuche die Codebasis nach relevanten Dateien für Orchestrierung, Dashboard und Activity-Log. Zusätzlich plane ich die Wiki-Dokumentation zu aktualisieren, die Log-Höhe auf ein Drittel des Terminals zu begrenzen und die Änderungen schrittweise zu committen. Ich verschaffe mir zuerst einen Überblick über die relevanten Stellen für Task-Kinds, Activity-Log und Dashboard.

frank commented 2026-07-12 17:16:34 +02:00

Author

Owner

Copy link

💭 Agent progress

Searching for OrchestrationEvent, prFixKind, and related structures.

💭 **Agent progress** Searching for OrchestrationEvent, prFixKind, and related structures.

frank commented 2026-07-12 17:16:36 +02:00

Author

Owner

Copy link

💭 Agent progress

Ich lese eventlog.go, pipeline.go, tui.go, prfix.go, watcher.go und die Wiki-Dokumentation, um zu verstehen, wie Aufgabenarten aktuell im Log und Dashboard angezeigt werden.

💭 **Agent progress** Ich lese eventlog.go, pipeline.go, tui.go, prfix.go, watcher.go und die Wiki-Dokumentation, um zu verstehen, wie Aufgabenarten aktuell im Log und Dashboard angezeigt werden.

frank commented 2026-07-12 17:16:38 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Pipeline, der Watcher und die UI-Dateien werden gelesen, um zu verstehen, wie Aufgabenarten durch das System geleitet werden.

Auch tui_test wird geprüft, insbesondere Drawer-Erweiterung, Standard-Logs und Plain-Logs.

💭 **Agent progress** Die Pipeline, der Watcher und die UI-Dateien werden gelesen, um zu verstehen, wie Aufgabenarten durch das System geleitet werden. Auch tui_test wird geprüft, insbesondere Drawer-Erweiterung, Standard-Logs und Plain-Logs.

frank commented 2026-07-12 17:16:40 +02:00

Author

Owner

Copy link

💭 Agent progress

Ich prüfe den aktuellen Branch-Zustand per Git-Diff und Status, um zu sehen, was bereits umgesetzt ist und was noch fehlt.

💭 **Agent progress** Ich prüfe den aktuellen Branch-Zustand per Git-Diff und Status, um zu sehen, was bereits umgesetzt ist und was noch fehlt.

frank commented 2026-07-12 17:16:45 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Änderungen für Issue #43 müssen komplett neu umgesetzt werden. Ich beginne mit der Planung.

Ich plane die Umsetzung in zehn Schritten. Dazu gehören eine neue TaskKind-Komponente mit festen IDs und Labels, Erweiterung der Datenstrukturen IssueEntry und OrchestrationEvent, Anpassung der Pipeline-Methoden sowie Aktualisierung des Formatierungs- und Log-Code für Konsolen, Dashboard und Web-Oberfläche.

Der Activity-Drawer soll standardmäßig erweitert und auf ein Drittel der Höhe gesetzt werden. Die Dokumentation im Wiki fehlt noch. Nun suche ich nach den Stellen für Plain-Logs und TrackRunning-Aufrufe.

💭 **Agent progress** Die Änderungen für Issue #43 müssen komplett neu umgesetzt werden. Ich beginne mit der Planung. Ich plane die Umsetzung in zehn Schritten. Dazu gehören eine neue TaskKind-Komponente mit festen IDs und Labels, Erweiterung der Datenstrukturen IssueEntry und OrchestrationEvent, Anpassung der Pipeline-Methoden sowie Aktualisierung des Formatierungs- und Log-Code für Konsolen, Dashboard und Web-Oberfläche. Der Activity-Drawer soll standardmäßig erweitert und auf ein Drittel der Höhe gesetzt werden. Die Dokumentation im Wiki fehlt noch. Nun suche ich nach den Stellen für Plain-Logs und TrackRunning-Aufrufe.

frank commented 2026-07-12 17:16:54 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Implementierung beginnt mit einer neuen Datei taskkind.go. Sie definiert den Typ TaskKind, die zugehörigen Konstanten und die Label-Zuordnung für die Anzeige in Log und Dashboard.

Das Feld TaskKind wird zu IssueEntry und OrchestrationEvent hinzugefügt. TrackRunning übernimmt die Zuweisung beim Jobstart. Die Pipeline setzt den passenden Wert pro Phase. RunIssue erhält TaskKindCoding, RunCIFix erhält TaskKindFixBuild.

Zusätzlich werden TaskKindResolveConflicts für RunConflictFix und TaskKindMention für RunMentionReply zugewiesen. Der RunIssue-Ablauf behält TaskKindCoding auch während Babysitting bei. Geplant ist die Setzung des TaskKinds auch für Einträge in der Warteschlange.

Die konkreten Konstanten werden als String-Untertyp mit den Werten coding, fix_build, resolve_conflicts und mention definiert. Eine Hilfsfunktion wandelt prFixKind in TaskKind um. TrackRunning wird nun direkt auf WatchStatus umgestellt.

Ein neuer TrackRunningKind-Methoden-Overload schreibt das TaskKind direkt in den Eintrag. runPRFixQueued liest das Kind über TaskKindFromPRFix aus. Die Pipeline speichert das TaskKind als Feld und setzt es in den Run*-Methoden am Start.

Eine Pipeline-Hilfsmethode setTaskKind schreibt das TaskKind in den Status. logOrchestration liest es aus dem Pipeline-Feld. Das Formatierungs-Template zeigt das Label vor der Agenten-Meldung an. Im TUI-Dashboard erscheint das Kind-Label neben der Issue-Nummer. Plain-Logs im Watcher erhalten ein TaskKind-Prefix beim Jobstart.

Eine neue Hilfsmethode logJobf soll die konsistente Kennzeichnung in Logs vereinfachen. Das Drawer-Panel im TUI-Dashboard wird standardmäßig erweitert. Die Web-Oberfläche erhält eine Spalte für das TaskKind sowie ein Prefix in der Aktivitätszeile. Auch BeginRunFor und runStream müssen geprüft werden, damit das TaskKind korrekt durchgereicht wird.

💭 **Agent progress** Die Implementierung beginnt mit einer neuen Datei `taskkind.go`. Sie definiert den Typ `TaskKind`, die zugehörigen Konstanten und die Label-Zuordnung für die Anzeige in Log und Dashboard. Das Feld `TaskKind` wird zu `IssueEntry` und `OrchestrationEvent` hinzugefügt. `TrackRunning` übernimmt die Zuweisung beim Jobstart. Die Pipeline setzt den passenden Wert pro Phase. `RunIssue` erhält `TaskKindCoding`, `RunCIFix` erhält `TaskKindFixBuild`. Zusätzlich werden `TaskKindResolveConflicts` für `RunConflictFix` und `TaskKindMention` für `RunMentionReply` zugewiesen. Der RunIssue-Ablauf behält `TaskKindCoding` auch während Babysitting bei. Geplant ist die Setzung des TaskKinds auch für Einträge in der Warteschlange. Die konkreten Konstanten werden als String-Untertyp mit den Werten `coding`, `fix_build`, `resolve_conflicts` und `mention` definiert. Eine Hilfsfunktion wandelt `prFixKind` in `TaskKind` um. `TrackRunning` wird nun direkt auf `WatchStatus` umgestellt. Ein neuer `TrackRunningKind`-Methoden-Overload schreibt das TaskKind direkt in den Eintrag. `runPRFixQueued` liest das Kind über `TaskKindFromPRFix` aus. Die Pipeline speichert das TaskKind als Feld und setzt es in den Run*-Methoden am Start. Eine Pipeline-Hilfsmethode `setTaskKind` schreibt das TaskKind in den Status. `logOrchestration` liest es aus dem Pipeline-Feld. Das Formatierungs-Template zeigt das Label vor der Agenten-Meldung an. Im TUI-Dashboard erscheint das Kind-Label neben der Issue-Nummer. Plain-Logs im Watcher erhalten ein TaskKind-Prefix beim Jobstart. Eine neue Hilfsmethode `logJobf` soll die konsistente Kennzeichnung in Logs vereinfachen. Das Drawer-Panel im TUI-Dashboard wird standardmäßig erweitert. Die Web-Oberfläche erhält eine Spalte für das TaskKind sowie ein Prefix in der Aktivitätszeile. Auch `BeginRunFor` und `runStream` müssen geprüft werden, damit das TaskKind korrekt durchgereicht wird.

frank commented 2026-07-12 17:16:56 +02:00

Author

Owner

Copy link

💭 Agent progress

Ich prüfe die Watcher-Logs und SetPollQueue, um die Task-Arten in den Queue-Einträgen zu ermitteln.

💭 **Agent progress** Ich prüfe die Watcher-Logs und SetPollQueue, um die Task-Arten in den Queue-Einträgen zu ermitteln.

frank commented 2026-07-12 17:17:06 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Implementierung wird schrittweise mit Commits umgesetzt. Der erste Schritt umfasst taskkind.go sowie die Kerntypen IssueEntry, OrchestrationEvent und deren Statusmethoden.

Der zweite Commit integriert Pipeline und Watcher. Der dritte zeigt die Aufgabenart in TUI und Web an und erweitert den Drawer. Der vierte ergänzt Wiki und Tests. Die Pipeline erhält ein taskKind-Feld. logOrchestration nutzt es. TrackRunning und SetPollQueue erhalten passende Erweiterungen. Ein neuer logJob-Helper ergänzt die Logs um die Aufgabenart.

Der logJob-Helper ergänzt die Logs um ein Label wie [Coding]. Start-Logs in runQueued und runPRFixQueued nutzen diesen Helper. LogOrchestration soll die Aufgabenart erhalten, ohne alle Aufrufstellen zu brechen. Dafür wird eine optionale Parameter-Erweiterung oder ein Strukturansatz bevorzugt.

Die Rückwärtskompatibilität wird durch einen neuen LogOrchestrationWithKind-Overload oder durch interne Zuordnung von p.taskKind gewahrt. SetPollQueue-Events bleiben unverändert. Die Pipeline übergibt p.taskKind an LogOrchestration.

LogOrchestration bleibt rückwärtskompatibel und delegiert intern an eine neue LogOrchestrationKind-Methode. Die Pipeline übergibt p.taskKind explizit. Im TUI werden Issue-Gruppen und Orchestration-Events um ein Badge mit der Aufgabenart ergänzt.

Die Web-UI-Methode renderActivity zeigt das Aufgabenart-Label an. SetPollQueue für PR-Fixes ergänzt die Aufgabenart in die Warteschlangeneinträge. Der Drawer im TUI-Modell ist standardmäßig erweitert. Die Tests werden um Label-Mapping, Event-Formatierung und Issue-Gruppen mit Aufgabenart erweitert. Das JSON-Tag könnte als task_kind angepasst werden.

Die JSON-Tags für TaskKind werden auf task_kind gesetzt. OrchestrationEvent erhält dasselbe Feld. Für RunIssue wird die Aufgabenart am Anfang gesetzt. Allerdings muss geprüft werden, ob TrackRunning bereits den Default-Wert setzt. Der Pfad über runOne oder Force-Run könnte anders sein.

💭 **Agent progress** Die Implementierung wird schrittweise mit Commits umgesetzt. Der erste Schritt umfasst taskkind.go sowie die Kerntypen IssueEntry, OrchestrationEvent und deren Statusmethoden. Der zweite Commit integriert Pipeline und Watcher. Der dritte zeigt die Aufgabenart in TUI und Web an und erweitert den Drawer. Der vierte ergänzt Wiki und Tests. Die Pipeline erhält ein `taskKind`-Feld. `logOrchestration` nutzt es. `TrackRunning` und `SetPollQueue` erhalten passende Erweiterungen. Ein neuer `logJob`-Helper ergänzt die Logs um die Aufgabenart. Der `logJob`-Helper ergänzt die Logs um ein Label wie `[Coding]`. Start-Logs in `runQueued` und `runPRFixQueued` nutzen diesen Helper. `LogOrchestration` soll die Aufgabenart erhalten, ohne alle Aufrufstellen zu brechen. Dafür wird eine optionale Parameter-Erweiterung oder ein Strukturansatz bevorzugt. Die Rückwärtskompatibilität wird durch einen neuen `LogOrchestrationWithKind`-Overload oder durch interne Zuordnung von `p.taskKind` gewahrt. `SetPollQueue`-Events bleiben unverändert. Die Pipeline übergibt `p.taskKind` an `LogOrchestration`. `LogOrchestration` bleibt rückwärtskompatibel und delegiert intern an eine neue `LogOrchestrationKind`-Methode. Die Pipeline übergibt `p.taskKind` explizit. Im TUI werden Issue-Gruppen und Orchestration-Events um ein Badge mit der Aufgabenart ergänzt. Die Web-UI-Methode `renderActivity` zeigt das Aufgabenart-Label an. `SetPollQueue` für PR-Fixes ergänzt die Aufgabenart in die Warteschlangeneinträge. Der Drawer im TUI-Modell ist standardmäßig erweitert. Die Tests werden um Label-Mapping, Event-Formatierung und Issue-Gruppen mit Aufgabenart erweitert. Das JSON-Tag könnte als `task_kind` angepasst werden. Die JSON-Tags für `TaskKind` werden auf `task_kind` gesetzt. `OrchestrationEvent` erhält dasselbe Feld. Für `RunIssue` wird die Aufgabenart am Anfang gesetzt. Allerdings muss geprüft werden, ob `TrackRunning` bereits den Default-Wert setzt. Der Pfad über `runOne` oder Force-Run könnte anders sein.

frank commented 2026-07-12 17:17:09 +02:00

Author

Owner

Copy link

💭 Agent progress

RunOne does not use TrackRunning because it runs as a one-shot job without watch status. Proceeding with implementation.

A new taskKind field will be added to the pipeline and status modules to track the active job type. SetRunTaskKind will update the active entry kind. Pipeline.logOrchestration will use this field. During CI fixes the kind will stay fix_build. Changes span taskkind.go, status.go, eventlog.go, and pipeline.go.

Changes will also touch watcher.go, status.go, tui.go, ui.go, the test files, and the wiki documentation. The TUI drawer will expand by default, and the web dashboard will show the task kind.

💭 **Agent progress** RunOne does not use TrackRunning because it runs as a one-shot job without watch status. Proceeding with implementation. A new `taskKind` field will be added to the pipeline and status modules to track the active job type. `SetRunTaskKind` will update the active entry kind. `Pipeline.logOrchestration` will use this field. During CI fixes the kind will stay `fix_build`. Changes span `taskkind.go`, `status.go`, `eventlog.go`, and `pipeline.go`. Changes will also touch `watcher.go`, `status.go`, `tui.go`, `ui.go`, the test files, and the wiki documentation. The TUI drawer will expand by default, and the web dashboard will show the task kind.

frank commented 2026-07-12 17:17:17 +02:00

Author

Owner

Copy link

💭 Agent progress

Der Drawer ist standardmäßig erweitert. Die TUI-Reproduktionstests nutzen das Modell ohne explizite Einstellung. Das könnte die Drawer-Höhe und Tests beeinflussen. Die Tests arbeiten aber mit mainHeight(), daher sollten sie weiterhin funktionieren.

Die Terminal-Größen-Tests bleiben auch mit erweitertem Drawer passend. Die Pipeline erhält ein taskKind-Feld. Jeder Run-Point setzt es zu Beginn. RunIssue wird als Coding, RunCIFix als FixBuild, RunConflictFix als ResolveConflicts und RunMentionReply als Mention markiert.

Die Pipeline schreibt den Aufgabentyp in den Watcher-Status. Der Watcher setzt ihn vor dem Start erneut per TrackRunningWithKind. TrackRunning nutzt nun diese Methode mit TaskKindCoding. SetPollQueue erhält den Typ für PR-Fix-Einträge.

Die Aufgabentyp-Anzeige wird in der TUI-Gruppenansicht und im Detail-View sichtbar. Ein neuer Helper für reine Logs ergänzt den Prefix. Der Watcher-LogJob wird ebenfalls angepasst.

Die logJob-Methode des Watchers fügt den Aufgabentyp-Präfix direkt in das Format-String ein. Die Meldungen bei runQueued und runPRFixQueued werden aktualisiert. Auch logOrchestration in der Pipeline erhält den TaskKind-Parameter.

Die LogOrchestration-Methode im Watcher erhält einen optionalen kind-Parameter am Ende. Die bestehende Signatur bleibt erhalten. Das ermöglicht den Aufgabentyp für interne Events wie blocked in status.go, während LogOrchestrationKind für Pipeline-Aufrufe verwendet wird.
Ich setze Task-Kind als zentrales Signal um und binde es in Status, Logs und UI ein.

💭 **Agent progress** Der Drawer ist standardmäßig erweitert. Die TUI-Reproduktionstests nutzen das Modell ohne explizite Einstellung. Das könnte die Drawer-Höhe und Tests beeinflussen. Die Tests arbeiten aber mit mainHeight(), daher sollten sie weiterhin funktionieren. Die Terminal-Größen-Tests bleiben auch mit erweitertem Drawer passend. Die Pipeline erhält ein `taskKind`-Feld. Jeder Run-Point setzt es zu Beginn. RunIssue wird als Coding, RunCIFix als FixBuild, RunConflictFix als ResolveConflicts und RunMentionReply als Mention markiert. Die Pipeline schreibt den Aufgabentyp in den Watcher-Status. Der Watcher setzt ihn vor dem Start erneut per TrackRunningWithKind. TrackRunning nutzt nun diese Methode mit TaskKindCoding. SetPollQueue erhält den Typ für PR-Fix-Einträge. Die Aufgabentyp-Anzeige wird in der TUI-Gruppenansicht und im Detail-View sichtbar. Ein neuer Helper für reine Logs ergänzt den Prefix. Der Watcher-LogJob wird ebenfalls angepasst. Die `logJob`-Methode des Watchers fügt den Aufgabentyp-Präfix direkt in das Format-String ein. Die Meldungen bei `runQueued` und `runPRFixQueued` werden aktualisiert. Auch `logOrchestration` in der Pipeline erhält den TaskKind-Parameter. Die `LogOrchestration`-Methode im Watcher erhält einen optionalen `kind`-Parameter am Ende. Die bestehende Signatur bleibt erhalten. Das ermöglicht den Aufgabentyp für interne Events wie `blocked` in `status.go`, während `LogOrchestrationKind` für Pipeline-Aufrufe verwendet wird. Ich setze Task-Kind als zentrales Signal um und binde es in Status, Logs und UI ein.

frank commented 2026-07-12 17:17:22 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Dateien status.go, eventlog.go, pipeline.go, watcher.go, tui.go und ui.go werden jetzt aktualisiert.

💭 **Agent progress** Die Dateien status.go, eventlog.go, pipeline.go, watcher.go, tui.go und ui.go werden jetzt aktualisiert.

frank commented 2026-07-12 17:17:30 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Datei pipeline.go wird um ein taskKind-Feld und zugehörige Methoden ergänzt.

💭 **Agent progress** Die Datei pipeline.go wird um ein taskKind-Feld und zugehörige Methoden ergänzt.

frank commented 2026-07-12 17:17:41 +02:00

Author

Owner

Copy link

💭 Agent progress

Die TUI wird angepasst. Der Drawer-Status wird standardmäßig auf erweitert gesetzt. Funktionen für Issue-Gruppen, Laufdetails und das UI werden aktualisiert.

Eventlog- und TUI-Tests werden ebenfalls aktualisiert.

💭 **Agent progress** Die TUI wird angepasst. Der Drawer-Status wird standardmäßig auf erweitert gesetzt. Funktionen für Issue-Gruppen, Laufdetails und das UI werden aktualisiert. Eventlog- und TUI-Tests werden ebenfalls aktualisiert.

frank commented 2026-07-12 17:17:50 +02:00

Author

Owner

Copy link

💭 Agent progress

Ich habe versehentlich die Funktion renderIssueRow entfernt und issueLink dupliziert.

Ich lese ui.go in der betroffenen Stelle und korrigiere die Fehler.

💭 **Agent progress** Ich habe versehentlich die Funktion `renderIssueRow` entfernt und `issueLink` dupliziert. Ich lese ui.go in der betroffenen Stelle und korrigiere die Fehler.

frank commented 2026-07-12 17:17:52 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Render-Funktion wird vollständig gelesen. Eine neue Funktion für Issue-Zeilen wird ergänzt. Die Abschnitte für aktuelle, laufende und wartende Aufgaben werden aktualisiert.

💭 **Agent progress** Die Render-Funktion wird vollständig gelesen. Eine neue Funktion für Issue-Zeilen wird ergänzt. Die Abschnitte für aktuelle, laufende und wartende Aufgaben werden aktualisiert.

frank commented 2026-07-12 17:17:54 +02:00

Author

Owner

Copy link

💭 Agent progress

ui.go wird angepasst. Die Funktion renderTaskKind wird in den Abschnitten current, queue und running verwendet. Auch renderActivity wird aktualisiert.

💭 **Agent progress** ui.go wird angepasst. Die Funktion renderTaskKind wird in den Abschnitten current, queue und running verwendet. Auch renderActivity wird aktualisiert.

frank commented 2026-07-12 17:18:01 +02:00

Author

Owner

Copy link

💭 Agent progress

Tests and wiki documentation are being updated. New tests cover drawer height and task kind display in orchestration event lines. eventlog_test.go and tui_test.go are modified accordingly.

A new status_test covers TrackRunningWithKind. The wiki Agent-Watch.md is updated with a task kinds section. Tests are run and changes committed incrementally.

💭 **Agent progress** Tests and wiki documentation are being updated. New tests cover drawer height and task kind display in orchestration event lines. eventlog_test.go and tui_test.go are modified accordingly. A new status_test covers TrackRunningWithKind. The wiki Agent-Watch.md is updated with a task kinds section. Tests are run and changes committed incrementally.

frank commented 2026-07-12 17:18:11 +02:00

Author

Owner

Copy link

💭 Agent progress

A test for TrackRunningWithKind is being added to status_test.go. The wiki page Agent-Watch.md is also being updated.

Tests are being run. Changes will be committed in parts.

💭 **Agent progress** A test for TrackRunningWithKind is being added to status_test.go. The wiki page Agent-Watch.md is also being updated. Tests are being run. Changes will be committed in parts.

frank commented 2026-07-12 17:18:34 +02:00

Author

Owner

Copy link

💭 Agent progress

Two tests fail. TestDrawerOuterHeightDefaultExpanded returns zero drawer height because width is zero. The width needs to be set in the test.

TestTUIViewFitsReportedTerminalSize fails because the expanded drawer overflows the 24-line terminal. The drawer height is clamped to a minimum of 10 lines, leaving only 13 lines for the main view. The layout must be adjusted so the view fits within the terminal height even with the drawer expanded.

The drawer height is fixed at 10 lines, leaving 13 lines for the main view. The total rendered height reaches 26, exceeding the 24-line terminal. Two fixes are under consideration: capping the drawer height more aggressively on small terminals, or adjusting the layout math so the total never exceeds the available height.

The expanded drawer adds six extra lines compared to the previous collapsed state. This forces the total view height to 26 on a 24-line terminal. The fix is to clamp the drawer height more aggressively on very small terminals so the view still fits within the terminal bounds.

The drawer height is capped at height - 8 so the dashboard and help line remain visible. On a 24-line terminal this yields 14 lines for the drawer, leaving 13 for the main view. The total view height still reaches 26, so the main view area must also be reduced.

The left panel layout may overflow. With 13 lines for the main view, the left panel gets 12 lines. The stats panel needs 8 lines, but the queue panel is forced to at least 6 lines, totaling 14. That exceeds the 12-line left panel height. This likely explains the test failure.

The drawer height is capped at 10 lines, leaving 13 lines for the main view. The total rendered height reaches 26, exceeding the 24-line terminal. The drawer expansion alone does not fully explain the overflow.

A tighter layout strategy is being considered. Instead of capping the drawer height independently, it would be computed from the remaining space after reserving a minimum main area. This would ensure the total view height stays within the terminal bounds. However, on a 24-line terminal this yields only 8 lines for the drawer, which is below the desired minimum of 10.

The drawer height formula is being revised. On terminals smaller than 30 lines, the minimum drawer height drops to 4 lines instead of 10. The expanded drawer is now capped at one-third of the terminal height, or at the remaining space after reserving a minimum main area. On a 24-line terminal this yields 8 lines for the drawer, leaving 15 lines for the main view.

The drawer minimum is now 4 lines on small terminals, and 10 lines only when the terminal is at least 30 lines tall. On a 24-line terminal this leaves 15 lines for the main view, bringing the total view height to roughly 24 lines. The failing test will be fixed by setting its width to 80.
Ich passe die Drawer-Höhe für kleine Terminals an, damit die Gesamtansicht wieder passt.

💭 **Agent progress** Two tests fail. TestDrawerOuterHeightDefaultExpanded returns zero drawer height because width is zero. The width needs to be set in the test. TestTUIViewFitsReportedTerminalSize fails because the expanded drawer overflows the 24-line terminal. The drawer height is clamped to a minimum of 10 lines, leaving only 13 lines for the main view. The layout must be adjusted so the view fits within the terminal height even with the drawer expanded. The drawer height is fixed at 10 lines, leaving 13 lines for the main view. The total rendered height reaches 26, exceeding the 24-line terminal. Two fixes are under consideration: capping the drawer height more aggressively on small terminals, or adjusting the layout math so the total never exceeds the available height. The expanded drawer adds six extra lines compared to the previous collapsed state. This forces the total view height to 26 on a 24-line terminal. The fix is to clamp the drawer height more aggressively on very small terminals so the view still fits within the terminal bounds. The drawer height is capped at `height - 8` so the dashboard and help line remain visible. On a 24-line terminal this yields 14 lines for the drawer, leaving 13 for the main view. The total view height still reaches 26, so the main view area must also be reduced. The left panel layout may overflow. With 13 lines for the main view, the left panel gets 12 lines. The stats panel needs 8 lines, but the queue panel is forced to at least 6 lines, totaling 14. That exceeds the 12-line left panel height. This likely explains the test failure. The drawer height is capped at 10 lines, leaving 13 lines for the main view. The total rendered height reaches 26, exceeding the 24-line terminal. The drawer expansion alone does not fully explain the overflow. A tighter layout strategy is being considered. Instead of capping the drawer height independently, it would be computed from the remaining space after reserving a minimum main area. This would ensure the total view height stays within the terminal bounds. However, on a 24-line terminal this yields only 8 lines for the drawer, which is below the desired minimum of 10. The drawer height formula is being revised. On terminals smaller than 30 lines, the minimum drawer height drops to 4 lines instead of 10. The expanded drawer is now capped at one-third of the terminal height, or at the remaining space after reserving a minimum main area. On a 24-line terminal this yields 8 lines for the drawer, leaving 15 lines for the main view. The drawer minimum is now 4 lines on small terminals, and 10 lines only when the terminal is at least 30 lines tall. On a 24-line terminal this leaves 15 lines for the main view, bringing the total view height to roughly 24 lines. The failing test will be fixed by setting its width to 80. Ich passe die Drawer-Höhe für kleine Terminals an, damit die Gesamtansicht wieder passt.

frank commented 2026-07-12 17:18:38 +02:00

Author

Owner

Copy link

💭 Agent progress

Layout tests passed. Running the full test suite next, then committing incrementally.

💭 **Agent progress** Layout tests passed. Running the full test suite next, then committing incrementally.

frank commented 2026-07-12 17:18:44 +02:00

Author

Owner

Copy link

💭 Agent progress

Tests passieren. Ich füge nun die Aufgabenarten-Modelle hinzu und verknüpfe sie im Pipeline- und Watcher-Log.

Die Aufgabenarten werden nun auch im TUI und Dashboard angezeigt. Die Agent-Wiki-Dokumentation wird ergänzt. Ich prüfe den Git-Status und erstelle die Commits.

💭 **Agent progress** Tests passieren. Ich füge nun die Aufgabenarten-Modelle hinzu und verknüpfe sie im Pipeline- und Watcher-Log. Die Aufgabenarten werden nun auch im TUI und Dashboard angezeigt. Die Agent-Wiki-Dokumentation wird ergänzt. Ich prüfe den Git-Status und erstelle die Commits.

frank commented 2026-07-12 17:18:46 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Umsetzung erfolgt in drei Schritten:

• Kern-Typen für Aufgabenarten, Status und Eventlog

• Integration in Pipeline und Watcher

• TUI-, Web-Oberfläche, Tests und Wiki

Die drei Schritte werden als separate Commits mit Push nach jedem Teil umgesetzt.

💭 **Agent progress** Die Umsetzung erfolgt in drei Schritten: - Kern-Typen für Aufgabenarten, Status und Eventlog - Integration in Pipeline und Watcher - TUI-, Web-Oberfläche, Tests und Wiki Die drei Schritte werden als separate Commits mit Push nach jedem Teil umgesetzt.

frank added 1 commit 2026-07-12 17:18:49 +02:00

feat(agent): add task kind model for orchestration jobs ... c673a709b3

Introduce stable task kind IDs with human labels and thread them through
IssueEntry, orchestration events, and watch status tracking.

Co-authored-by: Cursor <cursoragent@cursor.com>

frank commented 2026-07-12 17:18:49 +02:00

Author

Owner

Copy link

💭 Agent progress

Next step is committing the pipeline and watcher changes.

💭 **Agent progress** Next step is committing the pipeline and watcher changes.

frank added 1 commit 2026-07-12 17:18:51 +02:00

feat(agent): map dispatch paths to task kinds in pipeline ... bb5e398e4a

Set task kinds for coding, CI repair, conflict repair, and mention jobs;
prefix plain watcher logs with the matching kind label.

Co-authored-by: Cursor <cursoragent@cursor.com>

frank commented 2026-07-12 17:18:52 +02:00

Author

Owner

Copy link

💭 Agent progress

Die finale Commit umfasst die TUI, das UI, Tests und die Wiki-Dokumentation.

💭 **Agent progress** Die finale Commit umfasst die TUI, das UI, Tests und die Wiki-Dokumentation.

frank added 1 commit 2026-07-12 17:18:54 +02:00

feat(agent): show task kinds in dashboard and expand activity drawer ... 926abcd6e6

Display task kind labels in TUI, web UI, and activity log; default the
drawer to ~1/3 terminal height and document kinds in Agent-Watch wiki.

Co-authored-by: Cursor <cursoragent@cursor.com>

frank commented 2026-07-12 17:18:55 +02:00

Author

Owner

Copy link

💭 Agent progress

All commits were pushed. I am verifying the working tree is clean and preparing the final output with the PR title, body, and summary.

💭 **Agent progress** All commits were pushed. I am verifying the working tree is clean and preparing the final output with the PR title, body, and summary.

frank changed title from WIP: #43 Agent: Aufgabenart in Log und Dashboard anzeigen to feat(agent): show task kinds in log and dashboard 2026-07-12 17:19:02 +02:00

frank commented 2026-07-12 17:19:02 +02:00

Author

Owner

Copy link

✅ forge agent finished implementation

• Commit: feat(agent): show task kinds in dashboard and expand activity drawer
• Pull request: #44
• Next: waiting for CI / babysitting fixes if needed

docs/wiki/Agent-Watch.md        | 15 ++++++++++++++-
 internal/agent/eventlog_test.go |  3 ++-
 internal/agent/status_test.go   |  3 +++
 internal/agent/tui.go           | 26 ++++++++++++++++++++------
 internal/agent/tui_test.go      | 23 ++++++++++++++++++++---
 internal/agent/ui.go            | 34 +++++++++++++++++++++++++++-------
 6 files changed, 86 insertions(+), 18 deletions(-)

Agent output (tail)

TODO_DONE: Activity-Log nimmt im TUI etwa 1/3 der Terminalhöhe ein
PR_TITLE: feat(agent): show task kinds in log and dashboard
PR_BODY:
## Summary
- Stabile Task-Kind-IDs (`coding`, `fix_build`, `resolve_conflicts`, `mention`) mit menschenlesbaren Labels
- Mapping aus Dispatch-Pfaden: `RunIssue`, `RunCIFix`, `RunConflictFix`, `RunMentionReply`
- Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (`--no-tui`)
- Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals)
## Test plan
- [x] `go test ./internal/agent/...`
- [ ] `forge agent watch --tui` — Running/Queue zeigen Kind-Labels
- [ ] PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log
- [ ] `--no-tui` — Logzeilen mit `[Fixing Build]` o. ä.
---
### Änderungen (3 Commits)
1. **`taskkind.go`** — Task-Kind-Modell, Labels, Mapping von `prFixKind`
2. **Status & Pipeline** — `TaskKind` auf `IssueEntry` und `OrchestrationEvent`; `TrackRunningWithKind` / `SetRunTaskKind`; Pipeline setzt Kind pro Job-Typ
3. **UI** — TUI zeigt `[Agent Coding]` etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via `logJob()`
4. **Activity-Drawer** — standardmäßig expanded, ~`height/3` (min. 10 Zeilen ab 30 Zeilen Terminalhöhe)
5. **Wiki** — Abschnitt „Task Kinds“ in `docs/wiki/Agent-Watch.md`

✅ **forge agent finished implementation** - Commit: `feat(agent): show task kinds in dashboard and expand activity drawer` - Pull request: https://repository.hildebrandt.io/frank/forgecli/pulls/44 - Next: waiting for CI / babysitting fixes if needed ``` docs/wiki/Agent-Watch.md | 15 ++++++++++++++- internal/agent/eventlog_test.go | 3 ++- internal/agent/status_test.go | 3 +++ internal/agent/tui.go | 26 ++++++++++++++++++++------ internal/agent/tui_test.go | 23 ++++++++++++++++++++--- internal/agent/ui.go | 34 +++++++++++++++++++++++++++------- 6 files changed, 86 insertions(+), 18 deletions(-) ``` <details><summary>Agent output (tail)</summary> ``` TODO_DONE: Activity-Log nimmt im TUI etwa 1/3 der Terminalhöhe ein PR_TITLE: feat(agent): show task kinds in log and dashboard PR_BODY: ## Summary - Stabile Task-Kind-IDs (`coding`, `fix_build`, `resolve_conflicts`, `mention`) mit menschenlesbaren Labels - Mapping aus Dispatch-Pfaden: `RunIssue`, `RunCIFix`, `RunConflictFix`, `RunMentionReply` - Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (`--no-tui`) - Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals) ## Test plan - [x] `go test ./internal/agent/...` - [ ] `forge agent watch --tui` — Running/Queue zeigen Kind-Labels - [ ] PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log - [ ] `--no-tui` — Logzeilen mit `[Fixing Build]` o. ä. --- ### Änderungen (3 Commits) 1. **`taskkind.go`** — Task-Kind-Modell, Labels, Mapping von `prFixKind` 2. **Status & Pipeline** — `TaskKind` auf `IssueEntry` und `OrchestrationEvent`; `TrackRunningWithKind` / `SetRunTaskKind`; Pipeline setzt Kind pro Job-Typ 3. **UI** — TUI zeigt `[Agent Coding]` etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via `logJob()` 4. **Activity-Drawer** — standardmäßig expanded, ~`height/3` (min. 10 Zeilen ab 30 Zeilen Terminalhöhe) 5. **Wiki** — Abschnitt „Task Kinds“ in `docs/wiki/Agent-Watch.md` ``` </details>

frank commented 2026-07-12 17:19:02 +02:00

Author

Owner

Copy link

☑️ ToDos checked off

• Laufende Coding-Jobs zeigen Agent Coding
• CI-Repair zeigt Fixing Build
• Konflikt-Repair zeigt Resolving Conflicts
• Mindestens Mention-Follow-up ist als eigener Kind vorgesehen oder dokumentiert als nächster Kandidat
• Kind ist in TUI-Dashboard und Activity-Log erkennbar
• Wiki/Agent-Watch kurz dokumentiert, welche Kinds es gibt
• Activity-Log nimmt im TUI etwa 1/3 der Terminalhöhe ein

☑️ **ToDos checked off** - [x] Laufende Coding-Jobs zeigen **Agent Coding** - [x] CI-Repair zeigt **Fixing Build** - [x] Konflikt-Repair zeigt **Resolving Conflicts** - [x] Mindestens Mention-Follow-up ist als eigener Kind vorgesehen oder dokumentiert als nächster Kandidat - [x] Kind ist in TUI-Dashboard und Activity-Log erkennbar - [x] Wiki/Agent-Watch kurz dokumentiert, welche Kinds es gibt - [x] Activity-Log nimmt im TUI etwa 1/3 der Terminalhöhe ein

frank commented 2026-07-12 17:19:44 +02:00

Author

Owner

Copy link

🟢 CI green (attempt 1/3)

https://repository.hildebrandt.io/frank/forgecli/actions/runs/102

🟢 **CI green** (attempt 1/3) https://repository.hildebrandt.io/frank/forgecli/actions/runs/102

frank commented 2026-07-12 17:19:44 +02:00

Author

Owner

Copy link

💭 Agent progress

Die Implementierung ist abgeschlossen. Die Änderungen werden nun zusammengefasst.
Issue #43 ist umgesetzt. Die Aufgabenart ist jetzt ein erstklassiges Signal in Status, Logs und UI.

Summary

• Stabile Task-Kind-IDs (coding, fix_build, resolve_conflicts, mention) mit menschenlesbaren Labels
• Mapping aus Dispatch-Pfaden: RunIssue, RunCIFix, RunConflictFix, RunMentionReply
• Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (--no-tui)
• Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals)

Test plan

• go test ./internal/agent/...
• forge agent watch --tui — Running/Queue zeigen Kind-Labels
• PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log
• --no-tui — Logzeilen mit [Fixing Build] o. ä.

---

Änderungen (3 Commits)

1. taskkind.go — Task-Kind-Modell, Labels, Mapping von prFixKind
2. Status & Pipeline — TaskKind auf IssueEntry und OrchestrationEvent; TrackRunningWithKind / SetRunTaskKind; Pipeline setzt Kind pro Job-Typ
3. UI — TUI zeigt [Agent Coding] etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via logJob()
4. Activity-Drawer — standardmäßig expanded, ~height/3 (min. 10 Zeilen ab 30 Zeilen Terminalhöhe)
5. Wiki — Abschnitt „Task Kinds“ in docs/wiki/Agent-Watch.md

💭 **Agent progress** Die Implementierung ist abgeschlossen. Die Änderungen werden nun zusammengefasst. Issue #43 ist umgesetzt. Die Aufgabenart ist jetzt ein erstklassiges Signal in Status, Logs und UI. ## Summary - Stabile Task-Kind-IDs (`coding`, `fix_build`, `resolve_conflicts`, `mention`) mit menschenlesbaren Labels - Mapping aus Dispatch-Pfaden: `RunIssue`, `RunCIFix`, `RunConflictFix`, `RunMentionReply` - Sichtbar in TUI-Dashboard, Activity-Log, Web-UI und Plain-Logs (`--no-tui`) - Activity-Drawer standardmäßig aufgeklappt (~1/3 Terminalhöhe, mit Grenzen für kleine Terminals) ## Test plan - [x] `go test ./internal/agent/...` - [ ] `forge agent watch --tui` — Running/Queue zeigen Kind-Labels - [ ] PR-Repair (CI/Konflikt/Mention) — korrektes Kind in Dashboard und Activity-Log - [ ] `--no-tui` — Logzeilen mit `[Fixing Build]` o. ä. --- ### Änderungen (3 Commits) 1. **`taskkind.go`** — Task-Kind-Modell, Labels, Mapping von `prFixKind` 2. **Status & Pipeline** — `TaskKind` auf `IssueEntry` und `OrchestrationEvent`; `TrackRunningWithKind` / `SetRunTaskKind`; Pipeline setzt Kind pro Job-Typ 3. **UI** — TUI zeigt `[Agent Coding]` etc. in Queue/Overview/Run-Detail; Activity-Log mit Kind-Präfix; Web-UI mit Kind-Spalte; Plain-Logs via `logJob()` 4. **Activity-Drawer** — standardmäßig expanded, ~`height/3` (min. 10 Zeilen ab 30 Zeilen Terminalhöhe) 5. **Wiki** — Abschnitt „Task Kinds“ in `docs/wiki/Agent-Watch.md`

frank merged commit 25b9a88db7 into main 2026-07-12 17:20:31 +02:00

frank deleted branch agent/issue-43-agent-aufgabenart-in-log-und-dashboard-a 2026-07-12 17:20:31 +02:00

frank referenced this pull request from a commit 2026-07-12 17:20:33 +02:00

Merge pull request 'feat(agent): show task kinds in log and dashboard' (#44) from agent/issue-43-agent-aufgabenart-in-log-und-dashboard-a into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

agent:done

Managed by forge agent

  

agent:ready

Managed by forge agent

  

agent:working

Managed by forge agent

  

enhancement

New feature or request

No labels

agent:done

agent:ready

agent:working

enhancement

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

frank/forgecli!44

No description provided.