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/capture-session.md

@@ -142,8 +142,9 @@ records the issue number, and the transcript stays what it is: evidence.
 
 ### 5. Ingest, one transcript at a time
 
-Run `wiki-ingest` per transcript. **Sequentially. Never in parallel**, even when delegating to
-subagents.
+Run `wiki-ingest` per transcript, **each as a run of its own in a fresh context** - `/clear`
+between two runs, as `wiki-ingest` step 12 ends every run. The transcripts are already in `raw/`
+after step 3, so the reset loses nothing. **Sequentially. Never in parallel.**
 
 Concurrent ingests of the same corpus collide in three places, and each collision is a silent
 lost write rather than an error:
@@ -155,10 +156,10 @@ lost write rather than an error:
 - **`publish`.** Two commits racing on one branch, and the Mass-Update Gate's `--confirm` token
   digests a file list that the other run is still changing.
 
-When delegating, give each subagent its own `WIKITOOL_SESSION_ID` so the budget is scoped per
-transcript rather than shared - see [session-setup.md](session-setup.md). Several ingests are
-several planned units, which is what makes a fresh id legitimate rather than a way around a
-refusal ([gates.md](gates.md)).
+**Not to subagents.** An ingest has stops only the user can answer - the key points and the
+commitment in step 4, `fidelity` and `authority` in step 5, a name collision at `raw accept`, an
+exit 42 - and a subagent cannot ask them. It would have to guess, which the skill forbids, or
+abort.
 
 Start the next one only after the previous has published and its tree is clean.
 

instructions/gates.md

@@ -229,6 +229,12 @@ never in response to a gate refusal.** The plan is the human approval the gate w
 have to ask for; a refusal means that approval has not been given yet. If you are tempted to
 re-export the variable after an `ERROR` line, that is the gate working.
 
+**A run the user explicitly asked to start in the same context is the other legitimate
+boundary.** `wiki-ingest` ends every run after one source and recommends `/clear`; when the user
+asks to go on in this context regardless, that request is the human approval, the finished run is
+the unit boundary, and the new run takes a new id ([wiki-ingest](wiki-ingest/SKILL.md) § Decision
+points). The agent never proposes this itself, and it is no way past a refusal.
+
 **One tool takes a new id itself, for a fixed set of read commands.** `tools/bugreport.py`
 ([bug-report.md](bug-report.md)) runs `instructions verify` and `docs verify` under
 `WIKITOOL_SESSION_ID=bugreport-<stamp>`, so that collecting a report neither spends the

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