@jaypie/mcp 0.8.56 → 0.8.57

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.56#4233ad47"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.57#b4f7b221"
     ;
 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.56",
+  "version": "0.8.57",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/constructs/1.2.54.md

@@ -0,0 +1,19 @@
+---
+version: 1.2.54
+date: 2026-05-10
+summary: JaypieMigration grants control-plane DynamoDB perms scoped to passed tables (issue #339)
+---
+
+## Changes
+
+- `JaypieMigration` now grants control-plane DynamoDB actions (`DescribeContinuousBackups`, `DescribeTable`, `DescribeTimeToLive`, `UpdateContinuousBackups`, `UpdateTable`, `UpdateTimeToLive`) on the ARNs of any tables passed via `tables`, scoped to the table ARN and its indexes (`/index/*`). Data-plane access is unchanged.
+
+## Motivation
+
+The migration Lambda was previously granted only data-plane access via `grantReadWriteData`. Migrations whose entire purpose is to evolve table shape (add a GSI, change TTL, toggle streams, update backups) `AccessDenied` on the first control-plane call. Combined with `lambdaHandler`'s default soft-fail, the deploy reported `CREATE_COMPLETE` while later migrations silently never ran.
+
+Pair this with the new `migrationHandler` in `@jaypie/lambda` (1.2.6) for end-to-end loud-fail behavior.
+
+## Migration
+
+No action required. Existing migrations using only data-plane ops keep working; migrations that previously failed with `AccessDeniedException` on `dynamodb:DescribeTable` or `dynamodb:UpdateTable` should now succeed.

package/release-notes/jaypie/1.2.46.md

@@ -0,0 +1,13 @@
+---
+version: 1.2.46
+date: 2026-05-10
+summary: Re-export migrationHandler from @jaypie/lambda (issue #339)
+---
+
+## Changes
+
+- Re-exports `migrationHandler` from `@jaypie/lambda` 1.2.6.
+
+## Motivation
+
+Migration Lambdas should fail loudly so a failed migration fails the deploy. Use `migrationHandler` instead of `lambdaHandler` in migration entrypoints — see the migrations skill for usage.

package/release-notes/lambda/1.2.6.md

@@ -0,0 +1,27 @@
+---
+version: 1.2.6
+date: 2026-05-10
+summary: Add migrationHandler that defaults throw: true so failed migrations fail the deploy (issue #339)
+---
+
+## Changes
+
+- New `migrationHandler` export. Wraps `lambdaHandler` with `throw: true` defaulted so a thrown error propagates out of the Lambda, causing the CFN custom resource (and the deploy) to fail loudly instead of swallowing the error and reporting `CREATE_COMPLETE`.
+- Re-exported by `jaypie` and mocked by `@jaypie/testkit/mock`.
+- Pass `{ throw: false }` to opt back into the soft-fail behavior.
+
+## Motivation
+
+`JaypieMigration` runs its Lambda via a CFN custom resource provider. With `lambdaHandler`'s default `throw: false`, a thrown migration error was caught, logged as `fatal`, and returned as a successful response — CFN saw a 200-shaped response and marked the resource `CREATE_COMPLETE`. The deploy turned green while later migrations silently never ran.
+
+## Migration
+
+Update migration entry points from `lambdaHandler` to `migrationHandler`:
+
+```typescript
+import { migrationHandler } from "jaypie";
+
+export const handler = migrationHandler(async (event) => {
+  // migration logic
+});
+```

package/release-notes/mcp/0.8.57.md

@@ -0,0 +1,9 @@
+---
+version: 0.8.57
+date: 2026-05-10
+summary: Migrations skill recommends migrationHandler and documents control-plane perms (issue #339)
+---
+
+## Changes
+
+- `skill("migrations")` now recommends `migrationHandler` for the Lambda entrypoint and documents the control-plane DynamoDB permissions added by `JaypieMigration` 1.2.54.

package/release-notes/testkit/1.2.37.md

@@ -0,0 +1,9 @@
+---
+version: 1.2.37
+date: 2026-05-10
+summary: Mock migrationHandler from @jaypie/lambda (issue #339)
+---
+
+## Changes
+
+- Adds `migrationHandler` mock that mirrors the real handler — defaults `throw: true` so thrown errors surface in tests.

package/skills/migrations.md

@@ -44,16 +44,18 @@ new JaypieMigration(this, "SeedData", {
 - **Role**: Tagged as `CDK.ROLE.PROCESSING`
 - **Execution**: Runs on every deploy via CloudFormation custom resource (uses a deploy nonce to force re-invocation even when only Lambda code changes)
 - **Dependencies**: Use `dependencies` to ensure tables and other resources exist before the migration executes
+- **Permissions**: Tables passed via `tables` get data-plane (`grantReadWriteData`) plus control-plane access (`DescribeTable`, `UpdateTable`, `UpdateTimeToLive`, `UpdateContinuousBackups`) scoped to the table ARN and its indexes — migrations that add GSIs, toggle TTL, or change backups work without extra IAM
 
 ## Migration Lambda Handler
 
-The migration Lambda receives a CloudFormation custom resource event. Return a result to signal success; throw to signal failure and roll back the stack.
+The migration Lambda receives a CloudFormation custom resource event. Use `migrationHandler` so a thrown error fails the CFN custom resource (and the deploy) — `lambdaHandler`'s default `throw: false` returns a success-shaped response on error and CFN reports `CREATE_COMPLETE` even when the migration failed.
 
 ```typescript
 // src/migrations/seed/index.ts
 import { initClient, seedEntities, APEX } from "@jaypie/dynamodb";
+import { migrationHandler } from "jaypie";
 
-export const handler = async (event: any) => {
+export const handler = migrationHandler(async (event) => {
   await initClient();
 
   await seedEntities([
@@ -62,9 +64,11 @@ export const handler = async (event: any) => {
   ]);
 
   return { status: "complete" };
-};
+});
 ```
 
+`migrationHandler` is `lambdaHandler` with `throw: true` defaulted. Pass `{ throw: false }` to opt back into soft-fail behavior.
+
 ## Building Migration Code
 
 Bundle migrations separately using esbuild, then reference the output directory: