update ai prompt for external runner creation

README.md

@@ -79,6 +79,7 @@ Additional keymaps:
 ## Runner architecture
 
 Runners are standalone Lua modules. All runner modules are expected to implement the full interface so every command and keymap works.
+All functions are required (including the previously optional ones) and listing output must be streamed.
 Required functions:
 
 - `is_test_file`
@@ -87,6 +88,9 @@ Required functions:
 - `build_file_command`
 - `build_all_command`
 - `build_failed_command`
+- `parse_results`
+- `output_parser` (must stream listing output via `on_line`)
+- `parse_test_output`
 - `collect_failed_locations`
 
 No runner for your environment exists? No problem: use `runners-agents.md` to guide an AI-assisted runner implementation tailored to your stack.
@@ -100,6 +104,8 @@ No runner for your environment exists? No problem: use `runners-agents.md` to gu
 
 ## Development
 
+Runner development guidelines, including required data formats for keymaps, tests (`run_test.sh`), and Gitea CI (Neovim AppImage on ARM runners), are documented in `runner-agents.md`.
+
 Tests are written with `plenary.nvim` / `busted`. Mocks and stubs are allowed.
 
 Run tests:

runner-agents.md

@@ -13,7 +13,7 @@ implementieren muss, damit alle Commands vollständig unterstützt werden.
   - Beispiel: `lua/test-samurai-go-runner/init.lua` -> `require("test-samurai-go-runner")`.
   - `lua/init.lua` wäre `require("init")` und ist kollisionsanfällig; vermeiden.
 
-## Pflichtfunktionen (volle Command-Unterstützung)
+## Pflichtfunktionen (volle Command- und Keymap-Unterstützung)
 
 - `is_test_file(bufnr) -> boolean`
   - Wird für die Runner-Auswahl genutzt.
@@ -29,10 +29,18 @@ implementieren muss, damit alle Commands vollständig unterstützt werden.
   - Für `TSamAll`.
 - `build_failed_command(last_command, failures, scope_kind) -> command_spec`
   - Für `TSamFailedOnly`.
+- `parse_results(output) -> results`
+  - Fallback-Parser für vollständigen Output.
+- `output_parser() -> { on_line, on_complete }`
+  - Muss Streaming unterstützen (Listing wird live befüllt).
+- `parse_test_output(output) -> table`
+  - Detail-Ausgabe pro Test (Detail-Float und `<cr>` im Listing).
+- `collect_failed_locations(failures, command, scope_kind) -> items`
+  - Quickfix-Unterstützung (Keymap `<leader>qn`).
 
 ## Output-Parsing (Listing + Summary)
 
-Genau eine der folgenden Varianten muss vorhanden sein:
+Beide Varianten müssen vorhanden sein:
 
 - `parse_results(output) -> results`
   - `results` muss enthalten:
@@ -46,6 +54,9 @@ Genau eine der folgenden Varianten muss vorhanden sein:
 - oder `output_parser() -> { on_line, on_complete }`
   - `on_line(line, state)` kann `results` liefern (siehe oben).
   - `on_complete(output, state)` kann `results` liefern (siehe oben).
+  - `on_line` muss Ergebnisse liefern, damit das Listing-Float immer gestreamt wird.
+
+Hinweis: `parse_results` darf intern `output_parser().on_complete` nutzen, aber beide Funktionen müssen existieren.
 
 ## Listing-Gruppierung fuer Parent/Subtests
 
@@ -78,6 +89,25 @@ Genau eine der folgenden Varianten muss vorhanden sein:
 - `spec` (von `find_nearest`):
   - Muss mindestens `file` enthalten, z. B.:
     - `{ file = "...", cwd = "...", test_name = "...", full_name = "...", kind = "..." }`
+- `results` (für Listing-Float + Keymaps):
+  - `{ passes = { "Name1", ... }, failures = { "Name2", ... }, skips = { "Name3", ... } }`
+  - Optional: `display = { passes = { "DisplayName1", ... }, failures = { "DisplayName2", ... }, skips = { "DisplayName3", ... } }`
+  - `failures` steuert `[ FAIL ]`-Zeilen im Listing und wird von `<leader>nf`/`<leader>pf` genutzt.
+- `items` (für Quickfix):
+  - `{ { filename = "...", lnum = 1, col = 1, text = "..." }, ... }`
+  - Wird von `<leader>qn` verwendet.
+
+## Keymaps (Datenlieferung)
+
+- `<leader>nf` / `<leader>pf`
+  - benötigt `[ FAIL ]`-Einträge im Listing.
+  - Runner muss `results.failures` (und optional `display.failures`) liefern.
+- `<leader>qn`
+  - springt in die Quickfix-Liste.
+  - Runner muss `collect_failed_locations` implementieren und gültige `items` liefern.
+- `<cr>` im Listing
+  - öffnet Detail-Float.
+  - Runner muss `parse_test_output` liefern und Testnamen konsistent zu `results.*` halten.
 
 ## Optional empfohlene Metadaten
 
@@ -126,6 +156,17 @@ function runner.parse_results(output)
   return { passes = {}, failures = {}, skips = {}, display = { passes = {}, failures = {}, skips = {} } }
 end
 
+function runner.output_parser()
+  return {
+    on_line = function(_line, _state)
+      return nil
+    end,
+    on_complete = function(_output, _state)
+      return runner.parse_results(_output)
+    end,
+  }
+end
+
 function runner.parse_test_output(output)
   return {}
 end
@@ -145,21 +186,33 @@ return runner
 - build_file_command implementiert
 - build_all_command implementiert
 - build_failed_command implementiert
-- parse_results oder output_parser implementiert
+- parse_results implementiert
+- output_parser implementiert (Streaming)
 - parse_test_output implementiert
 - collect_failed_locations implementiert
 - command_spec `{ cmd, cwd }` korrekt zurückgegeben
 
 ## Projekt- und Prozessanforderungen
 
-- Eine englischsprachige `README.md` ist zu erstellen.
+- Rolle: **TDD-first Entwickler**.
-  - Sie muss bei jedem weiteren Prompt aktualisiert werden, wenn die Aenderungen es erfordern.
+  - Jede neue Funktion, jedes neue Kommando und jede Verhaltensänderung muss durch Tests abgesichert sein.
+  - Nach jeder Code-Änderung Tests via `bash run_test.sh` ausführen und bei Fehlern korrigieren, bis alles grün ist.
+- **Nicht raten**:
+  - Bei unklaren oder mehrdeutigen Anforderungen Arbeit stoppen und Klarstellung verlangen.
+  - TODO/NOTE im Code ist zulässig, stilles Raten nicht.
+- **Keine stillen Änderungen**:
+  - Bestehende Features dürfen nicht unbemerkt geändert oder ersetzt werden.
+  - Notwendige Anpassungen zur Koexistenz mehrerer Features müssen klar erkennbar sein.
+- Antworten immer auf Deutsch.
+- Eine englischsprachige `README.md` ist zu erstellen und wird bei Änderungen automatisch aktualisiert.
 - TDD-Vorgaben (aus `AGENTS.md`) uebernehmen:
   - Neue Funktionen/Commands/Verhaltensaenderungen muessen getestet werden.
   - Tests nach jeder Code-Aenderung ausfuehren.
   - Im Runner erstellter Quellcode ist ebenfalls zu testen.
-  - Eine eigene `run_test.sh` darf im Runner-Repo angelegt werden.
+  - Eine eigene `run_test.sh` wird im Runner-Repo angelegt.
 - Eine Gitea-Action ist zu erstellen, die bei jedem Push die Tests ausfuehrt.
+  - Neovim wird per AppImage installiert (kein `apt`).
+  - Runner laeuft auf `gitea-act-runner` mit Raspberry Pi 5 (ARM).
   - Beispiel (anpassbarer Workflow):
 
 ```yaml
@@ -176,6 +229,11 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
+      - name: Install Neovim (AppImage)
+        run: |
+          curl -L -o nvim.appimage https://github.com/neovim/neovim/releases/download/v0.11.4/nvim.appimage
+          chmod +x nvim.appimage
+          sudo mv nvim.appimage /usr/local/bin/nvim
       - name: Run tests
         run: bash run_test.sh
 ```