feat(continuous-delivery): assets in environment-agnostic stacks

text/0049-continuous-delivery.md

@@ -196,7 +196,9 @@ The proposal described in [PR#4131](https://github.com/aws/aws-cdk/pull/4131) su
 
 This means that the only way to produce environment-agnostic templates will be to explicitly indicate it when a stack is defined.
 
-Since the specific account and region are required when resolving asset consumption and publishing locations, the current plan is for the default asset store implementation to **fail if assets are used from environment-agnostic stacks**. Again, bear in mind that the current behavior (where the default is environment-agnostic stacks) is going to be changed.
+Then `cdk-assets` will simply substitute `${AWS::ACCOUNT}` and `${AWS::REGION}` with the account and region derived from the credentials configured for the CLI.
+
+> NOTE: even when an IAM role from another account is assumed for publishing, `${AWS::ACCOUNT}` and `${AWS::REGION}` always resolve to the CLI configuration and not to the other account.
 
 ## Bootstrapping
 

text/0092-asset-publishing.md

@@ -24,7 +24,10 @@ The main components of the assets manifest are:
 
 * **Destinations:** describe where the asset should be published. At a minimum, for file assets, it includes the S3 bucket and object key and for docker images it includes the repository and image names. A destination may also indicate that an IAM role must be assumed in order to support cross environment publishing. 
 
-  > Destinations are intentionally denormalized in order to keep the logic of where assets are published at the application or framework level and not in this tool. For example, consider a deployment system which requires that all assets are always published to the same location, and then replicated through some other means to their actual consumption point. Alternatively, a user may have unique security requirements that will require certain assets to be stored in dedicated locations (e.g. with a specific key) and others in a different location, even if they all go to the same environment. Therefore, this tool should not take any assumptions on where assets should be published besides the exact instructions in this file.
+NOTES:
+
+* **Denormalization:** destinations are intentionally denormalized in order to keep the logic of where assets are published at the application or framework level and not in this tool. For example, consider a deployment system which requires that all assets are always published to the same location, and then replicated through some other means to their actual consumption point. Alternatively, a user may have unique security requirements that will require certain assets to be stored in dedicated locations (e.g. with a specific key) and others in a different location, even if they all go to the same environment. Therefore, this tool should not take any assumptions on where assets should be published besides the exact instructions in this file.
+* **Environment-agnostic:** In order to allow assets to be used in environment-agnostic stacks, `assets.json` will support two simple substitutions `${AWS::AccountId}` and `${AWS::Region}` which will be replaced with the currently configured account/region (alternatively, we can also decide to support CloudFormation intrinsic functions and pseudo references). The "current" account and region will always refer to the one derived from the CLI configuration even if `assets.json` instructs to assume a role from a different account.
 
 Here is the complete manifest file schema in typescript: