frank/forgecli

Watch

Fork 0

Agent Dashboard: parallele TUI-Views, Limits & Configfile #15

New issue

Closed

opened 2026-07-12 11:26:31 +02:00 by frank · 1 comment

frank commented

2026-07-12 11:26:31 +02:00

Owner

Problem

forge agent watch unterstützt bereits --parallel, --repos und eine einfache Bubbletea-TUI (--tui). Im Parallelbetrieb ist die Ausgabe und Steuerung aber unzureichend:

Die TUI zeigt nur einen Agent-Output-Stream („Current agent run“); bei mehreren parallelen Runs kann man nicht zwischen Run-Views wechseln.
Start landet nicht bewusst im Agent-Dashboard; die Hauptview ist eher ein Log-Viewport mit Stats/Queue-Panels.
Parallelität ist nur global (--parallel), nicht pro Projekt/Repo begrenzt.
Es gibt kein Limit für offene Agent-PRs — bei vielen parallelen Features wachsen Merge-Konflikte.
Issue-Dependencies (Forgejo blocked-by / depends-on) werden beim Dispatch nicht beachtet.
Watch-Targets und Limits sind über viele CLI-Flags verteilt; es fehlt ein dokumentiertes Configfile.
Nach Merge eines Agent-PRs wird der lokale Main/Base-Branch nicht automatisch gefetched/gepullt — Folge-Runs starten auf veraltetem Stand.

Verwandt (aber getrennt): #14 (ACP-strukturierte Ausgaben), #13/#10 (Worktree-Lifecycle nach Merge).

Ziel

Ein grafisches Agent-Dashboard (TUI) als Standard-Startansicht für forge agent watch, mit View-Switching zwischen parallelen Runs, konfigurierbaren Parallelitäts-/PR-Limits, Dependency-aware Dispatch und automatischem Sync des lokalen Base-Branches nach PR-Merge — gesteuert über ein dokumentiertes Configfile.

Scope

1. Agent-Dashboard TUI (Hauptview)

Beim Start von forge agent watch (interaktiv) immer im Dashboard landen (nicht erst mit --tui als Zusatzflag — bzw. --tui als Default im Terminal, --no-tui für Plain-Logs).
Grafische TUI (bestehend: Bubbletea/Lipgloss) als Dashboard überarbeiten:
- Übersicht: Repos, Queue, Running, Done/Failed, offene Agent-PRs, Limits (Slots frei/belegt).
- Pro laufendem Run eine eigene View/Pane (Issue-Titel, Repo, Phase, Output).
- Zwischen Run-Views switchen (z. B. Tab / 1–9 / n/p / Listen-Auswahl), wenn mehrere Agents parallel laufen.
- Fokus klar: Dashboard = Steuerung & Überblick; Detail-View = Output des gewählten Runs.
Keybindings dokumentieren (Help-Footer).

2. Parallelitäts- und PR-Limits

Limit	Bedeutung	Zweck
`max_parallel` (global)	max. gleichzeitige Pipelines gesamt	Ressourcen / Agent-CLIs
`max_parallel_per_repo` (o.ä.)	max. gleichzeitige Runs pro Repo/Projekt	Konflikte & lokale Load
`max_open_prs` (global und/oder pro Repo)	max. offene Agent-PRs	Konflikte klein halten; neue Runs warten

Dispatch blockiert / queued, wenn Limits erreicht sind (sichtbar im Dashboard).
Bestehendes --parallel bleibt kompatibel und wird vom Configfile überschreib-/ergänzbar.

3. Issue-Dependencies

Vor dem Start eines Runs: Forgejo Issue-Dependencies prüfen (blocked-by / depends-on bzw. äquivalente API).
Issues mit offenen/unerfüllten Dependencies nicht dispatchen; im Dashboard als blocked anzeigen.
Nach Abschluss/Merge abhängiger Issues erneut in die Queue aufnehmen (nächster Poll).

4. Dokumentiertes Configfile

Neues Configfile (z. B. ~/.config/forge/agent.yaml oder projektspezifisch ./.forge/agent.yaml), dokumentiert in Wiki + Beispiel:

# Beispiel — finale Keys in der Implementierung festlegen
interval: 30s
agent: cursor-agent
model: ""
git_mode: pr          # commit | pr
trigger:
  label: agent        # genau einer: user | label | project

parallel:
  max: 3
  per_repo: 1
max_open_prs: 2       # global; optional per_repo darunter

repos:
  - owner: frank
    name: forgecli
    path: ~/src/forgecli   # lokaler Checkout für Pull/Fetch
    max_parallel: 1
    max_open_prs: 2
  - owner: frank
    name: anderes-repo
    path: ~/src/anderes-repo

# optionale Defaults wie working_label, done_label, babysit, …

Anforderungen:

Configfile dokumentieren (Felder, Defaults, Precedence: Flag > Env > Config > Default).
Mehrere zu überwachende Repos inkl. lokalem Pfad.
CLI-Flags bleiben nutzbar und überschreiben Config-Werte.
Wiki-Unterseite + Link von Home; Beispiele müssen mit forge agent watch --help übereinstimmen.

5. Sync nach PR-Merge

Wenn ein Agent-PR gemerged wird (Poll/API): lokalen Checkout des Repo-Base-Branches (main/default) fetch + pull (fast-forward preferred).
Zweck: nächste Worktrees/Runs starten auf aktuellem Stand; Konflikte reduzieren.
Fehler beim Sync sichtbar loggen / im Dashboard anzeigen, Watcher nicht hart abbrechen (retry beim nächsten Poll).
Abstimmen mit Worktree-Cleanup nach Merge (#13 / #10).

Nicht im Scope (zunächst)

Vollständige ACP-Event-Darstellung (#14) — Dashboard kann Raw-Output weiter anzeigen; strukturierte Events später einbinden.
Web-UI (--ui) Parität mit allen neuen Dashboard-Views (kann Follow-up sein; zumindest Status-Metriken zu Limits/Blocked sollten mitwachsen, wo einfach).
Multi-Host-Orchestrierung außerhalb der konfigurierten Repo-Liste.

Akzeptanzkriterien

Interaktiver forge agent watch-Start öffnet das Agent-Dashboard als Hauptview.
Bei ≥2 parallelen Runs kann man zwischen den Run-Views wechseln und den jeweiligen Output sehen.
Configfile steuert Repos, globale und per-Repo Parallelität, max. offene PRs; dokumentiert inkl. Precedence.
Dispatch respektiert max_parallel, max_parallel_per_repo und max_open_prs (sichtbare Queue-/Limit-Anzeige).
Issues mit unerfüllten Dependencies werden nicht gestartet und als blocked geführt.
Nach Merge eines Agent-PRs wird der lokale Base-Branch des betroffenen Repos gefetched/gepullt.
Wiki + --help sind aktualisiert; Tests decken Config-Parsing, Limit-Logik und Dependency-Skip ab.

Relevante Code-Stellen

internal/agent/tui.go — aktuelle Split-Screen-TUI
internal/agent/status.go — WatchStatus / parallele Runs
internal/agent/watcher.go — Poll, Queue, MaxParallel
internal/agent/config.go — Flags/Config, Repos, MaxParallel
internal/agent/pipeline.go / gitflow.go — PR-Modus, Worktrees, Git
internal/cmd/agent.go — CLI-Wiring
internal/agent/ui.go — Web-Dashboard (optional mitziehen)

Vorschlag Umsetzungsschritte

Configfile-Schema + Loader + Docs
Limit-Engine (per-repo parallel, max open PRs) im Watcher
Dependency-Check vor Dispatch
Post-Merge local base sync
Dashboard-TUI + View-Switching (Default bei TTY)

## Problem `forge agent watch` unterstützt bereits `--parallel`, `--repos` und eine einfache Bubbletea-TUI (`--tui`). Im Parallelbetrieb ist die Ausgabe und Steuerung aber unzureichend: - Die TUI zeigt nur **einen** Agent-Output-Stream („Current agent run“); bei mehreren parallelen Runs kann man **nicht zwischen Run-Views wechseln**. - Start landet nicht bewusst im **Agent-Dashboard**; die Hauptview ist eher ein Log-Viewport mit Stats/Queue-Panels. - Parallelität ist nur global (`--parallel`), nicht **pro Projekt/Repo** begrenzt. - Es gibt **kein Limit für offene Agent-PRs** — bei vielen parallelen Features wachsen Merge-Konflikte. - **Issue-Dependencies** (Forgejo blocked-by / depends-on) werden beim Dispatch nicht beachtet. - Watch-Targets und Limits sind über viele CLI-Flags verteilt; es fehlt ein **dokumentiertes Configfile**. - Nach Merge eines Agent-PRs wird der **lokale Main/Base-Branch** nicht automatisch gefetched/gepullt — Folge-Runs starten auf veraltetem Stand. Verwandt (aber getrennt): #14 (ACP-strukturierte Ausgaben), #13/#10 (Worktree-Lifecycle nach Merge). ## Ziel Ein **grafisches Agent-Dashboard (TUI)** als Standard-Startansicht für `forge agent watch`, mit View-Switching zwischen parallelen Runs, konfigurierbaren Parallelitäts-/PR-Limits, Dependency-aware Dispatch und automatischem Sync des lokalen Base-Branches nach PR-Merge — gesteuert über ein dokumentiertes Configfile. ## Scope ### 1. Agent-Dashboard TUI (Hauptview) - Beim Start von `forge agent watch` (interaktiv) immer im **Dashboard** landen (nicht erst mit `--tui` als Zusatzflag — bzw. `--tui` als Default im Terminal, `--no-tui` für Plain-Logs). - Grafische TUI (bestehend: Bubbletea/Lipgloss) als Dashboard überarbeiten: - Übersicht: Repos, Queue, Running, Done/Failed, offene Agent-PRs, Limits (Slots frei/belegt). - Pro laufendem Run eine **eigene View**/Pane (Issue-Titel, Repo, Phase, Output). - **Zwischen Run-Views switchen** (z. B. Tab / `1`–`9` / `n`/`p` / Listen-Auswahl), wenn mehrere Agents parallel laufen. - Fokus klar: Dashboard = Steuerung & Überblick; Detail-View = Output des gewählten Runs. - Keybindings dokumentieren (Help-Footer). ### 2. Parallelitäts- und PR-Limits | Limit | Bedeutung | Zweck | |-------|-----------|--------| | `max_parallel` (global) | max. gleichzeitige Pipelines gesamt | Ressourcen / Agent-CLIs | | `max_parallel_per_repo` (o.ä.) | max. gleichzeitige Runs **pro Repo/Projekt** | Konflikte & lokale Load | | `max_open_prs` (global und/oder pro Repo) | max. offene Agent-PRs | Konflikte klein halten; neue Runs warten | - Dispatch blockiert / queued, wenn Limits erreicht sind (sichtbar im Dashboard). - Bestehendes `--parallel` bleibt kompatibel und wird vom Configfile überschreib-/ergänzbar. ### 3. Issue-Dependencies - Vor dem Start eines Runs: Forgejo **Issue-Dependencies** prüfen (blocked-by / depends-on bzw. äquivalente API). - Issues mit offenen/unerfüllten Dependencies **nicht** dispatchen; im Dashboard als `blocked` anzeigen. - Nach Abschluss/Merge abhängiger Issues erneut in die Queue aufnehmen (nächster Poll). ### 4. Dokumentiertes Configfile Neues Configfile (z. B. `~/.config/forge/agent.yaml` oder projektspezifisch `./.forge/agent.yaml`), dokumentiert in Wiki + Beispiel: ```yaml # Beispiel — finale Keys in der Implementierung festlegen interval: 30s agent: cursor-agent model: "" git_mode: pr # commit | pr trigger: label: agent # genau einer: user | label | project parallel: max: 3 per_repo: 1 max_open_prs: 2 # global; optional per_repo darunter repos: - owner: frank name: forgecli path: ~/src/forgecli # lokaler Checkout für Pull/Fetch max_parallel: 1 max_open_prs: 2 - owner: frank name: anderes-repo path: ~/src/anderes-repo # optionale Defaults wie working_label, done_label, babysit, … ``` Anforderungen: - Configfile dokumentieren (Felder, Defaults, Precedence: Flag > Env > Config > Default). - Mehrere zu überwachende Repos inkl. lokalem Pfad. - CLI-Flags bleiben nutzbar und überschreiben Config-Werte. - Wiki-Unterseite + Link von `Home`; Beispiele müssen mit `forge agent watch --help` übereinstimmen. ### 5. Sync nach PR-Merge - Wenn ein Agent-PR **gemerged** wird (Poll/API): lokalen Checkout des Repo-Base-Branches (**main**/default) **fetch + pull** (fast-forward preferred). - Zweck: nächste Worktrees/Runs starten auf aktuellem Stand; Konflikte reduzieren. - Fehler beim Sync sichtbar loggen / im Dashboard anzeigen, Watcher nicht hart abbrechen (retry beim nächsten Poll). - Abstimmen mit Worktree-Cleanup nach Merge (#13 / #10). ## Nicht im Scope (zunächst) - Vollständige ACP-Event-Darstellung (#14) — Dashboard kann Raw-Output weiter anzeigen; strukturierte Events später einbinden. - Web-UI (`--ui`) Parität mit allen neuen Dashboard-Views (kann Follow-up sein; zumindest Status-Metriken zu Limits/Blocked sollten mitwachsen, wo einfach). - Multi-Host-Orchestrierung außerhalb der konfigurierten Repo-Liste. ## Akzeptanzkriterien - [x] Interaktiver `forge agent watch`-Start öffnet das **Agent-Dashboard** als Hauptview. - [x] Bei ≥2 parallelen Runs kann man **zwischen den Run-Views wechseln** und den jeweiligen Output sehen. - [x] Configfile steuert **Repos**, **globale und per-Repo Parallelität**, **max. offene PRs**; dokumentiert inkl. Precedence. - [x] Dispatch respektiert `max_parallel`, `max_parallel_per_repo` und `max_open_prs` (sichtbare Queue-/Limit-Anzeige). - [x] Issues mit unerfüllten **Dependencies** werden nicht gestartet und als blocked geführt. - [x] Nach Merge eines Agent-PRs wird der lokale Base-Branch des betroffenen Repos gefetched/gepullt. - [x] Wiki + `--help` sind aktualisiert; Tests decken Config-Parsing, Limit-Logik und Dependency-Skip ab. ## Relevante Code-Stellen - `internal/agent/tui.go` — aktuelle Split-Screen-TUI - `internal/agent/status.go` — `WatchStatus` / parallele Runs - `internal/agent/watcher.go` — Poll, Queue, `MaxParallel` - `internal/agent/config.go` — Flags/`Config`, `Repos`, `MaxParallel` - `internal/agent/pipeline.go` / `gitflow.go` — PR-Modus, Worktrees, Git - `internal/cmd/agent.go` — CLI-Wiring - `internal/agent/ui.go` — Web-Dashboard (optional mitziehen) ## Vorschlag Umsetzungsschritte 1. Configfile-Schema + Loader + Docs 2. Limit-Engine (per-repo parallel, max open PRs) im Watcher 3. Dependency-Check vor Dispatch 4. Post-Merge local base sync 5. Dashboard-TUI + View-Switching (Default bei TTY)

frank referenced this issue

2026-07-12 11:28:36 +02:00

Agent Bare Mode: Repos per URL clonen & aktuell halten #16

agent was assigned by frank

2026-07-12 12:27:00 +02:00

frank commented

2026-07-12 12:27:01 +02:00

Author

Owner

🤖 forge agent started

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

Agent Dashboard: parallele TUI-Views, Limits & Configfile — forge agent watch unterstützt bereits --parallel, --repos und eine einfache Bubbletea-TUI (--tui). Im Parallelbetrieb ist die Ausgabe und Steuerung aber unzureichend:

🤖 **forge agent started** - Agent: `cursor-agent` - Model: `(default)` - Mode: `pr` - Trigger: `assignee=agent` - Open ToDos: 7 Agent Dashboard: parallele TUI-Views, Limits & Configfile — `forge agent watch` unterstützt bereits `--parallel`, `--repos` und eine einfache Bubbletea-TUI (`--tui`). Im Parallelbetrieb ist die Ausgabe und Steuerung aber unzureichend:

frank added the

agent:working

label

2026-07-12 12:27:01 +02:00

frank referenced this issue

2026-07-12 12:31:21 +02:00

TUI: ACP-Output lesbarer machen (Chat zusammenfügen, Tool-Calls gruppieren) #20

frank referenced this issue from a pull request that will close it,

2026-07-12 12:32:50 +02:00

feat(agent): Agent-Dashboard, parallele Run-Views, Limits & agent.yaml #21

frank referenced this issue

2026-07-12 12:32:50 +02:00