While getting the test suite green on a fresh clone I noticed pipeline-per-detector.test.ts > fires echo_chamber fails — the pipeline returns load_bearing_vibes instead.
Digging in, I think the #129 tuning made echo_chamber unreachable in practice. Any user claim that qualifies for echo (vibes/assumption basis with 2+ assistant supports) now also qualifies for load_bearing_vibes, since supports count toward downstream and both minimums are 2. Selection has no per-type priority, so load_bearing always wins on the same anchor.
Not sure what the right answer is — maybe rank echo above load_bearing when both fire on the same anchor, or accept that load_bearing covers those cases now and retire echo. Happy to take a swing at it if there's a preferred direction. For now my tests PR just pins the current behavior so the suite is honest about it.
While getting the test suite green on a fresh clone I noticed
pipeline-per-detector.test.ts > fires echo_chamberfails — the pipeline returnsload_bearing_vibesinstead.Digging in, I think the #129 tuning made echo_chamber unreachable in practice. Any user claim that qualifies for echo (vibes/assumption basis with 2+ assistant supports) now also qualifies for load_bearing_vibes, since supports count toward downstream and both minimums are 2. Selection has no per-type priority, so load_bearing always wins on the same anchor.
Not sure what the right answer is — maybe rank echo above load_bearing when both fire on the same anchor, or accept that load_bearing covers those cases now and retire echo. Happy to take a swing at it if there's a preferred direction. For now my tests PR just pins the current behavior so the suite is honest about it.