Runs that go in circles end (M7.8)

Driver.run checks each turn with nisse_core.loop.circles and ends the run
as "circling" when the same calls get much the same back, one harness
correction is given again and again, or the model apologises, for
circle_repeats turns in a row (default 3). Near-identical calls (git add
a.py, b.py) and scattered apologies stay flags on the status page. A
fact in the transcript says why the run ended.

nisse-dev calls in a helper as for a stuck run, then asks the operator;
nisse-review counts a failed run and posts none of its drafts. Tuning:
tuning.driver / tuning.review circle_repeats (0 off) and circle_similar.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk

docs/Development-Plan.md

@@ -811,7 +811,12 @@ every agent. Seen 2026-10-24 on Flash-Next: invented tool names met with the
 prose reminder turn after turn, and a no-thinking run posting the same apology
 comment about 20 times until the turn cap. Repeated near-identical turns, or the
 same correction given too often, end the run as escalated, with what it was
-doing; the limits are tuning.
+doing; the limits are tuning. **Done** (this PR): `RunOutcome("circling")`
+after the same calls getting much the same back, one correction, or apologies,
+`tuning.*.circle_repeats` turns in a row (3). Near-identical calls only flag on
+the page (`git add a.py`, `b.py`). nisse-dev calls in a helper as for a stuck
+run, then asks; nisse-review counts a failed run and posts none of its drafts.
+The helper's own loop keeps its caps.
 
 ### Phase 8 — `nisse-ops`
 

docs/Tuning-Guide.md

@@ -193,6 +193,28 @@ looking around, not doing the work. Before M2.8 this was
   (escalation is doing its job). Second, how often the local model recovers
   on its own after its second failure (the limit may be too low).
 
+### `tuning.driver.circle_repeats` — default 3, and `circle_similar` — default 0.9
+
+When a driver run going in circles ends (architecture L2, M7.8), escalated as
+for `failure_limit`: a helper first, then you. A run circles when it makes
+the same tool calls this many turns in a row and gets much the same back
+each time, when the harness gives one correction this many times ("no such
+tool: …"), or when it apologises this many turns in a row. `circle_similar`
+is how alike two replies' text and two turns' results must be (0 to 1). 0
+for `circle_repeats` never ends a run this way; 1 isn't allowed, since every
+run would end at its first turn.
+
+- **Why only the same calls:** `git add a.py`, then `b.py`, then `c.py` are
+  near-identical and each gets the same empty answer, but they are progress.
+  The status page flags near-identical turns too, and scattered apologies;
+  the driver ends a run only on what can't be progress.
+- **Too low:** a model checking the same thing twice is cut off. 2 is the
+  least that means anything.
+- **Too high:** a looping run spends that many more turns, and context.
+- **Measured:** Qwen3.8-Flash-Next (2026-10-24) posted the same apology
+  comment about 20 times until the turn cap; 3 would have ended it at the
+  third.
+
 ### `tuning.preflight.max_turns` — default 20
 
 How many model calls one toolchain step may make (D3). The harness starts one
@@ -673,6 +695,12 @@ Failed review runs on one PR, at one head, before the reviewer says on the PR
 that it couldn't review it, and stops trying until the next push or an
 operator's `review` comment.
 
+### `tuning.review.circle_repeats` — default 3, and `circle_similar` — default 0.9
+
+As `tuning.driver.circle_repeats`, for review runs. A review run going in
+circles is a failed run (it counts toward `attempts`), and what it drafted is
+dropped rather than posted: the drafts are the repeats.
+
 ### `tuning.review.ci_wait_s` — default 3600
 
 How long a new head's review waits while its checks are pending. A review