real LLM runs that hit 2+ consecutive REGRESSION_ROLLBACK

[wei9072]

Body

Aegis V1.6 (sweep evidence)
verified STALEMATE_DETECTED firing in real LLM traffic across two
model families (5/5 ling-2.6 + 3/5 minimax-m2.5 = 8/10 runs).

THRASHING_DETECTED is still mechanism-only — direct evidence
from real traffic has not been captured yet. This issue is an open
call for that evidence.

What "thrashing" means here

A run where the pipeline's REGRESSION_ROLLBACK decision pattern
fires 2 or more times in a row. That is, the planner produces a
patch, the executor applies it, post-apply signals worsen, the
executor reverts — and then on the next iteration the same thing
happens again.

When that pattern is detected, Aegis emits THRASHING_DETECTED
(decision_pattern.py) and terminates the loop with the reason
"thrashing detected — 2 consecutive regression rollbacks; further iterations would burn budget".

Why we don't have evidence yet

V1.6 verification used inclusionai/ling-2.6-1t:free and
minimax/minimax-m2.5:free. Both got stuck in validation_veto
chains before reaching Executor.apply() — which is the
precondition for REGRESSION_ROLLBACK. The state-stalemate detector
caught them; the thrashing detector never had a chance.

V1's pre-Gap-1 sweep showed gemma × regression_rollback did
produce 3 consecutive rollbacks, but that data is from before the
Gap 1 detector existed.

What you can submit

Any of the following is useful evidence:

1. A reproducible scenario that consistently produces 2+
   consecutive REGRESSION_ROLLBACK events on a model you have
   access to. Ideally something you can run with
   aegis scenario run <name> and share the JSON snapshot.
2. A JSON snapshot from a real Aegis run showing
   decision_pattern: "thrashing_detected" in any iteration's event.
   Drop it in this issue or attach a gist.
3. A model + scenario pairing you suspect would thrash but
   haven't tested. We'll add it to V1.7 sweep matrix.

How to capture a snapshot

git clone https://github.com/wei9072/aegis && cd aegis
pip install -e .  # (build instructions in README)

# Drop your scenario in tests/scenarios/<name>/ then:
PYTHONPATH=. python scripts/v1_validation.py \
    --scenarios <your-scenario> \
    --models openrouter:<your-model>:free \
    --runs 5

# Snapshots land in tests/scenarios/<name>/runs/*.json

If any run's observed_patterns array contains
"thrashing_detected", that's the evidence we need. Attach the JSON
file (or paste the relevant excerpt).

Why this is open-call instead of dev-team-fixes-it

Per
docs/v1_validation.md's framing section,
Aegis is "a behavior harness for LLM-driven systems — instead of
teaching models what is good, it rejects outcomes that make the
system worse." That framing implies: validation comes from real
traffic, not from synthetic test cases.

The thrashing detector works in unit tests
(tests/test_decision_pattern.py) but unit tests can't tell us
whether real-world LLM behavior exercises this code path. If your
agent pipelines through Aegis and you see thrashing fire, please
share — that's how the framework gets validated.

What success looks like

Closing this issue requires at least one snapshot from a real
(non-test) Aegis run where:

{
  "observed_patterns": [..., "thrashing_detected", ...]
}

Once captured, it lands in docs/v1_validation.md as the V1.7
section, mirroring how V1.6 documented STALEMATE evidence.

---

Thanks. This is the kind of validation the project can't generate by
itself.

[wei9072]

Status update — V1.8 sweep status (2026-04-29)

No direct THRASHING_DETECTED evidence captured yet.

Mechanism unchanged across the V1.10 cleanup. The
detector lives in
crates/aegis-runtime/src/loop_step.rs
(is_thrashing + the step_decision precedence rule that puts
thrashing above stalemate when both fire). Pure-function logic,
unit-test-pinned, mechanically equivalent to the V0.x Python
detector this issue references.

What's blocking direct evidence:

The V1 + V1.5 + V1.6 sweep evidence in
docs/v1_validation.md
was collected on the Python pipeline. The Rust aegis pipeline run
now exists and is the path for a fresh sweep, but V1.8 (cross-model
re-validation on the Rust pipeline) is gated on LLM API budget,
not code. ~70 minutes of wall-clock per sweep matrix at the cell
counts the previous sweeps used.

Most likely place to surface organically:

A capable model attempting an aggressive structural refactor
(LoD chain restructure, package-boundary moves) where every patch
makes one signal better and another worse. V1's gemma × regression_rollback run 3 produced
regression_rollback × 3 consecutive — the closest indirect
evidence we have. Re-running that exact cell on the Rust pipeline
is the cheapest experiment (single cell, ~14 minutes of API time).

Still an open call. If anyone running aegis pipeline run
captures a THRASHING_DETECTED trace in real traffic, please
attach the JSON output here.