Skip to content

Update detector spec tests to match the #129 threshold tuning - #151

Open
InfinitePortaldev wants to merge 1 commit into
fiorastudio:masterfrom
InfinitePortaldev:detector-spec-tests
Open

Update detector spec tests to match the #129 threshold tuning#151
InfinitePortaldev wants to merge 1 commit into
fiorastudio:masterfrom
InfinitePortaldev:detector-spec-tests

Conversation

@InfinitePortaldev

Copy link
Copy Markdown

npm test currently fails on a fresh clone — five of the detector spec tests still assume the stricter pre-#129 thresholds.

This updates the fixtures and expectations to the tuned values:

  • below-threshold cases now sit below the current minimums
  • the challenged-chain case challenges every sub-chain long enough to qualify (the detector walks a chain from every node, so a sub-chain below the challenged pair is a candidate on its own)
  • the grounded_premise pipeline graph uses a single support so it stays under well_sourced's minimum
  • the echo_chamber pipeline case now pins what actually happens post-tuning (load_bearing_vibes wins) — see echo_chamber can't surface anymore after the #129 threshold tuning #150 for why that might deserve a real fix

Tests only, no behavior changes. The doctor and penguin failures on fresh clones are separate — sending PRs for those too.

The tuning in fiorastudio#129 left the older detector spec tests behind — they
still assume the stricter pre-tuning thresholds, so npm test fails on a
fresh clone. This updates the fixtures and expectations to the current
values. Tests only, no behavior changes.
@justinstimatze

Copy link
Copy Markdown
Contributor

Heads up — #156 builds on this branch, so please merge this one first.

It answers the open question you flagged here, so it puts the echo_chamber assertion back to expecting echo_chamber. Everything else you did is kept. The one place I went a different way is the challenged-chain fixture: rather than challenge every sub-chain, the detector now only starts from maximal chains, so a suffix can't qualify on its own. I left your extra edge in as belt-and-braces.

Also confirmed by running the suite against each PR separately — this fixes exactly its five failures and touches nothing else. Thanks for chasing all of these down.

fiorastudio pushed a commit that referenced this pull request Aug 1, 2026
…ion (#150)

Some detectors are specializations of others. `echo_chamber`'s predicate is
`load_bearing_vibes`' predicate plus three conjuncts (user speaker,
assistant-only supports, no pushback), so every echo case is also a
load-bearing case — one situation at two resolutions, not two competing
findings.

Selection takes candidates[0] within a category, so the general finding won
purely on the order detectors run in. The per-anchor cooldown made it
self-reinforcing rather than self-correcting: it keys on anchor_claim_id
without regard to type, so emitting the general finding also blocked the
specific one on that anchor. `echo_chamber` could not surface at all.

`SUBSUMES` names the containment; `runAllDetectors` drops a general finding
when a more specific one fired on the same anchor. Thresholds are untouched —

Also fixes two defects #129 exposed in the same area:

- `unchallenged_chain` fired on the unchallenged *suffix* of a challenged
  chain. The walk started from every node, so once the minimum length dropped
  4→3 a suffix below the challenged pair became a candidate in its own right.
  It now starts only from maximal chains, matching its documented "anchors on
  the head" intent.
- The "below threshold" / "below minimum length" fixtures hardcoded edge
  counts that #129's retuning turned into *at*-threshold cases, so they went
  green while testing nothing. They derive from REASONING_CONFIG now.

Three fixtures were mislabeled: they seeded a user vibes claim backed by
assistants with no pushback — a textbook echo chamber — and read as
load-bearing only because of the ordering bug. They now use an
assistant-authored anchor so they test what they claim to.

Builds on #151, which fixes the same five failures by pinning the current
behaviour and explicitly defers the real fix here. The two fixture sets
conflict and should not both be merged as-is.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFi4A9eG3CWPjDDMvdmUfy
fiorastudio pushed a commit that referenced this pull request Aug 1, 2026
The repo has no CI — .github/workflows contained only the stats updater — so
nothing has been running the test suite on PRs or merges. #129 shipped a red
suite in May and it stayed red until a contributor cloned the repo in July and
ran npm test by hand (#150, #151, #152, #153).

Node 20 (the engines floor) and 24, npm ci / build / test. `npm ci` compiles
better-sqlite3 from source when no prebuild matches the runner ABI, which is
the same path users hit on install, so a broken native build fails here too.

MERGE ORDER: this gates every PR the moment it lands, and the suite is not
green yet. #152 fixes the two doctor check-count failures and #153 fixes the
two Penguin frame-width/pose failures; those are the only four remaining, and
both PRs are open. Merge them first, or this red-gates unrelated work.

Note that CI could not have caught the bug fixed in the preceding commit: a
fresh runner has no ~/.claude transcript history, so resolveSessionTrace's
unbounded scan costs nothing there. Green CI is not evidence the suite is
sound on a real machine.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WFi4A9eG3CWPjDDMvdmUfy
@fiorastudio

Copy link
Copy Markdown
Owner

Thank you for the contribution!! We will be sure to review and circle back. Stay tuned for the upcoming 2.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants