@bajustone/fortress 1.0.0-rc.1

package/docs/observability.md

@@ -0,0 +1,394 @@
+# Observability
+
+Fortress has three layered observability surfaces. All three are zero-default — Fortress never writes to stderr, never imports `@opentelemetry/api`, and never allocates metric objects unless you explicitly opt in.
+
+## 1. Pluggable Logger (`config.logger`)
+
+The `FortressLogger` interface is structurally compatible with `pino`'s `BaseLogger` and Fastify's `FastifyBaseLogger`, so a `pino()` instance or `fastify.log` drops in directly with zero adapter code.
+
+```typescript
+export interface FortressLogger {
+  level: LogLevel | 'silent' | string;
+  fatal: LogFn;
+  error: LogFn;
+  warn: LogFn;
+  info: LogFn;
+  debug: LogFn;
+  trace: LogFn;
+  silent: LogFn;
+  child?: (bindings: Record<string, unknown>) => FortressLogger;
+  isLevelEnabled?: (level: LogLevel) => boolean;
+}
+```
+
+Where `LogFn` accepts any of three shapes:
+```typescript
+logger.info('a string');
+logger.info({ key: 'value' }, 'string with meta');
+logger.info('format %s', 'arg');
+```
+
+### Default: `SILENT_LOGGER`
+
+If you don't pass `config.logger`, Fortress uses a no-op logger where every method is a shared arrow function. Zero allocation per call.
+
+### Pino example
+
+```typescript
+import pino from 'pino';
+import { createFortress } from '@bajustone/fortress';
+
+const fortress = createFortress({
+  jwt: { key: process.env.JWT_SECRET! },
+  database: db,
+  logger: pino({ level: 'info' }),
+});
+```
+
+### Fastify example
+
+```typescript
+import Fastify from 'fastify';
+import { createFortress } from '@bajustone/fortress';
+
+const app = Fastify({ logger: { level: 'info' } });
+const fortress = createFortress({
+  jwt: { key: process.env.JWT_SECRET! },
+  database: db,
+  logger: app.log,
+});
+```
+
+### Console wrapper
+
+```typescript
+const consoleLogger = {
+  level: 'info',
+  fatal: (...a) => console.error('[fatal]', ...a),
+  error: (...a) => console.error('[error]', ...a),
+  warn:  (...a) => console.warn('[warn]',  ...a),
+  info:  (...a) => console.info('[info]',  ...a),
+  debug: (...a) => console.debug('[debug]', ...a),
+  trace: (...a) => console.debug('[trace]', ...a),
+  silent: () => {},
+};
+
+const fortress = createFortress({
+  jwt: { key: process.env.JWT_SECRET! },
+  database: db,
+  logger: consoleLogger,
+});
+```
+
+### What Fortress logs
+
+- **Plugin token-claim overwrite** (dev only, `warn` level) — when one plugin's `enrichTokenClaims` overwrites a claim set by an earlier plugin.
+- **Refresh token fingerprint mismatch** (`warn` level) — when `config.jwt.validateRefreshFingerprint === 'warn'` detects a UA change on refresh without rejecting.
+- **Unhandled errors in `fortress.handleRequest`** (`error` level) — anything that reaches the outer catch that isn't a `FortressError`.
+- **Unhandled errors in the Express error handler** (`error` level) — same, for the Express adapter.
+- **Observer failures** (`error` level) — when an auth/IAM/permission-check listener throws or rejects.
+
+Fortress does **not** call `logger.debug` or `logger.info` on hot paths like `checkPermission`. Hot-path observability goes through metrics and the sync `PermissionCheckEvent` observer, both of which are bounded and allocation-free when nobody subscribes. If you want per-check logs, attach a permission-check observer and call your logger explicitly — you'll pay the cost you opt into.
+
+## 2. Observer Lists
+
+Three independent listener lists on the `Fortress` instance. Each `add…Observer` call returns an `() => void` unsubscribe function. Listener exceptions are routed to `logger.error` and the remaining listeners continue.
+
+### `auth.addAuthObserver`
+
+Async, cold-path. Fires on every auth lifecycle event.
+
+```typescript
+import type { AuthEvent } from '@bajustone/fortress';
+
+const off = fortress.auth.addAuthObserver(async (event: AuthEvent) => {
+  switch (event.eventType) {
+    case 'LOGIN_SUCCESS':
+      // actor, identifier, ipAddress, userAgent available
+      break;
+    case 'LOGIN_FAILURE':
+      // identifier + error.code + error.message available
+      break;
+    case 'TOKEN_REUSE_DETECTED':
+      // metadata.tokenFamily available; send security alert
+      break;
+    // LOGOUT | REGISTER | TOKEN_REFRESH | TOKEN_FINGERPRINT_MISMATCH
+  }
+});
+
+// Later...
+off(); // unsubscribe
+```
+
+### `iam.addIamObserver`
+
+Async, cold-path. Fires on IAM mutation events (`ROLE_CREATED`, `ROLE_BOUND`, `PERMISSION_CHANGED`, `GROUP_MEMBER_ADDED`, etc.). Used by the audit-log plugin and the api-key plugin for cascade deletes.
+
+```typescript
+fortress.iam.addIamObserver(async (event) => {
+  if (event.eventType === 'ROLE_BOUND') {
+    await notifySlack(`Role ${event.targetId} bound to subject ${event.metadata?.subjectId}`);
+  }
+});
+```
+
+### `iam.addPermissionCheckObserver`
+
+**Synchronous, hot-path.** Fires on every `checkPermission` call with latency and cache-hit information.
+
+```typescript
+fortress.iam.addPermissionCheckObserver((event) => {
+  // This runs on the hot path — keep it bounded.
+  if (!event.allowed) {
+    metrics.increment('auth.denies', { resource: event.resource });
+  }
+});
+```
+
+**Why synchronous?** The listener signature returns `void`, not `Promise<void>`, to make it impossible to accidentally await expensive work inline. If you need async work, fire-and-forget: `void asyncWork()`.
+
+**Why separate from `addIamObserver`?** Permission checks fire thousands of times per minute in a busy app. Mixing them with mutation events would spam the audit-log plugin.
+
+### Error-routing gotcha (async observers only)
+
+The auth and IAM observer lists route listener failures to `logger.error` so one bad listener can't break the caller. But the safety net only engages when the listener **returns** the promise. Consider the two shapes:
+
+```typescript
+// ✅ Routed — the listener returns the promise, the list attaches .catch
+fortress.auth.addAuthObserver(async (event) => {
+  await siem.log(event); // a rejection here ends up at logger.error
+});
+
+// ✅ Routed — equivalent; the async function returns an implicit promise
+fortress.auth.addAuthObserver(event => siem.log(event));
+
+// ❌ Not routed — the listener returns `undefined`, the list has no handle
+//   on the inflight promise, and a rejection escapes to the runtime's
+//   unhandled-rejection handler.
+fortress.auth.addAuthObserver((event) => {
+  void siem.log(event);
+});
+```
+
+`void asyncWork()` is an explicit opt-out of the safety net. It's sometimes what you want — you accept the risk because you don't want the listener to wait on a cross-network call — but if you want rejections surfaced in your logger, return the promise. Fortress does not install a process-level `unhandledRejection` handler on your behalf.
+
+The permission-check observer is synchronous (returns `void`, not `Promise<void>`), so this gotcha doesn't apply to it — there's no async work to lose track of.
+
+## 3. OpenTelemetry Adapter (opt-in)
+
+The `@bajustone/fortress/otel` sub-path ships a single factory: `createOtelTelemetry()`. It's the **only file in the repository that imports `@opentelemetry/api`**, and the import is dynamic (`await import('@opentelemetry/api')`). Runtimes that don't import the `/otel` sub-path never resolve the peer dep.
+
+### Install
+
+```bash
+bun add @opentelemetry/api
+# Plus the SDK you want (this example uses Node SDK with OTLP):
+bun add @opentelemetry/sdk-node \
+        @opentelemetry/exporter-trace-otlp-http \
+        @opentelemetry/exporter-metrics-otlp-http
+```
+
+`@opentelemetry/api` is declared as an **optional peer dependency** on the Fortress `package.json`, so it's not installed automatically — you explicitly add it when you opt in.
+
+### Wire it up
+
+```typescript
+import { createFortress } from '@bajustone/fortress';
+import { createOtelTelemetry } from '@bajustone/fortress/otel';
+import { NodeSDK } from '@opentelemetry/sdk-node';
+import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http';
+import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics';
+
+// 1. Start an OTel SDK (registers global Tracer/Meter providers).
+const sdk = new NodeSDK({
+  metricReader: new PeriodicExportingMetricReader({
+    exporter: new OTLPMetricExporter({ url: process.env.OTEL_ENDPOINT! }),
+  }),
+});
+sdk.start();
+
+// 2. Wire the Fortress adapter.
+const observability = await createOtelTelemetry({ name: 'my-app-auth' });
+const fortress = createFortress({
+  jwt: { key: process.env.JWT_SECRET! },
+  database: db,
+  observability,
+});
+```
+
+### Metric catalog
+
+| Metric | Type | Unit | Attributes |
+|---|---|---|---|
+| `fortress.auth.events.total` | counter | — | `event`, `outcome`, `method` |
+| `fortress.iam.events.total` | counter | — | `event` |
+| `fortress.iam.permission_check.duration` | histogram | s | `subject_type`, `result`, `cached` |
+| `fortress.iam.permission_check.cache.hits` | counter | — | — |
+| `fortress.iam.permission_check.cache.misses` | counter | — | — |
+| `db.client.operation.duration` | histogram | s | `db.system.name`, `db.operation.name`, `db.collection.name` |
+
+**Histogram bucket boundaries:**
+
+- `fortress.iam.permission_check.duration`: `[0.0001, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1]`
+- `db.client.operation.duration`: `[0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1, 5, 10]` (OTel advisory default for DB clients)
+
+### Span catalog
+
+- `fortress.iam.permission_check.deny` — fired only on denied permission checks. Attributes: `subject.type`, `subject.id`, `resource`, `action`, `cached`. Allowed checks are metric-only — no span — to keep the hot path cheap.
+
+### Cardinality rules (important)
+
+Fortress **never** places user IDs, emails, tenant IDs, session IDs, or raw resource IDs on metric attributes. Those would cause cardinality explosions — every monitoring vendor charges you for high-cardinality metrics, and Prometheus will eat itself.
+
+Allowed metric attributes: `result`, `method`, `outcome`, `event`, `subject_type`, `cached`, and the three standard `db.*` semconv attributes. Everything else goes on spans (pivotable per trace) or logs (grep-able).
+
+### What Fortress does **not** emit
+
+- **`http.server.request.duration`** — that's the host framework's job via `@opentelemetry/instrumentation-http`, `@opentelemetry/instrumentation-hono`, `@opentelemetry/instrumentation-express`, etc. Emitting it here would double-count.
+- **Structured logs via `@opentelemetry/api-logs`** — that package is explicitly not for library authors and is alpha. Fortress uses its own `FortressLogger` contract, which is pino-compatible.
+
+## Provider contract (advanced)
+
+If you want to plug a non-OTel metric backend (custom Prometheus client, DataDog StatsD client, etc.), you can implement the `TelemetryProvider` interface directly instead of using the `/otel` adapter:
+
+```typescript
+import type { TelemetryProvider } from '@bajustone/fortress';
+
+const customTelemetry: TelemetryProvider = {
+  tracer: {
+    startSpan: (name, attrs) => makeSpan(name, attrs),
+    startActiveSpan: async (name, attrs, callback) => {
+      // Your backend must keep this span active across the async callback so
+      // nested database/IAM spans inherit it.
+      return myBackend.withActiveSpan(makeSpan(name, attrs), callback);
+    },
+  },
+  meter: {
+    createCounter: (name, opts) => ({ add: (v, a) => myBackend.counter(name).add(v, a) }),
+    createHistogram: (name, opts) => ({ record: (v, a) => myBackend.histogram(name).observe(v, a) }),
+  },
+};
+
+createFortress({ /* ... */ observability: customTelemetry });
+```
+
+Optional `startActiveSpan` is part of the frozen provider contract and is used at the request boundary for async parent propagation. Existing providers that implement only `startSpan` remain valid (Fortress falls back to it, without parent propagation). This is the escape hatch—most users should stick with `createOtelTelemetry()` because the OpenTelemetry SDK ecosystem already has exporters for every major backend.
+
+## 4. Event catalog
+
+Fortress emits structured events through three observer surfaces:
+
+- `fortress.auth.addAuthObserver(listener)` — user-lifecycle and token events.
+- `fortress.iam.addIamObserver(listener)` — IAM mutation events.
+- `fortress.iam.addPermissionCheckObserver(listener)` — every allow/deny check.
+
+The `audit-log` plugin subscribes to `addIamObserver` automatically so IAM events flow into the audit-log table without extra wiring. Wire your own `addAuthObserver` if you want auth events in the same log.
+
+### Auth events (`AuthEvent.eventType`)
+
+| Event | Outcome | Security weight | Recommended alert |
+|---|---|---|---|
+| `LOGIN_SUCCESS` | `success` | low | none |
+| `LOGIN_FAILURE` | `invalid_credentials` \| `account_locked` \| `account_inactive` \| `2fa_required` \| ... | medium | spike alert (>N per window per IP) |
+| `REGISTER` | `success` | low | spike alert (>N per window per IP) |
+| `LOGOUT` | `success` | low | none |
+| `TOKEN_REFRESH` | `success` \| `invalid` \| `expired` | low | none |
+| `TOKEN_REUSE_DETECTED` | `success` (revocation succeeded) | **high** | page on-call — indicates stolen refresh token |
+| `TOKEN_FINGERPRINT_MISMATCH` | `success` (revocation succeeded) | **high** | page on-call — indicates session hijack |
+| `IMPERSONATE` | `success` | medium | log to immutable trail |
+
+### IAM events (`IamEvent.eventType`)
+
+| Event | Where | Recommended alert |
+|---|---|---|
+| `ROLE_CREATED` / `ROLE_DELETED` / `ROLE_UPDATED` | `fortress.iam.createRole / deleteRole / updateRole` | log only |
+| `ROLE_PERMISSION_ADDED` / `ROLE_PERMISSION_REMOVED` | role-permission diff | log only |
+| `ROLE_BOUND` / `ROLE_UNBOUND` | role-binding mutations | log only |
+| `PERMISSION_CREATED` / `PERMISSION_DELETED` | permission catalog mutations | log only |
+| `PERMISSION_CHANGED` | direct-permission binding mutations | log only |
+| `GROUP_CREATED` / `GROUP_UPDATED` / `GROUP_DELETED` | group lifecycle mutations | log only |
+| `GROUP_MEMBER_ADDED` / `GROUP_MEMBER_REMOVED` | group membership mutations | log only |
+| `SERVICE_ACCOUNT_CREATED` / `SERVICE_ACCOUNT_UPDATED` / `SERVICE_ACCOUNT_DELETED` | service-account mutations | log only |
+
+All IAM mutation events carry `targetType`, `targetId`, and a `metadata` object suitable for audit-log persistence.
+
+### Permission-check events (`PermissionCheckEvent`)
+
+| Field | Description |
+|---|---|
+| `subjectType` | `'USER'` \| `'GROUP'` \| `'SERVICE_ACCOUNT'` |
+| `subjectId` | string id (kept off metric attributes by Fortress — stays on the in-process event) |
+| `resource`, `action` | what was checked |
+| `allowed` | final decision |
+| `cached` | whether the result was served from the permission cache |
+| `durationSeconds` | check latency |
+
+The handler is **synchronous and hot-path**. Keep it bounded — update a counter, push to an in-memory channel, never await a network call.
+
+## 5. Recommended dashboards and alerts
+
+### Auth dashboard
+
+- **Login success rate** = `rate(fortress.auth.events.total{event="LOGIN_SUCCESS"}[5m]) / rate(fortress.auth.events.total{event=~"LOGIN_.*"}[5m])`.
+- **Failure breakdown** by `outcome` attribute. A sudden spike in `invalid_credentials` from one IP range is credential-stuffing.
+- **Refresh churn** = `rate(fortress.auth.events.total{event="TOKEN_REFRESH",outcome="success"}[5m])`. Higher than expected (multiple per minute per user) indicates a misbehaving client.
+- **Token reuse** = `increase(fortress.auth.events.total{event="TOKEN_REUSE_DETECTED"}[1h])`. Any non-zero value is a paging incident — a refresh token was used after rotation.
+- **Impersonation** = `increase(fortress.auth.events.total{event="IMPERSONATE"}[1d])`. Audit weekly.
+
+### IAM dashboard
+
+- **Permission check rate**, separated by `result` (`allow` vs `deny`). A deny ratio over ~5% sustained indicates either a misconfig or active probing.
+- **Cache hit ratio** = `rate(fortress.iam.permission_check.cache.hits[5m]) / (rate(fortress.iam.permission_check.cache.hits[5m]) + rate(fortress.iam.permission_check.cache.misses[5m]))`. Healthy services see >90% after warm-up; a drop indicates churn (frequent role changes, cache invalidations).
+- **p99 check latency** = `histogram_quantile(0.99, sum by (le)(rate(fortress.iam.permission_check.duration_bucket[5m])))`. Target <10ms with cache, <100ms cache-miss.
+
+### OAuth dashboard (if mounted)
+
+- **Token-endpoint error rate** by `error` label from the response body shape; spike alert on `invalid_client`, `invalid_grant`.
+- **PKCE rejections** = audit-log `OAUTH_PKCE_REQUIRED` rows (if you mirror them into a counter via an `addAuthObserver`).
+- **Refresh-token family revocations** = `TOKEN_REUSE_DETECTED` events scoped to OAuth refresh tokens.
+
+### Database dashboard
+
+- **p99 query latency** = `histogram_quantile(0.99, sum by (le, db_operation_name)(rate(db_client_operation_duration_bucket[5m])))`. Triage slow queries by `db.operation.name` attribute.
+- **Operation rate** by `db.collection.name`. Useful when adding indexes or tuning the IAM cache.
+
+### Suggested alerts (production)
+
+| Alert | Expression / rule | Severity |
+|---|---|---|
+| Token-reuse detected | any `TOKEN_REUSE_DETECTED` event in 5m | **page** |
+| Token-fingerprint mismatch | any `TOKEN_FINGERPRINT_MISMATCH` event in 5m | **page** |
+| Login failure surge (per IP) | >100 failures from one IP in 10m | warn |
+| Permission-check deny ratio | `deny / total > 0.20` over 15m | warn |
+| Permission-check p99 latency | `p99 > 100ms` over 15m | warn |
+| Audit-log chain broken | `verifyChain().ok === false` from a scheduled job | **page** |
+| OAuth `invalid_client` surge | `>20/m` over 10m | warn |
+| Schema-version drift | `fortress migrate:check` non-zero exit in deploy preflight | **page** |
+
+All thresholds are starting points — tune to your traffic shape after a baseline week.
+
+## 6. Audit-log integration
+
+The `audit-log` plugin persists every `IamEvent` to `fortress_audit_log` automatically and can be configured to hash-chain entries (`auditLog({ hashChain: true })`) so deletions are detectable. Recommended pattern:
+
+```ts
+import { auditLog } from '@bajustone/fortress/plugins/audit-log';
+
+createFortress({
+  // ...
+  plugins: [auditLog({ hashChain: true })],
+});
+
+// Mirror auth events into the same log:
+fortress.auth.addAuthObserver((event) => {
+  fortress.plugins['audit-log'].logCustomEvent(event).catch((err) => {
+    fortress.logger.error({ err, event }, 'failed to persist auth event');
+  });
+});
+
+// Schedule a verifier (e.g. nightly cron):
+const result = await fortress.plugins['audit-log'].verifyChain();
+if (!result.ok) {
+  // Page on-call — someone tampered with the audit table.
+}
+```

package/docs/plugins/account-lockout.md

@@ -0,0 +1,131 @@
+# Account Lockout Plugin
+
+## Overview
+
+The `account-lockout` plugin adds progressive account lockout to Fortress. After a configurable number of failed login attempts, the account is temporarily locked. With escalation enabled, each successive lockout doubles the duration up to a configurable cap.
+
+Lockout sequence with defaults:
+- 1st lockout: 15 minutes
+- 2nd lockout: 30 minutes
+- 3rd lockout: 60 minutes (capped at `maxLockoutSeconds`)
+
+On successful login the failed attempt counter resets to zero.
+
+## Installation
+
+Import the `accountLockout` factory and pass it in the `plugins` array when creating a Fortress instance:
+
+```ts
+import { createFortress } from '@bajustone/fortress';
+import { accountLockout } from '@bajustone/fortress/plugins/account-lockout';
+
+const fortress = createFortress({
+  jwt: { key: 'your-secret-at-least-32-bytes!!' },
+  database: adapter,
+  plugins: [
+    accountLockout({
+      maxFailedAttempts: 5,
+      lockoutDurationSeconds: 900,
+      escalation: true,
+      maxLockoutSeconds: 3600,
+    }),
+  ],
+});
+```
+
+Once registered, methods are available at `fortress.plugins['account-lockout']` with full type safety.
+
+## Configuration
+
+All fields on `AccountLockoutConfig` are optional:
+
+| Option | Type | Default | Description |
+|---|---|---|---|
+| `maxFailedAttempts` | `number` | `5` | Number of consecutive failed login attempts before the account is locked. |
+| `lockoutDurationSeconds` | `number` | `900` (15 min) | Duration of the first lockout in seconds. |
+| `escalation` | `boolean` | `true` | When `true`, each successive lockout doubles the duration (exponential backoff). |
+| `maxLockoutSeconds` | `number` | `3600` (1 hour) | Maximum lockout duration in seconds. Escalation never exceeds this cap. |
+
+## How It Works
+
+The plugin uses three lifecycle hooks -- no manual calls are needed for the lockout logic itself:
+
+1. **`beforeLogin`** -- Checks if the identifier (email) is currently locked. If `lockedUntil` is in the future, a `FortressError` with code `UNAUTHORIZED` and message "Account temporarily locked. Try again later." is thrown.
+2. **`onLoginFailure`** -- Increments the failed attempt counter. When the counter reaches `maxFailedAttempts`, the account is locked for the calculated duration and `lockoutCount` is incremented.
+3. **`afterLogin`** -- Resets the failed attempt counter and clears the lock on successful login.
+
+## API Reference
+
+| Method | Signature | Returns |
+|---|---|---|
+| `getLockoutStatus` | `(identifier: string)` | `Promise<LockoutStatus>` |
+| `resetLockout` | `(identifier: string)` | `Promise<void>` |
+
+### getLockoutStatus
+
+Returns the current lockout status for an identifier (typically the user's email):
+
+```ts
+const status = await fortress.plugins['account-lockout'].getLockoutStatus('alice@example.com');
+
+console.log(status.isLocked);        // boolean
+console.log(status.failedAttempts);   // number
+console.log(status.lockoutCount);     // number
+console.log(status.lockedUntil);      // Date | null
+console.log(status.lastFailedAt);     // Date | null
+```
+
+The `LockoutStatus` type:
+
+```ts
+interface LockoutStatus {
+  identifier: string;
+  failedAttempts: number;
+  lockoutCount: number;
+  lockedUntil: Date | null;
+  lastFailedAt: Date | null;
+  isLocked: boolean;
+}
+```
+
+If no lockout record exists for the identifier, all counters are `0` and `isLocked` is `false`.
+
+### resetLockout
+
+Manually resets all lockout state for an identifier. Useful for admin-initiated unlocks:
+
+```ts
+await fortress.plugins['account-lockout'].resetLockout('alice@example.com');
+```
+
+This clears `failedAttempts`, `lockedUntil`, `lockoutCount`, and `lastFailedAt`.
+
+## Example
+
+```ts
+import { createFortress } from '@bajustone/fortress';
+import { accountLockout } from '@bajustone/fortress/plugins/account-lockout';
+
+const fortress = createFortress({
+  jwt: { key: 'your-secret-at-least-32-bytes!!' },
+  database: adapter,
+  plugins: [
+    accountLockout({
+      maxFailedAttempts: 3,
+      lockoutDurationSeconds: 60,
+      escalation: true,
+      maxLockoutSeconds: 600,
+    }),
+  ],
+});
+
+// After 3 failed logins, the account is locked for 60 seconds.
+// If the user fails again after unlock, the next lockout is 120 seconds.
+// The maximum lockout is capped at 600 seconds (10 minutes).
+
+// Admin can check status or manually unlock:
+const status = await fortress.plugins['account-lockout'].getLockoutStatus('alice@example.com');
+if (status.isLocked) {
+  await fortress.plugins['account-lockout'].resetLockout('alice@example.com');
+}
+```