bijux-dag-app¶
bijux-dag-app is the application orchestration layer for bijux dag
surfaces. It translates command inputs into services, coordinates reads and
writes, and shapes user-facing responses.
Use this page when the issue is about command behavior or output shape rather than graph truth or execution internals.
Responsibility Map¶
| Surface | Ownership |
|---|---|
| command orchestration | argument-to-service routing, workflow dispatch, output selection |
| response shaping | render flows, response models, diagnostics views, command-specific output contracts |
| app-level services | read, write, replay, inspect, graph, cache, and export/import orchestration |
| boundary | does not own kernel semantics, runtime scheduler internals, or artifact storage authority |
Source Layout¶
crates/bijux-dag-app/src/commandscrates/bijux-dag-app/src/routescrates/bijux-dag-app/src/inspectcrates/bijux-dag-app/src/replaycrates/bijux-dag-app/src/graphcrates/bijux-dag-app/src/formatcrates/bijux-dag-app/src/readcrates/bijux-dag-app/src/write
Open Next¶
- open the DAG Handbook for the package-wide architecture and interfaces
- open
bijux-dag-runtimewhen the question crosses from response shaping into execution policy - open
bijux-dag-cliwhen the concern is process wiring rather than app orchestration
Code Anchors¶
crates/bijux-dag-app/README.mdcrates/bijux-dag-app/CONTRACT.mdcrates/bijux-dag-app/src/lib.rscrates/bijux-dag-app/src/routes/run_routes.rscrates/bijux-dag-app/src/inspect/service.rs
Review Lens¶
- command routing should stay thin enough to explain and thick enough to keep user-facing contracts coherent
- orchestration should delegate kernel and runtime work instead of re-implementing it
- output contracts should remain explicit and test-backed