@kensio/yulin 1.21.0 → 1.21.1

package/docs/services/cloudwatch/README.md

@@ -9,8 +9,16 @@ Code that publishes a business metric is code teams already have, and until now
 it was to assert that the SDK client had been called. That proves the call was made. What it
 measured goes untested.
 
-Only custom metrics live here. This simulation publishes into no `AWS/` namespace. A query for
-`AWS/Lambda` `Invocations` comes back empty, in place of a number that was never measured.
+Most of what lives here is custom metrics. Simulated Lambda publishes its own `AWS/Lambda`
+`Invocations`, `Errors`, `Duration` and `IteratorAge`, simulated Cognito publishes a pool's
+`AWS/Cognito` counts, and no other simulated service publishes into an `AWS/` namespace yet. A
+query for one nothing measures comes back empty, in place of a number that was never taken. A test
+can stand a datapoint up for one of those itself, which is what drives an alarm on a service metric
+to a state change.
+
+A custom metric's datapoints arrive either from `PutMetricData` or from a CloudWatch Logs metric
+filter counting matching log events. See the [CloudWatch Logs docs](../logs/README.md) for the
+second route.
 
 CloudWatch specific types are imported from the `@kensio/yulin/cloudwatch` subpath.
 
@@ -143,6 +151,143 @@ console.log(read.MetricDataResults?.at(0)?.Values);
 `ListMetrics` reads `RecentlyActive: "PT3H"` against the same clock, so advancing time past the
 window drops a metric out of the listing without anything having to expire it.
 
+## Metrics a simulated service publishes
+
+Real CloudWatch holds two kinds of metric. A caller publishes a custom one through `PutMetricData`, and AWS publishes its own under a namespace beginning `AWS/` that no caller may write into. Both kinds are read the same way.
+
+Two services publish their own. Simulated Cognito counts what a user pool was asked to do, under `AWS/Cognito` and dimensioned by `UserPool` and `UserPoolClient`, which the [Cognito docs](../cognito/README.md) cover.
+
+Simulated Lambda publishes three of its own. Every invocation counts `Invocations` and a `Duration`, and one whose handler threw counts an `Errors` alongside them, all under `AWS/Lambda` and dimensioned by `FunctionName`. Nothing has to be turned on, and no execution Role needs a permission for it, which is how real Lambda behaves.
+
+```typescript sim-cloudwatch-lambda-errors
+/**
+ * An alarm firing on the errors a failing function counted.
+ */
+
+import {
+  DescribeAlarmsCommand,
+  PutMetricAlarmCommand,
+} from "@aws-sdk/client-cloudwatch";
+import { CreateFunctionCommand, InvokeCommand } from "@aws-sdk/client-lambda";
+
+import { SimAws } from "@kensio/yulin";
+import { makeLambdaZipFileInput } from "@kensio/yulin/lambda";
+
+const simAws = new SimAws();
+
+await simAws.clock().setTo(new Date("2026-08-30T09:00:00Z"));
+await simAws.lambda().createFunction(
+  new CreateFunctionCommand({
+    FunctionName: "orders",
+    Role: `arn:aws:iam::${simAws.defaultAccountId}:role/OrdersRole`,
+    Code: {
+      ZipFile: makeLambdaZipFileInput(() => {
+        throw new Error("order has no items");
+      }),
+    },
+  }),
+);
+await simAws.backgroundTasksComplete();
+
+await simAws.cloudWatch().putMetricAlarm(
+  new PutMetricAlarmCommand({
+    AlarmName: "OrdersFailing",
+    Namespace: "AWS/Lambda",
+    MetricName: "Errors",
+    Dimensions: [{ Name: "FunctionName", Value: "orders" }],
+    Statistic: "Sum",
+    Period: 300,
+    EvaluationPeriods: 3,
+    DatapointsToAlarm: 1,
+    Threshold: 0,
+    ComparisonOperator: "GreaterThanThreshold",
+    TreatMissingData: "notBreaching",
+  }),
+);
+
+await simAws.lambda().invoke(new InvokeCommand({ FunctionName: "orders" }));
+await simAws.backgroundTasksComplete();
+await simAws.clock().advanceBy({ minutes: 6 });
+
+const { MetricAlarms } = await simAws
+  .cloudWatch()
+  .describeAlarms(new DescribeAlarmsCommand({ AlarmNames: ["OrdersFailing"] }));
+
+// ALARM. The invocation counted its own error.
+console.log(MetricAlarms?.[0]?.StateValue);
+```
+
+`Duration` is measured on the simulation's clock rather than the host's, so it is a number a test can assert on. A handler that moves the clock reports the time it moved, and one that returns without touching it reports nothing spent. `IteratorAge` is measured the same way, and the Lambda documentation covers what a stream event source mapping reports.
+
+## Seeding a metric AWS publishes
+
+`PutMetricData` refuses a namespace beginning `AWS/`, exactly as an account does. An alarm watching a metric no simulated service publishes therefore sits in `INSUFFICIENT_DATA`, and its arithmetic goes untested however carefully the alarm itself is declared.
+
+The service writer is the way in. It is the same route simulated Lambda's own metrics take, reached from a test through `cloudWatch().serviceWriter()`, and it stands a datapoint up in any namespace.
+
+```typescript sim-cloudwatch-seed-service-metric
+/**
+ * Driving an alarm on a metric nothing in the simulation publishes.
+ */
+
+import {
+  DescribeAlarmsCommand,
+  PutMetricAlarmCommand,
+} from "@aws-sdk/client-cloudwatch";
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+
+await simAws.clock().setTo(new Date("2026-08-30T09:00:00Z"));
+
+await simAws.cloudWatch().putMetricAlarm(
+  new PutMetricAlarmCommand({
+    AlarmName: "SignInsThrottling",
+    Namespace: "AWS/Cognito",
+    MetricName: "SignInThrottles",
+    Dimensions: [{ Name: "UserPool", Value: "eu-west-1_pool" }],
+    Statistic: "Sum",
+    Period: 300,
+    EvaluationPeriods: 3,
+    DatapointsToAlarm: 1,
+    Threshold: 0,
+    ComparisonOperator: "GreaterThanThreshold",
+    TreatMissingData: "notBreaching",
+  }),
+);
+
+// The pool would have published this. Nothing here does, so the test does.
+simAws
+  .cloudWatch()
+  .serviceWriter()
+  .publish([
+    {
+      namespace: "AWS/Cognito",
+      metricName: "SignInThrottles",
+      dimensions: [{ Name: "UserPool", Value: "eu-west-1_pool" }],
+      value: 4,
+      unit: "Count",
+    },
+  ]);
+
+await simAws.backgroundTasksComplete();
+await simAws.clock().advanceBy({ minutes: 6 });
+
+const { MetricAlarms } = await simAws
+  .cloudWatch()
+  .describeAlarms(
+    new DescribeAlarmsCommand({ AlarmNames: ["SignInsThrottling"] }),
+  );
+
+// ALARM.
+console.log(MetricAlarms?.[0]?.StateValue);
+```
+
+A datapoint arriving without a `timestamp` is stamped with the simulation's clock. One carrying its own lands where it says, which fills a window without the clock having to be walked through it.
+
+`PutMetricData` is untouched by any of this. A caller naming a reserved namespace is refused exactly as before, and only the account's own machinery and a test reach the store this way.
+
 ## Alarms
 
 An alarm watches one metric and changes state on the simulation's clock, with no real timer behind
@@ -392,6 +537,12 @@ await simAws.cloudWatch().putMetricData(
   with evaluation on the simulation's clock and SNS notifications on a state change.
 - IAM authorization on each action, including the `cloudwatch:namespace` condition key and
   alarm-ARN resources.
+- `AWS/Lambda` `Invocations`, `Errors`, `Duration` and `IteratorAge`, published by simulated Lambda
+  itself and read back the way a custom metric is.
+- `AWS/Cognito` `SignInSuccesses`, `SignUpSuccesses`, `TokenRefreshSuccesses` and
+  `FederationSuccesses`, published by a simulated user pool.
+- Seeding a metric AWS publishes, through `cloudWatch().serviceWriter()`, so an alarm on one can be
+  driven to a state change from a test.
 - `AWS::CloudWatch::Alarm` in simulated CloudFormation, deployed through `PutMetricAlarm` and taken
   down with the stack.
 
@@ -413,7 +564,12 @@ test still passes and no longer means what it says.
   comes back at the period its query asked for.
 - **Cross-account metrics.** `IncludeLinkedAccounts` and `OwningAccount` are refused. There is no
   monitoring account.
-- **Metrics AWS publishes.** No simulated service writes its own `AWS/` metrics.
+- **Most metrics AWS publishes.** The `AWS/Lambda` and `AWS/Cognito` metrics above are the only ones
+  a simulated service writes. `Throttles` and `ConcurrentExecutions` need concurrency limits, which
+  simulated Lambda has none of, and every other `AWS/` namespace needs a source event built before a
+  metric can come from one. A test seeds what it needs from one of those
+  through the service writer. A CloudWatch Logs metric filter naming a reserved namespace is refused
+  when it publishes, as `PutMetricData` refuses a caller naming one.
 
 Two divergences are deliberate, and not refusals. Real CloudWatch rejects a datapoint more than two
 weeks old or more than two hours in the future, and this accepts any timestamp, letting a test seed

package/docs/services/cognito/README.md

@@ -2036,7 +2036,7 @@ so does one that signed up on the page below.
 
 ### The pages managed login serves
 
-A served domain answers five pages, so a browser in a local development server completes a whole
+A served domain answers six pages, so a browser in a local development server completes a whole
 sign-up, password reset and sign-in without any of it being stubbed out.
 
 `GET /oauth2/authorize` naming no `identity_provider` answers HTML holding the sign-in form. The
@@ -2046,6 +2046,25 @@ The pool's identity providers are links to the same endpoint with `identity_prov
 way in is on the one page. Posting the form redirects to the app client's callback URL with the code
 and the `state`, honouring a `code_challenge` the request carried.
 
+Following one of those provider links reaches a page standing in for the provider's own sign-in
+page. Real Cognito sends the browser to Google here, and nothing in this simulation calls Google, so
+the page asks who Google would have said is signing in. It says on its face that it is Yulin rather
+than the provider, twice, because somebody meeting it in a screenshot or a screen recording has to
+be able to tell that no real sign-in happened.
+
+The page asks for the subject and for one field per claim the provider's `AttributeMapping` reads,
+and every field arrives filled in, so the common case is pressing the button. The address it
+pre-fills is on `example.com`, which is reserved, so nothing left unedited reaches a real mailbox.
+Editing the address is what drives a federated sign-up against a pool that already holds one of its
+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.
+
 `/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`
 names. Posting it does what `SignUp` does and sends the browser to `/confirm`.
@@ -2752,6 +2771,171 @@ try {
 Cognito. Neither fires for `REFRESH_TOKEN_AUTH`, as neither does on real Cognito, where
 `PreTokenGeneration` does.
 
+A sign-in at the hosted domain runs `PreAuthentication` too, under the same
+`PreAuthentication_Authentication` source real Cognito reports it from `/login`. It runs for a
+password and for a passkey, once per sign-in, before the password is checked. A handler that throws
+refuses the sign-in, and a served domain draws that refusal on the sign-in form the way it draws a
+wrong password. A browser coming back on the managed login session it already holds runs nothing,
+because the `PreAuthentication` docs say the trigger does not activate on the renewal of a session
+that already exists.
+
+`PostAuthentication` stays unfired at the hosted domain. AWS names it for a federated sign-in and
+leaves it out of the table for a local user at managed login, and what real Cognito does there was
+not checked against a live account.
+
+### Federated sign-in triggers
+
+A user arriving from an identity provider runs the pool's triggers too, and which ones it runs
+depends on whether the pool has met the subject before. AWS documents the split, and this is what it
+comes to:
+
+| Sign-in event  | Trigger              | Source                              |
+| -------------- | -------------------- | ----------------------------------- |
+| First sign-in  | `PreSignUp`          | `PreSignUp_ExternalProvider`        |
+|                | `PostConfirmation`   | `PostConfirmation_ConfirmSignUp`    |
+|                | `PreTokenGeneration` | `TokenGeneration_HostedAuth`        |
+| Later sign-ins | `PreAuthentication`  | `PreAuthentication_Authentication`  |
+|                | `PostAuthentication` | `PostAuthentication_Authentication` |
+|                | `PreTokenGeneration` | `TokenGeneration_HostedAuth`        |
+
+That split is what an application hangs its own user record off. `PostConfirmation` runs the first
+time a Google user arrives and never again, which is the same place a local sign-up's record is
+written from, so one handler covers both ways in.
+
+```typescript sim-cognito-federated-triggers
+/**
+ * A PostConfirmation trigger that runs on a federated user's first sign-in.
+ */
+
+import {
+  CreateIdentityProviderCommand,
+  CreateUserPoolClientCommand,
+  CreateUserPoolCommand,
+  CreateUserPoolDomainCommand,
+} from "@aws-sdk/client-cognito-identity-provider";
+import {
+  AddPermissionCommand,
+  CreateFunctionCommand,
+} from "@aws-sdk/client-lambda";
+
+import { SimAws } from "@kensio/yulin";
+import { makeLambdaZipFileInput } from "@kensio/yulin/lambda";
+
+/**
+ * The part of the PostConfirmation event this handler reads.
+ */
+interface PostConfirmationEvent {
+  readonly triggerSource: string;
+  readonly userName: string;
+}
+
+const written: string[] = [];
+
+// A record is written here. A deployed handler writes it to DynamoDB.
+const postConfirmation = (event: PostConfirmationEvent): unknown => {
+  written.push(`${event.triggerSource} ${event.userName}`);
+
+  return event;
+};
+
+const simAws = new SimAws({ defaultRegionName: "eu-west-2" });
+const lambda = simAws.lambda();
+const cognito = simAws.cognitoIdentityProvider();
+const callbackUrl = "https://www.example.com/user/callback";
+
+// The function comes first, because the pool names it by ARN.
+const functionArn =
+  `arn:aws:lambda:eu-west-2:${simAws.defaultAccountId}` +
+  `:function:post-confirmation`;
+await lambda.createFunction(
+  new CreateFunctionCommand({
+    FunctionName: "post-confirmation",
+    Role: `arn:aws:iam::${simAws.defaultAccountId}:role/TriggerRole`,
+    Code: { ZipFile: makeLambdaZipFileInput(postConfirmation) },
+  }),
+);
+
+const created = await cognito.createUserPool(
+  new CreateUserPoolCommand({
+    PoolName: "myapp-users",
+    LambdaConfig: { PostConfirmation: functionArn },
+  }),
+);
+const userPoolId = created.UserPool?.Id ?? "";
+
+// The permission a CDK `addTrigger` emits, which lets Cognito invoke it.
+await lambda.addPermission(
+  new AddPermissionCommand({
+    FunctionName: "post-confirmation",
+    StatementId: "AllowCognito",
+    Action: "lambda:InvokeFunction",
+    Principal: "cognito-idp.amazonaws.com",
+    SourceArn: created.UserPool?.Arn,
+  }),
+);
+
+await cognito.createIdentityProvider(
+  new CreateIdentityProviderCommand({
+    UserPoolId: userPoolId,
+    ProviderName: "Google",
+    ProviderType: "Google",
+    ProviderDetails: {
+      client_id: "google-client-id",
+      client_secret: "google-client-secret",
+      authorize_scopes: "openid email",
+    },
+    AttributeMapping: { email: "email" },
+  }),
+);
+
+const client = await cognito.createUserPoolClient(
+  new CreateUserPoolClientCommand({
+    UserPoolId: userPoolId,
+    ClientName: "web",
+    AllowedOAuthFlowsUserPoolClient: true,
+    AllowedOAuthFlows: ["code"],
+    AllowedOAuthScopes: ["openid", "email"],
+    CallbackURLs: [callbackUrl],
+    SupportedIdentityProviders: ["Google"],
+  }),
+);
+
+await cognito.createUserPoolDomain(
+  new CreateUserPoolDomainCommand({
+    UserPoolId: userPoolId,
+    Domain: "myapp-login",
+  }),
+);
+
+const pool = cognito.userPool(userPoolId);
+
+pool.auth.identityProviders.require("Google").signInAs({
+  Subject: "108412093487519382745",
+  Claims: { email: "someone@example.com" },
+});
+
+const authorize = {
+  response_type: "code",
+  client_id: client.UserPoolClient?.ClientId ?? "",
+  redirect_uri: callbackUrl,
+  identity_provider: "Google",
+};
+
+// The first sign-in creates the pool's user for the subject.
+await cognito.hostedAuthorize(pool, authorize);
+console.log(written);
+// ["PostConfirmation_ConfirmSignUp Google_108412093487519382745"]
+
+// The second reaches the same user, and the sign-up triggers stay unfired.
+await cognito.hostedAuthorize(pool, authorize);
+console.log(written.length); // 1
+```
+
+A handler that throws from `PreSignUp` refuses the sign-in, and the pool is left without the user,
+because that trigger runs before the user is added. `autoVerifyEmail` and `autoVerifyPhone` are
+applied the way they are for a sign-up. `autoConfirmUser` has nothing to do, as a federated user is
+created in `EXTERNAL_PROVIDER` and never passes through `UNCONFIRMED`.
+
 ### The event, and what a failure gets back
 
 Every event carries `version`, `region`, `userPoolId`, `userName`, the `triggerSource` naming the
@@ -3010,6 +3194,151 @@ and the timestamps on tokens issued after it, but a verifier reading the host cl
 token it already holds by host time. Signing in in the past is what produces a token such a verifier
 refuses.
 
+## What a pool counts in CloudWatch
+
+A pool publishes into `AWS/Cognito` what real Cognito publishes about the requests it handles, dimensioned by `UserPool` and `UserPoolClient`. Nothing has to be turned on for it, and no caller needs a permission. Real Cognito behaves the same way.
+
+Four counts are kept. `SignInSuccesses` counts every authentication request, `SignUpSuccesses` every registration, `TokenRefreshSuccesses` every renewal from a refresh token, and `FederationSuccesses` every sign-in through an identity provider. Each is a 1 where the request issued tokens and a 0 where it did not, so `Sum` is how many succeeded, `SampleCount` is how many were made, and `Average` between them is the success rate. That is how the AWS documentation says to read them.
+
+```typescript sim-cognito-metrics
+/**
+ * An alarm on the rate at which a pool is turning sign-ins away.
+ */
+
+import {
+  DescribeAlarmsCommand,
+  PutMetricAlarmCommand,
+} from "@aws-sdk/client-cloudwatch";
+import { InitiateAuthCommand } from "@aws-sdk/client-cognito-identity-provider";
+
+import type { SimAws } from "@kensio/yulin";
+
+declare const simAws: SimAws;
+declare const userPoolId: string;
+declare const clientId: string;
+
+await simAws.cloudWatch().putMetricAlarm(
+  new PutMetricAlarmCommand({
+    AlarmName: "SignInsFailing",
+    Namespace: "AWS/Cognito",
+    MetricName: "SignInSuccesses",
+    Dimensions: [
+      { Name: "UserPool", Value: userPoolId },
+      { Name: "UserPoolClient", Value: clientId },
+    ],
+    Statistic: "Average",
+    Period: 300,
+    EvaluationPeriods: 3,
+    DatapointsToAlarm: 1,
+    Threshold: 0.5,
+    ComparisonOperator: "LessThanThreshold",
+    TreatMissingData: "notBreaching",
+  }),
+);
+
+// Two of these three fail, so the average falls under the threshold.
+for (const password of ["Wr0ng!", "AlsoWr0ng!", "Sup3rSecret!"]) {
+  const attempt = new InitiateAuthCommand({
+    ClientId: clientId,
+    AuthFlow: "USER_PASSWORD_AUTH",
+    AuthParameters: { USERNAME: "alice", PASSWORD: password },
+  });
+
+  try {
+    await simAws.cognitoIdentityProvider().initiateAuth(attempt);
+  } catch {
+    // A refused sign-in is counted as a zero rather than going uncounted.
+  }
+}
+
+await simAws.backgroundTasksComplete();
+await simAws.clock().advanceBy({ minutes: 6 });
+
+const { MetricAlarms } = await simAws
+  .cloudWatch()
+  .describeAlarms(
+    new DescribeAlarmsCommand({ AlarmNames: ["SignInsFailing"] }),
+  );
+
+// ALARM.
+console.log(MetricAlarms?.[0]?.StateValue);
+```
+
+Two `UserPoolClient` values are fixed names rather than ids. A user an administrator registers through `AdminCreateUser` reaches the pool through no app client and counts against `Admin`. An admin authentication request naming a client the pool has none of counts against `Invalid`, and the id it gave is left out.
+
+A token refresh stays out of `SignInSuccesses` and lands in `TokenRefreshSuccesses`, whether it arrived as a `REFRESH_TOKEN_AUTH` flow or as `GetTokensFromRefreshToken`. A federated sign-in counts where its tokens are issued, at the token endpoint, rather than at the authorization code the provider sent the browser back with.
+
+### Turning requests away
+
+Real Cognito turns a request away when the account has gone over a rate limit, answering `TooManyRequestsException` and counting a `*Throttles` beside the `*Successes` it counts a 0 in. Those limits belong to the account and are mostly undocumented. Working one out here would be inventing a number, and a test asserting against an invented number proves little about a real pool. A test says how many requests a pool should turn away instead, and the pool turns away that many.
+
+```typescript sim-cognito-throttles
+/**
+ * An alarm on the sign-ins a pool is turning away.
+ */
+
+import {
+  DescribeAlarmsCommand,
+  PutMetricAlarmCommand,
+} from "@aws-sdk/client-cloudwatch";
+import { InitiateAuthCommand } from "@aws-sdk/client-cognito-identity-provider";
+
+import type { SimAws } from "@kensio/yulin";
+
+declare const simAws: SimAws;
+declare const userPoolId: string;
+declare const clientId: string;
+
+await simAws.cloudWatch().putMetricAlarm(
+  new PutMetricAlarmCommand({
+    AlarmName: "SignInsThrottling",
+    Namespace: "AWS/Cognito",
+    MetricName: "SignInThrottles",
+    Dimensions: [
+      { Name: "UserPool", Value: userPoolId },
+      { Name: "UserPoolClient", Value: clientId },
+    ],
+    Statistic: "Sum",
+    Period: 300,
+    EvaluationPeriods: 3,
+    DatapointsToAlarm: 1,
+    Threshold: 0,
+    ComparisonOperator: "GreaterThanThreshold",
+    TreatMissingData: "notBreaching",
+  }),
+);
+
+const cognito = simAws.cognitoIdentityProvider();
+
+cognito.userPool(userPoolId).auth.throttle.signIns(1);
+
+try {
+  await cognito.initiateAuth(
+    new InitiateAuthCommand({
+      ClientId: clientId,
+      AuthFlow: "USER_PASSWORD_AUTH",
+      AuthParameters: { USERNAME: "alice", PASSWORD: "Sup3rSecret!" },
+    }),
+  );
+} catch {
+  // TooManyRequestsException, counted in SignInThrottles.
+}
+
+await simAws.backgroundTasksComplete();
+await simAws.clock().advanceBy({ minutes: 6 });
+
+const { MetricAlarms } = await simAws
+  .cloudWatch()
+  .describeAlarms(
+    new DescribeAlarmsCommand({ AlarmNames: ["SignInsThrottling"] }),
+  );
+
+// ALARM.
+console.log(MetricAlarms?.[0]?.StateValue);
+```
+
+`signUps`, `tokenRefreshes` and `federations` sit beside `signIns` on the same object, and each turns away only its own kind of request. A pool answers normally until a test asks it to turn requests away, and it goes back to answering normally once it has turned away the number it was given.
+
 ## Pool ARNs and IAM policies
 
 A pool ARN is the pool id after `userpool/`, and the region appears twice:
@@ -4513,9 +4842,17 @@ Sim Cognito currently supports:
 - A served sign-in form at `/oauth2/authorize`, a sign-up form at `/signup`, a confirmation form at
   `/confirm`, and the two password reset forms at `/forgotPassword` and `/confirmForgotPassword`,
   each carrying the authorize parameters through to the next
+- A served stand-in for an identity provider's own sign-in page, so a browser completes a federated
+  sign-in on a local development server, with the subject and the mapped claims pre-filled and
+  editable
 - The pool user a federated sign-in creates, named `<ProviderName>_<subject>`, in the
   `EXTERNAL_PROVIDER` status, carrying the `identities` attribute and claim and the attributes the
   provider's `AttributeMapping` named
+- The triggers a federated sign-in runs, being `PreSignUp` and `PostConfirmation` on a first
+  sign-in, `PreAuthentication` and `PostAuthentication` on every one after it, and
+  `PreTokenGeneration` under `TokenGeneration_HostedAuth` when the code is exchanged
+- The `PreAuthentication` trigger a local user's managed login sign-in runs, for a password and for
+  a passkey alike, with a handler's refusal drawn on the sign-in form
 - A `REGIONAL` web ACL in front of the pool, attached by `AssociateWebACL` on simulated WAFv2 and
   evaluated against every request the hosted domain and the two `.well-known` documents answer
 - App client OAuth settings: `AllowedOAuthFlowsUserPoolClient`, `AllowedOAuthFlows`,
@@ -4546,6 +4883,12 @@ Sim Cognito currently supports:
 
 Current documented limitations:
 
+- `SignInSuccesses`, `SignUpSuccesses`, `TokenRefreshSuccesses`, `FederationSuccesses` and the four
+  `*Throttles` beside them are the `AWS/Cognito` metrics a pool publishes. No rate limit works
+  itself out here. A pool turns a request away only where a test has told it to. `CallCount` and
+  `ThrottleCount` under `AWS/Usage` are absent. A client-side request naming an app client the pool
+  has none of counts nothing at all, because the app client id is what finds the pool and an unknown
+  one reaches no pool to report against.
 - Five authentication flows run: `ADMIN_USER_PASSWORD_AUTH` and `REFRESH_TOKEN_AUTH` through
   `AdminInitiateAuth`, `USER_PASSWORD_AUTH` and `REFRESH_TOKEN_AUTH` through `InitiateAuth`, and
   `USER_AUTH` through either. SRP, custom authentication and device tracking are outside the
@@ -4754,9 +5097,9 @@ Current documented limitations:
   and `CustomMessage` are the only Lambda triggers that run. Every other `LambdaConfig` key is
   refused when the pool is created or updated, naming the trigger, because a pool that accepted one
   would never call the function the template named. The custom challenge triggers would need a
-  challenge loop this simulation lacks, and the migration and federation triggers have no external
-  directory to reach. A simulated identity provider answers with the user `signInAs` put there,
-  beyond the reach of a trigger.
+  challenge loop this simulation lacks, and the migration and inbound federation triggers have no
+  external directory to reach. A simulated identity provider answers with the user `signInAs` put
+  there, beyond the reach of a trigger.
 - `AdminCreateUser` leaves `PostConfirmation` unfired, here and on real Cognito. It is the tempting
   place to hang the trigger and the wrong one. A project relying on it would pass here and write no
   record in production.
@@ -4766,8 +5109,25 @@ Current documented limitations:
 - A `PreSignUp` handler asking to verify an attribute the sign-up did not carry refuses the sign-up
   with `InvalidParameterException`. Real Cognito refuses it too, and what it names the error has not
   been checked against a live account.
-- `PreSignUp_ExternalProvider` goes unreached too. A federated sign-in creates the pool's user
-  directly rather than through the sign-up path a trigger hangs off.
+- A federated first sign-in reports `PreSignUp_ExternalProvider` and then
+  `PostConfirmation_ConfirmSignUp`, and every sign-in after it reports
+  `PreAuthentication_Authentication` and `PostAuthentication_Authentication`. That is the split AWS
+  documents for a federated user, and it is what makes a handler that hangs a profile record off a
+  first sign-in run once for a Google user.
+- `autoConfirmUser` has nothing to do on a federated sign-in. The user is created in
+  `EXTERNAL_PROVIDER` and never passes through `UNCONFIRMED`, so there is no confirmation for a
+  handler to skip. `autoVerifyEmail` and `autoVerifyPhone` are applied there as they are for a
+  sign-up.
+- A local user signing in at managed login runs `PreAuthentication` and leaves `PostAuthentication`
+  unfired. The documented table names the first for `/login` and the second only for a federated
+  sign-in, and what real Cognito does with the second there was not checked against a live account.
+- A browser signed in from the managed login session it was already holding runs no sign-in trigger,
+  which is what the `PreAuthentication` docs say of a renewed session.
+- A code exchanged at the token endpoint reports `TokenGeneration_HostedAuth` where the sign-in
+  happened at an identity provider, and `TokenGeneration_Authentication` where the pool signed in
+  one of its own users. Real Cognito reports the same two. A browser signed in from the managed
+  login session it was already holding reports the local source whichever way that session started,
+  because the session records nothing about the method that began it.
 - A `PostConfirmation` or `PostAuthentication` handler that throws fails the request, and what it
   ran after stands. A confirmed user stays confirmed and the tokens a pool issued stay issued, as
   they do on real Cognito.
@@ -4875,7 +5235,10 @@ Current documented limitations:
   `userinfo_endpoint`, where real Cognito names one.
 - Nothing calls an external identity provider. A provider's `ProviderDetails` are recorded and
   validated for presence, and never used. The user a simulated provider signs in is the one
-  `signInAs` put there. That accessor is a divergence for the same reason `confirmationCode` is one.
+  `signInAs` put there, or the one the served stand-in page for that provider posted back. Both are
+  divergences for the same reason `confirmationCode` is one.
+- The stand-in page is served, and an authorize request that reaches `hostedAuthorize` directly is
+  refused instead, naming `signInAs`. Only the serving layer can answer a caller with a page.
 - A custom domain answers on its own hostname with no Route53 record of its own, where real AWS
   needs an alias record to the CloudFront distribution Cognito creates. The distribution name a
   domain reports is a name unserved here.

package/docs/services/lambda/README.md

@@ -2748,6 +2748,34 @@ otherwise. A time read at module scope is therefore read too early, exactly as i
 variables. See [simulated time](https://yulinsim.dev/time/) for the whole picture, including where real
 AWS puts the time on the event.
 
+## What an invocation counts in CloudWatch
+
+Every invocation publishes `Invocations` and a `Duration` into `AWS/Lambda`, dimensioned by
+`FunctionName`. One whose handler threw publishes an `Errors` beside them. Real Lambda counts a
+failed invocation under both, so an alarm reading one against the other gets a failure rate.
+
+Nothing has to be turned on for it, and the execution Role needs no permission, which is how real
+Lambda behaves. An alarm on `AWS/Lambda` `Errors` can therefore be driven to a state change by
+invoking a function that fails, rather than by publishing a datapoint by hand. `PutMetricData` still
+refuses the `AWS/Lambda` namespace, exactly as an account does. See the
+[CloudWatch docs](../cloudwatch/README.md) for an alarm reading these.
+
+`Duration` is measured on the simulation's clock. A handler that moves the clock reports the time it
+moved, and one that returns without touching it reports nothing spent.
+
+A stream event source mapping publishes `IteratorAge` as well, in milliseconds, once a batch of
+DynamoDB Streams or Kinesis records has been handled. It is the distance between the newest record
+in the batch and the moment the batch finished, measured on the simulation's clock. A test that lets
+records age before anything reads them gets back the interval it let pass. A batch whose handler
+threw is counted too, because the retry leaves the function further behind rather than caught up. A
+queue mapping publishes none of it, and neither does a direct invocation.
+
+`Throttles` and `ConcurrentExecutions` are absent. Both count what a concurrency limit turned away,
+and this simulation applies none.
+
+A function built outside a `SimAws` instance has no simulated CloudWatch to publish into. It runs and
+counts nothing.
+
 ## CloudFormation functions
 
 Sim CloudFormation can create Lambda functions from `AWS::Lambda::Function`, typically alongside a