@jaypie/mcp 0.8.1 → 0.8.3

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.1#19334af2"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.8.3#6f36ab62"
     ;
 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.1",
+  "version": "0.8.3",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/release-notes/express/1.2.17.md

@@ -0,0 +1,12 @@
+---
+version: 1.2.17
+date: 2026-03-26
+summary: Pre-parse request body in LambdaRequest — express.json() no longer required
+---
+
+## Changes
+
+- LambdaRequest now eagerly pre-parses the body in the constructor: JSON bodies are parsed automatically, non-JSON bodies are set as strings
+- Sets `_body` flag so body-parser middleware (express.json()) skips if present, preserving the raw stream for consumers like MCP transport
+- `express.json()` middleware is no longer required for JSON body parsing on Lambda
+- Closes #246

package/release-notes/jaypie/1.2.25.md

@@ -0,0 +1,10 @@
+---
+version: 1.2.25
+date: 2026-03-26
+summary: Bump @jaypie/express to 1.2.17 for automatic body parsing
+---
+
+## Changes
+
+- Updated `@jaypie/express` dependency to ^1.2.17
+- JSON request bodies are now automatically parsed in Lambda handlers without requiring `express.json()` middleware

package/release-notes/logger/1.2.6.md

@@ -0,0 +1,10 @@
+---
+version: 1.2.6
+date: 2026-03-26
+summary: Export getDatadogTransport for clean shutdown in production
+---
+
+## Changes
+
+- Export `getDatadogTransport` from `@jaypie/logger` for production use cases like flushing the transport before `process.exit()` in ECS Fargate containers
+- Closes #248

package/release-notes/mcp/0.8.2.md

@@ -0,0 +1,11 @@
+---
+version: 0.8.2
+date: 2026-03-26
+summary: Updated skills documentation for logs, practice, and new JaypieDatadogForwarder
+---
+
+## Changes
+
+- Updated `logs` skill with Jaypie logging best practices, log.var usage, and level guidance
+- Updated `practice` skill with scrub documentation and style audit workflows
+- Added `JaypieDatadogForwarder` skill documenting the CDK construct for Datadog log forwarding

package/release-notes/testkit/1.2.27.md

@@ -0,0 +1,9 @@
+---
+version: 1.2.27
+date: 2026-03-26
+summary: Add getDatadogTransport mock
+---
+
+## Changes
+
+- Added `getDatadogTransport` mock (returns `null`) matching new `@jaypie/logger` export

package/skills/JaypieDatadogForwarder.md

@@ -0,0 +1,99 @@
+---
+description: JaypieDatadogForwarder CDK construct for deploying and importing the Datadog log forwarder
+related: cdk, datadog, aws
+---
+
+# JaypieDatadogForwarder
+
+CDK construct that wraps Datadog's official CloudFormation forwarder template. Deploys a Lambda that forwards logs to Datadog.
+
+## Import
+
+```typescript
+import { JaypieDatadogForwarder, resolveDatadogForwarderFunction } from "@jaypie/constructs";
+```
+
+## Creating the Forwarder (Provider Stack)
+
+```typescript
+const forwarder = new JaypieDatadogForwarder(this);
+```
+
+Uses environment variables for defaults and automatically exports the Lambda ARN as a CloudFormation output.
+
+### Constructor Signatures
+
+```typescript
+new JaypieDatadogForwarder(scope);
+new JaypieDatadogForwarder(scope, props);
+new JaypieDatadogForwarder(scope, id, props);
+```
+
+### Props
+
+| Parameter | Type | Default | Description |
+|-----------|------|---------|-------------|
+| `id` | string | `"DatadogForwarder"` | Construct ID |
+| `datadogApiKey` | string | `CDK_ENV_DATADOG_API_KEY` | Datadog API key |
+| `account` | string | `CDK_ENV_ACCOUNT` | Account identifier for tags |
+| `reservedConcurrency` | string | `"10"` | Lambda reserved concurrency (must be string) |
+| `additionalTags` | string | undefined | Extra Datadog tags (comma-separated) |
+| `service` | string | `"datadog"` | Service tag value |
+| `project` | string | undefined | Project tag value |
+| `enableCloudFormationEvents` | boolean | `true` | EventBridge rule for CF events |
+| `enableRoleExtension` | boolean | `true` | Extend Datadog IAM role permissions |
+| `createOutput` | boolean | `true` | Export forwarder ARN as CfnOutput |
+| `exportName` | string | `"account-datadog-forwarder"` | Export name for cross-stack reference |
+
+### Resources Created
+
+1. **Nested CloudFormation Stack** — deploys Datadog's official forwarder template
+2. **EventBridge Rule** — forwards CloudFormation events to Datadog (on by default)
+3. **CfnOutput** — exports forwarder Lambda ARN with name `"account-datadog-forwarder"`
+4. **Extended IAM Permissions** — adds `budgets:ViewBudget`, `logs:DescribeLogGroups` to Datadog role (if `CDK_ENV_DATADOG_ROLE_ARN` is set)
+
+### Public Properties
+
+```typescript
+forwarder.cfnStack          // CfnStack — the nested CloudFormation stack
+forwarder.forwarderFunction // IFunction — the Datadog forwarder Lambda
+forwarder.eventsRule        // Rule | undefined — EventBridge rule (if enabled)
+```
+
+## Importing from Another Stack
+
+Use the `resolveDatadogForwarderFunction` helper:
+
+```typescript
+import { resolveDatadogForwarderFunction } from "@jaypie/constructs";
+
+const forwarderFunction = resolveDatadogForwarderFunction(this);
+```
+
+This imports the Lambda via `Fn.importValue("account-datadog-forwarder")` and caches per scope (WeakMap), so multiple calls in the same stack return the same reference.
+
+### For Log Subscription Filters
+
+Use `resolveDatadogLoggingDestination` to get a `LambdaDestination`:
+
+```typescript
+import { resolveDatadogLoggingDestination } from "@jaypie/constructs";
+
+new SubscriptionFilter(this, "DatadogSubscription", {
+  logGroup,
+  destination: resolveDatadogLoggingDestination(this),
+  filterPattern: FilterPattern.allEvents(),
+});
+```
+
+## Environment Variables
+
+| Variable | Purpose |
+|----------|---------|
+| `CDK_ENV_DATADOG_API_KEY` | Default Datadog API key |
+| `CDK_ENV_ACCOUNT` | Default account identifier for tagging |
+| `CDK_ENV_DATADOG_ROLE_ARN` | Optional: Datadog IAM role ARN to extend permissions |
+
+## Tags
+
+All resources tagged with: `role=monitoring`, `service=datadog`, `vendor=datadog`, and optionally `project`.

package/skills/express.md

@@ -128,7 +128,7 @@ The Lambda adapter provides Express-compatible request properties:
 | `req.path` | URL path without query string |
 | `req.query` | Parsed query parameters (with array support) |
 | `req.headers` | Normalized headers (lowercase keys) |
-| `req.body` | Parsed body (via body-parser middleware) |
+| `req.body` | Pre-parsed body (JSON auto-parsed, text as string; no middleware needed) |
 | `req.params` | Route parameters (set by Express router) |
 | `req._lambdaContext` | Original Lambda context |
 | `req._lambdaEvent` | Original Lambda event |

package/skills/logs.md

@@ -9,6 +9,14 @@ Jaypie provides structured logging for observability.
 
 ## Basic Usage
 
+- All logging should use `log` from `jaypie`, custom functions should be eliminated
+- Logging should tell a story as the process unfolds; a non-developer should be able to read and follow
+- `log.trace` the happy path at major checkpoints or junctures where logic forks or errors may be thrown
+- `log.debug` things that should stand out, anything off the happy path that might impact operations later
+- Avoid `log.info`. Reserve info for values that must be recorded such as metrics
+- Use `log.warn` when the problem is unexpected and warrants attention but is recoverable. Use `log.debug` for unusual things that are part of normal operations
+- Use `log.error` when unrecoverable or "really bad." Do not use `log.error` just because an error occurs that is part of normal operations (e.g., 404)
+
 ```typescript
 import { log } from "jaypie";
 
@@ -17,129 +25,51 @@ log.debug("Debug information");
 log.info("Informational message");
 log.warn("Warning message");
 log.error("Error message");
-log.fatal("Fatal error");
+log.fatal("Fatal error"); // only used internally in jaypie
 ```
 
-## Structured Logging
-
-Always include context as the second argument:
+## Logging Data
 
+DO NOT use multiple parameters when logging:
+<BAD>
 ```typescript
-log.info("User logged in", {
-  userId: user.id,
-  email: user.email,
-  method: "oauth",
-});
-
-log.error("Payment failed", {
-  orderId: order.id,
-  amount: order.total,
-  error: error.message,
-});
+log.info("Processing", { id: "my-id" });
 ```
+</BAD>
 
-## Log Levels
-
-| Level | Use For |
-|-------|---------|
-| trace | Very detailed debugging (loops, iterations) |
-| debug | Development debugging |
-| info | Normal operations, business events |
-| warn | Unexpected but handled situations |
-| error | Errors that need attention |
-| fatal | Application cannot continue |
-
-## Setting Log Level
-
-Via environment variable:
-
-```bash
-LOG_LEVEL=debug npm run dev
-LOG_LEVEL=trace npm test
-```
-
-In production, typically `info` or `warn`.
-
-## Request Context
-
-Include request identifiers for tracing:
-
+Use `log.var` to log single-key objects that parse in Datadog:
+<GOOD>
 ```typescript
-log.info("Processing request", {
-  requestId: req.id,
-  path: req.path,
-  userId: req.user?.id,
-});
+log.trace("Processing", { id: "my-id" });
+log.var({ id: "my-id" });
 ```
+</GOOD>
 
-## Error Logging
-
-Log errors with full context:
-
+Or have the variable name tell the story:
+<GOOD>
 ```typescript
-try {
-  await riskyOperation();
-} catch (error) {
-  log.error("Operation failed", {
-    error: error.message,
-    stack: error.stack,
-    input: sanitizedInput,
-  });
-  throw error;
-}
+log.var({ Processing: id });
 ```
+</GOOD>
 
-## Sensitive Data
-
-Never log sensitive data:
-
+Nest multi-key objects under a single key:
 ```typescript
-// BAD
-log.info("User auth", { password: user.password });
-
-// GOOD
-log.info("User auth", { userId: user.id, hasPassword: !!user.password });
+log.var({ Processing: {
+  id,
+  amount,
+  quantity,
+} });
 ```
 
-## Searching Logs
+Log any important, even scalar, data and filter with `var` in Datadog
 
-### Via MCP (Datadog)
-
-```
-# Search by requestId
-datadog_logs --query "@requestId:abc-123"
-
-# Search errors
-datadog_logs --query "status:error" --from "now-1h"
-
-# Search by user
-datadog_logs --query "@userId:user-456"
-```
-
-### Via MCP (CloudWatch)
-
-```
-aws_logs_filter_log_events \
-  --logGroupName "/aws/lambda/my-function" \
-  --filterPattern "ERROR"
-```
-
-## Log Format
+## Setting Log Level
 
-Jaypie logs are JSON-formatted for Datadog:
+Via environment variable:
 
-```json
-{
-  "level": "info",
-  "message": "User logged in",
-  "timestamp": "2024-01-15T10:00:00.000Z",
-  "userId": "user-123",
-  "method": "oauth",
-  "dd": {
-    "trace_id": "abc123",
-    "span_id": "def456"
-  }
-}
+```bash
+LOG_LEVEL=debug npm run dev
+LOG_LEVEL=trace MODULE_LOG_LEVEL=warn npm test
 ```
 
 ## Lambda Logging
@@ -150,17 +80,24 @@ Lambda handlers automatically add context:
 import { lambdaHandler } from "@jaypie/lambda";
 
 export const handler = lambdaHandler(async (event) => {
-  // Logs automatically include:
-  // - requestId
-  // - functionName
-  // - cold_start indicator
-  log.info("Processing", { customField: "value" });
+  log.trace("Begin Processing");
+}, {
+  name: "exampleHandler"
 });
 ```
 
+Logs will include the `env`, `invoke`, and `handler` name. For example:
+
+```json
+{
+  "env": "sandbox",
+  "invoke": "uuid",
+  "handler": "exampleHandler"
+}
+```
+
 ## See Also
 
 - **`skill("datadog")`** - Datadog integration and log forwarding
 - **`skill("handlers")`** - Handler lifecycle with automatic log context
 - **`skill("variables")`** - LOG_LEVEL and other environment variables
-

package/skills/practice.md

@@ -4,7 +4,40 @@ description: Updates to Jaypie code, deploy, documentation, and other practices
 
 # Jaypie Practice
 
-## Workflow Dispatch Actions
+- These are Jaypie practices
+- Confirm any implementation before taking action
+- Do not assume a reference to this skill means to run it all
+
+## GitHub Workflow Dispatch Actions
 
 - Prefer workflow dispatch actions over branch names and tagging
-- Most work is agent-driven so "deploy to production" is more natural
+- Most work is agent-driven so "deploy to production" is more natural
+
+## Logs
+
+- Review ~logs and audit logging in the app
+
+## Scrub
+
+### Scrub Documentation
+
+- Use a subagent to find essential directories that do not contain a CLAUDE.md, if any
+  - Use a subagent to write a CLAUDE.md for each essential directory without one
+  - Parallelize this work except when one essential directory contains another
+  - In that case, complete the descendant CLAUDE first
+  - Whenever possible, offer a terse overview in the root or ancestor CLAUDE and reference the descendant for detail
+- Find CLAUDE.md file not impacted by the above
+  - Use a subagent to update each CLAUDE.md
+  - Also parallelize this work except when dealing with ancestor- descendant chains
+  - Resolve descendants as described
+- Find all README.md
+  - Use a subagent to update each
+  - Optimize both CLAUDE and README for agents
+  - Use terse, direct language
+  - Avoid superlatives, rationalizing the technology, or anything resembling hype/sales
+
+### Scrub Style
+
+- Do not allow imports from subpackages that are exported from `jaypie`
+  - Importing from `@jaypie/express` is not allowed because `jaypie` exports it
+  - Importing from `@jaypie/llm` is allowed because `jaypie` does not export it