fix(agent): detect a repeated same-tool fan-out

[LukasParke]

The gap

#73 keys a tool's streak on its last fingerprint (this.tools.get(toolName)), so a fan-out of distinct arguments reissued verbatim never accumulates evidence. Each round's first call has a different fingerprint than the previous round's last call, which resets the streak to 1 before the matching call arrives.

Measured against main before this change:

8 rounds x 3 distinct-arg calls (read a/b/c):  detections = 0
control, 1 call per round (read a):            none, observe, block, block

Zero detections across 24 calls the model had no business making. read(a), read(b), read(c) on repeat is the dominant shape in parallel-tool-calling agents, so this is the common case rather than an edge one.

Worth being precise about what #73 does handle: N identical calls fanned out in one round correctly count once (the duplicateInRound path, B3 in the remediation suite). The miss is specifically distinct arguments across a repeating round.

The fix

A round's identity for one tool is now the set of fingerprints it was called with, compared across rounds — not the last call.

The set is only complete once every call in the round has arrived, so a fan-out scores on the call that completes the match, and the round's earlier calls report the pre-match streak. That is deliberate: a partial fan-out genuinely is not yet a repeat.

r0: none, none, none
r1: none, none, observe     <- set matches r0 on the third call
r2: none, none, block

Ordering within the round does not matter (the set is sorted), a changed member resets the streak, and a strict subset is not a repeat.

Unchanged: single-call round timing, in-round duplicate collapsing, and verdict payloads. The persisted shape gains one additive optional field (roundFingerprints on DoomLoopStreak) so a fan-out's streak survives save/resume paired with the set that earned it; old blobs restore with their old semantics. Resumed single-call streaks behave exactly as before.

Tests

7 new tests in doom-loop-fanout.test.ts:

• accumulates across repeated fan-out rounds
• order-insensitive within a round
• resets when membership changes
• a strict subset is not a repeat
• single-call rounds behave exactly as before
• in-round duplicates still count once
• a resumed streak still increments after restore()

3 of the 7 fail without the fix — verified by stashing the change and re-running.

Verification

• vitest run (packages/agent): 753 passed, 61 files — the 115 existing doom-loop tests all still pass
• tsc --noEmit: clean (needed exactOptionalPropertyTypes care on the new optional fields)
• biome check: clean
• Changeset: patch

Context

Found while evaluating whether #73 supersedes the router-side port in openrouter-web#30170. It largely does — the ladder, escalation, text detectors, and in-loop stop are all things the router plugin cannot do from resolveEndpoints. This was the one axis where the router port was stronger, because the same gap was caught there in review and fixed by keying on a round fingerprint. Closing it here so the router can drop its duplicate and depend on the SDK.

Also verified while I was in here, no action needed: the two-tier fail-open in model-result.ts:1344 (raw-args fallback, then skip-detection) is correctly per-call, so one unhashable value cannot zero a whole request's detection.

One thing I did not change, flagging for a decision: the detector ignores tool results, so identical arguments with changing results reach block by round 3 — a polling tool returning running then done looks like a loop. loopKey: false is the intended exemption, but it is opt-out per tool rather than automatic. Folding a result digest into the round identity would make polling self-exempting; happy to follow up if you want that.

API example

For callModel users, doomLoop is configured exactly as before — what changed is when it fires:

import { callModel } from '@openrouter/agent';

const result = callModel(client, {
  model: 'z-ai/glm-5.2',
  input: 'Summarize these files.',
  tools: [readTool],
  // Unchanged config; ladder default is observe@2, block@3, stop@6.
  doomLoop: true,
});

// Model reissues the SAME three-call fan-out every round:
//   round 1: read(a), read(b), read(c)
//   round 2: read(a), read(b), read(c)   <- identical set
//
// was: no detection, ever — each round's first call reset the streak, so a
//      fan-out spun indefinitely while single calls tripped at round 2.
// now: round 2 -> streak 2 (observe), round 3 -> streak 3 (block), and EVERY
//      call of the round is refused at block, so the fan-out stops spending.
//
// A round that ADDS work is progress, and resets to 1:
//   round 3: read(a), read(b), read(c), read(d)   <- no verdict
//
// `loopKey` still runs exactly once per checked call. Persisted state gains
// one additive optional field so fan-out streaks survive save/resume.

API example — new public surface

This PR adds public API: DoomLoopMonitor.declareRound, plus resolveDoomLoopOption and ResolvedDoomLoopConfig exports (the monitor was previously exported without its config resolver, so it could not be constructed from the package at all). Consumer usage:

import { DoomLoopMonitor, resolveDoomLoopOption } from '@openrouter/agent';

// now: constructible from the public entrypoint (was: TS2345 / not exported)
const monitor = new DoomLoopMonitor(resolveDoomLoopOption(true));

for (const [round, batch] of batches.entries()) {
  // NEW: declare the round's complete set BEFORE recording any of its calls.
  // Undeclared multi-call rounds are scored per call and accumulate only on
  // the last-recorded member, order-dependently.
  await monitor.declareRound(
    round,
    batch.map((call) => ({ toolName: call.name, keyMaterial: call.arguments })),
  );
  for (const call of batch) {
    const { verdict } = await monitor.recordToolCall(call.name, call.arguments, round);
    if (verdict?.action === 'block') refuse(call, verdict.message);
  }
}

// State round-trips as plain JSON, so per-turn serverless topologies
// accumulate fan-out evidence across process boundaries.

Note on the implementation, since review

The first commit scored a round's fingerprint set as it accumulated, which
made a superset round transiently match its predecessor — blocking calls that
represented real progress, order-dependently. The engine now declares a round's
complete set before any of its calls is scored (declareRound). Subsequent
commits fixed fallout from that seam: streak sharing is scoped to declared
members, a non-member can no longer clobber the round's set, and loopKey runs
once per checked call. See the review threads for the full trail.

---

[cortex-github-agent]

A round that is a strict superset of the previous round transiently matches it, so a progressing round can be blocked.

The set is compared after every call while the round is still filling, so any round whose prefix (in sorted-merge terms) momentarily equals the prior set scores as a repeat — including rounds that add new work.

Trace with the default ladder (observe 2 / block 3 / stop 6)

r0 = [a,b], r1 = [a,b], r2 = [a,b,c] (the model added a third file — real progress):

r1: a -> streak 1        (set [a]   != prior [a,b])
    b -> streak 2        (set [a,b] == prior [a,b])   observe   ✔ correct
r2: a -> streak 1        (set [a]   != prior [a,b])
    b -> streak 3        (set [a,b] == prior [a,b])   BLOCK     ✘ read(b) is refused
    c -> streak 1        (set [a,b,c] != prior)

checkDoomLoopBeforeExecution turns that verdict into a hook_blocked outcome (model-result.ts, runToolWithHooks), so a legitimate call never executes and the model gets a "you are looping" error instead of its result. On main all three r2 calls score 1 and nothing fires.

It is also order-dependent, which contradicts the PR's "ordering within the round does not matter": emitting r2 as [c,a,b] never produces the transient match and nothing fires. Same shape applies to expanding fan-outs ([a], [a,b], [a,b,c], …), which accumulate streaks they should not.

The tests cover the strict-subset direction ("does not treat a partial repeat as a repeat") but not the superset direction, which is the one that fires.

Options: score a round's identity only once it is known complete (evaluate the previous round at the next round boundary, accepting one round of detection latency), or gate mid-round matches so a set that later grows cannot have already produced a blocking verdict. Either way, please add a superset regression test ([a,b], [a,b], [a,b,c] ⇒ no verdict on b).

[LukasParke]

Confirmed — reproduced all three claims against head (f46f74c), with the default ladder:

[a,b], [a,b], [a,b,c]  => [["none","none"],["none","observe"],["none","block","none"]]
[a,b], [a,b], [c,a,b]  => [["none","none"],["none","observe"],["none","none","none"]]
[a], [a,b], [a,b,c], [a,b,c,d]
                       => [["none"],["observe","none"],["none","observe","none"],["none","none","observe","none"]]

So read(b) is blocked in a round that added new work, the same round emitted in a different order fires nothing, and expanding fan-outs accumulate streaks. The order-dependence is the part I think settles it: the PR claims ordering within a round does not matter, and it demonstrably does. (Devin flagged the same thing and left it as a judgment call; I read the permuted case as making it a bug rather than a defensible trade-off.)

Root cause is that roundFingerprints grows incrementally but is compared against a completed prior set, so any prefix that transiently equals the prior set scores. Retracting after the fact cannot work — the block has already been returned and the call refused.

Not pushing a fix yet: the sound options change semantics the module documents as a cross-port spec, so I have taken the direction to the author rather than picking one myself. Leaving this thread open. The superset and order-permuted regression tests you asked for will come with the fix.

[LukasParke]

Fixed in eb3b51d — took your first option, adapted to avoid the latency cost.

Rather than deferring evaluation to the next round boundary, the engine now declares a round's complete call set before any of its calls is scored (declareRound, called from all three beginDoomLoopRound sites — they each already had the batch in hand). So the comparison is whole-round against whole-round with no detection latency, and single-call timing is untouched. I avoided boundary scoring specifically because it would shift single-call rounds from none, observe, block, block to none, none, observe, block, breaking the "unchanged: single-call rounds" guarantee for the most common shape.

Verified against your trace — the superset round now scores nothing, and the permuted form is identical:

[a,b], [a,b], [a,b,c]  => [...,["observe","observe"],["none","none","none"]]
[a,b], [a,b], [c,a,b]  => identical

Both regression tests you asked for are in, plus an expanding-fan-out case. All three fail against f46f74c with the buggy values.

Your other four findings are also addressed in the same commit:

• restore() dead state — confirmed unreachable and removed. priorStreak was only read under isSameRound, which needs previous.round !== undefined, and restore() deliberately leaves round unset. I split the remaining in-round duplicate tracking into a separate seenThisRound field so the two roles are no longer conflated.
• Stale docs — updated the recordToolCall docstring, the file-header "Round-scoped streaks" bullet (now states the round-set rule and the declare-before-scoring requirement for the Python/Go ports), and DoomLoopVerdict.streak. The verdict message no longer claims "identical arguments" for a fan-out; it says "the same set of arguments" and notes the parallel-call count.
• Partial mitigation at the block rung — fixed rather than documented. Every call in a repeating round now reports the round's streak, so a blocked fan-out stops spending entirely instead of executing N-1 calls per round. That is the one intentional behavior change beyond the bug fix.

[cortex-github-agent]

Summary

Keys a tool's per-round doom-loop identity on the set of fingerprints seen in the round instead of the last call, which genuinely closes the repeated-fan-out gap. But because the set is compared after every call while the round is still filling, a round that is a strict superset of the previous round transiently matches it and can fire observe/block/stop on a call that represents real progress — order-dependently, and untested.

Findings (5)

🟠 major · packages/agent/src/lib/doom-loop.ts:994-998
Mid-round set comparison makes a superset round match the previous round transiently. With r0=[a,b], r1=[a,b], r2=[a,b,c], the b call of r2 sees set [a,b] == prior [a,b] and scores streak 3 -> block, so a legitimate call is refused via checkDoomLoopBeforeExecution/runToolWithHooks (model-result.ts) even though the round added new work. On main nothing fires. The behavior is also emission-order dependent (r2 emitted as [c,a,b] fires nothing), contradicting the PR's 'ordering within the round does not matter'. Expanding fan-outs ([a], [a,b], [a,b,c], …) likewise accumulate streaks they should not.

🟡 minor · packages/agent/tests/unit/doom-loop-fanout.test.ts:150-166
The suite tests the strict-subset direction ('a strict subset is not a repeat') but not the superset direction, which is the case that actually produces a verdict. Add [a,b], [a,b], [a,b,c] asserting no verdict on the middle call, plus an order-permuted variant of the same superset round.

🟡 minor · packages/agent/src/lib/doom-loop.ts:907-914
restore() sets priorStreak: entry.streak, but round is intentionally left undefined, so isSameRound can never be true on the first resumed record and that field is never read — dead state that suggests a semantic it does not have.

🟡 minor · packages/agent/src/lib/doom-loop.ts:1035-1041
Docs are now inconsistent with the implemented semantics: the recordToolCall docstring still states 'A different fingerprint for the same tool resets the streak to 1', the file-header 'Round-scoped streaks' bullet and DoomLoopVerdict.streak ('consecutive identical-fingerprint round count') describe last-call keying, and the verdict message tells the model the tool was invoked 'with identical arguments (fingerprint X…)' — false for a distinct-argument fan-out, where the quoted fingerprint is only the completing call. Since the module advertises itself as the cross-port spec, the round-set identity should also be stated for Python/Go ports.

1 more finding(s)

🟡 minor · packages/agent/src/lib/doom-loop.ts:992-998
At the block rung only the call that completes the set is refused; the other N-1 calls of a repeating fan-out still execute every round (they report the pre-match streak). Detection now works, but mitigation is partial until the stop rung is reached — worth documenting so users do not expect a blocked fan-out to stop spending.

[perry-the-pr-reviewer]

Perry's Review

Verdict: 💬 Comments / questions
Risk: 🟢 Low

Details

Summary

This PR fixes a real gap in doom-loop detection: streaks were keyed on a tool's last fingerprint, so a repeating fan-out of distinct arguments (read(a), read(b), read(c) reissued verbatim every round) never accumulated evidence. The fix rekeys a round's identity on the set of fingerprints it was called with, compared across rounds. I traced the core logic through every test scenario (distinct fan-out, order-insensitivity, membership change, strict subset, single-call rounds, in-round duplicates, resumed streak) and the streak math is correct in each case. The new fields (roundFingerprints, priorRoundFingerprints, priorStreak) are run-local and never enter getState(), so persisted state is byte-identical — confirmed by reading the serialization path. duplicateInRound semantics also improved: it now catches non-consecutive duplicates within a round (e.g. read(a), read(b), read(a)), which the old last-fingerprint comparison missed.

One suggestion

The restore() path seeds roundFingerprints with only the last call's fingerprint ([entry.fingerprint]) and leaves priorRoundFingerprints absent. For a single-call streak this is fine — the resumed first call matches and increments. For a fan-out streak, the full round set is lost on serialize/resume, so the streak resets to 1 instead of continuing from the persisted value. This is consistent with the PR's stated design ("run-local, never serialized"), but it means a doom loop that spans a serialize/resume boundary (e.g. an approveToolCalls pause) gets a fresh 3-round grace window before re-detecting. A test documenting this behavior — that a resumed fan-out streak resets while a single-call streak continues — would pin the intended semantics for future readers and catch any accidental change.

Notes

• CI is all green (lint, typecheck, unit-tests, e2e-tests, structural-gate).
• The verdict message for a fan-out shows the latest call's fingerprint (not the full round set), which is a minor display nit but not worth blocking on.
• The duplicateInRound behavior change (non-consecutive duplicates now count) is an improvement and is handled correctly by the engine's doomLoopRoundDecisions map.

[perry-the-pr-reviewer]

▶ Prompt for agents

Suggestion: add a test documenting the resumed fan-out behavior.

restore() seeds roundFingerprints with only the last call's fingerprint ([entry.fingerprint]) and leaves priorRoundFingerprints absent. For a single-call streak this works (the resumed first call matches and increments — tested). For a fan-out streak the full round set is lost on serialize/resume, so the streak resets to 1 instead of continuing from the persisted value.

This is consistent with the PR's stated design ("run-local, never serialized"), but it means a doom loop that spans a serialize/resume boundary gets a fresh grace window before re-detecting. A test asserting that a resumed fan-out resets to streak 1 (while a single-call streak continues) would pin the intended semantics and prevent future regressions.

[LukasParke]

Agreed on the test, and the same block has a second issue worth folding in.

restore() sets priorStreak: entry.streak (line 913), but priorStreak is only read at line 997, inside the isSameRound branch — and isSameRound requires previous.round !== undefined, which restore() deliberately leaves absent. So that field is dead on every resumed record. Cortex flagged it independently; I traced the read and it is genuinely unreachable.

One correction on the summary: the review says the streak math is correct including order-insensitivity. That holds for the scenarios the suite covers, but the suite only tests the strict-subset direction. The superset direction is untested and does fire — reproduced against head:

[a,b], [a,b], [a,b,c]  => [["none","none"],["none","observe"],["none","block","none"]]
[a,b], [a,b], [c,a,b]  => [["none","none"],["none","observe"],["none","none","none"]]

Same round, same history, different emission order, different outcome — so order-insensitivity does not hold in general, and read(b) gets blocked in a round that added new work. Details on the two threads at lines 996/998. Flagging since the verdict was "would be APPROVE" partly on that basis.

Both tests (resumed fan-out, and the superset/permuted regressions) will land with the fix. Leaving this open until then.

[LukasParke]

Both done in eb3b51d.

Your test — added restarts a resumed FAN-OUT streak at 1, unlike a single-call streak, asserting exactly the asymmetry you described: a two-call fan-out at streak 2 restores to streak 1, while the existing single-call test still shows 3. Comment explains why the round set stays run-local (persisting it would change the state shape, which this PR guarantees is unchanged) and that a loop spanning a resume gets a fresh grace window.

The dead field — removed. I also split the in-round duplicate tracking into its own seenThisRound field, since the old roundFingerprints was doing double duty as both "the round's identity" and "what we have seen so far", which is what made the dead state easy to miss.

The superset issue from my earlier comment is also fixed in that commit: the engine declares a round's complete set before scoring any of its calls, so order-insensitivity now holds for supersets too, not just the permutations of a fixed set that the suite already covered. Worth a look if you revisit — the verdict summary's claim about the streak math was based on the tests that existed, and there are now four more.

CI green, 758 tests (5 new).

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

📝 Info: Undeclared multi-call rounds now match anywhere in the round, not just in the final position

The fixed-at-transition baseline changes undeclared (server-tool / direct-caller) semantics relative to the old last-fingerprint comparison: previously the second call of a round was compared against the first call of the same round, so [a] then [b, a] scored a as 1; now a is compared against the round-transition baseline [a] and scores 2 (observe). This is documented in the README limits section and is arguably more correct (a genuinely recurred in consecutive rounds), but it does mean server-tool verdicts can now fire one round earlier for some emission orders, and server-tool streaks can reach stop.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[LukasParke]

Confirmed against pre-PR main and documented in f8584f5 — your trace is exact:

round0=[a], round1=[b,a], undeclared:
  main (78c562e): b=1, a=1   (b overwrote the last fingerprint; a reset)
  this PR:        b=1, a=2   (baseline fixed at the round transition)

Intentional, and I am keeping it, for three reasons:

1. It is strictly more detection with no new false-positive path. Every increment still requires the fingerprint to have been genuinely issued in the previous round — the fixed baseline only stops a mid-round sibling from DESTROYING evidence by overwriting the comparison point. a really did repeat across consecutive rounds; the old 1 was the accident, not the new 2.
2. The fixed baseline is what makes declared rounds order-independent. Reverting the undeclared path to "compare against whatever was recorded immediately before" would mean two baseline mechanisms, and the last several bugs on this PR all lived in exactly that kind of dual-path divergence.
3. Order-dependence remains, but only in the harmless direction: which member accumulates still depends on what the PREVIOUS round recorded last, but within the current round a match now counts anywhere rather than only in final position — less order-sensitive than before, not more.

The README bullet now spells out the mid-round match ([a] then [b, a] scores a as a repeat even though b arrived first) alongside the last-member shape it already described. Declared rounds — every batch the tool loop executes — are unaffected either way.

[LukasParke]

Confirmed, and documented in the README limits section. Leaving open deliberately: this is a semantic change to undeclared (server-tool / direct-caller) rounds rather than a defect, and it pairs with the scope question on the per-call detector below. Flagging both for a human call before merge rather than resolving unilaterally.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Per-call streaks are a second, independent detector that fires without any declaration — new detections beyond the fan-out fix

The PR title/description frames the change as "detect a repeated same-tool fan-out", but the shipped implementation adds a second detector: callStreaks at packages/agent/src/lib/doom-loop.ts:1227-1233 counts every (tool, fingerprint) identity's consecutive rounds independently, and Math.max(streak, callStreak) at packages/agent/src/lib/doom-loop.ts:1294 lets it decide alone. This changes verdicts on paths the fan-out work does not touch: an undeclared multi-call round (server-tool records via checkDoomLoopForResponse in packages/agent/src/lib/model-result.ts:1844, and any direct DoomLoopMonitor consumer) previously accumulated only on whichever call was recorded last, and now every repeated member accumulates. It also means a round that adds new work ([a,b] → [a,b,c]) still blocks a and b from round 3, so an agent that re-reads a stable anchor file while making genuine progress is refused unless the tool opts out with loopKey: false. The changeset does document this as a newly reachable false-positive class, but it is worth a deliberate product decision rather than being read as a side effect of the fan-out fix.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[LukasParke]

Confirmed on every particular, and worth stating plainly: this is NOT a side effect — it is a deliberate product decision, made explicitly by the author, and the framing you are asking for exists on the record.

The sequence: I documented the varying-round and HITL gaps as known limits and put the per-call-streak design (originally your suggestion, on the varying-round thread) to the author as a build/no-build decision, including the false-positive cost. The author's direction was to build it, with the reasoning that a truly identical repeated call SHOULD flag — re-reading a file that is already in context is waste, not progress, and a deliberately-repetitive tool declares itself with loopKey: false/null. The stable-anchor-read shape you name was specifically weighed and accepted on those grounds.

Your undeclared-path observation is also right and also intended: per-call evidence needs no declaration, which is precisely what fixed that path's order-dependence (previously only the last-recorded member accumulated; now every repeated member does, emission-order-independently).

On the title framing: fair. The PR grew from "detect a repeated fan-out" to "two-detector design" across the review; the PR description's implementation note and the changeset both describe the per-call detector, its verdict-message behavior, and the false-positive class with the opt-out. I have kept the changeset as the authoritative consumer-facing description since it is what ships to the changelog.

No code change from this thread; the decision trail is the answer.

[LukasParke]

This is the right question and I am escalating it rather than resolving it. Confirmed at head: callStreaks counts every (tool, fingerprint) identity independently and Math.max(streak, callStreak) lets it decide alone, so it does change verdicts on paths the fan-out work does not touch — including the [a,b] → [a,b,c] case where a stable anchor file re-read gets refused while genuine progress is being made.

Two options for the human: (1) ship as-is and retitle, since the PR currently claims only the fan-out fix while shipping a second detector; or (2) gate the per-call detector behind an opt-in and land the fan-out fix alone, deferring the broader detection. Given this feature is slated to be announced on its own day as a first step, option 2 is the more conservative launch. Leaving open for that decision.

[LukasParke]

Re the CHANGES_REQUESTED review at f46f74c — all five findings were addressed in the 20 commits since; head is now d956562 (main merged in). Detail:

🟠 major — mid-round superset match. Fixed by eb3b51d ("score a doom-loop round's declared set, not a growing prefix"). Scoring is no longer done against a filling prefix, so [a,b], [a,b], [a,b,c] no longer blocks the b call. Three tests guard it: flags the repeated members of a superset round, never the new one, scores a superset round the same whatever order it is emitted in, and the expanding-fan-out case (doom-loop-fanout.test.ts:206-276).

🟡 missing superset test coverage. Added by the same commit — including the order-permuted variant you asked for.

🟡 restore() priorStreak dead state. priorStreak is live now, read at doom-loop.ts:1224 to carry a prior round's count across the same-round check.

🟡 stale docs / verdict message. The verdict builder branches on callSet.length > 1 and emits "the same set of N parallel calls (round identity …)" for fan-outs; "identical arguments (fingerprint …)" is only used for genuine single-call repeats, so it is no longer false. Round-set identity is documented in the README as the cross-port contract.

🟡 partial mitigation at the block rung. Now inaccurate as written — every declared member of the round receives the verdict, not just the completing call, and the README states this explicitly ("because every call in the round gets the verdict, that is N synthesized error outputs per round, not one").

Verification at head: 86/86 doom-loop tests pass, typecheck and lint clean. Two failures in hooks-contract-fixes.test.ts (vi.advanceTimersByTimeAsync is not a function) reproduce on clean origin/main at d030602 and are unrelated to this branch.

Two threads left open deliberately for a human decision — the per-call detector's scope, and the undeclared-round semantics change. Those are product calls, not defects.

[LukasParke]

Correction to my previous comment: the two hooks-contract-fixes.test.ts failures I mentioned were an artifact of my running bun test directly instead of the repo's runner (bun run test → turbo → vitest). Under the correct runner this branch is fully green at d956562:

• @openrouter/agent: 53 files, 675 tests passed, no type errors
• @openrouter/mcp: 9 files, 39 tests passed, no type errors

No pre-existing failures on main either — that claim was wrong and I'm retracting it. Lint clean, typecheck clean.