Workspace

The z00z workspace is a Rust monorepo, not a docs-first site. It contains live crates, binaries, tests, benches, verification scripts, and a research corpus under docs/. The first workspace habit to learn is evidence ownership: crate behavior is proved by the workspace, while broader protocol posture is often proved by the whitepaper corpus and must stay maturity-aware.

Readers who keep that boundary visible make fewer placement mistakes and write safer public claims. That habit scales.

Use the workspace map before making changes. Most mistakes in this repository come from editing the wrong crate, bypassing a shared abstraction, or writing a claim as if a corpus concept were already a shipped runtime surface.

Repository Shape

The active workspace is organized around member crates and repo-level support surfaces:

Do not treat docs/ as the runtime authority and do not treat the workspace manifest as a whitepaper substitute. Each layer answers a different question.

Crate Ownership Model

The main structure is not route-based. It is ownership-based:

This model matters because most implementation work should not add a second authority. Storage should not redefine core object meaning. Wallet helpers should not quietly become settlement truth. Research prose should not outrun the crates.

Workspace And Manifest Boundaries

The root Cargo.toml is the fastest structural source. It defines workspace members, default members, resolver, lint posture, and rust-version = "1.90.0". Individual crate manifests then define bins, tests, benches, features, and local dependency edges.

That means a contributor should ask these questions first:

Do not add a second config system, a parallel semantic authority, or a new bypass around z00z_utils just because a narrow crate change feels faster.

Configuration And Scripts

The z00z repo uses repo-level scripts and cargo entrypoints together. The most important first-session commands are:

If you document a command, it should appear in README.md, a crate manifest, or an actual script file. If the command does not exist, that is implementation work, not documentation wording.

Instruction Surfaces

.github/ contains the local automation and instruction layer:

These files are local evidence for workflow claims. They are not a reason to publish private prompt internals. Public docs should describe the supported workflow at the right level: which surfaces exist, what they are for, and how they protect the repository from drift.

Where Not To Put Things

The fastest workspace mistakes are placement mistakes:

This boundary keeps the repository understandable. It also prevents concept drift where one crate quietly starts acting like a second protocol authority.

Local Versus Target Architecture

The workspace has three evidence levels:

1. Live local repo evidence: crates, manifests, tests, scripts, bins, and help output that exist in z00z today.
2. Corpus-backed architecture: protocol concepts defined in content/whitepapers/, such as wallet-local possession, checkpoint settlement, assets, vouchers, rights, privacy boundaries, and post-quantum migration.
3. Open or target work: surfaces the papers describe more broadly than the current crates prove.

When writing developer docs, keep those levels visible. For example, this repository can prove that the rollup-node crate exists, that the simulator exposes scenario_1, and that the wallet crate declares specific bins and features. It should not pretend that every whitepaper lane is already a generated public API or a fully stabilized operator surface.

Practical Reading Path

If you are new to the workspace, use this path:

1. Open README.md and the shared full_verify.sh script to understand local commands.
2. Read README.md for the current quickstart and common workflows.
3. Read the root Cargo.toml for workspace membership and lint posture.
4. Read the owning crate manifest and nearby src/, tests/, examples/, or bin/ files.
5. Read the relevant whitepaper before adding protocol, wallet, privacy, legal, or crypto claims.
6. Run the targeted cargo gates and the shared full verify script before closing the work.

This sequence is intentionally boring. It keeps builders aligned with the actual repo instead of forcing them to infer structure from stale page names or assumptions carried over from other repositories.

It also keeps review cost down. When a contributor can name the owning crate, the governing manifest, the relevant tests, and the whitepaper section behind the claim, the next reviewer does not have to rediscover the repository from scratch.

Read Next

Continue to Core Protocol API for the object vocabulary, Verification And Tests for the gate stack, or AI Agent Playbook for repo automation rules.

Evidence and Further Reading

• github.com/z00z-labs/z00z, README.md, and root Cargo.toml define the live workspace map, common workflows, and member crates summarized here.
• crates/z00z_rollup_node/Cargo.toml, crates/z00z_simulator/Cargo.toml, and crates/z00z_wallets/Cargo.toml define the live operator, scenario, and wallet surfaces referenced here.
• .github/copilot-instructions.md and .github/requirements/Z00Z_DESIGN_FOUNDATION.md in the z00z repo define contributor rules, architecture boundaries, and verification posture.
• ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh in the z00z repo defines the shared broad verification gate.
• Main Whitepaper sections 3, 4, and 12 define the object, checkpoint, and maturity split used when workspace docs distinguish live code from broader protocol architecture.