khive-request — request-DSL parser, transport-agnostic.
Scope
Conceptually every transport into khive walks the same pipeline:
request string → parse → ParsedRequest → dispatch (VerbRegistry) → result
This crate owns only the parse step. The AST it produces (ParsedRequest,
ParsedOp) is consumed by transports (MCP today; HTTP gateway, FFI, CLI
in future) which then dispatch through khive-runtime's [VerbRegistry].
Keeping the parser in its own crate frees us to grow the syntax — pipe
chains, $prev substitution, LNDL-style natural-language declarations,
bash-flavoured redirections — without touching the runtime layering.
Today's syntax (v0.2 — ADR-020)
- Function-call form:
tool_name(arg=value, arg=value) - Function-call batch:
[tool_name(...), tool_name(...)] - JSON form:
[{"tool":"...", "args": {...}}, ...](or a single object)
Argument values are JSON literals — strings, numbers, booleans, null,
arrays, objects. Top-level operations inside [...] run in parallel by
convention (the parser preserves order; the transport drives concurrency).
Planned (deferred to dedicated ADRs)
- Pipe chains for sequential dependent ops (
v1(...) | v2(id=$prev.id)). - LNDL frontend — parses lact-block source and emits the same
ParsedRequest. - Bash-style redirection / substitution for ops that produce stream output.