`jobs::NodeView` can only ever display hive-c0re's queue. Five of its fields are domain knowledge: `approval_id` is only ever on a `DeployWindow`, `inputs` only on a `MetaLock`, `build_log_id` only on the nix-heavy kinds, `agent` is derived from the payload, and `kind` is a payload tag consumers branch on. A component built against that shape cannot render a second jobq. `graph::GraphNode` is `hive_jobq::Node` with both generics erased: the crate's own field set, with everything domain-specific in one opaque `payload.data` slot the consumer renders without branching on. That is the crate boundary made visible — hive-jobq owns structure, its host owns meaning — and it is the same split #2957 drew inside the code. Two details that are easy to get wrong and are pinned by tests: `GraphDep::Node` carries `accepts` as the **set** of terminal outcomes, not a strong/weak flag. A template emits its tails as a pair edged on the same upstream node, and the only thing telling them apart is which outcomes each accepts; collapsing that renders two structurally different nodes identically. There is **no roll-up field**. A group root ships as an ordinary node with `parent: None`, and its own `state` is its subtree's answer — `Finishing` means "own logic done, children still running", the terminal states are the rolled-up outcome. A separate field would be a lossier copy: `DagView::rollup_state` flattens `Running` and `Finishing` into one, which is exactly the distinction a viewer wants. `State` and `TerminalState` are re-exported from `hive-jobq` rather than redeclared, so they cannot drift from the scheduler that produces them.
16 lines
305 B
TOML
16 lines
305 B
TOML
[package]
|
|
name = "hive-host-sock"
|
|
edition.workspace = true
|
|
version.workspace = true
|
|
readme = "README.md"
|
|
|
|
[lints]
|
|
workspace = true
|
|
|
|
[dependencies]
|
|
chrono.workspace = true
|
|
hive-jobq.workspace = true
|
|
hive-sh4re.workspace = true
|
|
hive-types.workspace = true
|
|
serde.workspace = true
|
|
serde_json.workspace = true
|