Expand description
onepipeline owns a task DAG, executes it over
oneagentgraph and
onevcs, and merges the three
libraries’ event streams into one.
Dependency direction is one-way: onepipeline → {oneagentgraph, onevcs}.
Agent, harness, and model selection stay in the first; repository identities,
sessions, and publication stay in the second. This crate composes them and
owns the DAG, its continuous execution, the planner channel, and the
executor seam that decides where a dispatch runs.
§The surface, and what is behind it
Every public item here is named by
docs/contract.md — the approved contract,
committed verbatim — and the engine implementing it is private, so a
consumer can only reach what the contract promised.
tests/contract.rs drives the fixtures out of that document through these
types, so the two cannot drift.
A plan is not a file: it is one project of a
onetaskgraph store, named
by its qualified id and read through that product’s own binary. What this
crate owns is the run — its journal, its ledger, and the graph it projects
from them — and the plan’s definition stays where the user already tracks
their work.
A run’s durable state is one directory: the plan it was launched with, the merged event store every view reads, the run’s own result, the channel’s transport, and — beside the store — the account of any record a writer left half-written. The process driving the run is that ledger’s single writer, guarded by the run’s ownership lock; everything else reads.
Composition is by subprocess. The agents come from oneagentgraph and the
clones, publications, and change requests from onevcs, each reached
through its own CLI — so a build of either that still refuses will make the
dispatches this crate starts refuse too.
Where the contract could not be compiled exactly as written, the code
compiles against what does exist and the divergence is recorded in
docs/contract-divergences.md for
the planner who owns the contract. Every entry there has now been ruled on
and the contract amended to carry the ruling.
Re-exports§
Modules§
- channel
- The planner channel: the wire shapes, and the durable queue behind them.
- cli
- The command-line argument surface.
- controls
- The per-node controls a dispatch carries, and how each one reaches it.
- error
- The failure modes the contract names, and the process exit codes it assigns.
- event
- The merged event stream’s envelope.
- executor
- The executor seam.
- filter
- The shared event-filter grammar, and this library’s two uses of it.
- note
- The manager-note delivery seam: one note that reaches whichever party of a node’s live dispatch is speaking, and reaches the other with its response — or, where it reached no turn, is carried to the node’s next dispatch.
- plan
- The plan schema.
- report
- The report a settled member left behind.
- rules
- The executor-rules schema.
- views
- What the read-only views report.
Constants§
- VERSION
- The release of this crate a consumer is linking.
Functions§
- run
- Execute one parsed command line.