Bei der Prüfung von Hand (Windows, GitHub Copilot CLI, Stand 10.0.0) hat wiki-ingest ohne Argument nach dem Freigeben mehrerer Quarantäne-Einträge (#213) mehrere wartende Einträge aus incoming/im selben Kontext nacheinander abarbeiten wollen. Frage des Betreibers: gehört dazwischen jeweils ein /clear, und ginge das mit Subagents – in welchen Harnesses? Wortlaut des Stubs: Kommentar vom 2026-10-15.
Ergebnis
Umgesetzt in zwei Veröffentlichungen, beide mit grüner CI:
Version
Commit
Inhalt
CI
10.1.0-beta.13
3197acf
Skill, capture-session.md, gates.md, zwei How-tos
Läufe 737 (CI) und 738 (Converters) success
10.1.0-beta.14
b219add
Nachzug aus dem Abschluss: Regel für eine neue Session-Id nur noch in gates.md
Läufe 739 und 740 success
Lokal vor der ersten Veröffentlichung: docs verify, instructions verify, pytest (3085 passed, 4 skipped); vor der zweiten docs verify und instructions verify (reiner Anweisungstext).
Befund (gegen den Baum geprüft, 10.1.0-beta.12)
Die Regel „ein Lauf, eine Quelle“ gab es schon – im Trigger („One run is one source“) und in Schritt 1 („One run takes exactly that one entry“), seit #112 (2026-10-03), also auch in 10.0.0. Es fehlte kein Prinzip, sondern ein Ende des Laufs.
Schritt 12 endete offen: „Then say how many entries still wait in incoming/ …, so the user knows whether another run is due.“ Nirgends stand, dass der nächste Eintrag nicht im selben Kontext beginnt, und kein Reset wurde empfohlen.
Der Zweig „captured repositories“ schrieb die Schleife sogar vor: „Each further bundle is a run of its own, started by the same request“ – im Widerspruch zu docs/how-to/capture-repository-docs.md („Run it again for the next one“).
Das Iterationsbudget vertrug die Schleife nicht: ~20–35 wikitool-Aufrufe pro Ingest gegen 60 pro Session-Id; unter Claude Code und unter Copilot mit gesetzter WIKITOOL_SESSION_ID lief der zweite bis dritte Ingest im selben Kontext in die Sperre, unter Copilot ohne Id (pid-Fallback) fiel die Schleife mechanisch gar nicht auf.
Warum der Reset inhaltlich zählt: Mit Quelle A noch im Kontext schreibt der Lauf für Quelle B leicht Fakten aus A auf B's Seiten oder belegt sie mit B (Invariante 3, Provenienz). Kein Validator sieht das.
Präzedenz:stack-dev/stack-build enden mit einer festen Zeile, die dem Betreiber den nächsten Slash-Befehl nennt; ein /clear kann ohnehin nur der Betreiber auslösen.
Harnesses: Reset-Befehl und Subagents (recherchiert 2026-10-15)
Harness
Kontext-Reset
Subagents
Kann ein Subagent den Nutzer fragen?
Claude Code
/clear
ja (Agent-Tool)
nein – AskUserQuestion steht Subagents nicht zur Verfügung (Agent-SDK-Doku, mehrere Issue-Berichte 2025/26)
GitHub Copilot CLI
/clear (gleichbedeutend /new, /reset)
ja (Custom Agents, /task, /fleet; eigenes Kontextfenster)
nicht dokumentiert; nur Steering-Nachrichten aus dem Tasks-Dialog
Codex CLI
/clear (Terminal leeren, neuer Chat), /new
ja (standardmäßig an; auf Anforderung oder wenn AGENTS.md/Skill es verlangt)
nur Freigabe-Anfragen kommen hoch, keine Rückfragen dokumentiert
Mistral Vibe
/clear
ja (task-Tool)
nein – „Subagents run independently … without user interaction“
Folgerung:/clear ist in allen vier Harnesses der Reset – die Schlusszeile braucht keine Harness-Unterscheidung. Subagents gibt es überall, aber in keinem kann ein Subagent den Dialog führen, den ein Ingest verlangt.
Entscheidungen (Betreiber, 2026-10-15 – alle Empfehlungen angenommen, alle umgesetzt)
F1 – Ende eines Laufs. Nach Schritt 12 endet der Lauf hart. Warten weitere Einträge, sagt der Agent eine feste Zeile (Modell im Skill auf Englisch, gesprochen in der KB-Sprache) – „N more entries wait in incoming/. Next: /clear, then ingest.“ – und beginnt den nächsten Eintrag nicht von sich aus. Bittet der Nutzer ausdrücklich, im selben Kontext weiterzumachen: einmal Empfehlung und Grund (Provenienz, Budget), dann folgen, mit neuer Session-Id für den neuen Lauf. Verworfen: auch auf ausdrücklichen Wunsch nur nach Reset weiter – der Kontext ist die Entscheidung des Betreibers.
Folge für die Gate-Regel:instructions/gates.md § Taking a new session id erlaubte eine neue Id nur an einer in plan.md festgehaltenen Einheitsgrenze; ein einzelner Ingest hat keinen plan.md. Der Abschnitt nennt jetzt den ausdrücklichen Wunsch des Nutzers, im selben Kontext weiterzumachen, als zweite legitime Grenze (die Anfrage ist die menschliche Freigabe; nie vom Agenten angeboten, nie als Weg an einer Sperre vorbei). Beim Abschluss fiel auf, dass instructions/session-setup.md § Multi-unit runs die alte plan.md-Regel wiederholte und damit widersprach – jetzt verweist es nur auf gates.md (Invariante 8); gates.md spricht von „the two agent cases above“ statt „the two cases above“.
F2 – Zweig „captured repositories“. Dieselbe Regel – ein Bundle pro Lauf, dann Stopp mit der Zeile „N more bundles changed. Next: /clear, then update the captured repositories“. Der Satz „Each further bundle …“ ist entfallen; der Widerspruch zur How-to ist behoben.
F3 – Subagents: verworfen. Ein Ingest hat Halte, die ein Mensch beantwortet: Schritt 4 (Kernpunkte, Commitment bestätigen), Schritt 5 (fidelity/authority, nie geraten), die Namenskollision bei raw accept, Exit 42 bei publish/sync. Ein Subagent pro Eintrag kann keinen davon führen – er müsste raten oder abbrechen. Ein geteilter Ablauf (Subagent extrahiert → Hauptkontext bespricht → zweiter Subagent schreibt) liest die Quelle doppelt, macht die Übergabe der Entscheidungen zum neuen Fehlerort und gewinnt gegenüber /clear wenig. Wiedervorlage-Auslöser: ein Ingest, der ohne Dialog auskommt (z. B. Capture-Felder aus einem Manifest wie bei raw capture und kein Commitment-Gespräch). Im Skill steht dazu nichts; die Begründung bleibt hier.
F4 – instructions/capture-session.md Schritt 5 erlaubte, wiki-ingest an Subagents zu delegieren. Delegation gestrichen; jedes Transkript ist ein eigener wiki-ingest-Lauf mit dem Ende aus F1 (/clear dazwischen, die Transkripte liegen nach Schritt 3 schon in raw/). Die Begründung für „sequenziell, nie parallel“ bleibt, ein Absatz nennt, warum nicht an Subagents; Schritt 6 („Verify the set“) läuft nach dem letzten Lauf.
Umsetzung (Dateien)
instructions/wiki-ingest/SKILL.md: Trigger („One run is one source, in one context“), Schritt 1 Zweig „captured repositories“, Schritt 12 (hartes Ende mit den zwei festen Zeilen; entfallen, wenn nichts wartet), neuer Entscheidungspunkt „The user asks to go on with the next entry in this context?“.
instructions/capture-session.md Schritt 5 (F4).
instructions/gates.md § Taking a new session id und instructions/session-setup.md § Multi-unit runs (F1, Folge).
docs/how-to/ingest-a-source.md: ein Eintrag pro Lauf, /clear zwischen Läufen, Grund.
docs/how-to/capture-repository-docs.md: nächstes Bundle nach /clear.
docs/tutorials/first-source-to-first-answer.md gegengelesen: nur ein Eintrag, keine Änderung. docs/explanation/ und docs/reference/ geprüft: keine Seite beschreibt das Ende eines Ingest-Laufs oder die Session-Id-Grenze, keine Änderung.
instructions sync nach jeder Änderung; CHANGES.md über zwei version bump --patch.
Keine Code-Änderung: raw pending nennt die Zahl der Wartenden schon, raw status die geänderten Bundles.
Akzeptanzkriterien
instructions/wiki-ingest/SKILL.md enthält keinen Satz mehr, der mehr als einen Eintrag oder ein Bundle pro Lauf vorsieht (grep -n "Each further bundle" leer).
Schritt 12 endet, wenn weitere Einträge bzw. Bundles warten, mit der festen Zeile, die /clear und den nächsten Auslöser nennt, und sagt ausdrücklich, dass der Agent den nächsten Lauf nicht selbst beginnt; warten keine, entfällt die Zeile.
Die Zeile nennt /clear ohne Harness-Unterscheidung.
Ein Entscheidungspunkt regelt den ausdrücklichen Wunsch, im selben Kontext weiterzumachen: Empfehlung und Grund einmal, dann folgen, neue Session-Id.
Skill und docs/how-to/capture-repository-docs.md beschreiben das Ende eines Laufs gleich.
docs/how-to/ingest-a-source.md nennt den Reset zwischen zwei Läufen und den Grund.
instructions/capture-session.md Schritt 5 sieht keine Delegation von wiki-ingest an Subagents mehr vor (grep -n "delegat" instructions/capture-session.md ohne Treffer).
tools/wikitool instructions verify, tools/wikitool docs verify und pytest grün; CI auf beiden veröffentlichten Commits grün (737/738, 739/740).
Versionsteil
--patch, zweimal: nur Anweisungs- und Doku-Text ausgelieferter Dateien, kein Befehl, Flag, Dateiformat oder Pflichtfeld geändert; Drop-in vorwärts und rückwärts. Gebucht als 10.1.0-beta.13 und 10.1.0-beta.14 im MINOR-Kandidaten 10.1.0.
Nicht in diesem Paket
Units in ingest-large-tree.md laufen ebenfalls nacheinander in einem Kontext. Dort trägt work/<runkey>/README.md den Stand, ein Lauf lässt sich nach einem Reset fortsetzen, und das Lesen in Teilen begrenzt den Kontext schon. Ob zwischen Units ein Reset empfohlen wird, ist eine eigene Frage, die der Stub nicht stellte; kein Issue dafür angelegt.
## Anlass
Bei der Prüfung von Hand (Windows, GitHub Copilot CLI, Stand 10.0.0) hat `wiki-ingest` ohne Argument nach dem Freigeben mehrerer Quarantäne-Einträge (#213) mehrere wartende Einträge aus `incoming/` **im selben Kontext** nacheinander abarbeiten wollen. Frage des Betreibers: gehört dazwischen jeweils ein `/clear`, und ginge das mit Subagents – in welchen Harnesses? Wortlaut des Stubs: Kommentar vom 2026-10-15.
## Ergebnis
Umgesetzt in zwei Veröffentlichungen, beide mit grüner CI:
| Version | Commit | Inhalt | CI |
|---|---|---|---|
| 10.1.0-beta.13 | `3197acf` | Skill, `capture-session.md`, `gates.md`, zwei How-tos | Läufe 737 (CI) und 738 (Converters) `success` |
| 10.1.0-beta.14 | `b219add` | Nachzug aus dem Abschluss: Regel für eine neue Session-Id nur noch in `gates.md` | Läufe 739 und 740 `success` |
Lokal vor der ersten Veröffentlichung: `docs verify`, `instructions verify`, `pytest` (3085 passed, 4 skipped); vor der zweiten `docs verify` und `instructions verify` (reiner Anweisungstext).
## Befund (gegen den Baum geprüft, 10.1.0-beta.12)
1. **Die Regel „ein Lauf, eine Quelle“ gab es schon** – im Trigger („One run is one source“) und in Schritt 1 („One run takes exactly that one entry“), seit #112 (2026-10-03), also auch in 10.0.0. Es fehlte kein Prinzip, sondern **ein Ende des Laufs**.
2. **Schritt 12 endete offen:** „Then say how many entries still wait in `incoming/` …, so the user knows whether another run is due.“ Nirgends stand, dass der nächste Eintrag nicht im selben Kontext beginnt, und kein Reset wurde empfohlen.
3. **Der Zweig „captured repositories“ schrieb die Schleife sogar vor:** „Each further bundle is a run of its own, started by the same request“ – im Widerspruch zu `docs/how-to/capture-repository-docs.md` („Run it again for the next one“).
4. **Das Iterationsbudget vertrug die Schleife nicht:** ~20–35 `wikitool`-Aufrufe pro Ingest gegen 60 pro Session-Id; unter Claude Code und unter Copilot mit gesetzter `WIKITOOL_SESSION_ID` lief der zweite bis dritte Ingest im selben Kontext in die Sperre, unter Copilot ohne Id (pid-Fallback) fiel die Schleife mechanisch gar nicht auf.
5. **Warum der Reset inhaltlich zählt:** Mit Quelle A noch im Kontext schreibt der Lauf für Quelle B leicht Fakten aus A auf B's Seiten oder belegt sie mit B (Invariante 3, Provenienz). Kein Validator sieht das.
6. **Präzedenz:** `stack-dev`/`stack-build` enden mit einer festen Zeile, die dem Betreiber den nächsten Slash-Befehl nennt; ein `/clear` kann ohnehin nur der Betreiber auslösen.
## Harnesses: Reset-Befehl und Subagents (recherchiert 2026-10-15)
| Harness | Kontext-Reset | Subagents | Kann ein Subagent den Nutzer fragen? |
|---|---|---|---|
| Claude Code | `/clear` | ja (Agent-Tool) | nein – `AskUserQuestion` steht Subagents nicht zur Verfügung (Agent-SDK-Doku, mehrere Issue-Berichte 2025/26) |
| GitHub Copilot CLI | `/clear` (gleichbedeutend `/new`, `/reset`) | ja (Custom Agents, `/task`, `/fleet`; eigenes Kontextfenster) | nicht dokumentiert; nur Steering-Nachrichten aus dem Tasks-Dialog |
| Codex CLI | `/clear` (Terminal leeren, neuer Chat), `/new` | ja (standardmäßig an; auf Anforderung oder wenn AGENTS.md/Skill es verlangt) | nur Freigabe-Anfragen kommen hoch, keine Rückfragen dokumentiert |
| Mistral Vibe | `/clear` | ja (`task`-Tool) | nein – „Subagents run independently … without user interaction“ |
Quellen: [Copilot CLI command reference](https://docs.github.com/en/copilot/reference/cli-command-reference), [Copilot custom agents](https://github.blog/changelog/2025-10-28-github-copilot-cli-use-custom-agents-and-delegate-to-copilot-coding-agent/), [Codex slash commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli), [Codex subagents](https://learn.chatgpt.com/docs/agent-configuration/subagents), [Mistral Vibe README](https://github.com/mistralai/mistral-vibe), [Claude Code AskUserQuestion in Subagents](https://github.com/anthropics/claude-code/issues/20275).
**Folgerung:** `/clear` ist in allen vier Harnesses der Reset – die Schlusszeile braucht keine Harness-Unterscheidung. Subagents gibt es überall, aber in keinem kann ein Subagent den Dialog führen, den ein Ingest verlangt.
## Entscheidungen (Betreiber, 2026-10-15 – alle Empfehlungen angenommen, alle umgesetzt)
- **F1 – Ende eines Laufs.** Nach Schritt 12 endet der Lauf hart. Warten weitere Einträge, sagt der Agent eine feste Zeile (Modell im Skill auf Englisch, gesprochen in der KB-Sprache) – „N more entries wait in `incoming/`. Next: `/clear`, then `ingest`.“ – und beginnt den nächsten Eintrag nicht von sich aus. Bittet der Nutzer ausdrücklich, im selben Kontext weiterzumachen: einmal Empfehlung und Grund (Provenienz, Budget), dann folgen, mit neuer Session-Id für den neuen Lauf. Verworfen: auch auf ausdrücklichen Wunsch nur nach Reset weiter – der Kontext ist die Entscheidung des Betreibers.
- **Folge für die Gate-Regel:** `instructions/gates.md` § Taking a new session id erlaubte eine neue Id nur an einer in `plan.md` festgehaltenen Einheitsgrenze; ein einzelner Ingest hat keinen `plan.md`. Der Abschnitt nennt jetzt den ausdrücklichen Wunsch des Nutzers, im selben Kontext weiterzumachen, als zweite legitime Grenze (die Anfrage ist die menschliche Freigabe; nie vom Agenten angeboten, nie als Weg an einer Sperre vorbei). Beim Abschluss fiel auf, dass `instructions/session-setup.md` § Multi-unit runs die alte `plan.md`-Regel wiederholte und damit widersprach – jetzt verweist es nur auf `gates.md` (Invariante 8); `gates.md` spricht von „the two agent cases above“ statt „the two cases above“.
- **F2 – Zweig „captured repositories“.** Dieselbe Regel – ein Bundle pro Lauf, dann Stopp mit der Zeile „N more bundles changed. Next: `/clear`, then `update the captured repositories`“. Der Satz „Each further bundle …“ ist entfallen; der Widerspruch zur How-to ist behoben.
- **F3 – Subagents: verworfen.** Ein Ingest hat Halte, die ein Mensch beantwortet: Schritt 4 (Kernpunkte, Commitment bestätigen), Schritt 5 (`fidelity`/`authority`, nie geraten), die Namenskollision bei `raw accept`, Exit 42 bei `publish`/`sync`. Ein Subagent pro Eintrag kann keinen davon führen – er müsste raten oder abbrechen. Ein geteilter Ablauf (Subagent extrahiert → Hauptkontext bespricht → zweiter Subagent schreibt) liest die Quelle doppelt, macht die Übergabe der Entscheidungen zum neuen Fehlerort und gewinnt gegenüber `/clear` wenig. **Wiedervorlage-Auslöser:** ein Ingest, der ohne Dialog auskommt (z. B. Capture-Felder aus einem Manifest wie bei `raw capture` und kein Commitment-Gespräch). Im Skill steht dazu nichts; die Begründung bleibt hier.
- **F4 – `instructions/capture-session.md` Schritt 5** erlaubte, `wiki-ingest` an Subagents zu delegieren. Delegation gestrichen; jedes Transkript ist ein eigener `wiki-ingest`-Lauf mit dem Ende aus F1 (`/clear` dazwischen, die Transkripte liegen nach Schritt 3 schon in `raw/`). Die Begründung für „sequenziell, nie parallel“ bleibt, ein Absatz nennt, warum nicht an Subagents; Schritt 6 („Verify the set“) läuft nach dem letzten Lauf.
## Umsetzung (Dateien)
- `instructions/wiki-ingest/SKILL.md`: Trigger („One run is one source, in one context“), Schritt 1 Zweig „captured repositories“, Schritt 12 (hartes Ende mit den zwei festen Zeilen; entfallen, wenn nichts wartet), neuer Entscheidungspunkt „The user asks to go on with the next entry in this context?“.
- `instructions/capture-session.md` Schritt 5 (F4).
- `instructions/gates.md` § Taking a new session id und `instructions/session-setup.md` § Multi-unit runs (F1, Folge).
- `docs/how-to/ingest-a-source.md`: ein Eintrag pro Lauf, `/clear` zwischen Läufen, Grund.
- `docs/how-to/capture-repository-docs.md`: nächstes Bundle nach `/clear`.
- `docs/tutorials/first-source-to-first-answer.md` gegengelesen: nur ein Eintrag, keine Änderung. `docs/explanation/` und `docs/reference/` geprüft: keine Seite beschreibt das Ende eines Ingest-Laufs oder die Session-Id-Grenze, keine Änderung.
- `instructions sync` nach jeder Änderung; `CHANGES.md` über zwei `version bump --patch`.
Keine Code-Änderung: `raw pending` nennt die Zahl der Wartenden schon, `raw status` die geänderten Bundles.
## Akzeptanzkriterien
- [x] `instructions/wiki-ingest/SKILL.md` enthält keinen Satz mehr, der mehr als einen Eintrag oder ein Bundle pro Lauf vorsieht (`grep -n "Each further bundle"` leer).
- [x] Schritt 12 endet, wenn weitere Einträge bzw. Bundles warten, mit der festen Zeile, die `/clear` und den nächsten Auslöser nennt, und sagt ausdrücklich, dass der Agent den nächsten Lauf nicht selbst beginnt; warten keine, entfällt die Zeile.
- [x] Die Zeile nennt `/clear` ohne Harness-Unterscheidung.
- [x] Ein Entscheidungspunkt regelt den ausdrücklichen Wunsch, im selben Kontext weiterzumachen: Empfehlung und Grund einmal, dann folgen, neue Session-Id.
- [x] Skill und `docs/how-to/capture-repository-docs.md` beschreiben das Ende eines Laufs gleich.
- [x] `docs/how-to/ingest-a-source.md` nennt den Reset zwischen zwei Läufen und den Grund.
- [x] `instructions/capture-session.md` Schritt 5 sieht keine Delegation von `wiki-ingest` an Subagents mehr vor (`grep -n "delegat" instructions/capture-session.md` ohne Treffer).
- [x] `tools/wikitool instructions verify`, `tools/wikitool docs verify` und `pytest` grün; CI auf beiden veröffentlichten Commits grün (737/738, 739/740).
## Versionsteil
`--patch`, zweimal: nur Anweisungs- und Doku-Text ausgelieferter Dateien, kein Befehl, Flag, Dateiformat oder Pflichtfeld geändert; Drop-in vorwärts und rückwärts. Gebucht als 10.1.0-beta.13 und 10.1.0-beta.14 im MINOR-Kandidaten 10.1.0.
## Nicht in diesem Paket
- **Units in `ingest-large-tree.md`** laufen ebenfalls nacheinander in einem Kontext. Dort trägt `work/<runkey>/README.md` den Stand, ein Lauf lässt sich nach einem Reset fortsetzen, und das Lesen in Teilen begrenzt den Kontext schon. Ob zwischen Units ein Reset empfohlen wird, ist eine eigene Frage, die der Stub nicht stellte; kein Issue dafür angelegt.
Ausarbeitung des Stubs (2026-10-15). Wortlaut des Stubs, wie er im Body stand:
Stub, angelegt auf Wunsch des Betreibers (2026-10-13), Wortlaut aus der Prüfung von Hand auf dem Windows-Arbeitsrechner (GitHub Copilot CLI, Stand 10.0.0):
wiki ingest ohne weitere argumente scheint in einer schleife zu arbeiten und mehrere wartende dateien im gleichen kontext importieren zu wollen. sollten wir da nicht jeweils ein clear dazwischen haben?
könnten wir da mit subagents arbeiten, wenn ja, in welchen harnesses
Kontext: Vorher hatte wiki-ingest ohne Argument über upload collect mehrere Dateien aus dem OneDrive-Kanal in die Quarantäne geholt (#213); die hat der Betreiber freigegeben, danach lagen mehrere Einträge in incoming/.
Changelog: Body gegen den Baum (10.1.0-beta.12) ausgearbeitet: Befund (Regel „ein Lauf, eine Quelle“ existiert seit #112, aber kein Ende des Laufs; Repo-Zweig schreibt die Schleife sogar vor und widerspricht der How-to; Budget kippt beim 2.–3. Ingest im selben Kontext), Harness-Tabelle zu Reset-Befehl und Subagents, vier offene Entscheidungen F1–F4 mit Empfehlung, Dateien, Kriterien, Versionsteil --patch. Labels: status/incoming entfernt, area/kbkind/decisionprio/plannedsize/S.
**Ausarbeitung des Stubs (2026-10-15).** Wortlaut des Stubs, wie er im Body stand:
> Stub, angelegt auf Wunsch des Betreibers (2026-10-13), Wortlaut aus der Prüfung von Hand auf dem Windows-Arbeitsrechner (GitHub Copilot CLI, Stand 10.0.0):
>
> > wiki ingest ohne weitere argumente scheint in einer schleife zu arbeiten und mehrere wartende dateien im gleichen kontext importieren zu wollen. sollten wir da nicht jeweils ein clear dazwischen haben?
> >
> > könnten wir da mit subagents arbeiten, wenn ja, in welchen harnesses
>
> Kontext: Vorher hatte `wiki-ingest` ohne Argument über `upload collect` mehrere Dateien aus dem OneDrive-Kanal in die Quarantäne geholt (#213); die hat der Betreiber freigegeben, danach lagen mehrere Einträge in `incoming/`.
**Changelog:** Body gegen den Baum (10.1.0-beta.12) ausgearbeitet: Befund (Regel „ein Lauf, eine Quelle“ existiert seit #112, aber kein Ende des Laufs; Repo-Zweig schreibt die Schleife sogar vor und widerspricht der How-to; Budget kippt beim 2.–3. Ingest im selben Kontext), Harness-Tabelle zu Reset-Befehl und Subagents, vier offene Entscheidungen F1–F4 mit Empfehlung, Dateien, Kriterien, Versionsteil `--patch`. Labels: `status/incoming` entfernt, `area/kb` `kind/decision` `prio/planned` `size/S`.
torben
changed title from wiki-ingest ohne Argument arbeitet alle wartenden Dateien in einem Kontext ab – /clear dazwischen oder Subagents, und in welchen Harnesses? to wiki-ingest: ein Lauf endet nach einer Quelle mit Stopp und /clear-Empfehlung – keine Schleife im selben Kontext; Subagents geprüft2026-10-15 21:18:37 +00:00
Changelog: F1–F4 entschieden (Betreiber: alle Empfehlungen angenommen) – „Offene Entscheidungen“ ist jetzt „Entscheidungen“ mit Begründung, Subagents als verworfener Ansatz dort eingeordnet. Neu: instructions sync in der Dateiliste, Kriterium für den Entscheidungspunkt „im selben Kontext weitermachen“. kind/decision → kind/build.
**Changelog:** F1–F4 entschieden (Betreiber: alle Empfehlungen angenommen) – „Offene Entscheidungen“ ist jetzt „Entscheidungen“ mit Begründung, Subagents als verworfener Ansatz dort eingeordnet. Neu: `instructions sync` in der Dateiliste, Kriterium für den Entscheidungspunkt „im selben Kontext weitermachen“. `kind/decision` → `kind/build`.
Changelog: Gebaut und als 10.1.0-beta.13 veröffentlicht (Commit 3197acf), CI-Läufe 737 und 738 grün. Body auf den erreichten Stand umgeschrieben: Umsetzung und Kriterien abgehakt, F1–F4 als umgesetzt markiert. Neu gegenüber der Planung: instructions/gates.md § Taking a new session id nennt den ausdrücklichen Nutzerwunsch „im selben Kontext weiterzumachen“ als zweite legitime Grenze für eine neue Id – sonst hätte der Entscheidungspunkt des Skills der Regel „nur an einer plan.md-Grenze“ widersprochen.
**Changelog:** Gebaut und als 10.1.0-beta.13 veröffentlicht (Commit `3197acf`), CI-Läufe 737 und 738 grün. Body auf den erreichten Stand umgeschrieben: Umsetzung und Kriterien abgehakt, F1–F4 als umgesetzt markiert. Neu gegenüber der Planung: `instructions/gates.md` § Taking a new session id nennt den ausdrücklichen Nutzerwunsch „im selben Kontext weiterzumachen“ als zweite legitime Grenze für eine neue Id – sonst hätte der Entscheidungspunkt des Skills der Regel „nur an einer `plan.md`-Grenze“ widersprochen.
Changelog: Abschluss. Staleness-Prüfung fand zwei Stellen, die der gates.md-Zusatz veraltet hatte: session-setup.md § Multi-unit runs wiederholte die alte plan.md-Regel (verweist jetzt nur noch auf gates.md), und gates.md zählte „two cases“. Nachgezogen als 10.1.0-beta.14 (b219add), CI-Läufe 739/740 grün. Body in Endzustand gebracht („Stand“ → „Ergebnis“ mit beiden Veröffentlichungen), docs/explanation/ und docs/reference/ ohne Änderungsbedarf. Geschlossen.
**Changelog:** Abschluss. Staleness-Prüfung fand zwei Stellen, die der `gates.md`-Zusatz veraltet hatte: `session-setup.md` § Multi-unit runs wiederholte die alte `plan.md`-Regel (verweist jetzt nur noch auf `gates.md`), und `gates.md` zählte „two cases“. Nachgezogen als 10.1.0-beta.14 (`b219add`), CI-Läufe 739/740 grün. Body in Endzustand gebracht („Stand“ → „Ergebnis“ mit beiden Veröffentlichungen), `docs/explanation/` und `docs/reference/` ohne Änderungsbedarf. Geschlossen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Anlass
Bei der Prüfung von Hand (Windows, GitHub Copilot CLI, Stand 10.0.0) hat
wiki-ingestohne Argument nach dem Freigeben mehrerer Quarantäne-Einträge (#213) mehrere wartende Einträge ausincoming/im selben Kontext nacheinander abarbeiten wollen. Frage des Betreibers: gehört dazwischen jeweils ein/clear, und ginge das mit Subagents – in welchen Harnesses? Wortlaut des Stubs: Kommentar vom 2026-10-15.Ergebnis
Umgesetzt in zwei Veröffentlichungen, beide mit grüner CI:
3197acfcapture-session.md,gates.md, zwei How-tossuccessb219addgates.mdsuccessLokal vor der ersten Veröffentlichung:
docs verify,instructions verify,pytest(3085 passed, 4 skipped); vor der zweitendocs verifyundinstructions verify(reiner Anweisungstext).Befund (gegen den Baum geprüft, 10.1.0-beta.12)
incoming/…, so the user knows whether another run is due.“ Nirgends stand, dass der nächste Eintrag nicht im selben Kontext beginnt, und kein Reset wurde empfohlen.docs/how-to/capture-repository-docs.md(„Run it again for the next one“).wikitool-Aufrufe pro Ingest gegen 60 pro Session-Id; unter Claude Code und unter Copilot mit gesetzterWIKITOOL_SESSION_IDlief der zweite bis dritte Ingest im selben Kontext in die Sperre, unter Copilot ohne Id (pid-Fallback) fiel die Schleife mechanisch gar nicht auf.stack-dev/stack-buildenden mit einer festen Zeile, die dem Betreiber den nächsten Slash-Befehl nennt; ein/clearkann ohnehin nur der Betreiber auslösen.Harnesses: Reset-Befehl und Subagents (recherchiert 2026-10-15)
/clearAskUserQuestionsteht Subagents nicht zur Verfügung (Agent-SDK-Doku, mehrere Issue-Berichte 2025/26)/clear(gleichbedeutend/new,/reset)/task,/fleet; eigenes Kontextfenster)/clear(Terminal leeren, neuer Chat),/new/cleartask-Tool)Quellen: Copilot CLI command reference, Copilot custom agents, Codex slash commands, Codex subagents, Mistral Vibe README, Claude Code AskUserQuestion in Subagents.
Folgerung:
/clearist in allen vier Harnesses der Reset – die Schlusszeile braucht keine Harness-Unterscheidung. Subagents gibt es überall, aber in keinem kann ein Subagent den Dialog führen, den ein Ingest verlangt.Entscheidungen (Betreiber, 2026-10-15 – alle Empfehlungen angenommen, alle umgesetzt)
incoming/. Next:/clear, theningest.“ – und beginnt den nächsten Eintrag nicht von sich aus. Bittet der Nutzer ausdrücklich, im selben Kontext weiterzumachen: einmal Empfehlung und Grund (Provenienz, Budget), dann folgen, mit neuer Session-Id für den neuen Lauf. Verworfen: auch auf ausdrücklichen Wunsch nur nach Reset weiter – der Kontext ist die Entscheidung des Betreibers.instructions/gates.md§ Taking a new session id erlaubte eine neue Id nur an einer inplan.mdfestgehaltenen Einheitsgrenze; ein einzelner Ingest hat keinenplan.md. Der Abschnitt nennt jetzt den ausdrücklichen Wunsch des Nutzers, im selben Kontext weiterzumachen, als zweite legitime Grenze (die Anfrage ist die menschliche Freigabe; nie vom Agenten angeboten, nie als Weg an einer Sperre vorbei). Beim Abschluss fiel auf, dassinstructions/session-setup.md§ Multi-unit runs die alteplan.md-Regel wiederholte und damit widersprach – jetzt verweist es nur aufgates.md(Invariante 8);gates.mdspricht von „the two agent cases above“ statt „the two cases above“./clear, thenupdate the captured repositories“. Der Satz „Each further bundle …“ ist entfallen; der Widerspruch zur How-to ist behoben.fidelity/authority, nie geraten), die Namenskollision beiraw accept, Exit 42 beipublish/sync. Ein Subagent pro Eintrag kann keinen davon führen – er müsste raten oder abbrechen. Ein geteilter Ablauf (Subagent extrahiert → Hauptkontext bespricht → zweiter Subagent schreibt) liest die Quelle doppelt, macht die Übergabe der Entscheidungen zum neuen Fehlerort und gewinnt gegenüber/clearwenig. Wiedervorlage-Auslöser: ein Ingest, der ohne Dialog auskommt (z. B. Capture-Felder aus einem Manifest wie beiraw captureund kein Commitment-Gespräch). Im Skill steht dazu nichts; die Begründung bleibt hier.instructions/capture-session.mdSchritt 5 erlaubte,wiki-ingestan Subagents zu delegieren. Delegation gestrichen; jedes Transkript ist ein eigenerwiki-ingest-Lauf mit dem Ende aus F1 (/cleardazwischen, die Transkripte liegen nach Schritt 3 schon inraw/). Die Begründung für „sequenziell, nie parallel“ bleibt, ein Absatz nennt, warum nicht an Subagents; Schritt 6 („Verify the set“) läuft nach dem letzten Lauf.Umsetzung (Dateien)
instructions/wiki-ingest/SKILL.md: Trigger („One run is one source, in one context“), Schritt 1 Zweig „captured repositories“, Schritt 12 (hartes Ende mit den zwei festen Zeilen; entfallen, wenn nichts wartet), neuer Entscheidungspunkt „The user asks to go on with the next entry in this context?“.instructions/capture-session.mdSchritt 5 (F4).instructions/gates.md§ Taking a new session id undinstructions/session-setup.md§ Multi-unit runs (F1, Folge).docs/how-to/ingest-a-source.md: ein Eintrag pro Lauf,/clearzwischen Läufen, Grund.docs/how-to/capture-repository-docs.md: nächstes Bundle nach/clear.docs/tutorials/first-source-to-first-answer.mdgegengelesen: nur ein Eintrag, keine Änderung.docs/explanation/unddocs/reference/geprüft: keine Seite beschreibt das Ende eines Ingest-Laufs oder die Session-Id-Grenze, keine Änderung.instructions syncnach jeder Änderung;CHANGES.mdüber zweiversion bump --patch.Keine Code-Änderung:
raw pendingnennt die Zahl der Wartenden schon,raw statusdie geänderten Bundles.Akzeptanzkriterien
instructions/wiki-ingest/SKILL.mdenthält keinen Satz mehr, der mehr als einen Eintrag oder ein Bundle pro Lauf vorsieht (grep -n "Each further bundle"leer)./clearund den nächsten Auslöser nennt, und sagt ausdrücklich, dass der Agent den nächsten Lauf nicht selbst beginnt; warten keine, entfällt die Zeile./clearohne Harness-Unterscheidung.docs/how-to/capture-repository-docs.mdbeschreiben das Ende eines Laufs gleich.docs/how-to/ingest-a-source.mdnennt den Reset zwischen zwei Läufen und den Grund.instructions/capture-session.mdSchritt 5 sieht keine Delegation vonwiki-ingestan Subagents mehr vor (grep -n "delegat" instructions/capture-session.mdohne Treffer).tools/wikitool instructions verify,tools/wikitool docs verifyundpytestgrün; CI auf beiden veröffentlichten Commits grün (737/738, 739/740).Versionsteil
--patch, zweimal: nur Anweisungs- und Doku-Text ausgelieferter Dateien, kein Befehl, Flag, Dateiformat oder Pflichtfeld geändert; Drop-in vorwärts und rückwärts. Gebucht als 10.1.0-beta.13 und 10.1.0-beta.14 im MINOR-Kandidaten 10.1.0.Nicht in diesem Paket
ingest-large-tree.mdlaufen ebenfalls nacheinander in einem Kontext. Dort trägtwork/<runkey>/README.mdden Stand, ein Lauf lässt sich nach einem Reset fortsetzen, und das Lesen in Teilen begrenzt den Kontext schon. Ob zwischen Units ein Reset empfohlen wird, ist eine eigene Frage, die der Stub nicht stellte; kein Issue dafür angelegt.Ausarbeitung des Stubs (2026-10-15). Wortlaut des Stubs, wie er im Body stand:
Changelog: Body gegen den Baum (10.1.0-beta.12) ausgearbeitet: Befund (Regel „ein Lauf, eine Quelle“ existiert seit #112, aber kein Ende des Laufs; Repo-Zweig schreibt die Schleife sogar vor und widerspricht der How-to; Budget kippt beim 2.–3. Ingest im selben Kontext), Harness-Tabelle zu Reset-Befehl und Subagents, vier offene Entscheidungen F1–F4 mit Empfehlung, Dateien, Kriterien, Versionsteil
--patch. Labels:status/incomingentfernt,area/kbkind/decisionprio/plannedsize/S.wiki-ingest ohne Argument arbeitet alle wartenden Dateien in einem Kontext ab – /clear dazwischen oder Subagents, und in welchen Harnesses?to wiki-ingest: ein Lauf endet nach einer Quelle mit Stopp und /clear-Empfehlung – keine Schleife im selben Kontext; Subagents geprüftChangelog: F1–F4 entschieden (Betreiber: alle Empfehlungen angenommen) – „Offene Entscheidungen“ ist jetzt „Entscheidungen“ mit Begründung, Subagents als verworfener Ansatz dort eingeordnet. Neu:
instructions syncin der Dateiliste, Kriterium für den Entscheidungspunkt „im selben Kontext weitermachen“.kind/decision→kind/build.Changelog: Gebaut und als 10.1.0-beta.13 veröffentlicht (Commit
3197acf), CI-Läufe 737 und 738 grün. Body auf den erreichten Stand umgeschrieben: Umsetzung und Kriterien abgehakt, F1–F4 als umgesetzt markiert. Neu gegenüber der Planung:instructions/gates.md§ Taking a new session id nennt den ausdrücklichen Nutzerwunsch „im selben Kontext weiterzumachen“ als zweite legitime Grenze für eine neue Id – sonst hätte der Entscheidungspunkt des Skills der Regel „nur an einerplan.md-Grenze“ widersprochen.Changelog: Abschluss. Staleness-Prüfung fand zwei Stellen, die der
gates.md-Zusatz veraltet hatte:session-setup.md§ Multi-unit runs wiederholte die alteplan.md-Regel (verweist jetzt nur noch aufgates.md), undgates.mdzählte „two cases“. Nachgezogen als 10.1.0-beta.14 (b219add), CI-Läufe 739/740 grün. Body in Endzustand gebracht („Stand“ → „Ergebnis“ mit beiden Veröffentlichungen),docs/explanation/unddocs/reference/ohne Änderungsbedarf. Geschlossen.