@theokit/sdk 5.2.0 → 5.2.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,39 @@
1
1
  # Changelog
2
2
 
3
+ ## 5.2.1
4
+
5
+ ### Patch Changes
6
+
7
+ - [#594](https://github.com/usetheokit/theokit-sdk/pull/594) [`9dc8cf5`](https://github.com/usetheokit/theokit-sdk/commit/9dc8cf52bee690bfb9cf55bee63bcda71d3132b3) Thanks [@usetheodev](https://github.com/usetheodev)! - `effectiveToolNames` refuses a created tool instead of answering confidently about it ([#583](https://github.com/usetheokit/theokit-sdk/issues/583) follow-up)
8
+
9
+ Every field on `AgentOptions` is optional, so the `CustomTool` that `SubAgent.create()` returns —
10
+ `{ name, description, inputSchema, handler }` — satisfies the type **by vacuity, with no cast**.
11
+ Measured: a `@ts-expect-error` on that call is reported unused (`TS2578`), so the compiler genuinely
12
+ does not refuse it.
13
+
14
+ What came back was worse than a wrong number:
15
+
16
+ ```ts
17
+ effectiveToolNames(SubAgent.create({ name: "analyst", … }))
18
+ // { names: ["shell"], unresolved: [] }
19
+ ```
20
+
21
+ The empty `unresolved` claims **completeness** about an object the function never understood. A
22
+ caller reads that as *"this subagent still announces a shell"* and either disbelieves a fix that
23
+ worked, or "fixes" something on the strength of it. That is the defect [#583](https://github.com/usetheokit/theokit-sdk/issues/583) exists to eliminate, one
24
+ function further on — and the same argument that made this return `{ names, unresolved }` rather than
25
+ a bare array forbids it.
26
+
27
+ It now throws a `ConfigurationError` naming what to pass instead. The detection is exact rather than
28
+ heuristic: `AgentOptions` declares neither `handler` nor `inputSchema`, so an object carrying **both**
29
+ is a tool and not options.
30
+
31
+ **The workaround is still needed, and the 5.2.0 notes should not have implied otherwise.**
32
+ `SubAgent.create()` closes its spec inside the handler, so the spec cannot be recovered from the
33
+ returned tool — keep it in a variable, or extract it into a function a test can call, and pass that.
34
+
35
+ Reported by the `theocode` session, against advice of mine that was wrong.
36
+
3
37
  ## 5.2.0
4
38
 
5
39
  ### Minor Changes
package/dist/index.cjs CHANGED
@@ -919,8 +919,17 @@ var NoopMemoryProvider = class {
919
919
  var ALWAYS_REGISTERED = ["shell"];
920
920
  var MEMORY_BUILTINS = ["memory_search", "memory_get"];
921
921
  function effectiveToolNames(options) {
922
+ refuseCreatedTool(options);
922
923
  return { names: resolvableNames(options), unresolved: unresolvableSources(options) };
923
924
  }
925
+ function refuseCreatedTool(options) {
926
+ const candidate = options;
927
+ if (candidate.handler === void 0 || candidate.inputSchema === void 0) return;
928
+ throw new chunkJ7J7J2GN_cjs.ConfigurationError(
929
+ `effectiveToolNames received a created tool${typeof candidate.name === "string" ? ` ("${candidate.name}")` : ""}, not AgentOptions. \`SubAgent.create()\` returns a CustomTool and closes its spec inside the handler, so the spec cannot be recovered from it. Pass the spec you built it from \u2014 keep it in a variable, or extract it into a function the test can call.`,
930
+ { code: "effective_tools_expected_options" }
931
+ );
932
+ }
924
933
  function resolvableNames(options) {
925
934
  const withheld = new Set(options.withheldBuiltinTools ?? []);
926
935
  const builtins = [