@chatpanel/events 0.69.0 → 0.69.1

package/find-tool.js

@@ -34,11 +34,18 @@ export const FIND_DESCRIPTION =
 // meeting history" — while `find` was sitting in its toolset. The old line named the tool
 // and left the capability to be inferred, and inference is what small models are worst at.
 export const FIND_RESIDENT =
-  "You HAVE access to the user's own ChatPanel data — their past chats, notes, and "
-  + 'meeting transcripts and summaries — through the `find` tool, plus the web. When the '
-  + 'question is about past meetings, notes, people, decisions, or anything the user '
-  + 'discussed or wrote, call `find` FIRST and answer from what it returns. Never tell '
-  + 'the user you cannot access their meetings, notes or history: you can.';
+  "You HAVE access to the user's own ChatPanel data — past chats, notes, meeting "
+  + 'transcripts and summaries — through `find`, plus the web. For anything they discussed or '
+  + 'wrote, call `find` FIRST and answer from it; never say you cannot access their meetings, '
+  + 'notes or history. '
+  // Named here, resident, because a relayed agent with a web search of its own otherwise
+  // reaches for that: the desktop asked Codex about the weather, Codex searched on its own,
+  // read pages that were scripts and no temperature, and answered that it could not tell.
+  // The `weather` action answers in one request. And a `find` call is shown to the user as
+  // a step — an agent's own search is not. The whole block stays under the extension's
+  // 120-token resident cap (test-data-dispatch.mjs): the manual travels with `describe`.
+  + 'For anything current — weather, prices, news — use `find` (actions `weather`, '
+  + '`web_search`), not a search tool of your own; the user sees `find` calls as steps.';
 
 /**
  * Wrap the real search/read tools (history, web search, weather…) as the one `find` tool.

package/index.js

@@ -283,3 +283,4 @@ export { McpClient, mcpProvider } from './mcp-client.js';
 export { mcpSharedSystem, mcpInventorySystem, sourceCitationSystem, combineSystemPrompt, toolStatus, widgetAuthoringSystem, vaultWidgetSystem, wantsVaultGuidance } from './tool-hints.js';
 export { adaptiveToolRetryHint, createAdaptiveToolPolicy, isInvalidToolParametersResult } from './adaptive-tool-policy.js';
 export { getMcpProviders, testMcpServer, resetMcp } from './mcp-manager.js';
+export { WEATHER_TOOL_NAME, WEATHER_TOOL_SYSTEM, weatherToolProvider } from './weather-tool.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chatpanel/events",
-  "version": "0.69.0",
+  "version": "0.69.1",
   "description": "The canonical ChatPanel event-log and capability contracts \u2014 typed durable facts, clock-free deterministic linearization, schema upcasting, and the invariants the replay harness asserts. Pure, dependency-free ESM shared by the ChatPanel extension, gateway and bridge.",
   "type": "module",
   "main": "index.js",
@@ -105,7 +105,8 @@
     "./tool-hints.js": "./tool-hints.js",
     "./adaptive-tool-policy.js": "./adaptive-tool-policy.js",
     "./mcp-client.js": "./mcp-client.js",
-    "./mcp-manager.js": "./mcp-manager.js"
+    "./mcp-manager.js": "./mcp-manager.js",
+    "./weather-tool.js": "./weather-tool.js"
   },
   "files": [
     "LICENSE",
@@ -203,6 +204,7 @@
     "vault.js",
     "view.js",
     "voice-intents.js",
+    "weather-tool.js",
     "weather.js",
     "web-search-tool.js",
     "web-search.js",

package/weather-tool.js

@@ -0,0 +1,65 @@
+// `weather` as a TOOL — the spec, the guidance, and the answer shape, without the fetch.
+//
+// The extension answers "how is the weather in X" with this rather than with a web search,
+// because weather sites are rendered by scripts and a fetched page is navigation and no
+// temperature — which is exactly what a desktop turn without this tool produced: "I couldn't
+// retrieve reliable live weather". The engine (`weather.js`: the wttr.in query, the parse,
+// the ambiguity check) is already shared; this is the tool every client arms in front of it.
+//
+// `fetchJson(url, { timeoutMs })` is injected: each host owns its network guard and applies
+// it to a URL a MODEL supplied — attacker-influenced by construction.
+
+import { getWeather } from './weather.js';
+
+export const WEATHER_TOOL_NAME = 'weather';
+
+export const WEATHER_TOOL_SYSTEM =
+  'For weather, call `weather` FIRST — it answers the whole question in one request. Only '
+  + 'fall back to web_search if it tells you to. Report the location it says it resolved, '
+  + 'because a bare town name can geocode to the wrong place.';
+
+export function weatherToolProvider({ fetchJson } = {}) {
+  if (typeof fetchJson !== 'function') throw new Error('weatherToolProvider: fetchJson required');
+  return {
+    specs: [
+      {
+        name: 'weather',
+        // A read, declared: the round runner overlaps reads and serialises everything it
+        // cannot classify, and "weather" is not a verb its name heuristic knows.
+        annotations: { readOnlyHint: true, idempotentHint: true, openWorldHint: true },
+        description:
+          'Current conditions and a short forecast for one place, in a single request. Use this '
+          + 'for any weather question instead of searching. Returns the location it actually '
+          + 'resolved to — say which place the answer is for.',
+        parameters: {
+          type: 'object',
+          properties: {
+            location: {
+              type: 'string',
+              description: 'A place, as the user said it. Add a state or country only if THEY did '
+                + '— "Fairview, OR" if they said so, plain "Fairview" if they did not.',
+            },
+          },
+          required: ['location'],
+          additionalProperties: false,
+        },
+      },
+    ],
+    system: WEATHER_TOOL_SYSTEM,
+    async execute(name, input) {
+      if (name !== 'weather') return JSON.stringify({ error: `Unknown tool: ${name}` });
+      const location = String(input?.location || '').trim();
+      if (!location) return 'No location provided to weather.';
+      const got = await getWeather(location, { fetchJson });
+      // THE FALLBACK IS AN INSTRUCTION, not an error string. A model handed "weather failed"
+      // stops, or apologises; a model told which tool answers this next just uses it. The
+      // whole point of preferring one source is that it must degrade to the general one.
+      if (!got.ok) {
+        return `The weather service could not answer for "${location}" (${got.reason}). `
+          + `Now call web_search for "weather in ${location}" and answer from the results — `
+          + 'do not tell the user a tool failed.';
+      }
+      return { text: got.text, note: 'ChatPanel · wttr.in' };
+    },
+  };
+}