@aws/nx-plugin-mcp 1.0.0-rc.22 → 1.0.0-rc.24

package/docs/guides/connection/ts-agent-rdb.mdx

@@ -46,7 +46,7 @@ The generator modifies two files in your agent's source directory:
 
 </FileTree>
 
-Additionally, the agent's `<agent-name>-serve-local` target is updated to depend on the database's `serve-local` target.
+Additionally, the agent's `<agent-name>-dev` target is updated to depend on the database's `dev` target.
 
 ## How It Works
 
@@ -136,6 +136,6 @@ Ensure the agent's execution role has `rds-db:connect` permission and that its s
 
 ## Local Development
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
-This starts the agent and all connected databases. The `SERVE_LOCAL=true` environment variable causes each Prisma client to connect to its local Docker database instead of Aurora.
+This starts the agent and all connected databases. The `LOCAL_DEV=true` environment variable causes each Prisma client to connect to its local Docker database instead of Aurora.

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

@@ -35,7 +35,7 @@ Select your MCP server project as the source and your DynamoDB project as the ta
 
 ## Generator Output
 
-The generator updates the MCP server's `<mcp-server-name>-serve-local` target in `project.json` to depend on the DynamoDB project's `serve-local` target. No source files are modified.
+The generator updates the MCP server's `<mcp-server-name>-dev` target in `project.json` to depend on the DynamoDB project's `dev` target. No source files are modified.
 
 ## Using DynamoDB in Tools
 

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

@@ -46,7 +46,7 @@ The generator modifies two files in your MCP server's source directory:
 
 </FileTree>
 
-Additionally, the `<mcp-server-name>-serve-local` target is updated to depend on the database's `serve-local` target.
+Additionally, the `<mcp-server-name>-dev` target is updated to depend on the database's `dev` target.
 
 ## How It Works
 
@@ -130,6 +130,6 @@ Ensure the MCP server's execution role has `rds-db:connect` permission and that
 
 ## Local Development
 
-<NxCommands commands={["<mcp-server-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<mcp-server-name>-dev <project-name>"]} />
 
-This starts the MCP server and all connected databases. The `SERVE_LOCAL=true` environment variable causes each Prisma client to connect to its local Docker database instead of Aurora.
+This starts the MCP server and all connected databases. The `LOCAL_DEV=true` environment variable causes each Prisma client to connect to its local Docker database instead of Aurora.

package/docs/guides/connection.mdx

@@ -211,5 +211,5 @@ The connection generator makes use of <Link path="guides/runtime-config">Runtime
 :::
 
 :::tip[Local Development]
-Connected projects can be run on your machine with the `serve` and `serve-local` targets. See the <Link path="guides/local-development">Local Development</Link> guide for details.
+Connected projects can be run on your machine with the `serve` and `dev` targets. See the <Link path="guides/local-development">Local Development</Link> guide for details.
 :::

package/docs/guides/fastapi.mdx

@@ -618,6 +618,12 @@ When using `Custom` auth, your API is protected by a Lambda Authorizer that **de
 <Snippet name="api/waf-configuration" parentHeading="WAF" />
 </OptionFilter>
 
+<OptionFilter when={{ infra: 'rest-lambda' }} description="Access logging — REST APIs log requests to CloudWatch by default">
+### Access logging
+
+<Snippet name="api/access-logging" parentHeading="Access logging" />
+</OptionFilter>
+
 ### Integrations
 
 <Snippet name="api/type-safe-api-integrations" parentHeading="Integrations" />

package/docs/guides/local-development.mdx

@@ -1,12 +1,12 @@
 ---
 title: Local Development
-description: How local development works with the serve and serve-local targets
+description: How local development works with the serve and dev targets
 ---
 import Link from '@components/link.astro';
 import NxCommands from '@components/nx-commands.astro';
 import PackageManagerShortCommand from '@components/package-manager-short-command.astro';
 
-Connected projects expose two targets for running them on your machine: `serve` and `serve-local`. The difference is one of **scope** — how much of your application runs locally versus pointing at deployed AWS infrastructure.
+Connected projects expose two targets for running them on your machine: `serve` and `dev`. The difference is one of **scope** — how much of your application runs locally versus pointing at deployed AWS infrastructure.
 
 Consider a workspace with the following connections: a website that calls a tRPC `api`, and also calls an `agent` which in turn calls an `mcp` server.
 
@@ -39,13 +39,13 @@ deployed.agent -> deployed.mcp
 
 Use `serve` when you want to iterate on a single project against the "real", deployed versions of everything it depends on.
 
-## `serve-local`
+## `dev`
 
-The `serve-local` target runs the **targeted project** and **every project connected to it transitively**, all on your machine. The connection generator wires this up automatically — running `serve-local` on the website also starts local servers for the `api`, the `agent`, and the `mcp` server it reaches through the agent.
+The `dev` target runs the **targeted project** and **every project connected to it transitively**, all on your machine. The connection generator wires this up automatically — running `dev` on the website also starts local servers for the `api`, the `agent`, and the `mcp` server it reaches through the agent.
 
-<NxCommands commands={['serve-local website']} />
+<NxCommands commands={['dev website']} />
 
-When run this way, the website's `runtime-config.json` is automatically overridden (via [Vite's `MODE`](https://vite.dev/guide/env-and-mode), set to `serve-local`) so that it points at your locally running servers instead of deployed URLs.
+When run this way, the website's `runtime-config.json` is automatically overridden (via [Vite's `MODE`](https://vite.dev/guide/env-and-mode), set to `local-dev`) so that it points at your locally running servers instead of deployed URLs.
 
 ```d2
 direction: right
@@ -65,10 +65,21 @@ local: Local {
 
 Every project runs locally, so there are no deployed dependencies.
 
-Use `serve-local` when you are working across several connected projects at once and want to iterate quickly without deploying your infrastructure.
+Use `dev` when you are working across several connected projects at once and want to iterate quickly without deploying your infrastructure.
 
-:::tip[`dev` shortcut]
-A root `dev` script is added as a shortcut for the first website you generate in your workspace, so you can spin up the website and all connected components with:
+### Projects with multiple components
+
+Some project types can hold multiple components in a single project (for example a TypeScript or Python project containing several agents and MCP servers). For these:
+
+- The project-level `dev` target starts **all** of the project's components together. Each component is added to `dev` as it is generated:
+
+<NxCommands commands={['dev my-project']} />
+- Each component also exposes a `<component-name>-dev` target, so you can run a single component on its own:
+
+<NxCommands commands={['my-component-dev my-project']} />
+
+:::tip[Workspace `dev` script]
+Your workspace's root `package.json` includes a `dev` script that runs `nx run-many --target dev`, starting the `dev` target for every project that has one. Spin up your whole workspace's local development servers with:
 
 <PackageManagerShortCommand commands={["dev"]} />
 :::

package/docs/guides/nx-generator.mdx

@@ -286,7 +286,7 @@ import { generateFiles, joinPathFragments } from '@nx/devkit';
 // Generate files from templates
 generateFiles(
   tree,
-  joinPathFragments(__dirname, 'files'), // Template directory
+  joinPathFragments(import.meta.dirname, 'files'), // Template directory
   'path/to/output', // Output directory
   {
     // Variables to replace in templates
@@ -459,7 +459,7 @@ export const myGenerator = async (tree: Tree, schema: MyGeneratorSchema) => {
 
   generateFiles(
     tree,
-    joinPathFragments(__dirname, 'files'), // Template directory
+    joinPathFragments(import.meta.dirname, 'files'), // Template directory
     'path/to/output', // Output directory
     data,
   );

package/docs/guides/py-agent.mdx

@@ -397,19 +397,23 @@ AG-UI agents are designed to be consumed directly by a frontend. Use the <Link p
 
 ### Local Development
 
-The generator configures a target named `<your-agent-name>-serve`, which starts your Agent locally for development and testing.
+To run your Agent (and everything connected to it) locally, use the project's `dev` target:
 
-<NxCommands commands={['agent-serve your-project']} />
+<NxCommands commands={['dev your-project']} />
 
-This command uses `uv run` to execute your Agent using the [Bedrock AgentCore Python SDK](https://github.com/aws/bedrock-agentcore-sdk-python).
+If you have added multiple components to your project (agents, MCP servers, etc.), this starts them all. To run just this agent, target its `<your-agent-name>-dev` target:
+
+<NxCommands commands={['agent-dev your-project']} />
+
+This uses `uv run` to execute your Agent using the [Bedrock AgentCore Python SDK](https://github.com/aws/bedrock-agentcore-sdk-python).
 
 ### Chat with Your Agent
 
 The generator configures a `<your-agent-name>-chat` Nx target that drops you into an interactive terminal chat with your agent.
 
-The chat target runs standalone. By default it connects to your locally running agent, so start `<your-agent-name>-serve-local` first (in a separate terminal):
+The chat target runs standalone. By default it connects to your locally running agent, so start the agent's `<your-agent-name>-dev` target first (in a separate terminal):
 
-<NxCommands commands={['run your-project:agent-serve-local']} />
+<NxCommands commands={['agent-dev your-project']} />
 
 Then, in another terminal, start the chat:
 

package/docs/guides/py-dynamodb.mdx

@@ -57,7 +57,7 @@ The local development scripts are shared across all DynamoDB projects (both Type
 
 ### Starting Local DynamoDB
 
-<Snippet name="dynamodb/serve-local-start" />
+<Snippet name="dynamodb/local-dev-start" />
 
 ### Data Modelling
 
@@ -406,8 +406,8 @@ For further reading on DynamoDB data modelling, see the [DynamoDB data modelling
 
 The generated `client.py` exports two key utilities:
 
-- `is_local()` — returns `True` when `SERVE_LOCAL=true`, used to switch between local and AWS behaviour.
-- `get_table_name()` — returns the DynamoDB table name. When `SERVE_LOCAL=true`, reads the table name from `serveLocal.tableName` in `config.json`; otherwise fetches the name from AWS AppConfig using the `RUNTIME_CONFIG_APP_ID` environment variable and caches it for subsequent calls.
+- `is_local()` — returns `True` when `LOCAL_DEV=true`, used to switch between local and AWS behaviour.
+- `get_table_name()` — returns the DynamoDB table name. When `LOCAL_DEV=true`, reads the table name from `localDev.tableName` in `config.json`; otherwise fetches the name from AWS AppConfig using the `RUNTIME_CONFIG_APP_ID` environment variable and caches it for subsequent calls.
 
 `BaseModel` in `entities/base.py` uses both to configure PynamoDB automatically:
 
@@ -416,7 +416,7 @@ The generated `client.py` exports two key utilities:
 
 ### Stopping Local DynamoDB
 
-<Snippet name="dynamodb/serve-local-windows" />
+<Snippet name="dynamodb/local-dev-windows" />
 
 ## Adding/Removing Global Secondary Indexes
 

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

@@ -117,9 +117,19 @@ def dynamic_resource(item_id: str) -> str:
 
 ## Running Your MCP Server
 
+### Local Development
+
+To run your MCP server (and everything connected to it, such as a local database) locally, use the project's `dev` target:
+
+<NxCommands commands={['dev your-project']} />
+
+If you have added multiple components to your project (MCP servers, agents, etc.), this starts them all. To run just this MCP server, target its `<your-server-name>-dev` target:
+
+<NxCommands commands={['your-server-name-dev your-project']} />
+
 ### Inspector
 
-The generator configures a target named `<your-server-name>-inspect`, which starts your MCP server locally (via the `<your-server-name>-serve-local` target, including any connected dependencies such as a local database) and launches the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) pre-configured to connect to it over Streamable HTTP transport.
+The generator configures a target named `<your-server-name>-inspect`, which starts your MCP server locally (via the `<your-server-name>-dev` target, including any connected dependencies such as a local database) and launches the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) pre-configured to connect to it over Streamable HTTP transport.
 
 <NxCommands commands={['your-server-name-inspect your-project']} />
 

package/docs/guides/react-website-auth.mdx

@@ -98,6 +98,42 @@ cognito -> iam
 browser -> backend: IAM/Cognito
 ```
 
+#### Threat protection
+
+The User Pool is created on the Cognito [Plus feature plan](https://docs.aws.amazon.com/cognito/latest/developerguide/feature-plans-features-plus.html) with [threat protection](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-threat-protection.html) set to `AUDIT` mode for standard authentication. In audit mode, Cognito assigns a risk level to each sign-in and logs the assessment to CloudWatch without blocking users.
+
+Once you have observed the risk assessments for your users, you can switch to full-function enforcement to automatically respond to risky activity (for example requiring MFA or blocking sign-in):
+
+<Infrastructure>
+<Fragment slot="cdk">
+Set `standardThreatProtectionMode` to `StandardThreatProtectionMode.FULL_FUNCTION` in `packages/common/constructs/src/core/user-identity.ts`.
+</Fragment>
+<Fragment slot="terraform">
+Set `advanced_security_mode` to `ENFORCED` in the `user_pool_add_ons` block in `packages/common/terraform/src/core/user-identity/identity/identity.tf`.
+</Fragment>
+</Infrastructure>
+
+#### Web Application Firewall (WAF)
+
+By default the User Pool is associated with an [AWS WAFv2](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) Web ACL using the `AWSManagedRulesCommonRuleSet` and `AWSManagedRulesKnownBadInputsRuleSet` managed rule groups. You can disable this if you wish to manage your own Web ACL or do not require one:
+
+<Infrastructure>
+<Fragment slot="cdk">
+```ts
+new UserIdentity(this, 'Identity', { enableWaf: false });
+```
+</Fragment>
+<Fragment slot="terraform">
+```hcl
+module "user_identity" {
+  source = "../../common/terraform/src/core/user-identity"
+
+  enable_waf = false
+}
+```
+</Fragment>
+</Infrastructure>
+
 ## Infrastructure Usage
 
 <Infrastructure>

package/docs/guides/react-website.mdx

@@ -18,12 +18,12 @@ import Infrastructure from '@components/infrastructure.astro';
 import Snippet from '@components/snippet.astro';
 import OptionFilter from '@components/option-filter.astro';
 
-This generator creates a new [React](https://react.dev/) website with [Cloudscape](http://cloudscape.design/) configured by default, along with the AWS CDK or Terraform infrastructure to deploy your website to the cloud as a static website hosted in [S3](https://aws.amazon.com/s3/), served by [CloudFront](https://aws.amazon.com/cloudfront/) and protected by [WAF](https://aws.amazon.com/waf/).
+This generator creates a new [React](https://react.dev/) website with [shadcn/ui](https://ui.shadcn.com/) configured by default, along with the AWS CDK or Terraform infrastructure to deploy your website to the cloud as a static website hosted in [S3](https://aws.amazon.com/s3/), served by [CloudFront](https://aws.amazon.com/cloudfront/) and protected by [WAF](https://aws.amazon.com/waf/).
 
 The generated application uses [Vite](https://vite.dev/) as the build tool and bundler. It uses [TanStack Router](https://tanstack.com/router/v1) for type-safe routing.
 
 :::note[UX Provider]
-The default `uxProvider` is [Cloudscape](http://cloudscape.design/). You can also select [shadcn/ui](https://ui.shadcn.com/) or `None` (bring your own component library).
+The default `uxProvider` is [shadcn/ui](https://ui.shadcn.com/). You can also select [Cloudscape](http://cloudscape.design/) or `None` (bring your own component library).
 :::
 
 ## Usage
@@ -301,7 +301,11 @@ For Terraform projects, the `load:runtime-config` target copies the `runtime-con
 
 ## Local Development Server
 
-You can run a local development server using either the `serve` or `serve-local` target.
+The canonical command for local development is `dev`, which starts your website (and any local servers for APIs you've connected it to) with one command:
+
+<NxCommands commands={['dev <my-website>']} />
+
+The `serve` target is also available for when you need to control how much of your application runs locally versus pointing at deployed AWS infrastructure. For a broader overview of local development across connected projects, including how `dev` behaves for projects with multiple components, see the <Link path="guides/local-development">Local Development</Link> guide.
 
 ### Serve Target
 
@@ -313,46 +317,50 @@ You can run this target with the following command:
 
 This target is useful for working on website changes while pointing to "real" deployed APIs and other infrastructure.
 
-### Serve Local Target
+### Dev Target
 
-The `serve-local` target starts a local development server for your website (with [Vite `MODE`](https://vite.dev/guide/env-and-mode) set to `serve-local`), as well as starting any local servers for APIs you have connected your website to via the <Link path="/guides/connection">Connection generator</Link>.
+The `dev` target starts a local development server for your website (with [Vite `MODE`](https://vite.dev/guide/env-and-mode) set to `local-dev`), as well as starting any local servers for APIs you have connected your website to via the <Link path="/guides/connection">Connection generator</Link>.
 
 When your local website server is run via this target, `runtime-config.json` is automatically overridden to point to your locally running API urls.
 
 You can run this target with the following command:
 
-<NxCommands commands={['serve-local <my-website>']} />
+<NxCommands commands={['dev <my-website>']} />
 
 This target is useful when you are working across your website and API and wish to quickly iterate without deploying your infrastructure.
 
-:::note[`dev` script]
-If no `dev` script exists in your root `package.json` when this generator runs, a `dev` script is added that invokes `serve-local` for the generated website, meaning you can also start the local development server with:
+:::note[Workspace `dev` script]
+Your workspace's root `package.json` includes a `dev` script that runs the `dev` target for every project that has one:
 
 <PackageManagerShortCommand commands={["dev"]} />
 
-This makes the first React website you generate the default `dev` target for the workspace. Subsequent websites do not overwrite the existing `dev` script — you can invoke their `serve-local` targets directly, or update the script manually.
+This starts the local development server for your website (and any other projects with a `dev` target) in one command. To run just this website, use its own `dev` target (e.g. `nx dev <my-website>`).
 :::
 
 :::warning[Mock Authentication]
 When run in this mode and no `runtime-config.json` is present, if you have configured Cognito Authentication (via the <Link path="/guides/react-website-auth">`ts#website#auth` generator</Link>), login will be skipped and requests to your local servers will not include authentication headers.
 
-To enable login and authentication for `serve-local`, deploy your infrastructure and load runtime config.
+To enable login and authentication for `dev`, deploy your infrastructure and load runtime config.
 :::
 
-:::tip[Serve-Local Behavior]
-When running with `serve-local`, you can specify any environment variables required by your APIs to point to other deployed AWS resources, for example:
+:::tip[Dev Behavior]
+When running with `dev`, you can specify any environment variables required by your APIs to point to other deployed AWS resources, for example:
 
-<NxCommands env={{DYNAMODB_TABLE_NAME: 'xxxxx'}} commands={['serve-local <my-website>']} />
+<NxCommands env={{DYNAMODB_TABLE_NAME: 'xxxxx'}} commands={['dev <my-website>']} />
 
 Note that your local API servers will run with the AWS credentials you have configured locally.
 :::
 
 ## Building
 
-You can build your website using the `build` target. This use Vite to create a production bundle in the root `dist/packages/<my-website>/bundle` directory, as well as type-checking, compiling and linting your website.
+You can build your website using the `build` target. This runs the `bundle`, `compile`, `test` and `lint` targets, type-checking, bundling, testing and linting your website.
 
 <NxCommands commands={['build <my-website>']} />
 
+The `bundle` target uses Vite to create a production bundle in the root `dist/packages/<my-website>/bundle` directory. This is the deployable artifact consumed by your website infrastructure. You can run it on its own:
+
+<NxCommands commands={['bundle <my-website>']} />
+
 ## Testing
 
 Testing your website is much like writing tests in a standard TypeScript project, so please refer to the <Link path="guides/typescript-project#testing">TypeScript project guide</Link> for more details.

package/docs/guides/trpc.mdx

@@ -728,6 +728,12 @@ When using `Custom` auth, your API is protected by a Lambda Authorizer that **de
 <Snippet name="api/waf-configuration" parentHeading="WAF" />
 </OptionFilter>
 
+<OptionFilter when={{ infra: 'rest-lambda' }} description="Access logging — REST APIs log requests to CloudWatch by default">
+### Access logging
+
+<Snippet name="api/access-logging" parentHeading="Access logging" />
+</OptionFilter>
+
 ### Integrations
 
 <Snippet name="api/type-safe-api-integrations" parentHeading="Integrations" />

package/docs/guides/ts-agent.mdx

@@ -263,19 +263,23 @@ Most users will not need to modify `index.ts` — edit `agent.ts` to change tool
 
 ### Local Development
 
-The generator configures a target named `<your-agent-name>-serve`, which starts your Agent locally for development and testing.
+To run your Agent (and everything connected to it) locally, use the project's `dev` target:
 
-<NxCommands commands={['agent-serve your-project']} />
+<NxCommands commands={['dev your-project']} />
 
-This command uses `tsx --watch` to automatically restart the server when files change. The agent will be available at `http://localhost:8081` (or the assigned port if you have multiple agents).
+If you have added multiple components to your project (agents, MCP servers, etc.), this starts them all. To run just this agent, target its `<your-agent-name>-dev` target:
+
+<NxCommands commands={['agent-dev your-project']} />
+
+This uses `tsx --watch` to automatically restart the server when files change. The agent will be available at `http://localhost:8081` (or the assigned port if you have multiple agents).
 
 ### Chat with Your Agent
 
 The generator configures a `<your-agent-name>-chat` Nx target that drops you into an interactive terminal chat with your agent.
 
-The chat target runs standalone. By default it connects to your locally running agent, so start `<your-agent-name>-serve-local` first (in a separate terminal):
+The chat target runs standalone. By default it connects to your locally running agent, so start the agent's `<your-agent-name>-dev` target first (in a separate terminal):
 
-<NxCommands commands={['run your-project:agent-serve-local']} />
+<NxCommands commands={['agent-dev your-project']} />
 
 Then, in another terminal, start the chat:
 

package/docs/guides/ts-dynamodb.mdx

@@ -56,7 +56,7 @@ The local development scripts are shared across all DynamoDB projects (both Type
 
 ### Starting Local DynamoDB
 
-<Snippet name="dynamodb/serve-local-start" />
+<Snippet name="dynamodb/local-dev-start" />
 
 ### Data Modelling
 
@@ -118,12 +118,12 @@ For more details, see the [ElectroDB entity documentation](https://electrodb.dev
 
 The generated `src/client.ts` exports two key utilities:
 
-- `getDynamoDBClient()` — returns a cached singleton `DynamoDBClient`. When `SERVE_LOCAL=true`, connects to the local DynamoDB Local instance; otherwise creates an AWS client using the default credential chain.
-- `resolveTableName()` — returns the DynamoDB table name. When `SERVE_LOCAL=true`, returns the local table name constant; otherwise fetches the name from AWS AppConfig using the `RUNTIME_CONFIG_APP_ID` environment variable and caches it for subsequent calls.
+- `getDynamoDBClient()` — returns a cached singleton `DynamoDBClient`. When `LOCAL_DEV=true`, connects to the local DynamoDB Local instance; otherwise creates an AWS client using the default credential chain.
+- `resolveTableName()` — returns the DynamoDB table name. When `LOCAL_DEV=true`, returns the local table name constant; otherwise fetches the name from AWS AppConfig using the `RUNTIME_CONFIG_APP_ID` environment variable and caches it for subsequent calls.
 
 ### Stopping Local DynamoDB
 
-<Snippet name="dynamodb/serve-local-windows" />
+<Snippet name="dynamodb/local-dev-windows" />
 
 ## Adding/Removing Global Secondary Indexes
 

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

@@ -122,9 +122,19 @@ server.registerResource('dynamic-resource', 'dynamic://resource', {}, async (uri
 
 ## Running Your MCP Server
 
+### Local Development
+
+To run your MCP server (and everything connected to it, such as a local database) locally, use the project's `dev` target:
+
+<NxCommands commands={['dev your-project']} />
+
+If you have added multiple components to your project (MCP servers, agents, etc.), this starts them all. To run just this MCP server, target its `<your-server-name>-dev` target:
+
+<NxCommands commands={['your-server-name-dev your-project']} />
+
 ### Inspector
 
-The generator configures a target named `<your-server-name>-inspect`, which starts your MCP server locally (via the `<your-server-name>-serve-local` target, including any connected dependencies such as a local database) and launches the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) pre-configured to connect to it over Streamable HTTP transport.
+The generator configures a target named `<your-server-name>-inspect`, which starts your MCP server locally (via the `<your-server-name>-dev` target, including any connected dependencies such as a local database) and launches the [MCP Inspector](https://github.com/modelcontextprotocol/inspector) pre-configured to connect to it over Streamable HTTP transport.
 
 <NxCommands commands={['your-server-name-inspect your-project']} />
 

package/docs/guides/ts-rdb.mdx

@@ -58,7 +58,8 @@ Local development scripts are shared across all database projects and generated
   - packages/common/scripts/src/rdb
     - pull-image.ts Pulls the database container image
     - start-container.ts Starts a local database container
-    - wait-for-db.ts Waits for the local database to be ready
+    - wait-for-postgres-db.ts Waits for the local database to be ready (PostgreSQL)
+    - wait-for-mysql-db.ts Waits for the local database to be ready (MySQL)
 </FileTree>
 
 ### Infrastructure
@@ -218,10 +219,10 @@ The generated `prisma` target exposes the Prisma CLI, so you can use it to run a
 
 ### Stopping the Local Database
 
-Stopping `serve-local` (e.g. with `Ctrl+C`) automatically removes the local database container, but preserves the named volume so your data persists across restarts.
+Stopping `dev` (e.g. with `Ctrl+C`) automatically removes the local database container, but preserves the named volume so your data persists across restarts.
 
 :::caution[Windows]
-Due to limitations with signal handling on Windows, the container is not automatically removed when `serve-local` is stopped. You will need to remove it manually:
+Due to limitations with signal handling on Windows, the container is not automatically removed when `dev` is stopped. You will need to remove it manually:
 
 ```bash
 <engine> rm -f <scope>-<db-name>
@@ -537,7 +538,7 @@ Pin a specific Aurora engine version.
 
 By default, the generated local database container image matches the default Aurora engine version. If you change the Aurora engine version, it's recommended to also use a matching local container image version for maximum compatibility. See the AWS release notes for [Aurora PostgreSQL versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html) and [Aurora MySQL versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html) to identify the corresponding community database version.
 
-The local database image is configured in the `serveLocal.image` field of the generated `config.json` file in your database project root. Update that value when you change engine versions.
+The local database image is configured in the `localDev.image` field of the generated `config.json` file in your database project root. Update that value when you change engine versions.
 
 <OptionFilter when={{ engine: 'postgres' }}>
 <Infrastructure>

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

@@ -730,6 +730,10 @@ output "lambda_function_name" {
 
 <Snippet name="api/waf-configuration" parentHeading="WAF" />
 
+### Access logging
+
+<Snippet name="api/access-logging" parentHeading="Access logging" />
+
 ### Integrations
 
 <Snippet name="api/type-safe-api-integrations" parentHeading="Integrations" />

package/docs/guides/typescript-infrastructure.mdx

@@ -286,7 +286,7 @@ export class ApplicationStack extends Stack {
 
 ### Website Infrastructure
 
-If you have used the <Link path="guides/react-website">CloudScape website</Link> generator, you will notice you already have a construct in `packages/common/constructs` to deploy it. For example:
+If you have used the <Link path="guides/react-website">React Website</Link> generator, you will notice you already have a construct in `packages/common/constructs` to deploy it. For example:
 
 ```ts title="src/stacks/application-stack.ts" {3, 9-10}
 import { Stack, StackProps } from 'aws-cdk-lib';

package/docs/snippets/api/access-logging.mdx

@@ -0,0 +1,33 @@
+---
+title: Access logging
+---
+import Infrastructure from '@components/infrastructure.astro';
+
+For REST APIs, the generated infrastructure enables [access logging](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html) by default, writing one structured JSON line per request to a dedicated CloudWatch Logs group. The log group is encrypted with a customer-managed KMS key and retained for one year.
+
+API Gateway writes access logs using an account-level CloudWatch Logs role. This role is configured on the `AWS::ApiGateway::Account` setting, which is a **singleton per region per account** — there is only one role for every REST API in the region. To manage this safely across multiple independently-deployed stacks, the generated infrastructure:
+
+- Creates a shared CloudWatch Logs role and configures it on the account only when no working role is already set, so deployments never overwrite a role another stack owns.
+- Leaves the account setting untouched on teardown, so destroying one stack never disables logging for other REST APIs in the region.
+
+<Infrastructure>
+<Fragment slot="cdk">
+The account role is managed by the `ApiGatewayAccount` construct, a stack-scoped singleton resolved via `ApiGatewayAccount.ensure(scope)`. Each REST API's stage depends on it, and the role is configured by a Lambda-backed custom resource.
+
+You can customise the access log format by passing `deployOptions` when constructing your API:
+
+```ts {3-5}
+const api = new MyApi(this, 'MyApi', {
+  integrations: MyApi.defaultIntegrations(this).build(),
+  deployOptions: {
+    accessLogFormat: AccessLogFormat.clf(),
+  },
+});
+```
+</Fragment>
+<Fragment slot="terraform">
+The account role is managed by the `core/api/api-gateway-account` module, which is instantiated by the generated API module. It configures the account idempotently and is never reset on `terraform destroy`.
+
+You can customise the access log format by editing the `access_log_settings` block on the `aws_api_gateway_stage` resource in the generated API module.
+</Fragment>
+</Infrastructure>

package/docs/snippets/connection/dynamodb-local-development.mdx

@@ -2,6 +2,6 @@
 title: DynamoDB Local Development
 ---
 
-The `connection` generator configures your project's `serve-local` target to depend on the DynamoDB project's `serve-local` target. DynamoDB Local will start automatically alongside your project when running `serve-local`.
+The `connection` generator configures your project's `dev` target to depend on the DynamoDB project's `dev` target. DynamoDB Local will start automatically alongside your project when running `dev`.
 
-The `SERVE_LOCAL=true` environment variable is set automatically, so `getDynamoDBClient()` and `resolveTableName()` connect to the local DynamoDB Local instance instead of AWS.
+The `LOCAL_DEV=true` environment variable is set automatically, so `getDynamoDBClient()` and `resolveTableName()` connect to the local DynamoDB Local instance instead of AWS.

package/docs/snippets/connection/py-dynamodb-local-development.mdx

@@ -2,6 +2,6 @@
 title: Python DynamoDB Local Development
 ---
 
-The `connection` generator configures your project's `serve-local` target to depend on the DynamoDB project's `serve-local` target. DynamoDB Local will start automatically alongside your project when running `serve-local`.
+The `connection` generator configures your project's `dev` target to depend on the DynamoDB project's `dev` target. DynamoDB Local will start automatically alongside your project when running `dev`.
 
-The `SERVE_LOCAL=true` environment variable is set automatically, so `is_local()` returns `True` and your PynamoDB entities connect to the local DynamoDB instance instead of AWS.
+The `LOCAL_DEV=true` environment variable is set automatically, so `is_local()` returns `True` and your PynamoDB entities connect to the local DynamoDB instance instead of AWS.

package/docs/snippets/dynamodb/gsi-config.mdx

@@ -25,7 +25,7 @@ title: GSI Configuration
 The `sortKey` field is optional for hash-key-only GSIs.
 
 This config file is the single source of truth read by all consumers:
-- **Local development** — `serve-local` reads `config.json` and creates or updates the local table to match the GSI list
+- **Local development** — `dev` reads `config.json` and creates or updates the local table to match the GSI list
 - **CDK** — the construct reads `config.json` at synth time, so GSI changes are reflected on the next `cdk deploy`
 - **Terraform** — the module reads `config.json` at plan/apply time
 

package/docs/snippets/dynamodb/local-dev-start.mdx

@@ -0,0 +1,13 @@
+---
+title: Starting Local DynamoDB
+---
+import NxCommands from '@components/nx-commands.astro';
+
+The generator configures a `dev` target that starts a [DynamoDB Local](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) instance and creates the table. Use the project's `dev` target:
+
+<NxCommands commands={['dev <project-name>']} />
+
+This automatically:
+1. Pulls the DynamoDB Local image (`pull-image` target)
+2. Starts a container
+3. Creates a local table with the indexes defined in `config.json`

package/docs/snippets/dynamodb/local-dev-windows.mdx

@@ -0,0 +1,15 @@
+---
+title: Local Development Windows Caution
+---
+
+Stopping `dev` (e.g. with `Ctrl+C`) automatically removes the DynamoDB Local container, but preserves the named volume so your data persists across restarts.
+
+:::caution[Windows]
+Due to limitations with signal handling on Windows, the container is not automatically removed when `dev` is stopped. You will need to remove it manually:
+
+```bash
+<engine> rm -f <scope>-dynamodb
+```
+
+Replace `<engine>` with your container engine (`docker` or `finch`) and `<scope>` with your Nx workspace scope (e.g. `proj`).
+:::