@aws/nx-plugin-mcp 1.0.0-rc.95 → 1.0.0-rc.97

package/docs/guides/ts-lambda-function.mdx

@@ -38,9 +38,13 @@ The generator will add the following files to your project:
 - \<project-name>
   - src/
     - \<lambda-function>.ts Function implementation
+  - rolldown.config.ts [Bundling](#bundling) configuration for the function
+  - .gitignore Ignores the temporary configs Rolldown writes
 
 </FileTree>
 
+The generator also adds a `bundle` target to the project's `project.json`, and the Powertools, Middy and Zod runtime dependencies the handler imports to its `package.json`.
+
 If the `functionPath` option is provided, the generator will add the handler to the specified path within the project source directory:
 
 <FileTree>
@@ -78,6 +82,7 @@ The main function implementation is in `<function-name>.ts`. Here's an example:
 ```typescript
 import { parser } from '@aws-lambda-powertools/parser/middleware';
 import { EventBridgeSchema } from '@aws-lambda-powertools/parser/schemas';
+import { z } from 'zod';
 import middy from '@middy/core';
 import { Tracer } from '@aws-lambda-powertools/tracer';
 import { captureLambdaHandler } from '@aws-lambda-powertools/tracer/middleware';
@@ -85,7 +90,8 @@ import { injectLambdaContext } from '@aws-lambda-powertools/logger/middleware';
 import { Logger } from '@aws-lambda-powertools/logger';
 import { Metrics } from '@aws-lambda-powertools/metrics';
 import { logMetrics } from '@aws-lambda-powertools/metrics/middleware';
-import { z } from 'zod';
+import type { Context } from 'aws-lambda';
+export type { Context };
 
 process.env.POWERTOOLS_METRICS_NAMESPACE = 'MyFunction';
 process.env.POWERTOOLS_SERVICE_NAME = 'MyFunction';

package/docs/guides/ts-mcp-server.mdx

@@ -88,16 +88,20 @@ import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
 import { z } from 'zod';
 
 export const registerMyTool = (server: McpServer) => {
-  server.registerTool("toolName", {
-    description: "tool description",
-    inputSchema: { param1: z.string(), param2: z.number() } // Input schema using Zod
-  },
+  server.registerTool(
+    'toolName',
+    {
+      description: 'tool description',
+      // Input schema using Zod
+      inputSchema: { param1: z.string(), param2: z.number() },
+    },
     async ({ param1, param2 }) => {
       // Tool implementation
+      const result = `${param1} ${param2}`;
       return {
-        content: [{ type: "text", text: "Result" }]
+        content: [{ type: 'text' as const, text: result }],
       };
-    }
+    },
   );
 };
 ```
@@ -123,20 +127,46 @@ Resources provide context to the AI assistant. Like tools, each resource lives i
 ```typescript title="resources/my-resource.ts"
 import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
 
+const fetchSomeData = async (): Promise<string> => 'some dynamic context';
+
 export const registerMyResource = (server: McpServer) => {
   const exampleContext = 'some context to return';
 
-  server.registerResource('resource-name', 'example://resource', {}, async (uri) => ({
-    contents: [{ uri: uri.href, text: exampleContext }],
-  }));
+  server.registerResource(
+    'resource-name',
+    'example://resource',
+    {},
+    async (uri) => ({
+      contents: [{ uri: uri.href, text: exampleContext }],
+    }),
+  );
 
   // Dynamic resource
-  server.registerResource('dynamic-resource', 'dynamic://resource', {}, async (uri) => {
-    const data = await fetchSomeData();
-    return {
-      contents: [{ uri: uri.href, text: data }],
-    };
-  });
+  server.registerResource(
+    'dynamic-resource',
+    'dynamic://resource',
+    {},
+    async (uri) => {
+      const data = await fetchSomeData();
+      return {
+        contents: [{ uri: uri.href, text: data }],
+      };
+    },
+  );
+};
+```
+
+Register it inside `createServer` in `server.ts` the same way as a tool:
+
+```typescript title="server.ts" {6}
+import { registerMyResource } from './resources/my-resource.js';
+
+export const createServer = async () => {
+  const server = new McpServer({ name: 'my-server', version: '1.0.0' });
+
+  registerMyResource(server);
+
+  return server;
 };
 ```
 

package/docs/guides/ts-rdb.mdx

@@ -45,11 +45,18 @@ The generator will create the following project structure in the `<directory>/<n
     - create-db-user-handler.ts Lambda handler used to create the application database user during deployment
     - migration-handler.ts Lambda handler used to run database migrations during deployment
   - .gitignore Git ignore entries including generated Prisma client output
+  - .trivyignore Vulnerability IDs to suppress when scanning the migration image
   - config.json Local development connection details and runtime config key
   - Dockerfile Container image definition for the migration handler
   - package.json Project manifest defining the project's package name and dependencies
   - project.json Project configuration and build targets
   - prisma.config.ts Configuration for Prisma CLI
+  - README.md Project readme
+  - rolldown.config.ts Bundler configuration invoked by the `bundle` target
+  - tsconfig.json TypeScript project references
+  - tsconfig.lib.json TypeScript configuration for the library build
+  - tsconfig.spec.json TypeScript configuration for tests
+  - vitest.config.mts Vitest configuration
 </FileTree>
 
 Local development scripts are shared across all database projects and generated into `packages/common/scripts/`:
@@ -264,7 +271,7 @@ module "api" {
   source = "..."
   ...
 
-  environment_variables = {
+  env = {
     NODE_EXTRA_CA_CERTS = "/var/runtime/ca-cert.pem"
   }
 }
@@ -342,7 +349,7 @@ export const listExampleTable = publicProcedure
 
 **Option 2: tRPC middleware**
 
-If you are using the [middleware pattern](#injecting-the-prisma-client-via-middleware), add the `$disconnect()` call to the middleware so all procedures built on it are covered automatically:
+If you are using the <Link path="guides/connection/trpc-rdb#using-the-middleware">middleware pattern</Link>, add the `$disconnect()` call to the middleware so all procedures built on it are covered automatically:
 
 ```ts title="packages/api/src/middleware/db.ts"
 import { getPrisma } from '@my-scope/db';

package/docs/guides/ts-smithy-api.mdx

@@ -18,6 +18,8 @@ import PackageManagerShortCommand from '@components/package-manager-short-comman
 import Infrastructure from '@components/infrastructure.astro';
 import Snippet from '@components/snippet.astro';
 import OptionFilter from '@components/option-filter.astro';
+import InstallCommand from '@components/install-command.astro';
+import { TS_VERSIONS } from '../../../../../../packages/nx-plugin/src/utils/versions';
 
 [Smithy](https://smithy.io/) is a protocol-agnostic interface definition language for authoring APIs in a model driven fashion.
 
@@ -46,7 +48,6 @@ The generator creates two related projects in the `<directory>/<api-name>` direc
 <FileTree>
 
 - **model/** Smithy model project
-  - package.json Project manifest defining the project's package name and dependencies
   - project.json Project configuration and build targets
   - smithy-build.json Smithy build configuration
   - ssdk.rolldown.config.mjs Bundles the generated TypeScript Server SDK
@@ -55,9 +56,15 @@ The generator creates two related projects in the `<directory>/<api-name>` direc
     - operations/
       - echo.smithy Example operation definition
 - **backend/** TypeScript backend implementation
+  - package.json Project manifest defining the project's package name and dependencies
   - project.json Project configuration and build targets
   - rolldown.config.ts Bundle configuration
+  - tsconfig.json TypeScript configuration
+  - tsconfig.lib.json TypeScript configuration for the library sources
+  - tsconfig.spec.json TypeScript configuration for the tests
+  - vitest.config.mts Vitest configuration
   - src/
+    - index.ts Package entrypoint
     - handler.ts AWS Lambda handler
     - local-server.ts Local development server
     - service.ts Service implementation
@@ -91,7 +98,7 @@ The common infrastructure as code project is structured as follows:
 </FileTree>
 
 :::note[Generated Project]
-This project is generated using the [`ts#project`](guides/typescript-project) generator and therefore configures the same build targets.
+This project is generated using the <Link path="/guides/typescript-project">`ts#project`</Link> generator and therefore configures the same build targets.
 :::
 </Fragment>
 <Fragment slot="terraform">
@@ -110,7 +117,7 @@ This project is generated using the [`ts#project`](guides/typescript-project) ge
 </FileTree>
 
 :::note[Generated Project]
-This project is generated using the [`terraform#project`](guides/terraform-project) generator and therefore configures the same build targets.
+This project is generated using the <Link path="/guides/terraform-project">`terraform#project`</Link> generator and therefore configures the same build targets.
 :::
 </Fragment>
 </Infrastructure>
@@ -475,7 +482,9 @@ export interface ServiceContext {
 Next, write the resolver in `src/identity.ts`. It throws `UnauthorizedError` when the caller cannot be determined. The implementation depends on your selected `auth` method:
 
 <OptionFilter when={{ auth: 'iam' }} description="Identity resolution for IAM-authenticated APIs">
-For `IAM` authentication, we look up the caller in Cognito using the sub extracted from the API Gateway event:
+For `IAM` authentication, we look up the caller in Cognito using the sub extracted from the API Gateway event. The lookup uses the Cognito Identity Provider client, which is not a dependency of a generated Smithy backend, so install it into the backend project first:
+
+<InstallCommand pkg={`@aws-sdk/client-cognito-identity-provider@${TS_VERSIONS['@aws-sdk/client-cognito-identity-provider']}`} project="@my-scope/my-api" projectDir="packages/my-api/backend" />
 
 ```ts
 import { CognitoIdentityProvider } from '@aws-sdk/client-cognito-identity-provider';
@@ -498,7 +507,9 @@ export const getIdentity = async (
   }
 
   if (!sub) {
-    throw new UnauthorizedError({ message: 'Unable to determine calling user' });
+    throw new UnauthorizedError({
+      message: 'Unable to determine calling user',
+    });
   }
 
   const { Users } = await cognito.listUsers({
@@ -509,7 +520,9 @@ export const getIdentity = async (
   });
 
   if (!Users || Users.length !== 1) {
-    throw new UnauthorizedError({ message: `No user found with subjectId ${sub}` });
+    throw new UnauthorizedError({
+      message: `No user found with subjectId ${sub}`,
+    });
   }
 
   return { sub, username: Users[0].Username! };
@@ -536,7 +549,9 @@ export const getIdentity = async (
   const username = claims?.username;
 
   if (!sub || !username) {
-    throw new UnauthorizedError({ message: 'Unable to determine calling user' });
+    throw new UnauthorizedError({
+      message: 'Unable to determine calling user',
+    });
   }
 
   return { sub, username };
@@ -562,6 +577,17 @@ const httpResponse = await serviceHandler.handle(httpRequest, {
 });
 ```
 
+`getIdentity` is a required field on `ServiceContext`, and as the [caution above](#service-context) notes the context is constructed in **both** entrypoints — so `src/local-server.ts` needs it too. There is no API Gateway authorizer in front of the local server, so supply a stub identity for local development:
+
+```ts {5} ins={5}
+const httpResponse = await serviceHandler.handle(httpRequest, {
+  tracer,
+  logger,
+  metrics,
+  getIdentity: async () => ({ sub: 'local', username: 'local' }),
+});
+```
+
 We can now use the resolved identity in an operation, for example in `src/operations/echo.ts`:
 
 ```ts
@@ -801,6 +827,49 @@ output "lambda_function_name" {
 
 ### Integrations
 
+<Infrastructure>
+<Fragment slot="cdk">
+:::caution[Operation names are camelCase in CDK]
+Smithy operations are declared in PascalCase (`Echo`), and your backend exports them under that name. The CDK integration keys are the **camelCase** form of the same name, so an operation `Echo` is `echo` everywhere in your stack:
+
+```ts
+const api = new MyApi(this, 'MyApi', {
+  integrations: MyApi.defaultIntegrations(this)
+    // `Echo` in the model, `echo` here
+    .withOperationOptions({ echo: { timeout: Duration.seconds(60) } })
+    .build(),
+});
+
+api.integrations.echo.handler.addToRolePolicy(...);
+```
+:::
+</Fragment>
+<Fragment slot="terraform">
+:::note[Operation names are camelCase in Terraform]
+The generated module's operation-keyed outputs and its `operations.json` use the **camelCase** form of the Smithy operation name, so a Smithy operation `Echo` is keyed `echo`:
+
+```hcl
+# `Echo` in the model, `echo` here
+resource "aws_iam_role_policy" "echo_permissions" {
+  name = "echo-additional-permissions"
+  role = module.my_api.lambda_execution_role_names["echo"]
+
+  policy = jsonencode({
+    Version = "2012-10-17"
+    Statement = [
+      {
+        Effect   = "Allow"
+        Action   = ["s3:GetObject"]
+        Resource = "arn:aws:s3:::my-bucket/*"
+      }
+    ]
+  })
+}
+```
+:::
+</Fragment>
+</Infrastructure>
+
 <Snippet name="api/type-safe-api-integrations" parentHeading="Integrations" />
 
 #### Code Generation

package/docs/guides/typescript-infrastructure.mdx

@@ -44,7 +44,7 @@ The generator will create the following project structure in the `<directory>/<n
 
 </FileTree>
 
-If you set the `stageConfig` option, the generator also creates two shared packages for centralized credential management (if they don't already exist):
+If you generate with `--stageConfig=true`, the generator also creates two shared packages for centralized credential management (if they don't already exist):
 
 <FileTree>
 
@@ -53,12 +53,17 @@ If you set the `stageConfig` option, the generator also creates two shared packa
       - src
         - stages.types.ts Type definitions for stage credentials and config
         - stages.config.ts Your stage-to-credential mappings (edit this)
+        - resolve-stage.ts The `resolveStage` lookup your `main.ts` imports
         - index.ts Re-exports for importing from other packages
+      - README.md
     - scripts Centralized deploy/destroy scripts
       - src
-        - infra-deploy.ts Deploy bin script
-        - infra-destroy.ts Destroy bin script
-        - stage-credentials/ Shared logic (credential lookup, CDK command building)
+        - infra
+          - infra-deploy.ts Deploy bin script
+          - infra-destroy.ts Destroy bin script
+          - index.ts Re-exports for importing from other packages
+          - stage-credentials/ Shared logic (credential lookup, CDK command building)
+      - README.md
 
 </FileTree>
 
@@ -164,7 +169,11 @@ export class ApplicationStage extends Stage {
 ### Stage Credential Configuration
 
 :::note[Staged Configuration]
-This section applies when you generate with `stageConfig`. Without it, the generator produces a simpler setup where you manage AWS credentials yourself (e.g., by exporting `AWS_PROFILE` before deploying).
+This section applies when you generate with `stageConfig`:
+
+<NxCommands commands={['g @aws/nx-plugin:ts#infra --name=infra --stageConfig=true']} />
+
+Without it, the generator produces a simpler setup where you manage AWS credentials yourself (e.g., by exporting `AWS_PROFILE` before deploying).
 :::
 
 When you have multiple stages targeting different AWS accounts, managing credentials manually can be error-prone, especially as the number of stages grows.
@@ -263,8 +272,13 @@ Shared stages (under `shared.stages`) apply to any infra project in the workspac
 
 Project-specific stages (under `projects['packages/infra'].stages`) only apply to that project. When both exist for the same stage name, the project-specific entry takes priority.
 
-:::tip[Commit Stage Config]
-We recommend committing `stages.config.ts` so the team shares a single source of truth for stage credentials. If it contains personal profile names, you can add it to `.gitignore` and use a local override instead.
+:::note[Commit Stage Config]
+If you wish to commit `stages.config.ts` so the team shares a single source of truth for stage credentials, credential scanning may flag any AWS Account IDs specified in this file. You can suppress this in `.gitallowed` as follows:
+
+```text title=".gitallowed"
+# Allow AWS Account IDs in the stage configuration
+stages\.config\.ts:[0-9]+:.*[0-9]{12}
+```
 :::
 
 ### API Infrastructure
@@ -382,7 +396,7 @@ Your project has three deploy targets, each suited to a different situation:
 | Target           | Use it for                                                                                             |
 | ---------------- | ------------------------------------------------------------------------------------------------------ |
 | `deploy-sandbox` | Deploying your own sandbox stage during development. No stage argument needed. Uses express mode.        |
-| `deploy`         | Deploying any stage, by naming the stage or stacks you want.                                            |
+| `deploy`         | Deploying any stage, by naming the stage or stacks you want. Waits for full stabilization.               |
 | `deploy-ci`      | Deploying from a CI/CD pipeline, using a pre-synthesized cloud assembly. Waits for full stabilization.   |
 
 `deploy-sandbox` and `deploy` depend on `^assemble`, so they build the artifacts they are about to deploy and nothing else. `deploy-ci` deploys an assembly your pipeline already built, so it has no build dependencies at all.
@@ -419,7 +433,7 @@ You can specify any stage so long as it is defined in `main.ts`. To deploy an in
 
 <NxCommands commands={['deploy <my-infra> <my-infra>-sandbox/Application']} />
 
-Since this target can name any stage, including your production one, it waits for full resource stabilization when you generate with `stageConfig`. Pass `--express` to opt into express mode for a stage you are iterating on.
+Since this target can name any stage, including your production one, it waits for full resource stabilization. Pass `--express` to opt into express mode for a stage you are iterating on.
 
 ## Deploying to AWS in a CI/CD Pipeline
 
@@ -427,7 +441,7 @@ Use the `deploy-ci` target if you are deploying to AWS as part of a CI/CD pipeli
 
 <NxCommands commands={['deploy-ci <my-infra> my-stage/*']} />
 
-This target differs from the `deploy` and `deploy-sandbox` targets in two ways. First, it deploys a pre-synthesized cloud assembly rather than synthesizing on the fly, avoiding potential non-determinism from package version changes and ensuring that every pipeline stage deploys using the same cloud assembly. Second, it never uses express mode, so it always waits for every resource to fully stabilize before reporting success.
+This target deploys a pre-synthesized cloud assembly rather than synthesizing on the fly, avoiding potential non-determinism from package version changes and ensuring that every pipeline stage deploys using the same cloud assembly. Like `deploy`, it waits for every resource to fully stabilize before reporting success, and unlike `deploy` it accepts no `--express` opt-out.
 
 ## Tearing Down AWS Infrastructure
 

package/docs/guides/typescript-project.mdx

@@ -34,6 +34,7 @@ The generator will create the following project structure in the `<directory>/<n
 
   - src TypeScript source code
     - index.ts
+  - README.md
   - package.json Project manifest defining the project's package name and dependencies
   - project.json Project configuration and build targets
   - tsconfig.json Base TypeScript configuration for this project (extends workspace root tsconfig.base.json)
@@ -54,6 +55,10 @@ You will also notice some changes to the following files in your workspace root:
   - nx.json Nx configuration is updated to configure the @nx/js/typescript plugin for your project
   - tsconfig.base.json a TypeScript alias is set up for your project so that it can be imported by other projects in your workspace
   - tsconfig.json a TypeScript project reference is added for your project
+  - vitest.config.mts the shared Vitest configuration your project's own vitest.config.mts extends (created by the first TypeScript project)
+  - package.json shared build and test tooling is added
+  - pnpm-workspace.yaml the project is added to the workspace, and dependency versions to the [catalog](#catalogs) (the equivalent file for your package manager)
+  - .gitignore build and test output paths are ignored
 
 </FileTree>
 
@@ -270,11 +275,14 @@ You can achieve this by adding a target such as the following to your `project.j
     ...
     "bundle": {
       "cache": true,
+      "inputs": ["default"],
       "executor": "nx:run-commands",
       "outputs": ["{workspaceRoot}/dist/packages/my-library/bundle"],
       "options": {
-        "command": "rolldown -c rolldown.config.ts"
-      }
+        "command": "rolldown -c rolldown.config.ts",
+        "cwd": "{projectRoot}"
+      },
+      "dependsOn": ["compile"]
     },
   },
 }
@@ -288,12 +296,14 @@ import { defineConfig } from 'rolldown';
 
 export default defineConfig([
   {
+    tsconfig: 'tsconfig.lib.json',
     input: 'src/index.ts',
     output: {
       file: '../../dist/packages/my-library/bundle/index.js',
       format: 'cjs',
       codeSplitting: false,
     },
+    platform: 'node',
   },
 ]);
 ```
@@ -366,13 +376,10 @@ Vitest provides Jest-like syntax for defining tests, with utilities such as `des
 import { sayHello } from './hello.js';
 
 describe('sayHello', () => {
-
   it('should greet the caller', () => {
     expect(sayHello('Darth Vader')).toBe('Hello, Darth Vader!');
   });
-
 });
-
 ```
 
 For more details about how to write tests, and features such as mocking dependencies, refer to the [Vitest documentation](https://vitest.dev/guide/#writing-tests)

package/docs/guides/workspace.mdx

@@ -2,7 +2,7 @@
 title: Workspace
 description: Reference documentation for workspaces
 ---
-import { FileTree } from '@astrojs/starlight/components';
+import { Aside, FileTree } from '@astrojs/starlight/components';
 import Link from '@components/link.astro';
 import CreateNxWorkspaceCommand from '@components/create-nx-workspace-command.astro';
 import PackageManagerShortCommand from '@components/package-manager-short-command.astro';
@@ -29,6 +29,7 @@ When you create a new workspace with `@aws/nx-plugin`, the preset generator sets
   - tsconfig.base.json Root TypeScript configuration
   - aws-nx-plugin.config.mts Nx Plugin for AWS configuration
   - .git-secrets/ Vendored git-secrets bash script for credential scanning
+  - .gitallowed Patterns git-secrets treats as false positives
   - .husky/ Git hooks
   - .mcp.json Nx Plugin for AWS MCP server configuration for Claude Code
   - .cursor/mcp.json ...and for Cursor
@@ -167,21 +168,26 @@ New workspaces are configured with [Biome](https://biomejs.dev/) for static anal
 
 ### Git Secrets
 
-New workspaces include [git-secrets](https://github.com/awslabs/git-secrets) pre-commit hooks that scan staged files for AWS credential patterns before each commit. This prevents accidentally committing access keys, secret keys, and other sensitive values.
+Workspaces are set up with [git-secrets](https://github.com/awslabs/git-secrets) pre-commit hooks that scan staged files for AWS credential patterns before each commit. This prevents accidentally committing access keys, secret keys, and other sensitive values.
+
+The script is vendored into the workspace at `.git-secrets/git-secrets` and run by the `.husky/pre-commit` hook, so there is nothing to install — but it is not on your `PATH`, so invoke it by path rather than as `git secrets`.
 
 #### Suppressing False Positives
 
 Patterns in git-secrets use [egrep-compatible regular expressions](https://github.com/awslabs/git-secrets#options-for-add). If git-secrets blocks a commit that does not contain real credentials:
 
 ```sh
-# Allow a specific regex pattern
-git secrets --add --allowed 'my-regex-pattern'
+# Allow a specific regex pattern (-a is the allowed flag)
+bash .git-secrets/git-secrets --add -a -- 'my-regex-pattern'
+
+# Allow a literal string, escaping special characters (-l is the literal flag)
+bash .git-secrets/git-secrets --add -a -l -- 'my-literal+string'
 
-# Allow a literal string (special characters are escaped)
-git secrets --add --allowed --literal 'my-literal+string'
+# List what is currently allowed
+git config --get-all secrets.allowed
 ```
 
-You can also create a `.gitallowed` file at the repository root with one egrep-compatible regex per line (shared with your team via version control):
+These are recorded in your local git config, so they apply only to your own clone. To share a suppression with your team, add it to the `.gitallowed` file at the repository root instead — one egrep-compatible regex per line, matched against `<path>:<line-number>:<line-contents>`:
 
 ```text title=".gitallowed"
 # Allow test fixtures
@@ -194,7 +200,7 @@ For full details on managing patterns, see the [git-secrets documentation](https
 
 ## Nx Plugin for AWS Configuration
 
-The workspace ships with an `aws-nx-plugin.config.mts` file at the root. Generators read this file to pick sensible defaults so you don't have to pass the same flags every time. Two settings are particularly useful:
+The workspace ships with an `aws-nx-plugin.config.mts` file at the root. Generators read this file to pick sensible defaults so you don't have to pass the same flags every time:
 
 ```typescript
 // aws-nx-plugin.config.mts
@@ -207,10 +213,16 @@ export default {
   containers: {
     engine: 'docker', // or 'finch'
   },
+  packageManager: {
+    catalogs: true, // or false
+  },
 } satisfies AwsNxPluginConfig;
 ```
 
 - **`iac.provider`** — the default infrastructure-as-code provider (`cdk` or `terraform`) used by generators that emit infrastructure (e.g. `ts#infra`, `ts#api`, `py#api`). Generators that accept an `--iac` flag default to `inherit`, which reads this value.
 - **`containers.engine`** — the container CLI (`docker` or `finch`) baked into generated build/push/login commands. CDK image-asset builds also pick this up via the `CDK_DOCKER` environment variable. See the <Link path="guides/docker-bundling">Docker bundling guide</Link> for details.
+- **`packageManager.catalogs`** — whether generators record dependency versions in the package manager's catalog and reference them with the `catalog:` protocol (see [Single Version Policy](#single-version-policy)). Set it to `false` to have generators write direct version ranges into each project's `package.json` instead. It has no effect on npm, which has no catalog.
+
+The <Link path="guides/license">license generator</Link> adds a `license` key to this same file to configure its own behaviour.
 
-You can edit either setting at any time — subsequent generator runs will pick up the new value.
+You can edit any setting at any time — subsequent generator runs will pick up the new value.

package/docs/snippets/api/type-safe-api-integrations.mdx

@@ -66,6 +66,8 @@ const api = new MyApi(this, 'MyApi', {
 
 api.integrations.$router.handler.addEnvironment('LOG_LEVEL', 'DEBUG');
 ```
+
+Note that `$router` is no longer available if you override every operation via `withOverrides`, since no operation is left using the default router integration.
 </Fragment>
 <Fragment slot="terraform">
 With the `isolated` pattern, the module's outputs are maps keyed by operation name, so you can reach a single operation's resources. For example, to grant one operation's Lambda function extra permissions:

package/docs/snippets/connection/a2a-infrastructure.mdx

@@ -3,9 +3,12 @@ title: A2A Connection Infrastructure
 ---
 import Link from '@components/link.astro';
 import Infrastructure from '@components/infrastructure.astro';
+import Snippet from '@components/snippet.astro';
 
 After running the connection generator, you need to grant the host agent permission to invoke the remote A2A agent.
 
+<Snippet name="connection/infra-project-prerequisite" />
+
 <Infrastructure>
 <Fragment slot="cdk">
 ```ts title="packages/infra/src/stacks/application-stack.ts" {5}

package/docs/snippets/connection/infra-project-prerequisite.mdx

@@ -0,0 +1,8 @@
+---
+title: Infrastructure Project Prerequisite
+---
+import Link from '@components/link.astro';
+
+:::note[Infrastructure project required]
+The agent, MCP server and Gateway generators vend their constructs and modules into `packages/common`, but they do not create an application to deploy them from — so `packages/infra` does not exist until you generate it. Run the <Link path="guides/typescript-infrastructure">`ts#infra`</Link> generator (CDK) or the <Link path="guides/terraform-project">`terraform#project`</Link> generator (Terraform) before editing the file below.
+:::

package/docs/snippets/connection/strands-agent-rdb-ssl-requirements.mdx

@@ -23,7 +23,7 @@ new MyAgent(this, 'MyAgent', {
 ```hcl title="packages/infra/src/main.tf"
 module "my_agent" {
   ...
-  environment_variables = {
+  env = {
     NODE_EXTRA_CA_CERTS = "/usr/local/share/ca-certificates/rds-bundle.crt"
   }
 }

package/docs/snippets/connection/ts-lambda-rdb-ssl-requirements.mdx

@@ -28,7 +28,7 @@ module "api" {
   source = "..."
   ...
 
-  environment_variables = {
+  env = {
     NODE_EXTRA_CA_CERTS = "/var/runtime/ca-cert.pem"
   }
 }

package/docs/snippets/connection/ts-mcp-server-rdb-ssl-requirements.mdx

@@ -23,7 +23,7 @@ new MyMcpServer(this, 'MyMcpServer', {
 ```hcl title="packages/infra/src/main.tf"
 module "my_mcp_server" {
   ...
-  environment_variables = {
+  env = {
     NODE_EXTRA_CA_CERTS = "/usr/local/share/ca-certificates/rds-bundle.crt"
   }
 }

package/docs/snippets/required-prerequisites.mdx

@@ -5,5 +5,5 @@ title: Required Prerequisites
 - [Node >= 22](https://nodejs.org/en/download) (We recommend using something like [NVM](https://github.com/nvm-sh/nvm) to manage your node versions)
   - verify by running `node --version`
 - [UV >= 0.5.29](https://docs.astral.sh/uv/getting-started/installation/)
-  1. install Python 3.14 by running: `uv python install 3.14.0`
+  1. install Python 3.14 by running: `uv python install 3.14`
   2. verify with `uv python list --only-installed`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws/nx-plugin-mcp",
-  "version": "1.0.0-rc.95",
+  "version": "1.0.0-rc.97",
   "repository": {
     "type": "git",
     "url": "https://github.com/awslabs/nx-plugin-for-aws.git",

package/src/init/schema.json

@@ -13,6 +13,11 @@
       "x-priority": "important",
       "x-prompt": "Which provider would you like to manage your infrastructure?"
     },
+    "gitSecrets": {
+      "type": "boolean",
+      "description": "Whether to configure git-secrets to prevent committing AWS credentials.",
+      "default": true
+    },
     "mcp": {
       "type": "boolean",
       "description": "Whether to configure the Nx Plugin for AWS MCP server for use by coding agents.",

package/src/py/project/schema.json

@@ -32,7 +32,9 @@
       "type": "string",
       "description": "Whether the project is an application or library",
       "default": "application",
-      "enum": ["application", "library"]
+      "enum": ["application", "library"],
+      "x-priority": "important",
+      "x-prompt": "What type of Python project would you like to create?"
     },
     "moduleName": {
       "type": "string",