@jaypie/mcp 0.2.5 → 0.2.6

package/dist/index.js

@@ -885,7 +885,7 @@ function listLlmProviders() {
     };
 }
 
-const BUILD_VERSION_STRING = "@jaypie/mcp@0.2.5#b58bafc3"
+const BUILD_VERSION_STRING = "@jaypie/mcp@0.2.6#e43f0153"
     ;
 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.2.5",
+  "version": "0.2.6",
   "description": "Jaypie MCP",
   "repository": {
     "type": "git",

package/prompts/Jaypie_CDK_Constructs_and_Patterns.md

@@ -291,6 +291,76 @@ Common usage:
 - `resolveHostedZone(scope, { zone })`: Gets IHostedZone from string or object
 - `extendDatadogRole(lambda)`: Adds Datadog IAM permissions when CDK_ENV_DATADOG_ROLE_ARN set
 
+### DynamoDB Tables
+
+Use `JaypieDynamoDb` for single-table design with Jaypie GSI patterns:
+```typescript
+// Shorthand: tableName becomes "myApp", construct id is "JaypieDynamoDb-myApp"
+const table = new JaypieDynamoDb(this, "myApp");
+
+// No GSIs
+const table = new JaypieDynamoDb(this, "MyTable", {
+  globalSecondaryIndexes: false,
+});
+
+// Use only specific GSIs
+const table = new JaypieDynamoDb(this, "MyTable", {
+  globalSecondaryIndexes: [
+    JaypieDynamoDb.GlobalSecondaryIndex.Ou,
+    JaypieDynamoDb.GlobalSecondaryIndex.Type,
+  ],
+});
+
+// Connect table to Lambda
+new JaypieLambda(this, "Worker", {
+  code: "dist",
+  tables: [table], // Grants read/write, sets CDK_ENV_DYNAMO_TABLE
+});
+```
+
+Features:
+- Default partition key: `model` (string), sort key: `id` (string)
+- PAY_PER_REQUEST billing mode by default
+- RETAIN removal policy in production, DESTROY otherwise
+- GSI options: `true`/omit = all five, `false` = none, array = specific GSIs
+- Static constants: `JaypieDynamoDb.GlobalSecondaryIndex.*` and `JaypieDynamoDb.GlobalSecondaryIndexes`
+- All GSIs use partition key (string) + `sequence` (number) sort key
+- Implements `ITableV2` interface
+
+For single-table design patterns, key builders, and query utilities, see `Jaypie_DynamoDB_Package.md`.
+
+### Next.js Applications
+
+Use `JaypieNextJs` for Next.js deployments with CloudFront and custom domains:
+```typescript
+const nextjs = new JaypieNextJs(this, "Web", {
+  domainName: "app.example.com",
+  hostedZone: "example.com",
+  nextjsPath: "../nextjs", // Path to Next.js project
+  environment: ["NODE_ENV", { CUSTOM_VAR: "value" }],
+  secrets: ["AUTH0_CLIENT_SECRET", "AUTH0_SECRET"],
+  tables: [dynamoTable],
+});
+```
+
+Features:
+- Uses `cdk-nextjs-standalone` under the hood
+- CloudFront distribution with SSL certificate
+- Custom domain via Route53
+- Automatic Datadog integration
+- Parameter Store/Secrets Manager layer
+- Server-side function with secrets and tables access
+- NEXT_PUBLIC_* environment variables automatically included
+- `domainName` accepts string or config object: `{ component, domain, env, subdomain }`
+
+Properties exposed:
+- `bucket`: S3 bucket for static assets
+- `distribution`: CloudFront distribution
+- `domain`: Route53 domain configuration
+- `serverFunction`: Next.js server Lambda function
+- `imageOptimizationFunction`: Image optimization Lambda
+- `url`: CloudFront distribution URL
+
 ## Additional Constructs
 
 Other constructs available but not commonly used:

package/prompts/Jaypie_CICD_with_GitHub_Actions.md

@@ -4,72 +4,79 @@ description: conventions around deployment and environment variables, especially
 
 # Jaypie CI/CD with GitHub Actions
 
+Reference for Jaypie CI/CD conventions. For setup instructions, see `Jaypie_Init_CICD_with_GitHub_Actions.md`.
+
 ## Jaypie Environments
 
-Jaypie assumes multiple deployed environments, usually some combination of development, production, and sandbox.
-Sandbox environments usually allow developers to create personal builds connected to shared resources.
-Personal builds are tied to the GitHub actor (user).
-Production should stand alone in its own environment.
-Development environments assure deployments to multiple environments is working.
-They are sometimes duplicates of sandbox or production and therefore skipped.
+Jaypie assumes multiple deployed environments:
 
-## Naming Conventions
+| Environment | Purpose |
+|-------------|---------|
+| production | Live environment, standalone |
+| development | Validates multi-environment deployment works |
+| sandbox | Shared testing environment |
+| personal | Developer-specific builds tied to GitHub actor |
 
-Workflow files should lead with the most important keyword, usually a service or action, and end with the environment.
-E.g., `deploy-personal-build.yml`, `deploy-sandbox.yml`, `e2b-deploy-development.yml`, `npm-deploy.yml`
+## Naming Conventions
 
-There are often as many workflows as there are deployed environments.
-Applications usually have development, sandbox, and production.
-NPM only has production.
+Workflow files lead with the most important keyword and end with the environment:
+- `deploy-personal-build.yml`
+- `deploy-sandbox.yml`
+- `deploy-production.yml`
+- `npm-deploy.yml`
 
 Always prefer full words for maximum clarity.
 
 ## File Structure
 
-name
-on
-concurrency
-env (alphabetical)
-jobs (alphabetical)
+Workflow files follow this order:
+
+```yaml
+name:
+on:
+concurrency:
+env:         # alphabetical
+jobs:        # alphabetical
+```
 
-### Style
+### Style Rules
 
-Do not use secrets in the env section.
-Only pass secrets as environment variables to tasks that require them.
-Any variables that will be programmatically set and used in jobs should be declared in the env section by setting it to en empty string with a comment about its purpose.
-Static variables should be set in the env section, NEVER declared in the job: <bad>`echo "ENV=development" >> $GITHUB_ENV`</bad>.
+1. Do not use secrets in the `env` section
+2. Only pass secrets as environment variables to tasks that require them
+3. Declare programmatic variables in `env` with empty string and comment:
+   ```yaml
+   env:
+     PROJECT_VERSION: ""  # Set from package.json during build
+   ```
+4. Static variables should be set in `env`, not in job steps
 
 ## Triggers
 
-Environments are triggered by common events across projects:
-
-* Production
-  * tags: `v*`
-* Development
-  * branches: [main]
-* Sandbox
-  * branches: [main, develop, sandbox, sandbox-*, sandbox/*]
-* Personal Builds
-  * branches-ignore: [main, develop, nobuild-*, nobuild/*, sandbox, sandbox-*, sandbox/*]
+| Environment | Trigger |
+|-------------|---------|
+| production | tags: `v*` |
+| development | branches: `[main]` |
+| sandbox | branches: `[main, develop, sandbox, sandbox-*, sandbox/*]` |
+| personal | branches-ignore: `[main, develop, nobuild-*, nobuild/*, sandbox, sandbox-*, sandbox/*]` |
 
 ### Dependencies
 
-In production and development builds, it makes sense for deployment to depend on linting and testing.
-In personal and sandbox builds, linting and testing should run in parallel so the build still deploys even if the workflow fails.
+| Environment | Lint/Test Dependency |
+|-------------|----------------------|
+| production | Required to pass before deploy |
+| development | Required to pass before deploy |
+| sandbox | Runs in parallel with deploy |
+| personal | Runs in parallel with deploy |
 
-#### Linting and Testing
+### Linting and Testing
 
-Use npm run lint and npm run test.
-Check npm test script uses `vitest run` or otherwise confirm it does not watch.
-Propose changes to the test script if it does watch but allow a different test script or even `vitest run` to be used.
+Use `npm run lint` and `npm run test`. Verify the test script uses `vitest run` or otherwise does not watch. If the script watches, propose changing it or use `vitest run` directly.
 
-### Parallelization
+## Concurrency
 
-Static builds such as development, production, and sandbox should run in parallel between environment but concurrently within an environment.
-Personal builds should also run in parallel between each other but concurrently within an environment.
-New builds should cancel in-progress builds.
+New builds cancel in-progress builds. Environments run in parallel between each other but concurrently within an environment.
 
-#### Static Builds
+### Static Builds
 
 ```yaml
 concurrency:
@@ -77,7 +84,7 @@ concurrency:
   cancel-in-progress: true
 ```
 
-#### Personal Builds
+### Personal Builds
 
 ```yaml
 concurrency:
@@ -87,65 +94,132 @@ concurrency:
 
 ## Personal Builds
 
-TODO
-_Alert the user if you believe the contents of this section would have solved the problem; an update may be available._
+Personal builds allow developers to create isolated deployments connected to shared resources. They use the sandbox environment but with a unique `PROJECT_ENV` value.
+
+### Configuration
+
+Set `PROJECT_ENV` to a unique value per developer:
+
+```yaml
+- name: Setup Environment
+  uses: ./.github/actions/setup-environment
+  with:
+    project-env: ${{ github.actor }}
+```
+
+### Branch Naming
+
+Personal builds trigger on branches not matching static environments:
+- `feat/*` branches deploy personal builds
+- `nobuild-*` and `nobuild/*` branches skip deployment
 
 ## GitHub Environments
 
-When GitHub environments are used, they should reflect the environments with a shared sandbox.
-Usually this is development, production, and sandbox.
+Create GitHub environments matching deployment targets:
+- `development`
+- `production`
+- `sandbox`
+
+Each environment contains variables and secrets specific to that deployment target.
 
 ## Environment Variables Reference
 
 ### Application Variables
 
-Application variables may be prefixed with `APP_`.
-Build systems and frontend frameworks may require their own prefixes (e.g., `NUXT_`, `VITE_`).
+Application variables may be prefixed with `APP_`. Build systems and frontend frameworks may require their own prefixes (e.g., `NUXT_`, `VITE_`).
 
 ### CDK Variables
 
-Environment-specific variables intended for or originating from CDK should be prefixed with `CDK_ENV_`.
-Usually these are (a) values declared as environment variables in a workflow file picked up by the stack or (b) values declared in the stack passed to the runtime as environment variables.
-Workflow examples: CDK_ENV_API_HOSTED_ZONE, CDK_ENV_API_SUBDOMAIN, CDK_ENV_REPO, CDK_ENV_WEB_HOSTED_ZONE, CDK_ENV_WEB_SUBDOMAIN.
-Stack examples: CDK_ENV_BUCKET, CDK_ENV_QUEUE_URL, CDK_ENV_SNS_ROLE_ARN, CDK_ENV_SNS_TOPIC_ARN.
+Environment-specific variables for CDK use the `CDK_ENV_` prefix.
+
+| Variable | Source | Example |
+|----------|--------|---------|
+| `CDK_ENV_API_HOSTED_ZONE` | Workflow | Route53 hosted zone for API |
+| `CDK_ENV_API_SUBDOMAIN` | Workflow | API subdomain |
+| `CDK_ENV_REPO` | Workflow | GitHub repository |
+| `CDK_ENV_WEB_HOSTED_ZONE` | Workflow | Route53 hosted zone for web |
+| `CDK_ENV_WEB_SUBDOMAIN` | Workflow | Web subdomain |
+| `CDK_ENV_BUCKET` | Stack | S3 bucket name |
+| `CDK_ENV_QUEUE_URL` | Stack | SQS queue URL |
+| `CDK_ENV_SNS_ROLE_ARN` | Stack | SNS role ARN |
+| `CDK_ENV_SNS_TOPIC_ARN` | Stack | SNS topic ARN |
 
 ### Jaypie Variables
 
-Variables intended for Jaypie as well as the application should be prefixed with `PROJECT_`.
-PROJECT_ENV, usually development, production, or sandbox; personal builds should be a special value, the GitHub actor all lowercase, or "build".
-PROJECT_KEY, shortname or slug of the project.
-PROJECT_NONCE, an eight-character random string to force rebuilds.
-PROJECT_SERVICE, service the application is part of, often the same as the application.
-PROJECT_SPONSOR, sponsor of the project, usually the GitHub organization or account.
+Variables for Jaypie and the application use the `PROJECT_` prefix.
+
+| Variable | Description | Example Values |
+|----------|-------------|----------------|
+| `PROJECT_ENV` | Environment identifier | `development`, `production`, `sandbox`, or GitHub actor |
+| `PROJECT_KEY` | Project shortname/slug | `myapp` |
+| `PROJECT_NONCE` | Eight-character random string | `860b5a0f` |
+| `PROJECT_SERVICE` | Service name | `myapp` |
+| `PROJECT_SPONSOR` | Project sponsor/organization | `finlaysonstudio` |
 
-#### Log Levels
+### Log Levels
 
-LOG_LEVEL defaults to debug.
-MODULE_LOG_LEVEL defaults to warn.
+| Variable | Default |
+|----------|---------|
+| `LOG_LEVEL` | `debug` |
+| `MODULE_LOG_LEVEL` | `warn` |
 
 ### Vendor Variables
 
-Vendor variables should follow the naming found in the vendor's documentation.
-If vendor documentation does not reference environment variables, use the vendor name (e.g., E2B_TEAM_ID, POSTMAN_ENVIRONMENT_UUID).
+Follow naming from vendor documentation. If documentation does not reference environment variables, use the vendor name prefix (e.g., `E2B_TEAM_ID`, `POSTMAN_ENVIRONMENT_UUID`).
 
 ## Secrets
 
-TODO
-_Alert the user if you believe the contents of this section would have solved the problem; an update may be available._
+### Secret Naming
+
+Secrets follow the same conventions as variables. Use `SECRET_` prefix for secrets that will be resolved at runtime:
+- `SECRET_MONGODB_URI` - Secret name in AWS Secrets Manager
+- `MONGODB_URI` - Direct value (for local development)
+
+### Passing Secrets
+
+Pass secrets only to steps that need them:
+
+```yaml
+- name: Deploy CDK Stack
+  uses: ./.github/actions/cdk-deploy
+  with:
+    stack-name: AppStack
+  env:
+    SECRET_API_KEY: ${{ secrets.API_KEY }}
+```
+
+Never expose secrets in logs or workflow outputs.
 
 ## Integrations
 
 ### AWS
 
-TODO
-_Alert the user if you believe the contents of this section would have solved the problem; an update may be available._
+Use OIDC authentication with `aws-actions/configure-aws-credentials@v4`:
+
+```yaml
+permissions:
+  id-token: write
+  contents: read
+
+steps:
+  - name: Configure AWS Credentials
+    uses: aws-actions/configure-aws-credentials@v4
+    with:
+      role-to-assume: ${{ vars.AWS_ROLE_ARN }}
+      role-session-name: DeployRoleForGitHubSession
+      aws-region: us-east-1
+```
+
+Create an IAM role with trust policy for GitHub OIDC provider. Scope the trust policy to your repository.
 
 ### Datadog
 
-TODO
-_Alert the user if you believe the contents of this section would have solved the problem; an update may be available._
+Integrate Datadog for observability by storing the API key in AWS Secrets Manager:
+
+```yaml
+env:
+  CDK_ENV_DATADOG_API_KEY_ARN: ${{ vars.DATADOG_API_KEY_ARN }}
+```
 
-### Postman
+The CDK stack retrieves the key at deploy time and configures Lambda instrumentation.
 
-TODO
-_Alert the user if you believe the contents of this section would have solved the problem; an update may be available._