@jaypie/mcp 0.8.74 → 0.8.76

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.74#b9619bfe"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.76#d4ee8b15"
     ;
 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.74",
+  "version": "0.8.76",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/constructs/1.2.65.md

@@ -0,0 +1,14 @@
+---
+version: 1.2.65
+date: 2026-06-18
+summary: Stabilize JaypieEnvSecret cross-stack export name across both call forms
+---
+
+## Changes
+
+- `JaypieEnvSecret` now always derives its CloudFormation cross-stack export name from the construct id, for both the shorthand and explicit `(id, { envKey })` call forms.
+- Previously the explicit form derived the export name from `envKey`, silently renaming the export across a version bump and breaking existing `Fn::ImportValue` consumers (e.g. `env-sandbox-agents-AgentsInternalKey` became `env-sandbox-agents-AGENTSINTERNALKEY`).
+
+## Migration
+
+No changes required. Unchanged explicit-form call sites now keep their original id-based export name, restoring compatibility with previously published exports (issues #347, #365).

package/release-notes/constructs/1.2.66.md

@@ -0,0 +1,18 @@
+---
+version: 1.2.66
+date: 2026-06-20
+summary: Forward DD_VERSION to the Lambda environment for Datadog version tagging
+---
+
+## Changes
+
+- `jaypieLambdaEnv` now passes `DD_VERSION` through to the Lambda environment
+  when present in `process.env`, alongside the other allowlisted vars. This lets
+  projects tag telemetry with a version derived independently of
+  `PROJECT_VERSION` (e.g. from the latest git tag), which `dd-trace` reads at
+  runtime.
+- `addDatadogLayers` now falls back the `DatadogLambda` `version` to
+  `process.env.DD_VERSION || process.env.PROJECT_VERSION`, keeping the version
+  tag consistent with the env var.
+
+Issue: [#384](https://github.com/finlaysonstudio/jaypie/issues/384)

package/release-notes/llm/1.3.1.md

@@ -0,0 +1,13 @@
+---
+version: 1.3.1
+date: 2026-06-18
+summary: Version step to 1.3.1 to avoid conflict with an accidental 1.3.0
+---
+
+## Changes
+
+- No functional changes. Version advances directly from `1.2.41` to `1.3.1` to step over an accidental `1.3.0` and prevent ongoing version conflicts.
+
+## Migration
+
+No changes required.

package/release-notes/mcp/0.8.75.md

@@ -0,0 +1,13 @@
+---
+version: 0.8.75
+date: 2026-06-18
+summary: Document JaypieMigration in the cdk skill
+---
+
+## Changes
+
+- `cdk` skill: add a Database Migrations section covering `JaypieMigration` and link to `skill("migrations")`.
+
+## Migration
+
+No changes required.

package/release-notes/mcp/0.8.76.md

@@ -0,0 +1,15 @@
+---
+version: 0.8.76
+date: 2026-06-20
+summary: Correct the mocks skill to document the real @jaypie/testkit/mock pattern
+---
+
+## Changes
+
+- Rewrote the `mocks` skill, which documented a non-existent
+  `mockJaypie(vi)` / `mockLogger(vi)` / `mockAws(vi)` API. The working pattern
+  is `vi.mock("jaypie", async () => await import("@jaypie/testkit/mock"))`,
+  returning the flat mock namespace directly. Sub-package and export-verification
+  examples updated to match.
+
+Issue: [#385](https://github.com/finlaysonstudio/jaypie/issues/385)

package/release-notes/testkit/1.2.45.md

@@ -0,0 +1,17 @@
+---
+version: 1.2.45
+date: 2026-06-20
+summary: Drop the deprecated mongoose mock that broke @jaypie/testkit/mock at load time
+---
+
+## Removed
+
+- **Mongoose mock dropped from the `./mock` umbrella.** `@jaypie/testkit/mock`
+  statically imported `@jaypie/mongoose` (a deprecated, undeclared phantom
+  dependency), which threw `Cannot find package '@jaypie/mongoose'` at module
+  load in any project without mongoose installed. The mock is removed entirely;
+  `jaypie` never re-exported mongoose. The `connect`, `connectFromSecretEnv`,
+  `disconnect`, and `mongoose` exports are no longer available from
+  `@jaypie/testkit/mock`.
+
+Issue: [#385](https://github.com/finlaysonstudio/jaypie/issues/385)

package/skills/cdk.md

@@ -237,6 +237,27 @@ new JaypieLambda(this, "Handler", {
 
 See `skill("dynamodb")` for table key conventions and query patterns.
 
+## Database Migrations
+
+`JaypieMigration` runs DynamoDB migrations as a CloudFormation custom resource on every `cdk deploy`. It wraps a `JaypieLambda` in a `cr.Provider` and re-fires on the deploy nonce, so newly added migrations run on code-only deploys instead of being skipped:
+
+```typescript
+import { JaypieDynamoDb, JaypieMigration } from "@jaypie/constructs";
+
+const table = new JaypieDynamoDb(this, "myApp");
+
+new JaypieMigration(this, "SeedData", {
+  code: "dist/migrations/seed",
+  handler: "index.handler",
+  tables: [table],
+  dependencies: [table], // Ensures the table exists first
+});
+```
+
+Use `migrationHandler` from `jaypie` in the migration Lambda so errors propagate as CloudFormation failures. Prefer this construct over a hand-rolled `cr.Provider` + `cdk.CustomResource`, which is easy to key on the table name alone and thereby skip the deploy-nonce re-fire.
+
+See `skill("migrations")` for the full props table, behavior, and handler pattern.
+
 ## Lambda with Secrets
 
 Pass secrets as strings (auto-creates `JaypieEnvSecret`) or as construct instances:
@@ -390,6 +411,7 @@ new JaypieOrganizationTrail(this, "OrgTrail", {
 - **`skill("dynamodb")`** - DynamoDB key design and query patterns
 - **`skill("express")`** - Express handler and Lambda adapter
 - **`skill("lambda")`** - Lambda handler wrappers and lifecycle
+- **`skill("migrations")`** - JaypieMigration DynamoDB migration custom resources
 - **`skill("secrets")`** - Secret management with JaypieEnvSecret
 - **`skill("streaming")`** - JaypieDistribution and JaypieNextJs streaming configuration
 - **`skill("variables")`** - Environment variables reference

package/skills/mocks.md

@@ -22,11 +22,14 @@ In your test setup file:
 import { vi } from "vitest";
 
 vi.mock("jaypie", async () => {
-  const { mockJaypie } = await import("@jaypie/testkit");
-  return mockJaypie(vi);
+  const testkit = await import("@jaypie/testkit/mock");
+  return testkit;
 });
 ```
 
+`@jaypie/testkit/mock` re-exports a vitest mock for every `jaypie` export as a
+flat namespace, so returning it directly mocks the whole package.
+
 Configure in vitest.config.ts:
 
 ```typescript
@@ -43,35 +46,25 @@ export default defineConfig({
 
 ```typescript
 vi.mock("jaypie", async () => {
-  const { mockJaypie } = await import("@jaypie/testkit");
-  return mockJaypie(vi);
+  const testkit = await import("@jaypie/testkit/mock");
+  return testkit;
 });
 
 // Mocked: log, getSecret, sendMessage, etc.
 ```
 
-### Logger
-
-```typescript
-vi.mock("@jaypie/logger", async () => {
-  const { mockLogger } = await import("@jaypie/testkit");
-  return mockLogger(vi);
-});
-```
+### Sub-Packages
 
-### AWS
+To mock an individual `@jaypie/*` package, return the relevant mocks from the
+same flat `@jaypie/testkit/mock` namespace:
 
 ```typescript
-vi.mock("@jaypie/aws", async () => {
-  const { mockAws } = await import("@jaypie/testkit");
-  return mockAws(vi);
+vi.mock("@jaypie/express", async () => {
+  const testkit = await import("@jaypie/testkit/mock");
+  return { expressHandler: testkit.expressHandler };
 });
 ```
 
-### Legacy Mocks
-
-For legacy packages, see `skill("legacy")`.
-
 ## Using Mocks in Tests
 
 ### Verify Logging
@@ -158,20 +151,20 @@ afterEach(() => {
 
 ## Export Verification
 
-When adding exports to packages, update testkit:
+When adding exports to a Jaypie package, add a matching mock to testkit so the
+auto-mock stays complete:
 
 ```typescript
-// packages/testkit/src/mocks/mockJaypie.ts
-export function mockJaypie(vi) {
-  return {
-    log: mockLog(vi),
-    getSecret: vi.fn().mockResolvedValue("mock"),
-    // Add new exports here
-    newFunction: vi.fn(),
-  };
-}
+// packages/testkit/src/mock/<package>.ts
+import { createMockFunction } from "./utils";
+
+export const newFunction = createMockFunction((x) => x);
 ```
 
+Then re-export it from `src/mock/index.ts` (named export and default object) and
+bump the testkit patch version. Missing mocks surface as failures in testkit's
+`mock/__tests__/index.spec.ts` "all exports from original" check.
+
 ## See Also
 
 - **`skill("errors")`** - Error types used in mock assertions