Arid 2.0.0-alpha.1 — V2 Integration Alpha

Arid 2.0.0-alpha.1 is the first public build of the v2 contract.

The detector remains intentionally unchanged: Arid still finds exact normalized Python duplicate code and reports DUP001. V2 focuses on making that detector easier and safer to consume from CI systems, coding agents, editor tooling, and other automation.

This is an alpha release. It is intended for integration testing, especially around machine-readable contracts and combinations of the new CLI features. Breaking corrections may still be made before the stable 2.0.0 release.

What is new

Report v4 and stable finding identity

JSON output moves from report schema v3 to v4.

Key changes include:

• version is renamed to schema_version.
• Reports include tool_version, complete, resolved analysis metadata, and structured errors.
• Every finding has a stable path-independent arid-finding-v1 fingerprint.
• Occurrence distribution uses hybrid when a duplicate group contains both same-file repetition and cross-file duplication.
• Structural context and scope continue to use mixed where appropriate.

The new contracts are published in:

• schemas/report-v4.schema.json
• schemas/error-v1.schema.json
• schemas/capabilities-v1.schema.json

The historical report-v3 schema and baseline-v1 schema remain preserved.

Focused reporting without partial-project detection

Repeatable --focus <PATH> narrows which duplicate groups are reported while Arid still performs duplicate detection against the complete project corpus.

That means a changed file can still be compared against unchanged files rather than becoming an isolated mini-scan.

Partial analysis with explicit failure state

--keep-going allows independent file-local read, parse, or normalization failures to be collected while valid files continue through analysis.

Incomplete scans:

• set complete to false
• include deterministic structured errors
• exit with status 2
• cannot be converted into successful scans by --no-fail-on-findings
• do not emit misleading SARIF output

Baseline maintenance

V2 keeps baseline schema v1 and existing baseline files compatible while adding lifecycle operations:

• --baseline-status <PATH>
• --prune-baseline <PATH>

Pruning removes stale accepted debt only; it never silently accepts new duplication.

Explicit project and configuration control

New controls make project context deterministic for monorepos and automation:

• --config <PATH>
• --no-config
• --project-root <PATH>
• --show-config
• --list-files

Legacy nearest-config discovery remains available when no explicit selector is supplied.

Virtual source input

--stdin-path <PATH> lets one Python source file be supplied through stdin without writing it to disk.

The virtual source participates in the same parser, normalizer, corpus, duplicate detection, baseline, focus, and report pipeline as disk-backed files. If its logical path matches an existing disk file, it replaces that file for the scan rather than creating a second copy.

One scan, multiple outputs

Repeatable --report FORMAT=PATH destinations can produce supplemental text, JSON, Markdown, or SARIF output from the same in-memory scan.

This avoids rerunning discovery, parsing, normalization, or duplicate detection merely because different consumers need different formats.

Automation controls and capability discovery

V2 adds:

• --no-fail-on-findings to map findings-only exit status 1 to 0 without masking operational failure status 2
• deterministic --capabilities output for tools that need to discover supported automation features

Narrower supported Rust API

The v2 Rust library surface is intentionally smaller. The supported root-level API is centered on:

• Cli
• RunContext
• ColorEnvironment
• RunResult
• ExitStatus
• run
• run_with_context

Implementation modules that were accidentally public in earlier releases are no longer part of the supported v2 API.

Official GitHub Action

Arid now ships an official composite GitHub Action from the repository root.

For this alpha:

- uses: sponge-b0b/arid@v2.0.0-alpha.1
  with:
    paths: .

The Action installs the exact Arid package version associated with its release metadata, runs one Arid scan, exposes duplicate metrics and scan state as outputs, supports focused reporting, can add a Markdown job summary, and can optionally upload SARIF for complete scans.

Compatibility

Normal CLI users should still recognize Arid v2. The exact duplicate detector, DUP001, existing normalization behavior, baseline schema v1, normal path invocation, worker modes, and default exit-status meanings remain compatible with v1.2.

The intentionally breaking areas are primarily integration contracts:

• report schema v3 → v4
• report version → schema_version
• new required report metadata
• occurrence distribution mixed → hybrid
• new finding fingerprint
• SARIF finding identity
• narrower supported Rust API

If you consume Arid JSON or embed the Rust library, this alpha is specifically intended for testing your migration assumptions.

Install the alpha

With pip:

python -m pip install --pre "arid==2.0.0a1"
arid --version

Expected version output:

arid 2.0.0-alpha.1

What to test

Useful alpha feedback includes:

• report-v4 parsing and schema assumptions
• finding fingerprint stability in external tooling
• focus behavior in real repositories
• keep-going behavior around malformed or unreadable files
• baseline status and pruning workflows
• explicit project/config selection in monorepos
• virtual-source workflows used by coding agents or editor integrations
• multi-output CI pipelines
• GitHub Action installation, outputs, summaries, and SARIF behavior
• migration problems caused by the narrowed Rust API
• platform-specific packaging or installation problems

Detector-semantic regressions are also important: equivalent v1.2 and v2 scans with equivalent settings should still identify the same exact normalized duplicate code.

Known release stage

This alpha establishes the externally installable v2 surface for integration testing. It is not yet the performance-qualified or migration-frozen release.

Real-world repository validation, beta stabilization, current-Pylint performance qualification, migration documentation, and final release qualification occur in later v2 phases before stable publication.