@jaypie/mcp 0.8.155 → 0.8.156

package/dist/suites/docs/index.js

@@ -13,7 +13,7 @@ import { RELEASE_NOTES_HELP } from './help.js';
 /**
  * Docs Suite - Documentation services (skill, version, release_notes)
  */
-const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.155#dee71f8c"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.156#2f9f851b"
     ;
 // =============================================================================
 // ASSET PATHS

package/package.json

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

package/release-notes/constructs/1.2.84.md

@@ -0,0 +1,19 @@
+---
+version: 1.2.84
+date: 2026-09-13
+summary: JaypieLambda and JaypieMigration grant Query and Scan on table indexes CDK does not declare
+---
+
+## Changes
+
+- **`JaypieLambda` `tables`** grants `dynamodb:Query` and `dynamodb:Scan` on
+  `${tableArn}/index/*` for every table. CDK adds index ARNs only for indexes
+  declared in CDK, so a Lambda could not query a GSI created by a migration or
+  owned by an imported table (#546).
+- **`JaypieMigration`** inherits the grant, so a migration can query an index an
+  earlier migration created in the same deploy.
+
+## Upgrade
+
+Remove workarounds that add `dynamodb:Query` or `dynamodb:Scan` on
+`${tableArn}/index/*` to a `JaypieLambda` or `JaypieMigration` role.

package/release-notes/mcp/0.8.156.md

@@ -0,0 +1,11 @@
+---
+version: 0.8.156
+date: 2026-09-13
+summary: Skills document index Query and Scan grants for tables passed to JaypieLambda and JaypieMigration
+---
+
+## Changes
+
+- **`cdk`, `dynamodb`, and `migrations` skills** document that tables passed
+  via `tables` get `Query` and `Scan` on `${tableArn}/index/*`, covering
+  indexes created by migrations that CDK never declares (#546).

package/skills/cdk.md

@@ -232,8 +232,10 @@ const handler = new JaypieLambda(this, "ApiHandler", {
 
 | Tables Count | Permissions | Environment |
 |-------------|-------------|-------------|
-| 1 table | `grantReadWriteData()` | `DYNAMODB_TABLE_NAME` set automatically |
-| 2+ tables | `grantReadWriteData()` for each | No auto env var — set `CDK_ENV_TABLE` manually |
+| 1 table | `grantReadWriteData()` plus `Query`/`Scan` on `index/*` | `DYNAMODB_TABLE_NAME` set automatically |
+| 2+ tables | `grantReadWriteData()` plus `Query`/`Scan` on `index/*` for each | No auto env var — set `CDK_ENV_TABLE` manually |
+
+CDK grants index ARNs only for indexes declared in CDK. The explicit `index/*` grant covers GSIs created by migrations (`UpdateTable`) and indexes on imported tables.
 
 Single table example — at runtime, use `process.env.DYNAMODB_TABLE_NAME`:
 

package/skills/dynamodb.md

@@ -272,6 +272,8 @@ GSIs are defined using `fabricIndex()` from `@jaypie/fabric`. **Do not create al
 
 **Important:** DynamoDB allows only **one GSI to be added per deployment**. If you need multiple GSIs, add them sequentially across separate deploys. For production tables, the AWS CLI is often better suited for adding GSIs than CDK (which may try to replace the table).
 
+**Grants:** CDK adds `${tableArn}/index/*` to grants only for indexes declared in CDK. GSIs created by migrations or the CLI are invisible to CDK, so a role needs `Query` and `Scan` on the index ARN explicitly. `JaypieLambda` and `JaypieMigration` grant this for every table in `tables`; hand-rolled roles must add it.
+
 All GSIs use a composite sort key of `scope#updatedAt` (stored as `{indexName}Sk`). Queries use `begins_with` on the sk to filter by scope; omitting scope lists across all scopes.
 
 | GSI Name | Partition Key Pattern | Sort Key | Purpose | Add When |

package/skills/migrations.md

@@ -47,7 +47,7 @@ new JaypieMigration(this, "SeedData", {
 - **Role**: Tagged as `CDK.ROLE.PROCESSING`
 - **Execution**: Uses `cr.Provider` with both `onEventHandler` and `isCompleteHandler` pointing to the same Lambda. The `onEventHandler` returns `PhysicalResourceId` immediately; the migration code runs in `isCompleteHandler` invocations, which are polled by Step Functions until `IsComplete: true`. `Delete` requests skip the migration entirely.
 - **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
+- **Permissions**: Tables passed via `tables` get data-plane (`grantReadWriteData`), `Query` and `Scan` on `${tableArn}/index/*`, 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, and later migrations can query the GSIs earlier ones created
 
 ## Migration Lambda Handler