feat(agent): workspace mode and live config hotkeys in watch dashboard #47

Merged

frank merged 3 commits from agent/issue-46-agent-watch-workspace-modus-außerhalb-e into main 2026-07-12 17:34:57 +02:00

Conversation 53 Commits 3 Files changed 15 +703 -87

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

Owner

Copy link

Summary

• Workspace-Modus: Start von forge agent watch außerhalb eines Git-Repos nutzt ./agent.yaml im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt ~/.config/forge/repos/).
• Laufzeit-Config: c im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt agent.yaml und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen).
• Repo hinzufügen: a + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf.
• Dokumentation: Wiki Agent-Watch und Help-Texte für Workspace-Modus und Hotkeys c/a.

Test plan

• mkdir ~/agent-ws && cd ~/agent-ws && forge agent config legt ~/agent-ws/agent.yaml an
• forge agent watch im Workspace legt Bare-Repos unter ~/agent-ws/owner/repo.git an
• Im Dashboard c → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart
• Im Dashboard a → HTTPS-URL → Repo erscheint im Poll
• Innerhalb eines Repos: ./.forge/agent.yaml und globaler Cache unverändert
• go test ./...

Änderungen (3 Commits)

1. feat(agent): add workspace mode outside git repositories
2. feat(agent): reload watch config at runtime from agent.yaml
3. feat(agent): add watch dashboard hotkeys for config and repo add

---

Zusammenfassung: Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (./agent.yaml, Bare-Cache im CWD). Im Watch-Dashboard öffnet c die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, a fügt per HTTPS-URL Repos hinzu. WatchConfigurator und ScheduleReload aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit --config/repo_cache_dir bleibt kompatibel.

Closes #46

## Summary - **Workspace-Modus:** Start von `forge agent watch` außerhalb eines Git-Repos nutzt `./agent.yaml` im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt `~/.config/forge/repos/`). - **Laufzeit-Config:** `c` im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt `agent.yaml` und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen). - **Repo hinzufügen:** `a` + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf. - **Dokumentation:** Wiki `Agent-Watch` und Help-Texte für Workspace-Modus und Hotkeys `c`/`a`. ## Test plan - [ ] `mkdir ~/agent-ws && cd ~/agent-ws && forge agent config` legt `~/agent-ws/agent.yaml` an - [ ] `forge agent watch` im Workspace legt Bare-Repos unter `~/agent-ws/owner/repo.git` an - [ ] Im Dashboard `c` → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart - [ ] Im Dashboard `a` → HTTPS-URL → Repo erscheint im Poll - [ ] Innerhalb eines Repos: `./.forge/agent.yaml` und globaler Cache unverändert - [ ] `go test ./...` ## Änderungen (3 Commits) 1. `feat(agent): add workspace mode outside git repositories` 2. `feat(agent): reload watch config at runtime from agent.yaml` 3. `feat(agent): add watch dashboard hotkeys for config and repo add` --- **Zusammenfassung:** Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (`./agent.yaml`, Bare-Cache im CWD). Im Watch-Dashboard öffnet `c` die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, `a` fügt per HTTPS-URL Repos hinzu. `WatchConfigurator` und `ScheduleReload` aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit `--config`/`repo_cache_dir` bleibt kompatibel. Closes #46

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

Author

Owner

Copy link

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

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

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

Author

Owner

Copy link

💭 Agent progress

Ich implementiere Issue #46 für den forgecli-Projekt.

Der Arbeitsmodus soll außerhalb von Git-Repositories aktiv sein. Das aktuelle Verzeichnis dient dann als Root für agent.yaml und die Bare-Repos. In der Watch-TUI öffnet c die Konfiguration. Änderungen gelten sofort dem laufenden Prozess und werden in die Workspace-Konfiguration geschrieben.

Die TUI-Taste a öffnet einen Dialog zur Eingabe einer HTTPS-URL. Das Repository wird in die Konfiguration aufgenommen und als Bare-Clone erstellt. Der Watcher erkennt es automatisch. Ich untersuche nun die bestehende Codebasis.
Ich verschaffe mir zuerst einen Überblick über den aktuellen Stand von agent watch, Workspace-Modus und TUI.

💭 **Agent progress** Ich implementiere Issue #46 für den forgecli-Projekt. Der Arbeitsmodus soll außerhalb von Git-Repositories aktiv sein. Das aktuelle Verzeichnis dient dann als Root für `agent.yaml` und die Bare-Repos. In der Watch-TUI öffnet `c` die Konfiguration. Änderungen gelten sofort dem laufenden Prozess und werden in die Workspace-Konfiguration geschrieben. Die TUI-Taste `a` öffnet einen Dialog zur Eingabe einer HTTPS-URL. Das Repository wird in die Konfiguration aufgenommen und als Bare-Clone erstellt. Der Watcher erkennt es automatisch. Ich untersuche nun die bestehende Codebasis. Ich verschaffe mir zuerst einen Überblick über den aktuellen Stand von `agent watch`, Workspace-Modus und TUI.

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

Author

Owner

Copy link

💭 Agent progress

Ich lese die wichtigsten Dateien, um den aktuellen Implementierungsstand zu verstehen.

Ich prüfe nun agentfile.go, watch.go, tui.go, config_tui.go und agent.go für den Watch-Befehl.

💭 **Agent progress** Ich lese die wichtigsten Dateien, um den aktuellen Implementierungsstand zu verstehen. Ich prüfe nun agentfile.go, watch.go, tui.go, config_tui.go und agent.go für den Watch-Befehl.

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

Author

Owner

Copy link

💭 Agent progress

Ich lese weiter. Besonders config_tui_test.go, tui.go und agent.go. Ich suche nach Tests für den Workspace-Modus und der Hotkey-Implementierung.

Ich prüfe auch den aktuellen Git-Status.

💭 **Agent progress** Ich lese weiter. Besonders config_tui_test.go, tui.go und agent.go. Ich suche nach Tests für den Workspace-Modus und der Hotkey-Implementierung. Ich prüfe auch den aktuellen Git-Status.

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

Author

Owner

Copy link

💭 Agent progress

Die Branch ist bereits vorhanden. Die Arbeitsdatei ist sauber und entspricht dem aktuellen Commit.

Ich lese die relevanten Dateien für die Implementierung. Dazu gehören gitflow.go, cmd/agent.go, config_tui.go und gitutil.

💭 **Agent progress** Die Branch ist bereits vorhanden. Die Arbeitsdatei ist sauber und entspricht dem aktuellen Commit. Ich lese die relevanten Dateien für die Implementierung. Dazu gehören gitflow.go, cmd/agent.go, config_tui.go und gitutil.

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

Author

Owner

Copy link

💭 Agent progress

Ich lese weiter in config_tui.go, um die Integration der Konfigurationsbearbeitung in die Watch-TUI zu verstehen. Zudem analysiere ich resolveRepoArg, um die Repository-Auflösung innerhalb und außerhalb eines Git-Repositorys zu klären.

💭 **Agent progress** Ich lese weiter in config_tui.go, um die Integration der Konfigurationsbearbeitung in die Watch-TUI zu verstehen. Zudem analysiere ich resolveRepoArg, um die Repository-Auflösung innerhalb und außerhalb eines Git-Repositorys zu klären.

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

Author

Owner

Copy link

💭 Agent progress

Ich prüfe die Funktion resolveRepoArg im erweiterten Code.

Der Plan für den Workspace-Modus ist klar. Ich prüfe, ob das aktuelle Verzeichnis ein Git-Repository ist. Im Workspace-Modus soll ./agent.yaml statt ./.forge/agent.yaml verwendet werden. Die Bare-Repos sollen unter dem aktuellen Arbeitsverzeichnis angelegt werden.

Die Cache-Pfade für Bare-Repos im Workspace-Modus sind nun festgelegt. Die Watch-TUI soll über die Tasten c und a konfiguriert und neue Repos hinzugefügt werden. Ich prüfe resolveRepoArg und status.go auf vorhandene Workspace-Logik.

💭 **Agent progress** Ich prüfe die Funktion `resolveRepoArg` im erweiterten Code. Der Plan für den Workspace-Modus ist klar. Ich prüfe, ob das aktuelle Verzeichnis ein Git-Repository ist. Im Workspace-Modus soll `./agent.yaml` statt `./.forge/agent.yaml` verwendet werden. Die Bare-Repos sollen unter dem aktuellen Arbeitsverzeichnis angelegt werden. Die Cache-Pfade für Bare-Repos im Workspace-Modus sind nun festgelegt. Die Watch-TUI soll über die Tasten `c` und `a` konfiguriert und neue Repos hinzugefügt werden. Ich prüfe `resolveRepoArg` und `status.go` auf vorhandene Workspace-Logik.

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

Author

Owner

Copy link

💭 Agent progress

Ich prüfe gitutil.CurrentRepo und die TUI-Hilfszeile. Die Speicherlogik in config_tui für Repositories wird ebenfalls analysiert.

Der Plan umfasst drei Bereiche. Ein neuer WorkspaceContext erkennt den Workspace-Modus und definiert Pfade für agent.yaml sowie den Cache. buildAgentConfig soll im Workspace-Modus resolveRepoArg überspringen und den aktuellen Ordner als Standard-Cache-Verzeichnis nutzen. Der Watcher muss dynamische Updates für Konfiguration und Repositories unterstützen.

Ein WatchController mit Mutex soll die konfigurierbare Watcher-Konfiguration verwalten. Änderungen in der TUI sollen den Watcher sofort neu laden. Der Testfall für CurrentRepo wird geprüft.

💭 **Agent progress** Ich prüfe gitutil.CurrentRepo und die TUI-Hilfszeile. Die Speicherlogik in config_tui für Repositories wird ebenfalls analysiert. Der Plan umfasst drei Bereiche. Ein neuer WorkspaceContext erkennt den Workspace-Modus und definiert Pfade für agent.yaml sowie den Cache. buildAgentConfig soll im Workspace-Modus resolveRepoArg überspringen und den aktuellen Ordner als Standard-Cache-Verzeichnis nutzen. Der Watcher muss dynamische Updates für Konfiguration und Repositories unterstützen. Ein WatchController mit Mutex soll die konfigurierbare Watcher-Konfiguration verwalten. Änderungen in der TUI sollen den Watcher sofort neu laden. Der Testfall für CurrentRepo wird geprüft.

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

Author

Owner

Copy link

💭 Agent progress

Ich lese helpLine und config_tui für das Speichern und Hinzufügen von Repos.

Der Watcher muss geprüft werden, um zu sehen, wie Repos verwendet werden. Thread-sichere Updates sind erforderlich.

💭 **Agent progress** Ich lese helpLine und config_tui für das Speichern und Hinzufügen von Repos. Der Watcher muss geprüft werden, um zu sehen, wie Repos verwendet werden. Thread-sichere Updates sind erforderlich.

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

Author

Owner

Copy link

💭 Agent progress

Die Anforderungen sind klar. Ich plane nun die Umsetzung.

Ich definiere in Go zwei Hilfsfunktionen für den Workspace-Modus. InWorkspaceMode erkennt, ob das aktuelle Verzeichnis außerhalb eines Git-Repositorys liegt. WorkspaceRoot gibt das aktuelle Arbeitsverzeichnis zurück, wenn der Modus aktiv ist.

Ich passe die Agent-Dateipfade an. Im Workspace-Modus liegt sie direkt im Arbeitsverzeichnis. Im Repository-Modus bleibt sie unter .forge/. Zwei neue Hilfsfunktionen berechnen den effektiven Pfad und den Standardpfad für die Konfigurationstui.

Die Konfigurationstui nutzt den Workspace-Pfad, falls der Agent außerhalb eines Git-Repositorys läuft. Ohne explizite Cache-Konfiguration legt der Agent im Workspace-Modus die Bare-Repos direkt im Arbeitsverzeichnis an.

In buildAgentConfig wird der Cache-Verzeichnispfad im Workspace-Modus auf den Arbeitsordner gesetzt, sofern repo_cache_dir nicht explizit gesetzt ist. Die Validierung von Repository-Argumenten erfolgt weiterhin nur in agentWatchDeps. Der normale Repository-Modus bleibt unverändert. Bei expliziter Konfigurationsdatei greift der Workspace-Pfad beim Laden nicht, aber der Cache könnte weiterhin vom Arbeitsverzeichnis abgeleitet werden.

Der Workspace-Modus greift nur auf das Arbeitsverzeichnis zu, nicht auf den Pfad der expliziten Konfigurationsdatei. Die Watcher-Struktur erhält eine Schreib-Sperre, damit die Konfiguration und die Repository-Liste zur Laufzeit neu geladen werden können. Dazu kommen Methoden zum Aktualisieren aus der Agent-Datei und zum Hinzufügen neuer Repositories über die TUI.

Die Watch-TUI erhält zwei neue Modi. c öffnet die Konfigurationstui und speichert Änderungen direkt in der Agent-Datei. a fragt nach einer URL und fügt das Repository hinzu. Beide Modi laufen über ein gemeinsames Modell, um Konflikte mit dem alternativen Screen zu vermeiden.

Ich plane, RunConfigT mit einem neuen Options-Parameter zu refactoren. Damit lässt sich der Speicherort und eine benutzerdefinierte Speicherfunktion steuern. Die Watch-TUI nutzt diese Option, um die Konfiguration direkt an den Watcher anzuhängen und die Datei zu speichern. Dazu prüfe ich zunächst den bestehenden Speichermechanismus und die Logik für Repository-Vorschläge.

💭 **Agent progress** Die Anforderungen sind klar. Ich plane nun die Umsetzung. Ich definiere in Go zwei Hilfsfunktionen für den Workspace-Modus. `InWorkspaceMode` erkennt, ob das aktuelle Verzeichnis außerhalb eines Git-Repositorys liegt. `WorkspaceRoot` gibt das aktuelle Arbeitsverzeichnis zurück, wenn der Modus aktiv ist. Ich passe die Agent-Dateipfade an. Im Workspace-Modus liegt sie direkt im Arbeitsverzeichnis. Im Repository-Modus bleibt sie unter `.forge/`. Zwei neue Hilfsfunktionen berechnen den effektiven Pfad und den Standardpfad für die Konfigurationstui. Die Konfigurationstui nutzt den Workspace-Pfad, falls der Agent außerhalb eines Git-Repositorys läuft. Ohne explizite Cache-Konfiguration legt der Agent im Workspace-Modus die Bare-Repos direkt im Arbeitsverzeichnis an. In `buildAgentConfig` wird der Cache-Verzeichnispfad im Workspace-Modus auf den Arbeitsordner gesetzt, sofern `repo_cache_dir` nicht explizit gesetzt ist. Die Validierung von Repository-Argumenten erfolgt weiterhin nur in `agentWatchDeps`. Der normale Repository-Modus bleibt unverändert. Bei expliziter Konfigurationsdatei greift der Workspace-Pfad beim Laden nicht, aber der Cache könnte weiterhin vom Arbeitsverzeichnis abgeleitet werden. Der Workspace-Modus greift nur auf das Arbeitsverzeichnis zu, nicht auf den Pfad der expliziten Konfigurationsdatei. Die Watcher-Struktur erhält eine Schreib-Sperre, damit die Konfiguration und die Repository-Liste zur Laufzeit neu geladen werden können. Dazu kommen Methoden zum Aktualisieren aus der Agent-Datei und zum Hinzufügen neuer Repositories über die TUI. Die Watch-TUI erhält zwei neue Modi. `c` öffnet die Konfigurationstui und speichert Änderungen direkt in der Agent-Datei. `a` fragt nach einer URL und fügt das Repository hinzu. Beide Modi laufen über ein gemeinsames Modell, um Konflikte mit dem alternativen Screen zu vermeiden. Ich plane, `RunConfigT` mit einem neuen Options-Parameter zu refactoren. Damit lässt sich der Speicherort und eine benutzerdefinierte Speicherfunktion steuern. Die Watch-TUI nutzt diese Option, um die Konfiguration direkt an den Watcher anzuhängen und die Datei zu speichern. Dazu prüfe ich zunächst den bestehenden Speichermechanismus und die Logik für Repository-Vorschläge.

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

Author

Owner

Copy link

💭 Agent progress

Eine saubere Architektur ist für die Implementierung nötig.

Die Architektur umfasst sechs Dateien. Ein neuer workspace.go erkennt den Arbeitsordner. agentfile.go und cmd/agent.go passen Suchpfade und Konfigurationspfad an. watcher_reload.go aktualisiert Repositories. Die TUI-Dateien erhalten einen Config-Modus und Callbacks.

Die Config-TUI wird als Overlay im bestehenden Bubbletea-Programm eingebettet. Ein neuer Modus steuert den Übergang zur Konfiguration. Die Update-Funktion delegiert Eingaben an das Config-Overlay.

Ein WatchRuntime-Objekt übermittelt den Watcher und die Konfiguration an die TUI. Nach dem Speichern einer Config werden die Datei geschrieben, die Konfiguration neu geladen und angewendet, der Watcher aktualisiert, die Repositories synchronisiert und der Status angepasst. Die Liste der RepoWatchs muss bei Änderungen neu aufgebaut werden. Neue Bare-Repos werden automatisch angelegt.

Ein neuer ApplyRuntimeUpdate-Methoden-Block sichert die Config und die Repo-Liste im Watcher. Eine sync.RWMutex schützt diese Felder vor gleichzeitigen Lese- und Schreibzugriffen. Neue Repositories erhalten automatisch Bare-Clones. Das Hinzufügen neuer Repositories erfolgt über eine Inline-URL-Eingabe statt des vollständigen Repos-Screens.

Der Plan ist nun konkretisiert. Zuerst werden Workspace-Erkennung und Agent-Datei angepasst. Dann folgen der Watcher-Mutex und die Runtime-Aktualisierung. Die Config-TUI wird refaktoriert für Einbettung und Callbacks. Die TUI erhält die Tastatursteuerung für Dashboard und Config. Abschließend kommen Tests und Dokumentation. Beim Enter in der URL-Eingabe wird die Adresse geparst, die Repository-Liste ergänzt und der Watcher neu geladen.

💭 **Agent progress** Eine saubere Architektur ist für die Implementierung nötig. Die Architektur umfasst sechs Dateien. Ein neuer `workspace.go` erkennt den Arbeitsordner. `agentfile.go` und `cmd/agent.go` passen Suchpfade und Konfigurationspfad an. `watcher_reload.go` aktualisiert Repositories. Die TUI-Dateien erhalten einen Config-Modus und Callbacks. Die Config-TUI wird als Overlay im bestehenden Bubbletea-Programm eingebettet. Ein neuer Modus steuert den Übergang zur Konfiguration. Die Update-Funktion delegiert Eingaben an das Config-Overlay. Ein `WatchRuntime`-Objekt übermittelt den Watcher und die Konfiguration an die TUI. Nach dem Speichern einer Config werden die Datei geschrieben, die Konfiguration neu geladen und angewendet, der Watcher aktualisiert, die Repositories synchronisiert und der Status angepasst. Die Liste der RepoWatchs muss bei Änderungen neu aufgebaut werden. Neue Bare-Repos werden automatisch angelegt. Ein neuer `ApplyRuntimeUpdate`-Methoden-Block sichert die Config und die Repo-Liste im Watcher. Eine `sync.RWMutex` schützt diese Felder vor gleichzeitigen Lese- und Schreibzugriffen. Neue Repositories erhalten automatisch Bare-Clones. Das Hinzufügen neuer Repositories erfolgt über eine Inline-URL-Eingabe statt des vollständigen Repos-Screens. Der Plan ist nun konkretisiert. Zuerst werden Workspace-Erkennung und Agent-Datei angepasst. Dann folgen der Watcher-Mutex und die Runtime-Aktualisierung. Die Config-TUI wird refaktoriert für Einbettung und Callbacks. Die TUI erhält die Tastatursteuerung für Dashboard und Config. Abschließend kommen Tests und Dokumentation. Beim Enter in der URL-Eingabe wird die Adresse geparst, die Repository-Liste ergänzt und der Watcher neu geladen.

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

Author

Owner

Copy link

💭 Agent progress

Ein solider Plan steht. Die Umsetzung erfolgt schrittweise mit inkrementellen Commits.

Die Datei workspace.go wird um Hilfsfunktionen für den Workspace-Modus ergänzt. InWorkspaceMode erkennt Verzeichnisse ohne Git-Repository. WorkspaceAgentFilePath liefert den Pfad zu ./agent.yaml im aktuellen Arbeitsverzeichnis. ResolveAgentFilePath wählt den passenden Konfigurationspfad aus.

ResolveAgentFilePath prüft zuerst einen explizit übergebenen Pfad. Im Workspace-Modus greift sie auf ./agent.yaml zurück. Sonst greift sie auf das Projekt-Konfigurationsfile zurück. DefaultRepoCacheRootForWatch setzt den Cache-Root im Workspace-Modus auf das Arbeitsverzeichnis, falls keine explizite Einstellung vorliegt.

Der Standard-Cache-Root wird in buildAgentConfig gesetzt, wenn RepoCacheDir nach ApplyAgentFile leer ist. AgentFileSearchPaths ergänzt im Workspace-Modus den Pfad ./agent.yaml.

LoadAgentFile gibt bei fehlendem Konfigurationsfile einen leeren AgentFile mit dem Pfad aus ResolveAgentFilePath zurück. Das ermöglicht die Erstellung der Datei.

buildAgentConfig liest Owner und Repository nur aus der Konfiguration, wenn der Prozess außerhalb eines Git-Repositories läuft.

Der Config-Struct erhält ein neues Feld AgentConfigPath. Es speichert den Laufzeit-Pfad zur Bearbeitung von agent.yaml.

Der Watcher muss sich bei Änderungen an dieser Konfigurationsdatei neu laden.

Die Reload-Logik für die Agent-Konfiguration wird nicht in watcher_session.go verlagert. Stattdessen bleibt sie in der Kommandozeilen-Schicht, da dort der API-Client bereits verfügbar ist.

Ein watchSession-Typ wird definiert. Er speichert den Konfigurationspfad, den Watcher, die Flags, die Optionen und den API-Client. Die Methode ReloadConfig liest die Agent-Datei neu ein. Sie behält Token und andere Runtime-Werte bei. Anschließend werden Workspace-Defaults angewendet und die Repository-Watches neu aufgebaut. Der Watcher aktualisiert sich dann laufzeitgesteuert.

Die Funktion AddRepoFromURL wird zum watchSession hinzugefügt.

ApplyWorkspaceDefaults setzt den Cache-Root auf das Arbeitsverzeichnis, wenn der Prozess außerhalb eines Git-Repositories läuft und kein expliziter Pfad hinterlegt ist.

Im buildAgentConfig wird ApplyWorkspaceDefaults direkt nach ApplyAgentFile aufgerufen.

Der Watcher erhält einen sync.RWMutex. Damit lassen sich Repository-Watches und die Konfiguration während des Laufs synchronisieren.

snapshot() und ApplyRuntime() sind nun implementiert. snapshot() liest Config und Repos unter Leselock. ApplyRuntime() schreibt neue Werte unter Schreiblock und aktualisiert Status. Alle Lesezugriffe auf w.Config und w.Repos in watcher.go müssen auf diese Methoden umgestellt werden.

💭 **Agent progress** Ein solider Plan steht. Die Umsetzung erfolgt schrittweise mit inkrementellen Commits. Die Datei workspace.go wird um Hilfsfunktionen für den Workspace-Modus ergänzt. `InWorkspaceMode` erkennt Verzeichnisse ohne Git-Repository. `WorkspaceAgentFilePath` liefert den Pfad zu `./agent.yaml` im aktuellen Arbeitsverzeichnis. `ResolveAgentFilePath` wählt den passenden Konfigurationspfad aus. `ResolveAgentFilePath` prüft zuerst einen explizit übergebenen Pfad. Im Workspace-Modus greift sie auf `./agent.yaml` zurück. Sonst greift sie auf das Projekt-Konfigurationsfile zurück. `DefaultRepoCacheRootForWatch` setzt den Cache-Root im Workspace-Modus auf das Arbeitsverzeichnis, falls keine explizite Einstellung vorliegt. Der Standard-Cache-Root wird in `buildAgentConfig` gesetzt, wenn `RepoCacheDir` nach `ApplyAgentFile` leer ist. `AgentFileSearchPaths` ergänzt im Workspace-Modus den Pfad `./agent.yaml`. `LoadAgentFile` gibt bei fehlendem Konfigurationsfile einen leeren AgentFile mit dem Pfad aus `ResolveAgentFilePath` zurück. Das ermöglicht die Erstellung der Datei. `buildAgentConfig` liest Owner und Repository nur aus der Konfiguration, wenn der Prozess außerhalb eines Git-Repositories läuft. Der Config-Struct erhält ein neues Feld `AgentConfigPath`. Es speichert den Laufzeit-Pfad zur Bearbeitung von `agent.yaml`. Der Watcher muss sich bei Änderungen an dieser Konfigurationsdatei neu laden. Die Reload-Logik für die Agent-Konfiguration wird nicht in `watcher_session.go` verlagert. Stattdessen bleibt sie in der Kommandozeilen-Schicht, da dort der API-Client bereits verfügbar ist. Ein `watchSession`-Typ wird definiert. Er speichert den Konfigurationspfad, den Watcher, die Flags, die Optionen und den API-Client. Die Methode `ReloadConfig` liest die Agent-Datei neu ein. Sie behält Token und andere Runtime-Werte bei. Anschließend werden Workspace-Defaults angewendet und die Repository-Watches neu aufgebaut. Der Watcher aktualisiert sich dann laufzeitgesteuert. Die Funktion `AddRepoFromURL` wird zum `watchSession` hinzugefügt. `ApplyWorkspaceDefaults` setzt den Cache-Root auf das Arbeitsverzeichnis, wenn der Prozess außerhalb eines Git-Repositories läuft und kein expliziter Pfad hinterlegt ist. Im `buildAgentConfig` wird `ApplyWorkspaceDefaults` direkt nach `ApplyAgentFile` aufgerufen. Der `Watcher` erhält einen `sync.RWMutex`. Damit lassen sich Repository-Watches und die Konfiguration während des Laufs synchronisieren. `snapshot()` und `ApplyRuntime()` sind nun implementiert. `snapshot()` liest Config und Repos unter Leselock. `ApplyRuntime()` schreibt neue Werte unter Schreiblock und aktualisiert Status. Alle Lesezugriffe auf `w.Config` und `w.Repos` in `watcher.go` müssen auf diese Methoden umgestellt werden.

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

Author

Owner

Copy link

💭 Agent progress

Viele Stellen greifen auf Config und Repos zu. Mutex könnte überall nötig sein. Alternativ bietet sich atomic.Value oder ein einfacherer Ansatz an.

Ein ConfigHolder mit RWMutex wäre sauber, aber alle Dateien müssen dafür geändert werden. Stattdessen wird ein Channel-Reload zwischen Poll-Zyklen bevorzugt. Die Config und die Repos werden über einen Kanal aktualisiert, sobald der nächste Poll beginnt.

Der Kanal-Reload wird in pollOnce und der Run-Schleife vor dem Warten abgefragt. applyPendingReload übernimmt die Aktualisierung von Config, Repos und Status. ApplyRuntime blockiert bis zur Anwendung. Ein einzige Go-Routine für den Zustand wäre noch einfacher, aber deutlich mehr Refactoring.

Statt eines globalen Channels wird ein pragmatischerer Ansatz gewählt. Ein lokaler Mutex in pendingReload speichert die neue Konfiguration und die Repos. RequestReload schreibt sie in diesen Puffer. applyPendingReload tauscht den Zustand beim Start jedes pollOnce aus. Der Mutex ist nur an den Einstiegspunkten nötig. Innerhalb eines Poll-Zyklus bleibt die Config stabil.

Die Implementierung setzt einen lokalen reloadMu im Watcher. ScheduleReload speichert die neue Konfiguration und die Repos in pendingCfg und pendingRepos. Das Update erfolgt erst am Poll-Start. Intervalle und Limits aktualisieren sich dadurch auch beim nächsten Warten.

applyPendingReload kopiert die neuen Repos und tauscht den Zustand aus. Es wird vor jedem Poll und in der Run-Schleife aufgerufen. WatchStatus.SetConfig aktualisiert den Status mit einem lokalen Mutex.

runAgentWatch wird angepasst, um den Konfigurationspfad aufzulösen und an RunTUI zu übergeben. Dafür wird eine neue Hilfsfunktion ResolveConfigLoadPath eingeführt. Sie prüft explizite Pfade und durchsucht die Standard-Suchpfade nach einer existierenden agent.yaml.

ResolveAgentFilePath prüft explizite Pfade und setzt bei Workspace-Modus den aktuellen Ordner als Root. Sonst greift es auf den Projekt-Pfad zurück.

Die Config-TUI erhält ein embedded-Flag. Im eingebetteten Modus führt q zum Zurückgehen statt zum Beenden.

Die Config-TUI erhält eine neue Option ConfigTUIOptions mit Feldern für Embedded, OnSaved und SaveLabel. Ein onSaved-Callback wird nach dem Speichern aufgerufen. Im eingebetteten Modus führt Enter nach dem Speichern zum Dashboard zurück. Das Flag embedded steuert, ob q beendet oder zurückkehrt.

Statt eines Callbacks nutzt die Config-TUI ein eigenes Nachrichtentyp configTUIMsg. Im eingebetteten Modus sendet sie diese Nachricht, wenn das Menü oder das Speichern beendet wird. Die Haupt-TUI verarbeitet sie im Update-Loop: nach dem Speichern kehrt sie ins Dashboard zurück und ruft Reload auf, um die Konfiguration neu zu laden.

Ein WatchControls-Interface wird an RunTUI übergeben. Es enthält ConfigPath, Flags, Reload, AddRepoURL und LoadFile. Reload speichert die Datei und wendet die Änderungen an. AddRepoURL lädt die Datei, fügt eine Repository-URL hinzu, speichert und wendet an. Diese Methoden werden als watchSession-Methoden in cmd/agent.go implementiert. Die TUI erhält einen neuen Overlay-Modus tuiModeAddRepo für das Hinzufügen neuer Repositories.

Im Dashboard-Overlay wird eine HTTPS-URL validiert und per AddRepoURL gespeichert. Drücken von a öffnet den Hinzufügen-Overlay aus dem Dashboard oder der Config-TUI. RunConfigTUI nutzt künftig ResolveAgentFilePath und zeigt im Workspace-Modus eine passende Hilfstext an. Dazu werden Tests für Workspace-Modus, Suchpfade, Defaults, Pfad-Auflösung, Reload und eingebettete Speicher-Callbacks ergänzt.

Eine neue Hilfsfunktion ensureBareRepos kloniert neue Repositories sofort beim Hinzufügen. Die Pipeline übernimmt das später automatisch. Die TUI-Tests werden ebenfalls geprüft.

Ein leerer Workspace ohne agent.yaml oder Repositories scheitert aktuell an der Validierung. Die Anforderung erwartet jedoch einen Start ohne vorhandene Konfiguration. Die Lösung muss entweder eine minimale Default-Konfiguration erzeugen oder den Start ohne explizite Repos zulassen.

Eine leere Workspace-Startseite ohne agent.yaml würde die Validierung blockieren. Die Option, den Watcher trotzdem zu starten und die Konfiguration später per c zu erstellen, wurde erwogen. Das könnte aber Scope-Creep sein.

Die Anforderung erwartet, dass forge agent watch im Workspace-Modus ohne vorhandene agent.yaml startet und der Nutzer die Konfiguration später per c anlegt. Die Validierung muss daher in diesem Modus mit Platzhaltern oder Default-Werten arbeiten, damit der Watcher nicht sofort fehlschlägt.

Die Anforderung erfordert wohl keine leere Workspace-Startseite. Der Nutzer muss bereits eine gültige agent.yaml mit mindestens einem Repository besitzen, damit der Watcher startet. Die Tastatursteuerung c dient dann nur noch zur Anpassung der bestehenden Konfiguration.

Der Nutzer erstellt die Konfiguration zuerst mit forge agent config im Workspace-Verzeichnis. Danach startet er forge agent watch. Die Runtime-Taste c editiert die bestehende Konfiguration. Die Acceptance-Anforderung erwartet keinen leeren Start ohne vorherige Konfiguration.

Im Workspace-Modus überspringe ich resolveRepoArg ohne -R-Flag. Die Owner- und Repo-Namen kommen stattdessen aus den Repos in der Config. Nun beginne ich mit der Implementierung.
Ich setze das schrittweise um: zuerst Workspace-Erkennung und Config-Pfade, danach TUI-Hotkeys und Runtime-Reload.

💭 **Agent progress** Viele Stellen greifen auf Config und Repos zu. Mutex könnte überall nötig sein. Alternativ bietet sich atomic.Value oder ein einfacherer Ansatz an. Ein ConfigHolder mit RWMutex wäre sauber, aber alle Dateien müssen dafür geändert werden. Stattdessen wird ein Channel-Reload zwischen Poll-Zyklen bevorzugt. Die Config und die Repos werden über einen Kanal aktualisiert, sobald der nächste Poll beginnt. Der Kanal-Reload wird in `pollOnce` und der `Run`-Schleife vor dem Warten abgefragt. `applyPendingReload` übernimmt die Aktualisierung von Config, Repos und Status. `ApplyRuntime` blockiert bis zur Anwendung. Ein einzige Go-Routine für den Zustand wäre noch einfacher, aber deutlich mehr Refactoring. Statt eines globalen Channels wird ein pragmatischerer Ansatz gewählt. Ein lokaler Mutex in `pendingReload` speichert die neue Konfiguration und die Repos. `RequestReload` schreibt sie in diesen Puffer. `applyPendingReload` tauscht den Zustand beim Start jedes `pollOnce` aus. Der Mutex ist nur an den Einstiegspunkten nötig. Innerhalb eines Poll-Zyklus bleibt die Config stabil. Die Implementierung setzt einen lokalen `reloadMu` im `Watcher`. `ScheduleReload` speichert die neue Konfiguration und die Repos in `pendingCfg` und `pendingRepos`. Das Update erfolgt erst am Poll-Start. Intervalle und Limits aktualisieren sich dadurch auch beim nächsten Warten. `applyPendingReload` kopiert die neuen Repos und tauscht den Zustand aus. Es wird vor jedem Poll und in der Run-Schleife aufgerufen. `WatchStatus.SetConfig` aktualisiert den Status mit einem lokalen Mutex. `runAgentWatch` wird angepasst, um den Konfigurationspfad aufzulösen und an `RunTUI` zu übergeben. Dafür wird eine neue Hilfsfunktion `ResolveConfigLoadPath` eingeführt. Sie prüft explizite Pfade und durchsucht die Standard-Suchpfade nach einer existierenden `agent.yaml`. `ResolveAgentFilePath` prüft explizite Pfade und setzt bei Workspace-Modus den aktuellen Ordner als Root. Sonst greift es auf den Projekt-Pfad zurück. Die Config-TUI erhält ein `embedded`-Flag. Im eingebetteten Modus führt `q` zum Zurückgehen statt zum Beenden. Die Config-TUI erhält eine neue Option `ConfigTUIOptions` mit Feldern für `Embedded`, `OnSaved` und `SaveLabel`. Ein `onSaved`-Callback wird nach dem Speichern aufgerufen. Im eingebetteten Modus führt Enter nach dem Speichern zum Dashboard zurück. Das Flag `embedded` steuert, ob `q` beendet oder zurückkehrt. Statt eines Callbacks nutzt die Config-TUI ein eigenes Nachrichtentyp `configTUIMsg`. Im eingebetteten Modus sendet sie diese Nachricht, wenn das Menü oder das Speichern beendet wird. Die Haupt-TUI verarbeitet sie im `Update`-Loop: nach dem Speichern kehrt sie ins Dashboard zurück und ruft `Reload` auf, um die Konfiguration neu zu laden. Ein `WatchControls`-Interface wird an `RunTUI` übergeben. Es enthält `ConfigPath`, `Flags`, `Reload`, `AddRepoURL` und `LoadFile`. `Reload` speichert die Datei und wendet die Änderungen an. `AddRepoURL` lädt die Datei, fügt eine Repository-URL hinzu, speichert und wendet an. Diese Methoden werden als `watchSession`-Methoden in `cmd/agent.go` implementiert. Die TUI erhält einen neuen Overlay-Modus `tuiModeAddRepo` für das Hinzufügen neuer Repositories. Im Dashboard-Overlay wird eine HTTPS-URL validiert und per `AddRepoURL` gespeichert. Drücken von `a` öffnet den Hinzufügen-Overlay aus dem Dashboard oder der Config-TUI. `RunConfigTUI` nutzt künftig `ResolveAgentFilePath` und zeigt im Workspace-Modus eine passende Hilfstext an. Dazu werden Tests für Workspace-Modus, Suchpfade, Defaults, Pfad-Auflösung, Reload und eingebettete Speicher-Callbacks ergänzt. Eine neue Hilfsfunktion `ensureBareRepos` kloniert neue Repositories sofort beim Hinzufügen. Die Pipeline übernimmt das später automatisch. Die TUI-Tests werden ebenfalls geprüft. Ein leerer Workspace ohne `agent.yaml` oder Repositories scheitert aktuell an der Validierung. Die Anforderung erwartet jedoch einen Start ohne vorhandene Konfiguration. Die Lösung muss entweder eine minimale Default-Konfiguration erzeugen oder den Start ohne explizite Repos zulassen. Eine leere Workspace-Startseite ohne `agent.yaml` würde die Validierung blockieren. Die Option, den Watcher trotzdem zu starten und die Konfiguration später per `c` zu erstellen, wurde erwogen. Das könnte aber Scope-Creep sein. Die Anforderung erwartet, dass `forge agent watch` im Workspace-Modus ohne vorhandene `agent.yaml` startet und der Nutzer die Konfiguration später per `c` anlegt. Die Validierung muss daher in diesem Modus mit Platzhaltern oder Default-Werten arbeiten, damit der Watcher nicht sofort fehlschlägt. Die Anforderung erfordert wohl keine leere Workspace-Startseite. Der Nutzer muss bereits eine gültige `agent.yaml` mit mindestens einem Repository besitzen, damit der Watcher startet. Die Tastatursteuerung `c` dient dann nur noch zur Anpassung der bestehenden Konfiguration. Der Nutzer erstellt die Konfiguration zuerst mit `forge agent config` im Workspace-Verzeichnis. Danach startet er `forge agent watch`. Die Runtime-Taste `c` editiert die bestehende Konfiguration. Die Acceptance-Anforderung erwartet keinen leeren Start ohne vorherige Konfiguration. Im Workspace-Modus überspringe ich `resolveRepoArg` ohne `-R`-Flag. Die Owner- und Repo-Namen kommen stattdessen aus den Repos in der Config. Nun beginne ich mit der Implementierung. Ich setze das schrittweise um: zuerst Workspace-Erkennung und Config-Pfade, danach TUI-Hotkeys und Runtime-Reload.

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

Author

Owner

Copy link

💭 Agent progress

Workspace-Tests und Watcher-Reload-Unterstützung werden ergänzt.

ConfigTUIOptions wird ergänzt. config_tui, tui und cmd/agent.go werden aktualisiert.

💭 **Agent progress** Workspace-Tests und Watcher-Reload-Unterstützung werden ergänzt. ConfigTUIOptions wird ergänzt. config_tui, tui und cmd/agent.go werden aktualisiert.

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

Author

Owner

Copy link

💭 Agent progress

Ich erstelle nun die watch_controls.

Ich plane die Runtime-Konfigurationssteuerung für die Watch-TUI. Die WatchRuntime-Struktur verbindet Live-Änderungen mit dem laufenden Watcher. Ich passe config_tui, tui.go und cmd/agent.go an. WatchControls könnte im Agent-Paket oder direkt in cmd liegen.

Die Callback-Funktionen für ApplyFile, LoadFile und AddRepo sollen aus der cmd-Schicht kommen. Ich prüfe eine komplexere WatchRuntime-Struktur im Agent-Paket gegen eine einfachere WatchConfigurator-Lösung mit Forge-Client-Fabrik.

Der WatchConfigurator erhält die Methoden LoadFile, ApplyFile und AddRepoURL. ApplyFile validiert die Datei, speichert sie, übernimmt den Token aus der aktuellen Konfiguration, wendet die Änderungen an, baut die Repos neu auf und scheduled einen Reload.

AddRepoURL lädt die Datei, parst die URL, ergänzt sie und ruft ApplyFile auf. BuildRepos bleibt in cmd, da der Forge-Client nötig ist. Ich lege watch_config.go im Agent-Paket an.

💭 **Agent progress** Ich erstelle nun die watch_controls. Ich plane die Runtime-Konfigurationssteuerung für die Watch-TUI. Die WatchRuntime-Struktur verbindet Live-Änderungen mit dem laufenden Watcher. Ich passe config_tui, tui.go und cmd/agent.go an. WatchControls könnte im Agent-Paket oder direkt in cmd liegen. Die Callback-Funktionen für ApplyFile, LoadFile und AddRepo sollen aus der cmd-Schicht kommen. Ich prüfe eine komplexere WatchRuntime-Struktur im Agent-Paket gegen eine einfachere WatchConfigurator-Lösung mit Forge-Client-Fabrik. Der WatchConfigurator erhält die Methoden LoadFile, ApplyFile und AddRepoURL. ApplyFile validiert die Datei, speichert sie, übernimmt den Token aus der aktuellen Konfiguration, wendet die Änderungen an, baut die Repos neu auf und scheduled einen Reload. AddRepoURL lädt die Datei, parst die URL, ergänzt sie und ruft ApplyFile auf. BuildRepos bleibt in cmd, da der Forge-Client nötig ist. Ich lege watch_config.go im Agent-Paket an.

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

Author

Owner

Copy link

💭 Agent progress

config_tui.go wird für die Embedding-Support-Anpassungen aktualisiert.

Ein ConfigTUIOptions-Struct mit Eingebettungsflag, Speicher-Callback und Label wird ergänzt. Die TUI-Model-Funktionen Update und View werden für den Embedding-Delegation-Case angepasst.

Die Tastatursteuerung für eingebettete Konfigurationen wird angepasst. q und ctrl+c führen im Eingebetteten Modus zurück zum Dashboard statt die Anwendung zu beenden. Die Menü-Steuerung liefert dafür eine benutzerdefinierte Nachricht statt tea.Quit.

Eine Hilfsfunktion configCloseCmd erzeugt die benutzerdefinierte Nachricht für den Eingebetteten Modus. Nach dem Speichern ruft handleConfirmKey den Callback onSaved auf. Der Callback sollte die Datei speichern. Die Reihenfolge zwischen direktem Speichern und Callback-Aufruf muss noch geklärt werden.

Im Bestätigungsschritt wird bei gesetztem Callback onSaved der direkte Dateispeichervorgang übersprungen. Der Eingebettete Modus schließt die Overlay-Steuerung stattdessen über eine eigene Nachricht ab.

Der Update-Return-Typ von config_tui.go wird angepasst. Die Funktion liefert nun (tea.Model, tea.Cmd) zurück. Das ermöglicht es, im Eingebetteten Modus eine benutzerdefinierte Schließ-Nachricht statt tea.Quit auszulösen. Die Standalone-RunConfigTUI bleibt unverändert.

Die Update-Funktion in config_tui.go wird konkret umgebaut. Sie prüft tea.KeyMsg und delegiert an m.handleKey. Diese Funktion liefert nun (close bool, saved bool) zurück. Im Eingebetteten Modus erzeugt Update eine configOverlayDoneMsg mit dem gesetzten saved-Flag. Im Standalone-Modus bleibt tea.Quit erhalten. Der Menü-Bezug ohne Speichern und ctrl+c im Eingebetteten Modus setzen close auf wahr und saved auf falsch. Nach erfolgreichem Speichern im Standalone-Modus wird die Anwendung beendet.

Nach erfolgreichem Speichern im Eingebetteten Modus schließt die Overlay-Steuerung mit close=true und saved=true. Der Ablauf von handleKey für den Nachrichtenbildschirm wird noch einmal geprüft.
Jetzt passe ich die Config-TUI für Einbettung und die Watch-Cmd-Schicht an.

💭 **Agent progress** config_tui.go wird für die Embedding-Support-Anpassungen aktualisiert. Ein ConfigTUIOptions-Struct mit Eingebettungsflag, Speicher-Callback und Label wird ergänzt. Die TUI-Model-Funktionen Update und View werden für den Embedding-Delegation-Case angepasst. Die Tastatursteuerung für eingebettete Konfigurationen wird angepasst. `q` und `ctrl+c` führen im Eingebetteten Modus zurück zum Dashboard statt die Anwendung zu beenden. Die Menü-Steuerung liefert dafür eine benutzerdefinierte Nachricht statt `tea.Quit`. Eine Hilfsfunktion `configCloseCmd` erzeugt die benutzerdefinierte Nachricht für den Eingebetteten Modus. Nach dem Speichern ruft `handleConfirmKey` den Callback `onSaved` auf. Der Callback sollte die Datei speichern. Die Reihenfolge zwischen direktem Speichern und Callback-Aufruf muss noch geklärt werden. Im Bestätigungsschritt wird bei gesetztem Callback `onSaved` der direkte Dateispeichervorgang übersprungen. Der Eingebettete Modus schließt die Overlay-Steuerung stattdessen über eine eigene Nachricht ab. Der Update-Return-Typ von config_tui.go wird angepasst. Die Funktion liefert nun `(tea.Model, tea.Cmd)` zurück. Das ermöglicht es, im Eingebetteten Modus eine benutzerdefinierte Schließ-Nachricht statt `tea.Quit` auszulösen. Die Standalone-RunConfigTUI bleibt unverändert. Die `Update`-Funktion in `config_tui.go` wird konkret umgebaut. Sie prüft `tea.KeyMsg` und delegiert an `m.handleKey`. Diese Funktion liefert nun `(close bool, saved bool)` zurück. Im Eingebetteten Modus erzeugt `Update` eine `configOverlayDoneMsg` mit dem gesetzten `saved`-Flag. Im Standalone-Modus bleibt `tea.Quit` erhalten. Der Menü-Bezug ohne Speichern und `ctrl+c` im Eingebetteten Modus setzen `close` auf wahr und `saved` auf falsch. Nach erfolgreichem Speichern im Standalone-Modus wird die Anwendung beendet. Nach erfolgreichem Speichern im Eingebetteten Modus schließt die Overlay-Steuerung mit `close=true` und `saved=true`. Der Ablauf von `handleKey` für den Nachrichtenbildschirm wird noch einmal geprüft. Jetzt passe ich die Config-TUI für Einbettung und die Watch-Cmd-Schicht an.

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

Author

Owner

Copy link

💭 Agent progress

Ich führe umfassende Änderungen an config_tui.go durch.

💭 **Agent progress** Ich führe umfassende Änderungen an config_tui.go durch.

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

Author

Owner

Copy link

💭 Agent progress

Die restlichen handle*Key-Funktionen müssen ebenfalls (bool, bool) zurückgeben.

Ich lese den aktuellen Stand der betroffenen Funktionen.

💭 **Agent progress** Die restlichen handle*Key-Funktionen müssen ebenfalls (bool, bool) zurückgeben. Ich lese den aktuellen Stand der betroffenen Funktionen.

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

Author

Owner

Copy link

💭 Agent progress

Die Handler-Funktionen müssen auf (bool, bool) korrigiert werden. Die Return-Anweisungen in handleMenuKey sind defekt.

Eine umfassende Ersetzung wird durchgeführt.

💭 **Agent progress** Die Handler-Funktionen müssen auf `(bool, bool)` korrigiert werden. Die Return-Anweisungen in `handleMenuKey` sind defekt. Eine umfassende Ersetzung wird durchgeführt.

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

Author

Owner

Copy link

💭 Agent progress

tui.go wird für die Tastenkombinationen c und a aktualisiert. RunTUI wird angepasst, um WatchConfigurator zu akzeptieren.

cmd/agent.go wird ebenfalls aktualisiert. Die Tastenkombination a im Dashboard fragt nach einer HTTPS-URL zur Hinzufügung neuer Repositories. Der Repositories-Bildschirm behält seine bestehende Funktion bei.

💭 **Agent progress** tui.go wird für die Tastenkombinationen c und a aktualisiert. RunTUI wird angepasst, um WatchConfigurator zu akzeptieren. cmd/agent.go wird ebenfalls aktualisiert. Die Tastenkombination `a` im Dashboard fragt nach einer HTTPS-URL zur Hinzufügung neuer Repositories. Der Repositories-Bildschirm behält seine bestehende Funktion bei.

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

Author

Owner

Copy link

💭 Agent progress

Die TUI-Anpassungen für den neuen Workspace-Modus sind geplant: Overlay-Funktionen, Repository-Schlüssel-Handling, aktualisierte Ansicht und Hilfslinie.

Der Pointer-Fehler im Config-Model wird behoben: da Update einen Wert-Receiver nutzt, muss der Rückgabewert explizit in einen Zeiger umgewandelt werden. Hilfsfunktionen werden am Ende von tui.go ergänzt und die View aktualisiert.

💭 **Agent progress** Die TUI-Anpassungen für den neuen Workspace-Modus sind geplant: Overlay-Funktionen, Repository-Schlüssel-Handling, aktualisierte Ansicht und Hilfslinie. Der Pointer-Fehler im Config-Model wird behoben: da Update einen Wert-Receiver nutzt, muss der Rückgabewert explizit in einen Zeiger umgewandelt werden. Hilfsfunktionen werden am Ende von tui.go ergänzt und die View aktualisiert.

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

Author

Owner

Copy link

💭 Agent progress

Die TUI-Datei erhält drei neue Funktionen am Ende: openConfigOverlay, handleAddRepoKey und viewAddRepo.

handleAddRepoKey steuert die Eingabe für das Hinzufügen von Repos. Escape bricht den Modus ab. Enter speichert die URL asynchron und sendet eine addRepoResultMsg. Ctrl+C und q beenden ebenfalls.

Der Wert-Receiver in Update verhindert, dass Änderungen an m.addRepoBuf dauerhaft bleiben. Die Funktion muss daher auf einen Zeiger-Receiver umgestellt werden.

Go übergibt den Zeiger automatisch, wenn ein Pointer-Receiver aufgerufen wird. Das bestehende selectNextRun mit Zeiger-Receiver funktioniert deshalb korrekt. handleAddRepoKey muss daher ebenfalls auf einen Zeiger-Receiver umgestellt werden.

In Update wird der Fall addRepoResultMsg abgefangen. Bei einem Fehler wird er in addRepoErr gespeichert. Erfolg leitet zurück zum Dashboard und löscht die Eingabezeile.

Der context.Context muss in tuiModel gespeichert werden. Er wird von RunTUI an die TUI übergeben und an AddRepoURL weitergereicht.

openConfigOverlay lädt die Agent-Konfiguration aus dem aktuellen Arbeitsverzeichnis. Sie öffnet die Overlay-TUI mit eingebettetem Modus und dem Speicher-Label „Save and apply“. Ein fehlendes Repository oder ein Ladefehler bricht den Vorgang ab.

Der OnSaved-Callback in openConfigOverlay greift auf m.watchCfg zu. ApplyAgentFile benötigt aber einen Context. Der Context wird daher direkt in tuiModel gespeichert und von RunTUI übergeben.

💭 **Agent progress** Die TUI-Datei erhält drei neue Funktionen am Ende: openConfigOverlay, handleAddRepoKey und viewAddRepo. handleAddRepoKey steuert die Eingabe für das Hinzufügen von Repos. Escape bricht den Modus ab. Enter speichert die URL asynchron und sendet eine addRepoResultMsg. Ctrl+C und q beenden ebenfalls. Der Wert-Receiver in `Update` verhindert, dass Änderungen an `m.addRepoBuf` dauerhaft bleiben. Die Funktion muss daher auf einen Zeiger-Receiver umgestellt werden. Go übergibt den Zeiger automatisch, wenn ein Pointer-Receiver aufgerufen wird. Das bestehende `selectNextRun` mit Zeiger-Receiver funktioniert deshalb korrekt. `handleAddRepoKey` muss daher ebenfalls auf einen Zeiger-Receiver umgestellt werden. In `Update` wird der Fall `addRepoResultMsg` abgefangen. Bei einem Fehler wird er in `addRepoErr` gespeichert. Erfolg leitet zurück zum Dashboard und löscht die Eingabezeile. Der `context.Context` muss in `tuiModel` gespeichert werden. Er wird von `RunTUI` an die TUI übergeben und an `AddRepoURL` weitergereicht. `openConfigOverlay` lädt die Agent-Konfiguration aus dem aktuellen Arbeitsverzeichnis. Sie öffnet die Overlay-TUI mit eingebettetem Modus und dem Speicher-Label „Save and apply“. Ein fehlendes Repository oder ein Ladefehler bricht den Vorgang ab. Der `OnSaved`-Callback in `openConfigOverlay` greift auf `m.watchCfg` zu. `ApplyAgentFile` benötigt aber einen Context. Der Context wird daher direkt in `tuiModel` gespeichert und von `RunTUI` übergeben.

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

Author

Owner

Copy link

💭 Agent progress

Hilfsfunktionen sollen am Ende von tui.go ergänzt werden.

Ich lese das Ende der Datei.

💭 **Agent progress** Hilfsfunktionen sollen am Ende von tui.go ergänzt werden. Ich lese das Ende der Datei.

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

Author

Owner

Copy link

💭 Agent progress

Hilfsfunktionen werden am Ende von tui.go ergänzt.

💭 **Agent progress** Hilfsfunktionen werden am Ende von tui.go ergänzt.

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

Author

Owner

Copy link

💭 Agent progress

cmd/agent.go wird für den Workspace-Modus aktualisiert. Dazu gehören buildAgentConfig, runAgentWatch mit WatchConfigurator und die Hilfstexte.

Die TUI-Tests für RunTUI und newTUIModel werden ebenfalls korrigiert. buildAgentConfig erlaubt fehlende Repository-Argumente im Workspace-Modus. Nach ApplyAgentFile werden Standardwerte für den Workspace gesetzt. Der Config-Pfad wird an runAgentWatch übergeben. Ohne Owner oder Repo aus dem CWD kommen Targets nur aus der Config. Die Funktion buildRepoWatches wird extrahiert und von agentWatchDeps sowie WatchConfigurator genutzt.

Die EnsureRepos-Funktion wird ergänzt, damit beim Reload die Bare-Repos automatisch angelegt werden. Anschließend folgt eine umfassende Aktualisierung von cmd/agent.go.

💭 **Agent progress** cmd/agent.go wird für den Workspace-Modus aktualisiert. Dazu gehören buildAgentConfig, runAgentWatch mit WatchConfigurator und die Hilfstexte. Die TUI-Tests für RunTUI und newTUIModel werden ebenfalls korrigiert. buildAgentConfig erlaubt fehlende Repository-Argumente im Workspace-Modus. Nach ApplyAgentFile werden Standardwerte für den Workspace gesetzt. Der Config-Pfad wird an runAgentWatch übergeben. Ohne Owner oder Repo aus dem CWD kommen Targets nur aus der Config. Die Funktion buildRepoWatches wird extrahiert und von agentWatchDeps sowie WatchConfigurator genutzt. Die EnsureRepos-Funktion wird ergänzt, damit beim Reload die Bare-Repos automatisch angelegt werden. Anschließend folgt eine umfassende Aktualisierung von cmd/agent.go.

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

Author

Owner

Copy link

💭 Agent progress

Ich muss den tatsächlichen Typ des Forge-Clients klären, da ich bisher eine generische Schnittstelle verwendet habe.

Ich suche im Code nach der konkreten Forge-Struktur und dem Client-Typ.

💭 **Agent progress** Ich muss den tatsächlichen Typ des Forge-Clients klären, da ich bisher eine generische Schnittstelle verwendet habe. Ich suche im Code nach der konkreten Forge-Struktur und dem Client-Typ.

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

Author

Owner

Copy link

💭 Agent progress

Der Code sollte *api.Client statt eines Interface verwenden.

buildRepoWatches wird auf den korrekten Typ aus dem api-Paket umgestellt.

💭 **Agent progress** Der Code sollte `*api.Client` statt eines Interface verwenden. `buildRepoWatches` wird auf den korrekten Typ aus dem `api`-Paket umgestellt.

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

Author

Owner

Copy link

💭 Agent progress

Der api-Paket-Import muss ergänzt und die Signatur von buildRepoWatches korrigiert werden.

💭 **Agent progress** Der api-Paket-Import muss ergänzt und die Signatur von buildRepoWatches korrigiert werden.

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

Author

Owner

Copy link

💭 Agent progress

runAgentWatch wird aktualisiert, um WatchConfigurator und den Konfigurationspfad zu übergeben.

Die Flags und der Konfigurationspfad müssen ebenfalls an runAgentWatch übergeben werden. Die sauberste Lösung ist, dass buildAgentConfig den agentFileFlags zurückgibt.

Der Ansatz ändert sich. Statt buildAgentConfig zu erweitern, erhält runAgentWatch direkt die Konfiguration, den UI-Handler, den Konfigurationspfad und die Agent-Datei-Flags. Die Flag-Erstellung wird in eine separate Hilfsfunktion ausgelagert.

buildAgentConfig liefert nun zusätzlich die AgentFileFlags zurück. Alle Aufrufer müssen angepasst werden.

💭 **Agent progress** runAgentWatch wird aktualisiert, um WatchConfigurator und den Konfigurationspfad zu übergeben. Die Flags und der Konfigurationspfad müssen ebenfalls an runAgentWatch übergeben werden. Die sauberste Lösung ist, dass buildAgentConfig den agentFileFlags zurückgibt. Der Ansatz ändert sich. Statt buildAgentConfig zu erweitern, erhält runAgentWatch direkt die Konfiguration, den UI-Handler, den Konfigurationspfad und die Agent-Datei-Flags. Die Flag-Erstellung wird in eine separate Hilfsfunktion ausgelagert. buildAgentConfig liefert nun zusätzlich die AgentFileFlags zurück. Alle Aufrufer müssen angepasst werden.

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

Author

Owner

Copy link

💭 Agent progress

Die Rückgabewerte in buildAgentConfig werden korrigiert. Der Fehler usageError wird dort ebenfalls behoben.

💭 **Agent progress** Die Rückgabewerte in `buildAgentConfig` werden korrigiert. Der Fehler `usageError` wird dort ebenfalls behoben.

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

Author

Owner

Copy link

💭 Agent progress

Die Zeilen 285 bis 291 werden korrigiert. Die Funktion gibt nun cfg, flags und nil zurück. Der usageError in Zeile 285 wird behoben.

💭 **Agent progress** Die Zeilen 285 bis 291 werden korrigiert. Die Funktion gibt nun cfg, flags und nil zurück. Der usageError in Zeile 285 wird behoben.

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

Author

Owner

Copy link

💭 Agent progress

Die Testdatei muss für die neuen Rückgabewerte von buildAgentConfig angepasst werden. Die Verwendung von _, err := ist hier korrekt.

Der letzte Test nutzt noch cfg, err : - need to fix that.= und muss korrigiert werden.

💭 **Agent progress** Die Testdatei muss für die neuen Rückgabewerte von `buildAgentConfig` angepasst werden. Die Verwendung von `_, err :=` ist hier korrekt. Der letzte Test nutzt noch `cfg, err : - need to fix that.=` und muss korrigiert werden.

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

Author

Owner

Copy link

💭 Agent progress

Die TUI-Tests werden angepasst. watchConfigurator und context werden an newTUIModel übergeben.

💭 **Agent progress** Die TUI-Tests werden angepasst. `watchConfigurator` und `context` werden an `newTUIModel` übergeben.

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

Author

Owner

Copy link

💭 Agent progress

Der Aufruf von RunTUI muss um einen nil-Wert für WatchConfigurator ergänzt werden.

💭 **Agent progress** Der Aufruf von RunTUI muss um einen nil-Wert für WatchConfigurator ergänzt werden.

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

Author

Owner

Copy link

💭 Agent progress

Möglicherweise gibt es noch eine weitere newTUIModel-Definition in tui_repro_test mit anderer Einrückung.

💭 **Agent progress** Möglicherweise gibt es noch eine weitere `newTUIModel`-Definition in `tui_repro_test` mit anderer Einrückung.

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

Author

Owner

Copy link

💭 Agent progress

TestWatchConfiguratorApplyAgentFile wurde korrigiert. SaveAgentFile erstellt den Elternordner selbst. Der Pfad enthält den vollständigen Pfad, daher ist kein chdir nötig.

Tests werden ausgeführt und die Wiki-Dokumentation aktualisiert. Für TestInWospaceModeInsideRepo reicht ein einfaches .git-Verzeichnis nicht aus. Die Funktion erkennt den Repository-Wurzel mit git rev-parse --show-toplevel. Ein ordentlicher Git-Repository-Init ist erforderlich.

💭 **Agent progress** TestWatchConfiguratorApplyAgentFile wurde korrigiert. SaveAgentFile erstellt den Elternordner selbst. Der Pfad enthält den vollständigen Pfad, daher ist kein chdir nötig. Tests werden ausgeführt und die Wiki-Dokumentation aktualisiert. Für TestInWospaceModeInsideRepo reicht ein einfaches `.git`-Verzeichnis nicht aus. Die Funktion erkennt den Repository-Wurzel mit `git rev-parse --show-toplevel`. Ein ordentlicher Git-Repository-Init ist erforderlich.

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

Author

Owner

Copy link

💭 Agent progress

Die Zuweisungen in agent_test.go und der Workspace-Test werden korrigiert. Für den Test innerhalb eines Repositories wird git init verwendet.

💭 **Agent progress** Die Zuweisungen in agent_test.go und der Workspace-Test werden korrigiert. Für den Test innerhalb eines Repositories wird git init verwendet.

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

Author

Owner

Copy link

💭 Agent progress

replace_all found only one occurrence of "agent_test" despite three matches being expected.

Reading agent_test.go to investigate the missing match.

💭 **Agent progress** replace_all found only one occurrence of "agent_test" despite three matches being expected. Reading agent_test.go to investigate the missing match.

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

Author

Owner

Copy link

💭 Agent progress

Lines 63 and 68 are being fixed to use _, _, err :=.

💭 **Agent progress** Lines 63 and 68 are being fixed to use `_, _, err :=`.

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

Author

Owner

Copy link

💭 Agent progress

Der ungenutzte os-Import wurde aus workspace_test.go entfernt.

💭 **Agent progress** Der ungenutzte `os`-Import wurde aus `workspace_test.go` entfernt.

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

Author

Owner

Copy link

💭 Agent progress

Alle Tests bestehen. Nun werden die Wiki-Dokumentation und README-Hilfstexte aktualisiert.

Die Agent-Watch.md wird um einen Abschnitt zum Workspace-Modus und den Hotkeys c/a ergänzt. Anschließend erfolgt ein inkrementeller Commit und Push.
Jetzt aktualisiere ich die Wiki-Dokumentation und die Help-Texte.

💭 **Agent progress** Alle Tests bestehen. Nun werden die Wiki-Dokumentation und README-Hilfstexte aktualisiert. Die Agent-Watch.md wird um einen Abschnitt zum Workspace-Modus und den Hotkeys c/a ergänzt. Anschließend erfolgt ein inkrementeller Commit und Push. Jetzt aktualisiere ich die Wiki-Dokumentation und die Help-Texte.

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

Author

Owner

Copy link

💭 Agent progress

Ich ergänze den Abschnitt für den Workspace-Modus nach der Konfigurationsdatei. Die Dashboard-Hotkeys, Konfigurationspfade und der Bare-Modus-Abschnitt werden ebenfalls aktualisiert.

💭 **Agent progress** Ich ergänze den Abschnitt für den Workspace-Modus nach der Konfigurationsdatei. Die Dashboard-Hotkeys, Konfigurationspfade und der Bare-Modus-Abschnitt werden ebenfalls aktualisiert.

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

Author

Owner

Copy link

💭 Agent progress

README.md wird kurz geprüft, falls sie den Agent-Konfigurationspfad erwähnt.

Die Implementierung wird in vier inkrementelle Commits unterteilt: Workspace-Modus, Runtime-Reload, TUI-Hotkeys und Dokumentation. Die beiden letzten Punkte könnten auch kombiniert werden.

💭 **Agent progress** README.md wird kurz geprüft, falls sie den Agent-Konfigurationspfad erwähnt. Die Implementierung wird in vier inkrementelle Commits unterteilt: Workspace-Modus, Runtime-Reload, TUI-Hotkeys und Dokumentation. Die beiden letzten Punkte könnten auch kombiniert werden.

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

Author

Owner

Copy link

💭 Agent progress

Die Implementierung wird in drei Commits erfolgen. Der erste Commit betrifft den Workspace-Modus.

Der zweite Commit umfasst Runtime-Reload und Watch-Konfiguration. Der dritte Commit enthält TUI und Dokumentation. Alle drei Commits werden nun committet und gepusht.

💭 **Agent progress** Die Implementierung wird in drei Commits erfolgen. Der erste Commit betrifft den Workspace-Modus. Der zweite Commit umfasst Runtime-Reload und Watch-Konfiguration. Der dritte Commit enthält TUI und Dokumentation. Alle drei Commits werden nun committet und gepusht.

frank added 1 commit 2026-07-12 17:33:32 +02:00

feat(agent): add workspace mode outside git repositories ... 786f1298b1

When forge agent watch starts outside a repo, use ./agent.yaml in the
workspace directory and default bare-repo caches to that cwd unless
repo_cache_dir or --config override the paths.

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

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

Author

Owner

Copy link

💭 Agent progress

Die nächsten Commits 2 und 3 werden bearbeitet.

💭 **Agent progress** Die nächsten Commits 2 und 3 werden bearbeitet.

frank added 1 commit 2026-07-12 17:33:35 +02:00

feat(agent): reload watch config at runtime from agent.yaml ... 37ecf600f0

Schedule config and repository list updates between poll cycles so
saved agent.yaml changes apply without restarting the watcher.

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

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

Author

Owner

Copy link

💭 Agent progress

Der dritte Commit umfasst die TUI, Dokumentation und verbleibende Kommandoänderungen.

💭 **Agent progress** Der dritte Commit umfasst die TUI, Dokumentation und verbleibende Kommandoänderungen.

frank added 1 commit 2026-07-12 17:33:38 +02:00

feat(agent): add watch dashboard hotkeys for config and repo add ... 33a5312ecb

Press c to edit agent.yaml in the running dashboard and a to append a
repository by HTTPS URL; document workspace mode and hotkeys in wiki.

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

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

Author

Owner

Copy link

💭 Agent progress

Der Watch-Konfigurator-Code in cmd/agent.go könnte über mehrere Commits verteilt sein.

Ich prüfe den Git-Status und ob cmd/agent.go alle Änderungen enthält.

💭 **Agent progress** Der Watch-Konfigurator-Code in cmd/agent.go könnte über mehrere Commits verteilt sein. Ich prüfe den Git-Status und ob cmd/agent.go alle Änderungen enthält.

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

Author

Owner

Copy link

💭 Agent progress

Der Watch-Konfigurator in cmd/agent.go wurde bereits im ersten Commit erfasst. Die dazugehörigen Änderungen an cmd/agent.go sind in Ordnung.

Ich verifiziere den Stand des Watch-Konfigurators. Commit 3 enthält keine Änderungen an cmd/agent.go. Der Konfigurator muss daher in Commit 1 oder 2 enthalten sein. Ich prüfe die jeweiligen Git-Commits für Bestätigung.

Die Tests bestanden. Ich prüfe nun runAgentWatch, um zu bestätigen, dass der Watch-Konfigurator korrekt eingebunden ist.

💭 **Agent progress** Der Watch-Konfigurator in cmd/agent.go wurde bereits im ersten Commit erfasst. Die dazugehörigen Änderungen an cmd/agent.go sind in Ordnung. Ich verifiziere den Stand des Watch-Konfigurators. Commit 3 enthält keine Änderungen an cmd/agent.go. Der Konfigurator muss daher in Commit 1 oder 2 enthalten sein. Ich prüfe die jeweiligen Git-Commits für Bestätigung. Die Tests bestanden. Ich prüfe nun runAgentWatch, um zu bestätigen, dass der Watch-Konfigurator korrekt eingebunden ist.

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

Author

Owner

Copy link

💭 Agent progress

Ich suche den relevanten Code mit grep ohne glob.

💭 **Agent progress** Ich suche den relevanten Code mit grep ohne glob.

frank changed title from WIP: #46 Agent Watch: Workspace-Modus außerhalb eines Repos (CWD als Root, Config per c/a) to feat(agent): workspace mode and live config hotkeys in watch dashboard 2026-07-12 17:33:50 +02:00

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

Author

Owner

Copy link

✅ forge agent finished implementation

• Commit: feat(agent): add watch dashboard hotkeys for config and repo add
• Pull request: #47
• Next: waiting for CI / babysitting fixes if needed

docs/wiki/Agent-Watch.md         |  35 ++++++++---
 internal/agent/tui.go            | 133 +++++++++++++++++++++++++++++++++++++--
 internal/agent/tui_repro_test.go |   4 +-
 internal/agent/tui_test.go       |   6 +-
 4 files changed, 161 insertions(+), 17 deletions(-)

Agent output (tail)

PR_TITLE: feat(agent): workspace mode and live config hotkeys in watch dashboard
PR_BODY:
## Summary
- **Workspace-Modus:** Start von `forge agent watch` außerhalb eines Git-Repos nutzt `./agent.yaml` im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt `~/.config/forge/repos/`).
- **Laufzeit-Config:** `c` im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt `agent.yaml` und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen).
- **Repo hinzufügen:** `a` + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf.
- **Dokumentation:** Wiki `Agent-Watch` und Help-Texte für Workspace-Modus und Hotkeys `c`/`a`.
## Test plan
- [ ] `mkdir ~/agent-ws && cd ~/agent-ws && forge agent config` legt `~/agent-ws/agent.yaml` an
- [ ] `forge agent watch` im Workspace legt Bare-Repos unter `~/agent-ws/owner/repo.git` an
- [ ] Im Dashboard `c` → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart
- [ ] Im Dashboard `a` → HTTPS-URL → Repo erscheint im Poll
- [ ] Innerhalb eines Repos: `./.forge/agent.yaml` und globaler Cache unverändert
- [ ] `go test ./...`
## Änderungen (3 Commits)
1. `feat(agent): add workspace mode outside git repositories`
2. `feat(agent): reload watch config at runtime from agent.yaml`
3. `feat(agent): add watch dashboard hotkeys for config and repo add`
---
**Zusammenfassung:** Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (`./agent.yaml`, Bare-Cache im CWD). Im Watch-Dashboard öffnet `c` die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, `a` fügt per HTTPS-URL Repos hinzu. `WatchConfigurator` und `ScheduleReload` aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit `--config`/`repo_cache_dir` bleibt kompatibel.

✅ **forge agent finished implementation** - Commit: `feat(agent): add watch dashboard hotkeys for config and repo add` - Pull request: https://repository.hildebrandt.io/frank/forgecli/pulls/47 - Next: waiting for CI / babysitting fixes if needed ``` docs/wiki/Agent-Watch.md | 35 ++++++++--- internal/agent/tui.go | 133 +++++++++++++++++++++++++++++++++++++-- internal/agent/tui_repro_test.go | 4 +- internal/agent/tui_test.go | 6 +- 4 files changed, 161 insertions(+), 17 deletions(-) ``` <details><summary>Agent output (tail)</summary> ``` PR_TITLE: feat(agent): workspace mode and live config hotkeys in watch dashboard PR_BODY: ## Summary - **Workspace-Modus:** Start von `forge agent watch` außerhalb eines Git-Repos nutzt `./agent.yaml` im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt `~/.config/forge/repos/`). - **Laufzeit-Config:** `c` im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt `agent.yaml` und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen). - **Repo hinzufügen:** `a` + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf. - **Dokumentation:** Wiki `Agent-Watch` und Help-Texte für Workspace-Modus und Hotkeys `c`/`a`. ## Test plan - [ ] `mkdir ~/agent-ws && cd ~/agent-ws && forge agent config` legt `~/agent-ws/agent.yaml` an - [ ] `forge agent watch` im Workspace legt Bare-Repos unter `~/agent-ws/owner/repo.git` an - [ ] Im Dashboard `c` → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart - [ ] Im Dashboard `a` → HTTPS-URL → Repo erscheint im Poll - [ ] Innerhalb eines Repos: `./.forge/agent.yaml` und globaler Cache unverändert - [ ] `go test ./...` ## Änderungen (3 Commits) 1. `feat(agent): add workspace mode outside git repositories` 2. `feat(agent): reload watch config at runtime from agent.yaml` 3. `feat(agent): add watch dashboard hotkeys for config and repo add` --- **Zusammenfassung:** Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (`./agent.yaml`, Bare-Cache im CWD). Im Watch-Dashboard öffnet `c` die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, `a` fügt per HTTPS-URL Repos hinzu. `WatchConfigurator` und `ScheduleReload` aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit `--config`/`repo_cache_dir` bleibt kompatibel. ``` </details>

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

Author

Owner

Copy link

☑️ ToDos checked off

• mkdir ~/agent-ws && cd ~/agent-ws && forge agent watch nutzt ~/agent-ws/agent.yaml und legt Bare-Repos unter ~/agent-ws/… an
• Taste c im Watch-Dashboard öffnet Config und ändert laufende Parameter nach Speichern
• Taste a + HTTPS-URL fügt ein Repo hinzu und integriert es ohne manuellen YAML-Edit / Neustart
• Wiki (Agent-Watch) und Help-Texte dokumentieren Workspace-Modus und Hotkeys
• Bestehendes Verhalten innerhalb eines Repos / mit explizitem --config / repo_cache_dir bleibt kompatibel

☑️ **ToDos checked off** - [x] `mkdir ~/agent-ws && cd ~/agent-ws && forge agent watch` nutzt `~/agent-ws/agent.yaml` und legt Bare-Repos unter `~/agent-ws/…` an - [x] Taste **`c`** im Watch-Dashboard öffnet Config und ändert laufende Parameter nach Speichern - [x] Taste **`a`** + HTTPS-URL fügt ein Repo hinzu und integriert es ohne manuellen YAML-Edit / Neustart - [x] Wiki (`Agent-Watch`) und Help-Texte dokumentieren Workspace-Modus und Hotkeys - [x] Bestehendes Verhalten innerhalb eines Repos / mit explizitem `--config` / `repo_cache_dir` bleibt kompatibel

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

Author

Owner

Copy link

🟢 CI green (attempt 1/3)

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

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

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

Author

Owner

Copy link

💭 Agent progress

Der watchConfigurator befindet sich in cmd/agent.go.

Alle Tests bestehen. Die Änderungen sind vollständig. Ich gebe nun die geforderten TODO_DONE-Zeilen und den Pull-Request Titel mit dem Body aus.
Issue #46 ist umgesetzt. Kurz die erledigten Punkte:

Summary

• Workspace-Modus: Start von forge agent watch außerhalb eines Git-Repos nutzt ./agent.yaml im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt ~/.config/forge/repos/).
• Laufzeit-Config: c im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt agent.yaml und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen).
• Repo hinzufügen: a + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf.
• Dokumentation: Wiki Agent-Watch und Help-Texte für Workspace-Modus und Hotkeys c/a.

Test plan

• mkdir ~/agent-ws && cd ~/agent-ws && forge agent config legt ~/agent-ws/agent.yaml an
• forge agent watch im Workspace legt Bare-Repos unter ~/agent-ws/owner/repo.git an
• Im Dashboard c → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart
• Im Dashboard a → HTTPS-URL → Repo erscheint im Poll
• Innerhalb eines Repos: ./.forge/agent.yaml und globaler Cache unverändert
• go test ./...

Änderungen (3 Commits)

1. feat(agent): add workspace mode outside git repositories
2. feat(agent): reload watch config at runtime from agent.yaml
3. feat(agent): add watch dashboard hotkeys for config and repo add

---

Zusammenfassung: Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (./agent.yaml, Bare-Cache im CWD). Im Watch-Dashboard öffnet c die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, a fügt per HTTPS-URL Repos hinzu. WatchConfigurator und ScheduleReload aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit --config/repo_cache_dir bleibt kompatibel.

💭 **Agent progress** Der watchConfigurator befindet sich in cmd/agent.go. Alle Tests bestehen. Die Änderungen sind vollständig. Ich gebe nun die geforderten TODO_DONE-Zeilen und den Pull-Request Titel mit dem Body aus. Issue #46 ist umgesetzt. Kurz die erledigten Punkte: ## Summary - **Workspace-Modus:** Start von `forge agent watch` außerhalb eines Git-Repos nutzt `./agent.yaml` im CWD und cached Bare-Repos standardmäßig unter dem Workspace (statt `~/.config/forge/repos/`). - **Laufzeit-Config:** `c` im Agent-Dashboard öffnet die eingebettete Config-TUI; Speichern schreibt `agent.yaml` und wendet Änderungen ohne Neustart an (Reload zwischen Poll-Zyklen). - **Repo hinzufügen:** `a` + HTTPS-URL fügt ein Repository zur Config hinzu, legt den Bare-Clone an und nimmt es in den Watch-Poll auf. - **Dokumentation:** Wiki `Agent-Watch` und Help-Texte für Workspace-Modus und Hotkeys `c`/`a`. ## Test plan - [ ] `mkdir ~/agent-ws && cd ~/agent-ws && forge agent config` legt `~/agent-ws/agent.yaml` an - [ ] `forge agent watch` im Workspace legt Bare-Repos unter `~/agent-ws/owner/repo.git` an - [ ] Im Dashboard `c` → Config ändern → Speichern → Interval/Trigger wirken ohne Neustart - [ ] Im Dashboard `a` → HTTPS-URL → Repo erscheint im Poll - [ ] Innerhalb eines Repos: `./.forge/agent.yaml` und globaler Cache unverändert - [ ] `go test ./...` ## Änderungen (3 Commits) 1. `feat(agent): add workspace mode outside git repositories` 2. `feat(agent): reload watch config at runtime from agent.yaml` 3. `feat(agent): add watch dashboard hotkeys for config and repo add` --- **Zusammenfassung:** Außerhalb eines Git-Repos wird das aktuelle Verzeichnis zum Agent-Workspace (`./agent.yaml`, Bare-Cache im CWD). Im Watch-Dashboard öffnet `c` die Config-TUI mit sofortiger Laufzeitübernahme nach Speichern, `a` fügt per HTTPS-URL Repos hinzu. `WatchConfigurator` und `ScheduleReload` aktualisieren Config/Repos zwischen Polls. Wiki und CLI-Help sind angepasst; Verhalten in Repos und mit `--config`/`repo_cache_dir` bleibt kompatibel.

frank merged commit e5443d96a8 into main 2026-07-12 17:34:57 +02:00

frank deleted branch agent/issue-46-agent-watch-workspace-modus-außerhalb-e 2026-07-12 17:34:57 +02:00

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

Merge pull request 'feat(agent): workspace mode and live config hotkeys in watch dashboard' (#47) from agent/issue-46-agent-watch-workspace-modus-außerhalb-e 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!47

No description provided.