Handbook

Deployment topologies

Long-lived API worker imports TaskRunner, injects production chat, enforces auth before building LCDL payloads.

Updated

Pattern A — App service (sync)

Long-lived API worker imports TaskRunner, injects production chat, enforces auth before building LCDL payloads.

Pros: simplest ops story. Cons: request latency equals LLM latency unless queued.

Pattern B — Batch worker

Jobs pull records, call run_task with fake_chat for replay/tests or live chat for production batches.

Pros: easier rate limiting. Cons: requires durable job store outside LCDL.

Pattern C — IDE MCP sidecar

Cursor (or another MCP host) loads LCDL tools (MCP sidecar).

Pros: rapid human iteration. Cons: policy alignment with desktop egress controls.

LCDL deployment topologies

Three reference patterns for embedding governed LCDL tasks in services, batch workers, and IDE hosts.

  1. A — sync API service (TaskRunner in request path)Long-lived API worker runs TaskRunner inside each request.
  2. B — batch worker (queue + replay / live chat)Queued jobs call run_task with replay or live chat.
  3. C — MCP sidecar / IDE (egress policies vary)MCP host loads LCDL tools for IDE-adjacent iteration.

Shared rules

  • Keep secrets in orchestrator secrets stores—not in repo Markdown.
  • Centralize gateway routing per environment (Model routing).