Credential-free source validation

The first release question is whether the checked-in contracts agree before an operator spends time or testnet tokens on a candidate. Source validation checks code behavior, rendered configuration, operator guards, and the reviewed documentation. It requires no cloud credentials, running cluster, funded wallet, or payment endpoint.

This is the appropriate starting point for a contributor or reviewer. A passing result establishes the tested source contract. It does not establish that an image was published, a controller reconciled an environment, or a chaos gate passed. Those observations belong to a named release record.

Prepare the tools

Run commands from the repository root. The application and test tooling target Python 3.12. The broad validator also requires Helm, Terraform, and kubectl because the repository includes charts, Terraform configuration, and Kustomizations. Docker is optional for Compose configuration checking and required for the separate local smoke.

python3 -m venv .venv
.venv/bin/python -m pip install -r requirements-dev.txt
PYTHON=.venv/bin/python make validate

The Make target delegates to scripts/validate.sh. The validator runs these responsibilities in order:

Check	What it establishes
Documentation validation	Existing documentation links, screenshot inventory and hashes, and reproducible vector artwork agree with checked-in files.
Helm lint and render	Application profiles for dev, staging, and prod and the observability chart can render with their committed dependencies.
Terraform format/init/validate	Configuration is formatted and internally valid with the provider lockfile; backend initialization is disabled.
Shell syntax	Committed shell entrypoints parse, without sourcing ignored operator input.
Gate-runner inputs	Orchestrator, scorer, annotation helper, and workflow are present together.
Kustomize render	Committed Kustomizations compose successfully; nothing is applied.
Python tests	Application, delivery, gate, load, bootstrap, and evidence contracts satisfy the deterministic suite.
Signer tests	The separately located Permit2 tests are explicitly included.
Compose configuration	Docker, when installed, can parse the ordinary local Compose stack.

“Credential-free” does not mean every first run is offline. Installing Python packages and terraform init -backend=false may download dependencies. The Terraform step does not initialize the remote backend, calculate a cloud deployment, or apply resources. kubectl kustomize renders local manifests rather than using the current Kubernetes context.

Use a narrower check deliberately

For a documentation-only change, the existing presentation check is:

python3 scripts/validate-docs.py

For a focused source investigation, run the relevant deterministic tests, for example:

.venv/bin/python -m pytest tests/gate/test_no_data.py
.venv/bin/python -m pytest tests/validation/test_evidence_tools.py

The default pytest configuration excludes the integration marker. The marked local recovery contract uses an in-process ASGI client and fake dependencies; CI runs it separately. It can be selected explicitly without introducing a real payment or cloud operation:

.venv/bin/python -m pytest -m integration tests/integration/test_local_recovery.py

That test differs from Compose smoke, which starts real local containers. A live or paid-testnet procedure requires its own reviewed scope; selecting tests should never be used to bypass those entrypoint guards.

Interpret a failure

Stop at the failed layer. A missing Helm binary is a missing prerequisite, not a failed application contract. A failed render means the configuration needs review before any controller sees it. A scorer fixture failure means source behavior changed; it says nothing about whether the lab currently has usable telemetry.

Do not replace current output with an old test count. The 3 October verification report records 231 broad tests, one separately executed marked recovery check, and 13 signer tests for its source snapshot. Those numbers are historical observations. Record the actual checkout, command, prerequisites, exit status, and counts from each new validation.

The underlying contract is inspectable in pytest.ini, CI validation, and validation tooling tests. After source validation, continue with local development or inspect lab prerequisites according to the operation you intend to perform.