Arid 2.2.0-beta.1 — High-Signal Duplicate Intelligence Beta

Arid 2.2.0-beta.1 marks the feature-freeze point for the Arid 2.2 release line.

The detector remains intentionally unchanged from 2.1: Arid still finds exact normalized Python duplicate code and reports DUP001. V2.2 adds richer human summaries, objective duplicate hotspots, concise summary-only scans, the deterministic summary-v1 machine contract, expanded GitHub Action outputs, and bounded adaptive parallelism by default around that same focused detector.

This beta is for broader real-world and integration validation before stable-readiness qualification. New product features are not planned after this point. Fixes are limited to correctness defects, compatibility regressions, deterministic-output defects, platform inconsistencies, documentation defects, or release-process defects inside the approved v2.2 contract.

What is frozen

The beta carries forward the complete v2.2 surface introduced in alpha.1.

Rich human summary

Normal text scans end with a compact Summary containing:

• files analyzed
• files with duplicates
• source lines
• analyzed lines
• duplicate groups
• total occurrences
• duplicate lines
• duplication percentage

Detailed and summary-only human output can also include:

• Context breakdown
• Scope breakdown
• Distribution breakdown
• deterministic top-five Hotspots

These metrics are descriptive. Arid does not assign severity, health scores, quality grades, or percentage-based quality thresholds.

Objective Hotspots

Hotspots rank files by:

1. duplicate groups descending
2. occurrences descending
3. path ascending

A finding contributes at most one hotspot group count per path. Every reported location still contributes to hotspot occurrences.

The public list remains limited to five files.

--summary-only

--summary-only is frozen as a presentation modifier over the normal scan pipeline.

For text:

arid . --summary-only

suppresses individual DUP001 finding blocks while preserving the same logical Summary, Breakdown, Hotspots, filtering, worker behavior, and exit policy.

For JSON:

arid . --summary-only --json

or:

arid . --summary-only --format json

emits summary-v1.

Markdown and SARIF remain unsupported as primary summary-only formats.

Supplemental reports remain full existing formats. For example:

arid . \
  --summary-only \
  --report json=artifacts/full-report.json

writes full report-v4 while keeping primary text concise.

summary-v1

The compact deterministic machine contract remains:

• schemas/summary-v1.schema.json

It includes:

• completeness and structured errors
• effective analysis metadata
• files analyzed
• files with duplicates
• source and analyzed lines
• duplicate groups
• occurrences
• duplicate lines
• duplication percentage
• fixed Context counts
• fixed Scope counts
• fixed Distribution counts
• deterministic top-five hotspots

It intentionally excludes:

• elapsed timing
• worker count
• color state
• terminal layout
• human number formatting

summary-v1 is derived from the final typed report after baseline and focus filtering. It does not create another detector pass or another definition of duplication.

GitHub Action outputs

The official Action includes:

• occurrences
• files-with-duplicates
• summary-json

alongside the existing outputs.

summary-json follows the same logical summary-v1 contract as the CLI.

The Action continues to perform one Arid scan.

Adaptive parallelism by default

Implicit worker selection remains equivalent to:

--workers auto

Automatic selection uses available parallelism clamped to 1..=4, falling back to 1 when available parallelism cannot be determined.

Explicit values remain exact:

--workers 1
--workers 2
--workers 4
--workers 8

Explicit numeric values are not capped by the automatic-worker limit.

Parallelism remains confined to file preparation. Detection semantics and deterministic machine output are unchanged.

Compatibility

The following remain unchanged from Arid 2.1:

• exact duplicate semantics
• DUP001
• finding fingerprints
• report-v4 schema and meaning
• baseline-v1 schema and meaning
• error-v1
• suppression-status-v1
• path-explanation-v1
• suppression semantics
• discovery semantics
• focus semantics
• baseline filtering semantics
• normalization semantics
• [tool.arid] behavior
• explicit --workers 1
• explicit numeric worker behavior
• --workers auto semantics
• ordinary scan exit meanings 0 / 1 / 2
• --no-fail-on-findings
• Markdown report semantics
• SARIF semantics
• supplemental --report semantics
• supported platform set

The intentional v2.2 changes remain:

• normal text uses the rich Summary + Breakdown + Hotspots presentation;
• implicit worker selection uses bounded automatic parallelism rather than serial execution.

Alpha qualification results

Published 2.2.0-alpha.1 passed the complete pre-publication and published-artifact qualification path.

Before alpha publication, the v2.2 branch passed:

• the complete locked Rust test suite
• Clippy across all targets and features with warnings denied
• pinned Rust/rustfmt reproducibility checks
• Action and release Python unit tests
• locked release build qualification
• the inherited v2 and v2.1 validation suites
• the dedicated v2.2 contract suite
• real-world validation against Black, Django, mypy, and Rich
• Django determinism at workers 1, 2, 4, and 8
• Unicode, space-path, non-ASCII filename, relative-path, and source-location validation
• the full non-publishing supported-platform Release workflow
• stable 2.1.0 → v2.2 performance qualification

The pre-publication performance campaign measured the implicit v2.2 default versus stable 2.1:

Explicit --workers 1 remained effectively at stable 2.1 performance.

After alpha publication:

• the tag-triggered production Release workflow passed;
• all five supported standalone assets were published;
• exact PyPI arid==2.2.0a1 installed successfully;
• the published Linux x86-64 standalone archive passed its published SHA-256 check;
• the published standalone binary passed the complete validation/v2.2.sh suite;
• the exact PyPI-installed binary passed the complete validation/v2.2.sh suite;
• standalone and PyPI summary-v1 output was byte-identical;
• standalone and PyPI report-v4 output was byte-identical;
• the published GitHub Action verification job passed;
• the tagged Action pinned exact PyPI version 2.2.0a1.

No alpha qualification defect required a product or packaging correction before beta.

Install the beta

With uv:

uv tool install --prerelease allow "arid==2.2.0b1"
arid --version

Or with pip:

python -m pip install --pre "arid==2.2.0b1"
arid --version

Expected version output:

arid 2.2.0-beta.1

Official GitHub Action

For this beta:

- uses: sponge-b0b/arid@v2.2.0-beta.1
  with:
    paths: .

The release workflow verifies the published Action against the exact PyPI package version encoded in the tagged Action metadata.

What to test

Beta validation should focus on defects and integration friction in the frozen v2.2 surface, especially:

• rich summary usefulness on small, medium, and large repositories
• Context, Scope, and Distribution breakdown accuracy and legibility
• hotspot usefulness on real repositories
• --summary-only in local development and CI
• summary-v1 consumption by scripts, tools, and agents
• summary determinism across worker modes
• baseline and focus interactions
• outside-focus retained occurrence context
• incomplete keep-going summaries
• GitHub Action occurrences, files-with-duplicates, and summary-json
• implicit adaptive worker behavior on different machines
• explicit --workers 1 as the serial control path
• compatibility with report-v4 consumers
• Unicode and terminal presentation behavior
• platform-specific installation, packaging, and Action behavior

Any incompatible change to summary-v1, hotspot ranking, top-five behavior, or summary-only JSON semantics after this point requires an explicit versioned contract decision rather than silent mutation.

Next steps

After beta publication, Arid 2.2 enters full real-world beta stabilization.

The beta artifact will be qualified through:

• the established real-world detector campaign
• real rich-summary and hotspot inspection
• summary-only developer and CI use
• machine-contract consumption
• published Action verification
• worker determinism
• Unicode and supported-platform checks
• published-to-published performance comparison against stable 2.1
• documentation reconciliation

A release candidate is created only if beta qualification identifies a correction that requires another frozen published build. Otherwise the qualified beta may proceed directly to stable-readiness qualification under the v2.2 roadmap.