COLEMAN 4.5 — Keep the evidence behind your CI decisions¶
Adaptive test prioritization starts with knowing what the data actually records. COLEMAN 4.5 adds offline readers for RTPTorrent class executions and LRTS Jenkins reports, preserving the source identities, units and missing observations that can disappear in a convenient flat table.
You can inspect and reproduce a source conversion, publish its immutable provenance artifact and exercise the native TCPCI runner through checkpoint continuation. Source integrity and scientific admission stay separate.
Preserve executions before learning from them¶
The RTPTorrent reader retains project/job/class/position identity, including repeated class executions. Reported seconds, assertion failures, errors and skips keep distinct meanings. Filtered published baseline tables cannot silently replace the full raw layout or remove successful jobs from the evidence.
The LRTS reader pairs pinned processed metadata with a separately pinned raw Jenkins report. Project, PR, build, stage, suite, node and method observations remain explicit. Repeated methods stay separate; unknown outcomes and unavailable durations remain visible. Scheduled timestamps, execution duration and processed duration sums never become invented completion clocks or parallel savings.
Both readers use existing source caches and deterministic artifacts. Actual parsed bytes are checked against their frozen digests. Identical concurrent publication converges; conflicting or interrupted writes cannot publish a falsely completed source artifact. No third-party dataset rows are bundled.
Reproduce a complete native CI slice¶
Install the verified Python 3.14+ wheel attached to this release. Copy either
complete owned example to ci.py in a separate workspace:
Choose a cache outside Git and separate from the output tree, then run twice:
python ci.py owned-ci /absolute/path/to/external-source-cache
python ci.py owned-ci /absolute/path/to/external-source-cache
Each example authors a small fixture, uses the actual materializer and source reader, runs Random/RNFail and checks persisted metrics against an independent exact reference. Reopening the existing learning checkpoint preserves one native result row and the same converted source artifact. These are constructed serial checks, with no claim of observed CI history or independent project evidence.
The RTPTorrent guide and LRTS guide include complete SDK workflows, source versions/digests, field meanings, architecture diagrams, resource limits and explicit compatibility decisions.
What the source assessment established¶
One pinned RTPTorrent HikariCP member converts to 46,995 class executions across 1,662 jobs, retaining 23,302 repeated-class executions. Its published baseline slice has different coverage. The entire multi-gigabyte archive remains unverified; member checks do not prove container integrity.
The complete original LRTS artifact and Karaf v3 archive passed size and provider checksum verification, with computed SHA-256. Original artifact metadata matches the pinned Git CSV byte for byte. One checked metadata/report pair preserves 228 suites and 931 methods, including four repeated labels. Specific data terms were reviewed separately from the repository's code license.
These are bounded descriptive checks, not cross-corpus policy comparisons or large-suite performance claims. Neither source is admitted to protected temporal evaluation: outcome-availability clocks, logical mappings and complete expected suite evidence remain unresolved. The registry's seven required diversity gaps stay visible. A reader returning records is not evidence of generalization.
Compatibility and limits¶
This additive 4.x release reuses the runner, results, sinks, checkpoints and materialization contracts. Existing native and domain artifacts retain their meaning. New source slices require schema v1; unknown versions and incompatible layouts reject. There is no automatic migration from native results, filtered baseline tables or arbitrary JUnit XML.
RTPTorrent preserves exact declared class seconds. LRTS preserves explicitly declared binary64 source projections and rejects silent rounding, underflow, negative/nonfinite durations and incompatible units. Zero and unavailable remain different; valid negative values in unrelated signed contracts retain support.
Whole-archive fetching is not added. The existing materializer's ZIP64 policy and hard 128-entry ceiling remain in force; real source containers exceed them. Supported conversion starts from separately pinned permitted decoded members. Inputs are bounded per operation, without an OS sandbox or global cache quota. Recipe-only rows must remain local. The base package needs no MCP or transport dependency for these readers.
Validation and next steps¶
The reviewed implementation passed 2,107 tests with 95.40% combined statement/branch coverage, including installed base-wheel workflows outside the checkout. Lint, formatting, both type checkers, Pylint, docstring and structural gates, strict documentation and package builds passed. Local-only OpenCodeReview and manual exclusions covered every changed file. Confirmed review findings were reproduced and fixed with regressions before integration; source/identity/unit, serialization, corruption, interruption, concurrent publication and recovery checks accompany the readers.
The diversified benchmark program in #261 remains open. Controlled real-fault corpora, variant expansion, synthetic stress, comparable baselines/statistics, modern-CI feasibility, frozen confirmation and cross-corpus reports remain sequential work. Negative and inconclusive results remain valid.