Skip to main content

checkwash

CI PyPI License

Check whether a code change weakens your tests.

A test can pass after it stops checking something useful. checkwash reads your Git diff and flags known patterns such as deleted assertions, skipped tests, relaxed expectations, and CI checks that stop failing.

- assert total == 105.3
+ assert total > 0

The new assertion accepts many incorrect totals. checkwash can flag changes like this for review, including changes written by coding agents.

Runs locally. No LLM. No network during analysis. Never executes your code.

v0.3.0 replaces five file-wide exemption rules with content-bound ones. In v0.2.13 those rules could reuse a recorded approval for a later change to the same path; v0.3.0 retires their path-only keys. The upgrade notes describe the content-bound replacement, retired keys, and installation fixes.

Try it

You need Python 3.11+ and Git. Download and try the offline examples first.

Windows PowerShell (including 5.1):

curl.exe -LO https://github.com/taipei49314/checkwash/releases/download/v0.3.0/checkwash.pyz
python checkwash.pyz --version
python checkwash.pyz demo

PowerShell 5.1 aliases curl to Invoke-WebRequest; use curl.exe as written. macOS/Linux or Git Bash:

curl -LO https://github.com/taipei49314/checkwash/releases/download/v0.3.0/checkwash.pyz
python checkwash.pyz --version
python checkwash.pyz demo

Then, from a repository with at least two commits:

python checkwash.pyz check HEAD~1..HEAD

This checks your last commit. Start with a change you already understand. You can also download the file in your browser. For uncommitted changes use python checkwash.pyz check. For a branch review, use python checkwash.pyz check BASE...HEAD to compare from the merge base; BASE..HEAD compares the two named snapshots directly.

Result What to do
Pass · exit 0 No finding requires blocking under your configuration. Keep running your normal tests and review.
Block · exit 1 Read the finding and the diff. It may be weakened verification or a false positive.
Error · exit 2 Resolve the input or analysis error before relying on the result.

The default threshold is high: a visible warn can still pass. REPAIR_EVIDENCE describes related changes in the same diff; it does not prove a repair is correct.

For JSON/SARIF output and more examples, see the usage guide.

Know the limits

v0.3.0 is alpha. A pass does not prove that a change is correct or honest. Python is the main language supported; JS/TS support covers a limited set of test patterns. Known gaps remain.

Legitimate refactors can be flagged: the dedicated honest-refactor corpus records 24 blocks out of 60 (40%). Try it on your own changes before making it required. Coverage and limitations · Known gaps

Use it in CI

To stop a merge, make the checkwash status check required in your repository's branch rules. Installing the tool or adding a workflow alone does not enforce its verdict.

The recommended Action is pinned to v0.2.13; the CLI above is v0.3.0. Record which version you use. Full setup and exemptions

Copy the GitHub Actions workflow and require the check

Save this as .github/workflows/checkwash.yml:

# .github/workflows/checkwash.yml
on: [pull_request]

permissions:
  contents: read

jobs:
  checkwash:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
        with:
          python-version: "3.12"
      - uses: taipei49314/checkwash/action@042f69da93f6bc3663b2ee707b9f6a619a90bc41 # v0.2.13

After the workflow runs, open Settings → Rules → Rulesets and require the checkwash status context. Keep the job unconditional.

If you administer the repository and have this project's ruleset file, you can instead create the rule with:

gh api repos/OWNER/REPO/rulesets --method POST --input action/required-ruleset.json

This adds a ruleset; it does not replace existing ones. checkwash doctor can inspect the local workflow, but cannot verify live branch protection.

Why the older Action pin? A release cannot embed its own commit SHA, so the documented Action adopts a verified pin from the prior release. v0.3.0 changes detector logic (content-bound exemptions, parametrize row identity, table-oracle delegation, schema 2); the recommended Action advances only to v0.2.13, the prior release, whose detector logic is unchanged from v0.2.12. To verify another trusted release, use git rev-parse 'vX.Y.Z^{commit}'. Action reference

More options and evidence

Install as a CLI or try the included examples

If you already use pipx, install the fixed version:

pipx install checkwash==0.3.0
# or from the release tag:
pipx install git+https://github.com/taipei49314/checkwash@v0.3.0

checkwash check HEAD~1..HEAD
checkwash demo                  # 8 real tampering cases, blocked, offline

checkwash demo replays eight real tampering cases and one honest fix. It illustrates known patterns; it is not a coverage guarantee. You can run the same examples with python checkwash.pyz demo.

Read the measurements and their limits

The historical six-repo sweep recorded 42 / 1800 = 2.33% blocks: 27 false positives (1.50%), 15 legitimate policy blocks (0.83%). The tracked artifacts record engine v0.1.46 on a corpus used to tune the detectors, not a fresh v0.3.0 or held-out result.

1.33% of the corpus (24/1800) records opaque production changes. That flag does not establish that each verdict changed or each diff was unanalyzed.

Review methods vary: the three-rater agreement study covers an older 35-diff cohort, not all 42 blocks. The dedicated 24/60 refactor result above is a separate population; the general-commit rate does not predict it.

Measurements and source data · Generated results · Failure ledger

Looking for… Start here
Installation checks, versions and first use v0.2.13 guide
JSON/SARIF contracts and upgrades Stability
Required checks and reviewed exemptions Enterprise setup
Contributing or reporting a problem Contributing · Issues · Security reports
Readiness for 1.0 Criteria — not met

Related projects: checkwash-corpus and smallestlie hold evaluation work.

Alpha pre-release. 21 detectors, 1463 tests in the current source tree. Zero runtime dependencies. Apache-2.0.

Metadata

Release files for checkwash 0.3.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for checkwash 0.3.0
File Size Uploaded
checkwash-0.3.0.tar.gz 919.2 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for checkwash 0.3.0
File Interpreter ABI Platform
checkwash-0.3.0-py3-none-any.whl Python 3 none any Details

Total release size: 1.2 MB

Release files / checkwash-0.3.0.tar.gz

Download URL checkwash-0.3.0.tar.gz
Size 919.2 kB
Tags Source
SHA-256 checksum
How to use checksums
af2eda282f9291f28dc1346eb5c7ff5c52c2e93a47496330017ece2736ae6da8
BLAKE2b-256 checksum
How to use checksums
7a8f03ccf0e6623ee7a9c911a7b035bd53c660e7808dcb5eb2faf5c2704642a6
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 7, 2026.

Transparency log

Release files / checkwash-0.3.0-py3-none-any.whl

Download URL checkwash-0.3.0-py3-none-any.whl
Size 243.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
a23b2580ba10980b69a3c3eef07ae5db1597bed319a45914685306551db20382
BLAKE2b-256 checksum
How to use checksums
d5f4cdca044a4e9d6bdf71a44f3312a64aa4712633207e0edaf2e6a17c5c56d3
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 7, 2026.

Transparency log

Release history Release notifications | RSS feed

0.8.0

2 release files

0.7.0

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.2

2 release files

0.4.1

2 release files

0.4.0

2 release files

0.3.4

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

This release

0.3.0 This release

2 release files

0.2.9

2 release files

0.2.8

2 release files

0.2.7

2 release files

0.2.6

2 release files

0.2.5

2 release files

0.2.4

2 release files

0.2.3

2 release files

0.2.2

2 release files

0.2.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page