mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-19 23:01:25 +02:00
1cd559ca34
Migrates the background tick from buildPlannerPrompt + PlannerClient +
parsePlannerResponse to the shared runPlannerLoop with native function
calling. Structurally identical to the webapp runner (commit 5a) —
same catalog, same compact system prompt, same multi-turn chat.
Server-specific twist: the ``onToolCall`` callback is a no-op stub
(returns {success:true, message:'recorded — pending client
application'}). The server has no Dexie access, so it can't actually
execute writes; instead it captures the LLM's chosen tool_calls and
writes them as PlanStep entries on the iteration. The user's client
picks up those planned steps on sync — same shape as before, just
sourced from the LLM's native tool_calls instead of a regex-extracted
JSON block.
Scope trimmed by the SERVER_TOOLS filter: only propose-default (write)
tools go to the server planner. Read-only tools (list_*, get_*) are
hidden because stubbing a response would let the LLM hallucinate that
it saw real data. Read-then-act chains stay with the foreground
runner, which has a real executor.
Deleted: planner/client.ts (old PlannerClient; replaced by
planner/llm-client.ts). Drift guard in tools.ts collapses into a
SERVER_TOOLS = AI_TOOL_CATALOG.filter(propose) derivation — no more
hand-maintained duplicate list; the contract test now asserts the
inverse round-trip against AI_PROPOSABLE_TOOL_SET.
TODO (follow-up): token usage tracking is temporarily set to 0 because
runPlannerLoop doesn't expose per-message usage yet. Budget
enforcement on the server is effectively disabled until the loop
returns that data — the webapp runner is unaffected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
23 lines
995 B
TypeScript
23 lines
995 B
TypeScript
/**
|
|
* Server-side tool surface — derived from the shared AI_TOOL_CATALOG.
|
|
*
|
|
* The server offers only `propose`-default (write) tools to the planner.
|
|
* Read-only tools (`list_*`, `get_*`) are intentionally hidden because
|
|
* the server cannot execute them — it has no Dexie access, and stubbing
|
|
* a "recorded" response back would let the LLM hallucinate that it saw
|
|
* real data and plan against it. The foreground runner, which DOES
|
|
* execute reads, handles read-then-act chains.
|
|
*
|
|
* Each server-produced iteration captures the LLM's planned write-tool
|
|
* calls as PlanStep entries. The user's client applies them on sync.
|
|
*/
|
|
|
|
import { AI_TOOL_CATALOG } from '@mana/shared-ai';
|
|
import type { ToolSchema } from '@mana/shared-ai';
|
|
|
|
/** Write-tools the server planner may reference. */
|
|
export const SERVER_TOOLS: readonly ToolSchema[] = AI_TOOL_CATALOG.filter(
|
|
(t) => t.defaultPolicy === 'propose'
|
|
);
|
|
|
|
export const SERVER_TOOL_NAMES = new Set<string>(SERVER_TOOLS.map((t) => t.name));
|