@aws/nx-plugin-mcp 1.0.0-rc.85 → 1.0.0-rc.87

package/bin/aws-nx-mcp.js

@@ -54023,7 +54023,7 @@ ${PACKAGE_MANAGERS.map((pm) => buildNxCommand("<options>", pm)).join(" - \n")}
 - Generate all projects into the \`packages/\` directory
 - After making changes to your projects, fix linting issues, then run a full build
 - When it's time to start testing a project, suggest to the user that infrastructure is deployed to AWS. For websites, if a runtime-config.json is needed, use the load-runtime-config target after a deployment to point a local website at a sandbox stack.
-- For CDK infrastructure projects, deploy the sandbox stage with the \`deploy-sandbox\` target (eg \`nx deploy-sandbox infra\`) rather than passing a stage pattern to \`deploy\` — it already targets the sandbox stage declared in \`main.ts\`.
+- For CDK infrastructure projects, deploy the sandbox stage with the \`deploy-sandbox\` target (eg \`nx deploy-sandbox infra\`) rather than passing a stage pattern to \`deploy\` — it already targets the sandbox stage declared in \`main.ts\`. Likewise \`destroy-sandbox\` tears that stage back down.
 
 ## Batching Generators
 

package/docs/get_started/tutorials/dungeon-game/1.mdx

@@ -269,7 +269,7 @@ export class GameApi<
       pattern: 'isolated',
       operations: routerToOperations(appRouter),
       defaultIntegrationOptions: {
-        runtime: Runtime.NODEJS_LATEST,
+        runtime: Runtime.NODEJS_24_X,
         handler: 'index.handler',
         code: Code.fromAsset(
           url.fileURLToPath(

package/docs/get_started/tutorials/dungeon-game/wrap-up.mdx

@@ -34,7 +34,7 @@ We recommend you try your hand at extending the codebase with the following capa
 
 1. To destroy the AWS resources that were created, run the following command:
 
-<NxCommands commands={['destroy infra "dungeon-adventure-infra-sandbox/*"']} />
+<NxCommands commands={['destroy-sandbox infra']} />
 
     This will prompt you for a list of stacks to delete which should comprise of the `dungeon-adventure-infra-sandbox/Application/GameUI/waf` and `dungeon-adventure-infra-sandbox/Application`.
 

package/docs/get_started/upgrading.mdx

@@ -117,6 +117,12 @@ Finally, verify everything still builds, then delete `migrations.json` and commi
 
 <PackageManagerShortCommand commands={['build']} />
 
+<Aside type="caution" title="Some infrastructure changes are not migrated">
+Migrations don't cover every change to the infrastructure we vend. Where updating an already-deployed stack would fail or destroy data, no migration is provided — your workspace keeps deploying the resources it deploys today, while a newly generated workspace gets the newer shape.
+
+To pick those changes up, compare your infrastructure against what today's generators produce and apply the parts you want by hand, taking care over the deployment path for your existing resources.
+</Aside>
+
 ## Upgrading with an AI agent
 
 The whole flow can be driven by an AI coding agent end to end — nothing blocks on an interactive terminal. When `nx migrate --run-migrations` runs from inside an agent, Nx detects this, skips the agentic consent prompt, and instead of spawning a nested agent it **defers** each prompt migration back to the agent driving the run:

package/docs/guides/py-rdb.mdx

@@ -231,6 +231,10 @@ When using RDS Proxy, you do not need to configure the RDS CA bundle in the runt
 
 <Snippet name="rdb/encryption-key-rotation" />
 
+### Admin Credentials
+
+<Snippet name="rdb/admin-credentials" />
+
 ## Connections
 
 Use the <Link path="guides/connection">`connection`</Link> generator to integrate this project with others in your workspace. The following connections involve this project:

package/docs/guides/ts-rdb.mdx

@@ -311,6 +311,10 @@ For more details, see the AWS Lambda [SSL/TLS requirements for Amazon RDS connec
 
 <Snippet name="rdb/encryption-key-rotation" />
 
+### Admin Credentials
+
+<Snippet name="rdb/admin-credentials" />
+
 ## Limitations
 
 <OptionFilter when={{ engine: 'mysql' }}>

package/docs/guides/typescript-infrastructure.mdx

@@ -102,7 +102,7 @@ new ApplicationStage(app, 'my-app-sandbox', {
 
 The `env` property tells CDK which AWS account and region to deploy to. `CDK_DEFAULT_ACCOUNT` and `CDK_DEFAULT_REGION` are resolved automatically by the CDK CLI from your active AWS credentials. See the [CDK environments documentation](https://docs.aws.amazon.com/cdk/v2/guide/environments.html) for more details.
 
-The sandbox stage is the one the <Link path="guides/typescript-infrastructure#deploying-your-sandbox-stage">`deploy-sandbox` target</Link> deploys.
+The sandbox stage is the one the <Link path="guides/typescript-infrastructure#deploying-your-sandbox-stage">`deploy-sandbox`</Link> and <Link path="guides/typescript-infrastructure#tearing-down-your-sandbox-stage">`destroy-sandbox`</Link> targets act on.
 
 If you generated with `stageConfig`, the `main.ts` reads account and region from a centralized config file instead, falling back to environment variables when no config is set:
 
@@ -421,10 +421,34 @@ This target differs slightly from the regular `deploy` target in that it deploys
 
 ## Tearing Down AWS Infrastructure
 
-Use the `destroy` target to tear down your resources:
+Your project has three destroy targets, mirroring the deploy ones:
+
+| Target            | Use it for                                                                |
+| ----------------- | ------------------------------------------------------------------------- |
+| `destroy-sandbox` | Tearing down your own sandbox stage. No stage argument needed.             |
+| `destroy`         | Tearing down any stage, by naming the stage or stacks you want.            |
+| `destroy-ci`      | Tearing down from a CI/CD pipeline, using a pre-synthesized cloud assembly. |
+
+### Tearing Down your Sandbox Stage
+
+The `destroy-sandbox` target tears down the sandbox stage that `main.ts` declares, so you don't need to remember its stage name:
+
+<NxCommands commands={['destroy-sandbox <my-infra>']} />
+
+Destroying is irreversible, so CDK asks you to confirm the stacks it is about to delete. Pass `--force` to skip that confirmation, which is what you want when there is no terminal attached (in a script, say):
+
+<NxCommands commands={['destroy-sandbox <my-infra> --force']} />
+
+### Tearing Down a Specific Stage
+
+The `destroy` target tears down whichever stage or stacks you name:
 
 <NxCommands commands={['destroy <my-infra> <my-infra>-sandbox/*']} />
 
+To tear down an individual stack, give the full stack name:
+
+<NxCommands commands={['destroy <my-infra> <my-infra>-sandbox/Application']} />
+
 ## More Information
 
 For more information about CDK, please refer to the [CDK Developer Guide](https://docs.aws.amazon.com/cdk/v2/guide/core_concepts.html) and [API Reference](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html).

package/docs/snippets/rdb/admin-credentials.mdx

@@ -0,0 +1,42 @@
+---
+title: Admin Credentials
+---
+import Infrastructure from '@components/infrastructure.astro';
+
+The Aurora admin (master) user's password is generated and rotated by Aurora itself in AWS Secrets Manager, using [RDS-managed master user passwords](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html). Your infrastructure code never receives the password, so it cannot leak into a CloudFormation template or Terraform state file. Aurora rotates the secret every 7 days without any rotation function to deploy or maintain.
+
+The secret is encrypted with the same customer-managed KMS key as the cluster.
+
+Your application never uses these credentials. It connects as a least-privilege database user using IAM authentication — only the migration and create-db-user handlers read the admin secret, and each is granted access to just that secret and its KMS key.
+
+<Infrastructure>
+<Fragment slot="cdk">
+
+The admin secret is exposed as `secret.secretArn` on the underlying cluster, and `grantSecretRead` grants a consumer read access to it:
+
+```ts title="packages/infra/src/stacks/application-stack.ts"
+import { MyDatabase } from '@my-scope/common-constructs';
+
+const db = new MyDatabase(this, 'Db', { ... });
+
+db.grantSecretRead(myFunction);
+```
+</Fragment>
+<Fragment slot="terraform">
+
+The admin secret's ARN is exposed as the `secret_arn` output, alongside the `kms_key_arn` needed to decrypt it:
+
+```hcl title="packages/infra/src/main.tf"
+module "my_database" {
+  source = "../../common/terraform/src/app/dbs/my-database"
+  ...
+}
+
+output "database_secret_arn" {
+  value = module.my_database.secret_arn
+}
+```
+
+An RDS-managed secret holds a JSON object with `username` and `password` only — no connection details. Take the host, port and database name from the module's `writer_endpoint`, `cluster_port` and `database_name` outputs.
+</Fragment>
+</Infrastructure>

package/docs/snippets/rdb/architecture.mdx

@@ -35,4 +35,5 @@ app -> proxy: SQL (IAM auth)
 proxy -> aurora
 migrations -> aurora: Schema migrations
 migrations -> secrets: Admin credentials
+aurora -> secrets: Generates and rotates\nadmin credentials
 ```

package/package.json

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