@sema-agent/core
Version:
Stateless, task-oriented AI agent core
73 lines (72 loc) • 5.33 kB
TypeScript
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;