UNPKG

@sema-agent/core

Version:

Stateless, task-oriented AI agent core

73 lines (72 loc) • 5.33 kB
import { type WebFetchConfig, type WebSearchConfig } from "../tools/web.js"; import { type TaskListStore } from "../tools/task-list.js"; import { type SubagentToolOptions } from "../agents/subagent.js"; import type { ToolSpec, RoleSpec } from "../core/types.js"; /** * design/102 (K-8) rename (`autonomous` scenario → `code`; the "full-body" working name followed — * this bundle IS the `code` scenario's caller-composed tool half; file name kept for history). Config for * the code-scenario `spec.tools`-class bundle. The RICH seam-gated roster * (present_plan/skill/AskUserQuestion/LSP/hands/memory/run_workflow/tool_search) is NOT here — it auto-mounts in * `prepareTask` when the trusted assembler wires those deps/flags. This bundle is only the caller-composed factories. */ export interface CodeToolsConfig { /** web_fetch policy. 🔴 `allowHosts` stays UNSET by default — passing `[]` would refuse ALL hosts (truthy empty, * `web.ts` `if (allowHosts && !allowlisted)`), breaking single-tenant TOC web fetch. A MULTI-TENANT deployment * MUST pass an explicit allowlist; the SSRF floor (`isPrivateHost`) applies regardless. */ webFetch?: WebFetchConfig; /** WebSearch backend (BRAIN/model-service leg). Absent ⇒ WebSearch is not assembled (core ships no backend). */ webSearch?: WebSearchConfig; /** Subagent delegation. Present ⇒ assembled. Without an explicit `subagent.tools` a child INHERITS this bundle's * surface as the leader's own instances (one `TaskListStore`), bounded by what the spawning run mounts and trimmed * by the spawn tier (`SubagentToolOptions.inheritedTools`). Tools composed BESIDE the bundle are not inherited: a * host hands those per spawn through `subagent.extraTools`, behind its own gates. * 合车复审修③: when this carries NO explicit `systemPrompt`, the assembler defaults it to * `CODE_SYSTEM_PROMPT` — a code-scenario child holds Bash/Write side-effect tools, so it keeps the code * constitution (snapshot-before-mutate / destructive-op care / git discipline) instead of falling to the * lean SUBAGENT_PROMPT (the G1 default, which is the right upstream-anchor shape only for bare * general-purpose delegation). Pass an explicit `systemPrompt` here to override. */ subagent?: SubagentToolOptions; /** * TodoWrite (CONTEXT leg). Default true, BUT mutually exclusive with the task-list family (CC 209 * parity: TodoWrite is enabled only when the task list is off). With `taskList` on (the default), * TodoWrite is NOT mounted even when `todoWrite: true` is set explicitly — the exclusion gate wins; * pass `taskList: false` to get TodoWrite back. `todoWrite: false` always drops it. * design/277: the DEFAULT arm (undefined) is model-gated (`modelGate: "task-scaffold"` — trimmed * at prepare for gate-table models); an EXPLICIT `true` mounts unstamped (never gated). */ todoWrite?: boolean; /** * design/119 → CC209 对齐批B B3: the structured task-list family (TaskCreate/TaskGet/TaskUpdate/ * TaskList — stable ids, status transitions, dependencies). Default TRUE (CC 209 alignment: the task * list is on unless explicitly disabled, and TodoWrite is its off-state fallback — the two families * are mutually exclusive, never co-mounted). Only an explicit `taskList: false` reverts to the * TodoWrite shape. * design/277: the DEFAULT arm (undefined) is model-gated (`modelGate: "task-scaffold"`); an * EXPLICIT `true` mounts the family unstamped (never gated). `taskList: false` only selects the * TodoWrite family shape — it is NOT an explicit demand for TodoWrite (see `todoWrite`). */ taskList?: boolean; /** * design/147 §6 D2 (CC 2.1.216 shared team task list): a shared {@link TaskListStore} for the * task-list family. Mount the SAME instance into each teammate's bundle to share one team task * list (the `owner` claim semantics come alive); absent ⇒ the private per-run list (unchanged * default). Ignored when `taskList: false`. This bundle's own Agent children share it by inheritance. */ taskListStore?: TaskListStore; } /** * Single-source bundle of the `code` scenario's `spec.tools`-class tools, so each deployment doesn't re-wire it * (the single-source discipline: a scenario is data — a named bundle). * Profile-as-data — the engine iterates `spec.tools` branch-free; nothing keys off the scenario name. A trusted * assembler (service) calls this, sets `systemPrompt = CODE_SYSTEM_PROMPT` (or `role = CODE_ROLE`) + * `enablePlanMode:true`, and wires the deps seams (executionEnv/onQuestion/lspManager/skillSpecs/memoryStore/ * selfOrchestration) — that is what makes a run the `code` scenario. Returns ONLY the caller-composed tools. */ export declare function assembleCodeTools(cfg?: CodeToolsConfig): ToolSpec[]; /** * RoleSpec preset for the `code` scenario's coding role. Selected via the existing * `spec.systemPrompt ?? resolvedRole.systemPrompt` chain (no new field, no new conditional). `thinking:"high"` is a * sensible floor; the assembler/SDK can raise it (effort→thinking) per request. The global DEFAULT_SYSTEM_PROMPT * stays neutral. */ export declare const CODE_ROLE: RoleSpec;