@jaypie/mcp 0.8.60 → 0.8.61

package/README.md

@@ -1,61 +1,9 @@
-# Jaypie MCP
+# Jaypie MCP 🐦‍⬛
 
-MCP (Model Context Protocol) server for Jaypie development. Provides tools for AI agents to access Jaypie documentation, development guides, Datadog observability data, and AWS CLI operations.
+Model Context Protocol server for Jaypie.
 
-## Usage
+See [jaypie.net](https://jaypie.net) for documentation.
 
-```bash
-npx jaypie-mcp          # Run MCP server via stdio
-npx jaypie-mcp --verbose # Run with debug logging
-```
+## 📜 License
 
-## Environment Variables
-
-### AWS CLI Integration
-| Variable | Description |
-|----------|-------------|
-| `AWS_PROFILE` | Default profile if not specified per-call |
-| `AWS_REGION` or `AWS_DEFAULT_REGION` | Default region if not specified |
-
-AWS tools use the host's existing credential chain:
-- `~/.aws/credentials` and `~/.aws/config` files
-- Environment variables (`AWS_ACCESS_KEY_ID`, etc.)
-- SSO sessions established via `aws sso login`
-
-### Datadog Integration
-| Variable | Description |
-|----------|-------------|
-| `DATADOG_API_KEY` or `DD_API_KEY` | Datadog API key |
-| `DATADOG_APP_KEY` or `DD_APP_KEY` | Datadog Application key |
-| `DD_ENV` | Default environment filter |
-| `DD_QUERY` | Default query terms appended to searches |
-
-## MCP Tools
-
-### Documentation Tools
-- `skill` - Access Jaypie development documentation by alias
-- `version` - Returns package version string
-- `list_release_notes` - List available release notes
-- `read_release_note` - Read specific release note content
-
-### AWS CLI Tools (16 tools)
-- Step Functions: `aws_stepfunctions_list_executions`, `aws_stepfunctions_stop_execution`
-- Lambda: `aws_lambda_list_functions`, `aws_lambda_get_function`
-- CloudWatch Logs: `aws_logs_filter_log_events`
-- S3: `aws_s3_list_objects`
-- CloudFormation: `aws_cloudformation_describe_stack`
-- DynamoDB: `aws_dynamodb_describe_table`, `aws_dynamodb_scan`, `aws_dynamodb_query`, `aws_dynamodb_get_item`
-- SQS: `aws_sqs_list_queues`, `aws_sqs_get_queue_attributes`, `aws_sqs_receive_message`, `aws_sqs_purge_queue`
-- Profiles: `aws_list_profiles`
-
-### Datadog Tools (6 tools)
-- `datadog_logs`, `datadog_log_analytics`, `datadog_monitors`, `datadog_synthetics`, `datadog_metrics`, `datadog_rum`
-
-### LLM Tools (2 tools)
-- `llm_debug_call`, `llm_list_providers`
-
-See [CLAUDE.md](./CLAUDE.md) for detailed documentation.
-
-## License
-
-[MIT License](./LICENSE.txt). Published by Finlayson Studio
+[MIT License](./LICENSE.txt). Published by Finlayson Studio.

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.60#21fed95d"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.61#9515fd89"
     ;
 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.60",
+  "version": "0.8.61",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/constructs/1.2.58.md

@@ -0,0 +1,11 @@
+---
+version: 1.2.58
+date: 2026-05-18
+summary: Add bedrock:*, bedrock-agent:*, and bedrock-agentcore:* to Developer SSO permission set
+---
+
+## @jaypie/constructs 1.2.58
+
+### Features
+
+- **JaypieSsoPermissions**: Added `bedrock:*`, `bedrock-agent:*`, and `bedrock-agentcore:*` to the Developer permission set inline policy

package/release-notes/dynamodb/0.6.2.md

@@ -0,0 +1,32 @@
+---
+version: 0.6.2
+date: 2026-05-29
+summary: Add schema-agnostic scanTable/countTable and createTable/destroyTable to support table-rebuild migrations
+---
+
+## New
+
+Table-rebuild primitives. The 0.5.0 primary-key change cannot be migrated in
+place, so moving from 0.4.x requires copying records into a new table. These
+exports provide the verbs; the per-record transform stays application-specific.
+
+- **`scanTable({ tableName?, pageSize? })`**: async generator yielding every
+  raw item via a schema-agnostic `Scan`, paginating internally. Unlike the
+  query functions it does not depend on the GSI shape, so it reads an old
+  (0.4.x) table whose indexes no longer match the registered models. Pass an
+  explicit `tableName` to read a table other than the initialized one.
+- **`countTable({ tableName? })`**: total item count via a paginated `COUNT`
+  scan -- compare source and destination before destroying the old table.
+- **`createTable({ tableName?, billingMode?, wait? })`**: create a table with
+  the registered-model GSI schema, honoring the `initClient` config (real AWS
+  or local). Waits until the table is `ACTIVE` by default.
+- **`destroyTable({ tableName })`**: delete a table. `tableName` is required
+  with no default -- deleting is destructive and must be intentional.
+- **`getClient()`**: the raw `DynamoDBClient` (control-plane), alongside the
+  existing `getDocClient()` (data-plane).
+
+## Docs
+
+- New "Rebuilding a table (0.4 → 0.6)" guide documenting the CDK-managed,
+  maintenance-window cutover: deploy new table → scan/transform/write →
+  validate counts → flip `DYNAMODB_TABLE_NAME` → destroy old table later.

package/release-notes/jaypie/1.2.48.md

@@ -0,0 +1,13 @@
+---
+version: 1.2.48
+date: 2026-05-11
+summary: pick up @jaypie/lambda 1.2.8 fix for migrationHandler waiter loop (#350)
+---
+
+## Changes
+
+- Updated `@jaypie/lambda` dependency to `^1.2.8`.
+
+## Details
+
+See `@jaypie/lambda` 1.2.8 release notes. Consumers of `jaypie` now automatically pick up the `migrationHandler` discriminator fix that prevented `JaypieMigration` deploys from completing.

package/release-notes/kit/1.2.9.md

@@ -0,0 +1,9 @@
+---
+version: 1.2.9
+date: 2026-05-26
+summary: Add X-Webhook-Signature HTTP header constant
+---
+
+## Changes
+
+- Added `HTTP.HEADER.WEBHOOK_SIGNATURE` (`"X-Webhook-Signature"`) to the HTTP header constants

package/release-notes/lambda/1.2.8.md

@@ -0,0 +1,17 @@
+---
+version: 1.2.8
+date: 2026-05-11
+summary: fix migrationHandler discriminator — onEventHandler now returns Data marker so isComplete polls route correctly (#350)
+---
+
+## Changes
+
+- `migrationHandler`'s `onEventHandler` branch now returns `Data: { __migration: true }` alongside `PhysicalResourceId`.
+
+## Motivation
+
+`cr.Provider` only propagates `Data` into `isComplete` events when `onEvent` returned a `Data` field. The previous implementation returned `{ PhysicalResourceId }` with no `Data`, so every `isComplete` poll also had no `Data`, causing the `"Data" in cfnEvent` discriminator to always take the `onEventHandler` short-circuit branch. The waiter loop never received `IsComplete: true` and ran until `totalTimeout` (default 2 h), then failed the stack.
+
+## Migration
+
+No changes required. Consumers using `@jaypie/constructs@^1.2.56` and `@jaypie/lambda@^1.2.8` together will have working `JaypieMigration` deploys.

package/release-notes/llm/1.2.37.md

@@ -0,0 +1,12 @@
+---
+version: 1.2.37
+date: 2026-05-29
+summary: Update Anthropic LARGE model constant to claude-opus-4-8
+---
+
+## @jaypie/llm 1.2.37
+
+### Changes
+
+- **Model constants**: Updated Anthropic `LARGE` to `claude-opus-4-8`
+- **Tests/CI**: Refreshed the Anthropic, OpenAI, and xAI model matrices to current releases

package/release-notes/mcp/0.8.61.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.61
+date: 2026-05-29
+summary: Document @jaypie/dynamodb table-rebuild primitives and the table-rebuild migration pattern
+---
+
+## Changes
+
+- `skill("dynamodb")`: document `getClient`, `scanTable`, `countTable`,
+  `createTable`, and `destroyTable`, plus a "Rebuilding a table" section
+  covering the one-off, validated cutover from a 0.4.x table to the 0.5.0+
+  schema (distinct from the deploy-time `JaypieMigration` in
+  `skill("migrations")`).

package/release-notes/testkit/1.2.39.md

@@ -0,0 +1,11 @@
+---
+version: 1.2.39
+date: 2026-05-29
+summary: Mock the new @jaypie/dynamodb table-rebuild exports
+---
+
+## Changes
+
+- Add mocks for `@jaypie/dynamodb` 0.6.2 exports: `getClient`, `scanTable`
+  (empty async generator), `countTable` (resolves `0`), `createTable`
+  (resolves a success result), and `destroyTable`.

package/skills/dynamodb.md

@@ -68,11 +68,23 @@ initClient({
 | Function | Description |
 |----------|-------------|
 | `initClient(config?)` | Initialize the DynamoDB client (call once) |
+| `getClient()` | Get the raw client for control-plane ops (CreateTable/DeleteTable) |
 | `getDocClient()` | Get the initialized Document Client |
 | `getTableName()` | Get the configured table name |
 | `isInitialized()` | Check if client is initialized |
 | `resetClient()` | Reset client state (for testing) |
 
+### Scan and Table Administration
+
+Schema-agnostic table operations that honor the `initClient` config (real AWS or local). These are the building blocks for table rebuilds.
+
+| Function | Description |
+|----------|-------------|
+| `scanTable({ tableName?, pageSize? })` | Async generator yielding every raw item via a full `Scan` (paginates internally). Reads any table regardless of GSI shape -- pass the old table during a rebuild. |
+| `countTable({ tableName? })` | Total item count via paginated `COUNT` scan (validation) |
+| `createTable({ tableName?, billingMode?, wait? })` | Create a table with the registered-model GSI schema; waits until `ACTIVE` by default |
+| `destroyTable({ tableName })` | Delete a table; `tableName` required (no default) |
+
 ### Constants
 
 | Constant | Value | Description |
@@ -439,6 +451,30 @@ Version 0.5.0 is a breaking change. **Tables must be recreated** (pre-1.0 breaki
 | `DEFAULT_INDEXES` implicit fallback | Must `registerModel()` with `fabricIndex()` before querying |
 | Callers set `createdAt`/`updatedAt` | `indexEntity` manages both automatically |
 
+### Rebuilding a table
+
+The 0.5.0 primary-key change cannot be applied in place (DynamoDB cannot alter a primary key). The migration is a one-off, human-in-the-loop cutover to a new physical table, validated before destroying the old one. Run it once per environment, not as a deploy step. (Distinct from `JaypieMigration` in `skill("migrations")`, which runs CDK custom resources on every deploy.)
+
+Cutover (CDK-managed table name, maintenance window):
+
+1. Deploy the new table alongside the old (CDK).
+2. Pause writes so the copy can't go stale.
+3. Run a script: `scanTable({ tableName: OLD })` → transform → `updateEntity` (writes to the new table = the `initClient` singleton).
+4. Validate: `countTable(NEW)` matches `countTable(OLD)`; spot-check records.
+5. Flip `DYNAMODB_TABLE_NAME` (via `CDK_ENV`) to the new table and deploy; resume.
+6. `destroyTable({ tableName: OLD })` later, once confident (it is your rollback until then).
+
+```ts
+initClient({ tableName: NEW });        // singleton → destination
+await createTable({ tableName: NEW }); // new schema, waits ACTIVE
+for await (const item of scanTable({ tableName: OLD })) {
+  const { sequence, pk, sk, ...rest } = item;   // 0.4 → 0.6 transform
+  await updateEntity({ entity: rest });          // re-indexes + re-timestamps
+}
+```
+
+`scanTable` issues a raw `Scan`, so it reads the old table despite its mismatched GSIs; the transform is yours (field semantics are app-specific).
+
 ## See Also
 
 - **`skill("apikey")`** - API key hash storage in DynamoDB