Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/preview/llms.txt
Full corpus: https://docs.registrystack.org/preview/llms-full.txt

# Validate your project

> Check your Registry Stack project before you start it or hand it to an operator.

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

```sh
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:

```sh
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:

```sh
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:

```sh
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](../reference/diagnostics/operator/).

Stop it when you finish:

```sh
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.

## Next

- [Understand the generated files](../generated-artifacts/)
- [Prepare the operator handoff](../operate/)
- [Look up an error or status code](../reference/errors/)