@jaypie/mcp 0.8.90 → 0.8.91
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/dist/suites/docs/index.js +1 -1
- package/package.json +1 -1
- package/release-notes/jaypie/1.2.61.md +15 -0
- package/release-notes/llm/1.3.7.md +44 -0
- package/release-notes/logger/1.2.19.md +43 -0
- package/release-notes/mcp/0.8.91.md +13 -0
- package/release-notes/testkit/1.2.51.md +13 -0
- package/skills/llm.md +33 -0
- package/skills/logs.md +33 -0
|
@@ -9,7 +9,7 @@ import { gt } from 'semver';
|
|
|
9
9
|
/**
|
|
10
10
|
* Docs Suite - Documentation services (skill, version, release_notes)
|
|
11
11
|
*/
|
|
12
|
-
const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.
|
|
12
|
+
const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.91#18d21761"
|
|
13
13
|
;
|
|
14
14
|
const __filename$1 = fileURLToPath(import.meta.url);
|
|
15
15
|
const __dirname$1 = path.dirname(__filename$1);
|
package/package.json
CHANGED
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 1.2.61
|
|
3
|
+
date: 2026-07-04
|
|
4
|
+
summary: Pick up @jaypie/logger 1.2.19 (serialization limits) and @jaypie/llm 1.3.7 (quiet operate logging, onProgress)
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- `@jaypie/logger` dependency raised to `^1.2.19` — `log` now caps entries
|
|
10
|
+
at 256KB by default with largest-first attribute truncation, supports
|
|
11
|
+
`maxStringLength`/`maxDepth`, and exposes `log.config()` for runtime
|
|
12
|
+
overrides (issue #410)
|
|
13
|
+
- `@jaypie/llm` optional peer raised to `^1.3.7` — `operate()` logs
|
|
14
|
+
`operate.*` vars at trace with minimal payloads and accepts an
|
|
15
|
+
`onProgress` progress-event callback
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 1.3.7
|
|
3
|
+
date: 2026-07-04
|
|
4
|
+
summary: Quiet operate.* logging to trace with minimal payloads; add onProgress callback for progress events
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
### Logging
|
|
10
|
+
|
|
11
|
+
- All `operate.*` log vars (`operate.input`, `operate.options`,
|
|
12
|
+
`operate.request`, `operate.response`) now emit at **trace** instead of the
|
|
13
|
+
logger's var level (debug by default)
|
|
14
|
+
- `operate.request` and `operate.response` log draconian subsets instead of
|
|
15
|
+
full provider payloads (which re-logged the entire conversation history
|
|
16
|
+
every turn):
|
|
17
|
+
- `operate.request`: `{ model, turn, messages: <count>, latest: <last message text or type> }`
|
|
18
|
+
- `operate.response`: the text content, or the requested tool calls
|
|
19
|
+
(`{ name, arguments }`) when the model calls tools
|
|
20
|
+
- Full provider payloads remain available via the
|
|
21
|
+
`beforeEachModelRequest` / `afterEachModelResponse` hooks and LLM
|
|
22
|
+
Observability spans
|
|
23
|
+
|
|
24
|
+
### Progress Events
|
|
25
|
+
|
|
26
|
+
- New `onProgress` option on `operate()` — a single callback receiving
|
|
27
|
+
lightweight, serializable progress events, suitable for forwarding to
|
|
28
|
+
websockets, queues, or UI updates
|
|
29
|
+
- Event types (`LlmProgressEventType`): `start`, `model_request`,
|
|
30
|
+
`model_response`, `tool_call`, `tool_result`, `tool_error`, `retry`, `done`
|
|
31
|
+
- Event fields: `content`, `error`, `maxTurns`, `model`, `provider`, `tool`,
|
|
32
|
+
`toolCalls`, `turn` (1-indexed), `usage`
|
|
33
|
+
- Errors thrown by the callback are logged at warn and never interrupt the
|
|
34
|
+
loop
|
|
35
|
+
- New exports: `LlmProgressEventType` (enum), `LlmProgressEvent`,
|
|
36
|
+
`LlmProgressCallback`, `LlmProgressToolCall` (types)
|
|
37
|
+
- `stream()` is unchanged — its chunks already communicate progress
|
|
38
|
+
|
|
39
|
+
## Migration
|
|
40
|
+
|
|
41
|
+
No changes required. Consumers who relied on debug-level `operate.request` /
|
|
42
|
+
`operate.response` payload logging should switch to the
|
|
43
|
+
`beforeEachModelRequest` / `afterEachModelResponse` hooks or set
|
|
44
|
+
`LOG_LEVEL=trace` for the summarized vars.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 1.2.19
|
|
3
|
+
date: 2026-07-04
|
|
4
|
+
summary: Serialization limits with rational defaults — maxEntryBytes 256KB on by default, maxStringLength/maxDepth opt-in, log.config() runtime overrides (issue #410)
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- **Entries are capped at 256KB by default** (`maxEntryBytes: 262144`) — the
|
|
10
|
+
CloudWatch Logs event limit that fronts Datadog in Lambda (Datadog's own
|
|
11
|
+
per-log cap is 1MB). Oversized payloads previously flooded the pipeline or
|
|
12
|
+
were cut arbitrarily mid-JSON; now they truncate deliberately (issue #410)
|
|
13
|
+
- Entry truncation degrades gracefully: the top-level attributes of `data`
|
|
14
|
+
are truncated **largest-first**, each preserving a 72-character preview
|
|
15
|
+
plus a visible marker — `data:application/pdf;base64,JVBERi0xLjcK…
|
|
16
|
+
[truncated 612,340 chars]` — until the entry fits. Only if every attribute
|
|
17
|
+
is truncated and the entry is still oversized does `data` collapse to
|
|
18
|
+
`[truncated N bytes]`
|
|
19
|
+
- New opt-in limits:
|
|
20
|
+
- `maxStringLength` — truncate each string field beyond N characters with
|
|
21
|
+
the same marker style
|
|
22
|
+
- `maxDepth` — replace objects/arrays nested beyond N levels with
|
|
23
|
+
`[Object]` / `[Array(n)]` (like `util.inspect`)
|
|
24
|
+
- Configuration, in precedence order:
|
|
25
|
+
1. Constructor options — `new Logger({ maxEntryBytes, maxDepth,
|
|
26
|
+
maxStringLength })` / `createLogger` loggers pass through
|
|
27
|
+
2. `log.config({ maxStringLength: 1024 })` — runtime override, propagates
|
|
28
|
+
to derived loggers (`lib`, `with`, `flag`) and persists across `init()`
|
|
29
|
+
3. Env vars — `LOG_MAX_ENTRY_BYTES`, `LOG_MAX_STRING`, `LOG_MAX_DEPTH`;
|
|
30
|
+
set `0`/`false`/`none`/`off` to disable a limit
|
|
31
|
+
- Pass `false` for any option to disable it (`log.config({ maxEntryBytes:
|
|
32
|
+
false })` restores unlimited entries)
|
|
33
|
+
- Applied at serialization time only — the caller's object is never mutated.
|
|
34
|
+
Circular references are handled (`[Circular]`); class instances (Error,
|
|
35
|
+
Date) are not traversed so their serialization is unchanged
|
|
36
|
+
- New type exports: `SerializationLimitOptions`, `SerializationLimits`
|
|
37
|
+
|
|
38
|
+
## Migration
|
|
39
|
+
|
|
40
|
+
No changes required for typical logging. Entries over 256KB — which were
|
|
41
|
+
already lossy in CloudWatch — now truncate deliberately with visible
|
|
42
|
+
markers. To restore unlimited output, set `LOG_MAX_ENTRY_BYTES=false` or
|
|
43
|
+
call `log.config({ maxEntryBytes: false })`.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 0.8.91
|
|
3
|
+
date: 2026-07-04
|
|
4
|
+
summary: Document operate() progress events (onProgress) in the llm skill and serialization limits in the logs skill
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- `skill("llm")` documents the new `onProgress` progress-event callback on
|
|
10
|
+
`operate()` shipped in `@jaypie/llm@1.3.7`
|
|
11
|
+
- `skill("logs")` documents the serialization limits (`maxEntryBytes` 256KB
|
|
12
|
+
default, `maxStringLength`, `maxDepth`, `log.config()`, `LOG_MAX_*` env
|
|
13
|
+
vars) shipped in `@jaypie/logger@1.2.19`
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
version: 1.2.51
|
|
3
|
+
date: 2026-07-04
|
|
4
|
+
summary: Mirror @jaypie/llm LlmProgressEventType export; mock log.config() from @jaypie/logger
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Changes
|
|
8
|
+
|
|
9
|
+
- `@jaypie/testkit/mock` re-exports `LlmProgressEventType` alongside the
|
|
10
|
+
existing `LlmMessageRole`, `LlmMessageType`, and `LlmStreamChunkType`
|
|
11
|
+
mocks, matching `@jaypie/llm@1.3.7`
|
|
12
|
+
- `mockLogFactory` / `spyLog` mock the new `log.config()` method from
|
|
13
|
+
`@jaypie/logger@1.2.19`
|
package/skills/llm.md
CHANGED
|
@@ -316,6 +316,39 @@ const response = await Llm.operate(input, {
|
|
|
316
316
|
});
|
|
317
317
|
```
|
|
318
318
|
|
|
319
|
+
## Progress Events
|
|
320
|
+
|
|
321
|
+
For progress reporting (UI updates, websockets, queue notifications), prefer `onProgress` over wiring individual hooks. It receives lightweight, serializable events as the loop runs:
|
|
322
|
+
|
|
323
|
+
```typescript
|
|
324
|
+
import { LlmProgressEventType } from "@jaypie/llm";
|
|
325
|
+
|
|
326
|
+
const response = await Llm.operate(input, {
|
|
327
|
+
model: "gpt-5.1",
|
|
328
|
+
tools: toolkit,
|
|
329
|
+
onProgress: (event) => {
|
|
330
|
+
// event.type: start, model_request, model_response,
|
|
331
|
+
// tool_call, tool_result, tool_error, retry, done
|
|
332
|
+
websocket.send(JSON.stringify(event));
|
|
333
|
+
},
|
|
334
|
+
});
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
Fields carried by each event (`turn` is 1-indexed):
|
|
338
|
+
|
|
339
|
+
| Event | Fields |
|
|
340
|
+
|-------|--------|
|
|
341
|
+
| `start` | `model`, `provider`, `maxTurns` |
|
|
342
|
+
| `model_request` | `turn`, `model` |
|
|
343
|
+
| `model_response` | `turn`, `content` (text, if any), `toolCalls` (`[{ name, arguments }]`, if any), `usage` (this turn) |
|
|
344
|
+
| `tool_call` | `turn`, `tool: { name, arguments }` — fires before the tool runs; `arguments` is the JSON string |
|
|
345
|
+
| `tool_result` | `turn`, `tool: { name }` — the result value is deliberately omitted (it can be arbitrarily large); use the `afterEachTool` hook to receive it |
|
|
346
|
+
| `tool_error` | `turn`, `tool: { name }`, `error` (message string) |
|
|
347
|
+
| `retry` | `turn`, `error` (message string) |
|
|
348
|
+
| `done` | `turn` (total turns used), `content` (final text or structured output), `usage` (cumulative) |
|
|
349
|
+
|
|
350
|
+
Errors thrown by the callback are logged and never interrupt the loop. Hooks remain the right choice when you need the full provider request/response payloads. `stream()` communicates progress through its chunks; `onProgress` applies to `operate()`.
|
|
351
|
+
|
|
319
352
|
## Fallback Providers
|
|
320
353
|
|
|
321
354
|
Configure a chain of fallback providers that automatically retry failed calls when the primary provider fails:
|
package/skills/logs.md
CHANGED
|
@@ -110,6 +110,39 @@ const logger = new Logger({ format: "json", level: "debug", levelField: "status"
|
|
|
110
110
|
logger.info("test"); // { "message": "test", "status": "info" }
|
|
111
111
|
```
|
|
112
112
|
|
|
113
|
+
## Serialization Limits
|
|
114
|
+
|
|
115
|
+
Entries are capped at 256KB by default (`maxEntryBytes: 262144` — the CloudWatch Logs event limit that fronts Datadog in Lambda). Oversized entries truncate the top-level attributes of `data` largest-first, each keeping a 72-character preview plus a visible marker:
|
|
116
|
+
|
|
117
|
+
```
|
|
118
|
+
data:application/pdf;base64,JVBERi0xLjcK… [truncated 612,340 chars]
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
Two more limits are available, off by default:
|
|
122
|
+
|
|
123
|
+
- `maxStringLength` — truncate each string field beyond N characters
|
|
124
|
+
- `maxDepth` — replace objects/arrays nested beyond N levels with `[Object]` / `[Array(n)]`
|
|
125
|
+
|
|
126
|
+
Configure via env vars (`0`/`false` disables a limit):
|
|
127
|
+
|
|
128
|
+
```bash
|
|
129
|
+
LOG_MAX_ENTRY_BYTES=1048576 # Raise entry cap to 1MB (Datadog direct)
|
|
130
|
+
LOG_MAX_ENTRY_BYTES=false # Unlimited entries
|
|
131
|
+
LOG_MAX_STRING=16384 # Truncate strings beyond 16KB
|
|
132
|
+
LOG_MAX_DEPTH=8 # Collapse nesting beyond 8 levels
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Or at runtime with `log.config()` — propagates to derived loggers (`lib`, `with`, `flag`) and persists across `init()`:
|
|
136
|
+
|
|
137
|
+
```typescript
|
|
138
|
+
import { log } from "jaypie";
|
|
139
|
+
|
|
140
|
+
log.config({ maxStringLength: 1024 });
|
|
141
|
+
log.config({ maxEntryBytes: false }); // false disables a limit
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
Limits apply at serialization time only — the caller's object is never mutated.
|
|
145
|
+
|
|
113
146
|
## Lambda Logging
|
|
114
147
|
|
|
115
148
|
Lambda handlers automatically add context:
|