@niscorp/signal 0.1.1 → 0.1.3
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 +41 -0
- package/DOCS.md +7 -3
- package/dist/index.cjs +5 -4
- package/dist/index.cjs.map +1 -1
- package/dist/index.js +5 -4
- package/dist/index.js.map +1 -1
- package/package.json +3 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,46 @@
|
|
|
1
1
|
# @niscorp/signal
|
|
2
2
|
|
|
3
|
+
## 0.1.3
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- 63445cb: `complete()` and `stream()` on a decision provider say their own name.
|
|
8
|
+
|
|
9
|
+
Both run through `stepStream`, and the refusal a decision provider gives a chat verb named that instead: `signal.complete('…')` failed with `stepStream() is not available on a decision provider…` and `context.verb: "stepStream"`, for a call the caller never made.
|
|
10
|
+
|
|
11
|
+
The error now names the verb that was called — `complete() is not available on a decision provider — it answers decide() and generates no text`, `context.verb: "complete"`, and the same for `stream`. `step`, `stepStream` and `embed` already named themselves.
|
|
12
|
+
|
|
13
|
+
Only those two strings change. The code is `E_VERB_NOT_SUPPORTED` as before, it is raised at the same moment (for `stream()`, when the stream is first read), and no request is sent.
|
|
14
|
+
|
|
15
|
+
**What to change:** nothing.
|
|
16
|
+
|
|
17
|
+
- 8973c15: DOCS.md says what `embed()` and `meta.provider.raw` do. `embed()` does not check `supportsEmbedding`: the flag is what `describe()` reports, and the request is sent either way; a refused request is `E_PROVIDER_ERROR` with the provider's own error under `context.raw`. `meta.provider.raw` is `null` after `complete()` and `stream()`, which read the reply as a stream and keep no body (`step()` returns the body), and it is the provider's error for a call Signal recovered from a rejection. No code changed.
|
|
18
|
+
|
|
19
|
+
**What to change:** nothing.
|
|
20
|
+
|
|
21
|
+
- ce21cf7: DOCS.md says what a tool's `input` schema may be. The model is sent its JSON Schema, taken from the schema's output side, and the arguments are parsed with it once. So an `input` schema validates and does not convert:
|
|
22
|
+
- One with no JSON Schema (a `.transform()`, a `z.date()`) rejects the call before any request is made, with Zod's own error rather than a `SignalError`.
|
|
23
|
+
- One whose output is another kind than its input (`z.stringbool()`) is described to the model by its output: told `boolean`, a model that sends one gets `input_invalid` back, and it is the string that is accepted.
|
|
24
|
+
|
|
25
|
+
Convert inside `execute`. DOCS.md says this under "Defining Tools", and a test holds the first. No code changed.
|
|
26
|
+
|
|
27
|
+
**What to change:** nothing.
|
|
28
|
+
|
|
29
|
+
## 0.1.2
|
|
30
|
+
|
|
31
|
+
### Patch Changes
|
|
32
|
+
|
|
33
|
+
- fe30458: Every package exports its `package.json`, so an app can say which version of a package it runs by reading it from the package:
|
|
34
|
+
|
|
35
|
+
```ts
|
|
36
|
+
import prism from '@niscorp/prism/package.json' with { type: 'json' };
|
|
37
|
+
prism.version; // the version that is installed, not the range that asked for it
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Until now the `exports` map hid it, and the only way to the version was a path into `node_modules`. `check:packages` installs the tarballs and reads every package's version this way.
|
|
41
|
+
|
|
42
|
+
**What to change:** nothing. An app that read a version by path can read it by name.
|
|
43
|
+
|
|
3
44
|
## 0.1.1
|
|
4
45
|
|
|
5
46
|
### Patch Changes
|
package/DOCS.md
CHANGED
|
@@ -254,12 +254,14 @@ type SignalMeta = {
|
|
|
254
254
|
retries: number; // validation retries that occurred
|
|
255
255
|
toolCalls: ToolCallRecord[]; // tools called, args, results, timing
|
|
256
256
|
provider: {
|
|
257
|
-
raw: unknown; //
|
|
257
|
+
raw: unknown; // null: these calls read the reply as a stream, which leaves no body to keep (an array, one entry per call, when the run took several)
|
|
258
258
|
errors: ProviderError[]; // currently always empty
|
|
259
259
|
};
|
|
260
260
|
};
|
|
261
261
|
```
|
|
262
262
|
|
|
263
|
+
`step()` returns the provider's response body as its `raw`. Where a provider rejected a call and Signal recovered the attempt from the rejection, that call's `raw` is the provider's error.
|
|
264
|
+
|
|
263
265
|
---
|
|
264
266
|
|
|
265
267
|
## Structured Output
|
|
@@ -318,6 +320,8 @@ const searchTool = defineTool({
|
|
|
318
320
|
|
|
319
321
|
The Zod `input` schema validates the model's arguments before `execute` runs. The return value is stringified and sent back to the model. A call to an unknown tool, arguments that fail the schema, and an `execute` that throws do not fail the run: each goes back to the model as an `error: …` tool result (and is recorded in `meta.toolCalls`).
|
|
320
322
|
|
|
323
|
+
The model is sent the `input` schema as JSON Schema, taken from the schema's output side, so an `input` schema validates and does not convert. One with no JSON Schema (a `.transform()`, a `z.date()`) rejects the call before any request is made, with Zod's own error (`Transforms cannot be represented in JSON Schema`) rather than a `SignalError`. One whose output is another kind than its input (`z.stringbool()`) is described to the model by its output: told `boolean`, a model that sends one gets `input_invalid` back, and it is the string (`"true"`) that is accepted. Convert inside `execute`.
|
|
324
|
+
|
|
321
325
|
### Using Tools
|
|
322
326
|
|
|
323
327
|
```typescript
|
|
@@ -420,7 +424,7 @@ const similarity = cosine(a, b);
|
|
|
420
424
|
|
|
421
425
|
### Provider Support
|
|
422
426
|
|
|
423
|
-
|
|
427
|
+
`embed()` does not check `supportsEmbedding`: the flag is what `describe()` reports, and the request goes to the provider's embeddings endpoint either way. Of the known providers only **OpenAI** is marked as having one (`text-embedding-3-small`, `text-embedding-3-large`). An endpoint that refuses the request surfaces as `E_PROVIDER_ERROR` (`Embedding error: …`, the provider's own error under `context.raw`). A decision provider and the two adapters that are not implemented fail before any request is made.
|
|
424
428
|
|
|
425
429
|
Use a separate Signal client for embedding — embedding models are different from chat models:
|
|
426
430
|
|
|
@@ -521,7 +525,7 @@ All errors are `SignalError` instances with a `.code` and optional `.context`:
|
|
|
521
525
|
| `E_MISSING_SDK` | Provider SDK not installed |
|
|
522
526
|
| `E_VALIDATION_FAILED` | Response failed Zod validation after all retries; a `decide()` answer failed its gate; a `reasoningEffort` the model does not take |
|
|
523
527
|
| `E_MAX_ITERATIONS` | The tool loop did not finish within its turn limit |
|
|
524
|
-
| `E_PROVIDER_ERROR` | Provider API error (rate limit, server error, etc.); tools
|
|
528
|
+
| `E_PROVIDER_ERROR` | Provider API error (rate limit, server error, a refused `embed()`, etc.); tools on a provider without `nativeTools`; an adapter that is not implemented |
|
|
525
529
|
| `E_MAX_RETRIES`, `E_TOOL_NOT_FOUND`, `E_TOOL_EXECUTION`, `E_TOOL_VALIDATION` | Declared in `ErrorCode`, not currently thrown — tool failures go back to the model as tool results, and exhausted retries are `E_VALIDATION_FAILED` |
|
|
526
530
|
| `E_VERB_NOT_SUPPORTED` | A chat verb was called on a decision provider |
|
|
527
531
|
|
package/dist/index.cjs
CHANGED
|
@@ -1502,9 +1502,9 @@ var createSignalFromConfig = (config) => {
|
|
|
1502
1502
|
});
|
|
1503
1503
|
return { ...result, outcome: routed.outcome, wire: routed.wire };
|
|
1504
1504
|
};
|
|
1505
|
-
const
|
|
1505
|
+
const stepStreamAs = (verb) => (request, streamOptions) => {
|
|
1506
1506
|
const run = async function* () {
|
|
1507
|
-
const adapter = await getChatAdapter(
|
|
1507
|
+
const adapter = await getChatAdapter(verb);
|
|
1508
1508
|
const resolved = resolveProvider(config);
|
|
1509
1509
|
const declared = new Set((request.tools ?? []).map((tool) => tool.name));
|
|
1510
1510
|
const merged = config.options !== void 0 || request.options !== void 0 ? { ...request, options: { ...config.options, ...request.options } } : request;
|
|
@@ -1544,6 +1544,7 @@ var createSignalFromConfig = (config) => {
|
|
|
1544
1544
|
};
|
|
1545
1545
|
return run();
|
|
1546
1546
|
};
|
|
1547
|
+
const stepStream = stepStreamAs("stepStream");
|
|
1547
1548
|
const decideCalibrated = async (adapter, model, request, started) => {
|
|
1548
1549
|
const response = await adapter.decide(
|
|
1549
1550
|
{ model, state: request.state, questions: request.questions },
|
|
@@ -1631,7 +1632,7 @@ var createSignalFromConfig = (config) => {
|
|
|
1631
1632
|
onRetry: config.onRetry,
|
|
1632
1633
|
onToolCall: config.onToolCall
|
|
1633
1634
|
},
|
|
1634
|
-
{ stepStream, model: resolveProvider(config).model, capabilities: resolveCapabilities(config) }
|
|
1635
|
+
{ stepStream: stepStreamAs("complete"), model: resolveProvider(config).model, capabilities: resolveCapabilities(config) }
|
|
1635
1636
|
),
|
|
1636
1637
|
stream: (input, streamOptions) => runStream(
|
|
1637
1638
|
{
|
|
@@ -1644,7 +1645,7 @@ var createSignalFromConfig = (config) => {
|
|
|
1644
1645
|
onRetry: config.onRetry,
|
|
1645
1646
|
onToolCall: config.onToolCall
|
|
1646
1647
|
},
|
|
1647
|
-
{ stepStream, model: resolveProvider(config).model, capabilities: resolveCapabilities(config) }
|
|
1648
|
+
{ stepStream: stepStreamAs("stream"), model: resolveProvider(config).model, capabilities: resolveCapabilities(config) }
|
|
1648
1649
|
),
|
|
1649
1650
|
// ─── Low-level primitives — the execution core itself ────
|
|
1650
1651
|
step,
|