@kensio/yulin 1.21.6 → 1.21.8

package/docs/services/cognito/README.md

@@ -1,17 +1,14 @@
 # Simulated Cognito IDP
 
-Yulin includes a simulated Cognito user pool directory for tests and local development. Pools and
-their app clients are held in memory, and every operation is authorized by simulated IAM.
+Yulin simulates Cognito user pools, app clients, users, groups, tokens, hosted domains and Lambda
+triggers. Use `simAws.cognitoIdp()` directly or intercept a `CognitoIdentityProviderClient`.
+Cognito types are available from `@kensio/yulin/cognito`.
 
-Only user pools are simulated. Cognito identity pools, which exchange a token for AWS credentials,
-are a different service and are outside the simulation.
-
-Cognito-specific types are imported from the `@kensio/yulin/cognito` subpath.
+Cognito identity pools are unsupported.
 
 ## Creating a pool and an app client
 
-A pool needs a name. Everything else has a default, and the defaults here are the ones real Cognito
-applies.
+A user pool needs a name. Other properties use Cognito's defaults.
 
 ```typescript sim-cognito-create-user-pool
 /**
@@ -46,16 +43,14 @@ const appClient = await cognito.createUserPoolClient(
 console.log(appClient.UserPoolClient?.ClientId); // 26 lowercase characters
 ```
 
-A pool id names the region the pool was created in, as real pool ids do. Application code that
-splits the id on the underscore to find the region works here for the same reason it works on AWS.
+A pool ID contains the region before its underscore, matching Cognito's ID format.
 
 Two pools may share a name. Only the id identifies one.
 
 ## Password policy
 
-A pool created without a `Policies` of its own gets the real default of eight characters, with an
-uppercase letter, a lowercase letter, a number and a symbol each required. A request setting some of
-those keeps the defaults for the rest.
+A pool created without `Policies` requires at least eight characters with uppercase, lowercase,
+numeric and symbol characters. Setting part of the policy keeps the defaults for omitted fields.
 
 ```typescript sim-cognito-password-policy
 /**
@@ -86,10 +81,9 @@ with `InvalidPasswordException`, saying which rule it broke.
 
 ## Users
 
-`AdminCreateUser` creates a user in `FORCE_CHANGE_PASSWORD`, where real Cognito leaves a user an
-admin made. It has a temporary password and cannot sign in with it. Setting a permanent password
-moves the user to `CONFIRMED`. The sign-in flows read that status. A user in
-`FORCE_CHANGE_PASSWORD` gets the `NEW_PASSWORD_REQUIRED` challenge, not tokens.
+`AdminCreateUser` creates a user in `FORCE_CHANGE_PASSWORD` with a temporary password. Sign-in
+returns the `NEW_PASSWORD_REQUIRED` challenge until `AdminSetUserPassword` sets a permanent
+password. A permanent password changes the status to `CONFIRMED`.
 
 ```typescript sim-cognito-create-user
 /**
@@ -145,11 +139,9 @@ console.log(read.UserAttributes?.find((each) => each.Name === "sub")?.Value);
 A password set without `Permanent: true` is temporary, and leaves the user in
 `FORCE_CHANGE_PASSWORD` again.
 
-A user's `sub` is a UUID Cognito allocates, reported among its attributes. It is not the username,
-and code treating the two as interchangeable fails here, and not in a deployment. Admin
-operations here name a user by its username only. Real Cognito also accepts a `sub` where an
-operation asks for a username. That is one thing that works there and not here. The refusal says so
-when the username given is some user's `sub`.
+A user's `sub` is a generated UUID and differs from the username. Yulin's admin operations accept
+the username only. Cognito also accepts a `sub` for some operations, which Yulin reports as an
+unsupported lookup.
 
 Attributes come back under `Attributes` from `AdminCreateUser` and `ListUsers`, and under
 `UserAttributes` from `AdminGetUser`, as the real API names them.
@@ -160,11 +152,9 @@ Attributes come back under `Attributes` from `AdminCreateUser` and `ListUsers`,
 
 ## Signing in by email or phone number
 
-A pool created with `UsernameAttributes` signs its users in by that attribute, not by a username
-they chose. Cognito generates a UUID as the username for such a user, and the value the
-request called the username goes into the attribute the pool signs in by. That generated username
-is what `AdminGetUser` reports and what the `cognito:username` claim carries. An application reading
-"the username" off such a pool reads a UUID.
+A pool with `UsernameAttributes` signs users in with an email address or phone number. Cognito
+generates a UUID for the stored username. `AdminGetUser` and the `cognito:username` token claim
+report that UUID.
 
 A CDK `UserPool` with `signInAliases: { email: true }` emits `UsernameAttributes: ["email"]`, the
 usual way to build an email sign-in pool.
@@ -384,13 +374,11 @@ outside the simulation.
 
 ## Signing up
 
-`SignUp` is the other way a user gets into a pool. It names an app client rather than a pool, is
-authorized by no IAM policy, and leaves the user in `UNCONFIRMED` with the password it chose.
+`SignUp` creates an `UNCONFIRMED` user through an app client. The operation does not use IAM
+authorization.
 
-Real Cognito emails or texts a confirmation code at that point. Nothing here delivers a message, and
-the code is readable from the pool instead, through `confirmationCode` on the pool object. That is a
-deliberate divergence. Real Cognito never reports a code back to anyone, and reading one is what
-makes a registration flow testable at all.
+Read the confirmation code from `confirmationCode` on the simulated pool. Cognito sends the code by
+email or text and never exposes it through the service API.
 
 The pool also records the message it would have sent, holding the wording and the code a user
 would have read. That is in [Messages a pool would have sent](#messages-a-pool-would-have-sent)
@@ -500,9 +488,8 @@ the deployed pool would give. A pool created without the setting allows sign-up,
 
 ## Resetting a forgotten password
 
-A user that cannot get in asks for a code with `ForgotPassword` and sets a new password with
-`ConfirmForgotPassword`. Both name an app client, and neither is authorized by an IAM policy. They
-are the pair an application calls when it has built its own sign-in screens.
+`ForgotPassword` sends a code and `ConfirmForgotPassword` sets the new password. Both operations use
+an app client and bypass IAM authorization.
 
 The code goes to the same place a sign-up code goes, and is read back the same way, through
 `confirmationCode` on the pool object. `ForgotPassword` answers with `CodeDeliveryDetails` naming
@@ -633,9 +620,8 @@ are refused for one.
 
 ## Messages a pool would have sent
 
-Nothing here delivers an email or a text message. A pool records what it would have sent instead,
-and `sentMessages` on the pool object hands the record over. Each message carries the recipient, the
-medium, the subject, the body and the occasion it was sent on.
+The pool records outgoing email and text messages in `sentMessages`. Each entry contains the
+recipient, medium, subject, body and message type.
 
 A message is recorded on five occasions. Those are a `SignUp`, a `ResendConfirmationCode`, an
 `AdminCreateUser` that did not ask for `MessageAction: SUPPRESS`, an MFA code sent by text message,
@@ -2060,10 +2046,9 @@ own users at the same address, which real Cognito keeps as two accounts until
 `AdminLinkProviderForUser` merges them. That operation is unsimulated.
 
 Posting the page carries on into the sign-in the authorize endpoint already runs, ending in the same
-`<ProviderName>_<subject>` user and the same authorization code. Nothing is kept on the provider
-afterwards: a further authorize request asks again, because real Cognito asks the provider afresh
-every time. A provider that `signInAs` has already put somebody at skips the page, which is what
-leaves a test that says who is signing in seeing none of this.
+`<ProviderName>_<subject>` user and the same authorization code. Provider state is discarded after
+the request. A later authorize request asks again because real Cognito asks the provider afresh each
+time. A provider configured with `signInAs` skips the page and uses the configured identity.
 
 `/signup` is a link from that page. Its form asks for a username, a password and the attributes the
 pool needs, which are the ones its `Schema` made required and the ones its `AutoVerifiedAttributes`
@@ -3704,8 +3689,8 @@ console.log(described.UserPoolClient?.ClientName);
 
 A registered pool behaves like any other. It answers `DescribeUserPoolCommand` and
 `ListUserPoolsCommand`, holds users, groups and app clients, and serves its JWKS and OpenID
-configuration on localhost. Everything written against a pool id follows from the id it was
-registered under: its ARN, its issuer URL, the `iss` claim of its tokens and its `ProviderName`. A
+configuration on localhost. The registered ID determines the pool ARN, issuer URL, token `iss` claim
+and `ProviderName`. A
 policy naming `arn:aws:cognito-idp:eu-west-2:111111111111:userpool/eu-west-2_aBcDeFgHi` authorizes
 the handler that reads the pool, which is what a template carrying the id in two places needs.
 

package/docs/services/dynamodb/README.md

@@ -1,18 +1,13 @@
 # Simulated DynamoDB
 
-Yulin includes a simulated DynamoDB for tests and local development. Tables are held in memory, and
-every operation is authorized by simulated IAM.
-
-This page covers creating, describing, listing and deleting tables. What a request says is checked
-the way real DynamoDB checks it. A table that can be created here is one that could be created on
-AWS.
-
-DynamoDB-specific types are imported from the `@kensio/yulin/dynamodb` subpath.
+Yulin simulates DynamoDB tables, indexes, items, streams and time to live in memory. Use
+`simAws.dynamoDb()` directly or intercept a `DynamoDBClient`. DynamoDB types are available from
+`@kensio/yulin/dynamodb`.
 
 ## Creating a table
 
-`CreateTable` needs a `TableName`, a `KeySchema`, and an `AttributeDefinitions` entry for every
-attribute the key schema names.
+`CreateTable` requires a table name, a key schema and an attribute definition for every key
+attribute.
 
 ```typescript sim-dynamodb-create-table
 /**
@@ -45,8 +40,7 @@ await simAws.backgroundTasksComplete();
 A new table is `CREATING`, and activation is scheduled as background work. Call
 `simAws.backgroundTasksComplete()` when a test needs the table to be `ACTIVE`.
 
-The description carries back what the request asked for. That is the key schema, the attribute
-definitions, the table ARN, a table ID, and the billing and capacity the table was created with.
+The response describes the table's keys, attribute definitions, ARN, ID, billing mode and capacity.
 
 ## Key schema and attribute definitions
 
@@ -62,9 +56,8 @@ attribute as the type the table declared for it.
 
 ## Billing modes and throughput
 
-`BillingMode` defaults to `PROVISIONED`, making `ProvisionedThroughput` required with at least one
-read and one write capacity unit. A request that leaves both out asks for a provisioned table with
-no capacity, and is refused.
+`BillingMode` defaults to `PROVISIONED`. A provisioned table requires at least one read and one write
+capacity unit in `ProvisionedThroughput`.
 
 `PAY_PER_REQUEST` refuses `ProvisionedThroughput`, since an on-demand table has no capacity to
 provision.
@@ -111,8 +104,8 @@ reports for one.
 
 ## Global secondary indexes
 
-`GlobalSecondaryIndexes` on `CreateTable` declares indexes with a key of their own over the same
-items. Each index needs an `IndexName`, a `KeySchema` and a `Projection`.
+`GlobalSecondaryIndexes` adds indexes over the table's items. Each index requires an `IndexName`,
+`KeySchema` and `Projection`.
 
 ```typescript sim-dynamodb-global-secondary-index
 /**
@@ -583,9 +576,8 @@ console.log(description.Table?.TableStatus); // "ACTIVE"
 
 ## Tagging tables
 
-A table is tagged by `CreateTable`, or afterwards by `TagResource`. `UntagResource` takes tags off,
-and `ListTagsOfResource` reads them back. The three tag commands name their resource by ARN, in
-`ResourceArn`, where the table commands take a name or an ARN.
+Add tags during `CreateTable` or later with `TagResource`. Remove them with `UntagResource` and read
+them with `ListTagsOfResource`. Tag commands require the table ARN in `ResourceArn`.
 
 ```typescript sim-dynamodb-tag-table
 /**
@@ -683,9 +675,8 @@ calling `Tags.of(stack).add("Environment", "test")` gets a tagged table.
 
 ## Writing items
 
-`PutItem` writes one item, replacing the whole item under its primary key rather than merging into
-it. The item is there by the time the call returns. A write and the read that follows it need no
-step in between.
+`PutItem` replaces the complete item stored under the primary key. The write is visible when the
+command returns.
 
 ```typescript sim-dynamodb-put-item
 /**
@@ -739,10 +730,9 @@ anywhere else in the item.
 
 ## Reading and deleting items
 
-`GetItem` reads one item by its primary key, and `DeleteItem` removes one the same way. The `Key`
-both take is the whole primary key and nothing else. A missing key element, an attribute outside the
-key, or a value whose type fails to match the table's `AttributeDefinitions` is a
-`ValidationException` naming the attribute at fault.
+`GetItem` reads an item by primary key. `DeleteItem` removes it. The `Key` must contain every key
+attribute and no others, using the types declared in `AttributeDefinitions`. Invalid keys raise
+`ValidationException`.
 
 ```typescript sim-dynamodb-get-delete-item
 /**
@@ -822,9 +812,8 @@ Both take the table's name or its ARN, as the table commands do.
 
 ## Updating items
 
-`UpdateItem` changes part of an item, where `PutItem` replaces the whole thing. What to change is
-written as an `UpdateExpression` made of `SET`, `REMOVE`, `ADD` and `DELETE` clauses, in any order.
-Each keyword appears at most once, and the actions inside a clause are separated by commas.
+`UpdateItem` changes selected attributes. Its `UpdateExpression` may contain `SET`, `REMOVE`, `ADD`
+and `DELETE` clauses in any order. Each clause may appear once and contain comma-separated actions.
 
 A `SET` action is `path = operand`, where an operand is a value from `ExpressionAttributeValues`,
 another document path, or a call to `if_not_exists(path, operand)` or `list_append(one, other)`. Two
@@ -1066,12 +1055,11 @@ placeholder used by either counts as used.
 
 ## Conditional writes
 
-`PutItem`, `DeleteItem` and `UpdateItem` take a `ConditionExpression`, checked against whatever is
-stored under the key before anything changes. A condition that fails to hold leaves the item exactly
-as it was and throws `ConditionalCheckFailedException`, with the name and message real DynamoDB
-uses.
+`PutItem`, `DeleteItem` and `UpdateItem` evaluate `ConditionExpression` against the stored item before
+writing. A failed condition leaves the item unchanged and raises
+`ConditionalCheckFailedException`.
 
-That is how a write becomes an insert if absent, and how a version attribute becomes optimistic
+Use `attribute_not_exists` for insert-only writes or compare a version attribute for optimistic
 locking.
 
 ```typescript sim-dynamodb-conditional-write
@@ -1176,9 +1164,8 @@ expression, in both directions. A placeholder the request leaves undefined is a
 
 ## Projecting attributes
 
-`GetItem` takes a `ProjectionExpression`, a comma-separated list of document paths. Only those paths
-come back. A path is an attribute name, then any number of `.attribute` dereferences and `[n]` list
-indexes, such as `address.city` or `lines[0].sku`.
+`ProjectionExpression` is a comma-separated list of document paths returned by `GetItem`. A path can
+contain map attributes and list indexes, such as `address.city` or `lines[0].sku`.
 
 An attribute name that is a DynamoDB reserved word, or that has a character an expression cannot
 carry, is written as a `#name` placeholder and defined in `ExpressionAttributeNames`.
@@ -1259,12 +1246,11 @@ index and a path past that depth are each a `ValidationException` naming the pat
 
 ## Querying an item collection
 
-A table with a sort key holds an item collection under each partition key, holding the items with
-that partition key, ordered by their sort key. `Query` reads one of those collections.
+A table with a sort key keeps one ordered item collection per partition key. `Query` reads one
+collection.
 
-`KeyConditionExpression` says which. It is one equality on the partition key, optionally joined by
-`AND` to one condition on the sort key. The sort key condition is `=`, `<`, `<=`, `>`, `>=`,
-`BETWEEN` or `begins_with`, and both bounds of a `BETWEEN` are inside the range.
+`KeyConditionExpression` requires equality on the partition key. It may add one sort key condition
+with `AND`. Sort key operators are `=`, `<`, `<=`, `>`, `>=`, `BETWEEN` and `begins_with`.
 
 ```typescript sim-dynamodb-query
 /**
@@ -1371,8 +1357,8 @@ in `ExpressionAttributeNames`, as in any other expression.
 
 ### Paging a collection
 
-`Limit` counts the items a query evaluated. `LastEvaluatedKey` is the primary key of the item the
-walk stopped on, and the next request passes it back as `ExclusiveStartKey` to resume after it.
+`Limit` counts evaluated items. Pass `LastEvaluatedKey` back as `ExclusiveStartKey` to continue after
+the last evaluated item.
 
 ```typescript sim-dynamodb-query-paging
 /**
@@ -1447,9 +1433,7 @@ from a different partition key is refused, since it names a collection this quer
 
 ## Reading a global secondary index
 
-`IndexName` on `Query` and `Scan` reads an index in place of the table. The key condition is held to
-the index key schema and not the table's, which is the point. The index is how an access pattern the
-table key cannot serve gets served.
+Set `IndexName` on `Query` or `Scan` to read an index. Key conditions then use the index key schema.
 
 ```typescript sim-dynamodb-query-index
 /**
@@ -1572,9 +1556,8 @@ refused.
 
 ## Scanning a table
 
-`Scan` reads every item in a table. It needs no key knowledge at all. That is what makes it the
-operation test setup and assertions reach for, and the wrong operation for most application access
-patterns, since it reads the whole table however few items the caller wanted.
+`Scan` reads every item in a table without a key condition. It is useful for test assertions but
+usually reads more data than application code needs.
 
 ```typescript sim-dynamodb-scan
 /**

package/docs/services/ecr/README.md

@@ -1,31 +1,20 @@
 # Simulated ECR
 
-Yulin includes a simulated Amazon ECR for tests and local development. It holds repositories, and
-each repository holds images by tag, where a simulated image is a real in-process handler.
-
-That is what this service is for. A container image Lambda function cannot run here, because Yulin
-never reads an image, so something has to say what the code inside that image actually is. A
-repository is the natural place to say it. It is the stable name for the thing that holds the code,
-outliving any tag and any CDK construct ID, and a repository holding a registered handler outlives
-the stack that declared it too.
+Yulin represents an ECR image with an in-process Lambda handler. Register the handler against a
+repository and tag, then deploy or create a container image function that uses the image URI.
 
 ECR-specific types are imported from the `@kensio/yulin/ecr` subpath.
 
 ## What a simulated image is
 
-An image URI is only ever an identifier here. No image is pulled or inspected, and no layer,
-manifest, digest or scan finding exists. A simulated image is a handler function, registered against
-a repository and a tag.
+An image URI identifies a registered handler. Image content remains outside the simulation.
 
-Registering one is a Yulin-native operation, named `simulateImage` to keep it clear of a simulated
-`PutImage`. Real `PutImage` takes an image manifest for layers that were pushed over the Docker
-registry protocol. None of that happens in this process, and a simulated `PutImage` would be a
-command taking an argument nothing could produce.
+Use the Yulin-specific `simulateImage` method to register a handler. The simulated surface has no
+ECR SDK or Docker registry operations.
 
 ## Registering a handler as an image
 
-Register the handler once, in test setup, and every function that runs an image from that repository
-is created from it.
+Register the handler during test setup. Lambda resolves image functions from the same repository.
 
 ```typescript sim-ecr-register-image
 /**
@@ -82,36 +71,22 @@ console.log(Buffer.from(output.Payload).toString());
 await simAws.backgroundTasksComplete();
 ```
 
-Naming a repository is what creates it. A repository holds only its images. There is no prior
-declaration to make, and a test can name the repository its templates already point at.
+Calling `repository(name)` creates the repository if it is absent.
 
-The repository takes a bare name such as `orders` or `platform/orders`, and never a full image URI.
-The account, the region and the registry host around it come from the simulated ECR the repository
-belongs to. A name real ECR would refuse is refused here too.
+Pass a repository name such as `orders` or `platform/orders`. The selected simulated account and
+Region supply the registry host.
 
 ## How an image URI is matched
 
-Resolving an image URI happens in two steps, and the tag means something different in each.
-
-Finding the repository ignores the tag. A function's `Code.ImageUri` is matched on the registry host
-and the repository name, with any tag or digest dropped, because no tag is stable enough to write
-into a test. A CDK image asset is tagged with the asset content hash, which changes whenever the
-image source does, and a pipeline-built image is usually tagged with a git sha or a build number
-passed in as a stack parameter. An `ImageUri` built by `Fn::Sub` or from a stack parameter is
-matched on what it resolves to.
+Yulin first matches the registry host and repository name. It then looks for the requested tag. A
+registered tag selects that handler. An unknown tag, a digest or no tag selects the most recently
+registered handler. This fallback lets content-hash and build-number tags resolve without copying
+those generated values into the test.
 
-Choosing the image in that repository does read the tag. A tag the repository holds selects exactly
-that image, and any other tag, or none at all, falls back to the image registered most recently.
+The registry host determines the account and Region. Repositories with the same name in different
+scopes remain separate. Cross-account image references are supported.
 
-The registry host is part of the match, and the account and the region have to agree. A function can
-run an image from another account's repository, as it can on real AWS, and a same-named repository
-in another account is a different repository.
-
-So `orders:blue` runs the handler registered under `blue` where the repository holds one, and the
-handler registered most recently otherwise. That is how a blue/green pair of images in one
-repository can back two functions differently, while a content hash tag nobody registered still
-finds something to run. Registering a tag again both replaces what it held and makes it the most
-recent registration.
+Registering a tag again replaces its handler and makes that handler the most recent registration.
 
 ```typescript sim-ecr-image-tags
 /**
@@ -152,18 +127,15 @@ console.log(Buffer.from(output.Payload).toString()); // "blue handler"
 await simAws.backgroundTasksComplete();
 ```
 
-A function created directly through `CreateFunction` resolves its image the same way a template
-function does, as the example above shows. A function whose image resolves to no handler is refused,
-the way real Lambda refuses a function whose image it cannot pull.
+Direct `CreateFunction` calls and CloudFormation deployments use the same resolution rules. Lambda
+refuses an image URI that resolves to no handler.
 
 ## Repositories in CloudFormation
 
-`AWS::ECR::Repository` creates a simulated repository. A template declares a repository and never an
-image, as real CloudFormation does. A deployed repository starts empty unless a handler has already
-been registered in it.
+Simulated CloudFormation creates `AWS::ECR::Repository`. The repository starts empty unless a
+handler was already registered under its name.
 
-`Ref` returns the repository name, and `Fn::GetAtt` exposes `Arn` and `RepositoryUri`. An
-application stack can build its function's `ImageUri` from the repository a platform stack declared.
+`Ref` returns the repository name. `Fn::GetAtt` supports `Arn` and `RepositoryUri`.
 
 ```typescript sim-ecr-cloudformation-repository
 /**
@@ -236,34 +208,23 @@ console.log(Buffer.from(output.Payload).toString());
 await simAws.backgroundTasksComplete();
 ```
 
-A repository a handler is already registered in is adopted, and the order these happen in makes no
-difference. The image can exist before the stack that declares the repository, as it does in real
-life.
+A deployment adopts a repository that already contains a registered handler.
 
-Tearing the stack down removes the repository only where it holds no simulated image. One that does
-is left where it is, and the deletion is recorded as skipped, because the handler in it was
-registered outside any stack and is what every later deploy resolves to. Real ECR also refuses to
-delete a repository that still holds images, which fails the stack unless the template says
-`EmptyOnDelete`. Here the refusal is recorded and the teardown carries on, since what is being
-protected is a test's own registration.
+Stack teardown removes an empty repository. A repository containing a handler remains in place and
+its deletion is recorded as skipped. Teardown continues after the skipped deletion.
 
-Every other property a repository can declare is recorded as an ignored property, and the repository
-is created without it. That covers `ImageScanningConfiguration`, `ImageTagMutability`,
+Other repository properties are recorded as ignored. These include `ImageScanningConfiguration`, `ImageTagMutability`,
 `LifecyclePolicy`, `RepositoryPolicyText`, `EncryptionConfiguration`, `EmptyOnDelete` and `Tags`.
 
 ## Where a function's handler comes from
 
-Two things can back a container image function, and a deploy is looked at in this order:
+Yulin resolves a container image function in this order:
 
-1. An [executable binding](https://yulinsim.dev/services/lambda/#executable-bindings) given to that deploy, including one
-   naming the image repository. A binding is the more specific thing to have said, since it is about
-   one deploy.
-2. The simulated ECR repository the function's `Code.ImageUri` names. That is a standing statement
-   about what the image is, made once and good for every stack that runs it.
+1. An [executable binding](https://yulinsim.dev/services/lambda/#executable-bindings) supplied for the deployment.
+2. The handler registered in the ECR repository named by `Code.ImageUri`.
 
-A function with no binding and no registered image is skipped with a diagnostic, and the rest of the
-stack deploys. The reason separates a missing repository from an empty one, since those send you to
-different places. One is a wrong name, and the other is a handler that was never registered.
+A function with no binding or registered image is skipped. The diagnostic distinguishes a missing
+repository from a repository with no handlers.
 
 ## Available functionality
 
@@ -278,16 +239,14 @@ different places. One is a wrong name, and the other is a handler that was never
 
 ## Limitations
 
-Current documented limitations:
-
 - No image content, layer, digest, manifest or scan behaviour is simulated. A repository holds
   handlers, and no image is ever pulled or inspected.
 - There are no ECR SDK commands. `CreateRepository`, `DescribeRepositories`, `PutImage`,
   `DescribeImages`, `BatchDeleteImage` and `GetAuthorizationToken` are all absent. Registering an
   image is a Yulin-native operation because real `PutImage` takes a manifest for layers pushed over
   the Docker registry protocol, and that protocol never runs in this process.
-- Nothing authorizes against a repository. With no requests to authorize, a repository policy goes
-  unread and simulated IAM stays out of it.
+- CloudFormation authorizes `ecr:CreateRepository` and `ecr:DeleteRepository`. Handler registration
+  has no caller and skips authorization. Repository policies are ignored.
 - Lifecycle policies go unevaluated, and no simulated image ever expires. Tag mutability goes
   unenforced, and registering the same tag again replaces what it held.
 - Naming a repository creates it. There is no `CreateRepository` to fail for a name already taken,
@@ -295,8 +254,8 @@ Current documented limitations:
 - A stack teardown records the deletion of a repository holding a simulated image and carries on,
   where real CloudFormation fails the stack unless the template says `EmptyOnDelete`. The repository
   and its handler are left in place, and `EmptyOnDelete` itself goes unread.
-- Nothing tracks which stack created a repository. A repository holding no simulated image is
-  removed by the teardown of any stack that declared it, and made again by the next deploy.
+- The repository model records no owning stack. Teardown of any declaring stack removes an empty
+  repository.
 - Repository tags, registry policies, pull through cache rules, replication configuration and ECR
-  Public are not simulated.
-- ECR has no HTTP API under `serveSimAws`, and nothing for a Docker client to talk to.
+  Public are absent.
+- `serveSimAws` exposes no ECR HTTP API or Docker registry endpoint.