bijux-dag-cli
bijux-dag-cli installs the bijux-dag executable. It is the public command
package for the DAG product.
bijux-dag v0.4.0 is a local-first DAG runtime for reproducible workflows
with explicit graph contracts, deterministic execution records, verified
artifacts, cache explanation, and replayable run bundles. This crate is the
installed command surface for that promise.
Install it when you want the standalone DAG command surface:
For most users, this is the package to start with. It gives you the supported local DAG workflow surface without asking you to assemble the lower-level DAG crates yourself.
Release Status
- public crate on the
v0.4.0DAG release line - installs the stable operator-facing
bijux-dagbinary - does not promote experimental, simulated, or internal namespaces into the default public contract
Stable Operator Boundary
The supported release boundary is the visible bijux-dag --help surface:
validate, plan, run, replay, runs, artifact, artifact-inspect,
diff, explain, verify, doctor, cache, version, commands, and
completions.
Experimental routes remain available by explicit path for repository-owned
workflows, and bijux-dag commands --lane experimental is the deliberate
inventory surface for that lane. Simulated and maintainer namespaces require
explicit lane inventory through bijux-dag commands --lane simulated or
bijux-dag commands --lane internal, plus execution opt-in through
BIJUX_DAG_ENABLE_SIMULATED=1 or BIJUX_DAG_ENABLE_INTERNAL=1.
Container-backed nodes are part of the stable local execution surface. When a
supported engine such as Docker is available on PATH, bijux-dag run
executes the container step, retains stdout and stderr, and records engine and
image identity in the retained trace. When the engine is missing, the run
fails as an infrastructure error rather than silently degrading to another
execution mode.
Branch-backed workflows are also part of the stable local execution surface. When a DAG uses a branch node, retained runs record the selected decision, the skipped lane, and the join-node trigger evaluation so operators can inspect the execution path directly from run evidence.
What It Provides
- the
bijux-dagbinary entrypoint - thin startup wiring, process initialization, and exit mapping
- delegation into
bijux-dag-appfor actual command behavior - shell completion generation for the installed executable
- lane-scoped command discovery for stable, experimental, simulated, and maintainer-only route inventories
What It Does Not Own
- graph semantics
- runtime execution logic
- artifact persistence rules
If the question is about route behavior rather than process startup, the next
place to read is usually bijux-dag-app.
Representative Workflows
- Executable Examples maps the repository-backed hello, file-processing, cache, replay, failure, branch, and container proofs to their expected outputs.
- File Processing Workflow demonstrates a host-shell artifact workflow with replay and promotion.
- Cache Behavior Workflow demonstrates stable cache verification, explicit-path cache-miss explanation, selective invalidation, and corruption refusal.
- Reproducibility Model explains the retained identity surfaces behind cache verification, replay, export bundles, and artifact comparison.
- Data Pipeline Workflow demonstrates retained-run comparison and changed-input attribution.
- Branching Bulletin Workflow demonstrates retained branch decisions, skipped lanes, join-trigger evidence, and replay stability.
- Compliance-Gated Bulletin Workflow demonstrates transient retry evidence, focused replay repair, and strict verification after recovery.
- Container Packaging Workflow demonstrates mounted container inputs, retained outputs, and recorded image identity.
Internal schedule and backfill guides remain available in the DAG handbook for
deliberate maintainer work with BIJUX_DAG_ENABLE_INTERNAL=1, but they are not
front-door examples for the public bijux-dag package.
Internal Documentation
ARCHITECTURE.md: thin entrypoint flow, dependency boundary, ownership, panic containment, and change decisions.COMPLETIONS_AND_COMMAND_SURFACE.md: app-owned command authority, supported shells, compatibility, and references.CONTRACTS.md: process ownership, thinness, compatibility, failure, and verification contracts.INSTALLED_BINARY_CONTRACT.md: executable identity, argv, streams, status, isolation, and release evidence.PROCESS_AND_EXIT.md: parsing, dispatch status, streams, exit classes, signals, and process testing.TESTING_AND_RELEASE.md: test layers, isolation, release checks, and failure ownership.