daemon-backend-lingtai

# LingTai Daemon Backend — Knowledge Entrypoint `backend="lingtai"` is the built-in default — an in-process ChatSession run loop, not a wrapped external CLI. There is no installed binary whose help output could be consulted, and `backend_options` is ignored (there is no CLI process to forward argv to), so this backend has no flag surface to discover or translate. Its behavior is owned by live LingTai configuration, manuals, and source — route to the current authority instead of memorizing snapshots. ## Where the knowledge lives 1. **Task shape and behavior contract** — the `daemon-manual` router ([`manual/SKILL.md`](../../../../../SKILL.md)): `task` vs `prompt` vs `tools` vs `skills` vs `mcp` semantics, and the shared parent [`reference/cli-backends/SKILL.md`](../../../SKILL.md) for backend support. 2. **Preset selection and inspection** — run `system(action="presets")` for the live tier/connectivity/capability listing (guidance: `system-manual` → `reference/substrate-manual/SKILL.md`). A per-task `preset` must be a `.json`/`.jsonc` path exactly as returned by that listing; an unloadable or unreachable preset refuses the whole batch at emanate time. Omit `preset` to inherit the parent's regular (non-MCP) tool surface. 3. **Tools/skills/MCP inheritance** — parent MCP tools are **not** auto-inherited: pass full one-run `mcp` registrations per task. `skills` entries become a compact prompt catalog (paths, not pasted bodies). `email` is daemon-eligible but opt-in via `tools`. Preset-supplied capabilities are resolved first; only requested File/Shell host tools can be filled from the parent. Provider-bound tools do not silently borrow parent services. 4. **Completion contract** — the built-in `daemon_common` MCP is added automatically and `finish(status="done")` is the only terminal-success signal. The maintainer-facing architecture invariants are `src/lingtai/tools/daemon/CONTRACT.md`; the current tool schema description is the caller-facing authority. ## `context_token_limit` `context_token_limit` is a positive provider-compaction threshold, not a context or window setting. It is honored only for native LingTai LLM providers `Codex` and `mimo`; other native providers and every external CLI backend ignore it. An explicit preset resolves the comparison window from canonical `manifest.llm.context_limit`; without a preset, use the inherited parent effective window. Codex Responses uses `context_management` with stateless/full-history replay; compaction failure is non-fatal. Native mimo compaction failure is a hard failure. The external `mimo`/`mimocode` CLI alias is unrelated. ## Example: explicit preset, tools, skills, and MCP ```jsonc { "action": "emanate", "input": {"backend": "lingtai", "max_turns": null, "timeout": null, "tasks": [{ "task": "Summarize reports/audit.md into reports/audit-summary.md. Do not alter other files.", "tools": ["file"], "preset": "/approved/preset.json", "skills": [".library/custom/audit"], "mcp": [{"name": "local-docs", "transport": "stdio", "command": "python", "args": ["-m", "local_docs_mcp"]}] }]}, "reasoning": "bounded evidence task" } ``` Every field above resolves live: the preset path comes from `system(action="presets")`, skill paths resolve against the parent working directory, and the MCP registration is started as a task-scoped client whose tools appear only for this run (secret `env`/`headers` values are redacted in prompts). ## Harness boundary There is nothing to tune at the process-spawn layer: no reserved flags, no argv, no `backend_argv`/`backend_harness_argv` in `daemon.json`. Model and tool shape are chosen through `preset`; behavior is guided through `task`; capability comes from `tools`/`skills`/`mcp`. LingTai-backend tool calls still pass the kernel ToolExecutor/ToolCallGuard gate — a daemon run does not bypass normal execution policy.