@kensio/yulin 1.21.7 → 1.21.9

package/docs/services/cloudformation/README.md

@@ -1,12 +1,11 @@
 # Simulated CloudFormation
 
-Yulin includes a simulated CloudFormation service for tests and local development. It creates
-simulated AWS resources from CloudFormation templates, and works with hand-written templates, AWS
-SDK-style `CreateStackCommand` calls, or synthesized CDK template files.
+Yulin deploys CloudFormation templates into a simulated AWS environment. It accepts inline
+templates, AWS SDK command inputs, template files and synthesized CDK cloud assemblies.
 
 ## Basic usage
 
-Create a simulated AWS environment, get simulated CloudFormation, and deploy a template.
+Call `deployTemplate(...)` with a template and wait for the stack to finish deploying.
 
 ```typescript sim-cloudformation-basic-template
 /**
@@ -84,7 +83,7 @@ console.log(simAws.s3().getSimBucketByName("typed-site-bucket")?.bucketName);
 
 ## Creating stacks with AWS SDK command shapes
 
-You can also use AWS SDK-style CloudFormation commands.
+Use `createStack(...)` when the code under test works with AWS SDK command shapes.
 
 ```typescript sim-cloudformation-create-stack-command
 /**
@@ -263,11 +262,9 @@ await simAws.backgroundTasksComplete();
 
 ## Updating a stack
 
-`UpdateStackCommand` applies a changed template to a stack that is already deployed. Resources the
-new template adds are created, resources it drops are deleted, and resources it changed are
-replaced. Everything else is left alone, holding whatever it holds in simulated S3, DynamoDB or
-anywhere else. That is what lets a long-running local process pick up an infrastructure change
-without restarting and losing its data.
+`UpdateStackCommand` applies a changed template to an existing stack. It creates added resources,
+deletes removed resources and replaces changed resources. Unchanged resources keep their simulated
+state.
 
 ```typescript sim-cloudformation-update-stack
 /**
@@ -352,11 +349,9 @@ could mean nothing else.
 
 ### What counts as a change
 
-Resources are compared as they resolve, not as they are written. A changed parameter value shows up
-as a changed resource even when the template body is identical, and a template reordered without
-being changed shows up as no change at all. Outputs are compared the same way. The rest of the
-template body is compared as written. A change to a section the simulator ignores, such as
-`Description`, is still an update.
+Yulin compares resolved resources and outputs. Changing a parameter can therefore change a resource
+without changing the template body. Reordering an unchanged template has no effect. Other template
+sections are compared as written, including ignored sections such as `Description`.
 
 A template that changes nothing at all is refused with a `ValidationError` reading
 `No updates are to be performed.`, the same answer CloudFormation gives. So is an update asked for
@@ -436,12 +431,11 @@ An update from the held template with the deployed values changes nothing, and i
 
 ### Changed resources are replaced
 
-A resource whose template entry changed is deleted and created again from the new template. Real
-CloudFormation updates most properties in place and keeps what the resource holds. That makes this a
-divergence worth knowing about. A bucket that gains a property loses its objects here, where in AWS
-it would keep them. In-place update is the obvious next step, still to be built.
+Yulin replaces a resource when its resolved template entry changes. It deletes the old resource and
+creates a new one. AWS updates many properties in place. A simulated bucket therefore loses its
+objects when a property change replaces it.
 
-Three things follow from replacement:
+Replacement also affects dependencies and retention policies:
 
 - A resource naming a replaced resource is replaced too, all the way up the dependency chain, and
   nothing is left pointing at a resource that has gone. Real CloudFormation hands the dependent the
@@ -618,9 +612,8 @@ to create. Name the replacement in the template, as the example above does, to h
 
 ## Deploying through a change set
 
-A change set says what a template would do to a stack before anything happens to it. `cdk deploy`
-goes through one by default, and so does any deployment script that wants to see what an update will
-touch. Simulated CloudFormation serves `CreateChangeSetCommand`, `DescribeChangeSetCommand`,
+A change set describes a proposed stack operation without applying it. Simulated CloudFormation
+serves `CreateChangeSetCommand`, `DescribeChangeSetCommand`,
 `ExecuteChangeSetCommand`, `DeleteChangeSetCommand` and `ListChangeSetsCommand`.
 
 ```typescript sim-cloudformation-change-set
@@ -735,8 +728,7 @@ holds, in the order they were created.
 
 ## Deleting a stack
 
-`DeleteStackCommand` deletes the resources a stack created, in the reverse of the order they were
-created in, and then releases the stack name.
+`DeleteStackCommand` deletes resources in reverse creation order, then releases the stack name.
 
 ```typescript sim-cloudformation-delete-stack
 /**
@@ -801,9 +793,8 @@ Deleting a stack name that was never deployed succeeds, as it does in CloudForma
 
 ### When a resource cannot be deleted
 
-Some resources refuse to go, the same way they do in AWS. An S3 bucket that still holds objects is
-the common one. CloudFormation fails there and never empties the bucket for you. That is why CDK
-ships an `autoDeleteObjects` custom resource.
+Resource deletion can fail. For example, S3 refuses to delete a non-empty bucket. CloudFormation
+leaves the stack in `DELETE_FAILED` and does not empty the bucket automatically.
 
 A refusal leaves the stack in `DELETE_FAILED` with the reason on it, and keeps the stack name in use.
 `waitForStackDeleteComplete(...)` rethrows the error, and `DescribeStacksCommand` reports it as
@@ -896,7 +887,7 @@ takes either.
 
 ## Parameters
 
-Template parameters can be supplied when creating a stack.
+Pass template parameter values when creating or updating a stack.
 
 ```typescript sim-cloudformation-parameters
 /**
@@ -949,7 +940,7 @@ the type.
 
 ## Intrinsic functions
 
-Sim CloudFormation supports common intrinsic functions used by supported resources.
+Yulin resolves the following intrinsic functions in resource properties and outputs.
 
 ### `Ref`
 
@@ -991,8 +982,8 @@ console.log(
 );
 ```
 
-For supported resource types, `Ref` returns the resource-specific CloudFormation value. For example,
-an S3 Bucket `Ref` returns the Bucket name.
+`Ref` returns the CloudFormation value for a resource type. For an S3 bucket, it returns the bucket
+name.
 
 ### `Fn::GetAtt`
 
@@ -1251,8 +1242,8 @@ console.log(simAws.s3().getSimBucketByName("docs-site-bucket")?.bucketName);
 
 ### `Fn::FindInMap`
 
-A template `Mappings` section holds two levels of keys against a value. `Fn::FindInMap` reads one of
-those values, given the map name, the top-level key and the second-level key.
+A template `Mappings` section stores values under two levels of keys. `Fn::FindInMap` reads a value
+using the map name and both keys.
 
 ```typescript sim-cloudformation-fn-find-in-map
 /**
@@ -1330,9 +1321,7 @@ expression. A lookup that finds its value in the map ignores the default.
 
 ### `Fn::Split` and `Fn::Select`
 
-`Fn::Split` cuts a string into a list on a delimiter. `Fn::Select` reads one value out of a list by
-its zero-based index. They are usually written together, to pull one part out of a string another
-resource gave.
+`Fn::Split` divides a string by a delimiter. `Fn::Select` reads a list value by zero-based index.
 
 ```typescript sim-cloudformation-fn-select-split
 /**
@@ -1418,8 +1407,7 @@ resource and the property path the value sat at, for example
 
 ### `Fn::ImportValue`
 
-`Fn::ImportValue` reads a value another Stack exported. A Stack exports one by giving an Output an
-`Export.Name`, and a Stack in the same Account and Region imports it by that name.
+`Fn::ImportValue` reads a named output exported by another stack in the same account and region.
 
 CDK writes both halves on its own. Referencing a resource in another Stack of the same app puts an
 `Export` on the producer and an `Fn::ImportValue` on the consumer, with no opt-in.
@@ -1486,8 +1474,8 @@ exports published in that Region.
 
 ## Dynamic references
 
-A `{{resolve:...}}` dynamic reference reads a value from another service while a resource is being
-created. It is written into the template as ordinary text, so it can sit inside a longer string.
+A `{{resolve:...}}` dynamic reference reads an SSM parameter or Secrets Manager secret while
+creating a resource. A reference can appear inside a longer string.
 
 `Fn::Sub` and `Fn::Join` resolve first, and the reference is read from the string they built. CDK
 writes that shape whenever a secret sits in the same stack as the resource reading it (the secret's
@@ -1506,9 +1494,8 @@ for the segments and for what a reference Secrets Manager cannot answer resolves
 
 ## Conditions
 
-A template `Conditions` section names boolean expressions over the stack's parameter values. A
-condition decides whether a resource is created, and which value `Fn::If` gives a property or an
-output.
+The `Conditions` section defines boolean expressions over parameter and pseudo-parameter values.
+Conditions control resource creation and select `Fn::If` values.
 
 ```typescript sim-cloudformation-conditions
 /**
@@ -1632,7 +1619,7 @@ condition the template leaves undefined fails the deployment.
 
 ## Resource dependencies
 
-Resources can depend on each other explicitly with `DependsOn`.
+Use `DependsOn` to declare an explicit resource dependency.
 
 ```typescript sim-cloudformation-depends-on
 /**
@@ -1765,8 +1752,7 @@ in the assembly, and a Stack named in `stackOptions` carries its own.
 
 ## Deploying synthesized CDK templates
 
-Use `deployTemplateFile(...)` to deploy a template file, including the JSON templates CDK synthesis
-produces.
+Use `deployTemplateFile(...)` to deploy a JSON or YAML template file, including CDK synth output.
 
 ```typescript sim-cloudformation-cdk-template-file
 /**
@@ -1805,8 +1791,7 @@ const stack = await simAws.cloudFormation().deployTemplateFile({
 await stack.waitForDeployComplete();
 ```
 
-This is useful for local integration tests where you want CDK to produce the template, then Yulin to
-create the simulated resources from that synthesized output template.
+This lets an integration test synthesize with CDK and deploy the resulting template through Yulin.
 
 A template path with no file at it is refused with
 `No Sim CloudFormation template file at <path>`, naming the resolved path. A synthesized template
@@ -1814,8 +1799,7 @@ is build output, and a checkout that has yet to synthesize one meets this on the
 
 ## Deploying a template written as YAML
 
-CloudFormation takes a template in JSON or in YAML, and a template written by hand is usually YAML.
-`deployTemplateFile(...)` reads a `.yaml` or `.yml` file as YAML.
+`deployTemplateFile(...)` parses `.yaml` and `.yml` files as YAML.
 
 ```yaml
 Resources:
@@ -1917,6 +1901,10 @@ it.
 environment names. The assembly's `manifest.json` is where that comes from, so an app synthesizing
 several Stacks across several regions needs no loop of its own and no region constants beside it.
 
+An application test suite should normally call `deployCdkOut(...)` once from its shared Yulin setup.
+Every test then uses the same deployed Stacks. The [test suite setup guide](https://yulinsim.dev/testing/)
+shows this arrangement with Vitest and SDK interception.
+
 ```typescript sim-cloudformation-cdk-out-assembly
 /**
  * Deploying every Stack a synthesized CDK cloud assembly holds.
@@ -3250,10 +3238,10 @@ another function's event put there.
 Two shapes are refused rather than expanded. A bucket writing its `NotificationConfiguration` or its
 `LambdaConfigurations` as an intrinsic such as `Fn::If` is one, because there is no appending to a
 list CloudFormation has not resolved yet, and adding the event's own entries would drop whatever the
-intrinsic resolved to. The other is a function the template conditions out, which real CloudFormation
-refuses for the same reason SAM cannot fix it: the notification belongs to the bucket, the bucket is
-not conditioned, and nothing can condition one entry of somebody else's property. Condition the
-bucket along with the function, or declare the notification on the bucket yourself.
+intrinsic resolved to. The other is a function the template conditions out. Real CloudFormation
+refuses this because the notification belongs to the unconditioned bucket, and one entry of that
+property cannot have its own condition. Condition the bucket along with the function, or declare the
+notification on the bucket yourself.
 
 ### Simple tables
 

package/docs/services/cloudfront/README.md

@@ -1,18 +1,12 @@
 # Simulated CloudFront
 
-Yulin includes a simulated CloudFront service for tests and local development.
+Yulin simulates CloudFront distributions, origins, cache behaviour and edge functions. Use
+`simAws.cloudFront()` as part of a simulated AWS environment or create a standalone
+`SimCloudFront`. `serveSimAws` exposes distributions over localhost.
 
-Sim CloudFront can be used directly through `SimAws`, and it can also be served on localhost
-alongside other simulated AWS services, so application code can make HTTP requests through a
-CloudFront-like layer without talking to real AWS.
+## Create a distribution
 
-`SimCloudFront` can also be instantiated on its own, in which case it has its own isolated state,
-standing apart from any wider simulated AWS environment.
-
-## Basic Distribution setup
-
-Create a simulated AWS environment, add a sim S3 Bucket, and create a sim CloudFront Distribution
-pointing at that Bucket.
+Create an S3 bucket, then create a distribution whose origin uses the bucket's REST endpoint.
 
 ```typescript sim-cloudfront-distribution-s3-origin
 /**
@@ -95,19 +89,16 @@ console.log(distributionCreation.Distribution?.DomainName);
 
 ## What an S3 Origin can read
 
-An S3 Origin reads its Bucket through the ordinary GetObject command. The Bucket policy decides what
-the Distribution can serve. An Origin with no origin access control reads anonymously, the unsigned
-request real CloudFront sends to the S3 REST endpoint. An Object has to be publicly readable for the
-Distribution to serve it, and a Bucket with no policy answers 403 for every Object.
+An S3 Origin reads its bucket through `GetObject`. The bucket policy decides what the distribution
+can serve. Without an origin access control, CloudFront reads anonymously and the object must be
+publicly readable. A private bucket returns 403.
 
 An Origin that does have an origin access control reads as the CloudFront service principal. The
 Bucket stays private and its policy names the Distribution. See
 [Origin access controls](#origin-access-controls) for the Bucket policy that takes.
 
-That is what the two commands in the example above do. `PutPublicAccessBlockCommand` opts out of the
-block on public Bucket policies, then `PutBucketPolicyCommand` grants `s3:GetObject` to
-`Principal: "*"`. The same pair is what a static website Bucket needs, and it is what CDK's
-`publicReadAccess: true` generates.
+The example disables the block on public bucket policies, then grants `s3:GetObject` to
+`Principal: "*"`. CDK's `publicReadAccess: true` produces the same result.
 
 A denied read reaches the viewer as a 403 from the Origin, and a Distribution's custom error
 response for 403 replaces it. The usual single-page-app setup, rewriting 403 to `/index.html`,
@@ -118,10 +109,8 @@ an Origin that signs nothing.
 
 ## Static sites, default root objects and error pages
 
-A static site behind CloudFront usually leans on two Distribution settings. `DefaultRootObject`
-makes a request for the site root return the home page. `CustomErrorResponses` makes a URL that
-matches no object return the site's own error page in place of the Origin's. Sim CloudFront applies
-both, and a test can assert what a visitor would actually see.
+`DefaultRootObject` maps the distribution root to an object such as `index.html`.
+`CustomErrorResponses` replaces selected Origin errors with another object and status code.
 
 ```typescript sim-cloudfront-static-site
 /**
@@ -242,13 +231,10 @@ try {
 }
 ```
 
-The default root object stands in for a request to the root of the Distribution and nothing else. A
-request for `/blog/` is passed to the Origin as it arrived, even where that folder holds its own
-`index.html`. That is where CloudFront differs from an S3 website index document. The substituted
-path is what the rest of request handling sees, and a Cache Behavior pattern and a `viewer-request`
-CloudFront Function both act on the object being served. The value names an object at the Origin. It may be a
-path such as `public/index.html`, and it must not begin with a forward slash. Sim CloudFront refuses one that does with `InvalidDefaultRootObject`. The alternative would
-be a Distribution that answers its own root with a 403.
+The default root object applies only to `/`. A request for `/blog/` reaches the Origin unchanged,
+even if the Origin contains `/blog/index.html`. Cache Behaviors and viewer-request functions see the
+substituted root path. The value may contain a path such as `public/index.html`, but it must not start
+with `/`. Invalid values raise `InvalidDefaultRootObject`.
 
 A custom error response replaces the Origin's response when its status matches `ErrorCode`. The
 codes CloudFront supports are 400, 403, 404, 405, 414, 416, 500, 501, 502, 503 and 504. The response
@@ -276,7 +262,7 @@ status the Distribution serves no page for. See
 
 ## Serve simulated CloudFront on localhost
 
-Use `serveSimAws` when you want to make real HTTP requests to the simulated system on localhost.
+Use `serveSimAws` to send HTTP requests through the simulated distribution on localhost.
 
 ```typescript serve-sim-cloudfront-localhost
 /**
@@ -390,15 +376,14 @@ the Distribution behind it. See
 
 ## Custom Origins
 
-An Origin with a `CustomOriginConfig` is one CloudFront reaches over HTTP, in place of reading an S3
-Bucket. Sim CloudFront resolves its `DomainName` in the simulated environment and serves the request
-in process. A Distribution can front a simulated HTTP API endpoint
+An Origin with `CustomOriginConfig` routes requests to another simulated HTTP service. CloudFront
+resolves `DomainName` in the simulated environment and serves the request in process. A distribution
+can front a simulated HTTP API endpoint
 (`<api-id>.execute-api.<region>.amazonaws.com`), a simulated Lambda Function URL
 (`<url-id>.lambda-url.<region>.on.aws`), or anything a simulated Route53 record points at one of
 those.
 
-That covers the common arrangement of one Distribution serving static assets from a Bucket and
-sending `/api/*` to an API:
+The following distribution serves static files from S3 and sends `/api/*` to an HTTP API:
 
 ```typescript sim-cloudfront-distribution-custom-origin
 /**
@@ -568,14 +553,13 @@ try {
 }
 ```
 
-The Origin domain is resolved when a request is served, and the Distribution and the service behind
-its Origin can be created in either order, whichever way round a CloudFormation template happens to
-declare them.
+The Origin domain is resolved for each request. The distribution and Origin service may be created
+in either order.
 
 `OriginPath` is prefixed to the request path, as it is for an S3 Origin. An Origin path of `/v1`
 sends a request for `/things` on to `/v1/things`.
 
-Three things follow from the request never leaving the process:
+In-process routing has these limits:
 
 - A domain unknown to the simulation fails with an error naming the Origin and the
   domain. No real request is made to it, and external HTTP Origins are unsupported.
@@ -588,10 +572,9 @@ Three things follow from the request never leaving the process:
 
 ## Custom headers on an Origin
 
-CloudFront adds an Origin's custom headers to every request it sends that Origin. An origin that
-answers only requests carrying a header nothing else knows is how AWS documents
-[restricting a custom origin to CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-overview.html#forward-custom-headers-restrict-access),
-and a sim Distribution sends them the same way.
+CloudFront adds an Origin's custom headers to every request sent to that Origin. A service can use a
+private header value to
+[restrict access to CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-overview.html#forward-custom-headers-restrict-access).
 
 The CloudFront API and CloudFormation name the field differently, and both spellings are accepted
 here. The API has `CustomHeaders` inside an `Origin`, and `AWS::CloudFront::Distribution` has
@@ -741,10 +724,10 @@ An S3 Origin takes the headers and reaches nothing with them. Sim CloudFront rea
 `GetObject` and builds no HTTP request for a header to travel on, and real S3 ignores a header it
 has no use for.
 
-## An Origin declared twice
+## Duplicate Origins
 
-Two Origins over one domain name are ordinary. They differ by `OriginPath`, by their custom headers
-or by how CloudFront connects, and a Behavior points at whichever one it wants.
+Several Origins may use the same domain when their paths, headers, or connection settings differ.
+Each Behavior selects an Origin by ID.
 
 Two Origins that match in every property but the `Id` are one Origin written twice. Copying a
 Behavior and its Origin together, then editing the path pattern, leaves exactly that behind. Sim
@@ -840,9 +823,8 @@ value however they were ordered or cased.
 
 ## Viewer certificates
 
-A Distribution with alternate domain names needs an ACM certificate, and CloudFront accepts only
-certain ones. Sim CloudFront applies the same rules. A Distribution that real CloudFront would
-reject at deploy time is rejected here first, with `InvalidViewerCertificate`:
+A distribution with alternate domain names requires a valid ACM certificate. Yulin raises
+`InvalidViewerCertificate` when:
 
 - the certificate must be in `us-east-1`, wherever the rest of your infrastructure lives
 - the certificate must exist and be `ISSUED`
@@ -912,8 +894,8 @@ as well.
 
 ## Disabling and deleting a Distribution
 
-`DeleteDistributionCommand` removes a Distribution. CloudFront will only delete one that has stopped
-serving. The sequence is `UpdateDistributionCommand` with `Enabled: false` first, then the deletion. Deleting an enabled Distribution answers `DistributionNotDisabled`, as it does in AWS.
+Disable a distribution with `UpdateDistributionCommand` before deleting it. Deleting an enabled
+distribution raises `DistributionNotDisabled`.
 
 `UpdateDistributionCommand` takes a whole `DistributionConfig`, and applies the update as a
 replacement. Anything left out of the new config is dropped, including alternate domain names and
@@ -1012,17 +994,16 @@ Function code.
 
 ## Simulated CloudFront Functions
 
-The sim CloudFront supports `viewer-request` and `viewer-response` CloudFront Functions.
+Yulin supports `viewer-request` and `viewer-response` CloudFront Functions.
 
 A `viewer-response` Function runs for an Origin status below 400. CloudFront skips the
 viewer-response event once the Origin has answered 400 or higher (see
 [Limitations](#limitations)), and so does this simulation.
 
-Use `makeCffFunctionCodeInput` to pass a JavaScript handler function to `CreateFunctionCommand`, or
+Use `makeCffFunctionCodeInput` to pass a JavaScript handler to `CreateFunctionCommand`. Use
 [CloudFormation bindings](https://yulinsim.dev/services/cloudformation/#cloudfront-function-bindings "CloudFront Function bindings usage docs")
-to back a template Resource with one. A handler reference is what to reach for first. It stops on a
-breakpoint and can close over the test's own state. Publish the source itself where the test is
-about the code the Distribution carries, down to the 10 KB it has to fit in. A
+for a function declared in a template. Handler references support breakpoints and local state. Use
+source code when the test covers the deployed function or its 10 KB size limit. A
 [Lambda@Edge](#simulated-lambdaedge) function is an ordinary simulated Lambda function, and the same
 choice covers it.
 
@@ -1851,8 +1832,7 @@ parameter holding the version ARN into a support stack in us-east-1. The stack u
 reads that parameter back through a `Custom::CrossRegionStringParameterReader` resource, and the
 Behavior's `LambdaFunctionARN` is an `Fn::GetAtt` on it. Simulated CloudFormation makes that read
 itself, against the Region the resource names, and the association ends up holding the ARN the
-support stack published. Both stacks have to deploy, which is what deploying the whole cloud
-assembly does:
+support stack published. Deploy the whole cloud assembly to deploy both stacks:
 
 ```typescript
 await simAws.cloudFormation().deployCdkOut("cdk.out");
@@ -2014,8 +1994,8 @@ answered.
 ## Response headers policies
 
 A response headers policy sets headers on everything a cache Behavior serves. Declare one as
-`AWS::CloudFront::ResponseHeadersPolicy` and point a Behavior's `ResponseHeadersPolicyId` at it with
-a `Ref`, which is what CDK's `ResponseHeadersPolicy` construct synthesizes.
+`AWS::CloudFront::ResponseHeadersPolicy` and reference it from the Behavior's
+`ResponseHeadersPolicyId`. CDK's `ResponseHeadersPolicy` construct synthesizes this shape.
 
 ```typescript sim-cloudfront-response-headers-policy
 /**
@@ -2206,9 +2186,9 @@ it.
 
 ## Cache policies
 
-A cache policy decides what a cache Behavior keys its cache on and how long an object stays there.
-Declare one as `AWS::CloudFront::CachePolicy` and point a Behavior's `CachePolicyId` at it with a
-`Ref`, which is what CDK's `CachePolicy` construct synthesizes.
+A cache policy controls the cache key and time to live. Declare one as
+`AWS::CloudFront::CachePolicy` and reference it from the Behavior's `CachePolicyId`. CDK's
+`CachePolicy` construct synthesizes this shape.
 
 ```typescript sim-cloudfront-cache-policy
 /**
@@ -2652,8 +2632,8 @@ try {
 
 The Origin's own headers and the cache policy settle the TTL between them, the way they settle it in
 AWS. `s-maxage` is preferred to `max-age`, and `max-age` to `Expires`. Whatever the Origin asks for
-is held between the policy's `MinTTL` and `MaxTTL`. An Origin that asks for nothing gets the greater
-of `MinTTL` and `DefaultTTL`, which is a day on `CachingOptimized`.
+is held between the policy's `MinTTL` and `MaxTTL`. When the Origin supplies no cache lifetime,
+CloudFront uses the greater of `MinTTL` and `DefaultTTL`. `CachingOptimized` uses one day.
 
 An `Expires` header has to carry one of the three date formats HTTP allows. Anything else, a
 locale-formatted date included, is read as an object that expired already, the way any HTTP cache
@@ -2878,10 +2858,9 @@ different paths is `InvalidationBatchAlreadyExists`.
 
 ## Origin request policies
 
-An origin request policy decides which of the viewer's headers, cookies and query strings a cache
-Behavior carries to its Origin. Declare one as `AWS::CloudFront::OriginRequestPolicy` and point a
-Behavior's `OriginRequestPolicyId` at it with a `Ref`, which is what CDK's `OriginRequestPolicy`
-construct synthesizes.
+An origin request policy selects the viewer headers, cookies and query strings sent to the Origin.
+Declare one as `AWS::CloudFront::OriginRequestPolicy` and reference it from the Behavior's
+`OriginRequestPolicyId`. CDK's `OriginRequestPolicy` construct synthesizes this shape.
 
 ```typescript sim-cloudfront-origin-request-policy
 /**
@@ -3171,9 +3150,9 @@ Behavior names one without a template creating anything. `AllViewer`
 for it. CDK's `OriginRequestPolicy.ALL_VIEWER` and its seven siblings synthesize those IDs. A stack
 reaching for one deploys.
 
-Each also carries the three sections AWS publishes for it. A Behavior on `AllViewer` here sends the
-Origin everything the viewer sent bar its `Host`, which is the Origin's own domain under every
-policy. One on `CORS-CustomOrigin` sends the `Origin` header alone. One on
+Each also carries the three sections AWS publishes for it. A Behavior on `AllViewer` sends every
+viewer value except `Host`. The Origin's domain is used for `Host` under every policy. A Behavior on
+`CORS-CustomOrigin` sends the `Origin` header alone. One on
 `AllViewerExceptHostHeader` sends what `AllViewer` sends, since the `Host` it withholds was never
 the viewer's here.
 
@@ -3189,10 +3168,9 @@ Behavior, the way an absent cache policy does, and the Behavior reports no polic
 
 ## Origin access controls
 
-An origin access control is how a Distribution authenticates to a private Origin. The Origin then
-admits the Distribution and nothing else. Declare one as `AWS::CloudFront::OriginAccessControl` and
-point an Origin's `OriginAccessControlId` at it with a `Ref`, which is what CDK's
-`S3BucketOrigin.withOriginAccessControl` synthesizes.
+An origin access control lets a Distribution authenticate to a private Origin. Declare one as
+`AWS::CloudFront::OriginAccessControl` and reference it from the Origin's `OriginAccessControlId`.
+CDK's `S3BucketOrigin.withOriginAccessControl` synthesizes this shape.
 
 An `OriginAccessControlOriginType` of `s3` signs for an S3 Bucket Origin, and one of `lambda` signs
 for a Lambda Function URL Origin. The origin type has to match the Origin it is attached to. An `s3`
@@ -3635,11 +3613,9 @@ CloudFront. `await simAws.backgroundTasksComplete()` waits for that.
 
 ### ETags
 
-The key value store commands do check `IfMatch`, where the Distribution and Function commands ignore
-it. Both APIs require it on every write and CloudFront refuses a stale one, which is what stops two
-writers overwriting each other. A write carrying a stale ETag is refused with `PreconditionFailed`,
-and a caller has to thread the ETag through the way it does against CloudFront. Each write returns
-the new ETag for the next one.
+Key value store commands check `IfMatch`. Distribution and Function commands ignore it. Both key
+value store APIs require the current ETag for every write. A stale ETag raises
+`PreconditionFailed`, and each successful write returns the ETag for the next one.
 
 A store has two ETags and they are not interchangeable, as in AWS. Each `DescribeKeyValueStore`
 returns its own. The CloudFront client's versions the store's configuration, and the key value store
@@ -3993,8 +3969,8 @@ Where sim CloudFront knowingly behaves differently from AWS:
   response an `origin-request` function generated has no Origin status behind it, and its own status
   stands in.
 - **CloudFront's disallowed and read-only header lists go unchecked.** Real CloudFront answers 502
-  when an edge function adds `Connection` or edits `Content-Length`. Both kinds of function here
-  write what they like, apart from the viewer-request `host`, which is restored.
+  when an edge function adds `Connection` or edits `Content-Length`. Yulin accepts those changes.
+  It restores the `host` after a viewer-request function.
 - **An S3 Origin with no origin access control reads its Bucket anonymously.** That is the unsigned
   request real CloudFront sends to the S3 REST endpoint without one. The Bucket policy has to make
   an Object publicly readable for the Distribution to serve it. A legacy
@@ -4020,9 +3996,9 @@ Where sim CloudFront knowingly behaves differently from AWS:
   are absent, and `AWS::CloudFront::OriginAccessControl` is the only way to make one.
 - **A list's `Quantity` is only checked when it is there.** Every CloudFront list carries a count
   alongside its items, and a `Quantity` that disagrees with `Items` is refused with
-  `InconsistentQuantities`, as CloudFront refuses it. A list arriving as a plain array, which is the
-  CloudFormation shape, has no count to disagree with, and a template goes unchecked this way. So
-  does a hand-written `{ Items: [...] }` with the count left out. The AWS SDK types make omitting
+  `InconsistentQuantities`, as CloudFront refuses it. CloudFormation uses a plain array without a
+  count, so templates skip this validation. A hand-written `{ Items: [...] }` also skips it when the
+  count is absent. The AWS SDK types make omitting
   `Quantity` a compile error, so what arrives without one is a different mistake from the one this
   catches.
 - **A web ACL a Distribution names has to exist here.** `WebACLId` resolves to a web ACL created in
@@ -4075,11 +4051,9 @@ Where sim CloudFront knowingly behaves differently from AWS:
   share of real responses carry `Server-Timing`. This simulation adds it to every response once
   `Enabled` is true. A test asserting on it never depends on chance. The header's value is a
   fixed placeholder, since nothing here measures an Origin fetch the way CloudFront's edge does.
-- **A viewer's `Host` header never reaches an Origin.** Real CloudFront forwards it where a policy
-  names it, which is what `AllViewerExceptHostHeader` exists to stop. Here an Origin request always
-  carries the Origin's own domain as `Host`, since the request has to reach the simulated service
-  its URL names.
-- **CloudFront's own headers are not generated.** `X-Amz-Cf-Id`, `Via`, `X-Forwarded-For` and the
-  `CloudFront-Viewer-*` family are absent from an Origin request, so a policy naming one of them
-  forwards nothing. `Host`, `User-Agent` and the normalized `Accept-Encoding` are the three this
-  simulation sends of its own accord.
+- **Origin requests use the Origin's `Host` header.** Real CloudFront can forward the viewer's value
+  when a policy includes it. Yulin always sends the Origin domain because the request must reach the
+  simulated service named by the URL.
+- **CloudFront-generated headers are absent.** Yulin omits `X-Amz-Cf-Id`, `Via`,
+  `X-Forwarded-For` and the `CloudFront-Viewer-*` family. It generates `Host`, `User-Agent` and a
+  normalized `Accept-Encoding` value.