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

package/bin/aws-nx-mcp.js

@@ -35,12 +35,12 @@ var __toESM$1 = (mod, isNodeMode, target) => (target = mod != null ? __create$1(
 let node_process = require("node:process");
 node_process = __toESM$1(node_process, 1);
 let path = require("path");
+let path$3 = __toESM$1(path, 1);
 path = __toESM$1(path);
 let fs = require("fs");
-fs = __toESM$1(fs);
+fs = __toESM$1(fs, 1);
 let node_path = require("node:path");
-let node_path$1 = __toESM$1(node_path, 1);
-node_path = __toESM$1(node_path);
+node_path = __toESM$1(node_path, 1);
 let node_url = require("node:url");
 //#region ../../node_modules/.pnpm/zod@4.4.3/node_modules/zod/v4/core/core.js
 var _a$1;
@@ -20203,8 +20203,8 @@ var generators$1 = {
 const buildGeneratorInfoList = (baseDir) => Object.entries(generators$1).map(([id, info]) => ({
 	id,
 	metric: info.metric,
-	resolvedFactoryPath: path.resolve(baseDir, info.factory),
-	resolvedSchemaPath: path.resolve(baseDir, info.schema),
+	resolvedFactoryPath: path$3.resolve(baseDir, info.factory),
+	resolvedSchemaPath: path$3.resolve(baseDir, info.schema),
 	description: info.description,
 	..."hidden" in info && info.hidden ? { hidden: info.hidden } : {},
 	..."guidePages" in info && info.guidePages ? { guidePages: info.guidePages } : {}
@@ -21338,7 +21338,7 @@ var require_lodash_deburr = /* @__PURE__ */ __commonJSMin$1(((exports, module) =
 	module.exports = deburr;
 }));
 require_lodash_camelcase();
-var import_lodash_deburr = /* @__PURE__ */ __toESM$1(require_lodash_deburr());
+var import_lodash_deburr = /* @__PURE__ */ __toESM$1(require_lodash_deburr(), 1);
 const kebabCase = (str) => {
 	return (0, import_lodash_deburr.default)(str).replace(/[^a-zA-Z0-9]+/g, "-").replace(/([a-z0-9])([A-Z])/g, "$1-$2").toLowerCase().replace(/^-+|-+$/g, "");
 };
@@ -24471,7 +24471,7 @@ var init_minurl = __esmMin((() => {
 *   Nothing.
 */
 function assertPart(part, name) {
-	if (part && part.includes(node_path$1.default.sep)) throw new Error("`" + name + "` cannot be a path: did not expect `" + node_path$1.default.sep + "`");
+	if (part && part.includes(node_path.default.sep)) throw new Error("`" + name + "` cannot be a path: did not expect `" + node_path.default.sep + "`");
 }
 /**
 * Assert that `part` is not empty.
@@ -24631,7 +24631,7 @@ var init_lib$23 = __esmMin((() => {
 		*   Basename.
 		*/
 		get basename() {
-			return typeof this.path === "string" ? node_path$1.default.basename(this.path) : void 0;
+			return typeof this.path === "string" ? node_path.default.basename(this.path) : void 0;
 		}
 		/**
 		* Set basename (including extname) (`'index.min.js'`).
@@ -24648,7 +24648,7 @@ var init_lib$23 = __esmMin((() => {
 		set basename(basename) {
 			assertNonEmpty(basename, "basename");
 			assertPart(basename, "basename");
-			this.path = node_path$1.default.join(this.dirname || "", basename);
+			this.path = node_path.default.join(this.dirname || "", basename);
 		}
 		/**
 		* Get the parent path (example: `'~'`).
@@ -24657,7 +24657,7 @@ var init_lib$23 = __esmMin((() => {
 		*   Dirname.
 		*/
 		get dirname() {
-			return typeof this.path === "string" ? node_path$1.default.dirname(this.path) : void 0;
+			return typeof this.path === "string" ? node_path.default.dirname(this.path) : void 0;
 		}
 		/**
 		* Set the parent path (example: `'~'`).
@@ -24671,7 +24671,7 @@ var init_lib$23 = __esmMin((() => {
 		*/
 		set dirname(dirname) {
 			assertPath(this.basename, "dirname");
-			this.path = node_path$1.default.join(dirname || "", this.basename);
+			this.path = node_path.default.join(dirname || "", this.basename);
 		}
 		/**
 		* Get the extname (including dot) (example: `'.js'`).
@@ -24680,7 +24680,7 @@ var init_lib$23 = __esmMin((() => {
 		*   Extname.
 		*/
 		get extname() {
-			return typeof this.path === "string" ? node_path$1.default.extname(this.path) : void 0;
+			return typeof this.path === "string" ? node_path.default.extname(this.path) : void 0;
 		}
 		/**
 		* Set the extname (including dot) (example: `'.js'`).
@@ -24701,7 +24701,7 @@ var init_lib$23 = __esmMin((() => {
 				if (extname.codePointAt(0) !== 46) throw new Error("`extname` must start with `.`");
 				if (extname.includes(".", 1)) throw new Error("`extname` cannot contain multiple dots");
 			}
-			this.path = node_path$1.default.join(this.dirname, this.stem + (extname || ""));
+			this.path = node_path.default.join(this.dirname, this.stem + (extname || ""));
 		}
 		/**
 		* Get the full path (example: `'~/index.min.js'`).
@@ -24736,7 +24736,7 @@ var init_lib$23 = __esmMin((() => {
 		*   Stem.
 		*/
 		get stem() {
-			return typeof this.path === "string" ? node_path$1.default.basename(this.path, this.extname) : void 0;
+			return typeof this.path === "string" ? node_path.default.basename(this.path, this.extname) : void 0;
 		}
 		/**
 		* Set the stem (basename w/o extname) (example: `'index.min'`).
@@ -24753,7 +24753,7 @@ var init_lib$23 = __esmMin((() => {
 		set stem(stem) {
 			assertNonEmpty(stem, "stem");
 			assertPart(stem, "stem");
-			this.path = node_path$1.default.join(this.dirname || "", stem + (this.extname || ""));
+			this.path = node_path.default.join(this.dirname || "", stem + (this.extname || ""));
 		}
 		/**
 		* Create a fatal message for `reason` associated with the file.
@@ -53912,7 +53912,7 @@ const GUIDES_RELATIVE_PROBES = [
 ];
 const fetchLocalGuide = (guide) => {
 	for (const rel of GUIDES_RELATIVE_PROBES) {
-		const candidate = path.default.resolve(__dirname, rel, `${guide}.mdx`);
+		const candidate = path$3.default.resolve(__dirname, rel, `${guide}.mdx`);
 		try {
 			if (fs.default.existsSync(candidate)) return fs.default.readFileSync(candidate, "utf-8");
 		} catch {}
@@ -53935,7 +53935,7 @@ const SNIPPETS_RELATIVE_PROBES = [
 */
 const fetchSnippet = async (snippetName) => {
 	for (const rel of SNIPPETS_RELATIVE_PROBES) {
-		const candidate = path.default.resolve(__dirname, rel, `${snippetName}.mdx`);
+		const candidate = path$3.default.resolve(__dirname, rel, `${snippetName}.mdx`);
 		try {
 			if (fs.default.existsSync(candidate)) return fs.default.readFileSync(candidate, "utf-8");
 		} catch {}

package/docs/guides/agentcore-gateway.mdx

@@ -36,8 +36,8 @@ The generator creates a new project at `packages/<name>/`, plus a CDK construct
     - policies/ Cedar policy source files (omitted when `cedarPolicy: false`)
       - permit-all.cedar Default Cedar policy that permits authenticated callers from within the same AWS account
       - README.md Reference for writing Cedar policies
-    - serve-local.ts Local gateway aggregating attached MCP servers for local development
-    - project.json Adds the \<name>-serve and \<name>-serve-local aggregator targets
+    - local-dev.ts Local gateway aggregating attached MCP servers for local development
+    - project.json Adds the `serve` and `dev` targets
 </FileTree>
 
 ### Infrastructure
@@ -228,9 +228,9 @@ This denies the Python agent role from calling `ts-mcp___divide` while leaving t
 
 ## Local Development
 
-The generator adds a `<name>-serve-local` target to the Gateway project, which runs `serve-local.ts`: a local gateway exposing a single MCP endpoint that aggregates every attached MCP server (connected via the <Link path="guides/connection/agentcore-gateway-mcp">`agentcore-gateway#mcp-connection` generator</Link>), with tools prefixed `<target>___<tool>` to match the deployed Gateway. Running it starts the local gateway and all attached MCP servers together.
+The generator adds a `dev` target to the Gateway project, which runs `local-dev.ts`: a local gateway exposing a single MCP endpoint that aggregates every attached MCP server (connected via the <Link path="guides/connection/agentcore-gateway-mcp">`agentcore-gateway#mcp-connection` generator</Link>), with tools prefixed `<target>___<tool>` to match the deployed Gateway. Running it starts the local gateway and all attached MCP servers together:
 
-<NxCommands commands={["<name>-serve-local"]} />
+<NxCommands commands={["dev <name>"]} />
 
 See the connection guide for the full local development story.
 

package/docs/guides/connection/agentcore-gateway-gateway.mdx

@@ -43,12 +43,12 @@ The generator wires existing projects together rather than emitting new source f
 <FileTree>
 
 - packages/\<source-gateway>
-  - project.json `<source-gateway>-serve-local` gains a dependency on the target gateway's `<target-gateway>-serve-local`
-  - serve-local.ts `ATTACHED_MCP_SERVERS` updated so the local gateway aggregates the target gateway
+  - project.json the source Gateway's `dev` target gains a dependency on the target gateway's `dev` target
+  - local-dev.ts `ATTACHED_MCP_SERVERS` updated so the local gateway aggregates the target gateway
 
 </FileTree>
 
-The source Gateway project's `<source-gateway>-serve-local` target gains a dependency on the target Gateway's `<target-gateway>-serve-local` target, so running the source Gateway locally also starts the target gateway (and, transitively, every MCP server attached to it). The target gateway is also registered in the source Gateway project's `serve-local.ts` so the local gateway aggregates its tools.
+The source Gateway project's `dev` target gains a dependency on the target Gateway's `dev` target, so running the source Gateway locally also starts the target gateway (and, transitively, every MCP server attached to it). The target gateway is also registered in the source Gateway project's `local-dev.ts` so the local gateway aggregates its tools.
 
 ## Adding the gateway target to your stack
 
@@ -145,7 +145,7 @@ This means a tool call through a gateway chain must be permitted at every hop. T
 
 Running the source Gateway locally with:
 
-<NxCommands commands={["<source-gateway-name>-serve-local"]} />
+<NxCommands commands={["dev <source-gateway-name>"]} />
 
 starts the local source gateway, the local target gateway, and every MCP server attached to either, each on its assigned local port. Tool names are prefixed at each hop exactly as deployed (`<gateway-target-name>___<target-name>___<tool-name>`), so agent prompts and Cedar action names remain consistent across local and deployed runs.
 

package/docs/guides/connection/agentcore-gateway-mcp.mdx

@@ -46,12 +46,12 @@ The generator wires existing projects together rather than emitting new source f
 <FileTree>
 
 - packages/\<gateway>
-  - project.json `<gateway>-serve-local` gains a dependency on the MCP server's `<mcp>-serve-local`
-  - serve-local.ts `ATTACHED_MCP_SERVERS` updated so the local gateway aggregates the MCP server
+  - project.json the Gateway's `dev` target gains a dependency on the MCP server's `<mcp>-dev`
+  - local-dev.ts `ATTACHED_MCP_SERVERS` updated so the local gateway aggregates the MCP server
 
 </FileTree>
 
-The Gateway project's `<gateway>-serve-local` target gains a dependency on the MCP server's `<mcp>-serve-local` target, so running the Gateway locally also starts the MCP server. The MCP server is also registered in the Gateway project's `serve-local.ts` so the local gateway aggregates its tools.
+The Gateway project's `dev` target gains a dependency on the MCP server's `<mcp>-dev` target, so running the Gateway locally also starts the MCP server. The MCP server is also registered in the Gateway project's `local-dev.ts` so the local gateway aggregates its tools.
 
 ## Adding the MCP server target to your stack
 
@@ -123,9 +123,9 @@ The target `name` (`my-mcp-server` above) is used as the prefix for Cedar action
 
 Running the Gateway locally with:
 
-<NxCommands commands={["<gateway-name>-serve-local"]} />
+<NxCommands commands={["dev <gateway-name>"]} />
 
-starts a local gateway plus every attached MCP server on its assigned local port. The local gateway exposes a single MCP endpoint that aggregates the attached servers' tools. Agents connected to the Gateway via the <Link path="guides/connection/ts-agent-gateway">TypeScript</Link> or <Link path="guides/connection/py-agent-gateway">Python</Link> gateway-connection generators point at it when running with `SERVE_LOCAL=true`.
+starts a local gateway plus every attached MCP server on its assigned local port. The local gateway exposes a single MCP endpoint that aggregates the attached servers' tools. Agents connected to the Gateway via the <Link path="guides/connection/ts-agent-gateway">TypeScript</Link> or <Link path="guides/connection/py-agent-gateway">Python</Link> gateway-connection generators point at it when running with `LOCAL_DEV=true`.
 
 :::caution[Local fidelity]
 Local development uses a **local stand-in gateway** — a lightweight MCP aggregator started by the Gateway project, not the AgentCore Gateway service. As a consequence, **Cedar policies are not evaluated locally**. Every agent sees every tool on every attached MCP server. To exercise Cedar policies, run the agent's `serve` target instead (see the <Link path="guides/connection/ts-agent-gateway">TypeScript</Link> / <Link path="guides/connection/py-agent-gateway">Python</Link> agent-connection guides) so the locally-running agent calls the deployed Gateway.

package/docs/guides/connection/py-agent-a2a.mdx

@@ -62,7 +62,7 @@ The client suffix matches your agent's framework (`_strands` or `_langchain`). B
 Additionally, the generator:
 - Transforms your agent's `agent.py` to register the remote A2A agent as a tool using `@tool`
 - Adds the `agent_connection` project as a workspace dependency of your agent project
-- Updates the agent's `serve-local` target to depend on the target agent's `serve-local` target
+- Updates the agent's `dev` target to depend on the target agent's `dev` target
 
 ## Using the Connected A2A Agent
 
@@ -116,7 +116,7 @@ def get_agent():
 </TabItem>
 </Tabs>
 
-Both clients are directly callable, returning the remote agent's reply, and wrap an `httpx.AsyncClient` that signs requests with SigV4 when deployed to AWS and uses a plain `http://localhost:<port>/` endpoint when `SERVE_LOCAL=true`. The Strands client wraps a Strands `A2AAgent`; the LangChain client drives the a2a SDK directly.
+Both clients are directly callable, returning the remote agent's reply, and wrap an `httpx.AsyncClient` that signs requests with SigV4 when deployed to AWS and uses a plain `http://localhost:<port>/` endpoint when `LOCAL_DEV=true`. The Strands client wraps a Strands `A2AAgent`; the LangChain client drives the a2a SDK directly.
 
 The AgentCore session ID is propagated to the remote agent automatically via the `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id` header, regardless of framework: the agent server binds the inbound request's session into an async context, and the connection client's signed `httpx.Auth` stamps it on every outbound call — ensuring consistency for [Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html).
 
@@ -126,12 +126,12 @@ The AgentCore session ID is propagated to the remote agent automatically via the
 
 ## Local Development
 
-The generator configures the host agent's `serve-local` target to:
+The generator configures the host agent's `dev` target to:
 1. Start the connected A2A agent(s) automatically
-2. Set `SERVE_LOCAL=true` so the generated client connects directly to `http://localhost:<port>/` instead of AgentCore
+2. Set `LOCAL_DEV=true` so the generated client connects directly to `http://localhost:<port>/` instead of AgentCore
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
 This will start both the host agent and all connected A2A agents, with the host agent calling the remote agents over plain HTTP on their assigned local ports.

package/docs/guides/connection/py-agent-dynamodb.mdx

@@ -34,7 +34,7 @@ Select your Agent project as the source and your DynamoDB project as the target.
 
 ## Generator Output
 
-The generator updates the agent's `<agent-name>-serve-local` target in `project.json` to depend on the DynamoDB project's `serve-local` target, and adds the DynamoDB package as a workspace dependency. No source files are modified.
+The generator updates the agent's `<agent-name>-dev` target in `project.json` to depend on the DynamoDB project's `dev` target, and adds the DynamoDB package as a workspace dependency. No source files are modified.
 
 ## Using DynamoDB in Agents
 

package/docs/guides/connection/py-agent-gateway.mdx

@@ -60,7 +60,7 @@ Additionally, the generator:
 
 - Modifies your agent's `agent.py` to import the Gateway client and register its tools in `tools`
 - Adds `agent_connection` as a workspace dependency of the agent
-- Wires the agent's `<agent>-serve-local` target to depend on the Gateway's `<gateway>-serve-local` aggregator
+- Wires the agent's `<agent>-dev` target to depend on the Gateway's `dev` target
 
 ## Using the connected Gateway
 
@@ -110,8 +110,8 @@ def get_agent():
 
 In both cases the client behaves the same way per mode:
 
-- **Deployed mode** (`SERVE_LOCAL` unset): tools pointed at the Gateway's MCP endpoint, SigV4-signed.
-- **Local mode** (`SERVE_LOCAL=true`): plain-HTTP tools pointed at the local gateway started by the Gateway project's `serve-local` target.
+- **Deployed mode** (`LOCAL_DEV` unset): tools pointed at the Gateway's MCP endpoint, SigV4-signed.
+- **Local mode** (`LOCAL_DEV=true`): plain-HTTP tools pointed at the local gateway started by the Gateway project's `dev` target.
 
 The session ID is propagated to downstream MCP servers automatically via the `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id` header.
 
@@ -166,16 +166,16 @@ The Gateway URL is automatically registered in the `agentcore.gateways.<ClassNam
 
 ## Local Development
 
-The generator configures the agent's `serve-local` target to:
+The generator configures the agent's `dev` target to:
 
 1. Start the connected Gateway's local gateway and every attached MCP server
-2. Set `SERVE_LOCAL=true` so the generated client points at the local gateway instead of the deployed Gateway
+2. Set `LOCAL_DEV=true` so the generated client points at the local gateway instead of the deployed Gateway
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
-To run the agent locally **against the deployed Gateway** instead (for example, to exercise Cedar policies), use the agent's `serve` target. Without `SERVE_LOCAL` set, the client resolves the deployed Gateway URL from runtime configuration and SigV4-signs requests with your local AWS credentials:
+To run the agent locally **against the deployed Gateway** instead (for example, to exercise Cedar policies), use the agent's `serve` target. Without `LOCAL_DEV` set, the client resolves the deployed Gateway URL from runtime configuration and SigV4-signs requests with your local AWS credentials:
 
 <NxCommands commands={["<agent-name>-serve <project-name>"]} />
 

package/docs/guides/connection/py-agent-mcp.mdx

@@ -62,7 +62,7 @@ The client suffix matches your agent's framework (`_strands` or `_langchain`).
 Additionally, the generator:
 - Transforms your agent's `agent.py` to import and use the MCP server's tools via a class-based client
 - Adds the `agent_connection` project as a workspace dependency of your agent project
-- Updates the agent's `serve-local` target to depend on the MCP server's serve target
+- Updates the agent's `dev` target to depend on the MCP server's serve target
 
 ## Using the Connected MCP Server
 
@@ -165,12 +165,12 @@ The MCP server's AgentCore runtime ARN is automatically registered in the `agent
 
 ## Local Development
 
-The generator configures the agent's `serve-local` target to:
+The generator configures the agent's `dev` target to:
 1. Start the connected MCP server(s) automatically
-2. Set `SERVE_LOCAL=true` so the generated client uses direct HTTP transport instead of AgentCore
+2. Set `LOCAL_DEV=true` so the generated client uses direct HTTP transport instead of AgentCore
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
 This will start both the agent and all connected MCP servers, with the agent connecting to the MCP servers directly via HTTP on their assigned local ports.

package/docs/guides/connection/py-fast-api-dynamodb.mdx

@@ -33,7 +33,7 @@ Select your FastAPI project as the source and your DynamoDB project as the targe
 
 ## Generator Output
 
-The generator updates the FastAPI's `project.json` to add a dependency from its `serve-local` target to the DynamoDB project's `serve-local` target, and adds the DynamoDB package as a workspace dependency. No source files are modified.
+The generator updates the FastAPI's `project.json` to add a dependency from its `dev` target to the DynamoDB project's `dev` target, and adds the DynamoDB package as a workspace dependency. No source files are modified.
 
 ## Using DynamoDB in Route Handlers
 

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

@@ -34,7 +34,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, and adds the DynamoDB package as a workspace dependency. 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, and adds the DynamoDB package as a workspace dependency. No source files are modified.
 
 ## Using DynamoDB in Tools
 

package/docs/guides/connection/react-agui.mdx

@@ -71,7 +71,7 @@ The following dependencies are added to the root `package.json`:
 Each `useAgui<AgentName>` hook reads its agent's runtime value from <Link path="guides/runtime-config">Runtime Configuration</Link> and instantiates an `@ag-ui/client` `HttpAgent`:
 
 - **Deployed**: the runtime value is a Bedrock AgentCore Runtime ARN, which is converted to the AgentCore HTTPS endpoint: `https://bedrock-agentcore.<region>.amazonaws.com/runtimes/<encoded-arn>/invocations?qualifier=DEFAULT`
-- **Local development**: `serve-local` overrides the value to the agent's local URL (e.g. `http://localhost:8081`)
+- **Local development**: `dev` overrides the value to the agent's local URL (e.g. `http://localhost:8081`)
 
 The shared `AguiProvider` calls every generated hook and spreads each one into `selfManagedAgents` on a single `CopilotKitProvider`, which exposes them all to CopilotKit components.
 
@@ -218,13 +218,13 @@ Deeper overrides follow the same shape — e.g. replace just the copy button on
 
 ## Local Development
 
-The connection generator automatically configures `serve-local` integration:
+The connection generator automatically configures `dev` integration:
 
-1. Running `nx serve-local <website>` will also start the agent's local server
+1. Running `nx dev <website>` will also start the agent's local server
 2. The runtime config is overridden to point to the local AG-UI URL (e.g. `http://localhost:8081`)
 3. Both the website and the agent hot-reload together
 
-<NxCommands commands={['serve-local <WebsiteProject>']} />
+<NxCommands commands={['dev <WebsiteProject>']} />
 
 :::tip[Hot Reloading]
 The website and connected agent hot-reload together, enabling you to quickly iterate on both sides without deploying to AWS.

package/docs/guides/connection/react-fastapi.mdx

@@ -115,9 +115,9 @@ Whenever you make changes to your FastAPI, you need to rebuild your project in o
 :::
 
 :::tip[Auto-Regeneration]
-If you're actively working on both your React application and FastAPI together, use the React application's `serve-local` target which will automatically regenerate the client whenever your API changes, as well as hot-reloading your website and local FastAPI server:
+If you're actively working on both your React application and FastAPI together, use the React application's `dev` target which will automatically regenerate the client whenever your API changes, as well as hot-reloading your website and local FastAPI server:
 
-<NxCommands commands={['serve-local <WebsiteProject>']} />
+<NxCommands commands={['dev <WebsiteProject>']} />
 
 For more fine-grained control, you can use the `watch-generate:<ApiName>-client` target for your React application to regenerate the client every time you make API changes:
 

package/docs/guides/connection/react-py-agent.mdx

@@ -177,13 +177,13 @@ function ChatComponent() {
 
 ## Local Development
 
-The connection generator automatically configures `serve-local` integration:
+The connection generator automatically configures `dev` integration:
 
-1. Running `nx serve-local <website>` will also start the agent's local FastAPI server
+1. Running `nx dev <website>` will also start the agent's local FastAPI server
 2. The runtime config is overridden to point to the local HTTP URL (e.g., `http://localhost:8081/`)
 3. The TypeScript client is automatically regenerated when the agent's API changes
 
-<NxCommands commands={['serve-local <WebsiteProject>']} />
+<NxCommands commands={['dev <WebsiteProject>']} />
 
 :::tip[Hot Reloading]
 The website and connected agent will hot-reload, enabling you to quickly iterate on both together without deploying to AWS.

package/docs/guides/connection/react-smithy.mdx

@@ -116,9 +116,9 @@ Whenever you make changes to your Smithy API model, you need to rebuild your pro
 :::
 
 :::tip[Auto-Regeneration]
-If you're actively working on both your React application and Smithy API together, use the React application's `serve-local` target which will automatically regenerate the client whenever your API changes, as well as hot-reloading your website and local Smithy API server:
+If you're actively working on both your React application and Smithy API together, use the React application's `dev` target which will automatically regenerate the client whenever your API changes, as well as hot-reloading your website and local Smithy API server:
 
-<NxCommands commands={['serve-local <WebsiteProject>']} />
+<NxCommands commands={['dev <WebsiteProject>']} />
 
 For more fine-grained control, you can use the `watch-generate:<ApiName>-client` target for your React application to regenerate the client every time you make API changes:
 

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

@@ -64,13 +64,13 @@ Additionally, it installs the required dependencies:
 The generated client connects to your Agent via tRPC over WebSocket. The agent exposes a tRPC router (including the `invoke` subscription for streaming agent responses) over a WebSocket endpoint.
 
 - **Deployed**: The agent runtime ARN is loaded from <Link path="guides/runtime-config">Runtime Configuration</Link>. Running this connection generator also patches the agent's generated CDK/Terraform construct to publish its ARN to the website's `runtime-config.json` (under the `connection` namespace), so only agents you explicitly connect are exposed to the frontend. The ARN is converted to a WebSocket URL following the Bedrock AgentCore Runtime WebSocket protocol: `wss://bedrock-agentcore.<region>.amazonaws.com/runtimes/<encoded-arn>/ws`
-- **Local development**: When running with `serve-local`, the runtime config override sets the value to a local `ws://` URL (e.g., `ws://localhost:8081/ws`), and the client connects directly
+- **Local development**: When running with `dev`, the runtime config override sets the value to a local `ws://` URL (e.g., `ws://localhost:8081/ws`), and the client connects directly
 
 ### Authentication
 
 The generated code handles authentication depending on your agent's configuration:
 
-- **IAM** (default): Uses AWS SigV4 presigned URLs to authenticate the WebSocket connection. Credentials are obtained from the Cognito Identity Pool configured with your website's auth. In `serve-local` mode, signing is automatically skipped when <Link path="guides/react-website#runtime-configuration">`runtime-config.json`</Link> is not present
+- **IAM** (default): Uses AWS SigV4 presigned URLs to authenticate the WebSocket connection. Credentials are obtained from the Cognito Identity Pool configured with your website's auth. In `dev` mode, signing is automatically skipped when <Link path="guides/react-website#runtime-configuration">`runtime-config.json`</Link> is not present
 - **Cognito**: Embeds the JWT access token in the `Sec-WebSocket-Protocol` header as a base64url-encoded bearer token, following the [AgentCore WebSocket auth protocol](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started-websocket.html)
 
 
@@ -174,11 +174,11 @@ For more details on the vanilla tRPC client, see the [tRPC Vanilla Client docume
 
 ## Local Development
 
-The connection generator automatically configures `serve-local` integration for your react website:
+The connection generator automatically configures `dev` integration for your react website:
 
-1. Running `nx serve-local <website>` will also start the agent's local server
+1. Running `nx dev <website>` will also start the agent's local server
 2. The runtime config is overridden to point to the local WebSocket URL (e.g., `ws://localhost:8081/ws`)
-3. Like with connected APIs, authentication is skipped in `serve-local` mode when <Link path="guides/react-website#runtime-configuration">`runtime-config.json`</Link> is not present
+3. Like with connected APIs, authentication is skipped in `dev` mode when <Link path="guides/react-website#runtime-configuration">`runtime-config.json`</Link> is not present
 
 :::tip[Hot Reloading]
 The website and connected agent will hot-reload, enabling you to quickly iterate on both together without deploying to AWS.

package/docs/guides/connection/smithy-dynamodb.mdx

@@ -35,7 +35,7 @@ Select your Smithy API backend project as the source and your DynamoDB project a
 
 ## Generator Output
 
-The generator updates your Smithy API's `project.json` to add a dependency from its `serve-local` target to the DynamoDB project's `serve-local` target. No source files are modified.
+The generator updates your Smithy API's `project.json` to add a dependency from its `dev` target to the DynamoDB project's `dev` target. No source files are modified.
 
 ## Using DynamoDB in Operations
 

package/docs/guides/connection/smithy-rdb.mdx

@@ -46,7 +46,7 @@ The generator modifies three existing files in your Smithy API backend:
 
 </FileTree>
 
-Additionally, it updates the API's `serve-local` target to start the database automatically.
+Additionally, it updates the API's `dev` target to start the database automatically.
 
 ## How It Works
 
@@ -156,6 +156,6 @@ const server = createServer(async function (req, res) {
 });
 ```
 
-<NxCommands commands={["serve-local <api-project-name>"]} />
+<NxCommands commands={["dev <api-project-name>"]} />
 
-This starts both the API and the local database. The `SERVE_LOCAL=true` environment variable is set automatically, so the Prisma client connects to the local Docker database instead of Aurora.
+This starts both the API and the local database. The `LOCAL_DEV=true` environment variable is set automatically, so the Prisma client connects to the local Docker database instead of Aurora.

package/docs/guides/connection/trpc-dynamodb.mdx

@@ -35,7 +35,7 @@ Select your tRPC API project as the source and your DynamoDB project as the targ
 
 ## Generator Output
 
-The generator updates your tRPC API's `project.json` to add a dependency from its `serve-local` target to the DynamoDB project's `serve-local` target. No source files are modified.
+The generator updates your tRPC API's `project.json` to add a dependency from its `dev` target to the DynamoDB project's `dev` target. No source files are modified.
 
 ## Using DynamoDB in Procedures
 

package/docs/guides/connection/trpc-rdb.mdx

@@ -45,7 +45,7 @@ The generator creates a middleware file in your tRPC API project:
 
 </FileTree>
 
-Additionally, it updates your tRPC API's `serve-local` target to start the database automatically when running locally.
+Additionally, it updates your tRPC API's `dev` target to start the database automatically when running locally.
 
 ## Using the Middleware
 
@@ -120,8 +120,8 @@ export const dbProcedure = t.procedure
 
 ## Local Development
 
-The generator configures your tRPC API's `serve-local` target to depend on the database's `serve-local` target, so running:
+The generator configures your tRPC API's `dev` target to depend on the database's `dev` target, so running:
 
-<NxCommands commands={["serve-local <api-project-name>"]} />
+<NxCommands commands={["dev <api-project-name>"]} />
 
 will automatically start the local database alongside your API.

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

@@ -61,7 +61,7 @@ The generator creates a shared `agent-connection` package and modifies your agen
 
 Additionally, it:
 - Transforms your agent's `agent.ts` to register the remote A2A agent as a Strands `tool`
-- Updates the agent's `serve-local` target to depend on the target agent's `serve-local` target
+- Updates the agent's `dev` target to depend on the target agent's `dev` target
 - Installs required dependencies
 
 ## Using the Connected A2A Agent
@@ -90,7 +90,7 @@ export const getAgent = async (sessionId: string) => {
 
 The `sessionId` parameter is plumbed through from the caller, ensuring consistency for [Bedrock AgentCore Observability](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html).
 
-Under the hood, `RemoteAgentClientStrands.create(sessionId)` returns a Strands `A2AAgent` configured with a SigV4-signing `clientFactory` when deployed to AWS, and a plain `http://localhost:<port>/` endpoint when `SERVE_LOCAL=true`. The signing and endpoint resolution live in the framework-agnostic `agentcore-a2a-client-config.ts`; only the thin `agentcore-a2a-client-strands.ts` depends on Strands.
+Under the hood, `RemoteAgentClientStrands.create(sessionId)` returns a Strands `A2AAgent` configured with a SigV4-signing `clientFactory` when deployed to AWS, and a plain `http://localhost:<port>/` endpoint when `LOCAL_DEV=true`. The signing and endpoint resolution live in the framework-agnostic `agentcore-a2a-client-config.ts`; only the thin `agentcore-a2a-client-strands.ts` depends on Strands.
 
 ## Infrastructure
 
@@ -98,12 +98,12 @@ Under the hood, `RemoteAgentClientStrands.create(sessionId)` returns a Strands `
 
 ## Local Development
 
-The generator configures the host agent's `serve-local` target to:
+The generator configures the host agent's `dev` target to:
 1. Start the connected A2A agent(s) automatically
-2. Set `SERVE_LOCAL=true` so the generated client connects directly to `http://localhost:<port>/` instead of AgentCore
+2. Set `LOCAL_DEV=true` so the generated client connects directly to `http://localhost:<port>/` instead of AgentCore
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
 This will start both the host agent and all connected A2A agents, with the host agent calling the remote agents over plain HTTP on their assigned local ports.

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

@@ -35,7 +35,7 @@ Select your Agent project as the source and your DynamoDB project as the target.
 
 ## Generator Output
 
-The generator updates the agent's `<agent-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 agent's `<agent-name>-dev` target in `project.json` to depend on the DynamoDB project's `dev` target. No source files are modified.
 
 ## Using DynamoDB in Agents
 

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

@@ -56,7 +56,7 @@ The generator emits shared core client files into your `agent-connection` packag
 Additionally, the generator:
 
 - Modifies your agent's `agent.ts` to import the Gateway client class, call `<Gateway>ClientStrands.create()`, and register the returned client in the `tools` array
-- Wires the agent's `<agent>-serve-local` target to depend on the Gateway's `<gateway>-serve-local` aggregator
+- Wires the agent's `<agent>-dev` target to depend on the Gateway's `dev` target
 - Installs the required SigV4 / MCP dependencies
 
 ## Using the connected Gateway
@@ -76,7 +76,7 @@ export const getAgent = async () => {
 };
 ```
 
-When deployed (`SERVE_LOCAL` unset), the client points at the Gateway's MCP endpoint and authenticates with SigV4. When `SERVE_LOCAL=true`, it points at the local gateway started by the Gateway project's `serve-local` target, so the same `agent.ts` works uniformly in both modes.
+When deployed (`LOCAL_DEV` unset), the client points at the Gateway's MCP endpoint and authenticates with SigV4. When `LOCAL_DEV=true`, it points at the local gateway started by the Gateway project's `dev` target, so the same `agent.ts` works uniformly in both modes.
 
 The session ID is propagated to downstream MCP servers automatically via the `X-Amzn-Bedrock-AgentCore-Runtime-Session-Id` header.
 
@@ -131,16 +131,16 @@ The Gateway URL is automatically registered in the `agentcore.gateways.<ClassNam
 
 ## Local Development
 
-The generator configures the agent's `serve-local` target to:
+The generator configures the agent's `dev` target to:
 
 1. Start the connected Gateway's local gateway and every attached MCP server
-2. Set `SERVE_LOCAL=true` so the generated client points at the local gateway instead of the deployed Gateway
+2. Set `LOCAL_DEV=true` so the generated client points at the local gateway instead of the deployed Gateway
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
-To run the agent locally **against the deployed Gateway** instead (for example, to exercise Cedar policies), use the agent's `serve` target. Without `SERVE_LOCAL` set, the client resolves the deployed Gateway URL from runtime configuration and SigV4-signs requests with your local AWS credentials:
+To run the agent locally **against the deployed Gateway** instead (for example, to exercise Cedar policies), use the agent's `serve` target. Without `LOCAL_DEV` set, the client resolves the deployed Gateway URL from runtime configuration and SigV4-signs requests with your local AWS credentials:
 
 <NxCommands commands={["<agent-name>-serve <project-name>"]} />
 

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

@@ -61,7 +61,7 @@ The generator creates a shared `agent-connection` package and modifies your agen
 
 Additionally, it:
 - Transforms your agent's `agent.ts` to import and use the MCP server's tools
-- Updates the agent's `serve-local` target to depend on the MCP server's serve target
+- Updates the agent's `dev` target to depend on the MCP server's serve target
 - Installs required dependencies
 
 ## Using the Connected MCP Server
@@ -136,12 +136,12 @@ The MCP server's AgentCore runtime ARN is automatically registered in the `agent
 
 ## Local Development
 
-The generator configures the agent's `serve-local` target to:
+The generator configures the agent's `dev` target to:
 1. Start the connected MCP server(s) automatically
-2. Set `SERVE_LOCAL=true` so the generated client uses direct HTTP transport instead of AgentCore
+2. Set `LOCAL_DEV=true` so the generated client uses direct HTTP transport instead of AgentCore
 
 Run the agent locally with:
 
-<NxCommands commands={["<agent-name>-serve-local <project-name>"]} />
+<NxCommands commands={["<agent-name>-dev <project-name>"]} />
 
 This will start both the agent and all connected MCP servers, with the agent connecting to the MCP servers directly via HTTP on their assigned local ports.