@jaypie/mcp 0.8.156 → 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.156#2f9f851b"
+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.156",
+  "version": "0.8.157",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

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.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";

package/skills/dynamodb.md

@@ -474,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

@@ -48,6 +48,7 @@ new JaypieMigration(this, "SeedData", {
 - **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`), `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