@jaypie/mcp 0.8.21 → 0.8.23

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.
@@ -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.21#a7fd63df"
12
+ const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.23#3db47ebf"
13
13
  ;
14
14
  const __filename$1 = fileURLToPath(import.meta.url);
15
15
  const __dirname$1 = path.dirname(__filename$1);
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jaypie/mcp",
3
- "version": "0.8.21",
3
+ "version": "0.8.23",
4
4
  "description": "Jaypie MCP",
5
5
  "repository": {
6
6
  "type": "git",
@@ -39,7 +39,7 @@
39
39
  "typecheck": "tsc --noEmit"
40
40
  },
41
41
  "dependencies": {
42
- "@jaypie/fabric": "^0.2.2",
42
+ "@jaypie/fabric": "^0.2.4",
43
43
  "@jaypie/tildeskill": "^0.2.0",
44
44
  "@modelcontextprotocol/sdk": "^1.17.0",
45
45
  "commander": "^14.0.0",
@@ -0,0 +1,20 @@
1
+ ---
2
+ version: 0.4.4
3
+ date: 2026-04-10
4
+ summary: Pick up @jaypie/fabric@0.2.4 — query() once again falls back to DEFAULT_INDEXES for unregistered models
5
+ ---
6
+
7
+ # @jaypie/dynamodb 0.4.4
8
+
9
+ ## Changes
10
+
11
+ - Picks up `@jaypie/fabric@0.2.4`, restoring the deprecated `DEFAULT_INDEXES` fallback inside `getModelIndexes()`
12
+ - `query({ model, scope })` against an unregistered model no longer throws `ConfigurationError`; it auto-detects `indexScope` from the restored `DEFAULT_INDEXES`
13
+
14
+ ## Why
15
+
16
+ The 0.4.3 behavior surfaced as `ValidationException`/`ConfigurationError` against tables that previously worked, breaking deployed services. The fallback is restored as a deprecated behavior; both the dynamodb fallback and the underlying `@jaypie/fabric` `DEFAULT_INDEXES` export are slated for removal alongside `@jaypie/fabric@0.3.0`.
17
+
18
+ ## Migration
19
+
20
+ Register model indexes explicitly with `registerModel({ model, indexes })` to be ready for the upcoming removal.
@@ -0,0 +1,11 @@
1
+ ---
2
+ version: 1.2.20
3
+ date: 2026-04-09
4
+ summary: Integrate log session management in express handlers
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `expressHandler` and `expressStreamHandler` now call `log.setup()` / `log.teardown()` for session lifecycle
10
+ - Request status and normalized path are reported via `log.report()` for inclusion in the teardown report
11
+ - Replaced manual `log.tag()` calls with `log.setup(tags)` for invoke/handler tags
@@ -0,0 +1,20 @@
1
+ ---
2
+ version: 0.2.4
3
+ date: 2026-04-10
4
+ summary: Restore DEFAULT_INDEXES export and getModelIndexes fallback removed in 0.2.3; both are deprecated and slated for removal in 0.3.0
5
+ ---
6
+
7
+ # @jaypie/fabric 0.2.4
8
+
9
+ ## Restored
10
+
11
+ - `DEFAULT_INDEXES` export from `@jaypie/fabric` and `@jaypie/fabric/index` (removed in 0.2.3 via the same PR that added default security headers to `JaypieDistribution`)
12
+ - `getModelIndexes(model)` once again falls back to `DEFAULT_INDEXES` when a model has not been registered, restoring previous DynamoDB GSI behavior for unregistered models
13
+
14
+ ## Why
15
+
16
+ The 0.2.3 removal was a breaking change that left downstream consumers without a way to populate GSI keys for unregistered models, surfacing as `ValidationException` errors against tables that previously worked.
17
+
18
+ ## Deprecation
19
+
20
+ Both `DEFAULT_INDEXES` and the implicit fallback inside `getModelIndexes()` are marked `@deprecated`. They are scheduled for removal in 0.3.0. Register model indexes explicitly with `registerModel({ model, indexes })`.
@@ -0,0 +1,10 @@
1
+ ---
2
+ version: 1.2.5
3
+ date: 2026-04-09
4
+ summary: Integrate log session management in lambda handlers
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `lambdaHandler` and `lambdaStreamHandler` now call `log.setup()` / `log.teardown()` for session lifecycle
10
+ - Replaced manual `log.tag()` calls with `log.setup(tags)` for invoke/handler tags
@@ -0,0 +1,13 @@
1
+ ---
2
+ version: 1.2.13
3
+ date: 2026-04-09
4
+ summary: Add log session management with setup(), teardown(), and report()
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - `log.setup(tags?)` starts a logging session, applies tags, resets counters
10
+ - `log.teardown()` emits accumulated report as `log.info.var({ report })` with auto-tracked `{ log: { warn, warns, error, errors } }`
11
+ - `log.report({ key: value })` accumulates per-request data; warns on duplicate keys
12
+ - Warn and error calls (including `.var()`) are auto-counted during active sessions
13
+ - `init()` resets session state
@@ -0,0 +1,9 @@
1
+ ---
2
+ version: 1.2.28
3
+ date: 2026-04-09
4
+ summary: Add setup, teardown, report to log mock
5
+ ---
6
+
7
+ ## Changes
8
+
9
+ - Added `setup`, `teardown`, `report` to `mockLogFactory()`, mock types, and `spyLog`/`restoreLog`
package/skills/logs.md CHANGED
@@ -63,6 +63,23 @@ log.var({ Processing: {
63
63
 
64
64
  Log any important, even scalar, data and filter with `var` in Datadog
65
65
 
66
+ ## Session Management
67
+
68
+ Handlers automatically call `log.setup()` and `log.teardown()` to bookend each request. On teardown, a report is emitted as `log.info.var({ report })` containing accumulated data and warn/error counts.
69
+
70
+ ```typescript
71
+ // Manual session (handlers do this automatically)
72
+ log.setup({ handler: "myHandler", invoke: "abc-123" });
73
+
74
+ // Accumulate report data during the request
75
+ log.report({ userId: "456" });
76
+ log.report({ itemCount: 3 });
77
+
78
+ // Teardown emits the report with warn/error stats
79
+ log.teardown();
80
+ // => { report: { userId: "456", itemCount: 3, log: { warn: false, warns: 0, error: false, errors: 0 } } }
81
+ ```
82
+
66
83
  ## Setting Log Level
67
84
 
68
85
  Via environment variable: