@jaypie/mcp 0.8.155 → 0.8.157

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.157#937cc1b9"
     ;
 // =============================================================================
 // ASSET PATHS

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaypie/mcp",
-  "version": "0.8.155",
+  "version": "0.8.157",
   "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/constructs/1.2.85.md

@@ -0,0 +1,22 @@
+---
+version: 1.2.85
+date: 2026-09-13
+summary: Per-build tags skip DynamoDB tables so migration-owned indexes survive redeploys
+---
+
+## Changes
+
+- **`constructTagger`** adds `buildDate`, `buildHex`, `buildTime`, `commit`, and
+  `version` with `excludeResourceTypes` for `AWS::DynamoDB::GlobalTable` and
+  `AWS::DynamoDB::Table`. These tags changed every synth, forcing a table update
+  on every deploy. A table whose GSIs a migration created rejects that update
+  with `Invalid AttributeDefinitions`, so every deploy after the first rolled
+  back (#548).
+- **`JaypieInfrastructureStack`** applies the same exclusion to `stackSha`.
+
+## Upgrade
+
+Tables deployed with earlier versions carry the build tags. The first deploy on
+this version removes them, which is a table update. A table with no
+migration-owned indexes updates normally. A table with migration-owned indexes
+fails that update: recreate the table or declare its indexes in CDK.

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/release-notes/mcp/0.8.157.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.157
+date: 2026-09-13
+summary: Document that tables with migration-owned indexes need stable CloudFormation properties
+---
+
+## Changes
+
+- **`dynamodb`** adds "Keep Table Properties Stable": any CloudFormation update
+  to a table fails once a migration creates a GSI.
+- **`migrations`** notes migration-owned index behavior and recovery for stacks
+  deployed before `@jaypie/constructs` 1.2.85.
+- **`cdk`** notes that per-build tags skip DynamoDB tables (#548).

package/skills/cdk.md

@@ -131,7 +131,7 @@ workspaces/
    `cdk-{PROJECT_SPONSOR}-{PROJECT_KEY}-{PROJECT_ENV}-{PROJECT_NONCE}[-{key}]`,
    so naming stays consistent across sandbox, personal, and production deploys.
 2. **Account & region** resolved from `CDK_DEFAULT_ACCOUNT` / `CDK_DEFAULT_REGION` (overridable via `env`).
-3. **Standard tags** applied to the stack and propagated to every taggable child resource: `env`, `project`, `sponsor`, `nonce`, `commit`, `buildHex`, `buildDate`, `buildTime`, `version`, `service`, `creation`, `role`, `stack`.
+3. **Standard tags** applied to the stack and propagated to every taggable child resource: `env`, `project`, `sponsor`, `nonce`, `commit`, `buildHex`, `buildDate`, `buildTime`, `version`, `service`, `creation`, `role`, `stack`. Per-build tags (`buildDate`, `buildHex`, `buildTime`, `commit`, `version`, and `JaypieInfrastructureStack`'s `stackSha`) skip `AWS::DynamoDB::GlobalTable` and `AWS::DynamoDB::Table` so tables stay unchanged across deploys (see `skill("migrations")`).
 
 ```typescript
 import { Construct } from "constructs";
@@ -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 |
@@ -472,6 +474,16 @@ const table = new JaypieDynamoDb(this, "myApp", {
 
 Wire tables to Lambda using the `tables` prop — see `skill("cdk")` for details.
 
+### Keep Table Properties Stable
+
+Once a migration creates a GSI through `UpdateTable`, every CloudFormation update to the table fails:
+
+```
+Invalid AttributeDefinitions Expected the following attributes to be present: [indexModel, ...]
+```
+
+CloudFormation sends only the key attributes the template declares, and DynamoDB rejects a request that omits attributes existing indexes reference. Table properties, tags included, must stay the same across deploys. Jaypie keeps per-build tags (`buildDate`, `buildHex`, `buildTime`, `commit`, `version`, `stackSha`) off `AWS::DynamoDB::GlobalTable` and `AWS::DynamoDB::Table` for this reason. Change a migration-owned table through migrations, or declare its indexes in CDK.
+
 ## Local Development
 
 Use docker-compose for local DynamoDB. The `@jaypie/dynamodb` MCP tool can generate a `docker-compose.yml` with custom ports.

package/skills/migrations.md

@@ -47,7 +47,8 @@ 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-owned indexes**: after a migration creates a GSI, any CloudFormation update to the table fails with `Invalid AttributeDefinitions`. Keep table props and tags stable across deploys; per-build tags already skip tables (see `skill("dynamodb")`). Stacks deployed before `@jaypie/constructs` 1.2.85 carry build tags on the table, and removing them is itself a failing table update: recover by recreating the table or declaring its indexes in CDK
 
 ## Migration Lambda Handler