zeekay
21c96cf03f
Add read-only hanzo doctor checks and strict provenance verification. Reserve hanzo-node for the network node and use hanzo-cli for control delegation. Release 8.5.754. Testing: 387 Rust unit tests and three cloud parser tests passed; strict clippy passed; installer fixtures passed under sh and bash; real Gen strict provenance verified with GitHub CLI 2.102.1. Risk: installer alias migration removes only the known legacy hanzo-node symlink. Strict mode requires authenticated compatible gh and available release attestations; normal mode continues to require checksums and reports unavailable provenance. How to revert: revert this commit and republish the previous installer; install CLI v8.5.753 if necessary.
1.8 KiB
CLI end-to-end checks
make test runs the Rust workspace, command/parser checks, installer fixtures and API-spec drift checks. Live checks are opt-in: unit tests alone do not prove production works.
Run the production checks using your existing login:
HANZO_E2E_TOKEN="$(hanzo auth token)" make e2e
This exercises token login through stdin, identity, authenticated usage JSON, a local dev task that writes and verifies a file in a temporary Git repository, and a read-only cloud task that clones a real repository and completes inference. It requires dev on PATH. The local and cloud tasks consume normal usage; the cloud test leases a sandbox. It does not log out your existing account or modify the source repository.
The steering check also starts a bounded read-only task, sends an instruction
while it runs, follows the replacement session, and verifies its repository
answer. It requires an API release serving /v1/agent/coding/{session}/steer.
Both sessions have a 120-second execution budget. The test fails if the
instruction is refused or the handoff never completes.
Test the public installer and its actual downloaded binaries:
HANZO_E2E_TOKEN="$(hanzo auth token)" make e2e-installed
The installer runs in a temporary directory, verifies release checksums, and installs hanzo, hanzo-cli, dev, gen, and MCP. Tests use that directory first on PATH. It leaves your normal installation intact. A missing token is an error, and every coding test must actually complete; HTTP errors and a missing output file fail the run.
The tests cover the machine and platform on which they run. They do not replace macOS/Windows installation checks or interactive browser OAuth testing. Token login uses a real existing IAM session; it does not simulate a fresh browser sign-in.