Crate khive_request 

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.

Structs

ParsedOp

A single parsed operation: tool name + named argument bag.

ParsedRequest

Result of parsing a request input string.

Enums

DslError

Parser error — surfaced as invalid_params at the MCP boundary.

Constants

MAX_OPS

Hard cap on operations per request. ADR-020 §Why-100.

Functions

parse_request

Parse a request input string, returning either a single op or a batch.