Validate your project

View as Markdown

Run these checks after you change a project file, environment, workbook, or fixture. They find configuration and source problems before Registry Stack starts.

Run the commands from your project directory.

Run the project checks

registryctl test --project-dir .
registryctl check --project-dir . --environment local --explain
registryctl build --project-dir . --environment local

Command	What it tells you
`test`	The maintained offline fixtures produce their expected results. A project with no fixtures reports `0/0 passed`; that is not a source-data test.
`check --explain`	The authored files agree with one another, and the effective plan matches what you intended. The explanation omits secret values and source records.
`build`	Registryctl can produce the product configuration and artifact inventory under `.registry-stack/build/local/`.

Stop at the first failure. Correct an authored project file or the reviewed source, then rerun the checks. Do not correct a failure by editing anything under .registry-stack/.

Check runtime prerequisites

If this environment is intended to run locally, check its files, secret references, and source prerequisites:

registryctl preflight --project-dir . --environment local

preflight validates secret-reference availability, runtime-file posture, environment bindings, and product compatibility without contacting a source. An offline-only project may deliberately omit runtime bindings. You can test and build that project, but you cannot start it until an operator supplies the missing environment values.

For the supported local spreadsheet runtime, use registryctl doctor --profile local to validate the complete selected worksheet and the host prerequisites.

Check the local API

For the supported local profile:

registryctl doctor --profile local
registryctl start
registryctl smoke

doctor checks the local Registryctl installation, matching release assets, container provider, and project. start prepares the loopback-only runtime. smoke checks readiness and the maintained allowed and denied requests.

If you edit a workbook or authored YAML while the previous local runtime is still present, inspect that existing runtime before rebuilding it:

registryctl status
registryctl logs
registryctl open

These commands verify the existing generated runtime before reading its status or logs. They do not rebuild, start, or trust the changed authored input. After you correct the source problem, rerun registryctl start to replace the generated runtime.

For a stable diagnostic code and recovery action, use the operator diagnostic catalog.

Stop it when you finish:

registryctl stop

What these checks do not prove

Local success does not approve a production deployment, prove that a live country source is interoperable, or replace data, security, and operational review. Production credentials, networking, signing, activation, migration, and rollback belong to the operator handoff.