Skip to content

Package Surface

bijux-atlas-dev is a repository-only crate with publish = false. Its supported surface is the maintainer binary, its installed umbrella route, governed command identities, report contracts, and generated outputs—not a public Rust library API.

flowchart TD
    Crate[bijux-atlas-dev] --> Binary[bijux-atlas-dev binary]
    Binary --> Umbrella[bijux dev atlas]
    Binary --> Direct[cargo run -p bijux-atlas-dev]
    Binary --> Wrappers[Make and workflow routes]
    Binary --> Reports[Versioned reports and artifacts]
    Crate --> Internal[Private modules and adapters]
    Umbrella --> Contract[Maintainer contract]
    Direct --> Contract
    Wrappers --> Contract
    Reports --> Contract
    Internal --> Detail[Implementation detail]

Supported Surface

  • the bijux-atlas-dev binary identity and exit behavior;
  • the bijux dev atlas ... installed namespace when the Bijux umbrella is present;
  • command and suite identifiers consumed by Make, CI, and documentation;
  • capability flags controlling write, subprocess, network, and git effects;
  • structured report kinds, schema versions, paths, and validation commands;
  • generated references whose registries name this binary as their generator.

Internal handlers, module layout, and adapter implementations can change while those observable contracts remain stable. A private Rust symbol becomes a compatibility concern only when another supported repository surface consumes it as an authority.

Consumer Map

Consumer Supported dependency Unsupported shortcut
contributor direct binary help, documented command, and structured report importing private command handlers
Make target command, arguments, capabilities, and status reproducing domain logic in Make
GitHub workflow locked direct invocation and retained artifacts parsing terminal prose as a report contract
umbrella CLI explicit delegation contract silently changing capabilities or defaults
generated reference registry, source set, and generator copying output without provenance checks

The maintainer crate may expose Rust items for its own binaries and tests. That does not turn those items into a published library promise. External Rust consumers should use the product or operations crate that owns the needed behavior.

Command Authorities

The compiled CLI in crates/bijux-atlas-dev/src/interfaces/cli/ is the executable authority. The policy declaration at configs/sources/governance/governance/cli-dev-command-surface.json records the intended top-level families and forbidden product flows. The two must be validated together; configuration does not create a runnable command.

At this revision, compiled --help and the policy declaration are not identical. The declaration lists clients, packages, and demo, which are not exposed as compiled top-level commands, while compiled help exposes migrations, which is not listed in the declaration. Treat that difference as registry drift rather than silently promising either side as synchronized.

The registry also forbids query as a maintainer user-flow command. Product queries belong to bijux atlas, while repository validation and evidence remain under bijux dev atlas.

Repository Stability Contract

Changing a command name, capability requirement, report schema, or governed artifact path requires consumer and workflow review. Moving internal modules does not, provided direct CLI, umbrella, Make, and workflow routes retain their claimed parity. See Automation Command Surface for command selection and report discovery.

Compatibility Boundary

The crate is not published to crates.io, so its stability is repository contract stability rather than a public library SemVer promise. Checked-in consumers and documented maintainer commands define the support burden. A consumer that reaches into internal modules creates coupling to remove, not an automatic expansion of the supported surface.