#Check system

rlsbl includes 56 checks across 9 tags.

Run checks via the rlsbl check command. Checks are organized across 6 tags (project, release, changelog, workspace, quality, prepush) and validate project metadata, release state, changelog structure, workspace integrity, code quality, and pre-push enforcement. Four additional untagged checks run only with --all or --name.

#Running checks

# Run all checks
rlsbl check --all

# Run all checks in a tag
rlsbl check --tag changelog

# Run a single check by name
rlsbl check --name version-consistency

#Check results

Each check returns one of four statuses that determine how the result is displayed and whether it blocks the release pipeline. The severity level (error or warn) is declared per-check in the check metadata stored in checks.toml and controls which status is reported on failure versus advisory findings:

Severity is declared per-check in metadata. A check with severity = "error" reports fail on failure; one with severity = "warn" reports warn.

#Tags

Note: test-suite is tagged both prepush and quality, and scaffold-conflicts is tagged project, prepush, and release, so they appear in multiple tag counts. Four checks (layers-violations, deps-unused, deps-undeclared, deps-stale) have no tag and only run with --all or --name.

#Project checks

#Release checks

Release checks form a dependency chain: version-consistency -> local-tag -> remote-tag -> github-release. If an upstream check fails, downstream checks are skipped.

#Changelog checks

Dependencies: changelog-range and changelog-coverage depend on changelog-hashes (hash resolution must succeed first).

#Workspace checks

#Quality checks

#Prepush checks

Dependencies: test-suite and test-suite-workspace both depend on prepush-changelog-coverage -- fast checks fail first, so the test suite is skipped if changelog coverage fails. test-suite is also tagged quality, so it runs under both rlsbl check --tag prepush and rlsbl check --tag quality.

#Untagged checks

These 4 checks have no tag assignment and run only when explicitly requested via --all or --name. They are excluded from tag-based runs because they require specific project configurations (layer rules, workspace manifests) or have longer execution times:

#Target applicability

Not all checks apply to all 18 targets. Each check declares its applicability as one of three categories, which determines whether it runs for a given project based on the project's detected targets:

• Universal (None): runs for any target -- most project, release, and changelog checks
• Workspace-only ("workspace"): runs only in monorepo workspaces, target-agnostic
• Target-specific (frozenset): requires specific language targets with import scanners or AST analysis

[selfdoc: custom directive 'table-feature-matrix' failed: No module named 'rlsbl']

#Excluded targets

Some checks explicitly exclude specific targets where the compiler or language toolchain already enforces the same constraint natively, making rlsbl's check redundant. These exclusions prevent false positives and unnecessary warnings:

#Check metadata

Checks are declared in rlsbl/data/checks.toml with metadata that controls execution order, dependency resolution, and result severity. Each check entry has the following fields that the check runner uses to determine when and how to execute the check:

Checks are implemented via the @app.check() decorator in the rlsbl/checks/ package (one module per tag, e.g. project.py, release.py, workspace.py), which registers the function with strictcli's check system. The decorator name must match the key in checks.toml.