@kensio/yulin 1.21.7 → 1.21.9

package/docs/services/glue/README.md

@@ -1,26 +1,17 @@
 # Simulated Glue
 
-Yulin includes a simulated Glue Data Catalog for tests and local development. It holds databases,
-tables and the partitions registered against them, deploys databases and tables from
-`AWS::Glue::Database` and `AWS::Glue::Table`, and hands them back through `GetDatabase` and
-`GetTable`. A test can assert that a stack declared the table definition it meant to, including the
-Athena partition projection its parameters configure.
+Yulin simulates Glue Data Catalog databases, tables and partitions. The catalog stores metadata. It
+does not read the data in S3.
 
-A table here is a definition. The data it describes stays in S3, unread, and the catalog answers
-with what it was told to hold.
-
-Simulated [Athena](https://yulinsim.dev/services/athena/ "Simulated Athena usage docs") reads this
-catalog. A query naming a table no database here holds fails the way real Athena fails it, and a
-table's partition projection is evaluated when a query runs against it. All four projection types
-are covered, `enum`, `integer`, `date` and `injected`. A projection with a mistake in its parameters
-fails the query that reads it.
+Simulated [Athena](https://yulinsim.dev/services/athena/ "Simulated Athena usage docs") reads the
+catalog and evaluates partition projection when it runs a query.
 
 Glue-specific types are imported from the `@kensio/yulin/glue` subpath.
 
 ## Deploying a database and a table
 
-A stack declares the database, and the table names it through `Ref`. Both read back through the SDK
-once the deploy finishes.
+Simulated CloudFormation deploys `AWS::Glue::Database` and `AWS::Glue::Table`. A table can name its
+database through `Ref`.
 
 ```typescript sim-glue-cloudformation
 /**
@@ -84,18 +75,15 @@ const { Table } = simAws
 console.log(Table.Parameters["projection.enabled"]);
 ```
 
-Partition projection lives entirely in `TableInput.Parameters`. Those parameters are read into the
-table, and never recorded as ignored. A table whose parameters were dropped on the way in deploys
-green while projecting none of them. Simulated Athena reads those same parameters when a query runs.
-A broken projection fails that query.
+Partition projection configuration is stored in `TableInput.Parameters`. Athena reads these
+parameters when a query runs and rejects invalid projection configuration.
 
 `Ref` answers with the database name and with the table name.
 
 ## Names are folded to lower case
 
-A database name and a table name are both folded to lower case when they are stored. Real Glue folds
-them the same way, for compatibility with Apache Hive. A database created as `Rainlytics` is stored,
-reported and queried as `rainlytics`.
+Database and table names are stored in lower case. A database created as `Rainlytics` is reported as
+`rainlytics`.
 
 ```typescript sim-glue-name-folding
 /**
@@ -123,36 +111,27 @@ const { Database } = glue.getDatabase(
 console.log(Database.Name);
 ```
 
-Two names differing only by case are one name. A second `CreateDatabase` for `Rainlytics` after one
-for `rainlytics` is an `AlreadyExistsException`, and a `GetTable` finds the table under whichever
-spelling it is asked for.
+Names that differ only by case refer to the same database or table. Creating the second one raises
+`AlreadyExistsException`.
 
-Column names keep the case they were given, including partition keys. Real Glue leaves those alone,
-and simulated [Athena](https://yulinsim.dev/services/athena/ "Simulated Athena usage docs") folds a
-column name only when it runs a query.
+Column and partition key names keep their original case.
 
-A database or a table the template leaves unnamed is named from the stack name, the logical ID and a
-tail derived from both, folded the same way. A `LogTable` in `analytics-stack` becomes
-`analytics-stack-logtable-` and twelve more characters, where real CloudFormation ends the name in
-twelve random ones. The name is trimmed to the 255 bytes the catalog allows, and [the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
-cover how the stack name and the logical ID share what is left.
+CloudFormation generates a lower-case name when the template omits one. See
+[generated resource names](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates").
 
 ## Reading the catalog back
 
-`GetDatabase`, `GetDatabases`, `GetTable` and `GetTables` answer through the SDK. A `SimGlue` also
-carries `findDatabase`, `findTable`, `allDatabases`, `tablesInDatabase`, `findPartition` and
-`partitionsInTable`. Those read the same state without going through a Command or its
-authorization.
+Use the SDK commands to read the catalog through IAM authorization. The `findDatabase`, `findTable`,
+`allDatabases`, `tablesInDatabase`, `findPartition` and `partitionsInTable` accessors read the same
+state directly.
 
-The storage descriptor keeps its columns in the order they were declared, and the partition keys
-keep theirs. The two stay apart, the way real Glue keeps them. A partition key repeated among the
-storage descriptor's columns gives a table Athena refuses to query.
+Storage descriptor columns and partition keys keep their declared order. Athena rejects a table
+that repeats a partition key in the storage descriptor columns.
 
 ## Registering partitions
 
-A crawler, `MSCK REPAIR TABLE` or `ALTER TABLE ADD PARTITION` fills a real catalog's partition list.
-Here the six partition commands do it. A partition is keyed by its values in the order the table's
-`PartitionKeys` declares them, and carries a storage descriptor saying where its own data sits.
+Register partitions with the Glue partition commands. Values follow the order of the table's
+`PartitionKeys`. Each partition may provide its own storage descriptor.
 
 ```typescript sim-glue-partitions
 /**
@@ -219,24 +198,19 @@ console.log(Errors.length);
 console.log(Partitions[1]?.StorageDescriptor?.Location);
 ```
 
-`CreatePartition` registers one partition and `BatchCreatePartition` registers a list of them.
-`GetPartition` reads one back by its values, and `GetPartitions` answers with a table's partitions in
-registration order. `DeletePartition` and `BatchDeletePartition` remove them.
+`CreatePartition` and `BatchCreatePartition` register partitions. `GetPartition` reads one by its
+values. `GetPartitions` returns them in registration order. The delete commands remove them.
 
-A batch reports what it could not do in `Errors` and carries on with the rest, the way real Glue
-does. Each entry there carries the values it was given and an `ErrorCode` naming the refusal, so a
-job re-run over a week of days learns which days were already registered and registers the others.
+A batch continues after an individual partition fails. Its `Errors` list contains the supplied
+values and an `ErrorCode` for each failure.
 
-Values are positional. A `Values` list of a different length from the table's `PartitionKeys` lines
-up with the wrong keys, and is refused with `InvalidInputException` naming both counts. Registering
-one day twice is an `AlreadyExistsException`, since registration is not idempotent on real Glue.
-Deleting a table removes the partitions registered against it, the way deleting a database removes
-its tables.
+The number of values must match the number of partition keys. A mismatch raises
+`InvalidInputException`. Registering the same values twice raises `AlreadyExistsException`. Deleting
+a table removes its partitions, and deleting a database removes its tables.
 
 ## Filtering partitions
 
-`GetPartitions` takes an `Expression` and answers with the partitions it matches. A request carrying
-none reads them all.
+Pass `Expression` to `GetPartitions` to filter the result. Omitting it returns every partition.
 
 ```typescript sim-glue-partition-expressions
 /**
@@ -295,28 +269,19 @@ const { Partitions } = glue.getPartitions(
 console.log(JSON.stringify(Partitions.map((partition) => partition.Values)));
 ```
 
-A term names a partition key, an operator, and whatever the operator takes. The operators are `=`,
-`<>` and `!=`, `>`, `<`, `>=`, `<=`, `LIKE`, `IN` and `BETWEEN`, and `BETWEEN` takes both of its
-ends. `AND`, `OR` and `NOT` combine terms and brackets group them, with the precedence SQL gives
-them (`NOT` binds tightest, then `AND`, then `OR`). `NOT` also sits in front of `LIKE`, `IN` and
-`BETWEEN` to reverse that one term.
+Expressions support `=`, `<>`, `!=`, `>`, `<`, `>=`, `<=`, `LIKE`, `IN` and `BETWEEN`. Combine terms
+with `AND`, `OR`, `NOT` and parentheses. Operator precedence is `NOT`, then `AND`, then `OR`.
 
-Comparison follows the type the table declares for the key. `tinyint`, `smallint`, `int`, `integer`,
-`bigint`, `float`, `double` and `decimal` compare as numbers, so `10` sorts above `9` rather than
-below it. Every other declared type compares as text, which is the order a date written the ISO way
-already has. A key declared as a number is held to a numeric literal, and `hour = 'noon'` is refused
-rather than matching nothing.
+Numeric partition key types use numeric comparison. Other types use text comparison. A numeric key
+requires a numeric literal.
 
-`LIKE` matches the value's text whatever type the key is declared with, since that is what `LIKE`
-does. `%` stands for any run of characters and `_` for exactly one.
+`LIKE` treats the value as text. `%` matches any sequence and `_` matches one character.
 
-An expression naming a column the table does not partition by is refused, naming the column and the
-keys the table does have. So is one that cannot be read, and the message says where reading stopped.
+An unknown partition key or invalid expression is rejected with a position-aware error.
 
 ## Intercepting a GlueClient
 
-An intercepted `GlueClient` reaches the simulated catalog, so code under test builds its own client
-and sends its own Commands.
+Intercept a `GlueClient` when application code constructs the client itself.
 
 ```typescript sim-glue-sdk-interception
 /**
@@ -357,11 +322,9 @@ console.log(TableList?.[0]?.Name);
 
 ## Permissions
 
-Every Command authorizes through simulated IAM. Data Catalog resources are a hierarchy with the
-catalog at the root, and an operation on one needs permission on that resource and on every ancestor
-of it. Reading a table needs the table, the database and the catalog, and a policy naming only the
-table ARN is denied. Deleting a database needs permission on every table in it as well, since the
-tables go with it.
+Every command uses simulated IAM. Catalog resources form a hierarchy. A table operation needs
+permission on the table, database and catalog. Deleting a database also needs permission on its
+tables.
 
 ```typescript sim-glue-permissions
 /**
@@ -441,7 +404,7 @@ const { Table } = glue.getTable(
 console.log(Table.Name);
 ```
 
-A policy listing only the table ARN is refused here, and refused by real Glue for the same reason.
+A policy that grants only the table ARN is insufficient.
 
 ## Available functionality
 

package/docs/services/iam/README.md

@@ -1,11 +1,11 @@
 # Simulated IAM
 
-Yulin includes a simulated IAM service for tests and local development.
+Yulin simulates IAM users, roles, policies and authorization decisions for tests and local
+development. Other simulated services use IAM to authorize requests, simulated STS uses it to issue
+temporary role sessions, and simulated CloudFormation can create IAM resources from templates.
 
-Sim IAM stores simulated Roles, Users and Policies, and evaluates allow/deny authorization decisions
-for them. Other simulated services use it to authorize their own actions, simulated STS uses it to
-issue temporary Role sessions, and sim CloudFormation can create IAM resources from templates. It can
-also be instantiated on its own as `SimIam` with isolated state.
+Use IAM through `SimAws` when it should share state with other services. Use `SimIam` directly when
+you need an isolated policy evaluator.
 
 ## Basic usage
 
@@ -70,9 +70,8 @@ denied for every action.
 
 ## Authorization decisions
 
-`authorize(...)` returns a decision object. A denied request comes back as a decision too, and a
-test can assert on exactly why it was allowed or denied. The decision models the common IAM
-evaluation rules:
+`authorize(...)` returns an authorization decision without throwing when access is denied. Tests
+can inspect why the request was allowed or denied. The evaluator applies these rules:
 
 - A matching explicit `Deny` statement in any evaluated policy wins
 - Otherwise, within one Account, a matching `Allow` in an identity policy or resource policy allows
@@ -81,12 +80,11 @@ evaluation rules:
   [Cross-Account requests](#cross-account-requests)
 - Otherwise the request is implicitly denied
 
-The decision exposes `value` (`"Allow"`, `"ExplicitDeny"`, or `"ImplicitDeny"`), the convenience
-flags `isAllowed`, `isDenied`, `isExplicitDeny`, and `isImplicitDeny`, the matching
-`allowStatements` and `explicitDenyStatements`, and the resolved `caller` for diagnostics. The
-matching Allows are also available per side as `identityAllowStatements` and
-`resourceAllowStatements`. A cross-Account denial is best read from those. Statements the simulator
-could not evaluate are reported by `unevaluatedStatements`, covered under
+The decision's `value` is `"Allow"`, `"ExplicitDeny"` or `"ImplicitDeny"`. Convenience flags expose
+the same result as `isAllowed`, `isDenied`, `isExplicitDeny` and `isImplicitDeny`. The decision also
+contains the resolved `caller` and the matching allow and deny statements. For cross-account
+requests, inspect `identityAllowStatements` and `resourceAllowStatements` to see which side did not
+grant access. Unsupported statements appear in `unevaluatedStatements`, covered under
 [Statements left unevaluated](#statements-left-unevaluated).
 
 If the caller is omitted, authorization defaults to the simulation's own
@@ -1634,7 +1632,7 @@ stands apart from any wider `SimAws` environment. Other services instantiated st
 `new SimRoute53()`, fall back to allow-all authorization. Connect services through a shared `SimAws`
 instance when a test should exercise real IAM enforcement.
 
-## Available functionality
+## Supported operations
 
 Sim IAM currently supports:
 

package/docs/services/kinesis/README.md

@@ -1,16 +1,14 @@
 # Simulated Kinesis Data Streams
 
-Yulin includes a simulated Kinesis Data Streams for tests and local development. It creates streams,
-places records on shards the way real Kinesis does, and hands them back through shard iterators. A
-test can put an event and assert that the consumer read it, without an AWS account and without
-waiting on a real stream.
+Yulin simulates Kinesis streams, shards, records and shard iterators in memory. Use
+`simAws.kinesis()` directly or intercept a `KinesisClient`.
 
 Kinesis specific types are imported from the `@kensio/yulin/kinesis` subpath.
 
 ## Putting a record and reading it back
 
-`simAws.kinesis()` gives the service for the default account and region. Records go on with
-`PutRecord`, and come off through a shard iterator, which is the walk every Kinesis consumer makes.
+Create a stream, put a record, then read it through a shard iterator. This is the same sequence used
+by an AWS SDK consumer.
 
 ```typescript sim-kinesis-put-and-read
 /**
@@ -59,17 +57,15 @@ const { Records } = await kinesis.getRecords(
 console.log(new TextDecoder().decode(Records[0]?.Data));
 ```
 
-A record keeps the bytes it was given. Whatever the producer encoded is what the consumer decodes.
+Kinesis stores the bytes supplied by the producer. The consumer is responsible for decoding them.
 
 ## Shards and partition keys
 
-A stream is created with the shard count it asks for, and each shard owns a slice of a 128 bit hash
-key space. A record goes to the shard whose slice covers the MD5 hash of its partition key, which is
-the placement real Kinesis makes. Two records sharing a partition key therefore land on one shard,
-in the order they were put, and that per-key ordering is what most Kinesis consumers depend on.
+A stream divides the 128-bit hash key space evenly across its shards. Kinesis uses the MD5 hash of
+the partition key to select a shard. Records with the same partition key reach the same shard in
+write order.
 
-Records under different partition keys can land anywhere. A consumer that has to see every record
-reads every shard.
+Different partition keys may select different shards. Read every shard to consume the whole stream.
 
 ```typescript sim-kinesis-shards
 /**
@@ -121,12 +117,10 @@ console.log(
 );
 ```
 
-An `ExplicitHashKey` on a record overrides the partition key for placement, and the record still
-carries the partition key the producer gave it. That is how a producer pins a record to a shard it
-picked.
+`ExplicitHashKey` overrides the hash used for placement. The stored record still contains the
+original partition key.
 
-A stream created with `StreamModeDetails` of `ON_DEMAND` gets four shards, which is what real
-Kinesis starts an on-demand stream with. Nothing here grows or shrinks that count.
+An `ON_DEMAND` stream starts with four shards. Its shard count remains fixed.
 
 ## Where a read starts
 
@@ -140,24 +134,20 @@ Every shard iterator type resolves to a place on the shard.
 | `AFTER_SEQUENCE_NUMBER` | The record following that sequence number.                    |
 | `AT_TIMESTAMP`          | The first record that arrived at or after the instant given.  |
 
-`GetRecords` hands back a `NextShardIterator` pointing at where the read finished, which is what a
-polling consumer passes to its next call. A read that has caught up comes back empty with an
-iterator standing where it was.
+Pass `NextShardIterator` to the next `GetRecords` call. A reader at the end of the shard receives an
+empty record list and another iterator at the same position.
 
-`MillisBehindLatest` reports how far behind the tip the reader is. Zero means caught up. Otherwise
-it is the age of the last record handed back, measured against simulated time.
+`MillisBehindLatest` is zero for a reader at the end of the shard. Otherwise it reports the age of
+the last returned record, measured against simulated time.
 
 ## Retention
 
-A stream keeps a record for 24 hours. Records older than that are gone from a read, and trimming is
-applied at the instant of the read rather than on a timer, so moving simulated time forward is all a
-test needs.
+A stream retains records for 24 hours by default. Retention is applied when records are read. Move
+simulated time forward to test expiration.
 
-`IncreaseStreamRetentionPeriod` and `DecreaseStreamRetentionPeriod` move it, up to the 8760 hours
-Kinesis keeps at most. Each refuses a request that goes the other way, including one asking for what
-the stream already keeps, which is what real Kinesis does with a caller that has the wrong idea of
-what the stream is set to. Shortening the window drops whatever it has already outlived from the
-next read.
+Use `IncreaseStreamRetentionPeriod` or `DecreaseStreamRetentionPeriod` to change the period. Values
+must stay between 24 and 8,760 hours. Each command rejects a value pointing in the wrong direction.
+Shortening the period affects the next read.
 
 ```typescript sim-kinesis-retention
 /**
@@ -209,26 +199,21 @@ console.log(Records.length);
 ## Triggering a Lambda function
 
 A [Lambda event source mapping](https://yulinsim.dev/services/lambda/#triggering-a-function-from-a-kinesis-stream "Simulated Lambda Kinesis event source docs")
-polls a stream and invokes a function with the records it reads. Every shard is read by a processor
-of its own, as real Lambda reads one, and the function's execution role is what the polling is done
-as.
+polls each shard and invokes the function with batches of records. Reads use the function's
+execution role.
 
 ## Feeding a Firehose delivery stream
 
 A [Firehose delivery stream](https://yulinsim.dev/services/firehose/#reading-from-a-kinesis-stream "Simulated Firehose Kinesis source docs")
-can read a stream and buffer what it reads into an S3 Bucket. It reads every shard as its source
-`RoleARN`, starting at the end of the stream when the delivery stream is created.
+can read every shard and buffer the records into S3. It starts at the end of the stream and reads as
+its source `RoleARN`.
 
 ## Deploying a stream
 
-`AWS::Kinesis::Stream` creates a simulated stream, which is what a CDK `Stream` synthesizes. The
-stream goes through the ordinary `CreateStream` command, so a stream a template deployed is the same
-thing an SDK caller would have got, and a template asking for something Kinesis will not take is
-refused in the words `CreateStream` refuses it in.
+Simulated CloudFormation deploys `AWS::Kinesis::Stream` through `CreateStream`. A CDK `Stream`
+synthesizes this resource type.
 
-`Ref` gives the stream name and `Fn::GetAtt` on `Arn` gives the stream ARN, which is the way round
-real CloudFormation publishes them. Every Kinesis API and every grant names the ARN, so a template
-wiring a stream into a Lambda event source mapping or an IAM policy reads the attribute.
+`Ref` returns the stream name. `Fn::GetAtt Arn` returns its ARN.
 
 ```typescript sim-kinesis-cloudformation
 /**
@@ -274,32 +259,24 @@ await simAws.kinesis().putRecord(
 );
 ```
 
-`Name`, `ShardCount`, `RetentionPeriodHours`, `StreamModeDetails` and `Tags` are read. A stream the
-template does not name is named after the stack, the logical ID and a tail derived from both, as
-[the CloudFormation docs](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates")
-describe.
+Yulin reads `Name`, `ShardCount`, `RetentionPeriodHours`, `StreamModeDetails` and `Tags`. It generates
+a name when `Name` is absent. See [generated resource names](https://yulinsim.dev/services/cloudformation/#names-cloudformation-generates "Names CloudFormation generates").
 
-`RetentionPeriodHours` is applied after the stream is created, because `CreateStream` takes no
-retention on real Kinesis either. It only ever goes up: a new stream keeps records for 24 hours,
-which is also the least Kinesis accepts, so a template can ask for more or for the same and never
-for less.
+`RetentionPeriodHours` is applied after creation. A new stream already has the minimum 24-hour
+period, so a template may keep it or increase it.
 
-`StreamEncryption` and `DesiredShardLevelMetrics` are recorded against the resource as unsimulated
-and the stream is created anyway, so a template that encrypts its streams still deploys and the
-omission is somewhere a test can find it. Deleting the stack deletes the stream.
+`StreamEncryption` and `DesiredShardLevelMetrics` are recorded as ignored properties. The stream is
+still created. Deleting the stack deletes it.
 
-`AWS::Kinesis::StreamConsumer` and `AWS::Kinesis::ResourcePolicy` are reported as unsupported and
-skipped. One registers an enhanced fan-out consumer and the other admits a caller from another
-account, and neither has anything to act on here.
+`AWS::Kinesis::StreamConsumer` and `AWS::Kinesis::ResourcePolicy` are skipped. Enhanced fan-out and
+resource policies are absent.
 
 ## Permissions
 
-Every operation goes through simulated IAM. The action is the `kinesis:` name of the operation, and
-the resource is the stream ARN, `arn:aws:kinesis:<region>:<account>:stream/<name>`. `ListStreams`
-names no stream and authorizes against `*`.
+Every operation uses simulated IAM. Stream operations authorize the corresponding `kinesis:` action
+against the stream ARN. `ListStreams` authorizes against `*`.
 
-`GetRecords` authorizes against the stream the iterator was made on, which the iterator carries. A
-caller cannot reach a stream it lacks permission for by holding someone else's iterator.
+`GetRecords` authorizes against the stream stored in the iterator.
 
 ```typescript sim-kinesis-permissions
 /**
@@ -362,8 +339,7 @@ try {
 
 ## SDK interception
 
-A `KinesisClient` handed to `SimSdk` reaches the simulated service, so application code that builds
-its own client needs no change.
+Intercept a `KinesisClient` when application code creates and uses the client itself.
 
 ```typescript sim-kinesis-sdk-interception
 /**
@@ -418,38 +394,22 @@ console.log(put.ShardId);
 
 Every operation takes `StreamName` or `StreamARN`, and reads the ARN when a request carries both.
 
-Anything else refuses on send with `SimSdkUnsupportedCommandError`.
+Any other command raises `SimSdkUnsupportedCommandError`.
 
 ## Divergences and limitations
 
-- **A stream is `ACTIVE` as soon as it exists.** Real Kinesis reports `CREATING` while it brings the
-  shards up, and a status a test has to poll through earns nothing when there are no shards to bring
-  up. `DELETING` and `UPDATING` are absent for the same reason.
-- **Nothing reshards.** `UpdateShardCount`, `SplitShard` and `MergeShards` move the shard map
-  underneath consumers holding iterators, and they are left out. A shard is opened when the stream
-  is created and never closes, so no shard reports an ending sequence number and no read reports a
-  child shard.
-- **Enhanced fan-out is absent.** `RegisterStreamConsumer`, `DeregisterStreamConsumer`,
-  `ListStreamConsumers`, `DescribeStreamConsumer` and `SubscribeToShard` need an HTTP/2 event stream
-  that nothing here delivers. Every consumer reads through `GetRecords`.
+- Streams become `ACTIVE` immediately. `CREATING`, `DELETING` and `UPDATING` states are absent.
+- Resharding is absent. `UpdateShardCount`, `SplitShard` and `MergeShards` are unsupported. Shards
+  have no ending sequence number or child shards.
+- Enhanced fan-out is absent. Consumers read through `GetRecords`.
 - **A shard iterator never expires.** Real Kinesis expires one after five minutes. An iterator this
   simulation never issued is still refused, with the `ExpiredIteratorException` real Kinesis uses.
-- **Throughput is unlimited.** Real Kinesis takes 1 MB or 1,000 records a second per shard for
-  writes and 2 MB a second for reads, and refuses past that with
-  `ProvisionedThroughputExceededException`. Nothing here counts. That is why `FailedRecordCount` on
-  `PutRecords` is always zero: the reasons real Kinesis fails one record of a batch are throughput
-  limits and internal faults, and neither is simulated. The per-record result shape is still what a
-  consumer of the response reads.
+- Throughput is unlimited. Yulin never raises `ProvisionedThroughputExceededException`, and
+  `PutRecords` reports zero failed records.
 - **Sequence numbers are 56 digit counters.** They are unique within a stream and increase within a
-  shard, as real Kinesis promises. They also increase across shards here, which real Kinesis does
-  not promise, so a consumer ordering two records from different shards would be relying on
-  something AWS does not offer.
-- **Server-side encryption is absent.** `StartStreamEncryption` and `StopStreamEncryption` are left
-  out, and no response carries an `EncryptionType`.
-- **Tags are kept and never listed.** A stream created with `Tags` holds them, readable through
-  `findStream`. `AddTagsToStream`, `ListTagsForStream` and `RemoveTagsFromStream` are absent.
-- **Kinesis Data Firehose is a separate service.** It has a simulation of its own under
-  `simAws.firehose()`, and a delivery stream there can read a stream here. Kinesis Video Streams is
-  absent.
-- **`AWS::DynamoDB::Table` `KinesisStreamSpecification` stays unsimulated.** A table does not publish
-  its changes into a stream here.
+  shard, as real Kinesis promises. Yulin also increments them across shards. AWS promises ordering
+  within a shard only.
+- Server-side encryption is absent. Responses contain no `EncryptionType`.
+- Stream tags are stored and available through `findStream`. Tagging commands are unsupported.
+- Kinesis Video Streams is absent.
+- The DynamoDB `KinesisStreamSpecification` integration is absent.