wiki-ingest: ein Lauf endet nach einer Quelle mit Stopp und /clear-Empfehlung - keine Schleife über mehrere Einträge im selben Kontext; Subagents für den Ingest verworfen, capture-session delegiert nicht mehr; gates.md: neuer Lauf auf ausdrücklichen Wunsch ist eine Einheitsgrenze (#219); 10.1.0-beta.13

Files changed:
- CHANGES.md
- VERSION
- docs/how-to/capture-repository-docs.md
- docs/how-to/ingest-a-source.md
- instructions/capture-session.md
- instructions/gates.md
- instructions/wiki-ingest/SKILL.md

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

instructions/wiki-ingest/SKILL.md

@@ -11,7 +11,8 @@ description: Processes a new source file into the LLM wiki - extracts entities a
 directly into `raw/`, names a URL to ingest (step 1 fetches it into `incoming/` first), or
 explicitly requests ingestion - with or without naming what (step 1 picks the entry when nothing
 is named) - or asks to update the captured repositories (step 1 asks `raw status` which one moved).
-**One run is one source:** one file, one bundle or one folder.
+**One run is one source, in one context:** one file, one bundle or one folder. Step 12 ends the
+run and says what comes next; the run never goes on to the next entry by itself.
 
 **Before the first `wikitool` call:** `instructions/session-setup.md`.
 
@@ -100,10 +101,10 @@ validator complains - and the ticked list is the only record that they happened.
    - **One bundle per run:** the one the user named, otherwise the first changed one in the output.
      Announce it and carry on - which bundle, `old -> new` from its line, how many others changed,
      and any error lines as above; an error on one repository never stops the run for another. Ask
-     nothing here - step 4 is the halt before anything is written. Each further bundle is a run of
-     its own, started by the same request, so every run stays within the iteration budget and has
-     its own `publish`. A bundle the user named that is unchanged, or on an error line, ends the
-     run with that said - no other bundle is taken in its place unasked.
+     nothing here - step 4 is the halt before anything is written. The other changed bundles are
+     not taken up in this run: step 12 names them, and each is a run of its own in a fresh context.
+     A bundle the user named that is unchanged, or on an error line, ends the run with that said -
+     no other bundle is taken in its place unasked.
    - **Run the `raw capture --update <raw-bundle>` line printed under it.** `incoming/<bundle>/` is
      this run's source from here on, and step 1 continues as for any folder, the size check below
      included. A refusal - an `incoming/<bundle>` left over from an earlier run, for instance - is
@@ -466,8 +467,25 @@ validator complains - and the ticked list is the only record that they happened.
     deterministic count behind the "every 10 sources" cadence. If the threshold is reached,
     tell the user a full lint is due and offer to run `wiki-lint` next.
 
-    Then say how many entries still wait in `incoming/` (`tools/wikitool raw pending`), so the
-    user knows whether another run is due.
+    **Then the run ends - hard.** It ends here, not at the next entry. Count what still waits: the
+    entries `tools/wikitool raw pending` still lists, or, for a run that started from
+    `raw status`, the other changed bundles step 1 announced. If any wait, close with this one line
+    as the last thing you say, in the KB language (`AGENTS.md` § Conversation language), `N` being
+    that count:
+
+    > N more entries wait in `incoming/`. Next: `/clear`, then `ingest`.
+
+    For a captured-repository run:
+
+    > N more bundles changed. Next: `/clear`, then `update the captured repositories`.
+
+    If none wait, the line is left out. **Do not begin the next entry or bundle yourself**, and
+    take no "yes" or "go on" to the line above as the start of one without the decision point
+    below: the next source belongs in a fresh context, which only the user can open - `/clear`
+    does it, the same in every harness. Why: with this source still in context, the next run
+    writes its facts onto the other source's pages or cites them to the wrong raw file (no
+    validator sees that), and 20-35 `wikitool` calls per run put a second ingest in one context
+    against the 60-call budget.
 
 ## Decision points
 
@@ -509,6 +527,14 @@ validator complains - and the ticked list is the only record that they happened.
 - **`publish` exited 42?** A single ingest is normally well under the Mass-Update Gate
   threshold. If it trips - a source touching many entities - show the user the output and stop;
   see `instructions/gates.md`.
+- **The user asks to go on with the next entry in this context?** Their context is theirs to
+  decide, so this is not refused. Say once, in one or two sentences, that a fresh context is the
+  recommendation and why (the previous source stays in context and can leak into the next one's
+  pages and citations; the budget fits about two runs) - then follow. The new run is a planned
+  unit of its own with its own `WIKITOOL_SESSION_ID` (`instructions/session-setup.md`,
+  `instructions/gates.md` § Taking a new session id), and it ends with step 12 like the first.
+  The request, not a gate refusal, is what makes the new id legitimate: never take one to get
+  past a refusal.
 - **A gate or the loop-breaker refuses anything?** Stop and follow `instructions/gates.md`.
   A multi-tool ingest should land in roughly 20-35 `wikitool` calls; needing far more is a sign
   the source should be split into several ingests - which is