[astubbs]

Serves #255.

depends on #394

Description

The claim this PR makes: this module's three outstanding evidence gaps are closed, and each is
closed with a gate that has been shown to go red - Apache Kafka's own suite now runs with the seam
ON and every divergence is classified by mechanism, the properties stock Kafka Streams cannot express
are asserted against a real broker with their controls, and the realistic keyed benchmark reports its
own noise floor beside every ratio.

Nothing here touches the seam. No main Java in parallel-consumer-streams changed, and the patch is
untouched - deliberately, because two sibling rungs are changing dispatch semantics on this same base.

1. The seam-on evidence lane

The seam-off oracle has always been the behaviour-preservation gate: the patch changes nothing
while the switch is off. This adds its opposite - what Kafka's own suite says about the path this
module actually ships - and, more usefully, a verdict on it.

Seam-on failures are expected, which is why the branch forest's version of this run recorded them
and gated on nothing. The refusal envelope throws where stock would have run a construct; a committed
offset is Parallel Consumer's frontier rather than Streams' consumedOffsets; a record handed to a
worker has not been processed by the time process() returns. A gate that goes red every build is a
gate people stop reading.

So the run and the verdict are separate surefire executions. kafka-upstream-tests-seam-on
carries testFailureIgnore and never reddens a build; seam-on-evidence-classification reads what it
wrote and fails when a divergence matches no named mechanism. That split is the only arrangement in
which "these failures are expected" and "a new divergence fails the build" are both true.

The seam-off run is the control arm, and the two are differenced case by case. A divergence is a
case that passes with the switch off and fails with it on; nothing else is attributable to the
dispatch path. A case failing in both arms is failing for a reason the seam had nothing to do with,
and counting it would credit a change that did not cause it.

Three mechanisms are derived from the code at run time, so a sibling rung changing the envelope
needs no edit here at all:

Mechanism	How it is recognised
refused-construct	the marker is the longest common prefix of every message PcUnsupportedConstruct can produce, and the attribution is whichever constant the message names. No refusal string is copied
commit-frontier-encoding	the assertion renders an OffsetAndMetadata, so it is an assertion about the commit encoding whatever the case is called
ledgered-flake	a flaky-case: marker in any docs/inflight/ note

What cannot be derived is attributed in the ledger, not in the classifier. "This assertion fails
because Kafka's test drives the task synchronously" is a judgement about a test, not a fact
recoverable from expected: <5> but was: <0>. Those live in
docs/inflight/test-streams-seam-on-divergence-triage.md, keyed by method rather than by
parameterisation, under four named classes - asynchronous-dispatch, stream-time-never-advances,
exception-type-lost-in-the-worker, split-poll-wait. Three consequences, all deliberate: the
reasoning is reviewed as prose by whoever changes the semantics under it; the PR that closes a
mechanism deletes its entries in the same change; and an entry that stops matching is reported as
stale rather than rotting silently.

The flake is absorbed by mechanism rather than by a retry. The invalid-timestamps flake has been
failing this module's oracle intermittently for weeks. Because the oracle fails fast, one sighting
used to abort the lane before the measured arm ran at all - Kafka's suite twice, re-run, for a failure
already diagnosed. The lane now relaxes that one execution and makes the verdict itself: every
control-arm failure must carry a flaky-case: marker, or the lane stops and says there is nothing
trustworthy to difference against. The ordinary build's oracle is untouched and still fatal.

One inherited finding is corrected. The forest's triage counted that flake's seam-on failure as
the flake firing. It is attributed here to asynchronous-dispatch instead, on evidence the earlier
triage did not have: a sibling case fails seam-on in exactly the same parameterisation with exactly
the same assertion shape, in every seam-on run taken here, while the control arm was clean in the same
runs. A coin-flip flake does not land on two sibling tests at the same parameter in consecutive runs.
The flake registry is therefore consulted last among the divergence mechanisms and first on
the control arm - a flake explains a dirty control; letting it explain a divergence is how a real one
disappears.

2. The laws Kafka's own suite cannot state

Kafka's suite is the oracle for behaviour preservation. It cannot state the properties this module
exists for, because stock Kafka Streams has no arm in which two records of one partition run at once.
These do, and each carries its control:

• PcDrivenStreamsProofTest - PC-path output is identical, record for record, to what stock Kafka
  Streams produced. Two controls answering different questions: a same-harness seam-off arm, which
  separates "the patch changed the output" from "concurrency changed the output"; and the stock
  baseline itself, generated outside this module.
• PcDrivenStatefulProofTest - the same for a stateful topology, where Kafka's own store wrappers
  read the per-task record context ambiently. The module's existing envelope test already said this
  proof was the reason non-windowed aggregation is not refused - and the proof was not on this stack,
  so that sentence was pointing at nothing.
• CommitFrontierCrashRestartTest - nothing lost or double-counted across a crash. The committed
  frontier is a point below which every record has been processed, not the offset of the last one
  handed out, and under concurrent dispatch those are different records.
• ShadowedStreamsControlTest - stock, single-threaded Kafka Streams running our generated
  classes. It is a control: a concurrency change that quietly breaks the serial path is not a fix.

The baseline is generated in another module, and that is the whole point. This module compiles
patched Kafka classes into its own build output, which precedes the kafka-streams jar on the
classpath, so every KafkaStreams instance in this JVM runs the patch. A "stock arm" written here
would share every defect the patch introduced. The baselines come from
parallel-consumer-example-streams, which does not depend on this module and asserts its own
classpath is stock before recording a row. Both fixture tests were re-run on this branch and the
tracked fixtures still match what genuinely-stock Kafka Streams produces.

The lane above defers to one of these, and says so. commit-frontier-encoding cannot tell a
deliberate encoding divergence from an offset regression - both render an OffsetAndMetadata and
nothing in the assertion text separates them. Its javadoc names CommitFrontierCrashRestartTest as
what actually defends offset correctness, because that arm asserts on records that arrived rather than
on a base64 metadata string. An acknowledged blind spot with a named owner beats a predicate
pretending to cover it.

3. The realistic-domain benchmark, with a noise floor

A card issuer screens every authorisation against a fraud-scoring service; the screener has been down
and the queue has to clear. The canonical Kafka Streams enrichment shape, keyed the way a real
deployment would have to key it, with a skewed keyspace and a heavy-tailed cost - the two things that
cost this seam most.

Three arms, not two, and the third is what this rung adds. It is a second stock arm on the same
records: whatever it differs from the first by is this machine in this state, and that bounds how far
a ratio can move with nothing changed at all. The headline assertion no longer asks whether the ratio
beat one - a direction check is a coin toss at parity and is satisfied by a run in which the mechanism
did nothing. It asks whether the ratio beat the floor by a margin.

No figure from an earlier run survives in this diff. The forest's numbers were measured on another
machine; the headline multipliers, the wake-on-work ablation percentage and the CPU-bound refutation
are removed or attributed to the branch they were taken on. DEMO.md shows the report's shape with
the numbers elided and says why. The run prints its own, with the floor beside them.

Proven able to fail - every gate here, with the prediction stated first

The lane, three ways.

• An unexplained divergence. Removing the close-time commit-state publication from
  PcTaskDispatcher.close() was predicted to make exactly one case,
  shouldClearCommitStatusesInCloseDirty, fail seam-on while staying green seam-off, with no
  mechanism recognising a bare commitNeeded assertion. Exactly that: one unexplained divergence,
  named, with its recorded failure and stack; every other divergence still explained by the same six
  mechanisms; the script exited 1. Reverted and verified byte-identical by checksum. That run also
  demonstrated the control-arm path unplanned - the invalid-timestamps flake fired seam-off, and the
  lane named it from its ledger note and carried on instead of aborting.

• An expected-class divergence. The clean run classifies every divergence under six named
  mechanisms, with the refused constructs named individually, and exits 0.

• A missing or stale report directory. Running the classification execution alone against deleted
  directories failed with "That is an ERROR and not an empty result"; against directories from an
  earlier run it failed on the freshness check, naming the file, when it was written, and when the
  build started.

• A control arm nobody has diagnosed - and this one arrived on its own. On a later CI run
  StreamThreadTest.shouldChangeStateAtStartClose[1] failed seam-off, in Kafka's own test, on a
  10-second shutdown bound. The lane named the ledgered invalid-timestamps flake beside it, refused to
  produce a verdict on the divergence set while an undiagnosed control-arm failure stood, and said
  so in a verdict that outranked the classification - which was itself clean, no unexplained
  divergences at all. That is the mode this design exists for, and it had only ever been exercised on
  synthetic reports before.

  It is recorded in docs/inflight/test-streamthreadtest-start-close-shutdown-bound.md with the
  argument that carries it: the same case passed in the seam-ON arm of the same run, minutes
  apart on the same runner with the same patched classes, and a defect the patch introduced cannot be
  repaired by turning the seam on. One sighting, and the note says which observation would void it.

SeamOnDivergenceClassifierTest pins the first three at unit level on synthetic reports in milliseconds,
plus what the end-to-end runs cannot cheaply reach: an arm whose pin did not arrive (both arms
recording dispatch=false differences the control against itself and reports a flawless zero), arms
covering different classes, an attribution to an undeclared class, and a triaged attribution beating a
flake marker on the same case.

The benchmark, through a documented flag rather than a code edit. Predicted: with a worker pool of
one, PC dispatch has no concurrency to exploit, so the seam-on arm lands inside the noise floor and
the headline assertion fails while the run stays otherwise healthy. Exactly that - --pool 1 failed
one case, the headline, and its message carried the whole diagnosis including both stock arms and the
PC arm; the steady-state case, which asserts on sample size rather than a ratio, stayed green.

The margin rule itself is pinned by NoiseFloorTest, which runs in the ordinary build because it is a
pure function of two numbers. Its first case is the one that matters, and it is the one --pool 1
cannot reach: a 1.01x observation does not beat even the tightest possible floor. That is the
shape of the sabotaged run on #391 that printed its own headline claim, and a
direction check passes it.

Two defects found in the machinery being ported, both silent

bin/streams-benchmark.sh ran nothing and exited 0. Carried across unchanged it drove failsafe
with -Dit.test and -DskipUTs; these benchmarks live in src/test/java and this module has no
src/test-integration, so that selects nothing, runs nothing, and succeeds. It now drives surefire -
and because failIfNoSpecifiedTests has to be off for the Kafka executions' sake, the script asserts
a surefire report exists for every class it selected and exits 2 when one does not.

--pool N was documented and dead. The harness hardcoded the pool, so a reader could ask for a
configuration, be told in every log line that they had got it, and be measuring something else.

And one defect this PR introduced and caught before merge: naming the classifier in the
default-test execution silently dropped the root pom's two surefire excludes, promoting every
broker-backed arm out of failsafe and into the unit lane, where they ran, needed Docker, and went
green. Caught by reading the run rather than the tick. Both directions are now verified.

The one thing red here that is not expected, and it is NOT being greened

PcDrivenStatefulProofTest.pcDrivenAggregationMatchesTheStockBaseline timed out on repetition 2 of 3
in the Integration Tests lane - the run that first put that class on CI. Repetitions 1 and 3 passed
in the same JVM.

The obvious reading is wrong, and the run says so itself. Its StreamThread logged
polled 1207 times against Processed 14 total records in the two minutes it was stuck. A thread
short of CPU polls less; this one was going round its loop briskly and finishing almost nothing,
which is the shape of work dispatched and not completed rather than of a busy runner. The ambient
probe was clean - no rebalance dwell, no lag stagnation, no frozen partitions - so the group was
progressing at the broker while the task was not progressing at the processor.

A control arm was run rather than a verdict guessed. The whole streams integration suite,
locally, at the lane's own forkCount=4 -DreuseForks=true alongside core's integration suite: green,
including this class. Uncontended at forkCount=1: green in three separate runs. The instrumentation
is confirmed rather than assumed - failsafe pins no <forkCount> of its own, so the property does
arrive, unlike the surefire trap the root pom documents.

So contention is not established, and it is not being claimed. The one term the local arm cannot
vary is core count: four JVMs and four brokers on a developer machine is not four JVMs and four
brokers on two cores. docs/inflight/test-streams-stateful-proof-stalled-on-ci-while-still-polling.md
records the sighting, both arms, the two unattributed exception lines from the interleaved four-fork
log, and the experiment that would settle it - the same runner at forkCount=1, which holds the
machine fixed and varies only the load.

Nothing was loosened, shortened or serialised to make this pass. The lane re-runs on every push, so
the rate is being collected meanwhile.

The duplication reports, triaged

dups: clones was right once and the clone is gone. Both engines agreed on consumeByKey plus
flatten being copied between the seam-on dispatch arm and the stock control arm, byte-identical
apart from the deadline. That is worth fixing here for a reason specific to this module - those two
are a matched experiment, and a copy of the reading logic in each is a second varying term waiting to
appear the first time somebody tunes one. It now lives on BrokerStreamsIntegrationTest, which both
extend and which already holds the same broker, the same serdes and the same starting offset; the
deadline stays a parameter at each call site. Whole streams integration suite re-run green afterwards.
PMD CPD now passes both its rules.

dups: similarity and jscpd's threshold stay red, and the reason is what they measure. Every
remaining hit is an import block or a javadoc header between sibling classes - the offsets give it
away, they are lines 1 to 22 of the files. jscpd is lexical and counts comments; PMD CPD is
token-based and reports none of them. A rung that adds this much test code with similar imports and
long javadoc moves a lexical percentage, and +0.11% against a +0.1% limit is that, not new logic.

One real clone is deliberate and stays: the fixture format, written by
StockBaselineFixtureSupport and read by BaselineFixture. Those two live in modules that must not
share code - if the example module depended on the streams module, the baseline it generates would
run the patched classes and stop being a baseline. Extracting it would need a third module whose only
job is to reconnect the two things this design keeps apart.

Where this came from, and your siblings will move these results

Copied out of #271, the Kafka Streams feasibility study, which remains
the source god PR and keeps the semantic work, the measurements and the open review threads. The
seam-on run machinery and the triage method come from feats/ks-streams-seam-on-upstream-gate; the
benchmark suite and DEMO.md come from test/ks-streams-realistic-domain-benchmark. PC-side classes
are renamed io.confluent to bz.stub.

Two sibling rungs are in flight on this same base - stream time and punctuation, and error
surfacing and backpressure - and both change dispatch semantics. Their results will move this
lane's, and the lane absorbs that by design: it classifies by the failure's own evidence rather than
by test name wherever it can, and where it cannot the attribution is a ledger entry those rungs edit
in the PR that closes it. Two of the four attributed classes are theirs by name -
stream-time-never-advances and exception-type-lost-in-the-worker - and the lane reports an entry
that has stopped matching, so a rung that fixes one gets told rather than leaving a stale expectation.

Not here, named so a reader does not expect them: HeadOfLineBlockingBenchmarkTest, deliberately
left on the forest because it isolates head-of-line blocking on a fixture whose own construction bounds
its multiplier and the settled decision is to lead with backlog catch-up; and the example module,
which is #391's.

The dependency gate will be red until #394 merges. That is expected.

Checklist

• Docs updated - the module README (the seam-on lane and what its failures mean, the table of laws
  and their controls, and the reinstatement rule now naming the command that answers it), DEMO.md
  rewritten with its figures elided and the negative control documented, two docs/inflight/
  notes (the divergence triage, and the flake note gaining a machine-readable marker plus what the
  lane now does with it), and two method write-ups carried with the benchmark whose citations
  pointed at them
• User-facing feature documentation data added under docs/features/ - N/A - the module is still unpublished, so there is no artifact to depend on and nothing for the ladder to point a user at. The roadmap stage is unchanged, for the same reason the four rungs below gave
• Tests added/updated - the whole PR is tests. SeamOnDivergenceClassifierTest and
  NoiseFloorTest at unit level; SeamOnDivergenceLaneTest as the lane's gate; four broker-backed
  law arms with their controls; and the benchmark suite with its noise-floor arm
• Title & body reflect the final content of this PR
• Ran ce-simplify and ce-code-review locally - N/A - asked for review on the PR instead. Most of the diff is a copy from branches already reviewed on astubbs/parallel-consumer#271; what is new here - the classifier and its ledger-driven mechanisms, the control-arm integrity check, the noise floor and the margin rule, and the two silent defects found in the ported machinery - is what a reviewer should spend attention on

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 4 package(s) with unknown licenses.

See the Details below.

License Issues

.github/workflows/streams-seam-on-evidence.yml

Package	Version	License	Issue Type
actions/cache/restore	4.*.*	Null	Unknown License
actions/checkout	6.*.*	Null	Unknown License
actions/setup-java	5.*.*	Null	Unknown License
actions/upload-artifact	7.*.*	Null	Unknown License

Excluded from license check:

pkg:githubactions/actions/github-script

OpenSSF Scorecard

Package	Version	Score	Details
actions/actions/cache/restore	4.*.*	🟢 6.4	Details Check Score Reason Maintained 🟢 10 13 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10 Code-Review 🟢 10 all changesets reviewed Binary-Artifacts 🟢 10 no binaries found in the repo Packaging ⚠️ -1 packaging workflow not detected Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Pinned-Dependencies 🟢 3 dependency not pinned by hash detected -- score normalized to 3 Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Signed-Releases ⚠️ -1 no releases found Security-Policy 🟢 9 security policy file detected Branch-Protection ⚠️ 1 branch protection is not maximal on development and all release branches SAST 🟢 10 SAST tool is run on all commits
actions/actions/checkout	6.*.*	🟢 7	Details Check Score Reason Code-Review 🟢 10 all changesets reviewed Maintained 🟢 10 24 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10 Binary-Artifacts 🟢 10 no binaries found in the repo Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Packaging ⚠️ -1 packaging workflow not detected Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Signed-Releases ⚠️ -1 no releases found Pinned-Dependencies 🟢 3 dependency not pinned by hash detected -- score normalized to 3 Security-Policy 🟢 9 security policy file detected SAST 🟢 10 SAST tool is run on all commits Branch-Protection 🟢 6 branch protection is not maximal on development and all release branches
actions/actions/setup-java	5.*.*	🟢 5.4	Details Check Score Reason Maintained 🟢 10 30 commit(s) and 2 issue activity found in the last 90 days -- score normalized to 10 Code-Review 🟢 3 Found 9/26 approved changesets -- score normalized to 3 Binary-Artifacts 🟢 10 no binaries found in the repo Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Packaging ⚠️ -1 packaging workflow not detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions License 🟢 10 license file detected Pinned-Dependencies ⚠️ 0 dependency not pinned by hash detected -- score normalized to 0 Signed-Releases ⚠️ -1 no releases found Fuzzing ⚠️ 0 project is not fuzzed Security-Policy 🟢 9 security policy file detected Branch-Protection ⚠️ 0 branch protection not enabled on development/release branches SAST 🟢 10 SAST tool is run on all commits
actions/actions/upload-artifact	7.*.*	🟢 4.5	Details Check Score Reason Code-Review 🟢 10 all changesets reviewed Pinned-Dependencies ⚠️ -1 no dependencies found Maintained ⚠️ 0 0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0 Binary-Artifacts 🟢 10 no binaries found in the repo Token-Permissions ⚠️ -1 No tokens found Dangerous-Workflow ⚠️ -1 no workflows found Packaging ⚠️ -1 packaging workflow not detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Signed-Releases ⚠️ -1 no releases found Security-Policy ⚠️ 0 security policy file not detected SAST 🟢 10 SAST tool is run on all commits Branch-Protection ⚠️ 0 branch protection not enabled on development/release branches

Scanned Files

• .github/workflows/streams-seam-on-evidence.yml

[github-actions]

❌ Duplicate Code Report

Two engines run in parallel for cross-validation. Each has its own thresholds tuned to its baseline - the real safety net is the per-engine "max increase vs base" check.

✅ PMD CPD

	PR	Base	Change
Clones	31	30	🫤 +1
Duplicated lines	1015	963	:face_with_raised_eyebrow: +52
Duplication	0.13%	0.12%	🫤 +0.01%

Rule	Limit	Status
Max duplication	0.5%	✅ Pass (0.13%)
Max increase vs base	+0.1%	✅ Pass (+0.01%)

⚠️ 1 new clones introduced

• 26 lines (109 tokens): parallel-consumer-examples/parallel-consumer-example-streams/src/test/java/bz/stub/parallelconsumer/examples/streams/integrationTests/StockBaselineFixtureSupport.java:335 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/BaselineFixture.java:141

❌ jscpd (language-agnostic)

	PR	Base	Change
Clones	103	91	:face_with_monocle: +12
Duplicated lines	1538	1294	:face_with_raised_eyebrow: +244
Duplication	1.10%	0.99%	:face_with_monocle: +0.11%

Rule	Limit	Status
Max duplication	2%	✅ Pass (1.10%)
Max increase vs base	+0.1%	❌ FAIL (+0.11%)

⚠️ 12 new clones introduced

• 16 lines: parallel-consumer-examples/parallel-consumer-example-streams/src/test/java/bz/stub/parallelconsumer/examples/streams/integrationTests/StockBaselineFixtureTest.java:69 <-> parallel-consumer-examples/parallel-consumer-example-streams/src/test/java/bz/stub/parallelconsumer/examples/streams/integrationTests/StockStatefulBaselineFixtureTest.java:95
• 10 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/RebalanceUnderPcDispatchTest.java:14 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/StreamsBenchmarkHarness.java:17
• 11 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenStreamsDispatchTest.java:7 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/ShadowedStreamsControlTest.java:6
• 14 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenStreamsDispatchTest.java:17 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/ShadowedStreamsControlTest.java:15
• 9 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenStatefulProofTest.java:10 <-> parallel-consumer-examples/parallel-consumer-example-streams/src/test/java/bz/stub/parallelconsumer/examples/streams/integrationTests/StockStatefulBaselineFixtureTest.java:11
• 11 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenStatefulProofTest.java:22 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenStreamsProofTest.java:13
• 8 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PcDrivenProofSupport.java:9 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/ShadowedStreamsControlTest.java:7
• 70 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PaymentAuthorisationBenchmarkTest.java:10 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/WorkloadMatrixBenchmarkTest.java:9
• 56 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PartitionScalingBenchmarkTest.java:1 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/WorkloadMatrixBenchmarkTest.java:1
• 14 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/CommitFrontierCrashRestartTest.java:15 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/StreamsBenchmarkHarness.java:17
• 26 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/BaselineFixture.java:141 <-> parallel-consumer-examples/parallel-consumer-example-streams/src/test/java/bz/stub/parallelconsumer/examples/streams/integrationTests/StockBaselineFixtureSupport.java:335
• 11 lines: parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/BacklogCatchUpBenchmarkTest.java:7 <-> parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/PaymentAuthorisationBenchmarkTest.java:6

_{Powered by astubbs/duplicate-code-cross-check}

[github-actions]

⚠️ Duplicate code detected - 26 lines duplicated with parallel-consumer-streams/src/test/java/bz/stub/parallelconsumer/streams/integrationTests/BaselineFixture.java:141

[github-actions]

🧪🔒 Quarantine Lane Report

Quarantined test	Outcome	Owner	Meaning
ProducerManagerTest.producedRecordsCantBeInTransactionWithoutItsOffsetDirect	🔴 failing (expected)	#262	quarantine holding

_{🔴 expected while the owner PR is open · 🟡🎲 flapper, pass proves nothing · 🚨 a deterministic quarantined test passing means its fix landed: delete its @Quarantined annotation + docs/quarantined-tests.md entry (a merge-blocking review thread has been opened). Lane: non-gating; rules: see the Quarantine Audit check.}

[github-actions]

⚠️ SpotBugs Report

445 bug(s) found (rule-level exclusions only - see docs/inflight/static-spotbugs-rule-registry.md). See the annotations on the Files Changed tab for details.