These gates complete the full local verification. Run them before tagging a release. Network access is required for Gate 10 (CVE database query).
pytest --cov with a minimum coverage threshold of 80%. Measures line coverage across the entire source package. Tests in tests/ are excluded from the coverage measurement. The same threshold is enforced in CI in a clean install environment.
1.0.0, a major bump afterwards — witnessed by a git tag. The gate is advisory locally and authoritative in CI (where CI is set), so a breaking change you have not admitted in the version fails the pipeline rather than the push. When the package is unpublished or PyPI is unreachable, it falls back to reminding you that commits have piled up since the last tag.
LICENSE and COPYING files must be present. The license field must be declared in pyproject.toml. Both are generated by plesty init and set to LGPL-3.0-or-later.
pip-audit for known CVEs in all declared dependencies. A CVE blocks the push. Fix by upgrading the affected package: uv lock --upgrade-package <package> && uv sync.
CI=true is set — in CI, docs are built by the deploy-docs component in gate 12 instead. To test locally: unset CI && uv run plesty check.
DevicePipeline mock gates to be present in the test suite and passing — as eight named tests, or as one test_mock_pipeline calling run_mock_pipeline(). plesty init mock-test generates either. Activated only when module_type = "device" in [tool.plesty]. Runs without hardware — uses a mock solver that generates schema-valid responses. See Testing devices for the complete test file.
ExperimentPipeline contract test functions to be present in the test suite and passing. Activated only when module_type = "experiment" in [tool.plesty]. Runs without hardware — validates the package against the Experiment ABC contract: single public subclass, deterministic build_plan(), resolvable step operations, JSON-serializable plans, and async lifecycle hooks. See Testing experiments for the complete test file.
The rest of the lettered gates
d1 and e1 are the two you write tests for. The others are checks your
module either satisfies by construction or does not, and each reports N/A
unless its module_type matches:
| Gate | Applies to | Requires |
|---|---|---|
d2 — Device Status Contract |
device | The device reports its state the way every consumer expects, so a client can ask what is wrong without knowing the instrument |
d3 — Device Docs |
device | The package imports, exposes a hardware-free DocDevice/Device factory, and returns a populated doc_model() — so plesty docs needs no hand-written content |
a1 — Analyzer Contract |
analyzer | The analyzer implements the interface an experiment drives it through |
e2 — Experiment Persistence |
experiment | The plan, journal and records a completed run writes can be read back |
f1 — Field Test Findings |
any | A published field-test report carries no unresolved findings. No report published, no gate — see plesty init field-test |
d3 is the one that most often surprises a device author: it fails when the
module cannot be constructed without hardware, because then no documentation
can be generated from it either.
Coverage below 80%
The most common quantum failure on first attempt. Check the coverage report:
uv run pytest --cov=plesty/power_meter --cov-report=term-missing
The MISS column shows uncovered lines. Focus on branches in _write_, _query_, and check_errors — these are often missing from the scaffolded smoke tests.
CI=true and Gate 11
If you run plesty check in a CI environment (where CI=true is set by GitLab automatically), Gate 11 is skipped. This is intentional — the Sphinx build is done by the dedicated deploy-docs job in Gate 12 instead, which has access to the full CI environment and docs deployment credentials.