Quality Gates

plesty check runs a sequential gate pipeline. The first failure terminates the check — fix it and re-run. This design makes the output actionable: you always have exactly one thing to fix.

How it works

Pre-push hook

plesty init installs a pre-push hook that runs plesty check automatically before every git push. The standard it enforces comes from [tool.plesty] standard in pyproject.toml when that key is set:

cat .git/hooks/pre-push
# #!/bin/sh
# uv run plesty check

This means you cannot push code that fails the compliance check without explicitly bypassing the hook (which is strongly discouraged).

The standard ramps with your version

Set no [tool.plesty] standard and the standard is derived from the release version you declare, so a prototype is not held to release rules on day one and a released module cannot quietly stay on prototype rules:

A fresh plesty init scaffold therefore starts at pixel, and the tier rises on its own as you release. plesty check prints which rule it applied (derived from version 0.2.1, or from [tool.plesty] standard), so the answer is never a guess.

Two things override the ramp: an explicit [tool.plesty] standard always wins, and a project declaring no version at all falls back to quantum — the conservative default. A dynamic version (versioningit) is read from the latest git tag.

The --standard flag on plesty init sets only the tier written into the generated .gitlab-ci.yml; bump that input alongside your releases.

Gate summary

Six of the lettered gates are activated by module_type in [tool.plesty] and report N/A otherwise — so a module is only ever held to its own type's rules:

module_type = "device"

• d1 — Device API Pipeline: the eight DevicePipeline mock gates present and passing. See Testing devices.
• d2 — Device Status Contract: 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: the package imports, exposes a hardware-free DocDevice/Device factory, and produces a populated doc_model() — so plesty docs can generate the Parameters / Functions / Standard Methods pages with no hand-written content.

module_type = "analyzer"

• a1 — Analyzer Contract: the analyzer implements the interface an experiment drives it through.

module_type = "experiment"

• e1 — Experiment Contract: the five ExperimentPipeline checks — a single public Experiment subclass, deterministic build_plan(), resolvable step operations, JSON-serializable plans, async lifecycle hooks. See Testing experiments.
• e2 — Experiment Persistence: what the run writes can be read back — the plan, journal and records of a completed run round-trip.

Any module type

• f1 — Field Test Findings: a published field-test report must not carry unresolved findings. Modules with no report published skip it. plesty init field-test is what writes the test the report comes from.

Sections

• Pixel & Nebula gates (1–6) — fast local checks
• Quantum gates (7–11 + the lettered gates) — full verification
• CI-only gates (12–14) — run in GitLab CI only