Workspace and Tooling

Atlas lives in a multi-crate workspace. Development works best when you treat the workspace as the unit of truth, not only the single crate you happen to be editing.

Workspace View

flowchart LR
    Workspace[Workspace root] --> Atlas[crates/bijux-atlas]
    Workspace --> DevAtlas[crates/bijux-dev-atlas]
    Workspace --> Docs[docs/]
    Workspace --> Ops[ops/]
    Workspace --> Configs[configs/]

This workspace view shows why Atlas changes should rarely be reasoned about in one crate alone. The runtime, control plane, docs, configs, and ops material form one governed repository surface.

Tooling View

flowchart TD
    Cargo[Cargo] --> Build[Build and test]
    MkDocs[MkDocs] --> DocsSite[Docs site]
    Make[Make targets] --> Automation[Common workflows]
    DevAtlas[bijux-dev-atlas] --> ControlPlane[Governed checks and reports]

This tooling view keeps the main developer entry points visible. Each tool has a role, but bijux-dev-atlas is the unifying control plane for governed repository checks and generated evidence.

Practical Advice

• run commands from the workspace root
• treat bijux-dev-atlas as part of the development toolchain, not as a separate afterthought
• keep artifacts under artifacts/
• prefer explicit paths over current-directory assumptions

Toolchain Baseline

The current workspace MSRV and pinned Rust toolchain are both 1.85.0.

If Cargo.toml, rust-toolchain.toml, and release validation disagree about that version, treat it as a release blocker rather than a cosmetic drift.

Good Workspace Discipline

• start from the workspace root
• prefer governed commands over one-off local wrappers
• keep outputs under artifacts/ so cleanup and review stay predictable

Purpose

This page explains the Atlas material for workspace and tooling and points readers to the canonical checked-in workflow or boundary for this topic.

Stability

This page is part of the canonical Atlas docs spine. Keep it aligned with the current repository behavior and adjacent contract pages.