@kensio/yulin 1.21.6 → 1.21.8

package/docs/services/route53/README.md

@@ -1,11 +1,12 @@
 # Simulated Route53
 
-Yulin includes a simulated Route53 service for tests and local development.
+Yulin simulates Amazon Route 53 hosted zones, records and DNSSEC configuration for tests and local
+development. You can manage them through the AWS SDK or deploy them from CloudFormation and CDK
+templates. When Yulin serves the simulation on localhost, Route 53 records can route local hostnames
+to simulated services such as CloudFront distributions and S3 bucket websites.
 
-Sim Route53 can be used directly through `SimAws`, instantiated on its own as `SimRoute53`, and used
-by sim CloudFormation when deploying Route53 resources from CloudFormation or CDK templates. When
-served on localhost, Route53 records can route custom local hostnames to other simulated AWS
-services, such as simulated CloudFront distributions or simulated S3 bucket websites.
+Use Route 53 through `SimAws` when it should share state with other services. Use `SimRoute53`
+directly when you need an isolated Route 53 simulation.
 
 ## Basic Hosted Zone usage
 
@@ -54,8 +55,8 @@ console.log(hostedZoneOut.HostedZone?.ResourceRecordSetCount);
 Hosted Zone names are normalised with a trailing dot in Route53-style outputs, so `example.test`
 becomes `example.test.`.
 
-Hosted Zone creation uses background tasks to move the zone to `INSYNC`. If your test needs final
-state, call `await simAws.backgroundTasksComplete()` before continuing.
+Hosted zone creation moves the zone to `INSYNC` in a background task. Call
+`await simAws.backgroundTasksComplete()` before asserting on the final state.
 
 Hosted Zone IDs are accepted in any real Route53 shape, being a `Z` prefix followed by uppercase
 alphanumerics, up to 32 characters. A real Hosted Zone ID copied out of an AWS account, such as
@@ -65,14 +66,12 @@ alphanumerics, up to 32 characters. A real Hosted Zone ID copied out of an AWS a
 
 ## Registering a Hosted Zone with a chosen ID
 
-`CreateHostedZoneCommand` allocates its own Hosted Zone ID, as real Route53 does, and takes none
-from you. When something else already decided the ID, register the Hosted Zone as part of your test
-setup instead.
+`CreateHostedZoneCommand` allocates the hosted zone ID. When a synthesized template already contains
+an ID, register that hosted zone during test setup instead.
 
-The usual reason is a CDK app that looks its zone up with `HostedZone.fromLookup` instead of
-creating it. That bakes the real Hosted Zone ID into the synthesized template, and every
-`AWS::Route53::RecordSet` in the template names that ID. Registering the zone first lets the
-template deploy as it is, with no rewriting.
+For example, `HostedZone.fromLookup` writes the resolved hosted zone ID into the synthesized
+template. Registering that ID before deployment lets its `AWS::Route53::RecordSet` resources deploy
+without changing the template.
 
 ```typescript sim-route53-register-hosted-zone
 /**
@@ -1701,8 +1700,9 @@ await scopedRoute53.createHostedZone(
 );
 ```
 
-Each `SimAws` instance has its own isolated state. Create a fresh instance per test, or share one
-across related local setup.
+Each `SimAws` instance has its own isolated state. Application tests should normally use the instance
+from their shared [test suite setup](https://yulinsim.dev/testing/). A fresh instance remains useful
+when a test specifically needs an empty simulated account.
 
 ## Standalone SimRoute53
 
@@ -1732,7 +1732,7 @@ console.log(hostedZoneCreation.HostedZone?.Id);
 A standalone `SimRoute53` instance has its own isolated state, standing apart from any wider
 `SimAws` environment. Use `SimAws` when Route53 needs to resolve names to other simulated services.
 
-## Available functionality
+## Supported operations
 
 Sim Route53 currently supports:
 

package/docs/services/s3/README.md

@@ -1,13 +1,12 @@
 # Simulated S3
 
-Yulin includes a simulated S3 service for tests and local development.
+Yulin simulates S3 buckets, objects, policies, notifications and website hosting. Use
+`simAws.s3()` as part of a simulated AWS environment or create a standalone `SimS3`.
+`serveSimAws` exposes the S3 API and website endpoints over localhost.
 
-Sim S3 can be used directly through `SimAws` or instantiated on its own as `SimS3` with isolated
-state. Yulin can serve a simulated S3 service on localhost.
+## Create a bucket and object
 
-## Basic usage
-
-Create a simulated AWS environment, get simulated S3, create a Bucket, and put an Object into it.
+Create a bucket, write an object and read it back.
 
 ```typescript sim-s3-bucket
 /**
@@ -104,15 +103,15 @@ await scopedS3.createBucket(
 );
 ```
 
-Within one `SimAws` instance, Bucket names are globally registered across Accounts and Regions.
-Creating a Bucket with a name already used in another simulated Region or Account throws an error.
+Bucket names are global within a `SimAws` instance. Creating the same name in another simulated
+account or region fails.
 
-Each `SimAws` instance has its own isolated state. Create a fresh one per test or share one across
-all tests, as you prefer.
+Each `SimAws` instance has isolated state.
 
-## Listing Buckets
+## Listing buckets
 
-Use `ListBucketsCommand` to inspect Buckets in the selected simulated S3 scope. Each Bucket reports the instant it was created, taken from [simulated time](https://yulinsim.dev/time/) rather than the host clock.
+`ListBucketsCommand` lists buckets in the selected account and region. Each bucket reports its
+creation time from the [simulated clock](https://yulinsim.dev/time/).
 
 ```typescript sim-s3-list-buckets
 /**
@@ -137,17 +136,20 @@ console.log(listBucketsOutput.Buckets?.map((bucket) => bucket.Name));
 console.log(listBucketsOutput.Buckets?.[0]?.CreationDate);
 ```
 
-## Asking whether something is there
+## Checking whether a bucket or object exists
 
-`HeadObjectCommand` reports what a read would say about an Object without returning the Object, and `HeadBucketCommand` reports whether a Bucket is there and reachable. `HeadBucket` also reports the Region it was found in.
+`HeadObjectCommand` returns object metadata without the body. `HeadBucketCommand` checks that a
+bucket exists and is accessible, and reports its region.
 
-A HEAD response carries no body, so there is no document for an error code to travel in. Real S3 answers a `HeadObject` with `403` or `404`, and a `HeadBucket` with `400`, `403` or `404`, leaving the SDK to name the failure from the status alone. The simulator answers `404` for an absent Bucket and an absent Object alike, which an SDK client raises as `NotFound`, and `403` for a caller the permission is missing for. A read distinguishes `NoSuchBucket` from `NoSuchKey`, because a read has a body to say which.
+A HEAD response has no error document. Yulin returns 404 for a missing bucket or object, which the
+SDK raises as `NotFound`. It returns 403 when the caller lacks permission. `GetObject` can distinguish
+`NoSuchBucket` from `NoSuchKey` because its error response has a body.
 
 `HeadObject` authorizes against `s3:GetObject` and `HeadBucket` against `s3:ListBucket`, as real S3 does, so knowing something is there needs the permission to read it.
 
-## Listing Objects
+## Listing objects
 
-Use `ListObjectsV2Command` to list the Objects in a Bucket. The simulator supports `Prefix`,
+Use `ListObjectsV2Command` to list objects in a bucket. Yulin supports `Prefix`,
 `Delimiter`, `MaxKeys`, `ContinuationToken` and `StartAfter`, and answers with `Contents`,
 `CommonPrefixes`, `KeyCount`, `IsTruncated` and `NextContinuationToken`.
 
@@ -197,18 +199,16 @@ for (const object of listedObjects) {
 }
 ```
 
-Listings are sorted by key, and a page holds at most 1,000 keys, as in real S3. `MaxKeys` above that
-is lowered to it, and the response reports the page size that was actually used. A `MaxKeys` of zero
-returns no keys and completes the listing, and a negative one is refused with `InvalidArgument`.
+Listings sort objects by key and return at most 1,000 entries. Larger `MaxKeys` values are capped at
+1,000. Zero returns an empty complete page, and a negative value raises `InvalidArgument`.
 
 A listing that found no keys has no `Contents` at all, and the example reaches for `Contents ?? []`
 for that reason. `KeyCount` is the count either way.
 
 ### Walking a truncated listing
 
-A truncated response carries `NextContinuationToken`, which the next request passes as
-`ContinuationToken`. The token is opaque, as it is in real S3. Pass it back unchanged, read nothing
-out of it, and simulated S3 refuses one it did not issue.
+A truncated response includes `NextContinuationToken`. Pass it unchanged as `ContinuationToken` in
+the next request. Yulin rejects tokens it did not issue.
 
 ```typescript sim-s3-list-objects-v2-pagination
 /**
@@ -533,9 +533,8 @@ An Object uploaded in parts gets a different form. See
 
 ## Uploading an Object in parts
 
-`aws s3 cp` switches to a multipart upload above eight megabytes, and `@aws-sdk/lib-storage` uploads
-in parts whatever the size. Sim S3 answers the six operations that path is made of, over the SDK and
-over a served endpoint alike.
+Yulin supports multipart upload through the SDK and served S3 endpoint. This covers the operations
+used by `aws s3 cp` for files above eight megabytes and by `@aws-sdk/lib-storage`.
 
 ```bash
 aws s3 cp ./big.bin s3://widgets/big.bin   # 12MB, multipart under the covers
@@ -846,9 +845,8 @@ See [Serve simulated S3 on localhost](#serve-simulated-s3-on-localhost) for sett
 
 ## Deleting Objects
 
-Use `DeleteObjectCommand` to remove one Object, and `DeleteObjectsCommand` to remove several in one
-request. Both are authorized against `s3:DeleteObject` on the Object ARN. A caller allowed to read a
-Bucket cannot empty it.
+Use `DeleteObjectCommand` to remove one object or `DeleteObjectsCommand` to remove several. Each
+object requires `s3:DeleteObject` permission on its ARN.
 
 ```typescript sim-s3-delete-object
 /**
@@ -931,9 +929,9 @@ failures come back.
 
 ## Object versioning
 
-A versioned Bucket keeps every write of a key instead of overwriting it, and answers a delete with a
-marker rather than removing anything. Turn it on with `PutBucketVersioningCommand`, or with
-`VersioningConfiguration` on an `AWS::S3::Bucket` resource.
+A versioned bucket keeps each write as a separate version. Deleting a key adds a delete marker. Enable
+versioning with `PutBucketVersioningCommand` or the `VersioningConfiguration` property of an
+`AWS::S3::Bucket`.
 
 ```typescript sim-s3-object-versioning
 import {
@@ -1096,12 +1094,11 @@ A delete on a versioned Bucket raises `s3:ObjectRemoved:DeleteMarkerCreated` rat
 
 ## Object Lock
 
-Object Lock holds a version of an Object against a delete. A version can be held by a retention
-period, by a legal hold or by both, and a delete naming a held version is answered with
-`AccessDenied`. One way past exists and it is narrow. A `GOVERNANCE` retention period gives way to a
-request carrying `BypassGovernanceRetention` from a caller allowed to use it. A `COMPLIANCE` period
-and a legal hold hold against everyone, the account root included. Turn it on with `PutObjectLockConfigurationCommand`, or with
-`ObjectLockEnabled` on an `AWS::S3::Bucket` resource.
+Object Lock protects an object version with a retention period, a legal hold, or both. Deleting a
+protected version raises `AccessDenied`. A caller with `s3:BypassGovernanceRetention` may bypass
+`GOVERNANCE` retention by setting `BypassGovernanceRetention`. `COMPLIANCE` retention and legal
+holds cannot be bypassed. Enable Object Lock with `PutObjectLockConfigurationCommand` or
+`ObjectLockEnabled` on an `AWS::S3::Bucket`.
 
 Object Lock holds a version, and versioning has to be on underneath it. Turning it on over a Bucket
 with versioning off is refused with `InvalidBucketState`, as real S3 refuses it, and a template
@@ -1256,8 +1253,8 @@ Bucket created around the property would report a default retention it never app
 
 ## Event notifications
 
-A simulated S3 Bucket can notify a simulated Lambda function, a simulated SQS queue or a simulated
-SNS topic when an Object is created or removed. The configuration is applied with
+A simulated bucket can notify Lambda, SQS or SNS when an object is created or removed. Apply the
+configuration with
 `PutBucketNotificationConfigurationCommand` and read back with
 `GetBucketNotificationConfigurationCommand`.
 
@@ -1360,10 +1357,10 @@ can take the `.jpg` files under a prefix while another takes the `.png` files un
 The rule applies across the destination groups. A function and a queue that both want the same
 event are refused as readily as two functions.
 
-`PutBucketNotificationConfigurationCommand` replaces the whole configuration rather than adding to
-it. `GetBucketNotificationConfigurationCommand` answers an empty configuration for a Bucket that has
-none. Note that the response carries the destination groups at the top level, while the request nests
-them under `NotificationConfiguration`:
+`PutBucketNotificationConfigurationCommand` replaces the complete configuration.
+`GetBucketNotificationConfigurationCommand` returns an empty configuration when none is set. The
+request nests destination groups under `NotificationConfiguration`, while the response puts them at
+the top level:
 
 ```typescript
 const read = await simAws
@@ -1476,9 +1473,9 @@ function is.
 
 ### To an SQS queue
 
-A `QueueConfigurations` entry names a queue by ARN. The whole `Records` document arrives as one
-message body, and a consumer parses `record.body` to get at the event. Put a Lambda event source
-mapping on the queue and the chain runs end to end after one `backgroundTasksComplete()`.
+A `QueueConfigurations` entry names a queue by ARN. S3 sends the complete `Records` document as one
+message body. Add a Lambda event source mapping to consume it, then call
+`backgroundTasksComplete()` to finish the delivery chain.
 
 The queue's `Policy` attribute has to allow `sqs:SendMessage` for the `s3.amazonaws.com` service
 principal. S3 supplies `aws:SourceArn` and `aws:SourceAccount`. The `ArnLike` condition CDK's
@@ -1633,10 +1630,9 @@ its own policy and its own Account's IAM are what admit the Bucket. A FIFO queue
 
 ### To an SNS topic
 
-A `TopicConfigurations` entry names a topic by ARN. The whole `Records` document is published as the
-SNS `Message`, with a `Subject` of `Amazon S3 Notification`, as real S3 publishes it. A queue
-subscribed to the topic therefore has two envelopes to reach through. Parse the message body for the
-SNS envelope, then parse its `Message` for the S3 event.
+A `TopicConfigurations` entry names a topic by ARN. S3 publishes the complete `Records` document as
+the SNS `Message` with the subject `Amazon S3 Notification`. A subscribed queue receives an SNS
+envelope whose `Message` contains the S3 event.
 
 The topic's `Policy` attribute has to allow `sns:Publish` for the `s3.amazonaws.com` service
 principal. S3 supplies `aws:SourceArn` and `aws:SourceAccount`. The `ArnLike` condition CDK's

package/docs/services/scheduler/README.md

@@ -1,14 +1,12 @@
 # Simulated EventBridge Scheduler
 
-Yulin includes a simulated Amazon EventBridge Scheduler for tests and local development. Schedules
-are held in memory and every operation is authorized by simulated IAM. Scheduler-specific types are
-imported from the `@kensio/yulin/scheduler` subpath.
+Yulin simulates Amazon EventBridge Scheduler in memory. Schedules run when simulated time advances,
+and every management operation is authorized by simulated IAM. Import Scheduler-specific types from
+`@kensio/yulin/scheduler`.
 
-Scheduler is a separate service from [EventBridge](https://yulinsim.dev/services/eventbridge/), not a corner of it. It has its
-own SDK client, its own ARN shape, and its own way of reaching a target. A schedule assumes an IAM
-execution role, where an EventBridge rule relies on a resource policy admitting a service principal.
-A project using Scheduler cannot be tested against simulated EventBridge rules. That is why this
-exists separately.
+Scheduler is separate from [EventBridge](https://yulinsim.dev/services/eventbridge/). It uses its own
+SDK client and ARN format. It also assumes an execution role to invoke a target, while EventBridge
+rules use the target's resource policy.
 
 ## Creating a schedule
 
@@ -56,8 +54,7 @@ IAM policy naming a schedule needs the group in it, or it matches no schedule.
 
 ## Writing the schedule expression
 
-Three forms, and the same parser as an [EventBridge scheduled
-rule](https://yulinsim.dev/services/eventbridge/#rules-that-fire-on-a-schedule) with two differences:
+Scheduler accepts three expression forms:
 
 - `at(yyyy-mm-ddThh:mm:ss)` runs once, at that instant. The timezone is a separate setting on the
   schedule, outside the expression, and a trailing `Z` is refused.
@@ -71,9 +68,7 @@ rule](https://yulinsim.dev/services/eventbridge/#rules-that-fire-on-a-schedule)
 
 ## Firing a schedule
 
-A schedule fires on the simulation's clock. Advancing simulated time past a due
-instant invokes the target. Leave time alone and the target is never invoked. A nightly job takes no
-time at all to test.
+A schedule fires on the simulation's clock. Advance time past a due instant to invoke the target.
 
 ```typescript sim-scheduler-firing
 /**
@@ -163,12 +158,11 @@ own to describe.
 
 ### The execution role
 
-This is the part that differs most from an [EventBridge rule](https://yulinsim.dev/services/eventbridge/), and the part that
-most often goes wrong in a real account. A rule reaches its target as the `events.amazonaws.com`
-service principal, and the target's own resource policy decides. A schedule assumes the `RoleArn` on
-its target, and that role's policies decide. No resource policy on the target is involved at all.
+A schedule assumes the target's `RoleArn`, and that role's policies authorize delivery. An
+[EventBridge rule](https://yulinsim.dev/services/eventbridge/) instead invokes as
+`events.amazonaws.com` and depends on the target's resource policy.
 
-Two things therefore have to be right, and they are fixed in different places:
+The execution role needs both:
 
 - The role's **trust policy** has to let `scheduler.amazonaws.com` assume it. A role copied from an
   EventBridge rule trusts `events.amazonaws.com` and fails here.
@@ -176,14 +170,13 @@ Two things therefore have to be right, and they are fixed in different places:
   `sqs:SendMessage`, `sns:Publish` or `ecs:RunTask`.
 
 A trust policy may also carry the condition AWS recommends against the confused deputy problem. The
-schedule's group ARN is supplied as `aws:SourceArn`, and the Account the schedule is in as
-`aws:SourceAccount`. A role scoped to one schedule group is assumable by schedules in that group and
-by nothing else. CDK writes that condition into the execution roles it generates for a schedule
-target, so a role taken from a synthesized template works here unchanged.
+schedule's group ARN is supplied as `aws:SourceArn`, and the account is supplied as
+`aws:SourceAccount`. A role scoped to one schedule group is assumable only by schedules in that
+group. CDK writes that condition into the execution roles it generates for a schedule target, so a
+role from a synthesized template works unchanged.
 
-When either is missing the target goes uninvoked and no error is thrown, exactly as on AWS, where the
-failure goes to CloudWatch and nowhere the caller can see. `advanceBy(...)` still returns normally. A
-test asserting on a failed invocation reads `deliveryFailures`:
+If either permission is missing, `advanceBy(...)` still returns normally and the target is not
+invoked. Read `deliveryFailures` to assert on the failed delivery:
 
 ```typescript sim-scheduler-delivery-failures
 /**
@@ -256,9 +249,8 @@ following delay doubles to 2, 4, 8 seconds and so on. A retry does not run while
 still. `advanceBy(...)` runs every retry that becomes due in the interval and settles their work
 before it returns.
 
-Scheduler does not retry a failure that cannot clear by trying the same request. A missing target,
-a missing execution role, an execution role that does not trust Scheduler and an IAM denial are
-permanent failures. They are abandoned after the initial attempt.
+Scheduler retries only failures that may clear. A missing target, missing execution role, invalid
+trust policy, or IAM denial is permanent and is abandoned after the initial attempt.
 
 Set `Target.DeadLetterConfig.Arn` to a standard SQS queue ARN to keep an input that Scheduler abandons.
 The execution role needs `sqs:SendMessage` on this queue as well as permission to invoke the target.
@@ -267,19 +259,17 @@ shape and include the error, schedule ARN, target ARN, scheduled time and retry
 `EXHAUSTED_RETRY_CONDITION` is `MaximumRetryAttempts` or `MaximumEventAgeInSeconds` for an exhausted
 retryable failure. A permanent failure leaves that attribute out.
 
-A successful DLQ send does not add an entry to `deliveryFailures`, since the configured destination
-received the input. A missing queue or denied `sqs:SendMessage` is recorded there instead. This keeps
-a misconfigured DLQ visible to a test.
+A successful DLQ send leaves `deliveryFailures` empty because the configured destination received the
+input. A missing queue or denied `sqs:SendMessage` is recorded there instead.
 
 ### One-time schedules and what happens after
 
-An `at(...)` schedule fires once and then stops. By default it stays in the Account afterwards, which
-surprises people who expected it to clean up. It keeps counting against the schedule quota and keeps
-turning up in listings. `ActionAfterCompletion: "DELETE"` is what removes it, and after that
-`GetSchedule` reports it gone.
+An `at(...)` schedule fires once. It remains in the account unless
+`ActionAfterCompletion: "DELETE"` removes it. A retained schedule continues to appear in listings
+and count against the schedule quota.
 
-A schedule that is disabled when its only instant passes has not completed, since nothing was
-invoked. It is still there afterwards whatever `ActionAfterCompletion` says.
+A disabled schedule remains incomplete when its only instant passes. It stays in the account
+regardless of `ActionAfterCompletion`.
 
 `State: "DISABLED"` stops a recurring schedule firing while it is off, and an `UpdateSchedule`
 enabling it picks up from the next due instant. What it missed is never replayed. An update that
@@ -287,9 +277,8 @@ changes the expression reschedules from the new one.
 
 ## Running an ECS task on a schedule
 
-A target whose ARN names an ECS cluster runs a [simulated ECS](https://yulinsim.dev/services/ecs/) task, in place of being
-invoked with a payload. That is the shape a nightly batch job usually has. A container runs, does
-its work and stops.
+A target whose ARN names an ECS cluster runs a [simulated ECS](https://yulinsim.dev/services/ecs/)
+task. Use `EcsParameters` to select the task definition and use `Input` for task overrides.
 
 ```typescript sim-scheduler-ecs-target
 /**
@@ -404,8 +393,8 @@ target with no `Input` runs the task with no overrides.
 
 [Simulated ECS](https://yulinsim.dev/services/ecs/) decides which containers actually run. A container
 with a binding runs its handler, and a container without one is recorded as not simulated.
-A target naming a task definition with nothing bound therefore records a task that never started,
-and the schedule counts as invoked.
+A target naming a task definition without a bound container records a task that never started, and
+the schedule counts as invoked.
 
 ## Updating and deleting
 
@@ -457,8 +446,8 @@ console.log(described.ScheduleExpression); // "rate(30 minutes)"
 console.log(described.Description); // undefined, and not by accident
 ```
 
-`UpdateSchedule` carries the whole of a schedule, and anything an earlier request set and this one
-leaves out is gone. That is real behaviour and a common surprise. The schedule has to exist.
+`UpdateSchedule` replaces the full schedule definition. Any optional value omitted from the update
+is removed. The schedule must already exist.
 Updating one that is absent raises `ResourceNotFoundException`. EventBridge's `PutRule` creates it.
 
 `CreateSchedule` for a name that already exists raises `ConflictException`. A deployment running it
@@ -618,10 +607,10 @@ against the `RoleArn` on the target.
 
 ## Deploying from a CloudFormation template
 
-`AWS::Scheduler::Schedule` deploys through [simulated CloudFormation](https://yulinsim.dev/services/cloudformation/). A stack
-that declares its schedules can be exercised end to end, with no SDK calls of its own. Everything the
-Resource carries lines up with `CreateSchedule`, and a target ARN or execution role resolved by
-`Fn::GetAtt` from the same template works as it would in a real deployment.
+`AWS::Scheduler::Schedule` deploys through [simulated
+CloudFormation](https://yulinsim.dev/services/cloudformation/). Its properties follow
+`CreateSchedule`, and the target ARN or execution role can use `Fn::GetAtt` references to resources
+in the same template.
 
 ```typescript sim-scheduler-cloudformation
 /**
@@ -786,7 +775,7 @@ anyway. Read the record back from `stack.getResource("<logicalId>")?.ignoredProp
 Tearing the stack down removes the group. Its schedules go with it, whether or not they are
 Resources of the same stack.
 
-## Available functionality
+## Supported operations
 
 - `CreateSchedule`, `GetSchedule`, `UpdateSchedule`, `DeleteSchedule` and `ListSchedules`.
 - `at(...)`, `rate(...)` and six-field `cron(...)` expressions, fired by advancing the simulation's
@@ -839,7 +828,7 @@ Resources of the same stack.
 - A target `EventBridgeParameters`, `KinesisParameters`, `SageMakerPipelineParameters` and
   `SqsParameters` are refused outright, as is `EcsParameters` on a target whose ARN names something
   other than an ECS cluster. A `DeadLetterConfig` must name a standard SQS queue because simulated
-  SQS does not support FIFO queues.
+  SQS supports only standard queues.
 - An ECS target's `EcsParameters` takes `TaskDefinitionArn` and `TaskCount`, and takes and ignores
   `LaunchType`, `PlatformVersion`, `NetworkConfiguration` and `CapacityProviderStrategy`, since
   there is no placement and no network here for them to apply to. Anything else it can carry, such
@@ -849,5 +838,5 @@ Resources of the same stack.
   on an ECS target, where every other target type takes any text.
 - A `TaskCount` above one runs that many simulated tasks, and a bound container handler runs once
   for each of them, in this process and one after another.
-- `KmsKeyArn` is refused, and `ClientToken` is accepted and ignored. Schedule management requests
-  are not retried, so the token has no request to make idempotent.
+- `KmsKeyArn` is refused, and `ClientToken` is accepted and ignored. Yulin makes each schedule
+  management request once, so the token has no retry to make idempotent.

package/docs/services/secretsmanager/README.md

@@ -1,7 +1,7 @@
 # Simulated Secrets Manager
 
-Yulin includes a simulated AWS Secrets Manager for tests and local development. Secrets are stored
-in memory, versioned by staging label, and every operation is authorized by simulated IAM.
+Yulin simulates AWS Secrets Manager in memory. Secrets have encrypted versions and staging labels,
+and simulated IAM authorizes every operation.
 
 Secrets Manager-specific types are imported from the `@kensio/yulin/secretsmanager` subpath.
 
@@ -45,19 +45,14 @@ on read.
 
 ## Encryption and KMS permissions
 
-Every version is encrypted through simulated KMS when it is written and decrypted when
-`GetSecretValue` reads it. There is no flag for reading a secret without decrypting it. The read
-either returns the plaintext or fails.
+Every secret version is encrypted through simulated KMS. `GetSecretValue` decrypts the version and
+either returns its plaintext or fails.
 
-A secret naming no `KmsKeyId` uses the `aws/secretsmanager` AWS managed key, which asks the caller
-for no KMS permission at all. Secrets Manager supplies `kms:ViaService`, and that key's policy allows
-the account's principals to use it through Secrets Manager. A Lambda role granted only
-`secretsmanager:GetSecretValue` therefore reads the secret, as it does on real AWS.
+A secret without `KmsKeyId` uses the `aws/secretsmanager` AWS managed key. Its policy permits use
+through Secrets Manager, so callers do not need a separate KMS permission.
 
-Pass `KmsKeyId` to encrypt under a customer managed key instead, and the caller's own permissions on
-that key start to matter. Secrets Manager uses envelope encryption, asking KMS for a data key per
-version. A write needs `kms:GenerateDataKey` and a read needs `kms:Decrypt`. A role granted the
-secret but not the key fails here, ahead of a deployment.
+Pass `KmsKeyId` to use a customer managed key. Writing a version requires `kms:GenerateDataKey`, and
+reading it requires `kms:Decrypt`, in addition to the relevant Secrets Manager permission.
 
 ```typescript sim-secrets-manager-customer-key
 /**
@@ -141,10 +136,9 @@ they were made with and stay readable, as they do on real AWS.
 
 ## Secret ARNs and IAM policies
 
-Real Secrets Manager appends a hyphen and six random characters to the secret name in its ARN. A
-secret named `db-creds` gets an ARN ending `:secret:db-creds-AbCdEf`, and sim Secrets Manager does
-the same. A policy naming the bare ARN therefore matches nothing, and a policy has to end in
-`-??????` or a wildcard.
+Secret ARNs end with a hyphen and six random characters. A secret named `db-creds`, for example,
+gets an ARN ending in `:secret:db-creds-AbCdEf`. An IAM resource pattern for the secret must include
+that suffix, such as `-??????` or `-*`.
 
 ```typescript sim-secrets-manager-iam-policy
 /**
@@ -214,17 +208,16 @@ nothing, here as there.
 
 ## Naming a secret
 
-Every operation takes its target as a `SecretId`, in any of the three forms real Secrets Manager
-accepts. Those are the friendly name, the full ARN including the suffix, and the partial ARN without
-it.
+`SecretId` accepts the friendly name, the full ARN with its random suffix, or the partial ARN without
+the suffix.
 
 An ARN naming another account or region resolves to no secret at all. Its name is never read out and
 looked up locally, and a foreign ARN cannot reach a secret that happens to share a name.
 
 ## Versions and staging labels
 
-Every write creates a version, leaving the earlier ones in place. `AWSCURRENT` names the version a
-plain read returns, and writing a new current version demotes the previous one to `AWSPREVIOUS`.
+Every write creates a version. `AWSCURRENT` marks the version returned by a plain read. Writing a new
+current version moves `AWSPREVIOUS` to the former current version.
 
 ```typescript sim-secrets-manager-staging-labels
 /**
@@ -273,12 +266,9 @@ label. A version that has lost every label is on its way out of existence, and i
 
 ## Deletion and the recovery window
 
-`DeleteSecret` schedules deletion for later. The recovery window is 7 to 30 days, defaulting to 30.
-During that window the secret is still there. It can be described and restored, it refuses to be
-read or written, and it still holds its name.
-
-Holding the name is what a redeployed stack hits. Advancing the simulated clock past the window frees
-it.
+`DeleteSecret` schedules deletion after a recovery window of 7 to 30 days, defaulting to 30. During
+that window the secret can be described or restored, but it cannot be read or changed. Its name also
+remains reserved. Advance simulated time past the window to complete deletion.
 
 ```typescript sim-secrets-manager-deletion
 /**
@@ -435,14 +425,14 @@ console.log(credentials.username); // "app"
 console.log(credentials.password?.length); // 24
 ```
 
-Generated passwords are random. A test reads the value back out of the simulation the way a deployed
-application does.
+Generated passwords are random. Read the deployed value through Secrets Manager instead of asserting
+on an exact password.
 
 ## Reading a secret with a dynamic reference
 
-A template reads a secret that already exists through a `{{resolve:secretsmanager:...}}` dynamic
-reference. The reference is replaced with the secret's value as the resource holding it is created.
-CDK emits one from `SecretValue.secretsManager`.
+A `{{resolve:secretsmanager:...}}` dynamic reference reads an existing secret while CloudFormation
+creates the resource containing the reference. CDK emits this form for
+`SecretValue.secretsManager`.
 
 The whole form is
 `{{resolve:secretsmanager:secret-id:secret-string:json-key:version-stage:version-id}}`. Only the
@@ -554,11 +544,10 @@ another resource of the same stack creates is only there in time when the templa
 Resource properties are reported as they resolved, including this one. Real CloudFormation keeps a
 resolved secret out of its own logs and events, and sim CloudFormation has no such protection.
 
-### A reference the simulation cannot answer
+### Unresolved references
 
-Simulated CloudFormation deploys what it can. A reference naming a secret that was never created
-resolves to `dummy-value-for-<secret-id>`, and the stack carries on deploying. A template reading a
-secret a test does not care about is still worth deploying for everything else in it.
+If Yulin cannot resolve a reference, it substitutes `dummy-value-for-<secret-id>` and continues the
+deployment.
 
 The substitution is recorded on
 [`stack.ignoredProperties`](https://yulinsim.dev/services/cloudformation/#properties-a-resource-was-created-without),
@@ -596,9 +585,7 @@ The same applies to `SimSdk` interception. Intercepting `SecretsManagerClient` r
 code into the simulation, served in process. See
 [AWS SDK interception](https://yulinsim.dev/sdk/ "Simulated AWS SDK docs").
 
-## Available functionality
-
-Sim Secrets Manager currently supports:
+## Supported operations
 
 - `CreateSecretCommand`, holding either a string or binary
 - `GetSecretValueCommand`, by staging label or by version id
@@ -619,8 +606,6 @@ Sim Secrets Manager currently supports:
 
 ## Limitations
 
-Current documented limitations:
-
 - A `KmsKeyId` is checked when a version is written under it, not when it is set on its own. An
   `UpdateSecret` changing only the key accepts a key that is absent, and the next write of a value
   fails.