Acceptance checklist

Use this page as the canonical local acceptance checklist for the current repository state. Run the commands in this order. The acceptance gate is local and command-driven. It does not depend on CI, GitHub Actions, or unpublished helper scripts.

Acceptance gate

Run the following commands from the repository root:

python -m compileall src tests
ruff check src tests
ruff format --check src tests
mypy src
python -m pip install -e . --no-deps
meridian-tools --help
pytest tests/ -v

The canonical acceptance-gate result for the last command is:

244 passed, 2 skipped

That result is the pass or fail line for the default local acceptance gate. The recorded warning profile belongs to the release baseline, not to the acceptance-gate definition itself.

What each command proves

python -m compileall src tests proves that the checked-in Python files parse cleanly. If this step fails, you are dealing with a syntax or import-time parse issue and you should stop there.

ruff check src tests proves that the repository still satisfies the pinned lint rules. If this step fails, fix the reported lint violations before moving on.

ruff format --check src tests proves that the checked-in files still match the agreed formatting contract. If this step fails, run the formatter and then rerun the verification sequence.

mypy src proves that the configured static typing baseline still runs cleanly. If this step fails, either fix the reported type issue or update the documented ratchet intentionally.

python -m pip install -e . --no-deps proves that the package still builds and installs in editable mode from the local source tree. If this fails, treat it as a packaging or build-metadata break rather than a test-only problem.

meridian-tools --help proves that the published CLI entrypoint still resolves and that the lightweight command surface still imports cleanly. If this step fails, check the package entrypoint and import boundary before continuing.

pytest tests/ -v proves the behavioural contract of the repository. This is the broadest local validation step. If it fails, use the failing test names to identify which package contract regressed.

How to interpret failure

If the compile step fails, fix syntax or parse problems first. The later steps will not give you useful signal until that is resolved.

If lint, format, or type checks fail, treat that as a source-tree quality issue, not as an optional clean-up item. Bring the tree back to the pinned Ruff and mypy state before trusting the rest of the loop.

If editable install fails, treat the repository as not ready for contributor handoff. The package must install cleanly before the test result matters.

If CLI help fails, assume the published command surface is broken even if the Python modules still import manually.

If pytest tests/ -v fails, the acceptance gate is not met. A partial pass is not enough. Fix the failing behavioural contract and rerun the full command sequence.

Optional extra confidence

The repository also carries one opt-in live Meridian verification command for extra technical confidence:

MERIDIAN_TOOLS_ENABLE_REAL_FIT=1 pytest tests/test_demo_integration.py::test_real_pipeline_refresh_smoke tests/test_log_likelihood.py::test_compute_log_likelihood_dataset_real_posterior_smoke -m real_fit -v

This command is not part of the default blocking acceptance gate. It exists to provide one bounded live Meridian route that proves:

• real pipeline execution over bundled demo data
• manifest-backed stored-run refresh after the original YAML is removed
• the lower-level live log-likelihood reconstruction seam

On the reference development environment, the recorded run finished in 185.42 seconds (0:03:05); keep a budget of roughly six minutes or less for this extra-confidence command.