@jaypie/mcp 0.8.74 → 0.8.75

package/dist/suites/docs/index.js

@@ -9,7 +9,7 @@ import { gt } from 'semver';
 /**
  * Docs Suite - Documentation services (skill, version, release_notes)
  */
-const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.74#b9619bfe"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.75#7dfeb98d"
     ;
 const __filename$1 = fileURLToPath(import.meta.url);
 const __dirname$1 = path.dirname(__filename$1);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaypie/mcp",
-  "version": "0.8.74",
+  "version": "0.8.75",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/constructs/1.2.65.md

@@ -0,0 +1,14 @@
+---
+version: 1.2.65
+date: 2026-06-18
+summary: Stabilize JaypieEnvSecret cross-stack export name across both call forms
+---
+
+## Changes
+
+- `JaypieEnvSecret` now always derives its CloudFormation cross-stack export name from the construct id, for both the shorthand and explicit `(id, { envKey })` call forms.
+- Previously the explicit form derived the export name from `envKey`, silently renaming the export across a version bump and breaking existing `Fn::ImportValue` consumers (e.g. `env-sandbox-agents-AgentsInternalKey` became `env-sandbox-agents-AGENTSINTERNALKEY`).
+
+## Migration
+
+No changes required. Unchanged explicit-form call sites now keep their original id-based export name, restoring compatibility with previously published exports (issues #347, #365).

package/release-notes/llm/1.3.1.md

@@ -0,0 +1,13 @@
+---
+version: 1.3.1
+date: 2026-06-18
+summary: Version step to 1.3.1 to avoid conflict with an accidental 1.3.0
+---
+
+## Changes
+
+- No functional changes. Version advances directly from `1.2.41` to `1.3.1` to step over an accidental `1.3.0` and prevent ongoing version conflicts.
+
+## Migration
+
+No changes required.

package/release-notes/mcp/0.8.75.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.75
+date: 2026-06-18
+summary: Document JaypieMigration in the cdk skill
+---
+
+## Changes
+
+- `cdk` skill: add a Database Migrations section covering `JaypieMigration` and link to `skill("migrations")`.
+
+## Migration
+
+No changes required.

package/skills/cdk.md

@@ -237,6 +237,27 @@ new JaypieLambda(this, "Handler", {
 
 See `skill("dynamodb")` for table key conventions and query patterns.
 
+## Database Migrations
+
+`JaypieMigration` runs DynamoDB migrations as a CloudFormation custom resource on every `cdk deploy`. It wraps a `JaypieLambda` in a `cr.Provider` and re-fires on the deploy nonce, so newly added migrations run on code-only deploys instead of being skipped:
+
+```typescript
+import { JaypieDynamoDb, JaypieMigration } from "@jaypie/constructs";
+
+const table = new JaypieDynamoDb(this, "myApp");
+
+new JaypieMigration(this, "SeedData", {
+  code: "dist/migrations/seed",
+  handler: "index.handler",
+  tables: [table],
+  dependencies: [table], // Ensures the table exists first
+});
+```
+
+Use `migrationHandler` from `jaypie` in the migration Lambda so errors propagate as CloudFormation failures. Prefer this construct over a hand-rolled `cr.Provider` + `cdk.CustomResource`, which is easy to key on the table name alone and thereby skip the deploy-nonce re-fire.
+
+See `skill("migrations")` for the full props table, behavior, and handler pattern.
+
 ## Lambda with Secrets
 
 Pass secrets as strings (auto-creates `JaypieEnvSecret`) or as construct instances:
@@ -390,6 +411,7 @@ new JaypieOrganizationTrail(this, "OrgTrail", {
 - **`skill("dynamodb")`** - DynamoDB key design and query patterns
 - **`skill("express")`** - Express handler and Lambda adapter
 - **`skill("lambda")`** - Lambda handler wrappers and lifecycle
+- **`skill("migrations")`** - JaypieMigration DynamoDB migration custom resources
 - **`skill("secrets")`** - Secret management with JaypieEnvSecret
 - **`skill("streaming")`** - JaypieDistribution and JaypieNextJs streaming configuration
 - **`skill("variables")`** - Environment variables reference