Plesty Documentation

Quality Gates

Overview of the plesty check gate system — 14 core gates plus the module-type gates d1 (device) and e1 (experiment).

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

1
Gate runs → PASS → next gate
2
Gate runs → FAIL → print error, stop

Pre-push hook

plesty init installs a pre-push hook that runs plesty check automatically before every git push. The standard is read from [tool.plesty] standard in pyproject.toml:

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).

Gate summary

# Gate Tier Standard
1 Metadata & Namespace [SDK] pixel
2 Code Hygiene [SDK] pixel
3 API Interface Matching [SDK] nebula
4 Data Layer Compliance [SDK] nebula
5 Documentation Completeness [SDK] nebula
6 Dependency Coexistence [SDK] nebula
7 Automated Test Coverage [SDK+CI] quantum
8 Semantic Versioning [SDK+CI] quantum
9 Licensing Compliance [SDK+CI] quantum
10 Vulnerability Audit [SDK+CI] quantum
11 Docs Build [SDK] quantum
d1 Device API Pipeline [Device] quantum
e1 Experiment Contract [Experiment] quantum
12 Docs Deploy [CI] quantum
13 Secret Detection [CI] quantum
14 Build & Release [CI] quantum

The two module-type gates are activated by module_type in [tool.plesty] and silently skipped otherwise:

  • d1 — Device API Pipeline (module_type = "device"): all eight DevicePipeline mock-gate test functions present and passing. See Testing devices.
  • e1 — Experiment Contract (module_type = "experiment"): all five ExperimentPipeline contract test functions present and passing — single public Experiment subclass, deterministic build_plan(), resolvable step operations, JSON-serializable plans, async lifecycle hooks. See Testing experiments.

Sections