Verification And Tests

Verification in z00z already has a live code meaning, not just a docs meaning. The workspace ships real cargo gates, crate tests, benches, runnable targets, wallet feature boundaries, and simulator surfaces. Passing the current workspace gate is evidence for existing code, not proof that every target-architecture lane is complete.

The current z00z repository has verification gates, while deeper protocol checks must expand as more runtime surfaces harden.

Correctness depends as much on precise claims as on successful commands.

Verification Ladder

The ladder is ordered from fast local confidence to broader safety review. Today, the repo already has a real broad gate in ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh, plus targeted cargo commands and CLI help surfaces exposed in README.md. Future protocol hardening should extend that stack, not replace it with looser prose.

Current Local Commands

The current verification surface is defined by the workspace README, manifests, and shared verify script:

• cargo fmt --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace
• cargo run -p z00z_rollup_node -- --help
• cargo run -p z00z_simulator --bin scenario_1 -- --help
• ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh

The first three commands are the normal Rust delivery gate. The help commands are not decoration: they prove the current node and simulator entrypoints really exist. The shared full_verify.sh sweep then widens the gate to formatting, workspace clippy, tests for libs, bins, tests, examples, doctests, bench compilation, whitelisted runnable targets, and long-running test reporting.

That means a passing broad gate says something meaningful about the live workspace. It still does not prove every whitepaper target, but it is the right baseline for code claims.

Content-Source Checks

Developer work still needs stronger source checks than a single green command. For advanced pages and code-adjacent claims, acceptance should verify at least:

• Commands cited on the page appear in README.md, a crate manifest, or a real script.
• Crates, bins, tests, benches, and features cited on the page exist in the workspace.
• Risk-heavy flags such as wallet_debug_tools, verbose logging, or debug exports stay clearly non-production.
• Whitepaper-backed claims name the local content/whitepapers/*.md source and keep the maturity boundary visible.
• Docs pages still meet the local page contract: frontmatter, ## Read Next, and ## Evidence and Further Reading.
• Future protocol claims are labeled as target architecture when implementation evidence is absent.

These checks are deterministic and local. They can be implemented with rg, wc, short shell scripts, or future docs-specific validation scripts. They should not rely on a model to decide whether a required heading exists.

Editorial Review Loop

Substantial changes should go through repeated review passes, not a single green cargo run. Review the actual files changed, fix every significant issue, and continue until the latest pass stops finding material problems in claims, structure, scope, or source linkage.

For documentation-focused work, the review should check source coverage, concept drift, unsupported implementation claims, broken anchors, missing evidence, and maturity widening. Crypto or security specialist review is triggered when the change touches cryptographic claims, wallet recovery boundaries, privacy-sensitive logging, or runtime security posture.

Source Audit

A source audit is useful whenever repo-specific claims need proof. The workflow is straightforward: extract claims, verify local claims against workspace files first, use external sources only for standards or facts not resolved locally, and record whether claims are verified, plausible, contradicted, or unsupported.

For these docs, a source audit should confirm that pages do not invent files, commands, bins, tests, or shipped protocol behavior. It should also confirm that external references such as JSON-RPC are official standards pages when cited and that whitepaper anchors really support the protocol language being used.

Security and Privacy Review

The Privacy Threat Model makes privacy testing explicit. Documentation should call out privacy risks instead of implying they are solved by architecture diagrams. Current implementation review should pay special attention to wallet recovery boundaries, telemetry, timing leakage, selective disclosure, support export, and debug-only wallet features.

Security review should be triggered when code changes expose new request surfaces, secret handling, wallet actions, or external integrations. The main documentation risk here is misdocumentation: telling builders that a surface is safe, stable, or live when the repo proves something narrower.

Future Protocol Tests

Deeper protocol tests should continue to live beside the implementation they verify. Likely suites include:

• Storage root and HJMT-style proof tests.
• Replay-protection and nullifier-domain tests.
• Package validation and batch ordering tests.
• Data availability publication and retrieval tests.
• Checkpoint artifact and maturity tests.
• Wallet-local possession and disclosure tests.
• WASM wallet storage, prompt, and recovery tests.
• RPC request validation and error hygiene tests.
• Useful-work evidence, scoring, challenge, slashing, and appeal tests.
• Governance and genesis configuration tests.

Some of these suites already have visible footholds in the workspace today: wallet tests and benches in crates/z00z_wallets, simulator tests and examples in crates/z00z_simulator, and workspace-wide verification in full_verify.sh. Future additions should deepen those real surfaces instead of replacing them with documentation-only stand-ins.

Evidence Gate

Before closing a docs change, use this evidence gate:

1. Run scoped deterministic checks for the files changed.
2. Run the editorial review loop until significant in-scope issues stop appearing.
3. Fix all findings.
4. Run the relevant cargo gates and the shared full verify sweep when the scope justifies it.
5. Record concise evidence in the change summary or verification note.

If any gate fails, do not move forward until the issue is fixed or the blocker is explicitly recorded.

What Passing Means

Passing cargo check --workspace means the workspace resolves. Passing cargo test --workspace means the current suite passed. Passing full_verify.sh means the repo passed its current broad sweep. Passing the scoped docs checks means the edited pages meet the current structural and source-coverage expectations. Each result applies only to the command, crate, configuration, and current commit actually tested. These are strong signals, but they are still not automatic protocol security proofs.

A command result is not transferable to a different binary, feature set, network configuration, or release revision.

Future protocol code should define its own pass meanings. A storage test pass should mean roots and proofs behaved as expected. A wallet test pass should mean authorization, disclosure, recovery, and privacy cases passed under real wallet primitives. A useful-work test pass should mean evidence and dispute logic behaved as specified. Keeping those meanings separate makes release notes, audits, and user claims safer.

Failure Handling

When a verification command fails, fix the cause before moving forward. Do not work around a failing check by weakening the claim it was supposed to protect unless the documented requirement actually changed. If a check cannot be run, the summary should state the exact command, blocker, and residual risk. Silent skips are not acceptable evidence gates.

Review Evidence Records

Review summaries should record what was checked, not just that review happened. Useful evidence includes the exact cargo commands run, the crates or bins affected, docs source-anchor checks, claim-audit identifiers where used, and the final broad verify result. This evidence makes the next pass safer because it can resume from concrete facts instead of reconstructing intent from diffs alone. It also makes regressions easier to isolate.

Read Next

• Simulator for scenario-driven validation.
• API Reference for source-linked API claims.
• Examples And Tutorials for tutorial maturity discipline.

Evidence and Further Reading

• github.com/z00z-labs/z00z, README.md, and root Cargo.toml define the live quickstart, workspace members, and cargo gate posture summarized here.
• ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh in the z00z repo defines the broad verification sweep described here.
• crates/z00z_wallets/Cargo.toml and crates/z00z_simulator/Cargo.toml define the current tests, benches, examples, bins, and debug-sensitive features used as review anchors here.
• Privacy Threat Model And Metrics section 10 for privacy simulation and validation expectations.
• Proof-of-Useful-Work section 5 for useful-work proof and evidence concepts.