Architecture

JP is a Cargo workspace of small crates, each owning one concern: jp_cli parses commands and drives a query, jp_llm talks to providers, jp_conversation holds the event stream, and jp_storage and jp_workspace persist it. The pages below describe how those pieces meet.

Read the Query Stream Pipeline Architecture first: it is how a jp query turn runs today, from the streamed response to tool calls and interrupts. Structured Output Architecture and Indexing and Counting Conventions build on it. JP Query Architecture is the March 2026 analysis the pipeline was designed to answer, kept as a Snapshot. The knowledge base and Wasm tools pages are designs that have not been built.

Query Stream Pipeline ArchitectureHow `jp query` handles a streamed response: the turn coordinator's state machine, the event builder, the renderers, tool coordination, and interrupts.
Structured Output ArchitectureHow structured output flows through the streaming pipeline: a schema on `ChatRequest`, native provider APIs, and a `Structured` variant on `ChatResponse`.
Indexing and Counting ConventionsTurn positions are 1-based in the CLI and configuration and 0-based in stored and internal state, translated once at each boundary.
JP Query ArchitectureThe `jp query` command stack as it stood in March 2026, and the coupling and testing problems the query stream pipeline set out to fix.
Knowledge Base ArchitectureA design for a workspace knowledge base of topics and subjects, retrieved through a built-in `learn` tool and injected into the system prompt.
Wasm Tools ArchitectureA design for running tools as WebAssembly components: the `wasmtime` runtime, the WIT contract, and built-in and local Wasm tools.

Architecture ​

Architecture