frank/forgecli
Watch
1
0
Fork
You've already forked forgecli
 0
Code Issues 6 Pull requests 3 Projects Releases 7 Packages Wiki Activity Actions

Agent: Aufgabenart in Log und Dashboard anzeigen #43

New issue
Closed
opened 2026-07-12 17:14:54 +02:00 by frank · 1 comment
frank commented 2026-07-12 17:14:54 +02:00
Owner
Copy link

Motivation

Im Activity-Log und auf dem Agent-Dashboard (TUI / Web) ist aktuell oft nur erkennbar, dass etwas läuft — nicht auf einen Blick, welche Art von Aufgabe der Orchestrator gerade bearbeitet.

Beim Watchen laufen parallel bzw. nacheinander sehr unterschiedliche Jobs (neues Coding, CI-Repair, Merge-Konflikte, Mentions, …). Die Aufgabenart soll als erstklassiges Signal sichtbar sein.

Gewünschtes Verhalten

Für jeden laufenden bzw. geloggten Job eine klare Aufgabenart (Task Kind) anzeigen, z.B.:

Kind Bedeutung
Agent Coding Neues Issue / Implementierung im Coding-Agent
Fixing Build CI fehlgeschlagen → Repair am bestehenden PR/Worktree
Resolving Conflicts Merge-Konflikte am PR beheben
(weitere) Erweiterbar, z.B. Mention Follow-up, Incremental Commit, …

Wo sichtbar

  1. Activity-Log (Orchestration / Activity Drawer) — Kind als Label/Prefix, nicht nur freier Text
  2. Dashboard (TUI und ggf. Web-Status) — bei Running / Current / Queue klar erkennbar
  3. Plain Logs (--no-tui) — konsistente Kennzeichnung in Logzeilen

Anforderungen

  • Einheitliche, stabile Kind-IDs intern (z.B. coding, fix_build, resolve_conflicts, mention, …) und menschenlesbare Labels in der UI
  • Mapping aus bestehenden Dispatch-Pfaden (Pipeline.Run, RunCIFix / babysit repair, RunConflictFix, RunMentionReply, …)
  • Erweiterbar: neue Aufgabentypen sollen ohne UI-Umbau nachziehbar sein
  • Bestehende Detail-Activity (coding agent is working, babysitting PR #…, …) darf ergänzend bleiben; Kind ist das grobe Signal

Ist-Zustand (kurz)

  • IssueEntry.Activity ist freier Text
  • OrchestrationEvent hat category/type (agent/worktree/issue), aber kein Task-Kind
  • Intern existiert bereits prFixKind (ci / mention / conflict) — noch nicht als UI-/Log-Signal durchgezogen

Akzeptanzkriterien

  • 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

Layout: Activity-Log-Höhe

Die Loganzeige (Activity Drawer) soll im TUI-Dashboard etwa 1/3 der Terminalhöhe einnehmen — dauerhaft bzw. im Standard/expanded Zustand so, dass Aufgabenart und Verlauf ohne ständiges Umschalten gut lesbar sind.

  • Zielgröße: ~terminal_height / 3 (mit sinnvollen Min/Max-Grenzen bei sehr kleinen Terminals)
  • Dashboard-Übersicht und Run-Output teilen sich die restlichen ~2/3
  • Verhalten bei Resize beibehalten; ggf. nachziehen, falls die aktuelle Drawer-Höhe in der Praxis kleiner wirkt

Out of Scope

  • Neue Agent-Fähigkeiten (nur Darstellung / Tracking der bestehenden Job-Arten)
## Motivation Im Activity-Log und auf dem Agent-Dashboard (TUI / Web) ist aktuell oft nur erkennbar, *dass* etwas läuft — nicht auf einen Blick, *welche Art* von Aufgabe der Orchestrator gerade bearbeitet. Beim Watchen laufen parallel bzw. nacheinander sehr unterschiedliche Jobs (neues Coding, CI-Repair, Merge-Konflikte, Mentions, …). Die Aufgabenart soll als erstklassiges Signal sichtbar sein. ## Gewünschtes Verhalten Für jeden laufenden bzw. geloggten Job eine klare **Aufgabenart** (Task Kind) anzeigen, z.B.: | Kind | Bedeutung | |------|-----------| | **Agent Coding** | Neues Issue / Implementierung im Coding-Agent | | **Fixing Build** | CI fehlgeschlagen → Repair am bestehenden PR/Worktree | | **Resolving Conflicts** | Merge-Konflikte am PR beheben | | *(weitere)* | Erweiterbar, z.B. Mention Follow-up, Incremental Commit, … | ### Wo sichtbar 1. **Activity-Log** (Orchestration / Activity Drawer) — Kind als Label/Prefix, nicht nur freier Text 2. **Dashboard** (TUI und ggf. Web-Status) — bei Running / Current / Queue klar erkennbar 3. **Plain Logs** (`--no-tui`) — konsistente Kennzeichnung in Logzeilen ### Anforderungen - Einheitliche, stabile Kind-IDs intern (z.B. `coding`, `fix_build`, `resolve_conflicts`, `mention`, …) und menschenlesbare Labels in der UI - Mapping aus bestehenden Dispatch-Pfaden (`Pipeline.Run`, `RunCIFix` / babysit repair, `RunConflictFix`, `RunMentionReply`, …) - Erweiterbar: neue Aufgabentypen sollen ohne UI-Umbau nachziehbar sein - Bestehende Detail-Activity (`coding agent is working`, `babysitting PR #…`, …) darf ergänzend bleiben; Kind ist das grobe Signal ## Ist-Zustand (kurz) - `IssueEntry.Activity` ist freier Text - `OrchestrationEvent` hat `category`/`type` (agent/worktree/issue), aber kein Task-Kind - Intern existiert bereits `prFixKind` (`ci` / `mention` / `conflict`) — noch nicht als UI-/Log-Signal durchgezogen ## Akzeptanzkriterien - [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 ## Layout: Activity-Log-Höhe Die Loganzeige (Activity Drawer) soll im TUI-Dashboard etwa **1/3 der Terminalhöhe** einnehmen — dauerhaft bzw. im Standard/expanded Zustand so, dass Aufgabenart und Verlauf ohne ständiges Umschalten gut lesbar sind. - Zielgröße: ~`terminal_height / 3` (mit sinnvollen Min/Max-Grenzen bei sehr kleinen Terminals) - Dashboard-Übersicht und Run-Output teilen sich die restlichen ~2/3 - Verhalten bei Resize beibehalten; ggf. nachziehen, falls die aktuelle Drawer-Höhe in der Praxis kleiner wirkt ## Out of Scope - Neue Agent-Fähigkeiten (nur Darstellung / Tracking der bestehenden Job-Arten)
frank commented 2026-07-12 17:16:24 +02:00
Author
Owner
Copy link

🤖 forge agent started

  • Agent: cursor-agent
  • Model: (default)
  • Mode: pr
  • Trigger: assignee=agent
  • Open ToDos: 7

Agent: Aufgabenart in Log und Dashboard anzeigen — Im Activity-Log und auf dem Agent-Dashboard (TUI / Web) ist aktuell oft nur erkennbar, dass etwas läuft — nicht auf einen Blick, welche Art von Aufgabe der Orchestrator gerade bearbeitet.

🤖 **forge agent started** - Agent: `cursor-agent` - Model: `(default)` - Mode: `pr` - Trigger: `assignee=agent` - Open ToDos: 7 Agent: Aufgabenart in Log und Dashboard anzeigen — Im Activity-Log und auf dem Agent-Dashboard (TUI / Web) ist aktuell oft nur erkennbar, *dass* etwas läuft — nicht auf einen Blick, *welche Art* von Aufgabe der Orchestrator gerade bearbeitet.
frank closed this issue 2026-07-12 17:20:31 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
agent/issue-68-all-repos-filter-allowlist-owner-org-pat
agent/issue-67-all-repos-eigenes-refresh-intervall-api
agent/issue-69-doku-unattended-server-daemon-systemd-cr
agent/issue-56-agent-user-mapping-zusätzliche-user-üb
agent/issue-59-strukturelle-analyse-der-codebase
agent/issue-36-agent-config-mode-für-aktuelles-verzeic
0.10.0
0.9.0
0.8.0
0.7.0
0.6.0
0.5.0
0.4.0
0.3.3
0.3.2
0.3.1
0.3.0
0.2.0
0.1.0
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
agent
1 participant
Notifications
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#43
No description provided.